Met*_*win 4 automation installation infrastructure ansible
一些背景：
当我开始在我目前的工作场所（在服务器基础设施中）时，用于在 linux 系统上远程执行作业的 bash、perl 和 python 代码库已经就位，编写和维护此代码库的人花了数年时间对其进行改进，因为在我开始之前。
尽管现有的代码库可以做很多事情，但由于缺乏文档，有时很难使用。正在执行的一些脚本也已过时。我们非常依赖代码库的作者。（可以添加；只有作者可以编辑所涉及的脚本）
最近我一直在试验 Ansible 和配置 linux 环境、用户、组、防火墙、安装包和运行检查。我建议开始将基本任务转换为 Ansible，并随着时间的推移将其与 Tower 或 AWX 结合起来，以获得有关工作及其成功的良好概述。
今天，其他人并不太热衷于这个想法，尤其是代码库的作者。作者不迁移到 Ansible 的论点是它“太抽象了”。
问题是：
我应该尝试推动转向 Ansible 吗？
优点，我的看法：
缺点，我的看法：
任何人都已经开始使用 Ansible，并且基础设施已经到位，它的利弊？
我可以补充一点，在我的工作场所，我不是“最强的声音”，代码库作者是我们所有人中“最资深的”。所以涉及到一个等级制度，我的建议必须有很好的动机才能被听到。
对此感到高兴。
附注。根据您的经验，Ansible 可以是任何自动化工具。我刚好接触到 Ansible。
由于您的情况显然不仅涉及从当前情况中找到前进的好方法，而且还涉及工作场所的政治，因此纯技术论点似乎不会一直对您有所帮助。
实际上，我会说你已经有很多“配置即代码”是件好事，特别是如果你用 git 之类的东西控制它的版本，做某事的主要因素是可读性和努力摆脱总线因素：
如果重要任务只能由一个人可靠地执行，这对公司不利：这对个人来说不是真正的工作保障，但对公司来说却是单点故障。
要引入新工具，请写下一个商业案例向您的经理展示：您希望获得什么，这将如何影响他的底线？为您经常执行的某些任务创建概念证明，并展示与命令式脚本语言相比，声明式配置工具如何在实现或可读性或团队成员之间的技能共享方面产生差异。
当然，并没有说您必须只使用一种工具：shell 脚本不一定会被 Ansible 之类的工具淘汰，但听起来在您的公司中，它们的管理方式可能会减慢您的速度。