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

是这样的

西安疫情最近确实有严重的趋势，但是政府一直没有提倡在家办公，这也就让很多的公司以一切等政府下令为准一直是让员工来正常上班。

为了避免有感染，于是出了个持48小时核酸证明来上班的政策。

但是在政策实行的第一天周一，一码通崩溃了，查不出来你是不是绿码，也查不出来你是否检测过核酸。

有一些企业采取紧急预案，大家居家办公，别出门了。

还有一些企业例如我司，仍然下铁命令，到岗到位。（我们还是家互联网企业，严格的说只要有电脑就可以办公）

而之所以他敢下这个命令，是我们公司所在的大厦的防疫措施给的支持，是怎么做的呢？一码通不是打不开嘛，不重要，全员直接进入，前台登记个名字即可，你要实在良心过不去站公司楼前发个誓也行。

这什么概念？你上班就是个概率论问题了。先不说高新区附近就有确诊病历，不少同事甚至是从雁塔区等中高风险区来的，还有的同事小区都有人确诊了，还有的同事收到了短信提醒他是时空伴随者，但是！我们全部都在周一直接进了大厦到岗到位开始办公。

一码通的崩溃，让我这种普通打工族也要崩溃了，我上个班要面临的风险和心理压力太大了。

到了晚上，按照48小时核酸证明要求，我们又要开始做核酸。

核酸的排队有多夸张，我早上拍到了点

一米举例？不存在的，人挨着人，就这，雪上加霜的是一码通还扫不出来，只能拿身份证做，做着做着告诉你网络坏了，核酸做不了了。崩溃不？寒风中等五六个小时才做上核酸的大有人在，为什么大家非得天天来做这个核酸？因为上班要用啊48小时核酸证明。

而且已知现在已经有很多人是做核酸的时候被查出来确诊，那是否意味着排在这个人前后和周围的人都算密接？

这疫情能控住吗？

本来我周末做了核酸检测是阴性后，就想居家的，第一个不给别人添麻烦，第二个不给自己添麻烦。

但是政府不让啊

有的企业老板他就是个混球，只要你政府没下令居家办公，我所有的员工就得来上班。

政府也想的很好，我们为了民生，大家都正常上班，你们把核酸做了就行。

所以在西安就是早上大家扎堆上班，下班大家扎堆做核酸。在这中间还要伴随着有时候能扫出来有时候扫不出来的一码通。

真的是怕我们接触的不够多，一码通的崩溃让很多地方都不查验核酸就放行，就这一天难道不会出现新的感染病例？

我现在依然在高新区的办公楼里上班，前面楼已经陆续有确诊的被拉走了，但我们，依然在上班，甚至有的同事今天到单位才知道自己小区被封了，因为有确诊的，崩溃，真的就崩溃。

这就是西安的防疫现状，真牛。

昨天中午突然接到通知，女儿所在的学校（中学）下午6点封校，所有学生都要离校。当时的想法是马上开车去西安接她，后来一问政策，不行。我一旦去了西安，就回不来了，因为没有48小时核酸检测报告。

我马上问女儿，所幸当天（20日）上午学校集体做了核酸，6小时出结果。我决定让女儿坐高铁回来。她5点离校，去高铁站，以为到了高铁站就够6小时了。没想到到了高铁站怎么也刷不出结果，一直在那里冻了两个小时，直到赶不上末班高铁才放弃。

我想在北站附近给她找个旅馆住一晚，不幸的是，旅馆也要核酸结果。完美闭环。

挨个问了很多旅馆，都不行。没办法找学校，学校网开一面让她回学校宿舍住一晚。

我不懂技术，但我是基层卫生人员，日常经常帮群众处理各种健康码问题，所谓的处理就是把问题上报到几十个qq微信群里，找工程师人工改后台数据库。所以大概知道一点。

我不知道西安是什么情况。但在我看来，如果我们这里遇到西安这种疫情，健康码系统大概率会跟西安一样崩溃。

本省健康码系统运维人员有多少，我不知道。从历次开会培训判断，应该有5-10个人的团队。本市常见维护工程师只有一人，七八个微信群里都是同一个私人微信号在回答问题。无周末无调休。有时候遇到他下班了，就得等第二天。但如果事情特别重要，比如某个监测点几百个样本打不出条码来，他也会紧急加班。我

市里的平台也不太稳定，一周七天总要故障个两三次，每次解决方法也到简单，暂停工作10分钟，重启服务器。偶尔严重问题，就暂停半小时，重启服务器。

目前市平台和省平台的数据不共享，是通过我们这样的基层信息员手工同步。信息员从市平台手工导出一个excel，按省平台格式重新调整，再登录省平台，把excel表导入到省平台上。然后大家就能从微信公众号上看到核酸检测结果了。

但这个省平台也不稳定，每天上午下午下班前，所有单位的信息员都去登陆了省平台上传数据，省平台就会频繁掉线。过了12点，所有单位都下班了，立刻不掉线了。

所以，昨天我看到这个新闻的时候就在想，如果是我们这儿遇到了疫情，我们这套系统能撑住吗？

这套健康码系统和高铁购票系统有点像。平时不忙的时候，服务器多一点少一点无所谓，运维人员多一点少一点无所谓，系统稳不稳定也无所谓。反正又不是不能用。

而且，这类健康码都是政府购买的企业服务。既然是企业，也就要考虑利润，不可能提供冗余服务。利益优先吗。或者说采购合同里提到了要能应对突发事件，但具体突发事件有多大的规模？主管单位没有概念，企业可能有概念，但感觉日常就是这种配置的话成本太高，总觉得遇到了再扩容也来得及。

但很可惜，他们没来得及扩容。

我不懂技术，不知道这个没来得及扩容的技术问题是什么。但是从我目前看到的来说，负责我市业务的这个程序员，但他的权限也仅限于手工改改数据库，重启数据库，他一直在7X24小时工作，应付着全市一千多个检测点的所有问题。

真的遇到了问题，我估计这个人是撑不下来的。不管是技术上还是体力上。

啊对了，还有一点是我觉得最不放心的。

我所知道的大多数地方，健康码的服务都是由当地的his服务商提供的。his软件就是医院里使用的软件，挂号取药传递报告单什么的。这些软件公司都很专业，程序符合医疗政策需求，能够统计抗生素用量什么的。但是，这些公司不是互联网公司。他们的人才储备里，很少有这种互联网高并发业务的处理人员。

所以我们用的平台，才会临近下班的时候就卡住。因为，这类的高并发业务他们真的不熟。

其实我一直有一个疑问，全国各地都有防疫用的健康验证系统，北京叫『健康宝』，上海叫『随申码』，西安叫『一码通』，其他地区有『XX码』，那么，为什么不做一个全国通用的呢？

政策上的原因，经费上的原因呢，咱也不敢多做评论。

我只从技术上来说一说。

做任何一个系统，先定一下需求，不光是功能性需求，也有架构性需求，像『健康宝』『一码通』这样的系统，架构性需求差不多就是这样：

• 可访问性，要做到24x7，因为整个社会都依赖于这个系统；
• 访问流量，根据区域人口和活动规律，可以预估RPS请求量，包括峰值RPS量；
• 终端用户访问速度，并不需要毫秒级别的高速响应，但是不要慢于秒级；
• 数据导入量和消费速度，并不需要太高的实时性。

从功能上说，这个系统是单向的数据流动，差不多这样：

       运营商 --> 数据采集 --> 数据处理 --> 缓存 --> API --> 客户端     

这种单向的数据流动，没有什么逆向的交互，其实就大大简化了问题的复杂性。

但是，要考虑的问题依然很多。

下次，可以那这道题去考一考候选人——怎么构建一个可靠的健康码/一码通？

太神奇了，健康码验核酸结果这种业务，一开始就应该能想到是峰谷量差距极大的应用场景，为什么不一开始就考虑上云？

然后，这种独立单元式数据（任意两条之间的数据基本无交叉依赖），按某些规则分区分片不是起码的吗？那就算崩，一个区而已。为什么会突然全城一起崩？如果真这么干了还全崩，只能是机房级别的问题，例如说全机房掉电或者掉网——但这种故障没理由需要几个小时才能恢复啊？

最后，就算真的没分区，全放一起，按西安2000万人计算，每个人的数据平均1k（就几个状态码+几条核酸结果+几个时间戳而言，多到离谱了，精细设计一下，100字节可能都够用），一共也才20G数据——单服务器搞个纯内存数据库都能顶得住。对于这种写少多读的模型，都不用玩什么分布式集群了，直接双写单读甚至四写单读就完事了。

所以，前端业务上云，随便平行扩展，后面的数据全在内存里——这玩意是怎么顶不住这么点流量还全崩的？

这事闹大了，居然崩溃了一天。

早上上班崩溃，晚上下班居然还在崩溃。

官方建议这样做

在全员核酸检测的特殊时期，为减轻系统压力，建议广大市民非必要不展码、亮码，在出现系统卡顿时，请耐心等待，尽量避免反复刷新。

非必要不展码，不亮码。。可以。。

春晚小品都想好了：

西安一码通瘫痪，开发一码通的工程师因为不能提供绿码而进入大楼解决瘫痪问题，大幕徐徐展开，一工程师小A在那里急得满头大汗，一会掏工卡，一会展示手机微信群聊里的记录，一五十岁大爷（首选小潘子）穿保安制服在那里严守岗位，坚持没绿码就不能进。

这时第三个人小B登场，他两只乌黑的熊猫眼，一脸疲倦，油亮的大额头，靠后的发际线，他为什么能在大楼里面？原来007还没下班呢。看见小A大喜过望，喊道：我们的大牛终于来了，问题解决有希望啦，领导和一群同事等着你呢，快进来！

小A刚准备迈脚进去，小潘子一声大喊：停！没绿码不能进！小A、小B再一番求情，小潘子坚持原则不为所动，领导打电话也没用！

小B突然一拍脑袋，我把电脑拿下来就可以了啊，咱们这里有WIFI，直接连内网！小B飞速上楼拿来电脑，两人凑到一起看屏幕（来个夸张动作，头碰在一起啦，同时哎呀捂头，同时眼睛不离开屏幕）。小潘子搬出自己平时看抗日神剧的电视，说：小伙子们，来，用大屏幕不伤眼睛。

小A小B装模作样地看了几页代码，在那里念叨：Bug在哪呢？Bug在哪呢？小潘子拿着保温杯（必须配枸杞）在后面凳子上刺溜上几口，这时站起来拿个扫把假模假样地扫几下根本看不到垃圾的地面，突然抬头：小伙子，第23行，堆栈溢出了！（梗还是老的好）

小A一拍大腿，对啊，改了行代码，编译提交出去，这时手机叮地响了一声，推出一条消息：您的绿码已恢复！这里群里蹦出领导的声音：系统恢复了，小A小B你们做得很棒！小A小B拥抱在一起（好基友，一辈子！）。

小A向小潘子展示了绿码，小潘子笑呵呵地说：欢迎，请进！小A正准备迈出脚，突然停住：大爷，您怎么看出是堆栈溢出了呢？小潘子吹了口茶水，缓缓地说：小伙子，不瞒你说，你开发的小程序，调用的底层库是我当年开发的，你看最上面的那个作者XXX（随便编一个），就是我的花名。小A小B肃然起敬：原来您就是当年XXX技术的开发者，我们领导没少夸过您，说您是他心目中的大神啊。只是，您不是在阿里吗？（阿里中枪），怎么来我们公司来当一名保…

小潘子一脸黯然：我已经四十啦，干码农的35岁就会被优化，能坚持到40岁才走人，已经是公司照顾啦（小A小B画外音：才40，我以为您五六十岁的大爷呢）。突然振作起来：不对，BOSS说过，不是优化，是向社会输送有用人才！你别看我做保安，照样发光发热，要知道，这两年疫情一直不能清零，作为一名保安，坚持自己的职责，不放过一条潜在的漏网之鱼……（一番自我催眠与感动中）

语气突然一转：小伙子，刚才大爷不让你进去，不是故意为难你，而是我们要遵守各种规章制度，疫情才能控制下去啊。

小A：大爷（我怎么也跟着喊他大爷，我今年快35了，才比他小5岁，叫哥才对。呃，我快35啦……）您是对的，您站着门口坚守岗位，我开发绿码小程序，都是为抗击疫情做贡献啊。让我们喊一句（三人迅速站一排作打气状）：西安挺住！西安加油！

煽情，谢幕。

“非必要不XX”体看来要火，任何一个要求性的词汇如果不加以控制便会滥用，甚至变味。

回味一下，看看“非必要不XX”体是怎么卷起来的。

印象中，是在2020年疫情防控最严峻时期，各地政府发出“非必要不出门”的倡议，此时面对史无前例的出行管控，民众们自然带有强烈的不习惯感，这样一句非必要不出门，既转换了强制要求不出门的语气，又有衷心苦劝的意味深长，在当时的背景下得到了全民的拥护和贯彻执行。

紧接着，鉴于“非必要不XX”体的良好功效，各地各层级各类主体开始广泛传用。

开始拓展使用场景，

非必要不返乡。好吧，支持。

非必要不聚集。好吧，有道理。

非必要不旅行。好吧，省钱了。

非必要不就医。忍忍吧，节省医疗资源。

……

但是到了2021年即将结束的时候，

2021年12月12日前后，一些地方又打出“非必要不返乡”的号召，引发舆论热议。

紧接着，2021年12月20日，“非必要不展码”，开创了“非必要不XX”体的新境界。

甚至个别无法按期参加考研的学生爆出面临学校的“非必要不考研”的境况。

仔细拆解，不XX，表面为建议，实际包含着引导要求，关键在于“非必要”这三个字，彼时彼刻十分不必要，此时此刻非常有必要。

希望不要再滥用“非必要不XX”，不要拍着脑袋定义必要不必要，请问问群众需要不需要。

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

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

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

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

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

一些人总有这样的思维

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

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

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

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

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

点开下方核酸结果，可以看到最近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月底的时候二维码就有了边框注明疫苗接种状态，比如下面这个是金黄色的，标明完成了第二针接种。

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

一，需要解决的问题

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.将个人轨迹和已知病例、密接的轨迹做比对，并在服务器保存查询结果

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

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

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

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

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