摘要：論文主要探索圖技術在銀行數(shù)據(jù)中心的配置管理中的應用新思路。通過可視化建模、自動化采集、關系解析、圖數(shù)據(jù)庫存儲等技術手段實現(xiàn)了銀行數(shù)據(jù)中心雙模的運維對象配置管理，為數(shù)據(jù)中心的業(yè)務連續(xù)性提供了支撐，為數(shù)據(jù)中心的標準化管理提供了思路。

關鍵詞：數(shù)據(jù)中心;配置管理;圖技術;自動化

1、背景及意義

在互聯(lián)網(wǎng)時代，銀行數(shù)據(jù)中心所有的資源都呈現(xiàn)服務化的趨勢，如何實時反應線上服務狀態(tài)變化變得尤為重要，同樣配置管理（下文統(tǒng)稱CMDB）所記錄的信息狀態(tài)更需要實時同步。數(shù)據(jù)中心的服務主要分為兩種：

1、分層服務支撐。把基礎設施、基礎硬件、基礎軟件、基礎平臺變成服務，從服務構建到服務運行再到服務運營平臺，針對的是不同的領域，提供的是不同層面的資源支撐。

2、體系服務交互。包含兩種形態(tài)，一種是傳統(tǒng)的應用架構模式，一種是關于運維體系比如自動化體系、監(jiān)控體系、流程體系。

CMDB在ITIL時代是元數(shù)據(jù)平臺，傳統(tǒng)的CMDB所服務的IT服務過程是一種離線服務過程，不能夠?qū)崟r地訪問線上變化。所以傳統(tǒng)CMDB起到的作用相對較小，這就直接導致在數(shù)據(jù)中心運維過程中并未對CMDB的數(shù)據(jù)進行消費，流程和流轉(zhuǎn)在大多數(shù)情況下可以脫離CMDB來做。過去元數(shù)據(jù)平臺的定位運營不起來主要是對于它的依賴度太低，根本原因是非實時數(shù)據(jù)。

傳統(tǒng)CMDB除了實時性要求不高，還存在信息關注點偏移和范圍嚴重擴散的問題：傳統(tǒng)CMDB更側(cè)重于資產(chǎn)管理，而非資源管理，這就導致傳統(tǒng)的CMDB不能夠被真正的一線運維人員所使用，基本上都變成臺賬資產(chǎn)管理系統(tǒng);由于ITIL的一些傳統(tǒng)理念需要將所有的配置信息進行收集，這就導致配置信息管理邊界過于擴散，大量的無用配置信息也干擾了配置信息的消費。

金融科技發(fā)展迅速，新的服務理念需要更加高效完備的服務能力，分層服務支撐和運維體系服務交互對數(shù)據(jù)消費的實時性要求越來越高，所以以服務為導向的強實時的CMDB變得尤為重要;另一方面CMDB的建設不能再以單獨的形式進行，配置信息的有效性一定是與消費場景相關，沒有需求就沒有供給，所以以場景為導向的配置信息管理建設是重要原則，場景可以明確配置信息的范圍，避免了過多無用信息。

2、關鍵技術分析

2.1、自動化采集

配置信息主要分為環(huán)控、基礎軟硬件、應用系統(tǒng)、業(yè)務系統(tǒng)四個部分，其中環(huán)控的部分信息可以通過物聯(lián)網(wǎng)的RFID技術來實現(xiàn)自動化采集;基礎軟硬件部分的配置信息接口比較成熟，可以通過API、腳本編寫、AGENT等實現(xiàn)足夠高的自動化采集;應用系統(tǒng)的配置信息需要通過梳理才能確定自動化采集的程度;業(yè)務系統(tǒng)的配置信息采集需要通過流程輸入。

2.2? 關系解析

配置信息的關聯(lián)關系分析是實現(xiàn)的關鍵，這部分技術含量最高。首先需要能夠?qū)?shù)據(jù)中心的整體架構深入了解，包括環(huán)控、基礎軟硬件、應用、業(yè)務各個方面以及幾個層面之間的關聯(lián)方式。這個模塊是成敗的關鍵。配置信息可以通過收集來匯總，但是配置信息的關聯(lián)關系一定是需要多方討論、統(tǒng)一建模、約定規(guī)范、自動解析幾個步驟才能提取出來。

2.3? 圖數(shù)據(jù)庫

2.3.1 圖數(shù)據(jù)庫性能評估

圖數(shù)據(jù)庫能夠提供百萬級實體、千級關系的數(shù)據(jù)存儲及每日十萬級的數(shù)據(jù)更新（CMDB的規(guī)模在10*1萬級實體、100萬級關系）;能夠提供全系統(tǒng)聯(lián)機服務在50并發(fā)（參考數(shù)據(jù)中心運維人員數(shù)量）下，2度查詢耗時在1秒以內(nèi);百萬級實體、千萬級關系的數(shù)據(jù)導入耗時在半小時以內(nèi)（包括索引建立）;單條級數(shù)據(jù)更新耗時在毫秒級（包括索引建立）;支持在實體、關系的屬性上的索引建立以提供高效的查詢，任意屬性查詢耗時在毫秒級;支持全文檢索功能。

2.3.2 圖數(shù)據(jù)庫容量評估

銀行中等數(shù)據(jù)中心的配置管理的規(guī)模：節(jié)點數(shù)量十萬級、關系數(shù)量百萬級、節(jié)點屬性20個、關系屬性5個、歷史記錄5個。整體容量在5GB。

2.3.3 圖數(shù)據(jù)庫高可用機制

圖數(shù)據(jù)庫需要實現(xiàn)生產(chǎn)級的高可用機制，節(jié)點數(shù)量至少3個，滿足宕機恢復時間在秒級。

2.3.4 圖數(shù)據(jù)庫接口

圖數(shù)據(jù)庫需支持數(shù)據(jù)規(guī)模的存儲、查詢、路徑發(fā)現(xiàn)、關系遍歷，查詢、路徑發(fā)現(xiàn)、遍歷的條件應支持包括但不限于實體屬性、邊屬性、邊方向、遍歷度數(shù)的組合;組合方式應支持基本關系運算;圖數(shù)據(jù)庫需支持多類型實體，有向邊;需支持兩實體間多種類型的關系;需支持兩實體間同類型關系建立多條邊;需支持列表、字典、集合等復雜屬性類型;圖數(shù)據(jù)庫提供的操作方式、查詢方式需保證通用性以支持應用的可移植性;需提供圖數(shù)據(jù)建模功能，并提供相應工具，支持 csv 文件導入數(shù)據(jù)，支持從數(shù)據(jù)庫中提取實體，構建關系;圖數(shù)據(jù)庫需提供數(shù)據(jù)批量導出功能（csv）。

2.3.5 圖算法

圖數(shù)據(jù)庫需要預置若干常用圖算法（如連通圖、強連通圖、最短路徑、數(shù)三角形、標簽傳播、社群分析、PageRank、頻繁子圖等），并提供這些算法的參數(shù)調(diào)整接口或配置;圖數(shù)據(jù)庫需要提供自定義圖算法的集成接口，規(guī)范好輸入和輸出，第三方根據(jù)接口開發(fā)出相應的算法，可以簡單地集成到平臺中，就可以對圖譜進行算法的挖掘。

2.4? 可視化建模工具

圖數(shù)據(jù)庫需要具有良好的可視化建模工具，輔助建立節(jié)點和關系的要素，從而為后期的數(shù)據(jù)存儲提供元信息架構。

3、思路解析

3.1? 高度自動化

分布式架構的軟硬件架構直接導致數(shù)據(jù)中心維護對象的爆發(fā)式增長，只有高度自動化才能緩解人員不足、技能不夠的情況。經(jīng)過調(diào)研：現(xiàn)有的基礎軟硬件都能夠提供各種接口以獲取配置信息、狀態(tài)信息。實時性要求配置信息采集自動化，基礎軟硬件部分的信息可以實現(xiàn)完全自動化;現(xiàn)有應用層面需要進行一定的梳理工作后實現(xiàn)配置信息采集的標準化;關聯(lián)關系的定義需要分階段進行，首先要把數(shù)據(jù)中心的節(jié)點梳理，并將所有的關系進行統(tǒng)計和定義，然后根據(jù)節(jié)點的屬性信息自動生成節(jié)點關聯(lián)關系。

3.2? 全圖存儲

傳統(tǒng)集中式計算架構已經(jīng)逐步被分布式架構替換，數(shù)據(jù)中心的各種服務之間的關系越來越復雜。傳統(tǒng)的數(shù)據(jù)庫種類對于關系的存儲方式不夠理想直接導致開發(fā)周期過長、數(shù)據(jù)設計過于復雜。在分布式大大環(huán)境下，傳統(tǒng)的數(shù)據(jù)庫種類已經(jīng)無法滿足運維服務交互的需求，服務之間的關系需要新型的基礎性變革梳理。

圖數(shù)據(jù)庫作為近兩年的新生數(shù)據(jù)庫卻受到市場大量熱捧，其原因就是圖數(shù)據(jù)庫對于關系的處理技術是革命性的改變。數(shù)據(jù)中心數(shù)以百萬計的節(jié)點之間有無數(shù)的關系，因為傳統(tǒng)數(shù)據(jù)庫無法快速地處理關系，所以大量的信息無法展示和挖掘出來，這大大地影響了數(shù)據(jù)中心的運維效率。數(shù)據(jù)中心的配置信息全圖數(shù)據(jù)庫存儲可以將數(shù)據(jù)中心的提供服務的各種對象和關系原生地存儲在圖數(shù)據(jù)庫中，進而更加直觀地展示出來，而對全數(shù)據(jù)中心體系架構進行圖算法挖掘信息也變得更加敏捷。

3.3? 場景驅(qū)動

傳統(tǒng)CMDB一般都會以大而全作為建設目標，往往出現(xiàn)數(shù)據(jù)失效、數(shù)據(jù)過剩的現(xiàn)象，最終導致CMDB的數(shù)據(jù)無法消費。場景驅(qū)動的模型設計一方面可以提高建設效率，特別是為后期擴展提供堅實基礎，另一方面可以通過場景來直接消費配置信息，形成配置信息收集、存儲、消費的閉環(huán)。只有通過消費的認可，收集的配置信息才是最準確的、最有效的。

3.4? 面向DEVOPS

DEVOPS中的部署交付流水線、持續(xù)反饋和度量分析都需要強配置管理系統(tǒng)。新一代的配置信息管理系統(tǒng)不能僅僅滿足傳統(tǒng)ITIL的理念，需要面向DEVOPS。DEVOPS中的開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境都需要很多配置管理的消費，包括持續(xù)集成、測試、發(fā)布、部署、監(jiān)控、操作。DEVOPS深度融合自動化的理念，所以更加需要高度自動化的強配置管理平臺。

4、思路實現(xiàn)：

由于沒有高度自動化的配置管理平臺與圖數(shù)據(jù)庫結(jié)合的案例，在建設過程會遇到一些未知情況，所以建議采用原型開發(fā)模式，通過對典型場景的建模、開發(fā)為后期的大規(guī)模擴展提供寶貴經(jīng)驗。

主要按照四條主線進行：消費場景梳理與開發(fā);基礎資源架構梳理;應用資源梳理;配置管理與圖數(shù)據(jù)庫標準化。

4.1? 邏輯架構

4.2? 典型場景開發(fā)

選擇部分典型場景進行重點梳理和模型設計（如互聯(lián)網(wǎng)業(yè)務）;實現(xiàn)典型場景的數(shù)據(jù)自動化采集;實現(xiàn)典型場景的數(shù)據(jù)解析，特別是服務資源之間的關聯(lián)關系的自動化發(fā)現(xiàn);實現(xiàn)典型場景的數(shù)據(jù)入圖數(shù)據(jù)庫和基于圖數(shù)據(jù)庫的場景分析故障場景的影響性分析、應用系統(tǒng)的重要性分析、業(yè)務的關聯(lián)性分析）。

4.3? 基礎架構映射

數(shù)據(jù)中心的基礎資源（服務器、網(wǎng)絡、存儲、計算平臺、數(shù)據(jù)庫、中間件、大數(shù)據(jù)平臺）可以配置信息的自動化采集，基礎資源之間的關系相對固定，在技術上比較容易實現(xiàn)快速的建模與開發(fā)。

4.4? 應用資源梳理

數(shù)據(jù)中心的應用資源因為應用系統(tǒng)的種類較多，應用系統(tǒng)開發(fā)公司的標準化水平參差不齊，所以應用資源的配置信息采集與解析需要進行詳細的梳理。在前期典型場景的梳理和應用資源詳細梳理之后，再將應用資源配置信息統(tǒng)一采集入庫。

4.5? 平臺標準化

根據(jù)前期的典型場景的梳理初步配置信息的標準，在建設不斷推進的情況下，制定配置管理和圖數(shù)據(jù)庫平臺標準化管理規(guī)范，為后期實現(xiàn)平臺化、可配置化打好基礎。

4.6? 消費場景擴展

實現(xiàn)災備切換的雙機房服務資源架構圖的狀態(tài)信息豐富、云平臺的租戶服務內(nèi)容抽取展示。

5、風險分析

5.1 技術風險分析

配置管理的新思路技術要求高，特別是關系解析和圖數(shù)據(jù)庫兩部分，需要豐富的一線運維經(jīng)驗和對圖技術的深刻理解。需要對數(shù)據(jù)中心復雜基礎軟硬件的配置信息全圖化管理，沒有案例，更沒有成功案例，具有重大創(chuàng)新意義的同時存在較大技術風險。

5.2 流程風險分析

當前的流程基于ITIL開發(fā)，存在流程電子化程度不高、信息多余等情況。在配置信息管理中部分需要快捷的流程支持，因此，流程優(yōu)化也會影響配置管理平臺的成功實施。

5.3 組織風險分析

配置信息涉及多個技術條線的自動化采集信息和部分流程優(yōu)化，工作量的分配和團隊之間的協(xié)作也會大大影響建設的正常開展。

6.總結(jié)

隨著互聯(lián)網(wǎng)業(yè)務和分布式架構的不斷演進，銀行數(shù)據(jù)中心管理對象的數(shù)量和種類不斷增多，在新的技術架構體系下，將新型的圖技術運用到運維管理中去，大大提高了運維效率，規(guī)范了運營標準，減輕了運維工作。圖技術為銀行數(shù)據(jù)中心的配置管理提供了清晰的新思路，也為銀行的IT架構轉(zhuǎn)型提供了一部分有利支撐。

參考文獻：

[1]連城，淺析CMDB在云環(huán)境中軟件系統(tǒng)的應用方式[J].科學技術創(chuàng)新，2018，（2）：86-87。

[2]張幟，龐國明，胡佳輝，蘇亮，Neo4J權威指南[M].北京：清華大學出版社，2017。

[3]李全鑫，銀行數(shù)據(jù)中心運維自動化應用場景探討[J].計算機產(chǎn)品與流通，2019，（3）：112。

[4]張鳳軍.基于Neo4j圖數(shù)據(jù)庫的社交網(wǎng)絡數(shù)據(jù)的研究與應用[D].湖南大學，2016.

作者簡介：單瑋瑋（1986-），男，江蘇鹽城人，江蘇省農(nóng)村信用社聯(lián)合社信息科技部經(jīng)理助理，碩士研究生。