根據最近不斷涌現的風險投資、私募股權投資以及收購案例來看，目前應用程序性能管理（簡稱APM）市場已經贏得愈發高漲的關注與重視。而作為其迅速崛起的重要推手之一，云計算的廣泛興起為其貢獻了不可磨滅的動力。畢竟如今大量應用程序開始以云環境作為開發及托管的基礎平臺，而相關團隊也迫切需要一套解決方案用于監控并管理應用程序的實際性能表現。基于這一切，應用程序性能管理技術的成功也就變得順理成章。

不過這些應用程序及服務的客戶又抱有怎樣的態度——也就是那些為所在企業購買并維護一系列云應用組合的IT及Business Ops團隊？他們負責支持的用戶希望能夠在不考慮實際應用程序類型的前提下，由其提供對應用服務的高層維護方案。遺憾的是，目前市面上常見的大多數APM解決方案都無法確切滿足這類用戶的實際需求。

有鑒于此，很多已經擁有大量系統管理與監控工具的組織——包括那些規模龐大且技術實力強大的IT團隊——仍然在尋求各類備用方案，旨在幫助自身實現更為理想的云基礎應用程序管理成效。而正是這種理想與現實間的差距——再加上APM領域中的龐大IT Business Ops客戶基礎——才構成了未來幾年當中***前景的APM發展方向。

[[123414]]

???? 針對不同群體提供不同解決方案

很明顯，沒人會誤以為一套源代碼調試工具能夠在IT團隊的微軟Exchange Server管理領域發揮重要作用。前者根本與后者就風馬牛不相及，因此無法帶來任何實質性的幫助。盡管其能夠提供大量客觀信息，但IT運營團隊既無法加以利用、也不能拿來參考。

同理可知，我們不能指望著利用單一一套面向DevOps團隊開發的APM解決方案在使用Exchange Online、Dropbox、Salesforce.com或者其它“黑盒”SaaS應用程序的Business Ops團隊當中發揮作用。這些團隊并不需要登錄到應用程序服務器當中，他們也沒辦法對應用程序代碼進行調整或者直接通過與其云應用程序相對接的網絡基礎設施訪問日志文件或者SNMP信息。

事實上，Business Ops團隊對于APM解決方案提出的需求可謂多種多樣，每一個DevOps團隊可能都擁有自己獨特的具體問題。

下面我們就從選擇性難題入手，了解擺在技術團隊面前的那些分岔路口：

服務水平管理還是應用程序調整

從定義角度出發，DevOps意味著將應用程序開發與運營加以結合，其目標在于通過交付反饋來幫助開發人員以及運營人員共同對其所管理的應用程序或者服務項目加以優化。這些團隊利用APM工具來幫助自己了解哪些特定代碼或者基礎設施尚有提升空間，并借此改進其應用程序性能及可靠性表現。

相比之下，Business Ops則屬于特定用戶群體（包括銷售、市場推廣以及特定應用場景下的企業整體）與IT部門之間的配合產物。相較于傳統的持有者，如今這些對象開始充當云應用程序的“消費者”。他們專注于保證其用戶能夠正常接入服務，并利用其所依賴的應用程序實現正常的生產工作。然而，由于其中涉及一系列應用程序及多家ISP（即互聯網服務供應商），因此Business Ops團隊也需要一整套不同于以往的工具集來幫助自身對相關供應商的服務水平進行驗證與管理，此外還需要在自有網絡內部對問題進行檢測與隔離。

甩手不管還是親力親為

也許在DevOps團隊的應用程序性能管理與IT/Business Ops團隊對Salesforce.com等應用方案進行性能管理的過程中，***的區別在于應用程序源代碼以及托管基礎設施的實際訪問級別。對于那些第三方應用程序而言，Business Ops團隊完全無需考慮源代碼或者托管基礎設施方面的問題。這些應該屬于徹頭徹尾的“黑盒”環境，正如大多數通過網絡進行交付的應用程序只允許用戶直接訪問、而絕對無法進行深入剖析一樣。

出于這個原因，對那些網絡交付應用程序進行代碼層面的調整甚至是集成可以說完全不現實。Business Ops團隊需要利用APM解決方案與云應用程序當中所公開的UI及API進行對接與交互，只有這樣才能切實保證相關應用能為用戶提供符合預期的服務效果。

大量應用還是大量用戶

應用程序DevOps團隊，特別是那些正在著手構建由公有云托管的消費級或者B2B應用程序的團隊，通常會將主要精力集中在單一應用程序或者規模相對較小的應用程序組合的構建與管理方面。然而，他們同樣需要對自身應用程序的交付效果進行測試與優化，因此這類數量較小的應用往往需要面對幾乎無限龐大的用戶群體、遠程終端以及代碼執行路徑的密集訪問。他們希望盡可能多地就此收集數據并加以分析，從而在不影響用戶體驗的前提下為更多規模不定及來自世界各地的用戶提供服務。需要再次強調，正是因為這一點、接入到原始托管主機中的解決方案才具備如此重要的現實意義。

相比之下，業務運營團隊面對的問題則有所不同。他們通常需要面對并管理的用戶群體以及訪問點相對有限而且對實際情況更為熟悉，因此要求相關解決方案能夠使其更為順暢地管理來自多家供應商的數量繁多且持續增長的應用程序組合——同時又無需他們親自為每一款應用程序打理與協議及語法相關的具體工作。

由內而外還是由外而內

如果大家身為應用程序托管服務商，那么肯定希望能夠從網絡之外的遠程端點處獲取到能夠準確反映應用程序性能表現的數據——畢竟服務的實際使用者身在那里，關注他們的具體感受非常重要，對吧？無論大家采用的解決方案是對云環境下的入網點（簡稱POP）進行綜合性監控，還是通過一套被動/真實用戶監控（簡稱RUM）解決方案在應用程序內部對代碼進行追蹤，作為DevOps團隊、我們往往都對“由外而內”的應用程序性能視點保持著高度關注。

Business Ops團隊則需要采用另一種不同的控制方向。在大多數情況下，他們所面對的用戶會通過內部辦公網絡訪問基于云的應用程序方案。在這種情況下，那些在供應商托管入網點之外運行的監控解決方案往往起不到很好的效果，因為它們并不符合所謂“***一英里”原則——即無法從最貼近企業自身網絡環境的ISP/訪問點的位置進行性能檢測。這是一道巨大的鴻溝，因為大多數應用程序可用性及性能表現問題的根源都來自這“***一英里”范疇。如果大家僅僅是立足于云環境對云應用程序進行監控，那么幾乎不可能在問題實際影響到用戶之前將其檢測出來并加以解決。

易用性還是分析深度

服務供應商可以勾勒出一套明確的業務用例，從而驗證各項資源在APM解決方案的集成、部署、培訓以及實際管理等層面的投入狀況。如果大家無法提供高質量的用戶體驗，那么用戶當然不會繼續使用各位提供的應用程序，有效擴展以支持更大規模的用戶群體自然也就成了空談。對于尚處于發展階段的組織來說，應用程序服務供應商還具備將自有應用程序與APM解決方案高效集成、并對其提供的具體數據進行詮釋的必要技能與處理流程。

而在另一方面，Business Ops團隊則專注于支持其所在企業以及用戶。APM對于他們屬于達成既定目標的一種措施與手段，旨在幫助他們盡可能提高工作效率與實際效果。他們屬于真正的運營團隊而非軟件開發團隊，因此需要大量復雜的集成與/或腳本控制技能的解決方案由于太過繁瑣而并不適合他們，特別是在那些應用程序組合正不斷擴展的企業當中。他們所利用的云應用程序在這方面則擁有顯著且愈發理想的管理便捷性優勢。同理，運營團隊自然也希望自己的APM解決方案能夠具備同樣的特性。

Business Ops團隊需要的是能夠實現廣泛分析能力的解決方案，其作用范疇必須涵蓋當前所監控應用程序數量與交付情況，外加用戶與云應用程序本身之間的端到端網絡路徑層面。他們并不在乎是否能夠將特定應用程序的登錄時間縮短100毫秒，因為實現這一點不會帶來顯著的積極意義。相比之下，他們更希望盡可能對關鍵性用戶事務的執行流程加以檢測，從而避免那些本來幾秒鐘就能完成的處理任務被延長到十秒甚至二十秒。如果真的出現這種情況，IT團隊需要有能力及時揪出導致此類問題的根源——甚至來自業務網絡環境之外——并采取有效行動加以解決。

Business Ops——新的DevOps

很明顯，使用云應用程序的Business Ops團隊所需要的APM解決方案具備諸多特性，我們無法直接把適合應用程序服務供應商以及DevOps團隊的現成產品直接套用在他們身上。盡管市面上已經存在很多自我標榜為“企業級APM”的解決方案，但這些產品所面向的往往是那些所管理應用程序運行在自有服務器或者虛擬機環境下的技術團隊、而非云應用運營團隊。

雖然同樣名為應用程序性能管理工具，適用于Business Ops團隊的解決方案可謂完全不同、甚至應該被視為此類產品中的一大全新類別——APM for Business Ops。那么由此構成的是否應該算是利基市場？就目前來看，答案也許是肯定的。但隨著Amazon、谷歌、微軟以及其它多家大型廠商全面進軍云計算領域，全部跡象都指向同一個結論：無論屬于何種規模，企業內部云應用程序及服務在整體應用程序組合中所占比重將愈發可觀并持續增長。

因此，雖然APM for DevOps這股浪潮似乎已經達到了頂峰，但接下來的APM for Business Ops才剛剛來臨。換言之，這并非分岔路口，而是下一場變革的前奏。

英文：??http://www.apmdigest.com/apm-at-a-crossroad-in-the-cloud??