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

前 言

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

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

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

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

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

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

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

1、探索算法

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

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

image.png

故障集: (A|R|P|B) 機器學習

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

三個潛在的結果:

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

在此示例中,評價(Ratings)故障,請求成功,從而生成了如下圖表:

image.png

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

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

image.png

故障集: (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數據擴展了的請求依賴樹:

image.png

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時代的敏捷領導力》
相關文章
相關標籤/搜索