今天會(huì)重點(diǎn)跟大家交流我們SRE團(tuán)隊(duì)轉(zhuǎn)型的背景和實(shí)施的路徑，以及分享我們SRE體系的框架和思路，也會(huì)提及個(gè)人的一些思考。整個(gè)框架思路我們并不是一開(kāi)始就設(shè)計(jì)出來(lái)的，而是面臨著諸多的問(wèn)題，圍繞著解決這些問(wèn)題一步一步演變過(guò)來(lái)的。

一、云原生運(yùn)維轉(zhuǎn)型之道

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

如果大家有玩過(guò)游戲的話，對(duì)這個(gè)界面應(yīng)該不陌生。我們團(tuán)隊(duì)主要負(fù)責(zé)騰訊內(nèi)部游戲營(yíng)銷活動(dòng)的運(yùn)維支撐，在線營(yíng)銷活動(dòng)除了為玩家提升游戲體驗(yàn)以外，也為游戲項(xiàng)目組在拉新、活躍，甚至是購(gòu)買道具，都提供相關(guān)的營(yíng)銷活動(dòng)、運(yùn)營(yíng)事件等商業(yè)化的支持。

2、微服務(wù)架構(gòu)

這是我們的一個(gè)技術(shù)架構(gòu)。從這個(gè)技術(shù)架構(gòu)里我們可以看出，云原生已經(jīng)變成一個(gè)大趨勢(shì)了，我們團(tuán)隊(duì)95%以上都實(shí)現(xiàn)了微服務(wù)化。微服務(wù)化改變了開(kāi)發(fā)的交付模式，同時(shí)也給運(yùn)維帶來(lái)了很大的變化，我個(gè)人的感受是挑戰(zhàn)大于變化。以下6點(diǎn)是我認(rèn)為現(xiàn)階段我們面臨的最大的挑戰(zhàn)：

1）微服務(wù)調(diào)用鏈錯(cuò)綜復(fù)雜，難于理解

尤其是一些大型活動(dòng)，需要多個(gè)團(tuán)隊(duì)協(xié)同開(kāi)發(fā)，會(huì)涉及到幾百個(gè)微服務(wù)化的相互調(diào)用，整個(gè)微服務(wù)拓?fù)浞浅｝嫶螅斫饪蚣艿碾y度加大。

2）追蹤、指標(biāo)、日志數(shù)據(jù)上報(bào)標(biāo)準(zhǔn)不一

每個(gè)團(tuán)隊(duì)都自建了不少監(jiān)控平臺(tái)或方案，這也是由于一些歷史遺留原因?qū)е隆?/span>

3）無(wú)法快速定位服務(wù)問(wèn)題以及根因

由于多個(gè)團(tuán)隊(duì)協(xié)同研發(fā)一個(gè)大型營(yíng)銷活動(dòng)，當(dāng)問(wèn)題發(fā)生時(shí)，需拉通整個(gè)項(xiàng)目鏈條涉及的所有開(kāi)發(fā)與運(yùn)維團(tuán)隊(duì)各自排查，每個(gè)團(tuán)隊(duì)根據(jù)自己構(gòu)建的指標(biāo)監(jiān)控體系逐步定位問(wèn)題，勢(shì)必會(huì)拉長(zhǎng)問(wèn)題整個(gè)的排查、解決的周期。

4）很難在上線前發(fā)現(xiàn)服務(wù)性能瓶頸點(diǎn)

問(wèn)題的發(fā)現(xiàn)與處理相對(duì)滯后，通常是上線之后才發(fā)現(xiàn)服務(wù)被打爆，如計(jì)算資源不足、存儲(chǔ)節(jié)點(diǎn)IO過(guò)高、調(diào)用下游接口延時(shí)過(guò)大等一系列問(wèn)題。

5）無(wú)法判斷節(jié)點(diǎn)間強(qiáng)弱依賴關(guān)系

比如A模塊訪問(wèn)B模塊，當(dāng)B模塊出現(xiàn)異常，給主調(diào)方A模塊造成了影響，但是無(wú)法判斷影響面到底有多大？

6）新上線業(yè)務(wù)容量評(píng)估無(wú)法精準(zhǔn)計(jì)算

業(yè)務(wù)上線時(shí)我們無(wú)法判斷應(yīng)該給予多大的服務(wù)容量，通常產(chǎn)品運(yùn)營(yíng)策劃為了穩(wěn)妥起見(jiàn)報(bào)得虛高，導(dǎo)致運(yùn)營(yíng)成本也會(huì)被同等拉高。

3、環(huán)境的改變

前面提到我們面臨的幾大問(wèn)題，接下來(lái)講講大環(huán)境的改變：騰訊2018年930變革后，公司明確了內(nèi)部業(yè)務(wù)自研上云，歷經(jīng)4年多，團(tuán)隊(duì)面臨兩個(gè)較大的變化：

第一是作為公司內(nèi)部第一批上云的團(tuán)隊(duì)，我們已經(jīng)完成95%的流量切云，在云原生的環(huán)境下，運(yùn)維的模式也發(fā)生了改變，與以往傳統(tǒng)運(yùn)維模式的區(qū)別具體表現(xiàn)在以下6點(diǎn)：

1）資源→資產(chǎn)

在傳統(tǒng)的資源管理中，我們通常把一個(gè)設(shè)備的IP、性能配置、設(shè)備責(zé)任人等元數(shù)據(jù)信息記錄在CMDB里，但到云端的資產(chǎn)化的模式下，它的范圍和邊界被擴(kuò)大了，不僅僅是單臺(tái)設(shè)備的信息，它可以是負(fù)載均衡器、MySQL實(shí)例、也可能是一個(gè)云上任一PaaS服務(wù)，我們都把它當(dāng)成資產(chǎn)來(lái)看待與治理。

2）單體→微服務(wù)

單體服務(wù)微服務(wù)化，讓服務(wù)的治理更加精細(xì)化。

3）管理→治理

我認(rèn)為管理是一維的，治理是多維多元的，模式上發(fā)生了很大的改革。

4）事件驅(qū)動(dòng)→流水線

以前通常是開(kāi)發(fā)提交一個(gè)變更單，運(yùn)維跟進(jìn)并發(fā)起變更，出現(xiàn)異常則快速回滾。而在DevOps流水線之后，處處實(shí)現(xiàn)了自動(dòng)化，讓誰(shuí)開(kāi)發(fā)誰(shuí)運(yùn)維的理念得以實(shí)現(xiàn)，開(kāi)發(fā)可以隨意發(fā)起變更，一項(xiàng)目一天可能會(huì)發(fā)起幾十次的變更任務(wù)，非常高效，而不再由事件去驅(qū)動(dòng)。

5）DO分離→DO融合

以前開(kāi)發(fā)和運(yùn)維互不干涉，因?yàn)橛小皦Α钡谋Ｗo(hù)，也不需要給彼此背鍋，在云原生的背景下，我們要求開(kāi)發(fā)和運(yùn)維要盡可能地融合，也是遵循了DevOps的思想。

6）業(yè)務(wù)運(yùn)維→SRE

對(duì)傳統(tǒng)業(yè)務(wù)運(yùn)維的能力也提出了更高的要求，除了具備基礎(chǔ)運(yùn)維能力外，還需拓展包括對(duì)業(yè)務(wù)的理解、工具研發(fā)、數(shù)據(jù)分析、甚至是AIOps等能力，這也是我們所理解的SRE。

第二個(gè)變化是業(yè)務(wù)研發(fā)在整個(gè)云原生浪潮中的蛻變，包括采用云原生架構(gòu)來(lái)實(shí)現(xiàn)版本的交付，基于一站式的DevOps平臺(tái)，打通了研發(fā)線全生命周期管理，貫穿服務(wù)在開(kāi)發(fā)、編譯、構(gòu)建、部署等全流程，實(shí)現(xiàn)服務(wù)交付的全閉環(huán)。除此之外，還會(huì)涉及版本所需的質(zhì)量監(jiān)控、配置與容量管理、日志檢索等研發(fā)剛需功能，能力非常全面完整。

4、觸發(fā)轉(zhuǎn)型

從前面的提到的兩大變化，作為運(yùn)維團(tuán)隊(duì)的負(fù)責(zé)人，客觀而言對(duì)我與團(tuán)隊(duì)帶來(lái)的沖擊還是非常大的，因?yàn)槲覀兊谝慌隍v訊內(nèi)部完成自研上云，當(dāng)前98%的業(yè)務(wù)已經(jīng)在云端跑，在這個(gè)過(guò)程中，我發(fā)現(xiàn)過(guò)去我們構(gòu)建非常完備的傳統(tǒng)運(yùn)維能力，很大一部分已經(jīng)不適用，包括業(yè)務(wù)版本的發(fā)布、變更、配置管理、流量調(diào)度、監(jiān)控模式等等；可以看出運(yùn)維的職能跟價(jià)值很大一部分被稀釋了，具體體現(xiàn)在上云后系統(tǒng)運(yùn)維的職能，基礎(chǔ)設(shè)施管理、平臺(tái)Paas服務(wù)的維護(hù)等等；也逼得我們必須做轉(zhuǎn)型，也就是蛻變成云原生SRE，下面會(huì)重點(diǎn)提到為什么做這個(gè)選型，總結(jié)起來(lái)就是更加貼近業(yè)務(wù)、理解業(yè)務(wù)，實(shí)施高可靠性保障、提升用戶體驗(yàn)，做更加專業(yè)的運(yùn)維，如智能運(yùn)維。

那么應(yīng)該如何轉(zhuǎn)型，以及轉(zhuǎn)型之后要做什么事情，就是接下來(lái)我們要去思考和實(shí)踐的。我大概在2015～2016年開(kāi)始接觸SRE，也了解到SRE的一些思想和具體的實(shí)踐，在國(guó)內(nèi)應(yīng)該算是比較早的一批，2020年我們就完成全部業(yè)務(wù)上云，在這個(gè)階段我發(fā)現(xiàn)SRE的思想與我們面臨的困惑很契合，反復(fù)琢磨，不少思路確實(shí)能夠解決我們很多問(wèn)題，因此確定SRE是我們轉(zhuǎn)型的方向。

以下是個(gè)人總結(jié)未來(lái)運(yùn)維職能演變及轉(zhuǎn)型的路徑。隨著云原生技術(shù)和架構(gòu)的不斷成熟，勢(shì)必會(huì)帶動(dòng)IaaS、PaaS和DevOps的生態(tài)圈，往成熟度方向發(fā)展。但這幾個(gè)方向的發(fā)展勢(shì)必會(huì)對(duì)傳統(tǒng)運(yùn)維，包括系統(tǒng)運(yùn)維、平臺(tái)運(yùn)維和業(yè)務(wù)運(yùn)維產(chǎn)生很大的沖擊，這三個(gè)崗位會(huì)被弱化，即使沒(méi)有被弱化，一定程度上大部分職能也會(huì)轉(zhuǎn)嫁給運(yùn)維外包或業(yè)務(wù)研發(fā)身上。在這樣的一個(gè)背景之下，我們運(yùn)維要如何自救？

我這里給出了一個(gè)轉(zhuǎn)型的路徑，個(gè)人判斷總共會(huì)經(jīng)歷三個(gè)階段：

1）第一個(gè)階段：CloudOps（云端運(yùn)維）

云端運(yùn)維實(shí)際上與傳統(tǒng)運(yùn)維沒(méi)有太大區(qū)別，只是把傳統(tǒng)運(yùn)維搬到云上，也負(fù)責(zé)云端的資產(chǎn)的采購(gòu)、環(huán)境的部署，以及日常的運(yùn)營(yíng)跟運(yùn)維，同時(shí)也會(huì)關(guān)注成本，比如FinOps就是要關(guān)注云端的成本。

2）第二個(gè)階段：SRE

在SRE里會(huì)保留兩種職能：

• 一是資深運(yùn)維，最專業(yè)的和能力較強(qiáng)的運(yùn)維職能會(huì)被留下來(lái)。
• 二是工具開(kāi)發(fā)，很大一部分運(yùn)維做轉(zhuǎn)型時(shí)，具備一定開(kāi)發(fā)能力的運(yùn)維會(huì)轉(zhuǎn)至SRE工具研發(fā)的職能上來(lái)。

3）第三個(gè)階段：ServiceOps（運(yùn)維服務(wù)化）

在這個(gè)階段，會(huì)把更加專業(yè)的運(yùn)維能力打包成服務(wù)，交付給企業(yè)內(nèi)部的其他職能團(tuán)隊(duì)，專業(yè)性服務(wù)包含了SRE即服務(wù)，安全即服務(wù)，數(shù)據(jù)即服務(wù)等，而且這些平臺(tái)或服務(wù)都帶有一定智能化屬性，這是最基本的要求。

然后在企業(yè)內(nèi)部跨團(tuán)隊(duì)地實(shí)施賦能，比如會(huì)給研發(fā)團(tuán)隊(duì)、測(cè)試團(tuán)隊(duì)，甚至是財(cái)務(wù)團(tuán)隊(duì)做增值賦能，我判斷不少企業(yè)會(huì)在3～5年內(nèi)陸續(xù)進(jìn)入這個(gè)周期。???

5、目標(biāo)設(shè)定

前面提到運(yùn)維轉(zhuǎn)型的路徑，可以看出目前我們處于第二階段，即云原生SRE，我們給自己設(shè)定了幾個(gè)核心目標(biāo)，在團(tuán)隊(duì)的規(guī)劃里，我要求把以下5點(diǎn)做好即可：

1）具備服務(wù)全鏈路質(zhì)量覆蓋，定義可量化的SLI與SLO，不能出現(xiàn)任何一個(gè)盲點(diǎn)。

2）提升 MTBF（平均故障時(shí)間間隔）、降低 MTTR（故障平均修復(fù)時(shí)間）

3）DevOps升級(jí)至DevSecOps，關(guān)注云成本(FinOps)

4）具備多云多級(jí)的資產(chǎn)編排與治理的能力

• 一是能夠提升效率；
• 二是讓交付更加標(biāo)準(zhǔn)化，比如業(yè)務(wù)出海，可以快速?gòu)?fù)用國(guó)內(nèi)的交付能力，這些能力可以沉淀在各種編排模板、腳本，并且可以結(jié)合版本管理來(lái)追蹤變化的明細(xì)。

5）具備一定的故障預(yù)警、根因分析、問(wèn)題定位能力

通過(guò)智能化的水平提升我們質(zhì)量方面能力的要求。

提煉中心思想就是云端一切皆可編排，加上我們“三位一體”的可靠性保障體系，這兩個(gè)方向構(gòu)成了我們第一期的整體目標(biāo)。

6、SRE 8 準(zhǔn)則

有了目標(biāo)之后，我們還需要一些指導(dǎo)的原則，告訴我們應(yīng)該怎么做。這里我也提煉總結(jié)出了8點(diǎn)，我們內(nèi)部叫SRE 8 準(zhǔn)則，今天我會(huì)重點(diǎn)把核心三點(diǎn)（藍(lán)色框）提出來(lái)講，其它更多準(zhǔn)則說(shuō)明可以掃描右下角的二維碼查看。

二、SRE工具鏈建設(shè)思路

1、SRE體系全景

這是我們第一期的能力全景圖，SRE能力主要集中在中間這層，包括了多級(jí)事件編排，MTBF及MTTR這三大塊能力，內(nèi)部我們把它稱為“玄圖SRE”體系，具體說(shuō)明：

1）事件編排

• 事件編排的最底層要求是多云支持，因?yàn)槲覀兊臉I(yè)務(wù)是跨云的，很多業(yè)務(wù)部署在北美、東南亞，所以我們要求跨云支持編排。
• 資產(chǎn)編排要求我們能夠跨云實(shí)現(xiàn)資產(chǎn)的交付和自動(dòng)化。
• 容器編排主要是k8s workflow這套機(jī)制。
• 作業(yè)編排就是任務(wù)編排，針對(duì)某個(gè)容器、虛擬機(jī)或云主機(jī)進(jìn)行一系列功能性操作。

2）MTBF

即平均故障時(shí)間間隔，如何提升MTBF？

針對(duì)MTBF，我們希望是越長(zhǎng)越好，要達(dá)到這個(gè)目標(biāo)，以往我們?cè)跇I(yè)務(wù)上線之前，這部分前置工作做得很少，通常是等發(fā)生問(wèn)題后才被動(dòng)地去做定位，所以我們盡可能地把很多能力前置，根據(jù)當(dāng)前我們面臨的實(shí)際情況，我們認(rèn)為現(xiàn)階段混沌實(shí)驗(yàn)&全鏈路壓測(cè)是首要建設(shè)的能力。

3）MTTR

即故障平均修復(fù)時(shí)間，如何降低MTTR？

MTTR追求的目標(biāo)當(dāng)然是越短越好，這里我們拆解成了故障的發(fā)現(xiàn)、響應(yīng)、定位、解決及驗(yàn)證五個(gè)環(huán)節(jié)，同時(shí)分析了團(tuán)隊(duì)過(guò)去一年上百個(gè)故障案例，發(fā)現(xiàn)導(dǎo)致MTTR被拉長(zhǎng)最多的環(huán)節(jié)是故障定位上，因此，現(xiàn)階段我們集中精力放在這個(gè)環(huán)節(jié)上做文章，這也是我們著重建設(shè)可觀測(cè)性能力的緣由。???

2、底層組織邏輯

接下來(lái)講一講我們實(shí)現(xiàn)這些能力的底層邏輯。

首先說(shuō)明最底層部分，我們會(huì)定義SRE里面的標(biāo)準(zhǔn)規(guī)范、方法與目標(biāo)，相當(dāng)于我們?cè)谧龊蒙蠈悠脚_(tái)化之前，首先要把整個(gè)理論體系的底座梳理清楚，平臺(tái)化只是將這套理論體系的實(shí)例化。

中間層的平臺(tái)化，大家看到的可能是三個(gè)獨(dú)立的平臺(tái)能力，但我們把它看成一個(gè)整體，相當(dāng)于把這三個(gè)能力當(dāng)成一個(gè)能力體系來(lái)建設(shè)。因?yàn)槲覀冊(cè)趯?shí)踐的過(guò)程中發(fā)現(xiàn)，三個(gè)不同能力的任意組合都可以延伸出不同的玩法：

• 可觀測(cè)性+全鏈路壓測(cè)，能夠做資源的精準(zhǔn)評(píng)估。
• 可觀測(cè)性+混沌實(shí)驗(yàn)，能夠做強(qiáng)弱依賴分析。
• 全鏈路壓測(cè)可以作為混沌實(shí)驗(yàn)壓測(cè)的原子。

因此可觀測(cè)性、混沌實(shí)驗(yàn)和全鏈路壓測(cè)三者并不是割裂和獨(dú)立存在的，而是一個(gè)整體，它們之間可以相互發(fā)生關(guān)系，能夠產(chǎn)生一些我們意想不到的應(yīng)用場(chǎng)景，還有很多有意思的點(diǎn)等待著我們?nèi)ネ诰颉?/span>

三、SRE工具鏈建設(shè)實(shí)踐

1、可觀測(cè)性實(shí)踐

接下來(lái)我們講的第一個(gè)應(yīng)用是可觀測(cè)性，舉一個(gè)很簡(jiǎn)單的例子，就是我們運(yùn)維經(jīng)常碰到處理故障的一個(gè)典型過(guò)程。通常我們收到告警，第一步肯定是要去看Dashboard里是哪個(gè)曲線和圖表出現(xiàn)了明顯的異常，然后找出某個(gè)時(shí)間段異常發(fā)生的具體表現(xiàn)，是否有周期性，是哪個(gè)指標(biāo)發(fā)生了異常，再切換到下一步鏈路追蹤，分解出這個(gè)時(shí)間段，某個(gè)接口和方法是否延遲拉高了或報(bào)錯(cuò)了，通過(guò)追蹤的方式定位。最后一步則是通過(guò)日志分析導(dǎo)致這個(gè)函數(shù)方法出現(xiàn)異常的根因，定位出來(lái)后即可解決這個(gè)問(wèn)題。作為一個(gè)普通運(yùn)維人員，經(jīng)常按這個(gè)套路去定位與解決某個(gè)問(wèn)題，在整個(gè)過(guò)程當(dāng)中用到了指標(biāo)、日志和追蹤三個(gè)能力，實(shí)際上這三個(gè)能力就構(gòu)成了可觀測(cè)性的三大支柱。

• 指標(biāo)：提供服務(wù)性能、業(yè)務(wù)及運(yùn)營(yíng)等指標(biāo)，用于異常告警及可視化報(bào)表。
• 追蹤：分布式鏈路跟蹤，記錄請(qǐng)求跟蹤路徑，用于定位到具體服務(wù)或方法。
• 日志：服務(wù)日志，提供精確全面的系統(tǒng)記錄，用于最終定位問(wèn)題根源。

很多團(tuán)隊(duì)將這三個(gè)能力分開(kāi)建設(shè)，比如指標(biāo)通常是搭建一個(gè)Prometheus采集指標(biāo)，日志則搭建一些日志采取的組件，到ELK里進(jìn)行檢索，追蹤則用Skywalking或Jaeger之類的工具搭建，再檢索整條鏈路拓?fù)涞?。但是可觀測(cè)性要求將這三者融合，即通過(guò)一定的符號(hào)、特定的ID，把這三種能力串聯(lián)起來(lái)變成一個(gè)整體，這是可觀測(cè)性追求的目標(biāo)。

1）系統(tǒng)架構(gòu)

這是我們的可觀測(cè)性體系技術(shù)架構(gòu)，這個(gè)架構(gòu)可能與其他行業(yè)方案存在一定差異，共同點(diǎn)是我們也基于Opentelemetry完成業(yè)務(wù)端、采集、上報(bào)、傳輸、計(jì)算、存儲(chǔ)和應(yīng)用等一系列過(guò)程，但是我們會(huì)重點(diǎn)聚焦在綜合治理，后面也會(huì)提到我們會(huì)支持很多治理的能力，因?yàn)槲艺J(rèn)為任何一種服務(wù)都需要實(shí)施治理，缺乏治理則無(wú)法很好地使用及發(fā)揮它的效能。

2）平臺(tái)能力

接下來(lái)是我們的一些平臺(tái)能力，有基礎(chǔ)能力，也有我們認(rèn)為比較滿意的一些高級(jí)能力。

• 綜合管控治理

我們當(dāng)前服務(wù)的日PV是7000多億，如果我們?nèi)可蠄?bào)，可能與業(yè)務(wù)訪問(wèn)的流量是1:1的，甚至更大，我們最終目的是通過(guò)可觀測(cè)性的手段來(lái)提升高可靠性，但是如果它帶來(lái)的額外的成本抵消了我們帶來(lái)的價(jià)值，那么就不合理了。所以我們會(huì)做一些管控，如一定比例的采樣，同時(shí)我們也會(huì)做一些運(yùn)營(yíng)干預(yù)，比如當(dāng)流量達(dá)到一定頂峰時(shí)，如果此時(shí)仍然大量開(kāi)啟采集數(shù)據(jù)可能會(huì)對(duì)業(yè)務(wù)造成很大影響，因此需要采取熔斷機(jī)制來(lái)干預(yù)確保業(yè)務(wù)服務(wù)穩(wěn)定運(yùn)營(yíng)。

• ONE-SDK

我們把指標(biāo)、追蹤、日志這三者集成到某個(gè)SDK里做上報(bào)。目前Opentelemetry的官網(wǎng)里也只是定了規(guī)范，還沒(méi)有完全地實(shí)現(xiàn)三者能力的集成上報(bào)，局部的開(kāi)發(fā)語(yǔ)言SDK可能已經(jīng)支持了，比如Golang，更多的還是處于內(nèi)部聯(lián)調(diào)和測(cè)試的階段。

• 提升采集ROI

我們會(huì)開(kāi)啟采集的管控，當(dāng)出現(xiàn)極端情況時(shí)，我們只采集有價(jià)值的數(shù)據(jù)，比如只采集異常的數(shù)據(jù)，其它的統(tǒng)統(tǒng)不采，因?yàn)楫a(chǎn)生異常的數(shù)據(jù)可能占比不到1%，量是很小的。

3）綜合治理

我們的綜合治理分為采樣治理和運(yùn)營(yíng)治理。

①采樣治理

• 頭部采樣：在入口開(kāi)啟采樣，只采樣自定義的比例，如2%或10%。
• 尾部采樣：數(shù)據(jù)會(huì)先全量上報(bào)，通過(guò)緩沖池緩存數(shù)據(jù)，再異常處理，過(guò)濾出有異常的數(shù)據(jù)后入庫(kù)。
• 數(shù)據(jù)冷熱分離：考慮到后端高昂的存儲(chǔ)成本，我們做了分級(jí)（三級(jí)），比較熱的數(shù)據(jù)存放在ES里，超過(guò)一周的數(shù)據(jù)周期我們采用Clickhouse作為二級(jí)存儲(chǔ)，存儲(chǔ)一個(gè)月以上的數(shù)據(jù)我們存放到離線數(shù)倉(cāng)中，那么成本就越來(lái)越低。

②運(yùn)營(yíng)治理

更多是一些數(shù)據(jù)采集干預(yù)方面的手段，比如熔斷、降級(jí)、限速和染色。

染色即為打特定的標(biāo)簽，定義染色數(shù)據(jù)上報(bào)規(guī)則。比如我只關(guān)注某個(gè)玩家的登陸，那么把玩家的ID打進(jìn)去，它只采集該玩家的整個(gè)生命周期產(chǎn)生的日志，其它統(tǒng)統(tǒng)不采。

下面介紹我們?nèi)绾螌?shí)現(xiàn)綜合治理，我們利用了OpenTelemetry的Collector來(lái)實(shí)現(xiàn)，Collector內(nèi)部有 4 個(gè)核心組件：

• Receivers：負(fù)責(zé)接收不同格式的觀測(cè)數(shù)據(jù)，包括Zipkin、Jaeger、OpenCensus 以及Opentelemetry格式。
• Processors：負(fù)責(zé)實(shí)施處理邏輯，如打包、過(guò)濾、修飾、采樣等等。
• Exporters：負(fù)責(zé)將處理后的觀測(cè)數(shù)據(jù)按指定的格式重新輸出到后端服務(wù)中。
• Extensions：以旁路的模式來(lái)作為Collector本身健康心跳探測(cè)等。

利用這些組件組裝出一個(gè)或多個(gè) Pipelines，我們這里分別組裝了Agent和Collector兩個(gè)角色，Agent主要用于接收上報(bào)的信息，在processor中使用了比較多的像頭部采樣、熔斷、降級(jí)、限速、染色等處理，將處理后再將數(shù)據(jù)寫到kafka中；數(shù)據(jù)被后臺(tái)的Collector消費(fèi)后，我們?cè)赾ollector中則實(shí)現(xiàn)了尾部采樣、自動(dòng)補(bǔ)鏈等邏輯。

4）異常檢測(cè)

當(dāng)我們采集大量的數(shù)據(jù)之后檢測(cè)出異常點(diǎn)，此時(shí)需要定義告警，很多情況下會(huì)出現(xiàn)如指標(biāo)毛刺等帶有故障特征但實(shí)際上卻不是故障的情況，為了減少誤告，我們結(jié)合AIOps的技術(shù)做了一些探索，目前也取得了一定成效，具體的思路如下：

我們采集最新幾分鐘的Trace與Metric的數(shù)據(jù)，通過(guò)訓(xùn)練好的模型去推理異常權(quán)重，識(shí)別出的異常Trace再通過(guò)告警發(fā)出，由此可以看出我們的特征模型非常重要，那么如何確保這個(gè)模型的準(zhǔn)確性？有一個(gè)方案可供大家借鑒，我們分為兩個(gè)階段來(lái)實(shí)施：

第一階段是測(cè)試階段，結(jié)合壓測(cè)與混沌能力，在源頭做流量壓測(cè)及混沌實(shí)驗(yàn)，我們通過(guò)模擬CPU爆滿、流量異?；騺G包等等已知的故障原子，再結(jié)合壓測(cè)的手段，觀察服務(wù)表現(xiàn)出來(lái)的各類指標(biāo)數(shù)據(jù)，這就是我們想要的特征，通過(guò)平臺(tái)自動(dòng)化給特征打標(biāo)簽，可以釋放大量人力參與此類工作。

但是再完備的測(cè)試環(huán)境也無(wú)法模擬線上所有問(wèn)題，比如一些未知的問(wèn)題我們歷史上從未碰到過(guò)。所以會(huì)在第二階段（即將上線），我們會(huì)去采集現(xiàn)網(wǎng)真實(shí)的數(shù)據(jù)做驗(yàn)證，不斷地?cái)U(kuò)充跟修正特征模型，使模型越來(lái)越精準(zhǔn)，但是生產(chǎn)環(huán)境時(shí)則不可避免地需要依賴人工去打標(biāo)簽。

我們采用的是Matrix Profile的算法，在此之前我們也盤點(diǎn)了行業(yè)內(nèi)十幾個(gè)針對(duì)Trace的異常檢測(cè)算法，從推理速度、準(zhǔn)確性和參數(shù)調(diào)整的變異性等維度進(jìn)行選型，我們發(fā)現(xiàn)Matrix Profile這個(gè)算法是最接近我們需求的。Matrix Profile 的值表示子序列間的距離，距離越小的表示序列相似度高，而距離越大表示越異常，異常則對(duì)接我們的告警，我們當(dāng)前這套的準(zhǔn)確性能夠達(dá)到大約83%。

2、混沌工程實(shí)踐

混沌實(shí)驗(yàn)不少企業(yè)都已經(jīng)在引入并積極建設(shè)，更多是通過(guò)模擬真實(shí)現(xiàn)網(wǎng)的故障注入，發(fā)現(xiàn)服務(wù)是否存在異?；蛉觞c(diǎn)，但我個(gè)人覺(jué)得它的好處不僅限于此，對(duì)于SRE而言，它的價(jià)值在于一句古話說(shuō)的：平時(shí)多流汗，戰(zhàn)時(shí)少流血。我們平時(shí)模擬了大量的故障案例，在真正面臨故障時(shí)則能夠坦然面對(duì)，心里不會(huì)慌，包括在預(yù)防、發(fā)現(xiàn)、響應(yīng)、定位方面都給我們積累了大量的經(jīng)驗(yàn)，使我們能夠快速處理和解決問(wèn)題，我認(rèn)為混沌的意義應(yīng)該在于此。

1）平臺(tái)架構(gòu)

這是我們的整體架構(gòu)，這部分我們跟社區(qū)合作的比較多，比如PingCAP的Chaos Mesh，我們也參與了共建，所以很多原子是開(kāi)放的，平臺(tái)能力也很成熟，基本上用于做一些能力的封裝，比如上面的編排、演練、模板，官方也帶了一個(gè)簡(jiǎn)單的管理端，如果要求不高可以直接用。

2）平臺(tái)能力

這是我們的平臺(tái)能力，分為基礎(chǔ)和高級(jí)。我們平時(shí)做得最多的是紅藍(lán)對(duì)抗，紅藍(lán)對(duì)抗就是通過(guò)攻防不斷驗(yàn)證可靠性是否達(dá)到要求，達(dá)不到則持續(xù)修改迭代，發(fā)布過(guò)后再進(jìn)入下一輪攻防，還是比較有趣的，同時(shí)可以做一些依賴分析等能力。

我認(rèn)為服務(wù)強(qiáng)弱依賴分析是很有價(jià)值的，可以輕松感知如A調(diào)B服務(wù)，B出現(xiàn)問(wèn)題對(duì)A是否造成影響，我們分為三步來(lái)實(shí)施：

• 首先，基于可觀測(cè)性技術(shù)，追蹤到服務(wù)間的上下游依賴關(guān)系。
• 然后，對(duì)下游服務(wù)注入故障，如丟包、超時(shí)、響應(yīng)慢等。
• 最后，觀察主調(diào)方的穩(wěn)態(tài)指標(biāo)，如QPS、延時(shí)是否受影響，如果受影響則存在強(qiáng)弱依賴關(guān)系，從而要求開(kāi)發(fā)進(jìn)行改造，比如在主調(diào)方做一些訪問(wèn)DB的緩存等策略，達(dá)到要求后才能夠上線。

3、全鏈路壓測(cè)實(shí)踐

最后一個(gè)是全鏈路壓測(cè)，我認(rèn)為它的意義主要是兩點(diǎn)：

• 一是能夠發(fā)現(xiàn)上線之后的性能瓶頸點(diǎn)，因?yàn)閷?dǎo)致性能瓶頸的因素很多，如環(huán)境、參數(shù)配置不當(dāng)、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)等，逐個(gè)排查成本過(guò)高，可以通過(guò)壓測(cè)發(fā)現(xiàn)。
• 二是重大節(jié)點(diǎn)的運(yùn)營(yíng)保障，容量與負(fù)載沒(méi)有線性關(guān)系，無(wú)法精準(zhǔn)判斷容量夠不夠，壓測(cè)一下便知道。

1）平臺(tái)架構(gòu)

這是我們壓測(cè)的架構(gòu)，與傳統(tǒng)的壓測(cè)不同在于：傳統(tǒng)的壓測(cè)只是制造壓力源，但是當(dāng)被壓服務(wù)出現(xiàn)問(wèn)題時(shí)，無(wú)法定位具體是哪個(gè)接口、方法、調(diào)用出現(xiàn)了問(wèn)題，因?yàn)楸粔悍?wù)對(duì)于壓測(cè)平臺(tái)是一個(gè)黑盒子，需要研發(fā)自己去定位，這是傳統(tǒng)壓測(cè)面臨的問(wèn)題。我們的方案兼容傳統(tǒng)的壓測(cè)能力，即流量壓力的制造，同時(shí)結(jié)合可觀測(cè)性能力，將整個(gè)拓?fù)淅锼协h(huán)節(jié)中的每一條鏈路、每個(gè)接口、方法和函數(shù)出現(xiàn)的性能瓶頸，我們都能夠快速定位并告警，開(kāi)發(fā)進(jìn)一步跟進(jìn)，從而快速定位出具體的性能瓶頸點(diǎn)，并且具備針對(duì)異常做根因下鉆分析等能力。

2）平臺(tái)能力

3）服務(wù)壓測(cè)鏈路拓?fù)?/strong>

接下來(lái)我想講全鏈路壓測(cè)其中的一個(gè)應(yīng)用，即服務(wù)壓測(cè)鏈路拓?fù)?。我們?cè)谠搭^施壓，平臺(tái)能夠完整地呈現(xiàn)整個(gè)觀測(cè)鏈路，展示微服務(wù)間的調(diào)用關(guān)系鏈，同時(shí)能夠?qū)崟r(shí)計(jì)算出每一層微服務(wù)黃金指標(biāo)，即A調(diào)用B的耗時(shí)、QPS、延遲、放大倍數(shù)等都能計(jì)算出來(lái)。

放大倍數(shù)能夠用于服務(wù)上線前的資源評(píng)估，比如鏈路中的某個(gè)節(jié)點(diǎn)B，它被放大了5倍，那么就可以得知存量是20000核的資源需要做5倍+的擴(kuò)容，才能滿足未來(lái)版本上線時(shí)的資源需求。

4、總結(jié)

最后總結(jié)SRE實(shí)踐里的幾個(gè)過(guò)程。我們從立項(xiàng)到結(jié)項(xiàng)，通過(guò)技術(shù)與文化兩個(gè)層面落地。

1）立項(xiàng)：我們會(huì)組建一個(gè)FT的臨時(shí)團(tuán)隊(duì)，團(tuán)隊(duì)里有運(yùn)維、開(kāi)發(fā)、測(cè)試、產(chǎn)品等，運(yùn)維也會(huì)參加技術(shù)方案的討論，同時(shí)定制可觀測(cè)性上報(bào)的規(guī)范。

2）開(kāi)發(fā)：開(kāi)發(fā)需要落實(shí)運(yùn)維制定的規(guī)范，做好指標(biāo)埋點(diǎn)的上報(bào)，同時(shí)SRE會(huì)參與技術(shù)架構(gòu)的評(píng)審。

3）測(cè)試：我們會(huì)在這個(gè)階段大量地做混沌實(shí)驗(yàn)和全鏈路壓測(cè)。

4）上線：更多關(guān)注SLI、SLO等指標(biāo)和它的錯(cuò)誤預(yù)算，以及OnCall的機(jī)制是否完備，提前準(zhǔn)備好故障預(yù)案。

5）結(jié)項(xiàng)：對(duì)整個(gè)項(xiàng)目從立項(xiàng)到下線整個(gè)過(guò)程中，做得好的和不足的點(diǎn)進(jìn)行復(fù)盤和總結(jié)，沉淀的經(jīng)驗(yàn)以便復(fù)制到下一個(gè)項(xiàng)目當(dāng)中，同時(shí)我們會(huì)不斷完善整個(gè)SRE工具鏈的全景圖。

Q&A

Q：如何在全量采集和采樣采集之間找到平衡？

A：全量采集和采樣采集沒(méi)有好壞之分，與業(yè)務(wù)場(chǎng)景有關(guān)。實(shí)際上我們也有一個(gè)項(xiàng)目要求必須要全量，因?yàn)閷?duì)賬要求全部都要采樣。但除了這種以外，基本上都是按一定的比例去做的，一方面可能與業(yè)務(wù)要去談適合的采樣比例值，因?yàn)槲覀儫o(wú)法判斷是5%還是10%，是沒(méi)有標(biāo)準(zhǔn)的，可能前期我們?cè)谂c研發(fā)做項(xiàng)目評(píng)審時(shí)，實(shí)際上這個(gè)比例已經(jīng)談下來(lái)了。

另一方面我們?cè)谌肟谧鋈浚蠖俗鑫膊康那闆r占的比例也比較高，大約是40%，就是入口都放過(guò)來(lái)，但是真正到后端不會(huì)全部數(shù)據(jù)落地，只落地1%或不到。我認(rèn)為尾部采樣才是有價(jià)值的，因?yàn)樗贿^(guò)濾有異常的、錯(cuò)誤的或斷鏈的等，捕捉到這個(gè)標(biāo)簽并把它存下來(lái)，那么數(shù)據(jù)量就很小。但是另外一種情況是項(xiàng)目剛上線時(shí)或不同類型的活動(dòng)和項(xiàng)目，要求要拿到其特征，那么就相當(dāng)于要求前期要全量，后期關(guān)注成本再慢慢壓下來(lái)，所以我們分不同的階段和訴求做不同的策略。