管理百科

互联网人故障复盘流程

时间:2021-04-08  作者:admin   阅读:  

  编辑导语:我们在日常工作中很多时候都需要复盘,特别是在完成一个项目或者遇到技术问题时,复盘可以更好的解决问题,避免后续再次发生,也能得到很多经验;本文作者分享了关于互联网人在遇到故障时的复盘流程,我们一起来了解一下。

   一、为什么要做故障复盘

  互联网产品的更新迭代是非常快的,很多公司推崇敏捷开发,固定每周一个小版本,2周一个大版本的节奏,紧急线上问题、政策限制、实时热点(如新疆棉事件)还需要加急发布。

  频繁的变更过程就难以避免不出故障,“常在河边走,哪能不湿鞋”。

  规范的流程和高超的技术只是减少故障的发生频次,故障难以避免;出了故障后,为什么要做故障总结呢?

   复盘成长,这是最主要的价值。吃一堑长一智,通过复盘总结教训,后期工作中规避问题再发生; 组织过程资产沉淀,故障总结文档可以作为部门的组织过程资产为他人提供前车之鉴,新人入职或新接手项目后可以快速了解之前发生过什么,自己如何重蹈覆辙; 给老板交代,出了问题后,尤其是线上生产问题,影响大的时候要逐层汇报,有故障复盘,过程清晰明了,沟通效率更好; 给业务交代,产品Bug、系统故障往往会造成业务损失,要摆好姿态,厘清权责,给业务一个态度和交代。 二、什么情况下做复盘

  很多人不愿意做复盘,出来问题修复后,想着是能不让别人发现尽量不让别人发现;否则背着Bug后绩效C、D没跑了,或者是“懒”,“好了伤疤忘了疼”。

  故障和绩效各家公司的标准不一样,有的公司推崇的文化是鼓励员工主动复盘,但对个人而言,复盘更多的是自己的事情。

  以下情况都可以做复盘:

   产品变更发布后,产生Bug; 未做变更但产品或服务突然不可用(系统攻击、或机房故障); 操作故障,如产品、运营、研发在使用产品时的操作引发的隐在问题; 产品或服务遭到舆论导向的客诉; 误操作,由于未按照流程、没看清楚、没确认好等无心操作,带来的人为故障; 复盘时间要求:1个工作日以内(24小时),趁热打铁,凉了就没那么“刻骨铭心”了。 三、故障复盘形式

  按照故障影响范围和对业务造成的损失,每个公司都会对故障进行定级,以电商公司为例,可能会用损单量指标作为故障分级的标准。

  计算公示:

  损单量=故障持续时长*昨日(或上周同期或近七日日均)同时段平均订单,到小时或者分钟级别。

  故障级别和损单量的关系与公司业务量级以及对故障的容忍度有关。示例如下,P0为最高级故障。

   1. 会议复盘

  P0、P1级故障,典型故障、业务比较关注呼声较高的,可以组织会议复盘,当面沟通效率更高、能快速平息故障,解决问题。

  参会人员:当事人及其leader 必须参加,产品经理、开发、产品开发负责人、业务同事及其Leader,关心故障问题的老板们。

  会议纪要:复盘会议结束后,要形成会议纪要邮件发送参会人及其他周边干系人,会议内容参考复盘总结模板部分。

   2. 邮件复盘

  P2~P3故障,影响范围小,业务关注度低的可以采用邮件复盘的方式,把复盘过程邮件抄送相关方,如当事人leader 必须参加,产品经理、开发、产品开发负责人、业务同事及其Leader,关心故障问题的老板们。

   3. 文档复盘

  P4及以下故障,业务影响很小,团队内做好复盘文档沉淀,作为组织过程资产存档。

   四、复盘总结模板 1. 故障标题

  【故障级别】+日期+业务描述+故障简介+复盘总结+责任人,方便信息同步,如很多新闻用XX事件,七一五事件等。

  例如:【P0故障】20210401-小程序金刚位页面跳转异常-复盘总结-张三。

   2. 故障影响

  为什么把故障影响放到最前面?故障复盘内容一般会比长,尤其是老板们每天看的邮件、汇报很多,没时间把所有内容全部读一遍的,把故障影响提前告诉他们,他们自己心里有杆秤,要不要继续关注和跟进下去。

  故障影响,一般是描述故障带来的业务损失、产品、用户体验损失等多维度的影响分析。

   3. 事件回顾

  从故障开始、发现、修复、修复完成的详细过程,需要包含When、Who、Where、What,即什么时间,谁,做了什么事情,目的是;通过详细的过程描述,方便发现故障和处理故障过程中暴露出的问题,作为后续改进的依据。

  例如:

   yyyy-M-dd hh:mm 故障因xx开始 yyyy-M-dd hh:mm 运营张三发现故障 (或收到监控报警) yyyy-M-dd hh:mm 张三把问题反馈给开发李四 yyyy-M-dd hh:mm 李四验证发现问题确实存在,企业微信拉群,并通知上级领导报备故障 yyyy-M-dd hh:mm 李四通过代码、监控日志找到问题所在,确认影响范围及故障发生时间点 yyyy-M-dd hh:mm 李四定位问题后,通知上级领导及运营张三准备做回滚(代码修复),预计XX时间完成 yyyy-M-dd hh:mm 李四确认问题已修复,群内同步 yyyy-M-dd hh:mm 张三确认问题已修复,故障处理已结束 故障从XXX-XXX持续时长:XX小时XX分 4. 故障原因

  分析总结故障发生的原因,以上述案例为例,

  1)故障发生前导致故障的原因

  首先是为什么出现这个线上Bug,代码质量,开发自测、QA测试、产品验收为什么没发现?是没有自测还是测试用例执行不充分?

  2)故障发生后运营上报的原因

  上线流程是不是不合理,监控是不是没覆盖?

  3)故障处理过程耗时

  定位问题慢的原因?

   5. 故障总结 故障发生暴露的问题; 责任认定,目的主要是厘清故障产生各相关者的权责关系,方便后期跟进改进。 6. 改进计划

  根据故障复盘发现的问题,制定出可实施的改进计划。日后同类型的错误自己及相关的同事都去避免发生改进计划包括todolist、跟进人、deadline。

  改进计划可以包含但不限于:

   经验总结、知识分享; 监控覆盖; 系统或工具设计改造类; 流程类的、规则/规范类的、机制完善类; 系统、业务需求改造类的。 五、小结

  出问题不可怕,可怕的出问题不复盘,同样的问题重复犯。

  不管公司怎么要求,复盘和成长是自己的事情,成长的过程犯错误交学费在正常不过。

  作者:千冰仪,微信号公众号:数据干饭人,主要从事数据中台产品体系建设,包括:开发套件、数据资产、BI应用、精准营销平台、机器学习平台等。

  本文由@数据干饭人 原创发布于知乎网,未经作者许可,禁止转载。

  题图来自Unsplash,基于CC0协议


标签: 政策法规
声明:本站资源收集自互联网,只提供学习参考,任何人不得用于商业或者非法用途,如果本站资源侵犯到您的权益,请来信告知,我们核实后将及时处理。

我们提供国际在职博士招生简章,经验技巧等,您的给力支持,就是我们最大动力。如您有更好的建议,欢迎您与我们联系。

侵权联系侵权联系:QQ382512274 沪ICP备10038544号-3