lhc彩特码资料127:別黑王者榮耀亂象了!看一看它背后的這些Linux男人的苦事、G事、紀實

生肖码报特码诗138期

生肖码报特码诗138期 www.uiwhx.com 近期因游戲造成全民沉淪論的《王者榮耀》可謂是在風頭浪尖上,超2億注冊用戶、日活躍用戶5000萬、一月超30億元的流水——《王者榮耀》已成為社會現象級手游,隨之問題接踵而來。部分小學生沉迷后為買游戲道具刷爆家長銀行卡、為搶奪游戲中“buff(增益效果)”大打出手。

這些問題怎么產生?

責任又應由誰來承擔?

如何進行有效的防止沉迷監管?

種種問題引發社會廣泛討論

馬哥Linux作為Linux運維的號,我們不想談論《王者榮耀》的對與錯,只想說的是:適當娛樂,不傷大雅。

今天小編帶大家走進這些不為人知的幕后英雄Linux游戲運維的世界,一起窺探這神秘世界的一草一木。

王者榮耀從2015下半年至今取得輝煌成就,正所謂最好的愛情莫過于各自努力彼此成就:),運維這期間是Tcaplus伴其成長,遇到了很多風險和挑戰。

Tcaplus的管理??橛紗媧⒎袢止芾硐低?OMS)和tcapcenter組成,OMS向用戶呈現基于web的管理入口,將用戶的指令轉發給tcapcenter,實際的控制、管理工作由tcapcenter完成,OMS則將操作的進度和結果反饋給用戶。每個存儲集群有一個tcapcenter,而OMS與tcapcenter之間是一對多的關系,因此一個OMS可以管理多個存儲集群。

2、存儲集群是一組硬件資源的集合體,對其位置沒有特別的限制,但按照慣例,同一個集群的節點都應在同一個IDC內,以保證存儲服務的性能。

3、Tcaplus數據服務??櫚墓ぷ髟恚篈PI client連接tcapdir,讀取tcaproxy列表;tcapdir是Tcaplus API使用者在初始化系統時唯一需要提供的信息;tcapdir可以部署多個,以達到容災的效果;API client獲取tcaproxy列表之后,連接所有的tcaproxy進程。用戶發送數據讀寫請求,Tcaplus API根據用戶所指定的表名及key字段信息,決定將請求發送給哪個tcaproxy進程。tcaproxy進程接收到請求消息后,根據其維護的路由表確定目標tcapsvr master,然后將消息轉發給該tcapsvr master。tcapsvr master接收到請求消息之后,進行數據讀寫,并生成響應消息,原路返回經由proxy到達API client. 如果請求消息類型為寫操作,tcapsvr在發送響應之前,實際上還會生成一條binlog記錄,在較短時間內(毫秒~秒級)同步至slave,使得slave可實時維護一份與master相同的數據。

Tcaplus整體架構

回到正題,說一說我們的游戲運維及運維的生存指南和現狀。

一直以來,中國網游在世界上都處于舉足輕重的地位。從最早的端游到頁游再到手游,不僅市場用戶爆發式增長,近15年來網游技術的發展也是無比迅速。和單機游戲不同,網游除了游戲制作本身以外還牽涉到服務器端,再好的游戲如果出現鏈接、延遲等問題時也會造成巨大損失,這時候游戲運維便發揮了舉足輕重的作用。

中國網游的發展史,其實也是游戲運維的變革史,我們來看看網絡游戲在中國的發展歷程吧。

聯眾桌牌類游戲始于1998年,當然,嚴格意義上講,這還算不上網游,真正的網游應該始于2000年開始的《萬王之王》和里程碑的游戲《石器時代》;

2002年,《傳奇》出現,為網游史添加上了濃重的一筆,也算是中國網游史的分水嶺;

2003年,網絡游戲被國家被納入863計劃,也正式納入管理和審批。

順帶提一下,09年第二季度開始做網游老大、行業第一的騰訊游戲,也在這一年,出爐了第一款游戲,也是一款代理游戲、試水作:《凱旋》……由此開始,中國網游進入百花齊放的階段。

不難看出,中國網游還是個孩子,游戲應用運維工程師,更是最近幾年衍生的新生職業領域。

隨著D/O分離的加速,游戲運維工程師越來越多的承擔著更重要的責任。

一、有服務器的地方就有運維

如今我們說到游戲,可能想到的是火爆異常的VR,辦公室里一言不合帶上眼鏡就地開打;亦或是剛剛虐了李世石的AlphaGo,揚言要挑戰《星際爭霸2》“教主”Flash。然而,除去這些還有一個游戲行業不可避免的潮流正在發生,那便是網絡化。

這里說的不止是網游,前不久育碧旗下網游大作《全境封鎖》上線時鬧出個小笑話:由于很多國內玩家 之前沒注意是網游,下意識的以為育碧的游戲肯定是單機,好不容易下完之后才發現玩不上,進而發生了不少的騷動。這不是第一個發生這種情況的傳統游戲廠商,肯定也不是最后一個,很多有名的游戲公司都在做類似的嘗試,Popcap的《植物大戰僵尸:花園戰爭》系列,暴雪的《暗黑3》等,甚至那些還有單機成分的大作也早就開始網絡化:大名鼎鼎的《GTA5》、FPS風向標《使命召喚》系列和《戰地》系列,網絡聯機部分的比重也在一年一年的增加。

網絡聯機,意味著玩家需要登錄官方服務器,“有人的地方就有江湖”,這句話說的不僅是網游里的恩怨情仇,還包括游戲外的種種:“有服務器的地方就有運維?!閉獗閌墻裉煳頤且檔幕疤狻蝸吩宋?。

二、游戲運維編年史

1 石器時代:端游

想要了解如今的游戲運維,不得不從早期的端游運維開始說起。對于08年入行端游,11年經歷過頁游最后14年全面接觸手游的吳啟超來說,這幾年的游戲運維經歷讓他深切感受到運維思路的巨大轉變。

1.1端游的運維工種:IDC運維、系統型運維、網絡運維、業務型運維、運維值班等。各個工種分工各有側重。

IDC運維:裝機、換配件、扛著2U的服務器全國各個機房來回跑。

系統運維:安裝各種軟件,調試各種不兼容的軟件,在各種版本的Linux、Windows上。

網絡運維:二層交換、三層交換、四層交換,還要區分華為、思科。

業務運維:24點維護,零晨2點維護,零晨5點維護,早上7點維護……

運維開發:寫著各種的邏輯,因為業務、網絡環境、BUG、剛剛幫忙扛完服務器。

1.2端游運維業務范圍:在端游時代,大部分游戲公司都是自主做各種業務環境,做各種游戲業務需要的各種環境。

資產管理:服務器、交換機、各種服務分布位置,端口等。

服務器:搭建BT集群,做種子、分發,供玩家 游戲客戶端使用。

靜態緩存服務器:squid+apache|nginx

郵件服務器:postfix+sasl+ssl收發服務、反垃圾郵件服務。

網絡質量監控:somkingping各個機房的交換,各個安放點服務器。

配置管理:nginx、apache、lighttpd、MySQL

批量管理:ssh公鑰/私鑰

1.3端游游戲服務器架構:一般來講都是以一組服務器集群為一個區服單位,單機上的進程提供不同的服務。

傳統運維,任務道遠,正因為有過去那些年的翻譯文檔,兼顧整合方案,以及大批分享技術的前輩、社區,踩著前輩一步一個坑的走過來,才能有今天的運維的局面。

2.青銅時代:頁游

在2011-2013年左右的頁游運維,游戲市場處于探索期,其實運維也處于探索期。端游時代每個新服都要經歷上架、裝系統,裝服務的過程,一般一到兩周可以上線一個區服,對于端游高粘性低流動的特性來說可能還好,但是當頁游出現時,轉變給運維帶來的沖擊無法估量。頁游時代1天開100多個新服的概念,是傳統端游運維所不能理解的。當時的運維認為頁游就是把所有服務器實現自動部署服務,同時搭配運維自動部服工具就可以了。但事實上如果在開服時一組一組的使用物理服務器,開服速度根本跟不上,資源浪費還非常巨大,兩周后用戶留存率僅剩5%-7%。成本巨大虧空,急需技術轉型,這個時間點上出現了兩種概念影響了以后的手游以及云的發展。

2.1虛擬化技術

在2010年11月份左右,kvm出現在RHEL6中,去掉了RHEL5.X系列中集成的Xen。正是這一次虛擬化技術的轉型,而且當時市場的需要,在2011年-2012年掀起了一場私有云建設的風潮。在實踐過程中,優點很多,但暴露的缺點也不少。在端游占主要市場的情況下,實踐過程中表現出來的不適尤其明顯。

a.虛擬機時鐘不準

b.虛擬機網卡,超負荷down、丟包。

c.多虛擬機間爭搶cpu、內存。

d.多虛擬機間的安全訪問,虛擬機與物理機間的安全管控。

e.對于關系型數據庫磁盤讀寫慢問題突出。

f.等等

以上幾點隨著時間的推移有的已經然后解決,有的換上了代替方案。時至今日,端游在單純的虛擬云上部署仍是問題,但是隨著物理、虛掩混合云出現,這個局面應該可以被打破。

2.2 社交化的頁游

社區化的頁游戲,為什么這樣說呢,因為當時更多的頁游信托社區入口,導入用戶流量,當時最火的應該是人人網(校內網)的農場偷菜。然后是DZ論壇一堆農場插件襲卷全國,當然這一切都是為了增加用戶粘稠度。但是也影響了頁游技術的選型,當時基本上大家不約而的選用了于社區相同的LAMP的技術,從而降低開發成本及接入成本。當然現使用JAVASSH2架構的頁游也有。除技術選型外,同時還帶入了另一個概念:聯運。聯運這個概念在頁游時代對于端游運維就像一個惡夢,不同區服要隨時跨服站,不同區服要隨時可以合區,所有數據不再是以物理服務器為單位,而是要逐條打標簽,再也看不到賬號,只能拿著一串長長的KEY,四處兌換,然后拿著不知道所謂的表標問第三方…….

在這個時期,是運維開發的爆發年,隨著虛擬化技術的推廣,越來的越多的運維開始接觸自動化運維的概念,開始了自動化運維的奮斗之路,開始了以項目管理的角度看待運維腳本開發。

3.黃金時代:手游

隨著私有云轉為公有云、云時代推動著云計算以及移動互聯網的發展,網游行業慢慢進入了手游黃金時代,云時代的變革不僅挑戰了整個游戲行業,也挑戰了游戲運維。

3.1手游的運維工種:系統型運維,業務型運維。

3.2手游運維業務范圍:阿里云、亞馬遜、UClou

d、藍汛CDN、騰訊藍鯨、聽云監控。

3.3手游游戲服務器架構:一般來講都是以一組服務器集群為一個平臺單位,不同的集群提供不同的服務。

手游的架構理念是提供一組虛擬服務器,當短連接的時候,每開一組服,將玩家引導到Web集群,隨后被分配到不同的MongoDB,數據緩存用在Redis。當第一個服務器玩家請求DB時,會落到Mongo1上;當開第二個服的時候,還是將玩家引導到Mongo1上;以此類推直到運維發現壓力累積到一定程度時,便會新開一組MongoDB,Web集群也是如此但只有性能不夠時才會添加,一般情況下,每50個新服可能需要添加1個MongoDB。這便實現并解釋了當時在頁游里希望實現的快速開服方法。

到此為止我們已經回顧了一遍游戲運維從端游到頁游,再到手游的演變過程,不難看出,手游對于區服的架構概念不同于端游:端游認為一個物理集群是一個服,而手游認為一個Web請求落到相應的數據庫上就是一個服。這樣的好處是開服合服都簡單,如果前五十組服務器需要合并,實現起來很容易,因為同一個DB的數據是互通的,所以只需發一個公告,服務器加標識即可,不需要進行物理操作也不需要數據遷移。

4.游戲運維最強指南

說完了游戲運維的歷史,我們要開始今天的重頭戲,如何做好游戲運維?這里就用吳啟超的一個冷笑話作為開始:運維為什么存在?a,有服務器;b,因為研發忙不過來。不管是笑沒笑,運維確實因為上面兩個原因才會誕生的。那么回到正題,想成為玩轉上千服務器的游戲運維應該怎么樣做呢?系統部運維構建大致如下圖:

4.1構建CMDB

21世紀什么最重要?信息最重要!運維所需信息要涉及:機房、物理服務器、虛擬機、交換機、網絡、承載業務、業務配置、承載服務進程、端口等信息。不管是自己采購還是購買云服務,物理服務器和虛擬服務器都做為資產存在,在采購后錄入相關的資產管理,給它打上標簽,屬于哪個游戲,哪個平臺,這樣不同游戲平臺間就不能混用服務器了。然后,是再給不同的服務器標識它承擔的業務角色,比如它是MongoDB,我們需要打上的標簽會是大掌門-APPSTORE-MongoDB-主庫-9000端口-第一組服務。這樣一個基礎信息錄入就完成了。

這樣的信息只要是用來將來批量化部署、管理服務器使用,以及當出現故障時,運維可以很方便的查詢相當的服務器以及服務信息。但是數據的及時性、準確性、可檢查是一個難點。

4.2 集中批量化管理

CMDB不是TXT文件,而是要變成EXE文件。運維在面臨大量服務器的情況下,批量化工具的出現成為必須的結果,在日常的工作當中需要把其流程固化下來,為完成批量化安裝、管理打下基礎。大掌門喜歡使用sshsshpassparamikolibssh2這些基礎的技術做批量管理。原因是不用安裝簡單、穩定、安全、可控。當然吳啟超也表示推薦大家使用在市面上流程行puppet、Ansible、SaltStack等技術,為什么?簡單、簡單、簡單!下圖就是在做自動化半自動化運維過程中的模型。

批量管理的難點在于:

a.命令的并發執行,要控制各點的超時時間。

b.執行過程中,不同功能的不同權限要求。

c.數據通信安全的保證,以及能夠正常解析數據指令。

d.人員賬號權限管理,權限分發及回收。

e.物理服務器、云服務器統一化安裝及老項目改造。

f.網絡質量不可靠的情況下,執行不完整的情況下業務功能回滾。

4.3 性能與業務監控

4.3.1 應用性能監控

1、每天都會對服務器進行上線,升級等操作,每款游戲在一個平臺的集群數在幾十個到幾百個不等(根據平臺大?。?。因此每天維護和升級服務器壓力極大,服務器異?;螄煊β任侍獾姆⑸岣沒逖櫬瓷撕?。?這樣的隱患在于一旦發生游戲關服之后,就必須對玩家進行游戲中貨幣和元寶的賠償,平均每個玩家補償的元寶至少在5元以上,游戲幣和各類游戲道具若干,以此類推由于服務器故障造成的損失可想而知。

2、大掌門使用了聽云Server,能夠對服務器響應慢和不可用進行定位,查看慢應用追蹤和Web應用過程功能,能夠實時定位消耗資源最大的代碼和語句,這樣就能幫助實時進行有針對性的調整和優化,并且可以快速定位問題時間,最快能到分鐘級別。

3、發生高并發、服務器壓力激增的情況時,平時運行正常的服務器異常概率大幅增加,日??贍艿男閱芷烤鋇慊岜懷殺斗糯?,這就需要實時定位和解決性能瓶頸點,和提前進行預防改善。一般來說,傳統日志收集方式耗時耗力,效果非常不好,大掌門用了聽云Server后,可以進行1分鐘級定位能迅速有效發現瓶頸點。同時還結合了聽云Network的壓測功能,能夠在服務器上線前提前發現到高壓力下的瓶頸點,提前預防,避免由于高并發出現的服務器瓶頸。

4、還有一種性能情況需要提前預防,游戲公司盈利在于玩家的充值,對于 上從登陸到充值全流程的成功率業務部門極其關注,玩家點擊跳轉的失敗會直接導致充值付費用戶的轉化率。對此,大掌門通過聽云Network的事務流程功能能夠實時對事物流程進行警報,幫助業務部門提升用戶充值的轉化率。

4.3.2 業務監控

除了性能和硬件監控之外,對于游戲業務運轉是否正常也需要建立一套標準去評判。

對此,大掌門開發了一套適用于全公司所有的游戲的統一登陸、充值、交易平臺,解決了前端的SDK接入的問題,一個所有游戲或第三方的API接口統一接入的平臺。在做業務型監控時,運維會要求后端開發人員寫一個特定賬號,在訪問現有系統時,會完整的走一遍業務流,這樣就可以看到需要的業務數字。

4.4 數據倉庫搭建

上圖為大掌門數據倉庫的結構圖,由于數據倉庫搭建的話題比較大,只是簡單的從數據集市的角度來聊聊,DM指的是數據集市。由于數據集市需要面對不同的人群,因此在數據倉庫中需要建立不同的數據集市以面對各方的查詢需求,進而對數據按照業務類型進行分類。

1、財務:關心月度充值數據

2、商務:關心渠道結算數據

3、運營:關心用戶登陸量、轉化率、留存率、平臺充值額

4、產品:關心功能熱度、用戶體驗

5、客服:關心所有數據及玩家屬性

對于數據方面,運維的壓力來自于需要貫穿及掌握所有的數據,并且為所有部門服務。簡單的以下圖的ETL為例:

數據對于運維的痛點:

1、日志切割工作誰做?研發還是運維。日志切割按什么規則?大小還是日期?

2、使用什么工具進行日志收集?scribe還是flume還是sls?

3、數據的準確性誰來保證?日志內容不對、切割不對、傳輸丟失、入hadoop過濾

4、數據ETL過程監控,如果出現數據丟失怎么辦?

5、數據采集怎么樣盡可能的保證并發的采集,縮短時間。

6、數據的出現丟失或錯誤,整體數據回滾。誰來保證?怎么保證?

7、大量數據下,核對數據丟失情況怎么樣核對?用什么方法?

那大掌門又是如何解決這些問題的呢:

1、將數據日志進行切割(按照業務打包日志)并合理命名。比如A登陸日志,B充值日志,C消費日志。分門別類進行打包后,對數據每5分鐘切割1次,并生成md5包。

2、按照劃分IDCRegion。原來從本機向外傳輸數據會占用大量帶寬,對于本身CPU的消耗大的話都會影響游戲的運行。現在按照IDCregion做出劃分,每個區域中會有1-3個中心存儲服務器。將切割下來的數據放到中心存儲上,劃分成Aip1、Aip2、Aip3等md5壓縮包,此處無需做合并(原因見3)

3、建立 任務。建立好任務列表后,對每5分鐘的壓縮包進行 ??悸塹餃綣廈嫻牟街枳雋撕喜⒌幕熬?,可能會產生生在傳輸的時候丟數據卻無法確定的情況,因此2步驟無需對數據進行合并。

4、將 后的任務加到Hive數據倉庫里。將當天的數據放到MySQL中,之前的數據放到Hive里。當運營提出數據需求時便可以到Hive中 數據。即使數據出現錯誤,按照上面建立的每5分鐘的任務列表也可以重新以規定,時間點將數據壓縮包重新拉回來。并且該流程可以按照正向、反向雙向進行。

采用5分鐘壓縮包的另外一個原因在于,每臺服務器每天產生業務日志大概有5-6G的數據,分到5分鐘后,切割完每個文件就是20M-30M,壓縮后只占用很少的空間。這樣就解決了占用大量帶寬的問題。

5、數據傳輸后需將數據放到數據倉庫(DW)中,數據 完畢后會根據文件進行存儲,當天的數據按照5分鐘1個壓縮包進入MySQL,MySQL則進入當天的查詢。在數據倉庫中,數據包按游戲及平臺進行分類,這種格局的安排為了在并發時更好的運行。由于游戲與游戲之間是隔離的,因此按照這種模式是為了保證數據進行順利并發。

三、游戲應用運維工程師的工作現狀

1、對待需求:

有的響應需求,處理的很好,但,不懂得加入自己的思想和總結,每天積極的響應,但,長此以往,一直是積極的響應,像一部長期運轉的機器……

有的響應需求,但在處理的基礎上,分析需求,優化需求,盡可能的提升后期處理類似的效率;對于不合理的需求,盡快溝通、協調,當然,這是在充分了解游戲的基礎上,可以知道需求可以對項目、對運營帶來什么樣的影響和作用。

2、對待游戲接入:

有的是要求什么做什么,哪怕之前有游戲運維的經驗,也不太去考慮,前期的接入遺留的詬病,勢必影響后期的運營。

有的分析之前的游戲所有可能出現的風險、對待架構慎之又慎,盡可能規避所有后期可能遇到的短板。

3、對待游戲上線維護:

有的只是堅持著、做著,~~~

有的用周邊可能用到的一切工具或者資源,去分析所有可能存在優化的地方。

4、對待部門流程和建議:

有的不太主動思考,因此總結不多,即使有,也隨著隨之而來的需求、工作瞬間夭折而去~~~

有的盡可能多的去整理合理化建議、共享自己的所有的心得和總結,是交流,也是傳承……

5、還有很多類似的點,但,總歸一點,就是是否主動

是否主動思考、是否主動總結、是否主動優化、是否主動分享,是否有主動的心,決定一個 游戲運維人員在做什么和他可能提升的高度。

四、游戲應用運維工程師的技能和素質要求?

會寫腳本、會游戲的發布等操作、可以應付一些突發故障的處理、熟練操作linux就是一名合格的游戲應用運維工程師么?嗯,算,算是入門了吧。

那么我們來看看一名游戲應用運維工程師的技能和素質要求吧。

a、本科以上學歷;

b、有一年以上服務器運維經驗;

c、熟悉linux/UNIX等操作系統,有2年以上linux平臺操作經驗;

d、熟悉Shell編程,熟悉Perl/Python者優先;

e、熟悉主流數據庫(Mysql/Oracle);

f、高度的責任心、良好的溝通技巧和團隊合作精神,正直進取,有上進心;

g、擁有網絡游戲運維經驗者優先。

1、技能要求:每條后面都會跟一些注解

如果你翻一下大部分的搜索結果,其實答案已經明了:

A、有運維經驗

培養一名真正的運維工程師相對付出的成本是相對較大的,因為,他說來說去是一個復合型職業,雖然D/O分離弱化了一部分比如開發相關的要求,但,網絡、系統、腳本編程、數據庫、游戲架構方面的知識等等都需要較多的積累和學習,否則,開始相對較為吃力。

B、熟悉或者熟練 Linux/Unix等操作系統,并有比較久的操作經驗

系統級的越熟練越有用,當然,基本的命令是必須的。

C、熟悉任何一種腳本編程語言

基本上來說,shell編程基本要精通最好。

D、主流數據庫,比如Mysql、Oracle等至少要熟悉

也就是說,應用要至少沒有問題,當然,優化等可以進行更好了,一些問題定位和處理、最基本的統計、優化建議等等都需要這些。

E、較豐富的安全、網絡知識

很多時候,需要依靠這些知識去定位和解決問題。

2、素質要求

A、主動性、積極、樂觀

為什么要把這個排在第一位呢,其實,這個是運維效率提升的根本和對內外部滿意度提升,最有效果的一個素質,也是前面提到現狀里運維人員出現差異和不同的決定因素;

優化和效率提升需要主動性和積極的驅動;

問題的解決需要主動性;

溝通需要主動性和樂觀的驅使;

B、較強的溝通協調能力

游戲應用運維工程師面對的接口可能多達十幾個:安全組、網絡組、DBA(如果有單獨設立的話)、運營、策劃、研發、周邊開發(運營分析系統、應對客服使用的受理系統、周邊分析平臺)等等,看著這些羅列,就應該不難想象,如果沒有較強的溝通和協調能力,游戲應用運維工程師的工作將是非常被動和狼狽的。

C、能熬夜….(似乎當你真正投入到工作上,無論是開發、策劃、運維、或者其他任何職位,不能熬夜的話,估計都是個杯具)

這個嘛,因為游戲的發布多半會選擇在在線最低的晚上、凌晨、或者早上,所以,熬夜是必不可少的經歷之一了,當然,陪著他們的還可能有測試、運營等;偶爾,半夜被叫起來定位問題,也是不可避免的。

D、絕對強的抗壓性與必須的細心、細致和一絲不茍

經過上面種種的介紹,或許已經可以預料到,無論是運營、客服,還是研發,任何問題必須經過的一環便是游戲應用運維了,在高壓的狀態下,如何保持清醒的頭腦和邏輯分析以及合理安排時間,顯得極為重要,更重要的是,需要有在這種高壓下持續作戰的能力;當一切阻礙被慢慢改進、優化或者消除掉的時候,壓力自然會就會少了。成長,也會伴隨著這種壓力自始至終……

當然,還有一點,他們是admin/root權利的擁有者,他們的一個操作可能使一切天翻地覆,任何的操作可能都需要細心的護航。

E、正直為先

游戲內數據的敏感性大家都已經很清楚;

他們的一絲邪念,修改數據以獲取暴利,或許就會毀掉一個人的一生(游戲業里因為這個被開掉或者被訴諸法律的也應該有過先例了吧)

但,這種做法和偷竊、搶劫毫無區別,當然,可以通過種種手段去限制和把控,但,防,只是手段而已。所以,正直,必須的條件之一,也是比較隱晦的條件…

F、較強的總結、創新能力

一切為了盡可能的提高運營力:質量和效率永遠是運營支撐追求的目標。

G、前瞻性

每款游戲都有它的生命周期和發展走向。

一切都需要時刻去想著:它會如何?后面該怎么做?目前的這種狀態會保持多久?目前的支撐運營能力夠不夠?是否有優化點?如此種種~~~

H、一顆優化的心(優化和主動,已經是反復強調的東西了)

無論是針對產品本身支撐層面的優化,還是針對整個部門平臺或者公共組件的優化(當然,公共的東西,更多的是需要 建議和優化思路)

當然,優化不是一時腦熱,也不是豪放和粗狂,是點點滴滴的積累和每日的總結與凝聚的合力。

五、游戲運維職業的迷惘與發展前景

迷惘和職業現狀:

游戲運維工程師經過幾年的發展,逐漸已經成為游戲上線、運營不可或缺的主要組成部分,并對游戲運營產生比較大的影響和作用。但,目前大部分人對游戲運維的職業仍然會帶給人不少迷惘,因為它不像其他諸如游戲研發、游戲策劃、游戲美工等職位有非常明確的職業定位和比較明確的職業規劃、沒有這些職位有較強的職業認同感和成就感。

1、這個職業尚年輕,很多公司還處于成長和摸索階段,由于起工作特性,可能很多小的公司D/O分離甚至都沒有完全,很多公司的游戲運維工程師還在做著類似機房機器的上架、硬件級的維護等兼職工作。

2、自動化管理還未普及和完備,讓這個工作的重復工作相對很大。

3、體系化的理念和技術還在建設和摸索

發展前景:

1、中國網游潛力依然巨大、各游戲公司對有經驗的游戲運維工程師的需求量依然會很大

2、運維工程師技術含量及要求會越來越高,同時也是對公司應用、架構最了解最熟悉的人、越來越得到重視

3、游戲運維是一個融合網絡、系統、開發、安全、架構、存儲等的綜合性技術崗位,給大家提供一個很好的個人能力與技術廣度的發展空間

4、運維工作的相關經驗將會變得非常重要,而且也將成為個人的核心競爭力,具備很好的架構知識、各層面問題的解決能力及方案提供、全局思考能力等

5、如果真要以后不想做運維了,轉到其它崗位也比較容易,因為你所做的就是游戲運營,你所接觸的,都是游戲運營的各類角色。這一切依賴你的經驗和用心程度。

6、技術發展方向:游戲系統架構師、游戲運維專家

———有獎評論———

評論獎品:王者榮耀60點券(10名)

公布獎品時間:2017年07月10日

———廣告時間———

《馬哥Linux云計算及架構師》課程,由知名Linux布道師馬哥創立,經歷了8年的發展,聯合阿里巴巴、唯品會、大眾點評、騰訊、陸金所等大型互聯網一線公司的,馬哥課程團隊的工程師進行深度定制開發,課程采用 Centos7.2系統教學,加入了大量實戰案例,授課案例均來自于一線的技術案例。

開課時間:2017年7月10號

限時優惠搶位中———


相關推薦:
別黑王者榮耀亂象了!看一看它背后的這些Linux男人的苦事、G事、紀實

聯眾桌牌類游戲始于1998年,當然,嚴格意義上講,這還算不上網游,真正的網游應該始于2000年開始的《萬王之王》和里程碑的游戲《石器時代》;