第三方供应商故障导致我方 P1，SLA 该不该全背？聊聊 SRE 责任边界最模糊的一角

背景

做了 5 年 SRE，复盘会上最尴尬、也最容易吵翻的一类事故，不是代码 bug，而是「供应商锅」：对象存储 5xx 风暴、短信通道全量失败、第三方风控 API 超时、甚至 DNS/CDN 厂商区域性抖动。这类故障的共同点是——根因不在我们的代码里，但用户的投诉、老板的问责、复盘文档上的 P1 等级，全压在我们头上。

去年我们经历过一次典型：核心支付链路依赖一家第三方风控服务，对方机房网络抖动 25 分钟，我方订单成功率从 99.9% 掉到 61%，最终定级 P1。复盘会上吵了半小时，焦点不是「怎么快速降级」，而是：这次事故的责任归属，到底算 SRE 的，还是采购的，还是接入方的产品？ 最后文档里写的是「第三方故障，改进项：加强监控告警 + 补充降级预案」，但每个人都心知肚明，改进项的 owner 被默认为我们。

常见的几种做法（我观察到的分歧）

1. 全背派：「用户感知到的是我们，SLA 是我们承诺的，不管根因在哪，恢复速度就是我们的责任。」——逻辑自洽，但团队会觉得「背了别人的锅还要写改进项」很憋屈，长期下来 on-call 士气会掉。
2. 切割派：「根因在供应商，我们只是受影响方，应该单独定级（比如 P2-external），不占我方故障率，改进项只写『推动供应商整改』。」——对团队友好，但一旦供应商跑路、或合同里没有 SLA 条款，公司承担的全部损失还是我们的。
3. 双层归因派：事故分两层记录——影响层归我方（用户损失、SLA 达成），根因层归供应商；改进项也分两层，我方负责「韧性」，采购/业务负责「合同与供应商管理」。——理论上最干净，但要求公司真的有跨部门的事故归因机制，大多数团队没有。
4. 合同先行派：认为这根本不该在复盘会上吵，应该在接入供应商之前就把 SLA、赔偿、降级义务写进合同，SRE 只负责技术兜底。——道理对，但现实是绝大多数接入是业务方先跑起来、SRE 后补。

我的倾向

我倾向双层归因，但前提是把它做成流程而不是话术。具体三点：

1. 定级时强制标注根因域：P1 之外再加一个 tag，比如 root_cause: vendor / root_cause: internal / root_cause: infra，复盘文档模板里这一栏必填。不是为了甩锅，是为了让「我方故障率」和「我方受外部影响率」两个指标分开看——否则 SRE 团队的稳定性大盘永远混着别人的噪声。
2. 改进项必须成对出现：每一个「供应商故障」类事故，必须同时产出两类改进项——一类是韧性项（降级、熔断、多活、缓存兜底，owner 是 SRE/研发），一类是商务项（SLA 条款、赔偿、供应商健康度评估，owner 是采购/业务负责人）。只写韧性项不写商务项的复盘，我一般打回去——因为「同样的供应商再挂一次，我们还会再背一次」，这才是真正的复发风险。
3. on-call 排班要区分「值守」和「兜底」：供应商故障期间，SRE 的 on-call 职责是执行预案，不是排查对方根因。这条要写进 on-call 手册，否则一线同学每次都会陷入「到底是我们的问题还是对方的问题」的排查内耗，黄金恢复时间被浪费。

想听大家

• 你们团队遇到第三方故障，定级是怎么定的？有没有 external 这种独立标签？
• 复盘改进项里，商务类改进项（合同、SLA、赔偿）你们真的会写进去并跟踪落地吗？还是默认「那是采购的事」？
• 如果供应商的 SLA 是 99.9%，但你们的业务 SLA 是 99.95%，这 0.05% 的 gap 谁来填？技术上填（冗余/多活）还是商务上填（赔偿）？
• 有没有遇到「供应商已经整改了，但我们的韧性改造拖了一年还没做完」的情况？这种改进项逾期，责任算谁的？

先抛出来，想听听不同规模团队（3 人小团队 vs 200 人 SRE 组织）在这件事上的差异，我猜差异会比「追责到人还是到流程」那个话题更剧烈。