盛大自动化运维

一、演讲内容划分

第一个方面是咱们来看一下，为何要作自动化运维体系，就是解决“3W”里面的为何以及是什么，Why和What的问题。

第二个方面是咱们看一下，目前盛大游戏各个运维子系统是怎样工做的，是怎样设计、运行和处理问题的，解决“3W”里面的How的问题，怎样去作的。

第三个是对咱们盛大游戏在自动化运维过程当中遇到的一些问题的一些思考，作一个总结。

二、自动化运维体系简介

　　首先来看一下咱们为何要作一个自动化运维体系。首先来看一下运维遇到的一些挑战，第一个游戏的需求。它表现为三个方面。你们知道盛大游戏是比较知名的老牌游戏厂商。那它如今运营的游戏多达数百款。第二个游戏架构复杂。
　　游戏公司和通常的互联网公司有一个很大的区别，就是游戏来源多是不少，好比说有国外的、国内的，有大厂商、有小厂商的。每一个游戏的架构多是不同的，有的是分区制的，有的是大区制，各类各样的需求。
　　另一个是操做系统种类多，这与刚才的原因相似，开发者的背景与编程喜爱不同，会有Windows、Linux等。第二个是在硬件环境，主要表现为服务器数量多、服务器型号多。由于公司创建到如今十几年的时间了，在这个过程当中分批、分期采购的服务器几乎横跨各大OEM厂商的各大产品线，型号是比较多和杂的。
　　另外是人的因素，咱们在建设自动化运维体系过程当中个一个比较重要的考虑点是人的因素，若是你们都是很牛的人，不少时候一我的能够完成全部工做的状况下，可能你也不须要自动化运维体系了。正是由于咱们每一个人员的能力不同，技术水平良莠不齐，甚至是运维**惯也不同，致使咱们必需要建立一套规范的自动化运维体系，来提高咱们的工做效率。

三、自动化运维体系简介

再看一下咱们建设这套自动化运维体系的目标，也就是说咱们的原则是什么？我以为作任何一件事情，目标和原则都是很是重要的。
我对自动化运维体系的建设目标这块，总结为四个词：

• 第一是"完备"，你这个系统要能涵盖全部的运维需求；
• 第二个是"简洁"，简单好用，若是系统的操做流程和操做界面、设计思想都比较复杂，那运维人员使用起来是打折扣的，那系统的能力、发挥的效率也会所以打折扣；
• 第三个是"高效"，特别是在批量处理或者是进行特定任务时，系统可以及时给用户反馈；
• 第四个是"安全"，若是一个系统不安全，那么就可能致使作了之后很快就被人接管了。因此安全也是重要的因素。

四、运维子系统详解

4.1 自动化安装系统

　　来看一下盛大游戏当前自动化运维体系的几个子系统，它们是怎样联合起来工做的。第一个是自动化安装系统。服务器由自动化安装系统完成安装之后，会被自动化运维平台接管。
　　自动化运维平台对自动化安检系统、自动化客户端更新系统和服务器端更新系统提供底层支撑。自动化数据分析系统和自动化客户端更新系统会有关联关系。自动化数据分析系统会对自动化客户端更新系统的结果给予反馈。

下面咱们来看一下每一个子系统是如何设计和工做的？

　　说到自动化安装，你们可能并不陌生，咱们刚才说到挑战是两多两少，型号多、操做系统多，可是人少，可用时间也比较少。整个流程采用通用的框架，首先由PXE启动，是否安装Windows，是不是Linux，而后根据Windows系统自动识别出须要安装的驱动。服务器交付用户以前，会进行基本的安全设置。好比说防火墙设置，把Windows里面的共享关闭，这在必定程度上就提升了安全性，另外也减小了人工须要作的一些操做。

4.2 自动化运维平台

　　当服务器由自动化安装系统安装完成之后，就会被自动化运维平台接管。自动化运维平台是运维人员的做业平台，它主要解决的问题就是服务器、操做系统异构，并且数量特别多。咱们能够看到在这个图里面，咱们操做系统也是五花八门的，咱们在设计系统过程当中有几个考虑的地方，第一个是把整个系统在用户界面方面设计成基于浏览器的这样一个架构。运维工程师不管什么时候何地均可以去管理你的系统进行运维操做，那这样的话就比较方便。会由Octopod服务器对被操做的机器发布指令。你们能够看一下这里面有一个特色，Windows服务器也是用SSH的方式进行管理的。你们之前对Windows可能感受是深恶痛绝同样。其实Windows你也能够管得很好，这里面你们能够参考一下，看一下是否可以获得帮助。咱们使用了开源的SSH方式管理Windows，这样就能够对系统进行批量的补丁更新，批量的密码管理和操做都是能够的。全部的系统使用SSH管理，而不是本身开发一些Agent在上面，这也体现了自动化运维的观点，至少我是推崇的，不少时候咱们不必造轮子，本身造一套客户端的方法，不少时候它并无在生产环境里面获得强烈地验证。可是SSH协议自己已经存在不少年了，并且已经在盛大游戏使用不少年了，该出的问题已经出了，相对于造轮子，这一点更加稳定，更加经得起验证，使用起来更加方便。升级什么的也跟着升，就能够更加简单了。

4.3 自动安检系统

下一个系统是自动化安检系统，由于咱们的子系统比较多，业务也比较多。那咱们怎样设计一套系统去保障它们的安全呢？那么我这里面讲到主要是两个系统，一个是自动化安检平台。
　　游戏公司和通常的互联网公司有一个区别，就是它有不少的客户端，特别是比较大的客户端，或者是补丁文件须要发送给玩家去更新、下载和安装。若是这里面出现病毒和木马，将会是一个很糟糕的事情，甚至是对业务和公司的声望形成很大地影响。
当这些文件被发到玩家电脑以前，必须通过病毒检测系统去确保它没有注入相应的病毒代码。另外是服务器端，主要是经过安全扫描架构去作。你们知道安全不少时候并非一蹴而就或者是一劳永逸的过程，你若是不对你的系统进行持续地检查、检测、探测，那么你的一些误操做会致使你的系统暴露在互联网上，或者是暴露在恶意攻击者的眼皮之下。
　　经过一种主动、自发的安全扫描架构对你全部的服务器进行安全扫描，就能在很大程度上规避这样的问题。举一个例子就是咱们在去年的时候，也遇到过一个状况。某款交换机ACL达到必定的数量的时候，整个就失效了。若是你没有相关的配套机制去检查、检测，那你的服务器，你认为保护很好的端口或者是敏感的IP可能已经被暴露了。
　　因此经过这种主动的探测就能够减小不少的系统或者是人为的安全问题。

4.4 自动化客户端更新系统

面临的挑战

• 数百Gbps下载和更新带宽的调度
• 小运营商缓存问题
• 同名文件刷新问题
• DNS调度不许确
• DNS污染
• DNS缓存问题（TTL）

　　到客户端更新这块，你们知道游戏是有周期性的，特别是在游戏发布当天或者是有版本更新的时候，这时候玩家活跃度很高，下载行为也是比较多的。可是平时的时候可能更新和下载带宽并不大，这也是游戏很显著的特色。可是这个特色对于咱们构建这样一个分发系统就提出了很大地挑战。

　　那么第一个就是在高峰时候游戏产生的带宽可能达到数百G。第二个不少小运营商或者是中小规模的运营商会有一些缓存机制，固然这个缓存机制若是处理很差，会对业务形成影响，也就是非法缓存的问题。

　　另外是关于DNS调度的问题。DNS调度自己是基于玩家自己的Local DNS的机制解析的，针对这个会有调度不许确的问题，另外是DNS污染，或者是DNS TTL的机制致使你的调度不那么灵敏和准确。

　　针对这些问题，咱们有两套系统来解决问题。第一套是Autopatch系统，它解决的是大文件更新下载，另外是多家CDN厂商流量调度。操做流程也比较简单，由运维人员上传文件、安检，而后同步到CDN，CDN分发到相关边缘节点最后解压文件。它有一个特色，刚才说到游戏的周期性特色，就是平时带宽不是很大，可是节点的时候，或者是重大活动的时候带宽比较大。若是本身构建一套CDN系统，可能不是很划算的，因此咱们引入中国比较大型的多家CDN厂商调度资源。
　　咱们的调度是经过302的方法，而不是把域名给其中一家和其中几家。由于直接使用CNAME的话很难按比例调度，特别是当大带宽的时候，一家CDN厂商解决不了，或者是一家发生局部故障，你须要快速切除。经过集中的调度系统就能够实现这样的功能。全部用户下来的请求，第一个都是要在咱们这边进行调度，可是自己并不产生直接下载带宽，而是经过相关算法，按比例和区域调度给第三方的CDN厂商，而后客户端，玩家实际地是由第三方CDN厂商节点去下载。

 

　　刚刚讲到小运营商或者是某些运营商它的非法缓存机制会对业务形成影响。那么对于某些关键的文件，若是它缓存到是一个旧版本，那可能会形成很大地问题。好比说咱们的区服列表，若是咱们服务器端增长了新的区服，在客户端没有显现出来，那就致使玩家没有办法进入到新的区服去玩。
　　那针对这些问题，咱们设计了内部代号为Dorado的系统，由于这些文件自己是比较小的，并且数量也不是特别多，可是须要HTTPS去加密，经过加密规避小运营商的缓存问题。因此咱们对于关键文件，对于这些文件咱们所有是有自有节点，在节点上是支持HTTPS加密方法，规避小运营商缓存带来的一些问题。

4.5 自动化服务器端更新系统

　　再来看看服务器端更新。咱们采用的服务器端更新模式也是比较传统的一种相似于CDN的方式，是由目标服务器经过缓存节点去到**节点下载，由缓存节点缓存控制，这样能够减小网间传输的量以及提升效率。这里面有一个小插曲，咱们在设计这套系统的时候，也想过用P2P去作，可是由于在生产里面，你们想P2P是一个很炫的东西，或者是很节省带宽的东西，可是用于生产里面的大文件分发的时候会有几个问题，一个安全控制的问题，怎样让这些服务器之间又能传数据又能进行安全端口的保护这是很难的问题。
　　另外是怎样进行流量控制或者是进行流量限定，在P2P里面也是一个挑战，因此最终咱们是采用了一个看起来比较简单的架构去作。

4.6 自动化数据分析系统

　　说到客户端更新。更新的效果怎样，或者是玩家这边到底有没有安装成功或者是进入游戏。不少时候咱们很茫然或者是能够看日志，可是日志里面的信息不少是不完善和完整的。你下载客户端的时候，若是看HTTP的日志的话，里面是206的代码，你难以计算出玩家到底完整下载多少客户端，甚至他有没有下载下来校验结果是否正确也是很难知道的。因此咱们最终设计了这样一个自动化数据分析系统，它的目标就是要看一下用户从开始下载的过程开始到你一直登陆到游戏里面，到底数据是怎样转化的。
　　一种最理想的状况下多是用户下载之后，他最终就进入了游戏，可是这是一个理想状况。不少时候好比说由于他的网络很差，致使它最终没有下载成功，或者是一些帐号的问题，最终他没有登陆到游戏里面去。那么它展示起来的数据形式就是一个漏斗状的状况。那么咱们的目标就是让最终登陆的用户，最终要接近于咱们开始下载的用户量。

　　咱们来看一下系统的架构，首先有玩家这边的下载器或者是安装客户端，游戏客户单里面集成一些SDK，对于任何一个关键的点，好比说下载的按钮或者是终止的按纽都进行数据上报，固然这里面不会涉及到敏感的信息。上报之后会有Tomcat集群，而后集群处理之后会写入MongoDB里面去。

看一下例子，这是某个游戏在某个点内发生了不少的安装失败的问题。

　　看一下这个游戏在引导过程当中有什么问题，左边的这一列它分为三个文件，有一个是3兆，有两个是2G多的文件，其实你们能够想像一下。不少时候玩家看到小的文件就把小的文件直接下载安装了，可是实际上并不完整。这一点也告诉咱们，其实不少时候在运营或者是业务方面，在引导方面也是要比较合理才能去规避掉一些问题。

4.7 自动化数据备份系统

提问：正在运营的游戏，数据忽然没有了，并且没有任何备份，你怎么办？

　　把葛优大爷请出来了。你们想一想若是某个游戏在运营的过程当中，数据忽然没有了，并且没有备份。有什么想法？我以为葛优大爷作到很到位，基本上就是这个感受，基本上你身体都被掏空了，基本上很难办了。
　　有没有人想过用一些方法来解决这个问题，有没有人举手的，看来你们都只有一个想法打包走人，是吗？这里面讲一个小故事，游戏运营初期不少时候是粗放的，并无备份机制。在这种状况下，某游戏公司也确实发生过这样的问题，最后怎样作的呢？它实际上是作了一个活动，让玩家过来填本身的帐号信息以及属性，以及哪些金币，你填得对的和系统匹配的给你金币。那个年代的玩家都很纯真的，不少人把信息填上去了，咱们就你填什么就是什么，这个数据恢复了不少，游戏也就运营下去了。
　　在这以后，不少玩家看到这样的演讲就不这样操做了，因此警告你们备份必定要有，并且要保证备份的可恢复性。

　　这是咱们发生严重事故的第一个版本的备份系统，它的设计和实现也是比较纯朴、朴素的。就是根据不一样的机房，咱们会有一台FTP的服务器，而后本机房的写入FTP服务器，而后写入磁带，这样会致使你的磁带是分散的，没有集中存放的地方。而后基于FTP的上传是会有带宽甚至是有延迟的要求。

后来咱们设计了这样一个集中的备份系统。这样的话，它主要是解决几个问题。
　　第一个咱们全部机房所有配置一个负载均衡器的IP就能够了，当客户端须要上传文件，经过负载均衡器获取实际上传的地址，而后把文件上传，由左边第二个框里面的服务器进行接收，而且根据MD5值进行校验，若是校验没有问题，转到Hadoop的HDFS集群里面去，目前这个集群有数十PB的规模，天天上传量有几个T。
　　你们会想一个问题，在中国这样一个对于运维人员来讲网络要求很高的状况下，甚至是运营商之间的这种隔阂甚至是一些壁垒，致使网络不稳定、丢包、延迟的问题是怎样解决的呢？若是在大文件传输过程当中，你是基于TCP作的，涉及到单个链接上带宽延时积的理论上的限制。这里咱们创新的是，咱们客户端上传是走UDP的协议，UDP自己没有任何控制，说白了就是客户端能够任意、使劲地发就能够了。
　　那么最终会由服务器端检查你哪些文件片断收到了，而后通知客户端补传一些没上传的就能够了。基于这种方式就能规避不少由于网络抖动甚至是网络延迟比较大致使的问题。固然你也能够在客户端作流量的控制也是能够的。你们之后在遇到问题的时候，可能想想有一些不走寻常路的解决方案，也是可能存在的。

4.8 自动化监控报警系统

 

　　再看一下咱们游戏的监控体系，刚刚说到游戏的架构决定了有游戏客户端、有服务器端，有网络链路，因此你必需要有一个按比较完整的体系去进行全方位、立体式的这样一个监控，才能保证业务在发生问题以前进行预警，或者是发生问题时报警。
对于机房链路方面，咱们是有IDC的网络质量监控去作。在服务器网络设备和硬件方面，会有服务器的健康检查、性能监控以及网络设备和流量监控。在系统程序方面，咱们会进行系统日志的收集和分析，在游戏服务器端应用方面，会有服务器端的程序监控。在客户端方面，会有植入的SDK进行下载更新效果的收集，以及它崩溃的数据收集。
　　你们看一下左边这一列，为何标红色，是我想强调它的重要性。咱们运维考虑问题或者是设计架构的时候，咱们的视角不只仅局限于一个技术方面，或者是想技术怎样炫酷、多么牛，咱们要想一想技术在业务方面的架构。或者是可否经过业务指标监控咱们的运维能力、运维系统。
　　在游戏里面有一个指标很重要的，就是在线人数，经过监控在线人数这样一个业务指标，就能够知道我左边的系统是否工做正常，是否是有漏报、误报的状况，由于不少时候你任何一个环节出了问题。
　　最终表现的问题都是在业务方面，都是在产生价值的数据方面，因此咱们会有一套人数监控的系统，每一个游戏上线以前会接入系统里面去，把时时在线的人数聚集到系统里面，若是发生异常的抖动等状况都会显示在里面，也就能够告诉你是否发生了问题。

 

这是一个框架，那咱们看一下细节的，关于服务器的监控咱们是怎样作的。
　　架构是这样的，首先由运维工程师来配置监控策略，到监控策略平台里面去，监控策略平台会根据这些数据，将这些数据进行格式化，格式化成相关格式，而后**给刚刚在第三页PPT讲到的自动化运维平台，自动化运维平台会监控是外部来的，仍是远程检测，仍是网络模拟仍是本地的监控进行的。
　　好比说流量、本地进程的监控、本地日志的监控，它分别推给远程探测服务器，或者是游戏服务器自己。而后由它们进行数据上报，数据上报之后根据运维工程师配置的阈值，会触发相关的报警，而后通知运维工程师进行相关处理。由于虽然游戏是多种多样的，操做系统是多种多样的，或者是操做系统是五花八门的，可是总有一些能够你们公用的东西。
　　你们能够认为是监控的模板或者是监控的策略，咱们对服务器的东西也进行了整合汇总。你们能够看到咱们里面有很丰富的插件，运维人员只要个选择相关的插件，把阈值配一下，把时间配一下，就能够节省每一个人的时间和学**的成本，提升你配置策略的效率。
　　当配置策略完成之后，你直接绑定到你想要监控的服务器上就能够了。

五、总结

构建自动化体系的三个建议

• 按部就班
• 以实用为目的
• 考虑可扩展性

　咱们从2000年初到如今，一直在作自动化运维体系，这么多年以来咱们也想也在考虑一个问题，对咱们过去进行总结，我以为是有3个方面能够给到你们建议。
　　第一个是一个按部就班的原则，特别是中小公司或者是初创公司，不少时候咱们并不须要一个高大上、白富美的系统，你可能须要聚焦当前的问题，把当前的问题处理好、处理完美了，后面的问题也是一个迎刃而解的状况。若是你开始设计的系统很庞大、功能特别丰富，就会致使一些没法控制的局面。
好比说这个系统可能最后作不下去了，或者是由于耦合性太强，开发控制不了了，或者是项目费搁浅了也是有可能的。
可是若是开始的目标是解决一些特定的问题，有一些针对性的，推动起来也是比较简单的。
另外是考虑可扩展性，咱们设计系统的时候，功能或者是设计方面你可能不用考虑那么多，可是针对当前的问题你要考虑你的服务器，当发生一些比较大的扩张的时候，是否还能支撑它们，好比说数量级从十到一百、一千了，是否仍是可用的，这也是要考虑的问题，就是要考虑可扩展性。
　　另外是以实用为目的，这在咱们系统也是有体现的，不少状况下，市面上可能有一些比较成熟的协议和工具作这个东西，咱们只是须要经过相关的评估认为它在生产里面可用，不少时候不必本身再去作一套。
你再作一套不少时候没有通过验证的，可能会带来安全的问题。基于成熟的协议和框架去作，而不是本身再造轮子，不少时候是能够提高你的效率，保证你的稳定性和安全性。
Q & A
Q：
　　我想问一下对于数据服务器传输，你是说新的架构采用UDP传输的方式。我想问一下具体用什么软件，由于这种架构可能要两个中起色，一边发一边收，可能还存在不稳定的因素。您可能用这个技术比较成熟了，我想听听总体架构的基础方案。
A：
　　这位同窗提的问题很是棒，可能这一点也是分享里面比较有价值的思路。由于UDP自己的设计初衷并非被用于传文件，只是进行不可靠消息传送，好比说DNS里面广泛使用UDP。原本不是用于传文件，固然咱们将它用于传文件就要考虑刚才这位同窗所说的问题。
这里面咱们这个工具是自研的，市面上这个工具并不太多，市场上也有一些商业的产品，美国有一家公司好像是被IBM收购了，蛮贵的。这个实现起来并不困难，UDP没有一些链路检测的机制，不少东西实际上是在服务器端控制。
打个形象比喻，好比说客户端把这个文件Seek到某个位置里面去传就能够了。那服务器端根据收到的文件它最终会进行一个组合，这个和HTTP Range请求的思路相反。
服务器会看0—100兆文件里面我收到了哪些，哪些是错误的，这个时候再通知客户端补传就能够了，最终服务器端和客户端进行校验，就能够确保你是否彻底OK了。这个应该本身作也不是特别复杂的事情。

出处：http://www.cnblogs.com/madsnotes/

声明：本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文链接。