从美团程序员的灾难来看，在美团外卖自动化运维系统建设中，页面内容同样无法正常显示。美团服务器大面积宕机。这是一个上了热搜，让大家吃不上午饭的bug。吃饭的时候遇到这样的事情，真的很郁闷啊！而且，这种情况并非孤例。微博一搜，关于美团外卖情况的报道不少。还有人看到付款不成功，连续几次尝试付款，钱都出去了，但既没有下单也没有退款。想咨询美团外卖的客服，但是一直联系不上，无论是在线客服还是电话客服。不过，12时16分，美团微博回复：订单问题已解决，订单问题已解决，订单问题已解决。12点28分，APP依旧宕机。中午12时43分，美团微博回应：紧急修复后，陆续恢复。重复支付的订单将按原路线退回。系统故障期间未完成服务的订单，用户可自行取消退款，无需承担责任。随后，部分重复下单的网友已经收到了美团的退款和道歉红包。对于美团的工程师们来说，这次事故简直就是一年一度的灾难，可能会直接让美团的程序员们错失丰厚的年终奖机会。其实，这并不是美团第一次遇到类似问题。据了解，就在前天，也就是12月5日，美团外卖也出现了服务器崩溃的情况。当用户中午点完单想查看订单进度时，页面要么显示“系统处理异常”，要么显示“订单不存在”，导致用户无法追踪其送餐进度。美团后台宕机了。对此，不少网友吐槽美团的程序员到底是饿着肚子吃饭，无视系统bug，还是祭祀上天？是寒假吗？难道下一步要祭天？继暴风视频、虾米音乐之后，又一个程序员将??被祭祀上天。也有网友表示，饿了么放在美团身边的程序员终于发力了。还被隔壁的微博技术调侃，一有大事就崩溃：对此，不少网友调侃：网友都是阴谋论者：系统宕机可能是意外，也可能是突发事件如之前鹿晗的微博公布恋情时系统崩溃，但持续宕机可能是技术故障。下面小编就为大家带来一些干货，一起来看看日订单量超1600万的美团外卖自动化业务的运维之路。美团的外卖业务在互联网行业非常独特。不仅流程复杂——从用户下单、商户接单到配送员接单配送，而且中午和晚高峰时段压力和流量都非常集中。与此同时，外卖业务的增长非常迅速。自2013年11月上线至今不到4年，最新峰值突破1600万。在这种情况下，一旦发生事故，单纯依靠人工排查解决问题存在诸多局限性。本文将详细分析美团外卖运维过程中的问题发现、根因分析、问题解决等自动化运维系统的构建过程和相关设计原则。外卖业务的特点首先我们从业务本身的一些特点来说说业务自动化运维的必要性。复杂业务流程图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所示，业务仪表板不仅需要展示业务监控指标，还需要有很强的对外扩展能力，例如：当业务指标出现异常时，根据后台监控数据分析，可手动或自动标记Event，告知开发者业务指标波动的原因，实现用户信息的快速同步。可以通过时间戳和类型快速引导开发者进入其他监控系统，提高开发者排查问题的效率。我们定期对生产系统进行全链路压测，隔离压测流量监控，使压测数据不污染真实业务数据。在外卖业务场景中，我们的业务监控数据大多表现出很强的周期性。对于业务数据，我们可以利用历史数据，使用Holt-Winters等模型来预测业务数据。当我们的实际值和预测值不在置信区间内时，系统会直接发出警报。因为是更面向业务的运维系统，所以我们对敏感的业务指标进行了相应的权限管理。为了增加系统的使用场景，我们需要支持移动端，让用户随时随地通过手机查看自己关心的监控面板，触发服务保障计划。核心链接核心链接也是系统的主要入口。用户可以通过核心链路快速定位是哪条调用链出现了问题，如图8所示：图8：核心链路产品构建路径包括两个步骤：我们需要对核心链路上的服务节点进行健康评分，以及根据评分模型定义问题严重的环节。这里我们将根据业务的各项指标来描述一个业务的问题画像。问题画像中的指标也会被加权。观点。当我们确认某条链路出现问题时，链路上的更远节点可能就是引起问题的根节点，我们会实时获取该节点更多的相关监控指标进行分析诊断。这里会整合开发者日常排查的SOP，最终可能会定位到本服务节点部分服务器的磁盘或CPU的问题。我们最终会发布问题诊断结果。结果发布后，我们需要收集用户反馈来判断诊断结果是否准确，为我们后续优化评分定位模型和诊断模型提供强有力的数据支持。在核心链接建设初期，我们会建议开发者触发相应的服务保障计划。当我们的诊断结果足够准确时，我们可以针对固定的问题场景自动触发服务保护计划，以缩短解决问题的时间。业务保护与故障演练图9：业务保护与故障演练模块核心功能业务保护与故障演练模块是我们业务运维体系的重要组成部分，形成闭环。本模块需要具备的核心功能如图9所示，针对不同的保护需求，我们有不同类型的业务保护开关，主要有：在代码中切换。当业务异常时，需要手动进行降级操作。限流开关：一些特定的业务场景需要相应的限流保护措施。比如单机限流主要是为了保护自己服务器的资源，集群限流主要是为了底层DB或者Cache等存储资源的资源保护。还有一些其他的限流要求，希望能在系统中防止流量异常的有效保护。Hystrix自动断路器：通过监控异常数、线程数等简单指标，我们可以快速保护我们服务的健康状态不至于急剧恶化。根据我们的运维经验，多个开关的切换可能会涉及到生产事故的发生。这里，需要针对不同的故障场景，预先设定业务保护方案。当出现问题时，可以通过一键式操作保护多个服务。开关改变预设状态。既然我们有了针对不同故障场景的服务保障计划，我们就需要时时验证这些服务保障计划是否真的能达到预期的效果。与生产相关的事故是很少见的，当然不可能在生产中出现真正的问题后才去验证方案，需要模拟不同的故障。当我们的生产服务出现问题时，不管是网络原因还是硬件故障，服务的可能原因大多是服务超时或者变慢或者抛出异常。前期我们主要围绕这几点进行，以便对核心链路上的任意一个业务节点进行故障演练。生产故障可能会导致多个节点同时发生故障。在这里，我们需要我们的故障演练来支持应急管理。服务保障是业务运维的终端措施。我们需要让用户在软件中直接访问相应的服务保护。这里需要把服务保障和业务市场、核心环节结合起来，方便开发者发现问题。输入相应的服务保护计划。通过这些保护措施和故障演练功能，结合与核心链路的关系，可以结合故障诊断和全链路压力测试进行自动化建设。整合全链路压测我们现在定期组织外卖全链路压测。每一次压力测试都需要很多人的配合。如果能够针对单一的压测场景进行压测，将大大降低我们组织压测的成本。图10：改进全链路压测给我们带来的收益如图10所示，现在我们主要针对全链路压测时的压测流量进行不同场景的故障演练。在创建故障时，验证服务保护配置文件是否可以按预期启动保护服务的目的。后面会讲到我们对于全链路压测自动化建设的思路。自动化之旅主要介绍了我们在做基于业务的运维系统时需要的核心功能。下面将重点介绍我们在整个系统建设中主要关注自动化建设的地方。异常点自动检测我们在做核心链路建设的时候，需要采集各个服务节点的告警事件。这些告警事件包括服务调用时端到端的监控指标，以及服务自身SLA的监控指标。在与开发者交流时了解到，他们在配置这些监控指标时通常会花费大量的人力，而且需要反复调整每个指标的告警阈值才能达到理想状态。基于这些监控痛点，我们希望通过分析历史数据，自动检测异常点，自动计算并设置合适的告警阈值。图11：异常点自动检测如图11所示，我们根据不同监测指标的特点选择不同的基线算法，并计算它们的置信区间，帮助我们更准确地检测异常点。比如我们的业务是比较周期性的，大部分的监控指标都是在历史同期呈正态分布。这时，我们可以将真实值与平均值进行比较。如果差异在N倍标准差之外，则认为真实值是异常值。自动触发服务保护我们的服务保护措施一部分是通过Hystrix自动熔断，另一部分是我们现有的上千个降级和限流开关。这些开关通常需要开发者根据自己的运维经验手动触发。.图12：异常检测与服务保护联动如图12所示，如果我们能够根据各种监控指标准确诊断异常点，并提前将识别出的异常场景与我们的服务保护计划关联起来，就可以自动触发服务保护计划。压测方案将我们常规的外卖全链路压测自动化，需要相关业务方做好准备跟进。其中涉及到的数据建设，会涉及到很多业务方的改造、验证、准备工作。图13：压力测试计划的自动化如图13所示，我们需要通过压力测试计划将整个准备和验证过程串联起来，整个过程中尽可能少的人为活动。我们需要准备以下工作：对于真实流量的改造，尽可能提前通过任务进行基础数据构建、数据脱敏、数据校验等。进入流量回放阶段，我们可以针对典型故障场景（例如Tair故障等）触发故障预案。在进行故障演练的同时，结合核心链路的关系数据，可以准确定位与故障场景强相关的问题节点。结合我们针对典型故障场景预先建立的服务保护关系，自动触发相应的服务保护计划。在整个过程中，我们需要最终确认每个环境的运行效果是否达到了我们的预期。我们需要对每个环节都有相应的监控日志输出，最后自动生成最终的压力测试报告。在整个压测方案的自动化过程中，将逐步减少系统运行中的人为参与，逐步提升全链路压测的效率。我们希望用户点击一个开关，开始压测计划，然后等待压测结果。结语在整个业务运维体系的建设中，只有更加准确地定位问题的根节点，诊断问题的根源，才能逐步实现一些运维动作的自动化（比如触发降级开关，扩容等）集群等）。图14：自动化建设后期如图14所示，我们会??继续投入细化这些环节，希望能检测到任何维度的异常点，向上推测哪些业务指标可能会受到影响，哪些会受到影响做作的。用户体验;依靠全链路压测，可以非常准确的进行容量规划，节省资源。作者：刘宏伟简介：2016年加入美团点评，主要负责外卖业务架构相关工作。现在他正在围绕业务搭建监控运维系统。
