3. 稳定性度量体系设计

稳定性治理最容易陷入的误区，是“凭感觉判断系统稳不稳”。要把它变成可管理、可考核、可优化的工程问题，第一步就是建立一套度量体系。这套体系的核心是三个概念：SLI（Service Level Indicator，服务等级指标）、SLO（Service Level Objective，服务等级目标）、SLA（Service Level Agreement，服务等级协议），再叠加错误预算（Error Budget）作为“可消耗的容错额度”。

一、SLI、SLO、SLA 的定位与区别

三者是层层递进的关系，而不是同义词。

• SLI 是“测量值”：从监控系统里真实采集到的量化指标，例如“过去 5 分钟请求成功率 = 99.95%”“P99 延迟 = 320ms”。它回答“现在到底怎么样”。
• SLO 是“目标值”：团队对某个 SLI 设定的内部期望，例如“30 天滚动窗口内成功率 ≥ 99.9%”。它回答“我们希望达到什么水平”。
• SLA 是“对外承诺”：写进合同、带赔偿条款的协议，例如“月度可用性低于 99.9% 则赔付 10% 服务费”。它回答“我们对客户承诺什么，违约怎么办”。

关键原则是：SLA 必须比 SLO 宽松。内部目标定得比对外承诺更严格，才能留出缓冲。如果 SLO 是 99.95%，SLA 通常定在 99.9%，这样即使内部目标短暂未达成，也不会立刻触发对外赔付。

二、可用性计算：从“几个 9”到真实公式

可用性最常用的表达是“几个 9”，但工程上必须落到公式。以最常见的请求成功率型 SLI 为例：

可用性 = 成功请求数 / 总请求数 × 100%
       = (总请求数 - 失败请求数) / 总请求数 × 100%

示例（30 天窗口）：
总请求数   = 100,000,000
失败请求数 = 50,000
可用性     = (100,000,000 - 50,000) / 100,000,000
           = 99.95%

“几个 9”对应的月度不可用时间（按 30 天 = 43,200 分钟计）如下表，这是判断目标是否合理的重要参照：

注意：这里的“不可用时间”是按失败请求比例折算的等效时间，不是“系统完全宕机的时间”。一个系统可能一直在线，但错误率偏高，同样会消耗可用性额度。

三、错误预算：把稳定性变成可消耗的资源

错误预算是 SLO 的“另一面”。如果 SLO 是 99.9%，那么允许的失败比例就是 0.1%，这就是错误预算。

错误预算 = 1 - SLO
         = 1 - 99.9% = 0.1%

以 30 天、1 亿请求为例：
允许失败请求数 = 100,000,000 × 0.1% = 100,000 次
等效允许不可用时间 ≈ 43.2 分钟

错误预算的工程价值在于它把“稳定”和“迭代”统一到一个决策框架里：

• 预算充足：可以加快发布节奏、做风险较高的变更、开展混沌演练。
• 预算消耗过快：触发预警，冻结非必要变更，优先做稳定性修复。
• 预算耗尽：暂停功能发布，集中资源恢复稳定性，直到预算回补。

这样，稳定性就不再是“和业务对立的刹车”，而是有额度、可协商的工程资源。

四、监控指标选型：选对 SLI 比定高 SLO 更重要

SLI 选错，SLO 再漂亮也没有意义。选型时建议遵循三条原则：

1. 面向用户可感知：优先选用户真正能感受到的指标，如请求成功率、端到端延迟，而不是 CPU 使用率这类内部资源指标。
2. 可测量、可聚合：能从现有监控（如 Prometheus、日志、链路追踪）稳定采集，且能按时间窗口聚合。
3. 数量克制：一个服务通常 3～5 个 SLI 足够，覆盖“可用性、延迟、正确性、饱和度”几个维度即可，避免指标泛滥。

常见的 SLI 类型与选型建议：

对于数据平台，尤其要重视“数据时效性”和“数据正确性”类 SLI。例如离线任务可以用“T+1 数据在每日 08:00 前产出率”作为 SLI，SLO 设为 99%，这比单纯看任务成功率更贴近业务价值。

五、度量体系落地闭环

把上述概念串起来，就形成一条从采集到决策的闭环：SLI 采集 → SLO 判定 → 错误预算消耗 → 预警与变更管控 → 复盘与目标调整。下图展示了这一体系的核心结构与数据流向。

图中可以看到，SLA 位于体系最外层，是比 SLO 更宽松的对外承诺；而错误预算是连接“目标”与“日常决策”的枢纽。真正让度量体系产生价值的，不是把 SLO 写得多高，而是让错误预算真正参与发布、变更和复盘的决策。建议从一两个核心服务开始试点，跑通一个完整的月度周期，再逐步推广到更多服务。