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

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

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

資源性能管理

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

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

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

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

Apdex：一開始就要明確目標

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

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

　　因此，就可接受的最終用戶性能而言，一般的業(yè)務(wù)要求可以轉(zhuǎn)化成如下的應(yīng)用性能管理目標：

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

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

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

將應(yīng)用性能管理作為一個流程來實施和改進

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

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

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

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

定義

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

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

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

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

　　在流程斷成熟的過程中，也許會重新定義問題。也許對問題的定義所涉及的范圍變得越來越窄了。例如，可能有一套特定的事務(wù)處理程序?qū)χС謽I(yè)務(wù)流程至關(guān)重要，那么也許會改進原來的定義，以強調(diào)這些特定的事務(wù)處理程序。

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

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

衡量

　　我們衡量最終用戶的體驗，因為用這個衡量標準，我們能夠建立IT服務(wù)器質(zhì)量與業(yè)務(wù)目標的聯(lián)系。我們還需要衡量基礎(chǔ)設(shè)施的一些重要的方面。您也許已經(jīng)有了特定于平臺的工具，而且這些工具已經(jīng)完成了一些或大多數(shù)衡量最終用戶體驗的任務(wù)。您將這些工具組裝到一個應(yīng)用性能管理解決方案中的時候，也是評估這些工具是否足夠靈活、能夠滿足您的需求的好機會。這些工具監(jiān)測的衡量標準恰當(dāng)嗎？門限、時間間隔和警報能恰當(dāng)?shù)卣{(diào)節(jié)嗎？這些工具怎樣報告信息？這些信息能恰當(dāng)?shù)丶珊驼宫F(xiàn)相關(guān)性嗎？這些工具為方便診斷提供了合適的深入研究空間嗎？這些工具抓取了適合您的診斷信息嗎？在采用更大型的應(yīng)用性能管理解決方案的情況下，這些問題是需要各領(lǐng)域?qū)＜抑匦驴紤]的。

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

分析

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

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

改進

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

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

控制

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

　　類似地，應(yīng)用性能管理解決方案本身也可以改進?？梢钥紤]調(diào)整報警門限和報警規(guī)則，以更早地對將來可能出現(xiàn)的問題發(fā)出警報，這樣可以在業(yè)務(wù)受到影響之前采取行動。

　　執(zhí)狀態(tài)顯示板可以快速洞悉關(guān)鍵業(yè)務(wù)（例如，索賠處理）的當(dāng)前服務(wù)質(zhì)量。IT管理人員能夠?qū)崟r了解用戶受影響的嚴重程度、人員效率（PHL）以及由性能不佳導(dǎo)致質(zhì)量不佳而增加的成本。

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

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

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

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

總結(jié)

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