想象一下，现在是 2000 年代初，你是一位有着大胆想法的开发者。你想在生产环境中测试你的软件，而不是在安全、受控的环境中。这是真实用户与你的系统交互的地方。在当时，提出这样的事情可能会让你的老板用奇怪的眼神看你。但现在，在真实世界测试不仅是可接受的；它通常是被推荐的。
为什么会有这么大的变化？有几个原因很突出。今天的系统比以往任何时候都更复杂，推动我们更快地创新，确保我们的服务既可靠又强大。云技术、微服务和分布式系统的兴起改变了游戏规则。我们不得不相应地调整我们的方法和心态。
我们现在的目标是让系统能够处理任何事情——无论是减速还是全面停机。这就是混沌工程的用武之地。
在本期文章中，我们将深入探讨混沌工程的本质。我们将分解其关键原则、如何实践，以及来自真实世界的例子。你将了解如何引起一点受控的混沌，实际上有助于在弱点成为重大问题之前发现和修复它们。
准备看看拥抱混沌如何导致更强大、更可靠的系统。让我们开始吧！
什么是混沌工程？
那么，混沌工程到底是什么？这是一种应对软件开发中意外问题并保持系统运行的方法。有些人可能认为运行应用的服务器将永远顺利运行。其他人认为问题只是交易的一部分，停机是不可避免的。
混沌工程在这些观点之间取得平衡。它认识到事情可能出错，但断言我们可以采取措施防止这些问题影响我们的系统和应用性能。
这种方法涉及在我们的实时生产系统上进行实验，以识别弱点和可靠性不如应有的地方。这是关于衡量我们对系统弹性的信任程度，并努力提升这种信心。
然而，重要的是要理解，100% 确定不会出问题是不现实的。通过混沌工程，我们有意引入意外事件来发现漏洞。这些事件可能各不相同，例如随机关闭服务器、破坏数据中心，或篡改负载均衡器和应用副本。
简而言之，混沌工程是关于设计严格测试系统稳健性的实验。
有很多方式可以描述混沌工程，但这里有一个很好地捕捉其本质的定义，来源于 https://principlesofchaos.org/。
“混沌工程是在系统上进行实验以建立系统在生产中承受湍流条件能力的学科。”
这个定义强调了混沌工程的核心目标：确保我们的系统能够处理现实世界操作的不可预测性。
混沌工程 vs. 性能工程
当我们谈论确保系统顺利运行时，经常出现两个概念：性能工程和混沌工程。让我们讨论一下它们的区别以及它们如何重叠。
许多开发人员已经熟悉性能工程，它与 DevOps 同属一族。它涉及使用工具、过程和技术的组合来监控我们系统的性能并持续改进。这包括进行各种类型的测试，如负载、压力和耐久性测试，都旨在提高我们应用的性能。
另一方面，混沌工程是有意破坏东西。是的，这包括压力测试，但它更多的是观察系统在意外压力下的反应。压力测试可以被视为混沌实验的一种形式。所以，一种看待它的方式是将性能工程视为混沌工程的子集，反之亦然，取决于你如何应用这些实践。
另一种看待这两者的方式是作为组织内的不同学科。一个团队可能只专注于进行混沌实验并从失败中学习，而另一个团队可能沉浸在性能工程任务中，如测试和监控。根据组织结构、团队技能和其他各种因素，我们可能有单独的团队负责每个学科，或一个团队同时处理两者。
让我们考虑一个例子来更好地理解混沌工程。想象我们有一个系统，其中负载均衡器将请求定向到 Web 服务器。这些服务器然后连接到支付服务，支付服务又与第三方 API 和缓存服务交互，都位于可用区 A。如果支付服务无法与第三方 API 或缓存通信，请求需要重新路由到可用区 B 以维持高可用性。
本文为学习目的的个人翻译，译文仅供参考。
原文链接：Embracing Chaos to Improve System Resilience: Chaos Engineering。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。