最近，小编在知乎上看到这样一个问题：
1. 知乎好友：繁星若尘
不是我写的，是我见过的。
登录功能，把用户表的所有用户信息整个传到前端，for 循环遍历核对有没有正确的账号密码……
测试环境就几十个用户数据，跑得还挺快……
还好叫我给拦住了，没给上生产。
这写法直接震惊我一百年。
2. 知乎好友：Madcat
以前看过的一个段子，某程序员写了一个获取微信昵称的小程序，拿同事微信做测试，返回数据是 null 。排查许久找不到原因，后来灵光一现，点开同事微信资料，同事昵称就是 null ……
3. 知乎好友：风迟御
微博某用户（经提醒，是酷安用户）某天灵光乍现，把手机卡的名字改成了“无 SIM 卡”，然后手机就真的检测不出来对应的手机卡了，也无法点开相应 SIM 卡设置改回正常名称。
魅族手机的系统 bug。
解决办法也简单，先把系统语言改成英文，然后就能重新设置 SIM 卡信息了。想出这解决办法的，属实是人类智商巅峰了。
4. 知乎好友：大为
鄙人当年查出过一个惊天大 Bug，其实 Bug 并不高级，是一个 unsigned 32 位计数器溢出，每秒 1000 个 ticks，所以系统每 49 天崩溃一次。
电信级设备，500 万用户，哈哈，当时那个酸爽啊。
由于在极大的压力下找出这个 Bug，挽回数千万损失的原因，当年被连升两个职级，同时被评为优秀员工。
5. 知乎好友：风飞星闪
短信计费，写的判断条件忘关调试就打包了，直接变成了 While(true)。
导致用户一跑我们的游戏，几毛钱一条的计费，玩儿不了十几分钟就能把话费扣完……
结果直接被投诉在中国移动下架……限时整改之后也再没给上架……
甚至还有人专门找到我来求教怎么做“无限扣费”……
6. 知乎好友：明月
在我刚毕业进入一家刷卡支付公司工作，是个创业公司，长期权限管理混乱。
在一个阳光明媚的下午，我日常操作中进行数据库表数据清除，但是这次有点意外，平常都是两三秒就执行完毕，这次竟然卡了十来秒都没执行完。
正当我疑惑的时候，突然部门老大冲进办公室大喊系统异常了。
我心头一紧，不安地看了一下数据库连接地址，我了个去，是生产环境。我立马用 0.01 秒的手速停止了运行，然而为时已晚。
脑袋里一直闪烁出一句话：删库到跑路。
在几十秒的挣扎后，我还是鼓起勇气走向了老大，跟他说：老大我知道什么原因了。
老大开心地看着我说：可以啊，这么快找出问题了，赶快去解决，会后分析问题原因。
我诺诺地说道：我可能解决不了，我不小心删错库了。
只见老大脸色一正，不敢置信地看着我，过了几秒后大喊：A（运维工程师）赶快过来。
最后在运维加外请的大佬还有我，通过 binlog 日志恢复数据库，连续肝了 17 小时才解决。
从那天开始所有生产权限全部上收。
因为这事我身心俱累，在那周四请假出去旅游放松心情。
当我周一回来上班后，发现公司安静得可怕，我询问了一个跟我关系比较好的同事发生了什么事情。
他跟我说道：你出去旅游的时候线上出重大 Bug 了。
我骄傲地笑道：还有比我删库的事严重。
当我说完这句话，看到他一脸平静且不屑的表情时，我感觉到疑惑。
他安静地说道：周六晚上 B 同事为了赶进度，方便自己测试在代码写死了 00 成功，忘了删除直接上了生产，交易跑了一个上午才被发现，公司统计大概亏了上百万了。
我：啊这……
这件事后，项目上线必须代码过审，测试人员同意才行。
我和那同事通过个人能力，为公司的制度规范做出了前所未有的贡献，以致于现在都经常被拿出来当模范表扬。
7. 知乎好友：启舰
你知道世界最著名的四大 Bug 吗？
“电子邮件无法发送到 500 英里以外”
Bug 界最经典的传奇之一。
我在做校园的邮件系统管理员的时候，有用户向我抱怨说：他们不能发送超过 500 英里距离的 email……
如果你之前没有听过这个故事，如果你就是这个管理员，此刻是否一脸懵逼。
补充材料：
用户中有位地理统计人员，还添油加醋地制作了一张邮件发送失败地图。地图上显示，她邮件的送达区域半径比 500 英里就多那么一点点：半径内的收件人，全收到了；之外的，全失败了。
请给出你的 debug plan。
别说是邮票没贴够。
真相：
一次软件升级导致远程服务器超时时间被设为 0。在一个具有典型负载的特定机器上，零超时意味着如果连接时间稍微超过 3 毫秒，服务器就会终止连接。而以光速传播的电信号，在 3 毫秒的时间内所能到达的距离大约是：
0.003 * c(光速) = 558.84719 miles
“只有在星期三才会崩溃的系统”
Bug 界最经典的传奇之二。
一家医院用来监控病人健康的数据库，每到周三，会自己崩溃。
我在周三的时候通常也会崩溃，因为那天有组会，但我感觉这应该不是这道问题的答案。
补充材料：
该事件中，最大的难度在于，一周只有一天有机会 debug。
该系统记录日志是用 C 风格的代码编写的，把日志字符串记录到了一个固定长度的缓冲区中，其中日志时间一栏，格式例如 Monday, July 17, 1997, 10:38:47.123。
请给出你的 debug plan。
真相：
因为周三的日志时间一栏，缓冲区恰好溢出了。（就差一个字节写不下）不会有来自星星的 Bug，也没有哪个 Bug 是太阳的后裔，所有那些你认为的、不惜穿越时空来与你情定今生的 Bug，都特么是你曾经犯二惹的祸。
“当我坐在窗边的时候，内存读写就会失败”
Bug 界最经典的传奇之三。
给一个自己设计的 SD 卡控制器写驱动，从五月开始调试，一直很顺利。
到了七月份突然开始出现间歇性的 SD 卡读写失败，而且越靠近窗户，失败频率越高。
也许坐在窗前写程序本身就是一个错误，每次我坐在窗前的时候，都会想隔壁班的那个女孩怎么还没经过我的窗前。
补充材料：
驱动程序是要下载到控制器的板子上的。当这块板子放置于窗边，特别是正午的时候，调试几乎总是失败。
请给出你的 debug plan。
真相：
电路板上芯片的正常工作温度有限，当超过一定的温度时它就带不动负载了。而 7 月的正午，太阳正好通过窗户照到板子，导致温度过高。
“摇动游戏手柄的时候，游戏存档就会失败”
Bug 界最经典的传奇之四。
在开发 PS1 游戏“袋鼠大进击”这款游戏的存档/读档时候遇到的。
Bug 的症状是每隔一段时间存档/读档都会超时失败，并且十分随机。
像我这种游戏从来都是一命通关的人，其实不是很在乎能不能存档的。
补充材料：
该事件中的难点在于重现 Bug。当开发人员把可能出错的代码已经注释到了四大皆空的时候，Bug 依然随机出现。偶然间，测试发现了快速重现 Bug 的方法：一边摆动手柄，一边存档。
请给出你的 debug plan。
真相：
PS 的时钟在高频率下运行时，会影响到主板旁边的晶振，造成手柄控制器的内存卡控制器之间的串扰。手柄上一有信号，内存就被干扰了。
8. 知乎好友：FrankHsu
关于我是怎么亲手断送自己的未来的。
事故一：
毕业了由于比较牛鼻，直接进了某运营商工作。
有一天接了一个任务，要求写一个群发通知短信的代码。
当天大脑短路没改代码，接上了生产环境直接撸。
代码循环所有运营商内手机号，发送最新优惠活动。
编码、测试、完蛋，写成死循环了。
发现问题之后及时停止程序。还好，只是给数据库中的第一个号码发了一千条短信。
继续编码、测试、成功。
收拾东西回家睡觉。
第二天，我就失业了。
大家猜运营商数据库第一个号码是谁的？其实我也不知道。
只是去结算工资的时候，人力说开除我的人的级别很高。
事故二：
失业了之后，由于之前有在运营商的经历（咋失业的我没说），进到了某智能卡卡商公司，开发食堂智能卡。
代码测试都很正常，就是并发承载能力一般，不过同时刷个四五笔还是可以的。
本着实用主义精神，性能无所谓能用就行的态度，我打电话问食堂平常吃饭人多么。答：做的太难吃基本没有人来。
于是信心满满，下发到某高校食堂直接使用。
收拾东西回家睡觉。
第二天我就失业了。
学生发现在食堂吃饭刷了一定笔数之后，吃饭突然不花钱了。
然后他们发现由于食堂的小卖铺也是用卡收费的，买零食饮料也不花钱了。
于是所有学生都跑到食堂去刷零食，食堂小卖铺直接被学生拿空了。
我想那天一定是一个非常开心的日子。
学校来找公司要钱，公司说你直接走吧，工资不发了赔给学校。
我后来算了算，工资应该不够赔的。嗯，大企业果然有担当，我觉得我应该是赚了。
事故三：
失业了之后我就去了另一个卡商上班。
听说我去对手公司，我的老领导很开心的在我的离职报告上签了字，并且加上评语：此员工贼牛逼，本集团庙小容不下此大佛云云。
新公司业务跟老公司几乎重叠，因为有上一个公司的经验（事故经验），反而顺风顺水干了不久带了项目组。
后来有一次让我去跟一个祖传屎山。
这个项目已经被 n 多程序员和产品经理轮了 2n 遍，代码逻辑混乱，各种编码风格迥异，文档几乎没有。
Bug 情况是诡异的进程消失，运行一段时间之后，程序自杀了……
我改了好几个星期终于定位到具体位置，发现原来是内存溢出了。
当然为什么溢出，我哪里会知道。
那一块代码上面有上上上次的工程师的注释：
//do not touch
//one touch then die
想尽办法之后，我在溢出的方向给了 3 倍的内存空间，并且增加了守护进程。你要自杀，对不起，我不允许。
收拾东西回家睡觉。
第二天，公司一片混乱。除了我的组以外，其他的项目组的模块都崩溃了，那几个经理都哭了。
代码找了问题找了很多遍，怎么找也找不到问题，况且以前好好的。
客服一直在给客户道歉，我的组员们都在边上看笑话。
然后老总很聪明，让那个没 Bug 的项目经理来解救众生。
由于通宵加班还在睡觉的我，就被电话催到公司来了。
得知问题的我淡定一笑，偷偷的把我的程序进程用命令杀掉。
然后，都好了……
大抵超级英雄都是这个样子罢。
事故四：
超级英雄就要有超级英雄的待遇。
于是每周的技术分享，我就经常是站在台上哔哔扯扯的那个。
其实原本我挺喜欢这个安排的，因为不但周五下午可以不上班，还可以摸鱼，装作很认真听的样子，然后神游太虚。
但是我不喜欢在台上，每天绞尽脑汁想给大家讲什么是很痛苦的事儿。
最后实在没辙了，想想还是讲代码吧，正好可以把现在的项目查一遍。
于是拿出了祖传屎山。
屎山一出效果无敌，大家都精神了起来，都想看看这传说的代码是个啥子样子。
于是我口若悬河尽情的吐槽这个代码的垃圾，一段一段的分析写这段代码时候程序员的精神状态。
讲到精彩之处，听众都会开心的向我丢中性笔。
有一次，竟然在过程中找到一个 Bug，这个 Bug 极其的低级，大概就是 i++ 和 ++i 之类的前后赋值问题。
这个人上头了就要干傻事儿，和精虫上脑了一样。我突发奇想想看看这个代码是谁写的。
打开 SVN，在各个领导的众目睽睽之下，发现更新日期定格在半个月以前，作者是我自己……
直接社死……
再写一个事故吧，这个不是我的，是我师弟的。
某市尝试机器分校，小升初试点，系统吖做的。
正式分校前一天，内部测试预分校，准备先给领导看看。
问题领导有很多，年纪都不小了，输入个账号密码也是费劲儿。
于是打开鉴权，发布公共访问链接，给领导们看了个云山雾罩、走马观花。
主管领导看完表示：知道了，明天分。
吖高兴，关机、下班、睡觉。
公共地址没关……
晚上此链接在各个家长手中以各种方式传播。
经过内部人士鉴定，域名没错就是分校结果无疑。
第二天正式分校结果出炉，所有家长发现分校结果变了，自家孩子原本是重点的，却后来分到普通校。
家长认为，这绝对不是系统问题，也不是自己的问题，定是有贪官作祟，抢了她家娃的名额拿出去卖了。
一时之间六大门派围攻光明顶，机关门口挤满了人，要求杀尽贪官污吏、内惩国贼。
领导说，即便你有委屈有不甘，你看外面的人民群众，需要个交代。
……
于是，第二天公司就地解散。
后果不只是简单的赔钱丢人。
这些翻车事故在云栈社区也经常被开发者们拿出来分享和复盘。每一次大 Bug 都是一次血泪教训，也让后续的代码审查、权限管理和发布流程多了几分敬畏。
来源： https://www.zhihu.com/question/482967292
发表于 昨天 18:09
|
查看: 10|
回复: 0
