本文討論了在ERP
CRM
電子商務和定制的應用環境中管理可用性
性能和應用服務等級時所面臨的問題
本文的目標讀者是負責應用可用性
性能
服務等級和容量計劃的業務和IT管理人員
文中涉及到下面的IT基礎架構部分
MIS
應用/Web管理和電子商務等
概述 在當今的財富
強公司中
IT部門一直面臨巨大壓力
他們必須提供有可靠價值的技術服務以支持公司業務的發展
公司希望IT部門在現有或更少的人員和資源的情況下能夠向業務用戶提供應有的或更好的應用服務等級
同時企業通過實施IT應用在內部部門
合作伙伴
供應商和電子商務客戶之間持續優化業務過程並提高效率
所有這些將給IT部門帶來更多壓力
此外
這些應用具有復雜的多層的體系結構
運行著多種操作系統和一系列相互依賴的防火牆
服務器
操作系統
進程
Web服務器
J
EE應用服務器
數據庫和一些其它子部件等
然而
用戶並不關心這些管理應用基礎架構的復雜性
用戶主要關心的是系統在一個可預知時間內是否能夠完成一個業務過程
是否能夠更新工資單
查找客戶信息或查找網站並下訂單等
是否能夠成功完成業務過程是應用可用性的起碼要求－要麼能完成要麼不能
性能問題或可用性的不足都可影響生產效率
收入和用戶信心
也許是最重要的
在建立應用服務等級管理時
業務和IT部門應該考慮使用業務過程的性能
使用基於業務過程應用服務等級
業務管理人員可以使IT部門承擔更多的責任
IT部門可以通過比較具體業務過程或業務過程的組合隨時測定服務質量的可用性和變化
應用服務模型將業務過程映射到具體IT資源和應用組件上
基於業務過程的應用服務等級與應用服務模型相結合給業務和IT部門帶來很多好處
本白皮書討論了實現這個模型的挑戰和機制
並提出了下面這些關鍵問題
為什麼對業務過程性能的測量比對傳統的設備或服務器的測量能更精確地反映應用服務的可用性
為什麼要將業務過程映射到具體的IT應用基礎資源
例如Web服務器
J
EE應用服務器和數據庫服務器
業務過程性能:測量應用服務可用性的一個更好方法 用於測量應用服務的傳統方法各有不同
這主要取決於企業文化
業務目標和應用基礎架構的規模等
一些企業使用了商業化的系統監測產品
定制開發的腳本
或兩者組合使用來監測應用中所包含的操作系統進程是否在正常運行
這些產品往往依賴操作系統的工具如ping
vmstat
df
top和perfmon測定進程的可用性
如果組成應用的網絡
操作系統
和操作系統進程運行正常
我們就可以假定應用的運行是正常的
這些觀察方式都是測量應用服務等級性能的間接方法
沒有考慮到在一段可預知的時間內或從不同的地域位置實際執行完成業務過程的能力
直到最近
這些間接方法仍然是用於測量應用服務等級最常用的方法
因為我們還不具備在一段時間范圍內直接並可靠地測量業務過程的能力
現在
技術已經成熟可靠
我們可以通過記錄業務過程並反復回放的方式模擬用戶的業務過程
這些被記錄的業務過程可以被部署到指定的地方並且可以監測到業務過程的可用性和反應時間
業務過程是應用交付的最終產品
代表了應用服務可用性的一種直接測量方法
因此業務過程應該被用來確定應用服務等級
在實現基於Web的業務流程模擬之前
對用於記錄和回放業務過程的產品應該包括下面的一些功能
顯示一個完整的基於Web業務流程的總反應時間
以及具體到每個用戶操作步驟或動作（如登錄
搜索產品
購買產品
注銷）的詳細時間
估計嚴重或致命性能等級的期望反應時間
在用戶每步操作之間以間斷和不間斷兩種方式重新執行整個業務過程
將已記錄的腳本部署到外部的自動化機器上
然後以自動方式反復執行
將已記錄的腳本自動地存儲到一個中央目錄中
統一處理服務器和後端應用的可用性和性能信息
提供一個中央數據庫存儲和使用所產生應用服務報告
將業務過程映射到具體的應用基礎資源 用戶確切想要的是
從任何位置以可預知性能持續不斷地運行業務過程
保證性能的下一個邏輯步驟是把業務過程性能正確地映射到具體的IT層次和組成應用基礎架構的組件
包括性能信息和影響Web
應用和數據庫服務器的事件
將業務過程映射到應用基礎架構這一中心概念是以應用技術棧為基礎的
所有的應用都能分解成如下表所示的組件層次
這些層次是有次序的
從下到上表示從網絡到操作系統
再到應用
集成組件和業務過程的路徑
重要的一點是業務過程與應用棧的每一層次都是有關的
因此必須把它們聯系在一起考慮
才能對性能有全面的理解
表
應用棧
由於業務流程必然要使用棧中的各個層次
所以業務流程層次准確地反映了應用的業務流程可用性
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/19168.html
