读 LLM serving 论文会撞见 “SLO attainment 90%“，翻云厂商合同会撞见 “99.9% 可用性承诺”，过容灾评审会被问”你们的 RTO、RPO 定了多少”。三套场景、三套黑话，很容易当成三个孤立知识点去背。把权威出处（Google SRE 书、NIST SP 800-34、AWS 容灾白皮书）对着读完之后，我的结论是：它们是钉在同一条故障时间轴上的三族刻度——SLI/SLO/SLA 量”平时允许坏多少”，MTTx 家族量”坏一次多快修好”，RPO/RTO/MTD 量”大灾之后丢多少数据、停多久业务”。而且三族有一个共同本质：它们都不是测量工具，是定价工具——把”多可靠才算够”这个花钱问题，翻译成能写进合同、能触发告警、能决定架构预算的数字。
先立骨架：一次故障的时间轴
把一次故障从头到尾摊开，几乎所有可靠性指标都能在这条轴上找到自己的位置：
flowchart LR
S["最后一次<br>数据快照"] -->|"RPO 量这段<br>往回：丢多少数据"| F["故障发生"]
F -->|"MTTD<br>多久被发现"| D["监控告警"]
D -->|"MTTA<br>多久有人接手"| A["开始处置"]
A -->|"修复中"| R["系统恢复"]
R -->|"WRT<br>校验与补数"| W["业务完全追平"]
F -.->|"RTO 量这段：停多久"| R
F -.->|"MTD 上限：业务最多忍多久"| W图上没出现的 SLI/SLO/SLA 和 MTBF 在哪？它们不量”单次故障”，量的是很多次故障在时间上的累积效果——所以挂在轴外，作为统计层罩着整条轴。
按”坏的程度”分，三族指标各管一个 regime：
| 族 | 管什么场景 | 核心问题 | 权威出处 |
|---|---|---|---|
| 承诺层（SLI/SLO/SLA/错误预算） | 日常运行的质量波动 | 平时允许坏多少？ | Google SRE 书第 4 章 |
| 事故层（MTTD/MTTA/MTTR/MTBF） | 单次故障的响应 | 这次坏了，多快发现、多快修好？ | 事故管理实践（Atlassian 指标手册等） |
| 灾难层（RPO/RTO/WRT/MTD） | 机房级、站点级灾难 | 大灾之后，数据丢多少、业务停多久？ | NIST SP 800-34 Rev.1 |
下面逐族拆。
第一族：承诺层——SLI、SLO、SLA 与错误预算
这一族的源头文本是 Google SRE 书第 4 章《Service Level Objectives》，四个概念是一条递进链：先选尺子（SLI），再定刻度（SLO），然后签合同（SLA），最后把没用完的容错额度变成零花钱（错误预算）。
SLI（Service Level Indicator，服务质量指标）：一个精心定义的量化测量值，回答”用什么尺子量服务质量”。典型形态是比率：好事件数 / 总事件数——比如”响应时间低于 300ms 的请求占比”。注意分位数陷阱：平均延迟会把长尾平均掉，所以生产实践普遍用 p99 这类分位数当 SLI，原因我在网关解剖篇里借 The Tail at Scale 讲过——尾部才是用户体验的决定项。
SLO（Service Level Objective，服务质量目标）：给 SLI 定的目标值或目标区间，比如”30 天窗口内 99.9% 的请求成功”。这是内部工程目标，不对外承诺。
SLA（Service Level Agreement，服务质量协议）：含违约后果的对外合同——达不到就赔钱、赔代金券。SRE 书特意划清界限：SLA 是商务产物，工程团队真正对齐的是 SLO，且 SLO 应该比 SLA 更严，中间留出安全垫。
错误预算（Error Budget）：1 − SLO 就是你被允许的失败额度。99.9% 的 SLO 意味着 0.1% 的预算。它的精妙之处在于把”可靠性 vs 迭代速度”的争吵变成了记账：预算还有余，就放心发版、做实验；预算烧穿了，就冻结发布专心还债。
几个 9 到底是多少时间（亲手算的）
口头说”三个 9""四个 9”很飘，换算成停机时长才有体感。下表是我用一行 Python 算的（按 365.25 天/年、30 天/月）：
| 可用性 | 每年最多停 | 每月（30 天）最多停 |
|---|---|---|
| 99%（两个 9） | 87.7 小时 | 432 分钟（7.2 小时） |
| 99.9%（三个 9） | 8.8 小时 | 43.2 分钟 |
| 99.99%（四个 9） | 52.6 分钟 | 4.3 分钟 |
| 99.999%（五个 9） | 5.3 分钟 | 26 秒 |
看清一个残酷事实：每加一个 9，允许的停机时间缩十倍。三个 9 时一次事故还能从容处理（预算 43 分钟）；四个 9 时人工响应已经来不及了（4.3 分钟里要完成发现、接手、修复），必须靠自动化止损；五个 9 基本宣告”任何依赖人的恢复流程都超预算”。
燃烧率：错误预算的实时监控
预算是月度总账，告警需要实时信号。SRE Workbook 第 5 章《Alerting on SLOs》给的工具是燃烧率（burn rate）：当前消耗预算的速度是”匀速烧完刚好用尽”的几倍。
拿 99.9%/30 天举例（数字我验算过）：燃烧率 14.4× 意味着 50 小时就会烧穿整月预算；持续 1 小时正好消耗月预算的 2%——这正是 Google 推荐的第一档告警线”1 小时烧掉 2%“。生产上最成熟的形态是多窗口多燃烧率告警：快窗口（1h，14.4×）抓突发，慢窗口（6h，6×）抓阴燃，再各配一个短窗口（5m/30m）保证故障结束后告警快速复位、压掉毛刺误报。
第二族：事故层——MTTx 全家
承诺层看统计，事故层看单次。这一族全是”平均时间”（Mean Time To/Between X），沿着时间轴依次是：
| 指标 | 全称 | 量哪一段 | 反映什么 |
|---|---|---|---|
| MTTD | Mean Time To Detect | 故障发生 → 被发现 | 监控覆盖质量（通常由系统自动完成） |
| MTTA | Mean Time To Acknowledge | 告警触发 → 有人开始处理 | 值班响应机制、告警疲劳程度 |
| MTTR | Mean Time To Repair/Recover/… | 故障发生（或接手）→ 恢复 | 修复能力、预案完备度 |
| MTBF | Mean Time Between Failures | 上次故障 → 下次故障 | 系统本身的可靠性（可修复系统） |
| MTTF | Mean Time To Failure | 投入使用 → 报废性失效 | 不可修复部件的寿命（硬盘、硬件） |
记忆口诀：MTTx 越小越好，MTBF/MTTF 越大越好。
一个必须知道的坑：MTTR 的 R 有四种解读——Repair（修复）、Recovery（恢复）、Respond（响应）、Resolve（彻底解决），四者起止点不同，数值可以差好几倍。跨团队对比 MTTR 之前先对齐定义，否则就是鸡同鸭讲。这不是我的洞察，是事故管理实践里反复强调的公开警告。
MTBF 与 MTTF 的分界在”修不修得好”：服务器进程崩了重启接着跑，用 MTBF；硬盘坏了只能换新，用 MTTF。软件系统基本都用 MTBF。
第三族：灾难层——RPO、RTO、WRT、MTD
前两族假设”系统还在，只是坏了”。灾难层假设站点没了——机房断电、区域故障、数据被误删。这族的权威出处是 NIST SP 800-34 Rev.1《联邦信息系统应急规划指南》，四个指标构成一个嵌套结构：
RPO（Recovery Point Objective，恢复点目标）：从故障点往回量——恢复后数据能退到哪个时间点，中间那段就是永久丢失。RPO 由备份/复制频率决定：每天备份一次，RPO 就是 24 小时；同步复制，RPO 趋近于零。它量的是数据，单位虽然是时间，本质是”丢多少活”。
RTO（Recovery Time Objective，恢复时间目标）：从故障点往前量——系统资源恢复可用之前，最多允许停多久。RTO 由恢复手段决定：冷备重建要天级，热备切换是分钟级。它量的是服务。
WRT（Work Recovery Time，工作恢复时间）：系统起来了不等于业务能跑——还要校验数据一致性、补录故障期间积压的工作、确认下游没有脏数据。这段收尾时间就是 WRT。
MTD（Maximum Tolerable Downtime，最大可容忍中断）：业务侧的硬上限——这个业务功能最多能消失多久而不造成不可接受的后果。NIST 明确它来自 BIA（业务影响分析），是业务决策不是技术决策。三者的约束关系（CISSP 体系里的经典公式）：
方向值得注意：MTD 从业务往技术倒推。先由业务定”最多忍 4 小时”，再倒推出 RTO 只能给 3 小时、WRT 留 1 小时，最后由 RTO 决定买哪档容灾架构——而不是反过来由技术能力定业务承诺。
RTO/RPO 的价目表：AWS 四档容灾策略
RTO/RPO 不是许愿——每压低一个数量级，架构成本上一个台阶。AWS 容灾白皮书的四档策略就是一张公开价目表：
| 档位 | 做法 | RPO 量级 | RTO 量级 | 成本 |
|---|---|---|---|---|
| Backup & Restore | 定期备份到异地，灾后重建 | 小时级 | ≤ 24 小时 | 最低 |
| Pilot Light | 核心数据持续复制，其余资源灾时才拉起 | 分钟级 | 小时级 | 低 |
| Warm Standby | 异地跑一套缩容版全功能环境，灾时扩容 | 秒级 | 分钟级 | 中 |
| Multi-site Active/Active | 多站点同时服务流量 | 趋近零 | 趋近零 | 最高 |
读法不是”选最好的”，是拿着 BIA 给的 MTD 找最便宜的够用档。非核心的内部工具用第一档就够；支付链路才值得上第四档。
三族怎么咬合：两个公式、一条预算线
三族不是并列的三张卡片，它们互相换算：
齿轮一：事故层折算成承诺层。经典可靠性工程公式（稳态可用性）：
几个 9 不是独立指标，是”坏得多不多”ד修得快不快”的商。验算：MTBF 1000 小时、MTTR 2 小时 → 1000/1002 = 99.80%。这个公式还揭示了提升路径的二选一：要么少坏（工程质量），要么快修（运维能力）——四个 9 之后，快修那条路必须交给自动化。
齿轮二：错误预算是承诺层发给事故层的月度零花钱。99.9%/30 天 = 43.2 分钟预算，一次事故的 MTTD + MTTA + 修复时间直接从里面扣。倒过来读：如果你的 MTTD 就要 20 分钟，三个 9 的 SLO 每月只够两次事故——监控投资和 SLO 承诺是同一笔账。
齿轮三：灾难层由业务定价、技术找零。BIA 定 MTD → 倒推 RTO/WRT → RTO 决定容灾档位 → 档位决定预算。SRE 书对 SLO 说过同样的话：选目标”不是纯技术活动”。三族指标的立法权都在业务手里，技术只有执行权。
LLM 工程视角：这套刻度正在被搬进推理系统
这套语言不是传统运维专属，它正在 LLM serving 里被原样复用、甚至升级：
SLO 从事后验收变成调度器输入。DistServe（arXiv 2401.09670）给 LLM 推理定义了双 SLO：TTFT（首 token 延迟）管 prefill、TPOT（每 token 间隔）管 decode，并把 goodput 定义为”满足 SLO 前提下每 GPU 能扛的最大请求率”——吞吐不再裸算，先过 SLO 这道门。论文报告 P/D 分离后可多服务 4.48× 请求或收紧 10.2× 的 SLO（来源数字，未亲手复现）。这比传统用法激进：传统 SRE 里 SLO 是月末对账的尺子，DistServe 里 SLO 进了调度循环，变成每个请求的实时约束。我在 Agent 云预测篇里拆过它的 P/D 分离，这次换 SLO 视角再看：P/D 分离本质上是”一个系统里有两个 SLO，就该拆成两个资源池”。
训练侧早就有 RPO/RTO，只是不叫这个名。这是我的映射（观点）：checkpoint 间隔就是训练作业的 RPO——训练崩了，最近一个 checkpoint 之后的算力全部作废；从 checkpoint 加载恢复的时间就是 RTO。千卡训练里”多久存一次 checkpoint”的权衡（存太频繁拖慢训练、太稀疏崩一次丢几小时 GPU 时）和”备份频率 vs 存储成本”是同构问题。
Agent 云缺的正是这一族指标的对应物。我在 Agent 云预测篇里押过一个低置信度预测：eval 会成为 Agent 云的类型系统。用本篇的语言重述：传统云的验收语言是 SLO（比率 + 延迟就能说清”好”），Agent 的”好”是语义正确性——没法用好事件/总事件的比率 SLI 表达。评测-路由篇讲的正是这个空位上正在生长的东西。
还有哪些：全家福总表
把本篇出现的和几个常见的近亲一次列全：
| 指标 | 回答的问题 | 单位/形态 | 谁来定 | 族 |
|---|---|---|---|---|
| SLI | 用什么尺子量质量 | 比率、分位数延迟 | 工程 | 承诺层 |
| SLO | 尺子上目标刻在哪 | 目标值（99.9%） | 工程+产品谈判 | 承诺层 |
| SLA | 违约赔什么 | 合同条款 | 商务 | 承诺层 |
| 错误预算 | 还能坏多少 | 1 − SLO 的余额 | 由 SLO 派生 | 承诺层 |
| 燃烧率 | 预算烧多快 | 倍数（14.4×） | 由 SLO 派生 | 承诺层 |
| MTTD / MTTA / MTTR | 发现/接手/修好要多久 | 平均时长 | 工程 | 事故层 |
| MTBF / MTTF | 多久坏一次 / 能活多久 | 平均时长 | 测量所得 | 事故层 |
| RPO | 丢多少数据 | 时间（往回量） | 业务(BIA)→备份频率 | 灾难层 |
| RTO | 服务停多久 | 时间（往前量） | 业务(BIA)→恢复架构 | 灾难层 |
| WRT / MTD | 业务追平还要多久 / 业务最多忍多久 | 时间 | 业务(BIA) | 灾难层 |
| 持久性 Durability | 数据会不会永久丢失 | 年度不丢概率（对象存储常宣传 11 个 9，厂商口径，未单独核实） | 存储设计 | 灾难层近亲 |
| Goodput | SLO 内能扛多少请求 | 请求率 | 工程（LLM serving） | 承诺层×容量 |
区分三个容易混的词：可用性（availability，现在能不能用）、可靠性（reliability，多久坏一次，对应 MTBF）、持久性（durability，数据会不会没）。一个服务可以可用性五个 9 但持久性糟糕（响应快但会丢数据），也可以反过来。
元规律：可靠性指标 = 给不可靠性标价
收束成一条能带走的规律：每个可靠性指标都是业务给”不可靠”开出的价格标签，指标每收紧一个数量级，架构成本上一个台阶。
证据摆在三族里：SLO 每加一个 9，停机预算缩十倍，人工响应到四个 9 就出局，只能加钱买自动化；RTO/RPO 每压一个数量级，AWS 价目表就往下翻一档更贵的架构；MTD 干脆由 BIA 从业务损失倒推——立法权从头到尾在业务手里。所以这些指标的正确用法从来不是”测出来多少”，而是”谈出来多少，然后用最便宜的架构刚好达标”。过度达标不是美德，是把钱烧在没人要求的 9 上。
这条规律和门禁篇的”不可逆边界”接得上：RPO 量的恰好是不可逆损失的窗口——备份点之后的数据没有 undo。门禁篇说不可逆性跃迁处要设门，本篇补上另一半：不可逆窗口的宽度，是可以用钱买窄的，RPO 就是那个标价。
诚实的提醒
分清本篇数字的三档证据：
- 亲手算过：几个 9 换算表、43.2 分钟月度预算、14.4× 燃烧率 1 小时 = 2% 预算、50 小时烧穿、MTBF 1000h/MTTR 2h → 99.80%，全部用一次性 Python 脚本验算。
- 核实过的来源：SLI/SLO/SLA/错误预算定义（Google SRE 书第 4 章）、MWMBR 告警参数（SRE Workbook 第 5 章）、MTD/RTO/RPO 定义（NIST SP 800-34 Rev.1 原文 PDF）、AWS 四档策略的 RPO/RTO 量级（AWS 白皮书）、DistServe 的 4.48×/10.2×（arXiv 2401.09670）——有出处但未亲手复现。
- 我的观点/映射：checkpoint 间隔 = 训练的 RPO；“eval 是 Agent 云的 SLO 空位”——是类比推演不是共识。
最低成本的亲手验证实验（5 分钟）：
WINDOW = 30*24*60 # 30 天 = 43200 个分钟窗口
SLO = 0.999
budget = WINDOW * (1 - SLO) # 错误预算：43.2 分钟
bad = 30 # 注入一次 30 分钟全挂故障
print(f"月度可用性 {1 - bad/WINDOW:.4%}") # 99.9306% —— 还没破三个 9
print(f"预算余额 {budget - bad:.1f} 分钟") # 13.2 分钟 —— 但本月只剩这些了
print(f"故障期间燃烧率 {1.0/(1-SLO):.0f}x") # 1000x —— 任何告警档位都会秒触发跑完你会获得三个体感：一次 30 分钟的事故并不破月度 SLO，但会吃掉 70% 预算；全挂时燃烧率是 1000×，快窗口告警几分钟内就该响；剩余 13.2 分钟意味着本月再来一次同级事故就违约。进阶版：把它扩成双窗口（1h+5m）AND 逻辑的 MWMBR 模拟器，亲眼看看短窗口如何在故障结束后把告警快速复位——那是 SRE Workbook 第 5 章的核心机制，30 行内能写完。
参考来源
工程实践
- Google SRE Book, Ch.4: Service Level Objectives——SLI/SLO/SLA/错误预算的源头定义
- Google SRE Workbook, Ch.5: Alerting on SLOs——燃烧率与多窗口多燃烧率告警
- NIST SP 800-34 Rev.1: Contingency Planning Guide——MTD/RTO/RPO 的官方定义与 BIA 流程
- AWS Whitepaper: Disaster Recovery Options in the Cloud——四档容灾策略价目表
- Atlassian: MTBF, MTTR, MTTA, and MTTF——事故指标家族与 MTTR 四义警告
- Atlassian: Reliability vs. Availability——稳态可用性公式
- TechTarget: Why maximum tolerable downtime is a key business metric——MTD = RTO + WRT 的业务侧读法
论文
- DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving（arXiv 2401.09670）——TTFT/TPOT 双 SLO 与 goodput 定义