Chaos Mesh 在騰訊——騰訊互娛混沌工程實踐

本篇文章整理自騰訊互娛高階工程師吳召軍在 PingCAP Infra Meetup 上的演講實錄，歡迎點選【閱讀原文】檢視視訊回放，後臺回覆 「135」 即可獲取本期 PPT 連結。

本文首先介紹了騰訊互娛面臨的複雜的技術場景，然後介紹了騰訊互娛混沌工程團隊基於 Chaos Mesh 打造的雲原生混沌工程平臺，最後分享騰訊互娛近半年混沌工程實踐取得的收益。

騰訊互娛運營活動每天的訪問人次超過 100 億次，高峰的 QPS 超過 100 萬，每天活動程式碼釋出更新超過 500 次，資料量也超過 200 TB。面對海量的使用者請求和快捷的版本釋出迭代速度，如何才能又快又穩地保障服務的運營？騰訊互娛活動運營團隊給出的解決方案是 DevOps 和雲原生。

以前活動的釋出都是運維人員來操作，隨著活動量快速增長，出現了明顯的瓶頸。為了解決這個問題，騰訊互娛設計了一條從程式碼到生產環境的流水線。現在，活動開發只要把程式碼提交到倉庫，觸發程式碼提交，運營平臺就會自動編譯構建生成映象，並且自動把映象部署到騰訊雲 TKE。從程式碼完成到生產環境釋出完成只需 5 分鐘，並且全程都是開發自助完成。

如今，騰訊互娛運營活動基本上所有的服務都是跑在騰訊雲 TKE。受益於雲原生的技術紅利，服務的彈性伸縮，包括服務擴容、縮容的速度非常快，幾分鐘時間就可以從單副本擴展到一百個副本。

為了更加敏捷的迭代，開發團隊會把一個大型的、難以維護的服務拆分為很多的小服務進行獨立運營。小服務程式碼量少，邏輯較為簡單，所以交接、學習的成本比較低。這種微服務的組織方式逐漸成為大勢所趨，但是隨著小服務越來越多，服務間的呼叫關係也越來越複雜。所以這帶來一個新的問題：一個小服務的異常可能拖垮整條鏈路，帶來連鎖反應。

不同開發對容錯能力的處理也不一樣，有些服務的容錯能力特別好，降級能力也比較完善，但是有些服務就不一定了。還有的告警不及時，故障定位的工具不完善，導致一些故障處理起來比較麻煩。

那如何解決這個問題呢？騰訊遊戲混沌工程團隊給出的答案是：把 PingCAP 開源的 Chaos Mesh 在騰訊雲 TKE 落地，用以解決當前服務故障頻率高、質量控制挑戰大的問題。

混沌工程是 10 年前 Netflix 提出一個概念，Gartner 預計，到 2023 年，將有 40% 的組織把混沌工程實踐作為 DevOps 的一部分，而這將使得故障停機時間減少 20%。

業內對混沌工程的定義是通過主動注入故障，以期提前發現潛在問題，迭代改進架構和運維方式，最終實現業務韌性。換個更熟悉的說法就是：故障演練。

幾乎每一個技術團隊都會去做故障演練，一個服務在上線之前，會測試主備切換是不是生效，容災能力是不是能通過。比如說會把一個 Master 節點關機，看服務能不能自動的切換到 Slave 節點，這些其實就是早期的混沌工程。

混沌工程的雛形就是故障演練，但是故障演練並不等於混沌工程，混沌工程是在故障演練的基礎上擴展出來的新技術，主要體現在出現了專業的混沌工程工具，如 PingCAP 開源的 Chaos Mesh 等產品，以及相關理論體系的建立。

一年前，騰訊互娛正式啟動了混沌工程項目。如何在 K8S 場景下去做混沌工程？當時通過選型對比發現 Chaos Mesh 這個產品相對於其他的產品來說有非常多的優勢，功能明顯要比其他產品要多，程式碼是開源的，不需要額外開發做適配等。並且它本身也是 CNCF 的一個項目，在更新、迭代速度這一塊具備較為明顯的優勢。

為了充分的發揮 Chaos Mesh 的優勢，騰訊互娛混沌工程團隊把它整合到現有的運營平臺，在每個 TKE 叢集都部署了 Chaos Mesh，通過Chaos Mesh提供的dashboard API 來創建、執行、銷燬實驗，同時基於當前運營平臺的能力來觀測實驗效果，許可權上也與現有的運營平臺進行了對接。

從架構圖上來看，Chaos Mesh 是騰訊互娛整個混沌工程體系的核心引擎，它提供了最基礎的故障注入能力，包括 pod 、容器、網路、IO 等故障注入。在這個基礎之上封裝了包括紅藍對抗、故障演練、故障編排、故障觀測等等一整套的混沌工程能力體系。

騰訊互娛混沌工程團隊在使用 Chaos Mesh 的過程中，也跟社群進行了非常多的互動。吳召軍提到，他們給 Chaos Mesh 社群提了非常多的使用反饋和需求，然後這些反饋的 bug 很快就會被修復，許多需求在下一個版本里面就會體現出來，這讓他們的印象深刻。最開始用混沌工程的時候，Chaos Mesh 有一些文件不是很完善，使用時甚至需要連蒙帶猜。但是到了現在這個版本，文件已經非常豐富、非常全面，這一塊他們感覺到進步非常的大。

業界對混沌工程實踐落地上，有一套較為完善的理論體系，吳召軍總結了五個環節。首先是要有個方便好用的做實驗的平臺，這個平臺能夠去編排，下發實驗、執行實驗。然後就是在平臺做實驗計劃需要能有效控制風險，實驗執行過程中需要能實時觀測到實驗穩態指標，實驗發現了問題需要有跟進優化，問題已經解決之後要及時提交驗證和處理。形成一個完整的迭代閉環。騰訊互娛混沌工程團隊也是基於這個理論來實施建設混沌實驗平臺。

這裡就舉一個在騰訊互娛團隊內部的平臺執行實驗的例子，這裡是實驗編排環節，這裡的編排同時支援並行的和序列的，可以在一次實驗裡把所有需要執行的故障全部都編排好，多個服務並行去執行混沌實驗。

吳召軍舉了一個騰訊互娛經常做的一個實驗：測試服務在 CPU 高負載下的表現。他們會先編排實驗，然後下發執行，觀測相關服務的表現。通過運營平臺立馬就可以看到服務的曲線：包括 QPS、延時、響應成功率等等這些業務指標。然後實驗完成之後平臺還可以輸出實驗報告，判斷做這些實驗之後是不是能夠符合預期，並得出實驗結論。

在騰訊互娛有業務方提出希望可以在版本更新後都要都跑一遍混沌工程的套餐。於是混沌工程團隊就把 Chaos Mesh 整合在釋出流水線裡面，在使用者編排釋出的時候就可以把混沌演練這個環節插入進去，這樣每一次釋出都可以直接看得到混沌實驗的執行效果。

有時需要針對某一個賬號做混沌演練，要有效的控制爆炸半徑，只能影響這個賬號。騰訊互娛的做法是在閘道器層劫持流量，並在閘道器層下發實驗。可以針對一個特定的賬號下發延遲故障，觀測這個賬號的表現，實驗可以做到精細化控制。

另外，混沌工程團隊發現即使提供了便捷的混沌實驗平臺，讓開發同學自己左右手互搏也是很枯燥的，很難持久執行。為了將混沌工程落地，騰訊互娛設計了紅藍對抗的玩法，運維同學會經常性的選擇某些服務發起混沌實驗，檢驗開發同學的服務是否具備容錯能力，並把演練結果公示出來。開發同學為了避免出現服務漏洞被廣而告之，會非常積極的去提前做混沌實驗，提前解決掉隱患，形成比較好的良性迴圈。

在微服務的場景下，服務間的依賴關係梳理非常關鍵，非核心服務不能拖垮主服務，混沌工程可以非常方便檢驗強弱依賴關係，給被調服務注入故障，觀察主調服務的指標表現，可以直觀便捷地獲得依賴強弱關係。主動給被調的服務去注入故障，延時超過三秒或者五秒，觀察主調服務的 QPS 或延遲抖動。主調服務抖動，說明它們之間的依賴是比較強的依賴，可以根據場景、具體情況做一些優化。

同時，騰訊互娛現在還在使用混沌工程訓練故障診斷機器人。當服務變複雜之後，故障的概率會變得更大。騰訊互娛現在想做的是，通過混沌工程的方式在現網或者在特定環境做大規模演練，從而訓練出一個故障診斷的模型來幫助定位故障。

騰訊互娛這邊落地雲原生混沌工程有半年左右，事實上混沌工程已經在騰訊互娛內部幾乎所有的團隊都推開了。現在騰訊互娛平均每週混沌演練的次數超過了 150 次，提前發現問題數超過 100 個，每週發起演練總人數超過 50 人。

一般來說，故障演練需要手寫指令碼，比如做一個網路丟包 5% 的故障演練，熟悉的人可能很快把這個指令碼寫出來，如果不熟悉的話，可能要花很多時間去偵錯。混沌工程的優勢就體現在：只需要把這些故障在平臺上做簡單的拖拉拽的編排，不需要要編寫、偵錯指令碼，就能下發實驗並實時觀測實驗效果。故障演練這件事情的成本降低了，效率大大提高。

從騰訊互娛的統計資料來看，通過混沌工程與傳統的故障演練進行對比，混沌工程的效率至少提升了 10 倍以上，這就是做混沌工程最大的收益。