高可用性伺服器的 Linux 核心即時修補

Linux 核心即時修補可以在核心持續運作期間，套用指定的保安修補或錯誤修正，毋須立即重新啟動伺服器。對高可用性伺服器而言，這可以縮短節點需要排空流量或暫停服務的時間，但並不代表所有核心更新都可以免重新啟動完成。

實際要問的不是即時修補能否取消維護，而是它能否讓營運團隊更好地控制重新啟動的時間。即時修補可以先處理已知的核心問題，讓團隊在驗證變更、安排受控重新啟動，或等待適合工作負載的維護時段期間降低風險。能否使用某項功能，取決於作業系統供應商、修補工具、核心版本、已載入模組及服務架構。

Linux 核心即時修補會改變甚麼

即時修補通常會提供一個修補模組，在現有核心持續運作時更換指定的核心函式。即時修補框架會把新的呼叫導向修正後的實作，並在安全地完成現有執行流程後停用舊程式碼。不同供應商工具的具體機制可能不同，而每個修補仍只適用於其支援的函式及核心配置。

自動化可以令這個流程更容易重複執行。Dataplugs 的指南 什麼才是專屬伺服器營運中最值得做的自動化機會？說明如何把定期更新、監控、備份及維護轉化為受控的營運程序；同樣的原則亦適用於在伺服器群組中批准、套用及驗證即時修補。

• 應把即時修補視為對正在運行的核心作出的變更，而不是取代變更管理。
• 套用更新前，記錄正在運行的核心版本、Linux 發行版、修補框架、已載入模組、工作負載角色及目前的即時修補狀態。
• 確認供應商修補適用於準確的核心版本及編譯版本，並核實修補工具顯示受影響的函式受到支援。
• 預先定義修補後需要的證據，包括修補狀態、核心訊息、服務健康狀態、應用程式錯誤、延遲及相關保安警報。
• 保留重新啟動的路徑。無法重新啟動、復原或透過主控台連線的節點，不適合作為高可用性環境的安全修補目標。

按工作負載及故障範圍安排修補

高可用性並不是單靠修補工具建立的。服務應保留足夠容量及備援，讓團隊可以在套用修補期間把其中一台伺服器移出服務。需要時先在負載平衡器排空流量、暫停排程工作、保護集群法定人數，並在變更節點前檢查複製延遲。如果所有複本共用相同核心映像、硬件類別或故障範圍，一起修補便可能令維護工作變成服務中斷。

修補應按照受控變更管理。Dataplugs 的指南 伺服器營運中的變更管理最佳實務是什麼？涵蓋影響分析、批准、維護時段、回滾預期及變更後檢討；這些控制措施可以為即時修補建立清晰的決策路徑，而不是把更新當作一般套件安裝。

• 把一台具代表性的節點放入金絲雀批次，並包括生產環境中重要的硬件、核心版本、模組及工作負載特性。
• 把節點移出服務前，核實負載平衡器排空、服務發現、集群法定人數、複製、備份工作及操作人員存取。
• 為套用修補、核實修補狀態、進行工作負載檢查，以及在推進下一台節點前的觀察期設定暫停門檻。
• 為不同 Linux 發行版、核心系列、硬件世代及重要性級別設定不同批次，不要假設一個修補結果適用於全部伺服器。
• 指定可以停止推進的人員，並列明在發生故障或效能異常變化後恢復推進所需的證據。

擴大批次前先驗證修補

成功執行即時修補指令，只是第一項檢查。推進金絲雀批次前，應記錄 CPU 飽和度、記憶體壓力、排程器行為、儲存延遲、網絡錯誤、要求延遲、錯誤率、佇列深度、複製健康狀態及主要應用程式交易的基線。修補後及觀察期間比較同一組訊號。核心可能顯示修補已載入，但工作負載仍可能受到驅動程式、輸入輸出或應用程式層面的回歸影響。

驗證應同時覆蓋主機及服務。確認修補已啟用、預期函式已被替換、核心日誌沒有新增警告、必要模組仍然可用，而應用程式可以完成具代表性的要求。對集群系統而言，亦要檢查法定人數、複本延遲、容錯準備，以及節點重新加入正常流量後的健康狀態。

• 記錄修補前基線，並與變更記錄一併保存。
• 先在一台或少量節點套用修補，再將營運訊號與基線比較。
• 檢查即時修補狀態、核心訊息、已載入模組、服務健康狀態、監控及保安控制。
• 執行合成交易或具代表性的工作負載檢查，包括下游依賴及資料持久化路徑。
• 保留可執行的回滾途徑，包括移除修補、隔離節點、恢復流量、主控台存取，以及在不支援移除時安排重新啟動。

了解即時修補不能取代甚麼

即時修補不是讓 Linux 系統在任何情況下都可以免重新啟動變更的通用方法。供應商支援範圍可能不包括某個核心版本、已載入模組、驅動程式，或無法在運行期間安全轉換資料結構及介面的變更。韌體、硬件微碼、開機載入程式、部分驅動程式更新、主要核心升級，以及需要新的使用者空間配合的變更，仍然需要獨立的維護安排。

核心更新只是整套保安控制的一部分。Dataplugs 的文章 2025年專用伺服器安全最佳實踐將定期更新與防火牆、身份驗證、存取控制、監控、備份及其他控制措施並列。即時修補可以減少其中一項重新啟動依賴，但不能取代關閉暴露服務、檢討存取權限或測試復原。

• 把已即時套用的修補，與等待重新啟動的更新分開記錄，避免合規報告掩蓋待重新啟動的工作。
• 記錄修補取代關係、堆疊限制、依賴項、失敗嘗試，以及主機需要重新啟動的原因。
• 為不能即時修補的更新準備測試過的維護路徑，包括容量檢查、排空流量、容錯驗證、重新啟動及啟動後檢查。
• 為例外設定期限。即時修補後的節點不應在沒有負責人及檢討日期的情況下，無限期留在標準重新啟動週期之外。
• 保留主控台或帶外復原能力，因為核心變更可能在一般網絡管理仍未可用前已經失敗。

在 Dataplugs 維護模式中使用即時修補

對於在專屬伺服器上運行高可用性工作負載的團隊，即時修補最適合作為文件化維護模式的一個層次。設計應連繫伺服器資產清單、核心及模組記錄、監控、變更批准、流量管理、備份及復原存取。Dataplugs 環境可以按工作負載角色、地區、連線、硬件、備援及套用和驗證變更所需的操作存取進行評估。

成果應是一套可量度的例行流程，而不是單純部署一項工具：找出受影響主機、選擇金絲雀、排空流量後修補一台節點、比較健康訊號、在觀察期間暫停批次，然後才繼續。當修補不能安全套用時，同一份運行手冊應指示團隊安排計劃中的重新啟動，而不是鼓勵使用不受支援的替代方案。

結論

Linux 核心即時修補可以減少高可用性伺服器不必要的重新啟動壓力，但實際價值取決於兼容性檢查、按工作負載安排次序、可觀察的驗證，以及為仍需重新啟動的更新保留清晰路徑。應以它控制維護風險，而不是取消維護紀律。當專屬伺服器容量、監控、存取及變更程序互相配合，團隊便可以更早處理受支援的核心問題，同時維持可預測的復原計劃。如需進一步了解 Dataplugs 專屬伺服器環境，請聯絡 sales@dataplugs.com。