程仲漢 陳淑珍 丁強

（1.福建警察學(xué)院 計算機與信息安全管理系 福建省福州市 350007）

（2.網(wǎng)絡(luò)安全與執(zhí)法技術(shù)福建省高校工程研究中心 福建省福州市 350007）

在國家電網(wǎng)公司（簡稱國網(wǎng)）持續(xù)推進(jìn)建設(shè)新一代能源互聯(lián)網(wǎng)，力爭實現(xiàn)“一強三優(yōu)”的戰(zhàn)略背景下，信息通信運維支撐能力的重要性被賦予了更高的要求。由于國網(wǎng)軟硬件和網(wǎng)絡(luò)結(jié)構(gòu)的體量極其龐大且復(fù)雜，并具備特殊的層次性和多樣性，決定了其難以運用現(xiàn)成的互聯(lián)網(wǎng)公司運維體系。從央企橫向?qū)Ρ葋砜?，也沒有成功的自動化運維經(jīng)驗可以橫跨國網(wǎng)信息通信體系的四大層次，即電信層、IDC 層、應(yīng)用層、端層[1,2]。

2017年，國網(wǎng)提出要創(chuàng)新運維技術(shù)架構(gòu)，將信息通信運維從傳統(tǒng)人工模式向自動化、場景化、智能化模式轉(zhuǎn)變[3,4]。基于運維場景自動化的頂層設(shè)計SG-ITOM（State Grid-Information Telecommunication Operation Management）[5]應(yīng)運而生，目前已發(fā)展至3.0 版本。SG-ITOM 的核心思想是場景自動化，架構(gòu)上是將運維過程解耦在不同的中心子系統(tǒng)完成，每個中心各司其職，這樣就可以將各個網(wǎng)省子公司分散雜亂的運維工作納入統(tǒng)一管理。但是，頂層設(shè)計只能用于指導(dǎo)思想和制定標(biāo)準(zhǔn)，支撐場景自動化目標(biāo)需要實際的系統(tǒng)產(chǎn)品。因此，本文針對SG-ITOM 3.0 的核心子系統(tǒng)工具中心提出系統(tǒng)設(shè)計，闡述系統(tǒng)的目標(biāo)定位、功能設(shè)計和技術(shù)架構(gòu)，進(jìn)一步細(xì)化了頂層設(shè)計并推進(jìn)其實用化，可為日后的系統(tǒng)設(shè)計與研發(fā)奠定基礎(chǔ)。

1 SG-ITOM場景自動化

如圖1 所示，SG-ITOM 場景自動化的思想是將傳統(tǒng)的運維操作編排為場景，以場景為主體，以運維對象為客體，由手動執(zhí)行或規(guī)則觸發(fā)的方式執(zhí)行。當(dāng)軟硬件發(fā)生狀態(tài)變化（如服務(wù)器負(fù)荷過大）時，觸發(fā)對應(yīng)的運維場景（擴容場景），并調(diào)用相應(yīng)的工具或指令（擴展集群節(jié)點）完成自動化運維。SG-ITOM 共包括八大中心子系統(tǒng)，其中場景中心和工具中心是整個頂層設(shè)計的核心模塊。場景中心是連接其它中心的命令樞紐，并調(diào)用工具中心完成實際的工作。工具將自動化運維工作抽象為比場景更細(xì)粒度的單元，工具中心是統(tǒng)一管理運維工具的平臺。

2 工具中心概述

2.1 工具定義

工具是用于實現(xiàn)某個運維專項功能如web 應(yīng)用部署、主機巡檢等，且以運維對象或數(shù)據(jù)為操作客體的腳本、Docker 容器[6]或agent（主機代理）。一般來說，執(zhí)行邏輯比較簡單的程序以腳本形式來編寫，而難以用腳本語言實現(xiàn)的工具則封裝在Docker 容器里。前者通過agent 指令通道來調(diào)度運行，并操作運維對象。后者通過運行在集中的容器云中并對外提供服務(wù)如web service，進(jìn)而間接地影響運維對象。工具按照不同的功能大體分為12 類，如圖2 所示。

2.2 工具中心目標(biāo)

圖1：SG-ITOM 場景自動化的總體流程圖

圖2：各類工具示例圖

圖3：工具中心的運行流程圖

圖4：工具中心的功能架構(gòu)圖

圖5：工具中心的技術(shù)架構(gòu)圖

作為SG-ITOM 3.0 的核心技術(shù)支撐架構(gòu)，工具中心在功能和技術(shù)方面規(guī)范化運維工具的準(zhǔn)入機制、管理標(biāo)準(zhǔn)、運營標(biāo)準(zhǔn)以及計費標(biāo)準(zhǔn)，統(tǒng)一管理國網(wǎng)各單位的運維組件，避免重復(fù)建設(shè)。圖3 給出工具中心作為SG-ITOM 中的子系統(tǒng)之一的運行流程。如圖3 所示，工具的執(zhí)行是通過場景中心調(diào)用工具中心指定的工具來觸發(fā)，實現(xiàn)運維的專項功能，進(jìn)而作用于運維對象得到用戶想要的結(jié)果。工具在準(zhǔn)入環(huán)節(jié)就應(yīng)按照接口規(guī)范對外提供相應(yīng)API 描述和輸入輸出參數(shù)說明，以便場景中心來統(tǒng)一調(diào)用。

工具中心的管理范圍包括兩個層面：

（1）執(zhí)行層面。將工具在執(zhí)行環(huán)境中上線啟動，供用戶和場景中心調(diào)用。

（2）運營層面。借鑒互聯(lián)網(wǎng)軟件的運營模式，如蘋果公司的應(yīng)用商店，建立工具從注冊上線、審核、發(fā)布、評價、計費、下線的整個生命周期。

工具中心建設(shè)的總體目標(biāo)如下：

（1）統(tǒng)一準(zhǔn)入標(biāo)準(zhǔn)。工具中心統(tǒng)一所有運維工具的準(zhǔn)入機制，包含各類運維工具的注冊和審核，統(tǒng)一工具發(fā)布的入口，保證將來工具使用的合規(guī)性、安全性和可用性。

（2）工具統(tǒng)一管理。工具中心對運維工具進(jìn)行統(tǒng)一的全生命周期管理，統(tǒng)一不同廠家、不同工具的交付形式，簡化部署過程，簡化配置，簡化工具的升級，規(guī)范工具的版本及下線管理。

（3）統(tǒng)一執(zhí)行接口。為工具制定統(tǒng)一的調(diào)用接口。這樣，在標(biāo)準(zhǔn)的自動化運維場景腳本的支持下，就可以通過場景中心作用于工具之上，實現(xiàn)“一次編排，到處部署”。此外，通過配置引擎及監(jiān)控功能實現(xiàn)工具根據(jù)負(fù)載情況進(jìn)行動態(tài)伸縮，提高工具的可用性。

3 功能設(shè)計

如圖4 所示，工具中心為兩級部署架構(gòu)，一級工具中心作為國網(wǎng)統(tǒng)一工具倉庫，是各二級工具中心的通用工具權(quán)威源，負(fù)責(zé)整個國網(wǎng)的通用工具統(tǒng)一準(zhǔn)入和全生命周期管理。二級工具中心為各網(wǎng)省公司的工具倉庫，存放來自一級工具中心的通用工具，負(fù)責(zé)各網(wǎng)省自建工具的準(zhǔn)入、全生命周期管理，并作為工具最終的運行平臺，對外提供工具調(diào)用及監(jiān)控服務(wù)。因此，部署在不同層級，系統(tǒng)的功能有所差異，具體包括以下一級功能：

（1）工具準(zhǔn)入。為自動化工具的上傳注冊、審核、發(fā)布提供功能支持，保障進(jìn)入工具中心的工具的安全性和規(guī)范性。

（2）工具管理。為已經(jīng)發(fā)布的運維工具提供全生命周期管理，包括工具的展現(xiàn)、搜索、下載、描述編輯、下線、刪除、更新和版本管理等基本管理功能。另外，二級工具中心功能上支撐場景中心對工具的調(diào)用、啟停、腳本類工具的執(zhí)行。

（3）運行管理。僅存在于二級工具中心，負(fù)責(zé)響應(yīng)場景中心對工具的調(diào)用，包括工具的分發(fā)啟停、運行資源調(diào)控以及對工具運行狀態(tài)、操作執(zhí)行進(jìn)度進(jìn)行監(jiān)控。

（4）工具評價。支持用戶對工具發(fā)表文字評論和打分評價，其中打分評價將作為精品推薦功能的主要依據(jù)指標(biāo)。

（5）工具計費。支持多種方式計費，并支持后續(xù)計費方式的擴展，在結(jié)算環(huán)節(jié)提供多種支付方式，支持接入第三方支付平臺。

（6）統(tǒng)計分析。支持對工具下載量進(jìn)行下載排行，依據(jù)工具下載量、使用量、評分等進(jìn)行同類工具的精品推薦，支持日志記錄用戶在工具中心的操作行為。

4 技術(shù)架構(gòu)

系統(tǒng)在技術(shù)架構(gòu)上分為接入層、傳輸層、存儲層、執(zhí)行層和業(yè)務(wù)層，圖5 給出系統(tǒng)的分層次技術(shù)架構(gòu)圖。

4.1 接入層

接入層提供各類工具接入的標(biāo)準(zhǔn)及規(guī)范，并為各類工具的接入提供統(tǒng)一的接入服務(wù)。接入層是所有工具的接入到工具中心的統(tǒng)一入口，按照工具的特性提供腳本類工具接入和容器類工具接入服務(wù)，并完成工具接入過程中的各種標(biāo)準(zhǔn)規(guī)范、安全性等的審核及檢測，從而實現(xiàn)工具接入的流程化和標(biāo)準(zhǔn)化，保證接入工具的安全性。

各類工具按照工具中心的準(zhǔn)入管理規(guī)范，將工具相關(guān)文件，包括程序包、腳本、Docker 鏡像、工具描述語言TDL（Tools Describe Language）、工具附屬文件等進(jìn)行統(tǒng)一打包，通過接入層上傳。對于接入的工具，接入層通過工具審核服務(wù)對工具進(jìn)行審核（包括由審核專家人工審核以及通過機器進(jìn)行自動化測試）。對于符合接入條件的工具，接入層調(diào)用傳輸層提供的數(shù)據(jù)傳輸服務(wù)，將工具相關(guān)文件數(shù)據(jù)發(fā)送給存儲層。對于Docker 容器類工具，接入層的容器封裝模塊負(fù)責(zé)將Docker 容器類工具的程序包及其依賴的運行環(huán)境封裝為工具鏡像。

4.2 傳輸層

傳輸層用于支撐工具中心內(nèi)部控制命令和文件數(shù)據(jù)的傳輸、接入層與存儲層之間的工具介質(zhì)數(shù)據(jù)傳輸、工具倉庫與工具執(zhí)行環(huán)境之間的部分工具數(shù)據(jù)交換以及業(yè)務(wù)層與后臺的數(shù)據(jù)交換。傳輸層需要使用文件加密技術(shù)保證數(shù)據(jù)傳輸過程中的安全性，同時通過數(shù)字簽名技術(shù)保證文件傳輸過程中的完整性。

傳輸層根據(jù)工具介質(zhì)數(shù)據(jù)的大小等特性，主要提供兩種數(shù)據(jù)傳輸服務(wù)：

（1）消息中間件服務(wù)。主要為控制命令、腳本文件等數(shù)據(jù)量比較小的數(shù)據(jù)提供傳輸服務(wù)，推薦采用市面上主流的消息中間件技術(shù)實現(xiàn)，如RabbitMQ、ActiveMQ、ZeroMQ 等。在消息傳輸?shù)募夹g(shù)選型上，需要綜合考慮準(zhǔn)確性、實時性、可擴展性，以及消息服務(wù)器主備方案（例如使用三臺消息服務(wù)器兩兩互為主備），以防單點失效。

（2）文件傳輸服務(wù)。主要為容器等數(shù)據(jù)量比較大的工具介質(zhì)數(shù)據(jù)提供傳輸服務(wù)，其協(xié)議由存儲層的技術(shù)路線來決定。

4.3 存儲層

存儲層通過傳輸層接收接入層傳輸?shù)臄?shù)據(jù)，并集中存儲三類數(shù)據(jù)：工具介質(zhì)數(shù)據(jù)、工具運行的過程數(shù)據(jù)以及工具中心自身的業(yè)務(wù)數(shù)據(jù)。根據(jù)不同的數(shù)據(jù)類型，存儲層在技術(shù)路線設(shè)計上需要考慮數(shù)據(jù)存儲的可用性、擴展性以及數(shù)據(jù)存取性能。

工具介質(zhì)指的是工具文件以及工具啟動所必須的文件，將其按工具的來源地區(qū)、廠商、功能分類、名稱和版本號等作為目錄結(jié)構(gòu)來分級存儲不同工具的介質(zhì)。按工具的運行方式，工具介質(zhì)可分為四類：Docker 鏡像、程序包文件、腳本文件以及附屬文件（如TDL、數(shù)據(jù)庫初始化腳本、相關(guān)文檔等，列于工具文件清單中）。Docker 鏡像分塊存儲于鏡像倉庫中，而其它介質(zhì)數(shù)據(jù)作為啟動容器的基礎(chǔ)數(shù)據(jù)，數(shù)據(jù)量較為龐大（TB 級），因此采用分布式文件系統(tǒng)HDFS 作為公共存儲以擴展其存儲能力。

對于工具（主要是容器類工具）運行過程中的數(shù)據(jù)，細(xì)分為結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。前者可存儲于Oracle 或Mysql 中，后者可存儲于NFS 服務(wù)器或CephFS 服務(wù)器。工具通過遠(yuǎn)程掛載技術(shù)或文件傳輸協(xié)議與外部的文件系統(tǒng)交換數(shù)據(jù)。由于在執(zhí)行層中運行的工具數(shù)量很多，涉及的運行數(shù)據(jù)量也很龐大，所以在數(shù)據(jù)庫和文件存儲方面還需要考慮數(shù)據(jù)的高并發(fā)讀寫能力和實時處理能力。

4.4 執(zhí)行層

存儲層管理的工具介質(zhì)可視為工具的靜態(tài)形式，執(zhí)行層則是管理工具正式上線并執(zhí)行后的動態(tài)形式?；诖鎯又械墓ぞ呓橘|(zhì)及其附屬的啟動配置文件等，工具中心將工具啟動，并為場景中心提供接口服務(wù)。場景中心根據(jù)工具TDL 文件，傳入?yún)?shù)并調(diào)用工具中心的執(zhí)行層來執(zhí)行工具并獲取執(zhí)行結(jié)果。執(zhí)行層部署于各地網(wǎng)省，由各子公司為其提供和維護(hù)相應(yīng)的私有云資源。

根據(jù)工具類型，執(zhí)行層有幾種表現(xiàn)方式：

（1）工具容器PaaS 平臺?；贕oogle Kubernetes[7]實現(xiàn)，各個工具及其運行環(huán)境以封裝于一體的Docker 容器形式來運行，且互相隔離。提供相同服務(wù)的工具可協(xié)同并行，以容器集群的方式對外提供統(tǒng)一的REST 接口服務(wù)。容器集群的資源管理、容器調(diào)度、安全控制、運行監(jiān)控、請求路由等功能都由Kubernetes 的底層機制完成。容器內(nèi)部與存儲層中的工具運行數(shù)據(jù)的交互采用Docker 文件遠(yuǎn)程掛載方式。

（2）由統(tǒng)一Agent 執(zhí)行腳本，執(zhí)行層通過向Agent 端推送腳本，并由其執(zhí)行。

（3）指令通道，通過安全協(xié)議遠(yuǎn)程執(zhí)行終端指令。

此外，運行中的工具通過與存儲層、安全中心、審計中心、日志中心、監(jiān)控中心、資源配置中心等進(jìn)行直接交互或間接交互，讀寫其相應(yīng)中心的數(shù)據(jù)。

4.5 業(yè)務(wù)層

業(yè)務(wù)層基于統(tǒng)一服務(wù)的業(yè)務(wù)框架層實現(xiàn)面向各類角色的應(yīng)用服務(wù)，實現(xiàn)工具中心的各種功能。業(yè)務(wù)層及其底層服務(wù)的開發(fā)需要符合國網(wǎng)統(tǒng)一要求，需采用技術(shù)統(tǒng)一、架構(gòu)柔性、性能高效、安全可靠的企業(yè)級信息系統(tǒng)基礎(chǔ)框架和公共組件集[8]。業(yè)務(wù)間在設(shè)計上應(yīng)為松耦合，且各個業(yè)務(wù)都支持組件式插拔，以便工具中心將來的業(yè)務(wù)功能擴展。

業(yè)務(wù)層將工具中心的數(shù)據(jù)和業(yè)務(wù)邏輯以REST 的形式統(tǒng)一封裝，以RESTful API 的形式對外提供統(tǒng)一的接口服務(wù)，由前端或其他業(yè)務(wù)模塊調(diào)用。

5 結(jié)語

工具中心是國網(wǎng)信息通信運行管理頂層設(shè)計SG-ITOM 的核心子系統(tǒng)，與場景中心共同構(gòu)成了場景自動化的關(guān)鍵模塊。它可以將各種運維工具進(jìn)行標(biāo)準(zhǔn)化的閉環(huán)管理，并提供統(tǒng)一的執(zhí)行環(huán)境和接口，以便被場景中心調(diào)用，從而實現(xiàn)運維模式向場景自動化轉(zhuǎn)變。本文基于SG-ITOM 3.0 提出工具中心的具體設(shè)計，包括功能架構(gòu)和技術(shù)架構(gòu)，可為研發(fā)單位在系統(tǒng)的具體實現(xiàn)時提供思路和依據(jù)。