从西安一码通崩掉说起

这两天IT圈里议论最多的事件之一是西安一码通的崩溃问题，据说昨天工信部督导组都紧急赶赴西安督导了。以前疫情都是听说国家卫健委督导组，工信部督导组还真是头一回听说。这也说明我们的信息化已经发展到了何种地步。在DBA圈里传的都是数据库该优化了，实际上，以我这些年做优化的经验来看，西安一码通的问题大概率不需要数据库来背。

因为信息系统崩溃大多数是因为堵塞严重，从APP到云平台网络安全设备入口再到数据库，中间有一个很长的链条，这个链条上任何一点出问题，都会引起系统崩溃。我们前几个月接过一个类似的政府APP的优化项目，开始客户给我们的任务是通过数据库优化提升并发处理能力10倍，没想到项目一开始就发现，数据库根本没多大负载，网络、负载均衡、Redis及相关应用才是最大的瓶颈。

今天我并不想从系统及优化的角度去谈西安一码通的问题，而是想先重点谈谈处置预案的问题。看到网上讲述网友排了几小时队，然后医务人员告诉他一码通崩溃了，所以没法做核酸采样了，这确实是让人崩溃的事情。

于是信息系统一码通以及承建和运维一码通的西安电信变成了罪魁祸首，更深一点的人已经开始在挖为啥不是腾讯阿里来承接这个工程，而是选择了技术实力明显不行的中国电信，是不是里面有猫腻。实际上这么考虑问题都偏了，不应该是反思这个问题的关键。包括今天网上传播的西安大数据局的局长下课，似乎是大快人心了，实际上问题并没有彻底解决。

十多年前，记不清是2007年还是2006年了，顺丰的快递核心系统阿修罗因为扩容磁盘存储锁死，无奈只能切换到备用系统，不过备用系统容量不足，无法承载业务，只能临时从不用的服务器上拔内存。服务器重启的时候又因为HACMP的配置问题，IP地址加载不上，折腾了一会儿，最后导致阿修罗系统停服近1个小时。不过这一个小时的时间正好是顺丰业务最为关键的时间，大量的快递车辆到达清关口岸的时候打印不出通关单据，运输车辆到达机场的时候，无法打印货单。这一个小时的停机，给顺丰带来了近2000万的经济损失。

第二天开工作总结会的时候，作为数据库维保单位的负责人，我也参加了这场会议。当时我以及IT部门的朋友们都以为王卫一定会首先拿IT部门开刀。没想到王卫说的第一句话是，为什么我们的业务部门没有准备一套离开IT系统的手工处置预案。于是业务部门被首先问责，最后才轮到了IT部门为什么对灾备系统投入这么少。关于这个故障处置的事情其实也十分有趣，对于灾备系统建设中的误区也是一个很好的厘清，以后我找时间单独介绍吧。

作为顺丰的老板，王卫一针见血，看到了问题的本质，在信息化十分发达的今天，离开IT系统的工作能力是一个企业建立全方位能力的短板，这块短板不补上，早晚要出大事的。固然2009年因为深圳某个地区的上级变电站故障，导致顺丰机房的两路供电均出现问题，机房过热导致停服超过30小时，这次故障虽大，但是顺丰并没有出现前一次的手忙脚乱的问题，快递业务照常运行，只是快递查单受到了影响。

上面的这个例子要说的是，西安一码通最大的问题是缺乏备胎预案，如果预案完善，哪怕信息系统出现一些问题，都不会出大问题。而如果预案不完善，一个小问题都可以成为大问题。

当一码通崩溃的时候，需要亮码的时候完全可以使用微信支付宝的小程序，如果西安一码通出问题，是不是政府也允许使用国家平台健康码作为绿码依据呢？陕西其他地方的健康码，甚至外地的健康码是不是也可以作为备用呢？这些问题实际上只要政府的人多长点脑子，就可以迎刃而解的。

至于核酸检测，那就更简单了，建立一个十分简单的备用方案，一旦一码通出问题，搞一个小APP，把试剂瓶和身份证拍照后上传后继续采样就可以了。如果核酸检测是阴性，这些数据都在，通过识别软件识别一下相关的试剂瓶二维码，找到后，再找出和试剂瓶对应的几张身份证就可以了。如果检测结果是阴性的，数据存档就行了。这个简单的小应用恐怕不难做吧。实际上西安的疫情管控，暴露出来的是考虑问题的粗线条，政府管理的粗犷实际上也是水平不足的表现。

今天有个文安君出来给西安洗地了，举了不少巨婴的案例，并做出结论，西安做的并不差，上海遇到西安的问题，照样完蛋。确实在这些抱怨声中不免会有一些巨婴的鸣叫，不过这些都盖不住西安此次暴露出来的问题。上海的城市管理水平并不都在财大气粗上，一些细节上的用心，才是上海和西安在城市管理上最大的差别。而这个细心往往就是成败的关键。

回到信息系统上来看，西安一码通的倒掉也为我们IT人甚至是我们的企业、政府领导提了个醒，虽然是信息化时代了，如果脱离信息化不能干活，这种风险比某个系统倒掉还要危险。没有千年不漏的大瓦房，也没有谁敢保证自己的系统100%不会出问题。出问题不怕，没有预案才可怕。