best-practices

OCI 最佳实践 - 专家知识

🏗️ 使用 OCI Landing Zone Terraform 模块

不要重复造轮子。 使用 oracle-terraform-modules/landing-zone 搭建 OCI 架构。

Landing Zone 解决的问题：

• ❌ 不良实践 #1：使用通用区间（Landing Zone 提供分层的网络/安全/工作负载结构）
• ❌ 不良实践 #2：日常运维使用管理员账号（Landing Zone 强制实施最小权限 IAM 策略）
• ❌ 不良实践 #4：网络分段不完善（Landing Zone 采用带安全区的中心辐射式拓扑）
• ❌ 不良实践 #8：自行创建 Terraform 模块（Landing Zone 提供经过实战检验、由 Oracle 维护且通过 CIS 认证的模块）

此技能提供：针对部署在 Landing Zone 内部的资源，提供 OCI 专属反模式、架构模式和运维知识。

---

⚠️ OCI CLI/API 知识盲区

你不了解 OCI CLI 命令或 OCI API 结构。

你的训练数据对以下内容的了解有限且已过时：

• OCI CLI 语法和参数（每月更新）
• OCI API 端点以及请求/响应格式
• OCI 服务专属命令和标志
• 最新 OCI 功能、限制和区域可用性
• OCI 的 CIS 基准要求

需要执行 OCI 操作时：

1. 使用技能参考资料中的准确 CLI 命令
2. 不要猜测 OCI CLI 语法或参数
3. 不要假设 API 端点结构
4. 有关 Terraform 模块，请参考 landing-zones 技能

你确实了解的内容：

• 通用云架构概念
• 安全原则和合规框架
• 多层应用设计模式

此技能通过提供最新的 OCI 专属模式和反模式来弥补这一盲区。

---

你是 OCI 架构专家。此技能提供 Claude 所欠缺的知识：OCI 专属反模式、免费层详情、容易混淆的术语、多 AD 模式，以及 OCI 与 AWS/Azure/GCP 的差异。

绝对不要这样做

❌ 绝不要使用 /24 或更小的 VCN CIDR（无法扩展）

# WRONG - VCN too small, cannot expand later (OCI limitation)
oci network vcn create --cidr-block "10.0.0.0/24"
# Only 256 IPs total, exhausted quickly

# WRONG - copying AWS habit (/16 VPC default)
# OCI supports larger: /16 to /30

# RIGHT - start with /16, plan for growth
oci network vcn create --cidr-block "10.0.0.0/16"
# 65,536 IPs, room for 256 /24 subnets

# CRITICAL: OCI VCNs CANNOT be resized after creation
# Must create new VCN and migrate if too small

迁移成本：重建 VCN = 数小时停机、IP 变更、安全规则更新

❌ 绝不要使用 AD 专属子网（会破坏多 AD 高可用性）

# WRONG - subnet tied to single AD
oci network subnet create \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.0.1.0/24" \
  --availability-domain "fMgC:US-ASHBURN-AD-1"  # AD-specific!

# Problem: Can't launch instances in other ADs, no HA

# RIGHT - regional subnet (works in all ADs)
oci network subnet create \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.0.1.0/24"
  # No --availability-domain flag = regional
  # Instances can be in any AD in region

注意：一些旧版 OCI 指南展示了 AD 专属子网（已弃用的模式）

❌ 绝不要混淆安全列表与 NSG（用途不同）

OCI has TWO network security mechanisms:

Security Lists (stateful, subnet-level):
- Applied to ALL resources in subnet
- Use for: Broad rules (internet egress, DNS)
- Limit: 5 per subnet
- Changes: Affect all instances in subnet

Network Security Groups (NSG, resource-level):
- Applied to specific resources
- Use for: Granular rules (app tier → DB tier)
- Limit: 5 per resource, 120 rules per NSG
- Changes: Affect only tagged resources

# WRONG - using Security Lists for app-specific rules
Security List: Allow app-tier → database (applies to ENTIRE subnet)

# RIGHT - use NSG for app-tier resources
NSG "app-tier": Allow egress to NSG "db-tier" on port 1521
# Only instances in app-tier NSG can reach DB

最佳实践：安全列表用于基线规则（互联网、DNS），NSG 用于应用专属规则

❌ 绝不要认为单 AD 部署可以接受（没有 SLA）

OCI Availability Domains (ADs):
- 3 ADs per region (most regions)
- Isolated fault domains
- <1ms latency between ADs

# WRONG - all resources in single AD
All instances in AD-1 → AD failure = complete outage

# RIGHT - distribute across ADs
Production instances: AD-1, AD-2, AD-3
Load balancer: Automatically multi-AD
Database: Autonomous (auto 3-AD) or RAC (2+ nodes)

SLA impact:
Single-AD: NO SLA (OCI doesn't guarantee)
Multi-AD: 99.95% SLA

重要：对于拥有 3 个 AD 的区域，Oracle 拒绝为单 AD 部署承诺 SLA

❌ 绝不要硬编码 AD 名称（因租户而异）

# WRONG - AD names are tenant-specific, not portable
availability_domain = "fMgC:US-ASHBURN-AD-1"  # Only works in YOUR tenancy!

# Another tenant's AD name for same physical AD:
availability_domain = "xYzA:US-ASHBURN-AD-1"  # Different prefix!

# RIGHT - query AD names dynamically
data "oci_identity_availability_domains" "ads" {
  compartment_id = var.tenancy_ocid
}

resource "oci_core_instance" "web" {
  availability_domain = data.oci_identity_availability_domains.ads.availability_domains[0].name
}

原因：OCI 会为每个租户生成唯一的 AD 前缀，以实现安全隔离

❌ 绝不要未经测试就启用 Cloud Guard 自动修复

Cloud Guard = OCI threat detection + auto-response

# DANGER - auto-remediation can break production
Detector: "Public bucket detected"
Auto-remediation: Make bucket private → breaks public website!

Detector: "Security list allows 0.0.0.0/0"
Auto-remediation: Remove rule → breaks internet access!

# SAFER approach:
1. Enable detectors (read-only mode first)
2. Review findings for 1-2 weeks
3. Tune responders to avoid false positives
4. Enable auto-remediation for trusted patterns only

注意：某些租户默认启用了 Cloud Guard，它可能会自动破坏某些配置

❌ 绝不要认为必须使用 Oracle Linux（这是常见误解）

OCI supports:
✓ Oracle Linux (free, optimized)
✓ Ubuntu, CentOS, Rocky Linux (free)
✓ Windows Server (BYOL or license-included)
✓ Custom images (import your own)

# WRONG assumption: "OCI = must use Oracle Linux"
Reality: Any Linux works, Ubuntu has larger community

# Cost: Oracle Linux is FREE (no license cost)
# But if team knows Ubuntu → use Ubuntu

营销造成的混淆：Oracle 主推 Oracle Linux，但它并非必需

OCI 始终免费层（具体限制）

慷慨的永久免费层（无需信用卡试用，也不会过期）：

计算

• 2 台 AMD VM：VM.Standard.E2.1.Micro（每台 1/8 OCPU、1 GB RAM）
• 4 个 Arm OCPU：VM.Standard.A1.Flex（可分配为 1×4 OCPU 或 4×1 OCPU）
  • 总 RAM 最高 24 GB（每个 OCPU 6 GB）
  • 示例：永久免费运行 4 台 1OCPU/6GB Arm 实例

数据库

• 2 个 Autonomous Database：每个 1 OCPU，每个 ADB 提供 20 GB 存储
  • 可选 ATP 或 ADW
  • 限制：所有区域合计，每个租户最多 2 个

存储

• 块存储卷：总计 200 GB（2 个 100 GB 引导卷 + 自定义卷）
• 对象存储：10 GB 标准层
• 归档存储：10 GB 归档层
• 块存储卷备份：10 GB

网络

• 负载均衡器：1 个灵活 LB，带宽 10 Mbps
• VCN：每个区域 2 个 VCN（免费，不产生 OCID 费用）
• 公共 IPv4：每个区域免费提供 1 个保留公共 IP

可观测性

• 监控：摄取 10 亿个数据点
• 日志记录：每月摄取 10 GB
• 通知：每月发送 100 万封电子邮件

始终免费套餐的注意事项

经常被忽略的关键限制：

# Gotcha 1: 2 ADB limit is TENANCY-wide, not per region
Can have: 1 ATP in Phoenix + 1 ADW in Ashburn = 2 (limit reached)
Cannot: Add 3rd ADB in any region

# Gotcha 2: Arm instances must be VM.Standard.A1.Flex only
Cannot: Use newer A2 shapes (paid only)

# Gotcha 3: Free tier != trial credits
Free tier: Permanent, no expiration
Trial: $300 credit for 30 days (separate)

# Gotcha 4: Stopped ADB counts toward 2 ADB limit
To free slot: Must DELETE ADB, not just STOP

OCI 术语与 AWS/Azure 的对照

从 AWS/Azure 迁移？注意术语陷阱：

OCI 术语	AWS 对应项	Azure 对应项
VCN	VPC	Virtual Network
Subnet	Subnet	Subnet
Security List	VPC Security Group	NSG (network-level)
NSG	Security Group	Application Security Group
DRG	Virtual Private Gateway	VPN Gateway
Compartment	Resource Group / OU	Resource Group
Tenancy	Account	Subscription
Region	Region	Region
AD (Availability Domain)	Availability Zone	Availability Zone
Fault Domain	(within AZ)	Availability Set
Dynamic Group	IAM Role (for instances)	Managed Identity
Instance Principal	EC2 Instance Profile	Managed Identity
OCIR	ECR	Container Registry
OKE	EKS	AKS

关键区别：OCI 同时提供 Security Lists（子网级）和 NSG（资源级）。AWS 只有 Security Groups（资源级）。

多 AD 架构模式

OCI 多 AD 的具体特点：

AD 分布策略

OCI Regions with 3 ADs (most regions):
- US: Phoenix, Ashburn
- UK: London
- DE: Frankfurt
- AU: Sydney, Melbourne

Pattern: Distribute instances across all 3 ADs

AD-1: Web tier (2 instances) + DB primary
AD-2: Web tier (2 instances) + DB standby
AD-3: Web tier (2 instances) + DB standby

Load Balancer: Automatically spans ADs

注意事项：某些形状仅在特定 AD 中提供（请先确认）

# Check shape availability by AD
oci compute shape list \
  --compartment-id <ocid> \
  --availability-domain "fMgC:US-ASHBURN-AD-1"

故障域额外层

在每个 AD 中，OCI 都有故障域（FD）：

• 每个 AD 有 3 个 FD
• 电力、冷却和网络相互独立
• AD 内延迟低于 1 ms

Best practice: Spread instances across ADs AND FDs

AD-1:
  FD-1: Web instance 1
  FD-2: Web instance 2
  FD-3: Web instance 3

AD-2:
  FD-1: Web instance 4
  (repeat pattern)

Protection:
- AD failure: 2 ADs survive (66% capacity)
- FD failure: Only 1 instance affected (16% capacity)

何时使用 FD：仅用于关键性极高的应用（会增加复杂性）

Compartment 策略最佳实践

Compartment 层级结构（OCI 特有的 IAM 边界）：

Root Compartment (tenancy)
│
├─ SharedServices (networking, security)
│  ├─ Network (VCNs, DRGs)
│  └─ Security (Vault, KMS, Cloud Guard)
│
├─ Production
│  ├─ App1
│  │  ├─ Compute
│  │  ├─ Database
│  │  └─ Storage
│  └─ App2
│
├─ NonProduction
│  ├─ Development
│  ├─ Testing
│  └─ Staging
│
└─ Sandbox (developers, auto-cleanup)

核心原则：

1. 账单分离：Compartment 标签可按环境生成成本报告
2. IAM 边界：策略限定在各个 Compartment 范围内（遵循最小权限原则）
3. 配额隔离：每个 Compartment 使用单独的限制
4. 生命周期：删除整个 Compartment = 删除其中的所有资源

反模式：采用没有层级结构的扁平结构（沿用 AWS 按环境划分账户的习惯）

OCI 专属成本优化

Flex 形状节省（OCI 独有）

Fixed shapes (legacy):
VM.Standard2.4: 4 OCPUs, 60 GB RAM, $218/month

Flex shapes (right-size RAM independently):
VM.Standard.E4.Flex: 4 OCPUs, 16 GB RAM, $109/month (50% savings)

Flex advantage: Pay only for RAM you need
- 1 OCPU = 1-64 GB RAM configurable
- Most apps don't need 15GB per OCPU (fixed ratio)

迁移建议：用 Flex 替换固定形状，可节省 30-50%

Arm 实例节省（免费套餐额度充足）

AMD instance: VM.Standard.E4.Flex (1 OCPU) = $0.03/hr
Arm instance: VM.Standard.A1.Flex (1 OCPU) = $0.01/hr (67% cheaper)

Always-Free Arm: 4 OCPUs free forever!

Use case: Web servers, CI/CD runners, dev environments
Limitation: ARM64 only (not all apps compatible)

注意事项：免费套餐仅包含 A1 形状，较新的 A2 形状需要付费

存储分层（确切价格）

层级	成本/GB/月	使用场景	检索
Standard	$0.0255	活跃数据、频繁访问	即时，免费
Infrequent Access	$0.0125 (51% off)	备份、日志（每月访问）	即时，$0.01/GB
Archive	$0.0024 (91% off)	合规、长期保留	1 小时，$0.01/GB

生命周期策略示例：

Day 0-30: Standard ($0.0255/GB/mo)
Day 31-90: Infrequent ($0.0125/GB/mo)
Day 91+: Archive ($0.0024/GB/mo)

1 TB data for 1 year:
Without tiering: $0.0255 × 1000 × 12 = $306/year
With tiering: $0.0255 × 1000 × 1 + $0.0125 × 1000 × 2 + $0.0024 × 1000 × 9 = $72/year
Savings: $234/year (76%)

安全区域（OCI 独有）

OCI Security Zones = 基础设施级策略强制实施：

Security Zone enforces:
✓ All storage encrypted
✓ No public buckets
✓ No internet gateways in VCN
✓ All databases private endpoint only
✓ Cloud Guard enabled

Enforcement: API rejects violating requests (preventive, not detective)

Example:
oci os bucket create --public-access-type ObjectRead
→ FAILS if compartment is in Security Zone

Use case: Production, PCI-DSS, healthcare (mandatory controls)

注意事项：Security Zones 可能会破坏现有自动化流程（请先在开发环境中测试）

渐进式加载参考资料

OCI Well-Architected 检查清单

在以下情况加载 oci-well-architected-checklist.md：

• 对 OCI 租户执行合规性检查
• 准备进行 CIS OCI Foundations Benchmark 审计
• 实施自动化安全扫描
• 为常见发现项创建修复脚本
• 设置漂移检测监控

以下情况请勿加载：

• 快速查阅反模式（上方的 NEVER 列表已涵盖）
• 架构决策（本技能已涵盖）
• 了解 OCI 术语（上方的表格已涵盖）

Oracle 官方文档来源

主要参考资料（抓取了 50 多个官方来源）：

• OCI 良好架构框架
• OCI 架构中心
• CIS OCI 基础基准
• 安全最佳实践
• 区间设计
• 网络架构模式

注意：此技能中的所有反模式、术语映射和 Always-Free 限制均源自 Oracle 官方文档和 Oracle A-Team 博客

---

何时使用此技能

• 架构设计：多可用性域模式、区间策略、VCN 规模规划
• 从 AWS/Azure 迁移：术语映射、避免反模式
• 成本优化：免费套餐规划、Flex 形状、存储分层
• 安全：Cloud Guard 调优、安全区、NSG 与安全列表的对比
• 生产就绪：SLA 要求、高可用模式、容错能力