前世割接今生灰階 的版本釋出

0：割接    割接，就是把老系統割下來，把新系統接上去，哈哈，非常形象吧。後來，百度了一下“割接”，發現這是一個從網絡專業延伸到支撐網的名詞：傳統的割接是指使用一種新的事物替換原有舊的事物，也指将一種業務或流量從一個網中移植到另一外網絡中。現在，凡是以新的系統替換舊的系統的行為都稱為割接。

割接方案中，最難的就是涉及資料模型更新的地方了。現在的割接方案都是先把老的資料模型在系統更新前，通過批量操作方式，“一次性轉換”成新版本的資料模型。我們做過軟體開發的朋友們都很清楚，做正向的更新比逆向的降級要簡單，就好像連微軟等這些傳統的大軟體開發商都沒有提供這樣的服務：我們把OFFICE軟體從2003更新到2010，用了一段覺得不爽，不用解除安裝而直接回退到2003再使用。從正向考慮把老的模型更新到新模型，大家都認為是理所當然要做的事情，從項目建設之初就考慮的很清楚，在準備割接腳本時也很充分。但反過來，從新模型降級回老模型，絕大部分開發人員都是從内心拒絕這個事情的，人的思維中總是存在僥幸心理，萬一不成功才用到的腳本，為了這個“萬一”值得麼，有這功夫還不如好好想想怎麼確定成功呢，是以，最容易出問題的地方往往就在這些回退的腳本上。而且，因為都是批量操作，極易出錯，且要消耗大量的時間，這樣，把本來就很緊張的更新時間壓縮的更短，因為割接計劃中還要預留出足夠的回退時間。

灰階，是一種政策

1：灰階釋出

        是指在黑與白之間，能夠平滑過渡的一種釋出方式。AB test就是一種灰階釋出方式，讓一部分使用者繼續用A，一部分使用者開始用B，如果使用者對B沒有什麼反對意見，那麼逐漸擴大範圍，把所有使用者都遷移到B上面來。灰階釋出可以保證整體系統的穩定，在初始灰階的時候就可以發現、調整問題，以保證其影響度。

2：步驟

1）定義目标 2）標明政策：包括使用者規模、釋出頻率、功能覆寫度、復原政策、營運政策、新舊系統部署政策等 3）篩選使用者：包括使用者特征、使用者數量、使用者常用功能、使用者範圍等 4）部署系統：部署新系統、部署使用者行為分析系統（web analytics）、設定分流規則、營運資料分析、分流規則微調 5）釋出總結：使用者行為分析報告、使用者問卷調查、社會化媒體意見收集、形成産品功能改進清單 6）産品完善 7）新一輪灰階釋出或完整釋出

 哦，原來灰階釋出就是保持兩份不同的版本，讓一小撮使用者先在新版本上嘗鮮，等這部分小白鼠使用者穩定了，在把絕大部分的使用者遷移到新版本上來。

 别的先不說，就針對之前我們部門那麼多上司提出來的問題，一一解答下：

    n  灰階釋出後：上線前需要明确業務主線，如果業務規則、操作上存在纰漏，出問題的範圍也可控。而且，現在市場部門做推業務前，采用的也是先挑一個中等營業廳先操作試點，整理出業務規範，确定沒問題再大規模推廣，灰階釋出正好就能适應這種節奏和方式。

    n  灰階釋出後：可以控制在灰階環境上驗證新産品的準确性，驗證各種訂購、計費、查詢等場景。

    n  灰階釋出後：在灰階環境上觀察、收集營業員的操作，并錄制成自動化測試的腳本，可以快速提高自動化測試的比例。

    n  灰階釋出後：前台的影響範圍可控，也就是幾個台席、百十個客戶，完全可以避免上線故障和批量差錯的産生。

    這麼一圈分析下來，灰階釋出真是個令人激動的好東西啊！接下來，部門内針對灰階釋出的事情組織一撥人讨論，論證我們的CRM系統是否适合做灰階釋出。

    目前系統典型的分層架構都是三層結構，在WEB層、APP層做灰階釋出很容易，隻需要搭建兩套不同版本的生産環境，然後從WEB層控制通路的源頭即可。但是服務總要收斂到資料層，因為客戶的資料隻能保留一個版本才能保證最小粒度（單客戶級）的對外服務一緻性，是以，一旦要在這個層上做灰階，不但要保留兩個不同版本的資料，而且在程式控制、代碼邏輯上會非常困難。

    最後的結論是如果隻有WEB層的功能上線，做灰階是合适的，但我們每次上線都涉及都背景表的變化，無法承擔兩份資料的差異，是以無法實施灰階釋出。

    這事就一直擱置在這裡了。

    是不是在營運商裡，真的就不适合用灰階呢？

灰階，更是一種思想

    如果真的能通過在WEB層、APP層的灰階釋出控制影響的話，為什麼一定要提前批量把資料轉換過去呢，為什麼不能在客戶通路到系統，要用到資料的時候，才把客戶資料從老模型轉換成新模型呢？

也就是說，除了系統層面、資料層面能做灰階這種選擇，我們在過程上為什麼不能同樣采用灰階呢？

    具體的說，就是把以前批量的資料割接和回退的腳本“單元化”，封裝成一個個針對單獨資料來源的小腳本。不管你做沒做過DBA，我想這類針對單客戶的資料遷移，您一定會使用到索引，執行效率非常高，這樣，單個資料遷移完成後再調用新版本的服務，對客戶感覺基本沒有什麼影響。

    這樣，前端的灰階釋出，加上後端資料的即時轉換，我們就能做到每次更新後的版本至開放到一兩家營業廳、幾個台席，控制較少量的使用者使用，同時，采取動态資料遷移的方式，把這些台席上受理的客戶資料動态更新到新的資料模型，前台隻要加上個“資料轉換中，請等待”的提示，前台人員一定能夠了解，對這些“小白鼠”客戶持續跟蹤，等系統穩定了再逐漸放開台席，放開試點數量，這不就是一個完整的灰階釋出麼？

事情就是這樣，隻要你持續在一個問題上深入想下去，總會有解決的辦法。2013年初去廣東公司交流的時候，他們正在做CRM系統的割接，因為地市公司擔心割接帶來的業務影響，配合意願不強，而且在第一次割接的時候确實是因為系統問題産生了一些影響，被地市公司把問題放大，給了支撐很大的壓力。如果廣東公司能考慮下灰階的政策，在地市隻挑1、2個營業廳，讓他們先感受新系統，接受新系統，後續的割接應該會順暢很多。即使是新系統有問題，一兩家營業廳、幾個台席的失敗，對地市公司都是可以承受的。是以，灰階釋出看似一個加長系統更新的過程，其實是一個有效減低風險，加快割接進度的好政策呢。

    灰階部署典型的架構如下圖，供參考：

總結：真心希望移動公司以後的上線不再有“割接”這樣的詞，而都是采用“灰階”的方式，大家輕裝上陣，不用提心吊膽、不用熬夜幹活，大家白天裡輕輕松松就把事情做掉了。