构建端到端的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 系统的变化保持一致；最后，监控点越多，出现错误的可能性就越大，从而对整个的服务管理结果产生偏差，甚至完全无效。