如何优雅的完成一次事故复盘【转载】

对于如何主导一次事故复盘很有讲究和方法。对于主导事故复盘的人我们这里称其为“复盘owner”:有的公司是QA,有的公司是测试、开发或者其他角色来承担。

复盘的几个误区

0?wx_fmt=gif&wxfrom=5&wx_lazy=1

  1. 复盘owner仅仅是个会议记录仪:参会的各个角色讨论,owner无法发表任何意见。

  2. 复盘到的原因不是根本原因:表面原因,解决不了问题。

  3. 主体责任方搞错了:后面又要拉起第二次复盘。或者一味的去追责任方的责任,而忽略了事故本身的原因分析。

  4. 改进措施非常难以落地:比如改进措施严重依赖人的自觉,或者实施高复杂度的流程。

走入误区的原因


0?wx_fmt=gif&wxfrom=5&wx_lazy=1&retryload=1


  1. 复盘owner对这个产品或项目非常不熟悉。

  2. 复盘前对情况一无所知,完全不知道是什么影响,什么问题。

  3. 对原因没有刨根究底,或者被参加复盘的某个角色单方面误导了,导致没有挖掘到根本原因。

  4. 没有拉对人参会,比如有时候要拉入当事人的直接领导,甚至更高层的领导。

  5. 设计改进措施的时候,过度依赖人本身的自觉性或能力,没有考虑自动化。

事故复盘的正确打开姿势



复盘前:对事故过程和原因心中有数640?wx_fmt=png


是否有录单事故单,先要求录单责任人(运维、客服:不同公司有不同的要求)把事情发生经过写清楚。


找客服或产品运营同事确认具体的影响(事故越大,越要确认清楚,参见“了解事故影响小贴士”),找运维和涉及的开发问原因,根据原因涉及到的干系人及其部门,来定确定需要拉的非本产品或项目的人员和对应的复盘负责人。


对事故的关键原因做个初步判断,便于会上引导原因分析。 


复盘会要拉上的人有(根据实际情况裁剪): 责任方人员(可能是:产品、测试、开发、运维等),责任方人员的直接领导,产品受影响方的开发(产品、测试等),产品受影响方的开发(产品、测试等)的领导,产品受影响方的“事故接口人”,根据严重情况有可能要拉上部门经理。


了解事故影响小贴士

  • 影响的表现是什么:在用户端表现出来是什么操作或什么服务受到了什么影响。

  • 影响的范围是什么:是所有用户还是特定用户,是必现还是有几率出现。

  • 影响是如何恢复的:用户不需要任何操作直接恢复,还是需要一定的操作后才能恢复,例如重启,清缓存操作等。

  • 事故恢复后是否还可能存在其他服务的受损:例如历史记录被清空,信息或列表被清空等。


复盘中:控场复盘会议640?wx_fmt=png


会议现场:引导大家按照顺序进行复盘。顺序如下:

review事故发生过程——> 事故原因讨论——>改进措施讨论——>定级定责——>总结陈词。


注意对以下事项的把控和确认:check影响范围和时长,定级,原因是否ok,改进措施是否可以落地,改进措施落地时间。


原因的追溯:多问几个为什么,尤其对一些明显看起来打太极的人。


会议结束:记得简单清晰概括原因、责任人、改进措施等,不要留存模糊的地方。


复盘后:事故报告和改进措施落地640?wx_fmt=png


跟进开发在事故单系统(如果没有系统,则通过邮件方式提供)里面把改进措施写清楚。


两天内出具事故报告,发送给参会人员,并抄送与这个事件相关的人,或者关注这事件的领导。


跟进改进措施是否按时落地,并进行记录和定期更新完成状态。


Tips碎碎念
  1. 对于跨部门的事故,由事故的责任方主导事故复盘,如果你负责的产品或项目团队不是责任方,那么催促对方团队的事故接口人尽快拉起,并提供自己方的干系人,并积极参加复盘会。

  2. 要确认的信息在会上都确认清楚,不要等会下再来重复确认。

  3. 注意控制会议时间,不要太长。另外,说话语气要肯定。

  4. 对跨部门的事件复盘注意引起共鸣,复盘会上还在注意氛围与节奏的把控,不要让复盘会变成追责讨论会。

  5. 发出复盘报告要检查的几个点:检查标题 ,检查正文是否通畅,是否有错别字。



无论如何,能否有效复盘,并且通过复盘能挖掘出产品或项目的真实问题,“复盘owner”起到重要作用。

要做好事故复盘,“复盘owner”要做到的关键点:复盘前心中有数,拉到合适的人参加复盘会,复盘中按照步骤引导复盘,复盘后跟进措施落地。

640?wx_fmt=png

展开阅读全文

没有更多推荐了,返回首页