應(yīng)用性能的管理觀

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

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

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

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

本文將首先概括地講述 APM 設(shè)計(jì)、實(shí)施和運(yùn)營(yíng)的基本要素，將端到端 APM作為一個(gè)流程來進(jìn)行探討。

一、APM 設(shè)計(jì)

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

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

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

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

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

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

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

通過一系列基礎(chǔ)架構(gòu)工具構(gòu)建 APM 解決方案，會(huì)帶來集成和相關(guān)性方面的挑戰(zhàn)；您需要對(duì)主要的單一供應(yīng)商（single-vendor）解決方案進(jìn)行評(píng)估權(quán)衡，因?yàn)楣?yīng)商和定制化的多供應(yīng)商（multi-vendor）解決方案構(gòu)建和交付了集成。對(duì)于更小一些的部署，定制化的解決方案可能會(huì)更省錢，但是對(duì)于較大的實(shí)施，可擴(kuò)展性和維護(hù)方面的考慮將會(huì)迅速改變價(jià)格。

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

同樣重要的是，與技術(shù)和 IT 資源的成本相關(guān)的設(shè)計(jì)限制。許多 APM 項(xiàng)目不成功，是因?yàn)槿鄙訇P(guān)注和支持，因?yàn)闊o法維持這一解決方案、無法適應(yīng)基礎(chǔ)架構(gòu)的變化并無法定義基于真實(shí)世界反饋的流程。

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

基線對(duì)于任何 APM 實(shí)施來說可能是最重要的技術(shù)成功因素之一?；€確定了服務(wù)的正常運(yùn)行，為設(shè)定警報(bào)起點(diǎn)提供了參考，并提供了有價(jià)值的趨勢(shì)和容量規(guī)劃信息，因?yàn)樗鼈兪钦鎸?shí)的數(shù)據(jù)。

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

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

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

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

三、APM 運(yùn)行——持續(xù)的服務(wù)改進(jìn)

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

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

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

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

四、作為流程的 APM

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

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

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

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

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

控制（Control）：最后一步是最容易被忽視掉的；可是沒有它，您將會(huì)發(fā)現(xiàn)，有時(shí)候?qū)τ谕粋€(gè)問題，您一直在重復(fù)著前面的4個(gè)步驟。從業(yè)務(wù)角度來說，這是系統(tǒng)結(jié)構(gòu)發(fā)生變化的地方——增加資源或?qū)?xiàng)目邏輯作出改變以避免對(duì)限制的敏感，這些限制導(dǎo)致了問題的產(chǎn)生——應(yīng)該被考慮到。從 APM 的角度來說，考慮調(diào)整警報(bào)閾值和規(guī)則，從而提供一個(gè)對(duì)將來問題的提前警報(bào)，這樣就能在業(yè)務(wù)受到影響之前采取相應(yīng)的行動(dòng)。

五、總結(jié)

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

·體驗(yàn)（experience）：捕捉應(yīng)用或服務(wù)的終端用戶體驗(yàn)

·依賴性（dependency）：發(fā)現(xiàn)并模式化應(yīng)用的拓?fù)浣Y(jié)果

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

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

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