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

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

当时有一个特别的职位叫作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