应用程序架构本质，第 6 部分: 了解性能管理

本系列的 第 5 部分讨论性能监视的概念。接下来，第 6 部分将讨论如何计划和实现性能管理技术，以保证设计的平稳实现。就大多数定义而言，性能管理是网络、系统和应用程序组件的端到端响应时间和性能参数的趋势，可用于预测近期的性能下降情况。为了有效地处理组织中的性能管理，您要将重点放在出现问题时采取的具体措施上。可不能小看了这项工作。全球竞争的日趋激烈意味着企业不能对其应用程序架构采取随意监视的方式。相反，必须不断进行审查，以快速确定问题，从而尽可能减少停机时间，在问题带来大的影响前发现这些问题。

技能和能力：展现灵活性和适用性

可以这样说，性能管理中最重要的技能是灵活性。任何应用程序架构的目标都是实现所需的结果，对吧？其结果可能因组织不同而有很大的差别，但总的说来，不能得到所需结果的架构只能算是失败的项目。部署之后发现架构存在问题总会让人有些泄气。而这就是需要灵活性的地方。当架构存在缺陷时，要把您的自尊放在一边，保持足够的灵活性，敢于承认这一事实。您将从经验中得到重要教训，并保持足够开放的态度，以考虑各种解决方案和问题。

同样，适用性在管理架构的性能时也至关重要。有了适应能力后，方向的突然变化或意外的障碍并不会对您造成影响。您能够看到它们所代表的机会，了解性能问题所带来的各种可能性。灵活性可以帮助您认识问题，而适应性可帮助您容忍和接受变更。虽然只拥有其中一项也不错，但如果同时拥有这两项技能，就能从性能管理方面获得更多的支持。

技能和能力：致力于沟通

无论您是谁在哪里工作，如果您不能有效地就性能问题进行沟通，就无法有效地管理性能问题。例如，其他人可能无法认识到情况的严重性，或者不能对您的请求作出响应来提供帮助或信息。更糟糕的是，管理层会质疑您处理问题的能力。而这就使得沟通技能成为了性能管理中不可或缺的部分。

作为架构的一部分，您应该在性能相关的关键时期求助于沟通团队或自行制定沟通计划。这个计划并不需要多么详细，只需要能够帮助您或其他人在出现性能问题时快速地确定应该通知哪些人，以及应该按怎样的频率更新问题解决进度。例如，简单的性能管理沟通计划可以列出应该通知的主要高层管理人员、他们需要了解的信息以及将用于与其进行沟通的方式。无论一年后您是否仍然在处理此项目，其他人都可接替您进行相关工作，准确地知道和哪些人联系以及何时会出现性能问题。

技能和能力：展示分析能力

您分析问题的能力如何？毋庸置疑，这在应用程序架构师工作中占有极大的份量，因此您至少要习惯分析问题和查找解决方案。这很好，因为性能管理对分析技能的要求很高。您这方面的技能将随着在性能管理领域的使用而逐渐增强。

在开发阶段，您将分析信息，以进行预测建模和作出基于事实的决策。在性能管理阶段，您将以两种主要方式使用分析技能。首先，需要整个架构，以确定不同的部分将对整个组织造成什么样的影响或预测可能会与实际偏离的地方。这听起来很简单，但需要能够对根本原因进行专研，而这就是在性能管理期间使用分析技能的另一种方式。将分析技能用于性能管理时，务必记住，您不仅在分析问题来得到解决方案，而且还要分析所涉及的风险和可能会给组织带来的好处。

工具和技术：找到根源

在任何应用程序架构环境中，根源分析对有效的性能管理都是非常重要的。简单说来，这就是以确定和找出性能问题根源为目标的解决方法技术。这可能会比较麻烦，因为有时候可能会发现某个问题存在多个根源。不过，最终是某个特定的东西触发了“雪崩”，从而成为了性能问题。

有些人喜欢逐个处理性能问题，因为系统问题经常是分布在不同的时间，而并没有注意到某个问题在整个组织中不断重复出现。如果某个问题真的只是一次性的问题，则此方法是可以接受的。但实际上可能出现不断反复的更大问题。

从系统的角度而言，务必要在几乎每次发现设计出现性能问题时找出问题的真正根源。否则，您将不断地处理其表现症状，但问题却永远得不到解决。这将浪费本来可处理其他事情的很多时间和资源。不过，请注意，我说的是“几乎每次”。组织在大多数情况下都没有无限的资源可用，因此合理使用这些资源是非常必要的。在标识和消除性能问题根源的过程中，询问自己这些问题：

• 在哪些情况下需要立即进行根源分析？
• 哪些情况可以在不进行根源分析的前提下以可接受的方式加以处理？
• 消除这些根源的最终成本是否比继续对表现症状进行管理的成本低？
• 应该建立或使用哪些流程来确定根源？
• 信息是可操作数据还是原始数据？

这些问题非常重要，因为它们可帮助您在出现问题时进行管理。例如，如果某个系统问题导致无法获得支付款项，这可能对任何组织都是个大问题。显然，必须要确定问题的根源并快速予以解决。但如果出现的问题导致员工必须手动将信息输入到系统中，而不能使用自动工作流进行此工作，又如何呢？组织仍然可以继续正常的工作，因此这个特定的性能问题不需要根源分析——或者在完成根源分析前不能无限期地等待。

确定根源的工作可能很简单，也可能极为复杂。任何问题都存在差异，而这经常使得根源分析有些像猫捉老鼠。甚至在发现问题之前，您可能需要在多个部门（还可能涉及到多个提供商）之间进行协调。不断问“为什么”，直到找到问题的根源为止。模式完整且不能再问“为什么”的时候，通常就找到了根源。

工具和技术：确定解决选项

因为您了解问题并不意味着可以按照自己所想的方式解决问题。根据性能问题的实际根源，您的解决方法选项可能比较有限，也可能有多项选择。预算考虑（例如仅仅因为资源不可用）可能会让制定的解决方法计划泡汤。如果您要处理访问级别协议，可能会发现需要服务提供者的帮忙才能解决问题。此外，根源有时候可能是无法处理的。例如，有可能是软件内固有的问题。因此，发现根源时，需要确定能够用于管理此问题的一系列解决方法选项。

任何时候进行问题确定时，管理层都希望知道所有可用的选项。向他们提供信息时，不要犯仅仅列出选项的错误。相反，应该列出每个解决方法选项的优缺点。以下是一个例子：

问题：在客户来电订购部件时，销售代表不再能自动检索即时客户详细信息了。

解决方法 A：销售代表可以使用不同的流程在两分钟内手动检索客户详细信息。

解决方法 B：可以实现修复程序来恢复自动检索，成本为 50,000 美元。

从表面来看，解决方法 A 似乎是个合理的解决方案，对吗？只需要两分钟，然后销售工作就恢复正常了。在考虑预算的环境中，这可能比解决方法 B 更好。不过，如果您拥有 300 位销售代表，每位代表每个小时平均处理 4 位客户，这额外的两分钟就意味着每月要损失 9,600 个小时的生产力和销售时间。9,600 个小时！将此值乘以平均小时工资（仅按每小时 8 美元算），您会突然发现让销售代表持续进行手工检索，会每月 浪费您组织超过 75,000 美元的资金。

突然之间解决方法 B 开始变得非常经济合理了，对不对？不过，您的管理层可能不会立即认识到这一点。如果您简单地列出前面提到的选项，他们可能永远不会认识到采用乍看之下最合理的选项可能会浪费多少资金。您需要负责帮助他们了解所给出的每个解决方法选项的全部影响。

工具和技术：权衡需求

在处理性能管理问题时，最好使用需求管理技术来帮助确定问题对业务的影响。对问题影响的所有区域的需求进行权衡并不容易，但应该进行此工作，以确保解决方案对每个人都有效。例如，采用满足业务需求但却绕开了用户需求的解决方法并不一定很好。

为准确起见，每次对性能问题进行管理时，都应该考虑以下需求领域：

• 用户需求
• 业务需求
• 功能需求
• 非功能需求
• 流程需求

在解决问题时，不要尝试避开其中任何一个领域。如果忽略了其中的某个方面，您会发现某一类需求突然超越了其他需求，而这会在以后带来更多的麻烦。在对所有这些需求进行权衡时，您的沟通技能又要扮演很重要的角色了。例如，您需要帮助业务部门了解为何不能忽略用户需求，或者可能需要帮助管理层了解为何不能在考虑功能需求时忽略流程需求。

在组件级别，问题管理需要更为精细的权衡。您可能希望使用 IBM® WebSphere® 之类的软件帮助您监视组件级别的性能，以全面了解设计中的应用程序的工作情况。此类软件还允许您深入各个粒度级别，以帮助将问题分离出来。

从业务角度而言，任何性能管理问题都必须与业务管理实践保持一致。这意味着，如果要实现设计的最佳性能，必须将信息技术 (IT) 目标与组织的目标保持一致。如果必须遵循一系列命令，则按照其执行——但要记录何时通知了哪些人以及所得到的回应是什么。在考虑业务一致性的情况下确定所有解决方法，不要害怕让上级管理人员知道为何您的解决方案可全面解决业务问题。

工具和技术：管理问题

如果在根源分析期间确定某个应用程序需要退役，或需要对其进行更改，请考虑集中管理或分布式管理技术是否可以解决问题。这两个方法都有效，但如果您发现采用集中管理能更好地处理根源，请毫不犹豫地和您的高层管理人员谈谈这个想法。组织趋向于相信某个方法比另一个方法好，但在很多情况下两个方法可以同时使用。

这样做还会导致在处理性能问题时突然出现解决方案开发问题。这是因为组件级别的性能解决方法可能会对整个解决方案造成影响。利用这个机会从新的角度审视一下您的设计。实现设计时，可能会非常完美。不过，现在您有机会对其再次进行评估，确定是否可以或应该在实现问题解决方法时一并进行提升。还记得本文前面的示例吗？从预算角度而言，其中的解决方法 B 实际上更为明智。那么，如果您还能在设计中实现另一个小的改进，成本为 20,000 美元，这如何呢？加上原来的 50,000 美元，仍然能为公司节约资金，而且还能够额外带来一些改进。这就提出了反映此概念而且需要进一步发挥沟通技能的解决方法 C。您可以将性能问题变成组织胜利的号角。

里程碑

既然我们已经考虑了性能管理的各个方面，接下来就要看看性能管理工作中涉及的里程碑。虽然这可能会根据组织不同而有所变化，但可将此处所讨论的内容作为良好的开端。

使用关键性能指标

关键性能指标（Key performance indicator，KPI）设计用于帮助组织定义和测定到业务目标的进度。您知道哪些关键性能指标是针对组织的？哪些是针对遇到性能问题的部门的？在任何时候管理性能问题时，获得这些信息都是一个重要里程碑。

每次面对要处理的性能问题时，您的第一个里程碑应该为获得和了解这些指标。没有这些指标，就无法清楚地确定所面临的情况的影响广度。当然，组织的商业网站崩溃是个大问题。但通过使用关键性能指标，可以了解这个问题对组织的哪些领域有多大意义，从而快速确定崩溃的站点对哪里造成的问题最多。通过此方法，可以得到合适的解决方案，首先处理这些受到极大影响的区域，然后处理受到影响较小的区域。

创建报告

在本文前面，我建议在性能问题出现前制定沟通计划。作为危机期间的里程碑，您需要快速向管理层和受到影响的人员报告问题。这几乎与解决问题本身一样重要。如果组织中没有其他人知道发生了什么事，害怕、恐慌和愤怒很快就会蔓延开来。问题一出现，就发出标准报告，以便其他人能够了解目前已经发现了什么问题并在进行处理。

在报告中，请确保至少列出以下事项：

• 问题描述
• 问题解决方法
• 业务影响
• 根本原因
• 预防性措施

不要让报告 这个术语难倒你。例如，如果喜欢，可以将此报告制作为一个简单的演示文档幻灯片，其中将前述项目作为主要项目列出。但无论使用何种格式，都需要向相关方提供所需信息。如果无需不断回答关于所进行的工作以及何时能修复的问题，您就有更多时间来解决问题。

总结

在本文中，我们了解了如何计划和实现性能管理技术，以保持设计平稳地运行。从很多方面而言，应用程序架构师的工作永远也不会结束，因此可以将性能管理问题视为带着伪装的机会。有时候这些问题可能会让您烦心或感到挫败，但就长远来看，从中得到的经验教训可帮助您更好地进行自己的工作。

参考资料

学习

• 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
  
  
• 参考 “应用程序架构本质”系列的其他部分。
  
  
• 订阅 “应用程序架构本质”系列的 RSS，以获取本系列更新的信息。
  
  
• 查看 MustGather: Read first for all WebSphere Application Server Products，以获得关于 MustGather 可如何帮助进行问题确定工作和节约分析问题管理记录所需的时间。
  
  
• 阅读“用 DB2 Performance Expert 简化性能管理和调优: 如何快速排除问题和调优 DB2 UDB 服务器”（developerWorks，2004 年 11 月），以了解如何将 DB2 Performance Expert 用于进行监视、分析和优化工作。
  
  
• 阅读 IBM 红皮书®摘要： “Business performance management meets business intelligence”，了解如何采用全面的方法管理业务性能和实现业务目标。
  
  
• 在 developerWorks 的 Architecture 架构专区中，获取用以提高您在体系结构方面的技能的各种资源。
  
  
• 浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。
  
  
• 查看 IBM On Demand 演示程序，以了解有关 IBM 各种软件产品和技术的更详细的信息。
  
  
• 了解关于 developerWorks 技术事件和网络广播的最新消息。