问题|西安一码通又崩了,谁之过?谁该负责?

1月4日9时 , 西安一码通再次瘫痪 。 对此 , 西安大数据管理局回应 , 一码通链接访问量太大 , 正在采取限流措施 , 后续逐步开放 。 疫情期间 , 健康码是必不可少的出行“神器” , 扫一扫便知身份信息和健康状况 , 大幅提高了核验工作的效率和精准度 , 西安一码通的多次崩溃对人们的生产和生活带来了极大的不便 。
那到底西安一码通再次崩溃是谁之过呢?本次西安一码通崩溃的原因尚不明确 , 但是可从之前的系统崩溃中见到端倪 。
12月20日早7时40分左右 , 西安“一码通”用户访问量激增 , 每秒访问量达到以往峰值的10倍以上 , 造成网络拥塞 , 致使包括“一码通”在内的部分应用系统无法正常使用 。 西安市大数据局原局长刘军提出了“非必要不亮码”的观点:在全员核酸检测的特殊时期 , 为减轻系统压力 , 建议广大市民非必要不展码、亮码 , 在出现系统卡顿时 , 请耐心等待 , 尽量避免反复刷新 。
很明显 , 这一说法难以服众 。 到底西安一码通为何崩溃?对此 , 10余位来自腾讯、华为、中兴、ICT数据分析的专家从前端、后端、测试方面进行了主要原因分析 。
1、限流问题:市民在长时间无法刷出健康码的情况下 , 多次退出刷新重试 , 新的流量到达服务器 , 导致服务器压力变大、承受负载增加 , 说明西安“一码通”系统没有做好限流措施 。
2、服务器问题:服务器是有峰值限制的 , 不可能承受无上限的并发能力 。 而造成服务器瘫痪的原因就是在同一段时间内 , 访问人数多 , 造成高流量的突进 , 超出了服务器的承受范围 。
3、架构问题:西安“一码通”功能影响“核酸检测”服务 , 说明模块间从界面到数据调用互相影响 , 可能不是微服务架构 。
4、性能过载:典型的性能过载场景 , 不论内部根因是数据库瓶颈点 , 还是网络链接数瓶颈点等等 , 外因都是因为过载导致 。
5、场景问题:大数据查询下载的时候 , 一个线程占用资源过多 , 导致其他服务等待乃至个人电子码里面核酸的信息不显示了 。 所以估计西安“一码通”是个门户 , 数据甚至“卡片”都是从各子系统引过来的服务器挂死宕机的情况;
6、设计漏洞:没有考虑高流量高负载的情况 , 导致测试不充分;产品设计未考虑千万级的并发访问 , 交付前未进行同等级的压力测试 。
7、压力测试:在市民长时间无法看到健康码的情况下 , 多次退出刷新重试 , 新的流量到达服务器 , 导致服务器压力变大、承受负载增加 , 说明压力测试不够 。
据技术专家表示 , 前期西安电信对平台的压力测试不足 , 是造成本次服务瘫痪的主要原因 。

推荐阅读