美团外卖业务在互联网行业是十分奇特的，除了流程复杂——从用户下单、商家接单到配送员接单、交付，但是压力和流量在午、晚高峰时段特别集中。同时，外卖业务的下降特别迅猛，自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-等模型进行业务数据预测，当我们的实际值与预测值不在置信区间内将直接进行告警。
由于是愈发偏向业务的运维系统，我们针对敏感的业务指标进行了相应的权限管理。
为了降低系统使用场景，我们须要支持联通端，使用户可以在任何地方通过手机就可以查看自己关心的监控盘面并触发服务保护预案。
核心链路
核心链路也是系统主要的使用入口，用户可以通过核心链路快速定位是哪一个调用链出现了问题。如图8所示，这儿会涉及两个步骤：
①我们须要给核心链路上的服务节点进行健康评分，按照评分模型来划分问题严重的链路。这儿我们会依照服务的各个指标来勾勒一个服务的问题画像，问题画像中的指标也会有权重界定，例如：当服务出现了失败率报案、TP99报案，大量异常日志则会进列宽权重的加分。
②当我们确认完某条链路出现了问题外卖软件开发，在链路上越往前的节点可能是造成问题的根节点，我们会实时获取该节点更多相关监控指标来进行剖析确诊，这儿会融合开发人员日常排查问题的SOP，最终可能定位到是这个服务节点个别服务器的c盘或则CPU等问题。
图8核心链路产品建设路径
我们最终会发出问题确诊结果，这个结果在发出以后，还须要搜集用户的反馈，判定确诊结果是否确切，为我们后续优化评分定位模型与确诊模型提供有力的数据支持。在核心链路建设前期，我们会建议开发人员进行相应的服务保护预案触发，当我们的确诊结果足够确切以后，可以针对固定问题场景手动化触发服务保护预案，以减短解决问题的时间。
服务保护&故障演习
图9服务保护&故障演习模块的核心功能
服务保护&故障演习模块是让我们的业务运维体系产生闭环的重要部份，该模块须要具备的核心功能如图9所示。针对不同的保护需求，我们会有不同类型的服务保护开关，这儿主要有如下几种：
①降级开关：因为业务快速发展，在代码中会有成百上千的降级开关。在业务出现异常时须要自动进行降级操作。
②限流开关：有些针对特定业务场景须要有相应的限流保护举措。诸如：针对单机限流主要是对自身服务器的资源保护，针对集群限流主要是针对底层的DB或则Cache等储存资源进行资源保护外卖软件开发，还有一些其他限流需求都是希望可以在系统出现流量异常时有效地进行保护。
③自动熔断：可以通过监控异常数、线程数等简单指标，快速保护我们的服务健康状态不会随之恶化。
按照我们的运维经验，在出现生产车祸时可能会涉及到多个开关的切换，这儿就须要针对不同的故障场景预先设置服务保护预案，可以在出现问题时通过一键操作对多个服务保护开关进行预设状态的变更。我们既然有了应对不同故障场景的服务保护预案，就须要时常来验证这种服务保护预案是否真的可以起到预期的疗效。
生产对应的车祸不常有，肯定也不能只指望生产真的出现问题才进行预案的验证，还须要针对不同的故障进行模拟。当我们生产服务出现问题时，不管是由于网路缘由还是硬件故障，大多数表现在服务上的可能是服务超时或则变慢、抛出异常。我们前期主要针对这几点做到可以对核心链路上任一服务节点进行故障演习，生产故障可能会同时多个节点出现故障，这儿就须要我们的故障演习也须要支持预案管理。
服务保护是业务运维终端举措，我们须要在软件上可以让用户很便捷地直达对应的服务保护，这儿我们可以很容易就将服务保护与业务盘面、核心链路进行整合，在开发人员发觉问题时可以便捷地步入对应的服务保护预案。有了这种保护举措与故障演习功能，结合与核心链路的关系，就可以与故障确诊与全链路压测进行手动化方面的建设了。
整合全链路压测
我们如今定期会组织外卖全链路压测，每次压测就会涉及好多人的配合，假如可以针对单一压测场景进行压测将会大大减短我们组织压测的成本。如图10所示，我们如今主要在全链路压测的时侯，针对压测流量进行不同场景的故障演习，在制造故障的同时，验证服务保护预案是否可以像预期那样启动保护服务的目的。前面会讲一下我们针对全链路压测手动化建设思路。
图10提高全链路压测给我们带来的利润
后面主要介绍了我们在做基于业务的运维系统时须要的各个核心功能，下边重点介绍一下，我们在整个系统建设中，手动化方面的建设主要集中在哪些地方。
异常点手动检查
图11异常点手动检查
我们在做核心链路建设的时侯，须要搜集各个服务节点的报案风波，这种报案风波有服务调用时端到端的监控指标，还有服务自身SLA的监控指标。在和开发人员进行沟通的时侯了解到她们平常配置这种监控指标的时侯花费了大量的人力，每位指标的报案阀值都须要反复调整就能达到一个理想状态，基于这种监控痛点，我们希望可以通过剖析历史数据来手动的测量出异常点，并手动估算出应有的报案阀值并设置。如图11所示，我们依照不同监控指标的特性，选择不同的基线算法，并估算出其置信区间，拿来帮助我们愈发确切的检查异常点。例如我们的业务周期性比较强，大多数监控指标都是在历史同期呈现出正太分布，这个时侯可以拿真实值与均值进行比较，其差值在N倍标准差之外，则觉得该真实值是异常点。
手动触发服务保护
图12异常测量与服务保护联动
我们的服务保护举措有一部份是通过进行手动熔断，另外一部份是我们早已存在的上千个降级、限流开关，这部份开关平常须要开发人员按照自己的运维经验来自动触发。我们假如才能依据各类监控指标确切的确诊出异常点，并事先将早已确定的异常场景与我们的服务保护预案进行关联，就可以手动化的进行服务保护预案的触发，如图12所示。
压测计划手动化
图13压测计划手动化
我们定期进行的外卖全链路压测，须要召集相关业务方进行打算和跟进，这其中涉及的数据构造部份会关联到好多业务方的整修、验证、准备工作。如图13所示，我们须要通缺相测计划串联整个打算、验证过程，尽量少的有人为活动参与到整个过程中。这其中我们须要进行如下工作的打算：
整个压测计划的手动化进程中，将逐步降低系统运行中人为参与的部份，逐渐提高全链路压测效率。我们希望，用户点击一个开关开始压测计划，之后等待压测结果就可以了。
图14手动化建设后期加码点
在整个业务运维系统建设中，只有愈发确切定位问题根节点，确诊出问题根本诱因能够逐渐手动化去做一些运维动作（例如：触发降级开关，扩容集群等）。如图14所示，我们会在这种环节的精细化建设上进行持续投入，希望检查到任意维度的异常点，向下猜想出可能会影响什么业务指标，影响什么用户体验；向上依托于全链路压测可以十分确切的进行容量规划，节约资源。
刘宏伟，2016年加入美团，主要负责外卖业务构架相关工作，现正在围绕业务建设监控运维体系。
**美团外卖C端业务构架组：基于业务、服务、数据，进行深度整合、统一构架、规范，为外卖提供统一基础服务，搜集各业务线监控数据，进行实时剖析统计。我们正在努力将开发人员从日常运维工作中彻底解放下来，构建高效的业务运维平台。我们十分欢迎有业务运维经验，熟悉异常检查算法，对业务监控运维产品有深刻理解的同仁加入我们，共同提高美团外卖服务稳定性。
联系邮箱：#**
免责声明：部分文章信息来源于网络以及网友投稿，本站只负责对文章进行整理、排版、编辑，出于传递更多信息之目的，并不意味着赞同其观点或证实其内容的真实性，如本站文章和转稿涉及版权等问题，请作者在及时联系本站，我们会尽快为您处理。
