一個成熟的 SSD 驗證工程師，能夠找到 bug；而一個有價值的 SSD 驗證團隊，能夠累積 bug、管理知識、回溯邏輯。
我們常說：「驗證是一門用錯誤堆出來的技術」——但如果錯誤只發生過一次就被遺忘，那你的驗證就永遠只能停留在「被動救火」的層級。
這篇文章我想分享的是：- 我是如何把 SSD 驗證日常中的 bug、異常行為、平台不穩、reset fail、command misbehave 整理起來的。
- 這些知識如何變成一套**「可搜尋、可回顧、可訓練」**的內部 Wiki + 回溯系統。
- 如何靠這套系統，讓團隊每年少踩 50 次雷、早解 100 次問題。
一、為什麼驗證知識一定要系統化？
在 SSD 驗證的日常工作中，工程師們面對的是無數的測試用例、海量的日誌數據。每一次的 Debug，都像是從礦山中挖掘出一顆寶石。然而，如果這些寶石沒有被妥善儲存，價值就會隨時間消散。
1.1 驗證最大的資產不是 Script，而是「你遇過的 Bug」
許多人認為驗證團隊的資產是自動化腳本或報告。但真正讓團隊有價值的，是**「問題解決經驗」**。每一個曾經被分析、解決的 bug，都蘊含著對產品行為與潛在風險的深刻洞察。
想像一下，如果團隊累積了數千個 bug 的解決方案，包含「為什麼發生」、「如何重現」、「如何避免」，這將極大提升團隊的專業度。
1.2 常見痛點：知識流失與重複勞動
缺乏系統化管理，團隊常面臨以下痛點：
- 知識流失： 資深工程師離職，寶貴經驗隨之帶走，新人只能從頭踩坑。
- 重複 Debug： 半年前解過的問題又出現，卻沒人記得解法，導致重複投入人力分析。
- 新人培養困境： 缺乏系統化教材，新人只能靠口耳相傳，學習效率低。
- 問題追溯困難： 市場出問題時，無法快速回溯是哪個測試階段遺漏了。
1.3 思維轉變：Debug 過的錯 → 必須形成 Searchable Knowledge
要解決痛點，必須將每次 Debug 視為「知識創造」。
- 結構化儲存： 不能散落在個人的筆記本，必須在中心化知識庫。
- 可搜尋性 (Searchable)： 必須能透過 Error Code、平台型號快速找到解法。
- 可訓練性： 這些知識應成為新人培訓的教材。
二、建立知識庫的三大層級：從快速記錄到團隊智慧
知識庫建立並非一蹴而就，我將其分為三個層級，循序漸進：
Level 1: 快速記錄——捕捉第一手異常信息
- 目的： 在問題發生當下，快速捕捉資訊，確保不遺漏。
- 工具： Google Sheet, Notion, Excel。
- 記錄範例：
日期： 2025-07-12 10:30 AM 型號/SN： ABC-12345 / SN: XYZ789 平台： Intel Z690 / BIOS F15 / Win11 現象： FIO 測試中途報錯，Device 消失，BSOD。 初步判斷： 疑似 FW Crash 或 PCIe Link 不穩。 Log： (複製關鍵幾行錯誤代碼)
Level 2: 問題分類與歸納——建立知識的骨架
- 目的： 將零散異常串聯，建立清晰的分類架構。
- 工具： Notion, Confluence, Jira。
- 分類架構建議：
- Platform Related: PCIe Link Training Fail, NVMe Init Timeout...
- Command Related: Command Abort, Data Mismatch, Trim Failure...
- FW Crash: Controller Hang, Assert, Unexpected Reset...
- Performance: Latency Spike, Drop...
Level 3: 內部 Wiki 建置——沉澱為可傳承的 SOP
- 目的： 提煉成標準操作流程 (SOP) 與 Debug 指南，用於教學與回溯。
- 工具： Confluence, SharePoint。
- 內容範例 (以 PCIe Link Training Fail 為例)：
- 問題描述： 熱插拔後無法建立穩定 Link。
- 可能原因： BIOS 設定、PHY 參數不匹配、信號品質問題。
- Debug SOP：Step 1: 檢查 BIOS 與 Device Manager。Step 2: 收集 dmesg 與 SMART Log。Step 3: 使用 PCIe Analyzer 抓取訓練序列 (關鍵！)。Step 4: 交叉驗證 (換 Slot/換主機)。
- 典型案例： 附上 Intel Z690 偶發 Fail 的分析報告連結。
三、實戰技巧：我怎麼整理問題回溯流程
3.1 一個異常 Log → 怎麼進入記錄系統
- 收到 Fail Log → 標記資訊： 第一時間標記 SSD 型號、平台、FW 版本、測試場景。
- 手動截圖 + 初步推論： 針對 UI 錯誤或 BSOD 截圖。使用 Notion Template 填寫「疑似原因」（例如：疑似 PCIe Link Loss）。
- 成功復現後，補上 Root Cause： 這是最重要的一步。一旦找到根本原因（Root Cause）與解決方案（Fix/Workaround），必須回填到系統中，完成知識閉環。
3.2 標籤系統建議：提升搜尋效率
善用 Tag 是搜尋的關鍵：
- 關鍵字：
PSA Timeout,PRP Miss,Reset Fail,Data Corruption - 狀態：
Open,Reproduced,Fixed,Cannot Reproduce - 優先度：
P0 Critical,P1 High - 根本原因：
Root Cause: FW Bug,Root Cause: Host Issue,Root Cause: Test Env
3.3 實戰案例：2 分鐘內找到一年前的類似錯誤
曾有一次壓力測試出現罕見的 NVMe Command Abort。FW 團隊認為是新 Bug，但我輸入錯誤碼搜尋知識庫，發現一年前在不同平台也發生過完全相同的 Error Code。 當時的紀錄顯示原因為：「極端 I/O 下特定 Buffer 溢出」。 雖然平台不同，但錯誤特徵一致。我將舊紀錄提供給 FW，他們迅速定位到類似邏輯問題，原本可能要幾週的 Debug，縮短到兩天內解決。
四、從個人知識 → 團隊傳承：構建共享的 Debug 記憶體
4.1 一個人 Debug 很強，不如一個團隊有一套 Debug 記憶體
SSD 驗證涉及 HW/FW/Driver/OS，單兵作戰能力有限。共享知識庫能讓團隊在關鍵成員不在時，依然能依賴「團隊記憶體」推進進度，並降低跨領域 Debug 的門檻。
4.2 建議每季 Review 一次知識庫
知識庫是活的，建議每季召開一次 Knowledge Review Meeting：
- 挑出 Top 5 高頻錯誤進行分享。
- 更新過時的 SOP。
- 針對高頻錯誤，提煉出通用的預防措施（例如：是否該在前期增加某項測項？）。
4.3 給新人的 Onboarding：從前 20 大 Bug 學習
對於新人，與其叫他讀幾百頁的 NVMe Spec，不如讓他**「研讀知識庫中的 Top 20 Bug」**。
- 實戰導向： 了解產品最容易死在哪裡。
- 建立信心： 學習前人的分析邏輯，縮短獨立 Debug 的陣痛期。
- 雙向貢獻： 鼓勵新人在遇到問題時，也開始練習撰寫紀錄。
