危情時刻:健康碼如何遠離「崩潰」?

  原標題:危情時刻,健康碼如何遠離「崩潰」?

  記者白楊 北京報導

  1月10日上午,廣東省的粵康碼突然訪問異常,給很多正在上班的人帶來諸多不便。

  事後,粵康碼發佈公告稱,「10日上午8:31,平台監測到粵康碼流量異常增大,最高達每分鐘140萬次,超出承載極限,觸發系統保護機制,導致部分用戶訪問粵康碼緩慢或異常,運行保障團隊緊急處置,於9:04部分緩解,9:56完全恢復順暢運行」。

  一周前,西安一碼通更是在短短半個月內連續兩次崩潰。2021年12月20日早上,西安一碼通出現訪問異常,修復工作持續一整天;2022年1月4日上午,西安一碼通再次崩潰,至中午恢復正常。

  第一次故障,西安官方給出的回復是「每秒訪問量達到以往峰值的10倍以上,造成網路擁塞」,而第二次故障,同樣是因為「訪問量過大」。

  近兩年,隨著疫情防控進入常態化,健康碼已成為人們出行的一個「必需品」。這導致健康碼一旦出現問題,也會給人民群眾的生活帶來較大影響,尤其是像西安,正處於抗擊疫情的關鍵時刻,健康碼的失靈也直接妨礙了防疫工作的開展。

  有了前車之鑒,各地政府亟需思考的一個重要問題是——如何防止健康碼出現崩潰。

  安全與效率的博弈

  不過,行業專家李明告訴21世紀經濟報導記者,如果從技術的角度,健康碼運營支持已經非常成熟,但面對突如其來的訪問壓力,保證百分之百的不出現問題並不現實。

  且不說從理論上,就不存在絕對穩定的系統,從目前健康碼最常見的崩潰原因——流量過載來看,這背後尚存在效率、成本、安全的博弈問題。

  李明表示,一般的系統架構都存在承載閾值,當用戶流量超過這個閾值,系統便會出現崩潰。實際上,這個問題在很多產品中都出現過,比如此前的微博,便多次遇到因某明星突然曝出八卦新聞,用戶量瞬時增加導致產品崩潰。

  很多人會好奇,那為什麼不提高這個閾值,避免出現過載情況?這便涉及到訪問效率和成本的平衡問題。因為提高閾值,需要更多的伺服器,也意味著更多的成本。

  李明透露,以健康碼為例,承載千萬人口的訪問需要的成本大概是千萬級別。假如一個城市健康碼日常的並發量峰值只有10萬,為此卻準備50萬並發量的伺服器,也會造成資源浪費。

  所以在實際操作中,每個城市的健康碼都會根據當地情況,設置一個合理的閾值,至少能保證日常的使用。但這也會留下一個隱患,即當地居民集中大規模使用健康碼時,便會導致用戶流量超出閾值。

  雖然是小機率事件,但這也說明健康碼因為突然的流量增加出現崩潰,也算是一個意料之中的事情。因此,真正要解決的問題應該是,系統出現過載之後,能否快速恢復。

  李明稱,從技術的角度,目前也已經具備了快速應對的能力。其提到了幾個設計原則:

  首先在設計系統架構的時候,要考慮極端情況,比如某城市人口1000萬,那架構設計就至少要考慮到1000萬人可能出現的極端情況。

  在架構之下,要具備彈性伸縮的能力。比如平時只需要使用100台伺服器,在遇到特殊情況時,100台伺服器不夠用了,需要支持快速彈性擴展。這個場景其實也是雲計算的一項核心能力,目前也十分成熟。

  另外,系統也需要做災備。這是確保用戶訪問出現過載且彈性伸縮能力沒有發揮作用的情況下,至少有一套備案可以及時啟用。

  除此之外,像是對系統流程進行解耦,把整個業務過程分割成不同層級,防止流量集中湧入;或者是通過分散式的架構,將流量拆分到不同處理區。這些都能夠有效避免整個系統的崩潰。

  西安一碼通的警示

  所以,健康碼遇到問題並不可怕,只要能快速恢復,便基本能滿足群眾所需。但西安一碼通這次備受關注,一方面是第一次崩潰時間長達一天,另一方面則是短時間內連續出現兩次問題。

  按照上文提到的一些解決方案,西安一碼通在第一次遇到訪問量過載的時候,正常的操作應該是通過彈性伸縮的方式來應對,但一碼通系統最終崩潰,這說明在系統架構上,設計之初沒有充分考慮負載均衡和彈性伸縮的情況。

  據鈦媒體App從一位接近西安「一碼通」項目人士處獲悉,整個故障的大致原因已基本清晰,就是一起因流量過載、系統架構應對高並發不足,最終導致防火牆攔截數據無法返回的系統性故障。

  李明向記者表示,防火牆也有吞吐量的限制,如果流量太大超出吞吐量上限,那防火牆也將無法響應。正常來說,防火牆也應該有負載均衡機制,當一個防火牆無法支撐的時候,就啟用其他防火牆分擔其流量。

  當然,這個背後又涉及到公有雲和私有雲的問題。李明稱,目前整個政務市場都傾向於使用私有雲,如果防火牆是私有雲架構,那災備的防火牆平時即使不用,買來也需要成本,但這個成本往往不能省。

  系統架構無法滿足快速擴容,這也造成西安一碼通遇到高並發的流量時,處理能力變得殭化。至於為何出現這樣的情況,李明認為,這說明整個系統在設計時,就沒有充分考慮到各種可能出現的情況。而且在已經出現全城範圍的疫情防控時,也應該提前做系統的抗壓力測試和演練準備。

  此外,有些地區的健康碼建設的分包情況,也出現了一些不合理的問題。一般而言,作為總包商,核心模塊不應該再分包出去。

  這裏的核心模塊包括整個健康碼的接入、生成、驗碼等關鍵引擎。「當然,至於其他一些簡單的業務模塊,分包出去是沒問題的,幾乎所有健康碼項目,也都存在分包的情況」,李明說。

  對於健康碼項目,李明認為,首先要明確項目的邊界,比如承載的並發量是多大,遇到突發情況能容忍的處理時間是多少;

  其次,要有嚴格的審查機制。整個系統架構要經過認真的審查,並且審查人員應該實行終身負責制,而不是走個形式,導致出現問題不知道找誰;

  然後是在招標執行的時候,要確保投標公司有足夠的能力,這時候不光要看他們承諾的能力,更要看他們做過哪些案例;

  最後是有預警機制,比如當流量達到峰值的一定比例時,就要提前啟動預案。再比如某地突發局部疫情,這時候也要提前採取措施。

  西安一碼通因兩次崩潰而引發的巨大輿論,已給其他地方政府敲響了警鐘。比如北京在近日的防控疫情工作會議上便提出,用好「北京健康寶」,加強壓力測試和系統運行維護,確保正常運行。

  在疫情反覆無常的常態下,我們希望健康碼不要出現任何異常,如果發生了異常,也希望能夠以最快的速度恢復,而不是讓人們等待一天甚至半天那麼久。

  (應採訪者要求,李明為化名)

  (作者:白楊 編輯:張偉賢,盧陶然)

加入好友

台灣疫情資訊

台灣疫苗接種

相關熱門