本文以《SRE Google 运维解密》阅读笔记为选题起点，结合 Google 当前公开的 SRE Book 重写。原文覆盖监控、容量、过载和重试；这里进一步把这些手段放进一条可执行的可靠性闭环。
SRE 不是“再装一套 Prometheus 和 Grafana”，也不是把所有基础设施指标都设成告警。真正的起点是一个产品问题：用户依赖的服务行为是什么，我们准备把它做到多可靠？
只有先回答这个问题，监控、扩容、限流和故障处理才有共同目标。
SLI、SLO 和 SLA 分别是什么
| 概念 | 要回答的问题 | 示例 |
|---|---|---|
| SLI | 实际服务表现怎样 | 成功请求比例、延迟达标比例 |
| SLO | 我们希望达到什么目标 | 30 天内 99.9% 请求成功 |
| SLA | 未达到承诺会有什么后果 | 退款、赔偿或合同责任 |
SLO 是内部可靠性目标，不一定写进合同。它的价值是让产品、研发和运维可以围绕同一条数据做决策，而不是一方要求“绝不能出故障”，另一方只说“CPU 看起来正常”。
从用户旅程反推 SLI
不要先翻指标列表。先列出最关键的用户旅程，例如：
- 用户能够登录；
- 用户能够创建订单；
- 支付结果最终能回写订单；
- 商家能在承诺时间内看到结算数据。
然后为每条旅程定义“好事件”和“总事件”：
可用性 SLI = 好事件数量 / 符合条件的总事件数量
例如订单创建接口可以定义为：
好事件：非调用方错误，并在 800 ms 内返回成功的请求
总事件：进入服务且通过基础参数校验的创建订单请求
定义中必须说清楚：
- 在客户端、网关还是服务端测量；
- 哪些状态码属于服务失败；
- 主动取消和无效参数是否进入分母；
- 延迟从哪里开始、到哪里结束；
- 统计窗口和地区范围是什么。
如果只测服务端 HTTP 200，页面 JavaScript 崩溃、网关超时或错误业务结果都可能被漏掉。SLI 应尽量贴近用户真正感知的结果。
延迟不要只看平均值
平均延迟很容易掩盖长尾。100 个请求中 99 个耗时 20 ms，一个耗时 10 秒，平均值仍可能看起来不算离谱，但那个用户已经失败。
更实用的表达是“延迟达标事件比例”：
99% 的读取请求在 300 ms 内完成
95% 的批量导出任务在 10 分钟内完成
不同工作负载应分开定义。交互请求关心尾延迟，批处理更关心完成时限和吞吐，数据系统还可能关心新鲜度与正确性。
错误预算把可靠性变成资源
如果 30 天可用性 SLO 是 99.9%，允许的失败比例就是 0.1%。按纯时间粗略换算，约为 43.2 分钟；按请求事件统计时，则是总请求量的 0.1%。
错误预算 = 1 - SLO
预算消耗率 = 实际坏事件比例 / 允许坏事件比例
错误预算不是鼓励故障，而是承认 100% 可靠既不现实，也可能昂贵到阻碍迭代。团队可以约定：
- 预算充足时，正常发布功能；
- 预算消耗过快时，暂停高风险变更并处理可靠性问题；
- 预算耗尽时，只允许修复、回滚和已审批的紧急发布；
- 长期几乎不消耗预算时，检查目标是否过松，或系统是否过度建设。
这种规则必须在故障发生前约定。否则“要不要继续发布”仍会变成临时争论。
告警应该表示需要行动
CPU 80%、磁盘 70% 或线程数增加都可以作为诊断信息，但不一定值得半夜叫醒人。分页告警至少要满足：
- 用户正在受影响，或错误预算正在以不可接受的速度消耗；
- 值班人员现在采取行动能改善结果；
- 告警中有服务、范围、现象和操作入口。
可以用多窗口预算消耗率降低误报：短窗口识别快速事故，长窗口确认影响持续存在。具体阈值应根据 SLO、值班能力和历史事故调校，不应把网上的一组数字直接复制到所有服务。
基础设施指标仍然重要，但更适合作为原因候选：
- 延迟：用户等了多久；
- 流量：系统承受多少需求；
- 错误：结果失败或错误的比例；
- 饱和度：CPU、内存、队列、连接池还剩多少余量。
前面三项更接近用户，饱和度帮助预测和定位。
过载保护比事故后扩容更早一步
系统接近容量边界时，排队、超时和重试会互相放大。应在设计时明确：
- 哪一层限制并发与队列长度；
- 什么请求可以拒绝、降级或延后；
- 客户端是否设置总 deadline；
- 重试次数、退避和随机抖动如何配置；
- 同一调用链的重试由哪一层负责；
- 扩容需要多久，在扩容完成前如何保护系统。
无限队列通常只会把快速失败变成长时间超时。重试也不是免费的恢复手段：如果每一层都重试三次，调用链会产生倍增流量。应由最接近用户、又能判断幂等性的一层控制重试，并把剩余 deadline 向下游传递。
一条可运行的最小闭环
小团队可以从一条关键旅程开始：
- 定义用户视角的 SLI；
- 选择一个暂时可达到、但不是照抄当前表现的 SLO；
- 建立 30 天滚动窗口和错误预算面板；
- 为快速和慢速预算消耗配置告警；
- 给告警附上 dashboard、日志查询和 runbook；
- 故障时记录时间线、影响和缓解动作；
- 复盘后优先消除重复人工操作和放大机制；
- 每季度检查 SLI 是否仍代表真实用户体验。
不要一开始给几十个服务都定 SLO。先让一条关键链路真正影响发布和优先级，再复制模板。
SLO 评审模板
用户旅程：
SLI 定义：
测量位置：
好事件：
总事件：
目标与窗口：
排除项及理由：
错误预算政策：
快速消耗告警：
慢速消耗告警：
负责人和 runbook：
一个 SLO 如果没有明确测量方式、负责人和预算政策，就还只是愿望。