如何采用自动化即代码：将基础架构即代码扩展到策略即代码

在基础架构即代码（IaC）策略基础上，企业组织开始使用这些实践在运营生命周期的每个阶段实现 IT 流程的自动化。正如 IaC 将基础架构的构建、置备和部署标准化一样，IT 团队也可以采用运维即代码（OaC）将系统部署之后的管理和维护任务编写成代码。此外，还可以将这种方法扩展到策略即代码（PaC），以自动执行应用和解决方案的治理、风险和合规性流程。

实现自动化以加快交付和提升效率是应用和基础架构团队的共同目标，但大多数团队仍然依靠手动流程来进行 Day 2 运维和治理。自动化可以在这些领域提供与手动流程同样多的优势，但要想充分利用自动化执行 Day 2 流程，现有团队还需要学习新的工具和方法。采用运维即代码和策略即代码，可以很好地拓展现有的 IaC 战略的原则和做法，有效地简化这一文化变革，让企业组织能够运用所掌握的信息和所使用的工具来处理不同的任务。

按照 IaC 的方法，企业可以采用 OaC 和 PaC 将最佳实践编写成代码，并自动执行每个运维流程的常规任务，从而实现端到端自动化。这些自动化即代码方法可以确保以一致、可扩展的方法执行流程，从而让团队以最少的人工干预构建和维护自始至终都符合要求的应用、基础架构和工作负载。

构建和管理 IT 基础架构（例如服务器、云实例、操作系统、存储、负载平衡器和其他端点）历来是一个耗时的手动过程。但是，随着基础架构日益容器化并在多个平台（从数据中心到多云和边缘位置）上部署，其中一些基础架构以代码形式部署，尤其是在云中。

以代码形式部署时，基础架构可以更快地启动，以满足快速增长的需求和可扩展性需求。不过，这一好处也会给基础架构管理带来更多复杂性和紧迫性，企业组织通常需要每天置备和部署基础架构，并记录相关信息。为了跟上进度，IT 团队采用了 IaC 来自动执行这些流程。

IaC 涉及哪些内容？ 

IaC 方法通过自动执行的代码来定义、置备和管理基础架构。利用 IaC，我们可以创建包含基础架构规范的配置文件，从而更轻松地编辑和分发正确配置的基础架构和云实例。通过将这些规范编写成代码并将其记录下来，IaC 可帮助团队避免无记录的临时变更，并确保每次都置备相同的环境。

利用 IaC 实现基础架构自动化意味着开发人员在每次开发应用或推进部署时，都无需手动置备和管理基础架构组件，这可以大幅提高速度和一致性，同时减少人为错误和停机时间。通过这种方法，企业组织还可以在自动化代码中构建最佳实践，从而确保每项任务执行时会参考或依据团队成员之间共享的最佳做法、经验和专业技能。

扩展 IaC 策略

对于大多数企业组织而言，IaC 都是富有挑战性的转型，因为这需要花费时间开发新工具，并采用不同的工作方式。不过，团队也可以由此获得自由空间，可以更灵活地处理重点任务，更敏捷地响应问题。现在，许多自动化工具都可以处理 IaC，IT 团队已经在很大程度上融合了这种文化变革，并享受着随之而来的诸多好处。

通过使用专为 IaC 设计的现有方法和工具，IT 团队开始采用自动化即代码方法来处理整个运维生命周期内置备、配置和应用部署之外的流程。运维生命周期没有统一的定义，但通常分为以下阶段：

• Day 0：设计。指定基础架构的构建、配置和置备结构。 
• Day 1：部署。安装、设置和配置基础架构。
• Day 2：维护。管理、维护和更新与已部署基础架构相关的系统。

虽然 IaC 提供了在 Day 0 和 Day 1 构建并置备基础架构的一致方法，但它的重点是基础架构的初始部署和设置；而运维即代码则将这种方法应用于 Day 2 运维（例如管理、维护和更新系统），这将一直持续到应用或服务需要取消置备为止。

观看运维即代码概述

Day 2 任务（例如监控系统运行状况、安装升级和响应问题）一直都依赖于人力劳动。在服务器或应用停机时，IT 团队可能会收到工单警报，但停机只是表象，其根源还有待查明。所以，团队成员必须评估问题，因此可能会登录物理服务器，探查原因，并邀请其他 IT 专家来解决问题。问题最终解决，但这个过程需要花费相当的时间，尤其是在企业运营规模扩大时。

除此之外，Day 2 运维的复杂程度与 Day 0 和 Day 1 基础架构任务一样高，但对于应对 Day 2 运维的相关挑战，自动化尚未得到广泛应用。许多企业组织已经采用 IaC 来自动执行 Day 0 和 Day 1 流程，但现在，可以将同样的方法应用于从数据中心、跨云环境到边缘部署的运维，以帮助限制技术无序扩张和释放资源。

运维即代码涉及哪些内容？

运维即代码是 IaC 的自然发展。这涉及到利用基础架构和运维团队积累的知识（通过解决问题获得的所有经验），并通过自动化将其编写成代码。这意味着运维知识成为了可公开访问的资源，而不仅仅存在于团队成员手中。

OaC 是将团队的 Day 2 操作方法和运维知识标准化、代码化和系统化的过程。为了逐步采用 OaC，企业组织应： 

• 围绕供整个企业组织使用的通用代码库进行标准化，提高运维一致性。
• 将运维知识编写成代码，并将最佳实践构建到自动化流程中。 
• 将不同的工具和流程系统化为集成的端到端方法。

随着系统的智能程度、复杂程度和相互依赖程度越来越高，可以将 Day 2 的操作方法转变为可自动执行的代码。

与自动化的所有用途一样，运维即代码并不意味着取代人工，它让团队能够最大程度地减少繁琐的手动任务，转而重点关注具有前瞻性的项目。通过将团队的知识整合到共享方法中，OaC 还支持跨多种运营模式和团队结构开展的协作。

了解运维即代码在事件驱动时代的作用

通过将 IaC 和 OaC 方法扩展到治理，可以让 IT 团队摆脱臃肿、基于请求的流程，尤其是在执行策略时，策略是旨在确保运维遵守合规性要求、最佳实践和企业指令的规则、条件或指示。 

以代码形式定义和管理基础架构与运维之后，安全和合规性团队就可以使用相同的战略将策略应用于这些代码，并通过策略即代码方法将治理管理方法进行标准化。

自动化并不能从一开始就保证合规性和治理；必须一致地执行策略，以确保在运维生命周期的每个阶段正确应用 IaC 和 OaC。一直以来，常见的治理方法包括： 

• 构建包含审批的工作流，这导致个人很难提供临时解决方案。
• 通过基于角色的访问权限控制（RBAC）或基于属性的访问控制（ABAC）实施限制性安全权限，以控制哪些人可以在特定条件下或具有特定特征的情况下，以特定方式更改哪些技术。

这些手动方法容易出错，且非常耗时。策略即代码方法旨在将这些流程自动化。例如，可以设置自动化来防止 IT 员工创建不符合企业标准的云实例，或者防止他们交付不满足合规性要求的代码。RBAC 和 ABAC 仍然是需要的，但采用 PaC，可以创建更加精细的自动化流程，确定可以执行哪些操作以及何时执行。

策略即代码涉及哪些内容？

遵循与 IaC 和 OaC 类似的路线，PaC 将策略和安全要求编写成代码来自动执行合规性流程，这样可将标准构建到每个流程中，并在团队之间一致地执行相同的规则。通过使用代码来定义、更新、共享和执行策略，PaC 可以将治理集中化，还可以更轻松地以记录在案且一致的方式将策略高效应用于每个 IT 操作。

如果以代码形式定义策略，就可以在启动和部署基础架构时将策略无缝应用到基础架构中，并在执行自动化任务时将策略应用到运维中，这样一来，无论在何时何地进行自动化，都能执行标准方法。例如，如果某个员工正在运行自动化来修复特定主机上的问题，那么以代码形式编写到每个操作中的策略，就能阻止该员工执行违反团队规则的操作。

PaC 还支持根据约定标准调整技术环境和资源。例如，团队可以使用 PaC 来确保不将敏感的计算资源直接路由到互联网（这可能会违反安全策略），或者将其服务端口限制为仅 HTTPS 和 SSH。

随着 AI 助力提升各种系统的可扩展性，它使 IT 进一步超越人类本身所能实现和控制的范围。如果团队使用 AI 服务（例如红帽® Ansible® 自动化编码助手）来加速自动化开发，他们可以将策略写入代码，并从一开始就将治理注入学习模型。例如，AI 工具将策略纳入其学习模型之后，内容创建者就可以编写代码来自动维护规定的合规性要求。

利用 PaC 实现治理自动化，这可确保 AI 驱动型管理既能实现变革性效率，又能保持预期的控制，以便将合规性内置到面向 IT 团队制定的任务中。

阅读自动化策略即代码用例

简而言之，任何类型的自动化即代码转型主要都是文化挑战。利用从实现 IaC 自动化中获得的经验，IT 团队可以使用相同的方法和工具，在整个开发生命周期中采取更高效、适应性更强的运维方法。

实施 DevOps 给企业带来了各种好处和难题，但经过整个企业组织的共同努力和改变，可以实现根本性的工作方式和思维方式的转变。自动化总是涉及到改变任务的执行方式，但若要采用统一的自动化即代码战略，企业组织需要通过在运维的各个阶段共享实践来改变团队开展协作的方式。IaC、OaC 和 PaC 是这项工作的核心。

为了帮助实现向自动化即代码策略的文化转变，团队应：

• 像软件开发人员一样思考。使用 git 或其他存储库，同时在业务的各个领域培养现代开发和部署思维的文化。
• 树立自动化优先的理念。如果您手上有一个新项目，或者想要构建一些内容，不要只是埋首构建，首先要考虑如何将其实现自动化。可以从较为简单的自动化项目开始，然后逐步扩大范围。 
• 从个人的技能和经验入手。通过将企业组织中所有人积累的知识和经验构建到自动化中来填补人才缺口，以便在团队之间共享内容和专业知识。

通过将这一理念灌输到从系统设计到系统管理的每个团队中，就能成功采用自动化即代码。这些方法不仅偶尔可以将几个团队的任务实现自动化，并确保它们全部兼容，还可以让整个企业组织的团队共同制定共用的战略和规范。

要将这一战略落地，团队还必须超越只适用于某些用例、某些团队的临时解决方案。如果企业组织使用多种工具来推动流程，IaC 和 DevOps 可能会变得过于复杂，并产生技术债务。有了统一的自动化平台，用于执行配置、网络、基础架构或云任务的相同自动化语言就可以扩展到跨领域的运维任务，帮助 IT 团队管理整个端到端生命周期。

红帽® Ansible® 自动化平台包含实施企业级自动化所需的所有工具，包括事件驱动的 Ansible、分析、附加安全防护，以及一个由经过认证和验证的内容组成的广泛生态系统，可助您快速启动新的自动化计划。它采用人类可读的 YAML，因此各种技能水平的用户都可以在企业组织内共享、审核和管理自动化内容。 

借助 Ansible 自动化平台，您的企业组织可以将运维、基础架构和应用团队的经验编入基于 YAML 的 Ansible Playbook 和 Ansible Rulebook 中。Playbook 和 Rulebook 可用于将已知的解决方案模式构建到自动化即代码方法中，而事件驱动的 Ansible 可在发生特定事件时触发自动化。

通过将专业知识构建到 Playbook 和 Rulebook 中，您的团队可以自动执行 IT 响应，以限制配置偏移，最大限度地减少长期维护问题，并缩短平均解决时间（MTTR）。通过事件驱动的 Ansible 的模块化设计，您可以根据需要随时随地、跨领域以及针对运维生命周期各个阶段的用例自动执行 IT 操作。

进一步了解事件驱动的 Ansible

借助自动化编码助手，您可以将专业领域知识转换为可跨团队和跨领域扩展的可信 YAML 代码，从而使自动化即代码方法变得更加易于使用。用户可以用自然语言输入任务请求，自动化编码助手会生成用于创建 Ansible Playbook 的代码建议。这项服务可以帮助不同经验水平的团队成员提高生产力、效率和准确性，从而在整个企业组织内推动更加一致的自动化。

进一步了解 Ansible 自动化平台

红帽针对预配置的 Ansible 自动化平台环境提供了交互式教学。您可以使用这些互动式教学来测试、实践并学习如何高效地创建、管理和扩展 IT 实践，从快速开发和部署，到简化运维和分析，再到一致的端到端用户体验。

通过交互式实验室获取经验