傳統(tǒng)APM讓開發(fā)者瞬間崩潰的三大問題是什么，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

創(chuàng)新互聯(lián)公司專注于清豐網站建設服務及定制，我們擁有豐富的企業(yè)做網站經驗。 熱誠為您提供清豐營銷型網站建設，清豐網站制作、清豐網頁設計、清豐網站官網定制、成都小程序開發(fā)服務，打造清豐網絡公司原創(chuàng)品牌,更為您提供清豐網站排名全網營銷落地服務。

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

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

僅依靠傳統(tǒng)的APM手段可能會讓企業(yè)面臨三個關鍵領域的風險：

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

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

·無法及時修復性能問題

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

管理應用程序性能的最大問題之一是能否盡早找到性能問題，大多數(shù)企業(yè)的答案都是否定的。事實上，75%的開發(fā)人員都會在報告中提到性能問題影響生產中最終用戶的案例，APM解決方案傳統(tǒng)上被設計為僅在生產中工作。

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

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

DevOps運動敦促企業(yè)通過創(chuàng)建一個大型的虛擬團隊，將一些職能和責任從運營轉移到開發(fā)，從而擺脫這種困境。

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

診斷性能問題的來源

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

一旦應用程序投入生產，它就是一個大而復雜的系統(tǒng)的一小部分。不再僅僅是應用程序的工作，而是關于應用程序周圍的所有技術，從網絡基礎設施到分布式系統(tǒng)。Dynatrace的一項研究發(fā)現(xiàn)，平均來說，單個交易使用82種不同類型的技術，這使得試圖診斷生產中的性能問題來源如同大海撈針。

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

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

通常，應用程序問題可能是有條件的，很難再現(xiàn)，問題可能與客戶的部署環(huán)境相關，這也讓問題修復變得復雜起來。

修復性能問題

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

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

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

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

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

　小貼士

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

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

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

關于傳統(tǒng)APM讓開發(fā)者瞬間崩潰的三大問題是什么問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關知識。

網站欄目：傳統(tǒng)APM讓開發(fā)者瞬間崩潰的三大問題是什么
當前地址：http://sd-ha.com/article8/gphhip.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網站、移動網站建設、搜索引擎優(yōu)化、網站設計、網站維護、外貿建站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)