slug: cloud-ops-orchestrator name: cloud-ops-orchestrator version: "1.0.0" displayName: 雲運維編排器 summary: 用 Terraform+Ansible 編排多雲基礎設施，內建漂移檢測、變更預演與安全銷燬，杜絕誤刪。 license: MIT description: |- 雲運維編排器為 AI Agent 提供以基礎設施即程式碼（IaC）為核心的多雲運維能力。它明確劃分 Terraform（資源生命週期）與 Ansible（系統配置）的職責邊界，覆蓋 AWS、GCP、Azure 三大雲，並內建狀態漂移檢測、變更預演（plan）、安全銷燬（帶保護期）、憑證隔離與回滾機制。

核心能力：多雲資源編排（Terraform）、批次配置管理（Ansible）、CloudFormation 模板、狀態漂移檢測與自動修正、變更預演與審批門禁、分環境（dev/staging/prod）隔離、安全銷燬保護期、憑證 vault 整合。

適用場景：多環境交付、災備切換、擴縮容演練、合規基線對齊、成本最佳化清理、一人公司 DevOps 自動化。

差異化：相比只羅列命令的原始方案，本技能新增職責邊界紅線（Terraform 管什麼/Ansible 管什麼）、漂移檢測工作流（plan-diff-apply 三段式）、銷燬保護期（prod 環境強制 72 小時鎖定與二次確認）、環境隔離矩陣、以及變更預演報告生成。所有銷燬類操作預設 dry-run，需顯式 --confirm 才執行。

觸發關鍵詞：雲, 基礎設施, 編排, terraform, ansible, aws, gcp, azure, drift, 銷燬, 部署, cloud, infra, provision tags: - 自動化 - 雲運維 - 基礎設施即程式碼 tools: - read - exec

雲運維編排器

用宣告式程式碼管理多雲基礎設施，把"手動點控制台"變成"可審計、可回滾、可預演"的工程化流程。本技能解決五個核心痛點：職責混淆（Terraform/Ansible 用錯地方）、狀態漂移（線上與程式碼不一致）、誤刪災難（destroy 不可逆）、憑證洩露（明文 AK/SK）、環境串味（dev 改動影響 prod）。

職責邊界紅線

這是最常出錯的地方。明確分工：

一句話原則：Terraform 宣告"有什麼"，Ansible 宣告"裡面跑什麼"。兩者通過 Terraform 輸出的主機清單（inventory）銜接。

快速開始

前置檢查

# 驗證工具鏈
terraform version   # >= 1.5
ansible --version   # >= 2.15
aws --version       # 或 gcloud / az 版本

# 驗證憑證（不要把憑證寫進程式碼）
aws sts get-caller-identity   # AWS
gcloud auth list              # GCP
az account show               # Azure

標準工作流（plan → review → apply）

./cloud-ops.sh init aws prod          # 初始化 prod 環境後端
./cloud-ops.sh plan prod              # 預演變更，生成報告
./cloud-ops.sh review prod            # 人工/Agent 審查 plan 輸出
./cloud-ops.sh apply prod             # 執行變更（需 --confirm）

安全銷燬（帶保護期）

./cloud-ops.sh destroy prod           # 預設 dry-run，只列出將刪除的資源
./cloud-ops.sh destroy prod --confirm # 二次確認後才真正銷燬
小蔥技能站7w4.net每天更新，海量AI技能等你發現。

prod 環境強制 72 小時保護期：距離上次 apply 不足 72 小時的資源拒絕銷燬，除非加 --override-lock。

命令參考

cloud-ops.sh <command> <env> [options]

命令:
  init      初始化工作目錄與 Terraform 後端
  plan      預演變更（dry-run）
  review    生成人類可讀的變更摘要
  apply     執行變更（需 --confirm）
  destroy   銷燬資源（預設 dry-run，需 --confirm，prod 有保護期）
  drift     檢測狀態漂移
  reconcile 修正漂移（apply 差異）
  config    執行 Ansible 配置
  output    匯出主機清單給 Ansible
  cost      估算資源成本

環境: dev | staging | prod
通用選項: --confirm, --dry-run, --module <name>, --override-lock

目錄結構（推薦）

infra/
├── cloud-ops.sh              # 編排入口
├── envs/
│   ├── dev/                  # 開發環境
│   │   ├── backend.tf        # 狀態後端
│   │   ├── terraform.tfvars  # 環境變數
│   │   └── providers.tf
│   ├── staging/
│   └── prod/
├── modules/                  # 可複用模組
│   ├── web-app/
│   ├── database/
│   ├── k8s-cluster/
│   └── serverless/
├── ansible/
│   ├── inventories/          # 由 terraform output 生成
│   ├── playbooks/
│   └── roles/
└── policies/                 # 策略與守衛
    ├── destroy-guard.json
    └── drift-baseline.json

漂移檢測工作流

漂移（drift）指線上實際資源與 Terraform state 不一致，常因手動改控制台引起。

# 檢測漂移（只讀，不改任何東西）
./cloud-ops.sh drift prod

輸出示例：

DRIFT REPORT - prod (2026-07-18 09:00)
──────────────────────────────────────
[CHANGED] aws_security_group.web
  ingress[0].from_port: 443 → 8443  (手動修改)
[MISSING] aws_s3_bucket.logs
  資源在 state 中但云上不存在（可能被手動刪除）
[EXTRA] aws_instance.bastion-2
  雲上存在但 state 中無（手動建立未納入 IaC）

建議:
  - reconcile: 用程式碼覆蓋線上（推薦用於配置類漂移）
  - import:    把手動資源納入 IaC（推薦用於未納管資源）
  - ignore:    標記為已知例外

# 修正漂移（把線上拉回程式碼定義）
./cloud-ops.sh reconcile prod --confirm

# 或反過來：把手動資源納入 IaC
./cloud-ops.sh import prod aws_instance.bastion-2 i-xxxxx

變更預演報告

plan 命令不僅輸出 Terraform 原始日誌，還生成結構化摘要，供 Agent 或人審：

./cloud-ops.sh plan prod

{
  "env": "prod",
  "summary": {
    "add": 3,
    "change": 1,
    "destroy": 0
  },
  "resources": [
    {"action": "create", "type": "aws_rds_instance", "name": "primary", "risk": "medium"},
    {"action": "create", "type": "aws_security_group", "name": "db", "risk": "low"},
    {"action": "update", "type": "aws_lb_listener", "name": "https", "risk": "high", "note": "修改監聽埠將導致短暫中斷"}
  ],
  "cost_delta": "+$340/月",
  "requires_confirm": true
}

risk 欄位幫助 Agent 決定是否需要人工確認。high 風險變更預設拒絕自動 apply。

環境隔離矩陣

環境之間通過獨立的 state 後端和 IAM 角色物理隔離，避免 dev 的 plan 誤讀 prod 的 state。

憑證管理（防洩露）

絕對禁止：把 AWS_ACCESS_KEY_ID 寫進 .tf 檔案或提交到 Git。

推薦方式（按優先順序）：

1. 環境變數/Profile（本地開發）：

export AWS_PROFILE=prod-admin
# 或
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx

1. CI OIDC（推薦，無長期金鑰）：

# CI 通過 OIDC 臨時獲取憑證，無需儲存 AK/SK
provider "aws" {
  # 憑證由 CI 執行時注入
}

1. Vault 引用（團隊共享）：

export AWS_ACCESS_KEY_ID=$(vault read -field=access_key secret/cloud/prod)

.gitignore 必須包含：

*.tfvars.local
*.tfstate
*.tfstate.*
.cr-credentials/

模組模板

Web 應用（含 LB + ASG）

module "web_app" {
  source = "./modules/web-app"
  name   = "api"
  env    = "prod"
  instance_count = 3
  min_size = 2
  max_size = 6
  health_check_path = "/health"
  vpc_id   = module.network.vpc_id
  subnets  = module.network.private_subnets
}

資料庫（含只讀副本與備份）

module "database" {
  source = "./modules/database"
  engine = "postgres"
  version = "15"
  instance_class = "db.r6g.large"
  allocated_storage = 200
  backup_retention = 30
  multi_az = true
  read_replica_count = 1
}

Kubernetes 叢集

module "k8s" {
  source = "./modules/k8s-cluster"
  kubernetes_version = "1.28"
  node_groups = {
    general = { instance_type = "t3.large", desired = 3, min = 2, max = 5 }
    spot    = { instance_type = "t3.medium", desired = 2, min = 0, max = 10, capacity_type = "spot" }
  }
}

Serverless 函式

module "serverless" {
  source = "./modules/serverless"
  runtime = "python3.11"
  memory = 512
  timeout = 30
  log_retention = 14
}

Terraform 與 Ansible 銜接

Terraform 建好主機後，輸出 inventory 給 Ansible：

# 1. Terraform 輸出主機資訊
./cloud-ops.sh output prod > ansible/inventories/prod.yml

# 2. Ansible 配置主機
./cloud-ops.sh config prod --playbook site.yml

inventory 生成模板：

all:
  children:
    web:
      hosts:
        web-0: { ansible_host: 10.0.1.10, ansible_user: ec2-user }
        web-1: { ansible_host: 10.0.1.11, ansible_user: ec2-user }
    db:
      hosts:
        db-primary: { ansible_host: 10.0.2.10 }

場景化指南

場景 A：新專案首次交付

./cloud-ops.sh init aws dev
./cloud-ops.sh plan dev --module web-app
./cloud-ops.sh apply dev --confirm
./cloud-ops.sh output dev
./cloud-ops.sh config dev --playbook bootstrap.yml

場景 B：生產擴容

# 修改 terraform.tfvars: instance_count = 5
./cloud-ops.sh plan prod              # 確認只增不減
./cloud-ops.sh review prod            # 檢查風險等級
./cloud-ops.sh apply prod --confirm   # 執行

場景 C：成本最佳化清理

# 識別閒置資源
./cloud-ops.sh cost dev --idle
# 銷燬（dev 無保護期）
./cloud-ops.sh destroy dev --confirm

場景 D：災備切換

# 提升只讀副本為主
./cloud-ops.sh plan prod --module database --promote-replica
./cloud-ops.sh apply prod --confirm
# 切換 DNS
./cloud-ops.sh config prod --playbook failover.yml

銷燬保護機制（防誤刪）

destroy 命令的多層防護：

1. 預設 dry-run：不加 --confirm 只列出將刪除的資源，不執行。
2. 保護期檢查：prod 環境資源建立後 72 小時內拒絕銷燬。
3. 資源白名單：policies/destroy-guard.json 標記的關鍵資源（如生產資料庫）強制要求 --override-lock。
4. 依賴順序：按依賴反向銷燬，避免"刪了 VPC 還留著 EC2"。

// policies/destroy-guard.json
{
  "protected_resources": [
    {"type": "aws_rds_instance", "pattern": "prod-*", "reason": "生產資料庫"},
    {"type": "aws_s3_bucket", "pattern": "backup-*", "reason": "備份桶"}
  ],
  "prod_lock_hours": 72,
  "require_override": ["prod"]
}

FAQ

Q：Terraform state 檔案放哪？ A：dev 用本地檔案；staging/prod 用 S3+DynamoDB 鎖，禁止本地存 prod state。init 命令會按環境矩陣自動配置後端。

Q：plan 顯示要刪一個資源但我沒動它？ A：常見於 state 漂移或程式碼被他人修改。先 git diff 看 .tf 改動，再 drift 檢查線上。不要盲目 apply。

Q：Ansible 和 Terraform 誰先執行？ A：Terraform 先建資源，output 生成 inventory，Ansible 後配置。變更時順序相反：先 Ansible 下線應用，再 Terraform 改資源。

Q：如何回滾？ A：IaC 的回滾 = git revert + apply。把程式碼回退到上一個版本重新 apply。前提是 state 沒被破壞性修改。

Q：多雲混用怎麼管憑證？ A：每個 provider 用獨立的 profile/專案，通過 alias 區分。不要在一個 provider 塊裡塞多個雲的憑證。

Q：CI 裡怎麼跑？ A：用 OIDC 短期憑證，CI 只對 staging 有 apply 許可權，prod 必須人工觸發。參考環境隔離矩陣。

故障排查

效能最佳化

1. 並行資源：Terraform 預設並行建立無依賴資源，-parallelism=20 可調高（小心 API 限流）。
2. state 拆分：大環境按模組拆成多個 state，避免單 state 過大導致 plan 慢。
3. Ansible fact 快取：開啟 fact_caching=redis 避免每次採集。
4. 增量 plan：用 -target 只 plan 變更模組，但注意不要長期依賴 target（會掩蓋漂移）。

依賴說明

執行環境

• Agent 平臺：支援 SKILL.md 的任意 AI Agent
• 作業系統：Linux / macOS（Windows 需 WSL2）
• Shell：bash 4+

第三方依賴

API Key 配置

• AWS：AWS_PROFILE 或 AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY，建議 OIDC。
• GCP：GOOGLE_APPLICATION_CREDENTIALS 指向服務賬號 JSON。
• Azure：az login 或 ARM_CLIENT_ID/ARM_CLIENT_SECRET/ARM_TENANT_ID/ARM_SUBSCRIPTION_ID。
• 所有憑證禁止寫入 .tf 檔案，必須通過環境變數或 Profile 注入。

可用性分類

• 分類：MD+EXEC（Markdown 指令 + shell/Terraform/Ansible 執行）
• 說明：Agent 呼叫 cloud-ops.sh 編排底層工具鏈，負責策略判斷、風險審查與人工確認觸發。

這個 Skill 的內容框架不錯，涵蓋了雲基礎設施管理的多個重要場景，但實際質量有待提升。優點是功能覆蓋較全面，有詳細的使用指南和最佳實踐；主要不足是文件中有很多重複內容和不完整句子，看起來像是初稿未經整理。最關鍵的是，它只提供了文字說明而沒有可執行的指令碼工具，對於想直接使用的使用者來說幫助有限。如果後續能補充完整的工具指令碼並最佳化文件質量，會更加實用。