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

摘要： 测试环境是研发/测试同窗最经常使用的功能，稳定性直接影响到研发效率，那如何提高测试环境的稳定性？阿里巴巴应用与基础运维平台高级开发工程师张劲，经过阿里内部实践，总结了一套测试环境稳定性提高方法，供你们参考。

点此查看原文：http://click.aliyun.com/m/43287/

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

痛点

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

所以， 测试环境稳定性亟待大幅提高。

如何提高，通过答疑汇总和错误分析，主要集中在两个方面：

已成功申请的资源不可用

测试环境宿主机较差(过保机器)，且虚拟比高，容易发生故障。
宿主机故障时，其上的容器不会被自动迁移，极可能致使再次部署重启时失败。
调度系统巡检会将故障宿主机置为不可调度，因为其上仍有容器，不能下线修复后重用， 形成机器资源愈来愈少。

新申请资源时成功率低

测试环境机器被分为优先级不一样的资源池，资源池间机器资源不共享。
测试环境机器的容量/余量不透明，没有告警，形成因资源不足的调度失败。
由于测试环境与线上环境有很大不一样，资源调度系统以前没有针对测试场景优化， 成功率不高。

目标

容器申请成功率：99.9%

方案

指标数据

从一开始咱们就觉的数据很是重要，没有相关的稳定性数据，那咱们就无的放矢，根据数据咱们就能找到须要优化的点以及持续优化的动力。因此项目开始阶段就作了挺长时间的数据收集工做。

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

已申请容器不可用

容器自动置换

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

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

经过自动置换将故障机腾空，而后下线修复。

新申请容器失败

合理化资源池分配

屏蔽底层系统失败

由于测试环境与线上环境差别很大，通常测试环境使用的机器都是线上淘汰机，同时为了节省预算，每台宿主机的虚拟比都很高，致使在建立和使用容器时都特别容易失败，因此有必要作一个容器buffer池屏蔽掉底层失败对用户的影响。

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

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

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

同时为了最大程度的下降引入buffer池后可能对用户形成的影响，buffer池内加了许多动态开关，用于及时屏蔽某些功能。好比可针对具体应用设置是否须要修改容器主机名，此操做很是耗时，若是不改主机名，则平均不到1秒内会申请成功；若是某个应用不想使用buffer，也可当即屏蔽；若是buffer池自己出现问题，能够快速降级，在整个链路中去掉buffer功能。

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

总结

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

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

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

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

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

展望

虽然通过一系列改造优化后，成功率有了明显的提高，可是依然有不少地方须要完善：

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

除了对之前工做的完善，测试环境依然有许多要作的事情：好比如何提升整个测试环境资源的利用率， 如何减小容器交付耗时(从用户申请到用户可用)，如何推进应用的可调度化等等，但愿可以和你们一块儿探讨。

嘉宾介绍

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

云效粉丝福利：

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

工做地点：杭州、北京、美国

https://job.alibaba.com/zhaop...

2.参与你不知道的《阿里巴巴Java开发手册》背后故事文内活动，赢取签名版《阿里巴巴Java开发手册》，活动即将截止，欲参加从速！

识别如下二维码，阅读更多干货