ITSM，即Information Technical Service Management，也叫IT服务管理。

 Matt向我解释它的时候，打了一个很简单的比方：“公司的电脑或是打印机坏了，就向IT服务部门申报，该部门再安排人员去解决。”这是一个很常见的场景，我觉得了解这个项目的业务应该不难。但当我试着了解了ITIL，我立即意识到自己的愚蠢。

 ITIL（IT Infrastructure Library），是一套方法论，帮助说明了如何管理IT基础设施的流程。话说ITIL产生的根源是英国国家电信局的IT服务水平不高，就找了一帮顾问和专家来寻找解决方案，最后ITIL就诞生了。

 闲话少说，我还是借用上面的例子，对于ITIL指导ITSM来说说自己的看法。

 一间稍具规模的公司，每层楼有四台打印机。（对这些IT设备的基本信息进行管理，就是配置管理Configuration Management的范畴）

 员工甲发现一楼的打印机（编号为A）不能正常使用，于是（打电话/Email/Self-Service）联系IT服务部门报修。一线部门的人员一般只能解决常见的简单问题，对于无法解决的问题需要联系二线人员。同时，需要通过Email或是其他方式告知一楼的员工：“打印机A有故障”；还可能要联系采购部门，新添加一台打印机，以免影响日常工作。（这属于一个事故的处理流程，称作事故管理Incident Management）

 在新添加一台打印机的同时，又涉及到另一条流程，对这样新增一项设备的需求进行审批。（这正是需求管理，Require Management）

 ok，在解决了打印机A故障的不久之后，打印机B、C、D陆续都发生了故障，于是这个小故障就不单单是个故障了，它已经是一个大问题了。因此，前文中提到的Incident Management事故管理，显然到了Problem Management的级别。这个时候，可能就需要所谓的专家团队去研究这个问题的根源。在找到这个Problem的症结之后，也需要进行整理总结，建立“知识库”，进行知识管理。这样，以后出现类似的问题，就能有效地解决了……

 这个例子讲述了一些涉及到ITSM的活动。就拿事故管理Incident Management来说，ITIL提出“影响度”“紧急度”“优先级”这些概念定义incident，并提出SLA、OLA作为考量IT服务的指标。但真正困扰我们的东西，比如配置管理中如何把握配置项的粒度（仅把一台设备作为配置项显然是没有意义的~）、如何构建配置项间的关系，ITIL都没有提及。

 所以说，ITIL只是把各个部门间的协作和流程间传递和处理input、output信息的活动，定义成一些XX管理的概念而已。但如果真正要做ITSM的项目，ITIL却不可不知。毕竟，站在巨人的肩膀上，视野会更远、思维广度会更宽。当然，站得太高就得谨慎些，摔下来会很痛。