为你的服务打个疫苗 —— 混沌工程

魏小言

云原生领域优质创作者

博客专家认证

2022-05-17 17:07:04

初识混沌工程

混沌工程可以为我们做什么？

混沌工程是故障测试吗？

混沌工程原则

可量化的稳定状态

反映真实世界但风险未知的假设

自动化的生产环境实战

影响最小化

如何实施混沌工程

设计实验

执行实验

故障观察

开源项目

混沌工程
未知，既然避不开，为何不拥抱它？

在实际生产环境中，各种无法预知的事件难以避免，风险隐患无处不在。分布式系统架构的复杂性、海量数据的计算与存储、跨团队协同等，这些都在向系统的稳定性发起挑战。系统不确定性风险的加剧，最终将会波及到我们业务的连续性。

你是否想过：如果整个区域或数据中心出现故障、服务出现访问延迟、系统时钟不同步等这些问题发生，将会带来怎样的后果？其中有些结果我们可以预知，但更多可能在意料之外。这时候，你可以阅读这篇文章了解——“混沌工程”。

初识混沌工程
混沌工程（Chaos Engineering）是通过主动向系统中引入软件或硬件的异常状态（扰动），制造故障场景，并根据系统在各种压力下的行为表现，确定优化策略的一种系统性稳定性保障手段。

Netflix 前云架构师 Adrian Cockcroft，在 2018 年关于混沌工程的演讲中，提出了关于混沌工程的更精确的定义：“混沌工程是一种确保减轻故障影响的实验”。也有人将混沌工程比作疫苗，通过 “接种疫苗” 的方式，让系统具备抵挡 “重大疾病” 的能力。

2010 年底，Netflix 向全世界推出 Chaos Monkey ，其主要功能是随机终止在生产环境中运行的虚拟机实例和容器，模拟系统基础设施遭到破坏的场景，使得工程师能够观察服务是否健壮、有弹性，能否容忍计划外的故障。这就是混沌工程的早期雏形。

混沌工程可以为我们做什么？
应用场景   价值
容灾能力测试   通过注入故障，验证个别组件发生故障时不会影响整个系统，以及限流降级、熔断、主备切换、故障迁移等容灾手段的有效性。
微服务强弱依赖治理   非核心服务不能拖垮主服务。在给被调服务注入和去除故障过程中，观察主调服务的指标表现，可以直观便捷地获得依赖强弱关系，对不符合预期的依赖关系做进一步优化。
验证容器编排配置   通过模拟删除服务Pod和节点、增加Pod资源负载，观察系统服务可用配置性，验证副本配置、资源限制配置等是否合理。
监控警告   验证监控指标是否准确、监控维度是否完美、告警阈值是否合理、告警是否快速、告警接收人是否正确、通知渠道是否可用等。
应急演练   通过红蓝对抗等真是故障场景下的演练，考验相关人员的问题应急能力、应急效率，以战养战，丰富团队经验，增强团队信心。
混沌工程是故障测试吗？
混沌工程，与故障注入、故障测试等测试方法，有本质上的区别。混沌工程是一种生成新信息的实践，而故障注入是测试已知属性的方法。

在传统测试里，我们可以写一个断言，给定特定的条件，产生一个特定的输出，如果不满足断言条件，就说明测试出错，它不能产出一些让我们始料未及的 “惊喜”。

而混沌工程是探索更多未知场景的实验，实验会有怎样的新信息生成，我们是不确定的。

混沌工程原则
以下原则描述了应用混沌工程的理想方式：

可量化的稳定状态
实施混沌工程，首先要了解系统在正常状态下的行为。因为，在人为注入故障后，不仅要评估故障注入对系统造成的影响，还要确保系统能够恢复到这个稳定状态。

因此，需要收集一些可测量的指标，来实现系统稳定状态的可观测性。而业务指标相比系统指标（如 CPU 负载、内存使用率等），更能反映系统的健康状态以及用户满意度。

反映真实世界但风险未知的假设
在真实业务场景中，遇到的任何故障都是混沌实验的潜在变量。目前业界已经有了按照 IaaS 层、PaaS 层、SaaS 层划分的故障画像（如下图）。除了对这些已出现的问题进行分类、优先级排序外，也要对未来可能会出现的新问题保持关注。

同时，践行混沌工程要以接受不确定性为思想前提，即把重点放在发现未知的风险并进行改进，而非做出对实验输入和输出有明确预期的假设。

但是，在决定引入哪些事件时，也需要估算事件发生的概率和最终影响范围，推算造成的成本和复杂度等。

自动化的生产环境实战
————————————————
版权声明：本文为CSDN博主「魏小言」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_34417408/article/details/124824345

...全文