【轉】手遊公司運維之從一我的運維到運維主管

去年陰差陽錯地進入了我目前的公司，一家定位於創業型公司的手遊公司，公司目前有一款遊戲在線運營，還有兩款遊戲在內測和開發當中。回首在這家公司 工做的這段時光，感概頗深，半年時間掌握的知識是我以前兩年多掌握的還要多，在這邊工做半年好像是工做了一年半。之前我在大公司的時候，以爲工做時間太清 閒，想要得到更大的發展空間，想要學到更多的時候，更重要的是在大公司，沒有存在感和成就感。在大公司，不少東西作得很完善了，我只須要去適應大公司裏面 的工做流程，去作那些已經作得很模塊化的工做，可是他們是怎麼樣從一團混亂髮展成流程標準化，我不得而知，也沒人講解過，當時就以爲在這家大公司裏面，很 多東西都不是我作的，我只是一名簡單的運維小工，作些常規的簡單操做，因而，我用盡心思去了解運維方面的底層架構，我當時在想，若是我有機會，我必定會親 手把一個公司的運維部發展成這家大公司的模式。

我去目前公司面試的當天收到兩個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