最近，我和一位客戶偶然聊到一個有趣的 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 策略可以同時解決程序、產品以及人員方面的問題。