Gremlin: 擁抱失敗的混沌工程實踐 | IDCF

譯者語：這是一篇Kim Harrison現場轉播記錄關於混沌工程與失敗的主題演講。該演講是LaunchDarkly在舊金山組織的關於「失敗」主題線下活動的一部分。演講者Ana Medina[2]是供職於Gremlin公司的混沌工程師。
其實中國古人早就參透了其中道理：失敗乃成功之母。
我試圖從Ana的演講中分出了四個部分，她分別詳盡討論了爆炸半徑，遊戲日活動，星期四下線實踐和on-call與培訓四個部分。Gemlin在文化層面對於失敗和混沌工程的思考是最近幾年業界先進實踐值得咱們仔細學習。對比Netflix的ChAP博客文章，Ana的故事更貼近於咱們平常的工做，爲咱們從各個角度實踐混沌工程提供了參考。可謂是乾貨滿滿，請你們欣賞。

在生產環境進行測試又來了！五月份咱們在舊金山Microsoft Reactor舉行了線下的聚會。此次活動主要聚焦於關於失敗"的文化。特別地，咱們想聆聽和學習"失敗"文化（避免失敗，從失敗中恢復，從失敗中學習）是如何影響在生產環境中進行測試的。

Ana Medina, 本次的演講嘉賓，現任Gremlin的混沌工程師。她講述瞭如何實施混沌工程實驗而且讚美了"失敗"文化是如何幫助工程師造成肌肉記憶，投入更多時間開發功能和創建更具韌性的複雜系統的實踐中起到的做用。

"咱們要試圖更多地去創建這樣的勇氣：嘗試接受失敗終將發生的想法，也要你的組員接受失敗而且可以慶祝失敗的發生，而且可以意識到咱們可以從失敗中學到不少東西"

——Ana Medina，Gremlin混沌工程師

主持人：好了，你們準備好來點兒混沌了麼？對此我很是興奮。我很喜歡這個主題，混沌工程中的失敗和混沌工程如何成爲你成功的關鍵。有請下一位演講者，現任Gremlin的混沌工程師。Gremlin幫助企業用戶實施混沌工程從而避免了服務的失效和中止。Ana Medina曾供職於Uber，做爲基礎設施團隊的SRE聚焦於混沌工程與計算，現供職於Gremlin。讓咱們有請Ana。

Ana Medina：嗨！你們好！謝謝你們今天來捧場，也謝謝你們堅持到最後一個演講。很是激動可以和你們分享一些關於失敗和混沌工程的故事。

我是Ana Medina，我是來自Gremlin的混沌工程師。

Human are fallible "人類是易犯錯的"

易犯錯的意思就是製造錯誤或者犯錯誤。你們能夠舉手告訴我是否有人曾經犯過錯誤呢？是的，是的，你們都會犯錯，對吧？

我實際上想告訴你們的是使用另外一種方式看待問題。我想跟你們聊一聊創建和學習一種接受錯誤的文化。我相信這種兼收幷蓄的文化就是擁抱和注入失敗，這也是我今天所要討論的。

哲學家尼采說，"任何勇敢的人面對已知的危險也會缺少勇氣"。咱們要試圖更多地去創建這樣的勇氣：嘗試接受失敗終將發生的想法，也要你的組員接受失敗而且可以慶祝失敗的發生，並且可以意識到咱們可以從失敗中學到不少東西。

因此，咱們要作些什麼事兒呢？好的，今天我將講一講混沌工程。在座的各位是否能夠舉手示意我，有多少人據說過混沌工程？酷！太棒了！很高興據說你們已經在生產環境的測試中討論混沌工程了！它已經傳播開了！

那麼讓咱們再歸納一下，什麼是混沌工程呢？混沌工程是爲了揭露咱們系統的弱點而設計的，通過深思熟慮和詳盡計劃的實驗。它不是僅僅試圖於進行實驗並但願一切順利；而是要進行深思熟慮和詳盡計劃的實驗。

因此當同事們聽到混沌工程的時候常常會像這樣反應："等等！不！我不想讓別人破壞個人生產環境僅僅是由於他們能夠。"或者是咱們事先沒有作任何事兒就直接在週一貫你們宣佈："咱們今天要在生產環境進行混沌工程實驗"，而後同事們或者拔出網線或者關閉服務器等等各類混沌的事兒。不，這不是混沌工程實驗，它們既沒有詳盡計劃也沒有深思熟慮。

因此在Gremlin咱們把混沌工程類比於向你的系統中注入疫苗使得其從有害入侵中得到免疫。也就是說這實際上要讓你的工程師們事先就準備好應對這些失敗的場景。

爆炸半徑

什麼是混沌工程的法則呢？首先從一個實驗出發。而後考慮它的爆炸半徑而且進行下面的抉擇，要麼擴大實驗爆炸半徑並劃定範圍，要麼打斷實驗而且修復未被揭露的問題，而且再次進行重複實驗。

因此如圖所示，這就是咱們所說的爆炸半徑。首先從一個很是很是小的初始測試開始，而後你能夠看到混沌工程實驗在擴大，再以後你也許會看到混沌工程實驗成功了，正如咱們上文所描述的同樣。這樣的作法就比如，實際上你並不知道一個混沌工程實驗會給你兩個服務器帶來什麼樣的影響，爲何你要在100%的資源上進行實驗？因此你實際上須要從一個深思熟慮的方向出發，"我要從一個服務器開始，一個容器，就從一個服務開始。而後逐漸地持續地擴大爆炸半徑"。

這也意味着，也許我尚未信心在咱們的生產環境上進行混沌工程實驗。沒問題，咱們能夠從測試環境開始，從QA環境開始，在混沌工程實驗成長到足夠成熟以後，再於生產環境進行實驗。

在咱們討論爆炸半徑時，另一件須要咱們思考的事情是終止條件。是什麼可使得混沌工程實驗中止下來呢？有一些實踐包括了咱們的錯誤率升高，好比當我看到用戶的錯誤率升高或者API調用的錯誤頻率增高，那麼咱們就觸發使得實驗中止。或者當個人用戶出現了不少延遲，好比咱們在一個iOS生產環境上運行關閉容器的混沌工程實驗，當你看到先前只需幾毫秒加載的圖片須要五秒以上的時間才能在用戶的屏幕上出現的時候，你可能實際上須要下一步的操做來中止這個實驗了。

可是在討論混沌工程的時候你還有一個事情須要考慮，就是你的混沌工程平臺自己須要一個大紅按鈕（a big red button）！這個功能意味着當你從監視器或觀測系統發現你的用戶端受到了失敗的混沌工程實驗的影響，你有能力經過按下大紅按鈕來中止和恢復一切。

可見正如我所說，當咱們實施混沌工程的時候，要深思熟慮和精心計劃。咱們使用科學的方式來達到這個目標。一切從一個假說（hypothesis）開始。好比咱們說："若是我中止個人容器和Redis，我相信個人備用（Replica）Redis將會變成主要的（Primary）Redis。我不會遭受數據丟失的影響，我會繼續享受良好的用戶體驗，一切都會平穩的運行，由於我有良好的Redis配置。"

讓咱們繼續，你繼續上述假說實施了混沌工程實驗（我在去年11月的AWS re:Invent上也討論了這個例子）。咱們關閉了個人主要Redis容器，而後這下好了，我玩兒完了。由於我意識到個人開箱即用的Redis基本配置使得備份容器會觀測主要Redis容器（以保持同步）。當主要Redis被關閉而備用Redis容器看到一個空的主要Redis容器時候，備用Redis容器也清空了本身自己，而且被提高爲主要Redis容器。咱們丟失了全部Redis中的數據！

固然了，若是你在生產環境實施了這個實驗，那麼數據的丟失會給你的公司帶來很大的經濟損失，你的用戶也會怨聲載道。因此你沒必要要作這麼極端的實驗。那麼你要思考的是首先在一個相對安全的空間內實施混沌工程實驗，這樣實際上你能夠驗證配置的正確性，而且可以保證並經過監視工具和觀測工具驗證沒有數據的丟失，這也是工程師須要付出行動的地方。所以，當客戶再也沒法訪問應用程序上的任何數據時，你實際上並不會發現他們真的不滿意。

下一步，當你看到混沌工程實驗成功或者失敗以後，你須要分享這些結果。你須要分享這些"失敗"。你想告訴你的同事們："嗨，話說咱們上個月實施了一些混沌工程實驗，而後咱們探測到應用程序沒有正確的的配置，咱們要作下面這些步驟可讓咱們的應用程序更加有韌性，更加可靠。" 這樣來分享實驗結果是很是關鍵的一個部分。

（Ana再次展現了上圖）這仍是爆炸半徑的圖，咱們把全部的東西都放在一塊兒。首先咱們實施第一個初始的混沌工程實驗。咱們分析這些結果，咱們看到一切都很成功，所以咱們拓展爆炸半徑而後持續進行混沌工程實驗。

遊戲日

如今我想聊一點兒關於"失敗"的文化，聊一點兒我看待失敗發生的見解，以及我三年來實踐混沌工程的更多感覺。我以前加入Uber的混沌工程小組而且學習瞭如何搭建內部的工具，還爲它的運行值守。它給我了不少樂趣，我也從中學習到了不少。可是這個經歷也使我意識到我想要加入一個幫助其餘企業進行混沌工程的公司。

接下來我要開始講講"遊戲日"（Game Day）。在Gremlin，咱們主動的擁抱失敗而且不斷地告訴咱們的用戶也要如此。固然咱們告訴用戶要用Gremlin來作這件事。可是還有一件事兒，嗯，就是咱們作一個叫作"遊戲日"的實踐。簡單來講咱們把一個團隊叫到一塊兒，討論他們的架構圖而且思考什麼樣的錯誤和失敗會發生。Gremlin實際上有一整捆如何進行遊戲日的資源，他們放在一塊兒包括了目錄模板，可用的混堵工程實驗模板，郵件模板等等。可是這個點子其實是要你們在一塊兒思考架構圖，而且思考什麼樣的失敗在什麼地方會實際上發生。

這也是一個絕佳的時機回頭來看事故發生後的回顧和思考，"嗨，咱們實際上在幾個月前發生過一個事故，如今咱們想肯定咱們已經正確執行了應對措施。" 那麼你就能夠按照相同的條件來實施混沌工程實驗，從而知足你的事故發生後的回顧需求。

因此在Gremlin咱們實際上也是在這麼作的。咱們在Gremlin上使用Gremlin。咱們明確的使用軟件服務自我試用原則，咱們也想肯定它真的是具備韌性的而且可以爲咱們的員工展現其韌性。在兩個月以前，咱們把遊戲日的線路圖放在一塊兒，而且收集同事們的想法。"嗨，你想作混沌工程實驗，可是並不須要知道從哪裏開始？" 這樣咱們就寫出了像SRE手冊同樣的遊戲日線路圖，而且也思考了用SRE心態構建事物的方式的層次結構。

第一個基礎層面就是要肯定你的監測和告警要正確的配置和創建。咱們如今已經發表了博客，介紹了Gremlin實施遊戲日來驗證咱們的告警和監測系統。咱們是上個月發表的，揭示了一大堆乾貨。咱們已經可以從咱們的監測工具Datadog中學到不少東西了。上週五咱們剛剛在生產環境進行了遊戲日。咱們試圖去驗證生產環境的監測系統正確的運行。而且試圖去回答同事們是從手冊中尋找解決步驟仍是真的從實驗中獲得啓示而去解決問題。咱們很高興有這樣的互動。
遊戲日給咱們帶來的體驗是可以把任何人彙集在一塊兒。因此當我告訴別人他們想要把混沌工程帶到他們的公司，其實是在告訴他們："嗨，帶上一些實習生，中等水平的工程師和你的架構師們，這樣你能夠分享知識，而且可以一塊兒學習，檢查最終的決定，最後咱們就能爲公司帶來成功。"

星期四下架

另一個咱們不斷擁抱失敗而且可以實施一些混沌工程實驗的事情叫作"星期四下架"（Takedown Thursdays）。有趣的是，咱們以前把它叫作"星期五宕機"（Failure Fridays），可是隨着公司的發展壯大，咱們意識到在週五晚上進行混沌工程實驗真的變得愈來愈困難了。咱們有默認的遠程工做模式，因而在東海岸的員工在週五就須要加班，因而爲了他們咱們就變成了"星期四下架"。咱們在這天實際上會作一些新功能的發佈，或者各類新的嘗試。因而你們就聚到一塊兒，主要是產品的工程師，他們會思考各類不一樣的毀壞產品的方法。因此你不只僅是在使用這個產品應用，咱們還在後端進行混沌工程實驗，包括了底層的測試或者普遍意義上的應對高負載的事件。

我還要討論一個的話題，使用混沌工程進行斷路失敗過後的重現能促進和提升"失敗"文化。這也正是咱們說的關注事故後的回顧而且再次思考。"嗨，我想肯定工程師們介入而且修復了那些被標記和未被標記的根本問題。" 那些條件最終造成了混沌工程實驗，這樣你就可以使用這些行爲再次進行驗證。

在這部分"失敗"的文化中，咱們有好多人已經把系統事故的過後回顧和檢查分享出去，分享給更大的平臺，咱們也從中學習到了不少東西。你能夠去GitHub中搜索，那裏已經有一大堆公開的事故的回顧和討論。你更能夠從中發現有趣的行爲，也許有些正是你想在你的基礎設施中，你的應用程序中，你的服務中實施的，經過這些條件你就能夠造成混沌工程實驗的配置。經過這樣的方式你就能夠思考，"嘿，你們在分享他們關於失敗的想法，讓咱們看看他們其實是否能夠應用在個人場景中"。

On-Call和培訓

下一個實踐，在隨時待命值班（On-call）的培訓中使用混沌工程。好了，你們是否在隨時待命交接班的時候僅僅被丟過來一張紙，"嗨，輪到你了，幹活吧！" 也許還有一本手冊。這就是我實際上經歷的事兒。我入職公司第三週的時候，沒有任何生產環境（的經驗）也沒有任何系統的知識，而後在我值班的第二週凌晨三點咱們的生產環境發生了宕機。閱讀那本手冊真的是太可怕了。我仍是主任值班人，凌晨三點的時候，你能想象到我(至關崩潰)。公司並無可以向上升級彙報的必要文化。

因此我當時嚇壞了，我就想"好了，我知道咱們有這本手冊，咱們有全部的這些儀表板。" 我過去看着他們，而且執行了手冊上描述的必要步驟。可是我十分的懼怕。我當時想的是"噢，也許我明天進了公司發現本身就被開了"。整體的感覺一點也很差。糟糕的是那本手冊好像是180年前的同樣，因此在值班時候有一本陳舊的手冊事情就變得更糟糕了。如今回想起來我更但願我值班時候會有一些關於怎麼在心理上如何處理焦慮的培訓，讓我可以注視着咱們的儀表板的同時更快節奏地輸入命令，可以告訴同事我正在服務器上執行什麼。

因此想象一下，不管是你的輪崗實習生，你將要發佈新功能到生產環境的新入職的工程師，咱們要把他們叫到一塊兒來經過實施混沌工程實驗的方式來進行培訓。這是一個絕好的方式讓你們一塊兒學習過往的失敗經驗或者讓你們思考新的可能發生的失敗場景。

讓咱們歸納一下，失敗是能夠接受的事情。我想讓你們一塊兒體驗失敗並從中一塊兒學習。當咱們理解了人類必然犯錯便會擁抱錯誤，這樣兼容幷包的文化就能創造出一個環境。

Gremlin幾個月前發佈了免費產品。你們能夠訪問Gremlin.com註冊而且體驗混沌工程實驗，只須要五分鐘。咱們有兩個混沌工程實驗能夠實施在你的基礎設施上，關閉系統，關閉容器和佔滿CPU使用率。這是一個很好的可以實際驗證你的K8S環境是否真正可靠的方法，看他是否真實反應容器的空間，或者你的監視和告警正確配置，或者在CPU負載增高時彈性擴容是否能正確工做。

問答環節

觀衆1：大部分運維人員都知道系統哪裏哪些部分是嚴重損壞的，他們也已經給出了不少優先級，好比"這裏須要修復"。那麼你是怎麼從把系統毀壞的更嚴重和治療這個系統中分配和安排時間的呢？你是怎麼可以花時間去毀壞他們，與此同時你還已經知道有些毀壞的地方已經開始被修復了？

Ana：是的，我以爲這個例子更像這樣。"咱們已經足夠混亂了，咱們不想要系統裏面更多的混亂了。咱們爲何還要故意地作這個事情呢？" 因此項目經理是如何理解韌性的重要程度有時候十分關鍵。咱們的作法之一就是實踐遊戲日。咱們有時候會有公司的銷售人員安排三個小時後的時間來一塊兒體驗破壞。這個既能夠在開發環境也能夠在生產環境。可是這個最重要的是始終擁抱失敗去揭露失敗而且討論"這些P0的Jira任務究竟是什麼？"

Gremlin應對這個的作法是這樣的。咱們的工程師值班輪崗時候，並不會負責爲他本週的當前項目值班。你會在另外一個項目的Jira中工做，處理一些值班時候的事件，某些會變成影響韌性的事件，或者某些高優先級真正影響客戶的事件。

因此，咱們是經過試圖把韌性看成產品的一部分來處理這個事情的，咱們也試圖製造這些P0的事件。

觀衆2：咱們有一些共同的歷史，我如今是來自Uber的SRE。個人問題是，混沌工程到底在測試什麼（對象）呢？它是在測試基礎設施？測試服務仍是測試產品？

Ana：正如咱們在Uber作的，咱們有uDestory，它僅在基礎設施層面工做。可是咱們還能夠向上層移動。咱們能夠把它上移到應用程序層面。因此在Gremlin，咱們實際上不須要僅僅在基礎設施層面進行混沌工程。咱們有應用層面的混沌工程，如今咱們有Java的庫能夠寫入你的應用程序自己。它可讓你在程序內封裝和調用來知足你本身的一些目標。這能讓你更加的深思熟慮和計劃你的實驗。

咱們把這個應用叫作ALFI（application level fault injection），即應用層面故障注入，這是咱們來自Netflix的CEO提出的點子。他的想法是這樣的，"我想實施混沌工程實驗，可是我想在我房間中的PS主機上運行"。因此你要如何讓你的混沌工程實驗變得更加具體呢？使用ALFI你就能夠沒必要要具體到EC2主機或者Lambda函數。一樣的用這種方式你能夠僅在你的安卓系統上製造事故而非iOS設備。

觀衆3：謝謝！這真是太有趣了！我好奇的是你是否發覺經過混沌工程擁抱失敗，擁抱學習，擁抱持續學習的態度已經超越了工程自己？

Ana：是的，沒錯！咱們在公司作遊戲日的時候邀請了55人。咱們有從銷售，從市場部門來參與的同事，他們也在學習。在上週在生產環境進行的遊戲日實踐上，咱們有銷售的同事坐在一塊兒觀測儀表板，作筆記。工程師在指導他們如何使用儀表板，如何解讀峯值數據。而他們也沉迷於這個工程的世界之中了。這個在咱們的生活中是徹底可行的，咱們從自個人失敗中學習，不管從事業，到學業，仍是到咱們的內心健康，我是深信不疑的。這在很大程度上告訴人們失敗是能夠的，分享你的失敗，走到一塊兒，從中吸收教訓。

引用連接

[1] A Key to Success: Failure with Chaos Engineering: https://launchdarkly.com/blog...
[2] Ana Medina: https://twitter.com/Ana_M_Medina

來源：DevOpsXP
原文發表於LaunchDarkly博客，A Key to Success: Failure with Chaos Engineering[1]，- Kim Harrison, June 25, 2019
聲明：文章得到做者受權在IDCF社區公衆號（devopshub）轉發。優質內容共享給思否平臺的技術同伴，如原做者有其餘考慮請聯繫小編刪除，致謝。

5月每週四晚8點，【冬哥有話說】質量與測試專場。公衆號留言「質量」可獲取地址

• 0506 朱少民 《如何最大化軟件測試效能》
• 0513 陳琦 《數據驅動測試》
• 0520 陳霽 《沒錯，去QA是提升質量最有效的方法！》
• 0527 施慧斌 《DevOps實踐之持續測試》