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

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