针对高速团队的事件管理
如何运行重大事件管理流程
管理和解决影响大的事件
重大事件管理（在 Atlassian 中通常简称为事件管理）是 DevOps 和 IT 运营团队用来响应计划外事件或服务中断并将服务恢复到运行状态的流程。
什么是重大事件？
那么，什么构成重大事件呢？重大事件是紧急级别的中断或服务中断。
紧急级别的定义因组织而异。在 Atlassian，我们有三个严重性级别，前两个（SEV 1 和 SEV 2）都被视为重大事件。
如果所有 Atlassian 客户的面向客户的服务中断，那就是 SEV 1 事件。如果一部分客户的相同服务停机，那就是 SEV 2。两者都属于重大事件的范畴，需要我们的事件管理团队立即做出响应。
任何不干扰基本任务的事务都被视为 SEV 3，不属于重大事件。
定义您的重大事件管理流程
事件生命周期（有时也称为事件管理流程）是我们识别、解决、理解和避免重复事件的途径。
事件管理流程因公司而异，但对于任何团队来说，成功的关键是在重大事件发生之前，明确定义并提前传达严重性级别、优先级、角色和流程。
为了获得对优先级、角色和流程的共同理解，任何正在开始或重新审视重大事件管理流程的团队都应首先明确以下问题的答案：
Atlassian 的重大事件管理流程
在 Atlassian，我们的事件管理流程包括检测、提出新事件、开始通信、评估、发送初始通信、上报、委派、发送后续通信、审核和解决。
检测
首先，由我们的技术、客户报告或人员检测到事件。无论谁检测到事件（无论是注意到事务的技术人员还是接到沮丧客户电话的客户服务代表）都有责任在我们的系统中记录事件并确定严重性。
当事件传到我们团队时，它已经附上了 SEV 1、2 或 3。我们认为 SEV 1 级和 2 级是重大事件，SEV 3 表示影响较小的事件。
出现新事件
创建事件工作单后，将向负责该服务的待命专业人员发出通知。
我们在 Atlassian 上发出的页面警报包括有关事件严重性和优先级的信息以及摘要，一目了然地表明这是重中之重，还是可以等到其他事件结束后再处理。
开始沟通
一旦事件管理员收到警报，他们的首要任务就是告知事件修复正在进行中。他们将事件的状态更改为正在修复，并建立团队的沟通渠道。
在整个事件响应过程中提供灵活的沟通渠道，以便团队通过首选途径保持联系，这是重中之重。Jira Service Management 集成了多个通信渠道，例如嵌入式状态小工具、专用状态页、电子邮件、聊天工具、社交媒体和短信，从而最大限度地减少停机。
评估
事件经理已收到警报，沟通渠道已开放。下一步：评估事件本身。
对于我们团队来说，这个流程从团队必须回答的一系列问题开始：
- 这对 Atlassian 的客户和员工有什么影响？
- 客户看到了什么？
- 有多少客户受到影响？（部分？全部？）
- 事件是什么时候开始的？
- 已就此事件开启了多少支持案例？
- 是否还有其他因素会影响严重性级别或优先级，或者改变我们处理事件的方式？（例如：安全问题、社交媒体公关危机等）
一旦我们回答了这些问题，我们就可以放心地推进诊断和建议的修复，或者根据需要更改事件的 SEV 级别和优先级别。
发送初始沟通
一旦我们确认事件是真实的，与客户和员工的沟通就成为重中之重。正如我们在手册中所说的那样：
“初始的内部沟通的目的是将事件响应集中在一个地方，从而减少混乱。外部沟通的目的是告诉客户您知道出现了故障，您正在将其当作紧急事件进行调查。”
快速、准确的沟通有助于建立和保持客户信任。
我们有一个战略事件沟通计划，并按照简单的格式提供定期的状态更新。我们还会向一系列利益相关者发送电子邮件，其中包括我们的工程领导、重大事件经理和其他关键内部员工。如前所述，所有这些沟通方法均可在 Jira Service Management 中进行自定义，并且可以根据任何组织的事件响应计划进行定制。
上报
有时，待命团队会迅速解决事件。但是，如果没能迅速解决，下一步是将事务上报给更适合解决此特定事件的另一位专家或专家团队。
在 Jira Service Management 中，响应者可以对相关工作单进行分组，并将合作者添加到事务中以协调警报。响应者还可以使用丰富的事件时间线自动记录所有操作。通过访问自动化和知识库文章，他们能够快速调查事件并开展补救工作。
委派任务
一旦问题上报给新来的人，事件经理就会向他们委派一个角色。在 Atlassian，这些角色是预设的，因此团队成员可以快速了解对他们的期望。
有时，重大事件需要一个事件经理和一个小团队。其他时候，情况可能需要多位技术负责人，甚至需要多名事件经理。最初事件经理的任务是弄清楚何时会出现这种情况，然后聘请合适的人员。
发送后续沟通
随着事件持续发展，技术团队之外的另一轮沟通能够帮助客户和员工保持冷静、信任并了解最新消息。当合作者可以管理不同沟通平台上的警报以掌握事件响应情况时，即可轻松做到这点。
审查
不幸的是，在事件解决方面，没有一刀切的方案。这就是为什么在这个流程阶段，我们会花时间：
- 观察正在发生的事情，与团队分享并确认观察结果
- 就为什么发生事情（以及我们如何修复它）而列出猜想
- 开发和执行实验来证明或反驳这些猜想
- 重复
在整个过程中，事件经理会密切关注事情的进展情况。特定团队成员的任务是否过多？有人需要休息吗？我们需要招聘新人吗？根据需要进行更多委派。
解决
我们的事件手册将解决方案定义为“当前或即将发生的业务影响结束时”。
此时，紧急响应结束，团队过渡到处理善后工作和事后分析。
事后分析
我们的事件生命周期在事件解决后结束，但这还不是我们 Atlassian 流程的终点。我们还想尽一切努力确保事故不会重演。这就是为什么下一步是无指责的事后分析，旨在确定事件原因并帮助我们降低未来的风险。
在 Jira Service Management 中，使用事后分析模板即可轻松创建事后分析报告以及相关的事件时间线，并将其导出到 Confluence。这样，响应者就可以继续与跨职能团队合作，跟踪后续行动，避免将来发生类似事件。
角色和职责
角色和职责将因组织的文化、团队规模、待命时间表等而有所不同。一些常见的重大事件角色包括：
事件经理：负责监督事件解决的人员。
技术负责人：一位高级技术专家，其任务是弄清楚故障的内容和原因，确定最佳行动方案，并管理技术团队。
沟通经理：沟通专家（通常来自公关或客户支持团队），负责与受事件影响的内部和外部客户进行沟通。
客户支持主管：负责确保有关事件的工作单、电话和推文得到及时、妥善地回复。
社交媒体主管：负责在社交频道就事件进行沟通的社交媒体专业人士。
其他常见角色包括：
根本原因分析或问题经理：负责超越事件解决方案，以查明根本原因，并确定为避免将来发生问题而需做出的变更。
重大事件调查委员会：负责调查和变更管理的小组。
诸如 Jira Service Management 之类的事件管理解决方案对响应过程的每个步骤皆有助益，包括组织待命时间表、警报、联合团队以加强协作，以及开展事后分析等。