分享饿了么平台技术运营的实力，从几个角度来完成运营目标！

　　导语：分享饿了么平台技术运营的实力，从几个角度来完成运营目标！
　　饿了么平台不仅做外卖，还有蜂鸟、早餐和未来餐厅，以及很多其他的一些平台，正处在快速扩张阶段。整个外卖的产品链条长，从用户下单到最后配送到达，时间大概是30分钟左右，对时效性的要求非常强。
　　从技术的角度来看，饿了么遇到的最大挑战是事故。本文将围绕事故展开，分成两部分内容：技术运营经历与心得。第一部分经历又分为三个阶段：精细化分工、保稳定（容量和变更）和增效。第二部分心得，是作者对运维服务的理解。
　　饿了么平台技术运营经历
　　通过精细化分工促进并行提速，让专业的人利用专业的知识、最有效的工作方式提高工作效率及代码吞吐量，建立沟通渠道加速决策、信息流通保稳定。
　　精细化分工分为三部分内容：
　　第一部分是做数据库拆分和代码解耦。技术工作集中在数据库的拆分，先纵向拆分，不得已才做横向拆分，为了更快地服务业务的扩张，又夹杂了一些对代码解耦的工作。
　　所谓代码解耦，是把原来的代码系统想象成一个泥球，把它逐渐拆分成很多块。现在是有十多个业务模块，每一模块里面都有专门的团队来维护，内部又会划分域。
　　饿了么是数据库、代码拆分并行在做。然后，启动了强制接入新发布系统和单实例、单运用，也就是物理拆分。
　　第二部分是组建水平团队，例如大数据是水平团队，业务线是竖向团队，划分之后，从整个业务的发展走势图上升曲线非常陡，可以推断技术并没有防碍业务的快速发展，也就是技术的吞吐量、新产品研发效率是健康的。
　　第三部分，运维工程师还做了几件事，比如把监控分为Metric、Log、Trace、基础设施四个部分。组建Noc团队，负责应急响应，当发现有问题的时候，及时把信息通过Oncall通报给各成员。还有梳理各类扫除，接入发布、SOA，降级熔断开发等。
　　第一阶段，大扫除
　　大扫除的概念是什么呢？就是工程师对历史的事故进行分析之后，大概做出技术总结，把经常犯的一些错误，列成一些可做的规程，给所在部门的骨干进行宣传。具体内容包括：
　　SOA的服务治理，这里主要强调的是领域划分，高内聚低耦合。
　　对公共组件的治理。这里的数据库Redis由两个专业的团队组成，一个是DA，一个是DBA。DA治理的主要方案是收集各个产业伙伴的信息，规划容量，治理开发的使用姿势，把经验固化到研发流程里。本文转自《Linux就该这么学》技术干货
　　业务指标的梳理，包括对TPS的概念设定（状态轮转后再根据返回状态打点）、状态的停滞时间和状态的堆积深度，这个堆积深度主要是后端一些服务的状态轮转。
　　对超时链的合理设定和重试机制。
　　外部依赖及开关。为什么强调外部依赖呢？外部依赖可以分为两类，一类是跟其他公司的合作，例如调用其他公司的支付接口。还有一类依赖是团队之间的依赖，这里请不要相信任何人的服务，Bug随时都会发生。
　　关键路径。为什么要设置关键路径呢？一个是熔断，一个是降级。当非关键路径出现问题的时候，直接把它降掉就行了，不要影响关键路径。另外一个好处是接下来做补偿的时候，可以有针对性去做。
　　第二阶段，团队在日志上发生的事故也很多，可以逐个通过案例进行宣讲。
　　正在实现中的制定盲演习目标。因为八九百个技术工程师之间的代码交互本身是一个复杂系统，业务又是一个非常长的业务链，关键路径涉及的服务超过100个，简单的功能测试是可以的，但是容量大的时候，将很难定位他们之间存在的问题，比如A团队和B团队之间的代码耦合验收。这时想到的解决方案就是盲演习。盲演习除了在业务方可以做验收之外，还可以做基础设施，包括Redis集群、MySQL集群和网络。曾经做过一个测试，把一个Redis实例上的包量，按照百分之一的丢包率计算，导致整个全站的业务都掉底。当时整个Redis集群有12台，有几百个实例，其中一个实例有问题，就造成这么大的影响。通过盲演习，技术正在寻求单个节点宕机影响最小化的解决方案。
　　保稳定期。头号敌人是容量问题。
　　在业务快速扩张阶段，影响系统稳定性最大的敌人是容量，类似温水煮青蛙，或突然雪崩。因为不同语言判定容量的方式不同，饿了么1000多个服务组成的复杂系统，业务场景快速变换，服务变更频繁等等因素，导致容量问题困扰了近一年的时间。
　　最后采用的是定期线上全链路压测的方法，发动了一次百人战役，历时一个多月，整改了近200个隐患点，基本解决了容量问题。即便在低谷期的时候，也采用全联路压制。还可以配合技术在上线前的压测一起来做，然后把这些数据统筹起来进行分析。
　　秒杀事故
　　在517秒杀大促准备阶段，技术的运营思路是想用日常服务的集群来对抗秒杀，活动前把整个的容量提高了两倍多。但是当日订单量飙涨，秒杀开始后的那几秒钟，瞬时并发请求达到平常的50倍。当流量洪峰到来的时候，洪峰直接把前端Nginx的网络拥塞了。
　　反思下来，出现问题的原因是秒杀场景的经验少，对活动带来洪峰数据的预估过低，URL的限流未区分优先级等等。改进措施是专门针对秒杀搭建了一套系统，主要做了分级保护、建立用户端缓存、泳道、云集群和竞争缓存等。
　　第三阶段，增效。通过工具、资源、架构改造，提高效率。
　　本次分享大部分围绕事故来讲。每一次事故的出现都不是偶然的，很多问题是可以通过正确的使用姿势、提前做容量预估、灰度等方法规避的。如果说技术只是就事论事把这一件事情解决的话，事故往往在另外一个时间点还会出现。这就要求工程师以思考的方式去做事，比如做事故复盘、事故报道审核，还有验收小组等。然后，通过在各个阶段，多次把一个事故涉及的关键点提出来，不断地进行总结并制定可行的操作规范。问题的解决往往需要思维模式的转变，需要伙伴们多想想怎么从日常重要紧急的事务里抽离出时间思考。还有要敢于折腾。折腾是什么概念呢？就是要不断的演习、捣乱，工程师对于维护的系统，自己要非常的熟悉，这样在定位和解决故障的时候，就会非常精准。最后一个是灯下黑的问题，特别是基础设施这块。这在当时让人很头疼，查一个问题在基础设施上花费的时间是十多分钟到一个小时。后来有一个小伙伴改变思路，做出了一套系统，帮助团队非常好地解决了这个大问题。所以敢于思考，勤于尝试是饿了么技术团队非常重要的一个心得。
　　运营在互联网行业中是非常重要的一块内容，不仅仅需要有各种专业技能，而且要学会一定的运营方法，那么如果从互联网运营的分类角度入手，究竟如何才能完成运营目标呢？也就是从运营分类角度来提升运营能力，更加深入地剖析运营目标，并最终实现运营目标。
　　掌握运营分类内容，按照现有运营方法来分，可以分为用户运营、内容运营、活动运营和社区运营这四个大类，先搞清楚核心内容，其实都包含用户，千万不要把运营的内容和方法脱离用户，这点是运营中最忌讳的，也是运营过程中经常会遇到的问题，因为往往在追求运营目标过程中会偏离用户，因此要紧密关联用户是最重要的。
　　将用户分类不同类型，所谓的用户运营，说到底就是讲用户分类，最常见的可以分为活跃用户和普通用户，但是在用户运营过程中，千万不要只抓住活跃用户来运营，要知道普通用户是潜在的，另外对于普通用户是否能转换成活跃用户都是对运营能力地考验。
　　一定要生产让用户感兴趣的内容，内容为王是运营的王道，只有高质量持续性的内容，才会让用户产生持续性的关注度，就说最简单的，好多热文过后运营还是无法获得大成功，这主要是因为内容紧靠一次机会性地爆发是远远不够的，只要保持源源不断的好内容才是最好的运营方法。
　　要选择适合运营目标的活动，活动的形式在互联网上太过普遍，同样效果上面也是千差万别，就说最简单的，举办一个小型促销活动，前期广告宣传活动，活动执行内容，后期活动总结，这些内容在互联网运营中都是充满变数的，因此一定要选择适合自己的。
　　要学会善于借助社区平台，互联网上的社区相对于传统的社区活动，在网上根本不用考虑地域性，只要网络存在，针对运营内容，选择什么样的社区平台，都是可行的，但效果方面还是要根据运营能力的，毕竟大家都知道的社区运营，如何让用户关注你才是最关键的。
　　注意事项
　　不管是从哪个分类角度来运营，饿了么最终一定是和用户形成共赢的局面。