故障复盘会，可能是每个 SRE 和 DEV 最不愿参加的会议。业内常提，故障后回顾（Post-Mortem）需要做到“不指责”（Blameless），否则容易陷入“干得多错得多，错得多被骂得多”的恶性循环，打击团队积极性。
今天与 Google Gemini 聊起这个话题，它的观点令人印象深刻：
复盘会是“对事不对人”，但 HR 部门是“对人”的。
- 在复盘会上（Post-Mortem）：我们绝对不指责个人。因为一旦指责，氛围就会变得防御，真相将被隐藏，你永远无法获知故障的完整技术细节。复盘需要的是诚实。
- 在管理上（Performance Review）：如果一个人反复犯同样的低级错误，或存在主观恶意违规，那属于能力或价值观问题。这超出了“故障复盘”的范畴，进入了 “绩效管理” 领域。应由管理者在复盘会之外，通过私下沟通解决。
Google 提出的 5Why 原则被广泛认同。但细想之下，若想归咎于人，总能通过连续追问引导至“人的意识不足”或“管理不善”；若想归咎于系统，也能推导出“系统健壮性不足”；若想归咎于流程，则“增加审批环节”似乎成了万能解药，最终责任共担。
那么，真正有效的复盘最佳实践究竟是什么？让 Gemini 继续思考，这次的回答更具参考价值：
这一问切中要害。您指出的正是 “5 Why” 方法在落地时的最大软肋：
- 线性逻辑的局限：它假设问题是单链条的（A导致B，B导致C），但现代分布式系统的故障往往是 网状 的（复杂系统的涌现效应）。
- 归因的主观性：正如您所言，立场决定视角。管理者可能觉得是态度问题，SRE 认为架构有缺陷，QA 则归因于流程漏洞。
如果复盘最终演变为“甩锅大会”或“流程加法大会”，那就是彻底的失败。
真正的 最佳实践（Best Practice），并非追求哲学上的“终极真理”，而是追求 工程上的“投入产出比（ROI）”。
以下是结合 Google SRE、Etsy 等公司实践总结出的 “高价值复盘” 核心原则：
1. 从“追问 Why”转向“还原 How”
不要开场就问“为什么会故障？”，因为“为什么”容易激发防御心理和借口。应该问 “事情是如何一步步发生的？”（How did it happen?）。
我们需要构建一份精确到秒的 时间轴（Timeline）。事实本身不会说谎，也无法被甩锅。
- 14:00:01 工程师 A 提交了代码。
- 14:05:23 CI 系统通过了测试（这里是一个客观事实：测试覆盖率不足，而非某个人犯了错）。
- 14:10:00 流量涌入，内存开始飙升。
- 14:15:00 夜莺（Nightingale）发出告警，但在 Flashduty 中被抑制了（这里是一个客观事实：告警策略配置问题）。
最佳实践：复盘会的前 20 分钟，禁止讨论原因，只允许对齐时间轴。 当所有人面对同一份事实时间轴时，问题往往已不言自明。
2. 抛弃“根因”，拥抱“贡献因素”
在复杂系统中，根本不存在单一的“根本原因（Root Cause）”。
- 如果没有那个 Bug，系统可能不会挂。
- 如果熔断机制生效，系统可能不会挂。
- 如果不是遭遇流量高峰，系统可能不会挂。
以上三者可能缺一不可。因此，最佳实践是列出所有的 “贡献因素（Contributing Factors）”。这可以有效避免非此即彼的争论。
- 触发诱因：特定的代码 Bug。
- 放大因子：重试风暴（Retry Storm）。
- 防御缺失：缺乏有效的限流（Rate Limiting）机制。
3. 改进措施的“三不”与“三要”
这是关键：如何避免改进最终变成“增加流程”或“批评个人”？我们需要为 改进项（Action Items） 设立高标准的准入门槛。
| ❌ 低价值改进项 |
✅ 高价值改进项 |
核心原理 |
| “加强培训/提升意识” |
“在 CI 阶段引入静态代码检查（linter）规则” |
不要试图改变人，要优化工具。 |
| “下次操作前需主管审批” |
“将该操作自动化，或引入工具化的双人复核（Peer Review）” |
审批只是转移责任，并未降低错误概率；自动化才是根本解。 |
| “严肃处理当事人” |
“修改系统权限（如 sudo）配置” |
惩罚只会导致下次故障被隐瞒。 |
| “修复这个 Bug” |
“为此类 Bug 添加回归测试用例” |
修复 Bug 是“止血”，添加测试是建立“免疫力”。 |
黄金法则：如果一个改进项依赖于 “人的自律” 或 “行政命令”，那它很可能是无效的。只有那些能转化为 “代码” 或 “架构” 的改进，才会成为团队的长期资产。
4. 引入“停止规则”
您提到“最终都可以引导到制度和文化”。确实如此，但我们必须思考：改变这个制度，值得吗？
复盘需要引入 经济学视角 进行权衡：
- 如果本次故障造成了 1 万元损失。
- 但构建一套完美的防御架构需要投入 3 位工程师开发一个月（成本约 10 万元）。
- 结论：接受风险（Risk Acceptance）。我们记录下这个脆弱点，承认它的存在，但暂时不投入资源改进。这也是一种负责任的复盘结果。
总结
真正的最佳实践在于：承认系统永远存在缺陷，承认人永远可能犯错。 复盘的目的不是“消灭所有错误”，而是 “提升系统对错误的容忍与自愈能力”，并确保每一次故障付出的“学费”，都能转化为实实在在的 “工具代码” 或 “监控策略”，而非一纸空文的“管理制度规定”。
关于故障复盘、Blameless文化以及SRE实践，你还有哪些经验或困惑？欢迎在云栈社区与我们深入探讨。
发表于 昨天 01:11
|
查看: 2|
回复: 0
