混沌工程工具：一个混沌工程设计的例子(9)
原创
背景
前面几篇文章，从两个开源程序chaos-mesh、chaosblade入手，分析混沌工程的原理；然后讲混沌工程实施的完整过程及混沌原则梳理，本文主要是记录之前的知识，用一个例子说明混沌工程是怎么设计的。
混沌工程工具系列传送门：
1、 混沌演练工具Chaos-mesh与Chaosblade技术实现与原理分析(1)-腾讯云开发者社区-腾讯云
2、 混沌工程工具：chaos-mesh注入项原理分析(2)-腾讯云开发者社区-腾讯云
3、 混沌工程工具：chaosblade在服务器上注入项原理分析(3)-腾讯云开发者社区-腾讯云
4、 混沌工程工具：业务代码注入原理(4)-腾讯云开发者社区-腾讯云
5、 混沌工程工具：Chaosblade Java业务代码注入原理(5)-腾讯云开发者社区-腾讯云
6、 混沌工程工具：混沌工程实施过程及持久价值(7)-腾讯云开发者社区-腾讯云
7、 混沌工程工具：混沌工程定位及原则梳理(8)-腾讯云开发者社区-腾讯云
8、 混沌工程工具：一个混沌工程设计的例子(9)-腾讯云开发者社区-腾讯云
初版设计
设计原则
我们面对的系统十分庞大，微服务是数以千计，底层硬件也是数以千计，而单个组件的故障场景又有数十，最终构成了如此庞大的实验集，给实验选择带来了难度。
业界有的方法是随机抽取、专家权衡以及智能选择等方法，这些方法的本质，还是要看是否能满足商业目标。所以我们设计混沌工程时，应该服务于我们的商业目标：满足业务KPI(注意区分用户眼中的业务、运维眼中的业务)。
参考NF的解决方案，主要是使用FMEA 故障模式与影响分析的方法，来最终确定在哪里注入实验，能够获得最大的收益(混沌工程中称为能让团队学习到新东西)
所以第一版是采用专家设计模式:
1、 掌握待实验系统的知识
2、 基于业务功能设计实验
功能点级别设计表(以实际场景举例)
示例服务：
假定有这样一个链路，P服务是登陆服务，Q是用户数据库的中台，Redis缓存用户的登陆态、用户的账户信息等。目前都已经做了跨区部署，且P、Q无状态。
备注：下表只是出于演示，故障原因、故障模式并未穷举。列出一些经典的用来解释思维模式。
功能点 | 故障模式 | 故障影响 | 严重程度 | 故障原因 | 故障概率 | 风险程度 |
|---|---|---|---|---|---|---|
登陆 | Q无法访问MySQL | 当redis中无缓存时，用户无法登陆系统，预计有60%用户 | 高 | Q到MySQL网络中断 | 低 | 中 |
登陆 | 高 | MySQL集群掉电 | 低 | 中 | ||
登陆 | Q部分服务无法提供服务 | 如果超过半数的节点无法提供服务，用户会有访问延迟、无法登陆等情况发生 | 中 | 设备down机 | 中 | 低 |
登陆 | Q访问MySQL变慢 | 超过60%用户访问变慢或失败 | 高 | MySQL中有较多慢查询、全表扫描、负载高等情况 | 高 | 高 |
登陆 | 高 | Q到MySQL网络抖动 | 中 | 中 | ||
登陆 | 高 | MySQL底层设备异常而切换的，导致集群缓存丢失 | 中 | 中 | ||
......... | ||||||
大面积故障设计表
地域/可用区故障，是上面功能点级别故障的特例，主要考验的是业务系统设计完备性、人员的应急能力、应急自动化等能力。
基本工做扎实后才开始实施，这里不做展开。
最终设计
进行最终设计，要拉相关干系人进行讨论，因为对于复杂系统，一个人没办法掌握系统的方方面面，所以需要拉干系人进行讨论，避免认知上的缺陷。
讨论包括：
1、 讨论选择哪个实验(根据 混沌工程原则 -- 实验选择)
2、 该实验的业务KPI及资源特征(构建具有可证伪性的假说)
3、 如何实现实验(方法简单、可长期执行)
4、 爆炸半径控制方案，特别是生产环境有损的故障注入，要考虑注入时爆炸半径及恢复时爆炸半径(根据 混沌工程原则 -- 最小化爆炸半径)
5、 补偿能力，如果实验过程中对用户数据有影响，如何在结束时进行补偿
6、 应急处理，如果实验推翻了假说，团队如何动作来恢复业务
7、 快速终止实验的方法
最终方案表
最终实验表的选择，也是采用专家模式，基于下面的 实验选择 原则进行权衡。
功能点 | 故障模式 | 故障影响 | 故障原因 | 风险程度 | 是否演练 | 原因 | 稳态设置 | 演练方法 | 爆炸半径 | 补偿能力 | 应急处理 | 终止通道 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
登陆 | Q无法访问MySQL | 当redis中无缓存时，用户无法登陆系统，预计有60%用户 | Q到MySQL网络中断 | 中 | 否 | 1、 发生概率太低 2、 是主链路，发生时系统一定出问题 | ||||||
登陆 | MySQL集群掉电 | 中 | 否 | |||||||||
登陆 | Q部分服务无法提供服务 | 如果超过半数的节点无法提供服务，用户会有访问延迟、无法登陆等情况发生 | 设备down机 | 低 | 否 | 1、 需要在容量规划、监控环节cover 2、 实验学到的东西太少 | ||||||
登陆 | Q访问MySQL变慢 | 超过60%用户访问变慢或失败 | MySQL中有较多慢查询、全表扫描、负载高等情况 | 高 | 是 | 1、 该故障模式发生概率高 2、 发生时，会显著影响用户体验，有造成用户流失的风险 | 1、 前端有UI交互提示速度变慢 2、 登陆成功率 3、 Q服务资源监控 | 1、 在Q服务注入接口级延迟即可，没必要在网络、MySQL集群注入故障，以控制爆炸半径、保证演练可持续性 2、 借助推销员CFG，可以快速模拟CDB切换 | 针对select请求 | 无需 | 无需 | 执行实验工具的命令进行终止 |
登陆 | Q到MySQL网络抖动 | 中 | ||||||||||
登陆 | MySQL底层设备异常而切换的，导致集群缓存丢失 | 中 | ||||||||||
......... | ||||||||||||
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
