【IT168 信息化】

    应用性能管理（Application Performance Management，简称APM）最初是一种控制大型机性能的方法，它的应用贯穿整个系统开发生命周期（Systems Development Life Cycle，简称SDLC）。现在，由于最终用户的业务处理是靠越来越复杂的应用进行的，因此应用性能管理变得越来越重要了。应用性能管理从大型机环境进入基于Web的分布式环境以后，已经具备了实现端到端管理所必需的环境条件。因此可以全力关注哪些问题影响了企业应用的性能和可用性，关注如何识别这些问题、如何确定它们的重要性以及如何解决这些问题。

    在前一篇综述中我们介绍过应用性能管理从根本上可以看作是一套基础设施监测工具。因为清楚各项事务处理任务通过系统时所走路线的状况，才能实现有价值的监测，所以集中精力监测对应用起支持作用的基础设施组件的状态很重要。同样的，只有了解了最终用户的体验，才能知道应用是否发挥了应有的作用，因此我们需要了解应用为用户提供的服务好不好。最后，只有将最终用户体验与基础设施监测联系起来，做出的诊断才有意义，因此，当用户体验不好时，我们无疑需要到基础设施中寻找根本原因。

    在本文中，我们将探讨在数据中心运行中，应用性能管理怎样左右那些在大型机上使用的、一般而言更加结构化的工具和流程，以及应用性能管理如何受到这些工具和流程的左右。数据中心会牵涉到大型机、分布式系统和Web系统的集成。

    资源性能管理

    几乎每一个运行z/OS（大型机）系统的公司都实施了某种级别的性能管理，这些公司可选择的系统和资源监测工具有很多。一般而言，这些工具基于SMF数据进行监测、提供报警信号和实现自动化，以此实施系统资源管理。另外，各公司还可能用更加专门化的工具来监测和协调DB2、CICS、Websphere MQ、VSAM等环境。我们接下来马上探讨一套“组件”或平台工具，对一个整体但却很复杂的系统进行监测。

    一般而言，这些工具能够很好地完成高级资源监测任务，并能够对子系统进行力度更高和更详细的监测。例如，这些工具能够就参数调整向DB2或CICS专业人员提供良好的反馈信息，从而在特定环境中发现提高性能的机会。这套在大型机上使用的、相对成熟的工具已经孕育了一种定义完备的资源监测方法。采取主动性能管理方法（有时也称为MIPS管理）的企业已经获得了显著成果，由于无需为支持效率低下的应用而升级CPU，因而大大降低了成本。尽管主要的推动力是通过减少指令数来降低成本和防止成本，但是也有附加好处，如应用执行速度更快和代码质量的提高。

    尽管主要的关注点仍然是，无论在哪里，只要可能，都要减少指令，但是人们也越来越强调最终用户的感知了`，这是因为技术环境变得更加复杂了（例如：Web、SOA、EDI），企业也需要更好地实现IT与企业目标的一致性。事务处理的响应时间不再与大型机子系统的性能直接相关；也不能仅因为DB2资源可用，就认为使用DB2的应用运行良好。而且，今天的企业为达到目标，与重视成本控制一样，非常重视最终用户体验到的性能。这是大多数大型机性能管理解决方案力不从心的地方，因为这类解决方案主要关注资源监测、资源协调和纠错。这种局限与我们在分布式环境中所看到的情形相似――一套工具常常无法识别最终用户察觉到的应用性能问题。

    从应用性能管理的角度来看，让最终用户体验也成为进行调整的依据之一，或者进行调整时重视最终用户体验，我们就可以扩大这些大型机工具的适用范围。这从某种程度上翻转了原来的因果关系。通过管理和调整由最终用户响应时间衡量的应用性能，我们可以减少被调整应用和事务处理的总体资源需求。不过，以最终用户为导向的应用性能管理的主要目标不是基于MIPS降低成本，而是实现卓越的用户体验。

    一开始就要明确目标

    任何项目一开始就确定具体的目标，成功的可能性就会极大地提高，应用性能管理也不例外。就大型机而言，MIPS管理非常好的实施常常以定义非常完备的目标开始，如“降低前10个作业步的CPU使用率”，或“降低CICS Region CICSPROD中事务处理的响应时间”。这些降低成本/防止成本的目标是通过减少资源消耗实现的，是最基本的管理，企业在考虑基于最终用户感知的应用性能管理之前，要先处理这些问题。

    应用性能管理的目标也许更难以阐明，然而却同等重要。实际上，人们常常认为应用性能管理目标升级或发生了转变，因为这些目标随着时间的推移会变得更宏伟。在实现这些目标的过程中，当然需要衡量所取得的进步，同时还要确保这种衡量对业务是有意义的，例如，可以选择用Apdex性能指数，它实质上是用从0（不可接受）到1（极好）的标度以数字来表示用户满意度。

    因此，就可接受的最终用户性能而言，一般的业务要求可以转化成如下的应用性能管理目标：

    以Apdex指数来计算，最终用户对在线银行应用的体验将在6个月内达到0.85分（在Apdex体系中，代表“良好”），在18个月之后达到0.94分（在Apdex体系中，代表“极好”）的目标。

    您最好还是确定实现目标的步骤或检查点，因为我们可以假定，目前的体验没到可接受的程度，或者至少是不知道到什么程度，而实现这一目标将需要反复改进服务。

    从这种比较通用的做法开始，我们可以看到，我们需要衡量最终用户的体验，因为这是衡量业务成效的标准，我们是否取得成功将靠这个标准来衡量。我们还需要衡量支持应用的系统组件的性能，以确定在达到峰值使用率时可能出现的资源瓶颈，并调整系统，以提高性能。因此，我们需要了解应用在系统中运行所走过的路线，以及在这条路线上存在的各种相互依赖的关系。根据当前的监测记录和分析，我们可以了解对这条路线的监测是否全面。我们还要能够将监测结果与最终用户的体验联系起来，及时说明在这条存在各种依赖关系的路线上，用户体验与监测结果的关系。