傳統APM讓開發者瞬間崩潰的三大問題！

  如果你負責為企業建立或管理面向客戶的應用程式，那麼將有一長串需要擔心的事情。比如，最近，企業推出了新版本的應用程式，客戶在生產中卻發現了嚴重問題，應用程式的過度延遲正在破壞其使用者體驗。這時，你才想起來使用APM解決其中一些問題，實在是太晚了。你的客戶早已直接向公司抱怨，並對社交媒體表示了不滿，而你的管理團隊會問：“這是怎麼發生的?”

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

　　僅依靠傳統的APM手段可能會讓企業面臨三個關鍵領域的風險：

　　·無法儘早發現效能問題

　　·無法診斷效能問題的根本原因

　　·無法及時修復效能問題

　　發現效能問題

　　管理應用程式效能的最大問題之一是能否儘早找到效能問題，大多數企業的答案都是否定的。事實上，75%的開發人員都會在報告中提到效能問題影響生產中終端使用者的案例，APM解決方案傳統上被設計為僅在生產中工作。

　　傳統APM不是為測試階段而建立的，雖然傳統APM通常專注於生產環境，但一些企業試圖在開發和測試的早期階段使用它們。他們經常發現，這些指標和報告在這些階段無效。以生產為中心的APM將為應用程式效能提供統計分析，實質上是數千個事務的彙總結果。這可能有助於指出會影響業績的重大問題，但由於沒有任何交易細節，因此可能是一個非常模糊的指標。

　　開發人員與程式碼更改將如何影響整體效能是分開的兩件事情。在許多公司仍然有一種情況，開發人員不直接與構建的應用程式效能掛鉤。開發者構建應用程式並將其投放到生產中的操作團隊，當該團隊發現問題時，他們將反饋給開發團隊進行修復。

　　DevOps運動敦促企業通過建立一個大型的虛擬團隊，將一些職能和責任從運營轉移到開發，從而擺脫這種困境。

　　但即使在DevOps環境中，我們仍然可以看到許多測試正在進行，大多數APM工具都是面向運營或效能專家的。正因為如此，只要滿足功能要求，開發人員並不覺得他們最終要負責交付程式碼。這在發展和運營團隊之間造成了一點分歧，仍然難以找到效能問題。為了跨越這兩個團隊，開發人員應該有更多能力來洞察並影響他們正在構建的應用程式效能。今天，以生產為中心的APM並不能賦予開發者這樣的能力。

　　診斷效能問題的來源

　　一旦發現應用程式問題，診斷問題根源又變成一件棘手的事情。當你從開發過程轉變為生產時，這是一項越來越困難的任務。測試較晚的團隊將被迫診斷複雜基礎架構和場景中正在發生的效能問題。實際上，86%的根本原因是應用程式級別問題，這些問題將在開發環境中體現出來，並與環境保持一致。因此，當找到根本原因更容易時，儘早捕捉這些應用程式級別問題是有道理的。

　　一旦應用程式投入生產，它就是一個大而複雜的系統的一小部分。不再僅僅是應用程式的工作，而是關於應用程式周圍的所有技術，從網路基礎設施到分散式系統。Dynatrace的一項研究發現，平均來說，單個交易使用82種不同型別的技術，這使得試圖診斷生產中的效能問題來源如同大海撈針。

　　由於這種複雜性使得難以準確診斷問題根源，大多數問題並沒有得到真正解決，只是簡單地修補。更糟糕的是，匆忙交付修補往往容易造成其他問題，每過一天，問題就越來越嚴重。

　　正如前面已經介紹過的，傳統APM是高層次的，足以告訴你存在一個問題，並指出受影響的一般區域。它們的目的是監控難以置信的複雜基礎設施，所以一般的健康報告在運營團隊生產場景中非常有用。但是，傳統APM對於那些希望診斷問題根源的開發團隊來說並不重要，因為他們沒有提供詳細的根源分析。當檢測到問題並建立了報告將其傳遞給開發團隊時，可能需要在分階段環境中使用其他工具集的效能專家採取可操作的資料。

　　通常，應用程式問題可能是有條件的，很難再現，問題可能與客戶的部署環境相關，這也讓問題修復變得複雜起來。

　　修復效能問題

　　這是傳統APM最為暴露的領域，因為問題最終由開發人員解決。以生產為中心的APM並不與開發人員的日常工作流程保持一致，因此開發團隊採用是一個挑戰。開發人員已經在處理緊迫的期限和產品壓力，因此傳統APM的複雜性並不值得他們花時間去弄清楚如何獲得可操作的資料。

　　最重要的是，在開發環境中，傳統APM被認為是絕對的矯枉過正。畢竟，它們是為操作而開發的，並且具有許多開發人員不需要的功能。這些APM解決方案只能指出問題的大致方向，但不提供低層次的資料演示，以迎合開發人員解決問題的需要。因此，企業在解決傳統APM問題時經常會遇到以下問題。

　　沒有修復驗證可用。在開發機器上設定和配置傳統APM是一項可能回報很少的大任務，因為它們不提供有助於在開發環境中隔離，修復和測試問題的功能。傳統APM無法為開發人員提供即時反饋，因此他們可以看到程式碼更改如何影響他們正在處理的應用程式效能。

　　為了驗證錯誤修復，開發團隊必須等部署到生產階段。如果bug存在，那麼修復測試周期在時間和業務影響方面會非常昂貴。程式碼所有者和生產問題的表現之間的長反饋迴圈使修復更加複雜。

　　修復有問題的程式碼往往涉及程式碼的開發人員，由於開發程式碼通常需要幾個月的時間才能釋出到開發環境中，開發人員直到編寫程式碼後才看到這個有問題的程式碼。在這一點上，可能對程式碼已經不是很熟悉了，而其他程式碼可能已經構建在有問題的程式碼之上，使其成為大型程式碼庫的一部分。在研究，複製和解決問題所需的時間中，可能會影響成百上千的客戶。

　　小貼士

　　大多數公司目前處理績效管理的方式被打破了。當你等待生產來解決應用問題時，你的客戶會在你做之前找到它們。而當你把生產中發現的問題反饋給開發團隊解決時，如果你在開發階段或測試階段就開始解決問題，那麼花費的時間就會更長，成本也更高。每個團隊，特別是DevOps專注的團隊，都應該仔細研究如何提高發現，診斷和解決效能問題的速度。

　　如果沒有及早測試，客戶就會變成你的測試人員。如果將真實使用者置於未經過效能測試的產品程式碼上，這對於丟失客戶是一個很好的選擇。

　　傳統APM是為操作而構建的，對於生產來說必不可少，但不是為開發人員進行測試和開發而構建的。相反，開發人員需要尋找專門為開發和測試而構建的APM工具，儘早將工具集轉向以開發為中心的解決方案。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2154145/，如需轉載，請註明出處，否則將追究法律責任。