新年新方法自从 开始，这个专栏就已经提供了几个主要计划和工具，它们已经（并且还将）在 IBM WebSphere 支持社区内发展。在新的一年，我们将采用一种稍微不同的方法。除了有助于增强您的支持和自助服务体验的工具和资源的相关文章外，我们还将提供几篇植根于我们的面向客户的角色的经验的文章。这里，我们首先从我们遇到的一个最常见的 “最差实践” 开始：不充分的测试环境。
基础架构不良实践IT 行业非常关注建立有助于管理企业级项目相关的复杂性的设计模式和实践。IBM 通过遵循这样的行业最佳实践而获益。但是，对积极因素的强调意味着用户经常不能意识到使 IT 基础架构不稳定的细节，直到他们亲自经历一次服务级停用。
“网站停用” 对于任何在线业务来说都是一场噩梦。除了可能的收入损失外，一次停用可能会影响供应商的信誉，有可能为竞争者打开大门。许多技术公司在选择产品时将稳定性作为最重要的因素，尽管许多公司并不总是能够清晰地理解产品停用的实际成本。
最差实践（有时也称为 “不良实践”）正是那些使 IT 基础架构不稳定并导致业务级停用的因素。任何两个业务级停用都不相同，但它们之间通常共享一些常见因素。下面是一些最常见、最昂贵的因素：
测试环境不同于生产环境。
通信中断。
无视应用程序状态。
直接进入生产环节的更改。
不充足的容量或可伸缩性计划。
不完整或不充足的产品知识。
不完整或过时的架构计划。
模糊的生产流量配置文件。
不充足的负载或压力测试。
不完整的更改记录。
没有迁移计划。
组织基本上因为同样原因而执行这些不良实践：认为执行最佳实践成本高或没有必要，而偷工减料将节约时间和金钱。在现实中，组织可能会在短期内实现节约，但有一些内在风险必然会导致业务级停用和远远超出任何短期节约的长期损失。
大多数 IBM WebSphere Application Server 用户都拥有某些类型的测试环境。但是，由于成本因素，许多这些环境在技术上都不等同于生产环境。您可能能够想象到，我们遇到过由于缺乏独立的测试环境而导致产品停用的情况。在过去几年我们对客户网站的访问过程中， 我 们记录了一些不良实践，比如上面列举的那些，前提是它们直接导致或加重一个业务级停用。我们的分析显示，对 WebSphere Application Server 用户经历影响非常严重的情况，最常见的因素是测试系统在技术上不同于生产系统，或者根本不存在测试系统。我们遇到的所有情况中有超过 35% 都属于这种情况 — 而且还有不断增长的趋势。
本文余下部分将讨论这种特定不良实践，以及这种情况为何普遍存在。
测试环境不同于生产环境这种情况包括：
测试环境太小，或者测试环境过度使用，而需要时不可用。
测试硬件、网络或软件级别不同于生产环境。
同一台机器或网络上的 z/OS® LPAR 没有与生产系统隔离。
测试系统的配置设置不同于生产系统的设置。
我们来检查一个样例案例研究，以便更好地理解为何这是一种不良实践。
一家大银行发现，他们的 WebSphere Application Server for z/OS 环境在纳税高峰季节频繁出现产品停用，这种情况扰乱了他们客户的在线纳税业务，反过来也损害了银行与客户的关系。经过调查，IBM WebSphere SWAT Team 发现了许多导致这种情况的因素，其中大部分都是配置错误。
特别是，一个错误是该银行在一个 WebSphere Application Server 安装的基础上创建了两个应用程序服务器：一个是测试服务器，另一个是生产服务器。由于这两个应用程序服务器都在同一个基础 WebSphere Application Server 上运行，它们的日志被共享，它们的端口被配置为避免冲突，更重要的是，由于它们在同一个代码基上运行，对 Software Development Kit (SDK) 的任何升级都将扰乱这两个应用程序服务器。尽管频繁的测试系统更新是必要的，但反复扰乱生产系统却不能容忍。
认识到这个问题后，SWAT Team 督促该银行在不同的逻辑分区模式（LPAR）上分隔应用程序服务器测试和生产系统，以免它们互相影响。这种分离完成后，任何必要的后续问题确定都将非常简单。
由于一些看似实用或经济的原因，有些开发人员没有（或选择不）创建独立的测试系统。将测试和生产系统放在一起可能比较方便，或者，分配一个专用测试系统可能看起来比较浪费。您必须理解，这样的便利也是有代价的 — 生产系统停用可能会导致巨大损失。
可能的解决方案和预防意识简言之，您应该拥有一个与您的生产系统一致的测试系统。将应用程序移到生产环境之前，您可以在独立的测试系统上执行负载和压力测试，而应用程序在生产系统中的运行将不会受到干扰。拥有独立的测试系统有很多好处，包括：
