构建端到端的IT服务管理（二）
学习资料： ITIL培训基地专家讲堂直播 300期视频回放
服务的性能：设想您走到某一台自动取款机前，插入银行卡，希望取出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%的准确”，用户只能根据技术，投资，工期等多方面因素与现状，得到一个相对好的结果。
我是个凑数的。。。 前排，哇咔咔
页:
[1]