供应商的 SLA 是承诺，你的可用性是结果。
一、供应商挂了你才发现
耿乐的产品用了九个外部服务：数据库托管、对象存储、邮件、支付、模型推理、错误聚合、DNS、CDN 与登录。
某个周二，邮件服务商开始间歇性 500。他没有告警，也没有备用通道；用户收不到密码重置邮件，工单在三个小时里涨到四十条。他直到看见工单才知道供应商出了问题。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
依赖故障会伪装成你的故障。 用户不会区分「你们的邮件发不出」和「你们的邮件商挂了」。
先建清单，再谈冗余。 不知道用了几个服务，就无法判断哪一个值得备一条后路。
九个依赖里，真正影响核心路径的可能只有三个。 先分清哪些挂了必须降级，哪些挂了可以等。
二、九个依赖与它们的故障表现
清单要写到「挂了之后用户看到什么」。
| 依赖 | 用途 | 挂了的表现 | 降级动作 |
|---|---|---|---|
| 数据库托管 | 主数据读写 | 全站不可用 | 切只读副本，写入排队 |
| 对象存储 | 上传与下载 | 上传失败、图片裂开 | 提示稍后重试，禁用上传 |
| 邮件 | 登录、重置、通知 | 无法登录、收不到通知 | 改用备用通道或站内提示 |
| 支付 | 收款与订阅 | 无法付款、续费失败 | 显示延后扣款说明 |
| 模型推理 | AI 功能 | 该功能报错或转圈 | 关闭该功能，保留主路径 |
| 错误聚合 | 排障 | 无（内部） | 退回本地日志 |
| DNS | 域名解析 | 全站不可用 | 无降级，只能等 |
| CDN | 静态资源 | 页面样式丢失 | 回源直出 |
| 登录服务 | 第三方登录 | 部分用户无法登录 | 保留邮箱密码登录 |
按用户可见性排序。 错误聚合挂了没人知道，DNS 挂了所有人都知道；维护精力应该反过来分配。
内部依赖也要列。 错误聚合、监控与日志服务挂了不影响用户，但会影响你排障；它们的降级动作是「退回本地」。
每个依赖都要写一句降级动作。 没写就等于没有；出事时现想，通常会选择最糟的方案。
降级动作要能在一分钟内执行。 需要改代码的降级等于没有降级；配置开关与备用通道才算数。
「等供应商恢复」也是一种动作。 但要配上公告与补偿口径，不能只是干等。
三、SLA 读数与真实影响
SLA 是月度承诺，影响是按分钟算的。
供应商 SLA 99.9% → 90 天允许 129.6 分钟不可用
近 90 天实测：3 次故障、累计 42 分钟 → 用掉额度的 32%
这 42 分钟全部计入你的停机（占 138 分钟的 30.4%）
停机收入敞口 = 1800 ÷ 43200 × 42 ≈ 1.75 美元
双供应商冗余成本 ≈ +35 美元/月 = 420 美元/年
回本所需事故次数 = 420 ÷ 1.75 = 240 次/年
42 分钟的收入损失只有 1.75 美元。 单看收入，冗余永远不划算；真正的损失在信任与退款，这部分无法用这个公式算。
但 240 次说明冗余不是默认答案。 对低频、可降级的依赖，写降级动作比买第二家更合理。
SLA 赔付通常不覆盖你的损失。 多数赔付是服务抵扣，且要主动申请；它补不了用户的退款。
要按月记录供应商的故障分钟。 没有记录，就无法判断是偶发还是趋势；也无法在续费谈判时拿出依据。
要把依赖故障单独记账。 与自因故障分开，才知道该改架构还是该换供应商。
额度要看季度，不只看月度。 一个月用掉 60% 额度，下个月再出一次就超了。
四、三层降级与一次演练
降级要分层，从最轻的开始。
| 层级 | 做法 | 用户可见 | 成本 |
|---|---|---|---|
| 一层 | 重试 + 超时 3 秒 + 指数退避 | 几乎无感 | 0 |
| 二层 | 关闭非核心功能，保留主路径 | 一个入口变灰 | 0 |
| 三层 | 切换到备用通道或只读模式 | 部分功能受限 | 0 到 35 美元/月 |
重试要有上限。 无限重试会把一个供应商的抖动放大成你自己的雪崩；三次退避通常够。
重试要区分幂等。 付款与发信不能盲目重试；先确认操作幂等，再加自动重试。
关闭功能要能远程控制。 一个配置开关，比重新发布一版快得多。
备用通道只在核心路径上准备。 邮件与支付值得备一条；错误聚合不值得。
每季度演练一次。 手动关掉邮件服务十分钟，看降级是否生效、公告是否发出；不演练的预案等于没有。
演练要选低峰期。 周三下午比周一上午安全；演练本身也是一次可控的故障。
演练要记录用户是否感知。 如果没人发现，说明降级做得好；如果有人来问，说明公告还需要补。
记录演练结果。 哪一步卡住、谁发现的、花了多久，都要写进下一次的改进项。
五、行动清单与复算验收
先把九个依赖列出来，再决定谁需要备用。
- 列出全部外部依赖，标注用途与是否核心。
- 为每个依赖写下「挂了用户看到什么」。
- 给每个核心依赖写一句降级动作。
- 记录近 90 天各供应商的故障分钟数。
- 用 129.6 分钟额度算出各家消耗比例。
- 为邮件与支付各准备一条备用通道或开关。
- 每季度演练一次核心依赖的降级。
- 把依赖故障与自因故障分开记账。
验收标准：核心依赖挂掉时，你能在五分钟内说出降级动作、用户会看到什么、公告怎么写；说不出，说明你的依赖还没有运维。
使用边界与实操验收
本文处理的是一人产品的第三方依赖管理，不涉及供应商合同与采购谈判。
合同与赔付不归本文。 SLA 条款、赔付流程与数据处理协议走合规口径，本文只算可用性。
多供应商不是默认答案。 冗余会带来双份配置、双份监控与迁移成本；先算清收益再决定。
别把降级写成「联系供应商」。 那是动作，不是降级；用户在你的产品里等不到供应商的回复。
依赖清单要定期更新。 新增一个 SDK 就多一个依赖；半年不清，清单会少一半。
演练不要通知用户。 真正的演练要接近真实故障；提前通知会掩盖沟通环节的问题。
关注供应商的变更公告。 大部分故障来自变更，不是硬件；订阅公告能提前一周知道。
关键参考与核验范围
核验日期：2026-10-25。以下链接用于核对依赖管理与降级的一般做法，本文未逐条引用其内容。
- Google SRE：处理过载 ：用于核对降级与配额的取舍。
- AWS：构建可容错的系统 ：用于核对超时、重试与退避的实现要点。
引用口径。 本文只借用「分层降级 + 定期演练」这一一般方法；九个依赖、42 分钟、1.75 美元与 35 美元全部是教学假设，与上述材料无关。
核验范围。 核验的是「依赖清单能否支撑一次降级决策」，不是比对某家供应商的 SLA 条款与赔付规则。
如何自行复核。 取最近一次依赖故障，看当时的降级是否生效、公告是否在 15 分钟内发出；两项都否定，说明预案还停在文档里。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。