企业官网建设流程全解析

简介：《深信服负载均衡AD日常维护手册簿》是一份由厂商大客户服务部整理的运维文档，面向负责深信服AD负载均衡设备的网络管理员与运维工程师，用于规范日常巡检、例行维护与常见故障排查。内含1个Word文档（doc格式），压缩包整体大小约519KB，内容结构完整，便于现场查阅与打印参考。目前已有250人学习下载。手册按时间维度组织：每日检查涵盖设备状态灯、接口指示灯、CPU运行状态及异常状况，每周检查包括控制台账号安全性、关闭远程维护与配置文件备份；第3章集中梳理了无法登录控制台、虚拟服务无法访问、DNS解析异常、DNS策略与代理不生效等典型问题的排错思路。阅读后可建立清晰的AD设备维护清单，降低因巡检疏漏或配置缺失导致的业务中断风险。

1. 负载均衡AD设备的日常维护：设备没坏，流量却断了，问题出在哪

接手某厂商AD系列负载均衡设备（下面统一叫AD）的日常维护，最常遇到的情况不是设备宕机，而是后端服务明明健康，节点池却显示一片红，业务流量被强行摘掉；或者主备切换时VIP没有漂移，整段业务静默几分钟。这类“设备没坏、流量断了”的问题，几乎都出在健康检查参数、双机心跳线和运维巡检习惯上。这份标题为《日常维护手册》的文档，真正要解决的就是三件事：新设备交付后怎么查基线、日常巡检看哪些指标不踩雷、故障出现时怎么快速定位。适合正在维护AD设备、准备接手设备的新人，以及想把手头运维流程固化成制度的团队。

2. 开局巡检：新设备接流量前，先核对这六个基线项

设备上架、网络调通之后不要急着导配置、接业务。先花半小时把基线核对完，后面日常维护会省掉很多半夜告警。我习惯把基线项分成设备自身状态和外部依赖两类，逐项确认，每项都留一条检查记录。

2.1 双机状态与时间同步：最容易埋雷的两个基础项

双机热备是AD设备最常见的部署形态。登录Web控制台后，第一件事看“双机状态”页面，确认本机是主机还是备机、对端设备是否在线、备机的“同步进度”是不是100%。这里有个坑：同步进度偶尔显示99.9%是正常的，因为会话表在持续变化，但如果在业务平稳期长期低于99%，说明配置同步或会话同步有积压，需要看日志确认是不是备机性能不足。

心跳线的物理链路比任何参数都重要。强烈建议心跳口单独用一对光纤或网线直连，不要和业务口共用链路，更不要跨三层设备。心跳链路抖动是“双主”故障的头号原因，后面避坑章节会单独展开。日常巡检时可以用命令行从设备侧ping对端心跳地址确认丢包率，但更推荐在Web控制台的“双机状态”页面直接看心跳收发包统计。

时间同步是另一个常被忽略的基线项。AD设备参与证书校验、日志审计和会话老化，设备间时间偏差超过一定阈值会导致主备判断异常。在系统设置里配置NTP服务器后，用测试按钮手动同步一次，确认设备时间与标准时间偏差在一秒以内。这里注意：如果公司内网有NTP服务器，优先用内网的，外网NTP在故障断网时反而会成为不稳定因素。

2.2 路由回程、授权与告警通道：业务没通和功能突然失效都藏在这里

网络基线里最容易被漏掉的是后端服务器的回程路由。AD设备做流量转发时，后端服务器返回数据包必须能回到AD设备，常见做法是给后端服务器配置指向AD设备接口的路由，或者在后端服务器上把AD设备的接口地址设为网关。巡检时可以选一台后端服务器，从服务器上ping VIP地址，能通说明回程路径基本没问题。如果ping不通，优先查后端服务器的路由表，而不是查AD设备——这个问题在开局阶段排查比业务上线后容易得多。

授权基线和证书到期时间一起查。登录控制台后翻到授权管理页面，确认序列号的有效期和已激活的特性模块。这里要留意：授权到期不会让设备宕机，但会让某些功能静默失效，比如健康检查的高级特性或链路负载功能突然不生效，排查时很难联想到授权。我的习惯是把授权到期时间记录在维护日历里，提前一个月提醒续期。

告警通道在开局阶段就要验证，不要等到故障时才想起来。配置Syslog服务器和邮件告警后，手工在设备上触发一条测试日志，确认日志服务器能收到、邮件能发出来。这一步做完，日常巡检才不会依赖人肉盯控制台。安全策略方面，确认管理口访问白名单、AD之间的同步端口、AD到后端健康检查端口都放通，并且写进防火墙变更记录。

完成以上六项基线检查后，再做一次全量配置备份，这份备份文件就是后续所有变更的“后悔药”。备份文件导出后存放的位置要固定，命名规则带日期，便于回滚和追溯。

3. 日常巡检实操：Web控制台看状态，命令行查深水区

巡检体系分为两个层次：日常在Web控制台做状态体检，定期进命令行诊断模式查深水区指标。只盯控制台首页是不够的，很多问题在指标趋势里，不在瞬时数值里。

3.1 Web控制台体检清单：每天看状态，每周看趋势

控制台首页的核心指标是CPU、内存、会话数和节点状态。CPU和内存要看持续趋势，不要被瞬时尖峰误导。瞬时尖峰通常是四层包转发峰值造成的，如果是持续高位运行，需要结合会话数判断是否达到设备处理瓶颈。这里有一个实用信号：单台后端服务器的会话数如果持续远高于同节点的其他后端，说明权重配置或调度算法有问题，这个信号往往比CPU告警来得更早。

每一天的巡检建议按下面的清单走一遍，全部看完不超过十分钟：

每周的巡检加两项：翻一遍Syslog里的告警级别日志，确认本周有没有被刷掉的告警；看一次各链路入口的流量分布，确认没有单链路打满的情况。每周五下午做这件事最合适，既能覆盖工作日高峰的数据，又不会占用周末时间。

3.2 命令行诊断：控制台不给看的信息在这查

Web控制台适合看业务状态，但遇到故障时，控制台页面刷新不够快，深水区信息需要通过命令行诊断模式获取。通常用SSH登录AD设备的管理地址，进入诊断模式后，先敲help看当前版本支持哪些查询命令。不同产品线的命令集有差异，但常用的查询类命令大差不差，保持只读操作：

# 查看系统整体健康状态 show system health # 查看所有虚拟服务的启停状态和流量统计 show slb vserver # 查看节点池内所有真实服务器的状态 show slb real-server # 查看当前会话表总数和分布 show session-table summary # 查看授权状态和剩余时间 show license

以上命令只做查询，不会改变配置，可以放心执行。真正的运维纪律是：查询类命令随便敲，写操作类命令必须先在变更窗口内执行。诊断模式下最常用的是查看会话同步状态，主备机上各执行一次会话统计命令，对比两条设备上的会话总数，差值越小说明同步越健康。如果差值持续扩大，优先查心跳链路和同步端口，不要急着重启设备。

日志筛查建议结合时间段做：控制台页面看实时日志，诊断命令查历史日志。故障排查时，先确定故障时间窗，再拉该时间窗内的日志，从VIP状态变化、健康检查失败记录、会话表老化记录三条线索顺藤摸瓜。日常运维中，日志是定位问题最快的路径，但前提是Syslog已经配置好，并且日志没有被循环覆盖。

4. 健康检查与调度参数：三个参数调不好，节点被误杀还说设备烂

健康检查是日常维护里改动最频繁、也最容易翻车的部分。很多“后端服务明明正常但节点被摘掉”的故障，根本原因不是设备判断逻辑有问题，而是健康检查参数和业务真实场景不匹配。

4.1 健康检查为什么会误判：失败判定耗时要会算

健康检查的判定逻辑可以用一句话概括：连续失败次数达到阈值，节点被标记为不可用；连续成功次数达到阈值，节点恢复可用。这里的核心是时间窗口的概念：

失败判定耗时 = 检查间隔 × 连续失败次数

举个例子，检查间隔5秒、连续失败3次，那么设备需要15秒才能把节点判定为故障。如果业务高峰期网络有瞬间抖动，第一次检查超时、第二次检查超时、第三次检查刚好赶上网卡处理延迟，节点就被误摘了。反过来，间隔设成30秒、失败次数设成3次，判定耗时90秒，故障影响时间又太长。

调参的原则是：优先调失败次数，不要优先调大间隔。拉大失败次数可以容忍瞬时抖动，同时保持故障发现速度不过于迟钝。对于一般TCP业务，我常用的初始值是检查间隔5秒、超时3秒、失败3次、恢复2次。这个配置在多数场景下能平衡误杀和故障发现速度，但上线后要结合业务实测情况再微调。

4.2 健康检查参数表：每个参数改的是什么要清楚

健康检查参数之间是联动关系，单独调一个参数而不看整体效果，往往会造成新问题。下面这张表是我维护过程中整理的参考配置，不同业务类型需要调整的侧重点不一样：

检查端口写错是最低级的翻车现场。后端服务监听8443端口，健康检查却配了443端口，结果永远是失败，节点永远处于不可用状态。配置检查任务时，建议先在控制台用“手动测试”按钮验证一次，确认返回结果正常，再保存配置。

4.3 调度算法与会话保持：参数之间会打架

调度算法的维护难点不是参数本身，而是算法和会话保持策略的配合。加权轮询适合后端性能差异明显的场景，最小连接数适合长连接业务，源地址哈希适合需要会话粘滞的场景。但开了会话保持之后，再固定的调度算法也会被会话保持逻辑“覆盖”掉——这是最常见的误用。

一个典型的错配场景是：业务用了会话保持，同时后端权重调整想控制流量比例，结果发现权重怎么调都没用。原因在于会话保持优先，后续同一源地址的请求会持续被调度到同一台后端，权重只对新建会话生效。遇到这种情况，不要死磕权重参数，先确认会话保持超时时间和调度算法是否匹配业务特征。

会话保持超时时间也是日常维护不得不调的参数。超时太短，用户频繁被重新调度，表现为“登录后一会儿又被踢下线”；超时太长，后端服务器释放时还有大量会话保持记录，造成节点权重失衡。判断依据很简单：会话保持超时略大于业务的登录态有效期即可。比如业务登录态30分钟，会话保持超时设成45分钟是合理的。

连接超时参数关注度低，但影响面大。四层业务的连接超时设置过短，长轮询应用会被设备主动断开连接。排查时表现为“连接偶尔断一下、没有规律”，把连接超时从30秒调到300秒后问题消失。这类问题日志里不一定有明确的报错，需要靠排查经验积累。

5. 维护避坑记录：四次告警抖动，四种“我以为”

日常维护的坑绝大多数不是设备本身的功能缺陷，而是对设备行为逻辑的理解偏差。这里记录四个典型的故障排查过程，每一条都是“现象—原因—解决”的结构，供排查时对照。

5.1 健康检查全红，业务访问却正常

现象：某个节点池内的所有后端服务器在控制台上全部显示不可用，但直接访问后端服务器的业务端口完全正常。

原因：健康检查端口写错，检查了后端没有监听的端口，或者检查路径返回了预期外的状态码。最隐蔽的是HTTP健康检查配置了首页路径，但该路径做了重定向，每次检查返回301/302，设备判定为失败。

解决：先用控制台的“手动测试”功能对目标后端发起一次健康检查，观察返回内容；确认检查端口与后端监听端口一致；HTTP检查路径避开会做重定向的地址，选用一个固定返回200的状态接口。改完之后观察两个检查周期，确认节点状态恢复绿色。

5.2 主备切换后VIP没有漂移，变成了双主

现象：半夜心跳告警，第二天早上看日志发现两台设备都变为主机状态，VIP流量混乱。

原因：心跳链路存在单点隐患，比如心跳线经过的交换机端口有间歇性丢包，导致主备设备在一定时间内互相认为对方失联，各自抢占主角色。

解决：把心跳口改为物理直连，不经过任何交换设备；在双机配置里降低心跳超时和重试次数，让误判能更快恢复；同时确认主备优先级配置正确，避免出现两端优先级相同的情况。改造后做一次主动切换演练，验证VIP漂移正常。

5.3 后端服务器下电前没摘除，连接全部RST

现象：发布窗口对一台后端服务器做下线操作，直接关机后，访问该业务的用户出现大量报错。

原因：没有先通过控制台把节点置为“禁用”状态，设备仍在向这台服务器转发新连接；服务器断电后，TCP连接被RST终结，用户请求失败。

解决：发布流程里增加“先摘除节点、再操作服务器、验证完恢复节点”的固定步骤。节点摘除后，设备会停止向该节点调度新连接，已在处理的连接会在超时后自然断开，这一步做完再关机就安全了。这个流程应该写进发布规范，而不只是依赖操作人员临时注意。

5.4 版本升级后健康检查策略没生效

现象：设备版本升级完成后，部分新建的健康检查任务没有生效，节点池依然用旧的参数在运行。

原因：升级过程中部分配置分区的迁移不完整，或者新版本的配置结构有变化，旧备份里的策略无法直接对应到新版本。

解决：升级前确认当前运行版本与目标版本的兼容路径，避免跨大版本直接升级；升级前导出当前配置，升级后逐项核对关键策略，不要只看版本号就确认完成；发现策略未生效时，重新创建健康检查任务并手动测试，不要反复导入旧配置。

5.5 会话保持突然失效，用户反复重新登录

现象：业务高峰期用户反馈频繁掉线，需要反复登录，后端服务器负载分布却非常均匀。

原因：会话保持超时参数被调短，刚好短于业务登录态的有效时长，导致用户会话频繁被重新调度。

解决：确认业务登录态的有效时长，将会话保持超时设置高于该值；同时检查是否在调整其他参数时误改了会话保持策略。会话保持相关参数改动后，建议做一次持续连接测试，模拟用户长在线场景，确认不会中途断掉。

6. 应急切换与配置备份：维护手册里最值得练熟的两种保命操作

日常维护手册里最有价值的不是那些“精致”的参数调优，而是在故障窗口里能稳定执行的应急操作。主备切换演练和配置备份恢复，是两项一定要练熟的动作。

6.1 主备切换演练的正确顺序

半年做一次主备切换演练，确认VIP漂移和业务恢复能力不是停留在纸面上。演练要在业务低峰期进行，流程是：先确认备机同步进度为100%，再在主机上手动触发切换，用一段轮询脚本盯着VIP的漂移时间：

#!/bin/bash # 用法: ./failover_check.sh <VIP地址> TARGET=$1 echo "开始轮询 $TARGET 连通性" for i in {1..60}; do if ping -c 1 -W 1 $TARGET > /dev/null 2>&1; then echo "[$(date +%H:%M:%S)] VIP 可达，切换完成" exit 0 else echo "[$(date +%H:%M:%S)] VIP 不可达，等待漂移..." sleep 2 fi done echo "VIP 在 2 分钟内未漂移，请检查双机状态" exit 1

轮询脚本的意义是把“凭感觉等待”变成“量化观察”。VIP从不可达到可达的时间就是漂移时间，正常应该在几秒到十几秒之间。如果超过30秒还未恢复，需要立刻终止演练，切回原主机并排查心跳和VIP绑定配置。演练完成后，记录本次漂移时间、业务恢复时间、后端连接重建情况，作为下次演练的对比基线。

6.2 配置备份与恢复：最容易被忽略的“后悔药”

配置备份这件事，重要性排在所有维护动作前面。每周导出一份配置文件到本地，保留最近三份，命名规则统一为“设备名_配置日期”。备份不只是为了防设备损坏，更是为了给每一次变更留后路。变更配置前导出一份，变更后确认无问题再导出一份，回滚时就有两个明确的恢复点。

恢复备份时要注意：同版本内的备份恢复最稳定，跨大版本恢复容易出现部分策略不兼容。恢复完成后，按顺序检查授权状态、节点池状态、VIP状态、双机同步状态，确认没有因恢复操作引起的次生问题。如果恢复后授权丢失或功能异常，优先联系厂商技术支持确认版本兼容路径，不要反复尝试导入旧配置。

当年我第一次独立负责AD设备维护时，觉得双机热备配好就万事大吉，结果一次心跳线抖动让我体验了双主故障的滋味。从那以后，我把“心跳口物理直连”和“每季度一次切换演练”写进了自己的维护清单，再没出过同类问题。这套流程不难，难的是每次都按流程走。希望帮到你。

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