本文根據郭東白在2016ArchSummit全球架構師（深圳）峰會上的演講整理而成。

ArchSummit即將在2018年7月6日深圳華僑城洲際酒店開幕，更多分享內容請瀏覽：連結

講師介紹：
郭東白，現任阿里巴巴速賣通技術部總監。主要從事雲端計算和網際網路電商領域的研究。有十六年大型軟體系統研發和架構經驗，對跨大洲，高可用，高流量服務端軟體架構和研發有深入研究。領導設計了全球跨國家，多市場，多語言，多幣種，實時個性化，每秒近萬筆訂單量的多機房異地多活電商平臺, 連續兩年在超過200%流量增速下保持了99.99%的可用性。在2015年11月11日創造了2200萬單跨境交易，全球214個國家逾千萬人用16種語言下單。除電商領域的鑽研外，郭東白還為多個公司在不同領域打造了多維度，多層次的資料供應鏈產品。 並且有十多年的大型跨國界專案和大團隊管理經驗。 在甲骨文，微軟，和亞馬遜開發了多項突破性科技創新產品並且在市場上取得了的巨大成功。過去十一年分別為甲骨文，微軟，亞馬遜設計制定實施了工業標準戰略，參與規則制定，策略整合，夥伴發展，和長期戰略規劃。

-----------

郭東白：我先介紹一下我自己，我之前在美國讀書，在美國生活了十幾年，前年的時候回到了阿里巴巴。我目前負責阿里巴巴的AliExpress，它是跨境出口的網站，也是現在國內最大的跨境電商平臺，在全球範圍排名僅在Amazon和eBay之後。

首先我主要會講基於大資料的全球電商系統性能優化，因為事實上我們是用一個比較標準的系統，所以大資料的內容相對會講得比較少；在場有不少帶團隊的架構師同學，因此也會順便講一些架構師帶團隊的內容，然後接下來會介紹我們的Background、理論基礎、平臺設計、優化實施的具體過程，最後再講Business Impact。

一、Background

阿里巴巴系統裡實質有國內以及國際部分，國內部分大家都聽說過了——淘寶、天貓、聚划算，國際部分的“淘寶、天貓、聚划算”合在一起就是AliExpress。AliExpress是B2C做Consumer生意的，還有http://alibaba.com做B2B生意的。

AliExpress跟國內淘寶、天貓最基本的區別是我們在做跨境生意，什麼是跨境生意呢？這一邊是我們的賣家、另一邊是買家，中間隔了一個International Border，其中大多數賣家是中國賣家，但我們不僅僅侷限於中國賣家，現在俄羅斯賣家在我們平臺上也賣得非常好，每月幾十萬美金甚至上百萬美金的量級，他們都是做得非常不錯的賣家。

這些賣家其實面臨很多很多挑戰，可以想象一下如果一個俄羅斯賣家把他的貨賣到土耳其時，他需要什麼能力？對應的服務全是中國人，系統是中國人造的，賣家只懂俄文，商品都是俄文說明書，商品要賣到土耳其去，土耳其人可能一句俄文都不講，這個挑戰非常大，而且這個過程的資訊流挑戰很複雜。我們現在平臺支援16種語言，這些語言大多數是我們機器翻譯的，翻譯得也並不是很好，我們的機器翻譯水平也在萌芽狀態，我們整個過程面臨的挑戰如下：

• 語言障礙；

• 資訊流，圖片可能在本地是合適的，但在全球情況下資訊流就有挑戰了，例如現在巴西冬天是我們這裡的夏天，南北半球情況這些資訊聽起來像是地理問題，實際上是資訊問題，我們怎麼把合適的資訊送到南半球人上；

• 資金流，我們平臺支援的支付幣種有16種，大家各自用不同的幣種。不僅僅買家會跟錢有關，做電商的還包括聯盟、物流商（物流商還不止一個，國際物流分好幾段，可能中國有一段，俄羅斯那邊有快遞又有一段）等等。在整個大系統裡怎麼分利潤，包括你自己、平臺、買家、賣家、物流商、站長，而且這裡所有的人想拿的幣種還不一樣，有些人想拿美元，有些人想拿本地貨幣，遇到退款的話總不能把盧布退給美國人，這資金流存在很大的挑戰過程；

• Logistics（物流），物流也是很複雜的過程，怎麼確保中國的貨運到全球，假設別人不喜歡的話怎麼把貨退回來，這也是非常大的挑戰。

我今天講的是資訊流上的Performance，我先給出一些數字讓大家大致知道我們系統做得有多大：

• 我們系統現在在Alexa排名是第25名，第25名是什麼概念呢？http://microsoft.com（微軟）排在50名，http://walmart.com（沃爾瑪）排在150名，我們作為電商網站上排名非常高了，雙11單日的Order是2200萬單，儘管亞馬遜很大但它也到不了這個量；

• 我們系統的裝置有九千多種接近萬種型號，每天至少有200個國家的人不管是平時還是週末都會下單，當中有16種語言的人在下單；

• 我們的App launch了一年，雖然從去年才launch但在今年3月份我們已經在47個國家iTunes的App Store裡排名第1位，Google中我們在20多個國家排名第一位（Google只有80多個國家有排名數），相當於我們已經佔據了1/3的國家的下載量排名的第一位，從技術上來講我們支援了非常快速的增長。

我們為什麼關心 Performance呢？如下圖所示，這張圖顯示了Net Promoter Score和Relevance Score的值，Net Promoter Score是淨推薦值，在橫軸上越往左邊越好；縱軸是Relevance Score即相關性，相關性越大越重要，可以看出網站效能相關性是我們所有調研各種不同系統中的No.1重要，甚至比商品都重要，這也是我們當初非常驚詫的事實，這個Performance的滿意度不怎麼樣，我們的商品也有很大的挑戰，但是這個Performance滿意度竟然比我們商品的滿意度還要低，所以我們在（考慮）怎麼做商業的時候“效能”是很關鍵的數字。

效能為什麼很重要呢？大家玩過電商就知道了，電商非常重要的是引流，比如在各種搜尋網站做SEO，做這個事情別人會量你的效能，用效能作為衡量網站質量的引數，Google也不願意一點進連結結果一點反應都沒有，這樣Google自己的生意都壞掉了，Website Performance在8年多前Google就將其作為排名的重要指標，現在的確也還是他們的重要排名指標。

效能其實是錢，我們不是為了倒騰效能作為統計資料才做這個事情，作為架構師第一重要的事情還是得創造價值，不創造價值的架構師是沒用的。我們把效能優化理解成一場戰鬥，傳統的效能優化是怎麼打仗？有點像冷兵器時代打仗——匹夫之勇，什麼是匹夫之勇呢？我剛來的時候團隊裡也有這種人，比如他在網路優化或服務端優化上個人技術很好，有些人比如讀了幾篇Paper然後來試一下結果很有效然後自己玩。

要知道整個網站的Stack是非常深的，從客戶端（Android、iOS、Web）然後到整個網路層的請求，然後到接入層，然後到各種接入的Security層，比如各種各樣的閘道器，閘道器之後比如是Nginx反向代理、安全層、應用層、服務層、資料層一直到底層的基礎架構層，這個層級是非常深的，直到底層包括OS，你能想象出世界上會有一個人把所有從上到下全部精通嗎，不可能，冷兵器時代很多人就是學了一招好使，然後吹個牛晉個升就完了。

構建大團隊的時候不希望出現匹夫之勇來打仗，現在modern打仗不能靠匹夫之勇，你其實是希望設計一套系統能夠讓所有人一起創新，第一要創新，第二要集體創新，即democratic team，每個同學都應該賦能給他，甚至一個小兵也可以協助你打仗，而不是隻有兩個將軍打仗，你是需要每個人都要打，每個小兵都要完整參與到戰爭中，而且你要能夠真實衡量他們的貢獻，這個東西非常重要，很多情況下大家不患貧而患不均，所謂患不均是怎樣的？他對自己的貢獻不清楚，別人給他發的獎金他也不舒服。有個joke是80%的程式設計師認為自己比80%的程式設計師還要牛，做效能優化也是這樣的，以為優化了一點點就覺得自己很牛比別人都牛，其實有時候不是的。

先講講相關的技術：

• 大家可能已經看到現在市場上有比如做APM（Application Performance Monitoring）的，這種東西的確是做全棧優化的，但事實上很少做整個系統從任何一個地方歸集到全域性的指標，它不做這個能力；

• Web performance monitoring，這種就像webMethods，比如之前的Gomez，這些公司它們主要做測量來量客戶端的效能，他們會在網上給你發一大堆報表。這有什麼問題呢？他們其實不跟你自己的業務資料掛鉤，你也不希望把自己的業務資料都給他們，畢竟他們還服務第三方，如果你把資料都給了他們，你的競爭對手可能也會拿到同樣的資料，這些資料就會幫助你的競爭對手。一般我們不做這種共享，至少在我待過的大公司不會做這樣的共享。

• 最後是一些on-site的Performance Tuning Toolkits，這種一般在Server端做的，它的目的不一樣，它往往是為了節省你的伺服器成本，比如把你某某端效能優化N倍，使得throughput加了10倍，以前300臺機器變成了30臺機器，它是減少這個成本的。

但是我們想做的事情還是從使用者端來聊，期望能提升比如俄羅斯西伯利亞買家的體驗，使他更願意下單。做這個事情挑戰很大，因為搜尋空間非常大，做過效能優化的人都知道優化方案是非常多的，空間是以數百計，Stack非常深而且每個地方都有10+個優化方案，那麼從上到下在10+個不同的地方做優化最終就有上百個優化方案。

一個大的網站，像我們網站頁面和元素的數量級已經接近數百了，再算上後臺的應用整個複雜性就上千了，你能優化的地方的招數有數百，能玩這個招數的擂臺有數百近千，這兩個地方乘起來數量級是非常大，而且你每做一次優化都是有成本，大家如果自己做生意或者你是一個很大團隊的leader就會知道，你可能會經常困擾做優化也是有投入的，回報多大非常關鍵。這個問題其實就是搜尋空間太大，我們試圖把這件事情變得非常理智。

二、理論基礎

怎麼做呢？如果大家用過performance monitor就會知道，圖中綠色曲線是網站流量根據延遲的區間分佈，橫軸是延遲區間（以毫秒計，一般網站也不會等到64秒這麼長時間），這圖顯示了大多數請求發生在1秒左右即800毫秒到1.2秒的這個區間，這相當於是請求的延遲分佈；縱軸（紅色的軸）代表跳出率，代表在這個請求過後你決定不再繼續使用這個網站了就跳出了的概率，跳出率是隨著請求延遲越來越高的，相當於你在這兒等不及了煩死了最後即使這個請求返回來了你也放棄了繼續瀏覽的慾望了。

這個力度可以有粗有細，你可以是整個頁面的跳出率也可以是某個元素載入的跳出率，也可以是某個步驟的跳出率，比如說白屏載入、首屏載入到全屏載入，這是一個有順序的過程，白屏到首屏也可以來量跳出率。

有了有些數字的話，這個東西是可以量出來的：上圖公式中的P代表綠色的線，C代表紅色的線，一個頁面的轉化率是綠色曲線乘以紅色曲線的一個積分，有了這個東西你就能觀測到一些現象：下圖深綠色虛線是假設你的叢集的部分機器出現問題，出現問題以後你的請求流量會發生變遷，為什麼發生變遷？

高效能的請求變少了，在效能很差的地方（延遲很長的地方）請求數會變多，這就相當於產生了一個新的請求分佈，相當於叢集出問題了，很不幸的那部份流量落在出問題的機器上了，整個叢集的跳出率會隨著時延出現明顯的增長，正常情況下這條曲線是平的，但是例如有一個人平時如果在這個快速的地方被移到高延遲的地方，他一不高興不能等就走了。

如果你們量自己的網站就會發現曲線一般都是類似的，當然每個曲線是不一樣，因為你自己的客戶是被你訓練出來的，有的人可能耐性很好，你網站本身就很爛很Low，他天天在那兒等等習慣了也無所謂；有的是你的網站非常快，他根本不能等，這個曲線就會變得非常陡。

上圖是很多人都知道，是比較著名的圖，但是現在我們需要反過來想，假設虛線是你的正常情況，實線是你的理想情況，反過來把效能優化以後會得到一個回報，你的轉化率會上升（因為跳出率會減少），怎麼算呢？具體計算公式在下圖中寫著，正常情況下的分佈如圖，優化以後相當於把整個請求壓縮了，假設以前要15秒現在降成3秒，一旦壓進去之後流量不在慢的轉化率上發生而是在快的轉化率上發生，那麼綠色的區間就是做優化後你能得到的回報。

這只是一個理論值，這裡還有一個很強的假設：一個人群以前用15秒去下載一個頁面，如果把它降到3秒的話他們的購買率和3秒是一樣的，這仍然是假設還沒有證實。

如果這個假設成立的話，你就可以認為效能是跳出的唯一因素，在這種情況下你能算出來任何一個頁面因為效能不好而造成的損失我們叫Page Loss，一個頁面就有一個Page Loss，你知道一個頁面Page Loss的時候就能做更重要的事情：你能知道從一個頁面跳到下一個頁面這個損失是多大，如果把損失的東西都補回來，補到下一個頁面的話價值有多大。什麼意思呢？大家可以想象一個江河，它的水一直流到大海里，假設譁一下下大雨了，從小溪流匯到河流然後到大海，這個小溪流的水可能會被分流到農田、麥田裡或者被蒸發掉，河裡的水也有可能被人消耗掉，最終匯到大海的水假設你把所有損失都補償上的話，就是理論期望得到的總值。

具體的公式推導不做了，假設是有N個輸入，每個輸入都做剛才那個補償的話，圖中A部分就得到了理論流量，理論流量扣除自然損失，什麼叫自然損失呢？在任何一個頁面上，跟你的效能無關也有自然損失，說白了人家到你網站去了本來想買一個LV的包包，但是一看到你這兒都是沒見過名字的"VL"包包，他就不想買了就走了，這是自然流失，因為他是不滿意內容而不是不滿意效能。這個自然流失扣掉以後你得到的結果就是你的理論補償，這個公式實際上把真實頁面採集到的數做理論補償，做完理論補償然後扣除你之前算出來的自然跳出率，這個值就得到理論上的補償過的流量。

得到補償以後就能幹最後一件最重要的事情：從一個頁面補到下個頁面然後持續不斷地進行補償，我們就算不談元素僅僅大頁面就近百，在近百頁面的情況下在List（例如搜尋頁面）有補償，然後到Detail（詳情）有補償，然後到下單有補償，這個鏈路是很長的，整個鏈路一點一點補償回來最終到了大海——Order，為什麼用Order這個點呢？選擇這一個點的理由：它是你真真正正需要care的東西。

比如你是做內容網站的，其實你也有目標函式，你也有一個最最重要的東西，假設從你的網站做導流，你是一個聯盟網站，你想導到另外一個真實的下單頁面，例如當年的蘑菇街導到淘寶，只有點選生效以後才賺到錢了，這一點就是你最終要優化的東西。這個過程其實就是讓你把所有之前的要補償的東西一直算到你最終的回報有多大。這個過程就相當於我們剛才量List的補償、Detail的補償、Store的補償等，這個公式在你知道這個頁面關係圖的情況下就可以把整個理論的補償流量算出來。

這個過程完成了即完成了最後一步，任何一滴水即大家可以把一個小優化，比如說是註冊頁面上的小小優化，比如把驗證圖片的速度提升了3個毫秒，這3毫秒優化到底對最終客戶下單產生了什麼回報，這一滴水從註冊的頁面流到搜尋然後流到Detail，整個補償的這一滴水全部最終匯到你的訂單上，這樣就可以讓每個人（之前提到的要賦能全部的人）的能力都能體現出來，把個人所做的對效能的這一點點優化體現到全域性上去，這是我們要做的事情。

其實我們沒必要搜尋這個偉大的空間的，甚至還沒開始優化之前我就能知道回報有多大，為什麼？舉個例子——DNS優化，任何時候你要做一個DNS lookup，比如說俄羅斯遠東地區DNS lookup很慢，比如要25毫秒，你在沒有做這個優化之前你就知道這些人不管怎麼優化，只有少部分的俄羅斯遠東流量可以從25毫秒優化到15毫秒，這15毫秒結果是什麼呢？你把25毫秒設定成15毫秒代到前面的公式去，總的公式上就會告訴你如果優化從25毫秒變成15毫秒最終會得到多少訂單回報，全域性會得到多少訂單回報，比如說俄羅斯遠東訂單最終得了0.1%的回報，你的投入是多少呢？後來發現在俄羅斯遠東地區蓋一個專屬的DNS伺服器根本不比蓋在法蘭克福便宜，太貴了不願意蓋。這就是核心的東西，它給了你事先做決策的工具，剛才講我們搜尋空間上千，上千的搜尋空間沒等你幹活就知道值不值得做。

接下來一旦找到好的優化點，理論優化量你只要在這個頁面上做一次就知道它的真實回報是多少，因為一開始那個值是算出來的，一旦你做了優化之後你就得到真實的值，你就能量出來，那麼你就知道差值了，這個值就可以選擇性在其它頁面上推廣，因為你已經知道預計的回報是多少，比如說做DNS定址的優化，看了平均回報是5毫秒，鋪到20個頁面以後，雖然你有100多個頁面，但是你鋪到最大的20個頁面流量以後剩下的就不值得再看了。

最終怎麼樣了？你有很多優化方案和流量，上來你先診斷量出來的預估回報，這個回報就進入度量平臺，告訴你這個結果會有多少，如果結果不好你就放棄掉，如果結果好你出一個通用方案再推廣，並非對所有上千頁面推廣，你只是對回報足夠大的地方做推廣，這就變成足夠理性的決策，從現在開始效能優化不再是你牛逼你單挑，你要知道挑了以後是有成本的，要掉血的，如果那個人很爛不值得我掉血，跟他單挑有啥意思？最終結果是做最明智的打法，過去冷兵器時代的戰爭就變成現代戰爭，我們海陸空可以一起打，有的人可能做網路端效能優化的，有的人可能是做伺服器端效能優化的，這些不是同一行的人是可以比的，我們構建了一個平臺使得每個人打的結果實時都看得到。

三、平臺設計

這個平臺長什麼樣子？我到阿里的時候阿里已經有完整的系統，就是下圖中最上面的Business Domain這個圈子，這已經是完整的電商系統，在完整電商系統之外我們再加了Performance Command Platform，這個系統能讓你看到你的效能回報是什麼，並且能實時知道效能上是不是有問題，出了問題可以做報警、做監控，這個是覆蓋全鏈路的。我們沒有強制每個Business Domain都加到這個鏈路裡面，因為你要讓所有的人上來就相信你的效能優化平臺，即使你是美國回來的我也不一定相信你。

我們做這個事情根本沒有強制，我們先找最容易發力的地方發力，我以前聽一個講座：“你做這個東西避免大風險，從小風險做出來”，這是非常扯淡的，我們做架構師的人要搞清楚要玩就玩大風險高回報的事情，別從什麼小風險低迴報的事情做起來。如果你玩有大風險的地方你要控制你的風險就找最高回報的時候打，拿出結果以後你才有希望活下來，一旦掛了沒用了你弄小風險的東西人家一看覺得這個人沒什麼水平一點結果都沒有，這是很重要的。

我們有這套東西幹什麼？你在每個域裡做度量、分析、實驗，把這個實驗做好以後再推廣，比如在這個域裡推廣結果好了，大家信服了，然後從一個域到下一個域然後到所有的域嘩啦啦地推出來，這是一個持續不斷的過程。這裡就是我所說的有三板斧的人，很多人都各有一板斧，有的人很牛例如做DNS優化，阿里有自己的DNS Team，他們有DNS優化的能力，有些人是玩TCP優化不錯知道TCP優化怎麼做，還有些人是做網路端做Ajax的，這些人都可以同時在這平臺上玩了，而且玩的過程中是全部平行的過程，因為你的東西跟其他人的東西關係不大，你自己做自己的優化，到時候大家一起打擂，這個結果是完全可以度量的。這個過程就是把整個資料輸入到這個系統裡，一旦好使就把這個技術在整個系統上做推廣。

具體這個設計是怎樣的？剛才前面講的我們有一個打點系統，相當於把資料都採集進來，這是我們本身原有的系統，後面我們做Event Tracking系統埋點，然後做EventCollection做資料蒐集，然後有Offline Performance Data Analysis做離線和線上分析，而且我們有小資料庫Business DB定義所有的頁面之間的關係，然後到了我們網頁，網頁上會給你看到Reporting、Monitoring、Alarm這些能力，然後最後是我們有Cache會告訴你同比（周同比、年同比等）或者拉到歷史資料時看看結果，這就是我們整個系統。

這個系統長什麼樣？有些曲線是統計效能的，這條線是我剛剛講過的效能區間分佈的曲線，這條線是轉化率的曲線，這邊有些實時的東西用來查效能問題的，有時候會發現有些系統性能不一定是問題，但效能是很好的表徵，他一看這個請求嘩啦啦地上漲了可能是效能出問題了，所以這套東西做完了之後可以做監控幫助你提升穩定性，儘管目標是為了拿到錢拿到ROI，但事實上還有site-benefit——用來提升系統穩定性。

還有一個東西做什麼呢？對全球性的監控，效能來的打點資料是全球覆蓋的，任何一個IP，比如說俄羅斯遠東地區真實的請求的值是多少可以重新投影到這個世界地圖上，你就可以知道任何一點實時全球的可用性怎麼樣，網路可用性怎麼樣，還可以知道這個國家的平均值，這些值還可以跟些業務資料相關，這裡有很多外掛的功能，比如你可以看到全球的效能和轉換率之間的相關性都可以在這裡做到。

做了這個東西其實還只是開始，我說過了單打獨鬥是不行的。實質上培養一個做效能的高手是很花錢的，我們說做網路優化是幹什麼的，比如譁一下想試驗一個什麼東西但很多東西是要花錢買來的，比如一條專線得花錢部署，或者蓋個pop點、蓋機房或在CDN上買流量，這些全部是要花錢的，沒有一樣免費，而且最怕這些人培養好了他們就跳槽了，你們也不希望發生這些事情。實際上這個事情就把一個人普通的能力最後沉澱到一個系統裡去，而且這個系統會給你推薦你最需要優化的點在哪裡，從這裡繼續往前走。

四、優化實施

優化怎麼實施？實施效能優化有成千上百個手段，我就不單獨一個個介紹了，我們也不曾把所有的優化手段都用過，但我們試過的真正管用的招數我接下來都會說一下，這些都是我們花錢花人打出來的。

最有用的招數是動態加速，通過使用者把所有動態的內容提到邊緣節點，使得動態內容很快到使用者手裡，同時再把所有頁面元素做非同步請求，沒拿到的內容做非同步請求，然後再通過CDN網路返指到源站。幾個挑戰要注意：

1. 獲取使用者真實的IP，這變成非常複雜的事情，以前你可以直接拿IP，使用者是直接請求你的，現在通過CDN這個請求不一樣了
2. 源站的請求攔截，做安全的人都知道，如果攔截突然發現來自CDN的請求一大堆，你可能會把它攔截掉，你要想辦法把這個跳過，還有跨域呼叫CDN會調你的東西等等。

接下來的優化手段就不詳細講了，按順序來講接下來的優化是靜態化+ESI。其實很多優化手段光使一個不好使，我給大家講的東西是組合拳，得把一套的東西一起用。有些人說動態加速很好用結果自己一試不好用，為什麼呢？因為組合拳沒有用到，你少了很多東西比如靜態內容放到CDN上動態內容卻沒放，使用者看不到價格就不會下單，靜態化+ESI就是一個組合拳;

接下來的優化是元素請求合併：

權威DNS優化：

圖片DNS優化：

CDN排程優化：說到CDN排程，這個挺有意思的，舉個例子，你開始覺得邊緣節點放在巴西當然最快，但如果放在巴西之外，放在美國反倒比放在離巴西很近的阿根廷和墨西哥還要快，網路距離和真實能力頻寬相比反倒是離得比較遠的美國結果更好。

五、Business Impact
最後一部分Business Impact，我們做了這件事情帶來了什麼？分析效能變得非常快，之前要好幾天，現在只需要1分鐘，並且還有一個很重要的事情：我們把訂單增加了10.5%。一年之內這是白花花的銀子相當於白來的（例如一年的GMV是10億美金，現在變成了11億），直接回報是非常大的，這個專案給整個AliExpress每年帶來了數億美金的回報。

我們通過第一次量這個值後要做校準，我們預先有預測值，但是預測值要不停的用真實資料校準，我們發現第一次做完了我們的指標量出來發現損耗理論預計值下降36%，再看業務回報，我們的Direct購買率增長13.2%，全站的購買率反倒比Direct購買率增加更多，對網站不熟悉的使用者他更受效能影響，所以效能的拉新作用非常大，新使用者因為等不上一旦機器效能不好就跳走了，現在有了效能優化以後新使用者+老使用者總體的轉化率增加了26.9%，這是瞬間的轉化，隨著時間又會降下來，降下來最終的值是10%+，這10%+我們驗證了好幾次，有時候我們會有抖動等我們把這個優化關掉了，這個轉化率又降下去了，我們有一次連續3天關閉了主要的效能優化以後網站的轉化率降低了8%，所以我們對這個還是很有信心的。

雙11的效能保障流程也是這樣的，現在可以突然間做很強的壓測，在壓測階段你就知道你期望的效能是什麼。

怎麼看呢？我們先預計雙11期待的效能做離線分析，雙11之前的一週是綠色的曲線，雙11那天因為擴容了所以效能變好，但是雙11那一刻大流量來了效能又降下來了，但是降到我們的期望值，也就是我們之前的平均水平。假設這個值降的太低了，我們就要立即緊急擴容，花錢買更多的頻寬，但是我們現在正在期望值上所以不用擴容，我們的流量還是估得非常準的。

我們還可以做新頁面的效能分析：

很多人做業務的會指責我們做技術的效能變化導致訂單下降，但是我們一看轉化率——效能區間分佈，這兩天曲線的是完全重疊的，也就是效能一丁點都沒有變化，看頭一天和最近一天的轉化率曲線不重合——轉化率降低了，但是我們1秒鐘後100%告訴你這和效能無關，因為這曲線是完全重疊的，應該是其他業務原因導致的訂單變化。

總結一下，因為我也是做架構師開始，首先第一件事情是你的架構能讓大家創新，並且讓所有人創新。雖然我們做的這個架構很大，但是整個這套系統我自己的團隊只投了一個全職的同學，另外兩個專門做前端的同學，總共相當於三個人不到半年的時間搭起了整個平臺，我們拿到的GMV回報絕對值將近10個點，一套架構真正地Optimalize Team，讓大家都很興奮，能夠準確無誤測量你的商業回報，這個商業回報會使你一步一步贏得你的客戶的信任。

這是我的演講。謝謝。