现场需关注的信号
打鱼游戏上线后，需持续观察以下指标：
- 登录响应时间：超过3秒需排查网络或后端负载
- 子弹发射延迟：客户端与服务端时间戳偏差超过200ms可能引发不同步
- 鱼群刷新频率：低于设定值90%时检查定时器或数据库查询性能
- 金币增减异常：单用户每分钟金币变动超过阈值，需确认是否触发防刷机制
- 数据库连接池水位：超过80%需扩容或优化慢查询
一次线上事故中，子弹发射延迟从50ms飙升到800ms，原因是缓存穿透导致数据库CPU打满。现场观察该信号后立即切流，避免全服卡顿。
常见失败模式
根据多个打鱼游戏项目复盘，典型故障有：
- 大厅列表加载失败：多为API网关超时或后端服务雪崩
- 房间创建后无法加入：房间状态同步异常，常见于分布式锁失效
- 捕鱼结算不准确：概率算法在并发下出现竞态条件
- 排行榜显示错误：缓存更新策略不当，导致数据滞后或错乱
- 客户端闪退：资源加载失败或内存泄漏，常见于低端机型
诊断步骤
遇到异常时按以下顺序排查：
- 检查监控大盘：确认CPU、内存、网络IO、磁盘IO是否异常
- 查看最近变更：是否有新版本发布、配置修改或第三方依赖升级
- 分析日志：先看ERROR级别日志，再定位相关业务日志
- 复现操作：在测试环境模拟用户行为，确认是否为必现
- 回滚确认：若怀疑新版本，直接回滚到前一稳定版本验证
恢复与回滚
恢复操作需分优先级：
- 立即恢复：影响核心体验的故障（如无法登录、无法开炮）优先回滚服务
- 灰度恢复：非致命问题（如排行榜延迟）可先切部分流量到旧版
- 数据修复：若金币数据异常，需从备份恢复或执行补偿脚本
- 验证后上线：修复后需在预发布环境跑完自动化用例再全量
经验清单
整理自多次打鱼游戏运维事故： 打鱼游戏
- 所有概率计算必须加分布式锁，避免并发覆盖
- 关键接口设置熔断降级，防止雪崩
- 数据库读写分离，并定期清理过期数据
- 客户端资源包做完整性校验，避免加载损坏文件
- 建立灰度发布流程，新版本先覆盖5%用户观察24小时
- 监控报警阈值需根据业务量动态调整，避免误报