最近有幾個朋友提起”灰階發布"這個概念和相關的問題。想解釋一下幾種具體的發布方式（具體名稱中文翻譯不一定正確）、他們的優缺點和實現痛點。
這幾種方式都可以作為快速運營的軟體或者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，或者即時隨機選取；
- 產品效果的評價：有些產品需要有網路效應，如果按照使用者ID隨機抽取樣本，網路效應可能被打破而使產品在AB測試期間失效 （比如一個社交網站的平均使用者串連度是50，即一個使用者串連其他50個使用者，按照1%使用者ID隨機抽樣的AB測試，那被選中的使用者子群內部的串連度可能不到1）
- "逐步選擇"的邏輯本身是一個代碼，如果這個代碼寫錯的話可能帶來災難性後果。
- 灰階上線（dark launch）：我想“灰階上線”這個術語可能來源於dark launch。這是產品發布的另一種手段，往往用於需要一次發布的產品。 有一些產品可能因為市場營銷策略的原因，或者因為產品本身的特點（比如Facebook的使用者名稱註冊，或者可能像火車售票系統）不能進行AB測試那樣的逐步上線。同時，我們又需要知道這個產品一次上線的時候帶來的影響，在這種情況下我們可以用灰階上線。基本操作是在使用者訪問網站的時候，開啟新功能所需要啟動並執行代碼，但把使用者可見的輸出、互動和寫操作都屏蔽掉，按照AB測試的方法逐步把這個去掉使用者互動的產品發布出去。
- 特點：外界感覺不到新產品的測試過程
- 監控：和AB測試一樣，但主要關注的是系統的負載和資源消耗
- 痛點：
-
- 如何屏蔽使用者互動：一方面要獲得幾乎真實的產品負載，另一方面希望不要把代碼搞亂導致真正發布的時候需要很大改動；
- 對真實產品發布後負載的預測：產品發布之後可能形成正反饋（比如一個產品發布之後大受歡迎，引起更多的使用者註冊⋯⋯）灰階上線只能預測第一層效果，不能預測使用者行為的改變所引起的連鎖反應。
這幾種方式好像都被稱作灰階上線，它們還是有很大不同的。根據產品發布需要，各有優劣。
