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

業(yè)務(wù)背景

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

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

技術(shù)架構(gòu)體系

一個(gè)穩(wěn)定的架構(gòu)是設(shè)計(jì)與運(yùn)維出來的，為了達(dá)到穩(wěn)態(tài)運(yùn)行，設(shè)計(jì)上考慮了以下幾個(gè)方面：

1）選用合適的云原生產(chǎn)品

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

• 帶寬容量問題

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

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

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

• 云資源成本問題

云產(chǎn)品擁有較大的共享資源冗余，能夠快速達(dá)成大容量，同時(shí)深度采用云原生產(chǎn)品，能夠帶來較大程度的成本節(jié)約。例如采用scf云函數(shù)，無需在購買云服務(wù)器的情況下運(yùn)行代碼，使用騰訊云的能力彈性、安全地運(yùn)行代碼。無需冗余資源閑時(shí)運(yùn)行成本買單，同時(shí)因?yàn)樵圃a(chǎn)品具有天然的跨可用區(qū)容災(zāi)能力，基于云原生的兩地三中心架構(gòu)設(shè)計(jì)，基于騰訊云公有云通?？梢詽M足的高可用能力如：從負(fù)載層采用CLB的跨可用區(qū)高可用能力進(jìn)行可用區(qū)容錯(cuò)；應(yīng)用層TSF/TKE/CKAFKA的多可用區(qū)高可用能力容錯(cuò)；存儲(chǔ)層采用TDSQL多可用區(qū)部署及主從同步能力滿足高可用與容災(zāi)。

2）立體化監(jiān)控體系設(shè)計(jì)

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

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

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

可觀測體系

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

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

1）基礎(chǔ)組件可觀測

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

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

2）業(yè)務(wù)指標(biāo)可觀測

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

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

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

• 成功率監(jiān)控

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

• 耗時(shí)監(jiān)控

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

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

3）用戶體驗(yàn)可觀測

• 前端監(jiān)控

我們?cè)诮】荡a項(xiàng)目中使用的監(jiān)控工具是騰訊云RUM監(jiān)控（Real User Monitoring), RUM監(jiān)控的便捷之處在于對(duì)業(yè)務(wù)代碼的侵入性較少，只需新增數(shù)行代碼。能夠監(jiān)控到前端JS錯(cuò)誤、白屏、首屏打開速度、API成功率、API耗時(shí)等。

import Aegis from 'aegis-mp-sdk';const aegis = new Aegis({ id: "pGUVFTCZyewxxxxx", // 項(xiàng)目key uin: 'xxx', // 用戶唯一 ID（可選） reportApiSpeed: true, // 接口測速 spa: true, // 頁面切換的時(shí)候上報(bào) pv});

代碼示例：RUM監(jiān)控接入方法及為簡單方便。

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

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

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

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

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

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

4）業(yè)務(wù)撥測

我們可以模擬業(yè)務(wù)請(qǐng)求向業(yè)務(wù)后端接口發(fā)起撥測。撥測失?。o法連接、響應(yīng)超時(shí)、錯(cuò)誤返回碼）可發(fā)出告警，這種探測手段也比較有效。騰訊云的撥測功能能有效從全球發(fā)起撥測請(qǐng)求，并生成撥測結(jié)果報(bào)表。

上圖是全國健康碼質(zhì)量撥測質(zhì)量視圖。

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

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

容量壓測

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

1）讀接口壓測

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

2）寫接口壓測

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

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

3）壓測排障

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

混沌工程與故障演練

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

1）檢驗(yàn)服務(wù)的高可用性，如架構(gòu)無單點(diǎn)，具備健康檢查、負(fù)載均衡等能力

通過關(guān)機(jī)、網(wǎng)卡禁用、實(shí)例調(diào)整等手段模擬故障，檢驗(yàn)在IaaS/PaaS出現(xiàn)故障時(shí)，業(yè)務(wù)是否會(huì)受到影響，業(yè)務(wù)能否自動(dòng)切換，后端業(yè)務(wù)能否自動(dòng)止損熔斷等。

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

通過關(guān)機(jī)、網(wǎng)卡禁用、實(shí)例調(diào)整等手段模擬故障，檢驗(yàn)基礎(chǔ)監(jiān)控手段能否及時(shí)發(fā)現(xiàn)問題，業(yè)務(wù)監(jiān)控手段能否及時(shí)發(fā)現(xiàn)業(yè)務(wù)抖動(dòng)，告警能否觸達(dá)到相關(guān)的運(yùn)維人員。

3）檢驗(yàn)應(yīng)急預(yù)案的有效性，如擴(kuò)縮容預(yù)案，限流預(yù)案等

以壓力測試為輔助，檢驗(yàn)壓力條件下，能否快速成功擴(kuò)充容量，能否快速啟動(dòng)對(duì)業(yè)務(wù)限流。

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

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

業(yè)務(wù)架構(gòu)優(yōu)化與業(yè)務(wù)柔性

優(yōu)秀的架構(gòu)需要具有自保護(hù)能力與對(duì)后端應(yīng)用的保護(hù)能力。常見的保護(hù)能力如：

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

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

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

后端在網(wǎng)關(guān)等層面限流，只允許承載能力內(nèi)的請(qǐng)求進(jìn)行后端。通過壓測對(duì)系統(tǒng)承載能力摸底，從而在接入網(wǎng)關(guān)進(jìn)行限流。我們采用騰訊云智能網(wǎng)關(guān)（騰訊云公有云API網(wǎng)關(guān)有同樣的能力）限流?？梢詫?duì)后臺(tái)起到相應(yīng)的保護(hù)作用。

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

上圖是健康碼系統(tǒng)分層部署及各層對(duì)后端的保護(hù)能力。以上保護(hù)手段在每個(gè)項(xiàng)目中的實(shí)現(xiàn)策略均有所差異。因?yàn)樯婕暗接脩趔w驗(yàn)，需要與業(yè)主充分討論后執(zhí)行。

變更控制

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

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

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

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

作者:李雄政

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

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