“混沌工程实验性价比太低了。测试、研发和运维三个部门都投入了大量人力物力，在准生产环境做了不少故障注入实验。但发现的问题还是比较少。”在一次混沌工程实践回顾会上，一位测试人员如是说。

近十几年来，随着企业业务不断微服务化，并迁移到复杂分布式的云生产环境，云上各个微服务业务系统之间相互访问的稳定性，以及与所依赖的第三方系统之间相互访问的稳定性，都会受到错综复杂的云生产环境的未知暗债（“暗债”是 IT 系统中具有以下特点的漏洞——在引发故障之前，这些漏洞不为人知或不可见。 "暗债“源自物理学术语“暗物质”，两者都能影响世界，但人们却无法直接检测或看到它们。）的影响，而损害业务连续性。混沌工程就是业界在应对上述问题的过程中孕育而生的良好实践。

通过在测试环境和生产环境上，注入经过精心设计并控制好爆炸半径的故障，进行故障注入实验，就可以观察和学习复杂分布式系统的运行模式和失效模式，从而提升团队的系统稳定性设计，让团队能够快速应对业务系统在云环境上的未知故障。

我们知道，要想保持业务系统在云环境上运行的稳定性，离不开包括业务、研发、测试和运维部门的密切协作。这家企业的这4个部门的协作情况是怎样的呢？

最先响应运维部门实践混沌工程召唤的，是测试部门。测试部门认为混沌工程的故障注入实验，能丰富他们的压力测试和探索性测试的场景，从而发现更多软件缺陷。

然而相比之下，研发和业务部门的一线人员对此的参与度却不够高。他们认为，混沌工程的故障注入实验，其实就是另一种测试而已。

确实，测试部门就是把混沌工程故障注入实验，当作探索性测试来做的。“混沌工程实验，类似于探索性测试。实验本身没有明确的输入和预期的结果，而是通过对系统和服务的干预，来观察系统的反应。”测试人员在测试总结中这样写道。

缺乏明确的稳态行为假说

由于测试人员使用探索性测试的方法，来实践混沌工程故障注入实验，所以在实验结果报告中，找不到“系统稳态行为假说”的字眼。只是在“风险问题”的以下描述中，隐约看到稳态行为假说的影子：“预期主节点的docker服务关闭后，kubelet/api/etcd/controllers等pod会失效，之后这些核心服务的进程会重启，能继续提供服务”。

隐含的稳态行为假说没有反映用户价值

从上面的描述能看出，这个混沌工程实验的稳态行为假说，并不是没有，而是隐含存在的，即“能继续提供服务”。那如何才算“能继续提供服务”呢？这一点可以从测试方案的监控方式中，看出一点线索。即对于所有实验，无论注入的故障是什么，测试人员只关注3类指标：

1. 系统业务指标：如系统业务交易的错误率
2. 系统性能指标：如系统业务交易的TPS（每秒事务处理量）和响应时长的变化趋势
3. 系统资源指标：如系统的CPU、内存、磁盘IO和网络资源指标的变化趋势

看到这3类指标，我产生了一个疑问：“用户真的在乎业务交易错误率和TPS变化趋势吗？”我相信，用户会更在乎自己下的订单，是否能在3秒内成功处理。这一点所有人都能很好理解。那未能反映用户价值的稳态行为假说，会导致什么后果呢？或许这种充满技术细节的稳态行为假说，不便于业务人员和领导直观感知其业务影响，吸引不了他们的注意，从而丧失了获得他们支持的机会，并弱化了实验的价值。

隐含的稳态行为假说不够量化

再看上面这个通过观察TPS变化趋势来判断是否“能继续提供服务”的例子。如果这个实验是由测试人员手工执行的，凭借丰富的经验，测试人员是能判断系统是否“能继续提供服务”的。但如果将这个实验自动化，用工具在晚上自动执行实验，那么工具该如何界定系统是否“能继续提供服务”呢？所以要想实现自动化，必须要把稳态行为的假说进行量化，以便工具自动执行实验。

良好稳态行为假说示例

这里试着给出一个能反映用户价值，且有量化指标的稳态行为假说的示例：

即使在实例失效的条件下，系统仍然能在3秒之内，完成已受理的用户的交易，否则也能在5秒之内提示用户业务暂时不可用。

这个稳态行为假说，不仅体现了成功场景，也体现了失败场景。

良好稳态行为假说能节省实验成本

如何设计一个能节省实验成本的稳态行为假说呢？让我们看看发生在这家企业测试人员身上的故事。

这些测试人员正在使用一款开源工具，来进行混沌工程故障注入实验。由于这款工具，提供了5种可供注入的原子故障，于是测试人员也就设计了5个实验。如果用上述示例的写法，来编写稳态行为假说的话，会是这个样子：

1. 实验1的稳态行为假说：即使在 实例中止 的条件下，系统仍然能在3秒之内，完成已受理的用户的交易，否则也能在5秒之内提示用户业务暂时不可用。
2. 实验2的稳态行为假说：即使在 实例CPU爆满 的条件下，系统仍然能在3秒之内，完成已受理的用户的交易，否则也能在5秒之内提示用户业务暂时不可用。
3. 实验3的稳态行为假说：即使在 实例内存爆满 的条件下，系统仍然能在3秒之内，完成已受理的用户的交易，否则也能在5秒之内提示用户业务暂时不可用。
4. 实验4的稳态行为假说：即使在 实例磁盘爆满 的条件下，系统仍然能在3秒之内，完成已受理的用户的交易，否则也能在5秒之内提示用户业务暂时不可用。
5. 实验4的稳态行为假说：即使在 关闭实例网络 的条件下，系统仍然能在3秒之内，完成已受理的用户的交易，否则也能在5秒之内提示用户业务暂时不可用。

如果手工执行每个实验平均花30分钟，那么执行这5个实验，要花150分钟。

等一下！我们是企业的测试人员，不是开源混沌工程工具的测试人员！这5个原子故障好比病毒，它们所导致的症状都是同一个—— 实例失效 。而对于企业的测试人员，只要从上述5个故障中任选一个注入，就能达成让实例失效的目的。毕竟测试人员只须关注业务系统在实例失效后，是否能继续提供服务。换句话说，这5个原子故障，同属一个等价类。对于等价类，我们只要注入一个原子故障就够了。如果一定要全面注入这5个原子故障，那么可以在以后的各轮回归实验中，每轮实验依次轮流选择一种不同的原子故障注入即可。这样对于“实例失效”的实验，我们就能节省80%的实验成本。这下你就知道上面的良好稳态行为假说示例，为何要写“症状”了——“即使在 实例失效 的条件下”。这也在某种程度上，揭示了文章一开头测试人员所抱怨的混沌工程实验“性价比太低”的原因。

这个故事给我们的启发是，如果针对“症状”而不是“病毒”来设计系统稳态行为假说，就能帮助我们识别等价类，从而只选择少量的“病毒”注入，达成同样“症状”的效果，进而降低实验成本。

总结

编写反映用户价值、便于量化且针对“症状”的系统稳态行为假说，能让混沌工程实验的价值更容易让业务人员和领导理解，从而获得他们的支持，也能更有利于自动化，并能通过等价类划分，来降低实验成本，进而达成降本增效的目的。

原文 https://insights.thoughtworks.cn/chaos-engineering-efficiency/

链接: https://fly63.com/article/detial/11631