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

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

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

经验总结

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

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

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

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