事件响应的重要性
在此学习路径上另一个模块中讨论的监视的原则和实践的基础上，你现在将了解监视发现问题时应采取的措施。 如果收到可操作警报，告知你的系统没有按预期运行，这就将触发处理问题的响应。
什么是事件？
事件响应是指事件发生时你执行的操作，但究竟是什么构成了事件？ 这一问题的答案可以是主观的；即使是所有工程师都没有对什么是事件达成一致的见解。 如果在不同的行业和组织中提出问题，则会得到许多不同的答案。
有些会将所有中断标记为事件，无论客户是否受到影响。 我们同意将事件定义为服务中断，即对用户使用其所依赖的服务的能力产生影响的事件或情况。 例如，系统崩溃或者出现会影响到客户的故障时。
什么是事件响应？
预防所有问题是一个值得称赞，但却不可能实现的目标。 事情总将出现问题，因此，我们需要一个计划来限制对最终用户造成的影响，并尽快回到正常的操作状态。
关键在于作出紧急应对，而不是被动反应。 反应往往更具脉冲性并且基于当下，而不考虑长期效应。 响应是经过深思熟虑、经过组织且基于信息的行为。
事件响应方法确定了你在以下方面的效率：
- 了解出现的情况（诊断问题）。
- 会审（确定紧急程度）并确定问题的优先级。
- 使用合适的资源来缓解问题。
- 就该问题与利益干系人交流。
修正问题后，可以通过事后回顾过程来从事件中吸取教训。 这是一个重要主题，我们有一个完整的单独模块来对此进行探讨。
度量事件响应性能
你可能熟悉 TTR 这一首字母缩写词，它有着不同的定义，如“恢复时间”、“修正时间”或“还原时间”。所有这些变体指的都是同一内容：使服务恢复到能满足客户预期的状态所需的总时间。
此指标是衡量响应事件时团队表现好坏的一种方法。 恢复/修正/还原服务的速度越快，服务中断或降级所造成的影响就越小。
请务必了解你的组织处理事件响应的能力。 每年，DevOps 研究和评估组织 (DORA) 都会发布“DevOps 的状态”报告。 2019 年报告中的一些主要发现重点关注了事件响应性能。
- 此报告将可以在不到 1 小时的时间内检测到服务中断、做出响应并修正服务中断的工程团队分类为“精英或高水平执行者”。
- 能够在 24 小时内从事件中恢复的工程团队被分类为“中等水平执行者”。
- “低水平执行者”则是指在 1 周到 1 个月的时间内从服务中断恢复的工程团队。
这些级别之间的差异是十分显著的。 研究发现，与“低水平”同行团队相比，精英/高水平执行团队从事件中恢复的速度要快 2,604 倍。 精英/高水平执行者执行部署到生产的频率也要多 208 倍。
与其他执行者相比，精英执行者执行响应和恢复的速度为什么要快那么多？他们是如何做到的？ 至少部分原因是因为他们了解当问题不可避免地出现时准备好一个良好的基础响应计划的重要性。
在学习本模块的过程中，你将了解事件的特征和生命周期，以及如何使用所掌握的知识来创建自己的基础计划。