實體主機時鐘同步：chrony 來源、偏差與失同步驗證

付款回呼被判定逾期、登入權杖偶爾失效、跨程序日誌的先後順序顛倒，可能都源自同一個問題：系統時鐘未穩定同步。變更時區只能改變顯示方式，無法修正時間偏差。排查應從時間來源、同步狀態與業務容許範圍著手，而不是直接執行強制校時命令。

本文以 Debian 12 的 chrony 為例，建立「檢查來源—解讀偏差—設定同步檢核—驗證復原」的流程。AmdMetal 實體主機付款後，可在控制台查看登入憑證，再透過 SSH 連線；若有多個 IPv4，請使用第一個位址。以下操作不會修改網路位址，也不需要對外開放管理連接埠。

一、建立基準，區分顯示與校正

先記錄系統時間、時區、核心版本與目前使用的校時服務。業務日誌宜統一採用含時區的時間格式，排查紀錄則同時保留 UTC，避免將顯示差異誤認為時鐘漂移。

date --iso-8601=seconds
date -u --iso-8601=seconds
timedatectl status
uname -r
systemctl is-active chrony systemd-timesyncd

timedatectl 的同步欄位可作為線索，但不能取代時間來源檢查。也應確認沒有其他校時程序或組態管理工作同時調整時鐘。主機上的虛擬機器也要個別檢查，不能因為宿主系統正常，就認定客體系統也正常。

若尚未安裝 chrony，可透過系統套件來源安裝；但安裝過程可能啟動服務，並套用發行版的預設設定。對於已在執行業務的機器，應先審查即將生效的設定與套件安裝行為，不宜直接安裝後才觀察。

sudo apt-get update
sudo apt-get install chrony
systemctl status chrony --no-pager

執行中的資料庫、驗證服務與工作排程器可能受到牆上時鐘跳變影響。在評估業務行為之前，不要執行 date -s、chronyc makestep，也不要反覆重新啟動校時服務，試圖「修好時間」。

二、檢查時間來源，不將可達視為可信

安裝後，檢查主要設定檔及其引用的檔案。時間來源位址應採用組織核准的來源；不要照抄來路不明的公用位址，也不要將某個固定來源視為本站提供的基礎設施。

sudo grep -R -E \
'^[[:space:]]*(server|pool|peer|sourcedir|confdir|include|makestep|local|offline)' \
/etc/chrony
chronyc activity
chronyc sources -v
chronyc sourcestats -v

server、pool 用來定義來源，引用的目錄則可能帶入額外設定。重複來源應依實際伺服器去除；多個名稱也可能最終指向同一套基礎設施，不能只憑設定行數判斷來源是否彼此獨立。

在 sources -v 中，* 表示目前選用的同步來源，+ 表示參與組合計算的來源，? 表示目前無法納入來源選擇，可能與無法連線、樣本不足等情況有關。Reach 是以八進位表示的可達性歷史，377 代表最近八次輪詢都有收到回應，不代表時間一定準確。

來源異常的排查順序

先確認名稱解析，再檢查通往來源位址的路由與對外連線政策，接著觀察樣本是否持續更新。能收到 NTP 回應，只能證明通訊正常；來源時間異常、延遲不對稱或樣本分歧，仍會影響來源選擇。不要為了消除 ? 標記，就直接放寬整台機器的防火牆規則。

三、解讀偏差，避免只憑單一欄位判斷

chronyc tracking
journalctl -u chrony -b --no-pager -n 100

Reference time 應持續更新；Leap status 為 Not synchronised 時，不能通過驗收。System time 是 chrony 估計的剩餘校正量，數值接近零，不等於已獨立證實其相對於真實 UTC 的誤差。

Last offset 與 RMS offset 反映樣本與統計狀況；Root delay、Root dispersion 則提供通往參考時鐘的路徑與不確定性線索。必須將這些欄位與來源狀態一起判讀，而不是只截取一個小數，當作合格證明。

建議連續記錄多組結果，涵蓋數個輪詢週期。冷啟動後的收斂過程、網路恢復後的樣本重建，應與穩定運作期間分開判斷。不能為了縮小單次觀測值就不停調整設定，否則很難辨識究竟是哪項變更產生效果。

四、建立有等待上限的同步檢核

對於依賴時間的業務，可在啟動或部署檢查中加入有等待上限的同步檢核。以下數值僅為工程範例，實際門檻應依權杖有效期、稽核要求與業務測試決定，並非服務承諾。

chronyc waitsync 12 0.05 0 5

此命令最多檢查十二次，每次間隔五秒；要求進入同步狀態，且剩餘校正量小於 0.05 秒。第三個參數為零，表示不額外限制 skew。成功結束代表這些條件已滿足，不保證相對於真實 UTC 的誤差小於五十毫秒。

自動化工作必須讀取結束碼，不能將失敗輸出忽略：

if chronyc waitsync 12 0.05 0 5; then
    printf '%s\n' 'Clock gate passed'
else
    printf '%s\n' 'Clock gate failed' >&2
    exit 1
fi

同步檢核失敗時，應阻止相關啟動步驟並通知維運人員，不應自動以跳時方式修復。network-online.target 只涉及網路是否就緒，也不能證明時鐘已完成同步。

反向驗證同步檢核

在隔離的測試環境中，驗證沒有可用來源時，同步檢核會以非零結束碼結束；再恢復來源，驗證成功流程。不要在正式環境的實體主機上修改全域時間來製造偏差；這會同時影響所有服務，並污染用來判斷事故先後順序的日誌。

五、復原後驗收，保留可解讀的證據

若來源曾被手動標記為離線，應先確認網路已恢復，再執行 chronyc online。需要補充樣本時，可針對已設定的來源執行一次 chronyc burst 4/4，接著重新觀察來源選擇與 tracking 結果；不要循環呼叫，造成無意義的請求。

審查 makestep 時，尤其要注意類似 makestep 1.0 3 的設定：它允許在啟動後的前幾次時鐘更新中，對超過門檻的偏差直接跳時。重新啟動服務可能再次進入這個階段，因此「重啟一下」並不是沒有風險的操作。若確實需要大幅跳時，應先隔離受影響的業務，並完成復原計畫。

最終檢查應包括：

• 已選用合適的來源，參考時間持續推進，沒有長期停留在舊樣本。
• 剩餘校正量與不確定性符合業務門檻，連續觀察未見明顯惡化。
• 已驗證同步檢核的成功流程與失敗結束碼，且告警能確實送達。
• 已完成驗證、回呼與日誌排序的業務端複測，而不只是確認程序仍在執行。
• 已保留設定變更、命令輸出與觀察區間；日誌中的來源位址依存取權限管理。

耗時計算與逾時控制應優先使用單調時鐘，業務時間戳記才使用牆上時鐘。將應用程式的計時方式與主機同步驗收分開處理，才能避免一次校時讓正常耗時變成負數，也讓後續故障紀錄有據可解。

常見問題