国际 IT 领域的权威研究机构加特纳(Gartner)认为，IT 服务管理是一套通过服务级别协议(SLA)来保证IT 服务质量的协同流程，它融合了系统管理、网络管理、系统开发管理等管理活动和变更管理、资产管理、问题管理等许多流程的理论和实践。
国际 IT 服务管理论坛itSMf 则认为IT 服务管理是一种以流程为导向、以客户为中心的方法，它通过整合IT 服务与组织业务，提高组织IT 服务提供和服务支持的能力及其水平。
本文的目的在于，结合笔者近年来在帮着客户规划，设计及实施 IT 服务管理项目的过程中的经验及教训，给读者提供必要的思路，为读者日后实施类似项目提供一定的帮助。
IT 服务管理，着眼于整个IT 系统对组织，企业及其内部和外部使用者提供的端到端的服务。注意！这里强调的是端到端的服务，而不应局限在某一平台，软件，或中间件。这是因为，我们IT 系统所提供的服务越来越复杂，种类越来越多，往往单一的服务器，软件无法完成所有的工作，需要若干台不同平台的服务器，来自不同厂家的软件，应用协同工作。在这种情况下，如果IT 管理者依然像以前那样类似于“盲人摸象”那样各自为政，其结果必然是当发生问题时，众说纷纭，争论不休；既不利于提高用户使用的满意度，也不利于企业内部对自身服务的有效了解和管理，更无从谈起如何改进。
IT 服务管理，简而言之，就是能够随时知道IT 系统中都在发生什么，这些发生的事情对企业对内、对外服务有何影响及其范围，对于那些故障或意外，能够及时发现，隔离并修复。
我们以下图为例，来阐述有关 IT 服务管理的内容及其目的。下图是国外某一家电制造企业的业务系统架构图，每个方块代表完成特定功能的业务组件，而连线则代表了不同业务组件间的依存关系。
可以看出，对于诸如银行，运营商，规模制造业等大型企业来讲，其 IT 系统经过多年演变，不断发展，功能相对齐备；但组件繁多，相互间依存关系也极其复杂。针对这样复杂IT 系统的服务管理，主要着眼于以下几方面：
事件的管理及根源分析：一个复杂的 IT 系统中，每天会发生众多的事件，如某个端口状态改变，某个服务器CPU 使用过高等。这些事件有些是偶发的，独立的，有些是其他事件引起的；有些是非常严重的，会对系统服务或性能造成伤害，而有些又是无关紧要的。如何在成千上万的事件中抓住主要矛盾，即造成服务水平和质量下降的根源，是事件管理的关键。
服务水平管理：越来越多的企业要求对 IT 部门提供的服务进行量化管理，即要求某一级别的服务，及其持续时间。如要求某项服务的响应时间必须小于2秒，并保证在一年中99%的时间都能保持这种情况。更进一步，以实际发生的数据作为IT 部门整体考核的一个关键指标；随着服务外包，IT 系统服务以商品的形式在市场上供需要的企业购买，并与类似的提供IT 服务的企业开展竞争。其产品的好坏，除功能强大与否外，也体现在服务水平方面。作为IT 系统的管理者，要对自己所提供服务的水平有清晰的了解和认识，才能做进一步的改进与提升。
针对以上要求，我们如何实现 IT 服务管理呢？一个“简单”的思路，也是笔者在项目中经常遇到的思路，即，针对IT 架构中的每个组件，每个连接进行度量，在所有IT 部件上安放监控探针，并通过网络将监控到的结果进行集中，即将关性能的信息，如某个CPU 使用率达到90%，某些交易的响应时间增长到5 秒等，和有关事件的信息，如某个网络端口异常关闭，某个硬盘出现故障等，进行关联，可以进行较复杂的数学计算与分析，从而得到IT 服务管理想要的结果-服务的状态，水平，问题根源等。真的如此简单吗？事实往往并不是 这样的。
用一个形象的比喻，西方有句谚语：Looking for a needle in a haystack，即从一个干草堆中找一根针，类似我们说的“大海捞针”。有人曾经提出一个充满理想主义色彩的想法，以达到能自动的从干草堆中找到一根针的目的，就是在每个草棍儿上安放一个指南针，由于金属针的存在，其周围的指南针会有所显示，将所有指南针的信息收集到一起，就可以立刻知道针在干草堆中的位置。这样做可行吗？
这是一个很形象的类比，与前一段欲在每个 IT 组件上安放监控探针的想法类似。其结果当然是不可行。首先，其代价非常昂贵，用户必须针对不同平台，不同厂商的不同组件，均实施有效的监控（对于大型企业来讲，其数量将是成百上千）；其次，其架构将及其复杂，不但需要有效的度量，还要将度量到的信息集中、关联、筛选；另外，任何企业的IT 系统都是在不断演化，发展中，对于每个IT 组件上的监控，如何与IT 系统的变化保持一致；最后，监控点越多，出现错误的可能性就越大，从而对整个的服务管理结果产生偏差，甚至完全无效。
在一个实际的IT 环境中，当某个部分发生问题（如硬件故障致使磁盘无法读取；或软件问题，如程序处理出错致使某缓冲区溢出等），经过与其上下游的功能衔接，会对整个IT 服务（或某一部分）造成一定的影响。要对这种情况进行服务管理，通常的做法是对关键的部件实施有效的度量（注意，不是所有部件，只是关键部件），从而大致了解IT 系统中正在发生的事情；根据系统的组成，应用的逻辑，构建系统服务模型，并存放到服务模型数据库中（通常为符合ITIL标准的配置管理数据库（Configuration Management Database-CMDB）），用以模拟出某一事件对系统服务的影响。可见，在度量方面，通常只针对关键的部件进部署，所以我们不可能知道IT 系统中发生的所有事情；在服务模型方面，也不做到能够100%的模拟实际的应用系统；那么，可以预见，基于此得到的服务管理的监测结果必然不会是100%的准确。这是每一个服务管理项目所必须正视的一个问题，即“无法在服务管理中做到100%的准确”，用户只能根据技术，投资，工期等多方面因素与现状，得到一个相对好的结果。从另一方面看，任何一个项目，都应考虑投入与产出的关系。对于 IT 服务管理项目，同样，我们不能忽视其投入与产出，以下三张图有效的解释了IT 服务管理项目相关的投入与产出：
图 A 显示的是企业IT 服务管理项目实施的完整性与项目成本间的关系，可以看出，实施的越充分，越完整，整个项目的成本就越高。并且，在实施的开始阶段，成本的增加并不显著，随着完整性的增加，成本的增加也越来越明显，按照曲线的发展趋势来看，到最后（即横坐标向右发展），即使无限的投入也几乎无法提高任何完整性。
图 B 显示的是IT 服务管理项目所能达到的准确性与整个项目最后完成的效果之间的关系。显而易见，其也并非是线性的。
第四，应该看到，在当前的企业组织结构，尤其是 IT 部门的组织中，依照技术特点或技术种类，IT 系统的管理被分成多个小组。这种分割基本上还完全是依技术而定，而没有依照IT 系统所服务的业务来分。这样的管理方式有其存在的必要性和必然性，当然从业务管理的角度也有其弊端。上面提到的建立整合的服务管理监控仪表盘，从某种程度上可以缓解个技术组织间的隔阂，使不同技术组织都对一个相关的业务服务有一个一致的了解；在另一方面，通过必要的技术手段，建立并强化流程式的管理，针对于某项业务服务管理，通过流程，串联起各个小组中的相关人员，形成临时的虚拟团队，也有利于开展以业务为导向的管理工作。
