大型網(wǎng)站性能監(jiān)測、分析與優(yōu)化

大型網(wǎng)站性能監(jiān)測、分析與優(yōu)化目錄\h第1部分基礎(chǔ)篇\h第1章應(yīng)用性能管理概述\h1.1關(guān)于應(yīng)用性能\h1.2關(guān)于應(yīng)用性能管理\h1.3基本意識\h1.4如何正確開始\h1.5投入與收益平衡\h1.6優(yōu)秀企業(yè)的經(jīng)驗(yàn)\h第2部分監(jiān)測、工具篇\h第2章應(yīng)用性能監(jiān)測實(shí)踐\h2.1應(yīng)用性能監(jiān)測概述\h2.2應(yīng)用性能持續(xù)監(jiān)測\h2.3應(yīng)用性能即時監(jiān)測\h第3章性能監(jiān)測工具介紹\h3.1監(jiān)測工具概述\h3.2持續(xù)監(jiān)測工具\(yùn)h3.3即時監(jiān)測工具\(yùn)h3.4其他工具\(yùn)h3.5應(yīng)用性能指標(biāo)\h第4章性能監(jiān)測平臺搭建實(shí)踐\h4.1為什么要搭建監(jiān)測平臺\h4.2如何搭建性能監(jiān)測平臺\h第3部分分析、優(yōu)化篇\h第5章應(yīng)用性能分析實(shí)踐\h5.1產(chǎn)生性能問題的因素\h5.2應(yīng)用性能分析概述\h第6章應(yīng)用性能優(yōu)化實(shí)踐\h6.1應(yīng)用性能優(yōu)化概述\h6.2網(wǎng)絡(luò)優(yōu)化\h6.3系統(tǒng)優(yōu)化\h6.4前端優(yōu)化\h6.5后端優(yōu)化\h6.6移動優(yōu)化\h6.7其他優(yōu)化\h第7章性能優(yōu)化平臺搭建實(shí)踐\h7.1為什么要搭建優(yōu)化平臺\h7.2如何搭建性能優(yōu)化平臺\h第4部分標(biāo)準(zhǔn)、保持篇\h第8章應(yīng)用性能優(yōu)化標(biāo)準(zhǔn)\h8.1防止應(yīng)用性能退化概述\h8.2通過規(guī)范防止性能退化\h8.3通過流程防止性能退化\h8.4業(yè)界優(yōu)秀企業(yè)的經(jīng)驗(yàn)\h第9章應(yīng)用性能優(yōu)化保持\h9.1性能優(yōu)化保持概述\h9.2通過平臺防止性能退化\h9.3通過告警防止性能退化第1部分基礎(chǔ)篇第1章應(yīng)用性能管理概述第1章應(yīng)用性能管理概述1.1關(guān)于應(yīng)用性能應(yīng)用性能是互聯(lián)網(wǎng)產(chǎn)品的一種非功能特性，它關(guān)注的不是產(chǎn)品能否完成特定的功能，而是在完成該功能時展示出來的及時性。由于感受應(yīng)用性能的主體是人，所以應(yīng)用性能是一個可感知的綜合用戶體驗(yàn)值。這個體驗(yàn)值深受用戶使用產(chǎn)品的所有因素影響，這些內(nèi)在和外在的很多因素都對應(yīng)用性能和可用性造成干擾，如從用戶發(fā)起對應(yīng)用的訪問，到收到該訪問反饋的內(nèi)容，通常會經(jīng)過DNS查詢、網(wǎng)絡(luò)傳輸和接入轉(zhuǎn)發(fā)，以及Web服務(wù)、應(yīng)用服務(wù)、中間件、數(shù)據(jù)庫等應(yīng)用組件的信息處理，這些組件的性能優(yōu)劣，都會直接影響業(yè)務(wù)交互的實(shí)時性、準(zhǔn)確性和穩(wěn)定性，但是這些影響基本上都無法完全消除或解決，且主要發(fā)生在生產(chǎn)環(huán)境，難以在開發(fā)、測試環(huán)境中發(fā)現(xiàn)。1.2關(guān)于應(yīng)用性能管理其實(shí)應(yīng)用性能管理由來已久，IT從業(yè)者們對它的理解與實(shí)踐也幾乎是從IT誕生就已開始。而最終應(yīng)用性能都通過產(chǎn)品體現(xiàn)給最終用戶。誠然，應(yīng)用性能管理的本質(zhì)是通過掌控應(yīng)用性能狀況，從而改善應(yīng)用性能，為用戶提供最好的用戶體驗(yàn)。當(dāng)下的應(yīng)用性能管理已經(jīng)不是傳統(tǒng)的監(jiān)控系統(tǒng)，也不是單純地使用“Web最佳實(shí)踐”去優(yōu)化網(wǎng)站，而是為針對企業(yè)應(yīng)用特性建立一套科學(xué)完整的應(yīng)用性能監(jiān)測、分析、優(yōu)化體系。由于監(jiān)測和優(yōu)化勢必將影響應(yīng)用性能的所有維度，所以在生產(chǎn)運(yùn)維環(huán)境中，一旦出現(xiàn)應(yīng)用問題征兆，應(yīng)在影響擴(kuò)大之前，發(fā)現(xiàn)問題、判斷原因、隔離故障，從而達(dá)到高效解決問題之目的。應(yīng)用性能管理是系統(tǒng)工程Strangeloop的研究數(shù)據(jù)表明，網(wǎng)站出現(xiàn)1s的延遲后會導(dǎo)致頁面轉(zhuǎn)換率降低7%，流量下降11%，用戶滿意度降低16%。那么，在100%的網(wǎng)站訪客中，就會有57%的訪客在等待3s后放棄，其中80%訪客不會再回來，50%訪客轉(zhuǎn)向其競爭對手網(wǎng)站。性能問題無時無刻不發(fā)生在我們所使用產(chǎn)品的所有過程和所有環(huán)境，例如PC、移動、網(wǎng)絡(luò)、系統(tǒng)、應(yīng)用、硬件、產(chǎn)品邏輯等。正因?yàn)閼?yīng)用性能如此重要且時刻存在，騰訊從2006年開始了大規(guī)模性能優(yōu)化，并將此發(fā)展為騰訊工程師文化之一。百度、阿里在2010年后也陸續(xù)啟動了大規(guī)模的性能優(yōu)化項(xiàng)目。近幾年來，越來越多的企業(yè)進(jìn)行了系統(tǒng)性的性能優(yōu)化，例如新浪、攜程、美團(tuán)、58同城等。正是因?yàn)橐陨掀髽I(yè)對性能的不斷追求，才奠定了中國互聯(lián)網(wǎng)性能優(yōu)化理論與實(shí)踐基礎(chǔ)。應(yīng)用性能管理具有門檻在舉國互聯(lián)網(wǎng)+的時代，用戶至上已經(jīng)被多數(shù)企業(yè)接受。我相信企業(yè)級的應(yīng)用性能管理與優(yōu)化的時代即將來臨，也是企業(yè)可持續(xù)保持好的用戶體驗(yàn)的基本前提。其實(shí)像BAT級別的大型互聯(lián)網(wǎng)企業(yè)都有專職的性能管理團(tuán)隊(duì)，多年進(jìn)行性能管理和優(yōu)化，并建立其完整的性能管理平臺來協(xié)助。意旨讓性能管理和優(yōu)化變得更高效，并保證其產(chǎn)品能夠給用戶帶來卓越并可持續(xù)的體驗(yàn)。事實(shí)上，如果大多數(shù)中小企業(yè)要進(jìn)行性能管理和優(yōu)化是有門檻的。除了需要人力投入以外，還需要實(shí)踐積累的過程及可持續(xù)的維護(hù)能力。所以即便很多二三線互聯(lián)網(wǎng)企業(yè)涉及了性能優(yōu)化，在絕大多數(shù)情況下也只是產(chǎn)品級和部門級。而隨著產(chǎn)品版本迭代和人員流失，性能管理隨即出現(xiàn)退化和斷層，這也是當(dāng)前的基本現(xiàn)狀。第三方推動作用在增強(qiáng)如同CDN行業(yè)一樣，應(yīng)用性能管理也在加速商業(yè)化腳步，即APM行業(yè)。越來越多的云服務(wù)商投入到APM行業(yè)，加快了產(chǎn)業(yè)化進(jìn)程。隨著美國排名靠前的APM廠商紛紛上市，國內(nèi)APM廠商也日趨繁榮。一方面，廠商的投入及商業(yè)化手段有利于增加應(yīng)用性能管理的技術(shù)水準(zhǔn)和豐富方法論，直接降低企業(yè)落地應(yīng)用性能門檻。另一方面，APM的SaaS化，使得每家企業(yè)、甚至每一個開發(fā)者都可以直接使用最優(yōu)秀的APM云服務(wù)幫助改善產(chǎn)品性能，而無須投入額外的人力和資源來搭建應(yīng)用性能管理平臺。換句話說，第三方廠商的服務(wù)能力會從根本上幫助企業(yè)減少應(yīng)用性能的學(xué)習(xí)成本。1.3基本意識應(yīng)用性能木桶理論互聯(lián)網(wǎng)產(chǎn)品是創(chuàng)意、研發(fā)、系統(tǒng)、網(wǎng)絡(luò)、硬件、維護(hù)等所有資源相互交織的集合體，這些資源彼此之間有著千絲萬縷的聯(lián)系。它們必須通過共同協(xié)作以期達(dá)到穩(wěn)定產(chǎn)品運(yùn)行及良好用戶體驗(yàn)的最終目標(biāo)。如用木桶理論幫助理解的話，也就是說一只木桶能盛多少水，并不取決于最長的那塊木板，而是取決于最短的那塊木板，所以也可稱之為短板效應(yīng)。而將木桶理論進(jìn)一步延伸來看，新木桶理論認(rèn)為一只木桶能裝多少水，不光取決于最短的木板，更應(yīng)該取決于木桶是否存有縫隙，若木桶存有縫隙，則水將不斷流失。應(yīng)用性能木桶理論如圖1-1所示。圖1-1應(yīng)用性能木桶理論基本意識和思路應(yīng)用性能監(jiān)測、分析、優(yōu)化的過程就是找出“木桶”的短板、縫隙并進(jìn)行修復(fù)的過程。而“木桶”中的水，就是產(chǎn)品價(jià)值和用戶體驗(yàn)。本人的一些相關(guān)思路，會在隨后做詳細(xì)闡述，以便幫助大家參考理解。1.3.1價(jià)值與意義在互聯(lián)網(wǎng)行業(yè)，要成為受人尊敬的互聯(lián)網(wǎng)企業(yè)，產(chǎn)品的用戶體驗(yàn)是一塊基石——即應(yīng)用性能。在騰訊工作時，常聽到CEO馬化騰要求所有核心產(chǎn)品要做到業(yè)界速度最快，并多次強(qiáng)調(diào)：用戶放棄一個產(chǎn)品只需要2s，1s關(guān)掉網(wǎng)頁，1s打開競爭對手的網(wǎng)頁；在百度工作時，CEO李彥宏也多次強(qiáng)調(diào)，百度搜索80%的用戶要在1s打開。事實(shí)也證明減少檢索加載時間等于增加用戶檢索次數(shù)和廣告收入。從兩個中國互聯(lián)網(wǎng)航母級的企業(yè)如此重視應(yīng)用性能可以看出，應(yīng)用性能對互聯(lián)網(wǎng)產(chǎn)品有著至關(guān)重要的價(jià)值，而更多權(quán)威機(jī)構(gòu)統(tǒng)計(jì)數(shù)據(jù)也從側(cè)面說明了這一點(diǎn)。速度影響用戶滿意度和訪問量1Google的一項(xiàng)試驗(yàn)顯示隨著頁面加載時間從400ms增至900ms，每頁面搜索結(jié)果數(shù)從10增至30，將導(dǎo)致25%搜索者在第一個結(jié)果頁放棄。2有研究顯示，如果3s后，網(wǎng)頁還未加載完畢，57%的用戶會放棄。74%的用戶登錄某網(wǎng)站等待時間超過5s后就不會再登錄這個網(wǎng)站。3有研究顯示，寬帶用戶比窄帶用戶更沒有耐心。寬帶用戶愿意忍受的最長等待時間，往往只有4~6s。60%的用戶希望手機(jī)上的頁面加載時間不要超過3s。速度影響網(wǎng)站收益和SEO排名1Amazon的統(tǒng)計(jì)顯示每延長1s，Amazon一年就會減少16億美元銷售額，首頁打開時間每增加100ms，網(wǎng)站銷售量會減少1%。2據(jù)估計(jì)每年電子商務(wù)網(wǎng)站都會因載入速度過慢，而損失11億到13億美元的收入。3速度在Google的PR評分中占有一定的比例，Google的PR算法中加入了速度評分一項(xiàng)。也就是說，一個好的網(wǎng)站，是不可能讓它的頁面加載速度很慢的。速度是應(yīng)用性能最直接體現(xiàn)速度表示物體運(yùn)動的快慢程度，應(yīng)用或網(wǎng)頁速度簡單理解就是用戶打開一個應(yīng)用或網(wǎng)頁的快慢程度。有些書也總結(jié)為瀏覽器向服務(wù)器發(fā)送第一個請求到最后一個網(wǎng)頁元素加載完的消耗時間?？偠灾?，應(yīng)用或網(wǎng)頁加載消耗的時間越少，代表網(wǎng)頁速度越快。根據(jù)參與騰訊、百度多個產(chǎn)品線優(yōu)化實(shí)踐的體會，通常一個網(wǎng)頁的總加載時間<=5s基本不會讓用戶產(chǎn)生反感，用戶對網(wǎng)頁第一屏加載時間<2s的網(wǎng)站會形成良好印象。圖1-2所示為結(jié)合第三方公司的一些調(diào)研結(jié)果給出的用戶滿意度示意圖，以便大家能夠更好地理解應(yīng)用性能。圖1-2用戶滿意度示意圖應(yīng)用性能具有可控、可管理性應(yīng)用性能發(fā)生在產(chǎn)品邏輯、前端、網(wǎng)絡(luò)、后端、硬件、系統(tǒng)、應(yīng)用等所有環(huán)節(jié)，而這些環(huán)節(jié)之間既環(huán)環(huán)相扣又互相干擾、疊加，讓性能問題更加嚴(yán)重。所以應(yīng)用性能管理的最佳狀態(tài)是讓各環(huán)節(jié)平衡，并且讓各環(huán)境發(fā)揮最理想的性能狀態(tài)。其實(shí)就像人的健康管理一樣，人在有疾病的情況下只有兩個選擇：要么逐漸嚴(yán)重并產(chǎn)生多種并發(fā)癥讓影響更嚴(yán)重，要么盡快就醫(yī)盡快恢復(fù)減少影響。實(shí)際上，無論疾病的大小都會影響日常生活，應(yīng)用性能也如此。所以應(yīng)用性能管理的意義，如同健康管理的意義一樣，在盡快發(fā)現(xiàn)和修復(fù)性能問題，并保持甚至增加產(chǎn)品的體驗(yàn)和價(jià)值上，至關(guān)重要。以下是作者在百度參與部分性能優(yōu)化項(xiàng)目的數(shù)據(jù)，以便幫助大家理解應(yīng)用性能：1百度網(wǎng)頁搜索優(yōu)化收益，包含appquery1.83s→0.61s，首屏做到極致。2百度移動云性能優(yōu)化，首頁2.46s→0.9s，全面反超競品。3百度LBS速度優(yōu)化，首頁2.32s→1.8s，全面反超競品。4百度移動LBS性能優(yōu)化，首頁2.31s→1.08s，落地頁7.35s→6.25s。5百度國際化性能優(yōu)化，國際化搜索速度3~8s→1~2s，國際化網(wǎng)址導(dǎo)航3.46s→2.57s。6百度貼吧frs頁優(yōu)化，優(yōu)化后頁面基本功能可用時間提升30%。7百度貼吧wap頁優(yōu)化，優(yōu)化后頁面減少40%，直接帶動session上升。8百度Image改版，通過預(yù)讀取提高圖片展現(xiàn)速度，瀏覽量增加60%。1.3.2出發(fā)點(diǎn)產(chǎn)品的性能問題與人的健康狀況極其相似。通常只有在我們遇到身體不舒服時，才會去醫(yī)院檢查，才能得知究竟哪里出了問題，且對癥下藥之后仍需一定時間恢復(fù)健康。而產(chǎn)品的性能問題與人的不同之處在于，如若出現(xiàn)問題之后再修復(fù)已經(jīng)太晚，因?yàn)榇藭r已影響到所有用戶的使用，甚至已經(jīng)影響到了營收，并且在事后發(fā)現(xiàn)性能問題需要時間，修復(fù)問題更需要時間，所以性能出現(xiàn)問題對用戶的影響是持續(xù)的，而對于產(chǎn)品而言更加是一場噩夢。試問如若性能問題能夠被事先發(fā)現(xiàn)和修復(fù)，那么在產(chǎn)品研發(fā)過程中就能夠被有效回避。這就是性能優(yōu)化最根本的出發(fā)點(diǎn)，也是用戶獲得更好產(chǎn)品體驗(yàn)的基本前提?；疽?性能問題暴露前，盡早發(fā)現(xiàn)應(yīng)用性能問題，減少對用戶的持續(xù)影響。2性能問題發(fā)現(xiàn)時，盡快修復(fù)主要性能問題，減小應(yīng)用性能影響力度，最大程度改進(jìn)用戶體驗(yàn)。3性能問題優(yōu)化后，杜絕再次發(fā)生，可持續(xù)保持應(yīng)用性能優(yōu)化成果，防止性能退化?；驹瓌t1在產(chǎn)品不同生命周期性能側(cè)重不同，優(yōu)先驗(yàn)證簡單假設(shè)，從簡單到復(fù)雜，優(yōu)先選擇足夠簡單、容易出現(xiàn)收益的方案。2先別急著優(yōu)化，優(yōu)先規(guī)避性能惡化，事實(shí)和推測分開，事實(shí)驗(yàn)證推測，沒有論證預(yù)期收益不做優(yōu)化，把有限的精力投入到關(guān)鍵性能問題上。3從前端到后端，從外到內(nèi)層層剝離，縮小范圍到模塊，模塊內(nèi)部分割單元測試，確定優(yōu)化目標(biāo)。4性能優(yōu)化沒有盡頭，在高速迭代中完成優(yōu)化的同時，還需要與時俱進(jìn)。移動時代的當(dāng)下，不斷投入和提高移動應(yīng)用性能更具價(jià)值。5需要塑造情懷和氛圍，追求高性能的工程師文化，寫出快速友好的代碼。另外，性能優(yōu)化是持久戰(zhàn)，是一個系統(tǒng)工程，需要耐得住寂寞。1.3.3相關(guān)的人互聯(lián)網(wǎng)企業(yè)就是產(chǎn)品工廠，無論移動端還是PC端，都是由產(chǎn)品設(shè)計(jì)工程師構(gòu)圖，再由軟件工程師開發(fā)生產(chǎn)，最后由質(zhì)量和運(yùn)維工程師把關(guān)，以保障產(chǎn)品線上的穩(wěn)定可用。任何一個環(huán)節(jié)都是由人及人控制的機(jī)器完成，而性能問題的根源也在于此。一定程度上，人為因素決定了性能問題的發(fā)生和修復(fù)。而往往一個產(chǎn)品的性能問題是由多個人導(dǎo)致的（很多性能問題的產(chǎn)生是因負(fù)責(zé)人的意識淡漠及“功力”不足而直接導(dǎo)致的），我們能做的是將這些人通過性能相關(guān)的數(shù)據(jù)，聯(lián)動起來，一起解決并保持。應(yīng)用性能管理的角色與分工眾所周知提高一個網(wǎng)站的性能很難，而以一個很小的團(tuán)隊(duì)讓一個大規(guī)模網(wǎng)站一直保持高性能則更難。性能問題可以發(fā)生在一個模塊，也可以是一個產(chǎn)品，更可以發(fā)生在一個部門的多個產(chǎn)品?；谝患夜緦λ挟a(chǎn)品進(jìn)行對應(yīng)性能優(yōu)化，就是最大規(guī)模企業(yè)級的全公司產(chǎn)品性能優(yōu)化。例如騰訊、阿里、百度都有專職優(yōu)化團(tuán)隊(duì)來負(fù)責(zé)公司級產(chǎn)品優(yōu)化。而我在百度期間負(fù)責(zé)的UAQ團(tuán)隊(duì)就是具有這樣使命的團(tuán)隊(duì)。在日常工作中，需要同時配合14條核心產(chǎn)品線進(jìn)行性能優(yōu)化。而通常比較多的情況是產(chǎn)品級性能優(yōu)化，一個產(chǎn)品團(tuán)隊(duì)的技術(shù)經(jīng)理負(fù)責(zé)組織前端、后端、運(yùn)維等同時立項(xiàng)，分期優(yōu)化達(dá)成目標(biāo)。通常不同角色的分工如圖1-3所示。圖1-3性能優(yōu)化團(tuán)隊(duì)角色及分工1FE（前端研發(fā)）1）分析前端程序執(zhí)行效率，改進(jìn)前端邏輯和代碼性能。2）前端公共框架和代碼質(zhì)量管理，前端發(fā)布質(zhì)量規(guī)范。3）負(fù)責(zé)前端JS測速、用戶性能數(shù)據(jù)收集和分析，前端性能分析工具開發(fā)。2RD（架構(gòu)師、后端研發(fā)、移動研發(fā)）1）分析程序執(zhí)行效率、系統(tǒng)架構(gòu)中的性能瓶頸，優(yōu)化系統(tǒng)結(jié)構(gòu)。2）設(shè)計(jì)更好的應(yīng)用系統(tǒng)架構(gòu)和落地。3）針對影響性能的模塊和接口進(jìn)行專題項(xiàng)目改進(jìn)和持續(xù)迭代。3OP（運(yùn)維）1）分析系統(tǒng)運(yùn)行狀況（系統(tǒng)），分析系統(tǒng)資源使用情況（硬件）。2）分析應(yīng)用程序?qū)Y源的使用情況，應(yīng)用程序執(zhí)行效率及相關(guān)壓力測試。3）負(fù)責(zé)服務(wù)器硬件、軟件、軟件配置性能優(yōu)化，前沿相關(guān)技術(shù)調(diào)研和落地。4）提供與競品的瓶頸分析、速度優(yōu)化、評測報(bào)告、收益評估。4SYS（網(wǎng)絡(luò)）1）IDC、CDN、硬件性能測試、商務(wù)采購、上架，新硬件調(diào)研和落地。2）負(fù)責(zé)IDC外網(wǎng)、內(nèi)網(wǎng)傳輸及相關(guān)QoS保障，負(fù)責(zé)IDC、CDN性能優(yōu)化。3）負(fù)責(zé)操作系統(tǒng)母盤、內(nèi)核、TCP傳輸、網(wǎng)絡(luò)路由等調(diào)優(yōu)。正視團(tuán)隊(duì)在性能管理方面的短板性能問題發(fā)生在成長型團(tuán)隊(duì)或產(chǎn)品快速迭代的團(tuán)隊(duì)中是很常見的，而發(fā)生在成熟團(tuán)隊(duì)中則較少見到。團(tuán)隊(duì)負(fù)責(zé)人是性能問題發(fā)生和優(yōu)化的主要負(fù)責(zé)人，起到性能問題的關(guān)鍵把控作用。通常看一款產(chǎn)品的性能問題，就能看出團(tuán)隊(duì)負(fù)責(zé)人的底蘊(yùn)?？梢灶A(yù)見的是，如果團(tuán)隊(duì)負(fù)責(zé)人能規(guī)避多數(shù)性能問題，這款產(chǎn)品的體驗(yàn)肯定是優(yōu)秀的，并且這個團(tuán)隊(duì)的成員在性能優(yōu)化的儲備肯定是足夠的，反之則剛好相悖。從我在騰訊、百度做性能優(yōu)化的這幾年看來，正常情況下，多數(shù)團(tuán)隊(duì)達(dá)不到理想狀態(tài)與團(tuán)隊(duì)負(fù)責(zé)人出現(xiàn)短板和沒有意識是最糟糕的情況，而團(tuán)隊(duì)中部分角色出現(xiàn)短板則是很常見的情況。無論何種原因?qū)е滦阅芷款i，無論是誰指出來我們的產(chǎn)品存在性能問題，團(tuán)隊(duì)負(fù)責(zé)人一定要重視。因?yàn)橹灰嬖谛阅軉栴}，就會影響使用產(chǎn)品的所有用戶，包括未來的新用戶。如果不優(yōu)化，放任自流，就會持續(xù)影響。團(tuán)隊(duì)負(fù)責(zé)人不僅需要具備規(guī)避性能風(fēng)險(xiǎn)的能力，更需要提升整個團(tuán)隊(duì)性能優(yōu)化的意識。只有在日常迭代中減少性能問題的發(fā)生，才能從根本上保證在新產(chǎn)品開發(fā)過程中杜絕性能問題。值得注意的是，在保持和優(yōu)化應(yīng)用性能的經(jīng)驗(yàn)和教訓(xùn)上，以下三個方面也非常重要：1找到“頭狼”，讓有經(jīng)驗(yàn)的性能優(yōu)化高手來主導(dǎo)并快速啟動性能優(yōu)化，快速聚焦最高價(jià)值的優(yōu)化目標(biāo)的同時，在過程中提升整個團(tuán)隊(duì)的性能優(yōu)化能力和意識。2一切以數(shù)據(jù)說話，優(yōu)化的決策和優(yōu)化后的度量都是要建立在科學(xué)、能說服所有人的性能數(shù)據(jù)之上，并能監(jiān)測最終用戶體驗(yàn)及優(yōu)化收益，把性能數(shù)據(jù)價(jià)值化與全團(tuán)隊(duì)分享，最終得到認(rèn)可。3分擔(dān)責(zé)任，性能問題的發(fā)生是由產(chǎn)品各環(huán)節(jié)的角色決定的，首先要自己擔(dān)當(dāng)并正視性能問題。性能優(yōu)化的成功必須建立在與產(chǎn)品研發(fā)、測試、運(yùn)維等團(tuán)隊(duì)長期合作之上，不可能單方向完成，更不可以一蹴而就。1.3.4解決的問題所謂信息量是指從N個相等可能事件中選出一個事件所需要的信息度量或含量，也就是在辨識N個事件中特定的一個事件過程所需要提問“是或否”的最少次數(shù)。應(yīng)用性能優(yōu)化亦如此。每家互聯(lián)網(wǎng)企業(yè)都有若干產(chǎn)品及產(chǎn)品對應(yīng)的開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境，以及這些環(huán)境運(yùn)行的IDC、服務(wù)器、系統(tǒng)、應(yīng)用、用戶端等都同時存在大量的性能事件。這些性能事件最終會綜合發(fā)生在用戶使用產(chǎn)品的體驗(yàn)中，而應(yīng)用性能管理要解決的問題也應(yīng)運(yùn)而生。以下將結(jié)合個人實(shí)踐，提出應(yīng)用性能管理主要待解決問題。最終目的是提高用戶體驗(yàn)用戶體驗(yàn)與產(chǎn)品影響力、企業(yè)形象甚至企業(yè)營收都有直接關(guān)系。性能管理最終目標(biāo)都是以提高用戶體驗(yàn)為根本。例如BAT都是以追求極致體驗(yàn)著稱。一切應(yīng)用性能優(yōu)化和資源投入都是圍繞核心產(chǎn)品展開，力爭在同行業(yè)將產(chǎn)品體驗(yàn)做到最優(yōu)。百度在提升搜索體驗(yàn)中不斷探索和追求極致，為了加快100ms，投入數(shù)千臺服務(wù)器，足見其對于用戶體驗(yàn)重要性的把握。讓應(yīng)用性能完全透明可控建立完整體系的性能監(jiān)控和海量實(shí)時數(shù)據(jù)分析平臺，有助于實(shí)時跟蹤頁面性能，及時發(fā)現(xiàn)頁面性能問題，并為性能優(yōu)化效果提供數(shù)據(jù)支持。應(yīng)用性能管理最基礎(chǔ)的工作是監(jiān)測所有，宛如雷達(dá)一般的作用。也只有全方位監(jiān)測到所有環(huán)境中的性能事件并將這些性能逐一可視化、趨勢化，才具備應(yīng)用性能管理的前提。應(yīng)用性能中衡量用戶體驗(yàn)的指標(biāo)超過100個，分布在移動、PC、網(wǎng)絡(luò)、系統(tǒng)、應(yīng)用等大的維度，后面的章節(jié)會詳細(xì)介紹如何搭建體系的監(jiān)測平臺并介紹如何評測相關(guān)性能指標(biāo)。積累團(tuán)隊(duì)性能優(yōu)化實(shí)踐積累性能分析和評估方法、研究性能優(yōu)化的方法，有助于提高工程師在優(yōu)化性能方面的知識。而提供優(yōu)化性能的工具和庫，為多個產(chǎn)品線性能優(yōu)化提供支持，則能讓所有人都考慮性能，快速實(shí)施性能優(yōu)化。性能問題經(jīng)常在線上被用戶反饋或人工巡檢發(fā)覺，這在初創(chuàng)團(tuán)隊(duì)或新產(chǎn)品團(tuán)隊(duì)中是很常見的現(xiàn)象。一方面，因?yàn)槌墒斓膱F(tuán)隊(duì)或大的產(chǎn)品線都具備足夠的人力和時間來完善應(yīng)用性能，但肯定都是從不完善中走過來的。另一方面，由于團(tuán)隊(duì)在不斷地流動和變化中，這需要團(tuán)隊(duì)不斷積累與性能相關(guān)的意識。從一定程度上講，應(yīng)用性能對于研發(fā)抑或運(yùn)維都屬于高階技能，需要在日常工作中不斷實(shí)踐和積累。自動化解決常見性能問題研發(fā)、測試、運(yùn)維等工程師的主要壓力源自實(shí)現(xiàn)產(chǎn)品性能穩(wěn)定、可持續(xù)發(fā)展。在大多數(shù)情況下，由于主觀上對性能優(yōu)化方法和工具了解有限，而學(xué)習(xí)和實(shí)踐又需要較長時間，所以最理想的狀態(tài)是實(shí)現(xiàn)產(chǎn)品線優(yōu)化工程化地解決性能問題——即能自動化地規(guī)避、優(yōu)化應(yīng)用性能。但是當(dāng)下對多數(shù)團(tuán)隊(duì)來說可操作性極弱。以下列舉較為常見的實(shí)踐場景，以便理解。1成熟互聯(lián)網(wǎng)企業(yè)，例如BAT有公司級統(tǒng)一高性能前端框架、統(tǒng)一CDN、BGP網(wǎng)絡(luò)接入、高性能應(yīng)用組件等相關(guān)部門，并且有專業(yè)的人來維護(hù)這些平臺。產(chǎn)品只需要拆分接入即可享受到最優(yōu)性能，而且不需要自己維護(hù)。除此之外，成熟的互聯(lián)網(wǎng)企業(yè)應(yīng)當(dāng)具備完整的應(yīng)用性能管理體系和意識，在產(chǎn)品測試和發(fā)布前盡量將性能問題發(fā)生的概率減至最低。2邏輯簡單的產(chǎn)品，例如以靜態(tài)模塊為主的電商、咨詢、UGC用戶產(chǎn)生內(nèi)容等類產(chǎn)品，大量內(nèi)容即是用戶訪問的對象。這些內(nèi)容在發(fā)布時就可以自動做大量的優(yōu)化，并自動發(fā)布。也可以直接使用第三方高性能的云，例如計(jì)算、存儲、網(wǎng)絡(luò)等。1.3.5前提條件具備分析問題能力具備應(yīng)用性能相關(guān)的基礎(chǔ)知識和學(xué)習(xí)能力是做應(yīng)用性能管理的基本條件之一。任何企業(yè)和團(tuán)隊(duì)有關(guān)應(yīng)用性能管理的經(jīng)歷都是由小到大、由淺入深的積累過程。我在騰訊工作時，騰訊成熟團(tuán)隊(duì)最先開展性能優(yōu)化，并不斷將優(yōu)化成果在公司內(nèi)部分享。這是我們當(dāng)時最快的學(xué)習(xí)途徑之一。由于部門和產(chǎn)品之間存在差異性，所以我通過消化其他產(chǎn)品團(tuán)隊(duì)的優(yōu)化思路和方法，結(jié)合個人的體會，總結(jié)幾個主要學(xué)習(xí)途徑如下。1公司內(nèi)部。相對大的互聯(lián)網(wǎng)企業(yè)，多部門多產(chǎn)品，有些產(chǎn)品和團(tuán)隊(duì)肯定走在最前面。從研發(fā)的技術(shù)發(fā)展通道看，前端技術(shù)方向肯定會涉及性能優(yōu)化。因?yàn)榍岸素?fù)責(zé)看得見摸得著的產(chǎn)品構(gòu)建，直接產(chǎn)生大部分性能問題。而在公司內(nèi)部首先找到這些部門和接口的人，安排部門之間技術(shù)交流或當(dāng)面溝通都可以快速學(xué)習(xí)。2專業(yè)大會。當(dāng)前是用戶至上的時代，各公司或多或少都有不少性能管理的實(shí)踐，在各種大會上都能看到相關(guān)的分享，這些都是學(xué)習(xí)的途徑。例如Velocity大會的主題就是性能，InfoQ上也有很多與性能相關(guān)的采訪和文章。3多認(rèn)識牛人。無論是國內(nèi)或國外公司都有這個方向的牛人。而性能優(yōu)化本身是互聯(lián)網(wǎng)技術(shù)體系里的“上乘武功”。往往這些牛人都可以通過朋友介紹或在微博、微信上找到，也可以通過各種大會認(rèn)識，而且這些牛人多數(shù)都有在網(wǎng)站寫博客等習(xí)慣，這些都是學(xué)習(xí)和交流的突破口，如果問題較多可以整理出來集中約時間或郵件交流。爭取領(lǐng)導(dǎo)和同事支持首先可以肯定的是，所有領(lǐng)導(dǎo)在用戶體驗(yàn)和應(yīng)用性能上都是愿意投入時間和人力的，只是需要引導(dǎo)領(lǐng)導(dǎo)去正視現(xiàn)在的問題及排期。其次，每個產(chǎn)品團(tuán)隊(duì)的構(gòu)成和長短各不相同。有些團(tuán)隊(duì)的負(fù)責(zé)人是產(chǎn)品出身，有些是研發(fā)出身，有些甚至是銷售出身等，這些都需要通過對應(yīng)的側(cè)面去引導(dǎo)。此外，還存在一種情況是領(lǐng)導(dǎo)需要更多的數(shù)據(jù)做支撐，需要說服相關(guān)的同事配合去做一些問題的驗(yàn)證，做出幾個收益來輔助說明。最理想的狀態(tài)是讓領(lǐng)導(dǎo)親自搖旗吶喊，落實(shí)充足預(yù)算，與獎金掛鉤。舉個例子，阿里有個產(chǎn)品團(tuán)隊(duì)就與總裁級別的領(lǐng)導(dǎo)對賭過應(yīng)用性能，即設(shè)定速度KPI，如果完不成KPI當(dāng)年考核最低檔，當(dāng)然如若完成KPI獎金很豐厚。多了解公司內(nèi)外資源性能優(yōu)化要想做得深入，需要建立一整套監(jiān)測、分析、優(yōu)化平臺，特別是監(jiān)測平臺。而很多團(tuán)隊(duì)初期往往是從零開始的，一方面需要借助公司其他團(tuán)隊(duì)和公共團(tuán)隊(duì)的相關(guān)平臺來拿到數(shù)據(jù)，才能將數(shù)據(jù)二次加工集中到自有平臺。除了相對監(jiān)測起點(diǎn)較高外，優(yōu)化的資源更容易獲取，例如網(wǎng)絡(luò)、硬件可以預(yù)算采購、人力可以協(xié)調(diào)排期、公共的基礎(chǔ)平臺可以溝通接入等。另一方面，也就是公司外的資源，主要是通過找到優(yōu)秀的基礎(chǔ)云平臺，并將這些云平臺的技術(shù)人員也吸納進(jìn)來共同達(dá)成目標(biāo)。1.3.6組織形式多數(shù)互聯(lián)網(wǎng)產(chǎn)品團(tuán)隊(duì)往往因新產(chǎn)品功能和迭代而忽視應(yīng)用性能，但當(dāng)應(yīng)用性能的問題積累到臨界點(diǎn)后，會毫不留情地以影響產(chǎn)品體驗(yàn)的方式體現(xiàn)在產(chǎn)品的使用過程中，從而對產(chǎn)品的總體價(jià)值產(chǎn)生負(fù)面影響。而要平衡這個臨界點(diǎn)是需要具備一套完整的應(yīng)用性能監(jiān)測與分析平臺，這些工具平臺的建立需要時間和不斷調(diào)優(yōu)。所以優(yōu)秀的企業(yè)會招聘專職的性能優(yōu)化工程師來搭建監(jiān)測平臺和分析應(yīng)用的性能，從而幫助企業(yè)多個產(chǎn)品團(tuán)隊(duì)可持續(xù)優(yōu)化。這些性能優(yōu)化團(tuán)隊(duì)與產(chǎn)品團(tuán)隊(duì)是可平行發(fā)展的，甚至可以理解為內(nèi)部的甲乙方關(guān)系，這是常見的企業(yè)級應(yīng)用性能管理的組織形式。虛擬團(tuán)隊(duì)組織保障是非常有必要的。正所謂聞道有先后，術(shù)業(yè)有專攻。產(chǎn)品線RD＼FE＼QA＼OP團(tuán)隊(duì)主要精力集中在生產(chǎn)和維護(hù)產(chǎn)品上，而性能優(yōu)化團(tuán)隊(duì)的主要職責(zé)是在系統(tǒng)化的性能分析與優(yōu)化上。實(shí)際情況是，性能優(yōu)化工程師綜合能力和技術(shù)等級越高，產(chǎn)品線團(tuán)隊(duì)與性能優(yōu)化團(tuán)隊(duì)兩者則更能完美互補(bǔ)。在一定時間段內(nèi)，兩個團(tuán)隊(duì)需要組成一個虛擬團(tuán)隊(duì)并設(shè)定一個性能優(yōu)化目標(biāo)。例如在騰訊做門戶性能優(yōu)化時，我們會持續(xù)對比三大傳統(tǒng)門戶網(wǎng)站的速度，優(yōu)化前排名第4，經(jīng)過優(yōu)化后完全反超競爭對手。在百度PC搜索、移動搜索也是類似的形式，最后經(jīng)過虛擬團(tuán)隊(duì)的協(xié)調(diào)和持續(xù)優(yōu)化，最終全面反超競品。值得一提的是，也可將第三方相關(guān)團(tuán)隊(duì)納入到虛擬團(tuán)隊(duì)中。例如第三方CDN、APM、TCP加速服務(wù)商等。特別是在中小企業(yè)內(nèi)部人力有限的情況下，第三方的人力是非常好的補(bǔ)充，而且他們經(jīng)驗(yàn)豐富，服務(wù)和配合能力較強(qiáng)。通過第三方團(tuán)隊(duì)可以了解業(yè)務(wù)，并借助其曾經(jīng)幫助過的其他企業(yè)實(shí)踐過的優(yōu)秀經(jīng)驗(yàn)，直接轉(zhuǎn)化為提高自身企業(yè)應(yīng)用性能優(yōu)化效益。資源古人云“巧婦難為無米之炊”。其實(shí)也有這層意思，這里說的資源主要指非人力因素，專用于支撐應(yīng)用性能改善的資源。例如網(wǎng)絡(luò)資源IDC\CDN\BGP\TDO、內(nèi)部或外部高性能云平臺等。這些資源之間需要提前協(xié)調(diào)，在不同的階段要溝通好到位的時間。如果過早就緒會直接導(dǎo)致閑置、浪費(fèi)成本。舉個例子，如果在Q2需要使用100臺全新服務(wù)器，而在Q1就已經(jīng)全部上架，將導(dǎo)致90天的機(jī)架租用成本、電費(fèi)及服務(wù)器折舊。平臺這里的平臺主要指應(yīng)用性能的監(jiān)測、分析、優(yōu)化平臺。其中監(jiān)測權(quán)重最大，前期性能監(jiān)測不到位或監(jiān)測不完整都會讓性能優(yōu)化失真，甚至是偏離方向。后期則需要持續(xù)監(jiān)測應(yīng)用的性能并保持性能優(yōu)化的成果。監(jiān)測按大的分類主要可以分為PC、移動、國際化等，例如移動監(jiān)測又細(xì)分為WebApp、NativeApp（iOS\Android）監(jiān)測，其中PC監(jiān)測范疇最廣。主要分為PC和移動真機(jī)監(jiān)測、PC和移動JS監(jiān)測、網(wǎng)絡(luò)監(jiān)測、可用性監(jiān)測、流媒體監(jiān)測、應(yīng)用監(jiān)測等。監(jiān)測是應(yīng)用性能管理的“眼睛”?？梢哉f如果沒有監(jiān)測平臺，一切性能優(yōu)化都將失去度量，更無法發(fā)覺性能問題。筆者之前在百度負(fù)責(zé)UAQ性能優(yōu)化團(tuán)隊(duì)，結(jié)合個人體會，給出如圖1-4所示的企業(yè)級性能優(yōu)化組織形式。圖1-4百度優(yōu)化團(tuán)隊(duì)組織形式1.4如何正確開始應(yīng)用性能管理三部曲性能問題是實(shí)時發(fā)生的，并且會像人生病一樣反復(fù)出現(xiàn)。對于互聯(lián)網(wǎng)企業(yè)或產(chǎn)品負(fù)責(zé)人，需要持續(xù)地關(guān)注應(yīng)用性能，并不斷進(jìn)行改進(jìn)。而面臨的最大問題是如何正確地開始，少走彎路?？v觀國內(nèi)外多個優(yōu)秀企業(yè)的性能優(yōu)化團(tuán)隊(duì)沉淀，和自己在騰訊、百度的實(shí)踐，個人認(rèn)為性能優(yōu)化主要圍繞監(jiān)測、分析、優(yōu)化三個核心循環(huán)。第一步，監(jiān)測最是關(guān)鍵。監(jiān)測好比掌握應(yīng)用性能的“眼睛”?？杀M管萬事開頭難，但良好的開端即是成功的一半。所以我認(rèn)為前期的最主要精力應(yīng)該放在監(jiān)測上，監(jiān)測對象、如何監(jiān)測、監(jiān)測數(shù)據(jù)如何分析、如何定位故障并優(yōu)化等問題都會在后面的章節(jié)詳細(xì)闡述。應(yīng)用性能管理的三步如圖1-5所示。1監(jiān)測。通過監(jiān)測產(chǎn)品及競爭對手在各終端、各產(chǎn)品形態(tài)下的性能，例如PC、手機(jī)、平板終端及操作系統(tǒng)、網(wǎng)絡(luò)、應(yīng)用等，全面評估自身及競爭者的表現(xiàn)，并迅速定位故障及排錯。2分析。通過標(biāo)準(zhǔn)來評估網(wǎng)頁/應(yīng)用/網(wǎng)絡(luò)IDC、ISP、CDN等性能，為優(yōu)化及資源投入提供依據(jù)，為優(yōu)化效果提供衡量，提供性能及故障預(yù)警、報(bào)警。3優(yōu)化。通過網(wǎng)絡(luò)、系統(tǒng)、前端、應(yīng)用等各層進(jìn)行體系優(yōu)化，以將產(chǎn)品網(wǎng)頁速度優(yōu)化提升至業(yè)界最快為目標(biāo)，進(jìn)而提高用戶忠誠度、購買意愿、品牌價(jià)值等。圖1-5應(yīng)用性能管理的三步如何正確開始1部署監(jiān)控。前期最重要的是部署監(jiān)控，無論自有監(jiān)測平臺還是第三方監(jiān)測，必須在實(shí)際進(jìn)行優(yōu)化前完成。因?yàn)槿绻麤]有對比測試，就無法證明優(yōu)化效果。只有通過監(jiān)控平臺獲取到競品及網(wǎng)絡(luò)相關(guān)的數(shù)據(jù)，才對確定優(yōu)化方案具有參考價(jià)值。2查找瓶頸。接下來對于這些監(jiān)測對象和數(shù)據(jù)，需要分析出影響性能的瓶頸在哪？有哪些方面需要不斷調(diào)整或深入監(jiān)測？這一階段的主要工作是搜集各種相關(guān)信息，方便接下來制定優(yōu)化方案。3確定方案。完成瓶頸查找后的下一步是確定優(yōu)化方案。通過分析之前收集到的各種數(shù)據(jù)來進(jìn)行判斷，并完成需要發(fā)起性能優(yōu)化的討論及確定人力、資源投入的統(tǒng)籌。4優(yōu)化實(shí)施。這一步主要指優(yōu)化方案的實(shí)現(xiàn)過程。例如研發(fā)從前端、后端、移動端進(jìn)行全方位的代碼和邏輯優(yōu)化及硬件、網(wǎng)絡(luò)升級等。由于某些優(yōu)化會導(dǎo)致一些關(guān)聯(lián)的問題發(fā)生，需要做好前期的溝通和充分的論證。而核心產(chǎn)品需要單獨(dú)搭建線下測試環(huán)境，經(jīng)充分測試沒有問題后，在上線過程中還可以灰度做A/B測試，通過監(jiān)測真實(shí)用戶的數(shù)據(jù)，選擇最優(yōu)方案。5跟蹤反饋。持續(xù)反饋也是非常重要的工作，性能優(yōu)化是一個繁雜的系統(tǒng)工程，除了參與人和優(yōu)化項(xiàng)多以外，有些優(yōu)化是需要長時間持續(xù)優(yōu)化的。并需要進(jìn)一步建立周會或報(bào)告機(jī)制，需要指定各方向的負(fù)責(zé)人來跟蹤并反饋。另外，除了以上基本步驟以外，一些有助于正確地進(jìn)行性能優(yōu)化的思路分享如下：1初期以探索為主，不急于優(yōu)化。主要以找短板，搭建監(jiān)測平臺，掌握數(shù)據(jù)為主。中后期迭代過程中在穩(wěn)定的前提下以重點(diǎn)優(yōu)化核心產(chǎn)品為主。2從視覺感受和數(shù)據(jù)監(jiān)測上同時分析問題。在數(shù)據(jù)的基礎(chǔ)上設(shè)定優(yōu)化目標(biāo)，從一開始就需要準(zhǔn)備穩(wěn)定可靠的長期應(yīng)用性能監(jiān)控機(jī)制。3與關(guān)聯(lián)的產(chǎn)品線提前接觸。從設(shè)計(jì)優(yōu)化方案到優(yōu)化上線全程邀請他們一起參與，提前準(zhǔn)備好應(yīng)急方案。1.5投入與收益平衡做好長期投入的準(zhǔn)備無論應(yīng)用性能管理生命周期中的監(jiān)測還是優(yōu)化，都需要投入資源才有產(chǎn)出。例如人力、服務(wù)器（包含硬件）、機(jī)架、IDC\CDN帶寬等。這些資源投入只要有科學(xué)的監(jiān)測數(shù)據(jù)來衡量引導(dǎo)，肯定會有收益，只是收益的大小和質(zhì)量不同而已。事實(shí)上，往往在性能優(yōu)化立項(xiàng)之初，我們只需知道要達(dá)到的總目標(biāo)，例如80%的用戶加載時間<2s。但要達(dá)到這個目標(biāo)不可能一蹴而就，需要分期分階段完成，特別是在大型互聯(lián)網(wǎng)企業(yè)周期更長。例如我在騰訊做門戶性能優(yōu)化時，一共花費(fèi)2年時間歷經(jīng)3期；在百度做搜索性能優(yōu)化時，共耗時3年。所以需要從一開始決策投入與收益，基本原則如下。1抓住主要矛盾，制定性價(jià)比最高方案、讓收益最大者先行。通常立項(xiàng)時已經(jīng)能夠大致分析有多少改進(jìn)空間，這些改進(jìn)空間需要什么樣的資源。例如使用CDN，將舊業(yè)務(wù)遷移至高性能公共平臺等。需要將最容易落地、最容易出收益的先做，通常系統(tǒng)層、網(wǎng)絡(luò)層的優(yōu)化最容易出成果，受益面最廣，而且是一勞永逸。2聯(lián)合到所有相關(guān)的人并協(xié)商好時間并行。例如前端工程師、移動工程師、運(yùn)維工程師可以并行，也可單獨(dú)進(jìn)行優(yōu)化，優(yōu)化上線時也可以約定好時間共同上線，合并收益。也可以分前端、后端、移動端、網(wǎng)絡(luò)端等同時進(jìn)行。總之，靈活機(jī)動，合理分配。3提前協(xié)調(diào)資源，特別是貴資源。例如IDC、服務(wù)器，至少需要提前半年做預(yù)算，并最終通過發(fā)起采購、生產(chǎn)、物流、上架、配置環(huán)境和應(yīng)用等一系列復(fù)雜的流程才能落地使用。人的時間也是需要提前協(xié)調(diào)的，特別是部門的高工或架構(gòu)師，基本全年都排滿了，多數(shù)情況下需要BOSS特批才能騰挪出有限的時間。還有一種常見的做法是借，借機(jī)器、借人，都需要上層領(lǐng)導(dǎo)的足夠支持。應(yīng)用性能優(yōu)化VS成本優(yōu)化首先明確一點(diǎn)，性能優(yōu)化最大的收益是改善用戶體驗(yàn)，增加產(chǎn)品的口碑和商業(yè)價(jià)值，且同時還存在另一種極為重要的收益，即運(yùn)營成本收益。結(jié)合我在騰訊、百度參與了大量的產(chǎn)品性能優(yōu)化項(xiàng)目經(jīng)歷之見，由于系統(tǒng)總會有歷史包袱，初期隨便抓一個產(chǎn)品，分析后總能看到或多或少的性能問題，可隨著優(yōu)化工作的進(jìn)展，越到后面，優(yōu)化的工作慢慢變少，保持和維護(hù)優(yōu)化之后的性能慢慢成為主要工作。我在眾多性能優(yōu)化實(shí)踐中得到的經(jīng)驗(yàn)是，應(yīng)用性能管理的初期，優(yōu)化空間最大、優(yōu)化收益最容易體現(xiàn)。這里的優(yōu)化空間往往還包含大量的運(yùn)營成本減少，性能優(yōu)化與成本優(yōu)化通常在優(yōu)化前期是能夠兩者兼得的，而優(yōu)化后期優(yōu)化空間和難度越來越大是需要用成本換速度的，兩部分的關(guān)聯(lián)如圖1-6所示。圖1-6性能與成本優(yōu)化示意圖性能優(yōu)化伴隨大量的頁面和應(yīng)用性能提升，而內(nèi)容瘦身、業(yè)務(wù)合并會直接降低帶寬成本和服務(wù)器投入。恰逢這兩種成本是互聯(lián)網(wǎng)企業(yè)運(yùn)營成本主要構(gòu)成，性能優(yōu)化通常伴隨以下成本減少。1內(nèi)容瘦身和大量使用全國CDN，減少、北上廣中心IDC帶寬和服務(wù)器使用，降低帶寬、機(jī)架、服務(wù)器成本。2提升后端模塊性能和遷移規(guī)模化的高性能集群，從而降低資源消耗，提高資源利用率，合理冗余以抵御災(zāi)難。3通過服務(wù)器性能優(yōu)化和管理，讓資源管理透明化，預(yù)算估計(jì)更規(guī)范化，以減少不必要的資源閑置和浪費(fèi)。1.6優(yōu)秀企業(yè)的經(jīng)驗(yàn)國際一流互聯(lián)網(wǎng)企業(yè)（Google、Facebook、Yahoo！等）1性能管理方法論的先驅(qū)，并成立獨(dú)立的性能優(yōu)化團(tuán)隊(duì)，將性能優(yōu)化發(fā)揮到極致。2開源和沉淀了大量性能管理原則、工具、流程。其中，Google將性能作為網(wǎng)站檢索的重要權(quán)重。3性能優(yōu)化領(lǐng)域最專業(yè)的Velocity大會，每年為業(yè)界分享最新、最前沿的性能優(yōu)化相關(guān)成果。4Yahoo！有專業(yè)的性能管理團(tuán)隊(duì)，并對外產(chǎn)出工具和指南，例如Yslow。5Google有專業(yè)的性能管理團(tuán)隊(duì)，并對外產(chǎn)出工具和指南，例如webpagetest/pagespeed/SPDY。6Facebook有專業(yè)的性能管理團(tuán)隊(duì)，建立大量應(yīng)用性能數(shù)據(jù)統(tǒng)計(jì)和分析模型。國內(nèi)一線互聯(lián)網(wǎng)企業(yè)（騰訊、阿里、百度等）1緊跟國際先行者，針對自身特性進(jìn)行大量性能優(yōu)化實(shí)踐，并不斷總結(jié)、完善。2騰訊從2007年就開始進(jìn)行大規(guī)模用戶體驗(yàn)優(yōu)化。百度、阿里在2010年開始將性能管理體系化。3公司級性能監(jiān)測、優(yōu)化團(tuán)隊(duì)隨著逐年性能優(yōu)化不斷深入，并形成具有中國互聯(lián)網(wǎng)特色的完整性能管理方法論。國內(nèi)二三線互聯(lián)網(wǎng)企業(yè)（新浪、攜程、美團(tuán)、58同城等）1近年開始進(jìn)行性能優(yōu)化實(shí)踐，并取得重大收獲，性能提高20%~50%。2逐漸深入到研發(fā)、測試、發(fā)布等產(chǎn)品生命周期，在性能上不斷領(lǐng)先競爭對手。3性能優(yōu)化相關(guān)體系日漸完善，并不斷將性能優(yōu)化成果在各主題大會上分享。筆者有幸在百度負(fù)責(zé)過用戶訪問質(zhì)量UAQ（Useraccessquality）團(tuán)隊(duì)。團(tuán)隊(duì)定位主要是負(fù)責(zé)百度產(chǎn)品應(yīng)用性能管理與優(yōu)化，通過建立用戶訪問質(zhì)量監(jiān)測平臺，提供百度產(chǎn)品及競品訪問質(zhì)量一對一的監(jiān)測、分析、優(yōu)化服務(wù)，進(jìn)而建立可持續(xù)的用戶質(zhì)量分析、評估體系和優(yōu)化最佳實(shí)踐。主要通過內(nèi)容和應(yīng)用、網(wǎng)絡(luò)、系統(tǒng)層等優(yōu)化，達(dá)到提升用戶體驗(yàn)和產(chǎn)品價(jià)值的目標(biāo)。團(tuán)隊(duì)工作覆蓋百度33個產(chǎn)品線，監(jiān)測1200個任務(wù)，1~2重要級的產(chǎn)品線覆蓋率為93%，輸出300+份評測報(bào)告，全力配合百度14條核心產(chǎn)品線性能優(yōu)化，性能管理的形式如圖1-7所示。圖1-7百度應(yīng)用性能管理實(shí)踐第2部分監(jiān)測、工具篇第2章應(yīng)用性能監(jiān)測實(shí)踐

第3章性能監(jiān)測工具介紹

第4章性能監(jiān)測平臺搭建實(shí)踐第2章應(yīng)用性能監(jiān)測實(shí)踐2.1應(yīng)用性能監(jiān)測概述在現(xiàn)代市場上，無論是傳統(tǒng)互聯(lián)網(wǎng)企業(yè)，還是新型互聯(lián)網(wǎng)企業(yè)都是由運(yùn)行他們的業(yè)務(wù)軟件產(chǎn)品定義價(jià)值，進(jìn)而產(chǎn)生營收。也就是說產(chǎn)品的用戶體驗(yàn)將直接影響企業(yè)的收入和口碑。由此可見，企業(yè)的使命不再是簡單地建設(shè)一個網(wǎng)站或制作一個移動應(yīng)用程序，然后讓它們運(yùn)行。而是需要一個完整、智能的監(jiān)測體系進(jìn)行應(yīng)用性能管理，致力于時刻保持最佳用戶體驗(yàn)。一般大型互聯(lián)網(wǎng)企業(yè)都有專業(yè)團(tuán)隊(duì)或搭建專業(yè)平臺來負(fù)責(zé)此項(xiàng)工作。而在云時代，產(chǎn)品團(tuán)隊(duì)更迫切需要一個體系完整的應(yīng)用性能監(jiān)測平臺，使得任何“風(fēng)吹草動”都逃不出我們的手掌心。這個應(yīng)用性能監(jiān)測平臺不僅要能夠全方位監(jiān)測性能數(shù)據(jù)，而且還需要具備科學(xué)、合理的數(shù)據(jù)分析能力。也就是說，應(yīng)用性能監(jiān)測平臺會成為我們的眼、腦和手。首先它是我們的“眼睛”，幫我們7×24小時掌握整個系統(tǒng)的健康狀況；其次它是我們的“腦”，能夠根據(jù)歷史的數(shù)據(jù)和策略庫快速診斷并定位問題；最后它還是我們的“手”，協(xié)助我們快速進(jìn)行排障和性能優(yōu)化。監(jiān)測什么數(shù)據(jù)應(yīng)用性能監(jiān)測平臺是對應(yīng)用性能數(shù)據(jù)進(jìn)行分析和展現(xiàn)的平臺。它可以用來查看頁面性能的各種關(guān)鍵數(shù)據(jù)，并發(fā)現(xiàn)其中存在的問題。應(yīng)用性能監(jiān)測平臺也通過跟蹤頁面性能變化的歷史，了解功能升級對性能的影響，它甚至具備能夠自動發(fā)現(xiàn)頁面中出現(xiàn)的性能問題，并及時通知相應(yīng)人員等多種功能。應(yīng)用性能監(jiān)測到的數(shù)據(jù)主要如表2-1所示。表2-1應(yīng)用性能監(jiān)測類型應(yīng)用性能監(jiān)測實(shí)現(xiàn)步驟1采集數(shù)據(jù)。應(yīng)用性能的發(fā)生是無時不在的，并且一旦發(fā)生就會一直存在。一旦不及時處理，多個性能問題會彼此疊加放大，甚至在整個產(chǎn)品的生命周期的不同階段也會產(chǎn)生不同規(guī)模的性能瓶頸。所以說性能數(shù)據(jù)采集是第一步，并且數(shù)據(jù)采集不僅需要完整全面，也應(yīng)當(dāng)隨著產(chǎn)品生命周期不同階段變化而變化。例如初期只需要關(guān)注基礎(chǔ)的網(wǎng)絡(luò)性能、系統(tǒng)性能、應(yīng)用性能即可。而隨著產(chǎn)品的發(fā)展和演變，需要逐步加強(qiáng)，在原來的基礎(chǔ)上對多終端真實(shí)用戶性能、代碼性能、數(shù)據(jù)庫性能等方面的全面管理和優(yōu)化。數(shù)據(jù)采集中后期，在研發(fā)和架構(gòu)團(tuán)隊(duì)的配合下還需要采集所有基礎(chǔ)架構(gòu)及關(guān)聯(lián)關(guān)系的性能數(shù)據(jù)?？偠灾?，在采集階段需要最廣泛地采集適合于在開發(fā)、測試、運(yùn)維等生產(chǎn)環(huán)境中運(yùn)行的一切性能數(shù)據(jù)。應(yīng)用性能監(jiān)測各渠道分析如表2-2所示。表2-2應(yīng)用性能監(jiān)測渠道分析表2分析數(shù)據(jù)。數(shù)據(jù)分析是指將采集到所有維度的有價(jià)值的數(shù)據(jù)提煉并按有利于發(fā)現(xiàn)問題的方式進(jìn)行可視化的過程。這個過程是持續(xù)的、多樣的，是承上啟下最關(guān)鍵的一步，同時也是最有挑戰(zhàn)的一個階段。這個階段的成功與否取決于團(tuán)隊(duì)對整體應(yīng)用性能的認(rèn)識和實(shí)踐。也就是說，優(yōu)秀成熟的團(tuán)隊(duì)知道需要分析哪些性能數(shù)據(jù)，進(jìn)而引導(dǎo)監(jiān)測方式的落地和深入，從而論證性能優(yōu)化的方向和收益。3形成決策。決策是經(jīng)過采集數(shù)據(jù)和分析數(shù)據(jù)之后，在變化的生產(chǎn)環(huán)境中自上而下地觀察業(yè)務(wù)的性能影響，并且能夠快速解決應(yīng)用瓶頸，從而提高應(yīng)用性能和用戶體驗(yàn)。最終這些二次或歷經(jīng)多次性能優(yōu)化過的收益將由采集的性能數(shù)據(jù)趨勢變化來衡量，進(jìn)而循環(huán)，致力于將產(chǎn)品用戶體驗(yàn)優(yōu)化到最佳狀態(tài)。應(yīng)用性能監(jiān)測模式按用戶觸發(fā)主要分為主動與被動監(jiān)測。1主動監(jiān)測。即不依賴真實(shí)用戶訪問，通過抽樣用戶或IDC環(huán)境，主動訪問或模擬訪問服務(wù)，得到各維度應(yīng)用性能數(shù)據(jù)。這類監(jiān)測是屬于較小抽樣監(jiān)測，失真度較大，主要用來判斷基本的應(yīng)用性能狀態(tài)。如果我們用人的健康來幫助理解，也就是說主動監(jiān)測只能拿到較粗獷的生命體征狀態(tài)，例如是否生病，而監(jiān)測不到生什么病。而且監(jiān)測頻率是人為指定的，例如可用性監(jiān)測，PC真機(jī)監(jiān)測等，這類監(jiān)測好處是不需要對產(chǎn)品做額外的嵌碼或產(chǎn)生干擾。2被動監(jiān)測。主要指真實(shí)用戶在使用產(chǎn)品過程中產(chǎn)生的應(yīng)用性能數(shù)據(jù)，并觸發(fā)監(jiān)測采集規(guī)則，將數(shù)據(jù)返回?cái)?shù)據(jù)中心，這類數(shù)據(jù)最真實(shí)，而且抽樣率可以人為控制，多少都可以指定，真實(shí)用戶數(shù)據(jù)抽樣率越大，數(shù)據(jù)越接近真實(shí)用戶體驗(yàn)。例如移動SDK監(jiān)測，所有JS類監(jiān)測都是被動監(jiān)測，往往這類監(jiān)測會需要對產(chǎn)品做額外的嵌碼并產(chǎn)生少量干擾。從日志中分析用戶性能也屬于被動監(jiān)測，日志分析受日志規(guī)模和分析能力影響，時效性較難保障。平臺需要開放性和可擴(kuò)展即使有能力搭建公司級或部門級專業(yè)應(yīng)用性能平臺的團(tuán)隊(duì)，也無法同時滿足公司所有產(chǎn)品和團(tuán)隊(duì)的需求，包括第三方廠商。事實(shí)上，時間和精力也不允許。例如游戲與社區(qū)產(chǎn)品的屬性是完全不同的，電商與資訊行業(yè)側(cè)重也是不一樣的。所以要將我們搭建的應(yīng)用性能平臺最大化收益，讓最多的業(yè)務(wù)和人使用，就必須具備開放性。開放的過程中自然需要穩(wěn)定和可擴(kuò)展，方便其他業(yè)務(wù)團(tuán)隊(duì)和研發(fā)從平臺中提取對他們自己業(yè)務(wù)系統(tǒng)有意義的數(shù)據(jù)并植入到自己團(tuán)隊(duì)的業(yè)務(wù)平臺，通常需要將采集、分析、告警等模塊做成通用API，可以隨時、無門檻調(diào)用，隨時使用。2.2應(yīng)用性能持續(xù)監(jiān)測產(chǎn)品的生命周期是隨時變化的，而且往往會越來越復(fù)雜。結(jié)合本人在騰訊、百度多年工作經(jīng)歷來看，工作過的部門產(chǎn)品均沒有小于100個，而每個產(chǎn)品對應(yīng)的服務(wù)器數(shù)百到數(shù)千不等，對應(yīng)的模塊就更多了。例如百度單監(jiān)控的對象已經(jīng)超過了10萬，每天監(jiān)測到的原始日志數(shù)據(jù)達(dá)到數(shù)百TB，而且這些產(chǎn)品大部分都是成長型產(chǎn)品，只有部分產(chǎn)品上線跨度大的慢慢趨于穩(wěn)定。無論研發(fā)還是運(yùn)維都需要通過貫穿產(chǎn)品的不同階段、不同層次、不同維度建立一整套應(yīng)用性能管理平臺，才能駕馭復(fù)雜、龐大的多產(chǎn)品業(yè)務(wù)系統(tǒng)，使其能快速、穩(wěn)定地運(yùn)行并保持最佳用戶體驗(yàn)。持續(xù)監(jiān)測的基本特性往往這樣的應(yīng)用性能管理平臺是持續(xù)性的，并且覆蓋整個產(chǎn)品成長過程及所有環(huán)節(jié)，伴隨產(chǎn)品的迭代不斷完善。還可以肯定的是，每一家企業(yè)因業(yè)務(wù)特性、企業(yè)文化和團(tuán)隊(duì)基因不同，對應(yīng)用性能管理的追求是不一樣的，但基本框架都類似：主要以持續(xù)監(jiān)測為主，重點(diǎn)以用戶客戶端性能為核心的移動、PC監(jiān)測體系及以服務(wù)端為核心的系統(tǒng)、網(wǎng)絡(luò)、應(yīng)用等監(jiān)測體系?？傮w要求是監(jiān)測產(chǎn)品所有應(yīng)用場景性能，無論是互聯(lián)網(wǎng)、移動各產(chǎn)品形態(tài)，還是各終端、應(yīng)用、操作系統(tǒng)及各種網(wǎng)絡(luò)下的性能。主要滿足以下幾個特性：1覆蓋PC、移動、網(wǎng)絡(luò)、系統(tǒng)、應(yīng)用最完整的應(yīng)用性能管理，適用于應(yīng)用研發(fā)、測試和交付運(yùn)維的整個生命周期，并支持SaaS化。2主動、被動監(jiān)測最終用戶應(yīng)用性能及可用性。深入了解真實(shí)用戶的行為，以便快速而有針對性地解決問題，并最終提升用戶體驗(yàn)。3提高可見性就等于改進(jìn)應(yīng)用，提供數(shù)十種移動、操作系統(tǒng)、應(yīng)用、公有云等應(yīng)用性能解決方案，統(tǒng)一視圖幫助一覽整體性能狀態(tài)。4定制和交付最終用戶視角衡量業(yè)務(wù)應(yīng)用性能監(jiān)測體系，所有維度數(shù)據(jù)可以集成匯聚到企業(yè)系統(tǒng)，洞悉用戶性能全局。持續(xù)監(jiān)測分類應(yīng)用性能監(jiān)測主要以持續(xù)監(jiān)測為主，覆蓋范圍最廣，周期最長。7×24小時不間斷監(jiān)測產(chǎn)品運(yùn)行中的所有環(huán)節(jié)性能。持續(xù)監(jiān)測的數(shù)據(jù)具有趨勢性，可以跟蹤到長期的性能數(shù)據(jù)，有利于對應(yīng)用性能進(jìn)行版本迭代后的性能變化和優(yōu)化后的收益評估等。持續(xù)監(jiān)測覆蓋所有監(jiān)測維度，詳細(xì)分類如圖2-1所示，主要有以下幾類：1移動監(jiān)測，移動應(yīng)用性能監(jiān)測主要分為NativeAppSDK監(jiān)測（iOS、Android）、WebAppJS監(jiān)測、移動真機(jī)監(jiān)測三類。移動真機(jī)監(jiān)測只有大的互聯(lián)網(wǎng)企業(yè)才會搭建，即在全國分布的真實(shí)手機(jī)上持續(xù)監(jiān)測移動應(yīng)用的性能。不過，目前只有真機(jī)監(jiān)測才可以監(jiān)測競爭對手的性能，其他監(jiān)測都做不到，詳細(xì)內(nèi)容會在后面章節(jié)介紹。2PC監(jiān)測，與移動應(yīng)用對應(yīng)，泛指所有PC產(chǎn)品相關(guān)監(jiān)測，主要分為PCWeb真機(jī)監(jiān)測（網(wǎng)頁、文件）、PCJS監(jiān)測、網(wǎng)絡(luò)監(jiān)測、真機(jī)流媒體監(jiān)測、JS流媒體監(jiān)測、可用性監(jiān)測等，以上類型PC監(jiān)測所有數(shù)據(jù)均來自產(chǎn)品真實(shí)用戶。3系統(tǒng)監(jiān)測，服務(wù)器及操作系統(tǒng)性能監(jiān)測，這里要強(qiáng)調(diào)的是系統(tǒng)監(jiān)測一定要秒級，這樣才可以看到細(xì)微的系統(tǒng)級性能數(shù)據(jù)。系統(tǒng)監(jiān)測可以通過每臺服務(wù)器的監(jiān)測數(shù)據(jù)匯總IDC帶寬、業(yè)務(wù)模塊訪問量、各模塊之間的上下游數(shù)據(jù)流等數(shù)據(jù)，使用場景主要是為自有服務(wù)器、自建私有云及公有云環(huán)境，操作系統(tǒng)主要為CentOS、RedHat、Ubuntu、Windows等。4應(yīng)用監(jiān)測，主要分為語言類和第三方平臺類，語言類應(yīng)用監(jiān)測主要有Java、.NET、PHP、Node.js、Ruby、Python等監(jiān)測。第三方平臺類主要為MySQL、Redis、Tomcat、Docker等。圖2-1持續(xù)監(jiān)測分類2.2.1移動監(jiān)測移動互聯(lián)網(wǎng)大潮勢不可擋。過去這兩年，如果用一個關(guān)鍵詞來形容的話，那就是移動。它在改變一切，改變所有用戶的行為，改變技術(shù)，改變商業(yè)模式，改變眾多企業(yè)運(yùn)營的方式。在“互聯(lián)網(wǎng)+”的國策下，企業(yè)的商業(yè)價(jià)值在不斷往互聯(lián)網(wǎng)遷移，而互聯(lián)網(wǎng)的逐步演變也促使相關(guān)硬件、軟件、技術(shù)不斷更新?；ヂ?lián)網(wǎng)向移動互聯(lián)網(wǎng)轉(zhuǎn)變已經(jīng)不是趨勢，而是既成事實(shí)。移動互聯(lián)網(wǎng)相比傳統(tǒng)互聯(lián)網(wǎng)更為復(fù)雜，加上網(wǎng)絡(luò)接入、手機(jī)廠商、移動相關(guān)技術(shù)局限等眾多因素導(dǎo)致移動互聯(lián)網(wǎng)的應(yīng)用比互聯(lián)網(wǎng)更不穩(wěn)定，時常出現(xiàn)連接超時、閃退、卡頓、崩潰等問題，再加上移動用戶比互聯(lián)網(wǎng)用戶更加缺乏耐心，所以掌握移動產(chǎn)品應(yīng)用性能已經(jīng)成為產(chǎn)品、研發(fā)的重要工作，是移動互聯(lián)網(wǎng)時代做好用戶體驗(yàn)的重要一環(huán)。移動監(jiān)測分類及對比掌握移動用戶體驗(yàn)第一步是需要監(jiān)測到用戶的真實(shí)數(shù)據(jù)，目前移動監(jiān)測主要分為以下三類：1移動WebApp監(jiān)測，WebApp運(yùn)行于網(wǎng)絡(luò)和標(biāo)準(zhǔn)瀏覽器上，主要基于網(wǎng)頁技術(shù)開發(fā)實(shí)現(xiàn)特定功能的應(yīng)用?？梢岳斫鉃榫褪且粋€針對iPhone、Android優(yōu)化后的觸屏版的Web網(wǎng)站。無須安裝，依靠移動設(shè)備的瀏覽器來訪問，前端主要通過HTML或HTML5、CSS3、JavaScript等Web技術(shù)開發(fā)，服務(wù)端主要通過Java、PHP等實(shí)現(xiàn)。移動WebApp監(jiān)測最好的方式是在頁面嵌入JS監(jiān)測代碼來實(shí)現(xiàn)，可以指定抽樣比例，當(dāng)移動用戶訪問應(yīng)用時，觸發(fā)JS監(jiān)測代碼并將加載過程發(fā)送回服務(wù)端。2移動NativeApp監(jiān)測，NativeApp即原生應(yīng)用，即我們通常所說的移動客戶端，是針對不同手機(jī)系統(tǒng)單獨(dú)開發(fā)的本地應(yīng)用，如需使用則要將其先行下載至手機(jī)并安裝。下載NativeApp的最常見方法是訪問應(yīng)用程序商店，如蘋果的AppStore、安卓市場、GooglePlay等。在技術(shù)實(shí)現(xiàn)上一般采用針對操作系統(tǒng)的特定語言進(jìn)行編寫，如使用Objective-C開發(fā)iOS應(yīng)用，使用Java+Android開發(fā)Android應(yīng)用。NativeApp因?yàn)槲挥谄脚_層上方，向下訪問和兼容的能力會比較好，同時支持在線或離線的消息推送或本地資源訪問，在打開速度和交互界面上更優(yōu)于WebApp。因?yàn)橥耆谑謾C(jī)操作系統(tǒng)，所以內(nèi)嵌移動SDK進(jìn)行性能監(jiān)測是最好的方式，這種SDK與NativeApp一樣也是基于原生操作系統(tǒng)，數(shù)據(jù)最完整最真實(shí)。3移動端到端真機(jī)監(jiān)測，無論是WebApp還是NativeApp都只能監(jiān)測自身產(chǎn)品的應(yīng)用性能，而不能監(jiān)測競爭對手的。所以如果需要監(jiān)測競爭對手的應(yīng)用性能，就需要在全國多地招募真實(shí)手機(jī)或通過第三方NativeApp來實(shí)現(xiàn)移動端到端的真機(jī)監(jiān)測。這類監(jiān)測主要針對WebApp，因?yàn)閃ebApp通過本地瀏覽器加載，相比NativeApp而言非常輕，數(shù)據(jù)也很穩(wěn)定。而NativeApp需要安裝，如果沒有像瀏覽器這樣的公共渲染載體，能監(jiān)測到的相對公平的性能指標(biāo)非常有限，并且較基礎(chǔ)。目前移動真機(jī)監(jiān)測只有BAT和一線互聯(lián)網(wǎng)企業(yè)才會有需求。我當(dāng)時在百度負(fù)責(zé)搭建國內(nèi)最大規(guī)模的移動真機(jī)監(jiān)測，將會在后面的章節(jié)中詳細(xì)介紹。另外，常見的移動應(yīng)用還有一類叫HybridApp，又叫混合應(yīng)用，是一種介于NativeApp、WebApp之間的App，它雖然看上去是一個NativeApp，但只是一個UIWebView，里面訪問的是一個WebApp。HybridApp實(shí)質(zhì)是偽造一個瀏覽器的apk/ipa原生程序，并運(yùn)行了一個WebAPP。HybridApp兼具“NativeApp良好用戶交互體驗(yàn)的優(yōu)勢”和“WebApp跨平臺開發(fā)的優(yōu)勢”，這類應(yīng)用需要看使用JS或SDK監(jiān)測或兩者都使用，詳細(xì)對比如表2-3所示。表2-3移動產(chǎn)品形態(tài)及優(yōu)劣分析移動監(jiān)測基本目標(biāo)1為各產(chǎn)品團(tuán)隊(duì)提供針對移動應(yīng)用，移動WebApp、NativeApp、輕應(yīng)用、移動API等的自動評測、監(jiān)測、加速服務(wù)，幫助產(chǎn)品線解決應(yīng)用上線后性能問題的監(jiān)控與管理。2采用主動和被動不同監(jiān)測模式，獲取真實(shí)用戶訪問體驗(yàn)。通過實(shí)時、多維度分析和展現(xiàn)性能數(shù)據(jù)，及時幫助企業(yè)發(fā)現(xiàn)移動應(yīng)用使用過程中的崩潰、超時等問題。提前預(yù)防用戶流失，降低移動應(yīng)用上線后維護(hù)與迭代成本，提高用戶黏合度。3真實(shí)采集APP應(yīng)用性能，適應(yīng)于Android和iOS系統(tǒng)。監(jiān)測Android、iOS應(yīng)用執(zhí)行的每一行代碼，以及所有的請求，從響應(yīng)時間、吞吐量、網(wǎng)絡(luò)故障率、HTTP錯誤率等指標(biāo)展示APP應(yīng)用性能。4提供豐富的視圖展示，如拓?fù)洹⑷珖?省份/城市視圖、HTTP、交互、ISP、網(wǎng)絡(luò)、區(qū)間、錯誤、崩潰、設(shè)備、版本、操作系統(tǒng)等多種維度視圖，實(shí)時發(fā)現(xiàn)在用戶使用過程中的崩潰、慢交互等性能瓶頸。移動WebApp監(jiān)測2015年國內(nèi)移動Web開發(fā)需求大增，主要受益于微信的快速發(fā)展，包括用戶的增長及公眾號自媒體在營銷領(lǐng)域的滲透。2015年年底，微信的用戶量達(dá)到6億，公眾號數(shù)量突破1000萬。也就是說，在未來幾年內(nèi)，我們可以預(yù)見中小企業(yè)將大量推進(jìn)品牌公眾號運(yùn)營，外企、政府機(jī)構(gòu)將加速進(jìn)駐，同時自媒體創(chuàng)業(yè)更在蓬勃發(fā)展。微信官方在2016年年初發(fā)布“網(wǎng)頁開發(fā)者工具”，顯示出進(jìn)一步提高微信Web內(nèi)容技術(shù)含量的意圖。這些趨勢必然會吸引更多開發(fā)者進(jìn)入Web開發(fā)領(lǐng)域。在技術(shù)社區(qū)中，Google依然在繼續(xù)推廣以Chrome為容器的WebApp開發(fā)方法。從搜索趨勢看，2015年移動WebApp、混合式App依然是最受關(guān)注的熱門技術(shù)選項(xiàng)。WebApp監(jiān)測與優(yōu)化將越來越被企業(yè)和開發(fā)者重視。WebApp監(jiān)測價(jià)值及目標(biāo)1建立移動WebApp真實(shí)用戶性能監(jiān)測體系，基于JavaScript，從瀏覽器、內(nèi)嵌瀏覽器，收集真實(shí)用戶使用移動應(yīng)用時的性能數(shù)據(jù)，進(jìn)而分析真實(shí)用戶體驗(yàn)，加快對性能問題快速發(fā)現(xiàn)、定位及性能優(yōu)化的能力。2豐富的數(shù)據(jù)分析功能，有效分析不同地域、網(wǎng)絡(luò)、操作系統(tǒng)、瀏覽器、廠商上用戶使用應(yīng)用的體驗(yàn)，并且支持任務(wù)間的比對分析，協(xié)助灰度發(fā)布和測試等。3代碼級問題定位，在JS錯誤、慢頁面、資源加載失敗等問題跟蹤時，提供包括腳本文件、行數(shù)、終端環(huán)境等豐富信息，幫助精確定位和解決問題。4監(jiān)測產(chǎn)品環(huán)境下使用的第三方API和資源性能，通過在瀏覽器、內(nèi)嵌瀏覽器采集數(shù)據(jù)，既能監(jiān)測本地API、服務(wù)器端API調(diào)用狀況，也能監(jiān)測第三方API和資源服務(wù)質(zhì)量，如流量分析工具、CDN、廣告等，幫助及時發(fā)現(xiàn)第三方問題，保證產(chǎn)品可用性。5輕量級快速覆蓋多個WebApp產(chǎn)品線，充分利用各Web平臺的兼容性，用最小的工程代價(jià)，快速實(shí)現(xiàn)最大范圍和類型的應(yīng)用入口的覆蓋。既支持普通移動端瀏覽器打開的網(wǎng)頁應(yīng)用，也支持內(nèi)嵌瀏覽器打開的網(wǎng)頁應(yīng)用（如Cordova封裝的本地網(wǎng)頁）。6監(jiān)測端的可擴(kuò)展性，監(jiān)測端支持改寫指標(biāo)采集算法，用于修正特定應(yīng)用實(shí)現(xiàn)（如加載進(jìn)度指示等）的真實(shí)指標(biāo)數(shù)值，并支持自定義指標(biāo)。WebApp監(jiān)測實(shí)現(xiàn)原理JavaScript監(jiān)測腳本利用了多種現(xiàn)代瀏覽器的新特性，實(shí)現(xiàn)更高效率和更精確的指標(biāo)采集，同時保留了對流行的老版本瀏覽器的最大限度兼容和覆蓋，實(shí)現(xiàn)原理如下。1監(jiān)測端的頁面核心性能指標(biāo)收集，利用了W3C正式發(fā)布的NavigationTiming規(guī)范，達(dá)到了最精確的等級。這個規(guī)范已經(jīng)被所有的現(xiàn)代瀏覽器實(shí)現(xiàn)，能夠在所有智能手機(jī)瀏覽器中使用。通過JS監(jiān)測可以得到很多性能指標(biāo)，需要理解這些指標(biāo)項(xiàng)的真正含義，從而分析出問題所在，并做出有效的優(yōu)化。NavigationTiming記錄的所有瀏覽器事件和時序，被總結(jié)成一張順序圖，清晰地展示了瀏覽器打開一個網(wǎng)頁的大部分細(xì)節(jié)，如圖2-2所示。對于API的詳細(xì)使用方法和各個指標(biāo)的細(xì)節(jié)，在此不再贅述。圖2-2NavigationTiming監(jiān)測指標(biāo)具體的含義如表2-4所示。表2-4NavigationTiming指標(biāo)及含義2瀏覽器的JavaScriptAPI監(jiān)測，現(xiàn)代Web應(yīng)用采用了大量新的瀏覽器API，比如說Ajax請求?！氨O(jiān)測端”利用了較新的瀏覽器中Object.defineProperty接口，實(shí)現(xiàn)對大多數(shù)瀏覽器API調(diào)用的代理和監(jiān)控。這樣既不影響應(yīng)用代碼的正常運(yùn)行，同時不需要開發(fā)者為了監(jiān)測額外進(jìn)行適配。3傳統(tǒng)的時間戳收集和回傳方法，在使用現(xiàn)代瀏覽器的新特性同時，監(jiān)測JavaScript支持傳統(tǒng)實(shí)現(xiàn)中的時間戳收集方式，在“首字節(jié)時間”、“白屏?xí)r間”等指標(biāo)上達(dá)到了最大兼容性和覆蓋面。并且通過對圖片元素注冊事件監(jiān)聽，安全有效地實(shí)現(xiàn)“首屏?xí)r間”等指標(biāo)收集。在數(shù)據(jù)回傳上也根據(jù)瀏覽器環(huán)境使用多種回傳接口，確保數(shù)據(jù)在各種條件下完整高速回傳。4配置下發(fā)模塊使用CDN加速，可以允許任務(wù)管理模塊動態(tài)地更新監(jiān)測配置，并通過緩存刷新、設(shè)置過期時間等內(nèi)部API，以分鐘級速度下發(fā)大流量的配置。WebApp監(jiān)測拓?fù)淙鐖D2-3所示。圖2-3移動WebApp監(jiān)測拓?fù)鋱DWebApp監(jiān)測視圖WebApp監(jiān)測核心性能指標(biāo)有白屏?xí)r間、首屏?xí)r間、整頁時間、用戶可操作時間、首包時間、DNS時間、連接建立時間、基礎(chǔ)頁面下載時間、自定義的時間等。以上性能指標(biāo)通過全國、趨勢、省份、城市、運(yùn)營商、區(qū)間、瀏覽器、操作系統(tǒng)等視圖可視化后，提供在線性能分析功能，效果如圖2-4所示，詳細(xì)的視圖和講解說明會在本書第5章中介紹。圖2-4移動WebApp監(jiān)測視圖移動NativeApp監(jiān)測移動應(yīng)用誕生于蘋果的應(yīng)用商店AppStore，在2008年7月上線之初，APP數(shù)量只有500多個，同年10月谷歌上線的AndroidMarket僅有40多個。而截至2015年7月，前者的APP數(shù)量達(dá)到150萬，截至2015年1月，后者則已突破143萬。根據(jù)應(yīng)用數(shù)據(jù)追蹤公司AppFigures的2015最新統(tǒng)計(jì)顯示，2014年，AppStore開發(fā)者總數(shù)約為28.2萬，谷歌PlayStore的開發(fā)者總數(shù)為38.8萬。而根據(jù)《中國移動互聯(lián)網(wǎng)發(fā)展報(bào)告（2015）》統(tǒng)計(jì)顯示，中國移動應(yīng)用開發(fā)者數(shù)量超過300萬人。從APP數(shù)量和開發(fā)者人數(shù)不斷增長來看，NativeApp依舊是移動產(chǎn)品的主要形態(tài)，所以針對NativeApp監(jiān)測與優(yōu)化顯得尤為重要。NativeApp監(jiān)測價(jià)值及目標(biāo)1建立移動NativeApp真實(shí)用戶性能監(jiān)測體系，直接從終端手機(jī)提取最原始的診斷數(shù)據(jù)，采集移動APP的各項(xiàng)性能指標(biāo)，從響應(yīng)時間、網(wǎng)絡(luò)請求、數(shù)據(jù)庫、錯誤、崩潰、設(shè)備、CPU、內(nèi)存等各個角度進(jìn)行全面體檢，智能地分析數(shù)據(jù)，對應(yīng)用給出全面的評價(jià)，并給出完善建議。用戶根據(jù)評價(jià)提示可追溯到詳細(xì)信息，快速定位到問題的根源。2對HTTP請求提供詳細(xì)的數(shù)據(jù)分析，全面了解主機(jī)網(wǎng)絡(luò)性能情況，幫助產(chǎn)品線定位網(wǎng)絡(luò)性能問題，提升App在不同手機(jī)版本和操作系統(tǒng)下的響應(yīng)速度，改善App整體應(yīng)用性能。對移動應(yīng)用性能問題防患于未然，提高用戶留存率。3提供開放性API，允許添加自定義方法監(jiān)測、設(shè)置監(jiān)測級別和日志級別。根據(jù)API添加自定義的方法監(jiān)測，實(shí)現(xiàn)關(guān)鍵元素監(jiān)測分析，從自定義方法的響應(yīng)時間、自定義方法執(zhí)行時的內(nèi)存、CPU、線程狀況、方法軌跡等各個層面全面分析關(guān)鍵元素的性能狀況。4個性需求的定制化，監(jiān)測SDK整合主流的監(jiān)測功能，包括交互性能分析（基本交互分析、慢交互追蹤、線程分析、關(guān)鍵元素分析）、網(wǎng)絡(luò)監(jiān)控（基本網(wǎng)絡(luò)監(jiān)控、深層網(wǎng)絡(luò)追蹤、網(wǎng)絡(luò)錯誤分析、錯誤追蹤）、WebView監(jiān)控、多媒體監(jiān)控、Crash分析（AppCrash基本分析，Crash代碼級別追蹤）、設(shè)備及操作系統(tǒng)監(jiān)控、版本監(jiān)控、CPU/內(nèi)存性能監(jiān)控，等等。可以根據(jù)自身應(yīng)用特點(diǎn)及需求，提供對應(yīng)的配置文件，就可獲得一套量身定制的移動監(jiān)測數(shù)據(jù)。NativeApp監(jiān)測實(shí)現(xiàn)原理1iOS通過MethodSwizzling方式，Hook了常用框架的API而實(shí)現(xiàn)了監(jiān)測功能。MethodSwizzling原理（Hook原理）利用Objective-C的動態(tài)特性，實(shí)現(xiàn)在運(yùn)行時偷換selector對應(yīng)的方法實(shí)現(xiàn)（IMP），達(dá)到給方法掛鉤的目的。在Objective-C中，每個類都有一個方法列表，存放著selector的名字和方法實(shí)現(xiàn)（IMP）的映射關(guān)系。調(diào)用一個方法，其實(shí)是調(diào)用selector所對應(yīng)的實(shí)現(xiàn)方法（IMP）。因此，可以利用method_exchangeImplementations來交換2個方法中的IMP，利用class_replaceMethod來修改類，利用method_setImplementation來直接設(shè)置某個方法的IMP，從而達(dá)到Hook的目的。2Android通過Instrumentation代理及InvocationHandler動態(tài)代理類，使用ASM字節(jié)碼框架在字節(jié)碼層面Hook了android.jar中的類而實(shí)現(xiàn)監(jiān)測功能。1）Instrumentation代理，在AndroidSDK中，InstrumentationIns代理涉及兩方面，一方面是Instrumentation代理指定了agentmain作為入口方法，實(shí)現(xiàn)了在main方法之前執(zhí)行代理。另一方面是Instrumentation通過addTransformer方法加載ClassFileTransformer實(shí)現(xiàn)類，實(shí)現(xiàn)了在class被裝載到JVM之前將class字節(jié)碼轉(zhuǎn)換掉，從而達(dá)到動態(tài)注入代碼的目的。2）InvocationHandler動態(tài)代理，InvocationHandler實(shí)際上是攔截器的接口。在AndroidSDK中，InvocationHandler代理通過其實(shí)現(xiàn)方法InvocationDispatcher觸發(fā)invoke方法，在invoke方法中使用ASM字節(jié)碼框架來分別Hookandroid.jar中的annotation，activity，AsyncTask，network，sqllite，exception等類方法。3支持移動網(wǎng)絡(luò)、流媒體、崩潰、交互等性能監(jiān)測。1）網(wǎng)絡(luò)性能深度追蹤，移動SDK深入系統(tǒng)底層，監(jiān)聽了C/C++層的網(wǎng)絡(luò)通信API，獲取了網(wǎng)絡(luò)請求的DNS、TCP、SSL、數(shù)據(jù)發(fā)送、服務(wù)器響應(yīng)、數(shù)據(jù)接收等各個步驟的網(wǎng)絡(luò)交互性能數(shù)據(jù)以及詳細(xì)的網(wǎng)絡(luò)錯誤信息，幫助用戶快速定位網(wǎng)絡(luò)性能問題。2）視頻、音頻播放性能監(jiān)測，移動SDK監(jiān)測通過監(jiān)聽常用視頻、音頻播放框架，獲取視頻、音頻播放性能數(shù)據(jù)，包括開始播放時間、首次緩沖時間、緩沖次數(shù)、緩沖總時長、卡頓次數(shù)、總等待時間、下載速度、網(wǎng)絡(luò)狀況等，幫助用戶實(shí)時了解終端的播放性能情況。3）崩潰故障代碼級分析，移動SDK不僅能監(jiān)測到語言層面的崩潰，還要監(jiān)測操作系統(tǒng)層面的崩潰信號，崩潰問題定位到代碼行，歷史軌跡追蹤。iOSSDK利用PLCrashReporter開源框架，通過UncaughtExceptionHanler實(shí)現(xiàn)了對Objective-C層的崩潰信息監(jiān)聽，通過監(jiān)聽"SIGABRT"、"SIGBUS"、"SIGFPE"、"SIGILL"、"SIGSEGV"、"SIGTRAP"、"SIGTERM"、"SIGKILL"信號，捕獲unix層崩潰信息。Android通過UncaughtExceptionHanler及UncaughtSignalHanler捕獲了Java層及C++層的崩潰信息。4）交互性能跟蹤分析，移動SDK通過Hook移動框架的交互API，實(shí)時跟蹤APP運(yùn)行時的交互性能。幫助用戶了解APP在終端設(shè)備使用過程中的卡頓、反應(yīng)慢、掛起等問題。移動SDK提供慢交互追蹤功能，根據(jù)method堆棧軌跡追蹤，分析每一個交互的method堆棧的響應(yīng)時間占比，幫助用戶快速定位影響慢交互的主要因素。4支持移動主流開發(fā)模式及平臺。1）NativeAPP，從頁面加載、頁面渲染、頁面Trace、吞吐量等多個角度，度量Native頁面的交互性能。2）WebAPP，針對不同URL建立頁面Trace，記錄TCP、DNS、DOM加載、渲染等時間、服務(wù)器加載時間、網(wǎng)絡(luò)狀況等。從頁面加載、Ajax加載、頁面Trace等角度，度量HTML5頁面的交互性能。3）HybirdAPP（混合型APP），HybirdAPP是NativeAPP和WebAPP的混合模式，一般HybirdAPP采用原生語言的框架，對于內(nèi)容經(jīng)常變化、結(jié)構(gòu)簡單的頁面則用HTML5實(shí)現(xiàn)。移動SDK對于Native部分，按照NativeAPP的監(jiān)測方式監(jiān)測，HTML5部分，按照WebAPP的監(jiān)測方式進(jìn)行監(jiān)測，在前端視圖中分別展示Native交互視圖和WebView交互視圖。4）支持主流的開發(fā)平臺，AndroidSDK需要支持了Eclipse，Ant，Maven，Androidstudio四大主流開發(fā)平臺，iOSSDK支持Xcode開發(fā)平臺。NativeApp監(jiān)測拓?fù)淙鐖D2-5所示。圖2-5移動NativeApp監(jiān)測拓?fù)鋱DNativeApp監(jiān)測架構(gòu)及說明如圖2-6和表2-5所示。圖2-6移動NativeApp監(jiān)測架構(gòu)圖表2-5移動NativeApp監(jiān)測模塊及功能NativeApp監(jiān)測視圖NativeApp監(jiān)測核心性能指標(biāo)有響應(yīng)時間、請求數(shù)、傳輸大小、吞吐率、HTTP錯誤數(shù)、HTTP錯誤率、網(wǎng)絡(luò)錯誤數(shù)、網(wǎng)絡(luò)錯誤率等。以上性能指標(biāo)通過拓?fù)?、全國、HTTP、交互、崩潰、網(wǎng)絡(luò)、省份、城市、運(yùn)營商、區(qū)間、錯誤、設(shè)備、版本、操作系統(tǒng)等視圖可視化后，提供在線性能分析功能，效果如圖2-7所示，詳細(xì)的視圖和講解說明會在本書第5章中介紹。圖2-7移動NativeApp視圖移動端到端真機(jī)監(jiān)測隨著移動互聯(lián)網(wǎng)持續(xù)發(fā)展和深入，可以預(yù)見無論是現(xiàn)在還是將來，移動APP依舊是企業(yè)主要商業(yè)價(jià)值載體。而在商業(yè)競爭中，“知彼”遠(yuǎn)比“知己”重要。不過無論是移動JS監(jiān)測還是移動SDK監(jiān)測都不能監(jiān)測競爭對手性能，所以企業(yè)對WebApp、NativeApp產(chǎn)品形態(tài)的競爭對手性能監(jiān)測的需求隨移動互聯(lián)網(wǎng)演進(jìn)而越發(fā)強(qiáng)烈，移動端到端監(jiān)測應(yīng)運(yùn)而生。移動端到端監(jiān)測的所有監(jiān)測過程發(fā)生在真實(shí)手機(jī)上，監(jiān)測手機(jī)小規(guī)模數(shù)量可以部署在測試環(huán)境（多廠商、多網(wǎng)絡(luò)制式），而監(jiān)測手機(jī)大規(guī)模數(shù)量則主要通過自有移動客戶端下發(fā)或有償招募。百度性能優(yōu)化團(tuán)隊(duì)建立了一整套移動真機(jī)監(jiān)測平臺，主要對百度移動搜索等核心移動產(chǎn)品的競品進(jìn)行性能監(jiān)測。招募真實(shí)手機(jī)超過3萬臺，覆蓋33個省和港澳臺地區(qū)264個城市，同時在線1500+，日活5000+，采集樣本數(shù)10萬+/天，從用戶、地域、廠商、運(yùn)營商等維度建立了詳細(xì)的移動競品性能監(jiān)測和分析體系。另外，WebApp競品監(jiān)測因監(jiān)測過程發(fā)生在瀏覽器，相對NativeApp要簡單。移動端到端監(jiān)測拓?fù)鋱D如2-8所示。圖2-8移動端到端監(jiān)測拓?fù)鋱D2.2.2Web監(jiān)測在“互聯(lián)網(wǎng)+”的浪潮之下，不僅在互聯(lián)網(wǎng)本身這個領(lǐng)域產(chǎn)生了非常大的影響，其實(shí)也滲透到整個國民經(jīng)濟(jì)的方方面面，甚至可以毫不夸張地說，對各個行業(yè)都產(chǎn)生了非常大的影響。現(xiàn)如今，中國互聯(lián)網(wǎng)發(fā)展進(jìn)入了第二個十年，期間積累了大量的互聯(lián)網(wǎng)產(chǎn)品形態(tài)。這些不同互聯(lián)網(wǎng)領(lǐng)域經(jīng)過梳理劃分為資訊、搜索、娛樂、游戲、電商等行業(yè)。這些看似紛繁的各行各業(yè)，除了都經(jīng)歷過在互聯(lián)網(wǎng)不同階段中漫長時間的不斷演變以外，還具備一個共同點(diǎn)，它們都屬于PC時代。所以，這里討論的Web監(jiān)測主要指傳統(tǒng)PC互聯(lián)網(wǎng)及網(wǎng)絡(luò)相關(guān)的范疇，可以參考圖2-9幫助理解。Web監(jiān)測是每一個互聯(lián)網(wǎng)企業(yè)都會面臨的問題。圖2-9Web監(jiān)測拓?fù)鋱DPC端到端真機(jī)監(jiān)測通過招募真實(shí)用戶安裝PC監(jiān)測客戶端或企業(yè)自有PC產(chǎn)品客戶端進(jìn)行應(yīng)用性能監(jiān)測，監(jiān)測對象主要為網(wǎng)站/網(wǎng)頁/網(wǎng)頁元素/事物流、應(yīng)用API、IDC/CDN、服務(wù)器/云主機(jī)等。以抽樣最終用戶的視角及時發(fā)現(xiàn)在訪問過程中遇到的性能問題，通過對應(yīng)用性能及監(jiān)測數(shù)據(jù)不斷的優(yōu)化，使最終用戶獲得更優(yōu)的用戶體驗(yàn)。PC端到端真機(jī)監(jiān)測是目前唯一可以監(jiān)測競品的監(jiān)測途徑，而且是主動式、無須添加任何代碼，目前市場上第三方這類監(jiān)測廠商主要有國外的Dynatrace的前身Compuware、Keynote及國內(nèi)的基調(diào)、博睿。值得說明的是，目前國內(nèi)這種監(jiān)測也是APM行業(yè)主要的變現(xiàn)途徑。PCJS監(jiān)測前端嵌JS收集性能數(shù)據(jù)是零成本的，代價(jià)是通過前端工程師在網(wǎng)頁中嵌入JS監(jiān)測代碼，并會產(chǎn)生100~200ms左右的延時消耗，正如監(jiān)測方式一樣，這類監(jiān)測是偏網(wǎng)頁和前端的性能監(jiān)測，主要由前端工程師主導(dǎo)，而且自定義非常強(qiáng)，幾乎想監(jiān)測網(wǎng)頁中的任何元素都可以，例如白屏、首屏、全屏或網(wǎng)頁中的某一塊區(qū)域加載性能等，因?yàn)樾枰藶樘砑哟a，監(jiān)測效率較低。網(wǎng)絡(luò)監(jiān)測無論是傳統(tǒng)互聯(lián)網(wǎng)還是現(xiàn)代云時代，所有應(yīng)用和企業(yè)商業(yè)價(jià)值都依托在網(wǎng)絡(luò)之上，況且中國基礎(chǔ)網(wǎng)絡(luò)是非常特殊的，簡單來說就是有天然屏障?？梢院芸隙ǖ卣f在中國能駕馭基礎(chǔ)網(wǎng)絡(luò)的互聯(lián)網(wǎng)企業(yè)用戶體驗(yàn)一定不會差。網(wǎng)絡(luò)監(jiān)測更是每家互聯(lián)網(wǎng)企業(yè)都需要的。目前主流的且接近真實(shí)的網(wǎng)絡(luò)監(jiān)測主要是PC端到端真機(jī)監(jiān)測網(wǎng)絡(luò)延時和內(nèi)嵌JS下載不同IDC中的服務(wù)器上的文件判斷網(wǎng)絡(luò)性能?？捎眯员O(jiān)測可用性監(jiān)測有一定的歷史淵源，也是發(fā)展最早的一類監(jiān)測，主要通過一個或多個IDC向服務(wù)器、網(wǎng)頁或API發(fā)送請求，通過返回的數(shù)據(jù)判斷應(yīng)用的狀態(tài)，通常這種狀態(tài)只有可用與不可用兩種，因?yàn)檫@類監(jiān)測沒有任何真實(shí)用戶體驗(yàn)的意義，只局限于輔助快速發(fā)現(xiàn)故障從而提升用戶性能，只能判斷應(yīng)用的可用狀態(tài)，好比去敲門，如果房間里有人應(yīng)答說明房間里有人，是單純的可用性監(jiān)測，加上實(shí)現(xiàn)簡單而且在IDC的服務(wù)器上監(jiān)測，可以將監(jiān)測頻率做到秒級。流媒體監(jiān)測從主流CDN廠商超過50%的帶寬都是流媒體可以看出，流媒體行業(yè)發(fā)展的態(tài)勢是非常明顯的，有權(quán)威數(shù)據(jù)表示視頻卡頓持續(xù)7s，90%的用戶會放棄觀看該視頻，卡頓超過20s，幾乎沒有用戶繼續(xù)等下去。加上近幾年家庭數(shù)字媒體和移動視頻互動娛樂的崛起，流媒體監(jiān)測的需要越來越迫切了，目前主要通過PC端到端流媒體真機(jī)監(jiān)測和在播放器內(nèi)嵌JS代碼兩種方式實(shí)現(xiàn)，前者是完整但抽樣的流媒體用戶體驗(yàn)監(jiān)測，后者沒有網(wǎng)絡(luò)層數(shù)據(jù)但抽樣率更大并且主要監(jiān)測用戶端播放全過程的用戶體驗(yàn)。PC端到端真機(jī)監(jiān)測自從1991年全球第一個網(wǎng)站上線以來，互聯(lián)網(wǎng)經(jīng)過25年的蓬勃發(fā)展，已經(jīng)與人類日常生活息息相關(guān)。根據(jù)Netcraft發(fā)布的Web服務(wù)器調(diào)研數(shù)據(jù)顯示，截止到2015年12月，全球共有9.01億網(wǎng)站在線。在“互聯(lián)網(wǎng)+”的時代背景下，用戶體驗(yàn)是最終檢驗(yàn)企業(yè)是否成功最好的標(biāo)準(zhǔn)。而網(wǎng)站和網(wǎng)頁加載速度是決定用戶體驗(yàn)的關(guān)鍵指標(biāo)。訪問速度下降不僅帶來用戶流失，更會影響企業(yè)的業(yè)務(wù)，造成營收的損失。Radware公司公布的調(diào)研結(jié)果顯示，加載時間每提升1s，沃爾瑪官網(wǎng)的購買轉(zhuǎn)化率將提升2%。Firefox平均加載時間每減少2.2s，下載次數(shù)將提升15.4%，每年將增加預(yù)計(jì)1000萬次下載。如果汽車配件零售商AutoAnything加載時間減少一半，其銷售額將提升13%。通過有償招募的方式在真實(shí)用戶的PC、手機(jī)上安裝監(jiān)測客戶端收集性能數(shù)據(jù)是目前PC監(jiān)測中最常見，也是監(jiān)測數(shù)據(jù)最完整的監(jiān)測方式，可以通過服務(wù)端下發(fā)監(jiān)測任務(wù)到客戶端，按一定頻率主動監(jiān)測產(chǎn)品速度和體驗(yàn)，并發(fā)送到服務(wù)器進(jìn)行展現(xiàn)和分析。第三方商業(yè)公司做得較好的有g(shù)omez、keynote、基調(diào)網(wǎng)絡(luò)等公司，最大的特點(diǎn)是可以監(jiān)測競爭對手。顯然客戶端主動監(jiān)測與JS被動監(jiān)測各有利弊，相輔相成。通過本人在騰訊、百度的實(shí)踐，這兩種監(jiān)測必須具備，并建立真實(shí)用戶速度監(jiān)測體系，為速度優(yōu)化提供依據(jù)。通過客戶端監(jiān)測國內(nèi)外、各終端、各瀏覽器下各產(chǎn)品形態(tài)，在前端、網(wǎng)絡(luò)、系統(tǒng)、應(yīng)用層的性能及針對性地進(jìn)行優(yōu)化，目前百度搜索產(chǎn)品、商業(yè)產(chǎn)品經(jīng)過監(jiān)測、分析、優(yōu)化后