阿里巴巴测试环境稳定性提升实践

简介: 测试环境是研发/测试同学最常用的功能,稳定性直接影响到研发效率,那如何提升测试环境的稳定性?阿里巴巴应用与基础运维平台高级开发工程师张劲,通过阿里内部实践,总结了一套测试环境稳定性提升方法,供大家参考。
974713679d5fc7d1263f5038169b3d6461fec5e4
扫码或点我直达 免费领 

导读:测试环境是研发/测试同学最常用的功能,稳定性直接影响到研发效率,那如何提升测试环境的稳定性?阿里巴巴应用与基础运维平台高级开发工程师张劲,通过阿里内部实践,总结了一套测试环境稳定性提升方法,供大家参考。

痛点

每一次容器申请失败直接造成研发测试停滞, 同时带来答疑及问题排查(程序猿最怕的就是在代码写得正嗨的时候被人给打断,所以一般我都带耳机),涉及到测试链路上各个系统。随着集团pouch化的全面推进,半年来测试环境日容器申请量暴增10倍以上,低成功率导致研发低效的问题越来越凸显,每天累计造成集团上百小时的研发测试停滞,损失不可接受,也渐渐成为了pouch化推进过程中的一个阻力。

因此, 测试环境稳定性亟待大幅提升。

如何提升,经过答疑汇总和错误分析,主要集中在两个方面:

已成功申请的资源不可用
  • 测试环境宿主机较差(过保机器),且虚拟比高,容易发生故障。
  • 宿主机故障时,其上的容器不会被自动迁移,很可能导致再次部署重启时失败。
  • 调度系统巡检会将故障宿主机置为不可调度,由于其上仍有容器,不能下线修复后重用, 造成机器资源越来越少。
新申请资源时成功率低
  • 测试环境机器被分为优先级不同的资源池,资源池间机器资源不共享。
  • 测试环境机器的容量/余量不透明,没有告警,造成因资源不足的调度失败。
  • 因为测试环境与线上环境有很大不同,资源调度系统之前没有针对测试场景优化, 成功率不高。

目标

容器申请成功率:99.9%

方案

e76d30e81a2979f5ca63b086eb0b433ddd37a873

指标数据

从一开始我们就觉的数据非常重要,没有相关的稳定性数据,那我们就无的放矢,根据数据我们就能找到需要优化的点以及持续优化的动力。所以项目开始阶段就做了挺长时间的数据收集工作。

  • 测试环境链路数据收集:从上至下包括Normandy(基础应用运维平台),黄蜂(资源申请平台),Zeus(二层调度),Sigma(集团资源调度系统);其中我们最关心的就是最终容器交付的成功率,以及失败case。失败case可以帮助我们分析整个系统中到底哪些地方存在问题,成功率趋势则帮助我们检验新的修复优化是否真的有效且稳定,也是最终成果的衡量指标。、
  • 测试环境链路稳定性数据展示平台:其实上下游的每个系统都有自己的数据,但是没有整合,有的用阿里表哥,有的是发邮件,有的则没有展示出来,所以做这样一个小东西的目的就是将上下游系统的数据统一整合在一个页面上,更便于查看分析问题。
  • 每日/周/月错误分析:收集每天的错误数量及样例,便于分析问题。

已申请容器不可用

容器自动置换

容器自动置换是为了解决已申请的容器不可用问题,简单来说就是在另一台好的宿主机上扩一个新容器,然后将原来在故障宿主机上的旧容器下线。

整个流程如下:Sigma(资源调度系统)自动巡检出故障宿主机(比如磁盘满/硬件故障等),通知Atom(故障机替换)置换该故障宿主机上容器,Atom向Normandy(基础应用运维平台)发起机器置换流程。

通过自动置换将故障机腾空,然后下线修复。

新申请容器失败

合理化资源池分配

56fd916ea9532420e19fb0c78e01ca95d71914b7


d12e630f741cb70768e8924004c3944a42db2739

屏蔽底层系统失败

因为测试环境与线上环境差异很大,一般测试环境使用的机器都是线上淘汰机,同时为了节省预算,每台宿主机的虚拟比都很高,导致在创建和使用容器时都特别容易失败,所以有必要做一个容器buffer池屏蔽掉底层失败对用户的影响。

buffer池的整个逻辑非常简单清晰:在测试环境容器生产链路靠近用户的一端嵌入buffer池,预生产一批容器,在用户需要的时候分配给他。即使申请buffer容器失败,依然可以按原生产链路继续生产容器。每次从buffer池申请一个容器后,buffer池会自动异步补充一个相同规格的容器进来,以维持buffer池的容量。

如何确定buffer哪些规格的容器及池子的容量是另一个关键点:需要统计每种规格-镜像-资源池的历史申请量,按比例分配每种buffer的容量。同时为了保证即使在底层系统中断服务时,整个系统依然对用户可用,还需要确定高峰期的容器申请量,可允许中断时长以及测试环境机器资源, 用来确定整个buffer池子的容量。

还需要考虑的一点是,用户也分为普通用户(研发测试人员),系统用户(比如自动化测试系统等),他们的优先级也不同,需要优先保证普通用户可用。

同时为了最大程度的降低引入buffer池后可能对用户造成的影响,buffer池内加了许多动态开关,用于及时屏蔽某些功能。比如可针对具体应用设置是否需要修改容器主机名,此操作非常耗时,如果不改主机名,则平均不到1秒内会申请成功;如果某个应用不想使用buffer,也可立即屏蔽;如果buffer池本身出现问题,可以快速降级,在整个链路中去掉buffer功能。

另外buffer池在交付buffer容器前会额外做一次检查,判断容器是否可用,避免容器交付后,因为容器不可用而导致的服务部署失败,用户使用不了等问题。buffer池内部也会定期清理脏容器(不可用, 数据不一致等)和补充新的buffer容器。

总结

3244e08ec95162180ed6b4bccef4a122f6a74b10

上图展示测试环境最近2个月的容器申请成功率趋势,包括buffer池全量前后一个月。

从图中可以看到,11月末12月初的两天成功率极低,均是因为调度失败,之后根据资源池余量预测及报警及时调整了各个资源池的容量,提前消除了调度失败的可能,在此之后,成功率波幅都减少很多。

另一点,从buffer全量后,成功率波幅明显比buffer全量前大幅减小,波动次数明显减少,成功率趋于稳定。

buffer池全量后的一周内,由于buffer池内部的bug以及buffer命中率较低,成功率浮动较大,在bug修复以及提高buffer池命中率后,成功率基本稳定。

a9e50be306ae210b2e240dab17fd673e61512de0

上图展示近两个月的每日成功率趋势图,纵向对比了用户视角(有buffer)与底层系统视角(无buffer)。从图中可以看出,buffer池确实屏蔽了许多底层系统失败,除了其中一天buffer池被穿透导致成功率大跌。

展望

虽然经过一系列改造优化后,成功率有了明显的提升,但是依然有很多地方需要完善:

  • 资源池容量自动调配:目前算法简单,有些情况无法解决,比如大规模的新增或删除容器造成对余量趋势的误判。另外也要避免引入自动调配后造成宿主机标签的混乱。
  • buffer池模版动态的增减以及每种buffer的数量动态变化。当前buffer池一个难题就是如何覆盖到低频的应用镜像,这种镜像虽然低频但是容易申请失败,一旦这种容器大量申请,容易穿透buffer池,造成大量失败。
  • 扩大buffer池的容量,需要根据机器资源伸缩。

除了对以前工作的完善,测试环境依然有许多要做的事情:比如如何提高整个测试环境资源的利用率, 如何减少容器交付耗时(从用户申请到用户可用),如何推动应用的可调度化等等,希望能够和大家一起探讨。


嘉宾介绍

张劲(太云),阿里巴巴应用与基础运维平台-产品与架构部高级开发工程师,主要负责测试环境研发和效能提升,喜欢开源。

云效粉丝福利:

1.想要和作者一起共事吗?云效2.0-StarOps智能运维平台-致力于打造具备世界级影响力的智能运维平台,诚聘资深技术/产品专家  

工作地点:杭州、北京、美国







相关文章
|
3天前
|
敏捷开发 数据可视化 Devops
敏捷测试价值观、方法和实践读书笔记(4)
本章节探讨了敏捷测试执行的关键概念与实践。首先介绍了用户故事及其重要性,强调其在敏捷开发中的角色,并阐述了用户故事的 INVEST 原则。接着分析了用户故事生命周期中的测试关注点,包括定义、处理、完成及验收阶段的测试活动。此外,还对比了不同测试术语的差异,并提供了敏捷测试计划的策略与过程。通过看板等工具实现任务管理与跟踪,确保测试活动高效进行。最后,介绍了敏捷测试中的度量指标,帮助团队评估测试效果。
16 5
敏捷测试价值观、方法和实践读书笔记(4)
|
3天前
|
监控 架构师 Devops
敏捷测试价值观、方法和实践读书笔记(3)
本章节介绍敏捷测试转型框架,涵盖模型概览、实施难度与顺序、文化转变、角色技能需求及测试流程。敏捷测试转型模型包括文化、组织、流程与实践等关键要素,并针对各层面提出具体实施建议与障碍解决方案。此外,详细阐述了不同敏捷测试角色的技能需求与职责,以及从Sprint内至跨Sprint的测试流程与交付物。
15 5
敏捷测试价值观、方法和实践读书笔记(3)
|
3天前
|
开发框架 数据可视化 项目管理
敏捷测试价值观、方法和实践读书笔记(1)
敏捷软件开发宣言在身体力行的同时也帮助我们一直在实践中探寻更好的软件开发方法。由此,我们建立了如下价值观:个体和互动 高于 流程和工具工作的软件,高于 详尽的文档客户合作, 高于 合同谈判响应变化,高于 遵循计划。也就是说,尽管右项有其价值,但我们更重视左项的价值。
16 4
敏捷测试价值观、方法和实践读书笔记(1)
|
3天前
|
JavaScript 前端开发 Java
敏捷测试价值观、方法和实践读书笔记(5)
本章节介绍了敏捷功能测试的原则与实践,包括单元测试的概念及其编写步骤,测试驱动开发(TDD)的流程,以及如何通过模拟对象进行测试。详细讲解了单元测试的编写方法,如初始化对象、执行操作及验证结果,并探讨了 TDD 的五个步骤。通过具体案例展示了如何逐步完善储蓄账户的功能测试,包括存款、取款及异常处理。此外,还讨论了代码覆盖率的重要性及其局限性,强调了测试充分性比单纯追求代码覆盖率更为关键。
11 3
敏捷测试价值观、方法和实践读书笔记(5)
|
7天前
|
Web App开发 Java 测试技术
自动化测试的利器:Selenium WebDriver入门与实践
【9月更文挑战第8天】在软件开发的海洋中,测试是确保我们不会溺水的那根救生索。Selenium WebDriver,作为自动化测试的明星工具,让这根救生索更加结实可靠。本文将带你快速上手Selenium WebDriver,从基础设置到实际操作,再到实战演练,让你的开发之旅更加平稳顺畅。
|
4天前
|
JavaScript 前端开发 数据库
数据库测试场景实践总结
本文介绍了数据库超时和应用锁表SSDB测试场景的验证方法,通过锁定数据表模拟写入失败情况,并利用SSDB进行重试。测试需开发人员配合验证功能。同时,提供了SSDB服务器登录、查询队列数量及重启服务等常用命令。适用于验证和解决数据库写入问题。
17 7
|
3天前
|
机器人 测试技术
敏捷测试价值观、方法和实践读书笔记(6)
验收测试驱动开发(ATDD)强调在开发前定义验收标准,并通过自动化测试确保用户价值得到满足。验收测试关注用户需求是否实现,而非代码细节。ATDD涉及用户、产品负责人、开发人员及测试人员,通过讨论、开发和交付三个阶段,确保产品符合预期。此方法有助于团队更好地理解和实现用户需求。
16 5
|
1天前
|
监控 jenkins 测试技术
软件测试中的自动化测试策略与实践
本文将深入探讨自动化测试在软件开发中的重要性及其实施策略。我们将从自动化测试的基本概念入手,分析其在提高软件质量、缩短开发周期和降低维护成本方面的优势。通过具体案例,展示如何有效地规划和执行自动化测试,以及如何评估其效果。
11 1
|
3天前
|
敏捷开发 测试技术
敏捷测试价值观、方法和实践读书笔记(2)
本章节介绍敏捷测试在快速变化的软件开发环境中的重要性。传统测试方法在敏捷环境中面临时间紧迫、文档不足、频繁变更及资源短缺等挑战。敏捷测试遵循敏捷开发原则,强调测试与开发的紧密融合、团队协作及业务价值交付。其特点包括更强的协作、更短的周期、更灵活的计划及高效的自动化。相较于传统测试,敏捷测试具有加快产品上市时间、提升整体质量及简化流程降低成本的优势。
11 3
|
3天前
|
Devops jenkins 测试技术
敏捷测试价值观、方法和实践读书笔记(10)
本文介绍了敏捷测试的延伸实践,重点讨论了持续集成(CI)和持续部署(CD)的概念与实践方法。持续集成强调频繁提交代码至主干并自动化构建测试,确保快速反馈和高质量代码。持续部署则进一步实现自动化部署,通过蓝绿部署、金丝雀发布等方式提升软件交付效率。此外,文章还探讨了持续反馈机制,如A/B测试和混沌工程,以及DevOps文化下的测试策略,强调测试在整个开发流程中的重要性。
10 0
敏捷测试价值观、方法和实践读书笔记(10)