SRE 如何实现有效的事件响应

事件响应包括监控、检测和应对计划外事件，例如安全漏洞或其他服务中断。目标是恢复业务，满足服务级别协议 (SLA)，并为员工和客户提供服务。事件响应是对漏洞或中断的计划反应。一个目标是避免不受管理的事件。

建立随叫随到系统

响应的一种方法是建立随叫随到系统。以下是设置随叫随到系统时要考虑的步骤

1. 设计一个有效的随叫随到系统 
2. 理解受管理与不受管理的事件
3. 构建和实施有效的事后分析流程
4. 学习事后分析的工具和模板

理解受管理和不受管理的事件

不受管理的事件是指随叫随到的工程师处理的问题，通常由恰好有空帮忙的团队成员处理。通常，不受管理的事件会变成严重问题，因为它们没有得到正确处理。问题包括

• 角色不明确。
• 没有事件指挥。
• 随机团队成员参与（自由职业），这是管理流程的主要杀手。
• 沟通不畅（或缺乏沟通）。
• 没有中央机构运行故障排除。

受管理的事件是指使用明确定义的程序和角色处理的事件。即使事件不是预期的，也会有一个准备充分的团队来应对。受管理的事件是理想的。它包括

• 角色明确定义。
• 指定的事件指挥领导工作。
• 只有事件指挥定义的运维团队才能更新系统。
• 在确定沟通人员之前，存在专门的沟通角色。事件指挥可以填补这个角色。
• 公认的指挥中心，例如“作战室”。有些组织有定义的“作战室桥接号码”，所有事件都在那里处理。

事件管理在作战室中进行。事件指挥是领导作战室的角色。此角色还负责组织运维团队人员、计划和沟通。

运维团队是唯一可以接触生产系统的团队。提示：下次您加入事件管理团队时，要问的第一个问题是，谁在运行事件指挥？

深入了解事件管理角色

事件管理角色明确定义了谁负责哪些活动。这些角色应提前建立，并为所有参与者充分理解。

事件指挥：运行作战室并向其他人分配职责。

运维团队：唯一允许对生产系统进行更改的角色。

沟通团队：向业务合作伙伴或高级管理人员等利益相关者提供定期更新。

计划团队：通过处理长期项目（例如提供错误修复、事后分析以及任何需要计划视角的事项）来支持运维。

作为 SRE，您可能会发现自己担任运维团队角色，但也可能必须担任其他角色。

构建和实施有效的事后分析流程

事后分析是事件管理的关键部分，在事件解决后进行。

为什么要进行事后分析？

• 使用事后分析充分理解/记录事件。您可以提出诸如“可以采取哪些不同的措施？”之类的问题
• 进行深入的“根本原因”分析，产生有价值的见解。
• 从事件中学习。这是进行事后分析的主要好处。
• 识别预防机会作为事后分析的一部分，例如，识别监控增强功能，以便在未来更快地发现问题。
• 计划并跟进作为事后分析一部分分配的活动。

无责事后分析：SRE 的基本原则

不指责任何人。人们对事后分析感到非常害怕，因为一个人或团队可能要对中断负责。不惜一切代价避免指责任何人；相反，只关注系统和流程，而不是个人。孤立个人/团队会造成不健康的文化。例如，下次有人犯错时，他们将不会挺身而出并承认错误。他们可能会因为害怕被指责而隐藏活动。

尽管没有指责任何人的空间，但事后分析必须指出改进机会。这种方法有助于避免进一步的类似事件。

何时需要事后分析？

是否所有事件都需要事后分析，还是仅在某些情况下才需要？以下是一些关于何时事后分析有用的建议

• 最终用户体验影响超出阈值 (SLO)。如果由于以下原因影响了已有的 SLO
  • 服务不可用
  • 性能不可接受
  • 功能不稳定
• 数据丢失。
• 具有不同策略和协议的组织/团队特定要求。

事后分析中至少需要的六个项目

事后分析应包括以下六个组成部分

1. 摘要：提供简洁的事件摘要。
2. 影响（必须包括任何财务影响）：高管将寻找影响和财务信息。
3. 根本原因：尽可能确定根本原因。
4. 解决方案：团队实际为解决问题所做的事情。
5. 监控（问题检测）：说明事件是如何被识别的。希望这是一个监控系统，而不是最终用户的投诉。
6. 带有截止日期和负责人的行动项：这很重要。不要只是进行事后分析就忘记事件。建立行动项，分配负责人，并跟进这些行动项。一些组织还可能在事后分析中包含详细的事件时间线，这对于回顾事件序列可能很有用。

在发布事后分析之前，主管或高级团队成员必须审查该文档，以避免任何错误或歪曲事实。

查找事后分析工具和模板

如果您以前没有做过事后分析，您可能想知道如何开始。到目前为止，您已经了解了很多关于事后分析的知识，但是您实际上如何实施事后分析呢？

这就是工具和模板发挥作用的地方。有很多工具可用。考虑以下几点

1. 您组织中现有的 ITSM 工具。流行的例子包括 ServiceNow、Remedy、Atlassian ITSM 等。现有工具可能提供事后分析跟踪功能。
2. 也有开源工具可用，最受欢迎的是 Etsy 发布的 Morgue。另一个流行的选择是 PagerDuty。
3. 开发您自己的工具。请记住，SRE 也是软件工程师！它不必花哨，但必须具有易于使用的界面和可靠存储数据的方式。
4. 模板。这些是您可以随时用于跟踪事后分析的文档。有很多模板可用，但最受欢迎的模板是

• Google：事后分析文化：从失败中学习 和 事后分析示例
• Pagerduty：事后分析
• Atlassian：根本原因分析 – 5 个为什么？
  • 事件事后分析模板
  • 事件事后分析
• Splunk On-Call，原 VictorOps
• 其他 GitHub 模板资源
• 自定义内部模板：这可能是最有效的选择，因为它适合您组织的需求。

总结

以下是上述事件响应讨论的要点

• 有效的随叫随到系统对于确保服务可用性和健康状况是必要的。
• 平衡随叫随到工程师的工作量。
  • 分配资源。
  • 使用多区域支持。
  • 营造安全和积极的环境。
• 事件管理必须促进明确的职责分离。
  • 事件指挥、运维、计划和沟通。
• 无责事后分析有助于防止重复事件。

事件管理只是等式的一方面。为了使 SRE 组织有效，它还必须有变更管理系统。毕竟，变更是许多事件的原因。

下一篇文章着眼于应用有效变更管理的方法。

进一步阅读

• 无责事后分析和公正文化
• 事后分析清单