引言
2022
昨天（9月2日）成都的核酸系统崩了。软件园的同行们明显在家闲得发慌，已经凭着有限的信息做了几轮故障排查。昨天晚上有人发大白高举手机找信号的图片时，同行们就已经明确判断：这玩儿不可能是网络信号的问题，手机举高是没用的，手机开飞行模式也是没用的。
不是网络信号的锅
到底是谁在说谎？
这种甩锅文案有几个共同要素：第一，“与我无关”。第二，“是你的错”。第三，“专家说的”。东软这个文案，大家自行相与析，看看要素是否齐全。
因为大家都在这个行业里混久了嘛，都是千年的妖精，所以一般来说能预判到谁要甩锅，相关方也会提前准备防锅文案。果不其然啊，很快啊，没有大意，半个小时不到，四川省通信管理局的防锅文案就来了。
二是对成都市主城区内人流量较为集中、核酸采样流量较多的点位进行24小时巡检和靠前保障。截止9月2日19:00，通信行业累计出动应急通信保障人员2299人次，车辆734辆次，完成16164个重要点位和场所、4127条重要线路保障，为全市大规模核酸检测和群众生产生活提供了可靠的通信支撑。
目前，全市通信网络运行平稳，各核酸检测点移动网络覆盖良好，没有出现网络拥塞和故障。
公众号：四川省通信管理局
我说了嘛，都是千年的妖精，大家客客气气的官样文章下面，全是刀光剑影。不是行业里打滚的人不一定看得懂，要做成分屏对比图来看才清楚。
比如说，在这么一个典型的系统架构里面，处理“核酸检测登记”这个逻辑的软件，只是图中灰色的“应用系统”这一小部分。应用系统软件运行在应用服务器里，应用服务器比如可能是IBM生产的。应用软件要把数据保存在数据库里，数据库比如可能是Oracle生产的。不那么动态的文件（比如图片之类的）要保存在静态存储里，静态存储比如可能是EMC生产的。用户的网络请求进来的时候，会有个前端服务器先分发一下，静态文件和动态业务请求分别交给存储和应用服务器，这个前端服务器可能是开源的（也就是免费的）Nginx或者Apache。
所以，比如说，如果前端服务器出了故障，没有把核酸检测的请求发给应用服务器，那么东软自己做的核酸检测系统软件确实就没有收到请求，确实也没出故障。
从我过去的经验来看，这种可能性，也很不小。因为核酸检测这个业务逻辑，它太简单了，要么做对，要么做不对，一般出不了什么中间状态。那么现在东软的核酸检测系统一会儿能用一会儿不能用，很可能就是有些请求根本没去到业务软件。业务软件没有收到请求，当然也不能算软件出了故障。
然而问题在于，东软你卖的不光是你自己做的业务软件啊，你卖的是“全场景疫情病原体检测信息化解决方案”啊。你的解决方案里是包含了“高并发、高可用”的基础设施的啊。
要不然你把当初采购这个系统的成都市卫生健康信息中心请出来问问，他们掏钱买的是仅仅东软开发的核酸检测系统软件，还是包含软件硬件网络基础设施全部在内的全场景疫情病原体检测信息系统？他们当初采购的预算里，有没有包含网络接入的费用？东软当初投标的的方案里，有没有包含“高并发高可用”的网络方案？
哦，对了，这项目当初也没招标，是定向采购、紧急采购的。至于说为什么有一套由省大数据中心承建的核酸检测信息系统跑得好好的、7月份扛住了两波疫情冲击、日均检测1000万人次以上的情况下，还需要“紧急采购”，紧急到都来不及公开招个标。这我就不知道了，我也不分析。
结语
总之，我们一帮同行分析吧，这个事呢，东软是很难把锅甩得出去了。第一，人家甲方当初采购的就是端到端的解决方案，你自己吹的解决方案里就包含了高并发高可用，现在网络没出故障，测核酸罚站的人群微信照发抖音照刷，就你东软的系统不可用，这锅完全落在你自己解决方案的筐子里，你自己得背好。第二，在解决方案的筐子里面，数据库、应用服务器、存储、前端服务器等等标准组件，行业里大家都知道，基本上都是铁板，一般来说不会出故障的，一般来说都是系统集成商（也就是东软这一角）没用好才出故障。也就是说，不管从外部还是内部，东软这个能力不足造成的锅，很难甩掉，自己背好。
当然了，谁分析都可能有错，尤其现在信息披露得这么少的情况下。既然东软的声明都说有专家分析了，可以请把专家诊断调试的信息发出来嘛，大家一起来看看到底故障出在哪儿嘛。天府软件园别的没有，程序员有十万，你贴一堆错误堆栈信息别人看不懂，成都高新区有很多业主群会帮着你分析的。阳光是最好的消毒剂嘛对不对。
哦对了，现场播报个后续：今天（9月3日）上午，各市核酸点再次开始使用东软系统进行检测，中午左右系统再次崩溃。下午高新区、天府新区多个核酸点改为使用原来的省级核酸检测信息系统，老系统运行正常，核酸检测平稳高效进行。
本篇金句
……
一般来说，都是系统集成商没用好才出故障。
对于核酸检测系统故障问题，你怎么看？
如果你有和投资人对接的相关问题