事件事后分析模板
清晰的文档记录是有效事件事后分析流程的关键。每次事后分析期间，许多团队都使用全面的模板来收集一致的详细信息。
以下是事件事后分析模板的示例，该模板基于我们事件手册中概述的事后分析。您可以自行剪切和粘贴以上信息，记录您特有的事后分析。
事件摘要
用几句话概括事件。包括具体情况、原因、严重性以及影响持续的时间。
示例：
在 {日期} 的 {事件的时间范围，例如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 - 事件动态；采取的操作
确定根本原因：五问法
五问法是一种根本原因识别技巧。您可以这样来运用此方法：
- 首先描述事件影响，然后询问发生的原因。
- 记下它产生的影响。
- 询问为什么会发生此情况，以及为什么会产生影响。
- 然后，不断地问为什么，直至找出根本原因。
在您的事后分析文档中列出“原因”。
示例：
- 应用发生中断，因为数据库被锁定
- 数据库被锁定，因为对数据库的写入过多
- 因为我们向服务提送了一项变更，未意料到写入量会增高
- 因为我们没有针对负载测试变更建立相应的开发流程
- 因为我们从未觉得负载测试有必要，直到我们达到这个规模。
根本原因
请注意事件的最终根本原因，即确定需要更改的事物，以防止此类事件再次发生。
示例：
<导致缺陷的原因或出现缺陷的服务>连接池处理中的缺陷导致在出现故障的情况下泄露连接，以及对连接状态缺乏可见性。
待办事项检查
查看您的工程待办事项列表，了解是否存在任何计划外工作，防止发生此事件或至少减少其影响程度？
对待办事项列表进行清晰评估，有助于弄清楚过去围绕优先级和风险做出的决策。
示例：
待办事项列表中没有可改进此服务的具体项目。有一个关于流程类型改进的说明，这些都是工作流程到位的持续任务。
改进集成测试的请求单已经提交，但到目前为止尚未成功。
重现
既然您了解了根本原因，您能否回顾以下其他可能具有相同根本原因的事件？如果是，请注意在这些事件中尝试了哪些缓解措施，并询问再次发生此事件的原因。
示例：
这一相同的根本原因导致了事件 HOT-13432、HOT-14932 和 HOT-19452 的发生。
吸取的经验教训
讨论事件响应中哪些方面进展顺利、哪些方面本可以改进，以及哪些方面有改进的机会。
示例：
- 需要进行单元测试，以验证工作的速度限制器是否得到正确维护
- 应审查非典型正常操作的批量操作工作负载
- 批量操作应该缓慢启动并进行监控，如果服务指标有名无实，则会增加
纠正措施
描述为防止将来发生此类事件而下令采取的纠正措施。记录下负责人员、工作的截止时间以及工作的追踪区域。
示例：
- 暂时进行手动的自动扩展速度限制，以限制故障
- 单元测试和重新引入工作速度限制
- 引入辅助机制来跨群集收集分散的速度信息以指导扩展效果