返回
【GITC上海站】运维基础设施之数字化运营(上)
2017-02-23 16:09


摘自技术头条

— 个人简介 —
徐巍


先后就职于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住稳定版本,控制得了的情况下再考虑推进版,过程不能太激进了,用“好”技术比用“好技术”更重要,真的是这样的。


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

下载ZStack企业版

您已填写过基本信息?点击这里

姓名应该不少于两个字符
手机号格式错误
公司名称不应该少于4个字符
邮箱格式错误

下载链接将会通过邮件形式发送至您的邮箱,请谨慎填写。

下载ZStack企业版

还未填写过基本信息?点击这里

邮箱或手机号码格式错误

商务咨询:

400-962-2212 转 1

售后咨询:

400-962-2212 转 2

商务联系:

sales@zstack.io
申请ZStack多机版
姓名应该不少于两个字符
手机号格式错误
公司名称不应该少于4个字符
邮箱格式错误

商务咨询:

400-962-2212 转 1

售后咨询:

400-962-2212 转 2

商务联系:

sales@zstack.io

下载链接已发送至您的邮箱。

如未收到,请查看您的垃圾邮件、订阅邮件、广告邮件。 当您收到电子邮件后,请点击 URL 链接,以完成下载。

下载链接已发送至您的邮箱。

如未收到,请查看您的垃圾邮件、订阅邮件、广告邮件。
或点击下方URL链接 (IE内核浏览器请右键另存为), 完成下载:

感谢您使用 ZStack 产品和服务。

成功提交申请。

我们将安排工作人员尽快与您取得联系。

感谢您使用 ZStack 产品和服务。