再發一篇攢人品，早點突破新兵的限制。上一篇《運營商要向互聯網學什麼》html
2011年末，浙江公司分管支撐的楊劍宇副總在支撐內部召集了一次頭腦風暴，要求部門裏各位主管和骨幹輪流發言，不講成績，只講問題和思路，一圈人一個一個輪流講過來：前端
l 負責開發的主管說如今業務部門的需求常常考慮不清楚，而上線的時間壓力很大，風險也很大，匆忙上線很容易把現有的業務弄亂，同時，上線後每每要在業務規則、操做便捷性上作屢次修改，造成了不少沒必要要的二次開發，所以要求業務部門和需求管理員加大需求分析的力度，儘早明確需求，下降上線風險，減小二次開發。web
2 負責產品配置的同事說新增產品如今只能在測試環境上進行驗證，發佈後即爲生產環境，很難分析新產品上線帶來的影響，以及評估對現有產品模型、資費體系的衝擊。建議增長一套類生產的環境，進行全量模擬驗證。算法
3 負責測試發佈的同事說目前回歸測試案例集不全，有些前臺功能使用的場景只有一線營業員才知曉，一旦在上線前的迴歸測試有遺漏，上線後2個小時的核心功能迴歸並不能保證系統正常。要求增強自動化測試範圍，完善迴歸測試案例集。數據庫
4 負責投訴處理的同事說上線後的功能不穩定致使的前臺保障、批量客戶投訴對平常的運維工做的衝擊很大。要求提升需求分析和上線質量，避免故障和批量差錯的發生。後端
那爲何會有這麼多的事情呢，這一切都是由於2011年浙江移動新版本的CRM割接上線後各種事件、問題很是多，對於割接前已經穩定了不少年的開發、運維體系形成了極大的衝擊。服務器
割接，是一場戰爭網絡
割接，尤爲是核心系統的割接，對支撐，對前臺，就是一場戰爭，由於每一次的系統割接，基本就等同於次日系統沒法使用、或者用戶的批量投訴。架構
先來回顧一下什麼是割接。2003年剛畢業，我就遇上了浙江移動第一次全省集中BOSS系統的割接。我和同批進公司的朱駿一塊兒問當時的BOSS項目經理羅文模（現福建移動支撐的副總）：什麼是割接，他說：割接，就是把老系統割下來，把新系統接上去，哈哈，很是形象吧。後來，百度了一下「割接」，發現這是一個從網絡專業延伸到支撐網的名詞：傳統的割接是指使用一種新的事物替換原有舊的事物，也指將一種業務或流量從一個網中移植到另外一外網絡中。如今，凡是以新的系統替換舊的系統的行爲都稱爲割接。app
在通訊行業，割接是一件很慎重的事情，凡是割接，都是在晚上進行，要求進行周密的測試、數據的備份、以及失敗緊急回退方案演練等等，無論是正向，仍是反向，都要有充足的準備和演練，才能保證割接的成功。同時，通常在臨晨五、6點前要求割接完畢，完成業務驗證，不能影響次日的運營，所以，留給真正開始割接的時間並很少，對各配合方要求都很是高。浙江移動CRM割接步驟當時專門印發成了一本小冊子，A4的打印紙，100多頁，詳細到每個人、每個時間點、每個步驟、每個命令。
割接方案中，最難的就是涉及數據模型升級的地方了。如今的割接方案都是先把老的數據模型在系統升級前，經過批量操做方式，「一次性轉換」成新版本的數據模型。咱們作過軟件開發的朋友們都很清楚，作正向的升級比逆向的降級要簡單，就好像連微軟等這些傳統的大軟件開發商都沒有提供這樣的服務：咱們把OFFICE軟件從2003升級到2010，用了一段以爲不爽，不用卸載而直接回退到2003再使用。從正向考慮把老的模型升級到新模型，你們都認爲是理所固然要作的事情，從項目建設之初就考慮的很清楚，在準備割接腳本時也很充分。但反過來，重新模型降級回老模型，絕大部分開發人員都是從心裏拒絕這個事情的，人的思惟中老是存在僥倖心理，萬一不成功纔用到的腳本，爲了這個「萬一」值得麼，有這功夫還不如好好想一想怎麼確保成功呢，因此，最容易出問題的地方每每就在這些回退的腳本上。並且，由於都是批量操做，極易出錯，且要消耗大量的時間，這樣，把原本就很緊張的升級時間壓縮的更短，由於割接計劃中還要預留出足夠的回退時間。
灰度，是一種策略
這裏打斷一下，最近這幾年您據說過淘寶升級麼？若是沒有記錯，最近的一次淘寶發公告要暫停業務進行系統升級是2008年，以後再也沒有據說過淘寶經過半夜停業務的方式來作系統升級的事情了。您據說過QQ升級麼，事實上QQ從最開始的只能有500個好友到如今支持上億的好友，經歷過大大小小上千次的升級，歷來沒有停業務這一說法，爲何啊？由於互聯網產品有一個特色，爲了減小甚至避免系統升級對用戶使用形成影響，在升級的過程當中都採用了灰度發佈的策略。
什麼是灰度發佈，這裏引用一下百度百科的內容。
灰度發佈，是指在黑與白之間，可以平滑過渡的一種發佈方式。AB test就是一種灰度發佈方式，讓一部分用戶繼續用A，一部分用戶開始用B，若是用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把全部用戶都遷移到B上面來。灰度發佈能夠保證總體系統的穩定，在初始灰度的時候就能夠發現、調整問題，以保證其影響度。-- 百度百科
哦，原來灰度發佈就是保持兩份不一樣的版本，讓一小撮用戶先在新版本上嚐鮮，等這部分小白鼠用戶穩定了，在把絕大部分的用戶遷移到新版本上來。別的先不說，就針對以前咱們部門那麼多領導提出來的問題，一一解答下：
n 灰度發佈後：上線前須要明確業務主線，若是業務規則、操做上存在紕漏，出問題的範圍也可控。並且，如今市場部門作推業務前，採用的也是先挑一箇中等營業廳先操做試點，整理出業務規範，肯定沒問題再大規模推廣，灰度發佈正好就能適應這種節奏和方式。
n 灰度發佈後：能夠控制在灰度環境上驗證新產品的準確性，驗證各類訂購、計費、查詢等場景。
n 灰度發佈後：在灰度環境上觀察、收集營業員的操做，並錄製成自動化測試的腳本，能夠快速提升自動化測試的比例。
n 灰度發佈後：前臺的影響範圍可控，也就是幾個臺席、百十個客戶，徹底能夠避免上線故障和批量差錯的產生。
這麼一圈分析下來，灰度發佈真是個使人激動的好東西啊！接下來，部門內針對灰度發佈的事情組織一撥人討論，論證咱們的CRM系統是否適合作灰度發佈。
當前系統典型的分層架構都是三層結構，在WEB層、APP層作灰度發佈很容易，只須要搭建兩套不一樣版本的生產環境，而後從WEB層控制訪問的源頭便可。可是服務總要收斂到數據層，由於客戶的數據只能保留一個版本才能保證最小粒度（單客戶級）的對外服務一致性，因此，一旦要在這個層上作灰度，不但要保留兩個不一樣版本的數據，並且在程序控制、代碼邏輯上會很是困難。
最後的結論是若是隻有WEB層的功能上線，作灰度是合適的，但咱們每次上線都涉及都後臺表的變化，沒法承擔兩份數據的差別，因此沒法實施灰度發佈。
這事就一直擱置在這裏了。
是否是在運營商裏，真的就不適合用灰度呢？
灰度，更是一種思想
若是真的能經過在WEB層、APP層的灰度發佈控制影響的話，爲何必定要提早批量把數據轉換過去呢，爲何不能在客戶訪問到系統，要用到數據的時候，才把客戶數據從老模型轉換成新模型呢？
也就是說，除了系統層面、數據層面能作灰度這種選擇，咱們在過程上爲何不能一樣採用灰度呢？
具體的說，就是把之前批量的數據割接和回退的腳本「單元化」，封裝成一個個針對單獨數據來源的小腳本。無論你作沒作過DBA，我想這類針對單客戶的數據遷移，您必定會使用到索引，執行效率很是高，這樣，單個數據遷移完成後再調用新版本的服務，對客戶感知基本沒有什麼影響。
這樣，前端的灰度發佈，加上後端數據的即時轉換，咱們就能作到每次升級後的版本至開放到一兩家營業廳、幾個臺席，控制較少許的用戶使用，同時，採起動態數據遷移的方式，把這些臺席上受理的客戶數據動態升級到新的數據模型，前臺只要加上個「數據轉換中，請等待」的提示，前臺人員必定可以理解，對這些「小白鼠」客戶持續跟蹤，等系統穩定了再逐步放開臺席，放開試點數量，這不就是一個完整的灰度發佈麼？
事情就是這樣，只要你持續在一個問題上深刻想下去，總會有解決的辦法。2013年初去廣東公司交流的時候，他們正在作CRM系統的割接，由於地市公司擔憂割接帶來的業務影響，配合意願不強，並且在第一次割接的時候確實是由於系統問題產生了一些影響，被地市公司把問題放大，給了支撐很大的壓力。若是廣東公司能考慮下灰度的策略，在地市只挑一、2個營業廳，讓他們先感覺新系統，接受新系統，後續的割接應該會順暢不少。即便是新系統有問題，一兩家營業廳、幾個臺席的失敗，對地市公司都是能夠承受的。因此，灰度發佈看似一個加長系統升級的過程，實際上是一個有效減低風險，加快割接進度的好策略呢。
灰度部署典型的框架以下圖，供參考：
小結
2011年亞信在浙江割接，2012年在上海、北京、遼寧割接，亞信的餘鵬武總還計劃寫一本移動CRM割接的書，說要把這些經歷和痛苦都寫出來，雖然我相信這本書裏必定有不少的內容和趣聞，但我我的仍是不同意這種宣揚靠人堆、靠硬幹蠻幹的工做方法。
真心但願移動公司之後的上線再也不有「割接」這樣的詞，而都是採用「灰度」的方式，你們輕裝上陣，不用提心吊膽、不用熬夜幹活，你們白天裏輕輕鬆鬆就把事情作掉了。
割接前先再搭一套新系統，只有WEB和應用部分新建，數據部分先搭個空庫。數據部分作成腳本，按照規則預設，來的用戶屬於規則的，就觸發腳本，把舊數據庫的用戶數據升級填充到新的空庫裏面。
