盘点程序员写过的惊天 Bug：损失 3 千万不算啥，就差毁灭世界了！

Posted 2021-10-13 一去丶二三里

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了盘点程序员写过的惊天 Bug：损失 3 千万不算啥，就差毁灭世界了！相关的知识，希望对你有一定的参考价值。

星标/置顶 公众号👇，硬核文章第一时间送达！

“你职业生涯中写过最大的 Bug 是什么？”

在这个问题上，勇敢的新时代农民工们，总是能不断地创造奇迹。

一起来看看程序员的分享：（很多很多都是匿名，哈哈哈~）

让前公司损失 3000 万的匿名网友^[1]

这个必须匿名～离职后，某天微信群里和 QQ 群里炸了锅～

前同事们给我说，我写了一个 BUG，让公司损失了 3000W，让我等着公安上门吧（当然这是开玩笑）～

他们说我是故意写这么隐蔽的 BUG。这个 BUG 比较隐秘，直到项目上线 1 年后（我离职半年多），市场部才发现，测试都很专业，两个测试当时没有测出来让我也感觉很意外，我估计是业务逻辑的问题，市场部的人估计当时没想明白。

后来我回公司玩，然后跟我们对接的市场部的人，被发配下来当 PD 了。直到现在，我都不知道 BUG 是啥，哪里出了问题～

总之损失了 3000W 是真的，现在想想程序员真伟大，我随便一个 BUG 就是千万元的损失，感觉好怕怕。

一个写 Bug 坑了领导的匿名网友^[2]

写的这个 bug 差点直接坑死我的领导，得匿。上一家公司是一家集团的子公司，所在的集团体量很大，官僚气息严重，讲原则，讲 ZZ，上下级界限明显，这是背景。

有一天，集团上派发下来一个任务，内容很简单，为一个活动做个 H5 页面，这边没什么可说的。这个 H5 里面有一个页面，类似电影电视结束、游戏通关之后的工作人员列表。这个页面很重要，因为这里会展示集团领导的名字。从根本不知道还有这个项目的集团老板开始，到具体负责这个项目的基层负责人，都在其列。

这个 h5 体量不大，很快就做完了。期间我的老板过来跟我讲，让我把他的名字也加进那个页面中去，我就照做了。但是！也许是当时加班太累了，一时疏忽，加上我老板名字的同时，不小心删掉了集团里另一位中层领导的名字。

当晚，我完成了这个 h5 的开发工作，按流程部署测试环境，并提交测试。当晚，那位集团中层领导不知道为什么，看到了尚未正式发布，还在进行测试的项目，并且敏锐的发现：自己的名字不见了，换上了我公司领导的名字。后面具体发生了什么事情，细节我就不清楚了，不过回顾一下前文提到的故事背景：所在的集团体量很大，官僚气息严重，讲原则，讲 ZZ，上下级界限明显。也很容易猜的出来了，大概就是往抢班夺劝这方面发展了吧。

也不知道那位集团领导，会不会相信，这一切，真的只是我加班太多，手滑写的一个文案 bug 啊！

差点让公司损失 1000 万的匿名网友^[3]

前段时间刚出的 bug，公司估计损失了 1000w。问题也很简单，下午 2 点上线了一个需求，新增了一条 sql 语句：

select aid from xx where bid = ?

看着没有问题吧，bid 字段也是有普通索引的，上完线验收了业务功能正常就结束了。

凌晨 2 点被电话叫醒，加入语音会议后才知道数据库在晚上流量的高峰期 io 飙升了 5 倍，导致整个核心交易链路全部挂掉，dba 剔除 dbproxy 以后无法再次挂起，最终定位到可能是代码问题，回滚代码业务恢复正常，从定位问题到业务恢复花了一小时时间。

第二天领导带着一大帮人开始复盘问题的根本原因，dba 发现是因为新加的 sql 有回表现象，这张表有 80 亿数据，导致了整个数据库层面的 io 变高。然后就是接受领导的灵魂拷问，为什么发完需求不监控 mysql 指标，为什么不去关注系统的核心接口指标？复盘会开了好几次，bug 相关的文档整理了几十页。关于回表现象虽然了解其出现的原因，但是在实际开发中没有意识去规避。

为什么有 80 亿数据，因为有个小伙伴的刷数据脚本有问题，录入了重复数据，dba 认为问题其实跟数据量关系不大，目前库里几十亿的表也不止一张，后期是有规划重新梳理业务做拆分，而且这边表的 sql 都很是像回答中的 sql，不存在连表查询子查询等业务存在。

回答里面大家关心的分表问题，即便分了表，一旦涉及回表 io 还是会升高一样会导致上面的问题。解决方案是通过解决掉回表，新增 aid 和 bid 的联合索引。

不测试直接发布到生产环境的匿名网友^[4]

这事必须匿名。

我们这行是窗口行业。这几年管理越来越规范了，这些事情很少出现了。说说十年前的事情吧。客户下午快六点提过来的需求，要增加个查询内容，要第二天就要用上。

这玩意其实很简单，就是在一个 Oracle 几十万数据的表上在关联另外一个几十万表，加上一个查询条件就完事了。而且这两表基本属于天天用的，闭着眼都知道各个字段的内容。咱一看就这，分分钟搞定的事情。两个表 inner join 一下，查询条件一加。

打完收工，直接发现场。别问为啥没测试，问就是懒的测。现场直接更生产，别问为啥没现场验证，问就是懒的验证。

第二天开门，精彩来了，系统开始是慢，后来直接就宕掉了。

问：昨天还好好的，今天怎么不行了。答：就更新了这个查询，别的没干啊！

查：查询条件类型搞错了，数据库里存的是一个纯数字字符串，前台传过来用的是数值型变量传到 sql 里了。

结果：当地窗口部门直接关门半天……至于我有没有被罚，答案是没有。别问为啥，问就是当年管理不正规。

这事从甲方那边就大事化小，我们自然就小事化了了。这事也就是当年没什么 12345 之类的政府热线，要放到现在，这事起码半个月工资没了。

菜到差点“违法”的网友 Sun^[5]：

Java 后端，犯了一个非常低级的错误，由于独立开发所以底层不可能都手写，就在 git 上找了一个不错的开源项目，项目安全框架使用的 shiro, 虽然本人代码写的很菜，但是也知道 shiro 不能用 1.2.4 以前的版本，因为加密的用户信息序列化后存储在名为 remember-me 的 Cookie 中。攻击者可以使用 Shiro 的默认密钥伪造用户 Cookie，触发 Java 反序列化漏洞，进而在目标机器上执行任意命令，所以直接用了 1.4.2 版本。

过了大概有半年的时间，突然有一天早上四位 JC 老哥还有个小姐姐直接进了老板办公室，由于我们不是互联网公司，都不懂技术，JC 老哥也不懂技术，案件是上面局里派下到他们所里的，然后我们老板赶紧叫我下去，我进屋一看场面十分尴尬！！！然后我接过他们的检测报告看了一下，高危漏洞 shiro 反序列化命令执行，一下懵逼了，因为到 1.2.5 及以上版本，就不存在硬编码密钥的问题，而改为自定义密钥，但是我看了一下我使用的 shiro 版本是 1.4.2，按理不应该存在该问题了啊。

那问题出在哪里呢，让我万万没想到的是开源框架在代码里会配置 shiro 的密钥，而关键代码可以在 github 上通过 api search 接口搜索到，从而得到一个所谓的 key 包，其实就是这些密钥的集合，然后用这些公开的密钥去轮流尝试，如果你用了开源的框架，而没有修改 shiro 的密钥，其实这就相当于你使用的 shiro 密钥已经泄露，这是非常危险的，所以赶紧修改了 shiro 的密钥。

JC 老哥说这次就先这样赶紧处理漏洞，如果处理不好下次可要罚款了昂？然后下午又去所里做了笔录，都是眼泪啊兄弟们！！！修复了之后还要写一个承诺书还要去交到所里。

原本以为我写 bug，那就是菜。现在知道了写 bug 已经上升到违法了。附上承诺书让大家引以为戒！！！！