要一直能回退代碼。確保所有的版本都能夠回退，在一個(gè)階段或QA環(huán)境中，要實(shí)踐回退功能。在生產(chǎn)環(huán)境中，當必須用它解決突發(fā)事件時(shí)，要使用回退功能整理代碼，制定幾個(gè)簡(jiǎn)單的流程，確保能夠回退自己的代碼。

如果你還沒(méi)有經(jīng)歷過(guò)不能回退系統的痛苦，那么如果繼續玩火，不停地迅速修復系統，遲早會(huì )遇到這種問(wèn)題。不要用應用太復雜或者代碼發(fā)布太頻繁作為借口，拒不加入回退代碼的功能。一個(gè)明智的飛行員，如果沒(méi)有具備讓飛機著(zhù)陸的能力，就不會(huì )讓飛機起飛。一個(gè)明智的程序員，如果不能讓系統在緊急情況下回退代碼，就不應該發(fā)布代碼。



為了給接下來(lái)要講的原則制造氣氛，我們應該在深夜圍坐在一堆篝火周?chē)v恐怖故事。我們要講的是經(jīng)典的恐怖故事，就是人們在房子里聽(tīng)到了恐怖的聲音但并不逃跑的事。那些忽視所有警告信號的傻瓜就是我們。作為程序員的上司和CTO，我們收到過(guò)幾平每個(gè)經(jīng)理架構師和程序員的匯報:應用太復雜了，不能進(jìn)行回退。我們自己對此也確信無(wú)疑。代碼發(fā)布后曾經(jīng)出現過(guò)幾次中斷或問(wèn)題，先是瘋狂地迅速修復，之后在同一天中得到一個(gè)熱修復補丁，以便完全恢復服務(wù)。我們忍受了這種小小的不便，因為我們認為這個(gè)應用太復雜了，不能進(jìn)行回退。
 
和之前發(fā)布的所有版本一樣，一個(gè)主要的基礎設施的版本發(fā)布后，也不能進(jìn)行回退。這次發(fā)布簡(jiǎn)直是場(chǎng)災難。凌晨時(shí)，一切看起來(lái)都很好但當天亮了以后，流量激增，這個(gè)站點(diǎn)就招架不住了。如果回退，只會(huì )讓幾個(gè)用戶(hù)不高興，給自己留點(diǎn)兒小傷痕，但不會(huì )有更糟的事情了。但我們卻不能回退，所以只好花費一整天的時(shí)間，為這個(gè)站點(diǎn)做點(diǎn)兒增加容量、限制流量等工作，以便在得到修復補丁之前保持一切仍然運行。那天晚上我們推出了一個(gè)補丁，當時(shí)站點(diǎn)并沒(méi)有流量，所以我們認為問(wèn)題已經(jīng)修復了。第二天早晨，當流量增加后，這個(gè)站點(diǎn)又開(kāi)始有問(wèn)題了。只好又在晚上打補丁…這種模式持續了一周多。

接連折騰了這么多天，到那周結束時(shí)，所有人都已精疲力竭。最后，我們打了一個(gè)補丁，完全忽略之前的所有修改，終于使站點(diǎn)穩定了。雖然從這次事故(包括指揮失誤)中可以學(xué)到很多東西，但與本條原則關(guān)系最緊密的是，無(wú)論我們還是客戶(hù)所經(jīng)歷的所有痛苦都是可以通過(guò)回退代碼避免的。

事后總結經(jīng)驗教訓，我們確定日后不允許再發(fā)布沒(méi)有回退功能的版本。當時(shí)除了發(fā)出這個(gè)布告外，我們別無(wú)選擇，客戶(hù)無(wú)法容忍這種性質(zhì)的問(wèn)題，每個(gè)程序員也都理解了這種要求的必要性。六周后，當下一個(gè)版本準備好時(shí)，我們已經(jīng)能夠進(jìn)行回退了。我們曾經(jīng)都認為難以克服的困難變得相當簡(jiǎn)單了。

下面列出了要具備回退功能需要注意的幾個(gè)關(guān)鍵點(diǎn)。是的，回退的主要難點(diǎn)在于數據庫。通過(guò)仔細檢査應用，一一排除那些明顯的問(wèn)題，然后堅持幾個(gè)簡(jiǎn)單的原則，所有團隊都能夠進(jìn)行回退。

口數據庫修改只能是増量的。在下一個(gè)廢除了列之間的依賴(lài)關(guān)系的版本發(fā)布前，只能添加數據庫中的列或表，不能刪除。一旦實(shí)施了這些標準，每個(gè)版本都應該有一部分代碼專(zhuān)門(mén)用于清除上一個(gè)版本遺留的不再需要的數據。

口DDL和DML必須腳本化且測試過(guò)。每個(gè)版本中對數據庫的修改必須通過(guò)腳本實(shí)現，而不能手動(dòng)進(jìn)行。其中應該包括回退腳本。這樣做的原因有兩點(diǎn):1)團隊需要在QA或某個(gè)階段測試回退操作，以便驗證什么都沒(méi)有漏掉，不會(huì )妨礙回退；2)需要在一定負載的條件下測試腳本，確保在應用程序使用數據庫時(shí)，它仍然能夠執行。

口對應用中的SQL查詢(xún)進(jìn)行約束。開(kāi)發(fā)團隊需要消除所有SQL語(yǔ)句中的歧義，刪除所有 SELECT*查詢(xún)，并且給 UPDATE語(yǔ)句加上要更新的列的名字。

口數據的語(yǔ)義修改。在發(fā)布版本中，開(kāi)發(fā)團隊不能修改數據的定義。舉個(gè)例子。票務(wù)表中的一列用于存放狀態(tài)信號，其中有三個(gè)值assigned、fixed和 closed。在應用的新版本中，如果沒(méi)有發(fā)布處理新?tīng)顟B(tài)的代碼，就不能添加第四個(gè)狀態(tài)。

口Wire On/ire Off。應該讓?xiě)媒Y構化，使其能根據外部配置，讓有些用戶(hù)能夠訪(fǎng)問(wèn)某個(gè)代碼路徑和功能，而有的用戶(hù)則不能訪(fǎng)問(wèn)。這種設置可以存放在配置文件中，也可以存放在數據庫表中既能夠根據角色賦予訪(fǎng)問(wèn)權限，也能夠根據隨機百分比分配權限。有了這種結構，就能夠讓有限的用戶(hù)對新功能進(jìn)行beta測試，而且能夠迅速地刪除主要bug的代碼路徑，從而不必回退整個(gè)代碼。我們得到的教訓雖然慘痛，但是很有網(wǎng)站建設價(jià)值，有了這次教訓，我們再也不會(huì )發(fā)布不能回退的代碼了。即使以后和其他團隊一起工作，我們也會(huì )這樣要求自己的?？梢?jiàn)，這些原則并不復雜，而是相當簡(jiǎn)單，任何團隊都能夠應用它們，都能具備回退的能力。