基礎設施 - 管理 - 從自定義程式碼庫遷移到 Ansible 值得嗎？
一些背景：
當我開始在我目前的工作地點（在伺服器基礎設施中）時，已經有一個 bash、perl 和 python 程式碼庫用於在 linux 系統上遠端執行作業，編寫和維護這個程式碼庫的人花了數年時間改進它，在我開始之前。
儘管現有的程式碼庫可以做很多事情，但有時由於缺乏文件而很難使用。一些正在執行的腳本也已經過時了。我們非常依賴程式碼庫的作者。（可以添加，只允許作者編輯涉及的腳本）
最近我一直在試驗 Ansible 和配置 linux 環境、使用者、組、防火牆、安裝包和執行檢查。我建議開始將基本任務轉換為 Ansible，並隨著時間的推移將其與 Tower 或 AWX 結合起來，以更好地了解工作及其成功。
今天，其他人對這個想法並不太熱衷，尤其是程式碼庫的作者。作者不遷移到 Ansible 的論點是它“太抽象”。
問題是：
我應該嘗試推動遷移到 Ansible 嗎？
優點，我的看法：
- 許多功能已經通過模組存在。
- 新同事應該更容易上手。
- 可以與前端一起使用，例如 Tower 或 AWX。
- （可能）總體上更安全，因為自定義腳本要求您編寫自己的檢查。
- 我想 Tower/AWX 可以用於我們組織的其他團隊
缺點，我的看法：
- 學習曲線
- 將需要相當多的工作來實施。
- “另一個系統”來維護。
任何人都已經開始使用 Ansible，並且基礎設施已經到位，這樣做的利弊？
我可以補充一點，我不是工作場所的“最強聲音”，程式碼庫作者是我們所有人中“最資深的”。所以涉及到等級制度，我的建議必須有很好的動機才能被聽到。
對此感到高興。
PS。根據您的經驗，Ansible 可以是任何自動化工具。我只是碰巧了解了 Ansible。
由於您的情況顯然不僅是要從目前的情況中找到一條好的前進道路，而且還涉及工作場所的政治問題，因此看起來純粹的技術論點並不能一路幫助您。
實際上，我會說你已經有很多“配置即程式碼”很好，特別是如果你在 git 之類的東西中對其進行版本控制，那麼要做的主要因素是可讀性和努力擺脫匯流排因素：
如果重要任務只能由一個人可靠地執行，這對公司來說是不利的：這對個人來說不是真正的工作保障，但對公司來說是單點故障。
要引入新工具，請寫下商業案例向您的經理展示：您期望獲得什麼，這將如何影響他的底線？為您經常執行的某些任務創建概念驗證，並展示與命令式腳本語言相比，聲明性配置工具如何在實現或可讀性或團隊成員之間的技能共享方面產生影響。
當然，沒有什麼說您必須只使用一種工具：shell 腳本不一定會被 Ansible 之類的工具淘汰，但聽起來在您的公司管理它們的方式可能會減慢您的速度。