假設我們有一個多人游戲網站，其中的一個服務器群包含大量的應用程序和消息服務器，它們負責支持各個玩家在多人游戲中的交流，以及生成玩家在太空射擊游戲中使用的可視化Web界面。...
在分析哪些方面需要實現自動化時，人們往往希望將所有軟件都自動化。可問題在于，自動化會在構建、配置、管理和修復網站軟件組件的層次上，再增加一層抽象。自動化只在最頂層再增加一層或多層抽象。...
這似乎是很顯然的，但是在計劃如何實現系統自動化之前，我們需要獲得所有利益相關者的信息，其中包括業務和執行管理人員。對于組織中參與一個特定網站的所有團隊來說，他們都會特別關注于自己的部門，而這種關注可能與其他團隊發生沖突。在創建和管理Web基礎架構自動化的過程中，無論各自團隊的目標是什么(節約成本、節約時間和確定業務優先級等)，他們都應該達成一致協議。...
假設一家公司已經有一些基礎架構，需要安裝新版本操作系統、新的應用服務器程序和新的代碼庫，并且有400個應用程序需要重新安裝。根據表5-1度量標準來看，如果以人工方式執行所有任務，那么為每臺服務器安裝和配置操作系統需要花費1小時，更新Web服務器需要10分鐘，安裝 Hadoop節點需要1小時，安裝 Rails)應用程序需要30分鐘。此外，我們還可以從這些度量標準計算出自動化可以節省的時間。...
在大型網站基礎架構上，我們希望盡可能地保持系統的一致性。我們希望在整個基礎架構上使用相同的硬件、軟件和功能。然而，系統維護通常會慢慢變成一種人工操作過程或自動化程度較低的過程，這意味著軟件和功能會經常出現不一致性，或許只有在稍后報告給系統管理團隊或開發團隊時，這些問題才會暴露出來。隨著網站訪客的增多，出錯的可能性也會進一步增加。...
在一個擁有大量服務器的大規模網站中，安裝新的應用服務器程序部署新代碼或檢査系統配置一致性等任務都非常耗費時間。假如要在數百甚至上千臺服務器上安裝應用服務器程序，一次只安裝一臺，那么這種龐大的任務量顯然需要另辟蹊徑才行:編寫一個 Shell a腳本，實現在中央數據存儲區上僅通過一個指令就可以安裝好應用服務器程序。...
即使在一些有著穩健和健康的文檔編寫文化的組織中，應用的進化和修改速度也會遠遠快于文檔編寫速度。現實情況是軟件變化速度遠遠快于文檔編寫速度，即使有自動化文檔系統，有時候我們仍然需要人工編寫一些文檔。這種文檔需要通過一定的技術轉換，方能提供給在特殊閱讀環境中的讀者閱讀，因此無法通過自動化方法維護。...
一個組織不可能只有高級軟件工程師或系統管理員，所以，只有基于特定規范的文檔就意味著只有高級技術人員才能閱讀這些文檔。這是一種機能障礙問題。當然，這些文檔也是必要和重要的，這已經比只有閱讀代碼才能了解應用程序的情況好很多了。然而，這并不是一種完整的文檔戰略與文化。...
最好的Web開發人員總是可以寫出帶有好注釋的漂亮代碼，但是，他們一般也不會編寫專門給非開發人員閱讀的文檔。最好的工程師愿意瘋狂地開發應用程序，但是不愿意花一點時間去編寫文檔或向其他人說明應用程序。他們認為，代碼就是文檔，而且有技術的人都能夠理解代碼，所以編寫額外的文檔是在浪費時間。...
一旦在Web組織中逐步培養起編寫文檔的文化，那么員工就會越來越依賴于這種實踐方法。這種文化還有一個十分重要的優點，即如果出現人員流失和變動，那么良好的文檔可以縮短新人的“交接”時間。此外，除了構成一般軟件開發過程的標準代碼注釋、跟蹤和源代碼控制過程，編寫文檔也是一種審查方法。在一些開發專用軟件的公司中，文檔顯得尤為重要，因為新員工一般很難理解復雜的定制應用程序，以及各個應用又是如何組成客戶所訪問的網站。如果文檔成為這一過程的組成部分，人們就一定會對軟件構建方式進行交流，工程師...
