线上部分问题记录与分析—2025年5月

以下是上家公司部分线上问题，具体时间没有记录

线上问题处理思路

总体来说线上问题解决可以分为三阶段：响应止损—解决验证—复盘改进

1.响应止损

首先及时确认问题，然后评估问题类型及优先级，接着通知相关人员

如何定位问题类型及严重程度，可以多部门开会制定《线上事故认定及评级规范》，严重程度可能涉及影响范围、业务损失等方面，另外关于处理流程，多方意见也需要达成一致

• 如果问题是普通bug，看是否能复现，再根据优先级确定解决方案
• 如果问题是线上事故，需要及时止损，并讨论解决方案

2.解决验证

先根据问题类型及优先级，判断是马上解决还是后续解决，接着定位问题并解决，问题解决后需要再次验证

3.复盘改进

记录相关问题，进行根因分析，然后开会制定改进措施（需明确责任人及截止时间），管理者需要加入体系思考：比如流程改进，能力建设，知识沉淀等等

以下是目前遇到过的问题

1，部分用户前端钱包登录后去绑定Twitter返回时，无法绑定Twitter，提示登录失效

测试：测试时未模拟token失效（24小时）的情况，导致漏测这个bug

本质原因：后端登录失效采用两个状态码并且前端做了登录态的cookie保存，24小时才失效，不会主动退出登录

语录：用例设计与评审时主动询问开发的账号等相关信息的缓存设计方案

2，在RocketMQ中创建TBA的消息，某个字段为""时，消息会消费失败，导致无限重试消费，消息阻塞

测试：测试时模拟消息错误

本质原因：MQ机制导致，没有错误处理的会重试int类型的最大值

语录：需要对消费失败的场景进行处理

3，安卓无法扫描黑色底的登录二维码（白色可以）

本质原因：开发说是谷歌插件的bug

4，web端采用鼠标移动显示弹窗提示，H5端是点击出现，但点击其他弹窗不会主动关闭已出现的提示

本质原因：web的hover效果，存在与弹窗的层级问题

5，扫块服务漏扫某个区块的某个交易

本质原因：区块存在回滚，扫块服务扫的最新的块，导致交易漏掉

6，7月12日summer活动第一轮开奖失败问题

本质原因：性能未优化，masql较多负载下cpu满载，导致接口查询Mysql超时，rocketmq消息为顺序消费，导致消息未消费堵塞，开奖卡住，只有手动开奖

7，9月17日Eve活动部分用户无法参与开奖问题

本质原因：未考虑到上游消息已经过期的情况下，下游仅依赖消息进行业务流转 ，没有其他兜底机制

语录：消息中间件的作用是解耦，流量消峰，异步处理，负载均衡；而定时任务用于非实时的重复性任务

8，9月18日用户开奖算法问题，会导致大奖会较早的开完了，后面就没有大奖了

本质原因：开奖算法需要的是随机，采用的先分6类奖品，再随机到6类奖品之一，最后分配奖品

语录：进行算法测试时，需要结合运营策略与效果判断算法是否合理

9，12月24日TG账号绑定报错

本质原因：TG账号的账号名支持50个以上的字符，当前库的存储字段只varchar（50)，导致无法保存

语录：第三方接入后，对于要保存的第三方字段需要兼容数据的长度

10，3月27日Cc项目线上首次Twitter绑定报错

本质原因：用户使用没有www的域名访问，回调Twitter拿到token授权后，使用了original的地址，该地址有WWW，导致回调时token参数丢失，绑定失败，

语录：回调地址需要原地址相同，nginx可以配置未加www地址重定向到www域名