使用Grab的實驗平台進行混沌實驗編排

roman atachiants · tharaka wijebandara · abeesh thomas

原文：

譯：時序

服務部分可用並不是沒有風險。工程師需要對於rpc呼叫非核心服務時需要有有備用計畫。如果應急策略沒有很好地執行，非核心服務的問題也可能導致停機。

所以我們如何保證grab的使用者可以使用核心功能，例如叫車，而此時非核心服務正在出問題？答案是混沌工程。

在grab，我們通過在整體業務流的內部服務或元件上引入故障來實踐混沌工程。但失敗的服務不是實驗的關注點。我們感興趣的是測試依賴這個失敗服務的服務。

照理來說，上游服務應該有彈性並且整體業務流應該可以繼續工作。比如，叫車流程就算在司機位址服務上出現故障時仍應該可以工作。我們測試重試和降級是否配置正確，是否熔斷器被正確的設定。

為了將混沌引入我們的系統，我們使用了我們的實驗平台(exp)和grab-kit.

混沌實驗平台exp將故障注入到處理流量服務的中介軟體(grpc或http伺服器)。如果系統的行為與期望一致，你將對非核心服務故障時服務會平穩降級產生信心。

混沌實驗平台exp在grab的基礎設施中模擬不同的混沌型別，如延遲和記憶體洩漏。這保證了每個元件在系統的依賴不響應或響應很高時仍能返回一些東西。它能保證我們對於例項級失敗有彈性，因為微服務級別的中斷對於可用性也是乙個威脅。

為了構建我們的混沌工程系統，我們認為需要在兩個主要領域引入混沌：

你可以稍後啟用有意的或隨機的混沌實驗：

實驗最後，你可以將故障模式按以下分類：

這些模型都可以在基礎設施或應用級別使用或模擬：

對於grab，進行應用級別的混沌實驗並仔細度量影響面很重要。我們決定使用乙個已有的實驗平台來對圍繞系統的應用級別混沌實驗進行編排，即紫色部分，通過對下層像grab-kit這樣的中介軟體進行注入來實現。

現在有一些混沌工程工具。但是，使用它們經常需要較高階的基礎設施和運維技巧，有能力設計和執行實驗，以受控的方式有資源手工編排失敗場景。混沌工程不是簡單的在生產環境搞破壞。

將混沌工程理解成受控的實驗。我們的exp sdk提供彈性和非同步追蹤。這樣，我們可以將潛在的業務屬性度量對應到混沌失敗上。比如，在訂車服務上進行10秒延遲的混沌故障，我們可以知道多少輛車被影響了進而知道損失了多少錢。

使用exp作為混沌工程的工具意味著我們可以基於應用或環境精確定製，讓它可以像監控和部署管道一樣與其他環境緊密整合。

在安全上也可以獲得收益。使用exp，所有的連線都在我們的內部網路中，給我們攻擊表面區域的能力。所有東西都可以掌控在手中，對外部世界沒有依賴。這也潛在的使監控和控制流量變容易了。

混沌故障可以點對點，程式設計式的，或定期執行。你可以讓它們在特定日期的特定時間視窗來執行。你可以設定故障的最大數量並定製它們（比如****存mb數量，等待的秒）。

exp的核心價值是讓工程師可以啟動，控制和觀察系統在各種失敗條件下的行為。exp提供全面的故障原子集，用來設計實驗並觀察問題在複雜分布式系統發生時的表現。而且，將混沌測試整合到exp，我們對於部署流水線或網路基礎設施不需要任何改動。因此這種組合可以很容易的在各種基礎設施和部署正規化上使用。

要開發混沌工程sdk,我們使用我們已有exp sdk的屬性 - single-digit , 不需要網路呼叫。你可以看這裡對於exp sdk的實現。現在我們要做兩件事：

乙個在exp sdk之上的很小的混沌sdk。我們將這個直接整合在我們的已有中介軟體，如grab-kit和db層。

乙個專門的用來建立混沌實驗的基於web的ui

歸功於我們與grab-kit的整合，grab工程師不需要直接使用混沌sdk。當grab-kit處理進入的請求時，它先使用exp sdk進行檢查。如果請求「應該失敗」，它將產生適合的失敗型別。然後它被**到特定endpoint的處理器。

我們現在支援以下失敗型別：

舉個例子，如果乙個叫車請求到了我們的叫車服務，我們呼叫getvariable(「chaosfailure」)來決定請求是否應該成功。請求裡包含所有需要用來做決定的資訊（如請求id，例項的ip位址等）。關於實驗sdk的實現細節，看這篇部落格。

為了在我們的工程師中推廣混沌工程我們圍繞它建立了很好的開發者體驗。在grab不同的工程團隊會有很多不同的技術和領域。所以一些人可能沒有對應的知識和機能來進行合適的混沌實驗。但使用我們簡化過的使用者介面，他們不需要擔心底層實現。

並且，執行混沌實驗的工程師是與像產品分析師和產品經理不同的實驗平台使用者。所以我們使用一種簡單和定製化ui配置新的混沌實驗來提供一種不同的建立實驗的體驗。

在混沌工程平台，乙個實驗有以下四步：

定義系統正常情況下的理想狀態。

建立乙個控制組的配置和乙個對比組的配置。控制組的變數使用已有值來賦值。對比組的變數使用新值來賦值。

引入真實世界的故障，例如增加cpu負載。

找到區分系統正確和失敗狀態標誌性不同。

要建立乙個混沌實驗，標明你想要實驗破壞的服務。你可以在以後通過提供環境，可用區或例項列表來更細化這個選擇範圍。

下一步，指定一組會被破壞的服務影響的服務列表。你在試驗期間需要仔細監控這些服務。儘管我們持續跟蹤表示系統健康的整體度量指標，它仍能幫助你在稍後分析實驗的影響。

然後，我們提供ui來指定目標組和對比組的策略，失敗型別，每個對比組的配置。最後一步，提供時間週期並建立實驗。你已經在你的系統中加入了混沌故障並可以監控它對系統的影響了。

在執行混沌實驗後，一般會有兩種可能輸出。你已經確認了在引入的故障中系統保持了足夠的彈性，或你發現了需要修復的問題。如果混沌實驗最初被執行在預發環境那麼兩種都是不錯的結果。在第一種場景，你對系統的行為產生了信心。在另乙個場景，你在導致停機故障前發現了乙個問題。

混沌工程是讓你工作更簡單的工具。通過主動測試和驗證你系統的故障模式你減輕了你的運維負擔，增加了你的彈性，在晚上也能睡個好覺。