大区建设，“疫”不容辞 2020新年伊始，新冠疫情席卷全国。与此同时，运营商Y客户的NFV（网络功能虚拟化，Network Functions Virtualization）大区建设也在如火如荼进行着。2月底，刚回到北京研究所办公后不久，主管在eSpace问我：“出差浙江支撑大区建设，有困难不？”

看到这条消息，我的心里既激动又忐忑。一直盼望着去一线出差的机会，现在，终于来了；但疫情闹得厉害，这个出差机会来得真有些“不是时候”。来不及回复，我赶紧拿出手机查了疫情地图，还好，浙江是中风险地区。

客户的NFV大区是全球首个大区制虚拟化电信网络，在全国8大区、16个省有过万台服务器，承载过亿用户。同时首次引入IPv6（第六版因特网协议）等新特性，交付压力大，工期也火烧眉毛。而浙江子公司又是客户核心网云化建设项目的大区中心，项目交付面临更为艰巨的挑战。作为研发工程师，能出差一线支撑这样级别的项目交付，是非常难得的机会，也很有意义。

于是，几分钟后，我答复：“没问题。” 出发在即，主管送来了口罩和护目镜，朋友送来了消毒湿巾，在医院工作的高中同学把自己仅有的几个N95口罩，连同外科手套等防护用品都给我了。看到我晒出的全套物资，主管打趣道：“妥了，这装备都可以去高风险区域了”。就这样，全副武装的我，满载着大家援助的防护用品奔赴浙江。

第一次从研发到一线 越战越勇 抵达杭州后，要隔离2周，于是我还来不及欣赏“江南好，风景旧曾谙”的美景，便开启了在酒店隔离办公的日子。核心网CloudEPC解决方案版本经理张斌给我介绍了大区情况和出差任务，并安排我担任解决方案的研发问题总接口。

没想到问题很快就来了：隔离期间几乎每天12个小时以上的电话会议，会议中出现的好多专业名词我都感到陌生，只能像“小白”一样摸索，对一线、客户提到的任何一点都不敢有丝毫懈怠，竖起耳朵听每一个问题、记录每一处细节，生怕遗漏了什么。还有一堆之前在研发岗位从未遇到的组网、工具、资料问题，各种群组都在疯狂“艾特”我，催进展，甚至直接怼：“你懂不懂，搞没搞过交付”……

脑子里一团乱麻，我得赶紧振作起来——站在窗边，望着壮阔的钱塘江，深呼吸，心中默念很多遍：可以的，可以的！

梳理好工作思路，我给自己定下“改进三部曲”：第一，任务管理，将记录好的任务梳理成责任矩阵，逐一和家里对齐，明确责任人、交付时间，确保事情别在自己手里积压；第二，修习内功，深夜补齐网设、安装、周边网元等相关能力，确保在第二天沟通中能够听得懂，提升沟通效率；第三，外部对齐，主动给一线、周边同步进展，做到万事不被催。

就这样在紧张忙碌中度过了隔离期，我也学到了“三层组网”“灯塔”“脑裂”“一线、二线、三线”等名词。大家也不再催我，而是一起开心地讨论解决方案。一切步入正轨后，我才发现原来两周都没有给家人好好报一声平安，于是赶紧拿起电话，给家人介绍自己实际并未领略的杭州美景。

还没来得及歇口气，真正的挑战如期而至——承载30万现网用户的设备压力测试。这是NFV云化设备第一次在现网接受这样规模的用户量的考验。如何将云化设备与传统设备组成资源池，如何将用户迁移、让用户驻留，能否根据“1套CGW（控制面网关）和DGW（数据面网关）设备”的测试结果评估“多套CGW和DGW设备组合”的测试结果，需要重点监控哪些虚拟层的指标……一大堆问题扑面而来。我深刻意识到，在一线，我不再是单一领域的研发工程师，而是要从更系统化的视角去解决交付问题。

三人行，必有我师。技服、维护、研发“三”线专家汇聚于此，再加上家里的大师兄，他们成了我最好的导师，我也在解决交付问题过程中，搭建起了一座一线和研发沟通的桥梁。

4月8号晚，首次割接1万用户。现场，客户问，我们设备的内容计费怎么看？这正好是我在研发的代码责任田，我快速给客户讲解，并展示了对应性能统计指标。客户微微点点头。

4月9日零点，通过修改设备DNS（域名系统）权重，设备承载用户数缓慢爬坡；凌晨2点，按照既定方案加大割接权重，用户数快速攀升至30万。凌晨5点，路测全部通过，计费中心反馈计费正常、拨测系统业务稳定，健康巡检一切指标正常！

我们终于可以放心休息了。我趴在桌子上，头枕着胳膊小憩，那一刻，比睡在床上还要舒服。 压力测试通过后没两天，我刚刚梳理好测试报告，斌哥突然来问：“怀志，温州有个测试敢不敢去？”来杭州保障的这两个月，我早已克服对疫情的担心，越战越勇，没有半秒迟疑，立马答道：“走起。”

于是，分组核心网网关设备的计费准确性测试，在温州机房拉开了帷幕。

开始测试不久，客户突然拿来一张“异常”话单，质疑华为设备在某一个场景下的计费结果有问题。我们感到有点意外，之前在研发实验室验证时，没有发现有问题啊。究竟是什么地方错了呢？经过分析、用例发散测试，研发内部得出结论：该场景下的计费结果是正常的。之后我们立即整理材料向客户澄清，客户认可了我们的结论，并对华为的处理流程和响应速度很满意。

但没多久，客户又拿来一张话单。大伙一头雾水，又出问题了？原来是友商的设备上产生了一张错误话单，客户有些担心：“华为的设备是否存在同样的问题？”我们梳理了问题场景，会同研发计费专家团队分析论证，最后，我画了一张处理流程图，自信地告诉客户：华为的处理流程不一样，没有这个问题。再次赢得了客户的信任。

一周后，客户NFV一期大区FOA（first office application，首次试验局应用）入网计费准确性测试共19000+张话单，我司以零错误话单一次性通过验收。

最终，我司核心网云化设备30万用户压力测试一次性通过；计费准确性测试零错误话单一次性通过验收。5月18日，华为比友商提前近半个月完成NFV入网阶段全部质量要求验证，率先获得入网许可，为产品规模商用打下坚实基础。自研“黑科技” 实现“懒人梦” 事实上，大区版本的顺利交付，少不了研发领域多项“黑科技”的支持。其中有一项是我开发的Lua代码自动化检查工具，我给它起了个简单粗暴的名字 ——“Lua防护网”。

那是2018年下半年，分组核心网网关首个商用的CUPS（控制面与用户面分离）产品正在紧锣密鼓研发中。配置命令是产品功能的入口，在产品内部是通过Lua代码处理的，代码一旦存在问题就可能会导致产品的功能受损。CUPS产品在原有流程的基础上增加了多网元间的配置同步功能，使代码处理逻辑变得更加复杂。再加上对Lua缺乏有效的拦截防护手段，在版本研发初期，Lua代码问题层出不穷。

我是特性组的问题接口人，在处理问题的过程中发现：今天在A.lua上出的问题，明天可能又在B.lua上重演。测试同事经常提这样的“问题单大礼包”给我。

接口问题本已非常忙碌，“问题单大礼包”的出现，令我本不富余的时间雪上加霜。我想：能不能根据这些问题，分析提炼出来一些编码规则？再根据这些编码规则量化出一些检查点，开发工具来扫描代码？如果可以实现的话，那我们就可以通过工具扫描代码，提早发现问题，将问题拦截在开发阶段。

但白天电话和邮件应接不暇，时常被琐碎事务打断思路，我没有整块时间研究如何实现这个想法。只能趁晚上的空余时间，一个人静下来分析问题单，研究产品建模，自学python。像搭积木似的，每天完成一点点。

记得有一次晚上，在卫生间碰到开发部长轶哥，他问我怎么还不下班。由于我的工具还处在设计阶段，没有实质性成果，所以我没有坦白，只说：搞点别的，马上就走。轶哥一脸困惑地看着若有所思的我。后来，当他知道我是在做这项工具改进的时候，“埋怨”我没早告诉他：“有好的工具不应该只在自己的特性组用，我们应该推广。”

经过断断续续一个多月的投入，工具从无到有，有了雏形，第一次运行时，报出来几十处可疑点，在确认里面存在十几处功能问题后，我一下子就兴奋了——不枉我的投入啊！这下继续优化工具更有干劲了。

编码越来越顺，工具支持的功能点也越来越多，不久，我便实现了对自己特性组Lua代码的自动化检查。工具不仅能挖掘历史版本的问题，还可以通过定时扫描来拦截在研版本新需求开发引入的问题。有一回，工具播报出来当天新增的问题，负责开发这个特性的同事疑惑地来问我：代码这么写有什么问题？我给他看了下我根据工具整理出的历史问题案例分析，他恍然大悟。此刻我更加坚信：工具化是有意义的！

由于工具在我们组效果比较喜人，部门安排我来完善它的功能并在其他组进行推广。因此，我拥有了一小段可以专职投入这项改进的时间。部门又从每个特性组抽调人马，成立了专门的改进团队，我带着他们一起分析历史问题单、优化工具架构、统一各组编码风格、排查工具报错等。

众人拾柴火焰高。随着大家的投入，工具的功能更完善，检查点覆盖更全面，挖掘出了不少潜在问题。经过这一轮改进，工具能在1分钟内完成三千多个Lua文件的全量扫描，并精准拦截8类问题，产品Lua问题数也呈现出收敛态势。我们团队因此被评为“云核心网产品线战斗英雄团”，我也有幸被评为北研改进标兵。 改进不是一蹴而就的。在首批检查点部署完成后，再出现新的问题时，同事还会拉我一起分析能不能再增加检查点，通过工具拦截同类问题。不得不承认，每一次通过新增检查点，发现新问题的过程都是令人兴奋的。我们的目标是：通过一个问题，解决一类问题，做好产品的Lua防护网。 截至目前，工具可以支持检查15类功能问题，已全量看护产品Lua代码文件500余条，通过白盒手段将问题拦截在开发阶段。相信在大家的共同努力下筑起的这道Lua代码防护网，一定会成为高质量产品的守护者。

这次改进行动，让我也发现，能让未来变得越来越好的投入都是值得的，每天进步一点点，就会越来越好。我一直觉得自己是个“懒人”，不喜欢做重复的事情，或许正是这股子“懒劲儿”驱使我在工作中开发一些工具，通过编码解决工作中遇到的一些问题，替代复杂繁琐的人工操作，实现自己的“懒人”梦。现在亦是起点，归来仍是少年 还记得和华为的初见，是大学时参加了华为软件精英挑战赛。晋级区域复赛后，第一次来到北京研究所参观，自此埋下了来华为的种子。2017年，本科毕业后，我正式入职，成为一名研发工程师。

本以为编码竞赛之路至此告一段落，没想到，入职没多久就迎来第一届云核心网编程大赛。比赛是非常有趣的对战主题游戏，竞技双方通过程序控制来PK。我毫不犹豫地组队参加，还跟队友一起起了一个霸气的队名：象征着算法、质量、运气的“三驾码车”。在基本不影响业务交付的前提下，我们完成了紧张的算法设计和编码，经过层层对战，在数百支队伍中出线，杀入决赛8强。

作为晋级决赛的奖励，上级开发部给我们队发了两千多元的奖金。独乐乐不如众乐乐，我们决定用这笔奖金赞助一次部门活动，希望以后能有更多的同事能参与到编程比赛中来。就这样，那年初冬，一场以“三驾码车”队冠名的素质拓展活动在北京奥林匹克森林公园举行。

随后，我们继续参加了两届编程大赛。从2017年的“三驾码车”，到2018年的“AI小虾米”，再到2019年的“天码行空”，改变的是队名，不变的是热爱编程的初心。幸运的是，每年我们都晋级了决赛；不幸的是，差一点实力和运气，每次都是第4名，没登上过前三甲的宝座。

2019年参赛队合影@西安研究所（右一为作者） 结果也许不尽如人意，但其实也没那么重要。通过比赛，能够有机会学习新算法、接触新领域，每一次都有成长；还可以认识各部门的编码达人，结交很多新朋友。最重要的是：编程比赛的过程就像交付一个完整的产品，团队一起设计、一起编码、一起测试、一起调优，整个产品都是自己说了算，极尽编码之乐，真的很爽。

如果说，三届编程比赛，让我始终保持了对技术热爱的初心；那么，工具化改进，让我能通过编程解决实际问题，提高工作效率；一线交付，更让我有机会了解产品在整个网络中的位置，日后需求开发可以更贴近客户诉求、避免“闭门造车”。感谢公司提供这么多历练的机会，一路走来虽很艰辛，但也收获颇丰。

如今，我逐步担任产品维护版本PL和补丁经理的工作，短期内挑战巨大，但秉承“对代码充满敬畏”的态度，和“路漫漫其修远兮，吾将上下而求索”的信念，我相信，高质量交付补丁，守护现网平安，所有困难终究可以克服。

前路漫漫，任重道远。作为核心网设备的研发工程师，我们深谙质量和性能的责任之重，很荣幸有机会让遍布全球的数据业务奔跑在我编写的代码之上；很荣幸能参与到4G/5G建设，更期待以后的6G建设。长风破浪会有时，直挂云帆济沧海！

奔跑吧，华为少年！与君共勉，踏浪前行！