gremlin: What is Chaos Engineering?
什么是混沌工程？
混沌工程让您可以将您认为会发生的事情与系统中实际发生的事情进行比较。 您实际上是“故意破坏”以学习如何构建更具弹性的系统。
通过主动测试系统在压力下的响应方式，我们可以在故障出现之前识别并修复故障。 最终，混沌工程的目标是增强我们系统的稳定性和弹性。
混沌与可靠性工程技术作为构建可靠应用程序的基本学科正迅速获得关注。 在过去的几年里，许多组织——无论大小——都接受了混沌工程。
创建可靠的软件是现代云应用程序和架构的基本必要条件。 随着我们迁移到云或将我们的系统重新架构为云原生，我们的系统正在按设计分布，并且出现计划外故障和意外中断的可能性显着增加。 此外，转向 DevOps 会使可靠性测试更加复杂。
DevOps 抛弃了传统的可靠性测试
像 QA 和其他测试学科的出现是为了应对不断出现的问题并需要一种新的测试方法。
例如，单元测试验证我们编写的一些代码是否符合预期。集成测试验证我们编写的代码可以很好地与代码库的其余部分配合使用。有时我们会进行系统测试，试图验证整个系统是否符合设计规范。传统上，开发团队会传递他们的代码进行测试，以验证它是否按预期工作或发现需要修复的问题。
在这一点上，代码将被扔到一个运营团队的墙外，他们的工作是让代码在生产环境中运行。运维负责让东西运行起来，并且由于每个组织环境的独特性，各个运维团队都会提出自己的战略和计划。
DevOps 将开发和运营团队合并在一起，让他们共同承担生产准备和部署的责任。敏捷和 DevOps 软件流程将我们的开发和部署速度提高了几个数量级，因此我们可以更快地将产品和功能提供给客户。
但是，越快的代码被创建并检入到 master 中，QA 就越频繁地编写测试并且需要更多的测试。速度越快，偶尔出现错误的可能性就会越大。为了跟上步伐，测试已尽可能自动化。
此外，随着我们转向微服务和其他分布式、基于云的架构。这些分布式系统具有紧急行为，通过扩大和缩小规模来响应各种生产条件，以确保应用程序能够为不断增长的客户需求提供无缝体验。换句话说，这些系统从不遵循相同的路径来获得客户体验。紧急行为也意味着紧急失败。分布式系统会失败，但它们不太可能以同样的方式失败两次。
我们之前对测试的理解并不能解释当今独特且不断变化的生产环境。 DevOps 的 Ops 方面尽最大努力使事情顺利进行，但他们的任务通常只涉及将代码投入生产并希望获得最佳效果或回滚更改或在发生故障时进行修补程序。他们自动化了一些测试，但通常不会运行会发现由生产中的动荡条件引起的系统故障的测试。
传统的 QA 已经不够用了
DevOps 中缺少一些东西：混沌工程是您一直在寻找的测试方法。
传统的质量保证仅涵盖我们软件堆栈的应用层。 再多的传统 QA 测试或其他传统测试都无法验证我们的应用程序、其各种服务或整个系统是否会在任何条件下可靠地响应，无论是“按设计工作”还是在极端负载和异常情况下。
任何软件堆栈或应用程序层的故障都可能破坏客户体验。 传统的 QA 测试方法不会在这些潜在问题条件实际发生之前发现它们。
此外，大多数传统的 QA 活动都被其他团队吸收了。 许多测试现在由 CI/CD 管道自动化，并由 SRE 或 DevOps 团队监督。 发现和解决问题的责任已成为服务所有者的责任。 除此之外，不可否认的事实是，不可能建立准确模仿生产环境的测试和登台环境。
混沌工程如何帮助测试发展？
- 验证
- 更广泛的软件和基础设施场景
- 发现问题
- 传统测试无法暴露
- 安全地进行
- 并在生产中有效
- 帮助团队了解
- 系统在现实世界中的行为方式，而不仅仅是它们如何破坏或它们有什么错误
由于混沌工程可以在运行时测试代码质量，并且具有自动化和手动测试形式的潜力，因此该学科成为新质量评估工具箱中的强大工具。
早些时候我们解释了分布式系统是如何不断变化的，这意味着它们永远不会以相同的方式崩溃两次，但它们会崩溃。 Chaos Engineering 允许工程师在安全和受控的环境中模拟他们的系统如何响应故障，从而帮助企业防范这些故障。
我们使用混沌实验来模拟我们知道有可能导致问题的金丝雀实例上的事物，例如网络延迟。新服务在轻量级测试下是否有效？中等的？重的？我们努力推动新实例。在生产中。我们逐渐建立起来，甚至测试超出了我们期望的工作点。我们学到了东西。我们经常学到的东西会创造机会在下一次构建中进一步完善我们的工作。这在生产中是安全的，因为服务的其他实例正在处理客户需求；甚至没有人能说我们正在做混沌工程。
混沌工程是在当今复杂的现实中发现系统性问题的唯一方法，无论我们是否使用金丝雀部署。当网络延迟增加两微秒时，我们的 REST API 驱动的库存服务将如何表现？当大量延迟的请求全部并发到微服务时会发生什么？我们怎么知道？我们对其进行测试。
混沌工程入门
我们首先设计了一个小型混沌实验，其规模远小于我们认为可能造成麻烦的规模。接下来，我们限制爆炸半径和真正的潜在危害，以便在进行混沌测试时保证系统和数据的安全。然后，我们运行实验，完成后，我们仔细检查我们的监控和可观察性以及其他系统数据，看看我们学到了什么。
我们的混沌实验影响了什么？这些数据决定了我们如何优先考虑我们的工作，在我们发现的小问题变成大问题之前减轻它们（并且肯定会减轻我们立即发现的任何大问题！）。然后我们通过再次运行相同的混沌实验来跟进我们的工作，以确认我们的工作是有效的。
反复这样做，从小处着手，每次都修复我们发现的东西，很快就会加起来。我们的系统在处理我们无法控制或阻止的现实世界事件方面变得越来越好，例如当我们的云提供商发生意外中断时。
“哦，不！我们在 us-east-2 中的 Amazon S3 存储桶刚刚坏了？”不用担心，我们已经预料到了这一点，并且从客户的角度来看，我们的系统仍然表现良好。也许我们已经在 us-west-1 中进行了故障转移备份，并设计了我们的系统，以便在性能下降到一定水平时进行切换，而客户会注意到。
无论我们的解决方案是什么，我们都设计了它，我们实现了它，然后我们用混沌工程对其进行了测试。结果，当发生我们无法控制的生产故障时，它按预期工作，更重要的是，我们的客户甚至都不知道它发生了。
本文：https://architect.pub/gremlin-what-chaos-engineering
