文章探讨了自动化蔓延带来的隐性成本，包括认知负荷、维护耗时和安全风险，并提出了通过盘点、建立模式和运维即代码等方法进行整合的策略，以提高效率并降低技术债务。
译自：Why "automated" infrastructure might cost more than you think
作者：Justyn Roberts
在组织的某个角落，有一个 Jenkins 任务，没有人愿意去碰。这个任务是关键任务，每周四都会部署到生产环境。它是由一个三年前已经离开的人编写的，引用了可能仍然存在也可能不再存在的环境变量，而唯一的文档是一条 Slack 消息，上面写着“直接运行。它能用。”
这就是自动化蔓延，它正在悄然耗尽组织的工程速度。
没人追踪的隐性成本
在基础设施账单中没有体现出来的是记住哪些自动化存在于何处的认知负荷。花三十分钟来弄清楚为什么同一个任务在 Jenkins 中有效，但在 GitHub Actions 中却失败了。由于两个不同的工具管理着重叠的资源，导致环境之间出现了细微的偏差。团队可能会发现 高级工程师 将 20% 的时间仅仅用于维护自动化和保持现有管道的正常运行，而不是构建新功能。
那不是速度。那是在原地踏步。
团队可能会发现高级工程师将 20% 的时间仅仅用于维护自动化和保持现有管道的正常运行……那不是速度。那是在原地踏步。”
当所有人都专注于云支出时，真正的成本开始通过协调跨平台变更的会议、事件响应（需要三个团队同时在线，因为没人知道是哪个自动化修改了什么）以及需要一个月才能完成的安全审查（毕竟，审计师需要理解五种不同的权限模型）而浮出水面。
整合的真实面貌
成功的整合工作有一些共同点。
聪明的团队会从盘点开始。这不是一份一个月后就过时的电子表格，而是一份真实、持续维护的活生生的自动化目录，记录了存在哪些自动化、谁拥有它们以及它们做什么。团队无法整合他们看不见的东西。
他们在平台之前建立模式。问题不是“我们应该使用工具 X 还是工具 Y？”而是“我们真正需要哪三到四种自动化模式，以及实现每种模式最简单的方法是什么？”大多数组织都需要计划任务、事件触发的工作流、人工启动的运行手册和部署管道。其他一切可能都是特殊情况，应该证明其存在的合理性。
这些团队接受迁移是一个长期策略。蔓延不是一夜之间发生的，也不会一夜之间解决。目标是停止增加问题，同时逐渐减少现有足迹。
运维即代码的演进
通过运维即代码，团队可以从模式过渡到模板。这些模板作为扩展应用程序和 基础设施即代码 (IaC) 的基础。驱动 IaC 的相同原则——版本控制、可重复性、同行评审——现在正应用于运维本身。不仅仅是“我们如何部署这项服务？”而是“我们如何响应此警报？”和“我们如何引入新的数据库？”
做得好的团队并没有将运行手册视为可能过时的文档，而是将其视为可通过其实现进行自文档化的可执行代码。当步骤改变时，自动化也会改变。当自动化运行时，它会生成审计跟踪。
这不仅关乎效率。当操作知识存在于人们的头脑中（或者更糟，存在于某个人的笔记本电脑上未经文档化的脚本中）时，组织距离停机只有一次辞职的距离。
实际的下一步
对于希望摆脱这个陷阱的组织，这里有一些起点：
**先审计再行动。**花一周时间进行编目。与团队负责人交谈，找出当 X 出现故障时会发生什么，他们使用哪些脚本，以及如果通常运行脚本的人不在会发生什么。搜索仓库以查找管道定义。团队可能会发现他们不知道存在的自动化，以及没有人再使用但每个人都害怕删除的自动化。
**明确定义所有权。**每一段自动化都应该有一个所有者，他知道自己是所有者，并在适当的情况下与服务关联。大多数组织中孤立的管道数量表明这并不像听起来那么显而易见。团队可以移动，但服务通常不会。
**创建决策框架。**当有人需要新的自动化时，它应该放在哪里？写下标准，例如“如果是 CI/CD，使用 X。如果是计划操作，使用 Y。如果是事件响应，使用 Z。”使默认路径清晰，并考虑创建一个 GitHub 仓库来存储这些工件。
**衡量成本。**将维护现有自动化所花费的时间与构建新功能所花费的时间分开跟踪。如果维护持续占自动化相关工作的 30% 以上，则组织存在整合问题。
综合来看
有效的模式不是找到一个工具来统治所有。而是为“什么放在哪里”建立清晰的边界。
CI/CD 管道属于 CI/CD 系统。基础设施配置属于 Terraform、Pulumi 或团队已经标准化的任何工具。但中间层，包括计划维护任务、事件响应程序以及目前存在于 20 个不同地方的临时操作工作，是整合见效最快的地方。
这就是像 Rundeck 这样的运行手册自动化平台开辟利基市场的领域。它不是取代现有工具，而是为操作工作提供统一的控制平面。这些任务在组织的整个基础设施中进行编排，而不是重复。访问控制允许团队委派执行，而无需分发 SSH 密钥。审计跟踪提供了分散脚本永远无法提供的合规性故事。
其他工具也在此领域发挥作用。Ansible Automation Platform、各种 Kubernetes 运算符，甚至结构良好并带有适当 OpenID Connect (OIDC) 的 GitHub Actions。操作自动化应与应用程序代码一样严谨，这意味着对其进行整合，以便团队能够真正管理它。
不舒服的真相
自动化蔓延之所以持续存在，是因为它在局部是最佳选择。每个团队都使用他们熟悉的工具解决他们眼前的问题，这是一个合理的选择。蔓延是从合理的选择随着时间的推移而积累产生的。
“自动化蔓延之所以持续存在，因为它在局部是最佳选择……蔓延是从合理的选择随着时间的推移而积累产生的。”
解决它需要从不同的层面思考。这不仅仅是选择最适合工作的工具，而是为组织在未来五年内选择最佳的工具生态系统。这是一个更难回答的问题，需要大多数个人贡献者无法独自获得的认同。
然而，替代方案是技术债务，它看起来不像技术债务，并且似乎是业务照常。也就是说，直到有人离开，或者发生审计，或者发生事故揭示了基础是多么脆弱。
