個人理解：
混沌工程，chaos engineering，找出系統中的脆弱環節的方法學
混沌工程是軟件測試和質量保證的一種方法，在黑客入侵之前或系統故障之前使用它來識別漏洞，由于混沌工程測試而做出的改變增加了人們對系統的信心。
混沌工程類似于壓力測試，旨在識別和糾正系統或網絡問題。
風險，有針對性地對系統進行加固、防范，確保系統可用性，從而避免故障發生時所帶來的嚴重后果
混沌工程：主動的，錯誤注入，找出風險，模擬驗證系統，有災假設，了解系統，了解系統脆弱性，提示弱點，驗證系統在某個特定條件下的反應和表現，提前預防，避免失效
軟件測試：被動的，找出問題，真實系統，驗證系統滿足預期
AD-HOC?testing + Exploratory testing

---

• What Is Chaos Engineering? | Micro Focus
• Chaos Engineering: the history, principles, and practice
• 一文讀懂混沌工程 - 知乎
• What is chaos engineering? Chaos engineering and its principles explained

What is chaos engineering?
混沌工程是什么？

Chaos engineering is the process of testing a distributed computing system to ensure that it can withstand unexpected disruptions. It relies on concepts underlying?chaos theory which focus on random and unpredictable behavior. The goal of chaos engineering is to identify weakness in a system through controlled experiments that introduce random and unpredictable behavior.
混沌工程用來測試分布試計算系統，以確保其可以承受未預期的中斷。混沌工程依附于聚焦隨機和不可預期行為的混沌理論，目標是通過控制實驗引入隨機和不可預期行為以識別系統弱點。

A main benefit of chaos engineering is that organizations can use it to identify vulnerabilities before a hacker does or before a system failure. Changes made as a result of chaos engineering testing increase confidence in an organization's systems.
混沌工程的主要優勢在于組織可以在黑客入侵或系統失效之前識別系統弱點。混沌工程測試后的改變結果提升了對組織系統的信心。

Some IT groups hold chaos engineering game days where teams try to break or breach systems. They use failure mode and effective analysis?or other tactics to get insight into potential points of failure in their organization's systems.
一些IT團隊舉辦混沌工程游戲日，以嘗試破壞系統。使用失效模式和有效分析或其他策略以深入了?解組織系統中潛在的失效點。

The concepts behind chaos engineering
混沌工程背后的概念

The main concept behind chaos engineering is to break a system on purpose to collect information that will help improve the system's resiliency. Chaos engineering is an approach to software testing?and quality assurance. It is well suited to modern distributed systems and processes.
混沌工程背后的主要概念是破壞系統，以收集信息提升系統彈性。混沌工程是軟件測試和質量保證的一種方法，非常適合于當代分布式系統和過程。

Chaos engineering is particularly applicable to distributed computing environments. A distributed computing?system is a group of computers linked over a network and sharing resources. These systems can break when unexpected situations occur. With large distributed systems, the components often have complex and unpredictable dependencies, and it is difficult to troubleshoot errors or predict when an error will occur.
混沌工程適用于分布式計算環境。分布式計算系統是通過網絡連接和共享資源的計算機群。非預期的情況發生時系統會被破壞。對于大型分布式系統，組件通常復雜和非預期的依賴，因此定位錯誤或預測錯誤何時發生非常困難。

There are many ways a distributed system can fail. Their size and complexity can cause seemingly random events to occur. The bigger and more complex the system, the more unpredictable and chaotic its behavior appears.
有多種方式導致分布式系統失效。容量和復雜度似乎導致隨機事件的發生。系統越大越復雜，其行為表現的越非預期和混沌。

Chaos engineering experiments intentionally generate turbulent conditions in a distributed system to test the system and find weaknesses. Some example of problems a chaos experiment might uncover include:
混沌工程試驗目的在于分布式系統產生渦流條件，以測試系統并發現弱點。以下混沌問題示例可能包括

• Blind spots.?Places where monitoring software cannot gather adequate data.
  盲點。?監控軟件不能收集足夠數據的地方。
• Hidden bugs.?Glitches or other issues that can cause software to malfunction.
  缺陷隱藏。導致軟件故障的小故障或其他問題。
• Performance?bottlenecks.?Situations where efficiency and performance could be improved.
  性能瓶頸。效率和性能能夠提升的條件。

As more companies move to the cloud or the enterprise edge,?their systems are becoming more distributed and complex. The same can be said about software development methodologies where continuous delivery?is emphasized. Those development processes are getting increasingly complex as well. As an organization's infrastructure and processes for working within that infrastructure become more complex, the need to adapt to chaos grows.
越來越多的企業遷移至云或企業邊緣計算，系統變的越來越分散和復雜。強調持續交付的軟件開發方法同樣如此，這些開發過程也變的越來越復雜。隨著內部工作的組織基礎和過程變的越來越復雜，對混沌的需要也隨之增加。

How chaos engineering works
混沌工程如何工作

Chaos engineering is similar to stress testing?in that it aims to identify and correct system or network issues. Unlike stress testing, chaos engineering doesn't test and correct one component at a time.
混沌工程與壓力測試類似，目的是識別和收集系統或網絡問題。不同于壓力測試，混沌工程不會一次測試和校正一個組件。

Chaos engineering examines problems that have a seemingly infinite number of possible causes. It looks beyond the obvious issues and tests distributed systems against problems or sets of problems that are less likely to happen. The goal is to gain new knowledge about the system.
混沌工程所檢查的問題似乎有無限種可能的原因。其超越了明顯的問題，并基于不太可能發生的問題或一組問題測試分布式系統，目的是獲得對系統的新認知。

The process is typically divided into several steps:
該過程通常分為以下幾步

Set the baseline.?Start by establishing a baseline. The testers must identify how the system should operate under optimal conditions and specify what constitutes a normal working state.
設置基線。始于建立基線，測試人員必須識別系統如何在最優條件下操作，并確定正常工作狀態組成

Create a hypothesis.?Consider one or more potential weaknesses and formulate a hypothesis about the effects of those weaknesses. For example, software testers might want to know what will happen if a large traffic spike occurs.
創建假設。假定一個或多個可能的弱點，并就弱點產生的影響提出假設。例如，軟件測試者可能想知道高峰值發生時會發生什么。

Test.?Conduct experiments to gauge the consequences of a large spike. The experiments might reveal an error in a critical process or an unexpected cause-and-effect relationship. For example, a traffic spike simulation might reveal a storage performance issue.
測試。進行實驗以測量大峰值結果。實驗可能揭示關鍵過程的錯誤或非預期的因果關系。例如，峰值模擬可能發現存儲的性能問題

Evaluate.?Measure and evaluate how the hypothesis holds up and determine which problems to fix.
評估。度量和評估假說如何成立，并確認需要修復哪些問題

Chaos engineering teams take an ordered approach in their experiments, testing the following:
混沌工程團隊實驗和測試采用了有序的方法

• The things they are aware of and understand.
  意識到并理解的事情。
• The things they are aware of but don't fully understand.
  意識到并不能完全理解的事情。
• The things they understand but are not aware of.
  理解但并未意識到的事情。
• The things they are not fully aware of and do not fully understand.
  未意識到和未完全理解的事情。

They use "what if" scenarios that can trigger faults and failures to evaluate the performance and integrity of the system.
他們使用“如果”場景，以觸發失效和失敗以評估系統性能和完整性。

Advanced principles of chaos engineering
混沌工程的高級原則

Computer scientist L. Peter Deutsch and his colleagues at Sun Microsystems developed a list of eight fallacies of distributed computing. These are false assumptions that programmers and engineers often make about distributed systems. They are a good starting point when applying chaos engineering to a problem. The eight fallacies include:
計算機科學家彼得·德奇和他的同事在太陽微系統公司開發了一份關于分布式計算的八個謬論清單，這些是程序員和工程師經常對分布式系統做出的錯誤假設。將混沌工程應用于問題時這是個很好的起點。這八個謬論包括：

The network is reliable.
網絡是可靠的

There is zero latency.
0延遲

Bandwidth is infinite.
帶寬無限

The network is secure.
網絡是安全的

?Topology?never changes.
拓撲永無變化

There is one admin.
只有一個管理員

Transport cost is zero.
傳輸成本為0

The network is homogeneous.
同類網絡 --?沒明白什么意思？

There is debate as to whether these fallacies are still fallacies, but chaos engineers continue to use them as core principles in understanding system and network problems. The theme underlying them is that systems and network are never perfect or 100% reliable. Because of this, we have the concept of "five nines" for highly available systems. Instead of striving for 100% availability, the closest engineers can get to perfection is 99.999%.
這些謬論是否仍為謬論存在著爭議，但混沌工程師們仍繼續使用這些謬論作為理解系統和網絡問題的核心原則，其主題是系統和網絡永不完美或100%可靠。因此對高可用系統我們有“5個9”的概念。取代100%可用性的，完美工程師盡力追求的是99.999%的可用性。

These false assumptions are easy to make in distributed computing environments, and they are the basis of the seemingly random problems that arise out of complex distributed systems.
這些錯誤假設在分布式計算環境中很容易實施，它們是復雜分布式系統產生的看似隨機問題的基礎。

??

Many chaos engineering experiments are designed around these eight fallacies, which serve as a basis for determining the source of a problem in distributed architecture.
多數混沌工程實驗圍繞這8個謬論進行設計，作為確認分布式架構的問題根源的基礎

Chaos engineering best practices
混沌工程最佳實踐

Chaos engineering is complicated. Following these best practices can help avoid problems that stem from the fallacies listed above:
混沌工程是復雜的，以下最佳實踐可以幫助避免以上問題謬論產生的問題：

• Understand the usual behavior of the system.?Having a solid understanding of the system when it is healthy will help in diagnosing problems.
  理解系統常規行為。對正常系統的扎實理解有助于診斷問題
• Simulate realistic scenarios.?Focus on injecting likely failures and bugs. For example, if latency has been a problem in the past, inject bugs that induce latency.
  模擬真實場景。專注于失敗和缺陷注入。例如，如果延遲過去是個問題，注入缺陷將會導致延遲
• Test using real-world conditions.?This yields the most accurate results. Chaos engineering is often performed in production environments, especially when it is too cumbersome or expensive to duplicate a large, distributed system for testing purposes.
  使用真實世界條件測試。這將會產生更準確的結果。混沌工程經常在生產環境執行，特別是過于繁瑣或昂貴時，無法復制大型分布式系統進行測試
• Minimize the blast radius.?Chaos engineering can be highly disruptive. Success demands coordination among IT staff, developers and business units. Experiments in production environments are rarely run at peak times, and ideally, nobody using the system will be able to tell that chaos experiments are taking place. Redundancy should be in place to ensure that services remain available if experiments do cause issues.
  減小爆炸半徑（影響滿園）混沌工程具有高度破壞性。其成功需要IT、開發、業務部門協作。生產環境中的實驗很少在峰值進行，理想情況下，沒有人能說明混沌試驗如何進行，實施冗余以確保如果實驗導致問題系統服務仍可用

Examples of chaos engineering
混沌工程實例

Imagine a distributed system that can handle a certain number of transactions per second. Chaos engineering testing can be used to find out how the software would respond when that transaction limit is reached. Does performance suffer or would the system crash?
假想一個分布式系統可以處理一定數量的每秒交易量。混沌工程測試用來發現當交易限制時軟件如何響應，性能受到影響或崩潰？

Chaos engineering can also be used to test how the distributed system behaves when it experiences a shortage of resources or?single point of failure. If the system fails, developers can implement design changes. Once changes are made, the test is repeated to verify the desired results.
混沌工程常用來測試資源短缺或單點失效時分布式系統的行為。如果系統失敗，開發會進行設計變更。一但實施變更，重復測試以驗證所需結果。

One notable real-world system failure had a chaos engineering connection. In 2015, Amazon's DynamoDB experienced an availability issue in one of its regional zones. That lapse caused over 20 Amazon Web Services that relied on DynamoDB to fail in that region. Sites that used the services -- including Netflix -- were down for several hours. However, Netflix experienced less of a failure than other sites, because it had created and used a chaos engineering tool called Chaos Kong to prepare for such a scenario.
一個真實系統失效與混沌工程相關的實例。2015年，亞馬遜DynamoDB在一個區域遇到了可用性問題，此失效導致20多個依靠DynamoDB的亞馬遜網絡服務在該地區失效。使用這些服務的站點（包括Netflix）關閉了幾個小時。然而，Netflix?的失敗少于其他網站，因為它創建并使用了一種名為 Chaos Kong 的混沌工程工具以應對此類場景。

Chaos Kong disables entire AWS availability zones, which are the AWS data centers that serve a geographical region. Using the tool had given Netflix experience responding to regional outages?like the one the DynamoDB issue caused. The company's ability to deal with the outage is often cited in explaining the importance of chaos engineering.
Chaos Kong禁用了整個 AWS 可用性區域，即作為地理服務的 AWS 數據中心。如 DynamoDB?造成的問題，Netflix?使用工具響應該該區域停電問題。在解釋混沌工程的重要性時，公司有能力處理停電問題。

Chaos engineering tools
混沌工程工具

Netflix was a notable pioneer of chaos engineering and was among the first to use it in production systems. Netflix designed and open sourced chaos test automation platforms collectively dubbed the Simian Army.
Netflix是混沌工程的先驅，也是在生產系統最早使用混沌工程的公司之一。Netflix設計并開源的混沌測試自動化平臺統稱為“Simian Army”

There are several tools included in the Simian Army suite, including:
Simian Army套件包含多種工具：

• Chaos Kong.?Disables entire AWS availability zones.
  Chaos Kong.?標用AWS整個可用區域
• Chaos Monkey.?Randomly disables production environment instances to cause a system failure but is designed to not have effects on customer activity.
  Chaos Monkey?猴子。隨機禁用生產環境實例導致系統失效，但設計不會對客戶活動產生影響
• Chaos Gorilla.?Like Chaos Monkey but on a larger scale.
  Chaos Gorilla?大猩猩。與Chaos Monkey類似但范圍更大
• Latency?Introduces latency to simulate network outages and degradation.
  延遲。引用延遲以模擬網絡中斷和惡化

??NETFLIX

Chaos Monkey is a tool that enables chaos engineering by creating problems on systems. Here, it is shown terminating instances of a service.
Chaos Monkey是一種在系統中創造問題以實現混沌工程的工具。在此展示了服務終止實例。

The Netflix Simian Army continues to grow as more chaos-inducing programs are created to test the streaming service's capabilities. Some other chaos engineering tools include:
Netflix Simian Army作為測試流服務能力而引發的混沌程序，持續增長。其他混沌工具包括：

Simoorg.?An open source failure-inducing program. LinkedIn uses this program to perform chaos engineering experiments.
Simoorg。開源失效誘導程序，LinkedIn使用該程序執行混沌工程實驗。

Monkey-Ops.?An open source tool implemented in Go and built to test and terminate random components and deployment configurations.
Monkey-Ops。Go中實現的開源工具，用于測試和終止隨機組件和部署配置

Gremlin.?A chaos engineering program that works with AWS and Kubernetes?and focuses on the retail and finance sectors. It comes with built-in redundancy that stops chaos engineering experiments when they threaten the system.
Gremlin。工作在AWS和K8s的混沌工程程序，專注于零食和金融，內建冗余以在混沌工程實驗遇到系統威脅時終止該實驗

AWS Fault Injection Simulator.?Includes fault templates that AWS can inject into production instances. The platform has built-in redundancy and protective measures to keep the?failure injection testing?from causing system problems.
AWS失效注入模擬。使用失效模板AWS可以注入生產實例，該平臺內建冗余和保護措施以防止失效注入測試導致的系統問題。

Testing, resilience and quality assurance in modern DevOps software development environments is crucial. Learn best practices for testing in DevOps implementations?where continuous delivery and experimentation is a priority.
測試，現代DevOps軟件開發環境中，彈性和質量保證是至關重要的。學習DevOps實施中的測試最佳實踐是持續交付和實驗中的優先事項。

---

混沌工程介紹 - sunyllove

混沌工程基礎介紹

在一個由很多微服務組成的分布式系統中，我們永遠難以全面掌握發生什么事件會導致系統局部不可用，甚至全面崩潰。但我們卻可以盡可能地在這些不可用的情況發生之前找出系統中的脆弱點。Netflix的工程師團隊是根據多年實踐經驗主動發現系統中脆弱點的一整套方法。這套方法現在已經逐漸演變成計算機科學的一門新興學科，即“混沌工程”。通過一系列可控的實驗和執行實驗的原則，混沌工程將揭示出分布式系統中隨時發生的各類事件是如何逐步導致系統整體不可用的。

混沌工程是什么

混沌工程是一門新興的技術學科，它的初衷是通過實驗性的方法，讓人們建立復雜分布式系統能夠在生產中抵御突發事件能力的信心。
只要你有過在生產環境中實際運行一個分布式系統的經歷，你就應該清楚，各種不可預期的突發事件是一定會發生的。分布式系統天生包含大量的交互、依賴點，可能出錯的地方數不勝數。硬盤故障，網絡不通，流量激增壓垮某些組件……我們可以不停地列舉下去。這都是每天要面臨的常事，任何一次處理不好就有可能導致業務停滯、性能低下，或者其他各種無法預料的異常行為。
在一個復雜的分布式系統中，我們單靠人力并不能夠完全阻止這些故障的發生，而應該致力于在這些異常行為被觸發之前，盡可能多地識別出會導致這些異常的、在系統中脆弱的、易出故障的環節。當我們識別出這些風險時，就可以有針對性地對系統進行加固、防范，從而避免故障發生時所帶來的嚴重后果。我們能夠在不斷打造更具彈性[1]系統的同時，建立對運行高可用分布式系統的信心。
混沌工程正是這樣一套通過在系統基礎設施上進行實驗，主動找出系統中的脆弱環節的方法學。這種通過實驗驗證的方法顯然可以為我們打造更具彈性的系統，同時讓我們更透徹地掌握系統運行時的各種行為規律。
混沌工程，是一種提高技術架構彈性能力的復雜技術手段。Chaos工程經過實驗可以確保系統的可用性。混沌工程旨在將故障扼殺在襁褓之中，也就是在故障造成中斷之前將它們識別出來。通過主動制造故障，測試系統在各種壓力下的行為，識別并修復故障問題，避免造成嚴重后果。
它被描述為“在分布式系統上進行實驗的學科，目的是建立對系統承受生產環境中湍流條件能力的信心。”
它也可以視為流感疫苗，故意將有害物質注入體內以防止未來疾病，這似乎很瘋狂，但這種方法也適用于分布式云系統。混沌工程會將故障注入系統以測試系統對其的響應。這使公司能夠為宕機做準備，并在宕機發生之前將其影響降至最低。
如何知道系統是否處于穩定狀態呢？通常，團隊可以通過單元測試、集成測試和性能測試等手段進行驗證。但是，無論這些測試寫的多好，我們認為都遠遠不夠，因為錯誤可以在任何時間發生，尤其是對分布式系統而言，此時就需要引入混沌工程（Chaos Engineering）。
故障演練：目標是沉淀通用的故障模式，以可控成本在線上重放，以持續性的演練和回歸方式運營來暴露問題，推動系統、工具、流程、人員能力的不斷前進。

為什么需要混沌工程

1 ) 混沌工程與測試的區別
混沌工程、故障注入和故障測試在側重點和工具集的使用上有一些重疊。舉個例子，Netflix的很多混沌工程實驗的研究對象都是基于故障注入來引入的。混沌工程和其他測試方法的主要區別在于，混沌工程是發現新信息的實踐過程，而故障注入則是基于一個特定的條件、變量的驗證方法。
例如，當你希望探究復雜系統會如何應對異常時，會對系統中的服務注入通信故障，如超時、錯誤等，這是一個典型的故障注入場景。但有時我們希望探究更多其他非故障類的場景，如流量激增、資源競爭條件、拜占庭故障（例如性能差或有異常的節點發出錯誤的響應、異常的行為、對調用者隨機返回不同的響應等）、非計劃中的或消息內容非正常組合的處理等。如果一個面向公眾用戶的網站突然出現流量激增的情況，從而產生了更多的收入，那么我們很難將這種情況稱為故障，但我們仍然需要探究清楚系統在這種情況下會如何變現。和故障注入類似，故障測試是通過對預先設想到的可以破壞系統的點進行測試，但是并不能去探究上述這類更廣闊領域里的、不可預知的、但很可能發生的事情。
我們可以描述一下測試和實驗最重要的區別。在測試中，我們要進行斷言：給定一個特定的條件，系統會輸出一個特定的結果。一般來說，測試只會產生二元的結果，即驗證一個結果是真還是假，從而判定測試是否通過。嚴格意義上來說，這個實踐過程并不能讓我們發掘出系統未知的或尚不明確的認知，它僅僅是對已知的系統屬性可能的取值進行測驗。而實驗可以產生新的認知，而且通常還能開辟出一個更廣袤的對復雜系統的認知空間。整本書都在探討這個主題——混沌工程是一種幫助我們獲得更多的關于系統的新認知的實驗方法。它和已有的功能測試、集成測試等測試已知屬性的方法有本質上的區別。

一些混沌工程實驗的輸入樣例：

• 模擬整個云服務區域或整個數據中心的故障。
• 跨多實例刪除部分Kafka主題（Topic）來重現生產環境中發生過的問題。
• 挑選一個時間段，針對一部分流量，對其涉及的服務之間的調用注入一些特定的延時。
• 方法級別的混亂（運行時注入）：讓方法隨機拋出各種異常。
• 代碼插入：在目標程序中插入一些指令，使得故障注入在這些指令之前先運行。
• 強迫系統節點間的時間彼此不同步。
• 在驅動程序中執行模擬I/O錯誤的程序。
• 讓一個Elasticsearch集群的CPU超負荷。

混沌工程實驗的機會是無限的，可能會根據您的分布式系統的架構和您組織的核心業務價值而有所不同。

實施混沌工程的先決條件
要確定您的組織是否已準備好開始采用Chaos Engineering，您需要回答一個問題：您的系統是否能夠適應現實世界中的事件，例如服務故障和網絡延遲峰值？
如果您知道答案是“否”，您還有一些工作要做。Chaos Engineering非常適合揭露生產系統中未知的弱點，但如果您確定混沌工程實驗會導致系統出現嚴重問題，那么運行該實驗就沒有任何意義。先解決這個弱點。然后回到Chaos Engineering，它將發現你不了解的其他弱點，或者它會讓你更有信心你的系統實際上是有彈性的。混沌工程的另一個基本要素是可用于確定系統當前狀態的監控系統。如果不了解系統的行為，您將無法從實驗中得出結論。

混沌工程原則
“混亂”一詞讓我們想起隨機性和無序性。然而，這并不意味著混沌工程的實施也是隨機和隨意的，也不意味著混沌工程師的工作就是引發混亂。相反的是，我們把混沌工程視為一門原則性很強的學科，特別是一門實驗性的學科。
在上面的引用中，Dekker觀測了分布式系統的整體行為，他也主張從整體上了解復雜系統是如何失效的。我們不應該僅僅著眼于發生故障的組件，而是應該嘗試去理解，像組件交互中一些偶發的意外行為，最終是如何導致系統整體滑向一個不安全、不穩定的狀態的。
你可以將混沌工程視為一種解決“我們的系統離混亂邊緣有多少距離”的經驗方法。從另一個角度去思考，“如果我們把混亂注入系統，它會怎么樣？”
在這一部分，我們會介紹混沌工程實驗的基本設計方法，之后會討論一些更高級的原則。這些原則建立在真正實施混沌工程的大規模系統之上。在實施混沌工程的過程中，并不是所有高級原則都必須用到。但我們發現，運用的原則越多，你對系統彈性的信心就越充足。
軟件系統里并沒有類似的傳遞函數。像很多復雜系統一樣，我們無法為軟件系統表現出的各種行為建立一個預測模型。如果我們有這樣一個模型，可以推導出一次網絡延遲驟升會給系統帶來什么影響，那就太完美了。但不幸的是，迄今為止我們并沒有發現這樣一個模型。
因為我們缺乏這樣一個理論的預測模型，因此就不得不通過經驗方法來了解在不同的情況下我們的系統會如何表現。我們通過在系統上運行各種各樣的實驗來了解系統的表現。我們嘗試給系統制造各種麻煩，看它會發生什么狀況。但是，我們肯定不會給系統不同的隨機輸入。我們在系統分析之后，期望能夠最大化每個實驗可以獲得的信息。正如科學家通過實驗來研究自然現象一樣，我們也通過實驗來揭示系統的行為。
在開發混沌工程實驗時，請牢記以下原則：（它們將有助于實驗的設計）

? 建立穩定狀態的假設；

? 用多樣的現實世界事件做驗證；

? 在生產環境中進行實驗；

? 自動化實驗以持續運行；

? 最小化爆炸半徑；

1. 建立穩定狀態假設
任何復雜系統都會有許多可變動的部件、許多信號，以及許多形式的輸出。我們需要用一個通用的方式來區分系統行為是在預料之內的，還是在預料之外的。我們可以將系統正常運行時的狀態定義為系統的“穩定狀態”。
很多現有的數據采集框架已經默認采集大量的系統級別指標，所以通常來說，讓你的系統有能力抓取業務級別的指標比抓取系統級別的指標更難。然而花精力來采集業務級別的指標是值得的，因為它們才能真實地反映系統的健康狀況。這些指標獲取的延遲越低越好：那些在月底算出來的業務指標和系統今天的健康狀況毫無關系。
在選擇指標時，你需要平衡以下幾點：

• ? 指標和底層架構的關系。
• ? 收集相關數據需要的工作量。
• ? 指標和系統接下來的行為之間的時間延遲。

如果你還不能直接獲得和業務直接相關的指標，則也可以先暫時利用一些系統指標，比如系統吞吐率、錯誤率、99%以上的延遲等。你選擇的指標和自己的業務關系越強，得到的可以采取可執行策略的信號就越強。你可以把這些指標想象成系統的生命特征指標，如脈搏、血壓、體溫等。同樣重要的是，在客戶端驗證一個服務產生的警報可以提高整體效率，并可以作為對服務器端指標的補充，以構成某一時刻用戶體驗的完整畫面。

2. 用多樣的現實世界事件做驗證
每個系統，從簡單到復雜，只要運行時間足夠長，都會受到不可預測的事件和條件的影響。例如，負載的增加、硬件故障、軟件缺陷，以及非法數據（有時稱為臟數據）的引入。我們無法窮舉所有可能的事件或條件，但常見的有以下幾類：
? 硬件故障。
? 功能缺陷。
? 狀態轉換異常（例如發送方和接收方的狀態不一致）。
? 網絡延遲和分區。
? 上行或下行輸入的大幅波動以及重試風暴。
? 資源耗盡。
? 服務之間不正常的或者預料之外的組合調用。
? 拜占庭故障（例如性能差或有異常的節點發出有錯誤的響應、異常的行為、對調用者隨機地返回不同的響應等）。
? 資源競爭條件。
? 下游依賴故障。
也許最復雜的情況是上述事件的各類組合導致系統發生異常行為。

要徹底阻止對可用性的各種威脅是不可能的，但是我們可以盡可能地減輕這些威脅。在決定引入哪些事件的時候，我們應當估算這些事件發生的頻率和影響范圍，權衡引入它們的成本和復雜度。在Netflix，我們選擇關閉節點的一方面原因是，節點中斷在現實中發生的頻率很高，而引入關閉節點事件的成本和難度很低。對于區域故障來說，即使引入一些事件的成本高昂且引入流程復雜，我們還是必須要做，因為區域性故障對用戶的影響是巨大的，除非我們有足夠的彈性應對它。

文化因素也是一種成本。例如在傳統數據中心的文化中，基礎設施和系統的健壯性、穩定性高于一切，所以傳統數據中心通常會對變更進行嚴格的流程控制。這種流程控制，和頻繁關閉節點的操作是一對天然的矛盾體。隨機關閉節點的實驗對傳統數據中心的文化是一種挑戰。隨著服務從數據中心遷移到云上，管理基礎設施的職責被轉移給了云服務提供商，硬件的各類故障都由云服務平臺管理，工程部門對硬件故障就越來越習以為常。這種認知實際上在鼓勵一種將故障當作可預料的態度，這種態度可以進一步推動混沌工程的引入和實施。雖然硬件故障并不是導致線上事故最常見的原因，但是注入硬件故障是在組織中引入混沌工程并獲益的一個較簡單的途徑。

和硬件故障一樣，一些現實世界的事件也可以被直接注入，例如每臺機器的負載增加、通信延遲、網絡分區、證書失效、時間偏差、數據膨脹等。除此之外的一些事件的注入可能會具有技術或文化上的障礙，所以我們需要尋找其他方法來看一看它們會如何影響生產環境。[1]例如，發布有缺陷的代碼。金絲雀發布可以阻止許多顯而易見的簡單軟件缺陷被大規模發布到生產環境中，但其并不能阻止全部的缺陷被發布出去。故意發布有缺陷的代碼風險太大，可能會給用戶帶來嚴重的影響（參見第7章）。要模擬這類發布所帶來的缺陷問題，一種辦法是對相應的服務調用注入異常。

3.在生產環境中進行實驗
在我們這個行業里，在生產環境中進行軟件驗證的想法通常都會被嘲笑。“我們要在生產環境中驗證”這句話更像是黑色幽默，它可以被翻譯成“我們在發布之前不打算完整地驗證這些代碼”。
經典測試的一般信條是，尋找軟件缺陷要離生產環境越遠越好。例如，在單元測試中發現缺陷比在集成測試中發現更好。這里的邏輯是，離生產環境的整個部署越遠，就越容易找到缺陷的根本原因并將其徹底修復。如果你曾經分別在單元測試、集成測試和生產環境中調試過問題，上述邏輯的好處就不言而喻了。
但是在混沌工程領域，整個策略卻要反過來。在離生產環境越近的地方進行實驗越好。理想的實踐就是直接在生產環境中進行實驗。
在傳統的軟件測試中，我們是在驗證代碼邏輯的正確性，是在對函數和方法的行為有良好理解的情況下，寫測試來驗證它們對不對。換句話說，是在驗證代碼寫得對不對。
而當進行混沌工程的實驗時，我們所感興趣的是整個系統作為一個整體的行為。代碼只是整個系統中比較重要的一部分，而除了代碼，整個系統還包含很多其他方面，特別是狀態、輸入，以及第三方系統導致的難以預見的系統行為。
下面來深入了解一下為什么在生產環境中進行實驗對混沌工程來說是至關重要的。我們要在生產環境中建立對系統的信心，所以當然需要在生產環境中進行實驗。否則，我們就僅僅是在其他并不太關心的環境中建立對系統的信心，這會大大削弱這些實踐的價值。
即便你不能在生產環境中進行實驗，也要盡可能地在離生產環境最近的環境中進行。越接近生產環境，對實驗外部有效性的威脅就越少，對實驗結果的信心就越足。

4.自動化實驗以持續運行
手動執行一次性的實驗是非常好的第一步。當我們想出尋找故障空間的新方法時，經常從手動的方法開始，小心謹慎地處理每一件事以期建立對實驗和對系統的信心。所有當事人都聚集在一起，并向CORE（Critical Operations Response Engineering，Netflix的SRE團隊的名稱）發出一個警示信息，說明一個新的實驗即將開始。
這種謹小慎微的態度有利于：a）正確運行實驗，b）確保實驗有最小的爆炸半徑。在成功執行實驗后，下一步就是將這個實驗自動化，讓其持續運行。
如果一個實驗不是自動化的，那么就可以將這個實驗廢棄。

5.最小化爆炸半徑
我們經常運行本來只會影響一小部分用戶的測試，卻由于級聯故障無意中影響到了更多的用戶。在這些情況下，我們不得不立即中斷實驗。雖然我們絕不想發生這種情況，但隨時遏制和停止實驗的能力是必備的，這可以避免造成更大的危機。我們的實驗通過很多方法來探尋故障會造成的未知的和不可預見的影響，所以關鍵在于如何讓這些薄弱環節曝光出來而不會因意外造成更大規模的故障。我們稱之為“最小化爆炸半徑”。
能帶來最大信心的實驗也是風險最大的，是對所有生產流量都有影響的實驗。而混沌工程實驗應該只承受可以衡量的風險，并采用遞進的方式，進行的每一步實驗都在前一步的基礎之上。這種遞進的方式不斷增加我們對系統的信心，而不會對用戶造成過多不必要的影響。
最小風險的實驗只作用于很少的用戶。為此在我們驗證客戶端功能時只向一小部分終端注入故障。這些實驗僅限于影響一小部分用戶或一小部分流程。它們不能代表全部生產流量，但卻是很好的早期指標。例如，如果一個網站無法通過早期實驗，那么就沒有必要影響其余的大量真實用戶。
在自動化實驗成功之后（或者在少量的設備驗證沒有涵蓋要測試的功能時），下一步就是運行小規模的擴散實驗。這種實驗會影響一小部分用戶，因為我們允許這些流量遵循正常的路由規則，所以它們最終會在生產服務器上均勻分布。對于此類實驗，你需要用定義好的成功指標[1]來過濾所有被影響的用戶，以防實驗的影響被生產環境的噪聲掩蓋。[2]小規模擴散實驗的優勢在于，它不會觸及生產環境的閾值，例如斷路器的閾值，這樣你便可以驗證每一個單一請求的超時和預案。這可以驗證系統對瞬時異常的彈性。
接下來是進行小規模的集中實驗，通過修改路由策略將所有實驗覆蓋的用戶流量導向特定的節點。在這些節點上會做高度集中的故障、延遲等測試。在這里，我們會允許斷路器打開，同時將隱藏的資源限制暴露出來。如果我們發現有無效的預案或者奇怪的鎖競爭等情況導致服務中斷，那么只有實驗覆蓋的用戶會受到影響。這個實驗模擬生產環境中的大規模故障，同時可以把負面影響控制到最小，結果卻能使我們對系統建立高度的信心。
風險最大但最準確的實驗是無自定義路由的大規模實驗。在這個實驗級別，實驗結果應該在主控制臺上顯示，同時因為斷路器和共享資源的限制，實驗可能會影響不在實驗覆蓋范圍內的用戶。當然，沒有什么比讓所有生產環境中的用戶都參與實驗，能給你更多關于系統可以抵御特定故障場景的確定性了。
除了不斷擴大實驗范圍，在實驗造成過多危害時及時終止實驗也是必不可少的。有些系統設計會使用降級模式來給用戶帶來較小的影響，這還好，但是在系統完全中斷服務的時候，就應該立即終止實驗。這可以由之前討論過的“大紅色按鈕”來處理。
我們強烈建議實施自動終止實驗，尤其是在定期自動執行實驗的情況下。關于弄清楚如何構建一個可以實時監控我們感興趣的指標，并可以隨時實施混沌工程實驗的系統，這完全依賴于你手上的獨特的系統構造。

總結

以上是生活随笔為你收集整理的学习笔记：混沌工程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。