上篇文章说到了如何给事故定性，那么这篇我们继续聊聊事故复盘那点事。当事故发生时，我们修复了潜在问题，系统恢复到其正常运行状态。除非我们真正的复盘并采取行动，否则它们可能会无限重复。如果不加以控制，事件的复杂性可能会成倍增加，甚至会反应连锁反应最终产生极其严重后果，并最终影响到我们的用户。
事故复盘是对事件描述、分析其影响、为减轻或解决该问题而采取的措施、并分析根本原因以及防止该事件再次发生的后续行动的书面记录，最终的目的是从事故中吸取教训。
发起事故复盘的原则
事故复盘的主要目的是确保事故被记录在案，团队成员充分理解所有导致事故的根本原因，并采取有效的预防措施，以减少再次发生的可能性和或影响。根本原因分析。写一份事故复盘并不是惩罚，而是整个提供给整个团队一次学习的机会。发起事故复盘确实有一定的成本，团队内部可以灵活应对，但常见的进行事故复盘时机包括：
- 用户可感知到的产品部分或者全部功能不可用。
- 某个影响核心体验指标查过阈值。
- 数据丢失对业务产生深远影响。
在事故发生前确定复盘标准是很重要的，这样团队内部的每个人都知道什么时候有必要进行事故复盘。除了这些客观触发因素外，任何合作相关方都可以要求对某些特定的事件进行复盘。
把每一次事故当做学习的机会
著名电商Etsy的CTO在他的Blog上发表过一篇文章，题目是“Blameless PostMortems and a Just Culture”, 阐述Blameless PostMortems的重要性和实施方法。该CTO是John Allspaw，他是非常著名的演讲Velocity上《10 deploys per day- Dev & Ops cooperation at flickr》的两个主讲人之一。他在该博文上描述在他们Etsy公司进行Blameless PostMortems的做法和思考。他解释到：在事故回顾中，希望涉及的工程师能给出现场的详细信息，便于发现系统弱点或者流程缺失之处，详细信息包括如下内容：
- 他观察到了什么现象
- 他做出什么样的判断
- 他采取什么样的行动
- 行动得到什么样的结果
这些信息都只有在不害怕被惩罚的情况下才能详细的给出。因为认为自己将受到谴责的工程师没有动机去提供必要的详细信息，以了解该事故的详细原因。而如果对事故如何发生的了解不足，换一个人还会继续发生。所以该办法并不是保证工程师犯错误可以免除惩罚，而是更关注获得重要现场信息来持续对系统进行改进，避免错误重复发生。因为他相信，能获得真实的一手信息来诊断并确保事故不在发生，比起指责甚至处罚事故负责的工程师，对公司的长久利益更重要。
一个简单可执行的复盘通常包含以下几个内容
- 务必客观的阐述现象。
- 回顾应对方案。
- 确定影响范围。
- 分析根本原因
- 梳理新的机会点以及寻找新的模式或者机制
- 产出明确的行动计划并采取行动
参与复盘的同学在一个开放的环境以平衡的视角参与复盘，复盘的同学尽量详细的阐述发生事故的现象。以时间顺序对事故进行多维度的描述，主要包括当时的环境、应对思路、应对方案以及后续的行动计划。
关于根因以及应对
通常一个事故发生可能引起一系列的连锁反应，分清问题的主次是这个步骤的关键。分析根因的过程最终都会止于一系列的假设和既定的流程，那么我们的假设正确吗？是流程问题还是架构问题？难道真的是粗心大意吗？可以通过架构问题解决粗心大意问题吗？
参考文档：
Postmortem Culture: Learning from Failure
sre.google/sre-book/po…
如何做一次高效的事故复盘？
www.sohu.com/a/471206153…
