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

做者：张鑫，资深工程师，点餐团队成员。本文同步发布于知乎专栏： 张鑫技术男。

业务背景

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

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

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

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

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

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

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

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

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

关于黑匣子

定义

“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的一部分。

总结

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

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

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

---

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