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

業(yè)務背景

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

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

技術架構體系

一個穩(wěn)定的架構是設計與運維出來的，為了達到穩(wěn)態(tài)運行，設計上考慮了以下幾個方面：

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

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

• 帶寬容量問題

由于系統(tǒng)需要大容量的承載能力，導致地方政務云資源供給能力不足。表現(xiàn)如公網出口防護能力不足（如經常性面對境外DDOS攻擊/CC攻擊），IDC出口設備每秒新建連接數(shù)不夠等。我們采用了DDoS高防包/Waf/ecdn等方案來滿足。DDoS高防包與Waf產品有效抵擋住境內外的DDoS攻擊、Web攻擊、入侵、漏洞利用、掛馬、篡改、后門、爬蟲等網站及 Web 業(yè)務安全防護問題；ECDN產品通過靜態(tài)資源緩存有效降低混合云場景下政務云入口新建連接數(shù)、帶寬。也提升了用戶的訪問體驗。

2. 開發(fā)及部署效率問題

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

• 云資源成本問題

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

2）立體化監(jiān)控體系設計

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

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

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

可觀測體系

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

健康碼產品基于騰訊云PAAS產品構建，系統(tǒng)的可觀測點一般可基于以下能力構建：首先，采用了騰訊云waf/ 騰訊智能網關/騰訊云tke等做為基礎組件。這些組件都能夠輸出標準化日志，我們對日志進行清洗、匯聚，從而可獲得各種可觀測的metrics。其次，前端埋點。有助于監(jiān)控前端用戶體驗，發(fā)現(xiàn)資源加載慢、API接口超時、成功率低等問題。最后，組件自身的監(jiān)控系統(tǒng)，采用公有云API、 telegraf input、 prometheus exporter等方式對組件自身的健康情況做好監(jiān)控。

1）基礎組件可觀測

對于基礎組件來說，我們需要知道各組件的運行狀態(tài)、容量性能情況等?；A組件可觀測選型較多，相對私有云來說，公有云具有較好的可觀測生態(tài)。以騰訊云為例，公有云除了提供較好的dashboard 與告警能力外， 基于API V3構建的開源生態(tài)亦比較豐富，可使用grafana plugin 和prometheus qcloud exporter進行觀測，方便與prometheus / grafana 進行集成對接。

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

2）業(yè)務指標可觀測

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

• 業(yè)務量監(jiān)控

從Log中分解出相應的URL，分時間/URL Count 數(shù)量即可獲得業(yè)務量 metrics, 業(yè)務量的監(jiān)控有閾值監(jiān)控、同環(huán)比、動態(tài)閾值監(jiān)控等。

• 成功率監(jiān)控

成功率表示的是成功請求量占總請求量百分比，從Log中很容易區(qū)分出異常返回碼，從而計算出成功率。一般采用閾值監(jiān)控 。

• 耗時監(jiān)控

耗時監(jiān)控表示的是業(yè)務整體耗時，每一筆耗時在日志中均有記載，可采用平均值或p95耗時監(jiān)控，一般采用閾值、無閾值監(jiān)控等方法進行監(jiān)控。

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

3）用戶體驗可觀測

• 前端監(jiān)控

我們在健康碼項目中使用的監(jiān)控工具是騰訊云RUM監(jiān)控（Real User Monitoring), RUM監(jiān)控的便捷之處在于對業(yè)務代碼的侵入性較少，只需新增數(shù)行代碼。能夠監(jiān)控到前端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監(jiān)控接入方法及為簡單方便。

上圖是前端監(jiān)控數(shù)據總覽視圖，有助SRE第一時間了解整體用戶體驗數(shù)據。

上圖是某健康碼業(yè)務前端調用后端API成功率。

API監(jiān)控功能有助于SRE了解后端API性能，在后端成功率、耗時（如95分位，平均耗時）有波動時，可以有效下鉆分析并聯(lián)合后端進行排查。由于健康碼內部引用了大量的外部接口，在實際應用中，我們通常采用此方法第一時間發(fā)現(xiàn)第三方系統(tǒng)接口耗時波動，并及時聯(lián)系第三方接口后端進行處理。

上圖是某健康碼業(yè)務前端錯誤。該視圖有助于SRE第一時間了解整體前端錯誤數(shù)據，并有針對性對業(yè)務前后端應用進行優(yōu)化。

• 用戶反饋監(jiān)控

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

4）業(yè)務撥測

我們可以模擬業(yè)務請求向業(yè)務后端接口發(fā)起撥測。撥測失敗（無法連接、響應超時、錯誤返回碼）可發(fā)出告警，這種探測手段也比較有效。騰訊云的撥測功能能有效從全球發(fā)起撥測請求，并生成撥測結果報表。

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

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

上圖是某健康碼業(yè)務的第三方接口撥測，有助于自證清白。

容量壓測

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

1）讀接口壓測

我們會從系統(tǒng)隨機抽取一部分用戶，向系統(tǒng)模擬數(shù)十倍峰值請求來進行壓力測試。壓測的同時向第三方接口報備壓測流量，以免造成第三方系統(tǒng)損壞。

2）寫接口壓測

寫接口涉及到數(shù)據寫入到生產環(huán)境，所以一般采用兩種形式進行壓測。一種是標記數(shù)據壓測、比如采用一些模擬用戶ID 號段的用戶生成清求，壓測完成后采用刪除壓測數(shù)據的方式進行清臟。另一種是壓測請求http頭內攜帶壓測標記，業(yè)務代碼內對壓測請求特殊處理，旁路插入測試庫。

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

3）壓測排障

壓測過程中碰到瓶頸常見于：單核跑滿——存在于某些應用使用單核的情況，一般需要做業(yè)務改造，使系統(tǒng)運行在多核；負載過高——如CPU過高，虛擬機包量超 10W等；防火墻等數(shù)通鏈路故障——防火墻可能會存在帶寬限制、新建會話數(shù)限制等 （不限于互聯(lián)網出口防火墻、區(qū)域間防火墻）；PAAS能力限制——如redis單機版單核跑滿，連接數(shù)跑滿等；第三方接口延時過高——如第三方接口不能承壓等情況；某些私有云存在大量CPU超分。在壓測過程中發(fā)現(xiàn)并解決能力短板，從而使系統(tǒng)能達到理想的容量。

混沌工程與故障演練

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

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

通過關機、網卡禁用、實例調整等手段模擬故障，檢驗在IaaS/PaaS出現(xiàn)故障時，業(yè)務是否會受到影響，業(yè)務能否自動切換，后端業(yè)務能否自動止損熔斷等。

2）檢驗監(jiān)控覆蓋度和有效性，如基礎監(jiān)控、業(yè)務指標監(jiān)控的覆蓋度和告警有效性

通過關機、網卡禁用、實例調整等手段模擬故障，檢驗基礎監(jiān)控手段能否及時發(fā)現(xiàn)問題，業(yè)務監(jiān)控手段能否及時發(fā)現(xiàn)業(yè)務抖動，告警能否觸達到相關的運維人員。

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

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

4）提前發(fā)現(xiàn)服務穩(wěn)定性隱患并推動消除隱患，建立故障快速發(fā)現(xiàn)和快速止損的能力

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

業(yè)務架構優(yōu)化與業(yè)務柔性

優(yōu)秀的架構需要具有自保護能力與對后端應用的保護能力。常見的保護能力如：

某些高并發(fā)寫請求入庫前增加隊列以增加瞬時吞吐能力。如高峰期掃場所碼，掃場所碼信息入庫實時性要求并不強，采用騰訊云ckafka等組件進行業(yè)務削峰。

在應用加入適當時長（如：5分鐘）的緩存，用戶短時間調用該數(shù)據時走緩存，以減少對后端、第三方接口的請求。該緩存可以加在前端（如Localstorage）或 后端（采用redis或hash到有狀態(tài)服務的本地內存）。

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

后端在網關等層面限流，只允許承載能力內的請求進行后端。通過壓測對系統(tǒng)承載能力摸底，從而在接入網關進行限流。我們采用騰訊云智能網關（騰訊云公有云API網關有同樣的能力）限流。可以對后臺起到相應的保護作用。

第三方接口耗時太長，產生大量TCP連接而耗盡系統(tǒng)資源，此時會要求后端具有快速失敗的能力，不再長時間等待第三方接口返回。

上圖是健康碼系統(tǒng)分層部署及各層對后端的保護能力。以上保護手段在每個項目中的實現(xiàn)策略均有所差異。因為涉及到用戶體驗，需要與業(yè)主充分討論后執(zhí)行。

變更控制

業(yè)務上線后，需要持續(xù)保持業(yè)務穩(wěn)定運行，變更控制尤其重要，現(xiàn)網變更均需要提出變更請求，每一個變更請求需要進行技術嚴格評審后，經客戶、管理授權后方能在現(xiàn)網實施。

我們特別使用騰訊云coding承載變更工作流，變更工作在平臺中實現(xiàn)閉環(huán)。一個合格的變更請求至少要包含變更目的、實施過程、驗證方案、回退方案等。ITIL 的 change management中均有規(guī)范，此處不再詳述。變更時盡量遵循灰度發(fā)布，防止變更中產生較大影響面的問題。

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

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

作者:李雄政

來源:微信公眾號:騰訊云開發(fā)者

出處:https://mp.weixin.qq.com/s/AV_WQlHoAfotor6iVT1-Kw