一顆硬碟的遺言

當 SMART 亮紅燈，工程師看到的不只是壞掉的硬碟

接到電話的時候，已經是下午了。

對方是台中一家自動化機械設計公司的負責人，語氣有些急：「工程師說伺服器怪怪的，你可以過來看一下嗎？」

出門前，我把診斷隨身碟、備援硬碟、萬用電表、起子、網路線一件件放進工具箱。每次遇到這種電話，我都不知道今晚幾點回公司。路上順手買了一罐提神飲料。

到了現場，把診斷隨身碟插進前面板的 USB。沒有反應。換到後面板，才順利開機進入診斷環境。

大多數人看到的是：USB 壞了。

我看到的是：這台機器已經老化到開始出現第二層症狀了。

答案後來出來了——車程不計，現場停留時間：5 小時 13 分鐘。

---

SMART 亮了什麼燈

執行硬碟健康診斷後，畫面上出現了這一行：

不是警告，是宣判。預計 24 小時內故障，請立即備份所有資料。

幾個關鍵數字：

這顆硬碟，已經 8 年沒有休息過了。

為什麼今天才壞？工程師問的第二個問題

換硬碟是第一步。但我更想知道的是——它為什麼壞，而且是現在才壞？

這台伺服器有兩顆硬碟，承擔完全不同的任務：

SMART 數據裡有一個線索讓我多看了好幾眼：

項目	Disk 1（健康）	Disk 2（故障）
總寫入量	22 TB	21 TB
總讀取量	19 TB	590 TB ⚠️
讀寫比	約 1:1（正常）	28:1（異常）
磁頭載入次數	3,202 次	16,638 次（5 倍）

兩顆硬碟的寫入量幾乎相同，但 Disk 2 的讀取量是 Disk 1 的 31 倍。

這不是資料量的問題，而是工作性質的問題。機械設計軟體和資料庫的特性，讓這顆硬碟每天都在做大量的「隨機讀取」——磁頭不斷在碟片上跳來跳去，搜尋分散的小檔案。8 年下來，機械件的累積磨損，就是今天 22,984 個壞軌的真正來源。

備份架構能救得了你嗎？

這家公司有做備份，而且架構不差：

這是標準的 3-2-1 備份架構：3 份資料、2 種媒介、1 份異地。有備份，這次才有辦法在當天把系統救回來。

但有一個隱藏的風險值得留意：E: 本地備份和 C: 系統碟在同一顆實體硬碟上。如果 Disk 1 也故障，本地備份會同時消失。

從維修到預防：工程師的三層思維

換硬碟是當天就完成的事。但在回程的車上，我一直在想一個問題：

這 22,984 個壞軌，不是今天才出現的。它一定有個過程。

如果有人一直在看著它

SMART 的數據，其實是一本連續記錄的日記。

壞軌數從 0 到 22,984，不是一瞬間發生的。這個過程可能持續了幾個月，每週多幾十個，然後幾百個，然後突然加速。

如果有一套系統持續記錄這些數字，當數字開始加速惡化時自動發出警報——那麼今天的緊急現場，很可能在幾個月前就被一封電子郵件取代了：

回到公司後，我沒有先整理工單。

我先整理 SMART 紀錄。

因為我開始相信，如果今天能整理出一套規則，下一個客戶，就不用再等到 SMART FAILED 才知道。

一顆硬碟的遺言

那台伺服器，最後順利完成了資料移轉。客戶的資料庫完整無損，設計軟體也正常啟動。

整個過程裡，讓我印象最深的，不是那串 SMART 數據，而是業主說的一句話：

「我完全不知道這台機器快壞掉了。」

如果這顆硬碟會說話，它大概會說：

「我不是今天才壞。
我已經提醒你好幾個月了。
只是沒有人在聽。」

問題從來不是硬碟壞掉，而是沒有人知道它正在壞掉。

企業不是在硬碟壞掉那一天停機，而是在沒有任何預警的那一天，被迫停機。

---

今天，我花了五個小時救回一台 Windows Server。
但真正帶回公司的，不只是 SMART 報表。
而是一個一直存在、卻很少有人正視的問題：

如果工程師的經驗，能夠變成一套每天默默運作的監控系統，
那麼下一次收到的，就不會是「救駕」電話，
而是一封提醒：「請安排本月換碟」的電子郵件。

---