那些年线上BUG踩过的坑汇总

• 功能流程设计类：通常指的是研发在设计产品逻辑功能实现流程中，错误的执行调用关系而造成的风险事故。

• 技术方案实现类：在研发设计好流程后，每一个功能点的实现方案会因人而异，也会由于理解偏差或不足，而导致实现过程中缺少了对代码在运行过程中健壮性的评估。

• 技术服务使用类：这一类说的是在研发使用数据库服务、缓存服务、大数据服务、配置中心服务以及发布上线服务等时，对各项服务的配置以及使用上缺少一定的了解，而造成的事故。

• 后门违规操作类：这一类因公司对研发规范的执行强度不同，而是否会有此类风险。例如：有些研发同学会开发一些后门程序，比如可以在某个ERP页面执行数据库语句，临时修改数据。这样造成的风险，通常为后门违规操作，会有开除风险。

• 运营操作失误类：在研发以为还有一部分公司内的伙伴会使用研发同学开发的运营系统，配置活动、变更用户、执行流程等操作，但一般情况下这类系统缺少一定的强规则验证，导致运营小白在操作过程中造成风险，从而引发事故。 一般线上配置出错误卷，或者推错短信给用户等等，都是这样发生的。

事故名称	事故描述	事故结果
gc疯狂回收	最近调整了自己业余项目，跑一段时间就内存狂涨，还不能主动诱发	dump内存
重复扣入账	并发数过多，数据库连接满，等待超时，session断开。事务未提交，捞出继续干	500块，深入并发编程，目前并发模型在我心中，欢迎battle
数据覆盖	循环更新数据时，开启事务，持续时间过长，然后覆盖掉了用户在持续事务中提交的数据	没影响，就是多加了几天班
数据穿透	第三分使用脚本海里请求并发造成数据穿透	削峰天谷， 使用队列处理请求
这序列号咋重复了？？	序列号应具有全局的唯一，一条数据代表一条收入，序列号生成规则+代码bug导致序列号重复，影响了几万单收入核对	一级事故，回溯+通报
业务流程数据覆盖	流程是一个公共类，各种交易都在这个里面做，公共类一开始没有经过设计，有一个方法返回了这个模板类型字段，同时这个方法又是一个检验类，当时加了一个检验返回成错误码了，导致所有的交易都启不了流程。	挨批长记性。。。
simpledateformat的线程不安全导致多线程定时任务解析日期出错	某定时任务运行时，需要做一些日期解析动作，就用了一个公共变量simpledateformat，来格式化，结果任务经常间歇性报错，几天报一次或者一两周报一次，没啥规律。看异常信息才发现解析日期的字符串很奇怪，经常出现很多奇奇怪怪的数字。	定时任务报错，不过还好，定时任务只是为了做缓存而已，不涉及到数据库的更新，仅仅是查询而已。
前端解析主键异常	由于Long类型最大19位而JavaScript最大接收数字为16位，固存在精度丢失问题	统一处理将id转字符串再返回前端
list遍历删除	遍历删除清空list数组，为了节省计数器那小小一点内存，日了	报错被叼了呗，为啥不用计数器？不香吗？
商品超卖	售卖一个兄弟部门的电子券商品，同步库存的代码有问题，导致了超卖 对客户造成了损失	罚款1000元

业务流程搞错+代码频繁开辟线程池	业务流程搞错导致的问题就是改动特别大，有点类似重构代码了哎西，导致服务宕机很久，客户疯狂反馈	疯狂加班改业务，加了不知道多少个晚上，由于是菜狗子，写的代码太垃圾了，被大佬给疯狂叼
线上修改用户收货地址失败（同事需要的问题，也可以借鉴下^v^）	场景：客服反应用户需要把收货地址从河北省改为浙江省（因为疫情），公司要求修改线上数据需要提交工单，因此l到审核平台提交申请等一系列流程。 问题：工单显示修改结果成功，但是数据没有改过来，多位同事一起查看sql发现sql编写没有问题。 解决过程：检查sql是否正确，平台是否修改成功，又检查了数据是否正确，还检查了修改时间是没有问题的。	首先，忽略了一个问题，这个订单数据是淘宝下单同步到我们订单这边的，数据修改的后，淘宝又同步也数据过来，把修改正确的数据又改为了河北的地址。然后就怀疑sql审核平台问题。到这里故事已经讲完了。结论：想告诉大家要相信代码，多检查不确定的情况，不要钻到死胡同，老是怀疑审核平台问题，多检查自身问题。
业务相关事故	刚加入一个新的团队，没有深入了解别人的代码就进行复用，没有理解业务的场景就限制条件，类似的情况很多，只能说，再简单的代码都要保持敬畏，因为你不知道哪里会出问题	用户投诉、领导批评

使用fastjson	全身上下都是高危漏洞，一年不停升级版本打补丁	珍惜生命，远离fastjson
微信名存储bug	微信名的emj头等存入mysql编码是utf8的库报错	被怼了！改成utf8mb4编码
磁盘不足	数据库集群磁盘空间不足，提前两周提交扩容申请，甲方运维没提交上去，最后某台机器空间不足，导致整个集群彻底不能工作，体验一把某国产号称可以方便横向扩容的某idb的优越性	罚款，责任归系统建设方

删除整个项目目录文件	测试区，测试删除文件时目录写错，导致整个weblogic子项目目录被删	请项目中负责集成部署的公司帮忙重新部署，测试区瘫痪了两天
误更新生产订单数据3万多条	下班前，未带核心过滤条件，导致误更新3万多条订单数据，偷偷利用binlog恢复了，耗时3个小时	完美恢复数据
线上库整库误删除	应业务方要求要在线上环境创建线上联调库，使用了导出数据库DDL语句后，直接执行，导致执行了exists  drop语句，删除了线上库所有数据，数据量大表均在千万级，APP、网站全线瘫痪。	使用前一天的备份副本数据恢复，下载binlog日志按操作避开事发时间点分割后编译，导入数据，然后再修复事故之后的数据，共计耗时48小时。

业务漏洞	业务乱配优惠券，可以叠加，超级优惠，然后被薅羊毛	部门帮着查羊毛记录，处理订单，挽回损失。然后对外发公告宣称是被部门的风控系统误杀的。
贷款费率	运营配置T+1日结算贷款费率错误，导致用户贷款金额发生错误。	上线新费率替换旧费率，已经产生的费率错误联系贷款用户修复。
多活动互斥	三个部门的都做活动，但最后导致重复发奖。一个用户邀请别人奖励，变成了三份奖励。	产品提供渠道和互斥功能，让运营自己选择是否可以并行发放奖励。