作者：yorkoliu，騰訊 IEG 業務運維專家

一、前言

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

二、構建 SRE 體系

? SRE 能力全景

我們因地制宜，根據 IEG 海量在線營銷的業務場景，引入 SRE 度量的機制、定制 SRE 準則，以及打造較為完備的工具鏈體系，以下是團隊構建的玄圖-SRE 穩定性建設全景圖：

圖2.1 - 玄圖-SRE穩定性建設全景圖

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

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

• MTTI （Mean Time To ldentify）平均故障發現時間，強調團隊的監控告警能力的完備性；

• MTTA（Mean Time To Acknowledge）平均故障確認時間，強調團隊的 OnCall 機制執行，以及制度與技術的配套；

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

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

• MTTV （Mean Time To Verify）平均故障驗證時間，圍繞服務體驗為核心的監測體系，建立與業務、用戶的反饋機制。

這個環節作為穩定性保障的“事中”尤為重要，其中可觀測性作為下一代的質量監控的代表，通過強化分布式服務的日志、鏈路、指標的關聯，縮短發現問題、解決問題的時間，可以極大縮短 MTTR 中 MTTL 的耗時。

? 定制 SRE 準則

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

• 架構設計準則 - 我們認為所有的架構都是不完美的，都存在缺陷，因此我們在做業務架構設計時都必須要考慮服務穩定性保障，如負載均衡、多點容災、集群化服務、數據多活等能力；

• SRE 前置準則 - 在業務立項之初，SRE 角色需要提前介入，將運營階段可能出現的問題或風險提前在架構設計、編碼階段暴露，提前準備好解決方案，甚至規避問題與風險；

• 混沌實驗準則 - 故障不可避免，為何不讓其在測試或預發布環境提前到來，通過模擬現網真實故障來驗證服務的“韌性”，找出系統的弱點，同時驗證我們的監控告警的有效性，在 MTBF 階段實施最好不過，也是我們其中一把利器；

• 可觀測性準則 - 通過采集業務指標、日志、追蹤等數據，快速分析與定位問題，同時發現復雜系統的瓶頸點，在很長一段時間內，業務指標、日志、追蹤的采集與應用，都是獨立存在并分開建設，隨著時間的推移，發現這三者是相互關聯，相輔相成的，是我們的第二把利器；

• 全鏈路壓測準則 - 通過與可觀測性、混沌實驗能力的深度整合，實現模擬真實業務環境全鏈路壓測，達到業務上線前的精準資源評估，主動發現潛在性能、版本缺陷等問題，是我們的第三把利器；

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

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

• SRE 學習準則 - 營造學習的文化，目的是實現多個不同職能團隊的有機融合，相互了解大家面臨的問題或挑戰，形成一致的目標，達到有效的協同，解決業務的問題。團隊于 2016 年發起的《微分享》機制，截止目前累計 250 次分享 。

三、跟蹤 SLO 狀態

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

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

• [x] Availablity（可用性）代表服務是否正常或穩定，比如請求調用 HTTP 200 狀態的成功率、任務執行成功率等；

• [x] Latency（時延）服務響應是否足夠快，比如時延是否符合正態分布，需指定不同的區間，比如常見的 P90、P95、P99 等；

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

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

定義業務相對應 SLI 的 SLO 后，跟蹤 SLO 有利于穩定性目標的達成，時刻提醒還有多少錯誤預算可以供消費，是否應該調整版本發布的策略或節奏，更加聚焦人力在質量方面的優化。我們采用 SLO Tracker 來對接故障報單平臺，獲取故障單據、影響時長等信息，定期統計并做團隊反饋。

圖3.1 - SLO跟蹤統計報表

四、工具鏈建設

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

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

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

五、可觀測性平臺

1、可觀測概括

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

• 服務調用關系錯綜復雜，如何快速定位問題根因？

• 某服務發生異常，如何快速評估影響范圍？

• 如何快速分析復雜系統的服務瓶頸點？

• 服務追蹤、指標和日志分開上報，問題定位難度大?

• 活動發布頻繁，如何快速評估服務資源？

以上問題亟待建立全新的監控機制，幫助開發/運維人員全面洞察系統運行狀態，并在系統異常時幫助其快速定位解決問題，云原生可觀測性基礎設施應運而生。可觀測性則是通過采集業務指標、日志、追蹤等數據，快速分析與定位問題，同時發現復雜系統的瓶頸點，在很長一段時間內，業務指標、日志、追蹤的采集與應用，都是獨立存在并分開建設，隨著時間的推移，發現這三者是相互關聯，相輔相成的，是云原生 SRE 保障的一把利器。

圖5.1 -微服務調用關系圖

2、可觀測性架構

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

圖5.2 -玄圖可觀測性架構圖

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

• OneSDK 統一上報 : 遵循 OpenTelemetry 協議規范，集成指標、追蹤、日志能力-OneSDK，解決多節點上報時間誤差至微妙級；

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

• 豐富的能力擴展支持 : 為運營場景中復雜業務架構提供 AiOps 異常檢測、混沌強弱依賴分析、全鏈路壓測（精準資源評估）等擴展能力；

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

• 穩定性架構 : 支持多租戶管理與運營，支持主機與 K8S 環境部署，支持百億 PV 架構，協助運營人員快速發現、定位、分析與解決問題，效率提升 5 倍+；

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

3、平臺能力擴展

3.1 數據采集治理

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

圖5.3 -數據采集治理技術架構

3.2 鏈路數據檢索

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

圖5.4 - 服務鏈路追蹤檢索

3.3 鏈路調用拓撲

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

圖5.5 -服務鏈路拓撲圖

3.4 數據上報統計

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

圖5.6 - 服務數據上報統計

4、平臺能力擴展

4.1 全鏈路的異常檢測

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

圖5.7 - 服務異常檢測方案架構圖

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

圖5.8 -異常檢測效果圖1

4.2 調用強弱依賴分析

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

圖5.9 - 強弱依賴分析案例

六、混沌實驗平臺

1、混沌工程概述

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

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

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

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

• 業務、技術迭代速度快，頻繁發布變更，使得系統的穩定性受到更大的挑戰。

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

圖6.1 - 混沌工程的必要性（圖片來源網絡）

2、平臺技術架構

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

圖6.2 - 玄圖混沌工程實驗平臺架構圖

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

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

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

• 實驗觀測&實驗報告閉環，玄圖混沌工程實驗平臺打通了監控系統，實驗過程中可實時觀測實驗效果，實驗結束輸出實驗報告；

• 紅藍對抗常態化，平臺支持對抗演練記錄、歸檔，便于回溯、沉淀，增強趣味性和參與積極性；

• 可擴展架構，平臺基于可擴展架構設計，支持自定義故障原子，可靈活應對復雜實驗需求；

• 通用性方面，玄圖混沌實驗平臺將公司內部的藍鯨、奇點、北極星、網管系統等系統進行集成打通，實現所有業務都能開箱即用，無需額外的開發接入改造成本，實現了一站式服務。下面分別具體介紹下玄圖混沌實驗平臺具體能力體系。

3、平臺能力擴展

1）故障演練提效

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

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

2）故障注入原子

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

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

3）實驗編排能力

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

圖6.4-實驗編排

4）實驗觀測報告

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

圖6.5 - 實驗報告

5）紅藍對抗常態化

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

圖6.6 - 紅藍對抗流程圖

6）可擴展架構

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

圖6.7 - 可擴展框架

七、全鏈路壓測+ 平臺

1、全鏈路壓測概述

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

• 節奏快，比如開黑節，戰斗之夜，周年慶，活動僅持續數日；

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

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

• 訪問量無法精準預估，很難精準的預測一次活動的訪問量，玩家參與度經常超預期；

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

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

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

• 微服務間調用關系復雜，性能問題排查困難，費時費力，難以快速診斷出瓶頸點；

• 調用拓撲鏈路不透明，需要耗費大量人力梳理調用關系和放大倍數；

• 已經在線上運行的服務容量評估主要依據經驗，重要活動通過大量堆機器支撐。

為了解決以上難題，我們啟動了全鏈路壓測+平臺建設，通過在生產環境對業務大流量場景進行高仿真模擬，獲取最真實的線上實際承載能力、執行精準的容量規劃，目的在于保障系統可用性。

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

圖7.1 - QPS與資源負載曲線

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

2、全鏈路壓測架構

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

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

圖7.2 - 全鏈路壓測+ 平臺架構圖

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

總體而言，全鏈路壓測平臺不僅提供了傳統壓測基礎功能，如數據構造、請求撥測、壓測監控、壓測編排、發起壓力等。同時提供了壓測分析增值功能，如鏈路拓撲計算、鏈路統計、性能瓶頸定位、壓測流量染色、根因下鉆分析等。

3.平臺能力介紹

3.1 靈活的壓測編排

平臺支持靈活的發壓模式，包括：

• 固定壓力模式：并發數固定，可以設置最大 QPS

• 階梯壓力模式：并發數持續增加，可以設置最大并發數和最大 QPS

• 快速壓測模式：并發數持續增加，達到指定錯誤率或耗時閾值后壓測自動停止

圖7.3 - 壓測編排

3.2 云原生架構

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

圖7.4 - 壓力源負載指標

3.3 豐富的壓測指標

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

圖7.5 - 壓測指標監控

3.4 全鏈路拓撲圖

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

圖7.6 - 全鏈路拓撲圖

3.5 全鏈路統計

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

圖7.7 - 全鏈路指標統計

3.6 其它

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

八、思考與未來規劃

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

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

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

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。