4.6　及時修復

從寫完一行代碼到將這行代碼發布上線，其間經歷了一項又一項活動，以及各種等待。然而這并不是全部，只是理想情況。每一項活動都有可能失敗，都有可能檢測出問題，于是需要修復問題，需要返工，甚至返工多次。

那么，我們是否應該盡量避免遇到問題？當然不是。這些活動的目的（之一）就是發現問題并修復，以便讓質量提升到最終足以發布的程度。但關鍵是，發現了問題要及時修復。

4.6.1　為什么要及時修復

在集成測試階段發現的問題要及時修復，趁著開發人員的思維還在編程上下文里，定位和修復問題都比較快。此外，有些嚴重問題，比如構建沒有通過或者系統無法啟動，會阻礙集成發布流程的繼續流轉，甚至影響繼續開發。在集成分支上進行的持續集成，就好像交通運輸大動脈一樣，既是進一步測試所依賴的，也是開發人員相互之間交換代碼的場所，如果這里堵住了，那就全堵住了。所以，如果這里出現了問題，一定要及時修復。

如果代碼改動已經上線，那么這時暴露出來的問題更是要及時修復——出現故障要及時處理，對于嚴重的缺陷要考慮緊急修復，對于不那么嚴重的問題也要抓緊排期。所以說及時修復是一個貫穿始終的策略。

4.6.2　如何做到及時修復

要想做到及時修復：

第一要義是通知要及時和精準。要及時把發現的問題通知到負責處理問題的人，最好是通知到直接工作的人。比如代碼改動提交觸發的測試，發現問題就自動直接通知給代碼改動人，而不是通知給特定的協調人，因為最后是由代碼改動人來處理和解決問題的。另外，也不建議進行廣播，恨不得所有人都停下手頭的工作，一起來“吃瓜”—這又有什么實際的作用呢？通知手段以即時聊天等實時通知手段為佳。而如果是故障，則需要有一套規范的故障處理流程，保證故障被及時處理。

第二要義是優先處置。比如在集成過程中出現了問題，要有機制保證開發人員會高優先級快速響應。我們可以做相關統計，定期曬曬數據，看看是誰經常拖后腿。還可以考慮，如果在一定的時間內沒有解決問題就自動升級，通知團隊負責人。

第三要義是修不如退。修就是指修復——找到具體原因，修改代碼，然后發布修復后的新版本。退是指回退到上一個好用的版本，或者把有問題的改動摘除。在處理線上故障時常使用前者；而在處理集成過程中的問題時，有時候會使用后者，把有問題的代碼改動提交/合入摘除，這是后者的典型應用場景。情況越緊急，影響面越大，就越要采用退的方法而不是修；修起來難或者不確定難不難，也要采用退的方法。

第四要義是便捷排查。如果不是一退了之，而是真正修好的話，那么就需要能夠方便地排查問題，快速地定位問題。對問題的準確定位是一門學問，我們用它來對抗告警風暴。而在定位到具體問題后，要想修復，還要深挖問題根源。這時候就需要好用的日志。此外，在測試環境中，應該能夠快速精確地復現線上問題，進而進行調試。想一想，在實際的項目中，容易做到這一點嗎？