现在是星期一傍晚，您的应用程序终于将投入生产。经过一年的开发和几个月的QA之后，它将成为星期二早上最新的新闻。接下来的几天是客户与新的应用程序第一次交互的关键时期。
　　您可能认为开发人员可以拿到佣金，甚至开始新的开发，但这只是一个美好想法，并且不可能发生。预料不到的性能下降和错误可能会出现，而应用程序支持人员无法独立地解决这些问题。
　　J2EE应用程序的生产管理立刻变得混乱不堪。有一些公司有经验丰富的WebLogic管理员或者专业的应用程序支持人员。但许多公司没有这样的人，生产管理由普通IT应用程序支持人员和开发人员共同负责（开发人员通常有更丰富的J2EE经验，所以他们承担的更多）。这不是一种有效的或者高效率的生产管理策略。公司需要增加应用程序支持人员的专业知识，以便他们不需要开发人员的帮助，就可以处理最简单的生产问题。

生产之前的性能保证
　　作为开发人员，为了确保您的应用程序在生产中很好地运行，您要做您所能做的所有工作。在开发过程中，当设计和实现应用程序的功能时，还要考虑性能目标。在每一个项目中，时间和资源都是一项挑战。尽管在开发和QA过程中，功能测试通常先于性能测试，但也不应该忽视在这一阶段发现性能问题的好处。为性能测试分配时间和资源，可以换来故障时间的减少、维护客户的忠诚。在生产之前，每一项开发和测试计划都应该确定必须满足的性能标准。
　　但是，在实验室中分析应用程序的性能与反复检测它、将它用于实际用户负载有所不同。在实验室中，通常没有那么多资源进行真正全面的压力测试，因此您只能在少数处理模拟用户负载的机器上测试应用程序。这有助于确定需要注意的事务性瓶颈和系统级瓶颈，并有助于在应用程序过载或者无法访问系统的某些部分时，设计应用程序的行为。例如，如果某一数据源不能用（产生某种类型的“Error 500”），那么您可以通知用户某一块数据无法使用，并允许他们继续处理其他问题，而不是立即停机。
　　然而在开发和QA过程中，性能测试尽管重要，但它不可能解决每一个有关的性能问题。在生产中，应用程序将经受可能没有预料到的负载和使用模式的考验。应用程序支持小组必须随时准备处理突发事件。

缺乏专业知识
　　一旦应用程序投入生产，通常应该是将管理应用程序的责任转交给WebLogic管理员或者IT应用程序支持人员。不幸的是，许多公司没有经验丰富的BEA WebLogic Server管理员，因此不得不要求开发人员暂时弥补这个空缺。
　　仔细想想，出现这种专业技能空缺是很合乎逻辑的。在新业务应用程序平台发行初期，的确是开发人员拥有使用它的最丰富的经验。只有生产了许多应用程序之后，应用程序支持人员才有足够的经历来积累自己的专业知识。
　　应用程序支持小组有两个目标：一个目标是根据既定的服务水平确保应用程序的可用性得以维护；另一个目标是根据业务的需求，为应用程序将来的持续可用性制定计划。在此，我们将注意力放在第一个目标上，但我们应该知道，容量规划是将来的一个活跃份子，它要求专业应用程序支持小组必须掌握专业知识。
　　支持小组必需快速增加自己的专业知识，并肩负起适当处理当前的危机的重任。支持小组需要掌握的专业知识与应用程序开发人员必须掌握的专业知识完全不同，开发人员所需要的专业知识更多是关于调优应用服务器环境、了解J2EE的资源相关性以及配置应用服务器方面的。

过渡到生产环境的策略
　　开发人员可以被动地等待被拖去解决一些很小的性能问题，也可以在帮助应用程序支持小组学习维护应用程序可用性知识方面起着积极的作用。所需要的支持的数量随小组的规模、结构以及小组期望诊断问题的深度的不同而有所变化。随着WebLogic管理人员获得的经验和专业知识的增加，他们迟早会成为调优应用程序、使其在生产过程中运行得尽可能的好的专家。
　　作为向生产转化的一部分，开发小组应该制定描述应用程序高级功能和相关性的支持文档，如果您愿意，可以从系统管理的角度概述应用程序。这一起始点甚至可以为没有经验的支持人员开始学习应用程序提供了一个切入点。应该用文档记录应用程序的每一层以及外部相关性方面的信息，其中包括关键错误日志消息的一个列表。
　　尽管代码只驻留在BEA WebLogic Server上，但其他许多服务器也向应用程序提供数据和功能。支持文档应该概述所有Web服务器、其他开发小组之外开发的组件，以及应用程序用于数据和客户身份验证的所有后端数据库。描述数据源以及系统与外部数据源使用的通信类型的示意图非常有用。对J2EE环境中所有移动部分进行很好地描述，这将有助于很快地提高开发小组获得专业知识的速度。
　　为了确保环境的稳定，WebLogic管理员应该监控生产过程中对WebLogic Server进行的所有应用程序和配置方面的更改。为了准备成为管理服务器的WebLogic管理员，开发人员应该更新支持文档，提供每台服务器上必需部署的应用程序的列表、期望的响应时间，以及服务器和应用程序的热点瓶颈、潜在瓶颈的列表。
　　一旦这些都已明确，应用程序支持小组必需明白所有这一切是如何实际发挥其作用的。这是一个工具擅长的领域。

通知和培训工具
　　作为开发人员，有许多可利用的工具能够帮助您创建和测试一个大型应用程序。这些工具包括诸如编辑器、调试器、源代码控制工具等之类的基本工具，以及一些提高生产率，使您将工作做得更好的工具，例如分析器、内存调试器和自动测试工具等。应用程序支持小组需要自己的专业工具来配置、监控和诊断生产过程中应用程序出现的问题。理想的情况是，这样的工具不仅能实现更有效的管理，而且可以培养和帮助开发人员增长其专业知识。
　　现有的工具各式各样，从24x7应用程序监控方面的工具，到解决代码和数据库问题的深层问题诊断工具。但在帮助应用程序支持小组增加其J2EE专业知识方面，一个比较好的起点是WebLogic Server管理领域。
　　BEA WebLogic Server集群实际上是应用程序的前门。它运行代码、集中控制对后端数据库的访问、管理和协调对系统共享资源的使用。为了帮助管理WebLogic Server，应用程序支持应该选择在组织良好的实时界面中显示信息的工具、突出显示故障区的工具，以及提供洞察产生问题的原因的工具（参见图1）。

　　提供某一域的概述的工具可以分析出性能问题是特定于某一台服务器的，还是整个服务器集群所共有的。根据每台WebLogic Server、每个集群以及每个部署好的应用程序的状态，管理员可以很快确定未达到性能要求的范围。最初的筛选可以使WebLogic管理员可以很快地找到问题所在，并提供这种情况会对客户产生什么样的影响的初步概念。
　　信息的表达是缺乏经验的管理员能够确定其J2EE系统是否处于健康状态的关键因素。在WebLogic Server内，有数百种度量标准可以使用，每一个标准都用来解决某一部分的性能难题。单个的度量标准没什么用，但当您能够形象化它们之间的关系时，一幅活生生的性能图就呈现在眼前，您可以从中判断问题的所在。像BEA WebLogic Console 和命令行界面之类的工具就很好，它们允许您浏览这些度量标准。如果您知道问题所在，甚至可以帮助WebLogic专家找到这些问题。然而，尽管大多数WebLogic管理员依靠控制台来更改服务器的配置，但他们通常需要更直观的工具，来帮助他们找出实际需要调整的配置参数。
　　使WebLogic管理员尽快熟悉WebLogic Application Server内部情况的最好方法是向他们提供实时性能视图。如果能够了解应用程序与WebLogic Server是如何交互的，那么学习应用程序和找出性能问题会更容易一些。当客户通信量发生变化时，观察资源的使用随WebLogic组件之间的进程流（process flow）波动情况是一种非常有效的培训方式。一旦将形象化的警告信息添加到性能画上，WebLogic管理员就能够检测和判断许多问题，而不需要再叫开发人员来帮忙。形象化的警告信息应该突出显示瓶颈，并指出管理员应该更进一步地钻研应用程序或WebLogic的哪一部分。一幅性能图胜过千言万语，而实时性能图将节约大量的研究时间。

　　查看应用服务器管理工具的另一项有用功能是提供内部专家建议。这一信息允许WebLogic管理员对有关问题及其解决方案做出明智的决定。在管理员采取正确措施之前，可能仍然需要与开发小组协商，但是，可以使用与上下文相关的建议加速应用程序支持小组的内部决策过程。正确的诊断工具是您成为经验丰富的WebLogic管理员或是管理J2EE应用程序的新手的关键，综合的专家意见将增强经验丰富的人员的自信，并可以将一些任务转交给初级人员来完成。

结束语
　　在生产过程中运行J2EE应用程序需要一些专业知识，然而这些知识还不能广泛获得。此时，开发人员是最有资格诊断性能和可伸缩性问题的人，但他们不是生产过程中的灭火队，他们应该集中精力帮助应用程序支持人员掌握管理其应用程序所必需的专业知识。
　　简单的应用程序文档是帮助支持小组维护生产过程中的应用程序可用性的策略之一。并且对于将来容量使用规划而言，从生产应用程序中收集经验数据是必需的。至于日常管理（和培训），实时性能查看工具是一个理想工具，它可以显示操作中正在运行的应用程序，并帮助收集数据，以便进行容量规划。

关于作者
Hugh Docherty是Quest Software的J2EE性能管理解决方案的产品经理。Hugh在管理基于Web的金融应用程序的开发方面有着丰富的经验，另外，在构建和支持Web应用程序方面也有十多年的经验（更多）。

原文出处
http://www.sys-con.com/story/?storyid=43031&DE=1