构建端到端的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 服务管理的建议。