如何优雅地将关键任务系统升级为完全不同的系统？

Question

在我职业生涯的12+年中，我还没有克服这个障碍，我怀疑答案并不容易，甚至不可能，所以我向在座的每一个人询问他们的经验。

假设你遇到了严重的问题，只能通过从一个平台转移到另一个平台才能解决--要么是在选择多年前选择的平台时犯了一个错误，要么就是超越了系统最初的设计目标。你肯定知道，随着时间的推移，积累起来的巡洋舰意味着几乎不可能测试所有肯定会导致技术支持地狱的东西--我们都知道这会导致客户的流失。不是说顾客们已经在抱怨已经存在的严重问题了！

到目前为止，我发现最好的方法是设计一个转换计划，在几个客户上测试，在十几个客户上测试，在100个客户上测试，然后为每个人最终完成转换，并祈祷你已经解决了最初的120个错误，并希望动物副产品不会以最壮观的方式进入通风系统。

然而，这并不意味着它不会无论如何。

因此，假设您正在从Exchange迁移到Exim (甚至只是Sendmail到Exim)。你是怎么处理的？

Answer 1

这是一个棘手的问题，并根据具体情况而有所不同。关键问题是：

• 有一个后备计划，无论你做什么，有一个计划，如何回到旧的系统迅速。如果您不能这样做，那么需要进行更多的测试。
• 测试您最常用的功能。看看您的日志或度量，哪些功能使用最多，哪些功能更关键。更彻底地测试该功能。
• 有几个用户，包括你自己在新服务器上“活”了好几天。时间的长短应取决于变化有多大。(也就是说，“你应该是第一个测试者”)
• 如果可能的话，将新服务与旧服务并行运行。如果您可以将代理放在中间并转发某些请求或用户，这会有所帮助。
• 在负载平衡的集群中运行。这与前一次声明类似。如果可以在负载平衡的安排中运行这两个服务，请尝试这一点。随着事情的顺利进行，你可以逐渐摆脱旧的服务。
• 将旧服务器保留几个星期或更长时间。几个月来，当我不确定是否要使用旧服务器时，我一直在使用它们。关闭它们或断开网络电缆，以确保服务器上没有隐藏的依赖项。
• 确保新服务能够处理负载。将其逐步部署并监视系统性能，同时逐渐将更多的流量转移到新系统。
• 在做事情时，要确保失败是可见的和立即的。您希望早期发生失败，并且易于识别。

使用DNS对您有利。设置两个服务以响应相同的DNS名称，但DNS指向其中一个或另一个(或两者兼而有之)。使用Linux和Windows上的本地主机文件覆盖DNS，并能够在推出之前和之后验证设置。这也使得在推出后更容易进行故障排除。只需将本地主机文件更改为旧服务器，并查看问题机器上是否仍有故障。设置您的TTL的低，以允许快速退步。像思科的GSS这样的负载平衡器可以用于此。我可以使用iptables将特定的负载平衡主机从池中提取出来。

对于Apache来说，使用反向代理是零星迁移站点的好方法。对于其他人，使用DNS、代理或可能使用iptables框为您提供如何控制转换的选项。