云環境下業務不停機檢修方法

張磊，劉軍，晁凱，張敏杰，吳垠，劉賽

（1.南瑞集團有限公司（國網電力科學研究院有限公司），南京210003；2.南京南瑞信息通信科技有限公司，南京210003）

0 引言

近期，國家電網有限公司完成云平臺建設，并進入常規運營階段[1-2]。隨著多個重要業務系統遷移上云，業務部門對平臺提出下一步工作的推進要求[3-4]。如何發揮云平臺在不停運、無感知檢修的先天優勢，提高自動化、智能化作業水平，推進傳統業務、云上業務無感檢修成為當前云平臺運營工作中重點的研究任務[5-6]。

1 電力云計算平臺

國家電網公司通過云平臺建設，構建了新一代信息基礎設施平臺，帶動了公司的IT 資源和數據資源的建設，應用運維向“企業級”轉型，實現了強大的平臺架構，強大的支持和響應敏捷性，全局資源調度，靈活的共享和高效的應用[7-8]。

云平臺和數據中心堅持“企業級”建設，協調公司的規劃，建設和運營，實現公司IT 資源，數據資源和系統服務的“企業級”共享應用[9-10]。電網業務系統逐步遷移上云，相關的軟硬件資源由云平臺按需提供，不再根據系統進行配置，將公司的數據資源統一到公司的數據中心管理中，構建全網一朵云架構，形成一個“IT 資源服務中心”和一個“數據服務中心”，實現總部與省公司操作兩級協同[11-12]。全網一朵云平臺如圖1 所示。

圖1 全網一朵云平臺

2 不停機檢修方案

2.1 構建穩定的云平臺

方法和目的：擴容云平臺資源池，保證資源后備充足，分配率警戒線75%，保證資源穩定、足額、高利用率供給。重要措施：推進資源監控、資源統計、容量預測工作，嚴格執行資源申請開通、變更、回收機制，建設云平臺組件健康管理指標體系，達到事先健康評估和故障、隱患發現的效果，以不停機檢修工作為契點，建設全自動化業務系統檢修機制，降低人為故障率。資源健康管理系統的框架如圖2 所示。嚴格按照操作計劃的內容執行日常操作，并在日常工作的閉環中反饋有關組件優化，問題消除和云咨詢工作的補充建議。將云平臺資源運作流程制度化，建立云業務結構和資源應用的評審流程，逐步制定評審標準。

圖2 資源健康管理系統的框架

2.2 無感知檢修

結合云平臺Devops 解決方案和非感知實現的應用程序發布，主要從業務系統的服務系統的角度研究在不停止服務的情況下如何進行維護工作的策略和計劃。并且用戶不知道，并且對現有的維護對象進行了大修。標準化操作程序和實施計劃的流程準備。

在發布過程中，用戶不會感知到服務的重啟，這通常是通過新舊版本的共存實現的，也就是說，在發布過程中，新版本和舊版本是相互備用的通過切換路由權重的方式（不是0 或100）實現不同應用程序的聯機或脫機，在不中斷業務的情況下完成可視化的一鍵式灰色釋放，并且可以在升級期間隨時回滾到舊服務流程，以確保升級安全。無感知檢修過程如圖3 所示。

圖3 無感知檢修過程

通過不間斷的維護，在不影響用戶正常工作的情況下，實現了不間斷維護工作的應用服務保證。確保業務系統安全、穩定、高效的運行，大大提高了前端用戶的系統體驗價值，增強了客戶的黏度，解決了系統維護中業務不暢的問題。

3 實驗驗證

通過實驗，對應用服務進行了不間斷檢修。驗證方案包括ECS 加SLB 大修方案，CS 加SLB 大修方案，CS 服務單批大修，CS 服務批大修，CS 微服務大修以及微服務配置中心配置大修。

3.1 ECS加SLB檢修場景

SLB 負載權重用于控制訪問請求訪問的ECS 服務。升級資源統計服務時，可以通過調整負載均衡負載來實現。其他內部服務不允許直接訪問ECS IP 地址，必須通過SLB 訪問，否則將無法實現不間斷運行檢查。

根據云平臺資源部署服務，具體如下ECS_IP：25.50.146.204、25.50.146.203，ECS 服務端口：18080，SLB_IP-PORT：25.50.15.17-8081。確認兩個ECS 的服務正常，確認SLB 負載正常，兩個ECS 的負載權重為100，請訪問http://25.50.15.17:8081，請求將被隨機發送到兩個ECS 比例為1:1 時，服務正常，可以通過調整重量來更改比例。

測試正常后，將重量調回100，或逐漸調整。這時，用戶將隨機訪問版本1 或版本2 的服務。如果確定版本2 正常，則可以選擇快速調整204 的權重，而203 將直接接管請求。檢查SLB 入口http://25.50.15.17:8081的服務是否正常，所有請求將被203 接管。

至此，該服務的大修已經完成，在此過程中，仍有一些服務提供不間斷的服務來滿足不間斷的大修要求。維護操作版本升級或自包含配置修改等。通過SLB 負載切換方法可以實現業務應用程序的不間斷維護要求。檢修過程的結果如圖4 所示。

3.2 CS服務檢修

該服務部署的CS 服務通過SLB 端口公開該服務。CS 服務中有多個容器組副本。理論上，當需要對應用程序進行大修時，只需要替換容器組副本的內容即可。具體操作主要涉及負載的控制。CS 服務的容器組副本需要在版本維護開始時刪除負載，并在維護完成并通過測試后自動添加負載。

圖4 無感知檢修結果

單批部署是完整的更新版本，業務將中斷，并且無法進行停機維護和驗證。

批量檢查CS 服務，并通過SLB 端口公開該服務部署的CS 服務。CS 服務中有多個容器組副本。當需要對應用程序進行大修時，理論上只需要替換容器組副本的內容。具體操作主要涉及負載的控制。CS 服務的容器組副本需要在版本維護開始時刪除負載，并在維護完成并通過測試后自動添加負載。

在DEMO 描述和驗證中，只能批量部署多副本應用程序（滾動部署）。在v1 和v2 的過程中，需要驗證是否按要求刪除和增加了負載，如果v2 版本存在問題，驗證系統自己的處理方法，驗證容器服務是否正常，然后進行部署批量升級到v2 版本。在執行期間，容器組將等待新版本啟動，然后替換舊版本。應用程序本身可以通過設置批處理間隔來有效地完成不間斷維護。在此過程中，可以隨時啟動回滾操作。驗證在容器啟動失敗，上載失敗的映像v3 并啟動批處理部署時，是否可以完成升級部署。可以看出，已識別出異常圖像：容器本身的負載也從該版本中自動刪除，并且只有5 個負載地址。繼續等待，看看是否觸發了下一批更新。5 分鐘后，仍然不會觸發更新。失敗的鏡像無法正常釋放。此時，可以將所有副本回滾到原始版本。完成后負載將還原到6 個節點。最終結論是容器服務的批量部署可以完成不間斷的維護要求。

4 結語

通過對試點業務系統不間斷維護工作的研究，提出了云平臺維護工作的內容，對云平臺維護方法進行了合理性評估，并將云平臺Devops 解決方案與非平臺維護相結合。從業務系統的服務角度出發，對應用程序發布的看法，提出了在服務不停止，用戶不知情的情況下云平臺維護工作的策略和實施方法，進一步規范了操作流程和實施計劃以及準備現有維護對象維護過程的方法。下一步將對云平臺微服務應用程序的整個生命周期管理系統進行研究。