導讀｜隨著疫情防控模式的迭代，健康碼訪問DAU逐漸趨於下跌，意味著健康碼將逐步完成歷史使命，見證著疫情的結束。本文特邀騰訊研發工程師李雄政將從技術架構、可觀測體系、運營保障體系等運維體系多方面，總結回顧健康碼業務運營過程中的保障技術手段。

業務背景

疫情三年，奧密克戎已是強弩之末，疫情終將過去。歷經數個階段的迭代，騰訊健康碼產品服務於十餘個省份的居民，數億使用者、數百億次亮碼。有效助力保障公共衛生安全。全國健康碼共累計PV2k多億，亮碼1k多億，最大省份的健康碼使用者量超過1億，DAU過千萬。

隨著疫情防控模式的迭代，健康碼訪問DAU逐漸趨於下跌，意味著健康碼將逐步完成歷史使命，淡出歷史舞臺。本文就曾經在健康碼業務運營過程中的保障技術手段進行了回顧，歡迎有興趣的讀者在評論區一起探討。

技術架構體系

一個穩定的架構是設計與運維出來的，為了達到穩態執行，設計上考慮了以下幾個方面：

1）選用合適的雲原生產品

健康碼本身是要求高可用、高併發的應用，為了滿足業務穩定上線、快速上線的需求，我們採用了騰訊雲的公有云/私有化產品解決方案。以下是健康碼上線時碰到的幾大類問題：

• 頻寬容量問題

由於系統需要大容量的承載能力，導致地方政務雲資源供給能力不足。表現如公網出口防護能力不足（如經常性面對境外DDOS攻擊/CC攻擊），IDC出口裝置每秒新建連線數不夠等。我們採用了DDoS高防包/waf/ecdn等方案來滿足。DDoS高防包與Waf產品有效抵擋住境內外的DDoS攻擊、Web攻擊、入侵、漏洞利用、掛馬、篡改、後門、爬蟲等網站及 Web 業務安全防護問題；ECDN產品透過靜態資源快取有效降低混合雲場景下政務雲入口新建連線數、頻寬。也提升了使用者的訪問體驗。

1. 開發及部署效率問題

疫情的需求迭代較快，如果從頭開始開發產品，時間上不允許。騰訊雲TCB產品做為一站式雲原生解決方案，更加貼近小程式/Web 應用開發場景，使開發人員能快速構建完整專案、針對場景快速最佳化定製且集中管理，各產品間無需耗費時間精力分別配置與打通，無需切換多款雲產品的控制檯進行使用。

• 雲資源成本問題
  

雲產品擁有較大的共享資源冗餘，能夠快速達成大容量，同時深度採用雲原生產品，能夠帶來較大程度的成本節約。例如採用scf雲函式，無需在購買雲伺服器的情況下執行程式碼，使用騰訊雲的能力彈性、安全地執行程式碼。無需冗餘資源閒時執行成本買單，同時因為雲原生產品具有天然的跨可用區容災能力，基於雲原生的兩地三中心架構設計，基於騰訊雲公有云通常可以滿足的高可用能力如：從負載層採用CLB的跨可用區高可用能力進行可用區容錯；應用層TSF/TKE/CKAFKA的多可用區高可用能力容錯；儲存層採用TDSQL多可用區部署及主從同步能力滿足高可用與容災。

2）立體化監控體系設計

完整的監控體系，對提升系統SLA有非常重要的作用。一方面監控系統具有提前業務事件預警能力。最有效的監控體系能在業務發生故障前有效預警，從而知會SRE提前介入處置，防止事件擴大成故障，從而降低高故障數量。另一方面在發生故障後，能夠評估故障影響程度、有效追蹤異常點，引導技術人員介入處置，提升系統故障恢復SLA。

3）系統壓力測試、混沌工程、應急預案等多方面檢驗

隨著業務系統逐漸趨於成熟，要保障常規執行過程中的穩定性， 需要週期性保持對系統的應急演練工作。一方面透過壓力測試、破懷性測試來檢驗系統的承受能力。另一方面透過這些演練來檢驗運維人員團隊在面對業務事件時的響應質量、處置預案是否成熟與合規。

可觀測體系

可觀測能力做為基礎技術能力，在健康碼運維中是不可缺少的一部分。優秀的可觀測體系能夠幫助業務及時、準確地發現故障，亦能在故障診斷過程中追根溯源，及時協助問題定位、從而加速故障恢復。

健康碼產品基於騰訊雲PAAS產品構建，系統的可觀測點一般可基於以下能力構建：首先，採用了騰訊雲waf/ 騰訊智慧閘道器/騰訊雲tke等做為基礎元件。這些元件都能夠輸出標準化日誌，我們對日誌進行清洗、匯聚，從而可獲得各種可觀測的metrics。其次，前端埋點。有助於監控前端使用者體驗，發現資源載入慢、API介面超時、成功率低等問題。最後，元件自身的監控系統，採用公有云API、 telegraf input、 prometheus exporter等方式對元件自身的健康情況做好監控。

1）基礎元件可觀測

對於基礎元件來說，我們需要知道各元件的執行狀態、容量效能情況等。基礎元件可觀測選型較多，相對私有云來說，公有云具有較好的可觀測生態。以騰訊云為例，公有云除了提供較好的dashboard 與告警能力外， 基於API V3構建的開源生態亦比較豐富，可使用grafana plugin 和prometheus qcloud exporter進行觀測，方便與prometheus / grafana 進行整合對接。

需要特別說明的是由於原生監控指標較少，伺服器數量較多時，監控原生api可能無法滿足高額拉取頻率要求，我們可以採用開源手段進行監控，比如自行部署 node exporter， 由prometheus 自行抓取與監控。

2）業務指標可觀測

根據業務指標的重要程度，我們會針對關鍵指標如亮碼、核酸、疫苗介面相關業務指標進行觀測。對各種介面監控好，我們就可以有效保障系統整體質量，監控的指標包括各介面業務量、成功率、平均耗時、95分位耗時等。

• 業務量監控

從Log中分解出相應的URL，分時間/URL  Count 數量即可獲得業務量 metrics, 業務量的監控有閾值監控、同環比、動態閾值監控等。

• 成功率監控

成功率表示的是成功請求量佔總請求量百分比，從Log中很容易區分出異常返回碼，從而計算出成功率。一般採用閾值監控 。

• 耗時監控

耗時監控表示的是業務整體耗時，每一筆耗時在日誌中均有記載，可採用平均值或p95耗時監控，一般採用閾值、無閾值監控等方法進行監控。

常用的日誌處理手段有ElasticSearch / 騰訊雲CLS等。

3）使用者體驗可觀測

• 前端監控

我們在健康碼專案中使用的監控工具是騰訊雲RUM監控（Real User Monitoring), RUM監控的便捷之處在於對業務程式碼的侵入性較少，只需新增數行程式碼。能夠監控到前端JS錯誤、白屏、首屏開啟速度、API成功率、API耗時等。

import Aegis from 'aegis-mp-sdk';


const aegis = new Aegis({
  id: "pGUVFTCZyewxxxxx", // 專案key
  uin: 'xxx', // 使用者唯一 ID（可選）
  reportApiSpeed: true, // 介面測速
  spa: true, // 頁面切換的時候上報 pv
});

程式碼示例：RUM監控接入方法及為簡單方便。

上圖是前端監控資料總覽檢視，有助SRE第一時間瞭解整體使用者體驗資料。

上圖是某健康碼業務前端呼叫後端API成功率。

API監控功能有助於SRE瞭解後端API效能，在後端成功率、耗時（如95分位，平均耗時）有波動時，可以有效下鑽分析並聯合後端進行排查。由於健康碼內部引用了大量的外部介面，在實際應用中，我們通常採用此方法第一時間發現第三方系統介面耗時波動，並及時聯絡第三方介面後端進行處理。

上圖是某健康碼業務前端錯誤。該檢視有助於SRE第一時間瞭解整體前端錯誤資料，並有針對性對業務前後端應用進行最佳化。

• 使用者反饋監控

在業務出現問題時，微信投訴入口或微博等媒體一般會有投訴產生，一旦產生某些關健字彙聚，可以及時介入處理，防止事態擴大化。

4）業務撥測

我們可以模擬業務請求向業務後端介面發起撥測。撥測失敗（無法連線、響應超時、錯誤返回碼）可發出告警，這種探測手段也比較有效。騰訊雲的撥測功能能有效從全球發起撥測請求，並生成撥測結果報表。

上圖是全國健康碼質量撥測質量檢視。

我們也可能在系統內部建立起對第三方介面的撥測，達到自證清白的效果。低成本的撥測解決方案有 blackbox exporter等。

上圖是某健康碼業務的第三方介面撥測，有助於自證清白。

容量壓測

疫情往往會瞬時帶來比平日峰值數倍甚至數十倍的亮碼業務量，增長幅度較大，運維團隊一般無法即時進行擴容，所以在疫情增長趨勢較為明顯時，我們會預估業務量，並與業主溝通進行擴容，擴容後完成效能壓測。

1）讀介面壓測

我們會從系統隨機抽取一部分使用者，向系統模擬數十倍峰值請求來進行壓力測試。壓測的同時向第三方介面報備壓測流量，以免造成第三方系統損壞。

2）寫介面壓測

寫介面涉及到資料寫入到生產環境，所以一般採用兩種形式進行壓測。一種是標記資料壓測、比如採用一些模擬使用者ID 號段的使用者生成清求，壓測完成後採用刪除壓測資料的方式進行清髒。另一種是壓測請求http頭內攜帶壓測標記，業務程式碼內對壓測請求特殊處理，旁路插入測試庫。

騰訊雲壓測團隊提供了一系列的壓測工具及服務，有效助力每個健康碼業務疫情期容量保障。

3）壓測排障

壓測過程中碰到瓶頸常見於：單核跑滿——存在於某些應用使用單核的情況，一般需要做業務改造，使系統執行在多核；負載過高——如CPU過高，虛擬機器包量超 10W等；防火牆等數通鏈路故障——防火牆可能會存在頻寬限制、新建會話數限制等 （不限於網際網路出口防火牆、區域間防火牆）；PAAS能力限制——如redis單機版單核跑滿，連線數跑滿等；第三方介面延時過高——如第三方介面不能承壓等情況；某些私有云存在大量CPU超分。在壓測過程中發現並解決能力短板，從而使系統能達到理想的容量。

混沌工程與故障演練

上圖是健康碼混沌工程實踐。每個健康碼從新上線到成熟，產品與運維團隊都經歷了組建至成熟的過程，透過故障演練，團隊能快速找到產品架構薄弱點、組織效率瓶頸點，演習完成後可有針對性對演習中發現的問題進行最佳化，經歷過多次演習，架構高可用能力與組織效率均能有所提高。

1）檢驗服務的高可用性，如架構無單點，具備健康檢查、負載均衡等能力

透過關機、網路卡禁用、例項調整等手段模擬故障，檢驗在IaaS/PaaS出現故障時，業務是否會受到影響，業務能否自動切換，後端業務能否自動止損熔斷等。

2）檢驗監控覆蓋度和有效性，如基礎監控、業務指標監控的覆蓋度和告警有效性

透過關機、網路卡禁用、例項調整等手段模擬故障，檢驗基礎監控手段能否及時發現問題，業務監控手段能否及時發現業務抖動，告警能否觸達到相關的運維人員。

3）檢驗應急預案的有效性，如擴縮容預案，限流預案等

以壓力測試為輔助，檢驗壓力條件下，能否快速成功擴充容量，能否快速啟動對業務限流。

4）提前發現服務穩定性隱患並推動消除隱患，建立故障快速發現和快速止損的能力

在某些特定的業務耗時增加、錯誤率增加時，能夠快速啟動預案介入，快速恢復業務成功率及耗時。

業務架構最佳化與業務柔性

優秀的架構需要具有自保護能力與對後端應用的保護能力。常見的保護能力如：

某些高併發寫請求入庫前增加佇列以增加瞬時吞吐能力。如高峰期掃場所碼，掃場所碼資訊入庫實時性要求並不強，採用騰訊雲ckafka等元件進行業務削峰。

在應用加入適當時長（如：5分鐘）的快取，使用者短時間呼叫該資料時走快取，以減少對後端、第三方介面的請求。該快取可以加在前端（如Localstorage）或 後端（採用redis或hash到有狀態服務的本地記憶體）。

在後端或第三方介面故障時，由於使用者會不斷重試而瞬時增加大量請求，甚至導致後端雪崩，這時就有必要在前端增加限制重試的邏輯。比如有些小程式設計在使用者請求出錯後，會要求使用者重登陸， 但如果對該登陸請求沒有限制，必然會導致請求量過大而後臺雪崩。我們建議在前端加上限頻措施。以下是常見的前端設計：

後端在閘道器等層面限流，只允許承載能力內的請求進行後端。透過壓測對系統承載能力摸底，從而在接入閘道器進行限流。我們採用騰訊雲智慧閘道器（騰訊雲公有云API閘道器有同樣的能力）限流。可以對後臺起到相應的保護作用。

第三方介面耗時太長，產生大量TCP連線而耗盡系統資源，此時會要求後端具有快速失敗的能力，不再長時間等待第三方介面返回。

上圖是健康碼系統分層部署及各層對後端的保護能力。以上保護手段在每個專案中的實現策略均有所差異。因為涉及到使用者體驗，需要與業主充分討論後執行。

變更控制

業務上線後，需要持續保持業務穩定執行，變更控制尤其重要，現網變更均需要提出變更請求，每一個變更請求需要進行技術嚴格評審後，經客戶、管理授權後方能在現網實施。

我們特別使用騰訊雲coding承載變更工作流，變更工作在平臺中實現閉環。一個合格的變更請求至少要包含變更目的、實施過程、驗證方案、回退方案等。ITIL 的 change management中均有規範，此處不再詳述。變更時儘量遵循灰度釋出，防止變更中產生較大影響面的問題。

以上是從技術架構、可觀測體系、運營保障體系等運維體系各方面總結出來的、保障健康碼過程中的心得，希望能給大家一些借鑑和參考。整體來說，技術架構上，基礎資源儘量採用雲原生產品，滿足大容量、可伸縮、高可用的基礎資源能力。可觀測體系上，要採用雲原生產品構建業務前端、後端一體化觀測體系，保障業務可用性。運營保障體系上，好的系統運維是設計出來的， 一方面加強業務技術架構設計，可層可對後端提供保護，透過限流、邏輯熔斷等手段使業務架構具有容錯能力；另一方面平時要不斷透過混沌工程演習手段，檢驗系統容量及高可用能力，保障團隊能夠及時響應，專業響應。

當然我們碰到的業務場景有限，為了滿足業務快速上線，歷史上所採用的的一些技術實踐也不一定是最優的。當前雲產品發展日新月異，已經產生了更好的產品解決方案，期待大家在評論區一起發掘討論。