01 
前言
最近流行一个词，叫“显眼包”。大家看过来，现在在你们眼前的我，就是一个闪亮的“显眼包”。我超喜欢自己所在的部门——光传送技术开发部。我的身边小伙伴大多都是95后，大家活力十足，相处融洽，下班会一起去游泳、运动。周末一起去滑雪、玩剧本杀、K歌；也经常会一起聚餐，打羽毛球、乒乓球……我最喜欢的还是午饭后的环节，大家一边逛着美丽的溪村，一边聊着天，可以是身边的八卦，也可以是工作上的困惑，大家一起说说笑笑，时间过得尤其快。
在这样的团队中，我一路走来，虽然跌跌撞撞，但是如今回首，却感觉一路清风晓月，星河璀璨。
02 
小白探路新业务
我是转岗成为一名“追光者”的。在学习了一个多月的知识地图之后，PL跟我说：“小晖，有一个关于两种光设备通信的项目，交付内容比较明确，要不你试试？”
接到任务后，同事丢给我一份技术文档，开发的方案让我自由发挥。我心想这不是轻而易举吗，跟以前在学校上通信课程时做的东西没什么区别？于是，三下五除二，我很快就完成了编码和验证。
开始似乎都很顺利，正当我自信满满地在晨会上分享进展时，我仿佛看到了负责人微笑的嘴角瞬间收紧，眉头微微皱起。原来我要做的是基于已有的代码架构完成设备通信，此前我把问题想简单了。瞬间感觉晴天霹雳，脑子一下就炸开了，相当于我前面的工作都白做了，一切都要重新开始。而此时周边领域都已经完成编码，压力一下子来到我身上：难道转岗过来的“首秀”就要搞砸了吗？已有的代码架构到底是什么，又怎么基于这个架构进行开发呢？我急得在电脑前抓耳挠腮，丝毫没有头绪。
不行，不能坐以待毙，我调整好心态后，主动找主管龙哥求助。龙哥二话不说带着我从头到尾梳理了一遍整体架构，我这才对通信模型有了一定的概念。两个光设备的通信，类似于主控板和业务板之间的通信，完全可以基于当前的主干框架进行开发。
但面对几十万行的代码，我还是束手无策，无从下手。我只能求助业务专家，一起探讨具体的方案细节，涉及哪些代码模块。然而就这样一个通信问题，在专家看来再简单不过的问题，对我来说却都跟听天书一样，讨论的内容我都无法消化，只能记下来自己慢慢学习，遇到不懂的再厚着脸皮请教。
令我非常意外的是，在这个过程中，不管是龙哥还是专家们，都没有任何不耐烦，大家都在不遗余力为我答疑解惑。龙哥还经常会问我，有没有遇到什么问题，需不需要帮助。感受到大家的温暖后，我慌乱的情绪也慢慢镇定下来，一步步去夯实自己的业务知识。随着业务的深入，专家们口中的术语不再那么晦涩难懂，方案的问题逐渐得到解决。通过一遍一遍地熟悉代码，理清其中的通信原理，我完成了代码开发的工作。
随着这个项目的顺利结项，我迈出了在新部门的一小步，在面对突发事件能够从容应对，不自乱阵脚，收获了大家的高度认可。此后半年，我先后独立承担了两三个模块功能的交付，慢慢树立起自己的招牌，变成了大家信任的“老员工”。
03 
第一块单板的负责人，是我
2022年3月，一次小组例会上，龙哥主动跟我们说：“兄弟们，十年一遇的机会来了，波分未来十年关键竞争力是Kepler平台（光传送下一代平台），我们组担任先锋，负责技术项目可行性的摸底开发，有没有同学愿意担任G板的交付责任人？”
面对如此大的机会和挑战，大家都跃跃欲试，但是都没有业务单板调试经验，所以心里没有底。从单板启动、到业务通断、开销、告警和性能，每一步对我们来说都是一道坎。
“要不我来试试吧！”抱着初生牛犊不怕虎的心态，我主动承担了这项任务。
“这是Kepler平台的第一块单板，好多新特性都会在这块板子上面落地，你可以吗？”龙哥将信将疑地看向我，似乎在反复确认我的决定。
“没事，干就完了。”我心想之前负责的那些项目，不也是一个从0到1的过程吗，年轻人有什么不敢的。
最终团队决定给我这个机会。就这样，零调板经验的我接下了G板的交付责任人。
接了任务令后，我还是非常忐忑的，第一次接手这样重要的项目，而且G板的业务调试和特性开发整体都由我负责，我感到压力山大。但是秉承着勇于攀登、不畏艰难的精神，我选择正面迎接挑战。
对于单板调试来说，最基础的是单板启动、初始化器件，最关键是打通业务。因此，我不仅要熟悉单板的器件组成，了解单板的启动流程，更需要理解业务芯片涉及哪些组件，是如何打通业务的。于是我开始查阅单板相关的资料，下载业务芯片手册，学习各种业务知识，收集可能用到的调试手段，并找到波分已有的单板，熟悉单板的基本操作和建业务的流程等。
基本摸清单板调试流程后，我遇到了第一个难题。波分原有的架构最多支持两块业务芯片的单板，但是Kepler平台要支持包含四块业务芯片的单板，原有的软件设计模型无法复用，需要重新设计梳理。
芯片数量的扩展，意味着要重新整理芯片与交叉板的连线关系，让各单板业务芯片与交叉板的配置关系解耦。
经过初步梳理，我对四芯片扩展大致有了一些概念，但是如何进行软件模型设计，仍然是一知半解。那段时间我每天吃饭、睡觉都在思考这个问题，仍然毫无头绪，心里隐隐有些懊悔，当初为啥要夸下“海口”，接下这个任务。
怎么办，只能冲！我找到原有两芯片设计模型资料，阅读相关的代码，经过一段时间的梳理，基本熟悉了两芯片模型的设计原理。我分析出四芯片模型的设计关键是要清楚每块业务芯片与交叉板的连线数量，并将芯片与交叉板的连线关系抽象出一个逻辑总线模型，在代码开发时才能更好地排兵布阵。有一点思路后，我就组织方案讨论和串讲，让大家审视方案的不足。经过与专家多轮的讨论和评审，最终我们明确了软件模型的设计方案。
即使做好了充足准备，在调试单板启动的时候，也遇到了这样或那样的问题。我记得有一次单板反复复位，没有调试经验的我迟迟没有定位出原因。我尝试着从异常的日志记录入手，但每深入一条异常日志就要熟悉对应的组件代码，效率非常低，我不禁有些苦恼。
龙哥看到我沮丧的样子，指点我说：“小晖，你试试将正常运行单板日志和异常日志对比着看，说不定有新的发现。”
仿佛迷雾中的一缕光，照亮了我前行的方向。我顺着这个思路，将正常运行的单板日志和异常日志反复比对，很快发现关键异常点——原来是单板和业务芯片之间的通信总线初始化失败导致的。
后面的业务调试环节，也出现了背板流量不通的问题。我排查了链路同步状态、可达有配置后，发现有8个通道出现异常，反复尝试了各种配置方式后，还是无法打通业务。
芯片专家提出：“是不是配置到无效通道上了？”
哪些属于无效通道呢？要不找芯片资料看看？在翻遍了芯片手册和软件指南后，我发现30G的速率下芯片有8个通道是无法使用的。顺着这个思路，我重新修改了配置文件，改用其他可用的通道，背板流量终于打通了。
慢慢的，我没有了调板最初的心虚和紧张，反而开始享受其中的乐趣。感觉自己像是外科医生一样，解决各种疑难杂症，不管是单板启动问题还是业务问题，只要一步一步脚踏实地，见招拆招，就一定能解决。就这样不停地升级打怪，我定位问题的技能逐渐增加，从一个业务小白变成了经验丰富的多面手，顺利达成技术验证的阶段目标。
04 
变身“晖姐”
时间很快进入2022年9月，我们开始向商用版本迁移。作为Kepler平台的先锋板，版本赋予它的使命就是在其他板卡回来前，能够快速催熟新平台。尤记得在开工会上，项目经理语重心长地跟我说：“这个版本的交付压力会很大，但是我相信你肯定可以，交付过程中有任何问题一定要及时提出来。”听了他的话，我暗暗下定决心，一定要好好完成G版的商用交付，不能辜负大家对我的信任。
与技术项目的单点验证不同，对于商用版本来说，仅仅是打通基础业务是远远不够的。我作为G板交付负责人，要完成G板所有特性的开发和交付工作，还要把控整体的交付进度。
业务能够正常开通，需要主控下配置，单板接收到配置进行处理，处理完后再到交叉板，交叉板处理后再回到业务板。就像流水线一样，每一个环节都是不可或缺的，当中间某个地方故障时，整个流程就进行不下去了，只有修复后才能往下推进。而新平台，所有的设备包括主控板交叉板都是新的，意味着这里面任何一个环节都存在不稳定因素，业务板则是业务不通的第一责任主体。因此，我们这块板的顺利交付强依赖新平台主控交叉系统的稳定性。
为了提高大家的重视程度，将风险拦截在前期，我召集小组成员组织开展质量策划，让大家头脑风暴，提前识别交付过程中可能会遇到的问题，并针对每个问题制定应对策略，落实责任人和闭环时间。每周我都会拉大家对齐进展，分配当周的交付任务，讨论开发过程中遇到的困难。我们提前准备好了调试环境、软件版本和回板前的各种注意事项，万事俱备，只待回板。
12月初，单板终于回板了，项目经理要求我们在24小时内打通业务，完成零调工作。一切都是那么井然有序，硬件同学测量时钟电源信号，我们审视零调环节是否有遗漏。下午两点，我们突然发现单板上电后无法正常启动，硬件同学定位了一段时间仍然没有思路。
我心里有些着急，便登上调试环境，想一起检查看看是哪个环节导致的问题。在排查了部分寄存器后，我还真发现了蛛丝马迹：回板前我们刚好因为以太速率的问题修改过底层软件，硬件也配合出了新的上电版本，因与出厂时的底软版本不匹配，导致上电失败。
更换了上电版本后，单板能够正常启动，硬件功能一切正常。接下来我们启动软件调试。刚建好业务，打流看到背板流量以后，我信心满满地接上了仪表，却发现仪表流量有发无收。
“不会又出幺蛾子了吧！”经过一番排查，原来是光口接错了，虽然出了一些小插曲，但最终我们还是有惊无险地打通Kepler平台的第一条业务。
我们顺利打响了回板零调的第一枪，但是接下来仍然还有一场恶战。
距离版本转测不到一个月的时间，我们不仅要完成G板新特性的开发，还要保障整个系统的稳定性。时间紧、任务重，我们必须分秒必争。
大家都对Kepler寄予厚望，一方面期望G板落地更多的新特性，另一方面为了挣脱历史包袱，大家在开发的过程中，通过问题触发方案优化。所以转测前，部分方案仍然在反复变化，开发的效率非常低，各特性无法展开验证，我们面临极大的交付风险。除了技术问题外，受疫情的影响，原本人力不足的我们更是雪上加霜，各领域开发人员都面临分身乏术的窘境。
为了顺利完成第一个版本的转测，我们成立了专项讨论组跟踪方案的设计和落地。我与SE和DE（方案设计专家）反复讨论后敲定了方案细节，并求助版本增加人力投入。疫情期间，我们也没有停下脚步，我还记得居家的当天，我还在跟硬件同学协调物料，就为了能够尽快有环境进行开发验证。
版本转测后不久，单板之间业务不通，业务丢包，满配所有业务后，流量收发不一致，单板与主控之间链路的速率提升，导致小槽位单板与主控之间通信异常等一系列问题接踵而至。通信问题还没有完全解决，单板首次上车光启平台后，又出现了各种各样超预期问题，先是因为踩内存的问题导致单板出现异常复位，再到文件桩权限问题引入的保留内存无法恢复，问题一直没有得到收敛。各个群组都在轰炸式找人：
“小晖，单板业务不通了。”
“小晖，单板无法上线了。”
“小晖，单板又反复复位了。”
……
我仿佛被困在一个无解的迷宫里，每个转角都有一道棘手的难题，让我无从下手，沮丧到了极点。
龙哥看到我的状态不好，语重心长地对我说：“要不组织一次质量加固呢，让大家重视转测质量问题。”仿佛一股清泉涌上心头，我恍然大悟：是啊，单板交付不是我一个人的责任，需要各领域齐心协力！
我立即把转测以来的所有问题单都梳理出来，并迅速召集所有领域的开发人员，对当前交付状态进行阶段性复盘。根据问题单的分布，我们分析了当前问题持续爆发的根因：首先是一些单点问题，部分领域由于没有专业知识赋能，十分依赖问题驱动的形式，测出一个问题修改一个问题，无法做到举一反三，导致问题频繁出现。其次，在开发过程中，存在侥幸心理，没有做到全量覆盖自验证，我们一块单板24个光口，可能前面几个口的业务是正常的，后面几个口的业务却有问题。在版本特性“上车”的策略上，前一个特性还没稳定，后一个特性又“上车”了，多个特性耦合之后，遇到问题就不好定界，定位效率就更低了。
在识别到问题根因之后，我迅速调整了策略：作为交付负责人，我不能只关注本领域的交付需求，更需要把控整体特性端到端的交付，重视每一次的转测质量。各领域开发人员在转测之前，要进行充分自验证。针对某些特性基础薄弱的领域，要组织专家进行业务知识赋能。我对版本策略也提了相应的建议，希望能在一个特性稍稳定之后再上车另一个特性。最后，每一次版本转测前，我都会在环境上预加载转测版本，给各领域分配验证环境，及时拦截验证问题。
经过这次复盘，我们渐渐重回正轨，大家也更加重视质量问题，在版本回合主干时，打了一场漂亮的翻身仗。在大家的共同努力之下，我们做到了高质量回合，将回合后所有问题拦截在转测之前。
我的内心如释重负， 成就感席卷而来。经此一战，我不负众望地扛住了大旗，在交付技能上取得了从0到1的蜕变，获得了项目组和领导的认可。龙哥对我说：“晖姐，干得不错！”
（前排左一为作者）
05 
追光者，披荆斩棘，不畏艰辛
回顾这一年多的时间，我从一个什么都不懂的小白，一路披荆斩棘，不断地学习和成长，适应了新的环境，结交了一群并肩作战的小伙伴，锻炼了心理素质，积累了丰富的业务知识，收获了从零出发的底气。
初心依旧，砥砺前行，遇见更好的自己。我也更加期待未来的挑战，又要怎样与之斗智斗勇。正所谓“关关难过关关过，前路漫漫亦灿灿”，我要继续携着信念和坚持做一个勇敢无畏的追光者。
来源/《华为人》
转载请注明作者和出处
-END-
往期推荐：点击图片即可跳转阅读
华为顶牛硬件女工程师：等我老了可以跟孩子说：“你娘当年，干过一票大的！”
华为硬件工程师：做了10多年研发后才真正懂得师父的话
大裁员、倒闭的芯片公司有哪些？原因是什么？
继续阅读
阅读原文
关键词
代码
时间
波分
问题
软件