醫院運維 告警閃現後的故障排查

長期以來，醫院資訊化運維中存在著科室複雜、應用場景多、終端運維工作量大、軟體系統相容需求強等諸多痛點，且對技術裝置的穩定性、連續性要求極高，在日常運維中，需要應對和解決這些問題來保障業務穩定、健康執行。

1、資料孤島 

在資訊化建設中，醫院基本完成核心業務系統的建設，且配置一定規模的網路、伺服器、動環等系統。因此也會出現各 廠商獨立監控、資料割裂 ，形成運維孤島。

2、問題發現被動、滯後 

傳統人工巡檢的方式，存在問題發現被動、滯後，難以保障業務的穩定執行。且人工摸排時間長、效率低，運維工作效果不顯著。

3、告警不準確 

部分醫院有動環、基礎設施監控等管理系統， 醫院業務系統複雜，易產生告警冗餘，難以在告警風暴中判斷故障根因。

4、對資源和效能資料掌握不足 

對伺服器CPU、記憶體等計算資源，磁碟空間、磁碟I/O等儲存資源的缺乏監控管理，對系統應用節點和資料的各項效能引數配置等資料把控不足，不能提前發現隱患問題。

近5年，LinkSLA智慧運維管家在醫療領域服務滿意度95%以上，透過建立主動監控和御防，MOC線上值守的線上+線下的大運維服務，幫助醫院實現高效、穩定的業務環境。下面 透過一組小案例看LinkSLA智慧運維管家在醫院運維實踐中的價值。

一、告警問題

11月14日9點，平臺接到安徽某三甲醫院 HuaweiO cean S tor9000 裝置告警，告警提示3點異常：

• 檔案系統服務狀 態 異常；
• Node-01儲存節點異常；
• 協議共享服務異常；

（告警列表）

奇怪的是， 告警僅持續5分鐘，隨後檔案系統、存 儲節點和協議共享 服務狀態又 全部恢復正常。期間 無任何技術性調整，告警自動解除，是產生誤報嗎？裝置 問題需要再確認一下嗎？答案是肯定的， 對平臺告警準確率深信不疑的moc工程師不錯過任何隱患問題，堅持再次檢查裝置的健康狀況。

二、問題的排查過程

moc工程師溝通現場工程師，建議檢視裝置執行狀態，並檢視執行日誌，檢查是否有硬體故障發生。

次日，廠家檢查裝置發現Node1沒有備用節點，手動新增節點Node2，這一操作導致儲存節點Node4健康狀態和磁碟狀態異常，平臺收到告警建議進行整改，儲存節點Node4恢復正常，廠家將檢測日誌帶回做進一步分析。

3、廠家持續遠端觀察該裝置執行狀況，並將日誌回傳進一步分析。

4、在持續觀察以及日誌分析後，判斷記憶體條問題導致14日Node1節點和檔案系統告警。更換掉記憶體條後，問題得以解決。

三、案例小結

這個案例的細節驚喜在於告警閃現5分鐘後快速恢復，如果沒有MOC值守工程師的關注，很容易忽視這個異常告警，MOC工程師快速響應溝通現場，聯絡廠家進行裝置檢查，跟進故障修復進度，隱患問題最終得到解決。

LinkSLA智慧運維平臺抓住瞬間閃現的故障，將問題扼殺在萌芽中。充分體現平臺對故障的敏銳度，沒有空穴來風的報警，只有尚未明確的問題。

這也是線上監控+線下服務的典型案例。