3. 事故响应流程：事故的生命周期、事故优先级与影响度、事故升级机制
事故响应流程是ITSM服务目录中最核心的动态环节。理解事故的完整生命周期、科学的优先级与影响度评估模型，以及自动化的升级机制，是配置故障自愈策略的前提。本节将围绕这三个关键维度展开，帮助你在服务目录中建立标准化的响应框架。
3.1 事故的生命周期
一个事故从被记录到最终关闭，会经历一系列标准阶段。每个阶段都对应特定的处理动作和状态标记，故障自愈系统通常会在“诊断”和“恢复”阶段介入。
| 阶段 | 状态 | 关键动作 | 自愈介入点 |
|---|---|---|---|
| 1. 发现与记录 | 新建 | 用户/监控系统创建工单，记录症状、时间、影响范围 | 监控告警自动触发工单创建 |
| 2. 分类与初步支持 | 已分配 | 服务台根据症状匹配服务目录项，分配处理组 | 自动匹配自愈剧本（Runbook） |
| 3. 诊断与调查 | 处理中 | 技术团队分析根因，执行诊断脚本或人工排查 | 执行预定义诊断脚本，收集日志 |
| 4. 恢复与解决 | 已解决 | 执行修复操作（重启、回滚、扩容等），验证服务恢复 | 执行自动化恢复动作，验证健康状态 |
| 5. 关闭 | 已关闭 | 确认用户满意，更新知识库，关闭工单 | 自动关闭工单，生成自愈报告 |
关键认知： 故障自愈系统主要作用于第3阶段（诊断）和第4阶段（恢复）。如果自愈成功，事故将跳过人工处理环节，直接从“处理中”进入“已解决”状态，大幅缩短平均修复时间（MTTR）。
3.2 事故优先级与影响度
优先级决定了事故处理的紧急程度和资源投入。在服务目录中，优先级通常由影响度和紧急度两个维度共同决定。影响度衡量事故对业务造成的损害范围，紧急度衡量需要多快恢复。
3.2.1 影响度与紧急度矩阵
以下矩阵是ITIL推荐的标准模型，也是配置自愈策略时判断“是否自动执行”以及“执行何种级别自愈动作”的依据。
| 影响度 \ 紧急度 | 高（业务中断） | 中（业务受损） | 低（轻微影响） |
|---|---|---|---|
| 高（大量用户/核心系统） | P1 - 严重 | P2 - 高 | P3 - 中 |
| 中（部分用户/非核心系统） | P2 - 高 | P3 - 中 | P4 - 低 |
| 低（单用户/边缘系统） | P3 - 中 | P4 - 低 | P5 - 计划 |
自愈配置建议： 对于P3及以下优先级的事故，可以配置全自动自愈策略（如自动重启服务、自动清理磁盘）。对于P1/P2事故，建议配置“半自动”或“人工确认后执行”的自愈策略，避免高风险操作造成更大损失。
3.2.2 优先级与响应时间目标
服务目录中必须为每个优先级定义明确的响应时间和解决时间目标（SLA）。这些目标直接驱动升级机制。
- P1（严重）： 响应时间 ≤ 15分钟，解决时间 ≤ 4小时。自动升级至IT经理/架构师。
- P2（高）： 响应时间 ≤ 30分钟，解决时间 ≤ 8小时。自动升级至技术主管。
- P3（中）： 响应时间 ≤ 2小时，解决时间 ≤ 24小时。升级至高级工程师。
- P4（低）： 响应时间 ≤ 4小时，解决时间 ≤ 48小时。按需升级。
- P5（计划）： 响应时间 ≤ 8小时，解决时间 ≤ 120小时。无自动升级。
3.3 事故升级机制
升级机制是确保事故不被遗漏、资源及时到位的关键保障。在故障自愈场景中，升级机制通常分为职能升级和层级升级两种，且可以与自愈失败后的“降级处理”联动。
3.3.1 职能升级（Horizontal Escalation）
当当前处理团队无法解决事故时，将工单转交给更专业的技术团队。例如，从L1服务台升级到L2网络团队或L3数据库团队。在自愈场景中，如果预定义的自愈剧本执行失败，系统应自动触发职能升级，将事故连同诊断日志一并转交。
3.3.2 层级升级（Hierarchical Escalation）
当事故处理时间超过SLA阈值，或事故影响度上升时，需要通知更高级别的管理层介入，以协调资源或做出决策。在自愈配置中，可以设置“自愈失败次数计数器”，当连续失败达到阈值（如3次）时，自动触发层级升级。
避坑指南： 不要将所有事故都配置为“全自动自愈+无升级”。对于P1/P2事故，即使自愈成功，也建议触发“通知升级”动作，让技术主管知晓并确认自愈结果，避免因自动化误判导致业务隐患。
3.4 生命周期状态机与自愈集成
为了在服务目录中精确配置自愈行为，需要将事故生命周期状态与自愈引擎的状态机进行映射。以下是一个典型的状态转换表：
| 事故状态 | 自愈引擎状态 | 允许的自愈动作 | 升级触发条件 |
|---|---|---|---|
| 新建 | 等待诊断 | 触发诊断脚本 | 无 |
| 已分配 | 诊断中 | 执行诊断，匹配Runbook | 诊断超时（>5分钟） |
| 处理中 | 恢复中 | 执行恢复脚本（重启/扩容/回滚） | 恢复失败或SLA时间过半 |
| 已解决 | 验证中 | 执行健康检查，确认服务恢复 | 健康检查失败 |
| 已关闭 | 已完成 | 生成自愈报告，更新CMDB | 无 |
架构要点： 在配置故障自愈时，务必在服务目录中为每个事故模板绑定“升级策略模板”。该模板应包含：升级触发条件（时间/失败次数/影响度变化）、升级目标（职能组/管理层）、升级通知方式（邮件/短信/IM）。这样，当自愈流程出现异常时，系统能够自动、有序地升级，避免事故被“卡”在自动化流程中。