事件管理流程图
跨职能的事件管理流程图，涵盖事件登记、优先级判定、重大事件升级、SLA 违约预警、修复恢复、用户确认关闭与问题记录移交。
运作方式
把泳道改成你们真实的角色
把报告人／用户、服务台、事件经理和二线／三线支持换成你们组织中真实存在的角色。小团队常把事件经理并入服务台泳道；设有 NOC 的团队会在报告人之上增加一条监控泳道。
定义你们的优先级矩阵
把你们对影响度和紧急度的定义附在“分类并设定优先级”步骤上。写清楚 P1 到 P4 分别在受影响用户数和业务影响上意味着什么，让优先级是推导出来的，而不是每张工单都要重新谈判。
设定重大事件的触发条件
决定什么情况会让“是否为重大事件？”得到“是”：某项影响营收的服务中断、某个具名的关键系统、某个客户数量阈值。指明谁有权宣布，以及宣布之后立即会发生什么，例如开启应急会议并启动固定频率的通报。
接入你们的 SLA 目标与违约升级
把你们的响应和解决目标放在“是否在 SLA 目标内解决？”决策上，并写明违约分支上通知谁、提前多久通知。这条分支的意义在于提前预警，而不是事后报告。
约定关闭与问题管理的规则
定义什么算作用户已确认、工单在“已解决”状态下多久之后自动关闭，以及“根因是否仍未知？”上把事件推入问题管理的判定标准。反复出现的症状和每一次重大事件是常见的触发条件。
与每条泳道走查一遍，然后发布带版本的副本
与每条泳道中的人一起评审这张图，修正他们实际执行的步骤。达成一致之后，把它作为当前版本发布并附上签署确认，这样日后读到它的人就知道当时生效的是哪一版。
常见问题
事件管理和问题管理有什么区别？
事件管理恢复服务。问题管理消除原因，让事件不再复发。两者运行在不同的时钟上：事件按分钟或小时对照 SLA 衡量，而一份问题记录可以为了调查而开放数周。在本图中，两者在关闭处连接——“根因是否仍未知？”提起一份问题记录，同时并不让事件继续挂着。把两者混在一起是最常见的失败，其表现就是用户早已恢复工作、工单却仍然长期开放。
什么时候应当把一次事件宣布为重大事件？
当影响大到值得打破正常队列时：某项业务关键服务不可用、一大批用户被阻塞，或者存在安全、财务或声誉方面的暴露。触发条件应当在你需要用到它之前就写下来，并且客观到一线坐席在凌晨两点也能套用。一旦宣布，流程会改变形态，而不只是加快速度。一位具名的事件经理接过责任，应急会议开启，并且不论是否有新进展，都按固定节奏向干系人发出通报。
当一次事件即将违反 SLA 时会发生什么？
违约分支是一次层级升级，而不是技术升级。工作仍在继续，但事件经理被拉进来重新调整与客户的预期、在必要时重新调配资源，并记录目标为何未能达成。关键细节在于时机：这条分支应当在时限过去之前触发，依据的是诸如剩余时间已用掉百分之七十五这样的阈值，好让与客户的沟通发生在违约之前，而不是事后的一句道歉。
由谁关闭事件，什么才算已解决？
解决和关闭是两种不同的状态。工程师在修复实施完毕、服务恢复时把事件标记为已解决。只有当报告人确认服务对他们确实可用之后，事件才被关闭——这正是本图在关闭之前要经过报告人泳道中的“确认服务已恢复”和“用户是否确认已解决？”决策的原因。如果用户表示问题依旧存在，工单会重开回到初步诊断，而不是新建一张。多数团队还会设定一个自动关闭窗口，通常是三到五个工作日无回应。