事件响应包括监测、检测和应对安全漏洞或其他服务中断等非计划事件。其目的是恢复业务，满足服务水平协议（SLA），并为员工和客户提供服务。事件响应是对漏洞或中断的计划反应。一个目标是避免无人管理的事件。
建立一个随叫随到的系统
应对的一种方式是建立一个待命系统。这些是在建立待命系统时需要考虑的步骤。
- 设计一个有效的待命系统
- 了解有管理的事件与无管理的事件
- 建立并实施一个有效的事后分析过程
- 学习用于事后分析的工具和模板
了解有管理和无管理的事件
非管理型事件是指由待命工程师处理的问题，通常是由恰好可以提供帮助的任何团队成员处理。更多的时候，非管理事件因为没有得到正确处理而成为严重的问题。问题包括。
- 没有明确的角色。
- 没有事件指挥。
- 随机参与的团队成员（自由职业者），是管理过程的主要杀手。
- 沟通不畅（或缺乏）。
- 没有中央机构负责故障处理。
有管理的事件是指以明确定义的程序和角色来处理的事件。即使是没有预料到的事件，也会有一个准备好的团队来应对。一个有管理的事件是理想的。它包括。
- 明确的角色。
- 指定的事件指挥部，领导工作。
- 只有由事件指挥部定义的行动小组才会更新系统。
- 在确定通信人员之前，存在一个专门的通信角色。事故指挥部可以充当这一角色。
- 一个公认的指挥所，如 "作战室"。有些组织有一个确定的 "作战室桥号"，所有的事件都在这里处理。
事故管理在作战室中进行。事故指挥部是领导作战室的角色。这个角色也负责组织行动小组周围的人，进行规划和沟通。
运营团队是唯一可以接触生产系统的团队。提示：下次你加入一个事件管理团队时，要问的第一个问题是：谁在管理事件指挥部？
更多DevOps资源
深入了解事件管理角色
事件管理角色明确定义了谁负责哪些活动。这些角色应该提前建立，并被所有参与者充分理解。
事故指挥部。管理作战室并将责任分配给其他人。
运营团队。唯一允许对生产系统进行修改的角色。
沟通小组。为利益相关者提供定期更新，如业务伙伴或高级管理人员。
规划团队。通过处理长期项目来支持运营，如提供错误修复，事后分析，以及任何需要规划的观点。
作为一个SRE，你可能会发现自己处于运营团队的角色，但你也可能要扮演其他角色。
建立和实施一个有效的事后分析过程
后验收是事件管理的一个关键部分，它发生在事件解决之后。
为什么要进行事后分析？
- 利用事后分析充分了解/记录事件。您可以提出一些问题，如 "可以采取什么不同的方法？"
- 进行深入的 "根本原因 "分析，产生有价值的洞察力。
- 从事件中学习。这是做事后分析的主要好处。
- 作为事后分析的一部分，确定预防的机会，例如，确定监测的改进，以便在未来更早地发现问题。
- 作为事后分析的一部分，计划并贯彻执行指定的活动。
无责的事后分析：SRE的一个基本原则
不指责。老实说，人们很害怕事后总结，因为一个人或一个团队可能要对故障负责。不惜一切代价避免指责；相反，只关注系统和流程而不是个人。孤立个人/团队会创造一种不健康的文化。例如，下次有人犯错时，他们不会站出来接受错误。由于害怕被指责，他们可能会隐藏活动。
虽然没有指责的余地，但事后总结必须呼唤出改进的机会。这种方法有助于避免进一步的类似事件。
什么时候需要验尸？
是否所有的事件都需要进行事后分析，还是只在某些情况下需要？以下是一些关于何时需要事后分析的建议。
- 终端用户体验影响超过阈值（SLO）。如果到位的SLO受到影响，由于。
- 不可用的服务
- 不可接受的性能
- 功能不稳定
- 数据丢失。
- 组织/团体的具体要求，有不同的政策和协议需要遵循。
事后调查所需的六个最低项目
事后分析应包括以下六个部分。
- 摘要：提供一个简洁的事件摘要。
- 影响（必须包括任何财务影响）。高管们将寻找影响和财务信息。
- 根本原因。如果可能的话，找出根本原因。
- 解决方案。团队实际做了什么来解决这个问题。
- 监测（问题检测）。具体说明该事件是如何被发现的。希望这是一个监控系统，而不是一个最终用户的投诉。
- 带有到期日期和所有者的行动项目。这很重要。不要简单地进行事后总结而忘记事件。建立行动项目，指定所有者，并跟进这些行动。一些组织还可能在事后总结中包括一个详细的事件发生时间表，这对了解事件的顺序很有用。
在公布事后总结之前，主管或高级团队成员必须审查该文件，以避免任何错误或对事实的误导。
寻找事后总结的工具和模板
如果你以前没有做过事后分析，你可能想知道如何开始。到目前为止，你已经学到了很多关于事后分析的知识，但你如何真正实施一个？
这就是工具和模板发挥作用的地方。有许多可用的工具。请考虑以下几点。
- 你的组织中现有的ITSM工具。流行的例子包括ServiceNow、Remedy、Atlassian ITSM，等等。现有的工具可能提供事后跟踪功能。
- 开源工具也可以使用，最流行的是Morgue，由Etsy发布。另一个流行的选择是PagerDuty。
- 开发你自己的。记住，SRE也是软件工程师!它不必是花哨的，但它必须有一个易于使用的界面和可靠地存储数据的方法。
- 模板。这些是你可以随时用来跟踪你的后验的文件。有许多模板可用，但最受欢迎的是。
总结
以下是上述事件响应讨论的关键点：
- 有效的待命系统是必要的，以确保服务的可用性和健康。
- 平衡随叫随到的工程师的工作量。
- 分配资源。
- 使用多区域支持。
- 促进一个安全和积极的环境。
- 事故管理必须促进明确的职责分工。
- 事故指挥、操作、计划和沟通。
- 无责的善后工作有助于防止事件重复发生。
事件管理只是等式的一个方面。一个SRE组织要想有效，还必须有一个变化管理系统。毕竟，变化会导致许多事件。
