混沌工程笔试题

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

11、JAVA:
final修饰的类不可被继承、equals比较字符串内容，==比较引用地址
public static void main为程序的固定入口
ArrayList基于数据，随机访问效率高，非线程安全的集合
runtimeException属于非受检异常，无需强制捕获
接口方法默认为公共抽象方法，默认修饰符是public abstract
堆内存线程共享，主要作用是存储对象实例
手动抛出异常的关键词是throw

12、测试：
边界值测试上下界及内外点
测试步骤是复现与修复问题的关键
探索性测试强调经验与即时设计（不依赖预制用例）
冒烟测试是做通断性校验
负载测试验证并发承载能力
测试左移=尽早接入（核心是让测试活动尽早参与项目）
缺陷密度：每千行代码的缺陷数
测试用例必须有明确的预期结果才能执行

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

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

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

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

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

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

关键工具：

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

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

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

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

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

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