什么是事后回顾？
我们在此学习路径所含的一个前置模块中提到过，但这里再次快速回顾，事件的生命周期如下所示：
事件将经历以下几个阶段：
- 检测：首次发现存在问题时（理想情况下，是在客户通知或投诉之前，在我们的监视系统中发现）；
- 响应：立即进行操作，按照事件响应流程，尝试会审情况并进行紧急响应。
- 修正：努力确定问题，并努力使系统或服务恢复正常运行。
- 分析：事件发生后，尝试从经验中学习，也许可以确定系统或流程中需要改变之处。
- 准备情况：根据汲取的教训进行更改，以提高可靠性并改进相关上下文（流程等）。
本模块的主题大部分都发生在分析阶段。 我们进行事后回顾以从事件中汲取经验。
每次重大事件后都应进行事后回顾。
尽管正式回顾发生在响应和补救阶段之后，但在收到事件发生的可操作警报时就要立即为分析铺路，通知团队成员，并开始围绕事件进行对话。
定义事后回顾
并非每个人都使用完全相同的语言来表示这一过程。 有些人称之为：
- 事后回顾
- 事后学习回顾
- 事件调查报告
- 追溯
在此模块中，我们将使用术语“事后回顾”。
此外，并非每个人都以完全相同的方式进行事后回顾。 例如，许多人会先将与事件有关的所有人聚到一起，而其他人会选择通过单独访谈来创建回顾报告，然后再报告给群组。
如果组织中的团队架构使得难以召开单个大型会议，后一种方法通常效果更好。 例如，如果各个组的活跃性、个性和跨时区团队的分散性会妨碍这种集会，那么使用另一种方式来进行回顾可能会更容易。 应该采用最适合你的团队和环境的方式。
无论你怎么命名、怎么组织这一过程，都有三个要点：
- 应尝试让事件响应中涉及的所有人参与事后回顾。 包容所有人的意见非常重要，因为不同的人对同一件事会有不同的观点和记忆。
- 应在事件发生后的 24 到 36 小时内进行事后回顾。 神经科学已经确认人类记忆相当不可考：人是健忘的。 事件之后经过的时间越久，能想起的细节和具体回忆就越少。
- 事件评审不能包含指责。 我们将在下一单元中详细介绍这一点。
事后回顾的目的
事后回顾的目标是让你的团队能够学习和改进。 你需要了解系统，还要了解你准备的措施中哪些有效、哪些无效，才能进行改进。
同时，应当记住，你生成的操作项（报表、任务、bug 报告、票证、反馈）很有用，但并不是回顾过程的核心，核心在于学习和改进。 生成操作项列表最多是第二目标。