灰度發布

能夠平滑過渡的一種發布方式

灰度發布(又名金絲雀發布)是指在黑與白之間,能夠平滑過渡的一種發布方式。在其上可以進行A/B testing,即讓一部分用戶繼續用產品特性A,一部分用戶開始用產品特性B,如果用戶對B沒有什麼反對意見,那麼逐步擴大範圍,把所有用戶都遷移到B上面來。灰度發布可以保證整體系統的穩定,在初始灰度的時候就可以發現、調整問題,以保證其影響度。

灰度期:灰度發布開始到結束期間的這一段時間,稱為灰度期。

作用


及早獲得用戶的意見反饋,完善產品功能,提升產品質量 讓用戶參與產品測試,加強與用戶互動 降低產品升級所影響的用戶範圍。

步驟


1)定義目標
2)選定策略:包括用戶規模、發布頻率、功能覆蓋度、回滾策略、運營策略、新舊系統部署策略等。
3)篩選用戶:包括用戶特徵、用戶數量、用戶常用功能、用戶範圍等。
4)部署系統:部署新系統、部署用戶行為分析系統(web analytics)、設定分流規則、運營數據分析、分流規則微調。
5)發布總結:用戶行為分析報告、用戶問卷調查、社會化媒體意見收集、形成產品功能改進列表。
6)產品完善。
7)新一輪灰度發布或完整發布。

測試方法


灰度發布與網際網路公司常用A/B測試似乎比較類似,老外似乎並沒有所謂的灰度發布的概念。按照wikipedia中對A/B測試的定義,A/B測試又叫:A/B/N Testing、Multivariate Testing,因此本質上灰度測試可以算作A/B測試的一種特例。只不過為了術語上不至於等同搞混淆,談談自己理解的兩者的差異。
灰度發布是對某一產品的發布逐步擴大使用群體範圍,也叫灰度放量。
A/B測試重點是在幾種方案中選擇最優方案。

引擎


對於一般的小系統並不需要單獨的灰度發布引擎,可以參考A/B測試中做法,在頁面javascript或伺服器端實現分流的規則即可。但對於大型的網際網路應用而言,單獨的用於管理用戶分流的發布引擎就很有必要了。
灰度發布
灰度發布

常見問題


以偏概全
1)問題特徵:
a選擇的樣本不具有代表性;
b樣本具有代表性,但選擇樣本用戶使用習慣並沒有涵蓋所有核心功能。
2)解決方案:
樣本選擇要多樣化,樣本的組合涵蓋大部分核心功能。
知識的詛咒
“知識的詛咒”的說法來自《粘住》中實驗,具體可以自己搜索一下。我們自己對於自己開發的產品極為熟悉,於是乎想當然認為用戶也應當能夠理解產品的設計思路、產品的功能使用。
1)問題特徵:
a結果沒有量化手段;
b只依賴於用戶問卷調查;
c沒有web analytics系統;
d運營數據不全面,只有核心業務指標(例如交易量),沒有用戶體驗指標;
e對結果分析,只選擇對發布有利的信息,對其他視而不見。
2)解決方案:
a產品設計考慮產品量化指標;
b結果分析依據量化指標而不是感覺。
發布沒有回頭路可走
1)問題特徵:
a新舊系統用戶使用習慣差異太大,沒有兼容原有功能。
b新舊系統由於功能差異太大,無法并行運行,只能強制升級。
c新系統只是實現了舊系統部分功能,用戶要完整使用所有功能,要在 在新舊系統切換。
d新舊系統資料庫數據結構差異太大,無法并行運行。
2)解決方案:
前期產品策劃重點考慮這些問題,包括:
回滾方案、新舊系統兼容方案、用戶體驗的一致性、用戶使用習慣的延續性、新舊系統數據模型兼容性。
用戶參與度不夠
1)問題特徵:
a指望用戶自己去挖掘所有功能。對於一個產品,大部分用戶經常只使用部分功能,用戶大部分也很懶惰,不會主動去挖掘產品功能。
b互動渠道單一。
c陷入“知識的詛咒”,不尊重參與用戶意見。
2)解決方案:
a善待吃螃蟹的樣本用戶,包括給予參與測試的用戶小獎勵(例如MS給參與Win7測試用戶正版License)、給用戶冠以title;
b通過郵件、論壇、社區、Blog、Twitter等新媒體與用戶形成互動;
c提供產品功能嚮導。在hotmail最近的升級后的功能tip,gmail的tip都有類似的產品功能導向。在產品中會提示類似於:你知道嗎,xx還提供xx功能,通過它你可以xx。

例子


Gmail Labs是一個新特性櫥窗,用戶可以自己選擇一些未正式發布的新特性進行體驗,不喜歡可以關閉,在這個過程中,吃了螃蟹,也當了Google的小白鼠。
這個做法比傳統的灰度要高明很多,更加尊重用戶:
1、它沒有強加用戶,用戶是否願意當小白鼠完全自願;
2、新特性不是打包在一起的一個大版本,可以選擇某幾個喜歡的螃蟹嘗嘗;
3、螃蟹不好吃可以扔掉,不用硬吃進肚子里引發腸胃炎
當然這些好處也是有代價的:
1、要開發一個labs平台實現新特性上架、獨立嘗試的功能,這可能要改動Gmail的前後台架構;
2、新特性要按照一定規範來寫,才能發布到這個平台上,可能會增加一些工作量;
3、小白鼠用戶增多之後,對系統的壓力可能會有一定提升,因為每一位用戶調用的界面都不一樣了。
既然Gmail Labs能夠順利發布,那麼說明對Google來說,以上這些問題都不算問題。另外,現在展示的新特性,都註明了開發者的名字,那麼,Gmail Labs可能會開放這個平台讓外部開發者也能提交特性?這倒是很open的一種開發模式,非常適合Google的web app產品線。
網際網路產品有一個特點,就是不停的升級,升級,再升級。我所在的項目組,基本上保持每周一次的發布頻率,系統升級總是伴隨著風險,新舊版本兼容的風險,用戶使用習慣突然改變而造成用戶流失的風險,系統down機的風險.....
為了避免這些風險,很多產品都採用了灰度發布的策略,其主要思想就是把影響集中到一個點,然後再發散到一個面,出現意外情況后很容易就回退。
很長時間,我們都一直在改進搜索引擎的排序演演算法,盡量讓最好的商品出現在搜索結果的第一屏。我們嘗試了很多種演演算法,不斷調整各個排序因子所佔的比重。但是我們無法確信我們的排序結果能滿足所有用戶的需求。所以我們採用了灰度發布,選取幾個一級商品類目,在其中應用不同的排序演演算法,比如在女裝類目中,我們把賣家信用所佔的比率調整到60%,在珠寶類目中,我們把銷售量所佔的比率調整到60%.. 然後發布出去,收集用戶反饋,最終選擇一種大部分人認為好的演演算法。
QZone是另外一個採用灰度發布的例子。大家都知道,QZone在過去的一年中改進是巨大 的,從以前慢悠悠的老爺爺變成了一個充滿青春活力的小夥子。其中經歷了大小無數次的發布,他們的發布也都是採用了灰度發布的策略,用戶數據的升級並不是大面積的一次性升級,而是通過一個用戶升級標誌伺服器,如果用戶數據沒有升級,後台會把此用戶的數據逐步遷移到新版本上,然後將升級標誌位置1,升級過程中,用戶仍然可以訪問舊的數據,升級完成後的訪問都將轉發給新的版本。
QQ的很多產品發布都採用灰度發布,有些是抽取部分QQ號段升級成新系統,然後根據用戶反饋再大範圍升級。
在傳統軟體產品發布過程中(例如微軟的Windows 7的發布過程中),一般都會經歷Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等幾個階段(參考Software release life cycle)。可以看出傳統軟體的發布階段是從公司內部->外部小範圍測試>外部大範圍測試->正式發布,涉及的用戶數也是逐步放量的過程。在網際網路產品的發布過程中也較多採用此種發布方式:產品的發布過程不是一蹴而就,而是逐步擴大使用用戶的範圍,從公司內部用戶->忠誠度較高的種子用戶->更大範圍的活躍用戶->所有用戶。在此過程中,產品團隊根據用戶的反饋及時完善產品相關功能。此種發布方式,按照中國特色的叫法被冠以”灰度發布“、”灰度放量“、”分流發布“。
關於“灰度發布”叫法的來源無從考察。只不過按照中國傳統哲學的說法來看,很符合中國人中庸的思維模式:自然界所有的事物總是以對稱、互補、和諧的形式存在,例如黑與白、陰與陽、正與負、福與禍。在二元對立的元素間存在相互過渡的階段,所謂”禍兮福所倚,福兮禍所伏“。具體到黑與白,在非黑即白中間還有中間色——灰色。於是出現了很多關於灰色的說法:灰盒測試,灰色管理(極力推薦 任正非:管理的灰度),灰色收入,灰色地帶等等。因此對於灰度發布實際上就是從不發布,然後逐漸過渡到正式發布的一個過程。