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