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

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

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

但是，由于该服务非常陈旧，计划在未来12个月左右逐步淘汰，并将所有内容迁移到较新的服务中，因此已经做出了一个架构决策，不再对当前服务进行任何更改（极端情况除外，这些情况是轻微的配置更改，但我们的修复被归类为更大的更改）

另一种修复方法是将现有代码迁移并重新开发到新服务中，但是这是一项更大的工作，需要进行更广泛的测试等。这也意味着在这项工作完成之前，实时生产错误将一直存在

---

我试图理解，以前是否有人遇到过类似的情况，从架构角度来看，有什么理由不修复当前在您的实时系统中的某些代码？

如果实施修复的风险大于回报，那么这是没有意义的-即，如果错误影响了1%的用户1%的时间，但是修复是有意义的将面临影响100%用户的数小时停机风险。除非没有人使用它，否则部署将白费力气

但是，考虑到有几件事情已经准备就绪，我认为没有理由在生产环境中留下损坏的代码

在所有环境中自动部署—因此，将工作代码部署到测试环境的确切步骤顺序可以在生产环境中执行。任何手册都会引入错误的可能性

具有良好测试覆盖率的持续集成管道-这意味着您知道该修复程序不会潜在地破坏任何其他功能，因此，再次将部署它的风险降至最低

在生产环境中进行冒烟测试，以确保部署更改后一切正常

---

我相信建筑冻结是有充分理由的（或者可能只是政治原因）-但是，如果一个团队因为涉及的风险而害怕部署更改，那么它应该会触发警告。同样，我不是说这里的情况是这样的-只是一个一般性的评论-但是如果归结为对系统质量和部署过程缺乏信心，那么可能有一些事情需要重新考虑。一些bi行业中的g玩家（比如Facebook、Twitter和类似的公司）一天要部署多次，因为他们有一个可靠的流程，可以安全地进行部署。

考虑修复所花费的时间可能与使用新服务实施和解决问题所花费的时间相反

架构师可能会决定，最好花时间开发一个更健壮的新服务（正如您所说，它很快就会被迁移），而不是用两种不同的方式在同一件事情上工作两次

另一个需要考虑的因素是，如果当前的代码库很旧并且很难使用，那么您提到的解决方案是否有效，是否有任何迹象表明在没有完成全套回归测试的情况下（也意味着在不久将被淘汰的东西上花费更多的时间和精力）这实际上可能会破坏你的系统更多