我负责管理我们的生产服务器（邮件、Web、数据库都在一台服务器上）和我们的测试服务器。两者都是基于 Debian 构建的。但是，由于我对系统管理非常陌生，所以我只是在遇到必须更新的东西时才安装更新，以便我可以拥有更新的功能并修复错误。它现在是一个非常临时的过程，我想减少它。
所以我想知道知道自己在做什么的人如何处理这个问题？您多久在服务器上执行一次升级？测试和生产之间的升级过程是否不同？你总是先升级任何测试服务器吗？您是对所有软件进行全面更新，还是只安装选定的更新？
AskOverflow.Dev
我运行apt-get update -qq; 每天apt-get upgrade -duyq。这将检查更新，但不会自动进行。
然后我可以在观看时手动运行升级，并且可以纠正任何可能出错的地方。
除了维护一个打补丁的系统的安全问题，我发现如果我在补丁之间留得太久，我最终会得到一大堆想要升级的包，这让我很害怕——不仅仅是升级一个或每周两次左右。因此，我倾向于每周进行升级，或者如果它们是高优先级，则每天进行。这有一个额外的好处是知道哪个软件包破坏了您的系统（即，如果您一次只升级几个）
我总是先升级不太重要的系统。我还有一个“回滚计划”，以防我无法修复系统。（因为我们的大多数服务器都是虚拟的，所以这个回滚计划通常包括在升级之前拍摄快照，如果需要我可以恢复）
话虽如此，我认为在过去 4 年中，升级只破坏了一次或两次，那是在高度定制的系统上 - 所以你不必太偏执:)
在之前的答案之上 - 一些更具体的 Debian 事情：您应该订阅debian-security-announce和debian-announce和/或查看Debian 安全页面。
假设您正在运行 Debian 的稳定版本，大多数补丁将与安全或错误相关，这意味着任何给定软件包的版本之间不会有太多重大变化。根据 debian 补丁政策，补丁在被维护者转移到稳定分支之前也应该已经测试了一段时间。显然，这不会在修补时阻止破损，但在大多数情况下应该防止破损。
谨慎的做法是确保您的测试服务器保持最新，并且任何包含影响您和服务器的错误的软件包都应保持最新。一旦你知道补丁是稳定的，所有有安全建议的包都应该更新。
Debian 通常是一个非常稳定的操作系统，你不应该过分担心它的损坏，但是总是在更新之前阅读将要更新的内容，并留意任何看起来奇怪的东西。我也在我的 /etc/ 目录上使用 VCS 以确保可以使用“git diff”命令查看任何配置文件更改。
我进行了一次试运行（首先）以查看将要更新的内容。有时，库（在这个例子中我们称之为 libfoo）会改变它们的 API，这会破坏我们自己编写/安装的程序。如果更新了一些关键库，我会获取源代码并尝试在更新之前针对它重建我们的东西。
我还检查了我们没有跳到某些公共服务的中间版本，即 apache 等。我宁愿落后一年，不要遇到随机损坏，除非更新很关键。
如果您是系统管理员，您应该从Secunia之类的网站提取 RSS 提要，如果您的发行版要推送一些补丁，它应该会让您提前知道。
永远不要盲目地升级/更新。不幸的是，知道发生了什么问题的任务落在了您身上，而不是您的发行版包管理器身上，尤其是在您的系统支持程序员的情况下。
在我工作的地方，我们有一个相当广泛的过程，其中涉及使用名为 PatchLink 的软件来通知我们最重要的安全相关更新，我们会在测试后逐个包地应用它们。虽然我们有数千台服务器。
如果您只有两台服务器，则该过程应该简单得多。虽然我不认为做一个“apt-get update/upgrade”是你最好的选择。
我会监控您正在运行的软件的补丁，并根据这些版本中的修复决定何时升级。
由于您有一个测试服务器，显然，在应用更新之前总是测试更新。
手动更新最好是这里提到的，因为您可以看到正在发生的事情。但是，对于非常大量的服务器，这可能变得不切实际。试运行是一种标准做法，事实上，大多数包管理器会在继续之前询问您。
定期更新往往是最好的，尽管它可能是一种平衡行为。频繁更新意味着一次性减少，减少一次出错。如果事情确实出错了，那么需要检查的候选人就会减少。包也更擅长以较小的步骤进行更新，因为通常当程序员更新他们正在考虑从上一个版本到下一个版本时，他们是否会在上一个版本之外给予任何关注可能会有所不同，尽管这往往很重要主要用于快速发展的软件。
并非所有更新都是无中断的。你要注意这一点。有些会重新启动服务导致停机。
在理想的设置中，您可能具有以下内容：
对于小型设置，其中一些可能在不同程度上过度杀伤，但应牢记。
一般来说，更新对于服务器发行版来说通常是相对轻松的。这是因为他们几乎总是只坚持错误修复和安全更新。但是，如果人们对系统做了奇怪的事情或者您添加了额外的包源，您可能会遇到问题。
尽管这种情况比较少见，但它们偶尔会犯错误并破坏次要软件包版本之间的兼容性。
我喜欢 cron-apt 来自动化这个过程，但是正如@dinomite 在另一个关于更新的问题上指出的那样，专门配置它来自动化与安全相关的更新是一个非常聪明的想法——然后你可以手动更新你需要的东西。我一直在使用 cron-apt 进行所有更新，但实际上根据他的回答改变了这一点。如果你喜欢它，你可能应该投票给他的答案，而不是这个。
在 debian 上，我安装cron-apt并编辑它的配置文件，如果有任何更改，我会发邮件给我。这样，如果我的系统有更新，我就会收到通知并手动进行更新
与 cron-apt 一样，您应该查看unattended-upgrades软件包http://packages.debian.org/lenny/unattended-upgrades。
它非常易于配置，使您能够自动下载和应用安全更新，但保留其他更新以进行手动升级（或自行决定升级所有内容！）。
官方 Ubuntu 服务器指南有一个相当详细的部分，涵盖了无人值守升级包的使用https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html
注意：根据您的谨慎/偏执程度，您可以先在一组测试服务器上进行滚动升级，然后如果没有问题，让您的生产盒更新，尽管我个人没有遇到任何安全更新问题到目前为止破坏严重（敲木头）......
一旦应用，还有一个配置选项可以将每个安全更新的结果邮寄给您。此外，如果在更新期间出现任何对话框或交互式提示，需要系统管理员手动调整的提示，它也会提及这些。
我个人关闭了自动更新，并且不会定期在我的环境中的服务器上执行任何类型的包更新，除非：(b) 我因特定原因需要升级个别软件包；(c) 操作系统或软件包即将结束，它们将不再受支持，我们需要继续提供支持。我的理由是，在不知道发生了什么变化或为什么不知道发生了什么变化的情况下进行升级会为某些事情留下太多的空间。我已经做了 14 年这样的事情，而且效果很好。