作服務的必看：應用性能管理成熟度模型 --Idea Worth Spread

 --Idea Worth Spread

 

在企業中證實APM

在企業IT機構中工做過的人都會發現，一些好的工具很頻繁地遭遇廢棄。有時是由於工具自己沒有知足本來的預期或需求；有時是由於該工具的倡導者離開了機構；又或者僅僅是由於在供應商被收購或產品被廢棄以後，技術所以而變得過期。對於應用性能管理（APM）方面的工具來講也會面臨這樣的問題。對於該問題，並無終極的解決方案。可是，若是你的工做正好是採購像APM這樣的工具的話，這裏有一些能夠供你參考遵循的步驟，能夠儘量避免發生你所採購的軟件最終被束之高閣的窘況。如下是我在做爲監控架構師和APM買家這一職業生涯中所學習到的一些課程。

1. 記錄下那些讓你痛苦的事情

沒人會贊成爲一個工具無故端的買單，除非真的出現了一些傷害到你業務的問題須要去解決（例如：收入減小、生產力影響、客戶滿意度等）。若是你要證實一次採購的合理性，那就得找出切實存在的問題並將它記錄下來。最好是與業務或任務關鍵應用（好比你的電子商務平臺、在線交易應用、支付網關、風險計算、結算系統等）相關的問題。

找出那些因爲性能不佳和（或）故障時間從而對你業務產生嚴重影響的應用或服務，並記錄如下內容：

• 問題的數量和嚴重性級別
• 平均修復時間（MTTR——一般是從問題產生影響到被解決的平均時間）
• 對業務影響進行量化測量（例如：每分鐘損失的美圓、丟失的潛在用戶、每分鐘丟失的交易）
• 對每一個問題進行故障排除所涉及的平均員工數
• 每次事故的根本緣由

你將會在後續的評估文檔和業務證實中使用到這些數據。

 

2. 清點你所擁有的工具

不少IT機構都擁有着數十個不多被使用的工具，或者只是曾經被使用過。若是還沒有完成統計的工做，你須要清點已經擁有的這些軟件並將它們記錄下來。只要你持續地更新這個清單，你將會在後續的不少年內一直使用這些信息：

• 存在哪些工具以及這些工具該如何歸類？（例如：數據庫監控、網絡監控、操做系統監控、桌面監控）
• 咱們擁有哪些軟件許能夠及哪些許可如今還在有效期內？
• 這些工具擅長的領域？
• 這些工具不擅長的領域？
• 什麼能夠被歸爲APM工具？
• 若是我已經擁有了APM工具，爲何它沒有被合理的使用？

爲你擁有的工具加上標籤以便於理解他們的功能。這樣作有助於幫你識別出大家薄弱的環節在哪裏，而且能夠發現那些你所擁有但還沒有被充分利用的工具。

3. 發現你的盲點

如今你已經縱覽了整個監控系統體系的全景，你須要查看下是否還存在漏洞。一種檢查的方式是將你現有的工具集與一個應用性能管理解決方案應包含的工具集模型進行對比，好比，Gartner定義的APM的 5個維度。針對一個「完整的」APM解決方案，Gartner模型包含了如下5個標準：

1. 終端用戶體驗監控：測量你的應用和終端用戶之間全部交互方式的響應時間。僅僅理解應用在數據中心範圍內跑得有多快是不夠的。
2. 應用拓撲映射：自動檢測和展現全部應用交付所涉及的組件。你須要知道在任意指定時間內使用了哪些應用組件，特別是當某個問題對你的用戶形成影響的時候。
3. 業務事務分析（Business Transaction Profiling）：檢測和測量由單個用戶發起的請求所涉及的全部應用組件活動中的響應時間。這與測量單個web頁面的響應時間是不一樣的。
4. 深度應用診斷：檢測和測量代碼在你應用容器中執行的運行時間。若是你當前或將來的解決方案無需加載到應用容器中，那你將不須要此項重要功能。
5. 分析：數據的智能應用將爲你提供可供執行的信息。分析與報表是不一樣的，分析能夠（應該）做爲多個競爭方案間的關鍵鑑別方式。

對於能在APM解決方案中尋找什麼，Gartner模型應該使你有了一些概念。可是大多數軟件自己並不包含以上所描述的APM的五個方面，所以不少機構經過使用不一樣工具的組合來知足他們對可見性的需求。仔細審查一下大家庫存軟件清單中的工具列表，從而能夠找出大家現有APM策略中的漏洞。

一旦你在機構中證實並創建了APM流程，甚至得到了一款APM工具，後續的重點將是開始測量APM程序的有效性並識別出須要改進的方面。這即是APM成熟度模型能夠幫助你評估和分析的所在了。

一個新的APM成熟度模型

成熟度模型一般由於過於偏重理論而難以成功。供應商將成熟度模型強行推銷給他們的客戶並盡其最大努力來提高對該模型的採用和留存率，而客戶則由於過於忙着解決問題而沒有對此很上心。這即是我之因此要提出屬於我本身的APM成熟度模型的緣由，該模型將基於現實世界的經驗，幫助咱們解決迫在眉睫的問題並使用好APM工具，而不僅是停留在應該如何使用APM這一理論上。在這一章節中，我將提出個人新成熟度模型並提供一些APM買家或用戶可能在每一個階段提出的典型問題。

你會提出什麼樣的問題？

在成熟度模型中，對於你身處何處的最好指標取決於來自大家機構的問題以及陳述的類型。舉個例子，當個人孩子問起小寶寶來自何處時，我就立刻知道了他目前在生命成熟度模型中所處的位置——而且當任何別的孩子問起相同的問題時，那麼不論其年齡大小，極可能也處於相同的階段。爲了更容易地識別出你和你的機構目前所處的階段，我已經了整理你在流程中的每一個階段可能提出的不一樣類型的問題，並以此來組織好個人成熟度模型。

Hirsch的APM成熟度模型

第0級 —— 什麼即將發生？

• 咱們剛接到了一連串的電話表示網站或應用變得很慢。這是真的嗎？
• CPU、內存、磁盤和網絡看上去都很正常啊。爲何它仍是那麼慢？
• 你開始撥打電話或開啓/加入電話會議以詢問
  • 你是否作了什麼改動？
  • 你在日誌中有發現什麼嗎？
  • 咱們的網絡是否是出了問題？
  • 誰能讓DBA立刻上線？必定是數據庫出了什麼問題！
  • 系統剛纔又從新開始工做了。有誰作了任何修改嗎？
  • 問題是否是已經修復了？

• 凌晨三點來自求助臺的電話…系統又出問題了。該死的！
• 某個業務事務是如何與IT基礎設施關聯的？

第1級 —— 過多的信息！

• 咱們的新監控工具確實提供了不少的數據。可是看完全部的這些圖表並深刻挖掘這些數據將花費好幾個小時。
• 設置全部的警告閾值將花費很長的時間，可是我敢打賭這是值得的。
• 爲何會有這麼多的警告？難道每一個功能都在同一時間出了問題？
• 是否是真的出現了什麼情況？我不清楚，只能去測試一下站點或應用把問題找出來。
• 系統在開發/測試/qa的環境中都運行的很好。生產環境中有什麼不一樣嗎？
• 咱們在開發環境中對咱們的代碼進行了分析優化，可是它在生產環境中仍然愈來愈慢。這是爲何？
• 系統在客戶那爲何仍是這麼慢？但是在咱們辦公室看上去很正常啊。
• 咱們的APM工具在測試時表現得很不錯，可是咱們還不敢在生產環境使用它。
• 有誰知道在咱們的應用之間存在的依賴關係嗎？
• 我據說過所謂的DevOps。它究竟是什麼？

Level 2 – 唷，變得愈來愈好了!

• 咱們仍然會獲得不少的警告，可是一旦應用變慢或出現問題咱們會立刻知道。
• 咱們再也不須要去常常地設置警告的閾值；當重要的指標偏離他們的基準線時，咱們的工具會自動向咱們發出警告。
• 貌似咱們應用中的一些功能一般都比較慢。讓咱們專一於優化那些使用得最多或最重要的功能吧。
• 咱們爲應用構建了一個面板來展現它什麼時候變慢或出現了問題。
• 咱們能夠看到在測試環境或生產環境中發生的一切，而且知道不一樣環境間的區別。
• 因爲咱們監控了每個業務事務，因此咱們知道是否有終端用戶受到了影響。
• 是的，該問題對應的代碼在DoSomething方法的第45行。
• 咱們會爲應用自動部署監控。這是咱們如今構建或發佈流程的一部分。
• 咱們應用之間的依賴會經過工具自動進行映射。當咱們作出變動時，再也不須要去猜想哪裏會出現故障了。
• 當工做負載出現高峯時咱們能自動作出反應從而避免咱們的站點變慢或宕機，這是否是很酷？
• 我想知道業務是否會受到來自該問題的任何影響？

Level 3 – APM 搖滾巨星（Rockstar）

• 咱們構建了一個業務與技術的面板以便於每一個人能夠看到任意指定時間產生的任何影響。
• 咱們整合了全部的監控工具以提供整個應用以及每一個組件的健康狀況的總體視圖。
• 每當存在某個應用因爲用戶活動高峯而形成速度變慢（或者當咱們預測到將會變慢）時，咱們的工具將自動適應並在高峯結束前運轉起新的實例。
• 當咱們應用中的任意節點沒法正常工做時，咱們的工具將會自動移除掉已損壞的節點並替換以新的功能節點。
• 來源於APM工具集的這些數據將被機構中不少不一樣的功能組所使用，而這些組橫跨了技術和業務。

經過查看這些問題和陳述，你基本上已經能夠識別出你和你的機構目前屬於哪一級別的成熟度模型。甚至更重要的是你或許已經有了一個想法：經過查看你在模型的下一環節須要完成的事項來推動成熟度進程。很明顯，利用APM軟件是達到APM成熟度高級別的有效部分，可是好的流程和訓練有素的人員一樣是成功的關鍵組成部分。成爲APM搖滾巨星的惟一方式是謹慎地平衡好三個部分：人員、流程和技術。

關於做者

Jim Hirschauer是AppDynamics的技術佈道者。在加入AppDynamics以前，Jim在APM用戶端的問題處理，緊急狀況處置以及推進APM供應商精益求精方面花費了多年的時間。Jim的觀點源自於他在高壓金融服務環境下的工做，可是這些方式也適用於任何追求卓越的IT機構

 

查看英文連接：http://www.infoq.com/articles/apm-maturity-model