更好的格式排版请看飞书文档:https://ladingkanxue.feishu.cn/docx/AJUmdAwPUohnWJxV0H3cLJd1njh


🔹 期刊内容 🔹

①【变更管控】阿里 - 支付宝统一运营变更核心

源链接:https://mp.weixin.qq.com/s/tcMaqp3TAo1nse5UtIjv4A

小编:支付宝的统一运营变更做得相对体系(文章也写得比较抽象,需要斟酌话术),也沉淀出完整的工程能力和平台,整体会显得比较重,思路上值得借鉴。

质量问题
在数字化转型的过程,业务由粗放式运营演进为精细化运营,支付宝域内逐渐演进出 P2C、P2B、B2C 等各大运营体系。业务的发展也带来了运营平台数量的激增,截止当前,支撑各大运营体系的后台数量已达到 50+,并且为了支撑运营活动快速迭代,各平台采用配置化架构,通过配置免开发的方式供业务小二直接使用。
配置化架构带来高效和便利的同时,也带来技术风险敞口扩大,原因有 3 点:

  1. 传统代码实现需求有完善的研发与质量保障流程,配置化架构的每次操作,没有技术专职投入保障,无法通过 code review,以及线下/线上的测试回归保证正确性;
  2. 配置化平台大多是面向小二内部的产品, 区别于对外部客户的系统,本身产品设计上并没有很高要求,稳定性成熟度低,三板斧机制偏弱;
  3. 配置平台的使用对象是内部运营小二,大多数用户不具备技术风险保障的意识和专业性,且很多新用户不清楚平台的各种概念及规则。

方案介绍
宏观上看,先做变更分层,分为 SaaS 变更、PaaS 变更、IaaS 变更。其中 PaaS 和 Iaas 比较稳定,源自固定平台,变更语义明确,可以通过中心化的标准方案解决;而 SaaS 变更来自不同业务线,需要交有业务线去沉淀。
风险分类上,业务风险上浮,通用风险下沉。通用风险由统一的中台来处理,opscloud 作为风险防御平台对外提供通用防御能力,解决通用基础风险,不同的运营平台中接入 opscloud 来集中防控运营变更风险。
基于 opscloud 这个阵地,下沉五大标准能力:事前的变更分析、规则检查、业务验收;事中的变更推进;事后的问题发现。
同时以开放集成的方式,吸收业务特色的能力到配置防御流程中,解决业务个性化风险。

这里涉及的关键技术下面展开介绍。

数据引擎
将数据语义化分解,转化成可表达、可比较、可配置的规则结构,“数据” 锁描述的类型可以是 DB、GROOVY、HTTP、tr、ODPS(阿里数仓解决方案) 等不同来源的数据,在选择具体的某个节点下的数据,平台可以自动将数据切割为 KV 数据对呈现,提供一些基本的逻辑运算(如是否包含、是否数组包含、正则、数组相等、数据类型等)和诸如 $.comparePositionCrowdCheck[*].failedCnt 等参数化规则来表达防御配置。
数据引擎的作用是将上述处理能力封装并产品化提供,业务方部署场景模型及检测规则全流程,都可以采用配置化的方式,提升业务方部署效能,0 代码编写成本的规则部署能力,重点解决配置的业务语义识别和静态数据检测的问题。

功能验收
数据引擎赋能下,可以将规则可视化出来,从而从配置数据层面保障正确性。
对于部分通过具体数据无法直接判断正确性的场景,如

  1. 场景管理:提供录制回放和智能遍历能力,支持用户编写自动化用例完成定制化的验收
  2. 原子能力:将常用的验收操作步骤封装成 api,如图像能力解决端显内容的识别与断言、mock 产品化能力解决配置数据依赖通路问题等,降低使用成本,提升复用度
  3. 业务场境通路:这是重点内容,针对不同业务场景链路,配置数据的渲染会存在限制,如 UG 活动需要在指定机型、地域、时间等多因素同时满足的情况下才打开入口,现实中非常难以自动验收,需要人工配置成吨白名单。这里通过沉淀多类型的 mock 和 skip 能力,实现提前验收,包括:
  4. 访问限制:时间、空间、员工体系的限制可以被 mock。如活动红包发放时间为一个月后、只有北京市可完成、限定企业员工可访问,通过流量染色和参数篡改,模拟生效条件从而实现端上的透出,解决配置内容透出对时间、空间、人员等依赖
  5. 概率限制:将概率性透出变为 100% 透出。如五福刮刮卡中某个指定奖品验收,通过服务端 mock 产品化将业务配置模型直接组装转换为前端渲染模型,呈现用户,解决概率限制
  6. 任务限制:依赖前置任务完成才可触发透出的场景。如支付后推荐、扫码乘车后的激励等,有些复杂小众的线上线下场景完成成本大,则通过集成不同业务的场景化 mock 能力解决

沉淀通用处理原子能力,如 注入、mock、智能遍历等,解决业务通用的验收基建问题,对不同业务线个性化的问题,通过开放集成引入业务域特色解决方案。
以真机/模拟器渲染为底座,为用户封装供给原子化操作能力,如 mock、多版本/设备管理、OCR、黑白屏检测等原子能力,并为了适配业务玩法对服务端的依赖,通过注入能力的产品化,解决了部分业务配置对时间、空间、概率、人群等条件的限制,更加便于业务专注在验收的产品功能逻辑层。
小编理解:就是业务线自发做了很多业务特性的 mock 能力,最后由平台统一有机地集成在一起,一方面可以 Web 一键配置使用,另一方面也能打通云真机上的自动化任务,实现自动验收自动断言

业务预演
前面提及了两部分,分别是:

  1. 静态规则检测,从配置数据层面保障正确性
  2. 功能验收,从端产品功能层面保障正确性 以上两部分有一个很明显的局限,就是传统的单样本、单流量下验证通过,不能代表具备大流量属性的人群、活动、玩法、中奖概率、区域分布就没有配置问题,所以需要具备业务语言能力来提前看到配置真实生效时的数据分布。 小编理解:静态规则检测&功能验收,更多是服务于调试验证,但是真枪实战还是要看大规模的线上演练 联动蚂蚁技术风险团队的流量海关、仿真团队,共建业务预演能力。

  1. 预演样本采集:为业务预演提供匹配的用户流量,做法上根据历史用户流量提前打好标签,在预演需要的时候就可以按照标签直接筛选出期望命中&期望不命中的流量
  2. 预演执行引擎:创建预演任务,通过触发预演任务执行,捞取对应的流量样本进行分发触发不同业务接口进行预演,支持流程编排以满足不同业务预演需求(部分任务需要依赖其他前置任务预演结果)
  3. 业务回放链路:在近几年蚂蚁仿真环境大修的背景下,业务仿真升级仿真环境方案,减小业务链路的改造成本。在重点解决仿真底盘稳定性(可用率、容量)基础上,在实际落地过程中,遇到了如 TPP 非标应用仿真通路、策略模型线上加载、业务缓存刷新等问题,通过配置化 mock 等方式解决,可参考这里(小编:看不懂原文在说什么)
  4. 预演指标分析:通过对业务预演日志采集、通用人群分层数据分析,产出对应的活动预演结果报表数据,提供给运营进行业务确认。通过配置化指标能力,供给不同业务的接入,自定义规则开放能力,一次预演结果如右图

业务预演总结起来是在配置上线前,通过模拟用户触发参与,下钻分析用户参与后的业务结果数据及提供效果预览,帮助业务在不消耗预算及用户无感知的情况下,发现此类配置的风险,从 “上线前活动效果预估、活动设计错误拦截、配置内容错误拦截” 三个维度,规避活动风险引发的线上故障、大额资损风险、活动效果不及预期的情况。
小编理解:这里的业务预演,大概理解为在用户无感知的情况下完成了一次活动的参与,但是在真实用户的手机上活动是不透出不渲染的,所以用户才会无感知;
这里预演的意义,一方面是通过历史活动中已经沉淀下来的用户标签,去快速筛选到符合预演条件的用户,而不需要真正对线上全流量的用户做一次实时判断筛选下发,节省成本(下发配置也是消耗 cdn 带宽成本);另一方面可以在用户手机上探测有无不符预期的地方,比如运营配置了某张图片,通过预演发现这张图片因格式不正确导致端上渲染报错,就能提前拦截问题

风险机器人
这一部分相对简单,本质上就是将配置带来的质量风险,通过运营人员可以理解的业务语义输出出来,简单来说就是将最终的结果用运营同学能理解的语言输出。一方面是将技术风险做产品化的表达,做好人机交互;另一方面是风险结果输出到不同的运营平台前端,以便加审批/阻断发布流程,或让业务自定义后续处理流程。

智能推导
沉淀了一段时间的风险场景和防御用例后,系统也积累了相当量的配置运行数据。风险规则是基于业务专家经验人工输出的,出现一些局限性:

  1. 业务部门经常是横向推进专项,角色上区分专项 owner 和 业务参与方,如果专项 owner 新增了配置规则但是没同步到业务参与方,就会出现业务参与方漏配规则,出现风险
  2. 规则配置人可能存在知识盲区,导致对风险的理解不全面,从而出现规则漏配的问题 解决方案是,先将复杂的数据拆解为一些基本元数据,再去聚类历史变更数据特征,总结出正则特征以及置信度,从而产出训练模型。最终实现自动生产规则,提供完整的拦截反馈原因。

小编理解:靠人配存在漏配的可能,通过算法总结配置规律,自动地去配置规则(但会不会存在配置过拟合的问题?)

②【精准测试】飞书多维表格-Web 精准测试的研究与业务实践

为避免涉敏,本文章内容不在这里做分享,感兴趣的同学建议考虑一下飞书的 QA 岗位 😁,至少深圳、广州、北京都有~

③【服务压测】B 站压测系列-B 站压测实践之压测平台的演进

源链接:
B 站压测实践之压测平台的演进:https://mp.weixin.qq.com/s/-8flTCyNFDKrnnlHYaVAgw
B 站在全链路压测上的实践:https://mp.weixin.qq.com/s/ScFa571lSemNmoVk25GJjg
bilibili 全链路压测改造之全链自动化测试实践:https://mp.weixin.qq.com/s/9SGqpVO-5knO1COcoZK5Pg

小编:B 站压测实践从原始的手工执行不同团队各自为战,逐渐演化出第一代与第二代的平台化;文章重点介绍 B 站第二代压测平台的各种技术思想,包括压测容器、压测引擎、压测策略、数据隔离等方面展开。
压测平台演进

④【测试策略】阿里 - 测试环境不稳定&复杂的必然性及其对策

源链接:https://mp.weixin.qq.com/s/CEKX8NTN9UQdUm3rDdHnQQ

小编:这是一篇比较深刻的短文,作者的观点是测试环境不稳定的根源在于测试环境里面存在不稳定的代码,以及测试环境不稳定带来的影响小从而出现关注度低,最后作者给出了解决测试环境不稳定的两个思路,分别是兜底稳定的主干环境复用&基于 Mesh 的环境隔离。
质量问题
今天我们研发同学的心智是:当一个同学在测试遇到错误的时候,他的第一反应是 “一定是环境问题”。也就是说,他的第一反应是 “别人的问题”,只有当 “别人的问题” 都排出后他才会认真的去看是不是他自己的问题(包括项目的问题)。来探讨两个问题:

  1. 为什么测试环境的不稳定是必然的,怎么让它尽量稳定一点?
  2. 为什么测试环境比生产环境更复杂,怎么让它尽量简单一点?

观点解析
测试环境不稳定,是必然的。
有的人说线下的容量没有线上大,有的人说线下没有真实用户,有的人说线下缺少生产的真实数据,等等,各种答案都有。在作者看来,首先测试环境和生产环境,它们是两个不同的场景。对于生产环境,准确与稳定性最重要;对于测试环境,隔离、低成本和稳定的依赖最重要。
大家经常吐槽测试环境不稳定,不稳定的原因不外乎如下:

测试环境比生产环境更复杂
生产环境只有一套,链路和应用间的调用关系比较清晰,服务也相对比较稳定,但在测试环境中,因为涉及到多方并行研发,服务间的依赖会变得很复杂,如 A 强依赖于 B,B 变更之后还要保证不影响 A。随着分布式系统的演进,微服务的数量也呈指数级增长,整个系统的复杂度也会随之升级,即使单个微服务很简单,但是交互建立起的系统将成为复杂性的瓶颈。下图举例:

  1. 需要将链路上所有的应用都创建一套环境才能将链路跑通,谁能清楚整条链路上的应用?
  2. 并行开发使得多个节点同时变更,整条链路上的应用在不停变化,问题排查成本如何?那如果只孤立变更节点,其他节点取稳定状态去部署,维护成本如何?
  3. 多套环境,势必会带来并行干扰的问题,如何将请求准确的路由到期望的服务上?
  4. 同一套中间件、数据库等基础设施如何软隔离?

对于这种场景,生产环境(灰度、正式)之间首先存在物理隔离,其次是只需要一套环境即可满足,不存在多套相似的环境并行的问题。

让测试环境稳定与简单的方案

⑤【综合保障】阿里 - 语雀质量体系与自动化

源链接:https://mp.weixin.qq.com/s/r3Q8Ru2i5zZSm8uLEf8IAA

小编:语雀对外称测试开发比 1:20,整体质量保障工作显得麻雀虽小五脏俱全,从质量内建层面的研发规范,到测试左移的端到端自动化,再到持续集成,最后是相对完整的质量管理体系,适合早期快速发展的业务线作为标的来参考。
质量问题
语雀作为一款在线文档编辑与协同工具,产品和研发特点比较特殊,对应的质量保障体系建设经历了从 “农耕社会” 到 “初步探索工业化”,再到 “全面工业化” 发展的过程,在测试开发比 1:20 的情况下,如何做好质量保障工作,这篇文章给出了比较完整的方案。

方案介绍


🤔 关于 “他山之石” 💭


↙↙↙阅读原文可查看相关链接,并与作者交流