事件严重等级分级流程图

什么是事件严重等级分级流程

事件严重等级分级，是把一份报告转化为一个等级的那一步。有人读取证据，套用一组事先约定的判定，得出 P1、P2、P3 或 P4，而下游的一切都以这个答案为准。一开始就把它与优先级区分开是值得的，因为这两个词常被混用，然后在事件当中被拿来争论。严重等级描述的是影响，因而也决定了你所欠的响应：谁被呼叫、是否开启应急会议、多久向干系人通报一次。优先级描述的是排序：团队接下来拿起哪一件。严重等级依据证据评定，只有在证据变化时才变化；优先级则可以每天早上重设一次，而不必有人重新打开影响评估。

本页是一棵决策树，而不是一张流程图，这也正是它单独存在的理由。它回答一个问题：这次事件该定为哪个等级，以及谁有权决定——办法是把七道判定串联起来，直到每条路径都抵达一个具名的结果。它刻意止于等级被确定的那一刻。如果你需要的是那之后的端到端流程——工单如何在服务台、事件经理和各级支持之间被诊断、升级、解决、与用户确认并关闭——请使用 /zh/templates/事件管理流程 上的事件管理流程图。用本图来决定等级；用那一张来推进工作。

这里的泳道命名的是决策权，而不是部门，而这恰恰是多数严重等级矩阵留作默认的部分。服务台回答从报告中就能观察到的内容：服务是不可用还是降级，以及有多少用户或站点受到影响。服务负责人回答某项关键业务职能或营收路径是否真的被阻塞。事件经理负责临时解决方案的判定、宣布本身以及复盘。法务与合规只负责两个问题，别无其他：是否存在数据或安全暴露，以及是否有监管或合同的时钟正在走。四条泳道足以了结“谁来决定”的争论，而不必画出一张组织架构图。

本流程图涵盖的内容

本模板包含

• 四条决策权泳道，而不是一张部门图（服务台、服务负责人、事件经理、法务与合规），横跨五个评估阶段：接报、影响范围、业务影响、严重等级判定，以及结果与复盘。
• 开场的判定“服务是不可用还是降级？”有三个答案：“不可用”和“降级”继续进入决策树，而“无影响”当即终止于“作为服务请求关闭”，因此一项请求或咨询永远不会被贴上严重等级。
• 范围在业务影响之前评估：“受影响的用户或站点有多少？”分为“多个站点”，直接走向宣布 P1；“一个团队”，交给服务负责人；以及“单个用户”，仍然要检查是否存在暴露。
• 两条独立通往关键级的升级路径：“关键职能或营收是否被阻塞？”接入“是否有可行的临时解决方案？”，其中“无临时方案”宣布 P1，“有临时方案”定为 P2；以及“是否存在数据或安全暴露？”，其中“存在暴露”不论受影响用户多么少都宣布 P1。
• 矩阵的低端由一个问题决定：“是否已启动 SLA 或监管时钟？”，把“P3 中等，跟踪期限”与“P4 低，排期处理”分开，而不是留给个人判断；连同“P1 关键，应急会议进行中”“P2 高，修复进行中”以及作为服务请求关闭的出口，全图共有五个终点，另有一条明确的重新分级路径——“下一次通报时影响是否变化？”把“影响扩大”送回宣布 P1。
• 在关键决策上写明的成文标准：不可用意味着什么、用户数和站点数的阈值定在哪里、什么才算可行的临时解决方案，以及为什么一次暴露无论范围大小都按关键级处理。

何时使用本模板

• 把团队目前还在争论的严重等级定义写下来，好让凌晨三点分流同一次事件的两个人，不必谈判就能得出同一个等级。
• 配置一套把严重等级设为必填字段的 ITSM 或值班工具，而你需要的是每个等级背后的判定，而不是一个只有四个选项、毫无指引的下拉框。
• 在故障发生之前而不是在故障当中约定决策权：谁可以宣布 P1、谁来确认数据或安全暴露，以及谁有权重新分级。
• 复盘一次过去的事件，检查所定的等级是否与当时可得的证据相符——这与响应做得好不好是两个不同的问题。
• 带值班工程师和新的服务台坐席入门，他们需要一页纸看清那些问题、阈值，以及每个答案的落点。

运作方式

1. 把泳道改成你们真实的决策权

   把服务台、服务负责人、事件经理、法务与合规换成你们组织中真正握有每一项判定的角色。如果非工作时间没有人负责数据或安全这个问题，那是一个需要在重画泳道之前先补上的排班缺口。

2. 把你们的范围阈值写到图上

   打开“受影响的用户或站点有多少？”，把说明换成你们自己对多个站点、一个团队和单个用户的定义：一个区域、一个客户层级、活跃用户的一个百分比、一份具名客户清单。没有写下来的阈值，每次事件都会被重新商量一遍。

3. 为你们的服务界定不可用与降级

   逐个服务约定“不可用”意味着什么，包括部分可用的情形，例如只读模式、某个区域故障，或者队列仍在接单但没有在处理。这里的含糊会让整棵树整体偏移一个等级。

4. 诚实地设定临时解决方案的判定

   决定什么样的临时解决方案才算可行：有文档、被允许、在产能之内，并且受影响的用户今天就能用。一个需要培训、额外人手或政策例外的手工替代做法不算临时解决方案，而把它当作临时解决方案，是 P1 被记成 P2 最常见的方式。

5. 为每个结果附上各不相同的响应承诺

   “P1 关键，应急会议进行中”“P2 高，修复进行中”“P3 中等，跟踪期限”和“P4 低，排期处理”每一个都应当带有自己的呼叫规则、通报频率和目标时间。如果两个等级产生的行为完全相同，就把它们合并，而不是留着一个谁也分不清的等级。

6. 约定谁可以重新分级，并记录理由

   “下一次通报时影响是否变化？”这一决策是变更等级唯一被认可的途径。指明谁可以走这条路，要求把各项判定重新跑一遍，而不是把等级拿来重新谈判，并记录新的证据和时间，好让事后复盘看得出情况是在什么时候改变的。

7. 把图分发签署并保留版本

   严重等级标准只有在是大家共同认可的那一套时才有用。把这张图交给服务管理、各服务负责人和法务签署确认，然后保留获批版本，好让你们演练的定义就是你们发布的定义。

常见问题

事件严重等级和事件优先级有什么区别？

严重等级是一项关于影响的陈述：服务坏掉了多少、影响多少人、这挡住了什么。优先级是一项关于排序的陈述：团队接下来拿起哪一件。ITIL 其实并不把“严重等级”当作正式术语，它由影响度和紧急度推导出优先级。许多工程和 SRE 团队把严重等级当作影响那一半的简称，本图也是这样使用它的。可操作的规则是：严重等级驱动你所欠的响应（呼叫、应急会议、通报频率），且只在证据变化时才变化；而优先级驱动队列，可以每天重设。为两者各保留一个字段，可以避免有人为了获得更快的服务而去重新谈判影响评估。

这与事件管理流程图有什么不同？

它们就同一个主题回答不同的问题。本图是一棵决策树：这次事件该定为哪个严重等级，以及谁有权决定。它是一串以具名结果结尾的判定，并在等级确定的那一刻立即停止。事件管理流程图则是一张跨职能流程图：接下来会发生什么、由谁来做，从登记一直到诊断、升级、解决和关闭。多数团队两者都需要，而它们恰好只在一个点上连接，就是分派等级的那一步。流程版本位于 /zh/templates/事件管理流程。

我们应当设置多少个严重等级？

四个是常见的默认做法，也是本图采用的数量，有些组织会在其上再加一个 P0 或 SEV0 用于生死攸关的事件。数量本身不如每个等级是否带有各不相同的成文响应来得重要。如果 P3 和 P4 导致相同的呼叫规则、相同的目标时间和相同的通报频率，那你实际上只有三个等级和一个用不上的标签。少而一致地执行，胜过多而松散地执行，因为分级的价值就在于下游所有人都能据此行动而不必再问。

谁有权宣布 P1？

提前指名角色，并把名单保持简短。在本图中，宣布落在事件经理泳道，有三条分支汇入其中：多站点中断、关键职能被阻塞且没有可行的临时解决方案，以及已确认的数据或安全暴露。这个结构是刻意的，因为 P1 应当可以由多个方向的证据抵达，但应当由一个同时能够调动响应的角色来宣布。任何人都应当可以请求 P1；由一个具名角色来确认它。

数据或安全暴露是否自动使一次事件成为 P1？

在本图中是的，而且暴露分支会完全绕过用户数量判定。原因在于，一次暴露启动的时钟是按知悉时刻而不是按解决时刻计算的，因此一次很小的事件也可能承载很大的义务。在英国和欧盟 GDPR 之下，个人数据泄露必须在不当延误的情况下、并在可行时于知悉后 72 小时之内通报监管机关，而通知受影响的个人是另一项与高风险挂钩的判定。其他制度和合同各有自己的时限，客户通知期限往往比法定期限更短，因此请把适用于你们的那些写在决策方框上。许多组织还会把暴露完全引出这棵树，转入安全事件响应流程。

严重等级确定之后，什么时候才应当更改它？

在证据变化时，而不是在压力变化时。本图为此只留了一条路径，即“下一次通报时影响是否变化？”决策，其“影响扩大”分支把一个 P2 送回宣布 P1。把各项判定重新跑一遍，而不是重新挑起争论，并记录新到的证据是什么、在什么时候到的。降级遵循同样的规则，也值得明确处理，因为一次在影响已经消退之后仍停留在 P1 的事件，会悄悄训练人们无视等级。