2016年3月26日，由企業(yè)網(wǎng)D1Net舉辦的2016互聯(lián)網(wǎng)CTO/CIO大數(shù)據(jù)沙龍在北京隆重舉行，大數(shù)據(jù)行業(yè)的大咖云集，干貨紛呈，圍繞大數(shù)據(jù)的落地應用，CTO/CIO碰撞思想和觀點，從互聯(lián)網(wǎng)企業(yè)到運營商，再到政府，它們的大數(shù)據(jù)實踐經(jīng)驗和教訓在這里匯聚。

主持人：應用性能管理是所有互聯(lián)網(wǎng)公司都會關心的話題，接下來云智慧副總裁劉志達將和我們分享這方面的思考，帶來“互聯(lián)網(wǎng)+時代的高效業(yè)務運營”，大家掌聲歡迎!

劉志達：很高興有機會跟大家一起分享一下我們云智慧全棧應用性能系統(tǒng)解決方案。在“互聯(lián)網(wǎng)+”時代，移動和社交已經(jīng)改變了我們所有人的生活，社交現(xiàn)在已經(jīng)從虛擬變成真實的一個環(huán)境，每天我們離不開微信，剛才開會的時候，大家也不斷在用微信。

隨著整個社交模式的改變和移動對人生活模式的改變，我們整個應用的商業(yè)環(huán)境也發(fā)生了改變?，F(xiàn)在有很多新興公司用互聯(lián)網(wǎng)的模式在快速發(fā)展，這些數(shù)字就不再一一陳述了。更多的是說，在這種環(huán)境背景之下，企業(yè)對應用的預期會有什么樣的一個變化。其實主要有兩點總結：一個就是變化的速度，我們看到這些企業(yè)的發(fā)展是日新月異，每年的增幅非?？?，所有的市場，產品的交付速度其實在94%。我們在談這個速度的時候，更多是針對我們應用的交付。也就是說，一個新產品在上線，到用戶手里，再到新的一次更新升級，這種迭代的速度。比如小米，小米他們其實都是以周為單位進行迭代，更極端是百度貼吧，百度貼吧現(xiàn)在大口碑并不是太好，但是以前在貼吧非?；鸬臅r候，它的迭代一次有幾次，每天有幾次，這是我們跟他們溝通了解到的。

另外一個變化就是我們操作可預期的用戶體驗。用戶體驗這部分，其實之前的幾位朋友也都提到了就是用戶體驗。現(xiàn)在大家都在關注這個話題，不僅是互聯(lián)網(wǎng)企業(yè)，因為互聯(lián)網(wǎng)企業(yè)對用戶體驗更為看中，傳統(tǒng)企業(yè)實際上也在向這個方面轉型。至少去年的世界互聯(lián)網(wǎng)大會海爾的張瑞敏就提出來海爾實際上在從一個產品經(jīng)濟時代轉向用戶體驗的體驗經(jīng)濟時代。

我們在談用戶體驗的時候，其實有兩部分，一部分其實是一些感性的東西，它其實不太容易去衡量。比如說對用戶，對一個應用，比如顏色，它的使用習慣，或者是它的功能組合，這些都跟人的個人感官有直接的影響。所以，這部分是不太可預期的。比如說像12306網(wǎng)站，眾所周知驗證碼實在是比較坑。這種驗證碼它的用戶體驗不好，實際上我們很難去衡量。但是，另外一種，我們剛才提到一些Citrix列了很多數(shù)據(jù)，用戶訪問多少秒會發(fā)生一個變化，有多少用戶流失，這種情況是一個可衡量的，因為它是一個速度，其實說白了就是速度，也就是速度是怎么體現(xiàn)出來的?是你應用的性能表現(xiàn)，所以這部分是一個可衡量的指標。所以，我們其實更關注的，目前來說從應用本身角度，我是做技術的，我們關注的還是性能本身。當然，產品設計的，或者做運營的更會關心一些行為方面的數(shù)據(jù)。

針對這樣的問題，云智慧提出的解決方案是什么?其實我們也聚焦在這兩點上，一個是用戶體驗，一個是應用的性能。我這邊有一張比較大的圖，我在這里邊會逐一的介紹。這里邊有兩個緯度，第一個是我們在這個層面從事我們叫面向產品全生命周期的持續(xù)高速，這里面從產生、運營到后期迭代，都有完整的一個交付周期。我們也提到一個新的名詞，DevOps，主要在研發(fā)領域，這個被實踐的比較多一些，但是國內真正DevOps做的比較好的還是很少的，大部分偏傳統(tǒng)，也就是產品設計完開發(fā)，DEMO寫出來交給測試，測試沒有問題送給運維，然后事情其實跟研發(fā)已經(jīng)沒有關系了，運維保證系統(tǒng)平穩(wěn)的運行。

在這樣一個過程當中解決現(xiàn)在我們所面臨的問題還是比較難的，因為我以前是做傳統(tǒng)行業(yè)，傳統(tǒng)行業(yè)在一個軟件交付周期迭代速度比較慢，半年或者一年，春季或者秋季發(fā)布，常規(guī)是這樣，給客戶做系統(tǒng)升級，基本上半年其實就算比較快的速度了，有的在一年，甚至兩年才給客戶更新一次。

對現(xiàn)在互聯(lián)網(wǎng)的應用和產品來說，在以周為單位交付的時候，這個問題就凸顯出來了。其實包括我們現(xiàn)在自己做開發(fā)的時候也會有很大的問題。我們從一個產品開發(fā)到測試到上線這個過程壓縮到一個星期，這個對開發(fā)和測試要求非常高。怎么樣保證開發(fā)和測試一個比較好的銜接，或者能融合在一起，單純從管理方面去解決是沒有太好的辦法的，因為人的工作效率在這里，整個工作職能的分配都是固定的。所以，這部分我們提供了幾個產品服務來解決它。一個就是針對移動端的自動化測試。其實這個解決什么問題呢?移動的產品有一個特點就是跟我們以前的業(yè)務不太一樣的地方，就是移動的產品其實從技術端或者客戶端，當然H5是另看了。對于應用來說是一個客戶端，我們在測試的時候很多自動化的測試手段其實有兩個問題，一個是對功能的呈現(xiàn)，另外一個移動其實存在網(wǎng)絡問題，因為我移動用戶并不是普通的傳統(tǒng)的互聯(lián)網(wǎng)，這是一個問題，我們提供了一個自動化測試的這樣一套產品和服務，能夠很快把移動的測試時間壓縮到很短。另外我們提供了一個性能測試，這個性能測試其實它不是一個簡單的常用的那些，在這個里面做的性能測試更多是針對真實的用戶體驗測試。

解決什么問題?就是我的產品在開發(fā)完，實際上我們做性能測試，大部分在實驗室環(huán)境，也就是在公司自己內部，但是這樣做完上線之后能不能達到我們預期的效果是很難去說清楚的。至少在之前有幾家客戶，我們在推薦性能測試產品的時候他們在講，我們也在做性能測試，為什么還要用你們的性能測試工具來做呢?我們就說我們就試一下。我們測試了一萬并發(fā)沒有問題，我們能保證一萬并發(fā)，但是我們從真實環(huán)境去測到不了三千就并發(fā)了。所以，這就是實驗室環(huán)境和真實的生產環(huán)境實際上還是有很大出入的。這部分實際上需要的測試和傳統(tǒng)測試不一樣的地方主要是在環(huán)境上，后面我會詳細的講。

性能管理是我們的核心，性能管理主要要解決什么問題呢?因為一般來說我們在運維上對我的業(yè)務性能做的監(jiān)控，知道覆蓋在哪些層面?服務器、中間件，包括網(wǎng)絡環(huán)境，這個是傳統(tǒng)的做法。那么，從性能管理做法，實際上它是從業(yè)務入手，它其實不會從服務器角度去看，而是從應用角度去看。我的用戶比如在網(wǎng)上做一次支付購買，這個過程可能我用戶做了無操作了，最后完成了支付，這個過程里面每一步的性能是什么樣子，其實這是我們性能管理典型的要解決的一個場景。另外，我們還有性能監(jiān)控和安全，性能監(jiān)控實際上是對剛才我們提到的基礎的環(huán)境監(jiān)控和網(wǎng)絡監(jiān)控，主要在這方面。在安全部分，實際上我們把安全問題做成日常的監(jiān)控進行處理。

我們通過這些工具和服務獲取到客戶很多的新聞數(shù)據(jù)，我們能做什么?其實我們在接入客戶其他的業(yè)務數(shù)據(jù)，我們通過數(shù)據(jù)分析能夠衡量出我們所做的這些比如說測試后所做的改進，那么對我企業(yè)的業(yè)務會產生多大的影響，這個是可衡量的。

我分別來講一下，一個是移動應用測試，剛才我也提到了移動應用測試我們所做的一個出發(fā)點，主要是提升它的測試效率。這里邊涵蓋了它的一些特點，就是我這個移動應用實際上我有操作系統(tǒng)和設備的問題在里面，也就是有不同的Android、iOS，還有不同的設備廠家，它的兼容性也是我們很關注的事情。

我們做的這個自動化測試的一個特點是什么?一個是我們能做的可靠的回訪，我們要做持續(xù)的反饋，自動化測試。第二個我們做的還是比較準確，我們自帶的一些驗證都是在APP里面進行控制，我們能控制到APP里末面所有的用戶操作。第三，就是我們所做的應用其實是一個跨平臺的，它可以讓你快速的進行測試。這個是我們給一個客戶做的演示。這個其實就是我們一個客戶的APP，這里邊有幾臺機器，這都是真機。實際上我們給它APP打了一個包裝，也就是做了一個外殼，通過這個外殼驅動在真實手機上反復的跑它的業(yè)務應用，里面錄制了很多業(yè)務操作，包括我的一套的一系列的交易，它就會反復迭代的去跑。做這件事情的初衷，他們想解決的問題就是他們每次修改的時候只改很小的一個功能，但是對這種產品他改任何一個功能都要對所有的功能進行一次回饋測試，這個回饋測試遠遠超過開發(fā)這一小功能的測試量。所以，他通過自動化測試把這件事情轉變成一個不需要人參與的一個過程。實際上什么條件下呢?也就是它白天開發(fā)完，它晚上自動化的進行測試。所以，第二天來了，測試人員只需要針對它所開發(fā)的部分做一些探索性測試就好了，不會測試是通過自動化測試來替代的。

我們做的這個測試的過程其實也比較簡單，就是說只需要把這個APP給過來，我們實際上在這個上面進行了一個封裝，打一個包裝，但是它包裝完之后還是一個APP。我們用這個做腳本錄制，錄制完了這個腳本其實跟Web的自動化測試一樣，生成這樣的腳本，對這個腳本實際上可以做加工了，會在里面打一些參數(shù)做驗證的東西，或者是一些條件，測試的數(shù)據(jù)都可以加進去，然后在那邊把這些測試場景我們可以合并成交易，測試交易之后，真正放到實際的手機上，這個實際手機一種是安裝到我們的環(huán)境下，另外客戶可以自建一套自己的測試環(huán)境，也就是十幾臺手機就可以做這樣的測試了。實際上測試過程是實時的，測試結果會反復回來，這樣的循環(huán)迭代，完成整個的測試。這個是我們主要在一些銀行用的多一些。

性能測試，主要是針對Web層面或者API層面的性能測試，要解決的問題跟傳統(tǒng)的壓力測試不一樣的地方就是一個是環(huán)境的差異，第二個就是真實的線上測試，我們拉回到現(xiàn)實環(huán)境，但是這個可以做到真實環(huán)境去測試。怎么去做到?過程其實是一樣的，測試腳本到實時分析數(shù)據(jù)，這也是幾步，它最大的區(qū)別是什么?一個是這個測試壓力是從網(wǎng)絡上發(fā)起的，我們其實說在云端發(fā)起的，所有的測試點是在云主機上和我們自己的云端的服務器上。客戶實際上它的應用是在自己的環(huán)境，這個測試整個的過程就跟它上線之后實際用戶訪問是一樣的。

另外一個，在這種測試環(huán)境下，我們這個測試環(huán)境下，實際上測試過程是實時的，傳統(tǒng)的做法是腳本寫好，開始跑，比如我壓100萬的UV，5個小時看結果，如果在這個過程中抗不住壓力崩掉了，就崩掉了，它再調整壓力，再重新測試，調整壓力再重新測試。我們這個服務是這樣，可以逐漸加壓，因為我們做壓力測試的目的不是把系統(tǒng)壓死，而是要找到它的一個合理的承載范圍。所以，可以從一個比較低的數(shù)據(jù)UV，我們說的UV就是用戶訪問，從比較低的數(shù)據(jù)開始逐漸加壓力，邊加的時候就可以看到系統(tǒng)的出錯情況怎么樣。在這種方式下，可以逐漸一直找到，比如我的登錄錯誤率超過0.5%，我認為這個就不能接受了。到這個程度下，我的UV是多少，這個是可以很準確的衡量出來的，而且可以隨時停掉。

所以，在這種機制下，我們就不僅在測試環(huán)境可以用，生產環(huán)境也可以用，生產環(huán)境面向最終用戶，云端下是沒有任何問題的。所以，我們壓力測試跟傳統(tǒng)壓力測試不一樣的地方主要在這兩點。這是我們實際的壓力測試過程我截下來的一個圖，實際上這是整個壓力在執(zhí)行到一半的時候，這是壓力曲線不斷上升，然后我們每分鐘事務數(shù)，失敗事務數(shù)，這都是動態(tài)變化，包括我們對應的服務器的一些信息，它的一個性能狀態(tài)。其實我們可以了解到整個系統(tǒng)當前的狀態(tài)，可以隨時選擇調整壓力和停止測試，這是壓力測試。

還有一部分我們叫應用系統(tǒng)管理，這部分做的事情相對比較有意思一些，是面向業(yè)務的基于端到端的一個全棧的應用性能管理。所謂全棧實際上是從用戶端一直到服務器端整個全鏈路會打通。主要面向的業(yè)務是什么?我們會把用戶在他的應用上所做的這些訪問，我們定義成一些交易，比如說，我一個支付是一個交易，我做一次的業(yè)務查詢算是一個交易。定義成一些交易，每個交易后邊有一些事務，假如這個按鈕會出發(fā)一個事件，這個事件對應一個事務，這個事務響應可能有一個請求或者多個請求，每個請求會到服務器端，去服務器端分析所有請求這些錯誤情況，包括當時的交易情況都能做一些記錄。

這種做法主要的目的是什么?就是其實我們的交易做業(yè)務情況分析的時候，做一些用戶功能，對一些交易可以定義它的價值。比如這一筆交易可能是十塊錢，我這些交易，比如我執(zhí)行了500萬次，正常如果它都能執(zhí)行完我有多少收入，如果這個交易有幾個交易，因為有某些性能的提升，有些交易失敗了，實際上我可以算這個性能對我的業(yè)務影響到底有多大，這是具體衡量的。這個實際上是我們從前到后一個打通的過程，我們簡單解釋一下，底下這張圖我們把用戶從不同入口訪問的請求，到后端服務器端如何處理，整個邏輯圖分析出來。每個環(huán)節(jié)，比如從這端到前端的應用處理，中間花多長時間，這段到緩存數(shù)據(jù)庫花多長時間，整個鏈路上的時間都能拿到，我們知道這個性能，比如這個性能不好在哪里?然后我們進而分析一些統(tǒng)計，對哪些類請求，哪些業(yè)務，它的性能表現(xiàn)好與不好和它的交易成功這個比值我們能拿到，它的用戶實際的這是一個交易的整個我們用一個實際的圖來表達，這是單次，底下是匯總的，也就是系統(tǒng)當前的狀態(tài)，這是每一筆交易的過程。其實我們捕捉到非常細的信息出來，然后對應可以看到我們交易的所有的狀況。這些信息對運營是非常有價值的。

整個做法是怎么來做的呢?因為做技術的人大家會更關心一些。其實我們把這個東西分成兩個層面，一個層面就是交易性能全過程的跟蹤，用戶體驗有兩個，一種是移動的入口，一周是普遍的Web入口，Web入口跟傳統(tǒng)的做業(yè)務分析其實做法是一樣的，在上面打了JS，然后做用戶的行為數(shù)據(jù)搜集。另外一個是從移動端，這個請求發(fā)到后端，這個地方請求的時候會針對這個有一個K，每一步后面都會有一個K會跟過來，我們把數(shù)據(jù)搜集起來，就可以拿到所有的數(shù)據(jù)，就能形成我們的所有業(yè)務。這些都是一些主動性的監(jiān)控，把對應的服務器和基礎硬件、中間件的環(huán)境，這些性能數(shù)據(jù)都拿起來，我們就能看到一個完整的業(yè)務性能。這個是我們從體驗到安全到網(wǎng)絡到業(yè)務應用到基礎架構全覆蓋，然后做持續(xù)的監(jiān)控優(yōu)化。

補充一下其實這種都是在業(yè)務內部來做的，還有一部分實際上是模擬實際用戶，從模擬型做。就是當這個業(yè)務沒有人訪問的時候它的性能是什么樣，其實我們也需要知道。我們在全世界各地雇了很多的監(jiān)測棧，會對持續(xù)的應用發(fā)起請求，看這個目標的應用是否是正常的。除了Web的形式之之外，現(xiàn)在還有一種APP，現(xiàn)在APP應用越來越廣泛了，所以針對監(jiān)控一樣我們也是通過這樣的方式去模擬進行監(jiān)測，說APP是不是正?？捎玫摹Ｎ覀儼岩恍?shù)據(jù)匯總起來，其實這個數(shù)據(jù)嚴格來說我也不好說它算不算真正的大數(shù)據(jù)，但是它具有很多大數(shù)據(jù)的一些特性。我們把這些數(shù)據(jù)匯總起來，我們其實想把這些大量用戶的性能數(shù)據(jù)搜集起來，我們未來有一個想法，類似這樣的一個設想。假定我的業(yè)務想做一個活動，我想引入五千萬的流量，我現(xiàn)在的結構是否能撐得住，如果撐不住，那我需要什么樣的架構來支撐它。這個實際上是我們可以去未來做一些預測的數(shù)據(jù)。

我們在數(shù)據(jù)上的想法主要是解決端到端執(zhí)行分析過程中所產生的這些數(shù)據(jù)，怎么去體現(xiàn)出來它的價值。所以我們在這邊做的大數(shù)據(jù)比較定向的只是對我們這個領域來做的，是相對來說比較容易落地的一些事情。主要介紹一些主要的產品和服務。這是我們在大數(shù)據(jù)上做的一些呈現(xiàn)，這是數(shù)據(jù)來源，來源于不同的產品和服務，這是我們現(xiàn)有的性能管理的產品的數(shù)據(jù)，這些是業(yè)務數(shù)據(jù)做的一些匯總，這是我們的一些呈現(xiàn)。

我們給客戶提供的價值有幾點，從市場角度主要是針對實時的業(yè)務分析幫助他適應這個市場的變化。另外，對研發(fā)來說，做快速構建，持續(xù)改進，持續(xù)交付。對運維來說，主要能快速定位解決問題預測并預防問題，最后對運營來說叫提高用戶的滿意度。我們現(xiàn)在IT都是由內轉外，大部分資源其實都在云化，在這種情況下，實際上我們的產品對云端的應用可能更有效果，尤其我們的服務本身也是SaaS，也是隨時來隨時用的這種方式，本身就是一個比較新的應用。在云遷移、云監(jiān)控管理其實都何以考慮用這樣的產品來做。

簡單一句話介紹一下我們公司，我們公司主要專注在應用性能管理方面，其實公司2009年就成立了，一直在做這部分，但只不過我們運營做的比較晚，也就這兩年才開始做運營。謝謝大家!