基礎設施的發布管理
是否有人將發布管理主體用於基礎設施的系統管理，就像它用於軟體開發一樣？
我已經在系統管理領域工作了 10 多年，但我還沒有接觸過一家公司，它使用發布管理主體來管理伺服器基礎設施和應用程序配置，就像它在軟體開發中所做的那樣。諸如外部化配置、檢查版本化儲存庫中的配置、將配置自動部署到系統、通過適當的非產品環境進行推廣、組件的自動單元測試等。
我很好奇任何人用來管理這些配置和部署的應用程序和流程。此外，是否有人會為配置部署創建發行說明？
附加評論- 我同意盲目地訂閱一個方法框架不會讓你成為一個更好的組織，這不是我要問的。我試圖確定是否有某些概念可以應用於系統管理，就像它們應用於軟體開發一樣。例如，如果我想在 prod 中對系統進行配置更改，我怎麼知道我在 dev 中測試的內容是真正轉移到 prod 中的內容？我想說，如果您有一個系統，其中該配置被檢入儲存庫，版本化然後自動部署到 prod 中的系統，這將大大有助於確保一旦將它們部署到生產中就可以正常工作。
我實際上花了很多時間思考這個問題。在我的大型網際網路公司，我的工作是對執行在我們許多伺服器上的軟體進行內部發布管理。實際上，我們已經做了很多工作來嘗試將發布管理原則應用於基礎架構或系統管理。雖然我們的軟體包系統對外開放，但一般原則應該是一樣的。
下面是一個例子：過去，當設置 web 伺服器時，管理員必須記住將 vip 地址設置為環回地址上的別名，以使機器進入輪換狀態。我們不斷地與機器被換掉而錯過這一重要步驟作鬥爭。結果將是一個伺服器坐在那裡準備好，但無法提供流量，因為 vip 將其標記為關閉。
我們使用的解決方案是一個軟體包，我們將它集成到我們的一般版本中。我們有一個模板系統，可為大約 600 個場中的每一個場生成特定於伺服器場的設置。然後，在安裝匹配的軟體包時，打包系統會應用這些設置。
因此，我們創建的這個相對簡單的包只是採用了每個農場的設置並將其設置在系統環回上。這完全消除了系統被 vip 意外標記為關閉的問題。
我們也將此方法應用於系統的其他部分。結果是我們逐漸將大部分系統配置轉移到我們的軟體發布系統中。我們建構和分發包含所有必要軟體包的軟體版本。這些包依次獲取每個農場的設置並將它們應用於修復諸如環回地址之類的東西。
這仍然是一個相當高級的機制。還有其他系統可確保在伺服器上傳入基本作業系統並安裝系統管理員使用者帳戶。但是，一旦您超出該級別，我們會非常努力地將所有可能的系統配置移動到設置中，然後由軟體包讀取。我們對這種管理大約 10,000 台伺服器的方法感到非常滿意。