腾讯游戏大数据解密:DevOps持续改进之道-布道【原创】 不指定

刘天斯 , 2016/12/19 21:45 , Docker , 评论(2) , 阅读(17696) , Via 本站原创 | |
        2016年12月3日,在深圳圣淘沙酒店,运维帮、云技术、Linux中国三大社区联合主办主办了运维世界大会OpsWorld,演讲内容全程无广告,只谈技术,受到了广大观众的一直好评。本文根据刘天斯老师演讲内容整理而成。
点击在新窗口中浏览此图片
        我分享的主题是“DevOps持续改进之道——布道”。我刚才已经做了简单的介绍,这里再罗嗦一下,我叫刘天斯,现在是在腾讯互动娱乐负责大数据的运营。在互联网行业已经从业了13年,也算是一个老鸟,之前在天涯,工作了6年多。PPT右侧是我的两本著作,第二本是关于Docker的,如果大家关注Docker,可以在网上购买这本书来看看。我个人最近关注的方向有自动化运维、云计算、大数据、Docker  DevOps等。
点击在新窗口中浏览此图片
        这是我今天分享的大纲,总共分四大块,第一块是跟大家简单介绍一下我的DevOps观,第二点我会介绍我们布道平台在持续集成与交付这块是怎么做的。第三点会介绍布道在线服务运营能力。最后给大家做一个总结。
点击在新窗口中浏览此图片
        可能大部分人都认为DevOps无非是基于文化+技术这两个点在企业里面落地,这是大部分人之前的思维,在2015年底举行的全球DevOps峰会上,Gartner把DevOps做了进一步的划分,在文化和技术后面又细化出了过程和人。DevOps并非目标,但它可帮助您实现目标,企业的目标是更快地交付价值,DevOps是辅助我们完成这样一个目标的手段。
        DevOps产生的价值,我比较认同IBM给出的解释,总共有三点,第一,它认为这个会增强客户的体验。这是比较容易理解的,第二点是提高创新能力,这个不好理解,创新和它有什么关系呢?它的说法是这样的,通过DevOps去实践,通过精益的方法论去减少我们的浪费、返工,将我们现有的价值及精力投入到更有价值的事情,创新是其中的一个非常重要的点。第三个就是更快的实现价值。
        DevOps应该是永无止境的,它是一个持续改进的过程,它没有终点,它的目的是对影响交付质量的对象进行持续的改进,包括我们的技术、流程、团队,甚至企业的文化等。
        那我们怎么去检验我们的软件交付过程是不是高效的?我个人总结了一个“短”五个“快”。短就是我们交付软件的开发周期要短,快就是排错、解决问题、测试、部署、反馈这个闭环一定要快,不知道大家认不认可这样的观点,一会儿我们可以讨论一下。
点击在新窗口中浏览此图片
        Gartner在去年底提出DevOps的模型,它分为四个点,除了文化、技术,它还延伸出了过程和人这两个角色。我们首先从【技术】来看,这里面加亮的部分是重点要关注的,一个是【基础设施即代码】,第二个是【一键安装程序构建,测试、部署】,第三个是【监控一切】,第四个是【连续监控】。在【过程】里面,我认为应该关注的是【持续集成】、【测序】、【交付】这几个方面,另外还要关注到【自动化的构建】,包括【自动化发布】。我觉得【失败总结】这一点是比较重要的,当我们过程失败之后,必须要知道失败在哪里,要进行总结。另外一个是一切都要工具化,一切都要版本化。除了代码以外,我们的脚本或者是配置文件都要通过版本化进行管理。在文化这部分,我认为比较重要的就是协作的文化,还有持续的改进,还有学习的文化,这三个都不难理解,但是我认为,这里面是不是还遗漏了一点?我觉得少了信息的共享、透明,我认为这是非常关键。为什么这个很重要?在我们内部定期都会组织相关的讨论会,去讨论我们项目中碰到的问题以及风险,这些都是需要关注的,另外一点就是IBM提出的一个概念,运维要“左移”,意思是运维要在开发的生命周期阶段提前介入。这样做有什么好处呢?好处是有助于运维的问题提前在开发阶段提前暴露,我认为这是非常关键的一点。
        下面简单介绍一下我们服务的背景,我们为谁服务,服务什么样的平台。大家看一下我们的规模,当前的数据量每天入库7600亿条日志,大概80T,占公司总存储的26%。
点击在新窗口中浏览此图片
        这是我们的服务精细化的场景,这个背景是怎么来的?因为我们已经具备了海量的游戏数据,我们也在思考,怎么通过数据去驱动我们做精细化的运营。这也是我们目前不断在思考的。DataMore是我们思考出来的一个解决方案,它目前包括三个层次,第一个是大数据H5应用,比如说我们经常看到朋友圈大家分享的自己玩游戏的对局信息,这些数据都是由我们这边提供的。第二个是场景化的标签服务,我们会针对不同玩家打标签,打完标签就通过我们的精细化触达平台,针对性的做一些触达和营销活动。第三个是应用产品,比如说我们的游戏助手、官网,甚至是游戏里面的个人中心,大家会看到自己在游戏中的状态、成长轨迹、对战信息等,这些都可以看到,这就是游戏业务典型的一个服务化的场景。
点击在新窗口中浏览此图片
        下面再介绍一下我们的数据服务的架构,这个其实也没有太多的技术含量,基本上都是业界主流的能力,包括最左侧的游戏的数据源,它有两类,一类是游戏内的,一类是游戏外的。平台组件有三大块,一是数据接入,数据接入包括实时传输、离线传输,第二个是数据处理,包括实时计算引擎、离线引擎,第三个是数据储存,包括KV存储、DB存储、位图索引、HDFS等。我们的服务引擎这一块包括数据分析引擎、数据接口中心、运营规则引擎、用户触达中心,业务应用就是报表统计、数据分析、触达运营,总体来讲就是包括这样三块:数据采集、存储计算、应用落地。
点击在新窗口中浏览此图片
        这是我们的DataMore体系的技术架构,整个架构层次也比较简单,最上层是STGW,这是腾讯非常强大的一个负载均衡平台,再下面是二级代理。逻辑层我们现在有GoServer  PHP Server。实时数据层用的都是业界主流数据库存储技术,比如TRedis、Hbase、Postgresql等。最低层是数据计算层,包括实时计算引擎、离线计算引擎。当前整个服务的PV大概是6.35亿,日发布变更15次,单次发布时间是10秒,也就是一个容器起启的时间。
        下面介绍一下今天的主角“布道”。布道是我们数据服务全流程解决方案,采用了DevOps的思想实现软件的快速迭代、快速试错,最终提升软件交付的质量和达到持续改进的目的。它有几个特点,第一个是基于腾讯蓝鲸PaaS平台快速构建。蓝鲸本身就是一个PaaS平台,我们基于蓝鲸之上构建服务层的SaaS,本身布道就是基于最上层的SaaS服务。第二个是建立在DevOps的思想实践。我们这个实践思路来源于我刚才分享的Gartner发布的DevOps模型。各关键节点间之间的联系都是我们参考的样本。第三是面向运维、开发、测试、项目PM。第四个是具备持续集成、交付、部署等快速迭代的能力。第五是具备服务质量跟踪、用户舆情、持续反馈能力。
点击在新窗口中浏览此图片
        这是布道的能力体系,大家可以看一下,实际上包括两大块,一个是持续集成交付,另外一个是在线运营。其中服务质量和持续改进是贯穿整个服务生命周期。点击在新窗口中浏览此图片
        这是布道服务层的架构,刚才提到了这一块,第一块持续集成&交付是采用业界主流的架构,且比较通用,我就不详细再讲了。我们的在线运营是基于HECD的架构,实现Docker的发现注册与发现,最上层就是我们的接入层,比较简单高效,因为没有太多其它逻辑关联耦合的节点。这里的TDocker是部门内部基于Docker构建的容器服务解决方案。
        以DevOps形成的运营服务闭环,它的内涵及核心就是实现持续改进。首先通过我们的CICD的快速通道,实现软件平台的快速迭代,在质量管理方面,我们通过监控、安全、故障自愈、BUG修复等方式进行质量管理。在用户反馈方面,我们建立一个通道,会收集并响应用户的反馈,包括来源于客服和对外网舆情的采集,会将这些信息反馈给开发人员,开发人员收到反馈之后,会在功能或者bug这一块做功能修复,最终就会形成一个持续改进的闭环,而且是一个良性的闭环。
点击在新窗口中浏览此图片
        再简单介绍一下我们持续集成&交付的架构,刚才已经有提到,这里就简单说一下里面的几点细节。首先采用Docker架构具有一些优势,它可以保持跨环境一致性,天然易移植性,还有易于版本控制。然后CI&CD在流程方面做到编译并构建版本镜像,推送镜像仓库,触发交付作业并快速实现预览。
        以上介绍的是行业的主流做法,各家的方案都是大同小异的,我们在这个过程中加入了一些独特的东西,一个是代码扫描的工具coverity,它能够发现比较深层次代码逻辑问题,比如内存泄露、溢出、数组越界、未初始化等等,且目前支持的语言也比较多。
        另外一个是通过引入外网的流量,帮助我们实现压测,甚至做到一定BUG定位,它能达到百分之百的仿真的效果,具体的细节大家简单看一下PPT,整个步骤也非常简单,不是很复杂,它的特点是可以达到真实的模拟测试验证,有助于提前发现问题,有效降低发布风险。
点击在新窗口中浏览此图片
        这是一个案例,开发人员提交他的版本,然后进行预发布,在预发布里面有预览校验软件功能,也可引入外部的流量来进行预览,出现BUG会这个过程中被发现。我们在实践过程中碰到几点问题,在这里也跟大家一起分享。第一点是在容器中做源码的编译合不合理,不知道大家是怎么做的,我们给的结论是不合理。每个项目它用的第三方包或者功能组件是不一样的,可能A项目用的是A、B、C组件,B项目用的是1、2、3组件,不同的组件你在编译的时候去部署它的编译环境,这样会使我们的容器越来越臃肿,所以我们把这个环境迁移到另外一种角色(jenkinsslave),让它做源码的编译,编译完了就打包成镜像,保证镜像中没有太多无用的数据文件。第二点是容器性能的监控最优方案。我们使用Docker的时候有没发现一个问题?在容器中无论我们执行free、top、uptime、vmstat等命令,看到的都是主宿机的性能信息,原因是由于Docker的隔离性做得不够彻底导致。我们可以通过LXCFS这个组件帮助我们增强Docker的隔离性,它可以提供一个虚拟的PROC文件系统,另外也提供了容器自身的Cgroup的目录树,跟容器中的PORC目录是一一对应的。如何使用?我们Dockerrun的时候,通过“-v”参数,实现容器proc文件与Lxcfsproc的映射,效果是容器中看到的只是容器本身的内存、CPU等信息。比如说我们看CPU核数,看到的只是分配好的0、1、2、4的核数。第三点是容器在CI阶段的网络选择。这里只是给个建议,我们生产环境Tdocker使用的网络模型SRIOV,是通过硬件虚拟网卡的方式实现,然后Docker再通过IPlink做映射,但是我们在CI阶段,它是一个隔离的开发专区,它跟普通的IDC是不一样的,由于硬性相对比较老久,硬件虚拟化兼容性差,因此我们使用了Docker Macvlan方案,原理是通过创建网卡子接口与容器接口之间做映射,缺点是要求Linux Kernel 3.10.0及Docker>=1.12.0的环境。
        这是我们的线上服务。项目上线的时候,每个PM都有一个习惯,都会最大化去的申请资源,在极端情况下还会远远超过他的预估值,这个时候怎么办?只需要评估扩容的需求量为多少,什么样的机型配置,提交Tdocker在线扩容就可以了,后面的事情就交给布道去处理。
点击在新窗口中浏览此图片
        在告警方面我也分享一些思路,在腾讯已经有一套非常成熟的告警系统,我们在这里只是提供一些跟我们业务逻辑相关的策略,我们的思路首先是统一日志规范,每个人的开发水平和习惯都不一样,我们给他们统一一个规范,这个规范叫Tlog,另外引入基础+特性这两个指标。看到的这个DEMO,它通过XML的模式描述日志的结构。特性是跟业务绑定相关的,我这里有一些服务,这个服务我发了一些金币,发到某个区间可能出现问题了,我们就需要开发人员把这个发放的数值打印出来,我们好做一个曲线的跟踪。采集完之后就会进入一个日志采集环节,这个架构也很简单,就是LVS+Keepalive,采集完之后,这里就分两条线,一个是实时,一个是离线的。我们采用的是蓝鲸的实时数据平台,能够实现特性指标多维度的配置。
        这是蓝鲸的智能监控的界面。它是实时流,内部用的是Storm做实时分析,然后支持定义灵活的配置,有支持SQL的函数,比如支持某个字段的累加、求和,这个频率可以控制为10分钟、15分钟。
点击在新窗口中浏览此图片
        下面是我们安全这一块做的东西,首先是安全防御,在腾讯内部,安全这一块已经做得非常强悍,为什么我还讲安全呢?因为在公司层面做的安全防护更多是通用性或者基础类的防护,WAF更侧重在业务逻辑层,它的架构非常简单,通过布道做一些规则的下发到WAF,例如XSS、CC、UA、URI的规则等等,然后开启日志追踪,通过传输、实时分析防护日志,最终做到防护报告实时展示。
        规则校验步骤与大家简单介绍一下,目前采用Nginx+LUA结合的方式,它的防护流程是在检查端口及域名是否匹配规则,匹配就下发规则,然后检查黑白IP名单,后面再开启CC防护,以及开启userAgent检查,最后是开启URI检查注入、XSS、SSRF等。
        下面是舆情监控这一块,我们在这里特点就是关键词的实时监控、定时报送推送。从下面这个图可以看到,某一款游戏在某此活动期间的口碑展示情况,有多少是正面的,有多少是负面的报告。
点击在新窗口中浏览此图片
        最后做一个总结,在线运营的运营经验,第一个是资源评估,我们要定一个标准,根据实际服务场景来做出评估,而不是拍脑袋做。这个评估有一个公式:设计数量=(PV/86400)×2/单机承载最大QPS/0.8。
        第二个是灰度+热力度对蓝绿发布。蓝绿发布的目的是让我们的用户没有感知,我们做蓝绿发布,操作的步骤很多,一旦人工接触多了,就容易出现误操作。我们采用的是热更新方式,原理是服务A进程收到关闭信号量之后,启动B进程来接收已经创建的连接或新连接,当A进程连接完全释放之后就会自动关闭,整个过程用户无感知。灰度实际就是放量检验这个效果及功能,如中间没有出现问题,只需两步就完成变更。
        第三个是修复了Supervisor一个bug。Supervisor没办法对进程fork子进程进行管理,所以我们修复了这个bug,如大家碰到同样的问题可以私下找我,我会给大家具体的解决方法。
        最后是一个数据流向监控的实现思路。首先简单介绍一下为什么要做这个流向监控。数据的流向监控在业界目前没有较好的方案,当我们的数据链、处理链、服务链拉得很长的时候,如何感知当数据源头有发生变更或异常,影响到我们的最终服务,这是非常难度的,而且它跟我们的业务特点关系非常大。同样我们逆向推导也是成立的,我发现玩家的某个对局数据不对,本来是胜局结果变成了负局,怎么确认数据是从哪个节点负责计算或存储的?这个非常有挑战性,这需要我们的数据服务能力一步一步做叠加,需要不断做扩展与关联,才能够达到某一个层次的服务水平。目前我们做的还没那么完美。首先我们要具备元数据管理,还有元信息的管理,这是非常重要的两层。第二个是要有数据字典管理,我们给数据表名称、字段说明,结构性的定义及标签。第三个就是血缘关系,能够定义到任务之间的关系。第四个是数据服务的注册,这是比较核心的一点,怎么注册,我们怎么知道你用了哪个数据源呢?这很关键,我们内部开发了一个通用组件,比如说你要引用后端的数据层,你必须使用这个组件接入,这样关系才能够建立起来,所以应用配置文件也是单独生成的。而最上游我们会提供一个数据流向查询,我们用了A数据,查下来就知道它在这个过程经过了哪些关键点,有可能是存储、计算、分析、接口等。点击在新窗口中浏览此图片
        最后快速做一个总结,这是我们的持续服务的体系,在持续运营状态下,我们具备质量监控、舆情监控、容量管理、安全管理、故障治愈、故障修复等能力,同时收集用户服务体验、产品、BUG、新功能、吐槽点,将这些信息反馈给产品人员、开发人员和运维人员。再通过持续集成交付、发布变更管理,做到快速迭代及部署,最后就形成了良性的、持续改进的闭环。

1、【提问】:你刚才提到了资源分配的公式,你们那个公式是怎么总结出来的?那个公式的基础是以什么样的结果作为标准的?
【刘天斯】:这个公式也不是我们发明的,也是借鉴了很多前辈思路,我们只是在这个基础上做改进,结合我们自己的业务场景,包括我们服务是什么样的类型,因为服务类型不同,它的要求不一样,配置不一样,它的生命周期也不一样,它能够反映出来的效果和能力、访问量都不一样,比如服务到底是CPU型还是内存或IO型,完全不一样。这就带来一个问题,我们怎么定一个标准?我们目前聚焦在接入这块的逻辑层,供参考的是8核、4G内存,硬盘100到150G的配置。

2、【提问】:我是来自创维公司负责运维的。今天讲的是DevOps,DevOps要快速迭代到什么样的程度才行?像您现在做的一个平台一天发布15次,我不知道你在前面需要进行多长时间的准备?比如说线上的实时导流导多长时间是合适的?这个度我们一直拿捏不准,能帮我们解答一下,提点好的建议吗?【刘天斯】:在互联网行业我们大部分都是采用敏捷开发的模式,这样会产生技术的债务,这是必然的。你是传统行业吗?
【提问】:我们前身是传统行业,现在我们是互联网电视,相当于做电视上的服务,我们是非常快捷的,每天都发布,每天改bug,不停地迭代,而且需求也特别多,开发也忙不过来,我们运维也感觉到准备不足。
【刘天斯】:互联网这种快速发展的模式,势必会带来很多技术的债务,我觉得这是正常的。我们的互联网发展很快,必须要先要有一个雏形产品出来,然后再不断地迭代,这是大部分互联网公司或者是刚刚转型公司采用的模式,这种模式出现的问题我认为是很正常的问题,包括在腾讯也一样有这样的问题,他评估不到我在某个阶段要花多长时间去检验我们是否够快、是否高效。我们在布道这个环节下一步就是预发布,预发布追求的并不是快,而是能不能在临门一脚之前发现一些致命的问题,因此,可以在持续交付阶段追求快,而不应在预发布阶段。
足球比分 Homepage
2017/05/26 23:01
不错不错,好久没更新了。
harris Email Homepage
2017/03/17 21:29
一直很欣赏博主
分页: 1/1 第一页 1 最后页
发表评论

昵称

网址

电邮

打开HTML 打开UBB 打开表情 隐藏 记住我 [登入] [注册]