大型项目中的质量策略实践:外卖架构升级项目质量的“取”与“舍”

简介: 阿里QA导读:"大中台小前台"的组织和业务体制已经是互联网老生常谈的问题了,外卖场景作为最火热的线上线下场景,日均单量动辄千万量级,想要把交易流量融入到集团统一的中台架构体系中,难度无异于在给高速行驶的汽车换轮胎,对项目组尤其是质量守护同学提出了巨大的挑战,该如何应战?本地生活的雨清同学给大家带来架构升级质量保障的手段和思考,希望对大家有参考价值。

阿里QA导读:"大中台小前台"的组织和业务体制已经是互联网老生常谈的问题了,外卖场景作为最火热的线上线下场景,日均单量动辄千万量级,想要把交易流量融入到集团统一的中台架构体系中,难度无异于在给高速行驶的汽车换轮胎,对项目组尤其是质量守护同学提出了巨大的挑战,该如何应战?本地生活的雨清同学给大家带来架构升级质量保障的手段和思考,希望对大家有参考价值。

引言

     2020年外卖业务经历了大范围的架构升级,将外卖的交易流量融入到集团统一的中台架构体系中,前后耗时半年,参与的技术同学超过了200+,代码量200W+,用例量10000+,从数据上不难看出项目的浩大和紧迫。除此以外,这个半年中,技术团队照常承接业务需求,大部分项目经历了在原有的弹外链路研发上线之后,在切流前在弹内链路追平需求的过程,整个项目过程类似于飞行中切换引擎。一个日均单量几千万级的业务,任何的质量问题都会被放大,都有可能引发重大的故障,因此对于测试团队来说是一个非常大的考验。从另外一个角度来看,深入参与到这么具有挑战的项目的机会是非常少的,在过程中踩过的坑、做过的一些思考也是非常难得的,本文记录了过程中几个真实的场景,通过分析当时的目标、遇到的困难、应对的手段和思考,希望能给大家带来一些有价值的参考。


背景

   架构升级项目的目标是通过技术升级将外卖业务融入到中台体系中,与各个BU充分协作形成合力。项目的范围主要包括了:商品、店铺、导购、营销、交易、支付、结算等多个域,简单来说,就是涉及到交易流程中的各个相关方。

image.png


项目的主要挑战

   这一小节简单说明一下项目过程中遇到的三个主要的挑战,方便大家理解后面的具体场景下的选择。这几个挑战是贯穿整个项目,也是测试过程中的“上下文”。


团队协作

   因为项目而组合起来的几百人的技术团队,来自不同的BU、不同的部门,有各自的工作模式和规范的流程,这带来了最主要的一个困难是,大家对于研发流程的SOP理解不一致,对于提测质量的重视程度也不一致,最终导致了交付质量不合格,对于测试进度的冲击非常大。


任务重、风险高

   就像背景中描述的,项目工程大、时间紧,除此之外,从测试的角度看,质量要求高、保障难度大。一个成熟业务背后的技术升级,必须要保证业务的功能性、可用性、稳定性、安全性等各个方面跟升级前不能有较大的偏差,因此在测试过程需要考虑的东西就会很多;此外,在大流量的背景下,所有的小概率事件(异常场景、极端场景等)都必然会发生,因此对于测试全面性的要求就非常的高。


   非常不幸,正如大部分的大型项目都会遇到的头号风险--进度风险,在这个项目中体现的淋漓尽致:每一个重要的时间节点上,我们都遇到了非常大的质量挑战。

image.png

意外频发

   项目的过程完全应验了墨菲定律,几乎所有可能遇到的状况,最终都成为了意外状况。主要有:环境问题突出、交付质量不及预期、性能问题、仿真延期、以及各类进度风险等。

   其中环境的坑就从头到脚的踩了个遍:从弹外线下环境下线、弹内预发环境没有DB资源,到生产环境的中间件资源到位时间不及预期。其中生产环境的单元DB迟迟不能到位,也曾使我们面临选择:是等资源到位后在发布,还是修改TDDL层通过中心化先发布等到资源到位后再重新改回来?考虑到整体的节奏以及多个BU之间发布的依赖性,最终选择了后者。

image.png

质量保障架构的取舍

  每个项目的质量保障基本都可以划分为四块内容:流程优化,基础建设,线下测试,线上质量,每一块又根据各个团队的实际情况划分为不同的内容,这些内容一旦固定并沉淀下来,就成为测试团队的“工具库”,在后续的项目中可以随取随用。外卖入淘项目给原来的质量保障架构带了非常大的冲击,基本摧毁了整个“工具库”。在项目过程中重建这一套保障架构是非常困难的一件事,简单来说可以概括为三个字:无、难、急。

 

基础质量保障

   本地生活平台的质量保障架构主要内容部分如下图所示,通过“流程优化”来规范人的部分,从而保证过程质量、发布质量;通过“基础建设”来保证测试的“水电煤”--环境、数据、工具;通过“线下测试”来保障新旧功能;通过“线上质量”来保障线上的稳定性。在每次项目迭代过程中,质量架构中大部分的模块是现成的可以直接使用,只有少量需要跟随项目进行部分的更新。

image.png

架构升级项目质量保障

   本期项目中,由于整个外卖平台的架构进行了升级,测试环境、链路、数据、回归体系、工具建设、线上保障等等全部被推翻,导致了整个质量保障体系被击穿。如何在项目过程中重建保障能力,成为了当时最大的一个难点。

无:

  • 无规范的研发流程
  • 无现成的测试环境
  • 无现成的测试数据
  • 无回归体系

难:

  • 测试全面性难以保障
  • 校验的全面性难以保障
  • 核对监控的正确性难以保障

急:

  • 项目周期短,测不完

   分析了以上困难后,我们在项目过程中将保障能力划分为核心保障和基础保障。简单来说,核心保障是保命的,必须要在外灰前建设完毕的;基础保障是不完成,也不会出现大范围的线上问题或者导致项目延期的保障能力,基本都放在了外灰之后进行建设。举个简单的例子,在9月初的时候,稳定性小组的两个子项目寻求测试资源,一个是灰度中心、一个是仿真项目。考虑到灰度中心是决策每一笔交易流量走弹内新链路还是走弹外老链路,如果出错将是“要命”的,所以灰度中心是需要核心保障的,投入了专门的测试人员;仿真项目,本身是作为测试覆盖的补充,在测试人力吃紧、基于经验设计的测试用例还在不断发现bug的前提下,仿真保障的优先级就相对较低,最终没有投入测试人员(在此,感谢稳定性小组同学的理解和支持)。

   图中红色部分都是项目过程中重点投入人员保障的部分;蓝色部分是在核心保障建设完毕后,才投入保障的部分。需要说明的是,蓝色部分并非不重要,而是基于当时的节奏、人力、质量的一种取舍,而每一次取舍都会有相应的收益和代价。基于这样一个质量架构分时段建设的策略,我们在大促前顺利的完成了切流的目标,没有出现重大的线上故障;同时,我们也付出一些的代价,以图中“线下测试“中的“异常场景验证”为例,交易、营销平台都是对于异常处理非常敏感的平台,由于外灰前没有进行充分的异常验证,最终导致这两个平台在灰度期间出现的几十个线上问题中,近一半是异常处理的问题(发生概率低,没有达到P级)。

image.png


   另外值得一提的是,本期项目中引入了“基础建设”下的“数据报表”,并作为了核心保障能力。这是因为,在整个灰度切流过程中,我们需要大量的数据分析来验证线上的真实情况。以“加购到下单的转化率”为指标,灰度期间需要精确分析,小到同一个门店下走新链路的用户转化率和走老链路的用户转化率,是否出现了较大的差异;大到同一个城市下,是否出现转化率的差异等等。此外还有非常多的指标,只有确认每一次增量切流后,各个指标正常,才能计划下一次的切流。简单来说,数据报表是切流的依据,也是“生命线”。

image.png


  总结来说,质量保障体系的建设需要因时、因事而定,需要考虑时间、成本、风险、效果等因素,每一个选择都有它的利弊,没有绝对正确的决策,只有更适合当时情况的选择。个人的一点建议是,平时需要针对所负责的业务梳理出完整的质量保障大图,并深刻理解其中每个质量保障专项的内容、成本和效果,这样在应对大型项目冲击的时候,能快速的理清利弊,筛选出必要的专项。



相关文章
|
2天前
|
监控 Cloud Native 开发者
云原生技术浪潮下的微服务架构实践
云原生技术正引领着现代软件开发的潮流,其中微服务架构作为其核心理念之一,为复杂应用提供了灵活、可扩展的解决方案。本文将探讨在云原生环境下实施微服务架构的策略和挑战,并结合实际案例分析微服务设计的最佳实践,旨在为开发者提供一套可行的微服务部署与管理指南。
|
2天前
|
消息中间件 监控 API
构建微服务架构:从理论到实践的全面指南
本文将深入探讨微服务架构的设计原则、实施步骤和面临的挑战。与传统的单体架构相比,微服务通过其独立性、可伸缩性和灵活性,为现代应用开发提供了新的视角。文章将介绍如何从零开始规划和部署一个微服务系统,包括选择合适的技术栈、处理数据一致性问题以及实现服务间通信。此外,我们还将讨论在迁移至微服务架构过程中可能遇到的技术和组织挑战,以及如何克服这些难题以实现顺利过渡。
|
3天前
|
Java 编译器 Maven
使用intellij idea搭建SSM架构的maven项目 详细
使用intellij idea搭建SSM架构的maven项目 详细
17 4
|
1天前
|
存储 Cloud Native 物联网
数据库技术前沿探索:架构、优化与行业实践
一、引言 在信息化和数字化的浪潮中,数据库技术作为企业核心竞争力的关键要素,其重要性不言而喻
|
1天前
|
前端开发 JavaScript Java
计算机Java项目|基于SSM架构的网上书城系统
计算机Java项目|基于SSM架构的网上书城系统
|
2天前
|
运维 监控 安全
园区网典型组网架构及案例实践
园区网典型组网架构及案例实践
|
3天前
|
Java Maven
使用intellij idea搭建SSM架构的maven项目 配置文件
使用intellij idea搭建SSM架构的maven项目 配置文件
12 0
|
3天前
|
负载均衡 搜索推荐 应用服务中间件
后端开发中的微服务架构设计与实践
传统的单一应用架构已经无法满足当今快速变化的业务需求,微服务架构因其灵活性和扩展性逐渐成为后端开发的主流选择。本文将探讨微服务架构设计与实践,包括微服务架构的概念、优势以及在后端开发中的应用。同时,将结合实际案例分析微服务架构的设计原则和最佳实践,以帮助开发者更好地理解和应用微服务架构。
|
3天前
|
负载均衡 监控 应用服务中间件
微服务架构下的API网关设计与实践
【6月更文挑战第11天】在现代软件开发中,微服务架构因其灵活性和可扩展性而受到青睐。作为微服务系统的入口,API网关承担着请求路由、负载均衡、安全认证等关键职责。本文将深入探讨API网关的设计要点与实践策略,旨在为读者提供构建高效、稳定API网关的实用指南。
|
4天前
|
监控 Cloud Native 持续交付
云原生架构:从理念到实践的全面解析
云原生架构已经成为现代软件开发和部署的核心理念。它不仅改变了传统的软件开发模式,还为企业提供了更高的灵活性、可扩展性和可靠性。本篇文章将深入探讨云原生架构的基本概念、关键组件以及实际应用案例,帮助读者更好地理解和应用这一先进的技术框架。
24 3