美团外卖:日订单量超1600万的自动化业务运维之路

  • 时间:
  • 浏览:1

作者介绍

③ 我们都歌词 歌词 的代码中会有多量的降级限流开关,在服务异常时进行相应的保护操作。哪此开关随着产品快速地迭代,我们都歌词 歌词 那末多能确定它们是否还有效。另外,我们都歌词 歌词 那末多 较准确地进行容量规划以应对快速增长的业务量。哪此都那末多 通过全链路压测帮我们都歌词 歌词 不断地验证,并发现性能瓶颈,有效地评估服务容量。

美团外卖业务在互联网行业是非常独特的,不仅流程复杂——从用户下单、商家接单到配送员接单、交付,怎么让压力和流量在午、晚高峰半时 非常集中。一并,外卖业务的增长非常迅猛,自2013年11月上线到最近峰值突破1500万,还非要4年。在你这种情况报告下,一旦出现事故,单纯靠人工排查补救现象,发生较多的局限性。本文将详细解析现象发现、根因分析、现象补救等自动化运维体系的建设历程与相关设计原则。

我们都歌词 歌词 最终会发出现象诊断结果,你这种结果在发出前一天,还那末多 收集用户的反馈,判断诊断结果是否准确,为我们都歌词 歌词 后续优化评分定位模型与诊断模型提供有力的数据支持。在核心链路建设前期,我们都歌词 歌词 会建议开发人员进行相应的服务保护预案触发,当我们都歌词 歌词 的诊断结果足够准确前一天,那末多 针对固定现象场景自动化触发服务保护预案,以缩短补救现象的时间。

图12 异常检测与服务保护联动 

② 那末多 带着时间戳与类型快速引导开发人员进入其它监控系统,提高开发人排查现象的强度。

核心目标

 在整个业务运维系统建设中,非要更加准确定位现象根节点,诊断出现象根本原因那末多 逐步自动化去做许多运维动作(比如:触发降级开关,扩容集群等)。如图14所示,我们都歌词 歌词 会在哪此环节的精细化建设上进行持续投入,希望检测到任意维度的异常点,向上推测出可能会影响哪此业务指标,影响哪此用户体验;向下依托于全链路压测那末多 非常准确的进行容量规划,节省资源。

如下图6所示,在自动化业务运维系统中,业务大盘与核心链路作为用户使用的入口,一旦用户查看业务指标出现现象,我们都歌词 歌词 就那末多 快速定位该业务指标异常的根本原因。我们都歌词 歌词 通过对核心链路上服务情况报告的分析,帮助开发人员定位最终的现象节点,并建议开发人员那末多 触发哪此服务保护预案。业务大盘的预测报警、核心链路的红盘诊断报警以及可能收集到各个维度的报警事件,可那末多 对它们做进一步的统计分析,那末多 帮助开发人员从更加宏观的深度提前发现服务可能潜在现象,大慨提前对服务做健康检查。我们都歌词 歌词 那末多 定期通过全链路压测来不断验证现象诊断和服务保护是否有效,在压测时那末多 看过各个场景下的服务健康情况报告,对服务节点做到有效的容量规划。

外卖业务特点

进入到流量回放阶段,我们都歌词 歌词 那末多 针对典型的故障场景进行故障预案的触发(比如:Tair故障等)。

我们都歌词 歌词 现在定期会组织外卖全链路压测,每次压测后会涉及什么都许多人的配合,可那末多 能针对单一压测场景进行压测可能大大缩短我们都歌词 歌词 组织压测的成本。如图10所示,我们都歌词 歌词 现在主要在全链路压测的前一天,针对压测流量进行不同场景的故障演练,在制造故障的一并,验证服务保护预案是否那末多 像预期那样启动保护服务的目的。上边会讲一下我们都歌词 歌词 针对全链路压测自动化建设思路。

前面主要介绍了我们都歌词 歌词 在做基于业务的运维系统时那末多 的各个核心功能,下面重点介绍一下,我们都歌词 歌词 在整个系统建设中,自动化方面的建设主要集中在哪此地方。

图5 自动化业务运维系统核心建设目标

刘宏伟,2016年加入美团点评,主要负责外卖业务架构相关工作,现正在围绕业务建设监控运维体系。

针对真实流量的改造,基础数据构造、数据脱敏、数据校验等尽可能通过任务提前进行。

② 当我们都歌词 歌词 确认完某条链路出现了现象,在链路上越往后的节点可能是引起现象的根节点,我们都歌词 歌词 会实时获取该节点更多相关监控指标来进行分析诊断,这里会融合开发人员日常排查现象的SOP,最终可能定位到是你这种服务节点许多服务器的磁盘可能CPU等现象。

确定了核心目标,我们都歌词 歌词 前一天刚结速着手开发产品。接下来就介绍一下我们都歌词 歌词 建设这套系统的核心产品以及各个产品模块之间的关联,其它设计细节与我们都歌词 歌词 碰到的坑,本文不着重描述了,前一天会有更加针对性的文章分享出来。

我们都歌词 歌词 在日常的业务运维工作中老要 会碰到许多现象困扰着开发人员,如图4所示,主要有四大痛点:

② 限流开关:许多针对特定业务场景那末多 有相应的限流保护法律办法。比如:针对单机限流主日后对自身服务器的资源保护,针对集群限流主日后针对底层的DB可能Cache等存储资源进行资源保护,还有许多许多限流需求后会希望那末多 在系统出现流量异常时有效地进行保护。

图6 业务监控运维体系架构

外卖业务场景,使我们都歌词 歌词 大多数业务监控数据都呈现出很强的周期性,针对业务数据我们都歌词 歌词 那末多 利用历史数据使用Holt-Winters等模型进行业务数据预测,当我们都歌词 歌词 的实际值与预测值不在 置信区间内将直接进行告警。

根据我们都歌词 歌词 的运维经验,在出现生产事故时可能会涉及到多个开关的切换,这里就那末多 针对不同的故障场景预先设置服务保护预案,那末多 在出现现象时通过一键操作对多个服务保护开关进行预设情况报告的变更。我们都歌词 歌词 既然有了应对不同故障场景的服务保护预案,就那末多 老要 来验证哪此服务保护预案是否真的那末多 起到预期的效果。

 我们都歌词 歌词 定期进行的外卖全链路压测,那末多 召集相关业务方进行准备和跟进,这其中涉及的数据构造累积会关联到什么都有业务方的改造、验证、准备工作。如图13所示,我们都歌词 歌词 那末多 通过压测计划串联整个准备、验证过程,尽量少的许多人为活动参与到整个过程中。这其中我们都歌词 歌词 那末多 进行如下工作的准备:

发现现象–>诊断现象–>补救现象,你这种过程每一步都那末多 不断地提升准确度,整个流程那末多 通过全链路压测不断验证,当许多场景准确度非常高的前一天,就那末多 变为自动化方案。

图14 自动化建设后期发力点

综上所述,我们都歌词 歌词 那末多 帮助开发人员准确地定位现象和快速补救现象。

美团外卖自2013年上线至2017年10月份,在非要4年的时间里,日提单已达50万,日完成订单突破1500万,如图3所示。这期间,业务产品老要 发生高速迭代的过程中,许多数据访问的服务量会达到日均120亿+次,QPS近16万。现在可能在午高峰出现2个多多小小的事故,就会造成比较大的损失。

图2 美团外卖常规业务监控图

① 降级开关:可能业务快速发展,在代码中会有成百上千的降级开关。在业务出现异常时那末多 手动进行降级操作。

服务保护是业务运维终端法律办法,我们都歌词 歌词 那末多 在软件那末多 能让用户很方便地直达对应的服务保护,这里我们都歌词 歌词 那末多 将服务保护与业务大盘、核心链路进行整合,在开发人员发现现象时那末多 方便地进入对应的服务保护预案。有了哪此保护法律办法与故障演练功能,结合与核心链路的关系,就那末多 结合故障诊断与全链路压测进行自动化方面的建设了。

图3 美团外卖重要成长里程碑

图1 用户深度的美团外卖技术体系 

图10 提升全链路压测给我们都歌词 歌词 带来的收益

声明:本文可能美团点评技术团队微信公众号授权转发。

图11 异常点自动检测

图7 业务监控大盘及拓展能力 

如图7所示,业务大盘不光那末多 展示业务监控指标,还那末多 有很强的对外扩展能力,比如:

核心链路也是系统主要的使用入口,用户那末多 通过核心链路快速定位是哪2个多多调用链出现了现象。如图8所示,这里会涉及2个多多步骤:

我们都歌词 歌词 在做核心链路建设的前一天,那末多 收集各个服务节点的报警事件,哪此报警事件有服务调用时端到端的监控指标,还有服务自身SLA的监控指标。在和开发人员进行沟通的前一天了解到我们都歌词 歌词 平时配置哪此监控指标的前一天耗费了多量的人力,每个指标的报警阈值都那末多 反复调整那末多 达到2个多多理想情况报告,基于哪此监控痛点,我们都歌词 歌词 希望那末多 通过分析历史数据来自动的检测出异常点,并自动计算出应有的报警阈值并设置。如图11所示,我们都歌词 歌词 根据不同监控指标的特点,确定不同的基线算法,并计算出其置信区间,用来帮助我们都歌词 歌词 更加准确的检测异常点。比如我们都歌词 歌词 的业务周期性比较强,大多数监控指标后会在历史同期呈现出正太分布,你这种前一天那末多 拿真实值与均值进行比较,其差值在N倍标准差之外,则认为该真实值是异常点。

我们都歌词 歌词 希望通过许多自动化法律办法提升运维强度,从而将开发人员从日常的业务运维工作中解放出来,先来看2个多多用户使用场景:

① 我们都歌词 歌词 那末多 给核心链路上的服务节点进行健康评分,根据评分模型来界定现象严重的链路。这里我们都歌词 歌词 会根据服务的各个指标来描绘2个多多服务的现象画像,现象画像中的指标也会有权重划分,比如:当服务出现了失败率报警、TP99报警,多量异常日志则会进行高权重的加分。

结合我们都歌词 歌词 针对典型故障场景前一天建立的服务保护关系,自动触发对应的服务保护预案。

我们都歌词 歌词 会定期对生产系统进行全链路压测,一并为了压测数据不污染真实的业务数据,会对压测流量监控进行隔离。

图13 压测计划自动化

如图5所示,触发服务保护有两条路径。

① 各种维度的事件通知、报警事件充斥着开发人员的IM,我们都歌词 歌词 那末多 花什么都有精力去配置和优化报警阈值、报警等级才那末多出现什么都有误报。我们都歌词 歌词 希望那末多 将各种服务的报警指标和阈值标准化、自动化,怎么让自动收集哪此事件进行统计。一方面那末多 帮助开发人员提前发现现象潜在的风险,许多人面为我们都歌词 歌词 找出现象的根本原因提供有力的数据支持。

美团外卖的定位是“围绕在线商品交易与及时送达的O2O电商交易平台”。图1日后用户在使用美团外卖App过程中涉及到的技术模块,历经用户下单–>系统发给商家–>商家准备外卖–>配送,到最后用户收到商品比如热乎乎的盒饭,整个过程的时间那末多 控制在半小时之内。在这眼前 ,整个产品线上后会涉及什么都有数据分析、统计、结算、合同等各个端的交互,怎么让,对一致性的要求高,一并并发量也很高。

在故障演练的一并,我们都歌词 歌词 那末多 结合核心链路的关系数据准确定位出与故障场景强相关的现象节点。

我们都歌词 歌词 的服务保护法律办法有一累积是通过Hystrix进行自动熔断,另外一累积是我们都歌词 歌词 可能发生的上千个降级、限流开关,这累积开关平时那末多 开发人员根据许多人的运维经验来手动触发。我们都歌词 歌词 可能那末多 根据各种监控指标准确的诊断出异常点,并前一天将可能确定的异常场景与我们都歌词 歌词 的服务保护预案进行关联,就那末多 自动化的进行服务保护预案的触发,如图12所示。

那末多 补救现象

结语

图8 核心链路产品建设路径

怎么让,我们都歌词 歌词 的核心目标是,当整个方案那末多 自动化进行下去前一天,对于用户来说的使用场景就变成了:收到异常报警->收到业务服务恢复通知。随着自动化方案那末完备,开发人员那末多 更加关注业务逻辑的开发。

在整个流程中,我们都歌词 歌词 那末多 最终确认各个环境的运行效果是否达到了我们都歌词 歌词 的预期,就那末多 每个环节后会相应的监控日志输出,最终自动化产出最终的压测报告。

图4 开发人员日常监控痛点

生产对应的事故不常有,肯定日还能能只指望生产真的出现现象才进行预案的验证,还那末多 针对不同的故障进行模拟。当我们都歌词 歌词 生产服务出现现象时,不管是可能网络原因还是硬件故障,大多数表现在服务上的可能是服务超时可能更慢、抛出异常。我们都歌词 歌词 前期主要针对这几点做到那末多 对核心链路上任一服务节点进行故障演练,生产故障可能会一并多个节点出现故障,这里就那末多 我们都歌词 歌词 的故障演练那末多 能支持预案管理。

自动化路程

④ 开发人员收到各种报警前一天,通常后会根据许多人的经验进行现象的排查,哪此排查经验详细那末多 标准化(比如对某个服务的TP99异常,那末多 进行的排查操作),现象排查流程标准化前一天,就那末多 通过计算机自动化。我们都歌词 歌词 提高诊断的准确度,就那末多 将你这种流程更加智能化,减少人为参与。

② 公司有多套监控系统,它们有其他人的职责定位,怎么让互相那末关联,什么都有开发人员在排查现象时那末多 带着参数在不同的系统之间切换,这就降低了定位现象的强度。

整个压测计划的自动化线程中,将逐渐减少系统运行中人为参与的累积,逐步提升全链路压测强度。我们都歌词 歌词 希望,用户点击2个多多开关前一天刚结速压测计划,怎么让等待时间压测结果就那末多 了。

可能是更加偏向业务的运维系统,我们都歌词 歌词 针对敏感的业务指标进行了相应的权限管理。

① 当出现业务指标异常时,根据后台的监控数据分析,那末多 手动可能自动进行事件标记,告知开发人员是哪此原因引起了业务指标的波动,做到用户信息量的快速同步。

外卖业务每天在特定时刻流量陡增明显,有前一天与第三方做的许多活动会造成系统流量瞬间达到午高峰的2~3倍,如图2所示。

② 第二条,用户那末多 能直接通过诊断报警进入对应的核心链路,查看最终引起异常的根本原因,引导用户判断是否那末多 触发相应的服务保护预案。

① 每根,当用户在前期接收到我们都歌词 歌词 的诊断报警后,直接被引导进入该报警可能会影响到业务大盘。这时我们都歌词 歌词 要查看业务图表,可能影响到业务,引导用户直接进入该业务图表对应的核心链路,定位出现象的根本原因,进而再判断是否要触发该核心链路上对应的服务保护开关或预案。

背景

重点系统体系建设

服务保护&故障演练模块是让我们都歌词 歌词 的业务运维体系形成闭环的重要累积,该模块那末多 具备的核心功能如图9所示。针对不同的保护需求,我们都歌词 歌词 会有不类事型的服务保护开关,这里主要有如下几种:

③ Hystrix自动熔断:那末多 通过监控异常数、线程数等简单指标,快速保护我们都歌词 歌词 的服务健康情况报告那末多急剧恶化。

为了增加系统使用场景,我们都歌词 歌词 那末多 支持移动端,使用户那末多 在任何地方通过手机就那末多 查看许多人关心的监控大盘并触发服务保护预案。

外卖业务会有非常多的业务指标进行监控,业务指标和系统指标、服务指标不同,那末多 业务方根据不同的业务自行上报监控数据。业务大盘作为业务运维系统的使用入口,那末多 让开发人员快速查看许多人关心的业务指标的实时情况报告以及最近几天的走势。

首先从业务两种生活具有的许多特点来讲一下自动化业务运维的必要性。