如何创建事件管理流程
如何设计一条让严重程度决定后续一切的事件管理流程：先定级再诊断，把重新定级画成一条路径，并把原因交给一份独立的问题记录。
运作方式
先写优先级矩阵，再画图
优先级是影响对紧急程度，两者都需要写明分级：涉及多少用户、属于哪一档服务、是否牵涉资金或人身安全、损害扩大得有多快、有没有可用的临时方案。请先把这些定下来，因为一份边画图边现编的矩阵，描述的是上一次事件，而不是下一次。
想清楚宣告重大事件到底改变什么
把这次宣告换来的东西列出来：一位具名负责人、一条指挥通话线、按固定时点发布的进展、绕过常规变更审批的授权。如果除了标签之外什么都没变，这条分支就是装饰。示例在这上面花掉了整整两个步骤，那正是它诚实的工作量。
把登记和定级写成行
在 QueryChart 里，每一行就是一个方框。把触发事件填进“方框文字”列，接着是登记步骤，再接着是定级步骤，并在“连线至”列里让每一行指向下一行。三行下来，这张图就已经把话说完了：第 3 行的优先级是由第 2 行采集到的东西算出来的，这让第 2 行成为一个设计决定，而不是一张表单。
把定级分叉，并给两个出口都标上字
把定级那一行的“形状”列改成“决策”，把两个去向都列进“连线至”，再在“连线文字”里为每个行号配上它的答案。矩阵有四到五个级别，而图只在“是否为重大事件？”这里分叉一次——这一对标签比这里任何一对都更能干活，因为只有这里路径会改变。
让重新打开的路径指向更小的行号
报告人不认可的修复要退回诊断：第 15 行的“重新打开”出口指向第 7 行。定错的严重程度需要同样的处理，而示例并没有画出来——请从诊断那几行加一条分支回到“分类并设定优先级”。两者在“连线至”列里都是一个更小的数字。
校准矩阵，再指名谁有权宣告
把矩阵放在登记工单的人看得到的地方，然后测试它：给两个不同班次的人同样三段描述，比较他们各自定出的级别。不一致说明缺了一个级别，而不是同事不用心。然后指名每个班次里在事件经理还没醒之前，有权在“是否为重大事件？”上回答“是”的那个人。
常见问题
事件和问题有什么区别？
事件是服务的一次中断；问题是一次或多次事件背后的原因。它们被当作两条独立的流程，是因为跑的时钟不同——事件管理衡量的是恢复所需的时间，问题管理衡量的是原因是否真的被消除，而后者可能要花上几周。把两者合并，意味着找原因的工作会继承事件的紧迫感，然后在服务一恢复的那一刻就被放下。
事件优先级怎么定？
由一份公开矩阵上的影响与紧急程度决定，而不是由谁在催决定。影响是指组织受到多大范围的波及：用户、站点、服务档次、是否牵涉资金或人身安全。紧急程度是指损害扩大得有多快，以及有没有可用的临时方案。矩阵把这一对转换成优先级，而它只有在支撑这次判断的数据被一并记录下来时才站得住——一个没人能复盘出来的优先级，在事后被证明定错时也无从质疑。
什么时候应当把一次事件宣告为重大事件？
当它越过一条事先约定的门槛时——一档核心服务中断、达到某个人数的员工无法工作、监管或安全方面的暴露、疑似发生泄露。这次宣告只有在它改变行为的时候才站得住：一位具名的事件经理、一条指挥通话线、按固定节奏发布的更新。常见的失误是宣告得太晚，而先宣告、再解除的代价，远低于安静一个小时的代价。
被重新打开的事件应该另开一张工单吗？
不应该——重新打开原来那一张，因为这两份记录回答的是不同的问题。新开一张会重置解决时钟，并把一次失败的修复报成两次成功的修复，而这恰恰是掩盖服务不稳定的那种失真。在同一条记录上重新打开，能把历史留在一个地方，也让重新打开率变得可以衡量——而重新打开率，是一条事件流程能产出的最诚实的质量信号。