四年应届生到“软件总工程师”

网友投稿 588 2022-05-29

2007年高考报志愿,当别人还在纠结和犹豫时,我已经无比坚定地在志愿书填下了“通信工程”四个字。当时智能手机还没有普及,我拨弄着老式的诺基亚,总是好奇地想:电话是怎么打通的?那一端的人为什么能听到我的声音?中间经历了什么?被满脑子的问号所驱使,我迫不及待地想钻进通信的世界。

如今,我已经成为通信行业的一员,可以像电影里的黑客高手一样敲代码,甚至还顶着“软件总工程师”这样bling bling的光环,但那些环绕在我脑海的问号并没有减少:如何解决传输负载均衡问题?如何能让2G和3G、4G共享频谱?如何在大海里捞针,迅速定位现网问题?

问题越发棘手、刁钻,我只能逼着自己站得更高,钻得更深,探索未知。

每天8小时,半年写完一年的代码量

四年从应届生到“软件总工程师”

2014年我应届毕业,一入职就参与到控制器软件平台相关特性的开发中。控制器是无线网络GSM和UMTS制式的“总控台”,软件平台则是控制器的“腰”,承担着稳定客户网络的关键作用。

当时公司的控制器软件平台还在上海,我们13个研发新员工被派去承接业务,每人独立看护一个模块。当别人还在重复“看文档-改资料问题单-修改简单问题”的无限循环时,我主动向版本经理毛遂自荐:版本特性的开发,能不能交给我试试?也许是没料到新来的员工就这么“虎”,版本PL愣了一下,对上我无畏的眼神,竟然同意了这个“无理”的请求。

我主要负责控制器IP网络传输路径的负载均衡模块,这是控制器话务接入时调用最为频繁的功能点。“负载均衡”只有四个字,却异常复杂。控制器连接了众多网元,每条路径都有负载的瓶颈,过载就会丢包,导致语音失真、掉话,网速过慢等现象,引发运营商的投诉。

怎样能保证每一条链路的负载平均,不至于过载,同时让所有的链路达到最大使用效率?这个看似难以两全的难题,关键点就在均衡算法上。比如,装水的桶有大有小,容量各不同。按照以前的算法,100L的桶装的是50L的水,50L的桶也装50L的水,10L的桶也装50L的水,这样就造成一些水桶还没有发挥最大潜能,而与此同时,大量水桶的水溢出来,出现过载的问题。只有通过改进算法,让100L的桶有装80L的水,50L的桶装40L的水,10L的桶装8L的水,每个容器的承载率都是80%,保持均衡,才能实现鱼和熊掌兼得的目标。

刚开始,导师在一旁指导,一切进展顺利,我更是信心满满。可不久导师休假了,留下我一个人。一下没了可以依靠的臂膀,我只能在忐忑中开始奋战。我和SE、测试、维护一起组成“铁三角”,一起分析我们的目标场景是什么,判断现有算法是否能够满足,根据这些目标场景对齐方案。最终,特性开发最终满足了流量负载均衡商用要求,开启特性的现网局点再也没有听到负载不均的投诉。

在这个阶段,我每天12小时有8个小时和代码打交道,不是在写代码、看代码,就是在验证代码,半年写的代码量赶上了别人一年的量。当然,光有数量是没用的,质量过硬才值得骄傲。代码写完,都要上库去持续集成,任意一个代码环节出了问题,都会导致持续集成失败,出现掉话、断网等严重后果,所以我总是对代码保持着敬畏之心。有些开发人员可能会吐槽自己是码农,可如果心中有教堂,我们就不是码农,每一行代码都会转化为最有价值的存在。

让两条小河流入同一片土地

随着代码技艺的提升,我迎接的挑战难度提升了N次方,一个人Hold住全场的机会越来越多。

频谱是通信运营商赖以生存的“土地”,也是最重要的财富,特别是阳光好、灌溉便利、土壤肥沃的土地更是稀缺资源。随着MBB移动互联网时代的到来,“2G用户如何平滑退网”、“如何最大化GU黄金频谱的频谱效率”成了全球诸多运营商要面临的问题。2016年,无线“冒协议之大不韪”,提出了GU@5M解决方案,设想诸如900M这样的黄金沃土上,共用5MHz频谱资源,既种2G的高粱,也种3G的小麦。

作为控制器软件平台,我们的任务是打通整个语音报文合并的通路,换言之,就是要让两条小河一同流入种了高粱和大麦的农田,让农作物越长越好。

当时只有我一个人负责平台方案的设计,可现实情况是,我连语音通路怎么打通都不知道,更不用说把两条通路汇合起来,完全是一头雾水。但我这人一向是正向思维,想想,把一个大象装进冰箱总共分几步?第一步,把冰箱打开,第二步,把大象塞进去,第三步,把冰箱关上。那么,要让两条小河流入农田,其实也可以分解成三步:第一步,买铺路的原材料,第二步,制定施工图纸,第三步施工队进场施工。也就是首先考虑分配语音通路所需要用到的传输资源,其次,通过制定资源分配算法,实现资源均衡利用,最终将资源应用到语音通路架设中,实现合并语音流的传输。

为了确保解决方案能够走通,我们需要在一个由手机、基站、机房组成的模拟系统中验证方案。还记得那是任务截止日前一天晚上11点多,在成都软件大厦的实验室里,我们七八个人全神贯注地对着电脑,仔细观察每一条信令的走向,每个细胞都是紧绷的。当看到两路信号对接参数一个个冒出来,而且两者全都保持一致时,我们已经按捺不住激动的心情了。

我立马拿起2G的终端打电话,对方那头的“喂喂喂”的声音听起来异常清晰。“成功了!”我们激动地叫出声来,一直很冷静地坐在一旁的版本经理,突然一拍桌子跳起来:“太好了!”大家抱在一起又笑又跳,像孩子一样开心。

小系统达成验证目标后,成功支撑了后续上行COMP及GU联合调度等关键技术路径的开发,最终促成了整体方案转商用。GU@5M方案最终成功商用,使2G和3G的河水流入同一片麦地成为了现实,节省了频谱带宽资源,保护了GSM网络的投资,在全球各子网得到成功应用,成为无线最具价值的解决方案之一。

任务竞拍,只抢最难的活干

还没来得及庆贺,新的任务令又要发布了。2016年11月一早,我们部门20多号人挤在一个会议室里,准备进行一场竞拍。

“下一个任务是GL共频谱,200人/天工作量,谁要抢?”

版本经理的话音刚落,我就高高地举起了手中的竞拍牌:“我要抢!保证150人/天完成任务!”

显然,其他人都不打算举牌,我窃喜:“看来这回没有对手了。”

版本经理嘟囔了一句:“你这小子挺敢干的!”

自从2015年我们部门推行全栈工程师(FSD)制度以来,这样的场景每个版本都会上演。以前,我们要开发什么模块,承担多少工作量,都是由版本经理根据业务需要和每个人的能力来分配的,有很大的主观性,不一定能调动每个人的积极性,一些开发人员做的很可能不是自己真正想干的工作。而全栈工程师制度改变了这种情况,变“派活干”为“抢活干”。每个版本开始前,版本经理会把各项任务要求以及工作量公布出来。任何一个人都可以用竞拍的方式抢活,如果同时有两个人竞争,给自己定的目标高的人胜出。

我总是喜欢抢难度最高的特性,这些任务可能会直接决定业务的KPI,有些人可能会知难而退,可我觉得,机遇和风险是对“双胞胎”,不敢抢,就意味着自动放弃了机会。

这回,我早就盯上了GSM和LTE频谱并发特性,可以实现GL频谱动态共享,比起之前的任务,难度有过之而无不及。2G和4G(LTE)共用一个频谱,最大的问题是互有干扰,这就需要2G用户在使用时告诉4G用户“路径已经被占用了”,以便其绕道而行,我的任务就是建一个接口,让2G和4G通路之间可以互相沟通,以免相互干扰。

过程中有一个阶段特别难熬。任务涉及软件平台和硬件平台,我了解软件平台的实现,但并不知道硬件平台的约束条件。第一个方案出来后,硬件部门初步评估可行后,我并没有在硬件平台上验证,以致于快到迭代的时候,才发现底层硬件平台根本没办法支持现有方案。

还有一个星期就要迭代,一切还要推倒重来?周边各种压力纷至沓来,要求我做质量回溯的声音也很多:为什么一开始方案设置时候没有评估清楚?压力山大,最后的一个星期,我几乎把时间揉碎了用,经常熬夜熬到凌晨一两点,早上六七点再回来接着干。我这人心大,倒也没觉得崩溃,就是心里憋着一股劲:自己抢了活,哭着也要做完啊!

部门给了我很多资源,好几个专家和我并肩作战,帮我支招。大家一起想还有什么方案,难度多大,代码量多少,要花多长时间?接着在白板上写写画画,碰撞点子……一周后,我们拿出了第二套方案,在解决硬件平台适配问题的同时,把代码开发量压缩到了最小的程度。

意外的是,这套方案紧赶慢赶,居然赶上了迭代节奏,没有影响既定的计划,顺利完成了任务,也算是“越努力越幸运”的奇迹了。

24小时夺命CALL了解一下

2017年,我这颗不安分的心又蠢蠢欲动。做了几年开发,能力建立起来以后,我开始觉得自己过得太舒适了,就想折腾一下。想来想去,哪里是我们部门最难、最核心的业务?我想到了事故处理组。

这是我们部门专门处理网上问题的虚拟组织,无论节假日,7天24小时随时待命,处理GTAC转交过来的疑难问题,不仅要快速定位攻关紧急问题,定界恢复事故级问题,还要第一时间改进闭环网上问题。

在一些人看来,我的转身纯属自我“找虐”,但我不这么想,很多网上问题不只局限于软件平台,在这可以看到一个更大的业务链,对于个人的提升而言,是最好的练兵场。

压力是随时随地,无孔不入的,比如时间的压迫。事故级的网上问题,从上报到恢复要求在30分钟内解决。但30分钟其实是很困难的,控制器是一个很庞大的系统,仅仅通过有限的现象,如何知道问题出在哪个代码?真的像大海捞针一样。即使判断出问题,控制器也涉及和基站、核心网的对接,需要和其他网元一起操作验证,也很难保证在第一时间解决问题。

还有24小时夺命CALL的压力。如果要问一个维护人,最害怕的是什么?答案十有八九是午夜铃声。记得有一次,凌晨3点多,一个电话打进来,告知A国某版本出现2G单板复位的问题,导致一个区域的人打不了电话。我上一秒钟还是迷糊的,下一秒钟就被惊出了一身冷汗,放下电话,下意识就往公司赶。

回到公司,我立马开始查看日志、定位问题,一遍遍排查,到了早上7点多,终于揪住了问题的源头——不是平台的问题,而是2G业务出了问题。联系相关业务人员修复问题,很快,中断的业务得到了恢复。结束攻关已经是周末的早上了,本来想着躺下了歇歇,却发现自己脑子里还在不间断地放映攻关画面,竟兴奋地睡不着觉了。

这样的场景每一天都在重复,不久前,我们刚刚达成了全球网络控制器网上平安1000天的目标,这也算是对我们越来越少的头发和越夜越美丽的黑眼圈的最大慰藉了。

即将步入30岁的我,已经不那么锋芒毕露了,但依旧敢想、敢干、不怕输。每一年,我都会给自己设定要超越的阶段目标,努力成为每个阶段自己想成为的人,感受内心一点点的成长。

不管头衔是总工程师也好,是研发小兵也好,为了最初探索通信世界的朴素理想,我都会一直趴在软件上做精、做深、做透彻。我相信,只要愿意为自己走出一条路,世界就会为你打开一盏灯。

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

华为人期刊 程序员

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:【Flutter】屏幕像素适配方案 ( flutter_screenutil 插件 )
下一篇:只需十四步:从零开始掌握Python机器学习(附资源)
相关文章