Opsgenie 的警报和待命功能现已在 Jira Service Management 和 Compass 中可用。使用我们的自动迁移工具在 2027 年 4 月 5 日之前迁移现有的 Opsgenie 数据和配置。了解更多
事件事后分析流程：跟踪、记录和改进
关键要点
事件事后分析有助于团队厘清事件经过、原因及所需改进措施，以避免同类问题重复发生。
将 Jira Service Management、Confluence 和 Jira 结合使用，可搭建贯通响应、文档记录与后续跟进的工作流。
一致的事后分析模板能简化事件复盘的归档与对比工作，便于长期总结经验。
将纠正措施转化为指定负责人和截止时间的 Jira 工作项，可助力团队将经验教训落地为实际改进。
当生产环境出现问题时，修复只是开始。同样重要的是了解事件发生的原因，并确保不会以同样的方式再次发生。
事件事后分析是对事件从开始到结束的结构化复盘，涵盖出现故障影响范围、团队响应方式以及未来需要改进的事项。
依托事件响应计划模板指导流程，团队可统一归档每一次事件，避免遗漏关键信息，让每次复盘都能带来实质改进。
运作机制：管理事件并记录事后分析
完善的事件管理不仅仅是应急救火，更要搭建一套体系，让每一次事件都反哺流程优化、工具升级与后续预案完善。结合使用 Jira Service Management、Confluence 和 Jira，可为团队搭建贯通的工作流，覆盖完整的事件响应生命周期：从警报触发，到事后分析，再到后续跟进。
这种方法可实现所有事件文档统一规范留存，并建立清晰的责任追溯链条。告别事件信息零散散落于 Slack 消息、电子邮件和个人记忆的情况，所有内容统一留存于一个互联互通的生态系统中，便于复盘、查阅与落地执行。这种一致性也能让事件响应计划模板始终处于流程核心位置，而非变成团队有空才补填的东西。
以下是各个阶段的流程拆解说明：
在 Jira Service Management 中管理事件
Jira Service Management 是您事件响应的起点。一旦出现问题，即刻在 JSM 中记录事件、设定严重性等级，并分配合适的响应者。
在事件处理期间，团队可以使用 JSM 完成以下工作：
实时跟踪行动、决策和上报
清晰记录参与人员及所有变更内容
记录详细信息，为后续事后分析提供支持
及时向管理层同步进展，同时不干扰响应者的工作
由于 JSM 可与 Confluence 及 Jira 实现集成，事件处置过程中收集的数据，能够直接同步至事后分析文档与跟进工作。对于将 JSM 纳入整体 ITSM 软件的团队而言，事件数据还能为更大范围的服务管理提供数据支撑。
JSM 还能通过帮助团队完成以下工作，助力他们在整个响应过程中做好事件沟通：
持续向客户、支持团队及利益相关者同步最新进展
减少事件处理期间的混乱
实时同步事件状态与影响范围，提升透明度
在高严重性事件或危机管理场景中更清晰地沟通
待事件解决完毕时，团队已留存详实的事件发展全过程记录，既便于记录事后分析，也能让事后分析对未来改进更有用。
在 Confluence 中记录事后分析
事件解决后，应在细节仍清晰时（理想情况下 24 至 48 小时内）完成记录。拖延时间越长，相关背景信息流失越多，事后分析的价值也就越低。
使用事件事后分析模板创建专属的 Confluence 页面，并逐一填写各个板块：事件时间线、根本原因分析、影响评估以及经验教训。本页面提供的事件响应模板包含一套完整框架，团队可复制该框架并为每个新事件填写内容，无需每次都从零开始梳理需记录的内容。
将事后分析留存在 Confluence 具有以下几项实际优势：
团队全员可见：从研发人员到管理层，均可自行查阅事件始末，无需再追着让待命响应者口头重述要点。
规律问题识别：所有事件采用统一格式记录后，更容易跨季度发现重复故障与系统性短板。
无追责式文档记录：结构化的的事件响应模板能让讨论聚焦于系统和流程本身，而非相互追责，从而形成更客观、更有价值的报告。
新员工更快上手：新团队成员可查阅历史事后分析，了解系统在高压力下的运行表现，以及团队从过往事件中总结的经验教训。
如需更深入了解如何开展高效的事后分析复盘，请阅读我们的事件事后分析手册。
将跟进事项纳入 Jira 工作项进行跟踪
事后分析的价值完全取决于它所能推动的行动。复盘过程中发现的每一项整改措施及反复出现的问题，都应转化为 Jira 工作项，并明确负责人与截止时间。
这一步是能真正实现优化改进的团队，与反复陷入同类问题的团队之间的分水岭。当整改措施以可追踪工作项的形式留存在 Jira 中时，管理者可以监控进度，团队也能相互监督，落实已达成共识的优化任务。同时也便于优先级排序。由事件推动的工作与待办事项列表其余事项一并留存后，更便于于其他优先事项进行权衡，避免此类工作被悄然搁置、无人跟进。
合适的事件管理工具可端到端连接整个工作流。当响应、文档和跟进体系集成后，从发现问题到防范问题再次发生之间的周期会大幅缩短。
事件响应模板
以下是一份事件响应计划模板，团队可复制并根据每个新事件进行调整。该模板涵盖事后分析的每个阶段，从初始摘要、事件时间线，到根本原因分析、经验教训总结以及整改措施，一应俱全。对每个事件使用一致的结构，可确保不会遗漏任何内容，同时也便于长期对比各次事后分析内容。
模板内的示例仅作参考起点，并非刻板照搬的范本。请根据所在组织的实际运作模式，调整语言表述与信息详略程度。其目标是：完整记录足够的背景信息，确保即便数月后有人查阅这份事后分析，也能清晰了解事件始末以及团队采取的应对措施。
事件摘要
用几句话概括事件。包括具体情况、原因、严重性以及影响持续的时间。
示例：
在 {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 的发生。
吸取的经验教训
讨论事件响应中哪些方面进展顺利、哪些方面本可以改进，以及哪些方面有改进的机会。
示例：
需要进行单元测试，以验证工作的速度限制器是否得到正确维护
应审查非典型正常操作的批量操作工作负载
批量操作应该缓慢启动并进行监控，如果服务指标有名无实，则会增加
纠正措施
描述为防止将来发生此类事件而下令采取的纠正措施。记录下负责人员、工作的截止时间以及工作的追踪区域。
示例：
暂时进行手动的自动扩展速度限制，以限制故障
单元测试和重新引入工作速度限制
引入辅助机制来跨群集收集分散的速度信息以指导扩展效果