从美团程序员的灾难，看美团外卖自动化运维体系建设

作者：刘宏伟 2017-12-08 18:45:41

12 月 7 日中午，有网友发微博称，外卖订单付款出现延迟，部分用户付款后系统仍提示尚未付款；团购页面内容也无法正常显示。美团服务器出现大面积崩溃。

12 月 7 日中午，有网友发微博称，外卖订单付款出现延迟，部分用户付款后系统仍提示尚未付款；团购页面内容也无法正常显示。美团服务器出现大面积崩溃。

这是一个上了热搜，并让大家吃不上午饭的 Bug。

饭点时间，遇到这种事情，也真的糟心了！而且，这种情况还不是个例，在微博上一搜，反映美团外卖这种情况的还真不少。

并且有人看到显示支付不成功，连续尝试付款了好多次，但是钱出去了，却既没有下成单，也没有退款。

想找美团外卖的客服咨询情况，但是却一直联系不上，无论是网上客服还是电话客服。

不过，12:16 分美团微博回复：订单问题已修复，订单问题已修复，订单问题已修复。

12:28 分 APP 仍然处于宕机状态。下午12：43分，美团在微博上回应：经紧急修复后，现已陆续恢复，重复支付的订单会原路退回，系统故障期间未完成服务的订单，用户可以无责取消退款。

随后，部分重复下单的网友已经获得了退款和美团的致歉红包。此次事故对美团的工程师们来说，简直是年度灾难，很可能直接导致美团的程序员们错失丰厚年终奖的机会。

事实上，美团并非第一次出现类似的问题，据了解，就在前天，12 月 5 日，美团外卖也出现了一次服务器崩溃事故，中午当用户点完餐，想要查看订单进度时，页面要么显示“系统处理异常”，要么是“订单不存在”，使得用户无法追踪自己的餐品配送进度。

美团后台宕机，对此，不少网友吐槽美团的程序员是不是饿了去吃饭了，忽视了系统的 Bug，还是被祭天了？是不是放寒假了？

是不是下一步就要被祭天了

继暴风影音、虾米音乐后，又一程序员要被祭天了。有网友还称，饿了么安插在美团身边的程序员终于发力了。

还遭到了隔壁一遇大事儿就崩溃的微博技术的调侃：

对此，有不少网友调侃道：

网友的阴谋论派：

一次的系统宕机可能是偶然，或是突发事件如之前鹿晗公布恋情致微博系统崩溃，但是连续多次的宕机，也许就是技术的缺陷了。

下面小编给大家带来一些干货，一起来看看日订单量超1600万的美团外卖自动化业务运维之路。

美团外卖业务在互联网行业是非常独特的，不仅流程复杂——从用户下单、商家接单到配送员接单、交付，而且压力和流量在午、晚高峰时段非常集中。

同时，外卖业务的增长非常迅猛，自 2013 年 11 月上线到最近峰值突破 1600 万，还不到 4 年。

在这种情况下，一旦出现事故，单纯靠人工排查解决问题，存在较多的局限性。

本文将详细解析美团外卖运维过程中问题发现、根因分析、问题解决等自动化运维体系的建设历程与相关设计原则。

外卖业务特点 

首先从业务本身具有的一些特点来讲一下自动化业务运维的必要性。

业务流程复杂

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

美团外卖的定位是“围绕在线商品交易与及时送达的 O2O 电商交易平台”。

图 1 就是用户在使用美团外卖 App 过程中涉及到的技术模块，历经用户下单-->系统发给商家-->商家准备外卖-->配送，到最后用户收到商品比如热乎乎的盒饭，整个过程的时间需要控制在半小时之内。

在这背后，整个产品线上还会涉及很多数据分析、统计、结算、合同等各个端的交互，因此，对一致性的要求高，同时并发量也很高。

每日流量徒增明显

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

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

业务增长迅猛

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

美团外卖自 2013 年上线至 2017 年 10 月份，在不到 4 年的时间里，日提单已达 2000 万，日完成订单突破 1600 万，如图 3 所示。

在这期间，业务产品一直处在高速迭代的过程中，某些数据访问的服务量会达到日均 120 亿+次，QPS 近 40 万。现在如果在午高峰出现一个小小的事故，就会造成比较大的损失。

综上所述，我们需要帮助开发人员准确地定位问题和快速解决问题。

需要解决问题

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

我们在日常的业务运维工作中经常会碰到一些问题困扰着开发人员，如图 4 所示。

现在主要有四大痛点：

• 各种维度的事件通知、报警事件充斥着开发人员的 IM，我们需要花很多精力去配置和优化报警阈值、报警等级才不会出现很多误报。

我们希望可以将各种服务的报警指标和阈值标准化、自动化，然后自动收集这些事件进行统计。一方面可以帮助开发人员提前发现问题潜在的风险；另一方面为我们找出问题的根本原因提供有力的数据支持。

• 公司有多套监控系统，它们有各自的职责定位，但是互相没有关联，所以开发人员在排查问题时需要带着参数在不同的系统之间切换，这就降低了定位问题的效率。
• 我们的代码中会有大量的降级限流开关，在服务异常时进行相应的保护操作。这些开关随着产品快速地迭代，我们并不能确定它们是否还有效。

另外，我们需要较准确地进行容量规划以应对快速增长的业务量。这些都需要通过全链路压测帮我们不断地验证，并发现性能瓶颈，有效地评估服务容量。

• 开发人员收到各种报警之后，通常都会根据自己的经验进行问题的排查，这些排查经验完全可以标准化。

比如对某个服务的 TP99 异常，需要进行的排查操作，问题排查流程标准化之后，就可以通过计算机自动化。我们提高诊断的准确度，就需要将这个流程更加智能化，减少人为参与。

核心目标

我们希望通过一些自动化措施提升运维效率，从而将开发人员从日常的业务运维工作中解放出来，先来看一个用户使用场景，如图 5 所示，触发服务保护有两条路径。

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

第一条，当用户在前期接收到我们的诊断报警后，直接被引导进入该报警可能会影响到业务大盘。

这时我们要查看业务图表，如果影响到业务，引导用户直接进入该业务图表对应的核心链路，定位出问题的根本原因，进而再判断是否要触发该核心链路上对应的服务保护开关或预案。

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

发现问题-->诊断问题-->解决问题，这个过程每一步都需要不断地提升准确度，整个流程需要通过全链路压测不断验证，当某些场景准确度非常高的时候，就可以变为自动化方案。

因此，我们的核心目标是，当整个方案可以自动化进行下去之后，对于用户来说的使用场景就变成了：收到异常报警->收到业务服务恢复通知。

随着自动化方案越来越完备，开发人员可以更加关注业务逻辑的开发。

重点系统体系建设

确定了核心目标，我们开始着手开发产品。接下来就介绍一下我们建设这套系统的核心产品以及各个产品模块之间的关联。

体系架构

如图 6 所示，在自动化业务运维系统中，业务大盘与核心链路作为用户使用的入口，一旦用户查看业务指标出现问题，我们就需要快速定位该业务指标异常的根本原因。

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

我们通过对核心链路上服务状态的分析，帮助开发人员定位最终的问题节点，并建议开发人员需要触发哪些服务保护预案。

业务大盘的预测报警、核心链路的红盘诊断报警以及已经收集到各个维度的报警事件，如果能对它们做进一步的统计分析，可以帮助开发人员从更加宏观的角度提前发现服务可能潜在的问题，相当于提前对服务做健康检查。

我们需要定期通过全链路压测来不断验证问题诊断和服务保护是否有效，在压测时可以看到各个场景下的服务健康状态，对服务节点做到有效的容量规划。

业务大盘

外卖业务会对非常多的业务指标进行监控，业务指标和系统指标、服务指标不同，需要业务方根据不同的业务自行上报监控数据。

业务大盘作为业务运维系统的使用入口，可以让开发人员快速查看自己关心的业务指标的实时状态以及最近几天的走势。

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

如图 7 所示，业务大盘不光需要展示业务监控指标，还需要有很强的对外扩展能力，比如：

• 当出现业务指标异常时，根据后台的监控数据分析，可以手动或者自动进行事件标记，告知开发人员是什么原因引起了业务指标的波动，做到用户信息量的快速同步。
• 可以带着时间戳与类型快速引导开发人员进入其他监控系统，提高开发人排查问题的效率。

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

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

因为是更加偏向业务的运维系统，我们针对敏感的业务指标进行了相应的权限管理。

为了增加系统使用场景，我们需要支持移动端，使用户可以在任何地方通过手机就可以查看自己关心的监控大盘并触发服务保护预案。

核心链路

核心链路也是系统主要的使用入口，用户可以通过核心链路快速定位是哪一个调用链出现了问题，如图 8 所示：

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

这里会涉及两个步骤：

• 我们需要给核心链路上的服务节点进行健康评分，根据评分模型来界定问题严重的链路。
• 这里我们会根据服务的各个指标来描绘一个服务的问题画像，问题画像中的指标也会有权重划分，比如：当服务出现了失败率报警、TP99 报警，大量异常日志则会进行高权重的加分。

当我们确认完某条链路出现了问题，在链路上越往后的节点可能是引起问题的根节点，我们会实时获取该节点更多相关监控指标来进行分析诊断。

这里会融合开发人员日常排查问题的 SOP，最终可能定位到是这个服务节点某些服务器的磁盘或者 CPU 等问题。

我们最终会发出问题诊断结果，这个结果在发出之后，还需要收集用户的反馈，判断诊断结果是否准确，为我们后续优化评分定位模型与诊断模型提供有力的数据支持。

在核心链路建设前期，我们会建议开发人员进行相应的服务保护预案触发，当我们的诊断结果足够准确之后，可以针对固定问题场景自动化触发服务保护预案，以缩短解决问题的时间。

服务保护&故障演练

图 9：服务保护&故障演练模块的核心功能

服务保护&故障演练模块是让我们的业务运维体系形成闭环的重要部分，该模块需要具备的核心功能如图 9 所示。

针对不同的保护需求，我们会有不同类型的服务保护开关，这里主要有如下几种：

• 降级开关：由于业务快速发展，在代码中会有成百上千的降级开关。在业务出现异常时需要手动进行降级操作。
• 限流开关：有些针对特定业务场景需要有相应的限流保护措施。比如：针对单机限流主要是对自身服务器的资源保护，针对集群限流主要是针对底层的 DB 或者 Cache 等存储资源进行资源保护，还有一些其他限流需求都是希望可以在系统出现流量异常时进行有效地保护。
• Hystrix自动熔断：可以通过监控异常数、线程数等简单指标，快速保护我们的服务健康状态不会急剧恶化。

根据我们的运维经验，在出现生产事故时可能会涉及到多个开关的切换，这里就需要针对不同的故障场景预先设置服务保护预案，可以在出现问题时通过一键操作对多个服务保护开关进行预设状态的变更。

我们既然有了应对不同故障场景的服务保护预案，就需要时不时来验证这些服务保护预案是否真的可以起到预期的效果。

生产对应的事故不常有，肯定也不能只指望生产真的出现问题才进行预案的验证，还需要针对不同的故障进行模拟。

当我们生产服务出现问题时，不管是因为网络原因还是硬件故障，大多数表现在服务上的可能原因是服务超时或者变慢、抛出异常。

我们前期主要针对这几点做到可以对核心链路上任一服务节点进行故障演练，生产故障可能会同时多个节点出现故障，这里就需要我们的故障演练也支持预案管理。

服务保护是业务运维终端措施，我们需要在软件上可以让用户很方便地直达对应的服务保护，这里我们需要将服务保护与业务大盘、核心链路进行整合，在开发人员发现问题时可以方便地进入对应的服务保护预案。

有了这些保护措施与故障演练功能，结合与核心链路的关系，就可以结合故障诊断与全链路压测进行自动化方面的建设了。

整合全链路压测

我们现在定期会组织外卖全链路压测，每次压测都会涉及很多人的配合，如果可以针对单一压测场景进行压测将会大大缩短我们组织压测的成本。

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

如图 10 所示，我们现在主要在全链路压测的时候，针对压测流量进行不同场景的故障演练，在制造故障的同时，验证服务保护预案是否可以像预期那样启动保护服务的目的。

后面会讲一下我们针对全链路压测自动化建设思路。

自动化路程

前面主要介绍了我们在做基于业务的运维系统时需要的各个核心功能，下面重点介绍一下，我们在整个系统建设中，自动化方面的建设主要集中在什么地方。

异常点自动检测

我们在做核心链路建设的时候，需要收集各个服务节点的报警事件，这些报警事件有服务调用时端到端的监控指标，还有服务自身 SLA 的监控指标。

在和开发人员进行沟通的时候了解到他们平时配置这些监控指标的时候耗费了大量的人力，每个指标的报警阈值都需要反复调整才能达到一个理想状态。

基于这些监控痛点，我们希望可以通过分析历史数据来自动的检测出异常点，并自动计算出应有的报警阈值并设置。

图 11：异常点自动检测

如图 11 所示，我们根据不同监控指标的特点，选择不同的基线算法，并计算出其置信区间，用来帮助我们更加准确的检测异常点。

比如我们的业务周期性比较强，大多数监控指标都是在历史同期呈现出正态分布，这个时候可以拿真实值与均值进行比较，其差值在 N 倍标准差之外，则认为该真实值是异常点。

自动触发服务保护

我们的服务保护措施有一部分是通过 Hystrix 进行自动熔断，另外一部分是我们已经存在的上千个降级、限流开关，这部分开关平时需要开发人员根据自己的运维经验来手动触发。

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

如图 12 所示，我们如果能够根据各种监控指标准确的诊断出异常点，并事先将已经确定的异常场景与我们的服务保护预案进行关联，就可以自动化的进行服务保护预案的触发。

压测计划自动化

我们定期进行的外卖全链路压测，需要召集相关业务方进行准备和跟进，这其中涉及的数据构造部分会关联到很多业务方的改造、验证、准备工作。

图 13：压测计划自动化

如图 13 所示，我们需要通过压测计划串联整个准备、验证过程，尽量少的有人为活动参与到整个过程中。

我们需要进行如下工作的准备：

• 针对真实流量的改造，基础数据构造、数据脱敏、数据校验等尽可能通过任务提前进行。
• 进入到流量回放阶段，我们可以针对典型的故障场景进行故障预案的触发（比如：Tair 故障等）。
• 在故障演练的同时，我们可以结合核心链路的关系数据准确定位出与故障场景强相关的问题节点。
• 结合我们针对典型故障场景事先建立的服务保护关系，自动触发对应的服务保护预案。
• 在整个流程中，我们需要最终确认各个环境的运行效果是否达到了我们的预期，就需要每个环节都有相应的监控日志输出，最终自动化产出最终的压测报告。

整个压测计划的自动化进程中，将逐渐减少系统运行中人为参与的部分，逐步提升全链路压测效率。

我们希望，用户点击一个开关开始压测计划，然后等待压测结果就可以了。

结语

在整个业务运维系统建设中，只有更加准确定位问题根节点，诊断出问题根本原因才能逐步自动化去做一些运维动作（比如：触发降级开关，扩容集群等）。

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

如图 14 所示，我们会在这些环节的精细化建设上进行持续投入，希望检测到任意维度的异常点，向上推测出可能会影响哪些业务指标，影响哪些用户体验；向下依托于全链路压测可以非常准确的进行容量规划，节省资源。

作者：刘宏伟

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

责任编辑：武晓燕 来源： 美团点评技术团队