Ubuntu 的软件更新经常需要重新启动（这可能会产生停机等副作用）。
我看到 Ubuntu 有https://www.ubuntu.com/livepatch允许在不重启的情况下更新内核，但这是付费服务。还有拼接。
是否存在升级/修补无需重启的 Linux 发行版/流程？
（我知道设置高可用性 (HA) 服务器和使用一次性服务器是最佳实践 - 所以我不是询问有关如何维持服务，但在实际的服务器上。
答案1
对于您的问题“是否存在升级/补丁永远不需要重启的 Linux 发行版/进程？”，我不知道有任何这样的发行版/进程，而且我非常怀疑是否会有真正无需重启的发行版/进程。除了 Michael Hampton 关于为什么实时补丁在任何地方都不是开箱即用的体验的评论之外，实时补丁也无法实现与重启相同的效果。
有一件事可以说明这一点：我最近调查了一个问题，其中一个特定的实用程序在大量机器上开始出现段错误。我尝试查看它使用的共享库，看看最近升级的任何东西是否破坏了它；ldd 说它不是可执行文件（即使当我将同一个二进制文件拉到我的笔记本电脑上时，ldd 可以很好地看到共享库依赖项）。我尝试在 gdb 中逐步执行它；它甚至在到达第一条指令之前就出现了段错误。
查看故障发生的时间，我发现最近应用了一个 Ksplice 补丁。我撤消了补丁，二进制文件没有出现分段错误，然后将其重新添加进去，它又开始出现分段错误。重新启动到同等补丁的内核工作正常。原来是 Ksplice 人员没有正确应用的 32 位支持补丁。值得称赞的是，他们在几个小时内发布了一个修复补丁，它无需干预就可以在我们的机群上正常工作。
另一个例子：Meltdown/Spectre 补丁的侵入性太强，以至于 Ubuntu 内核团队认为实时修补不切实际，并要求人们重新启动系统进入修复后的内核，然后才能再次接收实时补丁。
我们在工作中运行大量物理和虚拟服务器，其中大量使用 Ksplice 和 Canonical Livepatch 系统。它们都比许多其他软件可靠得多，但我仍然希望我们的服务采用易于重启的架构设计，而不是依赖内核实时修补。
答案2
使服务高可用性和使单个机器高可用性之间存在重要区别。
在大多数情况下，目标是使服务高度可用，而单台机器的可用性只是实现该目标的一种手段。但是，通过提高单台机器的可用性，距离目标的距离是有限的。
即使您可以消除由于需要更新软件而导致的所有停机时间，单个机器仍然无法 100% 可用。因此，要将服务的可用性提高到高于单个机器的可用性，您必须在更高级别设计冗余。您问题的最后一句话表明您至少在原则上知道这一点。
如果您设计的服务可用性确实高于单台机器所能提供的服务，那么就不再有实现单台机器高可用性的压力。因此，对于高可用性服务，无需避免重新启动。相反，您可以牺牲单台机器的一些可靠性来节省资金，这些资金可以用于其他可以获得更高可靠性的领域。
一旦高级系统设计为在单个硬件组件出现故障时可靠，内核的实时修补就会从优势变成风险。
这是一种风险，因为实时修补的机器和使用最新内核版本启动的机器的行为之间可能存在细微差别。这可能会引入潜在的错误，从而导致下次重新启动机器时发生中断。重新启动以获得干净的版本被视为缓解某些中断的方法，这加剧了这种风险。
有一天，您可能会遇到一次停机，您认为重新启动机器可能会有所帮助。但是当您重新启动时，您遇到了潜在的错误，阻止机器恢复到所需状态。实时修补并不是发生这种潜在错误的唯一方式，它也可能由于一些平凡的事情而发生，例如手动启用服务但从未配置为在启动期间启动，或者配置为启动过早，以至于由于未满足依赖关系而无法启动。
由于这些原因，通过以足够慢的速度定期重启各个机器，实际上可能更容易实现高可用性服务，这样您就可以检测到问题并在发生问题时暂停重启序列。