「有問題就先重開機。」
這句話雖然經常被拿來嘲諷 MIS，但我們也不得不承認：重開機確實能解決不少問題。
它可以重新載入驅動、釋放記憶體、重啟背景服務、清除暫時狀態，順便終止一些已經卡到連自己在幹嘛都不知道的 Process。
問題是，重開機有時候只是讓症狀暫時消失，並沒有真正找到原因。
更麻煩的是，如果一看到問題就立刻重開，我們也可能同時清掉重要的現場資訊，例如：
結果就是電腦恢復正常了，大家都很開心，但沒有人知道剛才發生什麼。
幾天後問題再次出現，我們又只能重新開機一次。
剛開始工作時，遇到陌生問題很容易進入一種慌張模式：
1.先重新開機
2.還是不行，重新插線
3.再不行，修改 DNS
4.清除快取
5.關閉防火牆
6.重裝軟體
7.突然可以用了
8.不知道是哪一步有效
表面上做了很多事情，但一次改變太多條件，最後其實無法證明任何原因。
更危險的是，其中某些測試設定可能沒有改回來。
例如為了測試連線而關閉防火牆、加入臨時路由、開放過大的權限，問題解決後卻忘記復原。原本只是一張普通報修單，最後悄悄留下新的安全風險。
真正有效的排錯應該像科學實驗：
先提出假設，一次只改變一個條件，再根據結果決定下一步。
如此即使測試失敗，也不是浪費時間，因為你至少排除了一個可能原因。
我把常用的排錯方法整理成六個步驟：
這套流程可以套用在網路、Windows、Linux、印表機、帳號權限及各種企業服務。
工具可能不同，但思考方式不太會變。
上一篇提到，使用者的描述通常比較接近感受，而不是技術問題。
例如：
「公司網站壞了。」
這句話還不能直接拿來排錯。
經過詢問與測試後，可以改寫成：
Client A 自上午 10:20 起，無法透過主機名稱開啟內部網站；同部門其他電腦正常。直接使用 Server IP 可以連線，使用 FQDN 時則顯示名稱解析失敗。
這段描述已經包含：
此時問題就不再是「網站壞了」，而比較接近：
單一 Client 無法正確解析內部網站名稱。
問題定義得越精確，後面需要調查的範圍就越小。
同一個錯誤畫面，影響一個人和影響全公司，處理順序完全不同。
可以從以下幾個方向分類：
單一使用者
可能與下列項目有關：
單一設備
優先檢查：
單一區域或部門
可能涉及：
全公司或多個廠區
優先注意：
確認範圍除了幫助定位，也能決定事件優先級。
如果只有一個人無法使用印表機，可以依一般工單處理；如果整個部門都無法連線，就應先處理服務中斷，再研究某台印表機今天到底在鬧什麼脾氣。
問題定義完成後，不要立刻修改設定。
先看看設備目前留下了哪些證據。
以網路問題為例，可以蒐集：
如果是系統服務問題，則可能檢查：
證據要在修改前蒐集。
例如使用者無法取得 IP，如果第一個動作就是手動填入靜態 IP，雖然可能暫時恢復連線，卻也繞過了原本的 DHCP 問題。
這樣只能證明靜態設定能用，不能證明 DHCP 為什麼失敗。
只看異常設備，有時很難判斷某個數值到底正不正常。
最有效的方法之一，是找一個正常案例比較。
假設 Client A 無法連接內部網站，可以找同一部門正常的 Client B，比較：
| 項目 | Client A | Client B |
|---|---|---|
| IP 網段 | 是否相同 | 正常值 |
| Default Gateway | 是否一致 | 正常值 |
| DNS Server | 是否一致 | 正常值 |
| VLAN | 所在位置 | 預期位置 |
| Route | 是否缺少 | 正常路由 |
| 瀏覽器／Proxy | 是否不同 | 正常設定 |
如果 Client A 的 DNS 是公共 DNS，而 Client B 使用企業內部 DNS，差異就非常明顯。
Baseline 不一定是另一台電腦，也可以是：
如果不知道正常狀態長什麼樣，就很容易把正常現象誤認成異常，也可能把真正的異常當作「這台設備本來就這樣」。
蒐集完證據後，就可以列出幾個合理假設。
例如 Client 無法透過名稱開啟內部網站，但直接使用 IP 可以連線，可能原因包括：
注意，這時只是「可能原因」，還不是最終答案。
好的假設需要搭配：
例如：
假設：Client 使用了錯誤的 DNS Server。
驗證：查看 ipconfig /all，並與正常 Client 比較。
預期：異常 Client 的 DNS Server 與公司標準設定不同。
下一步：暫時指定正確 DNS 後重新測試名稱解析。
如果實際結果與預期不符，就先放下這個假設，調查下一個可能性。
不要因為心裡很想讓 DNS 背鍋，就開始把所有證據解釋成 DNS 有罪。
設備沒有義務配合我們的直覺。
這是整套流程最重要，也最容易被忽略的部分。
假設某台電腦無法上網，如果你同時：
接著網路恢復，請問原因是哪一個？
不知道。
這些動作可能全部沒有關係，也可能其中一項有效，但已經無法證明。
比較合理的方式是：
例如：
如果名稱解析恢復，就往 DNS 設定調查。
如果仍然失敗，將設定恢復，再查 DNS 流量或 Record。
如果 IP 可以連而名稱不行，說明底層網路路徑大致正常。
如果 IP 也不能連，則不應繼續只查 DNS。
每一個測試都應該協助縮小範圍，而不是單純期待設備突然恢復正常。
用分層方式決定測試順序
當問題與網路有關時，可以從底層向上檢查。
這不是每次都必須從頭跑到尾。
如果只有一個 HTTPS 網站有問題，其他網路服務全部正常，就可以直接從 DNS、Port、TLS 或應用層開始。
SOP 是用來整理思路，不是強迫工程師像 NPC 一樣固定走完所有對話選項。
陷阱一：看到第一個異常，就認定它是根因
假設你發現 Client 的 DNS Cache 裡有舊紀錄，清除後網站恢復。
看起來根因是 Cache。
但也可能是 DNS Server 的 Record 剛被修改，或 Client 原本使用錯誤 DNS。清除快取只是讓它重新取得暫時可用的答案。
因此還要繼續問：
修復動作有效，不一定代表它就是最深層原因。
陷阱二：忽略最近的變更
很多事故不是設備突然決定躺平，而是環境中某件事情改變了。
例如：
詢問「最近改過什麼」不是要找人背鍋，而是要找時間上的關聯。
如果每次問變更都像在抓戰犯，久了大家就會選擇什麼都不說，排錯難度直接上升。
陷阱三：只確認技術指標，沒確認使用者功能
Ping 成功，不代表 ERP 可以使用。
Port 443 可以連，不代表登入流程正常。
Service 顯示 Running，也不代表資料庫查詢沒有問題。
修復後必須重新執行原本失敗的操作，最好由使用者本人確認。
因為最終目標不是讓指令畫面變綠，而是讓工作流程恢復。
講了這麼多，並不是說不能重新開機。
重開機是合理的修復或測試手段，但最好先完成以下事情：
對個人電腦來說，重開機通常風險較低；對伺服器、交換器、防火牆或虛擬化平台來說，重啟可能影響大量使用者，絕對不能把它當成普通按鈕。
尤其是看到核心設備異常時，不要因為不知道下一步，就用重新開機抽卡。
運氣好叫快速恢復，運氣不好就是開始寫事故報告。
修復完成後，可以進行四層驗證。
確認 IP、Route、DNS、Service、Port 或介面恢復正常。
重新執行最初失敗的動作，例如登入、開啟網站、列印或連接 VPN。
確認其他使用者、設備或服務沒有因修復而受到影響。
如果原本是間歇性問題，要經過容易復發的時間範圍，不能剛成功一次就立刻結案。
例如網路原本每十分鐘斷一次，修正後只觀察三十秒，這個驗證說服力多少有點薄弱。
進行測試前，至少記錄：
例如要暫時新增一條 Route，應先保存原始 Routing Table，並記下刪除該 Route 的方式。
測試結束後，若變更不需要保留，就立即復原。
「我等等會記得」通常是事故文件裡最不可靠的一句話。電話一響、工單一來，那條臨時規則就可能在正式環境住上半年。
遇到問題時，最直覺的做法是立刻採取行動。
今天的六步流程是：
而沒有蒐集證據、沒有評估影響，也沒有後續驗證的重開機，不是個專業的作法
iThome鐵人賽
看影片追技術