我时不时地登录到生产网站/数据库/工具箱并看到典型的消息：
30 个软件包可以更新。16 个更新是安全更新。
我的问题是，你们如何处理生产 Ubuntu 机器上的更新？你们是否自动执行这些更新？你们是否为它们设置了停机时间？问题是，你永远不知道更新何时会破坏某些东西，例如现有的配置文件等。
这个问题的另一部分是，及时更新补丁是“一件好事”，但补丁几乎每天都会发布。如果每天都有新的安全补丁可用，那么需要进行多少次计划停机？
我认为有关如何管理更新的答案的帖子将非常有用。
答案1
与 Windows、RHEL、CentOS、SuSE、debian 等相比，修补 Ubuntu 没有什么特别之处。
在设计补丁程序时，你需要保持的基本心态是假设一些事情将要休息。
在设计补丁设置时我倾向于使用的一些基本准则是：
- 始终使用本地系统将补丁集中到您的网络内部，从那里安装补丁
这可能包括使用 WSUS 或<your_os_here>内部补丁管理机器的镜像。最好是能够集中查询并让您了解安装在您个人机器上的补丁的状态的机器。
- 如果可能的话，在机器上预先进行安装。
如果可能的话，当补丁发布时，让中央服务器将它们复制到各个机器上。这实际上只是为了节省时间，这样您就不必等待它们下载并安装，您只需在补丁窗口期间启动安装即可。
- 找一个停机窗口来安装补丁，你可能不得不重新启动，而且可能会出现问题。确保这些系统的利益相关者知道正在部署补丁。为“这”不起作用的电话做好准备。
根据我的基本理论，补丁会破坏事物，请确保您有一个停机窗口，以便应用足够长的时间来排除关键问题，并可能回滚补丁。您不一定需要有人坐在那里测试补丁。就我个人而言，我非常依赖我的监控系统，它让我知道一切都在我们可以承受的最低水平上运行。但也要准备好在人们开始工作时打电话来处理一些小问题。你应该总是安排一个人随时准备接电话——最好不是那个熬夜到凌晨 3 点修补机器的人。
- 尽可能实现自动化
就像 IT 行业中的其他一切一样，编写脚本、编写脚本，然后再编写脚本。编写软件包下载、安装开始、镜像的脚本。基本上，你想把补丁窗口变成一个临时看护任务，只要有人在场以防万一出现问题就行。
- 每个月有多个窗口
这样，如果出于某种原因无法在“指定夜晚”修补某些服务器，您可以不修补这些服务器。如果您无法在第一天夜晚修补它们，则要求它们在第二天夜晚可用。还可以让您保持同时修补的服务器数量合理。
最重要的是继续更新补丁！如果不这样做，你会发现自己必须花费 10 多个小时来打补丁，才能回到你遇到的问题。这会引入更多可能出错的点，并使查找导致问题的补丁变得更加困难。
这个问题的另一部分是，及时更新补丁是“一件好事”，但补丁几乎每天都会发布。如果每天都有新的安全补丁可用，那么需要进行多少次计划停机？
每月或每隔一个月修补一次服务器 - 在我看来 - 是一个非常可实现且可接受的目标。除此之外，您还将不断修补服务器，更不用说您开始陷入需要为每个服务器应用数百个补丁的情况。
至于您每月需要多少个窗口？这取决于您的环境。您有多少台服务器？您的服务器需要多长时间正常运行？
9x5 的小型环境可能每月只需要一个补丁窗口。大型 24x7 商店可能需要两个。非常大的 24x7x365 商店可能需要每周滚动一个窗口，以便每周修补一组不同的服务器。
找到适合您和您的环境的频率。
需要记住的是，100% 更新是不可能的要达到的目标 - 不要让安全部门告诉你其他的。尽你所能，不要落后太多。
答案2
要做的事情：
- 进行备份
- 确保它是一个可恢复的备份（尽管这两点都是一般要点）
- 升级时请尝试将流量引导出生产箱。
- 尝试采用带外访问方法，以防万一出现问题，KVM、串行控制台、本地访问或远程操作。
- 在一台服务器上进行测试，然后确保一切正常，然后再将更新部署到更多服务器上
- 如果可以的话，使用 puppet 来确保多个服务器上的版本号相同。（您也可以使用它来强制升级）
- 在测试服务器上，将配置文件的版本与新版本（已安装的更新版本）进行比较，并确保不会出现任何严重问题。我似乎记得 dpkg 在安装与当前安装的版本不同的新版本之前会进行询问。
需要避免的事情：
- 在中午、周一早上 9:00 或周五下午 5 点进行更新！（感谢@3influence！）
- 在非常大的数据库服务器上升级 MySQL（重启可能需要很长时间）
- 同时处理所有服务器（尤其是内核）
- 执行任何可能改变 /etc/networks 的操作（因为您可能会失去连接）
- 自动更新可以完成上述操作，无需您亲自检查一切是否正常。
答案3
另一点值得一提的是：如果你习惯使用 Windows，你会惊讶地发现大多数 Linux 更新不是需要停机或重启。有些更新确实需要，例如内核更新。但需要重启或停机的更新通常会被标记为需要重启或停机，并且可以按照单独的时间表进行处理。
答案4
对于 Ubuntu LTS 系统，我们按以下方式处理更新：
- 维护一套验收测试，检查软件中的所有关键路径
- 每天早上 4 点无人值守地安装安全升级，并立即运行验收测试。如果出现任何问题，工程师都会收到通知，并有足够的时间修复问题或在 9 点之前回滚。这种情况在五年内只发生过两次 - LTS 经过了充分测试并且很稳定。
- 我们每周都会使用蓝/绿部署自动重新部署整个基础设施（在 digitalocean 上），这样可以让所有软件包保持最新版本。如果新部署未通过验收测试，则部署将暂停，直到工程师可以调试问题。
对于我们来说，下一个合乎逻辑的步骤是消除内存会话信息，这样我们就可以简单地每天重新部署基础设施，甚至每天多次，而不会影响客户，并消除步骤（2）。
这种方法维护成本低，完全避免了维护窗口。