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

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

1、業(yè)務背景

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

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

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

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

尤其是一些大型活動，需要多個團隊協(xié)同開發(fā)，會涉及到幾百個微服務化的相互調(diào)用，整個微服務拓撲非常龐大，理解框架的難度加大。

2）追蹤、指標、日志數(shù)據(jù)上報標準不一

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

3）無法快速定位服務問題以及根因

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

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

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

5）無法判斷節(jié)點間強弱依賴關(guān)系

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

6）新上線業(yè)務容量評估無法精準計算

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

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

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

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

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

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

2）單體→微服務

單體服務微服務化，讓服務的治理更加精細化。

3）管理→治理

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

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

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

5）DO分離→DO融合

以前開發(fā)和運維互不干涉，因為有“墻”的保護，也不需要給彼此背鍋，在云原生的背景下，我們要求開發(fā)和運維要盡可能地融合，也是遵循了DevOps的思想。

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

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

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

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

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

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

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

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

1）第一個階段：CloudOps（云端運維）

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

2）第二個階段：SRE

在SRE里會保留兩種職能：

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

3）第三個階段：ServiceOps（運維服務化）

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

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

5、目標設定

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

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

2）提升 MTBF（平均故障時間間隔）、降低 MTTR（故障平均修復時間）

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

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

• 一是能夠提升效率；
• 二是讓交付更加標準化，比如業(yè)務出海，可以快速復用國內(nèi)的交付能力，這些能力可以沉淀在各種編排模板、腳本，并且可以結(jié)合版本管理來追蹤變化的明細。

5）具備一定的故障預警、根因分析、問題定位能力

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

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

6、SRE 8 準則

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

二、SRE工具鏈建設思路

1、SRE體系全景

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

1）事件編排

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

2）MTBF

即平均故障時間間隔，如何提升MTBF？

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

3）MTTR

即故障平均修復時間，如何降低MTTR？

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

2、底層組織邏輯

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

首先說明最底層部分，我們會定義SRE里面的標準規(guī)范、方法與目標，相當于我們在做好上層平臺化之前，首先要把整個理論體系的底座梳理清楚，平臺化只是將這套理論體系的實例化。

中間層的平臺化，大家看到的可能是三個獨立的平臺能力，但我們把它看成一個整體，相當于把這三個能力當成一個能力體系來建設。因為我們在實踐的過程中發(fā)現(xiàn)，三個不同能力的任意組合都可以延伸出不同的玩法：

• 可觀測性+全鏈路壓測，能夠做資源的精準評估。
• 可觀測性+混沌實驗，能夠做強弱依賴分析。
• 全鏈路壓測可以作為混沌實驗壓測的原子。

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

三、SRE工具鏈建設實踐

1、可觀測性實踐

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

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

很多團隊將這三個能力分開建設，比如指標通常是搭建一個Prometheus采集指標，日志則搭建一些日志采取的組件，到ELK里進行檢索，追蹤則用Skywalking或Jaeger之類的工具搭建，再檢索整條鏈路拓撲等。但是可觀測性要求將這三者融合，即通過一定的符號、特定的ID，把這三種能力串聯(lián)起來變成一個整體，這是可觀測性追求的目標。

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

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

2）平臺能力

接下來是我們的一些平臺能力，有基礎能力，也有我們認為比較滿意的一些高級能力。

• 綜合管控治理

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

• ONE-SDK

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

• 提升采集ROI

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

3）綜合治理

我們的綜合治理分為采樣治理和運營治理。

①采樣治理

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

②運營治理

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

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

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

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

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

4）異常檢測

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

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

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

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

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

2、混沌工程實踐

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

1）平臺架構(gòu)

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

2）平臺能力

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

我認為服務強弱依賴分析是很有價值的，可以輕松感知如A調(diào)B服務，B出現(xiàn)問題對A是否造成影響，我們分為三步來實施：

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

3、全鏈路壓測實踐

最后一個是全鏈路壓測，我認為它的意義主要是兩點：

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

1）平臺架構(gòu)

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

2）平臺能力

3）服務壓測鏈路拓撲

接下來我想講全鏈路壓測其中的一個應用，即服務壓測鏈路拓撲。我們在源頭施壓，平臺能夠完整地呈現(xiàn)整個觀測鏈路，展示微服務間的調(diào)用關(guān)系鏈，同時能夠?qū)崟r計算出每一層微服務黃金指標，即A調(diào)用B的耗時、QPS、延遲、放大倍數(shù)等都能計算出來。

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

4、總結(jié)

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

1）立項：我們會組建一個FT的臨時團隊，團隊里有運維、開發(fā)、測試、產(chǎn)品等，運維也會參加技術(shù)方案的討論，同時定制可觀測性上報的規(guī)范。

2）開發(fā)：開發(fā)需要落實運維制定的規(guī)范，做好指標埋點的上報，同時SRE會參與技術(shù)架構(gòu)的評審。

3）測試：我們會在這個階段大量地做混沌實驗和全鏈路壓測。

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

5）結(jié)項：對整個項目從立項到下線整個過程中，做得好的和不足的點進行復盤和總結(jié)，沉淀的經(jīng)驗以便復制到下一個項目當中，同時我們會不斷完善整個SRE工具鏈的全景圖。

Q&A

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

A：全量采集和采樣采集沒有好壞之分，與業(yè)務場景有關(guān)。實際上我們也有一個項目要求必須要全量，因為對賬要求全部都要采樣。但除了這種以外，基本上都是按一定的比例去做的，一方面可能與業(yè)務要去談適合的采樣比例值，因為我們無法判斷是5%還是10%，是沒有標準的，可能前期我們在與研發(fā)做項目評審時，實際上這個比例已經(jīng)談下來了。

另一方面我們在入口做全量，后端做尾部的情況占的比例也比較高，大約是40%，就是入口都放過來，但是真正到后端不會全部數(shù)據(jù)落地，只落地1%或不到。我認為尾部采樣才是有價值的，因為它只過濾有異常的、錯誤的或斷鏈的等，捕捉到這個標簽并把它存下來，那么數(shù)據(jù)量就很小。但是另外一種情況是項目剛上線時或不同類型的活動和項目，要求要拿到其特征，那么就相當于要求前期要全量，后期關(guān)注成本再慢慢壓下來，所以我們分不同的階段和訴求做不同的策略。