Terraform @ Scale - 第 8 部分：面向决策者与架构师的 Operational Guide

Terraform @ Scale 不是一个工具使用的问题。它是一个 Operating Model 的问题。

如果没有结构化的治理模型，将会产生：

失控的模块 Fork
分散的安全标准
不明确的职责划分
不断上升的运营风险
合规性攻击面
由于错误配置导致的重大财务影响

我们系列的这篇收官文章总结了：

一个跨领域的 Terraform Operating Model
治理与结构原则
组织层面的职责划分
CI/CD 与策略集成
企业层面的风险聚合
一个完整的 Terraform @ Scale Blueprint

目标受众：CIO、CISO、Head of Platform Engineering、Cloud Architects。

面向决策者与架构师的 Operational Guide

1. Terraform Operating Model（参考架构）

Terraform 并不是通过更多代码来实现扩展。它真正实现扩展依赖于清晰的结构。

一个稳健的 Operating Model 由清晰分离的层级构成：

1.1 治理层

Policy-as-Code（Sentinel、OPA）
合规规则
命名标准
安全规范
成本控制机制

1.2 平台 / 抽象层

基础模块
网络标准
IAM 模式
日志与监控基础
安全控制

1.3 服务层

可复用的服务模块
贴近应用的基础设施
数据库模式
消息模式

1.4 Tenant / Project 层

产品或项目配置
环境特定参数
Root 模块

1.5 CI/CD 与策略执行

自动化流水线
强制性评审
Plan 验证
Apply 前的策略检查

1.6 可观测性与防护护栏

Drift Detection
部署监控
审计追踪
策略违规告警

1.7 生命周期与版本管理

模块版本化
语义化版本控制
弃用策略
迁移路径

关键在于：这些层级在技术层面与组织层面都是有意识地相互分离存在的。

2. 如何在企业层面编排 Terraform

在企业语境下的 Terraform 不是一堆代码仓库的集合。
它是一个被编排的系统。

2.1 GitOps 结构

推荐结构：

基础模块仓库
服务模块仓库
Environment / Root 仓库
中心化策略仓库

分支策略：

受保护的 Main 分支
Pull Request 评审
用于生产发布的版本 Tag

2.2 角色与职责

平台团队：基础模块与治理
产品团队：服务模块与 Root 模块
安全团队：策略定义与评审
FinOps：成本控制与报告

没有清晰的角色分离就会产生混乱。
有了清晰的角色分离就会产生可扩展性。

2.3 Workspaces / Stacks / Environments

Dev / Stage / Prod 之间清晰隔离
不允许隐式的环境切换
不允许手工操作 State

2.4 基础模块 vs. 服务模块 vs. Root 模块

基础模块：技术标准
服务模块：可复用的服务
Root 模块：具体实现

这种分离会显著降低 Blast Radius。

2.5 迁移流程

版本升级策略
Canary 部署
分阶段 Rollout
在传播前进行回归测试

2.6 评审与自动化流程

强制流水线
策略检查
自动化测试
生产环境不允许直接 Apply 权限

3. Blueprint：Terraform @ Scale 的落地实践

这个 Blueprint 展示了一个在企业环境中可靠可用的 端到端参考流程：从模块变更到可审计地 Rollout 到多个产品团队 - 包括治理、测试、传播与可观测性。

3.1 用一句话描述目标状态

平台团队交付带版本的基础模块 + Guardrails；产品团队通过清晰定义的 Root 模块进行消费；CI/CD 强制执行测试、策略与受控 Apply；Drift 与审计持续运行。

3.2 模块类型与契约

3.2.1 基础模块

定义技术标准（网络、IAM Baseline、日志、默认加密）
允许做 breaking changes - 但必须受控且少见
严格遵循 SemVer：MAJOR.MINOR.PATCH

3.2.2 服务模块

封装重复出现的服务
使用基础模块
具备稳定接口（Inputs/Outputs）

3.2.3 Root 模块

“Assemblies”：为某个具体 Environment 组合服务模块与基础模块
不包含应该放在模块里的逻辑
是进行产品 / 环境特定参数化的地方（所谓 “T-Shirt Sizes”，并实现强制性要求与框架条件）

3.2.4 契约规则（简单但有效）：

模块输出的 Outputs 要像 API 一样对待。
Breaking 的 Output 变更 = Major 版本。
可选：先 Deprecation 阶段（告警），然后再 Removal。

3.3 工件地图：哪些东西存在于哪里？

3.3.1 Repositories（示例结构）

A) 基础模块（Platform-owned）

terraform-<provider>-network
terraform-<provider>-iam
terraform-<provider>-logging
terraform-<provider>-kms

B) 服务模块（共享，通常由平台策展）

terraform-<service>-rds
terraform-<service>-kafka
terraform-<service>-ecs
terraform-<service>-oke

C) Root 模块 / Environments（Product-owned，受治理约束）

terraform-prod-app1
terraform-stage-app1
terraform-prod-app2
terraform-prod-shared

D) Policies & Controls（Security-owned，平台集成）

policies-opa 或 policies-sentinel
terraform-standards（Tagging、Naming、Conventions）

E) CI/CD Templates（Platform-owned）

pipelines-terraform-template
pipelines-policy-gates

3.4 Governance Gates：哪些事情可以在哪里发生？

原则如下: 如果某件事重要到要在生产环境运行，那它就重要到必须被自动化检查。

示例：Sentinel 作为 Mandatory Gate（AWS & OCI）

为了让 “Policy-as-Code” 不只是 PowerPoint 里的词汇，这里给出两个最小示例，它们在实践中立刻有意义：加密必须开启 - 而且必须是自动的，不是靠感觉。

AWS 示例：S3 不允许没有 Default Encryption

import "tfplan/v2" as tfplan

main = rule {
  all tfplan.resources.aws_s3_bucket as bucket {
    bucket.applied.server_side_encryption_configuration is not null
  }
}

OCI 示例：Block Volumes 必须加密

import "tfplan/v2" as tfplan

main = rule {
  all tfplan.resources.oci_core_volume as volume {
    volume.applied.is_encrypted is true
  }
}

重要：这些刻意是“很小”的策略 - 但它们表达了核心点：治理不是用来讨论的，它是用来被检查的。其他一切都只是贴着审计标签的希望。

Mandatory Gates（每次 non-dev / prod Apply 之前）

terraform fmt / validate
CI 中执行 terraform plan，Plan 作为工件
Policy-as-Code（OPA/Sentinel）
安全扫描（例如 tfsec/checkov）或等价方案
成本估算（FinOps Gate） - 至少给出 Delta 指示
评审（至少 2 Eyes，其中 1 个来自平台或安全团队 - 对敏感变更）
只能通过流水线 Apply（不允许“Laptop-Apply”）

3.5 示例 Repo 布局（Root 模块）

重要: Root 模块要可读、小，并遵循标准。复杂性在模块中，而不在 Root 中。这也意味着：Root 模块应尽可能只做模块组合；资源只应在有充分理由的例外情况下才直接声明。

terraform-prod-app1/
  main.tf
  variables.tf
  outputs.tf
  backend.tf
  env/
    prod.tfvars
    stage.tfvars
  README.md

3.6 端到端流程（Blueprint）

Phase 0 - 初始状态

基础模块已版本化（Tags）
Root 模块 pin 模块版本（不引用 “main branch”）
策略在 CI 中启用

Blueprint in Code：Root 模块消费带版本的模块（OCI 示例）

这在实践中是这样：一个 Root 模块刻意保持“笨”，只做组合。智能在模块里 - 稳定性来自 pin 住的版本。

# main.tf (Rootmodule: terraform-prod-app1)
module "network" {
  source = "git::ssh://git@repo/platform/terraform-oci-network.git?ref=v2.4.0"

compartment_id = var.compartment_id
vcn_cidr       = var.vcn_cidr
}

module "db" {
source = "git::ssh://git@repo/services/terraform-oci-db.git?ref=v1.3.2"

compartment_id = var.compartment_id
subnet_id      = module.network.private_subnet_id
db_name        = var.db_name
shape          = var.db_shape
}

记住：这个 Root 模块可以被评审。这个 Root 模块可以被审计。并且当某件事坏掉时，您知道是哪个模块 Release 负责 - 而不是在一个基于 diff 的恐怖片里醒来。

Phase 1 - 基础模块变更（平台团队）

示例：网络模块调整（例如新增 Subnet 选项、Logging Default、更严格的 SG 规则）。

规则：

PR 中清晰标注 Change Classification：PATCH / MINOR / MAJOR
Changelog 条目 + 迁移说明（如为 Breaking）
测试自动运行（见 3.7）

Output:
Tag v2.4.0（或 Breaking 时为 v3.0.0）

Phase 2 - 模块发布与分发

发布工件：

Git Tag + Release Notes
模块文档更新
面向使用方的 “Upgrade Notes”

分发机制：

Root 模块通过版本引用模块（Registry 或 Git Tag）
可选：内部 Registry，用于集中化审批

Phase 3 - 传播到服务模块（可选，但经常有意义）

如果服务模块使用基础模块：

在服务模块中提交 PR，引入新的基础模块版本
服务模块级别的回归测试
为服务模块打 Release Tag

Phase 4 - Root 模块更新（产品团队）

机制（推荐）：

自动 PR（Dependency Bot / Renovate）提升模块版本：
- base-network v2.3.1 → v2.4.0
CI 生成 Plan Diff
PR 展示：
- 资源变更
- 策略结果
- 成本指示

决策:
只有在 Gates 全绿且变更被理解时才 Merge。

Phase 5 - Pipeline Apply（受控）

Apply 发生在：

先 DEV / INT
然后 STAGE
然后 PROD

Rollout 策略（关键变更）：

Canary：先选 1 - 2 个非关键 Tenant
然后按波次 Rollout（Wave 1 - N）

原则:
您不是在扩展勇气 - 您是在扩展流程。

Phase 6 - Observability & Audit

Apply 之后：

Log / Audit Trail：
- 谁 Merge 了？
- 哪个 Plan 被 applied 了？
- 跑了哪些策略检查？
Drift Detection：
- Scheduled plan（read-only）+ Drift 告警
Incident Hooks：
- 如果出现 Drift / Policy Violation：Ticket / Alert

3.7 Testing Blueprint：测试什么，如何测试？

A) 模块 Unit / Contract 测试

输入校验测试（Variable Validations）
输出契约测试（Breaking detection）
静态分析

B) 集成测试（Ephemeral Environments）

每个 PR 创建临时 Stacks
Apply + Assertions（例如资源存在、Tag 已设置、加密开启）
结束时 Destroy（Cleanup）

C) 回归测试

对关键模块做基于 Snapshot 的 Diff 检查
每个模块版本都有 “Golden” Testcases

最小标准：
每个基础模块 Release 至少必须执行一次 Ephemeral Apply 测试，理想情况下还应具备 Contract 测试，并在需要时通过 terraform test 与内置 Terraform Testing Framework（推荐 - 因为它在 Terraform 内集成且标准化）或等价 Testing Harness 来做基础模块的集成测试。否则这不是 Release，而是在掷硬币。

示例：terraform test 作为 Contract / Default 测试

测试不需要“很大”才有效。哪怕只有一条 Assertion，也能保护您避免经典事故：有人悄悄改了一个 Default - 几周后所有人都在问，为什么日志量和成本突然爆炸。

# tests/network_defaults.tftest.hcl
run "validate_defaults" {
  command = plan

  assert {
    condition     = module.network.enable_flow_logs == true
    error_message = "Flow Logs 必须默认启用。"
  }
}

这不是学术测试。这是安全带。并且是的：如果您不把这种东西自动化检查，那么每个 Release 最终都是在掷硬币 - 只不过赌注是生产预算。

3.8 Policy Blueprint：哪些事情必须永远为真？

几类几乎永远有意义的策略示例：

Tagging / Owner / CostCenter 必填
默认加密（Storage、DB、Secrets）
没有例外流程就不允许开放 Security Groups（0.0.0.0/0）
IAM Least Privilege Patterns（没有理由不允许使用 Wildcards）
Region / Account / Subscription 限制
对成本驱动型规格类别要求审批

Exception Handling:

例外只能通过 Pull Request（PR）。例外必须被标记为机器可读的代码（例如 Annotation / Tag / Policy Input），否则它又会变回讨论而不是流程。Pull Request 强制透明性、至少由另一人评审、文档化以及一个审计追踪。
带到期日（Expiry）
带 Owner
带 Ticket / 说明

3.9 Rollback 与 Recovery Blueprint

在 IaC 中，Rollback 并不总是 “git revert 然后一切都好”。因此：

优先 forward-fix - 针对非破坏性错误
State 操作只能在紧急流程下进行
Breaking Changes必须有迁移路径
为 State 与关键资源提供 备份 / 版本管理
为常见 Failure Modes 提供 Runbooks（Locking、throttling、provider bugs）

3.10 结果：您将获得什么

可扩展的模块治理 - 无瓶颈
可复现的变更 - 职责清晰
Apply 前的可见性（Plan / Policy / Cost）
受控 Rollout - 而不是 “Big Bang”
审计能力不再依赖口头指令

这就是重点: Terraform @ Scale 不只是“更多 Terraform”。它同样是一个 用于运营组织与变更管理的框架。

3.11 Pipeline Blueprint 检查清单: Terraform Deployment Control Flow（Stage-by-Stage）

这是面向决策者的紧凑控制框架。只要这些步骤被遵守，Terraform 就是可控的。

Terraform 部署只能在以下条件下发生：

代码有效
Plan 透明
策略满足
评审已完成
Apply 只能通过流水线执行
审计与 Drift Detection 已启用

缺少任意一点，就不是受控运营。

Stage 1 - Static Validation（Shift Left）

目标: 在基础设施受影响之前阻止错误。

terraform fmt
terraform validate
Variable Validations
Linting
静态安全扫描

Gate:
❌ 有错误 - 无法合并 PR

Stage 2 - Plan 与透明性

目标: 对变更获得完整可见性。

CI 中执行 terraform plan
保存 Plan 工件
Diff 分析（Add / Change / Destroy）
展示成本差异

Gate:
❌ 未经检查的 Plan - 不允许 Merge

Stage 3 - Policy Enforcement

目标: 强制治理，而不是讨论治理。

OPA / Sentinel 策略检查
Tagging 校验
Encryption 策略
IAM 限制
Region / Account 限制

Gate:
❌ 策略违规 - Merge 被阻止
✔ 例外只能通过 Pull Request，并附理由与到期日

Stage 4 - Review 与批准

目标: 人工控制作为自动化的补充。

至少 2 名 Reviewer
敏感变更需要安全评审
基础模块变更需要平台评审

Gate:
❌ 没有批准的 PR - 不允许 Apply

Stage 5 - Controlled Apply

目标: 可复现、可审计的部署。

只能通过流水线 Apply
不允许手工 Apply
生产部署串行化
可选：Canary / Wave Rollout

Stage 6 - Post-Apply Observability

目标: 部署后的持续控制。

保存审计日志
Drift Detection（scheduled plan）
监控错误配置
Incident Hooks

4. 中央风险矩阵：整体风险全景

Terraform 风险不是孤立产生的，而是会叠加。
风险矩阵不是装饰元素。它是导航设备：哪里最可能出事 - 以及一旦出事会花多少钱？

量表：发生概率（EW）与影响（AW）分别为 1（低）到 5（高）。
Score = EW × AW。
风险等级： 1–5 低， 6–10 中， 11–15 高， 16–25 严重。

ID	风险	类别	典型原因	EW	AW	Score	早期指标	控制 / 对策	Owner（典型）
R1	由于“过大”的 Root 模块导致的 Blast Radius	运营	单体化 Root 模块、缺少分段、缺少 Stacks / Workspaces 隔离	4	5	20	Plan 过大（资源很多）、Apply 时间很长、Rollback 频繁	切分 Root 模块（按领域 / 服务）、分离 Stacks / Envs、渐进式 Rollout / Canaries	Platform + Product
R2	版本漂移（Provider / Module / Terraform）	技术 / 运营	未 pin 或不一致、不同 Toolchains、缺少升级流程	5	4	20	Lockfiles 不一致、“works on my machine”、无法解释的 Plan Diffs	版本 Pinning + Lockfile 策略、Renovate / Dependabot 流程、定义 Upgrade Windows	Platform
R3	State 风险（损坏、锁问题、手工介入）	运营	手工 State 操作、缺少 Locking、并行 Apply	3	5	15	Lock 冲突频繁、“force-unlock”、Ticket 里出现 State Edit	带 Locking 的 Remote State、Apply 串行化、State 操作的紧急流程	Platform
R4	缺少策略或未强制执行（Policy Drift）	安全 / 治理	策略“作为文档存在”，但不是 Gate；例外没有到期日	4	5	20	重复出现 Findings、手工批准、“临时”例外长期存在	Policy-as-Code（OPA / Sentinel）作为强制 Gate，带 Expiry 的 Exception Workflow	Security + Platform
R5	IAM 错误配置（Over-Permissioning、Privilege Escalation）	安全	复用不安全的 Patterns、缺少 Least-Privilege 评审、Ownership 不清晰	4	5	20	角色过宽、Admin 过多、未评审的策略	标准化 IAM 模块、安全评审、扫描（例如 tfsec / checkov）+ Policy Gates	Security
R6	Secrets 放在错误的位置（State、Logs、变量、Git）	安全 / 运营	Secrets 作为明文变量、Outputs、缺少 Secret Backends	3	5	15	Secrets 出现在 Plans / Logs、“sensitive” 缺失、Git 泄漏	Vault / Secret Manager 集成、sensitive Outputs、Pre-Commit 扫描、Redaction	Security + Platform
R7	模块之间的依赖链与 “Hidden Coupling”	技术	数据源 / Outputs 级联、隐式依赖、缺少 Contracts	4	4	16	小变更 → 大 Diff、意外 Replacements、循环依赖	模块 Contracts（Inputs / Outputs）、Breaking Change 规则、测试 + SemVer 纪律	Platform
R8	大规模 Apply 的 API Limits / Throttling	运营 / 技术	批量变更、并行度、Provider 限制	3	4	12	Retry 风暴、timeouts、零星 Provider 错误	Rate-Limit 策略、更小的 Batches、串行化 Apply、Provider 调优	Platform
R9	Drift（现实 ≠ 代码）	运营 / 治理	在云控制台手工改动、缺少 Drift 检测	4	4	16	意外的 Plan、Incident “Fix in Console”、缓慢偏离	Drift Detection（scheduled plans）、角色 / 权限限制、正常运营中的 “No ClickOps” 策略（允许带日志记录的手工 Break-Glass）。	Platform + Ops
R10	未经测试的变更（模块缺少回归测试）	技术 / 运营	没有 Test Harness、没有 Pre-Prod Gate、没有 Canary 阶段	4	4	16	Breaking Changes 只在 Prod 才暴露、高 Hotfix 率	模块测试（unit / integration）、Ephemeral Environments、Pipeline Gates	Platform
R11	成本风险（Overprovisioning / 失控扩容）	FinOps / 运营	缺少预算 / Guardrails、缺少标准规格、缺少评审	4	4	16	成本爆炸、缺少 Tags、资源无 Owner	Tagging 作为策略、Budget Alerts、PR 中的 Cost Estimation、标准 Tiers	FinOps + Platform
R12	组织层面不清晰（Ownership、责任、批准）	组织	平台 / 产品边界不清、“谁都能做一切”、缺少 RACI	5	3	15	阻塞、Ticket 乒乓、影子仓库 / Forks	RACI、Repo 策略、明确职责、平台 - 产品接口	Management + Platform

压缩总结：Top 风险（Score ≥ 16）

R1、R2、R4、R5、R7、R9、R10、R11 是典型的“企业经典问题”：高到严重，因为它们会相互强化。

此外我们还看到：

哪里真的需要治理（R4 / R5 / R6）。
哪里清晰结构可以实现扩展（R1 / R2 / R7 / R10）。
如果没人盯着，哪里会烧钱（R11）。

5. Terraform @ Scale 的 RACI 模型

流水线定义了 会发生什么。
RACI 矩阵定义了 谁负责。

只有两者结合，才会形成一个稳健的 Operating Model。

角色：

Platform Team - 模块标准、CI/CD、技术治理
Security / CISO-Organisation - 策略、风险控制
Product / Application Teams - 基础设施的使用与配置
FinOps / Controlling - 成本控制与预算透明

RACI 定义：

R (Responsible) - 执行
A (Accountable) - 承担总体责任
C (Consulted) - 主动参与咨询
I (Informed) - 被告知

覆盖端到端流程的 RACI 矩阵

阶段	Platform	Security	Product	FinOps
开发基础模块	R	C	I	I
发布基础模块（Release）	A	C	I	I
定义 / 修改策略	C	R/A	I	C
开发服务模块	R	C	C	I
修改 Root 模块（产品变更）	C	C	R/A	I
CI 中的策略检查	R	A	C	I
敏感变更的安全评审	C	R/A	C	I
Merge 前的成本检查	C	I	R	A
在 DEV 中 Apply	R	I	C	I
在 PROD 中 Apply	R	C	C	I
Drift Detection 与 Monitoring	R/A	C	I	I
例外批准（Policy Exception）	C	R/A	C	I
错误配置引发的 Incident	R	C	C	I
成本升级处理	C	I	C	R/A

解读（对管理层很重要）

Platform 在运营层面负责。
Security 对策略负责。
Product 对业务变更负责。
FinOps 承担预算责任 - 不是 Platform。

该模型避免两类经典错误：

Security 变成部署阻塞者。
平台团队被要求对成本或业务决策负责。

6. Executive Governance 影响

Terraform 不是自然而然就会成功运作的。仅仅使用 Terraform 与 Infrastructure-as-Code，并不会自动产生一个真实存在的治理体系。相反，Terraform 会放大既有的方法与工作流。而如果这些方法与工作流本身就不正确，那么结果也可能适得其反。

基础设施自动化会放大影响 - 无论是积极的还是消极的。

以一家中型企业为例，假设它有 25 个 IT 团队，每个团队都维持各自的习惯与工作方式 - 那么即使使用 Terraform，结果仍会是一个难以穿透的纠缠网络：由彼此不匹配的模块、流水线与依赖构成。每个团队都坐在自己的船上划桨没有意义。作为管理者，您必须确保所有人都朝同一个方向、以同一个节奏、用相同的桨前进。否则在 IaC 的加速下，这些团队只会更快、更直线地彼此漂离，不再形成一个和谐整体。

对于 CIO 与 CISO 而言，Terraform @ Scale 乍看之下意味着：

基础设施变成代码
代码变得与治理相关
治理变得可自动化

建议的进一步措施：

建立一个专职的平台团队
引入强制性的 Policy-as-Code 机制
中心化模块仓库
定义版本化规范
强制 CI/CD Gates
定期架构评审

7. 结论与展望

企业环境中的 Terraform 不是工具议题。
它更是一个架构与组织模型。

在没有 Operating Model 的情况下引入 Terraform，只是在扩展不确定性。
在清晰治理下运行 Terraform，则是在扩展稳定性。

下一阶段的扩展方向：

Infrastructure Testing Frameworks
Design for Failure Patterns
平台团队成熟度模型
与 Service Catalogs 的集成
自动化合规报告

Terraform @ Scale 的含义是：

控制而不阻塞。
标准化而不失去创新。
速度而不失去控制。

而正是在这里决定：基础设施是继续成为风险，还是成为竞争优势。

Ralf Ramge

Founder, Cloud Architect & IT Consultant

Terraform @ Scale - 第 8 部分：面向决策者与架构师的 Operational Guide

Terraform @ Scale - 第 7 部分：模块版本管理最佳实践

Terraform @ Scale - 第6c部分：高级模块依赖管理（献给那些自虐型工程师）

Terraform @ Scale - 第 6b 部分：嵌套模块的实践处理

Terraform @ Scale - 第 6a 部分: 理解与管理嵌套模块

Terraform @ Scale - 第 5b 部分: API Gateways

Terraform @ Scale - 第 5a 部分：理解API限制

证书倒计时已启动：200 天期限正威胁您的核心业务！

Terraform @ Scale - 第 4b 部分：可扩展 Data Sources 的最佳实践

Terraform @ Scale - 第 4a 部分：Data Sources 有风险！

Terraform @ Scale - 第 8 部分：面向决策者与架构师的 Operational Guide

面向决策者与架构师的 Operational Guide

1. Terraform Operating Model（参考架构）

1.1 治理层

1.2 平台 / 抽象层

1.3 服务层

1.4 Tenant / Project 层

1.5 CI/CD 与策略执行

1.6 可观测性与防护护栏

1.7 生命周期与版本管理

2. 如何在企业层面编排 Terraform

2.1 GitOps 结构

2.2 角色与职责

2.3 Workspaces / Stacks / Environments

2.4 基础模块 vs. 服务模块 vs. Root 模块

2.5 迁移流程

2.6 评审与自动化流程

3. Blueprint：Terraform @ Scale 的落地实践

3.1 用一句话描述目标状态

3.2 模块类型与契约

3.2.1 基础模块

3.2.2 服务模块

3.2.3 Root 模块

3.2.4 契约规则（简单但有效）：

3.3 工件地图：哪些东西存在于哪里？

3.3.1 Repositories（示例结构）

A) 基础模块（Platform-owned）

B) 服务模块（共享，通常由平台策展）

C) Root 模块 / Environments（Product-owned，受治理约束）

D) Policies & Controls（Security-owned，平台集成）

E) CI/CD Templates（Platform-owned）

3.4 Governance Gates：哪些事情可以在哪里发生？

示例：Sentinel 作为 Mandatory Gate（AWS & OCI）

AWS 示例：S3 不允许没有 Default Encryption

OCI 示例：Block Volumes 必须加密

Mandatory Gates（每次 non-dev / prod Apply 之前）

3.5 示例 Repo 布局（Root 模块）

3.6 端到端流程（Blueprint）

Phase 0 - 初始状态

Blueprint in Code：Root 模块消费带版本的模块（OCI 示例）

Phase 1 - 基础模块变更（平台团队）

Phase 2 - 模块发布与分发

Phase 3 - 传播到服务模块（可选，但经常有意义）

Phase 4 - Root 模块更新（产品团队）

Phase 5 - Pipeline Apply（受控）

Phase 6 - Observability & Audit

3.7 Testing Blueprint：测试什么，如何测试？

A) 模块 Unit / Contract 测试

B) 集成测试（Ephemeral Environments）

C) 回归测试

示例：terraform test 作为 Contract / Default 测试

3.8 Policy Blueprint：哪些事情必须永远为真？

3.9 Rollback 与 Recovery Blueprint

3.10 结果：您将获得什么

3.11 Pipeline Blueprint 检查清单: Terraform Deployment Control Flow（Stage-by-Stage）

Stage 1 - Static Validation（Shift Left）

Stage 2 - Plan 与透明性

Stage 3 - Policy Enforcement

Stage 4 - Review 与批准

Stage 5 - Controlled Apply

Stage 6 - Post-Apply Observability

4. 中央风险矩阵：整体风险全景

压缩总结：Top 风险（Score ≥ 16）

5. Terraform @ Scale 的 RACI 模型

覆盖端到端流程的 RACI 矩阵

解读（对管理层很重要）

6. Executive Governance 影响

7. 结论与展望

Ralf Ramge

ICT.technology