自从现在开始工作以来，我一直在和老板和同事进行无休止的更新系统的斗争。
我当然完全同意，任何更新（不pipe是固件，操作系统还是应用程序）一出现就不应该不小心应用，但我也坚信，如果供应商发布它，至less应该有一些理由。 而最常见的原因通常是修复一些错误，这可能是你目前没有遇到的，但是如果你不跟上，你可能会遇到很快的错误。
安全修复尤其如此; 作为一个例子，有人只是简单地使用了已经有好几个月的补丁，臭名昭着的SQL Slammer蠕虫本来就是无害的。
我都是在部署之前testing和评估更新的。 但是我强烈反对系统pipe理的“如果没有破坏然后不去碰它”的方法，并且当我find生产Windows 2003 SP1或者ESX 3.5 Update 2系统的时候真的很伤我，唯一的答案就是“这是工作，我们不想打破它”。
你怎么看待这件事？
你的政策是什么？
如果你的公司政策不符合你的要求，那么你的公司政策是什么？
固件更新（BIOS，存储等）如何？
主要的操作系统更新（服务包）呢？
小操作系统更新呢？
那么应用程序更新呢？
我的主要兴趣当然是更新服务器，因为客户端补丁pipe理通常更直接，并且有众所周知的工具和最佳实践来处理它。
在确定修补策略时，安全性和敏捷性应与稳定性和正常运行时间相平衡。 你的推回方式应该是'好的，但是你需要知道我们现在面临着这些服务器被攻破，数据被盗，或者服务器无法正常工作的风险' “好吧，但是您需要知道这会影响我们的供应商对这个系统的支持，以及未来这个系统与新系统交互的能力。
针对长期“不破，不更新”的思路，你应该明确：
希望这给了你一些杠杆和好运的说服上述事情认真对待。 一如既往，build立一个certificate你已经知道pipe理风险的论文。
这是一场无休止的辩论，合理的人会不同意。 如果你在谈论用户电脑，我同意他们需要更新。 如果您正在讨论服务器，请考虑针对面向互联网的服务器的一个单独的策略，以及那些不支持的服务器。 我不知道你的服务器，但在我的环境中，也许有10％的服务器端口可以上网。 这些面向互联网的服务器在安全补丁方面获得最高优先级。 不面向互联网的服务器优先级较低。
安全专家会争辩说，这种方法是有问题的，因为如果一个黑客进入你的networking，未修补的服务器将允许利用漏洞通过networking像野火一样，这是一个合理的论点。 不过，如果你把那些面向互联网的服务器locking在紧张的状态，并且正确地configuration你的防火墙来打开那些绝对需要的端口，我认为这种方法很有效，而且经常可以用来安抚那些害怕补丁的pipe理员。
如果你只是依靠Windows Update来获得补丁（你没有提到你正在运行的是哪个操作系统，但我主要是一个Windows用户，所以这是我的参考），看看每个月发布的实际修补程序。 我有一些服务器，如果我在他们上运行Windows Update，我会被告知我需要50+补丁，但如果我滚动这些补丁，并研究每个补丁，我会发现90％的补丁项目是不安全的相关，但修复影响服务的错误，我不在该框上运行。 在使用补丁pipe理系统的大型环境中，审查所有已发布的内容是很常见的，而且只会影响到绝对必要的内容，这通常相当于微软发布的10％。
我的观点是，这场关于“打补丁还是不打补丁”的辩论表明，如果真的是一个巨大的灰色地带，你必须是一方或另一方。
我只能谈论服务器，但是我们有一个“季度更新”机制，在每年四个预先确定的和公布的date，我们将更新请求串起来，将它们应用到我们的参考环境，运行一个月来testing稳定性，在接下来的n天/周。 除此之外，我们还应用了一个紧急更新策略，在这个策略中，我们可以在一两天内部署参考，testing和推出紧急更新，如果严重程度是这样的话 – 虽然这只是最后一次使用的2/3 4年左右。
这种双向的方法可以确保我们的服务器是合理的，但不是愚蠢的，最新的，更新是由主题专家（即固件，驱动程序，操作系统，应用程序人员）而不是供应商驱动，但它也允许快速修复，如果需要。 当然，我们很幸运，在整个业务（<10个服务器variables）以及相当大的，最新的参考平台上testing的硬件模型很less。
我曾在不同的公司工作过，这些公司的策略贯穿始终，“尽快应用补丁，我们不在乎是否破坏了我们正在工作的一些东西 – 我们会把它们退出”，直到“没有两周的时间的testing“。 只要公司明白权衡，两个极端（和两者之间的点）都可以。
这个问题很重要：这个问题没有对错的答案。 这是在特定环境中平衡稳定性与安全性或function之间的平衡问题 。 如果您的pipe理链理解延迟testing补丁可能会使他们更容易受到恶意软件，那很好。 同样，如果他们明白在补丁可用的时候立即应用补丁程序可能无法正常工作，甚至会破坏您的特定系统configuration，这也是很好的做法。 当这些折衷不被理解时，存在问题。
我的观点是，最好的方法是在你的两个极端的中间。 例如，如果没有明显的理由，为什么你非常想升级ESX，可能会破坏工作系统？ 如果它是面向公众的，肯定可能是脆弱的，但不应该从networking外部直接访问它，那么风险在哪里？ 是否有任何错误或缺乏function，实际上是给你一个升级的理由 ？
为了它而升级，这就是你提出的（“但你可能很快就会遇到”），即使声称你不是，也是一个荒谬而危险的旅行之路。 除非你能提出一个实际的理由，而不是一些理论上可能的原因，否则如果他们反对升级，你永远不会说服别人。
如果你认为有一个真正的理由来进行升级，你应该logging优点和缺点，总是有缺点，并提交给树上的那些。 正确logging应该有一点阻力。 如果你不能提供一个令人信服的论据，那么请坐下来认真思考这个事实。
编辑
我想我应该清楚地说明，与执行软件或操作系统升级相比，我发现在应用所需的安全性和稳定性修补程序方面存在巨大差异。 我经过适当的testing后才开始实施。 后者我只有在有真正的好处时才做。
安全更新被发送到临时服务器，然后在显示他们没有吹起来之后进行生产。 除非有一个真正的噩梦 （我已经打了几次:(），在这种情况下，立即生产。其他更新只在需要时，花费时间在舞台上。
我认为首先要做的是按严重程度对更新进行“分类”，并根据分类情况制定补丁计划。 毫无疑问，零日安全修复程序必须马上应用; 而Service Pack可以在仔细评估后等待。