途遊鄒軼事:中小公司的維運怎麼做?
透過訪談和約稿的方式,請維運領域老砲輸出深刻洞見,共同碰撞,以期形成一些先進的共識,推動行業更好得前進。
這一期我們邀請到的是鄒軼事,途遊遊戲維運總監,鄒總經常戲稱自己是世界500萬強企業的運維代表,可見內心中是覺得中小公司的運維建設想法和大型企業是有差別的,今天我們帶著幾個問題,來請鄒總分享一下他的中小公司研運一體化之路。
這裡是接地氣、有高度的《運維百家講壇》第 6 期,開講!
問題預覽
- 途遊是遊戲公司,您覺得遊戲運維有哪些獨特性?面臨的最大維運挑戰是什麼?您又是如何解決這些挑戰的?
- 遊戲維運的人才技能是什麼樣子的,如果想在遊戲維運方向發展,您對職涯路徑規劃上有沒有什麼建議?
- 中型公司的維運團隊通常不會很大,您是如何對這有限的人力排兵布陣的,有沒有什麼心得可以分享給大家?
- 您是否會遇到因為團隊人才水平不行,導致自己的想法落地慢,落地難的問題,您是如何解決的?
- 您說您特別認同《維運的未來是平台工程》文章中的觀點,您的團隊也是一個產研式的全功能組織,想請您介紹一下:對於業務研發,相比直接使用雲端廠商提供的平台產品,您這個團隊帶來的Delta增益是什麼?
- 您經常說成本節省要硬橋硬馬,節省了大量成本,公司給發個獎狀,說明這個FinOps的項目大概率是在自嗨,在雲上、雲下Infra建設上,您的團隊為公司帶來了巨額成本節省,而且得到了公司的物質獎勵,能否分享一下相關的心得?
- 維運團隊一直是站在公司業務的後面,離業務的距離相對遠,對如何更好的支援業務,或如何說明運維對業務的價值這個點,您有什麼建議?
訪談實錄
問:途遊是遊戲公司,您覺得遊戲維有哪些獨特性?面臨的最大維運挑戰是什麼?您又是如何解決這些挑戰的?
整體遊戲維運架構相對傳統互聯網業務來比較,相對簡單,但是單機可靠性要求比較高,運維日常工作,相對事務性的工作較多,比如開服合服等等。面臨最大的維運挑戰,其實不是技術層面的,更多的是價值認可度層面的,怎麼讓我們業務部門認可我們的價值,這個挑戰我相信也是整個運維賽道同仁們一致的挑戰。要去贏得業務部門的認可,提升維運團隊的價值,從我以及我團隊的實踐來總結,其實就是一句話:紮實的做好服務,以業務部門/用戶為中心。
問:遊戲維運的人才技能是什麼樣子的,如果想在遊戲運維方向發展,您對職涯路徑規劃上有沒有什麼建議?
遊戲維運的人才技能和傳統網路產業沒有太大的差別,對於維運這個賽道來說,認知比較低和缺乏體系的成長環境,是我們中小廠運維面臨的比較現實的問題,我們常年和機器底層打交道,很少去認真思考過,未來10年,15年後的發展,更多的是追逐熱點,追逐變化,很少去思考沉澱那些不變的內容,以及怎麼去利用這些內容來做時間的朋友形成自己的競爭力。我個人建議中小廠的維運同學,還是要在理論方法論學習和技能提升兩手抓,用理論指導實踐,透過實踐完善自己對理論的理解。學習理論和方法這塊,我也提幾點建議:
- 抱持開放的心態去學習,ITIL,SRE,lean,scrum,平台工程,可觀測等等,不要糾結於門派之見,只要對自己有價值的內容,都可以去學習去吸收融合,例如ITIL抓住變更管理、故障管理、問題管理、持續服務改進,這幾個流程去學習並應用於實踐,其實就能解決好大部分維運問題。又例如對SRE的理念的學習,抓住SLO的理念,進行可靠性建設,引導業務部門與維運團隊建立一個可靠性目標共擔的協作模式。而在實踐的SLO落地的過程中,又可以引入可觀測性理念和方法,來加強自己對可觀測性能力的建構。
- 針對國外科技公司學習為主,面向國內大廠學習為輔,國外科技公司的理論和工程方法相對嚴謹和體系,不太受場景限制,可以學以致用,國內的大廠比較偏向特殊場景的實踐,理論和工程方法抽像不夠,基本上都是萬億並發,千億流量的場景,其實和中小廠的運維沒啥關係,中小廠去深度對標學習,價值槓桿率不高。
問:中型公司的維運團隊通常不會很大,您是如何對這有限的人力排兵布陣的,有沒有什麼心得可以分享給大家?
有限的資源,往往容易激發創新,團隊規模可以不大,但是要保持精幹、敏捷,換句話說就是你團隊要足夠能打,而且應對不確定性能力要強,要想達到這個效果,我個人總結了我們這5年的組織能力建設實踐:
- 人才結構要做深度優化,要引進專業產研人才,用產研驅動團隊價值輸出。目前途遊的維運安全團隊,產研和傳統維運比例接近1:1。
- 研運一體化的組織模式去構建,要形成一支全職能,端到端的混合型團隊。目前的途遊的運維安全團隊,有產品經理、研發負責人,前,後端工程師,服務營運工程師,維運工程師,IT工程師。
- 圍繞著互信、目標一致、資訊分享、去中心化去建構敏捷的文化氛圍。透過敏捷的文化氛圍,來形成一個能應付不確定性的敏捷組織。
關於敏捷組織的實踐,可以看我的分享:https://tuyoo.feishu.cn/docs/doccnFlAD2m7WnSpcLYxFJRImZb
#問:您是否會遇到因為團隊人才水平不行,導致自己的想法落地慢,落地難的問題,您是如何解決的?
這個肯定會遇到,我們解決思路:
- #保持耐心,對團隊持續迭代,這個就跟打牌一樣,你不能期望上手一手好牌,這個都得不斷的進出的換牌,最後把牌理順去贏得比賽。
- 對新人的標準是潛力要高於團隊現有70%的人員,不符合標準寧可不招聘,招人謹慎,對人的培養才會用心。
- 團隊負責人自己一定是團隊首席HR,要主動出擊去找人才,我最近4年在BOSS直聘上大概聊過接近兩萬人吧,看過的履歷應該超過2萬多份,這個可能很難有中小公司的維運負責人會做到這一點。
- 利用敏捷組織作為基礎支持,發揮集體智慧。
關於我團隊轉型實踐分享:https://tuyoo.feishu.cn/docx/doxcnGMuijglK6NdENYC2vD7KKh
#問:您說您特別認同《運維的未來是平台工程》文章中的觀點,您的團隊也是一個產研式的全功能組織,想請您介紹一下:對於業務研發,相比直接使用雲端廠商提供的平台產品,您這個團隊帶來的Delta增益是什麼?
在回答這個問題之前,我還是想闡述下我們對造輪子和外採服務的認知:
我們其實對外採還是自研,蠻開放的心態,也是蠻簡單的判斷,就是看ROI的投入產出比,標準化的,投入巨大的,自己搞不定的肯定是盡量用外部三方的服務或者產品來幫助我們解決問題,我們更關注的是如何服務好我們的業務部門,關注我們提供的服務結果和質量,不太關注這個能力是我們自己具備的還是三方的服務能力,只要能幫助我們提升服務品質和效率的,我們都非常開放的心態去吸收和融合。
再來回答這個產研團隊對我們的增益問題,每個公司都有它本身一些特性或者定制化場景需求,這些東西外來產品肯定不能完全覆蓋到位,所以這樣的一支端到端的團隊,其實是讓整個團隊有了解決一些非標問題的能力。這種能力其實非常關鍵,而且很大程度決定了團隊的價值實現。
另外說說我們對維運的未來是平台工程的理解,我對平台工程的理解有兩點關鍵要素:
- 平台工程面向的物件是以業務部門為主,而不是維運為主
- 平台工程提供的是自服務,平台工程輸出的產品和工具一定是業務部門自服務為主
#我們團隊轉型探索,就是主要按照這兩個要素來做的實踐,但是理論水準不夠,沒有清晰的去提出平台工程的理念。我們遊戲運維有一個蠻大的痛點就是瑣事很多,比如CDN的上傳發布,遊戲的配置更新,例行起停服,都是遊戲運維日常的事務,不可或缺,但是都是事務性的,價值很低,可能在我們遊戲維運的常識裡面,我們會想到做一些自動化的工具,去提升運維的人效,把運維從人肉或者寫腳本的狀態,變成WEBOPS狀態,這個感覺槓桿率還是太低,並沒有把運維釋放出來,所以在解決這些問題過程中,誕生了我對平台工程理念的原始理解,目前我們遊戲運維的日常事務性工作有50%都是專案組自服務,透過我們提供的工具,這在我們接觸平台工程的概念後,發現是高度認知一致的。所以對維運的未來是平台工程,我相信只要嚐過自服務的甜頭,吃過人肉運維的苦的同學,應該都會有很深的認同感。
問:您經常說成本節省要硬橋硬馬,節省了大量成本,公司給發個獎狀,說明這個FinOps的項目大概率是在自嗨,在雲上、雲下Infra建設上,您的團隊為公司帶來了巨額成本節省,而且得到了公司的物質獎勵,能否分享一下相關的心得?
對於FINOPS這件事,平時也和業界一些專家老師做過一些交流碰撞,結合我們團隊自己的實踐,我個人感覺FINOPS實踐落地難,難在改變老闆的認知,目前產業還是偏技術實現或理念碰撞階段,還停留在比誰更專業,更規範的階段,個人感覺不能影響到老闆認知的FINOPS,基本上都是無價值,或價值極低,做和不做沒啥區別。對於FINOPS這個領域不過多評價,我們縮小到成本優化這件事來講,在我們團隊我沒有設定過成本優化的OKR,我們一直用精益的理念在指導開展工作,精益有一個核心的理念,一切不產生價值的都是浪費,持續消除浪費, 這樣在工作進行過程中,其實就不用搞運動式的成本優化。很多省了幾個億的成本優化,可能在老闆眼裡就是應該的,以前浪費太大了,現在只是消除浪費,這自然就不會得到價值認可。
成本優化實踐過程中我個人總結了幾點:
- 要用精實的理念去持續指導成本優化,而不是簡單的運動式降本增效。
- 要拉齊價值共識,要和相關部門例如總辦,財務等監管部門達成共識。
- 成本優化的計算模型不能太複雜,模型計算太複雜,很難去達成共識。
- 數據要統一依照財務口徑進行核對,不能我們從技術角度想當然。
編者按:鄒總做成本優化,具體節省多少錢是經過財務最終測算的,個人覺得很值得借鑒,很多公司的成本優化,都是自己測算的,缺乏公信力,老闆較難有體感。
問:這是老問題了,維運團隊一直是站在公司業務的後面,離業務的距離相對遠,對如何更好的支援業務,或如何說明維運對業務的價值這個點,您有什麼建議?
具體怎麼去體現價值,我建議維運團隊要想體現價值,首先是要有服務意識,然後是要對服務體系進行建設,再就是保持耐心和持續改善,透過這個去形成一個正向循環,從而把時間做朋友。
在這塊我簡單分享下我們團隊的服務體系建立指導綱要。我們以客戶為中心,建構安全、可靠、有效率、低成本、永續的服務。透過服務營運輸出價值,透過產品和工具落地服務運營,並持續改善。在這個指導綱要中,我們將團隊裡的維運、產研和營運三個職能角色進行了深度整合。透過服務運營的產出來把價值體現出來。很多時候,做技術的人往往不太容易意識到服務運營的重要性,我們常常聽到人們談論技術運營和產品運營,但很少有人談論服務運營。這與我們做技術出身的慣性認知有很大關係,更多的是站在自己專業領域去表達,很少去站在我們服務對象的角度去看我們的價值。很多人提到服務可能就會簡單聯想到端茶倒水、跑腿這種角色,比較排斥提服務。但實際上,每個團隊都是服務型團隊。例如我們服務項目組,專案組服務我們最終的用戶,我們的最終用戶可能是在他的工作領域服務其他客戶。因此,提供服務是一件非常重要的事情。只有服務好了客戶,幫助他們獲得成果,才能真正體現自己的價值。
擴展閱讀
- #維百家講壇第5期:度小滿陳存利:20年老「司令」聊聊維運、績效、成長
- 維百家講壇第4期:又拍雲邵海楊:25年Linux老兵聊DevOps八榮八恥
- #運維百家講壇第3期:Flashcat來煒:如何把維運的飯碗端穩
- #維百家講壇第2期:作業幫聶安:運維如何轉型,聽聽作業幫的OPaS思路
- #維百家講壇第1期:井源:運維幾何
以上是途遊鄒軼事:中小公司的維運怎麼做?的詳細內容。更多資訊請關注PHP中文網其他相關文章!

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

熱門話題

一、SpringBootActuator端點簡介1.1什麼是Actuator端點SpringBootActuator是一個用來監控和管理SpringBoot應用程式的子專案。它提供了一系列內建的端點(Endpoints),這些端點可以用於查看應用程式的狀態、運行情況和運行指標。 Actuator端點可以以HTTP、JMX或其他形式暴露給外部系統,以便於維運人員對應用程式進行監控、診斷和管理。 1.2端點的作用和功能Actuator端點主要用於實現以下功能:提供應用程式的健康檢查,包括資料庫連接、快取、

曾幾何時,當我還是一名初出茅廬的電腦專業應屆生的時候,在招聘網站上瀏覽了很多招聘貼,眼花繚亂的技術職位讓我摸不著頭腦:研發工程師、運維工程師、測試工程師...大學期間專業課馬馬虎虎,更談不上有什麼技術視野,對於具體從事那個技術方向並沒有什麼明確的想法。直到一位學長對我說:「做運維吧,做運維不用天天寫程式碼,會玩Liunx就行!比做開發輕鬆多了!」我選擇了相信......入行十多年,吃過很多苦,背了很多鍋,弄死過服務器,經歷過部門裁員,如果有人現在跟我說做維運比開發簡單,那我會

隨著網路的快速發展,企業級應用的複雜度日益增加。針對這種情況,微服務架構應運而生。它以模組化、獨立部署、可擴展性高等特點,成為當今企業級應用開發的首選。作為一種優秀的微服務架構,SpringCloud在實際應用中展現了極大的優勢。本文將介紹SpringCloud微服務架構的部署與維運。一、部署SpringCloud微服務架構SpringCloud

過節前我和PG中國社區合作搞了一個關於如何使用D-SMART來運維PG數據庫的線上直播,正好我的一個金融行業的客戶聽了我的介紹,打電話過來聊了聊。他們正在做資料庫信創的選型,也試用了多個國產資料庫,最後他們準備選擇TDSQL。當時我覺得有點意外,他們從2020年就開始在做國產資料庫選型,不過好像最初使用TDSQL後的感受並不太好。後來經過溝通才了解到,他們剛開始使用TDSQL的分散式資料庫,發現對研發要求太高,所以後來就全部選擇TDSQL的集中式MYSQL實例,用下來發現挺好用的。整個資料庫雲

可觀測性一詞源自於工程領域,近年來在軟體開發領域也日益普及。簡而言之,可觀測性是指根據外部輸出以了解系統內部狀態的能力。 IBM對可觀測性的定義為:通常,可觀測性是指基於對複雜系統外部輸出的了解就能夠了解其內部狀態或狀況的程度。系統越可觀測,定位效能問題根本原因的過程就能越快速且準確,而無需進行額外的測試或編碼。在雲端運算中,可觀測性也指對分散式應用系統及支撐其運作的基礎設施的資料進行聚合、關聯和分析的軟體工具和實踐,以便對應用系統進行更有效地監控、故障排除和調試,從而實現客戶體驗優化、服務等級協議

透過採訪和約稿的方式,請維運領域老砲輸出深刻洞見,共同碰撞,以期形成一些先進的共識,推動產業更好得前進。這一期我們邀請到的是鄒軼事,途遊遊戲運維總監,鄒總經常戲稱自己是世界500萬強企業的運維代表,可見內心中是覺得中小公司的運維建設思路和大型企業是有差別的,今天我們帶著幾個問題,來請鄒總分享一下他的中小公司研運一體化之路。這裡是接地氣、有高度的《運維百家講壇》第6期,開講!問題預覽途遊是遊戲公司,您覺得遊戲維有哪些獨特性?面臨的最大維運挑戰是什麼?您又是如何解決這些挑戰的?遊戲維運的人

維運不要學golang,原因是:1、golang主要被用於開發高效能和並發效能要求較高的應用程式;2、維運工程師通常使用的工具和腳本語言已經能夠滿足大部分的管理和維護需求;3、學習golang需要一定的程式設計基礎和經驗;4、維運工程師的主要目標是確保系統的穩定和高可用性,而不是開發應用程式。

透過採訪和約稿的方式,請維運領域老砲輸出深刻洞見,共同碰撞,以期形成一些先進的共識,推動產業更好得前進。這一期我們邀請到的是陳存利,度小滿系統維運部總經理,20多年的職業生涯中絕大部分時間在互聯網領域。在百度維運部期間由於帶隊風格過硬,兄弟團隊稱其為」陳司令」。今天我們請「陳司令」來聊聊他的觀點。這裡是接地氣、有高度的《運維百家講壇》第5期,開講!問題預覽您很早加入了百度,後來隨度小滿獨立,我們了解到您身邊有許多員工其實是很長時間一直跟著您,經歷了很多業務的維運考驗,相信大家都很感興
