ApplicationPerformanceManagement（APM）最初是一种控制大型机性能的方法，其应用贯穿于整个系统开发生命周期（SystemsDevelopmentLifeCycle，SDLC）。如今，随着最终用户业务流程由越来越复杂的应用程序执行，应用程序性能管理变得越来越重要。应用性能管理从大型机环境进入基于Web的分布式环境后，已经具备了实现端到端管理的必要环境条件。这样您就可以关注哪些问题正在影响企业应用程序的性能和可用性，如何识别这些问题，如何确定它们的重要性，以及如何解决它们。我们介绍过，应用程序性能管理可以从根本上被视为一组基础设施监控工具。由于可以通过了解每个交易通过系统的路由状态来实现有价值的监控，因此重点监控支持应用程序的基础架构组件的状态非常重要。同样，只有了解终端用户的体验，才能知道应用是否发挥了应有的作用，所以我们需要知道应用为用户提供的服务好不好。最后，只有将最终用户体验与基础设施监控联系起来时，诊断才有意义，因此当用户体验不佳时，我们肯定需要从基础设施中寻找根本原因。我们将探讨应用程序性能管理如何影响数据中心运营中大型机上使用的通常更加结构化的工具和流程，以及如何受到这些工具和流程的影响。数据中心可能涉及大型机、分布式系统和Web系统的集成。资源性能管理几乎每家运行z/OS（大型机）系统的公司都实施了某种程度的性能管理，并且有许多系统和资源监控工具可供选择。一般来说，这些工具通过监控、提供告警信号和基于SMF数据实现自动化来实现系统资源管理。此外，公司可能会使用更专业的工具来监控和协调环境，例如DB2、CICS、WebsphereMQ和VSAM。我们立即讨论一组“组件”或平台工具，用于监控单一但复杂的系统。总的来说，这些工具可以很好地完成高级资源监控任务，并支持对子系统进行更密集和详细的监控。例如，这些工具可以向DB2或CICS专业人员提供有关参数调优的良好反馈信息，从而识别在特定环境中提高性能的机会。大型机上使用的相对成熟的工具集催生了一种定义明确的资源监控方法。采取主动方法进行性能管理（有时称为MIPS管理）的组织已经看到了显着的结果，通过消除升级CPU来支持低效应用程序的需要来降低成本。虽然主要推动是通过减少指令数来降低和防止成本，但也有一些附带好处，例如更快的应用程序执行和提高的代码质量。虽然主要重点仍然是尽可能减少指令，但随着技术环境变得更加复杂（例如：Web、SOA、EDI），也越来越重视最终用户的感知，企业还需要更好地实现IT的一致性和企业目标。事务处理的响应时间不再与大型机子系统的性能直接相关；使用DB2的应用程序也不应该仅仅因为DB2资源可用就表现良好。此外，当今的企业对最终用户体验的性能的重视与他们对成本控制的重视一样多，以实现他们的目标。这是大多数大型机性能管理解决方案的不足之处，因为它们专注于资源监控、资源协调和错误纠正。这种限制类似于我们在分布式环境中看到的情况——一组工具通常无法识别最终用户感知到的应用程序性能问题。从应用程序性能管理的角度来看，我们可以通过将最终用户体验作为调整的标准之一，或者在调整时考虑到最终用户体验，来扩大这些大型机工具的范围。这在一定程度上颠倒了原来的因果关系。通过管理和调整以最终用户响应时间衡量的应用程序性能，我们可以减少调整后的应用程序和事务的总体资源需求。然而，面向最终用户的应用程序性能管理的主要目标不是基于MIPS降低成本，而是实现卓越的用户体验。#p#Apdex：从一开始就明确目标 凡是在一开始就明确目标的项目，都会大大增加成功的概率，应用性能管理也不例外。对于大型机，MIPS管理最佳实践通常从明确定义的目标开始，例如“减少前10个作业步骤的CPU使用率”或“减少CICS区域CICSPROD中事务的响应时间”。这些通过减少资源消耗实现的成本降低/预防目标是企业在考虑基于最终用户感知的应用程序性能管理之前需要解决的基本管理问题。 应用程序性能管理的目标可能更难以阐明，但同样重要。事实上，它通常被视为应用程序性能管理目标的升级或转变，因为它们随着时间的推移变得更加雄心勃勃。在实现这些目标的过程中，当然需要衡量取得的进展，同时还要确保这种衡量对业务有意义。例如，您可以选择使用Apdex性能指数，该指数本质上是从0（不可接受）到1（优秀）的等级以数字表示用户满意度。欲了解更多信息，请访问：www.apdex.org。 因此，在可接受的终端用户性能方面，一般业务需求可以转化为以下应用性能管理目标： 按Apdex指数计算，网银应用的终端用户体验将在6以内1个月内达到0.85分（在Apdex系统中，代表“好”）的目标，18个月后达到0.94分（在Apdex系统中，代表“优秀”）的目标。 你最好确定到达那里的步骤或检查点，因为我们可以假设当前的体验是不可接受的，或者至少不为人所知，而实现这一点将需要对服务进行迭代改进。 从这种更通用的方法开始，我们可以看到我们需要衡量最终用户的体验，因为这是业务效率的衡量标准，我们的成功将通过这一衡量标准来衡量。我们还需要测量支持应用程序的系统组件的性能，以确定高峰使用时可能出现的资源瓶颈，并调整系统以提高性能。因此，我们需要了解应用程序在系统中运行的路径，以及这条路径上存在的各种相互依赖关系。根据目前的监测记录和分析，我们可以知道这条路线的监测是否全面。我们还需要能够将监控结果与终端用户的体验联系起来，及时说明这条路由上的用户体验与监控结果之间的关系，以及各种依赖关系。将应用程序性能管理作为一个过程实施和改进 接下来，我们考虑一种面向过程的应用程序性能管理方法。使用六西格玛DMAIC（定义、测量、分析、改进和控制）模型作为实施和改进应用程序性能管理解决方案的结构化方法，因为我们朝着“优秀”Apdex分数的最终目标前进，流程的各个组成部分需要迭代改进。 在我们检查DMAIC流程时，请牢记以下两个最重要的问题，这两个问题对于有效的端到端应用程序性能管理解决方案很重要：与业务保持一致——这是从零开始的首要目标从一开始就考虑业务成果进行设计。对于企业而言，重要的是从性能和可用性方面衡量用户体验。关联和故障隔离——将基础设施监控提升为应用程序性能监控的关键是能够洞察根本原因和影响，以真正了解基础设施指标如何影响最终用户响应时间，从而影响企业生产力。定义 首先，将目标转化为问题的定义：衡量终端用户的感知，让应用用户根据设定的Apdex目标来判断终端用户的满意度。这可以通过采样和推理来完成，合成或机器人代理会定期执行代表典型用户/应用程序交互的预定义脚本。如果选择这种方法，那么应该确保问题的定义，本质上是服务水平协议，清楚地说明了这些样本，使它们成为可接受的最终用户体验衡量标准。对于许多环境，使用“无代理”数据中心特定设备测量所有应用程序用户的响应时间可以覆盖更多的真实用户，提供快速洞察，即使是最精细的综合方法也可能遗漏问题。理想情况下，将这两种方法结合起来，既能获得综合测量方法的受控和主动优势，又能获得被动测量对真实用户的好处。 通过监控最终用户的看法，可以了解IT对业务目标的支持程度、用户不满意发生的频率以及用户挫败感的程度（如果使用无代理方法）。简而言之，这提供了用于确定Apdex分数的信息。我们还需要支持组件级别的性能指标，这需要了解通过系统的路由以及对“正常”行为的一些基本定义。我们可能希望监控每个服务器的性能，每个网络连接的状态，以及支持应用程序的每个进程、程序、区域、数据库等的状态。这需要了解应用程序为满足用户请求所采用的物理和逻辑路径，这可以像白板草图一样简单，也可以更复杂，并且需要详细了解应用程序的交互，或许可以借助反射实用程序来实现相互依赖性。 最后，我们需要能够显示测量结果和事件之间的相关性。相关性意味着实时关系，例如当用户遇到不可接受的延迟时测量磁盘队列深度。相关性还意味着了解正常行为，即能够将正常磁盘队列深度与用户遇到性能问题时测量的磁盘队列深度进行比较。基于这种相关性，可以设置警报，当然，假设这种测量在导致性能问题中发挥了作用。 从相关性中你还可以确定受影响的用户数量或类型，或者可能对业务流程的影响，所以从相关性中你也可以得到一些关于业务影响的上下文信息，从而知道业务影响价格.有关业务上下文的信息有助于IT正确确定首先响应哪些问题，并且业务上下文被视为业务服务管理(BSM)的一个组成部分。 随着流程的成熟，问题可能会被重新定义。也许问题的定义越来越窄了。例如，可能有一组特定的事务处理过程对支持业务过程至关重要，并且可以改进原始定义以强调这些特定的事务处理过程。 或许，可接受的响应时间的定义是针对特定的事务处理程序进行调整的。另一方面，原始定义的范围可能会扩展到包括较新的应用程序组件，或其他最初未考虑的相关应用程序。 请记住，您不可能监控所有任务和所有组件的所有可能细节。如果您尝试这样做，您很快就会被太多的数据淹没，而且其中大部分是无关紧要的。从明确定义的目标开始，可以提供可衡量的成功、渐进式改进和适当扩展的机会。始终将业务目标放在首位，然后将业务目标转化为支持应用程序的适当技术应该实现的目标。衡量 我们衡量最终用户体验，因为通过这个指标，我们能够将IT服务器质量与业务目标联系起来。我们还需要衡量基础设施的一些重要方面。您可能已经拥有特定于平台的工具，这些工具已经完成了部分或大部分测量最终用户体验的工作。当您将这些工具组合成一个应用程序性能管理解决方案时，这也是一个很好的机会来评估这些工具是否足够灵活以满足您的需求。这些工具监控的指标是否合适？是否正确调整了阈值、时间间隔和警报？这些工具如何报告信息？这些信息是否被正确整合并显示出相关性？这些工具是否为深入研究提供了合适的范围以促进诊断？这些工具是否为您捕获诊断信息？在更大的应用程序性能管理解决方案的情况下，这些问题需要各个领域的专家重新考虑。 几乎与您监控的内容一样重要的是您不监控的内容。许多系统监控工具和特定于子系统的工具提供成百上千个指标，但通常只有少数指标的信息量足以识别性能问题。分析 通过查看可用的应用程序性能报告以详细了解应用程序的时间花费方式和位置，性能分析师可以确定改进机会。某些（更一般的）性能问题在大型机系统监视器中表现得相当清楚。这些资源限制可以通过多种方式缓解，例如工作负载管理器定义、作业分类、负载平衡和作业调度。其他性能问题不太明显，需要更多关注和由专用性能管理工具构建的详细数据抓取配置文件。如此详细的摘要似乎令人生畏，尤其是对新用户而言。自动爬行、提供根本原因分析、甚至提出更正建议的解决方案即使对于简单的环境也是无价的，对于更复杂的环境几乎是必需的。 这是应用程序性能管理过程中的核心步骤。按照这个步骤不仅可以进行故障域隔离和根本原因分析，还可以实现持续服务改进（CSI）。相互依赖的故障可用于改进阈值设置（以改进应用程序性能管理解决方案）并作为修改系统设计的基础（以提高IT服务质量）。改进 现场专家与大型团队合作确定改进措施，以纠正错误的事情或问题。在这里，流程应该分支。ITIL事件管理的当前业务目标是尽快纠正问题并恢复服务质量。考虑应用程序交付基础架构本身：识别资源瓶颈或应用程序故障可以提供快速纠正问题所需的信息。同样，改进应用程序性能管理解决方案本身也很重要，因为我们认为应用程序性能管理是一个迭代过程，受益于持续的服务改进。应用程序性能管理工程师应该评估是否正在监视适当的指标，以及这些指标是否正确地相互链接以提供正确的故障域信息。当然，这些评估应该考虑到业务目标-表示Apdex得分为“优秀”，也就是说，评估应该直接与衡量最终用户体验相关联。 这并不意味着应该忽略与最终用户体验无关的度量，此类度量对于支持其他目标可能很重要，例如磁盘使用策略、容量规划等。然而，这确实意味着这些测量应该根据不同的标准进行。控制 最后一步最容易跳过。但是，如果没有这一步，我们就会重复事件管理，我们不会成为一个成熟的IT组织，也不会与业务保持一致。了解识别资源瓶颈和应用程序故障如何让领域专家快速恢复服务，这是事件管理的主要目标。最后一步还提供了规划系统调整所需的信息，以避免未来出现问题，这是问题管理的主要目标。根本原因可能是资源限制，例如Java虚拟机(JVM)可用的内存。在分析步骤中确定此问题，事件管理可能会通过重新启动Java虚拟机来释放内存。但是除非我们采取一些措施来防止瓶颈，例如消除内存泄漏的根源或向系统添加内存，否则问题仍然可能发生。为了避免对导致问题的特定约束的敏感性，您可以更改系统架构、添加资源、更改程序逻辑、更改服务策略等。 同样，应用程序性能管理解决方案本身也可以得到改进。考虑调整警报阈值和警报规则，提早提醒您未来可能出现的问题，以便在业务受到影响之前采取措施。 执行状态仪表板可让您快速了解索赔处理等关键操作的当前服务质量。IT经理可以实时了解用户影响的严重程度、人员生产力(PHL)以及因性能不佳而导致的质量不佳的成本增加。 服务运营图使IT专业人员能够查看受影响的业务服务和不同的位置。IT专业人员可以从这里开始，向下钻取以查找影响索赔处理的故障域。 故障域的即时隔离提醒相应的技术团队采取纠正措施。此图显示大型机层是问题的原因。主机负责人可以立即下钻，进一步定位并消除根本原因。 大型机专业人员可以深入了解问题的根本原因。例如，该图显示DB2在索赔处理方面存在问题，并列出了哪个DB2进程正在使用最多的资源（例如，响应时间和CPU时间）。这有助于专业人士快速了解SYSSH200进程耗时最长，因此需要检查。 一旦深入到SYSSH200进程：Strobe会显示所有SQL语句，因此专业人员可以单击指示经过时间的选项卡并对其进行分类以进一步查找根本原因。进一步深入研究可以揭示调整建议，以立即解决问题。#p#Summary 今天的数据中心变得越来越复杂和昂贵，以支持跨分布式和大型机平台运行的关键任务应用程序。这些通常依赖于大型机服务的应用程序无法再作为孤岛进行有效管理。尽管组件性能可能会影响最终用户的响应时间，但资源利用率和响应时间之间不再存在明确且直接的关联。为满足当今以客户为中心的企业需求，IT必须使用与业务相同的指标-用户满意度来管理性能。将现有的组件监控解决方案转变为真正的应用程序性能管理解决方案是实现这种IT业务一致性的重要一步，可以通过衡量用户体验并展示应用程序性能与最终用户体验的关系来实现。
