完整内容在此, 干话王_Docker 环境中用 Pumba 进行混沌测试
Chaos Engineering
「混沌不是深渊,而是发现系统韧性的镜子」
混沌工程是什么,不是什么?
最常见的误解是混沌工程只是随机地破坏营运环境中的事物。
只要可以帮助我们确信系统可以抵御突发事件的方法其实都可以称为混沌工程。混沌工程主要透过实验性的方法,从而建立对系统抵御营运环境中突发事件能力信心的工程。换句话说,混沌工程是一种透过主动注入故障来验证系统韧性的方法,目标是在真实故障发生前暴露系统脆弱性。
混沌工程 v.s. 故障演练 v.s. 测试 的差别
混沌工程实验听起来与另外两个很像, 但目的其实差异很大。
- 混沌工程 v.s. 测试
测试目的是关注已知的断言是否通过. 混沌工程关注的是发现更多未知的暗债。
- 混沌工程 v.s. 故障演练
故障演练侧重于操练已知的故障应对流程, 混沌工程侧重透过实验发现更多未知的暗债。
在营运环境上执行实验, 会有风险
其实任何有人在使用的系统都会有所谓的暗债, 未知的意外可能发生, 这些都是不可预测的. 即使我们不主动引入故障风险, 其实这些风险本来就存在着, 不是不会发生只是时候未到. 所以混沌实验要定义最小化爆炸半径来进行实验.
其次团队文化也不该一昧要求工程团队不能也不应该出现任何问题或失误. 一但有这样强硬的规范定案下去, 以后在未知的故障出现时, 大部分会出现甩锅情况, 耽误了更多发现更多暗债以及设计防范措施的时间.
尝试看看
团队如果有以下理由的话,不坊考虑实践混沌工程试试看︰
-
确定风险与成本,并设定 SLI、SLO 与 SLA。
-
在整体上测试系统(相比于端对端的测试,更加全面)。
-
找到团队忽略的**涌现性(Emergence)**特性。在复杂系统中,服务与组件之间的复杂交互可能导致意想不到的系统行为。例如,多个服务自己正常运作,但组合在一起时于高负载下出现极大的延迟或故障发生。
实验的 4 个步骤︰
定义稳态指标
定义什么是正常的,这取决于该系统跟目标。你可以是没有刮伤的车以 80 KM 的速度上阳明山,也能是其他的条件视为正常。最常见的大概是「9x %的使用者可以在 xxx ms 内访问系统的 API」。要定义哪些稳态指标,应该直接由业务策略来驱动设计的。能参考 Alex 的 Implementing Service Level Objectives: A Practical Guide to SLIs, SLOs, and Error Budgets 一书。
但我们前面有说混沌工程是更加全面的。其实很多因素都会影响这个指标。例如系统程序是否获得足够的 CPU time 与 memory?或者这些资源正在被其他程序佔用着。是不是 kernel 把 CPU 分配给令一个更高优先权的程序?诸如此类的。
设计实验假设
在这阶段,我们要把直觉塑造成一个可验证的假设,在一个明确定义的问题出现时,你的系统会发生什么情况的有根据的猜测。系统会继续工作嘛?还是逐渐变慢?变慢了多少?
现实中容易出问题的场景大概常见的如下︰
-
环境事件(断电、水灾、地震…)
-
硬体故障(CPU, Mem, Disk, Switch、变压器)
-
系统资源(CPU, Mem, 硬盘空间、频宽)
-
软件问题(Bug, Crash, Leak, Hack attack)
-
系统瓶颈
-
不可预期的涌现性特性
-
硬体的 bug
-
人为失误(设定错误、不小心关机….)
最简案例
o11y 显示的是我们跟使用者是否能够成功调用 API。稳态指标是 API 都能成功的回覆。实验假设是如果 cache 失效了,依然能获得回覆。执行实验,发现现在版本存在缺陷,新版本修复后正常。
定义稳态指标 | 确立系统正常行为基準 | API P99 延迟 < 200ms,错误率 < 0.1% |
设计实验假设 | 明确预期故障影响范围 | 当 30% 节点失效时,服务降级但不停机 |
执行故障注入 | 可控环境下触发故障 | 随机终止 Pod,网路延迟 500±50ms |
观察与分析 | 比对稳态指标偏差 | 错误率飙升至 15%,自动扩容触发延迟 |
常见误区澄清表
随机制造混乱 | 精準注入故障模式 |
营运环境专用 | 建议先在预发环境验证 |
一次性活动 | 需纳入CI/CD常态流程 |
仅测试基础架构 | 应包含业务逻辑验证 |
Pumba(a)
Pumba 是一个针对 Docker 容器进行混沌测试的工具,可以终止容器(kill、stop、remove),模拟网路问题(netem)、对容器的 cgroup 资源进行压力测试(stress)等。
完整内容在此, 干话王_Docker 环境中用 Pumba 进行混沌测试