持续测试新范式：拨压测一体化

作者：拂衣

近日，在 TiD2023 质量竞争力大会上，来自阿里云云原生可观测团队的吴垚进行了《持续测试新范式：拨压测一体化》主题分享，本次分享包含三部分：

业务连续性对稳定性平台的需求
阿里稳定性平台的演进及趋势分析
拨压测一体化的概念及最佳实践

如何保证业务连续性

在正式开始今天的话题前，我们先来聊一聊业务连续性。随着信息技术的快速发展和广泛应用，以互联网和金融业为代表的业务创新和正常运转越来越依赖于信息系统的安全和稳定运行。如何保证信息系统所支持的关键业务功能在故障或灾难发生后能及时恢复和持续运作，以减少故障或灾难可能造成的损失，已成为技术建设和运行维护必须考虑的重点课题。

不管是行业企业还是政府机构，对灾难恢复和业务连续性建设一直都十分重视，出台多项规范和指定性意见，如金融行业的《信息安全技术信息系统灾难恢复规范》（GB/T 20988 – 2007）和《银行业信息系统灾难恢复管理规范》（JR/T0044-2008）等标准、规范。同时，业界有非常多关于业务连续性的模型指导企业落地连续性建设，其中最让人熟知的就是 6R 模型。6R 模型详细描述故障从产生到结束的完整生命周期。纵览模型的整个周期，我们可以看到，整个周期被划分三道防线从而去保障业务的连续性：事前防控、事中应对、事后重建。

业务中断发生前，主要进行事前防控的工作，称为 Reduce（减少）阶段，即风险减少阶段。Reduce（减少）阶段是组织团队进行日常风险管理、IT 运维管理、业务连续性管理等管理工作。业务中断发生后，进行事中应对工作，并分为 Respond（应急响应）阶段和 Recover（恢复）&Resume（重启）阶段。Respond（应急响应）阶段阶段进行人员召集、情况了解和通报、损失评估、故障排查等工作；Recover（恢复）阶段主要执行恢复预案，包括IT部分的和业务部分以及配套支持职能部分的预案。恢复预案执行的启动是在宣布故障或灾难后开始。恢复预案执行完毕后事件稳定，进入 Restore（重建）和 Return（返回）阶段，业务回到正常状态。

在不断总结和复盘稳定性建设的过程中，我们发现在事前防控、事中应对阶段投入越多，全年故障发生总量也会相应降低。因此，我们对稳定性建设进行持续投入的同时，明确两个核心需求，即两个防线加固：

第一道防线加固： 模拟真实流量做压测，验证系统容量；故障演练，验证系统容灾容错能力。

第二道防线加固： 感知中断点左移，及时发现业务故障；建立开关预案机制，快速降级止损。

首先，是第一道防线的加固，即事前防控尽可能拦截到更多的故障。一方面，在业务上线之前做到充分的功能测试同时，对关键核心业务进行模拟真实流量的容量测试，也就是压力测试。另一方面，在整个系统上线之前，对预生产环境或灰度环境进行故障演练。比如说对基础设施层、应用层分别注入故障，观察系统自愈能力是否符合预期。所以，第一道防线加固需要确保在系统上线之前，能够把这个故障提前收敛掉。

其次，是第二道防线的加固，即缩短事中应对所花费的时间。事中应对的时间分为两个：感知时间与 Recover（恢复）时间。针对感知时间，这给监控和稳定性平台提出了新要求，即让感知点尽量左移，不要等到客户已感知到故障并反馈之后，才进行处理。做到能够提前主动感知到并在探测到故障之后进行快速的止损。同时，在实际生产过程中，随着各种意想不到的故障越来越多，我们就需要一套完整的预案机制。这其实就是 SRE 体系的建设，通过一套完整的应对机制来应对各种的故障。在阿里实践过程中，我们设计了开关预案机制，将历史发生的各种故障都抽象提炼到预案中。对故障处理的过程中，设计能够动态配置的功能降级开关。在大促时，如果有些业务的容量已达到水位阈值并会影响到稳定性时，可以直接通过动态的开关把对应功能进行降级，保证用户的整个使用体验平顺。

阿里保障业务连续性的最佳实践

接下来，我们看一下阿里巴巴及阿里云建设稳定性体系的演进过程，以及如何衡量体系建设的收益。

整个稳定性平台的演进与技术架构的演进息息相关，主要分为三个大的阶段。

首先，在淘宝刚刚开始时，技术架构主要还是单体应用。随着业务量的增加，PHP 单体应用被 Java 单体应用所取代。直到 08 年时，Java 单体应用也遇到了业务瓶颈，里面的业务逻辑非常复杂，开发人员非常多，迭代效率非常低。此后，阿里巴巴开始尝试分布式的应用架构拆分并在阿里云出现后，逐渐将核心电商交易系统迁移上云，以应对规模愈发庞大的业务。2018 年，阿里巴巴基本所有业务都跑在云上，并开始尝试容器化、Serverless 化等云原生化的探索。

与此同时，随着技术架构的演进，阿里巴巴围绕故障容错、异地多活容灾、容量规划进行稳定性的建设。通过引入调用链路分析平台、故障演练能力、压测体系等技术手段来提升稳定性，并将 ChaosBlade 等项目进行了开源，并进入 CNCF Sandbox。

与此同时，在支持内外部实施拨压测的过程中，我们发现测试角色的职责权限在 DevOps 环形图中向右移。越来越多测试团队不止负责上线前的功能测试、性能测试，也就是 Test 阶段。在功能上线后，还要通过拨测主动监控站点，线上业务可用性，也就是 Monitor 阶段。也是基于上述趋势与需求，云原生可观测团队提出拨压一体的概念，以帮助运维与测试团队更好的进行稳定性建设，这对于团队的收益非常明晰：

提升业务稳定性： 压测验证系统吞吐量，保证容量稳定性，拨测实时监控线上业务可用性，比业务方提前发现问题，缩小爆炸半径。
组织提效： 测试团队统一负责拨压测，梳理业务测试脚本工作不再需要测试、运维团队做 2 遍；运维团队专注资源监控，线上业务监控交给测试团队。
工具提效： 拨测压测共用一个平台，一套脚本语法，一组测试数据，提升工程师幸福感。

具体到业务收益，如故障数的减少、故障恢复时间缩短、提高无故障时间和失效间隔以及减少了故障处理的人力投入等。

拨压测一体化是什么

业务流量往往有峰谷效应，高峰期的业务中断可以通过服务端应用监控和告警及时感知，但在业务流量低谷期，如何感知业务中断成为难题。如果参照业务高峰期监控指标配置告警阈值，流量低谷期就不会触发到告警，无法感知到业务中断，如果告警阈值配置过低，在业务高峰期又会收到大量误告警。针对上述问题以及前文提到的右移，拨测、压测被有机的结合到一起。