这起事件的分析，会写得比较长。因此分成几部分发出来。这是第一部分。

01一码通崩溃事件复盘

12月20日星期一，也就是笔者撰写本文的日子，西安一码通崩了。具体一码通是几点开始崩的，并没有一个准确的说法。有人说是7点40左右开始。不过我个人感觉要早一点。我大概早上7点20左右开车经过南三环绕城高速雁塔收费站入口时，发现那里排了大量的车进不去高速。当时没多想，后来到了单位后才发现一码通打不开。现在想想，7点多的非高峰期，高速进不去，估计也是因为司机进高速时无法打开一码通和核酸结果。

崩溃的系统其实不止一码通，西安的核酸查询系统，包括疫苗接种系统都崩溃了。当然后两者可能是因为和一码通存在强关联所以崩溃的。一直到下午两三点以后，一码通和相关系统才开始陆续恢复。但是样式回滚到了之前没有接种标识的样子。

到了下午大概七点多，一码通系统又崩溃了。也是那会，很多人说核酸检测系统也崩溃了。可见这些系统是有一些强关联的。

02一码通崩溃的影响

一码通不能使用，对于处于疫情漩涡中的西安来说，无异于雪上加霜。

就在12月19日（星期日），西安高新区发布通知，要求周一员工必须持48小时内核酸阴性结果才能进出办公场所。西安的公交、地铁也在周日发通知说要求乘客拿48小时的核酸阴性结果才能乘坐公共交通工具。周一当天笔者大概7点40多到了西安软件园，结果因为一码通无法打开，核酸结果无法查证，物业和大厦保安没有办法放行。软件园里每个大楼下面都聚集了好多无法进入的员工。根据一些微信群里描述，很多公交车站，地铁站也都排了长队。上午10点多，笔者经过一个核酸检测点时，发现排队长度超过1公里。

由于西安这些天一直有新冠确诊患者，政府和整个社会都在加大核酸检测和防疫政策的力度。而作为防疫政策核心支撑系统的一码通崩溃，直接影响了整个西安市几乎所有市民的生活和工作。造成的影响应该是很大的。

03一些分析结论

在这里我们还是从软件开发的角度来分析一下这起事件。为了便于大家阅读，我先直接说一下关于这起事件个人的一些分析结论：

一码通崩溃不是因为网络拥堵导致的

一码通系统的容灾和备份机制存在缺陷

一码通系统，核酸查询系统和核酸检测系统之间的强关联是设计上的失误

西安市到现在都没有把自己的核酸检验报告系统和国家的核酸报告系统打通，是决策上的失误，也是政府信息化建设中的失误

未来各地『一码通』需要逐渐走向互联互通

由于话题比较多，考虑到公众号阅读的特性。我打算分成几篇文章发布。这是这一系列文章的第一篇。在这一系列文章的最后，借着这个机会，我希望谈一下软件系统如何在设计，开发和运营中确保系统稳定性。

04是拥堵引起的吗？

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

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

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

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

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

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

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

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

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

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

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

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

05系统崩溃的真实原因

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

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

修改了一部分程序代码，结果这部分代码有问题，把系统搞崩了。

或者代码没怎么变。但是一些新的数据进来以后，引发了以前没有运行过的一些情况，系统崩了。

或者就是上面1和2所说的情况兼具。

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

06一点感想

一码通有多重要。相信今天大家都体会到了。然而从这一起事件看起来，一码通的系统，明显缺乏足够好的容灾和备份机制。如果他们容灾和备份机制做得足够好的话，是完全可以在短时间内恢复到昨天或者前天的状态的。但是从今天系统反反复复的表现看。显然目前的系统虽然有一定的备份机制，但是备份机制不够完善，甚至比较混乱。这个话题比较长，在后面我会再写一篇文章来分析。

欢迎大家在简书关注我的公众号。或者在微信搜索同名公众号“软件开发与挖掘机技术” （softdive)也可以找到我。谢谢大家