如何让混沌工程实验降本增效

更新日期: 2022-05-31阅读: 749标签: 工程

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

近十几年来,随着企业业务不断微服务化,并迁移到复杂分布式的云生产环境,云上各个微服务业务系统之间相互访问的稳定性,以及与所依赖的第三方系统之间相互访问的稳定性,都会受到错综复杂的云生产环境的未知暗债(“暗债”是 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

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!