国美云成立于2016年，旨在通过云计算助力国美集团各版块业务发展，并对外提供领先的行业云服务。自2016年11月发布以来，国美云通过“成熟的架构经验+过硬的产品+贴身的运维”，在客户中获得了良好的口碑。今天我把自己在做云及运维自动化中总结的一些经验分享给大家。

一、 自动化理念

这几年从SA到DevOps，有幸参与了几家公司的IT基础设施的建设和发展历程。中间经历过不少硬仗，踩过坑收获过经验教训，摸爬滚打这么多年，尤其是参与了国美云的从无到有的整个建设过程，有一些经验和思考在此和大家分享一下。

做好自动化运维在我看来是有两个重要抓手：流程和工具，做好这两点基本就可以将自动化运维顺畅跑起来。总结起来是：流程梳理好，工具是手段。

我们都知道罗马不是一天建成的，所以我们在建设运维自动化平台时也要遵循循序渐进的原则，但大方向要清楚，互联网讲究敏捷开发，好产品是不断迭代出来的。

放一张蓝图，朝着目标前进！

图 1 运维自动化概貌

二、 自动化实践

我挑选了几个典型产品给大家做分享。

1.CMDB

1.1 CMDB的意义——降低运维管理成本

现在很多公司互联网公司不惜投入重金建设自己的CMDB，那为什么要这样做呢？早期的各个团队维护自己的数据已经很稳定而且比较灵活，引入CMDB及ITIL的概念，不但会打破原有的操作习惯，而且在系统建设初期会有大量的数据导入和使用习惯切换成本。我觉得这其实是权衡现金系统理念的成本和收益问题。公司早期的各个团队维护自己数据，可以较好的满足业务需求，但当数据量越来越大，业务越来越复杂，数据管理成本是急速上升的。这时候在使用传统的运维数据管理方式，恐怕很难支持业务发展。

图 2 数据管理成本

1.2 CMDB定位

国美云对CMDB的定位是数据中心运维数据库。运维公共配置信息存放在CMDB，其他子系统维护特定业务数据，但与CMDB信息有强关联。

图 3 国美云产品

1.3 CMDB建设

CMDB数据来源主要分两种，人工录入和自动发现。

图 4 CMDB数据来源

从存储数据来看，包括以下方面：

图 5 CMDB存储数据

主机数据建设

主机管理模块，用户可以通过综合搜索功能快速快速查询相关信息，具备服务器、网络设备录入和自动发现功能。

应用数据建设

建立服务树，确立人——应用——机器的关系，将人和项目进行关联，项目与资源关联。

资源数据建设

包括网段管理、机房管理、应用管理、机型管理，从IDC、机柜到服务器、网络设备等硬件信息再到网段、IP、操作系统等软件层次都纳入cmdb统一管理，以此作为云平台的数据中心，做到数据一致性，并对外提供数据服务

IDC 机柜视图：

图 6 机柜视图

1.4 数据消费

数据消费是CMDB最大的价值所在，CMDB的目的不是为了建立大而统一的数据仓库，而是如何将收集来的数据进行消费，并在消费的过程中逐步完善数据。以下是一些实践应用：

与堡垒机联动，应用增加机器时自动对负责人授权

与负载均衡系统联动，实现灰度发布

与监控系统联动，通过修改机器状态打开、关闭报警，方便维护或做变更，并通过汇聚监控数据对应用集群的资源利用率产生报表

1.5 问题与挑战

1.5.1 数据准确性维护，数据的非正常变更 相信人or相信程序？

可以说数据准确性是CMDB的最大难题，如何提高数据的准确性呢？有效的方法就是通过自动检测和人工审核，另外还需要建立一些标准，比如运维标准来禁止非标操作。

对于很容易判断对错的数据来说，检测脚本可以自动订正数据，比如宿主机上资源剩余量。有些则需要人工确认后才可以更改的，比如IP的探测，有些IP被不守规矩的人配置了但没在CMDB标志，探测到IP通后需要人工介入才知道具体是哪个应用使用。

1.5.2 性能挑战

作为一个数据中心，应对各种各样数据请求是基本功，有些请求比较简单，有些查询要求比较高，比如监控系统，当CMDB中的应用和机器变化都要及时推送给监控系统，还有一些经常查询的数据，可以放到Redis中以减轻CMDB的压力。

CMDB作为数据中心，除了提供查询数据还有分配数据的能力，比如IP地址的分配，这时要充分考虑高并发的情况。对此我们采用了乐观锁的方式解决这个问题，防止IP地址被重复分配。

1.5.3 其他数据处理方式

除了以上的提到的数据类型，有一些数据需要周期跑的，还有一些数据是需要延迟投递的，当然你可以在系统本身做定时器去做，但当任务量多的时候对系统压力也比较大。对此我们推荐放到MQ中，或者使用Beantalked，Beantalked相比MQ更侧重于任务的分发。

2.自动装机系统

2.1 技术简介

技术方案：PXE+RAMOS

中间还有ks，不过ks只是用来引导，没有其他功能，ramos是定制的，还需要修改initrd.img文件，替换其中的init脚本和预装一些命令和内核模块。Ramos是运行在内存的操作系统，里面放置了一系列装机脚本，可以做任何事情，新功能只需要扩展脚本即可。

2.2 功能介绍

目标： 只需要提供服务器序列号和位置，插上电源和网线开机就可以自动安装。解放生产力，减少IDC驻场人员和运维人员成本。

主要功能如下：

自动配置RAID，支持多种RAID配置

支持多种分区模式

自动向CMDB申请IP资源和主机名并配置IP，支持多种BOND设置

根据需要做固件驱动升级

支持拷机，对IO/NET/DISK/CPU进行压测（刚购买来的机器做，发现有问题的机器）

支持高并发装机，可以并发安装100台物理机，全部装完只需几分钟

2.3 上架流程

服务器下单后，在服务器还未发货之前，供应商提供机器详细信息，并录入到资产系统。SA对服务器进行规划，服务器发到IDC后，供应商按照区域上架相应机型，扫描机器的机柜U位即可，并上传CMDB系统，插上电源和网线开机就可以自动安装。也可以提前在CMDB算好机器的位置，服务器到货后按照指定的位置上架。

图 7 装机过程

2.4 拷机

拷机的意思就是对硬件做健康检查，具体是对服务器的CPU、MEM、DISK、网卡等进行压测，发现其中有问题的机器。为啥要有这个功能，其实我们是踩过硬件方面的坑的。总结下来硬件问题有两种，一种是比较明显问题的硬件，一种是看似没问题，但在高并发满负荷运行下出现抽风情况硬件。

前一种问题容易发现，但如果完全相信厂商没有做基本检测也会掉到坑里，比如有批采购的服务器中发现有一台的内存不一样，买的128G内存实际是160G内存，多了两块内存条，真是哭笑不得。这可不是什么好事情，万一是少两块内存条呢？

对于第二类问题用一般手段就很难发现了，需要长时间压测分析数据才能发现其中的问题，而且有时候跟操作系统、部署的服务有关。但一旦出现问题，排查起来异常艰难，耗时耗力。记得印象深刻的是tair超时问题的排查，当时出现了tair超时抖动的情况，百万分之几的出现率，在每天几亿次调用量的环境下，这是不能忍受的，问题发现是由于支付等关键业务放的开发对中间件团队的投诉。最后CTO召集中间件、测试部门、云产品支撑部、业务方开发多方组成联合调查组，经过近几周的排查终于发现是硬件CPU的问题。

另一个例子是DBA发现IO抖动（某时间点IOPS急剧下降到接近0）导致数据库压力陡增的案列。这些我们称之为毛刺现象，出现这种情况需要及时排查处理的，不然后续会出现大问题，万一赶上促销的时候爆发出了呢？后果不敢想像。当然如果业务量不大的情况下可以不用Care，因为中奖概率实在是太低了，但如果业务量大的情况下真的要重视了，因为摩尔定律告诉我们不要存在侥幸心理。

有过两次吃亏的经历，我们就着手从源头发现问题，防止有问题的机器流入到生产环境，源头当然是服务器上架装机了，自然而然这个任务放到了装机系统做。首先我们选择对CPU、内存、网卡、磁盘作为压测对象，并分别准备相应的压测脚本，最后嵌入到装机里，并在装机系统打Tag，装机时选择这个Tag就会执行拷机动作，最后把数据上传到CMDB进行数据展示。CMDB对数据进行汇聚，从CPU、内存、网卡、磁盘四个维度进行展示，发现有问题的机器。

以磁盘为例我们使用FIO工具进行压测，并对数据绘图展示：

场景1：raid0模式下

图 8 raid0模式压测结果

场景2：no-raid模式

图 9 直通模式压测结果

场景3：raid0模式下 升级firmware

图 10 升级固件压测结果

延迟情况

图 11 写延迟结果

2.5 推进标准化建设

在自动装机系统推进过程中，我们也推动了一些标准化建设，主要是网络和运维方面的标准化。网络方面主要是IDC网段的分布要提前规划好，交换机的分配、设置，网线的分配要标准化。运维方面标准化包括机柜的划分（我们分为大数据、DB、计算三种类型机器），机型配置的标准、raid的标准、bond的标准都做了规范。在这样清晰的划分下，装机上架自动化变不再是困难的事情。

图 12 装机标准化

3.负载均衡管理系统

3.1技术方案

4层使用LVS，7层使用NGINX

支持TCP、HTTP、HTTPS协议，支持证书管理，证书加密存储

LVS、NGINX使用集群模式部署，通过多台LVS组成OSPF集群LVS、NGINX做成标准镜像，可快速水平扩展

自研管理平台，实现LVS和NGINX的配置平台管理

配置入库并实时生效，保证LB集群配置一致性和高可用与发布系统联动，实现灰度发布与CMDB系统联动，通过机器状态改变自动从real-sever集群添加、摘除，实现应用一键上线、下线

图 13 负载均衡结构

3.2 推广，现有负载均衡规则迁移到系统

Lvs、Nginx转发规则从手工写的配置文件迁移到系统中是一件非常繁杂且量大的工作，而且最重要的是做好测试验证，让用户无感知。如果要完成这个工作，需要运维、配管人员、测试人员以及部分开发一同协作才能完成。如果没有很好的理由是很难调动其他部门积极配合你的，对此我们借助灰度发布的项目顺利的实施了这项工作。灰度发布项目是为了让发布能够白天发而不影响业务，以减少整个CTO部门人员的加班为目标设立的，对每个团队都是有利的，当然别人也会鼎力支持了。最后我们分四次在夜晚加班完成了整个迁移工作，做到了无缝迁移。

3.3 灰度发布

负载均衡最好的应用场景在灰度发布中，联动CMDB、部署系统一起实现灰度发布。

主要有以下特点：

支持90%应用随时发布，支持Http和dubbo服务，不影响业务，解放生产力

与slb、CMDB系统联动，从CMDB获取机器，通过slb操作负载均衡

基于流量灰度发布，可以设置发布频率（每次发布机器数量），发布流程:每次发布前自动扩容相应机器，部署应用后调用slb切换流量，依次类推直到应用机器都发完。

图 14 灰度发布流程

4.运维未来发展方向的思考

4.1 成本中心向利润中心转变

对于大型的集团来说，特别是比较传统的企业来说，受之前的IT技术能力限制往往是各个子公司建立一套IT系统，容易产生资源孤岛。对此的策略是集中技术，集中资源建立统一的资源池。除了对内采取降低成本的手段外，还需要对外走出去，将集团内的技术能力对外输出。

4.2 运维是基本功，运营是高要求

支持服务好内部客户，保障IT系统稳定运行不出故障是基本要求，在这方面各种技术也是不断发展，架构部断演进，从最初的All In One的小型机，到分布式架构再到多AZ，异地双活、多活架构，已经发展到一个比较稳定的阶段，基本上能满足中小型企业的IT需求了。在此基础上对我们运维人员更多的要求是向运营好IT系统转变，如何更好的挖掘数据，不断的降低资产、人力等各种成本是我们需要思考的地方。对此，我们也有自己的一些实践。

资源利用率的提升：

目标：挖掘设备使用能力，最大限度压榨服务器的性能，为公司领导和运营负责人提供快速查看服务器资源使用情况，为此我们提供了资源使用率APP。

APP主要有以下功能：

各公司以及所属应用对服务器资源线使用情况展示，包括机器总数，达标数及比例等

最近5周达标率走势展示

费用展示，各个产品负责人提供运营能力和决策能力

技术方案：

通过对监控系统（open-falcon）监控数据的采集、计算，通过预设的CPU、IO、网络流量等衡量条件，判断机器是否达标。对集群整体计算达标率。

图 15 资源使用率APP

5.结尾

以上是这些年我在运维自动化方面的一些实践和思考。除了上面介绍到的，我还在监控系统、发布系统、kubernetes等很多产品上有一些经验。另外这两年比较火的人工智，我们也尝试和运维做结合，实现AIOPS，比如磁盘故障预测，根据大量磁盘的历史监控数据进行学习，对现有的磁盘进行故障预测，并能做一些简单的修复工作，我们已经尝试在做。再比如，在流量调度方面也可以通过机器学习达到提前调度。由于篇幅有限，这里就不一一赘述，后续有机会还希望和大家做做分享交流。

整体而言随着互联网的不断发展，运维开发人员也要不断用新技术武装自己，技术不论好坏，只要是适合公司业务的，能提升公司效率，就值得我们去深究，另外运维开发人员应该更多的去了解业务，这样才有利于做出更多助力业务快速发展的产品。