1. 课程导入与OCI治理全景

在传统云上运维中，工程师往往通过控制台点击、CLI 命令或脚本手工创建资源。这种方式在单次实验里足够快，但当环境数量增长到开发、测试、预生产、生产四套甚至更多时，问题会迅速暴露：谁在什么时候改了安全列表？为什么测试环境的实例规格和生产不一致？一次误删能否快速回滚？基础设施即代码（Infrastructure as Code，IaC）正是为回答这些问题而出现的工程实践——它把云资源的定义从"人的记忆和操作"转移到"可版本化、可评审、可重复执行的代码"中。

在 Oracle Cloud Infrastructure（OCI）中，IaC 并不是一个孤立工具，而是一套贯穿资源生命周期的治理能力。OCI 原生提供 Resource Manager 服务，它把 Terraform 作为执行引擎封装为托管服务；同时，工程师也可以在本地或 CI/CD 流水线中使用 Terraform、Pulumi 等工具，通过 OCI Provider 直接调用 API。理解这两条路径的差异，是后续所有章节的基础。

IaC 在 OCI 中的定位

OCI 的资源模型是层次化的：Tenancy（租户）之下划分 Compartment（隔离舱），Compartment 内承载 VCN、子网、计算实例、数据库、负载均衡等资源，而 IAM Policy 决定"谁能在哪个 Compartment 对哪类资源做什么"。IaC 工具做的事情，是把这套层次结构用代码描述出来，并通过 Provider 与 OCI API 交互。

以 Terraform 为例，一段最小的 OCI 配置通常包含三部分：Provider 声明（指定 region 与认证方式）、资源定义（如 oci_core_vcn）、以及输出（如 VCN 的 OCID）。执行 terraform plan 时，Terraform 会先读取远端真实状态（State），再与代码中的期望状态做差异比较，输出将要创建、修改或销毁的资源清单；terraform apply 才真正调用 API 执行变更。这个"计划—执行"分离的机制，是 IaC 可审计性的关键来源。

provider "oci" {
  region = "ap-singapore-1"
}

resource "oci_core_vcn" "app_vcn" {
  compartment_id = var.compartment_ocid
  cidr_block     = "10.20.0.0/16"
  display_name   = "app-vcn-prod"
  dns_label      = "appvcn"
}

上面这段示例中，cidr_block 与 display_name 是声明式输入，compartment_ocid 通过变量注入，避免把租户敏感信息硬编码进仓库。执行后，OCI 会返回该 VCN 的唯一 OCID，Terraform 将其写入 State 文件。State 是 IaC 的"账本"，它记录了代码对象与真实资源之间的映射关系，因此 State 的存放位置和访问控制本身就是治理议题。

环境治理的核心目标

环境治理要解决的不是"能不能创建资源"，而是"资源是否始终处于被理解、被约束、可追溯的状态"。在 OCI 语境下，可以归纳为四个目标：

• 一致性：同一套代码在开发与生产环境产生结构相同、仅参数不同的资源，消除"配置漂移"。
• 隔离性：通过 Compartment 与 IAM Policy 划定边界，使测试环境的操作不会波及生产数据。
• 可追溯：每一次变更都对应一次代码提交与一次 plan 记录，审计时能回答"谁改的、改了什么、为什么"。
• 可恢复：State 与代码共同构成重建能力，环境被误删后可在受控流程下重新收敛。

这四个目标之间存在张力。例如过度追求隔离会导致 Compartment 数量膨胀、Policy 难以维护；过度追求一致又可能让生产环境被迫接受不适合的默认参数。治理的本质是在这些张力中做出显式取舍，并把取舍写进规范，而不是留给个人习惯。

责任边界：谁负责什么

引入 IaC 后，责任并不会自动消失，而是重新分配。一个常见的误区是认为"用了 Terraform 就不会出错"。实际上，代码写错 CIDR、变量默认值指向生产 Compartment、State 被并发写入导致锁冲突，都是真实存在的风险。因此需要明确三层责任：

需要强调的是，OCI 的 IAM Policy 是责任边界的技术落地。例如一条 Allow group AppDeployers to manage instance-family in compartment AppTest 的语句，把"能管理计算实例"这一权限严格限制在 AppTest 隔离舱内。IaC 代码中引用的 Compartment OCID 必须与 Policy 授权范围匹配，否则 plan 阶段可能通过、apply 阶段却被拒绝。这种"代码—权限—资源"三者对齐，是 OCI 治理区别于纯工具使用的核心。

整体学习路径

本课程后续内容将沿着"认知—构建—治理—运维"的路径展开。先用一张图建立 OCI 治理全景，再逐步深入到具体能力。

图中左侧是声明层，中间是执行引擎，右侧是 OCI 真实资源与治理机制。可以看到，IaC 并不是直接"操作资源"，而是通过执行引擎把声明翻译成 API 调用；治理则同时作用于声明层（代码规范、变量约束）和资源层（Compartment、Policy、审计）。

从示例看治理如何落地

假设要为某应用创建测试环境，一个符合治理要求的做法是：先在 AppTest Compartment 下定义 VCN，CIDR 使用 10.30.0.0/16，与生产的 10.20.0.0/16 明确区分；子网按用途拆分为 web-subnet 与 db-subnet；安全列表只放行 443 与数据库端口。这些参数写入 test.tfvars，与生产参数文件分离。执行 terraform plan -var-file=test.tfvars 后，检查输出中是否出现意外的 destroy 条目——这是防止误删生产资源的第一道人工闸门。确认无误再 apply，随后在 OCI 控制台的 Compartment 视图中核对资源归属，并检查 Audit 日志中是否记录了本次变更。