Microsoft Exchange Server Analyzer Retrospective

作者: Paul Bowden

在這篇文章中,我會簡單地介紹 Microsoft Exchange Server 解析程式工具系列的背景資料、此技術的發展情形,以及它到目前為止的使用情況。我也將介紹這些工具背後的製作團隊,並討論這些工具未來的方向。

源起

在 Microsoft,我們致力於提供最好的客戶服務和支援,當客戶需要緊急協助來解決中斷使用者服務及影響重要業務的問題時,我們會辨別出狀況為 CritSit (或稱「緊急狀況」)。當 CritSit 起始之後,包括來自 Microsoft 客戶服務和支援、Microsoft 服務、顧問群、帳戶管理和產品開發的 Microsoft 人員的整個團隊會共同合作,以便讓客戶能儘速上軌道,正常運作。

在 2003 年結束時,我們的 Exchange Server 團隊開始注意到三個重要的 Exchange Server CritSit 趨勢:

  • CritSit 變得越來越頻繁。

  • 在所有 Exchange Server CritSit 中,有超過 60% 是由於組態問題造成的,而不是產品本身的錯誤。

  • 在一些新的 CritSit 個案中,其他客戶也遇到幾個月前剛剛發生的相同 CritSit 問題。

看到組態中的簡單變更竟然對電子郵件環境的重要本質造成如此巨大影響,真是令人洩氣,對於客戶之間發生類似的 CritSit,我們也並不樂見。因此我們需要一種工具能夠以程式化的方式分析 Exchange 伺服器,並標示出可能會造成效能、延展性和可用性問題的議題。

在 2004 年 1 月,我寄了一封電子郵件給 Jon Avner,他是 Exchange 團隊的其中一個高階開發人員,信中提到我對這種工具的想法。碰巧 Jon 也在思考類似的工具,所以花了幾天的工夫,我們透過電子郵件研擬出此工具的規格和功能。然後,過了一個週末,Jon 終於推敲出第一版的 Microsoft Exchange Server Best Practices Analyzer Tool,我們比較喜歡稱它為 ExBPA 工具。

當時,我們並未真正瞭解自己所建立的技術有如此重要。Jon 擁有多年的程式開發經驗,在建立一般架構上的真知灼見,讓他所建立的架構幾乎能適應任何狀況,不論是 Exchange 或其它產品。我也花了好幾年的時間在設計大型 Exchange 拓撲及其疑難排解方面,所擁有的背景知識和經驗讓我能夠立即列出該工具應有的重點。

邁向成功

on 的工具在收集許多不同命名空間的資料上很有用:Active Directory 目錄服務、登錄、Microsoft Windows Management Instrumentation (WMI) 和其他等等。當客戶遇到問題時,客戶服務和支援工程師會請系統管理員執行工具,接著支援工程師會檢查該工具所收集到的大量資訊,來診斷客戶問題的主因。

工具已收集到許多有用的資訊,但是我們需要方法來自動剖析和分析這些資訊。因此我們請求 Jack Bennetto 的幫助,他是一位自動化方面的專家,熟諳 XML 路徑語言 (XPath),這是一種用於導覽 XML 文件階層的全面性語言。經過幾週後,Jack 就開發出一個分析引擎,我們將它與 Jon 的收集引擎相結合。有了 Jack 的新引擎,我們就能編寫一系列「規則」來依據給定的閾值產生訊息。如果收集到的值超出容忍的範圍,規則就會「引發」動作。

一切都進行的很順利,於是我們決定對 Microsoft 這裡的內部 Exchange 拓撲執行新工具。但結果並不順利。工具執行花了一天以上的時間。這實在太久了,因為此工具是設計來幫助受到電子郵件停機惡夢所苦的客戶。我們需要一位效能專家,他需要瞭解如何使這個工具有更好的擴充性。接著 Kevin Chase 也加入我們的團隊,他是您在 Microsoft 所遇到的最佳偵錯工程師之一。經過 Kevin 的一番改變,這個全域 Exchange 拓撲的收集時間降為兩小時,個別伺服器的掃描時間更不到五分鐘。

現在這個工具真的運作得很好,但是它的分析功能還是有限。我們需要一組更豐富的規則套用到所收集的資料。很幸運地,資料收集和分析的規則是儲存在 XML 檔,我們可以輕易更新它,而不必重新編譯程式碼。

在幾個客戶端中試過此工具之後,顯然電子郵件問題與 Exchange Server 軟體本身是密切相關的。往往發生電子郵件問題時,都是因為基礎架構 (例如作業系統或名稱解析方式) 未正確運作。因此我們擴大規則範圍來涵蓋這些相依關係。我們必須整體查看整個生態系統,而不只是在 Exchange 和在 Exchange 之下執行的元件,還必須查看在 Exchange 上面執行的應用程式。這是獨立軟體廠商 (ISV) (例如防毒廠商) 一直致力於提供其軟體規則集之處。

而這一切的努力和合作,在 2004 年 9 月初終於有了代價,我們發行了 Exchange Server Best Practices Analyzer Tool v1.0,它是一個免費下載軟體

改變是好事

Exchange Server Best Practices Analyzer 的主要成功因素之一在於我們能夠快速回應客戶需求和產品更新。每週我們都會發現更好的方式來執行 Exchange 系統。編寫到 Exchange Server Best Practices Analyzer 中的最佳作法規則有許多不同的來源:我們自己的開發團隊、Microsoft IT、客戶服務和支援、Microsoft 服務和客戶等。Exchange Server Best Practices Analyzer 的目的是要將這些知識編寫成單一應用程式。現在,這個工具可在它掃描的每一個 Exchange 伺服器上順利執行 1,500 種以上的組態檢查。它會告知伺服器在處理負載方面是否有問題、您的軟體 (不論是 Microsoft 軟體或來自另一個製造商的軟體) 是否過時,以及是否有其他您應該實作的最佳作法。

我們每月都會更新規則資料庫,因此,客戶知道他們會收到有關如何對 Exchange Server 進行最佳部署和執行的最新、最受信賴資訊。截至目前為止,Exchange Server Best Practices Analyzer 下載數已超過 700,000 次。

新解析程式的空間

Exchange Server Best Practices Analyzer 背後的設計原理之一是使用簡單。系統管理員不必太瞭解此工具就可以執行工具。Exchange Server Best Practices Analyzer 會自動偵測 Exchange 伺服器,瞭解那些伺服器的使用情形,並推測安裝的 Exchange Server 和 Windows 是哪個版本。

對 CritSit 個案的後續複查結果顯示,Exchange Server Best Practices Analyzer 的重要影響如下:組態相關問題數目迅速銳減。現在,效能和嚴重損壞修復是客戶主要的問題,但 Exchange Server Best Practices Analyzer 無法用來處理這些問題。一個出色的疑難排解工具要能夠在最短時間內精確指出問題的主因,這需要一個精靈型使用者介面。我們無法使用 Best Practices Analyzer 引擎來執行此工作,因為它只負責啟動、收集、分析和停止,沒有或幾乎沒有使用者的互動。總之,我們需要新的機制來要求使用者輸入,以支援不同的疑難排解工作流程。為協助建立這個新機制,有兩個新成員加入我們的團隊:一位是 Exchange 疑難排解專家 Nicole Allen,一位是 Sustained Engineering 團隊的開發組長 Weiguo Zhang,他們兩位負責製作 Exchange 產品的 Hotfix 和 Service Pack。他們著手建立一個有限狀態機器的實作,此引擎將支援互動式疑難排解工具所需的工作流程和分支邏輯。最後結果是「精靈引擎」,它會與 Best Practices Analyzer 引擎一起操作和整合。

感謝 Nicole、Weiguo 和其他工作人員的辛勞,使我們在 2005 年 11 月推出了 Exchange Server Analyzer Tools 系列的兩個新成員:

  • Microsoft Exchange Server Performance Troubleshooting Analyzer Tool

  • Microsoft Exchange Server Disaster Recovery Analyzer Tool

應用所獲得的經驗

今天,基於這三個解析程式工具的意見回饋,我們對於 Exchange 環境所面臨的一般問題有更多的瞭解。我們的最終目標是要加強 Exchange Server 來對付這些問題,來避免服務受到中斷。我們已開始將此經驗整合到下一版的 Exchange Server 產品,並命名為 Exchange Server "12"。以下是我們正在努力的一些範例:

  • 自動設定合理預設值   目前,有些客戶必須在安裝 Exchange Server 之後儘快調整其伺服器。我們已經知道許多他們所調整的參數。如果產品能夠在您安裝時自動做這些變更,不是很好嗎?

  • 實作覆寫範圍   雖然某些 Exchange 元件仍然需要手動覆寫 (常見於系統登錄中),但使用者不應該隨便輸入莫名其妙的值。產品應該保護自己,即使被覆寫也一樣。

    Dd159859.note(zh-tw,TechNet.10).gif 附註:

    這種狀況比您想像得還要普遍。例如,許多 Microsoft 知識庫文件在於討論如何編輯登錄,並提供以十進位表示的建議值。不過,在登錄編輯器 (RegEdit.exe) 中,預設輸入類型是十六進位。要輸入一個可能解譯錯的值實在太容易了。例如,輸入 31,000 的值將無意中產生實際值 200,704。

未來展望

Exchange Server "12" 會比 Exchange Server 的舊版更健全,這有一部份歸功於此處所描述的工作,但是對 Exchange Server Analyzer Tools 的需求則永遠存在。因此,我們會在 Exchange Server "12" 的包裝中附上這些工具。原始團隊的成員保持不變,還是有 Jon、Jack、Kevin、Nicole 和 Weiguo,而我把大部份時間花在研究和實作新方法上,希望使 Exchange Server 成為市場上最佳的郵件產品。

回到頁首 Paul Bowden Program Manager