更换生产服务器的build议

背景

我们的团队一直在调查我们的生产环境中的问题（请参阅Stack Overflow post ）。我们仔细研究了应用层（即代码，日志等），并且也做了一些低层的包嗅探，但是没有用。奇怪的是这个问题只发生在生产中。更奇怪的是，在一年多的时间里，失败点的代码并没有改变。

题

我们现在正处于一个需要开始探索其他select的阶段，其中一个就是用一个新的替代生产环境。这是我希望你们都能以某种方式帮助我的地方。

我正在寻找如何尽可能无缝地将旧生产环境换成新生产环境的build议/build议。但是，在一段时期内，我需要新老环境共同运作，以certificate新的环境能够解决问题。新环境将由一组pipe理员使用，而旧环境将由非pipe理员使用。一旦我们完成了validation，旧的环境就会完全closures。

我正在考虑在服务器前放置某种代理，以便根据需要redirect请求，并查看Apache Tomcat的Load Balancer应用程序。我不确定这是否是最好的方法，所以我希望这里有人能提供一些build议。

假设

只有应用程序服务器将被换出
数据库服务器将保持不变，而两个生产环境协同工作时，它们将指向同一个数据库
完全控制服务器

应用服务器技术

RHEL 5.7
Tomcat 6.0

看着这个问题，我不知道这是一个系统级别的问题 – 在那里的描述听起来像一个应用程序错误。无论哪种方式升级你的环境总是很好的思考，所以我会采取一些措施:-)

一个重大的软件更改或迁移的一般行动计划通常是这样的（从你的SO问题，无论我说DB /数据库你应该考虑你的App2服务器）：

尽可能在新硬件上复制您的环境（也可以升级软件 – 最新的操作系统，Web服务器，数据库等）
这可以包括克隆所有生产数据库（如果您没有方便的testing数据，这很好）。
testingbejeebus，确保你的问题没有了。
（这个部分在你的情况是有问题的，因为你说你不能可靠地重现问题）
清理testing中的碎屑
select一个方便的时间进行切换
（对于你的用户来说“方便”：不幸的是，这通常意味着星期六的凌晨3点或者pipe理团队的一些同样令人讨厌的事情）
进行切换 – 这包括（大致按此顺序）
- 从networking断开旧环境/禁用用户访问
- 将旧环境置于静止状态，不再变化
- 将任何数据库/易失性数据同步到新环境
- 做新的环境之前，你可以做任何testing
- 如果testing通过，则打开对新环境的访问权限
  （或正在准备把旧的回来）

在你的情况下，取决于时髦行为出现的位置，你可能会在第3步中将大部分短路短路：如果你的pipe理员是唯一一个看到应用程序的行为不当的部分，那么你的pipe理员可以击败testing副本的环境，直到他们重现错误或者确信它已经消失（并且如果这个错误popup，你又回到了应用程序域）。
如果问题是面向用户的，唯一真正的解决scheme就是将新的东西放到用户可以获得的地方，这基本上意味着要经历整个过程。

由于您要并行运行环境，因此您也面临一些不同的挑战：如果两个环境都要写入数据库，则需要采取预防措施，以确保两个环境都将相同的信息写入其数据库副本（Multiplex负载平衡器上的连接），或者两个环境都可以安全地与单个数据库进行交互。
并行运行几乎消除了上面＃5中的第一个和第三个项目符号（您不需要复制后端，而“旧”环境则继续运行 – 只需在旁边支撑新的项目）。

在你使用App1上的相同应用程序的情况下，你可以使用App2作为共享数据库，但是从软件的angular度来看，这是你需要考虑的事情（如果App2看到多个主机对话，App2会吓一跳）。

不pipe你做了什么，一定要坚持你的旧环境一段时间，而不要触及它（根据你的具体情况，这可能会更长或更短） – 例如，在我的公司大约8小时后，积累了太多的数据，我们无法回滚：数据丢失将是灾难性的，恢复时间长。
一旦你确定新的环境已经解决了你的问题（或者至less和老的环境一样好，没有新的问题），你可以把旧的东西变成一个开发实验室。