蚂蚁金服技术专家:更聪明的做线上质量

2020 年 5 月 29 日

蚂蚁金服技术专家:更聪明的做线上质量

作者介绍:张翔
车手、歌手、程序员,有态度有方法的质量 TL、新技术探索者和布道者,现就职于蚂蚁金服,他和他的爱车定居于成都。

你可曾遇到过这些问题?

在支付宝钱包的出境频道,会给用户推荐各色的内容,店铺、优惠券、旅游景点、攻略等。而一些奇葩的错误常常发生:

图 1:推荐店铺的内容上有错别字、禁忌词。

图 2:推荐了大量相同 / 相似的内容。

图 3:店铺的主图清晰度低,缺乏吸引力。

图 4:店铺图片出现了死链接。

这些奇葩的问题为什么会出现?

QA 都是吃干饭的啊?这些问题为什么研发过程中发现不了,上线后才发现,太打脸了啊!

稍微分析一下,发现这类问题在研发流程中的 QA 是解决不了的:

线下环节:确保了应用系统的代码逻辑是 OK 的;线下造数据验证推荐的功能,但无法验证推荐有效性、内容有效性。

线上环节:在灰度发布阶段,可以进行效果验证,并基于当天的数据、算法模型,做推荐有效性、内容有效性验证。

上线多天:上线多天后,我们发现哪些奇葩问题会从多个地方引入:

  1. 运营改了一个配置规则,导致某些地区内容推荐失效;
  2. 运营配置的营销页面,时间太长失效了,成为了死链接;
  3. 新的数据引入了一些体验不好的“脏数据”,并且推荐给了用户;
  4. 神经网络等不可解释性的模型,不知道哪天就引入了一些 badcase。

而这里面最大的问题是:

用户很可能比我们更早知道这些问题,但他们不会打电话给客服反馈,他们只会在心里默默的骂了一句“SB”然后再也不来了。

我们团队坚信,这些用户体验类的细节问题,会是我们成败的关键。

奇葩问题的人肉巡检 1.0

首先,这类问题是不好监控的:

  1. 问题无法衡量:用户在“看到”这些情况后,并不会去“交互”,所以很难记录行为并作指标统计。
  2. 问题无法分析:从页面访问行为等指标上,很难“环比”/“同比”出问题是什么。

所以产品经理和运营在刀耕火种年代,采用的办法就是承包责任制,每个人每天去看看自己所承包的城市 / 区域,有没有“死链接”、“内容敏感”、“垃圾图片”等问题,找到问题后拉着运营 / 产品经理 / 研发一起定位分析,尝试解决。

在我看来,这种方式简直就是石乐志

  1. 发现效率:人工方式,不一定能够赶在用户之前发现问题
  2. 改进效率:每次找人定位 / 解决,重复,解决慢
  3. 人力成本:全球有多少城市?用户体验问题有多少种?
  4. 优化价值:做了这么多优化,成效如何体现?

人和动物的本质区别就在于是否会使用工具,所以我们尝试用技术的力量解决。

用户体验巡检

< 把 Badcase 转成巡检用例 >:我们建立了一套和产品经理 / 运营的协作机制,帮助我们收集各种各样的花式问题;我们把这些问题转成检测项后,保证每一次检测都会覆盖全部的 Badcase,不会出现人肉检测的“漏测”问题;在开发检测项的时候,我们用到了图像识别 /NLP/ 位置核对等 AI 能力。我们建设的 30 多种用户体验检测项,覆盖了:

  1. 像店铺出现错别字 / 乱码 / 死链接 / 敏感词,店铺评论出现涉黄 / 涉暴 / 辱骂内容,这样的基础质检场景
  2. 像内容过期 / 内容重复,这样的推荐检测场景
  3. 像领土争端 (例如把香港认定为国家)/ 宗教禁忌,这样的法律合规场景
  4. 像推荐店铺过远 / 推荐店铺不在本城市,这样的位置准确性场景
  5. 像推荐店铺的门店 / 菜品图片不清晰,这样的图像质量场景

< 模拟用户漫游全球 >:我们用大数据的形式,每天找出全球重要地区 / 城市 / 街道的几万个经纬度点,模拟十几种具备不同特征的用户,作为不同的位置参数和用户参数,触发不同的推荐内容。和人肉检测相比,覆盖了更全的区域、用户群。

< 发现在用户之前,解决于润物无声 >:我们对巡检项划分了重要等级,并在线上进行巡检任务的分级调度,包括分钟级、小时级、天级等几种方式;等级最高的巡检项需要 5 分钟发现 30 分钟解决;而等级低的巡检项,一般通过项目排期等方式延后解决。巡检系统发现问题后,会把问题现场、错误原因等信息,通过钉钉机器人、邮件、大盘指标展示等渠道可视化出来,紧急任务自动创建任务流,让大家可感知可跟踪。而更有意思的是,我们把运营配置类的解决过程进行了沉淀,和业务系统一起形成“熔断”机制,保证了部分紧急问题的快速止损,让用户无感知。

在巡检体系建立后,我们先后发现并推动解决了几十个线上问题,预防了可能恶化影响更多用户的后果,将问题扼杀在摇篮之中。在这个通过技术赋能保障线上质量的过程中,更多的技术点、需求也都涌现了出来。

Think Big, Next to do

当我们在支付宝钱包的出境频道上实践成功后,发现还有更多的事情要做:

  1. < 经验复用开袋即食 >:支付宝首页的恵支付 / 腰封广告等渠道,也需要具备线上巡检的能力;我们做为线上质量的标配能力,如何快速赋能新业务,并让各渠道的个性化检测能力更灵活的实现,是后续要考虑的命题。
  2. < 推拉模式主从解耦 >:如何更好的和业务系统一起做“熔断”?除了由巡检平台发起熔断之外,巡检平台把巡检能力在“异步检测模式”的技术上,增加了“同步检测模式”;提供检测服务接口给业务系统,让业务系统获得检测建议并发起熔断。这样可以让巡检平台只掌握最重要的熔断操作,让业务系统可以定制自己专属的熔断操作。

To be continue

在大数据 /AI 时代,全生命周期质量保证中的线上质量越来越重要了,在我们死磕“线下质量”、“研发效能”的同时,需要在特定的业务场景更加关注线上质量。

出问题不可怕,只要能够在用户之前发现并解决就好;只要你跑的足够快,问题就追不上你的脚步。

2020 年 5 月 29 日 15:27 72

评论

发布
暂无评论
发现更多内容

如何解决 Kubernetes 的 DNS 延迟问题

倪朋飞

Kubernetes 微服务 云原生

我从来不在朋友圈晒投资人合影,却融了很多钱

邓瑞恒Ryan

高效工作 人脉 职业规划

聊聊:Java

字节先生

Java 编程 开发者 随笔杂谈 「Java 25周年」

探究vscode debug流程,解决无法运行go程序的问题

simpleapples

golang vscode

【SpringBoot】掌握这两个属性,你的测试类可以启动的更快些

遇见

Java Spring Boot Unit Test

Arduino 蓝牙遥控+超声避障小车

黄耗子皮

树莓派 极客

简单到不可能失败 —— 《微习惯》

零和幺

读书笔记

程序员职业鉴赏

陆陆通通

程序员 加班 职业病 鄙视链

阿里面试,一面就倒在了Java内存模型上?赶紧来看看

七哥爱编程

面试 Java并发 内存模型

三点思考,判断一家公司是否值得加入

邓瑞恒Ryan

高效工作 个人成长 职业

Scrum vs Kanban,如何选择

TerryLee

Scrum Kanban 敏捷开发 Worktile 研发管理

Oauth2的认证实战-HA篇

Damon

Java 架构 Kubernetes 微服务架构 Spring Cloud

像黑客一样思考

Fooying

黑客思维 黑客 安全攻防

我如何用 Python 给 Github 的 README.md 做一个访客统计功能

遇见

Python GitHub 开源 badge open-source

一文搞定 equals 和 hashCode

shengjk1

equals vs hashcode java equals java hashcode

无代码开发

Fenng

关于Iterator和Iterable

shengjk1

Iterator和Iterable java iterator java iterable

极客父母送给孩子的 ABC Book 就是这么 GEEK

魏彬(rockybean)

GEEK BOOK

一篇文章搞定 java 中的 path 和 classpath

shengjk1

java classpath java path classpath vs path classpath path

用你喜欢的 emoji 作为页面的 favicon 吧 🎉

遇见

CSS html favicon emoji

Kubernetes中的CI/CD

倪朋飞

Kubernetes DevOps 微服务

死磕Java并发编程(1):探究Java并发机制的底层原理

七哥爱编程

Java Java并发 并发编程

GitHub知错就改,是个好同志

遇见

GitHub

Kubernetes 容器运行时演进

倪朋飞

Kubernetes 容器 云原生

2020,这个世界会好吗?

IT民工大叔

读书笔记

回“疫”录:开篇

小天同学

疫情 回忆录 现实纪录 纪实

我的第一个千万阅读量

彭宏豪95

创作 生活 写作

Flink获取kafka中每条消息对应的topic

shengjk1

flink kafka flink 消费 kafka 获取 topic等信息

破解 Java Agent 探针黑科技!

谭建

Java JVMTI Java Agent APM Profile

你不必读完一本书

池建强

学习方法 读书

禁止在构造函数里调用虚函数

喵叔

C# .net 编码习惯

蚂蚁金服技术专家:更聪明的做线上质量-InfoQ