容灾切换是怎么触发的？健康探测

老司机的后备箱里永远躺着一条备胎，容灾切换就是服务世界的备胎机制——平时用不上，用上时救命。对承载大模型流量的平台来说，一次推理服务宕机若无人处置，损失会随时间滚大，所以工程上把「自动发现、自动切换」做成标配。

先带走一个判断：切换的难点不在切换动作本身，而在判定——什么时候认定主节点真的不行了。判定太快会误杀健康的慢节点，太慢则故障窗口拉长，整个容灾设计都在这两头找平衡。

健康探测的两个层次

探测分两层。第一层是连通性探测：周期性向目标发一个轻量请求，能通就算活着，好比敲门听回应。第二层是业务探测：不只问「在不在」，还问「能不能干活」，比如发一个极小的推理请求，验证模型真的能返回结果。只做第一层会漏掉服务假死——进程在、端口通，但模型卡死不响应的情况。两层探测试的问题不同，成本也不同，重要服务通常两层都配。

两层探的不是同一件事，覆盖面与成本都不一样。

判定失败的窗口与次数

单次探测失败不可信，网络抖动一次就切换，等于天天换备胎。工程上用「窗口 + 次数」双条件：连续 N 次探测失败、且发生在 M 秒的时间窗内，才判定故障。比如连续 3 次、间隔 5 秒都失败，才算真挂了。窗口参数怎么定，取决于业务对中断时长的容忍度：容忍三十秒中断的，可以把窗口放宽些；对连续性敏感的，就要压短窗口并加大探测频率，代价是探测本身占用更多算力。

判定数据也会喂给告警体系，两者的衔接见预算告警的阈值是怎么设的？内部门道在这——预算告警管的是钱烧太快，健康告警管的是服务不行了，机制同源。

切换动作发生的那几秒

判定成立后，切换按固定次序展开：先把故障节点从服务列表摘除，让新请求不再路由过去；再把流量切到备用节点，常见做法是 DNS 切换、负载均衡权重调整或主备选举；最后是数据侧确认，检查会话、缓存这些临时状态是否需要重建。整个过程的目标是秒级完成，用户感知往往只是某一次请求变慢或收到一次重试提示。

切换后服务恢复到什么水平，是可以被量化的，统计方法见SLA 的可用性是怎么算的？过程拆开看。切换是否自动执行、自动到什么程度，也受部署形态影响，私有化环境的权限约束见私有化的授权是怎么管的？关键步骤一次讲清。

切回去之前要确认什么

故障修复不等于可以立刻回切，草率回切是二次事故的常见来源。回切前要确认三件事：故障根因已定位并修复，而不是碰巧恢复正常；修复版本先经过验证，必要时先小比例引流观察；备用节点上的临时数据已同步或已无留存必要。确认无误后按逐步放量回切，别一次性把全部流量砸回去。

回切策略还与数据在哪儿有关：若主备分处内外网，数据同步方式由边界设计决定，见混合部署的数据分界是怎么划的？。

容灾切换流程速查表

• 探测：连通性 + 业务探活两层，假死也要能发现
• 判定：连续 N 次失败且在时间窗内，防误杀
• 切换：摘除 → 流量切备 → 状态确认，目标秒级
• 回切：根因修复 + 验证通过 + 逐步放量

聊聊容灾切换的常见疑问

• 切换期间用户会掉线吗？：长连接会断开重连，短连接通常无感，客户端合理的重试逻辑能把影响压到一次请求延迟。
• 探测本身挂了怎么办？：探测服务要多点部署且互相独立，避免探测单点导致全系统误判，这是容灾设计的自我兜底。
• 备用节点平时要跑流量吗？：可以按低比例分摊流量保持温度，避免真正切换时冷启动拖慢恢复速度。