故障切换不是“切过去就好”

高可用架构的价值，不只体现在故障发生时业务能否继续提供服务，还体现在故障结束后，团队能否准确回答三个问题：为什么切、切得对不对、下次能不能更快。如果切换过程没有留下足够细的日志，这三个问题往往只能靠人工回忆和零散线索拼凑，复盘容易变成“猜原因”。

因此，把故障切换的全过程日志当作一项基础设施能力来建设，而不是临时抓取，是提升可用性治理水平的关键一步。

一次完整切换包含哪些可记录环节

1. 探测与判定

健康检查、心跳超时、探测失败次数、探测源位置等信息，决定了系统“是否认为”某个实例异常。这里需要记录判定依据而不只是结论，否则无法区分真实故障与误判。

2. 决策与仲裁

记录触发规则、参与仲裁的节点、多数派结果、是否存在脑裂风险的判断过程。决策链一旦缺失，事后很难解释“为什么是这台接管，而不是另一台”。

3. 流量与状态切换

涉及虚拟IP漂移、DNS或负载均衡权重调整、连接摘除与重建、主从角色变更、数据一致性校验点等动作。建议按时间顺序逐条记录，而不是只记最终状态。

4. 恢复与回切

原实例恢复时间、是否满足自动回切条件、回切是否被执行、回切后是否需要人工确认，都属于切换事件的完整生命周期。

建议留存的日志字段

• 时间戳：统一时区与时钟源，并与监控、告警系统对齐
• 切换标识：为一次切换事件分配全链路关联ID，贯穿各组件日志
• 触发原因：探测失败、人工操作、计划内维护、上游依赖异常等分类
• 参与角色：决策节点、被切换实例、依赖的存储与网络设备
• 状态变迁：切换前后角色、权重、连接与会话保持状态
• 耗时分解：判定耗时、决策耗时、流量收敛耗时、业务恢复耗时
• 结果与残留：是否成功、是否有节点未同步、是否有告警未闭环

采集与留存的工程要点

1. 日志先行：切换动作开始前就写入事件起始记录，避免进程被终止导致关键信息丢失。
2. 集中汇聚：将编排组件、负载均衡、数据库、中间件、网络设备的日志统一采集，按切换标识串接。
3. 时间同步：所有节点使用统一时间源，否则跨设备时序无法还原。
4. 分级留存：原始日志与结构化事件分别保存，结构化字段便于检索与统计。
5. 可读性：为切换事件生成一份人类可读的时间线视图，降低复盘门槛。
6. 访问控制：日志涉及内网拓扑与配置信息，应控制访问权限，并按内部规范确定保存周期。

复盘时常见的分析路径

有了完整日志，复盘可以从“下结论”转向“建证据链”：

• 切换由真实故障触发，还是探测阈值、网络抖动导致的误判
• 切换耗时主要消耗在哪一段，是判定慢、决策慢，还是流量收敛慢
• 是否存在重复切换、来回震荡，触发条件是否需要调整
• 数据是否存在丢失或重复风险，状态同步是否在切换前完成
• 告警、值班响应与切换动作之间的时间关系是否合理

需要注意的是，日志只能说明系统做了什么，是否应该这么做，仍要结合业务目标与架构约束来判断。

与机房和基础设施的配合

故障切换往往涉及网络路径、机柜供电、跨机房链路等底层条件。将IDC侧的链路状态、设备告警与业务侧切换日志放在同一条时间线上，才能判断问题出在应用层还是基础设施层。这也是托管与多线接入场景中，运维与机房协同复盘的重点。

小结

高可用架构的成熟度，很大程度上取决于其可观测与可回溯能力。把故障切换全过程日志留好、串好、看得懂，既能缩短下一次故障的定位时间，也能让架构优化有据可依，而不是依赖经验直觉。