4.6　及时修复

从写完一行代码到将这行代码发布上线，其间经历了一项又一项活动，以及各种等待。然而这并不是全部，只是理想情况。每一项活动都有可能失败，都有可能检测出问题，于是需要修复问题，需要返工，甚至返工多次。

那么，我们是否应该尽量避免遇到问题？当然不是。这些活动的目的（之一）就是发现问题并修复，以便让质量提升到最终足以发布的程度。但关键是，发现了问题要及时修复。

4.6.1　为什么要及时修复

在集成测试阶段发现的问题要及时修复，趁着开发人员的思维还在编程上下文里，定位和修复问题都比较快。此外，有些严重问题，比如构建没有通过或者系统无法启动，会阻碍集成发布流程的继续流转，甚至影响继续开发。在集成分支上进行的持续集成，就好像交通运输大动脉一样，既是进一步测试所依赖的，也是开发人员相互之间交换代码的场所，如果这里堵住了，那就全堵住了。所以，如果这里出现了问题，一定要及时修复。

如果代码改动已经上线，那么这时暴露出来的问题更是要及时修复——出现故障要及时处理，对于严重的缺陷要考虑紧急修复，对于不那么严重的问题也要抓紧排期。所以说及时修复是一个贯穿始终的策略。

4.6.2　如何做到及时修复

要想做到及时修复：

第一要义是通知要及时和精准。要及时把发现的问题通知到负责处理问题的人，最好是通知到直接工作的人。比如代码改动提交触发的测试，发现问题就自动直接通知给代码改动人，而不是通知给特定的协调人，因为最后是由代码改动人来处理和解决问题的。另外，也不建议进行广播，恨不得所有人都停下手头的工作，一起来“吃瓜”—这又有什么实际的作用呢？通知手段以即时聊天等实时通知手段为佳。而如果是故障，则需要有一套规范的故障处理流程，保证故障被及时处理。

第二要义是优先处置。比如在集成过程中出现了问题，要有机制保证开发人员会高优先级快速响应。我们可以做相关统计，定期晒晒数据，看看是谁经常拖后腿。还可以考虑，如果在一定的时间内没有解决问题就自动升级，通知团队负责人。

第三要义是修不如退。修就是指修复——找到具体原因，修改代码，然后发布修复后的新版本。退是指回退到上一个好用的版本，或者把有问题的改动摘除。在处理线上故障时常使用前者；而在处理集成过程中的问题时，有时候会使用后者，把有问题的代码改动提交/合入摘除，这是后者的典型应用场景。情况越紧急，影响面越大，就越要采用退的方法而不是修；修起来难或者不确定难不难，也要采用退的方法。

第四要义是便捷排查。如果不是一退了之，而是真正修好的话，那么就需要能够方便地排查问题，快速地定位问题。对问题的准确定位是一门学问，我们用它来对抗告警风暴。而在定位到具体问题后，要想修复，还要深挖问题根源。这时候就需要好用的日志。此外，在测试环境中，应该能够快速精确地复现线上问题，进而进行调试。想一想，在实际的项目中，容易做到这一点吗？