今天我跟大家交流的是实实在在的怎么样做运维自动化这个主题。

可能之前大家也听过我介绍织云平台怎么做，我最近想一个事情，像腾讯这种体量（QQ月活量是8.3亿，8.3亿的DAU）及海量运维压力下，构建出的自动化运维平台如果真的放在一些中小企业，是没有太多的用武之地。

那么怎么办？

我一直在想怎么样能够让大家没白来这次的分享，所以我特意把我之前对整个运维自动化分享的内容重新提炼总结，通俗点的说就是更接地气，我节选了我们这么多年做运维自动化里面最重要的一些功能模块。

所以今天不会给大家介绍一个很庞大的系统，我会专门去讲自动化里最核心的环节（CMDB分层、技术架构及后续落地办法等等），说不定大家做了这些核心环节，就能提升到很高效的水平。

一、运维自动化的能与不能

今天的分享主要有三部分，前两部分会重点跟大家讲一下，我们做运维自动化之前，应该具备什么样的理念。无论是运维还是开发这两个角色，其实都需要去遵循这样一些俗称的标准化，我们的规范是什么？基于这样的一些规范，我们怎么把我们的自动化落地。

自动化不是万能的，并不是所有的场景都适用。运维自动化也是一样，在腾讯体量很小的时候，我们就一直琢磨着要怎么样高效运维。

因为腾讯的社交产品是树状结构，小的一些应用特别多。只有核心的几个像QQ相册、QQ空间、QQ音乐体量特别大，其他都是很碎片的小应用，如果这些小应用杂乱无章的生长，怎么规范化它？在它发展的时候我们的运维效率又能跟上。

去年6月份，腾讯整个集团的物理机刚刚突破50万，我们运维团队的人增幅远没有服务器增长的快。

我们先来看一下自动化想解决什么样的问题？

上面这些挺有意思的话节选于我们团队内部：比如文档即过期，我们做运维的，老板整天希望我们写一些所谓的运维文档，这个文档写出来的时候其实就意味着它已经过期了。

还有一些资深同事离职，经验也就消失了，这些都希望在自动化里解决。还有逻辑的解耦、微服务，写死IP，或者有必要的切换等，这些肯定是在做运维自动化的时候不希望去触的雷区，还包括包括人为同时的失误、架构的失控等等。

我们怎么样提出标准化规范？让我们的研发团队、运维团队更高效合作，避免出现误区？

做自动化不是为了炫酷，不能为了自动化而自动化，20%的工作消耗了我们80%的精力，我们只要集中精力把那20%的工作做好基本上就可以达到很好的状态了，就可以释放精力去做大数据、做智能化运维，而不是说什么场景都要追求到完完全全的极致。

我们团队内部，大家都会经常说一句话，任何事情做到80分，我们投入半年就够了。但是要把另外20分做完，可能要投入的时间远大于那80分，所以这时候，我也是希望大家在回去规划自己的运维自动化场景的时候，能够着重思考这一点，哪个优先去做。

我们给我们的运维自动化下了一个定义，做任何事情之前，首先清楚我们的目标：在大规模运维场景下，将重复度高的工作，基于监控数据智能决策触发，实现无人参与的自动操作的运维能力，称之为运维自动化。

这里很重要的是无人参与，目前我们的平台是可以做到无人职守扩和缩，今天就跟大家介绍怎么实现的。

再次回到业务场景，在腾讯的社交业务场景下，海量、敏捷、复杂高可用上面都有一些具体的描述，这也是在中国这么大的用户群体下所有社交产品的一个普遍表现形态。

二、DEV与OPS：求同存异

在这样一个海量的业务压力下，我们怎么样跟我们的开发人员、运维人员去共同定制我们能够落地实现的标准化运维方案？

在2008年、2009年的时候，我们当时提D/O分离，但我一直觉得D/O分离有点自己坑自己的味道，你开发好程序给我你就不用干了，我含着泪都要把这个干好。

一个架构很差的程序，我们没有办法把它维护得很高效。

在腾讯社交这个产品线，我们现在功能模块有5000多个，底下对应的微服务得上好几万个，这种情况是没有办法维护一些架构很差程序代码的。

在当时2010年的时候，DevOps的概念还没有提出，我们已经意识到这个问题，所以当时就已经开发了织云这个平台，当它真正的跟DevOps这个理念对齐的时候是不谋而合的。

只有合作才能走得更快，才能在激烈的互联网红海竞争下取得胜利，怎么去做？

我们把开发和运维有可能打交道的地方分成四大块：首先是架构。

运维很关注架构，不然没办法评估它的质量好坏跟架构有没有直接的关系。运维希望开发遵守我们的规范。

之前我跟一些传统行业的同行也有过交流，他们写了很多规范开发不能做，这些都是流于形式，没有办法实实在在的去要求。

为此，我们带着这样的问题，一起来看一下腾讯是怎么实践的。

我们推崇的统一架构、运维规范，怎么作用到开发人员的身上？然后基于这样的统一的规范，如何能够去打造运维的工具系统，让它实现自动化？

基本上所有的互联网业务架构，我们都是可以用上图来简单概括，分为客户端，用户用的终端、PC，中间是运营商，然后三层架构：接入层、逻辑层、数据层。

腾讯整个社交，大概是分成这个样子，针对同样的架构，我们就开始提出管理理念：框架化、组件化、无状态、分布式。

我们的框架化是怎么落地的？

在腾讯社交这边，我们的业务开发整个技术栈，基本上都是用C为我们的主要开发语言，不是用Java，所以说没有办法基于Java无痛注入的方案做APM，我们必须对开发的技术习惯设计更适合我们的框架。

为此，我们针对Socket通信把CS架构的服务端，按照公共的功能专门用来通讯、收发包，些能力变成一个框架。业务开发只需要专注写它的业务逻辑，实现我们的框架。

在腾讯基本上我们有支持同步的开发框架、支持异步的开发框架，还有Web服务的一些应用，都是有通用的框架来支持的。

再讲就是组件化，这里也有一个实例。假设我们现在要上一个网站，必须要有一个Web Server，不同的开发团队会有不同的选择，有人说Apache性能好，有人说NGINX比Apache强，有人说我用IIS，有人说那三个都是垃圾，我自己写的是最好的。

很不幸，这个事情如果在2009年之前在腾讯确实是这样子的，百花齐放，这就导致我们没有办法维护。对运维来说，100个不同的Web Server我就要选择100次。

为什么我们不能要求一致？我们站在组件化的高度及要求下，同一种应用场景只能选一个，这次才能针对这种组件化去做到极致。

说完我们的一些框架化、组件化的举例，通过提出了这样一些要求，我们运维团队让我们每一个业务开发，开发出来的架构都基本上长成上面的样子了。还有一些组件TGW、L5这些东西没有介绍到，大家可以在搜索引擎上查到之前的分享。

今天我特别希望把这个理念跟大家完整阐述一遍。当我们的业务架构的层级都长成这个样子的时候，我们无论是对它做自动化运维也好，做监控也好，都很方便。

刚刚上一个老师提到一点我觉得很有启发，一款应用我们应该怎么样去度量它？指标是怎么样子的？

腾讯内部是直播年。腾讯自己也在做直播，我们社交的直播光是APP估计两个数手不完，各种开发团队都在做直播，不同的直播怎么度量？

所以这时候，运维团队就占了很重要的决定性的作用。我出来说直播的质量、体系就应该这么看，我就给你定好了这种指标。

我觉得有很多事情，不是说技术好或不好，而是看谁来做更合适。这时候运维作为一个公共的支撑的团队，它更有这种权利或者说它更应该去规范这样的东西，让我们对同质的业务场景可度量。

前面两个部分，把我们的理念讲完了。我们要怎么样去落地？细节是什么样子的？下面有一个全局的图。

在我们社交运维团队，我们主要的运维产品有四大块：一个是织云，主要负责运维自动化方向，还有一个天网，还有我们的报表体系，专门用来做我们可度量的。最后还有一个手机运维MSNG，这里面包含了很多子的系统，今天主要是讲织云里面的一小部分。

三、运维自动化的技术细节

今天着重介绍织云，并且是织云最核心的功能点。有了标准化以后要做很多事情，才可以很轻松的实现运维工作的自动化。

光是在运维自动化里面，大家都说标准化、运维规范，那究竟是什么？今天特别想跟大家一起打开这个黑匣子，看一下腾讯运维的标准化是怎样的？

我们把业务架构又切分成不同的层，其实就是刚刚那个图的另外一种表现形式。五层，不同的层级，我们要做的标准化针对的对象不同的。

就像我们的设备层什么是标准？统一的机型、计算型的、内存型的、SSD，你是用关系型数据库，要用什么机型，要用大硬盘的，你是做Web Server的，内存标配一个就可以了。

特别是在虚拟化的今天，如果任由一个业务随意去选择它的机型，对于我们来说就是多了一种对象。在腾讯这么大的体量下我们没有办法容忍随随便便给我多增加一个运维对象。

所以我标红了几个字，就是要减少运维对象。像其他的业务层，你是IM型的应用，架构分布必须要三地、三活，QQ调度方案跟Q Zone的调度方案必须是一样的。所以我们做的一切的一切都是要减少运维对象。

减少完运维对象怎么去执行？在开发前，把整个产品的生命周期分成这么几块，在开发前、上线前、上线中、运营中，不同阶段，考虑的点不一样。

开发前，知道业务形态长成什么样，可能用到什么样的组件、什么样的框架，这个时候基本上杜绝了写死IP的念头，或者对本地存储特别敏感的情况。

其实我只是写出来，在真正运维工作中并没有说每次上线一个产品我们都去评审，时间也耗不起。

当我们形成了这样一个开发和运维合作的文化之后，开发团队自己就会遵守了，并且在不同的阶段，我们提出了不同的要求。每个要求都会对应了我们运维的一个工具系统，去支撑它，就是说我们的标准化可以落地了。

再来看基于我们互联网业务的架构层分层的特征，针对不同层次的对象去建设对应维护对象的系统，这些系统所产生的数据都把它结构化落地到我们的配置管理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流程系统，还有传输通道，如果大家所在企业的规模或者你所管理的设备量不大的话，效率已经提到很高了。

大家可以想一下，我要操作的对象都存在配置管理里面，配置好一个流程做执行，就是先安装包，再去启动相关的包，再把测试程序调用一下，把灰度接入两台在域名上，然后去验证一下没有问题，然后再接着全量上线。我们点几下按纽就解决了，不需要完全无人职守。

但是在腾讯这个体量还是不够，所以我们做了无人职守，做了无人职守还要做到这七点：你的设备怎么管理？究竟怎么样决策？应该用哪个设备？

还有我们的智能决策，依赖什么样的数据决策，应该起什么样的流程？

假设我们有一个Web层有10台机器同时挂了8台，当只挂了一台时我们可以不马上发告警，因为有一个决策系统在。

我知道Web层的机器无状态，我直接重启它把它踢下线，但是又挂、又挂，挂了5台时候决策系统就可以做一个决策，它的IP数量超过30%的不可用的时候，不能够再不发通知了，这个时候就应该发通知给运维人员，让人来干预这个事情，这是我们的智能决策。

还有我们的自动测试、灰度放量。

灰度放量基于怎样的策略来灰度放量是灰度管理系统考虑的。还有变更体检，有没有基础指标，CPU，你新上线的设备是不是跟现在设备CPU曲线吻合，或者说有没有一些业务监控能够告诉我，这就是变更体检要做的一些事情。

还有日志通知，自动化系统跟监控系统联动的时候，就像做一个变更，那边有业务告警，这两个数据一关联起来，可能业务告警就不发了，那个取决于监控系统那边告警策略建设。

3、实战案例

做完了这七点，可以实现什么状态？上面是腾讯QQ会员的一个真实案例，大家如果有用腾讯的产品肯定都收过腾讯给你推的红点。

有些人处女座一定要点那个红点，马上请求量就来了。这一点对于运维来说就是一个恶梦，如果没有提前准备容量，业务请求量就会飙高。

但是在无人守职的运维能力下，你也什么都不用做。你会收到一条短信提醒，无论是聊天工具的弹框，还是手机短信提醒你，现在正在有一个自动扩容在执行，它自己就跑完了整个流程。

因为我们把最核心的那三个部分，还有辅助它能实现最后一步七步做完，在自动化这一块是可以说走在到了人生的巅峰。

最后想跟大家一起小结一下：今天分享的主题没有把它铺得特别大，大家回去可以看一下，我们有什么样管理对象可以做成标准化，要怎么样把它框起来，框起来之后针对这种标准的场景怎么样做到最高效的运维。（梁定安（大梁）原创）

今天我跟大家交流的是实实在在的怎么样做运维自动化这个主题。

可能之前大家也听过我介绍织云平台怎么做，我最近想一个事情，像腾讯这种体量（QQ月活量是8.3亿，8.3亿的DAU）及海量运维压力下，构建出的自动化运维平台如果真的放在一些中小企业，是没有太多的用武之地。

那么怎么办？

我一直在想怎么样能够让大家没白来这次的分享，所以我特意把我之前对整个运维自动化分享的内容重新提炼总结，通俗点的说就是更接地气，我节选了我们这么多年做运维自动化里面最重要的一些功能模块。

所以今天不会给大家介绍一个很庞大的系统，我会专门去讲自动化里最核心的环节（CMDB分层、技术架构及后续落地办法等等），说不定大家做了这些核心环节，就能提升到很高效的水平。

一、运维自动化的能与不能

今天的分享主要有三部分，前两部分会重点跟大家讲一下，我们做运维自动化之前，应该具备什么样的理念。无论是运维还是开发这两个角色，其实都需要去遵循这样一些俗称的标准化，我们的规范是什么？基于这样的一些规范，我们怎么把我们的自动化落地。

自动化不是万能的，并不是所有的场景都适用。运维自动化也是一样，在腾讯体量很小的时候，我们就一直琢磨着要怎么样高效运维。

因为腾讯的社交产品是树状结构，小的一些应用特别多。只有核心的几个像QQ相册、QQ空间、QQ音乐体量特别大，其他都是很碎片的小应用，如果这些小应用杂乱无章的生长，怎么规范化它？在它发展的时候我们的运维效率又能跟上。

去年6月份，腾讯整个集团的物理机刚刚突破50万，我们运维团队的人增幅远没有服务器增长的快。

我们先来看一下自动化想解决什么样的问题？

上面这些挺有意思的话节选于我们团队内部：比如文档即过期，我们做运维的，老板整天希望我们写一些所谓的运维文档，这个文档写出来的时候其实就意味着它已经过期了。

还有一些资深同事离职，经验也就消失了，这些都希望在自动化里解决。还有逻辑的解耦、微服务，写死IP，或者有必要的切换等，这些肯定是在做运维自动化的时候不希望去触的雷区，还包括包括人为同时的失误、架构的失控等等。

我们怎么样提出标准化规范？让我们的研发团队、运维团队更高效合作，避免出现误区？

做自动化不是为了炫酷，不能为了自动化而自动化，20%的工作消耗了我们80%的精力，我们只要集中精力把那20%的工作做好基本上就可以达到很好的状态了，就可以释放精力去做大数据、做智能化运维，而不是说什么场景都要追求到完完全全的极致。

我们团队内部，大家都会经常说一句话，任何事情做到80分，我们投入半年就够了。但是要把另外20分做完，可能要投入的时间远大于那80分，所以这时候，我也是希望大家在回去规划自己的运维自动化场景的时候，能够着重思考这一点，哪个优先去做。

我们给我们的运维自动化下了一个定义，做任何事情之前，首先清楚我们的目标：在大规模运维场景下，将重复度高的工作，基于监控数据智能决策触发，实现无人参与的自动操作的运维能力，称之为运维自动化。

这里很重要的是无人参与，目前我们的平台是可以做到无人职守扩和缩，今天就跟大家介绍怎么实现的。

再次回到业务场景，在腾讯的社交业务场景下，海量、敏捷、复杂高可用上面都有一些具体的描述，这也是在中国这么大的用户群体下所有社交产品的一个普遍表现形态。

二、DEV与OPS：求同存异

在这样一个海量的业务压力下，我们怎么样跟我们的开发人员、运维人员去共同定制我们能够落地实现的标准化运维方案？

在2008年、2009年的时候，我们当时提D/O分离，但我一直觉得D/O分离有点自己坑自己的味道，你开发好程序给我你就不用干了，我含着泪都要把这个干好。

一个架构很差的程序，我们没有办法把它维护得很高效。

在腾讯社交这个产品线，我们现在功能模块有5000多个，底下对应的微服务得上好几万个，这种情况是没有办法维护一些架构很差程序代码的。

在当时2010年的时候，DevOps的概念还没有提出，我们已经意识到这个问题，所以当时就已经开发了织云这个平台，当它真正的跟DevOps这个理念对齐的时候是不谋而合的。

只有合作才能走得更快，才能在激烈的互联网红海竞争下取得胜利，怎么去做？

我们把开发和运维有可能打交道的地方分成四大块：首先是架构。

运维很关注架构，不然没办法评估它的质量好坏跟架构有没有直接的关系。运维希望开发遵守我们的规范。

之前我跟一些传统行业的同行也有过交流，他们写了很多规范开发不能做，这些都是流于形式，没有办法实实在在的去要求。

为此，我们带着这样的问题，一起来看一下腾讯是怎么实践的。

我们推崇的统一架构、运维规范，怎么作用到开发人员的身上？然后基于这样的统一的规范，如何能够去打造运维的工具系统，让它实现自动化？

基本上所有的互联网业务架构，我们都是可以用上图来简单概括，分为客户端，用户用的终端、PC，中间是运营商，然后三层架构：接入层、逻辑层、数据层。

腾讯整个社交，大概是分成这个样子，针对同样的架构，我们就开始提出管理理念：框架化、组件化、无状态、分布式。

我们的框架化是怎么落地的？

在腾讯社交这边，我们的业务开发整个技术栈，基本上都是用C为我们的主要开发语言，不是用Java，所以说没有办法基于Java无痛注入的方案做APM，我们必须对开发的技术习惯设计更适合我们的框架。

为此，我们针对Socket通信把CS架构的服务端，按照公共的功能专门用来通讯、收发包，些能力变成一个框架。业务开发只需要专注写它的业务逻辑，实现我们的框架。

在腾讯基本上我们有支持同步的开发框架、支持异步的开发框架，还有Web服务的一些应用，都是有通用的框架来支持的。

再讲就是组件化，这里也有一个实例。假设我们现在要上一个网站，必须要有一个Web Server，不同的开发团队会有不同的选择，有人说Apache性能好，有人说NGINX比Apache强，有人说我用IIS，有人说那三个都是垃圾，我自己写的是最好的。

很不幸，这个事情如果在2009年之前在腾讯确实是这样子的，百花齐放，这就导致我们没有办法维护。对运维来说，100个不同的Web Server我就要选择100次。

为什么我们不能要求一致？我们站在组件化的高度及要求下，同一种应用场景只能选一个，这次才能针对这种组件化去做到极致。

说完我们的一些框架化、组件化的举例，通过提出了这样一些要求，我们运维团队让我们每一个业务开发，开发出来的架构都基本上长成上面的样子了。还有一些组件TGW、L5这些东西没有介绍到，大家可以在搜索引擎上查到之前的分享。

今天我特别希望把这个理念跟大家完整阐述一遍。当我们的业务架构的层级都长成这个样子的时候，我们无论是对它做自动化运维也好，做监控也好，都很方便。

刚刚上一个老师提到一点我觉得很有启发，一款应用我们应该怎么样去度量它？指标是怎么样子的？

腾讯内部是直播年。腾讯自己也在做直播，我们社交的直播光是APP估计两个数手不完，各种开发团队都在做直播，不同的直播怎么度量？

所以这时候，运维团队就占了很重要的决定性的作用。我出来说直播的质量、体系就应该这么看，我就给你定好了这种指标。

我觉得有很多事情，不是说技术好或不好，而是看谁来做更合适。这时候运维作为一个公共的支撑的团队，它更有这种权利或者说它更应该去规范这样的东西，让我们对同质的业务场景可度量。

前面两个部分，把我们的理念讲完了。我们要怎么样去落地？细节是什么样子的？下面有一个全局的图。

在我们社交运维团队，我们主要的运维产品有四大块：一个是织云，主要负责运维自动化方向，还有一个天网，还有我们的报表体系，专门用来做我们可度量的。最后还有一个手机运维MSNG，这里面包含了很多子的系统，今天主要是讲织云里面的一小部分。

三、运维自动化的技术细节

今天着重介绍织云，并且是织云最核心的功能点。有了标准化以后要做很多事情，才可以很轻松的实现运维工作的自动化。

光是在运维自动化里面，大家都说标准化、运维规范，那究竟是什么？今天特别想跟大家一起打开这个黑匣子，看一下腾讯运维的标准化是怎样的？

我们把业务架构又切分成不同的层，其实就是刚刚那个图的另外一种表现形式。五层，不同的层级，我们要做的标准化针对的对象不同的。

就像我们的设备层什么是标准？统一的机型、计算型的、内存型的、SSD，你是用关系型数据库，要用什么机型，要用大硬盘的，你是做Web Server的，内存标配一个就可以了。

特别是在虚拟化的今天，如果任由一个业务随意去选择它的机型，对于我们来说就是多了一种对象。在腾讯这么大的体量下我们没有办法容忍随随便便给我多增加一个运维对象。

所以我标红了几个字，就是要减少运维对象。像其他的业务层，你是IM型的应用，架构分布必须要三地、三活，QQ调度方案跟Q Zone的调度方案必须是一样的。所以我们做的一切的一切都是要减少运维对象。

减少完运维对象怎么去执行？在开发前，把整个产品的生命周期分成这么几块，在开发前、上线前、上线中、运营中，不同阶段，考虑的点不一样。

开发前，知道业务形态长成什么样，可能用到什么样的组件、什么样的框架，这个时候基本上杜绝了写死IP的念头，或者对本地存储特别敏感的情况。

其实我只是写出来，在真正运维工作中并没有说每次上线一个产品我们都去评审，时间也耗不起。

当我们形成了这样一个开发和运维合作的文化之后，开发团队自己就会遵守了，并且在不同的阶段，我们提出了不同的要求。每个要求都会对应了我们运维的一个工具系统，去支撑它，就是说我们的标准化可以落地了。

再来看基于我们互联网业务的架构层分层的特征，针对不同层次的对象去建设对应维护对象的系统，这些系统所产生的数据都把它结构化落地到我们的配置管理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流程系统，还有传输通道，如果大家所在企业的规模或者你所管理的设备量不大的话，效率已经提到很高了。

大家可以想一下，我要操作的对象都存在配置管理里面，配置好一个流程做执行，就是先安装包，再去启动相关的包，再把测试程序调用一下，把灰度接入两台在域名上，然后去验证一下没有问题，然后再接着全量上线。我们点几下按纽就解决了，不需要完全无人职守。

但是在腾讯这个体量还是不够，所以我们做了无人职守，做了无人职守还要做到这七点：你的设备怎么管理？究竟怎么样决策？应该用哪个设备？

还有我们的智能决策，依赖什么样的数据决策，应该起什么样的流程？

假设我们有一个Web层有10台机器同时挂了8台，当只挂了一台时我们可以不马上发告警，因为有一个决策系统在。

我知道Web层的机器无状态，我直接重启它把它踢下线，但是又挂、又挂，挂了5台时候决策系统就可以做一个决策，它的IP数量超过30%的不可用的时候，不能够再不发通知了，这个时候就应该发通知给运维人员，让人来干预这个事情，这是我们的智能决策。

还有我们的自动测试、灰度放量。

灰度放量基于怎样的策略来灰度放量是灰度管理系统考虑的。还有变更体检，有没有基础指标，CPU，你新上线的设备是不是跟现在设备CPU曲线吻合，或者说有没有一些业务监控能够告诉我，这就是变更体检要做的一些事情。

还有日志通知，自动化系统跟监控系统联动的时候，就像做一个变更，那边有业务告警，这两个数据一关联起来，可能业务告警就不发了，那个取决于监控系统那边告警策略建设。

3、实战案例

做完了这七点，可以实现什么状态？上面是腾讯QQ会员的一个真实案例，大家如果有用腾讯的产品肯定都收过腾讯给你推的红点。

有些人处女座一定要点那个红点，马上请求量就来了。这一点对于运维来说就是一个恶梦，如果没有提前准备容量，业务请求量就会飙高。

但是在无人守职的运维能力下，你也什么都不用做。你会收到一条短信提醒，无论是聊天工具的弹框，还是手机短信提醒你，现在正在有一个自动扩容在执行，它自己就跑完了整个流程。

因为我们把最核心的那三个部分，还有辅助它能实现最后一步七步做完，在自动化这一块是可以说走在到了人生的巅峰。

最后想跟大家一起小结一下：今天分享的主题没有把它铺得特别大，大家回去可以看一下，我们有什么样管理对象可以做成标准化，要怎么样把它框起来，框起来之后针对这种标准的场景怎么样做到最高效的运维。（梁定安（大梁）原创）