良好事后回顾的特征和组成部分
现在，你了解了事后回顾的定义及其在响应过程中的角色，还了解了应在何时进行事后回顾。 在本单元中，你将稍微深入地详细了解使得事后回顾有效的因素。
由于时间各有不同，事后回顾的具体组成部分也可以有所不同。 但是，良好的回顾过程有一些共同的特征和组成部分，可以为你提供执行该过程的坚实基础。
事后回顾不是什么
在了解构成良好事后回顾的特征之前，应该考虑它不是什么。
- 它不是文档或报告。 “回顾”很容易被理解为书面总结，确实，事后回顾通常会得出一份总结报告。 但是，它们是事件响应生命周期的分析阶段中两个不同的组成部分。
- 它不是确定原因的过程。 回顾会涉及考量造成故障的因素，但目的并不是找到原因（尤其不是单个根本原因，因为复杂系统的故障几乎总是众多因素共同作用的结果。） 其目的是思考并共享有关事件各个方面的信息，以便进行学习和改进。 它不是一个操作清单。 你最终也许会由在回顾中学到的教训而得到这样的清单，但这并不是重点所在。 即使最后没有得到待办事项清单或 bug 报告，只你要比以前更了解系统，回顾就是成功的。
事件回顾的重中之重是对话。这是一个确定的空间，你的团队可以在其中回顾当时和现在所了解的情况，探索并更好地了解系统的各个部分（包括人力部分）是否能够协同工作来响应问题。
特性和组成部分
正如上一单元中提到的，事件回顾不能包含指责。虽然需要检查系统中的人是如何与系统交互的，但其目的不在于为任何人贴上“犯错了”的标签。重点关注的应该是技术和流程的故障，而不是人。
可以限定问题来反应这一点，例如：
- 在我们的监视中有什么不足，让键盘操作员没有获得必要的上下文来作出正确的决定？
- 工具中为什么会有‘销毁整个数据库’这个选项？
- 更有甚者：工具在执行此操作之前为什么没有要求确认？
当出现问题时，你可能不禁想指责别人。 但是，必须记住这一要点：
不能靠解雇员工来实现可靠性。
侮辱、指责或者以找到并解雇“责任人”为目标的调查并不能提升系统的可靠性。 相反，它会让你得到一个由缺乏经验甚至不敢做事的人组成的空壳操作团队。
回顾应以搜寻知识或上下文（而不是找出谁做了什么并就此作出反应）为目标。
尽管回顾的重点在于查明技术缺陷，但其过程需要更关注人而不是技术。 与事件涉及的人员对话，更重要的是倾听他们的观点。 保持思想开明。 不同的人有不同的观点，并非每个人都会同意，而这种观点的混合对于学习过程而言是无价之宝。
时候回顾时一种真诚的询问。 因此，它包含以下关键组成部分：
- 讨论 (Discussion)
- 公开 (Discourse)
- 异议 (Dissent)
- 发现
这“4 个 D”创建了一个框架，你可以在这一框架的基础上构建事后回顾，从而得到更可靠的系统和更高效的协作团队。
在下一单元中，我们将详细介绍可以遵循怎样的过程来实现更有效的事后回顾。