通过从错误中学习是非常重要的一个环节。通过根因分析和事后总结记录清楚失败的情况。
核心不是要一份无用的记录，或者承认错误，指责。
目的是要总结在过程中学的内容的解释或者沉淀，以及学习经验可以作为后续改进落地和其他人借鉴，
要确保故障报告随时可以查阅，并让团队认真贯彻执行，好的故障报告要让其他人知道过去现在和将来发生了什么，避免重复踩坑。

一份结构化的故障报告应该包含几个部分
1.事件的概述
2.事件的时间线，发现，查问题，解决问题
3.原因分析，问题链和责任链
4.影响和损害
5.解决该问题的行动项 执行人 执行完成时间
6.防止发生类似问题的行动项 执行人 执行完成时间 可以采用SMART原则分解行动项
7.学到的经验教训

好的实践

  • 覆盖所有相关方，可以从多个角度去改进问题。
  • bug是难免会发生的，尽量减少低级问题和错误，防止同类型错误，提前发现错误。
  • 过程中控制影响面，处理的及时性，处理流程的正确性，也是非常重要需要审视的环节

差的实践

  • 甩锅文化，分析其他人的问题比较全面，自身分析掩盖或者较少

一份好的模版如下：

:::warning

事件概述

（简要描述事件）

处理过程

（需要描述详细的处理过程，尽量每一个操作、每一次沟通，都做好记录，格式如下）
09:33 XX（客服团队）收到客户反馈XX系统无法使用，表现为………
09:35 XX开始处理问题
09:50 XX进入服务器查看日志
10:10 XX发现故障点
………………..
10:49 故障恢复

原因分析

（表面原因、深层原因，都需要分析）

影响范围

（影响了哪些系统、哪些功能、哪些用户、多长时间）

后续处理

（需要做的后续操作，如系统修改、数据恢复等，仅针对本次事故的善后事宜）

改进方案

（从根本上避免或降低该类事故发生的方案，架构更改、流程改进等）

  • 事前
  • 事中
  • 事后 :::