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

在业务快速扩张阶段,影响系统稳定性最大的敌人是容量,类似温水煮青蛙,或突然雪崩.因为不同语言判定容量的方式不同,饿了么1000多个服务组成的复杂系统,业务场景快速变换,服务变更频繁等等因素,导致容量问题困扰了近一年的时间.

最后采用的是定期线上全链路压测的方法,发动了一次百人战役,历时一个多月,整改了近 200 个隐患点,基本解决了容量问题.即便在低谷期的时候,也采用全联路压制.还可以配合技术在上线前的压测一起来做,然后把这些数据统筹起来进行分析.

秒杀事故

在 517 秒杀大促准备阶段,技术的运营思路是想用日常服务的集群来对抗秒杀,活动前把整个的容量提高了两倍多.但是当日订单量飙涨,秒杀开始后的那几秒钟,瞬时并发请求达到平常的 50 倍.当流量洪峰到来的时候,洪峰直接把前端 Nginx 的网络拥塞了.

反思下来,出现问题的原因是秒杀场景的经验少,对活动带来洪峰数据的预估过低,URL 的限流未区分优先级等等.改进措施是专门针对秒杀搭建了一套系统,主要做了分级保护、建立用户端缓存、泳道、云集群和竞争缓存等.

第三阶段,增效.通过工具、资源、架构改造,提高效率.

事故1：连续两周蜂鸟配送出现各类事故

原因是消息不断的批量重试导致 RMQ 堆积,UDP 句柄耗尽,熔断判定使用姿势不对.可以看出,新业务在快速交付过程中,代码质量、外部组建的使用姿势是事故高危隐患点.

事故2：MySQL

SQL 慢查询,从每周的 2 到 3 起,降低到近期很少出现.解决办法是使用组件治理.组件治理首先是服务化自己的资源、容量.第二个是设限流,做降级.第三个主要是限制开发的一些姿势.

这三点做完之后,接下来技术做了自动化相关的一些工作,主要是信息、标准化和编排.再一个是前置指标KPI,就是当一些组件刚使用起来时,要做一些量化的考虑.把这几条做到以后,技术基本上能避免出现大的故障问题.

对于使用姿势的治理,对稳定的收益最大.这里特别介绍几个关键点：

• 必须要有对组件精通的伙伴,看过源码,了解社区里碰到的所有的坑,还要深入业务开发一线,了解业务场景,初步判定组件在业务中的使用场景.
• 工程师进行知识传递,通过各种渠道把标准化、开发规范、集群化、开发使用姿势等知识点传递到位.
• 尽快把经验或红线固化到资源申请、架构评审等流程、工具里.

事故3：RMQ

在饿了么,RMQ 的使用场景非常多,有 Python,也有 Java.2016年年初的时候,工程师虽然做了一个技术、配置的梳理,还是留有很多的场景是没有想到的,主要涉及的问题有如下几个：

• 分区,就是技术在做割接的时候,核心交换是升级换设备.当设备网络割接完了,虽然在 RMQ 集群里面的配置是可以自恢复的,但是仍然还有很多集群没有做到自恢复.所以,技术特意预留了一个冷备 RMQ 集群,把现网所有的配置都部署到那一个冷备集群里面去.线上 20 多个 RMQ 集群中,如有一个宕掉的时候,可以及时切过来.
• 队列堵塞.主要是追查消费能力,因为业务飙升,消费能力不够,极容易导致队列堵塞.
• 使用场景.举例来说,在发送、接收消息的时候,如果每发一个消息,每收一个消息,都重建一次链接或者都重建 Queue.这种重建会导致 RMQ 内部的一个Event机制.当请求增长到一定程度的时候,就会直接影响 RMQ 的吞吐量,RMQ 的容量会掉到是原来的十分之一.

老大难：故障定位、恢复效率

故障定位慢的最主要原因是饿了么整个系统的信息量太大,当一个问题出现的时候,主导这个事故定位的工程师拿到的信息非常多,比如拿到三个信息,他很难决定到底是什么故障,需要如何检测出来.

当前的做法是进行碎片化、地毯式的大扫荡来排障.什么是地毯式的大扫荡呢?就是把足够多的信息先拿到,进行分工,要求涉及的每个工程师都来查看.内容涉及到外卖、商户、支付和物流,然后还有基础业务和网络监控,外网的一些流量,还有服务器的一些负担等等.

这时,技术工程师的有序自证就变得非常重要,当前能做到的是每一个人能看到当前负责的服务是不是有问题.还需要做的就是提供工具,比如交换机的丢包、服务器的丢包.通过一些工具,让技术工程师及时发现问题,但是这个过程是需要时间的.

另外一个是在自证的时候,一定要仔细地检查.作为团队中的一个成员,每一个技术工程师负责相应的板块,但一旦因为个人疏忽或是自检不足造成一些失误,要自己“刷锅”.故障定位后,提升恢复效率解决问题才是关键.

还有,应急演习很重要.应急演习直接关系到系统恢复的效率,当一个集群出问题的时候,技术能不能快速的恢复.

（编辑：ASP站长网）