事故复盘不是写检讨，而是让团队变强的一次机会
凌晨 2 点，监控突然开始报警。
接口 P99 从 200ms 飙到 5s，错误率一路上涨。值班同学冲进群里，开始查日志、重启服务、扩容、回滚。
两个小时后，服务终于恢复。
第二天上午，大家坐在会议室里开事故复盘。
然后有人问：
“这次事故到底是谁改的？”
如果复盘最后变成了这句话，那我觉得这次事故基本算白出了。
真正成熟的运维团队，应该慢慢完成一个转变：
从“事故发生了以后怎么解释”，走向“事故发生以后组织怎么变强”。
这也是我越来越认同的一件事情：
Postmortem 的终点，不应该是一份复盘文档，而应该是一次组织学习的开始。
一、很多公司的事故复盘，其实只是“事故作文”
我见过一些非常典型的事故复盘。
标题：
《XX系统 9月15日生产事故复盘报告》
内容大概是：
事故时间： 02:13
事故恢复： 03:47
事故影响： XX用户
事故原因： 某同学发布配置错误
处理方式： 回滚
责任人： XXX
整改措施： 加强发布审核
看起来特别完整。
但是过了三个月，同样的事故又发生了。
只是这次换了个人。
为什么？
因为这种复盘回答的是：
“上一次是谁做错了？”
而不是：
“为什么一个正常工作的工程师，能够这么容易把系统搞挂？”
这两个问题看起来差不多，实际上完全不同。
二、真正应该复盘的，不是“谁犯错”，而是“系统为什么允许错误发生”
假设生产环境有这样一条命令：
kubectl delete deployment payment-service -n prod
一个新人拿到了生产权限。
凌晨三点，他本来想删除测试环境 Deployment，结果 namespace 写错了。
系统挂了。
如果你的复盘结论是：
“新人操作失误，生产操作不规范。”
那你下一步大概率会做：
加强培训
加强教育
加强审批
加强责任意识
听起来都对。
但其实没有解决核心问题。
因为真正值得问的是：
为什么一个人的一个命令，就能让生产系统直接进入不可用状态？
成熟一点的改进可能是：
生产环境禁止直接 kubectl delete
↓
必须通过发布平台操作
↓
平台识别生产环境
↓
高危操作二次确认
↓
权限最小化
↓
操作审计
↓
异常行为自动告警
这时候，事故才真正产生了价值。
因为你不是要求：
“以后大家千万别犯错。”
而是让系统变成：
“即使有人犯错，也不至于造成灾难。”
这才是工程思维。
三、Postmortem 最重要的一个词：Blameless
很多人第一次听到 Blameless Postmortem（无责复盘），会产生一个误解：
“无责复盘是不是出了事故也不用追责？”
不是。
Blameless ≠ 不承担责任。
它真正想表达的是：
复盘的时候，不要把人的错误当成分析终点。
比如：
def deploy(config):
if config.env == "prod":
deploy_to_production(config)
这里最大的风险是什么？
不是某个人粗心。
而是：
代码允许任何人直接部署生产
那我们真正应该修改的，是系统。
例如：
def deploy(config, operator):
if config.env == "prod":
if not operator.has_permission("prod_deploy"):
raise PermissionError("没有生产发布权限")
if not config.approved:
raise PermissionError("生产发布未审批")
return deploy_to_environment(config)
再进一步：
def deploy(config, operator):
validate_config(config)
if config.env == "prod":
check_permission(operator)
check_approval(config)
check_change_window(config)
create_audit_record(operator, config)
return deploy_to_environment(config)
你会发现：
真正优秀的复盘，最后一定会落到系统、流程、工具和组织机制上。
四、事故不是“坏事”，重复事故才是真正的坏事
我特别喜欢一个判断事故价值的方法：
第一次事故叫问题，第二次同类事故叫管理问题。
比如第一次 Redis 把内存打爆。
大家发现：
没有内存告警
没有容量预测
没有淘汰策略
没有压测
然后补上。
半年后，又因为 Redis 内存爆了。
这时候就不能再简单说：
“又一次 Redis 内存事故。”
真正应该问的是：
为什么第一次事故留下的知识，没有进入组织？
这就涉及一个很容易被忽略的问题：
事故复盘 ≠ 组织学习
复盘只是：
发生了什么？
为什么发生？
怎么恢复？
以后怎么办？
而组织学习则是：
事故
↓
知识
↓
行动
↓
机制
↓
标准
↓
工具
↓
自动化
↓
组织能力
这是完全不同的层次。
五、不要只写“整改措施”，要给整改措施加上生命周期
很多 Postmortem 最大的问题，是整改项写得特别漂亮。
例如：
1. 增加监控
2. 优化发布流程
3. 加强代码审核
4. 完善应急预案
然后一个月以后：
TODO
TODO
TODO
TODO
最后谁都不知道做到什么程度了。
我更推荐把事故 Action Item 做成类似下面这种结构：
action_items = [
{
"problem": "数据库连接池耗尽",
"action": "增加连接池使用率监控",
"owner": "张三",
"priority": "P0",
"deadline": "2026-09-20",
"status": "DOING",
"verify": "模拟连接池耗尽，确认告警5分钟内触发"
}
]
注意最后那个：
verify
非常重要。
因为：
没有验证方式的整改措施，很容易只是“写过了”。
比如：
增加数据库监控
不够。
应该变成：
数据库连接池 > 80%
↓
触发 Warning
数据库连接池 > 95%
↓
触发 Critical
模拟连接池耗尽
↓
确认告警
↓
确认通知
↓
确认值班人员收到
这时候，它才从一句话变成真正的工程能力。
六、事故复盘真正应该关注的是“控制点”
举个大家都熟悉的例子。
一次线上发布导致 CPU 100%。
最开始调查发现：
某次代码提交引入了死循环
如果到这里就结束了：
“开发写代码不严谨。”
那意义其实不大。
继续往下问：
第一层
为什么有死循环？
代码 Bug
第二层
为什么测试没发现？
测试场景覆盖不足
第三层
为什么测试场景覆盖不足？
没有针对大数据量做测试
第四层
为什么没有大数据量测试？
性能测试没有纳入发布门禁
第五层
为什么发布可以绕过性能测试？
CI/CD 没有强制检查
你看。
一开始是：
一个 Bug
最后变成：
CI/CD质量门禁缺失
这就是典型的 从个人错误走向系统性原因。
七、真正高级的运维，不是“救火快”，而是“让火越来越少”
传统运维经常有一种英雄主义：
“这个问题只有我能解决。”
凌晨服务器挂了。
某个大佬上线。
ssh production
tail -f xxx.log
grep ERROR xxx.log
kill -9 xxx
systemctl restart xxx
然后：
“好了。”
群里：
“牛逼。”
确实牛逼。
但从组织能力角度来看，这其实不一定是好事。
因为如果：
只有 A 知道怎么处理
那么组织能力其实是：
A = 100
其他人 = 0
真正成熟之后应该变成：
A知道
↓
A写下来
↓
形成Runbook
↓
自动化
↓
新人也能执行
最终：
if service_down:
detect()
diagnose()
execute_runbook()
verify()
record()
这时候，原来只有一个人会的“绝活”，变成了整个团队的基础能力。
八、我特别建议把事故沉淀成“可执行知识”
很多公司的 Wiki 有几十万字。
但真正出事故的时候，没人看。
为什么？
因为知识写成了：
第一章 系统介绍
第二章 架构说明
第三章 网络拓扑
第四章 数据库设计
……
半夜三点的时候，你根本没心情看。
真正有价值的运维知识应该长这样：
【现象】
接口 5xx > 10%
【第一步】
检查：
kubectl get pods
【第二步】
查看：
kubectl logs xxx
【第三步】
如果出现：
OOMKilled
【处理】
kubectl rollout restart deployment xxx
【验证】
错误率恢复 < 1%
【升级】
超过10分钟无法恢复，通知DBA
这才叫：
Runbook。
它的价值不是“记录历史”。
而是：
让下一次事故处理得更快。
九、事故还可以反过来喂给监控、测试和AI
这也是我认为未来 AIOps 特别有价值的一点。
一次事故发生：
事故
↓
日志
↓
指标
↓
Trace
↓
人工判断
↓
根因
如果只是写一份 Postmortem：
事故结束
就结束了。
但如果继续做：
事故
↓
提取特征
↓
形成规则
↓
加入监控
↓
加入测试
↓
加入知识库
↓
AI学习
那事故就开始产生复利。
例如以前：
数据库连接数 > 90%
没人特别关注。
发生一次事故以后发现：
连接数 > 90%
+
慢SQL增加
+
CPU > 80%
+
请求量持续上涨
是一个非常危险的组合。
那么就可以形成：
if (
db_connections > 0.9
and slow_sql_rate > 0.2
and cpu_usage > 0.8
):
alert(
level="critical",
message="数据库资源耗尽风险"
)
下一次事故甚至可能还没发生，系统已经告诉你：
“这个事故正在形成。”
这就是从：
事故响应
走向：
事故预防。
十、最终要建立的是一条“事故 → 能力”的流水线
如果让我给一个真正落地的模型，我会这样设计：
┌──────────────┐
│ 生产事故 │
└──────┬───────┘
↓
┌──────────────┐
│ 快速恢复 │
└──────┬───────┘
↓
┌──────────────┐
│ Postmortem │
└──────┬───────┘
↓
┌────────┴────────┐
↓ ↓
技术原因 系统原因
↓ ↓
修复Bug 修机制
↓ ↓
加测试 加监控
↓ ↓
加告警 自动化
└────────┬────────┘
↓
┌──────────────┐
│ Runbook │
└──────┬───────┘
↓
┌──────────────┐
│ 知识库 │
└──────┬───────┘
↓
┌──────────────┐
│ 团队培训 │
└──────┬───────┘
↓
┌──────────────┐
│ 组织能力提升 │
└──────────────┘
这才是真正意义上的：
从 Postmortem 到组织学习。
十一、最后，我越来越觉得：事故本身不是最可怕的
运维工作有一个很残酷的现实：
复杂系统一定会出事故。
你再努力，也不可能做到：
事故率 = 0
真正应该追求的可能是：
事故发生
↓
影响越来越小
↓
发现越来越快
↓
恢复越来越快
↓
重复事故越来越少
↓
团队越来越不依赖个人
所以我不太喜欢把 Postmortem 翻译成简单的“事故总结”。
它更像是一种组织的记忆机制。
人会忘记。
新人会加入。
老员工会离职。
系统会重构。
代码会重写。
但是，如果一次事故最终变成了：
一条监控
一个测试
一个Runbook
一个自动化脚本
一个发布门禁
一条工程规范
一套培训材料
那么这场事故就没有白发生。
最好的事故复盘，不是让大家记住“谁搞砸了”。
而是让组织记住：
“我们曾经在这里摔倒过，所以以后不会再用同样的姿势摔第二次。”
这才是 Postmortem 最有价值的地方。
也是我理解的运维真正的成长：
从“我能把系统救回来”，到“我能让这个团队以后更不容易把系统搞挂”。
前者是运维能力。
后者，才是组织能力。
