企业必须主动以受控的方式破坏自己的系统，以防止灾难性故障。这种做法被称为混沌工程，在云原生应用的复杂世界中正变得越来越重要。
这是软件交付平台 Harness 高级软件工程师 Sayan Mondal 的观点，他指出开发者、站点可靠性工程师 (SRE) 和 IT 运维团队必须适应混沌。
在本周香港举行的 KubeCon + CloudNativeCon China 2025 大会上发言时，同时也是云原生计算基金会 (CNCF) 孵化项目 LitmusChaos 维护者和社区经理的 Mondal 解释了如何通过故意向系统注入故障来帮助增强它们对中断的抵御能力。
"现在到处都是云原生和分布式系统，存在很多相互依赖的故障点，" 他说。"云服务提供商实际上并非 100% 可靠，因为你可能遇到设备故障、电源中断和内存泄漏。"
此类中断造成的财务和声誉损失可能代价高昂。Mondal 举例称，一家金融公司因单一基础设施问题导致无法处理交易而损失超过 5500 万美元，以及 Slack 因 "大量日志记录" 导致的中断，使数千家企业的协作服务瘫痪。
他说，传统测试只是浅尝辄止，通常只涉及应用层。
"我们很少测试基础设施或底层平台服务，" Mondal 说。"混沌工程专门专注于触及底层。"
**应用程序的火灾演练**
Mondal 将混沌工程描述为 "在交付周期开始时进行的火灾演练，这样当实际事件发生时，你会更加准备充分"。它包括规划和模拟故障；使用不同类型的故障来识别漏洞；以及了解系统如何故障，以便组织能够构建更具弹性的系统。
对于想知道从哪里开始的 DevOps 和 IT 团队，Mondal 说他们不必从破坏生产系统开始。这个旅程可以在本地环境中使用 K3s 和 Minikube 等工具安全开始，然后转移到暂存和预生产环境，只有在团队感到舒适后才进入生产环境。
他介绍了 LitmusChaos 作为一个开源、跨云框架，提供 "最基本的开源混沌工具"，可以与其他用于监控和多租户的插件配对使用。拥有超过 200 万次安装，它为故障注入、实验管理和可观测性提供了丰富的功能集。
LitmusChaos 的核心建立在三个自定义资源定义 (CRD) 上：
ChaosExperiment：故障的蓝图，定义你要注入的内容。
ChaosEngine：用户定义的实验调优，定义你如何运行它，包括持续时间和特定参数。
ChaosResult：实验的输出，详细说明发生了什么以及学到了什么。
在演示过程中，Mondal 使用 LitmusChaos 针对示例电商应用程序的产品目录微服务。通过运行 "pod-delete" 故障，他展示了应用程序的产品列表如何消失，然后 Kubernetes 通过其自身的弹性机制如何使服务重新上线。这个简单的实验展示了团队如何验证其服务的弹性并了解它们在压力下的行为。
**组织混沌**
至于混沌工程团队通常在组织中的位置，Mondal 告诉 Computer Weekly，这通常是一个共同责任，由最接近系统可靠性的人员领导。
"主要来说，我们看到 SRE 是在做这件事的人，大多在首席级别，" 他指出，并补充说他的团队还包括运维和首席工程师。
然而，目标是将这种实践扩展到开发者。"在我的团队中，我们将其放入 CI [持续集成] 流水线。每当我们发布时，我们会自动注入混沌步骤作为发布过程的一部分，" Mondal 说，并补充说这种左移方法使开发者能够在发布代码时测试弹性。
这种开发者主导的测试由更大规模、更结构化的事件补充。"运维团队和 SRE 也会进行 'game-day' 事件，" 他说，并补充说这可以每季度进行一次，以应对更复杂的故障场景。
Mondal 补充说，将持续混沌测试与定期 game day 相结合有助于创建可靠性文化。
