手游公司運維主管是怎么煉成的？
前言
去年陰差陽錯地進入到這家創業型的手游公司。回首在這家公司工作的這段時光，感概頗深，半年時間掌握的知識是我之前兩年多掌握的還要多。在大公司，很多東西做得很完善了，沒有存在感和成就感，我只需要去適應大公司里面的工作流程，去做那些已經做得很模塊化的工作，但是他們是怎么樣從一團混亂發展成流程標準化，我不得而知，也沒人講解過，當時就覺得在這家大公司里面，很多東西都不是我做的，我只是一名簡單的運維小工，做些常規的簡單操作。由于不甘心這種清閑的工作，想要獲得更大的發展空間，獲得更多的知識。于是，我用盡心思去了解運維方面的底層架構，將運維工作做得更加極致。如今，夢想離我越來越近了。
面試
面試的當天收到兩個offer，一個是當前這個剛成立不久的公司，另一個是一家游戲公司。兩家公司的具體情況如下：
1、 當前公司收購了另外一家公司的項目組，收購的項目剛開始運營，公司缺一個運維人員，但是干得工作比較雜亂，統管公司的所有的運維工作，又當網管又要管理線上的服務器。
2、 另一家游戲公司，有一定規模，公司大概幾層樓，有幾百人。業務系統維護機制相對健全。
二者權衡之下，我還是選擇了目前所在的公司，雖然做桌面維護是我非常不愿意干的事情，但是公司正處于發展階段，剛開始難免會苦一點。但是對于我個人發展而言，還是比較有前途的。
入職
入職第一天就和二老板去搬電腦，入職第二天修電腦、安裝操作系統，第三天就要直接管理線上的服務器。這之后的每天都是忙忙碌碌。
一邊老板要讓弄打印機，弄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年，是一個充滿機遇和挑戰的一年，我會更加努力努力去做好自己的本職工作，帶領團隊成員打造優秀的運維團隊。
