企业官网建设流程全解析

简介：由深信服大客户服务部编写的这份手册，专门面向负载均衡AD设备的运维人员与网络管理员，聚焦日常维护与故障排查场景。内容系统梳理了每日例行检查项，包括设备状态灯、接口指示灯、CPU运行及异常状况判断；同时覆盖每周维护要点，如控制台账号安全性检查、关闭远程维护与配置备份操作，帮助一线运维降低设备故障风险。手册还收录了无法登录控制台、虚拟服务无法访问、链路负载导致上网时快时慢、DNS策略不生效等常见问题的排错思路。资源包含一个doc格式文档，大小519KB，内容按章组织，结构清晰，适合作为设备维护的随身参考手册。目前已有250人学习过这份资料，对企业网络运维人员快速掌握深信服AD设备维护要点具有实用价值。

1. 一份老手册的含金量：负载均衡 AD 设备的巡检逻辑至今不过时

收到这份某厂商 AD 设备日常维护手册的时候，我第一反应是文件日期有点旧，但翻开之后发现里面的巡检框架放到今天依然能打。负载均衡 AD 设备在大多数机房里都是“常年不重启”的角色，正因为不重启，日常巡检和故障排查才格外依赖一套固定的动作：每天看状态灯和 CPU，每周查账号和备份，遇到虚拟服务不通、DNS 解析不了、上网时快时慢时按顺序排错。这份手册把这三层拆得很清楚，适合刚接手 AD 设备的运维值班人员、负责定期巡检的网络管理员，也适合想把自己手头维护工作标准化的从业者。它不教你怎么配置业务，而是教你怎么保证这台设备稳定地跑下去。

2. 每日例行检查：状态灯、接口灯和 CPU 占用率的三个判断

2.1 巡检前准备：一台 Windows 电脑和升级客户端

手册里列的准备项很朴素：一台装了 Windows 系统的电脑，设备与这台电脑网络互通，外加附件里带的工具包（包含升级客户端程序）。这三样东西几乎就是全部日常巡检的基础。

为什么强调 Windows？因为厂商提供的升级客户端是一个 Windows 程序，用来登录设备调试、备份配置、执行常用网络命令。用 Linux 或者 macOS 的同事不是不能 ping，而是到后面做配置备份和恢复时绕不开这个客户端，所以准备项里直接按 Windows 来准备最省事。

网络连通性这一步容易被忽略。很多时候巡检人到了机房，笔记本往设备旁边一放就开始 ping，结果发现不同——因为笔记本走的是无线，和设备管理口不在同一广播域。正确做法是先用网线把笔记本接到设备的管理口或内网口所处在的交换机 VLAN，并确认能 ping 通设备的管理 IP，再开始后面的检查流程。这一步不通，后面所有判断都没有意义。

2.2 面板状态灯与接口灯：什么状态才是正常的

设备面板上的灯是巡检时最快的信息来源，但也是误判最多的地方。手册里说的几个状态，我建议直接记下来：

先说最容易误判的一条：状态灯。很多新手看到状态灯亮了就以为设备出故障，实际上设备启动时系统加载，状态灯会亮约一分钟，等系统起来之后熄灭。真正要警惕的是设备已经跑了一段时间，状态灯突然长亮并且业务已经受影响。双机热备的备机状态灯会一直闪烁，这是正常状态，不是故障，别一看到闪烁就切主备。

接口灯的判断顺序手册里写得很清楚：先看网线有没有破损，再看水晶头有没有破损，然后查网卡双工模式是否协商匹配。全都查完没问题，再考虑重启设备并切换主备、联系技术支持。这里我补充一个实践习惯：查看网卡双工模式时，直接把设备端和对端交换机端口强制成千兆全双工或者自适应，很多“灯亮但丢包”的怪问题都是协商出来的。

2.3 CPU 占用率长期居高：先查并发、DOS 攻击和进程异常

登录设备控制台后看到的第一页就是网关运行状态，这一页能直接看到 CPU 占用率。日常巡检不需要每分钟盯一次，但每次登录后扫一眼 CPU 占用率，长期居高就要处理。

手册给的排查顺序很明确：先看在线用户数是否超过设备能承受的并发参数。这一点在很多场景下被忽略了——设备还是三年前的规格，业务量翻了一倍，在线用户数早就超过了设备能力上限，表现就是 CPU 长期飘高，虚拟服务偶尔卡顿。这时候不是设备坏了，是容量不够了。

第二个要看的是设备是否遭到 DOS 攻击。注意一个关键细节：设备默认是关闭防 DOS 攻击的，开启之后才会产生日志。所以我一般建议新设备上线时就把防 DOS 攻击打开，并接好日志告警，不要等 CPU 高了你再回头查历史。没有日志的话，这个环节基本靠猜。

第三个是某个进程是否异常。这一步手册里写的是需要联系技术支持确认，因为普通运维拿不到设备内部的进程级信息。你可以做的只有记录现象：什么时间开始的、CPU 从多少涨到多少、当时跑了哪些业务，然后把这些信息连同截图一起发给技术支持，能省很多来回沟通的时间。

2.4 硬件异响与异常声响：风扇和硬盘的应急处理

手册里对设备异常状况的检查只有一条：听。风扇老化、硬盘出现坏道，都会在设备内部产生和正常运行明显不同的声音。设备在机柜里跑久了，风扇积灰、轴承磨损很常见，硬盘则可能在大量读写时出现细微的咔哒声。

这类问题的处理方式很直接：听到异常声响，断开电源停止设备工作，有备用机立即切换，然后联系客服走返修流程。这里有个容易翻车的操作——不要为了“确认是不是风扇”而拆开设备外壳。负载均衡设备不像 PC 服务器，拆机之后保修状态会受影响，而且带电拆机还有短路风险。手册里“立即断开电源”这个动作是排在所有检查步骤之前的，这个优先级不要颠倒。

这个巡检逻辑听起来很简单，但真正执行到位的人不多。多数 AD 设备的故障是渐进式的，状态灯、CPU、异响都是早期信号，等到业务中断再去排查，往往已经晚了。

3. 上架、布线与升级客户端：把维护规矩做在前面

3.1 搬移与上架：AD2000 以上必须装托盘或导轨

手册里关于设备搬移有一条硬性要求：移动设备前一定要拔掉所有电源线和外部电缆。这个动作看起来是常识，但实际机房维护中，因为赶时间而带电拔线搬设备的情况并不少见。带电搬动设备轻则接口闪断影响业务，重则损坏硬盘或电源模块。

上架规则里有一条容易被忽略的区分：AD2000 以上（含 AD2000）的机型必须安装托盘或导轨，小机型则没有这个强制要求。为什么要做这个区分？因为大机型的重量和深度决定了直接放机柜托架上不稳固，遇到地震或人碰到机柜时可能滑落。没有标准机柜的场景下，可以把设备放在干净的工作台上，但有一个前提：工作台要足够结实，能承担设备和线缆的重量。

设备四周留出 10cm 散热空间这条，很多机房执行不到位。机柜里设备装得密，前后空间被线缆挡住，两边的散热缝隙不够，设备夏天跑高温就变得“很玄学”——时好时坏，找技术支持查半天也没查出配置问题，最后发现是散热。

上架过程中的耳片安装规则是：装了托盘或导轨的设备，可视情况不安装耳片；其他情况都必须装。另外注意同一机柜里其他设备，安装过程中不要碰掉别人的电源线和网线接口——真实机房里这个意外发生的频率比想象中高，特别是设备多、线缆乱的老机柜。

3.2 电源与布线：冗余电源要接上，尾纤和电源线不能捆一起

冗余电源设备的电源接线这一条，手册只有一句话：有冗余电源设备必须接通冗余电源。但在实际部署里，经常看到只接了一路电源的情况——机房配电不够，或者UPS接口不足，于是只给设备供一路电。等到这路电出问题，设备直接宕机，冗余电源形同虚设。维护人员应该把这个要求写进机房的电源规划里，而不是到设备上架那天再协调。

布线部分有三个容易踩的坑：

第一，走道线缆必须绑扎，绑扎后的线缆要互相靠拢、外观平直、线扣间距均匀、松紧适度；布放在槽道里的线缆可以不绑扎。这里的关键是“松紧适度”，很多工程队扎线用蛮力拉紧，时间长了信号线的内部结构被挤压，会出现千兆降百兆甚至链路闪断的隐性问题。

第二，信号电缆、尾纤、电源线要尽量避开，不要靠太近，更不能绑扎在一起。电源线捆扎时电流会产生电磁干扰，尾纤本身强度低，和硬质线缆绑在一起会被勒出微弯，导致光衰增大。这三类线缆在机柜里应该走不同的走线区域。

第三，尾纤绑扎前要检查走线区域附近有没有毛刺、锐边或锐角物体，机柜外布放时建议加装光纤保护套管（波纹管）。光纤的抗拉强度远低于大家的直觉，一个毛刺就可能让光模块接收功率掉到阈值以下，而且这种问题排查起来很费劲——链路状态显示在线，但误码率高，业务表现就是“卡但不掉线”。

3.3 线缆标签：对端位置怎么写才不坑后人

标签这件事在技术文档里很少被重视，但实际维护中，标签写得好不好直接影响故障排查速度。手册给的规则其实很清晰：

电源线标签的内容是电缆对端位置信息，写的是电缆所在侧对端设备、控制柜、分线盒或插座的位置信息。举个例子，设备 A 的电源线插在机柜顶部的 PDU 第 3 口，标签上要写清楚“PDU-3”，而不是写“设备A的电源线”——标签贴在设备这一端，需要知道的是对面是什么。

信号线标签要求两面分别标识电缆两端所连端口的位置信息，这样无论从哪一端看，都能知道这根线连着谁和谁的哪个口。

还有一个操作细节：粘贴标签之前先在整版标签纸上填写或打印好内容，再揭下粘贴。不要贴一条写一条，那样标签容易贴歪，而且手写的内容到后期根本认不出来。机房里灰尘大，时间一长打印的标签也会模糊，建议选择带覆膜的标签纸。

3.4 升级客户端的使用：备份配置、恢复配置和内置命令

升级客户端是这套维护体系里最核心的工具。它是厂商开发的用于调试设备的客户端，集成了常用网络命令，并且具备升级、备份、恢复配置的功能。日常巡检中 90% 的“后悔药”都靠它来实现。

使用前有一个前置条件：必须放通 TCP 51111 端口。这个端口是设备与升级客户端之间的通信端口。从管理电脑到设备管理口之间的路径上，如果有防火墙或者安全策略，要把这个端口加入白名单。常见的翻车现场是：电脑和设备在同一网段能 ping 通，但升级客户端登录一直失败，查到最后是终端安全软件拦了 51111。

登录时输入设备的 IP 地址和登录密码。默认密码是dlanrecover或控制台 Admin 管理员的密码。这里我多说一句：拿到设备后第一件要做的事就是改掉这个默认密码，而且不要把它写进 Word 或者记事本到处发，用密码管理器统一管。

登录成功后按 F10，可以进入维护界面，里面分两块：

登录前可以做一次连通性检查，确认 51111 端口能从管理电脑访问到设备。Windows 下用 telnet 验证最直接：

# 验证设备管理口 51111 端口是否放通 telnet 192.168.1.100 51111

如果端口通，telnet 窗口会进入一个空白或带提示符的界面，或者直接显示连接成功；如果端口不通，会提示无法连接。这个检查能区分“客户端问题”还是“网络问题”，避免一上来就怀疑设备故障。注意 Windows 10 以后系统默认没装 telnet 客户端，需要在“启用或关闭 Windows 功能”里先勾选“Telnet 客户端”。

4. 每周例行检查：控制台账号、远程维护与配置备份

4.1 控制台账号安全检查：默认密码和多余账号是两个重灾区

手册里把控制台账号安全检查归到以周为单位的例行工作里，但实际项目里我建议新设备上线当天就做一遍。检查项只有三条，每一条都对着真实事故来：

默认密码这个坑不需要多解释，任何一个在互联网上暴露管理口的设备，都会被扫描工具第一时间尝试默认密码。多余账号的问题则更隐蔽：很多时候是厂商调试人员临时创建的账号，调试结束后没有删除，或者前任运维离职后账号还留在设备上。

删除多余账号时要先确认这个账号是否还有人在用，特别是那些做了权限隔离的账号。我见过一个案例：维护人员看到登陆日志里有个陌生账号出现过，就顺手把它删了，结果该账号是另一个业务团队共用的监控账号，删完第二天监控告警就断了。正确做法是先查账号关联的会话和业务，再决定是否删除。

4.2 关闭远程维护：排错通道不能长期开放

手册里对远程维护的要求就一句：及时关闭远程维护功能，防止设备被非法入侵。这句话背后是有真实教训的。

厂商提供远程维护功能，本质上是让技术支持能远程登录设备协助排查问题。但很多设备从上线到退役，远程维护通道就一直开着——因为开起来方便，万一出问题能让人家直接上来弄。问题是，这个通道开着，意味着有一个额外的攻击面暴露在网络上。对于无法上网管理、只能在内网访问的设备，问题还不大；对于管理口暴露在公网的设备，这几乎等于把大门钥匙挂在门框上。

我处理过的一个翻车现场是：某台设备的远程维护没有关，后来安全扫描发现设备被爆破登录过。虽然后台日志显示爆破没有成功，但这个事件本身足够让人出一身冷汗。从那以后我接手任何 AD 设备，第一件事就是在用远程维护排查完问题后把通道关掉，检查项写进周例行的清单里。周巡检时确认一下远程维护处于关闭状态，是运维成本的很小一部分，换来的却是整个内网入口的安心。

4.3 配置备份：每半个月一次，让恢复有后悔药

配置备份的重要性不需要多讲，但备份周期值得讨论。手册建议每半个月进行一次配置备份，理由很实在：系统意外瘫痪时，如果没有一份“足够新”的配置，恢复过程会从“导入配置”变成“回忆配置”——回想这段时间加过哪些虚拟服务、改过哪些策略、调整过哪些路由，这个过程的痛苦程度和出错概率都远大于定期备份。

备份操作本身很简单，按 F10 进入升级客户端界面，选择“备份配置”，设备会生成一份配置文件并保存到本地。关键在备份文件的管理规范上。我见过太多备份文件名叫做“backup”或者“配置备份2020”，一年下来同一个目录里躺了二十几份同名文件，根本分不清哪份是最新的。

我的备份习惯是文件名包含设备角色、备份日期和配置版本，这样每次恢复的时候按文件名就能直接找到目标版本。备份后的验证同样重要——备份文件不是考完了就不管，每两次备份里至少做一次恢复演练，确认备份文件能正常加载。这一步很多团队会跳过，直到设备真的瘫痪才发现之前的备份文件已经损坏或格式不兼容。给你的备份文件加一个校验动作：恢复演练后把结果记录在案，下次备份日期自动排上。

5. 常见问题排查与避坑：虚拟服务、DNS 代理和智能路由

5.1 无法登录控制台：从 alarm 灯到 telnet 端口的排查链路

无法登录设备控制台是最高频的故障，手册给出的排查链路很完整，按顺序执行能定位到绝大多数问题：

第一步，看设备面板上的红色 alarm 灯是否常亮。红灯常亮代表设备硬件或系统层面已经异常，这种情况下登录不进去是结果，不是原因。灯异常时先按第 2 章的方式处理，而不是反复尝试登录。

第二步，确认管理电脑是否能 ping 通设备管理口地址。这一步排除了本地网络的问题。ping 不通时检查网线、VLAN、IP 段是否匹配。

第三步，从内网 telnet 设备的 443 和 51111 端口，确认控制台服务端口是否在监听。443 是 Web 控制台端口，51111 是升级客户端端口。这里给一个完整的验证命令：

# 分别验证 Web 控制台和升级客户端端口连通性 telnet 192.168.1.100 443 telnet 192.168.1.100 51111 # 跟踪到设备管理口的路由，看数据包走到哪一跳断了 tracert 192.168.1.100

443 通而 51111 不通，说明 Web 服务正常但升级客户端的通信链路有问题，检查中间设备的端口管理策略；两个端口都不通，说明数据包根本没到达设备内网口，这时用tracert看一下路由在哪一跳中断，能快速定位是交换机问题还是设备网口问题。

第四步，如果 tracert 显示数据包能到达设备内网口但控制台仍然打不开，那就需要让技术支持介入了，可能是控制台服务本身崩溃或者系统文件异常。前面几步做完，已经能排除掉 90% 的“进不去”问题。

5.2 虚拟服务建了却访问不了：链路、节点和部署模式逐个排

“虚拟服务建好了，就是从外网访问不了”这个问题，排错步骤相当多，手册列了十条。按我的习惯，把它分成四个层次来查：

链路层和状态层是第一步，打开设备控制台，分别看链路状态、虚拟服务状态和节点状态。线路离线、虚拟服务状态显示“繁忙”或“离线”、节点不在线，这三种情况都会直接导致访问失败。这一步三分钟就能确认，先做掉能避免后面全部白查。

第二步是检查访问地址和部署模式。访问的 IP 是不是配置的互联网 IP？注意 DNS 策略和重定向会使用互联网 IP 替换 IP 组里的地址，这个替换动作经常把访问路径弄乱。然后分模式看：网关模式下，可以先禁用虚拟服务，建立一个端口映射试着访问——如果端口映射能通，说明业务链路没问题，问题出在虚拟服务策略上；网桥模式则要检查 IP 组里是否包含网桥 IP，访问的地址是不是网桥 IP；旁路模式部署最容易被忽略的是 SNAT 配置，没有做 SNAT 的话回程流量可能走到错误路径。

第三步，做内部验证：从内网绕过 AD 直接访问应用系统，确认应用本身是正常的。这一步能把“设备问题”和“应用问题”隔离开。如果应用本身就访问不了，那前面的虚拟服务排查全都白做。

第四步是会话保持相关的坑。如果配置的是 cookie 会话保持，访问异常时改为源 IP 会话保持看是否恢复正常。cookie 模式依赖客户端浏览器的 Cookie 行为，一旦浏览器安全等级设置过高、禁用部分 cookie，就会出现“登陆之后一会儿又弹出来让你重新登录”的经典症状。此外，如果业务是专门的客户端软件（比如手机炒股类 App），配置好虚拟服务后要重启一下客户端，很多客户端软件的长连接在服务端配置变更后不会自动重建连接。

5.3 上网时快时慢：链路繁忙保护与 DNS 代理的相互影响

“上网时快时慢，DNS 有时解析不了域名”这个现象在链路负载设备上非常经典，手册给了六个可能原因，但核心矛盾集中在两个点上。

第一个核心是链路繁忙保护。当设备启用线路繁忙保护后，如果线路繁忙，上网数据会匹配到智能路由里面的 default 策略，而 default 策略默认采用流量最小加权算法。流量最小加权算法的特征是“谁空闲走谁”，所以会出现一会走线路 1、一会走线路 2 的抖动。对于访问电信站点，流量走到联通线路上，表现就是慢；反过来也一样。

这里有一个部署时的建议：刚部署设备时，把繁忙保护比例设置成 99%。99% 意味着只有线路几乎跑满时才触发保护调度，日常流量基本保持稳定走原线路。如果只有一条电信或一条联通线路，则建议直接禁用繁忙保护——没有备用线路可选时，开着这个功能只会增加调度的不确定性。

第二个核心是 DNS 解析。两个常见场景：访问的目标 IP 不在 ISP 地址段里面，导致智能路由的策略匹配不到，走默认策略后路径漂移；另一种是使用电信的地址去访问网通的 DNS 服务器，网通的 DNS 对电信源地址的请求不回复，表现就是“DNS 解析不了”。

如果启用了 DNS 代理，问题会更复杂。DNS 代理的调度策略选轮询或加权轮询时，访问电信站点可能恰好被调度到联通 DNS，联通 DNS 解析不了电信域名，就出现间歇性的解析失败。这时候去控制台看 DNS 状态，能看到 DNS 服务器“不停离线、又不停上线”的抖动现象。解决思路是把 DNS 客户端里面配置的 DNS 服务器都设置在对应 ISP 的地址段内，避免跨运营商解析。

5.4 避坑清单：DNS 策略不生效、会话掉线等四个高频现象

这里是这份手册里被问得最多的几个问题，我按“现象 → 原因 → 解决”的格式整理出来：

现象一：DNS 策略不生效。原因通常是域名不是 A 记录，或者服务器设置里没有填写监听地址，或者监听地址和 DNS 代理的监听地址冲突。解决：先确认域名解析类型是 A 记录；然后检查服务器设置里的监听地址是否为空、是否和 DNS 代理的监听地址在同一个 IP 上；最后把电脑的 DNS 手动填成 AD 的 IP 验证能否解析，同时核对公网 NS 记录是否正确。

现象二：DNS 代理不生效。原因通常是监听地址没填或者 DNS 服务器列表为空。解决：确认监听地址已配置；确认 DNS 服务器列表里有可用的 DNS 地址；在 DNS 状态里查看服务器是否在线；最后确认客户端电脑的 DNS 是否填的是监听地址或 DNS 服务器列表中的地址。排查时卡住的大多是前面的配置项，优先检查这些基础字段。

现象三：智能路由不生效。原因多为外网线路离线或处于繁忙状态。解决：检查智能路由配置是否正确；到链路状态查看外网线路的在线情况；在路由测试里做一次实际测试，看匹配结果走的是哪条线路；最后检查出站高级配置里出站会话保持的子网掩码是否合适——子网掩码设得过宽，会让本应走不同线路的会话被“绑定”到同一条线路。

现象四：登录应用系统后不断要求重新登录。这个问题的隐藏原因很多，手册给的排查顺序很有价值：先确认是否开启了会话保持；如果用的是 cookie 会话保持，检查客户 PC 的系统时间和 AD 的系统时间是否有较大误差——cookie 校验依赖时间，时间不准会直接导致会话失效；然后看 cookie 超时时间是否设置过短；最后检查客户端浏览器是否把安全等级调得过高、禁用了部分 cookie。时间误差这条是最容易被忽略的，AD 设备本身不跑 NTP 的场景在真实机房还挺常见。

6. 把手册落成自己的巡检模板：一张表管住每天、每周、每月

读完这份手册，最值得做的事不是把每一页背下来，而是把它改造成一张属于自己的巡检模板。运维工作最怕的就是“凭感觉”巡检：今天看看灯，明天看看 CPU，后天可能就忘了。模板的作用是让每次巡检动作一致、判断标准一致、记录方式一致。

我基于这份手册整理了一张三层的巡检表，直接打印出来贴在值班位或者放到共享文档里就能用：

这张表的每一行都不是凭空写的，上面每一行都对应手册里的一个具体章节。把表落到纸面上之后，还有三件事要配着做：一是把操作记录填到表里，日期、执行人、结果三项缺一不可；二是每次处理完故障后，把故障现象和处理方法追加到表下方的备注区，下次再遇到同样问题时不用翻聊天记录；三是把表里所有涉及账号密码的动作（比如修改密码、删除账号）和设备的密码变更记录关联起来，保证设备密码在任何时间点都有人能负责。

我自己的一个习惯是：接手任何一台 AD 设备，先不碰业务配置，而是把每天、每周、每半月这三组动作完整走一遍，走到“配置备份”那一步时，顺手验证一下上一轮的备份文件能否恢复。这个过程强制做下来，基本就能把设备的家底摸清——哪些账号在、哪些端口开着、配置备份是不是最新、上一次备份能不能用。从那以后，我做过的每台 AD 设备巡检都强制走完这张表再下班，因为手册里那些事故，几乎每一件都能在这张表上提前看到影子。希望这份手册和这张表能帮到你，让你手上的 AD 设备少一些“玄学故障”，多一些可控的确定性。

本文还有配套的精品资源，点击获取