你須要的是持續的服務改進

IT 正在變得愈來愈重要，做爲公司運做鏈條上的一環，公司治理框架要將本身的業務目標、業務框架向 IT 傳遞。IT再也不與基礎建設和業務發展關聯脫節，而是要緊密聯繫在一塊兒的。

所以，有效的 IT 服務方法，包括識別、區分優先次序以及解決影響業務應用的性能和可用性問題。面向應用與業務的管理，以及其性能分析正在變得愈來愈重要，由於終端用戶依賴日益複雜的應用來實現關鍵業務交易。應用性能低下將下降生產力，影響客戶滿意度，並有損 IT 聲譽，進而致使成本攀升、收入減小、IT 變得效率低下——這些問題一般比可用性問題更加嚴重。

傳統的管理與監測解決方案一般沒法識別和解決應用性能問題的根源。事實上，最近在終端用戶體驗監測、依賴性映射和相關性方面的最新進展，已讓 IT 運行經理可以更有效地監測和解決不知足服務水平的問題。這些技術幫助提升對整個網絡、服務器（分佈式和大型主機）和其它應用層的可視性，藉助技術分析因果關係，從業務的角度肯定哪些響應該優先進行。實際上，即便基礎架構測量指標仍然提供主要的故障和容量數據，強調重點也已從基礎架構測量指標變成了業務測量指標。

問題和事件管理是面向應用與業務的管理的兩個核心 ITIL（信息技術基礎架構庫，簡稱 ITIL）流程。事件管理（Incident Management）是當 IT 出現問題的時候解決它們，做爲對服務質量下降的一種響應。事件管理的目標是恢復服務，對業務形成儘量小的影響。問題管理（Problem Management）強調識別和消除問題的根源。它經過改變服務和麪嚮應用與業務的管理解決方案，增長了服務質量改進的概念。

面向應用與業務的管理解決方案一般是做爲基礎架構監測實踐開始的，由 IT 機構的某個獨立業務部門實施，缺少一致的目標。例如，網絡團隊可能要部署一個開源網絡工具，以得到基礎網絡的可視性，而 Web 服務器團隊則可能會從一個主流的服務器廠商那裏部署一個服務器監測工具。然而，自上而下地設計一個面向應用與業務的管理方案要切合實際得多。使用這種方法，您先設想結果，而後將它應用於您選擇的解決方案組件。

公司高層提供的資源支持和參與對於任何面向應用與業務的管理項目的成功都是相當重要的，由於這將要求來自多個 IT 部門的積極支持。更重要的是，這些部門對於項目的業務價值要有一致的理解，由於他們每一個均可能會面對新的企業可視性，對某些東西失去控制（應對問題的新流程），或者放棄一個最受歡迎的工具。開始一個小型的面向應用與業務的管理項目，選擇一個戰略性的應用，爲業務全部者和 IT 機構闡明價值，大多數機構將會從中受益。這樣一個項目的成功，將可以被一個更全面、收益更明顯的解決方案利用。

然而，咱們大多數人並非從臨時拼湊開始設計 APM 解決方案；咱們已經擁有許多一直服務於咱們的目的的基礎架構工具。那麼，是什麼將一系列「結合平臺的」（platform-aligned）工具轉變成面向應用與業務的管理解決方案的呢？儘管對於這個問題可能會有許多技術回答，可是，這裏有兩個最重要的主題：

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

• 相關性和故障隔離（correlation and fault isolation）。對根源的可視性，是將基礎架構提高至面向應用與業務的管理、真正理解基礎架構測量指標如何影響業務生產力的關鍵。

很容易明白諸如終端用戶體驗（end-user experience，簡稱 EUE）和基礎架構測量指標等業務相關的測量指標的相關性爲什麼如此重要。將終端用戶體驗到的性能問題與基礎架構測量指標結合起來，隔離主要的根源，這能讓 IT 小組快速準確地專一於問題的起源，同時避免對不相關的組件採起行動。經過適當的閾值調整，這爲持續業務改進奠基了基礎。一樣地，經過 EUE 的相關性，以及受影響的用戶數量和所在位置、天天交易的次數和業務價值，能夠找到問題對業務的影響。

經過一系列基礎架構工具構建面向應用與業務的管理解決方案，會帶來集成和相關性方面的挑戰；您須要對主要的單一供應商（single-vendor）解決方案進行評估權衡，由於供應商和定製化的多供應商（multi-vendor）解決方案構建和交付了集成。對於更小一些的部署，定製化的解決方案可能會更省錢，可是對於較大的實施，可擴展性和維護方面的考慮將會迅速改變價格。

在設計流程裏，保持對終端用戶交易響應時間的專一很重要。這有兩個緣由。第一，性能分析和問題解決是爲更好的瞭解以業務爲導向的環境並提出重要意見。儘管在傳統上，基礎架構測量指標是知足事件和問題管理的數據，可是，這些基礎測量指標和它們的閾值驅動警報在沒有業務相關性的狀況下可以變得幾乎毫無心義。例如，對於一個 2M 廣域網鏈接來講，75% 的利用率到底是好仍是壞呢？當應用的性能降級時，這些組件級的測量還將總會被突出？其次，從對業務影響的角度來講，IT 可以優先對事件做出響應是有價值的，它表明了向業務一致性邁出的重要一步。

一樣重要的是，與技術和 IT 資源的成本相關的設計限制。許多面嚮應用與業務的管理項目不成功，是由於缺乏關注和支持，由於沒法維持這一解決方案、沒法適應基礎架構的變化並沒有法定義基於真實世界反饋的流程。

基線對於任何面向應用與業務的管理解決方案實施來講多是最重要的技術成功因素之一。基線肯定了服務的正常運行，爲設定警報起點提供了參考，並提供了有價值的趨勢和容量規劃信息，由於它們是真實的數據。

一般，面向應用與業務的管理解決方案會動態地爲一些被觀察到的測量指標構建基線；通過數天或數星期，這些基線趨於一個正常的定義。對於其它的測量指標，您極可能想要基於一段時間內的觀察手動設定基線。將這些基線做爲參考點，而後您就可以肯定性能閾值；當測量違反了特定的行爲準則時，警報就會產生。至少在最初的時候，這些閾值極可能以一個超出基線的比例被設定。例如，當頁面性能從基線下降 25% 的時候，就會引起一個警報。這些引起也極可能基於一個模板或一套規則被設定，可以包括更復雜的邏輯；再例如，當磁盤寫隊列在 60 秒內超出2至少5次的時候。 重要的、須要考慮的是哪些指標被監測，使用什麼閾值；大多數的面向應用與業務的管理工具提供多種多樣的測量選項，深刻的顯示出可以被分散甚至誤導的水平值。缺省值或特定平臺的模板可能經過面向應用與業務的管理解決方案廠商、軟件/硬件廠商、系統集成商或用戶社區得到。然而，不管是什麼資源，肯定這些閾值是否適用於您的特定環境都是很是必要的。儘管這一決定部分地可以在實施期間做出，可是大多數閾值的改進都是在運行期間實現的。

最後，咱們應該關注最終由 EUE 測量驅動的相關性能力。對於有效的相關性來講，最重要的是理解依賴性或交易在系統裏通過的路徑。它也建議要注意測量時間。固然，不是全部的指標都可以被連續評估，所以有些是在一段時間內進行取樣。這是一種檢測廣泛性問題的有效方法。然而，間歇的問題本質上可能會是短暫的，以致於它們在取樣期間被隱藏起來。儘管這些一般只會帶來更小的業務影響（由於它們以更小的頻率影響更少的用戶），可是它們本質上更難解決。交易「跟隨」（following）——一般經過貼標籤——可能對特定的環境是合適的，然而，暫時縮短的取樣間隔時間爲解決間歇問題提供一種更通用的方法。

成功的運行須要在穩定性和持續的服務改進（CSI）之間保持平衡。對許多企業來講，僅僅只有在故障發生並嚴重威脅到業務的時候，CSI 纔會成爲一個項目。一旦該問題獲得解決，這一律念又會當即被拋到腦後，直到下一個重大故障發生的時候纔會被再次記起。一個更周全的 CSI 方法將在事件和問題管理方面帶來明顯的改善，幫助 IT 機構更好地解決和預防問題的發生。

正如以前說起的，面向應用與業務的管理成功的關鍵——既確保業務一致性，又能解決問題——在於相關性。一個強大的 CSI 流程強調去改進被監測到的並找到更合適的閾值。

考慮一個面向應用與業務的管理方案的實施，終端用戶體驗和基礎架構指標要能被監測。當事件發生的時候——不管這個事件是由 EUE 警報引發的，仍是由於一個實際的終端用戶——IT 人員都要將這一事件和它的根源關聯起來。確認並修正敏感性或瓶頸——至少暫時要作到這點。若是瓶頸指標數據沒有被監測到，那麼，不管如何也要開始對面嚮應用與業務的管理進行明顯改進來監測它。若是瓶頸指標數據被監測到了，那也要着手改進去調整警報閾值，所以下一次警報可以在用戶抱怨以前就識別到問題。警報多是被動的——超過某一閾值的用戶正在經歷性能問題——也多是主動的——超出閾值給出了一個儘早的警告：若是用戶繼續這麼作的話，他將會出現性能問題。

最終，持續的服務改進應該不止是經過改善面向應用與業務的管理解決方案的質量來改進業務服務的水平。它可能意味着，經過撥出額外的資源或者對資源的使用給予優先考慮來控制資源，以至瓶頸將再也不發生。

OneAPM 是應用性能管理領域的新興領軍企業，能幫助企業用戶和開發者輕鬆實現：緩慢的程序代碼和 SQL 語句的實時抓取。想閱讀更多技術文章，請訪問 OneAPM 官方博客。