好看一区二区三区,日韩黄色a片免费观看,涩涩大香蕉,免费看一级一级人妻片,99成人视频免费观看,国产探花视频在线播放,久久久久久无码麻豆,日韩无码系列

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

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

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

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

一、前言

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

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

? SRE 能力全景

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

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

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

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

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

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

? 定制 SRE 準(zhǔn)則

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

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

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

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

[x] Volume（容量）服務(wù)承諾的最大容量是多少，比如常見(jiàn)的 QPS、TPS、會(huì)話數(shù)、吞吐量以及活動(dòng)連接數(shù)等等；
[x] Availablity（可用性）代表服務(wù)是否正常或穩(wěn)定，比如請(qǐng)求調(diào)用 HTTP 200 狀態(tài)的成功率、任務(wù)執(zhí)行成功率等；
[x] Latency（時(shí)延）服務(wù)響應(yīng)是否足夠快，比如時(shí)延是否符合正態(tài)分布，需指定不同的區(qū)間，比如常見(jiàn)的 P90、P95、P99 等；
[x] Error（錯(cuò)誤率）服務(wù)有多少錯(cuò)誤率，比如 5XX、4XX，以及自定義的狀態(tài)碼；
[x] Ticket（人工干預(yù)）是否需要人工干預(yù)，比如一些復(fù)雜故障場(chǎng)景，需人工介入來(lái)恢復(fù)服務(wù)。

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

圖3.1 - SLO跟蹤統(tǒng)計(jì)報(bào)表

四、工具鏈建設(shè)

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

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

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

五、可觀測(cè)性平臺(tái)

1、可觀測(cè)概括

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

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

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

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

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

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

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

?玄圖可觀測(cè)性平臺(tái)特點(diǎn)如下：

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

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

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

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

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

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

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

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

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

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

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

3.4 數(shù)據(jù)上報(bào)統(tǒng)計(jì)

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

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

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

4.1 全鏈路的異常檢測(cè)

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

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

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

圖5.8 -異常檢測(cè)效果圖1

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

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

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

六、混沌實(shí)驗(yàn)平臺(tái)

1、混沌工程概述

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

分布式系統(tǒng)日益龐大，很難評(píng)估單個(gè)故障對(duì)整個(gè)系統(tǒng)的影響；
服務(wù)間的依賴錯(cuò)綜復(fù)雜，單個(gè)服務(wù)不可用可能拖垮整個(gè)服務(wù)；
請(qǐng)求鏈路長(zhǎng)，全鏈路監(jiān)控告警、日志記錄等不完善，定位問(wèn)題難；
業(yè)務(wù)、技術(shù)迭代速度快，頻繁發(fā)布變更，使得系統(tǒng)的穩(wěn)定性受到更大的挑戰(zhàn)。

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

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

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

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

圖6.2 - 玄圖混沌工程實(shí)驗(yàn)平臺(tái)架構(gòu)圖

?具體平臺(tái)能力體系如下：

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

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

1）故障演練提效

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

圖6.3 - 精簡(jiǎn)流程，提升效率

2）故障注入原子

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

表6.1 - 玄圖混沌工程實(shí)驗(yàn)平臺(tái)支持原子

3）實(shí)驗(yàn)編排能力

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

圖6.4-實(shí)驗(yàn)編排

4）實(shí)驗(yàn)觀測(cè)報(bào)告

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

圖6.5 - 實(shí)驗(yàn)報(bào)告

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

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

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

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

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

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

七、全鏈路壓測(cè)+ 平臺(tái)

1、全鏈路壓測(cè)概述

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

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

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

活動(dòng)上線節(jié)奏快，開(kāi)發(fā)周期短，遇到性能問(wèn)題需要快速定位解決；
微服務(wù)間調(diào)用關(guān)系復(fù)雜，性能問(wèn)題排查困難，費(fèi)時(shí)費(fèi)力，難以快速診斷出瓶頸點(diǎn)；
調(diào)用拓?fù)滏溌凡煌该鳎枰馁M(fèi)大量人力梳理調(diào)用關(guān)系和放大倍數(shù)；
已經(jīng)在線上運(yùn)行的服務(wù)容量評(píng)估主要依據(jù)經(jīng)驗(yàn)，重要活動(dòng)通過(guò)大量堆機(jī)器支撐。

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

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

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

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

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

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

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

圖7.2 - 全鏈路壓測(cè)+ 平臺(tái)架構(gòu)圖

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

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

3.平臺(tái)能力介紹

3.1 靈活的壓測(cè)編排

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

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

圖7.3 - 壓測(cè)編排

3.2 云原生架構(gòu)

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

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

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

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

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

3.4 全鏈路拓?fù)鋱D

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

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

3.5 全鏈路統(tǒng)計(jì)

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

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

3.6 其它

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

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

SRE 體系的建設(shè)任重道遠(yuǎn)，完全復(fù)制 Google SRE 方法顯然是行不通，個(gè)人認(rèn)為原因有三個(gè)方面，第一點(diǎn)是以 Google SRE 崗位能力要求進(jìn)行人才招聘，在國(guó)內(nèi)存在一定難度；第二點(diǎn)是 SRE 文化在國(guó)內(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ù)雜度勢(shì)必會(huì)日益增大，但業(yè)務(wù)對(duì)穩(wěn)定性訴求是不變的。同時(shí)，云原生環(huán)境存在著大量的三方 PaaS 連接與集成，穩(wěn)定性保障也存在失控的風(fēng)險(xiǎn)。站在 SRE 的角度，任何一個(gè)細(xì)微環(huán)節(jié)的缺失與不足，都有可能影響 SLO 達(dá)標(biāo)率。

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

— 本文結(jié)束 —