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