管理J2EE的世界（上/ 下）

         

  本文描述了现有J2EE应用运营环境中所遇到的问题，提出了再造组织结构，重新分工的全新可操作性方法，以便更有效地发挥J2EE的优势，管理J2EE应用。本文适合负责企业J2EE应用的开发，运营和维护人员阅读

 

1. 介绍

 

        管理技术需要经验。无论是在飞机、发电厂，还是在从事计算和相关应用的公司中，运营中的所有技术必须被管理起来。一旦引入新技术，在具备运营能力之前，我们需要克服其学习曲线。很多机构一直在努力做到如何能够始终如一地采用新技术并形成所需的运营专门技术。特别对于IT机构来说，采用新技术的能力使得成功的公司从那些采用新技术失败的公司中脱颖而出。

        当IT机构采用每项新技术时，我们会遇到不断增长的复杂性。因此，随之出现更多的运营挑战。达到运营能力所需的时间因技术而不同。一些引入的新技术与现有环境非常相似（例如 Linux与Unix的运营支持结构），因此对机构来说达到运营能力只需很少的时间。而其它技术出现时，由于缺少参考模型，这就强迫公司在使用中进行学习并在没有足够运营能力的情况下采用新技术。缺乏运营能力增加了失败的可能性。J2EE技术给机构带来的就是这种挑战。

 

1.1. 当前的环境

 

        J2EE是新技术，在工作中很少或者没有运营参考模型可供使用。J2EE环境具有很多其他技术的特点，例如数据库，面向消息的中间件，和COTS（Commercial-off-the-shelf成熟的商业化） 应用，但这些环境中没有一项可通过直接拷贝进行扩展的方式就可适用。参考模型的缺乏导致需要投入特殊的支持，从而增加了失败的风险和支持成本，减慢了对失败的响应，并且在一些环境中，限制了这种高度灵活性技术的广泛使用。

        影响IT团队采用J2EE技术的因素是：

 

• 预算/成本：公司必须找到在机构中降低成本的办法，或者通过采用基于J2EE的应用，或者销减IT的直接成本（例如减少支持成本）。

   

   

• 缺乏支持J2EE技术的运营能力：机构缺少支持生产环境的必要技能和必要运营流程，因而减缓了采用J2EE的投入。

   

   

• 已经强化的J2EE应用的重要性：公司正在使用基于J2EE的业务关键性应用---直接面对外部客户或直接连接到关键的合作伙伴或供应商，并因此降低了业务成本----并且J2EE技术控制着更大的可能性。有了这些益处，失败将是不能容忍的。

   

          以前，从开始采用一种新技术到开始正式管理，一个公司需要一到两年的时间，而达到运营能力的水平则需要五年或五年以上时间。通过了解最成熟的计算环境，大型主机系统，我们可以看到达到了工业级的运营能力经历了15-20年时间。但是对于J2EE环境，由于上文提到的应用重要性和潜在的成本降低，管理的滞后被证实是有问题的是不可接受的。

          这种滞后的一个原因是管理是典型的在事后才会被考虑到的。公司集中在应用的所有特性和功能方面，但是还没有计划到运营支持。然而由于上面讨论到的业务关键性特点，在应用系统生命周期中的早期，很多机构正在密切关注对J2EE环境的管理。

          METAGroup建议机构通过协调的工作在机构之间建立运营能力，并在基于J2EE应用的生命周期的早期投入管理能力。这种能力必须涉及广泛的IT机构并必须包括具有清晰轮廓的支持过程。从其应用的开始到生命周期的结束通过理解运营的需要，公司必须重视J2EE的生命周期，否则风险将使得应用的工作付之东流。如果竭尽全力，运营能力有望在短短的一年内达到。

   

  2. 支持J2EE环境的几种角色

   

          很多参与者越过IT机构以某些方式合作支持生产性的J2EE环境。虽然已经有一些现有的角色，但是其他的角色正在刚刚出现。由于当前运营支持的不成熟，在前面还将有更多的变化。下面我们将回顾一下支持基于J2EE技术所需要的关键角色以及在运营支持时每种角色的责任。

   

  2.1. 最终用户角色

   

          虽然在支持J2EE应用中并不真正包括最终用户，但他们是一切的出发点。成功的公司把最终用户视为管理的基础。如果一个问题影响到了最终用户，那是非常严重的。如果有衡量标准，那么衡量标准一定要与最终用户有关;如果有汇报，那么应该从最终用户或对最终用户的影响方面来报告。应该根据对最终用户的性能，可用性，吞吐量，有用性等的潜在影响，来评估改变。不仅对于应用本身而且对于运营支持，最终用户一定都是设计的重点。

   

  2.2. 业务所有者（Business Owner）角色

   

          作为在运行环境中的应用系统的消费者，业务所有者是指其工作与业务的成败紧密相关的人，所以需要引进技术改进业务工作。虽然这种角色的人员不必涉及每天的管理工作，但是如果运营支持出现问题，他们将是第一个被通知到的。他们也是需要定期运营状态报告的人员，这些报告在很多机构中体现为服务等级协议（SLA）的形式。业务所有者必须通过SLA的要求尽量协调各种IT资源。这些要求从与纯技术尺度（如服务器的可用性，网络可用性）相对的角度说明了应用对业务的影响（如最终用户可用性，最终用户吞吐量），业务所有者把对最终用户体验的监控工作置于高优先级。

          META Group 已经观察到了业务所有者的一些变化。在过去，他们主要集中于关心将所有的关键特性和功能都包括在应用中，包括客户要求的各种花哨的东西。然而，当前技术已经跨过了公司的边界，客户，业务合作伙伴和供应商已经成为技术的最终用户，因此现在业务所有者必须关心客户的体验和技术是否能正确地运营。他们经常愿意为了确保拥有一个可支持的应用，而折衷一些应用的特性和功能。这个理论就是一个运行的应用可能缺少一个特性，这可能只困扰一个用户，但是如果应用完全不可用就意味着丢失所有的用户--以及这些用户的所有业务机会。所以性能差的应用比缺少一些特点的应用存在着更大的风险。

   

  2.3. 开发人员角色

   

          在J2EE世界中，开发人员的角色发生了变化。开发者可以不再写代码，通过质量保证小组交付代码并知道某一天会在生产系统中使用。基于J2EE的应用比传统应用的变化要频繁得多--在一些环境中是每天一次(相对于传统的环境，每年才改变一到两次)。因此在开发人员层次上的测试变得至关重要。因为开发人员带来的变化导致更短的QA(质量保证)周期并且在很多情况下，几乎没有生产接受过程（production acceptance process），所以为了确保提供可支持的应用，在开发人员层次上的测试是早期的重要步骤。

          接下来，开发人员一定期望能够更直接地参与到生产支持。目前，当机构安排谁将支持应用和学习必要的技能和知识时，J2EE开发人员就被推到这个生产支持的角色中。在一段时间内，这将使开发人员稍微远离运营的过程放慢了。然而，开发人员不会完全脱离他们过去担当的角色。需要的完善问题将不再是记录在服务台(Help Desk)中的需求，而是放在了下个发布版本的改变中。由于基于J2EE的应用对公司来说变得如此重要，这些问题必须很快地解决。由于体系结构本身允许以更快的速度进行较小的修改和分发，这就比较容易解决上面的问题。

          J2EE应用的一个好处就是底层的应用对象模型更容易了解，这通常是通过应用服务器实现的。应用服务器通过管理接口使这些数据可被监控。这些接口通常是基于JMX(Java Management Extensions)。这意味着在生产层次的监控中有更多可用的数据可以帮助开发人员识别问题。机构必须拥有这种能力并且学会在更低的细节层次(例如类，方法等)上监控生产应用，同时开发人员必须能接受到从生产来的数据。这样，开发人员将看到他们解决问题的时间明显减少了；而不必为了了解问题而再建立一个环境以再现问题。这些数据可以为开发人员指明需要修改的有、问题的类甚至方法。

   

  2.4. 质量保证角色

   

          质量保证角色的变化更加微妙。质量保证组仍然处于开发和生产之间，但现在质量保证过程更多地被拉向生产体系。从两个要点看，质量保证角色将在自己的机构内部细分为两个关键的中心：1)详细的应用测试(蜕变测试，集成测试等);2)参与应用性能测试(例如负载，事务执行等)同时建立测试环境和生产的阶段性代码(staging code)。质量保证中的应用性能要素主要包括J2EE运营小组。由于前面讨论的不断缩短的开发周期，对于生产接受阶段的时间限制越来越大。很多公司在生产系统上执行测试，这样几乎没有生产接受阶段的时间。质量保证者团队必须能够自动测量，同时要能够模仿一个真正的用户环境。另外在质量保证过程中必须有足够的灵活性可以在实际的生产环境进行临时性测试以确定应用是否如所希望的运作。

          质量保证管理人员必须有多种工具，可帮助他们和其他的运营支持小组分享信息。这些信息，例如在特定的负载程度下组件的响应情况，应用中的断点情况，和方法或EJB的正常性能指标等。如果他们都在用于测量和监控的一些工具中共享数据，那么这种共享将变得比较容易。需要理解的是，质量保证的监控工具不是直接使用在生产中;很明显，这些工具增加了系统负载，所以不能在生产环境中使用。然而，可以使生产系统连接到这些工具，这样可共享阈值信息，测量信息和关键点的识别信息等。此外，当在生产中发现问题时，如果从生产系统中不能得到足够多的细节，那么公司应该有能力回到质量保证环境中，再现此问题以便分析和解决。

   

  2.5. 应用所有者角色

   

          在公司里新出现的角色是应用所有者角色。每一个应用都集成了独特的系列技术以满足他们的需求。每个应用都有一群最终用户，他们希望该应用能提供给他们特定的服务。可是，IT在传统上是依据技术划分的，这阻止了从应用视点观察世界的能力，更重要的是阻止了从最终用户的视点观察。不过，这正在产生变化，在公司中应用所有者角色正在出现并发挥作用。应用所有者有责任对应用及其健康运行有高层次的视点。由于应用和最终用户的运营健康情况跟体系结构的健康情况不再有紧密关系，因此一个目标是把它们区分开。例如一个公司采用的是基本的三层J2EE应用(web服务器，web应用服务器，和数据库)并且web服务器和web应用服务器层进行了负载均衡，可以想象一些负载均衡的服务器停机不会影响到应用服务。两个web服务器可能停下来。但不会对最终用户产生影响。这两个服务器体现出了超额的能力。应用所有者的职责是确保对最终用户的监控和交流，从对业务有真正影响的角度看，这种工作在IT机构中应具有优先权。

          应用所有者角色通过一些接口为业务所有者角色提供服务。他们都是业务管理和技术之间的桥梁，并且负责提供业务SLR（服务等级报告）。他们不必自己产生所有服务等级数据而是从所有其它的IT小组获得数据。应用所有者不负责应用的维护。他们与开发的接口是帮助设置优先权，与运营角色一起确保解决问题的正确路径，与QA角色和J2EE管理人员一起协调改变和维护。他们是中心。

          应用所有者角色负责和所有参与J2EE环境支持的各方接口，确保他们一起工作，像一个小组一样来满足最终用户的要求。他们需要一些工具，这些工具不仅可以记录基础结构的健康情况还可以记录实际用户的体验情况。

   

  2.6. J2EE工程机构角色

   

          我们在IT中看到正在出现的一个新角色是J2EE工程师。它是一个web应用服务器和相关技术的所有者，这个人直接负责这些基础技术设施的维护和支持。很像数据库中的DBA（数据库管理）小组，Web应用服务器/J2EE技术相当复杂，以至于需要一个自己的工程小组。J2EE工程师们和DBA共同具有的另外一个特点是比其他运营小组（例如系统工程师，网络管理部门）更接近开发工作。J2EE工程师首先是属于运营支持小组的，但他们也要花费时间和开发人员一起确定最好的运营参数和改变配置信息。虽然他们会知道一点代码的情况，但只参与一些较小的改动而不参与重要的应用错误修改。另外，J2EE工程师小组将在开发人员的帮助下在生产环境中识别问题，这个任务是最近由扮演产品支持角色的开发人员完成的。J2EE工程师会对问题钻研很深。与将2-3级的支持工作交给开发小组不同，工程小组将对那些问题做出评估，如果他们无能为力，就决定把哪些工作交给开发小组。这最终的结果是开发人员可以合理的方式介入到生产系统中，减少了应用小组的支持工作，并最终由于专门的分工而可以更好地运营J2EE应用。

   

  2.7. 运营角色

   

          运营小组以24*7的时间监视IT世界的运营情况。当问题发生时，他们就是一线支持。以前，运营小组识别出问题或事故，并快速地将事故转给合适的应用或者工程小组，往往很少或没有附带事故的上下文情况。然后事故的接受人员必须开始分析并识别这个问题是否在他们的权限范围内或是否可以把这个问题转给其他人。

              对于基于J2EE的应用，诊断时间的长短是非常重要的。因为这些应用直接带来收入，所以公司必须寻找改善平均修复时间的方法。一个关键的方法是把运营角色和应用所有者角色联系起来，为他们提供有关应用是如何运行的更多详细情况。通知运营角色有一个高层次的故障将导致服务停止，然后运营小组将这个问题转给应用支持小组。可以采用自动化工具来触发进行更深入的分析，这样就可以在出问题前预先通知。通过可以进行深入分析的工具，运营小组可以着手搜集更为详细的信息，可为其他人诊断和解决问题提供帮助。

         

• 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应用的运营成熟程度。公司必须组建所有涉及到运营的支持角色，明确详细责任并运用过程将不同的小组联系起来。一个跨越小组的共享技术基础将帮助公司加快工作过程并使各个小组的工作更加紧密。         参考信息： www.metagroup.com,                         http://java.sun.com/j2ee/tools/management/                         http://www.jcp.org/aboutJava/communityprocess/final/jsr077/                         http://www.research.ibm.com/journal/sj/401/kreger.html                         http://javaboutique.internet.com/tutorials/JavaManagementExtensions/                         http://www.theserverside.com

     

•  

                                 文章来自于：（北京铸锐数码科技有限公司 www.InnovateDigital.com）