李冬|西安一码通“崩溃”调查：一场系统性失灵的数字政府再思考

2021年12月20日，西安“一码通”第一次故障时，曾有消息将故障原因指向属于应用层服务提供商的美林数据，但美林数据随即回应称：美林主要负责一码通后台，提供算法，‘一码通’运营不属于美林。
安恒信息给钛媒体App发来回应称，“安恒信息负责‘一码通’的一部分安全工作，保障系统不被网络攻击，到现在为止，没有发现网络攻击迹象。”
也有网友捕风捉影，分析称西安一码通的“码”采用图片形式下发，导致CDN（内容分发网络）冲垮负载均衡。钛媒体App求证获悉，“二维码以图片形式下发”的分析系误读，健康码本身并不是以图片形式传输。健康码就是个ID，通过ID指向数据库找出对应的信息。
最诡异的是，有传言称西安“一码通”建设是花了27万，让小公司几个实习生来做的项目。对此钛媒体App查阅官方资料得知，在西安市相关单位发布的中标公告中，确实有条公告信息符合“27万”、“不知名”公司的条件，并且标的中也明确出现了“一码通”字眼。

文章插图
西安科学技术局创新一码通系统招标信息
但钛媒体App求证发现，此“一码通”并非西安“一码通”。这项20几万的项目由“西安市科学技术局”主体招标，时间为2021年11月26日，并且公告全称为“《创新一码通系统开发项目竞争性磋商公告》”，公告明确表示该项目为以西安市创码通系统（以下简称“创码通”）为抓手，加快推动西安“秦创原”整体战略的落地建设。也就是说该项目实际是西安市“创码通”项目并非西安“一码通”。此前传言为断章取义。
“一码通”为何不通？在杂乱的信息中，有接近西安“一码通”项目人士向钛媒体App判断称，问题可能在于连接“一码通”和西安政务云的安全防护机制过载，让“一码通”平台无法调用政务云上的数据，因此“一码通”一直无法加载出数据。这一说法也侧面排除了应用层故障，将问题矛头指向政务云平台以及政务云平台上的安全防护机制。
综合多方给我们的回复，从技术上讲，“并发访问量过大触发防火墙防御阈值，同时还存在网络堵塞、丢包现象”的说法最为可靠，但无法单纯将责任归至其中任何一方。
简单来理解则是，处于应用层的西安“一码通”在运行过程中由于流量过载，触发了底层政务云的防火墙防御机制。——两个来自不同标的的各方本来各司其职，但在实际运行过程中却成为了彼此影响的统一系统。他们看似都没有直接责任，却像蝴蝶效应一般，酿成最终故障。
在公开信息显示的西安“一码通”事故相关的的近十位服务商中，众多争议主要集中在三家厂商——东软、阿里云和启明星辰。
东软负责西安“一码通”信息技术平台软件产品及相关平台功能定制化开发服务。据了解，起初该平台并不是为了支撑西安全员的核酸检测（核酸检测需要亮码），所以平台并没有设计与之对应的并发指标。而且在12月20日西安“一码通”出现故障后，QPS（每秒查询率）已经扩容至系统最大值4万，并且重新完善了代码，但这依然不足以支撑西安全城1200万人的集中检测并发量。
阿里云牵扯其中，不仅因为出现在一码通的采购清单中，也因为其负责西安政务云的建设。政务云核心都采用私有云方式建设，西安政务云也是如此。
前述接近项目消息人士透露，阿里云智能DNS解析在“一码通”中出现了解析错误问题，两条为“一码通”预留的VIP线路中，有一条出现故障。此外，RDS数据库中大量慢SQL，也导致了流量拥堵。这两个问题在后续排查中被快速解决。

李冬|西安一码通“崩溃”调查：一场系统性失灵的数字政府再思考｜钛媒体深度( 二 )