混沌工程初探

1、混沌工程的定义：混沌工程是一门新兴的技术学科，它的初衷是通过实验性的方法，让人们建立复杂分布式系统能够在生产中抵御突发事件能力的信心。——《Principles of Chaos Engineering》
可以理解成：一种类似于【疫苗】保护人体的方法

混沌工程和测试的区别：
常规测试：测试场景和结果已知
混沌工程：验证尚未明确结果的场景

混沌工程的来源：
08年Netflix决定把它的业务迁移到AWS上，从自身运维的角度考虑，它有很多担忧的地方：
很长时间内有两套系统在同时运行，运维的复杂度更高了
Netflix的用户量已经达到1亿，对应用稳定性依赖很高，如果出现故障对用户的影响非常大，甚至是致命的
业务不断复杂，引入微服务架构，对应用的高可用性要求越来越高
生产环境非常复杂，是多样性的，很难在测试环境中完全模拟生产的状况
Netflix决心探索一种在生产环境验证应用高可用性的一种方法，这就是现在大家所熟知的混沌工程

混沌工程核心思想：通过主动在生产环境或非生产环境下引入故障因子，验证系统应对故障的能力

混沌工程的五大原则：
建立稳定状态的假设、多样化地引入真实事件、在生产环境中进行实验、持续运行自动化实验、最小化爆炸半径

最小化爆炸半径 Minimize Blast Radius：在生产环境中进行实验可能会引发真实的故障发生，所以在执行试验时需要确保影响范围最小且可控
稳态假说 Build a Hypothesis around Steady State Behavior：建立一个围绕稳定状态行为的假说；关注可测量输出，而不是系统内部属性；短时间内的度量结果代表了系统的稳定状态；验证系统是否工作，而不是如何工作
真实事件 Vary Real-world Events：通过潜在影响或预估频率确定事件的优先级；任何能够破坏稳态的事件都是混沌实验的一个潜在变量
生产环境 Run Experiments in Production：系统的行为会根据环境和流量模式而变化；为了保证系统行为的真实性与当前部署系统的相关性，混沌工程强烈推荐在生产环境中进行实验
自动运行试验 Automate Experiments to Run Continuously：手工运行实验是不可持续的工作，所以需要把实验变为自动化且持续的执行

2、如何进行混沌测试
确定系统脆弱点：分析历史事件，直接拿产线事件是最短平快的
确定稳态指标：确定一个能代表系统稳定运行的关键指标，能直接反应出业务成功率，提出故障风险假设、设计实验场景、配置实验环境
确定可观测的其他指标：如用户并发数、平均每秒交易率、平均响应实际，用来评估故障对系统的其他影响
混沌工程实验：先保证系统正常收集稳态指标，然后注入故障并实施监控指标变化。若实验爆炸半径超出预期，则进行实验调整，根据指标的波动随时调整参数。然后中止故障，进行恢复性验证，观察中止故障后，系统能否恢复正常。
分析实验结果，探索稳定性改进措施

3、常见注入故障类型：

4、混沌工程体系化建设目标

5、利用混沌工程避免微服务的级联故障
微服务架构面临的挑战：微服务指数级增长，服务间关联关系庞杂且趋向于动态化，导致微服务的级联故障频发。级联故障指的是因依赖关系引发的局部故障导致整个系统崩溃（俗称蝴蝶效应）
涉及范围：转移切换、重试退避、超时机制、幂等操作、服务降级、拒绝服务、服务熔断

实验一：验证微服务熔断机制
实验准备：
针对用户服务配置慢调用熔断机制
对用户服务注入Cpu高负荷故障
模拟并发用户登录
实验假设：由于用户服务的Cpu负荷高，处理变慢后触发用户服务熔断

6、组件测试需结合业务需要进行，如redis故障场景：
磁盘空间填充可能会导致缓存备份失败
集群节点网络异常客户端访问超时
IO读写负荷高导致读写变慢，访问超时
内存不足可能导致redis无法写入
cpu高负荷可能导致RT大幅增加

关注指标：
内存使用率used_memory
命令处理数total_commands_processed
延迟时间latency
QPS
RT，错误率

如针对kafka故障注入：

如针对es故障注入：

7、问题1：“一个混沌实验的‘成功’是如何定义的？”
参考答案：
一个混沌实验的“成功”，绝对不是“故障没有发生”或者“系统没出问题”。它的成功定义是：
1）核心是验证稳态假说（Steady State Hypothesis）：
我们在实验前会定义一个“系统正常工作”的指标，比如：
交易成功率 ≥ 99.99%
P99响应时延 ≤ 200ms
数据库主从同步延迟 ≤ 1秒

实验成功的标准：在整个故障注入过程中，上述稳态指标始终没有被破坏。这意味着系统的冗余设计、限流降级、自动重试、熔断机制等韧性能力确实生效了。

2）成功的第二种情况：发现了“已知的未知”：
如果实验导致稳态指标被破坏了，这次实验依然是成功的——因为“成功”地发现了系统的弱点（例如某个服务没有配置超时、某个缓存穿透了、某个数据库连接池太小）。
此时“成功”意味着：我们获得了一个可复现的、有证据的漏洞，然后会推动研发团队修复它，并再次实验直到通过。

3）银行场景的特殊性：
在银行，一个实验成功还意味着：所有操作都在预设的爆炸半径内，没有影响到真实客户或生产环境，并且所有的注入和恢复步骤都是可审计、可回滚的。

8、核心理念：
稳态假说：定义一个“系统正常工作”的指标（如交易成功率、响应时延），实验过程中持续观测该指标是否被打破
最小爆炸半径：严格控制故障的影响范围，有控制的实验

• 选定业务场景（如：登录、转账、查询账户余额）。
• 定义稳态指标（如：转账成功率≥99.99%，P99≤500ms）。
• 确定爆炸半径（如：仅影响集群中5%的Pod）。

关键工具：

9、问题2：“如何在生产环境附近安全地进行实验？”
参考答案：
在生产环境附近（银行常称为“准生产环境”或“预发环境”）做混沌工程，核心是将风险控制到极致。我会从以下几个层面来保证安全：
1)强制环境隔离（物理/逻辑）：
优先选择独立的混沌演练环境，该环境与生产环境共用配置和数据模型，但流量是测试流量或脱敏流量。
如果不得不在生产环境做（比如验证真实容灾切换），会严格限定在特定的、标记为“可演练”的节点或服务实例上，例如只对1台后端服务器注入故障，而不是整个集群。

2)爆炸半径控制的技术手段：
节点打标签：在服务注册中心（如Nacos、Consul）或Kubernetes中，给允许注入故障的节点打上chaos-enabled=true标签。故障注入工具只针对这些节点生效。
流量染色：只对携带特定请求头（如x-chaos-test: true）的流量注入故障，正常用户流量不受影响。
按比例注入：比如只影响1%的请求或只影响1个Pod，而不是全量。

3)自动熔断与回滚机制：
设置实验执行的最大时长（如5分钟），超时自动终止并恢复。
设置观测指标阈值：如果全局稳态指标（如错误率）超过预设红线（如错误率突增5%），立即自动终止实验并执行预定义的恢复脚本。
所有注入的故障（如网络延迟、CPU负载）都必须是可逆操作，有对应的“清除”指令。

4)严格的审批与时间窗口：
银行通常要求所有生产/准生产环境的混沌实验必须经过变更审批，并在业务低峰期（如凌晨2-4点） 执行，且有应急人员全程待命。

总结：安全不是靠运气，是靠分层防御——从环境选择、流量隔离、自动熔断到流程审批，每一层都设防。

10、银行业务
用混沌工程验证交易一致性（比如模拟网络丢包后，交易是否仍能保持幂等）
“分布式核心”、“账务一致性”、“削峰填谷”、“容灾双活”
银行对生产环境的安全要求极高， 强调“安全”与“可控”，弱化“破坏”
强调所有实验都必须是可逆的，并具备完善的事后还原与影响分析能力
通过环境隔离（如“沙箱环境”）、节点打标签、实验自动熔断/回滚等机制，确保演练不影响真实业务
银行做混沌工程是为了验证应急预案的有效性、提升灾备切换效率，最终是为了满足监管对系统韧性的要求

11、混沌工程中，故障注入结束后第一步应该是：恢复服务并评估影响，优先恢复稳态
混沌工程的核心价值是验证系统弹性和韧性
混沌实验强调“最小爆炸半径”是：为了最小化影响范围，保障业务安全（核心原则强调可控、安全实验）
混沌实验启动前必须先明确系统稳态指标，即必须先定义正常指标（稳态指标），才能判断异常，无稳态无法判断实验影响
混沌工程与传统故障测试的主要差异是：混沌面向未知风险，传统测试验证已知逻辑
核心支付链路必须严格评审与控制（必须有预案、审批、限流），不适合做混沌实验
混沌实验中监控系统的主要作用是判断系统是否维持稳态（是否符合预期）
混沌工程推荐的实施顺序是：测试环境演练->逐步灰度生产
混沌工程“稳态假说”的含义是：正常流量下可保持稳定指标
混沌工程中自动化实验目的是长期持续验证系统韧性