A3--黃焱--B站故障演練平臺實踐.pdf

《A3--黃焱--B站故障演練平臺實踐.pdf》由會員分享，可在線閱讀，更多相關《A3--黃焱--B站故障演練平臺實踐.pdf（41頁珍藏版）》請在三個皮匠報告上搜索。

1、B站故障演練平臺實踐焱資深測試開發程師焱主要負責嗶哩嗶哩性能測試平臺、故障演練平臺等，參與各個型活動（如：S賽、跨晚、拜年紀等）的穩定性保障作。負責常規壓測、全鏈路壓測、故障演練等在公司的落地實踐。嗶哩嗶哩 資深測試開發程師嘉賓照錄CONTENTS背景01 如何實現故障注02 如何實現爆炸半徑的控制03 如何進依賴采集04 關于演練的動化05 01背景背景：混沌程&故障演練混沌程：套通過在分布式系統產環境上進實驗，主動找出系統中脆弱環節的法學。背景：云原架構下，微服務數量爆炸式增，服務間調關系錯綜復雜，對系統可靠性提出更要求。發展歷程：術：故障演練，種在混沌程思想指導下，通過故障注的式，尋找系

2、統問題的具體法。道：五原則（穩態假說、現實事件、產環境、持續運、爆炸半徑）嗶哩嗶哩混沌程之路2019年：起步探索 基于 chaosblade 在容器環境下注故障，使得業務可以在線下 UAT 環境進故障注；2021年：優化設計 重新設計混沌實驗平臺，打通服務樹和周邊平臺，增加了實驗管理、場景實驗等能，簡化戶操作；整體來說：斷斷續續的投。業務的接也參差不。直到。墨菲定律再上演痛定思痛：B 站混沌程分兩個向開始推進：容災演練：基礎設施層的容災演練，如多活架構。故障演練：業務層的故障演練，梳理強弱依賴。次匪夷所思的線上事故18:30：彈幕 OCR 服務（新服務，L2）上線20:12：稿件服務開始觸發

3、OOM，部分節點開始重啟（報警被淹沒）20:19：稿件服務量 OOM，SLO 開始受損，量業務開始出現問題UGC 播放加載失敗、視頻法播放、WEB 出現空窗；天推薦降級數據標題出現繁體字；直播間粉絲勛章法加載、主播中圖標不展示、是否可帶貨法判斷OGV 劇集信息法拉取、TV UGC 內容法播放、收藏夾列表為空、播放歷史為空、20:22：基礎組件（SLB/APIGW）確認故障（組件類 SLO 平臺，定位慢）20:25：發現量報警與稿件依賴有關20:28：多活切流失?。ㄇ辛靼钙脚_化能、多活架構失效）20:37：彈幕 OCR 服務回滾，稿件服務重啟后逐步恢復圖1.匪夷所思的線上事故（Murphys L

4、aw:Anything that can go wrong will go wrong.）容災失效依賴混亂業務層的故障演練需要解決的問題關鍵詞：故障注 爆炸半徑控制 依賴采集 演練的動化問題拆解：怎么創建故障？要演練哪些類型的故障？在線上環境做演練，怎么保證安全性？不同的業務場景，故障的標依賴項都有哪些？演練的成本如何降低？背景：希望貼近業務去做，細化到具體的業務依賴，梳理強弱依賴關系；盡可能在線上真實環境，演練核鏈路的故障場景；02如何實現故障注Golang 如何實現故障注代碼模式法：AOP 思想，中間件模式 所有基礎組件進改造，持中間件模式 故障演練 SDK，在應啟動時注冊故障演練中間件

5、平臺推送故障演練實驗信息給 SDK SDK 根據實驗配置注故障問題：Java 有 JVM，但是Go 沒有虛擬機，怎么實現 AOP 呢？備選案：動態法：通過反射找到運法的指針，動態插代碼（如：gohook）；（問題：多種限制、不建議于產）靜態法 代碼插法：基于抽象語法樹（AST）做代碼成；（問題：需要重新成代碼，操作成本）代碼模式法：相對安全、透明；(問題：基礎組件需改造；優勢：B站 Golang 研微服務框架 Kratos，可控程度)Server 類型故障注示例圖2.HTTP Server 組件改造，持注冊中間件 圖3.HTTP Server 具體的故障為，超時、錯誤碼等圖1.HTTP Ser

6、ver 類型的故障注中間件2.故障演練中間件在應啟動時注冊到位3.Server 類型具體的故障因實現爆炸半徑控制故障靶點匹配1.創建 Server 的時候，使全局注冊的中間件 故障為注4.超時、錯誤碼等Client 類型故障注示例圖2.HTTP Client 組件改造，持注冊中間件 圖3.HTTP Client 具體的故障為，超時、錯誤碼圖1.HTTP Client 類型的故障注中間件2.注冊Client 類型故障注ClientOpt 3.HTTP Client 類型具體的故障因實現 爆炸半徑控制故障靶點注1.創建 Client 的時候，使全局注冊的 _globalClientOpts 4.超

7、時、錯誤碼等Server/Client 類型故障并存疑問：為什么既有 Server 類型的故障，有 Client 類型的故障呢？效果不是基本樣嗎？故障注：持的故障類型持的故障類型&故障為：Server 類 HTTP Server、gRPC Server （報錯、超時、特殊 ECODE）Client 類 HTTP Client、gRPC Client（報錯、超時、特殊 ECODE）數據庫類 MYSQL、TIDB、TAISHAN 等（報錯、超時）緩存類 REDIS、MC 等（報錯、超時）消息隊列類 DATABUS 等（發送報錯、發送超時、接收報錯等）其他特殊類 些公司特有的基礎組件（內部容量滿等）

8、故障注整體流程基本流程：業務應 1 代碼接 SDK，fault.Init()SDK 注冊各類組件的故障演練中間件 SDK 初始化，負責與Fault-Service信息交互，gRPC 連 戶通過 Fault-Console創建場景、編輯靶點、啟動實驗 Fault-Admin 將實驗信息寫 Fault-DB、Fault-KV Fault-Service 從DB/KV 獲取實驗，下發給 SDK SDK 攔截相關流程，實現故障點注，信息上報圖1.SDK fault.Init 初始化時注冊各個組件故障中間件圖2.故障注整體流程故障注中的些波折示例：接 SDK 之后，故障注不效 現象：應顯示正常接，但是故

9、障法注 排查根因：Server 的初始化邏輯太底層，繞過了 Fault 故障注中間件示例：實驗過程中，不確定故障是否效：實時志的式，及時反饋；通過加 Fault 調試 Header，在響應 Header 中標明命中的實驗；1、正常式：使 DefaultServer 創建，默認效2、異常式：戶直接調底層的 NewServer 創建，需要顯式主動加 fault 中間件才能效示例：靶點匹配策略失效，未成功注故障 現象：接和配置都沒有問題，但是故障法注 排查根因：ctx 的傳遞出現了問題，使了 context.Background 等圖1.過于底層的 Server 創建段，繞過了故障注中間件圖2.故障

10、注排查的實時志、DEBUG 響應 Header 示例接故障演練是否會影響性能疑問：微服務框架中嵌了故障演練的功能，即使服務未接，是否也會影響服務性能？若應確實接了故障演練 SDK，演練過程是否會影響線上服務的性能？應對：如果應未接，那么故障演練的中間件不會被注冊，對性能完全影響。如果應接，些保障條件（性能影響忽略不計）演練實驗的情況下：快速退出，乎影響 有演練實驗的情況下：最簡單的操作（如字符串完全匹配、前綴匹配等）避免正則、RPC 調等耗時操作只有存在有效實驗時才會進故障注邏輯內部避免各類耗時操作03爆炸半徑的控制如何實現爆炸半徑的控制常規的控制式持：實例粒度 (位置 A)：Fault-Se

11、rvice 只向圈定的實例推送實驗；請求粒度 (位置 B)：攔截器識別請求信息，決定是否注故障fault-ctx;例如：請求 Path 信息；靶點粒度 (位置 C)：根據靶點配置的詳細匹配規則決定是否注；例如：請求 Path、緩存 Keys、操作類型、實例地址等；ABC業務需求：能否直接內部賬號來演練 業務特點：有賬號體系 解決式：持戶ID 粒度的控制（精確匹配、或根據尾號劃分）效果：只有指定的戶登錄，才會觸發故障（依賴ctx 傳遞戶 ID）新需求：消費場景的爆炸半徑控制背景：有些情景，如稿件的審核、點贊統計異步任務等，并不是傳統的 Server 服務類型，是個 Job；對于此類情景，如何實現

12、爆炸半徑的控制？消費場景爆炸半徑控制實現案：B 站基于 CQRS 架構的異步事件治理框架（Railgun），泛于實現此類消費場景?；?Railgun框架，插故障中間件，基于 Topic、消息內容判斷是否注 Fault-ctx，實現爆炸半徑控制。例如：可以對特定的稿件進線上故障演練，如指定內部戶創建的演練稿件。圖1.Railgun 異步事件框架中，在處實現標消息 fault-ctx 的掛載（實現消息粒度的爆炸半徑控制），然后fault-ctx 繼續傳遞到后續調各依賴的流程中（實現靶點粒度爆炸半徑控制）。因為需要 Topic 信息，所以需要在源頭進故障注處理04如何進依賴采集如何進依賴采集背景：

13、故障演練的場景配置，需要接粒度的依賴信息。由研發員梳理接依賴效率低、結果也不準確。備選案：基于現有基礎平臺結果導（不：只有應維度的依賴，不符合條件）基于 Trace 結果導（不：有些應接 Trace 程度不；線上 Trace 采樣率問題，可能存在遺漏）基于 Fault-SDK 在服務調依賴處進依賴上報（優勢：故障注和依賴采集完全匹配，可控性）依賴采集基本流程：圖1.依賴采集基本流程。在采集時通過 collectCtx 進信息傳遞。需要做好依賴去重、聚合作，降低依賴上報頻率。HTTP_CLIENT 依賴采集示例說明：依賴采集基本流程與故障演練實驗類似，可以視為靶點的實驗；在調依賴的位置，嵌依賴上

14、報的邏輯；圖2.http_client 類型依賴上報位置示例圖1.依賴采集與故障演練實驗，完全匹配。在故障注的位置附近進依賴上報。直接在故障注的位置附近進上報邏輯嵌上報的依賴信息與故障注類型天然匹配，通過依賴可以縫創建故障場景依賴的多樣性背景：同個應，不同的對外（API/Topic），依賴項可能不同；同個對外，不同的參數條件下，依賴項可能也不同；圖1.同個 Server 應，不同的條件下，依賴項可能不同；或者依賴的強弱關系也不同；取決于業務需求；應對：依賴采集的時候，以 API/Topic 為粒度進聚合；戶可以為控制流量，以采集到特定業務場景下的依賴；采集到的依賴項，可以選擇性導出為特定的演練

15、場景進固化，對應特定的業務情境。05關于演練動化演練動化：強弱依賴動判定背景：演練成本 雖然依賴采集的效率提了，但是演練的執成本依然昂。演練組合數=接數*依賴數*故障類型種類*故障參數種類解決：強弱依賴動判定 確定演練范圍（實例、接、依賴項）根據依賴項進 task 拆分（單故障點）SDK 內部維護各個 task 被觸發的次數，動實現 task 的切換 Fault-Service 根據上報返回的結果，判定強弱依賴限制：動強弱依賴判斷要求業務返回遵循規范（強依賴導致錯誤碼，弱依賴明顯報錯）；若返回不規范，強弱判定可能不準；演練動化：接/UI動化集成故障演練背景：接動化、UI 動化，可以加些業務信息

16、的斷，集成到 CI 流程，確保強弱依賴關系不被意外破壞?；玖鞒蹋汗收涎菥毱脚_提供 OpenAPI 操作故障演練實驗。業務 QA 設計測試例，編排故障場景。在動化腳本中開啟、關閉對應演練實驗。執特定的測試邏輯。對返回結果進處理（接斷、圖 DIFF、視頻錄制、BUG單創建等）關鍵點：故障效的時效性問題（從SDK拉故障改成 Fault-Service推送故障的模式，提故障效時效性）演練實例的選擇問題（持基于染的動圈定，與 CI 流程動發布染實例打通）問題：業務需要為創建量的故障演練場景，且維護好故障場景與 CASE 的對應關系；演練動化：多應場景的動演練背景：個實際的業務場景，通常會同時涉及多個應

17、，如何管理多應場景下的演練？解決：設計多應的業務場景的概念。個業務場景對應多個應場景，個應場景下可以有多個故障靶點。平臺持多應故障點應不同組合策略，動進組合和故障注。持鍵啟動。持綁定業務場景級弱依賴 CASE 集、單依賴級測試 CASE 集，強弱依賴執不同的靶點組合策略；06總結總結：故障演練平臺全景&演練基本流程流程示例1.程序，代碼接 SDK 2.平臺動獲取該服務對外提供的接，如 bmc_say_hello 3.執依賴動采集、強弱依賴動判定流程示例4.創建應場景和靶點5.控制爆炸半徑流程示例6.啟動實驗，故障效，影響具體的請求7.實驗現象觀察、節點志流程示例8.個業務場景下可以關聯多個應場景，每個應場景內部包含具體的靶點9.業務場景下，依賴級別可以關聯專的 CASE 集合、實現故障的單點注等感謝聆聽關注QECon公眾號