“黑匣子”工程 - 用户端监控保障体系建设

1,989 阅读8分钟
作者:张鑫,资深工程师,点餐团队成员。本文同步发布于知乎专栏:张鑫技术男

业务背景

美团点评的业务发展历程是一个不断深入挖掘行业价值的过程。

从用户评价,到团购,到外卖,到预订,再到点餐,越是后期的业务越需要向系统底层打通,对商家运营的介入程度越来越深。

对商家运营的介入程度加深之后的附带效应是:

  • 系统的不可替代性越来越强
  • 系统的复杂程度越来越高
  • 对系统稳定性的要求越来越高

这三个附带效应,对我们的服务能力提出了更高的要求。打个比方,如果说过去我们为用户提供的是自行车,那么现在我们要为用户提供的是飞机。飞机的不可替代性、复杂程度、系统稳定性要求都远高于自行车。

为了保障系统稳定运行,主要从两个方向入手:

  • 技术架构上和开发流程管控方面下功夫,防患于未然,系统性地降低风险。
  • 从故障响应方面下功夫,提高故障预警、分析、处理能力,做到快速响应快速解决。

所谓“黑匣子”工程,就是要建设一整套用户端监控保障体系。这套体系可以理解为给系统中每个商家或者用户加装一个记录用户行为和用户端内部状态的黑匣子。当故障发生时,我们要能够从黑匣子中得到全面的用户端数据,以数据分析的思路来解决难以复现的疑难问题。

我们建设用户端监控保障体系,就是要为整个业务的故障响应能力赋能。


关于黑匣子

定义

“A flight recorder, commonly known as a black box, although it is now orange-coloured, is an electronic recording device placed in an aircraft for the purpose of facilitating the investigation of aviation accidents and incidents.”

一种比喻

航空界使用黑匣子来助力事故分析,互联网领域一样可以借鉴其思路。

对于SAAS系统,整个系统可以理解为一个航空公司,用户可以理解为乘客,用户端可以理解为一架架在飞行的飞机。

对于系统后台,我们的监控数据通常是比较全面的。但是对于用户端,监控数据则十分匮乏,很多情况下,用户端只有简单的性能监控或者crash监控。

这就相当于一个航空公司只知道哪些飞机准点到达了,哪些飞机坠毁了,但是不知道飞机内部发生了什么,也就是没有黑匣子,这样难以对故障进行分析处理。

SAAS系统的用户端,也一样需要全面的监控数据来助力故障响应。

与黑匣子的类比关系:

  • The flight data recorder (FDR) - 记录用户端内部的关键数据
  • The cockpit voice recorder (CVR) - 记录用户端与各个后端服务的通讯


从过程复现到数据分析

在没有用户端“黑匣子”的系统中,我们处理问题的思路就相当于与在空难现场收集线索,然后试图根据碎片中的信息重现空难,在反复重现的过程中寻找问题的原因。

有了黑匣子,我们就可以直接调取发生故障时用户端的具体信息,从数据分析的角度查找原因。

传统思路:过程复现

传统思路是将用户与系统的交互视作一个过程,通过复现交互过程来定位并解决问题。

基本模式:

收集反馈 - 重复操作 - 复现问题 - 调试代码 - 定位问题

传统思路的缺陷:

• 用户的反馈是片面的,系统内部的信息无从了解,难以真实还原交互过程

• 疑难问题往往是小概率发生的,难以复现,甚至不可能在开发者所在的环境下复现

新思路:数据分析

新思路是将所有用户行为和系统行为视作数据集合,通过数据来记录用户在交互过程中的真实状态,通过数据分析的方法来定位并解决问题。

基本模式:

收集数据 - 调取数据 - 分析数据 - 定位问题

新思路的条件:

• 有完善的支撑系统来支持数据的收集和分析

• 改造代码来实现信息的全量上报

• 开发者具备数据分析的能力


用户端监控保障机制


用户端监控保障机制的核心是数据。一方面在于对于用户行为和系统状态的全量信息收集,另一方面是利用数据分析的思路解决问题,加快问题反馈闭环。

监控数据收集

关键目标:“全流程,全服务,全信息”的监控覆盖。

  • 全流程 - 从页面访问,到行为记录,到接口请求与反馈的全流程都要在监控范围内
  • 全服务 - 后台服务,平台服务,第三方服务
  • 全信息 - 要包括时间,地点,任务,网络状况,设备等上下文信息

问题反馈闭环

关键目标:每条问题反馈都能找到对应的监控记录。

问题反馈可以是用户主动反馈的,也可以是运营或技术人员分析发现的,也可以是系统的自动报警。

通过问题反馈,得到上下文信息,根据上下文信息通过多维度查询找到相关的监控记录,分析监控记录形成处理方案,处理方案经过积累沉淀再助力于问题反馈,形成整个闭环。


“3+3”监控覆盖

3+3:

  • 3个主要环节:资源到达,页面渲染,用户操作
  • 3种主要服务:后台服务,平台服务,第三方服务

监控的两种类型:

  • 记录型监控:记录系统各个关键环节的工作日志,用于正向确认系统状态正常
  • 捕捉型监控:记录具体错误信息,用于负向确认系统状态异常

捕捉型监控的缺陷在于我们对错误的捕捉是有预设性的,而很多疑难问题并不能被我们预设的条件捕捉到。

记录型监控与捕捉型监控必须相互配合才能准确定位问题,两者都很重要。


支撑系统建设

主要需求:

  • 全量的数据收集
  • 支持多维度的数据查询
  • 支持实时的数据分析
  • 支持指标报警
  • 使用简单快速

目前已有支撑系统的主要问题在于还没有一个现有系统能够同时满足所有主要需求。而且多数监控系统都是针对于后台的,专业的而用户端监控系统还在建设中。

实践中需要各个系统配合使用,或者基于已有系统做二次开发。

全面的用户数据上报,势必带来数据体量方面的挑战:

  • 大量数据上报的带宽压力
  • 大量数据的存储压力
  • 大量数据的快速检索与实时分析


监控数据分析

场景还原法是用数据还原系统在故障发生时的真实状态。

从故障相关的监控记录中,先向下查找交互过程中的断点,再从断点出发,向上查找具体错误原因。


管理保障

管理手段是辅助,目的是加快问题反馈闭环的运行速度。

运营人员根据故障FAQ来快速响应,并决定是否进入故障响应流程。确认需要研发人员介入之后,研发人员根据故障处理手册中的指导来排查问题。

问题处理完成之后,写成CaseReview,并沉淀成故障FAQ的一部分。


总结

随着移动互联网时代的结束,做线下服务的企业进入了深挖地底矿的新时代。随着我们的业务对商家运营的介入程度越来越深,对于稳定性的保障需要完成从自行车到飞机的转变。

“黑匣子”工程是给用户端系统装上收集数据的黑匣子,并且以数据分析的思路来解决疑难问题,加快问题反馈闭环,为整个业务的故障响应能力赋能。

文本给出了关于用户端监控保障体系建设方面的整体思考,后续会找机会将一些细节的设计与大家分享。欢迎大家批评指正。


本文对你有帮助?欢迎扫码加入前端学习小组微信群: