游戏运维自我排查案例

案例1：

情况描述：因为开发商提供的SQL的效率问题，计划DB变更耗时20分钟，实际执行耗时60分钟

解决方案：

1、大版本发布要有灰度机制，所有发到现网的版本，提前在灰度服进行验证，验证一段时间后，确保没问题再进行全服发布

2、收到SQL变更需求，特别是重要业务，需提前联系DBA评估SQL语句是否合理，并预留足够的时间

 

案例2：

情况描述：开服验证环境未发现异常，全服发布到现网后，监控到多个大区gameserver内存使用率快速升高到100%，部分玩家投诉进入游戏失败

解决方案：

内存升高后需立即联系开发确定是否是内存泄露问题

 

案例3：

情况描述：确定已经发布版本存在内存泄露bug后，项目组要求做版本回退，运维回复说未对程序和数据进行备份，且不知道如何进行回退

解决方案：

1、试用期1个月未获取运维上岗资格证，不能独立操作现网环境

2、在版本规划之初就应该考虑到版本可快速回退的方案，数据更是要每次变更前均需备份，为了减少发布时间的话，可以考虑在自动备份完成后开始发布任务

3、标准运维作业增加版本备份环境，根据版本大小选择全量备份或者增量备份；根据版本特性对进程文件、配置、端口、客户端等内容增加回退步骤，加入到checklist中，提前演练确保回退正常

 

案例4：

情况描述：发布期间，运维针对A大区DB服务器进行替换，且更新DB和gameserver，loginserver连接配置，发布后，A大区玩家集中反馈购买的道具不到账。

解决方案：

1、在操作前要准备完整的checklist，包含所有需要变更配置的点，周边系统的变更知会，提前评估权限问题

2、开服前缺少测试验证环节

 

案例5：

情况描述：

　　项目组统计到8.2日当天，xxx游戏的下载带宽是平时的3倍，造成了带宽成本浪费，且有玩家抱怨在8.3r日凌晨在线不高的时段进行下载时，游戏的下载速度和白天忙时相比并没提高，没达到玩家的预期。

解决方案：

1、针对大版本，提前做好预下载方案

2、客户端升级包提前开启预下载功能，官网开放手动升级包的下载，避免升级集中在开服环节，如果版本较大，需做好评估提前申请带宽，以保障下载速度