美团外卖业务在互联网行业非常独特，流程复杂，从——用户下单、商家下单到配送员下单、交付，压力和流量都非常集中在下午、晚上玩的吐司时段。 同时外卖业务增长非常快，2013年11月上线至今近期峰值突破1600万，还不到4年。 在这种情况下，一旦发生事故，单纯靠人工排除解决问题，有很多局限性。 本文详细解析问题发现、根本原因分析、问题解决等自动运输系统建设过程及相关设计原则。
首先，从业务本身所具有的几个特点出发，说明业务运输自动化的必要性。
业务流程复杂
图1用户视角的美团外卖技术体系
美国集团的外卖定位是“网上商品交易和及时配送的O2O电子商务平台”。 图1是用户在使用美团外卖APP的过程中涉及的技术模块，整个过程需要控制在30分钟内，直到用户下单、系统发送到商家、商家准备外卖、配送，最后用户收到热腾腾的便当等商品。 其背后是整个产品线中众多数据分析、统计、结算、合同等各端的交互，对一致性要求较高，同时并发性也较高。
每天的流量急剧增加
图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所示，这里会涉及两个步骤：
① 我们需要给核心链路上的服务节点进行健康评分，根据评分模型来界定问题严重的链路。这里我们会根据服务的各个指标来描绘一个服务的问题画像，问题画像中的指标也会有权重划分，比如：当服务出现了失败率报警、TP99报警，大量异常日志则会进行高权重的加分。
② 当我们确认完某条链路出现了问题，在链路上越往后的节点可能是引起问题的根节点，我们会实时获取该节点更多相关监控指标来进行分析诊断，这里会融合开发人员日常排查问题的SOP，最终可能定位到是这个服务节点某些服务器的磁盘或者CPU等问题。
图8 核心链路产品建设路径
我们最终会发出问题诊断结果，这个结果在发出之后，还需要收集用户的反馈，判断诊断结果是否准确，为我们后续优化评分定位模型与诊断模型提供有力的数据支持。在核心链路建设前期，我们会建议开发人员进行相应的服务保护预案触发，当我们的诊断结果足够准确之后，可以针对固定问题场景自动化触发服务保护预案，以缩短解决问题的时间。
服务保护&故障演练图9 服务保护&故障演练模块的核心功能
服务保护&故障演练模块是让我们的业务运维体系形成闭环的重要部分，该模块需要具备的核心功能如图9所示。针对不同的保护需求，我们会有不同类型的服务保护开关，这里主要有如下几种：
① 降级开关：由于业务快速发展，在代码中会有成百上千的降级开关。在业务出现异常时需要手动进行降级操作。
② 限流开关：有些针对特定业务场景需要有相应的限流保护措施。比如：针对单机限流主要是对自身服务器的资源保护，针对集群限流主要是针对底层的DB或者Cache等存储资源进行资源保护，还有一些其他限流需求都是希望可以在系统出现流量异常时有效地进行保护。
③ Hystrix自动熔断：可以通过监控异常数、线程数等简单指标，快速保护我们的服务健康状态不会急剧恶化。
根据我们的运维经验，在出现生产事故时可能会涉及到多个开关的切换，这里就需要针对不同的故障场景预先设置服务保护预案，可以在出现问题时通过一键操作对多个服务保护开关进行预设状态的变更。我们既然有了应对不同故障场景的服务保护预案，就需要时不时来验证这些服务保护预案是否真的可以起到预期的效果。
生产对应的事故不常有，肯定也不能只指望生产真的出现问题才进行预案的验证，还需要针对不同的故障进行模拟。当我们生产服务出现问题时，不管是因为网络原因还是硬件故障，大多数表现在服务上的可能是服务超时或者变慢、抛出异常。我们前期主要针对这几点做到可以对核心链路上任一服务节点进行故障演练，生产故障可能会同时多个节点出现故障，这里就需要我们的故障演练也需要支持预案管理。
服务保护是业务运维终端措施，我们需要在软件上可以让用户很方便地直达对应的服务保护，这里我们可以很容易就将服务保护与业务大盘、核心链路进行整合，在开发人员发现问题时可以方便地进入对应的服务保护预案。有了这些保护措施与故障演练功能，结合与核心链路的关系，就可以与故障诊断与全链路压测进行自动化方面的建设了。
整合全链路压测我们现在定期会组织外卖全链路压测，每次压测都会涉及很多人的配合，如果可以针对单一压测场景进行压测将会大大缩短我们组织压测的成本。如图10所示，我们现在主要在全链路压测的时候，针对压测流量进行不同场景的故障演练，在制造故障的同时，验证服务保护预案是否可以像预期那样启动保护服务的目的。后面会讲一下我们针对全链路压测自动化建设思路。
图10 提升全链路压测给我们带来的收益
前面主要介绍了我们在做基于业务的运维系统时需要的各个核心功能，下面重点介绍一下，我们在整个系统建设中，自动化方面的建设主要集中在什么地方。
异常点自动检测图11 异常点自动检测
我们在做核心链路建设的时候，需要收集各个服务节点的报警事件，这些报警事件有服务调用时端到端的监控指标，还有服务自身SLA的监控指标。在和开发人员进行沟通的时候了解到他们平时配置这些监控指标的时候耗费了大量的人力，每个指标的报警阈值都需要反复调整才能达到一个理想状态，基于这些监控痛点，我们希望可以通过分析历史数据来自动的检测出异常点，并自动计算出应有的报警阈值并设置。如图11所示，我们根据不同监控指标的特点，选择不同的基线算法，并计算出其置信区间，用来帮助我们更加准确的检测异常点。比如我们的业务周期性比较强，大多数监控指标都是在历史同期呈现出正太分布，这个时候可以拿真实值与均值进行比较，其差值在N倍标准差之外，则认为该真实值是异常点。
自动触发服务保护图12 异常检测与服务保护联动
我们的服务保护措施有一部分是通过Hystrix进行自动熔断，另外一部分是我们已经存在的上千个降级、限流开关，这部分开关平时需要开发人员根据自己的运维经验来手动触发。我们如果能够根据各种监控指标准确的诊断出异常点，并事先将已经确定的异常场景与我们的服务保护预案进行关联，就可以自动化的进行服务保护预案的触发，如图12所示。
压测计划自动化图13 压测计划自动化
我们定期进行的外卖全链路压测，需要召集相关业务方进行准备和跟进，这其中涉及的数据构造部分会关联到很多业务方的改造、验证、准备工作。如图13所示，我们需要通过压测计划串联整个准备、验证过程，尽量少的有人为活动参与到整个过程中。这其中我们需要进行如下工作的准备：
针对真实流量的改造，基础数据构造、数据脱敏、数据校验等尽可能通过任务提前进行。
进入到流量回放阶段，我们可以针对典型的故障场景进行故障预案的触发（比如：Tair故障等）。
在故障演练的同时，我们可以结合核心链路的关系数据准确定位出与故障场景强相关的问题节点。
结合我们针对典型故障场景事先建立的服务保护关系，自动触发对应的服务保护预案。
在整个流程中，我们需要最终确认各个环境的运行效果是否达到了我们的预期，就需要每个环节都有相应的监控日志输出，最终自动化产出最终的压测报告。
整个压测计划的自动化进程中，将逐渐减少系统运行中人为参与的部分，逐步提升全链路压测效率。我们希望，用户点击一个开关开始压测计划 ，然后等待压测结果就可以了。
图14 自动化建设后期发力点
在整个业务运维系统建设中，只有更加准确定位问题根节点，诊断出问题根本原因才能逐步自动化去做一些运维动作（比如：触发降级开关，扩容集群等）。如图14所示，我们会在这些环节的精细化建设上进行持续投入，希望检测到任意维度的异常点，向上推测出可能会影响哪些业务指标，影响哪些用户体验；向下依托qldwdm链路压测可以非常准确的进行容量规划，节省资源。
ssdwl，2016年加入美团，主要负责外卖业务架构相关工作，现正在围绕业务建设监控运维体系。
**美团外卖C端业务架构组：基于业务、服务、数据，进行深度整合、统一架构、规范，为外卖提供统一基础服务，收集各业务线监控数据，进行实时分析统计。我们正在努力将开发人员从日常运维工作中彻底解放出来，打造高效的业务运维平台。我们非常欢迎有业务运维经验，熟悉异常检测算法，对业务监控运维产品有深刻理解的同仁加入我们，共同提升美团外卖服务稳定性。
文章来源：https://tech.meituan.com/2017/11/14/digger-share.html