The path to better incident management starts here

更出色的事件管理之路从这里开始

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

事件产生的影响可以用每分钟损失数万或数百美元来衡量。风险如此之大,因此各个组织都在快速发展事件响应最佳实践。

如果组织不经常迭代其事件管理流程,他们将面临管理不善的事件、不必要的延误和相关的成本等风险。

下方列出了一些很常见和不太常见的最佳实践和提示。

几个人在看 Jira 面板

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 个要点皆有助益,包括从组织待命时间表和警报到联合团队以加强协作,再到开展事后分析等。