本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)，由 李兆龙 确认，转载请注明版权。
起源
Chaos engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent and unexpected conditions in production.
大概一年以前在上软件测试这门课时，我曾问过老师一个问题：当面对一个不知道结果的计算过程时如何做软件测试呢？这个问题细想起来很有意思，因为一个不知道结果的计算过程所能涵盖的过程实在是太过于广泛了。狭义的从计算机角度来说，一个复杂的分布式系统就是一个未知结果的计算过程，单个节点上软件测试是可行的，但是各个系统调用之间的准确性又该如何定义与测试呢？广义的从现实世界来说，没有办法可以准确预测某件单独事情对于全局的影响，比如俄乌战争，比特币下跌等等事件对于未来世界走势的影响。
纠其本质，真实的系统和世界不是简易且一成不变的，往往一个计算机的世界“函数”有着无数的输入，并不是只有按照调用规则中寄存器给你的那几个比特流而已。在系统与信号这门课中会学习到使用数学模型推导电气系统的行为，我们可以使用拉普拉斯变换来将整个电路的行为用一个函数表达。但是可惜软件系统并没有一个通用的数学模型来对未来行为建立预测模型。
抛开标准的定义不谈[1][2][3]，我认为混沌工程就是在主动模拟可能出现的故障，找到系统缺陷的过程。
标准化
奈飞的工程师确实厉害，混沌工程从开始的模拟故障到最后抽象出一套标准的流程，甚至演化出了学科，实在是令人佩服。
其实更令人佩服的还是五条准则：
- 建立稳定状态的假设
- 用多样的现实世界事件做验证
- 在生产环境中进行实验
- 自动化实验以持续运行
- 最小化爆炸半径
每个原则都代表了一种精妙的思想。首先混沌工程的实施本质上是需要检测结果的，这个结果简单来说可以是系统指标，但是因为本身的不可计算，结果往往应该定义为描述系统稳定，清晰，可度量的指标；其次选择注入的事件应该是与现实世界相符和；那为什么最好要在生产环境的实验呢，本质上还是太多测试环境很难模拟的问题造成的，比如生产环境的输入过于复杂，对于线上环境的三方依赖，生产环境的变更，已有的状态等；自动化实验与其他四点不同，它应该是属于工具实现的范畴，但是一定足够重要，因为混沌工程的本质在于对未知的探索，人工创建实验本身就包含着主动发现缺陷并测试的过程，这是本末倒置的；当然对于线上流量来说，控制风险是不必多说的问题。
有意思对是目前的混沌工程工具抽象出这样一套描述实验的抽象模型，基本清晰的阐述了实验本身[5]：
杂谈
大多数人听到混沌工程这个名词和pingcap不无联系，强大的宣传能力把一个CNCF孵化项目吹的神乎其神，但就我浅薄的看法来说，混沌工程工具和混沌工程本身是完全没什么关系的两个东西。
如何实现错误注入（无穷无尽的实验），指标分析（trace，金丝雀分析），自动实验(LDFI很有意思)，控制台操作这些是工具的事情，实施本身是使用者的事情，事实上我认为实施的过程才算是实践混沌工程，开发工具的过程沾边不大。
所以不是会造车就会开车，不是会磨锤子就会用锤子。目标和实现过程完全是两码事，在所有事情上过于强调过程而不是结果是不正确的，但是会造车的去开车和会磨锤子的用锤子和普通人当然也是不一样的。
编译器，操作系统，数据库一个道理。
参考：