互聯(lián)網(wǎng)產(chǎn)品的灰度發(fā)布

在傳統(tǒng)軟件產(chǎn)品發(fā)布過程中（例如微軟的Windows 7的發(fā)布過程中），一般都會經(jīng)歷Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等幾個階段（參考Software release life cycle）。可以看出傳統(tǒng)軟件的發(fā)布階段是從公司內(nèi)部->外部小范圍測試>外部大范圍測試->正式發(fā)布，涉及的用戶數(shù)也是逐步放量的過程。

在互聯(lián)網(wǎng)產(chǎn)品的發(fā)布過程中也較多采用此種發(fā)布方式：產(chǎn)品的發(fā)布過程不是一蹴而就，而是逐步擴大使用用戶的范圍，從公司內(nèi)部用戶->忠誠度較高的種子用戶->更大范圍的活躍用戶->所有用戶。在此過程中，產(chǎn)品團隊根據(jù)用戶的反饋及時完善產(chǎn)品相關功能。此種發(fā)布方式，按照中國特色的叫法被冠以“灰度發(fā)布”、“灰度放量”、“分流發(fā)布”。

關于“灰度發(fā)布”叫法的來源無從考察。只不過按照中國傳統(tǒng)哲學的說法來看，很符合中國人中庸的思維模式：自然界所有的事物總是以對稱、互補、和諧的形式存在，例如黑與白、陰與陽、正與負、福與禍。在二元對立的元素間存在相互過渡的階段，所謂”禍兮福所倚，福兮禍所伏“。具體到黑與白，在非黑即白中間還有中間色——灰色。于是出現(xiàn)了很多關于灰色的說法：灰盒測試，灰色管理（極力推薦 任正非：管理的灰度），灰色收入，灰色地帶等等。因此對于灰度發(fā)布實際上就是從不發(fā)布，然后逐漸過渡到正式發(fā)布的一個過程。

1、灰度發(fā)布的作用

及早獲得用戶的意見反饋，完善產(chǎn)品功能，提升產(chǎn)品質(zhì)量
讓用戶參與產(chǎn)品測試，加強與用戶互動
降低產(chǎn)品升級所影響的用戶范圍
。。。
2、灰度發(fā)布的步驟

1）、定義目標

2）、選定策略：包括用戶規(guī)模、發(fā)布頻率、功能覆蓋度、回滾策略、運營策略、新舊系統(tǒng)部署策略等

3）、篩選用戶：包括用戶特征、用戶數(shù)量、用戶常用功能、用戶范圍等

4）、部署系統(tǒng)：部署新系統(tǒng)、部署用戶行為分析系統(tǒng)（web analytics）、設定分流規(guī)則、運營數(shù)據(jù)分析、分流規(guī)則微調(diào)

5）、發(fā)布總結：用戶行為分析報告、用戶問卷調(diào)查、社會化媒體意見收集、形成產(chǎn)品功能改進列表

6）、產(chǎn)品完善

7）、新一輪灰度發(fā)布或完整發(fā)布

3、常見問題

3.1）、以偏概全

1)、問題特征：

a、選擇的樣本不具有代表性；

b、樣本具有代表性，但選擇樣本用戶使用習慣并沒有涵蓋所有核心功能
2）、解決方案：

樣本選擇要多樣化，樣本的組合涵蓋大部分核心功能

3.2）、知識的詛咒

”知識的詛咒“的說法來自《粘住》中實驗，具體可以自己搜索一下。我們自己對于自己開發(fā)的產(chǎn)品極為熟悉，于是乎想當然認為用戶也應當能夠理解產(chǎn)品的設計思路、產(chǎn)品的功能使用。

1）、問題特征：

a、結果沒有量化手段；

b、只依賴于用戶問卷調(diào)查；

c、沒有web analytics系統(tǒng)；

d、運營數(shù)據(jù)不全面，只有核心業(yè)務指標（例如交易量），沒有用戶體驗指標

e、對結果分析，只選擇對發(fā)布有利的信息，對其他視而不見
2）、解決方案：
a、產(chǎn)品設計考慮產(chǎn)品量化指標
b、結果分析依據(jù)量化指標而不是感覺

3.3）、發(fā)布沒有回頭路可走

1）、問題特征：

a、新舊系統(tǒng)用戶使用習慣差異太大，沒有兼容原有功能

b、新舊系統(tǒng)由于功能差異太大，無法并行運行，只能強制升級

c、新系統(tǒng)只是實現(xiàn)了舊系統(tǒng)部分功能，用戶要完整使用所有功能，要在 在新舊系統(tǒng)切換

d、新舊系統(tǒng)數(shù)據(jù)庫數(shù)據(jù)結構差異太大，無法并行運行

2）、解決方案：

前期產(chǎn)品策劃重點考慮這些問題，包括：

回滾方案、 新舊系統(tǒng)兼容方案、用戶體驗的一致性、用戶使用習慣的延續(xù)性、新舊系統(tǒng)數(shù)據(jù)模型兼容性

3.4）、用戶參與度不夠

1）、問題特征：

a、指望用戶自己去挖掘所有功能。對于一個產(chǎn)品，大部分用戶經(jīng)常只使用部分功能，用戶大部分也很懶惰，不會主動去挖掘產(chǎn)品功能
b、互動渠道單一
c、陷入“知識的詛咒”，不尊重參與用戶意見
2）、解決方案：
a、善待吃螃蟹的樣本用戶，包括給予參與測試的用戶小獎勵（例如MS給參與Win7測試用戶正版License）、給用戶冠以title
b、通過郵件、論壇、社區(qū)、Blog、Twitter等新媒體與用戶形成互動
c、提供產(chǎn)品功能向導。在hotmail最近的升級后的功能tip，gmail的tip都有類似的產(chǎn)品功能導向。在產(chǎn)品中會提示類似于：你知道嗎，xx還提供xx功能，通過它你可以xx 。

4、灰度發(fā)布 VS. A/B測試

灰度發(fā)布于互聯(lián)網(wǎng)公司常用A/B測試似乎比較類似，老外似乎并沒有所謂的灰度發(fā)布的概念。按照wikipedia中對A/B測試的定義，A/B測試又叫：A/B/N Testing、Multivariate Testing，因此本質(zhì)上灰度測試可以算作A/B測試的一種特例。只不過為了術語上不至于等同搞混淆，談談自己理解的兩者的差異。

灰度發(fā)布是對某一產(chǎn)品的發(fā)布逐步擴大使用群體范圍，也叫灰度放量

A/B測試重點是在幾種方案中選擇最優(yōu)方案

關于A/B測試可以參考這篇文章：A/B測試終極指南

5、灰度發(fā)布引擎

對于一般的小系統(tǒng)并不需要單獨的灰度發(fā)布引擎，可以參考A/B測試中做法，在頁面javascript或服務器端實現(xiàn)分流的規(guī)則即可。但對于大型的互聯(lián)網(wǎng)應用而言，單獨的用于管理用戶分流的發(fā)布引擎就很有必要了。“錢掌柜”分流發(fā)布模式 提到了原來阿里軟件所使用的灰度發(fā)布引擎，設計思路具有普遍性，可以供參考

6、參考文檔

“錢掌柜”分流發(fā)布模式

百度百科：灰度發(fā)布

A/B testing

A/B測試終極指南

---

www.blogjava.net/xiaomage234/archive/2012/07/04/382199.html

總結

以上是生活随笔為你收集整理的互联网产品的灰度发布的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。