【文/观察者网专栏作者 熊节】

与新冠疫情防控相关的软件系统在关键时刻出现技术故障的问题，一直以来备受关注。这样的重要系统屡屡出现重大技术故障，暴露出我国当前数字化建设过程中的若干短板，尤其是整个信息产业普遍缺乏交付可信软件系统的能力。

“可信”的门槛

按照英国可信软件基金会（Trustworthy Software Foundation）的定义，可信的软件系统应当具备以下5个方面的特质：

无害性（Safety）：软件运行时不会对任何东西或任何人造成伤害。

可靠性（Reliability）：软件正确运行不发生错误的能力。

可用性（Availability）：软件在需要时正常运行并提供服务的能力。

坚韧性（Resilience）：软件从错误中快速和完全恢复的能力。

安全性（Security）：软件防护恶意软件、黑客或意外误用造成危险的能力。

所有人都会赞同，良好的软件系统应当具备上述这些特质，服务于大众重要应用场景的软件系统应当是可信的。然而事实证明，获得可信的软件系统并非易事。即便是当前最受重视的疫情防控相关系统，由“已在国内17个省120多个地市部署应用”的行业领先企业来实施，仍然会在关键时刻不可用、且无法从错误中快速恢复。

更值得关注的是，在我国大张旗鼓开展数字化新基建的大背景下，采购软件系统的甲方单位普遍缺乏对软件项目实质性的监管治理能力。大部分甲方单位、尤其是信息化程度较低的传统行业和中西部地区甲方单位，基本不具备实质管控软件项目的能力。

曾经，某西部地区知名国企采购一个软件系统后，不确定乙方是否按合同要求交付了源代码，请笔者帮忙鉴定。笔者打开甲方传来的一个压缩包一看，只有若干光秃秃的.java源文件，前端网页源码、构建脚本、配置文件、数据库脚本、部署脚本等必要工作件（artefacts）全部付之阙如。

拿着这样一堆“源代码”，甲方根本不可能重新构建出线上运行的软件系统，甚至无法知道自己拿到的究竟是不是线上系统的源码，更遑论对其质量和可信性进行任何有效的管控。

在极度简化的场景下，软件开发商使用人类可读的编程语言来开发软件，产出的成果就是源代码。源代码和图片、文本等各种资源文件一起，再加上众多依赖软件，通过一个叫做构建的过程，被打包成为可执行的软件包，其中的内容通常是人类不可读、但是计算机可以执行的二进制文件。这个软件包再与各种配置文件相结合，通过叫做部署的过程，被安装到真实使用的生产环境上，成为线上运行的软件系统。

典型的（过度简化的）软件交付过程

在这个过程中，所有工作件的质量、所有操作的质量，都会影响最终线上系统的质量。

然而在当前我国数字化项目建设中，很多甲方只获得乙方构建部署完成后的线上系统，对构建过程、部署过程及涉及的工作件无法触及，也没有专业技术能力评判这些过程和工作件的质量。毫不夸张地说，很多数字化项目中，甲方实际上只获得了软件系统的使用权，根本没有获得系统的所有权。

甲方对软件系统所有权和管控权的缺失，会带来两个直接的恶果。首先是形成对厂商的严重依赖甚至绑定。因为甲方没有掌握软件交付过程和工作件，未来任何修补和增强都只能依赖原厂商，客观上形成原厂商的反竞争壁垒。另外，软件系统质量是否过关、是否可信，因为甲方不掌握软件交付过程和工作件，基本只能依赖厂商“又当球员又当裁判”。

笔者在之前接受观察者网采访时打了一个比方：

我国现在很多软件系统的验收，甲方既没有能力检验软件的无害性、可靠性、可用性、坚韧性、安全性等非功能指标，也没有能力深入软件交付过程审核其架构质量、代码质量、供应链质量等质量指标，常常只是以最终用户视角把软件功能跑一遍就完成了验收。这就好比修建一座大桥，甲方既不检查桥梁结构是斜拉式还是拱式，也不监督桥墩的施工质量，到竣工那天开一辆小轿车从桥面上顺利通过就算完工验收。至于大桥是否安全可靠，就全凭乙方自己提供的一堆文档来论证了。

这听起来可能荒诞，却是当前行业的真实现状。