解析东软对成都核酸检验系统故障声明中的数据

昨天随手写了《从核酸检测平台崩盘看性能工程的范围》。

在我仔细看了东软集团的《声明》之后，看到其中有几个数据：

在这个声明中，丝毫没有看到东软对此事有任何的亏欠，只看到了军功章在闪耀。

我还看到东软的人这样说：

这话说的这么富丽堂皇，你接这项目的金额是多少？东软就是为了民生而吃苦受累、流血流汗不求回报地干了这活了吗？搞得跟英雄似的。

技术厂商的存在就是为了支撑业务场景，这是份内的事情，做了一个系统结果崩溃了，还好意思委屈流泪吗？这不是本该挨打的事情吗？事情做不好，挨打就要站稳，没能力就别承接。

今天我就来聊聊声明这两个数据到底对系统的要求究竟有多“高”，看看你们值得不值得炫耀。

通常我们都可以在一个面对公众的系统出现故障之后，会看到官方发布这样的声明，在声明中也总会有一些看似很高的数据，以示厂商的能力还是非常强悍的。

对于非IT技术专业的民众，看到这样的数据，有一种“厂商其实也不容易，厂商已经做的非常好了”的幻觉，估计是厂商的声明想达到的效果。

我们看到的IT系统甩锅有两个经常出现的问题：网络不足和磁盘能力不足。

既然东软用了网络甩锅，我们就用声明中公布的数据来算算网络到底需要多少。

在成都核酸系统的这次故障中，并没有给出每天或每小时给出的支持人数。但文中提到在上海“平均每小时600万人次”，我先拿这个数据来推算，然后再来说成都的这次故障。那就是：

6000000 ÷ 3600 ≈ 1,667（人次/秒）

做过性能项目的人都应该可以感觉得到，这个容量要求并不高。那我们来算算网络带宽需要多少呢？

根据我做过的核酸系统的经验数据。请看下图中的"summary +"开头的数据。

用户级TPS在9000以上，这个是在容量场景下，也就是模拟真实用户操作的场景。这个场景对应的带宽是：

上图三列数据从左往右依次是2s/10s/40s内的平均带宽。按行来看，第一行是出口带宽，第二行是入口带宽，第三行是带宽之和。

我们就用用户级TPS 9000，带宽260Mb（注意这里是小b，即bit，位）来计算，因为我们通常所说的带宽百兆、千兆都是指的单边，所以这里我用260Mb来计算。那就是：

(260×1024)÷8÷9000≈3.7(KB/T)

也就是每个用户级的事务T产生的带宽是3.7KB（注意上面我已经除以8，所以换成了大B）。3.7KB已经可以传一个不小的接口了，并且在我这个数据是在没有上CDN之前。

在昨天的文章《从核酸检测平台崩盘看性能工程的范围》中，我们说到四川全省的全部核酸采集点在12000左右，成都市在3000左右（这个数据已经是高于公开核酸采集点数据的50%了）。

也许你要说，因为疫情严重，所以成都市可能会有更高，那我们就再增加一倍，成都市算6000个采集点，那四川全省的采集点就是在15000个左右。

我们来算一个表格：

也就是说就算是并发度达到20%，核酸采集点达到15000的时候，用户级的TPS才需要3000。

根据上面计算的一个用户级的带宽会用到3.7KB，那也就是3000TPS需要单边带宽：

(3000×3.7)×8÷1024 ≈ 87Mb

注意，上面我已经乘以8，转换成了小b。

那成都市总共人口在2000万左右，我们估高一点算2500万。全部完成需要的采集时长是：

25000000÷3000÷3600 ≈ 2.31(小时)

也就是说，如果所有人都没有任何间歇地干活，连气都不喘，这个核酸检测系统也能够支撑的情况下只需要最多最多2.31个小时就做完了。

如果按4%的并发来算，有兴趣的同学可以自行算一下，只需要17Mb，2500万检测完一轮需要12小时左右，这也不算慢了。

但是由于人是需要休息的，并发度也是没那么高的，采集点也是往高了估的，所以这里都是按上限的上限来计算的，才需要约87Mb的出口带宽。

真实带宽需求比这个值应该会小很多。

所以这个网络锅甩的真是没水准。除非是由于沟通协调不到位，连这么点带宽都不给你一个核酸系统用，各层干系人都等着出问题吗？

更别说声明中北京的一天2000万人次，一天如果只工作8小时，对系统的TPS需求才不到700！

这样的数据，你好意思拿出来说自己干的挺好吗？

性能容量评估的价值是支撑真实的业务场景，离开了这个目标，所有的过程都像笑话一样。

当你支撑不了业务场景的时候，默默反省背锅就行了，拿出点态度也算是真诚的，别再写这种表扬加悲壮的声明了。