可用性度量：三个 9 的代价表
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 6 · 高可用 · 第 34/49 篇 · 🚧 占位待学
上一篇：《Sentinel 实战：规则体系与生产落地》
下一篇：《冗余与故障转移：无状态与有状态的不同打法》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 6 · 单元 6.1
一、本文要解决的问题
老板说「我们要做到五个 9」——你知道那意味着一年只能停 5 分钟吗？可用性不是许愿，是数学：每个 9 都对应明确的停机预算、明确的投入量级。先学会算这笔账，再谈「高可用」三个字。
二、知识点清单
- 可用性公式：可用性 = 正常时间 ÷ 总时间；9 的预算表（99.9% = 8.76h/年，99.99% = 52.6min/年，99.999% = 5.26min/年）
- MTBF / MTTR：提升可用性的两条路（少出事 / 快恢复），而快恢复远比少出事便宜
- SLO / SLI / SLA 三件套：指标怎么选（成功率 / P99 / 数据新鲜度），目标与协议的关系
- 错误预算：预算内可以激进发布，预算耗尽只能冻结变更——稳定性的经济学
- 停机时间构成：故障发现 + 定位 + 决策 + 恢复，自动化每一段的收益
三、动手实验（学习时必须真跑）
- 给示例系统定义一组 SLI（接口成功率 / P99），用压测期间的错误统计算出「实验期可用性」
- 对一次人为故障（kill 数据库）做全程计时：发现 → 定位 → 恢复，分解 MTTR 各段占比
- 把 99.9% / 99.99% / 99.999% 的年停机预算换算成「允许几次什么级别的故障」，写一份代价表
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。