9月初成都核酸檢測系統崩潰把背後的廠商東軟擠上熱搜，作為疫情兩年多來每個民眾習以為常的國民軟體，各地的健康碼和核酸系統卻頻頻出現問題。通過關鍵詞檢索發現，包括杭州、天津、山東、成都、澳門、上海、西安、廣東在內的多個省市均報導出健康碼或核酸系統出現無法打開、系統崩潰、卡頓等現象。數據猿大致梳理了幾次影響較大的各地疫情軟體故障事件如下。
可以看到，對於各地疫情軟體故障後的問責情況，數據猿也只發現西安對於相關官員進行了問責，而對於技術廠商的責任則因複雜的技術原因抑或是預算等原因少有見公開問責的報導。
雖然各地供應商不一，但故障出現的時候大多與訪問量增加有關，核酸系統的業務場景並不複雜，系統崩潰的原因幾乎都是因為「並發量太大」 。以今年9月初成都核酸系統崩潰事件為例，雖然東軟集團的聲明中說是網絡原因，但四川信管局立馬對網絡覆蓋良好沒有故障進行了回復。
據專業人士分析，該次系統崩潰可能是因為核酸的NG負載均衡不支持彈性擴容，難以應對系統高並發。簡而言之，就像「路窄車道少不限流」的高速路，一旦大量車流同時湧入將導致全線擁堵甚至停滯。目前，業內對核酸系統崩潰的可能性誘因分析，大多也集中在伺服器、資料庫、壓力測試等IT架構設計與運維方面。
對於本次因為成都疫情深陷輿論漩渦的東軟，根據其微信公眾號顯示，東軟全場景疫情病原體檢測信息系統是東軟於2020年12月開發，新冠疫情爆發以來，東軟核酸檢測系統已在國內17個省120多個地市部署應用，包括北京、上海、重慶、天津等人口超大型城市，已累計檢測超過140億人次。但東軟並不是第一次出現類似事件，如上表所示，今年1月份，西安「一碼通」就曾發生故障，市民在每日例行核酸檢測過程中，遭遇了無法打開個人健康碼的情況。而西安「一碼通」背後的主要承接方中就包括東軟集團。
核酸系統崩潰的「鍋」，東軟甩不掉
外行看熱鬧，內行看門道。我們需要透過一次次的事故，來看到導致事故的內部原因。只有這樣，問題才能得到真正的解決。那麼，究竟「健康寶」崩了的原因是什麼呢？誰又該為「健康寶」的「崩潰」承擔責任……
想要弄清這些問題，必須要回歸到「健康寶」的「誕生」流程上。一般來說，政府部門不會直接參與研發，而是通過招投標的形式，承包給符合條件的企業進行研發和後期的技術維護，系統的運營方面一般由政府部門或者政府委託的政府平台負責系統投入後的運營和管理工作。
從系統研發的角度來看，「健康寶」的整個工作原理可以簡化為三個部分：
首先是信息採集。在第一次打開小程序時，用戶均需要填寫自己的個人信息，包括姓名、身份證號、住址等；
其次是信息審核。在提交信息資料後，系統會快速的根據填寫的個人信息，與背後的資料庫進行交叉驗證，從而確定個人信息的真實性和健康風險級別。在審核過程中，個人信息資料至少要跟三套大數據系統進行驗證：一是衛健委的數據，主要是確定健康信息；二是公安部門的數據，主要是確定戶籍狀況和社會關係；三是運營商的數據，主要是確定用戶的活動軌跡。
最後是「健康碼」動態管理。也就是根據「健康碼」的動態管理規則，最後系統「賦碼」。
看上去整個過程很簡單，但用的人多了，並沒有讓它更「智能」，反而經常「崩了」。作為一個系統化的產品，「崩了」這事非常常見，就像女孩子經常說「身體不舒服」一樣，背後的原因可能五花八門。
儘管原因複雜，我們仍然可以把這些問題歸結為三類：第一類是硬體問題，比如：訪問量過大導致伺服器癱瘓、網絡帶寬性能不足等，都屬於硬體問題；第二類是軟體問題，比如設計缺陷的問題等；第三類是管理問題，比如：後台運營等。管理方面的問題相對比較複雜，既有直接管理的問題，也有間接管理的問題。不同類型的問題，責任劃分的依據也有所區別。
先說硬體方面的問題。其實硬體方面的問題就是兩類：一是硬體的質量是否合格，二是硬體的數量是否與需求匹配。前者出現問題由生產廠商和鑑定機構承擔責任，後者出現問題則是採購方的決策者承擔責任。
再說軟體方面的問題。軟體方面的問題更多的與軟體開發方有直接關係，一旦判定是軟體本身的問題，開發方肯定難辭其咎。當然，有些情況下也不能僅僅追究開發方的責任，畢竟軟體的開發多數是基於硬體設備，有可能某些潛在的問題在開發階段曾向甲方領導層作出過提醒，但是沒有被重視，在這種情況下，如果後續的運營中出現問題，甲方領導層也需要承擔相應責任。
最後說管理方面。管理方面的問題有兩層，一層是項目投入使用過程中的運營維護，如果出現相關問題，一般是要追究相關人員的責任，另一層是相關人員上級領導的責任，主要是基於「誰領導誰負責」的原則。
基於上述的責任認定框架，我們不妨分析近期的成都核酸系統崩潰事件中，供應商東軟集團究竟該不該承擔責任。
成都市要求從9月1日至4日，在全市範圍內開展全員核酸檢測，核酸檢測系統在9月1日、2日、3日接連出現異常，系統出現響應延遲、卡頓等現象，由此導致採樣排隊時間過長，核酸檢測進度緩慢，部分居民在雨中「罰站」。事後，成都核酸檢測系統的供應商——東軟集團被罵上熱搜，而東軟集團發布聲明，「東軟的核酸檢測系統屬於應用軟體，其能否順暢運行與核酸碼等相關應用系統、後台的伺服器、算力、網絡帶寬、甚至防火牆配置等因素都緊密相關，而這些系統並非由東軟提供，當快速部署、切換時，初期往往會面臨協調穩定問題。」然而，聲明發布沒多久，四川省通信管理局發文回應稱，「相關部門全力做好『四川天府健康通』、核酸檢測等重點涉疫系統網絡保障，全市通信網絡運行平穩，各核酸檢測點行動網路覆蓋良好，沒有出現網絡擁塞和故障。」
故障發生了，東軟急忙撇清關係，究竟是誰的責任？我們不妨按照上面的分析框架來梳理推測一下。
在核酸檢測系統出現故障的同時，成都的網友仍然可以刷微博、玩抖音、觀看線上演唱會，由此可見4G/5G網絡沒問題，完全暢通。同樣是應用軟體，別人家的可以連上網，而核酸檢測系統卻不可以，要說不是系統的問題還真是「見鬼」了。
再進一步分析，在全員核酸檢測時，核酸檢測系統主要的應用單位是成都市的各個核酸檢測點以及其他疫情防控服務部門，工作內容主要是通過系統做簡單的錄入信息、上傳信息等工作。根據成都市公布的全市核酸檢測點的數量發現，截止到8月31日，成都市共有2565處核酸檢測點，我們做一個簡單的測算，在全員靜默管理期間進行全員核酸檢測，這2565處核酸檢測點同時工作，則核酸檢測系統的並發也就每秒2565左右，在2022年的今天，這放在IT系統來說壓力不算大。
最後我們再分析一下核酸檢測系統。目前並沒有公開資料找到成都市核酸檢測系統的產品架構，但是我們在東軟集團的官方網站上找到了類似產品的架構，如下圖所示。根據該產品的架構和描述，我們推測，各地部署的東軟核酸檢測系統應該是在此產品的基礎上略微做了調整。
通過官網的介紹來看，東軟集團智慧疫情防控全場景解決方案主要運用的是大數據的採集、清理、整合和交換等技術，即便是遇到了高流量、高並發的緊急情況，正常來說是可以通過增加服務節點並將新節點加入原服務集群的方式，實現快速擴容。但是根據結果來看，顯然其提供的核酸檢測系統在技術上並沒有達到。因此，只能說東軟集團的聲明有些「自欺欺人」了。
在上述的一番推理之後，再來做責任的認定其實就比較清楚了，大概率是因為東軟的軟體設計問題導致了後續問題的發生，而且在9月2日凌晨，東軟的全場景疫情病原體檢測信息系統緊急上線並首次投入使用，新系統的上線難免會出現穩定性問題。所以，如果一定要追究責任的話，東軟集團「無處可躲」。
總體來說，前期隨著各地「健康寶」系統的不斷升級，崩潰的次數和趨勢確是在減少，但是並不意味著類似事件不會再發生。為了減少此類事件的頻繁發生，運營部門仍然需要在以下兩方面做出努力。
在外部系統方面，需要嚴格檢查外部服務提供商的能力和水平，一定要仔細檢查他們的工作；其次，確保所有數據都安全備份；第三，確保選擇合適的資料庫部署方式和策略，高度敏感的數據不適合存儲在公有雲解決方案中。
在內部運營方面，不斷監視資料庫運行狀況，尤其是資料庫錯誤的情況下，確保業務平穩運行；其次，在運營人員方面，提升管理人員的戰略思維，培養快速、流暢的應對突發狀況的能力。
只有在軟體、硬體和管理方面同時提升和維護，才能保證「健康寶」安全、穩定的運營和服務疫情防控。
不崩只是底線，數據跨省打通也是剛需
除了頻繁崩潰外，各地「健康寶」系統和數據不能打通，導致健康碼各地不能互認，給用戶帶來麻煩的同時，也給疫情流調帶來困難，這個問題究竟如何解？
這個問題其實難點不多，但解決起來比較費勁。首先，「健康寶」系統需要的數據包括：個人信息數據、醫療狀況數據、行程軌跡數據。個人信息數據在公安部門的系統中，醫療狀況的數據在衛健委部門的系統中，個人行程軌跡的數據在運營商的系統中，這三個數據中，衛健委部門的數據相對複雜一點，因為各地衛生健康部門的數據並沒有完全打通，在數位化推進的過程中，地方政府選擇合作的供應商、政府系統並不相同，而且出於對當地居民數據安全和隱私的考慮，這些數據基本存儲在各自的私有雲中，所以一朵朵「政府雲」之間短時間難以打通。
不過，雖然短時間內難以實現全國「一碼通」，但「一省一碼」已經全部實現。在9月初國家衛健委召開的新聞發布會上，國家衛健委規劃司司長毛群安宣布全國所有省份實現了「一省一碼」，而且後續也會繼續推進健康碼互認。其實，不少省市也開始逐步的拓展核酸檢測結果的異地互認，比如北京健康寶在7月30日開始，就可以實現查詢外省市核酸檢測結果，並上傳至北京健康寶。
不積跬步無以至千里，雖然這小小的一步看似輕巧簡單，可背後的努力值得肯定，未來的全國「一碼通」值得期待。