公司域名更改 网站怎么做提示,用wordpress制作表单,无锡锡山网站建设,新乡网站开发摘要#xff1a; 测试环境是研发/测试同学最常用的功能#xff0c;稳定性直接影响到研发效率#xff0c;那如何提升测试环境的稳定性#xff1f;阿里巴巴应用与基础运维平台高级开发工程师张劲#xff0c;通过阿里内部实践#xff0c;总结了一套测试环境稳定性提升方法 测试环境是研发/测试同学最常用的功能稳定性直接影响到研发效率那如何提升测试环境的稳定性阿里巴巴应用与基础运维平台高级开发工程师张劲通过阿里内部实践总结了一套测试环境稳定性提升方法供大家参考。
点此查看原文http://click.aliyun.com/m/43443/ 导读测试环境是研发/测试同学最常用的功能稳定性直接影响到研发效率那如何提升测试环境的稳定性阿里巴巴应用与基础运维平台高级开发工程师张劲通过阿里内部实践总结了一套测试环境稳定性提升方法供大家参考。痛点每一次容器申请失败直接造成研发测试停滞 同时带来答疑及问题排查(程序猿最怕的就是在代码写得正嗨的时候被人给打断所以一般我都带耳机)涉及到测试链路上各个系统。随着集团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/zhaopin/job_detail.htm?refNoGP0421392.参与你不知道的《阿里巴巴Java开发手册》背后故事文内活动赢取签名版《阿里巴巴Java开发手册》活动即将截止欲参加从速识别以下二维码干货
