115 lines
5.3 KiB
Markdown
115 lines
5.3 KiB
Markdown
---
|
||
tags: [sre, postmortem, blameless, dora-metrics, incident-management]
|
||
create time: 2026-05-18 00:50
|
||
---
|
||
|
||
# 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%，这就是实质性的进步。
|
||
|
||
## 补充：事故分级标准
|
||
|
||
```mermaid
|
||
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 保障
|