梁鳳明-SRE在游戲中的指標設計與實踐-脫敏版.pdf

《梁鳳明-SRE在游戲中的指標設計與實踐-脫敏版.pdf》由會員分享，可在線閱讀，更多相關《梁鳳明-SRE在游戲中的指標設計與實踐-脫敏版.pdf（40頁珍藏版）》請在三個皮匠報告上搜索。

1、SRE在游戲中的指標設計與實踐姓 名 梁鳳明騰訊IEG發行游戲SRE負責人2012年加入騰訊，參與開發多款藍鯨SaaS運維工具和輔助運營工具，同時負責多款大型頭部自研和代理業務的運營規劃工作，先后在業務版本質量、用戶體驗等維度推動專項解決方案落地，主導騰訊游戲版本管理平臺和游戲體驗管理平臺等產品的開發和產品設計，助力業務成功。個人擅長海量業務全生命周期的服務規劃、云原生技術，目前專注于騰訊游戲的SRE體系建設騰訊游戲設計可觀測指標的痛點如何通過SRE視角設計游戲可觀測指標？如何讓指標實踐更進一步？總結與展望騰訊游戲設計可觀測指標的痛點騰訊游戲研發和運營模式騰訊游戲業務主要分為純自研和純代理部分

2、合作研發和委托研發業務游戲開發廠商眾多，開發語言多樣化游戲類型眾多，游戲架構差異大不同游戲間相互獨立，業務場景上差異大指標監控系統繁雜，百家爭鳴游戲業務在指標設計實踐上的巨大挑戰海量數據對平臺數據處理能力和運維配置管理能力提出巨大的挑戰環境迥異物理機、容器、云服務調用關系鏈復雜涉及多項中臺組件接入調用，可用性未知，如何快速了解業務的狀況和精準定位使用成本高昂，故障定位難涉及多個割裂的平臺，不同的數據類型都有獨立的平臺多項組件數據信息孤島，牽扯人員廣泛，溝通效率低，定位效率低維護效率低游戲場景豐富，不同業務間構建游戲監控各異，標準不統一，運維經驗高低，造成運維互備和維護成本高問題思考 采集的指標

3、太少，案發現場無法追溯 采集了非常多的指標看不過來 總是事故復盤后才發現缺少了監控策略 配置了很多監控策略，告警太多麻木了 定位的時候只有Metrics不夠用 運維配置的監控指標，研發和運營認可嗎？茫茫人海中，誰沒有戴口罩？如何通過SRE視角設計游戲可觀測指標？SRE視角下指標觀測數據度量準則measure everythingIf you cant measure your product/component,dont build it運維應關注系統整體的穩定性和可靠性，設計并實現面向SLO服務等級的指標體系架構設計準則提倡左移SRE 可以將從開發到運營的可靠性原則嵌入到每個流程、應用和代碼

4、更改中，以提高投入生產的軟件的質量。SRE 應該在初始設計階段影響架構決策，目標是盡早采取積極主動的措施，以確保從一開始就內置質量和可靠性運維可以通過云原生技術和微服務改造，協助開發進行架構設計和改造，那云原生業務的指標應該如何設計與實踐？SRE視角SRE視角下指標觀測 面向SLO服務等級的指標體系 面向云原生業務的指標體系SRE視角面向SLO服務等級的指標體系功能導向轉變為服務導向噪音小噪音大運維更關注業務整體穩定性指標越是貼近用戶的指標優先級越高從上往下梳理，尋找黃金指標并持續進行優化改進添加監控的最佳地址首先是用戶與應用程序交互的點，盡可能貼近用戶開始監控。-摘自監控運營實踐原則與策略S

5、RE視角下，指標設計和實踐模式問題參與角色輸出簡易方法有哪些用戶？產品用戶列表想為哪些用戶提供服務？哪些是重點用戶提供了哪些功能？產品功能列表所有的產品功能，哪些是核心功能功能的服務等級產品、運營 服務等級站在不同的用戶考慮他們的原始訴求每個功能的SLO？產品、運營 功能對應的SLO基于VELAT方法Volume 容量/流量 Error 錯誤 Latency 延遲Availability 可用率 Tickets 故障單SLO對應的SLI有哪些？SRESLI列表基于黃金指標進行選擇SLI指標如何進行統計？SRE統計方法及指標類型等不同的指標有不同的計算方法，首先計算要可靠才可行核心模塊有哪些？S

6、RE功能模塊進程模塊從功能和進程模塊兩個維度出發核心依賴有哪些？SRE依賴列表從核心功能出發考慮當前架構 有哪些核心依賴。原則是核心依賴越少越好。做好指標監控不只是運維的事情，監控是一項技能，運維應該是教練游戲業務按品類劃分不同游戲品類的功能側重點Play to winPlay for fun重單局FPS(第一人稱射擊)MOBA(多人在線戰術競技)重養成SLG(策略類)MMORPG(角色扮演)/卡牌游戲關鍵監控SLI指標涵蓋黃金指標指標含義對局網絡延遲地域、運營商、平臺、運營商 維度的延遲，以及不同延遲區間的占比。如200ms的占比對局退出分析對局退出原因分析重連率地域、網絡類型維度的重連率掉

7、線數對局掉線數曲線匹配平均耗時不同模式的匹配耗時，可根據此數據衡量模式的質量地圖加載耗時玩家進入房間后，加載地圖的耗時。如果出生點的附近建筑復雜，會增加地圖加載耗時傷害丟失或假紅率傷害丟失對局數/總對局數異常對局率對局中出現異常情況的對局數/總對局數對局收發網絡包比例按對局記錄，同一模式的比列應該是在一個較固定的區間。當客戶端超時時，從延遲指標可能看不出問題，但從此數據可以看出移動偏差位移差、朝向差、速度差用戶平均fps玩家平均幀率，由客戶端上報數據房間容量房間容量對局服務器負載對局服務計算機器的性能評分賽季結算賽季結算段位設置段位和勝點不匹配任務結算堆積一般從消息隊列或者程序數據獲取?？捎^測

8、玩家完成任務后，未結算的情況戰績查詢成功率戰績查詢成功率弱網玩家數占比弱網玩家數占比觀戰創建一般為日志關鍵字監控。指標含義頻道的網絡延遲頻道的網絡延遲頻道切換成功率頻道切換成功率頻道僵死數頻道進程處于僵死狀態，此時進程、端口均正常，但客戶端無法正常連接。通過日志分析得出頻道容量地圖/副本通關成功率核心副本比較關注地圖/副本通關耗時核心副本比較關注，耗時很短的可以用于外掛分析地圖/副本加載耗時副本加載耗時地圖/副本收發包量副本收發包量地圖/副本進入成功率有時進入副本會出現黑屏，只能退出重新登錄拍賣行加載時長拍賣行加載時長拍賣行交易量關鍵道具的交易量拍賣行交易平均價關鍵道具的交易平均價，關注是否有

9、惡意抬價副本平均fps根據玩家的設置，分為高fps和低fps維度重連率斷線重連的情況幀同步的不同步率幀同步技術需要關注，組隊情況下，多個用戶幀不同步，會出現快放追幀、卡頓情況頻道切換時間關注切換頻道超時的情況背包加載耗時背包加載耗時卡牌加載耗時卡牌加載耗時卡牌勝率重點卡牌的勝率曲線。FPS/MOBA類游戲關鍵SLI指標MMORPG/SLG/卡牌類游戲關鍵SLI指標游戲業務的SLO服務等級的指標梳理關鍵路徑支付場景匹配場景對局場景登錄場景游戲SLO設計實現方式 以玩家感受和功能設計為主要目標 從游戲玩家的關鍵旅程、由上而下梳理SLI，覆蓋游戲關鍵路徑和核心場景 以時間維度的度量計算游戲鏈路多個S

10、LI指標的錯誤消耗，形成整體場景的業務穩定性 重視黃金指標對SLO的影響，使用置信區間排除極端異常數據 對于不在業務運維管理范圍內的路徑，通過黑盒監控，定時撥測的方式上報SLO，可以快速定位故障發生點。游戲不同于常規web應用的特點：游戲調用鏈路復雜，調用各類公共組件來實現游戲功能有狀態服務多，業務場景復雜高度交互，玩家的游戲體驗對延遲要求嚴苛指標不是越多越好，而是要準確表現產品的服務能力游戲業務的SLO實踐對應指標的實時曲線，明確不穩定的點具體信息SLO大盤-下半部分提高開發商和項目組對游戲整體穩定性的把控，及時發現最突出的問題點SLO大盤-上半部分收益：多次幫業務快速定位異常，優化服務質量

11、游戲業務間SLO服務穩定性大屏統一數據、橫向拉通、關聯告警游戲端手游SLI/SLO大屏，用于業務間的橫向對比，評估和推進業務整體穩定性趨勢改善，降低MTTR(故障恢復時間)對于長尾業務，SLO作為穩定性衡量指標，如果服務指標層面可接受，可以減少投入和關注，從而實現長尾業務平臺化多業務手游SLO大屏多業務端游SLO大屏案例：可觀測指標設計幫助重大保障提升運維效率和組織籌備能力可觀測工程理念，快速創建騰訊游戲業務監控大屏(設置權限管理)，全局掌握業務信息SLO的下層SLI指標為大屏基礎數據，包含在線、流量、關鍵服務鏈接數保障成果：數百款業務，6日零時整點完成關服，7日零時準時開服挑戰時間有限檢查項

12、多業務量大效果一個大屏全局掌控零故障籌備一天時間一個工具全業務使用玩家在線業務TOP業務出流量業務鏈接數案例：可觀測指標設計幫助重大保障提升運維效率和組織籌備能力SRE保障工具對話服務完成業務指標狀態驗證查詢CLB VIP流量查詢RS流量查詢安全組檢查進程狀態SLO指標實踐小結可觀測工程不是運維單方的事。SLO是業內認可的SRE衡量業務穩定性方案，有助于多方達成共識如何理解SLO優化？游戲代幣補償其實也是一組定義在游戲運營層面的服務目標（SLO）；游戲設定計劃停服變更的時間目標，當出現開服時間延遲后（低于計劃的開服時間SLO），對玩家進行游戲代幣補償游戲優先做穩定性還是做功能的差異？SLO可觀

13、測模式不是設定目標達到最大錯誤預算后，就限制游戲業務的發布變更。主要是要對SLO設置告警，發現根因，驅動優化。在梳理和使用SLO的過程中，實現多個不同職能團隊的有機融合，相互了解大家面臨的問題或挑戰，形成一致的目標，達到有效的協同。但是游戲業務的可靠性始終是游戲精品化最重要的一個特性，如果業務的穩定性收到影響，需要多方推進，優先解決用戶的體驗問題。在這個過程中，最終實現游戲各個工作角色的合作共贏。外部開發商騰訊內部運營SRE視角下，運維能力左移云原生改造SRE提倡運維能力左移，在CI研發階段，通過DevOps及架構優化等方式，來升級運維職能和研運效能2022年，云原生改造游戲業務超過六十款，特

14、別是發行代理業務，其中大部分是運維主動驅動的云原生改造特別是對于發行代理業務，業務間差異巨大，云原生本身很好的規范了開發商的版本交付格式和交付標準、可觀測監控上報標準；通過Helm統一定義環境變量和個性化參數配置，大大降低了維護成本，解決了DevOps生成流水線“最后一公里”問題可伸縮/擴展可觀測發布時效故障定位版本控制/路由灰度云原生業務的指標監控變化Pod的銷毀重建高頻，本地數據容易丟失，如日志資產管理的方式視角不再適合必需綁定k8s的服務發現才能準確進行監控生命周期變短微服務模式，服務數量增多，本身暴露的指標也增多相應的基礎的告警策略也增長明顯，內置策略40+因為工作方式的變更，可觀測的

15、log和trace會更依賴各中間件的指標動不動就幾千數據量級陡增靠標簽維度進行工作，對于技術要求更嚴格非常容易產生高基數據，也非常容易因為使用不規范而觸發存儲問題有些數據只是關聯數據，并不能用于時序數據分析，還沒有配套的DB維度更豐富k8s平臺本身的組件和概念特別多微服務帶來的問題定位難度不僅是對用戶有挑戰，對平臺的挑戰更大平臺及業務復雜度高微服務架構資源動態變化觀測復雜度高工作方式變更研發運維關注的云原生業務的指標資源容量和指標性能控制執行狀況Events 系統事件數據資源生命周期共享集群獨享集群容器管理平臺的管理員業務Kubernetes的管理員Kubernetes使用模式關心的監控對象涉

16、及到數據指標依賴的服務狀況Metrics 指標數據宿主-物理機Node控制平面資源對象Pod內的組件Pod內的應用Traces 調用鏈Logs 日志數據Traces性能EventsMetricsProfiling資源Logs監控平臺幫助云原生業務自動進行指標采集和設置默認策略etcd存儲層etcd是否存活集群通信是否正常請求數的QPS請求延遲請求流量處理成功的百分比apiserver接口層請求延遲(毫秒)請求QPS請求錯誤請求飽和度scheduler調度層請求延遲(毫秒)請求QPS請求錯誤請求飽和度manager控制層請求延遲(毫秒)請求QPS請求錯誤請求飽和度pod調度在哪里資源的生命周期元

17、數據存儲資源的CURD60+指標500+指標200+指標1000+指標ClusterServicePodContainerWorkload DaemonSet Deployment StatefulSet Job CrontJob GameStatefulSet GameDeployment控制平面業務資源對象云原生業務自定義指標監控實踐擁抱并改進Prometheus故障自愈AIOPS大數據計算AI分析跨云區域，獨立部署Pod內應用指標輸出方式：1.直接使用Prometheus SDK 暴露 metrics2.直接使用Prometheus/Opentelemetry SDK PUSH上報3.直

18、接使用HTTP JSON數據上報4.通過log采集+清洗轉metrics監控某業務生成的PodMonitor指標業務如何解決游戲分區的指標上報痛點？游戲分大區，多個集群需要部署多套Prometheus集群，運維管理配置成本高游戲海量數據，如何解決Prometheus的性能瓶頸？場景能力豐富儀表盤可一鍵導入支持更簡易的UI配置支持便利的開箱即用的數據展示功能全復用，如故障自愈和AIOps能力數據協議支持支持prom的數據格式 腳本輸出支持exporter的封裝 不需要重復開發支持多指標計算 PromQL 和 各種函數支持ServiceMonitor/PodMonitor采集能力擴展 支持跨云區域

19、 跨集群傳輸 支持本地pull、遠程pull、push 支持平臺型數據采集 支持不同數據類型的采集Helm chart封裝游戲分區指標采集配置通過bkmonitor operator實現分布式指標采集可觀測指標數據一站式聯動，大大提升研運效能業務進行指標分析時不用在多個平臺間切換如何讓指標實踐更進一步？BKMonitor As Code指標的可觀測能力能不能更進一步？通過自動化方式提升可觀測系統的部署效率，讓可觀測系統像代碼一樣能安全保存，隨時變更可觀測標準范例跨業務可復制參考As Code的思路云原生聲明式管理通過Git分支版本控制數據源、監控面板、告警策略、故障自愈操作均 As CodeD

20、evOps理念（開發和運維一同參與指標的設計和配置，并做到快速發布和迭代）DataSource As CodeDashboard As CodeAlert As Code一個業務運維負責多款業務運維手工配置上百個dashboard需要花費數個小時！分區分服，需要增加區分環境的監控配置Action As CodeBKMonitor As Code實現方案評估自建Prometheus和Grafana的社區方案的問題：某業務上報給Prometheus的指標量級在32w/s以上，自建的Prometheus存在性能瓶頸自建系統的數據量級處理依賴數據源，Prometheus上報只是業務的數據指標采集的一部

21、分，如何整體做監控指標的統一管理？告警能力無法擴展，無法聯動故障自愈配置，對運維操作不夠便利，增加維護難度監控方案As Code方案基于Grafana的解決方案藍鯨監控優勢配置簡單批量管理版本控制對開發更友好可以與編碼結合方便復用和遷移能對接各種數據源社區的圖表可復用基本告警能力具備采集能力具備數據量級大于Prometheus的處理能力可以做計算平臺預處理，數據處理能力強AIOps能力聯動，優化告警Metric-Trace-Log全部打通告警能力豐富可擴展對接自愈等CD生態故障生成和跟蹤場景能力豐富可擴展BKMonitor As Code通過藍盾流水線完成可觀測 As Code批量編輯部署gi

22、t中將監控做聲明式定義和配置通過可觀測 As Code生成的藍鯨監控Dashboard通過可觀測 As Code生成的藍鯨監控Alert告警策略和故障自愈套餐BKMonitor As Code可觀測研運合作新模式，引入GitOps和Everything As Code，將業務可觀測納入版本管理審計并進行持續部署方便版本管理 Git工蜂管理，降低監控管理和維護難度提升業務的研運效率 某業務原本配置視圖或者策略批量變更的耗時可由120分鐘節約到10分鐘以內統一監控，可觀測策略聯動多個監控功能整合至藍鯨監控，Code化生成告警策略，可聯動藍鯨生態下其他系統，完成故障自愈多業務快速復用 方案通用，可以

23、快速clone給其他業務，快速完成監控方案接入如何快速滿足不同業務運維的指標監控需要？平臺的開放化和插件化，藍鯨監控落地游戲業務插件開發基于騰訊游戲tsf4g框架的tbus監控插件SLO穩定性指標獲取插件開發etcd監控插件SSL證書監控插件SRE理念工具開發和自動化如何快速滿足不同業務運維的指標監控需要？賦能運維業務運維自定義快速實現各類組件開發提高運維效率偏于多個業務間實現功能復用，提高運維效率降低開發和維護成本和平臺功能解耦，開發成本低，利于業務的長期使用和維護例：DDoS攻擊告警指標數據監控 某業務的某外網IP遭受的大流量DDoS攻擊，在攻擊流量超過對應運營商出口的封堵閾值或基礎免費防

24、護閾值時，會觸發封堵策略。觸發了封堵邏輯后，經過被攻擊IP的業務流量可能被丟棄，也就是業務可能會受到影響，所以建議業務需要實時告警，并能及時進行相應的處理總結與展望依托藍鯨生態支持多種OS和架構信息標準細粒度權限管理智能分析-大數據跨云區域自愈處理-CD類場景Monitor as Code-CI類場景SRE視角下的游戲指標實踐模式顛覆傳統模式 運維配置，大都依靠運維經驗，或被動接受研發的需求，進行監控配置 監控場景的目標都是提前預設的 不同業務自建監控體系，運維通過藍鯨SaaS滿足業務定制監控需求，個別情況下不利于長期維護SRE視角下可觀測模式 主動發現，服務和功能拆分后的調用關系監控 面向服

25、務等級，SLO指標受到威脅時才需要人工介入，減少告警噪聲，提高運維效率 研運合作模式，引入GitOps和Everything As Code，將業務可觀測納入版本管理審計并進行持續部署，提升業務的研運效率 數據關聯且場景關聯，引入監控的平臺能力和服務場景聯動SLO作為業務穩定性官方指標多個業務已經將SLO模式作為反映業務穩定性的官方指標，用于提升業務穩定性的數據標準，提高問題定位效率體現運維工作價值過去主要面向運維，現在面向業務和外部客戶，建設業務的全面可觀測指標，掌握更多主動性，體現運維工作價值觸達CI、CD、CO全周期的業務場景，運維有能力做游戲全鏈路的把控過去我們只針對運維可用性，承諾運

26、維響應時間和運維服務可用性，現在運維有能力對游戲的整體環節可用性做把控，有針對性的去優化洞察數據指標背后的意義SRE理念幫助運維通過指標梳理，構建立體化場景監控，從而快速定位故障，同時洞察數據指標背后的意義SRE建設中的思考關注成本。數據指標背后的計算，都要消耗服務資源。游戲監控指標的設計，要有實際意義，不要一味的為了大而全無法照搬Google SRE模式，大家對SRE本身有不同的理解，大的建設方向上，取長補短實踐SRE文化，其實是在用軟件工程化的思維，把游戲業務的工作場景工程化，抽離相對通用的方法論、故障解決流程等，向平臺化靠攏，做到可衡量、可管理、可復制，并且持續優化和創新SRE打造的是全生命周期的業務運營管理。和以往發行代理業務的運維模式不同，對于游戲業務來說，運維能力的左移尤其重要，在優化CD環節的同時，從源頭上就不斷提升CI的研發效率和指標監控能力。保證團隊的各司其職，覆蓋每個工程，不斷提升游戲全鏈路的效率Thanks開放運維聯盟高效運維社區DevOps 時代榮譽出品