行业甩锅日常甩上了热搜，这锅怕是没那么容易甩掉

9月2日成都的核酸系统崩了。软件园的同行们明显在家闲得发慌，已经凭着有限的信息做了几轮故障排查。昨天晚上有人发大白高举手机找信号的图片时，同行们就已经明确判断：这玩儿不可能是网络信号的问题，手机举高是没用的，手机开飞行模式也是没用的。

为啥呢？原因很简单，核酸系统崩的同时，抖音照旧在刷，微信照样在聊，说明4G/5G网络是畅通的。没道理别的APP都能连上互联网，就核酸系统连不上。

当然这个解释给IT同行看看是很明显的，非IT行业的人士可能觉得没那么明显。我可以再稍微多解释两句。简化地说，智能手机上的各个APP，都是通过一个叫TCP/IP的通信协议把自己的数据发给骨干网，然后再分发给各个应用的服务器——你也不必真的懂这些专业名词，大概可以这么理解：所谓“TCP/IP”“通信协议”就是标准的快递信封，“骨干网”就是送快递的车，“服务器”就是收这些快递的收件方。

对骨干网来说，他不关心每个收件方是什么人，他也不关心每个信封里装的是什么东西，他只要知道收件方住在哪儿，再多的信封他也会给你投递过去。那这个快递车有没有压力太大崩溃的时候呢？当然也有。但是这种时候，所有人的快递都会丢，而不太可能只有你一个人的快递丢。

如果微信照发，抖音照刷，而你的APP不工作，那极大概率是你的APP有问题，而不是整个网络有问题。这是常识。大家在家里或者办公室网络不稳的时候都会打开百度看看“网通不通”，网如果通的，再看是不是自己用的那个网站有问题。移动互联网也是一样的。网通着，就是对所有APP都通着，一般来说网络不会对某个APP特别对待——也不是完全没有，但是很罕见，概率很小。

没想到，今天承建这个系统的东软发了个声明。

系统上线后，发现有响应延迟、卡顿等现象，东软集团第一时间组织专家组和坚守现场的公司技术人员，与成都市相关部门一起，排查事故原因，强化安全防护，保证系统运行。据技术专家研判，目前出现的系统响应延迟、卡顿等现象与核酸检测系统软件无关。9月3日零点左右，在进行网络调整之后，系统运行平稳顺畅，效率得到极大提升，当日共完成1200万样本采集量。9月3日13时左右，系统再次无法进行访问，经排查，发现是网络出现故障，在恢复网络连接后，系统于14时左右再次恢复运行。具体网络故障的原因，相关部门正在排查。

公众号：东软集团声明

这个声明吧，我作为一个业内人士，感觉非常眼熟。我们这行业有个传统，一旦什么地方出故障，大家第一件事不是去修复故障，而是想方设法论证“不是我的故障”、“是别人负责的部分出的故障”。因为软件这个东西嘛，第一非常复杂，第二各个部分之间依赖很重很多，第三外人看不懂。一般来说，当事人就是全世界最懂这东西的人。所以，当事人的自证清白（以及论证“是别人的毛病”）就成了一件非常重要而又非常频繁发生的事情——这事，也叫，甩锅。

这种甩锅文案有几个共同要素：第一，“与我无关”。第二，“是你的错”。第三，“专家说的”。东软这个文案，大家自行相与析，看看要素是否齐全。

因为大家都在这个行业里混久了嘛，都是千年的妖精，所以一般来说能预判到谁要甩锅，相关方也会提前准备防锅文案。果不其然啊，很快啊，没有大意，半个小时不到，四川省通信管理局的防锅文案就来了。

二是对成都市主城区内人流量较为集中、核酸采样流量较多的点位进行24小时巡检和靠前保障。截止9月2日19:00，通信行业累计出动应急通信保障人员2299人次，车辆734辆次，完成16164个重要点位和场所、4127条重要线路保障，为全市大规模核酸检测和群众生产生活提供了可靠的通信支撑。

目前，全市通信网络运行平稳，各核酸检测点移动网络覆盖良好，没有出现网络拥塞和故障。

公众号：四川省通信管理局通信行业全力保障成都市全员核酸检测通信网络畅通

我说了嘛，都是千年的妖精，大家客客气气的官样文章下面，全是刀光剑影。不是行业里打滚的人不一定看得懂，要做成分屏对比图来看才清楚。

看看，防锅文案的典范，第一是不能单纯回应甩锅，还得借此机会讲讲自己做了很多工作，第二呢，最重要，必须正面回应甩过来的锅，“反弹”，坚决不接。

所以，网络到底是出现故障了还是没出现故障呢？

所以，东软和省通信管理局，到底是谁在说谎呢？

当然，其实还有这么一种可能性，就，谁也没说谎，昨天发生的故障，确实就跟核酸检测系统软件无关。我也可以简单解释一下。一个信息系统，其实是由很多层次、很多组件共同组成的，东软这样的软件厂商自己做的东西，其实只是其中的一小部分、我们称为“业务系统”的部分，其他东西都是现成拿来用的。

比如说，在这么一个典型的系统架构里面，处理“核酸检测登记”这个逻辑的软件，只是图中灰色的“应用系统”这一小部分。应用系统软件运行在应用服务器里，应用服务器比如可能是IBM生产的。应用软件要把数据保存在数据库里，数据库比如可能是Oracle生产的。不那么动态的文件（比如图片之类的）要保存在静态存储里，静态存储比如可能是EMC生产的。用户的网络请求进来的时候，会有个前端服务器先分发一下，静态文件和动态业务请求分别交给存储和应用服务器，这个前端服务器可能是开源的（也就是免费的）Nginx或者Apache。

所以，比如说，如果前端服务器出了故障，没有把核酸检测的请求发给应用服务器，那么东软自己做的核酸检测系统软件确实就没有收到请求，确实也没出故障。

从我过去的经验来看，这种可能性，也很不小。因为核酸检测这个业务逻辑，它太简单了，要么做对，要么做不对，一般出不了什么中间状态。那么现在东软的核酸检测系统一会儿能用一会儿不能用，很可能就是有些请求根本没去到业务软件。业务软件没有收到请求，当然也不能算软件出了故障。

然而问题在于，东软你卖的不光是你自己做的业务软件啊，你卖的是“全场景疫情病原体检测信息化解决方案”啊。你的解决方案里是包含了“高并发、高可用”的基础设施的啊。

要不然你把当初采购这个系统的成都市卫生健康信息中心请出来问问，他们掏钱买的是仅仅东软开发的核酸检测系统软件，还是包含软件硬件网络基础设施全部在内的全场景疫情病原体检测信息系统？他们当初采购的预算里，有没有包含网络接入的费用？东软当初投标的的方案里，有没有包含“高并发高可用”的网络方案？

哦，对了，这项目当初也没招标，是定向采购、紧急采购的。至于说为什么有一套由省大数据中心承建的核酸检测信息系统跑得好好的、7月份扛住了两波疫情冲击、日均检测1000万人次以上的情况下，还需要“紧急采购”，紧急到都来不及公开招个标。这我就不知道了，我也不分析。

（我是特别特别烦微信公众号不让给外链。反正这些信息网上都查得到，感兴趣的读者可以自行验证。）

总之，我们一帮同行分析吧，这个事呢，东软是很难把锅甩得出去了。第一，人家甲方当初采购的就是端到端的解决方案，你自己吹的解决方案里就包含了高并发高可用，现在网络没出故障，测核酸罚站的人群微信照发抖音照刷，就你东软的系统不可用，这锅完全落在你自己解决方案的筐子里，你自己得背好。第二，在解决方案的筐子里面，数据库、应用服务器、存储、前端服务器等等标准组件，行业里大家都知道，基本上都是铁板，一般来说不会出故障的，一般来说都是系统集成商（也就是东软这一角）没用好才出故障。也就是说，不管从外部还是内部，东软这个能力不足造成的锅，很难甩掉，自己背好。

当然了，谁分析都可能有错，尤其现在信息披露得这么少的情况下。既然东软的声明都说有专家分析了，可以请把专家诊断调试的信息发出来嘛，大家一起来看看到底故障出在哪儿嘛。天府软件园别的没有，程序员有十万，你贴一堆错误堆栈信息别人看不懂，成都高新区有很多业主群会帮着你分析的。阳光是最好的消毒剂嘛对不对。

哦对了，现场播报个后续：今天（9月3日）上午，各市核酸点再次开始使用东软系统进行检测，中午左右系统再次崩溃。下午高新区、天府新区多个核酸点改为使用原来的省级核酸检测信息系统，老系统运行正常，核酸检测平稳高效进行。

长按二维码关注

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。