Netflix: 訓練更聰明的混沌猴子 | IDCF

前 言

在Netflix，咱們發現主動的故障測試是一個很是棒的方法，幫助咱們在生產環境中發現潛在的問題，爲咱們的用戶提供了可靠的產品。

咱們作的全部努力（雖然有些是手動的），幫助咱們順利地沒有意外地度過了整個假期（若是在除夕之夜被選中值班，那就更好了！😊）。

可是誰喜歡手動的工做呢？另外，咱們只測試預期的失敗，每次練習一般只針對單個服務或組件進行測試。咱們要作得更好！

想象一下，一隻猴子在你的代碼和基礎架構中爬行，注入小的故障並檢查其是否致使用戶影響。

在探索構建這種猴子的過程當中，咱們發現了由彼得·阿爾瓦羅（Peter Alvaro）開發的稱爲Molly的故障測試方法。（http://www.cs.berkeley.edu/~p...）

鑑於咱們已經有了一個稱爲FIT（Fault Injection Test）的故障注入服務，相信咱們能夠在短時間內構建一個原型實現。（https://medium.com/@Netflix_T...）

咱們認爲，把Molly論文中闡述的概念應用到大規模生產中，這很是有意義。所以，咱們與Peter取得了聯繫，瞭解他是否有興趣共同構建原型。如下就是咱們的合做結果介紹。

1、探索算法

「依賴樹驅動的故障注入（LDFI）逆向地從正確的系統輸出中，斷定注入故障是否會改變輸出結果。」

Molly首先查當作功請求的全部內容，而後問：「哪些因素會改變這個結果？」 咱們如下面這個簡化的請求爲例：

故障集: (A|R|P|B)

一開始，咱們假設全部都是必要的因素。而後，假設用戶影響是由A或R或P或B故障引發的，其中A表明API（其餘以此類推）。咱們首先從潛在故障點中隨機選擇並從新執行該請求，並在選定點注入故障。

三個潛在的結果：

• 請求失敗：面臨失敗（未來的實驗須要調整以包含此故障）
• 請求成功：服務/故障點並不重要
• 請求成功：故障點被接管自動恢復了（故障轉移或回退）

在此示例中，評價（Ratings）故障，請求成功，從而生成了如下圖表：

故障集: (A|P|B) & (A|P|B|R))

由此可瞭解該請求的更多信息和故障點狀況。因爲播放列表（Playlist）是一個潛在故障點，所以咱們接下來將其失效，生成如下圖表：

故障集: (A|PF|B) & (A|P|B) & (A|P|B|R))

這說明了上面第三個潛在的結果。因爲執行了故障接管操做（PlaylistFallback），該請求仍然成功。因此，咱們有了一個新的故障點須要探索，同時更新實驗範圍，並進行清理、注入並重復，直到沒有更多的故障點可探索爲止。

Molly對如何探索這個搜索空間沒有規定。咱們的實現方式是：先列出故障點失效的全部可能性，而後從最小組合中隨機選擇。例如，[{A}，{PF}，{B}，{P，PF}，{R，A}，{R，B}…]。

探索從全部單點故障開始：A，PF，B；而後繼續兩個故障的組合，依此類推。

2、自動故障測試實現

2.1 依賴樹梳理

Netflix請求的依賴樹是什麼？

利用鏈路跟蹤系統，可爲整個微服務構建請求依賴樹。經過FIT，咱們可用「注入點」的方式得到更多信息。這些都是系統可能發生故障的關鍵拐點。

注入點，包括Hystrix命令執行、高速緩存查找、數據庫查詢、HTTP調用等等。

FIT提供的數據幫助咱們構建更完整的依賴樹，這就是算法分析的輸入。

在上面的示例中，咱們看到了簡單的服務請求樹。如下是是利用FIT數據擴展了的請求依賴樹：

2.2 成功的標準

「成功」是什麼？最重要的即是用戶體驗，須要一種衡量標準來反映這一點。爲此，咱們利用了設備報告的指標集。經過分析這些指標，就能夠肯定請求是否會產生用戶影響。

另外一種更簡單的方法是依靠HTTP狀態代碼肯定成功的結果。可是狀態碼可能會引發誤解，由於某些框架在部分紅功時就返回「200」的狀態，而在請求內容才放置用戶影響的錯誤描述。

目前，只有部分Netflix請求具備相應的設備報告指標。爲更多請求類型添加設備報告的指標後，咱們就有機會擴展自動故障測試以覆蓋更普遍的設備流量。

2.3 冪等操做

支持回放請求使Molly簡單易用，但咱們目前作不到。在收到請求時不知道該請求是否等價，不知道是否能夠安全地回放。

爲了彌補這一點，咱們將請求分紅多個等效類，每一個類中的請求「具備」相同的功能，即執行相同的依賴調用並以相同的方式失敗。

爲了定義請求類，咱們着重使用收到的請求信息：

• 路徑（netflix.com/foo/bar）
• 參數（?baz=boo）
• 發出請求的設備信息

咱們先嚐試去查看這些請求功能和依賴項之間是否存在直接映射。事實並不是如此。接下來，咱們探索了使用機器學習來查找和建立這些映射的方法。這彷佛是有但願的，可是須要大量的工做才能使其正確。

相反，咱們將範圍縮小到只檢查Falcor框架生成的請求。這些請求經過查詢參數提供了一組json路徑以供請求加載，即「視頻」、「配置文件」、「圖像」。咱們發現這些Falcor路徑元素與加載這些元素所需的內部服務一致。

將來的工做須要找到一種更通用的方法來建立這些請求類別映射，以便咱們能夠將測試範圍擴展到Falcor請求以外。

這些請求類別，會隨Netflix工程師編寫和部署的代碼而變化。爲了抵消這種偏移，咱們會天天對設備報告的指標集進行抽樣，對潛在的請求類別進行分析。無流量的舊類別使之過時，新的代碼路徑則建立新的類別。

3、用戶影響

請記住，此探索的目標是在故障影響大量用戶以前找到它並修復。在運行咱們的測試時，引發大量用戶影響，這是不可接受的。

爲了減輕這種風險，咱們重塑了探索方式，實如今任何給定時間段內只進行少許實驗。

每一個實驗的範圍都只針對一種請求類別，實驗運行時間很短（20-30秒），受影響的用戶數很小。

咱們但願每一個實驗至少有10個好的示例請求。

爲了濾除誤報，咱們會查看實驗的整體成功率，超過75%請求的失敗狀況標記爲已發現的失敗。
因爲咱們的請求類映射不是完美的，因此咱們還會過濾掉因爲某種緣由沒有執行要測試的失敗請求。

假設咱們一天能夠運行500個實驗。若是咱們每次運行均可能影響10個用戶，那麼最壞的影響是天天有5,000個用戶受到影響。

可是，並不是每一個實驗都會致使失敗。實際上，大多數實驗都會成功。

若是10%的實驗中發現失敗（較高的估計值），那麼實際上咱們天天會影響500個用戶的請求，而重試能夠進一步緩解。

當天天處理數十億個請求時，這些實驗的影響就很小了。

結 果

咱們很幸運，「App Boot」請求，做爲最重要的Netflix請求之一，知足了咱們的探索標準。該請求會加載運行Netflix應用，以及用戶視頻初始列表所需的元數據。

對於Netflix而言，這是一個關鍵時刻，咱們但願從一開始就向客戶提供可靠體驗來贏得他們。

這也是一個很是複雜的請求，涉及數十個內部服務和數百個潛在的故障點。

對這個空間的蠻力探索須要2^100次迭代（大約30個零），而咱們的方法可以在大約200次實驗中對其進行探索，並從中發現了五種潛在的故障，其中一種是故障點的組合。

一旦發現故障，咱們該怎麼辦？

好吧，還得手動處理。咱們尚未達到能自動修復故障的地步。

在這種狀況下，咱們有一個已知故障點的列表，以及一個容許某些人使用FIT重現故障的「方案」。由此，咱們能夠驗證故障並肯定解決方案。

咱們很高興可以構建此原型實現，驗證明施並使用它來發現真正的故障。

咱們也但願可以擴展它，以自動方式搜索更多的Netflix請求空間，在真正的故障發生以前，找到更多會產生用戶影響的潛在故障點，並解決它們！

來源：混沌工程實踐

做者：三水蝸牛 原文做者：Kolton Andrus, Ben Schmaus

標題：Automated Failure Testing, aka Training Smarter Monkeys

出處：Netflix Technology Blog

聲明：文章得到做者受權在IDCF社區公衆號（devopshub）轉發。優質內容共享給思否平臺的技術同伴，如原做者有其餘考慮請聯繫小編刪除，致謝。

6月每週四晚8點，【冬哥有話說】開心一「夏」。公衆號留言「開心」可獲取地址

• 0603 無敵哥 《IDCF人才成長地圖與5P》（《端到端DevOps持續交付(5P)精品課》第1課）
• 0610 冬哥 《帶你玩轉創新設計思惟》
• 0617 無敵哥 《敏捷項目管理究竟是個啥》
• 0624 冬哥 《VUCA時代的敏捷領導力》