行业动态

本文来自腾讯社交多媒体业务负责人@梁陵水（大梁）在听云的同名主旨演讲。 工作变成手工。

今天和大家分享的话题是如何做手工运维。

之前大家可能听我介绍过智云平台是怎么工作的。 最近在想一件事，比如腾讯的体量（QQ月活8.3亿，DAU 8.3亿）和海量运维的压力。 自动化运维平台如果真的放在一些中小企业，用处不大。

那怎么办呢？

还在琢磨怎么才能不让大家白白分享这一次，所以特意把之前分享的手动运维上的内容重新提炼总结了一下。 多年来，上述一些最重要的功能模块一直由人工操作和维护。

所以明天我就不给大家介绍一个非常庞大的系统了。 我会专门讲一下手工化中最核心的环节（CMDB分层、技术架构、后续实现方式等），说不定那些核心环节你都做了，你的效率就会提升到一个很高的水平。

1. 人工运维的能与不能

明天的分享主要有三个部分。 前两部分会着重告诉大家在做手工运维之前我们应该有什么样的概念。 不管是运维还是开发这两个角色，虽然都需要遵守这样的规范，但是我们的规范是什么？ 基于这样的规范，我们如何实现我们的手动实现。

手动化不是万能的，并不是所有场景都适用。 人工运维也是如此。 腾讯小的时候，我们还在思考如何高效的运维。

由于腾讯的社交产品是树状结构，因此有很多小应用。 只有QQ相册、Q空间、QQ音乐这些核心的非常大，其他都是很零散的小应用。 如果这样的小应用无序增长，如何规范？ 当它发展起来的时候，我们的运维效率才能跟上。

今年6月，腾讯整个集团的化机数量刚刚突破50万台。 我们运维团队的增长速度远不及服务器。

我们先来看看人工化要解决什么样的问题？

里面有意思的话摘自我们团队内部：比如文档过期了，我们做运维，老大要我们整天写一些所谓的运维文档。 这份文件写出来的时候，似乎意味着它已经过期了。

也有一些资深朋友辞职了，经验就没了。 都是希望人工解决的。 还有逻辑前馈，微服务，硬编码IP，或者必要的切换等等，这绝对是你在做人工运维的时候绝对不想触碰的雷区，同时包括人为错误。 、失控结构等。

我们如何提出标准化规范？ 让我们的研发团队和运维团队更高效的合作，防止误会？

规范化不是为了眼花缭乱，也不能为了规范化而规范化。 20%的工作消耗了我们80%的精力。 只要集中精力把那20%的工作做好，基本就能达到好的状态。 你可以释放你的精力去做大数据和智能运维，而不是说所有的场景都要追求到极致。

在我们团队里面，大家经常会说一句话，我们做任何事情做到80分，半年就够我们投入了。 而要完成另外的20分钟，可能比80分钟的时间要少很多，所以这个时候，也希望大家回家规划自己的手工运维场景时，能够注意这一点。 这是当务之急。

我们已经定义了我们的手动操作和维护。 做任何事情之前，首先要明确自己的目标：在大规模运维场景中，基于监控数据的智能决策，触发高重复性任务，实现无人参与，人工操作的运维能力称为人工操作和维护。

这里重要的是没有人参与。 目前，我们的平台可以在无人值守的情况下进行扩容和缩容。 明天，我将介绍如何实现它。

再回到业务场景，在腾讯的社交业务场景中，在海量、敏捷、复杂、高可用上有一些具体的描述，这也是国内所有拥有如此庞大用户群体的社交产品的共同体现。

2. DEV与OPS：求同存异

在如此巨大的业务压力下，我们如何与我们的开发人员和运维人员共同订制一个我们可以实施的标准化运维解决方案？

2008年和2009年的时候，我们当时就提到了D/O分离，但是我还是觉得D/O分离有点弄巧成拙。 如果你把程序开发出来交给我，你就不用做了。 我眼里含着泪水。 完成这件事。

结构不良的程序无法有效地维护它。

在腾讯的社交产品线，我们现在有超过5000个功能模块，对应的微服务有上万个。 在这些情况下，没有办法维护一些结构不良的程序代码。

那个时候2010年，概念的概念还没有提出来，我们就已经意识到了这个问题，所以我们当时就已经开发了智云平台，真正对接这个概念的时候，恰逢用它。

只有合作，才能在激烈的互联网红海竞争中走得更快，才能胜出。 怎么做？

我们把开发和运维可能涉及到的地方分为四大块：第一块是架构。

运维很关心架构，否则没办法评估它的好坏是不是和架构有直接关系。 Ops 希望开发违背我们的规范。

之前也和一些传统行业的同事交流过。 他们写了很多无法完成的规范开发。

因此，带着这个问题，我们来看看腾讯是如何实践的。

我们提倡的统一架构和运维规范，对开发者的面子有什么影响？ 那么基于这样一个统一的规范，我们如何构建一个运维工具体系，使其成为手册呢？

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

腾讯整个社交网络大致是这样划分的。 同样的结构，我们开始提出管理理念：框架化、组件化、无状态、分布式。

我们的框架是如何实现的？

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

所以在通信上，我们使用CS架构的服务器，根据公共功能进行通信、收集和分包，将这些能力做成一个框架。 业务开发只需要专注于编写其业务逻辑和实现我们的框架即可。

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

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

不幸的是，如果这件事在2009年之前在腾讯确实是这样，百花齐放，让我们无法维护。 为了运维，我要选择100个不同的网站100次。

为什么我们不能要求一致？ 我们站在组件化的高度和要求上，只能选择一种应用场景。 这一次，我们可以将这些组件化做到极致。

说完我们的一些框架和组件化的例子服务器运维技术，通过提出这样的需求，我们的运维团队让我们的每一个业务开发，开发出来的框架基本上就是里面的样子。 还有一些组件如TGW和L5没有介绍。 可以在搜索引擎上找到之前的分享。

明天我非常希望能和大家充分讨论这个概念。 当我们的业务架构层级长成这样的时候，无论是手动运维还是监控，都非常方便。

刚才一位老师提到了一件让我觉得很有启发的事。 我们应该如何衡量应用程序？ 指标是什么样子的？

今年是腾讯内部的直播年。 腾讯自己也在做直播。 仅靠我们的社交直播应用程序可能还不够。 各个开发团队都在做直播。 不同的直播如何衡量？

所以这个时候，运维团队就起到了非常重要和决定性的作用。 我下来就是说，直播的质量和系统应该是这样看的，这些指标我都给大家定好了。

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

接下来的两部分完成了我们的理念。 我们要怎么着陆？ 细节是怎样的？ 下面有一张全局图。

在我们的社会运维团队中，我们主要的运维产品有四大部分：一个是智云，主要负责人工运维的方向，还有一个天网，还有我们的报表系统，是专门做用来做我们可以测量的。 最后是手机运维MSNG，里面包含了很多子系统。 明天主要讲智云的一小部分。

3、人工运维技术细节

明天我们重点说说智云，这是智云的核心功能点。 标准化之后，需要做很多事情，这样就可以轻松实现人工运维工作。

说到人工运维，大家都在讲标准化、运维规范。 它们到底是什么？ 明天真想和大家一起打开这个黑匣子，看看腾讯运维的标准化程度如何？

我们把业务架构分成不同的层次，虽然是刚才的图的另一种表达方式。 五层，不同的层次，我们要做的标准化是针对不同的对象。

像我们的设备层有哪些标准？ 统一型号，计算型，内存型，SSD，你用的是关系型数据库，你要用什么型号，你要用大硬盘，你是做web的，标准显存就够了。

尤其是在当今这个虚拟化的世界里，如果让一个企业可以随意选择它的模式，对我们来说将是一个额外的工具。 腾讯这么大的体量，容不得我多掉一个运维对象。

所以我用红色标注了几个字，就是减少运维对象。 和其他业务层一样，你是一个IM类的应用，架构肯定是三地三活分布的。 QQ的调度方案必须和QQ空间一致。 所以我们所做的一切都是为了减少运维对象。

减少运维对象后如何实现？ 在开发之前，整个产品生命周期被分成几个部分。 开发前、上线前、上线中、运营中，在不同的阶段考虑不同的点。

开发前要知道业务形态是什么样的，可能用到什么样的组件，什么样的框架。 这时候硬编码IP的想法或者对本地存储很敏感的情况基本就避免了。

虽然只是记下来了，但是在真正的运维工作中，我并没有说我们每次上线产品都要，时间不够用。

当我们形成了这样一种开发和运维合作的文化之后，开发团队就会跟进，只是在不同的阶段，我们提出不同的要求。 每一个需求也会对应一个我们运维的工具体系来支持它，也就是说我们的标准化是可以落地的。

下面看一下我们互联网业务架构层的分层特点，针对不同层级的对象构建对应维护对象的系统。 该系统形成的数据将在我们的配置管理CMDB上进行结构化和实施。 这个 CMDB 在整个人工运维过程中起到了非常核心的作用。

什么是CMDB层？

我们的开发和运维在思维模式上有着本质上的不同。 我们在CMDB中提出了一个概念，就是模块的概念。 为什么会有模块的概念？ 也许开发者听到了自己写的一组代码。 对他来说，这套代码部署在一处，部署在三处。

但是对于腾讯来说，我们所有的核心服务都是三地三中心。 用户方面，上海的用户数量与北京不同，南方的用户数量和容量也与北方不同。 数量不一样，提前规划的机房也不一样。

这时候，我们提出了一个概念，就是模块。 这个模块必须按照运维的命名规则来定义，存储我们的固定资产、硬件配置、软件配置、运行设置、资源配置、流程配置、测试用例等信息。

存这种东西有什么用？

如果CMDB可以一下子看到我们整个QQ的某个功能，分布在北京、上海、深圳的容量分布图，或者记录下这个模块的测试用例。 这样我们在做手动化的时候，我可以在部署之后手动调整它的测试用例，手动测试完之后上线。 要实现这个目标，无非就是为手工化做铺垫。

1、智云的运维思路

后面还是会讲思路和概念。 接下来两部分介绍了标准化以及如何将标准化做成我们的配置，然后最后一步就是实现手动化。

手动化的过程在技术上似乎很简单。 无非就是配置一堆结构化的数据，用一些手工的手段或者写批处理脚本，全部上传到机器上恢复。

现在业界比较流行，口号是BUILD、SHIP、RUN（构建、传输、上传到生产环境执行），但实际上真的有那么理想吗？

上图是我们在腾讯每次发布的时候做的。 其实我陷害的内容并没有帮助我们解决问题。 怎么申请业务权限，可能是腾讯很有特点的。

大家知道，腾讯的很多业务都是在QQ的关系链系统下发展起来的，并不是所有的业务都有拉QQ关系链的权限。 访问QQ关系链必须经过授权，这是镜像部署无法解决的问题。 而我们智云平台必须要解决这样的事情。

据悉，测试中还有一些问题无法解决。 比如有人说我直接在测试环境下测试，做了个镜像，就可以了。

但是我们QQ有一些大集群，上千台机器。 每次发送都会重启吗？ 这也不现实。 测试结果如何？ 怎么解决灰度问题？ 到底如何上网？ 也没有解决上网的问题。 对于我们网站类的应用，还是需要加入外域解析，加入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次，而不是一条命令。 获得 100,000 个单位，因为人们总是会犯错误。

完成这个CMDB流程体系后，也就有了传输通道。 如果你的公司规模或者你管理的设备量不大，效率上面已经说的非常高了。

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

但是腾讯的体量还是不够，所以我们做了无人值守，要做这七点：你的设备怎么管理？ 如何做决定？ 我应该使用哪种设备？

而我们的智能决策，应该依靠什么样的数据决策，应该启动什么样的流程？

假设我们有一个web层有10台机器，8台机器同时挂了。 当只有一台机器挂了，我们不需要马上报警，因为有决策系统。

我知道web层的机器是无状态的。 我直接重启踢下线，又挂了又挂。 当5台机器都挂了，决策系统才能做出决定。 它的IP号超过30%是不可用的，这时候就不能不发通知了。 这个时候就应该给运维人员发通知，让人介入这件事情。 这是我们的明智决定。

还有我们的人工测试和灰度量。

灰度管理系统根据什么策略来考虑灰度量。 还有变更复检，有没有基础指标，CPU，你新上线的设备是否符合当前设备的CPU曲线，或者有没有业务监控，你可以告诉我，这些是一些东西在变更时需做复检。

还有日志通知。 当手动系统与监控系统联动时，就像是在做一个改变。 那里有商业警报。 一旦这两个数据关联起来，就可以不发出业务告警了。 哪一个取决于监控系统的告警策略？ 建筑。

三、实际案例

完成这七点后，能达到什么境界呢？ 是腾讯QQ会员的真实案例。 如果你用的是腾讯的产品，那你肯定收到过腾讯发给你的红点。

有的处女座一定要点那种红点，量马上就到。 这对运维来说是一场噩梦。 如果不提前规划好容量，业务请求量就会飙升。

但是有了无人值守的运维能力，你什么都不用做。 你会收到邮件提醒，无论是聊天工具弹框还是手机邮件提醒你当前正在执行手动扩容，它自己完成了整个过程。

自从我们完成了三个核心部分，并协助他们完成了最后七个步骤，可以说我们在手工化方面已经达到了人生的巅峰。

最后跟大家总结一下：明天分享的主题不会做的很大服务器运维技术，大家回家看看，我们有什么样的管理对象可以标准化，怎么去框定，以及框架搭建好之后，如何在这些标准场景下实现最高效的运维。

我们的标准化和配置，然后把流程系统和我们需要做的一切都连接到标准的对象上，最终可以实现我们的手动运维。 好了，明天的分享到此结束，谢谢大家。

阐明

本文来自中国应用性能管理行业盛会——2016中国应用性能管理大会（简称2016），由听云等联合主办，8月起在广州新广东皇冠假日酒店隆重召开18 日至 19 日。