B站 SRE 發展的 5 年

B站2017年之前沒有SRE，當時主要負責的事情就是效率優先，需求響應（比如變更、標準化、報警治理和瑣事優化）。2018年引入SRE文化，開始理解業務架構、推進讀的多活建設、探索 SRE 里的 Oncall 制度/復盤文化在B站的落地。

2019年正式進入落地，首先做了瑣事優化（釋放人力），將工單變更通過平臺來自助審批。之后做了 SLO 體系探索，包括平臺、基于 SLO 的服務分級體系、應急響應制度、復盤平臺、問題管理制度建設等。

2020年 SRE 穩定性體系初步完善，20年B站做了很多活動（S10、跨晚、最美的夜等）。有了故障前的應急響應及故障后的復盤，開始探索故障前混沌工程和故障演練；質量之后是容量，B站是容器化部署（探索 PaaS 容量管理體系），在一系列落地之后，2020年穩定性體系初步完善。2021年至今SRE繼續轉型，從 Oncall 制度逐漸轉向 BP 制度，更加關注穩定性和降本增效。之前做了多活、服務分級、SLO都會在今年重新做優化建設。全員現在在做 SRE 轉型。

穩定性保障

下面介紹一下轉型過程中具體的解析。首先是穩定性保障（高可用、多活、容量管理、活動保障）。

高可用

先看下整體架構。用戶首先從 CDN 層到接入層，接入層有4層 LB/7層 SLB，還有逐漸推廣的 API GW。

之后進到服務層，服務側會有一個 BFF（服務網關），下面是 Service、Job、Admin等。

• 中間件主要是 MQ，數據同步 Canal、DTS，消息通知 Notify、緩存；
• 存儲層面是關系型數據庫、 KV、對象存儲、ES等等；
• 再往下是可觀測與效率體系；
• 底層是穩定性體系，包括服務分級&SLO、混沌工程/故障演練、多活容災/預案管理、問題管理/事件分析、容量/降本及活動保障。

接入層

這是接入層架構，用戶通過 DNS 或降級 HTTP DNS 訪問 CDN，CDN 通過機房邊緣 POP 點匯聚流量到機房，機房有不同可用區(邏輯概念)，每個可用區主要是 SLB 和 API GW。

常見的故障有幾種：

網絡故障：邊緣節點回機房（運營商公網故障）；

機房故障：一般比較少遇到（主要看概率）；

組件故障：比如 SLB 節點發生故障等；

服務故障：SLB/API GW 所代理的服務等；

接入層的高可用方案，比如 DNS 降級 HTTP DNS、多 CDN 節點動態選路、APP邊緣節點網絡層故障降級第三方CDN重試；多 POP 點做流量匯聚，多線路做源站互備。

如果單可用區 SLB 故障，支持 CDN 從其他可用區跨專線回源。

對于后端服務故障，SLB可發現服務區的所有節點；單可用區服務故障節點可以自動降級。SLB 也支持常見的降級、容災與限流。

最后是 7.13 故障，SLB重建花了一個小時，故障后對 SLB 初始化重建做了很多優化，現在可以5分鐘重建一套SLB。API Gateway 的高可用與 SLB 類似，這里不再重復。

服務層

上面說了南北向（接入層），現在來看看東西向。對 SRE 來說，這一層一定要了解（微服務架構），如果不了解一旦服務出現故障給不出業務故障止損預案。

服務調用是通過內部 Discovery 服務發現組件進行調用，服務部署了多活（可用區A和B），每個機房服務都是多節點部署，不同節點所運行的物理機（比如是CPU型號不一導致單核算力不一，要看 K8s 有沒有做算力規劃）。

這個過程可能出現問題，比如容器節點算力不一，服務B流量過載、可用區故障等，也有幾種高可用能力：

• 服務調用有 P2C 算法，服務A調用服務B，服務B會返回自己節點的 CPU 使用率情況，服務A基于這次響應的 RT（包括服務B每個節點 CPU 使用率/成功率來選擇一個最優的節點），雖然服務B不同節點 CPU 算力不一，但最終 CPU 使用率是一樣的；
• 熔斷，服務B故障時，服務A做一個熔斷；
• 降級的場景有兩種：

一是可用區的降級，當服務B在某可用區故障，服務A調用B可以通過服務發現組件降級到其他可用區；另外是做多活的時候，服務在本可用區沒有做部署的情況下降級到其他可用區；

內容質量降級，服務B故障服務A可以訪問本地緩存/降級服務。在我們場景里，如果播放地址失敗會降級到災備播放地址。B站首頁APP推薦可能是動態的，推薦系統故障也會降級給用戶熱門視頻。

• 限流有兩種，一種是微服務框架側全局限流，它在框架層面的攔截器，B站內部主要是 Golang，使用 Kratos框架，基于框架做了分布式限流。第二部分是動態限流，不需要預先配置，基于 Google 的 TCP BBR 算法來實現的，會自動分析每個容器節點 CPU 使用率/成功 QPS 等來自適應做一個保護。

中間件

服務還有一種故障場景是中間件的依賴。

看看核心服務對中間件依賴，比如服務寫數據，對評論、彈幕數據可以接受最終一致，把寫的數據扔到 MQ，用 Job 消費消息隊列，寫入DB。DB 層面會掛一個 Canal 組件，來消費數據庫binlog，將消息寫回消息隊列，再刷到緩存里。

我們用到最常見的組件就是緩存/MQ/DB。

緩存在生產系統里有三種模式，Redis Cluster、Redis單節點/分布式、Memcache（內部是按這個順序做推薦建議），每種語言在生產環境 SDK 都出現過各種各樣的 Bug。

比如短連接風暴，之前搞拜年紀活動，活動一開始充電服務就故障了。后來發現，Jedis 的并發數量超過配置的 Total 之后，后續連接會變成短鏈接。redis單線程機制，長連接和和短連接性能相差10倍的數量級，一旦遇到短連接性能就會急劇下降。

我們用過各種語言，連 Redis 之后，往一個節點發一些cluster nodes 或者 slot 風暴這種請求，甚至可能會固定往一個節點發請求，很快把一個節點打死了。

當發生 cluster 風暴，再遇到短連接就會出現雪崩，根本沒辦法恢復。想恢復只能重建緩存或做一個冷重啟。后來我們對緩存做了統一的 proxy 代理（sidecar 模式，或者通過 proxyless sdk），也是為了降本增效，把單容器改成 sdk 模式進行部署訪問。

消息隊列主要做臨時持久化，異步寫DB。集中式代理，不用 sidecar 模式部署，我們內部支持 redis 和 gRPC 兩種協議。2020年B站做了很多擴圈活動，kafka topic數量急劇增加，當時代理是 kafka 的 Sarama SDK，這個 SDK 也是各種炸，不停出現故障。

數據庫層面，內部提供數據庫 proxy，用 sidecar 模式部署。對業務做讀寫分離，對業務透明。對異常SQL做攔截，比如慢SQL。為了降本增效，現在也提供了SDK模式。

前面說了很多架構層面的內容，SRE 一定要了解業務架構，如果不懂架構只能做日常需求（那和配管沒區別），不懂業務架構的 SRE 是沒有靈魂的。

那有了高可用能力，B站就不炸了嗎？2021.7.13故障，B站/微博/知乎全網熱搜，我們做一下復盤。

2021.7.13 故障

2021.7.13 晚 10:52，用戶反饋B站無法使用，內部大量服務、域名接入層報警不可用。
10:57分，Oncall 同學發現 SLB 故障。
11:17，內網登陸也受影響，17分核心成員才陸續進入內網系統。
11:23分，讀多活業務基本恢復。多活機房 SLB 容量過載，多活機房服務層正常/接入層掛了（容量漲了4倍左右）。
11點之后流量逐漸下降，重啟恢復。當時直播業務也做了多活，首頁接口沒做多機房流量分發（所以沒有恢復）。
11:17分登陸分析問題，開始懷疑是 SLB 組件問題，聯系最近在SLB層面做了三次引擎 Lua 層的變更，也沒有恢復。

此時面臨2個選擇，一是繼續排查問題（底層Debug，SLB具體是什么故障？)；二是給業務一個可以預期的止損手段。

當時選擇新建一套 SLB，嘗試隔離流量恢復業務。之后驗證流量隔離是有效的。

1:00左右，新建 SLB 全部完成，開始做業務流量切換。
1:40左右，業務已經全部切到新集群，核心業務全部恢復。

這里能看到很多問題：

• 用戶的鏈路和辦公網鏈路未徹底隔離，11:17分才陸續進入內網系統，有些辦公網后臺直接放在公網對用戶訪問，辦公網放到公網也會用到公網 SLB（沒有徹底隔離）。
• 多活未按預期立即生效。多活機房SLB流量過來，只支持讀，不支持寫。
• 人力不足。故障止損和排查無法并行。1點左右新建，后面才嘗試做故障排查。組件故障預案不完善、處理耗時久（集群的創建、配置的下發、公網 IP 配置花了接近1個小時）。
• 復雜事故影響面積大，故障定位成本高。
• 同時也看到，多活是機房級故障時容災止損最快方案！

通過 7.13 故障能看到：

• 多活基架能力不足。機房與業務多活定位關系混亂，流量調度層面不支持精細基于用戶特征做流量分片。
• 切量強依賴 CDN 平臺，多活的接入層/用戶流量調度分發層是在 CDN 層面實現，并沒有做一個多活統一管控平臺。
• 多活元信息也缺乏平臺管理，比如哪個業務做了多活（多活是同城雙活/異地容災），業務有哪些規則支持多活。?

高可用 - 多活

對于多活元信息定義做了標準化，業務多活 CRG 的定義（CRG 定義參考了螞蟻的多活模式）。

• Gzone 服務（全局共享服務），可以在用戶間共享數據，一個可用區寫/其他可用區讀（數據強一致性）。B站場景里，視頻播放/番劇/影視/稿件信息/直播間信息數據都是平臺型數據，這種數據在用戶間共享不需要做單元化。
• Rzone 單元化業務（用戶流水型數據），多可用區分片寫/讀，用戶維數據在B站里就是社區類場景（評論/彈幕/動態等適合單元化的場景）。
• Czone 和 Gzone 有點類似，Czone 所有可用區都可以寫/讀（非單元化），介于 Gzone 和 Rzone 之間的，這種場景需要業務接受一定數據延遲和不一致。

對機房進行梳理，當時上海有很多機房（都在一個地域內，機房定位比較混亂）。梳理后將上海的4個機房劃成兩個邏輯可用區，同城雙活（Gzone 類型服務）部署在上海；把江蘇可用區作為 Rzone 單元化服務部署模擬異地；我們又規劃華北/華南的可用區，來做單元化、Czone 服務部署（30ms-40ms網絡延遲）。

高可用 - 同城雙活

組件層面也做了優化。流量的 Router 是在 DCDN 層面，分發到各個機房，各個機房的服務在讀寫存儲，主要是 KV、DB，Proxy 來做接入，同城雙活的可用區只支持讀，寫都是通過 Proxy 轉到主機房。通過 GZS 來做多活狀態管理。

對這些組件優化主要是這幾個：

• DCDN 支持用戶 Mid、設備ID來做一致性 Hash，同時支持多機房動態權重。DCDN 是基于 Nginx 來構建的，后來重新開發支持多機房的動態權重。
• 服務原來的多活是不支持寫的，沒在多活機房做本地化部署和寫鏈路感覺。核心鏈路一定要在本地寫，微服務框架支持寫感知，弱依賴服務回到主機房。
• 存儲層面最早多活沒有 Proxy 組件，需要業務自己決定哪個機房讀/寫（管理成本特別高）。我們后來統一做 Proxy 做業務接入管理。
• KV 存儲原本不支持機房部署或者容災切換，之后也做了改造優化。包括 TIDB 也支持多機房容災切換。
• GZS 通過 GZS 來管理業務多活元信息、多活定義、切量編排/可視化。?

GZS：Invoker

GZS 內部叫 invoker，基于 API 的元信息管理，結合內部 CMDB 系統（CMDB 存儲業務元信息/審批平臺)，同時聯動內部幾個多活組件，比如 DCDN/KV存儲/DB存儲/API GW 組件來做流量切換。核心就是優化上面四部分：

• 多活規則元信息獲取方式優化
• 平臺多活和同城雙活切量演練
• 多活編排、接入流程優化
• 審批、巡檢、可觀測能力加強

實際多活編排和切量流程是，編排先選擇業務（評論/彈幕/播放）、選擇業務類型（同城雙活/單元化）、編排接入層規則。

數據庫層編排是 KV、DB，要把多活各個維度資源編排出來，業務就可以發起切量。

業務和業務域。業務域（直播/電商/社區），業務域下會有業務(社區有評論/彈幕/點贊等），切量編排是對流量編排或存儲編排。

切量完成之后觸發審批。審批之后是巡檢，巡檢主要為三部分：

• 容量巡檢，CPU/MEM；連接池，流量切到另一個機房，流量可能會翻倍；還有數據庫/緩存連接池能否扛得住；限流，微服務框架也有很多限流配置，限流能否扛住。
• 延時巡檢，主要做存儲層面的巡檢，現在是同城雙活，延遲基本上沒啥問題。
• 隔離巡檢，存儲有沒有跨業務混用？比如評論的業務是否用一個動態/彈幕 DB、KV。
• 可觀測，巡檢指標可觀測，連接池、限流是怎么變化的？業務多活流量規則，流量切換是否符合預期？是否把流量從1:1切到1:0；業務涉及核心應用SLO 指標。?

除了質量之外，前面提到降本增效一定是今年很多互聯網公司的目標，下面說如何通過容量管理做降本增效。

容量管理

容量管理之前，SRE 要想一個問題，要管什么容量？

• ?在整個系統架構中有接入層（核心是帶寬）；
• 應用層面核心就是計算資源；
• DB 和存儲，那是存儲資源。?

對 SRE 來講，容量管理的核心應該是應用。

容量管理做出之后誰關注？

不同角色關注是不一樣的，比如研發/SRE/平臺/預算團隊等等。

目標收益是做之前要想清楚的。這里是每個角色對容量管理的預期：

• 研發核心是有資源擴容、自動擴容、發布/回滾不被資源限制。
• SRE既要關注服務資源使用率，還要關注彈性擴縮，部門資源水位、降本增效。
• 部門維度，關注部門資源水位、使用率、部門成本、部門 TopN 服務報表。
• 平臺維度，容器平臺關注 Buffer、平臺超賣、資源混部、資源利潤率、降本增效。
• 成本團隊就是資源用量、賬單這些事情。

思考這些問題之后，內部圍繞 K8s 形成了容量管理，右邊是架構圖。

底層是 K8s 平臺，上層是基于 K8s 應用基礎數據搜集（集群容量/資源池容量/Node容量/應用容量/應用基本畫像）；

再往上是VPA/HPA/合池/配額管理。VPA 是面向 SRE平臺（對研發不可見），VPA 的好處是動態調整服務 Request 指標，提升 K8s 可調度資源數量；

HPA，橫向彈性伸縮，面向研發，解決服務擴容的問題；

合池，Buffer 復用，增加彈性資源能力。要解決機器維度的差異或者 Node 節點的差異；

配額管理，沒有合池每個部門只能看到獨立資源的物理資源，合池之后看不到物理資源（只能看邏輯資源，LIKE云平臺），Limit 作指標。

最上面就是容量可視化和報表運營，底層的元數據和容量保障之上給業務提供統一可視化平臺/運營平臺，查詢部門資源容量/排序，某個組織/業務的容量和數據。

容量管理 - VPA

VPA 是降本增效的利器。首先看幾個概念，在應用維度K8s有三個指標，一個是CPU Used（實際用了多少CPU，比如Limit 配了8個C，Request能配4個C，超賣的2倍，業務實際應用了2個c，Used 2c/Request 4c/Limit 8c；應用 CPU Limit/CPU Request=業務超賣率）。B站一開始超賣是應用維度超賣，就是給到研發自己配置。

遇到一些痛點，當 Request 分配完，Used 特別低時，資源池沒有資源可調度，SRE找研發按應用維度調整超賣率，對研發來講想搶占資源，這個服務是穩定的，不想把資源釋放出來，就導致共識很差，效率很低，收益特別小。后來把VPA改成平臺維度。

改造平臺維度之后，研發不關注超賣率，只關注 Limit，不再感知 Request，VPA 的指標放到平臺維度，業務實際用了多少 CPU/CPU total=物理資源 CPU 使用率。CPU Limit/CPU Total=資源池超賣率。CPU Request/CPU  Used=資源冗余度。內部情況物理資源 CPU 使用率低于40%，會調整 VPA 策略，動態回收 Request，比如有一個業務部門資源使用率特別低，直接調整為 VPA 策略。

右邊是K8s與VPA聯動的架構圖，上面是 VPA 管理平臺：策略管理/數據運營/黑名單/預警。

比如某些業務不適合VPA，比如Job類型/推送服務（一天只運行5-10分鐘），給這個服務做VPA沒有任何意義。

做活動時整個資源池應用CPU使用率會增加，這個時候開啟VPA，會導致第二天資源池分配的 CPU request 會增加，導致資源池沒資源可用。

同時做 VPA 之后也對 VPA 做了很多預警策略，發現VPA是否符合預期。

中間是 VPA 與 K8s 聯動 VPA 策略引擎。

底層是 K8s 提供的 VPA API。VPA主要解決兩個場景。一是新增一個Pod，比如一臺機器掛了，pod做一個漂移很常見，這種場景通過 K8s 的 APIServer 層面 Webhook 對所有新增的 Pod 做VPA；二是下發 VPA 策略對存量所有 Pod 做 updater，存量和新增的 Pod 都可以VPA。

規則按照這四個來：服務等級/服務畫像/資源類型/度量指標。舉個例子，內部L0服務，以CPU Used 7天P99指標，來 VPA 所有容器 CPU 資源，L2服務既要做CPU的VPA，也要做內存的 VPA。基于1天的指標來做就會更有利。

這是線上合池K8s資源使用率，有兩個指標，一個是只看容器CPU使用率，另外是一看物理機維度CPU使用率怎么樣，在8月初，物理機使用率達到50%以上，整個容器層面也可以超過40%。在VPA之前，我們一個資源池CPU使用率高峰期可以達到20%-30%就不錯了。今年上半年都沒有加資源，就靠VPA滿足業務新增所有需求。

前面講了高可用、多活，B站每年會有很多活動，比如S11、跨網拜年紀。2021年S11當天直播在線人數突破千萬。

活動保障流程主要是活動了解->容量預估->壓測演練->復盤清單->技保能力&預案。

前面講了高可用、多活，B站每年會有很多活動，比如S11、跨網拜年紀。2021年S11當天直播在線人數突破千萬。

活動保障流程主要是活動了解->容量預估->壓測演練->復盤清單->技保能力&預案。

活動重保

活動開始前做活動了解

活動形式：直播/點播/秒殺/抽獎…

重點場景：不同活動重點不一樣，彈幕互動、抽獎、送禮

活動對外鏈接：全鏈路保障

活動推送：站內推送、彈窗推送

活動后的場景：直轉點、二次熱點

時間線

容量預估

• 基礎資源

交換機帶寬、源站帶寬

靜動態CDN

• 業務資源

PaaS、laaS

Cache、MQ

壓測&演練

內部壓測分三輪：

第一輪：現有資源下壓業務瓶頸；

第二輪：資源就緒后按照之前的預估人數做容量壓測；

第三輪：所有優化和保障方案上線后壓測演練。

演練層面兩部分：

預案演練

故障演練：包括上下游依賴、中間件依賴、節點故障、HPA能力。

復盤清單

活動清單檢查

關閉混部

關閉VPA

活動鏈路服務開啟HPA

技保能力&預案

技術保障能力是側重問題發生前的，你具備哪些高可用能力，有哪些能力保障業務穩定性。比如多活、跨機房降級、熔斷等等，還有HPA、VPA等等。預案是問題發生之后應該怎么辦，它們倆有不同側重點，預案做攻擊、容量、服務故障等三方面預案。

現場重保&復盤

看好監控大盤，把活動核心指標做定時同步，比如S賽，一場比賽結束之后就把這場比賽數據同步一下，包含前面講的技術資源、業務資源、服務有沒有出現一些高可用問題，比如有沒有出現一些異常、限流。把活動中問題變更記錄下來，復盤時不僅做活動當天復盤，還把活動從前期準備的問題統一復盤。

SLO 實踐與反思

SLO

前面講的是穩定性保障、高可用，服務可用性怎么度量？

我們先看一下 Google 的定義：

SLO 為服務可靠性設立了一個目標級別，它是可靠性決策的關鍵因素，是 SRE 實踐的核心。

Google 甚至說沒有 SLO 就沒有SRE。為了使采用基于 SLO 的錯誤預算的可靠性工程方法，服務利益相關方認可 SLO，甚至服務可以達到 SLO。

基于 Google 的理論，B站基于現有分為兩部分：服務分級與SLO系統。

服務等級分四級，L0-L3。對象包含業務(產品）=> 應用 => API。

業務就是產品，比如評論等級是 L0，評論下是應用，應用的等級不能超過產品等級。應用下有 API（發評論/拉評論)，API的等級也不會超過應用的等級。

等級出來之后用于服務標準化、變革流程管控、報警測量，不同服務等級報警測量/穩定性要求不一樣，比如服務有沒有降級能力/多活能力。

SLO 系統提供的核心能力就是做 SLO 指標的選擇/計算/定義。

服務分級&SLO

這是實踐 SLO 的流程，首先創建業務&定級&定SLO；然后創建應用&定級；之后創建接口&定級&算SLI指標；最后基于接口聚合到業務上。

這種模型沒有運轉下去。

我們的反思：

• 分級模型太理想，定級成本非常高；
• 各種元信息關聯不及時，數據準確率低；
• 開始做 SLO 計算只算公網服務，也只算了在接入層（SLB層）指標，單條 Metrics 沒辦法覆蓋所有業務場景；
• 部分內網服務不對外，導致沒有 SLI 數據；
• SLI 數據除了當報表外，也沒人看

新的模式：

• 分級模型優化
• SLI模型優化
• SLO報警治理?

說一下現在的玩法：創建一個業務只對業務主場景定級，比如評論核心就是發評論/拉評論（對這個場景定級）。應用不再需要定級，只需要打標。算 SLI 對多個對象/多條SLI指標做計算，某個API就是業務某一個具體波動的體現，也算它的指標數據。對業務指標，比如業務一些在線人數、播放量、發送的評論這是業務，我們會算三個維度的SLI指標。對這些指標做SLO的運營和質量運營。

僅度量SLI是沒有任何意義的，核心是SLO報警和質量運營。

甚至SLO報警的重要性比質量運營更高，因為質量運營和SLI度量都不能幫業務提供什么東西，但 SLO 報警會幫業務第一時間發現問題，提升報警準確率。

事故定級

優化服務分級之后，也解決了事故定級中的問題。事故定級以前有兩個指標，業務損失&服務等級：故障時間&PV損失，因為之前分級模型比較復雜，有業務/應用/接口，出現故障哪個等級作為故障的等級，我們經常在這里扯皮不清。

對業務分級做了優化之后，只對主場景定級，事故時看業務損失&業務定級&業務主場景系數。

主場景故障系數是故障功能對主場景影響程度，這種模型完全把服務分級復雜模型包進去，不用在故障時扯皮。

SRE的培養與轉型

工作分層

工作分層：最上面是比較傳統的日常答疑、變更、報警處理等。再往下是 SRE 橫向的串聯、協作、拉通，再往下是SRE或運維核心，對業務做支持，比如業務遷移重構&改造，中間件推廣、技術運營、應急響應等等。基于上面三層抽象出穩定性體系，再將各種穩定性實踐整合成穩定性體系。

對 SRE 的能力要求：

• 運維能力：基本運維能力、網絡、OS/內核、架構能力
• 開發能力：工具開發、運維平臺開發、工程能力等
• 合作共贏：項目管理能力、團隊協作、同理心、情商與運營意識
• 個人潛質：學習能力、好奇心、逆向思維能力
• 責任心與擔當。

培養與轉型

SRE 培養有四方面：

• SRE文化：團隊要認可SRE文化，從團隊Title和組織名稱可以看到對SRE的重視；從上到下傳達SRE的轉型；SRE職級序列；
• SRE方法論：學習 SRE 理論知識，主要是《SRE工作解密》《SRE工作手冊》；
• SRE討論會：SRE方法論專題分享。基于理論做實踐落地。方法論掌握之后再拉大家做討論會，討論SRE的章節、內容，包括SRE穩定性、基礎運維架構的知識；
• 開發轉型：SRE 繞不開開發，內部也鼓勵做開發轉型，B站基于Golang，SRE 也是基于 Golang，鼓勵 SRE 先做工具開發，能力達標之后會分配專業開發導師，參與 SRE 平臺開發實踐，最終開發平臺又提升了SRE工作效率，實現正向循環。

作者簡介

武安闖，2016年加入B站，深度參與B站微服務拆分、云原生改造、高可用建設、SRE轉型和穩定性體系落地等項目。當前主要關注B站在線業務的SRE穩定性體系建設和推廣，對SRE的實踐有深入的探索與思考。