腾讯SNG梁定安：显微镜下的运维自动化(3)

再来看基于我们互联网业务的架构层分层的特征,针对不同层次的对象去建设对应维护对象的系统,这些系统所产生的数据都把它结构化落地到我们的配置管理CMDB里面,这个CMDB就在整个运维自动化的过程中扮演了一个很核心的地位.

CMDB层是什么东西?

我们开发和运维先天性就有一些思考模式的不同.我们在CMDB中提出了一个概念,就是模块概念.为什么要有模块这个概念?可能开发人员看到他自己写的一套代码,这套代码对他来说部署在一个地方和部署在三个地方都是一套代码.

但是对于腾讯来说,我们所有核心服务都是三地三中心,对于用户来说,天津的用户量跟深圳的用户量不一样,北方的用户跟南方的用户量不同,容量不同,准备的设备数量就不同,提前规划的机房也不一样.

这时候我们就提出了一个概念,就是模块.这个模块必须要按照运维的命名规则去定义它,存我们固定资产的信息,硬件配置、软件配置、运营设置,还有资源配置、流程配置、测试用例等.

存这些东西有什么用?

如果CMDB一下子就能看到我们整个QQ的某一个功能,分布在天津、上海、深圳的容量分布图,或者说记录了这个模块的测试用例.那么,我们在做自动化的时候,我把它部署完就可以自动调它的测试用例,自动测试然后上线.实现这个目的,都是为了自动化做铺垫.

1、织云的运维思想

前面我们一直讲思想讲理念,前面两个部分介绍了标准化,以及标准化怎么变成我们的配置化,变成配置化之后最后一步就是实现自动化.

实现自动化的过程,技术上看似很简单,无非就是把一堆结构化的数据通过配置,通过一些自动化的手段或者写批量的脚本,全部传上机器把它还原就可以了.

现在业界比较流行Docker,Docker的口号是BUILD、SHIP、RUN(构建、传输、传上生产环境执行起来),但是事实上有没有这么理想化?

上图是我们在腾讯每一个发布要做的事情.事实上我框起来的这些内容Docker并没有帮我们解决的,编入业务权限怎么申请,这个可能很有腾讯特色.

大家都知道,腾讯很多业务都是生长在QQ这样一个关系链体系下的,并不是所有的业务都有权限去拉QQ关系链的.访问QQ关系链必须要经过一个授权,这个是镜像部署解决不了的问题.但是我们织云平台必须要解决这样的事情.

此外还有一些Docker解决不了测试的问题,比如有人说我直接在测试环境测好打成一个镜像,这可以.

但是,我们QQ有些大集群上千台机器,每发一次都重启一次吗?这也不现实.测试怎么解决?灰度怎么解决?最后怎么上线?Docker也没有解决上线的问题.我们网站型的应用,最后还是要加到域外解析,加到DNS.怎么办?

为了解决它,所以我们内部整理了一个最适合腾讯社交的流程,如下图.

我们把整个自动部署的过程抽象成六大步,但其实分解开来是有23步,我们为了兼容带着业务特色的部署发布,带着我们运维要求的一些部署发布,还必须要有一个测试的环节,必须要有灰度的环节,最终完成上线.

我们把我们的自动化的流程抽象成23步放在我们的资源平台,但是资源平台究竟起到一个什么样的作用?或者说它的特别之处在哪里?我们是用了七大点把它总结出来,如下图.

首先它是要能传承的,所有的运维经验都是一种配置项资源存在CMBD里面,并且需要提出了很多标准,这些标准落地在我们管理不同对象的运维系统里面,最终是协作的.

这么多个特征组成整个织云的技术架构,我今天都不讲了,因为我觉得不需要这么多复杂的东西.

2、运维自动化的核心组件

接下来想跟大家深入一点的去交流自动化运维最核心的CMDB、流程系统,把我们的一个一个的工具通过我们的传输通道能串起来.

只要你实现了这些,你的运维效率就提高很多,不需要完全自动化,不需要无人职守.为什么要无人职守?本来就500台机器,10个人,每个人50台机器是很容易.

上图是我们最重要的CMDB的技术架构,归根结底就是一个关系型的数据库.

我们要存哪些配置项来设计表的结构,并且可以提供接口化,让我们的工具系统可以调度.

如果要做部署包的系统,首先要知道操作的对象是谁?这个对象的模块名是谁?我刚才提到很重要一点,我们统一了开发和运维的语言,操作这个模块每次部署需要装哪些包?发哪些配置?近期都存在我们的CMDB数据库里面,拉出来调我们的流程系统,调我们的传输工具,把这些资源推到我们的生产环境.

推完之后,要启动流程系统、启动步骤、测试步骤、灰度步骤、上线步骤,一步一步串起来.这就是为什么说自动化运维很重要的一个核心就取决于我们有什么样的一些料可以做这道菜.

接下来是流程系统,现在业界没有一些特别适用的开源方案,但是我们还是在做流程系统,今年又在做一版新的,希望做得更强壮.

假设我们写了100个脚本,只是一个大的脚本,把这100个脚本串起来就是我们流程系统.

它可以通过一定的数据触发执行,什么时候这个流程跑什么样的工具都是有一些决策的,或者说当某个工具失败了,究竟是重试还是跑分支流程,还是说终止告警,这就是我们的流程系统.

我们之前提供了一些函数头,里面的工具写好自己的逻辑,能够通过一些公共输入输出的函数方法,让这个工具本身处理完的输入输出能够被流程理解,能够传给下一个工具.

主要核心就是做了这样一个事情,架构做成什么样子不重要,所以今天我画的是原理,并不是架构.如果大家想看流程系统的架构,可以搜一下我以前分享过的运维自动化的PPT,里面有那个架构.

最后是传输通道,怎么样让流程串起来?

最终要操作生产环境的时候要怎么样做?在腾讯我们用一个C/S的架构来实现我们叫做命令通道的东西,可以传文件,可以执行命令.

大家写一个C/S,自己配一个协议,传一堆文件,它能解析指令、执行,找到对应的文件执行完,这个就是我们的传输通道最基础的一些功能.

但是传输功能是不是仅仅这么简单就足够了?

基于安全性考虑,我们还需要去关注我们的源IP权限,防止被黑客攻击变成肉机之后,随意发起批量操作,有损大厂名誉.

其次是用户身份的健全,QQ的运维不可能操作QQ音乐的设备,当然如果兼岗是可以的.我们会对执行的命令做一些解析,防止高危操作,防止某个人失恋了要删数据库走人.

还有约束目标的IP,对我们生产环境管理的理念是息息相关的,少数的像系统运维,因为他负责整个10万台机器,一次1万台也要分10次处理,而不是说一个命令把10万台搞定,因为人总会犯错的.

做完这些CMDB流程系统,还有传输通道,如果大家所在企业的规模或者你所管理的设备量不大的话,效率已经提到很高了.

（编辑：ASP站长网）