事件管理流程：从报障到关闭的完整步骤、角色和处理时限

简短回答： 事件管理流程把一次服务中断从报障到关闭按固定顺序走完：发现并登记、分类、定优先级、诊断、解决、关闭。目标是尽快恢复正常服务，并把对业务的影响降到最低。每一步都要有负责人、转入下一步的规则和时限，每张工单都要留下足够的记录，让下一个接手的人不必再问一遍用户。

本文写给想建立或理顺日常事件流程的中小企业 IT 负责人和服务台主管。读完后，你可以写出步骤、定好角色、设置时限，并使用工单模板。重大事件（少见的大范围故障）有单独的流程，见重大事件管理；本文讲的是普通事件的完整生命周期。

什么是事件？

据维基百科对事件管理的概述（2026 年 10 月 28 日核对），ITIL 2011 把事件定义为：IT 服务的计划外中断、服务质量的下降，或尚未影响服务的配置项故障。同一篇文章说，该流程的目的是尽快恢复正常的服务运行，并把业务影响降到最低。

ITIL 4 于 2019 年 2 月发布，把指引组织为实践（practice）而不是流程，所以在 ITIL 4 里你可能会看到它被称为事件管理实践；下面的步骤是服务台的常见做法，不声称与 ITIL 一致（2026 年 10 月 28 日核对）。

由此得出两点：

1. 先恢复服务。 找出根本原因是另一个流程（问题管理）。事件可以用临时解决办法关闭。
2. 请求不是事件。 新员工电脑、权限申请属于服务请求，走自己的流程。服务请求和事件的区别一文划清了界线。

六个步骤

不同资料对步骤的数法不同，有五步、六步、七步，区别在于怎样合并发现、登记和分类。实际顺序是一样的。选团队记得住的那种分法即可。

第一步：发现并登记

目标： 每个事件都成为一张有编号的工单。

1. 接受所有渠道的报告：门户、邮件、电话、聊天，以及监控的自动告警。
2. 首次联系时就建单，先建单再动手修。
3. 记录谁受影响、什么服务、看到了什么（附准确的报错文字或截图）、何时开始、怎样联系到对方。
4. 检查是否重复或已知问题。如果已有故障工单，把新工单关联上去。

负责人： 服务台（L1）。时限示例： 联系后数分钟内登记。

第二步：分类

目标： 放进正确的类别，让它到达合适的人手里。

1. 从一份简短固定的清单里选类别和子类别，例如邮件、网络、设备、应用、账号访问、安全。
2. 如果你管理配置项，关联受影响的服务和配置项（设备或系统）。
3. 此时标记疑似安全事件，立即转入安全处理路线。

负责人： 服务台。类别清单要短；清单太长，填的人会乱填。

第三步：定优先级

目标： 决定它需要多快得到处理。

1. 设定影响度（多少人或多大范围的业务受影响）和紧急度（业务多快需要修好）。
2. 按你的影响度和紧急度矩阵得出优先级。严重程度和优先级不是一回事，P1 到 P4 优先级说明各级怎样对应响应目标。
3. 事实变化时，允许服务台调整优先级，并写明原因。

负责人： 服务台，最高级别由事件经理参与。时限： 首次响应目标开始计时之前，优先级就要定好。

第四步：诊断与调查

目标： 找到修复办法或临时解决办法。

1. L1 初步诊断。 使用知识库和脚本。问工单里还没有答案的问题。如果是已知修复办法，直接执行。
2. 升级： 问题超出 L1 范围、超过时限，或出现风险（数据丢失、安全、大范围影响）时升级。用 L1、L2、L3 分级说明谁做什么，联系人见升级矩阵模板。
3. 每次升级写交接记录： 影响了什么、试过什么、下一步需要什么。
4. 按该优先级约定的间隔向用户通报, 即使没有新进展也要通报，并说明下次更新时间。
5. 厂商： 原因看似产品故障时，向厂商开案例，并把案例编号记在工单上。

负责人： 先是 L1，然后是 L2、L3 或处理小组。时限示例： 到该优先级的升级时间仍无进展，就往上转。

第五步：解决与恢复

目标： 用户那边的服务重新可用。

1. 实施修复或临时解决办法。超出标准范围的改动走变更控制，紧急变更走紧急通道。
2. 向用户确认确实可用，而不是只看系统显示正常。
3. 记录解决办法：做了什么、为什么有效、是临时办法还是永久修复。
4. 原因不明或只是临时办法时，创建问题记录，以便日后调查原因。
5. 把工单设为「已解决」，并告知用户。

负责人： 修复的人。时限： 该优先级的解决目标。

第六步：关闭

目标： 一条干净、可检索的记录。

1. 向用户确认， 或在设定时间内无回复就自动关闭。起点可以是几个工作日，自行设定并告知用户。
2. 检查记录： 类别正确、已写解决办法、已记录工时、关联记录已挂上。
3. 如果这张工单带来了经验，更新知识库。
4. 关闭。 已关闭工单通过新工单，或在约定期限内的跟进来重开。

负责人： 服务台。很多团队每月还会抽查已关闭的工单质量。

角色

小团队会一人兼多角色。关键是每个角色都有人负责。

1. 报障人或用户： 报告事件、回答问题、确认修复。
2. 服务台人员（L1）： 登记、分类、定优先级、执行已知修复、让用户知情。
3. 处理人员（L2、L3 或专门小组）： 处理 L1 以外的诊断和修复。
4. 事件经理（或服务台主管）： 盯队列和时限，接手卡住或高优先级的工单，负责升级。重大事件中的这个角色见另一篇指南。
5. 问题经理： 原因需要调查时接手。
6. 变更经理或审批人： 批准需要变更的修复。
7. 服务负责人和厂商： 为其服务或产品提供决定和支持。

时限示例

以下只是示意目标，不是标准。真正的数值由你的 SLA 决定。博迅（Brocent）公布的响应目标见 SLA 页面。

1. P1（严重），例如： 数分钟内响应，频繁向用户通报，没有进展立即升级，持续处理直到恢复。
2. P2（高）： 一小时内响应，在设定的较短时间后仍未解决就升级。
3. P3（中）： 当个工作日内响应，数天内解决。
4. P4（低）： 一两天内响应，按产能在较长的期限内解决。

定义三个计时：响应时间、升级时间、解决时间。只有在定义好的情况下（例如等用户回复）才暂停解决计时。

工单模板

好的工单包含以下字段，可复制到你的工具里。

摘要:        一行，现象 + 服务
报障人:      姓名、联系方式、位置
受影响:      多少用户，哪个服务/设备
现象:        用户原话、准确报错、截图
开始时间:    日期/时间，之前有何改动
类别:        类别 / 子类别
影响/紧急:   各 高/中/低 -> 优先级
已采取行动:  步骤、结果、谁、时间
升级给:      小组/个人、原因、时间
下次更新:    日期/时间
解决办法:    怎样修好的，临时还是永久
问题记录:    是/否，编号

常见错误

1. 先修后登记。 没有工单的快速修复，会从报表和知识库中消失。
2. 按嗓门定优先级，再加沉默。 不要让谁喊得响谁优先，用影响度和紧急度规则；并按计划通报，因为用户更容易原谅延迟，而不是没有消息。
3. 未经确认就关闭， 导致工单被重开、用户不满。
4. 没有交接记录， 用户在每一级都要回答同样的问题。
5. 把临时办法当最终办法。 原因不明时创建问题记录。
6. 把请求和事件混在一起， 扭曲数据和 SLA。

如何确认流程有效

1. 随机抽五张已关闭工单。每张都应显示谁、什么、何时、采取的步骤、解决办法和时间。
2. 没有任何未关闭工单超过升级时间却没有备注。
3. 用户按你设定的计划得到通报。
4. 每月数字合理：按类别的事件量、按优先级的响应和解决时间、重开率。指标定义见 MTTR、MTBF 和 MTTA。
5. 重复发生的事件带来了问题记录和知识库文章。

常见问题

什么是事件管理流程？

它是一组步骤，把一次 IT 中断从报障带到关闭，使服务得以迅速恢复、业务影响得到控制：登记、分类、定优先级、诊断、解决、关闭。

事件管理流程有哪些步骤？

发现并登记、分类、定优先级、诊断与调查、解决与恢复，最后关闭。不同框架会拆分或合并步骤，所以不同资料里会看到五步、六步或七步。

五步事件管理流程是什么？

常见的五步分法是：识别并登记、分类并定优先级、调查并诊断、解决并恢复、关闭。它与六步顺序相同，只是合并了其中两步。

事件管理流程的六个步骤是什么？

登记、分类、定优先级、诊断、解决、关闭。不同来源分法不同，选团队能一致执行的版本。

下一步

想了解我们对各优先级公布的响应目标，请阅读我们的 SLA 页面。

2026 年 10 月 28 日核对的来源：维基百科「Incident management」条目（en.wikipedia.org/wiki/Incident_management），其中引用了 ITIL 2011 的定义。