醫院應用服務健康監測

很多醫院在面臨醫療業務增長壓力的時候都會陷入一個怪圈：各業務科室反映醫生工作站開醫囑變得慢了，影像中心反映調取片子的速度慢了，檢驗科室反映讀取報告慢了……面對這些來自業務科室的壓力，很多醫院信息中心會通過購買服務器的方式來提高系統的響應服務速度，有的購買Web服務器，有的購買應用服務器，有的購買數據庫服務器……直到把醫院有限的機房全部填滿。

事實上，有一個很重要的工作被忽略——沒有對業務系統進行詳細的故障數據分析，缺乏業務系統健康狀態的數據分析。現在的醫療業務系統普遍采用三層架構，即Web服務器、應用服務器和數據庫服務器，從數量上看每層可能都有數臺以上的服務器，很多醫院看這種性能問題普遍都是從數量上看，但是走進每臺服務器我們會發現，影響和制約業務系統運行的還有軟件因素，即比物理資源更重要的軟件資源，如數據庫的連接信息、讀寫I/O狀態，數據庫明細和表空間狀態，應用服務器的會話性能、事務狀態、線程池等，這些軟件資源很多時候會成為系統運行的瓶頸。

此外，一直以來，醫院都是將網絡和系統應用分開管理，在很多醫院一般是由兩個團隊分別負責運維。對服務器應用軟件資源的管理，醫院大多采取獨立的系統管理；對網絡、安全、服務器等硬件資源的管理，醫院多采用獨立的網管系統。兩套班子，兩套系統，沒有統一融合的管理工具，數據中心的運維成本很高。

因此，醫院迫切需要建立一套可視化的應用監視手段，可集成數據中心系統管理，通過自動化的運維工具，提高運維效率，降低管理復雜度，保障整個醫療應用系統的穩定、高效、不間斷運轉。

在對醫院進行應用服務監測管理的時候，面臨如何管理、管理什么、關聯管理和管理控制等問題：

1、 管理不能以犧牲性能為代價，尤其如HIS、PACS、EMR等醫院核心業務系統，不能增加醫院業務系統的業務負擔；

2、 全面覆蓋限制服務能力的關鍵點，要對影響服務的各種資源進行詳細監控，不僅有硬件資源，還要有豐富的軟件資源；

3、 醫院業務從傳統相互獨立的應用模式向強關聯性發展，因此醫院業務服務健康監測，要能夠識別應用資源的依賴關系和相互依存性，跟蹤相關業務的性能，提高監控效率；

4、 監測不是目的，通過服務監測可及時發現問題，并建立良好的應用服務質量管理體系；

H3C APM醫院應用服務健康監測解決方案，從根本上解決了服務器應用資源管理問題，可以幫助醫院獲得更好的資源可視性和可控性，減少工作量，提高運維效率。

一、 管理方式

APM采用無代理（Agentless）模式，通過不同命令、腳本或模擬客戶端的方式要求應用資源反饋相應指標數據，然后根據指標數據對應用資源的性能、負載進行評估，從而評估應用系統的性能。比如對Windows服務器的監控可以采用SNMP協議和WMI（Windows管理規范）協議；對數據庫的監控可以采用ODBC連接、SQL結構化查詢語言等命令模擬客戶端登陸服務器以獲取相關數據。這種管理方式對于關鍵的醫療應用資源占用不大，增加應用系統穩定性。

二、 管理內容

APM覆蓋了包括以下的市場主流應用資源。

? 服務器操作系統：Windows、Linux、Sun Solaris、FreeBSD、IBM AIX、HP- UX、Tru64 Unix、Mac OS等；

? 數據庫：Oracle（8.x/9i/10g/RAC/11g）、MySQL（3.23.x/4.x/5.x）、Microsoft SQL Server（2005/2008）、IBM DB2（8.x/9.x）、Sybase等；

? Web服務器：Apache、Windows IIS、PHP等；

? 應用服務器：Microsoft .Net、GlassFish、JBoss、Oracle AS、SilverStream、Tomcat服務器、WebLogic、WebSphere等；

? 中間件：WebLogic、WebSphere等；

? 郵件服務器：Microsoft Exchange 2003/2007、其他SMTP、POP3型郵件服務器。

除此之外，APM還可以提供自定義監控的能力，對醫院諸多獨特的的應用系統進行監測。

在監控指標上，APM有所側重，如對主機系統、數據庫服務器、應用中間件，要分別關注其內部各種關鍵參數，以便準確把握系統運行狀態，及時地發現故障苗頭。對內部Web HTTP服務的監控是由于醫院內部有很多重要的Web應用，通過對HTTP和HTTP序列的監控，可以確保所有這些網頁7*24小時正常運行，并能夠在網頁響應變慢之前及時得到通知，這就盡可能地避免了醫生、醫務人員由于網頁打不開或者登陸不上去而抱怨。

三、 業務關聯管理

APM提供智能的關聯分析。對醫院IT管理員來而言，他們往往認為數據中心中各資源的性能明細等這些冷冰冰的數據與他具體負責的業務沒有關聯，尤其當系統龐大之后，海量的數據更是讓人感覺云山霧繞。在這種情況下，可以考慮基于業務維度的監控，通過分組數據中心中的應用、服務器及系統等不同資源，為異構的IT基礎架構創建一個具有邏輯意義的業務視圖，實時監控此邏輯視圖中的性能變化。

圖1 基于業務維度的監控

如圖1所示，某臨床信息系統包含門診醫生工作站、住院醫生工作站、護士工作站、電子病歷、臨床檢驗系統、醫學影像系統、營養配餐管理、臨床用藥咨詢、手術室麻醉系統、重癥監護信息系統、輸血管理系統等子系統，而每個子系統都由操作系統、數據庫、Web服務器、存儲等服務器應用組成，因此可以建立對應的邏輯視圖，如圖2所示。

圖2 基于業務維度監控的邏輯視圖

邏輯視圖可向下層層鉆取直至原子服務，每一種應用資源的性能變化即反應了其對應的子集，同時也反應整個臨床信息系統應用的性能。通過這種方式，用戶只需監控對應的邏輯視圖，簡單明了、清晰簡潔，顯著提高醫院數據中心應用資源運維管理的效率。

四、 管理控制

APM提供一體化融合的方式，能夠同步了解網絡和應用的情況。

1. 網絡與應用的拓撲結合

通過網絡與應用拓撲的結合，醫院可以按照業務的維度建立統一視圖，拓撲圖中融合網絡性能、告警數據，也可直接查看各種應用的運行信息，直觀形象地展示了當前醫院數據中心業務相關的網絡和應用情況（如圖3所示）。

圖3 網絡與應用的拓撲融合

2. 故障根源分析

醫院數據中心中一般存在大量的告警信息，但這些信息往往不需過分關注和處理。查看分析這些告警信息不僅耗費管理員大量的時間和精力，并且會將關鍵告警信息淹沒其中，從而影響管理員對數據中心故障的正確判斷和及時處理。很多醫院用戶都有這樣的感受，數據中心中的某臺核心設備端口斷電之后，從接入設備、匯聚設備到后端應用服務器都會產生故障，管理系統霎時間會收到海量的嚴重告警信息，在短時間內要求能夠快速定位到故障的源頭幾乎是一項不可能的任務。

故障的根源分析，要求系統能夠根據一定的算法規則，分析告警間的邏輯原因，自動屏蔽、排除無關的表象告警，最終幫助管理員找出導致故障的根源告警。通過常見的短信、Email等告警轉發手段，使用戶不需要坐在電腦前，就可以獲得關鍵的根源告警信息，從而能夠及時地解決問題（如圖4所示）。

圖4 服務器應用的故障根源分析

3. 綜合SLA分析

基礎網絡及服務器等資源的建設主要還是用于支撐上層業務和服務，SLA（Service Level Agreement，服務協議等級）就是用來衡量數據中心的服務水平。數據中心綜合SLA分析融入了告警、性能、流量、應用等數據，通過指標的創建與服務的建立，來完成整個服務的度量監控和管理。以醫院HIS應用為例，管理員將涉及的網絡、PC服務器操作系統、數據庫、郵件服務器及其相關的鏈路、配置、流量等組合成服務項，通過圖表數據實時監控服務的健康狀況，并對醫院各科室輸出SLA服務報表。一旦業務出現問題，相關模塊的數據能夠幫助管理員定位問題（如圖5所示）。

圖5 綜合SLA分析

這樣的管理辦法和思路給醫院數據中心運維人員帶來的好處是不言而喻的，一方面豐富的SLA圖形報表使得業務的服務質量清晰可見；另一方面，關鍵質量指標的數據使得定位問題不再無跡可循。