混沌大會問答：混沌工程的好處、挑戰和實踐

程式設計師運維技術軟體架構 · 發表 2018-10-15 07:38:00

摘要：本文要點現代體系結構和基礎設施是短暫的、動態的，不可預測的使用者行為與不可預見的事件交織在一起。我們的系統開始不再像可預測的金屬機器那樣工作，而更像具有突發行為的生物機器。災難恢復已經存在多年了，但是它很昂貴、很傳統，而且很脆弱，所以它只會部署在...

本文要點

現代體系結構和基礎設施是短暫的、動態的，不可預測的使用者行為與不可預見的事件交織在一起。我們的系統開始不再像可預測的金屬機器那樣工作，而更像具有突發行為的生物機器。
災難恢復已經存在多年了，但是它很昂貴、很傳統，而且很脆弱，所以它只會部署在必要的地方，而且極少會用得到。混沌工程利用了雲本地體系結構中現有的api和自動化。
IT團隊中的每個人都應該關注於混沌工程，但是關注的領域可能有所不同。例如，在作業系統層(CPU、記憶體)、網路層和應用層都存在混亂。即使是專注於使用者體驗的產品經理也應該將混沌練習作為他們特性展示的一部分，予以規劃和執行。
混沌工程是一種在目標時間框架內引發未知和意外故障的好方法，有助於提高系統的彈性。混沌工程應持續不斷地執行。
對於混沌工程來說，有幾個重要的先決條件。首先，你需要確保有適當的監控。然後，你需要能夠確定五大關鍵服務是什麼。接下來，選擇一個服務，並確定一個你想在其上執行的假設和混沌實驗。

9月28日，InfoQ在美國舊金山舉辦了的ofollow,noindex" target="_blank">混沌大會，為了準備這次會議，InfoQ採訪了多位演講者，並討論了混沌工程的好處、挑戰和實踐。

首屆Chaos Conf將由Gremlin Inc 團隊組織，旨在為專家、實踐者和混沌工程領域的新手提供一個分享經驗和學習新出現的良好實踐的論壇。演講內容包括向非技術涉眾介紹執行混沌實驗的想法、混沌工程的歷史、實現故障注入、故障管理模式、“破壞容器”和使用Kubernetes執行混沌實驗等。

InfoQ最近與諸位Chaos Conf演講者坐談，討論了混沌工程的方方面面，他們是：OUI.Sncf卓越運營總監Kriss Rochefolle 、亞馬遜雲架構副總裁Adrian Cockcroft 、Honeycomb執行長Charity Majors 、Turbine 實驗室執行長和創始人Mark McBride 、沃爾瑪實驗室工程總監Vilas Veeraraghavan 、推特工程經理Ronnie Chen 、彭博社軟體工程師Mikolaj Pawlikowski ，以及Gremlin的混沌皇后Tammy Butow 和Ana Medina 。

InfoQ：歡迎大家的到來，非常感謝你們參加了Chaos Conf會前問答環節。你們可以簡單介紹一下你們自己嗎?

Kriss Rochefolle：你好，我是來自法國南特理工學院的質量和安全工程師(現在叫IMT Atlantique)，我在軟體公司和初創企業中建立軟體質量團隊的經歷積累一定經驗，特別是在多站點環境和離岸環境中受益匪淺。

在領導了第一個法國flash銷售網站的敏捷 & DevOps方法之後，我加入了OUI。sncf集團在兩年前以卓越運營方法和少量的混沌工程繼續DevOps轉型。

Adrian Cockcroft：你好，我是亞馬遜雲架構戰略副總裁，我的部分工作是為亞馬遜運營開源社群團隊。我剩下的工作就是和客戶交流，在會議上發言。

Charity Majors：嘿，我是 honeycomb.io 的聯合創始人兼執行長，那是一家為軟體工程師建立可觀察性的公司。我還曾任職於Parse/Facebook, 是O'Reilly著作《資料庫可靠性工程》的合著者，長期作為運營工程師和體系破壞者。

Mark McBride：大家好，我是Turbine 實驗室的創始人和執行長。我們創造了Houston，它是一個專注於微服務自助服務的服務網路。在Turbine 實驗室之前，我在Nest負責伺服器端工程，更早的時候，我在推特工作。在這兩個地方，我都領導了向微服務的轉型。

Vilas Veeraraghavan：你好，我在沃爾瑪運營雲應用程式測試和部署管道。我們擁有用於混合雲部署和混沌工程的測試、分析、叢集規模估算。

Ronnie Chen：嗨，我現在是Twitter的工程經理。我從科技行業的後端工程師做起，然後進入資料工程領域。然而，對於混沌大會，我主要是以我作為技術潛水員(自給式水下呼吸器和換氣器)的身份發言。

Mikolaj Pawlikowski：我是彭博社的一名軟體工程師，我在那裡的工作主要是圍繞一個執行在Kubernetes之上的微服務平臺。這是一個大型的分散式系統，它把我引向了混沌工程正規化。

Tammy Butow和Ana Medina：我們都實踐了混沌工程。我們正踏在了失敗的邊緣上，並不斷探索如何利用混沌工程使系統更具彈性。我們也花時間幫助更大的社群瞭解更多關於混沌工程的知識。我們曾在Gremlin、Dropbox、Uber、DigitalOcean和澳大利亞國家銀行(National Australia Bank)實踐過CE。這些年來，我們學到了很多東西，能夠回饋社會是一件很棒的事情。

InfoQ：是什麼讓混沌工程如此重要?是什麼原因讓你認為這個話題現在受到了更多的關注?

Rochefolle：對於IT主管來說，服務的可用性與安全性同等重要，我們必須減輕重大事故和停機的影響：

每個歐洲組織每月重大IT事故(CIEs)的平均數量為3起
65%的歐洲組織報告稱，過去的重大IT事故已導致聲譽受損和相關的財務損失

來源

最近一個例子是亞馬遜超級會員日崩潰

Cockcroft：災難恢復已經存在了很多年了，但是它很昂貴，很傳統，而且很脆弱，所以它只部署在必要的地方，而且很少會用到。混沌工程利用了雲原生架構中現有的api和自動化(無論是在使用Kubernetes的前提下，還是在AWS上)，使災難恢復成本低、產品化且足夠健壯，可以持續執行，以證明存在安全邊際量。

Majors：因為現代系統需要它。就在過去幾年裡，基礎設施領域的複雜性激增。現代基礎設施由分佈廣泛的分散式系統組成，再加上容器和排程程式，另外還有虛擬化，它與第三方供應商、SaaS或IaaS的耦合已經極為鬆散，具有區域之間的冗餘和亞秒延遲保證，支援越來越多的語言、環境和編配層，以及“許多”儲存系統。

哦，別忘了微服務！現代的infra是短暫的和動態的，不可預測的使用者行為與不可預見的事件交織在一起，對可靠性和豐富的新特性集的渴望與日俱增。我們的系統開始不像可預測的金屬機器那樣工作，而更像具有突發行為的生物機器。

然而，我們用於與這些系統互動的大多數工具和實踐都是LAMP-stack時代的遺留產物，那時你可以檢視儀表板，瞭解系統的健康程度。你可以預測這些系統將如何失效，並監控這些東西。現在你不能再做這些事情了，這就是為什麼混沌工程開始出現，為什麼可觀察性和其他學科開始出現。

它們基於的是這樣的一個假設：失敗是不可避免的，同時又是不可預知的；理解你的系統並與之互動的最佳方法是接受這種不可能，併為此進行構建。你的目標不是讓每個人都預測未來，建立完美的系統，而是要不斷地管理失敗，迅速地發現並糾正它們，有時還會在某種可控的情況下注入它們，從而加速學習和應對。因此就有了混沌工程學。

世界正從一個已知的未知世界迅速轉變為一個未知的未知世界，從“預測失敗並監控它們”到“儀器和探索”。我們用來處理這些問題的工具和技術是完全不同的。

McBride：在推特和Nest，向微服務的轉變將一條不斷增長的鴻溝帶到了我們的面前，我們當前認為應用程式將如何失敗和應用程式實際上是如何失敗的之間存在著巨大的差異。在所有團隊中，我看到了明顯不同的方法，從建立昂貴的準生產模擬到允許開發人員安全直接地管理生產。工具化和直接與生產互動更加有效。

今天，關鍵的高規模服務都由小團隊管理，這種情況無非過去可比。混沌工程閉合這個迴圈，為他們提供實際資訊，讓之瞭解他們的服務在生產中的實際行為。否則，球隊只是在猜測什麼會被破壞，賭注高到無法猜測。

Veeraraghavan：在雲工程生態系統中，特別是基於微服務的體系結構中，存在一些傳統的devops和/或質量工程無法發現或發現成本極其昂貴的漏洞。混沌工程可以使我們更加簡單地找到這些以前難以發現的問題。隨著私有云部署成為所有公司的標準，這個話題將繼續變得越來越主流。

Chen：普通系統複雜性的增加肯定會引起人們對這場運動的關注，但是以訓練為目的而進行災難演習的做法，在其他行業已經存在多年了。

Pawlikowski：混沌工程幫助填補了其他更傳統的軟體測試方法留下的空白。特別是，它解決了分散式系統中各個元件互動所產生的問題，雖然每個元件都經過了測試，並顯示可正常工作，但整合在一起互動卻未必沒有問題。

我認為Netflix公司出版的《混沌猴》發揮了很大的作用，使混沌工程獲得了更多的關注。其他因素還包括雲、微服務和大型分散式系統的日益普及，在這些系統中，各種子元件出現故障是一種常態。

Butow & Medina：任何公司都不希望自己的系統出現停機或故障。多天停機是不可接受的。隨著分散式系統、雲基礎設施、無伺服器、微服務等的複雜性，作為工程師，我們甚至更難知道穩定狀態是什麼樣子。我們需要為失敗做好準備，而混沌工程可以做到這一點。

InfoQ：每個人都應該關注混沌工程，還是僅僅應該由運維團隊關注?

Rochefolle：擁有最好的客戶體驗是每個人的目標，而不僅僅是運維團隊。

混沌工程實踐是通過在事故發生時限制影響來改善混沌工程的一種方法：

開發團隊在他們的應用程式中使用彈性模式，
運維團隊提供和運營彈性平臺，以及
UX/UI團隊設計客戶體驗以吸收事件的影響。

Cockcroft：可用性是開發人員關心的問題，混沌工程確保開發人員構建有彈性的系統並學習如何使其更強大。混沌工程甚至不需要運維團隊插手都行。

Majors：甚至運維團隊什麼都不是了?在現代組織中，所有的工程團隊都交付軟體，每個人都掌握自己服務的健康狀況。這些專案過去被稱為“開發”和“運維”，但這已逐漸成為一種老古董嘍。

如果你問是否只有基礎設施團隊應該關心混沌，我會反問“只有基礎設施工程師有服務等級協議或者關心質量?”但願不是。每個工程團隊都應該熱心地關心(並負責)他們的服務的健康。混沌工程可以通過加速發現失敗場景並提升解決它們的速度來幫助你。

McBride：每個人都應該關注混沌工程。運維團隊需要成為冠軍，因為成功工作的關鍵是一個能讓團隊安全地執行混沌實驗的平臺。然而，一旦這一切就緒，服務團隊就真正找到了邊緣情況和粗糙邊緣，並且處於修復它們的最佳位置。

Veeraraghavan：每個人都應該關注混沌工程——關注的領域可能不同。例如，在作業系統層(CPU、記憶體)、網路層和應用層都存在混沌。即使是專注於使用者體驗的產品經理也應該計劃並執行混亂練習，作為他們特性展示的一部分。

Chen：每個在複雜系統中進行開發的人都應該認識到系統是如何失效的，並考慮失效模式。

Pawlikowski：好的工具化，可以自動完成任務，並且可以持續報告檢測到的問題，這對實現這一點非常有幫助。

Butow & Medina：我們堅信每個人都應該關注它。混沌工程可以在整個軟體棧中使用，我們認為所有開發人員都應該為自己的程式碼隨時待命，我們認為所有開發人員都應該針對失敗進行構建，並通過混沌工程實驗對其進行測試。混沌工程不僅僅是關於後端或基礎設施，這是所有工程師的事情。

InfoQ：混沌工程和彈性工程有什麼區別?

Rochefolle：彈性工程旨在通過構建具有彈性的應用和平臺來防止事故的影響。然而，我們的系統變得越來越複雜了，很難預測到所有的事情。

混沌工程是一種在目標時間框架內引發未知和意外故障(闇弱點)的好方法，從而幫助提高系統的彈性。通過不斷地執行混沌工程，它也幫助我們有信心恢復能力不會退化。總之，彈性工程是確定性的，而混沌工程是非確定性的。我們兩者都需要，以擁有最好的客戶體驗。

Cockcroft：如果你的團隊是這樣叫它們的，那就沒什麼明顯區別了。塔勒布認為，抗脆弱性與彈性不同，是因為抗脆弱系統在承受壓力時變得更強，而彈性系統具有固定的特性。混沌工程具有更強的抗脆弱性，因為系統需要尋找薄弱環節。

Majors：要是我知道就好了。是黑帽子和白帽子嗎?滲透性測試和…僅僅是破壞性測試?

McBride：他們很相似，因為他們都鼓勵開發人員，接受失敗是不可避免的這一事實。彈性工程只鼓勵團隊為失敗而設計。混沌工程更進一步，要求團隊測試他們的理論，最終產生更強大的系統。

Veeraraghavan：我覺得它們可以互換。然而，我發現彈性工程在高層領導中似乎更能獲得青睞，而混沌工程卻讓他們感到害怕：)

Chen：如果要仲裁這種區別，我或許不是個合適的人選。我的理解是，混沌工程側重於以故障注入為中心的方法，而彈性工程則是構建更多容錯系統的複雜學科。

Pawlikowski：另一方面，混沌工程更多的目的是為了觀察系統作為一個整體是否能夠繼續按照預期工作。這也使開發人員能夠檢測出他們沒有考慮過測試的缺陷。

Butow & Medina：混沌工程是一種實現彈性工程的方法。我們更傾向於關注抗脆弱性系統，這些系統不僅優雅地失敗，而且在你注入混亂和失敗時變得更加強大。一個系統應該不斷改進。

編者按：John Allspaw 在這個領域做了很多有趣的研究和思考。有關更多資訊和其他參考資料，請參閱這個比程式碼更棒的播客。

InfoQ：你能推薦一下你最喜歡的混沌工程領域的工具嗎?

Rochefolle：我們開發了自己的工具，因為我們不在亞馬遜AWS上，而目前大多數工具都是針對這個平臺的。

Cockcroft：我認為Gremlin 很好地引領了這一領域，我加入AWS之前是他們的顧問。chaostoolkit開源專案有很好的文件記錄，是每個人在進一步開發該領域進行協作的好地方。CNCF 混沌工作組也是一個很好的起點。

Majors：這聽起來有點偏私，但卻是大實話，那就是你的可觀察性工具先於honeycomb。如果你沒有能力觀察每一個失敗的請求，並深入分析其原因，然後返回檢視其他影響因素，那麼你就不是在做工程，而只是在猜測。我非常喜歡在生產環境中進行測試，也非常喜歡在受控環境下注入混亂。但是，如果你不能精確地觀察結果，如果你所擁有的只是儀表板和聚合，沒有唯一的請求識別符號，沒有能力通過高基數維度分解，那麼你就不是在做“混沌工程”，你只是在破壞一些東西。可見性是大多數現代化系統中缺失的一環。

McBride：最好的公司在故障和修復之間有一個緊密的反饋環。為了將失敗注入到系統帶有 Envoy （來自CNCF的一個服務網格代理）中，我個人最喜歡將chaos setup和Gremlin結合來用。

就服務是如何執行的，Envoy 提供了一個一貫的主張，Gremlin來搞破壞，特使提供工具來減輕所有型別的失敗。這是一個功能強大得驚人的系統，它不需要在不同的語言或多個服務之間以定製的方式重新實現修復。

Veeraraghavan：我們正在內部編寫許多工具(最終將釋出開源)。有很多工具可以滿足很多彈性需求。但是，大多數工具仍處於發展階段。隨著更多的公司(Netflix除外)開始執行混沌練習，這些工具將會越來越成熟。

Chen：擁有足夠訪問許可權的初級工程師會是個危險源。

Pawlikowski：我推薦的一個很好的資源，是可怕的混沌工程（Awesome Chaos Engineering），它列出了許多相關的資源和工具，沒有特定的順序。我最偏愛的是PowerfulSeal，這是我們公司針對Kubernetes叢集的編寫的一款混沌測試工具，並在公司中進行了廣泛地使用。去年，我們在位於奧斯丁的KubeCon + CloudNativeCon北美2017大會上將其作為開源專案釋出了。

Butow & Medina：空間仍然很小，在未來還會有更多的工具被開發出來，但是在使用Uber自己的混沌猴子工具uDestroy 後，我(Ana)學會了欣賞Gremlin提供的自動化混沌工程軟體。我(Tammy)過去在Dropbox對資料庫基礎設施進行混沌工程實驗時，就已經開發了自己的工具。在看到Gremlin的產品後，我覺得它比我夢想的任何東西都更棒，然後我問我是否可以加入團隊：)現在我在Gremlin工作，我已經在這裡工作了10個月了，我愛它！

InfoQ：如果一個團隊想要開始使用混沌工程，他們應該採取的第一步是什麼?

Rochefolle：通過組織一個遊戲日來準備文化變化

Cockcroft：在部署任何應用程式之前，先在新環境中安裝混沌工具和程序，並在應用程式進入生產環境之前建立一個測試環境來折磨它們。

Majors：確保他們的儀器足夠成熟，這樣他們就可以解釋系統中發生的未知事件。沒有裝備，戰爭還沒開始就輸了。

McBride：第一步就是開始做。最好是在每個人都注意的情況下故意中斷服務，而不是等到凌晨2點只有一個昏昏欲睡的開發人員醒來。混沌工程就是測試你對系統的瞭解。

作為第一步，選擇一些你認為應該有彈性的東西，並以你認為系統會優雅地恢復的方式破壞它。如果成功了，太好了。如果沒有，你已經學到了一些有價值的東西！

Veeraraghavan：坦率地說出你的期望，並意識到這應該是一個科學實驗。僅僅因為名字裡有“混沌”這個詞，並不意味著你放棄了作為工程師的責任。Gremlin有一些很棒的部落格，我們可以參考它們來計劃和執行實驗。

Chen：大多數團隊在開始實際的故障注入之前，應該先檢查他們的執行表和標準恢復程式偏離了實際系統狀態的程度。讓沒有運維背景的人按照你的文件來做，並在你開始將更多的混亂新增到整體之前進行驗證。

Pawlikowski：我會從令人敬畏的混沌工程開始，閱讀混沌工程宣言的原則，然後嘗試使用各種可用的工具來破壞你的系統。破壞你精心設計的系統是很有趣的！

Butow & Medina：我們相信混沌工程有幾個重要的先決條件。首先，你需要確保有適當的監控。然後，你需要能夠確定五大關鍵服務是什麼。接下來，選擇一個服務，並確定要對其執行的混亂實驗。

我們的目標是以一種不會對顧客造成傷害的方式進行實驗。你的系統應該優雅地失敗。我們的目標是使用混沌工程實驗來確認你對於失敗場景的假設。接下來觀察/分析結果，然後增加爆炸半徑。

關於小組成員

Kriss Rochefolle是OUI.Sncf卓越運營總監。為提高系統和團隊的質量和敏捷性提供組織、方法和工具的人，在混沌工程的探索和實驗過程中，充滿激情和快樂！

Adrian Cockcroft 是AWS. Adrian雲架構的副總裁。Adrian曾在Netflix擔任雲架構師，後來又在Battery Ventures擔任技術研究員，在開發雲生態系統方面發揮了關鍵作用。在此之前，他曾在eBay和Sun Microsystems擔任傑出工程師。

Charity Majors是Honeycomb執行長。Charity曾是Facebook、Parse和Linden實驗室的系統工程師和經理，也是《資料庫可靠性工程》的合著者。對於分散式系統，你不必關心繫統的健康狀況，你關心的是事件或部分的健康狀況。

Mark McBride是Turbine 實驗室的創始人兼執行長，Houston的製造者，它是一個現代交通管理平面。在建立Turbine 實驗室之前，他在Nest從事伺服器端工程。在此之前，他在推特工作，致力於將他們的rails程式碼庫遷移到基於jvm的對等端。

Vilas Veeraraghavan是沃爾瑪實驗室主任。Vilas於2017年加入沃爾瑪實驗室(Walmart labs)，帶領團隊負責電子商務和商店的測試和部署。在加入沃爾瑪實驗室之前，他曾長期任職於康卡斯特(Comcast)和Netflix，在這兩家公司擔任自動化、效能和故障測試負責人。他喜歡打破常規，認為混沌工程是測試複雜應用生態系統的新常態。