我订阅了 CentOS-announce 邮件列表，也读过各种严重性标签的定义，如“严重”、“重要”、“中等”、“低”、“BugFix”等等，但我仍然不清楚哪些问题真正需要解决，哪些问题可以等待（因为我需要证明中断我们的正常工作以发布更新是合理的）。
到目前为止，我一直试图尽快将关键更新应用到我们的生产环境中。
应用这些更新的正常时间表是什么？它们发生的频率非常高，显然我们无法快速应用所有更新，因为它们需要进行测试以确保它们不会破坏我们的系统。
就上下文而言，我们主要运营一个网站，系统上没有额外的用户，所以我通常不担心“本地漏洞”，而是担心远程漏洞。但我觉得我仍然不知道如何最好地应用这些更新。
谢谢，
答案1
我为不同的客户管理许多不同的网站，这就是我的工作。
首先，安全更新的首要任务应该是Web 应用程序本身。绝大多数攻击将针对您的网站及其运行代码，因此需要确保其安全。如果您使用现成的 Web 应用程序，那么我甚至会考虑这一点自动的更新，但在任何情况下，我都不会让 WordPress 或 Drupal 之类的安全更新停留超过 24 小时，然后再进行测试并很可能将其推出。
如果您的 Web 应用是定制的，请确保您的开发人员尽可能关注安全问题。在这种情况下，您的组织应该实施 DevOps，以确保 Web 开发人员和 IT 部门能够良好合作，并及时解决问题。
之后，我考虑的下一个关键更新是那些“广为流传”的更新，以及您在国家新闻中听到的更新，例如 Heartbleed、POODLE 等，以及关键路径中的任何更新，例如 Drupal 和 WordPress 网站的 nginx 和 PHP。我会在更新可用时立即应用它们。我也会加入邮件列表对于上游软件包（例如，我订阅了 openssl-announce）以便我尽快收到真正重要的事情的通知。
接下来，我每月一次将更新应用到每台面向公众的服务器（Web 前端、负载平衡器等）和每台支持服务器（数据库等）。这包括任何剩余的安全和错误修复更新。在许多组织中，这是每季度进行的，但我认为公共网站，尤其是从事电子商务的网站，不应该被搁置那么久。我几乎总是在微软补丁星期二之后的周末这样做，这段时间几乎总是有足够的时间来了解微软的糟糕更新（尽管我主要运行 Linux 系统，但有一个周末更新所有内容更容易）。
最后，我坐下来，放松，等待看看会出现什么问题。尽管你尽了最大的努力测试更新，但最终还是会出现问题。观察你的监控系统。如果出现未受监控的故障，请修复它，然后开始监控它。做好回滚的准备（yum history undo这很有帮助）。
答案2
在很大程度上这取决于。
显而易见的是，关键安全更新通常最好安装尽快地，但只有您知道您的基础架构和平台。 ASAP 的具体含义取决于您。如果您正在运行 Web 服务器，则最近会出现以下情况：
对你来说不是问题。不必着急。如果你正在运行 500 个 CentOS 工作站，那么该勘误表可能确实至关重要，你会在没有任何测试或仅进行最低限度测试的情况下推出此类更新。
这样的决定应该是影响/风险评估的结果，可能在你的安全官员的帮助下。
另一方面，对你来说，风险可能会减轻，因为所有工作站都被迫使用已经阻止此类恶意内容的 Web 代理，而这些工作站的 500 名高薪用户第二天早上无法正常工作也可能是一个不可接受的风险。那么尽快意味着经过仔细测试。
相比之下，错误修复通常并不重要并且可以等待，除非您的环境正受到这些错误的困扰，否则您可能希望尽快解决该问题。
Red Hat 的 Satellite 服务器或 Spacewalk 项目使这一点变得更容易，对于每个注册系统，你可以看到哪些勘误表和更新适用，反之亦然，对于每个勘误表，你可以看到有多少系统受到影响。这比只列出有待处理的可能更新的软件包要好得多
我曾经工作过的一些组织拥有非常简单的应用程序，允许自动修补服务器。“我们信任 Red Hat”。
其他组织有两个内部版本，所有勘误表都会累积起来，只有非常具体的、可远程利用的关键更新才会在该计划之外推出。还有一两个被认为对我们的设置至关重要的更新。在非生产环境中，在工作日开始之前推送更新，在早上进行强制性测试，在生产环境中，在发布更新后不超过 24 小时。