──混沌工程的落地不僅僅是工具方法的落地也是一種文化和設計的落地
本文旨在通過基本介紹和分享聲網的部分經驗，幫助大家瞭解混沌工程，提高業務服務可靠性。
00 前言
“什麼是混沌工程？聽起來很牛的樣子。”
“混沌工程與我們故障演練有什麼區別？”
“是不是我們通過了混沌測試就不會出問題？”
“這個場景我們不太會遇到，因為客戶沒有這麼操作的。”
上面的話是在我們推進混沌工程的工作時，大家會說到的幾個普遍問題。所以在討論混沌工程(Chaos Engineering)之前，我們需要知道什麼是“混沌工程”，要解決什麼樣的問題，如何保障服務的穩定性。
近些年來，我們軟體系統的規模及複雜度一直不斷的增長，傳統的大單體形式已經無法適應現在的迭代及部署，所以現在的軟體系統更加傾向於發展分散式的系統。分散式系統解決了我們單體架構時期迭代速度慢、技術債高、部署麻煩等問題，但同時也帶來了新的挑戰。根據 Google 2021 的 Devops 調研報告[1] ，我們可以看到越來越多的團隊進行了上雲的實踐，而且也愈發注重軟體交付運營的體驗（software delivery and operational performance） 。如何在分散式系統的快速迭代下，保障系統的穩定高可用，已經是近年來的熱點與難點。
如上圖，我們可以看到一個典型的微服務系統，一個具有服務邊界、鬆耦合的服務結構。傳統的測試方法確實可以在一定程度上確保服務間的可用性。例如契約測試可以儘早發現更多的問題，在頻繁迭代的系統下保障服務間的可用性，但這本質上也是服務呼叫方與提供方的一致性校驗，只是在業務邏輯上做了更好的測試保障。對於微服務系統的特性，例如高可用、服務依賴、分散式一致性等還是缺乏覆蓋。現有的測試手段很難去識別服務間的強弱依賴，也很難去驗證高可用策略的完備性，而混沌工程的出現，給了我們解決問題的思路以及方法。
01 概述
那什麼是混沌工程呢？
混沌工程是在分散式系統上進行實驗的學科，目的是建立對系統抵禦生產環境中失控條件的能力以及信心。混沌工程不是一項測試，有著明確的輸入輸出、是一個實踐性的學科，用來觀察系統的薄弱點以進行改進。
我們為什麼需要混沌工程呢？
在現實世界中，故障無處不在。我們在內部也對一部分應用服務進行了回顧與統計，發現結果與混沌工程實驗室《2021年中國混沌工程調查報告》[5]相似，這裡引用混沌工程實驗室的結果：
從中可以看到，變更類故障是引發重大事故的主要原因，線上機器也永遠不會是 Stable 的狀態。根據海恩法則，我們可以得知：每起嚴重事故背後，必然有 29 起輕微事故、300 起未遂徵兆和 1000 個隱患。合理運用混沌工程能夠很好的弱化以上問題，下圖即為聲網落地實踐的結果。
混沌工程與我們故障演練有什麼區別？
故障演練可以看做混沌工程的一種具體實踐。故障演練是通過向目標系統注入真實可能發生的故障來觀測系統的穩定性，但注入的場景相對是固定、已知的。混沌工程除了在其基礎上提供了一些理論指導以外，還是一個發現新問題的實踐過程，例如對某個區域進行服務重啟等。
02 如何實施
在開始進行混沌工程之前，我們要先確定我們的系統已經有了一些高可用的特性，可以在部分異常的情況下繼續正常工作。我們可以根據混沌工程原則[2]中的基本實踐原則進行如下實驗：
1.首先，用系統在正常行為下的一些可測量的輸出來定義“穩定狀態”。
2.其次，假設這個穩定狀態在控制組和實驗組都會繼續保持穩定狀態。
3.然後，在實驗組中引入反映真實世界事件的變數，如伺服器崩潰、硬碟故障、網路連線斷開等。
4.最後，通過控制組和實驗組之間的狀態差異來反駁穩定狀態的假說。
如果混沌工程實施下來發現兩者狀態一致，則基本認為是可以通過此故障的；如果狀態不一，那我們就找到了一個薄弱點，可以針對性地提高系統的穩定性。
這其中包含兩個關鍵點：
1.如何產生故障
2.如何觀測故障
在混沌工程實踐的相關文章中，談論最多的可能就是如何產生故障，市面上比較流行的有 ChaosBlade[3]、Chaos Mesh[4] 等工具，工具的選擇是和實際業務情況密不可分的。根據 Google 的調研[1]，現在選擇混沌雲方案進行部署的公司也越來越多，上述的單一工具也一定無法滿足所有的需求，所以如何滿足自身業務需求可能會是部分團隊比較頭痛的問題。就聲網的經驗來說，自研是不可避免的，從易用性上來說也需要提供一個平臺去提供全能力的支援。做比空想更重要，先實現並驗證場景，然後在業務中進行實驗，後續再進行優化可能是更好的一條路。
很多文章比較少提及的點就是如何觀測實際故障的發生，這反而是我認為最為重要的一個點。現如今，各公司基本都會有監控報警平臺，但還是有很多情況在我們的監控報警未響應時被使用者所發現，即監控系統未報警但使用者先報障了。這才是我們進行混沌工程最大的阻力——不能有效地發現問題。去解決此問題，在聲網的實踐過程中，我們總結了幾個可供參考的點：
1.補足所有基礎資源監控，並在實驗過程觀察所有基礎資源是否會受影響。我們曾經就遇到過核心異常導致 slab memory 洩露的情況，這個問題就需要基礎資源的監控來進行發現。
2.完善業務 SLI(Service Level Indicator)指標。根據自身業務的特點以及客戶關心的點定義 SLI 指標來進行觀測，例如 Netflix 就採用 SPS（播放按鈕的點選率）進行觀測。指標的要求不一定是恆定，可以有著某種變化的規律，但指標一定要容易測量以及統計週期短。測量的難度越高，說明描繪業務狀態的手段越少，需要進行思考及改進；統計週期越長，越有可能會略掉中間問題的點。
03 演進及評價標準
上一章節主要介紹了混沌工程的一些方法以及思路，那我們做了以後如何去評價，如何持續前進呢。從成熟度來看，我們認為落地大概會分為幾個階段：
1.單體實驗階段：本階段主要是在單節點上進行故障的場景開發、驗證以及在單節點的故障實驗。
2.故障實施工具化：本階段會針對業務進行故障實施的開發以及在業務上進行實驗，並初步進行自動化、工具化及整合進 CI/CD。
3.故障實施平臺化：本階段會進行自動的故障演練，範圍也逐漸從測試環境到生產環境，並且易用性大幅提升。
4.混沌價值產出：本階段可以提供混沌工程的價值，如供客戶去使用、提高客戶自身服務的穩定性；使用、應用 AIOps 等手段進行一些異常的預警、監測，向著 0 故障不斷前進。
上面講了那麼多，我們最終還是要為減少線上故障服務。如果不清楚做的情況，無法進行持續的改進，那就無法真正的閉環，最終不孚眾望，無法真正落地。混沌工程能夠幫助我們減少可用性問題，發現業務隱患，但我們很難用發現隱患的數量來衡量我們的工作，這充滿不確定性。那麼我們結合自身情況定義了自己的評價標準：
評價手段
• 使用者場景
混沌工程的最終受益者是穩定可靠的使用者體驗。那在混沌工程成熟度不高的前提下（還未有信心在生產環境進行實踐），在測試環境或者預釋出環境中能夠模擬線上場景的程度越高，我們也越有信心保障上線的可用性。另一方面，使用者使用場景是可以被感知的，我們可以通過覆蓋更多的使用者使用場景，更好的發現問題，增強業務信心。所以我們通過對測試場景佔線上使用者使用場景的比例來評估覆蓋度，越高越好。
• 混沌場景
一指標的選擇是較為通用的，對於混沌工程，我們一定會設計對比實驗，如何設計是有章法可循的。所以混沌工程的場景可以通過業界的通用故障，業務特性隱患以及業務歷史故障來整體預估。我們支援的場景越多，業務也越有信心。
• 服務指標
服務指標的來源可以是 SLO(Service Level Object)、SLI，在 Agora 我們也選用 XLA（eXperience Level Agreement）。混沌工程需要與業務共同建設業務的指標，這一指標也是線上運維 & 混沌工程需要觀測的指標。指標越完善，我們在對業務進行測試時，也有了更加好評判的標準，也更有信心。
04 總結
從聲網的建立初始就有了對可用性的投入，到現在已經成為了內部的標準與體系（見下圖）。
混沌工程不是萬能藥，是要結合公司的實際來進行設計和落地，對於可用性的投入也不僅僅是測試或者運維團隊，更應該是從流程上、從設計上都進行考慮，所以混沌工程的落地不僅僅是工具方法的落地，也是一種文化、設計的落地。
05 引用
[1] Accelerate State of DevOps 2021
https://services.google.com/fh/files/misc/state-of-devops-2021.pdf
[2] PRINCIPLES OF CHAOS ENGINEERING
https://principlesofchaos.org/
[3] ChaosBlade
https://github.com/chaosblade-io/chaosblade
[4] Chaos Mesh
https://github.com/chaos-mesh/chaos-mesh
[5] 混沌工程實驗室: 中國混沌工程調查報告(2021年)
http://www.caict.ac.cn/kxyj/qwfb/ztbg/202111/P020211115608682270800.pdf
Dev for Dev專欄介紹
Dev for Dev（Developer for Developer）是聲網Agora 與 RTC 開發者社群共同發起的開發者互動創新實踐活動。透過工程師視角的技術分享、交流碰撞、專案共建等多種形式，匯聚開發者的力量，挖掘和傳遞最具價值的技術內容和專案，全面釋放技術的創造力。