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