众所周知，系统的变化会带来不稳定，进而引发事故。迁移到 DevOps 使世界各地的组织能够以更小的增量和更高的频率进行发布。这降低了特定版本中失败的风险。另一方面，增加发布数量并不一定会减少待命团队需要响应的事件数量。

事件响应团队的主要职责是量化影响，并在必要时减轻影响。结果，服务恢复到正常运行状态。分析根本原因并实施预防措施不属于这个过程。现在，如果不进行这样的学习和分析，根本原因就得不到解决，预防措施也得不到落实。结果是：事件开始成倍增加，级联错误成为每周例行公事的一部分。最终，DevOps 团队花在事件响应上的时间越来越多，服务质量却不断下降。

进行尸检
为了避免这种死亡螺旋，您的团队必须承认需要从过去中学习以建设更美好的未来。这个学习过程称为事后分析（或post-mortem）。每当事件需要值班工程师做出响应时，就应该触发事后分析。典型的事后剖析从记录客观证据开始：

事件的触发因素
事件影响
检测和缓解的时间
采取的缓解措施
根本原因分析
根据上述证据，应该进行分析。分析通常由响应事件的待命团队成员执行，并且可能包括帮助缓解或分析根本原因的其他团队成员。分析过程需要找到以下问题的答案：

扳机。
我们收到了多少关于该事件的警报？
触发是否及时，或者我们可以提前注册吗？
影响
首先，影响是否足以引发事件？或者我们应该校准触发器吗？
是否采取了足够的措施来减轻影响并且是否遵循了流程？如果没有，我们是否需要投资培训或改进指南？
我们是否设法足够快地减轻影响？我们能做些什么来缩短缓解时间吗？
根本原因
根本原因会得到解决还是我们必须忍受它？
如果根本原因得到解决，那么我们到底需要做什么来解决呢？
根据分析，应撰写总结，包括吸取的教训以及登记和确定优先顺序的后续任务。后续任务通常包括：

解决根本原因的工程任务
DevOps 工程师改进监控设置的任务
管理者改进流程的任务
事后分析简介
向一个历史上从未进行过事后分析的组织引入事后分析并不像听起来那么容易。与每个新的或不断变化的流程一样，引入和持续变革需要组织各个级别的时间和精力。但是，有一些关键原则可以使更改变得更容易：

确保远离指责游戏和相互指责。这是让事情顺利进行的最关键的方面。如果分析的重点是指责造成事件的人，而不是确保团队学习和改进，那么这种举措就会造成伤害而不是好处。
指定专职领导，强制执行每个事件响应并进行事后分析。这些人往往来自 DevOps/on-call 团队，而且大多数情况下他们自己就是团队领导。
协作与分享。确保在适合共享和学习的媒介（例如维基）中记录事后分析。使用上个月的事后分析作为团队的定期学习材料。允许在事后分析期间和之后进行协作和评论。
涉及管理。表现出管理层的支持可以使工程师之间的宣传和教育变得更加容易。为了保持管理层的参与，提前制定目标并展示进展情况。你知道，经理们最喜欢的就是向上和向右的图表。
从小事做起。如果组织规模很大，那么从几个服务和一个团队开始就足以构建一个激励其他团队效仿的示例。最初的团队庆祝胜利通常足以让其他团队加入这股潮流。如果没有组织内部的积极榜样，那么引入变革就会困难得多。
事后检查清单
我们准备了一份清单，列出了您需要问自己的问题，以便以尽可能最好的方式进行 DevOps 事后分析。

检测
影响
对最终用户的影响
对生产力的影响
对基础设施的影响
减轻
缓解时间
缓解步骤#1
缓解步骤#2
根本原因分析
得到教训
后续行动
任务#1（检测/缓解/处理）
任务#2（检测/缓解/处理）
任务#3（检测/缓解/处理）