初生牛犊，青铜开局
2019年，我入职华为后加入云化软件栈团队，顺利成为一名“云核少年”。此时团队正热火朝天地投入在云核心网PaaS（平台即服务）联合交付项目中，我也领到了开局的第一个任务——担任其中一个模块的负责人。
想到自己曾在大学期间以独立开发者的身份承接过网站开发、脚本开发等项目，有丰富的经验，接下任务的我更加兴奋和期待了。团队要将一部分业务从IT产品线承接到云核产品线，支撑云核构筑自己的电信云PaaS平台的能力。这意味着，我们需要全新构筑很多方面的能力，包括构建、持续集成、需求交付、缺陷修复、维护、发布……不仅如此，PaaS平台由几十个微服务组成，几百万行的代码量，要想弄清楚其中的机制需要花不少精力。这种大型系统对我来说好比一座大山，并非短时间就能翻越。
我意识到，自己只是一名“青铜选手”，面对商业化的大型产品，之前的知识储备完全不够，看着部门前辈们轻车熟路地开展着各项工作，巨大的差距让我陷入焦虑，甚至夜里常常难以入眠。
在一次会上，同事们展开了激烈的技术交流，可他们谈到的技术点我未曾接触过，甚至说出的术语我都听不懂，很难参与进去。会后，迷茫的我主动找到导师求助，导师耐心地鼓励我说：“维民，不用担心，现在PaaS这块业务是部门新接手的，很多人都是从零开始，大家其实站在同一起跑线。这个阶段对新人来说反而更有机会，只要肯付出、多思考，成为专家只是时间问题！”导师的一番话缓解了我的焦虑，我静下心来，制定了半年度“青铜成长计划”。
第一关，夯实基础。Kubernetes（容器编排平台开源项目）是PaaS平台的核心，使用Go语言编写，而作为一个Go语言小白，要想快速入门，“多看代码”是我从部门前辈处得到最多的指点。于是，我左手拿Go语言基础知识书籍，右手翻阅Kubernetes核心代码，反复消化理解这些代码背后复杂的架构设计逻辑。其中一个核心模块的代码我读了6遍，逻辑流程图慢慢在脑海中清晰了起来。
半个月时间里，厚厚的技术书籍被我啃了三遍。是否真正掌握了知识，要看能否输出和分享，怀着这样的想法，我尝试写总结，分享在博客上。没想到其中有一篇的阅读量近两千，看到有同事留言说“学习到了很多”，成就感油然而生。这段时间的积累也为后续工作打下了坚实的基础。
第二关，战场历练。正好此时项目需要一支小分队出差杭州与产品线面对面对接，我立马举起了手，主动向主管争取到了这个机会。
出差期间，我投入到AOS（应用编排）业务模块中，这是我第一次进行Go语言实战。PL（项目负责人）派给我一个需求交付的任务，我仅用两天时间便完成了设计和开发，写了50行代码就搞定了。在完成基本功能自验后，我迫不及待地提交了MR（代码合入申请）。这将是我职业生涯中合入的第一份代码，我仿佛看到自己就要达成里程碑式成就，越想越激动。
我兴奋地跑到committer（代码提交者）身边，期待他快点将我的代码合入进去。然而，对方抛出一系列问题直接把我问蒙了——“升级回退场景考虑到了吗？”“重启的异常场景怎么处理？”“低版本的兼容性考虑到了吗……”
面对这些检视意见，我哑口无言。committer解释道：“云核产品、电信云产品作为通信基础设施，一个现网问题会带来全面的影响，因此我们的平台要追求极高稳定性，我们的代码要高要求、严标准，各类场景要考虑全面，要对自己的代码保持敬畏之心。”这下我终于明白了背后的道理，转变了自己“能用就行”的思维，将每一条检视意见都认真修改和总结，对每一行代码加以锤炼。当我的代码最终被合入主干代码时，我的心中也埋下了一颗“高质量”的种子。
在出差的三个月中，我最终完成了三个需求的独立交付，圆满地达成出差目标。期间，我构筑了服务级的独立看护能力，也逐步熟悉了交付流程，完成了交付大规模商用产品的认知转变，以及对于代码质量、对于专业化要求的理解。部门主管还为我颁发了“勇于冲锋奖”，这是我职业生涯的第一份激励。自此，我也从“青铜选手”蜕变为“白银选手”。
白银锻造，拔掉“眼中钉”
2020年，在我接手看护的AOS责任田中，dsl-parser服务成为了“眼中钉”。作为一个网元模板解析服务，主体是在开源代码基础上做了侵入式修改，涉及模板文件和数据解析，逻辑极其复杂。因解析速度慢、疑难问题多且难定位、开源维护成本高等致命缺点，dsl-parser服务不断受到下游产品同事的吐槽，也成为了我的一块心病。处理了几个问题单后，我实在忍无可忍，萌生了重构的想法。
说干就干，周末我来到公司进行了重构方案的分析。我梳理出三种重构方案，分别是模块级部分重构、其他开源方案替代、Go语言自研重写。我将这三类方案的优缺点一一罗列，与架构师和软件专家交流后，大家一致认可自研重写方案最优，既能解决上述致命问题，又能保证继承性能力。但这个方案难度极大：整个服务接近3万行Python代码，涉及数据解析、类型转化等复杂逻辑，且代码可读性差，重构成Go语言的工作量估算出来约20人月，人力管道根本无法承载，dsl-parser重构陷入僵局。
随着云核产品线各类软件活动的开展，“高质量”“主动优化”“性能提升”这些词不断在我脑中萦绕，重构dsl-parser服务的决心也愈发坚定。我鼓起勇气向PL请求协调两位同事参与，我们封闭一个半月时间进行挑战。PL担忧道：“这么大的难度和工作量，三个人能搞定吗？”这个问题我已经深思熟虑过，是有信心实现的。因为业余时间，我一直在研究这个服务的核心业务逻辑，并尝试用Go语言翻译内核逻辑，从技术和理论层面论证了可行性，接下来就是花精力投入的事情。团队软件质量改进氛围浓厚，主管对此赞成支持，软件总工凌希也愿意深度参与进来，最终，dsl-parser重构以任务令的形式启动了。
接下来的这一个半月是我最专注的时光。前所未有的工作量和工作强度，反而让我充满了阶段性目标达成后的踏实与希望。看着“TOSCA（云应用的拓扑与编排规范）协议”“模板文件的读取解析”“数据结构的解析”“ DAG（有向无环图）算法实现”“拓扑关系依赖解析”“全量数据校验和解析”等各模块逐步被我们重写，而且重构效果在模块级测试中表现优异，我们看到了胜利的曙光。那些“撸代码”到凌晨的日子，我们仿佛忘记了疲惫，专注沉浸其中，享受着一步一步接近目标的满足。
一个半月的封闭结束，我们“三人小分队”通过合理的阶段目标制定和分工，以及使用TDD（测试驱动开发）的实践，完成了全部的重构工作。在那个周六下午，我提交了最后一份MR，将原有服务切换为新的自研服务，“割接”的成就感不言而喻。当然我也有一点忐忑，3万行规模的代码，重写后会引入多少问题呢？
我的忐忑很快被实际转测试的结果打消——最终的缺陷数仅仅是3，这让我们自豪不已。重构效果也非常好，性能表现和资源占用均得到较大优化，解析效率提升5倍，资源占用降低50%，并发能力提升100%，而且节省漏洞修复、开源维护十余月/年，直接解除了对Python语言的依赖。
云核软件能力提升工作研讨（左二为作者）
如今，重构后的代码一直运行着，“跑”在各个局点，没有出过一个问题，dsl-parser重构成为了我的“代表作”之一。
对软件的追求激励着我不断前行。除了高质量地完成交付，我每年都会给自己设立软件课题与目标。从dsl-parser服务级重构，到产品线十佳效率提升工具aosctl，再到公司级优秀实践gofuzzer，作为一名软件开发工程师，我不断锤炼和锻造自己的作品，输出高质量的Clean Code（整洁代码），贡献有价值和意义的代码。也正是这种更高层次的追求，让我从白盒优秀评价机制开始以来的三年，每年都被评为“白盒优秀”。让优秀成为一种习惯，我一直在路上。
铂金进阶，拿下最年轻的TM
“PL（项目组长）、TM（团队主管）从优秀committer中选拔”“循环作战，持续提升软件能力”，这是我们产品线第一公里的理念，号召大家在战线中展现实力、积累经验，通过大循环和小循环结合、第一公里梯队和专家的轮换锻炼，“选、用、育、流”的培养机制逐步成熟，造就了活力四射的部门氛围。
我在循环锻炼中受益良多。从核心开发骨干、责任田主、参与版本交付的subPM（领域项目经理）、再到作为组长带队交付技术项目、挑战担任补丁经理……前期的技术积淀和自身的不断总结迭代，让我在各角色轮换中游刃有余，Z字型历练也让我补齐并掌握了研发交付流程，逐步理解公司在流程机制上的背后逻辑。但我知道，过去这些角色转换只是部门内的“小循环”，成为“六边形战士”仍需更多磨砺。
2022年8月，跟随产品线“四跨（跨专业、跨部门、跨地域、跨海外）”导向，我结束在松山湖的三年时光，来到杭州研究所，将业务方向转变到了技术门槛较高的南向资源管理领域，参与存储和网络的业务。2023年，我迎来TM岗位的挑战，成为大家口中“最年轻的TM”。我对自己定下要求：“深入团队、深入业务、做好质量，身体力行”。
彼时，正值裸机容器业务交付的关键时期，FusionStage（PaaS平台）24.1版本将会在印尼IOH（电信运营商）完成全球首局裸机容器商用交付，所有人都紧锣密鼓地为首局和后续上量做准备，但是否能顺利入网，没有人可以给出肯定的回答。
经过多个版本交付后，我知道一个成功的上网版本，需要经过深层次的锤炼。团队的看护存储、网络业务又比较特殊，一旦出现存储故障、网络不通等问题，就会影响网元的核心业务，极易造成严重后果、引发客户投诉。
裸机首局，必须打响第一枪，我选择主动出击——启动裸机平稳运行专项工作。专项的意义在于深入挖掘隐患，降低上网风险，实现现网平稳运行。
“需求都交付完成了，测试也验收了，该做的也都做了，这样的专项真的有收益吗？”有人提出疑问。
“有。”给出肯定的回答后，我继续解释道：“这个版本的特点是多集群架构、多个重点特性、多业务场景、第一次商用，里面一定有很多没有识别到的隐患点，我们还有很多工作可以做，比如可靠性场景的系统分析、疲劳测试、以往现网问题的分析等等，这些动作目前是缺失的。我们这个专项，就算仅仅识别出一两个关键问题，都是有价值和意义的，大家都清楚处理网上问题的成本，产品质量决定生活质量，我们一定要把问题拦截在前端！”
在专项子活动FMEA（失效模式与影响分析）分析中，我们识别出A服务的某块业务依赖文件读写，在该文件损坏场景下将会出现基本功能问题。但此时不同的声音依然存在：“出现这个问题的概率非常低，一般很难出现单个文件损坏的场景，而且修改这块机制的工作量也不小。”
“这个场景一定要加固，没有人谁能保证低概率问题就不会在现网出现，”我举出曾经文件损坏类的现网问题的例子，“这个问题出现后，没有自愈恢复机制，影响很大。”我的坚持得到了大部分人的认可。
非常巧的是，在我们识别该隐患点后的第三天，同事就在长稳测试中发现了一个基本功能问题，接口人定位完之后一看，惊呼道：“这不正是我们上次识别出来的‘低概率问题’吗！”至此，所有人都认可了FMEA系统性分析的价值，也肯定了专项的价值和意义。
后来专项工作收尾时，我们总共识别出6个严重级隐患点、 10多个改进加固点，最后一一落地解决。
2023年底，出征印尼一线负责研发保障的同事不断发来捷报：“PaaS搭建成功！”“网元部署成功！” “ATP（测试验收用例）测试完成！” “业务割接成功！”“期间没有出现存储和网络相关的任何问题！”成功交付首局的喜悦之情溢于言表，我和团队也在这一声声喜讯中收获了巨大的鼓励。业务成功交付、现网持续平安，这便是对我们最好的肯定。
这一切背后，离不开一支专业精深、充满活力的团队。结合业务诉求和个人发展诉求，我们制定了“一人一策”的分工和发展路径，让每个人在自己擅长的领域发光发热。一年时间，团队零人员流失，团队规模扩大了30%，优秀的团队成员逐步成长为骨干、优秀committer，四五级专家…..
荣获云核心网产品线“优秀工程师奖”
2023年，我荣获“金牌个人”奖，向王者段位迈进了一大步。我在心里定下了一个“小目标”——希望未来某一天成为产品经理或总监，引领一个产业的成功！
前方的路还长，不回头，继续向前！
“我不去想，
是否能够成功，
既然选择了远方，
便只顾风雨兼程。
我不去想，
未来是平坦还是泥泞，
只要热爱生命，
一切，都在意料之中。”
