在互聯網產品的發布過程中也較多采用此種發布方式：產品的發布過程不是一蹴而就，而是逐步擴大使用用戶的範圍，從公司內部用戶->忠誠度較高的種子用戶->更大範圍的活躍用戶->所有用戶。在此過程中，產品團隊根據用戶的反饋及時完善產品相關功能。此種發布方式，按照中國特色的叫法被冠以”灰度發布“、”灰度放量“、”分流發布“。
在傳統軟件產品發布過程中（例如微軟的Windows7的發布過程中），一般都會經歷Pre-Alpha、Alpha、Beta、Release candidate(RC )、RTM、General availability or General Acceptance (GA)等幾個階段（參考Software release life cycle）。可以看出傳統軟件的發布階段是從公司內部->外部小範圍測試>外部大範圍測試->正式發布，涉及的用戶數也是逐步放量的過程。
在互聯網產品的發布過程中也較多采用此種發布方式：產品的發布過程不是一蹴而就，而是逐步擴大使用用戶的範圍，從公司內部用戶->忠誠度較高的種子用戶- >更大範圍的活躍用戶->所有用戶。在此過程中，產品團隊根據用戶的反饋及時完善產品相關功能。此種發布方式，按照中國特色的叫法被冠以”灰度發布“、”灰度放量“、”分流發布“。
關於“灰度發布”叫法的來源無從考察。只不過按照中國傳統哲學的說法來看，很符合中國人中庸的思維模式：自然界所有的事物總是以對稱、互補、和諧的形式存在，例如黑與白、陰與陽、正與負、福與禍。在二元對立的元素間存在相互過渡的階段，所謂”禍兮福所倚，福兮禍所伏“。具體到黑與白，在非黑即白中間還有中間色——灰色。於是出現了很多關於灰色的說法：灰盒測試，灰色管理（極力推薦 任正非：管理的灰度），灰色收入，灰色地帶等等。因此對於灰度發布實際上就是從不發布，然後逐漸過渡到正式發布的一個過程。
1、灰度發布的作用
- 及早獲得用戶的意見反饋，完善產品功能，提升產品質量
- 讓用戶參與產品測試，加強與用戶互動
- 降低產品升級所影響的用戶範圍
- 。 。 。
2、灰度發布的步驟
1）、定義目標
2）、選定策略：包括用戶規模、發布頻率、功能覆蓋度、回滾策略、運營策略、新舊系統部署策略等
3）、篩選用戶：包括用戶特徵、用戶數量、用戶常用功能、用戶範圍等
4）、部署系統：部署新系統、部署用戶行為分析系統（web analytics）、設定分流規則、運營數據分析、分流規則微調
5）、發布總結：用戶行為分析報告、用戶問卷調查、社會化媒體意見收集、形成產品功能改進列表
6）、產品完善
7）、新一輪灰度發布或完整髮布
3、常見問題
3.1）、以偏概全
1)、問題特徵：
a、選擇的樣本不具有代表性；
b、樣本具有代表性，但選擇樣本用戶使用習慣並沒有涵蓋所有核心功能
2）、解決方案：
樣本選擇要多樣化，樣本的組合涵蓋大部分核心功能
3.2）、知識的詛咒
”知識的詛咒“的說法來自《粘住》中實驗，具體可以自己搜索一下。我們自己對於自己開發的產品極為熟悉，於是乎想當然認為用戶也應當能夠理解產品的設計思路、產品的功能使用。
1）、問題特徵：
a、結果沒有量化手段；
b、只依賴於用戶問卷調查；
c、沒有web analytics系統；
d、運營數據不全面，只有核心業務指標（例如交易量），沒有用戶體驗指標
e、對結果分析，只選擇對發布有利的信息，對其他視而不見
2）、解決方案：
a、產品設計考慮產品量化指標
b、結果分析依據量化指標而不是感覺
3.3）、發布沒有回頭路可走
1）、問題特徵：
a、新舊系統用戶使用習慣差異太大，沒有兼容原有功能
b、新舊系統由於功能差異太大，無法並行運行，只能強制升級
c、新系統只是實現了舊系統部分功能，用戶要完整使用所有功能，要在在新舊系統切換
d、新舊系統數據庫數據結構差異太大，無法並行運行
2）、解決方案：
前期產品策劃重點考慮這些問題，包括：
回滾方案、 新舊系統兼容方案、用戶體驗的一致性、用戶使用習慣的延續性、新舊系統數據模型兼容性
3.4）、用戶參與度不夠
1）、問題特徵：
a、指望用戶自己去挖掘所有功能。對於一個產品，大部分用戶經常只使用部分功能，用戶大部分也很懶惰，不會主動去挖掘產品功能
b、互動渠道單一
c、陷入“知識的詛咒”，不尊重參與用戶意見
2）、解決方案：
a、善待吃螃蟹的樣本用戶，包括給予參與測試的用戶小獎勵（例如MS給參與Win7測試用戶正版License）、給用戶冠以title
b、通過郵件、論壇、社區、Blog、Twitter等新媒體與用戶形成互動
c、提供產品功能嚮導。在hotmail最近的升級後的功能tip，gmail的tip都有類似的產品功能導向。在產品中會提示類似於：你知道嗎，xx還提供xx功能，通過它你可以xx 。
4、灰度發布 VS. A/B測試
灰度發佈於互聯網公司常用A/B測試似乎比較類似，老外似乎並沒有所謂的灰度發布的概念。按照wikipedia中對A/B測試的定義，A/B測試又叫：A/B/N Testing 、Multivariate Testing，因此本質上灰度測試可以算作A/B測試的一種特例。只不過為了術語上不至於等同搞混淆，談談自己理解的兩者的差異。
灰度發布是對某一產品的發布逐步擴大使用群體範圍，也叫灰度放量
A/B測試重點是在幾種方案中選擇最優方案
關於A/B測試可以參考這篇文章：A/B測試終極指南
5、灰度發布引擎
對於一般的小系統並不需要單獨的灰度發布引擎，可以參考A/B測試中做法，在頁面javascript或服務器端實現分流的規則即可。但對於大型的互聯網應用而言，單獨的用於管理用戶分流的發布引擎就很有必要了。 “錢掌櫃”分流發布模式 提到了原來阿里軟件所使用的灰度發布引擎，設計思路具有普遍性，可以供參考
6、參考文檔
特別注意：本站所有轉載文章言論不代表本站觀點，本站所提供的攝影照片，插畫，設計作品，如需使用，請與原作者聯繫，文章轉自alibuybuy