简介:技术团队的质量水平既影响到用户体验和业务效果,也与团队的研发效能和技术氛围息息相关。有赞的移动端受到线下门店场景的特殊性影响,需要支持本地的离线计算和硬件能力更有限的收银机设备,这也对移动端质量体系建设提出了更高更严格的要求。我们在探索移动质量提升的过程中,沉淀出了一些思考与方法论。
在技术团队,质量的话题相信大家都不陌生。以有赞的业务为例,质量问题无论是发生在业务上的交易链路还是在引流链路上,亦或是启动时的闪退或 loading 时间过长的性能问题,都会造成我们所服务的商家经营上的低效和 GMV 的流失,导致商家对有赞的技术能力产生质疑和抱怨,最终影响到有赞SaaS服务的续费率。
但事实上,质量不佳不仅会影响到业务和商家,对于技术团队自身的影响也不容小觑。
有赞移动团队也曾经历过从0到1快速迭代功能上线而对代码质量重视不足的阶段,这些挖下的坑在业务快速拓展的过程中带来了大量的线上问题和故障。线上问题的频发会让整个团队陷入一种效率上的恶性循环:应对线上问题会打断进行中的项目进度,严重的时候很多开发同学甚至不得不整个白天都在忙于处理线上问题,到了晚上才有空开始补今天的开发进度。这种情况下不仅会产生加班、延期等显性的影响,更严重的是技术方案考虑不周、Code Review不细致等隐性影响,会进一步降低线上代码的质量。这样的恶性循环也会让整个团队忙于救火,技术沉淀和氛围更加无从谈起。
质量不佳对于技术团队会形成恶性循环
因此我们深刻的感受到,对于一个技术团队而言,质量和稳定性其实是团队的地基。在好的质量基础上,我们才能更好去追求业务上的支撑与推动、研发效能提升、团队技术氛围等其他目标。
不同类型的业务场景中,对于移动端的要求也会有不同的侧重点。有些金融背景的业务会对于 app 的安全性要求更高,而另一些电商背景的业务可能对于动态能力要求更高,而技术团队在质量上努力的方向和侧重点都与业务特点密切相关。
那么有赞的业务场景中对移动端有哪些要求呢?我们归纳成以下两个突出的特点:
1、离线的业务能力
对于市面上的大部分app,当用户在移动 app 上操作下单的过程中,移动端通常只会负责信息的展示和用户的交互。而订单金额的营销计算(比如某个商品是否可以用优惠券减钱、某个商品是否在订单中符合成为赠品的条件)、数据的校验、订单的生成这些敏感的业务逻辑都会放在后端进行处理。
但是在有赞的门店业务场景中,我们为门店收银员开发的收银终端 HD 应用需要提供离线开单的能力。
这是因为门店场景中面对的是来店的顾客和真实排在收银台前的待付款消费者。这种场景要求收银系统在面临断网或者服务端宕机的挑战时,需要具有本地收银的能力。如果来店的消费者因为收银系统卡住而离店,那么商家就会蒙受巨大的损失。
门店场景中供门店收银的HD应用
本地去做营销计算和订单生成的要求不仅对于移动端本地数据缓存能力、数据变更及时性、逻辑复杂度、数据安全性提出了更高要求,在质量保障上还带来了两点挑战:
营销计算中的资损风险:如果移动端在创建订单过程中只负责信息展示和用户点击操作时,移动端由于自身 bug 导致资损风险的概率是极低的。但是当商品的折扣计算、优惠分摊、组包拆包、优惠叠加互斥逻辑都落在移动端本地时,编码 bug 导致订单金额计算错误,进而导致商家或者消费者资损的概率就会直线上升。比如一个商品并不在商家的限时折扣活动范围中,但是由于bug导致给这个商品也打了折扣卖了出去,就会给商家带来资损。而资损故障是非常严重的。这就要求我们必须有更严格的机制去确保核心代码的L0级稳定性。
问题的及时修复能力:当线上问题可能涉及资损时,也进而会对移动端的问题修复能力提出更高的要求。
就问题修复及时性而言,移动端相对于前后端有着天然的劣势。后端或者前端同学发现线上问题时,可以通过回滚做到几分钟内止血。但移动端不可能让每个终端卸载重装老版本,同时市面上的热修手段也存在诸多限制。这让我们不得不对于问题修复流程中的每个环节做更深入的思考与探索,尽可能在问题发生时能够快速止血,降低影响面。
2、受限的硬件水平
在门店场景中,我们为门店收银员提供的HD应用安卓端是运行在收银机上的。对于收银机的硬件能力,我们可以通过一个简单的对比感受一下:
我们抛去 CPU 能力等其他因素,但看内存这一项就存在着巨大的差距。有限的内存能力,要求我们移动技术同学不仅在编码和技术方案设计阶段在性能上有更细致的考量和设计,也要求我们对于线上的 app 性能卡顿问题有更强的分析能力和解决能力。
结合前文提到的有赞业务场景的要求,我们着重围绕以下几个命题,思考和探索如何提升移动质量:
我们将探索中的心得归纳为以下几点:
1、主动发现问题
在我们曾经出现过的一例线上资损故障中,由于场景实际触发频率较低,导致测试过程中被遗漏了。这个bug是6月6日发布上线的,但是直到7月10日有一个商家上报了一例我们才发现了这个涉及资损的问题。这件事情引发了我们的反思,对于核心业务链路上的异常行为,难道我们发现问题的途径只能依赖用户上报吗?
天网数据报警平台
事实上,主动去发现和修复问题对于移动端同学并不陌生。一个移动团队即使是在建立初期也会通过一些三方平台,对自己每个上线的版本进行 crash 的监控和分析。crash 平台就是主动发现和解决问题的表现。那么业务流程中的问题,我们是否也能做到主动上报、主动发现、主动修复处理呢?答案一定是可以的。
因此我们搭建了天网报警平台,目标就是对于核心业务链路上的异常情况,可以达到 crash 上报、分析、跟踪的同样效果。一套 crash 分析平台通常具备以下能力:问题上报、数据聚合、任务分配、版本过滤、上下文信息等,我们的天网平台也提供了相同的完整能力:
搭建了完整的平台能力之后,我们也深知整套系统的有效运转其实是深度依赖于业务同学在业务流程的关键环节中的主动分析和埋点,丰富的业务埋点才能让这套系统真正在业务主动防控中发挥效果,因此我们还汇总了适合业务主动埋点的最佳实践:
以下是一个天网报警的例子,在收银员操作一笔订单的过程中,移动端上报后端的开单参数中会包含以下信息:
我们曾经出现过的一个bug是在大型项目改造的过程中,在调用后端API传参时没有传选中的会员卡号。这个场景下,当这张会员卡有发放多倍积分的设置时,就会导致该笔订单最终发放的积分错误。这种场景下,我们增加对参数的主动校验:当开单参数中的营销信息中存在会员卡优惠,但是会员信息中又没有传卡信息时,就很有可能是开发中出现了bug,通过这样的参数内部交叉校验,我们就可以进行主动上报。
事实上,在一年后的一次重构过程中,开发同学真的又一次出现了同样的失误,而天网报警提供的信息这次就给与了我们很大的帮助。
截止目前,我们已经在业务核心链路上预埋了上百个报警点,并在线上多次真实预警了线上问题,让我们可以第一时间进行主动修复。
2、更早发现问题
看完前文可能有细心的同学已经会问了:如果对问题进行了埋点报警,那么又何必等到它上线再去处理呢?是不是在上线前就可以把问题修复掉?
回归阶段
答案当然是可以的。有赞的移动端发版是采用发版车机制,每周一我们会将测试验收通过的需求代码 merge 到 dev分支,去打出“高铁包”给测试同学进行回归,并且配合自动化测试进行核心流程的回归验收,下周一高铁包将会发布到市场。而高铁的这一周时间,就是回归发现问题的最佳时机。
因此我们将 crash 分析报警和天网业务告警的范畴都拓展到了回归阶段。高铁阶段的问题同样会主动触发报警,过去一年间,这两个平台都有多次在 bug 上线前主动报警的立功表现。
开发阶段
回归阶段报警并不是我们思考的终点,核心链路问题的发现和解决还可以更早吗?在开发阶段,甚至是方案设计阶段,有机会提前把一些线上问题扼杀在萌芽中吗?
我们在针对端上可能发生资损的环节设计了单元测试,并将单测的运行接入到了 CI 流程中,这样代码在提交时,就会直接经过单测的检验。
那么什么样的代码适合写单元测试呢?
我们经过讨论,将范围圈定在了移动端重新建模和发生运算两种场景上,各个业务域的同学通过梳理产出自己的单测用例。
方案设计阶段
还有比开发阶段更早的时机吗?可以在项目开发前就主动预防吗?我们在移动端设计了行为校验机制
行为校验
所谓行为校验,就是将用户的操作行为和数据进行交叉校验,这个校验可以增加一个新的维度来预防 bug 的发生。
我们仍然采用上文提到的订单参数中忘记传会员卡信息的 bug 为例,这里选中卡这个操作是客户端用户点击触发的,那么用户选卡的这个操作就是最终开单参数中应当包含会员卡的交叉校验点。
这样的校验逻辑对于我们就是一条“校验规则”,我们开发了行为校验的底层SDK,就是在核心开单业务链路上通过将全流程的用户操作行为和最终订单数据进行double check,新增一个维度来为业务保驾护航,提前避免开发过程中的低级失误引入 bug 的可能性。
类似的规则例子还有很多,比如一笔在线订单收款成功之前,一定曾经成功调用过支付接口,可以用来预防一些同学在页面跳转上的bug;
目前我们的行为校验已承载了核心业务链路上的多条规则,大大降低了资损故障的可能性。
问题的发现和解决贯穿整个研发流程
3、有效的流程机制支撑
虽然我们有了多样的工具平台来报警和及时发现问题,但是这样就可以提升质量了吗?在实践中,我们深刻的认识到,工具只有在配套高效合理的流程机制支撑,才能真正发挥威力。
在平台搭建初期,线上的crash和数据校验报警平台在报警时缺乏策略,没有就报警频率和at的负责人做收敛,导致单台设备的一个小问题,机器人就会短时间在群里发出几百条at所有人的报警消息。这种“狼来了”的报警只会让大家关掉群消息提示,或者关掉企微的通知。
不懂得克制的报警,相当于没有报警。
因此我们反复优化了报警策略,以“报出来的问题都是需要立即响应,不需要立即响应的都不要报出来”为原则,沉淀了一系列报警策略,详细内容可以参见之前的公众号文章[《有赞移动天网平台搭建》] 中的相关章节。
除去报警策略,我们另一个在流程规范上的沉淀是在Code Review环节上。
betterMR
在我们团队质量问题最严峻的时期,我们扭转被动战局的核心手段还是加强Code Review。但CR这件事情要想真的扎实做出效果,而不流于形式,是非常依赖好的流程机制进行支撑的。在强化和落地CR的过程中,我们面临以下挑战:
CR过程中的沟通成本
我们意识到,CR的过程必须通过流程规范提高其效率,降低对开发同学的打扰和负担,这样大家才能真正高质量的投入到CR中,相互保驾护航。
最终我们推出了betterMR机制,通过以下机制解决以上的挑战:
硬性要求:所有上线代码,至少2人review通过后才可以合入dev
时机问题&颗粒度问题:代码在开发过程中,拆分成多个子任务,分批提MR合并到自己的feature分支。因此CR过程可以穿插到整个开发流程中,而不是在上线前最后review
沟通成本问题:企微通知全程介入CR流程,核心链路通知相关人,无需线下单独沟通
CR发起:开发同学在MR中at两位reviewer,两位reviewer都会收到企微通知消息
CR建议:reviewer提出建议后,在评论中输入[N]命令触发企微通知给开发同学
CR再次review:开发同学根据建议完成改造后,在评论中输入[R]命令触发企微通知给reviewer再次review代码,确认建议已落地
CR通过:reviewer通过后评论“+1”,当MR中已累计两个“+1”时,开发同学会收到企微通知,代码已可以合并
及时性问题:团队对MR进行了分级,对应提出了及时性的要求
普通MR,要求24小时内完成review建议
紧急MR,要求2小时内完成review建议
数据汇总激励:我们针对MR还统计了周报和月报,对于团队中积极review代码的同学,在周会和月会上给与激励,让大家都认可review的积极效果
这套机制我们在2020年6月推出后,团队的线上问题数量立刻得到了有效控制。我们在当年Q3迅速将线上问题数量缩减到了之前的1/3,并在之后长期保持了很低的线上问题率。
过去两年移动团队的线上问题走势
配合有效的流程机制,工具能力才能真正发挥效果
4、重视性能
前文也提到有赞移动的性能挑战。在性能问题上我们的动作包括以下三个方面:
APM平台的搭建:主动发现线上问题,并且为线上卡顿问题提供分析数据与线索。APM平台的详细设计与实现,参加之前的公众号文章[《有赞移动性能监控平台(二)》]
线下监控平台:对于性能问题,我们也同样在探索在问题上线前发现和解决的可能性。我们所搭建的线下监控平台,在回归阶段对关键环节进行自动化测试并采集数据,如果发现同比上个版本某个数据有显著提升,就会报警提示开发接入排查;线下监控平台的详细实现参加之前的公众号文章[《有赞移动性能监控平台(一)》]
主动优化:根据APM平台和线下监控平台的数据与反馈,我们会主动安排性能优化的方案,对app性能进行持续优化。我们之前的公众号文章[《线程池优化与监控》] 就是其中的一个典型例子。
可用性、性能与流程规范共同构建了移动质量建设矩阵
质量提升的成果
过去两年我们在质量上的深耕与探索也给我们带来了丰厚的成果,这个成果不仅体现在我们的月均线上问题数量上,更体现在我们持续的技术产出上。技术同学救火的频率低了,就有更多时间主动出击,去体系化的搭建系统去预防线上问题的发生,预防机制又能进一步降低线上问题发生的概率,形成良性循环,这无论对于团队,还是开发同学个人的成长都是很有帮助的。
过去两年,有赞移动团队仅在质量建设方面就产出了多篇公众号文章,每篇文章背后都是技术同学的积累和沉淀:
本文讲到的有赞移动质量提升与实践的过程,其实也一定程度上代表了我们团队的工作方式。我们在应对有赞业务场景的过程中,会遇到如离线收银、性能深度优化等有挑战有意思的技术难题。而面对这些挑战和难题,我们会主动出击,寻求体系化的解决方法。这些解决方案中往往还会涉及到后端服务和前端页面的工作,以及产品化的思考,我们移动同学在此过程中不设边界的拓展自己的技能包,最终形成让人颇具成就感的技术沉淀。
我们也非常期待和欢迎更多喜欢这样工作方式的同学加入到我们有赞移动的家庭中,一起enjoy。
本文由哈喽比特于2年以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/X0HJaJA4QWUedtXptcXyPQ
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。
日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。
日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。
近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。
据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。
9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...
9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。
据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。
社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。