写点什么

单日 2000W+ 订单,如何忙中不错?美团外卖业务异常检测实践详解

2019 年 4 月 10 日

单日2000W+订单,如何忙中不错?美团外卖业务异常检测实践详解

写在前面

外卖业务持续高速成长,业务迭代快,逻辑复杂,关联服务多。如何快速准确识别系统各项指标的异常,发现问题根因,并快速解决显得尤为重要。在常规业务指标监控工作中需要手动维护上万业务指标报警阈值,不仅成本高,效果也不佳。我们尝试使用“形变分析模型”对业务指标自动进行异常检测,无需人工设置阈值。在实践过程中与外卖全链路压测,服务保护等稳定性保障系统进行内联,目前已覆盖绝大部分美团外卖 C 端核心业务指标,效果不错。


美团外卖业务异常检测现状

外卖业务特点

美团外卖从 2013~2018,历时五年,现在已经是全球最大外卖交易平台。外卖业务相关的指标主要会分为两大类:


  • 有规律的时间序列,大多数核心业务指标都会呈现出较强的规律性,如下图 1 所示:主要的履约交易流程(用户下单 > 支付 > 商家接单 > 配送 > 用户收货)中各个业务指标呈现周期性、趋势性,午、晚高峰陡升明显,与低峰期数值相差百倍。目前单日完成订单两千多万单,交易频次高,如果不能及时发现潜在业务指标异常,有可能引发重大事故。



图 1:有规律的时间序列


  • 无规律的时间序列,这类指标会因为一些偶发事件引起曲线的波动,没有很强的规律性。如下图 2 所示:

  • 根据当前的业务现状实施有针对性的营销策略,在特定时间进行红包发放等。

  • 特定业务上线,比如外卖 SET 化确定某一时间点进行引流。

  • 某应用失败率因为服务器硬件问题出现陡升现象。

  • 某应用性能指标因为网络抖动引起的变化。



图 2:无规律的时间序列


主要痛点

美团外卖在业务稳定性监控建设中会与一线开发人员频繁沟通,针对监控告警需求主要存在如下几个痛点,如下图 3 所示:


  • 告警精确率与召回率难平衡。精确率可以反映出对异常点的识别是否准确,误报会直接影响精确率。召回率可以反映出对所有异常点识别的是否够全,漏报会直接影响召回率。在业务异常检测告警过程中,漏报往往比误报带给业务的伤害更大,在重大事故时,如果不能及时识别出核心业务指标的异常点,很有可能会延误处理事故的最佳时机。提升召回率的同时可能降低精确率,而如果误报太多又会让业务开发人员在日常运维中对告警失去敏感度。

  • 人工配置告警阈值成本高。告警阈值配置需要对业务特点熟悉,对于新业务上线或者功能变更等动作可能会调整相应的告警阈值,指标波动在什么范围内发出什么等级的告警,这都需要投入较高的人力成本去维护。

  • 典型故障场景分析需要人工介入。对于故障场景需要人工介入去进行问题排查定位与解决,不同的开发人员处理问题的经验有差异,交接成本高。针对经常碰到的故障场景,在多次出现之后我们是可以将这些故障场景对应的特征进行归类整理并落地成专家模型,帮助开发人员快速定位故障方向,采用对应预案处理,提升效率。

  • 重大事故时如何避免告警洪潮。日常某一个业务指标出现问题发送告警,我们还可以较容易的定位具体问题。当多业务链路同时出现问题,可能会出现告警洪潮,让开发人员很难快速定位到问题根因去解决问题,这个时候需要有一套告警收敛策略帮助开发人员快速找到问题最严重的地方,给出处理建议。



图 3:开发人员在业务监控上的主要痛点


形变分析模型介绍

概览

在外卖业务场景下,与业务开发人员日常沟通过程中发现大家判断业务指标是否异常,大多数是通过人眼观察形状是否符合预期。我们希望找到一种方式可以通过对时间序列的 形状预测 来判断是否异常,并希望可以对异常严重程度设定不同的告警等级。通过简单的模型来覆盖常见故障场景,并具备较好的普适性。形变分析模型从上述痛点出发不断向前演进。


任何一种异常检测模型都有它的适用范围,形变分析模型也不例外,这里需要强调一下形变分析模型主要针对有规律的时间序列进行分析检测,主要会依赖两个简单的计算公式:


  1. 归一化互相关(余弦相关性)公式。它经常被用来判断两篇文章是否相似,也可以体现两个曲线的相似度,相似度越高说明形状越相似。

  2. 形变量计算公式。这里虽然是简单的四则运算,但是具备较好的适应性。


基于形变分析模型的异常检测主要关注点概括为如下几点,具体如下图 4 所示:


  • 形变分析:对时间序列两次处理归一形成形变量集合,通过形变量计算不同等级告警阈值。

  • 相关性变点检测:针对出现的特殊情况称之为超级变点,采用相关性变点检测作为方案补充。

  • 告警收敛策略:通过时间桶、链路维度对告警进行收敛,提供图形化的直观告警信息,避免告警洪潮。



图 4:基于形变分析模型的异常检测主要的关注点


下面会对形变分析模型详细展开介绍。


模型分析过程


图 5:基于形变分析的异常检测主要流程


下面给大家重点介绍一下形变分析模型的分析过程,这里主要会有四个步骤,具体如图 5 所示:


  • 确定时间序列特征,是否是有规律的时间序列。因为形变分析模型的适用范围是有规律的时间序列,这里主要表现为有周期、有趋势,所以可以确定曲线是否是有周期的(可以通过傅里叶变换确定曲线的短周期),确定节假日与工作日的差异性,并进行归类(工作日归为一类,节假日归为一类)。

  • 选择基准线。形变分析模型需要找到一个基准线来进行相关性分析,这里的基准线主要关注形状,而非具体数值。这个基准线,我们可以使用周同比的数据,可以通过一些预测算法进行预测(比如:STL + Holt-Winters),这里更加关注预测出的形状而非具体数值,也可以选择同源数据(同一链路上其他相似的业务指标)作为基线。

  • 基准形变量计算。根据选择的基准线与真实数据通过两次处理,去除时间、形状、量级等因素的影响,将时间序列归一到一个基准上,通过形变量计算得到基准形变量,为后续异常判定、等级设定做准备。

  • 异常判断阶段。可以通过聚类计算基准形变量,根据基准形变量自动设定不同等级的告警阈值,并结合人工反馈是否敏感等信息进行自动修正。


两次处理


图 6:形变分析的第一次处理


上面通过流程图介绍了一下形变分析模型的整体流程,下面针对形变分析模型中最核心的两次处理操作通过具体案例展开介绍一下。第一次是针对形状或时间的处理,具体如图 6 所示,形变分析模型预测出基准线,通过真实数值与基线数值进行归一化互相关计算,计算出一个新的时间序列,因为余弦相关通常用于正空间,所以每一个点都归一到了[0 , 1]区间上,从而去除了形状或时间的影响。归一化之后新的时间序列除了在午高峰附近两个明显的异常点有较大波动,在凌晨低峰期因为量级较小,也会出现比较明显的波动(因为量级小,形状差异会被放大)。上述现象表明不同时段的业务量级对余弦相关性影响较大,需要找到一种方式将量级的影响去除。



图 7:形变分析的第二次处理


第一次处理去除了形状或时间对时间序列的影响,接下来我们发现通过 如图 7 所示 的形变量计算公式可以将量级进行还原,或者可以理解为针对不同的量级赋予不同的权重,形成新的时间序列可以去除量级的影响,这就是第二次针对量级的处理,最终将时间序列归一到形变量集合上,通过聚类计算基准形变量达到设定不同告警等级阈值的目的。统一的标准为我们后续结合用户反馈对不同等级告警阈值进行微调带来了便利。


告警收敛策略

针对重大事故时如何避免出现告警洪潮,针对典型故障场景如何快速给开发人员提供简单直观的建议,这些也是在异常检测系统中需要重点关注的问题。其中告警收敛模型会优先关注两大类问题:


  • 简化告警内容,直观展示异常点与变化趋势。如下图 8 所示,日常大家收到的告警内容更多的是文字版,这里针对异常点的严重程度与前后变化趋势不太容易通过文字简单直观的表达出来。我们逐渐将异常告警信息变成了图形化,可以直观展示异常点变化幅度,展示最近时间区间异常变化趋势。通过收集用户点击行为判断大家对特定异常的关注度,对低关注度异常告警实施对应收敛策略。



图 8:告警展示形式


  • 在重大事故时避免出现告警洪潮,给用户推送清晰的分析报告。如下图 9 所示,在事故持续时间较长时,每分钟都发送告警会对业务造成干扰,模型可以采用连续三分钟发送异常告警之后,采用间隔 3、5、7、7……分钟进行发送,直到判断异常恢复为止。在多个业务链路出现故障时,同时多个业务指标发送告警,即使做了时间桶的收敛,也可能会出现较多告警,异常检测系统需要根据业务相关性,从强相关业务的业务链路上收集异常告警事件进行分析,从更高维度给出链路级分析报告(例如在外卖业务中:提单业务是支付业务的前置,支付业务是推单业务的前置,当支付业务发生问题时,提单业务一定会上涨,而推单业务一定会下降)。



图 9:告警收敛策略


解决了哪些问题

上面向大家介绍了形变分析模型的分析过程,接下来会通过几个典型案例详细说明形变分析模型解决了美团外卖哪些现实问题。


案例 1

业务背景:因为全国大范围出现恶劣天气,导致当天外卖订单整体抬升,如图 9 所示,午晚高峰整体抬升明显,这种情况下业务侧并不希望出现连续高等级告警。



图 10:案例 1,整体抬升


第一次对时间或形状的处理:将历史真实样本与基线进行归一化互相关计算,得到的归一化数据集可以看到在业务低峰期时,相关性波动较大,在午晚高峰时相关性很稳定。这时已经去除了时间或形状的影响。


第二次对量级的处理:通过形变量计算公式,还原量级,去除量级的影响,得到形变量数据集,通过基准形变量计算出不同告警等级对应的形变量告警阈值。如图 10 所示,没有发现任何时间点的形变量超过告警阈值,符合不作为异常识别的预期。


案例 2

业务背景:某一业务渠道出现问题,引起整体流量缓慢下降,如下图 11 所示,该情况需要在下降的过程中及时识别为异常,并根据下降的程度逐级提升告警等级。



图 11:案例 2,阴跌


通过两次对形状与量级的处理,最终可以看到只有在业务指标缓慢下降的时间范围内有对应形变量超过告警阈值,并且会随着下降程度告警等级逐级提升,符合需要识别为异常点的预期。


案例 3

业务背景:某服务入口流量因为某一渠道突然故障,引起整体入口流量陡降,之后曲线形状又恢复到与基线值重合,如下图 12 所示,该案例需要及时识别为较高等级异常。



图 12:案例 3,超级变点


通过对时间与量级两次处理,并没有任何时间点的形变量达到较高等级告警。这是为什么呢?对于形变量计算公式:(1 - 余弦相关性)x |实时当前值 - 基线当前值| ,这里看到在陡降异常点时 |实际当前值 - 基线当前值| 会趋近与 0,这样在陡降时的形变量也会趋近于 0,并没有超过对应的告警等级。这个案例在形变分析模型中属于一个特殊情况,针对这样的案例,我们需要引入互相关变点检测作为弥补,这样的异常点称之为超级变点。针对超级变点,需要利用公式:(1 - 余弦相关)x |前一分钟数值 - 当前值| 来进行识别,在进行形变量计算过程中只要这两种方式其中一种超过对应告警阈值就进行告警。在进行相关性变点检测之后,可以识别该异常点为较高等级异常,符合检测预期。


案例 4

业务背景:世界杯期间有针对性的进行营销活动,属于非常规营销活动,会不定时引起业务指标陡升,如下图 13 所示,该场景需要及时识别出指标异常,提醒开发人员关注相关业务指标。该业务场景是属于比较常见的在有规律的时间序列上出现随机的陡升陡降场景。



图 13:案例 4,陡升


在进行两次处理之后,三次活动期间引起的指标陡升超过告警阈值,符合指标异常需要被识别的预期。


案例 5

业务背景:在高峰期与低峰期都有跟基线相比波动超过 5%的异常点,在午高峰时需要进行 P0 级别告警,低峰期波动经常超过 10%可能并不需要进行告警,如下图 14 所示。



图 14:案例 5,高峰期与低峰期对告警识别的适应性


在进行两次处理后,可以看到在低峰期时形变量非常小,达不到告警阈值。在午高峰时形变量非常大,达到 P0 级别告警阈值。那么在低峰期如果想达到 P0 级别告警阈值,需要波动在 50%左右,如图 24 所示,这个案例体现了形变分析模型在阈值判定上较好的适应性。


异常检测系统的主要关注点


图 15:异常检测系统结构图


业务异常检测系统在整个稳定性保障体系中处在核心位置,承载着在业务出现重大事故时进行快速异常识别、定位根因、给出降级建议的责任。会分几大模块进行建设,具体如图 15 所示:


  • 多维度监控指标采集,这里主要包括:业务指标、应用指标(客户端、服务端、端到端)、系统指标(CPU、Memory、IO 等)。指标采集需要尽可能短的链路,需要对指标进行可信度标记,尽可能给后续异常检测流程提供稳定准确的数据支持。

  • 通过对不同类型时间序列特征进行识别,选择对应的异常检测模型。这里不仅需要识别出异常,还需要进行不同告警等级的阈值计算,通过收集用户反馈信息对不同模型识别异常的效果进行评估,进行半监督学习不断修正模型效果。

  • 异常检测系统针对识别出的异常告警事件进行汇总分析,可以从更高维度对业务进行健康检查(比如:可以分析出某一业务链路在某些时间点不稳定),给出故障诊断报告。


异常检测与其他稳定性保障系统的内联


图 16:业务稳定性保障两大核心场景


美团外卖偏向业务的技术保障能力对用户主要分为两大核心场景,具体如图 16 所示:


  • 业务稳定性监控场景,主要针对实时业务数据的监控、异常检测与故障诊断,在出现事故时直接帮助用户做出决策,给出处理建议。该场景中产生的诊断数据会形成多维度报告帮助用户进行日常的健康检查。用户可以消费异常检测事件,进行业务后续定制的保护动作。

  • 定期常规压测,分析核心链路中的性能瓶颈点,结合基于异常检测事件统计的稳定性报告对各个服务进行容量规划。在日常压测中会结合典型故障场景进行故障演练,确保各个服务保护动作真实有效。在压测施压过程中,异常检测发出的告警事件可以作为压力是否停止和开启的条件。


基于形变分析的异常检测落地情况及实践效果

基于形变分析的异常检测系统现在美团外卖应覆盖核心业务指标 2400 多个(其中包括订单、流量、营销、SET 等),因为使用的算法较简单,单次异常检测流程时间可以控制在 200ms。


在发送给用户的告警信息中不断收集用户反馈信息,在已有的反馈标记中,异常检测的精确率、召回率可以达到 80%,当然异常检测的准确性还有一部分依赖时间序列数据采集聚合通道的稳定性。关于告警阈值配置功能,有 74%的核心业务指标可以进行自动配置并调整。


整体回顾

本文主要给大家介绍了形变分析过程,突出对时间序列形状的预测。针对有规律的时间序列形变分析模型具有较好的适应性。然后给大家介绍了异常检测系统在美团外卖整个稳定性保障体系中的作用,以及形变分析模型在美团外卖的落地情况。


在进行业务指标异常检测时,尝试找到通用的异常检测方法非常具有诱惑力,但可能并不是最佳选择。尝试最适合你问题的最简单方法。用简单方法处理复杂问题,用简单模型收敛问题,用小成本撬动大效能。




作者简介


刘宏伟,2016 年加入美团点评,美团外卖技术保障组负责人,现正在围绕业务进行稳定性评估、实时监控、异常检测与故障诊断等方向的建设。


美团外卖技术保障组:围绕业务稳定性建设事前通过全链路压测系统建设提前发现服务性能瓶颈、进行服务保护预案演练、容量规划;事中通过异常检测与故障诊断模块,在重大事故时可以快速识别关键问题链路,定位根因;事后通过服务保护系统进行快速保护预案的触发,帮助开发人员快速解决线上问题,提升人效。


在此感谢对美团外卖业务异常检测做出重要贡献的同学:永强、庆文、召新、胡巍、龚炎、文浩、昌盛、占峰、素娟、强强、刘凯、绅宝、长伟、亢磊。


欢迎感兴趣的同学沟通联系。


联系邮箱: liuhongwei04@meituan.com


2019 年 4 月 10 日 15:097759

评论

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

你觉得你是哪类人?

Janenesome

读书笔记 思考

Web3极客日报#136

谢锐 | Frozen

区块链 独立开发者 技术社区 Rebase Web3 Daily

和儿子装一台 Hackintosh

苏锐

DIY Hackintosh 装机

人生就是一场说走就走的旅行

kimmking

回文串解题记录

不要注水

Java 算法

《Linux就该这么学》笔记(一)

编程随想曲

Linux

个人的投资原则

史前靓仔

带你100% 地了解 Redis 6.0 的客户端缓存

程序员历小冰

redis 缓存 redis6.0.0

MacOS使用指南之我并不需要系统菜单栏

lmymirror

macos 高效工作 完美主义 操作系统 新手指南

CTO股权”避坑“,你根本不知道我们多努力

赵新龙

TGO鲲鹏会 股权 CTO

抽象

落英亭郎

系统设计 面向对象 抽象

我的编程之路-3(熟练)

顿晓

c++ 调试 经历 项目 疑问

裸机Ubuntu18.04 配置实现人脸识别的第三方库

月夜

dlib face_recognition 人脸识别 环境配置

谈一谈自由职业者的心态

Bob Jiang

自由职业 写作 心态 营销

【Howe 学 JAVA】Java 类集框架2——集合输出

Howe

Java 集合 输出 类集

TL如何在团队中培养出更多前端技术专家

贵重

前端 团队建设 技术管理

回"疫"录(13):不信谣,不传谣

小天同学

疫情 回忆录 现实纪录 纪实 谣言

基于Serverless架构的Git代码统计

刘宇

云函数中使用Python-ORM: Peewee

刘宇

当你不知道怎么学习新技术时

石君

学习 方法论

引入了绩效管理,团队反而一天不如一天了?(一)

无箭的丘比特

团队管理 企业文化 绩效

【Howe 学 JAVA】Java 类集框架2——Set 集合

Howe

Java 集合 set

《CSS 选择器世界》读书笔记

灰二

CSS Java html 读书笔记 前端 张鑫旭

可能是最最最最简单的搭建博客方法

彭宏豪95

GitHub 写作 博客 GitPress

Web3极客日报#137

谢锐 | Frozen

区块链 独立开发者 技术社区 Rebase Web3 Daily

找到自己的领域,然后封神

一尘观世界

成长 提升 领域 机遇 趋势

Spring Boot可执行JAR的原理

小判

Spring Boot 类加载 Fat-JAR deflate JAR URL

Flink 1.10 细粒度资源管理解析

Apache Flink

大数据 flink 流计算 实时计算

CentOS7使用Iptables做网络转发

wong

Centos 7 iptables

我跑步的时候会想些什么

养牛致富带头人

跑步 运动 锻炼

Mac 自带软件-聚焦搜索

Winann

macos Mac spotlight

「中国技术开放日·长沙站」现场直播

「中国技术开放日·长沙站」现场直播

单日2000W+订单,如何忙中不错?美团外卖业务异常检测实践详解-InfoQ