2025 GOPS 全球运维大会暨研运数智化技术峰会·深圳站:腾讯IEG SRE应急响应实践_第1页
2025 GOPS 全球运维大会暨研运数智化技术峰会·深圳站:腾讯IEG SRE应急响应实践_第2页
2025 GOPS 全球运维大会暨研运数智化技术峰会·深圳站:腾讯IEG SRE应急响应实践_第3页
2025 GOPS 全球运维大会暨研运数智化技术峰会·深圳站:腾讯IEG SRE应急响应实践_第4页
2025 GOPS 全球运维大会暨研运数智化技术峰会·深圳站:腾讯IEG SRE应急响应实践_第5页
已阅读5页,还剩41页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

腾讯IEGSRE应急响应实践吴海洋2025-04腾讯IEG公共平台SRE负责人,高级工程师,2013年加入腾讯,先后担任逆战、QQ飞车等多款重点端、手游运维负责人。目前专注游戏

平台、公共组件平台SRE支撑体系建设等相关工作。吴海洋腾讯IEG公共平台SRE负责人1

游戏应急响应的目标和痛点2

基于蓝鲸基座的应急响应方案建设3

执行应急响应的思考和经验4

总结和展望:故障的可控目录/CONTENTS游戏应急响应的目标和痛点现状:•研发团队:自研和代理•游戏架构:模块多差异大,发行区域:国内和海外,全球发行•支撑平台:

BG内、

BG外平台服务•规模大:单游戏体量和整体体量特点:•上下游涉及服务、人员多(多组织,多角色)•

异构性非常强•

运营环境复杂GO

PS

会2

0

2

5·深圳站

腾讯游戏的特点● 故障发现故障诊断故障恢复故障复盘

告警时间

响应时间定位时间操作时间1min5min15min5min

15min30minGO

PS

会2

0

2

5·深圳站环节关键场景其他场景

腾讯游戏应急响应的目标故障发生

开始处理告警● 故障发现故障诊断故障恢复故障复盘

GO

PS

会2

0

2

5·深圳站告警时间

响应时间定位时间操作时间1~5min

5~15min15~30min

腾讯游戏应急响应的痛点资源约束、互相影响、衍生故障….快速执行?环节目标关键痛点人员多、信息乱、有依赖....有效信息高效协同游戏异构、场景多、链路长、环境复杂、跨组件平台

….故障发生

开始处理全准?经验预案监控告警?

为了应对故障,我们曾经做过的尝试告警优化:•基础设施:CPU、内存、磁盘、

IO、网络

…•业务服务:调用量、成功率

…•用户体验:登录、下载、更新、支付、单局、卡顿

…•

综合SLI/SLO架构优化:•冗余、容错、负载均衡、在线更新、在线伸缩、功能解耦、过载保护

…部署优化:•服务模块跨机房、跨城容灾建设,包含接入层、逻辑层、数据层

…•网络:多运营商、IP+域名、

HTTPDNS、探测调度…预案建设:•自动化流程、资源储备、故障自愈、混沌工程

…GO

PS

会2

0

2

5·深圳站故障案例二背景:游戏A6/11

日发布客户端资源热更新,更新后出现登录成功率下降。事故过程:6/10

15:00~15:30登录组件运维按计划执行某一模块升级,灰度和全量期间观测无异常。6/11

16:00游戏A发布热更。6/11

16:08~16:14游戏A运维收到登录异常告警,期间登录组件运维也收到游戏A登录异常告警,经排查发现自身服务成功率无异常,同时周知游戏A时,了解到A刚发了热更,遂认为是版本问题,于是等待A业务修复。6/11

16:15~16:40游戏A运维和研发联合排查,期间排除了新功能的影响,定位到用户的异常均在登录模块中的lua脚本,而该lua脚本这次没有改动,且和本次版本更新内容没有关联,并且只是部分玩家出现异常。6/11

16:41游戏A寻求登录组件帮助,组件运维联系研发进行排查。6/11

16:42~16:50登录组件研发经排查,发现后台存在某些异常的ID有一直在发起登录请求,也成功返回了数据,但是却没有登录成功,确认是由于A游戏本次更新触发了6/10组件升级带来的BUG导致。6/11

16:51~16:56登录组件运维紧急回滚版本。6/11

17:00游戏A登录异常逐步恢复。故障案例一背景:游戏A

11/7日发布了新版本,客户端版本新增了协议,会放大存储层压力,11/13日A业务活动放量,导致存储层proxy模块CPU持续100%,引发故障。事故过程:19:56游戏A运维收到告警,显示“用户登录失败超过阀值”,遂联系负责登录后台的开发同事

第一时间核查和解决。19:57-20:30游戏A运维、研发协同存储层负责同事一起排查,期间尝试重启游戏后台服务、对服务进行降级等措施,暂时恢复了登录,但是部分游戏功能依然受到影响。20:30-20:35

存储层服务团队定位到一台proxycpu100%,遂立即进行扩容。20:40扩容完毕,业务A逐步恢复

……..事故原因:……………..proxy模块CPU100%却无告警核查结果:告警策略配置了但未生效,导致没有触发告警。………………GO

PS

会2

0

2

5·深圳站

建设应急系统之前的情况不是很理想故障影响>40+min故障影响近1h协同问题:•

经验协同、口头协同•没有及时周知业务进行处理(研发、运营)•游戏场景中服务链路的某个服务异常,上下游服务没有及时协同处理(各自处理)处置问题:•

诊断时间过长•

恢复时间过长告警问题:•配置问题导致告警没有告出来•

配置问题导致告警延迟•告警太多,导致忽略了重要的告警•没有配置告警,导致问题没有及时发现•人员没有接到告警(环境因素)GO

PS

会2

0

2

5·深圳站

应急响应耗时过久原因分析类别监控项说明下载下载量/成功率/下载速度关键项安装安装量/成功率/耗时关键项登录域名劫持域名解析异常(劫持)/跨网登录成功率各个步骤的转化率登录时长玩家平均登录时长游戏内登录辅助判断掉线以及网络异常游戏内登出辅助判断掉线以及网络异常在线大厅在线/掉线/重连判断大厅基础体验gamesvr网络连接数辅助判断大厅掉线gamesvr当前房间数量辅助判断大厅掉线单局网络延迟/loading耗时/FPS单局体验判断情况单局在线/房间数/掉线单局基础运行情况判断流量监控辅助判断游戏内异常/掉线异常/网络异常平均丢包率/平均延时监控玩家网络情况/局内体验注册注册监控渠道、平台注册客户端崩溃崩溃率和崩溃量监控玩家游戏体验FPSFPS明细监控游戏流畅度匹配匹配时长/超时次数监控玩家游戏体验/网络异常角色创建角色创建流水监控关键项金钱/道具金钱消耗流水监控关键项,道具分类监控购买购买失败量监控玩家游戏体验周边系统周边系统的访问质量关键项后台逻辑异常逻辑异常监控告警常规项服务器基础CPU/内存/IO/流量/ping/

…常规项后台基础进程不存在/core/通道常规项容器平台pod/node/apiserver/

.常规项文件上传录像上传量/成功率监控玩家游戏体验......•

SLI指标多•指标受时间、地域、运营活动影响•不同游戏,甚至同类型游戏走势也有较大差异配置:告警分级、收敛VS有效发现降噪:误告VS及时发现GO

PS

会2

0

2

5·深圳站•

RPG•

STG•

MOBA•

SLG•

ACT

卡牌•

开放世界•

沙盒…..

游戏业务的监控告警配置大厅在线日常

周末

活动一个FPS类游戏的基础监控A游戏B游戏类别监控项说明集群维度A服务大盘请求量基础项,可以发现端侧异常A服务大盘请求成功量基础项,可以发现自身或者下游异常A服务大盘请求失败量基础项,稳定且敏感业务需要此项数据监控A服务大盘请求成功率基础项,可以发现自身或者下游异常A服务大盘错误码总量基础项,稳定且敏感业务需要此项数据监控A服务大盘细分错误码总量基础项,用于针对特定错误码监控A服务大盘请求延迟基础项,用于服务能力的及时感知A服务大盘容量水位基础项,用于容量异常的及时感知A服务大盘配置检查基础项,用于部署容灾、过载保护等配置监控B服务……业务维度A业务请求量基础项,作用同大盘,但是细分到A业务A业务请求成功量基础项,作用同大盘,但是细分到A业务A业务请求失败量基础项,作用同大盘,但是细分到A业务A业务请求成功率基础项,作用同大盘,但是细分到A业务A业务错误码总量基础项,作用同大盘,但是细分到A业务A业务细分错误码总量基础项,作用同大盘,但是细分到A业务A业务请求延迟基础项,作用同大盘,但是细分到A业务A业务容量水位基础项,作用同大盘,但是细分到A业务其他基本同游戏业务......GO

PS

会2

0

2

5·深圳站平台业务相比游戏业务,

SLI项不多,但是由于接入游戏业务众多,且游戏业务的异构性、服务接入方式、量级、运营周期、运营活动不同,会导致业务维度监控差异较大。•

面向C端游戏平台业务•

面向C端组件平台业务•

面向后台组件平台业务

平台业务的告警配置一个面向后台组件平台业务基础监控典型平台业务的部署模式业务数据A业务大盘数据B业务游戏团队组件A团队

组件B团队如何协作?

组件C团队GO

PS

会2

0

2

5·深圳站•任一团队内部所有角色是否都能及时感知异常?•任一组件团队感知异常后是否及时周知游戏团队?•游戏团队感知异常后是否周知所有组件团队?×

游戏

组件A

组件B

组件C

协同问题:信息孤岛导致无法有效协同当业务登录出现异常时某游戏业务的登录流程故障案例背景:游戏M预计于周年庆当日0点举行活动,预计登录峰值增长200%,且提前与组件A、B、C做了报备,组件A、B、C也充分评估容量满足报备要求。事故过程:00:05组件A运维收到告警电话,开始处理,发现从00:02开始游戏M登录请求成功率下降,并且有持续下降趋势,此时登录服务开始产生大量告警,于是开始联系组件A研发紧急处理。00:08组件A通过查看日志,发现大量组件B请求超时错误,于是紧急联系组件B,组件B回复服务CPU高,正在紧急扩容。此时组件A也发现,自身服务CPU90%,通过查看请求量数据,发现在自身容量的30%处出现异常,判断当前CPU90%应当是下游容量不足导致自身性能受影响(处理耗时增加+业务不断重试)

,于是并未做进一步的处理,等待组件B恢复。00:15收到组件B同步,已经扩容完毕,但是组件A观测数据,发现登录请求成功率并未恢复,登录成功请求量恢复并逐步增长到自身极限性能,自身CPU从90%增长到100%,此时请求量在持续上升。00:18组件A开始紧急扩容。00:32组件A扩容完毕,游戏M登录请求成功率逐步恢复。GO

PS

会2

0

2

5·深圳站•处置是一个复杂的过程,会受事故现场很多因素影响•冗余的资源以及工具执行效率有助于降低处置时间•人的判断可以快速定位问题,也可能增长处置时间组件B返回时延

(单位:毫秒)组件A单机器性能

(单位:

请求/秒)10042000100024000200018000

处置问题:诊断和恢复时间过长2000ms•

A调用时延增大,性能下降•

A有效输出低于极限•

游戏请求超时,重试……

游戏M

组件A

组件B

组件C

游戏M登录流程涉及组件100ms组件A组件B91%故障通过故障自愈解决风险控制GO

PS

会2

0

2

5·深圳站

如何解决这些问题?如何建设通用应急响应平台?发生之前

(聚焦规避风险)发生之后(聚焦发生事故后

快速解决)发生之初

(聚焦风险发生但

未造成事故前解决)避免故障故障自愈摇人基于蓝鲸基座的应急响应方案建设建设目标:•消除信息孤岛,做到信息实时共享•将标准工程化落地,避免组织协同机制崩溃•辅助信息采集、决策和执行,提高执行效率建设需要:•便捷的获取监控信息•便捷的获取上下游链路人员信息•

快速进行观测•快速执行自动化任务GO

PS

会2

0

2

5·深圳站

方案设计GO

PS

会2

0

2

5·深圳站

通过蓝鲸基座便捷构建应急系统GO

PS

会2

0

2

5·深圳站

协作共建

灾备管理预案管理灾备流程应急演练灾备预案演练计划

方案架构CMDB数据业务人员信息业务资产信息标准运维私有流程执行权限监控平台观测视图告警策略

蓝鲸配置平台平台层业务拓扑信息….. IT服务管理中心预案管理场景管理

BKVision

权限中心事件管理工作台公共流程…..告警事件…..能力层数据层标准运维监控平台演练实施应急管理应急处置蓝鲸监控入口BKChatAIDev接口页面……•确保故障发生后,有机制可以保证运维及时对故障进行响应•确保运维响应后,可以快速的拉起相关人员进行处理•确保建立响应后,有机制可以保证上级及时了解整个处理详细过程GO

PS

会2

0

2

5·深圳站

应急管理流程概览GO

PS

会2

0

2

5·深圳站游戏关键监控指标•

在线•

登录•

注册•

单局…

告警配置:通过巡检确保告警正确接入通过规范化业务核心指标监控上报以及监控配置巡检,确保监控正确接入。GO

PS

会2

0

2

5·深圳站

智能异常检测:无需配置告警核心监控配置后,监控平台默认自动应用智能检测,无需运维配置告警。GO

PS

会2

0

2

5·深圳站•针对关键指标,蓝鲸监控自动绑定故障应急•页面录入、

BKChat启动应急后,无需确认•监控启动的应急,需要确认

应急响应触发:监控平台自愈流程接入•

1min内启动紧急响应并触发相关人员拉起专用会议•

5min内交互提醒升级重大响应•

信息全程实时共享GO

PS

会2

0

2

5·深圳站

应急系统使用概览4、启动专项群和会议5、超时自动上升1、发起应急响应l2、人员确认6、应急解除3、应急协同GO

PS

会2

0

2

5·深圳站

应急系统使用概览处置上升••处置上升指运维未在规定时间内对完成故障修复而进行上升按照启动应急开始计算,每到一个层级的处置超时时间,就会对该层级人员进行电话周知响应上升•••响应上升指运维人员未及时对应急事件进行响应如果运维人员电话未接通,会逐级上升,直到其中一个层级电话打通如果运维人员电话接通,但是未能对应急事件进行确认,会在设定时间超时后进行上升GO

PS

会2

0

2

5·深圳站

上升机制:响应上升和处置上升3、对整个基础环境进行自动检查1、蓝鲸监控告警2、告警触发自动检查任务

(故障自愈套餐)

辅助诊断:通过故障自愈套餐触发基础环境状态检查告警GO

PS

会2

0

2

5·深圳站故障自愈除了可以修复明确处理流程的故障之外,也可以用于简单的信息提取来辅助故障诊断。故障发现故障诊断故障发生

开始处理自动检查未使用eBPFTrace调用链查看GO

PS

会2

0

2

5·深圳站

辅助诊断:蓝鲸监控APM+eBPFAPM和eBPF可以辅助运维和研发,提升诊断效率 Deep

Flw'协作共建应用拓扑查看使用eBPF基于Workflow使用LLMGO

PS

会2

0

2

5·深圳站

蓝鲸AIDev:智能辅助分析和根因诊断基于蓝鲸AIDev平台可以便捷的利用蓝鲸监控的知识辅助运维进行故障诊断和根因分析LLMWorkflowAgentLLM网关服务LLM模型集成LLMAgent

FrameworkCD智能场景CI智能场景CO智能场景提示词管理角色管理工具管理LLM模型服务层LLM场景服务层LLM工具构建层基于Agent

Framework使用LLM知识库GO

PS

会2

0

2

5·深圳站•应急系统支持事件启动后外部任务调用•可以通过BKAIDev平台创建基于大模型的workflow,用于辅助诊断

使用Workflow实现AI辅助诊断确定故障排查入口GO

PS

会2

0

2

5·深圳站

基于AgentFramework实现根因诊断

故障诊断:基于Transformer和对比学习的故障入口确定方案故障排查入口核心任务:在大量线上告警事件中确定故障诊断的排查入口依赖数据:告警数据、指标数据、图谱数据故障排查入口故障排查入口确定故障排查入口GO

PS

会2

0

2

5·深圳站关联实体图确定故障排查入口①告警降噪

②告警聚合对于降噪后的告警,按相似性聚类噪声告警示例:去除噪声告警3

故障诊断:基于社区发现和图的动态规划的故障诊断方案核心任务:推导故障传播图,确定根因节点依赖数据:

图谱数据、

eBPF数据GO

PS

会2

0

2

5·深圳站1.锁定故障入口2.提取入口关键异常3.子图查询4.传播路径推导5.确定根因节点6.故障传播图优化查找与入口节点密切相关的子图入口计算全局影响分数,选择全局影响分数最大的节点作为根因节点按照确定的根因节点,对故障传播子图进行剪枝和合并按照故障传播模式、调用边异常指标间的相关性,推导故障传播链并更新因果效应使用社区发现算法进行聚类,提取入口关键异常调用指标,计算入口权重计算故障排查入口调用边异常指标相似度故障排查入口异常指标关键簇相似度:0.55入口GO

PS

会2

0

2

5·深圳站

故障诊断案例:Redis延迟引发的故障调用边异常指标(业务Pod请求Redis节点)Redis延迟指标故障传播图Redis节点故障建单信息:数据来自应急系统

故障处置过程:数据来自应急系统故障复盘和改进计划改进计划跟进GO

PS

会2

0

2

5·深圳站

故障复盘:通过ITSM系统实现复盘和改进执行应急响应的思考和经验分类术语定义告警级别P1•该级别告警触发时,需要立即进行处理。•通知方式:电话+企业微信P2•该级别告警触发时,无需立即进行处理。•通知方式:企业微信响应级别优先级:一级>二级>三级。一级定义:关键路径异常,且持续时间大于10分钟,需跨团队关注与协作处理•该级别要求立即周知至总监以及部门重大故障群。•该级别要求研发、运维立即共同响应。二级定义:关键路径异常,且持续时间小于10分钟,需跨团队关注与协作处理该级

别要求研发、运维共同响应。三级定义:非关键路径服务异常,且持续小于10分钟,无需跨团队协作处理,该级

别要求运维响应。业务级别重点业务包含收入活跃>xxx的游戏,以及自定义添加的游戏。角色责任候选人员说明事故总控负责组建事故处理团队、分配任务给团队成

员,协调周边和资源以便更快速的处理故障。运维负责人研发负责人运维负责人负责运维侧协调安排

研发负责人负责研发侧协调安排事故处理处理故障直属运维直属研发运维作为现网唯一操作人员发言人本次事故对外发言人,职责包括:•

向关注事故的人周期性的发送事故进展•维护当前事故文档,保障其及时性和正确性运维负责人

服务经理GO

PS

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论