00 开始之前

1. 混沌不是计划内的事情，是冷不丁的来一下。
2. 没上混沌工程之前，一些小bug都知道
3. 上了混沌工程之后，小事变大事，bug瞒不住
4. 混沌不是找茬，是提前发现问题

01 混沌工程是不是大公司专属

1.1 混沌工程的由来

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system`s capability to withstand turbulent conditions in producion.

什么是混沌工程

• 在分布式系统上进行实验的学科，建立在生产环境中低于突发事件的信心
• 混沌工程并不是为了制造问题，而是为了捅破问题

混沌工程解决了什么问题？

• 分布式系统的反脆弱问题

  
  image.png

混沌工程出现的原因

• 服务调用黑洞
• 不可预知的用户使用场景
• 对稳定性的极致要求

image.png

混沌工程的解决思路

• 主动出击，攻击是最好的防御

混沌工程的几个误区

1. 故障演练

- 故障演练是对已知问题的复现 —— 开卷考试
- 混沌工程是没有预案的“攻击”

image.png

2. 技术能力足够强

- 技术能力是一个量变到质变的过程，需要厚积薄发
- 是一个逐步积累的过程，也是一个去除技术债的过程。不做永远都不会做

3. 只适合互联网行业

- 混沌工程和行业无必然关系
- 入股故障后悔出现灾难性结果，那么就推荐使用混沌工程。反之，不建议使用。

4. 只是一种特殊的测试，和真实情况有偏差

- 测试 - 基于已知的场景，验证是否为预期的结果
- 混沌工程 - 基于线上真实场景，随机模拟用户使用情况，无固定预期结果：例如拔个网线、换个IP，对于用户是无感知的，注重用户体验

5. 影响线上环境

- 混沌工程是为了发现潜在的问题，而不是创造新的问题

image.png

- 将k=1改成k=2，这是没事找事，不可能发生的，这不叫混沌，叫伪混沌
- 机房掉电，这是可能发生的，这属于混沌工程

• 混沌是为了发现潜在问题，而不是为了创造新的问题

6. 混沌就是随即停止机器

- 混沌工程存在多种故障场景

image.png

1.2 混沌工程的总结

• 拥抱失败
• 主动防御
• 技术实践
• 证有不证无

1.3 总结

1. 混沌工程重点是发现影响系统可用性的问题，而不是发现逻辑bug。
2. 混沌工程的思路是主动出击，通过模拟各种合理范围内的故障，来验证系统是否达到高可用性的要求
3. 实施混多工程过程中，需要设计多种故障场景，控制爆炸半径，降低对线上环境的冲击性

02 如何在我的场景中使用混沌工程

2.1 混沌工程的原理

• 稳态假设
• 模拟真实世界
• 线上推演
• 持续自动化
• 爆炸半径

2.1.1 混沌工程原理 - 稳态假设

• 设定稳定的标准
• 与监控系统联动
  image.png

2.1.2 混沌工程原理 - 模拟真实世界

• 真实！=全量：（一般是线上环境直接做，但是风险很大，从用户角度直接出发）
• 针对核心指标指定实验变量
  image.png

2.1.3 混沌工程原理 - 线上推演

• 流量可控
  不要针对全量用户搞混沌
  哪些服务需要经受考验
  需要对这些服务做哪些混沌操作
• 范围可控
  如果范围和流量不可控，就不要搞混沌
• 失败预案
  混沌危险系数非常高，最好是有一键恢复，一键回滚
  常见兜底方案：别的可以不搞，至少要实现网关层的降级熔断（⚠️一定要实现的）

image.png

2.1.4 混沌工程原理 - 持续自动化

• 手动的实验缺乏可持续性
• 自动化建立在自动化监控系统之上
  1）只有实现了自动化搞混沌，才算落地了
  2）混沌工程需要建立在自动化监控系统之上，是一件高度体系化的事情
  ：自动化监控、自动化运维、服务自愈、CICD自动化、失败预案，这些东西全都要搞齐之后，才能开始混沌工程，因为我们做混沌用的是线上环境，要有敬畏之心

2.1.5 混沌工程原理 - 爆炸半径

爆炸半径：要测试的服务+要测试的故障场景融合在一起
选择爆炸半径的时候，要有一定的基础：CMDB，需要做好CMDB，才能生成拓扑图，这样想对某个服务做混沌，才知道哪些服务依赖这个服务，会有什么影响和后果

• A/B测试
• 流控
  原则是：最好不让用户感知到，线上在搞混沌工程
  image.png

image.png

2.2 设计混沌工程

• 单节点故障
• 单区域故障
• 服务故障
• 全链路故障
• 自动化

2.2.1 设计混沌工程 - 单节点故障

• 混沌工程的基础
• 资源超负荷
  如CPU、内存、IO
• 资源不可用
• 节点不可用
  单节点频繁重启、网卡频繁的up、down（前提是机器有管理网卡）

⚠️注意：对于单节点故障，一定要给自己留后门，比如网卡需要有管理网卡，如果没有down掉后，就再也无法访问了、CPU打满后需要给一定时长等等

image.png

2.2.2 设计混沌工程 - 单区域故障

1. 自建IDC的情况：

• 集群高可用的基础
• 电源故障
  问一下机房有没有双路电源，最近定期有没有做过断电演练；我们主要是模拟故障，不是真的来制造一个故障，真把电源断掉了就属于制造故障了
• 网络设备故障
  看一下接入层的设备有没有云备份，交换机是不是两台，别在同一个机柜上，把两台分散开，可以通过插拔网线验证一下，插拔网线一般不会出啥问题，比电源故障来的轻多了

2. 公有云的情况：

• 专线不可用
  从你的机房到公有云的机房这两段的网络设备是否高可用，当然公有云那边设备不需要看，就看自己的机房这边的设备是否高可用，如果胆大的话，可以先拔一根网线，如果心里没底可以问一下再拔网线，先把网络拓扑弄清楚，再看能否拔网线
• 基础设施不可用
  模拟集群对外不可用就可以了
  1）模拟一下VPC路由规则，改自己VPC网络的路由规则，模拟两个不通
  2）主要是通过改网关层来模拟，其他都是虚化层（已经在单节点模拟过了）

image.png

2.2.3 设计混沌工程 - 服务故障

• 业务高可用的基础
• 服务资源超负荷
  比如业务qps超过1000，看能不能响应
  如果有流量限流，我们可以先降成800或者500，通过这种方式模拟资源超负荷
• 当前节点超负荷
  把当前CPU打满，看服务是否还稳定
• 依赖中间件故障
  mysql、redis网络故障或者连不上，mysql慢查询、redis缓存失效了，在这种情况下，看服务是否高可用
• 基础设施不可用
  dns、lb等会不会触发服务的降级熔断
  image.png

2.2.4 设计混沌工程 - 全链路故障

istio：做这块全链路故障时候很好的一个搭档工具

• 线上环境高可用的基础
• 网关不可用
• 流控故障
• 网络故障
  image.png

2.2.5 设计混沌工程 - 自动化

• CI/CD高可用的基础
  最常见的在CD过程中，V1版本是稳定的，上V2版本是有问题的，要看CI/CD能否降级、回滚的操作等稳定性
• 基础设施故障（镜像仓库，配置中心）
  拉到一半镜像仓库拉不下来了，看CI/CD反馈，是告警还是回退还是正常往下走还是等待在这里
• 网络故障

2.3 开源工具

• ChaosBlade

  
  image.png

• Chaos Mesh

  
  image.png

2.3.1 开源工具 - ChaosBlade（1）

—— 开箱即用

• 场景丰富
• 使用简单
• 无侵入
  image.png

image.png

2.3.1 开源工具 - ChaosBlade（2）

• 支持多种场景实验
• 对Java和C++服务支持较好
• 典型使用场景
  • 计算资源 / 服务资源 / 网络资源
    image.png

03 混沌工程案