关于调试，有一个真实的故事我要讲一讲

我的第一份工作是在微软中国做技术支持。主要工作就是远程帮助微软的客户解决微软平台上的研发问题，比如内存泄漏，崩溃和死锁之类的。遇上难题我们还会用工具直接连接到客户的环境中调试。在极少数情况下工程师也会到现场解决问题。

当时有一个特别的职位叫做CPR，全称是Critical Problem Resolver。只有极少数非常优秀的工程师才够得上这个称号。任何别的工程师解决不了的问题都可以上报找更高级的工程师帮忙，这个链条的顶端就是CPR。

在我职业生涯初期，有一位CPR给了我非常多的帮助和指点。即便十多年过去了，这段经历仍旧是对我影响最深刻的。当时学到的一些技巧，即便十多年后我展示给同事看的时候，还是可以震惊全场。而这位CPR也是有史以来微软最年轻的一位。

今天要讲的故事不是关于这位CPR的。而是流传在江湖中另外一个CPR的故事。

这要追溯到2000年左右。有一个传统企业开创先河决定用微软技术自主建设企业内部IT系统。当时IT系统可是只有银行，电信这样的企业才会投入的。而且通常都是采用IBM或者SUN的大型机中型机，系统也是UNIX系列比如Solaris。采用wintel系统自主搭建IT基础设施在当时可是先河之举。该客户还额外和微软签订了咨询顾问服务。

研发结束，上线前夕，这套新研发的服务在生产环境上测试时候总是莫名崩溃，而且毫无规律可循。当时技术支持远程跟进了很多周，还是一筹莫展。逝去的时间也逐渐消磨客户的信心。眼看工程的截止日期已经不远，微软让一个CPR到现场去帮助解决。

该工程师到了现场，日以继夜地调试，排查，分析了一波又一波的dump文件，尝试着各种方法。几天以后，该工程师对客户说，生产环境的硬件坏了，你找供货商换一下就好。

客户非常的震惊，然后发怒。认为微软找不到问题就把锅踢到硬件上去。要知道当时硬件服务商可都是牛气冲天的外资企业，不会没有缘由就换硬件的。更重要的是，服务器配件当时可不是made in China，都将是要进口空运的。等硬件运来，时间也过去了，如果问题没解决那真是就没有退路了。

客户最终同意换硬件试一试，但要求微软答应一个条件：如果新硬件不解决问题，要求微软对客户前期的投入全额退款。

工程师给领导解释了下状况，领导们商量了一下，完全信任工程师的判断，答应了客户的条件。

该服务在新的硬件上运行很多天后问题都没有再发生。这就是这个故事的结局。

这个故事在我的心里种下了一颗种子。我当时就想，什么时候我的技能也可以让我在调试器中分辨出硬件问题，什么时候我才能足够自信要求客户因为程序的崩溃去更换硬件，如果还我做当时的领导，我有勇气完全支持工程师的判断吗。

十多年过去了，虽然我还在微软，但早不做技术支持了。在Azure Compute组，我们管理微软所有的服务器，包括Bing的和Azure的。我们写的软件服务运行在每一台微软服务器上，整个Azure和数据中心都是建立在其之上。

十年前做技术支持的时候，我会因为客户的某一个程序崩溃而担心，希望服务进程永远健康运行。今天客户都迁移到云上，我会因为云宿主上的服务进程崩溃而担心。在过去的几年里，我也调试过很多次莫名的崩溃，我自己的代码也差点导致极其严重的故障。我在dump里面看到过疑似的内存故障或者磁盘故障，但我却从来没有活生生的在调试器里面见证过硬件的问题。那一颗种子还在那里，直到上个周末，2017年的双十一，我终于捉住了一个机会。 http://www.cnblogs.com/lixiong/p/7818247.html