美团外卖：业务自动化运维之路日订单量超过1600万单和发货，中午和晚高峰压力和流量非常集中。与此同时，外卖业务的增长非常迅速。自2013年11月上线至今不到4年，最新峰值突破1600万。在这种情况下，一旦发生事故，单纯依靠人工排查解决问题存在诸多局限性。本文将对自动化运维系统的问题发现、根因分析、问题解决等构建过程及相关设计原则进行详细分析。外卖业务的特点首先我们从业务本身的一些特点来说说业务自动化运维的必要性。复杂业务流程图1用户视角下的美团外卖技术体系图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所示，涉及两个步骤：①我们需要对核心链路上的服务节点进行健康评分，根据评分模型定义存在严重问题的链路。这里我们会根据服务的各项指标，画出一个服务的问题画像。问题画像中的指标也会被加权。例如：当服务出现故障率告警、TP99告警时，会添加大量的异常日志，并加上高权重点。②当我们确认某条链路出现问题时，链路上的更远节点可能就是引起问题的根节点。我们会实时获取更多节点的相关监控指标，用于分析诊断。这里我们会整合开发人员日常排查问题的SOP，最终可能会定位到该服务节点部分服务器的磁盘或者CPU。图8核心环节产品构建路径我们最终会出一个问题诊断结果。结果发布后，我们需要收集用户反馈来判断诊断结果是否准确，为我们后续优化评分定位模型和诊断模型提供强有力的数据支持。.在核心链接建设初期，我们会建议开发者触发相应的服务保障计划。当我们的诊断结果足够准确时，我们可以针对固定的问题场景自动触发服务保护计划，以缩短解决问题的时间。业务保护与故障演练图9业务保护与故障演练模块核心功能业务保护与故障演练模块是我们业务运维体系的重要组成部分，形成闭环。本模块需要具备的核心功能如图9所示。针对不同的保护需求，我们有不同类型的业务保护开关。主要有以下几种：①降级开关：由于业务的快速发展，代码中会有数百个降级开关。当业务异常时，需要手动进行降级操作。②限流开关：一些特定的业务场景需要相应的限流保护措施。比如单机限流主要是为了保护自己服务器的资源，集群限流主要是为了底层DB或者Cache等存储资源的资源保护。还有一些其他的限流要求，希望系统能出现流量异常。有效的保护。③Hystrix自动断路器：通过监控异常数、线程数等简单指标，我们可以快速保护我们服务的健康状态不至于急剧恶化。根据我们的运维经验，多个开关的切换可能会涉及到生产事故的发生。这里，需要针对不同的故障场景，预先设定业务保护方案。当出现问题时，可以通过一键式操作保护多个服务。开关改变预设状态。既然我们有了针对不同故障场景的服务保障计划，我们就需要时时验证这些服务保障计划是否真的能达到预期的效果。与生产相关的事故是很少见的，当然不可能在生产中出现真正的问题后才去验证方案，需要模拟不同的故障。当我们的生产服务出现问题时，无论是网络原因还是硬件故障，在服务上的表现大多可能是服务超时或者变慢，或者抛出异常。前期我们主要围绕这几点进行，以便对核心链路上的任意一个业务节点进行故障演练。生产故障可能导致多个节点同时失效。这里需要我们的故障演练和支持计划管理。服务保障是业务运维的终端措施。我们需要让用户在软件中直接访问相应的服务保护。这里需要把服务保障和业务市场、核心环节结合起来，方便开发者发现问题。输入相应的服务保护计划。通过这些保护措施和故障演练功能，结合与核心链路的关系，可以结合故障诊断和全链路压力测试进行自动化建设。整合全链路压测我们现在定期组织外卖全链路压测。每一次压力测试都需要很多人的配合。如果能够针对单一的压测场景进行压测，将大大降低我们组织压测的成本。如图10所示，我们主要针对全链路压测中的压测流量进行不同场景下的故障演练，验证业务保护方案是否能够在创建故障的同时按预期启动保护服务。后面会讲到我们对于全链路压测自动化建设的思路。图10全链路压测的提升给我们带来的收益自动化之旅前面主要介绍了我们在做业务化运维系统时需要的核心功能。下面将着重介绍我们整个系统建设的自动化方面。建设主要集中在哪里。异常点自动检测图11异常点自动检测我们在做核心链路建设的时候，需要采集各个服务节点的告警事件。这些告警事件包括调用服务时端到端的监控指标，以及服务自身SLA的监控指标。在和开发者交流的过程中了解到，他们在配置这些监控指标的时候，通常会花费大量的人力。需要反复调整各指标的报警阈值，以达到理想状态。基于这些监控痛点，我们希望通过分析历史数据来自动检测异常点，并自动计算并设置合适的告警阈值。如图11所示，我们根据不同监控指标的特点选择不同的基线算法，并计算它们的置信区间，帮助我们更准确地检测异常点。比如我们的业务是比较周期性的，大部分的监控指标都是在历史同期呈正态分布。这时，可以将真实值与平均值进行比较。如果差异在N倍标准偏差之外，则认为实际值是异常值。服务保护的自动触发图12异常检测与服务保护的联动我们的服务保护措施一部分是通过Hystrix自动熔断，另一部分是我们已经有的上千个降级和限流开关。这些开关通常需要开发者根据自己的运维经验来手动触发。如果我们能够根据各种监控指标准确诊断出异常点，并提前将识别出的异常场景与我们的服务保护计划关联起来，就可以自动触发服务保护计划，如图12所示。自动化压测方案图13自动化压测测试计划我们定期对外卖进行全链路压力测试，需要召集相关业务方进行准备和跟进。涉及到的数据构建会涉及到转换、验证、Preparation。如图13所示，我们需要通过压力测试计划将整个准备和验证过程串联起来，尽可能少的人为参与整个过程。其中，我们需要准备以下工作：对于真实流量的改造，尽可能提前通过任务进行基础数据构建、数据脱敏、数据校验等。进入流量重放阶段，我们可以针对典型故障场景（例如Tair故障等）触发故障预案。在进行故障演练的同时，结合核心链路的关系数据，可以准确定位与故障场景强相关的问题节点。结合我们针对典型故障场景预先建立的服务保护关系，自动触发相应的服务保护计划。在整个过程中，我们需要最终确认每个环境的运行效果是否达到了我们的预期。我们需要对每个环节都有相应的监控日志输出，最后自动生成最终的压力测试报告。在整个压测方案的自动化过程中，将逐步减少系统运行中的人为参与，逐步提升全链路压测的效率。我们希望用户点击一个开关，开始压测计划，然后等待压测结果。结论图14.自动化建设的后期制作点在整个业务运维体系的建设中，只有更加准确的定位问题的根节点，诊断问题的根源，才能逐步将一些运维自动化维护动作（如触发降级开关、扩容集群等）。如图14所示，我们将继续投入这些环节的精细化建设，希望能检测到任何维度的异常点，向上推测哪些业务指标和用户体验可能受到影响；向下依赖全链条压测，可以非常准确的进行容量规划，节约资源。
