有效记录，以便于衡量和改进流程，并向其它流程汇报。突发事件流程如下图所示：
第9页
f2213问题管理
对于突发事件有两种处理方法，一种是对其做出服务快速响应，尽快恢复其正常运行，另一种是鉴别和解决问题根源。这两种方法之间存在微妙的区别，而且经常被互相混淆。对其做好区分具有重要意义。
如果问题被怀疑存在于IT架构内部，问题管理流程将会瞄准其潜在的根源。一个问题可能是被突发事件暴露出来的，但是显然，问题管理的目标是解决问题根源，预防其可能产生的干扰，而不是迅速恢复系统运行。
当问题被识别后被识别的问题通常称之为已知错误，通常需要进行一个业务决策，决定是否采取永久性措施改进系统架构，以预防再次发生新的突发事件。如果需要，提交一个变更请求来实现改进。
为了有效和高效地识别突发事件背后的问题根源及其发展趋势，问题管理流
第10页
f程需要准确全面的突发事件的记录。问题管理流程同样需要和可用性管理流程密切联络，以确定这些趋势并明确补救措施的重要性。
流程：
2214配置管理
配置管理致力于控制一个变化中的IT架构标准化和状态监控，鉴别配置项目清册，相互关联，审核与注册，收集和管理有关IT架构的文档，为所有其它流程提供IT架构的相关信息。
配置管理是所有其它服务管理流程不可分割的一部分。拥有当前架构中所有部件的最新的，准确的，全面的和详细的信息，并管理其变更，使这些信息有效而高效地支持其它流程运行。变更管理可以与配置管理集成。至少，建议在配置管理系统中控制变更的登录和实施，并自在配置管理系统的帮助下对变更影响做出评估。因此所有变更请求应该被输入配置管理数据库CMDB，并随着变更请求的进展随时更新记录，直至其实施。
配置管理系统识别一个变更项目和架构中其它部件的关系，将这些部件的所有人召集到影响评估流程中来。不管一个变更是否在架构中实施，相互关联的配置管理记录应该在CMDB中得到更新。最好在变更发生时，使用集成工具自动地更新记录。
CMDB应该开放给整个服务支持组，使所有人理解部件失效可能的原因，
第11页
f从而使突发事件和问题可以被更容易地解决。CMDB还应当被用来把突发事件及问题记录和其它记录联系起来，比如失效的配置项目Co
figuratio
ItemCI和用户之间的联系。如果缺少了配置管理流程的集成，发布管理将难以实现，并可能错误连连。
服务交付流程同样依赖于CMDB中的数据。例如：服务级别管理需要识别相互结合在一起的部件，并在此基础r