變更管理是運營管理者在推進生產線管理流程的切入點，或是最早實施的流程之一。這不僅是因為變更管理流程的邏輯簡單、成果明顯，同時也是因為通過管理流程的實施，可以很快的發現關聯的管理或技術的問題，并加以改進，也就是達到“提綱挈領”的效果。這里的案例就是討論通過變更管理，發現和改進生產線的發布流程和環境一致性的問題。

01背景介紹

A公司是一家提供SaaS產品運營公司，公司主要經營國內外中小企業視頻會議、電話會議業務。運維團隊以及生產線管理流程已經初步建立。其中，變更流程的設置如下：

第一步，變更的申請

研發通過上線變更平臺，在產品上線發布前的1-3個工作日內提出變更申請。主要目的是盡早協調運維團隊的資源，和檢查上線申請的軟硬資源配置準備工作。如果在這個準備過程中發現問題，則及時溝通解決。

在發布的前24小時，研發再次修訂上線變更申請。這次主要是提交測試報告，和確認變更的時間及資源。運維與測試人員再次確認測試報告，確認無誤后則運維總監批復該流程，變更流程的申請部分到此結束。

第二步，變更的執行

在指定的發布時間，發布工程師執行發布動作，完成線上的軟件或硬件的安裝和配置。發布之后由測試人員進行測試驗證，有問題時決策是否回滾，測試通過后發布結束。

變更管理在流程本身上并沒有太大的問題，但在流程的執行中，會觸發各種隱含的問題。在管理流程的實施中，挖掘和暴露相關的問題，從而進行改進，也是管理流程的核心目標之一。這個案例主要講的是A公司在變更管理在實施過程中所發現的問題，以及后續是如何改進的。

02研發與運營的沖突

A公司在一次應用程序的模塊的接口升級中遇到困境。在整個發布過程中，研發的QA在測試環境完成整體的業務接口模塊的測試，并提交代碼和變更申請。運維團隊在變更審核中沒有發現問題，給予通過。隨后在指定的時間內執行正常的變更上線。

生產線的發布時間為晚上21:00-00:00的3個小時時間段進行。時間很有限。在實際上線過程中，碰到的問題是：軟件在線上由運維團隊更新完成后，QA執行變更測試，發現接口測試不通過，通過與開發人員問題排查，發現有一個連接其他相關聯的接口的網絡策略不通，這是因為兩個業務接口是分別兩個獨立的子網，邏輯上是隔離的，而在QA測試環境中，所有的網絡段之間的路由策略是開放的，所以，這個問題在QA測試環境里面沒有測試出來。

生產線服務是7x24運行的。要在生產線線上臨時開通網略策略，這是個未知情況而且風險很大。加之A公司剛剛經歷過網絡上的一些安全問題，針對網絡策略的調整，運維部門的網絡工程師非常謹慎。如果網絡策略不開通，就需要研發可以通過改代碼來規避網絡策略風險，但是改動的代碼又比較多，所以，線上的發布陷入僵持階段。

這次發布問題被升級到更高的管理層。負責生產線運營的VP被半夜call-in來決策。VP在電話會議上問研發和運營團隊，如果臨時開通網絡策略，有誰可以簽名保證不會出現安全事故。結果是沒有人出面保證。最后，這個變更被臨時取消，發布被回退。發布被安排在第二天的白天做緊急的測試，在第二天的晚上做線上實施。

A公司的決策是對的，新的軟件發布出現問題，臨時要做的補救動作影響大又沒有做過QA，所以，一定要做回滾操作。但同時，由于新的軟件上線的延遲，用戶的體驗和業務的推廣都受到了影響。要規避這種困境，只能從管理流程和技術環境上去優化。

SaaS產品運營的核心競爭力就是服務的穩定性及可持續性，變更管理在產品運營中起到的作用是至關重要的，直接會影響到用戶的體驗。因此，建議一套符合A公司業務運營變更流程及發布體系是當前最迫在眉睫的任務。運營部牽頭梳理變更發布中存在的問題主要有兩個：

（1） 變更中受影響的客戶規模大小無法控制

（2） 測試與生產環境不一致。

03解決方案：變更管理與用戶管理、發布管理的結合

針對這兩個問題，A公司主要從發布管理體系的建立和結合入手。切入點有3個：

o 用戶管理：切分用戶。從業務角度層面，將區分大客戶、小客戶做不同的體驗池管理，也就是流量切分；

o 發布管理：分步發布。從技術角度上考慮藍綠發布、灰度發布運用到發布管理中，做到無縫最小化的影響小客戶體驗的問題；

o 環境一致性：保持核心環境參數在線上的生產線系統與線下的開發測試系統的一致性，如將業務發布設計的關聯關系拓撲實施動態的更新并展示，對每次發布的服務都有哪些依賴接口、影響哪些服務和主機，解決環境不一致及相關網絡策略依賴問題。

其中，客戶的切分采用籃子管理的思路：

A公司最終決策將SaaS產品分成三個籃子，每個籃子為不同的版本，比如三個籃子對應的產品分別為N.1、N.2、N.3，

o N.1版本對應的是小型客戶企業，相對而言，他們對服務的新功能的要求快，相應穩定性要求少些、可以接受比較頻繁的變更。

o N.2版本對應的是中型企業客戶，變更周期相對短一些的；

o N.3版本對應的是大型企業客戶，這些客戶要求服務更穩定的、軟件變化小；

在業務這一層將客戶切分開來，發布問題其實也就解決了一大部分。比如在時間順序上，新的版本發布，可以先給N.1客戶，運行一段時間后，進入N.2，然后N.3。

發布管理主要體現藍綠發布、灰度發布上，另外，解決環境一致性問題也是A公司當時最關注的點。

04藍綠部署、灰度發布

（1）藍綠部署

藍綠部署（Blue Green Deployment）的目的是減少發布時的中斷時間、能夠快速撤回發布。

藍綠部署中，一共有兩套系統：一套是正在提供服務系統，標記為“綠色”；另一套是準備發布的系統，標記為“藍色”。兩套系統都是功能完善的，并且正在運行的系統，只是系統版本和對外服務情況不同。

藍色系統不對外提供服務，用來做發布前測試，測試過程中發現任何問題，可以直接在藍色系統上修改，不干擾用戶正在使用的系統。藍色系統經過反復的測試、修改、驗證，確定達到上線標準之后，直接將用戶切換到藍色系統。

切換后的一段時間內，依舊是藍綠兩套系統并存，但是用戶訪問的已經是藍色系統。這段時間內觀察藍色系統（新系統）工作狀態，如果出現問題，直接切換回綠色系統。

當確信對外提供服務的藍色系統工作正常，不對外提供服務的綠色系統已經不再需要的時候，藍色系統正式成為對外提供服務系統，成為新的綠色系統。原先的綠色系統可以銷毀，將資源釋放出來，用于部署下一個藍色系統。

A公司改進后的發布具體場景如下：

相同版本的產品分布在六個節點上運行，邏輯上分為a和b兩組，在發布時，首先把a組從負載均衡中摘除，執行a組的產品版本發布操作，b組仍然繼續提供服務，如下圖a組離線進行發布操作。

當a組升級完畢，負載均衡重新接入a組，再把b組從負載列表中摘除，進行新版本的發布。a組

重新提供服務，如下圖b組聯系進行發布操作。

最后，b組也升級完成，負載均衡重新接入b組，此時，a、b兩組版本都已經升級完成，并且都對能外提供服務。

（2）灰度發布（Canary releases）

金絲雀發布（Canary）也是一種發布策略，和國內常說的灰度發布是同一類策略。

藍綠部署是準備兩套系統，在兩套系統之間進行切換，金絲雀策略是只有一套系統，逐漸替換這套系統。

灰度發布，即讓一部分用戶繼續用老版本，一部分用戶開始用新版本，如果用戶對新版本體驗沒有太多的問題，相對穩定了，再逐步擴大到其他版本的生產線升級，也就是說把版本升升級按照用戶重要程度在一段周期內逐步平穩的都遷移到新版本上面來。

A公司結合用戶的3個分類，將生產線相應分類為3個集群。在上面實施了灰度發布的策略。

發布的難點在于需要對a、b、c三類客戶給與三個不同的身份標簽來確認用戶請求不同籃子的產品進行體驗。標注a/b/c三類不同的客戶屬性通常需要研發在產品設計階段完成，比如a/b/c客戶標簽分別為big、middle、small，那么客戶進入生產線統一登錄中心時，平臺會對請求的URL進行解析，如果解析到big關鍵字，則會讓該URL請求轉發到大客戶對應的業務集群中，因此，灰度發布的難點就是在研發設計初期就需要和產品共同考慮，并應對不同客戶對業務持續性和連續性的需求。如下圖為a/b/c不同客戶集群在一個負載均衡器中，如果a客戶需要升級版本，前提是b和c兩種類型的客戶已經升級完成，并運行了兩周，則可以進入a客戶的升級。

05環境一致性管理

環境一致性管理對開發環境、測試環境與生產環境所涉及到的業務關聯關系及網絡依賴關系的管理，這部分的管理難點在于生產環境屬于用戶實際使用的環境，是實際產生利潤來源的環境，所以，生產線上的投入的成本相對較高，基礎及應用設施大而全。而開發環境和測試環境基本是生產環境的縮小或者近似。

在實際變更中，上線發布失敗的很大一部分原因是因為測試環境與生產環境不一致導致的測試不完整或測試不一致。這里，環境不一致管理的難點不在于基礎設施本身，而是在于業務應用層。業務與業務之間的邏輯關聯關系決定環境管理的復雜度。而隨著業務版本迭代及業務的擴張，業務與業務的關聯關系變得愈發復雜。

基于變更管理流程中發現的問題，A公司經過不斷的探索，在環境一致性的管理做了很大改進。切入點是邏輯拓撲的動態管理。

A公司提出業務動態管理拓撲的方法是這樣：建立動態拓撲圖，任何的業務接口或者模塊的變更，動態拓撲都能清晰的看到他們之間的依賴，包括信息接口或者項目也能在動態拓撲上體現出來。業務關聯關系的拓撲圖如下：

上圖中的每個節點是服務器(server)。每個服務器，如svr-1，會包含幾個元素：主機名，IP地址，Port，接口名。與Srv1關聯的節點有哪些，都屬于哪些產品，哪些服務接口、模塊、端口信息等也會展現在圖上。每次變更后，拓撲圖都會更新。拓撲程序發現有新的端口或者應用上線，圖中的新組件則會顯示紅色，新增的與之關聯的也會自動變成紅色，待運維和研發人員確認后變成正常綠色狀態。

這樣，在變更申請中，通過拓撲圖來了解新的變更會影響哪些業務，會需要開放哪些網絡策略等，都比較清楚。

拓撲圖的動態維護是個關鍵。為了解決上線后拓撲更新的問題，A公司采用自動發現程序。自動發現程序有兩種方法實現，一個是在網絡層，通過網絡連接方式來動態實時獲取各個資產連接端口信息，并與業務建立關聯；另外一種是在應用層，就是通過APM的方式，對應用程序進行埋點，接口和接口相互調用信息可以通過埋點來獲取，并形成前后數據流關系。通過這樣的自動程序來發現上線后的服務連接的節點信息來實時更新拓撲，確保生產線的業務關聯關系拓撲永遠是最新的。

拓撲自動發現的程序設計的一個基礎是依托CMDB（配置管理庫）來定義資產（property）及其配置(configuration)，比如，每個資產運行哪些服務，每個節點運行哪些docker容器。同時，將變更管理的信息，包括配置改變（如網絡設備的ACL策略變更）、變更時間、業務影響等比較完整的信息，與CMDB結合，這樣就形成一個完整的閉環，得到一個全局的、完整的和實時的生產線運行信息。

06進一步的討論

從A公司的變更管理流程實施的經歷來看，我們可以學習到幾個關鍵點：

（1）通過變更控制，可以有效的降低變更給7x24生產線帶來的風險。

（2）通過變更管理，可以發現關聯的技術和管理上的問題。

（3）通過關聯的流程改進，如發布管理和環境一致性管理，可以有效的提高生產線變更的成功率。

A公司經過發布流程的改造，效率上有了很大的提升。客戶管理的群體通過單元化拆分來區別對待，從前端大客戶關系維護到后端的問題處理也變得順暢很多，單次發布的影響面降到最低，客戶基本無感知。發布過程中出現的問題也呈下降趨勢，服務的上下線就不再組織一個龐大的評審會來集中討論和整理業務的關聯關系，極大降低了各部門的溝通成本。

但是隨著A公司業務的成倍增長，發布管理及環境一致性管理變得越來也復雜，這直接體現在各服務產品模塊之間的接口設計及其相互調用。相應的運營成本也大幅度上升。首先，需要更多的單元去管理不同版本的產品線，不同群體客戶，這對成本上是一個挑戰；再次，越來越多的版本迭代，關聯關系拓撲的依賴關系變更復雜，經常出現同一個時間需要發布幾十個產品升級，依賴面變得更廣，關聯拓撲的更新變得不夠清晰化。后續需要引進AIOPS的算法來幫助維護復雜的運行中的生產線拓撲圖。

以上內容皆節選自《云計算和數據服務》這本書，書中采用理論與實踐相結合的形式，系統闡述云計算和大數據服務的具體實現。

云計算和大數據服務戰略的落地，包括技術構建和運營管理、新興的人工智能技術的應用，以及組織能力的建設。針對這一目標，全書分為七部分：云計算技術、大數據與數據智能、服務的技術運營、智能運營（AIOps）、安全技術與管理、服務質量管理和組織能力。寫作本書的目的是幫助讀者對云計算和大數據的重要專題從基本概念、發展思路到解決方案有一個系統認識。

本書具有非常強的可讀性和實踐指導意義，可作為云計算和大數據企業的高層管理人員和技術架構師的參考讀物，也可作為高校相關專業師生的教學參考用書。