背景
我的团队一直在调查生产环境中的一个问题（参见 Stack Overflow 帖子）。我们彻底检查了应用层（即代码、日志等），也进行了一些低级数据包嗅探，但无济于事。奇怪的是，这个问题只发生在生产中。更奇怪的是，故障点的代码一年多来都没有改变。
问题
现在，我们需要开始探索其他选择，其中之一就是用新的生产环境替换生产环境。我希望你们都能以某种方式帮助我。
我正在寻找有关如何尽可能无缝地将旧生产环境替换为新生产环境的建议/推荐。但是，在一段时间内，我需要新旧环境协同运行，以验证新环境是否解决了该问题。新环境将由一组管理员使用，而旧环境将由非管理员使用。一旦我们完成验证，旧环境将完全关闭。
我正在考虑在服务器前面放置某种代理，以便我可以根据需要重定向请求，并且正在查看Apache Tomcat 的负载均衡器应用程序。我不确定这是否是最好的方法，所以我希望这里有人可以提供一些建议。
假设
- 仅应用服务器将被替换
- 数据库服务器将保持完整，当两个生产环境同时运行时，它们将指向同一个数据库
- 完全控制服务器
应用服务器技术
- RHEL 5.7
- Tomcat 6.0
答案1
看看那么问题来了我不知道这是不是系统级问题——那边的描述听起来像是应用程序错误。无论如何，升级环境总是值得考虑的事情，所以我会尝试一下 :-)
重大软件变更或迁移的一般行动计划通常如下所示（从您的 SO 问题来看，我在任何地方都提到 DB/数据库，您都应该考虑您的 App2 服务器）：
- 尽可能在新硬件（以及可选升级的软件 - 最新的操作系统、网络服务器、数据库等）上复制您的环境。
这可以包括克隆所有生产数据库（如果您没有方便的测试数据，这很有用）。 - 进行彻底测试，确保问题已解决。
（这部分对您来说有问题，因为您说您无法可靠地重现该问题） - 清理测试中的杂物
- 选择一个方便的时间进行切换
（对您的用户来说“方便”：不幸的是，这通常意味着周六凌晨 3 点或管理团队同样讨厌的时间） - 进行转换 - 包括（大致按此顺序）
- 断开旧环境与网络的连接/禁用用户访问
- 将旧环境置于静止状态，使其不再发生变化
- 将任何数据库/易失性数据同步到新环境
- 在新环境上线之前，进行所有可以进行的测试
- 如果测试通过，则打开对新环境的访问
（或准备将旧环境放回去）
根据您的情况，根据异常行为出现的位置，您可能能够在步骤 3 附近缩短大部分步骤：如果您的管理员是唯一看到应用程序行为不端部分的人，那么您的管理员可以敲击环境的测试副本，直到他们重现错误或确信错误已经消失（如果错误出现，您将回到应用程序领域）。
如果问题面向用户，那么唯一真正的解决方案就是将新内容放在用户可以访问的地方，这基本上意味着要经历整个过程。
由于您希望并行运行环境，因此您还面临一些不同的挑战：如果两个环境都将写入数据库，则需要采取预防措施，以确保两个环境都将相同的信息写入其数据库副本（在负载均衡器上多路复用连接），或者两个环境都可以安全地与单个数据库交互。
并行运行几乎消除了上述第 5 条中的第一和第三点（您无需复制后端，“旧”环境将继续运行 - 您只需在其旁边支撑新环境即可）。
在您的特定情况下，如果 App1 上有相同的应用程序，您可能能够将 App2 用作共享数据库，但这是您从软件角度需要考虑的事情（如果 App2 看到多个主机与其通话，它会不会感到惊慌？）。
无论你做什么，一定要坚持使用旧环境一段时间而不去碰它（这段时间可以长一点也可以短一点，这取决于你的具体情况——例如，在我的公司，在一次重大的数据库模式更改后大约 8 小时，我们积累了太多数据，以至于我们无法回滚：数据丢失将是灾难性的，恢复过程也将旷日持久）。
一旦你确定新环境已经解决了你的问题（或者至少和旧环境一样好，没有新的您可以将旧东西变成开发实验室。