美团外卖自动化业务运维系统建设
写在前面
美团外卖作为O2O领域领先的电商平台, 到现在具有业务流程复杂, 业务增长迅猛等特点。在对业务系统稳定性与时效性都有较高要求的前提下，单纯靠人工排查解决问题，存在较多的局限性。下面给大家主要介绍一下从外卖业务自身特点出发，围绕业务展开问题发现，根因分析，问题解决等自动化运维体系建设历程与相关设计原则。
外卖业务特点
本章主要给大家介绍一下外卖的业务特点，从业务出发，介绍我们进行自动化业务运维的必要性。
- 业务流程复杂
美团外卖定位：围绕在线商品交易与及时送达的O2O电商交易平台。如图2-1所示，从用户行为角度，给出了美团外卖技术体系覆盖，这其中业务后台服务交互复杂，从用户下单商家接单->骑手接单->发配送->用户收到热乎乎的外卖，我们需要在20多分钟之内完成这一系列流程。在这后面，整个产品线上还会涉及很多数据分析，统计，结算，合同等各个端的交互，一致性要求高，并发量高。
- 每日流量陡增明显
外卖业务每天10点开始开始陡增，在11：30左右达到午高峰，在90分钟内， 流量陡增5倍多，有的时候还会和第三方做一些活动会造成系统流量瞬间达到午高峰的2~3倍，如图2-2所示。
- 业务增长迅猛
从2013年上线到2017年10月份日提单2000万，日完成订单1600万，只经历了不到四年的时间，如图2-3所示。业务产品一直处在高速迭代的过程，某些数据访问服务服务会达到日均120亿+访问， qps近40w，现在午高峰只要是一个小小的事故，就会引起比较大的损失。我们需要帮助开发人员快速的准确定位问题和快速解决问题。
需要解决的问题
我们在日常的业务运维工作中经常会碰到一些问题困扰着开发人员，如图3-1所示，主要有四大痛点：
各种维度的事件通知，报警事件充斥着开发人员的IM，我们需要花很多精力去优化配置报警阈值、报警等级才不会出现很多误报。我们希望可以将各种服务的报警指标、阈值标准化，自动化。然后自动收集这些事件进行统计，一方面可以帮助开发人员提前发现问题潜在的风险，另一方面为我们定位问题根因提供有力的数据支持。
公司有多套监控系统，它们之间的有各自的职责定位，但是这些系统之间没有关联性，开发人员在排查问题时需要带着参数在不同的系统之间切换，这就降低了开发人员定位问题的效率。
我们的代码中会有大量的降级限流开关，在服务异常时进行相应的保护操作，这些开关随着产品快速的迭代，是否还有效，我们并不能确定。另外，我们需要较准确的进行容量规划以应对快速增长的业务量。这些都需要通过全链路压测帮我们不断的验证，并发现性能瓶颈，有效的评估服务容量。
开发人员收到各种报警之后，通常都会根据自己的经验进行问题的排查，这些排查经验完全可以标准化(比如：某个服务的TP99异常，需要怎么排查)，问题排查流程标准化之后，就可以通过计算机自动化。我们为了问题定位、诊断越来越准确，希望可以将这一排查问题的流程更加智能化，以减少人为参与。
核心目标
我们为了将开发人员从日常的业务运维工作中解放出来，希望可以通过一些自动化措施提升运维效率。下面通过一个用户使用的场景描述一下我们的核心目标，具体如图4-1所示：
前期当用户接收到我们的诊断报警后，直接引导用户进入该报警可能会影响的业务大盘，查看业务图表，如果影响到业务，引导用户直接进入该业务图表对应的核心链路，定位最终的问题根本原因，从而判断是否要触发该核心链路上对应的服务保护开关或预案，以达到快速解决问题的目的。
用户也可以直接通过诊断报警进入对应的核心链路，查看最终引起异常的根本原因，引导用户判断是否需要触发相应的服务保护预案。
发现问题->诊断问题->解决问题 这个过程每一步都需要不断的提升准确度，我们可以通过全链路压测不断的验证这一流程的准确度，当某些场景准确度非常高的时候，可以变为自动化方案。
当整个方案可以自动化进行下去之后， 对于用户来说的使用场景就变成了：收到异常报警->收到业务服务恢复通知。随着自动化方案越来越完备，开发人员可以更加关注业务逻辑的开发。
重点系统体系建设
接下来主要给大家介绍一下我们建设的这套系统的核心产品，以及各个产品模块之间的关联关系。关于这几块的设计细节与我们碰到的坑，我们陆续会有更加针对性的博客分享出来。
体系架构
如图5-1所示，在自动化业务运维系统中，业务大盘与核心链路作为用户使用的入口，用户一般查看业务指标出现问题，需要快速定位该业务指标异常的根因。我们通过对核心链路上服务状态的分析，帮助开发人员定位最终的问题节点，并建议开发人员需要触发哪些服务保护预案。业务大盘的预测报警、核心链路的红盘诊断报警、以及已经收集到的各个维度的报警事件，如果能对它们进行进一步的统计分析，是可以帮助开发人员从更加宏观的角度提前发现服务可能潜在的问题，提前对服务做健康检查。我们需要定期通过全链路压测来不断验证问题诊断，服务保护是否有效，在压测时可以看到各个场景下的服务健康状态，对服务节点做到有效的容量规划。
业务大盘
外卖业务会有非常多的业务指标进行监控，这些业务指标和系统指标与服务指标不同，需要业务方根据不同的业务自行上报监控数据。业务大盘作为业务运维系统的使用入口，大家可以直接通过业务大盘快速查看自己关心的业务指标的实时状态以及最近几天的走势。如图5-2所示，业务大盘不光需要展示业务监控指标，还需要有很强的对外扩展能力，这里比如：
当出现业务指标异常时，根据后台的监控数据分析，可以手动或者自动进行事件标记，告知开发人员是什么原因引起的业务指标的波动，做到用户信息量的快速同步。
可以带着时间戳与类型快速引导开发人员进入其他监控系统，提高开发人排查问题的效率。
我们会定期对生产系统进行全链路压测，为了压测数据不污染真实的业务数据，我们也对压测流量监控进行了隔离。
外卖业务场景，使我们大多数业务监控数据都呈现出很强的周期性，针对业务数据我们可以利用历史数据使用Holt-Winters等模型进行业务数据预测，当我们的实际值与预测值不在置信区间内将直接进行告警。
因为是更加偏向业务的运维系统，我们针对敏感的业务指标进行了相应的权限管理。
为了增加系统使用场景，我们需要支持移动端，使用户可以在任何地方通过手机就可以查看自己关心的监控大盘并触发服务保护预案。
核心链路
核心链路也是系统主要的使用入口，用户可以通过核心链路快速定位是哪一个调用链出现问题。如图5-3所示，这里会涉及两个步骤：
我们需要给核心链路上的服务节点进行健康评分，根据评分模型来界定问题严重的链路。这里我们会根据服务的各个指标来描绘一个服务的问题画像，问题画像中的指标也会有权重划分，比如：当服务出现了失败率报警，TP99报警，大量异常日志则会进行高权重的加分。
当我们确认完某条链路出现了问题，在链路上越往后的节点可能是引起问题的根节点，我们会实时获取该节点更多相关监控指标来进行分析诊断，这里会融合开发人员日常排查问题的SOP，最终可能定位到是这个服务节点的某些服务器的磁盘或者cpu等有问题。
我们最终会发出问题诊断结果，这个结果在发出之后，还需要收集用户的反馈，判断诊断结果是否准确，为我们后续优化评分定位模型与诊断模型提供有力的数据支持。在核心链路建设前期，我们需要建议开发人员进行相应的服务保护预案触发，当我们的诊断结果足够准确之后，可以针对固定问题场景自动化触发服务保护预案，以缩短解决问题的时间。
服务保护&故障演练
服务保护&故障演练模块是让我们的业务运维体系形成闭环的重要部分，通过图5-4给大家展示了该模块都需要具备哪些核心功能。针对不同的保护需求，我们会有不同类型的服务保护开关，这里主要有如下几种：
降级开关：由于业务快速发展，在代码中会有成百上千的降级开关。在业务出现异常时需要手动进行降级操作。
限流开关：有些针对特定业务场景需要有相应的限流保护措施，比如：针对单机限流主要是对自身服务器的资源保护，针对集群限流主要是针对底层的DB或者cache等存储资源进行资源保护，还有一些其他限流需求都是希望可以在系统出现流量异常时有效的进行保护。
Hystrix自动熔断：可以通过监控异常数，线程数等简单指标监控快速保护我们的服务健康状态不会急剧恶化。
根据我们的运维经验，在出现生产事故时可能会涉及到多个开关的切换，这里我们就需要针对不同的故障场景预先设置服务保护预案，可以在出现问题时通过一键操作对多个服务保护开关进行预设状态的变更。我们既然有了应对不同故障场景的服务保护预案，就需要时不时来验证这些服务保护预案是否真的可以起到预期的效果。生产对应的事故不常有，肯定也不能只指望生产真的出现问题才进行预案的验证，这里我们还需要针对不同的故障进行模拟。当我们生产服务出现问题时，不管是因为网络原因还是硬件故障，大多数表现在服务上的可能是：服务超时或者变慢、抛出异常。我们前期主要针对这几点做到可以对核心链路上任一服务节点进行故障演练，生产故障可能会同时多个节点出现故障，这里就需要我们的故障演练也需要支持预案管理。
服务保护是业务运维终端措施，我们需要在软件上可以让用户很方便的直达对应的服务保护，这里我们可以方便的将服务保护与业务大盘、核心链路进行整合，在开发人员发现问题时可以方便的进入对应的服务保护预案。有了这些保护措施与故障演练功能，结合与核心链路的关系，就可以与故障诊断与全链路压测进行自动化方面的建设了。
整合全链路压测
我们现在定期会组织外卖全链路压测，每次压测都会涉及很多人的配合，如果可以针对单一压测场景进行压测将会大大缩短我们组织压测的成本。如图5-5所示，我们现在主要在全链路压测的时候，针对压测流量进行不同场景的故障演练，在制造故障的同时，验证服务保护预案是否可以像预期那样启动保护服务的目的。后面会讲一下我们针对全链路压测自动化建设思路。
自动化路程
上面主要介绍了我们在做基于业务的运维系统时需要的各个核心功能，下面重点介绍一下，我们在整个系统建设中，自动化方面的建设主要集中在什么地方。
异常点自动检测
我们在做核心链路建设的时候，需要收集各个服务节点的报警事件，这些报警事件有服务调用时端到端的监控指标，还有服务自身SLA的监控指标。在和开发人员进行沟通的时候了解到他们平时配置这些监控指标的时候耗费了大量的人力，每个指标的报警阈值都需要反复调整才能达到一个理想状态，基于这些监控痛点，我们希望可以通过分析历史数据来自动的检测出异常点，并自动计算出应有的报警阈值并设置。如图6-1所示，我们根据不同监控指标的特点，选择不同的基线算法，并计算出其置信区间，用来帮助我们更加准确的检测异常点。比如我们的业务周期性比较强，大多数监控指标都是在历史同期呈现出正太分布，这个时候可以拿真实值与均值进行比较，其差值在N倍标准差之外，则认为该真实值是异常点。
自动触发服务保护
我们的服务保护措施有一部分是通过Hystrix进行自动熔断，另外一部分是我们已经存在的上千个降级、限流开关，这部分开关平时需要开发人员根据自己的运维经验来手动触发。我们如果能够根据各种监控指标准确的诊断出异常点，并事先将已经确定的异常场景与我们的服务保护预案进行关联，就可以自动化的进行服务保护预案的触发，如图6-2所示。
压测计划自动化
我们定期进行的外卖全链路压测，需要召集相关业务方进行准备和跟进，这其中涉及的数据构造部分会关联到很多业务方的改造、验证、准备工作。如图6-3所示，我们需要通过压测计划串联整个准备、验证过程，尽量少的有人为活动参与到整个过程中。这其中我们需要进行如下工作的准备：
针对真实流量的改造，基础数据构造，数据脱敏，数据校验等尽可能通过任务提前进行。
进入到流量回放阶段，我们可以针对典型的故障场景进行故障预案的触发(比如：Tair故障等)
在故障演练的同时，我们可以结合核心链路的关系数据准确定位出与故障场景强相关的问题节点。
结合我们针对典型故障场景事先建立的服务保护关系，自动触发对应的服务保护预案。
在整个流程中，我们需要最终确认各个环境的运行效果是否达到了我们的预期，就需要每个环节都有相应的监控日志输出，最终自动化产出最终的压测报告。
整个压测计划的自动化进程中，将逐渐减少系统运行中人为参与的部分，逐步提升全链路压测效率。期望用户点击一个开关开始压测计划，然后等待压测结果就可以了。
写在后面
在整个业务运维系统建设中，只有更加准确定位问题根节点，诊断问题根因才能逐步自动化去做一些运维动作(比如：触发降级开关，扩容集群等)。如图7-1所示，我们会在这些环节的精细化建设上进行持续投入，希望检测到任意维度的异常点，向上推测出可能会影响哪些业务指标，影响哪些用户体验；向下依托于全链路压测可以非常准确的进行容量规划，节省资源。
作者简介
刘宏伟，2016年加入美团点评，主要负责外卖业务架构相关工作，现正在围绕业务建设监控运维体系。
美团外卖C端业务架构组：基于业务、服务、数据，进行深度整合、统一架构、规范，为外卖提供统一基础服务, 收集各业务线监控数据, 进行实时分析统计。我们正在努力将开发人员从日常运维工作中彻底解放出来，打造高效的业务运维平台。我们非常欢迎有业务运维经验，熟悉异常检测算法，对业务监控运维产品有深刻理解的同仁加入我们，共同提升美团外卖服务稳定性。
联系邮箱： liuhongwei04@meituan.com
名词解释
- MCC ：美团内部配置管理系统，可以进行项目中的配置管理，开关管理等。
- CAT ：大众点评实时监控系统，具体参考深度剖析开源分布式监控CAT。
- DIGGER ：美团外卖实时业务监控系统。
- FALCON ：小米开源的监控系统，在美团主要偏向于系统指标监控。
（转载本站文章请注明作者和出处 Panda）
