點擊上方“朱小廝的博客”，選擇“設(shè)為星標”

后臺回復(fù)”1024“獲取公眾號專屬1024GB資料

歡迎跳轉(zhuǎn)到本文的原文鏈接：https://honeypps.com/chaos/chaos-engineering-8-traps/

本文來自Nora Jones于2019年3月28日在第4屆混沌工程大會上的分享，原文地址參考資料2。

Nora Jones 是《Chaos Enginering》一書的作者之一，曾在Netflix、Jet.com、Slack等公司實施和落地混沌工程，同時她也在Lund University攻讀人因工程及系統(tǒng)安全專業(yè)的碩士學(xué)位，這也恰好給了她關(guān)于混沌工程結(jié)合人因相關(guān)的觀點。

我花了幾天時間去分析和理解這篇文章。原文是一篇ppt的講稿，很多內(nèi)容都是口語化的的表述，我在翻譯的時候盡量將其轉(zhuǎn)換成文章的形式來進行陳述。

混沌工程雖然不是一個太過新鮮的詞匯，但是就目前國內(nèi)而言，熟知的人也并不會太多。對于絕大多數(shù)人而言，有點超前，如果對于混沌工程不太了解，可以先看看我之前寫的這篇《混沌工程初識篇》。

正文

首先我們以一個史上著名混沌實驗做一個開場白——阿波羅1號。

阿波羅1號是美國阿波羅計劃中的第一個載人飛行任務(wù)。當時計劃將阿波羅1號的發(fā)射演習(xí)作為對阿波羅控制及服務(wù)模塊的首次測試，并計劃于1967年2月21日進行載人發(fā)射，而事實上并未成功。真實的情形是：在1967年1月27日發(fā)射演習(xí)測試期間，指揮艙中的一場大火燒死了全部在場的三名機組成員，于此同時，阿波羅1號的控制模塊也被摧毀。3個月之后，阿波羅1號被NASA正式退役。

最終調(diào)查結(jié)果得出：艙內(nèi)起火是由承載航天器動力的線路缺陷以及裝有易燃和腐蝕性冷卻劑的管道缺陷而引起的。起火之后，艙內(nèi)內(nèi)部壓強較大，致使原本為了確保他們在飛行過程中安全的艙門無法打開，最終也就使得艙內(nèi)機組人員并沒有能夠及時撤離。

當時，航天火箭并沒有裝載飛行燃料，參與人員錯誤地認為此項演習(xí)是相對安全的，即錯誤地認為“爆炸半徑”（混沌工程的5項原則之一——最小化爆炸半徑）能夠得到有效地控制。因此，本應(yīng)該具備的標準應(yīng)急準備也沒有實施，諸如消防、救援以及醫(yī)療小組也并沒有到位。

這次事件的結(jié)局是悲慘的，同時也令NASA蒙羞。這無疑是一場失敗的實驗，我們在執(zhí)行此類實驗的時候應(yīng)該保持高度的重視和警惕。這次事件之后，航天器的設(shè)計也被完全改變了。下面所要講述的內(nèi)容中也會多次提及阿波羅這個案例。

我們所從事的軟件行業(yè)一般不會直接影響到人的生命安全，不過我們所服務(wù)的企業(yè)會從事一些商業(yè)活動，以此來獲得盈利，而各式各樣的事故會讓企業(yè)承受不同程度的損失。事實上，這也就是為什么我們要在軟件行業(yè)中踐行混沌工程，并以此來構(gòu)建我們對事故處理能力的信心的原因之一。

陷阱1、通過發(fā)現(xiàn)系統(tǒng)缺陷的數(shù)量來衡量混沌實驗的成功與否

這是衡量混沌工程的ROI（投入產(chǎn)出比）的一個非常普遍的方式，很遺憾，這招用在混沌工程領(lǐng)域上并不怎么奏效。

援引 Dr. Robert L. Wears的一篇文章《The Error of Counting Errors》（鏈接見參考資料1）, 其中就有這么一句話：You don't know much about safety simply by counting erros。在這句話中，我們可以簡單的把“錯誤”這個詞替換成“在混沌工程中發(fā)現(xiàn)的缺陷”，道理是一樣的。僅僅是通過統(tǒng)計我們所負責的工具、產(chǎn)品或者團隊自身中所發(fā)現(xiàn)的缺陷，是無法評判混沌工程是否成功的。

在《The Error of Counting Errors》（鏈接見參考資料1）這篇文章中還有這么一句話：Error counts are measures of ignorance, ranther than risk。直譯為：錯誤數(shù)統(tǒng)計是用來衡量無知的，而不是用來衡量風(fēng)險的。

“哇哦，混沌工程收獲頗豐，僅上個季度我們團隊就發(fā)現(xiàn)了200多個缺陷”。如果你們也正在推行混沌工程，也許你會發(fā)現(xiàn)領(lǐng)導(dǎo)層樂意把“發(fā)現(xiàn)更多的缺陷”作為OKR中的目標之一，我（Nora Jones）以前的團隊就設(shè)定過類似的目標。我還和其它團隊的同事討論過這個目標，也對此有點躊躇，當時我那位同事說了這樣一番話：你們是通過系統(tǒng)缺陷的數(shù)量來做評估的？如果你們在季度快要結(jié)束的時候還沒有找到足夠多的缺陷數(shù)量來完成OKR的話，我想我可以幫助你完成，我知道一個特別拽的Javascript項目。。（本文來自公眾號：朱小廝的博客，ID: hiddenkafka）

統(tǒng)計系統(tǒng)缺陷的數(shù)量并不能真正地評估混沌工程項目的成功與否，反而還可能會引導(dǎo)你太過注重優(yōu)化次優(yōu)路徑而導(dǎo)致錯過混沌工程可以給你帶來的其它正向收益。

上圖所示的是由 Darrell Huff 于1954年寫的一本書，至今仍然很受歡迎。書中闡述了有關(guān)解釋統(tǒng)計數(shù)據(jù)的錯誤，以及這些錯誤如何讓我們產(chǎn)生了偏離實際的錯誤結(jié)論。推薦閱讀。

混沌工程的目標不僅僅是簡單地通過一些工具來發(fā)現(xiàn)系統(tǒng)缺陷，而是通過所找到的系統(tǒng)缺陷來引導(dǎo)我們走上彈性系統(tǒng)之路。

彈性是指系統(tǒng)的調(diào)節(jié)適應(yīng)能力，它可以以此在面對各種變化和干擾時維持自身的關(guān)鍵功能。我這里所說的“系統(tǒng)”并不單指工具、服務(wù)等，還包括人，學(xué)會如何處理遇到的各類問題也是混沌工程的一部分。我們所處事的態(tài)度，以及在面對壓力時的權(quán)衡抉擇都會影響系統(tǒng)的運行行為。

讓我們來架起混沌工程與彈性工程之間的橋梁，更多地討論我們所進行的混沌實驗的成功之處。并且我們也應(yīng)該專注于學(xué)習(xí)那些我們所擅長的東西，而不僅僅是發(fā)現(xiàn)漏洞并指出系統(tǒng)風(fēng)險。理解系統(tǒng)如何正確的運行會有助于我們更深入的找出和理解系統(tǒng)出問題的原因。

陷阱2、沒必要系統(tǒng)相關(guān)的所有人都來參與實驗的籌備和執(zhí)行

讓所有相關(guān)人員都到場，這一點執(zhí)行起來確實比較困難。但是，如果團隊里的所有成員能夠坐在一起，然后一塊探討實驗過程中系統(tǒng)潛在的變化，并且盡可能多表達關(guān)于系統(tǒng)的不同思考和想法，那么將會受益匪淺。

援引阿波羅1號的例子，這個陷阱二就存在了，當時認為沒必要所有部門都參與這個演習(xí)測試，譬如急救和醫(yī)療援助隊。

陷阱4、混沌工程應(yīng)該是強制性的

（譯者注：沒有看錯，這里就是陷阱4）

人為參與不可避免地會遇到種種協(xié)作問題，建立良好的人際關(guān)系也是混沌工程成功的一部分，我們需要去嘗試理解別人在壓力下如何權(quán)衡，以及如何發(fā)展專業(yè)知識和如何提煉專業(yè)知識等。

在混沌實驗執(zhí)行之后，強制要求相關(guān)人員把所找到的系統(tǒng)缺陷全部修復(fù)的行為，通常結(jié)局都不怎么好，反而還會損害與同事之間的關(guān)系。（譯者注：混沌工程的推行者和混沌工程的受眾并不隸屬上下層關(guān)系，且后者更熟悉執(zhí)行混沌實驗系統(tǒng)的細節(jié)，發(fā)現(xiàn)的缺陷對于后者而言也有輕重緩急，應(yīng)該尊重他們的意見和處理方式，而不是通過一種強制性的手段。）當我們像一個運維團隊做事時候很容易陷入這樣的一個陷阱。一味地追求發(fā)現(xiàn)更多的系統(tǒng)缺陷，并將這些缺陷添加到相關(guān)團隊的代辦事項中，且要求他們盡快完成這樣的做法沒什么太大的意義，也不會產(chǎn)生什么幫助。相反，你應(yīng)該提供足夠多的與系統(tǒng)缺陷有關(guān)的上下文信息，以便讓此系統(tǒng)相關(guān)的負責人去更好地理解系統(tǒng)，以此權(quán)衡利弊類抉擇去修復(fù)缺陷或者是忽略它而專注去做對業(yè)務(wù)更有利的事情。

于此同時，這里還有一個延伸的陷阱——應(yīng)當把發(fā)現(xiàn)的系統(tǒng)缺陷都修復(fù)掉，而且最好是自動化修復(fù)的。我們需要明確的是：在使用混沌平臺或者工具時的最佳實踐是把系統(tǒng)缺陷的上下文信息提供給服務(wù)所有者，而不是自動執(zhí)行修復(fù)程序或者消除系統(tǒng)缺陷。

陷阱5、在非生產(chǎn)環(huán)境中執(zhí)行的實驗不是真正的混沌實驗

在生產(chǎn)環(huán)境中執(zhí)行混沌實驗或者自動化執(zhí)行混沌實驗之前，在非生產(chǎn)環(huán)境中執(zhí)行混沌實驗或者練習(xí) GameDay 是非常有價值的、也是完全有必要的。

回想我在Netflix時，我們想要自動化混沌實驗的配置和執(zhí)行。但是，自動化配置混沌實驗是一個很漫長的過程，我們不得不從多個不同的數(shù)據(jù)源收集大量的與服務(wù)配置有關(guān)的數(shù)據(jù)。當我們收集了所有的這些信息并進行了相關(guān)匯總之后，我們將其通過UI（被稱之為 Monocle 的一個系統(tǒng)）的形式進行呈現(xiàn)，這樣相關(guān)服務(wù)的負責人員可以從其中發(fā)現(xiàn)其潛藏的價值。Monocle的創(chuàng)建完全是一個意外，起初我們并沒有想要創(chuàng)建它，我們只是想要實現(xiàn)自動化實驗配置。這也驗證了一個觀點——與實際自動化實驗相比，你可以在自動化實驗過程中獲得更多的價值。

陷阱6、執(zhí)行實驗是混沌工程中最重要的部分

創(chuàng)建和分享經(jīng)驗的過程才是踐行混沌工程的最高收益。一旦我們能夠通過 Monocle 發(fā)現(xiàn)系統(tǒng)缺陷并向服務(wù)的相關(guān)負責人展示時，那么我們從創(chuàng)建實驗中獲得的收益其實就已經(jīng)超過了我們實際執(zhí)行時所能獲得的收益（其中一些我們甚至不需要運行，我們可能已經(jīng)發(fā)現(xiàn)了存在的缺陷）。

實驗執(zhí)行前、實驗執(zhí)行時、實驗執(zhí)行之后所有的這些階段都應(yīng)平等和特定的關(guān)注。

由于篇幅關(guān)系，這里我只詳細介紹一下在實驗執(zhí)行前的準備階段的收益。

這里說一個有關(guān) Consul 的故事。事故能夠給我們提供一個這樣的機會：讓我們可以坐下來一起看看 A (Josie) 和 B (Javi) 在關(guān)于系統(tǒng)怎樣運行的理解上有什么偏差。Josie，作為某個服務(wù)的負責人，覺得 Consul 的可用性可以達到100%， 即使出現(xiàn)問題，Consul 團隊也會解決。同時，Javi 作為Consul 的架構(gòu)師，認為用戶不會做出這種可用性100%的假設(shè)。顯然 Josie 和 Javi 從未明確對齊過關(guān)于 Consul 的各自預(yù)期，因為他們都假設(shè)對方應(yīng)該知道這些認知。

Javi 擁有長期一線運維的經(jīng)驗，他覺得不會有用戶會認為一個服務(wù)可以提供 100% 的可用性，而且在用 Consul 的時候也肯定會配置相關(guān)的重試策略。因此，他也從未把這一點寫入文檔里，也沒有提示給用戶有關(guān)假定可用性為100%的任何風(fēng)險。Josie 非常喜歡 Consul，因為使用Consul可以方便快捷地存儲和變更鍵值對，省時又省力，并且他也確實在很多地方都用上了 Consul。正常情況下，事情也確實如 Josie 所預(yù)期的那樣，直到有一次發(fā)生了大規(guī)模停機。。。對于這次事故，顯然有部分原因是因為各自預(yù)期的不匹配，且也缺乏交流相關(guān)內(nèi)容的機會。不過話又說回來，除非真的遇到一次事故，否則類似的交流不會發(fā)生，因為大家不會因為一件彼此認為認知一致的事情而作任何交流。

這就是為什么要引入混沌工程原因。混沌工程就提供了一個機會——可以讓我們?nèi)ヌ剿飨到y(tǒng)的缺陷，更重要的是，可以讓我們一起交流各自關(guān)于系統(tǒng)運作的思考和認知。

混沌實驗的設(shè)計者/組織者（理想情況下）應(yīng)該是來自團隊外部的人，他們需要引導(dǎo)并理解團隊成員對于系統(tǒng)的可能的偏見。他們的任務(wù)是主持和引導(dǎo)團隊內(nèi)部人員進行對話、提問以及表達各自的觀點，以期最終能夠總結(jié)歸納出關(guān)于系統(tǒng)的假定。他們通過所尋求的團隊中各個成員的反饋來構(gòu)建后續(xù)的實驗。（本文來自公眾號：朱小廝的博客，ID: hiddenkafka）

盡管這個過程很費時間，但是非常重要（至少在混沌實驗設(shè)計階段）。團隊中的各個成員需要發(fā)表各自對于系統(tǒng)的不同觀點認知，最終能夠整和出系統(tǒng)的一個假定。通常而言，這個假定不應(yīng)該來自于實驗的設(shè)計者/組織者。實驗的設(shè)計者/組織者把大家聚到一起（30 - 60分鐘），讓每個成員有機會表達自己對系統(tǒng)的理解、當遇到某些故障時系統(tǒng)會發(fā)生什么。當來自不同團隊的各自成員在一個屋子里一起參與實驗的設(shè)計、一起討論關(guān)于系統(tǒng)的期望時，你將會受益良多。提取你在這個階段所獲得的有效信息和接下來的實驗執(zhí)行同等重要。

搞清楚具體要做什么樣的實驗也是混沌工程的價值之一。

設(shè)計混沌實驗的目標是讓團隊成員練習(xí)如何在問題的引導(dǎo)下討論關(guān)于系統(tǒng)的不同認知，第二個目標是如何以結(jié)構(gòu)化的方式設(shè)定實驗策略。

陷阱7、晚點再擔心（安全），最重要的是制造混沌

在阿波羅1號事故中，艙門原本是為了保證在飛行過程中宇航員的人身安全，但卻由于內(nèi)部壓力無法打開而釀成慘劇。具有諷刺意味的是，原本旨在確保您安全的某些事情最終會導(dǎo)致災(zāi)難性的事故。Dr. Richard Cook 將這種類型的統(tǒng)稱為“脆弱的防御措施（vulnerable defenses）”。

我們需要了解已采取的防御措施并測試其缺陷。通常，防御措施的缺陷很難被發(fā)現(xiàn)，而混動工程可以幫助你來揭示它。

制造混沌很容易，但是想要確保安全卻很難。我們經(jīng)常會犯錯，總是在事情失敗之后再想怎么去修復(fù)。陷阱7是一個很平常的陷阱，當我們還沉浸在成功制造混沌的喜悅中時，卻不知可能已經(jīng)身臨險鏡。

陷阱8、你可以在不了解系統(tǒng)的情況下進行混沌實驗

在執(zhí)行混沌實驗之前，如果你不了解系統(tǒng)的相關(guān)信息如：軌跡、事件模型等，那么結(jié)局將會很慘。

陷阱3、踐行混沌工程可以遵循特定的公式

為什么“陷阱3”會放在最后，這也是為了強調(diào)一下在踐行混沌工程時并沒有特定的萬能公式可以遵循。在實施 Game Day 或者混沌實驗時也沒有特定的模板可用。

希望閱讀此文的你可以跳出萬能的公式，多從全局的角度去思考，多想想如何觸達目標，而不是需要特定的“處方”。

總結(jié)

我們從混沌工程中學(xué)到的越多，我們對它的討論也就越多，我們也就能越了解它。如果我們能夠意識到這8個缺陷，那么我們可以更好地避開去更好的實踐混沌工程。

?

歡迎跳轉(zhuǎn)到本文的原文鏈接：https://honeypps.com/chaos/chaos-engineering-8-traps/

想知道更多？掃描下面的二維碼關(guān)注我

【混沌工程系列文章】

• 科普 | 明星公司之Netflix

• 看我如何作死 | 將CPU、IO打爆

• 看我如何作死 | 網(wǎng)絡(luò)延遲、網(wǎng)絡(luò)丟包、網(wǎng)絡(luò)中斷一個都沒落下過

• 混沌系列 | 其實制造“假死”很容易

• 干貨 | 這次我們看看阿里的人是如何蹂躪CPU的

• 阿里巴巴混沌測試工具ChaosBlade兩萬字解讀

• 混沌工程初識篇

朕已閱?

總結(jié)

以上是生活随笔為你收集整理的混沌工程的陷阱的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。