張文

摘? 要： 配置管理、監(jiān)控等運維工具軟件是數(shù)據(jù)中心運維管理工作的基礎(chǔ)，傳統(tǒng)商業(yè)運維工具軟件各自獨立，數(shù)據(jù)與流程不統(tǒng)一，難以滿足企業(yè)內(nèi)部流程、個性化場景對運維工具的需求。本文探討自主規(guī)劃和研發(fā)新型運維工具體系，在對現(xiàn)有工具優(yōu)化和提升的基礎(chǔ)上，通過API網(wǎng)關(guān)等技術(shù)實現(xiàn)運維工具的統(tǒng)一，并通過流程引擎技術(shù)促進運維服務(wù)化的落地。新型運維工具提升了運維管理工作效能與用戶體驗。

關(guān)鍵詞： 配置管理; 監(jiān)控; API; 流程引擎; 運維服務(wù)化

中圖分類號：TP391? ? ? ? ? 文獻標(biāo)識碼：A? ? ?文章編號：1006-8228（2022）06-130-04

Unionization and servitization

——the construction of a new operation tool system

Zhang Wen

（Shanghai Pudong Development Bank， Shanghai 200233， China）

Abstract： Software such as CMDB and monitoring is the basis of management of the data center. The data and processes of the traditional commercial software are not unified， which is difficult to meet the needs of the enterprise's internal requests. In this paper， a new operation and maintenance tool system is planned and developed. Base on the optimization and improvement of existing tools， the unification of tools is realized through API gateway and other technologies. On the other hand， the implementation of operation servitization is promoted through workflow engine technology. The new tool system improves the management efficiency and user experiences.

Key words： CMDB; monitoring; API; workflow engine; operation servitization

0 引言

現(xiàn)階段運維工具種類豐富，在單一運維場景下能夠發(fā)揮較好的效果，但各運維工具相互獨立，在數(shù)據(jù)、功能、流程等方面存在壁壘，難以形成合力來適配多樣化的運維管理需求。鑒于上述情況，筆者從統(tǒng)一化、服務(wù)化的視角出發(fā)，完成了運維工具體系的規(guī)劃、設(shè)計和建設(shè)，通過構(gòu)建新型的運維工具體系，各運維工具形成合力，發(fā)揮出了“1+1>2”的效果，提升了運維工具的服務(wù)能力和用戶體驗。

1 運維工具體系總體設(shè)計

統(tǒng)一化與服務(wù)化的運維工具體系總體架構(gòu)設(shè)計如下：

從圖1可知，服務(wù)型運維工具體系自底向上分為資源池、能力層、樞紐層、服務(wù)層，各層級的定位和用途如下。

l 資源層表示被運維工具體系管理的運維對象。

l 能力層包含基礎(chǔ)運維工具，向下管理實際的運維對象，向上提供標(biāo)準(zhǔn)的服務(wù)接口。

l 樞紐層是新型運維工具體系的核心，樞紐層通過建設(shè)API網(wǎng)關(guān)實現(xiàn)了運維工具的治理，通過流程引擎降低了運維服務(wù)建設(shè)的復(fù)雜程度。

l 服務(wù)層是服務(wù)型運維工具體系的關(guān)鍵，通過統(tǒng)一運維門戶實現(xiàn)了運維服務(wù)的整合，通過運維服務(wù)目錄和運維開發(fā)平臺的建設(shè)推進服務(wù)型運維工具體系的落地。

下文圍繞圖1進一步闡述運維工具體系統(tǒng)一化與服務(wù)化的落地方式。

2 統(tǒng)一化運維工具體系設(shè)計與實現(xiàn)

運維工具體系的統(tǒng)一化主要是通過整體的規(guī)劃、設(shè)計與建設(shè)，提升運維工具體系的服務(wù)能力，降低運維工具體系的建設(shè)成本。運維工具體系的統(tǒng)一化主要包含如下三方面內(nèi)容。

2.1 底層管理統(tǒng)一

在“煙囪式”的運維工具建設(shè)模式下，眾多工具都需要在客戶端安裝自己的Agent，每一種Agent都需要部署、維護和管理，成本非常高。本文采取如下方式解決了上述問題。

l 運維工具的Agent數(shù)量控制在兩個，兩套Agent相互管理，進一步實現(xiàn)了Agent級別的高可用。

l Agent通過兩（多）級代理的方式，適配了銀行生產(chǎn)環(huán)境嚴(yán)格的網(wǎng)絡(luò)管理的要求。

l 通過基于現(xiàn)有Agent開發(fā)框架自主研發(fā)，有效滿足了現(xiàn)階段的各項需求。

2.2 運維數(shù)據(jù)統(tǒng)一

2.2.1 配置數(shù)據(jù)

配置數(shù)據(jù)是數(shù)據(jù)中心的“數(shù)據(jù)孿生”，也是運維工具體系的核心[1]，配置數(shù)據(jù)的統(tǒng)一性與準(zhǔn)確性對運維工具體系至關(guān)重要。

⑴ 配置數(shù)據(jù)大集中，完整描繪運維對象。

配置數(shù)據(jù)不僅需要展現(xiàn)運維對象的技術(shù)特點，還應(yīng)兼顧運維對象的管理要求。另外，傳統(tǒng)的配置模型聚焦系統(tǒng)軟硬件配置，為適配技術(shù)發(fā)展趨勢，應(yīng)拓展至應(yīng)用、云平臺等方面。本文基于騰訊公司藍鯨智云軟件[2]，完成了一體化配置模型設(shè)計。

從圖2可知，數(shù)據(jù)中心的主要運維對象組織成了一個整體，通過配置數(shù)據(jù)的大集中，有效消除了配置數(shù)據(jù)的手工臺賬，為日常運維工作及其他工具建設(shè)夯實了基礎(chǔ)。

⑵ “生產(chǎn)”與“消費”雙輪驅(qū)動，提升配置數(shù)據(jù)準(zhǔn)確性。

配置數(shù)據(jù)在系統(tǒng)建設(shè)初期往往較為準(zhǔn)確，而隨著時間的推移，數(shù)據(jù)的質(zhì)量不斷下降。結(jié)合實戰(zhàn)經(jīng)驗，一是通過自動化方式采集技術(shù)類配置數(shù)據(jù)，二是通過對接運維流程來采集管理類配置數(shù)據(jù)，三是推廣配置數(shù)據(jù)的使用，反向促進配置數(shù)據(jù)質(zhì)量的提升。目前，實際配置模型近120個，配置實例超100萬條，關(guān)聯(lián)關(guān)系超過40萬條，主要運維對象配置數(shù)據(jù)時效性保持在分鐘級。配置數(shù)據(jù)已成為運維工具體系的數(shù)據(jù)標(biāo)準(zhǔn)，對運維服務(wù)化建設(shè)起到了關(guān)鍵作用。

2.2.2 監(jiān)控告警數(shù)據(jù)

監(jiān)控告警數(shù)據(jù)包含監(jiān)測采集數(shù)據(jù)、告警通知數(shù)據(jù)兩類，前者主要指CPU使用率等指標(biāo)類、系統(tǒng)/應(yīng)用日志等日志類數(shù)據(jù)，后者是指命中監(jiān)控策略與規(guī)則后需要處置的告警事件。監(jiān)控告警數(shù)據(jù)的處理流程如圖3所示。

⑴ 建設(shè)分布式數(shù)據(jù)采集平臺，滿足海量數(shù)據(jù)處理需求。

監(jiān)測采集數(shù)據(jù)體量大，時效性要求高，數(shù)據(jù)處理需求不斷增長。本文采用分布式數(shù)據(jù)處理架構(gòu)[3]，有效應(yīng)對海量數(shù)據(jù)處理場景。

l 不同區(qū)域的Agent將監(jiān)測采集數(shù)據(jù)上報至Proxy節(jié)點，Proxy服務(wù)器支持橫向擴展。

l Proxy服務(wù)器上報數(shù)據(jù)至管理服務(wù)器，管理服務(wù)器再根據(jù)數(shù)據(jù)種類等特征將數(shù)據(jù)發(fā)送至數(shù)據(jù)緩存節(jié)點。

l 數(shù)據(jù)緩存服務(wù)通過多套Kafka集群承載不同的數(shù)據(jù)流，可通過設(shè)置Partition數(shù)量增加單數(shù)據(jù)流的吞吐量。

l 數(shù)據(jù)處理服務(wù)根據(jù)不同的數(shù)據(jù)用途進行清洗、處理、存放。

上述架構(gòu)已支撐生產(chǎn)環(huán)境2萬節(jié)點的監(jiān)控數(shù)據(jù)采集功能，實際數(shù)據(jù)處理能力已達到400MB/s（含日志類數(shù)據(jù)），從數(shù)據(jù)采集到存儲控制用時在10s以內(nèi)，且平臺具備進一步的擴展能力。

⑵ 打造統(tǒng)一告警中心，提升告警有效性。

告警的有效性是衡量監(jiān)控告警能力的關(guān)鍵指標(biāo)之一。通過自研告警中心：一是廣泛接入軟硬件、機房、網(wǎng)絡(luò)等各類告警事件，實現(xiàn)告警事件的統(tǒng)一管理;二是告警通知人統(tǒng)一從CMDB查詢獲取，便于人員信息的統(tǒng)一維護管理;三是告警聚合與重復(fù)計數(shù)，提升告警有效性;四是通過基線閾值智能算法替代固定閾值算法，提升告警準(zhǔn)確率;五是對接自動化平臺、事件平臺等，提升告警處置效率，實現(xiàn)告警的閉環(huán)管理。

除配置及監(jiān)控兩類主要數(shù)據(jù)外，用戶數(shù)據(jù)等數(shù)據(jù)也需要統(tǒng)一維護管理，各運維工具統(tǒng)一同步獲取和使用。該類數(shù)據(jù)處理方式較為簡單，本文不再贅述。

2.3 標(biāo)準(zhǔn)功能統(tǒng)一

傳統(tǒng)架構(gòu)下，運維工具“煙囪式”建設(shè)，工具之間相互獨立，存在數(shù)據(jù)不統(tǒng)一、功能重復(fù)等問題，本文通過建設(shè)運維API網(wǎng)關(guān)[4]，實現(xiàn)了運維工具的有效整合與治理的目標(biāo)。一方面，運維工具將標(biāo)準(zhǔn)服務(wù)以API方式接入運維API網(wǎng)關(guān)（如圖1所示），另一方面，各個運維工具保持其API向下的兼容性，從而避免了工具自身升級換代等問題導(dǎo)致的與周邊工具的適配性等問題。運維API網(wǎng)關(guān)提供完善的管理功能，包括權(quán)限控制、流量控制、運行視圖等功能，便于API的管理和維護。目前各類運維工具接入的標(biāo)準(zhǔn)API近600個，范圍覆蓋各運維工具，已經(jīng)形成了較為完善的運維API生態(tài)，為上層運維服務(wù)化建設(shè)夯實了基礎(chǔ)。

3 服務(wù)化運維工具體系設(shè)計與實現(xiàn)

運維服務(wù)主要是指針對特定的運維場景，利用運維工具體系的各項能力，快速構(gòu)建的線上化、自動化、自助式的SaaS應(yīng)用，以提升運維管理工作效率和工作體驗。本文將運維服務(wù)目錄整體劃分為三級，具體90余項具體運維服務(wù)，摘錄如圖4所示。

服務(wù)和服務(wù)之間不是孤立的，而是可以有機的整合在一起，提供組合式服務(wù)[5]。以信息系統(tǒng)投產(chǎn)上線類變更為例，其涉及眾多部門及人員的參與，內(nèi)容多，耗時長，項目組往往并不能正確提出系統(tǒng)集成相關(guān)需求。針對此類通道，筆者組織研發(fā)了“集成需求”服務(wù)，如圖5所示。

該服務(wù)一是通過對系統(tǒng)集成工作的梳理，明確了“用戶知道哪些”和“管理員需要哪些”，通過集成需求的向?qū)教顖?，將用戶方和實施方進行了解耦。二是充分利用運維流程引擎[6]能力，將內(nèi)部管理流程從線下搬到線上，工作效率得到有效提升。三是通過與自動化相關(guān)API的結(jié)合，將集成需求轉(zhuǎn)換為對自動化API的驅(qū)動，變更耗時大幅降低，為應(yīng)用快速投產(chǎn)起到了顯著的促進作用。

運維服務(wù)建設(shè)通過組合各運維工具的基礎(chǔ)能力，實際發(fā)揮除了“1+1>2”的效果，降低了運維工具的使用門檻，實現(xiàn)了服務(wù)化運維工具體系的建設(shè)目標(biāo)。

4 總結(jié)

通過運維工具體系統(tǒng)一化與服務(wù)化的建設(shè)，改變了運維工具的建設(shè)模式，打通了運維工具的壁壘，盤活了運維工具的活力，充分發(fā)揮了運維工具的效能，為運維人員乃至總分行科技人員提供了良好的用戶體驗。后續(xù)將進一步圍繞統(tǒng)一化、服務(wù)化的建設(shè)思想，推進生產(chǎn)與開發(fā)測試環(huán)境的運維服務(wù)能力統(tǒng)一，全面提升運維服務(wù)化的廣度與深度，為傳統(tǒng)運維向智能化運維夯實基礎(chǔ)。

參考文獻（References）：

[1] 陳根.以配置管理為中心的運維工具體系建設(shè)研究[J].中國金融電腦，2021（4）：75

[2] 騰訊.藍鯨智云PaaS平臺[EB/OL].https：//github.com/tencent/bk-paas/，2021

[3] 戴炳榮，宋俊典，錢俊玲.云計算環(huán)境下海量分布式數(shù)據(jù)處理協(xié)同機制的研究[J].計算機應(yīng)用與軟件，2013，30（1）：107

[4] 邵歡慶，康建初.企業(yè)服務(wù)總線的研究與應(yīng)用[J].計算機工程，2007，33（2）：220

[5] 劉慧敏.以ITIL為基礎(chǔ)的IT服務(wù)管理應(yīng)用研究[J].計算機技術(shù)與發(fā)展，2012，22（5）：195

[6] 葛秀豪.基于SaaS模式的流程引擎和規(guī)則引擎服務(wù)模型研究[D].南京郵電大學(xué)碩士學(xué)位論文，2011