西安一碼通又“崩”了，半個月崩潰兩次，引發了業界關注，關於事件原因也引起外界諸多猜測。1月6日下午5時許，東軟集團（600718.SH）對投資者回應事故原因時，表示該故障與東軟所處應用層無關。回復稱，在進行現場分析之後，專家提出：“要加強網絡和信息安全，優化應急預案……防止出現網絡安全事故。”等指導意見。

一位接近西安“一碼通”項目的人士向鈦媒體App表示，當下已排除應用層故障；且在故障排查和壓力測試時發現，防火牆設備存在多次丟包現象。由此可以判斷，出故障的防火牆不屬於應用層。那麼故障是由什麼層面出現問題導致的？一次看似平常的健康碼請求，跟防火牆有哪種關聯，為什麼會因為防火牆丟包造成故障？

針對上述情況，鈦媒體App聯繫網絡與信息安全專家李冬，據李冬判斷，西安“一碼通”屬於政務工程，從系統安全上來說，西安市民訪問西安“一碼通”屬於外網訪問內網，二維碼調後台數據用確實要過防火牆，如果並發量超過原有架構設計，確實會發生防火牆丟包的可能。

鈦媒體App從另一位接近西安“一碼通”項目人士處獲悉，自12月20日“一碼通”故障後，多批專家組進駐調查，形成了多份報告，由官方最終拍板的報告尚未發布，但事實大致清楚，這是一起因流量過載、系統架構應對高並發不足，最終導致防火牆攔截數據無法返回的系統性故障。

不過事實上，經鈦媒體App編輯多方求證了解，在西安“一碼通”故障事件中，防火牆丟包雖是最終原因，但或許並不是根本原因。在諸多供應商和事件主體中，究竟是“誰”、在哪些環節出了問題，我們也做了一次全面复盤和還原。

西安一碼通的複雜供應商

西安一碼通的系統建設涉及基礎資源層、網絡層、應用層等多個專業廠商，並且據鈦媒體App了解，這些多個專業廠商在中標合同中分屬不同標的，主要標的有兩個。

一個是“疫情防控平台一碼通項目（以下簡稱：西安“一碼通”），該項目總包為西安電信。自2020年3月西安“一碼通”上線後，西安電信以招標形式分包給近十家科技公司的服務，包括開發與運維、安全相關產品與服務、引擎軟件產品、短信服務、大數據可視化等項目。

另一個是“西安市電子政務統一平台”，該項目簡稱為“政務雲”平台。據鈦媒體App了解到的消息，西安“一碼通”以政務雲平台為技術底座，基於政務雲平台搭建，其基礎資源層、網絡層的所需的存儲、網絡、計算等服務均由政務雲平台輸送，而西安“一碼通”通過西安電信購入的服務，可以統稱為“應用層”服務。

鈦媒體App根據官方公佈的公示信息統計，在應用層服務中，阿里雲提供政務雲和短信服務；西安東軟系統集成有限公司（以下簡稱“西安東軟”）提供“一碼通”軟件開發和運營維護服務；安恆信息技術股份有限公司（下稱“安恆信息”, 688023.SH）提供“一碼通”部分安全項目服務；美林數據股份有限公司（以下簡稱“美林數據”，831546.NQ）提供引擎軟件產品及相關服務；中譯語通科技（陝西）有限公司（以下簡稱“中譯語通”）提供大數據可視化服務。

而在政務雲平台中，北京啟明星辰信息安全技術有限公司（以下簡稱“啟明星辰”，002439.SZ）提供部分網絡安全服務；阿里雲也擔綱了政務雲平台的私有云建設。

在多類服務商糾葛下，問題也變得愈發複雜，這也導致西安“一碼通”故障調查和排除的繁瑣，相關方對事故認定的說法不一。

2021年12月20日，西安“一碼通”第一次故障時，曾有消息將故障原因指向屬於應用層服務提供商的美林數據，但美林數據隨即回應稱：美林主要負責一碼通後台，提供算法，’一碼通’運營不屬於美林。

安恆信息給鈦媒體App發來回應稱，“安恆信息負責’一碼通’的一部分安全工作，保障系統不被網絡攻擊，到現在為止，沒有發現網絡攻擊跡象。”

也有網友捕風捉影，分析稱西安一碼通的“碼”採用圖片形式下發，導致CDN（內容分發網絡）沖垮負載均衡。鈦媒體App求證獲悉，“二維碼以圖片形式下發”的分析系誤讀，健康碼本身並不是以圖片形式傳輸。健康碼就是個ID，通過ID指向數據庫找出對應的信息。

最詭異的是，有傳言稱西安“一碼通”建設是花了27萬，讓小公司幾個實習生來做的項目。對此鈦媒體App查閱官方資料得知，在西安市相關單位發布的中標公告中，確實有條公告信息符合“27萬”、“不知名”公司的條件，並且標的中也明確出現了“一碼通”字眼。

西安科學技術局創新一碼通系統招標信息

但鈦媒體App求證發現，此“一碼通”並非西安“一碼通”。這項20幾萬的項目由“西安市科學技術局”主體招標，時間為2021年11月26日，並且公告全稱為“《創新一碼通系統開發項目競爭性磋商公告》”，公告明確表示該項目為以西安市創碼通系統（以下簡稱“創碼通”）為抓手，加快推動西安“秦創原”整體戰略的落地建設。也就是說該項目實際是西安市“創碼通”項目並非西安“一碼通”。此前傳言為斷章取義。

“一碼通”為何不通？

在雜亂的信息中，有接近西安“一碼通”項目人士向鈦媒體App判斷稱，問題可能在於連接“一碼通”和西安政務雲的安全防護機製過載，讓“一碼通”平台無法調用政務雲上的數據，因此“一碼通”一直無法加載出數據。這一說法也側面排除了應用層故障，將問題矛頭指向政務雲平台以及政務雲平台上的安全防護機制。

綜合多方給我們的回复，從技術上講，“並發訪問量過大觸發防火牆防禦閾值，同時還存在網絡堵塞、丟包現象”的說法最為可靠，但無法單純將責任歸至其中任何一方。

簡單來理解則是，處於應用層的西安“一碼通”在運行過程中由於流量過載，觸發了底層政務雲的防火牆防禦機制。——兩個來自不同標的的各方本來各司其職，但在實際運行過程中卻成為了彼此影響的統一系統。他們看似都沒有直接責任，卻像蝴蝶效應一般，釀成最終故障。

在公開信息顯示的西安“一碼通”事故相關的的近十位服務商中，眾多爭議主要集中在三家廠商——東軟、阿里雲和啟明星辰。

東軟負責西安“一碼通”信息技術平台軟件產品及相關平台功能定制化開發服務。據了解，起初該平台並不是為了支撐西安全員的核酸檢測（核酸檢測需要亮碼），所以平台並沒有設計與之對應的並髮指標。而且在12月20日西安“一碼通”出現故障後，QPS（每秒查詢率）已經擴容至系統最大值4萬，並且重新完善了代碼，但這依然不足以支撐西安全城1200萬人的集中檢測並發量。

阿里雲牽扯其中，不僅因為出現在一碼通的採購清單中，也因為其負責西安政務雲的建設。政務雲核心都採用私有云方式建設，西安政務雲也是如此。

前述接近項目消息人士透露，阿里雲智能DNS解析在“一碼通”中出現了解析錯誤問題，兩條為“一碼通”預留的VIP線路中，有一條出現故障。此外，RDS數據庫中大量慢SQL，也導致了流量擁堵。這兩個問題在後續排查中被快速解決。

但在後續求證中，阿里雲一位發言人直接向鈦媒體App否認了上述兩個問題，指出雲平台遭遇流量擁堵消息失實，這位發言人對鈦媒體App回复：“阿里雲在西安一碼通提供的是雲底層設施，沒有參與上層的系統搭建。西安疫情期間，阿里云云平台運行穩定，DNS解析和RDS數據庫產品也並沒有發生故障，我們的技術團隊一直在現場重點保障。阿里雲十分願意為西安抗疫貢獻更多力量。”

“流量過載，飽和式流量衝到網絡防火牆之後，導致流量被攔截，數據請求無法訪問數據庫，市民信息與後台數據庫信息無法比對，最終導致手機端的展示系統無法顯示，也就是癱瘓，這個是可以說得通的。”李冬向鈦媒體App表示。

據鈦媒體App了解，西安“一碼通”的網絡防火牆產品由啟明星辰提供。在一份2020年11月30日發布的“西安市電子政務統一平台網絡安全服務外包項目單一來源採購徵求意見公示”文件中，採購人為西安市大數據資源管理局，中標金額為392萬元人民幣，採用單一採購方式，中標方為啟明星辰。

西安市電子政務統一平台網絡安全服務外包項目合同

問題到這裡並沒有結束。鈦媒體App了解到，網絡防火牆閾值是可以人為調整和設置的，即便一開始在壓測時閾值設置較低，收到報警後可由工程師在後台修改調整，並不需要耗費太長時間。“但是從西安一碼通的故障修復時間看（第一次故障次日修復，第二次故障約兩小時修復），網絡防火牆出現問題只是表象。”李冬分析，深層次原因的排查應該在架構設計是否合理，計算存儲帶寬資源是否充足兩個大的層面，而從以往經驗來看，責任更多在前者。

對此，截至發稿前，鈦媒體App再次聯繫啟明星辰，啟明星辰回復稱，一切以官方信息為準，目前官方信息暫未公佈，同時啟明星辰也否認防火牆本身出現問題。鈦媒體App獲悉，啟明星辰團隊目前在現場積極參與故障的修復。防火牆只是恰好成為故障爆發的弱環，超出設計本身限制。

此外，數字政府項目層層分包（運營商以及大型企業都可以作為總包方，也會互相成為彼此的分包商）也是被外界詬病的一點，這在項目層面屬於正常現象。而在西安“一碼通”項目中，西安電信作為項目總包，負有驗收和把控項目的最終責任。僅西安“一碼通”項目就涉及不下十個分包商，更不要說項目規模更大的城市類項目。如何做好分包商產品與服務質量管理，是總包以及項目主體不可推卸的責任，特別是涉及民生的關鍵基礎設施項目。

當洶湧的疫情成為西安“一碼通”的新預設條件，這場“違背”預設的系統崩潰似乎也不那麼讓人意外了。

現有架構應對高並發，力有未逮

西安“一碼通”的故障與多年前12306春運高峰宕機、雙十一狂歡節淘寶與京東的宕機並無二致。不同在於，12306與淘寶、京東的高並發是商業性的，而西安“一碼通”故障涉及的是民生問題，出現在疫情防控的緊要關頭。

隨著數字化、信息化的推進，各種“碼”被應用在生活中的各個方面。西安“一碼通”這類健康碼和微信、支付寶的支付碼有相似之處，但支付碼卻甚少發生大規模宕機事件，兩者的對比也有一定參考意義。

與健康碼不同，支付碼的投入建設週期長，並且從規劃之初就採用了支持大規模、高並發的分佈式架構，健康碼則更多是在疫情期間緊急上馬，事急從權，例如西安一碼通是在2020年3月到12月數次招標，而在此期間西安一碼通已經投入使用，類似情況在全國范圍內並不少見。

其次，對疫情態勢發展的預估也影響到系統建設。2020年初，社會普遍認為新冠疫情是一次突發事件，並沒有意識到事態會長期持續，自然也不會在一個“臨時系統”上花費重金。相比之下，微信、支付寶的健康碼則是多年來持續迭代、不斷優化，才有了良好的體驗。

“健康碼是非常典型的階段性突擊任務，還是按照傳統的建設方式去管理和推動的。初期確實很正常，但存在著面對大並發場景下的問題隱患。”浪潮軟件副總經理張峰對鈦媒體App表示。

而當相關方重視程度不夠時，健康碼作為一種需要持續資金投入的數字基礎設施，不可能憑空完成系統架構的改進。“就好比平時是一匹馬拉一輛車的貨，當貨變多的時候，要么換一匹更厲害的馬，要么加更多的馬。但只是換匹馬的話，再厲害也不會增加太多的馬力，更合理的做法是增加更多馬。從技術上說，前者是垂直擴展，後者為水平擴展，互聯網公司大多使用可水平擴展的分佈式架構。”張峰舉例。

然而，儘管分佈式架構有諸多好處，但是其所需要的啟動成本和時間也遠多於單體式架構，對資源的消耗和技術的要求也更高，由單體式架構向分佈式機構的重塑也並不容易，所以很多系統都是在原有架構上修修補補，這也是為什麼西安“一碼通”不能在短時間內實現水平擴展，一個月內連續兩次出現故障的原因。

“如果是架構的問題，那麼架構的改動是不能簡單用’優化’來概括的，這是個大工程，雖然不是從零開始，也等於重整。”李冬的分析也印證了張峰的判斷。

綜合來看，西安“一碼通”全套系統的本質問題在於預設前提突變，遠遠超出系統設計的基礎標準，系統架構改造也不足以應對大規模防控場景，從而導致系統中的各個環節危如累卵，最終匯集到防火牆處，造成連續“失碼”。

數字政府再思考

回溯西安一碼通連續兩次崩潰事件，有一點已經很明確，這不僅僅是技術問題。

12月20日，西安“一碼通”第一次發生崩潰，在當日舉行的西安疫情防控記者會上，彼時西安市大數據局局長劉軍錶示，當日早7時40分左右，西安“一碼通”用戶訪問量激增，每秒訪問量達到以往峰值的10倍以上，造成網絡擁塞，致使包括“一碼通”在內的部分應用系統無法正常使用。

1月4日，西安“一碼通”第二次崩潰，時間點也很“巧合”——一位西安市民告訴鈦媒體App，1月4日是西安市社會面清零的時間點，西安全市“拿出最佳狀態發起總攻，攻堅拔寨推進社會面清零”。在這一目標下，當天大批市民需要核酸檢測，而無論是核酸檢測還是外出都要亮碼。“一是疫情嚴重，上班點都要亮碼；二是短時間內全員核酸，大批轉移、大量亮碼導致流量激增。哪怕是分批呢？”在重壓之下，“一碼通”又一次扛不住了。

鈦媒體App聯繫另一位在西安定居多年的市民了解到，第一次故障發生時，西安除了基本處於正常運轉狀態，部分行業尚未歇業，日常進出各類場所需要亮碼，所以“一碼通”故障影響可能較大；但第二次故障時，西安各方都在努力實現社會面清零，大部分行業仍居家辦公，只有特殊人員或需要做核酸人員在外活動，“當天聽到社區大喇叭通知，說’一碼通’故障了，希望大家等系統好了再出門做核酸。但有些居民可能剛好在故障時正在排隊，這些居民可能受到影響。”該市民表示。

然而，在“健康碼”類應用已經在全國各省市普及的情況下，西安“一碼通”短期內兩次崩潰，引起了各界廣泛關注。1月5日，西安大數據資源管理局黨組書記、局長劉軍也因履職不力，被停職檢查。

复盤一碼通故障原因，數字政府、政務雲平台的建設還是要做好頂層設計，對於關鍵基礎設施應該統一規劃、前瞻部署，而不應該草草上馬。“決定係統健壯性差別的關鍵，更在於建設和運營。儘管技術高低可能稍有差別，但不會造成如此不同的差異，數字政府項目支撐城市級別的流量是經過驗證的，健康碼的問題在於重視不足。”張峰對鈦媒體App表示。

從鄭州特大暴雨到西安“一碼通”，這些突發事件背後都反映出維護數字基礎設施穩定意義重大。

“這不是常規解決電子化的問題，而是需要提供工具化來支撐政府以不變應萬變。”一位智慧城市建設從業者對鈦媒體App表示，面對潛在的緊急情況，首先是做好各種應急預案，然而當事態發展超出應急預案所能解決的範疇時，如何在專業信息化支撐部署完成之前，做一些工具化的支撐，實現快速應變，這可能是下一步智慧城市等領域需要著重要考慮的問題。