1. 可靠性工程概述：从MTBF到SLO的演进
1.1 可靠性度量指标的演进脉络
传统运维体系长期依赖 MTBF（Mean Time Between Failures，平均故障间隔时间） 和 MTTR（Mean Time To Repair，平均修复时间） 作为核心可靠性指标。这两个指标在硬件时代有效，但在云原生、微服务、持续交付的现代架构中暴露出明显局限：
- MTBF 无法反映用户真实体验——系统正常运行但响应缓慢，MTBF 仍为“正常”，用户却已流失。
- MTTR 忽略故障影响范围——一次影响 1% 用户的小故障与影响 100% 用户的大故障，MTTR 可能相同。
- 缺乏业务语义——MTBF/MTTR 是纯技术指标，无法与订单成功率、页面加载时间等业务目标对齐。
Google SRE 团队在《SRE 运维解密》中提出 SLO（Service Level Objective，服务等级目标） 作为新一代可靠性度量标准。SLO 将可靠性从“设备是否运行”转变为“用户是否满意”，并引入 误差预算（Error Budget） 作为风险决策的量化工具。
核心转变： 从“系统可用性 = 99.9%”到“用户请求成功率 ≥ 99.9%”，度量视角从基础设施转向最终用户体验。
1.2 从MTBF到SLO的对比分析
| 维度 | MTBF/MTTR 传统模式 | SLO/误差预算 现代模式 |
|---|---|---|
| 度量对象 | 硬件设备、单点组件 | 用户请求、端到端服务 |
| 数据来源 | 监控告警、工单系统 | 请求日志、分布式追踪、SLI 指标 |
| 业务对齐 | 弱，仅反映运维状态 | 强，直接映射用户体验与业务 KPI |
| 决策支持 | 被动响应，事后复盘 | 主动预算管理，事前风险控制 |
| 团队协作 | 运维与开发分离 | SRE 与产品共同承担可靠性责任 |
1.3 为什么需要误差预算
误差预算的核心逻辑：100% 可靠性不是目标，而是成本陷阱。追求极致可靠性会抑制发布速度、增加运维成本、降低创新效率。误差预算将可靠性目标转化为可消耗的“预算额度”，让团队在可靠性与迭代速度之间做出理性权衡。
误差预算公式： Error Budget = 1 - SLO（例如 SLO = 99.9%，则误差预算 = 0.1%）。在预算未耗尽时，团队可以安全地发布新功能；预算耗尽时，必须暂停发布并优先修复可靠性。
误差预算解决了三个关键问题：
- 量化风险容忍度——不再凭感觉判断“这次发布风险大不大”，而是用预算消耗率做客观依据。
- 打破“可靠性 vs 速度”的零和博弈——SRE 与产品团队共享同一本预算账本，共同决策。
- 建立告警与响应优先级——预算消耗速率超过阈值时触发告警，而非依赖静态的“系统宕机”告警。
1.4 课程目标与受众
本课程面向 SRE 工程师、DevOps 实践者、平台架构师、技术管理者，旨在帮助学员掌握从理论到工程落地的完整闭环：
| 目标维度 | 具体内容 | 交付成果 |
|---|---|---|
| 认知层 | 理解 SLO 与误差预算的数学原理、业务价值 | 能独立设计服务 SLO 指标体系 |
| 工程层 | 掌握误差预算台账的数据模型、采集管道、计算引擎 | 可落地一套误差预算台账系统 |
| 决策层 | 学会基于预算消耗率做发布决策、告警配置、容量规划 | 建立可靠性评审与风险控制流程 |
| 协作层 | 推动 SRE 与产品、研发团队共享预算账本 | 形成数据驱动的可靠性文化 |
前置要求： 学员需具备基本的监控系统使用经验（如 Prometheus、Grafana），了解微服务架构与 CI/CD 流程。本课程不涉及基础监控搭建，聚焦于 SLO 误差预算的工程化落地。
1.5 本章小结
- 可靠性度量已从 MTBF/MTTR 演进到 SLO + 误差预算，度量视角从基础设施转向用户体验。
- 误差预算的核心价值是 量化风险容忍度，让团队在可靠性与发布速度之间做出数据驱动的决策。
- 本课程将围绕 误差预算台账的工程落地，覆盖从 SLI 设计、数据采集、预算计算到决策输出的完整链路。