西安市一码通又不能使用了交大的高材生能出来帮助吗

应该是西安电子科技大学的事儿！前提是让前期给西安市政府做一码通系统的公司先把全部工程款吐出来，根据态度和危害程度再考虑要不要追究其附带赔偿责任。
重新定义和明确该系统开发建设的功能容量和验收标准。

参考：
电信移动联通三个公司竞标，电信以最低价中标，中标后包给了三个公司，主要问题就是需要扩容，而不是哪个学校高材生来开发的问题
参考：
交大的高材生只懂技术不懂人性，一码通的问题是因为没找到懂技术的人吗？
很明显不是，没把问题搞清楚，只能越帮越忙。

参考：
数据还不全，有些要完善，交大高材生，不能胜任办，技术靠团队，存储大空间，改进版权限，流程度上看，五极飞速传，容量优良安。

参考：
这个行业要西电出来帮忙
参考：
不能，首先进入不了那个圈子，一次又一次的关键时候掉链子，他们也不会让别人来胜任这份维护的
参考：
说实话，学校里的学生不适合做这种需要大量时间打磨的商业化软件，做个原型或者新技术研究还行。
毕竟，商业化软件需要考虑大量的可维可测，以及可靠可用性
参考：
作为IT行业（电子政务方向）从业者，西安一码通这种情况真是见怪不怪了。
政府的IT项目大多都是直接由三大运营商（电信、联通、移动）来承包，再分包给下面的很多小公司。
说得不好听点，就是三大运营商吃肉，再分给依附于他们的小公司一点汤喝。
这种情况下的产品质量，也就可想而知了。
很多时候无非是东拼西凑完成软件中标要求的“行活”，一般只要主要功能跑得通，就没有人会追究。
那项目是怎么验收通过的？
这就没法细说了，大家都懂的。
至于你说出了问题怎么办？
哈哈，不管运营商还是下面的公司，态度很简单：出了问题再说呗，能修复就修复，修复不了就找人背锅。
反正钱已经赚到手了，别的都好说。
这次一码通出问题，显然是下面公司没有预料到西安会突然爆发这么大的疫情，软件使用并发量超过了预估，没有充分的预案来准备。
至于
其次现在捅了篓子，运营商和公司首先想的是大事化小，降低负面影响，而不愿承认自己的失误。
要是能让一些高材生就把问题解决了，那不是打自己的脸吗？

参考：
西安一码通的崩溃，首先是一个技术问题，比如服务器、数据上传节点等等是不是能承载短时间涌现的百万级
作为一个千万等级的大城市，西安一码通在技术硬件上确保能处理相应的需求，这是连外行都知道的抗疫的基本条件，却就是这个基本硬件却接连在西安疫情最严峻的阶段“掉链子”，实在令人匪夷所思。
一码通的宕机，除了技术问题，还涉及到防疫程序的问题。
在什么范围内、针对多大规模的市民发起核酸检测或其他身份识别的请求，都应该有一个清晰的筹划，分批分次地进行。
这既是为系统承载力提供弹性，更是线下防疫有没有科学安排的最直观检验。
由此可见，西安的线下防疫部署恐怕有些失措。
疫情两年多来，不少地方早已形成了固定且有效的防疫组合：准确溯源，结合精细化的流调，配合社区的大规模核酸检测，再根据确诊病例、次密人群等划定等级不同的管理区。
从实际操作看，无论是社区暴发疫情，还是散发外溢病例，都可以通过这套组合防疫政策得到有效控制，其他地方并没有像西安这样，出现防疫码崩溃的现象。
比较西安一码通的两次崩溃，可以推测到科技防疫的第一线未能守住，导致它与线下的社区防疫、市民出行与生活，以及建立在一码通基础上的整个防疫大局都无法稳定。
这带来的一个显而易见的后果就是，缺一不可的线上与线下防疫联动失效，也容易让西安失去防疫最关键、最宝贵的时间窗口。

参考：
这个要看系统前期架构设计是否合理。
如果原本是按照一套大数据量，低并发，低频率请求的系统设计的，那就比较难提升了。
但如果设计初就考虑过高并发，高频率，服务横向扩容应该就可以快速提升服务能力。
这个和什么学校毕业的无关，还是需要有相关行业经验。

参考：
瘫痪一般是内存溢出，io……，导致server或Db当机，估计需要增加负载均衡和wed均衡集群。