核心更新：為什麼最危險的更新也是最安靜的

核心更新安裝完成，安裝過程順利結束，一切看起來都沒有改變。系統仍在執行舊核心，因為新核心只有在重新啟動後才會生效。

而危險正是藏在這裡。

原因與結果之間隔了好幾週

大多數套件失敗都會在操作當下顯現。服務停擺、出現錯誤，當天就會察覺。

核心不是這樣。問題會在下一次開機時出現，而那次開機未必是排定好的維護夜晚。停電了，機器自行重新啟動，然後就再也沒有回來。

在那一刻，沒有人會把它和上個月做的那次更新聯想在一起。眼前只有一個無法解釋的故障，看起來完全不像更新造成的問題。

通用原則：新的東西在經過驗證之前，不應成為預設

這是本文可以帶到其他地方的教訓，而且不只適用於核心。

新核心可以安裝，但永久的預設值應該維持舊核心。新核心只應該以下次開機時試用一次的選項來嘗試。

這樣設定之後，故障的樣貌就會改變：如果機器卡住，下一次開機時會自行回到舊核心。因為一次性的選擇，依定義就只生效一次。

得到的好處是：故障的名稱變成什麼事都沒發生，而不是機器不見了。

第二層：已安裝的東西不應悄悄成為預設

核心一安裝完成，大多數系統就會決定從此以最新的核心開機。如果不希望這樣，就必須在更新之前固定目前執行中的核心。

固定並不會阻擋新核心，只是讓它不會自行成為預設。想試用時，再自行選擇。

第三層：誰會發現機器卡住了

回退機制要能運作，必須有某個東西指出這台機器沒有起來。如果有硬體層級的看門狗，就由它負責，並重新啟動機器。

如果沒有，回退就需要手動重設。這不代表機制沒有用，但必須事先知道：在沒有看門狗的情況下，會自動回退這句話只對了一半。

即使沒有任何產品也成立的規則

核心更新之後，要刻意且盡快重新啟動。趁有人看著的時候。

自己排定的重新啟動是一次測試。三週後因停電而被迫的重新啟動則是一次事故。兩者唯一的差別，在於當時是否有人在場。

Atlas 的做法

Atlas 執行更新時，預設會固定目前執行中的核心，因此新安裝的核心不會自行成為開機預設。這個行為並非強制：它是一個可以在介面中關閉的選項。產品在這裡不替人做決定，而是把安全的一方設為預設。

經驗證的切換機制同樣建立在上述原則之上：永久的預設值一律是舊核心，新核心只透過一次性的下次開機來試用，若卡住，系統會自行回退。開機管理程式的類型會在執行時偵測，因為每台機器都不一樣。

另外還有兩個誠實的限制：

這個機制預設以僅觀察模式運作。也就是說，它會說明自己會做什麼，但不會更動開機設定。實際介入是另一個獨立的選擇。

如果沒有硬體看門狗，這個機制不會悄悄忽略這件事：它會妥善地停用自己，並說明可能需要手動重設。提出一個不存在的保證，比完全不提供保證更糟。