#1 楼
不同操作系统中有多种实用程序，可对运行中的代码进行热修补。 Linux的kpatch和livepatch功能就是一个例子，可以在不中断其运行的情况下修补正在运行的内核。它的功能是有限的，只能对内核进行微不足道的更改，但这通常足以缓解许多关键的安全问题，直到找到时间进行适当的修复为止。通常将这种技术称为动态软件更新。我应该指出，由于实时修补，实际上没有停机时间（高可用性）的站点不是那么可靠，但是由于冗余。每当一个系统出现故障时，都会有许多备份，这些备份可以立即开始路由流量或立即处理请求。有很多不同的技术可以完成此任务。冗余级别提供了可观的正常运行时间（以九为单位）。三点九的正常运行时间为99.9％。四个9的正常运行时间是99.99％，依此类推。“圣杯”是五个9正常运行时间，即99.999％的正常运行时间。您列出的许多服务由于其遍布全球的冗余备份系统而具有五个九的可用性。
评论
一旦所有HA基础结构都准备就绪，您实际上最好避免进行实时修补。实时修补会危害您的可靠性。 1.该错误可能已经导致内存中的数据结构出现问题，尽管您已经应用了实时补丁，但由于先前引入的问题仍然受到影响。 2.应用实时补丁与引导实际补丁内核之间可能存在细微差异，导致您的应用程序只能在前者上运行。下次重新启动时，您将遇到一个漏洞，到那时，该漏洞将很难得到缓解。
–卡巴斯德
18-10-24在12:31
@kasperd此外，3.实时修补受到更多限制，需要仔细考虑和测试，并在运行时添加其他间接寻址。为什么麻烦您一次一个地重新引导系统？无论如何，您可能已经在定期执行哪些操作了，因为当您拥有这样的群集时，为什么不呢？
–罗安
18-10-24在14:18
为了完整起见，在答案中可能值得一提的是，“五个九”或99.999％的可用性对应于每年仅超过5分钟15秒的停机时间。六个九（99.9999％）每年的停机时间不到32秒。
–用户
18-10-24在14:50
@immibis：在过去的几年中，Stack Exchange的停机时间已经超过一个小时，因此绝对不会达到99.999％
– BlueRaja-Danny Pflughoeft
18-10-24在21:36
@pipe您是否暗示政府网站很重要？商业网站更加关注可靠性，因为如果网站宕机，用户可以切换到竞争对手。政府网站的竞争不一样，如果用户停止使用他们的网站，他们也不会因此损失任何利润。这可能意味着您作为用户认为这些网站更为重要。但这同时意味着政府没有动力将可靠性放在首位。
–卡巴斯德
18-10-25在11:34
#2 楼
我在Netflix员工的一次安全会议上观看了一个演示。他们根本不打补丁。相反，当需要修补程序时，它们会站起来创建新实例，然后吹走未修补的实例。他们几乎一直在这样做。他们称其为红黑色部署。评论
有趣。看起来好像是滚动部署的一种变体-也许我们可以称其为“推土机部署”-raze and rebuild :-)。
–sleske
18-10-24在8:24
我认为这被称为红绿色部署，但在Netflix，他们称之为红黑色。
–mcgyver5
18-10-24在8:27
至少根据我的经验，红绿色部署是如果您有两个冗余的完整服务器集群，您可以在其中一次切换（一次），而滚动部署则只有一个集群，它会逐个更新。但是我不确定每个人都使用这样的术语。
–sleske
18-10-24在8:55
它是“蓝绿色”，而不是“红绿色”，但是@sleske的解释是正确的。 （我认为使用“蓝绿色”是因为“红绿色”听起来像是“红绿色重构” TDD方法。）但是，是的，Netflix称其为“红黑色”，因为它们是公司的颜色。
–曼上尉
18-10-24在13:43
也许他们应该将其重命名为“橙色（是新的）黑色”？
– Doktor J
18-10-25在14:02
#3 楼
简短的答案是：它们确实会重新启动。
您似乎假设Amazon和Google在单个服务器上运行，如果重新启动，则整个站点/服务下来了。这与事实相去甚远-大型服务通常在许多并行工作的服务器上运行。若要进一步阅读，请研究诸如群集，负载平衡和故障转移之类的技术。例如，Google在全球范围内拥有十几个数据中心，每个数据中心拥有大量服务器（估计有100,000个）每个中心有-400,000台服务器。）在这种环境中，更新（功能更新和安全更新）通常作为滚动部署安装：服务器
在子集上安装更新
重新启动子集；同时，其他服务器接管了
下一个子集的重复：-)
还有其他选项，例如热补丁，但至少在我的经验中，它们并不常用不在典型的大型网站上。有关详细信息，请参见森林的答案。
评论
Heck Netflix服务器将莫名其妙地重启并崩溃，只是为了让您保持警惕。他们称之为混沌猴子。
–阿伦
18-10-24在9:06
@kasperd前一天，我发现那里是一个混乱之港。他带走了整个可用区。只有红色按钮可以达到相同的效果。
–阿伦
18-10-24在14:18
您可以添加3.5：检查没有损坏。更适用于其他类型的更新，但是早期恢复还原的能力是使其缓慢的重要原因。很好的答案，IMO应该是公认的。
–传真机
18-10-24在22:07
@Aron Google拥有DiRT，它在某种程度上可以说是“混沌猴子”-模拟中断通常与丢失整个集群甚至数据中心和办公室有关。
–传真机
18-10-24在22:08
还听起来像OP假设他们正在运行Windows 10 ...
–马祖拉
18-10-25在5:29
#4 楼
您可以在“软件部署”下选中“部署活动”。一种常见的方法是在服务的前面使用负载均衡器，并相应地重定向流量。在一种称为“蓝绿色部署”的技术中，您将流量从“蓝色”服务器重定向到“绿色”服务器。这当然没有用户端的停机时间，但前提是应用程序可以正确地解决此问题，例如通过无状态服务。
假设您的应用程序在蓝色服务器上运行v1，而负载均衡器将流量定向到该服务器。您可以将绿色服务器（不接收任何流量）升级到v2。然后，您可以重新配置负载均衡器，以将流量定向到绿色服务器。因此，您已从v1升级到v2，而没有停机。
您也可以在测试过程中使用蓝绿色技术。例如，您将负载均衡器配置为将95％的流量引导到蓝色服务器（v1），并将5％的流量引导到绿色服务器（v2）。这样，您可以在流量减少的情况下测试新版本，并且在有错误的情况下对用户的影响也较小。
#5 楼
当事物聚集和代理时，这非常容易。因为您有许多节点可以执行相同的工作（或者在数据存储库（例如搜索引擎，Hadoop文件系统等）中有多个）可以进行Web搜索。您访问了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年的正常运行时间。
评论
是什么让您认为Google无法负担重启服务器的费用？您不必一次全部重新启动它们。如今，任何高于95％的硬件可用性正常运行时间都被认为是昂贵且过时的。大多数Web服务只是简单地将其服务分布在群集中，以实现接近100％的可用性，这比操作系统和硬件同类产品的成本要低。.
@DmitryGrigoryev正确，不需要全部重新启动，这是这里问题的核心。冗余系统是用于高可用性或“零停机时间”（从OP窃取描述）的常见方法。
冗余和负载平衡是此处的关键概念
如果您对Google如何进行可靠性工程特别感兴趣，建议您免费阅读Landing.google.com/sre/books。尽管其中很多都是围绕站点可靠性工程工作的概念和文化组成部分，但那里也有相当多的技术信息。