最近有幾個朋友提起”灰度發布"這個概念和相關的問題。想解釋一下幾種具體的發布方式（具體名稱中文翻譯不一定正確）、他們的優缺點和實現難點。
這幾種方式都可以作為快速運營的軟件或者web服務公司逐步發布新代碼或者新產品，邊嘗試邊改進的方法，這些方法可以避免一次發布里面某個產品／代碼的漏洞對網站產生瞬間毀滅性的后果。
這幾種方式各有優缺點和難點，根據實際情況一個公司可能使用不同的方法做不同的發布。
- 分步代碼發布(multi-phase code push)：這是敏捷開發的團隊常用的代碼發布方式?；静僮魇钦麄€團隊共用一個代碼庫，一定頻率（比如每天一次，或者每周一次）把整個代碼的最新版本做一個新的發布分支(release branch)，把發布分支逐步發布到產品線。
- 特點："逐步選擇"的過程不由代碼控制（如果代碼控制，那新一版本的控制代碼有問題就可能讓整個代碼發布過程崩潰）。“逐步選擇”過程由運營團隊負責：比如選擇每個機柜的第一臺機器，或者每個機群的第一個機柜，或者多個數據中心里面選擇某一個數據中心⋯⋯關鍵是選擇的時候是均勻分布到各種不同的機器上。如果新代碼在某一種配置的機器上有問題，運營團隊能夠及時發現。另外multi-phase code push的發布周期必須短于敏捷開發的迭代周期，往往一天或者一周之內要把代碼發布到所有機器。
- 監控：multi-phase code push一般要做實時的監控：代碼邏輯錯誤的信息按照代碼版本（比如svn revision number）來分類，保證新版本的代碼不帶來新的錯誤；硬件的信息（CPU內存IO）按照選擇的機器、機柜、機群、數據中心分類：保證新的版本不引起更大資源消耗。當以上的信息都確認之后，可以給更大規模的機器安裝新代碼。
- 難點：
- 如果前端負載均衡器不能保證用戶和機器一致的話，一個用戶可能在發布過程中看到若干次新版本和若干次舊版本（比如第一個頁面是新版本，而AJAX是舊版本），版本不兼容會造成Javascript錯誤、CSS錯位，甚至一些邏輯錯誤；Javascript體系架構需要做一些安全檢測，或者要求程序員開發的時候考慮版本兼容（一般在快節奏的web開發里面不容易）；或者用保持用戶和機器一致的前端負載均衡器；
- 監控的時候硬件資源消耗信息有可能因為發布過程本身產生很大的擾動，而與代碼無關（比如重啟之后緩存要重新warmup，增大IO，產生虛報），這需要代碼發布經理（pusher）的經驗來排除。
- AB測試(AB testing)：這是產品發布的常用手段。比起分步代碼發布，AB測試往往有更長的周期（比如幾個星期甚至幾個月）。基本操作是產品的開發者加一個或者多個配置控制（一般每個產品配置應該帶有配置的ID），允許通過調節相應的配置來讓一個產品發布到“逐步選擇”的用戶群。
- 特點：“逐步選擇”是一個有代碼控制的邏輯過程。一般的產品基于用戶ID選擇；也有基于IP或者其他信息的。
- 監控：AB測試的數據一般按照產品配置ID和打開／關閉狀態分類，分析某個產品配置在打開的時候和關閉的時候對用戶行為的影響，和對硬件資源的消耗，由此可以預測這個產品在100％發布之后的影響。
- 難點：
- 如何做選擇：不同的產品有不同的選擇方式。一般可以考慮用戶ID，但如果跟瀏覽器的緩存效率關系很大的，可能需要考慮IP（因為一個瀏覽器可能被多個用戶使用）；如果對非注冊用戶做的產品（比如各種注冊流程的測試），也可能需要IP，或者實時隨機選?。?/li>
- 產品效果的評價：有些產品需要有網絡效應，如果按照用戶ID隨機抽取樣本，網絡效應可能被打破而使產品在AB測試期間失效 （比如一個社交網站的平均用戶連接度是50，即一個用戶連接其他50個用戶，按照1%用戶ID隨機抽樣的AB測試，那被選中的用戶子群內部的連接度可能不到1）
- "逐步選擇"的邏輯本身是一個代碼，如果這個代碼寫錯的話可能帶來災難性后果。
- 灰度上線（dark launch）：我想“灰度上線”這個術語可能來源于dark launch。這是產品發布的另一種手段，往往用于需要一次發布的產品。 有一些產品可能因為市場營銷策略的原因，或者因為產品本身的特點（比如Facebook的用戶名注冊，或者可能像火車售票系統）不能進行AB測試那樣的逐步上線。同時，我們又需要知道這個產品一次上線的時候帶來的影響，在這種情況下我們可以用灰度上線。基本操作是在用戶訪問網站的時候，打開新功能所需要運行的代碼，但把用戶可見的輸出、互動和寫操作都屏蔽掉，按照AB測試的方法逐步把這個去掉用戶互動的產品發布出去。
- 特點：外界感覺不到新產品的測試過程
- 監控：和AB測試一樣，但主要關注的是系統的負載和資源消耗
- 難點：
- 如何屏蔽用戶互動：一方面要獲得幾乎真實的產品負載，另一方面希望不要把代碼搞亂導致真正發布的時候需要很大改動；
- 對真實產品發布后負載的預測：產品發布之后可能形成正反饋（比如一個產品發布之后大受歡迎，引起更多的用戶注冊⋯⋯）灰度上線只能預測第一層效果，不能預測用戶行為的改變所引起的連鎖反應。