應用性能管理（Application Performance Management，簡稱APM）最初是一種控制大型機性能的方法，它的應用貫穿整個系統開發生命周期（Systems Development Life Cycle，簡稱SDLC）。現在，由于最終用戶的業務處理是靠越來越復雜的應用進行的，因此應用性能管理變得越來越重要了。應用性能管理從大型機環境進入基于Web的分布式環境以后，已經具備了實現端到端管理所必需的環境條件。因此可以全力關注哪些問題影響了企業應用的性能和可用性，關注如何識別這些問題、如何確定它們的重要性以及如何解決這些問題。

我們介紹過應用性能管理從根本上可以看作是一套基礎設施監測工具。因為清楚各項事務處理任務通過系統時所走路線的狀況，才能實現有價值的監測，所以集中精力監測對應用起支持作用的基礎設施組件的狀態很重要。同樣的，只有了解了最終用戶的體驗，才能知道應用是否發揮了應有的作用，因此我們需要了解應用為用戶提供的服務好不好。最后，只有將最終用戶體驗與基礎設施監測聯系起來，做出的診斷才有意義，因此，當用戶體驗不好時，我們無疑需要到基礎設施中尋找根本原因。

我們將探討在數據中心運行中，應用性能管理怎樣左右那些在大型機上使用的、一般而言更加結構化的工具和流程，以及應用性能管理如何受到這些工具和流程的左右。數據中心會牽涉到大型機、分布式系統和Web系統的集成。

資源性能管理

幾乎每一個運行z/OS（大型機）系統的公司都實施了某種級別的性能管理，這些公司可選擇的系統和資源監測工具有很多。一般而言，這些工具基于SMF數據進行監測、提供報警信號和實現自動化，以此實施系統資源管理。另外，各公司還可能用更加專門化的工具來監測和協調DB2、CICS、Websphere MQ、VSAM等環境。我們接下來馬上探討一套“組件”或平臺工具，對一個整體但卻很復雜的系統進行監測。

一般而言，這些工具能夠很好地完成高級資源監測任務，并能夠對子系統進行力度更高和更詳細的監測。例如，這些工具能夠就參數調整向DB2或CICS專業人員提供良好的反饋信息，從而在特定環境中發現提高性能的機會。這套在大型機上使用的、相對成熟的工具已經孕育了一種定義完備的資源監測方法。采取主動性能管理方法（有時也稱為MIPS管理）的企業已經獲得了顯著成果，由于無需為支持效率低下的應用而升級CPU，因而大大降低了成本。盡管主要的推動力是通過減少指令數來降低成本和防止成本，但是也有附加好處，如應用執行速度更快和代碼質量的提高。

盡管主要的關注點仍然是，無論在哪里，只要可能，都要減少指令，但是人們也越來越強調最終用戶的感知了`，這是因為技術環境變得更加復雜了（例如：Web、SOA、EDI），企業也需要更好地實現IT與企業目標的一致性。事務處理的響應時間不再與大型機子系統的性能直接相關；也不能僅因為DB2資源可用，就認為使用DB2的應用運行良好。而且，今天的企業為達到目標，與重視成本控制一樣，非常重視最終用戶體驗到的性能。這是大多數大型機性能管理解決方案力不從心的地方，因為這類解決方案主要關注資源監測、資源協調和糾錯。這種局限與我們在分布式環境中所看到的情形相似――一套工具常常無法識別最終用戶察覺到的應用性能問題。

從應用性能管理的角度來看，讓最終用戶體驗也成為進行調整的依據之一，或者進行調整時重視最終用戶體驗，我們就可以擴大這些大型機工具的適用范圍。這從某種程度上翻轉了原來的因果關系。通過管理和調整由最終用戶響應時間衡量的應用性能，我們可以減少被調整應用和事務處理的總體資源需求。不過，以最終用戶為導向的應用性能管理的主要目標不是基于MIPS降低成本，而是實現卓越的用戶體驗。#p#

Apdex：一開始就要明確目標

　　任何項目一開始就確定具體的目標，成功的可能性就會極大地提高，應用性能管理也不例外。就大型機而言，MIPS管理最佳實施常常以定義非常完備的目標開始，如“降低前10個作業步的CPU使用率”，或“降低CICS Region CICSPROD中事務處理的響應時間”。這些降低成本/防止成本的目標是通過減少資源消耗實現的，是最基本的管理，企業在考慮基于最終用戶感知的應用性能管理之前，要先處理這些問題。

　　應用性能管理的目標也許更難以闡明，然而卻同等重要。實際上，人們常常認為應用性能管理目標升級或發生了轉變，因為這些目標隨著時間的推移會變得更宏偉。在實現這些目標的過程中，當然需要衡量所取得的進步，同時還要確保這種衡量對業務是有意義的，例如，可以選擇用Apdex性能指數，它實質上是用從0（不可接受）到1（極好）的標度以數字來表示用戶滿意度。如需更多信息，請登錄：www.apdex.org。

　　因此，就可接受的最終用戶性能而言，一般的業務要求可以轉化成如下的應用性能管理目標：

　　以Apdex指數來計算，最終用戶對在線銀行應用的體驗將在6個月內達到0.85分（在Apdex體系中，代表“良好”），在18個月之后達到0.94分（在Apdex體系中，代表“極好”）的目標。

　　您最好還是確定實現目標的步驟或檢查點，因為我們可以假定，目前的體驗沒到可接受的程度，或者至少是不知道到什么程度，而實現這一目標將需要反復改進服務。

　　從這種比較通用的做法開始，我們可以看到，我們需要衡量最終用戶的體驗，因為這是衡量業務成效的標準，我們是否取得成功將靠這個標準來衡量。我們還需要衡量支持應用的系統組件的性能，以確定在達到峰值使用率時可能出現的資源瓶頸，并調整系統，以提高性能。因此，我們需要了解應用在系統中運行所走過的路線，以及在這條路線上存在的各種相互依賴的關系。根據當前的監測記錄和分析，我們可以了解對這條路線的監測是否全面。我們還要能夠將監測結果與最終用戶的體驗聯系起來，及時說明在這條存在各種依賴關系的路線上，用戶體驗與監測結果的關系。

將應用性能管理作為一個流程來實施和改進

　　接下來，我們考慮面向流程的應用性能管理方法。將六西格瑪DMAIC（定義、衡量、分析、改進和控制）模型作為一種結構化方法，用來實施和改進應用性能管理解決方案，因為在我們向著“極好”的Apdex分數這個最終目標前進的過程中，需要反復改進這個流程的各個組成部分。

　　在我們檢查DMAIC流程時，請記住以下兩個最重要的問題，這對有效的端到端應用性能管理解決方案很重要：

·與業務的一致性 ―― 這是從零開始的、從一開始就考慮業務成果的設計的主要目標。對企業來說，重要的是以性能和可用性來衡量用戶體驗。

·相關性與故障隔離 ―― 將基礎設施監測上升到應用性能監測的關鍵是，能夠透視根本原因和影響，從而真正了解基礎設施衡量標準如何影響最終用戶的響應時間，以及因此了解企業的生產率。

定義

　　首先，將目標轉化為對問題的定義：衡量最終用戶感知，讓應用用戶依據設定的Apdex目標判斷最終用戶的滿意度。這可以通過取樣和推斷完成，利用綜合性或機器人式代理定期執行預定義的、代表典型用戶/應用互動的腳本。如果選擇了這種方法，那么就應該確保對問題的定義，本質上也就是服務級別協議，能夠清楚地解釋這些樣本，使這些樣本成為可以接受的衡量最終用戶體驗的指標。對很多環境來說，用一種“無代理”式數據中心專用設備衡量全部應用用戶的響應時間，可以覆蓋多得多的真實用戶，從而能迅速洞察甚至最深入細致的綜合性方法也可能錯過的問題。理想情況下，兩種方法相結合，可同時獲得綜合性衡量方法的受控性和主動性益處以及對真實用戶進行被動式衡量的好處。

　　通過監測最終用戶感知，可以了解IT對業務目標的支持作用有多大，用戶不滿意是否頻繁出現，以及用戶受挫的程度（如果采用無代理方法）。簡言之，這為確定Apdex分數提供了信息。我們還需要支持組件級性能衡量標準，這既需要了解經過系統的路線，又需要了解一些“正常”行為的基礎定義。我們可能想監測每個服務器的性能狀況、每條網絡連接的狀態以及支持應用的每個流程、程序、區域、數據庫等等的狀況。這需要了解應用在滿足用戶請求時走過的物理和邏輯路線，這條路線也許非常簡單，可以在白板上簡要敘述出來，也可能十分復雜，需要詳細了解應用的互動過程，也許還要借助反映相互依賴關系的實用工具。

　　最后，我們要能夠展示衡量結果與事件之間的相關性。相關性意味著一種實時關系，例如，在用戶體驗到不可接受的延遲時，衡量磁盤隊列深度。相關性還意味著對正常行為的了解，即能夠比較正常磁盤隊列深度與用戶體驗到性能問題時測量到的磁盤隊列深度。根據這種相關性，就有可能設定一個警報，當然，是假定這個測量值在引起性能問題上起了作用。

　　從相關性中還可以確定受影響的用戶數量或類型，或者也許是對業務流程的影響，因此從相關性中還可以獲得一些業務影響產生的環境信息，并因此知道這種業務影響的代價。有關業務環境的信息有助于IT部門恰當地確定，先對哪些問題做出反應，而且業務環境也被看作是業務服務管理（Business Service Management，簡稱BSM）不可或缺的組成部分。

　　在流程斷成熟的過程中，也許會重新定義問題。也許對問題的定義所涉及的范圍變得越來越窄了。例如，可能有一套特定的事務處理程序對支持業務流程至關重要，那么也許會改進原來的定義，以強調這些特定的事務處理程序。

　　也許，會針對特定的事務處理程序調整對可接受的響應時間的定義。另一方面，原來的定義所涉及的范圍也許擴大到包括更新的應用組成部分，或原來未考慮的其他有關應用。

　　請記住，您不可能監測所有任務和所有組件的所有可能監測的細節。如果您試圖這么做，那么您很快就會被太多的數據壓垮，而且很多數據是無關緊要的。從完備定義的目標開始，就有機會獲得可量度的成功、逐步的改進和適當的擴展。始終將業務目標擺在第一位，然后再將業務目標轉化成合適的、對應用起支持作用的技術應該達到的目標。

衡量

　　我們衡量最終用戶的體驗，因為用這個衡量標準，我們能夠建立IT服務器質量與業務目標的聯系。我們還需要衡量基礎設施的一些重要的方面。您也許已經有了特定于平臺的工具，而且這些工具已經完成了一些或大多數衡量最終用戶體驗的任務。您將這些工具組裝到一個應用性能管理解決方案中的時候，也是評估這些工具是否足夠靈活、能夠滿足您的需求的好機會。這些工具監測的衡量標準恰當嗎？門限、時間間隔和警報能恰當地調節嗎？這些工具怎樣報告信息？這些信息能恰當地集成和展現相關性嗎？這些工具為方便診斷提供了合適的深入研究空間嗎？這些工具抓取了適合您的診斷信息嗎？在采用更大型的應用性能管理解決方案的情況下，這些問題是需要各領域專家重新考慮的。

　　幾乎與您監測的東西同樣重要的是，您不監測的東西。很多系統監測工具和特定于子系統的工具提供成百上千種衡量標準，但是要確定性能問題，常常僅需要其中的幾種衡量標準就可以提供足夠的信息。

分析

　　通過回顧可用的應用性能報告，詳細了解一個應用的時間是怎樣用的、用在了哪里，性能分析師可以發現改進的機會。某些（更加普遍的）性能問題會在大型機系統監控器中相當清楚地顯示出來。這些資源限制可以用各種不同的方式來減輕，如工作量管理器（Workload Manager）定義、作業分類、負載均衡和工作調度。其他性能問題不會那么明顯，需要更多的關注以及由專門的性能管理工具建立的詳細數據抓取概要。這類詳細的概要可能看起來很嚇人，尤其對新用戶來說更是這樣。一個能實現抓取自動化、提供根本原因分析、甚至提出糾正的解決方案即使對簡單的環境也是非常寶貴的，而對更加復雜的環境幾乎就是必需的了。

　　這是應用性能管理流程的核心步驟。不僅可以根據這個步驟進行故障域隔離和根本原因分析，而且可以實現持續服務改進（CSI）。相互依存的故障可以用來改進門限設置（以改進應用性能管理解決方案），并作為修改系統設計（以改進IT服務質量）的依據。

改進

　　該領域的專家與一個大的團隊一起確定改進辦法，以糾正錯誤的事情或問題。在這里，流程應該有分支了。對應于ITIL事件管理（Incident Management）的當前業務目標是，盡可能快地糾正問題和恢復服務質量。考慮應用交付基礎設施本身：識別資源瓶頸或應用故障，可提供快速糾正問題所需的信息。同樣的，改進應用性能管理解決方案本身也很重要，因為我們認為應用性能管理是一個重復的流程，可從持續服務改進中受益。應用性能管理工程師應該評估，所監測的是否是恰當的衡量標準，這些衡量標準是否相互建立了恰當的聯系，以提供正確的故障域信息。當然，進行這些評估時應該牢記業務目標――代表“極好”的Apdex分數，也就是說，評估應該直接與衡量最終用戶體驗掛鉤。

　　這并不意味著，應該忽視與最終用戶體驗無關的衡量，這類衡量對支持其他目標也許是重要的，如磁盤使用策略、容量規劃，等等。不過這確實意味著，這些衡量應該依據不同的標準進行。

控制

　　這最后一步是最容易跳過的。不過，如果沒有這一步，我們就會重復事件管理，我們不會成為一個成熟的IT機構，我們也不會實現與業務取得一致的目標。看看識別資源瓶頸和應用故障是怎樣讓該領域專家快速恢復服務的吧，而快速恢復服務是事件管理的主要目標。以避免將來出現問題為目標進行系統調整所需要的規劃信息也由這最后一步提供，而避免將來出現問題是問題管理的主要目標。根本原因也許是資源限制，如Java虛擬機（JVM）可用的存儲器等。在分析那一步確定這個問題，而事件管理也許通過重新啟動Java虛擬機來釋放存儲器。但是除非我們采取一些步驟來防止瓶頸，如消除存儲器泄露的根源或給系統增加存儲器等，問題可能還是會發生。要避免對引起問題的特定限制因素的敏感性，可以改變系統架構、增加資源、改變程序邏輯、改變服務策略等等。

　　類似地，應用性能管理解決方案本身也可以改進。可以考慮調整報警門限和報警規則，以更早地對將來可能出現的問題發出警報，這樣可以在業務受到影響之前采取行動。

　　執狀態顯示板可以快速洞悉關鍵業務（例如，索賠處理）的當前服務質量。IT管理人員能夠實時了解用戶受影響的嚴重程度、人員效率（PHL）以及由性能不佳導致質量不佳而增加的成本。

　　服務運行圖使IT專業人員能夠看到受影響的業務服務和不同的位置。IT專業人員可以從這里開始，繼續深入研究，以找到影響索賠處理的故障域。

　　故障域的即時隔離提醒合適的技術團隊采取糾正措施。這張圖顯示，大型機層是問題的原因。負責大型機的人員可以立即深入研究，以進一步找到并消除根本原因。

　　大型機專業人員可以深入研究，以查看問題的根本原因。例如，這張圖顯示，就索賠處理而言，DB2有個問題，而且列出了哪個DB2流程使用的資源最多（例如，響應時間和CPU時間）。這有助于專業人員迅速了解，SYSSH200流程總的占用時間最長，因此需要檢查這個流程。

　　一旦深入到了SYSSH200流程：Strobe顯示所有SQL語句，因此專業人員可以點擊指示占用時間的標簽，進行歸類，以進一步找出根本原因。更進一步的深入研究可顯示調整建議，以立刻解決問題。#p#

總結

　　現在的數據中心由于支持跨分布式和大型機平臺運行的關鍵業務應用而變得日益復雜和昂貴了。這些應用常常依靠大型機服務，不再能夠作為相互隔離的孤島來有效管理了。盡管組件性能可能影響最終用戶的響應時間，但是在資源利用和響應時間之間，不再存在清晰和直接的關聯了。為了滿足今天以客戶為中心的企業需求，IT部門必須使用與業務部門相同的標準，即用戶滿意度，來管理性能。將已有組件監測解決方案變成真正的應用性能管理解決方案，是實現這種IT與業務一致性的重要步驟，并可通過衡量用戶體驗以及展現應用性能與最終用戶體驗的關系來完成這一步。