从核酸检测到健康码，为什么系统总是“崩了”？

随着疫情反复，频频崩溃的数据平台系统引起了人们的注意。
“我早上6点就起来了，6点半去排队，7点开始测，7点20就完事儿啦！”天津市民刘先生大清早就按照要求参加了核酸检测，等到他看到了微信群里有朋友在抱怨核酸检测系统的崩溃时，才觉得10日的早起，值了！
微信记录显示，有天津市民在10日10：40左右抱怨在快要排到时因核酸检测系统崩溃不得不暂缓检测，等到11：30时系统才重新恢复。“白排了吗？”刘先生问朋友，对方回答没有，因为喊了家人“轮流替会儿”。
官方系统为何如此“脆弱”？
各地大数据系统投入不少，除了最近天津的核酸检测系统出现崩溃情况之外，还属健康码最为常用，“崩溃”率也最高。
2021年，山东、西安、天津等地都先后出现过故障。事后披露的原因多为当日最高查询峰值激增导致系统阻塞。比如山东去年8月份当日最高查询峰值达60.96万人次/分钟，同前一工作日相比激增8倍，是去年最高峰值的2.5倍，西安“一码通”用户访问量激增时出现每秒访问量达到以往峰值的10倍以上，而粤康码流量异常增大时最高达每分钟140万次，超出承载极限，触发系统保护机制。
第一财经注意到，相对于千万级的常住人口数量，这些系统承载的每分钟的访问量在百万级别。

“传统的做法通常会分为两类，一是整合多方数据后，以统一的数据资源平台面向政府体系提供服务为主，另一类是部署两套系统分别应对政府内部服务和面向居民的服务体系。前者的架构在面对居民高并发的应用场景时容易遇到瓶颈；后者则可能会对数据资源进行重复建设。”一位业内人士告诉第一财经，这些系统的构建涉及基础资源层、网络层、应用层多个专业厂商，出现问题的表征一定是访问崩溃，但背后原因未必相同，因此不好对已经出现崩溃情况的系统做出评价。
目前，各健康码、核酸检测系统的运营公司大多是经由当地的大数据中心招投标建设而成，从股东方也可一窥技术提供方。比如“粤康码”由数字广东网络建设有限公司负责开发及技术维护，背后的股东包括中国电子、三大运营商和腾讯。西安的一码通由西安市大数据资源管理局牵头，中国电信西安分公司开发部署。记者曾联系了多家与健康数据平台或当地大数据中心有业务往来的技术供应方，但都得到了谢绝采访的回复。
不过，记者了解到，通常这样的系统会采用分布式大数据技术，结合所在地的人口情况、上下班出现的访问高峰设计出相应的系统容量和冗余量。“健康码的赋码业务逻辑需要根据运营商手机相关数据、公安人口相关数据、卫健委人员健康状态等数据进行离线加工融合，并通过实时对接健康云等用户注册信息融合加工达到秒级别的生产数据以快速控制风险。所以团队确定使用大数据分析和实时流处理引擎对这一业务场景进行技术支撑。”一位参与过某地健康码系统搭建的相关人士介绍称。
此外，还要对系统各环节下的全链路全方位测压，以保证系统上线足够高的可靠性和稳定性。
应急层面上看，系统要有足够的弹性伸缩能力。在访问出现激增的特殊情况时，能够快速扩容，满足相应的访问需求，比如进行容器化的设计保证底层基础设施具备良好的弹性伸缩能力。
除去访问容量冗余角度上的考虑，还要考虑对于整体系统层面的全流程监控设计，如网络访问情况，健康码接口访问统计，日峰值出现时段等指标。这不仅为实时大屏提供了相应的数据指标支撑，同时也为团队验证系统容量设计，监控保障系统稳定运行，以及后续实现资源动态扩缩容提供了决策依据。
即便考虑再周全，这世上当然没有完美无缺的系统，特别是在计算资源本身就是有限的情况下。业内人士提到需要配套合理的开发流程和运营管理流程来有效的支撑软件系统的持续升级和健康运行。比如在总体系统设计上，针对关键软件服务和数据配备应急资源和环境进行分级。平时这部分资源可用于一些创新业务或非关键性业务，一旦有临时性的业务需求如全员核酸时，可以及时将这部分应急资源用于业务扩容来支撑。
这有些类似于12306系统将订票和查询余票业务分开，在各个子系统按需进行扩缩容的设计，同样，也不建议在关键高并发的健康码查询路径上关联过多的非关键业务，不同业务采用微服务等新型软件开发方式来开发，结合容器云等技术来实现动态的按需扩缩容，同时保证各个业务之间不互相影响，如上传核酸报告、查询核算报告、查询健康码等业务要分开。
“在某些关键业务失灵后能够快速地从备份系统恢复数据并支持业务重新上线，这样即使某个业务短暂出现问题，我们可以通过灾备系统来快速恢复业务和数据，这样老百姓的等待时间可以从一天缩减到几分钟。”这位业内人士说。

---