淺聊灰度發布
1.緣起：
什麼是灰度發布？
什麼場景下需要灰度發布？
如何進行灰度發布？
2. 灰度發布：灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？
最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題「灰度發布」。
因為筆者所負責的產品還沒有達到他們產品使用者的量級上（最低的都在1千萬+），也就談不上灰度發布這一環節，所以只有聽的份。
雖然筆者暫時沒有涉及到，但在工作中也聽過關於灰度發布的一些資訊，只不過這一次聽他們幾個交談後更是增長了不少知識，為了讓自己更加的了解這乙個「新」概念，回到住處就在網上慢慢的「啃」起來，下面則是我對「灰度發布」的理解，現分享出來。
2.1、什麼是灰度發布，有哪些好處？
答：灰度發布（又名金絲雀發布）是指在黑與白之間，能夠平滑過渡的一種發布方式。
好處：提前獲得目標使用者的使用反饋；
根據反饋結果，做到查漏補缺；
發現重大問題，可回滾「舊版本」；
補充完善產品不足；
快速驗證產品的 idea。
2.2、那麼灰度發布的流程是咋樣的呢？
【某寶的案例.**網路】
產品需求收集和確定 –>； 技術方案出具和分工協調 –>； 開發編碼 –>； 內部伺服器環境的測試 –>； 聯調（又名預發環境） –>； 小**環境發布，內部員工噴噴噴 –>； 小流量（具體有多少取決於業務影響面）公網測試 –>； 收集資料寫反饋 –>； 全量上線。
2.3、灰度發布的方式方法有哪些？
2.4、灰度發布三大型別？
web頁面灰度：按照ip或者使用者id切流啊。具有隨機性，可以控制比例
客戶端灰度：一般按照使用者逐漸推送包，主要是pc端(win，mac)、移動端（安卓，os）內部大規模內測
2.5、灰度發布時，目標使用者選取策略？
即選取哪些使用者先行體驗新版本，是強制公升級還是讓使用者自主選擇等。可考慮的因素很多，包括但不限於地理位置、使用者終端特性（如解析度、效能）、使用者自身特點（性別、年齡、忠誠度等）。
對於客戶端應用，可以考慮類似chrome的多channel公升級策略，讓使用者自主選擇採用stable、beta、unstable channel的版本。在使用者有明確預期的情況下自行承擔試用風險。
2.6、a/b測試雲服務提供商
海外應用：optimizely
2.7、延伸閱讀：
馬化騰的灰度機制是這樣的：很多公司在一開始做產品定義時，要麼確定它是黑的，要麼確定它是白的。但是馬化騰發現，網際網路產品的定義是有使用者投票決定的。在一開始，我們不定義它是黑，還是白，有乙個灰度的週期。在這個灰度週期裡，讓使用者的口碑決定它是生是死，是白還是黑。
說的再直接點，這也是馬化騰創新上的灰度機制：容忍失敗，允許適度浪費，鼓勵內部競爭內部試錯。馬化騰說過，在產品研發過程中，我們還會有乙個困惑：自己做的這個產品萬一失敗了怎麼辦?
我的經驗是，在面對創新的問題上，要允許適度的浪費。怎麼理解？
就是在資源許可的前提下，即使有一兩個團隊同時研發一款產品也是可以接受的，只要你認為這個專案是你在戰略上必須做的。
你能說這是資源的浪費嗎？我認為不是，沒有競爭就意味著創新的死亡。即使最後有的團隊在競爭中失敗，但它依然是激發成功者靈感的源泉，可以把它理解為內部試錯。
2.8 具體內容，請參考：《馬化騰致信合作夥伴：灰度法則的七個維度》
需求度：使用者需求是產品核心，產品對需求的體現程度，就是企業被生態所需要的程度；
速度：快速實現單點突破，角度、銳度尤其是速度，是產品在生態中存在發展的根本；
靈活度：敏捷企業、快速迭代產品的關鍵是主動變化，主動變化比應變能力更重要；
冗餘度：容忍失敗，允許適度浪費，鼓勵內部競爭內部試錯，不嘗試失敗就沒有成功；
開放協作度：最大程度地擴充套件協作，網際網路很多惡性競爭都可以轉向協作型創新；
進化度：構建生物型組織，讓企業組織本身在無控過程中擁有自進化、自組織能力；
創新度：創新並非刻意為之，而是充滿可能性、多樣性的生物型組織的必然產物。
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布入門
我們的產品是個比較典型的網際網路產品，產品公升級採用 小步快跑 的方式，一般採用保持每週或每兩周一次的發布頻率，同時，每週會有數次bug上線。系統上線總是伴隨著風險，系統重大bug的風險，新舊版本相容的風險，使用者使用習慣突然改變而造成使用者流失的風險等等，因為這些風險的存在，很多次上線都是通宵達旦...