2011-09-19

OLG_OP - 網遊維運工程師

網路遊戲的流行算算到現在也有十多年了,網遊玩家們在組隊打怪推王撿寶時若是遇到lag、斷線、當機、回溯、修不好時很多人的第一個反應是工程師又出包了,也有人說是工程師在機房吃泡麵的時候不小心踢到線了。但是很少玩家真正知道遊戲公司的工程師平常都在幹些什麼?這就以過去幾年所看到的情況來大致描述一下遊戲維運工程師的工作。

在稍具規模網路遊戲公司維運工程部門中通常會有 系統 / 網管 / 資安 /資料庫 工程師 來負責維持服務的正常運作,下面就總稱為 維運工程師 ( Operation Engineer / OP ) 。網遊維運工程師跟開發單位的遊戲程式設計師所扮演的角色不同,遊戲程式設計師主要是負責開發遊戲,遊戲程式寫好以後交給營運單位(代理商)進行維運,一般遊戲內出現Bug漏洞大多數屬於程式開發端的問題,營運單位的工程師們基本上是沒有修復的權限與能力,而維運工程師一般來說也只能針對遊戲營運的後端網路/系統/主機架構進行最佳化;加上每款網遊的系統及網路架構都不同,維運單位只能配合開發單位開出的需求來建構,所以維運工程師負責的工作多又雜,往往幹起事情來還綁手綁腳的。網遊維運工程師的宿命就是遊戲穩定運行時也會有一堆雜事,一但命不好遊戲出了意外狀況就會被操到翻掉,而且維運工程部門屬於花錢單位又不能直接創造獲利,在公司角度的屬於無法開源只能盡量節流的單位。
接下來就以網遊代理商的角度為例來看看一款網路遊戲從開始到結束的過程中,維運工程師們都在幹些什麼:

一、前期評估:
代理前:通常網遊公司決定是否要代理/營運某款遊戲時都是先看遊戲的賣相,前期開發單位提供可供評估的技術資料一般都很少(屬商業機密),開發商也不會在談判階段就把遊戲先天限制跟缺陷告知代理商(甚至原廠自己都不知道),往往給的一些數值(像是一組伺服器可以同時容納多少玩家)都是理論值。維運工程師只能從少得可憐的資料中初步評估需要用到怎樣等級的硬體,要達到公司訂定的目標(同時多少人上線)需要多少台主機,大概會耗用多少頻寬,來試算出一個大概的成本供高層進行決策。
確定代理後:維運工程單位與開發商進行進一步的技術轉移合作,要到此時才能取得比較詳細的技術規格好規劃後端要達到營運目標實際所需的設備及架構。接下來維運工程師就要開始列出清單向硬體廠商採購(或租賃)伺服器、網路設備等,等機器到貨後到機房進行上架佈線工作。順帶一提的是大部分的網遊公司都是將主機代管於網路業者的IDC機房中,只有少數財大氣粗的業者才會自建機房,因為在IDC機房內環境又冷又吵不適合長時間作業,所以維運工程師在把伺服器上架作業系統搞定網路配置好以後就回公司辦公室了,日常管理操作一般都是遠端連線維護;而且稍具規模的IDC機房出入管制非常嚴格,所以基本上不會有在機房吃泡麵踢到電線的情況(但是因為IDC機房機櫃配的電源排插老舊接觸不良導致稍微大力關個機櫃門就會讓機器跳電的情況是真的有發生過)。

二、測試階段:
公司內部測試:此時一般會先有一到兩組的內測伺服器架設完成,同時跟遊戲改版(中文化)一起進行,企劃單位向開發商提出修改需求,開發商修改好後把程式交給維運工程師放到伺服器上運行,接著企劃單位再上去驗收測試,接著針對測試結果提出修改報告給開發商,開發商再修改再傳回來,如此的過程週而復始經過多次之後才會喬出一個大致堪用的版本。此階段維運工程師就是不斷地與原廠交換內部測試時發現的技術問題,同時之前下單採購的伺服器差不多這時也到貨了,工程師們便要到機房開始進行體力勞動(伺服器開箱、設定、組裝、上機櫃機架、佈線整線)。
封閉測試階段:待公司內部測試到大致堪用之後,就會配合行銷宣傳活動對外發放限量帳號開始封閉測試,此時通常也會有一到兩組的封測伺服器對外開放並告知參與封測的玩家在測試結束後會將資料清空,為了要在封測時能取得更廣泛的測試結果一般會要求原廠先將遊戲難度調低好讓參與測試的玩家能在短時間內快速升級。這時候維運工程師就必需隨時盯著封測伺服器的狀況,盡可能的在早期挖掘出各種潛藏的系統問題來要求原廠在正式上線前進行修正;同時也會刻意將主機數量或相關系統設定參數縮減來進行壓力測試以取得伺服器最高承載的實際數值。EX:假設原廠宣稱一組伺服器可以承載3000個玩家同時上線,根據經驗通常在封測階段實測下來能到原廠理論值的八成就該偷笑了,一般來說大概到了八成(2400)就會開始lag,而撐上九成(2700)就嚴重降低遊戲品質,這時候維運工程單位就有了一個日後擴充加開伺服器的評估資料標準,通常在理想情況的允許範圍以不發生lag的數值作為安全上限。同時在封測期間維運工程師也會需要規劃建立起一套維運狀態即時監控的系統來隨時掌握主機及網路的運作狀態,以便在發生異常時能夠即時找出問題點盡快排除,若有餘力的話維運工程師也會進行網路/系統的最佳化調整。此時工程部門也要依據測試得到的經驗來整理出一份緊急狀況處裡的SOP(標準作業程序)以因應日後可能發生的各種突發狀況,包含異常狀況查找排除、災難回復及資料備份復原等等的作業守則。一般來說在封測時因為事務繁雜又有上線時間壓力所以這階段對於維運工程師來說是最操的。
公開測試階段:當決策單位評估封測時的修正達到可接受的穩定狀態後,便會將封測資料清空開始進行公開測試。基本上現在遊戲營運商的公開測試就等同正式上線完全開放用戶進入了,維運工程單位就要配合PM行銷宣傳計畫及實際進入的玩家數量來逐步加開伺服器,當然這時所需的機器大部分都是事先就準備好了,要是一個不小心爆紅超出預期的話還得緊急追加伺服器,那又是一陣兵荒馬亂了。另外因為公測後就不刪檔了,所以維運工程師們只能祈禱遊戲中的嚴重bug都在封測時修完了(實際上當然是不可能的),也要隨時監看運作狀態,並彙整出營運資料及遊戲數值分析供PM作為後續行銷決策的評估參考。

三、營運階段:
當一款網路遊戲進入營運階段就代表後端運作相對穩定,此時維運工程師主要工作就是持續監控運作狀態,異常狀況緊急排除,全天24小時待命,配合原廠進行修正及改版,每次改版前的測試及準備,新版客戶端程式發布,例行停機維護,資料備份及回復,客訴查詢...等等。
其中最讓維運工程師頭痛的就是突發異常狀況的處裡,因為網路遊戲都是全年無休不間斷運行的,所以得24小時待命以備不時之需,而且隨時都有可能發生意外,凌晨當機或是硬體壞掉三更半夜衝去機房處裡都還是小事;要是突然爆出洗錢洗裝備之類的bug,由於營運端只能蒐集證據資料反饋給開發原廠進行修改,若影響層面大到嚴重破壞整體遊戲平衡時,甚至可能需要立即停機避免災難擴大並評估是否需要將資料回溯,當然回溯是殺傷力最大也是公司跟玩家都最不願意見到的,所以最可能的結果就是苦命的工程師要在成千上萬筆的遊戲資料庫跟遊戲歷程log紀錄中找出有問題的帳號進行個別處裡,若是此時原廠在後續支援上不夠積極的話就真的是個惡夢了。
除此之外還有像是盜帳號,遊戲寶物失竊的客訴處理,過去原廠在初期開發時通常不太會考慮到這方面的需求,此時維運工程師往往就得自己搞出一套遊戲歷程log查詢跟資料分析的系統來應付那些層出不窮的客訴問題,在協助處裡客訴的過程中常常是花了大把時間交叉比對物品交易紀錄與對話紀錄後發現被謊報或者只是朋友之間共用帳號沒喬好帳號,在不然就是被異常IP登入盜用,要是查到最後是這類有案可考的結果其實都還好,就怕是在幾千萬筆遊戲歷程中都查不出異常時往往就代表遊戲中可能隱藏了某個嚴重的漏洞,那就是惡夢的開始了。
至於平時例行停機跟改版時工程師都在幹些什麼,又是另一個故事了。

四、衰退階段:
網路遊戲的生命週期一般的情況都是在剛上線過陣子被炒熱後玩家人數最多,接下來隨著競爭出現、改版進度過慢或是系統出過大包等原因造成玩家數量會逐漸減少,此時在營運成本考量下就會開始被要求進行一些節流工作;像是縮減分流或是合併伺服器都是常見手段,這就牽涉到遊戲後端架構的問題,若只是縮減分流一般就還好,改改設定撤掉伺服器就搞定;比較麻煩的是伺服器合併,因為開發商在開發遊戲時通常不會考慮到這個部份,這就需要營運單位提出進行合併計畫後拜託原廠在不破壞既有資料結構跟遊戲平衡的前提下生出相關工具來作資料整合處裡,這在技術面就需要維運工程單位跟原廠不斷溝通協調,而且往往合併之後出現意外異常狀況的機率不低,然後工程師們就又陷入了 發現bug->回報->修正->測試->上線->發現新bug 的惡夢循環中。

五、打完收工:
當遊戲上線人數少到不足以支撐支出或是與原廠合約結束決定不續約時就會有關閉遊戲伺服器的情況發生,這時維運工程師就等決策單位下決定後安排時間去機房把伺服器撤掉,撤下來的機器設備就看其他遊戲是否用的上或是當作備援機待命。一般來說都會依成本考量將硬體資源運用最佳化,也就是把好一點的新機器給熱門遊戲用,較次等的機器就交給步入衰退階段的老遊戲使用,所以有時會發現進到沒什麼人玩的遊戲伺服器還會lag,那就有可能是用了其他遊戲退下來的老機器在扛。當然這個硬體資源重新調整的動作對維運工程師來說也是很累的,因為這樣喬來喬去對機櫃配置跟網路架構等的改動幅度不會小,而且通常只能搶時間抓停機的空隙來調整。

上面描述的只是一個大概,實際上還有不少沒提到的事情,像是在資安防護上與駭客的攻防更是刺激,不過那塊太黑暗了也不能說太多。而隨著這幾年網遊生命週期縮短及獲利萎縮的情況下,網遊公司都會精簡人力,這樣一來維運工程師都得身兼數職且幾乎沒有什麼喘息的機會,常常是這邊剛忙完封測那邊就要撤機器,這邊公測跑一半就接著得評估下款新遊戲,甚至是同時兩三款遊戲一起推出。要是一個運氣不好遊戲出了意外狀況,不管最終查出來是誰的錯,玩家們第一個問候的往往都是維運工程師的媽媽 ╮( ╯_╰ )╭ ... 。
所以基本上從事網遊維運工程師這份工作需要的是無止境的熱情配上大顆的心臟新鮮的肝跟堅強的意志,最後在這邊給仍堅守在此崗位上的網遊維運工程師們鼓勵一下,各位辛苦了!

2011-09-14

2011-09-14 PLURK bye bye

一句話, 不爽不要用 ,簡單不囉唆
PLURK bye bye

噗浪選戰肥皂箱


這新功能斬斷了我對噗浪的最後一絲留戀~ 881 ~ 祝你們好運~


P.S. 現在只是停用不像以前是屍骨無存的徹底刪除,不給力啊 XD



2011-09-05

2011-09-05 Apple 取消 App Store 付後七日服務條款?

前情提要: 2011-06-27 偉哉台北市政府幹掉了Google台灣的Android Market付費區
時至今日都兩個月過去了北市府與Google之間針對付後七日的問題依舊無解。

而回頭看看 2011-07-14 北市府法規會的新聞稿
消保重大進展 蘋果依北市府要求 賦予手機APP消費者七日退費權

裡面提到
"葉慶元主委表示,蘋果今日在其App Store的定型化契約中新增了七日內退費條款:「您得自產品收受之日起七日內,取消對產品之購買。在您通知iTunes您已刪除產品所有備份之前提下,iTunes將會退還您已支付之價款。自您取消購買時起,您不再被授權繼續使用該產品。此項權利不可拋棄。」(http://www.apple.com/legal/itunes/appstore/tw/terms.html)此一修正明確地依照臺灣消保法的規定,賦予消費者七日內退費的權利,值得肯定。"

BUT...

眼尖的網友在2011-09-04發現台灣專用的 AppStore 條款約定 中,之前配合葉狀師修改的付後七日條款不見了!!!

中文版 http://www.apple.com/legal/itunes/appstore/tw/terms.html
第三方備份 justaple Sep 5, 2011 11:21:43 AM 快照

英文版 http://www.apple.com/legal/itunes/appstore/tw/terms-en.html
第三方備份 justaple Sep 5, 2011 11:21:56 AM 快照

而之前 08/29/2011 的網頁快照
第三方備份 justaple Sep 5, 2011 11:27:43 AM 快照

英文版 網頁快照
第三方備份 justaple Sep 5, 2011 11:27:54 AM 快照

兩相對照一下可以發現

之前那一段葉狀師大張旗鼓引以為傲並以此質問Google「為何Apple能Google不能的」的付後七日條款消失了~
AppStore 條款約定 底下的最後更新退回到 06/21/2010 (有加上付後七日的版本最後更新日期為 07/13/2011
從快照日期 08/29/2011 來看,在當時的條款還是有付後七日規定的,但之後不知道何時被改回舊條款?

這個rollback的情況到底是AppStore網站單純的技術錯誤還是說葉狀師被Apple給婊了一道?

2011-09-07 update:
蘋果的 付後七日 又回來了回來了回來了~回來了~回來了~
還好當初有用第三方服務 justaple 頁面 XD