開發

混沌工程的陷阱

廣告
廣告

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

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

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

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

正文

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

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

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

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

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

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

陷阱1、通過發現系統缺陷的數量來衡量混沌實驗的成功與否

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

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

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

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

統計系統缺陷的數量并不能真正地評估混沌工程項目的成功與否,反而還可能會引導你太過注重優化次優路徑而導致錯過混沌工程可以給你帶來的其它正向收益。

上圖所示的是由 Darrell Huff 于1954年寫的一本書,至今仍然很受歡迎。書中闡述了有關解釋統計數據的錯誤,以及這些錯誤如何讓我們產生了偏離實際的錯誤結論。推薦閱讀。

混沌工程的目標不僅僅是簡單地通過一些工具來發現系統缺陷,而是通過所找到的系統缺陷來引導我們走上彈性系統之路。

彈性是指系統的調節適應能力,它可以以此在面對各種變化和干擾時維持自身的關鍵功能。我這里所說的“系統”并不單指工具、服務等,還包括人,學會如何處理遇到的各類問題也是混沌工程的一部分。我們所處事的態度,以及在面對壓力時的權衡抉擇都會影響系統的運行行為。

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

陷阱2、沒必要系統相關的所有人都來參與實驗的籌備和執行

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

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

陷阱4、混沌工程應該是強制性的

(譯者注:沒有看錯,這里就是陷阱4)

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

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

于此同時,這里還有一個延伸的陷阱——應當把發現的系統缺陷都修復掉,而且最好是自動化修復的。我們需要明確的是:在使用混沌平臺或者工具時的最佳實踐是把系統缺陷的上下文信息提供給服務所有者,而不是自動執行修復程序或者消除系統缺陷。

陷阱5、在非生產環境中執行的實驗不是真正的混沌實驗

在生產環境中執行混沌實驗或者自動化執行混沌實驗之前,在非生產環境中執行混沌實驗或者練習 GameDay 是非常有價值的、也是完全有必要的。

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

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

創建和分享經驗的過程才是踐行混沌工程的最高收益。一旦我們能夠通過 Monocle 發現系統缺陷并向服務的相關負責人展示時,那么我們從創建實驗中獲得的收益其實就已經超過了我們實際執行時所能獲得的收益(其中一些我們甚至不需要運行,我們可能已經發現了存在的缺陷)。

實驗執行前、實驗執行時、實驗執行之后所有的這些階段都應平等和特定的關注。

由于篇幅關系,這里我只詳細介紹一下在實驗執行前的準備階段的收益。

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

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

這就是為什么要引入混沌工程原因。混沌工程就提供了一個機會——可以讓我們去探索系統的缺陷,更重要的是,可以讓我們一起交流各自關于系統運作的思考和認知。

混沌實驗的設計者/組織者(理想情況下)應該是來自團隊外部的人,他們需要引導并理解團隊成員對于系統的可能的偏見。他們的任務是主持和引導團隊內部人員進行對話、提問以及表達各自的觀點,以期最終能夠總結歸納出關于系統的假定。他們通過所尋求的團隊中各個成員的反饋來構建后續的實驗。(本文來自公眾號:朱小廝的博客,ID: hiddenkafka)

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

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

設計混沌實驗的目標是讓團隊成員練習如何在問題的引導下討論關于系統的不同認知,第二個目標是如何以結構化的方式設定實驗策略。

陷阱7、晚點再擔心(安全),最重要的是制造混沌

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

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

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

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

在執行混沌實驗之前,如果你不了解系統的相關信息如:軌跡、事件模型等,那么結局將會很慘。

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

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

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

總結

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

我還沒有學會寫個人說明!

愛奇藝大數據實時分析平臺的建設與實踐

上一篇

上周艱難公司一覽:訴訟、勒索病毒、裁員

下一篇

你也可能喜歡

混沌工程的陷阱

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
重庆快乐10分苹果版本 保险行业很赚钱 赚钱的方法论 钻石奇迹赚钱 外地人靠养蟋蟀赚钱盖新房 内蒙古麻将老友 快乐十分 梦幻西游什么玩法最赚钱 网络点赞赚钱龙 上海天天彩 地下城勇士官网下载 卖装修工具赚钱吗 足球比分雪缘园 新浪爱彩苹果 捞金商务赚钱 体球比分网即时比分 湖北快3