【文/觀察者網專欄作者 熊節(jié)】

與新冠疫情防控相關的軟件系統(tǒng)在關鍵時刻出現(xiàn)技術故障的問題，一直以來備受關注。這樣的重要系統(tǒng)屢屢出現(xiàn)重大技術故障，暴露出我國當前數(shù)字化建設過程中的若干短板，尤其是整個信息產業(yè)普遍缺乏交付可信軟件系統(tǒng)的能力。

“可信”的門檻

按照英國可信軟件基金會（Trustworthy Software Foundation）的定義，可信的軟件系統(tǒng)應當具備以下5個方面的特質：

無害性（Safety）：軟件運行時不會對任何東西或任何人造成傷害。

可靠性（Reliability）：軟件正確運行不發(fā)生錯誤的能力。

可用性（Availability）：軟件在需要時正常運行并提供服務的能力。

堅韌性（Resilience）：軟件從錯誤中快速和完全恢復的能力。

安全性（Security）：軟件防護惡意軟件、黑客或意外誤用造成危險的能力。

所有人都會贊同，良好的軟件系統(tǒng)應當具備上述這些特質，服務于大眾重要應用場景的軟件系統(tǒng)應當是可信的。然而事實證明，獲得可信的軟件系統(tǒng)并非易事。即便是當前最受重視的疫情防控相關系統(tǒng)，由“已在國內17個省120多個地市部署應用”的行業(yè)領先企業(yè)來實施，仍然會在關鍵時刻不可用、且無法從錯誤中快速恢復。

更值得關注的是，在我國大張旗鼓開展數(shù)字化新基建的大背景下，采購軟件系統(tǒng)的甲方單位普遍缺乏對軟件項目實質性的監(jiān)管治理能力。大部分甲方單位、尤其是信息化程度較低的傳統(tǒng)行業(yè)和中西部地區(qū)甲方單位，基本不具備實質管控軟件項目的能力。

曾經，某西部地區(qū)知名國企采購一個軟件系統(tǒng)后，不確定乙方是否按合同要求交付了源代碼，請筆者幫忙鑒定。筆者打開甲方傳來的一個壓縮包一看，只有若干光禿禿的.java源文件，前端網頁源碼、構建腳本、配置文件、數(shù)據庫腳本、部署腳本等必要工作件（artefacts）全部付之闕如。

拿著這樣一堆“源代碼”，甲方根本不可能重新構建出線上運行的軟件系統(tǒng)，甚至無法知道自己拿到的究竟是不是線上系統(tǒng)的源碼，更遑論對其質量和可信性進行任何有效的管控。

在極度簡化的場景下，軟件開發(fā)商使用人類可讀的編程語言來開發(fā)軟件，產出的成果就是源代碼。源代碼和圖片、文本等各種資源文件一起，再加上眾多依賴軟件，通過一個叫做構建的過程，被打包成為可執(zhí)行的軟件包，其中的內容通常是人類不可讀、但是計算機可以執(zhí)行的二進制文件。這個軟件包再與各種配置文件相結合，通過叫做部署的過程，被安裝到真實使用的生產環(huán)境上，成為線上運行的軟件系統(tǒng)。

典型的（過度簡化的）軟件交付過程

在這個過程中，所有工作件的質量、所有操作的質量，都會影響最終線上系統(tǒng)的質量。

然而在當前我國數(shù)字化項目建設中，很多甲方只獲得乙方構建部署完成后的線上系統(tǒng)，對構建過程、部署過程及涉及的工作件無法觸及，也沒有專業(yè)技術能力評判這些過程和工作件的質量。毫不夸張地說，很多數(shù)字化項目中，甲方實際上只獲得了軟件系統(tǒng)的使用權，根本沒有獲得系統(tǒng)的所有權。

甲方對軟件系統(tǒng)所有權和管控權的缺失，會帶來兩個直接的惡果。首先是形成對廠商的嚴重依賴甚至綁定。因為甲方沒有掌握軟件交付過程和工作件，未來任何修補和增強都只能依賴原廠商，客觀上形成原廠商的反競爭壁壘。另外，軟件系統(tǒng)質量是否過關、是否可信，因為甲方不掌握軟件交付過程和工作件，基本只能依賴廠商“又當球員又當裁判”。

筆者在之前接受觀察者網采訪時打了一個比方：

我國現(xiàn)在很多軟件系統(tǒng)的驗收，甲方既沒有能力檢驗軟件的無害性、可靠性、可用性、堅韌性、安全性等非功能指標，也沒有能力深入軟件交付過程審核其架構質量、代碼質量、供應鏈質量等質量指標，常常只是以最終用戶視角把軟件功能跑一遍就完成了驗收。這就好比修建一座大橋，甲方既不檢查橋梁結構是斜拉式還是拱式，也不監(jiān)督橋墩的施工質量，到竣工那天開一輛小轎車從橋面上順利通過就算完工驗收。至于大橋是否安全可靠，就全憑乙方自己提供的一堆文檔來論證了。

這聽起來可能荒誕，卻是當前行業(yè)的真實現(xiàn)狀。