本次演讲主要介绍了国美云如何将企业IT成本中心（基础运维投入）转变为利润中心（独立云计算公司），及国美云自研云计算平台的整体架构。

前言

今天的主题是国美集团基于云计算和运维自动化IT的建设和实践。国美在大家印象里是比较传统的公司，因为毕竟有几十年的历史了，大家会觉得云计算和自动化运维怎么跟国美搭上边，希望通过本文为大家解一下惑。主要分为以下四块：

国美简介

国美运维新思路

国美云计算实践

国美运维自动化实践

1、国美简介

首先我想大概介绍一下国美集团，大家肯定最深的印象就是家电卖场。因为国美1987年开始就开始做家电卖场，现在有1500家门店，全国有30万员工，是国内最大的家电连锁企业。

国美发展到现在涉足面不光是家电零售，其实在下面的六大板块，我们公司都有涉及，地产开发、互联网金融、智能手机、智能制造、互联网和线下零售，集团旗下有很多上市公司分布在这几个板块里。

再讲一下我们的国美技术，国美在全国一共有30万员工，业务板块也非常多，这一些业务板块很多像互联网、智能手机、智能制造，线下零售都对技术要求非常高。

我们国美集团有上千名的技术人员，而且这一些技术人员支持的业务面也非常广，对底层有一定的挑战。国美发展这么多年来，从2000年左右就开始统一存储订单信息，我们国美云既有IOE又有云计算又有虚拟化，这是我们遇到一个比较大的挑战。

2、国美运维新思路

下面我们介绍下国美运维的新思路，怎么样帮助企业降低成本提高效率，这是我们的一些思考。

首先我想说一下企业的关注点，90%甚至100%的企业最关心的是什么东西？我自认为企业最关心就是赚钱。

从运维来讲怎么帮助企业实现这一目标：一个是降低运维成本，另一个提高运维的效率。

围绕这两点我们做了思考，我们想用云计算和运维自动化去实现这个目标。云计算就推出了国美云，国美集团统一的资源都到国美云建设，减少每一个公司重复的投入，降低企业的成本。

其次自动化，国美云降低自动化的平台流程，提供给各个子公司使用，帮助各个子公司提高运维效率。刚才我介绍国美还忽略了一点，其实国美大概有30多家产业类的公司，国美互联网、国美电器、国美在线、国美金融、国美手机都是需要这一些基础服务。

以前这些公司在做基础服务的时候，每一个公司都去组建自己的运维开发人员，基础运维人员、网络人员去承接IDC服务器建设。

我们的理念中一个是云计算，我们做了一些改变，首先是2016年6月份我们在集团层面成立了国美云这一家公司，目的就是提供给各个集团内的产业公司基础的 IAAS 云服务。

其次通过成立国美云我们把所有集团内的基础技术全部集中在一起，各个公司的基础运维研发人员、云计算研发人员和基础运维人员都归拢到国美云统一底层的基层服务。

另外我们成立国美云后，资源也得到了统一，就是我们的机柜、机房资源也是统一的进行采购、管理。资源服务器统一后，建立集中的资源池，统一的进行交付，各个公司再按需进行购买，不需要每一个公司提前自己购买资源池在那闲置浪费。

我们想通过组建国美云把我们的运维技术归拢到国美云之后，把我们的产品、技术对外输出出去。一方面对内服务，微盈利，集团整体的支出减少。对外，服务产生外部的服务能力，成本中心转换成利润中心。

另一个思路就是我们运维自动化，很多公司都在做。我们做的不同，我们把各个公司的运维自动化需求全部归拢到一家公司来统一实现。

运维标准是运维自动化的一个基础，没有运维标准你就没法进行大规模的部署、大规模的上线这样的操作。我们首先做的就是运维标准化。

其次我们打造运维生态链，后续我还会介绍生态链有哪一些组成。我们围绕着CI/CD的流程做了一个运维自动化的生命线，贯穿着这一个流程中间的是自动化平台。

最后一个就是统一建设，我们会建设二十种、三十种，但是不是所有的公司都用完这二十种、三十种，需要按需选择各种的自动化平台。

3、国美云计算实践

前面两点大概介绍了一下我们的一些思路，下面我想介绍一下我们的云计算的实践。

我们做了一些产品的思考，要做国美云，时间就是金钱，必须要快速服务，如果我们耽误两三年做出来，其它各个公司的业务发展都会受到很大的拖累。

本来我们做国美云的目的就是提供给各个产业链的公司，我们的手机我们的 IOT 基础服务，所以我们必须要快。

其次的话我们优先开发基础云产品，就是云计算，现在阿里云、腾讯云产品线非常丰富，IAAS 、PAAS 都非常丰富。所以前期人员有限，提供内部服务的情况下我们想提供一个 IAAS 服务，在 IAAS 再配备 PAAS 和 SAAS 服务。

考虑到国美云建设机房的速度和投入，自己建机房速度是会比较慢，其次前期的投入要比较多，而且要很长的时间比如说两年、三年我们才能把成本收回来。

我们在自建机房的基础上支持第三方的云，当作国美云来进行销售。比如说我们现在在北京建了机房，但是我们内部的业务很多都是发展在南方深圳那边，于是我们是通过利用第三方云包装在国美云平台进行统一的销售。

国美云最大的价值其实刚才也说了，就是运维希望达到的一个目标吧。一个就是降低成本，另外一个提高效率，这也是一个云的特征。

降低成本比较简单，因为资源可以复用，虚拟化比例提升，而且每一个公司按需买服务器，而不是一直买服务器就是堆着，所以降低了成本。

其次提高了交付效率，基于虚拟化可以实现一个很快的交付。

运维人员很多情况下是一个内部的运维支撑部门，就像刚才说的一样是一个内部的思维，跟产品跟我们的业务关联度不是特别大。

但是通过做国美云，我们很多运维人员要做乙方给甲方各个产业公司的基础云服务、运维服务。这个过程中，其实在思维模式上已经发生了从内到外的转变，产品的服务意识、服务形态都有一定的转变。

这是我们的一个 IAAS 产品架构图，其实相对来说比较简单，因为我们现在聚焦点是在 IAAS ，不论 SAAS PAAS 都有 IAAS 。

我们把产品主要分了三个层面：第一层是用户层；第二层是控制层；第三是服务层。

用户使用我们云平台，现在特指我们产业内各个子公司的一个SRE人员。使用我们的云平台会登陆我们的 Portal，还有基于云平台做了一些自动化运维的平台，可以调用 API 购买国美云主机。

控制层主要是起到资源总体调度，用户在 Portal 购买云主机会牵扯到后端很多的服务：我们内部运维管理平台，所有的资源信息还有一些主机信息、计费信息等信息。

服务层我可以重点讲几个产品，后面也会讲。 CMDB 是云的所有基础还有资产配置信息的数据库， GMSTACK 类似于 OpenStack 会做一个资源到云主机的创建管理的工作，RDS简单的提供出来。其次是不同的产业公司有相互结算，有独立的计费系统对主机和网络资源进行单独的计费。SLB是开发软负载，VPC我们现阶段主要是硬件厂商的SDN控制器做的，用一些开源的方案，现阶段是通过利用第三方的控制器去做的。我们现在是用 service 快存储提供给云主机使用，CDN第三方云平台，也是通过国美云统一的服务。下面还有 VPN 还有 Monitor ，最后有一个 MIX-Cloud 对接第三方云的API，上层购买资源的时候会请求 GMSTACK 购买第三方云的资源。

这是我们的 Command 中间的控制层，这一套系统是起到统一调度的作用。我们是用 Go 语言编写这一套系统，主要的作用是用户请求过来，它创建 VPC 或者购买云主机到内部，其实是一个很复杂的过程，并不是单纯请求某一个平台完成。

所以 Command 起到接口调用编排的作用，我们这一套系统支持同步、异步，并发一个请求过来，我们可以把它处理成异步还有回调的操作，这平台也是用 thrift 框架，同时 http、https、rpc都提供。

说一下我们的监控，其实最早的时候从我们2016年6月份创建公司以来，包括国美之前的一些运维体系，用的都是 Zabbix 。Zabbix 用的挺多，在主机达到千台以上。

Open-falcon 都是Go写的，它的性能还是比较好，而且我们做了一些针对 Open-falcon 定制化开发。比如说虚拟机，我们一般监控都是部署在虚拟机内进行监控，但是其实做云的话，这对用户来说体验不是特别好，所以我们现在所做的是从主席机直接对云主机进行监控，比如说CPU内存硬盘使用情况。

今年年初到6月份我们的 Open-falcon 有一个稳定的过渡，因为 Open-falcon 是小米和滴滴做的，上半年还是相对比较稳定。

而且有一些功能比较吸引人，比如说报警的收敛，比如原本会报警十条短信，另外的话还有报警的机位挂了，原本会收到很多短信，但是这个会帮你去拒掉。目前我们国美云大概有几千台云主机，全部是用 Open-falcon 做的监控。

其次就是云主机的调度，我们云主机调度也是自己研发，就是整套云的底层虚拟化并没有 Openstack。完成这一套调度有一些系统，每天有几千台创建量的时候，可以实时的去做水平的横向扩展，只要在这后面加调度系统就可以了。

其次的话我们的调度是通过服务状态，调度器可以去灵活的选择，根据不同的场景。

4、国美运维自动化实践

我再介绍一下我们运维自动化的实践。

这是我们的一个运维自动化实践图谱，也算是生态链。这就是围绕 CI/CD 的流程，核心标准化、流程化，把所有的开发、运维、测试、配置管理项目管理这一些角色全部通过这一个流程给汇聚起来。

我们现在这些平台有一些还在开发过程中，但是未来我们国美整个生态内的各个产业公司，运维自动化平台都会从这里选取使用，相当于这是我们国美云提供一套生态链给各个产业公司使用。

说一说我们的运维自动化的产品，CMDB 很多公司都有，互联网公司无论大小都有这种产品的存在。但是我们的产品主要是有什么特点？我们把网络资源当作资产一样管理起来，就是IP地址，其次我们 CMDB 里面维护了用户，用户指的是开发人员、测试人员，还有运维人员和设备的对应关系。

这是产品线的图，通过对应关系获取一些信息。其实很多的系统，比如说我们的监控系统都是可以通过产品线用户、机器的对应关系去获得一些信息，去实施一些服务，比如说堡垒机某一个用户就是登陆的权限。

其次就是通过 CMDB 的基础资源，我们形成了一个机房机柜的管理视图。因为我们 CMDB 存的信息比较全，每一台机器的资产信息，位置信息还有它的一个机型信息都有，所以我们通过这信息，视图就会有所有的机房排列的情况。

你点开每一个机柜，里面的每一个服务器摆列的情况都看的很明确。我们运维怎么上架怎么选择机柜也是非常方便，这图也帮了我们运维人员很多，我们服务器到货之前都是看这图让供货商直接参与进行了。

装机系统也是 PXE 和 PXD，但是不同的点是从 PXD，就是 ROMOS 里面有定制的启动脚本还有一些安装脚本。进入到 ROMOS 以后 CMDB 拿一些基础信息，应该装什么操作，应该分配什么IP地址，IP地址都不需要制定。

然后在装的过程中还需要去 wget 包，我们挂载硬盘，把包解压就装了系统。这系统的好处就是非常灵活，我们可以在操作系统里面定制很多东西，比如说我们现在做的就是 RAID ，根据梯型我们定义A5或者A6，就直接把 RAID 装机过程中做掉，其次对机器的压测还会发现一些新的问题。

装机系统性能也是不错，我们曾经安装过一百台以上的物理服务器几分钟就可以安装完成，主要的优点还是灵活性比较好。另外装机系统要使用的话，其实只要录入SN和它的位置，其他的都是通过 RAMOS 采集到 CMDB 来完成，对运维人员来说非常省事。

我们的负载均衡系统底层是基于 LVS 和 Nginx ，我们的云平台通过 namespace 封装对外服务。另外比较好的一点，我们作为自动化跟 CMDB 发布系统做了一些联动，下面会有一个稍微的介绍。

刚才我说了 CMDB 就是大家在前面的图里看到的，他在我们的服务层，其实是在我们的云平台里面，在我们的服务层起到一个资产管理还有配置信息管理的作用。

我们的 CMDB 还做了一个 SAAS 服务，提供给我们的 API 服务，在外面单独部署。我们现在的场景，国美互联网单独部署了我们的 CMDB ，通过 API 获取国美云的主机，其次自己管理了一些自己的主机， CMDB 不光云的平台，也可以作为 SAAS 单独在外面进行部署。

我们的灰度发布主要是依赖负载均衡系统，现在是支持 HTTP 的灰度发布，这集群十台服务器我们需要发两台，这时候从七层负载均衡上拿掉，拿掉过后等一段时间链接完全没有，因为 HTTP 就是短链接，等10秒过后，直接发这两台机器，发完过后没问题了，脚本都没问题，直接在负载均衡里面相当于一个滚动的发布，这样实现了基于流量的灰度发布。

这个过程中用户基本没感知都是 HTTP 的感知，并不会维护在前端，所以之前很多重要的应用都必须半夜去发，尽量影响较少的用户。

其实通过这系统我们跟 CMDB 部署结合，这过程中实现随时发，而且后续我们的部署更标准过后，我们可以做到这十台机器先不动，两台发了后再加进来再打掉两台这样的过程。

其实现在我们也在用 Docker ，Docker 更方便一点，但是很多业务我们现在还没有解决掉，必须跑在虚拟机上，所以说这系统还是解决了一些问题。

其实国美这边 Docker 也在用，我们的友商京东这一方面比较厉害，70%多的业务都是 Docker 上，我们也在努力推这东西，今年会有50%左右的业务跑在Docker 上。我觉得灰度发布是对 Docker 一个补充吧，也是一个比较传统的减少业务影响的一种发布方式。

END