查看原文
其他

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

点击上方 "Linux就该这样学关注,星标或者置顶,第一时间送达

责编:Linux妹 | 来源:程序员的那些事

上一篇:Linux进程之如何查看进程详情?

  大家好,我是Linux妹。

“你职业生涯中写过最大的 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 已经上升到违法了。附上承诺书让大家引以为戒!!!!

参考资料

[1]

匿名网友: https://www.zhihu.com/question/482967292/answer/2113447527

[2]

匿名网友: https://www.zhihu.com/question/482967292/answer/2088762808

[3]

匿名网友: https://www.zhihu.com/question/482967292/answer/2112673889

[4]

匿名网友: https://www.zhihu.com/question/482967292/answer/2114300592

[5]

Sun: https://www.zhihu.com/question/482967292/answer/2106452014



  声明:本文部分素材转载自互联网,如有侵权立即删除 。

--END--

往日精彩:

谁再说不熟悉Linux命令,就把这个给他扔过去!

5分钟带你了解Linux常用命令全称

推荐 4 款超好用的内网穿透工具,总有一款适合你

放弃使用 15 年的 macOS,我决定换成 Linux!

鼓励师加成太刺激了,鼻血喷了半斤,代码不一会儿就写完了...

Linux 服务器的性能参数指标总结

Linux系统安全强化指南

Linux 系统开机加电后发生了什么?

喜欢本文的朋友们,欢迎长按二维码,关注订阅号Linux就该这样学


收看更多精彩内容

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存