Opsgenie 的警报和待命功能现已在 Jira Service Management 和 Compass 中可用。使用我们的自动迁移工具在 2027 年 4 月 5 日之前迁移现有的 Opsgenie 数据和配置。
了解事件严重性级别
识别事件并确定其优先级，以便更快地解决
事件管理有三个基本真理。
首先，事件是不可避免的，尤其是对于不断成长和创新的公司而言。
其次，完善的事件管理实践对于企业良性运营至关重要，（而不完善的事件管理实践会给企业带来巨大损失—既耗费员工时间、影响员工满意度，也会损害企业营收）。
第三，并非所有事件的重要性都一样。丢失一个数据库中的数据与丢失所有数据库中的数据不一样。处理影响 20% 用户的中断与处理影响 90% 或 100% 用户的中断完全不同。在高峰时段处理系统中断比在大多数客户处于睡眠状态时处理系统中断的压力要大得多。即使是两起表面看起来相同的事件从本质来讲也是独一无二的。
针对高速团队的事件管理
利用 Jira Service Management 加快运营和开发团队之间的信息流动，以便在出现事件时做出响应并恢复系统。
这就是为什么拥有强大事件管理计划的公司具有明确定义的事件严重性级别和明确的最佳实践，以便在事件出现时对事件进行优先级排序。
什么是严重性级别？
事件严重性级别用于衡量事件对业务的影响程度。通常，严重性级别数字越小，事件的影响就越大。例如：在 Atlassian，我们将 SEV（严重性）1 事件定义为“影响非常大的严重事件”。这可能包括客户数据丢失、安全漏洞或或所有客户的面向客户的服务全面中断。SEV 2 事件是“具有重大影响的重大事件”，包括部分客户的面向客户的服务中断或系统中的关键功能无法使用。SEV 3 事件是“影响较小的次要事件”，例如给客户带来轻微不便的系统故障。在 Atlassian，SEV 3 事件可以在白天/工作时间处理，而 SEV 1 和 SEV 2 事件会向待命专业人员发出警报，无论何时均需立即修复。
严重性 | 描述 | 示例 |
|---|---|---|
1 | 产生极大影响的危机事件 | 面向客户的服务（如 Jira Cloud）对所有客户都不可用。 违反了保密或隐私保护政策 丢失了客户数据 |
2 名 | 产生巨大影响的重大事件 | 面向客户的服务对部分客户不可用 核心功能（例如git 推送、事务创建）受到显著影响 |
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 级严重性 | 影响极大的严重事件。例如：Jira 等面向客户的服务在所有客户中全面中断。 | ← | ← |
2 级严重性 | 产生巨大影响的重大事件。例如：面向客户的某项服务在部分客户中出现中断。 | ← | ← |
3 级严重性 | 产生较小影响的轻微事件。例如：某一系统缺陷给客户造成轻微不便。 | 若不及时处理则可能升级为重大事件的隐患事件。例如：一小部分客户的部分功能丧失。 | ← |
4 级严重性 | 不适用 | 激怒客户但不影响整体系统功能的支持请求。 | 影响产品可用性但未导致其瘫痪的轻微事件。例如：加载速度慢于平均水平。 |
5 级严重性 | 不适用 | 不适用 | 不影响产品可用性的缺陷或支持问题。例如：徽标显示位置错误，或部分遮挡了标题的最后一个字母。 |
必须有一个事件管理解决方案来升级事件，以便合适的团队迅速集结，开始解决问题。
了解 Jira Service Management 的所有事件管理功能（包括警报和待命值班表、协作沟通以及强大的报告和分析功能）如何使团队能够响应、解决事件并从中吸取经验教训。