写点什么

客户案例|某知名连锁咖啡品牌点餐小程序排障实录

作者:观测云
  • 2023-06-21
    上海
  • 本文字数:1582 字

    阅读完需:约 5 分钟

客户案例|某知名连锁咖啡品牌点餐小程序排障实录

大家都用过咖啡点餐小程序吗?


截至 2022 年,上海已有超过 8000 家咖啡店,容纳百余个咖啡品牌,已是全球咖啡馆最多的城市。行业内的激烈竞争不仅体现在咖啡品类创新或口味保证上,便捷的消费购买方式也成为制胜关键。很多知名品牌,都已提供线上点餐服务,用户可以通过手机 App 或是小程序在线上下单,随后去线下门店取餐或等待快递送餐上门。


「我们希望知道点餐 App 或小程序在每一个终端用户手机上的运行状态,知道他们与后台服务的通信情况。比如是否有大面积的点单页面加载卡顿、是否出现集中的支付失败异常、是否出现取餐号推送错误等等。要能尽早看到问题,并尽快解决问题,哪怕是个别用户遇到的问题,也要能清晰排查到。若等收到用户投诉后才去找问题,那就晚了,可能已经丢失了很多订单,给用户非常不好的体验,同时也对我们的品牌造成负面影响。」


这是来自某知名咖啡品牌的诉求


对点餐小程序的监测需求


1、在交流过程中,客户提出重点关注应用服务的性能监控,要能收集和分析应用的性能数据,及时发现潜在的问题并修复它们。


2、在客户的点餐小程序里,不仅有用到自己开发的服务,也包括一些第三方服务。如何能准确监测各个服务的质量,提供详细数据,快速定位故障责任方,也是重点需求。


之前使用过某云厂商的应用链路产品,但只能统计出第三方服务的报错数量,无法下挖更详细的信息,也无法准确记录故障现场上下文,这导致客户要在第三方服务商面前能完整复现故障后才可要求修复,经常碰到扯皮的困扰。


使用观测云后,经过大约 2 周的监控环境改造,已完美解决这些问题。


观测云使用场景


场景 1:在测试阶段就引入观测云


按传统经验,完整的监控平台往往只服务于生产环境,因为只有运维人员会使用基础设施或日志监控工具,碰到真实问题后,再回退给测试或开发去解决。但观测云认为,现代软件会面临快速迭代开发,要保证生产环境质量,监控应该更加「左移」,让测试和开发人员也能看懂监控数据,以便及早发现和解决问题。


观测云可以统一应用性能监测、基础设施监测和日志分析功能,通过应用链路自动绘制拓扑,展现调用关系,进一步分析服务调用之间的错误率、响应时间等,方便开发和测试在预发或测试环境就能看到运行状态。因为观测云提供 SaaS 服务,所以开发、测试和运维不用维护监控平台底座,甚至可以随时相互共享仪表板或数据,使应用在开发、测试和上线过程中都能全面实现可观测性,方便各个团队间实现相互协同。



场景 2:第三方服务接口报错定位


如下图所示,在自定义仪表板中,显示 RabbitMQ 队列出现报错(红色),这是一个支付请求消息队列,那意味着有用户遇到支付故障;



在视图上直接点击详情,找到具体链路请求;



进一步跳转,自动筛选出相关的错误链路信息;



继续下钻链路详情,可以看到具体的报错信息,可以看到是第三方供应商提供的接口有响应超时。



通过观测云的快照功能,把整条链路状态保存为一个数据副本,将分享链接给到第三方供应商,用直白的数据展示故障,提出报修后,快速得到了供应商的确认与修复。


经事后统计,因为该接口的间歇性故障曾造成每天约 2000 条支付报错,假设有一半的客户因为首次支付失败而放弃购买,那就是每天几万元的业务损失,每月损失可达百万元。通过观测云的全链路可观测能力,工程师们快速找到并修复了这个系统漏洞,创造了实际的业务新增收入,而实际使用观测云的工具成本,仅有几十分之一。


通过观测云,帮助该企业在 DevOps 的开发测试早期就能够及时发现问题,极大地减少了服务上线之后的错误率;同时在线上环境,也能够直接定位第三方服务报错的原因,大幅缩短 MTTR 并提升服务质量,直接推动客户的业务的增长


观测云

技术交流|行业资讯 | 干货分享 | 最佳实践,点击 ⬇ 「关注」或在观测云官网(guance.com)添加小助手即可获取~




发布于: 刚刚阅读数: 3
用户头像

观测云

关注

还未添加个人签名 2021-02-08 加入

云时代的系统可观测平台

评论

发布
暂无评论
客户案例|某知名连锁咖啡品牌点餐小程序排障实录_可观测性_观测云_InfoQ写作社区