我的团队一直在调查生产环境中的问题(see Stack Overflow post).我们已经彻底查看了应用程序层(即代码,日志等),并且还进行了一些低级别的数据包嗅探,但无济于事.奇怪的是,这个问题只发生在生产中.更奇怪的是,失败点的代码在一年多内没有改变.
题
我们现在正处于需要开始探索其他选项的地步,其中一个选择是用新的环境替换生产环境.这是我希望你们都能以某种方式帮助我的地方.
我正在寻找有关如何尽可能无缝地更换旧生产环境的建议/建议.但是,在某段时间内,我需要新旧环境协同运行,以验证新环境是否能解决问题.新环境将由一组管理员使用,而非管理员将使用旧环境.完成验证后,旧环境将完全关闭.
我想在服务器前放置某种代理,以便我可以根据需要重定向请求并查看Apache Tomcat’s Load Balancer application.我不确定这是否是最好的方法,所以我希望这里有人可以提供一些建议.
假设
>仅交换应用程序服务器
>数据库服务器将保持不变,当两个生产环境串联运行时,它们将指向同一个数据库
>完全控制服务器
应用服务器技术
> RHEL 5.7
> Tomcat 6.0
解决方法
主要软件更改或迁移的一般行动计划通常如下所示(从您的SO问题开始,无论我说DB /数据库,您应该考虑App2服务器)：
>尽可能在新硬件上复制您的环境(以及可选的升级软件 – 最新的操作系统,Web服务器,数据库等)
这可以包括克隆所有产品数据库(如果您没有方便的测试数据,这很棒).
>测试bejeebus,以确保您的问题消失.
(这部分在你的情况下是有问题的,因为你说你无法可靠地重现问题)
>清理测试中的碎屑
>选择一个方便的时间进行切换
(对您的用户来说“方便”：不幸的是,这通常意味着周六凌晨3点或管理团队同样令人厌恶)
>进行切换 – 这包括(大致按此顺序)
>断开旧环境与网络的连接/禁用用户访问
>将旧环境置于静止状态,使其不再发生变化
>将任何数据库/易失性数据同步到新环境
>在创建新环境之前,可以执行任何测试
>如果测试通过,则启用对新环境的访问
(或准备好把旧的一个放回去)
在您的情况下,根据时髦行为的出现位置,您可以在第3步中将大部分内容短路：如果您的管理员是唯一看到应用程序行为不端部分的人,那么您的管理员可以打败测试副本环境直到他们要么重现这个bug还是对它已经消失感到满意(如果这个bug突然出现在你的应用程序中).
如果问题是面向用户的,唯一真正的解决方案就是将新的东西放在用户可以获得的位置,这基本上意味着要经历整个过程.
您还有一些不同的挑战,因为您希望并行运行环境：如果两个环境都将写入数据库,则需要采取预防措施以确保两个环境都将相同的信息写入其数据库副本(多路复用)负载均衡器上的连接),或者两个环境都可以安全地与单个数据库进行交互.
并行运行几乎消除了上面#5中的第一和第三个项目符号(你没有复制后端,而“旧”环境一直在运行 – 你只需支撑它旁边的新项目).
在App1上具有相同应用程序的特定情况下,您可以将App2用作共享数据库,但是从软件的角度来看,这是您需要考虑的事项(如果看到多个主机与之交谈,App2会感到不安吗？).
无论你做什么,一定要坚持你的旧环境一段时间而不接触它(这可能会更长或更短,同时,取决于你的具体情况 – 例如在我的公司大约DB Schema改变后大约8小时我们我们积累了大量无法回滚的数据：数据丢失将是灾难性的,并且恢复时间很长.一旦你确定新环境已经解决了你的问题(或者至少与没有新问题的旧环境一样工作),你可以将旧的东西变成开发实验室.