5.1 網站可用性的度量與考核
網站的可用性描述網站可有效訪問的特性。
網站的頁面能完整呈現在用戶面前，需要經過很多環節，任何一個環節出問題，都會導致網站頁面不可訪問。
DNS會被劫持、CDN服務可能會掛掉、網站服務器可能會宕機、網站交換機可能會失效、硬盤會損壞、網卡會松掉、機房會停電、空調會失靈、程序會有Bug、黑客會攻擊、促銷引來大量的訪問、第三方合作伙伴的服務不可用.....
5.2 高可用的網站架構
網站高可用架構設計的主要目的就是保證服務器硬件故障時服務依然可用、數據依然保存並能夠被訪問。
實現上述高可用架構的主要手段是數據和服務的冗余備份及失效轉移，一旦某些服務器宕機，就將服務切換到其他可用的服務器上，如果磁盤損壞，則從備份的磁盤讀取數據。
一個典型的網站設計通常遵循如下圖所示的基本分層架構模型
典型的分層模型是三層，即應用層、服務層、數據層；各層之間具有相對獨立性，應用層主要負責具體業務邏輯處理；服務層負責提供可復用的服務；數據層負責數據的存儲與訪問。
不同的業務產品會部署在不同的服務器集群上，如某網站的文庫、貼吧、百科等屬於不同的產品，部署在各自獨立的服務器集群上，互不相干。這些產品又會依賴一些共同的復用業務，如注冊登錄服務、Session 管理服務、賬戶管理服務等，這些可復用的業務服務也各自部署在獨立的服務器集群上。至於數據層，數據庫服務、文件服務、緩存服務、搜索服務等數據存儲與訪問服務都部署在各自獨立的服務器集群上。
位於應用層的服務器通常為了應對高並發的訪問請求，會通過負載均衡設備將一組服務器組成一個集群共同對外提供服務，當負載均衡設備通過心跳檢測等手段監控到某台應用服務器不可用時，就將其從集群列表中剔除，並將請求分發到集群中其他可用的服務器上，使整個集群保持可用，從而實現應用高可用。
位於服務層的服務器情況和應用層的服務器類似，也是通過集群方式實現高可用，只是這些服務器被應用層通過分布式服務調用框架訪問，分布式服務調用框架會在應用層客戶端程序中實現軟件負載均衡，並通過服務注冊中心對提供的服務器進行心跳檢測，發現有服務不可用，立即通知客戶端程序修改服務訪問列表，提出不可用的服務器。
位於數據層的服務器情況比較特殊，數據服務器上存儲着數據，為了保證服務器宕機時數據不丟失，數據訪問服務不中斷，需要在數據寫入時進行數據同步復制，將數據寫入多台服務器上，實現數據冗余備份。當數據服務器宕機時，應用程序將訪問切換到有備份數據的服務器上。
5.3 高可用的應用
應用層主要處理網站應用的業務邏輯，因此有時也稱為業務邏輯層，應用的一個顯著特點是應用的無狀態性。
所謂無狀態的應用是指應用服務器不保存業務的上下文信息，而僅根據每次請求提交的數據進行相應的業務邏輯處理，多個服務實例（服務器）之間完全對等，請求提交到任意服務器，處理結果都是完全一樣的。
5.3.1 通過負載均衡進行無狀態服務的失效轉移
不保存狀態的應用給高可用的架構設計帶來了巨大便利，既然服務器不保存請求的狀態，那么所有的服務器完全對等，當任意一台或多台服務器宕機，請求提交給集群中其他任意一台可用機器處理，這樣對終端用戶而言，請求總是能夠成功的，整個系統依然可用。對於應用服務器集群，實現這種服務器可用狀態實時監測、自動轉移失敗任務的機制是負載均衡。
負載均衡，主要使用在業務量和數據量較高的情況下，當單台服務器不足以承擔所有的負載壓力時，通過負載均衡手段，將流量和數據分攤到一個集群組成的多台服務器上，以提高整體的負載處理能力。目前，不管是開源免費的負載均衡軟件還是昂貴的負載均衡硬件，都提供失效轉移功能。在網站應用中，當集群中的服務是無狀態對等時，負載均衡可以起到事實上高可用的作用。
當 Web 服務器集群中的服務器都可用時，負載均衡服務器會把用戶發送的訪問請求分發到任意一台服務器上進行處理，而當服務器 10.0.0.1 宕機時，負載均衡服務器通過心跳檢測機制發現該服務器失去響應，就會把它從服務器列表中刪除，而將請求發送到其他服務器上，這些服務器是完全一樣的，請求在任何一台服務器中處理都不會影響最終的結果。
由於負載均衡在應用層實際上起到了系統高可用的作用，因此即使某個應用訪問量非常少，只用一台服務器提供服務就綽綽有余，但如果需要保證該服務高可用，也必須至少部署兩台服務器，使用負載均衡技術構建一個小型的集群。
5.3.2 應用服務器集群的 Session 管理
應用服務器的高可用架構設計主要基於服務無狀態這一特性，但是事實上，業務總是有狀態的，在交易類的電子商務網站，需要有購物車記錄用戶的購買信息，用戶每次購買請求都是向購物車中增加商品；在社交類的網站中，需要記錄用戶的當前登錄狀態、最新發布的消息及好友狀態等，用戶每次刷新頁面都需要更新這些信息。
Web應用中將這些多次請求修改使用的上下文對象稱作會話（Session），單機情況下，Session 可由部署在服務器上的Web容器（JBoss）管理。在使用負載均衡的集群環境中，由於負載均衡服務器可能會將請求分發到集群任何一台應用服務器上，所以保證每次請求依然能夠獲得正確的 Session 比單機時要復雜很多。
集群環境下，Session管理主要有以下幾種手段。
1.Session 復制
Session 復制是早期企業應用系統使用較多的一種服務器集群 Session 管理機制。應用服務器開啟 Web 容器的 Session 復制功能，在集群中的幾台服務器之間同步 Session 對象，使得每台服務器上都保存所有用戶的 Session 信息，這樣任何一台機器宕機都不會導致 Session 數據丟失，而服務器使用 Session 時，也只需要在本機獲取即可。
這種方案雖然簡單，從本機讀取 Session 信息也很快速，但只能使用在集群規模比較小的情況下。當集群規模較大時，集群服務器間需要大量的通信進行 Session 復制，占用服務器和網絡的大量資源，系統不堪負擔。而且由於所有用戶的 Session 信息在每台服務器上都有備份，在大量用戶訪問的情況下，甚至會出現服務器內存不夠 Session 使用的情況。
而大型網站的核心應用集群就是數千台服務器，同時在線用戶可達千萬，因此並不適用這種方案。
2.Session 綁定
Session 綁定可以利用負載均衡的源地址 Hash 算法實現，負載均衡服務器總是將來源於同一 IP的請求分發到同一台服務器上（也可以根據 Cookie 信息將同一個用戶的請求總是分發到同一台服務器上，當然這時負載均衡服務器必須工作在 HTTP 協議層上，這樣在整個會話期間，用戶所有的請求都在同一台服務器上處理，即 Session 綁定在某台特定服務器上，保證 Session 總能在這台服務器上獲取。這種方法又被稱作會話黏滯。
Session 綁定的方案顯然不符合我們對系統高可用的需求，因為一旦某台服務器宕機，那么該機器上的 Session 也就不復存在了，用戶請求切換到其他機器后因為沒有 Session 而無法完成業務處理。因此雖然大部分負載均衡服務器都提供源地址負載均衡算法，但很少有網站利用這個算法進行 Session 管理。
3.利用 Cookie 記錄 Session
早期的企業應用系統使用 C/S（客戶端/服務器）架構，一種管理 Session 的方式是將 Session 記錄在客戶端，每次請求服務器的時候，將 Session 放在請求中發送給服務器，服務器處理完請求后再將修改過的 Session 響應給客戶端。
網站沒有客戶端，但是可以利用瀏覽器支持的 Cookie 記錄 Session
利用 Cookie 記錄 Session 也有一些缺點，比如受 Cookie 大小限制，能記錄的信息有限；每次請求響應都需要傳輸 Cookie，影響性能；如果用戶關閉 Cookie，訪問就會不正常。但是由於 Cookie 的簡單易用，可用性高，支持應用服務器的線性伸縮，而大部分應用需要記錄的 Session 信息又比較小。因此事實上，許多網站都或多或少地使用 Cookie 記錄 Session。
4.Session 服務器
Session 服務器是可用性高、伸縮性好、性能也不錯，對信息大小又沒有限制的服務器集群 Session 管理方案。
利用獨立部署的 Session 服務器（集群）統一管理 Session，應用服務器每次讀寫 Session時，都訪問 Session 服務器。
這種解決方案事實上是將應用服務器的狀態分離，分為無狀態的應用服務器和有狀態的 Session 服務器，然后針對這兩種服務器的不同特性分別設計其架構。
對於有狀態的 Session 服務器，一種比較簡單的方法是利用分布式緩存、數據庫等，在這些產品的基礎上進行包裝，使其符合 Session 的存儲和訪問要求。如果業務場景對 Session 管理有比較高的要求，比如利用 Session 服務集成單點登錄（SSO）、用戶服務等功能，則需要開發專門的 Session 服務管理平台。
5.4 高可用的服務
可復用的服務模塊為業務產品提供基礎公共服務，大型網站中這些服務通常都獨立分布式部署，被具體應用遠程調用。可復用的服務和應用一樣，也是無狀態的服務，因此可以使用類似負載均衡的失效轉移策略實現高可用的服務。
除此之外，具體實踐中，還有以下幾點高可用的服務策略。
1.分級管理
運維上將服務器進行分級管理，核心應用和服務優先使用更好的硬件，在運維響應速度上也格外迅速。顯然，用戶及時付款購物比能不能評價商品更重要，所以訂單、支付服務比評價服務有更高優先級。
同時在服務部署上也進行必要的隔離，避免故障的連鎖反應。低優先級的服務通過啟動不同的線程或者部署在不同的虛擬機上進行隔離，而高優先級的服務則需要部署在不同的物理機上，核心服務和數據甚至需要部署在不同地域的數據中心。
2.超時設置
由於服務端宕機、線程死鎖等原因，可能導致應用程序對服務端的調用失去響應，進而導致用戶請求長時間得不到響應，同時還占用應用程序的資源，不利於及時將訪問請求轉移到正常的服務器上。
在應用程序中設置服務調用的超時時間，一旦超時，通信框架就拋出異常，應用程序根據調度策略，可選擇繼續重試或將請求轉移到提供相同服務的其他服務器上。
3.異步調用
應用對服務的調用通過消息隊列等異步方式完成，避免一個服務失敗導致整個應用請求失敗的情況。如提交一個新用戶注冊請求，應用需要調用三個服務：將用戶信息寫入數據庫，發送賬戶注冊成功郵件，開通對應權限。如果采用同步服務調用，當郵件隊列阻塞不能發送郵件時，會導致其他兩個服務也無法執行，最終導致用戶注冊失敗。
如果采用異步調用的方式，應用程序將用戶注冊信息發送給消息隊列服務器后立即返回用戶注冊成功響應。而記錄用戶注冊信息到數據庫、發送用戶注冊成功郵件、調用用戶服務開通權限這三個服務作為消息的消費者任務，分別從消息隊列獲取用戶注冊信息異步執行。即使郵件服務隊列阻塞，郵件不能成功發送，也不會影響其他服務的執行，用戶注冊操作可順利完成，只是晚一點收到注冊成功的郵件而已。
當然不是所有服務調用都可以異步調用，對於獲取用戶信息這類調用，采用異步方式會延長響應時間，得不償失。對於那些必須確認服務調用成功才能繼續下一步操作的應用也不合適使用異步調用。
4.服務降級
在網站訪問高峰期，服務可能因為大量的並發調用而性能下降，嚴重時可能會導致服務宕機。為了保證核心應用和功能的正常運行，需要對服務進行降級。降級有兩種手段:拒絕服務及關閉服務。
拒絕服務：拒絕低優先級應用的調用，減少服務調用並發數，確保核心應用正常使用；或者隨機拒絕部分請求調用，節約資源，讓另一部分請求得以成功，避免要死大家一起死的慘劇。貌似 Twitter 比較喜歡使用隨機拒絕請求的策略，經常有用戶看到請求失敗的故障頁面，但是周圍的人都正常使用，在刷新頁面也好了。
關閉功能：關閉部分不重要的服務，或者服務內部關閉部分不重要的功能，以節約系統開銷，為重要的服務和功能讓出資源。淘寶每年雙十一促銷就使用這種方法，在系統最繁忙的時段關閉"評價“、”確認收貨“等非核心服務，以保證核心交易服務的順利完成。
5.冪等性設計
應用調用服務失敗后，會將調用請求重新發送到其他服務器，但是這個失敗可能是虛假失敗。比如服務已經處理成功，但因為網絡故障應用沒有收到響應，這時應用重新提交請求就導致服務重復調用，如果這個服務是一個轉賬操作，就會產生嚴重后果。
服務重復調用是無法避免的，應用層也不需要關心服務是否真的失敗，只要沒有收到調用成功的響應，就可以認為調用失敗，並重試服務調用。因此必須在服務層保證服務重復調用和調用一次產生的結果相同，即服務具有冪等性。
有些服務天然具有冪等性，比如將用戶性別設置為男性，不管設置多少次，結果都一樣。但是對於轉賬交易等操作，問題就會比較復雜，需要通過交易編號等信息進行服務調用有效性校驗，只有有效的操作才能繼續執行。
5.5 高可用的數據
不同於高可用的應用和服務，由於數據存儲服務器上保存的數據不同，當某台服務器宕機的時候，數據訪問請求不能任意切換到集群中其他的機器上。
保證數據存儲高可用的手段主要是數據備份和失效轉移機制。數據備份是保證數據有多個副本，任意副本的失效都不會導致數據的永久丟失，從而實現數據完全的持久化。而失效轉移機制則保證當一個數據副本不可訪問時，可以快速切換訪問數據的其他副本，保證系統可用。
5.5.1 CAP原理
高可用的數據有如下幾個層面的含義：
數據持久性
保證數據可持久存儲，在各種情況下都不會出現數據丟失的問題。為了實現數據的持久性，不但在寫入數據時需要寫入持久性存儲，還需要將數據備份一個或多個副本，存放在不同的物理存儲設置上，在某個存儲故障或災害發生時，數據不會丟失。
數據可訪問性
在多個數據副本分別存放在不同存儲設備的情況下，如果一個數據存儲設備損壞，就需要將數據訪問切換到另一個數據存儲設備上，如果這個過程不能很快完成，或者在完成過程中需要停止終端用戶訪問數據，那么這段時間數據是不可訪問的。
數據一致性
在數據有多份副本的情況下，如果網絡、服務器或者軟件出現故障，會導致部分副本寫入成功，部分副本寫入失敗。這就會造成各個副本之間的數據不一致，數據內容沖突。實踐中，導致數據不一致的情形有很多種，表現形式也多種多樣，比如數據更新返回操作失敗，事實上數據在存儲服務器已經更新成功。
CAP原理認為，一個提供數據服務的存儲系統無法同時滿足數據一致性、數據可用性、分區耐受性這三個條件。
在大型網站應用中，數據規模總是快速擴張的，因此可伸縮性即分區耐受性必不可少，規模變大以后，機器數量也會變得龐大，這時網絡和服務器故障會頻繁出現，要想保證應用可用，就必須保證分布式處理系統的高可用性。所以在大型網站中，通常會選擇強化分布式存儲系統的可用性（A）和伸縮性（P），而在某種程度上放棄一致性（C）。一般來說，數據不一致通常出現在系統高並發寫操作或者集群狀態不穩（故障恢復、集群擴容.....）的情況下，應用系統需要對分布式數據處理系統的數據不一致性有所了解並進行某種意義上的補償和糾錯，以避免出現應用系統數據不正確。
數據一致性可分為如下幾點：
數據強一致
各個副本的數據在物理存儲中總是一致的；數據更新操作結果和操作響應總是一致的，即操作響應通知更新失敗，那么數據一定沒有被更新，而不是處理不確定狀態。
數據用戶一致
數據在物理存儲中的各個副本的數據可能是不一致的，但是終端用戶訪問時，通過糾錯和校驗機制，可以確定一個一致的且正確的數據返回給用戶。
數據最終一致
這時數據一致性中較弱的一種，即物理存儲的數據可能是不一致的，終端用戶訪問到的數據可能也是不一致的（同一用戶連續訪問，結果不同；或者不同用戶同時訪問，結果不同），但系統經過一段時間（通常是一個比較短的時間段）的自我回復和修正，數據最終會達到一致。
因為難以滿足數據強一致性，網站通常會綜合成本、技術、業務場景等條件，結合應用服務和其他的數據監控與糾錯功能，使存儲系統達到用戶一致，保證最終用戶訪問數據的正確性。
5.5.2 數據備份
數據備份是一種古老而有效的數據保護手段，早期的數據備份手段主要是數據冷備，即定期將數據復制到存儲介質上並物理存檔保管，如果系統存儲損壞，那么就從冷備的存儲設備中恢復數據。
冷備的缺點是不能保證數據最終一致，由於數據是定期復制，因此備份設備中的數據比系統中的數據陳舊，如果系統數據丟失，那么從上個備份點開始后更新的數據就會永久丟失，不能從備份中恢復。同時也不能保證數據可用性，從冷備存儲中恢復數據需要較長的時間，而這段時間無法訪問數據，系統也不可用。
在網站實時在線業務中，還需要進行數據熱備，以提供更好的數據可用性。
數據熱備可分為兩種：異步熱備方式和同步熱備方式
異步方式是指多份數據副本的寫入操作異步完成，應用程序收到數據服務系統的寫操作成功響應時，只寫成功了一份，存儲系統將會異步地寫其他副本（這個過程有可能會失敗）
在異步寫入方式下，存儲服務器分為主存儲服務器（Master）和從存儲服務器（Slave），應用程序正常情況下只連接主存儲服務器，數據寫入時，由主存儲服務器地寫操作代理模塊將數據寫入本機存儲系統后立即返回寫操作成功響應，然后通過異步線程將寫操作數據同步到從存儲服務器。
同步方式是指多份數據副本的寫入操作同步完成，即應用程序收到數據服務系統地寫成功響應時，多分數據都已經寫操作成功。但是當應用程序收到數據寫操作失敗的響應時，可能有部分副本或者全部副本都已經寫成功了（因為網絡或者系統故障，無法返回操作成功的響應）
同步熱備具體實現的時候，為了提高性能，在應用程序客戶端並發向多個存儲服務器同時寫入數據，然后等待所有存儲服務器都返回操作成功的響應后，再通知應用程序寫操作成功。
在這種情況下，存儲服務器沒有主從之分，完全對等，更便於管理和維護。存儲服務客戶端在寫多份數據的時候，並發操作，這意味着多份數據的總寫操作延遲是響應最慢的那台存儲服務器的響應延遲，而不是多台存儲服務器響應延遲之和。其性能和異步熱備方式差不多。
傳統的企業級關系數據庫系統幾乎都提供了數據實時同步備份的機制。而一開始就為大型網站而設計的各種 NoSQL 數據庫（如HBase）更是將數據備份機制作為產品最主要的功能點之一。
關系數據庫熱備機制就是通常所說的Master-Slave 同步機制。Master-Slave 機制不但解決數據備份問題，還改善了數據庫系統的性能，實踐種，通常使用讀寫分離的方法訪問 Slave 和 Master 數據庫，寫操作只訪問 Master 數據庫，讀操作只訪問 Slave 數據庫。
5.5.3 失效轉移
數據服務器集群中任何一台服務器宕機，那么應用程序針對這台服務器的所有讀寫操作都需要重新路由到其他服務器，保證數據訪問不會失敗，這個過程叫作失效轉移。
失效轉移操作由三部分組成：失效確認、訪問轉移、數據恢復
1.失效確認
判斷服務器宕機是系統進行失效轉移的第一步，系統確認一台服務器是否宕機的手段有兩種：心跳檢測和應用程序訪問失敗報告
對於應用程序的訪問失敗報告，控制中心還需要再一次發送心跳檢測進行確認，以免錯誤判斷服務器宕機，因為一旦進行數據訪問的失效轉移，就意味着數據存儲多份副本不一致，需要進行后續一系列復雜的操作。
2.訪問轉移
確認某台數據存儲服務器宕機后，就需要將數據讀寫訪問重新路由到其他服務器上。對於完全對等存儲的服務器（幾台存儲服務器存儲的數據完全一樣，我們稱幾台服務器為對等服務器，比如主從結構的存儲服務器，其存儲的數據完全一樣），當其中一台宕機后，應用程序根據配置直接切換到對等服務器上。如果存儲是不對等的，那么就需要重新計算路由，選擇存儲服務器。
3.數據恢復
因為某台服務器宕機，所以數據存儲的副本數目會減少，必須將副本的數目恢復到系統設定的值，否則，再有服務器宕機時，就可能出現無法訪問轉移（所有副本的服務器都宕機了），數據永久丟失的情況。因此系統需要從健康的服務器復制數據，將數據副本數目恢復到設定值。
5.6 高可用網站的軟件質量保證
在網站運維實踐中，除了網絡、服務器等硬件故障導致的系統可用性風險外，還有來自軟件系統本身的風險。
5.6.1 網站發布
網站發布相當於提前預知的服務器宕機，過程可以更柔和，對用戶影響更小。通常使用發布腳本來完成發布，流程如下圖
發布過程中，每次關閉的服務器都是集群中的一小部分，並在發布完成后立即可以訪問，因此整個發布過程不影響用戶使用。
5.6.2 自動化測試
目前大部分網站都采用Web自動化測試技術，使用自動測試工具或腳本完成測試。比較流行的Web自動化測試工具是Selenium。Selenium運行在瀏覽器中，模擬用戶操作進行測試，因此Selenium可以同時完成 Web 功能測試和瀏覽器兼容測試。
5.6.3 預發布驗證
預發部服務器是一種特殊用途的服務器，和線上的正式環境唯一的不同就是沒有配置在負載均衡服務器上，外部用戶無法訪問。用於軟件上線前的驗證。
預發部服務器和線上正式服務器都部署在相同的物理環境（同一個數據中心甚至同一個機架上，如果使用虛擬機，甚至可能在同一個物理服務器上）中，使用相同的線上配置，依賴相同的外部服務。網站工程師通過在自己的開發計算機上配置hosts 文件綁定域名 IP 關系直接使用 IP 地址訪問預發布服務器。如果在預發布服務器上執行的測試驗證是正確的，基本可以確保在線上正式服務器部署時也沒有問題。
不過，也有可能因為預發部驗證而引入問題。因為預發布服務器鏈接的是真實的生產環境，所有的預發布驗證操作都是真實有效的數據，這些操作也許會引起不可預期的問題。比如創建一個店鋪，上架一個商品，就可能有真實的用戶過來購買，不能發貨會引起客訴。
此外，在網站應用中強調一個處理錯誤的理念是快速失敗（fast failed），即如果系統在啟動時發現問題就立刻拋出異常，停止啟動讓工程師介入排查錯誤，而不是啟動后執行錯誤的操作。
5.6.4 灰度發布
應用發布成功后，仍然可能發現因為軟件問題而引入的故障，這時候就需要做發布回滾，即卸載剛剛發布的軟件，將上一個版本的軟件包重新發布，使系統復原，消除故障。
大型網站的主要業務服務器集群規模非常龐大，比如某大型應用集群服務器數量超過一萬台。一旦發現故障，即使想要發布回滾也需要很長時間才能完成，只能眼睜睜看着故障時間不斷增加卻干着急。為了應付這種局面，大型網站會使用灰度發布模式，將集群服務器分成若干部分，每天只發布一部分服務器，觀察運行穩定沒有故障，第二天繼續發布一部分服務器，持續幾天才把整個集群全部發布完畢，期間如果發現問題，只需要回滾已發布的一部分服務器即可。
灰度發布也常用於用戶測試，即在部分服務器上發布新版本，其余服務器保持老版本（或者發布另一個版本），然后監控用戶操作行為，收集用戶體驗報告，比較用戶對兩個版本的滿意度，以確定最終的發布版本。這種方法被稱為 AB 測試。
5.7 網站運行監控
5.7.1 監控數據采集
廣義上的網站監控涵蓋所有非直接業務行為的數據采集與管理，包括供數據分析師和產品設計師使用的網站用戶行為日志、業務運行數據，以及供運維工程師和開發工程師使用的系統性能數據等。
1.用戶行為日志收集
用戶行為日志指用戶在瀏覽器上所做的所有操作及其所在的操作環境，包括用戶操作系統與瀏覽器版本信息，IP地址、頁面訪問路徑、頁面停留時間等，這些數據對統計網站 PV/UV 指標、分析用戶行為、優化網站設計、個性化營銷與推薦等非常重要。
具體用戶行為日志收集手段有兩種。
服務器端日志收集。這個方案比較簡單，Apache 等幾乎所有 Web 服務器都具備日志記錄功能，可以記錄大部分用戶行為日志，開啟 Web 服務器的日志記錄功能即可。其缺點是可能會出現信息失真，如IP地址是代理服務器地址而不是用戶真實IP；無法識別訪問路徑等。
客戶端瀏覽器日志收集。利用頁面嵌入專門的 JavaScript 腳本可以收集用戶真實的操作行為，因此比服務器日志收集更加精准。其缺點是比較麻煩，需要在頁面嵌入特定的 JavaScript 腳本來完成。
此外，大型網站的用戶日志數據量驚人，數據存儲與計算壓力很大，目前許多網站逐步來發基於實時計算框架 Storm 的日志統計與分析工具。
2.服務器性能監控
收集服務器性能指標，如系統 Load、內存占用、磁盤 IO、網絡 IO 等對盡早做出故障預警，及時判斷應用狀況，防患於未然。
此外，依據性能監控數據，運維工程師可以合理安排服務器集群規模，架構師及時改善系統性能及調整系統伸縮性策略。
目前網站使用比較廣泛的開源性能監控工具是 Ganglia，它支持發規模服務器集群，並支持以圖形的方式在瀏覽器展示實時性能曲線。
3.運行數據報告
除了服務器系統性能監控，網站還需要監控一些與具體業務場景相關的而技術和業務指標，比如緩沖命中率、平均響應延遲時間、每分鍾發送郵件數目、待處理的任務總數等。
對於服務器性能監控，網站運維人員可以在初始化系統時統一部署，應用程序開發完全不關心服務器性能監控。而運行數據需要在具體程序中采集並報告，匯總后統一顯示，應用程序需要在代碼中處理運行數據采集的邏輯。
5.7.2 監控管理
監控數據采集后，除了用作系統性能評估、集群規模伸縮性預測等，還可以根據實時監控數據進行風險預警，並對服務器進行失效轉移，自動負載調整，最大化利用集群所有機器的資源。
系統報警
在服務器運行正常的情況下，其各項監控指標基本穩定在一個特定水平，如果這些指標超過某個閾值，就意味着系統可能將要出現故障，這時就需要對相關人員報警，及時采取措施，在故障還未真正發生時就將其修復。
失效轉移
除了應用程序訪問失敗時進行失效轉移，監控系統還可以在發現故障的情況下主動通知應用，進行失效轉移。
自動優雅降級
降級是指網站為了應付突然爆發的訪問高峰，主動關閉部分功能，釋放部分系統資源，保證網站核心功能正常訪問的一個手段。淘寶每年“雙十一”促銷活動主動關閉“評價”、“確認收貨”等非核心功能，以保證交易功能的正常進行，就是一種降級。
網站在監控管理基礎之上實現自動優雅降級，是網站柔性架構的理想狀態：監控系統實時監控所有服務器的運行狀況，根據監控參數判斷應用訪問負載情況，如果發現部分應用負載過高，而部分應用負載過低，就會適當卸載低負載應用部分服務器，重新安裝啟動部分高負載應用，使應用負載總體均衡，如果所有應用負載都很高，而且負載壓力還在繼續增加，就會自動關閉部分非重要功能，保證核心功能正常運行。