Close

针对高速团队的事件管理

事件事后分析模板

清晰的文档记录是有效事件事后分析流程的关键。每次事后分析期间,许多团队都使用全面的模板来收集一致的详细信息。


以下是事件事后分析模板的示例,该模板基于我们事件手册中概述的事后分析。您可以自行剪切和粘贴以上信息,记录您特有的事后分析。

事件摘要

用几句话概括事件。包括具体情况、原因、严重性以及影响持续的时间。

示例:

在 {日期} 的 {事件的时间范围,例如15:45 到 16:35},{数目} 个用户遇到了 {事件症状}。

该事件是由 {变更} 在 {引发事件的变更时间} 触发的。

<变更> 包含 <变更描述或原因,例如更新系统的代码更改>。

此代码中的错误导致了 <问题描述>。

<监控系统> 检测到该事件。团队通过 <采取的解决措施> 开始处理该事件。

此 {严重性级别} 事件影响了 {X%} 用户。

正如指出的,此事件还产生了进一步影响{例如,提交的支持请求单数、社交媒体提及次数、与客户经理通话次数}。

致因

描述导致事件发生的事件序列,例如,之前的更改引入了尚未检测到的缺陷。

示例:

在 {MM/DD/YY} 的 {16:00}({客户影响之前的时间,例如相关事件发生前 10 天}),对 {产品或服务} 进行了一项变更,造成了 {引发事件的变更}。

此变更导致 <变更影响描述>。

故障

描述所实施的变更如何未能按预期生效。如果可行,请附上可视化的相关数据屏幕截图,以说明故障。

示例:

{数目} 个回复被错误发送到 {XX%} 的请求。这种情况持续了 {时间段}。

影响

描述事件发生期间,事件如何影响内部和外部用户。包括提出的支持案例数量。

示例:

在 {MM/DD/YY} {XX:XX UTC 到 XX:XX UTC} 之间的 {xx 小时 XX 分钟},{事件摘要} 我们的用户经历了此事件。

此事件影响了 {XX} 位客户(X% 的 {系统或服务} 用户),他们遇到了 {症状描述}。

提交了

检测

团队何时发现这起事件?他们如何知道事件正在发生?我们怎样才能缩短检测时间?请考虑以下问题:我们怎么能将缓解时间缩短一半?

示例:

检测到事件的标志:<警报类型> 被触发,<团队或人员>被呼叫。

接下来,{次要人员} 被呼叫,因为 {第一人员} 不负责写入磁盘的服务,这导致响应延迟了 {XX 分钟/小时}。

{描述改进} 将由 {改进的团队负责人} 设置,以便 {预期改进}。

响应

谁对这起事件做出了回应?何时以及如何响应的?请注意任何延迟或响应障碍。

示例:

在 {XX: XX UTC} 收到呼叫后,{待命工程师} 于 {XX:XX UTC} 在 {捕获事件信息的系统} 中上线。

该工程师没有 {受影响系统} 的背景知识,因此系统于 {XX:XX UTC} 向 {上报待命工程师} 发送第二次警报,后者于 {XX:XX UTC} 进入聊天室。

恢复

描述服务的恢复过程以及事件的结束过程。详细说明服务成功还原的过程,您了解需要采取哪些步骤进行恢复。

根据具体情况,请考虑以下问题:如何缩短缓解时间?您如何将缓解时间缩短一半?

示例:

我们采用三管齐下的方法来恢复系统:

{描述缓解问题的措施、采取该错误的原因,以及得到的结果}

示例:增加 BuildEng EC3 ASG 的大小,以增加可为工作负载提供支持的节点数量,降低调度超额订阅节点的可能性

  • 禁用 Escalator 自动扩展器以防止群集大幅缩减
  • 将 Build Engineering 调度器恢复为先前版本。

时间线

详细说明事件时间线。我们建议使用 UTC 对时区进行标准化。

包括任何值得注意的向导事件、任何活动的开始、第一个已知影响以及上报。记录所做的任何决定或变更、事件的结束时间,以及任何值得注意的后续事件。

示例:

所有时间均为协调世界时。

11:48 - K8S 1.9 控制面板升级完成

12:46 - 升级到 V1.9 完成,包括集群自动扩展器和 BuildEng 调度器实例

14:20 - Build Engineering 向 KITT Disturbed 报告问题

14:27 - KITT Distribled 开始调查特定 EC2 实例 (ip-203-153-8-204) 的故障

14:42 - KITT Disturbed 封锁节点

14:49 - BuildEng 报告该问题影响不止一个节点。86 个问题实例表明失败更具系统性

15:00 - KITT Distribled 建议切换到标准调度程序

15:34- BuildEng 报告 200 个容器集出现故障

16:00- BuildEng 使用 OutofCPU 报告终止所有失败的构建

16:13 - BuildenG 报告说,新构建反复出现故障,而且不是短暂的。


16:30 - KITT 将故障识别为事件,并将其作为事件执行。


16:36 - KITT 禁用了 Escalator 自动扩展器以防止自动扩展器删除计算,从而缓解该问题。

16:40 - KITT 确认 ASG 处于稳定状态,群集负载正常,客户受到的影响已解决。

模板:

XX:XX UTC - 事件动态;采取的操作

XX:XX UTC - 事件动态;采取的操作

XX:XX UTC - 事件动态;采取的操作

确定根本原因:五问法

五问法是一种根本原因识别技巧。您可以这样来运用此方法:

  • 首先描述事件影响,然后询问发生的原因。
  • 记下它产生的影响。
  • 询问为什么会发生此情况,以及为什么会产生影响。
  • 然后,不断地问为什么,直至找出根本原因。

在您的事后分析文档中列出“原因”。

示例:

  1. 应用发生中断,因为数据库被锁定
  2. 数据库被锁定,因为对数据库的写入过多
  3. 因为我们向服务提送了一项变更,未意料到写入量会增高
  4. 因为我们没有针对负载测试变更建立相应的开发流程
  5. 因为我们从未觉得负载测试有必要,直到我们达到这个规模。

根本原因

请注意事件的最终根本原因,即确定需要更改的事物,以防止此类事件再次发生。

示例:

<导致缺陷的原因或出现缺陷的服务>连接池处理中的缺陷导致在出现故障的情况下泄露连接,以及对连接状态缺乏可见性。

待办事项检查

查看您的工程待办事项列表,了解是否存在任何计划外工作,防止发生此事件或至少减少其影响程度?

对待办事项列表进行清晰评估,有助于弄清楚过去围绕优先级和风险做出的决策。

示例:

待办事项列表中没有可改进此服务的具体项目。有一个关于流程类型改进的说明,这些都是工作流程到位的持续任务。

改进集成测试的请求单已经提交,但到目前为止尚未成功。

重现

既然您了解了根本原因,您能否回顾以下其他可能具有相同根本原因的事件?如果是,请注意在这些事件中尝试了哪些缓解措施,并询问再次发生此事件的原因。

示例:

这一相同的根本原因导致了事件 HOT-13432、HOT-14932 和 HOT-19452 的发生。

吸取的经验教训

讨论事件响应中哪些方面进展顺利、哪些方面本可以改进,以及哪些方面有改进的机会。

示例:

  • 需要进行单元测试,以验证工作的速度限制器是否得到正确维护
  • 应审查非典型正常操作的批量操作工作负载
  • 批量操作应该缓慢启动并进行监控,如果服务指标有名无实,则会增加

纠正措施

描述为防止将来发生此类事件而下令采取的纠正措施。记录下负责人员、工作的截止时间以及工作的追踪区域。

示例:

  1. 暂时进行手动的自动扩展速度限制,以限制故障
  2. 单元测试和重新引入工作速度限制
  3. 引入辅助机制来跨群集收集分散的速度信息以指导扩展效果
后续内容
Blameless