在現實世界中，故障無處不在。我們在內部也對一部分應用服務進行了回顧與統(tǒng)計，發(fā)現結果與混沌工程實驗室《2021年中國混沌工程調查報告》[5]相似，這里引用混沌工程實驗室的結果：

從中可以看到，變更類故障是引發(fā)重大事故的主要原因，線上機器也永遠不會是 Stable 的狀態(tài)。根據海恩法則，我們可以得知：每起嚴重事故背后，必然有 29 起輕微事故、300 起未遂征兆和 1000 個隱患。合理運用混沌工程能夠很好的弱化以上問題，下圖即為聲網落地實踐的結果。

混沌工程與我們故障演練有什么區(qū)別？

故障演練可以看做混沌工程的一種具體實踐。故障演練是通過向目標系統(tǒng)注入真實可能發(fā)生的故障來觀測系統(tǒng)的穩(wěn)定性，但注入的場景相對是固定、已知的。混沌工程除了在其基礎上提供了一些理論指導以外，還是一個發(fā)現新問題的實踐過程，例如對某個區(qū)域進行服務重啟等。

02 如何實施

在開始進行混沌工程之前，我們要先確定我們的系統(tǒng)已經有了一些高可用的特性，可以在部分異常的情況下繼續(xù)正常工作。我們可以根據混沌工程原則[2]中的基本實踐原則進行如下實驗：

1. 首先，用系統(tǒng)在正常行為下的一些可測量的輸出來定義“穩(wěn)定狀態(tài)”。

2. 其次，假設這個穩(wěn)定狀態(tài)在控制組和實驗組都會繼續(xù)保持穩(wěn)定狀態(tài)。

3. 然后，在實驗組中引入反映真實世界事件的變量，如服務器崩潰、硬盤故障、網絡連接斷開等。

4. 最后，通過控制組和實驗組之間的狀態(tài)差異來反駁穩(wěn)定狀態(tài)的假說。

如果混沌工程實施下來發(fā)現兩者狀態(tài)一致，則基本認為是可以通過此故障的；如果狀態(tài)不一，那我們就找到了一個薄弱點，可以針對性地提高系統(tǒng)的穩(wěn)定性。

這其中包含兩個關鍵點：

1. 如何產生故障

2. 如何觀測故障

在混沌工程實踐的相關文章中，談論最多的可能就是如何產生故障，市面上比較流行的有?ChaosBlade[3]、Chaos Mesh[4]?等工具，工具的選擇是和實際業(yè)務情況密不可分的。根據?Google 的調研[1]，現在選擇混沌云方案進行部署的公司也越來越多，上述的單一工具也一定無法滿足所有的需求，所以如何滿足自身業(yè)務需求可能會是部分團隊比較頭痛的問題。就聲網的經驗來說，自研是不可避免的，從易用性上來說也需要提供一個平臺去提供全能力的支持。做比空想更重要，先實現并驗證場景，然后在業(yè)務中進行實驗，后續(xù)再進行優(yōu)化可能是更好的一條路。

很多文章比較少提及的點就是如何觀測實際故障的發(fā)生，這反而是我認為最為重要的一個點?，F如今，各公司基本都會有監(jiān)控報警平臺，但還是有很多情況在我們的監(jiān)控報警未響應時被用戶所發(fā)現，即監(jiān)控系統(tǒng)未報警但用戶先報障了。這才是我們進行混沌工程最大的阻力——不能有效地發(fā)現問題。去解決此問題，在聲網的實踐過程中，我們總結了幾個可供參考的點：

1. 補足所有基礎資源監(jiān)控，并在實驗過程觀察所有基礎資源是否會受影響。我們曾經就遇到過內核異常導致 slab memory 泄露的情況，這個問題就需要基礎資源的監(jiān)控來進行發(fā)現。

2. 完善業(yè)務 SLI(Service Level Indicator)指標。根據自身業(yè)務的特點以及客戶關心的點定義 SLI 指標來進行觀測，例如 Netflix 就采用 SPS（播放按鈕的點擊率）進行觀測。指標的要求不一定是恒定，可以有著某種變化的規(guī)律，但指標一定要容易測量以及統(tǒng)計周期短。測量的難度越高，說明描繪業(yè)務狀態(tài)的手段越少，需要進行思考及改進；統(tǒng)計周期越長，越有可能會略掉中間問題的點。

03 演進及評價標準

上一章節(jié)主要介紹了混沌工程的一些方法以及思路，那我們做了以后如何去評價，如何持續(xù)前進呢。從成熟度來看，我們認為落地大概會分為幾個階段：

1. 單體實驗階段：本階段主要是在單節(jié)點上進行故障的場景開發(fā)、驗證以及在單節(jié)點的故障實驗。

2. 故障實施工具化：本階段會針對業(yè)務進行故障實施的開發(fā)以及在業(yè)務上進行實驗，并初步進行自動化、工具化及集成進 CI/CD。

3. 故障實施平臺化：本階段會進行自動的故障演練，范圍也逐漸從測試環(huán)境到生產環(huán)境，并且易用性大幅提升。

4. 混沌價值產出：本階段可以提供混沌工程的價值，如供客戶去使用、提高客戶自身服務的穩(wěn)定性；使用、應用 AIOps 等手段進行一些異常的預警、監(jiān)測，向著 0 故障不斷前進。

上面講了那么多，我們最終還是要為減少線上故障服務。如果不清楚做的情況，無法進行持續(xù)的改進，那就無法真正的閉環(huán)，最終不孚眾望，無法真正落地。混沌工程能夠幫助我們減少可用性問題，發(fā)現業(yè)務隱患，但我們很難用發(fā)現隱患的數量來衡量我們的工作，這充滿不確定性。那么我們結合自身情況定義了自己的評價標準：

評價手段

? 用戶場景

混沌工程的最終受益者是穩(wěn)定可靠的用戶體驗。那在混沌工程成熟度不高的前提下（還未有信心在生產環(huán)境進行實踐），在測試環(huán)境或者預發(fā)布環(huán)境中能夠模擬線上場景的程度越高，我們也越有信心保障上線的可用性。另一方面，用戶使用場景是可以被感知的，我們可以通過覆蓋更多的用戶使用場景，更好的發(fā)現問題，增強業(yè)務信心。所以我們通過對測試場景占線上用戶使用場景的比例來評估覆蓋度，越高越好。

? 混沌場景

一指標的選擇是較為通用的，對于混沌工程，我們一定會設計對比實驗，如何設計是有章法可循的。所以混沌工程的場景可以通過業(yè)界的通用故障，業(yè)務特性隱患以及業(yè)務歷史故障來整體預估。我們支持的場景越多，業(yè)務也越有信心。

? 服務指標

服務指標的來源可以是 SLO(Service Level Object)、SLI，在 Agora 我們也選用 XLA（eXperience Level Agreement）?；煦绻こ绦枰c業(yè)務共同建設業(yè)務的指標，這一指標也是線上運維 & 混沌工程需要觀測的指標。指標越完善，我們在對業(yè)務進行測試時，也有了更加好評判的標準，也更有信心。

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 開發(fā)者社區(qū)共同發(fā)起的開發(fā)者互動創(chuàng)新實踐活動。透過工程師視角的技術分享、交流碰撞、項目共建等多種形式，匯聚開發(fā)者的力量，挖掘和傳遞最具價值的技術內容和項目，全面釋放技術的創(chuàng)造力。