混沌工程初分享

一、什么是混沌工程

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、故障方式确认（故障平台）

4、故障表现梳理

• 强弱依赖确认：强弱依赖关系是否合理，弱依赖是否走降级策略
• 故障后预期：预期是什么（兜底、重试策略、崩溃等），是否可控
• 指标的确认：故障注入、恢复时间

三、问题详情举例

1、送礼下游依赖的用户服务，对于礼物面板展示属于弱依赖，故障不可用后

• 预期：礼物面板应该展示正常，送礼失败，其他功能不受影响；
• 实际：上游依赖方超时，礼物面板不展示，影响送礼核心功能；
  
  因此针对强依赖我们也需要关注：
  a.下游数据能正常返回，即使是错误数据也对主流程（长链路）不影响
  b.下游不能将耗时耗尽，影响主流程执行

2、xgift 服务缓存超时，查缓存不回源时，礼物面板不展示（giftData接口不返回）；预期送礼异常，面板正常返回。【技术预期优化】

3、general-interface下游（全屏动画资源配置）的 live-play (飘屏资源、生效特效等) 服务注入故障不可用（丢包率100%），Android配置全屏动画的道具可以正常展示，送礼正常;

预期配置全屏动画的道具不可展示，不能赠送，iOS符合预期。【产品预期优化】

四、后续可优化点

1、根据业务形态，新增不同场景，不同业务的混沌测试。
2、可以从UAT环境逐步走向预发、生产环境。
3、全自动、全随机的混沌测试。通过不定期、不定时的进行随机故障注入。
4、端上能够全时段，全平台，对主干体验进行监控，在故障时，有兜底策略。