基于AIOps理念开发的新一代运维监控，全面展现IT运行状态，减少运维人员重复性工作量，提高运维速度IT系统故障排除，加速运维知识学习积累。DevOps的出现有其必然性。在软件开发生命周期中，遇到两个瓶颈。第一个瓶颈在需求阶段和开发阶段之间。为了应对不断变化的需求，对软件开发人员提出了很高的要求。后来出现了敏捷方法论，强调适应需求、快速迭代、持续交付。第二个瓶颈在开发阶段和构建部署阶段之间。大量已完成的开发任务可能会在部署阶段受阻，影响交付，于是DevOps应运而生。DevOps的三大原则：InfrastructureasCode（基础设施即代码）DeveOps的基础是使用自动化的脚本或软件来实现重复性的东西，比如Docker（容器化）、Jenkins（持续集成）、Puppet（基础设施建设）、Vagrant（虚拟化平台）等。持续交付（ContinuousDelivery）**持续交付是在生产环境中发布可靠的软件并交付给用户。持续部署不一定交付给用户。涉及到2次，TTR（TimetoRepair）维修时间，TTM（TimeToMarketing）产品上市时间。为了高效地交付可靠的软件，有必要尽可能地减少这两个时间。部署方式有很多种，比如蓝绿部署、金丝雀部署等。协同工作（CultureofCollaboration）开发者和运营者必须定期密切合作。开发应该理解作为软件另一个用户组的运维角色。协作有几个建议：1.自动化（减少不必要的协作）；2.范围小（每次修改的内容不要太多，降低发表风险）；3、统一的信息分发中心（如wiki，让双方都可以）4、标准化的协作工具（如jenkins）附上DevOps的定义：DevOps（Development和Operations的结合）是强调“软件开发者（Dev）”和“IT运维技术人员（Ops）”**之间沟通和合作的文化、运动或实践。通过自动化“软件交付”和“架构变更”流程，构建、测试和发布软件可以更快、更频繁、更可靠。自动化运维系统的需求是随着业务的增长以及对运维效率和质量要求的不断提升而产生的。在很多初创公司和中小企业中，运维还处于原始的“刀耕火种”状态。这里所说的“刀”和“火”就是运维人员的远程客户端，比如SecureCRT、WindowsRemoteDesktop。在这种工作方式下，服务器的安装、初始化、软件部署、服务发布、监控等全部由人工完成，需要运维人员登录服务器进行一项一项的管理和维护。这种非并发的线性工作模式是制约效率的最大障碍。同时，由于手动操作方式过于依赖运维人员的执行顺序和操作步骤，稍有不慎就会导致服务器配置不一致，即同一组服务器的配置存在差异.有时，这种差异很难直接检测到。例如，负载均衡组中个别服务器的异常很难发现。随着业务的发展，服务器越来越多，运维人员开始转向脚本和批量管理工具。与“刀耕火种”的工作方式相比，脚本和批处理工具确实提高了效率和项目质量。但是这种方法仍然存在很多问题。首先是脚本的非标准化。不同运维人员编写的脚本在使用的编程语言、编码风格和健壮性等方面存在巨大差异，这些脚本的版本管理也是一个挑战。二是脚本的继承。人员离职和工作交接，会导致脚本在运维人员之间得不到很好的继承和复用，因为下一个运维人员可能无法理解和修改上一个运维写的脚本人员。脚本函数。三是批次管理工具的选择。为不同的管理者选择不同的批次管理工具，必然会导致管理混乱，无法满足运维人员相互备份工作的需要。因此，构建自动化运维系统的需求也越来越迫切。通过自动化运维系统实现标准化，提高工程效率是唯一正确的选择。那么如何搭建自动化运维系统呢？本案例分为三大方面：第一是为什么要构建自动化运维系统，就是要解决“3W”中的Why和What，即why和what。二是介绍我司各运维子系统如何设计、运行和处理问题，解决“3W”中的How问题，即如何去做。三是对我司在自动化运维过程中遇到的一些问题进行总结。一、搭建自动化运维系统的原因我们先来看看为什么要搭建自动化运维系统。首先我们来看一下在运维中遇到的一些挑战，如下图所示。运维面临的第一个挑战就是游戏的需求。表现在三个方面：一是游戏数量多。我们公司目前运营近百款游戏。其次，游戏结构复杂。游戏公司和一般的互联网公司有很大的区别，就是游戏的来源可能有很多，有国外的也有国内的，有大的也有小的厂商；每个游戏的结构可能不同，有的是分区的。有的是集中的，有的是集中的，有各种各样的需求。三是操作系统种类繁多。这和刚才的情况差不多。游戏开发者有不同的背景和编程偏好，例如Windows和Linux。二是在硬件环境方面，主要表现在服务器数量多，服务器型号多。由于公司成立至今已十余年，在此过程中分批、分期采购的服务器几乎横跨各大OEM厂商的主要产品线，型号众多、杂项繁多。最后是人为因素。在构建自动化运维系统的过程中，比较重要的考虑因素之一就是人的因素。如果每个人的技术能力都很强，很多时候一个人就可以完成所有的工作，可能就不需要自动化运维系统了。正是因为每个运维人员的能力不同，技术水平不同，甚至运维习惯和工具也不同，所以我们必须打造一个标准化的自动化运维系统来提高工作效率。二、构建自动化运维系统的目标我们来看看构建这个自动化运维系统的目标，也就是说我们的原则是什么？作者将构建自动化运维系统的目标概括为四个字。首先是“完备”，系统必须能够覆盖所有的运维需求。二是“简洁”，简单易用。如果系统的运行流程、操作界面、设计思路比较复杂，运维人员的学习成本会很高，使用效果会打折扣，系统的能力和效率也会打折扣。第三是“效率”，尤其是在批量处理或者执行特定任务的时候，我们希望系统能够及时的给用户反馈。四是“安全”。如果系统不安全，它可能会很快被黑客接管。所以安全也是一个重要因素。3、自动化运维系统的结构和运行方式下图是我公司目前自动化运维系统的几个子系统。让我们来看看它们是如何协同工作的。首先会通过自动化安装系统安装服务器，然后由自动化运维平台接管。自动化运维平台将为自动化安全检查系统、自动化客户端更新系统、服务端更新系统提供底层支持。自动数据分析系统和自动客户端更新系统之间会有关系。自动数据分析系统将对自动客户端更新系统的结果进行反馈。自动化运维架构图我们来看看各个子系统是如何设计和工作的。3.1.自动化安装系统说到自动化安装，大家可能并不陌生。我们刚才说挑战是“二多二少”。机型很多，操作系统也很多，但是人少，能用的时间也少。如下图所示，整个流程采用通用框架。首先由PXE启动，选择要安装的操作系统类型（Windows或Linux），然后根据Windows系统自动识别要安装的驱动程序。在服务器交付给用户之前，会进行一些基本的安全设置，比如防火墙设置、关闭Windows共享等，这在一定程度上提高了安全性，减少了一些需要手动完成的操作。自动化安装流程图3.2、自动化运维平台服务器被自动化安装系统安装好后，由自动化运维平台接管。自动化运维平台是运维人员的操作平台。主要解决服务器和操作系统异构、数量多而带来的管理问题。操作系统多种多样，我们在设计系统的过程中考虑了以下因素：将整个系统的用户界面设计为基于浏览器的架构。运维工程师可以随时随地登录管理系统进行运维，更加方便。Octopod服务器向被操作的机器发出指令。异构服务器统一管理。以前大家可能都讨厌Windows，但是Windows也能驾驭得很好。我们使用开源的SSH方式来管理Windows，这样系统就可以批量打补丁和更新，密码管理和操作也可以批量进行。利用现有协议和工具。这个平台的特点是所有的系统都是通过SSH来管理的，而不是自己开发一些Agent，这也体现了自动化运维的观点。在很多情况下，我们不需要重新发明轮子。即使我们创建了客户端方法，大多数时候也没有在生产环境中经过严格验证。SSH协议本身已经存在多年，在我们公司也使用了很多年。问题已经出现了。与造轮子相比，使用SSH更稳定，更易测试，使用更方便。3.3.自动化安全检查系统下一个系统是自动化安全检查系统。既然我们有很多子系统，很多业务，那么如何设计一个系统来保证它们的安全呢？这里主要有两个系统：自动化安全检测平台和服务器端。我们先来看自动化安检平台。游戏公司和一般互联网公司的一个区别是，前者需要发送很多客户端（尤其是一些客户端比较大）或者补丁文件给玩家进行更新、下载和安装。如果这些文件中出现病毒和木马，那将是一件非常糟糕的事情，甚至会对业务和公司的声誉造成不良影响。这些文件在发送到玩家电脑之前，必须经过病毒检测系统的检查，确保没有被注入相应的病毒代码。再来看服务器端，主要是通过安全扫描架构来保证安全。安全不是一蹴而就、一劳永逸的。如果你不对系统进行持续的检查、检测、检测，你的一些误操作会导致系统暴露在互联网上，或者暴露在恶意攻击者面前。通过主动自发的安全扫描架构对所有服务器进行安全扫描，可以在很大程度上避免此类问题。举个例子，我们去年遇到过一个情况。当某台交换机的ACL达到一定数量时，就彻底失效了。如果没有相关的配套机制去检查和检测，那么你的服务器，你认为保护得很好的端口，或者敏感的IP可能已经暴露了。因此，通过这种主动检测可以减少许多系统或人为安全问题。3.4.客户端自动更新系统游戏是周期性的，尤其是在游戏发售当天或有版本更新的时候。此时玩家活跃度很高，下载行为较多。不过平时的更新和下载带宽可能并不大，这也是游戏非常突出的一个特点。这个特性对我们构建这样的分发系统提出了很大的挑战。第一个挑战是游戏可以在高峰时段产生数百GB的带宽。二是很多小运营商或者中小运营商都有一些缓存机制。如果这个缓存机制没有处理好，就会影响到业务，也就是非法缓存的问题。三是关于DNS调度。DNS调度本身是基于玩家自身LocalDNS的机制来解决的，会存在调度不准确的问题。第四是DNS污染，或者说DNSTTL的机制让调度变得不敏感和不准确。针对这些问题，我们有以下两个系统来解决。第一套是Autopatch系统，解决大文件更新的下载问题，第二套是多个CDN厂商的流量调度。操作过程也比较简单。运维人员上传文件，进行安全检查，然后同步到CDN，由CDN分发到相关的边缘节点，最后解压文件。刚才说了游戏的周期性特点，就是平时带宽不是很大，但是到了某个节点，或者重大事件的时候，带宽就比较大了。如果自己搭建CDN系统，可能不是很划算，所以我们引入了国内多家比较大的CDN厂商来调度资源。我们采用302调度的方式，而不是把域名给其中一个或几个。因为直接使用CNAME很难按比例调度，尤其是带宽大的时候，CDN厂商无法解决，或者CDN厂商出现局部故障，需要快速移除。通过集中调度系统可以实现按比例调度的功能。用户发出的所有请求首先要在我们这边调度，但它本身并不产生直接下载带宽，而是通过相关算法按比例、区域调度给第三方CDN厂商，然后由第三方实际分发播放器派对。CDN供应商节点下载客户端。第二套是多拉多系统。刚才提到小运营商或者一些运营商的非法缓存机制会影响业务，所以对于一些关键文件，如果缓存了一个旧版本，可能会造成很大的问题。比如我们的区服列表中，如果我们在服务器端新增了一个区服，但是在客户端没有显示出来，就会导致玩家无法进入新的区服进行游戏。针对这些问题，我们设计了一个内部代号为Dorado的系统，因为这些文件本身比较小，数量也不是特别多，但是需要用HTTPS加密，通过加密避免小运营商的缓存问题。因此，我们对这些密钥文件有自己的节点，并在节点上支持HTTPS加密方式，避免小运营商缓存带来的一些问题。3.5.服务端自动化更新系统我们采用的服务端更新方式也是比较传统的类CDN方式，通过缓存节点从目标服务器下载到中心节点，由缓存节点缓存控制，可以减少网络传输数据量，提高效率。我们在设计这个系统的时候，也想过用P2P来做。大家都觉得P2P很酷，也很节省带宽，但是在生产环境下用它来分发大文件的时候有几个问题。一是安全管控问题。很难让这些服务器传输数据并保护安全端口。其次，在P2P中做流量控制或者限流也是一个挑战。所以最后我们选择了一个看似更简单的架构。3.6.自动化数据分析系统谈到客户端更新，更新效果如何，玩家是否安装成功或进入游戏，很多时候我们一头雾水，只能看日志。但是日志中的很多信息是不完整的，不完整的。下载客户端的时候，看HTTP日志，有一个206的代码，很难统计玩家到底下载了多少个客户端，甚至是否下载了，验证结果是否正确，这也很难知道。所以我们最终设计了一个自动化的数据分析系统，目标是分析从用户开始下载到登录游戏，数据是如何转化的。最理想的情况是用户下载完客户端后，就进入了游戏，但这是比较理想的情况。很多时候，比如由于网络状况不佳，导致用户最终未能成功下载，或者由于账号出现问题，导致用户最终无法登录游戏。因此，显示的数据是一个漏斗形状。我们的目标是最终获得与最初下载客户端的用户数量相似的登录用户数量。让我们看一下系统的架构。首先是玩家端的下载器或安装客户端，游戏客户端中集成了一些SDK，任何关键点，如“下载”按钮或“停止”按钮的数据，都会上报。当然，这不会涉及敏感信息。上报后会有一个Tomcat集群，数据经过集群处理后写入MongoDB。看看这个游戏在开机过程中有什么问题。左边一栏分为三个文件，一个3MB，另外两个2G多。其实你可以想象一下。很多时候玩家看到小文件就直接下载安装小文件，其实并不完整。这也告诉我们，在很多时候，无论是在经营上还是在业务上，都需要在引导上更加合理一些，才能避免出现一些问题。3.7.数据自动备份系统我们第一版备份系统的设计实现比较简单：在不同的机房会有一个FTP服务器，将机房的数据写入FTP服务器，再写入到磁带，但是这样一来，磁带就散乱了，没有一个集中存放的地方；另外，基于FTP的上传会有带宽甚至延迟的要求。后来我们设计了一个集中备份系统。主要解决以下两个问题。首先是简化配置。我们所有机房的所有配置，直接用一个负载均衡器的IP就可以了。当客户端需要上传文件时，通过负载均衡器获取到实际的上传地址，然后上传文件，由左侧第二个框内的服务端执行。接收，根据MD5值校验。如果验证没有问题，就会转移到Hadoop的HDFS集群中。目前该集群规模为数十PB，日上传量为数TB。二是提高传输效率和成功率。每个人都会思考一个问题。在中国，网络环境非常复杂。运营商之间存在隔阂甚至壁垒，导致网络不稳定、丢包和延迟。如何解决问题？如果基于TCP传输大文件，理论上单连接上的bandwidth-delayproduct是有限制的。我们这里创新的是客户端使用UDP协议上传，UDP本身是没有控制权的。说白了，就是客户端可以任意的大力发送文件。最后服务端会检查你收到了哪些文件碎片，然后通知客户端上传一些没有上传的碎片。基于这种方法，可以避免很多由网络抖动或网络延迟引起的问题。当然也可以在客户端做流量控制。遇到问题，多想一想，说不定就能找到不走寻常路的解决办法。3.8.自动监控报警系统下面我们来看看游戏的自动监控报警系统。游戏架构包括游戏客户端、服务器、网络链路，因此需要有一个比较完善的系统，进行全方位、立体的监控，确保业务出现问题前预警，出现问题时报警发生。对于机房链路，有IDC（InternetDataCenter）网络质量监控；在服务器、网络设备和硬件方面，我们会做服务器健康检查、性能监控，以及网络设备和流量监控；在系统程序方面，我们会对系统日志进行收集和分析；在游戏服务器端应用方面，有服务器端程序监控；在客户端方面，我们会采集植入SDK下载更新后的效果，采集crash数据。作为运维人员，我们在思考一个问题或者设计一个架构的时候，不应该把自己的视角局限在一个技术方面，或者选择技术有多酷有多牛。我们必须思考技术的业务架构，或者是否能通过业务指标。监控我们的运维能力和运维系统。在游戏中，一个很重要的指标就是在线人数。通过监控在线人数这个业务指标，可以知道系统是否正常工作，是否存在误报或误报，因为很多时候任何一个环节都出现了问题，最终将反映在业务中，反映在产生价值的数据中。因此，我们有一个监控在线用户数量的系统。每一款游戏上线前，都会接入这个系统，在线用户数会实时采集到系统中。如果出现异常抖动，系统会显示出来，让您知道是否有问题。上面是一个框架，下面我们来看看具体细节以及如何监控服务器。首先，运维工程师在监控策略平台上配置监控策略，监控策略平台会将数据格式化成相关格式，然后推送到自动化运维平台。自动化运维平台会判断数据是外部的还是远程检测的；无论是网络模拟还是本地监控。比如流量、本地进程、本地日志的监控，都会推送到远程检测服务器或者游戏服务器本身，然后由他们上报数据。数据上报后，根据运维工程师配置的阈值，触发相关告警，通知运维工程师处理。因为虽然有各种各样的游戏，各种各样的操作系统，但是总有一些东西是大家可以共享的，比如监控模板或者监控策略。服务器的东西我们也做了整合和总结。你可以看到我们里面有很多插件。运维人员只需选择相关插件，配置阈值和周期即可，节省时间和学习成本，提高配置策略的效率。配置策略完成后，可以直接绑定到你要监控的服务器上。总结我们从2000年初开始做自动化运维系统，总结一下过去，我觉得有三个方面供大家参考。首先是循序渐进的原则，尤其是中小型公司或者初创公司，很多时候并不需要一个“高大上”的系统。关注当前问题，处理好当前问题，后续问题就会迎刃而解。如果一开始设计的系统非常庞大，功能特别丰富，就会导致一些不可控的情况。比如这个系统可能最后没法继续下去，或者因为耦合性太强，无法控制开发，或者项目因为资金问题搁浅。但如果一开始的目标是解决一些具体的问题，有的放矢，就比较容易推进。我们在搭建自动化运维系统的过程中，首先搭建了一个基础的服务器批量操作平台，先把一些需要重复执行的工作搬到平台上，然后根据需要丰富这个操作平台的功能运维的需要和提高效率，最终将周围的系统连接起来，相互连接，形成一个完整的自动化运维系统。二是考虑可扩展性。在设计系统的时候，你可能不需要考虑那么多的功能或者设计方面，但是你应该考虑当服务器数量扩展的比较大的时候，系统是否还能支持，比如数量级从十台到几百台,或数千，系统是否仍然可用。第三是出于实用目的。这也反映在我们的系统中。在很多情况下，市场上可能已经有比较成熟的协议和工具。使用它们来评估它们在生产环境中是否可用。如果可用，请直接使用它们。没有必要自己再做一个。自己做的这套工具，很多方面都没有经过验证，可能会造成安全问题。基于成熟的协议和框架，提高效率，保证稳定性和安全性。在“自动化运维平台”一节中可以看到，我们并没有从头开发一个Agent植入到托管服务器中，而是使用了开源的SSH协议和成熟的OpenSSH软件。这体现了优先开源方案加一部分二次开发而不是重新发明轮子的思路。
