那怎么来做自动化呢？有两个生命周期，第一个是服务器的生命周期，我们在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

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