》混沌工程实验性价比太低，测试、研发、运维三个部门投入了大量的人力物力，“在准生产环境做了很多故障注入实验。但发现的问题还是比较少。”在一次混沌工程实践回顾会上，一位测试人员如是说，过去十年，随着企业业务的不断微服务化，以及向复杂分布式云生产环境的迁移，各个微服务业务之间相互访问的稳定性云上的系统，以及与所依赖的第三方系统的关系互访的稳定性受制于云生产环境错综复杂的未知暗债（“暗债”是一个漏洞具有以下特征的IT系统——这些漏洞在发生故障之前是不为人知或不可见的。“暗债”源自物理学术语“暗物质”，两者都可以影响世界，但人们无法直接检测或看到它们的影响.)不利于业务连续性。混沌工程是业界在处理上述问题的过程中诞生的良好实践。通过注入精心设计和协同在测试环境和生产环境中控制爆炸半径故障，并进行故障注入实验，可以观察和学习复杂分布式系统的运行模式和故障模式，从而提高团队的系统稳定性设计，使团队能够快速响应云环境中业务系统的未知故障。我们知道，要保持业务系统运行在云环境下的稳定性，离不开业务、研发、测试和运维等部门的紧密协作。这家公司的四个部门之间的协作是怎样的？最先响应运维部门号召实践混沌工程的是测试部门。测试部门认为混沌工程的故障注入实验可以丰富他们的压力测试和探索性测试场景，从而发现更多的软件缺陷。但相比之下，研发和业务部门的一线人员参与度还不够。他们认为，混沌工程的故障注入实验其实只是另一种测试。确实，测试部门使用混沌工程故障注入实验作为探索性测试。“混沌工程实验类似于探索性测试，实验本身没有明确的输入和预期结果，而是通过系统和服务的介入来观察系统的反应。”测试人员在测试总结中写道。缺乏明确的稳态行为假设由于测试人员采用探索性测试方法进行混沌工程故障注入实验，因此在实验结果报告中找不到“系统稳态行为假设”的字样。只是在后面对“风险问题”的描述中，隐隐约约看到了稳态行为假说的影子：“预计master节点的docker服务关闭后，kubelet/api/etcd等pod/controllers会失效，那么这些核心服务的进程也会失效，重启继续提供服务。”隐含的稳态行为假设并不能体现用户价值从上面的描述可以看出，本次混沌工程实验的稳态行为假设并非不存在，而是隐含存在，即“可以持续提供服务””那么如何算作“继续提供服务”呢？这可以从测试计划的监控方式上看出来。也就是说，对于所有的实验，无论注入的故障是什么，测试人员只关注三类指标：系统业务指标：如系统业务交易的错误率系统性能指标：如TPS（每第二）和响应系统业务交易时长的变化趋势系统资源指标：比如系统CPU、内存、磁盘IO和网络资源指标的变化趋势看到这三类指标，我有一个疑问：“用户真正关心的是业务交易错误率和TPS变化趋势是什么？”相信用户会更关心自己的订单能否在3秒内成功处理。每个人都可以很好地理解这一点。不能反映用户价值的稳态行为假说会带来什么后果？或许这种充满技术细节的稳态行为假设不便于业务人员和领导直观感知其业务影响，无法引起他们的注意，从而失去获得他们支持的机会，削弱了实验的价值。隐含的稳态行为假设不够量化，再看上面通过观察TPS变化趋势来判断“是否可以继续提供服务”的例子。如果这个实验由测试人员手动进行，经验丰富，测试人员可以判断系统是否“可以继续提供服务”。但是如果你把这个实验自动化，用一个工具在晚上自动执行这个实验，这个工具怎么定义系统是否“持续提供服务”呢？因此，为了实现自动化，必须量化稳态行为的假设，以便工具可以自动执行实验。一个良好的稳态行为假设示例下面是一个可以反映用户价值并具有量化指标的稳态行为假设示例：即使在实例故障的情况下，系统仍然可以在3秒内完成接受申请.否则会在5秒内提示用户该业务暂时不可用。这种稳态行为假设不仅包含成功场景，还包含失败场景。一个好的稳态行为假设可以节省实验成本如何设计一个可以节省实验成本的稳态行为假设？让我们来看看发生在这位企业测试员身上的故事。这些测试人员正在使用开源工具进行混沌工程故障注入实验。因为这个工具提供了5种类型的原子故障可以注入，所以测试人员也设计了5个实验。如果把稳态行为假设写在上面的例子中，会是这样的：实验一的稳态行为假设：即使在实例被终止的情况下，系统仍然可以在3秒内完成accepteduserseconds否则，会在5秒内提示用户服务暂时不可用。实验二的稳态行为假设：即使实例CPU满载，系统仍能在3秒内完成接受用户的交易，否则也能在5秒内提示用户业务暂时不可用。实验三稳态行为假设：即使实例内存已满，系统仍能在3秒内完成接受用户的交易，否则也能在5秒内提示用户业务暂时不可用。实验四的稳态行为假设：即使实例磁盘已满，系统仍然可以在3秒内完成接受用户的交易，否则也可以在5秒内提示用户业务暂时不可用。实验四稳态行为假设：即使实例网络关闭，系统仍能在3秒内完成接受用户的交易，否则会在5秒内提示用户业务暂时不可用。如果手动执行每个实验平均需要30分钟，那么执行这5个实验，将需要150分钟。稍等！我们是企业测试人员，不是开源混沌工程工具测试人员！这五个原子故障就像病毒一样，它们引起的症状都是一样的——实例故障。对于企业测试人员来说，只要选择注入以上五种故障中的一种，就可以达到使实例失效的目的。毕竟测试人员只需要关注实例出现故障后业务系统能否继续提供服务即可。也就是说，这五个原子断层属于同一个等价类。对于等价类，我们只需要注入一个原子错误。如果这5个原子断层必须全部注入，那么在后续几轮回归实验中，每轮实验可以依次选择不同的原子断层注入。这样，我们就可以为“实例失效”实验节省80%的实验成本。现在你知道为什么在上面的良好稳态行为假设示例中写“症状”——“即使在实例失败的情况下”。这在某种程度上也揭示了文章开头测试人员抱怨混沌工程实验“性价比太低”的原因。这个故事的启发是，如果我们为“症状”而不是“病毒”设计一个系统稳态行为假设，就可以帮助我们识别等价类，从而只注入少量“病毒”就可以实现同样的“症状”效应，从而降低了实验成本。综上所述，写出反映用户价值、易于量化、针对“症状”的系统稳态行为假设，可以让混沌工程实验的价值更容易被业务人员和领导理解，从而获得他们的支持，而且还可以更有利于自动化，通过等价类划分可以降低实验成本，进而达到降本增效的目的。
