事件管理流程图 — Excel

简而言之

• 四条泳道，每一个步骤都有具名负责人：报告人／用户、服务台、事件经理，以及二线／三线支持，横跨从检测到关闭的五个阶段。
• 检测与登记：检测到或收到事件报告先进入登记事件并记录影响详情，然后才开始分流，因此工单本身就带有受影响服务、波及范围和症状。
• 分类与优先级判定，随后是是否为重大事件？决策，其是分支在事件经理泳道中执行宣布重大事件和开启应急会议并通知干系人，然后再汇回技术工作。

源数据表: 事件管理流程图

在 Excel 中每行记录一个步骤，并填写唯一编号、说明、下一步和负责人。 事件管理是在出现故障之后尽快恢复正常服务的流程。它的目标被刻意收窄：让用户重新开始工作。找出并永久消除底层原因属于问题管理，本流程把这部分工作移交出去，而不是把它吸收进来。正是把这条边界维持清晰，才使服务台不会为了让工程师追查根因而把工单一挂就是好几周。

将说明映射到 Box text，将目标映射到 Line to，将分支名称映射到 Line text，将负责人映射到 Vertical lane。 多数事件流程失败在交接处，而不是在技术工作上。工单被登记时缺少足够的影响信息，无法据此判定优先级。重大事件晚了二十分钟才被识别，因为没有人事先约定触发条件。升级到二线的工单无人认领。SLA 目标被错过，而客户是在事后而不是事前才听说。工单凭工程师一句话就被关闭，用户并没有确认服务确实可用。把流程画成泳道，能让每一处交接都可见，并为它指定一位负责人。 对照数据表检查图中的所有分支和责任人。 另请参阅 /zh/guides/如何整理-excel-流程图数据.

运作方式

1. 把泳道改成你们真实的角色

   在 Excel 中每行记录一个步骤，并填写唯一编号、说明、下一步和负责人。 把报告人／用户、服务台、事件经理和二线／三线支持换成你们组织中真实存在的角色。小团队常把事件经理并入服务台泳道；设有 NOC 的团队会在报告人之上增加一条监控泳道。

2. 定义你们的优先级矩阵

   将说明映射到 Box text，将目标映射到 Line to，将分支名称映射到 Line text，将负责人映射到 Vertical lane。 把你们对影响度和紧急度的定义附在分类并设定优先级步骤上。写清楚 P1 到 P4 分别在受影响用户数和业务影响上意味着什么，让优先级是推导出来的，而不是每张工单都要重新谈判。

3. 设定重大事件的触发条件

   分享前，沿着正常路径、拒绝路径和回环逐一检查图表。 决定什么情况会让是否为重大事件？得到是：某项影响营收的服务中断、某个具名的关键系统、某个客户数量阈值。指明谁有权宣布，以及宣布之后立即会发生什么，例如开启应急会议并启动固定频率的通报。

应避免的错误

• 缺少连接

  只有明确每一步的目标，并为每个决策结果命名，任务清单才会成为流程图。 编写或更新服务台操作手册，让新坐席一眼看到工单会走向哪里、每个阶段由谁负责。

常见问题

可以使用自己的 Excel 文件吗？

可以。将列映射到 QueryChart 工作表编辑器，调整行后再次核对目标位置。 事件管理恢复服务。问题管理消除原因，让事件不再复发。两者运行在不同的时钟上：事件按分钟或小时对照 SLA 衡量，而一份问题记录可以为了调查而开放数周。在本图中，两者在关闭处连接——根因是否仍未知？提起一份问题记录，同时并不让事件继续挂着。把两者混在一起是最常见的失败，其表现就是用户早已恢复工作、工单却仍然长期开放。

什么时候应当把一次事件宣布为重大事件？

当影响大到值得打破正常队列时：某项业务关键服务不可用、一大批用户被阻塞，或者存在安全、财务或声誉方面的暴露。触发条件应当在你需要用到它之前就写下来，并且客观到一线坐席在凌晨两点也能套用。一旦宣布，流程会改变形态，而不只是加快速度。一位具名的事件经理接过责任，应急会议开启，并且不论是否有新进展，都按固定节奏向干系人发出通报。

当一次事件即将违反 SLA 时会发生什么？

违约分支是一次层级升级，而不是技术升级。工作仍在继续，但事件经理被拉进来重新调整与客户的预期、在必要时重新调配资源，并记录目标为何未能达成。关键细节在于时机：这条分支应当在时限过去之前触发，依据的是诸如剩余时间已用掉百分之七十五这样的阈值，好让与客户的沟通发生在违约之前，而不是事后的一句道歉。