针对高速团队的事件管理
公共和私密事件事后分析
了解分享公开事后解释的正确时机
曾经有一段时间，几乎每个 IT 事件都被封锁在发生该事件的组织的四壁之内。但在今天，由于有了 Web 服务和云基础架构，这种情况已是罕见。技术事件是真正的“一对多”问题，它导致团队响应、学习和沟通事件的方式发生巨大变化。
请思考事件事后分析（通常也称为“事后审查”或“PIR”）。
事后分析可将人们聚集在一起以便讨论事件的细节：为什么会发生，产生的影响，采取了哪些措施来减轻影响和解决事件，以及如何才能防止事件再次发生。
事件事后分析可以分为两个截然不同的工件：讨论事件的会议，以及作为该会议输出而创建的对应事后分析报告。
人们提及“事后分析”时，通常会互换使用会议和报告这两项活动。人们使用这两个词语时，谈论的可能是其中一项，或两者兼而有之。
合作伙伴、客户和最终用户可能也想了解发生的情况，以及您采取了哪些措施来改善他们的体验。将事件事后分析公布到面向公众的网站上，这可能并非在所有情况下都适合，但您的营销或公共关系团队能够精心设计话术，以便人们充分掌握信息，并充分信任您的服务。
何时该做事后分析
在 Atlassian，我们始终对严重性级别为 1 和 2（“重大”）的事件进行内部的事后分析。而对于轻微事件，这是可选的。我们鼓励人们在任何适用的情况下使用事后分析流程。
由谁完成事后析误？
通常，提供导致事件的服务的团队负责完成相关的事后分析。该团队将指定一人来负责完成事后分析，相关的事务就会分配给他们。这是“事后分析负责人”，他们将通过起草和审批等工作推动事后分析的进行，直至结果发布为止。基础架构和平台级别的事件通常会影响公司的多个部门，这使得事后分析变得更加复杂和费事。因此，我们有时会指派专门的项目群经理来负责基础架构或平台级别的事后分析，因为这类员工更适合跨部门工作，而且也能为之投入必要的精力。
共享内部事后分析报告
事后分析获得批准后，我们可以通过在全公司共享自己的收获来增加其价值。为此，我们 Atlassian 实施了一个自动化操作，它会于事后分析请求单获得批准后在 Confluence 中创建一篇博客文章草稿。
创建公开事后分析报告
虽然这不太常见，但在事件发生后发布事后分析的公开版本通常是个好主意。
对于服务中断会影响许多用户的大型消费者服务，这尤为常见。通常，这些团队不会发布完整的内部报告，而是其精简版本。所有私密或敏感信息都会被清理掉，这非常重要。
共享公开事后分析报告
掌握适当的渠道来发布公开事后分析，可能会比较棘手。对于一些团队，这可以直接发布到公司的博客或网站上。另一些团队则有单独的工程博客，很适合用来发布事后分析。
在我们的产品 Statuspage 中，用户可以在事件解决之后，直接将公开事后分析发布到他们的状态页面上。