在實現系統(tǒng)的自動化時，可能沒有任何方法可以確定全部服務器是否都正確配置了某一個系統(tǒng)。如果部署一個審核系統(tǒng)，那么它就可以執(zhí)行一個自動化過程，確定某個屬性(如配置文件中的某個設置)在成百上千個服務器中是否保持一致。在自動化過程中，審核可能非常簡單，如驗證某一個配置在一組服務器中的完整性。例如，驗證某一個版本的Apache配置是正確的，而且在所有服務器上都保持一致，或者一組服務器都使用了一個相同的配置文件。事實上，即使部署了高級配置管理框架，有一些東西仍然會發(fā)生變化，不能保持同步，因此使用一種方法去驗證服務器、應用程序和配置的狀態(tài)，仍然是自動化過程的重要組成部分；如果基礎架構出現了問題，那么一定要再次檢查基礎架構的各個組件。


 
定要注意，不同的配置管理或自動化框架會采用不同的方式去審核一個基礎架構或多個服務器、操作系統(tǒng)、應用程序及其配置參數。通常，審核一個Web基礎架構的所有方面需要耗費大量的時間，但是與其當出現問題時才考慮必須審核哪些東西，不如想好哪些是不能不審核的。假如，生產網站出現了一個嚴重問題?？赡苓@個網站每月的用戶訪問量可達上百萬次，每年能夠產生50萬美元的收益。當召集所有人開會時關鍵是要確定出現了什么問題，以及如何解決這個問題。這時，問題可能就是由于應用程序代碼的版本不一致而引起的。大多數編程語言都會在應用程序的二進制文件中使用一種配置清單文件來確定Web服務器或應用服務器中所部署的應用程序版本。
 
現在，一個中等規(guī)模的網站基礎架構就可能包含50-1000Web服務器和應用服務器。其中包含了大量的操作系統(tǒng)、應用程序、配置文件和參數，這時我們要逐一排查，才能確定可能導致問題和影響網站訪問體驗的方面。
 
此刻應該使用審核軟件來確定哪些服務器出現了問題。在該例中，某個應用程序二進制文件的版本不一致性是問題的根源。下一步就是確定哪一些Web服務器或應用服務器出現了問題，這樣才能確定應該從哪里開始解決問題。同樣，一些好的審核框架可以幫我們創(chuàng)建用于修復當前服務器的補丁包，然后再將它們部署到所有確認出現問題的服務器上。
 
審核過程中最難的一步是確定要審核哪些部分。這個過程取決于正在運行的應用程序類型、源代碼管理和部分方式、源代碼庫的類型、所使用的編程語言、操作系統(tǒng)及管理方式和業(yè)務需求。如果一個環(huán)境可以容忍較長的停機時間，例如那些不會產生收益的網站，那么它的審核要求肯定低于那些每小時能產生大量收益的網站。后面一種環(huán)境需要使用一種高度可控和自動化的方法來確定出現問題的位置。
 
在一個完全虛擬化的環(huán)境中，所有應用程序都運行在一種虛擬化平臺上，只要有一個分配框架負責重新安裝虛擬服務器和重新部署應用程序代碼，我們就沒有必要引入一個復雜的審核框架，也沒有必要花太多時間去確定發(fā)生問題的位置，除非這個問題總是頻繁地重復發(fā)生。如果完全重建一個服務器并部署應用程序只需要8~15分鐘，那么就沒有必要去確定這個服務器所出現的問題。
 
然而，在一個固定的基礎架構或者一個未使用服務器虛擬化的基礎架構中，審核是非常重要的。在這種環(huán)境中，我們無法使用實時快照自動回滾修改，也不能啟動一個完全重建整個服務器及應用程序的過程。
 
注意即使沒有使用虛擬化技術，有一些配置管理框架仍然能夠保存數據庫的修改歷史記錄，并支持實時回滾修改。
 
與虛擬化環(huán)境相比，固定環(huán)境對于錯誤的容忍度較小，因此它們必須確定需要審核哪些文件、配置和應用程序。有一些方法可以解決很大一部分問題，如源代碼管理知識庫，但是它們無法解決由系統(tǒng)級配置變化引起的問題，如安裝內核補丁，更新網卡、磁盤控制器的固件和設備驅動程序，等等。這些修改通常會產生意想不到的結果，然后工程師必須自行分析哪些網卡出現了問題，然后才能在所有系統(tǒng)上逐一解決問題。
 
審核框架有以下優(yōu)點:
 
尋找一些未知問題；
改進系統(tǒng)與應用程序的性能；
幫助Web基礎架構從問題恢復，避免出現幾小時甚至幾天的停機時間；
在網站設計Web基礎架構出現問題時，定位那些日志或監(jiān)控系統(tǒng)都無法定位的問題位置。