本文件已封存並已停止維護。

識別 Operations Manager 2007 的需求

更新日期: 2009年5月

適用於: Operations Manager 2007 R2, Operations Manager 2007 SP1

識別公司的需求是 Operations Manager 設計程序的下一個步驟。需求可分成三類:商業需求、IT 需求與最佳化需求或目標。需求收集步驟是規劃 Operations Manager 2007 設計最重要的一個步驟。藉由充分瞭解需求,您就可以建立滿足這些期望的解決方案。如果專案交付項目不如預期,專案就可能失敗。

為確定您真正瞭解需求,您必須與幾組不同的人員談過。一開始,您必須瞭解關鍵專案關係人和贊助者的預期為何。如果他們期望 Operations Manager 能夠做到實際上無法達成的任務,這時就是教育他們和訂立適當目標的好機會。您還必須與即將使用 Operations Manager 資料的各組人員進行討論。這表示不只需要與技術服務人員和應用程式系統管理團隊討論,還包括他們的管理階層,也就是可能使用 Operations Manager 報表以及希望一目了然地知道應用程式狀態的人員。

在完成需求收集後,請彙整資料,然後公佈給所有相關人員參考。這可提供另一次機會來釐清所需功能。為進一步確保對需求達成共識,您可選擇要求專案贊助者和關鍵專案關係人在上面簽核。

商業需求

您要面對的企業主不僅僅是資助 Operations Manager 專案的高階主管,他們同時也是經理和主管,負責公司營收之所繫的業務流程。他們可能不會對 Operations Manager 這項產品特別有興趣,但迫切希望知道 IT 能夠提供哪種服務等級來支援任務關鍵性應用程式。

當您與這些角色的人員進行討論時,他們可能會著重於以下四個方面:

  • IT 持續提供服務

  • 其應用程式的效能資訊

  • 法規遵循

  • IT 成本報酬率

IT 持續提供服務

企業主對 IT 的要求主要是確保應用程式能夠啟動並執行。如果沒有,他們必須馬上知道。他們想要知道這種中斷情形對其業務流程的影響,以及預期中斷的時間。瞭解他們的業務流程是滿足其需求的關鍵。在與他們的對話當中,請確定您瞭解以下幾點:

  • 他們使用哪些應用程式來執行影響核心業務的操作?瞭解這點可找出必須提供端對端服務監視的應用程式。

  • 這些應用程式的元件為何?瞭解這點有助於建立將監視的分散式應用程式模型。

  • 應用程式是否有關鍵元件在工作站或其他用戶端上執行?瞭解這點有助於規劃用戶端監視策略。

  • 請他們描述其應用程式中的完整交易。Operations Manager 2007 可使用綜合交易定期測試應用程式,並可提供使用者使用應用程式的監視資料。

效能資訊

當您在討論企業主需要知道哪些應用程式效能資訊時,將業務流程效能和應用程式效能區分開來是非常重要的。業務流程效能 (或計量) 是由商業智慧應用程式提供,通常以報表和平衡計分卡的形式提供,這不屬於討論範圍。這時所必須瞭解的期望是與應用程式效能相關的期望。請確定您瞭解並討論到以下重點:

  • 他們目前收到哪些應用程式效能資訊?他們希望收到哪些資訊?瞭解這點有助於角色規劃 (設定檔和領域)。

  • 他們目前透過什麼方式接收應用程式效能資訊?他們希望透過什麼方式接收資訊?瞭解這點有助於您決定提供效能資訊存取的方式。例如,他們是否需要 Operations 主控台以及限於其應用程式的唯讀操作員和報表存取權,或 Web 主控台即已足夠?

法規遵循

對於業務流程擁有者來說,法規遵循不論是現在或未來都是一項重要議題。業務流程擁有者希望 IT 能夠參與公司的計畫,以達成法規遵循的目標並維持不懈。請務必涵蓋下列重點:

  • 業務流程是否受到法規管制?若是,法規內容為何?瞭解這點有助於稽核收集服務 (ACS) 規劃和角色規劃。

  • 業務流程擁有者希望 IT 提供哪種資料以及時段為何?這將有助於報表規劃和資料保留規劃。

IT 成本報酬率

不論是直接分攤費用或間接經常性費用,企業主都須支付 IT 服務的成本,而一個經營有方的企業主,會想知道這樣的投資有何報酬。您可以使用 Operations Manager 報表來回答這些問題,但必須知道企業主尋求的價值為何。請務必涵蓋下列重點:

  • 他們認為 IT 提供最有價值的服務為何?瞭解這點有助於報表規劃。

  • 他們是否知道目前 IT 成本的報酬為何?瞭解這點後,您可以選擇組合不同的報表,顯示從應用程式外部提供給企業主的服務。

IT 需求

IT 需求將主導 Operations Manager 拓撲及其支援的基礎結構。構成 IT 需求的兩大因素是最佳化目標和即將導入 Operations Manager 的 IT 環境。您將從 IT 贊助者、關鍵專案關係人以及 Operations Manager 資料使用者收集這些需求。討論時應由您這邊提出各式各樣的開放性問題。請先詢問 Operations Manager 將如何應用於環境以及該實作應最佳化的部分。請務必涵蓋下列重點。

最佳化目標

最佳化目標是 Operations Manager 實作在設計上必須達到的目標。這些目標可陳述如下:

  • 可用性/恢復能力--Operations Manager 必須在最短時間內恢復運作。瞭解這點有助於高可用性以及備份/復原規劃。

  • 成本--Operations Manager 必須以最經濟的方式實作。瞭解這點並在預算限制範圍內實作,是左右專案成敗的關鍵。

  • 效能--例如,Operations Manager 必須在不到 1 分鐘的時間內提供來自於環境的資料,而且在啟動主控台後,必須能夠在 10 秒內存取主控台。瞭解這點有助於硬體規劃。

  • 領域--Operations Manager 必須提供整個環境的單一檢視。瞭解這點有助於規劃所需的管理群組數目,以及這些管理群組之間的關係。

  • 系統管理--Operations Manager 系統管理功能必須限於 (或提供給) 特定群組。瞭解這點有助於規劃安全性群組、角色、存取權限,以及將實作的管理群組數目。

  • 存取點的位置--Operations Manager 資料只能從公司的內部網路存取,或必須在內部和外部都能存取。瞭解這點有助於規劃提供 Operations 主控台和 Web 主控台的位置。

  • 整合--Operations Manager 必須與現有的報修系統或其他企業監視產品整合。瞭解這點有助於規劃 Operations Manager 及其功能整合到環境的哪個部分,以及其所扮演的角色。這也有助於決定是否需要協力廠商連接器或自行開發的連接器。

清查目前環境

確實清查目前環境可提供兩方面的助益。首先,這能告訴您 Operations Manager 將監視的項目,其次,您還可以知道其運作的限制或界限。請務必涵蓋下列重點:

  • 規模--將受監視的裝置估計數目

  • 需要的管理組件--將受監視的應用程式。

  • 支援應用程式的裝置類型—這包括 Windows 電腦、網路裝置以及安裝 UNIX 或 Linux 的電腦。

  • 拓撲--將受監視之裝置的實體和網路位置。

  • 拓撲和主控台分配--Operations Manager 資料使用者的實體和網路位置。

  • 憑證和閘道伺服器需求--環境的 Active Directory 信任界限。

  • 目前的管理和技術服務產品--所有其他用來執行監視、警示和報表的產品。

  • 拓撲與閘道規劃--定義網路界限的防火牆和廣域網路 (WAN) 連結。

  • 拓撲與角色規劃--受監視裝置與應用程式的 IT 系統管理界限。

  • 拓撲與當地語系化--環境跨越的語言和地理界限。

清查現有程序

所有環境都必須以某種方式進行監視和管理。用來達成上述目的之技術的複雜度和成熟度各不相同。按照基礎結構最佳化模型,所有環境可分為四類:基本型、標準化、合理化以及動態。請參閱基礎架構最佳化技術中心,以取得這四類環境的更多資訊和自我評估工具,並瞭解您的程序和環境可歸類成哪一種環境。

為了規劃 Operations Manager 2007 功能的使用方式,您必須瞭解目前用來監視和管理環境的程序。這將有助於規劃回應警示資訊的方式和負責回應的人員。您可以規劃送出通知的方式和接收這些通知的人員,以及規劃管理群組和資料安全性的系統管理控制。

以下是在這個階段需要提出的主要問題:

  • 我的組織目前如何進行監視?

  • 我的組織對於監視處理序/系統提供的資訊採取什麼樣的措施?

另外也請務必涵蓋下列重點:

  • 針對自動化系統或技術服務人員所提出的問題或警示,一般由誰回應?瞭解這點有助於決定誰需要直接存取 Operations 主控台,以及主控台應包含哪些資料。

  • 技術服務人員通常就能解決問題,還是需要將問題轉交伺服器支援小組處理?

  • 公司是否設有專人負責的網路營運中心或其他專人負責的監視系統?如果是,持續使用的人數和主控台數目是多少?這有助於決定設置管理群組的位置,以便能夠獲得充分的支援。

  • 除了資料中心外,還有多少位置將部署代理程式,及其位於網路上何處?

  • 受管理裝置所在站台與管理伺服器所在站台之間,可用頻寬的統計資料為何?

  • 目前如何進行安全性登入?

  • 桌面或用戶端應用程式目前是否受到監視?

  • 如何監視安裝 UNIX 或安裝 Linux 的電腦和網路裝置?

 
顯示: