【转】手游公司运维之从一个人运维到运维主管

去年阴差阳错地进入了我目前的公司，一家定位于创业型公司的手游公司，公司目前有一款游戏在线运营，还有两款游戏在内测和开发当中。回首在这家公司 工作的这段时光，感概颇深，半年时间掌握的知识是我之前两年多掌握的还要多，在这边工作半年好像是工作了一年半。以前我在大公司的时候，觉得工作时间太清 闲，想要获得更大的发展空间，想要学到更多的时候，更重要的是在大公司，没有存在感和成就感。在大公司，很多东西做得很完善了，我只需要去适应大公司里面 的工作流程，去做那些已经做得很模块化的工作，但是他们是怎么样从一团混乱发展成流程标准化，我不得而知，也没人讲解过，当时就觉得在这家大公司里面，很 多东西都不是我做的，我只是一名简单的运维小工，做些常规的简单操作，于是，我用尽心思去了解运维方面的底层架构，我当时在想，如果我有机会，我一定会亲 手把一个公司的运维部发展成这家大公司的模式。

我去目前公司面试的当天收到两个offer，一个是另外一家游戏公司，有一定规模， 公司大概几层楼，有几百人。还有就是当前这家公司。这家公司的情况是刚成立不久，收购了另外一家公司的项目组，收购的项目刚开始运营，公司缺一个运维人 员，但是干得工作比较杂乱，统管公司的所有的运维工作，又当网管又要管理线上的服务器。当二老板面试我的时候，说我之前一直做的服务器运维工作，但是在这 边既要当网管又要做游戏运维时，我想了想，还是很坚定地说愿意到这边来工作。当时我想，虽然搞桌面维护是我非常不愿意干的事情，但是公司正处于发展阶段， 刚开始难免会苦一点，只要过了这个阶段，我的发展空间将会很大。一周过后，入职的第一天就和二老板去搬电脑，入职第二天修电脑和安装操作系统，第三天就要 直接管理线上的服务器。总之，之后的每天都是忙忙碌碌，好多天都是早上上班带的早餐，等到10点过才顾得上吃，不是帮同事处理桌面服务就是和开发讨论游戏 上线的问题，由于一些原因，项目组原来的成员陆续都离职，包括策划，美术，客户端和服务端，很多部门新来的同事都是不到一周就要被逼接手工作，公司一团混 乱，新来的策划还没有熟悉游戏资源配置，新来的服务端程序还没有熟悉游戏代码，运营那边就催促要更新资源，要发布上线。很长一段时间大家都是处于赶鸭子上 架的状态，硬着头皮上，慢慢去摸索。除了工作交接的问题外，更可气的是原项目组成员隔三差五就捣乱，导致我们经常加班，四处救火。最严重的一次就是去年国 庆之前的一天，公司自主运营的几个游戏区服玩家突然都进入不了游戏。这可急坏了我们，以为游戏服务器遭攻击了，或者有竞争对手捣乱，以为是 Nginx，PHP-FPM参数没有配置适当，以为是MongoDB数据库不稳定，又请ucloud的技术支持帮忙处理，到当天晚上1点过，最终确定为 MongoDB索引丢失导致PHP代码查询MongoDB数据库连接超时，进而玩家无法进入游戏。我和几个程序员都快要哭了的感觉，以为玩家的游戏数据全 坏了，还上什么班啊，卷铺盖走人得了。之后的一两个月里，几乎一到周末就有某些区玩家进入不了游戏，由于有之前的案例，就再次添加索引玩家又能进入游戏 了。奇怪的是，很过区服刚添加过索引不久，MongoDB索引又丢失了，我们到处高手问，网上查找资料，为什么MongoDB索引会无缘无故就丢失呢，很 多高手给的答案就是要么换掉MongoDB数据库要么重新审查MongoDB的表结构的业务逻辑。当时我看官方文档说MongoDB是内存映射型数据库， 我就怀疑是不是由于内存不够导致MongoDB数据丢失的情况，但是明明内存是够的啊。最后开发同事没法了就开始审核代码，最终发现游戏代码里面有后面程 序，通过调用PHP的eval()可以执行任意代码，再通过MongoDB的操作记录发现，MongoDB索引丢失的时间段里，有很多删除操作。代码修复 后，后面基本上就没有出现过类似事件了，他娘的，这不是要坑人吗，我们为此加了多少班，浪费了多少时间，为此，我决定以后有空了一定要对开发的上线代码进 行关键字过滤。物理机房断电，物理机房调整防火墙，游戏域名没有备案被当局墙掉，公司BI系统遭受CC攻击等等类似的事情还有很多，一个人扛过来了，受益 也颇深。刚来公司的时候，一边老板要让弄打印机，弄RTX，另一边老大又要让处理线上问题，两头都为难。还有就是游戏频繁上线代码的问题严重得很，又要项 目一直没有发布分支，导致很多时候测试刚测好，放到线上就又出问题了，原因是策划那边又改资源了，我这边也要频繁上线。刚开始通过rz,sz将开放打包的 代码上传到服务器，后来实在受不了，就想法写了同步脚本，但是频繁登录到服务器去执行脚本，我又受不了最近研究Rundeck，终于实现了在WEB界面去 发布代码，后续会写文章讲解。

在这边工作，我的脑子每天都在高速运转，每天都在想如何才能减轻自己的工作量，如何才能提高工作效率，不让自 己沉溺于繁琐的重复劳作。还有作为运维主管，如何去推动高效的运维，如何制定运维部内部员工的职业发展路线。我在大公司的时候我深切的体会到在一个公司做 网管几乎就只能一直做网管，很难进行转岗，因为网管基本上只会Windows系统，但是就目前来看，学习Windows是没有太大前途的，除非想一辈子做 网管。所以我在公司除了桌面系统推行使用Windows系统外，其他的内部服务全部使用Linux服务器，DNS,邮件服务器，域名代理等服务器，让公司 的网管组同事也能够有一定的发展空间，除了常规的Windows桌面维护外，有很多学习Linux 的机会，以后可以直接转岗到游戏运维。同时为了规范化运维工作，我在公司推动搭建公司内部的WIKI系统，无论是网管工作还是游戏运维工作都要记录到 WIKI系统中，以让新入职的同事能够尽快熟悉本质工作，同事也鼓励公司内部知识分享，将一些工作经验分享到WIKI系统中，逐步完善公司内部的知识库。

2014年我们需要做的工作还很多，去年经历的很多苦逼事件促使我们更快的成长，更快地寻找到适合自己发展的方向。主要有以下几个方面

第一，尽快完善代码上线流程。从过去的完全手动上传代码，到编写shell脚本，再到通过WEB方式去点击，总之，一切目的都是为了提高工作效率和避免重复劳动，运维工程师不应该被这些繁琐重复的劳动给拖累，应该去创造更多的价值，应该花更多时间去研究如何优化流程。

第二，完善监控系统。在过去由于时间精力有限，我只是使用zabbix初步搭建了一个监控系统，对于很多业务层面上的监控都没有做调整，如游戏域名的正常访问，MongoDB监控等。

第 三，所有的Linux服务器统一账号管理。在去年，由于情况特殊，项目开发具有服务器的所有权限，去年我晚上睡觉的时候都担心别人会误操作删除服务器数 据，但是都是使用同一个账号登录服务器的，无法得知是谁登录服务器，所以今年我要仿照之前外企的账号管理模式，搭建OpenLDAP集中账号管理服务器， 对不同人进行访问权限分类。

第四，对上线代码进行审核。在去年，由于前项目组程序员在游戏代码中留后门导致我们经常加班，经常是半夜打车回家的苦逼经历，在今后的代码上线之前一定要对开发的代码进行审核，避免由于有意无意的安全风险。

第 五，和开发同事一起研究如何优化游戏架构。目前每个游戏区服都是使用单独的域名，单独的Nginx虚拟主机目录，然后同样的代码要拷贝多份，每个区服需要 单独配置配置文件，由于程序的架构不支持负载均衡架构。这种方式太坑爹了，既不能合理利用服务器系统资源，运维这边也是干些重复的体力活。在后期我们会考 虑使用HAProxy+Keepalived作为游戏服的前端，然后根据负载情况增加或减少后端的游戏服。这里需要考虑游戏玩家的session会话和应 用日志处理的问题。

第六，深入学习MongoDB和Redis。后面的项目，我们也使用MongoDB和Redis作为游戏的游戏数据库。所以，运维这边有必要深入了解MongoDB和Redis数据库。

第 七，公司内部邮件服务器切换。由于公司是创业型公司，一直使用的是QQ的免费企业邮箱，随着公司的发展，无论是从企业的私密性要求和邮件的收发效率来讲， 使用类似QQ企业邮箱这种免费邮箱会有很多限制和安全性隐患。数据放到自己公司内部才是最安全的，况且部门内部员工邮件沟通走内网也是相当快速的。在去年 我们使用iRedmail开源邮件方案在公司内部测试，我平时除了正式的工作邮件交流使用公司的正式邮箱，其他的邮件全是使用测试邮箱账号进行收发邮件， 如接受zabbix监控报警邮件，注册国外网站使用的邮箱，包括公司内部一些系统的通知邮箱地址，如xwiki系统，redmine，代码发布系统全是使 用测试邮箱账号。从使用状况来看，iRedmail开源邮件解决方案还是比较高效和稳定的，所以，今年我们会抽时间将邮件服务器从QQ免费企业邮箱迁移到 iRedmail邮件服务器。

第八，推进自动化运维。工作第一年我花时间研究了puppet，结果没有使用，现在也没有再去研究了，由于 puppet是使用ruby语言写的，puppet的配置语言和ruby也类似。我决定直接放弃puppet，选用SlatStack作为我们的自动化运 维工具，它由python编写，很方便进行二次开发，同时正在使用的自动化工具Rundeck也可以整合SaltStack,所以，StaltStack 是今年我们需要研究的重点。

2014年，是一个充满机遇和挑战的一年，我会更加努力努力去做好自己的本职工作，带领团队成员打造优秀的运维团队。

转自：http://john88wang.blog.51cto.com/2165294/1370276