餘鵬鯤：被集火的西安“一碼通”，為什麼給羣眾添了堵

【文/科工力量專欄作者 餘鵬鯤】

西安的疫情牽動着全國人民的心，人們在表達關心關切的同時，也對西安應急抗疫工作提出了批評和責備。西安“一碼通”是被集火的對象，作為抗擊疫情最重要的數字資產和信息基礎設施，西安“一碼通”幾度癱瘓，為本就心情鬱悶的羣眾添了堵。由於類似的情況並不多見，人們不禁要問西安“一碼通”（以下簡稱“一碼通”）有什麼技術上克服不了的問題？為什麼不能夠在疫情面前持續提供服務？

“一碼通”再度宕機後，西安市委組織部1月5日公佈：因履職不力，西安市大數據資源管理局黨組書記、局長劉軍停職檢查。劉軍此前分管的工作正是“一碼通”工作專班，這一事件標誌着行政問責的開始，同時也充滿了尷尬。

此前“一碼通”崩潰後，工信部已經派員指導“一碼通”工作，也將這一工作的重要性提升到“政治站位”的高度。然而幾天之後，“一碼通”又崩了。

儘管有西安市民表示，這次崩潰恢復得很快，只用了近5小時就通了，比第一次好多了。但這一事件本身，仍然暴露出西安數字政務體系的嚴重問題，5小時才修復已經是嚴重落後於時代了。

此外，“一碼通”工作是由西安大數據管理局負責監管的，但是“一碼通”不是大數據業務。如果説“一碼通”崩潰時第一次的訪問量是一筆糊塗賬，那麼第二次就很清晰了。

1月4日，西安封城管控，“一碼通”只用來做核酸和查核酸檢測結果。由於崩潰時，核酸檢測只是初步開始，因此查核酸檢測結果的人並不多。同時，核酸檢測是分批進行的，並且在同一批中還是排隊進行。這麼一算，當時同時訪問“一碼通”的人數，高峯期充其量也就是5分鐘50萬人。

“一碼通”又沒有什麼複雜的交互，以查詢為主。5分鐘內50萬人對不超過4000萬人（2021年西安常住人口1295萬，這裏是從高估計的結果）的數據進行訪問，這怎麼能算是大數據業務呢？

因此，儘管是大數據資源管理局局長被問責，但是“一碼通”就是一個常規業務。這一事件也説明，地方政府對信息產業的監管，目前還是合規性監管和價值觀監管，在技術性監管方面乏善可陳。

那麼我們就從技術角度出發看一看，常規業務“一碼通”需要哪些保障，又是怎麼崩潰的。

“一碼通”的問題出在軟件上

作為常規業務的“一碼通”，存在很多先天優勢，本該堅如磐石。全國類似平台這樣崩潰的幾乎沒有，也證明了這一點。

首先是訪問侷限在城域網內，“一碼通”是西安用户訪問西安服務器，跨城市訪問的流量可以忽略不計。這樣的業務可以很容易地採取一些激進的優化措施，並且不會造成穩定性問題。

同時，“一碼通”是權威平台。即使出現了崩潰，只要十分鐘之內重整了，羣眾就會很自然的以為是自己信號有問題，或者網絡卡了，根本不會產生輿情波動。

因此“一碼通”的問題，實質是崩潰臨界訪問量太小，以及重整修復速度太慢疊加造成的。

大型電子商務網站系統架構，來源CSDN

上圖是常見的商務網站系統架構，代表了目前主流網站的技術架構和先進生產力，“一碼通”業務的架構雖未公佈，但也應該大同小異。類似架構的網站，數據送入用户手中，要經過發送請求、數據查詢、服務器響應、服務器分發、網絡傳輸和接收等過程（如下圖所示）。

主流網站查詢業務流程

這些過程中，可能出現的硬件問題是服務器過載，以及網絡阻塞。

由於響應“一碼通”應用的請求、分發數據、負載均衡都需要消耗服務器資源，因此訪問量的增大必然帶來服務器過載，目前服務器資源幾乎都是以雲的形式提供，服務器資源可實時增加。

疫情封城時，陝西本地其他雲資源訪問量下降。如果陝西的雲提供商下決心保通“一碼通”，甚至跨區域協調資源，“一碼通”所需的服務器資源是有保證的。

網絡阻塞，又分為上行阻塞和下行阻塞。上行阻塞就是用户向服務器發送的信息過多，佔滿了上行帶寬。下行阻塞就是服務器向用户發送的信息太多，佔滿了下行帶寬。如果是合理的網絡佔用，主要看陝西雲服務提供商以及網絡業務開發者的對接工作。從全國來看，雲資源比陝西少的省也是沒有任何問題的。

資源沒有問題，雲服務商願意配合，網絡業務開發時，有自動化的應對方案，那麼“一碼通”就不會出現網絡阻塞的問題。換句話説，“一碼通”的問題主要是軟件問題。

業務邏輯不合理是硬傷

按照查詢業務流程，負載均衡、數據庫、服務器業務和應用端業務都有可能造成這個問題。具體地來説，是個別服務器壓力過大、數據庫訪問延遲增加、服務器業務處理時間過長、應用端發送內容過大等問題。這裏面除了負載均衡，都可通過增加業務資源和合理改變業務邏輯的方式去解決。

負載均衡問題目前還未完全解決，繼續深入也非常困難。但這裏説的困難，是大型互聯網企業要考慮的。“一碼通”的訪問量，哪怕是用免費開源的Nginx和Apache也不難解決。

“一碼通”的業務邏輯恰恰不合理，“一碼通”的核心是健康碼，然而“一碼通”還融合了政務二維碼掃描、公民電子證件、健康碼、公積金、城市新聞、政務地圖、幼兒託管、停車數據查詢、天氣、空氣質量等等業務，是一個複雜的系統。

根據相關媒體的報道，至少有六家企業參與了“一碼通”開發運營。

從數據庫的角度講，怕的是鎖（數據庫軟件中的一種機制，用於防止意外寫入）太多。12306系統的訪問量比淘寶“雙十一”期間的訪問量要小好幾倍，依然無法自如地應對春運，根源就在於火車票務業務的鎖太多。

將各種業務集合為“一碼通”，本身並不意味着鎖更多。但將業務融合在一起後，就會催生出數據庫聯合查詢的需求，以及更多需要鎖的需求。有從事軟件開發行業的西安網友，結合使用“一碼通”的經歷，指出：“一碼通”在崩潰之前，疑似默認聯合查詢核酸檢測結果以及健康碼狀態。

由於健康碼狀態和核酸檢測結果的查詢密度存在數量級的差異，如果網友反映的問題是真的，這種安排的合理性屬實值得商榷。

同樣地，將政府應用聯合成“一碼通”，也不利於服務器處理以及精簡應用上傳數據。因為健康碼業務無需接收大量數據，而城市新聞、地方天氣等功能都需要預先獲取服務器的許多資源，更不用説這些功能還要產生大量的上行數據。

筆者願意直説，這種將市民需求量相差很大的業務捆綁在一起的做法，是部門本位的體現，也浪費了大量資源。一個普通西安市民可能一天要出示3-4次健康碼，但是城市新聞一天更新一次也夠了。城市新聞陪着健康碼更新，浪費了大量上下行帶寬。

此外，將多種業務捆綁到一起後，在技術上往往就低不就高。很多政務系統老業務採用的技術棧十分陳舊，與需要較新技術支持的健康碼捆綁到一起，成倍地放大運營中的風險因素。根據財新網的消息，有不願透露姓名的內部人事説：“問題可能出在連接一碼通和數據平台間的安全防護機制過載”。

如果財新網的報道屬實，還是要怪“一碼通”設計了這樣冗雜不合理的業務，又跨了太多的機構和部門。

“一碼通”並非一直這麼複雜，疫情之初的“一碼通”就十分簡潔。現在這個“一碼通”，是升級改造後的結果。這也許從一個側面説明，為何爆發疫情人心惶惶時，“一碼通”經歷住了考驗。反而是疫情爆發兩年後，“一碼通”多次突發癱瘓。

新舊一碼通界面對比，左為現今版本，右為早期版本

根源是信息體系建設不完善

2021年6月，《人民郵電報》刊登了《“科技抗疫”中流砥柱：西安電信“一碼通”平台服務保障專班》報道。文章中盛讚：“金盃銀盃不如老百姓的口碑。‘有了一碼通，出行更便捷，防疫更輕鬆’。人民羣眾沉甸甸的評價是對保障專班最好的褒揚”。

待到“一碼通”成為批判對象後，這樣的文章就顯得非常諷刺。不過從當初的報道中，我們還是能看到“一碼通”後來出問題並非偶然，根源在於信息體系建設不完善。

“一碼通”的核心功能是健康碼，是怎麼開發出來的呢？“保障專班召之即來、來之能戰，主動整合既有產品能力，全體成員三天三夜不眠不休，研發出西安市個人電子識別碼”。

也就是説健康碼三天就研製出來了，剩下的時間多花在了增加功能上，該報道再也沒有提到與健康碼直接相關的保通工作。這其實反映了很多幹部羣眾的軟件開發觀，在他們眼中，軟件升級就是不斷增加新的功能，軟件升級的目的就是充分利用硬件性能。

這與軟件開發觀念完全違背，在穩定的前提下，性能是軟件最重要的功能。但是很多領導幹部，由於本身並不日常使用相關軟件，因此不注重性能方面的要求。在理想的情況下，軟件開發中增加功能點應該以完全不影響速度為前提。性能的冗餘對穩定性非常重要，軟件的負載不應該不斷提高。

此外，軟件是為了某個目的而開發的，其專用性非常重要。喜歡搞個大綜合，號稱要“1+1>2”早已成為政務軟件和企業內部管理軟件先天不足的重要原因。這也搞，那也搞，必然是要犧牲軟件的速度、穩定或健壯性之一的。

承認軟件有專用性的情況下，就要承認隨着時代的發展，軟件是必然要重構的，小車不倒只管推的思路是不行的。Win11裝IE瀏覽器已經很困難了，政務系統還有很多業務只能靠IE瀏覽器訪問。Flash已經停止維護了，依然跑着很多機關的核心業務。今後這樣的業務，想要與其他業務配合的難度將越來越大。

該報道中，還有更多的雷人內容，指向政務軟件開發運維兩張皮的問題。“一碼通”保障專班僅僅將1MB的一張圖片，壓縮到100KB，就用了兩天兩夜。

相關報道中令人震驚的內容

很多網友對此事竭盡嘲諷，因為從技術上説，有損壓縮的圖片的大小可以逼近0。同時已經有自動化壓縮的免費工具了，可以按照想要的大小，按可能的最高質量進行壓縮，因此有人認為“開發者甚至不善於利用搜索引擎”。

筆者認為沒有這麼簡單。如果“一碼通”保障專班水平真的如此之低，完全不可能開發“一碼通”這樣的應用。更有可能的情況是，來自於“上面”的要求，對圖片的風格質量都做了詳細的規定，甚至需要有關方面批准，才導致“工作看似簡單，卻藴含着高技術含量”。開發者在這樣的情況下，絞盡腦汁的縮小圖片的大小，説明其對緊急狀態下能調用的資源沒有信心。

“一碼通”曾經“日均訪問量達千萬人次”，並且在應急擴容中表現出色，但當時的相關工作是“在西安市疫情防控指揮部的統一指揮下”。隨着疫情防控常態化，“召之即來”的開發者回到原先的單位，“一碼通”崩潰時管理者保障乏力也就不難理解了。

沒有了原先的協調級別，沒有了精幹的技術團隊，“一碼通”信息體系建設的不完善集中地暴露了出來。

“一碼通”事件説明，監管部門技術力非常薄弱，鬧了很多笑話。完善信息體系，最需要的就是相關部門的領導擺脱大甲方的心態。在業務主要靠外包的情況下，必須要對領導自身的技術水平進行考核。不然要麼提出些貽笑大方的需求，要麼完全被外包公司的技術棧拖着走，終究不是長久之計。

一切問題最終是人的問題，領導幹部的技術水平不提高，技術思想更新的就慢，更不會去想線下業務與線上業務匹配的問題。

同時，信息體系建設必須有輕有重，詳略得當。“一碼通”27萬的招標價已經成為了笑話，妄圖以普通政務軟件的價格，購買日活上千萬的軟件，必然加重後續運營的歷史負擔。

最後，建設信息體系建設必須保障開發人員的建議權和運維人員的無責緊急決斷權。開發人員享有建議權，有利於避免寫出業務邏輯不合理的應用。運維人員享有一定條件下的無責緊急決斷權，最壞不過是浪費了錢，對一碼通這樣的業務，卻能在崩潰重整時節約大量寶貴的時間。

本文系觀察者網獨家稿件，文章內容純屬作者個人觀點，不代表平台觀點，未經授權，不得轉載，否則將追究法律責任。關注觀察者網微信guanchacn，每日閲讀趣味文章。