最近，我和一位客户偶然聊到一个有趣的 Service Pack 问题。IT 团队决定将 SP2 应用到其 SQL Server 生产服务器上。他们尽职尽责地工作：先将 Service Pack 应用到测试环境中的服务器上，以确保使用 SQL Server 的应用程序不会中断。测试结果似乎非常理想。于是，他们通知了组织中的每一个人，并计划好将此修补程序应用到服务器的时间。
一切进行得都非常顺利。然后，他们继续在测试阶段将修补程序分发给服务器，最后再在开发阶段真正实施。部署过程也完全符合标准。直到一位开发人员尝试打开他的 Reporting Services 项目时，才突然出现许多奇怪的小问题。报告虽然打开了，但部分报告不能使用。另一位开发人员打开 Analysis Services 数据库时一切正常，直到他尝试打开“计算成员”选项卡时，才发现肯定是某些内容出现了问题。
您也许已经猜到了问题所在，服务器已经接收到了 Service Pack，但是开发人员并没有接收到。由于安装在桌面上的 SQL Server 客户端工具被视为桌面部署的一部分，而不是服务器部署的一部分，因此这些工具不在升级范围之内。此外，要将 Service Pack 分发给开发人员，还需要再对分发进行一次测试和设置。（我们甚至不会提到一个事实，即并非所有开发人员都是循规蹈矩的 — 也就是说，一些开发人员早已将策略没有明确规定的 Service Pack 应用到自己的桌面了。该部分完全可以再写一篇文章了）。
虽然现在已经开始采取措施解决这种杂乱现象，但是对该公司使用的一些分析型应用程序的维护却慢慢停顿下来。这种情况更加说明 Service Pack 策略的不一致性及不明确性，同时也透露出部门与部门之间沟通的弊端。分发 Service Pack 使生态环境更加安全，因此是非常重要的一个环节。
一些组织反对应用 Service Pack，担心 Service Pack 虽然能够帮助解决漏洞，但分发此软件会产生更多的冲突与困扰，会得不偿失。其他组织根本就没有策略，允许单个用户和系统管理员随意应用或忽略修补程序。这样就增加了维护任务本身的难度，因为修补程序不一定出现在每一个服务器上。一些服务器受到全面的保护，而其他服务器却仍然保持安装时的状态。
大多数较大型和/或较复杂的 IT 组织都了解基础结构优化模型，因此也都意识到自身应该积极建立策略和实现程序，以防止这种情况发生。他们也知道可以把许多问题自动化，以避免出现这种窘况。但是，最重要的是大家需要了解自己所做的哪些事情将影响其他人员和其他部门，然后就是彼此沟通。
考虑 Service Pack 影响自己范围的方式、思考与自己系统有关的部分事项以及了解自己使用的内容比较容易；但是要越过个人领域，考虑外在更改所产生的影响，就比较困难了。有时候，我们在应用 Service Pack 的时候，不免就会成为井底之蛙了。
幸好，这个问题已经轻松解决。原因是该公司的模型相当成熟，确定问题（重复一下，只有遵守规则的开发人员才会遇到这个问题，所以这在某种程度上有点令人费解）后，就会立刻自动分发修补程序。顺畅的沟通再加上设计良好的系统，使问题可以在停机或中断时间最短的情况下得到解决。
看来问题的答案就是使我们的基础结构以及我们自身成熟起来。一个有效的 Service Pack 策略可以同时解决程序、产品以及人员方面的问题。
原文地址
本文来源：微软TechNet中文站