基础设施即代码 (IaC) 是云原生应用和基础设施定义、供应和管理 IT 基础设施的一项基本实践。
译自 Why Most Companies Are Struggling With Infrastructure as Code，作者 Arshad Sayyad。
基础设施即代码 (IaC) 是云原生应用程序和基础设施定义、供应和管理 IT 基础设施的一项基本实践。团队无需通过临时脚本手动配置系统，而是可以将其基础设施需求编纂成机器可读的配置文件，并自动化许多中间步骤。这将软件工程实践引入基础设施管理，使组织能够更高效地配置基础设施，从而显著改善现代 IT 运营：它承诺提高一致性，减少人为错误，并显著提高基础设施部署的速度和可靠性，但并非完全如愿。
自动化基础设施供应和管理 可以 使组织快速扩展其环境，维护基础设施更改的版本控制，并确保开发、测试和生产环境保持一致。在当今基于云原生和微服务的架构中，这一点比以往任何时候都更加重要，因为基础设施需要灵活、可复制且易于大规模管理。尽管 IaC 具有诸多潜在优势，但它仍然是大多数组织面临的一个棘手挑战。在 GenAI 世界中，导致 IaC 创建和部署的封闭式、无上下文流程正在减缓工程团队的速度，并给企业增加高昂的额外开销。
根据Stacked Up：IaC 成熟度报告，只有 13% 的组织实现了 IaC 成熟度。然而，大多数 (51%) 组织表示，只有部分基础设施以代码形式表示，而 10% 的组织仍处于早期阶段，只有一小部分基础设施存储在试点项目的代码中。这些数字几乎没有描绘出组织中 IaC 成熟度的图景。鉴于 IaC 的诸多承诺的优势，是什么阻碍了组织完全且成熟地采用 IaC？
简而言之，实现 IaC 成熟度比听起来要复杂得多。事实上，60% 的受访者同意，“IaC 是一个强大的概念，但在实践中，它并没有带来我们希望的所有好处。”几乎所有受访者 (97%) 都报告了 IaC 的困难，并分享了以下最紧迫的问题：
- 56% 的人难以执行一致的配置，尽管使用了大量的工具
- 54% 面临与管理相关的挑战多个工具
- 45% 的人难以确定 IaC 的所有权，不确定谁负责构建模板、部署它们以及维护基础设施
虽然IaC 旨在使基础设施管理和部署更快更容易，但 51% 的开发人员表示，他们将超过 20% 的时间用于 IaC。这对组织来说具有重大的成本影响。对于开发人员来说，这绝非理想的结果，他们应该构建新的应用程序和服务，或提高现有应用程序和服务的业务差异化。只有 17% 的受访者表示，他们的开发团队实现了将 IaC 时间减少到 10% 以下的目标。
“99% 的基础设施专业人员报告说，在 IaC 工具之间切换会导致精神任务中断。”
面对这些挑战，75% 的基础设施利益相关者同意以下说法：“当任何人都可以进行更改时，负责追查 IaC 配置错误令人沮丧。”对 IaC 的那些未跟踪的更改增加了安全漏洞和治理风险的可能性，从而使组织面临风险。组织必须提高其 IaC 成熟度，以消除未跟踪更改和相关风险增加的可能性。
该研究确定了跨角色流程改进的多个领域，以提高 IaC 成熟度，主要集中在以下六个领域：
- 43% 缺乏编写有效 IaC 的技能
- 32% 担心确保 IaC 中的治理和安全
- 31% 遇到文档方面的挑战
- 28% 担心 IaC 的一致性
- 28% 难以管理 IaC
- 25% 希望 IaC 更好地支持特定应用需求
只有 2% 的受访者认为无需改进其当前的 IaC 流程，这进一步突显了大多数组织在 IaC 成熟度方面面临的挑战。
为了应对这些挑战，93% 的受访者认为需要创新才能使 IaC 更快速、更高效。目前，编写和维护 IaC 的责任广泛分散，这使得确保 IaC 在创建和维护期间的安全性和合规性更具挑战性。成熟的技术可以帮助管理这些分散的责任，并在不增加更多认知负荷的情况下提高与最佳实践的一致性。
一种可以帮助解决当前问题的特定技术是生成式基础设施即代码 (IfC)，其中 IaC 本身是从应用程序代码自动生成的，并带有符合最佳实践的防护措施。46% 的调查受访者表示，直接从应用程序代码生成 IaC 将是有利的。IfC 解决了团队面临的许多挑战，消除了许多组织都在努力应对的 IaC 所有权、时间和技能问题。最近，Gartner 在其年度炒作周期中将 IfC 认定为新兴范例，表明未来属于无缝、自动化和上下文感知的 IaC 创建方法。
管理云系统是一个不断发展的生态系统，需要开发、基础设施和执行团队学习新技术和技能，以持续交付客户应用程序。虽然与手动流程相比，IaC 已经实现了更精简和可扩展的部署机会，但仍需要新技术来提高整体 IaC 成熟度并交付组织所需的值。寻求提高其 IaC 成熟度和简化基础设施配置的组织应将 IfC 作为实现这两个目标的解决方案进行调查。