一个程序员星人，无论他(她)用的是 Python 还是 Java；无论程序是运行在手机还是服务器端；无论写的是底层还是应用，只要你对他说出下面的话：

        『你开发的这个程序 crash 了。』

他就会条件反射：        

        『这怎么可能！』

… …

Debugging stories are fun! This is a collection of links to various debugging stories.

What I don’t understand is why schools don’t teach systematic debugging. It’s one of the most fundamental skills in engineering: start at the symptom of a problem and trace backwards to find the source. 

Why do we leave material out of classes and then fail students who can’t figure out that material for themselves? Why do we make the first couple years of an engineering major some kind of hazing ritual, instead of simply teaching people what they need to know to be good engineers? For all the high-level talk about how we need to plug the leaks in our STEM education pipeline, not only are we not plugging the holes, we’re proud of how fast the pipeline is leaking.

最近 fix 了一个 Go 程序系统线程数量暴增的问题，线程数量维持在2，3万个，有时候甚至更多，这情况明显不符合 Go 的并发原理。第一次发现线程数巨多是因为这个程序突然 crash 了，由于设置了程序可用的最大线程数，所以线程数一太多就会crash。

这个程序其实就是现在挺火热的 Swarm …

事情的起因是我们为 LeanCloud 结构化存储后端搭建了一个实验性质的小集群，使用了 MongoDB 3.0 和 WiredTiger 引擎。该集群在平稳运行了几个月后的某一天突然开始出现大量不明原因的超时。

按常规套路，我首先怀疑到 io，但是检查 iostat、dstat 和 iotop 之后便排除了这一可能。况且我们给 MongoDB 用的是 Intel 企业级 SSD，也不太可能在这里出问题。

… 

于是下意识地 strace 上去，发现这个线程只调用了一个 syscall：futex。所以，有什么东西是单线程处理并且还拿着锁……pstack 一下，只给了一个函数名 __evict_server。再没有更多的信息了。

在实际操作中，一方面，对日常生活中自然产生的问题，不可能给出独一无二、完全明确的定义；另一方面，如果不能就问题本身达成一定程度的共识，几乎可以肯定，最后找到的解决方案无法切中要害。这种时候，一般都是在为说话嗓门最大、口才最好或者资产最雄厚的人解决问题。

问题解决者的工作是为别人解决问题。对于想成为问题解决者的人来说，入门的关键在于把单一思维模式切换成多重思维模式，即从“能解决一个问题的人”到“能解决很多问题的人”，或者说“问题解决者”。