系统里用了三家的服务：短信、对象存储、支付。三份合同都写着 99.9%，出事那天翻出来看，才发现三份都只赔月度费用的若干倍，而业务损失按小时计。合同没写错，是"治理"这件事从一开始就没做：没人定义过哪些依赖是关键路径，也没人算过它们失效时会发生什么。
外部依赖治理要回答的问题只有三个：哪些是关键路径、谁负责、失效时怎么办。三个问题都有明确答案时，SLA 才有意义；否则 SLA 只是一份用来安慰自己的文件。
1. 三个问题与它们的产物
| 问题 | 产物 | 没有产物的后果 |
|---|---|---|
| 哪些是关键路径 | 依赖分级清单 | 所有依赖同等对待，资源摊平 |
| 谁负责 | 每个依赖一个负责人 | 出事时所有人都在等别人 |
| 失效时怎么办 | 降级、备选、兜底方案 | 现场临时决策，通常选错 |
清单是基础，负责人是执行前提，方案是预案。三者顺序不能颠倒：没有分级就没有负责人，没有负责人就没人维护方案。
// 依赖登记：分级的依据是"失效时业务能否继续"，不是合同金额
dependency:
name: sms-gateway-a
class: channel // infrastructure / data / capability / channel
critical_path: true
owner: team-growth
failure_mode: 验证码发不出，注册与登录阻塞
fallback: 切换备用通道 + 语音验证码
exit_hours: 8 // 完全切走所需时间，这是锁定的真实判据
2. 四类依赖与替代难度
| 类型 | 例子 | 替代难度 | 主要成本 |
|---|---|---|---|
| 基础设施 | 云主机、对象存储、CDN | 低到中 | 数据迁移与 DNS 切换 |
| 数据 | 行情、风控名单、地理编码 | 高 | 口径不一致，结果不可比 |
| 能力 | 短信、支付、OCR、模型推理 | 中 | 接口适配与联调 |
| 渠道 | 应用商店、推送、社交登录 | 高 | 平台规则不由你定 |
数据类最难替换：换供应商不是换接口，而是换口径。同一个"风险分"在两家的定义不同，切换后业务指标会跳变，而团队往往把它误读成"效果变差"。
3. SLA 的读法：四个必须问清的点
| 维度 | 要问的问题 | 常见陷阱 |
|---|---|---|
| 可用性口径 | 按什么统计？请求数还是时间点？ | 按分钟采样，一分钟内的抖动被抹平 |
| 赔付上限 | 最多赔多少？ | 上限等于月度费用的若干倍 |
| 排除条款 | 哪些情况不算违约？ | 上游故障、计划维护、不可抗力几乎覆盖全部 |
| 测量权 | 谁的数据算数？ | 只有供应商自己的监控 |
第三项决定 SLA 的实际约束力。把"计划维护"和"上游依赖故障"排除之后，剩下的违约情形往往只有供应商自己机房着火这一类。
4. 赔付上限的实际意义
─── 算一遍就知道 SLA 赔的是什么 ───
月度费用 M
赔付上限 通常为 M 的 1 到 3 倍（按合同核对）
一次故障损失 按小时计的业务损失，通常远大于 M
结论 赔付覆盖的是"账单"，不是"损失"
所以 SLA 的正确用法不是"出事能拿回多少"，而是"用它来约束供应商的响应义务"：赔付金额本身很小，但违约记录会影响续约谈判与优先级。把 SLA 当成保险，会在第一次事故后就不再相信任何合同。
5. 单点供应商的三种对冲
| 手段 | 前置成本 | 见效时刻 | 适用 |
|---|---|---|---|
| 备选 | 中：接入第二家、维护双份适配 | 切换时才见效 | 关键路径、切换可自动化 |
| 降级 | 低：设计一条功能更弱的路径 | 立即 | 功能可裁剪 |
| 自建 | 高：人力与长期维护 | 长期 | 依赖是核心竞争力时 |
降级最容易被低估：短信发不出时改用语音验证码，或把注册流程改成"先密码后验证"，成本远低于接第二家短信通道。但降级方案必须提前设计并演练，否则事故现场没人敢改流程。
6. 切换能力要定期验证
写在文档里的备选方案等于没有。验证的最小形式是季度演练一次，只验证"能不能切"，不验证"切过去好不好用"：
─── 切换演练：只做可回滚的那一步 ───
1) 在预发环境把主通道权重降到 0，备用通道拉到 100
2) 跑一组固定用例：发送、查询状态、失败重试
3) 记录切换耗时与失败条数，与上次演练对比
4) 切回主通道，确认无残留配置
─── 判定标准：切换耗时不超过 exit_hours，用例全通过 ───
演练最常见的发现不是"切不过去"，而是"切过去之后没人知道怎么切回来"。所以演练必须包含回切，且回切由另一个人执行。
7. 锁定的判据是退出时长
| 判据 | 为什么不够 | 更好的判据 |
|---|---|---|
| 有没有导出功能 | 导出格式可能无法直接导入别家 | 导出后多久能被新系统消费 |
| 数据在不在自己手里 | 在，但结构与索引绑死了 | 换系统后重建索引需要多久 |
| 接口是否标准 | 标准接口也可能有私有扩展 | 去掉私有扩展后功能缺多少 |
把这三条合成一个数字：从决定换到新系统承载全量流量所需的小时数。这个数字超过可接受的中断窗口，就是被锁定了，无论合同怎么写。
─── 退出时长按环节拆，才知道卡在哪 ───
导出 4h // 数据量与导出速率决定
转换 12h // 字段映射与口径对齐，通常最慢
回灌 6h // 目标系统的写入速率
验证 8h // 抽样比对，不可省
合计 30h // 这才是"锁定"的真实含义
8. 合同里必须争取的四项
| 条款 | 内容 | 谈判时机 |
|---|---|---|
| 数据导出 | 格式、频率、是否收费 | 签约前，最容易拿到 |
| 终止后过渡期 | 停止服务后仍可用多久 | 签约前，常被忽略 |
| 变更通知 | 涨价、改接口的提前通知期 | 续约时 |
| 审计权 | 能否查看其可用性记录 | 大额合同时 |
第二项最关键：没有过渡期，终止合作等于当天断服。第三项决定了涨价是可预期的还是突袭——提前 30 天通知和提前 90 天通知，对排期的影响完全不同。
9. 供应商变更的早期信号
| 信号 | 含义 | 该做什么 |
|---|---|---|
| 涨价通知提前期变短 | 议价能力向你转移，对方不在意续约 | 启动备选评估 |
| 支持响应变慢 | 客户分层或团队缩减 | 记录工单时长，作为谈判材料 |
| 被收购 | 产品线可能被合并或停服 | 查收购方的产品重叠 |
| 文档更新停滞 | 维护投入下降 | 确认是否有替代路线图 |
| 新功能只在大客户版 | 分层策略成型 | 评估自己的档位是否还够用 |
这些信号都不构成"立刻迁移"的理由，但它们应该触发一次评估。等到停服公告发布时再评估，退出时长会从 30 小时变成 300 小时。
10. 多供应商不等于低风险
接两家是为了降低单点风险，但它同时引入了新风险：
─── 多供应商的成本结构 ───
适配层 两套接口、两套错误码、两套限流规则
一致性 两家的结果可能不同，需要定义"以谁为准"
运维 双份监控、双份告警、双份对账
决策 出事时选哪家，需要提前定规则
如果两家的切换从不演练、结果口径从不校准，那"双供应商"只是把复杂度翻倍，可靠性提升接近于零。判断标准很简单：上次真的靠备用供应商扛过流量，是什么时候。
11. 依赖清单与负责人登记
// 清单的维护成本要低，否则三个月后就没人更新
dependencies:
- name: sms-gateway-a
critical: true
owner: team-growth
backup: sms-gateway-b
last_drill: 2026-07-12
- name: geo-coding-api
critical: false
owner: team-search
backup: 本地缓存 + 降级为城市级精度
last_drill: null // 非关键路径允许为空，但要标出来
last_drill 为空是有信息的：它明确告诉你哪些依赖从未验证过切换。清单里最危险的不是"没有备选"，而是"有备选但从未试过"。
12. 度量
| 指标 | 看什么 | 参考方向 |
|---|---|---|
| 关键依赖数 | 标记为关键路径的依赖条数 | 应少而稳定，持续增长说明分级失效 |
| 单点依赖占比 | 无备选的关键依赖比例 | 应逐年下降 |
| 退出演练覆盖 | 有最近一次演练记录的关键依赖占比 | 应接近全量 |
| 变更响应时长 | 从收到变更通知到评估完成 | 应与通知提前期匹配 |
第一个指标的反向使用很重要：关键依赖数量持续增长，通常说明分级被滥用——所有依赖都被标成关键，等于没有分级。
13. 排错：治理落不下去的常见原因
| 现象 | 原因 | 处理 |
|---|---|---|
| 清单建了没人更新 | 维护成本高于收益 | 只登记关键路径，其余自动发现 |
| 备选方案从没切过 | 切换需要人工改代码 | 把切换做成配置项，先解决可切性 |
| 出事时找不到负责人 | 负责人写的是团队而非具体角色 | 写到角色，并在值班表里对应到人 |
| SLA 谈判没有筹码 | 没有可用性记录 | 自己侧也采一份，作为对照数据 |
| 迁移评估永远做不完 | 退出时长没拆环节 | 按导出、转换、回灌、验证四段估 |
14. 边界：什么时候不值得做完整治理
| 条件 | 治理程度 | 理由 |
|---|---|---|
| 非关键路径 | 只登记，不设备选 | 失效影响可接受 |
| 可当日替换 | 记录替换步骤即可 | 退出时长短，预案价值低 |
| 成本极低、影响面极小 | 不登记 | 治理成本高于风险 |
判断门槛用一句话：如果这个依赖明天消失，业务能否在一周内照常运行。能，就只登记；不能，就必须有负责人、有方案、有演练记录。三类边界之外的依赖，做完整治理是过度投入。
15. 自测
- 外部依赖治理的三个问题是什么？为什么顺序不能颠倒？
- 四类依赖里，为什么数据类最难替代？
- 读 SLA 时，"测量权"这一项为什么比赔付比例更重要？
- 赔付上限只等于月度费用若干倍，那么 SLA 的正确用法是什么？
- 判断是否被锁定的唯一数字是什么？它由哪几个环节相加而成？
- 关键依赖数量持续增长，通常说明分级出了什么问题？