我經常登入生產 web/db/tools 框並看到典型的訊息：
可以更新30個包。 16個更新是安全性更新。
我的問題是，你們要如何處理生產 Ubuntu 機器上的更新？您會自動執行這些更新嗎？您為他們設定停機時間嗎？問題是，您永遠不知道更新何時會破壞某些內容，例如現有的設定檔等。
這個問題的另一部分是，跟上補丁是“一件好事”，但補丁幾乎每天都會發布。如果每天都有新的安全修補程式可用，那麼需要進行多少次規劃停機？
我認為關於如何管理更新的答案的線程將非常有用。
答案1
與 Windows、RHEL、CentOS、SuSE、debian 等相比，為 Ubuntu 打補丁沒有什麼特別之處。
在設計補丁程式時，您需要保持的基本心態是假設一些事情將要休息。
我在設計補丁設定時傾向於使用的一些基本準則是：
- 始終使用本地系統在內部集中到安裝補丁的網絡
這可能包括使用 WSUS 或<your_os_here>內部修補程式管理電腦的映像。最好能夠集中查詢並讓您了解各個機器上安裝的補丁的狀態。
- 如果可能的話，在機器上預先進行安裝。
如果可能的話，當補丁發佈時，中央伺服器將它們複製到各個機器上。這實際上只是節省時間，因此您不必等待它們下載和安裝，您只需在補丁視窗期間開始安裝即可。
- 取得中斷視窗來安裝補丁，您可能需要重新啟動，並且可能會出現某些問題。確保這些系統的利害關係人知道正在部署修補程式。做好迎接「這個」不起作用的電話的準備。
根據我的基本理論，即補丁會破壞事物，請確保您有一個中斷視窗來應用補丁足夠長的時間來解決關鍵問題，並可能回滾補丁。您不一定需要在補丁發布後讓人們坐在那裡進行測試。就我個人而言，我非常依賴我的監控系統來讓我知道一切都在我們可以逃脫的最低水平上運行。但也要做好準備，在人們開始工作時可能會遇到一些煩人的小問題。您應該始終安排專人隨時準備接聽電話 - 最好不要是凌晨 3 點才起床修補盒子的人。
- 盡可能自動化
就像 IT 中的其他事物一樣，腳本、腳本然後再編寫更多腳本。腳本包下載、安裝啟動、鏡像。基本上，你想把修補窗戶變成一項保姆任務，只需要一個人在那裡以防萬一出現問題。
- 每月有多個窗口
如果由於某種原因無法在「指定的晚上」對某些伺服器進行修補，這使您能夠不對其進行修補。如果您無法在第 1 晚完成這些任務，請要求它們在第 2 晚有空。
最重要的是跟上補丁！如果你不這樣做，你會發現自己必須進行 10 個小時以上的大補丁視窗才能回到你所陷入的點。引入更多可能出錯的點，並使尋找導致問題的補丁變得更加困難。
這個問題的另一部分是，跟上補丁是“一件好事”，但補丁幾乎每天都會發布。如果每天都有新的安全修補程式可用，那麼需要進行多少次規劃停機？
每月一次或每隔一個月修補一次伺服器是 - 恕我直言 - 一個非常可以實現且可以接受的目標。不僅如此，您將不斷為伺服器打補丁，更不用說您會開始遇到每台伺服器需要應用數百個補丁的情況。
至於你一個月需要幾個窗戶？這取決於你的環境。你們有多少台伺服器？您的伺服器所需的正常運作時間是多少？
9x5 的較小環境可能每月只需要一個補丁視窗。大型 24x7 商店可能需要兩個。非常大的 24x7x365 可能需要每週滾動視窗才能每週修補一組不同的伺服器。
找到適合您和您的環境的頻率。
需要記住的一件事是 100% 最新是不可能的要達到的目標 - 不要讓您的安全部門告訴您其他情況。盡力而為，不要落後太多。
答案2
要做的事情：
- 進行備份
- 確保它是可恢復的備份（儘管，這兩點是一般性的點）
- 升級時嘗試將流量引離生產環境。
- 嘗試使用帶外存取方法（KVM、序列控制台、本機存取或遠端控制）以防萬一出現問題。
- 在一台伺服器上進行測試，然後確保一切正常，然後再將更新部署到更多伺服器上
- 如果可以，請使用 puppet 以確保多個伺服器上的版本號相同。 （也可以用它來強制升級）
- 在測試伺服器上，將設定檔的版本與新的（已安裝的更新）版本進行比較，並確保沒有任何內容會嚴重破壞事物。我似乎記得 dpkg 在安裝與目前安裝的版本不同的新版本之前詢問過。
要避免的事：
- 在中午進行更新，或週一早上 09:00，或週五下午 5 點！ （感謝@3influence！）
- 在大型資料庫伺服器上升級 MySQL（重新啟動可能需要很長時間）
- 一次處理所有伺服器（尤其是核心）
- 做任何可能改變 /etc/networks 的事情（因為你可能會失去連線）
- 自動更新可以執行上述操作，而無需您在場檢查一切是否正常。
答案3
另一點值得一提：如果您習慣了 Windows，您會驚訝地發現大多數 Linux 更新都這樣做不是需要停機或重新啟動。有些是這樣做的，例如核心更新。但需要重新啟動或停機的更新通常會被標記為此類，並且可以按單獨的計劃進行處理。
答案4
對於 ubuntu LTS 系統，我們會以以下方式處理更新：
- 維護一套驗收測試來檢查我們軟體中的所有關鍵路徑
- 每天凌晨 4 點在無人值守的情況下安裝安全升級，並立即執行驗收測試。如果出現任何問題，工程師會接到傳呼，並且有充足的時間來修復問題或在上午 9 點之前回滾。迄今為止，這種情況在五年內只發生過兩次 - LTS 經過充分測試且穩定。
- 我們每週都會透過藍/綠部署自動重新部署整個基礎架構（在 digitalocean 上），從而使所有軟體包保持最新版本。如果新部署未通過驗收測試，部署將被暫停，直到工程師可以偵錯問題。
對我們來說，下一個合乎邏輯的步驟是消除記憶體中的會話訊息，這樣我們就可以每天甚至每天多次重新部署基礎設施，而不會影響客戶並消除步驟 (2)。
這種方法維護成本低，並且完全避免了維護窗口。