浅谈业务服务目录（包含SLA）与事件分类的区别

无论你是在做ITIL的落地项目，或者ISO20000的咨询项目，或者第三方外包服务我们都会用到服务目录（包含SLA）和事件分类这些基本概念，毕竟事件管理是目前国内比较能落地的流程，几乎一半以上的项目都要涉及到相关设计、咨询与落地，但是在我做项目的过程中、在与客户研讨过程时，往往会发现很多人经常将服务目录（包含SLA）和事件分类弄混淆，当然这里不乏一些乙方的咨询实施人员，那么针对这个问题今天我也正好说说自己对于这两者区别的一些理解和看法，望请大家拍砖~

先说说容易混淆的原因吧：

1 项目的约束性：很多咨询项目往往只主做事件流程，所以经常会忽略了体系管理的其他流程的概念。事件管理流程中会涉及服务级别协议管理流程中的部分内容，但是也会一定程度上会混淆概念，例如我们在做事件分类或故障分类时就会认为这就是提供给客户的服务，理所当然理解这就是服务目录。这种情况更多的出现在第三方服务提供商身上，很多时候即使甲乙双方都错误的理解或者片面的混淆了事件分类与服务目录的区别倒也没关系，不会对整体服务产生什么重大影响。

2 工具的误导：很多工具或者工具实施者在本身设计和理解上有误区，导致设计出的工具或者工具实施过程中将服务目录与事件分类混淆，从而也导致使用者（多数是甲方）的理解偏差。

3 工作经验误导：很多人做管理或咨询是从底层运维干起的，在思维意识上或多或少有一定的固化，往往认为以前给客户提供的报障服务就是服务目录（不包含SLA），而后再加上时限要求就是服务目录（包含SLA）了，这种理解表面上看上去挺合理但实质上却是不了解服务级别管理流程的体现。

说完原因回过头来说说我浅薄的理解吧：

服务目录：

服务目录一般分为业务服务目录和技术服务目录，二者分别从业务和技术的视角将我们所提供的服务和为提供服务所做的工作进行了分类罗列（多说一句，技术服务目录往往作为OLA和UC的参考依据，有时做项目时客户并不需要技术服务目录），并且会伴随着服务目录在成本能够满足的前提下与客户（业务部门）、内部组织之间和供应商共同协商并最终签署协议也就是是SLA、OLA、UC，与客户（业务部门）签署的SLA中往往针对业务服务目录进行了可用性指标（可用性、可靠性、可维护性）的描述（当然有时还有一些附加内容或条件）。

服务目录（业务服务目录）的目的在于量化服务，为客户（业务部门）清晰的提供了IT部门的服务菜单，并且为今后服务改进、服务变更提供了基础性的支撑，同时也是信息部门价值的对外具体体现。

事件分类（有时也叫报障和服务请求分类）：

事件分类目前经常分为报障和服务请求（监控单说），我们会将事件细化成三级或者四级，最后一级的分类其实很重要，我们在做最后一级分类时经常会犯难，到底是以现象分类还是以服务组件分类呢？在做选择前我们应该回过头来想一下事件管理的作用，除了理论上说的快速解决故障和服务请求外，事件管理也要为问题寻源、技术分析、容量管理等管理工作和流程提供有力的数据支撑，这样看来事件分类的最后一级定位到服务组件往往要比定位到现象要好（这里要说明一下定位到现象也不是不好，对于还没有上其他流程的单位或者对于事件响应要求较高的单位还是比较管用的，但是这样做要有前期历史积累），所以说正常来讲事件分类最终是定位到服务组件，而不是服务，也不是服务场景。

在事件分类做好后需要根据事件分类进行优先级排定（紧急度、影响度，有时还有VIP）并针对优先级制定响应、解决时限。紧急度需要参考服务目录（包含SLA），注意这里仅仅是参考，不是照搬，因为在实际服务中，为了达成服务目录中的SLA我们需要留出一部分富余，且实际还要考虑VIP、影响度等因素，所以说无论从分类（服务分类/事件分类）上讲，还是考核指标（SLA/响应时限）上讲，服务目录（包含SLA）与事件分类是有关连的但不是可以照搬的更不是等同的。