针对高速团队的事件管理
了解事件严重性级别
识别事件并确定其优先级，以便更快地解决
事件管理有三个基本真理。
首先，事件是不可避免的，尤其是对于不断成长和创新的公司而言。
其次，强大的事件管理实践对于正常运行的企业至关重要，（而薄弱的事件管理实践会使企业在员工时间和满意度以及业务收入方面付出巨大代价）。
第三，并非所有事件的重要性都一样。丢失一个数据库中的数据与丢失所有数据库中的数据不一样。处理影响 20％ 用户的中断与处理影响 90％ 或 100％ 用户的中断完全不同。在高峰时段处理系统中断比在大多数客户处于睡眠状态时处理系统中断的压力要大得多。即使是两起表面看起来相同的事件从本质来讲也是独一无二的。
针对高速团队的事件管理
利用 Jira Service Management 加快运营和开发团队之间的信息流动，以便在出现事件时做出响应并恢复系统。
这就是为什么拥有强大事件管理计划的公司具有明确定义的事件严重性级别和明确的最佳实践，以便在事件出现时对事件进行优先级排序。
什么是严重性级别？
事件严重性级别是衡量事件对业务影响的标准。通常，严重性级别数字越小，事件的影响就越大。
例如：在 Atlassian，我们将 SEV（严重性）1 事件定义为“影响非常大的严重事件”。这可能包括客户数据丢失、安全漏洞或所有客户面向客户的服务中断时。
SEV 2 事件是“具有重大影响的重大事件”，包括一部分客户的面向客户的服务中断或系统中的关键功能无法运行时。
SEV 3 事件是“影响较小的小事件”，例如给客户带来轻微不便的系统故障。
在 Atlassian，SEV 3 事件可以在白天/工作时间处理，而 SEV 1 和 SEV 2 事件会向待命专业人员发出警报，以便随时立即开始修复。
| 严重性 | 描述 | 示例 |
|---|---|---|
| 1 | 产生极大影响的危机事件 |
|
| 2 | 产生巨大影响的重大事件 |
|
| 3 | 产生较小影响的小型事件 |
|
严重性级别有助于快速了解影响以及为 IT 和 DevOps 团队设置优先级。
您的 SEV 级别定义得越明确，团队就越有可能保持同步，在事件发生时快速而适当地做出反应。如果没有明确定义的严重性级别，很容易将重要时间浪费在定义和解释事件的紧急性上，而不是解决问题。
严重性级别在何时及何地有用？
SEV 级别的核心价值在于它们可以为团队节省时间。拥有严重性级别和针对每个级别的明确路线图的团队可以直接解决问题。没有严重性级别的团队可能要在重大事件最初的关键时间里弄清楚事件有多重要、谁应该处理以及如何处理。
事件越严重，就越需要尽可能多地节省时间，不仅要提前做好事件解决和沟通计划，还要明确 SEV 级别和优先级。
严重性与优先级有何不同？
乍一看，事件严重性似乎与事件优先级相同。毕竟，具有严重后果的严重事件应该在不太严重的事件之前优先处理，对吧？
但事实是，对于大多数企业来说，实际情况会更复杂。
严重性是衡量影响程度的指标。事件对用户的影响有多大？它会摧毁用户的整个系统吗？会阻止用户完成一项重要任务？还是只会激怒用户，然后让任务变得更难完成？
另一方面，优先级是衡量紧迫性的标准。我们需要多快解决这个问题？哪个问题需要先解决？
有时两个衡量指标完全一致。导致整个公司崩溃的高严重性事件可能也是 DevOps 和 IT 团队需要关注的最高优先级事项。
但有时优先级和严重性不一致。例如：假设您网站主页的标题中有错别字。这是一个低严重性问题，因为它实际上不会影响网站的功能。用户仍然可以做任何他们需要进行的工作。员工仍然可以做他们需要进行的工作。
但是，企业可能会出于品牌标准的考虑，或者因为它会引起混乱，或者仅仅是因为它使网站内容看起来很糟糕，从而将纠正错别字视为高优先级。因此，此事件可能是低严重性和高优先级。
同样，假设发生了导致您的应用崩溃的事件。此事件为高严重性，因为这会导致用户无法进行所需的工作。但是，我们也假设该事件仅影响了 0.05％ 的用户。如果还有其他影响更广泛的事件，那么此类事务可能不是最高优先级，尽管通常“系统正在崩溃”意味着需要全员行动。
这两个衡量指标在事件管理中都很重要，但必须要注意识别二者何时一致，何时不一致。高严重性不会自动将某些事务推到优先级列表的顶部，高优先级并不总是意味着系统停机。
由于优先级比严重性更具可操作性，因此它是我们使用的主要衡量标准。而且，由于严重性通常是决定优先级的关键因素，因此我们在事件手册中为自己的事件管理实践设定了明确的定义。
为您的组织定义事件严重性级别
并非所有事件的重要性都一样，也并不是所有组织都以相同的方式处理事件。在设置严重性级别及其相关流程和预期时，除了事件的影响外，您还需要考虑以下因素：
- 您的技术团队的规模
- 待命值班表
- 您的服务在一天中的高流量和低流量时段
- 事件发生频率
为什么？因为所有这些因素都可能影响您定义 SEV 级别的方式。
例如，在单个时区为本地市场提供服务的应用在凌晨 2 点到早上 7 点之间可能会有很大的使用间隔。那么，如果您整个系统在凌晨 3 点停机，SEV 级别是否与高峰时段的系统中断相同？
或者，一家拥有小型团队的初创公司，发生很多我们认为是 SEV 3 的事件呢？他们是否应该坚持使用 SEV 3 级别，让团队确定如果同时发生三起事件，哪些事件应该优先？或者他们是否应该将它们进一步分为 SEV 3、4 甚至 5，以区分面向客户的系统中部分功能丧失、性能问题和更小的问题，例如不影响系统可用性但最终需要修复的错误？
这里最重要的是了解您的业务、您的团队，以及什么样的 SEV 级别和优先级定义对您有用。
| Atlassian 3 级 | 4 级 | 5 级 | |
|---|---|---|---|
| 1 级严重性 | 产生极大影响的关键事件。 | ||
| 2 级严重性 | 产生巨大影响的重大事件。 | ||
| 3 级严重性 | 产生较小影响的小型事件。 例如：系统错误给客户带来了轻微的不便。 | 如果不迅速解决，有可能成为重大事件的事件。 | |
| 4 级严重性 | 激怒客户但不影响整体系统功能的支持请求。 | 一个小型事件，会影响产品可用性，但不会使其陷入停顿。 | |
| 5 级严重性 | 不影响产品可用性的错误或支持问题。 | ||
必须有一个事件管理解决方案来升级事件，以便合适的团队迅速集结，开始解决问题。
了解 Jira Service Management 的所有事件管理功能（包括警报和待命值班表、协作沟通以及强大的报告和分析功能）如何使团队能够响应、解决事件并从中吸取经验教训。