Fork me on GitHub

块存储质量的铸就之路 — 测试左移在大型分布式系统中的工程实践

修复一个Bug的成本在不同阶段有着天壤之别,发现问题越早,修复代价便越低。本文将讲述阿里云块存储在真实业务场景中的测试左移实践。

01 为什么要测试左移?

众所周知, 软件工程原则:问题发现得越早 ,修复问题的代价越低。 在《代码大全》一书中,从软件工程实践角度说明一个Bug的成本在产品需求分析阶段、开发阶段、测试阶段、生产阶段有着天壤之别,在修复难度、引入新问题的可能性、沟通成本等方面计算,集成测试阶段修复一个Bug的成本是编码阶段的40倍。

什么是测试左移?即测试向左扩展,让测试介入代码提测之前。比如,扩展到开发阶段,在架构设计时考虑产品的可测试性,进行开发自测。测试左移是一个理念,代码门禁 *[1] *是测试左移的典型实践,即提交代码自动触发编译和测试,构建失败则阻塞代码提交。

图片

图1 代码门禁

代码门禁通过缩短测试反馈弧尽早发现缺陷,阿里云块存储团队代码门禁单日有效拦截百余次Case,拦截多个业务逻辑缺陷、百余次进程Crash、数据安全性缺陷、CPU/Mem资源使用缺陷等。如若没有代码门禁,将导致问题被掩盖,不断积累。

02 何时进行测试左移?

在系统最初阶段建立严格的代码准入标准和CICD系统是否是最好的时机呢?从质量保证的单一维度考虑,答案是肯定的。但从业务整体效益来看并非全局最优。**理性看待技术债,技术债像贷款,有好也有坏,可以超前消费变现贷款买房,但相应的,有利息,利滚利,开发难度越来越大。 **

RethinkDB与MongoDB在竞争中失利。技术上,RethinkDB比MongoDB更追求完美,但是比MongoDB发布稳定版本晚了三年,错过了NoSQL的黄金时机,详细内容可以阅读《RethinkDB:why we failed》*[2] *。如下图所示,ABC三家公司关于技术债和业务先行的时间之间的平衡:

  • A公司:只关注业务,不关注技术债;
  • B公司:持续关注技术债,但对业务时机不敏感;
  • C公司:持续关注业务和技术债。对业务机会很敏感,最初放手借贷,控制技术债并在合适的时候偿还。

图片

图2 技术债 (来源:《质量与速度的均衡:让“唯快不破”快得更持久》葛俊)

阿里云块存储在2018年初发布ESSD* [3]* 邀测,业界首个百万IOPS的云盘服务,性能上有50倍的飞跃,在真实业务场景中,PostgreSQL数据库的写入速度快了26倍。透支了大量的技术债抢先了市场之后,团队内部集中偿还技术债,进行质量建设,一年后ESSD达到规模铺量的质量标准并进行了商业化。

03 测试左移的原则和实践

提前透支大量技术债后,团队养成了“糙快猛”的研发习惯,对于改变习惯和测试左移将面临落地的挑战,需要从上至下调整预期,测试左移的前期必然带来项目交付周期的放缓,长远来看,整体效率更高。

测试左移原则不等同于测试原则,实践总结了三条测试左移的原则如下:

图片

表1 测试左移原则

✪ 原则一:左移标准共识

建立左移标准并在团队内达成共识是测试左移最基础的原则,在代码门禁系统中要求代码覆盖率卡点、静态代码质量扫描,业务覆盖率* [4] *要求是所有功能测试均需在代码门禁阶段添加相应的测试Case覆盖。

例如,块存储的云盘是一个分布式存储系统,通过建立了Cluster in Docker的一键秒级构建集群环境实现Function Test测试脚手架,使得全链路E2E测试在代码门禁阶段有了落地的土壤。新Feature评审时功能测试不接受手工测试报告,只接受Function Test List的Code Review,以避免手工测试无自动化沉淀,相同问题重复出现。

✪ 原则二:坚持快速反馈

早发现早治疗,越早治疗修复成本越低。对于架构设计、编码实现和测试不足遗漏到生产环境的缺陷,不断反问,该问题是否可以在更早的测试阶段拦截?

例如,分布式系统下的级联雪崩故障,RPC Timeout不合理 + 无限重试 + 无并发Queue Depth限流造成错误的循环持续运转,负反馈机制压崩了分布式系统。全链路的极限压测是必须的,同时对于单一功能测试验证也必须在代码门禁环节添加自动化Case,让自动化验证限流、重试和超时机制符合设计实现预期。

✪ 原则三:持续分解问题

持续分解问题是测试左移最核心的原则,把一个系统拆解为多个子系统,用抽象和分层的方法,让每个同学开发时只面对有限的信息,并且能够有条理的深入到每一个子系统中查看细节。

例如,将复杂问题拆分成具体到每个模块松耦合的功能语义,各模块补充各自的契约测试覆盖。对于分布式系统Server热升级(热升级,即不影响服务的升级),需在升级前,中心管控节点Master将Server进程服务调度走,Server进程之间负责服务迁移(老进程Unload,新进程Load),Client需从Master/Server感知到服务已被调度走,需更换Location进行访问,拆解成Client/Master/Server的多个模块内Case覆盖。

在测试左移的实践过程中,总结了如下三个阶段:

✪ 阶段一:建立测试脚手架

简单可依赖的CICD的测试框架是基建保障。业界有很多开源的CI测试框架,例如Jenkins、GitlabCI、Travis-CI、Tekton等,阿里的Aone和蚂蚁的LinkIn等。

对于IaaS的底层块存储分布式系统,单个单元测试即达到4 Core Cpu和6GB Mem的资源需求,单机无法满足近万个门禁Case测试的及时性。业界和公司内的系统无法满足分布式编译构建和分布式测试的需求,块存储基于Kubernetes+Jenkins自研实现了门禁系统。

图片

图3 EBS CI门禁系统

通过Kubernetes实现Case资源隔离,每个Case独占容器,容器运行过程中CPU/Mem资源设置Limit,避免Case之间打架(例如:某个Case内存泄漏导致内存不足,发生争抢,CGroup可能误杀了其他Case),Case运行环境用完即抛确保环境一致性, 提交代码即自动触发测试(Test as a Service) ,确保有了土壤可以落地后,门禁系统负责测试运行,开发者负责Case编写和不稳定Case的问题解决。

✪ 阶段二:高频测试,快速测试

"If it hurts, do it more often" ,高频测试是治理不稳定Case的法宝,越低频复现的问题越难调查,尽量多的暴露不稳定的失败,降低问题调查的门槛。通过分布式并发运行、提高构建速度(增量编译/分布式编译)、分层测试提升测试运行速度。

块存储门禁系统基于Kubernetes实现,即具备测试并发度横向扩展能力,白天CI系统进行代码门禁卡点和自助构建任务,夜间高频百轮回归门禁Case和E2E回归。高频测试大大增加了低概率时序Bug的暴露频次,在门禁系统中通过CPU资源超卖,相当于模拟CPU主频降频,多次发现低概率的数据安全性、进程Crash等缺陷问题。

图片

图4 EBS 各级测试运行轮数

✪ 阶段三:不稳定Case治理

不稳定Case治理可能是门禁系统中挑战最大的部分,若不治理将导致破窗效应,测试左移则前功尽弃。不稳定Case治理的慢性病更适合小步快跑高频反馈,在具体实践中,首先,通过组织会议脑爆,共同吐槽门禁的不稳定,建立自发的共识、原则和标准进行公示,发动群众的主观能动性;其次,找到推动变革的关键人物,Team Leader和核心成员高度配合,建立红黑榜,每月树立效能之星,做的差的同时也有相应的惩罚;最后,找到推动变革的行动抓手,不稳定Case发现的数据安全性、Crash的严重缺陷团队内强调Case质量和该同学切身利益手头项目的强相关性,建立硬性标准:5%以上概率的失败commmit一天内revert等。关于不稳定Case的治理Google和微软在2016年和2017年相继发表了论文,Google论文* [5]*,微软论文 *[6] *。

块存储治理不稳定Case主要通过高频测试和文化布道。块存储门禁系统是全量卡点,即任一Case失败则阻塞代码提交,随着Case的增加,对Case的稳定性要求与日俱增。门禁系统上万个Case中如若有3个Case通过率为90%,则整体通过率为72%;一周内不稳定的Case的每日运行轮数是稳定Case的权重5倍,未修复Case更高频的暴露复现,对于已修复的Case以验证修复效果。团队内从上至下达成一致共识:生产问题优先级 > 不稳定Case优先级 > 新Feature项目研发优先级。下图是块存储近半年不稳定Case Top15的回归失败轮数,分子是失败轮数,分母是单日运行轮数,失败比例越高颜色越深。

图片

图5 EBS 门禁Top15不稳定Case通过率

在测试左移的实践落地过程中会遇到很多挑战,知行合一很难,整个团队遵守相同的标准规范落地更难。块存储系统有百万行代码,在近一年中生产代码行数增加约20%,测试代码行增加约100%,近万个门禁Case,持续治理不稳定Case,门禁通过率从4.7%提升至70%,后续计划通过精准测试来进一步提升门禁通过率。

仰望天空,并脚踏实地。在测试左移的编码实践方面推荐学习TDD(Test-Driven Development),在《软件测试》《Google :Building Secure & Reliable Systems》《重构》 《重构与模式》《敏捷软件开发》《程序员的职业素养》……国外泰斗级程序员大叔的书里,全部都推荐了TDD(测试驱动开发)。TDD不是万能药,主要思维模式是,先想清楚系统的行为表现,再下手编码,测试想清楚了,开发的API/系统表现就清晰了,API/函数/方法语义就明确了。如何衡量测试的好坏?好的测试是What,包含Given When Then;差的测试是How,若每次方法/函数修改之后如果必须完全重写测试,或许需要重新考虑测试实现和系统本身的设计结构了。

扩展阅读

[1] 代码门禁

https://devblogs.microsoft.com/bharry/pre-checkin-validation-for-tfs/

[2] RethinkDB:why we failed

https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html

[3] 阿里云首个百万IOPS云盘的背后

[4] 业务覆盖率

https://www.continuousdelivery20.com/blog/ch-code-coverage-best-practices/

[5] Google论文

https://research.google/pubs/pub45794/

[6] 微软论文

http://uploads.pnsqc.org/2016/papers/12.WinningWithFlakyTestAutomation.pdf

图片


本文地址:https://www.6aiq.com/article/1654102727860
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出