00 开始之前
- 混沌不是计划内的事情，是冷不丁的来一下。
- 没上混沌工程之前，一些小bug都知道
- 上了混沌工程之后，小事变大事，bug瞒不住
- 混沌不是找茬，是提前发现问题
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 总结
- 混沌工程重点是发现影响系统可用性的问题，而不是发现逻辑bug。
- 混沌工程的思路是主动出击，通过模拟各种合理范围内的故障，来验证系统是否达到高可用性的要求
- 实施混多工程过程中，需要设计多种故障场景，控制爆炸半径，降低对线上环境的冲击性
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
-
计算资源 / 服务资源 / 网络资源
