混沌工程 - 主动制造故障的艺术
本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →
“需求是发明之母”。同样地，Netflix 不仅是在线媒体流平台，也因其实际需求催生了混沌工程。
2008 年，Netflix 遭遇了严重的数据库损坏事件，导致三天无法配送 DVD。这促使 Netflix 工程师开始思考将单体架构迁移到分布式云架构。
新的分布式架构由数百个微服务组成。迁移解决了单点故障问题，但也引入了新的复杂性，需要构建更可靠、容错的系统。此时，Netflix 工程师提出了一个创新想法：在不影响用户服务的前提下测试系统容错能力。
他们开发了 Chaos Monkey——一个能在不同位置、不同时间间隔制造随机故障的工具。随着 Chaos Monkey 的发展，一门新学科应运而生：混沌工程。
“混沌工程是通过对系统进行实验来建立对系统抵御生产环境中动荡条件能力的信心。” - 混沌原则
混沌工程是一种通过经验探索方法来认知系统行为的实践。正如科学家通过实验研究自然与社会现象，混沌工程通过实验来认知特定系统——包括其可靠性、稳定性及在意外或不稳定条件下的生存能力。
在大型分布式系统中，故障可能由应用失效、基础设施故障、依赖故障、网络中断等多种因素引发。传统方法（如集成测试或单元测试）无法覆盖所有故障场景，这使得混沌工程成为必需：
-
提升系统韧性
-
暴露系统潜在威胁与漏洞
-
在生产环境发生故障前识别系统弱点
许多人认为自身规模远不及 Netflix 等科技巨头，也没有同等量级的数据库或系统。
这种观点或许正确，但随着时间的推移，混沌工程已发展得如此成熟，不再局限于 Netflix 这类数字企业。为确保系统性能稳定与持续可用，越来越多不同行业的公司正在实施混沌实验。
Chaos Mesh
2022-10-24：由于 https://www.oreilly.com/online-learning/leveraging-katacoda-technology.html 政策调整，同时参考 #356，交互式教程暂不可用。
为测试 TiDB 的韧性与可靠性，PingCAP 工程师开发了强大的混沌测试工具 Chaos Mesh。这是一个云原生混沌工程平台，可在 Kubernetes 环境中编排混沌实验。Chaos Mesh 涵盖了分布式系统的各类潜在故障，包括 Pod、网络、系统 I/O 及内核层面。
Chaos Mesh 提供多种故障注入方法：
-
clock-skew: 模拟时钟偏移
-
container-kill: 模拟容器被杀
-
cpu-burn: 模拟 CPU 压力
-
io-attribution-override: 模拟文件属性异常
-
io-fault: 模拟文件系统 I/O 错误
-
io-latency: 模拟文件系统 I/O 延迟
-
kernel-injection: 模拟内核故障
-
memory-burn: 模拟内存压力
-
network-corrupt: 模拟网络数据包损坏
-
network-duplication: 模拟网络数据包重复
-
network-latency: 模拟网络延迟
-
network-loss: 模拟网络丢包
-
network-partition: 模拟网络分区
-
pod-failure: 模拟 Kubernetes Pod 持续不可用
-
pod-kill: 模拟 Kubernetes Pod 被终止
Chaos Mesh 的核心设计理念在于简化混沌测试流程，确保所有实验都能快速执行且易于理解。
最新发布的 1.0 版本 正式推出 Chaos Dashboard，该控制台大幅简化了混沌实验的复杂度。通过几次鼠标点击，您就能在仪表板中定义实验范围、指定故障注入类型、设置调度规则并实时观察实验结果。
若想在浏览器中快速体验 Chaos Mesh，可尝试 Katakoda interactive tutorial，无需部署即可上手实践。要深入了解设计理念和工作原理，请阅读项目维护者 Cwen Yin 撰写的 这篇技术博客。
加入社区
欢迎所有对混沌工程或 Chaos Mesh 感兴趣的朋友加入社区！作为社区成员，我可以自信地说：这里汇聚了热情开放的维护者，他们珍视每位成员的见解和建议，共同推动项目和社区发展。
加入 CNCF Slack 工作区 的 #project-chaos-mesh 频道，即可参与讨论并获取最新资讯。