本文要點
- 軟件應用變得越來越複雜，停機的成本愈加昂貴，消費者對停機的容忍度也越來越低。
- 混沌工程還不是很主流，但本次問答的受訪者大都認爲它已經走出了創新階段，進入了應用曲線的早期使用階段。在組織內部，事件響應和緩解措施變得越來越重要，優先級不斷上升。
- 混沌工程的核心理念已經很完善了，在過去的幾年中社區對它的理解更爲廣泛和深刻。工程師開始理解它是實驗和信息共享的有原則實踐，並不是什麼完全隨機攻擊的神話。
- 軟件工程師一直在生產中做測試（即使他們沒有意識到這一點）。混沌工程可以提供更正式的方法。
- 通過事件響應策略和管理演練遊戲日之類的形式關注人員和流程可以顯著提升價值。與大多數技術變革一樣，新理念普及的最大障礙往往是人們自身。關鍵在於找出實踐的合理性，設定期望並在整個組織中建立信任。
- 太多的人認爲構建和運行系統的目的是不要犯錯誤。當他們意識到出色的系統並不完美，而是有彈性的，那麼組織自然就能開始理解混沌工程及其實踐的優勢。
- 混沌工程的一個好處是你不需要很多工具就能啓動。例如，你可以使用Linux的本地kill命令來停止進程和iptables來造成網絡連接問題。
- 谷歌的團隊會做DiRT（災難和恢復測試），他們走進數據中心對服務谷歌內部系統的機器“造成可怕的後果”，例如拔掉硬件等。組織的規模沒有那麼大的話，也有侵入性較小的開源和商業工具可用。
- 爲了從混沌工程的投資中獲益，組織首先需要建立一種從事件中學習的文化。沒有這種學習過程，投資可能就無法創造價值，並令人感到沮喪。觀察系統並瞭解停機時間的影響也是關鍵所在。
第二屆混沌大會活動於9月25日至26日在舊金山舉行，InfoQ也將報道活動概況。在爲大會做準備時，InfoQ與許多演講者坐下來討論了衆多話題，諸如混沌工程的演變和應用、進行混沌實驗時相關人員和流程的學習重點以及主流應用的最大障礙等。
希望深入學習混沌工程的讀者可以參閱最新版的混沌社區日v4.0的摘要、混沌工程電子雜誌以及有關彈性系統的多份QCon演講的摘要。
InfoQ：非常感謝幾位參加2019混沌論壇的會前問答。請各位簡單介紹一下自己。
Jason Yee：我是Datadog的高級技術傳播者。Datadog是基於SaaS的可觀察性平臺，使開發人員、運營和業務團隊可以更好地瞭解用戶體驗和應用性能。
Caroline Dickey：我是Mailchimp的網站可靠性工程師，這是一個針對小型企業的多合一營銷平臺。我構建工具和配置以支持工程運作，並發展監視和服務級別的目標以改善我們應用程序的健康水平；我領導了Mailchimp的混沌工程計劃。
Joyce Lin：我是Postman的開發者支持——這是一種在開發社區中廣泛應用的API開發平臺。我還與致力於更好的軟件開發實踐的組織合作。
Robert（Bobby）Ross：我叫Robert Ross，但人們喜歡用流行的XKCD漫畫來稱呼我Bobby。我是尖端技術愛好者，所以我喜歡嘗試新事物並願意承受嘗新的代價。我是事件響應工具FireHydrant的CEO。
Kolton Andrus：我是Gremlin的CEO兼聯合創始人。我曾全力在Amazon建立可靠的系統，當時我的團隊負責零售網站的可用性。我建立了他們的第一個“混沌工程”平臺（彼時還沒有這種概念），並幫助其他團隊做了他們的第一個實驗。然後我加入了Netflix，那時他們剛剛開始撰寫有關這個話題的博客。我建立了他們的下一代故障注入測試（FIT），並與所有關鍵的流媒體團隊一起將正常運行時間的可靠水平從三個九提高到了四個九（99.99％）。看到了Amazon和Netflix獲得的價值後，我強烈感受到所有人都需要這種方法，需要強大的工具來支持它——因此我創立了Gremlin。
YuryNiño：我來自哥倫比亞國立大學，目前是Aval Digital Labs的DevOps工程師，我們這家創業企業領導着我國一批銀行的數字化轉型。
我也是混沌工程的擁護者。我喜歡破壞軟件應用、設計彈性策略、在生產中實驗並解決棘手的性能問題。我正在研究軟件系統的安全性與人爲錯誤和缺乏可觀察性之間的關係。目前我正在領導一家創業公司創建哥倫比亞的第一個混沌社區。我們正在構建Gaveta，這是一款用來支持混沌遊戲日執行的應用。
Jose Esquivel：我是Backcountry.com的一名工程經理，在供應鏈管理中負責實現、市場營銷和內容團隊的工作。他們運行着大約65種API，這些API在我們的網絡內與第三方系統及公共API交互。從技術角度來看，我的責任是確保這些API保持穩定並及時添加新功能。
Subbu Allamaraju：我是Expedia Group的VP。我剛加入Expedia時負責了我們的旅行平臺向雲的戰略遷移。這些年我花了大量時間繼續推動這一轉型，更重要的是讓我們爲卓越運營做好了準備。我認爲大家之間有很多東西可以學習交流，因此我在自己的博客上撰文並在許多會議上發表演講。
Dave Rensin：我是谷歌的高級工程總監，目前正在爲我們的CFO從事戰略項目。在谷歌，我負責客戶支持、一部分SRE以及全球網絡容量規劃。
Paul Osman：我負責Under Armour Connected Fitness的現場可靠性工程團隊。我的團隊負責MyFitnessPal、MapMyFitness和Endomondo等產品。加入Under Armour之前，我曾在Pagerduty、SoundCloud、500px和Mozilla工作。我的大部分職業生涯都橫跨運維和軟件開發領域，因此自然而然地走近了SRE工作。這些年來我已經在多家公司實踐過混沌工程。
InfoQ：在過去的一年中混沌工程發生了什麼變化？應用情況如何？混沌工程已成爲主流了嗎？
Yee：我認爲混沌工程本身並沒有什麼變化，理念還是一樣的，但是我們對它的理解更深了。工程師開始明白這是有原則支撐的實驗和信息共享的實踐，並不是完全隨機攻擊的神話。神話的破滅和最佳實踐的出現都推動了混沌工程的應用。它還不是很主流，但我們肯定已經走過了“創新者”階段，進入了應用曲線的“早期使用者”部分。
Dickey：在組織中，事件響應和緩解措施愈加重要，優先級不斷提升。應用程序變得越來越複雜，停機成本愈加高昂，消費者對停機的容忍度也越來越低。令人欣喜的是，過去一兩年來人們對待突發事件的態度已經不再只是分析其成因或推卸責任，而是開始將事件視爲一場完美的風暴。混沌工程是這種行業範式轉變的理想選擇，因爲它讓工程師能夠識別並解決可能導致連鎖故障的問題。
混沌工程在大型科技公司和早期使用者當中已經成爲了主流，而在中小型公司中仍在尋找自己的立足之地。但這種趨勢是不變的，因爲軟件的分工越來越細，人們犯錯的機率也不會減少！我很期待看到幾年後混沌工程的應用和相關實踐會是怎樣的情況——投身於這一行業是很有趣的。
Lin：我相信混沌工程對於大多數團隊來說仍然是一種可能考慮在未來實施的新事物。如果團隊做好了發佈前測試的所有基礎工作，那麼他們就更容易開始混沌實驗。
Ross：混沌工程運動的一大影響在我看來就是遊戲日的流行。它們並不是一個全新的概念，但我注意到已經有越來越多的公司採用它們。人們意識到，既然發佈前測試軟件的舞臺已經搭建好了，爲什麼不一起測試一下事件響應流程呢？大型企業這樣做已經有很多年了，越來越多的小公司也加入了進來。
Andrus：不過幾年前，我還得經常向人解釋爲什麼需要混沌工程。現在大多數認真運營的團隊都理解了它的價值，只需要一些幫助即可入門。擁有兩年經驗的早期使用者現在已經取得了很大的成功，並且正在設法將其擴展到整個組織中。主流羣體仍在與項目和團隊一起展開測試，然後才能更全面地應用混沌工程。
Niño：我認爲混沌工程在很短的時間內就達到了驚人的發展速度。經典文章“混沌工程”的作者在2016年提問，是否有可能構建一套可在組織間重複使用的自動化故障注入工具。僅僅三年後的今天，我們已經擁有20多種工具來實施混沌工程，一些組織正在使用它們來在生產中構建更可靠的系統。
根據Thoughtworks發佈的最新版《技術雷達》，混沌工程已經從一個廣爲人知的理念轉變爲一種公認的主流方法，可用來改善和確保分佈式系統的彈性。
Esquivel：在線業務的負載一直在增長，而對於電子商務來說大部分流量集中在一年中的某幾個星期。這意味着在人流量大的時期，公司的收入直接與系統穩定水平成正比。採用諸如單元測試、集成測試、安全測試、負載測試及最終混沌測試等工具已成爲關鍵任務。混沌工程的使用率一直在上升，我們都知道自己確實需要它。現在我們需要的是花費時間來等待它成熟。
Allamaraju：還沒有。
儘管這個話題已經有約十年的歷史，但業界對混沌工程這種理念的理解仍處於萌芽狀態。
我的理由如下。在這個行業中很少有人將生產環境中運行的軟件視爲隨機和非線性的系統，而且我們每次做出更改時都會在系統中引入許多假設。因此當團隊設計混沌工程時，他們會通過各種混沌工程工具測試操作系統以及網絡和應用級別的故障，但遠不足以瞭解系統的安全性。
即使我們對生產系統所做的大部分工作看起來都是良性的，但這些工作有時仍會將系統推向不安全的區域，阻止我們交付客戶所需和想要的價值。因此在深入研究混沌工程技術之前，從事件中學習和反思是非常重要的。
Rensin：我認爲混沌工程一直都是主流方法，只不過以前我們叫的名字不一樣。如果你的客戶先碰上了混沌，我們稱之爲“客戶支持”。如果你的電信公司（或提供商）先你一步，我們稱之爲“厄運”。我認爲這是去年發生的最大變化。當越來越多的人發現混沌工程的本質時，他們也更深刻地意識到自己的組織已經身處其中（或需要這樣做）了。
Osman：人們的興趣越來越濃，但許多公司仍在努力入門。我覺得這是因爲混沌工程並非靈丹妙藥——混沌工程處於一個能力矩陣中，這個矩陣整體的確可以產生效果，但是如果沒有可觀察性、良好的事件響應流程和無過錯反思等事物的配合，單單是混沌工程自己不太可能帶來什麼驚喜。
基本上來說，如果你們不是學習型組織，那麼開展實驗是沒有意義的，混沌工程技術也會無濟於事。從好的一面來看，越來越多的人意識到現代系統是複雜的，明白故障無法全部預測。僅僅讓質量檢查團隊在過渡環境中測試並不會消滅故障，因此人們對混沌工程的興趣越來越大。我認爲所有這些都可能意味着它現在已經成爲了主流。:)
InfoQ：採用混沌工程實踐的最大障礙是什麼？
Yee：與大多數技術變革一樣，最大的障礙在於人本身。想要獲得領導者的批准來故意破壞你的生產系統是很困難的，尤其是無法準確判斷業務風險和收益的情況下更是如此。想要贏得支持，關鍵在於創建一個可靠的策略來管理混沌測試的破壞半徑、確保發現的薄弱環節得到改善並傳達業務價值等等。
Dickey：文化上的轉變——在堆積的工作計劃中讓工程師優先考慮並重視破壞性測試——這一直是推動Mailchimp採用混沌工程技術的最具挑戰性的部分。策劃遊戲日或實施混沌工程自動化至少需要幾個小時的準備工作，而且如果沒有專門的混沌工程團隊，做計劃和確定場景的耗時可能會影響進度。
因此，重要的是要記住所有工程規範都需要文化上的轉變——無論是引入單元測試、代碼審查還是日常站會或在家工作都是如此。由於Mailchimp的混沌工程計劃很大程度上是由SRE團隊引導的，因此我們不得不依靠技術講座和內部新聞通訊直接與團隊聯繫，並設法讓遊戲日更加有趣（我們建議使用混沌紙杯蛋糕），從而推動整個工程部門的參與度。
Lin：僅僅靠解決一個常見的障礙並不足以證明採用混沌工程實踐的合理性。當組織的其他成員還不瞭解它或不相信其收益時，他們會感到恐懼和困惑。更糟糕的是人們通常會認爲你只是在隨機搞破壞，並沒有合理的假設和前提。
Ross：你需要一位流程推動人。人們總是習慣繼續做自己熟悉的事情。需要有人力挺纔好嘗試混沌工程。我認爲有時“混沌工程”這個詞可能會讓某些人害怕，因此你需要有人真正向團隊成員解釋其價值所在，並讓所有人蔘與其中。入門往往是很難的。
Andrus：我認爲許多人都理解基礎的理念，但是低估了它爲業務提供價值的潛力。他們只把它當作一個任務，而不是用它節省手頭項目的時間——簡化諸如遷移到雲或採用Kubernetes之類新服務的工作。可靠性往往是事後纔想到的，因此我們正在投入大量工作來教育市場並展示投入前期努力會產生的價值。
Niño：我遇到的障礙很多，比如設法理解爲什麼構建彈性系統與軟件、基礎架構、網絡、數據甚至是製作項目列表都有關係。但我認爲最大的挑戰是文化變革。
根據我的經驗，很難讓客戶同意拿他們的系統來做實驗。剛談起混沌工程時客戶很興奮，比如會說：“如果巨頭都在這樣做，我們也應該考慮混沌工程。” 但等他們瞭解了基本概念後就會說：“我們不會在生產中注入失敗”之類的話。
另一方面，我認爲也必須提到這些侷限，告訴大家混沌工程技術本身不會使系統更強大，增強系統是系統設計者的使命。混沌工程使我們瞭解系統如何應對生產中的動盪條件，並建立起對其可靠性水平的信心，但設計策略是我們的責任。技術不是彌補我們弱點的靈丹妙藥。
David Woods在這方面有一個很好的觀點：“擴展系統能力以處理某些額外擾動會以其他方式增加系統對其他類型事件的脆弱程度。這是複雜的自適應系統的基本取捨”。
Esquivel：企業必須精通IT才能克服應用混沌工程的最大障礙——欠缺將穩定性放在首位的文化。高層管理人員必須瞭解技術，並知道對質量的投資可以轉化爲有效的長期解決方案。只交付功能是不夠的，構建功能的同時必須確保解決方案中包含以下非功能要素：通過單元和集成測試保證的可維護性和一致性、通過負載測試保證的性能水平，以及通過注入混沌測試等保證的穩定性。
Allamaraju：在我看來，最大的門檻是理解混沌工程實踐背後的基本原理，同時發展一種安全運行我們系統的文化，並闡明這種實踐相對其他工作的價值所在。如果你無法闡述清楚並創建出假設以證明其可以帶來價值，那麼你就無法通過混沌工程獲得成功。
一旦克服了這些障礙，混沌工程的實際實踐就會自然而然地到位。
Rensin：不要再追求完美。太多的人認爲系統的目的是不要犯錯誤。一旦他們意識到一個好的系統不是完美的，而是有彈性的，那麼混沌工程就自然而然地到來了。
Osman：我認爲信任是最常見的障礙。你必須有一種信任文化，其中團隊相互信任，非技術的利益相關者則相信工程團隊會考慮客戶的最大利益。這種信任非常重要——如果團隊擔心混沌實驗可能發生什麼情況並且進展不順利，他們當然就會猶豫不決。
混沌工程揭示了複雜系統的一項缺陷：我們無法完全控制，也無法預測生產中會發生什麼。不幸的是一些組織不願面對這一現實。這就是爲什麼在介紹混沌工程之前，更重要的是先引入無過錯反思和良好的事件響應機制之類的實踐。這些實踐會影響組織的文化，爲討論混沌工程打下基礎。
InfoQ：混沌工程中人的因素有多重要？你能爲希望提高組織應變能力的領導者提供一些參考意見嗎？
Dickey：混沌工程的推廣既是營銷工作也是技術工作。領導力支持對於混沌工程計劃能否取得長期成功是至關重要的。我推薦出色的混沌工程技術這份全面的資源清單，可以成爲一個很好的起點。
Lin：大多數組織都害怕更快交付軟件背後的風險，並通過越來越多的預發佈測試來減輕這種擔憂。當組織對他們的平均恢復時間心裏有數時，就會願意開展深入的混沌實驗來學習更多內容。
Ross：當你對某些東西進行混沌測試時，你可能會發現一些有嚴重缺陷的代碼/基礎結構設計，然後可能就會想“怎麼會出這種問題？” 請務必記住，會引入問題的是組織而非個人。你可能會發現某些代碼引起某個問題，就算你不說，編寫代碼的人也知道那是自己寫的。有的人可能會很難受，甚至可能因此感到不適。你要讓他感受到支持和鼓勵，因爲我們所有人都會犯錯（實際上如果你編寫的是生產代碼，那麼你已經在犯錯了）。不要到處怪這怪那，你做不到的話就還沒有爲混沌工程做好準備。
Andrus：在我們這個行業中，我最討厭的事情之一是還沒投入資源訓練好團隊就讓他們待命。我們進行消防演習是有原因的：這樣我們就有機會提前練習並建立肌肉記憶，以免出事以後火燒眉毛四處亂竄。同樣，事件管理的一大要素就是團隊之間的協調——通常指的是以前沒有互動的各個團隊。在緊急情況出現之前建立互動空間就能準備得更加充分，取得更好的成績。
Niño：我認爲混沌工程是人們爲自己創造的學科。我們人類、我們的態度以及我們在壓力下所做出的權衡都體現在系統運行和表現的方式中。在混沌工程中，我們設計故障，在生產中進行實驗，分析結果並生成彈性策略。
談到參考資料，我認爲一些出色的人員和組織已經利用混沌工程提升了他們的彈性。Gremlin團隊在這個方面做得很出色；他們的工具和文檔爲那些想要提升彈性的領導者提供了很好的參考。
Esquivel：一旦人們明白自己努力的成果是自己擁有的——這裏我指的是公司所有權——那麼你就很容易獲得支持，人們也很容易參與。在Backcountry，產品VP、工程總監和幾名工程經理都提倡提高彈性。在這種情況下，自上而下的支持是取得進展的關鍵所在。
Allamaraju：人是這門學科的核心。畢竟是人在構建和運行我們的系統。人們可以通過運營指標來聆聽那些系統的反饋。人們可以從事件中學習，以瞭解系統什麼時候可以工作，什麼時候不行。
不幸的是我們仍在通過經驗來學習這些知識，這需要花費很多時間。
Rensin：人是所有系統中最重要的部分。我們爲他人構建和運營這些事物。人也是最大的障礙（或動力源泉）。我認爲建立組織彈性的最好方法是定期“關閉”關鍵人員。比如說“今天，Sally不會回覆任何工作郵件或消息。生活交流沒問題，但工作的事情一概免談。” 我們爲什麼要這樣做？是要找出只有Sally才擁有的部落知識，然後全記下來——或至少傳播開來。這樣隨機測試過足夠多的成員後，突然間你就會擁有一支更具韌性的團隊。
Osman：像我前面提到的那樣，人是非常重要的！工具和流程再怎麼好，沒人信任和使用也毫無意義。談到參考資料，混沌工程已有七年曆史了，但我還是推薦John Allspaw在ACM Queue中發表的文章“生產中的故障注入”。這是對這個概念很好的介紹。他在同年寫的“無過錯反思和公正的文化”博文也很棒。我多次提到良好的事件響應流程的重要性；如果組織沒有自己滿意的流程，我都推薦他們參考PagerDuty的事件響應文檔，寫得很好。要是你不知道該怎麼起步，看這些就行。
InfoQ：能否推薦一些自己喜歡的混沌領域的工具和實踐/遊戲？
Yee：混沌工程有一點好處是你不需要很多額外的工具。比如說你可以使用Linux的原生kill命令來停止進程和iptables來造成網絡連接問題。我們在Datadog使用的一些工具包括可模擬惡劣網絡條件的Comcast，和HTTP負載測試工具Vegeta。
Dickey：Mailchimp已成爲Gremlin的客戶大約一年了，我們很滿意他們的工具所提供的靈活性和功能。我們選擇使用他們的工具而不是構建自己的，因爲我們認爲開發人員可以花更多的時間爲客戶創造出色的產品。我們還有一些獨特的技術限制（我在大會上的演講會提到），這所以很多開源工具都用不了。
SRE團隊每月組織一次遊戲日，其他團隊需要時加大頻率。事件模擬遊戲日（有時稱爲戰爭遊戲或消防演習）已經幫助我們的工程師可以更輕鬆地響應事件了。
Ross：我很喜歡嘗試不用任何工具的混沌工程。基本上來說，遊戲日中有一個工程師團隊負責破壞網站，不告訴另一個團隊他們要做什麼，什麼時候會做（很有意思）。這樣我們就能知道哪裏是領域知識所在地、人們在發生狀況時是否瞭解流程、你是否爲此設置了警報，以及他們是否有合適的調查工具等等。
Andrus：我推薦的一些最佳工具實際是命令行和觀察工具。可以grep/sort/cut/uniq一組日誌來縮小調查範圍。可以用TCPDump或網絡分析工具來真正瞭解幕後情況。瞭解延遲分佈、聚合和百分比以及你要測量的內容都是理解系統行爲的關鍵所在。
還有一個叫做Gremlin的工具。;）我們最近爲剛入門的用戶推出了一個免費版本，你可以用它運行停機和CPU實驗。
Niño：有些行業要部署到雲端還有很多限制，我推薦用Chaos Monkey之類的工具進行Spring Boot。這個工具非常適合用於做一些涉及延遲、受控異常以及在本地架構中終止活動應用之類的實驗。
我還一直在探索ChaoSlingr，一種用於安全混沌工程的新工具。它是爲AWS構建的，你可以用它將故障推送到系統中，同時識別出安全問題並更好地瞭解基礎架構。
Esquivel：我們已經從內置工具轉向了商業軟件，除非你願意花費大量時間和金錢，否則我們建議你還是選擇商業方案。我們選擇的解決大規模穩定問題的武器是Jenkins，它使用Gatling和Gremlin進行負載測試，在預設的衝擊半徑下釋放混沌；我們用它可以很輕鬆地在生產和開發環境中進行混沌實驗。
Allamaraju：我沒有最喜歡的哪種工具或實踐。相反，我將研究系統的架構、我們所做的假設和通過事件觀察到的弱點，然後發展假設以測試故障，並找出哪些工具或實踐可以用來測試假設。
Rensin：在谷歌我們使用DiRT（災難和恢復測試），我們會走進數據中心，對服務谷歌內部系統的機器做一些可怕的事情——例如拔下硬件。有一個小型團隊來計劃和執行這項工作，避免對客戶造成傷害；但大多數情況下我們的工程師會將其視爲真正的中斷。我們通過這種方式發現了很多東西，而DiRT事後反思是谷歌上最好的資料之一。
Osman：實踐而言，我真的很喜歡在事件的事後反思過程中策劃混沌實驗。當你查看事件的前後過程時請注意意外情況——也許數據庫失敗了卻沒人真正知道原因，或者服務A的延遲增加導致了意料之外的錯誤——這些都是混沌實驗很好的對象，幫助團隊在某些壓力下了解有關係統行爲的更多信息。Richard Cook談到了“想象中的系統”與“現實系統”之間的區別，而事後反思是彌補它們一些差異的絕佳機會。這些差異是高價值混沌實驗的理想材料。
InfoQ：能否用兩句話介紹你的混沌大會演講？你的演講爲什麼不容錯過？
Yee：如果彈性是現代應用的必要需求，那麼我們需要改變軟件的構建方式。我將談論彈性驅動的軟件開發，這是在早期開發流程中應用混沌原理以確保應用更具彈性的一種方法。
Dickey：對於許多公司而言，混沌工程意味着測試服務之間的依賴關係或殺死容器實例。我的演講談論了何時不能採用這些方法，以及這種情況下如何實踐混沌工程，比如說你的主要應用是在裸機上運行的單體架構的情況。
Lin：在組織中推行混沌工程是誰的責任？在非常大型且成熟的公司中，可能由SRE或DevOps團隊來處理，但如果你沒有定義清晰的功能怎麼辦？還有誰能開展混沌實驗？我的演講將研究這個主題。
Ross：我們將向你展示如何將先前發生的嚴重事件的影響因素整合到一個混沌實驗中。然後我們從上一個事件的反饋中學習經驗，再來測試事件是否會再次發生。
Andrus：今年這個領域有了很多發展。我們看到面向公衆的停機次數有所增加，但這種趨勢帶來好處之前我們都害怕它產生的負面影響。我的演講將介紹公司如何爲常見的、影響廣泛的停機事件做準備，幫助聽衆瞭解如何建立更可靠的網絡。
Niño：如今有很多關於混沌工程的書籍、工具、卡片和論文。對於剛開始探索該學科的人來說這可能是很大的負擔。我的演講“入門混沌工程的流行菜譜”提供了指導和實驗，幫助混沌工程師新手入門
Esquivel：在進行混沌實驗時我想解決一個常見的問題：混沌工程有沒有很好的路線圖？爲此我想展示八種穩定性模式、討論實現可觀察性的三種方法，並用實時混沌測試來做總結。
Allamaraju：我準備探討如何形成失敗假設。根據我在Expedia Group的經驗，我會分享我們用來驅動安全性的防護體系，以及如何制定基於價值的假設來促進安全性。
Rensin：我認爲我們可以（並且應該）將混沌工程原理應用到團隊開發和培訓中。沒有理由將這些想法侷限在於軟件或硬件上。我想我可以說服聽衆爲什麼它可以讓團隊和公司變得更好。
Osman：Ana Medina和我將討論將混沌工程引入組織的方法。我們將從工作過的公司的實際案例中汲取經驗。我們還將介紹引入這些實踐的多種途徑。如果你在公司中一直很難就這一理念獲得支持，或者你對混沌工程技術感興趣但不知道如何入門，那麼你絕對應該觀看我們的演講。
最後，InfoQ聯繫到了Gremlin的傳播總監Adam LaGreca，瞭解了他對大會目標的看法。他表示，2018年混沌大會主要討論什麼是混沌工程，以及爲什麼團隊應該這樣做。今年的主題是“突破”，演講者主要是這一領域的先驅，他們會分享他們的專業知識和來之不易的經驗。
受訪者介紹
Jason Yee是Datadog的技術佈道者，他致力於利用測試和監視功能來激勵開發人員和操作工程師。他曾是O’Reilly Media的DevOps＆Performance社區經理和MongoDB的軟件工程師。
Caroline Dickey是亞特蘭大Mailchimp的站點可靠性工程師。她負責建立內部工具，與開發團隊合作開發SLI和SLO，並領導混沌工程計劃——包括協調每月的遊戲日。
Joyce Lin是Postman的首席開發倡導者。每月有700萬開發人員和超過300,000家公司使用Postman來訪問1.3億個API。她經常與API優先組織合作，並且在現代軟件實踐方面對該做和不該做的事情有突出的觀點。
Robert Ross（Bobby Tables）是FireHydrant的創始人兼CEO。
Kolton Andrus是Gremlin的CEO兼聯合創始人。此前，他負責解決亞馬遜和Netflix中企業範圍內的事件。
Yury Niño是一名軟件和DevOps工程師，也是一名混沌工程師。Niño喜歡軟件應用、自動化、閱讀、寫作和教學。
Jose Esquivel是Backcountry.com的首席軟件工程師。
Subbu Allamaraju是Expedia Group的副總裁。
Dave Rensin在谷歌的工程領導團隊中工作。他幫助谷歌將資金投入到正確的地理位置、技術和戰略投資中。
Paul Osman是Under Armour的高級工程經理。他是一位經驗豐富的軟件工程領導者，對運營和可靠性工程充滿熱情。
原文鏈接：
Designing Chaos Experiments, Running Game Days, and Building a Learning Organization: Chaos Conf Q&A