Auto-sync: 2026-04-24 00:02

wiki/concepts/14种UML图.md

@@ -0,0 +1,41 @@
+---
+title: "14种UML图"
+type: concept
+tags: []
+sources: [fireworks-tech-graph]
+last_updated: 2026-04-18
+---
+
+## Description
+fireworks-tech-graph 完整支持的 14 种 UML（统一建模语言）图类型，涵盖结构图、行为图和交互图三大类。
+
+## 完整图类型列表
+
+| UML 类型 | 描述 | 推荐风格 |
+|---------|------|---------|
+| **类图** | 类、属性、方法、关系 | 风格 1, 4 |
+| **组件图** | 软件组件和依赖关系 | 风格 1, 3 |
+| **部署图** | 硬件节点和软件部署 | 风格 3 |
+| **包图** | 包组织和依赖关系 | 风格 1, 4 |
+| **复合结构图** | 类/组件的内部结构 | 风格 1, 3 |
+| **对象图** | 对象实例和关系 | 风格 1, 4 |
+| **用例图** | 参与者、用例、系统边界 | 风格 1 |
+| **活动图** | 工作流、并行流程 | 风格 3 |
+| **状态机图** | 状态转换和事件 | 风格 2, 3 |
+| **序列图** | 时间顺序的消息交换 | 风格 2 |
+| **通信图** | 对象交互和消息 | 风格 1, 2 |
+| **时序图** | 状态随时间的变化 | 风格 2 |
+| **交互概览图** | 高层交互流程 | 风格 1, 2 |
+| **ER 图** | 实体关系数据模型 | 风格 1, 3 |
+
+## 分类
+
+**结构图（7种）：** 类图、组件图、部署图、包图、复合结构图、对象图、用例图
+
+**行为图（2种）：** 活动图、状态机图
+
+**交互图（5种）：** 序列图、通信图、时序图、交互概览图
+
+## Relationships
+- [[14种UML图]] is supported_by [[fireworks-tech-graph]]
+- [[14种UML图]] is used_by [[7种视觉风格系统]]

wiki/concepts/7种视觉风格系统.md

@@ -0,0 +1,58 @@
+---
+title: "7种视觉风格系统"
+type: concept
+tags: []
+sources: [fireworks-tech-graph]
+last_updated: 2026-04-18
+---
+
+## Description
+fireworks-tech-graph 内置的 7 种视觉风格系统，每种风格定义了背景色、字体、颜色 Token、布局规范和使用场景推荐。
+
+## The 7 Styles
+
+| # | 名称 | 背景色 | 字体 | 适用场景 |
+|---|------|--------|------|---------|
+| 1 | **扁平图标风**（默认） | `#ffffff` | Helvetica | 博客、幻灯片、技术文档 |
+| 2 | **暗黑极客风** | `#0f0f1a` | SF Mono / Fira Code | GitHub README、开发者文章 |
+| 3 | **工程蓝图风** | `#0a1628` | Courier New | 架构设计文档、工程规范 |
+| 4 | **Notion 极简风** | `#ffffff` | system-ui | Notion、Confluence、内部 Wiki |
+| 5 | **玻璃态卡片风** | `#0d1117` 渐变 | Inter | 产品官网、演讲 Keynote |
+| 6 | **Claude 官方风格** | `#f8f6f3` | system-ui | Anthropic 风格图表，温暖专业美学 |
+| 7 | **OpenAI 官方风格** | `#ffffff` | system-ui | OpenAI 风格图表，简洁现代设计 |
+
+## 风格选择指南
+
+**UML 图类型：**
+- 类图/组件图/包图：风格 1（扁平图标风）或风格 4（Notion极简风）
+- 序列图/时序图：风格 2（暗黑极客风）
+- 状态机图/活动图：风格 3（工程蓝图风）
+- 用例图/交互图：风格 1（扁平图标风）
+
+**AI/Agent 图类型：**
+- RAG/Agentic Search：风格 2（暗黑极客风）或风格 5（玻璃态卡片风）
+- 记忆架构：风格 3（工程蓝图风）
+- Multi-Agent：风格 5（玻璃态卡片风）
+
+**文档类型：**
+- 内部文档：风格 4（Notion极简风）
+- 技术博客：风格 1（扁平图标风）
+- GitHub README：风格 2（暗黑极客风）
+- 演示文稿：风格 5（玻璃态卡片风）或风格 6（Claude官方风格）
+
+**品牌特定：**
+- Anthropic/Claude 项目：风格 6（Claude官方风格）
+- OpenAI 项目：风格 7（OpenAI官方风格）
+
+## Key Enhancements
+- `style_overrides`：微调标题对齐或配色 token
+- `containers[].header_prefix` / `containers[].header_text`：工程编号分区标题（风格3）
+- `containers[].side_label`：左侧 Layer Label（风格6）
+- `window_controls` / `meta_*`：终端/文档风格顶部 chrome
+- `blueprint_title_block`：蓝图标题信息框（风格3）
+
+## Relationships
+- [[7种视觉风格系统]] is implemented_by [[fireworks-tech-graph]]
+- [[7种视觉风格系统]] is used_for [[14种UML图]]
+- [[7种视觉风格系统]] is used_for [[RAG]]
+- [[7种视觉风格系统]] is used_for [[AI Agent]]

wiki/concepts/AWS-Tagging-Standards.md

@@ -0,0 +1,66 @@
+---
+title: "AWS Tagging Standards"
+type: concept
+tags: [AWS, Tagging, Governance, Compliance, Policy]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+AWS Tagging Standards（AWS 标签规范）是企业级 AWS Landing Zone 治理框架的核心组成部分，定义了 AWS 资源上必须使用的标准标签键（Mandatory Tags）、命名约定（Naming Conventions）和允许值列表（Allowed Values）。标签规范是企业云治理的第一道防线，直接影响网络安全策略、成本分配和资源管理效率。
+
+## Aliases
+- Tagging Policy
+- Tag Standard
+- AWS Tagging Policy
+- Tag Governance
+
+## Core Components
+
+### 1. Mandatory Tags（强制标签）
+组织定义的必须存在于所有 AWS 资源上的标签键，例如：
+- `Environment`: `dev | staging | prod`
+- `CostCenter`: 成本中心代码
+- `Owner`: 资源负责人
+- `Application`: 应用名称
+- `Project`: 项目名称
+
+### 2. Naming Conventions（命名约定）
+资源命名的标准化规则，例如：
+- `prod-web-server-001`
+- `dev-db-postgres-01`
+
+### 3. Allowed Values（允许值列表）
+每个标签键对应的允许值集合，例如：
+```yaml
+Environment:
+  - dev
+  - staging
+  - prod
+  - uat
+CostCenter:
+  - CC-001
+  - CC-002
+```
+
+## Context in This Wiki
+
+在该组织的 AWS Landing Zone 环境中，标签规范具有双重关键性：
+
+1. **Checkpoint 防火墙安全策略**：Checkpoint 防火墙读取 EC2、安全组和负载均衡器的标签值来配置网络访问策略，标签缺失或无效将直接导致流量被拦截。
+2. **服务控制策略（SCPs）**：AWS Organizations 的 SCPs 基于标签规范阻止不合规资源的新建，但仅能阻止新资源，无法处理存量不合规资源。
+3. **标签验证工具（Tag Validation Tool）**：SRE 团队开发的 Python/Boto3 工具，通过 `variables.yaml` 配置文件扫描所有现有资源并与规范比对，生成 CSV 审计报告。
+4. **未来成本核算**：标签计划用于区分同一账户下不同产品的资源消耗，支持 FinOps 成本分摊。
+
+## Related Concepts
+
+- [[AWS-Tags]]：AWS 资源标签的基础定义
+- [[Tag-Validation-Tool]]：基于标签规范的自动化审计工具
+- [[Service-Control-Policies-SCPs]]：基于标签规范的上游强制机制
+- [[Variables-YAML]]：标签验证工具的核心配置文件
+- [[FinOps]]：利用标签实现成本分摊
+
+## Sources
+
+- [[ctp-topic-28-aws-tag-validation-tool]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]

wiki/concepts/AWS-Tags.md

@@ -0,0 +1,44 @@
+---
+title: "AWS Tags"
+type: concept
+tags: [AWS, Tagging, Metadata, Cloud-Governance]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+AWS Tags（AWS 资源标签）是附加在 AWS 资源上的键值对（Key-Value Pair）元数据，用于识别、分类和管理云资源。在企业 AWS Landing Zone 环境中，标签不仅是资源管理的工具，更是安全策略（Checkpoint 防火墙网络访问控制）和成本核算的基础。
+
+## Aliases
+- Resource Tags
+- AWS Resource Tags
+- 标签策略（Tagging Policy）
+
+## Core Attributes
+
+| 属性 | 说明 |
+|------|------|
+| 格式 | `Key: Value`（键值对） |
+| 作用对象 | EC2, Security Groups, Load Balancers, Lambda, RDS 等 |
+| 常见标签键 | `Name`, `Environment`, `CostCenter`, `Owner`, `Application`, `Project` |
+| 适用层面 | 网络安全、成本核算、资源分组、访问控制 |
+
+## Context in This Wiki
+
+AWS Tags 在该组织中扮演双重关键角色：
+
+1. **网络安全**：Checkpoint 防火墙通过读取 EC2、安全组和负载均衡器的标签值动态配置网络访问策略；标签缺失或无效时，防火墙将拦截相关流量。
+2. **成本核算**：标签用于按产品/部门/环境区分同一账户下不同资源的成本消耗。
+
+## Related Concepts
+
+- [[AWS-Tagging-Standards]]：AWS 标签规范，包括强制标签键、命名约定
+- [[Tag-Validation-Tool]]：用于审计 AWS 资源标签合规性的自动化工具
+- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略，用于强制执行标签规范
+- [[FinOps]]：云财务管理，标签是成本分摊的基础
+- [[Checkpoint-Firewall]]：依赖标签值配置网络策略
+
+## Sources
+
+- [[ctp-topic-28-aws-tag-validation-tool]]
+- [[ctp-topic-10-aws-tagging-deep-dive]]

wiki/concepts/CI-CD-Pipeline.md

@@ -1,61 +1,51 @@
-# CI/CD Pipeline
+---
+title: "CI/CD Pipeline"
+type: concept
+sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-9-ci-cd-with-gruntwork]
+last_updated: 2026-04-14
+---
 
 ## Definition
-CI/CD (Continuous Integration/Continuous Delivery/Deployment) pipelines automate the process of building, testing, and deploying software changes.
+CI/CD 流水线（CI/CD Pipeline）是持续集成（Continuous Integration）和持续交付/部署（Continuous Delivery/Deployment）的自动化流程，用于管理基础设施代码（IaC）的构建、测试和部署。在 Gruntwork Landing Zone 架构中，每个 Landing Zone 配置独立的 Jenkins 服务器和 CI/CD 流水线来自动化 Terraform 基础设施变更。
 
-## Components
+## Core Components
 
-### Continuous Integration (CI)
-- Automated builds on code commits
-- Automated testing (unit, integration, e2e)
-- Code quality checks and linting
-- Artifact generation
+### CI（持续集成）
+- **代码提交**：开发人员将特性分支代码推送到 GitHub 仓库
+- **自动构建**：Jenkins 触发 Terraform 初始化和格式化验证
+- **自动测试**：TerraTest 执行基础设施单元测试和集成测试
+- **代码审查**：Pull Request 必须通过审查才能合并到主分支
 
-### Continuous Delivery (CD)
-- Automated deployment to staging environments
-- Manual approval gates for production
-- Configuration management
+### CD（持续交付/部署）
+- **自动部署**：合并到主分支后，Jenkins 自动执行 Terraform Plan
+- **审批流程**：变更需要人工审批后才执行 Apply
+- **渐进式部署**：支持 Blue-Green 部署和 Canary Release 策略
 
-### Continuous Deployment
-- Fully automated deployment to production
-- Feature flags for gradual rollout
-- Automated rollback capabilities
+### Infrastructure-Specific Considerations
+- **状态管理**：Terraform State 的锁定和远程存储（使用 S3 + DynamoDB）
+- **幂等性**：Terraform 模块设计必须支持重复执行而不产生副作用
+- **回滚机制**：通过 Terraform State 历史版本实现快速回滚
+- **漂移检测**：定期运行 `terraform plan` 检测配置漂移
 
-## Tools
-- **CI/CD Platforms**: Jenkins, GitLab CI, GitHub Actions, CircleCI, ArgoCD
-- **Build Tools**: Maven, Gradle, npm, Docker
-- **Testing**: JUnit, PyTest, Selenium, Playwright
+## Tools in Gruntwork Landing Zone Context
+- **Jenkins**：核心 CI/CD 引擎，每个 Landing Zone 独立部署
+- **Terraform**：IaC 工具，定义和管理 AWS 资源
+- **TerraTest**：Go 语言编写的基础设施测试框架
+- **GitHub**：代码仓库，支持特性分支和 Pull Request 工作流
 
-## Best Practices
-1. Keep the pipeline fast (under 10 minutes)
-2. Fail fast — run fastest tests first
-3. Use meaningful commit messages and branch names
-4. Implement proper caching strategies
-5. Store build artifacts securely
-6. Enable parallel test execution
-
-## CI/CD Pipeline Across DevOps Maturity Levels
-
-| Maturity | Pipeline Maturity |
-|----------|------------------|
-| Phase 1 | No CI/CD — manual builds, manual testing, milestone-based releases |
-| Phase 2 | Basic version control, some automation for risk reduction, unit/integration/E2E tests |
-| Phase 3 | Automated infrastructure provisioning, security scans in CI, more frequent deployments |
-| Phase 4 | Continuous integration pipeline, immutable infrastructure managed through pipelines, performance testing |
-| Phase 5 | Zero human intervention, real-time data-driven decisions, multiple daily deployments |
-
-## Sources
-- [[sources/cloud-devop-maturity-guideline.md]]
-- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
+## Git Workflow
+- 特性分支开发：`feature/<description>`
+- 通过 Pull Request 合并到主分支
+- 必须经过代码审查和 CI 测试
+- 合并后触发自动部署流水线
 
 ## Related Concepts
-- [[concepts/DevOps-Maturity]]
-- [[concepts/Infrastructure-as-Code]]
-- [[concepts/DevSecOps]]
-- [[concepts/Continuous-Integration]]
-- [[concepts/Continuous-Deployment]]
-- [[concepts/Change-Failure-Rate]]
+- [[Landing-Zone-Architecture]]：CI/CD 流水线是 Landing Zone 自动化运维的核心机制
+- [[Terraform-Modules]]：被 CI/CD 流水线自动化部署的 IaC 模块
+- [[GitOps]]：基于 Git 的运维方式，CI/CD 是其技术实现
+- [[TerraTest]]：用于基础设施变更的自动化测试工具
 
-## Ingested
-- Date: 2026-04-21
-- Date: 2026-04-24 (updated with maturity level progression)
+## References
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+- [[ctp-topic-9-ci-cd-with-gruntwork]]
+- [[ctp-topic-2-git]]

wiki/concepts/Columnar-Storage.md

@@ -0,0 +1,39 @@
+---
+title: "Columnar Storage"
+type: concept
+tags:
+  - Data-Warehouse
+  - Storage
+  - Performance
+sources:
+  - ctp-topic-68-introduction-to-redshift
+last_updated: 2026-04-23
+---
+
+## Overview
+列式存储（Columnar Storage）是一种数据存储格式，数据按列而非按行组织。专为分析型工作负载（OLAP）设计，相比传统行式存储能显著提升聚合查询和全表扫描性能，同时降低存储空间需求。
+
+## How It Works
+行式存储按行存储：`[row1_col1, row1_col2, row1_col3, row2_col1, row2_col2, row2_col3, ...]`
+列式存储按列存储：`[col1_row1, col1_row2, ..., col2_row1, col2_row2, ..., col3_row1, col3_row2, ...]`
+
+## Key Advantages
+- **查询性能**：只需读取查询涉及的列，避免全行读取 I/O 开销
+- **压缩效率**：同一列数据类型一致，压缩比更高（如 Dictionary Encoding、Run-Length Encoding）
+- **向量化执行**：列式数据可直接进行 SIMD 向量化计算，CPU 利用率更高
+- **聚合查询友好**：COUNT/SUM/AVG 等聚合仅需读取相关列
+
+## Trade-offs
+- **点查询效率低**：单行更新/插入需读写整列数据
+- **写入放大**：行更新涉及多列修改
+- **适用场景受限**：适合读密集型分析，不适合频繁更新的事务处理
+
+## Applications
+- **数据仓库**：Amazon Redshift、Google BigQuery、Snowflake、ClickHouse
+- **列式文件系统**：Apache Parquet、Apache ORC
+- **分析型数据库**：Apache Druid、Apache Kylin
+
+## Related Concepts
+- [[MPP]]：列式存储常与 MPP 架构结合，实现大规模并行分析
+- [[Sort-Key]]：在列式存储中排序键可进一步优化范围查询性能
+- [[Data Compression]]：列式存储天然适合高压缩比

wiki/concepts/DBA-Role-Evolution.md

@@ -0,0 +1,64 @@
+---
+title: "DBA Role Evolution"
+type: concept
+tags:
+  - AWS
+  - Cloud
+  - Database
+  - Career
+sources:
+  - ctp-topic-51-architecting-with-aws-purpose-built-databases
+last_updated: 2026-04-23
+---
+
+## Definition
+云时代 DBA 角色演变（Cloud DBA Evolution）是指数据库管理员（Database Administrator）的职能从传统的底层平台管理（备份、补丁、容量规划）向现代的应用层创新（架构设计、查询优化、性能调优）转变的过程。
+
+## Traditional DBA Responsibilities (On-Premises)
+传统 DBA 的核心职责：
+- **平台管理**：数据库安装、配置、补丁升级
+- **备份恢复**：执行备份、验证恢复、灾难演练
+- **容量规划**：存储计算资源规划、采购
+- **性能监控**：数据库指标监控、瓶颈诊断
+- **安全合规**：用户权限管理、合规审计
+
+## Cloud-Native DBA Responsibilities (AWS)
+云时代 AWS 环境下的 DBA 职能转变：
+
+| 传统职责 | 云时代处理方式 | DBA 新焦点 |
+|---------|--------------|-----------|
+| 备份恢复 | AWS 自动备份（ RDS/Aurora 内置） | 制定备份策略、验证 RTO/RPO |
+| 补丁升级 | AWS 自动打补丁（Managed Service） | 评估补丁影响、安排维护窗口 |
+| 容量规划 | 按需扩展（Auto Scaling / Serverless） | 成本优化、右规格选型 |
+| 故障恢复 | Multi-AZ 自动故障转移 | 架构设计、演练自动化 |
+| 硬件维护 | AWS 负责 | 更高层次的架构决策 |
+
+## New DBA Focus Areas
+云时代 DBA 应聚焦的领域：
+
+1. **数据库架构设计**：专用数据库选型（[[Purpose-Built-Databases]]）、多数据库混合架构
+2. **查询优化**：慢查询分析、索引策略、执行计划优化
+3. **性能调优**：Aurora Serverless、DynamoDB On-Demand 的合理使用
+4. **安全加固**：VPC 安全组、加密（KMS）、IAM 权限最小化
+5. **成本优化**：Reserved Instances、Savings Plans、冷热数据分层
+6. **应用集成**：连接池配置（ RDS Proxy）、读写分离、缓存策略
+7. **数据治理**：Schema 设计规范、数据生命周期管理
+
+## Key Quote
+> "The role of the DBA is evolving in the cloud." — Femi George, AWS Database Sales Specialist
+
+AWS 负责底层平台管理，DBA 的价值转移到**应用创新**而非平台维护。
+
+## Aliases
+- Cloud DBA
+- 云时代 DBA
+- DBA 职能转变
+- Database Administrator Evolution
+- Database Reliability Engineer
+
+## Related Concepts
+- [[Purpose-Built-Databases]]：云时代 DBA 需要掌握多种专用数据库的选型能力
+- [[Multi-Database-Architecture]]：DBA 负责设计多数据库混合架构
+- [[RTO]]：云时代 DBA 关注的关键灾备指标
+- [[Amazon-RDS]]：托管关系型数据库，DBA 从平台管理转向应用优化
+- [[Amazon-Aurora]]：云原生数据库，存储计算分离架构

wiki/concepts/Docker-Containerization.md

@@ -0,0 +1,50 @@
+---
+title: "Docker Containerization"
+type: concept
+tags: [docker, cloud-migration, devops, aws]
+last_updated: 2026-04-23
+---
+
+## Definition
+Docker 容器化是一种操作系统级虚拟化技术，将应用程序及其所有依赖项打包为轻量级、可移植的容器，确保应用程序在任何环境中一致运行。
+
+## Key Features
+- **轻量级**：共享主机操作系统内核，无需完整虚拟机开销
+- **可移植性**：容器在任何支持 Docker 的环境中一致运行
+- **隔离性**：每个容器独立运行，拥有自己的文件系统、网络和进程空间
+- **版本控制**：容器镜像支持版本化，便于回滚和审计
+- **可组合性**：通过 Docker Compose 定义多容器应用
+
+## Cloud Migration Context
+在 [[Octane-Hub]] 的 AWS 迁移案例中，Docker 容器化是关键基础设施：
+
+| 组件 | 原环境 | 目标环境 |
+|------|--------|----------|
+| QuickSee | 物理服务器 | AWS Docker |
+| Release Manager | 物理服务器 | AWS Docker |
+| Patch Manager | 物理服务器 | AWS Docker |
+| 安全程序板 | 物理服务器 | AWS Docker |
+
+### Octane Hub 迁移经验
+- Docker 是主要部署模式，运行在 AWS Landing Zone 账户中
+- 后台作业（支持集成、数据复制、内部空闲搜索）同样容器化
+- 迁移策略："紧密镜像现有设置"，保持应用架构不变
+
+### 未来演进
+- 当前：Docker 容器运行在 EC2 实例上
+- 目标：迁移到 AWS ECS（Elastic Container Service）以获得更好的编排能力
+
+## Key Concepts
+- **镜像 (Image)**：应用程序及其依赖项的可读模板
+- **容器 (Container)**：镜像的运行实例
+- **Dockerfile**：定义镜像构建步骤的脚本
+- **Docker Compose**：定义和运行多容器应用的工具
+- **Volume**：容器持久化数据存储
+
+## Related Concepts
+- [[Packer]]：用于构建 Docker AMI 镜像
+- [[Terraform]]：用于在 AWS 上部署容器基础设施
+- [[AWS-Landing-Zone]]：企业级多账户 AWS 环境
+
+## References
+- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]

wiki/concepts/EFS-vs-EBS.md

@@ -0,0 +1,64 @@
+---
+title: "EFS vs EBS"
+type: concept
+tags: [aws, storage, cloud-migration, devops]
+last_updated: 2026-04-23
+---
+
+## Definition
+AWS 提供多种存储解决方案，其中 EFS（Elastic File System）和 EBS（Elastic Block Store）是两种核心存储类型，适用于不同场景。
+
+## Comparison Table
+
+| 特性 | EBS | EFS |
+|------|-----|-----|
+| **类型** | 块存储（类似虚拟硬盘） | 文件存储（类似网络文件系统 NFS）|
+| **访问方式** | 单个 EC2 实例 | 多个 EC2 实例同时访问 |
+| **性能** | 高性能、低延迟 | 中等性能，适合共享访问 |
+| **价格** | 按存储量和 Provisioned IOPS 计费 | 按实际使用量计费 |
+| **持久性** | 独立于 EC2 生命周期 | 可用区冗余存储 |
+| **适用场景** | 数据库、日志、系统盘 | 共享文件存储、备份、内容管理 |
+
+## Cloud Migration Context
+
+### [[Octane-Hub]] 的存储选型经验
+
+#### 问题发现
+- 最初考虑使用 EFS 用于存储
+- 发现性能问题：**数据库无法直接在 EFS 上运行**
+- EFS 的延迟和吞吐量不适合高 IOPS 需求的工作负载
+
+#### 最终方案
+| 数据类型 | 存储选型 | 原因 |
+|----------|----------|------|
+| MSSQL 数据库（实时）| EBS | 需要高 IOPS、低延迟 |
+| 数据库备份 | EFS | 适合大容量、低频访问 |
+| 未来规划 | S3 | 成本优化目标 |
+
+### 存储选型原则
+1. **高 IOPS 需求**（数据库）→ EBS
+2. **共享文件访问**（多实例）→ EFS
+3. **成本优化/归档** → S3
+4. **混合策略**：热数据用 EBS/EFS，冷数据用 S3
+
+## Key Differences
+
+### EBS 特点
+- 作为 EC2 实例的独立卷挂载
+- 可单独创建快照进行备份
+- 支持 `io1`/`io2` 类型提供高 IOPS
+- 适合：操作系统、数据库、应用数据
+
+### EFS 特点
+- 通过 NFS 协议访问
+- 支持多可用区部署
+- 自动扩展，按使用量计费
+- 适合：Web 服务器共享存储、代码仓库、备份文件
+
+## Related Concepts
+- [[AWS-Landing-Zone]]：企业级 AWS 环境架构
+- [[Octane-Hub]]：Docker 容器化工作负载迁移案例
+- [[Cloud-Migration]]：云迁移最佳实践
+
+## References
+- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]

wiki/concepts/Federated-Access.md

@@ -0,0 +1,39 @@
+---
+---
+title: "Federated Access"
+type: concept
+sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-11-ad-integration-and-login-using-ad-accounts]
+last_updated: 2026-04-14
+---
+
+## Definition
+联邦访问（Federated Access）是一种基于身份联合（Identity Federation）的 AWS 身份管理机制。用户通过企业现有身份提供者（如 Active Directory）进行身份验证，由 AD 组自动映射到对应的 IAM 角色，从而获得云平台资源的访问权限，无需在 AWS 中单独创建和管理 IAM 用户。
+
+## Key Benefits
+- **集中身份管理**：使用企业现有 AD，无需在 AWS 中单独管理用户账号
+- **自动化权限分配**：AD 组 → IAM 角色的映射自动化，人员变动即时生效
+- **安全审计**：所有访问通过 AD 域控制器统一记录和审计
+- **消除凭证共享**：避免 IAM Access Key 的分发和管理风险
+
+## Architecture
+- **Identity Provider (IdP)**：企业 Active Directory
+- **AWS IAM Identity Provider**：在 AWS 中配置 SAML 2.0 联合身份
+- **IAM Roles**：定义具体权限策略，信任策略允许 IdP 中的特定 AD 组
+- **AD Groups**：在 AD 中维护的组，按职能或项目划分
+
+## Workflow
+1. 用户在企业网络登录 AD 账户
+2. 通过 AWS SSO 或 SAML 联合发起 AWS 控制台或 CLI 访问请求
+3. AWS 使用 AD 凭证验证用户身份
+4. 根据用户所属 AD 组，分配对应 IAM 角色的临时凭证
+5. 凭证自动过期，强制定期重新认证
+
+## Related Concepts
+- [[Landing-Zone-Architecture]]：联邦访问是 Landing Zone 安全账户的核心身份管理机制
+- [[IAM]]：AWS 身份和访问管理的底层服务
+- [[Active-Directory]]：企业侧的联合身份提供者
+
+## References
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+- [[ctp-topic-5-aws-identity-and-access-management-iam]]

wiki/concepts/Landing-Zone-Architecture.md

@@ -0,0 +1,44 @@
+---
+title: "Landing Zone Architecture"
+type: concept
+sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]
+last_updated: 2026-04-14
+---
+
+## Definition
+Landing Zone（落地区）是基于 Gruntwork 仓库的 AWS 多账户基础设施部署单元。每个 Landing Zone 对应一个独立的 AWS 环境（如 R&D Labs、SAS/Staging/Production），由产品团队在 Gruntwork 参考架构基础上自行定义具体服务（如 ECS 集群、RDS 数据库），并通过独立的 GitHub 仓库管理 IaC 代码。
+
+## Key Characteristics
+
+### 与 Reference Architecture 的区别
+- **Reference Architecture**：标准化的最佳实践起点和蓝图
+- **Landing Zone**：基于 Reference Architecture 的具体部署实现，由产品团队定制
+- **关键区别**：Landing Zone 不包含 ECS 集群或 RDS 数据库等具体服务，而是由各产品团队自行填充
+
+### 部署结构
+- 每个 Landing Zone 拥有独立的 GitHub 仓库管理 Terraform/IaC 代码
+- 每个 Landing Zone 配置独立的 Jenkins 服务器用于部署基础设施变更
+- 每个产品团队维护自己的 Jenkins 任务来部署其负责的基础设施
+
+### 身份管理
+- 安全账户使用**联邦用户（Federated User）**
+- 通过 AD（Active Directory）组映射到 IAM 角色
+- 替代传统的 IAM 用户管理方式
+
+## Deployment Workflow
+1. Gruntwork 提供参考架构和 Terraform 模块库
+2. 产品团队基于 Gruntwork 仓库创建自己的 Landing Zone
+3. 使用特性分支开发，通过 Pull Request 合并到主分支
+4. Jenkins CI/CD 流水线自动化执行 Terraform Plan/Apply
+5. TerraTest 用于基础设施变更的自动化测试
+
+## Related Concepts
+- [[Reference-Architecture]]：Landing Zone 的设计蓝图
+- [[Federated-Access]]：Landing Zone 安全账户的身份管理机制
+- [[CI-CD-Pipeline]]：Landing Zone 的自动化部署流水线
+- [[Terraform-Modules]]：Gruntwork 提供的 IaC 模块库
+
+## References
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]
+- [[ctp-topic-9-ci-cd-with-gruntwork]]

wiki/concepts/MPP.md

@@ -0,0 +1,40 @@
+---
+title: "MPP (Massively Parallel Processing)"
+type: concept
+tags:
+  - Distributed Computing
+  - Data-Warehouse
+  - Performance
+sources:
+  - ctp-topic-68-introduction-to-redshift
+last_updated: 2026-04-23
+---
+
+## Overview
+MPP（大规模并行处理）是一种分布式计算架构，通过多个计算节点并行执行查询和数据处理任务，显著提升大规模数据集的查询速度和系统吞吐量。
+
+## How It Works
+1. **任务分解**：协调节点（Leader/Coordinator）将大型查询分解为多个子任务
+2. **并行分发**：子任务分发至多个计算节点（Compute Node）
+3. **独立执行**：各节点在本地数据子集（Slice/Partition）上并行执行计算
+4. **结果汇总**：各节点结果返回协调节点，进行最终聚合和输出
+
+## Key Benefits
+- **线性扩展**：增加节点数量可线性提升查询性能
+- **高吞吐量**：适合复杂分析查询和大规模数据聚合
+- **容错性**：单节点故障不影响整体系统（部分实现）
+
+## Trade-offs
+- **数据倾斜（Data Skew）**：数据分布不均导致部分节点负载过重
+- **跨节点通信**：节点间数据传输增加延迟
+- **复杂查询优化**：需精心设计数据分布策略
+
+## Applications
+- **数据仓库**：Amazon Redshift、Snowflake、Google BigQuery
+- **大数据处理**：Apache Spark（Spark SQL）、Presto/Trino
+- **科学计算**：分布式矩阵运算、基因组分析
+
+## Related Concepts
+- [[Columnar-Storage]]：列式存储与 MPP 协同优化分析查询
+- [[Distribution-Key]]：数据分布策略影响 MPP 性能
+- [[Sort-Key]]：排序键优化局部性，提升 MPP 节点内效率

wiki/concepts/Multi-Database-Architecture.md

@@ -0,0 +1,89 @@
+---
+title: "Multi-Database Architecture"
+type: concept
+tags:
+  - AWS
+  - Database
+  - Architecture
+  - Microservices
+sources:
+  - ctp-topic-51-architecting-with-aws-purpose-built-databases
+last_updated: 2026-04-23
+---
+
+## Definition
+多数据库混合架构（Multi-Database Architecture）是指在单一应用中根据各部分的数据特征选用不同类型专用数据库的架构模式，以实现最优的数据层性能。
+
+## Core Principle
+每个数据模型应使用最适合它的数据库类型：
+- **关系型数据** → 关系型数据库（Aurora / RDS）
+- **高频读取** → 内存缓存（ElastiCache）
+- **无结构键值** → 键值数据库（ DynamoDB）
+- **高度互连** → 图数据库（Neptune）
+
+## Real-World Case Studies
+
+### Duolingo 案例（来源：[[ctp-topic-51-purpose-built-databases]]）
+| 数据类型 | 数据库 | 选型原因 |
+|---------|--------|---------|
+| 个性化学习进度 | DynamoDB | 高写入、低延迟、弹性扩展 |
+| 高频词/短语 | ElastiCache | 微秒级读取缓存 |
+| 事务数据（购买、订阅）| Aurora | ACID 强一致性、复杂查询 |
+
+### Netflix 案例（来源：[[ctp-topic-51-purpose-built-databases]]）
+| 数据类型 | 数据库 | 选型原因 |
+|---------|--------|---------|
+| JSON 文档（用户数据、偏好）| DynamoDB | 高弹性、低延迟、JSON 原生支持 |
+
+### Peloton 案例（来源：[[ctp-topic-51-purpose-built-databases]]）
+| 数据类型 | 数据库 | 选型原因 |
+|---------|--------|---------|
+| 实时健身反馈 | ElastiCache Redis | 微秒级响应、即时用户体验 |
+
+## Architecture Patterns
+
+### Cache-Aside Pattern（旁路缓存）
+```
+应用 → DynamoDB/RDS（主数据库）
+     ↘ ElastiCache（缓存层）
+```
+- 读取：先查缓存，未命中则查数据库并回填缓存
+- 写入：先写数据库，再失效/更新缓存
+
+### CQRS Pattern（命令查询职责分离）
+```
+写入 → DynamoDB（优化写入）
+读取 → DynamoDB + ElastiCache（优化读取）
+     ↘ Aurora（复杂查询读取）
+```
+
+### Event-Driven Data Sync
+```
+DynamoDB Streams → Lambda → Aurora
+                  → Lambda → Elasticsearch（搜索）
+                  → Lambda → S3（归档）
+```
+
+## Trade-offs
+| 优势 | 挑战 |
+|------|------|
+| 最优性能：每个场景用最佳数据库 | 复杂度：多数据库运维成本 |
+| 弹性扩展：各层独立扩展 | 一致性：跨数据库事务管理 |
+| 成本优化：按需选择规格 | 学习曲线：团队需掌握多种数据库 |
+| 容错隔离：单库故障不扩散 | 数据迁移：服务间数据同步 |
+
+## Aliases
+- Polyglot Persistence
+- 多数据库混合架构
+- 数据库混合部署
+- Database Polyglot
+- Mixed Database Architecture
+
+## Related Concepts
+- [[Purpose-Built-Databases]]：多数据库架构的基础——专用数据库选型原则
+- [[Amazon-DynamoDB]]：多数据库架构中的键值/文档数据存储
+- [[Amazon-ElastiCache]]：多数据库架构中的缓存层组件
+- [[Amazon-Aurora]]：多数据库架构中的关系型事务数据存储
+- [[Amazon-Neptune]]：多数据库架构中的图数据存储
+- [[Amazon-Timestream]]：多数据库架构中的时序数据存储
+- [[DBA-Role-Evolution]]：云时代 DBA 需要掌握多数据库架构设计能力

wiki/concepts/Purpose-Built-Databases.md

@@ -0,0 +1,70 @@
+---
+title: "Purpose-Built Databases"
+type: concept
+tags:
+  - AWS
+  - Database
+  - Architecture
+  - Cloud-Native
+sources:
+  - ctp-topic-51-architecting-with-aws-purpose-built-databases
+last_updated: 2026-04-23
+---
+
+## Definition
+专用数据库（Purpose-Built Databases）是一种数据库选型原则——根据应用的数据模型、访问模式和性能需求，选择最适合该用例的专用数据库类型，而非用单一数据库解决所有问题。
+
+## Core Principle
+> "We need to start thinking of the right purpose-built database for the right application." — Femi George, AWS Database Sales Specialist
+
+核心理念：**从用例出发，选择最佳工具，避免一刀切（One-Size-Fits-All）**。
+
+## AWS Database Categories
+
+| 类别 | AWS 产品 | 适用场景 |
+|------|---------|---------|
+| 关系型 | RDS, Aurora | 固定 schema、ACID 事务、复杂关联查询 |
+| 键值 | DynamoDB | 高吞吐量、简单键值访问、无 schema 约束 |
+| 文档 | DocumentDB | 半结构化 JSON、灵活 schema、嵌套查询 |
+| 宽列 | Keyspaces | 大规模写入、Cassandra 兼容工作负载 |
+| 内存缓存 | ElastiCache | 微秒级延迟、高频读取、会话存储 |
+| 图数据库 | Neptune | 高度互连数据、欺诈检测、推荐引擎 |
+| 时序数据库 | Timestream | IoT 遥测、监控指标、时间序列分析 |
+| 账本数据库 | QLDB | 不可变事务日志、审计追踪 |
+
+## Selection Criteria
+选择专用数据库时应考虑：
+1. **应用规模**：用户数量、请求量、数据量
+2. **访问模式**：读密集 vs 写密集、点查 vs 范围查询
+3. **数据模型**：结构化 vs 半结构化、关系复杂度
+4. **性能需求**：延迟、吞吐量、可用性
+5. **运维成本**：托管 vs 自管理、团队技能
+
+## Multi-Database Architecture
+现代应用常采用多数据库混合架构：
+
+**Duolingo 案例**（来源：[[ctp-topic-51-purpose-built-databases]]）：
+- **DynamoDB**：存储个性化学习进度数据（键值访问）
+- **ElastiCache**：缓存高频词/短语（内存缓存）
+- **Aurora**：处理事务性数据（关系型）
+
+**Netflix 案例**（来源：[[ctp-topic-51-purpose-built-databases]]）：
+- **DynamoDB**：高弹性、低延迟 JSON 文档访问
+
+## Aliases
+- Purpose-Built Databases
+- 专用数据库
+- 专用数据库选型
+- Database Polyglot
+- Polyglot Persistence
+
+## Related Concepts
+- [[Multi-Database-Architecture]]：多数据库混合架构模式
+- [[Amazon-DynamoDB]]：AWS 专用键值数据库
+- [[Amazon-Aurora]]：云原生关系型数据库
+- [[Amazon-Neptune]]：AWS 图数据库
+- [[Amazon-Timestream]]：AWS 时序数据库
+- [[Amazon-Keyspaces]]：AWS 宽列数据库
+- [[Amazon-DocumentDB]]：AWS 文档数据库
+- [[Amazon-ElastiCache]]：AWS 内存缓存数据库
+- [[DBA-Role-Evolution]]：云时代数据库架构师角色的转变

wiki/concepts/RTO.md

@@ -1,81 +1,55 @@
 ---
-title: "RTO (Recovery Time Objective)"
-tags: [devops, disaster-recovery, sre, reliability]
-created: 2026-04-25
+title: "RTO"
+type: concept
+tags:
+  - AWS
+  - Disaster Recovery
+  - High Availability
+  - Cloud Architecture
+sources:
+  - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
+last_updated: 2026-04-23
 ---
 
-# RTO (Recovery Time Objective)
-
-**RTO (Recovery Time Objective)** 是指系统发生故障后，业务能够容忍的最大停机时间。它衡量的是恢复速度——从系统下线到用户可以重新使用系统的时间窗口。
+## Overview
+RTO（Recovery Time Objective，恢复时间目标）是从系统故障发生到恢复正常运行所需的最大可接受时间。是灾备（DR）策略中的核心指标。
 
 ## Definition
+- **RTO**：系统从故障中恢复的时间目标
+- 与 [[RPO]]（Recovery Point Objective，恢复点目标）共同构成灾备的两大核心指标
 
-> "RTO is about getting back online. It's the clock that starts ticking the moment your system goes down." — LaunchDarkly
+## AWS Database RTO 对比
 
-RTO 是灾备规划的核心指标之一，与 [[RPO]]（恢复点目标）共同构成灾备目标体系。
+| 数据库服务 | AZ 故障 RTO | 架构特点 |
+|-----------|------------|----------|
+| **Aurora** | ~30 秒 | 6 副本跨 3 AZ 共享集群卷 |
+| **RDS** | ~2 分钟 | EC2 + EBS 分离，Multi-AZ 备用节点 |
+| **传统自建** | 数小时 | 需手动恢复 |
 
-## Key Characteristics
+## RTO vs RPO
 
-| 维度 | 说明 |
-|------|------|
-| **衡量对象** | 停机时间（Downtime Duration） |
-| **起点** | 系统故障发生的时刻 |
-| **终点** | 用户可以重新使用系统 |
-| **关注点** | 速度（How Fast） |
+| 指标 | 定义 | 衡量内容 |
+|------|------|----------|
+| **RTO** | 恢复时间目标 | 系统不可用的最大时长 |
+| **RPO** | 恢复点目标 | 可接受的最大数据丢失时长 |
 
-## RTO vs. RPO
-
-RTO 和 RPO 经常被混淆，但衡量的是完全不同的维度：
-
-- **RTO** — 关注速度：系统多久能恢复？
-- **RPO** — 关注数据：能承受多少数据丢失？
-
-两者可以独立设定：快速恢复不代表数据不丢失，反之亦然。
-
-## Tiered RTO Targets
-
-| Tier | 场景 | RTO 目标 | 说明 |
-|------|------|----------|------|
-| Critical | 支付处理、用户认证 | < 5 分钟 | 业务立即停止，需要 3AM 告警 |
-| Important | 管理后台、报表 | < 1 小时 | 业务减速但不停止 |
-| Nice-to-have | 内部工具、文档站 | < 4 小时 | 仅造成不便 |
-
-## RTO in Modern CD Context
-
-传统灾备规划假设 RTO 针对的是硬件故障（服务器宕机、数据中心断电），但现代持续交付中最大的风险来自**代码变更**：
-
-- 支付流程 Bug 导致结账失败
-- 数据库迁移锁死应用
-- AI 模型更新产生异常响应
-- 新功能在负载下性能骤降
-
-**[[Feature Flag]]** 将 RTO 从小时级降至秒级：只需切换配置，无需重新部署代码。
-
-## 实现手段
-
-| 方法 | RTO 效果 | 说明 |
-|------|----------|------|
-| 传统灾备（从备份恢复） | 小时级 | 需要重建基础设施 |
-| [[Kill Switch]]（Feature Flag） | 秒级 | 配置变更，无需部署 |
-| 容器化 + 自动扩缩容 | 分钟级 | 需要容器编排平台 |
-| Active-Active 多活 | 近零 | 成本极高 |
-
-## RTO 与成本的关系
-
-- 近零 RTO 需要"冗余一切"（服务器、数据库、网络、跨数据中心）
-- 大多数团队无法承担如此高的成本
-- **建议**：按应用分层级设定 RTO，而非对所有系统一刀切
-
-> "What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it."
+## Key Insights
+- Aurora 的低 RTO 源于其 6 副本跨 3 AZ 的共享集群卷架构，故障时无需重建数据
+- RDS 的 RTO 较高是因为需要备用节点接管并重新建立连接
+- RTO 优化需要考虑 DNS TTL、TCP Keep-Alive、连接池配置等多个层面
+- **[[LaunchDarkly]]** 是企业 RTO 优化的典型案例
 
 ## Related Concepts
+- [[RPO]]：Recovery Point Objective，恢复点目标
+- [[Disaster Recovery]]：灾备策略
+- [[High Availability]]：高可用性
+- [[Amazon Aurora]]：Aurora 的 RTO 优势
+- [[Amazon RDS]]：RDS 的 RTO 特点
+- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：AWS 数据库 RTO 实测对比
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]：企业级灾备策略
 
-- [[RPO]] — Recovery Point Objective，数据丢失量指标
-- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标
-- [[Kill Switch]] — 通过 Feature Flag 实现秒级 RTO
-- [[High Availability]] — 高可用性，降低 RTO 的基础设施
-- [[Feature Flag]] — 实现配置级热修复的核心机制
-
-## Sources
-
-- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
+## Aliases
+- Recovery Time Objective
+- 恢复时间目标
+- RTO
+- MTTR（Mean Time To Recovery，与 RTO 相关但 MTTR 是实际测量值）

wiki/concepts/Reference-Architecture.md

@@ -0,0 +1,39 @@
+---
+title: "Reference Architecture"
+type: concept
+sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]
+last_updated: 2026-04-14
+---
+
+## Definition
+参考架构（Reference Architecture）是一套经过实战验证的最佳实践集合，作为企业云平台部署的起点和蓝图。它定义了标准化的账户结构、网络拓扑、安全边界和服务组合，帮助组织快速建立符合安全和合规要求的云基础设施。
+
+## Key Components
+
+### Account Structure
+- **Core Accounts（核心账户）**：
+  - `Shared`：共享服务账户，提供 CI/CD 工具、NTP、DNS 等公共服务
+  - `Logs`：日志账户，集中收集和存储所有账户的审计日志
+  - `Security`：安全账户，托管 IAM 角色和联邦身份配置
+- **Workload Accounts（工作负载账户）**：
+  - `Prod`：生产环境账户
+  - `Stage`：预发布环境账户
+  - `Dev`：开发环境账户
+
+### Network Topology
+- Centralized network design with VPCs per account
+- Transit Gateway for cross-account connectivity
+- Shared services accessible via VPC peering or Transit Gateway
+
+## Relationship with Landing Zone
+- **Reference Architecture**：标准化的起点和蓝图，定义通用模式
+- **Landing Zone**：基于 Reference Architecture 的具体部署单元，由各产品团队在 Gruntwork 仓库基础上定制
+
+## Related Concepts
+- [[Landing-Zone-Architecture]]：Reference Architecture 的具体部署实例
+- [[Federated-Access]]：安全账户的身份管理机制
+- [[Terraform-Modules]]：实现 Reference Architecture 的 IaC 模块库
+
+## References
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]

wiki/concepts/Service-Control-Policies-SCPs.md

@@ -0,0 +1,98 @@
+---
+title: "Service Control Policies (SCPs)"
+type: concept
+tags: [AWS, Organizations, Policy, Security, Compliance, Tagging]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+Service Control Policies（SCPs，服务控制策略）是 AWS Organizations 的一种高级策略类型，用于集中定义在组织单元（OU）或账户级别上所有成员账户的最大可用权限。SCPs 属于预防性控制（Preventive Controls），在 IAM 权限被评估之前先被执行，确保任何账户中的任何操作都不会超出组织设定的安全边界。与 IAM 策略不同，SCPs 本身不授予权限，而是限制可授予的权限范围。
+
+## Aliases
+- SCP
+- Service Control Policy
+- Organization Policy
+- AWS Organization Policy
+
+## Core Attributes
+
+| 属性 | 说明 |
+|------|------|
+| 作用层级 | Organization Root / Organizational Unit (OU) / Account |
+| 策略类型 | 预防性控制（Preventive） |
+| 执行顺序 | 在 IAM 权限评估之前执行 |
+| 默认行为 | 除非显式允许，否则拒绝（Default Deny） |
+| 影响范围 | 组织内所有成员账户 |
+| 不支持的操作 | 无法在根账户上附加 SCP |
+
+## Use Cases
+
+### 1. 标签合规性强制执行
+在该组织的 AWS Landing Zone 中，SCPs 用于强制执行标签规范——阻止不合规资源（如缺少必需标签键或标签值不在允许列表中）的创建。这确保了新资源从一开始就符合组织的安全和网络策略要求。
+
+### 2. 服务限制
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Sid": "DenyUnapprovedRegions",
+      "Effect": "Deny",
+      "Action": "*",
+      "Resource": "*",
+      "Condition": {
+        "StringNotEquals": {
+          "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
+        }
+      }
+    }
+  ]
+}
+```
+
+## Limitations
+
+| 限制 | 说明 |
+|------|------|
+| 存量资源 | SCPs 无法修改或删除已存在的资源，只能阻止新资源的创建 |
+| 根账户 | 无法对组织的根账户附加 SCP |
+| 服务控制粒度 | 无法直接基于资源标签值做细粒度控制（需配合其他机制） |
+| Tag-based SCPs | 可基于标签键存在性做过滤，但无法基于标签值列表做精确限制 |
+
+在标签合规性场景下，SCPs 可以强制要求"必须包含某标签键"，但对于"标签值必须在允许列表中"这类精确验证，则需要依赖 Tag Validation Tool 进行审计。
+
+## SCPs vs IAM Policies
+
+| 维度 | SCPs | IAM Policies |
+|------|------|-------------|
+| 作用对象 | 组织/OU/账户级别 | IAM 用户/角色/组 |
+| 执行顺序 | 先于 IAM | 后于 SCPs |
+| 授予权限 | 否（仅限制范围） | 是 |
+| 覆盖范围 | 全账户所有实体 | 指定实体 |
+
+## Context in This Wiki
+
+SCPs 与 Tag Validation Tool 在标签治理中形成互补关系：
+
+```
+SCPs（预防性控制）
+  ↓ 阻止不合规资源的新建
+  ↓
+Tag Validation Tool（检测性控制）
+  ↓ 发现已存在的不合规存量资源
+  ↓
+CSV 审计报告 → 团队手动修复
+```
+
+## Related Concepts
+
+- [[AWS-Tagging-Standards]]：SCPs 强制执行的对象规范
+- [[Tag-Validation-Tool]]：SCPs 的下游补充（处理存量资源审计）
+- [[Policy-as-Code]]：SCPs 本身应以代码形式管理（版本控制/GitOps）
+- [[AWS-Organizations]]：SCPs 的承载平台
+- [[Zero-Trust-Architecture]]：SCPs 是零信任原则在 AWS Organizations 中的体现
+
+## Sources
+
+- [[ctp-topic-28-aws-tag-validation-tool]]

wiki/concepts/SnapMirror.md

@@ -0,0 +1,43 @@
+---
+title: "SnapMirror"
+type: concept
+tags: [NetApp, Data-Replication, Disaster-Recovery, Storage]
+sources: [ctp-topic-46-netapps-on-aws]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+SnapMirror 是 NetApp 提供的数据复制技术，用于在 NetApp 存储系统之间（本地到云端、跨区域或跨集群）复制数据和快照。通过块级复制实现高效的数据同步，初始基线复制后，后续更新仅传输变更数据（增量复制）。
+
+## Mechanism
+
+1. **Peering Relationship**：在集群之间和 SVM 之间建立对等关系
+2. **Baseline Copy**：初始全量复制，将源卷的完整数据复制到目标卷
+3. **Incremental Updates**：基线后，仅复制自上次更新以来更改的数据块
+4. **Read-Only Destination**：SnapMirror 关系中的目标卷为只读
+
+## Key Characteristics
+
+- **Block-Level Replication**：块级复制而非文件级，支持 Deduplication 和 Compression 保留
+- **Encryption Support**：可选加密传输
+- **SnapMirror Relationships**：可建立级联或扇出配置
+- **Transfer Priority**：可配置传输优先级
+
+## Use Cases
+
+- **Disaster Recovery**：本地 NetApp 到 AWS CVO 的灾备复制
+- **Data Migration**：从本地迁移到云端（配合 Cloud Volume ONTAP）
+- **Cross-Region Replication**：跨 AWS 区域的数据保护
+- **Backup to Cloud**：冷数据备份到 S3（通过 CVO）
+
+## Related Concepts
+
+- [[Snapshot]]：SnapMirror 复制快照作为数据一致性的保证
+- [[Cloud Volume ONTAP (CVO)]]：AWS 云端运行 SnapMirror 的目标存储
+- [[Data Tiering]]：可与 SnapMirror 结合实现数据生命周期管理
+- [[Disaster Recovery]]：SnapMirror 是 DR 策略的核心组件
+
+## Related Entities
+
+- [[NetApp]]：SnapMirror 的提供方

wiki/concepts/Tag-Validation-Tool.md

@@ -0,0 +1,71 @@
+---
+title: "Tag Validation Tool"
+type: concept
+tags: [AWS, Tagging, Validation, SRE, Python, Boto3, Automation]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+AWS Tag Validation Tool（SRE 团队开发的 AWS 标签验证工具）是一个基于 Python 和 Boto3 的自动化审计工具，用于扫描 AWS 账户中的资源标签合规性。该工具通过 YAML 配置文件（`variables.yaml`）定义每个账户的合法标签键及允许值，自动扫描 EC2、安全组（Security Groups）、负载均衡器（Load Balancers）和 Lambda 函数等资源类型，将扫描结果与预期值进行比对，最终生成详细的 CSV 审计报告。
+
+## Aliases
+- AWS Tag Validator
+- Tag Audit Tool
+- Tag Compliance Scanner
+
+## Core Components
+
+### Architecture
+```
+variables.yaml  →  Python/Boto3 扫描器  →  CSV 审计报告
+     ↑                                    ↑
+  合法标签配置                      不合规资源列表
+  (per account)                      (Resource ID + 问题描述)
+```
+
+### Technology Stack
+| 组件 | 技术 |
+|------|------|
+| 语言 | Python |
+| AWS SDK | Boto3 |
+| 环境管理 | Poetry |
+| 扫描对象 | EC2, Security Groups, Load Balancers, Lambda |
+| 配置格式 | YAML |
+| 输出格式 | CSV |
+
+### Configuration (variables.yaml)
+```yaml
+tags:
+  Environment:
+    allowed_values:
+      - dev
+      - staging
+      - prod
+  CostCenter:
+    allowed_values:
+      - CC-001
+      - CC-002
+```
+
+## Context in This Wiki
+
+该工具解决了 Checkpoint 防火墙依赖标签配置网络访问策略所带来的合规性问题：
+
+- **问题背景**：SCPs（Service Control Policies）仅能阻止不合规资源的新建，无法修复已存在的存量资源
+- **解决方案**：该工具扫描存量资源，识别缺失或值错误的标签，生成 CSV 报告供团队修复
+- **工具定位**：属标签治理闭环的第三环——制定规范（Topic 10）→ 强制执行（SCPs）→ 审计发现（Topic 28）
+
+## Related Concepts
+
+- [[AWS-Tags]]：被验证的 AWS 资源标签
+- [[AWS-Tagging-Standards]]：标签规范的定义
+- [[Variables-YAML]]：工具的核心配置文件
+- [[Service-Control-Policies-SCPs]]：上游强制机制（阻止新资源创建但无法处理存量）
+- [[Boto3]]：工具使用的 AWS Python SDK
+- [[Poetry]]：工具的环境管理工具
+- [[Checkpoint-Firewall]]：依赖正确标签值配置网络访问策略
+
+## Sources
+
+- [[ctp-topic-28-aws-tag-validation-tool]]

wiki/concepts/Terraform-Modules.md

@@ -0,0 +1,62 @@
+---
+title: "Terraform Modules"
+type: concept
+sources: [ctp-topic-1-gruntwork-landing-zone-architecture, ctp-topic-3-deploy-and-maintain-infrastructure]
+last_updated: 2026-04-14
+---
+
+## Definition
+Terraform 模块（Terraform Modules）是一组可复用、经过测试的 Terraform 配置文件，用于构建具有业务上下文的 AWS 云服务。Gruntwork 的 Terraform AWS 服务目录（Service Catalog）提供了经过生产环境实战验证的模块集合，强调服务应具有业务上下文，而非简单的资源堆砌。
+
+## Key Principles
+
+### Business Context Over Raw Resources
+- 传统 IaC：定义单个 AWS 资源（EC2 实例、安全组等）
+- Gruntwork 模块：封装完整的服务逻辑（如"Web 应用服务"而非"VPC + EC2 + ALB"）
+- 模块包含服务所需的全部配置：网络、安全、监控、日志、备份等
+
+### Reusability
+- 一次编写，多处使用
+- 版本化管理，通过 Terraform Module Registry 分发
+- 支持参数化配置，适应不同环境
+
+### Production-Ready
+- 经过多个客户生产环境验证
+- 内置安全最佳实践（加密、访问控制、审计日志）
+- 包含监控和告警配置
+- 支持灾难恢复和备份策略
+
+## Module Structure
+```
+module/
+├── main.tf          # 主要资源定义
+├── variables.tf     # 输入变量
+├── outputs.tf       # 输出值
+├── versions.tf      # Terraform 版本约束
+├── examples/        # 使用示例
+└── test/            # TerraTest 测试
+```
+
+## Gruntwork Service Catalog
+Gruntwork 提供的 Terraform 模块库，涵盖：
+- 网络层：VPC、子网、NAT Gateway、VPN
+- 计算层：ECS 集群、自动扩展组
+- 数据层：RDS 数据库、DynamoDB 表
+- 安全层：IAM 角色、KMS 密钥、安全组
+- 监控层：CloudWatch 告警、日志配置
+
+## Relationship with Landing Zone
+- Landing Zone 基于 Gruntwork 仓库创建
+- 产品团队使用 Gruntwork 模块构建业务服务
+- CI/CD 流水线自动化部署 Terraform 模块
+
+## Related Concepts
+- [[Landing-Zone-Architecture]]：使用 Terraform 模块构建 Landing Zone
+- [[Terraform]]：基础设施即代码工具，Terraform 模块是其复用单元
+- [[TerraTest]]：用于测试 Terraform 模块的 Go 测试框架
+- [[CI-CD-Pipeline]]：自动化部署 Terraform 模块的流水线
+
+## References
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-9-ci-cd-with-gruntwork]]

wiki/concepts/Variables-YAML.md

@@ -0,0 +1,103 @@
+---
+title: "Variables YAML"
+type: concept
+tags: [AWS, Tagging, Configuration, YAML, Automation]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+`variables.yaml` 是 AWS Tag Validation Tool 的核心配置文件，采用 YAML 格式定义每个 AWS 账户所期望的合法标签键及其对应的允许值列表（Allowed Values）。该文件是标签验证工具进行合规性比对的数据来源，每个账户可拥有独立的 `variables.yaml` 配置。
+
+## Aliases
+- variables.yml
+- tag-variables.yaml
+- account-vars.yaml
+
+## File Structure
+
+```yaml
+# variables.yaml — 每个账户一份
+account_id: "123456789012"
+account_name: "sas-prod"
+
+tags:
+  Environment:
+    required: true
+    allowed_values:
+      - dev
+      - staging
+      - prod
+      - uat
+
+  CostCenter:
+    required: true
+    allowed_values:
+      - CC-FINANCE
+      - CC-ENGINEERING
+      - CC-OPERATIONS
+
+  Owner:
+    required: true
+    allowed_values:
+      - team-platform
+      - team-data
+      - team-security
+
+  Application:
+    required: false
+    allowed_values: []  # any value accepted
+
+  Project:
+    required: true
+    allowed_values:
+      - project-alpha
+      - project-beta
+      - poc-ml-pipeline
+```
+
+## Core Attributes
+
+| 属性 | 说明 |
+|------|------|
+| 文件格式 | YAML |
+| 作用域 | Per-account（每个账户独立配置） |
+| 用途 | Tag Validation Tool 合规性比对的数据源 |
+| 存储位置 | SRE Tools Repository |
+| 管理方式 | 版本控制（Git） |
+
+## Fields
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `account_id` | string | 是 | AWS 账户 ID |
+| `account_name` | string | 是 | 账户名称（便于识别） |
+| `tags` | dict | 是 | 标签键→约束映射 |
+| `required` | bool | 否 | 该标签是否为必填项 |
+| `allowed_values` | list | 否 | 该标签的允许值集合；空列表表示任意值 |
+
+## Context in This Wiki
+
+在 AWS Tag Validation Tool 的工作流中，`variables.yaml` 扮演数据模型的角色：
+
+```
+variables.yaml 定义规范
+        ↓
+Tag Validation Tool 读取配置
+        ↓
+扫描 AWS 账户资源（EC2/SG/LB/Lambda）
+        ↓
+比对实际标签值与 allowed_values
+        ↓
+生成 CSV 报告（Resource ID + 问题类型 + 期望值 vs 实际值）
+```
+
+## Related Concepts
+
+- [[Tag-Validation-Tool]]：使用 variables.yaml 作为数据源的工具
+- [[AWS-Tagging-Standards]]：标签规范的来源
+- [[Service-Control-Policies-SCPs]]：与 variables.yaml 共同构成标签治理的"规则定义 + 强制 + 审计"三层体系
+
+## Sources
+
+- [[ctp-topic-28-aws-tag-validation-tool]]

wiki/concepts/技术图生成.md

@@ -0,0 +1,45 @@
+---
+title: "技术图生成"
+type: concept
+tags: []
+sources: [fireworks-tech-graph]
+last_updated: 2026-04-18
+---
+
+## Description
+用自然语言描述系统架构、流程或关系，自动生成可直接发布的 SVG/PNG 技术图的过程。核心技术栈包括 LLM 生成 SVG 代码 + 渲染工具导出 PNG。
+
+## 核心流程
+1. **自然语言描述** → 用户用文字描述想要的图（架构/流程/对比/思维导图等）
+2. **LLM 解析 + SVG 生成** → AI 理解描述，生成符合形状词汇表和箭头语义的 SVG 代码
+3. **渲染导出** → `rsvg-convert` 将 SVG 渲染为 1920px PNG
+4. **发布** → PNG 直接嵌入文章/Slide/文档
+
+## 关键工具
+- [[fireworks-tech-graph]]：Claude Code Skill，内置 7 种风格 + 14 种 UML 图
+- [[rsvg-convert]]：SVG → PNG 渲染工具
+- [[7种视觉风格系统]]：确保图形风格一致性
+- [[语义形状词汇表]]：确保图形元素语义一致性
+- [[语义箭头系统]]：确保箭头语义一致性
+- [[14种UML图]]：覆盖完整 UML 图类型
+
+## 应用场景
+- **技术文档**：RAG 架构图、Agent 流程图、系统架构图
+- **博客文章**：配图生成，提升文章可读性
+- **演示文稿**：Keynote/Slide 配图，支持多种视觉风格
+- **内部 Wiki**：知识图谱、流程说明
+- **GitHub README**：项目架构图、流程图
+
+## 优势
+- **速度**：几秒生成，无需手动绘图
+- **一致性**：形状词汇表 + 语义箭头系统确保视觉语义统一
+- **可编辑**：SVG 输出可随时修改
+- **可发布**：PNG 可直接嵌入文档
+
+## Relationships
+- [[技术图生成]] uses [[fireworks-tech-graph]]
+- [[技术图生成]] uses [[7种视觉风格系统]]
+- [[技术图生成]] uses [[语义形状词汇表]]
+- [[技术图生成]] uses [[语义箭头系统]]
+- [[技术图生成]] uses [[14种UML图]]
+- [[技术图生成]] uses [[rsvg-convert]]

wiki/concepts/语义形状词汇表.md

@@ -0,0 +1,38 @@
+---
+title: "语义形状词汇表"
+type: concept
+tags: []
+sources: [fireworks-tech-graph]
+last_updated: 2026-04-18
+---
+
+## Description
+fireworks-tech-graph 中定义的语义化形状系统——每种概念类型（LLM/Agent/存储/工具等）对应特定的 SVG 形状，确保图形在不同风格中保持一致的视觉语义。
+
+## 形状映射表
+
+| 概念类型 | SVG 形状 | 说明 |
+|---------|---------|------|
+| 用户 / 人类 | 圆形 + 身体路径 | 人形图标 |
+| LLM / 模型 | 圆角矩形，双边框，⚡ | 双边框表示智能，双闪电表示计算 |
+| Agent / 编排器 | 六边形 | 六边形表示协调/编排角色 |
+| 短期记忆 | 虚线边框圆角矩形 | 虚线表示非持久性 |
+| 长期记忆 | 实线圆柱体 | 圆柱体表示数据库/持久存储 |
+| Vector Store | 带内环圆柱 | 内环表示向量/语义检索 |
+| Graph DB | 三圆簇 | 三圆簇表示图结构关系 |
+| 工具 / 函数 | 带 ⚙ 的矩形 | 齿轮表示工具/函数 |
+| API / 网关 | 六边形（单边框） | 单边框六边形表示对外接口 |
+| 消息队列 / 流 | 横向管道 | 管道表示流式/队列 |
+| 文档 / 文件 | 折角矩形 | 折角表示文档 |
+| 浏览器 / UI | 带三点标题栏的矩形 | 浏览器 chrome |
+| 决策节点 | 菱形 | 菱形表示判断/决策 |
+| 外部服务 | 虚线边框矩形 | 虚线表示外部依赖 |
+
+## 核心价值
+确保 AI Agent 生成的技术图在不同风格、不同时间生成时保持**图形语义一致性**——看到六边形就知道是 Agent，看到带内环圆柱就知道是向量数据库，无需解释。
+
+## Relationships
+- [[语义形状词汇表]] is used_by [[fireworks-tech-graph]]
+- [[语义形状词汇表]] implements [[AI Agent]] visual representation
+- [[语义形状词汇表]] implements [[RAG]] visual representation
+- [[语义形状词汇表]] implements [[Mem0]] visual representation

wiki/concepts/语义箭头系统.md

@@ -0,0 +1,28 @@
+---
+title: "语义箭头系统"
+type: concept
+tags: []
+sources: [fireworks-tech-graph]
+last_updated: 2026-04-18
+---
+
+## Description
+fireworks-tech-graph 中定义的语义化箭头系统——通过颜色和虚线样式编码箭头的含义，使技术图的箭头本身携带语义信息，无需额外图例说明。
+
+## 箭头语义表
+
+| 流类型 | 线宽 | 虚线 | 含义 |
+|--------|------|------|------|
+| 主数据流 | 2px 实线 | — | 主要请求/响应路径 |
+| 控制 / 触发 | 1.5px 实线 | — | 系统 A 触发 B |
+| 记忆读取 | 1.5px 实线 | — | 从存储检索数据 |
+| 记忆写入 | 1.5px | `5,3` | 写入/存储操作 |
+| 异步 / 事件 | 1.5px | `4,2` | 非阻塞异步事件 |
+| 反馈 / 循环 | 1.5px 曲线 | — | 迭代推理循环 |
+
+## 核心价值
+AI Agent 生成技术图时，通过统一箭头规范确保不同人、不同时生成的图保持**箭头语义一致性**——阅读者看到虚线箭头就知道是写入操作，看到曲线就知道是反馈循环，无需查阅图例。
+
+## Relationships
+- [[语义箭头系统]] is used_by [[fireworks-tech-graph]]
+- [[语义箭头系统]] is part_of [[技术图生成]]