Archived

This repository has been archived on 2026-05-24. You can view files and clone it. You cannot open issues or pull requests or push a commit.

Files

T

hhs f8bcbb9d37 vault backup: 2026-05-18 00:17:59

2026-05-18 00:17:59 +08:00

5.3 KiB

Raw Permalink Blame History

tags, create time

SRE 心法与事故复盘 — 文化和方法论

概述

SRE 不仅是技术指标和告警规则，更是一种工作文化。本章介绍 Google SRE 提出的五条核心心法，以及事故复盘的标准流程和 DORA Metrics 效能评估框架。更多 SLO/Error Budget 理论参见 ../04-SRE实践/01-SLI-SLO-SLA详解。

SRE 五条心法

1. 用户视角定义 SLO

不是"API P99 < 200ms"，而是"用户在正常网络下加载页面 < 2s"。

技术指标可能欺骗你——P99 延迟低不代表用户体验好。一个前端图片加载慢 3 秒的服务，后端再快也无法让用户满意。永远从用户的感知出发定义质量。

2. 错误预算用完 = 停止功能开发

当 Error Budget 耗尽时，团队必须全力修 bug、加稳定性，而不是继续发新功能。这不是惩罚，而是资源重新分配的客观依据。

3. Blameless Postmortem

不问"谁干的"，问"流程哪里可以改进"。责备个人只会让团队成员隐瞒问题，最终酿成更大的事故。

4. 自动化一切重复劳动

手动操作一定会出错。无论是回滚、扩容还是配置变更，能脚本化的绝不人工执行。这不仅仅是效率问题，更是可靠性问题。

5. 接受一定程度的失败

在可控范围内快速迭代，比追求完美更重要。Google 的"可控失败"理念认为：小规模的失败是发现系统性问题的最佳途径。

Blameless Postmortem 模板

字段	填写内容
事件名称	`2026-05-05 支付服务超时事故`
影响范围	约 15% 的支付请求失败，持续 23 分钟
发现时间	14:32 (On-Call 接到告警)
恢复时间	14:55 (回滚后确认恢复)
根本原因	某次变更后支付网关的连接池大小从 50 降到 10
时间线	14:00 发布 v1.2.3 → 14:30 错误率开始升高 → 14:32 收到告警 → 14:35 开始排查 → 14:45 定位根因 → 14:50 回滚 → 14:55 完全恢复
改进行动	① 连接池参数变动必须经过压测验证；② 监控中补充连接池活跃数指标
跟进人	@zhangsan (行动 ①)、@lisi (行动 ②)

[!tip] 什么是真正的 "Blameless"？

Blameless ≠ 不追究责任。它的意思是：聚焦于系统和流程缺陷，而非个人的失误。人类会犯错，这是物理定律级别的现实。好的 Postmortem 应该揭示为什么系统设计允许一个简单的配置变更导致大规模故障。

Postmortem 写作原则

原则	做法
事实先行	按时间线罗列发生了什么，不掺入主观判断
5 Whys 分析法	连续问 5 次"为什么"，直到触及根因
行动项可追踪	每个改进措施都要有负责人和截止日期
公开透明	Postmortem 全文共享给全公司，不隐藏信息
闭环验证	改进措施完成后回顾是否真正预防了同类问题

SRE Metrics 看板

除了 SLO，SRE 还需要关注以下运营指标：

指标	说明	目标
MTTR	Mean Time To Recovery	核心服务 < 30min
Change Failure Rate	变更导致故障的比例	< 5%
Lead Time for Changes	代码提交到上线的时间	< 2h
Deployment Frequency	日均部署次数	> 5 (大规模团队)

[!tip] DORA Metrics

Google 提出的四大 DevOps 指标，广泛用于评估工程效能：

部署频率 — 交付速度

变更前置时间 — 从代码提交到生产部署需要多久

变更失败率 — 多少部署导致了故障或回滚

MTTR — 恢复服务的平均时间

四种绩效等级的 DORA 表现

等级	部署频率	变更前置时间	变更失败率	MTTR
🏆 精英 (Elite)	每日多次	< 1 小时	< 5%	< 1 小时
🥈 高 (High)	每周 1-6 次	< 1 周	6-15%	1-7 天
🥉 中 (Medium)	每月 < 1 次	1-4 周	16-30%	> 1 个月
⬜ 低 (Low)	< 每月 1 次	> 6 个月	> 30%	> 6 个月

[!info] 关于 DORA 的提醒

DORA Metrics 的价值在于纵向对比自身演进，而非横向攀比。一个创业团队追求"精英级"可能过度工程化。关键是看趋势——如果你的 Change Failure Rate 从 20% 降到了 10%，这就是实质性的进步。

补充：事故分级标准

flowchart TD
    P0["🔴 P0 - 灾难性<br/>全站不可用 / 资金损失<br/>CTO 级别通知<br/>2h内必须恢复"] --> P1
    P1["🟠 P1 - 严重<br/>核心功能受影响<br/>负责人 + SRE 紧急会议<br/>4h内必须恢复"] --> P2
    P2["🟡 P2 - 一般<br/>部分功能降级<br/>工作时间处理<br/>24h内必须恢复"] --> P3
    P3["🟢 P3 - 轻微<br/>非核心问题<br/>下个迭代处理"]
    
    style P0 fill:#ffcdd2
    style P1 fill:#ffe0b2
    style P2 fill:#fff9c4
    style P3 fill:#c8e6c9

关联笔记

../04-SRE实践/01-SLI-SLO-SLA详解 — SLI/SLO/SLA 三层模型
../04-SRE实践/02-错误预算深度解析 — Error Budget 告警联动
../hhs/MS/05-部署运维/02-Kubernetes — K8s 自愈能力与 SLO 保障

5.3 KiB Raw Permalink Blame History Unescape Escape