《梁凤明-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 时代荣誉出品