landing-zones

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

OCI Landing Zones - Expert Architecture

OCI Landing Zones - 专家级架构

⚠️ OCI Landing Zone Knowledge Gap

⚠️ OCI Landing Zone 知识缺口

You don't know OCI Landing Zone patterns and tooling.

Your training data has limited and outdated knowledge of:

OCI Landing Zone reference architectures (updated quarterly)
Resource Manager stacks for landing zones
Compartment design patterns and governance
Security Zones and CIS Foundation compliance
Multi-tenancy patterns (SaaS, multi-environment)
Landing Zone Terraform modules and best practices

When landing zone design is needed:

Use patterns and CLI commands from this skill's references
Do NOT guess compartment hierarchies or network topologies
Do NOT assume IAM policy structures
Load
```
landing-zone-cli.md
```
for deployment operations

What you DO know:

General cloud architecture concepts
Networking principles (subnets, routing, firewalls)
IAM concepts (users, groups, policies)

This skill provides OCI-specific landing zone patterns that differ from AWS/Azure/GCP.

你不了解OCI Landing Zone的模式与工具

你的训练数据中关于以下内容的知识有限且过时：

OCI Landing Zone参考架构（每季度更新）
用于着陆区的Resource Manager堆栈
Compartment设计模式与治理方案
Security Zones与CIS基础合规要求
多租户模式（SaaS、多环境）
Landing Zone Terraform模块与最佳实践

当需要进行着陆区设计时：

使用本技能参考文档中的模式与CLI命令
不要猜测compartment层级结构或网络拓扑
不要假设IAM策略结构
加载
```
landing-zone-cli.md
```
获取部署操作指导

你已掌握的内容：

通用云架构概念
网络原理（子网、路由、防火墙）
IAM概念（用户、组、策略）

本技能提供的OCI专属着陆区模式与AWS/Azure/GCP的模式存在差异。

🚨 Top 10 OCI Bad Practices - Solved by Landing Zones

🚨 OCI十大不良实践 - 着陆区可解决所有问题

Why Landing Zones Matter

着陆区的重要性

Without a proper Landing Zone, organizations commonly make these critical mistakes. OCI Landing Zones solve all 10:

#	Bad Practice	Impact	Landing Zone Solution
1	Using a couple of generic compartments (or no compartments)	No governance, cost allocation impossible, blast radius = entire tenancy	Hierarchical compartments: Network/Security/Workloads structure with policy inheritance
2	Using Administrator group for daily operations	No least privilege, audit trail useless, compliance violations	Granular IAM policies: Per-compartment, per-role policies with principle of least privilege
3	Internet breakout from spoke networks	Egress cost waste ($3k-5k/month), no egress filtering, data exfiltration risk	Hub-spoke topology: Centralized egress via NAT/Firewall in hub VCN
4	Poor network segmentation	Dev can access prod, lateral movement in breach, no environment isolation	Separate compartments + VCNs: Dev/Test/Prod isolation with Security Zones
5	Internet-wide open ports (22, 3389, 8080)	Direct attack surface, brute force attempts, breach entry point	Security Lists/NSGs: Default deny, explicit allow only from bastion/VPN
6	Default security rules and route tables	Overly permissive, not aligned to architecture, security drift	IaC-managed rules: Explicit, version-controlled, CIS Benchmark aligned
7	Limited use of OCI security services	Manual security, no proactive detection, violations found after breach	Integrated security: Cloud Guard, Security Zones, VSS, OSMS, NFW, WAF enabled by default
8	Creating your own Terraform modules	Reinventing wheel, unmaintained, no CIS compliance, inconsistent patterns	Official OCI modules: Battle-tested, Oracle-maintained, CIS certified
9	Public exposure of services (buckets, databases, compute with public IPs)	Data breaches, compliance violations, unauthorized access	Security Zones: Deny public IPs, deny public buckets, encryption enforced
10	No logging, monitoring, notifications	Blind to incidents, no audit trail, compliance failures, long MTTR	Observability stack: VCN Flow Logs, Audit Logs, Cloud Guard, Alarms, Notifications

如果没有合适的着陆区，企业通常会犯以下严重错误。OCI Landing Zones可解决全部10项问题：

序号	不良实践	影响	着陆区解决方案
1	使用几个通用compartment（或不使用compartment）	缺乏治理、无法进行成本分配、影响范围覆盖整个租户	层级化compartment：采用网络/安全/工作负载的结构并支持策略继承
2	使用管理员组进行日常操作	未遵循最小权限原则、审计日志无效、违反合规要求	精细化IAM策略：基于compartment和角色的策略，遵循最小权限原则
3	从分支网络直接访问互联网	出口成本浪费（每月3000-5000美元）、无出口过滤、存在数据泄露风险	中心辐射型拓扑：通过中心VCN中的NAT/防火墙实现集中式出口
4	网络分段不足	开发环境可访问生产环境、入侵后可横向移动、环境无隔离	独立compartment + VCN：开发/测试/生产环境隔离，并启用Security Zones
5	开放全网可访问的端口（22、3389、8080）	直接暴露攻击面、遭受暴力破解尝试、成为入侵入口	安全列表/NSG：默认拒绝所有流量，仅明确允许来自堡垒机/VPN的访问
6	使用默认安全规则和路由表	权限过度宽松、与架构不匹配、存在安全漂移风险	IaC管理的规则：明确的、版本控制的、符合CIS基准的规则
7	很少使用OCI安全服务	手动安全管理、无主动检测、入侵后才发现违规	集成化安全方案：默认启用Cloud Guard、Security Zones、VSS、OSMS、NFW、WAF
8	自行创建Terraform模块	重复造轮子、模块无人维护、不符合CIS合规、模式不一致	官方OCI模块：经过实战检验、由Oracle维护、通过CIS认证
9	服务公网暴露（存储桶、数据库、带公网IP的计算实例）	数据泄露、违反合规要求、未授权访问	Security Zones：禁止公网IP、禁止公共存储桶、强制加密
10	无日志、监控与通知机制	无法感知事件、无审计轨迹、合规失败、平均恢复时间长	可观测性堆栈：VCN流量日志、审计日志、Cloud Guard、告警、通知

Cost Impact: With vs Without Landing Zone

成本影响：有无着陆区对比

Without Landing Zone (Annual Waste):

Egress via IG instead of SG: $36k-52k/year
Flat compartments (no optimization): $50k-100k/year (cannot identify waste)
No Security Zones (breach): $100k-$10M+ (average breach cost)
Manual Terraform maintenance: $50k-100k/year (engineer time)
Total avoidable cost: $236k-$10.2M+/year

With Landing Zone:

One-time setup: $10k-30k (mostly planning/design)
Annual maintenance: $5k-10k (Terraform updates)
ROI: 10x-100x+ in first year

无着陆区（年度浪费）：

通过IG而非SG访问互联网：每年3.6万-5.2万美元
扁平化compartment（无优化）：每年5万-10万美元（无法识别浪费）
无Security Zones（遭遇入侵）：每年10万-1000万美元以上（平均入侵损失）
手动维护Terraform：每年5万-10万美元（工程师时间成本）
可避免总成本：每年23.6万-1020万美元以上

有着陆区：

一次性搭建成本：1万-3万美元（主要为规划/设计成本）
年度维护成本：0.5万-1万美元（Terraform更新）
投资回报率：第一年可达10-100倍以上

Compliance Impact

合规影响

Regulatory frameworks requiring Landing Zone patterns:

PCI-DSS: Network segmentation (#1, #3, #4, #5)
HIPAA: Encryption, logging, access controls (#7, #9, #10)
SOC 2: Least privilege, monitoring, change management (#2, #6, #10)
ISO 27001: Information security controls (all 10)
CIS OCI Foundations: 100+ controls (Landing Zone implements 80%+)

Without Landing Zone: Compliance audit failures, remediation costs $100k-500k With Landing Zone: CIS Benchmark aligned by default, audit-ready

You are an OCI Landing Zone architect. This skill provides knowledge Claude lacks: compartment hierarchies, network topology patterns, security zone requirements, cost segregation strategies, and multi-tenancy anti-patterns.

要求采用着陆区模式的监管框架：

PCI-DSS：网络分段（第1、3、4、5项）
HIPAA：加密、日志、访问控制（第7、9、10项）
SOC 2：最小权限、监控、变更管理（第2、6、10项）
ISO 27001：信息安全控制（全部10项）
CIS OCI基础基准：100+项控制要求（着陆区可实现80%以上）

无着陆区：合规审计失败，整改成本10万-50万美元 有着陆区：默认符合CIS基准，随时可通过审计

你是一名OCI Landing Zone架构师。本技能补充了Claude缺失的知识：compartment层级结构、网络拓扑模式、Security Zones要求、成本隔离策略以及多租户反模式。

NEVER Do This

绝对禁止的操作

❌ NEVER create flat compartment structure (no hierarchy)

BAD - Flat compartments:
tenancy/
  ├─ app1-dev
  ├─ app1-test
  ├─ app1-prod
  ├─ app2-dev
  ├─ app2-test
  └─ app2-prod

Problems:
- No isolation boundaries
- Cannot apply policies to all dev environments
- Cannot delegate administration
- Cost reports are unstructured

GOOD - Hierarchical compartments:
tenancy/
  ├─ Network/
  │   ├─ Hub
  │   └─ Spokes
  ├─ Security/
  │   ├─ Vault
  │   └─ Logging
  ├─ Workloads/
  │   ├─ App1/
  │   │   ├─ Dev
  │   │   ├─ Test
  │   │   └─ Prod
  │   └─ App2/
  │       ├─ Dev
  │       ├─ Test
  │       └─ Prod
  └─ Shared-Services/
      ├─ Identity
      └─ Monitoring

Why critical: Hierarchical structure enables policy inheritance, delegation, and logical cost segregation. Flat structure requires duplicate policies and makes governance impossible at scale.

❌ NEVER use default VCN CIDR (10.0.0.0/16) everywhere

BAD - Same CIDR in all environments:
Dev VCN: 10.0.0.0/16
Test VCN: 10.0.0.0/16  # Cannot peer with Dev!
Prod VCN: 10.0.0.0/16  # Cannot peer with Dev or Test!

Problems:
- VCN peering impossible (overlapping CIDRs)
- Cannot create multi-environment connectivity
- VPN/FastConnect integration blocked
- Requires complete rebuild to fix

GOOD - Non-overlapping CIDR allocation:
Dev VCN: 10.10.0.0/16
Test VCN: 10.20.0.0/16
Prod VCN: 10.30.0.0/16
Hub VCN: 10.0.0.0/16 (shared services)

Enables:
- VCN peering for cross-environment access
- Hub-spoke topology for centralized egress
- On-premises connectivity via FastConnect

Cost impact: VCN CIDR is IMMUTABLE. Wrong CIDR = complete rebuild = downtime + migration costs.

❌ NEVER skip Security Zones in production compartments

bash

undefined

❌ 绝对不要创建扁平化compartment结构（无层级）

BAD - 扁平化compartment:
tenancy/
  ├─ app1-dev
  ├─ app1-test
  ├─ app1-prod
  ├─ app2-dev
  ├─ app2-test
  └─ app2-prod

问题:
- 无隔离边界
- 无法对所有开发环境统一应用策略
- 无法委托管理权限
- 成本报告结构混乱

GOOD - 层级化compartment:
tenancy/
  ├─ Network/
  │   ├─ Hub
  │   └─ Spokes
  ├─ Security/
  │   ├─ Vault
  │   └─ Logging
  ├─ Workloads/
  │   ├─ App1/
  │   │   ├─ Dev
  │   │   ├─ Test
  │   │   └─ Prod
  │   └─ App2/
  │       ├─ Dev
  │       ├─ Test
  │       └─ Prod
  └─ Shared-Services/
      ├─ Identity
      └─ Monitoring

关键原因：层级结构支持策略继承、权限委托和合理的成本隔离。扁平化结构需要重复配置策略，无法实现规模化治理。

❌ 绝对不要在所有环境中使用默认VCN CIDR（10.0.0.0/16）

BAD - 所有环境使用相同CIDR:
Dev VCN: 10.0.0.0/16
Test VCN: 10.0.0.0/16  # 无法与Dev VCN对等连接!
Prod VCN: 10.0.0.0/16  # 无法与Dev或Test VCN对等连接!

问题:
- VCN对等连接无法实现（CIDR重叠）
- 无法创建多环境连通性
- VPN/FastConnect集成受阻
- 需要完全重建才能修复

GOOD - 非重叠CIDR分配:
Dev VCN: 10.10.0.0/16
Test VCN: 10.20.0.0/16
Prod VCN: 10.30.0.0/16
Hub VCN: 10.0.0.0/16（共享服务）

优势:
- 支持VCN对等连接实现跨环境访问
- 支持中心辐射型拓扑实现集中式出口
- 支持通过FastConnect实现本地连接

成本影响：VCN CIDR是不可变的。错误的CIDR配置需要完全重建，导致停机和迁移成本。

❌ 绝对不要在生产环境compartment中跳过Security Zones

bash

undefined

BAD - no security zone enforcement

BAD - 未启用安全区域强制管控

oci iam compartment create
--compartment-id $PARENT_ID
--name "Prod"
--description "Production workloads"

Result: No guardrails, resources can violate security policies

结果: 无防护措施，资源可能违反安全策略

GOOD - security zone enabled

GOOD - 启用安全区域

1. Create security zone recipe

1. 创建安全区域规则集

oci cloud-guard security-zone-recipe create
--compartment-id $TENANCY_ID
--display-name "CIS-Prod-Recipe"
--security-policies "["deny-public-ip", "deny-public-bucket"]"

2. Create security zone for prod compartment

2. 为生产compartment创建安全区域

oci cloud-guard security-zone create
--compartment-id $PROD_COMPARTMENT_ID
--display-name "Prod-Security-Zone"
--security-zone-recipe-id $RECIPE_ID

Enforces: No public IPs, no public buckets, encryption required

强制管控: 禁止公网IP、禁止公共存储桶、强制加密


**Why critical**: Security Zones prevent violations BEFORE resource creation. Without them, auditing finds violations AFTER compromise. Cost of breach: $100k-$10M+.

❌ **NEVER mix dev and prod resources in same compartment**

BAD - shared compartment: App1/ ├─ vm-dev-1 (development instance) ├─ vm-prod-1 (production instance) └─ db-prod (CRITICAL DATABASE)

Problems:

Developers with dev access can accidentally delete prod DB
Cannot set different backup policies
Cost reports mix dev and prod spending
Compliance violations (SOC2, ISO27001)

undefined

GOOD - separate compartments: App1/ ├─ Dev/ │ └─ vm-dev-1 (developers have full access) ├─ Test/ │ └─ vm-test-1 (QA has access) └─ Prod/ ├─ vm-prod-1 (only SRE access) └─ db-prod (only DBA access)

Enables:

Least privilege per environment
Separate budgets and alerts
Independent backup policies
Compliance audit trails


**Risk**: Production outage from dev team mistake. Happened at 47% of surveyed enterprises in 2023.

❌ **NEVER use root compartment for workload resources**

BAD - resources in root: tenancy (root)/ ├─ vcn-1 (WRONG - in root) ├─ instance-1 (WRONG - in root) └─ database-1 (WRONG - in root)

Problems:

Cannot delegate administration
Root policies affect all resources
Cannot isolate blast radius
Violates CIS OCI Foundations Benchmark

undefined

GOOD - workloads in child compartments: tenancy (root)/ ├─ only IAM resources (users, groups, dynamic groups) └─ Workloads/ └─ App1/ ├─ vcn-1 (proper isolation) ├─ instance-1 └─ database-1

Root compartment usage:

Identity resources only (users, groups, policies)
Top-level compartments
Nothing else


**Why critical**: Root compartment is for tenancy-wide IAM. Resources in root bypass governance.

❌ **NEVER skip tagging strategy (cost allocation nightmare)**

BAD - no tags: Resource created with no tags Cost report shows: "oci.compute.instance: $5,234/month" Question: Which team? Which project? Which environment? Answer: Unknown - requires manual investigation

Result: Cannot chargeback costs, cannot optimize

undefined

GOOD - defined tag namespace + mandatory tags:


**关键原因**：Security Zones可在资源创建前阻止违规操作。如果没有Security Zones，只能在入侵后通过审计发现违规。入侵损失可达10万-1000万美元以上。

❌ **绝对不要将开发与生产资源混合在同一个compartment中**

BAD - 共享compartment: App1/ ├─ vm-dev-1 (开发实例) ├─ vm-prod-1 (生产实例) └─ db-prod (核心数据库)

问题:

拥有开发权限的人员可能意外删除生产数据库
无法设置不同的备份策略
成本报告混合了开发与生产支出
违反合规要求（SOC2、ISO27001）

undefined

GOOD - 独立compartment: App1/ ├─ Dev/ │ └─ vm-dev-1（开发人员拥有完全权限） ├─ Test/ │ └─ vm-test-1（QA人员拥有权限） └─ Prod/ ├─ vm-prod-1（仅SRE人员拥有权限） └─ db-prod（仅DBA人员拥有权限）

优势:

每个环境遵循最小权限原则
独立的预算与告警
独立的备份策略
合规审计轨迹清晰


**风险**：开发团队失误导致生产环境停机。2023年调查显示，47%的企业曾遭遇此类问题。

❌ **绝对不要在根compartment中部署工作负载资源**

BAD - 资源部署在根compartment: tenancy (root)/ ├─ vcn-1 (错误 - 在根compartment) ├─ instance-1 (错误 - 在根compartment) └─ database-1 (错误 - 在根compartment)

问题:

无法委托管理权限
根策略影响所有资源
无法隔离影响范围
违反CIS OCI基础基准

undefined

GOOD - 工作负载部署在子compartment: tenancy (root)/ ├─ 仅存放IAM资源（用户、组、动态组） └─ Workloads/ └─ App1/ ├─ vcn-1（合理隔离） ├─ instance-1 └─ database-1

根compartment用途:

仅存放身份资源（用户、组、策略）
顶级compartment
无其他用途


**关键原因**：根compartment用于租户级IAM管理。部署在根compartment的资源会绕过治理规则。

❌ **绝对不要跳过标签策略（会导致成本分配混乱）**

BAD - 无标签: 创建的资源未添加标签成本报告显示: "oci.compute.instance: 每月5234美元" 问题: 属于哪个团队？哪个项目？哪个环境？答案: 未知 - 需要手动调查

结果: 无法进行成本分摊、无法优化成本

undefined

GOOD - 定义标签命名空间 + 强制标签:

1. Create tag namespace

1. 创建标签命名空间

oci iam tag-namespace create
--compartment-id $TENANCY_ID
--name "Organization"
--description "Organization-wide tags"

2. Create mandatory tags

2. 创建强制标签

oci iam tag create
--tag-namespace-id $NAMESPACE_ID
--name "CostCenter"
--description "Cost center for chargeback"
--is-retired false

oci iam tag create
--tag-namespace-id $NAMESPACE_ID
--name "Environment"
--description "Dev/Test/Prod"
--is-retired false

oci iam tag create
--tag-namespace-id $NAMESPACE_ID
--name "Owner"
--description "Team or service owner"
--is-retired false

oci iam tag create
--tag-namespace-id $NAMESPACE_ID
--name "CostCenter"
--description "用于成本分摊的成本中心"
--is-retired false

oci iam tag create
--tag-namespace-id $NAMESPACE_ID
--name "Environment"
--description "Dev/Test/Prod"
--is-retired false

oci iam tag create
--tag-namespace-id $NAMESPACE_ID
--name "Owner"
--description "团队或服务所有者"
--is-retired false

3. Make tags mandatory at compartment level

3. 在compartment级别设置标签默认值（强制）

oci iam tag-default create
--compartment-id $WORKLOAD_COMPARTMENT_ID
--tag-definition-id $COSTCENTER_TAG_ID
--value "${iam.principal.name}"

Cost report now shows:

CostCenter: Engineering ($3,200)
CostCenter: Marketing ($2,034)
Environment: Prod ($4,100)
Environment: Dev ($1,134)


**Cost impact**: Without tags, cost optimization is guesswork. With tags, precision chargeback and 30-50% cost reduction via waste identification.

❌ **NEVER use single-region landing zone for production**

BAD - single region: All resources in us-ashburn-1 RTO: Hours-days (rebuild in new region) RPO: Last backup (data loss)

Problems:

No disaster recovery
Region outage = complete downtime
Violates SLA requirements
Insurance/compliance issues

undefined

GOOD - multi-region architecture: Primary: us-ashburn-1 DR: us-phoenix-1

Autonomous Data Guard (standby)
Traffic Manager (DNS failover)
Object Storage replication
Compartment structure mirrored

RTO: 15 minutes (automated failover) RPO: Near-zero (Data Guard sync)


**Cost**: Multi-region adds 60-100% infrastructure cost. Cost of regional outage: $500k-$50M depending on SLA.

❌ **NEVER allow internet gateway in DMZ without egress firewall**

BAD - direct internet gateway: DMZ Subnet → Internet Gateway → Internet No egress filtering, all outbound traffic allowed

Problems:

Data exfiltration possible
Command & control connections unblocked
Compliance violations (PCI-DSS, HIPAA)

undefined

GOOD - egress control via NAT or firewall: Option 1: Service Gateway + NAT Gateway DMZ Subnet → NAT Gateway → Internet

Egress only, no inbound
All traffic logged
Can use Network Firewall for DPI

Option 2: Hub-spoke with centralized firewall Spoke → DRG → Hub VCN → Network Firewall → Internet

All egress goes through hub
Firewall policies enforce allow-list
Complete visibility and control


**Security impact**: Uncontrolled egress is #3 cause of data breaches (Verizon DBIR 2023).

oci iam tag-default create
--compartment-id $WORKLOAD_COMPARTMENT_ID
--tag-definition-id $COSTCENTER_TAG_ID
--value "${iam.principal.name}"

现在成本报告可显示:

CostCenter: Engineering（3200美元）
CostCenter: Marketing（2034美元）
Environment: Prod（4100美元）
Environment: Dev（1134美元）


**成本影响**：无标签时，成本优化只能靠猜测。有标签时，可实现精准成本分摊，并通过识别浪费降低30-50%的成本。

❌ **绝对不要为生产环境使用单区域着陆区**

BAD - 单区域: 所有资源部署在us-ashburn-1 恢复时间目标(RTO): 数小时至数天（在新区域重建）恢复点目标(RPO): 最后一次备份（存在数据丢失）

问题:

无灾难恢复能力
区域故障 = 完全停机
违反SLA要求
保险/合规问题

undefined

GOOD - 多区域架构: 主区域: us-ashburn-1 灾备区域: us-phoenix-1

Autonomous Data Guard（备用实例）
Traffic Manager（DNS故障转移）
对象存储复制
镜像compartment结构

恢复时间目标(RTO): 15分钟（自动故障转移）恢复点目标(RPO): 近乎零（Data Guard同步）


**成本**：多区域架构会增加60-100%的基础设施成本。区域故障的成本：根据SLA不同，可达50万-5000万美元。

❌ **绝对不要在DMZ中使用无出口防火墙的互联网网关**

BAD - 直接互联网网关: DMZ子网 → 互联网网关 → 互联网无出口过滤，允许所有出站流量

问题:

可能发生数据泄露
命令与控制连接未被阻止
违反合规要求（PCI-DSS、HIPAA）

undefined

GOOD - 通过NAT或防火墙管控出口: 选项1: 服务网关 + NAT网关 DMZ子网 → NAT网关 → 互联网

仅允许出站，禁止入站
所有流量被日志记录
可使用网络防火墙进行深度包检测

选项2: 中心辐射型拓扑 + 集中式防火墙分支 → DRG → 中心VCN → 网络防火墙 → 互联网

所有出站流量经过中心节点
防火墙策略强制实施允许列表
完全可见性与管控


**安全影响**：不受控的出口是数据泄露的第三大原因（Verizon DBIR 2023）。

Progressive Loading References

渐进式加载参考文档

Landing Zone Architecture Patterns

着陆区架构模式

WHEN TO LOAD

landing-zone-patterns.md

Designing hub-spoke network topology
Choosing compartment hierarchy pattern (workload-centric vs environment-centric vs tenant-centric)
Implementing Security Zones and Cloud Guard integration
Setting up tagging strategy and cost allocation
Designing network topology (single VCN vs hub-spoke vs multi-region)

Do NOT load for:

Quick anti-pattern reference (NEVER list above covers it)
Understanding Top 10 Bad Practices (covered in this skill)
CLI commands (use landing-zone-cli.md instead)

何时加载

landing-zone-patterns.md

设计中心辐射型网络拓扑
选择compartment层级模式（以工作负载为中心 vs 以环境为中心 vs 以租户为中心）
实现Security Zones与Cloud Guard集成
设置标签策略与成本分配方案
设计网络拓扑（单VCN vs 中心辐射型 vs 多区域）

请勿加载用于:

快速查阅反模式参考（已在上述“绝对禁止”列表中覆盖）
了解十大不良实践（已在本技能中覆盖）
CLI命令（请使用landing-zone-cli.md）

OCI Well-Architected Framework (Official Oracle Documentation)

OCI架构完善框架（Oracle官方文档）

WHEN TO LOAD

oci-well-architected-framework.md

Need comprehensive understanding of Landing Zone design principles
Designing production-grade landing zones from scratch
Understanding Security & Compliance pillar (IAM, encryption, monitoring)
Understanding Reliability & Resilience pillar (HA, DR, fault tolerance)
Understanding Performance Efficiency & Cost Optimization pillar
Understanding Operational Efficiency pillar (IaC, automation, scalability)
Comparing Core Landing Zone vs Operating Entities Landing Zone
Need official Oracle guidance on multi-region deployment

MANDATORY - READ ENTIRE FILE (~3,400 lines): This is the official Oracle documentation on OCI Well-Architected Framework and Landing Zones. Read completely when:

Starting a new landing zone design project
Preparing architectural review or compliance audit
Need to justify Landing Zone decisions to stakeholders

Do NOT load for:

Quick CLI commands (use landing-zone-cli.md instead)
Specific implementation steps (covered in this skill's decision trees)

何时加载

oci-well-architected-framework.md

需要全面理解着陆区设计原则
从零开始设计生产级着陆区
理解安全与合规支柱（IAM、加密、监控）
理解可靠性与弹性支柱（高可用、灾备、容错）
理解性能效率与成本优化支柱
理解运营效率支柱（IaC、自动化、可扩展性）
对比核心着陆区与运营实体着陆区
需要Oracle官方的多区域部署指导

强制要求 - 完整阅读文件（约3400行）：这是Oracle官方关于OCI架构完善框架与着陆区的文档。在以下场景中需完整阅读:

启动新的着陆区设计项目
准备架构评审或合规审计
需要向利益相关者证明着陆区决策的合理性

请勿加载用于:

快速查阅CLI命令（请使用landing-zone-cli.md）
具体实施步骤（已在本技能的决策树中覆盖）

OCI CLI for Landing Zones

OCI CLI 用于着陆区管理

WHEN TO LOAD

landing-zone-cli.md

Creating compartment hierarchies
Setting up Security Zones and Cloud Guard
Configuring tag defaults and tag namespaces
Implementing hub-spoke network topology
Creating budgets and cost tracking

Example: Create compartment hierarchy

bash

oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Workloads" \
  --description "Application workloads"

Do NOT load for:

General OCI architecture concepts (covered in this skill)
IAM policy syntax (covered in iam-identity-management skill)
Network configuration (covered in networking-management skill)
Official Oracle documentation (use oci-well-architected-framework.md instead)

何时加载

landing-zone-cli.md

创建compartment层级结构
设置Security Zones与Cloud Guard
配置标签默认值与标签命名空间
实现中心辐射型网络拓扑
创建预算与成本跟踪

示例: 创建compartment层级

bash

oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Workloads" \
  --description "Application workloads"

请勿加载用于:

通用OCI架构概念（已在本技能中覆盖）
IAM策略语法（已在iam-identity-management技能中覆盖）
网络配置（已在networking-management技能中覆盖）
Oracle官方文档（请使用oci-well-architected-framework.md）

When to Use This Skill

何时使用本技能

Initial OCI tenancy setup and foundation
Migrating from AWS/Azure/GCP to OCI
Designing multi-tenant or multi-environment architectures
Implementing governance and cost controls
Preparing for compliance audits (CIS, SOC2, ISO27001)
Scaling from single app to enterprise platform
Disaster recovery and multi-region planning

初始OCI租户设置与基础搭建
从AWS/Azure/GCP迁移至OCI
设计多租户或多环境架构
实施治理与成本管控
准备合规审计（CIS、SOC2、ISO27001）
从单应用扩展至企业级平台
灾难恢复与多区域规划