事件响应的最佳实践和提示

1. 常备应急背包

事件响应者的“应急背包”存放着所有重要的信息，以便团队在需要时以最短的延迟加以访问。这很有可能是一份数字化文档，但为事件响应者提供一个集中的起点会有极大帮助。

其可能包括各种各样的内容：

• 事故响应计划
• 联系人名单
• 待命时间表
• 上报政策
• 指向会议工具的链接
• 访问代码
• 政策文档
• 技术文档和运行手册

2. 不逃避操作说明书

运行手册提供在给定场景中应采取哪些步骤的指导。当系统专家可能无法立即到场时，它们对于待命轮换的团队来说尤为重要。若有一套维护良好的运行手册，团队能够更快地做出响应，并且建立事件响应实践的共享知识库。

3. 接纳混乱，促进稳定

混沌工程 (Chaos Engineering) 是通过故意注入错误对系统进行实验的方法，目的是了解如何更可靠地构建系统。Chaos Monkey 就是这样一个例子。Chaos Monkey 最初由 Netflix 开发，是一款通过故意使生产系统离线来测试网络弹性的工具。

4. 告别 NOC

在过去，Network Operations Centers (NOCs) 充当大型 IT 系统的监控和警报中心。现代事件管理工具可以大幅简化此过程。根据定义的警报类型、团队计划和上报策略自动化警报交付工作流，可以避免人为错误和/或延迟的可能性。

5. 整合，而非增负

没有什么比持续从多个监控工具收到警报更糟糕的了。通过单一工具来集中警报流，团队能够更好地过滤干扰，快速将精力集中到需要注意的事项。

6. 记住：知识就是力量

基本的警报会传达出了状况，但并不总会表述具体的问题。这会导致不必要的延迟，因为团队必须调查并确定问题缘由。通过将警报与触发原因技术细节相结合，可以更快地启动修复过程。

7. 为警报设置警报

拉丁语词组“quis custodiet ipsos custodes”（“谁在保卫守卫？”）提出了一个普遍的问题。就像受其保护的系统容易受到事件和停机影响，IT 和开发人员团队所采用的监控工具也不例外。全面的警报流程可确保持续检查系统及其监控工具的运行状况。

8. 止血

分诊医生知道，如果他们深陷于试图在抵达时解决所有问题，他们会面临造成更大伤害的风险。他们的重点是短期行动，使患者病情稳定下来，足以转移到接受更多急诊护理的地方。在技术领域，遏制措施侧重于临时解决方案（隔离网络、回退版本、重启服务器等），这些解决方案至少会限制事件的范围，或者更理想的是使系统重新上线。

9. 不孤军奋战

IT 和 DevOps 团队中的英雄文化是一种日薄西山的理念。因为是唯一能使系统恢复上线的人，而成为在夜晚和周末无休止地孤军奋战的工程师，这已不再是一种潮流。相反，团队就要以团队的方式工作。链条的牢固程度取决于其最薄弱的一节，因此要尽力培养整个团队，而不仅仅是一位孤星。

10. 公开透明

如果用户遭遇服务中断，相关事件通常会在短时间内公开。为了能抢先一步，团队应该制定事件沟通计划。目标是通过公开承认正在发生中断与客户建立信任，并向他们保证已在采取措施来解决中断。Statuspage 之类的工具非常适合分发这种信息。

11. 从失败中学习

绝大多数情况下，IT 和 DevOps 团队会表示，他们只花时间检查“重大中断”。虽然这是一个良好的开端，但往往会忽视可能产生持续影响的小事件。并非所有事件都需要冗长的报告，但事后分析总是有用的。

12. 寻找根本原因（没有根本原因！）

或者说有？在分析事件时，很少能指明单个可识别的“根本”原因。系统常常会太过复杂，而且它们相互依存，无法确定事件的单一根本原因。即使根本原因看似明显（比如，击键错误导致应用崩溃），通常也有理由去查明哪些外部因素可能造成应用崩溃（或未能阻止崩溃）。寻找多个根本原因，更深入地了解您的事件。

13. 不要指责

对于每一事件，事后分析的目标应该是了解出了什么问题，以及可以采取哪些措施来避免将来发生类似事件。重要的是，此过程不应被用来指责他人。那是因为，如果团队聚焦于“何人”而不是“何事”，引起的情绪会使分析偏离方向，无法真正了解发生了什么。

还有一件事

在现代事件管理环境中，唯有变化是永恒不变的。也就是说，系统将不断地以新的和不同的方式承受压力。知道这一点的团队也明白，问题不在于系统是否会出现故障，而在于何时出现故障。采取措施准备好应对这些故障，应被视为持续成功的关键要素，并将其融入工程团队的 DNA 中。

诸如 Jira Service Management 之类的事件管理解决方案对这 13 个要点皆有助益，包括从组织待命时间表和警报到联合团队以加强协作，再到开展事后分析等。