首先，我們先來介紹一下 DevOps 的定義：
DevOps 是一種文化，它鼓勵包括開發和運維團隊在內的所有利益相關方之間進行協作，並通過自動化來改進流程，以提高軟件交付的質量和速度。
雖然 DevOps 本身就在強調企業內部文化的變革，但是你會發現在公司中大家還是使用“DevOps 工程師”這個頭銜，當然，與其它職位相同，DevOps 工程師也會有初級、高級之分。
我的整個職業生涯都專注於 DevOps，並在多家財富 500 強的公司工作過。本文中將和大家分享初高級 DevOps 工程師在面對配置管理相關問題時的不同解決方法。
配置管理
我對配置管理的定義是這樣的：它是一種確保公司所擁有的所有軟件和硬件資產在任何時候始終都是已知並被跟蹤的原則——這些資產未來的任何變更都是已知且被跟蹤的。您可以將配置管理看作是技術資產的一個隨時更新的庫存清單，一個單一的事實來源。
如何在 IT 部門中實施配置管理，與其說是一門科學，不如說是一門藝術：必須從引入變更的過程、實際變更的內容以及該變更是如何與許多其他依賴系統相關聯的等許多不同的方面加以控制和跟蹤。
對於 DevOps 工程師來說，配置管理最重要的 5 個方面是：
- 管理操作系統和中間件層軟件的安裝和配置
- 定義自己的 configuration-as-code（配置即代碼）
- 無論環境如何，都能確保可重複的變更是冪等的
- 瞭解系統某一個部分的變更可能會對另一個部分產生的影響
- 定義自己的 networks-as-code（網絡即代碼）
下面，我們以操作系統和中間件層軟件的安裝和配置、networks-as-code 爲例，來深入探討一下初高級 DevOps 之間不同的處理方法。
管理操作系統和中間件層軟件的安裝和配置
這是有運維操作背景的人們最熟悉的地方，需要對應用程序運行其上的多個操作系統和中間件有技術上的瞭解，需要知道 /etc/hosts 文件是什麼，以及它是做什麼的，並且在大多數情況下，使用命令行多於 GUI。
問題： 在數十臺甚至數百臺的服務器上安裝某些監控代理軟件
初級 DevOps 工程師的方法
編寫一個 powershell/bash 腳本，該腳本可以使用給定的主機名和憑證輸入來安裝和配置對應的代理。如果安裝失敗，則將失敗信息寫入日誌中，以便稍後查看。
高級 DevOps 工程師的方法
- 查看需要安裝此特定軟件的操作系統和版本，並嘗試將其標準化爲受支持的最低版本。
- 將軟件安裝在基礎鏡像中，這樣在默認情況下，就能將軟件安裝到任何新服務器上
- 使用配置管理工具，如 Chef 或 Ansible，而不是編寫需要管理和維護的自定義腳本
- 思考並從配置腳本中推導環境變量，以便在一次性部署到 100 臺服務器之前，先在預發佈環境中測試安裝變更
- 利用源代碼控制系統，該源代碼控制系統通常是基於 GIT 的，且具有可對代碼進行測試的持續集成工具
總結
從本質上講，高級 DevOps 工程師會以整體的視角來審視任何給定的問題，並試圖理解如何在企業範圍內實現這種變更，而不是簡單地解決單一給定的問題。坦白地說，這種技能的技術含量較低，更多的是評估和解決問題的能力。
定義自己的 configuration-as-code
這個問題與在某些配置管理工具（例如 Ansible 或 Chef）以及如何用所選工具實現實際配置的技術技能有關。
問題： 標準 RHEL 配置需要一個額外的掛載存儲驅動，該驅動的 /mount 位置需要 100gb 的可用磁盤空間。
初級 DevOps 工程師的方法
利用 Ansible 任務來連接磁盤驅動，擴展邏輯卷掛載並創建 /mount FS。並假定此操作僅在新配置的虛擬機上運行，因此，如果運行在現有服務器上，則可能會導致故障。
高級 DevOps 工程師的方法
- 爲標準 RHEL 配置部署創建一個 Ansible 角色
- 使用 set_fact 模塊爲現存掛載點定義一個變量
- 如果
/mount在給定的磁盤空間中不可用，則用腳本創建它
總結
和不同的開發語言（java 、.net 、javascript）一樣，每種語言都有自己的方式來實現代碼中的某些邏輯。高級 DevOps 工程師瞭解如何實現代碼的邏輯，以便解決配置所面臨的多種可能性，而初級 DevOps 工程師很有可能是首次使用給定的工具 / 語言來解決該問題，因此只是簡單地嘗試解決眼前的問題。
原文鏈接