前言

在过去三年多时间里，我因为工作的原因负责了一些和机器学习、AI推荐、自然语言处理相关的工作，系统性的学习了这块的知识。之前可能做了多年开发和运维的关系，我非常希望能把这两个东西结合在一起，所以有一些自己的感受和想法，希望把这块跟大家分享一下。

其次，因为 DevOps 在这两年发展非常迅猛火爆，尤其咱们这个社区。但是也看到里面有一些紧张或者是忧虑的成分，这一块也可以讲讲，在AI智能化、自动化的大背景下，我们的同事应该怎么样来发展，也有自己的一点小观点跟大家分享。

运维团队的践行之路“致简”

织云（Cloud Operations Console）是腾讯的企业级运维管理平台，为了更好的运维管理我们设计了这个系统，这个系统里面非常重要的一个设计理念点：“简”，化繁为简。做产品要简单，解决这么复杂的用户环境、场景的情况下，其实“简”是非常重要的。

通向致简--研发结构分析

由于各个公司的组织架构不同，研发架构也不同。比如有些公司是中心型的，整个公司里非常强的中央研发机构，可以把整个公司架构都解决。有些公司是不同的小的技术团队，做一些不同的产品，可能是分散型的结构。也有一些公司整个就是散的，没有特别明显的中心化。

但是对于大多数公司来讲，研发一般都是先行于运维的，系统上线之后才会考虑运维的事情，上线之后发现好多运维的工作跟不上。

不同公司的结构不同，运维团队的影响力也不一样，你有很多好的想法但是苦于你的团队推动力不行或者团队技术能力储备不够，所以无法推动。

通向致简--管理方式分析

可能的管理方式：

• 第一种，全局设计整体考虑

  这个公司有很强的研发结构，可以从全局设计一个非常强大的研发体系，它在这个研发体系里就可以把整个运维环境里所要面对的扩展性、一致性、调度等等这样一些东西全部考虑进去。

• 第二种，灵活适配效率优先

  公司已经发现了非常分散，针对每种情况做适配的工具，短期效率可能非常高；

• 第三种，标准规范持续改进

  通过强制的规范和约束，以及通过模块化的规范和标准，让业务变得逐渐统一，短期可能效率低，但长远来看可能会带来长期的收益。

工具可以带来效率提升，而标准和规范有时候很难感受到或者能够衡量带来的效率。兼顾全局目标与短期需求，短期可以开发满足需求的高效工具，长远可以进行系统的模块化和标准化。

通向致简--环境分析

上面的图是以我们团队的案例给大家做一个介绍。

我们团队在1999年的时候发布QQ，2002年QQ秀上线，2005年QQ音乐上线，QQ空间是在2005年6月正式发布，在2006年我们才做了D/O分离。

上面几个产品都是海量的服务，每一个都是不同的团队研发的，在不同的年代全部上线了，而且每个产品都有大量的用户群体、大量的服务器，研发结构可能也会有差异，这时候运维再接过去改进它、管理它，其实有很大的挑战。

2009年QQ农场上线，这是一个全民的游戏，短期内我们几个月时间布了四五千台服务器上去。

多中心型研发组织，规模大、增长快、研发架构不统一、变更频繁、持续online、没有维护时间，较强的系统耦合，这些都是QQ的东西，对QQ平台的服务都有一些依赖。

最后是长生命周期，上线之后，除了农场这样游戏类的东西可能慢慢淡化了，但是其他业务是多年运营的，需要长期维护它。

通向致简--需求分析

这两年在个性化推荐这一块有个观点，从千人一面到千人千面，这块我们的做法是从千人千面到千人一面，要让运维同事全部掌握，难度是非常高的。

我们做的是把这个框架全部独立出来，把 TCP/IP 通信协议里的网络层和性能相关的东西全部脱离出来，做成一个框架，包括稳定性、空中海量连接等全部放在框架里。

使用SO的方式编写，这样的方式让我们编写的代码基本上都是一样的。

程序编写出来之后，你要上线可能会涉及到配置文件、启动命令、启动参数、log保存路径，我们全部用包的思想把它装在包里面，对安装路径写到这个log的格式，写到log的大小，还有启动、关闭、安装、删除等等全部进行了约束，做到了程序交付千人一面，对我的环境来讲逐渐进行规范和约束。

通向致简--确定工作目标

从架构及分工上简化，历史原因，不可能说之前就有非常好的名字服务，所以我们做了一个L5系统，希望我们的程序出故障以后，我们不像硬件厂商提供给我们的服务一样，两周之后再来给你处理。

当时的目的就是希望做到这个程度，基本原理是我们有一个中心的服务器，DNS服务器，上面包含所有的名字服务的注册，在每个机器上都会有一个 Agent ，就是本地的共享内存。从服务器上拉下来一个名字，然后IP地址，拉下来以后就可以了，如果网络中断，只影响下发，不影响历史数据。

我们每一次请求都会把成功、失败、延迟上传到服务器，这样可以做到判断哪个机器的成功率、失败率多少，延迟多少，可以做一个负载均衡的设置，从而达到负载均衡和名字服务的作用，做完这个以后就可以把架构从上到下进行统一。

接入层刚才没仔细讲，我们叫 Qzhttp 的接入组件，把进入层全部进行标准容错。我们中间加了一层 access 层，记录之后，由L5和 access 进行容错， access 层对下面的数据层进行容错。

刚才说的千人一面的组件全部在组件运维组维护，接入运维组现在3-4个人，组件运维组是9个人，存储运维组是9个人，我们总共是10万台级别的服务器，2/3以上的是这三个组维护的，标准化之后大家的效率提升非常明显。

我们做了一个基于CMDB的虚拟镜像。

通向致简--建立标准仓库

我们把一个模块要提供完整服务的时候，通常是多组进程，加一些基础服务，甚至装一些脚本，会依赖一些命令一些权限。

这个用户有没有开通会员、开通游戏，这个是需要权限的，我们把它也当做一种资源，我们把它登记到这个模块以来运行的二级 CMDB 里。

镜像包、配置、文件、权限、脚本、测试工具，全部记录在中间，类似于 Docker 镜像一样，通过这样的方式，我们形成了一个运维和开发的交付界面，拿到以后，运维开发我们可以共同维护这个交付页面，从而达到非常高效的运维过程。

通向致简--梳理流程

我画了一个简单的图，我们把一个进程需要的相关资源打到一个包了，把包放在资源仓库里，资源仓库里的东西如果有模块要运转，需要哪些资源在我们的CMDB记录下来，包括权限。

在我们的监控系统中，发现某个模块需要扩容，或者我们日常决策需要扩容的时候，通过流程进行调度下发，调度运行把它从资源仓库里放到我们业务模块A上去，然后进行注册，注册之后我们就可以通过灰度的方式进行上线，上线之后还会有一些自动化测试。

通向致简--注重规律

很多人会讲，规范推动起来非常困难，确实是，但是没有大家想象的那么困难。

运维环境中的60%法则，规范这东西对整个团队是有帮助的，但是短期是有困难的，你最重要的是保持耐心去推，推的时候有一个60%法则，你推过60%以后，剩下的就慢慢靠过来了。

我们也花了很多天把我们可信的东西做了推广，一般是一年时间推，推完之后一年时间到60%，慢慢到80%、100%。

约束趋于规范，灵活带来效率。你可能做了很多工具改进它，一个规范，其实这些问题都不存在了。

腾讯运维实力案例

• 红米空间首发

  织云效果还是不错的，比如说我们在红米空间首发的时候，虽然小米这两年势头没有那么猛了，但是早期他们上线的时候还是非常猛的。在红米空间首发，单秒有14.8万抢购，90秒卖了10万台，超过1亿点赞。

• 天津大爆炸2亿调度

  大家都知道两地三中心做多地分布，但是真正发生过地震或者掉电、火灾这样的事情在国内没怎么听说过，但是我们遇到一次，天津大爆炸，爆炸过程中这么厚的钢板被打成了V字型，很多墙都倒了，都停电了，只有机房有保障。平时我们调一个set，天津有好几个set，全部要调会深圳和上海，我们做了大量的扩容工作。

• 春节红包

  春节红包这块我们也做了好多次的支持，春节红包对用户量的拉动，大家会带动消息量，整个链条，这么多模块同时需要扩展，这也显示了我们千人一面或者按层来管理的优势。

  最近几年流行的一些工具和方案

• 运维组件级服务

  这两年修改很多开源的系统，譬如 Zookeeper 、 Puppet 、 Docker ，这些是运维组件级的服务。

  类似于 Docker 镜像管理这方面不是很完善，同时安全性方面可能也会有一些小问题，比如用SSH通道下发同时建很多互信关系。

• 轻量级整体解决方案

  整体解决方案有 Ansible 、 SaltStack ，这个是轻量级的运维解决方案。

• 重量级整体解决方案

  重量级整体解决方案中比较好的，如： K8S 和 OpenStack。

即使有这样的开源工具，标准规范一样不能少。比如说把 Docker 和 Puppet 做比， Puppet 更偏向于文件级， Docker 更偏向大的集装箱级，实际过程中也发现很多公司把它作为类似于虚拟机一样的，把整个的服务全放在里面，包可能更小一点。

如果只是把运维和开发的界面寄托于 Docker 来解决，就好比把开发的所有东西都装进 Docker 里，线是乱七八糟的，但出问题的时候，受力的还是运维。因为这个线是无数的开发在里面布的，找一个人过来解决不了这个问题，但是运维把它布得很清晰的时候，出了问题一样可以解决的。

Puppet包Docker及规范

织云系统早年一直是服务于我们内部，也受制于我们的人力，所以一直没有开发出一个对外的版本。

在去年底我们也下决心把它做成一个可以独立部署的第三方部署版本，我们最近也把它交付给了几个互联网金融公司和在云上支持房地产公司的客户。

7月份我们刚刚出了第二个版本，做了很多改进，特点是基于规范化、标准化理念。

第二是长期让业务趋于一致，其实里面还有很多细致的东西，然后较少的定制开发。大家互相知道你的模块之间怎么维护怎么管理，大家都是同一个理念，会更加标准更加高效一点。

运维团队的践行之路“致智”

接下来我们分享一下AI浪潮下的运维：智

我负责这块工作也做了很多实践，我们在推荐这个领域也做到每天170亿次的推荐量，做的是通用推荐场景，20多个业务，400多个场景，用了大量的机器学习的算法和支持。

另外做了一些文本处理的东西，社群和自然语言处理的东西，所以这一块天然有我们的责任感，把运维的工作解决一下，做了一些思考。

机器学习,我们先看一下机器学习，十大机器学习算法。

C4.5:做分类用的；

K-means:主要是聚类；

SVM:做分类用的；

Apriori:是频繁项类；

EM:最大似然估计；

PageRank:做搜索用的；

AdaBoost:分类用的；

KNN:分类用的；

贝叶斯：分类用的；

CART:分类和回归；

里面有七个是和分类相关的。

推荐类如逻辑回归、决策树、矩阵分解、CF、Word2Vector、强化学习等。大多数情况下也都是一种分类问题、二分类问题，最多是多分类，多分类问题也可以转化为二分类问题。

深度学习，DNN、CNN、RNN，CNN里面有一个叫卷积和池化，卷积就是用一个窗口去提取一些图片里小的特征，比如线条或者编译，池化就是把这个东西再进行一个最大值或者是平均值。

简单来讲，加入一个图片以1024x1024，这么大的像素点，这个像素点就是特征，这个像素点其实没什么意义，都是一个的，通过这样的方式把它大量汇聚。比如车的轮子、方向盘或者灯，说白了就是提取一些特征，通过人为的标注，判断是不是车、是不是人、是不是你。

分类算法的应用

分类算法本质上是通过大量数据的“线索”找到分类依据，“线索”就是特征，分类算法大多数对特征有较强的依赖。比如指证分解和隐含特征，他不需要把特征明确提取出来，但是大多数对它都比较有强的依赖。

其实我们运维环境中有大量的数据，只要这些数据你能记录下来，我们就能通过我们的技术和累计的经验，知道哪些特征对这个问题进行一个分类有帮助。

其实我们在过程中就应该把这些数据想办法记录下来，把这个特征尽量保证得更加清晰，不要放在一个连续的字符串里，应该隔断。

可能有些人有误解，我们把数据交给深度学习网络，它就可以把这个东西分析出来，其实不是这样，如果把一个图片的1024连续的数据分享给神经网络，他也分不出来。

运维和AI可能结合的点

AI和运维的结合，某种程度上讲有点像无人驾驶，可以服务大家，但是短期内还是比较困难的。我们在很多决策，虽然里面叫做AI机器学习，但是在这个里面有个问题，他有很多场外信息你可能并没有纳入到这个角色里，这个场外地区是很难补齐的，有很长的路要走。

做得更加智能和AI化，是短期内可以挖掘很多实践的。对数据的特征建设和归档中走向智能，解放自己的双手。

运维和AI可能的结合点：智能告警、网络异常分析、程序异常分析、关联异常分析、变更体验报告、硬件故障预测、投诉文本聚类、咨询客服机器人。

有很多的数据场景，我们通过一个归类统计数，再和异常进行标注，异常行为有什么样的特征？正常情况下有什么样的特征？这种数据就可以采集下来进行一个分类。

对于网络异常，各种不同的网络异常，表现状态不一样，可以把这个东西进行一个分类。

关联异常分析，发现异常以后，哪个最终是导致异常最根本的原因，底层的故障会导致上面多处告警，如果能够最终定位出来，当然我们可能有一个故障单，这个故障单定位出来以后，你就知道哪里是。然后你把这个长期的关系，以后的工作就会变成一种类似于标注，标注出来这是一个什么异常，是一个分类。

因为分类算法都要进行样本集，日常的故障单处理就可以变成样本集。变更体验报类似的及遇见故障预测，很多谈对已经在研究，通过系统log，判断这个硬盘会不会出现一些故障。

文本聚类投诉，咨询服务机器人，这是我们最近刚刚做出来的，运维团队来讲有非常大的咨询服务，咨询量很大，但是内容很固定。

针对一个系统的，其实可以提升我们效率的，或者说我们运维的构成进入到一个新的不同的领域里去。

运维团队的践行之路“致深”

还有一个选择，你成为每一个细分的领域最顶尖的人。我也在我的团队里经常说你能不能做到在我们团队里任何一个领域出现故障的时候，所有的人都第一时间想到你，找你来解决这个问题。

第二个感受，大学里的课程，我们运维同事很多都是对计算机行业对IT行业有很大的热诚，但是很多人都是相关专业的，他很多基础知识是有缺失的。想做 DevOps ，我觉得有些基础知识是确实需要的，学习起来也并没有那么困难。

在大学里面和你相关的课并不多，相关的课就那么几门，一门课一年就二十个学时。你要对它进行深度的学习，给自己一个定位标签，在这个团队里你就扎准一个方向，深度学习、深度原因，做到让团队所有人遇到这个地方的问题肯定就找你。

同时你可以把一个东西做好以后做第二个，第二个做好以后做第三个，把整个课程体系全部摸一遍，基础非常牢靠，这时候你再去做 DevOps Master 。

第一你在技术上有影响力，第二你对所有的细节非常清楚，第三你有这个资历和影响力，别人也信任你，你有这个眼界可以达到这个程度。