本文翻譯自Netflix工程師合著的 Chaos Engineering一書。這本書介紹了混沌工程的主要概念，以及如何在組織中實踐這些概念和經驗。也許我們開發的相關工具只適用於Netflix自身的業務和系統環境，但我們相信工具背後的原則可以更廣泛地應用於其他領域。
InfoQ 將就這一專題持續出稿，感興趣的同學可以持續關注。
譯者序
近年來，隨着服務化、微服務和持續集成的逐漸普及，從開發到線上的便捷性大幅提高。我們在使用這些便利性所帶來的好處的同時，對其負面性的問題也要有所認知。尤其是在一個複雜的分佈式服務體系中，故障發生的隨機性和不可預測性都大大增加了。快速迭代的門檻越來越低，但是對複雜系統穩定性的考驗卻在成倍增長。在這條路上，各家都有自己的經驗實踐。
Chaos Engineering混沌工程從出現到標準化成爲一門學科，是伴隨着Netflix過去三年多時間裏同穩定性持續戰鬥的歷程一起成長起來的，這是每一次故障帶來的深度思考，抽象而成的理論和實踐的結合。混沌工程是一門相對高級的系統穩定性治理方法論，它提倡採用探索式的研究實驗，發現生產環境中的各種風險。爲什麼說相對高級，因爲成功實施混沌工程，要求對現有系統的彈性有一定信心。
前言
混沌工程是一門新興的技術學科，他的初衷是通過實驗性的方法，讓人們建立對於複雜分佈式系統在生產中抵禦突發事件能力的信心。
——混沌工程原則
只要你有過在生產環境中實際運行過分佈式系統的經歷，你就應該清楚，各種不可預期的突發事件一定會發生。分佈式系統天生包含大量的交互、依賴點，可以出錯的地方數不勝數。硬盤故障、網絡不通、流量激增壓垮某些組件，我們可以一直列舉下去。這都是每天要面臨的常事兒，處理不好就會導致業務停滯，性能低下，或者是其他各種無法預期的異常行爲。
在複雜的分佈式系統中，人力並不能夠阻止這些故障的發生，我們應該致力於在這些異常行爲被觸發之前，儘可能多地識別出會導致這些異常的，在系統中脆弱的，易出故障的環節。當我們識別出這些風險，我們就可以有針對性地進行加固，防範，從而避免故障發生時所帶來的嚴重後果。我們能夠在不斷打造更具彈性（彈性：系統應對故障、從故障中恢復的能力）系統的同時，樹立運行高可用分佈式系統的信心。
混沌工程正是這樣一套通過在系統基礎設施上進行實驗，主動找出系統中的脆弱環節的方法學。這種通過實證的驗證方法顯然可以爲我們打造更具彈性的系統，同時讓我們更透徹的掌握系統運行時的各種行爲規律。
實踐混沌工程可以簡單如在STG環境的某個實例上運行 kill -9來模擬一個服務節點的突然宕機，也可以複雜到在線上挑選一小部分（但足夠代表性）的流量，按一定規則或頻率自動運行一系列實驗。
混沌工程在Netflix的發展歷程
2008年Netflix開始從數據中心遷移到雲上，之後就開始嘗試在生產環境開展一些系統彈性的測試。過了一段時間這個實踐過程才被稱之爲混沌工程。最早被大家熟知的是“混亂猴子”（Chaos Monkey），以其在生產環境中隨機關閉服務節點而“惡名遠揚”。進化成爲“混亂金剛”（Chaos Kong）之後，這些之前獲得的小收益被無限擴大。規模的擴大得益於一個叫做“故障注入測試”（Fault Injection Test，FIT）的工具。我們隨後確立了混沌工程的若干原則，用以將這個實踐規範的學科化 ，同時我們推出了混沌工程自動化平臺，能夠在微服務體系架構上，24*7不間斷地自動運行混沌工程實驗。
在開發這些工具和實踐的過程中，我們逐漸意識到，混沌工程並非是簡單的製造服務中斷等故障。當然，嘗試破壞系統和服務很簡單，但並不是全都可以有建設性、高效地發現問題。混沌工程的意義在於，能讓複雜系統中根深蒂固的混亂和不穩定性浮出表面，讓我們可以更全面地理解這些系統性固有現象，從而在分佈式系統中實現更好的工程設計，不斷提高系統彈性。
1. 爲什麼需要混沌工程
混沌工程是一種通過實證探究的方式來理解系統行爲的方法。就像科學家通過實驗來研究物理和社會現象一樣，混沌工程通過實驗來了解特定的系統。
實踐混沌工程是如何提高系統彈性的呢？它通過設計和執行一系列實驗，幫助我們發現系統中潛在的、可以導致災難的、或讓用戶受損的脆弱環節，推動我們主動解決這些環節。相比現在各大公司主流的被動式故障響應流程，混沌工程向前邁進了一大步。
1.1 混沌工程和測試的區別
混沌工程，故障注入FIT和故障測試在側重點和工具集上有一些重疊。舉個例子，在Netflix的很多混沌工程實驗研究的對象都是基於故障注入來引入的。混沌工程和這些其他測試方法的主要區別在於，混沌工程是發現新信息的實踐過程，而故障注入則是對一個特定的條件、變量的驗證方法。
例如當你希望探究複雜系統如何應對異常時，對系統中的服務注入通信故障，如超時，錯誤等，這是一個故障注入的典型場景。但有時我們希望探究更多其他的非故障類的場景，如流量激增、資源競爭條件、拜占庭故障（例如性能差或有異常的節點發出有錯誤的響應、異常的行爲、對調用者隨機性的返回不同的響應，等等）、非計劃中的或非正常組合的消息處理，等等。因爲如果一個面向公衆用戶的網站突然收到激增的流量，從而產生更多的收入，我們很難稱之爲故障，但我們仍然需要探究清楚系統在這種情況下會如何變現。和故障注入類似，故障測試方法通過對預先設想到的可以破壞系統的點進行測試，但是並沒能去探究上述這類更廣闊領域裏的、不可預知的、但很可能發生的事情。
我們可以描述一下測試和實驗最重要的區別。在測試中，我們要進行斷言：即給定一個特定的條件，系統會輸出一個特定的結果。測試一般來說只會產生二元的結果，驗證一個結果是真還是假，從而判定測試是否通過。嚴格意義上來說，這個實踐過程並不能讓我們發掘出系統未知的或尚不明確的認知，它僅僅是對我們已知的系統屬性可能的取值進行測驗。而實驗可以產生新的認知，而且通常還能開闢出一個更廣袤的對複雜系統的認知空間。這整本書我們都是在探討這個主題——混沌工程是一種幫助我們獲得更多的關於系統的新認知的實驗方法。它和已有的功能測試、集成測試等以測試已知屬性的方法有本質上的區別。
一些混沌工程實驗的輸入樣例：
- 模擬整個雲服務區域或整個數據中心故障；
- 跨多實例刪除部分Kafka topic來重現生產環境中發生過的問題；
- 挑選一個時間段，和針對一部分流量，對其涉及的服務間調用注入一些特定的延時；
- 方法級別的混亂（運行時注入）：讓方法隨機拋出各種異常；
- 在代碼中插入一些指令可以允許在這些指令之前運行故障注入；
- 強制系統節點間的時間不同步；
- 在驅動程序中執行模擬I/O錯誤的程序；
- 讓某個Elasticsearch集羣CPU超負荷。
混沌工程實驗的可能性是無限的，根據不同的分佈式系統架構和不同的核心業務價值，實驗可以千變萬化。
1.2 混沌工程絕不僅是Netflix的專屬
我們在和其他公司或組織的專業人士討論混沌工程時，經常收到的一個反饋是，“哇哦，聽起來非常有意思，但是我們的系統功能和業務與Netflix完全不同，所以這東西應該不適合我們。”
雖然我們提供的案例都來自於Netflix的經驗，但是書中所描述的基本原則並不針對任何特定的組織，所介紹的設計實驗的指導也沒有基於任何特定的架構或者工具集。後面，我們會討論混沌工程成熟度模型，希望評估一下自身爲什麼，在什麼時間點，以什麼方式進行混沌工程實踐的讀者可以採用。
像最近的一次混沌工程社區日（一個來自不同組織的混沌工程實踐者的聚會），參會者來自Google，Amazon，Microsoft，Dropbox，Yahoo!，Uber，cars.com，Gremlin Inc.，加州大學聖克魯茲分校，SendGrid，北卡羅萊納州立大學，Sendence，Visa，New Relic，Jet.com，Pivotal，ScyllaDb，GitHub，DevJam，HERE，Cake Solutions，Sandia National Labs，Cognitect，Thoughtworks，and O’Reilly出版社。在本書裏，你會看到來自各行各業（金融，電商，航空航天，等等）的關於混沌工程實踐的案例和工具。
混沌工程也同樣適用於傳統行業，如大型金融機構，製造業和醫療機構。交易依賴複雜系統嗎？有大型銀行正在使用混沌工程來驗證交易系統是否有足夠的冗餘。是否有人命懸一線？在美國，混沌工程在許多方面被當做模型應用在了臨牀試驗系統中，從而形成了美國醫療驗證的黃金標準。橫跨金融、醫療、保險、火箭製造、農業機械、工具製造、再到數字巨頭和創業公司，混沌工程正在成爲複雜系統改進學科的立足點。
飛機啓動失敗？
在伊利諾伊大學的香檳分校，Naira Hovakimyan和她的研究團隊把混沌工程用在了噴氣式戰鬥機上。團隊由兩名B-52飛行員、一名F-16飛行員、兩名飛行測試工程師和兩名安全飛行員組成。在試飛過程中，飛機被注入了幾種不同的故障配置。這些配置甚至包括飛機重心突然變化和空氣動力學參數變化！這給團隊能否在故障發生時重新構建機體爬升動力學參數，以及應對其他會導致故障的配置都帶來了極大的挑戰。在制定並親身實踐了一系列故障情景之後，團隊最終能夠自信地認定該系統對於低空飛行是安全的。
1.3 混沌工程的前提條件
在判斷你的組織是否已經準備好實施混沌工程之前，需要回答這樣一個問題：你的系統是否已經具備一些彈性來應對真實環境中的一些異常事件，像某個服務異常、或網絡閃斷、或瞬間延遲提高這樣的事件。
如果你的答案是明確的“No”，那麼在實施本書中討論的各項原則之前，你需要先做一些準備工作。混沌工程非常適合於揭示生產系統中未知的脆弱環節，但如果你很確定混沌工程實驗會導致系統出現嚴重的故障，那運行這樣的實驗是沒有任何意義的。你需要先解決這個問題，然後再回到混沌工程，然後你不僅能繼續發現更多不知道的脆弱點，還能提高對系統真實彈性水平的信心。
混沌工程的另一個前提條件是監控系統，你需要用它來判斷系統當前的各項狀態。如果沒有對系統行爲的可見能力，就無法從實驗中得出有效的結論。由於每個系統都是獨一無二的，對於如何針對混沌工程揭示出的脆弱環節進行根本原因分析，我們留給讀者作爲練習。
混亂猴子（Chaos Monkey）
2010年底，Netflix向全世界推出了“混亂猴子”。這家流媒體服務提供商在之前的幾年開始遷移到雲上。之前的數據中心垂直擴展給Netflix帶來過很多單點故障，其中一些故障甚至大規模中斷了當時的DVD業務。雲服務不光帶來了水平擴展的機會，同時可以把重度的基礎設施運維工作轉移到可靠的第三方。
數據中心本就會時不時的發生一些小故障，然而到了雲服務的水平擴展架構中，提供同一個服務的節點數大幅增加，發生這類故障的機率也大幅增加。數以千計的服務節點裏，時不時就會有節點出現異常或者掉線。所以需要有一種全新的方法，既可以保留水平擴展帶來的好處，同時又有足夠的彈性來隨時應對節點故障。
在Netflix，並沒有制度要求工程師一定要按照某種規定來構建任何東西。相反，高效的領導者在工程師之間建立強有力的一致規約或原則，然後讓工程師在自己的領域裏找到解決問題的最好辦法。在節點隨時會發生故障的案例裏，我們要建立的強力規約和原則就是，開發的服務要具備在單一節點突然掉線的情況下還能持續提供端到端服務的能力。
混亂猴子在業務正常進行的時間段內，僞隨機地關閉生產環境中正在運行中的節點，而且關閉的頻率比正常節點故障頻率還要高很多。通過高頻率的觸發這些不常見的且具備災難性的事件，我們給了工程師強大的動力在開發他們的服務時必須考慮到如何輕鬆應對這類事件。工程師必須儘可能提早並快速地處理這類故障。再加上自動化、冗餘、回滾策略，以及其他彈性設計的最佳實踐，工程師很快就可以讓自己的服務在這些故障發生時也能保持正常運行。
經過幾年的發展，混亂猴子逐漸變得更強大，現在它可以指定終止一組節點，並且通過與Spinnaker（持續發佈平臺）集成進行自動的線上實驗。但從根本上它還是提供2010年以來一樣的功能。
混亂猴子最大的成就在於讓我們的工程師之間形成了構建具備足夠彈性服務的規約和原則。現在它已經是Netflix工程師文化中不可或缺的一部分了。在過去五年左右的時間裏，僅有一次節點掉線影響了我們的服務。當時正巧混亂猴子終止了一個由於部署失誤而沒有冗餘的服務節點，因而造成了問題。幸運的是，這個故障發生在白天工作時間，這個故障的服務剛剛部署不久，對用戶的影響也非常小。可想而知，如果這個服務一直在線上運行了幾個月，混亂猴子在某個週末的晚上終止了它的節點，且負責該服務的工程師沒有在on-call的情況下，將造成多大的災難。
混亂猴子的美妙之處就在於此，它能儘可能地將服務節點失效的痛苦提到最前，同時讓所有工程師在構建具有足夠彈性應對失敗的系統上，達成一致的目標。
2. 管理複雜性
複雜性對工程師來說既是挑戰也是機遇。你需要一支技術純熟，同時有足夠應變能力的團隊，來成功管理和運行一套包含許多組件和交互的分佈式系統。在這樣的複雜系統中充滿了創新和優化的機會。
軟件工程師通常會對這三個方面進行優化：性能、可用性、容錯能力。
性能
在這裏特指對延遲或資源成本的最小化。
可用性
系統正常響應和避免停機的能力。
容錯能力
系統從非正常狀態中恢復的能力。
通常一個有經驗的團隊會同時針對這三個方面進行優化。
在Netflix，工程師們還會考慮第四個方面：
新功能開發的速度
指工程師可以把新功能，創新功能提供給用戶的速度。
Netflix在軟件工程中的決策過程中，非常鼓勵端到端的功能開發速度，而不僅僅是快速部署本地功能。在以上四者中找到平衡的過程，可以爲架構選型的決策提供必要的信息。
在充分考慮了這些方面之後，Netflix選擇採用微服務架構。但我們要記住康威定律：
任何組織在設計一套系統（廣義概念）時，所交付的設計方案在結構上都與該組織的通信結構保持一致。
Melvin Conway, 1967
在微服務架構中，各團隊彼此獨立開發和運營自己的服務。每個團隊可以自行決定何時將代碼送入生產環境。這個架構策略以溝通協調爲代價來提高新功能開發速度，通常工程組織被劃分爲許多個這樣的小型團隊。我們希望這些小團隊的特點是鬆散耦合（即沒有太多的組織架構限制，而是強調小團隊之間的協作）和高度協調（即每個人都能看到更全面更大的全景，從而明確他們的工作是如何有助於和其他團隊一起實現更大的目標）。小團隊之間的有效溝通是成功實施微服務架構的關鍵。混沌工程適時的提供了系統彈性的驗證能力，來支持快速功能開發，實驗，以及團隊對系統的信心。
2.1 理解複雜系統
想象一個向消費者提供產品信息的分佈式系統。如下圖，這個服務由7個微服務組成，從A到G。A服務存儲了用戶的個人信息。B服務存儲用戶的登錄賬戶信息，如用戶上一次登錄的時間和訪問了什麼信息。C服務是關於產品信息的。D服務作爲API網關處理所有來自外部的接口訪問。
來看一個請求的例子，用戶通過手機App訪問了一些信息：
- 請求首先進入D服務，即API服務；
- D服務本身並沒有所有需要的信息，所以它進一步請求C服務和F服務以獲取必要的數據；
- C服務和F服務也同時都需要更多的信息來滿足請求，於是C服務請求A服務，F服務請求了B服務和G服務；
- A服務也需要訪問B服務，B服務需要訪問E服務，同時G服務也需要訪問E服務；
- 對D服務的一個請求，擴散到了整個微服務架構裏。而且當所有依賴的服務沒有返回或者超時之前，API不會向手機App返回響應。
這樣的請求模式非常常見，而且在有一定規模的系統中這類交互的數量要大得多。相比緊密耦合的單體應用來說，有趣的是傳統架構師的角色被顯著削弱了。傳統架構師的角色更多是負責理解系統中各個組成部分是如何組成整個系統的，以及他們之間是如何有效交互的，然而在一個大型分佈式系統中人類難以勝任這個角色。太多的組件，頻繁的改動和革新，無數非計劃中的組件交互，人類是不可能把這些內容全都放在腦中。微服務架構給我們帶來了開發速度和靈活性的提升，代價卻是犧牲了我們的掌控性和可理解性。這個缺失恰好爲混沌工程創造了機會。
其實在任何一個複雜系統中都是這樣，即使是一個單塊系統，在它變得越來越大，依賴越來越多的時候，也不會有一個架構師可以理解添加一個新的功能對整個系統意味着什麼。也許有個非常有趣的例外就是有一類系統的設計原則裏本來就不會考慮可理解性，例如深度學習，神經網絡，遺傳進化算法和其他機器智能算法。如果人類揭開這些算法的蓋子來看看他們的內部構造時，一系列的權重和非無效解產生的浮點數對個人理解來說就太困難了。只有系統整體發出的響應才能被人類所理解。整個系統應該具有意義，而系統的任何子部分都不需要有意義。
在一個請求/響應的過程中，意大利麪條式的調用圖代表了典型的，需要混沌工程關注的系統固有混亂。傳統測試，如單元測試，功能測試，集成測試，在這裏是不夠的。傳統測試只能告訴我們正在測試的系統中的某個屬性的斷言是真還是假。但現在我們需要更進一步發現會影響系統行爲的更多未知屬性。也許一個基於真實事件的例子有助於說明這個不足。
2.2 系統複雜性示例
E服務包含提供用戶定製化體驗的信息，例如預測用戶下一個動作，用以在手機App上展示相應的選項。一個用於展示這些選項的請求也許會先去A服務獲取用戶的信息，然後去服務E獲取用於個性化的信息。
現在我們先對這些微服務是如何設計和運行的做一些合理的假設。由於請求數量很大，我們採用一個固定的散列函數把用戶請求均衡分散開，這樣一個固定的用戶只會由一個特定的節點服務，而不是所有A服務的節點都面對整個用戶羣。例如在A服務背後的數百個節點中，所有來自用戶“CLR”的請求只會被路由到節點A42。如果A42出現任何問題，足夠智能的路由邏輯會將A42的職責路由到集羣中的其他節點。
如果下游所依賴的服務出現異常，A服務有合理的預案。如果A服務無法和持久層通信，它就從本地緩存中返回結果。
在運行時，每個微服務會平衡監控、報警和資源的考量，以合理的兼顧性能和對內部的洞察，而不會對資源的利用率不管不顧。擴展規則會基於CPU負載和I/O性能來決定是否在資源稀缺時加入更多節點，以及在資源閒置時去掉多餘的節點。
現在我們的環境就緒了，讓我們來看看請求的模式。用戶“CLR”啓動了手機App應用，然後發送了一個請求來獲取內容豐富的App首頁。不巧的是，他的手機目前並不在服務區。用戶並不知道自己不在服務區，於是他發出了多次對首頁的請求，這些請求都被手機操作系統緩存在了本地隊列，以等待網絡連接恢復後發出。App本身也有重試機制，它在操作系統的本地隊列之外，也將這些請求緩存在了App自身的隊列中。
突然網絡連接恢復了。手機操作系統同時把數百個請求一次性的發送出去。因爲用戶“CLR”發起的是對首頁的請求，所以E服務被同時請求了數百次以獲取和用戶個性化體驗相關的信息。每一個對E服務的請求都會先請求A服務。於是A服務同時被打開首頁和其他服務（如E服務）請求了數百次。由於A服務的架構設計，所有“CLR”的請求都被路由到了節點A42。A42在這麼大流量下無法對所有請求都從持久層獲取數據，所以它切換到從本地緩存中獲取數據。
從緩衝中響應請求大大減少了爲每個請求提供服務所需的處理時間和I/O開銷。事實上，A42的CPU和I/O突然降到很低的水平，以至於其負載平均值低於集羣擴展策略的回收閾值。於是策略考慮資源的有效利用，對集羣進行了收縮，對A42進行了回收，同時將流量轉發到了集羣的其他節點。其他節點這時就需要額外的處理本屬於A42需要做的工作。比如A11接管了來自“CLR”的請求。
在A42轉移到A11的過程中，E服務中對A服務的請求超時了。於是E服務爲了自身能應對上游的請求，啓動了它的預案，返回了一些不含個性化的內容。
用戶“CLR”最終收到了響應，注意到內容不像平時那樣個性化，於是多刷新了幾次首頁。A11比平時需要處理的工作更多了，所以它也逐漸切換到從緩存中返回一些稍稍過時的信息。CPU和I/O相應的降低了，再一次提示集羣可以收縮了。
其他一些用戶也逐漸注意到他們的App展示給他們的內容不像往常那樣個性化了。他們也開始不斷刷新內容，這又觸發了更多的對A服務的請求。額外的流量壓力致使A服務中更多的節點選擇從緩存中返回信息，CPU和I/O進一步相應降低，集羣進一步加速收縮。更多的用戶注意到了問題，觸發了用戶引起的重試風暴。最終，整個集羣都開始從緩存中返回信息，重試風暴壓垮了其餘節點，A服務掉線了。B服務對於A服務掉線沒有預案，於是進一步拖垮了D服務，於是整個服務基本上都中斷了。
2.3 從例子中學到了什麼
上面的場景在系統理論中被稱爲“牛鞭效應”。輸入中的一點擾動會觸發一個自我強化的循環，最終導致輸出結果的劇烈波動。在上面的例子中，輸出的波動拖垮了整個應用。
上述例子中最重要的一個特徵是每一個單一的微服務的行爲都是合理的，只有在特定場景下這些行爲組合起來才導致了系統預期之外的行爲。這一類交互的複雜性不是人力可以完全預期到的。每一個微服務都可以被全面的測試覆蓋，但我們任然不能在任何測試場景或集成測試環境中看到這類行爲。
期待任何人類的架構師能理解這些組件和組件的交互模式，從而能充分預測這些預期之外的系統效應，都是不合理的。而混沌工程提供了可以讓這些效應浮出水面的工具，從而讓我們建立對複雜分佈式系統的信心。有了這個信心，我們就可以爲這些又龐大又充滿迷霧，無法被某一個個人全部理解的系統設計有效的架構，同時兼顧功能開發的速度。
混亂金剛（Chaos Kong）
在混亂猴子（Chaos Monkey）成功的基礎之上，我們決定繼續深入。混亂猴子的功能是關閉節點，而混亂金剛是用來關閉整個AWS區域。
Netflix視頻的每一個字節都來自於CDN。在峯值的時候，我們貢獻了大約北美互聯網三分之一的流量。這是世界上最大的CDN，它同時也包含着許許多多“令人着迷”的工程問題，我們先把混沌工程問題放在一旁，現在先聚焦在Netflix其他的一些服務上，我們稱之爲Netflix服務的“控制平面”（Control Plane）。（這類服務類似於路由器中執行Routing功能的部分。）
除了視頻流媒體來自CDN之外，所有其他與服務的交互都是由AWS雲服務的三個區域提供的。在數千種我們支持的設備上，從2007年的藍光播放器一直到最新款的智能手機，雲上應用處理全流程的服務，包括啓動、註冊、瀏覽、選擇視頻、播放，播放時的心跳檢測，等等。
2012年的聖誕節期間，AWS的一個單一區域發生了嚴重的中斷故障，這個事故迫使我們必須儘快採取多區域的策略。如果你對AWS區域不太瞭解，可以把它們想象爲多個數據中心。通過多區域的故障恢復策略，我們可以把所有用戶從故障的區域轉移到另一個，最大限度地控制單個區域中斷造成影響的範圍和時長。
這項工作需要負責微服務架構的多個團隊之間進行溝通協調。我們在2013年底完成了混亂金剛，我們打算用它來關閉整個AWS區域。這個硬性的強制促進了工程師們建造可以在AWS區域間平滑過渡服務的一致目標。這裏我們只是模擬整個區域中斷的故障，畢竟我們沒有權限把整個AWS區域真正中斷掉。
當我們認爲已經爲跨區域故障恢復做好了準備時，就開始了每個月一次的混亂金剛演習。在第一年，我們經常會發現故障恢復中各種各樣的問題，這些問題給了我們大量的空間進行改進。到第二年我們已經可以非常平滑地進行演習。我們現在已經能夠非常規律地進行演習，確保服務時刻具備應對整個區域中斷故障的彈性，無論這類故障是基礎設施導致的還是自己的軟件問題導致的。
以上是本書的第一部分，接下來的第二部分將會介紹混沌工程原則，有興趣的同學可以持續關注。
譯者簡介
侯傑，TGO鯤鵬會會員，美利金融技術副總裁，整體負責美利金融技術研發工作。曾在愛點擊，IBM中國，IBM澳大利亞擔任研發管理，諮詢管理等職位，帶領團隊負責過多個大規模金融行業信息化項目，和互聯網轉型實踐。畢業於南京大學。