研究了混沌原理，找了一些开源项目，比如阿里巴巴开源的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 应该仍然有效。如果您愿意，该工具包还能够验证指标。
Mangle 3.0 发布了一个使用弹性分数进行分析的选项。详细文档可在https://github.com/vmware/mangle/blob/master/docs/sre-developers-and-users/resiliency-score.md获得
混沌原理略高于实际测试，它们反映了设计与实际系统以及注入系统与基线的哲学，但过于抽象，无法应用于日常测试，它们是一种推理方式，而不是工作过程方法论。
我认为对照组与实验的措辞是一个特别值得怀疑的部分——您在受控环境中进行测试（注入）并尝试捕捉是否存在面向用户的事件、任何形式的 SLA 违反或降级。如果您在支架或专用环境中进行测试，我看不出哪里有对照组。
我们使用非常线性的混沌方法，即：
有人可能会说我们实际上是在使用 1 和 2 中的 Choas 原理，但我们倾向于认为 choas 测试是非常线性和简单的过程。