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