一、關注產品比伺服器更重要

無論是Web網站還是要移動應用，最終都要呈現給使用者的，不是伺服器的負載圖，而是產品本身。而從產品形態展示到伺服器的請求處理，這個過程中有很多過程，這也同樣是運維人員需要關注的。哪怕後臺再爛，Bug一大堆，也能支撐的了現有系統的使用者訪問。因為作為運維人員職責並不是開發，而是保證開發出來的系統不會因為伺服器某些問題而導致使用者無法訪問，從而影響為使用者提供正常服務。

一般來說，從使用者角度監測產品，有如下幾個維度？

1.使用情況監測:監測內容包括使用者是否完成預設的訪問路徑，停留在哪些內容比較長。

2.互動動作監測:監測內容包括頁面哪些位置更容易吸引使用者點選，哪個元素比較吸引人。

3.訪問效能監測:監測的內容包括使用者看到他(她)想看到的頁面內容，花了多久時間，能否正常顯示。

4.使用者統計監測:監測的內容包括使用者的年齡、性別、職業分佈，滿意度調查等。

不同的維度有不同的人關注。比如像產品經理比較關注的就是使用情況和互動動作

對於運維人員，更需要關注的就是訪問效能。因為使用情況和訪問效能及其最後的使用者統計都是建立在訪問的基礎上。

二、網站監測的明星指標

1.可用性

主要是可用性，對於任何網站，可用性都是首要的關鍵指標。人們常說“聊勝於無”，就網站運維來說，建立對網站應用的可用性監測，是產品監測從無到有的第一步。最簡單通用的方式就是對應用最終釋出的伺服器進行80埠上是否可連線的定期測試。

對於大規模網站應用，連線可用性又可以細分為伺服器可用性、運營商可用性、地區可用性、錯誤響應比等四個方面。

a.伺服器可用性

大規模網站一般情況下都擁有多個對外發布的可用的伺服器。運維人員既要盡力保障整個應用叢集的高可用性，也同樣需要關注叢集內部單個伺服器的可用性。否則，一旦出現連續宕機的情況，就很容易出現雪崩反應。

如果是運維人員只是僅僅管理三到四臺機器上面的幾個專案，那還好，如果是成千上萬臺伺服器支撐著一個規模非常大的專案的話，為了保障某部分伺服器出現問題第一時間解決，那麼監控手段的有效性和實時性是非常重要的。

b.運營商可用性

運營商的可用性很多參考例子，我就以前段時間因為運營商的緣故導致某創業公司資料丟失問題。這個說白了最直接的原因就是騰訊的原因。從某個角度看就是因為運營商沒選好導致的。

c.地區可用性

比如現在阿里雲伺服器提供華北一、華北二等之類的選項就是因為地區網路可用性的原因。有的時候因為業務需要在某個特定的區域對外提供服務。

d.錯誤響應比

因為多方面的原因，例如伺服器負載過高、網路延時、DNS劫持篡改甚至運維操作失誤(比如前段的運維人員不慎刪庫)等，連線可用的網路也可能返回錯誤的結果。與連線可用性比較，錯誤響應比更難以監測。

2.響應時間

響應時間這個不用說的太多，在很多年前有個8秒定律，然後變成4秒定律，最後變成了最好是1秒或者2秒定律，當然了，實際因情況而定。或許有人對8秒定律這樣的很疑問，對此，我覺得不是特別理解的人，可以參照平時上網，如果你好久好久也就是10秒以上時間沒開啟這個網站，恐怕你早就放棄了。我這個10秒都是誇張了點。當然了，這裡針對的是一般使用者。像我們開發人員這些特別的使用者，一般訪問外國的技術網站，確實有的時候很卡，當然也不排除有的時候無法訪問(攔截的緣故)，但是為了學習這也是沒有辦法的事情，於是有的就想盡辦法代理訪問或者是FQ等等。

3.首屏響應時間

首屏一般是使用者第一眼看到的，首屏如果響應半天，只僅僅看到了有的圖片顯示有的沒有顯示、有的css樣式或者js動態效果出來了，有的就沒有。如果是這樣的話，那麼使用者早就跑光了。

為此針對這種情況，就需要前端人員和運維人員合作採取一些必要的措施，比如動靜分離、CDN之類的。

三、網頁瀏覽過程

1.解析域名

解析域名同樣分成幾部分。

首先，瀏覽器本身是可以快取DNS域名解析的，所以瀏覽器會先在自己內部的DNS快取中檢視是否有現成的記錄，如果有，就直接返回結果。

否則，查詢作業系統級別的DNS快取。這在Window作業系統中，是一個叫DNSCache的服務；在Linux作業系統中，可能是HSCD服務，也可能是DNSmasq服務。如果命中，直接返回結果。

如果依然沒有，下一步是查詢本機Hosts記錄。該檔案在Windows作業系統下位於C:\Windows\System\drivers\etc\hosts,在Linux作業系統下位於/etc/hosts。

2.連線伺服器

在獲取最終的伺服器IP後，下一步就是與該IP的網頁服務埠(即HTTP的80和HTTPS的433埠)建立TCP連線。這部分過程涉及TCP/IP相關的知識，無論是開發和運維人員都有這個必要去好好看看。

3.傳送請求

在成功連線上對應埠後，瀏覽器開始傳送HTTP請求。HTTP請求包括請求方法、URL和協議版本三個最基本要素，以及種類繁多的各式HTTP Header。完整的協議內容通過檢視RFC2616，以及《HTTP協議指南》獲取。

4.等待響應

這一步可能會讓讀者覺得很驚訝，但事實上，這個時間確實存在，而且有必要單獨關注。動態網頁的內容，需要伺服器端進行資料庫查詢等複雜操作；靜態內容，也需要伺服器進行磁碟尋道讀取；如果是代理伺服器，或者檔案通過NFS掛載，那麼更大的世界消耗還有內部網路互動等。這個時間依賴於伺服器效能，也就可以間接反映出伺服器端的負載壓力情況。

5.傳輸響應內容

傳輸響應內容的快慢，取決於網速

6.瀏覽器渲染處理

瀏覽器接受完全部響應內容後，開始在本地進行渲染處理。

對於HTML檔案，現代瀏覽器一般會讀取到<a href>和<img src>等需要繼續請求元素節點，隨機提前開始準備DNS解析，並稍後開始建連。因為DOM樹的構建是隨著HTML語句的讀入進行的，所以這一部分操作相當快速。

對於CSS/JS檔案，CSS操作DOM樹JS則更準確就是客戶端指令碼語言，它們都需要在瀏覽器上編譯執行。

瀏覽器對這兩種檔案的執行速度對全頁面顯示完成總時間的影響非常大。因為在目前的協議和實現下，瀏覽器頁面渲染都是單執行緒的，CSS和JS的執行都會阻塞整個頁面的效果。

如果將JS指令碼放在HTML程式碼的開頭或者中間，那這個阻塞甚至會影響到DOM樹的構建。所以在Yahoo等常見前端優化規則，大多數建議將JS指令碼放到</body>前

四、瀏覽器網路監測和分析

常用的瀏覽器除錯工具FireBug和Chrome開發人員工具。我覺得這兩個足以勝任。同時也是前後端、運維人員常用的工具之一。