行业动态

关于作者

徐峰

盛大游戏高级研究员

2006年毕业于南京大学，2011年加入盛大游戏，拥有十年运维经验，曾参与盛大游戏旗下多款大型端游、手游的线上运维，领导统一运维平台的产品功能设计与实现，并具有工信部认证的高级信息系统项目经理资格

前言

首先，请允许我做一个简短的自我介绍。我叫徐峰，来自盛大游戏，现任系统工程高级研究员。我写了一本书，叫《Linux Best 》。

在这次演讲中，我把它分为三个方面。

第一个方面，我们来看看为什么要做一个自动化运维系统，也就是解决“3W”中的why和what，why和what的问题。

第二个方面是看盛大游戏的各个运维子系统是如何工作的，如何设计、运营和处理问题，如何解决“3W”问题，如何去做。

三是总结一下我们在盛大游戏自动化运维过程中遇到的一些问题。

自动化运维系统介绍

首先，我们来看看为什么我们需要做一个自动化的运维系统。首先，我们来看看运维中遇到的一些挑战，以及第一个游戏的要求。它表现在三个方面。我们都知道盛大游戏是比较知名的老牌游戏厂商。它现在运营着数百款游戏。第二种游戏结构复杂。

游戏公司和普通的互联网公司有一个很大的区别，就是游戏的来源可能有很多，国外的、国内的、大厂商的、小厂商的。每个游戏的结构可能不同，有的分区，有的很大，需求多样。

另一个是操作系统的种类很多，和刚才的原因差不多。开发者的背景和编程偏好不同，如Linux、Linux等。二是在硬件环境上，主要表现在大量的服务器和大量的服务器型号上。由于公司成立十余年，在这个过程中分批分期采购的服务器几乎跨越了各大主机厂的主要产品线，而且型号比较多且杂。

另一个是人为因素。在构建自动化运维系统的过程中，比较重要的考虑因素之一就是人的因素。如果每个人都是好人，很多时候一个人可以完成所有的工作。 ，也许你不需要自动化运维系统。正是因为我们每个人的能力不同，技术水平参差不齐，甚至运维习惯也不同，所以我们必须建立一个标准化的自动化运维体系来提高我们的工作效率。

看看我们构建这个自动化运维系统的目标，也就是我们的原则是什么？我认为做任何事情，目标和原则都很重要。

我构建自动化运维系统的目标总结为四个字：

运维子系统详解

1.自动化安装系统

我们来看看盛大游戏目前自动化运维系统的几个子系统，以及它们是如何协同工作的。第一个是自动安装系统。服务器由自动化安装系统安装完成后，由自动化运维平台接管。

自动化运维平台为自动化安全检查系统、自动化客户端更新系统和服务器端更新系统提供底层支持。自动数据分析系统和自动客户端更新系统是相关联的。自动化数据分析系统将反馈自动化客户端更新系统的结果。

让我们来看看每个子系统是如何设计和工作的。说到自动化安装，大家可能并不陌生。我们刚才提到，挑战是多两个少两个，模型和操作系统很多，但是人少，可用时间少。

整个过程采用了一个通用的框架。首先是通过PXE启动，是否安装，是否是Linux，然后根据系统自动识别要安装的驱动。在服务器交付给用户之前，会进行基本的安全设置。

比如在防火墙设置中，关闭了里面的共享，在一定程度上提高了安全性，也减少了一些需要手动进行的操作。

2.自动化运维平台

服务器由自动化安装系统安装后，将由自动化运维平台接管。自动化运维平台是运维人员的操作平台。它解决的主要问题是服务器和操作系统是异构的，数量非常庞大。

我们可以看到，在这张图中，我们的操作系统也是五花八门的。在设计系统的过程中，我们有几个考虑因素。首先是将整个系统设计为基于浏览器的用户界面。一个架构。

运维工程师可以随时随地管理您的系统进行运维操作，更加方便。服务器将向正在操作的机器发出指令。你可以看看这里的一个特性，服务器也是由 SSH 管理的。过去每个人都对它的感觉感到厌恶。

事实上，你可以很好地管理它。你可以参考这里，看看你是否能得到帮助。我们采用开源SSH方式进行管理，可以批量更新补丁到系统，批量密码管理和操作。

所有系统都是通过SSH管理的，而不是在上面开发一些Agent，这也体现了自动化运维的观点，至少我尊重。很多时候我们不需要自己造轮子，而是自己搭建一个客户端的方法服务器运维，很多时候在生产环境中并没有得到强烈的验证。

但是SSH协议本身已经存在很多年了，在盛大游戏中也使用了很多年。问题已解决。与造轮子相比，这更稳定、更可验证、更易于使用。方便的。升级之后也有升级，可以更简单。

3.自动安检系统

下一个系统是自动化安全检查系统，因为我们有更多的子系统和更多的业务。那么我们如何设计一个系统来保证他们的安全呢？然后我这里讲了两个主要系统，一个是自动化安检平台。

游戏公司和一般互联网公司的一个区别是他们有很多客户端，尤其是大客户端，或者需要发送给玩家更新、下载和安装的补丁文件。如果有病毒和木马，那将是一件非常糟糕的事情，甚至会对业务和公司的声誉造成很大的影响。

这些文件在发送到玩家电脑之前，必须经过病毒检测系统，确保没有被注入相应的病毒代码。另一个是服务器端，主要通过安全扫描架构来完成。我们都知道，安全往往不是一朝一夕的过程，也不是一劳永逸的过程。如果您不不断地检查、检测和检测您的系统，那么您的一些误操作将导致您的系统暴露在互联网上或被恶意攻击。在攻击者的眼皮底下。

通过一种主动、自发的安全扫描架构，它会扫描您的所有服务器以确保安全，您可以在很大程度上规避这个问题。举个例子，我们去年也遇到过一个情况。当某台交换机的ACL达到一定数量时，整个ACL就失效了。如果您没有相关的支持机制进行检查和检测，那么您的服务器、您认为保护良好的端口或敏感IP可能已经暴露。

所以通过这种主动检测，可以减少很多系统或人的安全问题。

4.自动客户端更新系统

说到客户端更新，我们都知道游戏是周期性的，尤其是在游戏发售当天或者有版本更新的时候。这时候玩家很活跃，下载行为也很多。

但是在平时，更新和下载带宽可能不会很大，这也是游戏一个非常显着的特点。但是这个特性对我们构建这样一个分发系统提出了很大的挑战。

那么第一个就是游戏产生的带宽在高峰期可能达到数百G。其次，很多小型运营商或中小型运营商都有一些缓存机制。当然，如果这个缓存机制处理不好，就会影响业务，也就是非法缓存的问题。

另一个问题是关于 DNS 调度的。 DNS调度本身是根据玩家自己的Local DNS机制解析的。对此，会出现调度不准确的问题。此外，DNS 污染或 DNS TTL 机制会使您的调度变得不那么敏感和准确。

我们有两个系统来解决这些问题。第一套是系统，解决大文件的更新下载，多CDN厂商的流量调度。操作过程也比较简单。运维人员上传文件，进行安全检查，然后同步到CDN。 CDN将文件分发到相关的边缘节点，最后解压文件。

它有一个特点，刚才提到了游戏的周期性特点，就是平时带宽不是很大，但是在节点的时候，或者是重大事件的时候，带宽就比较大了。如果自己搭建CDN系统，可能不太划算，所以我们引进国内很多大型CDN厂商来调度资源。

我们的调度是通过302的方式，而不是把域名分给其中的一个或几个。因为直接使用CNAME很难按比例调度，特别是带宽大的时候，CDN厂商解决不了，或者本地出现故障，需要快速移除。这样的功能可以通过集中调度系统来实现。

所有用户的第一个请求是在我方调度，但不产生直接下载带宽，而是通过相关算法按比例和面积调度给第三方CDN厂商，然后在客户端，播放器实际上是由第三方 CDN 供应商节点下载的。

刚才提到小运营商或者部分运营商的非法缓存机制会影响业务。那么对于一些关键文件，如果缓存到旧版本，可能会造成很大的问题。

比如在我们的区域服务器列表中，如果我们在服务器端添加了一个新的区域服务器，但它没有出现在客户端，就会导致玩家无法进入新的区域服务器进行游戏.

针对这些问题，我们设计了内部代号系统，因为这些文件本身比较小，数量也不是特别多，但是需要HTTPS加密，小运营商的缓存问题可以通过加密避免。

所以我们对所有的key文件都有自己的节点，并且在节点上支持HTTPS加密，避免一些小运营商缓存带来的问题。

5.自动服务器端更新系统

让我们来看看服务器端更新。我们使用的服务器端更新方式，也是类似于CDN的传统方式。目标服务器通过缓存节点到中心节点下载，由缓存节点缓存控制，可以减少网络传输量，提高效率。

有一个小插曲。我们在设计这个系统的时候也想过用P2P来做，但是因为在生产中大家都觉得P2P是一个很炫的东西，或者说是节省带宽的东西。 ，但是在生产中用于分发大文件时存在几个问题。一是安全控制问题。如何在这些服务器之间传输数据并保护安全端口是一个难题。

另外，如何控制流量或限制流量也是P2P中的一个挑战，所以最终我们采用了一个比较简单的结构来做。

6.自动化数据分析系统

说到客户端更新。更新有什么效果，或者玩家是否安装成功或进入游戏。很多时候我们不知所措或者可以看日志，但是日志中的很多信息是不完整的服务器运维，不完整的。

下载客户端的时候，如果查看HTTP日志，里面有一个206代码。你很难计算出玩家完整下载了多少客户端，甚至很难知道他是否下载了验证结果。 所以我们最终设计了这样一个自动化的数据分析系统。它的目标是查看从下载过程开始到您登录游戏时数据是如何转换的。

一个理想的情况可能是用户下载后进入游戏，但这是一个理想的情况。很多时候，比如他的网络不好，最后下载不成功，或者是账号有问题，最后没有登录游戏。

那么它呈现的数据形式就是一个漏斗状的情况。那么我们的目标就是让最终登录的用户数接近我们开始下载的用户数。

让我们来看看系统架构。首先，播放器端有下载器或安装客户端。部分 SDK 集成在游戏客户端列表中。对于任何一个关键点，比如下载按钮或者终止按钮NYU上报数据，当然不会涉及敏感信息。上报后会有一个集群，然后集群处理后写入。

看一个例子，这是一款在某个时间点大量安装失败的游戏。

在启动过程中查看此游戏的问题。左边一栏分为三个文件，一个是3MB，两个是2G以上的文件。事实上，你可以想象它。很多时候玩家看到小文件直接下载安装小文件，其实并不完整。这也告诉我们，在很多情况下，无论是运营还是业务上，都需要在引导上更加合理，避免出现一些问题。

7.自动数据备份系统

请葛优叔叔出去。大家想想如果一个游戏在运行过程中，数据突然没了，没有备份。有任何想法吗？我觉得葛优叔做得很好。基本上，就是这种感觉。基本上，你的身体已经被掏空了，基本都难以驾驭。

有没有人想过解决这个问题的办法，有没有人举手，看来大家只有一个想法收拾行李走吧？这是一个小故事。游戏运营初期，很多时候都是粗放，没有备份机制。

在这种情况下，某游戏公司确实有这样的问题，他们到底是怎么做的？它实际上是一个活动，让玩家来填写他们的账户信息和属性，以及你正确填写了哪些金币，系统会为你匹配金币。那个时代的玩家是很无辜的。很多人填的信息，我们就填你填的。这个数据恢复了很多，游戏继续运行。

在这之后，很多玩家看到这样的言论就不会这样做了，所以我提醒大家做好备份，并保证备份的可恢复性。

这是我们第一个发生严重事故的备份系统版本，其设计和实现都比较简单和简单。也就是根据不同的机房，我们会有一个FTP服务器，然后写入机房的FTP服务器，再写入磁带，这样会导致你的磁带分散，没有集中存储地方。那么基于FTP上传会有带宽甚至延迟的要求。

然后我们设计了这样一个集中式备份系统。在这种情况下，它主要解决了几个问题。

第一个是为我们所有的机房配置一个负载均衡器IP。客户端需要上传文件时，通过负载均衡器获取实际上传地址，然后从左侧第二个框开始上传文件。如果验证没有问题，则转入HDFS集群。目前该集群规模为数十PB，日上传量为数T。

每个人都会思考一个问题。在中国，对运维人员的网络要求非常高，运营商之间的差距甚至是一些壁垒，导致网络不稳定，丢包，如何解决时延问题？如果在大文件传输过程中基于 TCP 进行，则涉及到单个连接上带宽延迟乘积的理论限制。我们这里创新的是我们的客户端上传使用UDP协议，UDP本身没有控制权。说白了就是客户端可以任意硬发送。

那么服务器最终会检查你收到了哪些文件段，然后通知客户端重新上传一些没有上传的文件。基于这种方法，可以避免很多由网络抖动甚至大的网络延迟引起的问题。当然，你也可以在客户端做流量控制。以后遇到问题的时候，可能会想一些非常规的解决方案，也可能存在。

8.自动监控报警系统

我们来看看我们游戏的监控系统。刚才提到游戏的架构决定了有游戏客户端，有服务器，有网络链路，所以你必须有一个比较完善的系统才能全方位进行，这样的三维监控可以保证业务会在问题发生前发出预警，或在问题发生时发出警报。

对于机房链路，我们有IDC的网络质量监控来做。在服务器网络设备和硬件方面，将有服务器健康检查、性能监控、网络设备和流量监控。在系统程序方面，我们会收集和分析系统日志，在游戏服务器端应用方面，会有服务器端程序监控。在客户端，会有一个植入的SDK，用于收集下载和更新效果，以及收集其崩溃的数据。

看左边那一栏，为什么用红色标出，因为我想强调它的重要性。当我们考虑运维或架构设计的问题时，我们的视角不局限于技术方面，或者我们想思考技术有多酷和牛逼，我们必须考虑技术在业务中的架构。方面。或者我们是否可以通过业务指标来监控我们的运维能力和运维系统。

游戏中的一个重要指标是在线人数。通过监控在线人数等一个业务指标，可以知道我左边的系统是否正常工作，是否有漏报或误报，因为很多时候任何一个环节都有问题。

最终表现的问题，都是关于业务和产生价值的数据，所以我们会有一个监控人数的系统。每款游戏上线前，都会与系统连接，采集一直在线的人数。在系统中，如果出现异常抖动等，会显示在里面，可以告诉你是否有问题。

这是一个框架，让我们来看看细节，我们如何进行服务器监控。

结构是这样的。首先运维工程师配置监控策略，然后到监控策略平台。监控策略平台会根据数据对数据进行格式化，格式化成相关格式，然后推送到第三页PPT中提到的自动化运维平台，自动化运维平台会监控是否它来自外部来源，远程检测，网络模拟或本地监控。

例如监控流量、本地进程、本地日志等推送到远程检测服务器，或者游戏服务器本身。

然后他们会报告数据。数据上报后，会根据运维工程师配置的阈值触发相关告警，然后通知运维工程师进行相关处理。因为虽然有各种各样的游戏，各种各样的操作系统，或者各种各样的操作系统，但总有一些东西是大家可以共享的。

您可以将其视为监控模板或监控策略。我们还对服务器的东西进行了整合和总结。你可以看到我们有很多插件。运维人员只需选择相关插件，匹配阈值，匹配时间，可以节省大家的时间和学习成本，提高你的配置策略效率。 .

配置策略完成后，可以直接绑定到你要监控的服务器。

总结

从 2000 年初到现在，我们一直致力于自动化运维系统。这么多年，我们也想考虑一个问题。总结我们的过去，我觉得可以从三个方面给大家建议。

第一个是循序渐进的原则，尤其是对于中小型公司或初创公司。很多时候我们不需要一个高级的、白色的、丰富的系统。您可能需要专注于当前的问题并妥善处理它们。 ，处理完美，后面的问题也是可以轻松解决的情况。如果您开始设计一个非常庞大且功能丰富的系统，可能会导致一些无法控制的情况。

比如这个系统最终可能不工作，或者因为耦合太强，开发无法控制，或者项目费用搁浅。

但是如果最初的目标是解决一些具体的问题，有一些针对性，推进起来也比较简单。

另一个是考虑可扩展性。在我们设计系统的时候，你可能不需要在功能或者设计上考虑那么多，但是对于当前的问题，你需要考虑你的服务器。当一些比较大的扩展发生时，是否还能支持它​​们，比如十到一百、一千的数量级，仍然可以使用，这也是一个需要考虑的问题，也就是考虑可扩展性。

另外，它是出于实用目的，这也体现在我们的系统中。在很多情况下，市场上可能有一些相对成熟的协议和工具可以做到这一点。我们只需要通过相关的评估就可以认为它在生产中。可用，很多时候不需要自己再做一套。

你做的另一套没有经过多次验证，可能会带来安全问题。基于成熟的协议和框架来做，而不是自己重新发明轮子，通常可以提高你的效率，确保你的稳定性和安全性。

问答

更多精彩继续

12月16-17日，北京站将在国际会议中心举行，将为您呈现更多精彩内容。

立即注册，在 10 月 30 日前享受早鸟价 20% 的折扣。