服務案例|故障頻發的一週,居然睡得更香!
醫院運維,聽起來平平無奇毫不驚豔,但其中的含金量,可不是 “維持系統正常執行”就能總結的。畢竟醫院對業務連續性的超高要求,讓運維面對的問題都是暫時的,下一秒可能就有新問題需要發現解決。
醫療資訊化不斷提高,各類裝置、終端數量呈爆發式增長。 IT執行環境日趨複雜,系統間關聯逐漸加深,機房管理、系統監控...運維工作加量不加價。在保障資訊系統高可用,穩定與安全之間,資訊部門選擇所有。
當我們試圖解決醫院棘手的運維問題,就要去做系統性建設。安徽某三甲醫院攜手 LinkSLA智慧運維平臺,已經走過四個年頭,早早完成從傳統運維到智慧運維的升級,不僅改善對業務系統的支撐,同時幫助運維工作提質增效。
醫院運維能力提升主要集中在三個方面:
1、全棧資源統一監控
涵蓋 多型別、品牌監測,支撐大規模複雜資料的關聯分析,一個介面瞭解醫院所有 IT資源執行狀態。
2、 IT資源視覺化呈現和分析能力
資料呈現更靈活,將網路拓撲、關鍵效能指標、系統健康狀態和警報資訊等視覺化呈現,提供資料的圖形展示,運維人員可快速掌握和分析資訊。
3、 故障的快速定位與恢復,保障 業務連續性。
實時自動巡檢,準確定位故障節點,將故障處理時效從小時級降至分鐘級。自動識別並分析業務及關聯資源的常見故障,變被動響應為主動預防,有效降低故障發生率。
該使用者上週罕見的頻發告警故障,平臺透過及時的告警和服務響應,幫助使用者快速解決故障保障業務系統的穩定健康。客戶表示雖然告警變多了,但是平臺比他更主動,出手更快。很享受這種可控、可靠的服務。
案例一、解決
nutanix節點記憶體使用率高問題
宿主機的記憶體使用率看似微不足道,實際檢查起來費時費力,很多使用者會過濾掉,不願為這種小事每天做例行檢查。但是小問題也會引發大事件,嚴重可導致非計劃停機,大面積的業務中斷。
上週一 16:55分,平臺收到該客戶Nutanix-Hypervisor記憶體使用率超出閾值告警。
MOC工程師通知現場工程師處理,提醒記憶體使用過高,建議 將部分虛擬機器遷移,從 02節點遷移至01節點。
虛擬機器遷移後,告警問題得以解除。
平臺透過
moc7*24線上值守,幫助客戶更輕鬆高效運維,提前告知客戶,做好空間規劃與清理,有效避免小事情造成麻煩。
案例二、解決 HIS資料庫日誌空間滿問題
週二 14:22,平臺收到HIS資料庫日誌檔案空間使用率過高告警,THIS4的日誌檔案增高,接近100。
日誌檔案使用率閾值設為 80%,過去一段時間使用率在10%左右平穩執行,根據當天時序圖顯示,從14:20開始,短短5分鐘THIS例項的日誌檔案就從2.74G火速上升到28.86G,日誌檔案異常暴增,背後到底發生啥?讓moc帶我們走進現場。
MOC工程師第一時間溝通現場工程師,檢查故障確定因資料庫差異化備份導致, 資料庫 : COMMON、HRP_HB、MZHSZ、 NIS_MOBILE、THIS4備份完成後,磁碟空間使用率恢復正常, 告警得以解除。
分鐘級的告警響應,源自於平臺對每個業務元件的指標、日誌進行實時監控檢測,一旦觸發告警 moc工程師會第一時間響應,通知現場工程師直到問題解決。將隱患扼殺在萌芽狀態,大大降低系統當機風險。
案例三、解決
C盤IO繁忙率高問題
週三 7:18,【OC】磁碟繁忙率超過閾值, C盤讀寫請求服務佔所用時間百分比"Percent_Disk_Time"大於90%,逼近100%。
moc工程師初步判斷兩種可能。 其一, C盤負載過重,導致磁碟無法及時處理所有的讀寫請求,其二,磁碟驅動器出現了故障或其他問題。
MOC工程師與現場工程師溝通,建議進行系統效能分析和磁碟故障排除, 檢查系統中的磁碟活動情況,檢視程式或應用程式是否過多佔用磁碟資源,嘗試 清理磁碟碎片,釋放磁碟空間。進行病毒掃描,確保系統沒有受到惡意軟體的影響。如果是硬體故障,可能需要更換磁碟或進行維修。
透過現場工程師排查,最終得出由於部署服務反覆停止和重啟導致 C佔用率過高導致,重啟伺服器後恢復正常
LinkSLA改變傳統人工排查故障的方式,透過實時自動巡檢,一站式的資料管理分析,快速定位響應告警,效率大幅提升。傳統需要供應商多次溝通才能完成故障定位修復,甚至耗時1個月以上時間,基於平臺的監控資料以及專家支援,故障發現定位恢復時間縮短至小時級。
此外,透過 MOC工程師,客戶可以輕鬆使用平臺,無需時刻緊盯監控,也能掌握平臺執行狀態,遇到突發問題,moc會第一時間通知,協助故障定位和提供解決方案,真正做到事前有御防,事中有保障,事後有總結。
LinkSLA智慧運維改善資訊部門對業務系統的支撐能力,同時大幅降低運維人員的工作強度,使其將更多精力用於運維管理,未來醫院發力智慧醫療,也將受益智慧運維的高效工作,收穫長期價值。
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/70013542/viewspace-2996617/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【故障公告】週五下午的一次突發故障
- 數字金融向縱深發展 服務應用頻頻創新
- 微服務實戰:服務發現的可行方案以及實踐案例微服務
- 服務限頻限次的場景方案
- 【jmeter】記一次服務頻寬的流量模型測試JMeter模型
- 第五週週一(安卓端連線服務端)安卓服務端
- SpringBoot開發案例之整合Dubbo分散式服務Spring Boot分散式
- 一週雲事|雲服務高速增長
- 華為雲服務治理 | 微服務常見故障模式微服務模式
- Laravel —— 服務注入實戰案例Laravel
- 【.NET6】gRPC服務端和客戶端開發案例,以及minimal API服務、gRPC服務和傳統webapi服務的訪問效率大對決RPC服務端客戶端APIWeb
- linux故障集合:架構階段備份服務-儲存服務錯誤Linux架構
- Facebook全球服務中斷,一週當機兩次
- SpringCloud進行nacos的服務註冊和服務管理案例SpringGCCloud
- 基於DKHadoop的智慧人社服務平臺開發案例簡述Hadoop
- .Net Core微服務——服務發現:Consul(一)微服務
- 【Azure Cloud Services】雲服務頻繁發生伺服器崩潰的排查方案Cloud伺服器
- asp.net core服務的生命週期ASP.NET
- 14、Workerman案例1-Http服務HTTP
- python監控MongoDB服務程序,故障釘釘告警PythonMongoDB
- Envoy服務網格如何減輕級聯故障?
- 打通C/4HANA和S/4HANA的一個原型開發:智慧服務創新案例原型
- SpringBoot 2.x 開發案例之整合MinIo檔案服務Spring Boot
- 成都寺廟小程式開發案例原始碼提供服務商原始碼
- 先於使用者發現服務故障-內網可用性監控內網
- 最佳化 Java Spark 服務忙了整整一週JavaSpark
- 分享一次機房出口頻寬跑滿的案例
- 記一次儲存問題導致的rac故障案例
- 大型金融服務集團RPA案例分享
- OGG DDL觸發器引發的故障系列(一)觸發器
- 死磕一週演算法,我讓服務效能提高50%演算法
- Android四大元件之服務————服務的生命週期和啟動方式Android元件
- consul服務註冊與服務發現的巨坑
- [翻譯]微服務設計模式 - 5. 服務發現 - 服務端服務發現微服務設計模式服務端
- Elasticsearch 磁碟空間異常:一次成功的故障排除案例分享Elasticsearch
- 【故障公告】騰訊雲簡訊服務故障造成無法傳送手機簡訊
- 微服務的故障處理微服務
- 物流服務網站搭建,從定製到開發一體化服務網站