我很想听听 serverfault 社区的经验拼接在生产中。
维基百科的简短介绍：
Ksplice 是 Linux 内核的免费开源扩展，它允许系统管理员将安全补丁应用于正在运行的内核，而无需重新启动操作系统。
和
Ksplice 无需重新启动内核，即可应用任何仅需修改内核代码的源代码补丁。与其他热更新系统不同，Ksplice 仅将统一差异和原始内核源代码作为输入，并正确更新正在运行的内核，无需进一步的人工协助。此外，利用 Ksplice 不需要在系统最初启动之前进行任何准备（例如，正在运行的内核不需要经过特殊编译）。为了生成更新，Ksplice 必须确定内核中的哪些代码已被源代码补丁更改。
有几个问题：
稳定性如何？您在使用内核的“无需重启实时修补”时遇到过什么奇怪的问题吗？内核崩溃或恐怖故事？
我已经在一些测试系统上运行它，到目前为止它一直按照广告宣传的那样运行，但我感兴趣的是其他系统管理员在全力投入并将其部署到我们的生产服务器之前对 Ksplice 的体验。
那么，有人在生产中使用 Kspice 吗？
更新：嗯，几个小时后没有看到关于这个问题的任何实际活动（除了一些点赞和收藏）。也许为了激发一些活动，我还会问几个问题，看看我们是否能开始讨论……
“如果你知道 Ksplice，那么你为什么不是使用它？”
“您是否认为它仍过于前沿、尚未被证实或测试过？”
“Ksplice 是否不太适合您当前的补丁管理系统？”
“您是否讨厌拥有长时间（且安全）正常运行的系统？” ;-)
答案1
（首先，免责声明：我在 Ksplice 工作。）
我们自然会在自己的生产基础设施上使用它，但更重要的是，我们的 500 多家企业客户（截至 2010 年 12 月的数字）也使用它。
一位系统管理员在 Red Hat Enterprise Linux 用户邮件列表上提出了同样的问题，并得到了许多答案，其中一些摘录如下：
我们已经在十几台主机上运行 Ksplice 几个月了。到目前为止，它的效果与宣传的一样好。
和
我控制着 500 台以上的机器，其中约 445 台连接到 uptrack（rhel 4 和 5）。我们在重启机器之前使用 ksplice 阻止了一些 root 漏洞。由于我们仍在测试，所以我们还是推出了新内核，但我已经运行了数周的 ksplice，没有出现任何问题。
人们表达的一个担忧不是稳定性，而是它与现有审计和监控工具的集成：
使用 ksplice 的唯一“陷阱”是目前还没有任何可用的“ksplice 感知”审计工具。
正如您所料，这是我们目前投入巨资的领域。
答案2
我听说过 Ksplice，当时我觉得这是个好主意。无需停机，无需重启。但后来我进一步研究了一下，就不敢尝试了。
我避免这样做的原因是：
Linux 内核已经非常复杂了。Ksplice 又增加了复杂性。复杂性越高，失败的可能性就越大。
在远程服务器上尝试使用 Ksplice 是鲁莽的，因为一旦发生故障将导致长时间停机和昂贵的维修费用。
对我来说唯一的好处是更高的正常运行时间统计数据。
答案3
我一直在家用服务器上使用 Ksplice（正常运行时间并不重要，但有也是好事）。使用过程中从未遇到任何问题 - 偶尔通过 Apt 更新客户端，内核更新本身从未出现任何问题，也没有（明显的）不稳定情况。
不过，通常的“YMMV”免责声明适用！;-)
答案4
好问题。我的第一反应可能是“为什么做我需要这个？”
最可能不不需要它。即使在 5 个 9 的设置中，“定期维护”通常是 SLA 中允许这种停机时间的条款。如果您有 HA 设置，则切换到故障转移，在一个框上安装内核，重新启动，然后在另一个框上重复此操作。如果您无法承受框上五分钟的停机时间，那么您无论如何都需要故障转移设置。
虽然这是一项新技术，但我还没有看到它有多少实际用途。当然，内核安全更新是必要的，应该尽快修补，但与简单地安装新内核并重新启动相比，这能为您节省多少时间/精力/担忧？如果出现问题怎么办？假设您有幸拥有 PXE 类型的恢复选项，那么您通过重新映像系统会浪费多少时间？
此外，如上所述，如果在多台服务器上出现问题，远程试验这样的技术可能会带来灾难。在测试中，您是否使用与 DC 中完全相同的硬件？在一台机器上运行良好的东西在另一台机器上可能就无法正常运行。
仅我的 0.02 美元。