1月4日9时 ， 西安一码通再次瘫痪 。 对此 ， 西安大数据管理局回应 ， 一码通链接访问量太大 ， 正在采取限流措施 ， 后续逐步开放 。 疫情期间 ， 健康码是必不可少的出行“神器” ， 扫一扫便知身份信息和健康状况 ， 大幅提高了核验工作的效率和精准度 ， 西安一码通的多次崩溃对人们的生产和生活带来了极大的不便 。
那到底西安一码通再次崩溃是谁之过呢？本次西安一码通崩溃的原因尚不明确 ， 但是可从之前的系统崩溃中见到端倪 。
12月20日早7时40分左右 ， 西安“一码通”用户访问量激增 ， 每秒访问量达到以往峰值的10倍以上 ， 造成网络拥塞 ， 致使包括“一码通”在内的部分应用系统无法正常使用 。 西安市大数据局原局长刘军提出了“非必要不亮码”的观点：在全员核酸检测的特殊时期 ， 为减轻系统压力 ， 建议广大市民非必要不展码、亮码 ， 在出现系统卡顿时 ， 请耐心等待 ， 尽量避免反复刷新 。
很明显 ， 这一说法难以服众 。 到底西安一码通为何崩溃？对此 ， 10余位来自腾讯、华为、中兴、ICT数据分析的专家从前端、后端、测试方面进行了主要原因分析 。
1、限流问题：市民在长时间无法刷出健康码的情况下 ， 多次退出刷新重试 ， 新的流量到达服务器 ， 导致服务器压力变大、承受负载增加 ， 说明西安“一码通”系统没有做好限流措施 。
2、服务器问题：服务器是有峰值限制的 ， 不可能承受无上限的并发能力 。 而造成服务器瘫痪的原因就是在同一段时间内 ， 访问人数多 ， 造成高流量的突进 ， 超出了服务器的承受范围 。
3、架构问题：西安“一码通”功能影响“核酸检测”服务 ， 说明模块间从界面到数据调用互相影响 ， 可能不是微服务架构 。
4、性能过载：典型的性能过载场景 ， 不论内部根因是数据库瓶颈点 ， 还是网络链接数瓶颈点等等 ， 外因都是因为过载导致 。
5、场景问题：大数据查询下载的时候 ， 一个线程占用资源过多 ， 导致其他服务等待乃至个人电子码里面核酸的信息不显示了 。 所以估计西安“一码通”是个门户 ， 数据甚至“卡片”都是从各子系统引过来的服务器挂死宕机的情况；
6、设计漏洞：没有考虑高流量高负载的情况 ， 导致测试不充分；产品设计未考虑千万级的并发访问 ， 交付前未进行同等级的压力测试 。
7、压力测试：在市民长时间无法看到健康码的情况下 ， 多次退出刷新重试 ， 新的流量到达服务器 ， 导致服务器压力变大、承受负载增加 ， 说明压力测试不够 。
据技术专家表示 ， 前期西安电信对平台的压力测试不足 ， 是造成本次服务瘫痪的主要原因 。
压力测试不足的问题真的难以解决吗？相比之下 ， 武汉的防疫工作就比较经得起考验了 。 武汉经历3次重大疫情 ， 每次应对疫情表现出来的“速度、稳定、有序” ， 与西安防疫形成了鲜明的对比 。 就拿8月份的突发疫情来说 ， 面对超5000万次核酸查询 ， 武汉仍顺利地打赢了疫情防控阻击战 。
据网络资料显示 ， 当初移动电信联通三家竞标西安一码通 ， 西安电信中标 ， 然后把业务分包给三家公司——浙江安恒、美林科技以及另外一家公司 。 传闻当时负责西安一码通开发运维的工作人员 ， 陷入了“没有绿码就不能上班 ， 不上班就无法修复软件”这一死循环段子的主角 ， 这名程序员就是美林数据的工作人员 。
美林数据毕竟只负责数据 ， 系统崩溃的原因很多 。 疑似美林副总裁在朋友圈回应了关于西安一码通的说明：美林数据参与的是赋码算法 ， 电信和东软负责运营 。 本次系统崩溃与我公司无关 。