基于知識圖譜開展業務運行故障快速處置技術研究

中圖分類號：P414 文獻標志碼：A 文章編號：2095-2945(2025)14-0010-07

Abstract:Thebusinessystem ofthepublicmeteorological servicecenter hascomplex data processesandprocesing nodes. Howtoquicklydeterminethefaultpointwhenafaultocursandrelevantinformationisscarceidentifythenatureof thefault， anddeterminethemethodtorepairthefaultisaproblemfacedbytheoperationandmaintenanceworkersofthepublicservice center.Thispaperintroducestheideas，methodsandrelatedtechnologiesofknowledgemaping，takestheserviceproduct generatioprocessandnodesastheobject，reliesontheNeo4j databasetobuildaknowledge mapingdatabaseoftheservice productproductionprocess，andestablishesa\"countercurrentfaulttroubleshotingmethod\"todeterminefaultpointsandthe speed of fault nature has been greatly increased.

Keywords: knowledge graph；Neo4j; rapid troubleshooting;countercurrent troubleshooting;graph database

公共氣象服務中心（以下簡稱“公服中心\"以向社會及各服務單位提供所需的氣象服務產品為其主要的業務。目前，公服中心商業氣象服務的對象多是高德、餓了么等大型商業用戶，對服務系統的時效性、穩定性、可靠性都有嚴苛的要求。然而在業務系統運維方面，目前中心基本采用“專家運維 + 運維信息文檔查詢\"的系統運維模式，通過簡單的告警信息，運維人員憑經驗查詢1個或幾個運維信息文檔，找尋數據的傳輸流程，嘗試定位故障位置，并進行相應修復。這種方式耗時長、效率低下、對運維人員個人素質及當時狀態有較強的依賴性。隨著中心業務系統規模的不斷增長，業務系統運維的復雜度也在成倍增長，一直沿用上述傳統的運維模式已難以滿足用戶的時效和質量要求了。

因此，選擇有效技術，大幅提升故障排查和處置的時效，是擺在中心業務運維工作者面前的需要盡快解決的問題。

1運維現狀

公服中心目前專業氣象服務用戶有15個，大型商業服務對象4個，相應的業務系統5個，配置使用的計算機服務器30臺。其導致的業務運維工作的復雜度主要體現在以下幾個方面。

1.1種類繁多，標準各異

數據服務是公服中心對外服務的主要提供方式之一，現在對外提供的數據種類有164種，由于數據需求方所提出的個性化需求，這些數據產品的內容及格式也彼此不同。這些服務產品都是由各業務處室以及下屬科組制作而成的，制作流程較為復雜，而數據產品制作所用服務器、制作平臺及人員又較難管控，這些都對業務運維工作造成了一定困難。

1.2網絡復雜，流程多樣

氣象部門出于網絡安全考慮，內網與外網由DMZ區完全隔開，這增加了在對外服務時數據服務產品在內部流轉過程中的中間環節。此外，根據用戶對數據獲取

方式需求的不同，中間所涉及的服務器以及傳輸方式也隨之不同。

當前中心對商業、省級、內部用戶的服務模式有4種分別為互聯網接口、互聯網推送、內網接口和內網非接口。

互聯網接口：由中心業務部門為特定用戶制作專門的服務數據，并按時存放在DMZ區的商業服務數據庫

中，用戶通過接口自行從服務端的商業服務數據庫中獲取服務數據。

互聯網推送：由中心業務部門為特定用戶制作專門的服務數據，并主動推送至用戶端指定服務器的指定目錄下。

相關流程如圖1、圖2所示。

內網接口/推送數據服務與之類似，不再贅述。

1.3手冊交叉，檢索費力

目前采用的運維方式主要是靠專家運維 ?+ 運維信息文檔查詢的方法，而由于業務、技術歸屬等原因，許多運維信息文檔被存儲在了各個不同的目錄之中，有些還分了很多子目錄，查詢起來十分不便，這給運維工作（尤其是在故障排查過程中）造成了諸多不便。部分運維文檔所在位置如圖3所示。

2解決思路

就目前而言，氣象部門信息系統的運維工作仍以人工為主，以國家氣象信息中心綜合業務實時監控系統“天鏡\"為例，其大致做法如下。

故障告警。“天鏡\"的故障告警信息有3個來源：其一，“天鏡\"系統自動報警;其二，用戶發現故障后通過呼叫\"天鏡\"坐席或其他通信方式報警;其三，“天鏡\"技術人員在例行巡檢中發現異常后報警。

故障處置：“天鏡\"值班人員根據業務運維值班表電話通知相關二線人員，由二線人員依據系統提示信息和運維人員的經驗開展故障處理工作。

由此可見，即便是代表目前氣象部門運維能力最高水準的“天鏡”系統，人工作業依然是運維工作中故障處置的主要工作方式，公服中心也是如此。所不同的是，“天鏡”是采用整體設計規劃、由專門項目建成的專用于運維的工作平臺，而公服中心自前尚沒有這樣的運維專用平臺。所以單就告警提示信息而言，公服中心運維人員所獲得的信息較之“天鏡”便有著天壤之別，很難根據系統顯示信息直接對故障進行定位和性質判識。因此，公服中心運維人員面臨的問題是，如何在現有的基本條件下，在沒有豐富準確的提示信息的情況下，充分利用已有的基本信息，盡可能提高故障排查和處置速度。

名稱 修改日期 類型 大小 △□

bak 2024/4/822:29 文件夾

laps 2024/3/1121:23 文件夾

mqpf 2024/4/1211:29 文件夾

ocf和中央臺城鎮預報 2023/3/29 16:08 文件夾

ocf和中央臺城鎮預報訂正系統-新版 2023/3/2916:08 文件夾

rgf 2024/1/311:10 文件夾

scw 2024/4/2618:30 文件夾

公服中心存儲業務使用情況 2023/6/1513:42 文件夾

會商大屏 2023/3/2916:08 文件夾

精細化三維實況專業服務產品 2023/10/26 17:32 文件夾

南方電網 2024/4/198:03 文件夾

全國智能預報精細化服務風產品（SCMO... 2024/5/12 8:54 文件夾

全球16-45天多模式集成預報服務產品 2023/3/2916:08 文件夾

數據支撐服務平臺 2024/3/1813:40 文件夾

雨雪相態 2024/4/1510:32 文件夾

運維信息excel 2024/5/20 8:54 文件夾

自動切換說明 2023/12/621:23 文件夾

綜合業務業務內網 2024/4/2815:12 文件夾 =

10.0.74.226對外ip地址.txt 2021/6/2116:42 文本文檔 1KB

14時文件名清單.txt 2024/5/2017:22 文本文檔 172 KB

□14時文件名清單.txt.bak 2024/5/2017:20 BAK文件 176KB

aqi數據流程-2021版.doc 2023/3/1819:19 Microsoft Word .. 52KB

nfdw.tar.gz 2024/3/188:20 WinRAR壓縮文件 3，323KB

Zu指數和dia4指數推送文件頻次說明.docx 2021/8/1315:40 Microsoft Word .. 15 KB

北京標準格式雷達基數據應急措施.txt 2021/9/38:00 文本文檔 1KB

補實況格點1KM產品步驟.txt 2022/1/59:46 文本文檔 1 KB

釘釘密碼.txt 2023/4/1214:55 文本文檔 1KB

中國辦業務移交運行科.docx 2022/6/17 6:54 Microsoft Word .. 19KB

核心平臺訂正系統重啟文檔（10.30.16... 2022/7/14 8:47 Microsoft Word.. 21KB

華風集團智慧云業務系統網絡運維.docx 2021/8/210:27 Microsoft Word .. 63KB

華風集團智慧云業務系統網絡運維20210... 2021/7/2916:20 Microsoft Word .. 62KB

礦區數據運維文檔20240425.docx 2024/4/2814:55 Microsoft Word.. 31KB

中全國預警信息統一服務接口系統運維.docx 2024/1/2214:47 Microsoft Word .. 388KB

人保和應急部降水實況和預報數據運維流. 2021/8/28 18:09 Microsoft Word.. 264KB

人保數據和實況數據應急處理.docx 2020/12/15 7:01 Microsoft Word.. 361KB

數據業務記錄-20240520.xlsx 2024/5/2115:47 Microsoft Excel... 250KB

西安機場數據傳輸清單匯總0328.xlsx 2023/3/2817:05 Microsoft Excel... 15KB

為了解決這些問題，本文主要從以下幾點入手。

2.1運維信息規范處理

目前我們所有的系統信息，數據與數據之間的關系，數據與服務器之間的關系都是存儲在由不同人寫的不同的文檔之中的，所以在文檔的閱讀、理解、查詢的方式上也有很大的不同。需要將所有的運維信息及文檔統一規范化管理，以方便查詢。

2.2 運維信息統一管理

在所有的文檔信息內容與編寫格式都統一后，需要將這些文檔統一錄人到數據庫中，使得這些數據與關系可以統一存儲、統一處理、統一查詢。從而避免四處找文檔，以及文檔內容與相應故障不對應等問題。

2.3逆流向故障排查

就筆者所參與維護的公服中心各業務系統而言，所謂故障，除系統崩潰等重大設備故障外，絕大多數日常故障最終都反映在需要發送給客戶的服務信息(數據文件)出現問題，或未能按時發送，或數據文件本身不正常。對于這種故障，迅速確定故障發生點是當務之急。為此，筆者設計了利用發生故障的服務產品的制作流程信息，沿流程“逆向\"排查的\"逆流向故障排查法”，即，在故障發生后，自故障發現點開始，按照數據服務產品自制作端至客戶端的流轉流程，采用逆向數據排查法，也就是采用倒推的方式：從故障發現端(最遠為用戶端，終點)起，沿服務產品數據流轉流程逐個節點反推，一直回退到數據的制作端(起點），通過逐節點查看服務產品數據文件是否到達，以及文件大小及內容是否異常等方式，來判斷產品數據流轉到該節點為止的傳輸是否正常以及數據本身是否異常，從而判斷出故障發生的具體位置及故障的類型。

此方法的特點是，排查路徑、順序、位置、對象及判識標準都基本明確，沒有冗余的操作。這對于缺乏良好的運維平臺及充分的故障告警提示信息的公服中心運維工作而言，是一種充分利用現有信息提高故障排查效率的較為有效的方法。

因此在這里，建立數據與服務器、數據與制作人、數據與用戶、數據與目錄之間的關系，以及關系的準確性、規范性和完備性就變得尤為重要，一旦建立起良好的關聯關系，即便人工排查，在方向上也不會出現歧路，可經過有限的節點數逆向順序排查到故障發生點，以及故障的類型，不會出現冗余無效的操作。在日后建成的公服中心運維平臺(在建)中，更可以借助計算機快速完成上述操作。

為了一并達成上述幾個問題的解決方案，本文嘗試將知識圖譜的概念引入運維工作中，從而讓問題排查變得快速而高效。

3技術選型

3.1知識圖譜

本質上來說知識圖譜是一種結構化的知識表示形式2-。知識圖譜的發展歷史源遠流長。從經典人工智能的核心命題——知識工程，到互聯網時代的語義Web，再到當下很多領域構建的數千億級別的現代知識圖譜，以及在語義搜索智能問答8推薦計算語言理解大數據分析和設備物聯等領域都得到了廣泛的應用。知識圖譜技術發展到今天，其內涵已經遠遠超出了語義網絡的范圍。如今在更多實際場景下，知識圖譜作為一種技術體系，是大數據時代知識工程的一系列代表性技術的總和。

知識圖譜是典型的交叉技術領域，其主要是由自然語言處理、人工智能和機器學習、計算機視覺和知識庫等幾個方面組成。而其中的知識庫便是知識圖譜的根基，也是重中之重，知識庫主要以圖數據庫為載體，而圖數據庫的導入與制作便是建立整個知識圖譜的根本。

3.2 圖數據庫

圖數據庫(GraphDatabase)技術以圖論為根基，是基于圖理論實現的一種新型NoSQL數據庫，直觀、自然、直接和高效，不需要中間過程的轉換和處理。由于圖數據庫技術可以直接描述各種復雜的現實世界系統，使得其具有廣泛的適用性和更高的應用價值。

圖數據庫的數據存儲結構和數據查詢方式都是以圖論為基礎的。圖論中圖的基本元素為節點和邊，在圖數據庫中對應的就是節點和關系。

在圖數據庫中，數據與數據之間的關系通過節點和關系構成一個圖結構，并在此結構上實現數據庫的所有特性，如對圖數據對象進行創建、讀取、更新和刪除(Create、Read、Update、Delete，簡稱CRUD)等操作的能力，還有處理事務的能力和高可用性等。目前市面上較為流行的圖數據庫產品有Neo4j、OrientDB、TITAN和FlockDB等。本項自引人Neo4j圖數據庫作為知識庫的技術選型。

在圖數據庫中，關系是最重要的元素。通過關系能夠將2個節點相互關聯起來構建與我們的問題領域密切相關的復雜模型。Neo4j圖數據庫是一個帶有大型生態系統的數據庫。Neo4j有一個重要的特點，就是用來保證關系查詢的速度，即免索引鄰接屬性。該數據庫中的每個節點都會維護與他相鄰節點的引用，因此每個節點都相當于是與它相鄰節點的微索引，這比使用全局索引的代價要小得多；這就意味著查詢時間和圖的整體規模無關，只與它附近節點的數量成正比。眾所周知，關系型數據庫中使用全局索引連接各個節點，這些索引對每個遍歷都會增加一個中間層，因此會導致非常大的計算成本。而Neo4j的免索引鄰接屬性為圖數據庫提供了快速高效的圖遍歷能力。

對比圖4和圖5，可以明顯地看出關系型數據庫與Neo4j在查找關系時的區別。

圖4展示了RDBMS（關系型數據庫）中的查詢方式。要查找HTHT所購買的數據，首先要執行關系表的索引查詢，時間成本為 O(log(n))，n 為索引表的長度，這對于偶爾的淺層次查詢是可以接受的。但是當查詢的層次變深或者是執行反向查詢時，代價將會越來越高，直至變得不可接受。如果相較于查詢HTHT所購買的數據，要查詢某個數據被哪些客戶購買了，將不得不使用暴力方法來遍歷整個索引，時間復雜度則將增長到 o (n) 。除非我們再建立一個從數據到用戶的索引表，但是該方法將會占用許多額外空間，并且使索引變得難以維護。

如果我們再考慮一個更復雜的場景，HTHT所購買過的數據還被哪些用戶使用過，則找到HTHT購買過的數據的時間成本為 O(log(n)) ，找到每個數據被哪些用戶購買過的時間成本為 O(n) ;假如HTHT購買過 ?_m 個數據，那么總的時間復雜度即為 O(m×n×log(n) 。即使再建立一個方向索引表，時間復雜度也為 O(m×n) 。

由于使用了免索引近鄰機制，每個節點都有直接或間接指向其相鄰節點的指針。要查找HTHT買過的東西，只需要在HTHT的關系鏈表中遍歷，每次的遍歷成本僅為 O(1) 。要查找一個商品被哪些人購買了，只要跟隨指向該商品的關系來源即可，每次的遍歷成本也是 o (1)。對于更復雜的情況，要查找HTHT購買過的數據被哪些用戶購買過，時間復雜度也僅為 O(m) 。這相較于RDBMS的時間復雜度而言是占有絕對優勢的。

因此，利用免索引鄰接機制，在圖數據庫上進行關系查詢，效率非常高，這種高效是建立在圖數據庫注重關系的架構設計之上的[12-15]。

4技術實現

4.1模型選擇

圖數據要具體存儲到圖數據庫中，最終落實為具體的數據文件，自然就涉及特定的圖數據模型，即如何存、采用什么實現方式來存圖數據。常用的有3種：屬性圖（PropertyGraphs）、超圖（Hypergraphs)和三元組(Triples)。

屬性圖模型直觀且容易理解，能描述絕大部分圖使用場景，也是當下最流行的圖數據模型，有如下特點：

1)它包含節點和關系；

2)節點可以有屬性(鍵值對）；

3)節點可以有一個或多個標簽；

4)關系有名字和方向，并總是有一個開始節點和一個結束節點;

5)關系也可以有屬性。

超圖是一種更為廣義的圖模型，在超圖中，一個關系(稱作超邊)可以關聯任意數量的節點，無論是開始節點端還是結束節點端。

三元組是一個包含主謂賓的數據結構，例如張三和李四擁有3套房子等。顯然，單個三元組的語義還是比較有限，需要借助資源描述框架來增強其只是推理及數據關聯性。

由于系統運維場景多是單對單的場景，因此選擇屬性圖來作為運維圖數據庫的模型最為合適，Neo4j采用的就是這種屬性圖模型。

4.2 關系與節點的設計

從宏觀角度來說，Neo4i中僅僅只有2種數據類型。

1)節點(Node)：節點類似于E-R圖中的實體(Enti-ty)。每一個實體可以有零個或多個屬性(Property)，這些屬性以key-value對的形式存在。屬性沒有特殊的類別要求，同時每個節點還具有相應的標簽(Label)，用來區分不同類型的節點。

2)關系(Relationship)：關系也類似于E-R圖中的關系(Relationship)。一個關系有起始節點和終止節點。另外，與節點一樣，關系也能夠有自己的屬性和標簽。

因此在設計關系與節點時，采用E-R圖的方式，從各個不同的目錄，文檔與平臺中提取出信息并最終繪制成圖。

在本文的具體應用中，上述“關系-節點\"中的“節點”是由各個重要的環節與信息組成，包括數據傳輸中所經過的目錄，執行傳輸時所執行的程序信息，以及程序所在的服務器信息。而“關系”則是這些節點信息之間的聯系以及他們之間的流程信息。“節點\"和“關系”之所以這樣確定，是由數據服務產品制作過程中的數據傳輸流程而決定的：數據從內網的生產目錄一路經過多個服務器的目錄流轉，經由不同程序的轉發，從內網的加密網絡環境經過DMZ區傳輸到外網，再由外網解析入庫傳輸到商業服務數據庫中，最終由因特網進行接口服務。這一套流程的主線是數據所存放的目錄，整個流程由一條主線從左到右依次分布，而這條主線就是我們存儲數據的目錄。目前我們日常運維的故障排查過程即是以目錄為依據，根據目錄中數據的狀態，沿“關系\"路徑逆向(即：逆產品生成流向)來進行故障的逐“節點\"排查的。

4.3 圖數據庫的生成

待E-R圖繪制完成并審核通過后，即可開始進行入庫的工作。Neo4j的入庫有多種方式，一般可采用Java、Python、Excel以及原生的Cypher語言來執行入庫操作。由于數據內容分散龐雜，很難采用集中入庫的方式，因此采用Cypher語言進行逐條入庫。最終人庫了25類數據總計1000多條的代碼。

節點入庫Cypher語句示例如下。

CREATE（n:Users{用戶名:'cnigc_user’，歸屬部門：'華新天力'}）return n。

關系入庫Cypher語句示例如下。

MATCH(n:Services{所屬環節：'內網’，程序名稱:'zookeeper'})，(m:Services{程序名稱:'fileToMQ_RAC')CREATE(n)-[r:部署]- $$ (m）return r_o

5 應用場景

5.1改善目前運維時效

在完成數據入庫和E-R關系建立后，本文應用生成的Neo4j進行了日常運維操作。

在實際使用過程中，值班人員根據微信告警得知哪個數據服務產品在其對應的哪個目錄下出現狀態異常后，登錄Neo4j數據庫，使用Cypher語言或者直接在圖形上點擊操作，查詢與該數據所涉及的目錄相關的節點，找到上一級目錄節點，確認數據服務產品是否正常，如果正常則查詢與這兩個目錄節點相關的程序節點中所指出的程序是否正常，如果仍未發現異常則可以查詢跟該程序相關的節點，多數情況下有3種可能：一是服務器內存出現問題；二是服務器部署的執行該程序的程序出現問題；三是與故障有關目錄節點的服務器的物理存儲容量出現問題。自前尚未出現上述3種可能以外的故障原因。

這種應用雖仍然是手工方式，但處理效率由原先的35min 左右的處理時間提升到了 17min 以內。因此，在日常常規的專家型運維中，使用Neo4j較之以往逐個手動依次查詢相關目錄和文檔，可以更加快速地定位到故障所關聯的目錄、程序、服務器以及相應的負責人。經初步比較，實現熟練操作后，使用Neo4j后故障定位時效較之使用前，速度至少提高一倍。同時，使用Neo4j也可以更加高效的判明這次故障所影響的用戶范圍，并判斷處理的優先級。

更重要的是，因為路徑、順序、位置和判識標準都已基本確定，在未來的運維專用平臺建設項目中，如果采用計算機處理，時效將是以前人工“專家運維\"模式的數十倍以上。

5.2 故障定位自動化構想

以本文成果為基礎，在未來采用計算機實現故障定位時，可依循如下構想。

電腦系統通過定時掃描傳輸log日志與最新數據的接口返回代碼來判斷是否有數據產品出現問題，以及哪個數據服務產品出現了問題。然后根據該數據的數據名稱對應表讀取Neo4j庫中對應數據名稱的目錄節點，查詢數據存放在哪個目錄下。根據數據目前存放的目錄狀態進行判斷。多數情況下有3種可能：一是數據目前在fail目錄下；二是數據目前在某各環節的起始或某個中途目錄下；三是數據目前在任何目錄下都未能查詢到。

1如果該數據存放在某環節的fai1自錄下，則嘗試將該數據移動到該環節的起始目錄并執行該環節的程序，然后等待一段時間后進行再次排查。如果數據又進入了fail環節則對值班人員進行告警。

2)如果該數據存放在某環節的某個中途目錄或起始目錄下，則暫時不做處理，等待一段時間后再次查詢，如果結果相同，則查找與該目錄相關的程序節點并對其進行重啟，待程序重啟后，則將該數據移動到該環節的起始目錄并重新執行該環節的起始程序，然后等待一段時間后進行再次排查，如果結果相同則對值班人員進行告警。

3)如果數據未能查詢到存在于任何自錄下，則查詢該數據所關聯的負責人節點，并對該負責人進行告警。如果在重啟程序環節發現程序啟動報錯，則對該程序的負責人進行告警。如果在重啟程序時發現所在服務器已鏈接失敗，則查詢庫中該程序所對應的服務器節點，并對服務器負責人進行告警。

由于條件有限，本文臨時搭建了一個簡易測試環境，根據上述思路，進行了一定程度的有限測試，初步結果表明，對一些簡單故障，計算機即可直接自動化處理，且時效在秒級以內。對那些復雜故障，除去必須的程序重啟和等待時間，也可在第一時間通知到責任人，并對故障環節和現象進行簡單報告，這將大大提高對故障的處理時效。

由此可見，在未來全中心業務系統運維專用平臺建設項目中，若在本文的基礎上采用計算機處理，時效將是以前人工“專家運維”模式的數十倍以上。

6 結束語

自動化、智能化是業務系統運維工作未來的發展方向，而運維信息的規范化、標準化和完備化則是這一切的基礎。本文研究過程中接觸了這方面的工作，并著手進行了相應的規范化處理工作，在提高運維工作中故障發現和處置效率的同時，也為未來公服中心全面實施運維信息規范化工作進行了一些嘗試。

Neo4j數據庫的應用范圍非常廣泛，無論是在傳統運維方面還是在系統應用方面甚至是在數據銷售方面都有廣泛的前景。將Neo4j數據庫技術應用于大規模復雜數據流的結構性管理，既是一種嘗試，也是一種可行的選擇。相信在不久的未來，圖數據庫在氣象信息業務工作中會越來越多，越來越好。

參考文獻：

[1]國家氣象信息.國家氣象信息中心業務系統運行故障協同處置管理辦法[Z].2024-06-03.

[2]BORNER K，CHEN C，BOYACK K. Visualizing knowledgedo-mains [J].Annual Review of Information Science and Tech-nology，2003(37):179-255.

（下轉20頁）