越过山丘

我现在有个“毛病”，一些常人看来会怦怦心跳的事情，我已经没有特别的感觉了，这也许就是十年维护历练出来的。好在，认识老婆是好几年前的事情，要不然可能连老婆都追不到手了。

做维护就像翻越一座座崎岖不平的山丘，攀登这一路满是艰辛，回头望，精彩的风景已在脚下。

我成了会议妥妥的“C位”

2017年9月8日，某C局点，MSC（移动交换中心）上部署一个功能后，BSC（基站控制器）上位置更新掉话率出现异常，需要回退操作同时分析原因。

这不像以往的操作那么简单，如果回退，会影响另外一个部门Y设备的现网部署。他们的设备要在现网交付，必须和我们的设备对接来获取数据。一回退，他们就获取不到数据，无法部署了，直接影响一线的销售收入。Y部门研发主管、一线销售主管都非常着急，轮番给我们部门主管打电话，希望问题尽快解决，最好不回退。

而偏偏那个时候，我们产品好几个问题在同时攻关，一个组七八个人都投进去了，只有我一个人被派过来支撑。Y部门来了14个人，从维护经理、PL，割接操作实施、产品各模块、到电话那头的一线，纷纷把注意力投向我。

“BSC上的指标有什么影响？”

“什么原因引起的BSC指标变化？”

“MSC开启功能后，流程是什么？”

“MSC的指标有没有变化？”

“能不能不回退，失败原因是什么？”

……

大家你一句我一句，不答复吧，怕人家说你态度不好，答复吧，谁来分析问题？那一刻，我恨不得自己能像孙悟空一样长出三头六臂，或者拔一根毫毛幻化出无数猴子猴孙来解答所有问题。我当仁不让地成了会议的绝对C位，紧张得手心冒汗，从没想到自己有一天会站在这样的聚光灯下，还是这种方式。

情况紧急，再紧张也要强制自己静下心来分析问题，这就好比，一个人专心写代码很嗨，突然一堆人站在你面前看你写。

饭要一口口吃，路要一步步走。一次专心做一件事。于是，我定了个策略，请对方部门出个接口人，我统一答复，如果还有问题，内部先讨论。这样一来，争取到时间来分析问题了。终于，经过一下午的奋战，根因分析清楚了，短暂回退了之后，当天凌晨，客户执行了我们提供的解决方案，所幸没有对项目进度有大的影响，终于长舒一口气。

这个5小时，过得比5天还漫长。此后，不管再遇到多么棘手的现网问题，我都会让自己先冷静下来，心里默念“不紧张、不紧张“，然后再开始处理问题。

美味的“烫手山芋”

如果问一个维护人什么是“双活”？他可能会皱起眉头，深叹一口气。双活的现象就是你打电话给别人，一切都正常，但是别人打电话给你，就死活打不通。

这是由于手机注册的信息在两个MSC上都存在，当HLR（归属位置寄存器）记录的MSC信息和真实手机注册的MSC不同时，就会导致被叫失败。在2G和3G网络很少出现这种问题，但自从上了4G，双活问题就不断出现，每年大规模的双活局点越来越多，影响用户多、时间长，每次发生都需要团队攻关处理，客户感受差，存在事故风险。

引起双活的场景很多，很多场景都不是我们单一产品引起的，也就不是靠一家产品能搞定的，大家也试了很多方法，但效果并不理想，每次都需要人工介入，恢复时间长，最快也要4-5个小时，久而久之，成了老大难问题。

2017年3月，正值部门讨论全年工作规划，解决双活难题又被大家点名提了出来，双活一定要想办法解决，但是能解决到什么程度，大家都摇摇头，不知道。

主管突然把目光投向我，眼神中带着期许，这个问题便很快落到了我的头上。临危受命，如履薄冰，好在我之前已经在思考解决方法了，这可能也是我一贯的做事方式吧，每次处理完一个疑难网上问题，就会思考，下次怎么改进、具备什么能力才能在下次遇到此类问题，能够快速地解决？所以，对这个“烫手山芋”，我没有半点抗拒，并且当即就有了初步思路，先朝这个方向放手去做吧，梦想还是要有的，不试一试怎么知道呢？

我花了一周时间，联合服务一起，把可能引起这个问题的所有场景彻底梳理了一遍，理出六大场景，再一个个打开看，有哪些方法能避免这个场景不发生？从产品侧来看，我们需要做哪些事情，需要其他产品配合做哪些事情。有方法以后，推动实施起来，就没那么难了。

从3月到10月，从有了解决方案、开发、试点部署到全面部署，历时7个月的奋战，双活这一盘旋在我们心头的老大难问题终于搞定了。此后，很少再接到双活的问题了，即使偶尔发生，研发和服务也能很快搞定。

场景多样，我们的产品搞不定，就以为没有解决方案了？可能还是视野不够开阔。如果站在更高的层面，用全面系统的方法来审视这个问题，就一定会知道怎么解决了，而站在问题里，可能永远都找不到出来的路。

花183天才定位的死机问题

还有一类经常要处理的问题是死机，也就是进程复位。

几乎每年都会出现几次模块复位的问题，一般我们通过收集模块复位的黑匣子，结合死机调用栈，再排查相关模块的代码，1天左右就能定位出来。但是有一次模块死机的定位，却断断续续花了183天。

那是2017年5月15日下午，15：00整，突然接到W国家报告一个局点出现模块复位，一天复位5-6次。

我立刻收集死机对应的信息，不到一天时间，搞清死机是因为指针变量被“踩”了（即变量被其他变量修改，导致栈空间被破坏），但是被谁踩了？不知道。情况紧急，为了尽快恢复业务，安抚客户，先对被踩代码进行保护，发布补丁，问题很快得到解决。

可问题的根因还没有找到，不知道什么时候还会爆发，不知道其他局点是否也存在，我心里还是感觉到不安。为了彻底消除这个隐患，飞雷、老许和我3个人关在会议室，迅速排查，一起梳理每个蛛丝马迹，包括现网特性、异常呼叫模型、实验室模拟和现网差异、代码异常点，同时对引起异常的呼叫进行分析。然而，一周时间过去了，没有任何发现。

时间不等人，为不影响正常业务开发，我释放了集中攻关的资源，但是不安还是在心里无法抹去。接下来的时间，只要一有空我就去看下相关代码，有该局点的问题就看一下消息跟踪和日志。有时候也想，既然问题都不发生了，不去理会算了，但终究还是放不下。现网的坑和隐患，一定要挖出来，不挖出来，别人可能再跳进去，或者又发生了，这是对网络安全的不负责任。我想干维护的人都有这种“轴”吧！

时间很快，一晃就已过去了半年。我终于在处理另外一个运营商网络问题时，从收集到信息中发现了一个“可疑”的字符串，正常字符串长度小于16个，而这个字符串长度却足有两倍——32个。我隐约感觉这个异常点和之前的死机问题有关。

分析代码，发现是由于代码保护不足导致A数组越界了，但是这个越界应该踩到相邻的变量，为什么相邻的变量没有问题呢？我将进程文件反编译，发现编译器进行了优化，调整了函数调用关系，导致A数组越界“踩”到了D指针数组了。我这才恍然大悟，不同编译器对代码优化的逻辑原来是不一样的。这也同样适用于困扰我多个月的死机问题啊！问题终于真相大白，只怪自己懂的还不够多。

从发生问题到找出原因，历时6个月，183天，这也是我定位时间最长的一个问题。之后，我把这个异常排查加入到代码静态检查工具中，防止后续存在相似越界问题。根因找到后，我心里的石头终于落地。跳出常规思路，打破砂锅问到底，思路的开阔性也许就是这么练出来。

有人说我懂得多，其实我只不过比别人多处理几个网上问题而已。每次处理完之后，我都会多问几个why，多查几个资料，多了解一点信息。处理一个问题，只是一个点，再想想这个点是做什么的，有什么功能，然后把问题发生的来龙去脉了解清楚，再发散一下，下次处理此类的问题就会更快。处理问题多了之后，连成一片，点便成了面。

我想做任何事情都是这样，经历困难就像翻越一座又一座高低不平的山丘，要坚信成功，还要从中学习和反思，方能百炼成钢。

-------------------

本文为《华为人》版权所有，未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com