观察者网：根据目前披露的信息，成都核酸系统崩溃，问题可能出在哪里？

熊节：就核酸系统来说，它的数据写入并不复杂，从检测量推算，平均下来也就是每秒300左右的并发，这放在IT系统里面来说压力不算大。有很多常见的IT系统，比如银行、支付、电商等系统都能够很好承载这种水平的压力。所以就单纯从技术上来说，核酸检测系统的压力负载不算特别大的。

从目前的情况来看，是新旧系统切换，又恰好赶上了全市的静态化管理，需要三天三次核酸检测，所以就出现了问题。对于“东软”这套新系统，我认为它是在非功能性需求没有得到充分验收的情况下紧急上线，所以才出现了系统崩溃不能响应的情况。

一般来看，如果在这种负载量较大的情况下，测试和验收做得不充分，就可能导致系统在之前小范围试用的时候运转良好，但是一旦到了全市大范围使用的时候，经受不住压力考验继而崩溃。我觉得这是一个比较明显的问题。

核酸检测采样（新华网资料图）

观察者网：您提到了系统验收的问题。除却微观个案，从宏观的角度看，类似的情况在数字化系统建设过程中是否也存在呢？除了验收，在数字化建设项目中还存在哪些亟待关注的短板和不足？

熊节：核酸检测系统其实挺有代表性的。这两年新冠疫情的影响，某种意义上也推动了我们国家数字化建设的发展，迫使我们上线了很多重要的数字化系统，健康码、行程码、核酸码都是典型的例子。

同时，它也暴露出来我们数字化建设过程当中的一些短板。因为数字化系统，尤其是软件系统，它和传统的工程建设系统有很大的区别。

第一，对于数字系统的产物交付，很多甲方的处理边界是模糊的。软件产品交付给甲方以后，甲方是不是真正拥有了这个软件系统，其实经常是很成问题的。甲方经常名义上拥有了一个软件，实际上完全对这个软件没有控制。

它体现出来的现象之一就是，甲方采购一个系统以后，就会形成对厂家的严重绑定和依赖。如果想进行后续的维护，找其他厂家来做就非常困难，因为厂家都会有自己的技术门槛、技术壁垒，这给甲方的选择造成很大的约束。

第二，甲方对软件研发的过程缺乏管控。在软件系统的采购中，或多或少都存在这个问题。这不是说我们没有软件工程的标准方法，或者是没有项目监理之类的角色，但是实际上的情况就是我们这个行业里面，软件工程方法都是比较浮于纸面的，包括甲方自己的验收和第三方的监理也存在这一问题。

对于不少甲方和监理而言，他们管理的更多是流程，管理的是文档，很少有甲方或者监理有能力进入到系统的源代码里面去，去了解系统的整个建设过程到底是怎么在发生的。

这就带来第三个问题，就是对软件研发的质量缺乏管控。我们可以用建筑行业做一个类比，比如说甲方单位要修个大桥，那么监理肯定要关注建设过程中的若干质量要求，包括设计的质量、施工的质量等等。可大量软件项目的质量把控其实做得是非常皮毛的，如果我们把软件系统类比为一座大桥的话，很多软件项目的验收就是一辆车在桥面上开过一次，项目就验收了。

这种现象在建筑行业中是不可想象的，甲方起码得验收最终交付的建筑跟当初的设计是否吻合，起码得验收大桥的结构是斜拉还是桥墩、有几个桥墩、桥墩的结构强度是否符合要求……然而有很多软件项目，甲方根本没有去验收软件的架构设计是否得到了实施，就好像验收大桥的时候根本不看有几个桥墩，找辆车开过去就验收了，因为甲方并没有能力去了解这个软件的架构到底是什么样的。