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