技术,是靠脚印走出来的

举报
技术火炬手 发表于 2019/04/18 14:17:57 2019/04/18
【摘要】 成长的道路充满荆棘,而收获成功后的喜悦早已冲散所有乌云,路途中的风景依然美丽

1a.JPG

2009年8月份初来尼代,至今兜兜转转已经接近7年,去过最拥堵的拉各斯,到过每到10月就起沙城暴的Kano,在美丽的Bauchi公园见过非洲大象,享受过Abuja一路飞奔的快车道。见证了在一群可爱的华为人一步一个脚印的辛苦付出下,尼日利亚通信业务的大幅提升。2009年时,绝大多数尼日利亚人民还在使用2G低速网络,我们当时还在用公司的CDMA网络的集团号;到2015年时,CDMA网络早已消失殆尽,随着2016年各运营商LTE的上线,用户进一步享受到了通信技术发展带来的“快车道”。

而我也从一个工程师逐步走到系统部TD的角色,成长的道路充满荆棘,而收获成功后的喜悦早已冲散所有乌云,路途中的风景依然美丽。

初入尼代   

2009年在国内完成移动端局和关口局业务上线后,在那个酷夏飞行了接近20个小时后终于来到尼日利亚拉各斯,走出机场后第一感觉是湿漉漉,雨季的尼日利亚居然比国内还凉快,让我预想不到。 在拉各斯没呆到一周的时间,就直接去往项目组所在地Kano办事处,开启了我在海外的第一个项目,也开启了周一早上驱车3小时从Kano到Kaduna,周五晚上回Kano的两点一线的生活。

当时所在的项目属于Zain运营商(尼日利亚Airtel前身),我司刚刚突破北部,需要在北部Kano,Kaduna,Bauchi和Abuja新建MSC(移动交换中心)和MGW(即时消息网关),项目的难点是这是尼日利亚首个硬件平台ATCA(先进的电信计算架构),且智能网需要通过友商私有协议对接,而我没接触过相关的协议,要学习的东西很多。项目组有技术大拿陈胜,此时的我就像个学生,在老师孜孜不倦地教导下快速学习所有新知识,那个时候每当和陈胜他们一起解决问题后,那种莫名其妙的兴奋如同上学时解掉一个复杂的数学题。在Kaduna的那两个月,白天机房,晚上宾馆,吃着本地人做的中国炒饭,虽然辛苦,压力也大,但每当看到自己在项目里能做的事情越来越多,技术上也越来越成熟,也就忘却了那份苦累,这也许就是我们这些技术人员成长的必经之路。

在学习中逐步成长,在前辈的指点下,在项目的磨练下,我快速对整个产品和协议吃熟吃透,这为后面独立开通Kano局点打下了坚实的基础,也让我收获了第一次成功的喜悦。从那以后我坚信世上没有吃不了的苦,只要勤勤恳恳,踏踏实实去做好每件事,成功的道路就不会离你太远。

第一次紧张时刻

来过尼日利亚的人记忆犹新的肯定是“轰轰”的发电机声音,在2010年时,市电供电能力每天只有4个小时,其余全靠发电机。而这发电机有时却又不停地“抽风”,让我经历了第一次紧张时刻。那时在Multilinks CDMA网络运营商做维护,晚上7点突然接到监控人员反馈数据中心机房温度急剧升高,第一时间升级到客户,并从客户侧了解到市电切到油机时,两台油机均无法正常工作,一时半会还解决不了。

我也是第一次遇到这种突发情况,在去机房的路上心情极度忐忑,毕竟数据机房里有我们的HLR(归属位置寄存器),MSC设备,这些设备一旦无法正常运行,那就是百万级别的用户无法通话和上网,影响不可估计。在升级到代表处后,领导们各方协调资源,联系各产品线技术大拿赶往现场,这让我坚信在公司的大平台庇护下,一切问题都会有效地解决,信心倍感增强。

进入机房第一感觉是扑面而来的高温,赶紧让客户将机房的所有窗户打开,客户也从库房里搬来了数个大电风扇,朝着我们的设备进行散热降温。此刻的我拉着本地员工逐个排查现网各个网元的运行状态,查询温度,看告警,排查KPI和语音数据拨测,确保业务可用性。一轮排查下来,当前业务没受影响,但设备的温度已经达到50多度,离我们的单板高温阈值已经越来越近,而市电迟迟不来,发电机也未见有修复的迹象,心中一万遍“凉凉”。

这时的我也只能做最坏的打算,和客户一起讨论各个网元故障后带来的影响,以及我们的应急预案,在20分钟内即将影响和方案梳理清楚,并同步给客户的高层和代表处。就在我们紧盯设备时,HLR的其中一个小型机由于高温突发故障,看着设备面板上红色的故障,赶紧前往设备排查发现是高温引起的磁阵异常,而恢复的手段只有等到温度冷却。这个时候我们立马将HLR Bypass的方案先准备好,并同步获取客户审批。

此时代表处也紧急协调了陈璇和郝小飞两名专家到现场支持,这也是我第一次感觉到团队的力量,心中那片乌云也逐渐散开。在坚持了2个小时后,市电终于来了,客户机房的制冷系统开始运行,我们悬着的心才开始放下来,这个时候才发现身上早已汗流浃背。但此刻我们仍然需要继续观察设备和业务,待机房温度彻底下降后,第一时间将HLR的小型机恢复,而这个时候油机也恢复正常。此时我们才如释重负,而客户也第一时间对我们表示感谢,也让我们体会到付出总有回报,那句简简单单的“well done”是客户对我们的认可,更是对我司维护的肯定。

走出机房时已是深夜,看着浩瀚星空,一阵凉风吹散疲惫的身心,回想着刚刚那一刻的惊心动魄,第一次感觉维护的不容易,也第一次体会到维护的伟大。

话单时长1s差异的痛点

2015年客户风险评估部门在稽查话单时,发现我们在端局、关口局、计费中心上话单的话单时长1s差异超过客户的预期(同一个呼叫在不同网络节点上生产的话单,差异1s,比如中国移动拨打中国联通的呼叫,在中国移动用户的话单是30s,但中国联通侧的话单是31s,这样中国移动就要多付1s的钱给中国联通),要求华为解决,否则将对我们罚款。计费关系到客户的收入,收到客户投诉后,我们立即启动攻关,在当时TD游少甫的带领下与GTAC、研发成立联合攻关团队,开始了接近一个月的7*24小时工作模式。

在明确目标和方向后,大家朝着“全营一杆枪”方向奔赴到各自队伍,分别成立了“现网配置检查组”,“网络拨测和分析组”,“话单分析组”,“客户协调组”和“总体组”。由“总体组”统一协调和拉通各个资源和分析结论对齐。如此强大的攻关团队,大家都是信心十足,也坚信没有华为解决不了的问题,在大量网络数据排查未发现问题后,大家聚焦到网络的拨测和话单分析上,而这2项工作又是全靠人工来做,为了样本数据能够达到一定的量级,每天拨测的数据都在1000次以上,拨测完后还要针对这些数据进行消息分析,再对比到话单(一天的话单量就达到50G的分析量),一天下来后感觉眼睛都在打圈,甚至在睡梦中还在拨测数据。

经过大量消息跟踪和话单分析,拉通机关GTAC和研发一起,将整体的流程和协议支撑进行匹配,基于客户现网的配置和历史上的变更,结论是我司当前的处理符合机制。我们前前后后多达几十次与客户沟通,将拨测数据、协议与客户进行澄清,得到CTO初步认可,但这个法国人仍然是眉头紧皱。我们也认识到,当前只证明我司没有因错误配置和产品能力导致问题,但客户问题依然没有解决,如何帮助客户进行优化,解决客户痛点,是我们开始思考的方向。

在大量样本分析下,我们的话单时长差异比例大概在1%左右,而客户预期的阈值只有0.5%。这个时候大家也产生了不一致的声音,我们按照协议且从当前数据分析来看,主要是信令传输和两端呼叫量的差异,话单差异的比例我们是否该投入更多的精力去做优化?经过一系列激烈讨论(协议上是否明确定义,产品是否有能力,客户满意度如何保障等),最终大家达成了一切以客户为中心的思想,我们还是要以帮助客户成功为目标。

我们继续深度分析了产品的能力和优化空间,开始对所有可以减少“1s”话单概率的方案再一次梳理,最终在传输协议模式上,OCS(在线计费系统)事件上报和SIP(会话发起协议)的拆线时间点上找到突破,在得到客户授权完成一系列的变更后,成功将“1s”话单的时延降低到客户的预期内,当我们拿着优化后的成果再次去找CTO进行交流时,CTO一连几次地对我们说“Well Done, Huawei always is best”,而他的脸上盛满笑容,让我们深深体会到只有帮助客户解决了根本问题/痛点,才是帮助客户成功。

2a.jpg

2200万用户一次性割接

2016年,客户对运营数字化和产品能力要求越来越高,我们成功引导客户使用华为计费中心OCS5.5替换原有1.3平台,在IT侧完成OCS5.5的一切准备工作情况下,我们面临着如何将现网用户平稳有效地割接,既要保证设备的升级换代,也要保障用户体验和减少客户的损失。 此次操作涉及将现网多套智能计费控制中心调整到OCS侧节点,共计2200万用户需要一次性完成割接,风险高,难度大。

方案中最核心的部分是需要梳理所有用户模板与OCS各单元的对应关系,将现网用户做相应的计费GT(全局名)数据修改,并对用户进行业务重置,保障用户可以正常割接到OCS5.5。2200万用户量级的割接,更是挑战之重,极大地要求我们将工作做精做细,任何一丝马虎都将带来严重的后果。

作为CT侧主要负责人,我负责核心网和软件侧10个产品与OCS拉通调测。大家共同作战,有问题互帮互助,发现问题及时上升,快速解决,加班加点赶进度,朝着OCS5.5快速上线的目标前进,在大家共同的努力下,比预估时间早1个月完成了业务集成调测。业务集成调测仅是迈入成功的第一步,割接是否能够成功还是未知数。  

割接方案与保障至关重要,在和IT一起讨论割接方案时,大家对每个步骤每个细节仔细斟酌,在碰撞中擦出火花,最初的设计方案是要将现网所有用户的智能网寻址地址全部修改为OCS侧新的寻址码,但该方案带来的最大缺点是,所有用户均需要修改再做业务重置,影响面很大。在不断的方案澄清,产品侧能力确认,大平台和软件双方的讨论后,我们成功寻找到一条新路,与其在核心网 上去修改用户的GT,不如反其道而行之。让新建的OCS寻址码与用户的保持一致,这样只要调整信令网路由即可实现割接,进而缩短割接时长。  

最终在OCS确认方案可行并落地,奠定了割接成功的基础。任何项目的成功都离不开我们这群踏踏实实做技术的人,也更需要我们这种精益求精,锲而不舍的精神,也只有这样才能将事情一次性做对做好。

新的起点

2017年,我从核心网的TL转身为项目组的维护TD,虽然之前维护核心网,会和周边众多网元做拉通,有着一定的多产品拉通经验。但随着TD的转身,逐步认知了TD的岗位职责,TD不仅仅要懂得技术、拉通,还需要介入售前,对技术方案把关,输出最佳成本方案,设计最优方案,同时也要懂得管理和经营。在走过两年的维护TD道路后,我也摸索了一些自己的方法论:主动性维护管理,网络安全规范化操作,CS标准化动作运行,看网讲网识别网络风险和机会点,客户声音管理,重大事件事前、事中、事后协同作战,共同保障。正是因为有了这些方法论和团队的共同作战,确保了网络安全,两年来无客户投诉,系统部也在地区部CS排名持续保持在TOP行列。

2018年开始接任系统部TD, 新的转身新的起点,前面的道路相信不会一路平坦,但只要坚持对技术的学习,积累与沉淀,扩展视角,必将踏出一条康庄大道。成长的道路纵然万般曲折,只要我们始终追逐心中的梦想,朝着目标去奋斗,终究会“凤凰涅槃,浴火重生;鹤啸九天,火舞人间。”

技术的道路永无止境,随着5G的到来,以及尼代在数据业务、IMS、VoLTE上的发展,要领悟和学习的东西依旧很多,果实固然好吃,仍需同志们辛苦栽培,相信尼代定会再次崛起,大有可为。

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

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


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。