多地址接入的切换判定：条件、粒度、冷却与放量｜洹拓科技
一、”异常即切换”这句需求只写了一件事
多地址接入是多机房业务的基础配置：一个业务入口后面挂着若干可用地址，出问题时把流量从坏的那个挪走。麻烦在于这套东西常被压成一句需求交给工程，那句需求是”异常就切换”。据一篇多地址接入的工程实践整理，失效判定被简化到这里，正是来回抖动与长期不回切的源头；该文给出的四项约束必须同时定义，判定条件、判定粒度、冷却策略、回切放量，缺一项，其余三项做得再细也会在缺的那一项上失守。
该文的切入点是”三地址两故障”的一次现场：池内有三个可用地址，期间出现两类性质不同的故障。一类整体不可达，探测、业务侧信号、外部通告都指向同一个结论，判定和回切都不难。另一类只在部分接口或部分地区表现异常，其余路径完全正常。第二类才是真正要设计的场景，因为它同时考验判定条件与判定粒度，还会把冷却和放量两件事逼出来：地址并没有全坏，切过去之后要不要回来、多久允许回来、一次放多少量回去，”异常即切换”这几个字里一个也没答。
洹拓在交付里见过不少这样的地址池：切换动作实现得完整，四件事只定义了一件事，其余三件靠值班人员临场判断。这样的系统扛得住一次故障，扛不住第二次。
二、判定条件：三类信号各自会怎么误判
判定条件的三条来源要分开写，因为它们的失效方式不同，能承担的角色也不同。
探测，也就是主动心跳与连通性检查，反应最快、成本最低。它测的对象是”这个地址通不通”，不是”这个地址上的业务好不好”。两类误判出在这里：探测端口还活着，应用进程已经不可用；探测路径与业务路径不同构，中间设备放行了探测包却没有放行真实请求。所以探测适合当触发器，不适合当结论。
业务侧的错误率与延迟，是离用户感受最直接的一路，它有两个污染来源。一个是突发流量：判定窗口取得短，一次正常的高峰就会被读成地址故障，因为流量涨得急时排队与超时先出现，错误本身未必和地址有关。窗口该取多长不由习惯决定，而由”一次真实地址故障在业务侧稳定显形所需的时间”决定；窗口短于这个时间，判定就是在跟随流量形状而不是跟随故障。另一个是分母：低流量时段少量失败请求就能把比例推高。所以窗口要同时有时间下限与样本量下限，只满足其中一个，判定就落在噪声上。
外部状态，指机房或运营商层面的通告，只能做复核。它在两个方向上出错：滞后于故障；覆盖了故障却没有覆盖自家业务实际受影响的那部分。写法上要落两句话，外部通告不能单独触发切换，只能确认或否决一条已由前两类信号提出的候选；外部通告说一切正常，也不能让内部判定失效。
落到规则上，建议以业务侧信号为主判、探测做快速预筛、外部通告做复核与否决。三路的原始判定结果都要留档，事后才可能复盘是哪一路把结论带偏。
三、判定粒度：最容易设错的一层
粒度决定”什么算坏”，四种粒度的后果完全不同。
| 判定粒度 | 判的是什么 | 典型误判 | 摘除的影响范围 |
|---|---|---|---|
| 按地址 | 整个地址可用或不可用 | 部分接口坏时，要么读成整体可用而长期不摘，要么读成整体不可用而把正常接口一起切走 | 该地址承载的全部业务 |
| 按接口 | 单个接口或单类请求的可用性 | 低流量接口凑不够样本，长期停在不确定这一档 | 只对应坏掉的那一类请求 |
| 按地区 | 同一地址在不同来源地区的表现 | 来源信息不可得或被中转掩盖时，把局部异常读成全局正常 | 该地区入口对应的流量 |
| 按业务线 | 以业务为单位聚合它依赖的地址 | 共用地址的多个业务互相牵连，一条线的问题把另一条线一起摘掉 | 该业务线的全部入口 |
按地址判之所以危险，是因为”只有部分接口坏”这类故障在这种粒度下只有两种读法，而两种读法都错。判成整体可用，受影响的那部分业务持续流血；判成整体不可用，正常接口被一起摘除，流量涌进池内另外两个地址，把容量问题也带出来。
按接口判把这种误判压小了，代价是状态数量成倍增加，每一份状态都要独立凑够判定样本。更关键的是一处连锁：摘除单位从地址变成接口，回切也只能按接口回切，冷却与放量的对象必须跟着改写。这一点最常被漏，粒度改了而冷却和放量还按地址算，等于换个地方继续抖。
按地区判要先看数据面能否拿到真实来源地区，被中转与代理掩盖时，地区维度只是名义存在。按业务线判要处理共用地址，判定单位与故障域不重合时必须写清是整条线一起切，还是这条线在该地址上的请求被切走。
四、冷却策略：要防的是振荡
冷却不是”等一等”，它防的是同一个地址在两个结论之间来回跳。三件事要定。
第一件是计时从哪一刻起算，三个候选时刻的行为差别很大。从判失效那一刻起算最激进，此时摘除动作可能还没做完，冷却会在动作完成前就开始消耗。从恢复探测通过那一刻起算又太松，等于允许一个反复好坏的地址随时回来。建议从”真正摘除完成”这一刻起算，起算点要写成可核对的事件，比如该地址上的存量连接排空完成、已不再承接新流量，并把这一时刻连同判定依据一起记录。
第二件是冷却期内是否允许人工强制切。要允许，但要把它做成带留痕的例外，而不是一句”特事特办”。强制动作至少记录发起人、发起时看到的信号、承诺的回收条件；到期必须复核，否则人工例外会变成长期挂着的状态，后面所有的自动判定都建立在一个人工偏离之上。同一方向上的另一件事也要定：在冷却期内把流量强行切回原地址，是否要触发一段新的冷却，默认应当要，理由与自动切出时相同。
第三件是出冷却的判定，必须与进入冷却时使用同一套条件、同一粒度、同一窗口。最常见的设计缺陷是进冷却用业务错误率、出冷却用探测通过，两套条件不对称，地址还没真正恢复就被放回来，接着再抖一次。兜底规则也在这里：同一地址在同一时段内重复进冷却达到约定次数，就停止自动恢复转人工决策，并把这几轮的原始判定数据一并留下。
冷却时长取多少不由习惯决定，而由两件事的交集决定：故障在这类地址上通常的持续时长，以及一次回切被证伪所需要的时间。后者更常被忽略，但它是主导项。
五、回切放量：分批规则与停止条件
回切要同时解决三个问题，一是回到哪个地址，二是用什么切法，三是每批停留多久、看什么指标、什么时候停。
回到哪个地址，取决于最初为什么切走。若当时是全量摘除，回切目标就是原地址；若是按接口或按地区局部摘除，就只把那一部分放回原地址，不该动的部分继续停在原处。这一步写不清，后面的放量就是在放大一个错误的目标。
三种切法各自适合的场景不同。
- 按流量比例放：适合故障影响面不明但已确认地址本身恢复的情况；难点在小流量档位样本不足，比例指标看不清，此时要改用更直接的信号判断这一批有没有观察价值，比如请求能否正常建立，而不是等比例稳定。
- 按地区放：适合”只有部分地区异常”这类故障，把受影响地区的表现单独盯住，其他地区先回；要防止按地区切开了判定却没有按地区切开冷却，两边对象不一致就还会振荡。
- 按业务优先级放：适合有强实时链路的客户，把不能出错的业务放在后面几批，让可容忍波动的业务先踩路；这条线要和客户一起定，优先级不能只由运维偏好决定。
每批停留多久，该由”这一档流量下，判定所需的时间窗口与样本量下限都能走完”决定，而不是拍一个固定分钟数。看的指标至少四组：业务侧错误率、延迟分布的尾部、探测与外部状态是否一致、客户可感知的业务量本身。尾延迟比平均值更早报警，平均值把问题抹平了才看见，通常已经晚了一轮。
停止与回退的条件要写成单条可判的语句：任一批次内错误率抬升或尾延迟超出该业务自己定的基线，立即停止继续放量，并回退到上一批的档位；同一地址连续多批没能通过，就把回切整体挂起，转人工评估故障是否只是被容量掩盖。回退动作本身也要留冷却，避免”放量、失败、回退、再放量”在没有新证据的情况下循环。
六、逐项验收与三处同源
四项约束要各配一条可复现的测试动作和预期结果，这也是该文强调的落点：每条约束能被单独验证，而不是合并成”切换功能已实现”一句。
- 判定条件：注入探测失败但业务侧完全正常的组合，预期是不切换；注入探测正常但业务错误率升高的组合，预期是走主判路径切出。后面这条最常被漏，它才是证明”探测只做预筛”这条规则真的生效的动作。
- 判定粒度：只让部分接口异常，预期是仅这些接口被摘，同地址其余接口保持可用；同时核对回切是否也按接口执行。
- 冷却策略：把地址恢复时间制造得比冷却时长短，预期是不回切；在冷却期内做一次人工强制，预期是留下发起人、依据与到期复核记录。
- 回切放量：按预置批次推进一次回切，中途注入失败，预期是停在当前批并回退上一档，且回退也进冷却。
演练报告的结论栏不该只写”切换成功”。这四个字只覆盖了动作是否执行，没有说明执行得对不对：按错误的粒度切走全部接口，动作照样成功；冷却时间没生效、放量一步到位，报告里也依然是成功。结论要按上面四组预期逐条填，填不出原始数据的那一条就不算通过。
配置一致性是最容易松的一道。四组值要定义清楚：地址池成员配置、探测参数、冷却时长、放量批次；它们同时存在于应用侧、网关侧与文档说明三处。三处不同源时必须有一句事先约定好的裁决规则，而不是靠值守人员当场判断哪一处”看起来更新”。
| 配置项 | 三处都可能出现 | 以哪一处为准 | 另一处怎么处置 |
|---|---|---|---|
| 地址池成员 | 应用侧、网关侧、文档 | 网关侧，它决定实际转发 | 应用侧同步改写，文档记录生效时刻 |
| 探测参数 | 应用侧、网关侧、文档 | 执行探测的那一侧 | 非执行侧只保留说明，不留可编辑副本 |
| 冷却时长 | 应用侧、网关侧、文档 | 网关侧的切换控制器 | 变更须走同一次审批，两侧一起改 |
| 放量批次 | 应用侧、网关侧、文档 | 演练与变更单里固化的那一版 | 文档抄录，不得自行调整批次 |
同源的真正含义不是三处数值长得一样，而是”改一处必须留下另两处的对齐证据”。这条要进变更模板，成为切换类配置评审的固定项，而不是靠事后巡检发现不一致。对做云服务和 SaaS 交付的团队来说，地址池这块能签的从来不是一句”支持自动切换”，而是上面这张表加四组验收动作。