3. 所有角色齐心协力

一个重要挑战是J2EE应用的复杂性在不断增加。尽管它们可以反映三层的应用架构，但是负载均衡，大量依赖关系，来自外部的影响和外部用户等方面的复杂性是公司以前从未遇到过的。在这种环境里，故障或应用的问题几乎从来不是线形的，也就是说在原因和结果之间很少有单一的路径。识别问题不象识别单一的因果关系那么简单。所以，这需要快速遍历复杂的可能性树并在无数可能的原因中找出真正的原因。

线性的： 一个由于没有正确释放锁而执行缓慢的方法会减慢响应时间，因此在一定负载的情况下应用会慢下来。由于这是很好理解的关系，所以原因和结果是清楚的。

非线性的 事务处理的响应时间很慢。碰巧一些方法的执行也变慢了，这就有很多可能的原因。前一天修改了一些代码，影响到了与这个事务有关的一些组件。另外，网络也时而慢下来。机构面对的原因可能是复杂的，可能是多个方法相互关联的问题或网络的问题，诊断将不会是单一线性的。

协调适当的角色克服这种复杂性的能力将是公司获得成功的关键。一旦建立这样的机构，公司必须转换他们的关注点，以确保角色之间能够共同合作。确保合作意味着将工作集中在过程定义，共享工具和共享运营数据等方面。

3.1. 过程

为保证很多不同的角色像一个默契的管弦乐队一样一起工作，他们就必须都遵照相同的过程规范。

重要的是所有的过程都应该从对最终用户影响的视点出发。无论关系到评估影响，识别问题的的重要性，了解测试的负载程度，还是推定适当的响应时间，出发点必须是"用户需要什么？"。

支持J2EE应用的关键过程包括:

故障的识别，报告和转交：这个过程包括对警报进行识别，确认存在的问题，并确定在机构中如何将问题转交下去。最初的警报将转给运营或应用支持。公司不应该简单地给这些小组一个简单的通知单(即，单子上写着"如果A警报发生就通知管理员B")；他们应该让这些小组使用初始的诊断工具以便更深入地识别问题，同时应该开始搜集信息，并将信息转交给能最终解决问题的小组。其他小组使用他们自己的工具（例如网络管理工具），应该时刻保证与应用和运营支持小组共同保证他们数据是同步一致的，同时避免为一个简单的故障安排过多的人手。META Group观察到很多这样的情形，多个人员响应同一个故障，每个人都使用他们自己工具中的数据，独立作战。他们不仅在重复劳动，浪费公司的时间，而且存在着干涉他人工作的风险，因此拖延了故障的时间。这就是为什么以对最终用户的影响为优先并从清晰的问题识别和故障转交为出发点的重要性原因。

分析/解决问题/根本原因: 一旦一个队伍负责处理一个故障，那么这个过程就是对一系列检查点的简单遍历，从而隔离出故障的可能发生位置。当识别出一个简短列表时，就从最可能的项目开始逐一排查。然而，确定可能的原因和影响并不容易。这就是在解决问题过程中需要工具的地方。故障处理小组从运营小组得到的数据越多，他们越能更快地做出评估，确定如何恢复服务，识别根本原因并做出修正。另外，这些队伍应该有一个装有诊断工具的工具箱以便让他们做更深的分析。最后，应该寻找能够快速隔离可能原因的工具。

这一过程应该考虑到角色之间能够直接的问题转交。这应该包括运营角色或者应用所有者角色将问题转交给J2EE管理员的能力，然后是J2EE管理员转给质量保证小组做更深入的诊断的能力，或者将问题直接转给开发角色的能力。一个小组将问题转给另外一个小组不应该受到惩罚。这种协作必须成为正常的程序。如果用户受到了很大影响，那么这些小组甚至可以同时协调共同参与解决故障。

改变管理/生产接受：现在更新应用系统，改变应用管理，对应用和相关技术的影响性分析（例如如果计划对服务器做变动，需要分析其对应用的影响）等都已成为日常工作。在以前的管理中，这一过程在各个小组之间有很大空白。简单地说，开发角色开发完之后，将工作转给质量保证经理。质量保证小组完成工作之后又转给生产接受角色。然后生产接受小组拿到应用后会发现大量无法接受的地方，就开始和质量保证和开发小组协商进行一些完善。在快速前进的J2EE应用环境中，在各个小组的通力配合下，必须更快地执行整个过程。由于每个小组都需要扮演运营支持的角色，所以不能将应用转给其他组。公司必须规定一个过程，在这过程中必须包含转交技术的小组的参与（例如质量保证小组应参与生产环节），同时当转交技术时，还应包含那些可促进下一步工作效率的信息知识 (例如一些脚本（scripts），众所周知的阈值等级)。

性能调整：这是一个通过调整应用及其组件从而保证所有组件处于最佳运营状态的过程。这一过程从开发人员确保编写的代码正确运行开始，涉及到下面角色：
- 质量保证小组角色：保证可以处理正确的负载程度和提供希望性能的生产配置。
- J2EE管理员角色：保证Web应用处于最佳良好状态
- 应用所有者角色：保证最终用户的体验-体现所有小组的所有改进工作--达到或超出期望。

性能调整是一个主动性步骤，不管有没有故障，公司都应该把性能调整作为经常性工作。经常性的性能调整可以防止应用耗费资源和运行变慢。

3.2. 工具

传统上，购买工具不仅从技术的分类角度考虑也从机构组织的分类角度考虑。这导致在J2EE世界中的每个角色针对他们的具体工作都有自己的工具。虽然我们知道每个人在其领域中对工具都有特殊的需要（例如开发工具与生产监控工具的需求是不同的），但是如果在这些工具能够有联接，那是很有好处的。一个关键的联接是在数据层次上的集成，这使得信息可以在工具间流动，使每个工具比单独使用时更具智能。

在J2EE环境中，我们特别看到开发小组购买自己的运营工具并不只是为开发人员提供帮助（例如调试工具）。在开发工具和生产工具之间通常是有关联的。这些工具也被用来与质量管理小组共享来加快他们的工作。所以开发和质量保证小组能够共享这些已经采用的工具以及他们的使用知识和与生产小组（例如运营、应用支持，J2EE管理员等）共同使用的脚本等，从而缩短时间，提高这些小组的工作效率。一个附带的好处是大家都使用相同的数据工作。当每个小组都熟悉这些相同的基本工具时（在不同层面有不同用途），这些数据就成为可信的信息来源，每个人都可以使用做决策。这可以减少小组之间的指责，减少不同小组之间的分歧并可以帮助整个协作过程。

工具带来的另一个价值是加快了问题的识别，从而加快了解决问题的过程。这是处理上面提到的非线形故障的一种办法。由于这些故障需要大量的调查分析，所以解决这些故障需要付出巨大的努力。公司应该寻找一些工具，这些工具能够识别所有当前的问题点，可能的原因或影响最大的问题，而不是只是提供简单的线形的，因果关系的功能。 虽然很少能识别出唯一的问题根本原因，但是通常能够提出应该调查的一些因素和应该进行进一步调查的一些可能原因。这将防止公司进行漫长费力的问题识别工作，其典型的做法是对应用基础结构和软件一步一步地进行逻辑检查。

4. 成熟中的机构组织

成功的机构组织将看到他们的运营能力从单纯的反应型状态到适应型状态的成熟过程。这种成熟性对于降低支持成本和减少失败风险是非常重要的。为了保证这种成熟，公司必须了解和测量他们的成熟程度，成熟程度可分为反应型，管理型，主动型和最终的适应型。

4.1. 反应型

反应型阶段是运营一个机构组织最没效率的方式。其特点体现在：几乎没有管理过程，在应用的生命周期中各个角色几乎没有协作，使用一些不相关的工具。

不幸的是这是大部分机构组织的状态。我们给处于反应型环境下的公司的唯一建议就是：现在应该将工作重点集中到应用支持上并且努力成为一个管理型环境。

4.2. 管理型

管理型环境是指当故障发生时，有清楚的确认真正问题，识别原因和负责人，和修正故障的过程。机构不会陷入混乱，相互指责或各自为战中，每个小组都愿意协作。管理型环境的一个特点是在相关的小组之间共享数据，通常使用相同的或可集成的工具。当然管理型环境有程度之分，一些已经是完全管理的，而其他是正在快速成熟的（例如每个小组中使用还没有集成的工具）。

管理型环境将如下一些关键的特点

各个小组与数据相结合，而不只是对数据作出反应: 一个警报引发全部恐慌的阶段正在过去，现在的警报提示着需要做更多的分析，验证和汇集另外的智能，并且开始问题的识别过程。此外，数据被用来决定如何解决问题，而不是被用来指责其他小组。这需要一种"我们的问题"而不是"别人的问题"的文化。

在机构组织中有明晰的技术关系，使得能够快速评估影响：这可使公司进行基本的根本原因分析。当存在简单的因果关系时，根本原因分析有用的。但是由于不能扩展到包含所有可能结果，所以对于复杂多维度问题的作用是有限的。因此公司需要了解复杂的Web技术和业务关系，这可使他们看到问题扩散的多条路径以及在IT机构和业务中的影响。对这些关系了解的越多，会发现他们的关系越多，组织机构也就越强壮。

必须清晰理解下面内容：
- 应用的最终用户：哪些应用或服务影响哪些用户群体？在特定应用或服务上，一些改变或问题对业务有何影响？
- 要素关系(例如服务器，数据库) ：现在有哪些要素，它们是如何联系的？哪个Web应用服务器运行在哪个物理服务器上？Web应用服务器和哪个数据库相联并且数据库运行在哪个物理服务器上?
- 组件关系(例如类，方法) 哪个类被哪个EJB调用?哪个方法是哪个servlet的一部分？在整个J2EE的应用中，所有的组件关系是什么？

发生问题时的自动化数据收集： 当无论是个人还是工具发出问题信号时，管理型环境有能力开始收集更多的详细信息。最好的情况是工具在达到某个阈值时触发并自动开始搜集其他与该阈值有关的数据。然后该工具通知相关人员（例如应用支持或工程层次的小组）。当这些人员处理问题时，他们已经获得了大量信息，这样识别和解决问题的第一步就完成了。

问题识别过程：由于一个阈值往往只是问题的征兆而不是问题的本身，所以问题的识别远远不只是阈值的触发。这一过程从较高层次开始确定问题发生在应用的哪个部分（例如应用服务器，Web服务器，数据库等），然后让工程小组对已经识别出的问题组件进行数据研究并更深入地进行分析（例如识别问题出在哪个EJB中，进一步是问题出在这个EJB的哪个方法中。如果这时原因已经清楚了，那么工程小组可以解决这个问题或者转给其他必须提供帮助的小组（例如开发小组）。如果问题依旧没有识别出来，工程小组可以调动其他能够提供帮助的小组。这一过程包含所有工作，需要在相关的所有小组中共享工作流和共享数据。基于最终用户的交互数据（用户响应）可以帮助加快识别问题的过程，可以分析最终用户的事务，识别在事务流中问题出现在哪里。这使得能够迅速集中资源并快速解决问题。

4.3. 主动型

主动型阶段不只是一项特殊技术，而是一个理念体系，在应用和服务的生命周期中，主动型公司认为应用管理非常重要。这些机构在建设应用时，将形成清晰的管理数据并且经过严格的开发单元测试和定义明确的质量保证过程，并且这工程是持续的。开发人员和质量保证小组经常检查应用并重新确认已做的改变，以确保应用可以按照预先的设计运行。

在主动型环境中，生产小组需要定期对应用和基础结构做调整。例如调整J2EE应用服务器保证达到最佳的吞吐量。另外，对运营的度量应该与设计的目标进行比较（假设，当然，那些目标应该已经是确定的）。所有这些说明了在基于J2EE应用支持中，主动型环境中的所有角色是通过数据和技术的共享方式进行交互。

主动型技术也是存在的，这种技术采用工具查看各种数据并寻找异常情况，一些异常情况不只是单一度量的阈值。例如，当线程数量超过了指定的数量或者CPU时间超过了一个使用率时，达到阈值。当一个工具提供主动性方式时，该工具可以推断一些度量间的关系。例如，CPU可以达到60%使用率，是在正常运行范围内，但是JVM线程数量增长的比平时快，同时一些EJB存在不同寻常的大量实例。虽然这些度量中没有一个可以产生警报，但是他们的组合可以表明存在问题。如果线程继续产生，导致某个特定的EJB异常退出（特点是大量的重新初始化）或从另外一个服务中以一新方式调用， 那么CPU开始达到峰值，用户就感觉应用变慢了。主动型方式是可以达到的，只需要同时运用工具和用户的智能两种资源。

最后，主动型环境可以使用运营状态下的历史数据，从中寻找改进的机会。这可能包括调整应用，重新设计应用的某些特殊部分，或主要改变基础结构等。无论结果是什么，都是在问题发生前，通过使用历史数据来改进性能。

4.4. 适应型

适应型管理是大多数机构组织的梦想。如果一个环境是适应型的，那么技术本身可以识别问题并自动地改正问题。公司有很大的灵活性根据当前情况来调配资源。发生的问题不一定是故障，但是反映了使用的趋势。例如当应用的使用增加时，系统自动为了防止出现瓶颈自动提供额外的资源。当然系统会向所有小组发出通知让他们知道系统已经做了哪些工作。系统为了防止问题再次发生已经根据规则自己采取了行动。另外一个例子是当达到峰值时，系统将自动将资源提供给业务更关键的应用。

实际上，IT距离适应型系统还有很多年时间，但是这最终必将成为现实。为作好准备，公司必须在建设可管理的应用（例如在自己开发的应用中采用JMX）方面开始进行投入，这些应用可以对外提供关键的运营数据。此外，公司还必须准备好清晰的运营过程并且在管理技术方面形成规范，以及在适应型系统中形成自动化。如果公司在适应型系统上投入并能够成功实现，他们将看到在运营支持机构中可减少大量成本，需要很少的支持人员并能防止问题和资源耗费的出现。

5. 总结

还有很多工作要做。基于J2EE应用的重要性要求公司采取比过去更快的行动达到J2EE应用的运营成熟程度。公司必须组建所有涉及到运营的支持角色，明确详细责任并运用过程将不同的小组联系起来。一个跨越小组的共享技术基础将帮助公司加快工作过程并使各个小组的工作更加紧密。