混沌工程初分享
混沌工程初分享
一、什么是混沌工程
1、什么是混沌
混沌是一种现象，在一个动力系统中，因为各种不同的参数变化导致的一系列的连锁反应。
比如：
在南美洲亚马逊河流域热带雨林中的蝴蝶，偶尔的几次振翅，可以在两周以后引起美国得克萨斯州的一场在龙卷风。
因为蝴蝶振动翅膀的行为，导致其身边的空气系统发生变化，并产生微弱的气流，而微弱的气流的产生又会引起四周空气或其他系统产生相应的变化，由此引起一个连锁反应，最终导致其他系统的极大变化。
2、什么是混沌测试
混沌测试 是一种 可试验的、基于系统 的方法来 处理大规模分布式系统中的混乱问题。
通过不断试验，观察系统的行为和反应。了解系统的实际能承受的韧性边界并建立信心，总而言之—— 以试验的方法尽早揭露系统弱点。
3、如果不做混沌测试
我们会尽可能多地编写单元测试，覆盖代码逻辑；
进行足够多的系统测试、场景覆盖测试，确保我们的系统可以与其他组件一起工作；
进行回归测试，确保新功能与老系统的兼容性等。
还会执行性能测试，用以改进处理数百万次请求的性能。
可是，这些 对于分布式系统来说还远远不够。
无论我们做了多少测试，仍然无法100%保证我们的系统能够应对生产环境的各种不可预测性。
我们可能会遇到以下的应用层、数据层、中间件层、操作系统层、存储层、网络层存在的各种问题。
所以为了让我们的分布式系统更加健壮，我们需要注入各种可以控制的异常；
并进行全链路实时监控，全面掌握注入异常可能导致的系统问题；
从而 提升系统容错性，建立系统抵御生产环境中不可预知问题的信息。
4、业内混沌工程有哪些
-
Netflix 是混沌工程的著名先驱，也是最早将其用于生产系统的公司之一。并出版了混沌工程领域内的首部书籍《混沌工程：Netflix 系统稳定性之道》，另外其开源混沌项目-Chaos Monkey （用于向基础设施以及业务系统中注入各类故障类型。这只 “猴子” 就是混沌工程起源。）
-
阿里巴巴是国内较早开始探索混沌工程并做出开源的公司，其开源项目 ChaosBlade可以结合阿里云进行 chaos 实验。
-
PingCap 作为国内优秀的数据库领域开源公司，在最近开源了内部混沌工程实践平台 - Chaos
Mesh。（一个云原生的混沌测试平台，Chaos Mesh 提供在 Kubernetes 平台上进行混沌测试的能力。让应用跟混沌在
Kubernetes 上共舞。） -
Gremlin 为一家混沌工程商业化公司，该公司提供了一个混沌工程实验平台，用于在已安装 Gremlin
守护进程（代理）的计算设备上执行和管理混沌实验。同时提出了 chaos gameday
的概念。（目的是通过有目的地、定期地、创建重大故障来提高可靠性。它们还有助于提升混沌工程的价值） -
字节跳动早期在内部使用的故障演练平台，主要通过网络干扰模拟下游依赖故障。
5、不同角色混沌测试中的任务
架构师：验证系统架构的容错能力
开发&运维：提高故障的应急效率
测试：提早暴露线上问题，降低故障复发率
产品&设计：提升客户使用体验
二、混沌测试梳理思路
1、被测服务链路梳理
-数据链路(进直播间接口)
链路追踪：
1、使用服务链路梳理平台对被测服务的上下游依赖进行梳理
梳理服务依赖
2、强弱依赖梳理：梳理核心接口依赖，选择接口，筛选trace，选择查看深层关系依赖图
3、涉及中间件
方法A：
使用traceid 查看数据链路，同时结合代码查看 ，从代码里可得知，网关层，网关层接口有热门房间缓存 是本地缓存（需要重启容器才可清缓存）
由链路可得知，直播间接口 → 房间信息接口 → 勋章信息接口, 勋章信息接口服务依赖redis（后续注入中间件故障时，需在勋章信息接口服务进行）
方法B：服务依赖梳理平台也会罗列 mysql、redis 的配置信息，进行梳理
2、故障类型梳理
-依赖RPC服务故障：强弱依赖超时/不可用/内容异常
-中间件故障：配置中心超时/不可用，Redis 超时/不可用，Databus 超时/不可用
-机器故障：自身宕机、CPU满载、内存异常、磁盘空间满载、网卡流量满载、网络中断
-基础设施故障：数据库超时/不可用，DNS 超时/不可用，机房超时/不可用
故障类型大致分为不可用、不稳定，给出以下参考配置，给出以下参考配置
故障类型 故障配置 备注
服务不稳定
CPU占用率>=70%
内存占用率>=70%
服务网络丢包50%
服务不可用
服务超时
服务网络丢包100%
服务自身宕机（杀pod）
CPU占用率100%
内存占用率100%
数据库中间件不稳定
redis网络丢包50%
db网络丢包50%
数据库中间件不可用
redis连接超时 （注入overlord伴生容器）
redis连接报错
db连接超时
其他 配置中心超时
3、故障方式确认（故障平台）
故障注入平台 平台地址 使用指南 实现原理 支持功能 优缺点
基于chaosblade的FIT平台
uat 环境：http://uat-sre.bilibili.co/chaos/test
pre/prod 环境：http://sre.bilibili.co/chaos/test
2.1 单一实验
容器层面故障：
使用Linux中的一些kill、tc等一些命令，提供故障模拟的能力
模拟CPU负载：CPU100% 就是起个服务，真实的去占用容器的CPU资源，这个是模拟CPU争抢(处理慢或者超时，能响应 也是符合预期的)
模拟IO高：两个进行，一个读、一个写，调用dd命令实现的 IO 高模拟；
模拟端口不通：ChaosBlade 是通过 iptables 命令添加 drop 规则来实现的禁用端口；
模拟丢包： ChaosBlade 是通过 traffic control 添加过滤器队列、分类、过滤器来实现的。也就是 tc 的 netem loss。
模拟网络延迟：通过 traffic control 添加过滤器队列、分类、过滤器来实现的网络延时。也就是 tc 的netem delay。
ChaosBalde 是通过将 tc 来实现的模拟丢包和延时。杀死进程：kill命令
支持系统问题的异常注入：
基础组件：server重启、下游服务宕机、网络延迟&丢包、内存&CPU高负载、中间件Redis、DB、MQ等调用异常
业务：CPU打满、内存异常、磁盘读写故障、数据库、缓存、下游服务的网络延时和丢包、DNS篡改。
服务层面仅支持 A 到B这种故障，B自身这块平台上没支持
优点：
使用chaosblade方案，容器级别 的故障
缺点：
1、手工方式操作,比较繁琐，效率低、难以复用
2、每次执行要手动重新配置
3、容器爆炸半径难以控制
4、不能在线上环境操作
混沌故障平台
uat环境：https://uat-main-infra.bilibili.co/#/applicationHighAvailability/appList
pre/prod 环境：https://main-infra.bilibili.co/#/applicationHighAvailability/appList
故障演练平台-Quick Start
集成SDK的模式：
调用（redis、mc、grpc、http）组件前，会先调用故障演练的sdk，根据平台配置按需注入错误，拦截到真实组件的调用；
指定集群、节点、接口和用户，在请求粒度上注入错误，实现故障的精确控制。
比如请求redis： 请求-> 故障演练sdk（这里拦截，redis请求报错、超时等） -> redis sdk -> 真实redis
优点：
1、简便选择接口、缓存端口号等；
2、支持实际强弱依赖自动收集
3、可控制爆炸半径范围
4、实时日志等
缺点：
1、使用前，代码需接入sdk（一行代码），对实际性能无影响
2、不支持cpu、内存异常故障
4、故障表现梳理
- 强弱依赖确认：强弱依赖关系是否合理，弱依赖是否走降级策略
- 故障后预期：预期是什么（兜底、重试策略、崩溃等），是否可控
- 指标的确认：故障注入、恢复时间
详情：混沌测试梳理思路
EG : 直播送礼场景梳理：https://info.bilibili.co/pages/viewpage.action?pageId=298977715
以送礼功能为参考：
【混沌测试一期】…/…/混沌工程/【已评审–全量】–混沌测试送礼功能.xmind
【混沌测试二期】s12送礼混沌测试
三、问题详情举例
1、送礼 下游依赖的 用户 服务，对于礼物面板展示属于弱依赖，故障不可用后
预期礼物面板应该展示正常，送礼失败，其他功能不受影响；
实际上游依赖方超时，礼物面板不展示，影响送礼核心功能；
因为针对强依赖我们也需要关注：
2、下游数据能正常返回，即使是错误数据也对主流程（长链路）不影响
3、下游不能将耗时耗尽，影响主流程执行
4、送礼服务缓存超时，查缓存不回源时，礼物面板不展示；预期送礼异常，面板正常返回。【技术预期优化】
5、全屏动画资源配置服务下游 的 飘屏资源服务 注入故障不可用（丢包率100%），Android 配置全屏动画的道具可以正常展示，送礼正常;
预期配置全屏动画的道具不可展示，不能赠送，iOS符合预期。【产品预期优化】
四、Q&A
Q A 备注
五、后续优化
1、根据业务形态，新增不同场景，不同业务的混沌测试。
2、可以从UAT环境逐步走向预发、生产环境。
3、全自动、全随机的混沌测试。通过不定期、不定时的进行随机故障注入。
4、端上能够全时段，全平台，对主干体验进行监控，在故障时，有兜底策略。