我很想听听 serverfault 社区在生产中使用Ksplice的经验。
来自维基百科的快速简介：
Ksplice 是 Linux 内核的免费和开源扩展，它允许系统管理员将安全补丁应用到正在运行的内核，而无需重新启动操作系统。
和
Ksplice 可以在不重新启动内核的情况下应用任何只需要修改内核代码的源代码补丁。与其他热更新系统不同，Ksplice 仅将统一的 diff 和原始内核源代码作为输入，并且它可以正确更新正在运行的内核，而无需进一步的人工协助。此外，利用 Ksplice 在系统最初启动之前不需要任何准备（例如，正在运行的内核不需要经过特殊编译）。为了生成更新，Ksplice 必须确定内核中的哪些代码已被源代码补丁更改。
所以有几个问题：
稳定性如何？您在内核的“无需重启的实时修补”中遇到过什么奇怪的问题吗？内核恐慌还是恐怖故事？
我一直在一些测试系统上运行它，到目前为止它一直像宣传的那样工作，但我对在“全力以赴”并将其部署到我们的生产服务器之前，其他系统管理员在 Ksplice 方面的经验感兴趣。
那么，有人在生产中使用 Kspice 吗？
更新：嗯，几个小时后没有看到关于这个问题的任何实际活动（除了一些点赞和收藏）。也许为了激发一些活动，我还会再问一些问题，看看我们是否可以进行讨论......
“如果您知道 Ksplice，您是否有理由不使用它？”
“你是否觉得它仍然过于前沿，未经证实或未经测试？”
“Ksplice 不适合您当前的补丁管理系统吗？”
“你讨厌拥有运行时间长（且安全）的系统吗？” ;-)
（首先，免责声明：我为 Ksplice 工作。）
我们自然会在自己的生产基础设施上使用它，但更重要的是，我们的 500 多家企业客户也是如此（截至 10 年 12 月的数量）。
一位系统管理员在 Red Hat Enterprise Linux 用户邮件列表上提出了同样的问题，并得到了许多答案，其中一些摘录如下：
和
人们表达的一个担忧不是稳定性，而是它与现有审计和监控工具的集成：
正如您所料，这是我们现在大力投资的领域。
我听说过 Ksplice，当时我认为这是个好主意。没有停机时间，没有重新启动。但后来我进一步研究了它，我害怕尝试它。
我避免它的原因是：
Linux 内核已经非常复杂。Ksplice 增加了复杂性。更复杂=更多失败。
在远程服务器上试验 Ksplice 将是鲁莽的，因为故障会导致长时间的停机和昂贵的维修。
就我而言，唯一的好处是更高的正常运行时间统计数据。
我一直在我的家庭服务器上使用 Ksplice（正常运行时间并不重要，但很不错）。根本没有任何问题 - 通过 Apt 偶尔更新到客户端，内核更新本身没有任何问题，并且没有（明显的）不稳定。
但是，通常的“YMMV”免责声明适用！;-)
Ksplice 是一个开源内核扩展，但请记住，虽然该软件是免费的，任何人都可以使用，但它是专门由一家从事 Linux 补丁管理的公司（也称为“Ksplice”）创建的。Ksplice（内核模块）只有在您的内核有 ksplice 可用的补丁时才真正有用，除非您与 Ksplice（该公司）签订了支持合同，否则您可能永远不会看到这些补丁。
因此，虽然 ksplice（该工具）相当成熟，但只有在您考虑使用 Ksplice（该公司）进行补丁管理时才真正相关。
好问题。我最初的反应是“我为什么需要这个？”
很可能不需要它。即使在五个九的设置中，“计划维护”通常也是 SLA 中允许这种停机时间的条款。如果您有 HA 设置，则切换到故障转移，在一个机器上安装内核，重新启动，然后在另一个机器上重复。如果您连五分钟的停机时间都买不起，那么无论如何您都需要进行故障转移设置。
虽然它是一项新技术，但我还没有看到它有太多实际用途。当然，内核安全更新是必要的，并且应该尽快修补，但是与简单地安装新内核并重新启动相比，这可以为您节省多少时间/精力/担忧？如果事情不顺利怎么办？假设您有幸拥有 PXE 类型的恢复选项，那么您通过重新映像系统浪费了多少时间？
此外，如上所述，如果在多台服务器上出现问题，远程试验这样的技术可能是一场灾难。在您的测试中，您是否使用与 DC 中完全相同的硬件？在一台机器上播放好的东西可能在另一台机器上播放不好。
只是我的 0.02 美元。
这是很久以前的事了，但 Ksplice 可以为您做的很多......
提高了安全性，因为它允许在不停机的情况下进行动态修补，这在高度敏感的环境中非常重要。
提高了稳定性，因为它允许在不停机的情况下进行即时修补，在没有时间重新启动的情况下，事情可以得到改善。
提高了性能，因为它允许在不停机的情况下进行动态修补，只应用你需要的东西来做你需要它做的事情。
提高了主动性，因为它允许在不停机的情况下进行动态修补，因此可以为热门的新补丁设置测试场，同时轻松恢复到先前的状态。