大家共同学习交流－－－管理J2EE的世界（上）

╃無名草╃

摘要：本文描述了现有J2EE应用运营环境中所遇到的问题，提出了再造组织结构，重新分工的全新可操作性方法，以便更有效地发挥J2EE的优势，管理J2EE应用。本文适合负责企业J2EE应用的开发，运营和维护人员阅读。
, X3 d, ~. d( Y2 R& l: Q& O( @: @$ o
1. 介绍
/ o! a7 R; R3 J! Q* s# r! p0 P
管理技术需要经验。无论是在飞机、发电厂，还是在从事计算和相关应用的公司中，运营中的所有技术必须被管理起来。一旦引入新技术，在具备运营能力之前，我们需要克服其学习曲线。很多机构一直在努力做到如何能够始终如一地采用新技术并形成所需的运营专门技术。特别对于IT机构来说，采用新技术的能力使得成功的公司从那些采用新技术失败的公司中脱颖而出。

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

1 q) }; z/ w# R' JJ2EE是新技术，在工作中很少或者没有运营参考模型可供使用。J2EE环境具有很多其他技术的特点，例如数据库，面向消息的中间件，和COTS（Commercial-off-the-shelf成熟的商业化） 应用，但这些环境中没有一项可通过直接拷贝进行扩展的方式就可适用。参考模型的缺乏导致需要投入特殊的支持，从而增加了失败的风险和支持成本，减慢了对失败的响应，并且在一些环境中，限制了这种高度灵活性技术的广泛使用。
3 K$ R7 y. r, \; A0 m  S
3 c5 N- P% f1 c% E3 ]; H影响IT团队采用J2EE技术的因素是：


. O0 l3 @7 g! N( T( d
预算/成本：公司必须找到在机构中降低成本的办法，或者通过采用基于J2EE的应用，或者销减IT的直接成本（例如减少支持成本）。
. X) E/ W  K$ H# o2 d6 @
缺乏支持J2EE技术的运营能力：机构缺少支持生产环境的必要技能和必要运营流程，因而减缓了采用J2EE的投入。
" X! C' P- G6 x: W8 o
& n/ ]4 B4 A8 k2 c4 X; S已经强化的J2EE应用的重要性：公司正在使用基于J2EE的业务关键性应用---直接面对外部客户或直接连接到关键的合作伙伴或供应商，并因此降低了业务成本----并且J2EE技术控制着更大的可能性。有了这些益处，失败将是不能容忍的。
5 j$ b2 l, ^8 D2 R( |7 ?
3 N2 A( z) ]4 Z4 S) G) ^: P7 G- E以前，从开始采用一种新技术到开始正式管理，一个公司需要一到两年的时间，而达到运营能力的水平则需要五年或五年以上时间。通过了解最成熟的计算环境，大型主机系统，我们可以看到达到了工业级的运营能力经历了15-20年时间。但是对于J2EE环境，由于上文提到的应用重要性和潜在的成本降低，管理的滞后被证实是有问题的是不可接受的。
3 j( m0 p% m% ~! Y8 c
这种滞后的一个原因是管理是典型的在事后才会被考虑到的。公司集中在应用的所有特性和功能方面，但是还没有计划到运营支持。然而由于上面讨论到的业务关键性特点，在应用系统生命周期中的早期，很多机构正在密切关注对J2EE环境的管理。
, f6 m* K' j/ v5 Q% |
- `" E8 N( i; h- V, CMETAGroup建议机构通过协调的工作在机构之间建立运营能力，并在基于J2EE应用的生命周期的早期投入管理能力。这种能力必须涉及广泛的IT机构并必须包括具有清晰轮廓的支持过程。从其应用的开始到生命周期的结束通过理解运营的需要，公司必须重视J2EE的生命周期，否则风险将使得应用的工作付之东流。如果竭尽全力，运营能力有望在短短的一年内达到。

2. 支持J2EE环境的几种角色
! Q0 I) {& J% ~$ M$ V0 t
  o% r) ^# P" l# T" p很多参与者越过IT机构以某些方式合作支持生产性的J2EE环境。虽然已经有一些现有的角色，但是其他的角色正在刚刚出现。由于当前运营支持的不成熟，在前面还将有更多的变化。下面我们将回顾一下支持基于J2EE技术所需要的关键角色以及在运营支持时每种角色的责任。
) k* W/ p$ T; v- L
2.1. 最终用户角色
$ h2 O9 r6 l5 o7 F/ B虽然在支持J2EE应用中并不真正包括最终用户，但他们是一切的出发点。成功的公司把最终用户视为管理的基础。如果一个问题影响到了最终用户，那是非常严重的。如果有衡量标准，那么衡量标准一定要与最终用户有关;如果有汇报，那么应该从最终用户或对最终用户的影响方面来报告。应该根据对最终用户的性能，可用性，吞吐量，有用性等的潜在影响，来评估改变。不仅对于应用本身而且对于运营支持，最终用户一定都是设计的重点。
8 v2 a( j/ g& E9 E- e
+ @+ o( x# i& I9 V1 [5 W2.2. 业务所有者（Business Owner）角色
$ a" u* O# S+ k5 @' s& H+ E1 F$ u作为在运行环境中的应用系统的消费者，业务所有者是指其工作与业务的成败紧密相关的人，所以需要引进技术改进业务工作。虽然这种角色的人员不必涉及每天的管理工作，但是如果运营支持出现问题，他们将是第一个被通知到的。他们也是需要定期运营状态报告的人员，这些报告在很多机构中体现为服务等级协议（SLA）的形式。业务所有者必须通过SLA的要求尽量协调各种IT资源。这些要求从与纯技术尺度（如服务器的可用性，网络可用性）相对的角度说明了应用对业务的影响（如最终用户可用性，最终用户吞吐量），业务所有者把对最终用户体验的监控工作置于高优先级。

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

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

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

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

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

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

2 d4 h* n: e- f$ R- b! F2.5. 应用所有者角色
在公司里新出现的角色是应用所有者角色。每一个应用都集成了独特的系列技术以满足他们的需求。每个应用都有一群最终用户，他们希望该应用能提供给他们特定的服务。可是，IT在传统上是依据技术划分的，这阻止了从应用视点观察世界的能力，更重要的是阻止了从最终用户的视点观察。不过，这正在产生变化，在公司中应用所有者角色正在出现并发挥作用。应用所有者有责任对应用及其健康运行有高层次的视点。由于应用和最终用户的运营健康情况跟体系结构的健康情况不再有紧密关系，因此一个目标是把它们区分开。例如一个公司采用的是基本的三层J2EE应用(web服务器，web应用服务器，和数据库)并且web服务器和web应用服务器层进行了负载均衡，可以想象一些负载均衡的服务器停机不会影响到应用服务。两个web服务器可能停下来。但不会对最终用户产生影响。这两个服务器体现出了超额的能力。应用所有者的职责是确保对最终用户的监控和交流，从对业务有真正影响的角度看，这种工作在IT机构中应具有优先权。
) q3 [, y* o) {: w( I: m
. e9 v4 S: S, R3 Y+ |& Y' Y应用所有者角色通过一些接口为业务所有者角色提供服务。他们都是业务管理和技术之间的桥梁，并且负责提供业务SLR（服务等级报告）。他们不必自己产生所有服务等级数据而是从所有其它的IT小组获得数据。应用所有者不负责应用的维护。他们与开发的接口是帮助设置优先权，与运营角色一起确保解决问题的正确路径，与QA角色和J2EE管理人员一起协调改变和维护。他们是中心。
9 z6 t0 M- g; v" H" b
* i$ Y. i6 w1 {0 P1 E3 q# C/ p应用所有者角色负责和所有参与J2EE环境支持的各方接口，确保他们一起工作，像一个小组一样来满足最终用户的要求。他们需要一些工具，这些工具不仅可以记录基础结构的健康情况还可以记录实际用户的体验情况。
6 J4 ^6 M3 |3 u& w* \( ]2 B
2.6. J2EE工程机构角色
我们在IT中看到正在出现的一个新角色是J2EE工程师。它是一个web应用服务器和相关技术的所有者，这个人直接负责这些基础技术设施的维护和支持。很像数据库中的DBA（数据库管理）小组，Web应用服务器/J2EE技术相当复杂，以至于需要一个自己的工程小组。J2EE工程师们和DBA共同具有的另外一个特点是比其他运营小组（例如系统工程师，网络管理部门）更接近开发工作。J2EE工程师首先是属于运营支持小组的，但他们也要花费时间和开发人员一起确定最好的运营参数和改变配置信息。虽然他们会知道一点代码的情况，但只参与一些较小的改动而不参与重要的应用错误修改。另外，J2EE工程师小组将在开发人员的帮助下在生产环境中识别问题，这个任务是最近由扮演产品支持角色的开发人员完成的。J2EE工程师会对问题钻研很深。与将2-3级的支持工作交给开发小组不同，工程小组将对那些问题做出评估，如果他们无能为力，就决定把哪些工作交给开发小组。这最终的结果是开发人员可以合理的方式介入到生产系统中，减少了应用小组的支持工作，并最终由于专门的分工而可以更好地运营J2EE应用。

2.7. 运营角色
运营小组以24*7的时间监视IT世界的运营情况。当问题发生时，他们就是一线支持。以前，运营小组识别出问题或事故，并快速地将事故转给合适的应用或者工程小组，往往很少或没有附带事故的上下文情况。然后事故的接受人员必须开始分析并识别这个问题是否在他们的权限范围内或是否可以把这个问题转给其他人。
/ I/ L7 R7 ?7 Q2 U% {0 [
% p/ j( h; C7 y6 }& W对于基于J2EE的应用，诊断时间的长短是非常重要的。因为这些应用直接带来收入，所以公司必须寻找改善平均修复时间的方法。一个关键的方法是把运营角色和应用所有者角色联系起来，为他们提供有关应用是如何运行的更多详细情况。通知运营角色有一个高层次的故障将导致服务停止，然后运营小组将这个问题转给应用支持小组。可以采用自动化工具来触发进行更深入的分析，这样就可以在出问题前预先通知。通过可以进行深入分析的工具，运营小组可以着手搜集更为详细的信息，可为其他人诊断和解决问题提供帮助。

Fledgling

好东西，复制下来，呵呵，谢谢楼主