视点·观察|西安一码通“崩溃”调查:一场系统性失灵的再思考

1月4日,西安一码通又“崩”了,半个月崩溃两次,引发了业界关注,关于事件原因也引起外界诸多猜测 。1月6日下午5时许,东软集团(600718.SH)对投资者回应事故原因时,表示该故障与东软所处应用层无关 。回复称,在进行现场分析之后,专家提出:“要加强网络和信息安全,优化应急预案……防止出现网络安全事故 。”等指导意见 。
视点·观察|西安一码通“崩溃”调查:一场系统性失灵的再思考
文章图片


一位接近西安“一码通”项目的人士向钛媒体App表示,当下已排除应用层故障;且在故障排查和压力测试时发现,防火墙设备存在多次丢包现象 。由此可以判断,出故障的防火墙不属于应用层 。那么故障是由什么层面出现问题导致的?一次看似平常的健康码请求,跟防火墙有哪种关联,为什么会因为防火墙丢包造成故障?
针对上述情况,钛媒体App联系网络与信息安全专家李冬,据李冬判断,西安“一码通”属于政务工程,从系统安全上来说,西安市民访问西安“一码通”属于外网访问内网,二维码调后台数据用确实要过防火墙,如果并发量超过原有架构设计,确实会发生防火墙丢包的可能 。
钛媒体App从另一位接近西安“一码通”项目人士处获悉,自12月20日“一码通”故障后,多批专家组进驻调查,形成了多份报告,由官方最终拍板的报告尚未发布,但事实大致清楚,这是一起因流量过载、系统架构应对高并发不足,最终导致防火墙拦截数据无法返回的系统性故障 。
不过事实上,经钛媒体App编辑多方求证了解,在西安“一码通”故障事件中,防火墙丢包虽是最终原因,但或许并不是根本原因 。在诸多供应商和事件主体中,究竟是“谁”、在哪些环节出了问题,我们也做了一次全面复盘和还原 。
西安一码通的复杂供应商
西安一码通的系统建设涉及基础资源层、网络层、应用层等多个专业厂商,并且据钛媒体App了解,这些多个专业厂商在中标合同中分属不同标的,主要标的有两个 。
一个是“疫情防控平台一码通项目(以下简称:西安“一码通”),该项目总包为西安电信 。自2020年3月西安“一码通”上线后,西安电信以招标形式分包给近十家科技公司的服务,包括开发与运维、安全相关产品与服务、引擎软件产品、短信服务、大数据可视化等项目 。
另一个是“西安市电子政务统一平台”,该项目简称为“政务云”平台 。据钛媒体App了解到的消息,西安“一码通”以政务云平台为技术底座,基于政务云平台搭建,其基础资源层、网络层的所需的存储、网络、计算等服务均由政务云平台输送,而西安“一码通”通过西安电信购入的服务,可以统称为“应用层”服务 。

推荐阅读