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

先进做法经验交流发言稿范文_优质事件上报经验做法_典型经验做法范文

常在河边走,哪能不湿鞋?日常工作中,总会遇到产品在正式使用过程中出故障,导致功能出现缺陷或者信息暴露等等问题。无论大公司或小公司,例如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

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

经验总结

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

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

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

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


本文由转载于互联网,如有侵权请联系删除!