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

中圖分類號：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

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

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

1運維現(xiàn)狀

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

1.1種類繁多，標準各異

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

1.2網(wǎng)絡復雜，流程多樣

氣象部門出于網(wǎng)絡安全考慮，內網(wǎng)與外網(wǎng)由DMZ區(qū)完全隔開，這增加了在對外服務時數(shù)據(jù)服務產(chǎn)品在內部流轉過程中的中間環(huán)節(jié)。此外，根據(jù)用戶對數(shù)據(jù)獲取

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

當前中心對商業(yè)、省級、內部用戶的服務模式有4種分別為互聯(lián)網(wǎng)接口、互聯(lián)網(wǎng)推送、內網(wǎng)接口和內網(wǎng)非接口。

互聯(lián)網(wǎng)接口：由中心業(yè)務部門為特定用戶制作專門的服務數(shù)據(jù)，并按時存放在DMZ區(qū)的商業(yè)服務數(shù)據(jù)庫

中，用戶通過接口自行從服務端的商業(yè)服務數(shù)據(jù)庫中獲取服務數(shù)據(jù)。

互聯(lián)網(wǎng)推送：由中心業(yè)務部門為特定用戶制作專門的服務數(shù)據(jù)，并主動推送至用戶端指定服務器的指定目錄下。

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

內網(wǎng)接口/推送數(shù)據(jù)服務與之類似，不再贅述。

1.3手冊交叉，檢索費力

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

2解決思路

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

故障告警?！疤扃R\"的故障告警信息有3個來源：其一，“天鏡\"系統(tǒng)自動報警;其二，用戶發(fā)現(xiàn)故障后通過呼叫\(zhòng)"天鏡\"坐席或其他通信方式報警;其三，“天鏡\"技術人員在例行巡檢中發(fā)現(xiàn)異常后報警。

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

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

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

bak 2024/4/822:29 文件夾

laps 2024/3/1121:23 文件夾

mqpf 2024/4/1211:29 文件夾

ocf和中央臺城鎮(zhèn)預報 2023/3/29 16:08 文件夾

ocf和中央臺城鎮(zhèn)預報訂正系統(tǒng)-新版 2023/3/2916:08 文件夾

rgf 2024/1/311:10 文件夾

scw 2024/4/2618:30 文件夾

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

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

精細化三維實況專業(yè)服務產(chǎn)品 2023/10/26 17:32 文件夾

南方電網(wǎng) 2024/4/198:03 文件夾

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

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

數(shù)據(jù)支撐服務平臺 2024/3/1813:40 文件夾

雨雪相態(tài) 2024/4/1510:32 文件夾

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

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

綜合業(yè)務業(yè)務內網(wǎng) 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數(shù)據(jù)流程-2021版.doc 2023/3/1819:19 Microsoft Word .. 52KB

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

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

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

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

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

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

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

華風集團智慧云業(yè)務系統(tǒng)網(wǎng)絡運維.docx 2021/8/210:27 Microsoft Word .. 63KB

華風集團智慧云業(yè)務系統(tǒng)網(wǎng)絡運維20210... 2021/7/2916:20 Microsoft Word .. 62KB

礦區(qū)數(shù)據(jù)運維文檔20240425.docx 2024/4/2814:55 Microsoft Word.. 31KB

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

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

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

數(shù)據(jù)業(yè)務記錄-20240520.xlsx 2024/5/2115:47 Microsoft Excel... 250KB

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

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

2.1運維信息規(guī)范處理

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

2.2 運維信息統(tǒng)一管理

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

2.3逆流向故障排查

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

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

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

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

3技術選型

3.1知識圖譜

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

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

3.2 圖數(shù)據(jù)庫

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

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

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

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

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

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

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

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

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

4技術實現(xiàn)

4.1模型選擇

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

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

1)它包含節(jié)點和關系；

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

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

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

5)關系也可以有屬性。

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

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

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

4.2 關系與節(jié)點的設計

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

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

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

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

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

4.3 圖數(shù)據(jù)庫的生成

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

節(jié)點入庫Cypher語句示例如下。

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

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

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

5 應用場景

5.1改善目前運維時效

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

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

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

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

5.2 故障定位自動化構想

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

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

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

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

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

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

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

6 結束語

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

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

參考文獻：

[1]國家氣象信息.國家氣象信息中心業(yè)務系統(tǒng)運行故障協(xié)同處置管理辦法[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頁）