布道-腾讯游戏数据服务运营之道，DevOps思想传教者

本文根据运维帮沙龙黄志演讲内容整理所得

沙龙总结及ppt下载，可以点击下方链接：

运维帮沙龙第十二期《架构演进之路》深圳·10月15号（总结含PPT）

我叫黄志，2008年毕业就进入了腾讯，现在在腾讯主要负责游戏的数据运维。

下面介绍一下腾讯游戏数据的概况，当前有端游、页游、手游，将近450款业务，每天产生14万+的入库，现在有70P左右的数据，占总存储26%，这是一个海量的数据。我们用这个海量数据不仅仅做内部精分报表，还一直探索如何用这些数据为游戏精细运营做推动，实现真正大数据的价值。

所以一个主要产品DataMore就应运而生，这是一个游戏精细化运营服务，有三种运用场景：应用产品，场景化标签服务，还有就是精准营销服务，比如通过大数据给玩家打上标签，在付费的时候给他们一些特别关照；应用场景，比较常见就是助手、官网，这些数据都是由Datamore进行提供的。

这里面是Datamore的实际场景

包括剑侠情缘个人中心、王者荣耀英雄榜、还有QQ炫耀年报回顾。

这是我们用DATAMORE的应用场景，还有大数据应用，可能大家这些都有接触到，会在朋友圈里面可以看到这样的分享。

在数据中心做运维，当前主要的服务场景就是Datamore数据魔盒，不管是大数据还是场景化标签，还是应用产品，在架构上大概都是这样的架构

从接入层、逻辑层、实施数据层与离线数据层。接入层有腾讯官网，逻辑层用GO语言进行开发，实时层也用到了TRedis。我们统一使用容器化做支撑，使用HECD的架构，当前PV达到5.35亿，日均发布变更在15次以上，单次发布时长10秒钟左右。

布道是我们建设的运营平台，做平台是需要有一个响亮有趣的名字，所以就取名布道，是因为我们想它既是运营工具平台，也是DevOps的思想传教者。所以布道就是业务服务全流程解决方案，采用DevOps思想实现软件的快速迭代，快速试错，提升软件发布及运营质量。是基于蓝鲸快速构建，实践DevOps思想，面向运维、开发、测试、PM，最主要客户就是运维同学，具备持续集成、交付、部署、运营管理、服务质量管理及持续改进等能力。

我们一直在讲DevOps，我们理解的DevOps是什么样子？这是DevOps最终的样子

首先它应该贯穿软件整个生命周期，我们可以看到DevOps五个关键点，文化和变更、自动化落地、分享、同步。精英理论，还有可量化指标、监控，把运维、开发、测试整合在一起，从而实现共赢。从这里看到DevOps不仅仅有工具和技术支撑，更重要是沟通协作方式的改变。我觉得这应该是9%的改变加10%的技术，这是我们理解的DevOps的最终样子。

布道如何构建DevOps的平台？

首先布道从这个图可以看到功能架构，主要就是两大块：持续集成交付、还有在线运营。持续集成交付主要就是软件开发测试阶段，在线运营是软件的线上运营阶段，所以我们会涵盖到整个软件生命周期，对接到各个运营工具平台，梳理流程管理，通过质量管理持续反馈达到持续改进效果。

系统架构也是按照刚刚所说的两大块模块持续集成及在线运营两大模块，持续集成我们采用这个模块。开发通过提交代码到SCM，进入服务器，然后发现代码变更，实现编译，构建镜像，将镜像推到仓库里面，然后交付到现网。这是一个架构，记忆容器变更，会注入服务器上，再把信息反馈到这里，然后根据信息的模板形成全新配置软件，之后再推送出去，通过存载使新配置生效，当然接入层仍然是腾讯。在线运营和持续集成交付之间，是通过镜像、仓库接到一起的，这是我们的系统架构。

所以布道不仅仅涵盖持续集成和交付，还包括业务在线运营全流程，我们要形成运营的闭环，最终的核心就是持续改进的概念，怎么样做持续改进呢？首先持续集成和交付让快速迭代有了一个载体，然后在舆情监控及时发现用户反馈，日志及性能能够反馈应用信息，然后实现不断优化，形成持续改进的闭环，这是我们布道的核心。

接下来介绍一下持续集成这一部分，我们有一个典型的项目CICD持续集成，首先介绍这个项目，在这里需要几个节点，代码方面通过代码变更，然后把这个任务分配到节点，形成可执行的文件，之后是反馈。然后再构建镜像，推到仓库里面，这是两者的结合。

持续集成交付之所以选择Docker，是因为它能够促进持续集成交付，有一个天然优势就是可以保持跨环境的一致性，在环境下进行快速部署，有天然易移植性，也易于版本管理，每一个Tag都能够形成版本镜像，这在业务发布维稳的时候非常方便。Docker镜像有三层设计：第一个基础镜像层，在这个基础上构建应用层的镜像，安装一些常用工具，在应用层镜像基础上用于构建业务镜像，这样版本管理会比较容易实现。有Docker的加入CI工作就非常简单，就是编译构建，然后推送到镜像仓库，最后进行交付和作业。

这是我们持续集成在布道中一个实现流程

这里面简单介绍一下，首先我们要求开发要不断进行代码自检，并到合理主干，防止偏离主干。在这里我们可以看到这个代码扫描工具，然后在做到预发布的时候，就产生了外网流量引入，在这里我们做成可选择性接入的两个东西，根据项目的需要选择去做。

这里介绍一下Coverity，我们使用Coverity，这是业界公认的误报率和漏报率极低的静态代码检查工具，可以发现内存泄露、溢出、数组越界、未初始化等等代码问题，当前使用版本都可以支撑很多语言包括C/C++、Java、NET等等多种语言。在实际部署中，在CIServer进行变更，然后在编译的时候得到一个中间键，再推送到CI Coverity上，在Coverity进行分析。当然分析的结果会以报表形式返回给用户，当然这样的话可能并没有太大效果，所以我们就把腾讯内部的敏捷开发平台打通，将这些缺陷的报告生成后直接发送，录入到系统里面，让代码责任人进行修改并关闭这个缺陷单。

这是代码扫描的邮件通知

这里会告诉你有什么是漏洞严重，什么是一般，这里就会直接录入到TAPD，长期以往下去，持续改进将有效提升代码的质量。

下一个讲到现网流量的引入，我们如何做呢？这里使用就是Tcpcopy，部署主要分客户端、服务端，客户端就是我们被拷贝流量的服务器，这需要部署到tcpcopy里面去。整个现网流量引入过程大概就是这样子：外网请求、用户请求，到现网服务器，然后处理请求再反馈给用户。这个包会在IP层拷贝到TCP镜层，然后再发送给测试级，在测试级上面也会响应处理和返回，但这个包会在IP层被丢弃，然后在里面拷贝反馈到这里，最终完成一个连接，这是我们现网流量引入的实现。现网流量的引入可以帮助我们真实还原到测试验证，有助于提前发现各种问题，有效的降低发布风险。

持续集成和交付，为什么没有说持续部署呢？这里有一个关于持续部署的思考：

• 持续交付并不是说每一个改动都尽快部署到生成环境中，而是指任何一个改动都是证明可以在任何时候进行部署的。 

• 持续交付到持续部署，这里面差别就是是否自动部署到正式的生产环境中。这里面主要就是自动部署。

• 我认为持续部署在现网中可能会存在一定风险，比如说有一些版本包并不是马上就需要部署出去，可能是有一个时效，可能需要定时发布，所以持续部署有一定风险。

• 但我们系统应该具备到持续部署的能力，这样在项目需要的时候，我们可以持续部署带来一定收益。

• 最后我们希望用一键部署方案去降低部署的成本

这是我们一个项目持续集成和交付的实例

在平台中的一个实践，就是版本交付之后会有单元测试然后持续交付，交付到预发布环境里面，然后根据项目需求选择一些配置或者进行脚本的配置，最后会发布到一个现网环境中去，只需要选择一个版本包点击发布就可以了。

这里有五个关键点，平台在接入项目的时候就需要为这个项目估算需要多少资源或者多少容器，当前我们通过PV值来估算，常见估算方式就是用做总并发连接数来估计，但在业务场景下我们得出比较简化的方案：最大QPS=（PV/86400）*2；机器数量=最大QPS/单机QPS/0.8，这是我们进行资源估算的方式。

接下来讲讲进程监管工具Supervisor，我们之所以选择Supervisor作为进程监管工具，大家可能也有在用，第一安装配置比较简单，操作简便，还有一个很重要就是Supervisor所有进程都是其子进程作为监管，所以能够实现秒起，可以让影响降到最低。其次，它也能够做到集中式管理。

我们在使用Supervisor的时候也遇到两个小问题，简单介绍一下，在使用GO语言开发的时候，考虑到一个热更新，使用Facebook插件作为热更新，热更新的思路就是通过发送自定义信号量给到程序，程序再生成一个子进程，这个时候新请求就会进入子进程，老进程就会进入老进程，当完成以后它们就会退出，从而实现热更新。

这个问题就来了，这个新进程是不属于Supervisor的子进程，就脱离了Supervisor的监管，所以这个时候Supervisor会认为这个程序就是丢掉的，在这个问题上我们提供一个解决思路：Supervisor会自带一个pidproxy，我们可以用其稍微修改，使其能够适配到通过pidfile监管到某些进程，这样就能够实现任何程序都能够使用Supervisor作为进程的监管。

第二个小问题就是没有办法先CD到目录执行到可执行文件，会反馈找不到这个进程/文件，这应该算是Supervisor的小问题，在这里面有一个解决方案，大家可以参考一下。Supervisor可以实现到热更新之后，这种频繁更新方式就会优于我们业界所说的变更方式，更新不会影响现网的用户。

接下来分享一下关于监控告警的思考，Datamore项目多、日志杂，要针对每个项目独立配置告警么？我们首先统一日志格式规范，要打什么日志，怎么打，打到哪里，以什么作为分割符号，这里都有规范。我们还会处理一个统一上报日志集群，这个分布式日志集群采集到所有日志，然后分两条线，一个就是实时线，一个就是离线，实时线就是实时告警；离线数据会做一个类似报表的东西，反馈业务运营状况，会有访问率、成功率等等数据。

下面是我们配置告警的一些信息，方便我们把日志规范配置下来，所有业务上线都不需要配置更多，不需要进行单独配置告警。这是离线数据生成日志报，可以让我们方便掌握所有状况，也有助于我们发现一些问题。

当然对于运维来说，虽然我们的项目在布道平台上线之前，都会经过公司级别的漏洞扫描，同时还有系统防护，防护各种攻击。为了进一步保证系统安全，布道在任何基础上还基于这些做了一道防火墙，可以通过服务需求进行定制防护策略。开发在这里效率能够有保障，我们TLOG的日志，反馈监控报表，这会帮助我们做一些防护策略，然后把相关防护策略发下去。

这是我们安全防御LUA的防护流程，通过LUA的语言定制开发，防护流程就会从检查端口、运营、匹配规则、匹配下发规则开始，检查到黑白IP名单，开启CC防护，开启UserAgent检查及URI检查。LUA和Nginx的结合，主要就是在配置上，将LUA配置上去即可。

这是我们安全防御实践页面

我们可以通过匹配规则，加上黑白名单，还有信息攻击策略定义在多少秒，访问多少次，或者有一些异常的设置，设置规则就会下发到各个前端上面去。

我们还会接入舆情监控WeTest，可以通过7×24小时抓取应用包、AppStore等应用市场评论评星，还可抓取游戏官方相关论坛的用户发贴回贴，汇总用户舆情，并进行智能分类，帮助项目快速了解外部口碑。

总结一下就是

• 用户评论实时、全面抓取

• 评论智能分类，定位问题

• 针对单独功能的评论追踪

• 竞品评论比对，掌握先机

这个方法大家可以使用一下，亮点也可以体现，对于我们项目来说，舆情可以帮助我们有效发现问题，推动持续改进。

最后回到我们布道持续改进体系

平台将产品人员、开发人员，运维人员整合在一起，从项目的立项开始，通过持续集成交付和发布变更管理，促进快速迭代，通过质量监控、舆情监控，流量管理和安全管理，加强在线运营的持续运营。最后通过日报表还有各种通讯工具，将信息同步以及顺畅的沟通，提升整体沟通协作，最终达到持续改进的效果，这就是我们持续改进的体系。

沙龙总结及ppt下载，可以点击下方链接：

运维帮沙龙第十二期《架构演进之路》深圳·10月15号（总结含PPT）

重磅消息

运维世界大会·深圳站（OpsWorld）

12月3日举行

购票快速通道，扫描二维码

老王专场+运筹帷幄专场，限时特价优惠10元购票