12 月 20 日西安一码通崩溃，西安建议市民非必要不展码、亮码，一码通故障的影响有多大？ 第2页

让阿里双十一团队去做，绝不至于如此。目前主流媒体过分强调互联网行业的负面影响，到了否认互联网在社会发展中的地位的程度，就有点过了。希望社会正确认识到计算机高薪的价值，不要再搞程序员离开大厂进工厂这种反智宣传了。

很多人说西安没有一个二线城市应该有的防疫水平

但其实这就是一个二线城市的正常水平

两年前武汉爆发，很多人说吃一堑长一智，有了这次的经验以后就知道怎么合理应对了

但我一直认为这是不可能的，因为非典给管理者的经验已经够多了，新冠来了仍然是从头来过

一些人总有这样的思维

“没发现，说明做的好” “发现了，下次也能改”

但你一天拥有这样的思维，（）就一天靠不了谱

首先崩溃的原因大概率是并发过高了。

我来猜一下为什么，以及怎么修的

以前，打开西安一码通健康码后，底下会有最近一次的核酸结果：

点开下方核酸结果，可以看到最近7天内的所有核酸结果：

然而，在20号瘫痪一天之后，新版一码通变成了这样：

可以注意到，最近一次核酸结果不再显示，疫苗接种结果不再显示。

核酸查询入口挪到了一码通主界面：

新版核酸查询结果：

可以看到，只显示最近一天的结果了，并且手动查询其他日期也不再显示。

也就是说，事关千万人出行和安全的基础软件设施，在经历一天的紧急维修后，并没有选择扩容。政府应该是不缺钱的，那么就是无法短时间内扩容，也就是这个软件架构设计就有问题，根本支撑不住这么高的并发。

那么他们选择了什么呢？尽量避免核酸查询。也就是说瓶颈应该是出在核酸查询接口的并发能力上。现在，亮码不再显示核酸（也不显示疫苗），手动查询只显示最新一条记录。

如果原来亮一次码需要：

查询最新核酸1次，查询疫苗接种1次。

那么现在亮一次码则省掉了以上两次查询。

这应该会避免掉很多不必要的流量，比如公交、地铁。

如果原来查一次核酸需要以下任意一种：

1. 查询7天内核酸1次（用数据库自带日期计算函数）。
2. 查询从当天往前推每天的核酸7次。
3. 不停查询最新n次核酸，n累加1，直到最后一条记录日期与当天做差大于7。

（这三种写法是依愚蠢程度上升的。）

那么现在查一次核酸则固定变成了1次查询（order by date desc limit 1）。

确实相比以性能有提升。

综上，结合微博上看到的各单位要求出示48h核酸阴性报告才能上班，昨天是周一第一天执行该政策，我认为，是过高的核酸查询并发把整个健康码系统给拖崩溃了。

解决方案就是：

1. 在健康码界面砍掉核酸查询，让公交地铁等扫码但不看核酸的场景不再查询核酸。

2. 在核酸查询界面砍掉过往核酸查询，只留一条最新记录。

我想这是扩不了容的情况下能做的一切了。

但我还是想不通为什么这两步做了一整天。

那么问题来了，为什么扩不了容？

如真如网上所说，系统由电信、东软和美林数据共同支持，假设美林甩锅合理成立（微博有自称美林员工说美林只提供数据支持，不负责运营），那我猜东软是主力。

不管是电信还是东软，都不是第一天入行了。这又不是互联网创业不知第二天死活先上线再说，一开始做系统的时候，就应该知道面向的是全西安人民，真的一点扩容的后路都没有留？缓存、拆表、集群……有那么多方法，开发的时候多耗不了多少精力。如今这个堪称搞笑的补救措施——你以为抗压能力强了？其实是砍了很多功能哒！——贻笑大方了属于是。

一些分析结论：

1. 一码通崩溃不是因为网络拥堵导致的
2. 一码通系统的容灾和备份机制存在缺陷
3. 一码通系统，核酸查询系统和核酸检测系统之间的强关联是设计上的失误
4. 西安市到现在都没有把自己的核酸检验报告系统和国家的核酸报告系统打通，是决策上的失误，也是政府信息化建设中的失误
5. 未来各地『一码通』需要逐渐走向互联互通

01

是拥堵引起的吗？

一码通是因为什么原因崩溃的？大数据局曾经对媒体说是网络拥堵导致（参见陕西交通广播微博）。今天下午新闻发布会也说是拥堵导致的。坦率地说，这种说法我是不相信的。原因有二：

1. 西安一码通上线已经很长时间了。这期间大部分时候还是很稳定的。西安的上班高峰期，也就是扫码高峰期大体上应该在8点到9点之间。但是一码通崩溃是从7点多开始的，当时大部分人都还没出门，更谈不上扫一码通了。网络根本不可能在那个时候拥堵。更不可能因为拥堵造成系统崩溃。实际上最近因为疫情，很多人出门会避开高峰期，高峰期一码通系统的网络流量应该是没有平时大的。

2. 如果真的是网络拥堵导致系统崩溃，那么解决是很容易的。解决网络拥堵大体上有两种手段：一是限流，二是扩容。限流就是把一部分网络请求阻挡住，只让部分网络请求通过。这样系统负荷就小了。扩容就是增加服务器的硬件，比如增加服务器的内存，CPU，如果服务器有集群，则可以在集群中增加更多服务器，之后通过负载均衡将大流量分布到更多的服务器去，进而降低单个服务器的负荷。

如果为不太懂计算机技术的朋友们打个比方，拥堵导致崩溃可以用“小马拉大车”来理解。本来小马只能拉一辆车，现在要求它同时拉两辆车，那小马肯定身体撑不住。解决办法中的“限流”可以理解为先扔下一辆车，拉走另外一辆车，之后再来拉扔下的那个车。“扩容”则可以理解为调来更多的小马，本来只有一个小马，现在有两个小马拉了，自然就可以拉动了。

需要说明的是，当今的计算机系统，基本上都部署在云上。而在云计算平台上，“限流”和“扩容”都是非常容易实现的。甚至夸张一点说，点几下鼠标，动一动键盘，很快可能就搞定了。一码通系统据说部署在阿里云上，无论是搞限流还是扩容，应该都不难，更不至于花了大半天都没有恢复。

另外一个关于一码通问题是程序问题的佐证是，一码通的样式在今天进行了回滚。

下面这个图是10月份时候健康码的样子，注意10月底的时候二维码就有了边框注明疫苗接种状态，比如下面这个是金黄色的，标明完成了第二针接种。

直到昨天，这个边框也是存在的。但是今天下午系统恢复以后却消失了。变成了下面这个好几个月之前的样子：

所以我们判断系统进行了回滚。

另外，周日进行了核酸的一部分人也发现他们的结果一直没出来。但按照常理，应该是出来的。我个人的猜想是数据库也进行了回滚。回滚到了周日的某个时间点。这比程序回滚的时间跨度要小很多。

如果仅仅是流量太大，正如我上面所说，直接优化网络，优化硬件就可以。为什么要把程序回滚到2个月以前的样子呢？回答只能是，程序出了问题，一时又改不好。所以只能把程序回滚了。有可能回滚了很多次，直到找到这一个版本能运行，结果已经是很久以前的程序了。。。而网络拥堵，明显只是一个借口。。。

需要注意的是，在程序下午回滚以后，晚上七点多又崩溃了。原因是什么呢？很可能是数据和程序存在不匹配的情况。或者是数据库里面的存储过程之类出了问题。

02

系统崩溃的真实原因

那么系统崩溃真实原因是什么呢？目前看起来，当事的企业和大数据局都倾向于用”网络拥堵“的接口来说事。他们如果不告诉我们真实原因。我们就只能从一些表象进行猜测。当然这些猜测可能对，也可能不对。下面是我个人的分析。

系统之前运行地很稳定，突然就崩溃了。这样的情况，如果不是网络问题，那么大体可以分为两种：

1. 修改了一部分程序代码，结果这部分代码有问题，把系统搞崩了。
2. 或者代码没怎么变。但是一些新的数据进来以后，引发了以前没有运行过的一些情况，系统崩了。
3. 或者就是上面1和2所说的情况兼具。

总结：最大的可能是周日晚上一码通经历了代码更改，但是上线的版本出现了 bug导致的。从后面程序回滚以后依然崩溃的现象来看，崩溃的原因和数据有一定关系。可能是错误的代码修改了数据库，导致程序回滚以后依然有崩溃现象。也有可能是存储过程等保存在数据库中的代码出了问题导致的。

申明：以上内容部分转载自公众号【软件开发与挖掘机技术】刘杰，感谢公众号作者，为了让更多人了解情况因此发出，侵删

---

  li-yi-53-93 网友的相关建议: 
      

建议建立全国统一的流调信息平台，并精细化调整新冠肺炎疫情分区分级标准

一，需要解决的问题

1.局部地区健康码系统过载

全国疫情处于散发状态，大多数地区没有疫情，健康码查询量有限。只有局部地区出现聚集性传播，大量查询导致个别城市健康码系统过载。

如果为了满足尖峰需求配置很大的服务器，将面临长时间闲置，配置较小的服务器，则无法应对突发访问。

如果做全国性系统，就可以用部署在全国的服务器进行负载均衡，解决局部地区访问量过大的问题。

2.已有流调体系存在缺陷

（1）普通民众无法方便的查询是否和行程复杂的外地病例有轨迹重合

成都1号病例去过兰州出现过多个确诊病例的大唐宫，但除非依次查看兰州所有病例轨迹，很难知晓该地的疫情传播风险。

（2）在部分区域留下漏调的空白

例如在11-12月的长三角疫情中，宁波一号病例11月22日下午有上海虹桥站的旅行史，杭州11月25日报告的无症状感染者11月22日也去过上海虹桥站。

杭州、上海发布的流调都只涉及本市的部分，宁波流调中提到病例去过上海华为研发中心等地。

三地都没有说明杭甬三个病例是否在上海有接触史。

二、解决方案

1.为了取得准确的信息，需要建立统一的流调信息平台，明确流调发布制度，

对于行程复杂的感染者、密接，应当在隔离地点一次性完成病例涉及所有地点的流调（流调包括多少天，细到什么程度要有统一标准），并规范录入数据库，供全国其他地区的授权人员查看。

如果其他地区的疾控人员有对病例进行电话补充流调，可以在系统中补充。

与电子地图运营商合作，在流调阶段将病例活动地点名称转化为地图上的坐标，一方面用程序自动比对轨迹寻找传播链和密接，也便于疾控人员人工比对。

2.新冠肺炎疫情分区分级标准要以疫情扩散风险性为评判标准，更加精细化

为了准确衡量传播风险，除“确诊病例数量”外，需要考虑的因素有：

（1）感染者从感染到隔离的周期。周期越长，可能的传代数量越多，风险性越大。

（2）感染者的居住状态，独栋房屋、集体宿舍、城市小区、排水不良的老旧城中村、闭环管理居住点的人员扩散危险性不等。

（3）本地人口流动情况，如果有大量旅游团、货车司机群体流动，则应当提高风险等级。

（4）某个出现病例的地区如果处于高危地点（边境线、口岸、传染病医院、隔离点、冷链操作点）附近，则应当提升风险等级。

（5）季节性因素。冬天飞沫存在时间较长，呼吸道传染病高发，应当提高等级。

（6）已知病例活动轨迹是否涉及人流密集地点或者流调较困难的地点，如购物中心、机场、铁路枢纽客运站等。

（7）其他地区的传染链是否在本地区有交叉。

（8）本地区的流调是否清晰，是否有病例查不到来源。

（9）本地近期核酸检测数量和人口的比例。

（10）已经发现的混检阳性样品数量。

（11）对于边境和口岸地区，还需要考虑边境线以外的疫情发展状况和每日平均入境人数（包括临时来口岸停留但不办理入境手续的飞机机组成员、货船船员、货运司机）。也需要考虑口岸人员防护规范性。

3.将个人轨迹和已知病例、密接的轨迹做比对，并在服务器保存查询结果

可以为每个人（以身份证号或者护照号作为唯一ID）建一个行程数据表，系统自动从通讯运营商、支付宝、微信读取轨迹数据，让程序自动和已知病例轨迹、各个风险区比对。

比对完成后，将比对结果写回个人数据表中，如果比中就在个人数据表中展示相关时间、地点。

查询健康码的时候，如果不进行实时计算，只读取个人行程数据表就可以大大提高访问速度。

三、建议统一平台的好处

1.提高疾控部门工作效率

“建立统一的信息平台，明确流调发布制度”后，各省、各市专人定时浏览一遍信息即可得知外地病例是否在本地有轨迹，不再需要跨市、跨省发协查函、也不需要等待其他地区发函给自己。

2.更准确的掌握某地传播风险

如果多地流调发现本地病例有涉及到外地同一地点的轨迹，就可以自动提示该地点的传播风险。

3.提升欠发达地区的流调水平

系统可由发达地区流调专家牵头，结合工作经验编写业务流程并调试。

欠发达地区疾控人员经过培训后，只需要根据流程规范操作，就可以减少流调过程中的遗漏。

4.避免局部城市访问量过大导致的系统崩溃

更大的系统允许更多的服务器，可以做更多的异地备份，容灾能力有很大提高。

5.方便个人了解被感染风险

对经常出差的人来说，每天花几个小时查看各地最新流调信息是不现实的。

只有系统使用足够简单，才能推广得好，用得好。

四、西安疫情流调整理

可点击看大图，或者点击2021年12月西安-东莞疫情

画图工具链接：ProcessOn

---

  jackyzmq 网友的相关建议: 
      

“因访问量过大导致系统崩溃”

作为一个老IT人，我告诉你这是IT层面惯用也好用的甩锅套路，当年我也没少用 ：）

虽说做IT的毕竟只是少数，大多数人不太了解这个行当。但是人云亦云，只会是独立判断能力缺失的表现。其实只要问几个问题就能想明白（这些问题和IT无关）：

20日访问量过大，那19日不大吗？18日呢？之前每一天都不过大，就20日过大？有什么突发事件导致访问量的激增吗？如果没有激增，只是正常增长超过某个界限，早些日子接近界限的时候干嘛去了？

能导致这种突然崩溃的，只可能是程序bug。有可能来自新代码，也可能是老代码上线前没检查出来的。如果真是访问量过大的原因，现象上看一般不会是突然崩溃，而是一天一天的反应变慢，每天都慢一点……

---

  xiarenzhimajuan 网友的相关建议: 
      

还选个毛

几个老头，谁能活到11月谁自动当选

---

  xiaobing_4429 网友的相关建议: 
      

有一说一，其实性价比最高的4K蓝光播放设备很可能是二手xbox

---