Auto-sync: update nexus workspace

2026-04-29 15:44:38 +08:00
parent b2aadf771a
commit c961c6a394
114 changed files with 4784 additions and 1334 deletions
--- a/wiki/concepts/AWS-Firewall-Manager.md
+++ b/wiki/concepts/AWS-Firewall-Manager.md
@@ -0,0 +1,73 @@
+---
+title: "AWS Firewall Manager"
+type: concept
+tags:
+  - AWS
+  - Security
+  - Multi-Account
+  - Firewall
+  - Compliance
+sources:
+  - ctp-topic-55-aws-firewall-manager
+last_updated: 2026-04-14
+---
+
+## Definition
+
+AWS Firewall Manager 是 AWS 提供的集中化管理服务，用于在组织级别（Organization）跨账户和跨应用程序统一配置防火墙规则和安全策略。它提供了一个合规仪表板视图，支持 WAF、Network Firewall、Shield Advanced 和安全组（Security Group）四种策略类型的统一管理。
+
+## Core Capabilities
+
+### 1. Centralized Policy Management
+- 在单一账户（Firewall Manager Admin Account）中定义策略，自动分发到目标账户或 OU
+- 支持跨多个 Landing Zone（如 RLABS、R&D、SAS、CAT）的统一纳管
+- Firewall Manager 账户独立于任何单一 Landing Zone
+
+### 2. Security Group Policy Types
+- **Common Security Group Policy**：附加基线安全组，允许产品团队在其上继续添加额外规则
+- **Audit & Enforcement Security Group Policy**：拒绝过度宽松的安全组规则，支持手动修复或自动修复
+- **Cleanup Security Group Policy**：清理未使用的冗余安全组
+
+### 3. Automatic Remediation
+- 依赖 AWS Config 作为合规评估引擎，检测不合规资源
+- 通过 AWS Lambda 触发修复事件，自动执行策略
+- 新建 EC2 实例自动附加基线安全组，删除策略自动从实例剥离安全组
+
+### 4. Cross-Account Rule Distribution
+- 通过 Prefix List 定义 CIDR 范围
+- 通过 AWS RAM（Resource Access Manager）跨账户共享 Prefix List，实现规则同步更新
+
+## Prerequisites
+- 需要在组织（Organization）级别启用 Firewall Manager
+- Firewall Manager 管理员必须在目标 OU 内拥有管理员权限
+- 所有目标账户必须启用 AWS Config
+
+## Use Cases
+- 多 Landing Zone 环境下的安全基线统一实施
+- 替代 Checkpoint Firewall 无法覆盖的公网子网流量管控
+- 集中化 WAF 规则管理，支持产品团队在基线规则上叠加自定义规则集
+
+## Architecture Pattern
+```
+Firewall Manager Admin Account
+    ├── Security Group Policy Definition
+    │       ├── Target: Account / OU
+    │       └── Baseline Security Group
+    ├── AWS Config (Compliance Engine)
+    └── AWS Lambda (Remediation Trigger)
+            ↓ (RAM: Prefix List Sharing)
+Target Accounts
+    └── EC2 Instances (Auto-attached)
+```
+
+## Related Concepts
+- [[AWS Config]]：合规评估引擎
+- [[AWS Lambda]]：自动化修复执行
+- [[Security Group Policy]]：策略类型分类
+- [[AWS-Landing-Zone]]：上层基础设施框架
+- [[Terraform]] + [[Terragrunt]]：IaC 自动化部署
+
+## Tooling
+- Terraform provider for Firewall Manager
+- Terragrunt for Landing Zone multi-account orchestration
+- Atlantis CI/CD pipeline for automated policy deployment
--- a/wiki/concepts/AWS-Instance-Scheduler.md
+++ b/wiki/concepts/AWS-Instance-Scheduler.md
@@ -0,0 +1,69 @@
+---
+title: "AWS Instance Scheduler"
+type: concept
+tags:
+  - AWS
+  - Cost-Optimization
+  - FinOps
+  - Automation
+  - EC2
+  - RDS
+sources:
+  - ctp-topic-27-aws-instance-scheduler
+  - ctp-topic-63-optimise-resource-cost-using-automation
+last_updated: 2026-05-12
+---
+
+## AWS Instance Scheduler
+
+AWS 官方提供的自动化解决方案，通过定时控制 EC2 和 RDS 实例的启动和停止状态来降低非生产环境（开发和测试）的云成本。
+
+## Core Mechanism
+
+技术架构（四层）：
+
+1. **CloudFormation**：一键部署完整解决方案栈
+2. **CloudWatch Events**：定时触发器，默认每 15 分钟触发一次 Lambda 函数
+3. **Lambda 函数**：读取调度配置并执行实例启停操作
+4. **DynamoDB Config Table**：存储调度定义（Schedules）和周期定义（Periods）
+
+## Key Features
+
+- **基于时间表触发**：按预设时间表（而非空闲率）执行启停操作
+- **多时区支持**：可配置不同办公时间（西雅图时间、英国时间等）
+- **标签化关联**：通过实例上的 `Schedule` 和 `Period` 标签关联调度逻辑
+- **RDS 维护窗口兼容**：智能配合 RDS 每 7 天强制维护窗口，维护完成后恢复调度状态
+- **Override Status**：高级配置，强制将实例保持在停止状态
+- **数据保留**：实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"
+
+## Deployment Model
+
+- **独立部署**：通过 AWS 官方 CloudFormation 模板一键部署
+- **Guardrails 集成**（Micro Focus CTP）：CCOE 通过 Guardrails 框架将 Instance Scheduler 自动推送至公司内月消费 10 美元以上的 AWS 账号，用户无需手动配置
+
+## Relationship to FinOps
+
+Instance Scheduler 是 [[FinOps（云财务管理）]] 核心技术手段"自动化调度"的具体实现方案：
+
+- **CTP Topic 13**：首次提出"实例调度器"作为 FinOps 5 大策略之一
+- **CTP Topic 27**：详解 AWS 原生 Instance Scheduler 的技术架构和运营要点
+- **CTP Topic 63**：作为自动化成本优化的 5 大策略之一再次引用
+
+## Cost Impact
+
+非 7×24 工作负载（如开发/测试环境）每天只运行 10 小时，相比 24 小时运行可节省约 **70%** 的实例成本。
+
+## Aliases
+- Instance Scheduler
+- AWS EC2 Instance Scheduler
+- AWS RDS Instance Scheduler
+
+## Related Pages
+- [[CloudWatch-Events]] — 触发机制
+- [[DynamoDB-Config-Table]] — 调度配置存储
+- [[Tagging]] — 实例关联方式
+- [[RDS-Maintenance-Window]] — RDS 兼容性
+- [[Override-Status]] — 高级覆盖配置
+- [[Godrails]] — CTP 中的自动化部署框架
+- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源
+- [[ctp-topic-63-optimise-resource-cost-using-automation]] — 技术实施参考
--- a/wiki/concepts/Assume-Role.md
+++ b/wiki/concepts/Assume-Role.md
@@ -0,0 +1,76 @@
+---
+title: "Assume Role"
+type: concept
+tags: [AWS, IAM, Security, Cross-Account, Authentication]
+sources:
+  - ctp-topic-16-cross-account-terraform-modules.md
+  - ctp-topic-5-aws-identity-and-access-management-iam.md
+last_updated: 2026-05-15
+---
+
+## Overview
+
+Assume Role 是 AWS IAM 的一种安全机制，允许一个 AWS 实体（用户、服务或角色）通过调用 `sts:AssumeRole` API 获取另一个 IAM 角色的临时安全凭证，从而在不同的安全上下文中执行操作。这是 AWS 跨账号访问的核心机制。
+
+## How It Works
+
+```python
+# 1. 源实体（如 ECS Deploy Runner）调用 STS AssumeRole
+response = sts.assume_role(
+    RoleArn="arn:aws:iam::TARGET_ACCOUNT:role/Cross-account-ECS-Deploy-Runner-Role",
+    RoleSessionName="ecs-deploy-runner-session"
+)
+
+# 2. 获取临时凭证
+temp_access_key = response['Credentials']['AccessKeyId']
+temp_secret_key = response['Credentials']['SecretAccessKey']
+temp_token = response['Credentials']['SessionToken']
+
+# 3. 使用临时凭证访问目标账号资源
+ec2_client = boto3.client('ec2', 
+    aws_access_key_id=temp_access_key,
+    aws_secret_access_key=temp_secret_key,
+    aws_session_token=temp_token
+)
+```
+
+## Key Properties
+
+- **临时凭证**：有效期通常为 1-12 小时，过期后无法使用
+- **最小权限**：仅获取所 Assume 角色的权限
+- **审计可追溯**：所有 Assume 操作都会记录在 CloudTrail 中
+- **无持久凭证泄露**：无需存储长期 Access Key
+
+## Use Cases
+
+| 场景 | 说明 |
+|------|------|
+| 跨账号部署 | Shared Account 的 EDR Assume 目标账号的角色执行 Terraform |
+| 跨账号数据访问 | 账户 A 访问账户 B 的 S3 资源 |
+| 服务间授权 | Lambda 函数 Assume 特定角色访问其他服务 |
+| 联邦访问 | 跨账户的 IAM Role 信任关系 |
+
+## Relationship with Cross-Account Terraform
+
+在 [[Cross-account-Terraform-Modules]] 方案中：
+
+```
+[[Shared-Account]] (EDR)
+    ↓ sts:AssumeRole
+[[TF-State-Bucket-Accessor]] (目标账号) → 读写 Terraform 状态文件
+    ↓
+[[Cross-account-ECS-Deploy-Runner-Role]] (目标账号) → 执行资源部署
+```
+
+## Relationships
+
+- [[Shared-Account]] ← uses ← [[Assume-Role]]
+- [[ECS-Deploy-Runner]] ← uses ← [[Assume-Role]]
+- [[Blast-Radius]] ← enables ← [[Assume-Role]]
+- [[Cross-account-Terraform-Modules]] ← mechanism ← [[Assume-Role]]
+
+## Related Concepts
+
+- [[IAM-Policy]]：Assume Role 的权限边界由 IAM Policy 定义
+- [[Blast-Radius]]：Assume Role 是控制爆炸半径的关键工具
+- [[Cross-account-Terraform-Modules]]：Assume Role 是跨账号 Terraform 方案的核心技术
--- a/wiki/concepts/Blast-Radius.md
+++ b/wiki/concepts/Blast-Radius.md
@@ -0,0 +1,73 @@
+---
+title: "Blast Radius"
+type: concept
+tags: [Security, AWS, IAM, Risk-Management, Architecture]
+sources:
+  - ctp-topic-16-cross-account-terraform-modules.md
+  - ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md
+last_updated: 2026-05-15
+---
+
+## Overview
+
+Blast Radius（爆炸半径）是一个安全概念，描述在云基础设施中某个组件（如一个 AWS 账号）被攻破或出现故障时，其影响范围的大小。**目标是最小化爆炸半径**，确保单个组件的问题不会波及其他系统。
+
+## In AWS Multi-Account Architecture
+
+在 AWS Landing Zone 多账号架构中，Blast Radius 控制是核心设计原则：
+
+### Without Blast Radius Control（高风险）
+
+```
+Workload Account A
+       ↓ 直接互信
+Workload Account B
+
+风险：Account A 被攻破 → Account B 同时沦陷
+```
+
+### With Blast Radius Control（推荐架构）
+
+```
+Workload Account A
+       ↓ (受限)
+[[Shared-Account]]
+       ↓ (受限)
+Workload Account B
+
+风险：Account A 被攻破 → 仅影响与 Shared Account 的受限连接
+      Shared Account → Account B 的连接受独立角色控制
+```
+
+## Key Mechanisms
+
+| 机制 | 说明 |
+|------|------|
+| **独立账号隔离** | 每个 Workload 独立账号，无直接互信 |
+| **最小权限角色** | [[TF-State-Bucket-Accessor]] 和 [[Cross-account-ECS-Deploy-Runner-Role]] 仅授予最小必要权限 |
+| **Assume Role 临时凭证** | 无长期凭证泄露风险 |
+| **审计追踪** | CloudTrail 记录所有跨账号操作 |
+
+## Blast Radius vs. Blast Width
+
+- **Blast Radius**：组件被攻破时的**潜在影响范围**
+- **Blast Width**：跨账号直接信任连接的**数量和密度**
+
+降低 Blast Radius 的策略：
+1. 减少账号间的直接信任关系
+2. 使用 Shared Account 作为唯一信任中介
+3. 实施最小权限原则
+4. 定期轮换 IAM 角色凭证
+
+## Relationships
+
+- [[Shared-Account]] ← enables ← [[Blast-Radius-Control]]
+- [[Cross-account-Terraform-Modules]] ← secures_via ← [[Blast-Radius]]
+- [[Assume-Role]] ← minimizes ← [[Blast-Radius]]
+- [[AWS-Landing-Zone]] ← designed_for ← [[Blast-Radius-Control]]
+
+## Related Concepts
+
+- [[IAM-Policy]]：最小权限是控制 Blast Radius 的工具
+- [[Cross-account-Terraform-Modules]]：Blast Radius 控制是该方案的核心安全价值
+- [[Assume-Role]]：临时凭证机制是控制 Blast Radius 的关键技术
--- a/wiki/concepts/CI-CD-Secrets.md
+++ b/wiki/concepts/CI-CD-Secrets.md
@@ -0,0 +1,110 @@
+---
+title: "CI/CD-Secrets"
+type: concept
+tags:
+  - CI/CD
+  - Security
+  - DevOps
+  - Cloud
+---
+
+## Definition
+
+CI/CD Secrets 是指在持续集成/持续部署（CI/CD）流水线中管理敏感信息（密码、API Key、证书、私钥等）的最佳实践。传统 CI/CD 流程中这些 secrets 通常以明文形式硬编码在配置文件、环境变量或脚本中，造成严重的安全风险。
+
+## Security Problems with Plain-Text Secrets
+
+1. **代码仓库泄露**：Secrets 可能意外提交到 Git 等版本控制系统
+2. **日志暴露**：Secrets 在构建日志中可见
+3. **网络传输**：Secrets 在流水线各阶段间传输时可能被截获
+4. **审计缺失**：无法追踪谁在何时访问了哪些凭据
+5. **轮换困难**：硬编码的 Secrets 难以定期轮换
+
+## Best Practices for CI/CD Secrets Management
+
+### 1. Centralized Secrets Management
+
+将所有 Secrets 集中存储在专用服务中：
+- AWS Secrets Manager
+- HashiCorp Vault
+- Azure Key Vault
+- GCP Secret Manager
+
+### 2. Dynamic Credentials
+
+使用动态临时凭证替代静态密钥：
+```yaml
+# ❌ 危险：静态密钥
+environment:
+  DB_PASSWORD: "static_password_123"
+
+# ✅ 推荐：动态获取
+environment:
+  DB_PASSWORD:
+    from_secret: aws:database-password
+```
+
+### 3. Pipeline Integration Pattern
+
+```
+┌─────────────┐    Request     ┌─────────────────┐
+│   CI/CD     │ ──────────────→│  Secrets        │
+│  Pipeline   │                │  Manager        │
+└─────────────┘←────────────── └─────────────────┘
+                   Dynamic Secret
+```
+
+### 4. GitOps with Secrets
+
+使用 Sealed Secrets、Vault Agent 或 cloud-native solutions 实现 Git 安全存储：
+- **Sealed Secrets**：将 secrets 加密后存储在 Git 中
+- **External Secrets Operator**：Kubernetes 原生 secrets 管理
+- **AWS Secrets Manager + SSM**：AWS 原生解决方案
+
+## AWS Implementation Example
+
+```python
+# Lambda function for secrets retrieval in CI/CD
+import boto3
+import os
+
+def get_db_credentials():
+    client = boto3.client('secretsmanager')
+    response = client.get_secret_value(
+        SecretId='prod/database/credentials'
+    )
+    return json.loads(response['SecretString'])
+```
+
+## Security Controls
+
+1. **最小权限**：CI/CD 服务账号仅授予必要的 secrets 读取权限
+2. **网络隔离**：Secrets 服务在私有网络中，不暴露给公网
+3. **审计日志**：记录所有 secrets 访问操作
+4. **自动轮换**：Secrets 定期自动轮换，无需人工干预
+5. **临时凭证**：使用 STS 临时凭证替代长期密钥
+
+## Related Concepts
+
+- [[SecretsManagement]]：敏感信息管理的整体框架
+- [[SecretRotation]]：密钥轮换机制
+- [[GitOps]]：基础设施即代码的 Git 工作流
+- [[Infrastructure-as-Code]]：基础设施即代码
+
+## Related Entities
+
+- [[AWS]]：AWS Secrets Manager 提供方
+- [[HashiCorp]]：HashiCorp Vault 提供方
+- [[ControlTower]]：AWS 多账户治理框架
+
+## Sources
+
+- [[ctp-topic-37-secrets-certificates-management]] — CI/CD secrets cleanup implementation phase
+- [[ctp-topic-62-aws-secrets-manager]] — JDBC Wrapper + CI/CD integration details
+
+## Aliases
+
+- Pipeline Secrets
+- Build Secrets
+- Deployment Credentials
+- GitOps Secrets
--- a/wiki/concepts/Canary-Deployment.md
+++ b/wiki/concepts/Canary-Deployment.md
@@ -1,56 +1,28 @@
---
-title: "Canary Deployment"
-type: concept
-tags: [DevOps, Deployment, Kubernetes, ECS, AWS]
-sources: [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
-last_updated: 2026-05-05
---
-
-# Canary Deployment
-
-## Definition
-金丝雀部署（Canary Deployment）是一种软件发布策略，通过将新版本逐步推向一小部分用户来降低风险——在新版本全面推广前，先将少量流量导向新版本，观察其行为和性能，验证无误后再逐步扩大比例。
-
-## Core Mechanism
-1. **流量分割**：将用户流量按比例分割（如 5%/10%/50%/100%）
-2. **逐步提升**：从低比例开始，逐步增加新版本流量
-3. **快速回滚**：发现问题时，立即将流量切回旧版本
-
-## Implementation in AWS
-
-### ECS (Elastic Container Service)
-ECS 模块支持金丝雀部署，通过 Target Group 权重调整实现流量控制：
- 创建新旧两个 Task Definition
- 通过 ALB/NLB 的 Target Group 逐步调整权重
- 结合 CloudWatch 监控自动决策扩缩比例
-
-### EKS (Elastic Kubernetes Service)
-Kubernetes 原生支持金丝雀部署，通过以下机制：
- `ReplicaSet` 控制新旧版本副本数
- `Service` 选择器配合金丝雀标签
- Argo Rollouts 等高级工具提供声明式金丝雀策略
-
-### AWS Tools
- **AWS CodeDeploy**：原生支持 ECS 和 Lambda 的金丝雀部署策略
- **ALB Target Groups**：权重路由实现流量分割
- **CloudWatch**：金丝雀指标监控
-
-## Comparison with Other Deployment Strategies
-
-| 策略 | 风险 | 成本 | 适用场景 |
-|------|------|------|----------|
-| **Blue-Green** | 中 | 高（双倍资源） | 快速回滚需求 |
-| **Canary** | 低 | 中 | 生产验证 |
-| **Rolling** | 中 | 低 | 资源受限环境 |
-| **A/B Testing** | 低 | 中 | 功能验证 |
-
-## Key Metrics to Monitor
- 错误率（5xx）
- 延迟（P50/P95/P99）
- 业务指标（转化率/点击率）
- 资源利用率
-
-## Related Concepts
- [[Blue-Green-Deployment]]：双环境切换策略
- [[ECS-Module-Deployment]]：ECS 场景的模块化部署
- [[Infrastructure-as-Code]]：部署自动化基础
+---
+title: "Canary Deployment"
+type: concept
+tags:
+  - Deployment
+  - ECS
+  - IaC
+sources:
+  - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi
+last_updated: 2023-08-08
+---
+
+## Definition
+Canary Deployment（金丝雀部署）是一种渐进式发布策略，通过逐步将流量从旧版本切换到新版本，降低新版本上线风险——先让少量用户（"金丝雀"）使用新版本，观察无异常后再全量发布。
+
+## How It Works
+1. **小流量引入**：新版本部署后，仅将少量流量（如 5-10%）引导至新版本实例
+2. **监控验证**：通过 CloudWatch/Grafana 等监控指标对比新旧版本表现
+3. **渐进切换**：验证通过后，逐步增加新版本流量比例（如 25% → 50% → 100%）
+4. **自动回滚**：若新版本指标异常，自动将流量切回旧版本
+
+## ECS Context
+ECS 模块内置 Canary Deployment 支持，结合 ALB（Application Load Balancer）的目标组权重规则，实现零停机渐进式发布。
+
+## Connections
+- [[ECS-Module]] ← includes ← Canary Deployment
+- [[Infrastructure-as-Code]]：Canary 部署通过 Terraform IaC 定义
+- [[Auto-Scaling]]：常与自动扩缩容配合使用
--- a/wiki/concepts/Choreography.md
+++ b/wiki/concepts/Choreography.md
@@ -0,0 +1,43 @@
+---
+title: "Choreography"
+type: concept
+tags:
+  - EDA
+  - Architecture
+  - Microservices
+last_updated: 2026-04-14
+---
+
+## Aliases
+- Choreography Pattern
+- 编舞模式
+- 去中心化事件协调
+
+## Definition
+编舞模式（Choreography）是一种微服务间通过事件进行自发协调的模式，各服务自主响应事件并发布新事件，无需中央协调器。服务通过事件总线了解全局状态和下一步操作。
+
+## Characteristics
+- **Decentralized**：无中央协调器，各服务平等
+- **Autonomous**：每个服务自主决定如何响应事件
+- **Loosely Coupled**：服务之间完全解耦，通过事件总线交互
+- **Resilient**：局部故障不影响其他服务
+- **Harder to Track**：整体业务流程不直观，调试复杂
+
+## Example
+1. 订单服务发布 `OrderCreated` 事件
+2. 库存服务订阅并发布 `InventoryReserved` 事件
+3. 支付服务订阅并发布 `PaymentProcessed` 事件
+4. 通知服务订阅并发送确认通知
+
+## Comparison with Orchestration
+| 维度 | Choreography（编舞） | Orchestration（编排） |
+|------|---------------------|---------------------|
+| 控制 | 去中心化 | 集中式 |
+| 协调器 | 无 | 有（Step Functions） |
+| 复杂度 | 局部低，整体高 | 局部高，整体低 |
+| 可观测性 | 较难追踪 | 易于追踪 |
+| 适用场景 | 简单、独立的服务 | 复杂、有明确业务流程 |
+
+## Sources
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
+- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]
--- a/wiki/concepts/CloudHealth.md
+++ b/wiki/concepts/CloudHealth.md
@@ -0,0 +1,31 @@
+---
+title: "Cloud Health"
+type: concept
+tags:
+  - AWS
+  - Cost-Optimization
+  - Monitoring
+aliases:
+  - Cloud Health
+  - CloudHealth
+  - 云计算健康
+last_updated: 2026-05-12
+---
+
+## Overview
+
+Cloud Health 是 AWS 提供的云成本分析和监控工具，帮助组织了解、优化和管理云支出。提供资源清单、成本分解、月度账单洞察和趋势分析。
+
+## Key Features
+
+- **资源清单**：全面了解云资源使用情况
+- **成本分析**：按账户、服务、标签等维度分析成本
+- **账单洞察**：月度账单详细分解和趋势追踪
+- **异常检测**：识别异常支出和浪费
+- **RightSizing 建议**：基于使用数据提供优化建议
+
+## Related Pages
+
+- [[FinOps]]
+- [[PCG Team]]
+- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
--- a/wiki/concepts/CloudWatch-Events.md
+++ b/wiki/concepts/CloudWatch-Events.md
@@ -0,0 +1,37 @@
+---
+title: "CloudWatch Events"
+type: concept
+tags:
+  - AWS
+  - Event-Driven
+  - Serverless
+  - Scheduling
+sources:
+  - ctp-topic-27-aws-instance-scheduler
+last_updated: 2026-05-12
+---
+
+## CloudWatch Events
+
+AWS 事件驱动服务（原名 Amazon EventBridge），用于构建事件驱动的架构，实现 AWS 资源变更与应用程序之间的自动化响应。
+
+## Role in AWS Instance Scheduler
+
+在 AWS Instance Scheduler 架构中，CloudWatch Events 充当**定时触发器**：
+
+- **默认触发间隔**：每 15 分钟触发一次
+- **触发目标**：Lambda 函数
+- **事件内容**：包含当前时间戳和调度评估所需的上下文信息
+- Lambda 函数读取 DynamoDB 中的调度配置，根据实例标签决定是否执行启停操作
+
+## Key Characteristics
+
+- **完全托管**：无需管理服务器或基础设施
+- **近实时**：支持分钟级定时触发
+- **规则驱动**：通过规则（Rule）定义事件模式和目标
+- **多目标支持**：可触发 Lambda、ECS 任务、SQS 队列等多种目标
+- **跨账户事件**：配合 EventBridge Bus 实现跨账户事件路由
+
+## Related Pages
+- [[AWS-Instance-Scheduler]] — 主要使用场景
+- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源
--- a/wiki/concepts/Competing-Consumer-Pattern.md
+++ b/wiki/concepts/Competing-Consumer-Pattern.md
@@ -0,0 +1,39 @@
+---
+title: "Competing Consumer Pattern"
+type: concept
+tags:
+  - EDA
+  - Architecture
+  - Messaging
+  - Cloud
+last_updated: 2026-04-14
+---
+
+## Aliases
+- Competing Consumers
+- 竞争消费者模式
+- 多消费者竞争模式
+
+## Definition
+竞争消费者模式（Competing Consumer Pattern）指多个消费者共享同一个消息队列，但每条消息只被其中一个消费者处理。确保消息处理的负载均衡和故障容错。
+
+## Implementation
+- **AWS SQS**：设置多个消费者从同一标准队列拉取消息，SQS 自动将消息分配给可用的消费者
+- 消费者之间的竞争通过 SQS 的隐式负载均衡机制实现
+
+## Key Characteristics
+- **Mutual Exclusion**：每条消息只被一个消费者处理
+- **Load Balancing**：消息自动分配给空闲的消费者
+- **Fault Tolerance**：某消费者失败，其获取的消息会重新入队供其他消费者处理
+- **Ordering Not Guaranteed**：标准 SQS 不保证消息顺序
+
+## Use Cases
+- 并行处理大量独立任务（如图片处理、文件转换）
+- 将工作负载分发到多个 Lambda 函数或 ECS 任务
+- 实现工作线程池的消息分发
+
+## Ordered Alternative
+如需保证消息顺序，使用 **SQS FIFO 队列** + **单一消费者**，或在 Kinesis 中使用分片键保证同类型消息有序处理。
+
+## Sources
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
--- a/wiki/concepts/Demand-Management.md
+++ b/wiki/concepts/Demand-Management.md
@@ -0,0 +1,51 @@
+---
+title: Demand Management
+type: concept
+tags: [ITIL, Cloud-Governance, Process]
+sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16]
+---
+
+# Demand Management
+
+**需求管理（Demand Management）** 是平衡需求与可用容量的必要手段，是 ITIL 服务过渡阶段的关键活动。
+
+## Overview
+
+需求管理在云转型过程中的核心价值：
+- 平衡业务单元需求与可用云资源容量
+- 通过标准化流程确保公平的资源分配
+- 支持端到端需求履约流程的透明化
+
+## Key Processes
+
+| 阶段 | 活动 |
+|------|------|
+| 需求提交 | 业务单元通过 Octane/Qixi 提交需求 |
+| 需求评审 | ADM/ITOM 需求规划会议评估 |
+| 需求审批 | Oli Workflow 三阶段审批 |
+| 需求履约 | SMACs 嵌入式自动化履约 |
+
+## Goals
+
+- **80% 自助服务**：业务单元能够自行识别和请求所需服务
+- **自动化履约**：机器完成机器能完成的工作
+- **透明管道**：需求处理流程全程可见
+
+## Related Concepts
+
+- [[ITIL-Service-Management]] — ITIL 框架
+- [[Oli-Workflow]] — 支出审批工作流
+- [[Product-Backlog]] — 产品待办列表
+- [[SMACs]] — 技术栈组合
+- [[FinOps]] — 云财务运营
+
+## Related Entities
+
+- [[Tom-Bice]] — FinOps 团队负责人
+- [[FPNA-Team]] — 预算验证团队
+- [[Octane]] — 需求管理平台
+- [[Qixi]] — 需求提交入口
+
+## Sources
+
+- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]]
--- a/wiki/concepts/Dependency-Dashboard.md
+++ b/wiki/concepts/Dependency-Dashboard.md
@@ -0,0 +1,32 @@
+---
+title: "Dependency Dashboard"
+type: concept
+tags:
+  - Renovatebot
+  - Dependency-Update
+  - GitOps
+last_updated: 2026-05-11
+---
+
+# Dependency Dashboard
+
+## Definition
+Renovate Bot 在 GitHub 仓库中自动创建的一个 GitHub Issue，用于汇总所有依赖状态、待处理的 Pull Request 以及更新选项，提供全局依赖状态视角。
+
+## Core Functions
+- 汇总所有检测到的依赖项及其当前版本
+- 列出所有待处理/已打开的 Pull Request
+- 提供批量合并、更新策略配置等交互选项
+- 作为单一入口，方便团队在一个界面内查看和管理所有依赖更新
+
+## Related Concepts
+- [[Renovate-Bot]] — 依赖 Dashboard 由 Renovate Bot 自动生成
+- [[Dependency-Management]] — Dashboard 是依赖管理的可视化工具
+- [[Semantic-Versioning]] — Dashboard 中显示的版本号遵循 SemVer 规范
+
+## Related Sources
+- [[ctp-topic-15-working-with-renovatebot]]
+
+## Aliases
+- Renovate Dashboard
+- Dependency Issue
--- a/wiki/concepts/DynamoDB-Config-Table.md
+++ b/wiki/concepts/DynamoDB-Config-Table.md
@@ -0,0 +1,51 @@
+---
+title: "DynamoDB Config Table"
+type: concept
+tags:
+  - AWS
+  - DynamoDB
+  - Configuration
+  - Scheduling
+sources:
+  - ctp-topic-27-aws-instance-scheduler
+last_updated: 2026-05-12
+---
+
+## DynamoDB Config Table
+
+AWS Instance Scheduler 架构中的核心数据存储组件，用于持久化调度规则和周期定义。
+
+## Schema Design
+
+DynamoDB Config Table 通常包含两张表：
+
+### Schedules 表
+- **ScheduleName**：调度名称（如 `Seattle-9-5`、`UK-9-5`）
+- **Timezone**：时区配置
+- **Description**：调度描述
+
+### Periods 表
+- **PeriodName**：周期名称
+- **BeginTime**：开始时间
+- **EndTime**：结束时间
+- **Weekdays**：适用工作日（周一至周五）
+- **InstanceType**：应用实例类型（EC2/RDS）
+
+## Role in AWS Instance Scheduler
+
+DynamoDB Config Table 是 Instance Scheduler 的**逻辑核心**：
+
+1. Lambda 函数通过 DynamoDB SDK 读取 Schedules 和 Periods 定义
+2. 根据当前时间和实例标签（`Schedule`、`Period`）匹配适用的调度规则
+3. 返回匹配结果后决定执行启动或停止操作
+
+## Key Advantages
+
+- **无服务器**：无需管理任何基础设施，按需扩展
+- **低延迟**：毫秒级读取性能，满足高频调度查询
+- **高可用**：多可用区自动复制，无单点故障
+- **成本效益**：按请求计费，零管理工作负载
+
+## Related Pages
+- [[AWS-Instance-Scheduler]] — 主要使用场景
+- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源
--- a/wiki/concepts/ECS-Deploy-Runner.md
+++ b/wiki/concepts/ECS-Deploy-Runner.md
@@ -0,0 +1,43 @@
+---
+title: "ECS Deploy Runner"
+type: concept
+tags: [Terraform, ECS, Deployment, IaC, Docker, CI/CD]
+sources:
+  - ctp-topic-16-cross-account-terraform-modules.md
+last_updated: 2026-05-15
+---
+
+## Overview
+
+ECS Deploy Runner（EDR）是运行在 AWS ECS 上的 Docker 容器，负责在跨账号 Terraform 部署流水线中执行 `terraform plan` 和 `terraform apply` 命令。它是流水线的实际执行单元。
+
+## How It Works
+
+1. **触发**：Jenkins（托管在 [[Shared-Account]]）检测到模块目录中的 `cross-account.json` 标记文件
+2. **启动**：ECS Deploy Runner 在 Shared Account 的 ECS 集群中启动
+3. **Assume Role**：通过 Assume Role 获取两个目标账号 IAM 角色的临时凭证：
+   - `[[TF-State-Bucket-Accessor]]`：读取目标账号的 Terraform 状态文件
+   - `[[Cross-account-ECS-Deploy-Runner-Role]]`：在目标账号中执行资源部署
+4. **执行**：运行 Terraform CLI 命令完成部署
+
+## Key Characteristics
+
+- **容器化**：运行在 Docker 容器中，环境一致性好
+- **按需启动**：每次部署触发一次容器启动，无长期占用
+- **临时凭证**：通过 Assume Role 获取的短期凭证，最小化密钥暴露时间
+- **与 Terragrunt 配合**：Terragrunt HCL 文件配置角色切换逻辑
+
+## Local vs CI/CD Difference
+
+| 环境 | 角色处理 |
+|------|---------|
+| 本地开发 | Terragrunt 自动处理角色切换，无需手动 Assume Role |
+| Jenkins CI/CD | EDR 通过 Assume Role 获取两个专用角色的临时凭证 |
+
+## Relationships
+
+- [[CI/CD Pipeline]]：EDR 是 CI/CD 流水线的执行层
+- [[Cross-account-Terraform-Modules]]：EDR 是跨账号 Terraform 模块方案的核心执行组件
+- [[Shared-Account]]：EDR 运行在 Shared Account 的 ECS 集群中
+- [[Assume-Role]]：EDR 通过 Assume Role 获取跨账号权限
+- [[Docker-Containerization]]：EDR 以 Docker 容器形式运行
--- a/wiki/concepts/ECS-Module.md
+++ b/wiki/concepts/ECS-Module.md
@@ -0,0 +1,39 @@
+---
+title: "ECS Module"
+type: concept
+tags:
+  - ECS
+  - Terraform
+  - IaC
+  - Modules
+sources:
+  - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi
+last_updated: 2023-08-08
+---
+
+## Definition
+ECS Module 是 CTP/SRE 团队基于 Gruntwork 仓库构建的 Terraform 模块，用于在 AWS 上自动化部署和管理 ECS（Elastic Container Service）容器化应用。
+
+## Core Features
+- **Docker 容器化**：将应用封装为 Docker 容器作为逻辑部署单元
+- **多部署模式**：支持 EC2 实例部署
+- **自动扩缩容（Auto-Scaling）**：根据负载动态调整容器实例数量
+- **自动故障恢复（Auto-Healing）**：自动重启失败的容器任务
+- **金丝雀部署（Canary Deployment）**：支持渐进式流量切换
+- **集中管理**：通过 Listener 方式统一管理各产品团队的 ECS 部署
+
+## Architecture
+- 基于 Gruntwork terraform-aws-ecs 模块
+- 使用 VPC、ELB 安全组、EFS 卷作为前置条件
+- 支持 YAML/JSON 配置传递
+- 集成 CloudWatch、Splunk、Grafana、Prometheus 监控
+
+## Listener Approach（集中管理）
+避免各产品团队直接下载 Gruntwork 模板并本地使用导致的碎片化问题，改为统一通过 Listener 机制集中管理和更新 ECS 配置。
+
+## Connections
+- [[Gruntwork]] ← based_on ← ECS Module（技术基础来源）
+- [[ECS]] ← manages ← ECS Module（AWS ECS 服务层面）
+- [[Canary-Deployment]] ← included_in ← ECS Module
+- [[Cloud-Transformation-Programme]] ← implements ← ECS Module（CTP 核心产出）
+- [[Terraform]] ← tool ← ECS Module（模块实现工具）
--- a/wiki/concepts/ECS.md
+++ b/wiki/concepts/ECS.md
@@ -9,8 +9,10 @@ tags:
 aliases:
  - ECS
  - Elastic Container Service
-  - Amazon ECS
-last_updated: 2026-05-12
+sources:
+  - learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording
+  - ctp-topic-48-terraform-vs-terragrunt.md
+last_updated: 2026-05-13
 ---

 ## Overview
--- a/wiki/concepts/Event-Driven-Architecture.md
+++ b/wiki/concepts/Event-Driven-Architecture.md
@@ -1,108 +1,49 @@
---
-title: "Event-Driven Architecture"
-type: concept
-tags:
-  - Architecture
-  - Event-Driven
-  - Serverless
-  - AWS
-sources:
-  - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
-  - public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091
-  - public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091
-last_updated: 2026-05-05
---
-
-## Definition
-
-Event-Driven Architecture（事件驱动架构）是一种软件设计范式，在该模式下，系统组件通过产生和消费事件（Event）进行异步通信，而非通过直接的函数调用或请求-响应模式。事件是系统中发生的重要动作或状态变化的声明式通知，事件消费者无需知道事件产生者的存在。
-
-## Core Principles
-
-| 原则 | 描述 |
-|------|------|
-| 异步通信 | 生产者和消费者解耦，无需同步等待响应 |
-| 事件声明 | 事件代表"发生了什么"，而非"该做什么" |
-| 松耦合 | 生产者和消费者之间无直接依赖 |
-| 可扩展 | 新增消费者无需修改生产者代码 |
-
-## Event Anatomy
-
-典型事件包含：
-
-```json
-{
-  "event_id": "uuid",
-  "event_type": "ORDER_CREATED",
-  "source": "order-service",
-  "timestamp": "2026-04-14T10:00:00Z",
-  "data": { /* 业务相关数据 */ }
-}
-```
-
-## AWS Event-Driven Stack
-
-| 组件 | 角色 | 说明 |
-|------|------|------|
-| [[Amazon-EventBridge]] | 事件总线 | 接收、过滤、路由事件到目标 |
-| [[AWS-Lambda]] | 事件消费者 | 响应事件执行处理逻辑 |
-| [[Amazon-SNS]] | 事件发布/订阅 | 一对多广播消息 |
-| [[Amazon-SQS]] | 事件队列 | 可靠的事件持久化和顺序处理 |
-| [[Amazon-DynamoDB]] | 事件源 | DynamoDB Streams 触发 Lambda |
-| [[Amazon-S3]] | 事件源 | S3 事件通知触发 Lambda |
-
-## Serverless 中的事件驱动
-
-[[AWS-Lambda]] 是事件驱动架构的核心执行单元：
-
- **事件即触发器**：Lambda 函数不主动运行，由事件触发
- **事件源映射**：Lambda 轮询 Kinesis、DynamoDB Stream、SQS 获取事件
- **状态变化即事件**：S3 对象上传、API Gateway 请求、DynamoDB 写入等均为事件
-
-## Event Patterns
-## EDA 三组件与事件代理类型
-
-| 组件 | 角色 | 说明 |
-|------|------|------|
-| 事件生产者（Producer） | 产生事件 | 服务检测到状态变化时发布事件 |
-| 事件消费者（Consumer） | 消费事件 | 订阅并处理事件，执行对应业务逻辑 |
-| 事件代理（Broker） | 路由/存储 | 分事件路由器和事件存储两类 |
-
-**事件路由器（Event Routers）**——按规则过滤事件并路由到正确消费者：
- [[Amazon-EventBridge]]：更丰富，支持 Schema 注册、跨服务触发
- [[Amazon-SNS]]：一对多广播（Fan-out）
-
-**事件存储（Event Stores）**——流式持久化事件，消费者自行过滤：
- [[Amazon-SQS]]：标准队列（乱序/高性能）/ FIFO 队列（有序/Exactly-Once）
- [[Kinesis-Data-Streams]]：有序事件流，支持重放
-
-## 编排模式：Choreography vs Orchestration
-
-| 模式 | 特点 | 适用场景 |
-|------|------|---------|
-| Choreography（编排） | 各微服务自主通信，无中央协调者 | 简单、独立的跨服务交互 |
-| Orchestration（编排） | 中央协调者（如 [[AWS-Step-Functions]]）控制工作流步骤 | 复杂业务流程、需要事务保障 |
-
-## 生产级最佳实践
-
-1. **幂等性（Idempotency）**：同一操作执行一次或多次产生相同结果。[[AWS-Lambda]] 异步调用会自动重试，因此幂等性是处理重复消息的关键——尤其适用于订单、支付等场景。
-
-2. **事件排序**：
-   - **有序**：SQS FIFO 或 Kinesis Data Streams
-   - **乱序可接受**：标准 SQS 或 EventBridge（消费者自行处理乱序）
-
-3. **团队独立性**：采用去中心化所有权，平台团队提供基础设防（Cloud CoE），消费者团队自主按需消费事件。
-
-## Event Patterns
-1. **Pub/Sub**：SNS 主题广播，多消费者订阅同一事件类型
-2. **Event Streaming**：Kinesis/DynamoDB Stream 持久化事件流，支持重放
-3. **Fan-Out**：SNS 主题或 EventBridge 规则将事件分发到多个消费者
-4. **Competing Consumer**：同一消息同一时间只有一个消费者处理（SQS）
-5. **Dead-Letter Queue（DLQ）**：处理失败事件，防止消息丢失
-6. **Saga Pattern**：通过事件序列协调分布式事务
-7. **Event Sourcing**：完整记录所有状态变化事件作为唯一真相来源
-
-## Connections
- [[Event-Driven-Architecture]] ← is_execution_model_of ← [[Serverless-Computing]]
- [[Event-Driven-Architecture]] ← uses ← [[Amazon-EventBridge]]
- [[Event-Driven-Architecture]] ← executed_by ← [[AWS-Lambda]]
+---
+title: "Event-Driven Architecture"
+type: concept
+tags:
+  - EDA
+  - Architecture
+  - Cloud
+  - Microservices
+last_updated: 2026-04-14
+---
+
+## Aliases
+- EDA
+- Event Driven Architecture
+- 事件驱动架构
+
+## Definition
+事件驱动架构（EDA）是一种软件架构范式，通过在松耦合的生产者（Producer）和消费者（Consumer）之间传递事件（Event）来实现系统解耦。事件是状态变化或更新的通知，触发异步处理和响应。
+
+## Core Components
+- **Event Producer**：事件的产生者，感知状态变化并发布事件
+- **Event Consumer**：事件的订阅者和处理者，响应事件执行相应逻辑
+- **Event Broker**：事件的中介路由器，负责分发和传递事件
+
+## Event Broker Types
+- **Event Router**（事件路由器）：过滤并路由事件到正确的消费者（SNS / EventBridge）
+- **Event Store**（事件存储）：流式存储事件，消费者自行过滤所需事件（SQS / Kinesis）
+
+## Key Design Principles
+- **Decoupling**：生产者和消费者完全解耦，独立演进
+- **Scalability**：各组件可独立扩展
+- **Resilience**：局部故障不影响整体系统
+- **Idempotency**：幂等性保证异步重试不产生副作用
+
+## Best Practices
+- 稀疏事件（sparse events）适合频繁变化的数据，但消费者可能需要额外查询详情
+- 完整状态事件（full state）包含更多细节，但受 EventBridge 负载大小限制
+- 事件排序需使用 SQS FIFO 或 Kinesis Data Streams
+- EventBridge 最佳实践：每个订阅者使用单一规则、避免为自定义事件使用默认事件总线、使用死信队列处理失败事件
+
+## Related Messaging Patterns
+- [[Fan-Out-Pattern]]：扇出模式
+- [[Competing-Consumer-Pattern]]：竞争消费者模式
+- [[Choreography]]：编舞模式
+- [[Orchestration]]：编排模式
+
+## Sources
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
--- a/wiki/concepts/Fan-Out-Pattern.md
+++ b/wiki/concepts/Fan-Out-Pattern.md
@@ -0,0 +1,34 @@
+---
+title: "Fan-Out Pattern"
+type: concept
+tags:
+  - EDA
+  - Architecture
+  - Messaging
+  - Cloud
+last_updated: 2026-04-14
+---
+
+## Aliases
+- Fan-out
+- 扇出模式
+
+## Definition
+扇出模式（Fan-Out Pattern）指将一个事件同时分发给多个消费者（订阅者）的模式。在事件驱动架构中，生产者发布一条消息，通过事件代理自动分发给所有感兴趣的消费者。
+
+## Implementation
+- **SNS Topic**：发布到 SNS Topic，多个 SQS 队列或 Lambda 函数订阅同一主题
+- **EventBridge Rules**：基于规则路由，将事件分发给不同的目标服务
+
+## Use Cases
+- 同一订单事件触发库存服务、支付服务、通知服务
+- 日志事件同时发送到 CloudWatch Logs、S3 和第三方监控系统
+- 数据同步：同一数据变更同步到多个下游系统
+
+## Best Practices
+- SNS Topic 订阅多个 SQS 队列实现可靠的消息传递
+- EventBridge 每个订阅者使用单一规则，便于维护和调试
+- 消费者独立扩展，不影响其他消费者
+
+## Sources
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
--- a/wiki/concepts/FinOps.md
+++ b/wiki/concepts/FinOps.md
@@ -1,111 +1,40 @@
---
-title: "FinOps"
-type: concept
-sources: [cloud-operating-model-key-strategies-and-best-practices]
---
-
-# FinOps
-
-> **FinOps** — Cloud Financial Management，云财务管理，是一种将财务责任、跨团队协作和业务价值最大化相结合的云成本管理实践。
-
-## Definition
-
-FinOps（Financial Operations）是云时代的一种运营框架：
-
- **可见性** — 了解云支出去向
- **优化** — 持续减少浪费
- **业务价值** — 最大化云投资回报
-
-## FinOps Core Principles
-
-| 原则 | 描述 |
-|------|------|
-| **云是一个 marketplaces** | 实时价格，竞争驱动 |
-| **财务责任人人有责** | 集中团队无法独自优化 |
-| **按需 vs 承诺** | 两者混合以平衡灵活性和成本 |
-| **持续优化** | 定期评估和调整 |
-| **业务价值驱动** | 成本透明支撑业务决策 |
-
-## FinOps Maturity Model
-
-| Level | 描述 | 特征 |
-|-------|------|------|
-| **Crawl** | 可见性 | 建立标签、成本分配、基础监控 |
-| **Walk** | 优化 | .right-sizing、预留购买、自动化 |
-| **Run** | 自动化 | 实时优化、自动策略执行 |
-
-## Key Practices
-
-### 1. Chargeback / Showback
-
-| 模型 | 描述 | 适用场景 |
-|------|------|---------|
-| **Showback** | 向部门展示成本 | 培养成本意识 |
-| **Chargeback** | 部门承担实际成本 | 强化责任 |
-
-### 2. Resource Tagging
-
-**必需标签**
-| 标签 | 示例 | 用途 |
-|------|------|------|
-| `Environment` | prod, staging | 环境隔离 |
-| `Owner` | alice@example.com | 责任追踪 |
-| `CostCenter` | CC-12345 | 财务归因 |
-| `Application` | billing-api | 应用关联 |
-
-### 3. Cost Optimization
-
-**技术**
- .Right-sizing（资源优化）
- Reserved Instances / Savings Plans
- Spot/Preemptible 实例
- 生命周期策略（存储）
- 闲置资源清理
-
-**流程**
- 定期成本审视（Weekly/Monthly）
- 预算告警
- 成本异常检测
- 优化建议 Review
-
-### 4. Unit Economics
-
-| 指标 | 公式 | 目标 |
-|------|------|------|
-| **Cost per Transaction** | 总成本 / 交易数 | 持续降低 |
-| **Cost per User** | 总成本 / 用户数 | 持续降低 |
-| **Cost per Revenue** | 总成本 / 收入 | 稳定或降低 |
-
-## Tools
-
-| 类别 | 工具 |
-|------|------|
-| **原生** | AWS Cost Explorer, Azure Cost Management, GCP Billing |
-| **第三方** | Spot.io, CloudHealth, Densify, Kubecost |
-| **BI/可视化** | Tableau, Looker, Power BI |
-
-## FinOps Team Roles
-
-| 角色 | 职责 |
-|------|------|
-| **FinOps Practitioner** | 日常成本监控和分析 |
-| **FinOps Lead** | 策略制定、跨团队协调 |
-| **Cloud Economist** | 云经济学、成本建模 |
-| **Business Partner** | 业务部门对接 |
-
-## Integration with Other Practices
-
-| 实践 | 关系 |
-|------|------|
-| **DevOps** | FinOps-aware 开发 |
-| **SRE** | 可靠性与成本平衡（SLO vs 成本） |
-| **Cloud Governance** | 成本策略是治理一部分 |
-| **Cloud Security** | 安全成本量化 |
-
-## See Also
-
- [[Cloud Cost Optimization]] — 云成本优化
- [[Cloud Governance]] — 云治理
- [[Cloud Adoption Strategy]] — 云采用策略
- [[Multi-Cloud Strategy]] — 多云策略
- [[DORA Metrics]] — DORA 指标
+---
+title: "FinOps (Cloud Financial Management)"
+type: concept
+tags:
+  - AWS
+  - FinOps
+  - Cost-Optimization
+aliases:
+  - FinOps
+  - 云财务管理
+last_updated: 2026-05-12
+---
+
+## Overview
+
+FinOps（云财务管理）是一种云资源管理学科，通过可见性、优化和治理实现云投资最大化价值。核心目标是在云环境中建立成本意识文化，实现工程速度与财务问责制的平衡。
+
+## Core Principles
+
+- **可见性**：确保所有云支出的可见性，按责任单元拆分
+- **优化**：持续优化资源使用，降低单位成本
+- **治理**：建立策略和控制，确保支出在预算内
+
+## Key Practices
+
+- **Showback/Chargeback**：成本分摊机制，Showback 展示成本数据，Chargeback 强制成本归属
+- **Reserved Instances / Savings Plans**：承诺计划用于长期工作负载成本优化
+- **RightSizing**：根据实际使用情况调整实例规格
+- **Spot Instances**：可中断工作负载使用竞价实例降低 60-90% 成本
+- **Graviton ARM 实例**：相比 Intel x86 实例成本更低、能耗更低
+
+## Related Pages
+
+- [[PCG Team]]
+- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
+- [[ctp-topic-63-optimise-resource-cost-using-automation]]
+- [[SpotInstances]]
+- [[ReservedInstances]]
+- [[SavingsPlans]]
+- [[Graviton]]
--- a/wiki/concepts/Fine-Tuning.md
+++ b/wiki/concepts/Fine-Tuning.md
@@ -0,0 +1,40 @@
+---
+title: "Fine-Tuning"
+type: concept
+tags: [AI, ML, fine-tuning, foundation-model, customization]
+sources: [public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]
+last_updated: 2026-05-12
+---
+
+## Aliases
+- Fine-tuning
+- Model Fine-tuning
+- 模型的微调
+
+## Definition
+Fine-Tuning（微调）是在预训练基础模型之上，使用特定领域或任务的数据进一步训练模型，使其适应特定业务场景。与 RAG 不同，微调直接修改模型权重，而非在推理时注入外部知识。
+
+## Key Facts
+- 属于三大数据整合方法之一（RAG / Fine-tuning / Continued Pre-training）
+- 与 RAG 的核心区别：RAG 保留原始模型权重，通过检索增强回答；Fine-tuning 修改模型权重，改变模型本身
+- 适用场景：特定领域术语、风格、任务类型的深度适配
+- 成本：需要额外的训练资源和时间
+- AWS Amazon Bedrock 支持 Fine-tuning 基础模型
+
+## Comparison with RAG
+
+| 维度 | Fine-Tuning | RAG |
+|------|-------------|-----|
+| 修改模型权重 | 是 | 否 |
+| 推理延迟 | 无额外延迟 | 有检索开销 |
+| 外部知识库 | 不依赖 | 依赖 |
+| 适用场景 | 风格/任务适配 | 知识密集型问答 |
+| 成本 | 训练成本高 | 索引/检索成本 |
+
+## Related Concepts
+- [[Foundation-Models]]：微调作用于基础模型
+- [[RAG]]：另一种数据整合方法，与微调互补
+- [[Amazon-Bedrock]]：提供 Fine-tuning 能力
+
+## Sources
+- [[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]]
--- a/wiki/concepts/Foundation-Models.md
+++ b/wiki/concepts/Foundation-Models.md
@@ -0,0 +1,33 @@
+---
+title: "Foundation Models"
+type: concept
+tags: [AI, ML, foundation-model, generative-AI, LLM]
+sources:
+  - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin
+  - public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec
+last_updated: 2026-05-12
+---
+
+## Definition
+Foundation Models（基础模型）是拥有数十亿参数的大规模预训练模型，是生成式 AI 的核心驱动力。Amazon 认为大多数客户体验和应用将被生成式 AI 重塑，而生成式 AI 的力量来自于基础模型。
+
+## Key Properties
+- **规模**: 数十亿参数（billions of parameters）
+- **预训练**: 在大规模通用数据上预训练
+- **可定制**: 支持微调（Fine-tuning）、持续预训练、RAG 等数据定制技术
+- **多模态**: 可处理文本、图像、代码等多种模态
+
+## Related Concepts
+- [[Generative-AI]]：基础模型是生成式 AI 的核心技术
+- [[RAG]]：检索增强生成，用于在基础模型上整合私有数据
+- [[Amazon-Bedrock]]：提供基础模型访问的全托管服务
+- [[Amazon-Titan]]：Amazon 开发的基础模型系列
+
+## Examples
+- Amazon Titan（Amazon Bedrock 内置）
+- Anthropic Claude
+- Meta Llama
+- OpenAI GPT 系列
+
+## Sources
+- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]
--- a/wiki/concepts/GitOps.md
+++ b/wiki/concepts/GitOps.md
@@ -1,44 +1,79 @@
---
-title: "GitOps"
-type: concept
-tags:
-  - DevOps
-  - CI/CD
-  - Kubernetes
-  - Infrastructure as Code
---
-
-## Definition
-GitOps 是一种将软件开发的版本控制与协作原则应用于云原生基础设施和应用部署的方法论。核心思想：**使用 Git 作为单一事实来源（Single Source of Truth）声明系统的期望状态，由自动化代理（GitOps Controller）持续协调实际状态向期望状态收敛。**
-
-## Four Principles
-1. **声明式配置（Declarative Configuration）**：所有基础设施和应用配置必须以声明式代码描述，而非命令式脚本
-2. **版本控制（Version Control）**：所有配置存储在 Git 仓库中，享受完整的变更历史、代码审查和回滚能力
-3. **CD 流程分离（CD Process Separation）**：CI 专注构建和分析代码，CD 专注部署，两者解耦增强安全性
-4. **自修复协调器（Automated Reconciliation）**：GitOps Controller 持续监控实际状态与 Git 声明状态，自动调和偏差
-
-## Key Benefits
- 开发者只需掌握 Git 即可完成安全部署
- 分钟级代码变更上线
- 零停机回滚（Git 历史即回滚计划）
- Git 提交日志天然构成合规审计追踪
- 提高开发者生产力（使用熟悉的工具）
-
-## Pull Model vs Push Model
-
-| | Pull Model（推荐） | Push Model |
-|---|---|---|
-| 机制 | 部署代理主动监控 Git 和目标系统 | CI/CD 管道主动推送变更到目标 |
-| 安全性 | 更高——系统状态不暴露给外部 | 较低——需外部访问目标系统 |
-| 代表工具 | ArgoCD, Flux | Jenkins CI/CD, Terraform Cloud |
-| 适用场景 | GitOps 核心模式 | 传统 CI/CD 扩展 |
-
-## Relationship with IaC
-GitOps 是 [[Infrastructure as Code]] 的部署编排层：
- **IaC**：定义"基础设施应该是什么样的"（Terraform/Pulumi/HCL）
- **GitOps**：定义"如何确保基础设施始终符合声明"（ArgoCD/Flux/Atlantis）
-
-## Sources
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 方法论入门，Victor Etkin 主讲
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] — Atlantis 作为 GitOps 工具实践
- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 与 GitOps 的关联
+---
+title: "GitOps"
+type: concept
+tags:
+  - GitOps
+  - IaC
+  - DevOps
+  - CD
+sources:
+  - ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments
+  - ctp-topic-33-an-introduction-to-gitops
+  - ctp-topic-9-ci-cd-with-gruntwork
+last_updated: 2026-04-29
+---
+
+# GitOps
+
+## Definition
+
+GitOps 是将软件开发原则（尤其是 Git 版本控制）应用于基础设施和应用程序部署的方法论。其核心思想是：**将 Git 仓库作为声明式配置的单一事实来源（Single Source of Truth），通过自动化机制确保实际环境与 Git 中声明的期望状态保持一致。**
+
+## Core Principles
+
+1. **Declarative Configuration（声明式配置）**
+   所有基础设施和应用配置以声明式语言（如 Terraform HCL、Kubernetes YAML）描述，而非命令式步骤。
+
+2. **Version Control（版本控制）**
+   所有配置存储在 Git 仓库中，享受版本历史、代码审查（Pull Request）和回滚能力。
+
+3. **Automated CD（自动化持续交付）**
+   CI 专注代码构建和分析，CD 专注部署；两者解耦，增强安全性和可靠性。
+
+4. **Self-Healing（自修复协调）**
+   GitOps Controller 持续监控实际状态与 Git 声明状态，自动调和偏差（drift correction）。
+
+## Architecture Patterns
+
+### Pull Model（推荐）
+- GitOps Agent（如 ArgoCD、Flux）同时监控 Git 仓库和目标系统
+- Agent 通过 Pull 方式主动检测变更，无需外部系统推送
+- 安全性更高，符合零信任原则
+
+### Push Model
+- CI/CD 流水线（如 Jenkins、GitHub Actions）在代码变更后主动推送到目标环境
+- 配置相对简单，但安全性较低
+
+## Tooling Ecosystem
+
+| Tool | Role | Model |
+|------|------|-------|
+| [[Atlantis]] | Terraform 自动化 Plan/Apply | Pull（PR-based）|
+| ArgoCD | Kubernetes 应用部署 | Pull |
+| Flux | Kubernetes 持续交付 | Pull |
+| Terraform Cloud/Enterprise | Terraform 协作与状态管理 | Hybrid |
+
+## GitOps vs Traditional CI/CD
+
+| Dimension | Traditional CI/CD | GitOps |
+|-----------|------------------|--------|
+| Source of Truth | Pipeline definition | Git repository |
+| Trigger | Push to repo | Automated pull + diff detection |
+| State Drift Detection | Manual or periodic | Continuous automatic |
+| Rollback | Manual or scripted | Git revert + auto-sync |
+| Audit Trail | Build logs | Git commit history |
+| Security Model | Token-based push | Agent has minimal permissions |
+
+## Related Concepts
+- [[Infrastructure as Code (IaC)]]：GitOps 的核心技术基础
+- [[CI/CD Pipeline]]：GitOps 的前身和组成部分
+- [[Terraform]]：主流 IaC 工具，Atlantis 是其 GitOps 工具
+
+## Related Entities
+- [[Atlantis]]：Terraform GitOps 的核心工具实现
+- [[Jenkins]]：传统 CI/CD 模式（非 GitOps 原生）
+
+## Related Sources
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] — Atlantis 工具实践层
+- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 概念层（Victor Etkin 讲解）
+- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 实践
--- a/wiki/concepts/ITIL-Service-Management.md
+++ b/wiki/concepts/ITIL-Service-Management.md
@@ -0,0 +1,49 @@
+---
+title: ITIL Service Management
+type: concept
+tags: [ITIL, Framework, Process]
+sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16]
+---
+
+# ITIL Service Management
+
+**ITIL（Information Technology Infrastructure Library）服务管理框架** 将业务流程分为五个阶段，是企业 IT 服务管理的国际标准方法论。
+
+## Five Stages
+
+| 阶段 | 描述 |
+|------|------|
+| **Service Strategy（服务战略）** | 定义服务如何为客户创造价值 |
+| **Service Design（服务设计）** | 设计新服务或变更服务 |
+| **Service Transition（服务过渡）** | 构建和部署服务，需求管理对应此阶段 |
+| **Service Operation（服务运营）** | 日常运维和支持 |
+| **Continual Service Improvement（持续服务改进）** | 优化服务质量和效率 |
+
+## Application in Cloud Transformation
+
+在 OpenText 云转型过程中：
+- **Oli Workflow** 对应请求履约的第一阶段（服务过渡阶段）
+- **Demand Management** 是服务过渡阶段的关键活动
+- **Product Backlog** 支持持续服务改进
+
+## Core Principles
+
+1. **以服务为导向**：一切活动都围绕服务交付
+2. **持续改进**：PDCA 循环不断优化
+3. **端到端治理**：覆盖服务全生命周期
+
+## Related Concepts
+
+- [[Demand-Management]] — 需求管理
+- [[Oli-Workflow]] — 审批工作流
+- [[SMACs]] — 技术栈组合
+- [[FinOps]] — 云财务运营
+
+## Related Entities
+
+- [[MUI]] — 审批人
+- [[Shannon]] — 审批人
+
+## Sources
+
+- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]]
--- a/wiki/concepts/Idempotency.md
+++ b/wiki/concepts/Idempotency.md
@@ -0,0 +1,29 @@
+---
+title: "Idempotency"
+type: concept
+tags:
+  - Architecture
+  - Reliability
+  - Cloud
+last_updated: 2026-04-14
+---
+
+## Definition
+幂等性（Idempotency）是指一个操作被执行一次和被执行多次，产生的结果是相同的。在分布式系统和事件驱动架构中，这是确保系统可靠性的关键设计原则。
+
+## Why It Matters in EDA
+Lambda 异步调用会自动重试（通常重试 2-3 次），因此服务在处理事件时必须考虑幂等性，避免因重复处理导致的数据不一致或副作用（如重复下单、重复扣款）。
+
+## Implementation Strategies
+- 为每个事件分配唯一标识符（Event ID），消费者维护已处理事件记录
+- 使用数据库唯一约束或乐观锁防止重复写入
+- 基于业务语义的去重（如订单号唯一性检查）
+
+## Applicable Scenarios
+- 订单处理和支付
+- 库存扣减
+- 消息确认
+- 状态更新
+
+## Sources
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
--- a/wiki/concepts/InfrastructureAsCode.md
+++ b/wiki/concepts/InfrastructureAsCode.md
@@ -0,0 +1,33 @@
+---
+title: "Infrastructure as Code"
+type: concept
+tags:
+  - IaC
+  - DevOps
+  - Cloud
+sources:
+  - ctp-topic-48-terraform-vs-terragrunt.md
+- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]]
+last_updated: 2026-05-15
+---
+
+## Definition
+Infrastructure as Code（IaC）是通过代码定义和管理基础设施的实践，实现基础设施的版本控制、自动化部署和一致性管理，而非手动配置。
+
+## Key Characteristics
+- **声明式配置**：定义期望的最终状态，而非步骤
+- **版本控制**：所有基础设施定义纳入 Git 管理
+- **幂等性**：重复执行产生相同结果
+- **自动化**：与 CI/CD 流程深度集成
+
+## Core Tools
+- [[Terraform]] — 云无关的 IaC 工具
+- [[Terragrunt]] — Terraform 的 DRY 包装器
+- AWS CloudFormation — AWS 原生 IaC
+- Pulumi — 编程语言驱动的 IaC
+- Ansible — 配置管理工具
+
+## Connections
+- [[Terraform]] ← implements ← [[InfrastructureAsCode]]
+- [[Terragrunt]] ← extends ← [[Terraform]]（多环境管理）
+- [[Atlantis]] ← enables ← [[GitOps]]（PR 驱动的 IaC 部署）
--- a/wiki/concepts/JDBCWrapper.md
+++ b/wiki/concepts/JDBCWrapper.md
@@ -0,0 +1,92 @@
+---
+title: "JDBCWrapper"
+type: concept
+tags:
+  - AWS
+  - Java
+  - Database
+  - Security
+  - SDK
+---
+
+## Definition
+
+JDBC Wrapper（JDBC 包装器）是一种通过包装 JDBC 连接，配合 AWS SDK 从 AWS Secrets Manager 动态获取数据库凭据的编程模式，使应用程序无需硬编码数据库密码即可连接数据库。
+
+## Problem Statement
+
+传统数据库连接方式：
+```
+应用程序 → 配置文件/环境变量 → 数据库
+                     ↑
+            硬编码明文密码（安全风险）
+```
+
+**问题**：
+- 密码在代码、配置文件或环境变量中明文存储
+- 密码变更需要修改配置并重启应用
+- 无法实现细粒度的访问控制
+- 密码泄露风险高
+
+## Solution: JDBC Wrapper Pattern
+
+使用 JDBC Wrapper 的连接方式：
+```
+应用程序 → JDBC Wrapper + AWS SDK → AWS Secrets Manager → 数据库
+```
+
+**工作流程**：
+1. 应用程序通过 JDBC Wrapper 建立连接
+2. JDBC Wrapper 调用 AWS SDK 向 Secrets Manager 请求凭据
+3. Secrets Manager 返回动态获取的数据库密码
+4. JDBC Wrapper 使用临时凭据建立数据库连接
+5. 连接完成后，凭据不在应用内存中长期保留
+
+## Key Benefits
+
+| 优势 | 说明 |
+|------|------|
+| **无密码访问** | 用户无需知道数据库密码，通过 IAM 角色授权 |
+| **动态轮换** | 数据库密码轮换时，应用无需重启 |
+| **集中审计** | 所有数据库访问通过 Secrets Manager 记录 |
+| **最小权限** | 基于 IAM 角色控制数据库访问权限 |
+| **审计追溯** | 用户名由角色控制，可追溯数据库操作 |
+
+## Implementation Architecture
+
+```
+┌─────────────┐     ┌──────────────┐     ┌─────────────────┐     ┌──────────────┐
+│ Application │────▶│ JDBC Wrapper │────▶│ AWS SDK         │────▶│ Secrets      │
+│             │     │ (密码获取)    │     │ (调用API)        │     │ Manager      │
+└─────────────┘     └──────────────┘     └─────────────────┘     └──────────────┘
+                                                                          │
+                                                                          ▼
+                                                                  ┌──────────────┐
+                                                                  │ Oracle/MySQL │
+                                                                  │ Database     │
+                                                                  └──────────────┘
+```
+
+## Access Control Model
+
+- **用户名**：由 IAM 角色控制，根据角色映射数据库用户
+- **密码**：由 AWS Secrets Manager 动态提供，无需人工知晓
+- **访问权限**：通过 IAM Policy 控制谁能访问哪些 Secrets
+
+## Related Concepts
+
+- [[SecretsManagement]]：敏感信息管理的整体框架
+- [[SecretRotation]]：密码轮换机制，与 JDBC Wrapper 配合实现无停机轮换
+- [[AWS-SDK]]：AWS 服务调用开发工具包
+- [[IAM-Roles]]：基于角色的访问控制机制
+
+## Sources
+
+- [[CTP-Topic-62-AWS-Secrets-Manager]] — Victor 演示使用 JDBC Wrapper + AWS SDK 实现无密码 Oracle 数据库登录
+
+## Aliases
+
+- Database Credential Provider
+- Secrets Manager JDBC Driver
+- Dynamic Database Credentials
+- AWS SDK Database Wrapper
--- a/wiki/concepts/MLOps.md
+++ b/wiki/concepts/MLOps.md
@@ -0,0 +1,59 @@
+---
+title: "MLOps"
+type: concept
+tags: [ML, DevOps, machine-learning, operations, CI/CD]
+sources:
+  - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin
+last_updated: 2026-05-12
+---
+
+## Definition
+MLOps（Machine Learning Operations，机器学习运维）将机器学习与运维结合，涉及人员、技术和流程，以实现协作式 ML 解决方案。ML Ops 需要多元化团队和鼓励协作的文化，扩展了 DevOps 的原则和方法。
+
+## Key Components
+
+### Three Pipelines
+
+#### 1. Data Pipeline（数据管道）
+- 数据收集（Data Collection）
+- 数据集成（Data Integration）
+- 数据准备（Data Preparation）
+- **工具**: Amazon S3, Amazon Redshift
+
+#### 2. Training Pipeline（训练管道）
+- 特征工程（Feature Engineering）
+- 模型训练（Model Training）
+- 超参数调优（Hyperparameter Tuning）
+- **工具**: Amazon SageMaker
+
+#### 3. Inference Pipeline（推理管道）
+- 模型部署（Model Deployment）
+- 模型监控（Model Monitoring）
+- **工具**: Amazon SageMaker Real-time Endpoints
+
+## Key Challenges
+- 数据溯源（Data Provenance）
+- 模型管理（Model Management）
+- 部署工作流（Deployment Workflows）
+- 持续集成/持续部署（CI/CD）
+- 监控与可观测性
+
+## Relationship to DevOps
+MLOps 在 DevOps 实践基础上增加了 ML 特有的挑战：
+- 模型版本控制
+- 实验追踪
+- A/B 测试
+- 模型性能监控
+- 数据漂移检测
+
+## Related Concepts
+- [[DevOps]]
+- [[Amazon-SageMaker]]
+- [[Foundation-Models]]
+- [[Responsible-AI]]
+
+## Related Entities
+- [[AWS]]
+
+## Sources
+- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]
--- a/wiki/concepts/Oli-Workflow.md
+++ b/wiki/concepts/Oli-Workflow.md
@@ -0,0 +1,71 @@
+---
+title: Oli Workflow
+type: concept
+tags: [Workflow, Cloud-Governance, FinOps]
+sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16]
+---
+
+# Oli Workflow
+
+**Oli Workflow** 是 OpenText 超大规模云厂商支出审批工作流，所有云支出请求必须经过此流程审批。
+
+## Overview
+
+Oli Workflow 是企业云治理的核心流程：
+- **强制审批**：所有超大规模云厂商支出，无论金额，均需 MUI 或 Shannon 书面审批
+- **团队接管**：由 Tom Bice 领导的 FinOps 团队接管
+- **平台集成**：正在集成到 SMACs 平台
+
+## Three-Stage Approval Process
+
+| 阶段 | 负责方 | 验证内容 |
+|------|--------|----------|
+| 1. 可行性验证 | FinOps | 评估需求的技术和财务可行性 |
+| 2. 技术可行性验证 | Cloud Services | 评估技术实现可行性 |
+| 3. 预算可用性验证 | FPNA Team | 确认预算可用性 |
+
+## Request Form Fields
+
+| 字段 | 说明 |
+|------|------|
+| 员工信息 | 从企业 AD 自动拉取 |
+| 组织选择 | 下拉菜单选择 |
+| 成本中心 | 来自 Talent Central |
+| 请求类型 | 预算增加 vs 新建实验室空间 |
+| 云服务商 | 下拉选择 |
+| 区域 | 必须是活跃区域列表中的区域 |
+| 理由说明 | 评论区域提交 |
+
+## Key Features
+
+- **CSV 报告**：飞行中 CSV 报告追踪工作流状态、申请人、成本中心、月成本、当前步骤
+- **自动化整合**：与 Confluence 基础说明、AD 员工信息、Talent Central 成本中心集成
+- **拒绝机制**：未提供理由详情的请求将被立即拒绝
+
+## Approval Authority
+
+| 审批人 | 职责 |
+|--------|------|
+| MUI | 超大规模云厂商支出审批人 |
+| Shannon | 超大规模云厂商支出审批人 |
+
+## Related Concepts
+
+- [[FinOps]] — 云财务运营
+- [[Demand-Management]] — 需求管理
+- [[SMACs]] — 技术栈组合
+- [[ITIL-Service-Management]] — ITIL 框架
+- [[Product-Backlog]] — 产品待办列表
+
+## Related Entities
+
+- [[Tom-Bice]] — FinOps 团队负责人
+- [[FPNA-Team]] — 预算验证团队
+- [[MUI]] — 审批人
+- [[Shannon]] — 审批人
+- [[Octane]] — 需求管理平台
+- [[Qixi]] — 需求提交入口
+
+## Sources
+
+- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]]
--- a/wiki/concepts/Orchestration.md
+++ b/wiki/concepts/Orchestration.md
@@ -0,0 +1,44 @@
+---
+title: "Orchestration"
+type: concept
+tags:
+  - EDA
+  - Architecture
+  - Microservices
+  - AWS
+last_updated: 2026-04-14
+---
+
+## Aliases
+- Orchestration Pattern
+- 编排模式
+- 集中式服务协调
+
+## Definition
+编排模式（Orchestration）是一种由中央协调器（Orchestrator）集中控制和协调多个服务执行复杂业务流程的模式。与编舞模式（Choreography）的去中心化不同，编排模式通过中央工作流引擎驱动各服务按顺序执行任务。
+
+## AWS Implementation
+- **AWS Step Functions**：AWS 提供的工作流服务，用于构建状态机
+  - **State Machine**：状态机由多个 State（状态）组成，每个 State 代表一个工作步骤
+  - **Transitions**：状态转换定义从一个状态到下一个状态的条件和路径
+  - **Standard Workflows**：长时运行工作流，适合人工审批、长时间处理流程
+  - **Express Workflows**：高频短时工作流，适合毫秒级响应的大规模事件处理
+
+## Characteristics
+- **Centralized**：中央协调器控制整体流程
+- **Visible**：业务流程和状态转换清晰可见，便于监控和追踪
+- **Easier Debugging**：工作流失败时可准确定位到具体状态
+- **Tight Coupling Risk**：中央协调器与各服务存在一定耦合
+
+## Comparison with Choreography
+| 维度 | Orchestration（编排） | Choreography（编舞） |
+|------|---------------------|---------------------|
+| 控制 | 集中式 | 去中心化 |
+| 协调器 | 有（Step Functions） | 无 |
+| 复杂度 | 局部高，整体低 | 局部低，整体高 |
+| 可观测性 | 易于追踪 | 较难追踪 |
+| 适用场景 | 复杂、有明确业务流程 | 简单、独立的服务 |
+
+## Sources
+- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
--- a/wiki/concepts/Override-Status.md
+++ b/wiki/concepts/Override-Status.md
@@ -0,0 +1,51 @@
+---
+title: "Override Status"
+type: concept
+tags:
+  - AWS
+  - Scheduling
+  - Control
+  - AWS-Instance-Scheduler
+sources:
+  - ctp-topic-27-aws-instance-scheduler
+last_updated: 2026-05-12
+---
+
+## Override Status
+
+AWS Instance Scheduler 中的高级配置机制，允许管理员强制覆盖正常的调度规则，将实例保持在特定状态（通常为停止状态）。
+
+## Core Mechanism
+
+通过在实例上设置 `Override` 标签来激活：
+
+- **`Override = true`**：强制将实例保持在停止状态，即使在预设的启动时间内也不启动
+- **`Override = false`**：恢复正常调度逻辑
+
+## Use Cases
+
+### 1. 紧急维护场景
+- 实例正在进行紧急安全补丁更新
+- 临时禁用调度以避免干扰关键操作
+
+### 2. 资源保留场景
+- 保留特定环境（如 UAT/预生产）在特定时期保持运行
+- 临时排除特定实例从自动调度
+
+### 3. 故障规避
+- 实例上运行的任务无法接受意外重启
+- 生产等效环境需要更精细的控制
+
+## Relationship to Tagging
+
+Override Status 通过 `Override` 标签实现，是 Instance Scheduler [[Tagging]] 机制的重要组成部分：
+
+| 标签键 | 作用 | 优先级 |
+|--------|------|--------|
+| `Schedule` | 指定调度名称 | 正常调度 |
+| `Override = true` | 强制停止覆盖 | 最高优先级 |
+
+## Related Pages
+- [[AWS-Instance-Scheduler]] — 主要使用场景
+- [[Tagging]] — 实现机制
+- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源
--- a/wiki/concepts/Pre-commit-Hooks.md
+++ b/wiki/concepts/Pre-commit-Hooks.md
@@ -0,0 +1,34 @@
+---
+title: "Pre-commit Hooks"
+type: concept
+tags:
+  - GitOps
+  - DevOps
+  - CI/CD
+  - Automation
+last_updated: 2026-05-11
+---
+
+# Pre-commit Hooks
+
+## Definition
+在提交代码前运行的脚本工具，通常用于代码格式化、linting、安全扫描等。Renovate Bot 可以自动检测并更新这些钩子插件的版本号。
+
+## Core Functions
+- 在 `git commit` 前自动执行检查脚本
+- 常用场景：代码格式化（Prettier）、linting（ESLint）、安全扫描（Trivy）、Secrets 检测
+- 版本管理：保持钩子插件版本与最新安全修复同步
+- Renovate 集成：自动为 pre-commit 配置文件（如 `.pre-commit-config.yaml`）中的版本标签创建更新 PR
+
+## Related Concepts
+- [[Renovate-Bot]] — Renovate Bot 可自动更新 pre-commit 钩子插件版本
+- [[Dependency-Management]] — pre-commit 钩子是项目依赖的一部分
+- [[GitOps]] — pre-commit 是 GitOps 工作流中的质量门禁
+
+## Related Sources
+- [[ctp-topic-15-working-with-renovatebot]]
+
+## Aliases
+- Git Hooks
+- Pre-commit Framework
+- pre-commit-config.yaml
--- a/wiki/concepts/Privileged-Access-Management.md
+++ b/wiki/concepts/Privileged-Access-Management.md
@@ -0,0 +1,89 @@
+---
+title: "Privileged-Access-Management"
+type: concept
+tags:
+  - Security
+  - PAM
+  - Compliance
+  - Cloud
+  - DevOps
+---
+
+## Definition
+
+Privileged Access Management（PAM，特权访问管理）是一类安全解决方案，用于管理和监控具有 elevated permissions 的账号访问权限。特权账号包括系统管理员、数据库管理员、安全管理员等拥有超出普通用户权限的账号，以及应用程序服务账号、API 账号等非人工身份。
+
+## Core Objectives
+
+1. **凭据保护**：集中存储和管理特权账号密码、SSH 密钥、API Key 等敏感凭据
+2. **访问控制**：实施最小权限原则，确保用户仅获得完成任务所需的最小权限
+3. **会话监控**：记录和审计所有特权会话，支持事后追溯和合规审查
+4. **威胁检测**：实时检测异常特权行为，防止凭据滥用和横向移动攻击
+
+## PAM Architecture
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│                      PAM Solution                           │
+├─────────────────────────────────────────────────────────────┤
+│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐       │
+│  │  Credential │  │   Session   │  │    Risk    │       │
+│  │   Vault     │  │   Manager   │  │   Engine   │       │
+│  └─────────────┘  └─────────────┘  └─────────────┘       │
+│                                                             │
+│  ┌─────────────────────────────────────────────┐           │
+│  │              Access Control Layer            │           │
+│  │  (RBAC, MFA, Policy-based Access)            │           │
+│  └─────────────────────────────────────────────┘           │
+└─────────────────────────────────────────────────────────────┘
+                          ↑
+        ┌─────────────────┼─────────────────┐
+        ↓                 ↓                 ↓
+   ┌─────────┐      ┌─────────┐      ┌─────────┐
+   │  Root   │      │   DB    │      │  API    │
+   │ Account │      │  Admin  │      │ Service │
+   └─────────┘      └─────────┘      └─────────┘
+```
+
+## Cloud-Native vs Traditional PAM
+
+| Aspect | Traditional PAM | Cloud-Native (AWS Secrets Manager) |
+|--------|-----------------|----------------------------------|
+| Deployment | On-prem / Hybrid | Fully managed SaaS |
+| Client Agent | Required | Not required |
+| Scalability | Manual scaling | Auto-scaling |
+| Cost Model | Perpetual license + maintenance | Pay-per-use |
+| Integration | Manual configuration | Native AWS integration |
+
+## Key Vendors
+
+- **CyberArk**：Enterprise PAM market leader, on-prem and cloud offerings
+- **AWS Secrets Manager**：Cloud-native secrets management
+- **HashiCorp Vault**：Cloud-agnostic secrets and privileged access
+- **BeyondTrust**：Endpoint privilege management
+- **Thycotic**：Privileged access management
+
+## Related Concepts
+
+- [[SecretsManagement]]：敏感信息管理的整体框架
+- [[SecretRotation]]：密钥轮换机制
+- [[IAM-Roles]]：基于角色的访问控制
+- [[Zero-Trust]]：零信任安全模型
+
+## Related Entities
+
+- [[CyberArk]]：Enterprise PAM vendor
+- [[AWS]]：Cloud-native secrets management provider
+- [[HashiCorp]]：Cloud-agnostic secrets management
+
+## Sources
+
+- [[ctp-topic-37-secrets-certificates-management]] — CyberArk Micro Focus PAM evaluation
+- [[ctp-topic-62-aws-secrets-manager]] — AWS-native PAM implementation
+
+## Aliases
+
+- PAM
+- Privileged Access Management
+- Privileged Identity Management
+- PIM
--- a/wiki/concepts/Product-Backlog.md
+++ b/wiki/concepts/Product-Backlog.md
@@ -0,0 +1,51 @@
+---
+title: Product Backlog
+type: concept
+tags: [Agile, Scrum, Product-Management]
+sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16, ctp-topic-57-product-backlog-managing-demand]
+---
+
+# Product Backlog
+
+**产品待办列表（Product Backlog）** 是敏捷开发中的核心工件，是已排序的需求、特性、技术任务和缺陷的列表，是 Sprint 规划的输入来源。
+
+## Overview
+
+在 OpenText 云转型中：
+- Oli Workflow 审批通过的请求进入 Product Backlog 管理管道
+- 通过双周评审会议评估需求的理解度、价值和优先级
+- Sprint 规划采用 50% 新需求 / 50% 支持+技术债的配比
+
+## Key Processes
+
+| 阶段 | 活动 |
+|------|------|
+| 需求提交 | 通过 Octane 提交 |
+| 评审会议 | 评估理解度、价值、优先级 |
+| 特性化 | 带任务列表的详细需求 |
+| Sprint 规划 | 提前6个 Sprint 规划 |
+| 履约 | Prerequisite Phase → Sprint |
+
+## Attributes
+
+- **优先级排序**：基于 WSJF（Weighted Shortest Job First）
+- **估算**：评估工作量大小
+- **细化（Refinement）**：持续完善需求细节
+- **渐进明细**：随着理解加深不断完善
+
+## Related Concepts
+
+- [[Demand-Management]] — 需求管理
+- [[Oli-Workflow]] — 审批工作流
+- [[SMACs]] — 技术栈组合
+- [[WSJF]] — 加权最短工作优先
+
+## Related Entities
+
+- [[Octane]] — 需求管理平台
+- [[Qixi]] — 需求提交入口
+
+## Sources
+
+- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]]
+- [[sources/ctp-topic-57-product-backlog-managing-demand.md]]
--- a/wiki/concepts/Prompt-Engineering.md
+++ b/wiki/concepts/Prompt-Engineering.md
@@ -0,0 +1,58 @@
+---
+title: "Prompt Engineering"
+type: concept
+tags: [generative-ai, llm, prompt, aws, amazon-bedrock]
+sources: [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]
+last_updated: 2026-05-12
+---
+
+## Aliases
+- 提示词工程
+- Prompt Design
+- 提示工程
+
+## Summary
+
+**Prompt Engineering**（提示词工程）是创建、设计和优化提示词（Prompt）以引导大语言模型（LLM）产生准确、相关输出的技术实践。它是一个迭代过程，需要针对具体用例反复测试和调整提示词。
+
+## Key Properties
+
+- **类型**：方法 / 技术实践
+- **核心目标**：确保 LLM 输出的准确性和相关性
+- **过程性质**：迭代式（测试 → 调整 → 优化）
+
+## Prompt 四大组件
+
+1. **指令（Instruction）**：明确告诉模型要执行什么任务
+2. **上下文（Context）**：提供背景信息，帮助模型理解场景
+3. **用户输入（User Input）**：具体的问题或请求
+4. **输出指示器（Output Indicator）**：指定期望的输出格式或风格
+
+## 基础技巧
+
+### One-shot Prompting（单样本提示）
+- 提供一个示例，让模型理解任务模式
+- 适合简单、结构清晰的任务
+
+### Few-shot Prompting（少样本提示）
+- 提供 2~5 个示例，帮助模型理解多样性
+- 适合需要格式一致性但示例丰富的场景
+
+### Chain-of-Thought（思维链）
+- 在提示词中引导模型逐步思考
+- 提供 step-by-step 推理示例
+- 适合复杂推理和多步骤任务
+
+## 最佳实践
+
+- **清晰准确**：指令应具体、无歧义
+- **结构化**：使用明确的分隔符组织各组件
+- **考虑人类响应**：LLM 训练数据来自人类，因此提示词应符合人类沟通习惯
+- **迭代优化**：针对具体用例持续测试和调整
+
+## Connections
+
+- 核心技术：[[GenerativeAI]]（LLM 是 Prompt Engineering 的载体）
+- 应用平台：[[AmazonBedrock]]（Bedrock 上的基础模型均支持 Prompt Engineering）
+- 相关工具：[[AmazonQ]]（Amazon Q Developer 利用 Prompt Engineering 优化代码生成）
+- 相关概念：[[RAG从入门到精通系列1：基础RAG]]（RAG 系统中的 Prompt Engineering 是关键调优点）
--- a/wiki/concepts/RDS-Maintenance-Window.md
+++ b/wiki/concepts/RDS-Maintenance-Window.md
@@ -0,0 +1,49 @@
+---
+title: "RDS Maintenance Window"
+type: concept
+tags:
+  - AWS
+  - RDS
+  - Database
+  - Maintenance
+sources:
+  - ctp-topic-27-aws-instance-scheduler
+last_updated: 2026-05-12
+---
+
+## RDS Maintenance Window
+
+AWS RDS（Relational Database Service）维护窗口是数据库实例进行必要维护操作（如补丁升级、系统升级）的时间段，由 AWS 预先定义或由用户指定。
+
+## Core Characteristics
+
+- **频率**：每个 RDS 实例每 7 天强制执行一次维护
+- **持续时间**：通常 30-60 分钟
+- **可中断性**：维护期间实例可能不可用
+- **用户控制**：用户可指定首选维护窗口（每周一次，每次 30 分钟）
+
+## AWS Instance Scheduler 中的处理
+
+Instance Scheduler 具备智能感知 RDS 维护窗口的能力：
+
+1. **维护前**：在维护窗口开始前将 RDS 实例状态记录为"即将进入维护"
+2. **维护期间**：暂停调度操作，不执行启停指令
+3. **维护完成后**：自动识别维护结束，恢复正常的调度状态
+
+## Key Considerations
+
+- **停止 vs 终止**：RDS 实例的关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"，否则维护窗口结束后实例不会重新启动
+- **多可用区**：Multi-AZ 实例的维护通常自动在备用实例上进行，对主实例影响较小
+- **蓝绿部署**：使用蓝绿部署进行数据库升级可减少停机时间
+
+## Relationship to Instance Scheduler
+
+RDS Maintenance Window 是 Instance Scheduler 在调度 RDS 实例时必须考虑的特殊约束：
+
+- 实例的 `InstanceType` 标签用于区分 EC2 和 RDS
+- RDS 实例需要额外的维护窗口逻辑判断
+- 调度算法需查询 RDS API 获取实例维护状态
+
+## Related Pages
+- [[AWS-Instance-Scheduler]] — 依赖此机制
+- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源
--- a/wiki/concepts/Rate-Limiting.md
+++ b/wiki/concepts/Rate-Limiting.md
@@ -0,0 +1,33 @@
+---
+title: "Rate Limiting"
+type: concept
+tags:
+  - CI/CD
+  - DevOps
+  - GitOps
+last_updated: 2026-05-11
+---
+
+# Rate Limiting
+
+## Definition
+速率限制，为防止自动化工具（如 Renovate Bot）瞬间产生过多 Pull Request 导致 CI/CD 系统（如 Jenkins）崩溃，Renovate 允许限制每小时或同时开启的 PR 数量。
+
+## Core Functions
+- 限制每小时创建的 PR 数量
+- 限制同时打开的 PR 数量上限
+- 防止 GitHub API 触发速率限制（429 Too Many Requests）
+- 避免给 CI/CD 系统带来突发负载
+
+## Related Concepts
+- [[Renovate-Bot]] — Rate Limiting 是 Renovate Bot 的重要配置选项
+- [[Dependency-Management]] — Rate Limiting 支撑依赖管理的稳定运行
+- [[CI-CD]] — CI/CD 流水线是 Rate Limiting 的保护对象
+
+## Related Sources
+- [[ctp-topic-15-working-with-renovatebot]]
+
+## Aliases
+- API Rate Limiting
+- Request Throttling
+- PR Rate Limit
--- a/wiki/concepts/ReservedInstances.md
+++ b/wiki/concepts/ReservedInstances.md
@@ -0,0 +1,39 @@
+---
+title: "Reserved Instances"
+type: concept
+tags:
+  - AWS
+  - Cost-Optimization
+  - FinOps
+aliases:
+  - Reserved Instances
+  - RI
+  - 预留实例
+last_updated: 2026-05-12
+---
+
+## Overview
+
+Reserved Instances（预留实例）通过预付费或无预付承诺，获得相比 On-Demand 最高 60-72% 的折扣。适用于稳定运行的长期工作负载。
+
+## Key Characteristics
+
+- **承诺期限**：1年或3年
+- **支付选项**：全额预付、部分预付、无预付
+- **范围**：区域级或可用区级
+- **类型**：Standard（可交换）、Convertible（可转换）
+
+## When to Use
+
+- 生产环境中的稳定工作负载
+- 数据库实例
+- 核心业务应用
+- 7×24 运行的服务
+
+## Related Pages
+
+- [[FinOps]]
+- [[SavingsPlans]]
+- [[SpotInstances]]
+- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
+- [[ctp-topic-63-optimise-resource-cost-using-automation]]
--- a/wiki/concepts/Responsible-AI.md
+++ b/wiki/concepts/Responsible-AI.md
@@ -0,0 +1,47 @@
+---
+title: "Responsible AI"
+type: concept
+tags: [AI, ethics, governance, responsible-AI, transparency]
+sources:
+  - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin
+  - public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec
+last_updated: 2026-05-12
+---
+
+## Definition
+Responsible AI（负责任 AI）是一套确保 AI 系统安全、公平、透明和合规的原则和实践。AWS 在 Amazon Bedrock 中提供了 Guardrails for Amazon Bedrock，用于根据应用需求和负责任 AI 政策定制安全保障措施。
+
+## Six Key Principles
+
+| 原则 | 描述 |
+|------|------|
+| **Fairness（公平性）** | 确保 AI 系统不会对特定群体产生偏见 |
+| **Explainability（可解释性）** | 使 AI 决策过程透明可理解 |
+| **Robustness（鲁棒性）** | 确保 AI 系统在各种条件下稳定可靠 |
+| **Governance（治理）** | 建立清晰的 AI 使用和决策责任框架 |
+| **Transparency（透明度）** | 公开 AI 系统的能力、局限和使用方式 |
+| **Privacy & Security（隐私与安全）** | 保护用户数据，遵守隐私法规 |
+
+## AWS Implementation
+
+### Guardrails for Amazon Bedrock
+Amazon Bedrock 提供的安全护栏服务，允许客户：
+- 根据应用需求定制安全保障措施
+- 过滤有害内容
+- 实施负责任 AI 政策
+- 监控和审计 AI 交互
+
+### Data Privacy
+Amazon Bedrock 在数据隐私方面的保证：
+- 用户数据不与第三方模型提供商共享
+- 提示词（Prompts）不与模型提供商共享
+- 仅在请求-响应周期内存储数据
+- 符合 GDPR 合规要求
+
+## Related Concepts
+- [[Amazon-Bedrock]]
+- [[Guardrails-for-Amazon-Bedrock]]
+- [[Foundation-Models]]
+
+## Sources
+- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]
--- a/wiki/concepts/Root-Terragrunt-HCL.md
+++ b/wiki/concepts/Root-Terragrunt-HCL.md
@@ -0,0 +1,68 @@
+---
+title: "Root Terragrunt HCL"
+type: concept
+tags: [Terraform, Terragrunt, IaC, Configuration, AWS]
+sources:
+  - ctp-topic-16-cross-account-terraform-modules.md
+  - ctp-topic-48-terraform-vs-terragrunt.md
+last_updated: 2026-05-15
+---
+
+## Overview
+
+Root Terragrunt HCL 是项目根目录下的 `terragrunt.hcl` 配置文件，用于定义所有 Terraform 模块通用的远程状态存储（Remote State）和角色切换逻辑。它是 Terragrunt DRY（Don't Repeat Yourself）原则的核心体现。
+
+## Key Responsibilities
+
+### 1. Remote State Configuration
+
+```hcl
+remote_state {
+  backend = "s3"
+  config = {
+    bucket         = "my-terraform-state"
+    key            = "${path_relative_to_include()}/terraform.tfstate"
+    region         = "us-east-1"
+    encrypt        = true
+    dynamodb_table = "terraform-locks"
+  }
+}
+```
+
+### 2. Cross-Account Role Switching
+
+```hcl
+inputs = {
+  # 在跨账号场景中，通过 assume_role 切换到目标账号的角色
+  assume_role_arn = "arn:aws:iam::TARGET_ACCOUNT:role/Cross-account-ECS-Deploy-Runner-Role"
+}
+```
+
+## How It Works
+
+Terragrunt 通过继承机制将根目录的配置自动应用于所有子模块：
+
+1. **检测模块**：Jenkins 检测到模块目录
+2. **加载配置**：Terragrunt 加载根目录的 `terragrunt.hcl`
+3. **注入变量**：自动将 remote_state 和 assume_role_arn 注入子模块
+4. **执行命令**：运行 `terragrunt plan/apply`
+
+## Relationship with Terragrunt
+
+- [[Terragrunt]] ← uses ← [[Root-Terragrunt-HCL]]
+- [[Cross-account-Terraform-Modules]] ← configured_by ← [[Root-Terragrunt-HCL]]
+- [[ECS-Deploy-Runner]] ← configured_by ← [[Root-Terragrunt-HCL]]
+
+## Key Differences: Local vs CI/CD
+
+| 环境 | Role 处理 |
+|------|----------|
+| **本地开发** | Terragrunt 自动从 HCL 配置 Assume Role，无需手动干预 |
+| **Jenkins CI/CD** | EDR 使用 HCL 中配置的 assume_role_arn，通过 ECS 容器环境 Assume |
+
+## Related Concepts
+
+- [[Terragrunt]]：Terragrunt 是该配置的解析和执行引擎
+- [[TerraformState]]：remote_state 配置定义了状态文件存储位置
+- [[Assume-Role]]：assume_role_arn 配置控制跨账号角色切换
+- [[DRY-Principle]]：Root HCL 是 DRY 原则在 IaC 中的应用
--- a/wiki/concepts/SMACs.md
+++ b/wiki/concepts/SMACs.md
@@ -0,0 +1,50 @@
+---
+title: SMACs
+type: concept
+tags: [Technology-Stack, Cloud, Digital-Transformation]
+sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16, ctp-topic-57-product-backlog-managing-demand]
+---
+
+# SMACs
+
+**SMACs** 是 Social（社交）、Mobile（移动）、Analytics（分析）、Cloud（云）四种技术的组合，代表现代数字化转型的核心技术栈。
+
+## Components
+
+| 字母 | 含义 | 技术示例 |
+|------|------|----------|
+| **S** | Social（社交） | 企业社交平台、协作工具 |
+| **M** | Mobile（移动） | 移动应用、物联网设备 |
+| **A** | Analytics（分析） | 大数据分析、机器学习 |
+| **C** | Cloud（云） | 公有云、私有云、混合云 |
+
+## In OpenText Cloud Transformation
+
+在 OpenText 云转型中：
+- **Oli Workflow** 正在集成到 SMACs 平台
+- **主服务目录（Combined Cloud Products Master Catalog）** 将嵌入 SMACs
+- **Enterprise Iton 项目**（标准 OT SMACS 租户）正在进行中
+
+## Goals
+
+- 统一数字化平台，提升服务交付效率
+- 支持业务单元 80% 场景下自助选择所需服务
+- 自动化履约流程，减少人工干预
+
+## Related Concepts
+
+- [[Demand-Management]] — 需求管理
+- [[FinOps]] — 云财务运营
+- [[ITIL-Service-Management]] — ITIL 框架
+- [[Oli-Workflow]] — 审批工作流
+
+## Related Entities
+
+- [[Tom-Bice]] — FinOps 团队负责人，推动 SMACS 集成
+- [[Octane]] — 需求管理平台
+- [[FPNA-Team]] — 预算验证团队
+
+## Sources
+
+- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]]
+- [[sources/ctp-topic-57-product-backlog-managing-demand.md]]
--- a/wiki/concepts/SavingsPlans.md
+++ b/wiki/concepts/SavingsPlans.md
@@ -0,0 +1,36 @@
+---
+title: "Savings Plans"
+type: concept
+tags:
+  - AWS
+  - Cost-Optimization
+  - FinOps
+aliases:
+  - Savings Plans
+  - SP
+  - 节省计划
+last_updated: 2026-05-12
+---
+
+## Overview
+
+Savings Plans（节省计划）是 AWS 提供的灵活定价模型，通过承诺一定使用量（以美元/小时计算）获得相比 On-Demand 最高 72% 的折扣。比 Reserved Instances 更灵活。
+
+## Types
+
+- **Compute Savings Plans**：最灵活，覆盖 EC2、Lambda、ECS 等
+- **EC2 Instance Savings Plans**：针对特定实例家族的承诺
+- **SageMaker Savings Plans**：针对 SageMaker 服务
+
+## Key Advantages
+
+- 相比 RI 更灵活，无需指定具体实例类型
+- 自动应用于任何符合条件的资源
+- 与 Reserved Instances 可叠加使用
+
+## Related Pages
+
+- [[FinOps]]
+- [[ReservedInstances]]
+- [[SpotInstances]]
+- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
--- a/wiki/concepts/SecretRotation.md
+++ b/wiki/concepts/SecretRotation.md
@@ -0,0 +1,92 @@
+---
+title: "SecretRotation"
+type: concept
+tags:
+  - AWS
+  - Security
+  - Automation
+  - DevOps
+---
+
+## Definition
+
+Secret Rotation（密钥轮换）是指定期自动更换敏感凭据（密码、API Key、证书等）的安全机制，旨在防止长期密钥泄露导致的安全风险。
+
+## Why Rotate Secrets?
+
+1. **降低泄露风险**：即使密钥被意外泄露，轮换机制可限制暴露窗口
+2. **合规要求**：满足 SOC 2、PCI-DSS 等安全合规标准
+3. **密钥生命周期管理**：遵循安全最佳实践中的密钥生命周期原则
+4. **应对内部威胁**：限制离职员工或恶意内部人员的凭据滥用
+
+## AWS Secrets Manager Rotation Strategies
+
+### Built-in Rotation Lambdas
+
+AWS Secrets Manager 为以下服务提供开箱即用的轮换 Lambda 函数：
+- **RDS 数据库**：MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Aurora
+- **Redshift**
+- **DocumentDB**
+
+### Custom Rotation Patterns
+
+#### Oracle Database Password Rotation
+
+```
+用户密码存储在 Secrets Manager
+        ↓
+Lambda 函数被触发（或定时）
+        ↓
+Lambda 连接 Oracle 实例（使用当前凭据）
+        ↓
+生成新密码
+        ↓
+更新数据库中的用户密码
+        ↓
+更新 Secrets Manager 中的密码
+        ↓
+完成轮换
+```
+
+**关键优势**：无需通过邮件发送新密码，通过 AWS 角色授权访问 Secrets
+
+#### SendGrid API Key Rotation
+
+- **问题**：多个团队各自管理 SendGrid API Key，轮换需要代码变更和重启应用
+- **解决方案**：集中式 SMTP 服务统一处理 SendGrid 轮换，应用只连接内部 SMTP 服务器
+- **实现**：SMTP 服务在端口 1025 提供服务，应用无需感知后端 API Key 变更
+
+## Rotation Triggers
+
+| 触发方式 | 说明 |
+|---------|------|
+| 定时轮换 | 按固定间隔（天数）自动触发 |
+| 手动触发 | 通过 AWS CLI 或 Console 手动启动 |
+| API 调用 | 通过 `rotateSecret` API 编程触发 |
+| 事件驱动 | CloudWatch Events 触发 Lambda |
+
+## Best Practices
+
+1. **先集中，后轮换**：先完成 Secrets 集中化管理，再启用轮换
+2. **测试回滚**：轮换失败时的回滚机制测试
+3. **应用兼容性**：确保应用支持动态获取新凭据（使用 JDBC Wrapper、SDK 等）
+4. **监控告警**：轮换失败时的告警通知机制
+5. **分阶段实施**：先低风险系统试点，再推广至生产环境
+
+## Related Concepts
+
+- [[SecretsManagement]]：敏感信息管理的整体框架
+- [[JDBCWrapper]]：数据库应用获取动态凭据的方式
+- [[Lambda]]：用于执行轮换逻辑的无服务器函数
+- [[ControlTower]]：企业级 Secrets 管理的治理框架
+
+## Sources
+
+- [[CTP-Topic-62-AWS-Secrets-Manager]] — Oracle 数据库和 SendGrid API Key 轮换实施案例
+
+## Aliases
+
+- Key Rotation
+- Credential Rotation
+- Password Rotation
+- API Key Rotation
--- a/wiki/concepts/SecretsManagement.md
+++ b/wiki/concepts/SecretsManagement.md
@@ -0,0 +1,63 @@
+---
+title: "SecretsManagement"
+type: concept
+tags:
+  - AWS
+  - Security
+  - Cloud
+  - DevOps
+---
+
+## Definition
+
+Secrets Management（敏感信息管理）是指在云环境中集中存储、管理、安全轮换敏感凭据（密码、API Key、证书、加密密钥等）的实践，旨在消除硬编码明文密码和密钥的安全风险。
+
+## Core Principles
+
+1. **集中化存储**：所有 Secrets 存储在集中式保险库（Vault）中，而非代码、配置文件或环境变量
+2. **最小权限访问**：通过 IAM 角色和策略控制谁可以访问哪些 Secrets
+3. **自动轮换**：定期自动更换 Secrets，减少长期密钥泄露风险
+4. **审计追踪**：记录所有 Secrets 访问和变更操作
+5. **加密传输**：Secrets 在传输和存储时均加密保护
+
+## AWS Secrets Manager Implementation
+
+### Three-Phase Approach
+
+1. **集中 Secrets**：将所有密码、密钥集中到 AWS Secrets Manager
+2. **调整自动化**：修改 CI/CD 和应用程序，从 Secrets Manager 动态获取凭据
+3. **启动轮换**：启用自动轮换机制，定期更换凭据
+
+### Key Benefits
+
+- 开发者无需直接访问 Secrets，通过角色和 AWS 凭证授权
+- 无需客户端软件（对比 HashiCorp Vault）
+- 与 AWS Control Tower 集成实现企业级标准化
+- 成本比自托管 Vault 方案更低
+
+## AWS Alternatives
+
+| Feature | AWS Secrets Manager | HashiCorp Vault |
+|---------|-------------------|-----------------|
+| 客户端依赖 | 无 | 需要 |
+| 托管服务 | 完全托管 | 自托管/托管 |
+| 成本 | 按 API 调用计费 | 基础设施+运维成本 |
+| Lambda 集成 | 原生支持 | 需要额外配置 |
+
+## Related Concepts
+
+- [[SecretRotation]]：定期自动更换 Secrets 的机制
+- [[JDBCWrapper]]：通过包装器动态获取数据库凭据
+- [[IAM-Roles]]：基于角色的访问控制
+- [[ControlTower]]：AWS 多账户治理
+
+## Sources
+
+- [[CTP-Topic-62-AWS-Secrets-Manager]] — AWS Secrets Manager 企业实施经验
+- [[CTP-Topic-37-Secrets-Certificates-Management]] — Secrets 和证书管理最佳实践
+
+## Aliases
+
+- Secret Management
+- Credentials Management
+- API Key Management
--- a/wiki/concepts/Security-Group-Policy.md
+++ b/wiki/concepts/Security-Group-Policy.md
@@ -0,0 +1,68 @@
+---
+title: "Security Group Policy"
+type: concept
+tags:
+  - AWS
+  - Security
+  - Security-Group
+  - Firewall-Manager
+  - Compliance
+sources:
+  - ctp-topic-55-aws-firewall-manager
+last_updated: 2026-04-14
+---
+
+## Definition
+
+Security Group Policy 是 AWS Firewall Manager 中的安全组策略类型，用于在组织级别对安全组进行集中化管理和合规性控制。Policy 定义在 Firewall Manager 管理员账户中，通过 AWS Config + Lambda 机制自动分发和强制执行到目标账户的 EC2 实例。
+
+## Policy Types
+
+### 1. Common Security Group Policy（通用安全组策略）
+- **作用**：将基线安全组附加到所有目标账户的 EC2 实例
+- **特点**：允许产品团队在基线之上继续添加自定义安全组规则
+- **适用场景**：需要统一安全基线但保留团队灵活性的场景
+
+### 2. Audit & Enforcement Security Group Policy（审计与强制执行策略）
+- **作用**：检测并拒绝过度宽松（over-permissive）的安全组规则
+- **两种修复模式**：
+  - **手动修复（Manual Remediation）**：仅告警，由管理员手动处理
+  - **自动修复（Auto Remediation）**：通过 Lambda 自动纠正不合规规则
+- **适用场景**：强制最小权限原则，防止安全组配置错误导致风险暴露
+
+### 3. Cleanup Security Group Policy（清理策略）
+- **作用**：自动识别并清理未使用的冗余安全组
+- **适用场景**：减少安全组管理复杂度，避免过期规则堆积
+
+## Policy Lifecycle
+```
+Policy Created in Firewall Manager Admin Account
+    ↓
+Target Account / OU Association
+    ↓
+AWS Config Compliance Check
+    ├── Compliant → No Action
+    └── Non-Compliant → Lambda Triggered
+            ↓
+Auto-Remediation (if enabled)
+    ↓
+New EC2 Instance → Auto-attach Security Group
+Policy Deleted → Auto-detach Security Group from all instances
+```
+
+## Prerequisites
+- Firewall Manager 管理员账户已配置
+- 目标账户必须启用 AWS Config
+- 目标账户所在 OU 必须授予 Firewall Manager 管理员相应权限
+
+## Relationship with Other Concepts
+- **[[AWS Firewall Manager]]**：Security Group Policy 的上层管理平台
+- **[[AWS Config]]**：提供合规性评估数据
+- **[[AWS Lambda]]**：执行自动化修复逻辑
+- **[[Prefix List]]**：定义允许的 IP CIDR 范围，供安全组规则引用
+- **[[AWS RAM]]**：跨账户共享 Prefix List
+
+## Design Patterns
+- **分层叠加模式**：Common SG（基线）+ 产品团队自定义 SG（叠加）= 完整安全策略
+- **黑名单模式**：Audit & Enforcement Policy 拒绝特定危险规则（如 0.0.0.0/0 全开放）
+- **白名单模式**：只允许明确声明的 CIDR 范围访问
--- a/wiki/concepts/Shared-Account.md
+++ b/wiki/concepts/Shared-Account.md
@@ -0,0 +1,55 @@
+---
+title: "Shared Account"
+type: concept
+tags: [AWS, Multi-Account, Landing-Zone, Architecture, IAM]
+sources:
+  - ctp-topic-16-cross-account-terraform-modules.md
+last_updated: 2026-05-15
+---
+
+## Overview
+
+Shared Account（共享账号）是 AWS Landing Zone 多账号架构中的核心管理账号，托管 CI/CD 平台（[[Jenkins]]）、镜像仓库等公共服务，并作为跨账号部署的**信任源**（Trust Source）。
+
+## Role in Multi-Account Architecture
+
+在 AWS Landing Zone 中，Shared Account 是 Workload 账号之间的**唯一信任中间人**：
+
+```
+Workload Account A → 不直接访问 → Workload Account B
+       ↑                                       ↓
+       └── ← Shared Account (Assume Role) ────┘
+```
+
+这种架构通过[[Blast-Radius]]控制实现了：
+- Workload 账号之间无直接信任关系
+- 所有跨账号操作通过 Shared Account 中转
+- 安全策略集中管控和审计
+
+## Responsibilities
+
+| 职责 | 说明 |
+|------|------|
+| CI/CD 托管 | Jenkins、构建代理 |
+| 镜像仓库 | ECR 中的容器镜像 |
+| 跨账号部署 | [[ECS-Deploy-Runner]] 运行在此账号，通过 Assume Role 访问目标账号 |
+| 公共服务 | DNS（NTP 等）供给 |
+
+## Security Principles
+
+1. **最小权限**：仅持有部署所需的两个专用角色（State Accessor + Deploy Runner Role）
+2. **审计追踪**：所有操作集中记录
+3. **隔离保护**：Shared Account 本身受到严格的安全控制和定期审计
+
+## Relationships
+
+- [[AWS-Landing-Zone]]：Shared Account 是 Landing Zone 架构的支柱
+- [[ECS-Deploy-Runner]]：运行在 Shared Account 的 ECS 集群
+- [[Jenkins]]：托管在 Shared Account
+- [[Blast-Radius]]：Shared Account 架构是 Blast Radius 控制的核心机制
+- [[Assume-Role]]：Shared Account 通过 Assume Role 访问 Workload 账号
+
+## Related Concepts
+
+- [[Cross-account-Terraform-Modules]]：Shared Account 支撑的核心功能
+- [[Infrastructure-as-Code]]：Shared Account 中的 Jenkins 驱动 IaC 部署
--- a/wiki/concepts/TF-State-Bucket-Accessor.md
+++ b/wiki/concepts/TF-State-Bucket-Accessor.md
@@ -0,0 +1,70 @@
+---
+title: "TF State Bucket Accessor"
+type: concept
+tags: [Terraform, IAM, S3, State-Management, AWS, Security]
+sources:
+  - ctp-topic-16-cross-account-terraform-modules.md
+last_updated: 2026-05-15
+---
+
+## Overview
+
+TF State Bucket Accessor 是跨账号 Terraform 部署方案中的两个核心 IAM 角色之一，专门用于在目标 AWS 账号中读取和写入 Terraform 状态文件（S3 存储）。
+
+## Purpose
+
+Terraform 状态文件记录了基础设施的当前期望状态。在跨账号场景中：
+
+- **状态文件存储位置**：每个 Workload 账号拥有独立的 S3 存储桶
+- **访问挑战**：Shared Account 的 [[ECS-Deploy-Runner]] 需要读写这些状态文件
+- **安全约束**：不能直接赋予 Shared Account 对所有 S3 桶的完全访问权限
+- **解决方案**：在每个目标账号中创建专门的 IAM 角色，仅允许部署工具 Assume
+
+## Security Design
+
+遵循最小权限原则（Principle of Least Privilege）：
+
+```json
+{
+  "Effect": "Allow",
+  "Principal": {
+    "AWS": "arn:aws:iam::<SharedAccount>:role/ecs-deploy-runner-execution-role"
+  },
+  "Action": [
+    "s3:GetObject",
+    "s3:PutObject",
+    "s3:ListBucket"
+  ],
+  "Resource": [
+    "arn:aws:s3:::<account>-terraform-state",
+    "arn:aws:s3:::<account>-terraform-state/*"
+  ]
+}
+```
+
+## Relationship with Terraform State
+
+- [[TerraformState]]：状态文件管理是 IaC 的核心问题
+- [[Blast-Radius]]：专用角色限制了凭证泄露时的影响范围
+- [[Assume-Role]]：EDR 通过 Assume Role 获取该角色的临时凭证
+
+## Dual Role Pattern
+
+跨账号 Terraform 部署使用**双角色模式**，将状态访问和资源部署分离：
+
+| 角色 | 职责 | 托管位置 |
+|------|------|---------|
+| **TF State Bucket Accessor** | 读取/写入 Terraform 状态文件 | 目标账号 |
+| [[Cross-account-ECS-Deploy-Runner-Role]] | 执行资源部署（plan/apply） | 目标账号 |
+
+## Relationships
+
+- [[TerraformState]] ← protected_by ← [[TF-State-Bucket-Accessor]]
+- [[ECS-Deploy-Runner]] ← uses ← [[TF-State-Bucket-Accessor]]
+- [[Assume-Role]] ← mechanism ← [[TF-State-Bucket-Accessor]]
+- [[Blast-Radius]] ← controls ← [[TF-State-Bucket-Accessor]]
+
+## Related Entities
+
+- [[ECS-Deploy-Runner]]：使用该角色的执行器
+- [[Cross-account-ECS-Deploy-Runner-Role]]：双角色模式中的另一个角色
--- a/wiki/concepts/Tagging.md
+++ b/wiki/concepts/Tagging.md
@@ -0,0 +1,55 @@
+---
+title: "Tagging"
+type: concept
+tags:
+  - AWS
+  - Resource-Management
+  - Governance
+  - Cost-Optimization
+sources:
+  - ctp-topic-27-aws-instance-scheduler
+  - ctp-topic-28-aws-tag-validation-tool
+last_updated: 2026-05-12
+---
+
+## Tagging
+
+AWS 资源标签化（Tagging）是通过在 AWS 资源上附加键值对元数据来实现资源分组、归类和自动化策略关联的管理机制。
+
+## Role in AWS Instance Scheduler
+
+Instance Scheduler 通过实例上的特定标签来关联调度逻辑：
+
+| 标签键 | 说明 | 示例值 |
+|--------|------|--------|
+| `Schedule` | 关联调度名称 | `Seattle-9-5` |
+| `Period` | 关联周期名称 | `Weekdays-Business-Hours` |
+| `Override` | 覆盖状态 | `true`（强制停止）/ `false`（正常调度） |
+
+## Key Tags for Instance Scheduler
+
+- **`Schedule`**：将实例关联到 DynamoDB Config Table 中的调度定义
+- **`Period`**：将实例关联到具体的周期（开始/结束时间、工作日）
+- **`InstanceType`**：标识实例类型（EC2/RDS），影响调度行为差异
+
+## AWS Tagging Best Practices
+
+- **一致性命名**：使用标准化前缀（如 `Environment:`、`Team:`、`CostCenter:`）
+- **必填标签**：Enforce Tag 策略要求所有资源必须附有特定标签
+- **自动化标签**：通过 AWS Config Rules 或 Lambda 自动补全缺失标签
+- **标签验证**：使用 Tag Editor 或第三方工具（如 ctp-topic-28-aws-tag-validation-tool）确保标签合规
+
+## Relationship to Governance
+
+Tagging 是 AWS 云治理的基石，支持：
+
+- **成本归因**：按团队/项目/环境追踪云支出
+- **访问控制**：基于标签的 IAM 策略
+- **自动化操作**：Instance Scheduler、自动化备份等均依赖标签
+- **资源分组**：跨服务和账户的资源发现与分组
+
+## Related Pages
+- [[AWS-Instance-Scheduler]] — 核心使用场景
+- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源
+- [[ctp-topic-28-aws-tag-validation-tool]] — 标签验证工具
+- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] — FinOps 标签策略
--- a/wiki/concepts/TerraformState.md
+++ b/wiki/concepts/TerraformState.md
@@ -0,0 +1,30 @@
+---
+title: "Terraform State"
+type: concept
+tags:
+  - Terraform
+  - IaC
+  - State Management
+sources:
+  - ctp-topic-48-terraform-vs-terragrunt.md
+last_updated: 2026-05-13
+---
+
+## Definition
+Terraform State 是 Terraform 内部维护的 JSON 文件，记录了真实世界基础设施资源与 HCL 代码定义之间的映射关系，是 Terraform 将期望状态与实际运行环境绑定的核心机制。
+
+## Core Mechanism
+- **状态锁定（State Locking）**：防止并发执行导致状态冲突
+- **状态后端（State Backend）**：本地存储适用于个人开发，企业级使用需配置远程后端（S3 + DynamoDB、Terraform Cloud、Consul 等）
+- **状态漂移检测（Drift Detection）**：对比状态文件与实际资源，发现非 Terraform 管理的变更
+
+## State Management Best Practices
+- **永远不要手动修改状态文件**——使用 `terraform import` 导入已有资源
+- **使用远程后端**：本地状态在团队协作下会导致状态文件冲突和丢失
+- **启用状态加密**：敏感信息（密码、密钥）可能存在于状态中
+- **版本化存储**：使用支持版本控制的远程后端（如 S3 + DynamoDB）
+
+## Connections
+- [[Terraform]] ← uses ← [[TerraformState]]
+- [[Terragrunt]] ← abstracts_away ← [[TerraformState]]（通过模板化管理 remote state 块）
+- [[TerraformEnterprise]] ← provides_managed ← [[TerraformState]]（远程工作区状态管理）
--- a/wiki/concepts/cross-account-json.md
+++ b/wiki/concepts/cross-account-json.md
@@ -0,0 +1,59 @@
+---
+title: "cross-account.json"
+type: concept
+tags: [Terraform, CI/CD, Jenkins, Deployment, IaC]
+sources:
+  - ctp-topic-16-cross-account-terraform-modules.md
+last_updated: 2026-05-15
+---
+
+## Overview
+
+`cross-account.json` 是部署在 Terraform 模块目录中的一个约定俗成的**标记文件**（Marker File），用于告知 Jenkins CI/CD 流水线该模块需要调用跨账号部署逻辑。
+
+## Purpose
+
+在复杂的 AWS Landing Zone 环境中，并非所有 Terraform 模块都需要跨账号部署：
+
+- **普通模块**：仅在单一账号内运行，使用标准 Jenkins → EDR 流水线
+- **跨账号模块**：需要在多个账号中同时创建资源（如 DNS 配置 + 应用部署）
+
+`cross-account.json` 作为信号标记，区分这两类模块。
+
+## How It Works
+
+```
+module-directory/
+├── main.tf
+├── variables.tf
+├── outputs.tf
+└── cross-account.json  ← 标记文件（Jenkins 检测此文件）
+```
+
+1. **Jenkins 扫描**：Jenkins 在检测模块时，检查目录中是否存在 `cross-account.json`
+2. **识别类型**：存在 → 触发跨账号部署流程；不存在 → 标准单账号流程
+3. **调用 EDR**：触发 [[ECS-Deploy-Runner]] 执行跨账号 Terraform 操作
+
+## Content Example
+
+`cross-account.json` 通常可以为空文件（文件名本身即标记），或包含简单配置：
+
+```json
+{
+  "description": "This module deploys resources across multiple accounts",
+  "target_accounts": ["InfoBlocks", "Workload"],
+  "execution_order": ["InfoBlocks", "Workload"]
+}
+```
+
+## Relationships
+
+- [[Jenkins]] ← detects ← [[cross-account.json]]
+- [[ECS-Deploy-Runner]] ← triggered_by ← [[cross-account.json]]
+- [[Cross-account-Terraform-Modules]] ← signaled_by ← [[cross-account.json]]
+
+## Related Concepts
+
+- [[CI/CD Pipeline]]：Jenkins 是 CI/CD 流水线的大脑，通过此标记决定执行路径
+- [[Cross-account-Terraform-Modules]]：该标记是跨账号 Terraform 模块的识别机制
+- [[Marker-Pattern]]：约定优于配置（Convention over Configuration）的典型应用