国美云成立于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 负载均衡结构
