中山一院：新一代的智慧醫院建設，以流量分析爲抓手，提升用戶體驗
導言
中山大學附屬第一醫院，簡稱中山一院，位於廣州市，始建於1910年，2019年中國醫院排行榜發佈，中山一院位居第六。
作爲一家現代化大型三甲醫院，中山一院在信息化系統的建設上是較爲全面的，基於HIE的可擴展基礎架構建立了包括HIS、EMR、HRP、LIS、 PACS等應用的信息化管控體系。雖然信息中心投入了很大精力在IT系統的建設和基礎架構的維護上，但還是會出現系統運行緩慢，用戶體驗感不佳等問題。由於醫療行業的業務特殊性，對系統的連續性和使用效率要求非常高，因此急需建設一套完善的網絡流量監控分析系統。
2020年，中山一院採用了新的智能流量分析平臺，實現了網絡質量和應用系統性能的實時監測，並實現了快速故障分析能力。本次IB資訊記者王永智採訪了中山一院信息中心技術負責人劉翰騰，請他分享中山一院從流量角度實現穩定運維，提升用戶體驗的最佳實踐。
1：系統7×24小時全年穩定在線是實現高效就醫的基礎
記者：就醫院行業來說，其網絡運維特點有哪些不同於其他行業的地方?
劉翰騰：醫院信息系統，尤其是核心系統，都是7×24小時全年都不能停機的，最大的停機時間窗只有半小時左右，否則就會影響患者排隊就醫。這種行業特性，就需要網絡運維能夠快速定位故障，及時排查。業務的特殊性決定了對網絡運維的要求，對連續性的保障程度要求是比較高的。因此，在網絡監控工具的選擇上，我們要求工具對信息系統傳遞的及時性，跟流程驅動的準確性，這是和其它行業有差異的地方。
記者：醫院智能化運維建設的難點是什麼?
劉翰騰：醫院的智能運維常規還是以軟件運維優先的，但軟件運維它又需要載體，就是硬件跟網絡要有比較強的支撐。我們現在感覺智能運維這一塊之所以難做的原因，就是軟件跟硬件之間的銜接度不高，各種不同的系統各自獨立，導致後面其它系統取數據的時候，底層資源的關聯性較差，這種情況會導致後續的很多故障定位的問題，比如經常會出現整體資源夠用，但是局部慢的情況。出現問題時，軟硬件維護人員之間會互相推諉，沒有快速定位的方法的話就會責任界定不清。
記者：中山一院日常的用戶有哪些?這些人員的數量級是多少?
劉翰騰：我們的用戶分爲終端內的用戶、開發運維的用戶以及患者，也就是前端互聯網的用戶。終端就是我們的醫生、護士跟管理人員。我們內網大約有3000臺左右的終端，醫生站、護士站、收費處、取藥處、自助機，這些我們都定位爲內網的醫療業務終端;我們還有2000個左右的辦公終端，就是上互聯網做一些溝通協調的用途;開發運維工程師的電腦目前的規模有兩三百臺。患者、前端互聯網用戶的數量，我們是按門診量去估算的，每天規模大概在15,000左右。
2 ：智能監測與巡檢，提升用戶體驗
記者：信息中心對網絡運維的能力要求是怎樣的?
劉翰騰：作爲運維團隊我們希望瞭解對於終端我們開放了哪些網絡端口，哪些端口允許連入我們的網絡;服務器開多少臺，提供什麼系統程序;開了哪些數據庫，多少個服務端口等等，這些流程要有一個從發佈到批准到後面上線的審覈過程，也要有配套的監測運維的機制。我們會做一些日誌審計，以及對於流量和數據庫的操作行爲審計。然後對這些審計的結果，建立巡檢，把運作過程中的問題通過巡檢發現出來，最後建立事件響應流程，有需要的話採取運維干預的措施，這是日常供給側的。
還有一側是故障側。前端業務是連續在用的，比如有醫生、護士或者病人在使用，那麼前端在使用的時候我們後臺就會建立服務檯的故障處理流程，比如去判斷前端事故的類型，能夠快速定位故障的話，就可以儘量縮窄故障的影響面。所以關於故障的定位的時效性跟準確性是比較頭疼的問題，是希望找各種工具來完善的。
我們這次採用的是智維數據的nCompass可視化智能流量監控平臺。其實我們在採用現在這套工具之前，我們也上了很多運維監測類的其他工具，有關於主機性能的，數據庫性能的，還有整個機房的環控這些，但是問題在於每個環節都是一個獨立診斷模型，碰到一個跨系統的故障的時候，我們就需要運維團隊的每個人都把自己負責的系統狀態報一下，故障出在哪裡只能憑團隊的運維經驗去猜測，導致我們的診斷機制跟定位的精度都不是太高，想要縮窄對業務的影響面那就更難了。
記者：這次採用新的網絡運維工具，實現了哪些目標?
劉翰騰：nCompass可視化智能流量監控平臺(以下簡稱nCompass)就像保衛部安防監控的總控室，它可以知道醫院整體的各個服務環節之間的通訊過程，知道誰找誰的時候變化量是多少，性能延遲是多大，流量有多高。各個環節之間的通訊流量回溯的時候，可以爲定位診斷故障的原因提供一個更好的視角。從整體到局部的故障定位會加速很多，提高了人效和準確性。
3:從創新技術到醫療應用場景的落地，支撐前、中、後端臺高效運轉的秘訣
記者：能不能請您介紹幾個流量監控平臺幫助解決運維故障定位的例子?
劉翰騰：我們影像有兩類典型用戶，一類是放射科的醫生，因爲他要根據檢查的影像寫報告，如果他的診斷報告沒出來，那麼外科比如需要做一些手術干預前，要等這些意見的時候，就會降低臨牀的工作效率了。另外一類用戶是其他科室的醫生，他可能也會自己直接去看影像結果，比如說門診的醫生，他要對病人的病情做評估，去做一些門診處方的判定等，如果這個影像慢，也會直接影響到門診病人流量的週轉，就會導致門診排隊。還有我們正在開發的第三個業務，就是“雲膠片”。以後可能會允許病人在手機端直接打開影像，病人可以拿這個影像給第三方的醫生看。如果這個體驗不好，那麼其他醫生在會診時可能就會覺得這個資料我不看了，我就看其它的，這個對醫療質量的全面性就會有影響了。現在有了nCompass以後，就能精準定位到全景影像打開慢到底是哪裡出了問題，知道該如何去優化。
比如去年12月28日下午四點半左右很多用戶反饋訪問“全景影像系統”時出現頁面打不開無法訪問的情況。經過nCompass可以看到一些指標異常的情況，初步懷疑是F5負載節點出現了問題。
通過HTTP分析模板和數據包驗證，可以得到分析結論，是由於掃描漏洞設備的瞬間大量訪問,觸發了F5安全保護機制，導致部分正常的業務訪問也無法進行，從而引發此次故障。那麼我們就很快進行了針對性處理，使全景影像系統恢復了正常打開。
案例2預約掛號慢
劉翰騰：還有比如我們門診的叫號系統，醫生也經常反映說叫號很慢，但是又不是全部科室的叫號慢，可能只是某個科室慢。這種情況下獨立看每一臺服務器的性能都正常，但是通過nCompass就可以發現，原來服務器在調用某個科室時它的調用表的邏輯是有問題的。通過nCompass的模型可以細緻定位出某個功能函數的入參有問題，這一點已經有很大的啓發性了。
劉翰騰：之前由於只是對設備的可用性進行監控，缺少應用可用性方面的監控，很多時候出現投訴時，很難找到問題所在。例如，門診醫生投訴訪問電子病歷慢，之前的工具只能對設備的可用性進行監控及排查，沒有辦法快速有效地評估客戶的使用體驗，判斷具體是訪問哪個URL慢，調用哪個參數以及查詢的哪個數據庫語句是有延遲的，無法對用戶訪問進行全程的跟蹤。包括電子申請單，以前也是經常被門診醫生投訴，等待電子申請單彈出的時間太長了，導致醫生門診的效率變低，患者體驗不好。
現在我們也是通過這種流量模型來看，通過應用的端到端視圖展現業務系統各節點的訪問關係以及運行狀態，可以做到實時監控，而且視圖中的數據支持靈活的編輯、深度鑽取等功能，可以進行業務邏輯梳理，形成各業務系統的端到端可視化監控。當故障發生時可通過指標顏色以及數值的變化快速鎖定故障節點。這樣就可以幫助我們運維人員很快找到到底是誰的通訊過程是有問題的。
4:展望：智慧醫療的IT架構設計基礎是以用戶體驗爲核心
記者：未來對醫院的運維自動化還有哪些建設想法?
劉翰騰：去年我院獲得“2020全國智慧醫院建設優秀案例”授牌。這也是對我院堅持信息技術創新，提升服務能力的階段性成果給予了充分肯定。作爲醫院的技術支持部門，信息中心一直以用戶體驗爲核心，並積極探索優化醫院IT資產管理效率的最佳實踐路徑。
目前在智能監控方面我們已經基本實現了精準告警，那麼在未來的運維建設上，我們還有一些目標想要實現，比如在應用的可用性監測方面，使用智能基線跟蹤生產側的變化過程，基於AI算法及產品內置的故障分析邏輯，實現告警事件自動化智能分析，提升故障的響應效率。而在性能側方面通過深層次的隱患巡檢分析，能幫我們及時發現業務系統運行中的隱患問題，規避嚴重故障的發生。在安全側則想要建立及時預警的機制，比如基於網絡流量和防火牆配置，監控防火牆實時狀態，實現策略優化、合規檢查和策略變更分析等。
這些都是我們下一步想通過nCompass平臺實現的技術能力，相信結合這些先進的技術能力，會進一步提升前端用戶體驗，提升我院的綜合服務能力。