如果你負(fù)責(zé)為企業(yè)創(chuàng)建或管理面向客戶(hù)的應(yīng)用程序，那么將有一長(zhǎng)串需要擔(dān)心的事情。比如，最近，企業(yè)推出了新版本的應(yīng)用程序，客戶(hù)在生產(chǎn)中卻發(fā)現(xiàn)了嚴(yán)重問(wèn)題，應(yīng)用程序的過(guò)度延遲正在破壞其用戶(hù)體驗(yàn)。這時(shí)，你才想起來(lái)使用APM解決其中一些問(wèn)題，實(shí)在是太晚了。你的客戶(hù)早已直接向公司抱怨，并對(duì)社交媒體表示了不滿(mǎn)，而你的管理團(tuán)隊(duì)會(huì)問(wèn)：“這是怎么發(fā)生的?”

這種噩夢(mèng)般的場(chǎng)景，即使是世界上最好的公司也能體驗(yàn)到。例如，Google發(fā)現(xiàn)流量下降了20%，而搜索頁(yè)面的生成時(shí)間多了半秒。亞馬遜發(fā)現(xiàn)，每增加100毫秒的延遲，銷(xiāo)售額就會(huì)減少1%。如果連這些巨頭都可能成為生產(chǎn)應(yīng)用問(wèn)題的受害者，它也可能發(fā)生在任何人身上。

僅依靠傳統(tǒng)的APM手段可能會(huì)讓企業(yè)面臨三個(gè)關(guān)鍵領(lǐng)域的風(fēng)險(xiǎn)：

·無(wú)法盡早發(fā)現(xiàn)性能問(wèn)題

·無(wú)法診斷性能問(wèn)題的根本原因

·無(wú)法及時(shí)修復(fù)性能問(wèn)題

發(fā)現(xiàn)性能問(wèn)題

管理應(yīng)用程序性能的最大問(wèn)題之一是能否盡早找到性能問(wèn)題，大多數(shù)企業(yè)的答案都是否定的。事實(shí)上，75%的開(kāi)發(fā)人員都會(huì)在報(bào)告中提到性能問(wèn)題影響生產(chǎn)中最終用戶(hù)的案例，APM解決方案?jìng)鹘y(tǒng)上被設(shè)計(jì)為僅在生產(chǎn)中工作。

傳統(tǒng)APM不是為測(cè)試階段而建立的，雖然傳統(tǒng)APM通常專(zhuān)注于生產(chǎn)環(huán)境，但一些企業(yè)試圖在開(kāi)發(fā)和測(cè)試的早期階段使用它們。他們經(jīng)常發(fā)現(xiàn)，這些指標(biāo)和報(bào)告在這些階段無(wú)效。以生產(chǎn)為中心的APM將為應(yīng)用程序性能提供統(tǒng)計(jì)分析，實(shí)質(zhì)上是數(shù)千個(gè)事務(wù)的匯總結(jié)果。這可能有助于指出會(huì)影響業(yè)績(jī)的重大問(wèn)題，但由于沒(méi)有任何交易細(xì)節(jié)，因此可能是一個(gè)非常模糊的指標(biāo)。

開(kāi)發(fā)人員與代碼更改將如何影響整體性能是分開(kāi)的兩件事情。在許多公司仍然有一種情況，開(kāi)發(fā)人員不直接與構(gòu)建的應(yīng)用程序性能掛鉤。開(kāi)發(fā)者構(gòu)建應(yīng)用程序并將其投放到生產(chǎn)中的操作團(tuán)隊(duì)，當(dāng)該團(tuán)隊(duì)發(fā)現(xiàn)問(wèn)題時(shí)，他們將反饋給開(kāi)發(fā)團(tuán)隊(duì)進(jìn)行修復(fù)。

DevOps運(yùn)動(dòng)敦促企業(yè)通過(guò)創(chuàng)建一個(gè)大型的虛擬團(tuán)隊(duì)，將一些職能和責(zé)任從運(yùn)營(yíng)轉(zhuǎn)移到開(kāi)發(fā)，從而擺脫這種困境。

但即使在DevOps環(huán)境中，我們?nèi)匀豢梢钥吹皆S多測(cè)試正在進(jìn)行，大多數(shù)APM工具都是面向運(yùn)營(yíng)或性能專(zhuān)家的。正因?yàn)槿绱?，只要滿(mǎn)足功能要求，開(kāi)發(fā)人員并不覺(jué)得他們最終要負(fù)責(zé)交付代碼。這在發(fā)展和運(yùn)營(yíng)團(tuán)隊(duì)之間造成了一點(diǎn)分歧，仍然難以找到性能問(wèn)題。為了跨越這兩個(gè)團(tuán)隊(duì)，開(kāi)發(fā)人員應(yīng)該有更多能力來(lái)洞察并影響他們正在構(gòu)建的應(yīng)用程序性能。今天，以生產(chǎn)為中心的APM并不能賦予開(kāi)發(fā)者這樣的能力。

診斷性能問(wèn)題的來(lái)源

一旦發(fā)現(xiàn)應(yīng)用程序問(wèn)題，診斷問(wèn)題根源又變成一件棘手的事情。當(dāng)你從開(kāi)發(fā)過(guò)程轉(zhuǎn)變?yōu)樯a(chǎn)時(shí)，這是一項(xiàng)越來(lái)越困難的任務(wù)。測(cè)試較晚的團(tuán)隊(duì)將被迫診斷復(fù)雜基礎(chǔ)架構(gòu)和場(chǎng)景中正在發(fā)生的性能問(wèn)題。實(shí)際上，86%的根本原因是應(yīng)用程序級(jí)別問(wèn)題，這些問(wèn)題將在開(kāi)發(fā)環(huán)境中體現(xiàn)出來(lái)，并與環(huán)境保持一致。因此，當(dāng)找到根本原因更容易時(shí)，盡早捕捉這些應(yīng)用程序級(jí)別問(wèn)題是有道理的。

一旦應(yīng)用程序投入生產(chǎn)，它就是一個(gè)大而復(fù)雜的系統(tǒng)的一小部分。不再僅僅是應(yīng)用程序的工作，而是關(guān)于應(yīng)用程序周?chē)乃屑夹g(shù)，從網(wǎng)絡(luò)基礎(chǔ)設(shè)施到分布式系統(tǒng)。Dynatrace的一項(xiàng)研究發(fā)現(xiàn)，平均來(lái)說(shuō)，單個(gè)交易使用82種不同類(lèi)型的技術(shù)，這使得試圖診斷生產(chǎn)中的性能問(wèn)題來(lái)源如同大海撈針。

由于這種復(fù)雜性使得難以準(zhǔn)確診斷問(wèn)題根源，大多數(shù)問(wèn)題并沒(méi)有得到真正解決，只是簡(jiǎn)單地修補(bǔ)。更糟糕的是，匆忙交付修補(bǔ)往往容易造成其他問(wèn)題，每過(guò)一天，問(wèn)題就越來(lái)越嚴(yán)重。

正如前面已經(jīng)介紹過(guò)的，傳統(tǒng)APM是高層次的，足以告訴你存在一個(gè)問(wèn)題，并指出受影響的一般區(qū)域。它們的目的是監(jiān)控難以置信的復(fù)雜基礎(chǔ)設(shè)施，所以一般的健康報(bào)告在運(yùn)營(yíng)團(tuán)隊(duì)生產(chǎn)場(chǎng)景中非常有用。但是，傳統(tǒng)APM對(duì)于那些希望診斷問(wèn)題根源的開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)并不重要，因?yàn)樗麄儧](méi)有提供詳細(xì)的根源分析。當(dāng)檢測(cè)到問(wèn)題并創(chuàng)建了報(bào)告將其傳遞給開(kāi)發(fā)團(tuán)隊(duì)時(shí)，可能需要在分階段環(huán)境中使用其他工具集的性能專(zhuān)家采取可操作的數(shù)據(jù)。

通常，應(yīng)用程序問(wèn)題可能是有條件的，很難再現(xiàn)，問(wèn)題可能與客戶(hù)的部署環(huán)境相關(guān)，這也讓問(wèn)題修復(fù)變得復(fù)雜起來(lái)。

修復(fù)性能問(wèn)題

這是傳統(tǒng)APM最為暴露的領(lǐng)域，因?yàn)閱?wèn)題最終由開(kāi)發(fā)人員解決。以生產(chǎn)為中心的APM并不與開(kāi)發(fā)人員的日常工作流程保持一致，因此開(kāi)發(fā)團(tuán)隊(duì)采用是一個(gè)挑戰(zhàn)。開(kāi)發(fā)人員已經(jīng)在處理緊迫的期限和產(chǎn)品壓力，因此傳統(tǒng)APM的復(fù)雜性并不值得他們花時(shí)間去弄清楚如何獲得可操作的數(shù)據(jù)。

最重要的是，在開(kāi)發(fā)環(huán)境中，傳統(tǒng)APM被認(rèn)為是絕對(duì)的矯枉過(guò)正。畢竟，它們是為操作而開(kāi)發(fā)的，并且具有許多開(kāi)發(fā)人員不需要的功能。這些APM解決方案只能指出問(wèn)題的大致方向，但不提供低層次的數(shù)據(jù)演示，以迎合開(kāi)發(fā)人員解決問(wèn)題的需要。因此，企業(yè)在解決傳統(tǒng)APM問(wèn)題時(shí)經(jīng)常會(huì)遇到以下問(wèn)題。

沒(méi)有修復(fù)驗(yàn)證可用。在開(kāi)發(fā)機(jī)器上設(shè)置和配置傳統(tǒng)APM是一項(xiàng)可能回報(bào)很少的大任務(wù)，因?yàn)樗鼈儾惶峁┯兄谠陂_(kāi)發(fā)環(huán)境中隔離，修復(fù)和測(cè)試問(wèn)題的功能。傳統(tǒng)APM無(wú)法為開(kāi)發(fā)人員提供即時(shí)反饋，因此他們可以看到代碼更改如何影響他們正在處理的應(yīng)用程序性能。

為了驗(yàn)證錯(cuò)誤修復(fù)，開(kāi)發(fā)團(tuán)隊(duì)必須等部署到生產(chǎn)階段。如果bug存在，那么修復(fù)測(cè)試周期在時(shí)間和業(yè)務(wù)影響方面會(huì)非常昂貴。代碼所有者和生產(chǎn)問(wèn)題的表現(xiàn)之間的長(zhǎng)反饋循環(huán)使修復(fù)更加復(fù)雜。

修復(fù)有問(wèn)題的代碼往往涉及代碼的開(kāi)發(fā)人員，由于開(kāi)發(fā)代碼通常需要幾個(gè)月的時(shí)間才能發(fā)布到開(kāi)發(fā)環(huán)境中，開(kāi)發(fā)人員直到編寫(xiě)代碼后才看到這個(gè)有問(wèn)題的代碼。在這一點(diǎn)上，可能對(duì)代碼已經(jīng)不是很熟悉了，而其他代碼可能已經(jīng)構(gòu)建在有問(wèn)題的代碼之上，使其成為大型代碼庫(kù)的一部分。在研究，復(fù)制和解決問(wèn)題所需的時(shí)間中，可能會(huì)影響成百上千的客戶(hù)。

小貼士

大多數(shù)公司目前處理績(jī)效管理的方式被打破了。當(dāng)你等待生產(chǎn)來(lái)解決應(yīng)用問(wèn)題時(shí)，你的客戶(hù)會(huì)在你做之前找到它們。而當(dāng)你把生產(chǎn)中發(fā)現(xiàn)的問(wèn)題反饋給開(kāi)發(fā)團(tuán)隊(duì)解決時(shí)，如果你在開(kāi)發(fā)階段或測(cè)試階段就開(kāi)始解決問(wèn)題，那么花費(fèi)的時(shí)間就會(huì)更長(zhǎng)，成本也更高。每個(gè)團(tuán)隊(duì)，特別是DevOps專(zhuān)注的團(tuán)隊(duì)，都應(yīng)該仔細(xì)研究如何提高發(fā)現(xiàn)，診斷和解決性能問(wèn)題的速度。

如果沒(méi)有及早測(cè)試，客戶(hù)就會(huì)變成你的測(cè)試人員。如果將真實(shí)用戶(hù)置于未經(jīng)過(guò)性能測(cè)試的產(chǎn)品代碼上，這對(duì)于丟失客戶(hù)是一個(gè)很好的選擇。

傳統(tǒng)APM是為操作而構(gòu)建的，對(duì)于生產(chǎn)來(lái)說(shuō)必不可少，但不是為開(kāi)發(fā)人員進(jìn)行測(cè)試和開(kāi)發(fā)而構(gòu)建的。相反，開(kāi)發(fā)人員需要尋找專(zhuān)門(mén)為開(kāi)發(fā)和測(cè)試而構(gòu)建的APM工具，盡早將工具集轉(zhuǎn)向以開(kāi)發(fā)為中心的解決方案。