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


摘自技术头条


那怎么来做自动化呢?有两个生命周期,第一个是服务器的生命周期,我们在IDC是没有人的,负责IDC、OS等底层治理的也就几个人,服务器做了包括PXE启动,启动的顺序,加电自动引导等定制化后,只要IDC的工作人员把服务器上架插上电,就自动化安装操作系统,完全不需要介入,操作系统安装完成后,后台的一些程序会把机器的信息写到CMDB,并和供应商那里反馈的数据做一个校验,如果供应商提供的数据跟实际的不一致,能及时发现,交付的时候只要做一个初始化动作就可以了。


我们在大量的使用虚拟化,早期这块用人肉管理KVM,去年到今年我们引入了zstack,zstack是一个完全异步无状态轻量级的私有云的解决方案,我们把zstack做了二次开发,跟流程系统做结合,用户把它的需求,如我是谁我要什么类型什么配制的机器配,主机名是什么等等信息填入ewf,审核通过后,zstack会自动的在后台创建,最重要的是整个zstack管理平台,和生产环境完全解耦,就算整个zstack挂了,线上的服务不受任何影响(新部署vm会有问题),但只要有database,几分钟就能恢复,重新搭一套起来,非常的快速和健壮。


刚刚有提到为什么会拔磁盘这种需求,有的人说我这边要存一些什么数据,另外一些人存一些什么数据,而我们的标准服务器不支持这么大的磁盘空间,所以我们提供了分布式文件系统,如果有这种大的数据存储需求,建议你走这个分布式文件系统,这样既能够做标准化,也能力提高利用率,目前在数据库备份、图片源站等方向在使用。


自动化硬件检测,我们有那么多的服务器,数以万计的硬盘,几乎每周都有服务器、硬盘损坏,作为运维一定要比用户比业务比产品比技术比所有人更早发现问题,所以我们要监控,磁盘是不是有问题,内存哪里有问题,是不是真的有问题,目前可能无法做到发现可能坏的情况,但已经可以做到肯定坏了就可以发现,发现只是开始,怎么处理,比如说是哪块硬盘,它的序列号是多少,它属于哪一台机器,这个机器在哪个机位哪个U位,是哪个品牌的,它的供应商是谁,把所有的信息收集处理出来,发给对应的供应商,同时发给业务团队,把机器markdown,如此同时,会记录这个信息,例如哪个型号的硬盘坏的比较多,哪个厂家的东西比较多,这样在采购技术评分会更有针对性,也可以用数据说话。


监控是运维的核心,从网络、硬件、OS、APP到service,这是很宏大的,希望以后有机会单独来展开,这里会简单的讲一些,如关键节点镜像流量做实时分析,这样哪些服务器流量很高,究竟是谁,哪一个IP,这样的话就能更好的帮助大家定位问题。


通过应用层打点,能知道各个机房在网络层各业务的调用关系,流量是从哪个service到哪个service的,哪个机房到哪个机房的,从这个图里面可以看到绝大部分流量都在北京机房内的,跨IDC的流量会很少,如果某个时间跨IDC的流量上升很多,其实是有风险的,可以给业务数据支撑,优化,告诉他们,减少这种调度。


报警这块,有数百万的各个层面的监控点,如大数据的机器,千兆网卡跑满是很正常的,但业务层可能跑400兆800兆就很紧张了,所以报警要支持自定义,另外,有些报警如内存不足,需要应用优化或者做一些服务器的升级,这个可能是一个非短期的过程,但是短期内也能接受,所以提供了一个snooze功能,收到这个报警邮件,点一下链接就能选择在某个时间段不发这个报警,减少报警量。


报警多了,分工细了,怎么来核算KPI呢,这是谁的报警呢?我们会对报警数据做分析,从这里就能看到,通过面板可以实时的看到谁的报警最多,哪个类型的报警最多,可以跟KPI做绑定,让大家更关注报警。


我们会把所有的日志做一些收集分析,这个图是网络日志,说交换机防火墙,基于一些级别,级别高了直接标红标黄做一些告警,包括这个是交换的,还有一些服务器的,服务器基于安全的,比如message,其实有很多很多的细节,硬件故障,或者内存OOM,甚至还有用户的操作日志等等,可以把这些日志收集过来做实时和离线分析,实时可以做告警,离线可以做容量,做一些展示,如某个业务的容量,我能知道每个业务的Qos,分析CDN供应商的质量究竟怎么样,谁好谁不好,我为什么选择它,它的哪个地域好,或者哪个ISP好,基于多个纬度的。


这个图就是自动化和流程的结合的一个例子,服务器的申请流程,申请人填一下这个机器是哪个部门哪个业务线要用的机器,希望什么时候交付,什么配制,把这个信息一填,审批完毕后服务器就会自动的交付,服务器创建初始化,并把这些信息全部反馈到cmdb,做数据的闭环。


关于架构评审,每周都会有架构评审会,把每次要新上的项目做review,它的架构是否合理,是否考虑了可运维性,需要什么资源,包括以后的升级、监控,埋点,还有对你来容量的预估,这个就在很大程度上避免了后续的问题。


后面,我就谈一些数据运营的思想,作为运维,自动化、标准化是最基础的,后面要做的其实是数据运营,让数据来驱动,举个例子这个图是机型的成本情况,它的成本是多少,每种类型的机器花了多少钱,机器分配给哪个团队,哪个团队花了多少钱,利用率怎么样。上面一个图是每个团队,第一个团队已经消耗了这么多的服务器,为什么消耗了这么多的机器,下面这个图是交付数据。


从这个数据里看得到,从15年开始整个服务器的交付最开始很少很少,而16年达到了日交付数百台服务器峰值的交付规模,通过这些数据,我们能知道,哪个时间交付了多少机器,交付给谁了。


还有我们CDN的日志,上面两个图的曲线是一样的,一个是Qqs,另外一个是带宽,CDN最近用的怎么样,从这个能够做一些更细致的分析,我们的用户在哪里,它的质量究竟怎么样,可以和厂商反馈这个事情。


做这么多的工作之后,其实还有很多不足,我们现在还在做跨机房灾备,未来要考虑做多活,随着现在数据流量越来越增长,我们是否要做全万兆网络,支持SDN的场景,我们怎么提高单机吞吐量,怎么提高资源利用率,饿了么应用场景其实很有特点,每天中午11:30的时候流量非常非常高,下午6:30又非常非常高,晚上绝大部分机器是闲置的,那闲置的机器能干吗呢?是不是可以做一些机器学习,怎么样让他们的配送更精准,我们是否要采用混合云的架构,把其中一些峰值流量迁移到公有云做弹性,这样的话可以极大的,降低成本。


最后就是一些感想了,谈到这个我就想到高铁,几年前觉得高铁投资那么多那么贵,是否不值得?现在看来解决了很多问题,带来很多收益,所以基础设施的投资永远要超前,要考虑未来三年甚至五年,这样能增强网站的稳定性,否则不断的变更升级,成本没少花,稳定性也无法保证;那第二个点,运维或者是技术一定要有业务导向,不能说做出一个系统来,就为了实现一个很炫酷的功能,要倾听用户的声音,解决用户的需求,不能为了技术而技术;第三点,服务意识很重要,出了问题,就算不是你的问题,你也要联系对应的人跟进,每个人都要有主人翁的精神;第四点,复杂就意味这不可靠,简单就意味着可靠,在私有云场景下简单即可用,我们一定要做标准化,一定要做到足够简单;第五点,其实做技术的人有一个坏毛病,总觉得别人的东西不好,我要做造一个,造出来又一版,出来一个又一个,重复的造,其实没有什么意义的,首先把方向定好,朝着一个方向一直往前,迭代更新;最后就是技术圈变化很快的,总有一些新东西,人工智能、机器学习都来了,我们一定要不断的学习,不断的拥抱变化。



我的讲演完成了,谢谢大家!最后求Linux运维!


Mail:wei.xush@ele.me


微信:xw2014

------- 现场视频直击 ------


【GITC上海站】


更多精彩内容将在技术头条持续发布,敬请关注!微信号:jishutoutiao

下载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 产品和服务。