在不同的操作系統中，有許多實用程序可以對運行中的代碼進行熱修補。 Linux的 kpatch和 livepatch功能就是一個示例，這些功能允許修補正在運行的內核而不會中斷其運行。它的功能是有限的，只能對內核進行微不足道的更改，但這通常足以緩解許多關鍵的安全問題，直到找到時間進行適當的修復為止。這種技術通常稱為動態軟件更新。

我應該指出，儘管這些站點實際上沒有停機時間（高可用性）因為實時補丁，所以不是那麼可靠，而是因為冗餘。每當一個系統出現故障時，就會有許多備份可以立即開始路由流量或立即處理請求。有很多不同的技術可以完成此任務。冗餘級別提供了顯著的正常運行時間，以 nines為單位。三點九的正常運行時間為99.9％。四個9的正常運行時間是99.99％，依此類推。“聖杯”是五個9正常運行時間，即99.999％的正常運行時間。您列出的許多服務由於其遍布全球的冗餘備份系統而具有五個九的可用性。

我在一次Netflix員工的安全會議上觀看了一次演講。他們根本不打補丁。相反，當需要修補程序時，它們會立足新實例，然後吹走未修補的實例。他們幾乎一直在這樣做。他們稱其為紅黑部署。

簡短的答案是：

它們確實會重新啟動。

您似乎假設Amazon和Google在單個服務器上運行，如果那樣重新啟動後，整個站點/服務都已關閉。這與事實相去甚遠-大型服務通常在許多並行工作的服務器上運行。若要進一步閱讀，請查看諸如集群，負載平衡和故障轉移​​a>之類的技術。

Google例如，具有遍布全球的十幾個數據中心，每個數據中心都擁有大量服務器（估計每個中心 100,000-400,000服務器）。

環境，更新（功能更新和安全更新）通常作為滾動部署安裝：

• 選擇一些服務器子集
• 在子集
• 重新啟動子集；同時，其他服務器接管了
• 重複下一個子集的操作：-）

還有其他選項，例如熱補丁，但使用頻率不高以我的經驗，至少在典型的大型網站上沒有。有關詳細信息，請參見森林的答案。

您可以在“軟件部署”下選中“ 部署活動”。一種常見的方法是在服務之前使用負載均衡器，並相應地重定向流量。在一種稱為“藍綠色部署”的技術中，您將流量從“藍色”服務器重定向到“綠色”服務器。這當然沒有用戶端的停機時間，但前提是應用程序可以正確地解決此問題，例如通過無狀態服務。

假設您的應用程序在藍色服務器上運行v1，而負載均衡器將流量定向到該服務器。您可以將綠色服務器（不接收任何流量）升級到v2。然後，您可以重新配置負載均衡器，以將流量定向到綠色服務器。因此，您無需停機即可從v1升級到v2。

您也可以在測試過程中使用藍綠色技術。例如，您將負載均衡器配置為將95％的流量引導到藍色服務器（v1），並將5％的流量引導到綠色服務器（v2）。這樣一來，您可以在流量減少的情況下測試新版本，並且在出現錯誤的情況下對用戶的影響也較小。

集群和代理時非常容易。因為您有許多節點能夠完成相同的工作（對於數據存儲庫，例如搜索引擎，Hadoop文件系統等，則為幾個）。

進行網絡搜索。您訪問了www.altavista.com。 DNS條目列出了六個IP地址，您的客戶端隨機點擊了一個。每個IP都是一個Cisco路由器，該風扇將風扇散佈到內部IP地址上的8台物理前端服務器中的任意一台（共48台）。該服務器對您的查詢進行規範化（刪除空白等），然後對其進行MD5哈希處理。 MD5決定查詢將訪問300個代理服務器中的哪個。該查詢通過標準協議（例如SOAP）發送到代理。

前端服務器是可互換的，因為它們僅處理單個查詢的瞬時需求。在最壞的情況下，客戶的查詢被丟棄。當前端服務器開始出現故障時，可以使用RRD數據或其他數據收集來監視，然後將其流量重新路由到備用服務器。思科路由器也是如此。

代理首先檢查其緩存。對於緩存命中，它將進行本地化混合併將答案發送回；完成。如果是“緩存未命中”，則代理會將查詢散發到搜索集群。

如果代理髮生故障，可以再次為該代理交換另一台物理計算機。現在，它變得更為關鍵，因為代理不可互換。每個人“擁有”搜索結果頻譜的一小部分。因此，如果0x0000-0x00d9計算機掉線，替代者必須知道介入該範圍。更糟糕的是，那台替代機器將有一個空的緩存，因此每個搜索查詢都將是一個緩存未命中。這將使每個被關閉的代理服務器適當上的負載適當稍微增加 。這意味著，如果您同時彈跳所有代理，則請勿在高峰搜索時間內這樣做！

搜索集群具有相似的層次當然，由於冗餘和冗餘，搜索數據庫的每個部分都位於多個節點上，因此，如果一個節點發生故障，其他節點可以提供該結果的一部分。

我以代理為例。通過SOAP進行通信，通過某種類似的高級協議進行通信。進出數據都是暫時的，但緩存對平衡搜索引擎群集負載很重要。關鍵是，它可以隨時互換，最壞的情況是一些搜索超時。前端服務器會注意到這一點，並且可以簡單地再次發送其查詢，此時新代理將啟動。

因此，如果您有300個代理，則需要1/2個小時一個代理來恢復其緩存，您可以使搜索引擎的負載增加20％，然後可以每30秒交換1個代理，因此在任何滑動的30分鐘內，有60個代理（20％）正在重建緩存。假設甚至迫切需要快速實現 。

該示例需要花費2-1 / 2個小時才能推出，如果緊急威脅需要更快的響應，那麼您要么會忍受更多高速緩存未命中之苦，要么就將服務中斷足夠長的時間進行修補（但在搜索中）引擎示例高速緩存未命中仍然是一個問題，當您重新啟動時。我已經看過緊急數據庫重新加載和必要的高速緩存刷新後的RRD圖，這是值得一看的。）

當然通常可以修補，停止和重新啟動該過程，而無需完全重新啟動。我在生產節點上看到了2年的正常運行時間。