我研究了混沌的原理，并寻找了一些开源项目，比如阿里巴巴开源的chaosblade和vmware的mangle。
这些工具都是故障注入工具，对测试系统的分析没有任何作用。
根据混沌原理，我们应该
1.首先将"稳态"定义为系统的一些可测量输出，指示正常行为。
2.假设这种稳定状态将在对照组和实验组中继续。
3.引入反映真实世界事件的变量，如服务器崩溃、硬盘驱动器故障、网络连接中断等。
4.试图通过寻找对照组和实验组之间稳态的差异来推翻这一假设。
那么我们如何执行步骤4呢？我们是否应该使用监控系统来监控一些主要指标，以检查故障注入后系统的状态。
有什么好的建议或最佳实践吗？
那么我们如何执行步骤4呢？我们是否应该使用监控系统来监控一些主要指标，以检查故障注入后系统的状态。
一如既往，答案是it depends...。这取决于你想如何衡量你的假设，取决于假设本身，也取决于系统。但通常引入度量来提高/增加可观察性是完全有意义的。
如果你的假设是Our service can process 120 requests in a second, even if one node fails.，那么你可以通过指标来衡量是的，但你也可以通过发送和接收回复的请求来衡量。这取决于你。
但如果你的假设是I get a response for an request which was send before a node goes down.，那么直接用请求和响应来验证这一点更有意义。
在我们的项目中，我们使用了例如chaostoolkit，它可以让您在json或yaml中指定假设，并通过相关操作来证明它
所以你可以说我有一个稳态X，如果我做了Y，那么稳态X应该仍然有效。如果您愿意，该工具包还可以验证指标
混沌原理略高于实际测试，它们反映了设计与实际系统以及注入与基线下系统的哲学，但有点过于抽象，无法应用于日常测试，它们是一种推理方式，而不是一种工作过程方法。
我认为对照组与实验的措辞是一个特别值得怀疑的部分——你在受控环境中进行测试(注入(，并试图了解是否存在面向用户的事件、任何形式的SLA违反或降级。如果你在支架或专用环境中进行测试，我看不出哪里有对照组。
我们使用了一种非常线性的各种混沌方法，即：
- 查找系统中的故障点(基于体系结构、关键用户场景和事件历史(
- 设计choas测试场景(可能是单个攻击或更复杂的序列(
- 运行测试、注册结果并为新版本重用绿色
- 启动修复红色测试的任务，在解决方案可用时进行验证
可以说，我们实际上在使用1和2中的Choas原理，但我们倾向于认为Choas测试是一个非常线性和简单的过程。
Mangle 3.0发布了一个使用弹性分数进行分析的选项。详细文档可在https://github.com/vmware/mangle/blob/master/docs/sre-developers-and-users/resiliency-score.md