我负责管理我们的生产服务器（邮件、网络、数据库都在一台服务器上）和测试服务器。两者都是基于 Debian 构建的。但是，由于我对系统管理还很陌生，因此我只在遇到需要更新的东西时才安装更新，以便获得新功能并修复错误。目前这是一个相当临时的过程，我希望让它不那么临时。
所以我想知道那些知道自己在做什么的人是如何处理这个问题的？你们多久对服务器进行一次升级？测试和生产之间的升级过程是否不同？你们总是先升级任何测试服务器吗？你们是对所有软件进行全面更新，还是只安装选定的更新？
答案1
我跑apt-get 更新 -qq；apt-get 升级 -duyq每天。这将检查更新，但不会自动执行。
然后，我可以在观察的同时手动运行升级，并可以纠正任何可能出错的事情。
除了维护已打补丁的系统的安全问题之外，我发现如果补丁间隔太长，我最终得到了一大堆包裹需要升级的软件包很多，这让我很害怕，这比每周升级一两个软件包要可怕得多。因此，我倾向于每周升级一次，如果优先级高，则每天升级一次。这样做还有一个好处，就是知道哪个软件包破坏了你的系统（例如，如果你一次只升级几个软件包）
我总是先升级不太重要的系统。我还制定了“回滚计划”，以防无法修复系统。（由于我们的大多数服务器都是虚拟的，因此这个回滚计划通常包括快照升级之前，如果需要我可以恢复到
话虽如此，我认为在过去的 4 年里，升级只出现过一两次问题，而且是在一个高度定制的系统上 - 所以你不必太过偏执 :)
答案2
除了之前的答案之外，还有一些更具体的 Debian 内容：你应该订阅Debian-安全公告和debian-宣布和/或查看Debian 安全页面。
答案3
假设您正在运行 Debian 的稳定版本，大多数补丁将与安全或错误有关，这意味着任何给定软件包的版本之间不会有太多重大变化。根据 Debian 补丁政策，补丁在被维护者移至稳定分支之前也应该经过一段时间的测试。显然，这不会阻止修补时出现故障，但在大多数情况下应该可以防止故障。
明智的做法是确保您的测试服务器保持最新状态，并且任何包含影响您和您的服务器的错误的软件包都应保持最新状态。一旦您知道补丁稳定，就应该更新所有包含安全警告的软件包。
Debian 通常是一个非常稳定的操作系统，您不必过于担心其出现故障，但是，在更新之前，请务必阅读即将更新的内容，并留意任何看似异常的情况。我也在 /etc/ 目录中使用 VCS，以确保可以使用“git diff”命令查看任何配置文件更改。
答案4
手动更新是最好的，正如这里提到的，因为您可以看到正在发生的事情。但是，对于大量服务器来说，这可能变得不切实际。试运行是一种标准做法，事实上，大多数包管理器都会在继续之前询问您。
定期更新往往是最好的，尽管这可能有点平衡。频繁更新意味着一次更新更少，一次出错的可能性更小。如果真的出错了，需要检查的候选对象也更少。软件包在小步更新方面也略胜一筹，因为通常当程序员更新时，他们会考虑从上一个版本过渡到下一个版本，他们是否会关注上一个版本以外的内容可能会有所不同，但这往往对快速发展的软件最为重要。
并非所有更新都是无中断的。您需要注意这一点。有些更新会重新启动服务，从而导致停机。
在理想的设置中，您可能具有以下内容：
- 一种无缝切换服务器的方法（A/B 或 tick tock）。这意味着您在一台服务器还在运行的时候对其进行更新，然后只需将流量从当前服务器切换到新服务器即可。对于数据库等服务，这可能更为复杂。
- 测试更新的能力。您应该拥有实际上是生产环境的克隆的测试服务器（但不连接到任何生产服务）。这些服务器将允许您首先测试更新。
- 增量备份是一种理想的良好备份策略。你永远不知道会发生什么。谨慎总是比后悔好。
- 要知道哪些时间活动最多，以及什么程度的停机是可以容忍的。
- 了解如何回滚更新或特定包。
- 拥有自己的软件包镜像，这样更新在各个服务器上都是一致且可预测的。这是迈向值得信赖的无人值守系统的第一步。这意味着您可以更新镜像，在一台或多台测试机器上运行更新，然后如果一切顺利，就可以自动发布。我非常享受管理大约 800 台 EPOS 机器的乐趣。
- 良好的一致性，以便您可以知道如果某件事在这里有效，那么它在那里也会有效。
对于小型设置来说，其中一些可能会不同程度地过度，但应该牢记在心。
一般来说，服务器发行版的更新通常相对轻松。这是因为它们几乎总是只进行错误修复和安全更新。但是，如果有人对系统做了奇怪的事情或您添加了额外的软件包源，您可能会遇到问题。
尽管这种情况比较罕见，但它们偶尔也会犯错误并破坏小版本软件包之间的兼容性。