最近流行一個詞，叫「顯眼包」。大家看過來，現在在你們眼前的我，就是一個閃亮的「顯眼包」。我超喜歡自己所在的部門——光傳送技術開發部。我的身邊小夥伴大多都是95後，大家活力十足，相處融洽，下班會一起去遊泳、運動。周末一起去滑雪、玩劇本殺、K歌；也經常會一起聚餐，打羽球、桌球……我最喜歡的還是午飯後的環節，大家一邊逛著美麗的溪村，一邊聊著天，可以是身邊的八卦，也可以是工作上的困惑，大家一起說說笑笑，時間過得尤其快。
在這樣的團隊中，我一路走來，雖然跌跌撞撞，但是如今回首，卻感覺一路清風曉月，星河璀璨。
小白探路新業務
我是轉崗成為一名「追光者」的。在學習了一個多月的知識地圖之後，PL跟我說：「小暉，有一個關於兩種光裝置通訊的計畫，交付內容比較明確，要不你試試？」
接到任務後，同事丟給我一份技術文件，開發的方案讓我自由發揮。我心想這不是輕而易舉嗎，跟以前在學校上通訊課程時做的東西沒什麽區別？於是，三下五除二，我很快就完成了編碼和驗證。
開始似乎都很順利，正當我自信滿滿地在晨會上分享進展時，我仿佛看到了負責人微笑的嘴角瞬間收緊，眉頭微微皺起。原來我要做的是基於已有的程式碼架構完成裝置通訊，此前我把問題想簡單了。瞬間感覺晴天霹靂，腦子一下就炸開了，相當於我前面的工作都白做了，一切都要重新開始。而此時周邊領域都已經完成編碼，壓力一下子來到我身上：難道轉崗過來的「首秀」就要搞砸了嗎？已有的程式碼架構到底是什麽，又怎麽基於這個架構進行開發呢？我急得在電腦前抓耳撓腮，絲毫沒有頭緒。
不行，不能坐以待斃，我調整好心態後，主動找主管龍哥求助。龍哥二話不說帶著我從頭到尾梳理了一遍整體架構，我這才對通訊模型有了一定的概念。兩個光裝置的通訊，類似於主控板和業務板之間的通訊，完全可以基於當前的主幹框架進行開發。
但面對幾十萬行的程式碼，我還是束手無策，無從下手。我只能求助業務專家，一起探討具體的方案細節，涉及哪些程式碼模組。然而就這樣一個通訊問題，在專家看來再簡單不過的問題，對我來說卻都跟聽天書一樣，討論的內容我都無法消化，只能記下來自己慢慢學習，遇到不懂的再厚著臉皮請教。
令我非常意外的是，在這個過程中，不管是龍哥還是專家們，都沒有任何不耐煩，大家都在不遺余力為我答疑解惑。龍哥還經常會問我，有沒有遇到什麽問題，需不需要幫助。感受到大家的溫暖後，我慌亂的情緒也慢慢鎮定下來，一步步去夯實自己的業務知識。隨著業務的深入，專家們口中的術語不再那麽晦澀難懂，方案的問題逐漸得到解決。透過一遍一遍地熟悉程式碼，理清其中的通訊原理，我完成了程式碼開發的工作。
隨著這個計畫的順利結項，我邁出了在新部門的一小步，在面對突發事件能夠從容應對，不自亂陣腳，收獲了大家的高度認可。此後半年，我先後獨立承擔了兩三個模組功能的交付，慢慢樹立起自己的招牌，變成了大家信任的「老員工」。
第一塊單板的負責人，是我
2022年3月，一次小組例會上，龍哥主動跟我們說：「兄弟們，十年一遇的機會來了，波分未來十年關鍵競爭力是Kepler平台（光傳送下一代平台），我們組擔任先鋒，負責技術計畫可行性的摸底開發，有沒有同學願意擔任G板的交付責任人？」
面對如此大的機會和挑戰，大家都躍躍欲試，但是都沒有業務單板偵錯經驗，所以心裏沒有底。從單板啟動、到業務通斷、開銷、告警和效能，每一步對我們來說都是一道坎。
「要不我來試試吧！」抱著初生牛犢不怕虎的心態，我主動承擔了這項任務。
「這是Kepler平台的第一塊單板，好多新特性都會在這塊板子上面落地，你可以嗎？」龍哥將信將疑地看向我，似乎在反復確認我的決定。
「沒事，幹就完了。」我心想之前負責的那些計畫，不也是一個從0到1的過程嗎，年輕人有什麽不敢的。
最終團隊決定給我這個機會。就這樣，零調板經驗的我接下了G板的交付責任人。
接了任務令後，我還是非常忐忑的，第一次接手這樣重要的計畫，而且G板的業務偵錯和特性開發整體都由我負責，我感到壓力山大。但是秉承著勇於攀登、不畏艱難的精神，我選擇正面迎接挑戰。
對於單板偵錯來說，最基礎的是單板啟動、初始化器件，最關鍵是打通業務。因此，我不僅要熟悉單板的器件組成，了解單板的啟動流程，更需要理解業務芯片涉及哪些元件，是如何打通業務的。於是我開始查閱單板相關的資料，下載業務芯片手冊，學習各種業務知識，收集可能用到的偵錯手段，並找到波分已有的單板，熟悉單板的基本操作和建業務的流程等。
基本摸清單板偵錯流程後，我遇到了第一個難題。波分原有的架構最多支持兩塊業務芯片的單板，但是Kepler平台要支持包含四塊業務芯片的單板，原有的軟體設計模型無法復用，需要重新設計梳理。
芯片數量的擴充套件，意味著要重新整理芯片與交叉板的連線關系，讓各單板業務芯片與交叉板的配置關系解耦。
經過初步梳理，我對四芯片擴充套件大致有了一些概念，但是如何進行軟體模型設計，仍然是一知半解。那段時間我每天吃飯、睡覺都在思考這個問題，仍然毫無頭緒，心裏隱隱有些懊悔，當初為啥要誇下「海口」，接下這個任務。
怎麽辦，只能沖！我找到原有兩芯片設計模型資料，閱讀相關的程式碼，經過一段時間的梳理，基本熟悉了兩芯片模型的設計原理。我分析出四芯片模型的設計關鍵是要清楚每塊業務芯片與交叉板的連線數量，並將芯片與交叉板的連線關系抽象出一個邏輯匯流排模型，在程式碼開發時才能更好地排兵布陣。有一點思路後，我就組織方案討論和串講，讓大家審視方案的不足。經過與專家多輪的討論和評審，最終我們明確了軟體模型的設計方案。
即使做好了充足準備，在偵錯單板啟動的時候，也遇到了這樣或那樣的問題。我記得有一次單板反復復位，沒有偵錯經驗的我遲遲沒有定位出原因。我嘗試著從異常的日誌記錄入手，但每深入一條異常日誌就要熟悉對應的元件程式碼，效率非常低，我不禁有些苦惱。
龍哥看到我沮喪的樣子，指點我說：「小暉，你試試將正常執行單板日誌和異常日誌對比著看，說不定有新的發現。」
仿佛迷霧中的一縷光，照亮了我前行的方向。我順著這個思路，將正常執行的單板日誌和異常日誌反復比對，很快發現關鍵異常點——原來是單板和業務芯片之間的通訊匯流排初始化失敗導致的。
後面的業務偵錯環節，也出現了背板流量不通的問題。我排查了鏈路同步狀態、可達有配置後，發現有8個通道出現異常，反復嘗試了各種配置方式後，還是無法打通業務。
芯片專家提出：「是不是配置到無效通道上了？」
哪些屬於無效通道呢？要不找芯片資料看看？在翻遍了芯片手冊和軟體指南後，我發現30G的速率下芯片有8個通道是無法使用的。順著這個思路，我重新修改了配置檔，改用其他可用的通道，背板流量終於打通了。
慢慢的，我沒有了調板最初的心虛和緊張，反而開始享受其中的樂趣。感覺自己像是外科醫生一樣，解決各種疑難雜癥，不管是單板啟動問題還是業務問題，只要一步一步腳踏實地，見招拆招，就一定能解決。就這樣不停地升級打怪，我定位問題的技能逐漸增加，從一個業務小白變成了經驗豐富的多面手，順利達成技術驗證的階段目標。
變身「暉姐」
時間很快進入2022年9月，我們開始向商用版本遷移。作為Kepler平台的先鋒板，版本賦予它的使命就是在其他板卡回來前，能夠快速催熟新平台。尤記得在開工會上，計畫經理語重心長地跟我說：「這個版本的交付壓力會很大，但是我相信你肯定可以，交付過程中有任何問題一定要及時提出來。」聽了他的話，我暗暗下定決心，一定要好好完成G版的商用交付，不能辜負大家對我的信任。
與技術計畫的單點驗證不同，對於商用版本來說，僅僅是打通基礎業務是遠遠不夠的。我作為G板交付負責人，要完成G板所有特性的開發和交付工作，還要把控整體的交付進度。
業務能夠正常開通，需要主控下配置，單板接收到配置進行處理，處理完後再到交叉板，交叉板處理後再回到業務板。就像流水線一樣，每一個環節都是不可或缺的，當中間某個地方故障時，整個流程就進行不下去了，只有修復後才能往下推進。而新平台，所有的裝置包括主控板交叉板都是新的，意味著這裏面任何一個環節都存在不穩定因素，業務板則是業務不通的第一責任主體。因此，我們這塊板的順利交付強依賴新平台主控交叉系統的穩定性。
為了提高大家的重視程度，將風險攔截在前期，我召集小組成員組織開展品質策劃，讓大家頭腦風暴，提前辨識交付過程中可能會遇到的問題，並針對每個問題制定應對策略，落實責任人和閉環時間。每周我都會拉大家對齊進展，分配當周的交付任務，討論開發過程中遇到的困難。我們提前準備好了偵錯環境、軟體版本和回板前的各種註意事項，萬事俱備，只待回板。
12月初，單板終於回板了，計畫經理要求我們在24小時內打通業務，完成零調工作。一切都是那麽井然有序，硬體同學測量時鐘電源訊號，我們審視零調環節是否有遺漏。下午兩點，我們突然發現單板上電後無法正常啟動，硬體同學定位了一段時間仍然沒有思路。
我心裏有些著急，便登上偵錯環境，想一起檢檢視看是哪個環節導致的問題。在排查了部份寄存器後，我還真發現了蛛絲馬跡：回板前我們剛好因為以太速率的問題修改過底層軟體，硬體也配合出了新的上電版本，因與出廠時的底軟版本不匹配，導致上電失敗。
更換了上電版本後，單板能夠正常啟動，硬體功能一切正常。接下來我們啟動軟體偵錯。剛建好業務，打流看到背板流量以後，我信心滿滿地接上了儀表，卻發現儀表流量有發無收。
「不會又出幺蛾子了吧！」經過一番排查，原來是光口接錯了，雖然出了一些小插曲，但最終我們還是有驚無險地打通Kepler平台的第一條業務。
我們順利打響了回板零調的第一槍，但是接下來仍然還有一場惡戰。
距離版本轉測不到一個月的時間，我們不僅要完成G板新特性的開發，還要保障整個系統的穩定性。時間緊、任務重，我們必須分秒必爭。
大家都對Kepler寄予厚望，一方面期望G板落地更多的新特性，另一方面為了掙脫歷史包袱，大家在開發的過程中，透過問題觸發方案最佳化。所以轉測前，部份方案仍然在反復變化，開發的效率非常低，各特性無法展開驗證，我們面臨極大的交付風險。除了技術問題外，受疫情的影響，原本人力不足的我們更是雪上加霜，各領域開發人員都面臨分身乏術的窘境。
為了順利完成第一個版本的轉測，我們成立了專項討論組跟蹤方案的設計和落地。我與SE和DE（方案設計專家）反復討論後敲定了方案細節，並求助版本增加人力投入。疫情期間，我們也沒有停下腳步，我還記得居家的當天，我還在跟硬體同學協調物料，就為了能夠盡快有環境進行開發驗證。
版本轉測後不久，單板之間業務不通，業務丟包，滿配所有業務後，流量收發不一致，單板與主控之間鏈路的速率提升，導致小槽位單板與主控之間通訊異常等一系列問題接踵而至。通訊問題還沒有完全解決，單板首次上車光啟平台後，又出現了各種各樣超預期問題，先是因為踩記憶體的問題導致單板出現異常復位，再到檔樁許可權問題引入的保留記憶體無法恢復，問題一直沒有得到收斂。各個群組都在轟炸式找人：
「小暉，單板業務不通了。」
「小暉，單板無法上線了。」
「小暉，單板又反復復位了。」
……
我仿佛被困在一個無解的迷宮裏，每個轉角都有一道棘手的難題，讓我無從下手，沮喪到了極點。
龍哥看到我的狀態不好，語重心長地對我說：「要不組織一次品質加固呢，讓大家重視轉測品質問題。」仿佛一股清泉湧上心頭，我恍然大悟：是啊，單板交付不是我一個人的責任，需要各領域齊心協力！
我立即把轉測以來的所有問題單都梳理出來，並迅速召集所有領域的開發人員，對當前交付狀態進行階段性復盤。根據問題單的分布，我們分析了當前問題持續爆發的根因：首先是一些單點問題，部份領域由於沒有專業知識賦能，十分依賴問題驅動的形式，測出一個問題修改一個問題，無法做到舉一反三，導致問題頻繁出現。其次，在開發過程中，存在僥幸心理，沒有做到全量覆蓋自驗證，我們一塊單板24個光口，可能前面幾個口的業務是正常的，後面幾個口的業務卻有問題。在版本特性「上車」的策略上，前一個特性還沒穩定，後一個特性又「上車」了，多個特性耦合之後，遇到問題就不好定界，定位效率就更低了。
在辨識到問題根因之後，我迅速調整了策略：作為交付負責人，我不能只關註本領域的交付需求，更需要把控整體特性端到端的交付，重視每一次的轉測品質。各領域開發人員在轉測之前，要進行充分自驗證。針對某些特性基礎薄弱的領域，要組織專家進行業務知識賦能。我對版本策略也提了相應的建議，希望能在一個特性稍穩定之後再上車另一個特性。最後，每一次版本轉測前，我都會在環境上預載入轉測版本，給各領域分配驗證環境，及時攔截驗證問題。
經過這次復盤，我們漸漸重回正軌，大家也更加重視品質問題，在版本回合主幹時，打了一場漂亮的翻身仗。在大家的共同努力之下，我們做到了高品質回合，將回合後所有問題攔截在轉測之前。
我的內心如釋重負， 成就感席卷而來。經此一戰，我不負眾望地扛住了大旗，在交付技能上取得了從0到1的蛻變，獲得了計畫組和領導的認可。龍哥對我說：「暉姐，幹得不錯！」
（前排左一為作者）
追光者，披荊斬棘，不畏艱辛
回顧這一年多的時間，我從一個什麽都不懂的小白，一路披荊斬棘，不斷地學習和成長，適應了新的環境，結交了一群並肩作戰的小夥伴，鍛煉了心理素質，積累了豐富的業務知識，收獲了從零出發的底氣。
初心依舊，砥礪前行，遇見更好的自己。我也更加期待未來的挑戰，又要怎樣與之鬥智鬥勇。正所謂「關關難過關關過，前路漫漫亦燦燦」，我要繼續攜著信念和堅持做一個勇敢無畏的追光者。
聲明：本文來源：【華為人】，轉載請註明作者和出處
