不擅长与人打交道,他凭啥在华为“活”下来?

文摘   2024-11-23 07:03   江苏  


作者 | 吕志畅
来源 | 华为人 心声社区
投稿 | funqitown(微信)


保持一颗金子般的好奇心

文 | 吕志畅


我是一个不擅长与人打交道的人,要说有什么本事,可能就是学习能力和动手能力还算可以,也耐得住寂寞,对技术还有点好奇心。小时候,我算是个安静的破坏大王,曾经把闹钟、风扇等都拆了一遍,就为了看看它们里面是怎么样的。长大后,从步入IT行业的第一天起,我就决定在技术这条路上坚定前行。


对我而言,技术是一种兴趣,我会主动钻研自己感兴趣的技术领域。有点沉闷的我,在技术上却是一个不安分的人,愿意去探索各种新兴技术。




“布料上印花”,助我加入华为


上学的时候,我所在的实验室主要做嵌入式Linux开发,我们用C语言在Linux系统上做各种应用和系统开发。这是一门非常重视实践的技术,但我也深知理论对于实践的重要性。因此,那几年我把《C程序设计语言》、《UNIX环境高级编程》和《Linux设备驱动》这些专业书都认真研究了一遍。我会因为一个复杂的问题而彻夜难眠,会因为一个新概念而反复思考,凭借这样一份“执着”,我对嵌入式Linux开发有了更深的理解。


当时,我们实验室有个给校外的合作企业做数码印花机的数据处理系统的项目。数码印花机可以将数码图案直接打印到布料上,但因为系统的处理性能不高,限制了数码印花机的工作效率,让企业蒙受了不少损失。我和小伙伴们一起投入优化中,我突然想到可以从“Linux是如何实现多线程”这个方向切入,进而决定从线程调度方向开始优化。就这样,在客户车间经过一周的调试,我通过不到10行的代码,为客户创造了实实在在的经济价值。当年,我在客户公司还看到了一些准备采购印花机的非洲朋友,心想自己做的东西能够帮助到非洲的朋友们,我心中不免有一丝自豪。


毕业找工作时,我投递了华为IT产品线的岗位。前两轮面试我因紧张而表现平平,自觉发挥得不是太理想。终面的时候,面试官先是问我有什么自豪的事情,我详细讲述了那个优化数码印刷系统的故事,他听后露出了肯定的表情。然后,面试官问了我一道关于C语言里变量声明语法的题目,他给了我十多个变量声明的语句,其中夹杂着大量的数组指针、函数指针、指针函数等晦涩的语法概念。但是,一看到题目,我激动坏了:这不就是那些年我钻研过的C语言吗?我指着题目中的各个变量,逐个说明它们的变量类型,不到1分钟就全部回答出来了,对接下来几个追加的提问也都应答如流。面试官很惊讶:“很厉害啊,真的是200个人中只有1个能全部回答出来,而且还能回答得这么快!”就这样,靠着对技术的钻研精神,我拿到了华为的Special Offer。



“好奇心”伴我在华为成长


我校招选的岗位是当时最热门的IT产业。倒也不是为了蹭热度,而是出于我自身的好奇心:“云服务这东西是怎么回事?各种XaaS是什么意思?”我想要搞明白这些问题。


入职后,我被分到IT产品线,参与IaaS(基础设施即服务)的开发。入职第一周,我就后悔了。之前在学校里,我写惯了Linux/C代码,现在突然转到一个异常陌生的领域,我只懂一点Java基础语法,Spring、Tomcat这些新知识我都不懂,连最基本的IDE(集成开发环境)我用得都不熟练。那段时间我特别迷茫,经常不在状态,好在我的师父兼PL(项目组长)老朱觉察到了端倪,他主动开导我:“新员工刚进来不熟悉业务是很正常的,慢慢来,不要有太大的心理压力。而且,你现在不会只是因为你没有学过,并不是因为你学不会,你花点时间看一看就会了,肯定不必别人差!”


“学?但我也不知道从何学起啊?”我不解地问道。


师父继续耐心回答道:“首先,你要对我们的业务系统有整体的了解,这个可以拉着MDE(模块设计师)老祖和辉哥,一起把整体架构和业务流程好好过一遍;然后,针对你负责的业务模块,你要明确上下文和相关联的周边模块;最后,直接从代码入手,逐行分析,有不明白的地方就随时问。”


一番对话后,我感觉自己的状态好多了,仿佛从未知的恐惧中找到了方向。


那时,新员工转正前都是早上8点打卡,我对自己要求严格一点,我会在7点半准时到工位。每天早上,我都会学习业务知识和专业技能。我基于MDE梳理的模块和业务知识,分阶段安排好学习计划。


内容确定了,但是具体执行起来还是有点困难,比如开源模块和周边组件这类内容,内部可参考的资料并不多。那时,我发现官方手册是一个非常不错的学习资料,虽然枯燥晦涩,但却全面且权威。那段时间,每天早上我都会一边翻着手册,一边做实验验证,慢慢找到了学习的乐趣。那段时间,我系统性地把业务模块学习了一遍,并且高质量地交付了所负责的模块,完成了国内首家异构计算服务的上线。


转正后,早上可以9点打卡,但我还是改不了早到的习惯。在很长一段时间里,我还是每天早上7点半到工位,继续利用这段时间来满足自己对技术的好奇心。随后几年,我在产品线内先后辗转过当时最新奇的AI算法和性能倍增这两部分业务,其间有过面对未知的痛苦,也有过豁然开朗后的喜悦。我通过不断的技术积累,主导了机器视觉全息路口雷视拟合算法实现从0到1的构建、解决了海量存储芯片替代的BCM问题,在为构建万物互联的智能世界的进程中不断贡献着自己的一份力量。渐渐地,我发现如果能保持一份对技术的“好奇心”,没有什么技术是学不会的,也会帮助我们不断探索新的技术领域。



“开源”和“内源”,我们两个都要


2022年,产品线大力发展虚拟化这一新业务。恍惚间,多年前的记忆突然涌上心头:那是我刚开始学习Linux系统时,我在电脑的Windows系统上用虚拟化软件装了Ubuntu系统。我当时很好奇,操作系统这种软件按理应该直接跑在硬件上,现在怎么还能跑在软件上呢?难不成“硬件”是靠“软件”实现的?我查了一些资料,但怎么都看不懂,最后只知道这叫“虚拟化”,再后来也就不了了之了。现在,我有机会弄清楚什么是“虚拟化”,我很激动。


来到新领域后,架构师陆续给我们讲了网络虚拟化业务的全貌和未来的规划,从SDN(软件定义网络)、控制面和转发面的分离解耦,到Overlay和Underlay网络,再到连接和隔离、网络和安全,这些新奇的概念瞬间填满了我的大脑,并再次点燃了我的好奇心。


不久后,在做DCS(数据中心虚拟化解决方案)网络多租的第一个版本特性时,我接到了一个任务:需要构建上层的网络虚拟化管理面。我带着满腔的热情投入工作,但这个工作不好干。要想快速做出一个东西,唯一的办法就是在现有的基础上修改,也就是大家常说的“复用”。


我们决定基于一款开源软件Neutron来构建平台能力,这是开源云计算平台OpenStack的网络组件,也是一款成熟的网络管控面组件。但我们只想使用Neutron这个单独的组件,因此我们首先要将Neutron从OpenStack中解耦出来单独运行。将一个模块从复杂的系统中拆分独立出来,过程看似简单,实则却充满了挑战。因为模块之间的交互和依赖关系复杂,能借鉴的经验很少,我们需要细致的分析和大量的论证。


体内的学习本能告诉我,应该先对事物建立一个整体的感性认识。因此,我研读了几篇介绍OpenStack的文档,了解到OpenStack的各组件是按照微服务的思想设计的。既然是微服务,那就是一个个单独的运行态进程,只要把这个进程解耦出来就行了。我继续查询文档分析,一个个依赖软件浮出水面,我的思路也渐渐清晰起来:首先需要将Neutron的依赖梳理清楚,保留数据库和消息队列等仍需要继续使用的部分,其余的则通过打桩进行隔离。


然而,如何才能获得一个可运行的Neutron软件包呢?难道我要去分析OpenStack的构建流水线?不行,成本太高了,时间来不及啊!


深夜,坐在电脑前,我看着屏幕上闪烁的代码,急躁爬上了眉梢。突然,我灵光一现:既然是Python代码,那它的依赖包安装和进程入口函数等内容都应该是按照社区标准方式定义的,我只需要把它当做一个普通的Python包来对待就行了。我仔细看了一遍文档,很快就搞定了Neutron的软件包。接下来,我迫不及待地马上拉起Neutron进程。然而,出现了一堆报错信息,提示缺少关键配置参数。


我竟然把配置文件给忘了!我看了一眼代码目录,一个熟悉的目录出现在我眼前——etc,凭借多年的Linux使用经验,我坚信那其中一定有Neutron的配置文件。但在这个目录中查看一番后,我有点失望,里面并没有配置文件,只有一些看不懂什么用途的脚本。失望之余,我看到里面还有一个README文档,我打开一看:好家伙,原来是为了保证配置文件和代码的一致性,需要通过脚本从代码中动态生成配置文件,这个隐藏的配置文件总算被我找到了。


依赖组件、Neutron软件包、配置文件都准备好了,再经过一番调试,我成功地单独拉起了Neutron进程,并下发了业务。调通了!喜悦之情难以言表。就这样,凭借着严谨的分析逻辑和谨慎细致的验证,我逐步拆解、解决了问题,最终快速完成了Neutron解耦运行的原型验证。


原型有了,接下来就要进行具体的业务适配了。那段时间,我没事就会翻开开源手册和开源代码,了解一些内部代码的实现细节。还记得,我们遇到了一个协程调度死锁的问题,刚开始根本无从定位,困扰了我们很久。我们陷入了困境,这个死锁的问题就像一个狡猾的幽灵,悄无声息地潜伏在代码深处,让我们无从下手。按照以往经验,如果能导出调用栈等数据就能获得非常有效的定位信息,但我们采用的Python语言是解释型语言,以往使用的调试器无法发挥作用。尽管我们在调试器里做了Python的扩展,但也只能导出线程的调用栈,无法导出协程的调用栈,还是无法解决问题。


直到有一天,我突然意识到,业界应该也会有类似的问题,那他们是怎么定位的?我开始四处查找开源技术的博客和手册,试图在其中找到可用的线索,终于在一份手册中找到了“将协程调用栈等诊断信息导出”的方法。凭借这些诊断信息,再加上对业务流程的梳理分析,我们终于顺利解决了死锁问题。


还有一次,我们要将管理面Neutron的原生数据库MySQL替换掉,对接公司自研的一款高斯数据库。刚开始,我们以为只是简单地替换数据库驱动,但没想到这款高斯数据库竟然没有为SQLAlchemy(Python语言的一款ORM对象关系映射框架)提供配套的驱动代码。研究几天之后,我们发现想要在短时间内自研出驱动代码,根本不现实。但解决问题的方法有很多种,我就开始公司内源社区里“淘金”,终于找到了一款类似场景的驱动代码,适配修改后竟然完美解决了问题。从此之后,“从开源和内源社区中学习”也成了我们团队思考和解决问题的利器。我想,拥抱开源和内源,是这个时代的技术人都需要具备的一项生存技能。


伴随好奇心的驱使以及对开源和内源社区的不断探索,我作为网络多租服务SE,主导完成了网络多租管理面Neutron整体框架的设计与搭建,完成了硬SDN场景网络多租中各个关键特性的设计开发,还和团队成员一起从0到1构建起网络多租服务,切实提升了DCS解决方案竞争力。


团队合照(右三为作者)



写在最后


“好奇心不灭,技术人永不止步!”这是我送给自己的勉励,也是我一直以来努力的方向。如今,我在广阔的技术天地间不断解锁一个个好奇的关卡,不断钻研技术,不断提升自己的能力。希望我能继续保持好奇心,继续行走在探索的路上。接下来,我依然还在虚拟化业务这片领域里摸爬滚打,打造最强的全栈软件,让DCS成为替代VMWare的最佳选择,使能数据价值,攀登IT巅峰。


来源/《华为人》作者 杨宇蒙

风起堂观察/为您讲述华为奋斗者的故事


风起堂观察
讲述大佬传奇故事,解读商业智慧和管理方法,分享科教文领域价值观点。
 最新文章