在IT运维日常工作中，不管企业引入了国际标准规范与否，均无可避免的产生事件管理行为，认可ITIL管理规范的IT管理者，同时也认识到IT运维的管理流程并是非孤立存在的，因此事件处理过程不可避免的与其它流程产生关系。在ITIL管理模型的学习中，我们可以通过理清事件管理过程与ITIL其它管理流程的关系，达到对ITIL管理框架形成立体化的认识。
事件管理的基本环节可分为：事件检测和记录事件分类和任务派单事件解决和恢复事件关闭四个环节。
先来看看“事件检测和记录”环节，事件在记录和确认的过程中，可能需要查询涉及到的系统或应用的信息，然后记录相关的有价值的信息，或确认信息的正确性，将事件的范围确定下来。这个过程，事实上就涉及到配置管理，有效的配置管理，将会对事件管理产生有价值的输出。
事件记录和定位后，进入“事件分类和派单“环节。将事件分类定性，目的是为了对该事件进行一个等级评价，最终映射到处理该问题的优先级，然后根据该优先级在其他事件中的位置，采取合理有序的响应行动，即对工单的处理。于是，该环节事实上触发了服务级别管理过程。
通过服务级别管理，对既定的事件级别，做出相应的有时间规限的响应动作，或者事件升级动作，以此达到资源合理分配，应对有序的事件处理效果。
事件得到处理，便进入“事件解决和恢复“环节，在解决问题的过程中，可能会对目标系统进行改变，如此，便触发了变更管理，变更管理的过程中，也会触发配置管理过程，在配置管理，变更管理过程完成后，事件得到解决，故障得到恢复，在下一个事件出现前，又处于一个相对稳定状态，事件回到了事件管理的主线中来。如果一个事件反复出现，或者经历某时间段不能解决，将会视为问题，于是触发了问题管理，问题管理将会输出产生该问题的根因和可重用解决方案，最终使该类事件得以解决，系统状态恢复。
事件解决后，需要一个确认环节，确认环节完成后，事件关闭。然而，这个关闭，事实上是有时效性的，在实践过程中，我们会有一个状态，称为“重开“，即原来关闭了的事件处理流程，需要重新开启，再处理。出现这种情况的原因通常发生在事件恢复确认环节，可能确认的条件不充分，确认的方法不正确导致事件被认为可以关闭，事实仍然有遗留问题存在。重开的状态，也可能触发启动问题管理过程，定位问题根因，寻找解决方案，最终解决问题，保存于知识库，这个过程事实上又触发了知识管理过程，在此不再赘述。
以上，我们以事件管理为主线，粗略的分析梳理了基于ITIL框架的IT运维管理过程，运用该思路，我们可以清晰的将标准化的控制流程贯穿于事件管理当中，为我们在IT运维管理工作中考察各环节的执行效果，问题定位提供帮助。
