手游公司运维主管是怎么炼成的？
入职第一天就和二老板去搬电脑，入职第二天修电脑、安装操作系统，第三天就要直接管理线上的服务器。这之后的每天都是忙忙碌碌。
一边老板要让弄打印机，弄RTX，另一边老大又要让处理线上问题，两头都为难。还有就是游戏频繁上线代码的问题严重得很，又要项目一直没有发布分支，导致很多时候测试刚测好，放到线上就又出问题了，原因是策划那边又改资源了，我这边也要频繁上线。刚开始通过rz,sz将开放打包的代码上传到服务器，后来实在受不了，就想法写了同步脚本，但是频繁登录到服务器去执行脚本，我又受不了最近研究Rundeck，终于实现了在WEB界面去发布代码，后续会写文章讲解。
后来，由于某些原因，项目组原来的成员陆续离职（包括策划，美术，客户端和服务端），工作交接混乱，新来的策划还没有熟悉游戏资源配置，新来的服务端程序还没有熟悉游戏代码，运营那边就催促要更新资源，要发布上线。很长一段时间大家都是处于赶鸭子上架的状态，硬着头皮上，慢慢去摸索。
除了工作交接的问题外，更可气的是原项目组成员隔三差五就捣乱，导致我们经常加班，四处救火。最严重的一次就是去年国庆之前的一天，公司自主运营的几个游戏区服玩家突然都进入不了游戏。这可把我们急坏了，预想了几种情况：
1、游戏服务器遭攻击了
2、竞争对手捣乱
3、Nginx，PHP-FPM参数没有配置适当
4、MongoDB数据库不稳定
请ucloud的技术支持帮忙处理，当天凌晨1点后，确定此次故障为MongoDB索引丢失导致PHP代码查询MongoDB数据库连接超时引起的。之后的一两个月里，几乎一到周末就有某些区玩家进入不了游戏，由于有之前的案例，就再次添加索引玩家又能进入游戏了。奇怪的是，很多服务器刚添加过索引不久，MongoDB索引又丢失了，我们到处高手问，网上查找资料，为什么MongoDB索引会无缘无故就丢失呢？很多高手给的答案就是要么换掉MongoDB数据库要么重新审查MongoDB的表结构的业务逻辑。
当时我看官方文档说MongoDB是内存映射型数据库，我就怀疑是不是由于内存不够导致MongoDB数据丢失的情况，但是明明内存是够的。最后开发同事开始审核代码，最终发现游戏代码里面有后面程序，通过调用PHP的eval()可以执行任意代码，再通过MongoDB的操作记录发现，MongoDB索引丢失的时间段里，有很多删除操作。代码修复后，后面基本上就没有出现过类似事件了。这简直是坑人的节奏，我们为此加了多少班，浪费了多少时间。
为此，我决定以后有空了一定要对开发的线上代码进行关键字过滤。物理机房断电，物理机房调整防火墙，游戏域名没有备案被当局墙掉，公司BI系统遭受CC攻击等等类似的事情还有很多，一个人扛过来了，受益也颇深。
我的脑子每天都在高速运转，如何才能减轻自己的工作量，如何才能提高工作效率，不让自己沉溺于繁琐的重复劳作。
之前在大公司的工作经验让我明白网管这个职位很难进行转岗，因为网管基本上只会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年，是一个充满机遇和挑战的一年，我会更加努力努力去做好自己的本职工作，带领团队成员打造优秀的运维团队。
