騰訊 自研游戲運維中心總監
騰訊游戲服務“云梯”的服務體系設計和建設第一負責人，專注海量運維、高可用以及自動化運維等相關技術，致力于提升業務運維的自動化，建設運維崗位價值體系。
通過運維服務整體提升團隊核心價值和技術能力，擁有十三年的運維技術實踐和團隊管理經驗，跟隨騰訊大平臺運維成長，深知運維之痛，同時更了解如何從日常運維中，挖掘業務運維核心價值。
前言
筆者在騰訊游戲運維里面除了做好業務運維之外，還承擔一個云梯的建設。這個云梯的團隊核心價值就在于提升游戲運維崗位的價值，助力游戲業務做得更好，并專注于海量運維，高可用以及自動化運維等相關技術，建設運維崗位的成長體系，最終通過運維服務輸出，不斷提升運維團隊的崗位價值和核心競爭力。
1、運維服務再定義
講到運維服務，我們首先要定義下什么叫運維服務。從百度里面查到運維服務，一共分為六大項服務內容，實際上這個應該叫IT服務，從一定程度上來說，這個有點太過于復雜了，而且很難理解。
我這邊濃縮一下，變成一個運維基礎服務：發布、變更、故障處理，+SLA（安全、成本）。為什么 +SLA，因為運維一定要關注安全和成本這兩個要點。
今天給大家介紹我們的定義：“被你的產品或你服務的團隊關注并且可以產生增值價值點，而且是可計價的才叫運維服務+”。
相當于它必須具備三個關鍵點：
第一個是用戶關注；
第二個是能夠增值效益；
第三個是可計價。
可能有人有疑問說為什么是三點，我解釋一下：
運維一直都是在后端默默無聞，典型背鍋俠，既然你要做服務，從幕后走到臺前，那必須做你的用戶—老板、產品負責團隊、玩家（用戶）關注的事情。
做好現在用戶關注的事情并不足夠，只有關注未來，就如股票一樣都是在買未來的增長。
先做好本分的事情，然后再不斷思考和建設可以產生增值效益的事情，因為增值才體現你和團隊的核心競爭力。
做任何事情都是有價值的，如果沒有價值對比，就沒有辦法衡量是否做得好。
可計價也就是有有價值的事情做，才能夠使得團隊更有動力。
2、騰訊游戲運維服務體系
講完這個大家可能會覺得說好像有點道理，但也挺虛的，那我們來看看實戰。
正式開始實戰介紹之前我們來介紹騰訊游戲運維服務的整體構成。一共包括六大塊服務體系：用戶體驗、運營活動、運維成本控制、運營咨詢、版本服務和整個業務安全的保障服務構成。
六大服務模塊下面還分了19個子服務，今天我不會將19個子服務一一向大家介紹。我一共介紹三個案例，也是不斷進階演進的服務案例。
3、服務實戰檢驗—游戲行業開合服
首先看一個在游戲行業大家最熟悉的開服和合服。開合服是干什么的？
其實開合服最先是在頁游時代出來的，是里面最簡單最直接的手段。最先在我們行業叫滾服，是一個產品運營接的，可以減少玩家之間平衡度的問題。同時可以減少一些內容創作的工作量，同時也可以通過導流的方式拉到更多的收入。
3.1 游戲行業開合服的特點
對于運維層面來看，一共有四個階段，分別有各自的特點：
上線初期
第一個是上線初期，業務剛上線，開服，這個時候導量速度非常猛，需要人力盯著導量情況，新區的開放也一般是人工判斷，手動執行。
導量穩定期
第二個是導量穩定期，這個業務進入平穩期了，每周會有基本固定的放量，可以不需要人工操作，通過業務設定注冊量，到量后自動開新區，有的業務則會固定每周的開放時間。
精細運營期
第三個是精細運營期，通過之前積累的數據，產品運營跟蹤開服后的效果，調整開服時間，開服策略，運營策略等。達到既能讓老區玩家對游戲的某些玩法還能夠順利進行，同時后來新進的玩家追趕起來也不至過于困難。
合服期
最后是合服期,單服人數低于某個量后，玩家流失速度會非常快，游戲中的一些核心團隊 PVP 玩法也會受到影響，業務一般通過合服降低流失。
3.2 開合服要完成的重要事項
這背后運維要做什么，最直接簡單的就是做開服的動作。騰訊游戲運維做了什么事情？
我們首先做到了手動開服，在智慧雪球項目組通過人工點擊開服按鈕，調后臺任務自動完成大區對外開放操作，然后是自動開服，最后做到定時開服。
自動開服會有一個問題，達到這個閾值的時候你有可能是半夜三更，也可能時間并不是項目組想要的市場導量的時間點，你把這個服對外了，但這個量上不來，自然這個服就變成鬼服了。
三個節點里面，目前整個騰訊游戲運維做到的自動化程度還有技術實現程度，在2016年最新的統計數據中，整個效率做到了5分鐘之內我們能夠將一個服對外。
3.3 開服向更高進階
如何服務進階？做技術的天天看曲線，這條曲線有沒有什么特點？
這個曲線上，在線 PCU 和注冊人數兩個曲線基本上很吻合，這個就是一個開服期間最容易出現的情況，就是在線跟注冊人數同樣速度在增長的，因為這個游戲很火爆。
大家做運維都很清楚一點，你的在線的承載和你的注冊數肯定不是一一對應的，比如注冊可以注冊到5萬人，但是在線撐死只有1萬人。這會帶來什么問題？
最大的問題是這個新服很容易在過兩天之后就變成鬼服了，比如前期你的注冊達到1萬的時候你的 PCU 也達到了1萬，按照我們之前定的三個場景，必然會觸動你的自動開服或者定時開服，因為玩家進不來，你不開這個量就流失了，市場就沒了。
這個好像挺無解的，我們運維干了一件事情，我們從原來的開一個服，我們把它變成了一個池子，這個池子就是當注冊和 PCU 達到一定量級的時候，我們將這個服關閉推薦，而自動推薦其他服。
推薦服是什么意思：大家玩游戲可能都會注意到一點，新手登進之后，會有個默認推薦服在那里，你自然會點進默認推薦服。
所以下次當你看到上面這條曲線是上面這個情況的時候，你可以把幾個服做成一個池子去推薦，避免瞬間撐滿，而是均衡灌滿。右邊這個流程是我們的整個自動推薦服的流程圖，5分鐘自動輪循一次，達到這樣一個效果。
這時候你的項目組會非常買你做的事情，因為你干的活好像不是很復雜，但是解決了他們一個很大的痛點，他不需要一開服就合服。
3.4 合服向更高進階
講完開服的服務進階我們再講合服的，合服這個就相當于前面的一些鬼服把它合在一起。
最正常的一個工作流程是這樣的。項目組運營團隊會提交需求，開發團隊會提交數據合并工具，因為合服最大的工作量就是把數據庫里的數據做合并，你有很多社區、社團或者玩家的角色名稱，你要把它合并在一起，開發必須提供數據合并工具。
運營團隊會提供一個N合M的過程，有可能是2合1，有可能是3合1。大部分的運維同學會收到這樣一個表格，xxx服務，活躍多少，合并到什么樣子。這是普通的運營團隊會給我們的數據報告。
做得好一點，他會給我們一個這樣的報告，因為什么原因，從幾個維度上看，分別選取，像日活躍、開服小于多少天的區服列表等，拿到之后，運維團隊會挑選合適的服務器，這個是我們該做的。
接下來運維執行工具，做數據合并，然后正式對外開服。
整個運維的工作里面，最大的工作量就在數據合并的過程，有很多會出錯，特別是做 DBA 的兄弟，肯定天天吐槽合服的事情。數據合并特別是在騰訊這樣數據量特別巨大的情況下，我們目前能夠做到的2016年的場景是2到3小時能夠完成一個服的合并動作。
當然包括完成所有數據的清洗包括重新導入的，包括處理數據異常的過程。周而復始這樣去操作。這樣一個服務其實只能說你做好了本份的事情，整個增值的效益完全沒有體現在這里。
既然做服務，看一下在騰訊游戲運維里面是怎么去做的，這個是目前我們真正的合服的流程圖。
首先可以看到，我會根據項目組給我們的條件，會幫他們做一些篩選大區，比如說 PCU 小于多少，DNU 小于多少，活躍付費率小于多少的大區，篩選這些大區屬于需要去合并的大區。
篩選完之后根據一些組合，我們不希望項目組只是通過很簡單的 excel 表格去做，我們會去幫他做開服天數相近等來進行合服的組合，給項目組推薦哪幾個合服組合是合適的。
最后會給到一個合服后的數據分析對比。這些數據我們做更好一點，我們會把這個數據放到合服預估里面去。
為什么叫合服預估？因為合服是一個周而復始的過程，你做得更好一步，你需要把這個定期推給項目組。
這個是我們內部的截圖，會根據他的規則選擇條件，當他有數據異常的時候會提醒他出來，會標示出哪些是符合規則、哪些不符合規則的。這些是項目組現在關注的，因為你幫他解決工作效率的問題，但那是不是就足夠了？做完這個還不夠，我們需要關注整個項目組未來能夠做得更好的一點是什么。
做游戲有一個非常大的關鍵，如果你理解這個游戲業務的話，你會發現，如果想讓這個服合并之后會效果更好的話，其實你需要去考慮，合服里面的用戶，不只是說你只把 DAU、客戶、付費能力相加一起就可以了，因為你還需要讓玩家保持經濟平衡或者社區平衡，引入這些因子之后，你對運維的技術挑戰提升就會要求高很多。
你需要在組合里面考慮這些因子，我們怎么做，在這里面我們引入了大數據的算法，目前用聚類的算法，幫項目組聚類出哪幾個服的戰力平衡、經濟水平平衡，通過這個推給項目組，這個是我們整個合服的進階。
接下來整個合服之后的效果對比，我們會跟蹤他的 PCU、DAU 的數據對比變化，給項目組更好的決策數據。包括 DAU 的分布、ARPU 值的收益分布等。
這是我們上線半年來我們做到的收益，我們已經累計給項目組節約了260個小時，我們的推薦區服已經被使用了7368次，詳細效果如下：
3.5 服務建設過程中的幾個問題
在整個服務建設過程，我們都會很怕產品團隊提很多需求，因為做IT的實際上是不斷在挖產品需求，你一旦開始挖產品需求了，就會帶來一個問題，產品團隊他的需求會不斷的變化，他也會有自己很好的想法給到你。
我們從服務開發者的角度或者服務建設者的角度上講，他會從集成平臺這里，開發者中心，開發者框架，給我們快捷的支撐。
同時剛才大家也看到前面的服務建設里面，我們會用到很多的原子和功能，在下面這個作業平臺里，有豐富的原子層，能夠讓我們組合起來靈活快速。
4、向外部產品的用戶延伸—版本服務
講完這個服務以后大家還是會有疑問，剛才講到的都是服務于內部用戶的，既然你想從幕后到臺前，只是讓你的產品團隊、你的老板都知道這樣還是不夠的，最好的方法是你能夠服務于你產品使用的用戶，那才是最能夠從幕后走到臺前。延伸到產品的用戶，怎么做？這里不講太多廢話和道理，直接來看案例。
從內部到外部，我們通過一個版本服務案例講一下，這個案例大家可能會更容易理解一點。
4.1 版本服務在日常發布中的應用
因為做版本，只要做運維的都接觸過，不像前面的開合服，只有做游戲的才會有這種業務場景，離開了游戲其實很難有這種業務場景。在做版本服務，做發布這個事情上，我們可以做什么？
還是看一條曲線，這個曲線有個非常簡單的特點，紅色的線是發布日的曲線，黑色的線是平時的業務曲線，這兩個點是我們運維最關心的點，就是發布時長。從2012年的3到4個小時到2016年的0.88個小時我們可以完成一個版本的發布對外。
實際上來說這是不夠的，我不是說發布時長我們優化得還不夠，而是我們做運維來說，我們關注得還不夠。因為關注的只是產品中你目前知道的事情，本份的事情。哪些是產品關心的事情？產品關注收入、DAU，一個在線恢復時長才是產品最關注的事情，在線恢復得快，DAU和日常的DAU是一樣的。
4.2 版本服務在線恢復中的應用
在線恢復快，玩家的在線時長也會同樣加長，比如說你等到晚上8、9點鐘玩家才能進到游戲，你的在線恢復到正常水平到晚上8點鐘，還是說你上午一發布完，中午玩家就進來了，其實這是有本質上的區別的。
看一下騰訊游戲運維是怎么做在線恢復時長提升的，因為你一個版本發布了，玩家進不進來是用戶決定，純粹由用戶的行為決定。
分析一下，玩家什么時間喜歡上來玩游戲，更新版本包時長，這個還跟成本關聯，同時自動化程度也密切相關。
首先，我們再深入分析一下這個怎么去做，會有個版本發布時間，選在凌晨幾點鐘發還是在高峰期發，這個也看你運維的技術能力，你敢不敢在高峰期發和在高峰期來臨之前發，這是不一樣的。還有更新包投放時間，這個包你是提前發出去還是在版本發布同時發出去。
第二步是投放自動化，還有更新的成本。用戶更新包所需要的時長，分發量和用戶增量的問題。在四大因素里面，我們游戲運維是怎么去影響他們的。大家可以看到，在在線恢復時長優化里、在包投放時間還有投放自動化、分發量做一些優化，會有幾大方面，分發量和成本會由閹割的完整包和更新包分解拆包。
一個游戲版本如果對外的話，會分兩類玩家，一類是新玩家，一類是原來的玩家做更新的。閹割版的你在發布之前幾天就可以對外發布了。
另一個問題，更新包的拆包解包，那么更新包是什么？
做過游戲行業可能會了解到一點，它除了那些程序腳本之外，其實有很多資源，很多時候美工團隊或者音頻團隊已經做出來了，如果運維團隊愿意把這個事情做一些拆分的話，你可以提前把這個更新包拆分出去，讓玩家預埋到已經在他電腦里的版本里去，這樣直接減少分發量和成本的問題。
在時間點上，預下載的自動推送和錯峰時間點的預判，這兩點會直接決定你的成本還有你預下載的效果。預下載就是說你的玩家在玩游戲的時候，他可以預先把你的資源下載到本地來，這是一個很成熟很簡單的技術，你是自動推送的還是人工盯著的，這個差別還是蠻大的。
另外一塊是根據玩家的平均在線時長去計算預下載投放的時間。
當你的玩家的在線時長是2小時、3小時或者6小時，實際上會決定你的投放時長，因為你的資源包的下載是需要時間的，你不可能以全速的速度下載，因為玩家玩游戲，你全速下載會占他的帶寬，你可以根據你平均下載的速度，根據你的游戲體驗去決定。
這時候你會算出100M的更新包，如果玩家每天平均在線2小時，你要提前多少時間放，這是很精細的計算的過程，時間點的掌控對運維來說，不再是以前你放一個包過來就往上丟。
還有用戶增量的問題，用戶的增長速度，這個游戲版本非常好玩，用戶增量會非常大，你怎么控制這個增量，通過預下載多渠道推送，通過大區灰度、用戶灰度，P2P 增量。
整個體現了在版本服務里面，在運維團隊里面怎么去做精細化的運營，不只是說你把自動化做好就足夠了。
4.3 我們的收益
看一下我們做完前面的事情之后有什么收益，在用戶增長和包量增長上，在2013年和2016年增長2倍的情況下我們的在線恢復時長壓縮到了原來的90%，同時這個帶寬成本下降了50%。
這個事情做的不僅漂亮，而且老板覺得你給整個業務團隊省錢了，是非常合適的事情，拿這個業績匯報給老板看，老板會很嗨。
怎么做到，可以看一下，這里傳統的就不講了，業務ABC會把版本需求推送給我們，正常來說(黑色字體)我們會做一些部署的動作，成本監測，完整包管理等。
我們會做用戶數據、推送時間、自動推送、灰度控制、拆包的自動建設的能力，不一一介紹了，依托藍鯨會做自動化調度的能力，會達成整個游戲版本服務技術架構的特點，更多是一些功能模塊。整個服務是由這些框框組成的。
4.4 我們不曾止步
看到上面的版本服務和開合服的案例，大家可能想蠻不錯了，因為它有三個特點都滿足了。
用戶關注，包括剛才說的版本服務，玩家可以很快的進到游戲里面來玩耍，一進來更新時間又短，花在版本更新的帶寬也少。
老板也關注，玩家也關注，增值效益也有了，助力提升 DAU、在線時長，收益還不錯，在兩年多的時間里我們壓縮到了只有10%在線恢復時長。
可計價當然是 ok 的，每一個用戶進來之后產生收益是 ok 的，因為你影響了在線時長，每個用戶的在線時長在商業里的數據是可以依托的。
我們覺得還不夠，我們碰到一個核心的問題，剛才看到特別是前面那一頁版本服務建設的框架里面，會有一個問題，這個問題有四個特點
特點一：環節緊扣
每個服務環節緊密相扣，不管是前面的像表格一樣的方式還是后面的框架圖，都會發現它整個環節非常緊扣，密不可分。
特點二：依賴業務運維
它非常依賴業務運維某個人或者某個團隊的某幾個兄弟對這個業務的理解。
特點三：更加復雜變化的需求
因為你做好了現在這一步，你除了能做發布變更、自動化部署之外，你還能幫助我們去影響 DAU 和在線恢復時長。這樣項目組就嗨了，他們覺得他可以給你提更多的需求，更加復雜變化的需求，他會想能不能給我加點不同的用戶等級，怎么去給用戶更好的更新版本的體驗。
特點四：成本控制
然后是成本控制，還是有很多人為的因素在里面。
5、實戰進階引入微服務新應用—下載服務
5.1 微服務初探
這里面我們引入了一個東西，叫微服務框架。
左邊這張圖是微服務框架很簡單的示意圖，微服務有三個特點。
去中心化
解耦合
可以獨立演進。
為什么引入微服務框架？
因為這三個特點可以去解決我們前面的這四個核心的問題。同時，架構、框架這些東西讓運維團隊的可以比較好理解。
當你跟他講一些代碼級的東西，他很難真正去理解，做運維和做后臺開發的兄弟還是有思維理解上的區別的。
這時候我們看一下在微服務引入之后，我們怎么讓服務進階。微服務引入之后我們解決了三個問題。
一個是服務的分解，這里跟藍鯨的支撐框架不一樣的一點是，我們這個不是原子的，我們是單單的一個微服務，完全是一個獨立可運作的服務內容。
第二個是消除依賴
第三個是可以成本細分
我們可以演進成下面這些點，而且可以隨意組合。比如有些項目組說，我不想要那么復雜高大上的功能，就要包制作和版本管理就可以了，把這個服務給到項目組就 ok 了。
項目組覺得我不需要版本管理，我只要包制作實時數據，或者更多，通過預下載渠道投放，希望能給玩家更好的體驗，可以這樣去組合，或者需要更多的東西，包括防盜鏈跟蹤、異常用戶跟蹤。
一個是服務分解，每個都是獨立的微服務，第二，依賴關系完全沒有了，第三個每一個都可以獨立控制成本。
5.2 下載服務微服務優化
下載服務引入微服務之后，會從左邊的只有原來的四大塊管理，包制作、版本管理、成功率跟蹤、成本限速，右邊是除了做到原來的，拓展了包制作的功能之外，包括智能限速，用戶等級、單用戶、地域這些。
我們還做到一點，可以在異常用戶里做到單用戶級包括用戶分級的能力，整個服務可以不斷往前去拓展。
像用戶分級里面有專屬的禮包、專屬的 VIP、用戶關懷，對單獨的用戶做白名單限制，實時數據里可以根據用戶的等級、地域去做，整個服務的拓展會更加靈活更方便。
5.3 我們引入微服務后的收益
引入之后可以達到幾個效果，一個是靈活，可見收益。因為每個服務都是獨立可以看到效果的。
還有獨立計價，獨立演進，還有拓展能力，上面那個圖是非常方便的，可以隨意往下或者往左右兩邊去擴展你的服務。
做完這個之后我們的收益是怎么樣呢？
首先，玩家下載完成率我們提升20%，下載完成率是產品運營團隊關注的玩家的下載時長，這個是玩家關注的，玩家下載時長下降60%，一個玩家下載一個版本包花的時間只需原來的40%就 ok 了。
另外老板比較關心的成本，我們在整個事情中成本消耗增加是0。顯然好像還不夠，還算了一個收益，因為我們不可能去導流用戶過來，不可能吸引用戶過來，但是我們可以在這個階段讓玩家不要流失，用戶成功下載完以后就能讓玩家進入游戲，這樣就提升了游戲的轉化率。
5.4 更進一步—禮包分發服務
如果說我們還想進一步提升轉化率和下載成功率，我們能怎么去做，達成一個服務進階？
服務你既然做出來了，你的項目組、你的團隊，會給你更高的要求，你自己也希望更進一步。這里會有一個影響，你要關注下載取消和不轉化的用戶。這個時候我們想到一個東西，你要讓下載取消和不轉化用戶，再增加一點東西吸引他，看行不行。
這時候我們想到一個游戲道具禮包，這個也不太復雜，這也是項目組給我們提的要求，希望說這個時候你能不能再增加一點東西，我們多投一點市場成本是 ok 的。
5.5 禮包問題的三座大山
禮包不是一個小事，這是一個市場資源進去要投放的東西，我們解決哪些問題，你必須有精準定位，給誰發，什么時候發，發什么東西。
接下來大家可能會想，這不是營銷該干的事情嗎，營銷團隊他可能來說可以幫我們制作禮包，但是在運維環節給誰，什么時候投和投什么，投什么可能他們比我們的專業度更好一點。但給誰，什么時候投放完全是由我們運維團隊決定的。
怎么去做呢，首先做這個事情你需要去關注理解你的業務，簡單一點，你怎樣給玩家投，會有兩個特性，一個是老玩家，一個是新玩家。
WHO？
解決 WHO 這個問題，我們會有用戶分級，可以看到玩家的等級與付費的關系，玩家的等級越高，付費率就越高。因為我們需要決定給誰發的問題，是給高等級的玩家發還是給低等級的玩家發。
再看左邊那張圖，玩家等級成長分布圖，中間有掉下來一個點，在130級，這是某款游戲的數據，130級的玩家很難升級，這時候如果來了一個老玩家，是個老用戶，他剛好在120級左右的時候，那你給他發是最合理的。
這個很簡單，其實就是數據分析的過程，所有做運維做技術的其實就是做數據分析。
WHEN？
要解決什么時候發的問題，因為玩家下載過程是個動態的過程，我們引入“智能+”，就是運維大數據的建設。
首先通過取消玩家下載完成比例的數據分析圖，看到一個玩家基本上會在10%以內或者15%之間取消掉下載。這個區間其實還很大，我們提煉幾個關鍵的因素，玩家目前下載過程中的當前完成率和當前耗時，都是當前而不是歷史。
左邊這張圖是歷史數據分析出來的取消的規則，右邊這張圖是實時數據取消的規則，還有當前下載的速度。
通過這個會形成一個拉格朗日函數，再用一個 SVN 向量機的方式找到一個分類的超平面，因為你三個因子可以去定義一個分類的超平面。通過這個你可以去劃分一個玩家有可能取消的平面。
在實時下載過程中，這三個因子數據我們實時運算出來，越靠近這個超平面的時候，越不需要給他發禮包，當他離得更遠的時候，更需要給他發禮包，因為他有可能就真正的流失了。靠這個平面他有可能會從取消變成完成。通過實時運算獲取玩家下載過程中的取消概率，這個是我們解決的 WHEN 的問題。
WHAT？
解決發什么的問題，剛才前面提到不同等級的玩家，需要給誰發的問題。這個實際上在大數據里面也沒有別的算法。基于隱因子模型的協同過濾推薦算法，確定正在單個下載玩家的禮包內容。
結論舉例，在下載為 1879KB/S、當前進度為 5%、已下載10分鐘的玩家，在進度 8%、15% 和 30% 會分別發送XX禮包。在運維領域看起來有點害怕，但實際上就看你敢不敢跨界用了。
5.6 “禮包+智能”效果展示
我們整個騰訊游戲運維也在慢慢跨向現在的智能化的時代。做完這個之后，有什么效益，我們在原來基礎上將下載完成率提升了 8%，轉化率在原來基礎上再加9%。還不錯的，也讓運維的兄弟會覺得自己不只是說我就天天做個包往外分發，看看 CDN 的成本數據。
我會關注用戶怎么從我所負責的環節流失走，我怎么能拉他回來，用一些營銷手段，也會看到我們下載的實時數據里面怎么去給項目組更好的技術上的優化和解決方案。
6、“智能+”&“微”服務
目前我們整個服務的走向是“智能+”，以“智能+”的技術和解決方案去推進我們微服務不斷往前拓展。這個微服務除了微服務框架之外，有個特點，就是無微不至，我們希望通過我們運維團隊提供給用戶無微不至的服務。
舉例一下我們無微不至怎么去拓展，比如像下載服務可以不斷往下拓展。
像安裝登錄服務也可以不斷往前拓展。包括開服服務，手動開服和自動開服，在上線初期和運營期，哪些是可以做的，哪些是關注的。
包括最下面的，戰力的差距，你開了一個新服的時候，當戰力的差距不夠的時候，我們會跟銷售說這時候你應該給玩家推送一個禮包。
騰訊游戲運維服務進階，剛才提到像智能化還有貼近業務之類的，我們整個運維團隊需要具備六大能力項，需要有感知、分析、決策、執行、呈現，非常關鍵的一點是保護。
另外還有兩個關鍵點，一個是整個團隊的文化，還有一個是人才結構的培養。
同時我們濃縮了六個字母，為了讓運維更好的記憶和理解，“CEBTOS”，貼近業務、理解業務，關注用戶的體驗，在質量效率成本方面找一個均衡，以技術導向為優先。
上面所有案例都有核心技術在里面，這里面也會體現你的團隊的技術競爭力，擁有運營能力，同時你最終的產出，給用戶看到的都是服務，并且需要非常關注安全。
微信掃一掃
