作者：yorkoliu，騰訊 IEG 業(yè)務(wù)運(yùn)維專家

一、前言

上一篇文章《云原生背景下的運(yùn)維價值思考與實踐(上)》 重點(diǎn)介紹了云原生背景下運(yùn)維轉(zhuǎn)型的思考，圍繞著整個 DevOps 交付鏈，貼近業(yè)務(wù)不斷輸出運(yùn)維的能力與價值。這篇內(nèi)容我想談?wù)?DevOps 的下半段，通過我們的構(gòu)建服務(wù)穩(wěn)定性保障實踐，利用 SRE 的思想與方法，不斷去沖刺穩(wěn)定性的終極目標(biāo)：“提升 MTBF（平均故障時間間隔）、降低 MTTR（故障平均修復(fù)時間）”，很多小伙伴會有疑問，DevOps 與 SRE 到底是什么樣的關(guān)系？在 Google 出版的第二本書《The Site Reliability Workbook》的第一章節(jié) ，已經(jīng)明確給出了這個問題的解釋，一行代碼勝千言：“class SRE implements interface DevOps”，即 SRE 是 DevOps 的一種實現(xiàn)方式，也是 Google 在運(yùn)維領(lǐng)域的一種具體實踐。個人也比較認(rèn)同這個解釋，也深受啟發(fā)，不得不佩服 Google 大佬的抽象與總結(jié)能力，放眼國內(nèi)運(yùn)維行業(yè)的發(fā)展歷程，也潛移默化在形成自己的發(fā)展路徑，實踐與 Google 提出的 SRE 具有異曲同工之妙，缺少的是進(jìn)一步做抽象，形成一套完整的方法論體系。本文的出發(fā)點(diǎn)也是站在巨人肩膀之上，結(jié)合自身業(yè)務(wù)服務(wù)場景，思考在云原生背景下，運(yùn)維轉(zhuǎn)型還有多少種可能性，本文或許只給出其中一種答案吧。

二、構(gòu)建 SRE 體系

? SRE 能力全景

我們因地制宜，根據(jù) IEG 海量在線營銷的業(yè)務(wù)場景，引入 SRE 度量的機(jī)制、定制 SRE 準(zhǔn)則，以及打造較為完備的工具鏈體系，以下是團(tuán)隊構(gòu)建的玄圖-SRE 穩(wěn)定性建設(shè)全景圖：

圖2.1 - 玄圖-SRE穩(wěn)定性建設(shè)全景圖

在這個體系中，云原生環(huán)境下的 IAAS 或 PAAS，我們關(guān)注的是 MTTF (Mean Time To Failure，平均無故障時間)，這個能力由基礎(chǔ)設(shè)施團(tuán)隊來保障。

全景圖的中間是我們的玄圖 SRE 體系，采用藍(lán)鯨多級編排組裝體系中的各種能力項，MTBF 列意為平均故障時間間隔，可以理解成穩(wěn)定性保障的事前與事后，在這個環(huán)節(jié)中，我們在原有基礎(chǔ)上擴(kuò)展出兩個核心能力，其中一個是“混沌實驗”，旨在通過主動注入服務(wù)故障，提前發(fā)現(xiàn)并解決系統(tǒng)存在的隱患，提升系統(tǒng)的韌性；另一個為“全鏈路壓測”，模擬真實的并發(fā)數(shù)及用戶訪問，通過自動拓?fù)鋱D快速找到影響性能模塊，定位問題根源。MTTR 列意為故障平均修復(fù)時間，這里我們拆解了 5 個步驟，分別做下解釋：

• MTTI （Mean Time To ldentify）平均故障發(fā)現(xiàn)時間，強(qiáng)調(diào)團(tuán)隊的監(jiān)控告警能力的完備性；

• MTTA（Mean Time To Acknowledge）平均故障確認(rèn)時間，強(qiáng)調(diào)團(tuán)隊的 OnCall 機(jī)制執(zhí)行，以及制度與技術(shù)的配套；

• MTTL （Mean Time To Location）平均故障定位時間，要求團(tuán)隊對故障的分析與解決問題經(jīng)驗的積累，以及平臺工具的配套；

• MTTT （Mean Time To Troubleshooting）平均故障解決時間，對服務(wù)高可用架構(gòu)的設(shè)計、容錯、擴(kuò)展能力提出要求；

• MTTV （Mean Time To Verify）平均故障驗證時間，圍繞服務(wù)體驗為核心的監(jiān)測體系，建立與業(yè)務(wù)、用戶的反饋機(jī)制。

這個環(huán)節(jié)作為穩(wěn)定性保障的“事中”尤為重要，其中可觀測性作為下一代的質(zhì)量監(jiān)控的代表，通過強(qiáng)化分布式服務(wù)的日志、鏈路、指標(biāo)的關(guān)聯(lián)，縮短發(fā)現(xiàn)問題、解決問題的時間，可以極大縮短 MTTR 中 MTTL 的耗時。

? 定制 SRE 準(zhǔn)則

?在實踐 SRE 過程中，我們總結(jié)并提煉了“SRE 8 準(zhǔn)則”，來指導(dǎo)我們的日常運(yùn)維工作。有了這 8 個準(zhǔn)則，就很清楚我們需要具備什么樣的能力與工作方法，來達(dá)成什么樣的工作目標(biāo)，同時也延伸出下面介紹的 SRE 工具鏈。首先簡單介紹我們的 SRE 8 準(zhǔn)則，下面簡要進(jìn)行剖析：

• 架構(gòu)設(shè)計準(zhǔn)則 - 我們認(rèn)為所有的架構(gòu)都是不完美的，都存在缺陷，因此我們在做業(yè)務(wù)架構(gòu)設(shè)計時都必須要考慮服務(wù)穩(wěn)定性保障，如負(fù)載均衡、多點(diǎn)容災(zāi)、集群化服務(wù)、數(shù)據(jù)多活等能力；

• SRE 前置準(zhǔn)則 - 在業(yè)務(wù)立項之初，SRE 角色需要提前介入，將運(yùn)營階段可能出現(xiàn)的問題或風(fēng)險提前在架構(gòu)設(shè)計、編碼階段暴露，提前準(zhǔn)備好解決方案，甚至規(guī)避問題與風(fēng)險；

• 混沌實驗準(zhǔn)則 - 故障不可避免，為何不讓其在測試或預(yù)發(fā)布環(huán)境提前到來，通過模擬現(xiàn)網(wǎng)真實故障來驗證服務(wù)的“韌性”，找出系統(tǒng)的弱點(diǎn)，同時驗證我們的監(jiān)控告警的有效性，在 MTBF 階段實施最好不過，也是我們其中一把利器；

• 可觀測性準(zhǔn)則 - 通過采集業(yè)務(wù)指標(biāo)、日志、追蹤等數(shù)據(jù)，快速分析與定位問題，同時發(fā)現(xiàn)復(fù)雜系統(tǒng)的瓶頸點(diǎn)，在很長一段時間內(nèi)，業(yè)務(wù)指標(biāo)、日志、追蹤的采集與應(yīng)用，都是獨(dú)立存在并分開建設(shè)，隨著時間的推移，發(fā)現(xiàn)這三者是相互關(guān)聯(lián)，相輔相成的，是我們的第二把利器；

• 全鏈路壓測準(zhǔn)則 - 通過與可觀測性、混沌實驗?zāi)芰Φ纳疃日?#xff0c;實現(xiàn)模擬真實業(yè)務(wù)環(huán)境全鏈路壓測，達(dá)到業(yè)務(wù)上線前的精準(zhǔn)資源評估，主動發(fā)現(xiàn)潛在性能、版本缺陷等問題，是我們的第三把利器；

• DevOps 交付準(zhǔn)則 - 通過打造高效的價值交付鏈，覆蓋 CI、CD、CO 服務(wù)全生命周期運(yùn)營管理，CI 我們采用 ODP 封裝藍(lán)盾方案，CD 與 CO 采用藍(lán)鯨運(yùn)維編排及監(jiān)控告警等能力，SRE 會將大分部精力聚焦在 CO 環(huán)節(jié)；

• 故障應(yīng)急準(zhǔn)則 - 故障不可避免，我們能做的是不斷去提升 MTBF，降低 MTTR，包括事前的實施大量混沌實驗、故障預(yù)案；事中采用打造的工具鏈，快速發(fā)現(xiàn)、分析、定位與解決問題；事后組織總結(jié)復(fù)盤，沉淀案例經(jīng)驗；

• SRE 學(xué)習(xí)準(zhǔn)則 - 營造學(xué)習(xí)的文化，目的是實現(xiàn)多個不同職能團(tuán)隊的有機(jī)融合，相互了解大家面臨的問題或挑戰(zhàn)，形成一致的目標(biāo)，達(dá)到有效的協(xié)同，解決業(yè)務(wù)的問題。團(tuán)隊于 2016 年發(fā)起的《微分享》機(jī)制，截止目前累計 250 次分享 。

三、跟蹤 SLO 狀態(tài)

量化目標(biāo)是一切工作的起點(diǎn)，所有運(yùn)維工作都以圍繞 SLO（服務(wù)水平目標(biāo)）指標(biāo)的定制、執(zhí)行、跟蹤、反饋來展開。其中定制與執(zhí)行因各業(yè)務(wù)形態(tài)的差異，此處不進(jìn)行展開，指導(dǎo)的原則是選擇合適的 SLI（Service Level Indicator，服務(wù)等級指標(biāo)），設(shè)定對應(yīng)的 SLO。梳理與采用業(yè)務(wù)側(cè)關(guān)注的 SLI 指標(biāo)，目標(biāo)值達(dá)成一致即可。我們具體的 SLI 采集實踐見第一篇文章的云原生應(yīng)用監(jiān)控 章節(jié)，其中關(guān)于識別 SLI Google 提出 VALET 法，分別是 Volume、Availability、Latency、Error 和 Ticket 的首字母，這 5 個單詞就是我們選擇 SLI 指標(biāo)的 5 個維度。

• [x] Volume（容量）服務(wù)承諾的最大容量是多少，比如常見的 QPS、TPS、會話數(shù)、吞吐量以及活動連接數(shù)等等；

• [x] Availablity（可用性）代表服務(wù)是否正常或穩(wěn)定，比如請求調(diào)用 HTTP 200 狀態(tài)的成功率、任務(wù)執(zhí)行成功率等；

• [x] Latency（時延）服務(wù)響應(yīng)是否足夠快，比如時延是否符合正態(tài)分布，需指定不同的區(qū)間，比如常見的 P90、P95、P99 等；

• [x] Error（錯誤率）服務(wù)有多少錯誤率，比如 5XX、4XX，以及自定義的狀態(tài)碼；

• [x] Ticket（人工干預(yù)）是否需要人工干預(yù)，比如一些復(fù)雜故障場景，需人工介入來恢復(fù)服務(wù)。

定義業(yè)務(wù)相對應(yīng) SLI 的 SLO 后，跟蹤 SLO 有利于穩(wěn)定性目標(biāo)的達(dá)成，時刻提醒還有多少錯誤預(yù)算可以供消費(fèi)，是否應(yīng)該調(diào)整版本發(fā)布的策略或節(jié)奏，更加聚焦人力在質(zhì)量方面的優(yōu)化。我們采用 SLO Tracker 來對接故障報單平臺，獲取故障單據(jù)、影響時長等信息，定期統(tǒng)計并做團(tuán)隊反饋。

圖3.1 - SLO跟蹤統(tǒng)計報表

四、工具鏈建設(shè)

SRE 的準(zhǔn)則與方法論固然重要，但沒有強(qiáng)有力的工具鏈來作為支撐，在執(zhí)行面將面臨步步維艱，因此我們在 2 年前就開始著手規(guī)劃 SRE 工具鏈的建設(shè)，根據(jù) SRE8 準(zhǔn)則的平臺能力要求，明確了三個發(fā)展的能力項，分別為可觀測性、混沌實驗、全鏈路壓測等。首先我們也積極擁抱開源社區(qū)，得益于社區(qū)成熟技術(shù)標(biāo)準(zhǔn)與 SRE 工具鏈組件，讓我們可以充分借用社區(qū)的力量，快速且低成本構(gòu)建滿足我們自身業(yè)務(wù)場景的服務(wù)能力。同時我們也積極參與開源社區(qū)，包括貢獻(xiàn)源碼，行業(yè)大會技術(shù)布道，參與中國信通院發(fā)起的行業(yè)標(biāo)準(zhǔn)定制等等。玄圖-SRE 工具鏈體系，第一期我們通過“三位一體”，有效助力業(yè)務(wù)在“事前”提前發(fā)現(xiàn)潛在問題，“事中”快速定位問題根因，以及“事后”快速復(fù)盤歷史故障。幫助業(yè)務(wù)實現(xiàn)服務(wù)高可靠性的目標(biāo)。放眼行業(yè)，此組合方案也是云原生環(huán)境穩(wěn)定性保障的首選。下面是玄圖 SRE 工具鏈能力全景圖：

圖4.1 - 玄圖-SRE工具鏈能力全景圖

如圖 4.1 所示，是我們構(gòu)建 SRE 工具鏈的底層邏輯，首先我們打造整個體系的根基，分別定制 SRE 的標(biāo)準(zhǔn)規(guī)范、方法與目標(biāo)。平臺化只是將這套理論體系的實例化，在平臺層面我們是以可觀測性為底座，收集并共享業(yè)務(wù)的鏈路拓?fù)鋽?shù)據(jù)，供上層的混沌實驗與全鏈路壓測等平臺進(jìn)行集成，來實現(xiàn)更加高級的能力。通過多種能力的整合，目前已經(jīng)初步具備了強(qiáng)弱依賴分析、資源精準(zhǔn)評估、異常快速定位、發(fā)現(xiàn)服務(wù)瓶頸、業(yè)務(wù)拓?fù)淅斫狻⒃鰪?qiáng)服務(wù)韌性等一系列核心能力。下面將逐一進(jìn)行相關(guān)能力的介紹。

五、可觀測性平臺

1、可觀測概括

?在云原生時代下，應(yīng)用的可觀測性基礎(chǔ)設(shè)施至關(guān)重要。在 IEG 營銷服務(wù)場景下，微服務(wù)間調(diào)用關(guān)系更是錯綜復(fù)雜，給服務(wù)性能瓶頸分析、快速定位影響評估范圍和根因分析等方面帶來了諸多的挑戰(zhàn)。云原生一線開發(fā)/運(yùn)維人員時常面臨以下問題：

• 服務(wù)調(diào)用關(guān)系錯綜復(fù)雜，如何快速定位問題根因？

• 某服務(wù)發(fā)生異常，如何快速評估影響范圍？

• 如何快速分析復(fù)雜系統(tǒng)的服務(wù)瓶頸點(diǎn)？

• 服務(wù)追蹤、指標(biāo)和日志分開上報，問題定位難度大?

• 活動發(fā)布頻繁，如何快速評估服務(wù)資源？

以上問題亟待建立全新的監(jiān)控機(jī)制，幫助開發(fā)/運(yùn)維人員全面洞察系統(tǒng)運(yùn)行狀態(tài)，并在系統(tǒng)異常時幫助其快速定位解決問題，云原生可觀測性基礎(chǔ)設(shè)施應(yīng)運(yùn)而生。可觀測性則是通過采集業(yè)務(wù)指標(biāo)、日志、追蹤等數(shù)據(jù)，快速分析與定位問題，同時發(fā)現(xiàn)復(fù)雜系統(tǒng)的瓶頸點(diǎn)，在很長一段時間內(nèi)，業(yè)務(wù)指標(biāo)、日志、追蹤的采集與應(yīng)用，都是獨(dú)立存在并分開建設(shè)，隨著時間的推移，發(fā)現(xiàn)這三者是相互關(guān)聯(lián)，相輔相成的，是云原生 SRE 保障的一把利器。

圖5.1 -微服務(wù)調(diào)用關(guān)系圖

2、可觀測性架構(gòu)

玄圖-可觀測性平臺 基于 OpenTelemetry 通用解決方案，結(jié)合 IEG 營銷服務(wù)場景的服務(wù)高吞吐以及采集治理等特性要求，平臺架構(gòu)設(shè)計如下圖 5.2 所示。玄圖可觀測性平臺的架構(gòu)以 OpenTelemetry 為核心，覆蓋 Trace/Metric/Log 數(shù)據(jù)采集、傳輸、處理和應(yīng)用全流程。

圖5.2 -玄圖可觀測性架構(gòu)圖

?玄圖可觀測性平臺特點(diǎn)如下：

• OneSDK 統(tǒng)一上報 : 遵循 OpenTelemetry 協(xié)議規(guī)范，集成指標(biāo)、追蹤、日志能力-OneSDK，解決多節(jié)點(diǎn)上報時間誤差至微妙級；

• 靈活的數(shù)據(jù)治理能力 : 支持多種動態(tài)采樣策略、數(shù)據(jù)聚合控制、熔斷及降級機(jī)制。根據(jù)業(yè)務(wù)的不同體量、精細(xì)化程度等要求，靈活配置與下發(fā)策略。通過兼容流式線的頭部干預(yù)、尾部干預(yù)的綜合治理能力，保障業(yè)務(wù)運(yùn)行穩(wěn)定；

• 豐富的能力擴(kuò)展支持 : 為運(yùn)營場景中復(fù)雜業(yè)務(wù)架構(gòu)提供 AiOps 異常檢測、混沌強(qiáng)弱依賴分析、全鏈路壓測（精準(zhǔn)資源評估）等擴(kuò)展能力；

• 多語言 SDK 支持 : 目前可支持 Golang、Python、C++、PHP、RUST、JS 多種開發(fā)語言；

• 穩(wěn)定性架構(gòu) : 支持多租戶管理與運(yùn)營，支持主機(jī)與 K8S 環(huán)境部署，支持百億 PV 架構(gòu)，協(xié)助運(yùn)營人員快速發(fā)現(xiàn)、定位、分析與解決問題，效率提升 5 倍+；

• 服務(wù)解耦&分級存儲 : 引入 Kafka/Pulsar 消息中間件做上下游解耦，極大擴(kuò)展前后臺服務(wù)能力，便于集成數(shù)據(jù)應(yīng)用，且支持滿足不同應(yīng)用場景的分級存儲，支撐高峰上報 QPS300W/S 的運(yùn)營能力，提供秒級數(shù)據(jù)處理能力。

3、平臺能力擴(kuò)展

3.1 數(shù)據(jù)采集治理

微服務(wù)鏈路錯綜復(fù)雜，海量的鏈路追蹤數(shù)據(jù)對可觀測性平臺服務(wù)的運(yùn)營能力更是不小的挑戰(zhàn)，完備的數(shù)據(jù)采集治理能力必不可少。玄圖可觀測性平臺為運(yùn)維和開發(fā)人員提供了豐富的采樣治理能力和運(yùn)營治理能力，如圖 5.3 所示， 玄圖可觀測平臺支持多種動態(tài)采樣策略、數(shù)據(jù)聚合控制、熔斷及降級機(jī)制等采集運(yùn)營策略。滿足不同業(yè)務(wù)體量和精細(xì)化程度運(yùn)營要求，支持靈活配置與下發(fā)策略，且通過兼容流式線的頭部干預(yù)、尾部干預(yù)的綜合治理能力，為業(yè)務(wù)穩(wěn)定運(yùn)行保駕護(hù)航。

圖5.3 -數(shù)據(jù)采集治理技術(shù)架構(gòu)

3.2 鏈路數(shù)據(jù)檢索

玄圖可觀測性平臺為用戶提供鏈路追蹤數(shù)據(jù)采集、傳輸、處理和應(yīng)用全流程服務(wù)。其中通過鏈路數(shù)據(jù)檢索和可視化功能可清晰明了地看到同一調(diào)用鏈下服務(wù)內(nèi)部和服務(wù)間調(diào)用鏈路及其相應(yīng)調(diào)用狀態(tài)、調(diào)用時延等指標(biāo)，可幫助用戶快速定位鏈路異常點(diǎn)和分析服務(wù)性能瓶頸點(diǎn)。同時平臺也提供了豐富的查詢條件來幫助業(yè)務(wù)快速檢索到所需鏈路數(shù)據(jù)，方便易用。

圖5.4 - 服務(wù)鏈路追蹤檢索

3.3 鏈路調(diào)用拓?fù)?/h5>

微服務(wù)鏈路錯綜復(fù)雜，玄圖可觀測平臺提供了服務(wù)間調(diào)用拓?fù)潢P(guān)系圖，幫助業(yè)務(wù)快速了解其業(yè)務(wù)場景下服務(wù)間上下游調(diào)用關(guān)系，從全局的視野觀察和保障服務(wù)運(yùn)營。玄圖還利用該鏈路拓?fù)淠芰Y(jié)合混沌工程、全鏈路壓測，擴(kuò)展更多業(yè)務(wù)服務(wù)能力（下面會有詳細(xì)敘述）。

圖5.5 -服務(wù)鏈路拓?fù)鋱D

3.4 數(shù)據(jù)上報統(tǒng)計

對上報的鏈路數(shù)據(jù)，平臺同時提供了多維度的統(tǒng)計能力，包括租戶和服務(wù)維度下的錯誤率、P50/P95/P99 延遲、調(diào)用次數(shù)等指標(biāo)。通過該分析數(shù)據(jù)，業(yè)務(wù)可輕松地觀測到某個時間段內(nèi)耗時最高、成功率最差、調(diào)用次數(shù)最多的服務(wù)表現(xiàn)，從而幫助運(yùn)營任務(wù)分析問題；同時這些統(tǒng)計數(shù)據(jù)也對接了外部監(jiān)控組件，可按照業(yè)務(wù)自定義規(guī)則進(jìn)行告警，幫助業(yè)務(wù)第一時間發(fā)現(xiàn)問題。

圖5.6 - 服務(wù)數(shù)據(jù)上報統(tǒng)計

4、平臺能力擴(kuò)展

4.1 全鏈路的異常檢測

就異常檢測而言，基于領(lǐng)域的傳統(tǒng) IT 管理解決方案往往只能在單一或數(shù)個維度根據(jù)人工規(guī)則進(jìn)行判斷，無法充分利用多種數(shù)據(jù)間的潛在關(guān)聯(lián)性，也很難考慮到一些特殊情況，因而無法智能化地提供可靠、高可用的洞察和預(yù)測性分析。以玄圖可觀測性平臺為基礎(chǔ)的 AIOps 的研究旨在使用智能化的分析手段對 Trace/Metric/Log 數(shù)據(jù)進(jìn)行分析，輔助傳統(tǒng)規(guī)則方法，以更加精準(zhǔn)識別服務(wù)的異常點(diǎn)，減少誤告。

圖5.7 - 服務(wù)異常檢測方案架構(gòu)圖

玄圖 AIOps 實踐思路如上圖 5.7 所示，獲取最新一段時間的 Trace/Metrics 數(shù)據(jù)，通過訓(xùn)練好的模型推算異常權(quán)重，識別出異常的 Trace 數(shù)據(jù)。其中模型特征較為關(guān)鍵，我們通過測試階段和上線階段兩個階段不斷完善，其中測試階段我們結(jié)合壓測平臺和混沌實驗，模擬故障，自動標(biāo)注異常特征，并于上線階段，采集現(xiàn)網(wǎng)真實的 Trace 異常點(diǎn)結(jié)合任何判斷不斷更新特征庫。以下是平臺上的 AIops 能力展示：

圖5.8 -異常檢測效果圖1

4.2 調(diào)用強(qiáng)弱依賴分析

玄圖可觀測性鏈路追蹤結(jié)合混沌平臺，可以快速分析出服務(wù)間強(qiáng)弱依賴關(guān)系。玄圖可觀測性調(diào)用跟蹤系統(tǒng)追蹤記錄了服務(wù)間的調(diào)用關(guān)系，使用混沌工程給被調(diào)服務(wù)注入故障，觀察主調(diào)服務(wù)的業(yè)務(wù)指標(biāo)，可以得出服務(wù)間的強(qiáng)弱依賴關(guān)系。業(yè)務(wù)方可以進(jìn)一步結(jié)合具體業(yè)務(wù)場景進(jìn)行依賴治理，優(yōu)化關(guān)鍵路徑，實現(xiàn)低耦合架構(gòu)。比如某游戲任務(wù)系統(tǒng)這個例子，獲取任務(wù)配置服務(wù)超時致入口超時，進(jìn)而導(dǎo)致玩家請求失敗，未能降級從本地獲取配置，控制面的配置服務(wù)故障影響到了數(shù)據(jù)面，顯然是不合理的。非核心服務(wù)出現(xiàn)了問題不能將問題一直傳遞下去導(dǎo)致服務(wù)整體不可用。

圖5.9 - 強(qiáng)弱依賴分析案例

六、混沌實驗平臺

1、混沌工程概述

在我們將應(yīng)用以云原生的方式上云之后，受益于云原生的 devops、K8S、微服務(wù)、服務(wù)網(wǎng)格等技術(shù)紅利，應(yīng)用的上線下線、發(fā)布變更、容量管理、服務(wù)治理等運(yùn)營效率獲得了極大提升。海量的并發(fā)請求、敏捷的運(yùn)營訴求驅(qū)動著應(yīng)用從單體服務(wù)向微服務(wù)、分布式系統(tǒng)演進(jìn)。運(yùn)營效率提升的同時也帶來了新的挑戰(zhàn)，主要表現(xiàn)為以下幾點(diǎn)：

• 分布式系統(tǒng)日益龐大，很難評估單個故障對整個系統(tǒng)的影響；

• 服務(wù)間的依賴錯綜復(fù)雜，單個服務(wù)不可用可能拖垮整個服務(wù)；

• 請求鏈路長，全鏈路監(jiān)控告警、日志記錄等不完善，定位問題難；

• 業(yè)務(wù)、技術(shù)迭代速度快，頻繁發(fā)布變更，使得系統(tǒng)的穩(wěn)定性受到更大的挑戰(zhàn)。

在復(fù)雜的分布式系統(tǒng)中，無法阻止故障的發(fā)生，而且發(fā)生時間可能是周末、半夜、團(tuán)建時等。我們應(yīng)該致力于在這些異常故障被觸發(fā)之前，盡可能多地識別風(fēng)險。然后，針對性地進(jìn)行加固，防范，從而避免故障發(fā)生時所帶來的嚴(yán)重后果。混沌工程正是這樣一套通過在分布式系統(tǒng)上進(jìn)行實驗，主動找出系統(tǒng)中的脆弱環(huán)節(jié)的方法學(xué)。混沌工程則是通過模擬現(xiàn)網(wǎng)真實故障來驗證服務(wù)的“韌性”，找出系統(tǒng)的弱點(diǎn)，同時驗證我們的監(jiān)控告警的有效性，在 MTBF 階段實施最好不過，是我們 SRE 保障的第二把利器。

圖6.1 - 混沌工程的必要性（圖片來源網(wǎng)絡(luò)）

2、平臺技術(shù)架構(gòu)

玄圖體系致力于打造完整的云原生運(yùn)維能力，其中混沌工程作為質(zhì)量管理工具，通過故障注入的方式幫助系統(tǒng)尋找薄弱點(diǎn)，提高系統(tǒng)的穩(wěn)定性，構(gòu)建具備韌性的應(yīng)用。玄圖混沌實驗平臺主要基于開源技術(shù)框架，并且在原框架基礎(chǔ)上引入了開源組件 ChaosMesh 和 ChaosBlade。玄圖混沌實驗平臺架構(gòu)如下圖 6.2 所示，在平臺設(shè)計層面，我們按照計劃-編排-執(zhí)行-觀察-記錄-還原的思路，設(shè)計了演練計劃、演練編排、演練管理、演練報表和演練報告等模塊。基于這些模塊，在平臺上可以實施自動化日常演練、紅藍(lán)攻防演練、突襲演練等豐富的能力，且打通了藍(lán)鯨、奇點(diǎn)、北極星等內(nèi)部系統(tǒng)，業(yè)務(wù)開箱即用。

圖6.2 - 玄圖混沌工程實驗平臺架構(gòu)圖

?具體平臺能力體系如下：

• 故障注入場景豐富，玄圖混沌工程實驗平臺提供 27 種故障原子，覆蓋主機(jī)和 K8S 環(huán)境，并且支持自定義擴(kuò)展；

• 靈活的實驗編排能力，平臺提供靈活的實驗編排能力，相對于手工腳本編排實驗，通過平臺執(zhí)行故障演練效率提升 10 倍；

• 實驗觀測&實驗報告閉環(huán)，玄圖混沌工程實驗平臺打通了監(jiān)控系統(tǒng)，實驗過程中可實時觀測實驗效果，實驗結(jié)束輸出實驗報告；

• 紅藍(lán)對抗常態(tài)化，平臺支持對抗演練記錄、歸檔，便于回溯、沉淀，增強(qiáng)趣味性和參與積極性；

• 可擴(kuò)展架構(gòu)，平臺基于可擴(kuò)展架構(gòu)設(shè)計，支持自定義故障原子，可靈活應(yīng)對復(fù)雜實驗需求；

• 通用性方面，玄圖混沌實驗平臺將公司內(nèi)部的藍(lán)鯨、奇點(diǎn)、北極星、網(wǎng)管系統(tǒng)等系統(tǒng)進(jìn)行集成打通，實現(xiàn)所有業(yè)務(wù)都能開箱即用，無需額外的開發(fā)接入改造成本，實現(xiàn)了一站式服務(wù)。下面分別具體介紹下玄圖混沌實驗平臺具體能力體系。

3、平臺能力擴(kuò)展

1）故障演練提效

傳統(tǒng)的手工故障演練一般是根據(jù)需求臨時開發(fā)工具，工具開發(fā)完之后還需測試驗證，功能大同小異，浪費(fèi)了很多重復(fù)工作，臨時開發(fā)的工具，效果還不能保證。玄圖混沌平臺的故障原子是經(jīng)過大量的實踐反復(fù)驗證的，效果穩(wěn)定可靠，拿起來就能直接用，沒有開發(fā)成本。故障的原子非常豐富，可以模擬出機(jī)器、網(wǎng)絡(luò)、操作系統(tǒng)、應(yīng)用層異常等各種故障場景。平臺還提供了靈活的實驗編排能力，可以一次性把多個不同的故障編排之后自動執(zhí)行。實驗執(zhí)行之后都需要觀察效果，手工故障演練需要借助于其他工具或者第三方平臺看效果，而玄圖混沌平臺打通了基礎(chǔ)指標(biāo)數(shù)據(jù)以及支持業(yè)務(wù)自定義指標(biāo)，在實驗過程中可以直接查看到實驗效果。另外，臨時演練是一次性的，沒有記錄和保留現(xiàn)場，沒法回溯，玄圖實驗平臺詳細(xì)記錄了每次實驗內(nèi)容，隨時都可以查詢以及復(fù)現(xiàn)。總結(jié)起來，玄圖混沌工程故障演練平臺，提供實驗編排、執(zhí)行、觀察、記錄一站式服務(wù)，將故障演練的耗時從小時級縮短到分鐘級，相對于手工故障演練效率提高了 10 倍以上。

圖6.3 - 精簡流程，提升效率

2）故障注入原子

玄圖混沌平臺能夠模擬的故障非常豐富，通過故障原子組合可以模擬出云服務(wù)異常，機(jī)器故障，操作系統(tǒng)故障，網(wǎng)絡(luò)故障，應(yīng)用層故障，以及根據(jù)特定場景定制的故障等。很好的解決了傳統(tǒng)故障演練工具開發(fā)耗時久，工作重復(fù)，效果沒發(fā)精準(zhǔn)控制，工具沒法復(fù)用等痛點(diǎn)。比如光纖中斷生產(chǎn)環(huán)境很難復(fù)現(xiàn)，但通過混沌工程網(wǎng)絡(luò)丟包實驗可以輕松模擬。目前平臺已經(jīng)支持的故障注入能力如下：

表6.1 - 玄圖混沌工程實驗平臺支持原子

3）實驗編排能力

在實際場景中，我們一般需要同時模擬多個故障，也就是需要把多個故障編排在一起并行或者串行執(zhí)行，玄圖混沌平臺支持拖拉拽完成復(fù)雜故障場景編排，可以同時模擬多個服務(wù)，多種類型故障，實現(xiàn)了分鐘級復(fù)雜故障事件演練。

圖6.4-實驗編排

4）實驗觀測報告

混沌實驗平臺提供了實驗編排、執(zhí)行、觀測、報告輸出等一站式實驗?zāi)芰?#xff0c;比如我們需要驗證一臺機(jī)機(jī)器掛了對服務(wù)到底有何影響。可以在平臺上發(fā)起一個丟包 100%的實驗，理想情況下，1 分鐘內(nèi)能自動隔離異常機(jī)器，請求成功率會出現(xiàn)短暫下跌，1 分鐘后能自動恢復(fù)。業(yè)務(wù) QPS、耗時、成功率都能保持穩(wěn)定。實驗執(zhí)行之后可以通過平臺的報表實時觀測效果，這里的例子我們發(fā)現(xiàn)響應(yīng)延遲明顯上升，QPS 明顯下跌，并且持續(xù) 5 分鐘以上都沒有恢復(fù)，不符合預(yù)期。實驗結(jié)束之后在平臺可以直接記錄實驗結(jié)論：系統(tǒng)不能自動隔離剔除后端異常實例，需要優(yōu)化改造。實驗過程、數(shù)據(jù)得以很好的保存記錄。

圖6.5 - 實驗報告

5）紅藍(lán)對抗常態(tài)化

玄圖混沌平臺還支持發(fā)起紅藍(lán)對抗，左右互搏通常很枯燥。通過紅藍(lán)對抗的方式，增加了故障演練的趣味性和游戲性。玄圖混沌平臺通過流程工具打通紅藍(lán)對抗的全流程，記錄每一次演練的詳情，很好的解決了傳統(tǒng)的紅藍(lán)對抗，溝通成本高，缺少工具支持，流程不規(guī)范，反饋不及時，經(jīng)驗無沉淀的痛點(diǎn)。通過常態(tài)化的紅藍(lán)對抗故障演練培養(yǎng)了業(yè)務(wù)開發(fā)人員的風(fēng)險意識，從軟件設(shè)計之初就考慮到可能會遇到的各種故障，提前從架構(gòu)設(shè)計層面規(guī)避，有效提升服務(wù)的容錯能力。

圖6.6 - 紅藍(lán)對抗流程圖

6）可擴(kuò)展架構(gòu)

故障演練的需求隨著技術(shù)和業(yè)務(wù)的發(fā)展會不斷的變化，為了應(yīng)對這種變化，我們從設(shè)計之初就采用了可擴(kuò)展架構(gòu)，實驗原子之間解耦，某個原子的增刪改不影響其他原子，遇到新的實驗需求，可以任意橫向增加原子，從軟件架構(gòu)上實現(xiàn)了對需求變化的靈活應(yīng)對。

圖6.7 - 可擴(kuò)展框架

七、全鏈路壓測+ 平臺

1、全鏈路壓測概述

游戲營銷服務(wù)旨在通過精細(xì)化運(yùn)營活動，實現(xiàn)拉新、拉活躍、拉回流等運(yùn)營事件，使玩家獲得更好的游戲體驗。在線服務(wù)有如下特點(diǎn)：

• 節(jié)奏快，比如開黑節(jié)，戰(zhàn)斗之夜，周年慶，活動僅持續(xù)數(shù)日；

• 數(shù)量多，每天都會有大量活動上線，而且活動種類繁多；

• 訪問量大，游戲運(yùn)營活動高峰時段日 PV 超過百億；

• 訪問量無法精準(zhǔn)預(yù)估，很難精準(zhǔn)的預(yù)測一次活動的訪問量，玩家參與度經(jīng)常超預(yù)期；

• 活動邏輯復(fù)雜，上下游依賴多，并且對依賴服務(wù)有 N 倍放大，容量評估工作量大。

正是由于營銷活動這些特點(diǎn)，在日常運(yùn)營中，我們幾乎每天都要面臨類似“雙 11”的考驗，經(jīng)常面臨如下難題：

• 活動上線節(jié)奏快，開發(fā)周期短，遇到性能問題需要快速定位解決；

• 微服務(wù)間調(diào)用關(guān)系復(fù)雜，性能問題排查困難，費(fèi)時費(fèi)力，難以快速診斷出瓶頸點(diǎn)；

• 調(diào)用拓?fù)滏溌凡煌该?#xff0c;需要耗費(fèi)大量人力梳理調(diào)用關(guān)系和放大倍數(shù)；

• 已經(jīng)在線上運(yùn)行的服務(wù)容量評估主要依據(jù)經(jīng)驗，重要活動通過大量堆機(jī)器支撐。

為了解決以上難題，我們啟動了全鏈路壓測+平臺建設(shè)，通過在生產(chǎn)環(huán)境對業(yè)務(wù)大流量場景進(jìn)行高仿真模擬，獲取最真實的線上實際承載能力、執(zhí)行精準(zhǔn)的容量規(guī)劃，目的在于保障系統(tǒng)可用性。

事實上，系統(tǒng)的容量是一只薛定諤的貓，只有打開箱子才知道貓是什么情況，只有通過全鏈路壓測才能準(zhǔn)確掌握系統(tǒng)的極限值。如圖 7.1 所示，QPS 到 1 萬的時候，資源負(fù)載是 20%，根據(jù)經(jīng)驗預(yù)估 QPS 到 3 萬負(fù)載到 60%，容量是充足的，流量漲 2 倍沒問題。事實上影響服務(wù)性能的因素有很多，長連接、短鏈接、請求串、返回串的大小都會影響到服務(wù)性能，真正的兩倍流量過來，服務(wù)已經(jīng)過載了，經(jīng)驗往往是靠不住的。

圖7.1 - QPS與資源負(fù)載曲線

只有通過生產(chǎn)環(huán)境全鏈路執(zhí)行壓測，真實模擬用戶行為場景，實時監(jiān)控系統(tǒng)表現(xiàn)，提前識別和快速定位系統(tǒng)的中的不確定因素，并對不確定因素進(jìn)行處理，優(yōu)化系統(tǒng)資源配比，使用最低資源成本，使系統(tǒng)從容面對各種極端場景，達(dá)到預(yù)期的系統(tǒng)性能目標(biāo)。通過這種方法，在生產(chǎn)環(huán)境上落地常態(tài)化穩(wěn)定壓測體系，實現(xiàn)業(yè)務(wù)系統(tǒng)的長期性能穩(wěn)定治理。因此平臺放在 MTBF 階段實施，是我們 SRE 保障的第三把利器。

2、全鏈路壓測架構(gòu)

傳統(tǒng)壓測工具的定位僅僅是制造壓力，對目標(biāo)服務(wù)發(fā)起請求，被壓服務(wù)對其而言是個黑盒子，當(dāng)壓測發(fā)現(xiàn)問題后需要被壓服務(wù)側(cè)自行分析定位原因，壓測工具能夠發(fā)揮的作用有限，并且可替代性很強(qiáng)，市面上有非常多的壓測工具可供選擇。

全鏈路壓測+平臺具備傳統(tǒng)壓測工具的發(fā)壓能力，壓力引擎當(dāng)前采用的是開源社區(qū)的 locust+boomer 方案，經(jīng)過調(diào)優(yōu)，單核發(fā)壓能力能達(dá)到 2w/s，同時基于 TKE 云原生架構(gòu)，壓力源做到了彈性伸縮，可以根據(jù)負(fù)載自動擴(kuò)容，理論上并發(fā)數(shù)可以做到無限擴(kuò)展。同時，壓力引擎可以根據(jù)需要靈活的集成使用其他優(yōu)秀引擎。

圖7.2 - 全鏈路壓測+ 平臺架構(gòu)圖

全鏈路壓測+平臺的重點(diǎn)在于對被壓服務(wù)進(jìn)行剖析，基于 SRE 工具鏈中的可觀測性平臺，拿到了服務(wù)調(diào)用關(guān)系鏈，通過 TraceID 可以將一次請求經(jīng)過的全鏈路服務(wù)串聯(lián)起來，基于此可以計算出服務(wù)間的調(diào)用拓?fù)鋱D，在發(fā)起壓測的同時自動生成全鏈路調(diào)用拓?fù)潢P(guān)系。并且統(tǒng)計出每一層調(diào)用的黃金監(jiān)控指標(biāo)，如 QPS、耗時、成功率等，可以一目了然的看到微服務(wù)間的放大倍數(shù)。在壓測過程中能實時觀測到全鏈路每個環(huán)節(jié)的指標(biāo)，當(dāng)壓測出現(xiàn)瓶頸時，如入口延遲增大，從鏈路統(tǒng)計視圖能快速定位到導(dǎo)致入口延遲增大的具體微服務(wù)，再進(jìn)一步通過 trace 詳情下鉆分析，能夠定位到具體的方法。

總體而言，全鏈路壓測平臺不僅提供了傳統(tǒng)壓測基礎(chǔ)功能，如數(shù)據(jù)構(gòu)造、請求撥測、壓測監(jiān)控、壓測編排、發(fā)起壓力等。同時提供了壓測分析增值功能，如鏈路拓?fù)溆嬎恪㈡溌方y(tǒng)計、性能瓶頸定位、壓測流量染色、根因下鉆分析等。

3.平臺能力介紹

3.1 靈活的壓測編排

平臺支持靈活的發(fā)壓模式，包括：

• 固定壓力模式：并發(fā)數(shù)固定，可以設(shè)置最大 QPS

• 階梯壓力模式：并發(fā)數(shù)持續(xù)增加，可以設(shè)置最大并發(fā)數(shù)和最大 QPS

• 快速壓測模式：并發(fā)數(shù)持續(xù)增加，達(dá)到指定錯誤率或耗時閾值后壓測自動停止

圖7.3 - 壓測編排

3.2 云原生架構(gòu)

全鏈路壓測+平臺的壓力源由平臺托管，用戶無需關(guān)注壓力源。壓力源基于 TKE 容器化部署，資源可以根據(jù)需要靈活擴(kuò)展，理論上可以做到無限擴(kuò)展。同時，平臺將壓力源的負(fù)載指標(biāo)主動暴露出來，可以通過壓測報告實時查看壓力源負(fù)載數(shù)據(jù)。

圖7.4 - 壓力源負(fù)載指標(biāo)

3.3 豐富的壓測指標(biāo)

全鏈路壓測+平臺的壓測工具作為請求客戶端，會實時上報壓測指標(biāo)，在壓測過程中通過壓測報告能實時觀測到相關(guān)的監(jiān)控指標(biāo)，包括 QPS、耗時、成功率等，同時能夠查看壓測客戶端的請求返回日志。

圖7.5 - 壓測指標(biāo)監(jiān)控

3.4 全鏈路拓?fù)鋱D

基于可觀測性技術(shù)，全鏈路壓測平臺能捕獲微服務(wù)間調(diào)用拓?fù)潢P(guān)系，在壓測過程中，根據(jù)實際請求調(diào)用鏈實時生成服務(wù)間調(diào)用拓?fù)鋱D，并且統(tǒng)計出每一層調(diào)用的黃金監(jiān)控指標(biāo)，如 QPS、耗時、成功率等，通過拓?fù)鋱D可以一目了然的看到微服務(wù)間的放大倍數(shù)。其中對于第三方服務(wù)（如 DB）在沒有上報 trace 的情況下也能通過自動補(bǔ)鏈技術(shù)計算出統(tǒng)計指標(biāo)。

圖7.6 - 全鏈路拓?fù)鋱D

3.5 全鏈路統(tǒng)計

基于可觀測性技術(shù)，全鏈路壓測平臺能計算出鏈路拓?fù)鋱D中每一層調(diào)用的黃金指標(biāo)（QPS、耗時、成功率等），并通過時序報表實時展示。當(dāng)壓測出現(xiàn)瓶頸后（失敗率或耗時明顯增加），通過報表能夠快速定位到導(dǎo)致系統(tǒng)出現(xiàn)瓶頸的微服務(wù)，再進(jìn)一步通過 trace 詳情下鉆分析，能夠定位到具體的方法，極大提升了性能問題定位效率。

圖7.7 - 全鏈路指標(biāo)統(tǒng)計

3.6 其它

除此之外，全鏈路壓測+平臺還提供壓測流量染色（特定 Header 頭）以及壓測標(biāo)記全鏈路透傳功能，被壓服務(wù)適配后能夠?qū)崿F(xiàn)壓測流量隔離，將壓測流量導(dǎo)流到影子庫表。實現(xiàn)了在不污染生產(chǎn)環(huán)境業(yè)務(wù)數(shù)據(jù)情況下進(jìn)行全鏈路性能測試，能在生產(chǎn)環(huán)境對寫類型接口進(jìn)行直接的性能測試，實現(xiàn)在生產(chǎn)環(huán)境可控壓力測試。當(dāng)前我們也正在探索無侵入的流量隔離方案，敬請期待。

八、思考與未來規(guī)劃

SRE 體系的建設(shè)任重道遠(yuǎn)，完全復(fù)制 Google SRE 方法顯然是行不通，個人認(rèn)為原因有三個方面，第一點(diǎn)是以 Google SRE 崗位能力要求進(jìn)行人才招聘，在國內(nèi)存在一定難度；第二點(diǎn)是 SRE 文化在國內(nèi)企業(yè)的認(rèn)知與普及都不太夠；第三點(diǎn)受限于基礎(chǔ)設(shè)施即代碼、體系化的 SRE 工具鏈、服務(wù)標(biāo)準(zhǔn)及抽象等能力成熟度。另外，我們也面臨著諸多挑戰(zhàn)，包括互聯(lián)網(wǎng)行業(yè)日新月異的業(yè)務(wù)形態(tài)、新技術(shù)的不斷發(fā)展，業(yè)務(wù)的復(fù)雜度勢必會日益增大，但業(yè)務(wù)對穩(wěn)定性訴求是不變的。同時，云原生環(huán)境存在著大量的三方 PaaS 連接與集成，穩(wěn)定性保障也存在失控的風(fēng)險。站在 SRE 的角度，任何一個細(xì)微環(huán)節(jié)的缺失與不足，都有可能影響 SLO 達(dá)標(biāo)率。

為應(yīng)對這些挑戰(zhàn)，我們會將整個 SRE 穩(wěn)定性全景拼圖逐步進(jìn)行拼湊，所以注定是一個長期持續(xù)建設(shè)的過程。下階段我們會重點(diǎn)深度整合“三件套”能力，驗證其真正發(fā)揮的效能。部分能力也會積極貢獻(xiàn)給社區(qū)。相信不久，我們會陸續(xù)推出 SRE“四件套、五件套...”,大家拭目以待。

作者簡介：劉天斯 騰訊 IEG 在線營銷 SRE 負(fù)責(zé)人，騰訊 T12 級技術(shù)專家，國家工程實驗室茲聘專家。從事互聯(lián)網(wǎng)技術(shù)運(yùn)營近 16 年，熱衷開源技術(shù)研究與應(yīng)用，擅長海量服務(wù)運(yùn)維(SRE)與規(guī)劃、云原生技術(shù)、大數(shù)據(jù)治理、數(shù)據(jù)中臺與業(yè)務(wù)中臺的建設(shè)等工作。

o 曾榮獲：華章最有價值作者、中國十大杰出 IT 博主、WOT 十大優(yōu)秀講師、OpsWorld 金牌講師、TOP100 優(yōu)秀出品人、中國數(shù)據(jù)質(zhì)量杰出專家獎、DAMA 中國數(shù)據(jù)治理專家獎。

o 中國信息通信研究院-專家委員、海南省大數(shù)據(jù)產(chǎn)業(yè)聯(lián)盟專家組成員，曾參與行業(yè)級《數(shù)據(jù)資產(chǎn)管理實踐白皮書》、《數(shù)據(jù)標(biāo)準(zhǔn)管理白皮書》、《大數(shù)據(jù)運(yùn)維成熟度模型》、《微服務(wù)分級標(biāo)準(zhǔn)》、《混沌工程平臺能力要求》、《可觀測性平臺能力要求》等多個行業(yè)標(biāo)準(zhǔn)的編寫。

o 個人著作：《python 自動化運(yùn)維：技術(shù)與實踐》、《循序漸進(jìn)學(xué) Docker》、《第一次使用 Docker 就上手》、《破解數(shù)據(jù)治理之謎》等，個人發(fā)明專利 12 個。

總結(jié)

以上是生活随笔為你收集整理的云原生背景运维转型之 SRE 实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。