将应用性能管理作为一个流程来实施和改进
接下来，我们考虑面向流程的应用性能管理方法。将六西格玛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语句，因此专业人员可以点击指示占用时间的标签，进行归类，以进一步找出根本原因。更进一步的深入研究可显示调整建议，以立刻解决问题。
总结
现在的数据中心由于支持跨分布式和大型机平台运行的关键业务应用而变得日益复杂和昂贵了。这些应用常常依靠大型机服务，不再能够作为相互隔离的孤岛来有效管理了。尽管组件性能可能影响最终用户的响应时间，但是在资源利用和响应时间之间，不再存在清晰和直接的关联了。为了满足今天以客户为中心的企业需求，IT部门必须使用与业务部门相同的标准，即用户满意度，来管理性能。将已有组件监测解决方案变成真正的应用性能管理解决方案，是实现这种IT与业务一致性的重要步骤，并可通过衡量用户体验以及展现应用性能与最终用户体验的关系来完成这一步。
