西安最近因為疫情+出血熱一度備受關注，加之一碼通事件，讓其爭議不斷。
事件回顧：12月20日8點左右，不少人發現西安一碼通無法打開，整整一天，一碼通處於癱瘓狀態，嚴重影響民眾的出行，更鬧出了發誓自己做過核酸才能上班的鬧劇。
后來，官方解釋道：因訪問量過大，導致系統崩潰。
據悉，負責運維一碼通的是西安電信，所以在恢復系統的策略是優先恢復電信用戶，移動和聯通用戶遲遲無法恢復（這種時候還在搞這種小九九）。直至21日上午，系統才恢復正常。
在此，其他不作討論，僅從技術的角度分析這起事件。
下面分析下一碼通事件所犯的技術錯誤
1.壓力測試不充分
對於一個常駐人口千萬級的城市，在疫情嚴峻的大背景下，應該預測到一碼通的並發訪問壓力。在架構設計時，結合實際使用場景，應充分考慮系統的QPS，做好嚴謹的壓力測試，最終輸出可信的壓測報告。
2.容災能力差
對於並發訪問場景的樂觀估計，導致瞬時流量驟增時，系統扛不住壓力崩潰。對此，常規的限流、熔斷、降級等措施，都可以有效的保護系統。反觀一碼通，應急方案欠缺，容災能力有待提升。
3.架構設計的問題
首先，健康碼和核酸證明，不應該做強綁定。不能因為其中一個異常，導致另一個無法訪問。這是產品設計層面的缺陷；
其次，單個用戶的訪問異常，不能無限次的允許其訪問服務，這只會使服務壓力更加雪上加霜；
最后，容錯性差，猜想沒有做分布式集群部署或即使做了但也存在很大的問題；
4.監控不足
任何一個程序軟件都不是完美的，不可能一直穩定運行，我們要承認其可能出錯的事實。比如常見的CPU、內存使用率飆升，很大概率會導致系統崩潰。這時應設置最起碼的閾值，當超過這個閾值時，提前預警，可防止災難的發生。