应用性能管理（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降低成本，而是实现卓越的用户体验。#p#
Apdex：一开始就要明确目标
任何项目一开始就确定具体的目标，成功的可能性就会极大地提高，应用性能管理也不例外。就大型机而言，MIPS管理最佳实施常常以定义非常完备的目标开始，如“降低前10个作业步的CPU使用率”，或“降低CICS Region CICSPROD中事务处理的响应时间”。这些降低成本/防止成本的目标是通过减少资源消耗实现的，是最基本的管理，企业在考虑基于最终用户感知的应用性能管理之前，要先处理这些问题。
应用性能管理的目标也许更难以阐明，然而却同等重要。实际上，人们常常认为应用性能管理目标升级或发生了转变，因为这些目标随着时间的推移会变得更宏伟。在实现这些目标的过程中，当然需要衡量所取得的进步，同时还要确保这种衡量对业务是有意义的，例如，可以选择用Apdex性能指数，它实质上是用从0（不可接受）到1（极好）的标度以数字来表示用户满意度。如需更多信息，请登录：www.apdex.org。
因此，就可接受的最终用户性能而言，一般的业务要求可以转化成如下的应用性能管理目标：
以Apdex指数来计算，最终用户对在线银行应用的体验将在6个月内达到0.85分（在Apdex体系中，代表“良好”），在18个月之后达到0.94分（在Apdex体系中，代表“极好”）的目标。
您最好还是确定实现目标的步骤或检查点，因为我们可以假定，目前的体验没到可接受的程度，或者至少是不知道到什么程度，而实现这一目标将需要反复改进服务。
从这种比较通用的做法开始，我们可以看到，我们需要衡量最终用户的体验，因为这是衡量业务成效的标准，我们是否取得成功将靠这个标准来衡量。我们还需要衡量支持应用的系统组件的性能，以确定在达到峰值使用率时可能出现的资源瓶颈，并调整系统，以提高性能。因此，我们需要了解应用在系统中运行所走过的路线，以及在这条路线上存在的各种相互依赖的关系。根据当前的监测记录和分析，我们可以了解对这条路线的监测是否全面。我们还要能够将监测结果与最终用户的体验联系起来，及时说明在这条存在各种依赖关系的路线上，用户体验与监测结果的关系。
将应用性能管理作为一个流程来实施和改进
接下来，我们考虑面向流程的应用性能管理方法。将六西格玛DMAIC（定义、衡量、分析、改进和控制）模型作为一种结构化方法，用来实施和改进应用性能管理解决方案，因为在我们向着“极好”的Apdex分数这个最终目标前进的过程中，需要反复改进这个流程的各个组成部分。
在我们检查DMAIC流程时，请记住以下两个最重要的问题，这对有效的端到端应用性能管理解决方案很重要：
·与业务的一致性 ―― 这是从零开始的、从一开始就考虑业务成果的设计的主要目标。对企业来说，重要的是以性能和可用性来衡量用户体验。
·相关性与故障隔离 ―― 将基础设施监测上升到应用性能监测的关键是，能够透视根本原因和影响，从而真正了解基础设施衡量标准如何影响最终用户的响应时间，以及因此了解企业的生产率。
定义
首先，将目标转化为对问题的定义：衡量最终用户感知，让应用用户依据设定的Apdex目标判断最终用户的满意度。这可以通过取样和推断完成，利用综合性或机器人式代理定期执行预定义的、代表典型用户/应用互动的脚本。如果选择了这种方法，那么就应该确保对问题的定义，本质上也就是服务级别协议，能够清楚地解释这些样本，使这些样本成为可以接受的衡量最终用户体验的指标。对很多环境来说，用一种“无代理”式数据中心专用设备衡量全部应用用户的响应时间，可以覆盖多得多的真实用户，从而能迅速洞察甚至最深入细致的综合性方法也可能错过的问题。理想情况下，两种方法相结合，可同时获得综合性衡量方法的受控性和主动性益处以及对真实用户进行被动式衡量的好处。
通过监测最终用户感知，可以了解IT对业务目标的支持作用有多大，用户不满意是否频繁出现，以及用户受挫的程度（如果采用无代理方法）。简言之，这为确定Apdex分数提供了信息。我们还需要支持组件级性能衡量标准，这既需要了解经过系统的路线，又需要了解一些“正常”行为的基础定义。我们可能想监测每个服务器的性能状况、每条网络连接的状态以及支持应用的每个流程、程序、区域、数据库等等的状况。这需要了解应用在满足用户请求时走过的物理和逻辑路线，这条路线也许非常简单，可以在白板上简要叙述出来，也可能十分复杂，需要详细了解应用的互动过程，也许还要借助反映相互依赖关系的实用工具。
最后，我们要能够展示衡量结果与事件之间的相关性。相关性意味着一种实时关系，例如，在用户体验到不可接受的延迟时，衡量磁盘队列深度。相关性还意味着对正常行为的了解，即能够比较正常磁盘队列深度与用户体验到性能问题时测量到的磁盘队列深度。根据这种相关性，就有可能设定一个警报，当然，是假定这个测量值在引起性能问题上起了作用。
从相关性中还可以确定受影响的用户数量或类型，或者也许是对业务流程的影响，因此从相关性中还可以获得一些业务影响产生的环境信息，并因此知道这种业务影响的代价。有关业务环境的信息有助于IT部门恰当地确定，先对哪些问题做出反应，而且业务环境也被看作是业务服务管理（Business Service Management，简称BSM）不可或缺的组成部分。
在流程断成熟的过程中，也许会重新定义问题。也许对问题的定义所涉及的范围变得越来越窄了。例如，可能有一套特定的事务处理程序对支持业务流程至关重要，那么也许会改进原来的定义，以强调这些特定的事务处理程序。
也许，会针对特定的事务处理程序调整对可接受的响应时间的定义。另一方面，原来的定义所涉及的范围也许扩大到包括更新的应用组成部分，或原来未考虑的其他有关应用。
请记住，您不可能监测所有任务和所有组件的所有可能监测的细节。如果您试图这么做，那么您很快就会被太多的数据压垮，而且很多数据是无关紧要的。从完备定义的目标开始，就有机会获得可量度的成功、逐步的改进和适当的扩展。始终将业务目标摆在第一位，然后再将业务目标转化成合适的、对应用起支持作用的技术应该达到的目标。
衡量
我们衡量最终用户的体验，因为用这个衡量标准，我们能够建立IT服务器质量与业务目标的联系。我们还需要衡量基础设施的一些重要的方面。您也许已经有了特定于平台的工具，而且这些工具已经完成了一些或大多数衡量最终用户体验的任务。您将这些工具组装到一个应用性能管理解决方案中的时候，也是评估这些工具是否足够灵活、能够满足您的需求的好机会。这些工具监测的衡量标准恰当吗？门限、时间间隔和警报能恰当地调节吗？这些工具怎样报告信息？这些信息能恰当地集成和展现相关性吗？这些工具为方便诊断提供了合适的深入研究空间吗？这些工具抓取了适合您的诊断信息吗？在采用更大型的应用性能管理解决方案的情况下，这些问题是需要各领域专家重新考虑的。
几乎与您监测的东西同样重要的是，您不监测的东西。很多系统监测工具和特定于子系统的工具提供成百上千种衡量标准，但是要确定性能问题，常常仅需要其中的几种衡量标准就可以提供足够的信息。
分析
通过回顾可用的应用性能报告，详细了解一个应用的时间是怎样用的、用在了哪里，性能分析师可以发现改进的机会。某些（更加普遍的）性能问题会在大型机系统监控器中相当清楚地显示出来。这些资源限制可以用各种不同的方式来减轻，如工作量管理器（Workload Manager）定义、作业分类、负载均衡和工作调度。其他性能问题不会那么明显，需要更多的关注以及由专门的性能管理工具建立的详细数据抓取概要。这类详细的概要可能看起来很吓人，尤其对新用户来说更是这样。一个能实现抓取自动化、提供根本原因分析、甚至提出纠正的解决方案即使对简单的环境也是非常宝贵的，而对更加复杂的环境几乎就是必需的了。
这是应用性能管理流程的核心步骤。不仅可以根据这个步骤进行故障域隔离和根本原因分析，而且可以实现持续服务改进（CSI）。相互依存的故障可以用来改进门限设置（以改进应用性能管理解决方案），并作为修改系统设计（以改进IT服务质量）的依据。
改进
该领域的专家与一个大的团队一起确定改进办法，以纠正错误的事情或问题。在这里，流程应该有分支了。对应于ITIL事件管理（Incident Management）的当前业务目标是，尽可能快地纠正问题和恢复服务质量。考虑应用交付基础设施本身：识别资源瓶颈或应用故障，可提供快速纠正问题所需的信息。同样的，改进应用性能管理解决方案本身也很重要，因为我们认为应用性能管理是一个重复的流程，可从持续服务改进中受益。应用性能管理工程师应该评估，所监测的是否是恰当的衡量标准，这些衡量标准是否相互建立了恰当的联系，以提供正确的故障域信息。当然，进行这些评估时应该牢记业务目标――代表“极好”的Apdex分数，也就是说，评估应该直接与衡量最终用户体验挂钩。
这并不意味着，应该忽视与最终用户体验无关的衡量，这类衡量对支持其他目标也许是重要的，如磁盘使用策略、容量规划，等等。不过这确实意味着，这些衡量应该依据不同的标准进行。
控制
这最后一步是最容易跳过的。不过，如果没有这一步，我们就会重复事件管理，我们不会成为一个成熟的IT机构，我们也不会实现与业务取得一致的目标。看看识别资源瓶颈和应用故障是怎样让该领域专家快速恢复服务的吧，而快速恢复服务是事件管理的主要目标。以避免将来出现问题为目标进行系统调整所需要的规划信息也由这最后一步提供，而避免将来出现问题是问题管理的主要目标。根本原因也许是资源限制，如Java虚拟机（JVM）可用的存储器等。在分析那一步确定这个问题，而事件管理也许通过重新启动Java虚拟机来释放存储器。但是除非我们采取一些步骤来防止瓶颈，如消除存储器泄露的根源或给系统增加存储器等，问题可能还是会发生。要避免对引起问题的特定限制因素的敏感性，可以改变系统架构、增加资源、改变程序逻辑、改变服务策略等等。
类似地，应用性能管理解决方案本身也可以改进。可以考虑调整报警门限和报警规则，以更早地对将来可能出现的问题发出警报，这样可以在业务受到影响之前采取行动。
执状态显示板可以快速洞悉关键业务（例如，索赔处理）的当前服务质量。IT管理人员能够实时了解用户受影响的严重程度、人员效率（PHL）以及由性能不佳导致质量不佳而增加的成本。
服务运行图使IT专业人员能够看到受影响的业务服务和不同的位置。IT专业人员可以从这里开始，继续深入研究，以找到影响索赔处理的故障域。
故障域的即时隔离提醒合适的技术团队采取纠正措施。这张图显示，大型机层是问题的原因。负责大型机的人员可以立即深入研究，以进一步找到并消除根本原因。
大型机专业人员可以深入研究，以查看问题的根本原因。例如，这张图显示，就索赔处理而言，DB2有个问题，而且列出了哪个DB2流程使用的资源最多（例如，响应时间和CPU时间）。这有助于专业人员迅速了解，SYSSH200流程总的占用时间最长，因此需要检查这个流程。
一旦深入到了SYSSH200流程：Strobe显示所有SQL语句，因此专业人员可以点击指示占用时间的标签，进行归类，以进一步找出根本原因。更进一步的深入研究可显示调整建议，以立刻解决问题。#p#
总结
现在的数据中心由于支持跨分布式和大型机平台运行的关键业务应用而变得日益复杂和昂贵了。这些应用常常依靠大型机服务，不再能够作为相互隔离的孤岛来有效管理了。尽管组件性能可能影响最终用户的响应时间，但是在资源利用和响应时间之间，不再存在清晰和直接的关联了。为了满足今天以客户为中心的企业需求，IT部门必须使用与业务部门相同的标准，即用户满意度，来管理性能。将已有组件监测解决方案变成真正的应用性能管理解决方案，是实现这种IT与业务一致性的重要步骤，并可通过衡量用户体验以及展现应用性能与最终用户体验的关系来完成这一步。
