緊盯IT應用性能

在IT投資龐大之后，如何盡可能釋放它的效能成了企業CIO們最操心頭痛的事。

“一輛正在行駛的汽車，您被告知它的速度是120英里／小時，但事實上只達到了80英里／小時，找不到問題只能干著急”，這一幕一定會讓不少企業的系統維護人員產生共鳴，如何找回那丟失的40英里／小時，這就是應用性能管理的使命。

性能跟不上應用的擴張

今天，IT企業不得不面對這樣的窘境：用戶一面享受著各種復雜的應用，一面又追逐著更高的性能。然而隨著應用復雜度在不斷地爬坡，系統性能的提升就顯得更加舉步為艱，兩者間的微妙關系，還真的一言難盡。

眾所周知，信息技術現已成為企業核心競爭力的一個重要組成部分，是業務成敗的決定因素。信息技術通過不斷地技術創新，一方面不斷完善自身的體系結構和實施手段；另一方面，它引導新業務模式的產生，成為生產力提升和變革的原動力。正是由于信息技術對于企業經營模式，乃至整個社會溝通方式所產生的顯著而巨大的影響，它已經從一個輔助性的角色，轉變成為眾人所矚目的重點話題。

讓我們把目光從整個社會的大范疇聚焦到一個企業，信息技術的發展已經到了一個極致。7x24的全天候訪問，跨越軟硬件平臺的無限可擴展性，簡單、一致的用戶自助服務界面……諸如此類的苛刻要求，都是為了滿足業務部門”更快、更高、更強”的要求而制定的。然而，在信息系統滿足了上述的種種要求之后，其自身的結構也變得異常的復雜。

在一個典型的企業應用環境中，從后臺的硬件存儲開始，往往要通過數據庫，應用服務器、Web服務器和客戶端應用幾個技術層次來實現業務操作，其中還會由若干承擔具體任務的中間件產品和技術擴展，來提供諸如均衡負載、高可用性、可伸縮性等企業計算所必須具備的功能。

如此復雜和功能強大的信息系統為企業業務目標的實現提供了技術上的保障，然而，這還不足以實現提高生產力的最終目標。一個企業應用的評估標準應該有兩個，一個是可實現性，一個是運行效率。對于前者，我們通過基礎架構和技術組件來達成，而后者，傳統的實現方法是通過專門的維護團隊來保證的。對單一類型的應用而言，“效率”，也就是“性能”，通過這種方式，是能夠得到保證的。無論是數據庫，還是應用服務器，乃至在更加復雜的定制應用和打包應用領域，都有廠商或者集成商的專業技術人員來為之提供支持服務。對于用戶而言，無論是依靠廠商的服務，還是自己擁有的系統維護團隊，對于單一類型的應用系統尚且能夠確保性能。然而，隨著特定技術之間的交叉、融合，只單純掌握一種技能的維護人員已經越來越難以應付系統性能所提出的挑戰，再者，龐大的維護隊伍顯然將帶來另一種壓力。

基于Web，有喜有悲

在進入21世紀之后，隨著Web技術成為數據展現和操作訪問的事實標準，企業利用這個平臺，將原來分散的子系統進行整合。盡管應用整合可以通過多種手段來實現，但J2EE的出現，由于其天生具備良好的開放型和可擴展性，使之在應用整合和開發的過程中發揮了愈來愈顯著的優勢。

采用J2EE技術部署基于Web的應用，已經顯著改變了服務的基本經濟原則、競爭力和用戶界面。基于Web的應用迅速代替成本更高的“人員協助”傳統服務。這種新一代應用為企業提供了獨一無二的機會，使之能夠利用傳統系統，在多個服務“層”之間分配應用，充分利用新計算技術的優勢。雖然這些基于Web的應用為公司提供了無與倫比的靈活性，但卻使所在的基礎設施面臨不斷地改變和超高的負載，應用性能的下降所導致的不良用戶體驗，反而降低了客戶的滿意率和忠誠度。

當今的用戶都期望能在世界各地隨時訪問網站。如果應用的用戶發現屏幕底部的藍色進度條從左到右前行的速度過慢，他們就會離開該網站，而且通常不會再次訪問。同樣，如果服務水平沒有達到期望值，現有客戶端通常會重新使用陳舊的、高成本的舊應用來處理業務，或者開始關注其他供應商或服務。從而，企業的管理者認識到，由于目前業務對于信息系統的依賴性，如果不能遏制應用性能下降導致的客戶流失，如果不能克服復雜性所導致的遲緩的故障排查，對于J2EE在內的新技術的使用都會適得其反，導致業務的下滑。

應用性能管理的使命

就在人們對于應用性能逐漸缺乏耐性的時候，一種對于應用性能進行監控、報告、分析，改進以及趨勢預測的技術應運而生，我們把這類技術成為應用性能管理(Application Perfor-mance Management，APM)。

應用性能管理究竟會為我們的系統性能帶來怎樣的改變?也許英國電信的互聯網業務部的親身經歷更有說服力。兩年前，他們開發了一款全新的尖端網絡中心系統稱之為BT Openworld，用以提高ISP的性能和可用性，改進客戶體驗。而這款網絡中心系統同樣面臨性能管理的挑戰。“我們的團隊認識到，系統并沒有達到最佳運行狀態，客戶訂單經常不能在協議規定的交付時間執行，而且需要不斷對系統進行人工調節，負責處理訂單流程的人員還要負責不斷地以手工方式進行系統調優、打補丁和風險管理，”回想起那段日子，負責系統運行維護的經理Neal Kelshaw覺得苦不堪言，而現在，這一切一去不返，他接著說，“當VERITAS i3完全投入使用的第一天，它就找出了問題的確切原因：設備數據庫中存在一個Oracle性能問題，該問題影響了系統的容錯性，導致訂單排隊的失敗。我們及時解決了該問題，這應該歸功于應用性能管理。”兩相比較，Neal Kelshaw顯然更信任應用性能管理。

其實Neal Kelshaw的遭遇只是冰山一腳，很多系統管理人員都面臨這樣或者那樣的性能問題。而更讓人揪心的是他們看得到癥狀，卻找不到根源，因此越來越多的人寄希望于各種APM軟件。然而APM畢竟不同于一般的性能調優工具，他需要有完善的方法論和解決方案作為保障，這是每一個用戶應該首先明確的。我們可以從四個層面來解讀APM的使命：

一、APM著眼的是應用系統整體的性能管理，而非僅僅針對某個技術層次的“煙囪式”的解決方案。

從性能指標的檢測開始，APM就是以最終用戶的響應時間為主要的衡量標準，在第一時間將問題定位于某個技術層次在問題得到修改之后，它也會從應用整體響應時間的角度，測量改進之后的性能。

二、APM的視野不僅足夠寬廣，而且足夠深入。

對于每個技術層次，APM都能夠溯本求源，準確定位導致性能下降的根本問題。而且，它提供專家級的建議，通過最佳實踐幫助使用者盡快進行修復。

三、APM考察應用系統的性能依據，來自于用戶的真實操作數據。

同比傳統性能調優工具使用的模擬數據，APM才能夠收集到用戶實際的體驗，將使用習慣，業務波動和技術指標綜合考慮。顯而易見，這種數據只能來自于生產環境，而APM依靠其對于應用超低的負載，能夠實施7x24的長期監控，是那些產生高額負載的性能調整工具所不能比擬的。

四、APM擁有專門的數據存儲。

APM將采集的數據經分析之后存放起來，而非在考察之后就拋棄，或者僅僅保留短時間的性能數據。只有這樣，使用者才能夠通過對于長時間的歷史記錄的分析得到結論，從而了解過去曾經發生過什么，現在正在發生什么，以及今后即將發生什么。這就使得，APM不僅僅是一個在性能問題出現后進行補救的工具，而且能夠為系統的維護團隊提供預警信息，在性能問題真正開始影響用戶的使用之前，就將其改正，保證為用戶提供一個性能可靠，堅如磐石的應用系統。