1、演讲内容划分
第一个方面是我们来看一下，为什么要做自动化运维体系，就是解决“3W”里面的为什么以及是什么，Why和What的问题。
第二个方面是我们看一下，目前盛大游戏各个运维子系统是怎样工作的，是怎样设计、运行和处理问题的，解决“3W”里面的How的问题，怎样去做的。
第三个是对我们盛大游戏在自动化运维过程中遇到的一些问题的一些思考，做一个总结。
2、自动化运维体系简介
首先来看一下我们为什么要做一个自动化运维体系。首先来看一下运维遇到的一些挑战，第一个游戏的需求。它表现为三个方面。大家知道盛大游戏是比较知名的老牌游戏厂商。那它现在运营的游戏多达数百款。第二个游戏架构复杂。
游戏公司和一般的互联网公司有一个很大的区别，就是游戏来源可能是很多，比如说有国外的、国内的，有大厂商、有小厂商的。每个游戏的架构可能是不一样的，有的是分区制的，有的是大区制，各种各样的需求。
另外一个是操作系统种类多，这与刚才的缘由类似，开发者的背景与编程喜好不一样，会有Windows、Linux等。第二个是在硬件环境，主要表现为服务器数量多、服务器型号多。因为公司建立到现在十几年的时间了，在这个过程中分批、分期采购的服务器几乎横跨各大OEM厂商的各大产品线，型号是比较多和杂的。
另外是人的因素，我们在建设自动化运维体系过程中个一个比较重要的考虑点是人的因素，如果大家都是很牛的人，很多时候一个人可以完成所有工作的情况下，可能你也不需要自动化运维体系了。正是因为我们每个人员的能力不一样，技术水平参差不齐，甚至是运维**惯也不一样，导致我们必须要创建一套规范的自动化运维体系，来提升我们的工作效率。
3、自动化运维体系简介
再看一下我们建设这套自动化运维体系的目标，也就是说我们的原则是什么？我觉得做任何一件事情，目标和原则都是非常重要的。
我对自动化运维体系的建设目标这块，总结为四个词：
- 第一是"完备"，你这个系统要能涵盖所有的运维需求；
- 第二个是"简洁"，简单好用，如果系统的操作流程和操作界面、设计思想都比较复杂，那运维人员使用起来是打折扣的，那系统的能力、发挥的效率也会因此打折扣；
- 第三个是"高效"，特别是在批量处理或者是进行特定任务时，系统能够及时给用户反馈；
- 第四个是"安全"，如果一个系统不安全，那么就可能导致做了以后很快就被人接管了。所以安全也是重要的因素。
4、运维子系统详解
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讲到的自动化运维平台，自动化运维平台会监控是外部来的，还是远程检测，还是网络模拟还是本地的监控进行的。
比如说流量、本地进程的监控、本地日志的监控，它分别推给远程探测服务器，或者是游戏服务器本身。然后由它们进行数据上报，数据上报以后根据运维工程师配置的阈值，会触发相关的报警，然后通知运维工程师进行相关处理。因为虽然游戏是多种多样的，操作系统是多种多样的，或者是操作系统是五花八门的，但是总有一些可以大家公用的东西。
大家可以认为是监控的模板或者是监控的策略，我们对服务器的东西也进行了整合汇总。大家可以看到我们里面有很丰富的插件，运维人员只要个选择相关的插件，把阈值配一下，把时间配一下，就可以节省每个人的时间和学**的成本，提高你配置策略的效率。
当配置策略完成以后，你直接绑定到你想要监控的服务器上就可以了。
5、总结
构建自动化体系的三个建议
- 循序渐进
- 以实用为目的
- 考虑可扩展性
我们从2000年初到现在，一直在做自动化运维体系，这么多年以来我们也想也在考虑一个问题，对我们过去进行总结，我觉得是有3个方面可以给到大家建议。
第一个是一个循序渐进的原则，特别是中小公司或者是初创公司，很多时候我们并不需要一个高大上、白富美的系统，你可能需要聚焦当前的问题，把当前的问题处理好、处理完美了，后面的问题也是一个迎刃而解的情况。如果你开始设计的系统很庞大、功能特别丰富，就会导致一些无法控制的局面。
比如说这个系统可能最后做不下去了，或者是因为耦合性太强，开发控制不了了，或者是项目费搁浅了也是有可能的。
但是如果开始的目标是解决一些特定的问题，有一些针对性的，推进起来也是比较简单的。
另外是考虑可扩展性，我们设计系统的时候，功能或者是设计方面你可能不用考虑那么多，但是针对当前的问题你要考虑你的服务器，当发生一些比较大的扩张的时候，是否还能支撑它们，比如说数量级从十到一百、一千了，是否还是可用的，这也是要考虑的问题，就是要考虑可扩展性。
另外是以实用为目的，这在我们系统也是有体现的，很多情况下，市面上可能有一些比较成熟的协议和工具做这个东西，我们只是需要通过相关的评估认为它在生产里面可用，很多时候没必要自己再去做一套。
你再做一套很多时候没有经过验证的，可能会带来安全的问题。基于成熟的协议和框架去做，而不是自己再造轮子，很多时候是可以提升你的效率，保证你的稳定性和安全性。
Q & A
Q：
我想问一下对于数据服务器传输，你是说新的架构采用UDP传输的方式。我想问一下具体用什么软件，因为这种架构可能要两个中转机，一边发一边收，可能还存在不稳定的因素。您可能用这个技术比较成熟了，我想听听整体架构的基础方案。
A：
这位同学提的问题非常棒，可能这一点也是分享里面比较有价值的思路。因为UDP本身的设计初衷并不是被用于传文件，只是进行不可靠消息传送，比如说DNS里面普遍使用UDP。本来不是用于传文件，当然我们将它用于传文件就要考虑刚才这位同学所说的问题。
这里面我们这个工具是自研的，市面上这个工具并不太多，市场上也有一些商业的产品，美国有一家公司好像是被IBM收购了，蛮贵的。这个实现起来并不困难，UDP没有一些链路检测的机制，很多东西其实是在服务器端控制。
打个形象比喻，比如说客户端把这个文件Seek到某个位置里面去传就可以了。那服务器端根据收到的文件它最终会进行一个组合，这个和HTTP Range请求的思路相反。
服务器会看0—100兆文件里面我收到了哪些，哪些是错误的，这个时候再通知客户端补传就可以了，最终服务器端和客户端进行校验，就可以确保你是否完全OK了。这个应该自己做也不是特别复杂的事情。
出处：http://www.cnblogs.com/madsnotes/
声明：本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。