不更新实时系统中损坏代码的原因？
Reasons not to update broken code in a live system?
在我目前的工作中，在一项服务中发现了实时代码库中的错误。
我们已经确定了一个相对较小的代码更改，可以解决该问题，并且已确认它可以在测试环境中工作。
但是，由于这项服务已经很老了，计划在接下来的 12 个月左右逐步淘汰它，并将所有内容迁移到较新的服务，因此做出了架构决策，不再对当前服务（极端情况下的例外情况是微小的配置更改，但我们的修复被归类为更大的更改）
另一种修复方法是将现有代码迁移并重新开发到新服务，但这是一项更大的工作量，需要进行更广泛的测试等。同时也意味着现场制作在这项工作完成之前，错误将一直存在
我想了解一下，以前有没有人遇到过类似的事情，在架构方面有什么原因不修复当前在您的实时系统中的某些代码？
如果实施修复的风险大于回报，那么它就没有意义 - 即如果错误在 1% 的时间内影响了 1% 的用户，但修复将冒停机时间的风险，影响 100用户百分比。除非无论如何都没有人使用它，否则部署将是一种浪费。
但是，考虑到一些事情已经到位，我认为没有理由在生产环境中留下损坏的代码。在我看来，这些东西是：
- 在所有环境中自动部署 - 因此可以在生产中执行将工作代码部署到测试环境的确切步骤顺序。任何手册都会引入错误的可能性。
- 具有良好测试覆盖率的持续集成管道 - 这意味着您知道该修复程序不会破坏其他任何东西，因此再次强调，将部署它的风险降至最低。
- 在生产环境中进行冒烟测试，以确保部署更改后一切正常。
我确信架构冻结有充分的理由（或者可能只是政治原因）——但如果团队因为涉及的风险而害怕部署更改，则应该敲响警钟。同样，我并不是说这里就是这种情况 - 只是一般性评论 - 但如果归结为对系统质量和部署过程缺乏信心，则可能需要重新审视一些事情。该行业的一些大公司（想想 Facebook、Twitter 和类似公司）每天部署多次 - 因为他们有一个可靠的流程可以让他们安全地这样做。
花费在修复上的时间可能会与使用新服务实施和解决问题所花费的时间相抵消。
架构师可能会决定，最好将时间花在开发更健壮的新服务上（正如您所说的那样，无论如何都会很快迁移），而不是仅以两种不同的方式在同一件事上工作两次。
另一个要考虑的因素是，如果当前的代码库陈旧且难以使用，那么你提到的有效修复是否有任何建议，如果没有完成全套回归测试（也意味着花费更多的时间和精力在很快就会被淘汰的东西上）实际上最终可能会破坏更多的系统？
在我目前的工作中，在一项服务中发现了实时代码库中的错误。
我们已经确定了一个相对较小的代码更改，可以解决该问题，并且已确认它可以在测试环境中工作。
但是，由于这项服务已经很老了，计划在接下来的 12 个月左右逐步淘汰它，并将所有内容迁移到较新的服务，因此做出了架构决策，不再对当前服务（极端情况下的例外情况是微小的配置更改，但我们的修复被归类为更大的更改）
另一种修复方法是将现有代码迁移并重新开发到新服务，但这是一项更大的工作量，需要进行更广泛的测试等。同时也意味着现场制作在这项工作完成之前，错误将一直存在
我想了解一下，以前有没有人遇到过类似的事情，在架构方面有什么原因不修复当前在您的实时系统中的某些代码？
如果实施修复的风险大于回报，那么它就没有意义 - 即如果错误在 1% 的时间内影响了 1% 的用户，但修复将冒停机时间的风险，影响 100用户百分比。除非无论如何都没有人使用它，否则部署将是一种浪费。
但是，考虑到一些事情已经到位，我认为没有理由在生产环境中留下损坏的代码。在我看来，这些东西是：
- 在所有环境中自动部署 - 因此可以在生产中执行将工作代码部署到测试环境的确切步骤顺序。任何手册都会引入错误的可能性。
- 具有良好测试覆盖率的持续集成管道 - 这意味着您知道该修复程序不会破坏其他任何东西，因此再次强调，将部署它的风险降至最低。
- 在生产环境中进行冒烟测试，以确保部署更改后一切正常。
我确信架构冻结有充分的理由（或者可能只是政治原因）——但如果团队因为涉及的风险而害怕部署更改，则应该敲响警钟。同样，我并不是说这里就是这种情况 - 只是一般性评论 - 但如果归结为对系统质量和部署过程缺乏信心，则可能需要重新审视一些事情。该行业的一些大公司（想想 Facebook、Twitter 和类似公司）每天部署多次 - 因为他们有一个可靠的流程可以让他们安全地这样做。
花费在修复上的时间可能会与使用新服务实施和解决问题所花费的时间相抵消。
架构师可能会决定，最好将时间花在开发更健壮的新服务上（正如您所说的那样，无论如何都会很快迁移），而不是仅以两种不同的方式在同一件事上工作两次。
另一个要考虑的因素是，如果当前的代码库陈旧且难以使用，那么你提到的有效修复是否有任何建议，如果没有完成全套回归测试（也意味着花费更多的时间和精力在很快就会被淘汰的东西上）实际上最终可能会破坏更多的系统？