要更新还是不更新？

自从我现在工作的地方开始工作以来，在更新系统方面，我一直与我的老板和同事进行不懈的斗争。

我当然完全同意，任何更新（无论是固件，操作系统还是应用程序）一经发布，都不应立即应用，但我也坚信，至少应该有一些理由让供应商发布它；并且最常见的原因通常是修复一些错误...也许您现在还没有遇到过，但是如果您不跟上，可能很快就会遇到。

对于安全修复程序尤其如此。例如，如果有人简单地应用了已经可用了几个月的补丁程序，那臭名昭著的SQL Slammer蠕虫将是无害的。

在部署更新之前，我全心全意地测试和评估更新；但是我非常不同意系统管理中的“如果没有损坏就不要碰它”的方法，当我发现生产Windows 2003 SP1或ESX 3.5 Update 2系统时，这确实伤害了我，我唯一能得到的答案是“它正在起作用，我们不想破坏它”。

你怎么看待这件事？
什么是你的政策是什么？如果不符合您的公司政策，您的公司政策
是什么？

固件更新（BIOS，存储等）如何处理？
主要操作系统更新（Service Pack）如何？
较小的操作系统更新如何？
那么应用程序更新呢？

我的主要兴趣当然是在更新服务器，因为客户端补丁程序管理通常更简单，并且有众所周知的工具和最佳实践来处理它。

确定补丁程序策略时，应在安全性和敏捷性与稳定性和正常运行时间之间取得平衡。您的后推方法应遵循“好的，但您需要知道我们现在面临这些服务器受到威胁并盗取数据或使服务器无法运行的风险”和“好的，但是您需要知道这会影响我们的供应商对该系统的支持，以及将来使该系统与新系统交互的能力”。

针对长期的“不间断，不更新”的心态，您应该明确指出：

• 将未打补丁的遗留系统迁移到现代系统中要比逐步更新该系统要昂贵和痛苦得多。
• 经验丰富且技术熟练的IT人员积极寻找不断发展其IT系统的新技术和公司。当公司由于系统停滞不前而变得不受欢迎时，失去了高度敬业的，富有创造力的IT员工时，营业额，机会损失和知识损失会带来非常现实的美元成本。然后，剩下的就是“生命”。

希望这在说服上述情况时能给您带来一定的影响力和最好的运气。像往常一样，建立书面记录，证明您已对他们所承担的风险进行了管理。

这是一场无休止的辩论，理性的人会不同意。如果您在谈论用户PC，我同意需要对其进行更新。如果您在谈论服务器，请考虑针对面向Internet的服务器和不面向Internet的服务器的单独策略。我不了解您的服务器，但在我的环境中，也许我们的服务器中有10％的端口可以打开互联网。当涉及到安全补丁程序时，这些面向Internet的服务器将获得最高优先级。不面向互联网的服务器的优先级较低。

安全专家认为，这种方法是有问题的，因为如果黑客确实入侵了您的网络，则未打补丁的服务器将允许漏洞利用像野火一样在整个网络中徘徊，这是一个合理的论点。但是，如果您将那些面向Internet的服务器保持锁定状态，并正确配置防火墙以仅打开那些绝对需要的端口，我认为这种方法可以奏效，并且通常可以用来安抚那些害怕补丁的管理人员。

如果您仅依靠Windows Update的补丁程序（您没有提到您正在运行哪个操作系统，但我主要是Windows操作系统的人，所以这是我的参考），请查看每月发布的实际修补程序。 。我有一些服务器，如果我在这些服务器上运行Windows Update，将会被告知我需要50多个补丁，但是如果我滚动浏览这些补丁并研究每个补丁，我会发现90％的补丁都不安全相关但已修复的问题会影响我无法在该设备上运行的服务。在使用补丁程序管理系统的较大环境中，通常会检查发布的所有内容，而只关心绝对必要的内容，通常这占Microsoft发布的内容的10％左右。

我的论点是，关于“修补或不修补”的辩论表明，当您确实是一个巨大的灰色地带时，您必须一方或另一方。

我只能谈论服务器，但是我们有一个“季度更新”机制，在每年的四个预定和宣布的日期，我们汇总更新请求，将其应用到我们的参考环境中，运行一个月以测试稳定性，如果部署良好，在接下来的n天/周内。在此之上，我们应用紧急更新策略，如果严重程度如此，我们可以在一两天内部署参考，测试和推出紧急更新-尽管最近一次仅使用了2/3次4年左右。

这种双重方法可确保我们的服务器保持合理但并非愚蠢的最新状态，更新是由主题专家（例如，固件，驱动程序，操作系统，应用程序人员）而非供应商来驱动的，而且还可以在发生问题时进行快速修复需要。哦，当然，我们很幸运能在整个业务中使用很少的不同硬件模型（服务器变量少于10个），并且可以测试相当大的最新参考平台。

我曾在不同的公司工作过，这些公司从“尽快申请补丁，我们不在乎它们是否破坏了我们正在努力的工作，我们会在之后将其淘汰”到“没有两周就什么都不会应用”的政策测试。” 只要公司了解折衷方案，两个极端（以及两者之间的点）都可以。

这很重要：这个问题没有正确或错误的特定答案；这是在特定环境中平衡稳定性与安全性或功能之间的问题。如果您的管理链了解到延迟测试补丁可能会使它们更容易受到恶意软件的攻击，那就很好。同样，如果他们了解尽快应用补丁可能无法正常工作甚至破坏您的特定系统配置，那也很好。当不了解这些权衡时，就会存在问题。

我的观点是，最好的做法是在您的两个极端之间取得一点成就。例如，如果没有明显的原因，为什么您如此迫切地希望升级ESX，这可能会破坏工作系统？当然，如果它是面向公众的，则它可能会很容易受到攻击，但应该无法从您的网络外部直接访问它，那么这又有什么风险呢？是否有任何错误或功能不足，实际上没有理由向您介绍升级的理由？

出于此目的而进行升级（这实际上是您的建议（“但您可能很快就会经历”），即使声称自己没有这样做，这也是一条荒谬而危险的旅行之路。除非您能提出实际原因，而不是理论上可能的原因，否则您将永远无法说服其他人是否反对升级。

如果您认为确实有理由执行升级，则应记录优点和缺点，并且始终存在缺点，并向更高级别的人员提出。正确记录下来的阻力应该很小。如果您无法提供令人信服的论点，请高枕无忧，再认真考虑一下。

编辑

我想我应该明确指出，与执行软件或操作系统升级相比，应用所需的安全性和稳定性补丁之间存在巨大差异。经过适当的测试，我首先实现了。只有在有真正好处的情况下，我才会这样做。

安全更新被发送到登台服务器，然后证明它们不会破坏一切，然后进行生产。除非有一个真正的哔哔 ING紧急情况（我已经打了几次:(），在这种情况下，现在生产。仅在需要时，在分期花时间后其他更新。

我认为要做的第一件事是按严重性对更新进行“分类”，并根据分类制定补丁计划。毫无疑问，必须立即应用零日安全修复程序；而Service Pack在经过仔细评估后可以等待。