9月2日，成都全市居民正在进行全员核酸检测时，“成都核酸系统崩了”登上微博热搜。据网友反映，当天晚间，虽然现场医护人员通过将手机高高举过头顶的方式来获得信号，却依然无济于事。

据媒体后续跟进报道，事实上是成都的核酸检测系统出了问题，该系统背后的开发企业正是“东软集团”，而这也并不是东软第一次出现类似事件。

围绕“东软”的争议及舆论场上热议的话题，四川质量发展研究院高级研究员熊节做出如下评议：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

比如这几年流行“微服务”的概念，这个技术术语代表的是一种软件架构的风格，有很多的厂家会在自己的方案里面写：我们采用了微服务架构，所以我们这个软件很先进。但是绝大部分的项目里面，甲方没有能力对架构进行验收，他根本没法知道这个软件到底是不是采用了微服务架构。

我觉得这是一个很严重的问题。几年前某外企曾经采购过一家中国软件公司开发的软件，乙方也号称是微服务架构，结果甲方有一位从美国来的架构师在会议现场打开系统源代码来检验，指出乙方并没有采用微服务架构。像这样的技术能力，我国大部分非IT行业的甲方是不具备的，因此就留下了更大的“忽悠”的空间。

在具体的项目开发过程中，还有一些其他的问题，比如说企业间的层层转包，企业内部的层层下发，任务最后可能下发到技术能力有限的一些年轻程序员手中，甚至还可能是根本不具备相应能力的“无证程序员”手中，而经验丰富的程序员大部分都是在忙售前阶段的工作，逐渐远离软件开发第一线。这可能就把一些潜在的性能隐患和安全隐患埋到系统里面，再加上前面我们说的甲方的验收质量把控又没做到位，那么这些隐患可能就一直埋下去，最终在正式使用时爆雷。

观察者网：从这些案例出发，您能否为我们总结一下数字化新基建给传统的项目采购和管理机制带来了哪些新的挑战？

熊节：软件项目的招标一般来说是百万千万这样的规模，相对于建筑工程来说，金额没那么大，但是水很深。刚才我们也提到了一点，数字化新基建的软件项目往往有很大的依赖性和绑定性，一个厂商做了一个系统以后，其他的厂家很难在它的基础上去加强完善。

于是，我们就会看到一个现象：一些厂商的系统价格很便宜，甚至是不要钱，它们去投标政府采购的项目，凭借价格优势中标之后就可以长期拿项目。因为只要它们的系统打进去之后，在这上面需要做增强、扩展的时候，政府没办法找别家公司。

因为政府作为甲方，也没有能力掌握源代码，所以二期、三期工程就必须得找同一家来干，你找其他家干不了。于是很多厂商找到了一种绕开公开招投标的方法：一期工程以很低的价格进入，价格低到可以不用公开招投标，然后在二期三期不断做增强，把真正想做的功能放进去，整个工程的金额变得越来越大。由于厂商很容易在软件里设置技术门槛，后面二期三期工程其他厂家很难接手，往往就会变成定向采购。这种现象确实可能会带来中国福彩app官方下载的不透明的操作，甚至中国福彩app官方下载的腐败空间。

新基建资料图

另外一些挑战就是我刚聊到过的，甲方在技术能力上面的缺失。当然甲方不必是技术专家，传统的基建项目也是这样。但是我们要看到这里面有一个相对性，传统的基建项目里，甲方就算不是专家，他对基建的了解程度也是相当深的。可我们看到不少数字化新基建的软件项目，问题严重到可以说是乙方想怎么做就怎么做，最后乙方很简单地跑一下基本功能就完成验收，性能、压力、安全性等非功能需求和软件架构设计质量、研发过程质量、代码质量等内部质量都无法验收。

这是一个很严重的问题，它会造成大量表面光鲜的“豆腐渣”工程在数字化建设中被验收、被使用，对于我们打牢数字化新基建的基础是非常不利的。

观察者网：考虑到这些情况，您觉得各方该如何共同应对此类新挑战？

熊节：我国目前在数字化建设上处于国际领先地位，在全球来说都是逐渐走进了无人区的感觉。进入新的领域以后，就必然会有新的挑战。我觉得这里面除了采购服务的政府部门、参与其中的技术企业要付出努力、积极应对挑战外，还应该有学术界、行业组织和官方标准机构的介入与通力合作。

首先对于数字化系统采购的甲方来说，提升自身的技术能力是必须的。我国当前大张旗鼓开展数字化建设，那么甲方就必须形成与数字化新基建建设相配套的能力。

其次从乙方来说，我觉得从事数字化新基建项目的企业需要做些事情去提高自己的透明度，把研发过程和质量保障过程透明出来，让甲方能看到、能看懂，能够对系统进行有效的质量检验。对乙方企业来说，把原来“黑箱操作”的研发过程和质量保障过程透明出来，这肯定是让渡了自己的短期利益，但同时也是对行业的贡献，也会给自己打开更大的机会之门。

比如华为，它过去几年在国外被打击得比较狠，英国政府要求他们自证软件可信，给他们造成了很多麻烦，但是也倒逼他们发展出了一整套软件可信机制。现在华为就有了这个能力，能证明自己的软件质量是可靠的，性能和安全是过关的，并且甲方也能理解这个验证过程。

同理，国内其他软件厂商是不是能自发地建立起一套机制，主动提升自己的能力和透明度，增加自己在行业内、在社会上的信誉，我觉得这也是需要考虑的。

第三个角度，制定标准的机构和高校，应该考虑去做一些更贴近实际的东西。现在信息技术发展太快，这使得制定标准的机构和高校有点赶不上节奏。比如说行业里流行CMMI认证和ISO认证，我坦率说，这些认证是比较不落地的。对于一线的软件开发者来说，他每天写的代码是不是合乎专业技术水平的要求，是不是达到了应有的质量标准，在这些认证里其实都是空白的，目前行业里也没有充分的管理。

因此，我觉得制定标准的机构和高校也应该考虑把这个事情做得更细更落地一些，真正落到源代码上去。最终软件的质量是落到源代码上，光管文档管流程是管不好软件质量的。那么怎么能建立一套第三方的、中立的、真正扎实有效的过程和质量标准，怎么把这些标准和指导落到源代码上去，这也是一个需要长期解决的问题。

智慧城市运营管理中心（新华网资料图）

第四个角度，目前国内自发的技术社区比较少，我想或许可以组成一个政府、高校、标准制定机构、技术公司、从业人士多方通力合作的交流平台。在此基础上，或许能有一些具备技术能力的、中立的第三方监理和质量监管机构和机制出现。

今天行业里没有这样能落到技术细节上的第三方监理存在，就会导致乙方“又当球员又当裁判”的局面。比如说成都市卫健信息中心提前预判到了核酸检测信息系统会有性能压力，要求东软证明系统性能过关，但是谁有能力进行性能测试呢？实践中就还是东软自己做性能测试，提交性能测试的报告，那么东软就又当球员又当裁判了，因为甲方没有这个能力来开展性能测试，或者验证乙方提供的性能测试报告是否真实。

如果有一家具备技术能力的第三方监理存在，这个第三方就可以站在中立角度估算一组性能指标，开展独立的性能测试，从而给甲方提供更可靠的质量保障。当然这里面还会有利益纠葛，监理机构也有腐败的可能性，但是我们应该首先允许这样的第三方出现，进而再去思考完善之策。

除了性能问题以外，数据安全也是一个非常重要、但是又技术性很强、甲方很难验收的领域。尤其是像核酸检测系统这样全是公民关键隐私数据的系统，应该以什么方式去确保这些系统在采购、设计、研发、上线实施、运维的整个过程当中，考虑了如何保障了公民个人隐私数据安全，并切实地把这些考量落实到了软件系统中，这也是数字化时代一个严峻的挑战。

一方面我们会有越来越多数字化系统的需求，其中很多系统会在相当紧急的情况下开发上线，另一方面每一个考虑不周全的数据接入点都会增加公民关键隐私数据泄露的风险。如何切实地提高全行业数字化系统研发的可信能力，是未来整个IT行业需要应对的挑战。