运维必备生存指南 |《王者荣耀》乱象居然也能反映出运维生存现状？
《王者荣耀》已成为社会现象级手游，随之问题接踵而来。部分小学生沉迷后为买游戏道具刷爆家长银行卡、为抢夺游戏中“buff(增益效果)”大打出手。前端
这些问题怎么产生？python
责任又应由谁来承担？linux
如何进行有效的防止沉迷监管？ios
种种问题引起社会普遍讨论。nginx
达妹只想说的是：游戏虽好玩，可不能贪呦~web
今天就带你们走进这些鲜为人知的幕后英雄Linux游戏运维的世界，一块儿窥探这神秘世界的一草一木。sql
王者荣耀从2015下半年至今取得辉煌成就，正所谓最好的爱情莫过于各自努力彼此成就：），运维这期间是Tcaplus伴其成长，遇到了不少风险和挑战。
shell
一、Tcaplus的管理模块由存储服务全局管理系统(OMS)和tcapcenter组成，OMS向用户呈现基于web的管理入口，将用户的指令转发给tcapcenter，实际的控制、管理工做由tcapcenter完成，OMS则将操做的进度和结果反馈给用户。每一个存储集群有一个tcapcenter，而OMS与tcapcenter之间是一对多的关系，所以一个OMS能够管理多个存储集群。数据库
二、存储集群是一组硬件资源的集合体，对其位置没有特别的限制，但按照惯例，同一个集群的节点都应在同一个IDC内，以保证存储服务的性能。apache
三、Tcaplus数据服务模块的工做原理：API client链接tcapdir，读取tcaproxy列表；tcapdir是Tcaplus API使用者在初始化系统时惟一须要提供的信息；tcapdir能够部署多个，以达到容灾的效果；API client获取tcaproxy列表以后，链接全部的tcaproxy进程。用户发送数据读写请求，Tcaplus API根据用户所指定的表名及key字段信息，决定将请求发送给哪一个tcaproxy进程。tcaproxy进程接收到请求消息后，根据其维护的路由表肯定目标tcapsvr master，而后将消息转发给该tcapsvr master。tcapsvr master接收到请求消息以后，进行数据读写，并生成响应消息，原路返回经由proxy到达API client. 若是请求消息类型为写操做，tcapsvr在发送响应以前，实际上还会生成一条binlog记录，在较短期内（毫秒~秒级）同步至slave，使得slave可实时维护一份与master相同的数据。
Tcaplus总体架构
回到正题，说一说咱们的游戏运维及运维的生存指南和现状。
一直以来，中国网游在世界上都处于举足轻重的地位。从最先的端游到页游再到手游，不只市场用户爆发式增加，近15年来网游技术的发展也是无比迅速。和单机游戏不一样，网游除了游戏制做自己之外还牵涉到服务器端，再好的游戏若是出现连接、延迟等问题时也会形成巨大损失，这时候游戏运维便发挥了举足轻重的做用。
中国网游的发展史，其实也是游戏运维的变革史，咱们来看看网络游戏在中国的发展历程吧。
联众桌牌类游戏始于1998年，固然，严格意义上讲，这还算不上网游，真正的网游应该始于2000年开始的《万王之王》和里程碑的游戏《石器时代》；
2002年，《传奇》出现，为网游史添加上了浓重的一笔，也算是中国网游史的分水岭；
2003年，网络游戏被国家被归入863计划，也正式归入管理和审批。
顺带提一下，09年第二季度开始作网游老大、行业第一的腾讯游戏，也在这一年，出炉了第一款游戏，也是一款代理游戏、试水做:《凯旋》……由此开始，中国网游进入百花齐放的阶段。
不难看出，中国网游仍是个孩子，游戏应用运维工程师，更是最近几年衍生的新生职业领域。 随着D/O分离的加速，游戏运维工程师愈来愈多的承担着更重要的责任。
1、有服务器的地方就有运维
现在咱们说到游戏，可能想到的是火爆异常的VR，办公室里一言不合带上眼镜就地开打；亦或是刚刚虐了李世石的AlphaGo，扬言要挑战《星际争霸2》“教主”Flash。然而，除去这些还有一个游戏行业不可避免的潮流正在发生，那即是网络化。
这里说的不止是网游，前不久育碧旗下网游大做《全境封锁》上线时闹出个小笑话：因为不少国内玩家下载以前没注意是网游，下意识的觉得育碧的游戏确定是单机，好不容易下完以后才发现玩不上，进而发生了很多的骚动。这不是第一个发生这种状况的传统游戏厂商，确定也不是最后一个，不少有名的游戏公司都在作相似的尝试，Popcap的《植物大战僵尸：花园战争》系列，暴雪的《暗黑3》等，甚至那些还有单机成分的大做也早就开始网络化：大名鼎鼎的《GTA5》、FPS风向标《使命召唤》系列和《战地》系列，网络联机部分的比重也在一年一年的增长。
网络联机，意味着玩家须要登陆官方服务器，“有人的地方就有江湖”，这句话说的不只是网游里的恩怨情仇，还包括游戏外的种种：“有服务器的地方就有运维。”这即是今天咱们要说的话题——游戏运维。
2、游戏运维编年史
1 石器时代：端游
想要了解现在的游戏运维，不得不从早期的端游运维开始提及。对于08年入行端游，11年经历过页游最后14年全面接触手游的吴启超来讲，这几年的游戏运维经历让他深切感觉到运维思路的巨大转变。
1.1端游的运维工种：IDC运维、系统型运维、网络运维、业务型运维、运维值班等。各个工种分工各有侧重。
IDC运维：装机、换配件、扛着2U的服务器全国各个机房来回跑。
系统运维：安装各类软件，调试各类不兼容的软件，在各类版本的Linux、Windows上。
网络运维：二层交换、三层交换、四层交换，还要区分华为、思科。
业务运维：24点维护，零晨2点维护，零晨5点维护，早上7点维护……
运维值班：0点盯着屏幕打电话，1点盯着屏幕打电话，2点盯着屏幕打电话……
运维开发：写着各类的逻辑，由于业务、网络环境、BUG、刚刚帮忙扛完服务器。
1.2端游运维业务范围：在端游时代，大部分游戏公司都是自主作各类业务环境，作各类游戏业务须要的各类环境。
资产管理：服务器、交换机、各类服务分布位置，端口等。
下载服务器：搭建BT集群，作种子、分发，供玩家下载游戏客户端使用。
静态缓存服务器：squid+apache|nginx
邮件服务器：postfix+sasl+ssl收发服务、反垃圾邮件服务。
网络质量监控：somkingping各个机房的交换，各个安放点服务器。
配置管理：nginx、apache、lighttpd、MySQL。
批量管理：ssh公钥/私钥。
监控管理：nagios、catcai而后是c|perl|python|shell+rrdtool各类业务监控图。
1.3端游游戏服务器架构：通常来说都是以一组服务器集群为一个区服单位，单机上的进程提供不一样的服务。
传统运维，任务道远，正由于有过去那些年的翻译文档，兼顾整合方案，以及大批分享技术的前辈、社区，踩着前辈一步一个坑的走过来，才能有今天的运维的局面。
2.青铜时代：页游
在2011-2013年左右的页游运维，游戏市场处于探索期，其实运维也处于探索期。端游时代每一个新服都要经历上架、装系统，装服务的过程，通常一到两周能够上线一个区服，对于端游高粘性低流动的特性来讲可能还好，可是当页游出现时，转变给运维带来的冲击没法估量。页游时代1天开100多个新服的概念，是传统端游运维所不能理解的。当时的运维认为页游就是把全部服务器实现自动部署服务，同时搭配运维自动部服工具就能够了。但事实上若是在开服时一组一组的使用物理服务器，开服速度根本跟不上，资源浪费还很是巨大，两周后用户留存率仅剩5%-7%。成本巨大亏空，急需技术转型，这个时间点上出现了两种概念影响了之后的手游以及云的发展。
2.1虚拟化技术
在2010年11月份左右，kvm出如今RHEL6中，去掉了RHEL5.X系列中集成的Xen。正是这一次虚拟化技术的转型，并且当时市场的须要，在2011年-2012年掀起了一场私有云建设的风潮。在实践过程当中，优势不少，但暴露的缺点也很多。在端游占主要市场的状况下，实践过程当中表现出来的不适尤为明显。
a.虚拟机时钟不许
b.虚拟机网卡，超负荷down、丢包
c.多虚拟机间争抢cpu、内存
d.多虚拟机间的安全访问，虚拟机与物理机间的安全管控
e.对于关系型数据库磁盘读写慢问题突出。
f.等等
以上几点随着时间的推移有的已经而后解决，有的换上了代替方案。时至今日，端游在单纯的虚拟云上部署还是问题，可是随着物理、虚掩混合云出现，这个局面应该能够被打破。
2.2 社交化的页游
社区化的页游戏，为何这样说呢，由于当时更多的页游信托社区入口，导入用户流量，当时最火的应该是人人网（校内网）的农场偷菜。而后是DZ论坛一堆农场插件袭卷全国，固然这一切都是为了增长用户粘稠度。可是也影响了页游技术的选型，当时基本上你们不约而的选用了于社区相同的LAMP的技术，从而下降开发成本及接入成本。固然现使用JAVASSH2架构的页游也有。除技术选型外，同时还带入了另外一个概念：联运。联运这个概念在页游时代对于端游运维就像一个恶梦，不一样区服要随时跨服站，不一样区服要随时能够合区，全部数据再也不是以物理服务器为单位，而是要逐条打标签，再也看不到帐号，只能拿着一串长长的KEY，四处兑换，而后拿着不知道所谓的表标问第三方…….
在这个时期，是运维开发的爆发年，随着虚拟化技术的推广，越来的越多的运维开始接触自动化运维的概念，开始了自动化运维的奋斗之路，开始了以项目管理的角度看待运维脚本开发。
3.黄金时代：手游
随着私有云转为公有云、云时代推进着云计算以及移动互联网的发展，网游行业慢慢进入了手游黄金时代，云时代的变革不只挑战了整个游戏行业，也挑战了游戏运维。
3.1手游的运维工种：
系统型运维，业务型运维。
3.2手游运维业务范围：
阿里云、亚马逊、UCloud、蓝汛CDN、腾讯蓝鲸、听云监控。
3.3手游游戏服务器架构：
通常来说都是以一组服务器集群为一个平台单位，不一样的集群提供不一样的服务。
手游的架构理念是提供一组虚拟服务器，当短链接的时候，每开一组服，将玩家引导到Web集群，随后被分配到不一样的MongoDB，数据缓存用在Redis。当第一个服务器玩家请求DB时，会落到Mongo1上；当开第二个服的时候，仍是将玩家引导到Mongo1上；以此类推直到运维发现压力累积到必定程度时，便会新开一组MongoDB，Web集群也是如此但只有性能不够时才会添加，通常状况下，每50个新服可能须要添加1个MongoDB。这便实现并解释了当时在页游里但愿实现的快速开服方法。
到此为止咱们已经回顾了一遍游戏运维从端游到页游再到手游的演变过程，不难看出，手游对于区服的架构概念不一样于端游：端游认为一个物理集群是一个服，而手游认为一个Web请求落到相应的数据库上就是一个服。这样的好处是开服合服都简单，若是前五十组服务器须要合并，实现起来很容易，由于同一个DB的数据是互通的，因此只需发一个公告，服务器加标识便可，不须要进行物理操做也不须要数据迁移。
4.游戏运维最强指南
说完了游戏运维的历史，咱们要开始今天的重头戏，如何作好游戏运维？这里就用吴启超的一个冷笑话做为开始：运维为何存在？a，有服务器；b，由于研发忙不过来。无论是笑没笑，运维确实由于上面两个缘由才会诞生的。那么回到正题，想成为玩转上千服务器的游戏运维应该怎么样作呢？系统部运维构建大体以下图：
4.1构建CMDB
21世纪什么最重要？信息最重要！运维所需信息要涉及：机房、物理服务器、虚拟机、交换机、网络、承载业务、业务配置、承载服务进程、端口等信息。无论是本身采购仍是购买云服务，物理服务器和虚拟服务器都作为资产存在，在采购后录入相关的资产管理，给它打上标签，属于哪一个游戏，哪一个平台，这样不一样游戏平台间就不能混用服务器了。而后，是再给不一样的服务器标识它承担的业务角色，好比它是MongoDB，咱们须要打上的标签会是大掌门-APPSTORE-MongoDB-主库-90000端口-第一组服务。这样一个基础信息录入就完成了。
这样的信息只要是用来未来批量化部署、管理服务器使用，以及当出现故障时，运维能够很方便的查询至关的服务器以及服务信息。可是数据的及时性、准确性、可检查是一个难点。
4.2 集中批量化管理
CMDB不是TXT文件，而是要变成EXE文件。运维在面临大量服务器的状况下，批量化工具的出现成为必须的结果，在平常的工做当中须要把其流程固化下来，为完成批量化安装、管理打下基础。大掌门喜欢使用sshsshpassparamikolibssh2这些基础的技术作批量管理。缘由是不用安装简单、稳定、安全、可控。固然吴启超也表示推荐你们使用在市面上流程行puppet、Ansible、SaltStack等技术，为何？简单、简单、简单！下图就是在作自动化半自动化运维过程当中的模型。
批量管理的难点在于：
a.命令的并发执行，要控制各点的超时时间
b.执行过程当中，不一样功能的不一样权限要求
c.数据通讯安全的保证，以及可以正常解析数据指令
d.人员帐号权限管理，权限分发及回收
e.物理服务器、云服务器统一化安装及老项目改造
f.网络质量不可靠的状况下，执行不完整的状况下业务功能回滚。
4.3 性能与业务监控
4.3.1 应用性能监控
一、天天都会对服务器进行上线，升级等操做，每款游戏在一个平台的集群数在几十个到几百个不等（根据平台大小）。所以天天维护和升级服务器压力极大，服务器异常或响应慢等问题的发生会给用户体验带来伤害。?这样的隐患在于一旦发生游戏关服以后就必须对玩家进行游戏中货币和元宝的赔偿，平均每一个玩家补偿的元宝至少在5元以上，游戏币和各种游戏道具若干，以此类推因为服务器故障形成的损失可想而知。
二、大掌门使用了听云Server，可以对服务器响应慢和不可用进行定位，查看慢应用追踪和Web应用过程功能，可以实时定位消耗资源最大的代码和语句，这样就能帮助实时进行有针对性的调整和优化，而且能够快速定位问题时间，最快能到分钟级别。
三、发生高并发、服务器压力激增的状况时，平时运行正常的服务器异常几率大幅增长，平常可能的性能瓶颈点会被成倍放大，这就须要实时定位和解决性能瓶颈点，和提早进行预防改善。通常来讲，传统日志收集方式耗时耗力，效果很是很差，大掌门用了听云Server后，能够进行1分钟级定位能迅速有效发现瓶颈点。同时还结合了听云Network的压测功能，可以在服务器上线前提早发现到高压力下的瓶颈点，提早预防，避免因为高并发出现的服务器瓶颈
四、还有一种性能状况须要提早预防，游戏公司盈利在于玩家的充值，对于官网上从登录到充值全流程的成功率业务部门极其关注，玩家点击跳转的失败会直接致使充值付费用户的转化率。对此，大掌门经过听云Network的事务流程功能可以实时对事物流程进行警报，帮助业务部门提高用户充值的转化率
4.3.2 业务监控
除了性能和硬件监控以外，对于游戏业务运转是否正常也须要创建一套标准去评判。
对此，大掌门开发了一套适用于全公司全部的游戏的统一登录、充值、交易平台，解决了前端的SDK接入的问题，一个全部游戏或第三方的API接口统一接入的平台。在作业务型监控时，运维会要求后端开发人员写一个特定帐号，在访问现有系统时，会完整的走一遍业务流，这样就能够看到须要的业务数字。
4.4 数据仓库搭建
上图为大掌门数据仓库的结构图，因为数据仓库搭建的话题比较大，只是简单的从数据集市的角度来聊聊，DM指的是数据集市。因为数据集市须要面对不一样的人群，所以在数据仓库中须要创建不一样的数据集市以面对各方的查询需求，进而对数据按照业务类型进行分类。
一、财务：关心月度充值数据
二、商务：关心渠道结算数据
三、运营：关心用户登录量、转化率、留存率、平台充值额
四、产品：关心功能热度、用户体验
五、客服：关心全部数据及玩家眷性
对于数据方面，运维的压力来自于须要贯穿及掌握全部的数据，而且为全部部门服务。简单的如下图的ETL为例：
数据对于运维的痛点：
一、日志切割工做谁作？研发仍是运维。日志切割按什么规则？大小仍是日期？
二、使用什么工具进行日志收集？scribe仍是flume仍是sls？
三、数据的准确性谁来保证？日志内容不对、切割不对、传输丢失、入hadoop过滤
四、数据ETL过程监控，若是出现数据丢失怎么办？
五、数据采集怎么样尽量的保证并发的采集，缩短期。
六、数据的出现丢失或错误，总体数据回滚。谁来保证？怎么保证？
七、大量数据下，核对数据丢失状况怎么样核对？用什么方法？
那大掌门又是如何解决这些问题的呢：
一、将数据日志进行切割（按照业务打包日志）并合理命名。好比A登录日志，B充值日志，C消费日志。分门别类进行打包后，对数据每5分钟切割1次，并生成md5包。
二、按照划分IDCRegion。原来从本机向外传输数据会占用大量带宽，对于自己CPU的消耗大的话都会影响游戏的运行。如今按照IDCregion作出划分，每一个区域中会有1-3个中心存储服务器。将切割下来的数据放到中心存储上，划分红Aip一、Aip二、Aip3等md5压缩包，此处无需作合并（缘由见3）。
三、创建下载任务。创建好任务列表后，对每5分钟的压缩包进行下载。考虑到若是上面的步骤作了合并的话就可能会产生在传输的时候丢数据却没法肯定的状况，所以2步骤无需对数据进行合并。
四、将下载后的任务加到Hive数据仓库里。将当天的数据放到MySQL中，以前的数据放到Hive里。当运营提出数据需求时即可以到Hive中下载数据。即便数据出现错误，按照上面创建的每5分钟的任务列表也能够从新以规定时间点将数据压缩包从新拉回来。而且该流程能够按照正向、反向双向进行。
采用5分钟压缩包的另一个缘由在于每台服务器天天产生业务日志大概有5-6G的数据，分到5分钟后，切割完每一个文件就是20M－30M，压缩后只占用不多的空间。这样就解决了占用大量带宽的问题。
五、数据传输后需将数据放到数据仓库（DW）中，数据下载完毕后会根据文件进行存储，当天的数据按照5分钟1个压缩包进入MySQL，MySQL则进入当天的查询。在数据仓库中，数据包按游戏及平台进行分类，这种格局的安排为了在并发时更好的运行。因为游戏与游戏之间是隔离的，所以按照这种模式是为了保证数据进行顺利并发。
3、游戏应用运维工程师的工做现状
一、对待需求：
有的响应需求，处理的很好，但，不懂得加入本身的思想和总结，天天积极的响应，但，久而久之，一直是积极的响应，像一部长期运转的机器……
有的响应需求，但在处理的基础上，分析需求，优化需求，尽量的提高后期处理相似的效率；对于不合理的需求，尽快沟通、协调，固然，这是在充分了解游戏的基础上，能够知道需求能够对项目、对运营带来什么样的影响和做用。
二、对待游戏接入：
有的是要求什么作什么，哪怕以前有游戏运维的经验，也不太去考虑，前期的接入遗留的诟病，势必影响后期的运营
有的分析以前的游戏全部可能出现的风险、对待架构慎之又慎，尽量规避全部后期可能遇到的短板。
三、对待游戏上线维护：
有的只是坚持着、作着，~~~
有的用周边可能用到的一切工具或者资源，去分析全部可能存在优化的地方
四、对待部门流程和建议：
有的不太主动思考，所以总结很少，即便有，也随着随之而来的需求、工做瞬间夭折而去~~~
有的尽量多的去整理合理化建议、共享本身的全部的心得和总结，是交流，也是传承……
五、还有不少相似的点，但，总归一点，就是是否主动
是否主动思考、是否主动总结、是否主动优化、是否主动分享，是否有主动的心，决定一个 游戏运维人员在作什么和他可能提高的高度
4、游戏应用运维工程师的技能和素质要求？
会写脚本、会游戏的发布等操做、能够应付一些突发故障的处理、熟练操做linux就是一名合格的游戏应用运维工程师么？嗯，算，算是入门了吧
那么咱们来看看一名游戏应用运维工程师的技能和素质要求吧
让咱们打开你喜欢的任何一款搜索引擎，去搜索：“游戏 + 运维工程师 ” 去看看目前主流的游戏公司对这方面同窗的要求吧，简单罗列一个，以下:
a、本科以上学历；
b、有一年以上服务器运维经验；
c、熟悉linux/UNIX等操做系统，有2年以上linux平台操做经验；
d、熟悉Shell编程，熟悉Perl/Python者优先；
e、熟悉主流数据库(Mysql/Oracle)；
f、高度的责任心、良好的沟通技巧和团队合做精神，正直进取，有上进心；
g、拥有网络游戏运维经验者优先。
一、技能要求:每条后面都会跟一些注解
若是你翻一下大部分的搜索结果，其实答案已经明了:
A、有运维经验
培养一名真正的运维工程师相对付出的成本是相对较大的，由于，他说来讲去是一个复合型职业，虽然D/O分离弱化了一部分好比开发相关的要求，但，网络、系统、脚本编程、数据库、游戏架构方面的知识等等都须要较多的积累和学习，不然，开始相对较为吃力
B、熟悉或者熟练 Linux/Unix等操做系统，并有比较久的操做经验
系统级的越熟练越有用，固然，基本的命令是必须的
C、熟悉任何一种脚本编程语言
基本上来讲，shell编程基本要精通最好
D、主流数据库，好比Mysql、Oracle等至少要熟悉
也就是说，应用要至少没有问题，固然，优化等能够进行更好了，一些问题定位和处理、最基本的统计、优化建议等等都须要这些。
E、较丰富的安全、网络知识
不少时候，须要依靠这些知识去定位和解决问题
2、素质要求
A、主动性、积极、乐观
为何要把这个排在第一位呢，其实，这个是运维效率提高的根本和对内外部满意度提高最有效果的一个素质，也是前面提到现状里运维人员出现差别和不一样的决定因素；
优化和效率提高须要主动性和积极的驱动；
问题的解决须要主动性；
沟通须要主动性和乐观的驱使；
……
B、较强的沟通协调能力
游戏应用运维工程师面对的接口可能多达十几个:安全组、网络组、DBA（若是有单独设立的话）、运营、策划、研发、周边开发（运营分析系统、应对客服使用的受理系统、周边分析平台）等等，看着这些罗列，就应该不难想象，若是没有较强的沟通和协调能力，游戏应用运维工程师的工做将是很是被动和狼狈的。
C、能熬夜….（彷佛当你真正投入到工做上，不管是开发、策划、运维、或者其余任何职位，不能熬夜的话，估计都是个杯具）
这个嘛，由于游戏的发布多半会选择在在线最低的晚上、凌晨、或者早上，因此，熬夜是必不可少的经历之一了，固然，陪着他们的还可能有测试、运营等；偶尔，半夜被叫起来定位问题，也是不可避免的。
D、绝对强的抗压性与必须的细心、细致和一丝不苟
通过上面种种的介绍，或许已经能够预料到，不管是运营、客服，仍是研发，任何问题必须通过的一环即是游戏应用运维了，在高压的状态下，如何保持清醒的头脑和逻辑分析以及合理安排时间，显得极为重要，更重要的是，须要有在这种高压下持续做战的能力；当一切阻碍被慢慢改进、优化或者消除掉的时候，压力天然会就会少了。成长，也会伴随着这种压力自始至终……
固然，还有一点，他们是admin/root权利的拥有者，他们的一个操做可能使一切天翻地覆，任何的操做可能都须要细心的护航。
E、正直为先
游戏内数据的敏感性你们都已经很清楚；
他们的一丝邪念，修改数据以获取暴利，或许就会毁掉一我的的一辈子（游戏业里由于这个被开掉或者被诉诸法律的也应该有过先例了吧）
但，这种作法和偷窃、抢劫毫无区别，固然，能够经过种种手段去限制和把控，但，防，只是手段而已。因此，正直，必须的条件之一，也是比较隐晦的条件…
F、较强的总结、创新能力
一切为了尽量的提升运营力：质量和效率永远是运营支撑追求的目标。
G、前瞻性
每款游戏都有它的生命周期和发展走向
一切都须要时刻去想着:它会如何？后面该怎么作？目前的这种状态会保持多久？目前的支撑运营能力够不够？是否有优化点？如此种种~~~
H、一颗优化的心（优化和主动，已是反复强调的东西了）
不管是针对产品自己支撑层面的优化，仍是针对整个部门平台或者公共组件的优化（固然，公共的东西，更多的是须要 建议和优化思路）
固然，优化不是一时脑热，也不是豪放和粗狂，是点点滴滴的积累和每日的总结与凝聚的协力。
5、游戏运维职业的迷惘与发展前景
迷惘和职业现状：
游戏运维工程师通过几年的发展，逐渐已经成为游戏上线、运营不可或缺的主要组成部分，并对游戏运营产生比较大的影响和做用。但，目前大部分人对游戏运维的职业仍然会带给人很多迷惘，由于它不像其余诸如游戏研发、游戏策划、游戏美工等职位有很是明确的职业定位和比较明确的职业规划、没有这些职位有较强的职业认同感和成就感。
一、这个职业尚年轻，不少公司还处于成长和摸索阶段，因为起工做特性，可能不少小的公司D/O分离甚至都没有彻底，不少公司的游戏运维工程师还在作着相似机房机器的上架、硬件级的维护等兼职工做。
二、自动化管理还未普及和完备，让这个工做的重复工做相对很大。
三、体系化的理念和技术还在建设和摸索
发展前景：
一、中国网游潜力依然巨大、各游戏公司对有经验的游戏运维工程师的需求量依然会很大
二、运维工程师技术含量及要求会愈来愈高，同时也是对公司应用、架构最了解最熟悉的人、愈来愈获得重视
三、游戏运维是一个融合网络、系统、开发、安全、架构、存储等的综合性技术岗位，给你们提供一个很好的我的能力与技术广度的发展空间
四、运维工做的相关经验将会变得很是重要，并且也将成为我的的核心竞争力，具有很好的架构知识、各层面问题的解决能力及方案提供、全局思考能力等
五、若是真要之后不想作运维了，转到其它岗位也比较容易，由于你所作的就是游戏运营，你所接触的，都是游戏运营的各种角色。这一切依赖你的经验和用心程度。
六、技术发展方向：游戏系统架构师、游戏运维专家
做者：吴启超、Tom，采编自腾讯课堂，感谢做者辛苦付出。
云计算免费课程火热开讲中，运维干货内容免费抢先听，点击文末“阅读原文”便可免费听运维课！固然也有其余IT课程免费听（Java、前端、大数据、Python、设计、C++、嵌入式、网络营销），后台回复“姓名+联系方式+所在+课程名称”也可申请其余免费课程，火速抢先~~~~
PS:记得查收小编送你的免费大礼包呦~
免费领 | 《Shell脚本 100例》电子书免费拿，运维必备干货~
▼▼点击【阅读原文】，免费听5天Linux运维干货分享课，火热开讲中，速来抢！