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

立足于基础架构即代码（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 系统的能力和效率，它使 IT 进一步超越人类本身所能实现和控制的范围。如果团队使用 AI 服务（例如搭载 IBM watsonx Code Assistant 的红帽® Ansible® Lightspeed）来加快自动化开发，他们就可以将策略编写为代码，并从一开始就将治理注入学习模型。例如，AI 工具将策略纳入其学习模型之后，内容创建者就可以编写代码来自动维护规定的合规性要求。

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

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

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

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

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

通过将这一理念灌输到从系统设计到系统管理的每个团队中，就有望成功采用自动化即代码。有了这些方法，自动化任务就不再只是少部分团队零散、无法保证兼容性的尝试，它们能为企业组织中的所有团队提供一种可以共同塑造、共享共用的策略和规范。

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

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

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

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

详细了解 Event-Driven Ansible

搭载 IBM watsonx Code Assistant 的红帽 Ansible Lightspeed 可以帮助您将特定领域的专业知识转换为可信的 YAML 代码，实现跨团队和跨领域的规模化应用，从而使自动化即代码方法更易于使用。用户可以使用自然语言输入任务请求，Ansible Lightspeed 将与 IBM watsonx 基础模型交互来生成代码建议，以用于创建 Ansible Playbook。这项服务可以帮助各种经验水平的团队成员提高生产力、效率和准确性，从而在整个组织内推动实现更加一致的自动化。

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