2017年入职时，我面对新员工培训辩论赛题目“干一行爱一行”还是“爱一行干一行”，毫不犹豫地选择了后者。成为一名软件工程师，是因为我喜欢软件工程，相信热爱是干出一番事业的原动力。
七年过去，我从能力垫底的萌新到产品的架构专家，其间有过被破格提拔的兴奋，也有过迷茫崩溃的绝望。我渐渐明白，“热爱”不只是初见时的心动，顺遂中的欢喜，还有逆境中的磨砺。
在“爱一行干一行”的梦幻开头之后，是“干一行爱一行”的强大定力。
从小宋到深哥
“网元交叉查不出来，你来定位一下。”
“老大，交叉是什么？”
……
“端到端服务Core了，你赶紧处理一下！”
“老大，Core是啥意思？”
……
初入职场，这样的对话就是我的日常。那时我的编码能力、表达能力都不突出，技术栈是Java，与部门主流的技术栈C++不符，正想着如何破局，机会来了——我被安排加入了一个6人特战队，参与U2000-T（传输网的网络管理系统）的集群云化微服务架构切换项目。
当时运行的平台U2000-T技术老旧，管理能力有限，随着网络的不断演进，在网设备越来越多，网管系统必须具备灵活可扩展的能力，就好像要把货物越装越多的卡车变成一节节火车车厢，容量不够就增加车厢，系统的负载能力就有了灵活扩容的基础。
将卡车上的货物搬到火车车厢上容易，但要将火车组装起来并稳定运行，就没那么容易了。新的平台架构就像是一个小朋友堆起来的玩具火车，连轮子都转不起来。操作系统、数据库、核心配置等，每个模块都有关键问题出现。
我们的特战队里有专家，也有资深骨干员工，他们都有各自熟悉的领域，而我作为各项能力都垫底的萌新，没有自己的“责任田”，就跟着各路神仙四处出击，哪里需要我就去哪里，碰到任何模块的问题都“照单全收”。我看什么都新奇，也看什么都懵懂，只能“迈开腿，张开嘴”，遇不懂就问、逢人就问，问队友、问导师、问主管，边学边干，在实操中一步步熟悉全领域的技术知识，快速学习各种知识和工具。
天赋不够，努力来凑。我没有技术上的优势，就在韧性上死磕。当时有个网元管理器进程总是莫名其妙反复重启，我分析程序运行文件、对照代码看堆栈、参考日志，都找不到问题原因。问其他同事也找不到答案，他们都忙得晕头转向，也不熟悉新的调试技术，告诉我实在解决不了就先绕过，但我不想放弃，就靠着刚学了几天的GDB（一种程序调试工具）调试技术，硬着头皮直接开始调汇编，一行行指令不断输入进去，反复缩小问题范围。
经过近十个小时的连续调试，在自己脑子几乎要宕机时，我终于找到了原因——编译器有问题！我和同事沟通才知道，原来这个版本升级了C++编译器，上网查资料发现这个版本的编译器还真是有bug，可能会将某些地址编译错误。我将编译器回退后，问题完美解决。
得知我定位业务难点时竟然发现了C++编译器的底层问题，主管王宏新向我竖起了大拇指。后来他还让我担任讲师，向全部门赋能GDB调试技术。那一刻，我的成就感爆棚，没想到短短半年，我就从新人小透明变成了大家都知道的“深哥”。
那是我第一次知道坚持的力量，只要敢于深挖，就能所向披靡。
“深哥”不好当
平台切换项目干了大半年，我成为了最快掌握新平台系统全貌的新员工，C++的编码能力也得到了极大提升。我缓了一口气，有时还能准时下班体验一下新运营的有轨电车，拍一拍江城的日落风光。
然而，很快我就迎来了新任务。主管找到我：“业务发放是新平台项目中的核心板块，目前非常缺人手，是块难啃的硬骨头，但也是一次难得的机会，你有底层平台切换的项目经验，上次在部门的培训又建立了自己的技术影响力，这个任务可以让你再扩大一些自己的知识面，你愿意挑战一下吗，‘深哥’？”
这句“深哥”让我心神一动，我想再难也不会比平台切换的从零开始难了吧？而且平台建起来了到底好用吗，我自己也想检验一下成果，这不就是摆在面前“白捡”的机会？于是我果断接受了挑战。
因为我之前在平台切换中的工作与版本经理、测试人员、开发人员等都建立了良好的沟通机制，主管就让我担任特性接口人。我这才知道天上没有掉下来的馅饼，更没有“白捡”的机会，主管喊我那声“深哥”背后套路太深了——要做好“接口”，得什么都懂。我再次开启“疯狂海绵”模式，快速学习新的领域知识，从前台的JS/React技术，到后台的Java微服务技术，从波分客户端业务，到SDH（同步数字体系）、ETH（以太网）数据业务，短短两个月就在各种实战的洗礼中摸了个遍。
当时OTN（光传输网）专线正在快速推广期，每周都在打市场的关键项目。有个测试局点需要研发连续3天提供24小时保障，PL涂指导和我两班倒，白天我对外沟通，晚上他通宵支撑。没有独立对接过外部的我，担忧地对他说：“这么重要的事情，我万一没搞定咋办？”他回答“怕什么，放心搞，出了啥事儿我顶着！”这句话让我瞬间有了后盾和底气。
后来在支撑时我不再畏手畏脚，对外接口现网问题和市场诉求，对内快速调配团队人手。最后一天保障时，突然来了一个时延开关的紧急需求，因为人力不够我自己顶上，前后台的开发一起搞定，从白天一直干到次日上午8点，才终于完整实现了功能，支撑了局点测试的诉求，最终协助市场人员成功拿下了项目。
经过这一战，我算是在新领域上站稳了脚跟，获得了团队的认可，之后PL就放心将团队事务全权交给我负责处理，只有重大紧急的事务才需要他介入。而我收获的不只是业务技术上提升，也提升了自己团队协作沟通的综合能力。
就在我一路高歌猛进、准备大展拳脚时，“516”事件来了，我们之前的硬件方案不能再用，必须尽快完成国产化切换工作，NCE-T的ARM切换项目被提上了日程。
主管敢给，我就敢接
2019年五月中旬的一个午后，武汉已经进入初夏，窗外阳光炙热，会议室内的氛围却格外沉寂。主管给大家讲了NCE-T的ARM切换项目的战略意义，以及我们面临的巨大挑战，问“谁愿意作为Owner牵头？”坐在角落里的我环顾四周，无人表态，迟疑片刻之后，我站了起来，说：“我申请出战！”
还记得当时主管诧异的眼神，他估计没想到我一个新兵蛋子会主动请缨。那一刻我心里“咯噔”一下，正想着我是不是太冲动，有些自不量力了，他已经点了头：“好，那就由你来负责。”
现在回想起来，不知道该说主管路子野，还是我胆子大，反正当时一个敢给，一个敢接，我就这么在入职还不到2年时成了大项目的负责人。
那时我们的主线版本刚开始启动大规模投入，无法抽出足够人力，我负责的切换项目在初期只有4个人投入，我作为整体Owner牵头统筹。在此之前我从未完整负责过一个专项的开展，连专项日报都不知道该怎么写，主管就手把手教我。我这才知道，他之所以敢把这个大项目分给我，除了认可我在之前工作中的韧性，更重要的是因为他会给我兜底。在他和周边同事的帮助下，我踉踉跄跄地组织起了专项运作。
当时项目的思路是先将产品版本安装到ARM架构服务器上，然后一方面通过白盒分析产品编译告警识别指令集差异导致的问题，另一方面通过黑盒自动化和手工测试全量覆盖识别系统性问题。
由于项目底座是基于主线版本拉取的分支，本身就有不少基础质量问题，又因为切换了底层硬件，很多操作系统的指令集都不兼容，而且CPU的性能也存在一定的劣化。各种因素叠加在一起，导致奇怪的问题层出不穷，项目刚启动，就陷入了十分艰难的局面。
我在请教主管和同事之后，系统梳理了专项的整体计划和各项风险，制作了详细的项目计划和事务跟踪表。每天在例会上集中对齐，用日报推动跟进风险问题的解决，提出了“阻塞问题当天解决，非阻塞问题第二天解决，所有问题在下个B版本前解决”“高质高效完成NCE-T切换泰山服务器项目，率先达成全域目标”的要求。
在主管的支持下，我把开发人员和测试人员集中在一起办公，让大家可以高效对齐工作，关键问题也可以快速传递、组织闭环。对于公共领域的问题，没有人承接，我就自己组织攻关分析。当时我发现有个问题是ARM架构和X86架构下的某个类型默认符号不一致，由此导致变量取值存在差异，程序运行出行异常结果，我就组织各组逐个代码仓分析相关编译告警，地毯式排查所有可能的代码，彻底解决了该类问题。
经过两个月的专项运作，NCE-T在全域率先达到了专项质量出口标准，并启动NCE全域首个实验局。这个项目为NCE-T在硬件层面的BCM（业务连续性）收编奠定了基础。我也在完成了一次大型专项运作后，初步具备了主导一个项目端到端交付的能力。
后来，我又接手工程迁移架构项目，将传统U2000的数据通过迁移工具迁移至全栈脱A的NCE-T新版本中。这个项目的难点在于需要详细分析NCE-T和U2000-T的所有数据差异，从数据库到文件、配置项，基于所有数据含义的差异针对性开发工具脚本，进行数据转换和迁移。这要求我既要懂各种业务，也要熟悉shell、python和powershell等各种脚本语言。我边学边干，在人手不够时自己埋头开发了19条迁移路经，同时梳理了大量的场景和工具的使用方法，主导完成了迁移工具商用，支撑全球BCM收编。
两个大项目的历练，让我的能力飞速提升，我也因此得到了组织的认可。2020年，我被公司破格提级，连升两级。斗志满满的我开足了马力向前跑，在2021年主导完成了OTN网络层的业务发放融合，在2022年又转身成为了版本架构师。这些工作让我把NCE-T领域的特性基本全部摸了一遍，对全领域的业务有了更透彻的了解，也有了迎接任何新事物、新挑战的良好心态和勇气。
那时的我意气风发，觉得自己就像个“战神”，没有打不赢的战役。因此主管让我担任子领域架构师时，我也依旧信心满满，丝毫没有想到，我将在不久后的未来，跌入万丈深渊……
双手沾泥，才有全局观
在我担任子领域架构师之前，无论是特性接口人，还是专项负责人，我做得更多的都是指令性的工作，解决问题是我的主要工作目标。但子领域架构师的角色却是要从整个系统出发，不仅要看护整体架构稳定运行，还要在深度理解业务、考虑各环节配合协调的基础上主导业务的后续发展，设计架构怎么规划，不同的部件怎么配合，面向未来满足客户需求。
我从埋头苦干的角色变成了埋头苦想怎么干的角色，原来的经验不够用了，汇报方案、开展设计时，质疑声源源不断地出现，让我难以招架。
一次智能故障的架构设计汇报，要评审NCE-T和NAIE（网络人工智能引擎）的配合、工程部署方案等。我的材料刚翻到第一页，就有人开始问“NAIE是什么？”我支支吾吾解释了半天，继续往下讲，马上就又来一堆疑问：“智能故障的AI是什么？AI算法怎么实现的？为什么要用NAIE？用了NAIE的什么能力？”“智能故障的目标是什么？解决什么场景的问题？这些能力能不能解决客户的问题？”
我当时心想：“还能不能让我说话了？我就是一个架构师啊，这些问题不应该是MKT、解决方案架构师和系统工程师该回答的吗？”那段时间我被反复敲打、锤炼，一遍又一遍修改材料，评审时还总是被挑战。主管提醒我要有全局观，只有全面系统地思考问题，才能设计出完整的架构方案。
道理我明白，可要怎么做呢？我沮丧又迷茫，感觉自己所有的努力都像是无头苍蝇的乱飞，甚至开始对自己的能力产生怀疑。“全局观”三个字听起来宏大而虚无缥缈，我的抓手到底在哪儿呢？
直到有一次，我去旁听组内的质量例会，当时新晋的几个年轻PL讲质量改进措施，主管问他们：“你们改进的目标是什么？” “目标都没有，讲一堆措施有什么用？”
这句话仿佛一道惊雷，炸开了我混沌的思路。做架构设计，不就是要以客户为中心考虑方方面面的需求？我回答不上来评审时的那些问题，也许是因为我始终在闭门造车，并没有找到真正的目标和方向？意识到问题就去解决，我决定跳出“旋涡”，深入一线，去客户现场学习历练。
2023年，我加入智能分析TL（技术组长）团队，作为专家下沉到团队，不只是从技术角度解决问题，还主导建立团队的沟通机制、质量管理机制，在保证团队稳定性的同时协助团队完成关键版本的质量大逆转，输出高质量产品和服务，解决交付困境。2024年，我加入大网专项专家组核心团队，多次去现场参加重大项目的保障升级，主导多个关键问题的攻关，参与大网整体运作。
去前方战场感受炮火，我更加理解了一线的问题和压力，对客户场景的诉求有了更深入的理解和把握，对架构也有了更深层次的认知。这些经历终于让我慢慢建立起了自己的“全局观”，开始真正全面系统地思考问题，思考做的架构方案到底应该怎么去适配商业逻辑，又该如何根据业务规划落实架构规划。
再去汇报架构方案时，我听到的质疑声越来越少，在重要大网专项中，我作为核心架构师成员，参与了整体的运作思路设计，并深度参与关键疑难问题攻关、版本基础质量看护，最终支撑大网成功平稳上市。
重点大网项目合影（前排左四为作者）
现在的我，没有了当初的年少轻狂。曾经突飞猛进的称心快意，骑虎难下的不知所措，都已经成为过去。我期待的下一个七年，是继续探究求索的踌躇满志，在仰望星空的同时脚踏实地，等到若干年后回首过往时，能坦然说一句，我的热爱，从未曾被辜负。
