对于IT机构来说，不幸的是，正确的应用程序配置通常都会在开发到生产的转换中受到损害（或者沦为人工错误的牺牲品）。结果可能是减慢部署或是应用程序出现故障——这两种情况在关键业务应用程序领域都是致命的。幸运的是，对于企业来说，这个问题并没有被忽视，而且出现了一种新的技术可以集中和自动化这些应用程序配置文件的创建。

　　在WebLogic开发机构中，开发人员通常使用电子邮件、文本文档或口头通信，提出他们关于QA小组应该使用什么样的配置参数，以便充分支持测试环境中的最新二进制转储的建议。例如，开发人员可能让QA小组进行审查，确保ShrinkingEnabled在JDBC连接池下被设为“true”，而连接池的线程数目被设为50。有时信息会非常简单明了（例如：“这是该DB连接的URL”）；有时则需要研究一下（例如：“这是事务性数据源JNDIName”）。在大多数情况中，这并不是单方的交流。让QA构建支持那些设置最佳测试环境的人需要一些时间。还有就是，其中的一些信息，比如Server和SSL监听端口设置，取决于具体的环境。但是最终，设置定义好了，二进制值签入了构建过程，而开发人员也基本上不再插手其应用程序正常运行的配置参数（参见图1）。

图1

　　在IT领域的生产方面，配置设置以不同的方式来看待。在一个典型的生产环境中，IT经理忙于使大约1000个任务关键型应用程序保持正常运行，而且要让它们一直运行，最好有99.999%的可用性。与开发机构不同的是，IT领域的人与IT基础架构层（Web服务器、应用服务器、数据库，等等）的维护和保养紧密联系。他们密切关注生产阶段支持J2EE应用程序的平台，因为如果这些平台出现故障的话，他们的工作可能就危险了。此外，他们还必须管理与所有底层配置文件关联的复杂性，不管它是在WebLogic中还是在应用程序基础架构层的其他所有资产中。

　　在应用程序性能和可用性非常重要的领域，保持应用程序最大限度地正常运行要比应用程序所完成的功能更为重要。

　　这不是秘密：与生产相关的人员将尽力阻止应用程序崩溃，或者当故障应用程序停止运行时让它重新运行。在这些情况中（虽然开发人员通常最先涉及到），问题通常都存在于所支持的IT基础架构中的底层配置。通常不是代码本身引起了崩溃。但往往是责任被推卸，而没有采取多少措施来确保将来不会出现更多与配置有关的问题。

　　从高层面来看，开发人员和IT机构的愿望是一致的：都想尽可能快速而平稳地将新应用程序投入生产。但是，他们的方法是完全不同的。对于IT基础架构小组领导来说，对围绕他们知之甚少的应用程序的底层参数做动态调整是摆在他们面前的现实问题。而另一方面，开发人员则要依赖编码专业知识和行业解决方案来好好利用当今的领先技术。他们的任务是要创建和交付行业领先的应用程序。开发人员并不深入研究支持应用程序的各种IT资产的错综复杂性。在他们的创造性世界中，新能力和具有竞争力的优势才是关键的。找出设置支持这些应用程序的环境资产的最佳方法则是IT的任务。

　　难道只是看着应用程序通过QA成为完整GA版本，然后就靠预演和生产相关人员自己努力了，这样够吗？还是这样本身就有问题？IT和开发人员应该更紧密地合作来满足基础架构的要求吗？一家大型保险公司（他们要求不在本文中提到公司名称）认为IT和开发人员应该合作。与大多数机构不同的是，该公司的IT部门在整个应用程序生命周期都保持对基础架构设置的控制权，包括开发阶段、QA阶段、性能测试阶段、预演阶段和生产阶段。该公司的开发人员不控制他们自己的测试沙箱。如果他们开发的应用程序需要对JDBC提供程序进行修改，开发人员将允许IT部门这么做。

　　　这个例子听起来有点极端，但是它源于捕获并记录所需的一切，从而构建所谓的应用程序Run Book的需要。为了解决无法精确反映生产环境中Run Book的问题，IT小组回溯到开发环境，收集全套的配置数据，这些数据最终将用于支持在生产中运行的应用程序。对于该公司来说，要获得对应用程序基础架构的精确评估，意味着在新开发项目还没开始之前就开始收集支持Run Book的数据。

　　第二个例子是一家大型金融服务公司。该公司需要一个更耐用的工具，来提供给IT在定义灾难性恢复信息和诊断生产中的应用程序问题时使用。他们要求的解决方案意味着，所有牵涉到构建和交付新的J2EE应用程序中的小组需要尽早参与，并定义一套将直接输入到构建跟踪解决方案中的配置信息。为了达到这个目标，他们实现了一个过程，通过该过程，每个经过PVCS审查的组件构建都必须附有一套电子版的基础架构配置数据。该数据必须围绕整个基础架构层，包括WebLogic，还必须包括Apache、Oracle数据库，以及所有与最终将为防火墙所需的端口设置有关的内容。

　　如果说出现在这些公司的现象预示着什么的话，那么在未来几年中，开发人员将逐步要求参与到生产Run Book中。这很可能集中在WebLogic配置信息。但是，正如您在此所看到的，开发人员还需要仔细研究他们当前不测试或使用的外围技术。可能他们甚至会协助定义最佳实践，以便当应用程序到达生产环境时IT小组可以作为参考。

　　当然，要求开发人员定义在QA测试周期完成后支持应用程序的实际配置参数，这是不大可能的。但是，在将Web应用程序快速转入生产后，并使它们以后能保持正常运行的想法驱动下，公司无疑会寻求新技术以促进应用程序的发展。最后结果可能是，在整个应用程序生命周期中，开发人员完全了解甚至可能全面控制与基础架构关联的参数。为此，公司当然会考虑自动管理该信息的好处。通过自动化，整个环境，以及与之关联的底层配置设置，都可以被捕获并重新部署。这样可以最小化IT基础架构小组的参与，所用的时间只是目前手动配置新环境所用时间的几分之一。与当前出现的其他新技术相比，自动化为IT基础架构经理提供了最高的可能收益，因为它看起来能节省开支并提高机构效率。

　　自动化需要帮助公司的开发和QA部门给IT基础架构小组提供关于底层配置数据的信息。明确地说就是，IT基础架构小组需要知道，随新应用程序向预演小组提供的配置数据，已经经过严格检查，并反映了当前的生产现实。

　　等到程序启动时，开发IT Run Book的工作已经完成了。这是因为IT将会接受直接从他们非常了解的测试环境中收集的同样信息。不会有涉及更多生产场景的中间方法。Run Book将精确反映生产环境（参见图2）。

图2

　　要达到这种幸福的状况，必须从一开始就决定好各个小组将如何共享最终要写回IT Run Book的信息。在整个过程中，开发人员应该能够自由地访问和评论端到端的QA测试环境。他（或她）也应该能够提供关于各种底层基础架构资产需要如何配置以获得最优性能的建议。这实质上是标准和策略创建的练习。通过从开发和QA部门征集反馈信息，IT基础架构小组可以收集关于资产配置的可察觉的要求，并可以实际监视这些资产要求的修改一直到生产阶段。此外，它们实际上控制了方向，因为贯穿整个测试阶段的核心要求是QA环境必须完全与生产匹配。

　　这个Run Book自动化方案的最后阶段是由QA部门把应用程序的整个二进制版本，以及所有被QA和开发部门一致通过的“最佳”配置，一起推入UAT阶段。当前，UAT阶段存在的瓶颈主要是由于花在弄清进行了什么测试上的时间。要考察大量的更改是如何做出的，也会造成瓶颈，因为在生产环境中GM里程碑将会影响应用程序。现在既然Run Book已经透明并且可访问以便大家查看，而且在某些情况下还可以修改，问题就解决了。如果QA测试环境的快速比较可以说明，应用程序在使用了当前生产技术的环境中运行得很好，那么加在UAT阶段的负担实际上就消除了。

　　一组完全经过验证的、精确反映生产的配置数据可以很容易地被整个应用程序生命周期中感兴趣的涉众所访问。因此，配置管理数据库（CMDB）的理念必须被付诸实施。此外，底层数据必须考虑到一定级别的粒度性，才能达到在此描述的结果。这就是说，提升整个应用程序环境及其相关资产的所有配置项，无缝通过QA、通过预演阶段以及后续发布到生产的能力。

结束语

　　允许公司将新Web应用程序快速投入到生产，并自动化有意义的Run Book开发的技术还很少。但是，它正在增长。时间将会证明，对开发机构来说，牢牢抓住整个基础架构要求将是一笔宝贵的财富。最起码在哪些配置需要管理和首选属性值方面，这种系统将能提供整个机构的更好可见性。对于开发而言，一个明显优点是在生产环境中很少需要帮助诊断配置相关的问题。