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

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

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

[[123414]]

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

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

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

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

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

服務(wù)水平管理還是應(yīng)用程序調(diào)整

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

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

甩手不管還是親力親為

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

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

大量應(yīng)用還是大量用戶

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

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

由內(nèi)而外還是由外而內(nèi)

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

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

易用性還是分析深度

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

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

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

Business Ops——新的DevOps

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

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

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

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