代码改变世界

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

2017-11-15 17:08  lixiong  阅读(1096)  评论(1编辑  收藏  举报

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

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