點擊上方“服務(wù)端思維”，選擇“設(shè)為星標”

回復(fù)”669“獲取獨家整理的精選資料集

回復(fù)”加群“加入全國服務(wù)端高端社群「后端圈」

作者 | 騰訊程序員出品?| 騰訊技術(shù)工程

一、前言

這篇內(nèi)容我想談?wù)?DevOps 的下半段，通過我們的構(gòu)建服務(wù)穩(wěn)定性保障實踐，利用 SRE 的思想與方法，不斷去沖刺穩(wěn)定性的終極目標：“提升 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 在運維領(lǐng)域的一種具體實踐。個人也比較認同這個解釋，也深受啟發(fā)，不得不佩服 Google 大佬的抽象與總結(jié)能力，放眼國內(nèi)運維行業(yè)的發(fā)展歷程，也潛移默化在形成自己的發(fā)展路徑，實踐與 Google 提出的 SRE 具有異曲同工之妙，缺少的是進一步做抽象，形成一套完整的方法論體系。本文的出發(fā)點也是站在巨人肩膀之上，結(jié)合自身業(yè)務(wù)服務(wù)場景，思考在云原生背景下，運維轉(zhuǎn)型還有多少種可能性，本文或許只給出其中一種答案吧。

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

? SRE 能力全景

我們因地制宜，根據(jù) IEG 海量在線營銷的業(yè)務(wù)場景，引入 SRE 度量的機制、定制 SRE 準則，以及打造較為完備的工具鏈體系，以下是團隊構(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è)施團隊來保障。

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

• MTTI （Mean Time To ldentify）平均故障發(fā)現(xiàn)時間，強調(diào)團隊的監(jiān)控告警能力的完備性；
• MTTA（Mean Time To Acknowledge）平均故障確認時間，強調(diào)團隊的 OnCall 機制執(zhí)行，以及制度與技術(shù)的配套；
• MTTL （Mean Time To Location）平均故障定位時間，要求團隊對故障的分析與解決問題經(jīng)驗的積累，以及平臺工具的配套；
• MTTT （Mean Time To Troubleshooting）平均故障解決時間，對服務(wù)高可用架構(gòu)的設(shè)計、容錯、擴展能力提出要求；
• MTTV （Mean Time To Verify）平均故障驗證時間，圍繞服務(wù)體驗為核心的監(jiān)測體系，建立與業(yè)務(wù)、用戶的反饋機制。

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

? 定制 SRE 準則

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

• 架構(gòu)設(shè)計準則 - 我們認為所有的架構(gòu)都是不完美的，都存在缺陷，因此我們在做業(yè)務(wù)架構(gòu)設(shè)計時都必須要考慮服務(wù)穩(wěn)定性保障，如負載均衡、多點容災(zāi)、集群化服務(wù)、數(shù)據(jù)多活等能力；
• SRE 前置準則 - 在業(yè)務(wù)立項之初，SRE 角色需要提前介入，將運營階段可能出現(xiàn)的問題或風險提前在架構(gòu)設(shè)計、編碼階段暴露，提前準備好解決方案，甚至規(guī)避問題與風險；
• 混沌實驗準則 - 故障不可避免，為何不讓其在測試或預(yù)發(fā)布環(huán)境提前到來，通過模擬現(xiàn)網(wǎng)真實故障來驗證服務(wù)的“韌性”，找出系統(tǒng)的弱點，同時驗證我們的監(jiān)控告警的有效性，在 MTBF 階段實施最好不過，也是我們其中一把利器；
• 可觀測性準則 - 通過采集業(yè)務(wù)指標、日志、追蹤等數(shù)據(jù)，快速分析與定位問題，同時發(fā)現(xiàn)復(fù)雜系統(tǒng)的瓶頸點，在很長一段時間內(nèi)，業(yè)務(wù)指標、日志、追蹤的采集與應(yīng)用，都是獨立存在并分開建設(shè)，隨著時間的推移，發(fā)現(xiàn)這三者是相互關(guān)聯(lián)，相輔相成的，是我們的第二把利器；
• 全鏈路壓測準則 - 通過與可觀測性、混沌實驗?zāi)芰Φ纳疃日?，實現(xiàn)模擬真實業(yè)務(wù)環(huán)境全鏈路壓測，達到業(yè)務(wù)上線前的精準資源評估，主動發(fā)現(xiàn)潛在性能、版本缺陷等問題，是我們的第三把利器；
• DevOps 交付準則 - 通過打造高效的價值交付鏈，覆蓋 CI、CD、CO 服務(wù)全生命周期運營管理，CI 我們采用 ODP 封裝藍盾方案，CD 與 CO 采用藍鯨運維編排及監(jiān)控告警等能力，SRE 會將大分部精力聚焦在 CO 環(huán)節(jié)；
• 故障應(yīng)急準則 - 故障不可避免，我們能做的是不斷去提升 MTBF，降低 MTTR，包括事前的實施大量混沌實驗、故障預(yù)案；事中采用打造的工具鏈，快速發(fā)現(xiàn)、分析、定位與解決問題；事后組織總結(jié)復(fù)盤，沉淀案例經(jīng)驗；
• SRE 學(xué)習準則 - 營造學(xué)習的文化，目的是實現(xiàn)多個不同職能團隊的有機融合，相互了解大家面臨的問題或挑戰(zhàn)，形成一致的目標，達到有效的協(xié)同，解決業(yè)務(wù)的問題。團隊于 2016 年發(fā)起的《微分享》機制，截止目前累計 250 次分享 。

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

量化目標是一切工作的起點，所有運維工作都以圍繞 SLO（服務(wù)水平目標）指標的定制、執(zhí)行、跟蹤、反饋來展開。其中定制與執(zhí)行因各業(yè)務(wù)形態(tài)的差異，此處不進行展開，指導(dǎo)的原則是選擇合適的 SLI（Service Level Indicator，服務(wù)等級指標），設(shè)定對應(yīng)的 SLO。梳理與采用業(yè)務(wù)側(cè)關(guān)注的 SLI 指標，目標值達成一致即可。我們具體的 SLI 采集實踐見第一篇文章的云原生應(yīng)用監(jiān)控 章節(jié)，其中關(guān)于識別 SLI Google 提出 VALET 法，分別是 Volume、Availability、Latency、Error 和 Ticket 的首字母，這 5 個單詞就是我們選擇 SLI 指標的 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)定性目標的達成，時刻提醒還有多少錯誤預(yù)算可以供消費，是否應(yīng)該調(diào)整版本發(fā)布的策略或節(jié)奏，更加聚焦人力在質(zhì)量方面的優(yōu)化。我們采用 SLO Tracker 來對接故障報單平臺，獲取故障單據(jù)、影響時長等信息，定期統(tǒng)計并做團隊反饋。

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

四、工具鏈建設(shè)

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

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

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

五、可觀測性平臺

1、可觀測概括

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

• 服務(wù)調(diào)用關(guān)系錯綜復(fù)雜，如何快速定位問題根因？
• 某服務(wù)發(fā)生異常，如何快速評估影響范圍？
• 如何快速分析復(fù)雜系統(tǒng)的服務(wù)瓶頸點？
• 服務(wù)追蹤、指標和日志分開上報，問題定位難度大?
• 活動發(fā)布頻繁，如何快速評估服務(wù)資源？

以上問題亟待建立全新的監(jiān)控機制，幫助開發(fā)/運維人員全面洞察系統(tǒng)運行狀態(tài)，并在系統(tǒng)異常時幫助其快速定位解決問題，云原生可觀測性基礎(chǔ)設(shè)施應(yīng)運而生。可觀測性則是通過采集業(yè)務(wù)指標、日志、追蹤等數(shù)據(jù)，快速分析與定位問題，同時發(fā)現(xiàn)復(fù)雜系統(tǒng)的瓶頸點，在很長一段時間內(nèi)，業(yè)務(wù)指標、日志、追蹤的采集與應(yīng)用，都是獨立存在并分開建設(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)圖

?玄圖可觀測性平臺特點如下：

• OneSDK 統(tǒng)一上報 : 遵循 OpenTelemetry 協(xié)議規(guī)范，集成指標、追蹤、日志能力-OneSDK，解決多節(jié)點上報時間誤差至微妙級；
• 靈活的數(shù)據(jù)治理能力 : 支持多種動態(tài)采樣策略、數(shù)據(jù)聚合控制、熔斷及降級機制。根據(jù)業(yè)務(wù)的不同體量、精細化程度等要求，靈活配置與下發(fā)策略。通過兼容流式線的頭部干預(yù)、尾部干預(yù)的綜合治理能力，保障業(yè)務(wù)運行穩(wěn)定；
• 豐富的能力擴展支持 : 為運營場景中復(fù)雜業(yè)務(wù)架構(gòu)提供 AiOps 異常檢測、混沌強弱依賴分析、全鏈路壓測（精準資源評估）等擴展能力；
• 多語言 SDK 支持 : 目前可支持 Golang、Python、C++、PHP、RUST、JS 多種開發(fā)語言；
• 穩(wěn)定性架構(gòu) : 支持多租戶管理與運營，支持主機與 K8S 環(huán)境部署，支持百億 PV 架構(gòu)，協(xié)助運營人員快速發(fā)現(xiàn)、定位、分析與解決問題，效率提升 5 倍+；
• 服務(wù)解耦&分級存儲 : 引入 Kafka/Pulsar 消息中間件做上下游解耦，極大擴展前后臺服務(wù)能力，便于集成數(shù)據(jù)應(yīng)用，且支持滿足不同應(yīng)用場景的分級存儲，支撐高峰上報 QPS300W/S 的運營能力，提供秒級數(shù)據(jù)處理能力。

3、平臺能力擴展

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

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

圖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)用時延等指標，可幫助用戶快速定位鏈路異常點和分析服務(wù)性能瓶頸點。同時平臺也提供了豐富的查詢條件來幫助業(yè)務(wù)快速檢索到所需鏈路數(shù)據(jù)，方便易用。

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

3.3 鏈路調(diào)用拓撲

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

圖5.5 -服務(wù)鏈路拓撲圖

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

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

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

4、平臺能力擴展

4.1 全鏈路的異常檢測

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

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

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

圖5.8 -異常檢測效果圖1

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

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

圖5.9 - 強弱依賴分析案例

六、混沌實驗平臺

1、混沌工程概述

在我們將應(yīng)用以云原生的方式上云之后，受益于云原生的 devops、K8S、微服務(wù)、服務(wù)網(wǎng)格等技術(shù)紅利，應(yīng)用的上線下線、發(fā)布變更、容量管理、服務(wù)治理等運營效率獲得了極大提升。海量的并發(fā)請求、敏捷的運營訴求驅(qū)動著應(yīng)用從單體服務(wù)向微服務(wù)、分布式系統(tǒng)演進。運營效率提升的同時也帶來了新的挑戰(zhàn)，主要表現(xià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ā)生時間可能是周末、半夜、團建時等。我們應(yīng)該致力于在這些異常故障被觸發(fā)之前，盡可能多地識別風險。然后，針對性地進行加固，防范，從而避免故障發(fā)生時所帶來的嚴重后果。混沌工程正是這樣一套通過在分布式系統(tǒng)上進行實驗，主動找出系統(tǒng)中的脆弱環(huán)節(jié)的方法學(xué)。混沌工程則是通過模擬現(xiàn)網(wǎng)真實故障來驗證服務(wù)的“韌性”，找出系統(tǒng)的弱點，同時驗證我們的監(jiān)控告警的有效性，在 MTBF 階段實施最好不過，是我們 SRE 保障的第二把利器。

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

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

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

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

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

• 故障注入場景豐富，玄圖混沌工程實驗平臺提供 27 種故障原子，覆蓋主機和 K8S 環(huán)境，并且支持自定義擴展；
• 靈活的實驗編排能力，平臺提供靈活的實驗編排能力，相對于手工腳本編排實驗，通過平臺執(zhí)行故障演練效率提升 10 倍；
• 實驗觀測&實驗報告閉環(huán)，玄圖混沌工程實驗平臺打通了監(jiān)控系統(tǒng)，實驗過程中可實時觀測實驗效果，實驗結(jié)束輸出實驗報告；
• 紅藍對抗常態(tài)化，平臺支持對抗演練記錄、歸檔，便于回溯、沉淀，增強趣味性和參與積極性；
• 可擴展架構(gòu)，平臺基于可擴展架構(gòu)設(shè)計，支持自定義故障原子，可靈活應(yīng)對復(fù)雜實驗需求；
• 通用性方面，玄圖混沌實驗平臺將公司內(nèi)部的藍鯨、奇點、北極星、網(wǎng)管系統(tǒng)等系統(tǒng)進行集成打通，實現(xiàn)所有業(yè)務(wù)都能開箱即用，無需額外的開發(fā)接入改造成本，實現(xiàn)了一站式服務(wù)。下面分別具體介紹下玄圖混沌實驗平臺具體能力體系。

3、平臺能力擴展

1）故障演練提效

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

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

2）故障注入原子

玄圖混沌平臺能夠模擬的故障非常豐富，通過故障原子組合可以模擬出云服務(wù)異常，機器故障，操作系統(tǒng)故障，網(wǎng)絡(luò)故障，應(yīng)用層故障，以及根據(jù)特定場景定制的故障等。很好的解決了傳統(tǒng)故障演練工具開發(fā)耗時久，工作重復(fù)，效果沒發(fā)精準控制，工具沒法復(fù)用等痛點。比如光纖中斷生產(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)芰?，比如我們需要驗證一臺機機器掛了對服務(wù)到底有何影響?？梢栽谄脚_上發(fā)起一個丟包 100%的實驗，理想情況下，1 分鐘內(nèi)能自動隔離異常機器，請求成功率會出現(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）紅藍對抗常態(tài)化

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

圖6.6 - 紅藍對抗流程圖

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

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

圖6.7 - 可擴展框架

七、全鏈路壓測+ 平臺

1、全鏈路壓測概述

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

• 節(jié)奏快，比如開黑節(jié)，戰(zhàn)斗之夜，周年慶，活動僅持續(xù)數(shù)日；
• 數(shù)量多，每天都會有大量活動上線，而且活動種類繁多；
• 訪問量大，游戲運營活動高峰時段日 PV 超過百億；
• 訪問量無法精準預(yù)估，很難精準的預(yù)測一次活動的訪問量，玩家參與度經(jīng)常超預(yù)期；
• 活動邏輯復(fù)雜，上下游依賴多，并且對依賴服務(wù)有 N 倍放大，容量評估工作量大。

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

• 活動上線節(jié)奏快，開發(fā)周期短，遇到性能問題需要快速定位解決；
• 微服務(wù)間調(diào)用關(guān)系復(fù)雜，性能問題排查困難，費時費力，難以快速診斷出瓶頸點；
• 調(diào)用拓撲鏈路不透明，需要耗費大量人力梳理調(diào)用關(guān)系和放大倍數(shù)；
• 已經(jīng)在線上運行的服務(wù)容量評估主要依據(jù)經(jīng)驗，重要活動通過大量堆機器支撐。

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

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

圖7.1 - QPS與資源負載曲線

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

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

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

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

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

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

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

3.平臺能力介紹

3.1 靈活的壓測編排

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

• 固定壓力模式：并發(fā)數(shù)固定，可以設(shè)置最大 QPS
• 階梯壓力模式：并發(fā)數(shù)持續(xù)增加，可以設(shè)置最大并發(fā)數(shù)和最大 QPS
• 快速壓測模式：并發(fā)數(shù)持續(xù)增加，達到指定錯誤率或耗時閾值后壓測自動停止

圖7.3 - 壓測編排

3.2 云原生架構(gòu)

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

圖7.4 - 壓力源負載指標

3.3 豐富的壓測指標

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

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

3.4 全鏈路拓撲圖

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

圖7.6 - 全鏈路拓撲圖

3.5 全鏈路統(tǒng)計

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

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

3.6 其它

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

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

SRE 體系的建設(shè)任重道遠，完全復(fù)制 Google SRE 方法顯然是行不通，個人認為原因有三個方面，第一點是以 Google SRE 崗位能力要求進行人才招聘，在國內(nèi)存在一定難度；第二點是 SRE 文化在國內(nèi)企業(yè)的認知與普及都不太夠；第三點受限于基礎(chǔ)設(shè)施即代碼、體系化的 SRE 工具鏈、服務(wù)標準及抽象等能力成熟度。另外，我們也面臨著諸多挑戰(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)定性保障也存在失控的風險。站在 SRE 的角度，任何一個細微環(huán)節(jié)的缺失與不足，都有可能影響 SLO 達標率。

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

— 本文結(jié)束 —

●?漫談設(shè)計模式在 Spring 框架中的良好實踐

●?顛覆微服務(wù)認知：深入思考微服務(wù)的七個主流觀點

●?人人都是 API 設(shè)計者

●?一文講透微服務(wù)下如何保證事務(wù)的一致性

●?要黑盒測試微服務(wù)內(nèi)部服務(wù)間調(diào)用，我該如何實現(xiàn)？

關(guān)注我，回復(fù) 「加群」 加入各種主題討論群。

對「服務(wù)端思維」有期待，請在文末點個在看

喜歡這篇文章，歡迎轉(zhuǎn)發(fā)、分享朋友圈

在看點這里