3. 可靠性度量体系设计
可靠性治理的起点不是监控工具，而是业务目标。一个云原生平台如果只盯着 CPU、内存、Pod 重启次数，很容易陷入“指标全绿但用户仍在投诉”的困境。可靠性度量体系要解决的核心问题是：把模糊的“系统要稳定”翻译成可计算、可告警、可决策的量化契约。这条链路可以概括为：业务目标 → SLI 选择 → SLO 设定 → 错误预算计算 → 告警阈值联动。
一、从业务目标推导可靠性关注点
业务目标通常以用户可感知的方式表达，例如“下单请求 99% 在 300ms 内返回”“支付回调不丢失”“控制台登录可用”。设计度量体系时，第一步是把这些目标拆成两类：请求型目标（有明确请求与响应，如 API 调用）和资源型目标（关注持续可用或数据完整，如消息不丢、存储可读写）。请求型目标适合用“好事件数 / 总事件数”的比例来度量；资源型目标则常用“时间占比”或“数据完整率”来度量。区分这两类，决定了后续 SLI 的表达式形态。
二、SLI 选择：选“用户视角”而非“机器视角”
SLI（Service Level Indicator，服务等级指标）是 SLO 的度量基础。选择 SLI 时优先遵循“用户视角”原则：用户关心的是请求是否成功、是否够快，而不是某个中间件的线程池是否打满。常见的 SLI 类型包括：
- 可用性 SLI：成功请求数 / 总请求数，成功通常定义为 HTTP 非 5xx 且业务码正常。
- 延迟 SLI：在阈值内完成的请求数 / 总请求数，例如 P99 小于 300ms 的比例。
- 吞吐/质量 SLI：如消息投递成功率、数据写入完整率。
- 饱和度 SLI：如队列积压时长，用于预警而非直接作为 SLO。
选择时要避免“指标越多越好”。一个服务通常 2～4 个 SLI 即可覆盖核心体验。同时要明确统计口径：统计窗口（如 5 分钟、1 小时、28 天滚动）、请求过滤条件（是否排除健康检查、压测流量）、成功判定规则。口径不一致会导致 SLO 与告警互相矛盾。
三、SLO 设定：从“能做到”到“该做到”
SLO（Service Level Objective，服务等级目标）是 SLI 的目标值，例如“28 天滚动窗口内，下单接口可用性 ≥ 99.9%”。设定 SLO 不能拍脑袋，建议参考三个输入：历史实际达成水平、业务容忍度、成本约束。若历史可用性长期在 99.95%，直接定 99.99% 会带来巨大投入且难以达成；若业务明确要求 99.9%，则以此为准并倒推架构冗余。
SLO 还要区分内部目标与对外承诺。内部 SLO 可以更严格，用于提前预警；对外 SLA 通常略宽松，避免法律与赔付风险。此外，SLO 应绑定明确的统计窗口，滚动窗口比自然月更能反映持续状态。
四、错误预算计算：把“允许失败”量化
错误预算是 SLO 的衍生量，表示在统计窗口内允许的“坏事件”总量。计算公式为：
错误预算 = (1 - SLO) × 总事件数
错误预算消耗率 = 实际坏事件数 / 错误预算
剩余错误预算 = 1 - 消耗率举例（示例假设）：某下单接口 28 天滚动窗口内总请求数为 2,000,000，SLO 为 99.9%，则错误预算 = (1 - 0.999) × 2,000,000 = 2,000 个坏事件。若当前已产生 1,200 个坏事件，则消耗率 = 60%，剩余 40%。错误预算的意义在于把“可靠性”变成可消耗的资源：消耗过快说明稳定性在恶化，需要冻结变更、优先修复；消耗很慢则说明 SLO 可能过松，可考虑提升目标或加快迭代。
五、告警阈值联动：让告警跟随预算而非单点抖动
传统告警常基于瞬时阈值（如错误率 > 1% 持续 1 分钟），容易在流量波动时误报。更合理的做法是把告警与错误预算消耗速率联动，常见有两种：
- 燃尽率告警：计算单位时间内错误预算的消耗速度。若按 28 天窗口均匀消耗，燃尽率为 1；若 1 小时燃尽率超过 14.4，意味着按此速度 2 天内就会耗尽预算，应触发高优先级告警。
- 多窗口多燃尽率：同时观察短窗口（如 5 分钟）和长窗口（如 1 小时），短窗口快速燃尽触发紧急告警，长窗口缓慢燃尽触发工单级告警，减少噪声。
告警阈值应与 SLO 窗口、错误预算公式保持一致，避免“SLO 用 28 天、告警用 1 分钟”造成的口径割裂。告警触发后应能直接回答：当前消耗了多少预算、按此速度还能撑多久、是否需要回滚或扩容。
六、落地要点与常见误区
第一，SLI 口径必须写入文档并与采集实现对齐，例如“成功”是否包含业务降级返回。第二，SLO 不要一次定太多，先覆盖核心链路，再逐步扩展。第三，错误预算不是考核工具，而是决策工具：预算充足时鼓励发布，预算紧张时自动收紧变更。第四，告警要能回答“还剩多少预算、按当前速度还能撑多久”，而不是只报一个错误率数字。第五，定期复盘 SLO 达成情况，若长期远超目标，可评估提升 SLO 或放宽以换取迭代速度。