安全之外:谈构建端到端的IT服务管理

可以看出，对于诸如银行，运营商，规模制造业等大型企业来讲，其 IT 系统经过多年演变，不断发展，功能相对齐备；但组件繁多，相互间依存关系也极其复杂。针对这样复杂IT 系统的服务管理，主要着眼于以下几方面：

服务的可用性：如何保证系统在需要的时间段内能够提供正常的服务。随着IT 的不断发展，竞争不断加剧，市场对企业的要求也不断增加。如在上世纪九十年代，银行的IT 系统只需对外营业到下午6 点，而现在，随着信用卡，网上银行等需求的出现，绝大多数银行都已提供每周7 天，每天24 小时的所谓7×24 的不间断服务。IT 系统复杂如“蜘蛛网”，其中任何一个点上出现的问题，是否会影响到部分或全部的对外服务？影响有多大？如何修复？从而不影响或尽量少的影响到系统对最终用户的功能。

服务的性能：设想您走到某一台自动取款机前，插入银行卡，希望取出500块钱，您的每一个操作，都要等待十几秒或数十秒，您是否会对此家银行的服务满意呢？如果时常如此，您是否会考虑改用另一家银行的服务？当您插入银行卡或在POS 终端上划卡时，从您面前的终端，经过一系列服务器，网络等IT 组件及设备，交易是一个极其复杂的过程，代表交易的电子信号可能要在IT 系统中“旅行”上千公里，在许多节点停留并被处理，而通常要求这个过程必须在几秒甚至零点几秒内完成。如何能够保证？当途中的某个环节出现问题时，如何能够及早的发现并改善，这都是有关服务性能的话题。

事件的管理及根源分析：一个复杂的 IT 系统中，每天会发生众多的事件，如某个端口状态改变，某个服务器CPU 使用过高等。这些事件有些是偶发的，独立的，有些是其他事件引起的；有些是非常严重的，会对系统服务或性能造成伤害，而有些又是无关紧要的。如何在成千上万的事件中抓住主要矛盾，即造成服务水平和质量下降的根源，是事件管理的关键。

服务水平管理：越来越多的企业要求对 IT 部门提供的服务进行量化管理，即要求某一级别的服务，及其持续时间。如要求某项服务的响应时间必须小于2秒，并保证在一年中99%的时间都能保持这种情况。更进一步，以实际发生的数据作为IT 部门整体考核的一个关键指标；随着服务外包，IT 系统服务以商品的形式在市场上供需要的企业购买，并与类似的提供IT 服务的企业开展竞争。

其产品的好坏，除功能强大与否外，也体现在服务水平方面。作为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 服务管理项目，在什么情况下容易得到较高的投资回报，而什么情况下就应及时收手。如图C 所示：

图中A 点处，投资较少，而项目能达到的效果较大，故此处为投资回报最高的地方，即最大的投入产出比；而图中的B 点往右，整个项目的投资会急剧增加，而能达到的效果增长却完全不明显，也就是我们常说的“费力不讨好”。从项目管理的角度，从投入产出的经济性来讲，都是应尽量避免的。

另一个经常遇到的问题，或用户经常提出的要求就是针对那些出现概率极低的问题及其对业务服务的影响是否进行管理与监控，或者说，在实施企业业务服务管理项目时，我们是否应该包含那些曾经出现过的小概率事件？对于这个问题，不能以简单的是或不是来回答。一个IT 系统经年累月的运行，一定会出现这样那样的故障，其中有的故障可能只出现过一次，或者有的故障只在其他类似企业出现过，对于这样的事件，更多的是应该从系统架构的设计方面予以有效的避免，而不是过多的着眼于在IT 服务管理项目中将其及时发现并进行影响性分析。这同样是一个有关投入与产出比的问题，与其花费大量的人力物力和时间应对一个几乎不会再发生的问题，不如基于现有的条件完善那些针对日常经常出现问题的处理。

总之，对于 IT 服务管理，应该以项目的眼光和角度出发，均衡企业现有的人，财，物，开展有针对性的工作。基于已有的系统，软硬件条件，进行必要的补足后，搭建起企业的IT 服务管理平台。在这一过程中，切记不要过分强调细节，也不要好高骛远，尽量从简单的业务系统开始，以简单的业务模型为起点，逐步完整，层层深入，循序渐进。并且，实施IT 服务管理绝不是一个一次性的工程，而是要随着企业业务发展而不断做出必要的调整，改进，完善。可以说，企业实施IT 服务管理，重要的是过程，过程对了，自然会有结果。

以下是笔者从实际的服务管理项目中总结出的几条经验教训，供读者参考。可能部分内容对于您的企业实际情况并不合适，这也是非常正常的，毕竟，实施企业IT 服务管理的最根本的是要从企业系统的实际出发，因企业而异，因系统而异。

首先，在实施服务管理项目前，从领导决策层到技术实施团队都应该达成一个共识，即IT 务管理是粗略的管理，不可能做到100%的精准与100%的控制。在这一点上，笔者的一个同事曾做过一个非常贴切的比喻，即IT 服务管理就好象是我们定期进行的体检，我们只能通过一些体征指标，大体上了解身体的状态；大多数人没有时间，没有能力，更负担不起去把身体的每个部件，从里到外，用各种能用的设备来都做一个全面的检查。同样，一个IT 服务管理项目，也是从一些关键的点入手，从三个层面来进行。从离基础架构最近的资源层：根据系统特点，选择关键的测试点，以实时或准实时的方式构建出基础架构的“关键运行指标”（即我们常说的KPI-Key Performance Index/Indicator）；在与管理者最近的业务服务管理层：要构建业务运行的KPI，使领导者，业务经理等管理层能够了解当前系统业务服务的状态；在以上两层之间，还需要有一个能够提供深度问题分析，问题关联，业务拓扑管理的一层。

在基础架构管理中，就像前面提到过的，要对资源的运行进行必要的度量，要有针对性的选择进行度量的切入点，但切记不能过分追求度量的范围与数量。在这一部分中，要收集资源的事件，资源的运行性能，并且通过必要的工具，收集并整理资源间的调用关系。通过资源管理工具，对收集到的信息进行整理和处理，并以相对直观的方式表现出来，使管理和运维人员对系统资源的运行状况有一个相对清晰的概念。

在业务服务管理中，应建立业务服务的模型和业务影响性分析，并且一切都应该从业务服务的角度出发（而不是从IT 的角度）。在这一部分中，最好有了解业务的人员参加，因为只有了解业务的人员才知道对于某一业务服务，什么是最重要的。

其次，要建立可行的手段了解业务服务的结果。尽量从业务服务的边际上发现并测量业务服务的状态，而不是通过若干个中间指标生成。那么，哪些业务服务的状态是最常要了解的？

系统的可用性，即在多长时间内某项服务是能够被最终用户所正常使用的。随着业务复杂性的不断提升，影响业务可用性的因素也越来越多，要通过分析，了解构成业务可用性的“短板”，及时加以度量，并通过手段进行提升。

响应时间是另一个经常使用的指标，很多时候，它直接影响着用户对业务服务的满意程度。试想一下，您从网页上提交一个服务请求，您的耐心给您多长时间来等待网页的回应？对于响应时间的测量也有多种方式，如使用类似测试工具那样的交易模拟机制，定期通过网络触发测试交易并记录其响应时间；也可以从服务器的角度，通过性能管理工具直接记录后台服务器中交易的相应时间。这两种方法各有特点，应结合使用。

客户满意度也是一个重要的业务服务指标。业务服务的对象即为客户，所谓从业务服务出发，就不能不包含客户对业务服务的印象。越来越多的业务服务管理项目，把客户满意度作用一个关键的指标加以度量。读者可以都有经历，在电话银行服务后被要求对当次服务进行评价。其他的客户满意度还包括服务中心的正在处理案件数，平均处理时间等。在设计IT 服务管理项目中，应该考虑将现有的与客户满意度有关的数据如何包含进来，并从一个合适的切入点导入的到业务服务模型之中。

其他的与业务服务结果有关的指标还有很多，如系统/网络的吞吐量；重要组件（如批量处理，离线数据处理）的处理时间等。在项目设计过程中，应均衡考虑，从简单直接的指标入手，逐渐丰富。

第三点，从向与业务服务相关各方提供一个有关业务实时交付情况的集成监视仪表盘（Dashboard）开始开展项目。通过可视化的手段，让各方及时了解系统业务服务的状态，这往往能够在短时间内达到事半功倍的效果。所谓‘业务服务的相关各方’，是指那些系统服务的使用者，付费者，管理者，等等，在现今的企业中，可能涉及到企业中绝大多数的人员。让这些人有一个直接的手段或方法了解其所使用，其所购买，或其所管理的服务的运行状态，是实施系统服务管理的目的，而通过一个集成仪表盘式的界面将众多的KPI 合理有机的组合，展现，是项目成败的关键所在。

在构建集成监控仪表盘的初期，甚至可以考虑以‘只读’的模式进行展现。即在项目的初期，只是通过集成监控仪表盘对不同监控工具或用户相关数据进行有机的集成，展现，并不作为系统管理的‘门户’供使用者发现问题后能做深度问题发掘与分析。也就是说，‘业务服务的相关各方’只能通过这个界面了解服务状态，而不能直接通过它发现并处理问题的根源。这样做的好处是，在项目初期，尽量减少服务管理项目的复杂程度，使大家可以将更多的资源用在如何将各种手段获取的KPI 映射，转化为各方接受的业务服务状态。而关于问题跟踪，深度分析的功能，可以通过相关的专业工具或手段进行。

第四，应该看到，在当前的企业组织结构，尤其是 IT 部门的组织中，依照技术特点或技术种类，IT 系统的管理被分成多个小组。这种分割基本上还完全是依技术而定，而没有依照IT 系统所服务的业务来分。这样的管理方式有其存在的必要性和必然性，当然从业务管理的角度也有其弊端。上面提到的建立整合的服务管理监控仪表盘，从某种程度上可以缓解个技术组织间的隔阂，使不同技术组织都对一个相关的业务服务有一个一致的了解；在另一方面，通过必要的技术手段，建立并强化流程式的管理，针对于某项业务服务管理，通过流程，串联起各个小组中的相关人员，形成临时的虚拟团队，也有利于开展以业务为导向的管理工作。

关于业务管理流程，是一个当前非常热门的话题，国际上众多标准化组织也针对IT 服务管理总结出很多的理论和体系，如ITIL 等。针对企业中IT 管理流程实施的成熟度，国际知名的IT 咨询研究公司Gartner 曾做过相关的市场调研，对于IT 管理流程的实施程度，从初始的阶段，到其高级阶段，分为0 到5 共6个层次。如下表：

Gartner 的调查结果显示，在2007 年，绝大多数企业处于1 和2 之间，即对流程的重要性有了充分的认知，对部分IT 服务也开始指定并遵守一些必要的管理流程。调查的另一个出人意料的结果是，到2012 年，大多数企业的流程成熟的也只能达到2 和3 之间。也就是说，对于企业中IT 服务管理流程的实施，并不像人们普遍认为的那样简单容易。

所以，对于企业计划 IT 服务管理，我们的建议是从简单入手，如可以从实施可用性管理，性能管理等流程开始，将这些流程在企业中的实施提升到主动的阶段或层次，即针对上述管理，制定具有可重复的流程，并且实现这些流程的自动化。而对于诸如变更管理，服务生命周期管理等较复杂的管理流程，可以考虑稍后再开始进行。

接下来，让我们讨论一下有关 KPI 的问题。虽然企业的IT 管理组织还是依照技术特点而定，（而不是依照所提供的服务而定），我们还是可以从不同的技术系统中获取必要的有关业务的关键运行指标（KPI）。然后再对这些KPI 进行组合，处理等后续工作，提炼出有关业务服务状态的业务服务管理指标，并依前面提到过的方式在企业集成服务管理仪表盘上进行显示。

对 KPI 的选择至关重要，并且需要业务人员与相关IT 人员充分合作，深度讨论而得到。其中一条重要的原则就是，切勿过多！只选择那些非常关键的一组指标。这里有一个经验数值，即每个服务或系统最多不易超过20 个KPI。其次，建议在服务的边界处采集KPI。在SOA（Service Oriented Architecture）的架构中，组成系统的是众多的服务，KPI 的采集点就应该在各项服务或各组服务的对外接口处；对于那些传统架构的IT 系统，则应该在组件的对外接口处进行，如数据库的对外连接，子网的边界处等。

第六点，有关“黄线”的问题。在指定业务服务监控的报警阈值时，大家都会指定两个值，预警值（即常说的Warning，用黄色表示）和临界值（即Critical，多用红色）。这样做的好处是，当出现黄色报警时，管理人员就可以采取一些必要的措施，避免事态进一步恶化；如果没有好转，出现了红色报警，则采取更进一步的手段，调用更多的资源，牵扯进更多的人力物力进行解决。这样做的初衷是好的，但是也有其弊端。

静态的定义两个数值，分别作为预警值和临界值的做法很不灵活，有时候也不准确。如在某些情况下，系统服务超出预警值后，其变化可能是多种情况，如恶化的速度加快或减免，甚至于情况又自动好转等。针对这种情况，市场上有的服务监控产品提供了较智能的报警方式，即以结果为导向的报警，用户无需指定预警值，只需给定临界值，和一个达到临界值的预警时间，监控软件会根据当前KPI 的变化趋势，计算其达到临界值的预计时间，如果这个时间比用户定义的时间短就发生预警报警。

第七点，一个好的业务服务管理中，一定会有一些用于诊断的工具。使用这些工具，用户可以在业务服务受到影响时，及时隔离问题，进行必要的深入研究，进行相应的资源调配或程序逻辑改进，从而根本解决问题。

根据笔者的经验，诊断工具可分为以下三个方面：一，交易方面，采用跟踪或模拟交易等手段，检查交易的运行，对交易的端到端响应时间进行细分，定位影响交易响应的瓶颈等；应用方面，在应用程序和中间件级别进行故障诊断，结合业务逻辑，分析，调试，优化应用程序及代码；三，资源方面，进行资源使用分析，监控各组件运行，建立相关的自动化操作，对工作负载的变化趋势进行可视化处理并优化资源环境。

IT 服务管理是一个过程，它将集成企业内部现有的或正在建设的资源管理，应用管理，事件管理等多个项目，并对这些相关项目在实现方法与策略上提出要求与指导。它不简单的是一个技术领域的项目，不应只限于技术产品的招投标与采购，更应该关乎组织结构，管理方式和技术实现，以一个整合的方式来实施。

目前，国内的部分银行，大型的电信等 IT 程度较高的企业都在开始或考虑实施IT 业务服务管理，这是一个潮流，更是一个方向。在这个方向上，作为IT系统（甚至于企业的）管理者，与IT 系统的使用者应该有充分的沟通和共识，统一思想，制定出一致的目标和实施步骤，充分考虑业务流程的调整，组织结构的优化，技术实现与服务厂商的能力和水平等多方面因素。

我们相信，随着人们对 IT 服务管理的认识不断加深，市场上管理理念的不断完整，以及相关厂商，产品的不断完善，IT 业务服务管理必将越来越显现出其重要性，对其投入的产出也将被越来越多的企业所认识与接受。

以上讨论的内容与思路，来源于笔者近几年参与的有关业务服务管理和 IT资源管理的工作经验和教训，并结合了IBM 公司软件部Tivoli 产品发展策略小组对业界实施IT 服务管理的建议。

【作者简介】

张劼，andy.j.zhang@gmail.com

IBM 软件部Tivoli 资深技术工程师。1996 年加入IBM 中国公司，一直从事系统集成方面的技术支持。曾参与过国内多家大型银行的主机系统大集中项目和IT 管理项目。