不更新实时系统中损坏代码的原因？

Question

在我目前的工作中，在一个服务中识别的实时代码库中存在错误。

我们已经确定了一个相对较小的代码更改，可以解决问题并且已经确认可以在测试环境中工作。

但是，由于这项服务已经过时了，计划在未来12个月左右逐步淘汰，并将所有内容迁移到新服务中，因此制定了一项架构决策，不再对当前服务进行更改（对于极端情况，例如微小的配置更改，但我们的修复被归类为更大的更改）

替代修复方法是将现有代码迁移并重新开发到新服务，但这是一个更大的工作块，需要进行更广泛的测试等。并且还意味着实时生产错误将直到这项工作完成为止

我试图理解，有没有人遇到过这样的事情，并且在架构方面有什么理由不修复目前在你的实时系统中的某些代码？

Answer 1

使用新服务实现和解决问题所花费的时间可以抵消对修复工作所花费的时间的考虑。

建筑师可能会决定花时间更好地开发一种更强大的新服务（正如你所说的那样很快就会迁移），而不是仅仅以两种不同的方式对同一件事做两次。

要考虑的另一个因素是，如果当前的代码库已经过时并且难以使用，那么您提到的修复程序是否有效，是否有任何建议表明没有完成一整套回归测试（也是意味着花费更多的时间和精力在很快就会被逐步淘汰的事情上，这实际上最终会破坏你的系统更多？

Answer 2

如果实施修复的风险超过了奖励，那么它没有意义 - 即如果错误在1％的时间内影响1％的用户，但修复将有几小时的停机时间影响100用户百分比。除非没有人正在使用它，否则部署将是浪费精力。

但是，考虑到有几件事情到位，我认为没有理由在生产环境中留下破碎的代码。在我看来，这些事情是：

1. 通过所有环境自动部署 - 因此，可以在生产中执行将工作代码部署到测试环境的确切步骤顺序。任何手册都会引入错误的可能性。
2. 具有良好测试覆盖率的持续集成管道 - 这意味着您知道该修复程序不会破坏其他任何内容，因此再次将配置风险降至最低。
3. 在生产环境中进行冒烟测试，以确保在部署更改后一切正常。

我确信建筑冻结的原因很充分（或者可能只是政治性的） - 但如果团队因为涉及风险而害怕部署变更，那么它应该会触发警告。同样，我并不是说这是一个例子 - 只是一般性意见 - 但如果归结为对系统质量和部署过程缺乏信心，可能会有一些事情发生在需要重新审视。该行业的一些重要参与者（想想Facebook，Twitter和类似公司）每天多次部署 - 因为他们有一个坚实的过程，可以让他们安全地做到这一点。