??? 在傳統軟件產品發布過程中（例如微軟的Windows 7的發布過程中），一般都會經歷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、參考文檔
?? 百度百科：灰度發布
?? A/B testing
?? A/B測試終極指南
復雜事件處理(Complex Event Processing)入門1
??? 一個新產品需要重點考慮業務風險控制。關于風險控制系統整體的技術方案可以參考 支付系統風控系統建設思考 。此方案盡管能夠滿足業務需求，但對于海量交易數據分析、風險事件的實時處理、大量的風險規則處理上，在實時性、性能、架構的可擴展性上都不是很理想，有必要重新從架構上考慮一下實現方案。
?? 一般而言，風險控制系統標準的軟件架構如下：
?
1、風控系統實現的幾種方案
?? 1)、數據庫方案：將風險規則、交易數據等都采用關系數據庫存放。正如 支付系統風控系統建設思考 所 提到的方案，交易庫和風險庫一般分別部署在不同的服務器上，在事件觸發上可以采用數據庫觸發器、消息隊列事件等方案。此種方案技術實現相對簡單，但在進行 海量交易數據查詢以及大量風險規則處理時候，數據庫系統查詢性能及擴展性成為一個較大的瓶頸。很難滿足風險事件實時分析的要求。
?? 2)、內存數據庫方案：由于對海量交易數據的查詢、分析極其消耗數據庫資源，可以采用內存數據庫方案來替代關系數據庫，保證風險事件實時處理的性能。 但目前開源的內存數據中VoltDB、H2、MonetDB、FastDB、Berkeley DB、SQLite等在大規模的業務場合應用的成熟度尚待考察，而Oracle TimesTen、MCObject eXtremeDB、Altibase價格太高。
?? 3)、分布式緩存方案：采用Memcached等NOSQL的分布式緩存來緩存交易數據、風險規則等，但由于NOSQL解決方案并不擅長數據間的關系邏輯處理，需要在程序中大量維護業務處理邏輯，遠不如關系數據庫或內存數據庫方案方便。
? 以上方案，都可以通過規則引擎（例如drools）來完成風險規則的管理和維護，避免了風險規則維護的繁瑣及規則間復雜關系處理。
?
2、Complex Event Processing (復雜事件處理)
??? Complex Event Processing (復雜事件處理)是一種新興的基于事件流的技術，它將系統數據看作不同類型的事件，通過分析事件間的關系，建立不同的事件關系序列庫，利用過濾、關聯、聚 合等技術，最終由簡單事件產生高級事件或商業流程。CEP適合的場景包括實時風險管理、實時交易分析、網絡詐欺、網絡攻擊、市場趨勢分析等等。
??? CEP的幾大特點：
- 基于數據流
- 時間序列
- 實時
- 復雜
?????????????????? 數據庫方案與CEP方案 對比（摘自Sybase CEP方案）
?
3、開源項目
Esper – Complex Event Processing
??? http://esper.codehaus.org/
JBoss – Drools Fusion
??? http://www.jboss.org/drools/drools-fusion.html
Open ESB IEP SE
??? http://wiki.open-esb.java.net/Wiki.jsp?page=IEPSE
ActiveInsight
??? http://www.activeinsight.net/
??? 其他產品或開源項目，可以參考： Complex Event Processing Vendors
? 其中Esper和Drools Fusion很值得考慮，后續作為重點研究對象。
?
4、參考資料
??? 深入淺出復合事件處理（CEP）
??? 輕松理解復合事件處理
??? Esper：CEP Engine
??? Complex Event Processing：An attempt at clarity on an often confusing topic
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
