如何优雅的完成一次事故复盘【转载】
对于如何主导一次事故复盘很有讲究和方法。对于主导事故复盘的人我们这里称其为“复盘owner”：有的公司是QA，有的公司是测试、开发或者其他角色来承担。
复盘owner仅仅是个会议记录仪：参会的各个角色讨论，owner无法发表任何意见。
复盘到的原因不是根本原因：表面原因，解决不了问题。
主体责任方搞错了：后面又要拉起第二次复盘。或者一味的去追责任方的责任，而忽略了事故本身的原因分析。
改进措施非常难以落地：比如改进措施严重依赖人的自觉，或者实施高复杂度的流程。
复盘owner对这个产品或项目非常不熟悉。
复盘前对情况一无所知，完全不知道是什么影响，什么问题。
对原因没有刨根究底，或者被参加复盘的某个角色单方面误导了，导致没有挖掘到根本原因。
没有拉对人参会，比如有时候要拉入当事人的直接领导，甚至更高层的领导。
设计改进措施的时候，过度依赖人本身的自觉性或能力，没有考虑自动化。
是否有录单事故单，先要求录单责任人（运维、客服：不同公司有不同的要求）把事情发生经过写清楚。
找客服或产品运营同事确认具体的影响（事故越大，越要确认清楚，参见“了解事故影响小贴士”），找运维和涉及的开发问原因，根据原因涉及到的干系人及其部门，来定确定需要拉的非本产品或项目的人员和对应的复盘负责人。
对事故的关键原因做个初步判断，便于会上引导原因分析。
复盘会要拉上的人有（根据实际情况裁剪）： 责任方人员（可能是：产品、测试、开发、运维等），责任方人员的直接领导，产品受影响方的开发（产品、测试等），产品受影响方的开发（产品、测试等）的领导，产品受影响方的“事故接口人”，根据严重情况有可能要拉上部门经理。
了解事故影响小贴士
影响的表现是什么：在用户端表现出来是什么操作或什么服务受到了什么影响。
影响的范围是什么：是所有用户还是特定用户，是必现还是有几率出现。
影响是如何恢复的：用户不需要任何操作直接恢复，还是需要一定的操作后才能恢复，例如重启，清缓存操作等。
事故恢复后是否还可能存在其他服务的受损：例如历史记录被清空，信息或列表被清空等。
会议现场：引导大家按照顺序进行复盘。顺序如下：
review事故发生过程——> 事故原因讨论——>改进措施讨论——>定级定责——>总结陈词。
注意对以下事项的把控和确认：check影响范围和时长，定级，原因是否ok，改进措施是否可以落地，改进措施落地时间。
原因的追溯：多问几个为什么，尤其对一些明显看起来打太极的人。
会议结束：记得简单清晰概括原因、责任人、改进措施等，不要留存模糊的地方。
跟进开发在事故单系统（如果没有系统，则通过邮件方式提供）里面把改进措施写清楚。
两天内出具事故报告，发送给参会人员，并抄送与这个事件相关的人，或者关注这事件的领导。
跟进改进措施是否按时落地，并进行记录和定期更新完成状态。
对于跨部门的事故，由事故的责任方主导事故复盘，如果你负责的产品或项目团队不是责任方，那么催促对方团队的事故接口人尽快拉起，并提供自己方的干系人，并积极参加复盘会。
要确认的信息在会上都确认清楚，不要等会下再来重复确认。
注意控制会议时间，不要太长。另外，说话语气要肯定。
对跨部门的事件复盘注意引起共鸣，复盘会上还在注意氛围与节奏的把控，不要让复盘会变成追责讨论会。
-
发出复盘报告要检查的几个点：检查标题 ，检查正文是否通畅，是否有错别字。
无论如何，能否有效复盘，并且通过复盘能挖掘出产品或项目的真实问题，“复盘owner”起到重要作用。
要做好事故复盘，“复盘owner”要做到的关键点：复盘前心中有数，拉到合适的人参加复盘会，复盘中按照步骤引导复盘，复盘后跟进措施落地。