背景信息：
当我开始在我目前的工作地点（服务器基础设施）工作时，已经有了一个 bash、perl 和 python 代码库，用于在 Linux 系统上执行远程作业，在我开始工作之前，编写和维护这个代码库的人已经花了数年时间来完善它。
虽然现有的代码库可以做很多事情，但由于缺乏文档，有时很难使用。一些正在执行的脚本也已经过时了。从这一点来看，我们非常依赖代码库的作者。（可以补充一下：只有作者才被允许编辑所涉及的脚本）
最近我一直在尝试使用 Ansible 和配置 Linux 环境、用户、组、防火墙、安装软件包和运行检查。我建议开始将基本任务转换为 Ansible，并随着时间的推移将其与 Tower 或 AWX 结合起来，以便对作业及其成功情况有一个良好的了解。
如今，其他人对这个想法并不太热衷，尤其是代码库的作者。作者不转向 Ansible 的理由是它“太抽象了”。
问题是：
我是否应该尝试转向 Ansible？
在我看来，优点如下：
- 许多功能已经通过模块实现。
- 新同事应该更容易接受。
- 可与前端一起使用，例如 Tower 或 AWX。
- （可能）总体上更安全，因为自定义脚本要求您编写自己的检查。
- 我认为 Tower/AWX 可以供我们组织的其他团队使用
我认为的缺点是：
- 学习曲线
- 将需要相当多的工作来实现。
- 需要维护的“另一个系统”。
有谁已经尝试过 Ansible，并且已经建立了基础设施，其优缺点是什么？
我可以补充一点，在我的工作中，我并不是“最有发言权的人”，而代码库作者是我们所有人中“最资深的人”。因此，这里面存在着一个层级，我的建议必须经过充分的激励才能被听取。
很高兴能有这样的想法。
附言：就您的经验而言，Ansible 可以是任何自动化工具。我只是碰巧了解了 Ansible。
答案1
由于您的情况显然不仅要从当前情况中找到一条好的出路，而且还要涉及工作场所的政治，因此纯粹的技术论点似乎并不能完全帮助您。
从实际角度来说，我想说的是，你已经拥有了很多“配置即代码”，这是件好事，尤其是如果你已经在 git 之类的东西中对它进行了版本控制，那么要做的主要因素就是可读性，并努力摆脱总线因素：
如果重要任务只能由一个人可靠地完成，那么对于公司来说这不是好事：这对于个人来说不是真正的工作保障，但却是公司的单点故障。
要引入新工具，请写下一个业务案例来向您的经理展示：您期望获得什么，这将如何影响他的底线？为您经常执行的某些任务创建概念证明，并展示与命令式脚本语言相比，声明式配置工具如何在实施或可读性或团队成员之间的技能共享方面产生影响。
当然，没有任何规定说你必须只使用一种工具：Shell 脚本不一定会被 Ansible 这样的工具所取代，但听起来在你的公司中，它们的管理方式可能会减慢你的速度。
答案2
我认为值得与您的前辈交谈并仔细听取他的意见，正如您所说，他既有经验又很聪明。
对于下一步行动，你必须非常清楚地了解事情为什么会变成现在这个样子的根本原因。还要询问他应该从他的角度解决哪些挑战或弱点。很多时候，决策背后都有一些根本原因，而对于新加入公司的人来说，这些原因很难理解。
根据您收到的信息，您可能需要回答自己这个问题：这家公司是否适合您，因为您在这里描述的方式确实引起了一些人的注意。如果您决定这份工作适合您，您应该通过关注已表达的问题来帮助您的上级。如果不是，只需更新您的简历并开始寻找新的机会。
正如其他人在评论中指出的那样，决定性的不是特定工具的名称，而是它是否是最适合特定情况和公司的工具。考虑到具体情况，进化而不是革命可能是正确的答案。
例如，一个进化步骤可能是继续使用现有脚本，但使其更方便使用，同时扩大能够使用脚本所提供功能的人员范围。也许版本控制以及使用工具伦德克将是向前迈进的适当方法。
通常，展示简短的 POC 会有所帮助，你可以在其中展示特定工具如何以更智能的方式解决具体任务。这种方法通常比讨论或论文更能说服他人。你还应该积极寻求公司内部的支持，因为无论选择哪种工具，最重要的是它的接受程度。
话虽如此，我个人也喜欢 Ansible，您已经指出了它的优点。但是，您提出 Ansible 的方式可能会被内部误认为是（消极的）革命性举措，甚至是反对。
最重要的是倾听，并采取一些巧妙的行动。祝你好运！