深度好文-饿了么进化史（你一定会有收获）
深度好文-饿了么进化史（你一定会有收获）
大家都知道这两年饿了么的发展迅速，作为一名运维人员如果你工作在饿了么，你可曾这样分析过？之前分享过一篇关于饿了么的文章。
大家好，首先，先简单介绍下自己，我是徐巍，目前在饿了么负责基础设施的运维及开发工作，早些年就职于PPTV、携程、游族等公司，也算是一个运维的老兵了。饿了么成立于2008年，2014年底开始迎来业务的大规模爆发性增长，2015-2016年饿了么进入高速发展期，业务和服务器的增长都在数十倍的规模，这种大规模的增长必然带来很多挑战，本文将通过饿了么运维基础设施的进化史和大家分享不同时期应对挑战的措施和思路。
一、1.0时代
2014年至2015年被称为饿了么的1.0时代，业务迎来高速发展，这时更多考虑的是业务需要什么就赶紧上什么，而不是长远的架构等。每个人或团队负责自己的一部分工作，全力配合业务的需求。可想而知，这个过程中会有很多的由于考虑不周产生的技术债，也就是所谓的“痛”点。网络的痛
网络的痛主要表现在：
● 没有标准化：IP乱挂。外网IP直接挂到服务器上；有的服务器可能有2个甚至3个IP；有的有bonding，有的没有；
● 攻击多：业务高速增长的情况下还会有遭遇大量的攻击，一遇到攻击就可能宕机；
● 带宽收敛比较低。因为流量太大，如缓存高带宽的情况，交换机上联端口或者服务器千兆网卡很快被打满；
● 监控缺失：出了问题技术团队不知道，骑手或用户说不能下单了之后各种投诉，由客服反馈过来；
● 单点：从业务到整体架构到每个业务甚至机器都存在很多单点；
● 还有链路质量不稳定的问题。
服务器的痛
资源的痛主要表现在：
● 服务器交付不及时：去年到今年我们最高周交付量是3700+台逻辑服务器。平均下来每个月都是几千台的交付、回收，对效率要求非常高；
● 资产管理缺失：无标准，维护成本高。这时处于野蛮增长时期，需要服务器就赶紧买，不会考虑有多少服务器。也不知道服务器都是什么配置的，没有标准化，可能这一台有SSD，另一台就没有。维护起来成本非常高。
● 交付质量无保证：全部都是人肉装机，2015年底的情况是买进一批机器就临时组成一个装机小分队，一起装机。因为都是人肉操作，慢且交付质量无法保证，排查更困难。
基础服务缺失
基础服务缺失主要体现在：● 监控方面最早是用zabbix，配置不一导致有些硬盘没有监控、IOPS是多少都是缺失的，业务层监控也没有覆盖全；
● 负载均衡，每个业务自己搞一两台服务器，挂个Nginx做反向代理，都是这么随便做的；
● 集中式文件存储。每一台服务器会把很多文件存在本地，这为整个基础设施管理带来很多问题。举个例子，有的东西，比如理论上互联网很多的SOA服务都是无状态的，本地除了代码之外，不应该有其他的东西，但发生故障的时候，业务因为监控不成熟无法确认问题，需要看日志，这就复杂了，有人说要保留一周，有人说要保留一个月，有时日志一天就是几十个G怎么办？那就加一块硬盘，怎么加？谁来采购和管理？后面的标准化怎么做？集中式日志、集中式文件存储都是为了解决标准化的问题。
基础的服务也非常混乱。
二、我们做了什么
面对这么多的问题我们怎么办？其实运维做三件事情就够了。
- 第一是标准化，从硬件到网络到操作系统到使用的技术栈、软件的安装方式、日志的存放路径、名称、代码部署方式、监控从上到下，要建立一套体系化的标准。有了标准就可以用代码自动化，有了自动化和标准化之后就可以实现良性循环。
- 第二是流程化，流程化是把很多的需求通过步骤进行规范化和标准化。
- 第三是平台，构建一个平台实现标准化和自动化。
我理解的是运维需要做两个生命周期的管理。
- 第一是资源的生命周期管理，包括资源的采购、上架、部署、代码、故障处理、服务器回收、报废等。
- 第二是应用的生命周期管理，包括应用开发、测试、上线、变更，应用下线、回收等。
2.1 标准化
关于标准化有一个概念，我经常和大家强调，就是要让我们的用户做选择提，而不是问答题。举个例子，用户经常会说我要一台24核32G 600G硬盘的机器，这时你应该告诉用户：我现在有A、B、C、D四种机型，分别是计算型、存储型、内存型、高I/O型，你要哪种？这很重要，很多用户只是习惯了两台机器：一台配200G硬盘，一台配250G硬盘。用户的需求千奇百怪，如果没有标准化很难做到。我们的服务器型号是统一的，提供各种型号，你需要和用户谈，收集用户需求，尽量辨别出来用户的真实需求。
机型采购的时候要做定制化，比如要不要把省电模式关掉。各个厂商还有一些坑，包括直通卡的盘符漂移等问题，如何做自动化，机器来了如何自动上线。
服务器出厂和上架也要做定制化。我们把资源标成一个个模块，最小的模块是3个机柜，每个机柜放多少台服务器是固定的。生产的时候，比如说我要采购一千台服务器，我告诉厂商我已经规划好了，这一千台服务器放在哪一个机房里，哪一个机柜，哪一个U位，厂商会做定制化，机器到货上架之后，厂家人或服务商把电一接，操作系统自动化安装，甚至是网络，每一层都是标准化的。
2.2 流程+自动化
上图展示的是饿了么的工作流引擎。可以理解为资源生命周期中有很多流程，比如服务器的申请，包括物理机申请、虚拟机申请、云服务申请等；比如大量状态，包括回收等。流程的背后是自动化，规范用户输入，让用户做选择题，要什么样的机型、什么样的配置、多少数量，表单一填好，后台就自动化地执行了。
2.3 自动化+平台
● 物理服务器自动化装机及初始化。比如我有几千台服务器，能不能一天装好？360曾经一天最高装了5000台服务器，我们的最高纪录是一天装机2500台物理服务器。● 网络设备上线自动化。
● 资源管理平台。对所有的资源能做统一化管理，类似资源交付流程的管理后台
● 分布式文件系统，主要用于数据库备份及图片处理
● 日志集中平台，所有的日志集中到elk上，不要上服务器看日志了
2.4 私有云平台(Zstack)
饿了么早期实行野蛮生长的方式，虚拟机就是自己创建。创建完了会有一个问题：怎么知道一个机器可以再创建呢？比如说我一个机器可以创建6台虚拟机，已经创建5台了，怎么知道还有一台创建在哪里？需要把一个业务布置到10台物理机，甚至是跨机柜的，避免单点物理机或单个机柜出现故障，影响全局应用，这就涉及到了虚拟机的资源调度，我们选用了ZStack。为什么选用ZStack呢？
私有云比较火的三个开源技术选型分别是：OpenStack、CloudStack和ZStack。
本着越简单越好的原则，我们排除了OpenStack，它太重了，没有人也没有时间去Hold这么大的系统。而且从行业内得到一些反馈，总体来说不是很好。
CloudStack的开发者也是ZStack的开发者，当时CloudStack社区已经没有人维护了，并且它不支持centos7。
所以我们选用了ZStack，那个时候ZStack也有不少bug，但还是比较简单的，我们可以做好。
ZStack的特点：简单、无状态、接口化比较简单，安装一下，就可以跑起来了。当然想要用好，后面还是有点难度的。它是一个中心结构，所有的都是基于消息做的，我们的ZStack平台看不到什么高大上的页面，后面都是自定义的接口，前端的流程自动调后端的接口，通过一些消息来进行同步。ZStack目前已经管理了超过6000台虚拟机。
三、2.0时代
在1.0时代我们做了一些标准化、自动化的工作，让我们的东西顺畅地跑起来。从2016年开始，我们进入了2.0时代，这个阶段也存在一些痛点：SLA是什么？有数据吗？你说效率很高了，如何证明？一天交付1000就是高吗？数据怎么衡量？在IT圈里，除了上帝，所有的东西都要用数据说话，一切要可量化，可衡量。
四、我们做了什么
这个时期我们解决痛点的措施从两方面着手：精细化运维和数据化运营。运维和运营是不一样的。
4.1 精细化运维
精细化运维包括以下方面。● 网络架构的持续升级
● 服务器性能基线制定
● 服务器交付质量校验(不合格不交付)
● 硬件故障报修自动化
● 网络流量分析
● 服务器重启自动化
● Bug fix:省电模式、bonding。。。
网络架构持续升级
早期我们有一个数据中心，使用的核心交换机是华为的5700SE，这意味着什么？在一次流量突发中，这个设备引发了我们P0级的事故。所有我们重新定义了网络标准，并持续做了大量的网络升级，包括核心、负载均衡、汇聚到核心的带宽，以及网络架构优化。
还有IDC间链路，最早我们一些IDC间链路是打的V**，现在同城的用裸纤，跨城的都是用传输。这里也有依稀持续的投入。
网络优化
如图所示，北京和上海的IDC，从办公室访问IDC我们都拉了裸纤和专线，全部做到足够的强壮。还包括到第三方支付的，比如支付宝、微信支付等等。
服务器的性能基线制定，交付质量校验
交付的服务器是否足够好，要用数据说话。我们所有的服务器都有一个基线，比如一种计算型的机型，计算能力、I/O能力是多少、网卡小包的PPS可以达到多少等都是可以测试的。在交付的时候会进行性能测试，达到基线才可以交付，否则就不能交付。
网络流量分析
我们当初遇到过汇聚到接入之间某根光纤带宽跑满的情况，因为早期带宽收敛比不够，4个10G在上面，由于网络流量的算法原因，导致4个10G端口的其中一个被跑满了。我们要知道关键节点的流量是哪一个业务在跑、跑的怎么样，有问题要告警出来。
硬件故障保修自动化
目前我们的服务器数量很多，每周可能存在数十台的故障，怎么第一时间知道故障，并且在不影响业务的情况下快速修复？
还有一些其他的工作，如服务器的自动化重启，做运维都很辛苦，如果半夜有一个故障或者服务器坏了，需要重启，如果你还得通过远程管理卡输入密码登录进去重启，就太low了，要实现自动化重启。
服务器自动化报修总体来说是几个逻辑。
● 故障发现
● 故障通知：用户、IDC、供应商
● 故障处理
● 故障恢复校验
● 故障分析
第一是故障发现，如何发现资源故障？监控，带内、带外、日志多方位监控。所有监控的报警到一个地方来做初步的收集，最后就会到这个系统。
这是9月19日的图，可以看到有非常多的故障，发现这些故障之后要通知，通知也是很复杂的，是短信、电话还是内部的工具？我们要多渠道地进行通知。有的用户比较牛，他说你不用给我发邮件，我这边有一个接口，可以做自动化的发送，比如我们的服务器故障了，自动给他发一个消息，收到这个消息之后，业务就开始把这个机器关掉，甚至把数据操作等一系列操作做完，做完之后返还给报修系统一个消息：这个服务器你可以去维修了，收到这个消息之后，通知IDC、供应商：哪一个机房、哪一个机柜、哪一个U位、序列号多少的服务器发生了什么问题，请于什么时间段上门维修，同时通过各种方式告诉IDC：谁身份证号多少，什么时间会带着什么设备上门做哪一个地方的维修。
我们数以万计的服务器只有两个人来进行运维。供应商维修、故障处理是人肉的，处理之后登陆外部系统，给我们发一个消息，告诉我们这个服务器修好了，我们的程序会自动检查故障有没有恢复，如果恢复了，就通知用户说资源什么时候修好了，用户接到消息，会把服务器再拉回来。同时所有的故障信息都会进入我的数据库，自动进行分析，看到哪一个品牌的服务器不好、哪一个机型或者是哪一个配件坏的比较多，在做供应商和机型选择的时候就可以有一个参考。
精细化运维还有各种Bug Fix等很多细节，细节是魔鬼。当初被省电模式坑得很惨，包括网卡的问题，从硬件到服务，代码的Bug就更多了。
运维管理平台
我们有很多机柜、机房，这些数据都通过自动化的系统进行采集和展示。
运维重点需要考虑三件事情：质量、效率和成本。上图中可以看到这是一个模块，这个模块当中有很多的机柜，这些机柜用电量很大，这就体现出了成本，我们大量的机柜是黄色，黄色是告警。一个机柜的电量是4000W、5000W，我们会尽量把资源充分利用起来，成本相对最优，所以我们的机柜都是一些比较高电的，比如说47U的机柜我们会放很多的设备。
4.2 数据化运营
IT所有的东西都要用数据说话。资产情况
资产情况包括：我们有多少服务器，分布在哪些机房，有多少机柜，服务器是什么机型，品牌和型号，哪些是占用的，哪些是未用的。
网络流量分析
网络流量分析包括：网络流量来自于哪些人，比如说这里有一个异常突起，我就知道这是在在跨城带宽传输造成的。跨城带宽大家都知道，是非常贵的10G带宽一下子跑满了，扩容要三个月，这个时候整体业务会受到严重影响。我们要第一时间知道谁在用这些流量。
服务器去哪儿了
我们买了那么多公司的东西，得知道这些机器谁在用？图中的这条线是资源利用率，这是大数据部门，图中可以看到大数据的资源利用率是很高的。而其他的部门资源利用率不高。通过这个数据我给你发报表，告诉你花了多少钱，用了多少服务器，什么类型的服务器，分布情况和利用率是多少。这是运营的思想，而不是运维的思想。
资源交付SLA
我们的工作量如何衡量？我们交付了很多服务器，什么时间交付的、交付的是什么型号、交付的效率如何？一定要可衡量。举个例子，做年终KPI考核的时候，你说我们部门做了很多工作，这个工程、那个项目，这些都是废话。只要告诉我，今年做了几个项目，这些项目分别部署了多少资源、效率是什么，以前平均交付时间是2小时，现在是20分钟，未来是5分钟。
成本核算
今年我们花了很多钱，这么多钱花在哪里？谁花的？买了什么？给谁用了？用得怎么样？从各个维度来看，这些成本的构成等等，甚至我们的成本和友商的成本对比，都通过这些东西可以看出来。
供应商的质量评价
比如每个配件什么时候故障了，故障率是多少？自动给厂商打分，报表会自动交到采购，作为采购的一个技术评分，这个过程没有人的介入。包括质量方面，某一个厂商这一段时间的质量下降了，可以要对他进行售后管理。
五、总结
这次分析主要是资源生命周期管理，本文大部分内容偏向于底层资源，但思想可以落到所有的模块，比如日志、不同运维系统、监控等。最后谈一些感想。
简单及可用。我从入行到现在从事互联网运维差不多十年时间，早期服务器的故障需要很懂的人一台一台地去看，现在的做法是一台服务器出问题了，拉掉，另外一台服务器快速顶上去，成本可控、质量可控、效率第一，这种情况下一定要简单及可用。
这句话最早是百度传出来的，这也是我做运维的一个准则，一切的东西都要简单。有一些开源的解决方案具备很多很牛的功能，但你要深刻思考你真的需要吗？它真的对你有帮助吗？真正核心的价值是什么？所有软件程序必须要做到高类聚低耦合，避免很强的依赖。
标准化能标准化的，自动化可以自动化的。标准化一定是未来的趋势，现在随着阿里云、腾讯云的发展，小的公司很多东西都会迁移到云上，未来混合云的架构，运维可以做什么？怎么做到快速的扩容和弹性计算，弹性计算包括容量规划、压测等，这当中有很多的点，这些点的基石就是标准化、自动化。
尽量不要重复造轮子，自己造轮子。搞开发的人很喜欢造轮子，总觉得我到一家公司，不写点东西，显得我很Low或者没有绩效。“用好”软件比用“好”软件更重要。工具没有好坏之分，就看你能不能用好，在对的时间做对的事情，不要有对工具有偏见，它只是一块砖，我们要做的是把这些砖做好合并，用好这些砖。
先有，后好(80分万岁)。万事起头难，第一步一定要先有。不要说我想一个东西想得很宏大，各个方面设计特别牛，要考虑的是这个东西能落地吗？落地是最重要的。那有人会问做了很多东西，可是很烂怎么办？先收口，收口之后慢慢优化。
互联网快速发展，互联网应用一定要快速迭代，我们公司每天有数百次发布，敏捷式开发快速更新非常重要。这个过程一定是螺旋式上升的，甚至有前进两步后退一步的情况。不要说谁家的架构就是最牛的，只有适合你才是最好的，而且不同阶段适合你的东西是不一样的，需要不断重构和迭代。
现有用户和新用户同等重要。这是亚马逊提出来的。亚马逊有一件很有名的事情：当年有一个用户要将服务迁移到亚马逊，预计上千万美金。亚马逊评价说，这个服务迁过来，要做什么样的改造，这个改造会对现有业务的稳定性造成什么影响。经过层层上报，最后的结论是这个用户我不要了。因为接受后现有用户得不到保障。
这一点非常重要。2016年9月份，我们的日志系统上线，刚刚上线的时候，峰值8万/秒的请求量，到10月份达到80万/秒，这时还不断有用户过来说要接入。我当时感觉硬件、架构等方面都快Hold不住了，我跟大家说了这件事情，给自己争取了1个月的缓冲期，做了大量的技术改造，现在峰值每天超过260万条日志，也可以进行实时的收集、传输、存储、分析。这当中一定要找一个平衡，在服务好现有用户的同时，逐步接入新用户，当然也不能很生硬的说“no way”，这样你的品牌就没有了。
拥抱变化，不要有玻璃心。我工作了很多年，也去过好几家公司，可以看到每家公司在不同阶段都有不同的变化。比如我的团队中基本上都是开发没有运维了，标准化做好了，底层就是一个硬件软件，一个操作系统专家，其他的都是一些程序员。可是很多人本身是做运维的怎么办？要开始学习代码，要有变化和成长。今年我给团队的目标是2017年要把我们这个团队做没了。意思是要做到无人值守，或者只花10%、20%的时间和精力做后台的bug fix，其他80%的时间做价值输出，现在这个目标已经在落地的过程当中了。
Q & A
Q：你们会对业务部门的服务器需求进行指导吗？A：我们的服务器分为好几种，包括计算型、存储型、内存型、高I/O型（数据库专用）。存储型主要是大数据在用，计算型是做虚拟化和计算的，比如SOA无状态服务，在申请机型的时候，每个业务的机型基本上都是一模一样的。新业务起来的时候会有架构评审，评审架构有没有认证、有没有数据打点、有没有日志规范、有没有日志规范、整个架构设计是否合理、资源需求是否合理。
Q：日志统一平台的是自己做的吗？
A：我们有集中的管理中心，写了一套脚本自动安装Flume，也在Flume上也做了二次开发，比如 Java有的是跨行日志，我们要做合并行的处理；比如有的业务异常日志2M，我扛不住的，这种异常日志我会做判断，丢弃；比如有的可能目录里有多个日志，怎么处理？
Q：用户查看日志，对各个业务索引是怎么实现的？比如说我是业务方，我只看自己业务的日志？
A：目前这个没有做到，大家知道kibana的权限管理是很弱的，目前我们还没有做这一块。这里我要提一个点，我们有一个系统，业务代码里面会埋一个SDK，把堆栈的调用链的关系都打到这个系统，最终会展示出列表，这个系统会和我们的日志系统对接，用户看到调用链，一点就可以把类似信息拖过去了。现在kibana这个页面用的人不多，相当于只是后端的服务了。
Q：您刚刚提到会有一个性能测试跑压测，你们的压测怎么做呢？
A：用系统自带的一些I/O压测。每个机型的基本指标，比如说CPU能力、IOPS、PPS能力。
Q：刚刚说到日志，当我的应用达到十几万请求的时候，如果都往Flume上写，就把服务器的CPU占满了。我目前的做法是先把日志放在本地，再通过网上推上去。
A：Flume是很好的工具，但性能不是很强。我们压测它的处理能力最高是2万条/秒，实际上它是跑不到这么高的，包括它在跑的过程当中会有一些假死，甚至有的时候sink会满掉，这当中要做大量的监控，你应该把Flume做成分布式的。比如说我每个业务服务器上都有一个Flume，通过TCP、UDP、日志直接读文件的方式。这个要看业务的容忍度，我们有一些业务堆日志说一条都不能丢，我们测试下来UDP有30%-50%的丢弃，如果说对日志完整性要求很高，不建议使用。
Flume1.7版本可以支持基于偏移量的日志，而且是支持多文件的。越简单越好，越标准化越好，因为打到本地你的磁盘空间也可能有问题，甚至是I/O也可能有问题。
Q：你们开发和运维团队是如何运作的？是放在一起吗？
A：关于这个问题，我和阿里也聊过，他们做了3次探索。第一个是开发开发，开发好了给运维用。很多公司都会这么做，这么做有一个坏处：运维说你开发的是什么东西，我不愿意用；开发就说运维一天到晚就知道提需求。双方关系很不好，最后做出来的东西没有人用，那就没有意义了。
阿里做了第二个尝试。既然这样，那所有的开发自己开发自己运维，运维做其他的事情，公司这么大，肯定有事情做。这样的坏处是：开发对运维理解不深刻，运维系统和线上业务开发是很不一样的，运维系统对可靠性要求相对差，但是对质量和效率的要求很高。开发不懂运维，容易出现各种故障。
因此阿里做了第三件尝试，把开发和运维合在一起。
饿了么有部分专职的开发和运维团队，也有开发和运维合在一起的团队。