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