怎样写好事故报告,并且做好经验复用与分享?

浏览量:10 次

我只想知道将来我会死在什么地方,这样我就永远不去那儿了。

常在河边走,哪能不湿鞋?日常工作中,总会遇到产品在正式使用过程中出故障,导致功能出现缺陷或者信息暴露等等问题。无论大公司或小公司,例如2017年12月7日美团外卖重复支付bug,2018年6月27日下午阿里云挂了长达2时,2019年1月3日,艺考报名系统“艺术升”APP持续崩溃、闪退,导致数十万艺考生无法报名。

在事故来临时,我们积极应对,处理完事故,后面的事情同样重要。作为产品相关人员,撰写一份优秀的事故报告,做出经验总结,落地执行改进措施,既能有效避免同类事情再次发生,又能提前消灭其他隐藏的危险。

事故报告内容结构

事故报告基本可以分为五大模块:标题、事故描述、事故处理、事故责任人、经验总结。其他诸如处罚、资料附件等等根据实际需要添加。下面,我以真实事件为原型,模拟一个事故来作为例子描述。

标题

标题:XX系统响应崩溃事故报告

说明:直接点名主题;或准确指明事故具体名称+事故报告

事故描述

这里我们应用记述六要素,时间、地点、人物、起因、经过、结果。

时间:2018年12月3日10:00—2018年12月4日00:00

地点:全国各区域用户(无区域性的事故,可去掉本项)

人物:产品用户(有些事故由于人为操作不当导致,需加上相关人物。)

起因:2018年12月3日上午10点,官网活动开始,用户大量进入APP,每秒最大并发连接数1.98万,随后,其他活动也开始举行,并发数保持高峰。由于排队人数过多,服务器的响应能力严重不足,导致系统出现了拥堵。

经过:2018年12月3日10点,官网活动开始,用户大量进入APP,每秒最大并发连接数1.98万,上午11点,每秒最大并发连接数2万;系统报警,开发人员XX紧急检查……

随后,A、B、C三大活动方活动也开始举行,并发数保持高峰,2018年12月3日12点,每秒最大并发连接数2.5万。

2018年12月3日18点,所有活动方均已开始举行活动,每秒最大并发连接数5.7万。

……

以上为各重点节点描述,本文不再赘述。

说明:简要描述各个重要时间节点,还原事件经过,让查看的人有清晰的事件发展路线,如有相关数据图表,也应加上。

结果:2018年12月3日10:00起-2019年12月4日00:00,期间APP持续崩溃、闪退,导致所参与的200万用户提交请求出现失败。12月4日凌晨,APP恢复正常。

说明:结果描述需要具体、真实并且包含影响范围。

事故处理

2018年12月3日10:00,系统报警,开发人员XX紧急检查,并联系相关负责人汇报情况……商讨方案……马上申请调用服务器…..组织进行架构优化……由于之前系统在线排队用户较多,消化用户队列需要一段时间,此过程用户体验略慢,截止12月4日凌晨,所有页面与App己完全恢复正常,目前系统稳定。

说明:事故处理需要描述从开始导处理完毕的过程,可用于复盘,若有发现处理过程不足的地方,可备后续改进,优秀的经验可用于分享。

事故责任人

产品负责人XXX

技术负责人XXX

说明:根据实际情况填写负责人,以便进行追责、改进等等工作。

经验总结

本次事故突出了我们系统人员在前期系统流量冲击预估不足,没有紧急扩充服务器方案。

说明:一次事故,表面的原因可能是是一行代码写错,一个失误、一个忽视。但实际上暴露的产品研发流程规范、制度规范、人员安全意识等等,这些才是我们后续需要重点解决的,很多时候,事故报告被当作一种形式化的文档。

甚至,有部分公司也根本不需要写事故报告,解决问题后就不管了,没有进行后续的跟进总结。事故一次次发生,无论产品或者人员没有从这一次次的事故中吸取教训、取得进步。

以上为事故报告的内容构成,事故报告之外,经验复用、分享同样重要。

经验复用与分享

经验复用

产品内部:每一个事故都不是偶然的,造成的原因不是唯一,在其他地方往往也存在问题。例如:产品某个接口暴露敏感信息,我们也应该同样检查类似接口,避免其他接口也出现同样的问题。

其他产品:在一家公司中,往往产品研发流程、制度规范大部分一致,若是由于流程不完善,此时不应该只对出问题的产品线进行优化,在做出改进措施后,应当将其延伸复用到其他产品线,避免其他产品线出现同样的问题。

经验分享

这里我们参考万达内部培训方法《11130教学法》来对我们的经验进行分享。“11130”的含义是:1个业务问题;1个实际案例;1个解决方法;30分钟讲解。

1个业务问题+1个实际案例:两者避免了我们之前在做经验分享时内容大而全、不聚焦、无重点导致受众根本记不住的问题。专注一个或一类业务问题,彻底分析,举一反三,全面解决问题。实际发生的案例,我们印象更为深刻,也更加容易产生联想,用工作中实际发生的案例来呈现问题,呈现解决方法,问题实,方法实,有价值。 1个解决方法:复盘后,我们根据实际问题,制定最好的那个解决方法,只分享最好的,不累赘,更有利于大家吸收,反思自己所负责的产品。 30分钟讲解:平时大家工作任务重,所以对于这种经验分享,事故总结会议总是心存排斥,30分钟只是一个概念,如果一个问题可以讲透,可以缩短到20分钟、15分钟甚至10分钟。30分钟讲解,让分享可以灵活安排在部门例会后或问题发生的现场。根据不同情况,时间也可以适当延长,但我们尽量在短时间内把问题讲透。

通过《11130教学法》,我们可以快速学习,特别是互联网行业,在这个快速迭代更新的世界,我们也需要快速更新我们的知识。重大的事故,带来的负面影响往往很大,但是随着带来的教训与经验也往往更多,我们需要将这些解决问题的方法与经验得到快速的沉淀,转化为企业资产。

以上,通过回顾事故,做出总结,将经验进行复用与分享,相信我们能够做到不重复踩坑!

最后分享投资大师查理芒格最喜欢的一句谚语:

我只想知道将来我会死在什么地方,这样我就永远不去那儿了。

 

作者:彬go,微信公众号“有个思享”,专注读书与产品心得分享,欢迎交流。

本文由 @彬go 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

 
®关于本站文章™ | 若非注明原创,默认 均为网友分享文章,如有侵权,请联系我们™
㊣ 本文永久链接: 怎样写好事故报告,并且做好经验复用与分享?