在完成系統的自動化時，可能沒有任何辦法能夠肯定全部效勞器能否都正確配置了某一個系統。假如部署一個審核系統，那么它就能夠執行一個自動化過程，肯定某個屬性（如配置文件中的某個設置）在成百上千個效勞器中能否堅持分歧。在自動化過程中，審核可能十分簡單，如考證某一個配置在一組效勞器中的完好性。例如，考證某一個版本的Apache配置是正確的，而且在一切效勞器上都堅持分歧，或者一組效勞器都運用了一個相同的配置文件。事實上，即便部署了高級配置管理框架，有一些東西依然會發作變化，不能堅持同步，因而運用一種辦法去考證效勞器、應用程序和配置的狀態，依然是自動化過程的重要組成局部；假如根底架構呈現了問題，那么一定要再次檢查根底架構的各個組件。
一定要留意，不同的配置管理或自動化框架會采用不同的方式去審核一個根底架構或多個效勞器、操作系統、應用程序及其配置參數。通常，審核一個Web根底架構的一切方面需求消耗大量的時間，但是與其當呈現問題時才思索必需審核哪些東西，不如想好哪些是不能不審核的。假設，消費網站呈現了一個嚴重問題。可能這個網站每月的用戶訪問量可達上百萬次，每年可以產生50萬美圓的收益。當召集一切人開會時關鍵是要肯定呈現了什么問題，以及如何處理這個問題。這時，問題可能就是由于應用程序代碼的版本不分歧而惹起的。大多數編程言語都會在應用程序的二進制文件中運用一種配置清單文件來肯定Web效勞器或應用效勞器中所部署的應用程序版本。
如今，一個中等范圍的網站根底架構就可能包含50-1000Web效勞器和應用效勞器。其中包含了大量的操作系統、應用程序、配置文件和參數，這時我們要逐一排查，才干肯定可能招致問題和影響網站訪問體驗的方面。
此刻應該運用審核軟件來肯定哪些效勞器呈現了問題。在該例中，某個應用程序二進制文件的版本不分歧性是問題的本源。下一步就是肯定哪一些Web效勞器或應用效勞器呈現了問題，這樣才干肯定應該從哪里開端處理問題。同樣，一些好的審核框架能夠幫我們創立用于修復當前效勞器的補丁包，然后再將它們部署到一切確認呈現問題的效勞器上。
審核過程中最難的一步是肯定要審核哪些局部。這個過程取決于正在運轉的應用程序類型、源代碼管理和局部方式、源代碼庫的類型、所運用的編程言語、操作系統及管理方式和業務需求。假如一個環境能夠容忍較長的停機時間，例如那些不會產生收益的網站，那么它的審核請求肯定低于那些每小時能產生大量收益的網站。后面一種環境需求運用一種高度可控和自動化的辦法來肯定呈現問題的位置。
在一個完整虛擬化的環境中，一切應用程序都運轉在一種虛擬化平臺上，只需有一個分配框架擔任重新裝置虛擬效勞器和重新部署應用程序代碼，我們就沒有必要引入一個復雜的審核框架，也沒有必要花太多時間去肯定發作問題的位置，除非這個問題總是頻繁地反復發作。假如完整重建一個效勞器并部署應用程序只需求8~15分鐘，那么就沒有必要去肯定這個效勞器所呈現的問題。
但是，在一個固定的根底架構或者一個未運用效勞器虛擬化的根底架構中，審核是十分重要的。在這種環境中，我們無法運用實時快照自動回滾修正，也不能啟動一個完整重建整個效勞器及應用程序的過程。
留意即便沒有運用虛擬化技術，有一些配置管理框架依然可以保管數據庫的修正歷史記載，并支持實時回滾修正。
與虛擬化環境相比，固定環境關于錯誤的容忍度較小，因而它們必需肯定需求審核哪些文件、配置和應用程序。有一些辦法能夠處理很大一局部問題，如源代碼管理學問庫，但是它們無法處理由系統級配置變化惹起的問題，如裝置內核補丁，更新網卡、磁盤控制器的固件和設備驅動程序，等等。這些修正通常會產生意想不到的結果，然后工程師必需自行剖析哪些網卡呈現了問題，然后才干在一切系統上逐一處理問題。
審核框架有以下優點：
尋覓一些未知問題；
改良系統與應用程序的性能；
協助Web根底架構從問題恢復，防止呈現幾小時以至幾天的停機時間；
在網站設計Web根底架構呈現問題時，定位那些日志或監控系統都無法定位的問題位置。
