開篇

　　兒時的我，生活在遙遠青藏高原的一個邊遠小城，當年，每個單位喝水都是自己打井，城市里矗立著大大小小各式各樣的水塔，在高原的藍天白云襯托下，形成不一樣的風景。高原的老兵們都知道，過了昆侖山口，望見水塔，那就快到城市了。

　　挑水是那時學校值日生每日的任務，大家帶著水桶和扁擔，三五成群的去到水塔邊，男生們嬉戲打鬧著，玩得不亦樂乎，往往一桶水運回教室只剩下了半桶。冬天挑水，則需要小心翼翼，走在結冰的路上，一不小心滑倒，不僅是水沒了，就連棉衣棉褲都會濕透，那冰冷的滋味可不好受。那時就想，要是有自來水就好了，水龍頭一開，嘩嘩的水就來了，我們就不要擔水這么辛苦了。

　　如今，自來水早就是城市的標配，誰也不關心它到底怎么來的。自來水公司接管了城市的供水需求，統一生產、統一布網、統一管理、統一收費，我們只需要按需付費即可。不好的就是，一旦它供水出現問題，會影響幾萬甚至幾十萬人的工作和生活。

　　寫這篇文章過程中，抖音平臺就在給我推送慈善視頻，為某鄉村的孩子能用上干凈的飲用水，奉獻愛心。我在感慨大數據強大的數據收集分析能力之外，也感慨我們今天的生活差距之大，一些我們已經習以為常的東西，在某些地區依然還非常之難得，甚至可以說是奢侈品。

　　其實，信息化也有同樣的場景，在沿海發達地區的醫院，信息化水平就是比其他地區高很多。一些信息化建設高水平的醫院已經開始探索元宇宙、區塊鏈的應用了，而邊遠地區的醫院，往往還在煩惱能否找到一個合適的人手把HIS系統的運維工作做好。

　　對比來看，今天我們的信息系統不也類似于生活用水的變遷歷史么。各家單位自建的系統就類似于原來各單位的供水塔，建設、維修、維護等工作，事無巨細都是自己經管，還很難做到用戶滿意。這兩年，隨著云技術的成熟應用，加之醫院的觀念的改變，一些應用系統逐步開始上云。上云后，使用確實更加方便了，只要網絡通暢，也不用關心服務器資源，不用關注機房的管理，不用關注網絡安全的問題，統統都可以托付給服務商。就像各地的核酸采集都是云端部署了，在任何地方，只要手機有信號，打開健康碼，掃碼登記、核酸檢測，絲滑順暢。如果我們自己部署系統，那就得架設網絡、安裝電腦和打印機、部署系統，每個環節都不能少，每個核酸采集點還得配備信息運維人員，更重要的是無法做到快速響應。

　　如今“我們只顧用，其他的都交給服務商”，確實方便了很多。

找準云服務場景

　　“軟件即服務”是一個不錯的理念，但是更需要強大的技術力量去實現。強如國家電網這類巨無霸企業，經過幾十年的發展，在電力行業積累了大量的原創性技術和人才儲備，技術實力已經全球獨步。據說，關于特高壓的技術，外國人想了解也都必須讀中文教科書。云端部署能力已經完全能夠滿足國內需求，技術輸出已經成為常態，所以這幾年我們的特高壓技術開始走向世界，然而與自來水公司、供電局這樣的社會公共事業單位不同的是，現在的醫療軟件云服務商還很弱小。無論是資金、市場還是技術力量，云服務都存在許多需要提升的地方，還需要我們有著清醒的認識，尤其是不能人云亦云，需要給云服務找準場景，找對應用。結合我們的應用，對云服務使用時需要注意的問題加以總結，供大家參考。

　　1.無論是公有云還是私有云，資源規劃、架構設計最為重要。工作中我們時常會聽到在做產品介紹時，將“云”作為一個賣點，甚至有“一云遮百丑”的推廣模式，然而當用起來才發現，系統各種不好用，不易用。其實云技術作為一種手段雖然改變了計算機編程的開發模式，但是從架構設計上原有的設計模型依然適用。也就是從分析業務需求、企業架構到業務架構再到系統架構、以至于網絡架構和數據架構這些方面的內容其實并沒有變。甚至云服務在設計時更應該考慮如何應對不可預知的超大數據的訪問問題。因此我們在選擇云服務時，需要仔細考察其架構設計方案，選擇合適的產品。

　　2.資源的使用容易被忽視，尤其是需要重視可能出現的資源瓶頸。正因為云服務的方便性，往往讓我們忽視云服務所依靠的硬件資源。其實無論是公有云還是私有云，都必須依靠具體的硬件資源才能實現。因此，我們不能因為云部署的方便性，忽視了對資源的管理。應該加強對硬件資源的監測，加強日常運維管理，避免出現雞蛋放在一個籃子里，籃子破了雞飛蛋打。這正值年底預算填報時間，大家可以檢測一下各自的超融合或者虛擬化的硬件性能，提前謀劃，提早布局。

　　3.云服務模式下，個性化需求不易滿足。云服務一個特點就是標準化程度高，而我們目前的醫療信息化建設現狀就是個性化需求尤為突出。在利用云服務時，我們就要有這個心理準備，“那就是我們采購的服務就是公司提供的標準服務，個性化需求很難被滿足”。市場用戶越多越成熟的云端服務產品，對于醫院的“個性化需求”就越不會去滿足。他們可能會收集我們的需求，在未來的版本更新迭代中包含進去。因為不管商務經理怎么吹，程序員也不會為了你這個獨特的需求去改動代碼的。當然也存在有技術性問題，可能你這需求“傷筋動骨”了，做架構設計時壓根沒考慮這么多因素，不能改，一改系統就得重構，代價太多。

　　4.云服務模式現場運維能力會被逐步弱化。當資源集中在云端，現場運維人員必將越來越被邊緣化，甚至只有客戶經理與我們對接。作為客戶，我們見到的最多的就是客服經理，她會用她的微笑來“平息你的怒火”，想聯系技術人員，那叫申請技術支援，就算你發火也沒有用。你要知道公司的核心團隊在總部、核心硬件在總部，用戶就是系統的一個瀏覽器而已，理論上只要總部穩定高效，每一個用戶體驗就會好，所以公司根本不會現場配備能力強的運維人員。但是這種模式也會造成研發人員與實際需求的脫節，無法形成共情。你在現場舉著手機找信號急得不可開交;他在云端說系統運行正常，為甲乙丙丁誰的責任，爭論不休。

　　5.云服務環境下，故障排查的難度可能更大。云服務涉及到基礎資源(計算資源、存儲資源)、網絡鏈路、應用系統、安全管理配置等環節，一旦出現問題，定位錯誤和問題會比較復雜，進而影響到恢復時間。我們必須腦海里有著清晰的架構，才能一步步的去找出故障點，因為當故障出現時，每一個服務商都會先撇清自己的問題，有時候故障還涉及到需要協調線路運營商、硬件資源提供商、軟件系統服務商、安全運維團隊等等的技術資源。這也就造成在原本單機模式很容易解決的簡單的故障，一旦上云后反而解決問題的時間更長了。

　　6.數據安全管控難度更大，尤其是數據上云后，很難再受到管控。你并不能知曉數據被誰用了，被誰拷貝復制了多少次，這種缺乏第三方監管的狀態，用戶就成了安全責任承擔者。因此在網絡安全越發嚴格的今天，我們更應該在采用云服務時，明確將數據安全責任寫入合同。尤其是醫療數據的高價值和高關注度，更應該應用與數據安全同步。對于存儲在云端的數據，建議應該有本地的一套備份數據，并且具有再次利用數據的能力。

　　7.用“乙方思維”去做好甲方的事情。“我們買的是服務”這句話背后的含義就是，服務是要支付費用的，這與傳統的本地化部署有根本的不同。原來我們購買了軟件，超過維保期，只要軟件穩定運行，或者說我們掌握了自我運維的能力，往往都不再給軟件商支付服務費。這在一些人腦海里形成了定式，不用支付軟件運維費用。但是對于云服務則不同，你不付錢，肯定就會面臨斷供的風險。這個主動權往往就在服務提供方，而不是使用方。對于云服務來說，當我們選擇了一個服務商后，從事實上，我們其實就已經從甲方變成了乙方。無論是按時付費、按需付費還是按流量付費，付費是我們必須“遵守的準則”。否則，可能因為維護費沒有談妥，支付服務費不及時，我們直接被停止了服務。甚至我們還得面對云服務商黃了，服務到期后，云消失了，無系統可用的尷尬處境。

　　技術和用戶是互相成長、相互促進的，我們就應該在其中去尋找平衡。幾年前，我們還在不停的爭論，是否應該采取云服務，今天云服務已經成為一種常規的信息服務手段。讓子彈飛一會，最終通過市場作用，通過行業主管部門的引導和監督，優勝劣汰，最終會形成個別優勢企業，進行重點扶持，云服務也會更規范、更標準。

尾聲

　　這些年，無論在那里居住，我家里都會準備一個水桶，用于儲水，以備不時之需。如何解決云服務下的不時之需，相信這也是一個蠻不錯的課題。你如果有答案，歡迎留言告訴我。

　　作者簡介

　　黃昊，現任陸軍特色醫學中心信息科主任、高級工程師，CHIMA常委，中國研究型醫院學會醫院信息化分會常務理事，中國研究型醫院學會醫院信息化分會智慧醫療專委會主任委員。