淘系技术个人页面-阿里云开发者社区

从应届生到测试顶会讲师，他只用了一年时间！

作者|豆豆、定源都说憋大招需要时间的积累，一位刚踏出校园入职阿里巴巴淘系技术质量才一年多的新同学，凭什么登上测试行业最高讲台之一的MTSC大会主会场做分享？他是怎么做到的？让我们来看看他的成长故事吧。 ▐ 自我介绍大家好，我叫黄俊，阿里花名豆豆。从毕业那刻起变加入了阿里巴巴淘系技术质量团队，有幸加入到团队AI智能化测试方向的研究探索中。经过这一年多的成长，从对业务的融入、理解、思考，到质量建设上的构思、试错、突破，我受益良多。感谢于良师益友的老板指导，还有一对一师兄的辅导，更有一群志同道合的同学一起并肩作战，与善人居，如入芝兰之室，久而不闻其香，超nice的团队决定了我的现在。对于即将毕业或者想来阿里做测试开发行业的新同学，如果你还在迷茫或者有疑问，不妨继续往下看看我的心路历程：初入职场的迷茫主动出击，找到切入点下钻深入思考聚焦并落地拿结果 ▐ 初入职场，偶遇丝迷茫还记得你的第一个测试开发场景吗？这里附上我的第一个需求&质量建设：新人时期，我的第一个接手需求是手淘消息的搜索（如上图所示）；第一次完整走完流程的需求是手淘消息的智能push，包含了评审、排期、开发、联调、提测、测试、灰度、bugfix、全量等等；第一个质量保障工具是手淘消息客户端日志的上报。总的来说，我的新人时期，在不断学习识别业务需求的过程中，时刻洞察质量建设突破点，逐渐完成了从学生到职场的转变。不过随着业务的深入，虽然可以在相关业务上独当一面，但是如何找到测试技术和业务结合的切入点？我不禁陷入了迷茫。现在回头来看，这应该是很多测试开发的新人都会遇到的一个问题。好在这一时期并没有太长，之后我开始多和师兄、主管、团队老同学的交流，主动走出去和不同部门的同学交流，阿里真的是一个很大的舞台，高手如林，我的眼界和思维被迅速打开，经过和师兄以及主管的反复对焦，我开始逐渐找到适合自己的场景。 ▐ 主动出击，寻找点切入在经过一段时间的适应和转变后，自身对整体消息场景已经有了一定的基础见解，对切入点的感觉开始变得懵懵懂懂，渴望着将一些新的技术融入于现有的业务场景，便踏上了寻找可以将想法落地的场景之路。 19年的春季，正值手淘消息全链路监控排查体系之际打造如火如荼之际，也是我第一次接触测试右移的道路，在和消息测试团队的师兄师姐们一起研发的同时，逐步开始沉淀通用能力，例如诸多系统间错综复杂的链路如何秒级定位能力、统一降级、统一采样等等。随后在团队重点研究的AIOps领域，确定了多个研究方向，而其中的“智能异常检测”方向，在当时还是新兴领域，集团还没有特别好的解决方案，而异常检测本身其实是实际业务中的一项关键性需求。在Devops领域，指标监控是系统稳定性的关键，也是监控/运维平台成功的关键，成功的异常检测有助于发现异常后及时提醒用户采取相应的措施，避免更大故障的发生。通过对国内外现状展开调研，并与达摩院同事进行了交流与合作，对智能异常检测行业现状的了解和摸底，我们的研究内容开始逐步有了线索。虽然这个任务技术挑战很大，也没有太多可以参考的先例，但是我觉得可以发挥我有算法基础喜欢技术钻研的优势，便义无反顾地ALL in到这个任务的研究探索中，并且在过程中我发现自己找到了技术和业务结合可以落地的切入点。找到切入点并不容易，结合对阿里“六脉神剑”价值观的践行，阶段性总结一下有以下几个方面的成长： 1、经济基础决定上层建筑，业务理解决定质量建设。 2、不要怕折腾，多沟通，少情绪，有耐心。 3、Keep Learning，不为失败找借口，只为成功找方法，全力以赴拿结果。 ▐ 深入思考，聚集智能化监控在测试右移智能化的道路上，逐步找到切入点后，便开始在这个领域深入研究。如果将一个产品的上线一分为二，左移是往测试之前的开发阶段移，右移则是往上线之后移，这就要求测试开发同学需要做好指标监控。指标的监控关乎稳定性，但随着数据量的增加，加上指标的复杂周期性和模式变化的动态性，基于传统监控的阈值/同比环比的规则难以适用，而且复杂的领域知识导致为每条指标配置相应的规则费时费力，无法应用在大规模数据监控上。在很多时候，给我的感触是，右移比左移更具有挑战性。因此，我们迫切希望传统监控向智能化监控进行转型，基于团队前期对海量系统日志数据实时计算的基础上，我通过结合百余种实时数据，尝试了20多种异常检测算法，一个全新的智能化异常检测平台呼之欲出。然而聚焦和深入到智能异常检测方向的研究并非一帆风顺，中间经历了不少曲折克服了不少困难，比如：场景1、在面临百余种数据类型时，当现有的业务数据跑出一个还不错的模型，而换在另外一种业务数据效果就大打折扣，如何保障这么多数据类型都有一个不错的效果？解决思路：随着基于对业务数据的深入理解，基于团队前期对海量系统日志数据实时计算的基础上，结合百余种实时数据，尝试了20多种异常检测算，逐渐探索出对于业务数据的算法场景化能力。场景2、当面临大量业务指标的接入，或者是一个全新场景，没有那么多时间来训练拟合该指标的模型，如何保障业务可以顺利地快速接入使用？解决思路：提前将场景化的基础模型作为快速接入的选项，并结合无监督学习，配合完成新指标的接入使用，随后再进行逐步迭代，以适应新指标的快速接入。场景3、当在实时检测有了一定的沉淀能力后，越来越多的业务方反馈，Holmes的报警能不能再提前一点？解决思路：真实的业务现状使我们体会到单有检测能力是远远不够的，晚一分钟发现问题，往往也是致命的，致使我们踏上了预测的研究道路。经过不懈的努力，智能化异常检测平台（Holmes）终于落地，并且在淘系核心战役巴拿马项目上线以及双十一大促备战的过程中发挥了作用。下面就展开简单介绍一下这个平台： ▐ 聚焦落地，福尔摩斯（Holmes）-- 淘系智能化监控平台 Holmes是一款智能化、轻量级、易接入、可扩展的异常检测平台，使用基于AI的异常检测算法，替代传统的规则监控方案。解决规则告警系统准确率低、时效性低、规则配置复杂与耗费人力等诸多问题。特点：学习历史数据，分析当前指标曲线趋势是否异常基于以往数据，进行预测未来指标走势优势：算法检测代替规则检测告警准确率高更早发现异常情况可适应业务发展带来的趋势变化解决的异常场景： MSTC大会-主会场分享基于Holmes的落地，我和师兄董福铭（吾铭）一起在MTSC 2020大会申报了议题《手淘AIOPS实战-消息全链路智能监控》，结合Holmes平台的实战做经验分享。介绍如何通过SDK实现应用内链路日志聚合、采样率控制、统一降级开关等功能，打通客户端到服务端链路，实现IM端到端秒级排查。通过实时计算实现消息核心指标到达率/时延的实时监控。使用AI检测算法，替代传统的规则监控方案，解决规则告警准确率低、时效性低、规则配置复杂与耗费人力等诸多问题。通过NLP进行舆情智能分类，并结合全链路数据对预警问题进行分析定位，打造全链路智能监控排查平台。 ▐ Holmes异常检测平台配置化指标接入流程通过4步简单配置进行指标的接入和算法选择，轻松开启智能异常检测。基本算法概览机器学习上有一个定理，叫没有免费午餐定理(No Free Lunch,NFL)，表示的是在机器学习上，不存在一种通用的最优的算法可以解决所有问题，因此在面对各类数据时，Holmes将算法场景化。在实时检测方面，集成了无监督学习和有监督学习，主要运用了高斯分布、STL、孤立森林、XGBoost等；在数据预测方面，集成了LSTM、Prophet、三次指数平滑等。实践效果目前Holmes异常检测平台已经在集团内部开放接入和运行，支持集团内常用数据源，帮助接入业务方的开发测试同学构建智能监控体系，减少繁琐的规则配置，有效提高了线上质量监控的覆盖率。今年的多次大促期间，Holmes的准确性方面也进一步得到验证，有效保障了大促的稳定性质量。覆盖应用：淘宝、千牛、优酷、钉钉、淘宝直播、闲鱼等接入指标：核心业务指标 300+ 提前预警：有效提前预警线上问题 50+ 算法调用：5000W+ 展望 Holmes异常检测平台是淘系技术质量团队打造，在智能化测试领域的一次实践，未来我们希望利用AI算法实现业务全方位智能化监控和问题定位。覆盖更多的数据类型，打造通用的算法模型，同时我们也在全链路监控排查、智能舆情处理等多方面进行探索，期待后续跟大家分享。 ▐ 主管点评豆豆同学19年4月份硕士毕业后，加入阿里巴巴淘系技术质量团队，仅仅通过一年多的时间就成长为团队技术骨干之一。针对豆豆同学的特点，以及团队将19年的整体打法做了分解，将团队AIOps领域探索的智能化异常检测（智能化监控中的重要组成部分）安排给豆豆。对他有两个期望：一方面期望这个能力可以有纵深的下钻，作为整个IM消息测试中台中测试右移的主要武器之一。另一方面也期望可以横向扩展，未来逐步在阿里集团内进行推广使用。作为主管也明白这个技术探索对新人来说有一定的落地风险，当时并没有太多可以参考的先例，而且对同学的AI算法能力和工程化落地能力均有很大的挑战。这也是豆豆加入淘系技术质量团队后的第一个测试技术创新开发任务。面对压力和挑战，我们很欣喜地发现，豆豆同学并没有被压垮。他迎难而上，查阅了大量业界和阿里集团的资料，调研开源算法、阅读论文，结合师兄吾铭的指导和消息测试团队的反复讨论，豆豆不断优化和完善技术方案，先后克服了多项技术难题。最终Holmes智能异常检测平台在手淘消息场景落地使用，为第一年阿里生涯交出一份漂亮的答卷。新财年，豆豆继续发力，不仅扩大了算法支持的场景个数、准确率，还多次提前预警线上问题，并将支持的业务系统从淘系扩大到了阿里集团多个BU，受到广泛好评。对于豆豆来说，精彩才刚刚开始，Holmes的落地只是一个起点。今年双十一之后，一个新的保密技术创新项目又开始酝酿，豆豆同学届时又会憋一个什么样的大招？让我们拭目以待！这里也简单展开一下，新同学除了学习基本功之外，新同学也可以在师兄和主管的引导下，逐步养成思考的好习惯。比如，如何让自己和团队产生更多的链接（多看多沟通多思考）？如何与所在团队的大方向结合（埋头干活的同时也抬头看路）？如何站在团队研究基础之上进一步构建自己的创新产品（借力）？等等，我觉得是新同学们可以思考方式上去做一些转变的。豆豆同学只是整个淘系技术质量团队（极测）中的一位典型代表，这样优秀的新同学在我们部门还有很多。我们有非常体系化的极测新人培训课程，以及阿里非常著名的“百阿”新人培训，淘系技术质量团队（极测）会针对每一位入职的新人安排一对一的师兄指导，也会针对同学的特点设计和规划职业发展方向。在部门技术驱动的理念下，不仅会对同学的业务理解培养，同时还会在技术创新上给予同学相应的发力场景和落地辅导。结合上一对一师兄和主管在日常工作、生活中对具体的问题和项目实战中的点滴进行具体指导，相信新加入的同学们一定也会像豆豆一样快速成长！ MTSC2020中国互联网测试开发大会深圳站现场淘系技术部-（极测）质量团队-诚招英才我们负责所有淘系业务的质量保障。在这里：可以经历双十一等超大并发场景；可以接触到全链路压测、海量的数据处理、人工智能推荐算法等领域；可以学习到业界最前沿的测试技术、一对一指导的师兄辅导机制、定期而丰富的技术分享；还可以与层层选拔的各路优秀同学共同战斗，共同成长！我们以技术驱动，构建业界领先的质量体系。我们的使命是让测试更简单，让研发更高效，让用户体验更极致。还在等什么，快来加入我们吧！AI智能化测试新赛道，你就是下一个明日之星!邮件发送至：dingyuan.jh@alibaba-inc.com

首次面向B端展开全链路压测！淘系高难度压测实践方案公开

背景 “今年的双11是全球极大内容电商场的超级爆发，消费者、技术、内容与商业生态之间每一秒都在产生激烈共振，实时性、复杂性和持续峰值的叠加令其成为全球技术顶峰。2020年双11，阿里巴巴峰值交易达到了58.3万笔/秒，其背后的商家链路也承受着史无前例的压力”阿里巴巴副总裁汤兴如此描述今年的双11。阿里商家业务域涉及集团近20条业务线，100多个场景，400+链路，部分业务深度融入在导购、交易链路中。商家链路业务涵盖淘系的上千万商家及数百家核心三方服务商的伙伴。以往由于平台和商家IT基础设施存在“水位差”，平台很难帮助商家进行系统的改造升级和全链路验收。随着阿里面向商家与生态伙伴推出了新一代数字化基建体系，借助云原生技术引擎与云IT治理能力，帮助商家与生态伙伴重构系统的高可用基线，使得越来越多的商家具备了和阿里同等量级的超大规模数据处理能力。常规备战中各个业务依靠单链路压测，缺少互通联动，缺少全局把控，容易有质量盲点，隐患容易被忽视，风险较高。商家链路出现问题，直接影响商家生产经营能力，对商家和消费者造成重大的体验伤害。业内的全链路压测普遍面向C端场景，B端场景往往重视度不够。商家端的场景结构极其庞杂，涉及内部系统还涉及众多三方系统，开展全链路压测面临着诸多挑战。为有效预防风险，提升各个业务以及三方合作伙伴系统稳定性，提升用户体验，今年我们克服了重重困难首次面向商家链路开展了全链路压测。挑战 ▐ 核心难点商家业务涵盖商家工具、消息、多媒体、算法等多种业务形态，各应用间调用错综复杂，如何理清核心链路的依赖，保障核心链路不遗漏是开展压测的首要挑战。压测实施上，如何模拟数百个场景流量的叠加耦合，并留好应对突发情况的操作空间，且在同一时间批量将流量拉到峰值是压测执行的一大挑战。商家业务涉及众多合作伙伴服务商的系统，阿里生态的复杂性，使得接入阿里平台的服务商系统架构存在异构化、多样化、性能差异大等多方面技术挑战，每个服务商对于稳定性的认知存在差异。 ▐ 解决方案针对上述挑战，我们的核心解决方案为：统一流程规范标准、压测组织协同、统一验收复盘。工具支撑压测一体化。压测涵盖预案、限流、演练、监控等内容，模拟大促真实情况。全链路压测方案 1、统一流程规范各个业务参与全链路压测明确准入准出标准。全链路压测的基本准入原则：每个场景单链路压测通过后才能进入全链路压测。准出标准包括：系统水位、流量比例、响应时间、缓存命中率、限流、jvm指标等。服务商系统与阿里系统标准一致。流程上统一进行场景review、链路评审、全链路压测以及复盘，复盘中的问题同步优化解决。 2、工具支撑一体化在集团已有的压测能力基础上，我们重点在商家链路分析，流量评估，压测模型、结果校验自动化等方面建设一站式压测工具，解决商家全链路压测的核心问题。链路分析压测场景选取的基本原则：大流量场景核心链路场景复杂业务链路场景流量扩散场景。参照以上原则，在我们在集团中间件支持的基础上，开发了链路分析场景推荐工具，用人工+工具check双保险的方式进行链路模型生成。示意原理如下图，应用A某接口的一次调用，我们可以获取其下游应用的trace，访问的数据库或者缓存，并且分析出1次调用对下游流量的放大。链路示意图其工作流程如下：统计流量调用的服务，存储等指标，获取对下游的调用次数，得到对下游请求的放大。获取流量大于某阈值的入口链路。获取调用链路深度或者依赖调用大于某阈值的链路。获取翻倍调用大于某阈值的链路。流量评估常规流量评估通常是根据监控和上游调用来评估接口流量，评估比较理想化，容易产生误差。如果前期流量预估不充分，会导致压测无法达到目标或远超目标值，靠压测来发现这些问题成本太高。对此我们引入了深度机器学习，利用算法能力来做智能预测，更加精确的进行流量评估。其主要的工作原理如下: 抓取应用的出入口流量、RT、QPS、错误率、应用系统水位等信息。应用深度机器学习，对基础数据进行分析学习，产生该应用的算法模型。该模型可以根据入口流量，预估出口流量、应用系统水位等信息。效果如图所示。接口流量模拟对比图其核心思想为: 算法每天根据线上真实数据持续学习，持续优化，生成可靠模型。用户输入接口预估流量，平台输出预估的下游接口流量、存储QPS、机器数和系统水位等信息。模型构建结合业务场景，我们建立了两种压测模型：0点模型和非0点模型。0点模型涉及场景在大促0点流量达到峰值，非0点模型场景峰值则在其他时间达到峰值，压测模型的设计不是简单的覆盖业务，还需要考虑各个业务之间的流量耦合。有上下游关系的链路，下游的压测流量也是来自上游。除了考虑商家域内的流量耦合，还要考虑集团其他域的流量耦合。因此，与之配合的还有非常多的压测预案，用以控制压测流量的准入准出。有流量的耦合就要考虑耦合流量不足的情况，不是每次压测上游都会有充足流量打到下游。在保障能够耦合上游流量的同时，下游业务自身还要具备流量补充能力，当来自上游的流量不足时，自身可以补充足够的流量，满足自身系统的验证。 3、压测执行压测数据准备采用淘系技术质量部自研凤凰平台[见附1]录制线上流量做“平移”，场景数据更加真实有效。录制化也提升了数据准备的效率，一次录制多次使用。场景管理上做到了1人1键执行所有的场景，极大的节约人力。每次全链路压测商家和交易、导购都会同步开展，0点流量全部打到100%，以验证跨业务域的流量依赖和叠加的情况。从压测开始到流量拉到100%时间非常有限，在压测初期，这个过程中通常会伴随着⾮常多的问题。这些问题在前期准备过程中很难发现，主要问题有以下⼏类：压⼒分布不均。模型紧急调整。数据⽂件紧急修正。个别压测机异常。受压测管控影响，服务调⽤受限。压测任务紧急管控。执行⼈员需要⼀边控制不受影响的业务继续按计划加压，同时需要迅速对出现的问题作出判断，给出解决方案。对于能够快速修正的场景，⾸先将其从压测活动中单独摘掉，调整完成后重新关联到压测任务中。对于⽆法快速修正的场景，要迅速协调业务同学进⾏单链路操作。受上述问题影响，现场需要制定不同的应对策略，主要包括以下几种情况：压测过程中某个场景需要紧急卸载压⼒，其他场景保持。压测过程中某个场景没有达到⽬标，但系统资源已经出现瓶颈，需要保持压⼒⽔位排查问题，其余业务继续加压。压⼒拉到100%个别业务没达到预期需要继续增加压⼒。这⼏类问题在前期压测过程中出现频率⾮常⾼，如果前期准备不到位会阻塞压测节奏。此外全链路压测具备从客户端（成功率、错误量、舆情等）到服务器（接口成功率、中间件成功率、水位等）的完整监控体系，避免出现只关注到服务可用性而忽视客户端及用户实际体验受损的盲区。在数百个商家全链路压测场景中，消息、开放、小程序是几个典型的非常规压测场景，压测实施难度大，接下来重点介绍一下这几个场景的全链路压测实践。 ▐ 核心场景1: IM消息体系的端到端全链路压测传统服务端压测通常是http或者tcp类型的短链接压测，也就是客户端请求一次，拿到返回后，连接就关闭了。但是这种方式并不适用于IM消息系统的压测，IM的系统与服务端建立的是长连接，用户A发送消息给用户B的时候，用户B是被动收到服务器的推送，而不是主动拉取数据，这个模式对压测的实施非常有挑战。为了解决这个问题，我们基于NIO开发了手淘和千牛的瘦客户端，模拟真实用户与服务端保持长连接在服务端，并将部分业务逻辑做了参数化，集成到了瘦客户端中。比如瘦客户端在收到消息推送后，回复ACK，表示收到了消息，并且根据已读比例对该消息进行已读设置。长连接瘦客户端消息链路压测需要模拟客户端登录后保持长连接，目前业内常规压测工具对消息场景都不适用，需要独立开发工具。核心方案如下：开发瘦客户端集成到压测引擎中模拟端到端的场景模拟消息回复模拟消息已阅读模拟消息漫游压测引擎部署到CDN节点上模拟真实用户收发消息创建长连接模拟用户真实保持长连接在线长连接压测架构图全链路消息业务打通消息全链路除了包含消息上下行，消息已读未读，消息内容模型（文本、卡片、多媒体消息），消息漫游等基础消息业务，也在集团二方和合作伙伴三方中衍生出了如机器人智能辅助、订单核对，修改地址，智能客服等消息业务。消息业务图由于消息业务的复杂性，导致我们在压测的时候需要协调各个业务方的压测数据，来调整实际压测时各业务方的压力。例如某个账号开通了A业务也开通了B业务，发送给该账号的消息走到了两个业务，导致流量叠加，最后的压测结果不准确。为了解决这一问题，我们统一收口了消息业务压测脚本，通过统一分配账号，通过统一开通业务，统一发起流量等方法，解决了流量叠加互相干扰以及各业务线脚本无法复用等一系列问题。 ▐ 核心场景2: 三方服务商全链路压测淘系电商业务是一个覆盖消费者、平台、商家、三方服务商的生态链路。借助平台开放的接口，三方服务商可以开发出客户管理、订单管理、互动营销等方向的电商支持工具，帮助商家提升运营效率。要实现商家全链路保障，就需要驱动并赋能三方服务商一起参与到全链路压测中来。淘系电商生态交互图订单推送全链路压测在涉及三方的众多场景中最核心的是订单场景，订单推送全链路覆盖了消费者在淘宝下单后到收到货物的整个过程。链路涵盖多个内外部系统，直接关系到消费者的购物体验，压测重要性不言而喻。订单推送全链路交互图订单推送全链路压测面临以下痛点：服务商数量众多，没有统一的压测工具。压测订单模型构造难度大、准确性差压测结果收集困难，数据分析工作量大、标准不统一。为此我们开发了订单推送全链路压测平台赋能服务商，平台具有以下特点：基于历史订单数据一键生成压测模型，方便、精准用户只需指定历史订单的起止时间，系统会自动分析该时间段内的线上订单数据，并根据订单的买家、优惠、商品等信息模拟生成压测订单模型。订单推送压测模型压测结果数据自动收集、分析，全面、直观工具会自动从监控数据中收集相关压测指标，在报告分析阶段跟历史数据进行比对、根据压测标准计算出压测质量分、产出压测结论、给出优化建议。订单推送压测报告生成示意图支持Service Mesh技术，生产环境压测更简单、安全压测平台支持云原生的Service Mesh技术，对于生产环境压测改造只需修改POD节点的相关配置，无需对系统业务代码进行改造，大大降低生产环境压测成本，同时减少代码改造可能带来的安全风险 ▐ 核心场景3:三方小程序压测小程序是淘系在APP端开放的重要形式，由于三方小程序集成在手淘、千牛等淘系APP中，其稳定性关系到淘系APP的稳定和用户体验。受技术和安全上的限制，三方服务商无法自主对小程序接口进行线上压测，为此我们开发了小程序压测平台为服务商伙伴们提供高效、易用的官方压测工具。三方小程序压测平台使用简单、易上手、自动化程度高，大大降低了技术门槛和服务商的压测成本，其核心能力如下：系统根据线上接口流量自动分析、创建、下发压测任务。服务商只需编辑压测参数，执行压测任务即可。压测通过并提交报告后，系统会根据压测流量值设定限流保护值。三方小程序压测流程图此外，我们还组织了头部核心服务商联合预演。通过全链路压测，模拟业务峰值流量，演练了各种应急预案和沟通机制，以应对大促中可能出现的异常和突发状况，形成了压测、封网、预演的完整保障链路：在全链路压测的同时对核心三方小程序进行压测，模拟更真实的双十一环境。在压测的同时进行异常情况演练：人工模拟引入问题、故障。对问题、故障进行紧急处理，演练沟通、协同机制和应急处理流程。总结全链路压测期间总计发现130+内部系统问题，大促前所有问题都得到了有效解决。整个大促期间商家业务系统0故障、商家问题反馈较往年降低了50%，商家以及消费者感受到了如丝般顺滑，捍卫了商家利益与体验。一百多家核心的ISV参与了全链路压测验收，全链路压测帮助商家与生态伙伴重构了系统的高可用基线，使商家在信息处理和数据处理的水平上，和淘宝拉到同一个水位，使得商家具备了和阿里一样的超大规模数据应用能力，帮助商家系统发现并修复上千个性能问题，在效率和能力上大幅度提升商家系统稳定性。未来我们计划将在三个方面持续优化，为商家和合作伙伴提供更优质的服务： 1、基于算法能力的智能化压测。 2、场景、预案、限流、压测结果等全方位的自动化分析。 3、多维度监控、海量告警信息的智能分析定位处理。附1：凤凰生态利用JVM-Sandbox提供的统一底层能力，大家奇思妙想产生模块原子能力生态，提供开放、快速的模块开发、管理、鉴权、部署能力(魔方平台)，通过对模块能力的组合，衍生出录制回放、故障注入、强弱依赖梳理、系统Mock、快速问题定位、测试质量评估等上层产品模块(凤凰平台2.0)，并对各个环节产生的数据、标准能力都开放API和能力，在业务回归、攻防演练、架构治理等领域输出方案，致力于快速、高效的提升系统整体稳定性。开源地址： https://github.com/alibaba/jvm-sandbox-repeater?spm=ata.13261165.0.0.11ee30bfW4qEoF JVM-Sandbox属于基于Instrumentation的动态编织类的AOP框架，通过精心构造了字节码增强逻辑，使得沙箱的模块能在不违反JDK约束情况下实现对目标应用方法的无侵入运行时AOP拦截。开源地址： https://github.com/alibaba/JVM-Sandbox?spm=ata.13261165.0.0.5a094b01By8WRH 淘系技术部-质量团队-诚招英才负责保障整个淘宝和天猫主站的业务质量，在这里有丰富多样的业务场景和技术挑战。在这里你能够了解世界级双十一是如何保障的，面对双十一海量峰值流量，沉淀最具挑战的大促稳定性保障产品，在这里可以为过亿DAU的互动产品保驾护航，感受行业最复杂的营销玩法技术魅力，在这里可以近距离了解目前炙手可热的内容电商，见识李佳琦、薇娅等是怎样成为带货红人，在这里还可以探索大数据驱动下的前线业务和增长策略，在3D、AI、5G等新技术加持下打造一个个电商领域的新赛道。在这里你还会和一群优秀的伙伴共事，这里有对技术的极致追求，使用业界最前沿的研发技术和理念，创新质量保障的方法、工具和平台，提升研发测试效能，不断完善用户体验，以技术驱动，构建业界领先的质量体系。我们的任何一点优化改进都将使数亿用户受益，期待你的加入，欢迎加入我们一起共同打造淘系的技术质量！联系方式：dahai@taobao.com 关注「淘系技术」微信公众号，一个有温度有内容的技术社区~

淘系技术个人页面-阿里云开发者社区

个人介绍

擅长的技术

【年度重磅】阿里淘系全年技术总结黑皮书，1500页免费下载！

2020年末：浅谈阿里前端的多样化

从应届生到测试顶会讲师，他只用了一年时间！

《MNN For Swift》移动端机器学习实战课程发布！

首次面向B端展开全链路压测！淘系高难度压测实践方案公开

【年度重磅】阿里淘系全年技术总结黑皮书，1500页免费下载！

2020年末：浅谈阿里前端的多样化

从应届生到测试顶会讲师，他只用了一年时间！

《MNN For Swift》移动端机器学习实战课程发布！

首次面向B端展开全链路压测！淘系高难度压测实践方案公开

Serverless ：让「前端开发者」走向「应用研发者」

淘系资深技术专家接受InfoQ采访表示：端智能必将成为驱动业务创新的核心推动力

淘宝APP产品升级：首页聚焦转化和运营效率「买家秀」社区升级为 「逛逛」

CDN工作原理及其在淘宝图片业务中的应用

畅销书《深入浅出Vue.js》作者，在阿里淘系6个月的收获成长

设计模式最佳套路2 —— 愉快地使用管道模式

淘宝直播“一猜到底”——移动端实时语音识别技术方案及应用

设计模式最佳套路—— 愉快地使用策略模式

4982亿背后的前端技术—2020天猫双11前端体系大揭秘

阿里巴巴副总裁汤兴：双11电商直播间里的每一秒都是技术人的骄傲

双11技术总指挥汤兴：今年双11是技术和商业的完美共振

做一件有利于所有前端工程师的事儿

5G时代|淘宝直播高画质低延时技术探索

归因组件ACE：订单归类技术解决方案

闲鱼 Weex 页面优化过程详解

【年度重磅】阿里淘系全年技术总结黑皮书，1500页免费下载！

2020年末：浅谈阿里前端的多样化

从应届生到测试顶会讲师，他只用了一年时间！

《MNN For Swift》移动端机器学习实战课程发布！

首次面向B端展开全链路压测！淘系高难度压测实践方案公开

Serverless ：让「前端开发者」走向「应用研发者」

淘系资深技术专家接受InfoQ采访表示：端智能必将成为驱动业务创新的核心推动力

淘宝APP产品升级：首页聚焦转化和运营效率「买家秀」社区升级为 「逛逛」

CDN工作原理及其在淘宝图片业务中的应用

畅销书《深入浅出Vue.js》作者，在阿里淘系6个月的收获成长

设计模式最佳套路2 —— 愉快地使用管道模式

淘宝直播“一猜到底”——移动端实时语音识别技术方案及应用

设计模式最佳套路—— 愉快地使用策略模式

4982亿背后的前端技术—2020天猫双11前端体系大揭秘

阿里巴巴副总裁汤兴：双11电商直播间里的每一秒都是技术人的骄傲

双11技术总指挥汤兴：今年双11是技术和商业的完美共振

做一件有利于所有前端工程师的事儿

5G时代|淘宝直播高画质低延时技术探索

归因组件ACE：订单归类技术解决方案

闲鱼 Weex 页面优化过程详解

淘宝APP产品升级：首页聚焦转化和运营效率「买家秀」社区升级为「逛逛」

淘宝APP产品升级：首页聚焦转化和运营效率「买家秀」社区升级为「逛逛」