張文

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

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

中圖分類號(hào)：TP391? ? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A? ? ?文章編號(hào)：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)階段運(yùn)維工具種類豐富，在單一運(yùn)維場(chǎng)景下能夠發(fā)揮較好的效果，但各運(yùn)維工具相互獨(dú)立，在數(shù)據(jù)、功能、流程等方面存在壁壘，難以形成合力來適配多樣化的運(yùn)維管理需求。鑒于上述情況，筆者從統(tǒng)一化、服務(wù)化的視角出發(fā)，完成了運(yùn)維工具體系的規(guī)劃、設(shè)計(jì)和建設(shè)，通過構(gòu)建新型的運(yùn)維工具體系，各運(yùn)維工具形成合力，發(fā)揮出了“1+1>2”的效果，提升了運(yùn)維工具的服務(wù)能力和用戶體驗(yàn)。

1 運(yùn)維工具體系總體設(shè)計(jì)

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

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

l 資源層表示被運(yùn)維工具體系管理的運(yùn)維對(duì)象。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 總結(jié)

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

參考文獻(xiàn)（References）：

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

[2] 騰訊.藍(lán)鯨智云PaaS平臺(tái)[EB/OL].https：//github.com/tencent/bk-paas/，2021

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

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

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

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