转：混沌工程

Posted 2022-12-30 Rolei_zl

个人理解：
混沌工程，chaos engineering，找出系统中的脆弱环节的方法学
混沌工程是软件测试和质量保证的一种方法，在黑客入侵之前或系统故障之前使用它来识别漏洞，由于混沌工程测试而做出的改变增加了人们对系统的信心。
混沌工程类似于压力测试，旨在识别和纠正系统或网络问题。
风险，有针对性地对系统进行加固、防范，确保系统可用性，从而避免故障发生时所带来的严重后果

---

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.

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:

1. 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.
2. 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.
3. 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.
4. 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:

1. The network is reliable.
2. There is zero latency.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology never changes.
6. There is one admin.
7. Transport cost is zero.
8. 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%.

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.

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.

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.

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 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.

There are several tools included in the Simian Army suite, including:

• Chaos Kong. Disables entire AWS availability zones.
• Chaos Monkey. Randomly disables production environment instances to cause a system failure but is designed to not have effects on customer activity.
• Chaos Gorilla. Like Chaos Monkey but on a larger scale.
• 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.

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:

Simoorg. An open source failure-inducing program. LinkedIn uses this program to perform chaos engineering experiments.

Monkey-Ops. An open source tool implemented in Go and built to test and terminate random components and deployment configurations.

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.

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.

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.

---

一文读懂混沌工程 - 知乎 

混沌工程通常用于测试分布式计算系统，以确保其能够承受意外的中断。混沌工程基于随机和不可预知行为的混沌理念，混沌工程的目标是通过引入随机和不可预知行为的受控实验来识别系统中的弱点。混沌工程的主要好处是组织可以在黑客入侵之前或系统故障之前使用它来识别漏洞。由于混沌工程测试而做出的改变增加了人们对系统的信心。一些 IT 团队举办混沌工程游戏日，团队尝试破坏系统，使用故障模式、有效分析或其他策略来深入了解组织系统中的潜在故障点。

混沌工程背后的理念
混沌工程背后的主要理念是破坏系统收集相关信息，这将有助于提高系统的弹性。混沌工程是软件测试和质量保证的一种方法，非常适合现代分布式系统和流程。混沌工程特别适用于分布式计算环境，分布式计算系统是一组通过网络连接并共享资源的计算机。当意外情况发生时，这些系统可能会中断。对于大型分布式系统，组件通常具有复杂且不可预知的依赖性，并且很难排除错误或预测何时会发生错误。分布式系统有许多方式可能会失效。大小和复杂性可能导致看似随机的事件发生。系统越大、越复杂，其行为就越不可预测和混沌。混沌工程实验故意在分布式系统中产生湍流条件，以测试系统并找出弱点。混沌实验可能发现问题的一些示例包括：
· 盲点：监控软件无法收集足够数据的地方。
· 隐藏的错误：故障或其他可能导致软件故障的问题。
· 性能瓶颈：效率和性能可以改进的情况。
随着越来越多的公司迁移到云或边缘计算，他们的系统变得越来越分散和复杂。强调持续交付的软件开发方法也是如此。这些发展过程也变得越来越复杂。随着组织在基础设施内工作的基础设施和流程变得更加复杂，适应混沌的需求也随之增加。

混沌工程如何运作
混沌工程类似于压力测试，旨在识别和纠正系统或网络问题。与压力测试不同，混沌工程不一次测试和校正一个组件。混沌工程检查的问题，似乎有无限数量的可能原因。它超越了显而易见的问题，并针对不太可能发生的问题或一组问题测试分布式系统。目标是获得有关该系统的新知识。该过程通常分为几个步骤：
1. 设置基线：首先建立基线，测试人员必须确定系统应如何在最佳条件下运行，并指定什么是正常工作状态。
2. 创建一个假设：考虑一个或多个潜在的弱点，并就这些弱点的影响提出一个假设。例如，软件测试人员可能想知道如果出现大流量峰值会发生什么情况。
3. 测试：进行实验，以测量大峰值的后果。实验可能揭示关键过程中的错误或意外的因果关系。例如，流量峰值模拟可能会显示存储性能问题。
4. 评估：衡量和评估假说如何成立，并确定需要解决哪些问题。
混沌工程团队在实验中采取有序的方法，测试如下：
· 了解和理解的事情。
· 意识到但并不完全理解的事情。
· 理解但不知道的事情。
· 并不完全了解和不完全理解的事情。
使用"如果"场景，可以触发故障和故障来评估系统的性能和完整性。

混沌工程的先进原则
计算机科学家彼得·德奇和他的同事在太阳微系统公司开发了一份分布式计算的八个谬论清单。这些是程序员和工程师经常对分布式系统做出的错误假设。在将混沌工程应用于问题时，它们是一个很好的起点。这八个谬论包括：
1. 网络是可靠的。
2. 没有延迟。
3. 带宽是无限的。
4. 网络是安全的。
5. 拓扑永远不会改变。
6. 有一个管理员。
7. 运输成本为零。
8. 网络是同质的。
关于这些谬论是否仍然是谬论，存在争议，但混沌的工程师们继续将谬论作为理解系统和网络问题的核心原则。其主题是系统和网络永远不完美或 100% 可靠。正因为这样，对于高度可用的系统有了"五个九"的概念。最接近完美的工程师不是争取 100% 的可用性， 而是 99.999% 。这些错误的假设在分布式计算环境中很容易做出，并且它们是复杂分布式系统产生的看似随机问题的基础。

混沌工程最佳实践
混沌工程很复杂，遵循这些最佳实践可以帮助避免上述谬论产生的问题：
· 了解系统的通常行为：在系统健康时对系统有一个坚实的理解将有助于诊断问题。
· 模拟逼真的场景：专注于可能的失败和错误。例如，如果延迟在过去是个问题，则关注诱导延迟的错误。
· 使用真实情况进行测试：这将产生最准确的结果。混沌工程通常在生产环境中进行，尤其是当它过于繁琐或昂贵，无法复制大型分布式系统进行测试时。
· 最大限度地减少爆炸半径：混沌工程可能具有高度破坏性。成功需要 IT 人员、开发人员和业务部门之间的协调。生产环境中的实验很少在高峰期进行，理想情况下，使用该系统的人无法判断正在进行混沌实验。应实行冗余，以确保如果实验确实造成问题，服务仍然可用。

混沌工程的例子
想象一下，一个分布式系统，可以处理一定数量的交易每秒。混沌工程测试可用于了解软件在达到交易限制时会如何响应。性能是否受到影响，或者系统是否会崩溃？混沌工程还可用于测试分布式系统在资源短缺或单点故障时的行为。如果系统出现故障，开发人员可以实施设计更改。更改后，将重复测试以验证所需的结果。一个值得注意的真实系统故障与混沌的工程连接有关。2015年，亚马逊的 DynamoDB 在其一个区域遇到了可用性问题。这一失误导致20多个依靠DynamoDB的亚马逊网络服务在该地区失效。使用这些服务的网站（包括Netflix）关闭了几个小时。然而，Netflix 遇到的失败比其他网站少，因为它创建并使用了一种名为 Chaos Kong （混沌金刚）的混沌工程工具来为此类场景做准备。Chaos Kong禁用了整个 AWS 可用性区域，即为地理区域提供服务的 AWS 数据中心。使用该工具为Netflix 提供了应对区域中断的经验，如 DynamoDB 问题造成的中断。在解释混沌工程的重要性时，经常提到公司处理停电问题的能力。

混沌工程工具
Netflix 是混沌工程的著名先驱，也是最早将其用于生产系统的公司之一。Netflix 设计并开源的混沌测试自动化平台统称为" Simian Army."。Simian Army.套房中包括几种工具，包括：
· 混沌金刚：禁用整个 AWS 可用区。
· 混沌猴子：随机禁用生产环境实例会导致系统故障，但设计不会对客户活动产生影响。
· 混沌大猩猩：像混沌猴子，但在更大的规模。
· 延迟：引入延迟以模拟网络中断和退化。

混沌猴子是一种工具，通过在系统上制造问题来实现混沌工程。在这里它显示了服务终止实例。随着更多引发混沌的节目被创建来测试流媒体服务的功能，Netflix Simian Arm继续增长。其他一些混沌工程工具包括：
Simoorg：开源故障诱导程序，LinkedIn使用这个程序进行混沌工程实验。
Monkey-Ops：在 Go 中实现并构建的开源工具，用于测试和终止随机组件和部署配置。
Gremlin：一个混沌的工程项目，与AWS和Kubernetes合作，专注于零售和金融行业。它附带了内置冗余，在混沌工程实验威胁系统时阻止它们。
AWS Fault Injection Simulator：AWS 可以注入生产实例的故障模板。该平台具有内置冗余和保护措施，以防止故障注入测试造成系统问题。

---

混沌工程介绍 - sunyllove

混沌工程基础介绍

在一个由很多微服务组成的分布式系统中，我们永远难以全面掌握发生什么事件会导致系统局部不可用，甚至全面崩溃。但我们却可以尽可能地在这些不可用的情况发生之前找出系统中的脆弱点。Netflix的工程师团队是根据多年实践经验主动发现系统中脆弱点的一整套方法。这套方法现在已经逐渐演变成计算机科学的一门新兴学科，即“混沌工程”。通过一系列可控的实验和执行实验的原则，混沌工程将揭示出分布式系统中随时发生的各类事件是如何逐步导致系统整体不可用的。

混沌工程是什么

混沌工程是一门新兴的技术学科，它的初衷是通过实验性的方法，让人们建立复杂分布式系统能够在生产中抵御突发事件能力的信心。
只要你有过在生产环境中实际运行一个分布式系统的经历，你就应该清楚，各种不可预期的突发事件是一定会发生的。分布式系统天生包含大量的交互、依赖点，可能出错的地方数不胜数。硬盘故障，网络不通，流量激增压垮某些组件……我们可以不停地列举下去。这都是每天要面临的常事，任何一次处理不好就有可能导致业务停滞、性能低下，或者其他各种无法预料的异常行为。
在一个复杂的分布式系统中，我们单靠人力并不能够完全阻止这些故障的发生，而应该致力于在这些异常行为被触发之前，尽可能多地识别出会导致这些异常的、在系统中脆弱的、易出故障的环节。当我们识别出这些风险时，就可以有针对性地对系统进行加固、防范，从而避免故障发生时所带来的严重后果。我们能够在不断打造更具弹性[1]系统的同时，建立对运行高可用分布式系统的信心。
混沌工程正是这样一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学。这种通过实验验证的方法显然可以为我们打造更具弹性的系统，同时让我们更透彻地掌握系统运行时的各种行为规律。
混沌工程，是一种提高技术架构弹性能力的复杂技术手段。Chaos工程经过实验可以确保系统的可用性。混沌工程旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。
它被描述为“在分布式系统上进行实验的学科，目的是建立对系统承受生产环境中湍流条件能力的信心。”
它也可以视为流感疫苗，故意将有害物质注入体内以防止未来疾病，这似乎很疯狂，但这种方法也适用于分布式云系统。混沌工程会将故障注入系统以测试系统对其的响应。这使公司能够为宕机做准备，并在宕机发生之前将其影响降至最低。
如何知道系统是否处于稳定状态呢？通常，团队可以通过单元测试、集成测试和性能测试等手段进行验证。但是，无论这些测试写的多好，我们认为都远远不够，因为错误可以在任何时间发生，尤其是对分布式系统而言，此时就需要引入混沌工程（Chaos Engineering）。
故障演练：目标是沉淀通用的故障模式，以可控成本在线上重放，以持续性的演练和回归方式运营来暴露问题，推动系统、工具、流程、人员能力的不断前进。

为什么需要混沌工程

1 ) 混沌工程与测试的区别
混沌工程、故障注入和故障测试在侧重点和工具集的使用上有一些重叠。举个例子，Netflix的很多混沌工程实验的研究对象都是基于故障注入来引入的。混沌工程和其他测试方法的主要区别在于，混沌工程是发现新信息的实践过程，而故障注入则是基于一个特定的条件、变量的验证方法。
例如，当你希望探究复杂系统会如何应对异常时，会对系统中的服务注入通信故障，如超时、错误等，这是一个典型的故障注入场景。但有时我们希望探究更多其他非故障类的场景，如流量激增、资源竞争条件、拜占庭故障（例如性能差或有异常的节点发出错误的响应、异常的行为、对调用者随机返回不同的响应等）、非计划中的或消息内容非正常组合的处理等。如果一个面向公众用户的网站突然出现流量激增的情况，从而产生了更多的收入，那么我们很难将这种情况称为故障，但我们仍然需要探究清楚系统在这种情况下会如何变现。和故障注入类似，故障测试是通过对预先设想到的可以破坏系统的点进行测试，但是并不能去探究上述这类更广阔领域里的、不可预知的、但很可能发生的事情。
我们可以描述一下测试和实验最重要的区别。在测试中，我们要进行断言：给定一个特定的条件，系统会输出一个特定的结果。一般来说，测试只会产生二元的结果，即验证一个结果是真还是假，从而判定测试是否通过。严格意义上来说，这个实践过程并不能让我们发掘出系统未知的或尚不明确的认知，它仅仅是对已知的系统属性可能的取值进行测验。而实验可以产生新的认知，而且通常还能开辟出一个更广袤的对复杂系统的认知空间。整本书都在探讨这个主题——混沌工程是一种帮助我们获得更多的关于系统的新认知的实验方法。它和已有的功能测试、集成测试等测试已知属性的方法有本质上的区别。

一些混沌工程实验的输入样例：

• 模拟整个云服务区域或整个数据中心的故障。
• 跨多实例删除部分Kafka主题（Topic）来重现生产环境中发生过的问题。
• 挑选一个时间段，针对一部分流量，对其涉及的服务之间的调用注入一些特定的延时。
• 方法级别的混乱（运行时注入）：让方法随机抛出各种异常。
• 代码插入：在目标程序中插入一些指令，使得故障注入在这些指令之前先运行。
• 强迫系统节点间的时间彼此不同步。
• 在驱动程序中执行模拟I/O错误的程序。
• 让一个Elasticsearch集群的CPU超负荷。

混沌工程实验的机会是无限的，可能会根据您的分布式系统的架构和您组织的核心业务价值而有所不同。

实施混沌工程的先决条件
要确定您的组织是否已准备好开始采用Chaos Engineering，您需要回答一个问题：您的系统是否能够适应现实世界中的事件，例如服务故障和网络延迟峰值？
如果您知道答案是“否”，您还有一些工作要做。Chaos Engineering非常适合揭露生产系统中未知的弱点，但如果您确定混沌工程实验会导致系统出现严重问题，那么运行该实验就没有任何意义。先解决这个弱点。然后回到Chaos Engineering，它将发现你不了解的其他弱点，或者它会让你更有信心你的系统实际上是有弹性的。混沌工程的另一个基本要素是可用于确定系统当前状态的监控系统。如果不了解系统的行为，您将无法从实验中得出结论。

混沌工程原则
“混乱”一词让我们想起随机性和无序性。然而，这并不意味着混沌工程的实施也是随机和随意的，也不意味着混沌工程师的工作就是引发混乱。相反的是，我们把混沌工程视为一门原则性很强的学科，特别是一门实验性的学科。
在上面的引用中，Dekker观测了分布式系统的整体行为，他也主张从整体上了解复杂系统是如何失效的。我们不应该仅仅着眼于发生故障的组件，而是应该尝试去理解，像组件交互中一些偶发的意外行为，最终是如何导致系统整体滑向一个不安全、不稳定的状态的。
你可以将混沌工程视为一种解决“我们的系统离混乱边缘有多少距离”的经验方法。从另一个角度去思考，“如果我们把混乱注入系统，它会怎么样？”
在这一部分，我们会介绍混沌工程实验的基本设计方法，之后会讨论一些更高级的原则。这些原则建立在真正实施混沌工程的大规模系统之上。在实施混沌工程的过程中，并不是所有高级原则都必须用到。但我们发现，运用的原则越多，你对系统弹性的信心就越充足。
软件系统里并没有类似的传递函数。像很多复杂系统一样，我们无法为软件系统表现出的各种行为建立一个预测模型。如果我们有这样一个模型，可以推导出一次网络延迟骤升会给系统带来什么影响，那就太完美了。但不幸的是，迄今为止我们并没有发现这样一个模型。
因为我们缺乏这样一个理论的预测模型，因此就不得不通过经验方法来了解在不同的情况下我们的系统会如何表现。我们通过在系统上运行各种各样的实验来了解系统的表现。我们尝试给系统制造各种麻烦，看它会发生什么状况。但是，我们肯定不会给系统不同的随机输入。我们在系统分析之后，期望能够最大化每个实验可以获得的信息。正如科学家通过实验来研究自然现象一样，我们也通过实验来揭示系统的行为。
在开发混沌工程实验时，请牢记以下原则：（它们将有助于实验的设计）

1.  建立稳定状态的假设；
2.  用多样的现实世界事件做验证；
3.  在生产环境中进行实验；
4.  自动化实验以持续运行；
5.  最小化爆炸半径；

1. 建立稳定状态假设
任何复杂系统都会有许多可变动的部件、许多信号，以及许多形式的输出。我们需要用一个通用的方式来区分系统行为是在预料之内的，还是在预料之外的。我们可以将系统正常运行时的状态定义为系统的“稳定状态”。
很多现有的数据采集框架已经默认采集大量的系统级别指标，所以通常来说，让你的系统有能力抓取业务级别的指标比抓取系统级别的指标更难。然而花精力来采集业务级别的指标是值得的，因为它们才能真实地反映系统的健康状况。这些指标获取的延迟越低越好：那些在月底算出来的业务指标和系统今天的健康状况毫无关系。
在选择指标时，你需要平衡以下几点：

•  指标和底层架构的关系。
•  收集相关数据需要的工作量。
•  指标和系统接下来的行为之间的时间延迟。

如果你还不能直接获得和业务直接相关的指标，则也可以先暂时利用一些系统指标，比如系统吞吐率、错误率、99%以上的延迟等。你选择的指标和自己的业务关系越强，得到的可以采取可执行策略的信号就越强。你可以把这些指标想象成系统的生命特征指标，如脉搏、血压、体温等。同样重要的是，在客户端验证一个服务产生的警报可以提高整体效率，并可以作为对服务器端指标的补充，以构成某一时刻用户体验的完整画面。

2. 用多样的现实世界事件做验证
每个系统，从简单到复杂，只要运行时间足够长，都会受到不可预测的事件和条件的影响。例如，负载的增加、硬件故障、软件缺陷，以及非法数据（有时称为脏数据）的引入。我们无法穷举所有可能的事件或条件，但常见的有以下几类：
 硬件故障。
 功能缺陷。
 状态转换异常（例如发送方和接收方的状态不一致）。
 网络延迟和分区。
 上行或下行输入的大幅波动以及重试风暴。
 资源耗尽。
 服务之间不正常的或者预料之外的组合调用。
 拜占庭故障（例如性能差或有异常的节点发出有错误的响应、异常的行为、对调用者随机地返回不同的响应等）。
 资源竞争条件。
 下游依赖故障。
也许最复杂的情况是上述事件的各类组合导致系统发生异常行为。

要彻底阻止对可用性的各种威胁是不可能的，但是我们可以尽可能地减轻这些威胁。在决定引入哪些事件的时候，我们应当估算这些事件发生的频率和影响范围，权衡引入它们的成本和复杂度。在Netflix，我们选择关闭节点的一方面原因是，节点中断在现实中发生的频率很高，而引入关闭节点事件的成本和难度很低。对于区域故障来说，即使引入一些事件的成本高昂且引入流程复杂，我们还是必须要做，因为区域性故障对用户的影响是巨大的，除非我们有足够的弹性应对它。

文化因素也是一种成本。例如在传统数据中心的文化中，基础设施和系统的健壮性、稳定性高于一切，所以传统数据中心通常会对变更进行严格的流程控制。这种流程控制，和频繁关闭节点的操作是一对天然的矛盾体。随机关闭节点的实验对传统数据中心的文化是一种挑战。随着服务从数据中心迁移到云上，管理基础设施的职责被转移给了云服务提供商，硬件的各类故障都由云服务平台管理，工程部门对硬件故障就越来越习以为常。这种认知实际上在鼓励一种将故障当作可预料的态度，这种态度可以进一步推动混沌工程的引入和实施。虽然硬件故障并不是导致线上事故最常见的原因，但是注入硬件故障是在组织中引入混沌工程并获益的一个较简单的途径。

和硬件故障一样，一些现实世界的事件也可以被直接注入，例如每台机器的负载增加、通信延迟、网络分区、证书失效、时间偏差、数据膨胀等。除此之外的一些事件的注入可能会具有技术或文化上的障碍，所以我们需要寻找其他方法来看一看它们会如何影响生产环境。[1]例如，发布有缺陷的代码。金丝雀发布可以阻止许多显而易见的简单软件缺陷被大规模发布到生产环境中，但其并不能阻止全部的缺陷被发布出去。故意发布有缺陷的代码风险太大，可能会给用户带来严重的影响（参见第7章）。要模拟这类发布所带来的缺陷问题，一种办法是对相应的服务调用注入异常。

3.在生产环境中进行实验
在我们这个行业里，在生产环境中进行软件验证的想法通常都会被嘲笑。“我们要在生产环境中验证”这句话更像是黑色幽默，它可以被翻译成“我们在发布之前不打算完整地验证这些代码”。
经典测试的一般信条是，寻找软件缺陷要离生产环境越远越好。例如，在单元测试中发现缺陷比在集成测试中发现更好。这里的逻辑是，离生产环境的整个部署越远，就越容易找到缺陷的根本原因并将其彻底修复。如果你曾经分别在单元测试、集成测试和生产环境中调试过问题，上述逻辑的好处就不言而喻了。
但是在混沌工程领域，整个策略却要反过来。在离生产环境越近的地方进行实验越好。理想的实践就是直接在生产环境中进行实验。
在传统的软件测试中，我们是在验证代码逻辑的正确性，是在对函数和方法的行为有良好理解的情况下，写测试来验证它们对不对。换句话说，是在验证代码写得对不对。
而当进行混沌工程的实验时，我们所感兴趣的是整个系统作为一个整体的行为。代码只是整个系统中比较重要的一部分，而除了代码，整个系统还包含很多其他方面，特别是状态、输入，以及第三方系统导致的难以预见的系统行为。
下面来深入了解一下为什么在生产环境中进行实验对混沌工程来说是至关重要的。我们要在生产环境中建立对系统的信心，所以当然需要在生产环境中进行实验。否则，我们就仅仅是在其他并不太关心的环境中建立对系统的信心，这会大大削弱这些实践的价值。
即便你不能在生产环境中进行实验，也要尽可能地在离生产环境最近的环境中进行。越接近生产环境，对实验外部有效性的威胁就越少，对实验结果的信心就越足。

4.自动化实验以持续运行
手动执行一次性的实验是非常好的第一步。当我们想出寻找故障空间的新方法时，经常从手动的方法开始，小心谨慎地处理每一件事以期建立对实验和对系统的信心。所有当事人都聚集在一起，并向CORE（Critical Operations Response Engineering，Netflix的SRE团队的名称）发出一个警示信息，说明一个新的实验即将开始。
这种谨小慎微的态度有利于：a）正确运行实验，b）确保实验有最小的爆炸半径。在成功执行实验后，下一步就是将这个实验自动化，让其持续运行。
如果一个实验不是自动化的，那么就可以将这个实验废弃。

5.最小化爆炸半径
我们经常运行本来只会影响一小部分用户的测试，却由于级联故障无意中影响到了更多的用户。在这些情况下，我们不得不立即中断实验。虽然我们绝不想发生这种情况，但随时遏制和停止实验的能力是必备的，这可以避免造成更大的危机。我们的实验通过很多方法来探寻故障会造成的未知的和不可预见的影响，所以关键在于如何让这些薄弱环节曝光出来而不会因意外造成更大规模的故障。我们称之为“最小化爆炸半径”。
能带来最大信心的实验也是风险最大的，是对所有生产流量都有影响的实验。而混沌工程实验应该只承受可以衡量的风险，并采用递进的方式，进行的每一步实验都在前一步的基础之上。这种递进的方式不断增加我们对系统的信心，而不会对用户造成过多不必要的影响。
最小风险的实验只作用于很少的用户。为此在我们验证客户端功能时只向一小部分终端注入故障。这些实验仅限于影响一小部分用户或一小部分流程。它们不能代表全部生产流量，但却是很好的早期指标。例如，如果一个网站无法通过早期实验，那么就没有必要影响其余的大量真实用户。
在自动化实验成功之后（或者在少量的设备验证没有涵盖要测试的功能时），下一步就是运行小规模的扩散实验。这种实验会影响一小部分用户，因为我们允许这些流量遵循正常的路由规则，所以它们最终会在生产服务器上均匀分布。对于此类实验，你需要用定义好的成功指标[1]来过滤所有被影响的用户，以防实验的影响被生产环境的噪声掩盖。[2]小规模扩散实验的优势在于，它不会触及生产环境的阈值，例如断路器的阈值，这样你便可以验证每一个单一请求的超时和预案。这可以验证系统对瞬时异常的弹性。
接下来是进行小规模的集中实验，通过修改路由策略将所有实验覆盖的用户流量导向特定的节点。在这些节点上会做高度集中的故障、延迟等测试。在这里，我们会允许断路器打开，同时将隐藏的资源限制暴露出来。如果我们发现有无效的预案或者奇怪的锁竞争等情况导致服务中断，那么只有实验覆盖的用户会受到影响。这个实验模拟生产环境中的大规模故障，同时可以把负面影响控制到最小，结果却能使我们对系统建立高度的信心。
风险最大但最准确的实验是无自定义路由的大规模实验。在这个实验级别，实验结果应该在主控制台上显示，同时因为断路器和共享资源的限制，实验可能会影响不在实验覆盖范围内的用户。当然，没有什么比让所有生产环境中的用户都参与实验，能给你更多关于系统可以抵御特定故障场景的确定性了。
除了不断扩大实验范围，在实验造成过多危害时及时终止实验也是必不可少的。有些系统设计会使用降级模式来给用户带来较小的影响，这还好，但是在系统完全中断服务的时候，就应该立即终止实验。这可以由之前讨论过的“大红色按钮”来处理。
我们强烈建议实施自动终止实验，尤其是在定期自动执行实验的情况下。关于弄清楚如何构建一个可以实时监控我们感兴趣的指标，并可以随时实施混沌工程实验的系统，这完全依赖于你手上的独特的系统构造。