應用性能的管理觀

申請免費試用、咨詢電話：400-8352-114

端到端應用性能管理（End-to-end Application Performance Management，簡稱APM）指的是 一種 IT 服務方法，包括識別、區(qū)分優(yōu)先次序以及解決影響業(yè)務應用的性能和可用性問題。APM 正在變得越來越重要，因為終端用戶依賴日益復雜的應用來實現(xiàn)關鍵業(yè)務交易。應用性能低下將降低生產(chǎn)力，影響客戶滿意度，并有損 IT 聲譽，進而導致成本攀升、收入減少、IT 變得效率低下——這些問題通常比可用性問題更加嚴重。

傳統(tǒng)的監(jiān)測解決方案通常無法識別和解決應用性能問題的根源。事實上，最近在終端用戶體驗監(jiān)測、依賴性映射和相關性方面的最新進展，已讓 IT 運行經(jīng)理能夠更有效地監(jiān)測和解決不滿足服務水平的問題。這些技術幫助提高對整個網(wǎng)絡、服務器（分布式和大型主機）和其它應用層的可視性，借助技術分析因果關系，從業(yè)務的角度確定哪些響應該優(yōu)先進行。實際上，即使基礎架構測量指標仍然提供主要的故障和容量數(shù)據(jù)，強調(diào)重點也已從基礎架構測量指標變成了業(yè)務測量指標。

我們將撰寫一系列應用性能管理最佳實施的文章，從問題和事件管理的視角剖析 APM。問題和事件管理是 APM 的兩個核心 ITIL（信息技術基礎架構庫，簡稱 ITIL）流程。事件管理（Incident Management）是當IT 出現(xiàn)問題的時候解決它們，作為對服務質(zhì)量降低的一種響應。事件管理的目標是恢復服務，對業(yè)務造成盡可能小的影響。問題管理（Problem Management）強調(diào)識別和消除問題的根源。它通過改變服務和 APM 解決方案，增加了服務質(zhì)量改進的概念。

本文將首先概括地講述 APM 設計、實施和運營的基本要素，將端到端 APM作為一個流程來進行探討。

一、APM 設計

APM 解決方案通常是作為草根、基礎架構監(jiān)測實踐開始的，由IT 機構的某個獨立業(yè)務部門實施，缺乏一致的目標。例如，網(wǎng)絡團隊可能要部署一個開源網(wǎng)絡工具，以獲得基礎網(wǎng)絡的可視性，而web 服務器團隊則可能會從一個主流的服務器廠商那里部署一個服務器監(jiān)測工具。然而，自上而下地設計一個 APM 方案要切合實際得多。使用這種方法，您先設想結果，然后將它應用于您選擇的解決方案組件。

您如何著手開始呢？在 ITIL 的世界里，最終支持服務級別協(xié)議（service level agreement，簡稱 SLA）的運行級別目標（operational level target，簡稱OLT）是一個好的起點；這些將已經(jīng)解決了預期的業(yè)務產(chǎn)出和成本限制，并且應該實現(xiàn)一個高水平的設計。不與 ITIL 相關？您仍然能夠采用適合您需求的部分最佳實施。從與業(yè)務部門討論、理解業(yè)務目標開始，確定 APM 預算，使用對應用交付基礎架構的理解和它的性能敏感性，并草擬一個方案。您很可能想把這個作為一個練習，測試什么可能會出錯，盡可能廣泛地擴展范圍；成本和其它的實際考慮將很快專注于這一設計。您當然不會是第一個采取這種方法的人，您可充分利用與供應商的關系、用戶群和咨詢合作伙伴，來理解類似嘗試可能會有的成功和失敗。

公司高層提供的資源支持和參與對于任何 APM 項目的成功都是至關重要的，因為這將要求來自多個 IT 部門的積極支持。更重要的是，這些部門對于項目的業(yè)務價值要有一致的理解，因為他們每個都可能會面對新的企業(yè)可視性（他們在高管儀表板上的測試指標），對某些東西失去控制（應對問題的新流程），或者放棄一個最受歡迎的工具。開始一個小型的 APM 項目，選擇一個戰(zhàn)略性的應用，為業(yè)務所有者和 IT 機構闡明價值，大多數(shù)機構將會從中受益。這樣一個項目的成功，將能夠被一個更全面、收益更明顯的解決方案利用。

然而，我們大多數(shù)人并不是從臨時拼湊開始設計 APM 解決方案；我們已經(jīng)擁有許多一直服務于我們的目的的基礎架構工具。那么，是什么將一系列“結合平臺的”（platform-aligned）工具轉(zhuǎn)變成APM 解決方案的呢？盡管對于這個問題可能會有許多技術回答，但是，這里有兩個最重要的主題：

·業(yè)務一致性（business alignment）。全新的主要設計目標仍然應該從注重業(yè)務產(chǎn)出開始。對業(yè)務來說，重要的將是終端用戶的體驗——這個可通過性能和可用性進行測量。

·相關性和故障隔離（correlation and fault isolation）。對根源的可視性，是將基礎架構提升至 APM、真正理解基礎架構測量指標如何影響業(yè)務生產(chǎn)力的關鍵。

很容易明白諸如終端用戶體驗（end-user experience，簡稱 EUE）和基礎架構測量指標等業(yè)務相關的測量指標的相關性為何如此重要。將終端用戶體驗到的性能問題與基礎架構測量指標結合起來，隔離主要的根源，這能讓 IT 小組快速準確地專注于問題的起源，同時避免對不相關的組件采取行動。通過適當?shù)拈撝嫡{(diào)整，這為持續(xù)業(yè)務改進奠定了基礎。同樣地，通過 EUE 的相關性，以及受影響的用戶數(shù)量和所在位置、每天交易的次數(shù)和業(yè)務價值，可以找到問題對業(yè)務的影響。

通過一系列基礎架構工具構建 APM 解決方案，會帶來集成和相關性方面的挑戰(zhàn)；您需要對主要的單一供應商（single-vendor）解決方案進行評估權衡，因為供應商和定制化的多供應商（multi-vendor）解決方案構建和交付了集成。對于更小一些的部署，定制化的解決方案可能會更省錢，但是對于較大的實施，可擴展性和維護方面的考慮將會迅速改變價格。

在設計流程里，保持對終端用戶交易響應時間的專注很重要。這有兩個原因。第一，性能分析和問題解決是為更好的了解以業(yè)務為導向的環(huán)境并提出重要意見。盡管在傳統(tǒng)上，基礎架構測量指標是滿足事件和問題管理的數(shù)據(jù)，但是，這些基礎測量指標和它們的閾值驅(qū)動警報在沒有業(yè)務相關性的情況下能夠變得幾乎毫無意義。例如，對于一個 2 M 廣域網(wǎng)連接來說，75% 的利用率究竟是好還是壞呢？一個被報告的交易性能問題是由 SAN 里長度為 8 的測量磁盤陣列引起的嗎？當應用的性能降級時，這些組件級的測量還將總會被突出？其次，從對業(yè)務影響的角度來說，IT 能夠優(yōu)先對事件作出響應是有價值的，它代表了向業(yè)務一致性邁出的重要一步。

同樣重要的是，與技術和 IT 資源的成本相關的設計限制。許多 APM 項目不成功，是因為缺少關注和支持，因為無法維持這一解決方案、無法適應基礎架構的變化并無法定義基于真實世界反饋的流程。

二、APM 實施——將解決方案轉(zhuǎn)變?yōu)檫\行

基線對于任何 APM 實施來說可能是最重要的技術成功因素之一?；€確定了服務的正常運行，為設定警報起點提供了參考，并提供了有價值的趨勢和容量規(guī)劃信息，因為它們是真實的數(shù)據(jù)。

通常，APM 解決方案會動態(tài)地為一些被觀察到的測量指標構建基線；經(jīng)過數(shù)天或數(shù)星期，這些基線趨于一個正常的定義。對于其它的測量指標，您很可能想要基于一段時間內(nèi)的觀察手動設定基線。將這些基線作為參考點，然后您就能夠確定性能閾值；當測量違反了特定的行為準則時，警報就會產(chǎn)生。至少在最初的時候，這些閾值很可能以一個超出基線的比例被設定。例如，當頁面性能從基線降低 25% 的時候，就會引發(fā)一個警報。這些引發(fā)也很可能基于一個模板或一套規(guī)則被設定，能夠包括更復雜的邏輯；再例如，當磁盤寫隊列在 60 秒內(nèi)超出 2 至少 5 次的時候。

重要的、需要考慮的是哪些指標被監(jiān)測，使用什么閾值；大多數(shù)的 APM 工具提供多種多樣的測量選項，深入的顯示出能夠被分散甚至誤導的水平值。缺省值或特定平臺的模板可能通過 APM 解決方案廠商、軟件/硬件廠商、系統(tǒng)集成商或用戶社區(qū)獲得。然而，無論是什么資源，確定這些閾值是否適用于您的特定環(huán)境都是非常必要的。盡管這一決定部分地能夠在實施期間作出，但是大多數(shù)閾值的改進都是在運行期間實現(xiàn)的。

最后，我們應該關注最終由 EUE 測量驅(qū)動的相關性能力。對于有效的相關性來說，最重要的是理解依賴性或交易在系統(tǒng)里經(jīng)過的路徑。它也建議要注意測量時間。當然，不是所有的指標都能夠被連續(xù)評估，因此有些是在一段時間內(nèi)進行取樣。這是一種檢測普遍性問題的有效方法。然而，間歇的問題本質(zhì)上可能會是短暫的，以至于它們在取樣期間被隱藏起來。盡管這些通常只會帶來更小的業(yè)務影響（因為它們以更小的頻率影響更少的用戶），但是它們本質(zhì)上更難解決。交易“跟隨”（following）——通常通過貼標簽——可能對特定的環(huán)境是合適的，然而，暫時縮短的取樣間隔時間為解決間歇問題提供一種更通用的方法。

一個實現(xiàn)強大 APM 配置的明智方法是，在前生產(chǎn)測試實驗室實施關鍵 APM 監(jiān)測組件，這樣您就能夠觀察到一系列系統(tǒng)負載上的正常行為，這對于設置基線是非常有用的。通常，您將會找到性能的瓶頸。知道哪些測量指標表明了該瓶頸的根源和它發(fā)生的閾值，這是一個理解依賴性并積極配置生產(chǎn)監(jiān)測閾值的理想辦法，而且其帶來的影響也很小。

三、APM 運行——持續(xù)的服務改進

成功的運行需要在穩(wěn)定性和持續(xù)的服務改進（CSI）之間保持平衡。對許多企業(yè)來說，僅僅只有在故障發(fā)生并嚴重威脅到業(yè)務的時候，CSI 才會成為一個項目。一旦該問題得到解決，這一概念又會立即被拋到腦后，直到下一個重大故障發(fā)生的時候才會被再次記起。一個更周全的 CSI 方法將在事件和問題管理方面帶來明顯的改善，幫助 IT 機構更好地解決和預防問題的發(fā)生。

正如之前提及的，APM 成功的關鍵——既確保業(yè)務一致性，又能解決問題——在于相關性。一個強大的 CSI 流程強調(diào)去改進被監(jiān)測到的并找到更合適的閾值。

考慮一個 APM 的實施，終端用戶體驗和基礎架構指標要能被監(jiān)測。當事件發(fā)生的時候——無論這個事件是由 EUE 警報引起的，還是因為一個實際的終端用戶——IT 人員都要將這一事件和它的根源關聯(lián)起來。確認并修正敏感性或瓶頸——至少暫時要做到這點。如果瓶頸指標數(shù)據(jù)沒有被監(jiān)測到，那么，無論如何也要開始對 APM進行明顯改進來監(jiān)測它。如果瓶頸指標數(shù)據(jù)被監(jiān)測到了，那也要著手改進去調(diào)整警報閾值，因此下一次警報能夠在用戶抱怨之前就識別到問題。警報可能是被動的——超過某一閾值的用戶正在經(jīng)歷性能問題——也可能是主動的——超出閾值給出了一個盡早的警告：如果用戶繼續(xù)這么做的話，他將會出現(xiàn)性能問題。

最終，持續(xù)的服務改進應該不止是通過改善 APM 解決方案的質(zhì)量來改進業(yè)務服務的水平。它可能意味著，通過撥出額外的資源或者對資源的使用給予優(yōu)先考慮來控制資源，以致瓶頸將不再發(fā)生。分配符合業(yè)務策略的網(wǎng)絡質(zhì)量，增加一個 SAN，或卸載一個專門服務器上的流程，這些都是例子。

四、作為流程的 APM

與事件和問題管理類似，APM 本身能夠被作為一種流程來考慮，因此也適合持續(xù)改進。在 六西格瑪 DMAIC （定義、測量、分析、改進和控制）模式下，既可考慮用于實施 APM 解決方案，又能夠考慮作為一種解決問題的一致方法。

定義（Define）：首先而且最重要的是，您必須界定問題。對于 APM 解決方案的設計來說，這一定義始于業(yè)務需求，而且是經(jīng)常能夠被擴展。然而，對于響應問題來說，這一步則反其道而行之，將問題的定義嚴格限定于它最簡單的核心因素。

測量（Measure）：這一步專注于收集相關的診斷信息，忽略不相關的或分散的數(shù)據(jù)。與 EUE 測量的相關性，對于實現(xiàn)確定的故障域隔離和最終根源分析的主要目標來說至關重要?？芍噩F(xiàn)的問題允許更好的相關性。

分析（Analyze）：該流程的核心步驟包括解釋數(shù)據(jù)。通常，APM 解決問題流程的目標是對一個問題進行“選療”（triage）——識別故障域并對該結論提供支持性證據(jù)。這一步實現(xiàn)了持續(xù)的服務改進；相關的故障能夠被用于改進閾值設置，并作為修正系統(tǒng)設計的輸入數(shù)據(jù)。

改進（Improve）：領域?qū)＜摇c更大的團隊合作——確定改進選項來解決事件或問題。這一流程應該分開。當然，主要的業(yè)務目標是解決問題以重新恢復服務，但是從持續(xù)服務改進的角度來看，改進 APM 解決方案也很重要。APM 工程師應該評估正確的指標是不是正在被監(jiān)測到，這些指標是不是相關、能夠提供正確的故障域信息。

控制（Control）：最后一步是最容易被忽視掉的；可是沒有它，您將會發(fā)現(xiàn)，有時候?qū)τ谕粋€問題，您一直在重復著前面的4個步驟。從業(yè)務角度來說，這是系統(tǒng)結構發(fā)生變化的地方——增加資源或?qū)椖窟壿嬜鞒龈淖円员苊鈱ο拗频拿舾校@些限制導致了問題的產(chǎn)生——應該被考慮到。從 APM 的角度來說，考慮調(diào)整警報閾值和規(guī)則，從而提供一個對將來問題的提前警報，這樣就能在業(yè)務受到影響之前采取相應的行動。

五、總結

隨著當今的業(yè)務應用日益變得分布和獨立，Gartner 已經(jīng)為 APM 確定了 4個“維度”。我們已經(jīng)在不同程度上討論了這些維度，在此總結如下：

·體驗（experience）：捕捉應用或服務的終端用戶體驗

·依賴性（dependency）：發(fā)現(xiàn)并模式化應用的拓撲結果

·深潛（deep dive）：捕捉與依賴的組件相關的豐富統(tǒng)計數(shù)據(jù)

·剖析（profiling）：跟蹤整個基礎架構內(nèi)的交易流

成功的 APM 解決方案將在應用環(huán)境中能夠有效地解決這些維度的問題。在隨后的最佳實施文章中，我們將探討什么辦法能夠確保您交付的應用服務可被有效管理。每個主題——數(shù)據(jù)中心、網(wǎng)絡、J2EE 和 .NET——將作為一個單獨的方法、綜合的 APM 解決方案的一部分被一一談及，并專注于特別的終端用戶體驗。