优先级矩阵是什么
事件优先级由影响（影响多少用户与业务）与紧急度（恶化速度、有无临时方案、时间敏感性）共同决定，常见做法是用矩阵把两者的组合映射到 P1-P4。有两个关键点：用户填报的“紧急”只是输入，并不等于优先级；优先级必须驱动人的行为，包括告警路由、值班呼叫、响应时限与汇报层级，否则分级只是一个标签。
基本信息
| 判定输入 | 影响面 + 紧急度 |
|---|---|
| 常见级数 | P1-P4（行业约定，ITIL 未强制规定） |
| 影响面判据 | 受影响用户数、业务功能、金额与合规影响 |
| 紧急度判据 | 是否持续恶化、有无临时方案、时间敏感性 |
| 必须驱动 | 响应时限、告警路由、升级规则、汇报层级 |
| 责任人 | 服务台初判，二线可调整并留痕 |
典型使用场景
- 新故障受理：按矩阵初判优先级，决定是否立刻呼叫值班
- 同批告警排序：值班队列按优先级与影响面排序处置
- 升级触发：高优先级事件在时限内未恢复，自动逐级升级
- 值班排班：不同优先级对应不同的呼叫层级与到场要求
- 报表与复盘：统计各级别数量与超时比例，识别分级是否失真
- 与业务对齐：把矩阵交给业务方确认，避免口径分歧
优先级映射示例
| 影响面 | 紧急度高 | 紧急度低 |
|---|---|---|
| 影响面大（核心业务、大范围用户） | P1 立即处置，全时呼叫人 | P2 尽快处置，按值班流程 |
| 影响面中（部分用户或次要功能） | P3 排期处置，纳入当日队列 | P4 常规处置，按队列处理 |
| 影响面小（个别用户） | P3 当日处理 | P4 常规处置 |
分级落地要点
分级落地要点
优先级 = 影响 × 紧急度（按矩阵映射）
用户填报的紧急程度仅作输入，不直接等于优先级
分级规则与响应时限写入值班手册，并进入工单系统自动化
反例：所有工单都标 P1，等于没有分级，高优事件被稀释ITIL 未规定固定级数，P1-P4 为实践约定；分级规则需与业务方共同确认并写入值班手册，并随业务变化定期复核。
优先级如果不能推动告警与呼叫，夜间的高优事件依旧可能躺在队列里到天亮，分级就失去意义。
影响面与紧急度判定线索
- 影响面：受影响用户比例、核心功能是否可用、是否有资金或合规风险
- 影响面：是否只有单一客户或内部用户，能否用临时方案绕行
- 紧急度：故障是否仍在恶化，例如错误率持续爬升、容量继续消耗
- 紧急度：是否存在时间敏感节点，例如结账、开票、监管报送窗口
- 紧急度：有无可用临时方案，绕行手段是否会造成数据不一致
分级要留调整通道：初判后二线可以基于真实情况上调或下调，但必须写下理由，供后续校准规则使用。
与时限配套的设计
- 每个级别定义明确的响应时限与解决时限
- 达到时限一半仍未解决就自动提醒，不允许静默超时
- 超过时限自动升级到上一层级，由管理者协调资源
- 按季度统计各级别时限达成率，据此校准分级规则
分级结果要能被业务看懂：对外沟通时说明影响面与处置动作，比只报一个 P1 更有助于业务方安排应对。