一、什么是混沌工程
1、什么是混沌
混沌是一种现象,在一个动力系统中,因为各种不同的参数变化导致的一系列的连锁反应。
比如:
在南美洲亚马逊河流域热带雨林中的蝴蝶,偶尔的几次振翅,可以在两周以后引起美国得克萨斯州的一场在龙卷风。
因为蝴蝶振动翅膀的行为,导致其身边的空气系统发生变化,并产生微弱的气流,而微弱的气流的产生又会引起四周空气或其他系统产生相应的变化,由此引起一个连锁反应,最终导致其他系统的极大变化。
2、什么是混沌测试
混沌测试 是一种 可试验的、基于系统 的方法来 处理大规模分布式系统中的混乱问题。
通过不断试验,观察系统的行为和反应。了解系统的实际能承受的韧性边界并建立信心,总而言之—— 以试验的方法尽早揭露系统弱点。
3、如果不做混沌测试
我们会尽可能多地编写单元测试,覆盖代码逻辑;
进行足够多的系统测试、场景覆盖测试,确保我们的系统可以与其他组件一起工作;
进行回归测试,确保新功能与老系统的兼容性等。
还会执行性能测试,用以改进处理数百万次请求的性能。
可是,这些对于分布式系统来说还远远不够。
无论我们做了多少测试,仍然无法100%保证我们的系统能够应对生产环境的各种不可预测性。
我们可能会遇到以下的应用层、数据层、中间件层、操作系统层、存储层、网络层存在的各种问题。
所以为了让我们的分布式系统更加健壮,我们需要注入各种可以控制的异常;
并进行全链路实时监控,全面掌握注入异常可能导致的系统问题;
从而 提升系统容错性,建立系统抵御生产环境中不可预知问题的信息。
4、业内混沌工程有哪些
-
Netflix 是混沌工程的著名先驱,也是最早将其用于生产系统的公司之一。并出版了混沌工程领域内的首部书籍《混沌工程:Netflix 系统稳定性之道》,另外其开源混沌项目-Chaos Monkey (用于向基础设施以及业务系统中注入各类故障类型。这只 “猴子” 就是混沌工程起源。)
-
阿里巴巴是国内较早开始探索混沌工程并做出开源的公司,其开源项目 ChaosBlade可以结合阿里云进行 chaos 实验。
-
PingCap 作为国内优秀的数据库领域开源公司,在最近开源了内部混沌工程实践平台 - Chaos
Mesh。(一个云原生的混沌测试平台,Chaos Mesh 提供在 Kubernetes 平台上进行混沌测试的能力。让应用跟混沌在
Kubernetes 上共舞。) -
Gremlin 为一家混沌工程商业化公司,该公司提供了一个混沌工程实验平台,用于在已安装 Gremlin
守护进程(代理)的计算设备上执行和管理混沌实验。同时提出了 chaos gameday
的概念。(目的是通过有目的地、定期地、创建重大故障来提高可靠性。它们还有助于提升混沌工程的价值) -
字节跳动早期在内部使用的故障演练平台,主要通过网络干扰模拟下游依赖故障。
5、不同角色混沌测试中的任务
- 架构师:验证系统架构的容错能力
- 开发&运维:提高故障的应急效率
- 测试:提早暴露线上问题,降低故障复发率
- 产品&设计:提升客户使用体验
二、混沌测试梳理思路
1、被测服务链路梳理
a. 数据链路(进直播间接口)
- 链路如何分析?
使用链路梳理平台对被测服务的上下游依赖进行梳理,梳理核心接口强弱依赖,选择接口,筛选trace,选择查看深层关系依赖图。 - 涉及中间件
方法A:
使用traceid 查看数据链路,同时结合代码查看 ,从代码里可得知,网关层,网关层接口有热门房间缓存 是本地缓存(需要重启容器才可清缓存)
http://dapper.bilibili.co/linkTrace/0013e8246496ce4568371a922e11d113
由链路可得知,房间页 → 房间grpc接口 → 勋章网关 , 勋章网关服务依赖redis(后续注入中间件故障时,需在勋章网关服务进行)
方法B:
http://uat-cloud.bilibili.co/paladin/appdetail?id=live.live.xgift#sh/sh001/uat 平台自动识别、罗列 mysql、redis 的配置信息,进行梳理
2、故障类型梳理
- 依赖RPC服务故障:强弱依赖超时/不可用/内容异常
- 中间件故障:配置中心超时/不可用,Redis 超时/不可用,Databus 超时/不可用
- 机器故障:自身宕机、CPU满载、内存异常、磁盘空间满载、网卡流量满载、网络中断
- 基础设施故障:数据库超时/不可用,DNS 超时/不可用,机房超时/不可用
故障参考指标:故障类型大致分为不可用、不稳定,给出以下参考配置,给出以下参考配置。
3、故障方式确认(故障平台)
故障注入平台 | 实现原理 | 支持功能 | 优缺点 |
---|---|---|---|
基于chaosblade的FIT平台 | |||
混沌故障平台 |
4、故障表现梳理
- 强弱依赖确认:强弱依赖关系是否合理,弱依赖是否走降级策略
- 故障后预期:预期是什么(兜底、重试策略、崩溃等),是否可控
- 指标的确认:故障注入、恢复时间
三、问题详情举例
1、送礼下游依赖的用户服务,对于礼物面板展示属于弱依赖,故障不可用后
- 预期:礼物面板应该展示正常,送礼失败,其他功能不受影响;
- 实际:上游依赖方超时,礼物面板不展示,影响送礼核心功能;
因此针对强依赖我们也需要关注:
a.下游数据能正常返回,即使是错误数据也对主流程(长链路)不影响
b.下游不能将耗时耗尽,影响主流程执行
2、xgift 服务缓存超时,查缓存不回源时,礼物面板不展示(giftData接口不返回);预期送礼异常,面板正常返回。【技术预期优化】
3、general-interface下游(全屏动画资源配置)的 live-play (飘屏资源、生效特效等) 服务注入故障不可用(丢包率100%),Android配置全屏动画的道具可以正常展示,送礼正常;
预期配置全屏动画的道具不可展示,不能赠送,iOS符合预期。【产品预期优化】
四、后续可优化点
1、根据业务形态,新增不同场景,不同业务的混沌测试。
2、可以从UAT环境逐步走向预发、生产环境。
3、全自动、全随机的混沌测试。通过不定期、不定时的进行随机故障注入。
4、端上能够全时段,全平台,对主干体验进行监控,在故障时,有兜底策略。