被集火的西安“一码通”，为什么给群众添了堵

“一码通”再度宕机后，西安市委组织部1月5日公布：因履职不力，西安市大数据资源管理局党组书记、局长刘军停职检查。刘军此前分管的工作正是“一码通”工作专班，这一事件标志着行政问责的开始，同时也充满了尴尬。

此前“一码通”崩溃后，工信部已经派员指导“一码通”工作，也将这一工作的重要性提升到“政治站位”的高度。然而几天之后，“一码通”又崩了。

尽管有西安市民表示，这次崩溃恢复得很快，只用了近5小时就通了，比第一次好多了。但这一事件本身，仍然暴露出西安数字政务体系的严重问题，5小时才修复已经是严重落后于时代了。

此外，“一码通”工作是由西安大数据管理局负责监管的，但是“一码通”不是大数据业务。如果说“一码通”崩溃时第一次的访问量是一笔糊涂账，那么第二次就很清晰了。

1月4日，西安封城管控，“一码通”只用来做核酸和查核酸检测结果。由于崩溃时，核酸检测只是初步开始，因此查核酸检测结果的人并不多。同时，核酸检测是分批进行的，并且在同一批中还是排队进行。这么一算，当时同时访问“一码通”的人数，高峰期充其量也就是5分钟50万人。

“一码通”又没有什么复杂的交互，以查询为主。5分钟内50万人对不超过4000万人（2021年西安常住人口1295万，这里是从高估计的结果）的数据进行访问，这怎么能算是大数据业务呢？

因此，尽管是大数据资源管理局局长被问责，但是“一码通”就是一个常规业务。这一事件也说明，地方政府对信息产业的监管，目前还是合规性监管和价值观监管，在技术性监管方面乏善可陈。

那么我们就从技术角度出发看一看，常规业务“一码通”需要哪些保障，又是怎么崩溃的。

大型电子商务网站系统架构，来源CSDN

上图是常见的商务网站系统架构，代表了目前主流网站的技术架构和先进生产力，“一码通”业务的架构虽未公布，但也应该大同小异。类似架构的网站，数据送入用户手中，要经过发送请求、数据查询、服务器响应、服务器分发、网络传输和接收等过程（如下图所示）。

主流网站查询业务流程

这些过程中，可能出现的硬件问题是服务器过载，以及网络阻塞。

由于响应“一码通”应用的请求、分发数据、负载均衡都需要消耗服务器资源，因此访问量的增大必然带来服务器过载，目前服务器资源几乎都是以云的形式提供，服务器资源可实时增加。

疫情封城时，陕西本地其他云资源访问量下降。如果陕西的云提供商下决心保通“一码通”，甚至跨区域协调资源，“一码通”所需的服务器资源是有保证的。

网络阻塞，又分为上行阻塞和下行阻塞。上行阻塞就是用户向服务器发送的信息过多，占满了上行带宽。下行阻塞就是服务器向用户发送的信息太多，占满了下行带宽。如果是合理的网络占用，主要看陕西云服务提供商以及网络业务开发者的对接工作。从全国来看，云资源比陕西少的省也是没有任何问题的。

负载均衡问题目前还未完全解决，继续深入也非常困难。但这里说的困难，是大型互联网企业要考虑的。“一码通”的访问量，哪怕是用免费开源的Nginx和Apache也不难解决。

“一码通”的业务逻辑恰恰不合理，“一码通”的核心是健康码，然而“一码通”还融合了政务二维码扫描、公民电子证件、健康码、公积金、城市新闻、政务地图、幼儿托管、停车数据查询、天气、空气质量等等业务，是一个复杂的系统。

根据相关媒体的报道，至少有六家企业参与了“一码通”开发运营。

从数据库的角度讲，怕的是锁（数据库软件中的一种机制，用于防止意外写入）太多。12306系统的访问量比淘宝“双十一”期间的访问量要小好几倍，依然无法自如地应对春运，根源就在于火车票务业务的锁太多。

将各种业务集合为“一码通”，本身并不意味着锁更多。但将业务融合在一起后，就会催生出数据库联合查询的需求，以及更多需要锁的需求。有从事软件开发行业的西安网友，结合使用“一码通”的经历，指出：“一码通”在崩溃之前，疑似默认联合查询核酸检测结果以及健康码状态。

由于健康码状态和核酸检测结果的查询密度存在数量级的差异，如果网友反映的问题是真的，这种安排的合理性属实值得商榷。

同样地，将政府应用联合成“一码通”，也不利于服务器处理以及精简应用上传数据。因为健康码业务无需接收大量数据，而城市新闻、地方天气等功能都需要预先获取服务器的许多资源，更不用说这些功能还要产生大量的上行数据。

笔者愿意直说，这种将市民需求量相差很大的业务捆绑在一起的做法，是部门本位的体现，也浪费了大量资源。一个普通西安市民可能一天要出示3-4次健康码，但是城市新闻一天更新一次也够了。城市新闻陪着健康码更新，浪费了大量上下行带宽。

此外，将多种业务捆绑到一起后，在技术上往往就低不就高。很多政务系统老业务采用的技术栈十分陈旧，与需要较新技术支持的健康码捆绑到一起，成倍地放大运营中的风险因素。根据财新网的消息，有不愿透露姓名的内部人事说：“问题可能出在连接一码通和数据平台间的安全防护机制过载”。

如果财新网的报道属实，还是要怪“一码通”设计了这样冗杂不合理的业务，又跨了太多的机构和部门。

“一码通”并非一直这么复杂，疫情之初的“一码通”就十分简洁。现在这个“一码通”，是升级改造后的结果。这也许从一个侧面说明，为何爆发疫情人心惶惶时，“一码通”经历住了考验。反而是疫情爆发两年后，“一码通”多次突发瘫痪。

新旧一码通界面对比，左为现今版本，右为早期版本

待到“一码通”成为批判对象后，这样的文章就显得非常讽刺。不过从当初的报道中，我们还是能看到“一码通”后来出问题并非偶然，根源在于信息体系建设不完善。

“一码通”的核心功能是健康码，是怎么开发出来的呢？“保障专班召之即来、来之能战，主动整合既有产品能力，全体成员三天三夜不眠不休，研发出西安市个人电子识别码”。

也就是说健康码三天就研制出来了，剩下的时间多花在了增加功能上，该报道再也没有提到与健康码直接相关的保通工作。这其实反映了很多干部群众的软件开发观，在他们眼中，软件升级就是不断增加新的功能，软件升级的目的就是充分利用硬件性能。

这与软件开发观念完全违背，在稳定的前提下，性能是软件最重要的功能。但是很多领导干部，由于本身并不日常使用相关软件，因此不注重性能方面的要求。在理想的情况下，软件开发中增加功能点应该以完全不影响速度为前提。性能的冗余对稳定性非常重要，软件的负载不应该不断提高。

此外，软件是为了某个目的而开发的，其专用性非常重要。喜欢搞个大综合，号称要“1+1>2”早已成为政务软件和企业内部管理软件先天不足的重要原因。这也搞，那也搞，必然是要牺牲软件的速度、稳定或健壮性之一的。

承认软件有专用性的情况下，就要承认随着时代的发展，软件是必然要重构的，小车不倒只管推的思路是不行的。Win11装IE浏览器已经很困难了，政务系统还有很多业务只能靠IE浏览器访问。Flash已经停止维护了，依然跑着很多机关的核心业务。今后这样的业务，想要与其他业务配合的难度将越来越大。

该报道中，还有更多的雷人内容，指向政务软件开发运维两张皮的问题。“一码通”保障专班仅仅将1MB的一张图片，压缩到100KB，就用了两天两夜。

相关报道中令人震惊的内容

很多网友对此事竭尽嘲讽，因为从技术上说，有损压缩的图片的大小可以逼近0。同时已经有自动化压缩的免费工具了，可以按照想要的大小，按可能的最高质量进行压缩，因此有人认为“开发者甚至不善于利用搜索引擎”。

笔者认为没有这么简单。如果“一码通”保障专班水平真的如此之低，完全不可能开发“一码通”这样的应用。更有可能的情况是，来自于“上面”的要求，对图片的风格质量都做了详细的规定，甚至需要有关方面批准，才导致“工作看似简单，却蕴含着高技术含量”。开发者在这样的情况下，绞尽脑汁的缩小图片的大小，说明其对紧急状态下能调用的资源没有信心。

“一码通”曾经“日均访问量达千万人次”，并且在应急扩容中表现出色，但当时的相关工作是“在西安市疫情防控指挥部的统一指挥下”。随着疫情防控常态化，“召之即来”的开发者回到原先的单位，“一码通”崩溃时管理者保障乏力也就不难理解了。

没有了原先的协调级别，没有了精干的技术团队，“一码通”信息体系建设的不完善集中地暴露了出来。

“一码通”事件说明，监管部门技术力非常薄弱，闹了很多笑话。完善信息体系，最需要的就是相关部门的领导摆脱大甲方的心态。在业务主要靠外包的情况下，必须要对领导自身的技术水平进行考核。不然要么提出些贻笑大方的需求，要么完全被外包公司的技术栈拖着走，终究不是长久之计。

一切问题最终是人的问题，领导干部的技术水平不提高，技术思想更新的就慢，更不会去想线下业务与线上业务匹配的问题。

同时，信息体系建设必须有轻有重，详略得当。“一码通”27万的招标价已经成为了笑话，妄图以普通政务软件的价格，购买日活上千万的软件，必然加重后续运营的历史负担。

最后，建设信息体系建设必须保障开发人员的建议权和运维人员的无责紧急决断权。开发人员享有建议权，有利于避免写出业务逻辑不合理的应用。运维人员享有一定条件下的无责紧急决断权，最坏不过是浪费了钱，对一码通这样的业务，却能在崩溃重整时节约大量宝贵的时间。