创建事后分析报告

为什么收集和记录数据是事件事后分析流程的关键

事件事后分析可以分为两个截然不同的工件：讨论事件的会议，以及作为该会议输出而创建的对应事后分析报告。

人们提及“事后分析”时，通常会互换使用会议和报告这两项活动。人们使用这两个词语时，谈论的可能是其中一项，或两者兼而有之。

想要从事后分析模板着手？查阅我们的事后分析模板。

然而，事后分析会议和事后分析书面报告是有区别的。

在 Atlassian，我们通常使用事后分析或事件事后分析来描述对事件进行分析的整个过程，具体包括：

• 举行事件事后分析会议

• 记录会议期间的操作和信息

• 获得对后续行动的批准并传达会议成果

阅读我们的事件管理手册，详细了解 Atlassian 如何管理事后分析。

什么才算好的事件事后分析报告？

清晰且一致的提示

好的报告应该建立在清晰和一致的框架之上。高效的团队会在模板上设置每一事后分析，供参与者回答一系列问题或按提示提供信息。

这样可确保不遗漏关键细节。而且，还能在事件之间建立一致性，帮助团队识别模式、趋势和改进机会。框架可以随时间推移迭代和改进，但任何变更都应是有意为之。

丰富的细节和数据

事后分析字段不是省略细节和掩盖事实的地方。在这里，您要做到非常细致和具体。不要只说您看到了流量激增，准确指明变化的指标有多少、分别是哪些。不要只说团队感到困惑，引用聊天记录中某人表达困惑的原话。

包容、无指责的语言

与许多团队一样，我们 Atlassian 也践行无指责事后分析。重要的是，在会议和事件分析中杜绝指责他人。不过，撰写报告时同样也要确保谨慎对待措辞。不要使用责怪或挑错的语言。

在事后分析报告中应提出的重要问题

以下是 Opsgenie 事后分析功能中包含的提示：

• 致因：描述引发这起事件的状况

• 故障：描述哪些方面未能达到预期

• 检测：描述事件是如何被检测到的

• 根本原因：进行五问法分析，了解事件的真正起因

• 缓解和解决：您采取了哪些措施来解决这起事件？

• 吸取的经验教训：哪些方面进展顺利？哪些地方还可以改进？您还有什么其他收获？

查阅我们关于事后分析模板的文章，查看更多可包含在事后分析报告中的示例问题。

事后分析报告应包括的其他内容

• 屏幕截图：附上相关的屏幕截图，尤其是响应团队在中断期间截取的屏幕截图。您看到产品发生什么变化？哪些产品行为未能按预期出现？

• 工作单：关联与事件有关的任何相关工作单。

• 客户反馈：客户有没有发来任何与该事件相关的反馈？这些可以通过帮助台、电子邮件或社交媒体等渠道反映。将这一切都包含在内也没关系。

• 图表与图形：哪些数据可视化呈现有助于展示事件的影响？

• 数据：还有哪些关于事件或其影响的关键数据点？

• 聊天交流记录：如果团队在响应过程中使用了 Slack 等聊天工具，不妨附上聊天记录中的任何关键消息或交流记录。

• 时间线：一目了然的事件时间线是事件分析的绝佳助手。事件发生期间的关键活动有哪些，其时间戳分别是什么。

内部与外部事后分析报告

虽然这不太常见，但一些组织会选择在事件发生后发布事后分析的公开版本。对于服务中断会影响许多用户的大型消费者服务，这尤为常见。他们可能会发布完整的事后分析报告，或者（更有可能）发布内部报告的精简版本。也许要清理掉一些敏感或私密信息。

专业人士如何应对重大事件

获取我们免费提供的事件管理手册。了解 Atlassian 用于管理重大事件的各种工具和技术。

获取手册