SRE（Site Reliability Engineering，站点可靠性工程）不是把运维换个名字，而是用软件工程的方法解决运维问题，并把「可靠性」变成可以度量、可以交易、可以持续改进的工程目标。

本文按五个主题展开：SRE 的边界、SLI/SLO/SLA 与错误预算、Toil 治理、事故响应与 On-call、无指责复盘与故障档案库。

• 什么是 SRE：与 DevOps、传统运维的边界
• SLI / SLO / SLA 与错误预算
• Toil 识别与消除
• 事故响应流程与 On-call 值班
• 无指责复盘与故障档案库
• 快速落地检查清单

什么是 SRE：与 DevOps、传统运维的边界

一句话定义

Google 对 SRE 的经典定义是：

SRE is what happens when you ask a software engineer to design an operations team.

也就是：让软件工程师来设计并运行运维体系。SRE 把运维问题当成软件问题来处理，用代码、自动化、度量和工程决策替代长期的人肉操作。

SRE 的核心不是「更辛苦地值班」，而是：

• 用 SLI/SLO 定义什么叫「可靠」。
• 用 错误预算 在「发布速度」和「稳定性」之间做理性取舍。
• 用 Toil 治理 把重复劳动转化为自动化。
• 用 事故响应和复盘 把故障转化为组织能力。
• 用 容量规划、变更管理、可观测性 提前降低风险。

SRE 关注什么

与传统运维的边界

传统运维并非「落后」，它在稳定、可控、强审计的环境中仍然有价值。SRE 的改变在于：把可靠性从「感觉」变成「指标」，把运维从「人力」变成「工程」。

与 DevOps 的边界

DevOps 是一场文化和组织运动，强调开发与运维协作、持续交付、自动化和反馈闭环。SRE 是 DevOps 原则的一种具体实现方式。

可以这样理解：

• DevOps 是理念：打破开发与运维的墙，谁构建谁运行，快速反馈，持续改进。
• SRE 是实践：用 SLO、错误预算、Toil 预算、On-call、无指责复盘等具体机制落地这些理念。
• Google 的说法是：class SRE implements DevOps。

两者不是二选一。一个组织可以实践 DevOps 但没有 SRE 团队；也可以有 SRE 团队但 DevOps 文化不成熟。最理想的状态是：DevOps 提供文化和交付基础，SRE 提供可靠性治理机制。

SRE 不是什么

• 不是「运维团队改名」：如果工作内容还是手工工单、重启服务、盯监控，那只是换了名片。
• 不是追求 100% 可用性：100% 既做不到，也不经济；SRE 追求「在成本约束下满足业务目标的可靠性」。
• 不是只负责 Kubernetes：容器编排只是基础设施之一，SRE 关注的是端到端服务可靠性。
• 不是消防队：长期救火说明系统设计和流程有问题，SRE 要把救火变成工程改进。
• 不是研发的「背锅侠」：可靠性是研发、运维、产品、业务共同的责任。
• 不是所有团队都必须一样：SRE 的落地形态取决于组织规模、业务阶段和风险承受能力。

SRE 的组织形态

无论哪种形态，都要避免两个极端：

• SRE 变成「高级运维」，只接工单不写代码。
• SRE 变成「纯咨询」，没有权限、没有责任、没有落地能力。

SRE 成熟度参考模型

SRE 的十条工作原则

1. 可靠性是功能：像做产品一样做可靠性，有目标、有优先级、有投入。
2. 用 SLO 说话：没有度量就没有改进，没有目标就没有取舍。
3. 错误预算是决策工具：不是惩罚工具，而是发布与稳定之间的调节器。
4. 自动化优先：能自动化的重复劳动，不要长期占用人。
5. 减少 Toil：Toil 超过一定比例，SRE 就没有时间做工程。
6. 变更可控：灰度、回滚、特性开关、发布检查清单。
7. 故障是学习机会：无指责复盘，关注系统和流程，而不是找替罪羊。
8. 可观测性先行：指标、日志、追踪、事件、部署标记要能关联。
9. 容量与成本并重：可靠性不是无限堆资源，要考虑单位成本。
10. 可持续 On-call：值班不能靠英雄主义，要靠流程、工具和轮换。

SRE 落地路线图

SLI / SLO / SLA 与错误预算

三个概念的关系

关系可以概括为：

SLI 是测量值
SLO 是内部目标
SLA 是对外合同
错误预算 = 1 - SLO

关键原则：

• SLO 通常比 SLA 更严格，这样在触达合同红线前，内部已经有预警和缓冲。
• SLA 是法律/商务承诺，不是越严越好；要结合架构、依赖和成本。
• SLI 必须是用户视角的，不能只看服务器 CPU 这种「自我感觉良好」的指标。

什么是好的 SLI

好的 SLI 应满足：

• 用户可感知：反映用户真正关心的成功、延迟、正确性。
• 可测量：有稳定的数据源，采样和聚合方式明确。
• 可行动：指标恶化时，团队知道如何排查和改进。
• 成比例：指标变化与用户体验变化大致对应。
• 定义清晰：明确分母、分子、时间窗口、排除项。

一个完整的 SLI 定义至少包含：

常见 SLI 类型

注意：

• 不要用平均值做延迟 SLO，平均值会掩盖长尾。
• 不要只看服务端，客户端感知的延迟可能包含网络、DNS、CDN。
• 不要把 4xx 一律算失败，要区分客户端错误和服务端错误；但某些 4xx 也可能是业务缺陷。
• 不要忽略采样偏差，日志采样、指标聚合都可能让 SLI 失真。

SLI 示例

HTTP API

可用性 SLI = 非 5xx 请求数 / 有效请求数
延迟 SLI = 延迟 <= 300ms 的请求数 / 有效请求数

有效请求可以排除：

• 健康检查
• 监控探针
• 已知爬虫（需谨慎）
• 客户端主动取消（需单独分析）

批处理任务

新鲜度 SLI = 数据产出时间 <= 承诺时间的批次 / 总批次
完成率 SLI = 成功完成的批次 / 应完成批次
正确性 SLI = 校验通过的记录数 / 总记录数

存储系统

可用性 SLI = 成功读写请求 / 有效读写请求
持久性 SLI = 1 - 丢失对象数 / 总对象数
延迟 SLI = 读写延迟 <= 阈值的请求比例

SLO 怎么定

定 SLO 的基本步骤：

1. 选关键用户旅程：不要一开始给所有服务定 SLO。
2. 定义 SLI 公式：分子、分母、窗口、排除项写清楚。
3. 测量基线：先观察 4-8 周真实表现。
4. 设定目标：从略低于当前水平开始，逐步收紧。
5. 定义错误预算政策：预算消耗后怎么办。
6. 配置燃尽率告警：不要只配静态阈值。
7. 定期评审：业务变化、架构变化、依赖变化都要重评。

SLO 目标不是越高越好：

• 99.9% 与 99.99% 的成本可能差一个数量级。
• 目标过高会导致过度保守、发布停滞、团队疲惫。
• 目标过低会失去用户信任和内部约束力。

SLO 的计量口径

实践建议：

• 同一服务不要混用多种口径，否则预算无法解释。
• 延迟 SLO 用「低于阈值的请求比例」或分位数，不要用平均延迟。
• 客户端测量更贴近用户体验，但受网络和端侧影响；服务端测量更稳定，但可能漏掉边缘问题。关键服务最好两者都有。
• 指标缺失、采集失败要单独处理，不能当成「没有错误」。

依赖链与 SLO

• 端到端 SLO 面向用户旅程，组件 SLO 面向内部服务，两者不能互相替代。
• 不要简单把依赖 SLO 相乘当作端到端 SLO；冗余、重试、降级、缓存都会改变实际影响。
• 关键依赖要有自己的 SLO，并纳入容量规划和故障演练。
• 依赖故障时，要明确降级策略和用户可见影响。
• 错误预算按用户旅程聚合，避免「每个组件都达标，但端到端体验很差」。

错误预算

错误预算 = 1 - SLO。

例如 SLO 99.9%，错误预算就是 0.1%。

错误预算的意义：

• 它不是「允许故障」的借口，而是「用多大代价换多少速度」的量化工具。
• 预算充足时，可以加快发布、做实验、承担可控风险。
• 预算耗尽时，应冻结高风险变更，优先修复可靠性，直到预算恢复或有明确例外。

错误预算政策

一个可执行的政策示例：

政策要点：

• 冻结的是高风险变更，不是所有变更；修复类、回滚类、降级类变更应放行。
• 例外要有记录：谁批准、为什么、风险是什么、何时复核。
• 不要把预算当 KPI 惩罚人，否则团队会隐藏故障、篡改指标。
• 预算按服务/用户旅程分别计算，不要用一个总预算掩盖局部问题。

燃尽率与告警

燃尽率（Burn Rate）表示错误预算消耗速度：

Burn Rate = 当前错误率 / (1 - SLO)

例如 SLO 99.9%，当前错误率 1%，则燃尽率 = 1% / 0.1% = 10 倍。意味着按当前速度，30 天预算大约 3 天就会烧完。

多窗口多燃尽率告警（示例）：

这类告警比「5xx > 1%」更贴近用户体验，也更少噪音。

PromQL 示例

# 5xx 比例
sum(rate(http_requests_total{job="api",code=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="api"}[5m]))

# p99 延迟
histogram_quantile(
  0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket{job="api"}[5m]))
)

# 99.9% SLO 的 1 小时燃尽率
(
  sum(rate(http_requests_total{job="api",code=~"5.."}[1h]))
  /
  sum(rate(http_requests_total{job="api"}[1h]))
) / 0.001

注意：

• 分母要排除健康检查等无效请求。
• 延迟桶的边界要和 SLO 阈值对齐。
• 指标缺失、采集失败也要纳入可靠性分析，不能当成「0 错误」。

SLO 文档模板

服务名称：
用户旅程：
负责人：
SLI：
  - 名称：
  - 好事件：
  - 有效事件：
  - 公式：
  - 数据源：
SLO：
  - 目标：
  - 窗口：28 天滚动
  - 当前基线：
错误预算：
  - 计算方式：
  - 政策：
告警：
  - 快烧：
  - 慢烧：
  - 通知渠道：
依赖：
  - 上游服务及其 SLO：
复核周期：每季度

SLA 怎么定

SLA 是对外合同，通常包含：

• 服务范围与排除项。
• 可用性/延迟等指标定义。
• 测量方法与数据来源。
• 统计周期（月/季）。
• 未达标的补偿（服务 credits、退款等）。
• 客户责任与免责条款。
• 报告与争议处理流程。

SLA 设计原则：

• **不要承诺 100%**：架构、上游依赖、客户网络都可能出问题。
• SLO 要严于 SLA：给自己留缓冲。
• 指标要可测量、可审计：否则争议不断。
• 排除项要写清楚：计划维护、客户误用、不可抗力、上游故障等。
• 补偿要可执行：别写无法兑现的承诺。
• 与业务/法务一起定：SRE 提供技术可行性，业务决定商业条款。

常见误区

Toil 识别与消除

什么是 Toil

Toil 是手动、重复、可自动化、战术性、不产生持久价值、随服务规模线性增长的工作。

六个判定条件：

1. 手动：需要人执行。
2. 重复：反复发生。
3. 可自动化：理论上可以由机器完成。
4. 战术性：打断当前工作，处理眼前问题。
5. 无持久价值：做完后不会留下长期能力。
6. 线性增长：服务规模翻倍，工作量也翻倍。

Toil 不等于所有运维工作。事故响应、容量规划、架构设计、自动化建设、知识沉淀都不属于 Toil。

常见 Toil

如何识别 Toil

方法一：时间采样

让 SRE/运维按小时或半天记录工作类型：

连续记录 2-4 周，就能看出 Toil 占比和主要来源。

方法二：工单分析

对工单按「频率、耗时、重复性、可自动化」分类：

方法三：On-call 中断日志

记录每次 page 的原因、处理动作、是否重复、是否有 runbook。重复出现的 page 往往对应可消除的 Toil 或可改进的告警。

方法四：价值流分析

画出从「用户请求」到「价值交付」的流程，标记每个等待、审批、手工步骤。手工步骤越多，Toil 和错误风险越高。

Toil 预算

Google SRE 的经验是：每个 SRE 的 Toil 不应超过 50% 工作时间。超过这个比例，SRE 就没有足够时间做工程改进，长期会陷入「越忙越没空优化，越不优化越忙」的循环。

企业可以根据规模设定：

• 初创团队：Toil 可能暂时偏高，但要有下降趋势。
• 成熟团队：Toil 控制在 30%-50%。
• 平台团队：Toil 应持续低于 30%，把能力产品化。

Toil 预算要作为团队指标，而不是个人考核指标，避免「谁做得快就被分配更多 Toil」。

消除 Toil 的策略

1. 先消除，再简化，最后自动化

很多团队一上来就自动化，结果把错误流程固化。正确顺序是：

1. Eliminate：这个步骤真的需要吗？能否取消审批、合并流程、删除无效检查？
2. Simplify：能否标准化、减少选项、统一工具？
3. Automate：把稳定、重复的流程自动化。
4. Delegate：交给平台、CI/CD、自助门户。
5. Outsource：非核心能力考虑托管服务。

2. 自动化分级

大多数团队应先从 L1/L2 做起，再逐步走向 L3/L4。不要为了「智能」而跳过可靠性基础。

3. 自动化的工程要求

自动化不是「写个脚本」就完了，至少要满足：

• 幂等：重复执行结果一致。
• 可观测：有日志、指标、告警。
• 可回滚：失败能恢复。
• 可测试：有单元测试/集成测试/演练。
• 最小权限：只授予必要权限。
• 审计：谁触发、改了什么、结果如何。
• 失败处理：超时、重试、熔断、人工接管。
• 文档：谁维护、如何排错。

4. 自助化与平台化

把高频请求变成自助能力：

• 证书申请/续期：ACME + CLM。
• 环境创建：IaC 模板 + 自助门户。
• 权限申请：RBAC + 审批自动化。
• 发布：CI/CD + GitOps + 灰度。
• 扩缩容：HPA/VPA + 集群自动扩缩。
• 诊断：统一 dashboard + runbook + 查询模板。

平台化的关键是黄金路径：让正确做法成为最容易的做法，而不是靠文档和审批强迫。

5. Toil 项目排序

用 ROI 排序：

优先级 = 月节省小时 × 影响人数 × 错误减少收益 / 建设与维护成本

优先做：

• 高频、耗时、规则明确、风险可控。
• 重复出错、影响面大的。
• 有明确 owner 和维护能力的。
• 能复用到多个团队的。

不要做：

• 只发生一次的。
• 流程本身还没稳定的。
• 自动化成本高于收益的。
• 没有监控和回滚能力的。

Toil 治理机制

• 每月 Toil 盘点：列出 Top 10 Toil，估算月耗时。
• 设定 Toil 预算：团队/个人不超过 50%，并跟踪趋势。
• 纳入迭代：每季度至少安排一个 Toil 消除项目。
• 奖励自动化：把「减少多少人工」纳入团队复盘，而不是奖励救火英雄。
• 记录节省：自动化上线后，统计节省时间、错误率变化、MTTR 变化。
• 防止反弹：新流程上线时评估是否引入新的 Toil。

Toil 指标

常见反模式

• 为了自动化而自动化：流程本身有问题，自动化只是加速错误。
• 一次性脚本入库：没有测试、没有 owner、没有文档，半年后没人敢动。
• 自动化后仍需人工确认：名义上自动，实际还是人肉。
• 隐藏 Toil：为了指标好看，把 Toil 记成项目工作。
• 只优化个人效率：没有平台化，换个团队又要重做。
• 忽视维护成本：自动化系统本身也需要 owner 和监控。

事故响应流程与 On-call 值班

事故分级

先定义严重级别，避免每次都要争论「这算不算事故」。

分级要点：

• 就高不就低：不确定时先按更高级别响应，后续可降级。
• 早期宣告：不要等到确认根因才 declare，先拉人、先止损。
• 级别可调整：影响扩大则升级，影响缩小则降级并记录。

事故角色

小团队可以一人多角，但IC 和排查者尽量分离。IC 如果埋头 debug，就没人管全局、沟通和决策。

事故生命周期

检测 → 宣告 → 集结 → 缓解 → 沟通 → 解决 → 复盘

1. 检测

来源：

• SLO 燃尽率告警
• 业务指标异常
• 用户反馈/客服工单
• 依赖方通知
• 安全告警
• 巡检/游戏日发现

要求：

• 告警必须可行动、有 owner、有 runbook。
• 避免「告警风暴」，要分组、抑制、去重。
• 监控本身也要有冗余，避免监控先挂。

2. 宣告

一旦确认影响用户，立即：

• 创建事故频道/会议。
• 指定 IC。
• 确定初始级别。
• 通知相关团队。
• 开始时间线记录。

宣告话术示例：

【事故宣告】SEV2
现象：下单 API 5xx 比例 18%，持续 5 分钟
影响：部分用户无法下单
IC：张三
频道：#inc-20261023-001
下次更新：15 分钟后

3. 集结

• 拉齐研发、SRE、DBA、网络、客服、业务。
• 明确谁负责排查、谁负责沟通、谁记录。
• 建立单一信息源，避免多个群各说各话。

4. 缓解优先

事故响应的第一目标是止损，不是找根因：

• 回滚最近变更。
• 关闭特性开关。
• 切流/降级/限流。
• 扩容/重启/故障转移。
• 恢复备份。
• 绕过故障依赖。

原则：

• 先止血，再诊断。
• 小步操作，及时验证。
• 保留现场：日志、指标、配置、部署版本。
• 避免多人同时改生产，由 Ops Lead 统一指挥。

5. 沟通

沟通节奏按级别：

• SEV1：每 15-30 分钟更新。
• SEV2：每 30-60 分钟更新。
• SEV3：按需或每 2-4 小时。

沟通内容：

• 当前状态（investigating/identified/monitoring/resolved）。
• 用户影响。
• 已采取动作。
• 下一步计划。
• 下次更新时间。
• 不要给不可靠的 ETA。

状态页模板：

[Investigating] 我们正在调查部分用户无法下单的问题。
[Identified] 已定位到数据库连接池耗尽，正在扩容并重启异常实例。
[Monitoring] 服务已恢复，5xx 比例回到正常水平，持续观察 30 分钟。
[Resolved] 问题已解决，根因分析和改进项将在复盘后同步。

6. 解决

• 确认核心指标恢复。
• 观察足够长的稳定期。
• 关闭事故频道，保留记录。
• 通知客服/业务/客户。
• 安排复盘。

7. 复盘

所有 SEV1/SEV2、重复事故、SLO 严重违约都应复盘；SEV3/4 可做轻量复盘。详见下一节。

On-call 值班设计

轮值模式

基本要求：

• Primary 第一响应，Secondary 超时升级。
• 明确响应时间，如 5 分钟内确认，15 分钟内升级。
• 交接要有书面记录。
• 值班期间保证可访问网络、电脑、VPN、生产权限。
• 值班后安排恢复时间，避免长期疲劳。

值班职责

• 及时确认 page。
• 判断严重级别，决定是否宣告事故。
• 按 runbook 执行初步缓解。
• 需要时升级给 secondary/专家/IC。
• 记录时间线和操作。
• 交接未完成事项。

可持续 On-call

不可持续的信号：

• 每班大量噪音 page。
• 长期睡眠不足。
• 只有个别人能处理。
• 事故全靠英雄主义。
• 值班没有补偿或恢复时间。
• 告警没有 runbook。

改进方向：

• 设定 page 量目标，如每 12 小时不超过 2 个可行动 page。
• 清理不可行动告警。
• 自动化和自愈。
• 轮换和培训，扩大值班人员池。
• 游戏日和演练。
• 值班反馈机制，每次噪音 page 都要有改进项。

交接模板

交班人：
接班人：
时间：
当前事故：
  - 编号/级别/状态/IC
  - 已采取动作
  - 待办与风险
计划变更：
  - 时间/内容/负责人/回滚方案
告警与容量：
  - 异常指标
  - 容量风险
其他：
  - 需要关注的事项

Runbook、Playbook 与 Game Day

Runbook 至少包含：

• 触发条件和影响判断。
• 前置检查（权限、环境、影响范围）。
• 操作步骤（可直接复制执行的命令）。
• 验证方式（指标、日志、业务探测）。
• 回滚步骤。
• 升级联系人和升级条件。
• 最后更新时间。

Game Day：

• 定期模拟真实故障，验证告警、runbook、权限、沟通和降级是否有效。
• 设定明确的爆炸半径和终止条件。
• 从低风险场景开始，如单实例故障、依赖超时、证书过期演练。
• 结束后必须复盘，把发现转成行动项，而不是「演完就结束」。

告警治理

好的告警：

• 基于症状（用户受影响），而不是单纯原因（CPU 高）。
• 有明确 owner、severity、runbook、dashboard。
• 可行动：收到后知道做什么。
• 去重、分组、抑制：避免一个故障触发几百条告警。
• 有升级路径。
• 定期评审，删除无效告警。

告警分层：

事故指标

MTBF 在复杂分布式系统中受多因素影响，适合做趋势参考，不宜作为单一 KPI。

常见事故响应反模式

• 没有 IC，所有人各干各的。
• 先找根因，不止血。
• 不及时沟通，客服/业务靠猜。
• 多人同时改生产，互相覆盖。
• 事故频道信息碎片化。
• 不敢宣告事故，怕担责。
• 值班没有权限，处处等人审批。
• 告警太多，真正的故障被淹没。
• 事故结束后不复盘，或复盘后不跟踪行动项。

无指责复盘与故障档案库

什么是无指责复盘

无指责复盘（Blameless Postmortem）不是「不追究责任」，而是：

• 假设当事人在当时的信息、工具、压力下做出了合理决策。
• 关注系统和流程为什么允许错误发生，而不是找「谁干的」。
• 通过改进系统、工具、流程、培训，降低同类问题再次发生的概率。
• 对行动项和整改结果保持问责。

核心理念：

• 人不是故障的根因，系统才是。
• 「人为错误」是结论的起点，不是终点。要问：为什么这个操作容易出错？为什么没有拦截？为什么没有检测？
• 心理安全：说真话不会被惩罚，才能拿到真实信息。
• 学习优先：复盘的目标是学习，不是审判。

什么时候做复盘

建议：

• 所有 SEV1/SEV2 事故。
• SLO 严重违约或错误预算快速耗尽。
• 重复发生的 SEV3。
• 近失事件（差点出事）。
• 重大变更失败。
• 安全/数据相关事件。

轻量复盘适用于低级别事件，可以只记录时间线、原因和 1-2 个行动项。

复盘时间线

复盘模板

# 事故复盘：<标题>

## 基本信息
- 事故编号：
- 日期：
- 级别：
- 服务：
- 负责人：
- 状态：草稿/评审中/已发布/已关闭

## 摘要
用 3-5 句话说明发生了什么、影响是什么、如何恢复。

## 影响
- 用户影响：
- 业务影响：
- SLO/错误预算影响：
- 持续时间：
- 受影响范围：

## 时间线（UTC）
| 时间 | 事件 | 来源 |
| ---- | ---- | ---- |

## 根因与 Contributing Factors
- 直接触发因素：
- 技术原因：
- 流程原因：
- 组织/人为因素：
- 为什么没有更早发现？
- 为什么没有自动拦截？

## 检测与响应
- 如何发现：
- 检测耗时：
- 响应是否及时：
- 哪些做得好：
- 哪些需要改进：

## 行动项
| 编号 | 行动 | 类型 | 负责人 | 优先级 | 截止时间 | 状态 |
| ---- | ---- | ---- | ------ | ------ | -------- | ---- |

## 经验与附录
- 关键日志/指标/图表：
- 相关 runbook：
- 相关变更：
- 参考文档：

根因分析的正确姿势

不要只写「人为错误」

「人为错误」几乎总是真的，但它不是可行动的结论。要继续追问：

• 为什么这个操作容易出错？
• 为什么没有校验/审批/自动化拦截？
• 为什么监控没有发现？
• 为什么 runbook 没有覆盖？
• 为什么当时的信息不清晰？
• 为什么时间压力这么大？

使用 Contributing Factors

事故通常是多因素叠加：

• 触发因素：直接引发故障的变更/事件。
• 技术因素：代码缺陷、配置错误、容量不足、依赖故障。
• 检测因素：监控缺失、阈值不合理、告警被淹没。
• 响应因素：runbook 缺失、权限不足、沟通不畅。
• 组织因素：排期压力、职责不清、培训不足、技术债。

5 Whys 的局限

5 Whys 适合简单问题，但容易：

• 只沿一条因果链，忽略并行因素。
• 把复杂系统问题简化成单点。
• 导向「找个人」而不是「改系统」。

更推荐结合：

• 时间线重建
• 因果树/鱼骨图
• 变更与故障相关性分析
• 反事实分析：「如果当时有 X，是否能避免/缩短？」
• Swiss Cheese 模型：多个防线同时失效

行动项质量

差的行动项：

• 「加强监控」
• 「提高意识」
• 「注意操作」
• 「以后小心」

好的行动项：

• 具体：增加数据库连接池使用率 > 80% 的告警，阈值持续 5 分钟。
• 可衡量：告警上线后，连接池耗尽类事故检测时间 < 5 分钟。
• 有 owner：DBA 团队张三。
• 有截止时间：2026-11-15。
• 有验证方式：演练一次连接池耗尽场景。
• 有优先级：P1。

行动项类型：

行动项不要太多。一次复盘聚焦 3-5 个高价值改进，比列 30 个没人做的任务更有效。

复盘会议怎么开

• 由中立的人主持，避免管理者主导定责。
• 先讲时间线，再讨论原因和改进。
• 鼓励当事人还原「当时看到什么、怎么想、为什么这么做」。
• 使用无指责语言：
  • 不说「你为什么没检查？」，说「当时有哪些检查手段？为什么没有触发？」
  • 不说「这是某某的失误」，说「这个操作缺少防呆设计」。
• 时间盒 60-90 分钟。
• 会议结束前确认行动项 owner 和截止时间。
• 会后发布复盘，向相关团队共享。

故障档案库

复盘写完不能躺在文档库里。要建立可检索、可复用、可维护的故障档案库。

档案字段

标签体系

建议至少按以下维度打标签：

• 服务/团队
• 症状（5xx、延迟、超时、数据丢失）
• 根因（代码、配置、容量、依赖、变更、安全）
• 触发（发布、流量、证书、DNS、数据库）
• 级别（SEV1-4）
• 状态（open/mitigated/closed）

档案库的用法

• 事故发生时：先搜历史相似故障，快速找到缓解方案。
• 复盘时：引用同类事故，判断是否重复问题。
• 季度评审：统计 Top 根因、重复事故、行动项完成率。
• ** onboarding**：新成员通过真实故障学习系统。
• 自动化：把高频故障的缓解步骤转成 runbook 和自愈脚本。
• 风险治理：识别高影响、低检测、重复发生的系统性风险。

维护机制

• 每篇复盘有 owner。
• 行动项进入工单系统，定期跟踪。
• 每季度清理过期/失效的 runbook。
• 复盘发布后同步到档案库和团队知识库。
• 事故频发的服务进入可靠性专项。
• 将档案库与监控、发布、CMDB 关联，形成可追溯链路。

复盘指标

无指责文化怎么建立

• 领导示范：管理者先承认系统问题，不急着找人背锅。
• 区分学习与绩效：复盘信息不用于惩罚，除非涉及故意违规/重大过失。
• 奖励发现和修复：奖励主动报告近失事件、改进系统的人。
• 语言规范：培训无指责表达，避免「谁的责任」。
• 透明共享：复盘对相关团队开放，而不是藏在少数人手里。
• 闭环：行动项必须有人做、有人验收，否则文化会变成「复盘表演」。
• 持续：文化不是一次培训，而是长期制度设计。

常见反模式

一个简化的复盘示例

事故：支付 API 证书过期导致 5xx
级别：SEV2
影响：12 分钟内约 8% 支付请求失败
时间线：
  10:00 证书过期
  10:03 SLO 快烧告警触发
  10:05 On-call 确认，宣告 SEV2
  10:08 定位到证书过期
  10:12 替换证书并 reload
  10:15 指标恢复，持续观察
根因/因素：
  - 自动续期任务失败，但没有告警
  - 只监控了证书剩余 7 天，没有监控续期任务本身
  - 证书 owner 离职，清单未更新
行动项：
  - P1：为续期任务增加成功/失败告警（owner：SRE，2 周）
  - P1：证书纳入 CLM 清单，明确 owner（owner：平台，1 个月）
  - P2：增加证书过期演练（owner：SRE，1 个季度）

这个例子的重点不是「谁忘了续期」，而是：为什么续期失败没有告警？为什么证书没有 owner？为什么监控只覆盖了结果没有覆盖过程？

快速落地检查清单

• 已选定 1-2 个核心用户旅程，而不是给所有服务同时定 SLO
• 每个 SLO 有 owner、SLI 公式、数据源、窗口和排除项
• SLO 严于 SLA，并经过业务/法务确认
• 错误预算政策明确，例外有记录和复核机制
• 告警基于燃尽率和用户症状，而不是纯资源阈值
• 每条 page 告警都有 owner、runbook 和升级路径
• On-call 轮换、交接模板、响应时间和补偿机制已落地
• Top 10 高频故障有 runbook，且定期演练
• 事故分级、IC 角色、沟通模板和状态页已就绪
• SEV1/SEV2 在 5 个工作日内完成复盘
• 复盘行动项有 owner、优先级、截止时间，并进入工单跟踪
• 故障档案可检索，标签统一，能关联监控和变更记录
• 每月盘点 Toil，每季度至少完成一个 Toil 消除项目
• 关键依赖有 SLO、降级方案和容量评估
• 定期 Game Day/演练，验证检测、响应和恢复能力
• 跟踪 MTTD、MTTA、MTTR、page 量、复盘完成率和行动项关闭率

结语

SRE 方法论的价值不在于术语，而在于把可靠性变成一套可执行的闭环：

• 用 SLI/SLO 定义目标。
• 用 错误预算 做取舍。
• 用 Toil 治理 释放工程时间。
• 用 事故响应 控制损失。
• 用 无指责复盘和故障档案 把经验变成组织能力。

落地时不要追求一步到位。先选一个核心服务，把 SLO、On-call、复盘和 runbook 跑通，再逐步扩展到更多服务和团队。