Opsgenie 的警报和待命功能现已在 Jira Service Management 和 Compass 中可用。使用我们的自动迁移工具在 2027 年 4 月 5 日之前迁移现有的 Opsgenie 数据和配置。
事件事后分析模板
清晰的文档记录是有效事件事后分析流程的关键。每次事后分析期间，许多团队都使用全面的模板来收集一致的详细信息。
以下是事件事后分析模板的示例，该模板基于我们事件手册中概述的事后分析。您可以直接复制粘贴该模板，用于记录自身的事后分析。
事件摘要
用几句话概括事件。包括具体情况、原因、严重性以及影响持续的时间。
示例：
在 {DATE}的 {time range of incident, e.g. 15:45 and 16:35} 期间，有 {NUMBER} 名用户遇到了{EVENT SYMPTOMS}。
该事件由 {TIME OF CHANGE THAT CAUSED THE EVENT} 的一项{CHANGE}触发。
此次{CHANGE}内容如下：{DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}。
此代码中的一个缺陷导致了{DESCRIPTION OF THE PROBLEM}。
该事件由 {MONITORING SYSTEM} 检测到。团队通过{RESOLUTION ACTIONS TAKEN}启动了事件处理流程。
该事件的严重级别为{SEVERITY LEVEL}，影响了 {X%} 的用户。
事件造成的进一步影响包括：因此事件产生了{e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS}。
致因
描述导致事件发生的事件序列，例如，之前的更改引入了尚未检测到的缺陷。
示例：
在 {MM/DD/YY}的 {16:00}（{AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}），为实现{THE CHANGES THAT LED TO THE INCIDENT}，我们向 {PRODUCT OR SERVICE} 实施了一项变更。
此更改导致{DESCRIPTION OF THE IMPACT OF THE CHANGE}。
故障
描述所实施的变更如何未能按预期生效。如果可行，请附上可视化的相关数据屏幕截图，以说明故障。
示例：
向 {XX%} 的请求错误发送了 {NUMBER} 条响应。该问题持续了 {TIME PERIOD}。
影响
描述事件发生期间，事件如何影响内部和外部用户。包括提出的支持案例数量。
示例：
在 {MM/DD/YY} {XX:XX UTC and XX:XX UTC} 期间，总计 {XXhrs XX minutes}，我们的用户遇到了该事件：{SUMMARY OF INCIDENT}。
该事件影响了 {XX} 个客户（占 {SYSTEM OR SERVICE} 用户总数的 X%），受影响用户遇到的事件症状如下：{DESCRIPTION OF SYMPTOMS}。
提交了 {XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS}。
检测
团队何时发现这起事件？他们如何知道事件正在发生？我们怎样才能缩短检测时间？请考虑以下问题：我们怎么能将缓解时间缩短一半？
示例：
当{ALERT TYPE}被触发且{TEAM/PERSON}收到呼叫时，该事件被检测到。
随后，{SECONDARY PERSON}收到呼叫，因为{FIRST PERSON}不负责向磁盘写入的服务，这导致响应延迟了 {XX MINUTES/HOURS}。
{DESCRIBE THE IMPROVEMENT}将由{TEAM OWNER OF THE IMPROVEMENT}推进落地，预期达成{EXPECTED IMPROVEMENT}。
响应
谁对这起事件做出了回应？何时以及如何响应的？请注意任何延迟或响应障碍。
示例：
在 {XX:XX UTC} 收到呼叫后，{ON-CALL ENGINEER}于 {XX:XX UTC} 在 {SYSTEM WHERE INCIDENT INFO IS CAPTURED} 上线响应。
该工程师缺乏 {AFFECTED SYSTEM} 相关背景知识，因此于 {XX:XX UTC} 向{ESCALATIONS ON-CALL ENGINEER}发送了二次警报，后者于 {XX:XX UTC} 加入事件处理沟通渠道。
恢复
描述服务的恢复过程以及事件的结束过程。详细说明服务成功还原的过程，您了解需要采取哪些步骤进行恢复。
根据具体情况，请考虑以下问题：如何缩短缓解时间？您如何将缓解时间缩短一半？
示例：
我们采用三管齐下的方法来恢复系统：
{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME}
示例：增加 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 的发生。
吸取的经验教训
讨论事件响应中哪些方面进展顺利、哪些方面本可以改进，以及哪些方面有改进的机会。
示例：
需要进行单元测试，以验证工作的速度限制器是否得到正确维护
应审查非典型正常操作的批量操作工作负载
批量操作应该缓慢启动并进行监控，如果服务指标有名无实，则会增加
纠正措施
描述为防止将来发生此类事件而下令采取的纠正措施。记录下负责人员、工作的截止时间以及工作的追踪区域。
示例：
暂时进行手动的自动扩展速度限制，以限制故障
单元测试和重新引入工作速度限制
引入辅助机制来跨群集收集分散的速度信息以指导扩展效果