用户
 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,登录网站

小程序社区 首页 资讯/观点 查看内容

互联网人故障复盘流程

Rolan 2021-4-7 00:21

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


一、为什么要做故障复盘

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

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

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

  1. 复盘成长,这是最主要的价值。吃一堑长一智,通过复盘总结教训,后期工作中规避问题再发生;
  2. 组织过程资产沉淀,故障总结文档可以作为部门的组织过程资产为他人提供前车之鉴,新人入职或新接手项目后可以快速了解之前发生过什么,自己如何重蹈覆辙;
  3. 给老板交代,出了问题后,尤其是线上生产问题,影响大的时候要逐层汇报,有故障复盘,过程清晰明了,沟通效率更好;
  4. 给业务交代,产品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协议

鲜花
鲜花
鸡蛋
鸡蛋
分享至 : QQ空间
收藏
原作者: 数据干饭人 来自: 人人都是产品经理
便民服务

400-8826-226

电话服务热线时间:9:00 - 21:00

关注我们

微信公众号