第一財經注意到，相對於千萬級的常住人口數量，這些系統承載的每分鐘的訪問量在百萬級別。隨着疫情反覆，頻頻崩潰的數據平台系統引起了人們的注意。“我早上6點就起來了，6點半去排隊，7點開始測，7點20就完事兒啦！”天津市民劉先生大清早就按照要求參加了核酸檢測，等到他看到了微信群里有朋友在抱怨核酸檢測系統的崩潰時，才覺得10日的早起，值了！
微信記錄顯示，有天津市民在10日10：40左右抱怨在快要排到時因核酸檢測系統崩潰不得不暫緩檢測，等到11：30時系統才重新恢復。“白排了嗎？”劉先生問朋友，對方回答沒有，因為喊了家人“輪流替會兒”。
官方系統為何如此“脆弱”？
各地大數據系統投入不少，除了最近天津的核酸檢測系統出現崩潰情況之外，還屬健康碼最為常用，“崩潰”率也最高。
2021年，山東、西安、天津等地都先後出現過故障。事後披露的原因多為當日最高查詢峰值激增導致系統阻塞。比如山東去年8月份當日最高查詢峰值達60.96萬人次/分鐘，同前一工作日相比激增8倍，是去年最高峰值的2.5倍，西安“一碼通”用戶訪問量激增時出現每秒訪問量達到以往峰值的10倍以上，而粵康碼流量異常增大時最高達每分鐘140萬次，超出承載極限，觸發系統保護機制。
第一財經注意到，相對於千萬級的常住人口數量，這些系統承載的每分鐘的訪問量在百萬級別。
“傳統的做法通常會分為兩類，一是整合多方數據后，以統一的數據資源平檯面向政府體系提供服務為主，另一類是部署兩套系統分別應對政府內部服務和面向居民的服務體系。前者的架構在面對居民高併發的應用場景時容易遇到瓶頸；後者則可能會對數據資源進行重複建設。”一位業內人士告訴第一財經，這些系統的構建涉及基礎資源層、網絡層、應用層多個專業廠商，出現問題的表徵一定是訪問崩潰，但背後原因未必相同，因此不好對已經出現崩潰情況的系統做出評價。
目前，各健康碼、核酸檢測系統的運營公司大多是經由當地的大數據中心招投標建設而成，從股東方也可一窺技術提供方。比如“粵康碼”由數字廣東網絡建設有限公司負責開發及技術維護，背後的股東包括中國電子、三大運營商和騰訊。西安的一碼通由西安市大數據資源管理局牽頭，中國電信西安分公司開發部署。記者曾聯繫了多家與健康數據平台或當地大數據中心有業務往來的技術供應方，但都得到了謝絕採訪的回復。
不過，記者了解到，通常這樣的系統會採用分佈式大數據技術，結合所在地的人口情況、上下班出現的訪問高峰設計出相應的系統容量和冗餘量。“健康碼的賦碼業務邏輯需要根據運營商手機相關數據、公安人口相關數據、衛健委人員健康狀態等數據進行離線加工融合，並通過實時對接健康雲等用戶註冊信息融合加工達到秒級別的生產數據以快速控制風險。所以團隊確定使用大數據分析和實時流處理引擎對這一業務場景進行技術支撐。”一位參與過某地健康碼系統搭建的相關人士介紹稱。
此外，還要對系統各環節下的全鏈路全方位測壓，以保證系統上線足夠高的可靠性和穩定性。
應急層面上看，系統要有足夠的彈性伸縮能力。在訪問出現激增的特殊情況時，能夠快速擴容，滿足相應的訪問需求，比如進行容器化的設計保證底層基礎設施具備良好的彈性伸縮能力。
除去訪問容量冗餘角度上的考慮，還要考慮對於整體系統層面的全流程監控設計，如網絡訪問情況，健康碼接口訪問統計，日峰值出現時段等指標。這不僅為實時大屏提供了相應的數據指標支撐，同時也為團隊驗證系統容量設計，監控保障系統穩定運行，以及後續實現資源動態擴縮容提供了決策依據。
即便考慮再周全，這世上當然沒有完美無缺的系統，特別是在計算資源本身就是有限的情況下。業內人士提到需要配套合理的開發流程和運營管理流程來有效的支撐軟件系統的持續升級和健康運行。比如在總體系統設計上，針對關鍵軟件服務和數據配備應急資源和環境進行分級。平時這部分資源可用於一些創新業務或非關鍵性業務，一旦有臨時性的業務需求如全員核酸時，可以及時將這部分應急資源用於業務擴容來支撐。
這有些類似於12306系統將訂票和查詢余票業務分開，在各個子系統按需進行擴縮容的設計，同樣，也不建議在關鍵高併發的健康碼查詢路徑上關聯過多的非關鍵業務，不同業務採用微服務等新型軟件開發方式來開發，結合容器雲等技術來實現動態的按需擴縮容，同時保證各個業務之間不互相影響，如上傳核酸報告、查詢核算報告、查詢健康碼等業務要分開。
“在某些關鍵業務失靈后能夠快速地從備份系統恢複數據並支持業務重新上線，這樣即使某個業務短暫出現問題，我們可以通過災備系統來快速恢復業務和數據，這樣老百姓的等待時間可以從一天縮減到幾分鐘。”這位業內人士說。