饿了么技术运营是如何摆平那些恼人事故的

《饿了么技术运营是如何摆平那些恼人事故的》要点：
本文介绍了饿了么技术运营是如何摆平那些恼人事故的，希望对您有用。如果有疑问，可以联系我们。

饿了么技术运营部、风控管理部高级总监

作者：徐盎

编辑：孙淑娟

徐盎,擅长精益运维、精细化风控,通过与公司其他团队协作、推动并完善运维信息化、标准化、服务化的建设,逐步实现自动化运维及交付,数据可视化,进而做到低成本的保障系统稳定；通过数据与规则适配,以及产品设计、人工审计、风控平台建设使每一元补贴用在公司既定目标的实现上.

饿了么平台不仅做外卖,还有蜂鸟、早餐和未来餐厅,以及很多其他的一些平台,正处在快速扩张阶段.整个外卖的产品链条长,从用户下单到最后配送到达,时间大概是30分钟左右,对时效性的要求非常强.

从技术的角度来看,饿了么遇到的最大挑战是事故.本文将围绕事故展开,分成两部分内容：技术运营经历与心得.第一部分经历又分为三个阶段：精细化分工、保稳定(容量和变更)和增效.第二部分心得,是作者对运维服务的理解.

一、技术运营经历

技术运营的职责是尽最大的努力协同更多的人来达成保稳定的目标,可以划分为两个阶段：运维保障、运维服务.现在,饿了么处在运维服务的阶段,技术运营团队作为乙方,把开发出来的产品,开发测试后的服务,做维护,保障稳定、调优性能、提高资源的利用率.

在业务快速扩张阶段,技术团队需要做哪些事情呢?

首先,第一阶段,精细化分工.

通过精细化分工促进并行提速,让专业的人利用专业的知识、最有效的工作方式提高工作效率及代码吞吐量,建立沟通渠道加速决策、信息流通保稳定.

精细化分工分为三部分内容：

第一部分是做数据库拆分和代码解耦.技术工作集中在数据库的拆分,先纵向拆分,不得已才做横向拆分,为了更快地服务业务的扩张,又夹杂了一些对代码解耦的工作.

所谓代码解耦,是把原来的代码系统想象成一个泥球,把它逐渐拆分成很多块.现在是有十多个业务模块,每一模块里面都有专门的团队来维护,内部又会划分域.

饿了么是数据库、代码拆分并行在做.然后,启动了强制接入新发布系统和单实例、单运用,也就是物理拆分.

在整个的代码解耦和精细化分工的过程当中,他们碰到了很多问题,其中比较典型的两类事故是：

• 事故1：超时,后端服务慢,引发连锁反应,导致前端服务雪崩.用户的请求耗时依赖于 RPC 调用路径上服务的响应时间.当其中某个节点变慢,整个集群都不可用,一般救急措施是要按照调用链从前往后按顺序停服务,然后在从后往前启动服务.

  当这类问题发生的时候,如果没有熔断机制,前端的服务因依赖关系造成雪崩,而且服务不能自己恢复.加了熔断机制之后,当后端问题节点重启或是网络抖动恢复后,前端服务也会自己恢复.

• 事故2：连续三天商户需要不断重试才能接单,这与Redis治理有关.当交换机发生 Bug 导致网络抖动,受影响最大的就是 Redis,在网络抖动期间积压的请求会建立太多 Redis 连接,连接过多会导致 Redis 响应延迟从 1ms 飙升到 300ms.由于 Redis 请求慢导致服务的处理速度被拖慢,而外部请求仍在积压,最后引起雪崩.

  刚开始出现故障的时候,因 Zabbix 的监控周期长,运维工程师监控不到.后来,他们用了三天的时间进行压测复现,才排查出来故障点.事后,运维工程师打造了一种新的基础设施监控工具,实现方式是每 10 秒钟把 /proc 目录下的所有指标收集起来,基本能做到 3 分钟内定位问题.

  还有丢包的重传也会严重影响 Redis 的性能,因为一个 HTTP 引擎到后端有可能产生几十个甚至上百次的 Redis 请求,其中有一次被命中重试,对服务的影响都是致命的.

精细化分工的第二部分是组建水平团队,例如大数据是水平团队,业务线是竖向团队,划分之后,从整个业务的发展走势图上升曲线非常陡,可以推断技术并没有防碍业务的快速发展,也就是技术的吞吐量、新产品研发效率是健康的.

期间,运维工程师还做了几件事,比如把监控分为 Metric、Log、Trace、基础设施四个部分.组建 Noc 团队,负责应急响应,当发现有问题的时候,及时把信息通过 Oncall 通报给各成员.还有梳理各类扫除,接入发布、 SOA,降级熔断开发等.

大扫除

大扫除的概念是什么呢?就是工程师对历史的事故进行分析之后,大概做出技术总结,把经常犯的一些错误,列成一些可做的规程,给所在部门的骨干进行宣传.具体内容包括：

• SOA 的服务治理,这里主要强调的是领域划分,高内聚低耦合.
• 对公共组件的治理.这里的数据库 Redis 由两个专业的团队组成,一个是 DA,一个是 DBA.DA 治理的主要方案是收集各个产业伙伴的信息,规划容量,治理开发的使用姿势,把经验固化到研发流程里.
• 业务指标的梳理,包括对 TPS 的概念设定(状态轮转后再根据返回状态打点)、状态的停滞时间和状态的堆积深度,这个堆积深度主要是后端一些服务的状态轮转.
• 对超时链的合理设定和重试机制.
• 外部依赖及开关.为什么强调外部依赖呢?外部依赖可以分为两类,一类是跟其他公司的合作,例如调用其他公司的支付接口.还有一类依赖是团队之间的依赖,这里请不要相信任何人的服务,Bug 随时都会发生.
• 关键路径.为什么要设置关键路径呢?一个是熔断,一个是降级.当非关键路径出现问题的时候,直接把它降掉就行了,不要影响关键路径.另外一个好处是接下来做补偿的时候,可以有针对性去做.
• 日志.团队在日志上发生的事故也很多,可以逐个通过案例进行宣讲.
• 正在实现中的制定盲演习目标.因为八九百个技术工程师之间的代码交互本身是一个复杂系统,业务又是一个非常长的业务链,关键路径涉及的服务超过 100个,简单的功能测试是可以的,但是容量大的时候,将很难定位他们之间存在的问题,比如 A 团队和 B 团队之间的代码耦合验收.这时想到的解决方案就是盲演习.盲演习除了在业务方可以做验收之外,还可以做基础设施,包括 Redis 集群、 MySQL 集群和网络.曾经做过一个测试,把一个 Redis 实例上的包量,按照百分之一的丢包率计算,导致整个全站的业务都掉底.当时整个 Redis 集群有12台,有几百个实例,其中一个实例有问题,就造成这么大的影响.通过盲演习,技术正在寻求单个节点宕机影响最小化的解决方案.

第二阶段,保稳定期.头号敌人是容量问题.

（编辑：上饶站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!