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

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

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

01 如何保证业务连续性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03 拨压测一体化是什么

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

（1）什么是拨测

拨测试一种零侵入、开箱即用、主动式服务的可用性和性能监控工具，它通过部署在全球的监测点，模拟真实用户的业务行为，定时对站点发起测试，持续监测业务连续型和网络性能，并衡量用户体验。作为主动式监控服务，不受业务峰谷期的影响，全周期守护业务连续型。云拨测的核心能力和应用场景如图：

（2）什么是压测

压测是容量规划中不可缺少的工具，相信大家也非常熟悉了，根据验证的场景不同，压测又可以分为以下几种测试类型：

（3）拨压测一体化平台

可以看出，拨测和压测都是通过模拟真实用户的行为，来对系统的容量、可用性、性能做测试，从业务场景和系统架构的角度来看，拨测平台和压测平台有高度的相似性。因此，我们把拨测压测平台整合为拨压测一体化的平台，统一管控脚本、调度任务和流量。

压测前需要准备业务脚本，其实拨测也是需要这么一套脚本的。当拨测和压测分为两个平台的时候，同一套业务流程，需要使用两个平台的语法，配置两遍。通过拨压测一体化脚本，其实可以把这个配置脚本的工作减半，一套脚本，既能发起拨测，也能发起压测。

04 拨压测一体最佳实践

阿里云网站测速平台支持对 PING、TCP、DNS、网站测速、HTTP 接口、文件下载等场景进行拨测，并支持对 HTTP 接口进行压测。您还可以通过阿里云网站测速平台发起对比拨测，了解两个网站之间的性能差异。下面介绍如何通过阿里云网站测速平台，验证站点可用性和接口性能。

（1）发起网站测速任务

此处以模拟电信、移动和联通运营商在全国 34 个省会城市对阿里云官网访问为例，演示如何使用阿里云网站测速平台对网站进行测速。

登录阿里云网站测速平台[1]。
选择拨测类型。此处选择网站测速。
单击拨测类型下方的下拉框，选择监测点。此处选择运营商为电信、移动和联通，选择地区为全国 34 个省会城市。
在下拉框右侧输入需要进行拨测的 Web 应用地址。例如：http://www.aliyun.com。
单击立即发起。

在拨测结果区域查看网站的可用性、首包用时、首屏用时、完全加载用时等指标，以及各监测点详细数据列表。

单击详细数据列表对应监测点右侧的详情，可以查看对应监测点的详细性能指标和页面元素。

性能指标

页面元素

（2）发起对比拨测

您还可以通过阿里云网站测速平台发起对比拨测，了解两个网站之间的性能差异。

此处以模拟电信、移动和联通运营商在全国 34 个省会城市对阿里云和其他云厂商访问为例，演示如何使用阿里云网站测速平台对比两个网站的性能。

登录阿里云网站测速平台。
选择拨测类型。此处选择网站测速。
单击拨测类型下方的下拉框，选择监测点。此处选择运营商为电信、移动和联通，选择地区为全国 34 个省会城市。
单击对比拨测，然后输入需要进行对比拨测的 Web 应用地址。例如：http://www.aliyun.com 和 http://www.XXcloud.com。
单击立即发起。
在拨测结果区域查看两个网站的可用性、首包用时、首屏用时、完全加载用时等指标，以及各监测点详细数据列表。