領域備註 準備好您的修補策略

Mark D. Scott

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

Mark D. Scott 是 Microsoft 諮詢服務的資深顧問。 他與客戶密切合作，説明設計和構建大規模的以資料為中心的應用程式。 您可以通過 granddaddy2002@msn.com或 mascott@microsoft.com與他聯繫。