数据猿大致梳理了几次影响较大的各地疫情软件故障事件如下。

可以看到，对于各地疫情软件故障后的问责情况，数据猿也只发现西安对于相关官员进行了问责，而对于技术厂商的责任则因复杂的技术原因抑或是预算等原因少有见公开问责的报道。

虽然各地供应商不一，但故障出现的时候大多与访问量增加有关，核酸系统的业务场景并不复杂，系统崩溃的原因几乎都是因为“并发量太大” 。以今年9月初成都核酸系统崩溃事件为例，虽然东软集团的声明中说是网络原因，但四川信管局立马对网络覆盖良好没有故障进行了回复。

据专业人士分析，该次系统崩溃可能是因为核酸的NG负载均衡不支持弹性扩容，难以应对系统高并发。简而言之，就像“路窄车道少不限流”的高速路，一旦大量车流同时涌入将导致全线拥堵甚至停滞。目前，业内对核酸系统崩溃的可能性诱因分析，大多也集中在服务器、数据库、压力测试等IT架构设计与运维方面。

对于本次因为成都疫情深陷舆论漩涡的东软，根据其微信公众号显示，东软全场景疫情病原体检测信息系统是东软于2020年12月开发，新冠疫情爆发以来，东软核酸检测系统已在国内17个省120多个地市部署应用，包括北京、上海、重庆、天津等人口超大型城市，已累计检测超过140亿人次。但东软并不是第一次出现类似事件，如上表所示，今年1月份，西安“一码通”就曾发生故障，市民在每日例行核酸检测过程中，遭遇了无法打开个人健康码的情况。而西安“一码通”背后的主要承接方中就包括东软集团。

核酸系统崩溃的“锅”，东软甩不掉

外行看热闹，内行看门道。我们需要透过一次次的事故，来看到导致事故的内部原因。只有这样，问题才能得到真正的解决。那么，究竟“健康宝”崩了的原因是什么呢？谁又该为“健康宝”的“崩溃”承担责任……

想要弄清这些问题，必须要回归到“健康宝”的“诞生”流程上。一般来说，政府部门不会直接参与研发，而是通过招投标的形式，承包给符合条件的企业进行研发和后期的技术维护，系统的运营方面一般由政府部门或者政府委托的政府平台负责系统投入后的运营和管理工作。

从系统研发的角度来看，“健康宝”的整个工作原理可以简化为三个部分：

首先是信息采集。在第一次打开小程序时，用户均需要填写自己的个人信息，包括姓名、身份证号、住址等；

其次是信息审核。在提交信息资料后，系统会快速的根据填写的个人信息，与背后的数据库进行交叉验证，从而确定个人信息的真实性和健康风险级别。在审核过程中，个人信息资料至少要跟三套大数据系统进行验证：一是卫健委的数据，主要是确定健康信息；二是公安部门的数据，主要是确定户籍状况和社会关系；三是运营商的数据，主要是确定用户的活动轨迹。

最后是“健康码”动态管理。也就是根据“健康码”的动态管理规则，最后系统“赋码”。

看上去整个过程很简单，但用的人多了，并没有让它更“智能”，反而经常“崩了”。作为一个系统化的产品，“崩了”这事非常常见，就像女孩子经常说“身体不舒服”一样，背后的原因可能五花八门。

尽管原因复杂，我们仍然可以把这些问题归结为三类：第一类是硬件问题，比如：访问量过大导致服务器瘫痪、网络带宽性能不足等，都属于硬件问题；第二类是软件问题，比如设计缺陷的问题等；第三类是管理问题，比如：后台运营等。管理方面的问题相对比较复杂，既有直接管理的问题，也有间接管理的问题。不同类型的问题，责任划分的依据也有所区别。

先说硬件方面的问题。其实硬件方面的问题就是两类：一是硬件的质量是否合格，二是硬件的数量是否与需求匹配。前者出现问题由生产厂商和鉴定机构承担责任，后者出现问题则是采购方的决策者承担责任。

再说软件方面的问题。软件方面的问题更多的与软件开发方有直接关系，一旦判定是软件本身的问题，开发方肯定难辞其咎。当然，有些情况下也不能仅仅追究开发方的责任，毕竟软件的开发多数是基于硬件设备，有可能某些潜在的问题在开发阶段曾向甲方领导层作出过提醒，但是没有被重视，在这种情况下，如果后续的运营中出现问题，甲方领导层也需要承担相应责任。

最后说管理方面。管理方面的问题有两层，一层是项目投入使用过程中的运营维护，如果出现相关问题，一般是要追究相关人员的责任，另一层是相关人员上级领导的责任，主要是基于“谁领导谁负责”的原则。

基于上述的责任认定框架，我们不妨分析近期的成都核酸系统崩溃事件中，供应商东软集团究竟该不该承担责任。

成都市要求从9月1日至4日，在全市范围内开展全员核酸检测，核酸检测系统在9月1日、2日、3日接连出现异常，系统出现响应延迟、卡顿等现象，由此导致采样排队时间过长，核酸检测进度缓慢，部分居民在雨中“罚站”。事后，成都核酸检测系统的供应商——东软集团被骂上热搜，而东软集团发布声明，“东软的核酸检测系统属于应用软件，其能否顺畅运行与核酸码等相关应用系统、后台的服务器、算力、网络带宽、甚至防火墙配置等因素都紧密相关，而这些系统并非由东软提供，当快速部署、切换时，初期往往会面临协调稳定问题。”然而，声明发布没多久，四川省通信管理局发文回应称，“相关部门全力做好‘四川天府健康通’、核酸检测等重点涉疫系统网络保障，全市通信网络运行平稳，各核酸检测点移动网络覆盖良好，没有出现网络拥塞和故障。”

故障发生了，东软急忙撇清关系，究竟是谁的责任？我们不妨按照上面的分析框架来梳理推测一下。

在核酸检测系统出现故障的同时，成都的网友仍然可以刷微博、玩抖音、观看线上演唱会，由此可见4G/5G网络没问题，完全畅通。同样是应用软件，别人家的可以连上网，而核酸检测系统却不可以，要说不是系统的问题还真是“见鬼”了。

再进一步分析，在全员核酸检测时，核酸检测系统主要的应用单位是成都市的各个核酸检测点以及其他疫情防控服务部门，工作内容主要是通过系统做简单的录入信息、上传信息等工作。根据成都市公布的全市核酸检测点的数量发现，截止到8月31日，成都市共有2565处核酸检测点，我们做一个简单的测算，在全员静默管理期间进行全员核酸检测，这2565处核酸检测点同时工作，则核酸检测系统的并发也就每秒2565左右，在2022年的今天，这放在IT系统来说压力不算大。

最后我们再分析一下核酸检测系统。目前并没有公开资料找到成都市核酸检测系统的产品架构，但是我们在东软集团的官方网站上找到了类似产品的架构，如下图所示。根据该产品的架构和描述，我们推测，各地部署的东软核酸检测系统应该是在此产品的基础上略微做了调整。

（东软集团智慧疫情防控全场景解决方案，来源：东软集团官网）

通过官网的介绍来看，东软集团智慧疫情防控全场景解决方案主要运用的是大数据的采集、清理、整合和交换等技术，即便是遇到了高流量、高并发的紧急情况，正常来说是可以通过增加服务节点并将新节点加入原服务集群的方式，实现快速扩容。但是根据结果来看，显然其提供的核酸检测系统在技术上并没有达到。因此，只能说东软集团的声明有些“自欺欺人”了。

在上述的一番推理之后，再来做责任的认定其实就比较清楚了，大概率是因为东软的软件设计问题导致了后续问题的发生，而且在9月2日凌晨，东软的全场景疫情病原体检测信息系统紧急上线并首次投入使用，新系统的上线难免会出现稳定性问题。所以，如果一定要追究责任的话，东软集团“无处可躲”。

总体来说，前期随着各地“健康宝”系统的不断升级，崩溃的次数和趋势确是在减少，但是并不意味着类似事件不会再发生。为了减少此类事件的频繁发生，运营部门仍然需要在以下两方面做出努力。

在外部系统方面，需要严格检查外部服务提供商的能力和水平，一定要仔细检查他们的工作；其次，确保所有数据都安全备份；第三，确保选择合适的数据库部署方式和策略，高度敏感的数据不适合存储在公有云解决方案中。

在内部运营方面，不断监视数据库运行状况，尤其是数据库错误的情况下，确保业务平稳运行；其次，在运营人员方面，提升管理人员的战略思维，培养快速、流畅的应对突发状况的能力。

只有在软件、硬件和管理方面同时提升和维护，才能保证“健康宝”安全、稳定的运营和服务疫情防控。

不崩只是底线，数据跨省打通也是刚需

除了频繁崩溃外，各地“健康宝”系统和数据不能打通，导致健康码各地不能互认，给用户带来麻烦的同时，也给疫情流调带来困难，这个问题究竟如何解？

这个问题其实难点不多，但解决起来比较费劲。首先，“健康宝”系统需要的数据包括：个人信息数据、医疗状况数据、行程轨迹数据。个人信息数据在公安部门的系统中，医疗状况的数据在卫健委部门的系统中，个人行程轨迹的数据在运营商的系统中，这三个数据中，卫健委部门的数据相对复杂一点，因为各地卫生健康部门的数据并没有完全打通，在数字化推进的过程中，地方政府选择合作的供应商、政府系统并不相同，而且出于对当地居民数据安全和隐私的考虑，这些数据基本存储在各自的私有云中，所以一朵朵“政府云”之间短时间难以打通。

不过，虽然短时间内难以实现全国“一码通”，但“一省一码”已经全部实现。在9月初国家卫健委召开的新闻发布会上，国家卫健委规划司司长毛群安宣布全国所有省份实现了“一省一码”，而且后续也会继续推进健康码互认。其实，不少省市也开始逐步的拓展核酸检测结果的异地互认，比如北京健康宝在7月30日开始，就可以实现查询外省市核酸检测结果，并上传至北京健康宝。

不积跬步无以至千里，虽然这小小的一步看似轻巧简单，可背后的努力值得肯定，未来的全国“一码通”值得期待。

来源：数据猿