摘自技术头条

先后就职于PPTV、携程、饿了么，参与和主导过数次业务快速增长导致的运维建设和运营，在运维标准化自动化数字化，以及基础设施等领域有一定经验。

主题简介

随着饿了么业务的爆发性增长，基础设施如何在保障稳定性的同时来支撑业务高速发展，并逐步向精细化运维、数字运维过度，反向驱动业务的方向发展。

演讲主题 | 运维基础设施之数字化运营

大家好，我是徐巍，来自饿了么，我今天分享的主题是运维基础设施之数字化运营。

我会分六个模块来讲：基础设施在饿了么的定义，我们的目标我们努力的方向是什么，接下来在做这些事情的中间遇到了一些什么问题，怎么去解决，接下来的方向，最后是个人在运维这块这么多年工作的一些感想。

在饿了，基础设施的定义包括IDC、网络、和基础服务，服务是对内服务基础平台，也就是运维平台化的概念，如DNS、CDN、yum等等，另外还有一些服务，举个例子，如果有一些大容量的文件系统需求，我们会提供分布式文件系统，例如日志集中收集分析处理平台等等。

我觉得运维的价值主要体现在三个方面，第一个是稳定，稳定又表现在2个方面，第一个不要出问题，第二个QoS要好，这两个字说起来比较简单，真正要做到还是相当困难的，特别对于饿了么这样一个及时性要求非常高的电商交易平台，在稳定这块的要求相当相当高，第二个要快，刚才洋码头也分享了这个事情，我们每天有超过100个application发布，运维怎么支撑，例如我们经常有各种秒杀活动，怎么样快速的扩容。第三个低成本指的是业务可能是指数级发展的，这个过程中我们运维的成本希望是可控的。

在这个过程中我们遇到很多问题，随着流量爆发式增长，我们的网络设备性能不足，从核心到接入到主机层面全部都出过问题；带宽收敛比过低，举个例子，线上有些的汇聚层到核心的带宽只有30个Gb；网络结构一个机房存在多个中心节点，节点之间只有2Gb的线路，这就形成了很严重的瓶颈；网络设备接入层存在网络单点，甚至不同型号混用，排障的时候就比较麻烦；还有监控不全的问题。

服务器层面碰到的问题可能更多一点，如不够标准化，存在机型混乱，各个品牌各个型号的机器，并且有硬盘内存各种插拔的现象，插拔会带来几个问题，第一个：备件管理会很难，硬盘的型号、类型、大小，和托架的匹配，不同厂商都有区别，非常复杂；第二个，很难做成本核算；服务器有的配外网IP，有的没有，有的做了bonding，有的没有，有的是单网卡，有的是双网卡，型号也不一样。

操作系统存在各种版本，虚拟化场景，早期的文件系统是XFS的，在大块的文件下，它的IO某些情况下可能会hang住，在centOS6、centOS7都有类似的问题，这个XFS bug，这个到现在还没fix完；还有网卡做bond0，也是需要交换机支持的，并且流量做不到很均匀，有些场景可能还有些小问题，还有省电模式， CPU降频，以及网卡中断，在e1000等低端的网卡会体现得很明显，还有网卡百兆的问题，CPU温度异常自动降频的问题，等等...

那我们怎么解决这些问题呢？第一个要做标准化，做标准化很重要的一点是不能让用户做问答题，要让用户做选择题，我们是运营部门，运营部是一个服务部门，服务部门需要很强的服务倾向，要服务好用户，但用户的需求是千奇百怪的，所以需要收集用户的需求，基于用户的需求收敛一些选择，而不能是发散式的，这样的话最后会把自己埋到坑里去的。

标准化网络，据目前而言，单机房物理服务器不超过5000的规模，大二层网络是能够解决的，所以我们现在的网络目前是一个大二层，收敛比做到了1：1，所有的节点全部都是做了堆叠，没有单点，这是机房内部图，下面一个图是IDC互联图。

目前是北京以及上海还会有一些云的服务，北京和上海之间，以及上海各IDC之间全部都用裸纤打通，网络质量会相对稳定，另外核心机房，北京上海的节点，全部都是BGP，北京还有2个物理隔离的两个BGP出口，如果某个出口被攻击了，流量会很简单的切到另外一个口。

关于IDC建设和规划，我们目前有数千台服务器，由于早期的规模不是很大，北京机房机位预留不够，所以就存在好几个模块，这个模块一堆机柜那个模块一堆机柜，该怎么布线呢？这个需要重点考虑，布线在很大程度上就决定机房内网的稳定性，所以做了标准化，三个机柜为一个模块，每次采购的时候至少是45台服务器，放在三个机柜里面，三个机柜里面接三台交换机，两台做数据一台做管理，我们以后的方向可能会更加的高密度，两个机柜甚至一个机柜做整机柜交付，这样的话布线会简单很多，交付速度也大大提高。

服务器层面把机型做一些标准化，我们会提供计算型服务器，存储型服务器，内存型服务器，把服务器的型号标准化，和厂商合作做定制化服务，如BIOS设置和固件版本，就规避了CPU温度过高，省电等等问题，出厂的时候，已经知道它要放在哪个机房哪个机柜哪个位置，大致做什么类型的用途，也刷进去资产标签。随着我们业务的爆发性增长，服务器需求是非常庞大且无法预期的，这个过程中就会受到一个制约，财务会问：你为什么要这么多钱，业务说：我要机器你要给我机器，为了缓解这个问题，我们做了采购周期化，每一个月或者两个月收集需求，让各个业务团队提交新增需求，和扩容需求merge起来，汇总做标准化，再同步到供应商，基于这些数据，采购和供应商谈一个采购框架，框架谈好之后不用每次采购都去比价，速度和价格会有优势，采购周期也会缩短，网络设备服务器都能够在规定的时间全部到位。

OS标准化这块，除了少量的历史遗留基本上全部干掉了，主要是支持CentOS两个版本。应用的标准化，首先要倾听用户的声音，了解研发需求的情况下，定一个标准，控制研发的技术使用，谨慎的引用新技术，举个例子，缓存用redis，如果现在用并且能hold住，没有特别的需求没必要再去引入mongo，类似的需求需要整个架构来review，技术平台应该是逐步的简化的，整个技术栈混乱的话，后台也会很混乱，但是我们也不能够因噎废食，还是要适当的引入新的技术，如redis cluser，它在集群这块会有一些优势，我们引入了，现在也在调研dpdk，也许以后也会引入。整个技术首先是hold住稳定版本，控制得了的情况下再考虑推进版，过程不能太激进了，用“好”技术比用“好技术”更重要，真的是这样的。

标准化的目的是什么，让整个系统更简单，做自动化的成本就会低，自动化做好之后又会促进标准化，形成正循环，减少人为操作，用流程和自动化固化下来，形成闭环。