从疑难杂症中挖掘“宝藏”

陈星虎

2009年6月，大学毕业，我同时拿到华为和C公司的offer，班里的同学都说：“签C公司吧，听说工作轻松点，大家还能继续玩耍，一起工作”。可我觉得华为是国内最好的通信公司，可以和最牛的人一起，学到最先进的技术，是多么好的机会啊！老爸看到我的纠结，对我说：“你一定要遵循自己内心的选择才不会后悔。”于是，我加入了华为，来到了西研所无线网络OSS大家庭。

这一晃，就是十年。十年，不过是时间长河里的惊鸿一瞥，于我，却是人生一段充实而精彩的旅程——在一个优秀的团队，和一群有想法的人，做一些有成就感的事情。

不称职的球迷，称职的“守门员”

2010年6月，入职不到一年的我，“幸运地”参与了南非世界杯的通信保障。由于是世界杯，场馆和周边都是重点保障区域，客户的网络运维人员需要实时监控场馆的通信指标。可就在开幕式前不到一周，实时监控反复出现丢数据、自动取消监控的现象。

版本经理老谢立刻前往一线查看具体情况，项目组了解这块业务的其他老员工全都出差一线支撑其他项目，这个问题自然而然地落到了留守的我的肩上。眼看4天后就是世界杯了，再看看眼前这个棘手的问题，感觉自己就像热锅上的蚂蚁般坐立不安，好久不长的口腔溃疡也出来凑热闹了。

时间紧，任务重，唯有尽快行动起来，想尽一切办法把问题搞定。于是，我开始搭建测试环境、在环境上跑业务、熟悉代码和流程。我还第一次主动协调网元的兄弟一起攻关，模拟重现问题场景。经过整整三天不知疲惫的奋战，终于，在世界杯的前一天，给出了解决方案。解决问题的那一刻，心里的石头总算落了地，呼吸都变得更加顺畅了。

世界杯开幕式当晚22:00，隔着6个小时的时差，我一个人守在西安的办公室，和远在约翰内斯堡的老谢打着越洋电话，以全新的方式迎接世界杯的到来。

我：“实时监控正常不？”

老谢：“嗯，暂时没有发现问题。”

我：“客户现在创建监控任务没？”

老谢：“暂时没有。”

我：“能不动先别动，以不变应万变。”

我突然想到比赛，忍不住问：“你在那边能看开幕式不？精彩不？”

虽然我是个不折不扣的老球迷，错过了等待4年的世界杯，但在赛场之外做好“守门员”，保障世界杯通信，比看一场完胜的比赛还要畅快淋漓。这样一种特别的观看形式，比以往任何一次都有意义。

怀疑和直觉，让我有如神助

可能是骨子里有种不服输的劲儿，我对网上问题总有一种“迷恋”。2013年，我成为北向性能组的维护PL。当时项目组人员新，模块问题多，问题数量长期霸榜，我总觉得时间不够用。有时候骑自行车下班，脑海里翻来覆去的还是怎么解决问题，想到一点什么就停下车，记在手机备忘录里，第二天再接着分析。所以一大早到工位，我开口就是“昨天骑车时，我想到……”身边的同事总是打趣我：“你是不是一骑上自行车，就会有很多灵感？”

也许是习惯吧，遇到任何可疑的地方，我都要把逻辑想通，把代码想通。例如有的问题可能是磁盘空间满引起的，解决了磁盘空间的问题，就恢复了。但我在仔细读取日志时，还发现了数据库错误的信息，就会想，这个错误并不影响问题的解决，可是为什么会报错？必须把这点搞清楚才能心安。慢慢地，我在不断追问“为什么”的过程中，形成了一种直觉，就像代码的“坏味道”一样，我如果觉得“怪怪”的地方，很可能就是出问题的地方。

2014年10月，Z国J局点突发紧急问题，内存暴涨导致服务器不定时宕机，由于内存暴涨只发生在瞬间，不到1秒就消失得无影无踪，监控都无法记录到是什么原因触发的。

项目组小孙直接被派往一线现场支撑，强子在家里定位。看着强子紧皱的眉头，我意识到问题的棘手。

看了看局点授权返回的日志，依稀感觉和之前A局点的日志“长得很像”，尽管A局点当时的问题是其他原因引起的，但我留意过它还出现了内存跳变增长的异常，并“顺便”分析了原因。没想到，就是当时的“顺便”分析，让我此刻对J局点的问题恢复有了直觉。

“小孙，你看看客户是不是在集中任务中创建了一些MML脚本？”

 小孙：“有，咋了？”

“我怀疑跟这有关系。你让一线用鼠标点一下X任务，注意监控内存，准备中止Y进程。”

“我试试。”话音刚落，小孙就发现内存开始快速上涨。“涨了！涨了！重现了！”他惊讶地大喊。

“你把这个任务后台对应的结果文件移动一下，然后再重新点一下X任务。”

“我的天，不涨了！ ”老孙盯着我看了半天，简直不敢相信，在没有收集脚本、也没有监控到内存上涨的服务情况下，问题就这么轻易地解决了，一时说不出话来。

等缓过神，他忙问我是怎么知道原因的。其实我就是凭直觉，隐隐觉得这个问题和A局点的有相似之处，于是印证了一下，没想到这么快就定位好了。

还有一次，凌晨3点，A国Y局点系统运行缓慢，8100连环call。这个问题是“老大难”问题，两年时间里，每次出现都要通宵两天、脱掉一层皮才能恢复，所有人谈Y局点色变。

我揉着惺忪的双眼，确认得到客户授权后，远程电脑查看上百个进程，突然感觉几个打包压缩进程“怪怪”的，检查发现是一个XFTP （文件主动推送）服务触发的。我试着让局点停掉这个服务，果然，Med（网元连接处理元数据的服务）很快恢复正常了，性能也不延迟了。没想到，困扰两年的问题居然在30分钟内解决了！后来继续定位，我发现根因是打包压缩进程运行期间系统调用频繁，导致其他业务运行缓慢，奇怪的是在其他局点从没出现过这种情况，所以大家怎么也猜不到。

同事老王看到我一连串迅速有效的处理，瞪大了眼睛，一脸疑惑：“你用的哪门子“神功”定位的？”

哪有什么“神功”，我不过在疑难问题中不断怀疑、深入分析罢了。怎样从处理1个问题中获得10份经验？如果定位完问题，不对问题继续深挖，那就只能得到一份经验；而深挖一下，会发现，呈现在面前的居然是一座金库，里头满是宝贝，满是知识点。这些知识点在以后的某个瞬间可能就会帮到你，让你犹如神助。

维护要把人解放出来

作为一名维护人员，我还有一颗开发人员的心。我从一入职就开始写工具，后来我也要求兄弟们定位问题要工具化、智能化。

我们一直说“30分钟快速恢复问题”，但之前很多问题都需要人来定位，其实很难做到这个要求。2017年，我主导设计了EMS-FMA（网管故障运维助手）工具。当故障发生时，EMS-FMA自动对“故障树”每个节点的可能原因进行分析，得到故障原因。这就好比，一棵树上都是“故障现象”， EMS-FMA可以从树梢到树干、树根，层层还原现象的原因，定位根因。我们现在遇到客户端无法登录的问题，90%都是通过这个工具诊断出原因的。有了新的场景，我们就继续增加到故障树上，随着新问题越来越多，维护人员经验不断丰富，故障模式库也越来越完善，模式库就成了集所有维护人员智慧于一体的“大脑”了。

除了这个定位问题的工具，当前，我们正在探索让网络问题“自愈”的技术：通过机器学习辅助发现、定位、恢复问题。举个例子，数据库异常导致某个场景故障，异常是因为数据库里有一个长事务（执行时间比较长可能会影响其他业务的SQL语句）阻塞了其他事务。我们就开发了一个工具，定时去监控有没有长事务，有就“干”掉，系统就实现了“自愈”。还有一些是从产品能力去设计的，比如经常出现磁盘空间满的问题，我们就主动规划磁盘空间配额，分析每个模块的配额，让每个特性具备自规划的能力，以此预防问题的发生。

维护最重要的是防微杜渐，而这些工具起到的作用就是预防。通过智能化工具、维护工具、测试工具等，可以有效提升问题定位的效率，提升产品质量。而维护工程师有了过硬的维护定位能力和良好的开发技能，一定能在当前岗位做出不一样的价值。

回望这十年，工作和生活非常充实。我妻子也是搞通信的，非常支持和理解我的工作。儿子也以我为荣，经常自豪地告诉别的小朋友：“我爸爸是工程师，可以帮别人打通电话，我爸爸可伟大了！”不管是节假日还是深夜，每当出现故障需要加班紧急处理时，我说“有个地方的叔叔阿姨打不了电话，爸爸要去支撑一下，这样别人才可能打通电话”，他都会懂事地点点头，从不哭闹。

自律使人自由，我每年还会给自己提一个挑战目标。我想学互联网技术，就利用碎片时间学习各种技术贴，每天在朋友圈分享一篇，已经坚持了一年；我想跑步健身，今年就坚持锻炼，完成了首个半马；我想学尤克里里，于是每周发一首弹唱视频到朋友圈，坚持了一年，同事华姐还打趣地说：“我小孩现在每天都要看着你的朋友圈来学尤克里里了”。

未来，我还将以更饱满的激情，对生活更诚挚的热爱，迎接下一个更加精彩的十年！

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