他刚进公司被问最多的是：20万行代码，搞得定不？

20万行代码，搞得定不？

“你肩上扛了20万行代码，搞得定不？”这是我刚进华为时听到最多的一句话。

2008年9月新员工培训完，我没有回西安，而是直接飞到上海承接产品。刚进上海项目组，就受到了热情的接待。

“这次西安来了多少人承接我们模块?”上海X模块的PL问我。

我愣愣地指了指自己：“就我一个”。

“什么，就你一个？我们组有20万行代码，赶紧反馈再加人。 ”

其实，刚出校园的我对20万行代码并没有太多概念，但是看到他的反应，顿感不妙。我赶紧找到在其他项目组承接产品的西安PL，却得到了安慰，“没有想象的那么严重，你那块业务我也知道一些，我给你分析看。X模块代码逻辑比较简单，Y模块基本不出问题可以暂时不学，这样……这样……你只要集中把这几个模块搞定就行了。 ”

加人是不可能的，于是我的培养计划也相应有了变化。入职前两个月，我每天的任务就是读代码，下班前半小时给全组讲解。而同期其他新员工在入职一个月时已经开始处理问题单和开发需求了。第三个月中期答辩时，其他人的胶片上呈现的都是“处理了XX个问题单，开发了XK代码的需求”，而我的胶片都是模块的代码功能介绍。

学习期结束后，20万行代码的威力很快得以体现。为了让我快速熟悉业务，项目组把活最杂的接口人工作安排给了我，负责所有的网上问题、实验室问题定位以及几个高风险模块的问题单修改。很快，我就淹没在电话和邮件的海洋里，焦头烂额。

“问题定位没？邮件都发好几个小时了，环境不保留了。”

“这个问题我分析应该是你们模块的问题，快看下，下班前没结论我就转单了。”

“怎么回事，你名下问题单怎么不见少，版本都快过不了点了。”

……

是的，我成了各个组的“焦点”，同时也开始变得焦虑，虽然每天凌晨才回公寓，依然无法阻止上窜的DI值（问题密度），这下该如何是好？

很快，导师和PL注意到了我的窘境，伸出了援助之手。看现象，找原因，和我一起分析现状，一件一件分析手头的事务，传授四象限工作心得，把眼前的事务按照四象限法则排好优先级，再一一击破，慢慢坚持一段时间后，我终于开始变得从容起来。

就是为了晚上能睡安稳觉

转正之后，我很快就遇到了第一个网上问题，并且经历了一次深刻bug修复过程。依稀记得那是周日，凌晨两点，电话响起时我感觉像是刚躺下就被叫醒。

“我是在一线支撑的测试经理，新版本升级报错了，需要马上解决！”

“好的，什么情况？先尝试做下这几步恢复操作，再收集下日志，我马上去公司。”一听是现网的问题，本来一脸迷糊的我瞬间清醒，这可容不得半点马虎。快速穿好衣服，打车直奔公司。

还好，问题很快定位，之前现网的服务器出现过网卡故障，客户把服务器拆封，两块网卡拔出来擦拭金手指，插进去的时候交换了插槽位置，导致网卡的PCI总线编号发生变化。为了防止客户私装其他网卡，引起兼容性问题，新版本代码做了强制校验，但对于这种更换网卡位置的场景，却没有考虑到。

“这谁设计的功能，画蛇添足！老版本都没问题，这是致命bug，我要求必须回溯！”虽然功能不是我开发的，但听到电话另一端的措辞严厉，也感觉像犯了大错，不敢吱声。这次的经历，让我再后续很长一段时间，一接到网上问题电话就非常紧张。

网上问题引起的风波还没过去，修改这个网上问题的任务就落到我头上，没有想到的是这次修改也不顺利。代码很快就修改完了，但是验证时遇到一个问题。由于老型号服务器存量并不多并且前几年已停止发货，三种老型号服务器，实验室只有一台了，其他两种类型的服务器没有办法验证，怎么办？

“代码判断的就是这几个信息，你可以通过模拟打桩，之前我都是这么测的”，在老员工的指导下，我很快完成了打桩测试，但心里总有点不踏实。

结果在版本内部转测试前的预验证环节，兄弟项目组的同事找到了我，他们的一台服务器装上新版本后运行不起来。我心里“咯噔”一下，不会是那两种没有验证的服务器吧？果然，经过实机分析，发现我用的打桩模拟方法和真实的硬件还是有差异。

对于这次的修改引入，PL特地过来辅导：“这次主要是你经验不足，不要太放在心上。不过我们也要好好想想，遇到困难，是不是尽全力了。”再次修改时，还是有一种类型的服务器没找到，感觉真的没办法了。

一大早我只好再求助导师和PL，几小时后，PL过来对我说：“我已经给周边几个部门打过电话了，有几台服务器可能是我们要找的，我带你去确认下。

又经过几个小时，我们终于在一个实验室的角落找到了一台落满灰尘的服务器。拍拍灰尘，一看，好家伙，这不正是我们要找的么！找电源，接线，上电，安装版本……看到版本软件顺利启动，心里悬了很久的大石头总算落地了。

“好，我们再把交换网卡顺序的场景覆盖下。”然而折腾了半天，网卡还是没拔下来。原来这个型号的服务器硬件设计上也做了防呆，卸网卡需要专用的小工具。

半个小时后，网卡终于拔了下来，PL手上不小心被划了口子，鲜血直流，他却蛮不在意：“为了晚上能睡个安稳觉，这点小伤，值了！”

后来每当看到“打造质量口碑，构筑质量文化的教堂”时，我想说我们的质量追求真的很简单，就是为了晚上能睡安稳觉。

没有定位不了的问题

“Hello，sir……”下班刚出公司，我就接到了一个老外的电话。竖起耳朵再加上熟练的“sorry”“pardon”，才终于搞清楚了，原来是之前在espace上交流过的印度一线小伙，马上要去客户机房操作了，还有两个操作步骤不太清楚。

从来没跟老外通过电话的我，一时语塞，面红耳赤，嘴巴几次想张但就是张不开，到嘴边的单词，就是说不出来。

对方还在时不时的“hello? hello?”以为我不在线。哎，平时都是由GTAC的兄弟帮忙沟通，这下没人帮忙了，这可如何是好……不管了，管他语法怎样，突然，一句“yes”蹦出了口，慢慢地，一个单词、一个单词地蹦出，虽然磕磕巴巴，但总算可以用英语交流了。

我在电话了说了一通，反复确认对方了解了我的意思后，才放下电话。一看手心紧张得都是汗。好在总算交流完了，顿感身心舒畅了许多。

就这样，入职两三年后，一切逐渐步入正轨，不管是遇到什么难题，我似乎都可以从容应对了。

不过，现网出现的两三起未定位的Linux系统挂死问题，一直是大伙儿笼罩在头顶的乌云。由于使用的Linux是几年前外购的版本，一直未升级，维测功能比较弱。而我们作为业务软件团队，也不具备定位这种疑难问题的经验，求助公司的Linux团队后，仍无法定位，只能以老旧Linux系统问题进行了答复。

没想到，不久，在一个大T局点又出现了这个问题。没办法，我们只能再次求助OS、硬件相关人员，快速组建了攻关团队。由于缺少日志，大家从软件硬件各种角度进行大胆猜测，然后在实验室进行故障注入测试，持续了一个月后，实验室连问题都没有复现，更谈不上定位，所有人都很沮丧。好在新版本软件已经合入了挂死时自动复位的自愈功能，问题影响可以将到最低。一线也接受了自愈方案。第一次的集中攻关就这样心有不甘地以失败告终。

出来混，迟早要还的。问题攻关永远不会缺席，只是来得晚而已。大半年后，中国区的一起Linux挂死问题拉开第二次攻关序幕。由于是晚上出的问题，一线还没来得及处理，我们请求一线保留环境，立刻协调了公司Linux和硬件的专家马上出差到现场定位。

“这次抓到第一现场，总算能定位了。”我心里想。可惜从一线并没有传回好消息，只是进一步确认，确实是Linux系统挂死了，原因还是不知道。一时，又陷入僵局。

但是攻关不能因此停滞。我们再次静下心来，继续分析日志，看代码，分析这几个问题找共同点，很快发现这几个问题涉及的设备都是在运行了快一年左右时出现了问题。莫非与单板的运行时长有关系？累积效应的故障模式？大家很快调整了攻关方向。不久，就找到一篇关于Linux内核内存泄露的案例，经过计算，在我们的单板上正好在一年左右Linux系统一些关键内存就会耗尽，出现系统挂死。真是踏破铁鞋无觅处，得来全不费工夫。

后续我参与甚至主导过多起耗时长久、艰苦卓绝的疑难问题攻关，Linux系统挂死攻关在这些问题中不是影响最大和最紧急，但却让我受益最多。经历过这次攻关后，面对任何疑难问题，我心中都有一个信念：在我司，从来没有搞不定的事，也从来没有定位不了的问题！

2014年到2017年，由于工作调整，我转战产品开发，暂时离开了网上问题处理。2018年我又重新回归。

又是一次半夜紧急电话，我急匆匆赶到GTAC的攻关室处理紧急问题，一进门，又见到以前的几位老伙计：“看见你来我就放心了”。这句话一时间又让我浑身充满了力量！