黄昊：云技术应用的烦恼

开篇

　　儿时的我，生活在遥远青藏高原的一个边远小城，当年，每个单位喝水都是自己打井，城市里矗立着大大小小各式各样的水塔，在高原的蓝天白云衬托下，形成不一样的风景。高原的老兵们都知道，过了昆仑山口，望见水塔，那就快到城市了。

　　挑水是那时学校值日生每日的任务，大家带着水桶和扁担，三五成群的去到水塔边，男生们嬉戏打闹着，玩得不亦乐乎，往往一桶水运回教室只剩下了半桶。冬天挑水，则需要小心翼翼，走在结冰的路上，一不小心滑倒，不仅是水没了，就连棉衣棉裤都会湿透，那冰冷的滋味可不好受。那时就想，要是有自来水就好了，水龙头一开，哗哗的水就来了，我们就不要担水这么辛苦了。

　　如今，自来水早就是城市的标配，谁也不关心它到底怎么来的。自来水公司接管了城市的供水需求，统一生产、统一布网、统一管理、统一收费，我们只需要按需付费即可。不好的就是，一旦它供水出现问题，会影响几万甚至几十万人的工作和生活。

　　写这篇文章过程中，抖音平台就在给我推送慈善视频，为某乡村的孩子能用上干净的饮用水，奉献爱心。我在感慨大数据强大的数据收集分析能力之外，也感慨我们今天的生活差距之大，一些我们已经习以为常的东西，在某些地区依然还非常之难得，甚至可以说是奢侈品。

　　其实，信息化也有同样的场景，在沿海发达地区的医院，信息化水平就是比其他地区高很多。一些信息化建设高水平的医院已经开始探索元宇宙、区块链的应用了，而边远地区的医院，往往还在烦恼能否找到一个合适的人手把HIS系统的运维工作做好。

　　对比来看，今天我们的信息系统不也类似于生活用水的变迁历史么。各家单位自建的系统就类似于原来各单位的供水塔，建设、维修、维护等工作，事无巨细都是自己经管，还很难做到用户满意。这两年，随着云技术的成熟应用，加之医院的观念的改变，一些应用系统逐步开始上云。上云后，使用确实更加方便了，只要网络通畅，也不用关心服务器资源，不用关注机房的管理，不用关注网络安全的问题，统统都可以托付给服务商。就像各地的核酸采集都是云端部署了，在任何地方，只要手机有信号，打开健康码，扫码登记、核酸检测，丝滑顺畅。如果我们自己部署系统，那就得架设网络、安装电脑和打印机、部署系统，每个环节都不能少，每个核酸采集点还得配备信息运维人员，更重要的是无法做到快速响应。

　　如今“我们只顾用，其他的都交给服务商”，确实方便了很多。

找准云服务场景

　　“软件即服务”是一个不错的理念，但是更需要强大的技术力量去实现。强如国家电网这类巨无霸企业，经过几十年的发展，在电力行业积累了大量的原创性技术和人才储备，技术实力已经全球独步。据说，关于特高压的技术，外国人想了解也都必须读中文教科书。云端部署能力已经完全能够满足国内需求，技术输出已经成为常态，所以这几年我们的特高压技术开始走向世界，然而与自来水公司、供电局这样的社会公共事业单位不同的是，现在的医疗软件云服务商还很弱小。无论是资金、市场还是技术力量，云服务都存在许多需要提升的地方，还需要我们有着清醒的认识，尤其是不能人云亦云，需要给云服务找准场景，找对应用。结合我们的应用，对云服务使用时需要注意的问题加以总结，供大家参考。

　　1.无论是公有云还是私有云，资源规划、架构设计最为重要。工作中我们时常会听到在做产品介绍时，将“云”作为一个卖点，甚至有“一云遮百丑”的推广模式，然而当用起来才发现，系统各种不好用，不易用。其实云技术作为一种手段虽然改变了计算机编程的开发模式，但是从架构设计上原有的设计模型依然适用。也就是从分析业务需求、企业架构到业务架构再到系统架构、以至于网络架构和数据架构这些方面的内容其实并没有变。甚至云服务在设计时更应该考虑如何应对不可预知的超大数据的访问问题。因此我们在选择云服务时，需要仔细考察其架构设计方案，选择合适的产品。

　　2.资源的使用容易被忽视，尤其是需要重视可能出现的资源瓶颈。正因为云服务的方便性，往往让我们忽视云服务所依靠的硬件资源。其实无论是公有云还是私有云，都必须依靠具体的硬件资源才能实现。因此，我们不能因为云部署的方便性，忽视了对资源的管理。应该加强对硬件资源的监测，加强日常运维管理，避免出现鸡蛋放在一个篮子里，篮子破了鸡飞蛋打。这正值年底预算填报时间，大家可以检测一下各自的超融合或者虚拟化的硬件性能，提前谋划，提早布局。

　　3.云服务模式下，个性化需求不易满足。云服务一个特点就是标准化程度高，而我们目前的医疗信息化建设现状就是个性化需求尤为突出。在利用云服务时，我们就要有这个心理准备，“那就是我们采购的服务就是公司提供的标准服务，个性化需求很难被满足”。市场用户越多越成熟的云端服务产品，对于医院的“个性化需求”就越不会去满足。他们可能会收集我们的需求，在未来的版本更新迭代中包含进去。因为不管商务经理怎么吹，程序员也不会为了你这个独特的需求去改动代码的。当然也存在有技术性问题，可能你这需求“伤筋动骨”了，做架构设计时压根没考虑这么多因素，不能改，一改系统就得重构，代价太多。

　　4.云服务模式现场运维能力会被逐步弱化。当资源集中在云端，现场运维人员必将越来越被边缘化，甚至只有客户经理与我们对接。作为客户，我们见到的最多的就是客服经理，她会用她的微笑来“平息你的怒火”，想联系技术人员，那叫申请技术支援，就算你发火也没有用。你要知道公司的核心团队在总部、核心硬件在总部，用户就是系统的一个浏览器而已，理论上只要总部稳定高效，每一个用户体验就会好，所以公司根本不会现场配备能力强的运维人员。但是这种模式也会造成研发人员与实际需求的脱节，无法形成共情。你在现场举着手机找信号急得不可开交;他在云端说系统运行正常，为甲乙丙丁谁的责任，争论不休。

　　5.云服务环境下，故障排查的难度可能更大。云服务涉及到基础资源(计算资源、存储资源)、网络链路、应用系统、安全管理配置等环节，一旦出现问题，定位错误和问题会比较复杂，进而影响到恢复时间。我们必须脑海里有着清晰的架构，才能一步步的去找出故障点，因为当故障出现时，每一个服务商都会先撇清自己的问题，有时候故障还涉及到需要协调线路运营商、硬件资源提供商、软件系统服务商、安全运维团队等等的技术资源。这也就造成在原本单机模式很容易解决的简单的故障，一旦上云后反而解决问题的时间更长了。

　　6.数据安全管控难度更大，尤其是数据上云后，很难再受到管控。你并不能知晓数据被谁用了，被谁拷贝复制了多少次，这种缺乏第三方监管的状态，用户就成了安全责任承担者。因此在网络安全越发严格的今天，我们更应该在采用云服务时，明确将数据安全责任写入合同。尤其是医疗数据的高价值和高关注度，更应该应用与数据安全同步。对于存储在云端的数据，建议应该有本地的一套备份数据，并且具有再次利用数据的能力。

　　7.用“乙方思维”去做好甲方的事情。“我们买的是服务”这句话背后的含义就是，服务是要支付费用的，这与传统的本地化部署有根本的不同。原来我们购买了软件，超过维保期，只要软件稳定运行，或者说我们掌握了自我运维的能力，往往都不再给软件商支付服务费。这在一些人脑海里形成了定式，不用支付软件运维费用。但是对于云服务则不同，你不付钱，肯定就会面临断供的风险。这个主动权往往就在服务提供方，而不是使用方。对于云服务来说，当我们选择了一个服务商后，从事实上，我们其实就已经从甲方变成了乙方。无论是按时付费、按需付费还是按流量付费，付费是我们必须“遵守的准则”。否则，可能因为维护费没有谈妥，支付服务费不及时，我们直接被停止了服务。甚至我们还得面对云服务商黄了，服务到期后，云消失了，无系统可用的尴尬处境。

　　技术和用户是互相成长、相互促进的，我们就应该在其中去寻找平衡。几年前，我们还在不停的争论，是否应该采取云服务，今天云服务已经成为一种常规的信息服务手段。让子弹飞一会，最终通过市场作用，通过行业主管部门的引导和监督，优胜劣汰，最终会形成个别优势企业，进行重点扶持，云服务也会更规范、更标准。

尾声

　　这些年，无论在那里居住，我家里都会准备一个水桶，用于储水，以备不时之需。如何解决云服务下的不时之需，相信这也是一个蛮不错的课题。你如果有答案，欢迎留言告诉我。

　　作者简介

　　黄昊，现任陆军特色医学中心信息科主任、高级工程师，CHIMA常委，中国研究型医院学会医院信息化分会常务理事，中国研究型医院学会医院信息化分会智慧医疗专委会主任委员。