饿了么是如何做技术运营的 / 木子杰软件教程

饿了么平台不仅做外卖，还有蜂鸟、早餐和未来餐厅，以及很多其他的一些平台，正处在快速扩张阶段。整个外卖的产品链条长，从用户下单到最后配送到达，时间大概是30分钟左右，对时效性的要求非常强。
从技术的角度来看，饿了么遇到的最大挑战是事故。本文将围绕事故展开，分成两部分内容：技术运营经历与心得。第一部分经历又分为三个阶段：精细化分工、保稳定（容量和变更）和增效。第二部分心得，是作者对运维服务的理解。

技术运营经历

01

通过精细化分工促进并行提速，让专业的人利用专业的知识、最有效的工作方式提高工作效率及代码吞吐量，建立沟通渠道加速决策、信息流通保稳定。精细化分工分为三部分内容：第一部分是做数据库拆分和代码解耦。技术工作集中在数据库的拆分，先纵向拆分，不得已才做横向拆分，为了更快地服务业务的扩张，又夹杂了一些对代码解耦的工作。所谓代码解耦，是把原来的代码系统想象成一个泥球，把它逐渐拆分成很多块。现在是有十多个业务模块，每一模块里面都有专门的团队来维护，内部又会划分域。饿了么是数据库、代码拆分并行在做。然后，启动了强制接入新发布系统和单实例、单运用，也就是物理拆分。精细化分工的第二部分是组建水平团队，例如大数据是水平团队，业务线是竖向团队，划分之后，从整个业务的发展走势图上升曲线非常陡，可以推断技术并没有防碍业务的快速发展，也就是技术的吞吐量、新产品研发效率是健康的。期间，运维工程师还做了几件事，比如把监控分为 Metric、Log、Trace、基础设施四个部分。组建 Noc 团队，负责应急响应，当发现有问题的时候，及时把信息通过 Oncall 通报给各成员。还有梳理各类扫除，接入发布、 SOA，降级熔断开发等。
02

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

第二阶段，保稳定期。头号敌人是容量问题。在业务快速扩张阶段，影响系统稳定性最大的敌人是容量，类似温水煮青蛙，或突然雪崩。因为不同语言判定容量的方式不同，饿了么1000多个服务组成的复杂系统，业务场景快速变换，服务变更频繁等等因素，导致容量问题困扰了近一年的时间。最后采用的是定期线上全链路压测的方法，发动了一次百人战役，历时一个多月，整改了近 200 个隐患点，基本解决了容量问题。即便在低谷期的时候，也采用全联路压制。还可以配合技术在上线前的压测一起来做，然后把这些数据统筹起来进行分析。秒杀事故在 517 秒杀大促准备阶段，技术的运营思路是想用日常服务的集群来对抗秒杀，活动前把整个的容量提高了两倍多。但是当日订单量飙涨，秒杀开始后的那几秒钟，瞬时并发请求达到平常的 50 倍。当流量洪峰到来的时候，洪峰直接把前端 Nginx 的网络拥塞了。反思下来，出现问题的原因是秒杀场景的经验少，对活动带来洪峰数据的预估过低，URL 的限流未区分优先级等等。改进措施是专门针对秒杀搭建了一套系统，主要做了分级保护、建立用户端缓存、泳道、云集群和竞争缓存等。第三阶段，增效。通过工具、资源、架构改造，提高效率。

运营心得

01

本次分享大部分围绕事故来讲。每一次事故的出现都不是偶然的，很多问题是可以通过正确的使用姿势、提前做容量预估、灰度等方法规避的。如果说技术只是就事论事把这一件事情解决的话，事故往往在另外一个时间点还会出现。这就要求工程师以思考的方式去做事，比如做事故复盘、事故报道审核，还有验收小组等。然后，通过在各个阶段，多次把一个事故涉及的关键点提出来，不断地进行总结并制定可行的操作规范。问题的解决往往需要思维模式的转变，需要伙伴们多想想怎么从日常重要紧急的事务里抽离出时间思考。还有要敢于折腾。折腾是什么概念呢？就是要不断的演习、捣乱，工程师对于维护的系统，自己要非常的熟悉，这样在定位和解决故障的时候，就会非常精准。最后一个是灯下黑的问题，特别是基础设施这块。这在当时让人很头疼，查一个问题在基础设施上花费的时间是十多分钟到一个小时。后来有一个小伙伴改变思路，做出了一套系统，帮助团队非常好地解决了这个大问题。所以敢于思考，勤于尝试是饿了么技术团队非常重要的一个心得。

饿了么APP

饿了么是如何做技术运营的

技术运营经历

运营心得

相关推荐