三个关于 Debug 的小故事
昨天听podcast听到的，觉得还蛮好玩，分享一下：
1. Email发不超过500英里的故事
如果你是公司的 IT，有人告诉你公司的 email 只能发送到500英里以内的人，你会是什么反应？你一定觉得这是个大玩笑吧。事实上，故事的主人公也是这么想的，觉得那帮人有毛病。然后他随手一试，从北卡到亚特兰大，没问题。到华盛顿，没问题。到纽约，420英里，没问题。到孟菲斯，600英里，擦，不行了！
最后发现是因为 mail server 在 upgrade 的过程中降级了软件，从而导致软件的配置有稍许不同 — timeout 变成了 0，意味着 3ms timeout，刚好是 500 英里左右的距离！
2. 游戏无法存档的故事
这是一个游戏开发者的苦逼故事。他负责一个存档读档的部分，然后发现有一定的概率在写的时候会出错。读档存档非常重要，于是他调试了好几个月，把 code 剥离到最最基本，却发现还是会出错。后来他突然发现在游戏初始化的时候会设置一个较高的刷新频率，如果他在写档的时候重置一下这个频率就不会出错。他百思不得其解，为什么一个较高的频率会导致出错。直到有一天有个 PM 在看他调试的时候玩了一会儿遥控器，这个时候写档就失败了。他一把把遥控器抢了过来，再次调出程序，写档，玩遥控器，失败，100% 重现。
最后他把这个结果发给了游戏机厂商，还在日本。那边一开始也不信，直到看到了重现的文档，发现是控制元件之间的互相影响。
3. 系统夜间错乱的故事
一个苏联的工程发现他的系统经常挂，白天运行的好好的，晚上就会挂。排查的时候发现每晚都在某一个固定的时刻出问题，而这个时间总是有一趟火车经过。这趟火车不是普通的列车，而是从切尔诺贝利核泄漏站出发的火车，核辐射会对磁盘和内存造成影响以至于每晚准时宕机。而后工程师发现这些火车是运肉的，然后他就立刻离开苏联了。
这让我想到另外一个故事，也是每晚准时宕机的故事。而且当工程师去现场排查的时候，晚上就不宕机了。工程师以为是不是有老鼠，装了一个摄像头，结果发现的真相是搞清洁的阿姨每天晚上会拔掉风扇电源打扫什么的，一段时间之后机箱会过热然后故障。而当有人排查的时候，阿姨就不会拔掉电源了。