信息通信運行數據自主采集、智能分析關鍵技術研究及應用

國網寧夏電力有限公司信通公司 劉思堯 李雪松

安徽繼遠軟件有限公司 李 昂

1.項目概述

1.1 項目背景

隨著公司“十三五”信息化規劃的總體推進，公司逐步建成和完善“兩級調控、三層檢修、一體化運行、全業務支撐”的信息通信運維體系(SG-ITOM3.0)。同時，公司完成了運行維護-信息通信一體化調度運行支撐平臺（I6000）（四期）的建設，為公司電力信息運維工作提供了強大的支撐，保障了電網信息系統的穩定運行、高效運轉、全面支撐公司生產經營管理。在此期間，雖然電力信息通信技術得到了極快的發展，但是仍存在不足。支撐信息通信業務進一步融合發展，提升信息通信的運維管理水平，本項目在信息通信一體化調度運行支撐平臺基礎上，研究信息通信運行數據自主采集、故障檢測、風險預警、自動化運維及輔助決策等關鍵技術，并開發原型系統，通過構建統一的信息通信融合模型和自主標準化采集框架，提出信息通信運行故障監測與風險預警算法，實現信息通信業務系統的智能運維和主動檢修，提高信息運維水平、提高信息通信運檢效率，保障信息通信系統的運行質量和服務質量。

1.2 項目目標

隨著堅強智能電網建設深入開展，信息通信系統作為國家電網公司智能電網重要技術支撐和手段，面臨著新的問題和挑戰，業務應用需求主要表現在運行數據越來越繁雜多樣，運行管理必須從被動向主動轉變，提供科學智能的趨勢預測和主動預警，研究信息通信運行主動輔助決策技術，實現信息系統運維及部署的自動化，特別是版本升級的部署自動化，將運維人員從機械的、枯燥的可自動化完成的工作中解放出來，有效提高信息系統運維效率，降低運維成本，提升運維服務的質量，減少信息系統版本升級時帶來的風險。

通過本項目的實施，進一步支撐“兩級調度、三層檢修、一體化運行”的調運體系建設要求，實現對信息通信系統的集中管控、精益管理、高效運作，全面支撐堅強智能電網和“三集五大”管理體系建設。

1.3 項目研究內容

本課題主要研究業務系統智能化運維關鍵技術，包括研究信息系統版本自動升級的管理方法、技術規范；研究信息系統版本升級時數據庫腳本自動傳輸、執行、回滾、執行成功驗證技術；研究信息系統程序的自動傳輸、部署、回退、部署成功驗證技術；研究支撐信息系統多級部署的集中式版本自動升級管理技術平臺，集中管理各類信息通信系統的版本自動升級。

2.系統自動升級技術設計

2.1 總體架構

系統的總統架構如下圖所示：

圖2 -1 系統總體架構

通過系統的總體架構設計，利用好Docker容器技術、自動構建技術及Kubernetes技術實現應用系統從開發、測試、部署到升級的全過程自動化。系統研發人員利用Docker容器實現代碼的快速更新和部署，測試人員利用Docker容器的易復制性，能時刻保持和開發環境的一致，及時反饋測試結果。利用自動代碼構建工具保持代碼的持續發布，通過搭建鏡像服務器，將應用系統代碼以鏡像的方式存儲在鏡像倉庫中，現場人員即可通過鏡像倉庫快速部署系統，并利用Kubernetes技術實現對容器的集群化管理，快速地更新應用、擴展應用節點，保持系統的高可用性。

2.2 數據架構

數據架構中數據技術分類和數據部署設計，分別解決每一方面的關鍵問題，同時又相互支撐，互為補充，形成一個統一、有機的整體數據架構。數據技術分類和數據部署設計在數據模型的基礎上展開，按照不同的數據分類，結合系統架構的要求進行數據部署設計。

數據架構分類設計是基于信息系統版本的自動升級處理實踐，從設計角度將信息系統升級所需要的數據進行具體分類，并針對不同設計類別的數據特性采用不同的存儲方式和處理方式，以保證系統的處理性能、靈活性和可擴展性。

2.3 關鍵技術

在版本升級過程中，對于數據庫和程序很顯然需要考慮成功之后的驗證，以及未成功時的回退，尤其是回退如果不成功，將會影響到系統的正常訪問，這首先需要一套切實可行的規范的管理機制和流程，其次對于一個集中的版本管理平臺而言，如何統一規劃實現不同的信息通信系統通過數據庫腳本實現自動傳輸、執行、回滾、執行成功驗證，以及信息系統程序的自動傳輸、部署、回退、部署成功驗證，這是本科技課題的研究重點之一。

2.3.1 容器技術

Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然后發布到任何流行的Linux 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何接口。

Docker 使用客戶端-服務器 (C/S) 架構模式，使用遠程API來管理和創建Docker容器。Docker 容器通過 Docker 鏡像來創建。容器與鏡像的關系類似于面向對象編程中的對象與類。

Docker采用 C/S架構 Docker daemon 作為服務端接受來自客戶的請求，并處理這些請求（創建、運行、分發容器）。 客戶端和服務端既可以運行在一個機器上，也可通過 socket 或者RESTful API 來進行通信。

Docker daemon 一般在宿主主機后臺運行，等待接收來自客戶端的消息。 Docker 客戶端則為用戶提供一系列可執行命令，用戶用這些命令實現跟 Docker daemon 交互。

2.3.2 Linux Namespace

LXC所實現的隔離性主要是來自kernel的namespace, 其中pid,net, ipc, mnt, uts 等namespace將container的進程, 網絡, 消息, 文件系統和hostname 隔離開。

2.3.3 Control Groups

cgroups 實現了對資源的配額和度量。 cgroups 的使用非常簡單，提供類似文件的接口，在 /cgroup目錄下新建一個文件夾即可新建一個group，在此文件夾中新建task文件，并將pid寫入該文件，即可實現對該進程的資源控制。

2.3.4 AUFS

AUFS (AnotherUnionFS) 是一種 Union FS, 簡單來說就是支持將不同目錄掛載到同一個虛擬文件系統下(unite several directories into a single virtual filesystem)的文件系統，更進一步地，AUFS支持為每一個成員目錄(AKA branch)設定'readonly', 'readwrite' 和 'whiteout-able' 權限,同時AUFS里有一個類似分層的概念, 對 readonly 權限的branch可以邏輯上進行修改(增量地，不影響readonly部分的)。通常 Union FS有兩個用途, 一方面可以實現不借助 LVM， RAID 將多個disk和掛在到一個目錄下，另一個更常用的就是將一個readonly的branch和一個writeable的branch聯合在一起，Live CD正是基于此可以允許在OS image不變的基礎上允許用戶在其上進行一些寫操作。

3.系統自動升級技術實現

3.1 基礎鏡像管理

Docker是Docker.Inc公司開源的一個基于輕量級虛擬化技術的容器引擎項目，整個項目基于Go語言開發，并遵從Apache 2.0協議。通過分層鏡像標準化和內核虛擬化技術，Docker使得應用開發者和運維工程師可以以統一的方式跨平臺發布應用，并且以幾乎沒有額外開銷的情況下提供資源隔離的應用運行環境。

鏡像（Image）就是一堆只讀層（read-only layer）的統一視角，下面的這張圖展示了鏡像的定義。

圖3 -1 鏡像示意圖

從左邊我們看到了多個只讀層，它們重疊在一起。除了最下面一層，其它層都會有一個指針指向下一層。這些層是Docker內部的實現細節，并且能夠在主機（注：運行Docker的機器）的文件系統上訪問到。統一文件系統（union file system）技術能夠將不同的層整合成一個文件系統，為這些層提供了一個統一的視角，這樣就隱藏了多層的存在，在用戶的角度看來，只存在一個文件系統。 我們可以在圖片的右邊看到這個視角的形式。

3.2 應用鏡像管理

（1）應用封裝

應用封裝采用Docker做為應用容器引擎，Docker是輕量級虛擬化技術，它在標準的LXC之上融合AUFS分層鏡像管理機制，并以應用為單元進行“集裝封箱”，實現的相關應用封裝能力如下：

1）Docker容器技術可以部署應用到可移植的的容器中，這些容器獨立于硬件、語言、框架、打包系統，幫助實現持續集成與部署。一個標準的Docker容器包含一個軟件組件及其所有的依賴，包括二進制文件、庫、配置文件、腳本等。

2）Docker容器可以封裝任何有效負載，可以在任何服務器之間進行一致性運行。開發者構建的應用只需一次構建即可多平臺運行。

（2）應用鏡像管理

將應用進行封裝后，得到應用鏡像，和基礎鏡像類似，需要對應用鏡像進行統一的管理。

3.3 鏡像倉庫管理

Docker鏡像（Image）類似于虛擬機的鏡像，可以將他理解為一個面向Docker引擎的只讀模板，包含了文件系統。鏡像是創建Docker容器的基礎，通過版本管理和增量的文件系統，Docker提供了一套十分簡單的機制來創建和更新現有的鏡像。鏡像倉庫是Docker集中存放鏡像文件的場所。

3.4 應用發布管理

用戶直接指定相關版本的應用鏡像進行部署或升級，成功后，對應用的發布結果進行驗證，對驗證不通過的應用直接指定原版本鏡像進行回滾和還原。整個升級過程就是對應用鏡像的復制和運行，從而實現信息系統的快速部署，保證生產環境、測試環境和開發環境的一致。

3.5 應用升級/回滾管理

應用發布完成后，用戶可根據應用的版本進行升級或回滾，所用的kubernetes的命令為kubectl rolling-update。

kubectl rolling-update是一個非常重要的命令，對于已經部署并且正在運行的業務，rolling-update提供了不中斷業務的更新方式。rolling-update每次起一個新的pod，等新pod完全起來后刪除一個舊的pod，然后再起一個新的pod替換舊的pod，直到替換掉所有的pod。rolling-update需要確保新的版本有不同的name，Version和label，否則會報錯 。

3.6 應用擴容/縮容管理

應用發布完成后，應用的節點可根據需要或資源負荷進行調節，即為應用的擴容/縮容。所用的kubernetes的命令為kubectl scale。

Kubectl scale用于程序在負載加重或縮小時副本進行擴容或縮小，如前面創建的nginx有兩個副本，可以輕松的使用scale命令對副本數進行擴展或縮小。

圖3 -8 與I6000系統的集成

3.7 數據庫升級管理

信息系統版本自動升級完成后，若需要對數據庫進行相關升級，可首先對數據庫進行備份，然后執行升級腳本，對升級后的數據庫進行驗證，若升級失敗，則利用數據庫備份文件進行還原，實現數據庫的遠程自動化升級。

3.8 應用集成（圖3-8）

由于自動化部署系統采用B/S結構，產品本身提供豐富的Webservice接口/JMS接口，通過接口調用的方式，可實現與I6000系統的數據集成。自動化部署系統還提供Webservice接口/JMS接口來提取/發布包括應用系統信息、數據庫信息等在內的數據，自動化部署系統可通過調用相關接口來讀取I6000系統的基礎數據來實現同步與更新。

自動化部署系統對設備的管理有其自身的特點，初次進行設備納管時需以I6000系統中資源管理模塊（CMDB）為準提取IP、OS/IOS版本等基本配置信息。在日常運維中，系統定時進行設備信息采集，則以系統所搜集設備信息為準，對I6000中資源管理模塊（CMDB）進行同步與更新，對其數據項進行補充與更新，從而保證信息的完整與準確。

3.9 接口清單

對基礎鏡像和應用鏡像進行版本管理。基礎鏡像主要用于存儲信息系統運行所需的運行時庫（如JRE、.NETFramework等）和中間件（Tomcat、Weblogic等）的鏡像文件；應用鏡像主要用于存儲信息系統軟件的鏡像文件。

4.結論及建議

4.1 結論

實現信息系統運維及部署的版本自動化升級部署，將運維人員從機械的、枯燥的可自動化完成的工作中解放出來，有效提高信息系統運維效率，降低運維成本，提升運維服務的質量，減少信息系統版本升級時帶來的風險。

4.2 建議

工具化和標準化的運用程度是運維自動化發展水平提升的重要體現，逐步構建物理設備層、操作系統層、應用服務層、運維操作層的標準運維體系，實現以下目標∶

（1）運維自動化發展工具化：設計和利用各種小工具，促進標準化的實施，將可重復的操作簡單化，將多次操作流程化，減少人為操作的低效，降低故障率。

（2）運維自動化發展web化：設計研發完善的運維工作平臺，具備完善的權限控制，完備的日志記錄，弱化流程，實現統一平臺，標準化作業。

（3）運維自動化發展服務化（api化）：根據4層標準化運維體系，逐步設計和完善API，實現運維操作API化。

（4）運維自動化發展智能化：建立和完善觸發機制和決策系統（網絡神經系統），初步實現智能化的自動擴容、縮容、故障自愈等。

版本自動化升級僅僅是運維自動化發展的其中一點，更多的是以此為起點探索運維自動化發展的廣闊前景。運維自動化未來的發展方向是智能運維，隨著智能化技術的發展，智能運維的呼聲越來越高，目前國內智能運維發展還處于一個探索階段，要想盡快在智能運維領域有所突破，首先要主抓好監控系統和告警系統，并利用機器學習算法進行快速監控和排障。智能運維的發展一定是一個長期演進的過程，需要大量的投入和學習。