ITIL 4 讲解：Event，Incident 和 Crisis, 流程如何界定？

这个话题源自客户的提问：如果监控报告发生了异常，

1. 运维团队处理了，这算是Even还是Incident管理流程?

2. 如果没有处理，异常越来越严重（当然处理的时候也有可能问题越来越严重）,发生了危机，是属于Incident的管理流程还是需要建立一个新的流程（Crisis Management)？

其实这一场景的管理，在ITIL 4中，划分为三个实践:　监控和事态管理（Monitoring and Event Management ），事件管理（Incident Management）和服务连续性管理（Service Continuity Management)。在回答这个问题之前，我们先看看这三个实践的范围和流程。这里先要说明，由于翻译的问题，Incident Management从ITIL V3，一直翻译成事件管理，其实我认为翻译成故障管理更合适。为了避免歧义和不纠结翻译的问题，下文都用英语单词Event, Incident描述。

区分三个关键词语

事态 Event: 对服务或其他配置项（CI）的管理具有重要意义的任何状态更改

事件 Incidnet: 服务的意外中断或服务质量的降低

灾难 Disaster: 对组织造成重大损失或重大损失的突发性意外事件。要将事件归类为灾难，该事件必须符合组织预定义的某些业务影响标准

从ITIL 4给出的定义来看，他们之间的关系应该是：

Event是由监控系统反映出来的关于CI项的状态变化，产生的信息有可能是一个通知，有可能是潜在故障，需要我们关注，有可能是故障，也有可能是重大故障或者灾难。对于Event的管理，需要我们去定义Event的类型，告警的阈值，Event的优先级和Incident优先级的对应，以及何时触发Incident Management。

Incident就是我们理解的故障，生产系统的异常情况，有可能产生中断，也有可能未产生中断。

Disaster是灾难，比如数据中心全部中断服务，业务系统大面积瘫痪。企业需要提前制定危机工作小组，以及确定沟通计划，比如上报监管机构，开展企业危机公关处理程序等等。

对比三个实践的范围和流程

对比完目的和范围后就会发现，Monitoring and Event management关注的是监控范围，确定要维护的信息和产生信息的处理规则，阈值的确定和报告（目前监控管理面临的痛点是信息太多，应该如何提炼有价值的信息），Incident Management关注的是尽快恢复服务，而连续性管理关注的是如果识别风险，制定措施和计划，保证系统的连续服务，并定期演练连续性计划。

三个实践的接口和关联

在企业实践的运维过程中，很多事情都是连续的，但是我们很难用一个流程把所有的事情活动都确定下来。于是ITIL对于流程进行了适当的分割，对于流程的范围也做出了界定，虽然这一定程度上不太符合目前DevOps提倡的端到端，事实上这是目前企业IT运维的现状。

ITIL４有进步的一点是，每个practice都写明了和其他practice的接口，也强调了“ITIL实践只是价值流环境中使用的工具的集合；它们应该根据情况在必要时进行组合。” 这三个实践的接口部分是：

1. 需要定义从Event到Incident的关联场景。

2. 需要定义从Incident到Disaster的关联场景。

如果我们要做流程的切割，那么根据ITIL的最佳实践，建议：

1. Incident的早期发现、诊断、故障自愈：应属于Monitoring and Event Management。

2. 来自监控系统的Event，产生了业务中断，或者有潜在业务影响和风险，Event要按照Incident的处理流程，作为Incident来处理。

3. 制定服务连续性计划并将其与Incident Management管理活动分开管理时，应该有一个明确的触发服务连续性程序的标准。在评估故障的业务影响时，运维专家应确定重大故障是否可能导致灾难，并通知危机管理小组，以便他们能够做出决定。

最后总结

根据以上的解释，如果监控报告发生了异常，

1. 运维团队处理了，这算是Even还是Incident管理流程?

【答】：运维团队进行处理了，应该遵循Incident管理流程，去除异常，恢复服务。

2. 如果没有处理，异常越来越严重（当然处理的时候也有可能问题越来越严重）,发生了危机，是属于Incident的管理流程还是需要建立一个新的流程（Crisis Management)？

【答】：如果还没有升级成为灾难，需要上报危机工作小组的话，还是按照Incident管理流程。如果需要，Incident 管理流程中，可以建立Major Incident子流程（重大故障管理流程），进行区别对待处理，包括激活24*7团队，事后要生产重大故障报告，管理问题管理流程分析原因等等。

写在最后，ITIL的最佳实践和流程可以组合应用，尤其是在企业大规模运维业务中，流程的边界分割可以依据企业情况灵活使用。

希望本文可以就Event, Incident和Crisis（Disaster）给大家一点启发。

附：服务连续性：https://blog.51cto.com/yazi0127/2551977

监控和Event: https://blog.51cto.com/yazi0127/2550306