如何创建事件管理流程
如何设计一条让严重程度决定后续一切的事件管理流程：先定级再诊断，把重新定级画成一条路径，并把原因交给一份独立的问题记录。
事件管理流程按事件的严重程度选定一条恢复服务的路径，等服务回来之后，再把尚未回答的原因问题交给一份独立的问题记录。
简而言之
- 优先级由登记时采集的字段算出来，而不是由这次事件感觉有多糟来定。
- 所有事件走同一条路径，对小事太重，对大事又太安静。
- 事中提高或降低严重程度需要自己的一条画出来的路径，而多数图都漏了它。
- 恢复服务和解释清楚是两条流程，中间隔着一次交接。
- 关闭需要报告人的确认，而不是工程师的自信。
严重程度不是一个字段，它就是流程
事件管理先恢复服务，再交代究竟发生了什么。多数组织第一版画出来的是一条单行道——登记、诊断、修复、关闭——而它在两个方向上同时失效。对一台谁也够不着的打印机来说，它过于隆重，于是大家干脆不提工单，改成直接打电话给同事；而对一次本该把三个人从床上叫起来的中断来说，它又安静得离谱。
优先级是在任何人搞清楚哪里坏了之前，根据影响和紧急程度定下来的，而它之后的一切都由这一次判断来定尺寸：叫醒谁、相关方多久收到一次消息、修复对着哪一只时钟计时。因此定级是承重的那一步，而它偏偏是在信息不全的情况下做出的——所以它有时候一定会错，这就意味着重新定级应当作为一条画出来的路径留在图上，而不是悄悄改一个字段。
示例把一次事件铺在五个阶段、四条泳道上，其中最值得盯着看的一行是“调查并诊断”：一次已宣告的重大事件，和一张一线修不了的工单，最后落进同一个方框。严重程度决定的是叫谁来、哪只时钟在走，而不是最终由谁去做诊断——这就是这张图在按严重程度配置投入这件事上诚实的边界。另外请注意，“根本原因是否仍不明？”对所有严重程度都只在同一个位置发问，这正是一次 P1 和一次 P4 留下同样证据的原因。
一次定级，决定其后一切
看看在有人开始诊断之前，“是否为重大事件？”就已经定下了多少事：一条指挥通话线、一次相关方通报，以及所属泳道的更换。
工单单薄，优先级就错
登记占两行：“发现或报告事件”和“登记事件并记录影响”。优先级所依据的一切都在第二行采集——受影响的服务、涉及多少人、什么时候开始、有哪些症状——所以一张单薄的工单不是拖慢定级，而是污染定级。
严重程度决定后续尺寸
“是否为重大事件？”的“是”出口并不是同一条路径的加大音量版：“宣告重大事件”和“开通指挥通话并通知相关方”都发生在任何人开始诊断之前，负责方也从服务台换成事件经理那条泳道。“否”那一支紧接着到来。
通往服务恢复的两条路
“一线是否已解决？”让小事保持简短：它的“是”出口通往“执行一线修复”。其余的汇入二线／三线支持泳道，那里的“是否在 SLA 目标内解决？”是在诊断之后才发问的——所以“升级超时并向相关方通报”报告的是一次来不及预防的超时。
重新打开会跳过定级
“用户是否确认已解决？”的“重新打开”出口重新进入“进行初步诊断”，而那一行位于定级之下——所以一次被重新打开的事件会再诊断一遍，却从不重新定级，无论第二次失败到此刻已经付出多少代价。“建立问题记录”是原因离场的地方。
运作方式
先写优先级矩阵，再画图
优先级是影响对紧急程度，两者都需要写明分级：涉及多少用户、属于哪一档服务、是否牵涉资金或人身安全、损害扩大得有多快、有没有可用的临时方案。请先把这些定下来，因为一份边画图边现编的矩阵，描述的是上一次事件，而不是下一次。
想清楚宣告重大事件到底改变什么
把这次宣告换来的东西列出来：一位具名负责人、一条指挥通话线、按固定时点发布的进展、绕过常规变更审批的授权。如果除了标签之外什么都没变，这条分支就是装饰。示例在这上面花掉了整整两个步骤，那正是它诚实的工作量。
把登记和定级写成行
在 QueryChart 里，每一行就是一个方框。把触发事件填进“方框文字”列，接着是登记步骤，再接着是定级步骤，并在“连线至”列里让每一行指向下一行。三行下来，这张图就已经把话说完了：第 3 行的优先级是由第 2 行采集到的东西算出来的，这让第 2 行成为一个设计决定，而不是一张表单。
把定级分叉，并给两个出口都标上字
把定级那一行的“形状”列改成“决策”，把两个去向都列进“连线至”，再在“连线文字”里为每个行号配上它的答案。矩阵有四到五个级别，而图只在“是否为重大事件？”这里分叉一次——这一对标签比这里任何一对都更能干活，因为只有这里路径会改变。
让重新打开的路径指向更小的行号
报告人不认可的修复要退回诊断：第 15 行的“重新打开”出口指向第 7 行。定错的严重程度需要同样的处理，而示例并没有画出来——请从诊断那几行加一条分支回到“分类并设定优先级”。两者在“连线至”列里都是一个更小的数字。
校准矩阵，再指名谁有权宣告
把矩阵放在登记工单的人看得到的地方，然后测试它：给两个不同班次的人同样三段描述，比较他们各自定出的级别。不一致说明缺了一个级别，而不是同事不用心。然后指名每个班次里在事件经理还没醒之前，有权在“是否为重大事件？”上回答“是”的那个人。
应避免的错误
诊断之后才定级
到那时候，真正重要的那次升级已经没有发生，优先级字段记录的只是结果有多糟。影响和紧急程度在原因明确之前就能回答，这正是定级那一行排在第三位的原因。
一出生就带着的严重程度
影响会变大，优先级不会。它在服务台泳道里定下一次，就锁死了呼叫名单和那只时钟，而图上唯一一条向后的路径又重新进入它的下方。请把重新定级画成一条路径，并指名谁有权走。
靠新开工单来重新打开
原来那张在目标内关闭，第二张开始跑一只全新的时钟，报表上于是显示两次快速修复，而不是一次失败的修复。请把重新打开画成在同一条记录上退回诊断。
问题记录没有负责人
“建立问题记录”是一行，不是一个结果。一份没有负责人、没有日期、也没有链回它所源自的那些事件的记录，就是关闭用的文书工作，下次清理时会被无人过目地关掉。请在建立它的时候就把这两样都指名。
创建你们的事件流程
把事件示例作为你们自己的图表打开，把你们的严重程度门槛填到定级那一行，把值班角色填进泳道。
相关指南
常见问题
事件和问题有什么区别？
事件是服务的一次中断；问题是一次或多次事件背后的原因。它们被当作两条独立的流程，是因为跑的时钟不同——事件管理衡量的是恢复所需的时间，问题管理衡量的是原因是否真的被消除，而后者可能要花上几周。把两者合并，意味着找原因的工作会继承事件的紧迫感，然后在服务一恢复的那一刻就被放下。
事件优先级怎么定？
由一份公开矩阵上的影响与紧急程度决定，而不是由谁在催决定。影响是指组织受到多大范围的波及：用户、站点、服务档次、是否牵涉资金或人身安全。紧急程度是指损害扩大得有多快，以及有没有可用的临时方案。矩阵把这一对转换成优先级，而它只有在支撑这次判断的数据被一并记录下来时才站得住——一个没人能复盘出来的优先级，在事后被证明定错时也无从质疑。
什么时候应当把一次事件宣告为重大事件？
当它越过一条事先约定的门槛时——一档核心服务中断、达到某个人数的员工无法工作、监管或安全方面的暴露、疑似发生泄露。这次宣告只有在它改变行为的时候才站得住：一位具名的事件经理、一条指挥通话线、按固定节奏发布的更新。常见的失误是宣告得太晚，而先宣告、再解除的代价，远低于安静一个小时的代价。
被重新打开的事件应该另开一张工单吗？
不应该——重新打开原来那一张，因为这两份记录回答的是不同的问题。新开一张会重置解决时钟，并把一次失败的修复报成两次成功的修复，而这恰恰是掩盖服务不稳定的那种失真。在同一条记录上重新打开，能把历史留在一个地方，也让重新打开率变得可以衡量——而重新打开率，是一条事件流程能产出的最诚实的质量信号。
