與其糾結于“背鍋人”是誰，我們更應該把精力放在未來應該如何未雨綢繆，避免類似情況的發生。
所謂“好事不出門，壞事傳千里”，身為一名在京工作的陜西人民，看到自己的家鄉西安最近總是以各種負面姿態出現在熱搜榜上，心里難免不是滋味兒。
疫情的突然爆發讓所有人都猝不及防，在抗疫過程中各種問題也隨之暴露，#一碼通崩了#是目前西安遇到的諸多問題中比較典型、影響面也比較廣的一個，而且短短兩個星期內竟然發生了兩次。
放在以前我們可能很難想象，一個數字化系統的故障竟然可以引起如此大規模的社會混亂。
在一碼通崩潰的當天，大量市民無法乘坐地鐵和出租車，進不了公司和商廈，甚至有家都不能回，一時間怨聲載道——我們同學、同鄉群里各種問候祖宗的“優美陜西話”此起彼伏，讓人不禁感慨中文的“表意豐富”和“博大精深”。
這事兒也引起了領導層的高度重視，這不，據工信部官網4日發布，2021年12月30日至31日，工業和信息化部總工程師韓夏到陜西省通信管理局開展疫情防控工作調研。
工信部官網截圖
韓夏強調，西安“一碼通”要加強技術改進和網絡擴容，確保平臺安全穩定運行。韓夏甚至還專程來到西安“一碼通”工作專班，了解核酸采樣系統應急處置措施，要求系統再優化，細節再完善，確保不出現擁塞宕機現象。
到了5日上午，“西安大數據資源管理局局長被停職”突然曝出，事件再度升級，“一碼通崩了的鍋究竟該由誰來背”的話題也引發了網友們的廣泛議論。
身為一名在京工作家鄉又在陜西的科技圈媒體人，覺得有必要趁此來聊聊這個事兒。
問題出在哪里？
首先，“西安一碼通”為什么會崩？關于問題的原因，目前可謂是眾說紛紜，筆者也咨詢了一些業內專家，在沒有官方詳細的調查報告出來之前，大家給了以下幾種猜測：
第一種可能是網絡堵塞
當“一碼通”系統第一次崩潰的時候，原西安市大數據資源管理局局長劉軍在出席新聞發布會時對此做出回應稱，近日因“一碼通”使用頻率加大，對網絡與平臺造成較大壓力，“12月20日早7:40分左右，西安‘一碼通 ’用戶訪問量激增，每秒訪問量達到以往峰值的10倍以上，造成網絡擁塞，致使包括 ‘一碼通’在內的部分應用系統無法正常使用。經緊急協調資源并采取擴容、限流等應急措施，平臺已逐步恢復使用，但因訪問量仍很大，尚可能有部分卡頓現象。”
然而，對于該回應，部分專家和網友并不完全買賬。網友分析道——西安“一碼通”其實上線已經很長時間了，大部分時候還是很穩定的。西安上班高峰期，也就是掃碼高峰期應該在8點至9點之間，但“一碼通”崩潰是從7點多開始的，當時大部分人都還沒出門，更談不上掃一碼通了。網絡應該不可能在那個時候擁堵，更不可能因為擁堵造成系統崩潰。
某不愿意透露姓名的通信專家則向筆者直截了當地吐槽：“這個和網絡的關系應該不大，大家用的都是4G，難道西安的4G就比其他地方的4G慢？大家平時上網打游戲看視頻都沒有問題，掃個碼網絡就承受不了了？更多的可能是和服務器、計算能力或大數據相關。”
第二種可能是系統不夠健壯
西安電子科技大學網絡與信息安全學院教授楊超則在接受媒體采訪時表示，“一碼通”此次出現長時間、大范圍不能掃碼的情況，可能是系統不夠健壯，同時掃碼人數的激增導致系統的壓力變大了，軟硬件系統負荷大了以后，會出現各種意想不到的問題，不一定是系統本身計算能力不行。”
第三種可能是安全問題
這個從工信部總工韓夏在陜西調研時強調的話中就可以一窺端倪。韓夏表示：“要切實加強網絡和信息安全，優化應急預案，強化安全防護，排查安全隱患，防止出現網絡安全事故，出現問題要及時響應，快速修復。”
物聯網智庫在采訪時，也有多位專家提到了安全問題的可能性。比如，以前電商平臺會經常出現被黑產薅羊毛的情況，類似的情形也會在一碼通亮碼的場景下發生，比如有的用戶手機上安裝了有缺陷的軟件，那該類軟件就會不停重復訪問行為，或者越是亮不了碼，用戶越是不停的重試，如果系統本身沒有安全機制，那就識別不了這種異常訪問。
第四種可能是數據庫和服務器的問題
有來自某IT大廠的專家猜測，可能是反向代理服務器崩了。反向代理服務器位于用戶與目標服務器之間，但是對于用戶而言，反向代理服務器就相當于目標服務器，即用戶直接訪問反向代理服務器就可以獲得目標服務器的資源。同時，用戶不需要知道目標服務器的地址，也無須在用戶端作任何設定。反向代理服務器通常可用來作為Web加速，即使用反向代理作為Web服務器的前置機來降低網絡和服務器的負載，提高訪問效率，反向代理服務器崩了自然系統也就出問題了。
第五種可能是容災和備份機制存在缺陷
所謂“容災”，是指災難發生時，在保證生產系統的數據盡量少丟失的情況下，保持生存系統的業務不間斷地運行。“備份”則是指為防止系統出現操作失誤或系統故障導致數據丟失，而將全系統或部分數據集合從應用主機的硬盤或陣列復制到其它的存儲介質的過程，是數據高可用的最后一道防線，目的是為了系統數據崩潰時能夠恢復數據。
很容易理解，容災和備份其實都是系統未雨綢繆的措施，如果容災和備份機制做得足夠好的話，是完全可以在短時間內恢復到昨天或者前天的狀態的。如果容災和備份機制存在問題，那出了問題就沒有辦法及時得到解決。
從系統反反復復的表現看，西安一碼通雖有一定的備份機制，但是備份機制明顯不夠完善。
誰應該為之“背鍋”？
出了問題的時候，除了分析問題的原因，還有一個大家都很關心的點在于“誰來為此負責”？
為了找到真正的“背鍋俠”，媒體們已經把“西安一碼通”涉及的機構和單位扒了個底兒朝天。
相關資料顯示，該數字化系統由西安市大數據資源管理局牽頭，中國電信西安分公司開發部署，于2020年2月25日在全市范圍內推廣使用。參與西安“一碼通”安全工作的還有啟明、安恒、思安、東軟、阿里云、美林數據等多家公司，從網絡、應用、數據等多個層面為其提供安全防護。
根據公眾號“云頭條”的部分整理：
2020年3月1日，中國電信股份有限公司西安分公司發布《疫情聯控平臺一碼通項目》單一來源采購公示，單一來源采購供應商為“西安東軟系統集成有限公司”。
2020年7月13日，西安電信發布《“一碼通”應用采買短信服務項目》中選人公示，阿里巴巴云計算（北京）有限公司中標。
2021年10月25日，西安電信發布《2021年“一碼通”服務專席熱線業務外包項目》單一來源采購公示，單一來源采購供應商為中通服旗下“陜西省通信服務有限公司中意科技分公司”。
2020年12月10日，西安電信發布《西安“一碼通”安全平臺項目》單一來源采購公示，單一來源采購供應商為“杭州安恒信息技術股份有限公司 ”。
2020年12月10日，西安電信發布《西安“一碼通”大數據可視化分析項目》單一來源采購公示，單一來源采購供應商為“中譯語通科技（陜西）有限公司 ”。
......
網友們對此評論：“哦，我知道原因了，原來是單一來源采購的鍋！”
事情發生后，立即有網友涌到相關企業的官方渠道下方留言詢問。
對此，安恒信息在互動平臺表示，公司在西安一碼通業務中負責部分應用層安全防護及合規產品，以應對可能存在的網絡攻擊和運維風險。自服務一碼通以來，公司長期安排技術人員值守，重點時期進行24小時不間斷的監測和保障，到目前為止，并無黑客攻擊導致業務問題的跡象。
上游新聞記者也曾多次致電西安一碼通的開發公司美林數據以及運營維護公司西安東軟，但兩家公司的聯系電話均處于可以撥通、無人接聽狀態。去年12月20日，西安一碼通首次出現故障之后，記者就撥打了美林數據的公司和西安東軟的公司電話，當時接聽熱線的工作人員對這一事件進行了回應。美林數據的工作人員強調他們僅負責一碼通的后臺和賦碼算法，不負責運營和維護，因此崩潰與他們無關。西安東軟則不愿就一碼通崩潰原因做過多分析。
總結一下大家的回復，“不知道，不清楚，不是我的鍋。”
北京數洋智慧科技有限公司CEO朱瑾鵬則對此表示：“說到責任這個話題，更應該強調每個建設環節、每個參與者都應該有相應的認責機制，才能做到各環節層層把關，層層防護，主動擔當。”
以后如何“未雨綢繆”？
無論是尋找問題的根源，還是找到所謂的責任人，本意都是為了防患未然，避免再次發生。
在北京數洋智慧科技有限公司CEO朱瑾鵬看來，采取一些有效的手段和措施，杜絕類似問題的發生才是關鍵所在，而相關措施則可以分為事前、事中和事后三個方面。
首先，在事前，我們可以通過良好的架構設計、有效的方案預審、評審等方式去避免系統設計缺陷，另外，系統還需要進行充分的壓力與仿真測試。朱瑾鵬表示，“一碼通這個應用雖然數據接口比較復雜，但是業務邏輯并不是很復雜，數據量容易測算，民眾在高峰期間訪問的行為模式也可以通過大數據算法仿真模擬，所以說應該比較容易模擬類似的場景，當前的測試與數據算法技術是完全具備支撐條件的。但從結果來看顯然是當初壓力與仿真測試沒有做好，沒有預料到會出現現在這么一個極端負荷的情況。”
接著，在事中，應通過技術、算法和主動運維手段去實時監控關鍵指標，做到主動監控，甚至主動預警，一旦流量超過閾值或前兆預警指標出現應主動觸發排障機制，通過啟動備用線路、增加處理能力甚至系統降速等手段確保系統不宕機。
最后，在事后，系統遇到故障怎么搶修？從目前看前期預案考慮的不夠完善，技術、管理與運維保障機制準備不足，才會出現搶修慢以及屢次發生的情況
結語
文章的最后，想再強調一下，雖然西安此次應對疫情出現了各種混亂和諸多問題，但也希望大家也能多給這座城市一點兒耐心和信心。
也由衷的祝愿我家鄉的親人和朋友們早日恢復平靜的生活。
西安，加油~
最后的最后，對愿意為本文提供支持的5位業內專家表示由衷的感謝~
參考資料：
1.《西安一碼通，兩個星期兩次崩潰，這到底為了什么？》，鋒利傳媒法治視野
2.《不堪重負！西安“一碼通”半個月內再次故障，細數崩潰的N種可能》，智領云科技
3.《#西安一碼通#又崩了。。。誰之責 ？》，云頭條
4.《西安“一碼通”系統崩潰背后：多家公司為其提供安全防護》，紅星新聞
