Clos 网络中的可拒答根因分析（OSDI 2026）
原题：The Abstention Protocol: RCA for Clos Fabrics (Operational Systems)
一句话总结：面对 Clos 网络中 0.3%–1% 链路持续存在的背景故障，CoreSec 用带
requisite、required、sufficient和optional标记的组合代数替代加权打分，在 60 多个 Azure region、40 万个数据中心和超过 70 万次事故上把误报率从 18%–22% 降到 1% 以下，同时允许证据不足时拒绝归因。
问题与动机
大型云网络中的故障根因分析（RCA）面对的是持续存在的噪声，而不是干净的 fail-stop 故障。光模块退化、链路抖动、控制面重启和滚动升级会让许多设备同时呈现异常；Clos 的路径冗余又会把其中大部分故障隐藏在正常转发之下。客户事故发生时，异常实体不等于根因实体。
CoreSec 处理的是已经被外部检测器发现的、与某个客户服务相关的网络事故。它从 16 分钟的 telemetry 窗口中，综合 Pingmesh、NetBouncer、设备计数器、流量信号和基础设施健康信息，输出某条链路、TOR、T1、T2 或集群级根因。早期 Azure 系统把这些信号压成加权分数，再选择最高分实体；论文报告其误报率长期处于 18%–22%，且调权会把一种故障的改进换成另一种故障的退化。
论文的设计判断是：这里首先是证据组合问题，其次才是评分或分类问题。不同 agent 在覆盖范围、时延和故障类型上各有专长，系统应保留“证据不足或冲突”这一结果，而不是强行选出一个实体。
关键观察 / 隐含假设
- 观察 1：单个 telemetry agent 的可靠性依赖故障类型。 主动探测能快速发现链路故障，但可能漏掉软件缺陷；设备计数器能捕获硬件退化，却容易受瞬时噪声影响；流量信号更接近客户影响，但覆盖依赖流量量级（§2、§3）。
- 依赖假设：不同 agent 的错误模式足够互补，能够用角色标记表达“必须满足”“单独足够”或“仅作支持”。
- 可能失效场景：多个 agent 共享同一个上游采集故障，或新型故障同时绕过所有 agent 时，组合结构仍可能只能拒答，无法定位。
- 观察 2：故障在 Clos 层级上的传播形态可以区分局部组件与上层交换机。 单个 TOR 的影响通常局限在机架；T1 故障会使其 fan-out 中许多 TOR 同时退化。历史事故分析支持 T1 的
2/3fan-out 规则（§5.2）。- 依赖假设：拓扑连接关系稳定，且受影响 TOR 的比例比应用工作负载造成的局部相关性更有区分度。
- 可能失效场景：流量极不均衡、探测覆盖变化或拓扑重构时，业务影响可能集中在少量 TOR，使真实 T1 故障无法达到
2/3。
- 假设 1：拒答可以安全地当作 false negative。 CoreSec 将没有足够证据的结果计为 false negative，以换取避免错误归因触发错误隔离或缓解动作（§7–§8）。证据强度为强，因为论文明确记录了拒答原因、下游误触发缓解下降超过 80%，并说明拒答会把事故交给人工处理。
- 假设 2：历史故障模式能覆盖未来部署。 三个阈值和五组配置在多种 vendor、流量和硬件代际中不需逐集群重调（§8–§10）。证据强度为中：部署跨度很大，但论文没有公开事故样本、标签或盲测数据。
核心方法
CoreSec 为每个网络实体维护 healthy（H）、unhealthy（U）和 indeterminate（I）三态。agent 的新鲜数据先按自身阈值映射为通过、失败或拒答，再由四类控制标记组合：requisite 数据过期或失败时立即拒答；required agent 必须全部通过；sufficient agent 通过即可直接投票；optional agent 只在前述证据未给出决定时提供支持。数据超过 agent 的 freshness window 会被忽略，避免把延迟报告当成当前证据（§3）。
论文还给出了一个小型 merge operator：单个可信的 U 可以吸收其他状态；H 需要一致证据；冲突保留为 I。作者在附录 A 中证明该运算满足结合性，因此 agent 到达顺序、并行执行方式和异步更新不会改变组合结果。实际系统每 5 分钟重跑一次，直到 16 分钟窗口结束；低层归因可以被更高层充分证据替换，但不会反向降级。
五组配置分别面向 server–TOR cable、TOR、switch–switch cable、T1 和 T2。每组使用不同的 agent 角色，避免让同一套证据在所有层级拥有相同权重。随后通过拓扑启发式合并候选：TOR 需同时满足 P2.15 异常分位数和至少 20% 服务器受影响；T1 需有至少 2/3 fan-out TOR 不健康；集群级探测丢包率超过 4% 才触发广泛影响判断（§5）。当 T1 条件满足时，其下属 TOR 候选被抑制；彼此独立的不同层故障则保留。
系统刻意排除了会造成反馈环的下游 incident summary。早期版本把由 CoreSec 归因间接产生的健康汇总再次作为输入，导致新事故被旧归因偏置；这些信号平均晚到 18 分钟，也超过 16 分钟决策窗口（§5）。
设计取舍
- 拒答换取安全边界：缺失或冲突证据不会被迫压成一个分数，代价是部分事故必须交给 on-call。最近六个月拒答率仍为 1.5%，且 T1 故障在少于
2/3TOR 报告异常时会被漏掉。 - 确定性规则换取适应成本：配置、阈值和决策 trace 易于审计，不需要 runtime ML 重训；代价是新型故障需要人工发现模式并新增 agent，规则本身不能从未见过的故障中学习。
- 拓扑先验换取部署约束：层级抑制规则利用 Clos 的传播结构，能避免把上层故障拆成多个 TOR 故障；拓扑变化、非典型流量分布或探测覆盖不足时，规则的迁移性需要重新验证。
实验与结果
- 三年生产部署覆盖 60 多个 Azure region、400 个数据中心、数十万服务器和数千台交换机，处理超过 700,000 次网络事故（§8）。
- 相比此前的加权 RCA，误报率从 18%–22% 降至 1% 以下；论文称误报改善约 20 倍（§8、表 2）。
- 拒答率从部署初期的 10% 降至最近六个月的 1.5%，主要原因是补充了覆盖缺口的 agent，而不是重新调整三个阈值（§8、图 4）。作者把拒答按 false negative 计算。
- 约 99% 的事故在前两次重跑内稳定，典型归因在事故检测后 10 分钟内返回；论文称未观察到旧加权系统常见的归因振荡（§9）。
- 下游误触发缓解动作下降超过 80%，与错误归因相关的客户投诉下降 40%，人工 RCA 工作量相当于减少 3 个全职工程师（§7、§9）。
- 阈值敏感性分析显示，T1 fan-out 在 0.50–0.90 扫描时约 0.66 总误差最低；低于 0.60 增加误报，高于 0.75 增加漏报。集群丢包阈值低于 3% 易受瞬态不稳定影响，高于 5% 会漏掉客户可见影响，4% 位于折中区域（§9、图 5）。
论断—证据表
| 论断 | 证据 | 评测边界 | 置信度 |
|---|---|---|---|
| 结构化组合和显式拒答比旧加权 RCA 更少误报 | 18%–22% 降至 1% 以下（§8、表 2） | Azure 生产网络；对照为部署前系统 | 中 |
| 系统能在异步 telemetry 下稳定收敛 | 99% 在前两次重跑稳定；16 分钟窗口、5 分钟重跑（§6、§9） | 论文给出生产统计，但未公开 trace 分布 | 中 |
| 拓扑阈值跨部署泛化 | 10 个部署的阈值敏感性曲线；多 vendor 和硬件代际无需重调（§8–§10、图 5） | Azure Clos 变体；缺少公开数据集和盲测 | 中 |
| 拒答降低自动化误触发 | 误触发缓解下降超过 80%（§7） | 依赖下游运维流程和内部指标 | 中 |
批判性分析
论证链条
从“agent 专长按故障类型变化”到“用控制标记组合证据”这一链条是闭合的。附录 A 的结合性证明也确实支撑了异步到达下的顺序无关性。更大的跳步在于生产准确性：论文使用可见 CoreSec 输出的 on-call postmortem 作为 ground truth，没有盲测，因此人工标签可能受到系统建议影响。作者承认这一点，并提出对部署前事故回放和同集数据上的旧系统重跑进行补充验证，但当前文本未提供结果。
假设压力测试
2/3 fan-out 对真实 T1 故障的保护依赖故障影响面足够大。稀疏探测、业务热点或多路径流量变化都可能让真实影响比例低于阈值。4% 集群丢包阈值同样把“客户可见影响”绑定到特定探测体系；探测采样策略或业务 SLO 改变后，阈值不一定保持不变。
merge operator 的“U 吸收一切”带来安全偏置：一个被标记为 sufficient 的错误失败信号可能直接触发归因。论文依靠 agent 角色和阈值控制该风险，但没有给出各 agent 的独立精确率、相关错误率或 sufficient 信号的误触发分解。
实验可信度
生产规模、跨硬件部署和三年时间跨度足以说明系统有运维价值。阈值扫描也比只报告单点配置更有说服力。限制是基线只有上一代生产系统，没有与 007、NetBouncer 等方法在相同标签集上的公平比较；论文解释这些系统回答的问题不同，但仍缺少把“组合代数”和“拒答本身”拆开的对照实验。postmortem 标签未盲化，公开材料也没有每层级 Level 1–3 的混淆矩阵。
系统性缺陷
系统运行在已有 Azure 运维管线之上，新增 agent 仍需要识别新故障模式、配置 freshness window 和验证阈值。论文未量化 telemetry 拉取、存储和重复重跑的资源开销，也未讨论 agent 自身被攻陷或被系统性污染时的安全边界。大范围 telemetry 故障和数据中心级事故会故意产生 mass abstention，自动化隔离必须暂停并转人工；这是一项明确的运行约束，而不是异常情况。
局限与后续工作
- 局限 1：标签存在反馈偏差。 postmortem 作者可能看到 CoreSec 归因；需要对部署前事故做离线回放，并在同一标签集上重跑旧加权系统。
- 局限 2：新型故障依赖人工扩展。 可按故障类型统计持续拒答率，验证新增 agent 是否只降低目标类别拒答，而没有提高误报率。
- 局限 3：高层故障可能被保守阈值漏掉。 应按 T1 fan-out 规模、探测覆盖率和业务流量分布分层报告 false negative，而不是只报告总体拒答率。
- 后续工作 1： 将 agent 相关性和共享 telemetry 缺失纳入评测，测量“单点采集故障”对 sufficient/requisite 规则的影响。
- 后续工作 2： 让 LLM 或统计模型只负责上游信号提取，把最终组合留在可审计代数中，并比较该架构与 runtime ML RCA 的校准、延迟和拒答质量。