Appearance
SLO 与稳定性工程
定位：金融级稳定性方法论（1/6）。"系统要稳定"是口号，"放款成功率月度 SLO 99.95%、错误预算烧完就冻结发布"才是工程承诺。本篇写四件事。一是可用性每个 9 的代价曲线。二是 SLI 怎么从黄金信号推到业务指标。三是错误预算怎么与发布刹车联动。四是信贷场景为什么按"资损优先级"定级而不是只看可用性。同系列：容量账本见 容量规划与全链路压测，故障现场的三个动作见 应急预案三板斧-限流降级切流。故障的主动验证见 混沌工程与故障演练；指标采集的底层设施见 观测性三件套。
一、代价曲线：每个 9 都比上一个贵得多
| 可用性 | 年不可用 | 月不可用 | 达标需要的典型架构 | 边际代价 |
|---|---|---|---|---|
| 99%（2 个 9） | 3.65 天 | 7.3 小时 | 单机房，无冗余 | 低：正常开发 |
| 99.9%（3 个 9） | 8.76 小时 | 43.8 分钟 | 主备部署、人工切换 | 中：冗余资源 + 值班 |
| 99.99%（4 个 9） | 52.6 分钟 | 4.3 分钟 | 同城双活、切换自动化 | 高：全链路预案自动化 |
| 99.999%（5 个 9） | 5.3 分钟 | 26 秒 | 两地三中心/单元化多活 | 极高：组织级投入 |
成本
│ ____
│ ______/ 5个9
│ _____ / 单元化+多活+全自动化
│ ____ / 4个9 组织级投入
│ ____ / 3个9
│ ____ / 冗余资源+预案自动化
│ ____ / 2个9 主备+人工值班
│ _____ /
└───────────────────────────────────────────────────────► 可用性
曲线是指数的：3→4 个 9 只是把不可用时长压 10 倍，
但靠"人把备用系统拉起来"做不到分钟级恢复——必须自动化，
而预案自动化本身是最大的复杂度投资（见[复杂度治理](复杂度治理.md)）三个务实结论：
- 不要默认 4 个 9。按业务影响选：信贷核心资金链路（放款/扣款）值 4 个 9；账单查询 3 个 9；内部运营后台 2 个 9 足够。给所有系统统一拉高 SLO 是花钱买心理安慰。
- 均值达标 ≠ 稳定。99.99% 摊到全年是 52 分钟。一次 40 分钟的机房级故障就烧掉全年 77% 的预算。SLO 要按滚动窗口管理，不能年底算总账。
- 可用性买不来正确性。多活架构解决"服务了吗"，解决不了"做对了吗"——这是第四节按资损定级的根源。
反例：某系统年报"全年可用性 99.97%"，看着健康；拆开看是"前 11 个月 100%，12 月账单日连续故障 2 小时"。全年均值掩盖了故障集中度——信贷的流量与故障都是日历驱动的（大促与月结双峰，见 容量规划与全链路压测），平均值在这个行业尤其会骗人。
二、SLI 选取：从黄金信号推到业务指标
SLI 三条选取标准。用户视角：用户能感知的，不是机器视角的。比例型：好事件 / 总事件，可直接换算成预算。少数派：一个服务不超过 3 个 SLI——全是重点等于没有重点。
分层推导链：
技术 SLI（黄金信号，见[观测性三件套](观测性三件套.md)） 业务 SLI（金融真正考核的）
────────────────────────────────────── ─────────────────────────────────
延迟：放款接口 P99 < 800ms ──┐
错误：网关 5xx 比例 < 0.1% ──┼──► 放款成功率 ≥ 99.95%（按笔）
流量：QPS（用于容量规划，不作 SLI） ──┤ 账单日扣款成功率 ≥ 99.9%
饱和度：DB 连接池水位（用于告警） ──┘ 对账差错笔数 = 0（正确性 SLI）关键认知：技术 SLI 是手段，业务 SLI 是目的。网关 5xx 率 0.05% 全绿，但失败的那部分全是放款单——业务 SLI 直接打红。反过来，业务 SLI 告警了，要靠技术指标 + trace 定位（见 问题定位步骤）。
| 层 | SLI 例子 | 回答的问题 | 典型反例 |
|---|---|---|---|
| 正确性 | 对账差错笔数、利息计算误差笔数 | 做对了吗 | 完全不设——金融系统最大的盲区 |
| 业务 | 放款/扣款/额度查询成功率 | 用户拿到服务了吗 | 拿"进程存活"当 SLI（活着但全超时） |
| 技术 | P99 延迟、5xx 率、依赖超时率 | 问题在哪一层 | 拿 CPU 使用率当 SLI（是原因不是结果） |
再补一个穿透反例：把 SLI 定在"入口网关成功率"，核心服务超时被网关的静态兜底页遮住。SLI 常绿，用户什么业务都办不成。SLI 必须穿透到业务语义层。静态兜底算不算成功，要按业务语义定义清楚。
三、错误预算：把"多稳定"变成一本账
错误预算 = 1 - SLO
月度 SLO 99.95% → 月预算 = 43800 分钟 × 0.05% ≈ 21.9 分钟
预算消耗 = 故障时长（不可用口径） + 灰度期降级（把用户体验受损也算进来）错误预算的意义：在"全力求稳"和"快速迭代"之间给出可计算的折中——预算就是创新配额。没有预算机制的团队只剩两个坏选项：要么"任何变更三层审批"（慢死），要么"先上了再说"（事故死）。
预算与发布刹车联动（SLO 落地的关键，不联动就是报表装饰）：
| 预算剩余 | 发布策略 |
|---|---|
| > 30% | 正常节奏、正常灰度 |
| 10% ~ 30% | 只放低风险变更，灰度档位加密（1% → 2% → 5%），观察时长翻倍 |
| 0 ~ 10% | 冻结功能发布，只允许稳定性修复 |
| < 0（超支） | 全量冻结 + 强制复盘，超支部分从下月预算扣 |
消耗速度告警（burn rate）：不等预算烧完才反应。"1 小时烧掉月预算 2%"立刻电话告警，"6 小时烧掉 5%"工单告警。发现能力取决于监控告警体系的设计，见 观测性三件套 的报警四问。
两个反例：
- 预算只算故障不算灰度：大促前一周连续发布，每次引入 0.1% 的静态兜底，单次都不超阈值。用户体验实质降级，预算却显示"充足"。灰度降级必须折算进预算。
- 预算烧完但大促在即，业务方施压"这个功能必须上"。正确做法不是默默破例，而是走风险评审。要么书面确认临时下调该窗口 SLO 并明确责任，要么把变更挪到预算恢复后。预算制度被撕开口子一次，制度就死了。
四、金融场景：资损优先级定级，而非仅可用性
可用性回答：服务了吗？ ──► 99.99%，全绿
正确性回答：做对了吗？ ──► 失败的 0.01% 里，有 300 笔重复放款
每笔都是真金白银 + 客诉 + 监管问询信贷场景的三条特殊性：
- 错误不可逆。少扣一次款可以补扣。多放一笔款、一批账单利息算错，追溯成本远高于故障本身。
- 故障反而是"好的"失败方式。系统拒绝/超时，用户重试即可，无损失。系统"降级返回一个猜的额度"，就是资损。所以金融降级的默认方向是安全侧（拒绝或走保守策略），不是"给个兜底值"。详见 应急预案三板斧 的降级一节。
- 监管与声誉放大。批量错账的影响半径超出技术团队。涉及报送与处罚，公关时间远长于故障时间。
资损优先级定级表（简化版）：
| 级别 | 定义 | 信贷例子 | 响应要求 |
|---|---|---|---|
| P1 资损/数据错乱 | 错钱、错账、批量数据错误 | 重复放款、利息多算、额度超卖 | 立即拉全员，止血优先于定位，评估监管报送 |
| P2 核心不可用 | 放款/还款链路整体不可用 | 账单日扣款超时率 90% | 按 1-5-10 应急响应（见三板斧篇） |
| P3 局部可用性 | 非核心功能降级/变慢 | 账单导出超时、营销页错误 | 当日修复，值班处理 |
| P4 无感故障 | 冗余层故障，用户无感 | 单实例异常被自动摘除 | 排期修复 |
定级三要素：影响金额（笔数 × 单笔）、影响客户数、是否可逆。注意 P1 与 P2 可能并存且互相转化。机房故障导致扣款全超时（P2），恢复后消息重放又造成重复扣款（升级为 P1）。定级是动态的，随事态演进而升降。
对账是正确性 SLI 的最后防线：T+1 对账差错笔数必须为 0。这是唯一能兜住"静默资损"（系统不返回错误但做错了）的指标。宁可放款链路 3 个 9 + 对账零差错，不要放款 4 个 9 + 对账形同虚设。
五、SLO 落盘：服务分级与 SLO 目录
SLO 不是每个服务一份大而全的文档，而是一张全公司统一的目录，按服务分级分配预算与保障：
| 服务 | 等级 | 核心 SLO（月度） | 预算联动 | DRI |
|---|---|---|---|---|
| 放款核心 | S0 资金链路 | 放款成功率 ≥ 99.95%；对账差错 = 0 | 烧完即冻结发布 | 资金域架构师 |
| 账单日扣款 | S0 资金链路 | 扣款成功率 ≥ 99.9% | 同上 | 账单域架构师 |
| 额度/账单查询 | S1 高流量 | 成功率 ≥ 99.9% | 联动灰度档位 | 服务 owner |
| 营销/推荐 | S2 非核心 | 成功率 ≥ 99.5% | 仅告警，不刹车 | 服务 owner |
| 内部运营后台 | S3 | 工作时段可用 ≥ 99% | 不做预算管理 | 服务 owner |
分级有三重价值。资源分配：S0 享受双活与 1-5-10 保障，S3 不进应急体系（见 应急预案三板斧）。预期管理：S2 的营销页抖动不该触发 P2 响应。以及预算的价格差——S0 的 1% 预算比 S3 的 1% 预算贵得多，别用同一把尺子考核。
反例：SLO 目录建好后再没人动过——业务早已把某个查询服务变成还款必经链路（事实上的 S0），目录里它还是 S2，预算与保障全错位。SLO 目录要跟着业务重要性走，而业务重要性会变。
六、运营节奏：这本账谁在什么时候看
| 节奏 | 动作 | 谁参加 |
|---|---|---|
| 日常（值班） | burn rate 告警响应，按预案止血 | 值班 oncall |
| 周会 | 过本周预算消耗 Top3 服务，异常消耗归因 | 各域稳定性接口人 |
| 月度 | 错误预算复盘：烧在哪、哪些变更贡献了消耗、下月刹车策略 | 架构师 + 质量团队 |
| 季度 | SLO 目录修订：随业务重要性升降级（升 S0 要同步配资源） | 技术决策会（见 技术决策与ADR） |
追问链
老板问："把可用性从 3 个 9 提到 4 个 9，要花多少钱？"
先反问值不值：当前月度不可用的 43 分钟里，有多少落在核心资金链路？如果故障大头在内部后台，钱应该花在核心链路的预案自动化上，而不是全网统一升 9。SLO 按服务定，不按公司定。
SLO 定 99.9% 还是 99.95%，怎么科学地定？
回看历史 + 业务折算：过去 12 个月真实可用性多少、每次故障折算的业务损失多少。把 SLO 定在"当前水平 + 略需努力"的位置，并约定预算有富余时用于发布提速。定 100% 等于禁发布，定得过低等于没有质量约束。SLO 是双方谈判的结果，不是技术团队单方面的承诺。
为什么金融 SLI 要加"对账差错 = 0"这种绝对指标？
比例型 SLI 衡量可用性，正确性必须用绝对值：0.01% 的错账率乘上亿级交易量就是上千笔资损。可用性指标天然容忍失败，正确性指标必须零容忍——这是金融与普通互联网服务在 SLI 上的分水岭。
错误预算到底是谁的预算？开发的不敢发，业务的不让冻。
预算属于 SLO 承诺的受益方（业务），执行权在稳定性接口人。这正是需要月度复盘对齐的原因。业务方在"发布提速"和"稳定性"之间做权衡并签字，技术方提供消耗数据与风险量化。把预算当技术团队单方面的武器，或当业务方单方面的紧箍咒，都运营不下去。
一句话总结
SLO 把"稳定"翻译成三个可运营的物件：一条业务化的 SLI、一本错误预算账、一套与发布联动的刹车。 而在信贷场景，账本之上还要加盖一层"资损优先"的定级。可用性度量"服务了吗"，正确性度量"做对了吗"，后者永远排前面。
2026-10 新增（金融级稳定性方法论系列）。