我在华为度过的 “两辈子”（学习那些在大厂表现优秀的人）

Posted 2023-02-28 神技圈子

“七”是一个很神奇的数字——

生物学中认为组成身体的细胞，七年会彻底更新一遍；

李笑来说，七年就是一辈子，每一辈子至少要习得一个重要的技能，进而获得不可逆的重生；

白居易写道，“试玉要烧三日满，辨才须待七年”……

如果说七年就是一辈子，那么我在华为已经度过了整整“两辈子”。

当图灵大道的玉兰遍地盛开，我迎来了到华为的第14个春天。刚入职那会儿，我也如同眼前这春景般朝气蓬勃，对以后的日子充满期待。

2008年毕业后，我加入华为UAP（通用接入平台）团队做语音播放业务的维护，接触的第一个产品做语音播放和语音会议功能。

生活中最熟悉的应用场景就是用户给运营商客服打电话，在没接通前听到的一段语音播报“您拨打的电话正在通话中，请稍候再拨”就是我们团队做的。这个产品在我长初期，对我提升最快的不是技术方面的“硬本领”，而是思考如何去定位定界问题、如何冷静应对现网问题，以及如何应急处理突发状况这些“软能力”。

“诚朴雄伟，励学敦行”是我母校校训。“踏踏实实记录好所有遇到的故障和处理的问题，再一步步把产品做稳定”是我入职后导师的“师训”。从被领进门起，师父时常提醒我“记录比记忆更重要，坚持把日常工作中遇到的问题记录下来，整理成产品不断优化的方向，久而久之，低级的咨询类问题自然就消失了。”也是在师父的耳提面命之下，我把日常维护时处理过的问题和故障分类整理成文档，日子一久，竟然真的积累出一套支撑问题定位的“红宝书”。这个记录和复盘的习惯也成了我后来“几辈子”的工作准则：品质等于投入，时间在哪儿，结果就在哪儿。每天改进1%，优化资源，提高效率，说不定人生从此大不同呢？

承接“PaaS平台”

2020年8月， GDE（GTS数字化中台）服务与软件平台产品部团队接了个“大单”——自主构建PaaS平台，这个大单要从2015年公司很多部门陆续构建PaaS平台说起。PaaS平台为客户提供一个完整的云平台（硬件、软件和基础架构）用于开发、运行和管理应用程序。公司希望统一标准建造一个全功能平台，避免重复投入，确保功能相近的情况下造出来的平台能够通用。

“这是公司层面使用的平台，范围覆盖广，提需求的一定很多，接手平台后，对方还会发版本吗？1000多万行代码，加在一起就跟个大雪球一样，还有团队支持吗？GDE支撑的业务场景差异巨大，从极轻的工具场景，到海量现网实时数据采集，这么多复杂场景和业务，在同一个产品上实现时，就需要有非常多的技术手段来解决，如果定位不清，会不会重蹈覆辙？”当主管沟通希望让我接手自构建平台时，我还沉浸在思考这几个问题中，还没等我想好如何一一回应这些问题，主管突然抬起头认真地问我：“那你要放弃接手平台吗？”但听到主管问要不要放弃的时候，还是脑袋一热，不假思索地马上回答：“当然不！”我的人生字典里从来没有一个不字，怎么可能随便放弃呢。

答应只需要一分钟，但接下来的磨砺远比一分钟要长的多得多。

我不仅要搞定之前担心的所有问题，还要满足契合轻量化、高性能、大规模的业务场景。GDE除了现网300多个局点的维护，还要开发新特性、满足快速迭代的业务场景，除了支撑运营商领域，还有企业场景全面上GDE，支撑全球客户数字化转型，对这个只有三十几个同学的团队而言，相当于要在一缸大米中找出10颗红豆。

但让我惊讶的是，当我带着使命忐忑地回团队宣布时，大家竟然欢呼雀跃——“娜姐，这个平台很有意思，搞起！”“娜姐，我们感兴趣，剩下的就让暴风雨来得更猛烈些吧！”

这群年轻人的干劲和乐观精神让我很感动，大家身上努力的品质和实现自我的渴望，重新定义了什么叫“Younger”。

黎明前的黑暗

团队开始投入自构建PaaS平台后，我们不仅要在4个月内发出第一个自构建版本，还要大幅度改进产品的可交付性，以便现网开局能够批量商用可复制。

作为架构师和committer（代码提交者）委员会主任，我负责产品的架构设计和代码质量把关，通过对合入代码检视、定期组织代码飞检来提升代码整体质量，以及白盒评价（代码质量关联绩效评价结果）来牵引大家追求“clean code”。这期间，我在轻量化裁剪、大容量和性能优化，还有工程能力提升等技术突破点中自由发挥，更加爱上了“左手架构图，右手亲手实现”的感觉。

但我们还是陷入了浩瀚的代码海洋，版本出包更是放缓了整个团队的速度。就像组队打游戏一样，最初每个人的技能都差不多，但往往因为没有合理利用属性牌而未能发挥最大实力。

出包最初，大家每天都是几班倒，结束后再验证升级，直到确认整个版本的功能可用后才能转测，而到转测这个点基本已经下半夜了。

“娜姐，我好像陷在里面出不来了，天天都是安装部署和升级，还要花大量时间等，我已经在公司睡了好几天了。”小伙伴疲惫地撑起耷拉着的眼皮。

“是啊，我今天凌晨三点交给下一个人验证，再过仨小时天又亮了……”大家从最初的斗志昂扬，一边自嘲，一边渐渐有些迷茫。看着这群年轻人的眼里渐渐黯淡，我心里既着急又心疼，一边鼓励大家黑夜过去光明必然到来，我们现在处在平台起步阶段，短暂的阵痛期是必然的，一边暗自下决心，一定要带着大家挺过去。

为了快速通过“新手村”，我在代码海洋里深潜，在这环环相扣的关卡中，找到了平台必须的组件，裁剪掉了非必要组件，清晰梳理出组件间的依赖关系，调整至互不依赖。这些招式果然卓有成效，我带领着全队迅速晋级，我们又重新制定计划，从工程出包到编译出包再到极限压缩，确保最大程度发挥每个角色的优势。

出包完成后，我们到达“中级村”，迎来令人忐忑的平台版本安装环节。安装至少要花费2小时，其中单个服务很容易出错，如果跑到某个服务时资源不足，便会把系统CPU“压爆”……在安装环节，我和团队临近崩溃，差点耗光精力值。

怎么办？我对现状做了一次系统梳理，发现“妖怪出没的速度=组网数量操作系统数量升级路径”，每一种组合都需要在代码里增加分支判断，找到影响因素之后，我开始根据现实调整策略，决定采用全部卸载重装的方式，来避免多重路径的连锁反应。春节假期的几天里，在原先因数据不一致导致安装异常的卡点，我通过分析数据结构、反复尝试，终于将原型版本调通了！

原型版本合到正式代码仓库之后，终于，两天后的晚上9点，聊天窗口弹出一通消息——“升级成功，业务升上来了！”消息一出，群里热闹得炸开了锅，通过卸载重装的方式我们终于一次搞定了所有妖怪。

然而短暂的开心之后，该面对的问题还要继续面对：如果我们想要验收一个问题单已经解决，并且修改不会引入其他问题，全量测试的话，要进行多个物理形态上验证。现网近300个局点的版本收编，23条升级路径7种组网，都要升级到第一个自构建的版本。这难度，跟《西游记》中玉帝让鸡去啄完米山才肯给凤仙郡降雨不相上下了吧！好不容易搞定了问题定位，接下来能带领大家走向光明？我又开始绞尽脑汁。

成功在谷底破局后

“探索一片全新的未知领域时，试错是必经的过程，如何降低试错成本找到一条大致成功的必然道路……”脑海中的声音不断环绕，我头痛如正在被念紧箍咒的孙行者。今晚早点回去吧，让大脑先放松一下。我破天荒第一次早早回到家中。

打开电视，《觉醒年代》正在播出，看到新青年们纷纷把自己认为最好的思想用来救中国，把“实践出真知”理论奉为圭臬，一路探索最后成功找到了适合中国的特色社会主义道路，我忽然有了灵感，那就大胆实践吧！时间窗宝贵，与其因担心而畏缩不前，不如积极尝试调整！

我尝试着用领域建模重新定义架构来判断可行性，希望能在实际过程中找到解题的钥匙。这就像在各环节紧密相连的流水线上生产一台机器，如果某个过程出现故障，必定会影响整条生产线，我重新梳理架构的动作，相当于把机器组件拆成多个部分，各个领域之间互相独立开，关联性强的零件划分到一个领域中，各自加工互不影响，这样加工的速度也就快了，最后直接组装好就行，过程中不管哪个环节出现问题，整条产线正常运转，不需要停下来等单部件修好再跑！

随着思路的转变，我们很快做出来第一个版本。但由于算法原因，出包时间、压缩时间很长，而高效交付意味着包得小，所以这一版本并不理想。我们绞尽脑汁，在各个压缩工具之间选型，尝试各种压缩算法，可不是压缩比例不够，就是压缩效率不足……直到春节前夕，大家都一直没试到最佳路径，十分懊恼。

这天，群消息突然闪了起来，“大家伙儿，我测试过了，我开发的这个工具脚本能在3分钟内搞定！”此时群里面热闹起来，“真的吗？能经得起我们检验吗？”经过多位同学的测试后，这个压缩算法果然行得通，我们顺利找到了效率提升的突破口。没多久，团队里的另一个小伙伴又集成了最新算法的压缩工具，第二天就迅速把工具推送到了所有打包流水线上，并行编译、并行压缩，原本3小时跑完的代码现在10分钟搞定，我们成功了！一个人走得快，一群人走得远，团队一起的力量超过想象。

“最后一公里”通关

2021年初，我们开始进行收官冲刺，为了更好交付产品，团队小伙伴们对各模块进行性能调优和运维重构。胜利让我们尝到了甜头，还想再往前探索一步，从整体架构的角度考虑每个组件的必要性。

但很快我们陷入了纠结，就好比建房子，是在老房子上砸墙装修呢，还是把房子推到重来呢？如果我们选择不重构而是在老代码上修补，很难平衡性能瓶颈，无法真正改善居住体验；如果选择重构，又面临着人力不够的问题，同时担心动作太大砸到承重墙……掐来算去，自研人力一只手就可以数过来，重构到落版本至少需要60人干1个月。

“重构吧！”大家最终下定决心，希望能把性能提升100%_{200%，资源降配50}70%，将整个房子修葺得焕然一新！

我们把思考后的设计方案放在第一个大版本里，先打地基、把水电修好，带着两位小伙伴改善运维监控的可用性。直到产品界面体验、功能完备度、性能稳定度稳步提升，我们才算勉强完成了重构初版，算是有了一个勉强能住的房子。

迭代周期和交付节奏飞快，因此我们下一个要解决频发的问题单。我从代码看护角度想到办法，一边检视代码，保证新合入代码的高质量；一边微重构已有的功能特性，小步快跑，这就像在高速路上换轮胎，手把手逐步带着大家做到“clean code”。

终于在2个月后，我们将产品彻底稳定下来，这时的性能和资源较老版本有大幅提升，小规格套餐的集群管理规模提升，能够管理的集群规模也增加了一倍。这让力求商业交付完美的我们成就感满满，装修完验收完成了，整个屋子焕然一新！这一刻，“通关”路上“逢山开道，遇水搭桥”的勇气和坚持显得弥足珍贵。

后来，我们的“瘦身秘籍”开始在平台内推广应用，效率提升效果明显，在GTS产业里面有数百套局点，比之前云上平台资源降配到了70%，原来要十几台虚拟机才能开局，现在最少只需要一台就够了，大大节省了资源和投入。核心技术具也有较高的适用性和借鉴复制价值，周边团队赞不绝口的说：“多亏你们团队钻研技术，ADO（华为固网业务敏捷数字化运营解决方案品牌）软件包从10G降到了3G，真牛！”

后记

啃源码、多动手、持续学习就像是不断累积的筹码，而时间就是最大的杠杆。在公司的“两辈子”里，我很幸运能跟随产品一起成长，走在一条起步荆棘但无比正确的道路上，看到GDE Kernel作为云原生PaaS平台，成为服务于运营商业务、企业业务、Cloud&AI服务工具的底座压舱石，我很自豪。

感恩主管们的指导和并肩前行的团队小伙伴们，在我的低谷时期，总不吝给予最暖心的明灯指引——“Follow your heart，决定了就坚定地走下去！”