IT服务管理的指挥与智慧

IT服务管理的指挥与智慧

在当今动荡不宁、不断变化的 IT 环境中，IT服务管理（ITSM）的重要性不言而喻，它通过保证关键业务系统和服务的可用性和可靠性，为整个企业提供至关重要的支持。随着技术变得越来越复杂，解决问题也越来越耗时，对技能的要求不断提高，维持优质服务的成本不断上升。面对紧张的预算和有限的资源，优先级处理、响应能力和标准明确的工作流程对于最大限度地提高业务关键 IT 服务的可用性至关重要。

有时候我们常常在问：“为什么在标准化管理中，IT服务和产品中‘个性化’的词汇会更加吸引人？而又为了什么在企业的IT服务管理中要把各种烦恼的事情都要提前解决，不再四处奔波？是要显得我们的工作更加有价值，还是我们的肢体已经懒惰了，更依靠人脑和电脑的智慧？”但愿我的这篇闲扯的blog是一丝清风，为君解忧。

创业难守业更难

从历史到今天，从IT到建筑，从餐饮到航空，从回顾历史到探索未来，每一个领域都离不开“管理”。在遥远的异域传说中，人类的始祖亚当，最初就是伊甸园的管理者，也是人类的第一个管理者。他曾经那样天真无邪，但自从他和他的女人一起吃了是非果之后，情况就开始变得不妙。有是非就有分歧，有分歧就有辩论，有辩论就有战争，有战争就有欲望，有欲望就有痛苦。

我们在应对一个企业网络架构建设阶段，更多的是一个“临摹者”而非创造者，也就是说很多的技术方案可以支持你创建一个网络从筹备到完工验收。而当我们把网络交付给用户之后，两种人的分歧就从来没有消停过。以下用户因为网络缓慢而大发牢骚？

这些矛盾你可能都遇到过：

 业务部门因为服务器出现故障而指责IT部门不负责任？
 新版本的报表软件更新，遭到90%以上的员工投诉设计繁琐？
 永远无法先行一步预防故障的发生，被别人和自己封为“救火员”？
 为什么IT服务部门的预算总是相对较高，遭到公司高层的白眼？
 业务系统平稳无碍，又遭人妒忌，沦落为企业最清闲的部门？
 是否被其它部门利用，IT部门做了许多不必要的工作？
 ……

一切的分歧和矛盾是我们造成的吗？为什么在信息化平台已经运转起来之后，这些问题都将逐个得冒了出来呢？我只能说：“因为管理不到位！”IT管理的课题与领域相当之大，，在之前，由于我们也没有可以参考的资料指导，所以只能摸着石头过河。我曾经向一些同行调查他们的工作情况，我想只有我们这些人说出“真心话”才反映出了企业IT管理中的诸多难题。真心话的共同点就是：网络建设中的技术已经无法满足我们针对服务进行管理的要求。
企业网络在对多种主机平台、多种设备的管理维护时需要我们掌握所有平台的维护法则，但我们不可能做到这一点。所以，企业必然要投入拥有其他几项技术知识的管理维护人员，即使这样，我们也无法同时对分散的主机、网络设备、数据库、业务系统性能进行统一的监控管理。业务结构不断变化的本性造成系统的复杂性不断增加，你不再能控制一个内部软件系统，就像你不能控制气候的变化一样。另外，尽管我带领的IT部门已经是一个很艰难的部门了，但是IT技术的发展，如云计算、虚拟化等还将使管理变得更复杂。虽然我们自己也意识到在整个公司发展的过程中，特别是公司越来越习惯于IT服务的时候，客户对于IT服务的期望值就会越来越高，IT部门所提供的服务也必须逐渐地有所提高。但对于有些IT部门来讲，如果说对于需求的反映不及时，或者说服务质量不能够快速提高，或者成本不能够降低下来，就会成为“破鼓万人捶”的对象。
当然，已经有一些人已经筹措了整套的想法，但管理手段（一个电话或一封邮件）和工具落后，导致很多问题反复出现：管理人员无法预测将要发生的故障，有时不能及时发现故障，运营维护人员整天忙于“救火”，“救火后”仍然没有增加任何“消防知识”，同样的故障反复出现，都将促使“离职”事件的发生。
长期来看，作为CIO，我也面临着一个迫在眉睫的选择。当前，外包的趋势虽然在持续发展，但从以下两方面来看，IT部门依然有生存空间：一是肯定还会有一些系统会由企业内部的IT部门来运作；其二，我担心由于那些没有很好采用外包的系统，将会遭受到系统失败的结果，也将不得不改由自己的IT部门来做。作为技术人员，近10年来我们可能尝试了近百个网管软件。但作为管理者来说，将网络监控技术运用的如火纯青，仍然改变不了IT部门地位低下的现状。当然，这不说“原生类”的IT技术不重要，由于采用的网络管理及与设备管理不能积累相关的客户信息，不能指导业务提高效率，也就无法让用户满意。缺乏主动性能分析，运营管理人员缺乏对网络、主机系统全面的性能统计分析，即使今天用户说“可以了”，明天我们还可能犯同样的错误。因此，如果我们永远停留在“网络设备管理”这个层面的，正是这种虚假的“成功”会阻止我们做出变革。

由智慧的产品所联想到的IT管理

目前，IBM提出了整合服务管理（Integrated Service Management，以下简称ISM），那么ISM提出的是在一个什么情景中诞生的呢？我们以中小企业为例，是“服务台”一体化解决方案为核心的，通过此方案内置的问题解决工具，中间市场客户可提高操作人员的生产效率，进而降低企业成本。服务台工作人员可凭借该功能提高其服务支持功能的效率。此外，强大的自助式门户，涵盖针对常见问题开箱即用的最佳实践解答，最终用户利用此门户可快速自行解决问题，而不必求助他人。这个方案中的一个概念非常重要，就是“服务台”。
而在ISM整个方案中，又包括了Tivoli Foundations Application Manager ，它是 “应用程序管理”一体化解决方案。在这个一体化的交付软件包中，包含了IT环境中所有实施应用程序管理所必须的重要支撑，包括： IT 资产发现、网络监控、服务器监控以及关键 IT 元素（数据库、邮件服务器和虚拟服务器等）的监控。其中包括实时和历史信息查看功能，可让IT部门了解其 IT 环境当前和过去的运营情况并制作相关的智能报告，凭借该功能了解全部网络、服务器、中间件和应用程序组件的服务性能和运行状况，并改善服务质量。根据我的理解，这应该是指得是IT运维中必不可少的“工具”。
当您驶离行车道时，您的手机和您的车载语音指挥系统自动同步，车辆会向家里的报警系统发送信号以启动报警系统。对您的行驶模式进行分析后，车载全球定位系统（GPS）会建议您改道，以便节省燃油成本并且避免交通堵塞。最后，车辆会通知您的防抱死制动系统需要检修，并且会在您的个人数字助理（PDA）上检查您的日程安排，然后为您安排检修时间……在IBM这位IT巨人提出“智慧的地球”之后，“智慧的产品”更为我们阐述了一个理念或者一种可以应对未来变化思路有多重要，人类的历史也许因为一个概念而彻底改变。
因此，要深入了解IT服务管理（IT Service Management，简称ITSM）对于我们现在能做什么，就需要深入了解这个概念是否已经变成事实，也就是它是否已经能够帮我们解决问题。
ITSM这个词，最早从20世纪60年代即被开始使用，但是直到80年代英国政府有关部门组织开发ITIL，且ITIL被广泛使用之后，IT服务管理才得以成为一个特定的词汇。纵观最近30年，ITSM和ITIL两个词可以说是“相互提携、相伴成长”。正如其他所谓国际先进概念在中国的遭遇一样，ITSM也经历了非常曲折经历才被国内同行所认知。十年之前，ITIL在中国当时仅是偶见诸报端，基本上也是无人理会，很多人包括我，也觉得这只是一个模糊概念上的炒作，并不会提高我的IT技能，也不会对我的职业发展有什么大的帮助。时过境迁，经过国内数年的应用，大家逐渐认识到，ITSM确实一种“以流程为中心、以客户为导向”的通用方法，也是一种改变企业信息化命运的良药。
可能你现在就想细细品味ITIL的果实，不过还是让我们要从一位电器集团的CIO的经历开始吧（内容涉及个人隐私，为化名）。这家电器集团如今拥有450个销售网点和分支机构，向大约26个省市和14个国家提供产品销售和服务支持。

陈磊（男，现年34岁）从这个集团的网络建设开始，他以早期CCIE证书拥有者的背景进入这家集团，并获得了信息网络部经理的职位。随着公司业务的不断发展和壮大，业务部门对IT技术和自动化系统的依赖越来越大，他们需要IT来支持处理大量交易数据和库存配货。然而，由于公司缺少一支有组织且结构化的一线IT支持服务团队，各个省市的店面雇员在面对时而发生的IT故障和问题时变得越来越沮丧：他们不知道向谁寻求帮助，在四处求救时浪费了大量的宝贵时间；另外，对于那些重复发生的问题和服务故障，没有一个现成的经验和知识帮他们直接解决问题，使得陈磊的手下陷入一遍遍解决同类问题的僵局。当他们处理分店即时的销售和库存调用业务时，每笔业务销售额的准确性和调货的即时性对他们来说至关重要。业务部门迫切需要一种最快，最准确的方法来协助完成所有交易。然而，他们却搞不清一旦发生客户端、网络和服务器故障时，他们应该打电话找谁来寻求帮助。甚至即使打了电话，问题也不能得到很好解决，影响业务的进行。但此时的陈磊已经疲惫不堪，队伍也很消沉，因为时常发生的故障问题导致所有人几乎1年来就没有节假日，这直接导致了这些业务部门的领导和IT团队本身对陈磊开始出现信任危机：IT服务与我们业务部门不是同路人，他并不是一个值得信任的，拥有共同业务目标的好的合作伙伴。IT技术支持团队错误的认为陈磊只不过是一个技术上的狂人，而对于“管理”还是乳臭未干的毛头小子。
另寻出路的陈磊开始找“下家”，而也许就是上天的安排，他在HR网站上搜索职位的时候发现了“IT服务台经理（Help Desk）”这个职位。通过对这个职位需求的了解，以及各个媒体的报道，陈磊终于再次从技术的角度重新树立了自己在管理上的改变。

提示：当时的IT服务台经理职能与现在的工作区别很大，为何这样说呢？
当时，帮助台与服务台两个术语在实际应用中通常可以交替使用的，IT人对于它的理解也基本相同，但两者在概念和面向对象上并不完全一样。
（1）帮助台的主要任务是记录、解决和监控IT 服务运作过程中产生的问题，主要和事故管理相关联。面向的用户主要是IT 部门内部人员。
（2）服务台的概念则具有更广泛的内涵，它通过提供一个集中和专职的服务联络点促进了组织业务流程与服务管理基础架构的集成。服务台适用于作为一个广泛的，集中受理的前台支持角色，而不仅仅是帮助台。服务台不仅负责处理事故、问题和客户的询问，同时还为其它活动和流程提供接口。这些活动和流程包括客户变更请求、维护合同、服务级别管理、配置管理、可用性管理和持续性管理等。面向的用户主要是IT 系统的实际使用者。

服务台，在IT服务支持中扮演着一个极其重要的角色。完整意义上的服务台可以理解为系统应用部门和服务流程的“前台”，它可以在不需要联系特定技术人员的情况下处理大量的客户请求。对陈磊所要建立的服务台就如他的CCIE证书一样，都是“交换机”和“路由器”的重新解释。在碰到任何问题或疑问时，只需通知和联系服务台的工作人员，再由服务台的工作人员指导和协调下一步的处理工作。陈磊对于管理和服务概念上的改编是巨大的，那个这个看似路由器或者交换机的东西，为他解决了什么问题呢？

 由于只有一个联系点，发生服务故障时，所有网点的业务人员可以直接与IT技术服务人员联系，避免了不知找谁来解决问题的情况发生，从而缩短了“遗失时间”。
 服务台人员对所有IT用户提交的服务请求，故障和问题等进行记录，这些记录提供了一种发现IT基础设施问题的机制。
 为IT管理提供一种可量化的评价机制来评估业务，同时业务人员也可以了解IT部门现在的工作状态，双向沟通都在服务台上进行。IT服务台将彻底促进IT与业务的沟通，改善业务对IT的认识。
 通过配置管理中的配置管理数据库，处于单一联系点的IT服务人员可以掌握所有配置项信息，使其可以更有效果且更有效率的使用各种配置项资源。
 当面对同时发生的大量突发事件时，服务台提供了一种结构化的流程来安排工作优先级，影响度大且紧急的问题优先解决；同时，服务台选择最快的方式来恢复发生故障的IT服务。由于所有解决问题的方法都将被记录在问题管理数据库中，IT人员只要搜索一下该数据库，就可获得解决已发生过问题的解决方案，缩短了平均不可用时间。
 对于更简单的客户端技术问题，普通用户可以通过服务台的搜索功能得到技术解答和修复。

针对最后一点，可能陈磊都没有想到自己竟然成了“先知”，这与IBM 提出Tivoli Foundations Service Manager一体化解决方案非常接近：强大的自助式门户，涵盖针对常见问题开箱即用的最佳实践解答，最终用户利用此门户可快速自行解决问题，而不必求助他人。围绕服务台改变IT现状的结果是喜人的，陈磊实现了所有既定目标。通过使用新建成的基于ITIL的服务台，客户可以方便的记录所有发生的突发事件，并对事件进行分类和报告，支持并解决这些突发事件和问题。这样最终用户可以将注意力集中在如何实现其业务目标，增加主营业务收入，已经产品服务和技术更新反馈上等等，而不是被突如其来的IT服务故障所累，而其IT服务部门也不必再被误解，不断的陷入客户的抱怨和指责声中。IT真正变成了一个强有力且有效的内部工作工具，支持业务需求，是每一个业务部门好的合作伙伴。

回顾陈磊在职业道路上的坎坷，这让我们明白了一个IT人从技术人员如何跻身管理人员的道理。因为对IT部门而言，一方面需要对涉及IT的事项进行管理，另一方面也需要为其他部门提供IT服务。IT部门做这两类事情的方法，分别叫做“IT管理方法”和“IT服务方法”。将这两种方法用一个词来概括，就叫做“IT服务管理”，即IT Service Management = IT Service + IT Management。
基于上述分析，我们很容易理解，首先这个ITSM本身没有任何新意，其次我们没有任何必要讨论要不要IT服务管理，因此只要存在IT部门，就存在IT服务管理。只不过以前是隐性的，现在被显性了而已。

成功推销ITSM是关键

ITIL作为IT管理实践的最佳指南，它的光环几乎吸引所有大型企业的IT管理团队，高管们都希望能够通过它改善和提高IT服务的水平。然而，不是人人都会获得成功，当企业借助ITIL标准化实施ITSM的时，面临的挑战真可谓“丰富之至”！

企业实施ITSM项目时，制订正确步骤就要比烹制“河豚”，正确的烹制流程会使ITSM变得相当美味，而错误的“刀工”很有可能造成“服毒身亡”。
第一步，并不是要设计什么模型，也不需要按照英国发明人建议的那样先取得ISO 20000认证，因为你可能在一个儒家管理盛行的中国式管理的年代，所以你要在身边培养起来更多的“知音”才是关键。在一家专门针对 CIO 或者 CTO的网站上，我帮助一家咨询公司做个两份调查，这是针对参加过ITSM的培训的管理层而言的调查表。我发现他们有一个非常相似的矛盾心理状态，这就是 ITSM如果实施起来的内容太多、困难太大，付出的人员成本也会增加，与现在的流程很难匹配。为了在自己的组织和部门推销ITSM ，受过培训的领导们会组织参与运维的工作人员培训，让他们知道什么是ITSM？ITSM包含什么内容？怎样做好运维？怎样在已有的基础上如何提高水平？但定制培训内容和ITSM的推销过程却是困难的，运维工程师很难掌握 ITIL 的精髓并利用到实践中去。因此，我们相信发布一份贴近与IT维护人员报告会起到ITSM宣传的作用，推广ITSM就是让更多的IT和非IT人员熟悉流程以及这种方法的优势，这绝非是推广一些ITSM产品所替代的。另外，由于我工作的关系，我也负责一些ITIL的课程，所以我建议在“推销”ITIL的时候，遇到的一个挑战就是要说服那些过去认为ITIL只是一个时髦概念的人。逐渐地，你身边越来越多的人将认识到ITIL的好处，但这的确是需要时间的考验。

ITSM的四大关键因素

首先，我们将IT服务中的各个对象关联起来，如下图所示：

ITSM中四大重要的因素就是人员、流程、技术、信息（其中技术也特指为：工具），而这四个因素和IT服务项目成功与否息息相关，如何对这四个关键因素进行最好的管理呢？

人脑和电脑的难题

实施了ITSM后，理清了流程，经验文档化，流程程序化，服务可度量，工作可监督。不再是“人”说了算，不再完全依赖某人的经验，而是制度流程说了算，如果某人再要说了算，那也要等改了文档后。因此，所有的管理都有据可依，那么会不会有人再发出“以前是怎么管”的感慨呢？人的价值在ITSM中是否减弱了呢？
回答是否定的。ITIL的应用过程中，人员相关的因素应该是首要考虑的因素。因为ITIL的应用实际上是一个管理变革活动，特别依靠人的积极参与来完成。在变革过程中，由于可能涉及到人员的职能、利益、思维模式、工作方式等的转换，产生的误解、消极和阻力不容忽视。我们需要在对ITSM有清楚认识前提下，逐步建立ITSM流程化管理标准体系的过程中，充分让ITSM更好的为人服务，而不是让人来为ITSM服务。ITSM项目一旦完成，一切都将变得“死板”（很多人至今无法相信 ITSM项目成功就取决于这种“死板”的机制），需要所有人员做出配合流程变化的承诺，这也是人脑为什么先要统一原因。即使员工做出了承诺，但人脑在实施ITSM之后必然会出现不统一的状况，这一结果必然是ITSM(电脑)系统中定义的流程偏离了人脑的预期。”

“杀鸡用牛刀”的流程会遭遇顽强抵抗

ITSM是一种以流程为导向，以客户为中心的方法，流程管理上基本包括流程层级、流程规则、角色权限级别等。举例来说，某集团的产品销售部的一台终端出现无法上网的问题，调查后发现因为主机原来进行过网卡更换处理，而原有在交换机上有配置了MAC地址绑定的功能。如果使用原来的ITSM系统流程，首先销售人员会登录ITSM系统的服务台告知故障现象，然后走故障管理流程。随着这个故障上升成为了一个事件，触发了事件管理流程，然后问题就出现了：原有的ITSM系统中无法定义紧急变更流程的输入、输出功能，因此这个事件也就停在了这里。
ITSM流程带来了规范的操作、可控制的运营过程，也带来了官僚和僵化的危险，流程的繁琐会成为人们抵制ITSM的另一个理由。但很多企业在实施前的准备不足却使得流程更加拖沓，因此量化管理流程前，应以最大限度地消除由于ITSM失配所导致的运营风险为前提。势必要将更换鼠标和键盘等事件的流程数量缩减至较少，避免“小马拉大车、杀鸡用牛刀”的管理模式出现。

信息混乱会导致错误指挥

本文记叙到这里，我们还有一个非常重要的概念没有提，这就是：CMDB（配置管理数据库）。为了达到动态IT运维服务所追求的目标，我们必须将ITIL指导真正落实为明显的、可衡量的，变成可以整合的实体，而这承载这些实体的容器就是CMDB。
CMDB信息模型有两种不同的方式。一种是自上而下，即先有一个宏观的企业视图，在CMDB中为该视图部署一个元数据模型，然后确保所有管理应用程序符合元数据模型。另一种方式是自下而上，即把低层的数据集进行标准化，依此开发模型。由自下而上产生的CMDB模型与具体的管理功能和应用无关，因而比实际上的低层次数据集更易操控，它更易被接受，因为它无需破坏企业的组织架构和文化。
作为ITIL实施成功的关键与保障，CMDB相当于整个“网络列车”前行的动力源泉。由于它可以代替了以往手工存储和管理企业IT架构中设备的各种配置信息，因此更多地企业开始考虑采用自动获取的方式存储IT基础设备的各种配置项信息，然后将其与ITIL的所有流程都紧密相连，提供有效数据支持ITIL其他流程的运转， CMDB配置库可以是比喻成企业网络中的“眼睛和大脑”。
这个特殊的动态数据库作为ITIL标准流程里一个核心的组成部分，记录了ITIL流程运转的过程，从开始启动、发现事件、问题处理、变更管理、版本发布，到最后的关闭，中间的所有的过程都会被自动的记录到CMDB中。试想如果CMDB对故障设备的关键性指标提供了错误描述，事件能够得到及时解决吗？如果没有配置管理的同类故障统计分析支持，如何实现主动的问题管理？如果没有配置管理提供CI（配置项）之间的关系作为依据，如何针对将要进行变更的CI以作风险评估？

巧妇也需要有米下锅

很多人都知道，工具在ITSM中的地位要排在流程和人的后面，但是这并不说明工具就不够重要，如果在上百台服务器和几十个业务系统面前，你依然让我用手工的方式去运维，必然导致我 “发飙”。如今，各家厂商ITSM的工具所包含的广度越来越大，但在同时，单个工具的亮度也越来越被弱化。具体来讲，IT服务管理工具厂商包括BMC、IBM、HP和CA、神州泰岳、广通、游龙、北塔、摩卡、泰信等等。
但有了工具就不会失败吗？在执行ITSM策略时面临的最大挑战就是流程必须根据每个企业客户的实际需求而进行调整，但很多ITSM项目要么停顿不前，或是完全失败。就如我们理解的一样，ITSM只是一套方法论，其最终的实施还是要依靠相应的工具和经验。有些时候，ITSM工具之所以无法量化，因为这个工具本身就不能适合企业的需求，死板的ITSM工具，必然结果就是项目失败。以上这些厂商的产品各有千秋，我们也仁者见仁，智者见智吧。不过如果我依然站在IT管理者的身份上来讲，比较关注下面两点：
可视化功能：这可以让我们了解信息环境中利用率不足的资源以及有过剩的容量、可用于支持新业务运营的资源，以优化资源分配，从而降低成本。同时，通过预测资源过度利用，以及针对可能无法根据业务需求继续扩展和增长的资源生成前瞻性事件和报告，以降低风险。
自动化功能：可以帮助我们精简事件和问题管理流程，改善整体服务质量和快速恢复服务。通过前一个功能（实时可视性），第一时间了解问题、事件和服务请求的优先级、紧急程度和影响，并利用这些知识和功能查看其需求是何时、何地和如何解决的。

向着IT服务管理的目标前行

随着云计算、虚拟化、SOA等新技术的不断涌现，目前IT的运行环境正在发生剧烈变化。越来越多的应用、更复杂的数据、异构的系统平台、跨系统和跨组织的业务流程优化等，这都使得ITSM的规划要比几年之前艰难了很多。
ITSM作为“管理学”中的新兴学科，其实施的重点是IT的运营和管理，而不是IT的技术本身。我们拿一个生活中的例子来说，如果把组织的业务过程比作安排一辆汽车去完成一趟运输任务，那么ITSM规划的任务相当于为这次旅行选定正确的路线、合适的汽车和司机。而ITSM的任务则是确保汽车行驶过程中司机遵循操作规程和交通规则，对汽车进行必要的维修和保养，尽量避免其出现故障；一旦出现故障也能很快修复；并且当汽车到达目的地时，整个行驶过程中的所有费用都可以准确地计算出来，这便是成本管理。而这些细节组成起来，就是 “智能”的交通,如果我们把这个例子套用到IT运维上,这就是“智能”的IT服务管理。

在获取更多层面的支持者之后，你便可以开始制订ITSM实施路线图，当然之前你最好完成的参加一次ITIL或者ISO 20000的培训，以便有章可循。总之，我们都希望通过可视化，可控化和自动化，实现企业IT设施，人员与流程的互通互联，进而达到业务与IT系统的全面融合，在这个目标上不要偏离轨道。