总结
当前生产事故复盘实践存在三大缺点：
- 复盘报告分享难：生产意外事件复盘报告通常仅供少数IT团队人员阅读，导致大部分软件人员不了解以往事故的避坑要点，增加重蹈覆辙的风险。
- 演练考试非考验：仅针对运维部门感兴趣的基础设施层意外事件进行演练，忽视程序bug导致的意外事件演练，导致实际遇到后者时难以正确应对。
- 缺乏亲身体验感：仅阅读复盘报告难以亲身体会意外事件场景，容易忽视之前发现的陷阱。
这给做软件的人带来三大痛点：
- 难被认可：不出问题时不被重视，出问题时被指责。
- 心里发虚：缺乏演练导致抢修时心虚。
- 很快遗忘：缺乏实操导致读完复盘后很快忘记。
“意外事件助推避坑”具有四大价值点：
- 领导更认可：将避坑指南写得利他且易懂以提升稳定性保障领导认可度。
- 更多人学到：将生产事故复盘改名为避坑指南以扩大分享学习范围。
- 练过心不慌：练过停机长和损失大的意外事件后遇事不慌。
- 印象更深刻：避坑指南与定期演练相配套以让已发现陷阱印象生动深刻。
“意外事件助推避坑”的定义：
- 意外事件：指导致系统不可用或离线的特定事情的发生，包括计划外事件。
- 助推：营造容许自由选择的温和环境，引导人们从意外事件中体验到避坑要点，从而印象深刻，有助于避免重蹈覆辙。
实现“意外事件助推避坑”的原则：
- 预防虽重要，难免遇意外。
- 修复意外时，系统仍可用。
- 不去指责人，实操印象深。
- 利他且易懂，领导更认可。
实现原则的具体步骤：
- 识别意外事件点
- 隔离意外事件点
- 替换意外事件点
- 避坑意外事件点
- 演练意外事件点
业界普遍缺乏“可隔离”、“可替换”和“可避坑”这三种有助快速修复的思维。
以语雀意外事件为例说明如何实现“意外事件助推避坑”：
- 稳态假说：华东地区生产环境存储服务器被某种原因下线后，在重新上线之前，存储服务器事件点可隔离，即不影响前端应用正常使用，且前端应用仍可向用户报告整个系统现状。
如何撰写“意外事件避坑指南”：
- 反模式：缺少上下文、使用术语且不做解释、缺乏意外事件确切的影响数据、缺乏触发因素的底层细节描述、缺乏意外事件恢复的细节描述、缺乏可验证的预防措施、具有指责意味、分享范围有限、延迟发表。
- 模式：提供上下文、解释术语、提供意外事件确切的影响数据、提供触发因素的底层细节描述、提供意外事件恢复的细节描述、提供可验证的预防措施、不具有指责意味、分享范围广泛、及时发表、数据驱动结论、提供图表辅助说明、简明扼要。
针对分布式计算的八大谬误进行“可避坑”演练：
- 网络可靠 -> 依赖可靠
- 延迟为零
- 带宽无限
- 网络安全
- 拓扑不变
- 一人管理
- 传输免费
- 网络同构
总结：
- 当前生产事故复盘实践的三大缺点是复盘报告分享难、演练考试非考验、缺乏亲身体验感。
- 这给做软件的人带来难被认可、心里发虚、很快遗忘的痛点。
- “意外事件助推避坑”具有领导更认可、更多人学到、练过心不慌、印象更深刻的四大价值点。
- 实现“意外事件助推避坑”的原则是预防虽重要，难免遇意外；修复意外时，系统仍可用；不去指责人，实操印象深；利他且易懂，领导更认可。
- 业界普遍缺乏“可隔离”、“可替换”和“可避坑”这三种有助快速修复的思维。
