【.com原稿】饿了么平台不仅做外卖，蜂鸟、早餐、未来餐厅等众多平台也在快速扩张阶段。整个外卖产品链很长，从用户下单到最终送达的时间在30分钟左右，对时效性的要求非常强。从技术角度来看，饿了么遇到的最大挑战是意外。本文将以事故为中心，分为技术操作经验和心得体会两部分。第一部分体验分为细化分工、稳定（能力和变化）和效率提升三个阶段。第二部分经验是笔者对运维服务的理解。1.技术运维经验技术运维的职责是尽最大努力与更多的人合作以达到保稳定的目的，分为运维保障和运维服务两个阶段。现在，饿了么正处于运维服务阶段。技术运营团队作为乙方维护开发的产品，开发测试服务，保证稳定性，优化性能，提高资源利用率。在业务快速扩张阶段，技术团队需要做什么？首先，第一阶段是精细化分工。通过精细化分工促进平行提速，让专业的人用专业的知识和最有效的工作方法提高工作效率和代码吞吐量，建立沟通渠道加速决策，保持信息的稳定流动。细化分工分为三部分：第一部分做数据库拆分和代码解耦。技术工作集中在数据库的拆分上，先是垂直拆分，不得已才进行水平拆分。为了更快的服务于业务扩展，混入了一些代码解耦的工作。所谓代码解耦，就是把原来的代码系统想象成一个泥球，逐渐拆分成很多块。现在有十多个业务模块，每个模块都有专门的团队维护，内部领域划分。饿了么正在并行进行数据库和代码拆分。然后开始强制接入新的发布系统和单例单用，也就是物理拆分。在整个代码解耦和精细化分工的过程中，他们遇到了很多问题，其中典型的事故有两类：事故一：超时，后端服务慢，引发连锁反应，导致前端雪崩端服务。用户的请求时间取决于RPC调用路径上服务的响应时间。当其中一个节点变慢导致整个集群不可用时，一般的应急措施是按调用链从前到后的顺序停止服务，再从后到前启动服务。出现这种问题时，如果没有熔断机制，前端服务会因为依赖导致雪崩，服务无法自行恢复。加入熔断机制后，当后端问题节点重启或网络抖动恢复时，前端服务也会自行恢复。事件二：连续三天，商家要不断重试接单，跟Redis治理有关。当交换机的一个bug导致网络抖动时，Redis受到的影响最大。网络抖动期间，请求的积压会建立过多的Redis连接。连接过多会导致Redis响应延迟从1ms飙升到300ms。由于Redis请求慢，导致服务处理速度变慢，而外部请求依然积压，最终造成雪崩。故障刚出现的时候，由于Zabbix的监控周期长，运维工程师监控不到。后来，他们又用了三天的时间进行了压力测试和复现，才排查出故障点。随后，运维工程师创建了一个新的基础设施监控工具。实现方法是每隔10秒收集一次/proc目录下的所有指标，3分钟内基本可以定位问题。另外丢包重传也会严重影响Redis的性能，因为一个HTTP引擎可能会向后端产生几十个甚至上百个Redis请求，其中一个会命中重试，影响很大在服务上。致命。精细分工的第二部分是组建横向团队。比如大数据是横向团队，业务线是纵向团队。划分之后，整个业务的发展趋势图上升曲线非常陡峭，可以推断技术对业务没有阻碍。快速发展，即技术的吞吐量和新产品开发的效率是健康的。期间运维工程师也做了几件事情，比如把监控分为四个部分：Metric、Log、Trace、Infrastructure。组建Noc团队负责应急响应。当发现问题时，会及时将信息通过Oncall通知所有会员。还有整理各种清洗，接入发布，SOA，降级熔断开发等，通用清洗是什么概念？即工程师在对历史事故进行分析后，粗略地做一个技术总结，将一些常犯的错误列成一些可行的程序，向部门骨干进行宣传。具体内容包括：SOA服务治理，这里主要强调领域划分，高内聚低耦合。对公共组件的治理。这里的数据库Redis由两个专业团队组成，一个是DA，一个是DBA。DA治理的主要计划是收集各个行业合作伙伴的信息，规划容量，管理开发的使用态势，并将经验固化到研发过程中。业务指标的梳理包括TPS的概念设置（状态轮换，然后根据返回的状态进行管理），状态的停滞时间，状态的积累深度。这个积累深度主要是一些后端服务的状态轮换。超时链的合理设置和重试机制。外部依赖项和开关。为什么要强调外部依赖？外部依赖可以分为两类，一类是和其他公司的合作，比如调用其他公司的支付接口。另一种依赖是团队之间的依赖。请不要相信这里任何人的服务，bug随时都会发生。关键路径。为什么要设置关键路径？一个是熔断，一个是降级。当非关键路径出现问题时，直接drop掉即可，不影响关键路径。还有一个好处就是下次补偿的时候，可以有针对性的进行。日志。战队日志中也有很多意外，可以通过案例一一宣讲。制定的盲目锻炼目标正在实现。因为八九百个技术工程师之间的代码交互是一个复杂的系统，业务是一个很长的业务链条。关键路径涉及100多个服务。简单的功能测试是可以的，但是当容量很大的时候，就很难定位他们之间存在的问题，比如A团队和B团队之间的代码耦合验收。这时候想到的解决办法就是盲练。盲操不仅可以做业务端的验收，还可以做基础设施，包括Redis集群、MySQL集群、网络等。我曾经做过一个测试，按照1%的丢包率计算Redis实例上的包量，导致整个站点的业务跌到谷底。当时有12个Redis集群和数百个实例。其中一个实例出了问题，造成了这么大的影响。通过盲演，该技术正在寻求一种将单个节点宕机的影响降到最低的解决方案。第二阶段是稳定期。第一个敌人是能力问题。在业务快速扩张阶段，影响系统稳定性的最大敌人是容量，这类似于温水煮青蛙或突发的雪崩。由于不同的语言对容量的确定方式不同，饿了么由1000多个服务组成的复杂系统、业务场景的快速变化、频繁的服务变更等因素导致容量问题困扰了它近一年。最终采用定期线上全链路压测的方式，发起了一场100人的战役。历时一个多月，整改隐患近200处，基本解决产能问题。即使在低谷期，也采用全链路抑制。也可以在上线前和技术的压力测试一起做，然后再进行数据的统筹和分析。秒杀事故发生在5.17秒杀活动准备阶段。技术运营思路是利用日常服务集群对抗秒杀。活动开始前，整个容量增加了一倍多。但当天订单量暴涨，闪购开始后的几秒内，瞬时并发量达到平时的50倍。当流量洪峰来临时，洪峰直接将前端Nginx网络拥堵。反思一下，问题的原因是秒杀场景经验少，活动带来的洪峰数据预估太低，URL限流没有优先考虑等等。改进措施是专门针对秒杀搭建系统，主要是分级保护，建立客户端缓存、泳道、云集群和竞技缓存等。第三阶段是提高效率。通过工具、资源和架构转型提高效率。事故一：蜂鸟快递连续两周发生各种事故。原因是消息连续批量重试导致RMQ堆积，UDP句柄耗尽，fuse判断姿势不正确。可见，在新业务快速交付的过程中，代码质量和外部组件的使用姿势是事故的高危隐患点。事件2：MySQLSQL慢查询，从每周2到3次，近期已经减少到很少了。解决方案是使用组件治理。组件治理首先是服务于自身的资源和能力。二是限流降级。三是主要是一些限制发展的姿势。这三点完成后，技术会做一些自动化相关的工作，主要是信息化、标准化和编排。另一种是前置指标KPI，即一些组件在初次使用时，要进行一些量化的考虑。这几项做好后，技术基本可以避免重大故障问题。对于使用手势的治理，稳定性的收益是最大的。这里有几个重点：必须有一个精通组件的小伙伴，阅读源码，了解社区中遇到的所有坑，深入业务开发一线，了解业务场景，初步确定业务场景中组件的使用。工程师进行知识传递，通过各种渠道将标准化、开发规范、集群化、开发使用姿势等知识点传递到位。尽快将经验或红线固化为资源申请、架构评审等流程和工具。意外三：你饿了吗RMQ？RMQ有很多使用场景，包括Python和Java。2016年初，虽然工程师做了技术和配置review，但还是有很多场景没有想到。涉及的主要问题如下：一是设备升级。当设备网络割接完成后，虽然RMQ集群中的配置可以自愈，但是还有很多集群没有实现自愈。因此，该技术专门预留了一个冷备RMQ集群，将现网的所有配置部署到该冷备集群中。在线的20多个RMQ集群中，如果有一个宕机，可以及时切换。队列被阻塞。主要是追溯消费能力，因为业务飙升，消费能力不够，很容易导致排队拥堵。要使用的场景。比如在发送和接收消息时，如果每发送一次消息，每接收一次消息，就重建链接或者重建Queue。这种重构会导致RMQ内部有一个Event机制。当请求增加到一定程度，会直接影响RMQ的吞吐量，RMQ的容量会下降到原来的十分之一。难点大：故障定位和恢复效率故障定位慢的主要原因是饿了么整个系统的信息量太大。当问题出现时，负责故障定位的工程师会得到很多信息，比如3条信息，他很难判断故障是什么以及如何检测。目前的做法是进行零星的、地毯式的扫荡来排除故障。什么是扫地毯？就是先获取足够的信息，进行分工，要求每个参与的工程师都去检查。内容涉及到外卖、商家、支付和物流，还有基础的业务和网络监控，外网的一些流量，服务器的一些负担等等，这时候，技术工程师有序的自证就变成了很重要。现在能做的就是大家可以看到自己目前负责的服务是否有问题。需要做的就是提供工具，比如交换机的丢包，服务器的丢包。通过一些工具，技术工程师可以及时发现问题，但这个过程需要时间。二是自证时，一定要认真核对。作为团队的一员，每个技术工程师都负责相应的版块，但一旦因为个人疏忽或自查不力出现一些错误，就得自己“甩锅”了。故障定位后，提高恢复效率，解决问题是关键。此外，应急演练也很重要。应急演练直接关系到系统恢复的效率。当集群出现故障时，技术能否快速恢复。2.运营经验这次的分享大部分都是围绕意外发生的。每一次事故都不是偶然的，很多问题都可以通过正确的使用姿势、提前预估容量、灰度来避免。如果技术只是个案解决这个问题，事故往往会在另一个时间点发生。这就需要工程师做事要有思维，比如做事故审查、事故报告审查、验收组等。然后，通过在每个阶段多次提出事故涉及的重点，不断总结和制定切实可行的操作规范。问题的解决往往需要思维方式的转变，需要伙伴多思考如何从重要且紧急的日常事务中抽出时间。并且敢于折腾。折腾是什么概念？就是不断钻研，不断捣乱。工程师必须非常熟悉维护系统，这样他们在定位和解决故障时才会非常准确。最后一个就是灯下黑的问题，尤其是基础设施。这在当时是很头疼的。检查基础设施上的问题需要十多分钟到一个小时。后来有个小伙伴改变了主意，做了一个系统，帮助团队很好的解决了这个大问题。所以敢于思考，勤于尝试，是饿了么技术团队非常重要的经验。作者：徐安编辑：孙淑娟完善运维信息化、标准化、服务化建设，逐步实现运维自动化交付、数据可视化，进而实现低成本保障系统稳定；通过数据和规则适配，以及产品设计、人工审计、风险管控平台的建设，让每一元补贴都用在企业既定目标的实现上。【原创稿件，合作网站转载请注明原作者和出处为.com】
