学习笔记：混沌工程

个人理解：
混沌工程，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]小规模扩散实验的优势在于，它不会触及生产环境的阈值，例如断路器的阈值，这样你便可以验证每一个单一请求的超时和预案。这可以验证系统对瞬时异常的弹性。
接下来是进行小规模的集中实验，通过修改路由策略将所有实验覆盖的用户流量导向特定的节点。在这些节点上会做高度集中的故障、延迟等测试。在这里，我们会允许断路器打开，同时将隐藏的资源限制暴露出来。如果我们发现有无效的预案或者奇怪的锁竞争等情况导致服务中断，那么只有实验覆盖的用户会受到影响。这个实验模拟生产环境中的大规模故障，同时可以把负面影响控制到最小，结果却能使我们对系统建立高度的信心。
风险最大但最准确的实验是无自定义路由的大规模实验。在这个实验级别，实验结果应该在主控制台上显示，同时因为断路器和共享资源的限制，实验可能会影响不在实验覆盖范围内的用户。当然，没有什么比让所有生产环境中的用户都参与实验，能给你更多关于系统可以抵御特定故障场景的确定性了。
除了不断扩大实验范围，在实验造成过多危害时及时终止实验也是必不可少的。有些系统设计会使用降级模式来给用户带来较小的影响，这还好，但是在系统完全中断服务的时候，就应该立即终止实验。这可以由之前讨论过的“大红色按钮”来处理。
我们强烈建议实施自动终止实验，尤其是在定期自动执行实验的情况下。关于弄清楚如何构建一个可以实时监控我们感兴趣的指标，并可以随时实施混沌工程实验的系统，这完全依赖于你手上的独特的系统构造。