软件和系统开发是创新和解决未知问题的练习。软件和系统是容易出错的，因为它们是由具有不同观点和技能的人（很可能是多人）制作的。技术变得越来越分散和复杂，尤其是随着微服务的推动。很少有人拥有完整的端到端知识 […]
软件和系统开发是创新和解决未知问题的练习。软件和系统是容易出错的，因为它们是由具有不同观点和技能的人（很可能是多人）制作的。技术变得越来越分散和复杂，尤其是随着微服务的推动。很少有人拥有整个系统的全部端到端知识。
类似于围绕态势感知的军事术语，战争迷雾，在现代发展中理解变化的总体影响可能很困难（发展迷雾）。再加上用户对系统始终可用的期望，测试系统的稳健性和对未知数的弹性可能只是：一个未知数。
混沌工程通过在整个应用程序和基础架构堆栈中注入故障，然后允许工程师验证行为并进行调整，从而使故障不会向用户显现，从而帮助解决未知问题。再加上站点可靠性工程实践的兴起，混沌工程试图计算不可能的影响。
混沌史
站点可靠性工程师的热门读物是 Nicholas Taleb 的《黑天鹅：极不可能的影响》（2007 年）。塔勒布在他的作品中介绍了黑天鹅的隐喻。塔勒布将黑天鹅事件分类，例如突然的自然灾害或在出版他的书时的商业活动，谷歌取得了惊人的空前成功。黑天鹅事件具有三个特征：不可预测，影响巨大，当它结束时，我们会设计一种解释，让黑天鹅看起来不那么随机。
在处理发展的迷雾时，我们很容易陷入分布式计算的谬误，这是计算机科学家 Peter Deutsch 提出的一组关键断言。一些主要的谬误是：网络可靠，延迟为零，带宽无限，并且只有一名管理员。消除谬误，您的服务将始终如一，并且随时可用。正如我们所知，系统和服务总是会起起落落——但是当涉及到开发未知的细节时，我们很容易忘记这一点。
例如，假设我们正在构建一些依赖 Amazon S3 进行对象存储的功能。如果我们正在为执行复杂处理的服务构建功能并且最终输出是在 S3 中写入或更新对象，我们作为工程师可能会假设 S3 将在那里。我们上下测试我们的功能，并为 S3 部分提供不太复杂的测试覆盖率。亚马逊网络服务在 2017 年发生了自己的黑天鹅事件，当时 S3 遭遇中断。我们认为会存在的东西（即使性能/写入 SLA 降低）也没有，分布式计算的谬误又回来咬我们。
S3 中断确实有助于确保我们接触到堆栈的所有部分，即使我们接触的部分看起来并不明显，这可能是由于我们对分布式计算的谬误的看法/迷雾。混沌工程和混沌实验带来了可控的混沌，因此我们可以摆脱这些类型的事件。
什么是混沌工程？
混沌工程是故意将故障注入系统以衡量弹性的科学。与任何科学方法一样，混沌工程专注于实验/假设，然后将结果与对照（稳态）进行比较。分布式系统中典型的混沌工程示例是关闭随机服务，以查看项目如何响应以及对用户旅程的损害表现在哪些方面。
如果您对应用程序需要运行的内容（计算、存储、网络和应用程序基础设施）进行横截面分析，则将故障或动荡条件注入该堆栈的任何部分都是有效的混沌工程实验。网络饱和或存储突然变得不稳定/满负荷是技术行业已知的故障，但混沌工程允许对这些故障进行更可控的测试，等等。由于可能会影响广泛的基础设施，混沌工程的用户和从业者几乎可以是支持应用程序/基础设施堆栈的任何人。
谁使用混沌工程？
由于混沌工程涉及广泛的技术和决策，混沌工程实验可能有多个利益相关者。爆炸半径越大（受测试和实验影响的范围），参与的利益相关者就越多。
根据应用程序堆栈的领域（计算、网络、存储和应用程序基础架构）以及目标基础架构所在的位置，这些团队的利益相关者可以参与其中。
如果爆炸半径很小并且可以在运行的容器中进行测试，那么应用程序开发团队可以进行测试，而不必担心突破容器。如果工作负载或基础设施的影响范围更广（例如，测试 Kubernetes 基础设施），平台工程团队很可能会参与其中。为未知提供覆盖是运行 Chaos 测试和寻找弱点的核心原因。
为什么要进行混沌测试？
开发的迷雾是非常真实的，尤其是对于更大的分布式系统、复杂系统和微服务实现。从应用程序的角度来看，每个单独的微服务都可以单独测试并确定按设计工作。正常的监控技术可以认为单个服务是健康的。
使用微服务模式，单个请求可以遍历多个服务以获得聚合响应来满足用户或其他服务的请求。服务之间的每个远程请求都在遍历额外的基础设施并跨越不同的应用程序边界，所有这些都可能失败。
如果一项琐碎或非琐碎的服务或基础设施在服务水平协议 (SLA) 范围内没有响应，系统的功能和用户旅程将受到怎样的影响？这正是混沌工程正在解决的问题。混沌工程实验的结果随后被用于创建一个更具弹性的系统。
混沌工程原理
《混沌工程原理》是一篇出色的宣言，描述了混沌工程的主要目标和原则。混沌工程原理进一步分解了四种类似于科学方法的实践。但是，与科学方法不同的是，假设系统是稳定的，然后寻找方差。越难中断稳态，系统的信心和稳健性就越高。
从定义基线开始（稳态）
了解什么是正常/稳定对于检测偏差/回归至关重要。根据您要测试的内容，拥有一个良好的指标，例如响应时间或更高级别的目标，例如在特定时间内完成用户旅程的能力，是衡量正常性的良好指标。实验中的稳态是对照组。
假设稳态将持续
与科学方法背道而驰，假设一个假设一直都是真的不会留下太多的余地。混沌工程旨在针对强大而稳定的系统运行，试图找出应用程序故障或基础设施故障等故障。对不稳定的系统运行混沌工程并没有提供太多价值，因为这些系统已经不可靠并且不稳定性是已知的。
引入变量/实验
与任何科学实验一样，混沌工程在实验中引入变量以查看系统如何响应。这些实验代表了影响应用程序四大支柱中的一个或多个的真实故障场景：计算、网络、存储和应用程序基础设施。例如，故障可能是硬件故障或网络中断。
尝试反驳假设
如果假设是针对稳态的，则稳态的任何方差或中断（对照组和实验组之间的差异）都反驳了稳定性假设。现在有了一个可以关注的领域，可以进行修复或设计更改，以使系统更加健壮和稳定。
在实施混沌工程实验时，实施混沌工程的原则会导致一些设计注意事项和最佳实践。
混沌工程最佳实践
在实施混沌工程或任何测试时，有三个支柱。第一个是提供足够的覆盖范围，第二个是确保经常运行实验并在生产中模拟/运行，第三个是最小化爆炸半径。
为估计的故障频率/影响提供覆盖范围
在软件中，您永远不会达到 100% 的测试覆盖率。建立覆盖需要时间，而考虑每个特定场景是一个白日梦。覆盖范围致力于使最有影响力的测试。在混沌工程中，这将测试会产生严重影响的项目，例如存储不可用或可能发生很多的项目，例如网络饱和或网络故障。
在您的管道中连续运行实验
软件、系统和基础设施确实会发生变化——每个人的状况/健康状况都可能会迅速发生变化。运行实验的好地方是在 CI/CD 管道中。CI/CD 管道在进行更改时执行。衡量变革的潜在影响的最佳时机莫过于变革开始在管道中建立信心的旅程。
在生产中运行实验
正如在生产中进行测试的可怕想法一样，生产是用户所处的环境，流量峰值/负载是真实的。为了全面测试生产系统的稳健性/弹性，在生产环境中运行混沌工程实验将提供所需的见解。
最小化爆炸半径
因为你不能以科学的名义降低生产，所以限制混沌工程实验的爆炸半径是一种负责任的做法。专注于小实验，这些实验会告诉你你想要识别什么。专注于范围和测试。例如，两个特定服务之间的网络延迟。比赛日计划可以帮助计算爆炸半径和重点。
有了这些最佳实践，混沌工程是一门不同于负载测试的学科。
混沌工程和负载测试有什么区别？
当然，负载本身会带来混乱。我们通常将我们的系统设计为在多个部分中具有弹性（启动额外的计算、网络、持久性和/或应用程序节点以应对负载）。那是假设一切都在同一/适当的时间出现，因此我们可以领先于负载。
在计算机科学领域，Thundering Herd 问题（惊群问题)并不新鲜，但随着我们向更加分布式的架构迈进，它会更加普遍地表现出来。例如，Thundering Herd 问题可能在机器级别，因为大量进程被启动，另一个进程成为瓶颈（处理一个且仅一个新进程的能力）。在分布式架构中，Thundering Herd 可能是您的消息系统能够一次摄取大量消息/事件，但处理/持久化这些消息可能会成为瓶颈。如果您收到消息过多，您好 Thundering Herd。
负载测试肯定会帮助我们为雷鸣群做准备，这是一种压力，但是如果系统的一部分甚至不存在，或者游戏迟到了怎么办？这就是混沌工程的用武之地。如果没有混沌工程，一个非常难以测试的项目将是级联故障。历史上更等同于电网，级联故障是一个部分的故障可以触发其他部分的故障。在分布式系统领域，这是我们试图找到单点故障并确保我们的应用程序/基础设施足够健壮以处理故障。
今天，不乏工具和平台来帮助您实现混沌工程目标。
混沌工程工具
围绕混沌工程有很多进步和工具。很棒的资源列表是 Awesome Chaos Engineering 列表。此列表向构建 Chaos Engineering 的混沌测试工具致敬，向使 Chaos Engineering 更易于使用的新平台致敬。
混沌猴（Chaos Monkey）
Chaos Monkey 被公认为最早的混沌工程工具之一，由 Netflix 开发。最初的 Chaos Monkey 会随机禁用生产实例。最终，混沌猴成为了猿猴军团（Simian Army）的一员。尽管今天 Chaos Monkey 是一个独立的项目。
四面军(The Simian Army)
受原始 Chaos Monkey 成功的启发，Simian Army 是一系列工具（例如 Janitor Monkey、Latency Monkey、Security Monkey 和 Doctor Monkey），专注于引入不同类型的故障。今天，四面军退役了。
Gremlin 平台（Gremlin Platform）
Gremlin 是最早的 SaaS 混沌工程平台之一。Gremlin 能够协调和测量打包在 SaaS 平台中的混沌工程实验。如果这是您第一次涉足混沌工程，Gremlin 提供了很多很棒的资源。
AWS 故障注入模拟器（AWS Fault Injection Simulator）
最近专注于 AWS 服务，AWS 提供了故障注入模拟器。如果您完全使用 AWS 平台并希望将混沌工程实验引入您的 AWS 环境，AWS FIS 是一个不错的选择。了解有关故障注入测试及其优势的更多信息。
无论您选择哪种工具，您的 CI/CD 管道都是运行和编排混沌工程实验的好地方。
试验您的 CI/CD 管道
随着在系统中建立信心的新方法开始受到关注，CI/CD 管道是协调建立信心步骤的好地方。混沌工程实验非常适合在 CI/CD 管道中运行。最近，Harness 和 Gremlin 创建了一个演示，展示了 CI/CD 管道和 Gremlin Experiments 之间的集成。
可能的艺术是让混沌工程实验的结果影响部署，或者如果部署到较低的环境，让 Harness 作为混沌工程实验和其他自动化测试的协调器。如需完整示例，请前往 Harness 社区了解更多信息。
线束（Harness ）在这里提供帮助
Harness 软件交付平台是一个非常强大的平台，专门用于协调建立信任的步骤。就像在任何实验中一样，混沌工程的一个支柱是有一个基线。想象一下，您是一个团队的新手，例如 SRE 团队，该团队涵盖了数十个不是您自己编写的应用程序。首次运行混沌工程测试将需要隔离或启动应用程序和相关基础设施的新发行版，以进行试验，而不会对生产产生影响。
如果您的应用程序不是通过强大的管道部署的，那么创建另一个隔离部署可能与正常部署应用程序的正常潮起潮落一样痛苦。沿着混沌工程成熟之旅前进，因为混沌工程测试被视为强制覆盖，按照惯例，将它们集成到用于判断调用或故障策略的 Harness 工作流中很简单。
