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

2026-04-20 00:02:56 +08:00
parent 8341ee6cc4
commit 6ab2838935
104 changed files with 4077 additions and 31 deletions
--- a/wiki/concepts/AI.md
+++ b/wiki/concepts/AI.md
@@ -0,0 +1,25 @@
+---
+title: "AI"
+type: concept
+tags: [technology, intelligence]
+sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
+last_updated: 2024-02-06
+---
+
+## Summary
+AI（人工智能）是复制需要人类智能才能完成的任务的系统，是计算机科学的一个分支。
+
+## Definition
+Artificial Intelligence (AI) 是指能够复制以前需要人类智能才能完成的任务的系统，通常通过机器学习寻求概率性结果。
+
+## Key Attributes
+- **类型**：技术/计算机科学
+- **子领域**：机器学习、深度学习、自然语言处理、计算机视觉
+- **核心方法**：监督学习、无监督学习、强化学习
+- **应用**：分类 AI、预测 AI、生成式 AI
+
+## Connections
+- [[AI]] ← includes ← [[Machine Learning]]
+- [[AI]] ← includes ← [[Generative AI]]
+- [[AWS]] ← provides ← [[AI]]
+- [[Foundation Model]] ← powers ← [[AI]]
--- a/wiki/concepts/API-Gateway.md
+++ b/wiki/concepts/API-Gateway.md
@@ -0,0 +1,41 @@
+---
+title: "API Gateway"
+type: concept
+tags:
+  - AWS
+  - Serverless
+  - API
+  - Gateway
+date: 2024-09-03
+---
+
+## Definition
+API Gateway 是 AWS 托管服务，用于创建、发布、维护和保护 API。作为 API 的前端入口，将请求路由到后端服务（如 Lambda、EC2），并处理认证、限流、监控等功能。
+
+## Endpoint Types
+- **Edge-optimized（边缘优化）**：
+  - 通过 CloudFront CDN 分发
+  - 降低延迟
+  - 适合全球访问
+
+- **Regional（区域）**：
+  - 同区域部署
+  - 更低延迟
+  - 适合同区域客户端
+
+- **Private（私有）**：
+  - 仅 VPC 内部访问
+  - 通过 VPC 端点访问
+  - 适合内部服务
+
+## Key Features
+- 请求验证：验证 API 密钥、JWT、IAM
+- 速率限制：防止 API 滥用
+- 缓存：减少后端调用
+- 监控：CloudWatch 集成
+- 自定义域名：绑定自有域名
+- API 版本管理：v1、v2 版本控制
+
+## Aliases
+- Amazon API Gateway
+- API Gateway
--- a/wiki/concepts/Amazon-Bedrock.md
+++ b/wiki/concepts/Amazon-Bedrock.md
@@ -0,0 +1,26 @@
+---
+title: "Amazon Bedrock"
+type: concept
+tags: [AWS, AI, generative-AI]
+sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
+last_updated: 2024-02-06
+---
+
+## Summary
+Amazon Bedrock 是 AWS 提供的全托管服务，用于使用基础模型构建和扩展生成式 AI 应用。
+
+## Definition
+Amazon Bedrock 是 AWS 的全托管服务，允许客户访问和定制强大的基础模型 (Foundation Models)，包括 Amazon Titan 和第三方模型，无需管理底层基础设施。
+
+## Key Attributes
+- **类型**：AWS AI/ML 服务
+- **核心功能**：基础模型访问、微调、持续预训练、RAG、Agents
+- **数据安全**：数据仅在请求响应周期存储
+- **定制方法**：Fine-tuning、Continued Pre-training
+
+## Connections
+- [[AWS]] ← provides ← [[Amazon Bedrock]]
+- [[Amazon Bedrock]] ← hosts ← [[Foundation Model]]
+- [[Amazon Bedrock]] ← implements ← [[RAG]]
+- [[Amazon Bedrock]] ← uses ← [[Agents]]
+- [[Generative AI]] ← powered_by ← [[Amazon Bedrock]]
--- a/wiki/concepts/Budget-Control.md
+++ b/wiki/concepts/Budget-Control.md
@@ -0,0 +1,39 @@
+---
+title: "Budget Control"
+type: concept
+tags: []
+sources: [Public-Cloud-Learning-Sessions-Budget-Control]
+last_updated: 2024-03-19
+---
+
+## Aliases
+- AWS Budget Control
+- 预算控制自动化
+
+## Definition
+AWS账户预算控制自动化系统，提供账户所有者详细的支出警报和成本分析报告，实现成本控制。
+
+## Mechanism
+- 警报类型：forecast（预测）、actual（实际）、severe（严重）、enforcement（强制执行）四级
+- 评估间隔：8小时
+- 执行机制：100%阈值触发SCP阻止新资源创建
+- 评分系统：考虑账户规模和月末时间，避免惩罚月末轻微超支的账户
+
+## Components
+- AWS Budget Alerts：触发SNS主题
+- Lambda：解析邮件数据，创建详细消息
+- Step Functions：丰富账户信息、预算详情、联系人数据
+- SCP：Service Control Policy，限制AWS服务使用
+
+## Reports
+- Top Services Report：展示月度服务成本占比（基于Athena数据）
+- Top Users Report：展示每日用户支出（基于Cost Explorer数据）
+- Detailed Excel Report：资源级别的成本明细（资源ID、创建者、成本）
+
+## Related
+- [[FinOps Team]]
+- [[SRE Core Team]]
+- [[Public Cloud Learning Sessions - Budget Control - 20240319]]
+- [[SCP]]
+- [[Source Identity]]
+- [[AWS]]
--- a/wiki/concepts/Cloud-Health.md
+++ b/wiki/concepts/Cloud-Health.md
@@ -0,0 +1,33 @@
+---
+title: "Cloud Health"
+type: concept
+tags:
+  - FinOps
+  - AWS
+  - Cost-Monitoring
+date: 2026-04-19
+---
+
+## Summary
+- 定义：云成本分析和监控工具，由 CloudHealth Technologies 开发，后被 VMware 收购
+- 用途：提供资源清单、成本分析和月度账单洞察
+- 价值：帮助企业实现云成本可视化、优化资源使用
+
+## Aliases
+- AWS CloudHealth
+- VMware CloudHealth
+
+## Key Features
+- 资源清单管理
+- 成本分析报告
+- 月度账单洞察
+- 优化建议生成
+- 多云支持
+
+## Connections
+- [[PCG-Team]] — 使用 Cloud Health 进行成本监控
+- [[Cost-Optimization]] — 提供优化建议
+
+---
+
+*最后更新: 2026-04-19*
--- a/wiki/concepts/Cross-Account-Event-Forwarding.md
+++ b/wiki/concepts/Cross-Account-Event-Forwarding.md
@@ -0,0 +1,37 @@
+---
+title: Cross-Account Event Forwarding
+type: concept
+tags: [aws, eventbridge, multi-account, event-driven]
+date: 2026-04-19
+---
+
+## 定义
+
+跨账号事件转发（Cross-Account Event Forwarding）是指通过 Amazon EventBridge 将一个 AWS 账号中的事件路由到另一个 AWS 账号的机制。该机制允许组织在多账号架构中实现集中式事件管理。
+
+## 核心机制
+
+- **自定义事件总线**：在管理账号创建自定义事件总线，配置跨账号权限策略
+- **PutEvents API**：源账号通过 PutEvents API 将事件发送到目标账号的事件总线
+- **事件规则**：目标账号通过事件规则过滤和处理接收的事件
+
+## 组件
+
+- **Event Bus**：事件总线，事件的入口点
+- **Event Rule**：事件规则，用于过滤和路由事件
+- **Permission Policy**：事件总线的跨账号权限策略
+
+## 应用场景
+
+- **集中日志收集**：将多个账号的 CloudFormation 事件转发到管理账号
+- **集中告警**：跨账号统一告警通知
+- **安全事件集中**：安全相关事件集中到 SOC 账号
+
+## 与集中式日志的关系
+
+跨账号事件转发是实现集中式日志的关键技术基础。通过 EventBridge 将分散在各账号的事件汇聚到中央存储位置（如 CloudWatch Logs 或 OpenSearch），实现统一监控和查询。
+
+## Connections
+- [[EventBridge]] ← implements ← [[Cross-Account Event Forwarding]]
+- [[Centralized Logging]] ← depends_on ← [[Cross-Account Event Forwarding]]
+- [[Multi-Account Strategy]] ← enables ← [[Cross-Account Event Forwarding]]
--- a/wiki/concepts/Declarative-Configuration.md
+++ b/wiki/concepts/Declarative-Configuration.md
@@ -0,0 +1,30 @@
+---
+title: "Declarative Configuration"
+type: concept
+tags: [DevOps, GitOps, 配置管理]
+sources: [ctp-topic-33-an-introduction-to-gitops.md]
+last_updated: 2026-04-19
+---
+
+## Definition
+Declarative Configuration（声明式配置）是一种配置管理方法，通过描述系统的期望状态（what）而非具体步骤（how）来定义基础设施和应用配置。
+
+## Key Characteristics
+- 定义期望的结果状态，而非实现步骤
+- 工具负责计算如何达到期望状态
+- 幂等性：多次应用产生相同结果
+- 易于理解和版本控制
+
+## Examples
+- Kubernetes YAML 配置
+- Terraform HCL 配置
+- Docker Compose 配置
+- Ansible Playbook
+
+## Related Concepts
+- [[Infrastructure as Code (IaC)]]
+- [[GitOps]]
+- [[Idempotent Operation]]（幂等操作）
+
+## Related Sources
+- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
--- a/wiki/concepts/Demand-Management.md
+++ b/wiki/concepts/Demand-Management.md
@@ -0,0 +1,26 @@
+---
+title: "Demand Management"
+type: concept
+tags: [ITSM, Cloud, FinOps]
+---
+
+## Definition
+需求管理是一种平衡用户请求与可用容量的业务流程，确保组织能够有效地管理和分配资源。
+
+## Context
+在云资源管理的背景下，需求管理用于平衡对超大规模云服务商（如 AWS、Azure、GCP）的资源请求与组织可用的计算、存储和网络容量。Oli 工作流通过三阶段审批流程实现需求管理：可行性验证、技术可行性验证和预算可用性验证。
+
+## Key Points
+- 请求方负责推动其工作流获得批准
+- 审批流程包括：发起人、请求者经理、M5、实验室服务总监、基础设施 M5、云服务基础设施、云服务、最终审批（Shannon 或 MUI）
+- 机器应执行机器能做的事，实现自动化处理
+- 目标是让业务部门 80% 的时间能够自主选择所需服务
+
+## Related Concepts
+- [[ITIL Framework]]
+- [[Service Catalog]]
+- [[Workflow Process]]
+
+## Related Entities
+- [[FinOps Team]]
+- [[FPNA Team]]
--- a/wiki/concepts/EBS-GP3.md
+++ b/wiki/concepts/EBS-GP3.md
@@ -0,0 +1,40 @@
+---
+title: "EBS GP3"
+type: concept
+tags: [AWS, EBS, Storage, Cost-Optimization]
+sources: []
+last_updated: 2026-04-19
+---
+
+## Definition
+EBS GP3（General Purpose SSD 第3代）是 AWS EBS 的一种卷类型，推荐作为通用型 SSD 的默认选择，成本比 GP2 低 20%，且可独立扩展 IOPS 和吞吐量。
+
+## Key Features
+- **成本节省**：比 GP2 便宜约 20%
+- **独立扩展**：IOPS 和吞吐量可独立于卷大小进行扩展
+- **高 IOPS**：最大 16,000 IOPS（最高配置）
+- **高吞吐量**：最大 1,000 MB/s（最高配置）
+
+## Specifications
+| 属性 | GP3 默认 | GP3 最大 |
+|------|---------|---------|
+| 卷大小 | 1 GiB - 16 TiB | 1 GiB - 16 TiB |
+| IOPS | 3,000 | 16,000 |
+| 吞吐量 | 125 MB/s | 1,000 MB/s |
+
+## Use Cases
+- 数据库工作负载
+- 虚拟化桌面
+- 应用服务器
+- 开发测试环境
+- 企业应用
+
+## Migration from GP2
+- 自动化工具应更新为默认创建 GP3 卷
+- GP2 迁移到 GP3 可立即节省成本
+- 无需停机即可完成迁移
+
+## Connections
+- [[EBS-GP2]] ← improves ← [[EBS-GP3]]
+- [[EBS-Snapshot-Archive]] ← uses ← [[EBS]]
+- [[AWS]] ← provides ← [[EBS-GP3]]
--- a/wiki/concepts/EBS-Snapshot-Archive.md
+++ b/wiki/concepts/EBS-Snapshot-Archive.md
@@ -0,0 +1,53 @@
+---
+title: "EBS Snapshot Archive"
+type: concept
+tags: [AWS, EBS, Snapshot, Storage, Cost-Optimization]
+sources: []
+last_updated: 2026-04-19
+---
+
+## Definition
+EBS Snapshot Archive（EBS 快照归档层）是 AWS EBS 快照的长期存储层，成本比标准快照层低 75%，适合很少需要访问的快照，但恢复时间更长且需保留 90 天。
+
+## Key Features
+- **成本节省**：比标准快照层低约 75%
+- **长期保留**：最短保留期限 90 天
+- **恢复时间**：需要 24-72 小时恢复可用
+- **自动化管理**：通过 Data Lifecycle Manager (DLM) 或 AWS Backup 管理
+
+## Pricing Comparison
+| 存储类型 | 价格（每 GB/月） |
+|---------|----------------|
+| 标准快照 | $0.05 |
+| 归档快照 | $0.0125 |
+
+## Use Cases
+- 长期合规性快照备份
+- 灾难恢复基础镜像
+- 软件发布版本镜像
+- 历史数据存档
+
+## Implementation
+通过 DLM 创建生命周期策略：
+```json
+{
+  "LifecyclePolicy": {
+    "TargetTags": ["Backup"],
+    "PolicyRules": [
+      {
+        "RuleName": "Archive",
+        "CopyTags": true,
+        "TransitionToArchive": {
+          "DaysAfterCreation": 90
+        },
+        "RetainUntilExpiration": false
+      }
+    ]
+  }
+}
+```
+
+## Connections
+- [[EBS-GP3]] ← uses ← [[EBS]]
+- [[Lifecycle-Policy]] → implements → [[EBS-Snapshot-Archive]]
+- [[AWS]] ← provides ← [[EBS-Snapshot-Archive]]
--- a/wiki/concepts/EC2-Spot-Instances.md
+++ b/wiki/concepts/EC2-Spot-Instances.md
@@ -0,0 +1,46 @@
+---
+title: "EC2 Spot Instances"
+type: concept
+tags:
+  - AWS
+  - EC2
+  - Cost-Optimization
+  - Spot
+sources: []
+last_updated: 2026-04-19
+---
+
+## Definition
+EC2 Spot Instances 是 AWS 提供的一种利用闲置计算容量的实例类型，相比按需定价最高可节省 90% 成本。
+
+## Key Characteristics
+- 利用 AWS 数据中心的闲置容量
+- 相比按需实例最高可享 90% 折扣
+- 当 AWS 需要回收容量时可能会被中断
+- 提供中断前通知机制
+- 支持与 Auto Scaling、EKS、ECS 集成
+
+## Use Cases
+- Web 服务（具备容错能力）
+- 容器化工作负载
+- 高性能计算批处理
+- 大数据分析
+- CI/CD 流水线
+
+## Key Considerations
+- **容错能力**：应用需能处理实例中断
+- **灵活性**：支持跨多个实例类型和可用区
+- **无状态**：适合无状态工作负载
+- **中断风险**：AWS 提前 2 分钟通知回收
+
+## Best Practices
+- 跨实例类型和可用区分散部署
+- 配置自动响应中断的机制
+- 结合 Graviton 使用进一步优化成本
+
+## Connections
+- [[AWS]] ← provides ← [[EC2-Spot-Instances]]
+- [[Cost-Optimization]] ← achieved_by ← [[EC2-Spot-Instances]]
+- [[Spot-Interruption]] ← risk_of ← [[EC2-Spot-Instances]]
+- [[EKS]] ← supports ← [[EC2-Spot-Instances]]
+- [[ECS]] ← supports ← [[EC2-Spot-Instances]]
--- a/wiki/concepts/EFS-Infrequent-Access.md
+++ b/wiki/concepts/EFS-Infrequent-Access.md
@@ -0,0 +1,43 @@
+---
+title: "EFS Infrequent Access"
+type: concept
+tags: [AWS, EFS, Storage, Cost-Optimization]
+sources: []
+last_updated: 2026-04-19
+---
+
+## Definition
+EFS Infrequent Access（EFS 不频繁访问层）是 AWS EFS 的一种存储层，适合很少访问的文件，通过生命周期策略自动将冷文件移动到低成本的存储层。
+
+## Key Features
+- **成本节省**：比标准层低约 85%
+- **自动分层**：通过生命周期策略自动转移
+- **即时访问**：访问不频繁访问层数据时自动移回标准层
+- **最小计费对象**：128KB 以下文件不计费
+
+## Pricing
+| 存储类型 | 价格（每 GB/月） |
+|---------|----------------|
+| 标准层 | $0.30 |
+| 不频繁访问层 | $0.045 |
+
+## Lifecycle Policy
+```json
+{
+  "LifecyclePolicies": [
+    {
+      "TransitionToIA": "After 30 days of last access"
+    }
+  ]
+}
+```
+
+## Considerations
+- **最小计费对象大小**：128KB 以下文件计费为 128KB
+- **访问成本**：检索数据时有额外的访问费用
+- **适合场景**：日志文件、备份文件、归档数据
+
+## Connections
+- [[EFS-Standard]] ← extends ← [[EFS]]
+- [[Lifecycle-Policy]] → implements → [[EFS-Infrequent-Access]]
+- [[AWS]] ← provides ← [[EFS-Infrequent-Access]]
--- a/wiki/concepts/Event-Driven-Architecture.md
+++ b/wiki/concepts/Event-Driven-Architecture.md
@@ -0,0 +1,35 @@
+---
+title: "Event-Driven Architecture"
+type: concept
+tags: [Architecture, Event-Driven, Async, Serverless]
+sources: []
+last_updated: 2026-04-19
+---
+
+## Summary
+事件驱动架构是一种以事件为核心驱动系统行为的架构模式，实现服务间松耦合。
+
+## Definition
+Event-Driven Architecture（EDA）是一种软件架构范式，组件之间通过事件（状态变化或动作）进行通信和解耦。
+
+## Core Characteristics
+- **异步通信**：事件生产者与消费者基于事件解耦
+- **事件驱动**：行为由事件触发，而非直接调用
+- **松耦合**：事件生产者不关心消费者实现
+- **可扩展性**：易于扩展新事件消费者
+
+## Use Cases
+- 实时数据处理
+- 微服务异步通信
+- 物联网数据采集
+- 实时工作流触发
+
+## Related Services
+- [[EventBridge]]：AWS 事件总线
+- [[Amazon SQS]]：消息队列
+- [[Amazon SNS]]：发布/订阅通知
+- [[Lambda]]：事件目标
+
+## Related Patterns
+- [[Message Queue]]：消息队列模式
+- [[Pub/Sub]]：发布/订阅模式
--- a/wiki/concepts/FSx-for-NetApp-ONTAP.md
+++ b/wiki/concepts/FSx-for-NetApp-ONTAP.md
@@ -0,0 +1,45 @@
+---
+title: "FSx for NetApp ONTAP"
+type: concept
+tags: [AWS, FSx, NetApp, Storage, Cost-Optimization]
+sources: []
+last_updated: 2026-04-19
+---
+
+## Definition
+FSx for NetApp ONTAP 是 AWS 提供的托管 NetApp ONTAP 文件系统服务，支持自动分层功能，可在 SSD 和 HDD 容量池之间自动移动数据以优化成本。
+
+## Key Features
+- **自动分层**：在 SSD 和 HDD 容量池之间自动移动数据
+- **数据去重**：内置重复数据删除功能
+- **压缩**：支持数据压缩减少存储空间
+- **NetApp 兼容性**：与 ONTAP 原生协议兼容
+- **成本优化**：相比 EBS 可节省高达 60% 成本
+
+## Architecture
+- **SSD 存储池**：高性能层，存储活跃数据
+- **HDD 容量池**：低成本层，存储冷数据
+- **自动迁移**：根据策略自动在层级之间移动数据
+
+## Use Cases
+- 企业文件共享
+- 数据库存储
+- 媒体处理
+- 软件开发环境
+- 数据归档
+
+## Pricing
+- SSD 存储：$0.08/GB/月
+- HDD 容量池：$0.02/GB/月
+- 数据传输：标准 AWS 数据Transfer rates
+
+## Migration Example
+ADM 公司通过多次迁移最终选择 FSx for NetApp ONTAP：
+1. 初始迁移到 OpenZFS：成本高
+2. 自托管 NetApp on EC2：高数据传输成本
+3. 迁移到 FSx for NetApp ONTAP：**成本降低 60%**
+
+## Connections
+- [[AWS-FSx]] ← extends ← [[FSx-for-NetApp-ONTAP]]
+- [[NetApp]] ← provides ← [[FSx-for-NetApp-ONTAP]]
+- [[AD]] ← migrated_to ← [[FSx-for-NetApp-ONTAP]]
--- a/wiki/concepts/Fan-out-Pattern.md
+++ b/wiki/concepts/Fan-out-Pattern.md
@@ -0,0 +1,25 @@
+---
+title: "Fan-out Pattern"
+type: concept
+tags:
+  - Messaging
+  - EDA
+  - Architecture
+date: 2026-04-19
+---
+
+## Definition
+Fan-out Pattern（扇出模式）是一种消息传递模式，一个事件可以同时分发给多个消费者。当一个事件需要触发多个独立的处理流程时，扇出模式可以高效实现一对多的通知机制。
+
+## Implementation
+- **SNS Topic**：发布/订阅模式，一个消息发布到主题，多个订阅者接收
+- **EventBridge Rule**：基于规则将事件路由到多个目标
+
+## Use Cases
+- 单个订单创建事件触发：库存更新、通知发送、数据分析、财务处理等多个独立流程
+- 用户注册事件触发：欢迎邮件、积分奖励、偏好初始化等多个独立业务逻辑
+
+## Relationship
+- [[Event-Driven Architecture]] ← uses ← [[Fan-out Pattern]]
+- [[Fan-out Pattern]] ← implemented_by ← [[Amazon SNS]]
+- [[Fan-out Pattern]] ← implemented_by ← [[EventBridge]]
--- a/wiki/concepts/Foundation-Model.md
+++ b/wiki/concepts/Foundation-Model.md
@@ -0,0 +1,26 @@
+---
+title: "Foundation Model"
+type: concept
+tags: [AI, generative-AI, ML]
+sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
+last_updated: 2024-02-06
+---
+
+## Summary
+基础模型是具有数十亿参数的大规模预训练模型，能够执行多种任务，是生成式 AI 的核心。
+
+## Definition
+Foundation Model（基础模型）是经过大规模预训练的大语言模型，具备零样本和少样本学习能力，可通过微调适应各种下游任务。
+
+## Key Attributes
+- **参数规模**：数十亿参数
+- **训练方式**：大规模预训练
+- **特点**：零样本学习、少样本学习、多任务能力
+- **代表模型**：Amazon Titan、GPT-4、Claude、Llama
+
+## Connections
+- [[AI]] ← powers ← [[Foundation Model]]
+- [[Generative AI]] ← powered_by ← [[Foundation Model]]
+- [[Amazon Bedrock]] ← hosts ← [[Foundation Model]]
+- [[Foundation Model]] ← supports ← [[Fine-Tuning]]
+- [[Foundation Model]] ← supports ← [[RAG]]
--- a/wiki/concepts/Generative-AI.md
+++ b/wiki/concepts/Generative-AI.md
@@ -31,4 +31,6 @@ Generative AI（生成式 AI）是指能够根据学习到的模式和数据创

 ## Connections
 - [[Agentic AI]] ← 区别于 ← Generative AI：核心用途不同
- [[LLM]] ← powers ← Generative AI：大语言模型是 GenAI 的技术基础
+- [[LLM]] ← powers ← Generative AI：大语言模型是 GenAI 的技术基础
+- [[Foundation Model]] ← powers ← Generative AI：基础模型是生成式 AI 的核心
+- [[Amazon Bedrock]] ← provides ← Generative AI：AWS 提供 Bedrock 服务
--- a/wiki/concepts/Git.md
+++ b/wiki/concepts/Git.md
@@ -0,0 +1,38 @@
+---
+title: "Git"
+type: concept
+tags: [Git, VCS, 版本控制, DevOps]
+sources: [ctp-topic-2-git.md]
+last_updated: 2026-04-19
+---
+
+## Definition
+Git（分布式版本控制系统）是一种开源的分布式版本控制系统，用于跟踪代码变更、支持多人协作开发。每个开发人员都拥有完整的代码仓库副本，支持离线工作、分支合并和历史追溯。
+
+## Core Features
+- 分布式架构：每个用户拥有完整仓库副本
+- 分支管理：支持轻量级分支和快速合并
+- 完整性保证：使用 SHA-1 哈希确保数据完整性
+- 性能：本地操作极快，网络操作按需拉取
+
+## Common Commands
+- `git clone`：克隆远程仓库
+- `git add` / `git commit`：暂存和提交更改
+- `git push` / `git pull`：推送和拉取远程更改
+- `git branch` / `git checkout`：分支管理
+- `git merge` / `git rebase`：合并分支
+
+## Related Concepts
+- [[Infrastructure as Code (IaC)]]
+- [[CI/CD 流水线]]
+- [[GitOps]]
+
+## Related Entities
+- [[GitHub]]
+- [[GitLab]]
+- [[Gitea]]
+
+## Aliases
+- Git
+- Git 版本控制
+- 分布式版本控制
--- a/wiki/concepts/GitOps.md
+++ b/wiki/concepts/GitOps.md
@@ -2,20 +2,52 @@
 title: "GitOps"
 type: concept
 tags: [DevOps, Git, 基础设施, 部署]
-sources: [DevOps-Culture-and-Transformation.md]
-last_updated: 2025-03-02
+sources: [DevOps-Culture-and-Transformation.md, ctp-topic-33-an-introduction-to-gitops.md]
+last_updated: 2026-04-19
 ---

 ## Definition
-GitOps 是一种使用 Git 作为单一真相源（Single Source of Truth）来管理基础设施和部署的文化理念和运维框架，所有配置和部署声明都存储在 Git 仓库中。
+GitOps 是一种使用 Git 作为单一真相源（Single Source of Truth）来管理基础设施和部署的文化理念和运维框架，所有配置和部署声明都存储在 Git 仓库中。它是 DevOps 的逻辑演进，将软件开发原则应用于部署流程。

-## Key Principles（关键原则）
- 声明式基础设施
- Git 作为单一真相源
- 自动同步和部署
- 可审计和可回滚
+## Key Principles（四大原则）
+1. **Declarative Configuration**（声明式配置）：系统以声明形式定义，描述期望状态而非具体步骤
+2. **Version Control**（版本控制）：所有配置存储在 Git 中，实现版本管理和审计追踪
+3. **CD Process Separation**（CD 流程分离）：CI 和 CD 解耦以增强安全性
+4. **Incremental Infrastructure**（增量基础设施）：渐进式实施基础设施变更

-## Related Concepts
- [[DevOps 文化]]
- [[Infrastructure as Code (IaC)]]
+## Core Benefits（核心优势）
+- 使用开发者熟悉的工具提升开发生产力
+- 通过轻松的回滚能力最小化失败部署
+- 支持更快的功能发布
+- 通过 Git 特性实现实时审计和改进安全性
+
+## Key Components（核心组件）
+- **Git**：存储部署基础设施和应用配置，作为唯一真相源
+- **GitOps Controller**：协调 Git 状态与实际系统状态的代理
+- **CD Pipeline**：自动化部署流程
+- **Infrastructure as Code**：通过代码管理基础设施
+
+## Implementation Models（实现模型）
+- **Pull Model**（拉取模型）：GitOps 推荐模型，监控 Git 和目标系统，自动同步变更
+- **Push Model**（推送模型）：传统 CI/CD 部署模式，通过触发器推送变更
+
+## Kubernetes Workflow
+1. 开发者提交代码
+2. 创建容器镜像
+3. 将部署配置存储在 Git 中
+4. GitOps Agent 监控变化
+5. 向环境推出镜像
+
+## Key Concepts
+- [[Declarative Configuration]]（声明式配置）
+- [[Infrastructure as Code (IaC)]]（基础设施即代码）
 - [[CI/CD 流水线]]
+- [[Pull Model]]（拉取模型）
+- [[Idempotent Operation]]（幂等操作）
+
+## Related Entities
+- [[Victor Etkin]] — GitOps 概念的演讲者和布道者
+
+## Related Sources
+- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
+- [[DevOps-Culture-and-Transformation]] — DevOps 文化转型
--- a/wiki/concepts/ITIL-Framework.md
+++ b/wiki/concepts/ITIL-Framework.md
@@ -0,0 +1,21 @@
+---
+title: "ITIL Framework"
+type: concept
+tags: [ITSM, Service-Management]
+---
+
+## Definition
+ITIL（Information Technology Infrastructure Library）是一个广泛使用的 IT 服务管理框架，将业务流程分为五个核心阶段：服务战略（Service Strategy）、服务设计（Service Design）、服务转换（Service Transition）、服务运营（Service Operation）和持续改进（Continual Improvement）。
+
+## Context
+在 Oli 工作流流程中，ITIL 框架提供了需求管理的理论支撑。审批流程是请求处理的第一阶段，之后是需求管理和定义工作。云资源请求的完整端到端流程包括：审批阶段、需求管理和定义工作。
+
+## Key Points
+- 审批流程是请求处理的第一阶段
+- 服务目录正在开发中，将合并云产品的标准化清单
+- 目标是简化业务部门从目录中识别和请求服务的过程
+
+## Related Concepts
+- [[Demand Management]]
+- [[Service Catalog]]
+- [[Workflow Process]]
--- a/wiki/concepts/Idempotent-Operation.md
+++ b/wiki/concepts/Idempotent-Operation.md
@@ -0,0 +1,34 @@
+---
+title: "Idempotent Operation"
+type: concept
+tags: [DevOps, GitOps, 基础概念]
+sources: [ctp-topic-33-an-introduction-to-gitops.md]
+last_updated: 2026-04-19
+---
+
+## Definition
+Idempotent Operation（幂等操作）是指可以多次执行而不会改变超出初始应用结果的操作。无论执行多少次，最终状态都与执行一次相同。
+
+## Examples
+- Kubernetes 部署：多次 apply 相同配置不会导致重复创建
+- Terraform apply：重复执行会产生相同的基础设施状态
+- 文件权限设置：重复 chmod 相同权限
+- 数据库 UPSERT：重复插入或更新
+
+## Non-Idempotent Examples
+- `curl` 请求：每次执行都会创建新资源
+- 计数器递增：每次执行都会改变值
+- 文件追加：重复执行会累积内容
+
+## Importance in GitOps
+- 确保部署过程可重复执行
+- 支持自动重试和恢复
+- 简化故障处理和调试
+
+## Related Concepts
+- [[GitOps]]
+- [[Declarative Configuration]]
+- [[Infrastructure as Code (IaC)]]
+
+## Related Sources
+- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
--- a/wiki/concepts/Infrastructure-as-Code-IaC.md
+++ b/wiki/concepts/Infrastructure-as-Code-IaC.md
@@ -2,8 +2,8 @@
 title: "Infrastructure as Code (IaC)"
 type: concept
 tags: [DevOps, 基础设施, 自动化, 版本控制]
-sources: [DevOps-Culture-and-Transformation.md]
-last_updated: 2025-03-02
+sources: [DevOps-Culture-and-Transformation.md, ctp-topic-33-an-introduction-to-gitops.md]
+last_updated: 2026-04-19
 ---

 ## Definition
@@ -18,3 +18,5 @@ last_updated: 2025-03-02
 - [[DevOps 文化]]
 - [[CI/CD 流水线]]
 - [[GitOps]]
+- [[Declarative Configuration]]
+- [[Idempotent Operation]]
--- a/wiki/concepts/Instance-Scheduling.md
+++ b/wiki/concepts/Instance-Scheduling.md
@@ -0,0 +1,40 @@
+---
+title: "Instance Scheduling"
+type: concept
+tags:
+  - FinOps
+  - Cost-Optimization
+  - Automation
+date: 2026-04-19
+---
+
+## Aliases
+- Instance Scheduler
+- EC2 Scheduling
+- RDS Scheduling
+- 定时启停
+
+## Definition
+通过预设时间规则自动控制 EC2 和 RDS 实例启停的技术，实现非生产环境成本优化。
+
+## Mechanism
+- 基于 CloudWatch Events 定时触发
+- Lambda 读取 DynamoDB 配置表中的调度规则
+- 根据实例标签（Schedule、Period）执行启停操作
+- 支持时区配置和自定义工作时间
+
+## Use Cases
+- 开发/测试环境非工作时间自动关机
+- 按地区办公时间配置调度
+- 强制维护窗口配合（RDS）
+- Override 状态强制保持停机
+
+## Related Entities
+- [[AWS Instance Scheduler]]
+- [[CloudWatch Events]]
+- [[DynamoDB Config Table]]
+
+## Related Concepts
+- [[Cost Optimization]]
+- [[Right Sizing]]
+- [[Workload Optimization]]
--- a/wiki/concepts/Lambda.md
+++ b/wiki/concepts/Lambda.md
@@ -0,0 +1,35 @@
+---
+title: "Lambda"
+type: concept
+tags:
+  - AWS
+  - Serverless
+  - Compute
+  - Cloud-Native
+date: 2024-09-03
+---
+
+## Definition
+AWS Lambda 是无服务器（Serverless）计算服务，开发者只需编写业务逻辑代码，AWS 自动处理服务器配置、扩展和运维。Lambda 函数由事件触发，当事件发生时执行相应的代码。
+
+## Core Characteristics
+- 事件驱动：Lambda 函数由状态变化（事件）触发
+- 按需付费：按请求数和执行时长计费
+- 自动扩展：AWS 自动处理负载均衡和扩展
+- 支持语言：Node.js、Python、Java、C#、Go、Ruby 等
+
+## Invocation Types
+- 同步调用：调用者等待响应
+- 异步调用：事件进入队列后立即返回
+- 事件源映射：根据流或队列事件触发
+
+## Management Features
+- 版本控制：发布代码快照，通过别名指向特定版本
+- 别名：指向特定版本的指针，支持蓝绿部署
+- Layers：共享公共代码库
+- 并发控制：设置函数并发上限
+
+## Aliases
+- AWS Lambda
+- Lambda 函数
+- Lambda Function
--- a/wiki/concepts/Lifecycle-Policy.md
+++ b/wiki/concepts/Lifecycle-Policy.md
@@ -0,0 +1,43 @@
+---
+title: "Lifecycle Policy"
+type: concept
+tags: [AWS, Storage, Cost-Optimization]
+sources: []
+last_updated: 2026-04-19
+---
+
+## Definition
+生命周期策略是一种自动化规则，用于在不同存储层之间自动转换数据、设置保留策略和管理过期对象，无需手动操作。
+
+## Key Features
+- 自动存储层转换：根据预设规则将数据从热存储移动到冷存储
+- 保留策略：设置快照和对象的保留期限
+- 过期清理：自动删除过期对象和不完整的分段上传
+- 成本优化：减少存储费用，优化存储支出
+
+## AWS Services
+- **S3 Lifecycle Policies**：转换对象到 S3 Standard → Intelligent-Tiering → Glacier 层级
+- **EFS Lifecycle Policies**：将文件在标准层和不频繁访问层之间移动
+- **EBS Snapshot Lifecycle**：归档快照到 Archive 层，使用 DLM 或 AWS Backup
+
+## Implementation
+```json
+{
+  "Rules": [
+    {
+      "ID": "MoveToGlacier",
+      "Status": "Enabled",
+      "Filter": {"Prefix": "archive/"},
+      "Transitions": [
+        {"Days": 365, "StorageClass": "GLACIER"}
+      ],
+      "Expiration": {"Days": 1825}
+    }
+  ]
+}
+```
+
+## Connections
+- [[S3-Intelligent-Tiering]] ← implements ← [[Lifecycle-Policy]]
+- [[EFS-Inrequent-Access]] ← implements ← [[Lifecycle-Policy]]
+- [[EBS-Snapshot-Archive]] ← uses ← [[Lifecycle-Policy]]
--- a/wiki/concepts/ML-Ops.md
+++ b/wiki/concepts/ML-Ops.md
@@ -0,0 +1,23 @@
+---
+title: "ML Ops"
+type: concept
+tags: [DevOps, ML, operations]
+sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
+last_updated: 2024-02-06
+---
+
+## Summary
+ML Ops 结合机器学习和运营，涉及人员、技术和流程，以实现协作式 ML 解决方案。
+
+## Definition
+ML Ops (Machine Learning Operations) 是将 DevOps 原则应用于机器学习系统的实践，包括数据管道、训练管道和推理管道的自动化和监控。
+
+## Key Attributes
+- **核心组成**：数据管道、训练管道、推理管道
+- **关注点**：数据溯源、模型管理、部署工作流
+- **工具**：Amazon SageMaker、MLflow、Kubeflow
+
+## Connections
+- [[DevOps]] ← extends ← [[ML Ops]]
+- [[ML Ops]] ← manages ← [[Machine Learning]]
+- [[Amazon SageMaker]] ← implements ← [[ML Ops]]
--- a/wiki/concepts/Machine-Learning.md
+++ b/wiki/concepts/Machine-Learning.md
@@ -0,0 +1,24 @@
+---
+title: "Machine Learning"
+type: concept
+tags: [AI, data-science]
+sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
+last_updated: 2024-02-06
+---
+
+## Summary
+机器学习是 AI 的子领域，使用数据创建决策逻辑或模型，通过从数据中学习来改进预测和决策。
+
+## Definition
+Machine Learning (ML) 是人工智能的一个分支，通过算法从数据中学习，自动改进模型以进行预测或决策，无需明确编程。
+
+## Key Attributes
+- **类型**：AI 子领域
+- **核心方法**：监督学习、无监督学习、强化学习
+- **应用**：分类、预测、生成、推荐
+
+## Connections
+- [[AI]] ← is_parent_of ← [[Machine Learning]]
+- [[Machine Learning]] ← enables ← [[Generative AI]]
+- [[Amazon SageMaker]] ← hosts ← [[Machine Learning]]
+- [[Machine Learning]] ← implements ← [[RAG]]
--- a/wiki/concepts/Prompt-Engineering.md
+++ b/wiki/concepts/Prompt-Engineering.md
@@ -0,0 +1,32 @@
+---
+title: "Prompt Engineering"
+type: concept
+tags:
+  - AI
+  - Prompt-Engineering
+  - LLM
+date: 2024-11-12
+---
+
+## Summary
+提示词工程（Prompt Engineering）是创建、设计和优化提示词以引导大语言模型（LLM）响应的过程，确保输出的准确性和相关性。
+
+## Definition
+Prompt Engineering（提示词工程）是指通过精心设计提示词来提升 AI 输出质量的技术，涵盖需求拆解、结构化表达、场景共情、迭代优化四个维度。
+
+## Key Components
+提示词由以下组件构成：
+- **指令（Instructions）**：明确告诉模型要做什么
+- **上下文（Context）**：提供背景信息
+- **用户输入（User Input）**：具体问题或任务
+- **输出指示器（Output Indicator）**：提示模型输出格式
+
+## Basic Techniques
+- **One-shot Prompting**：提供一个示例
+- **Few-shot Prompting**：提供多个示例
+- **Chain of Thoughts**：提供逐步思考过程
+
+## Connections
+- [[LLM]] ← guides ← Prompt Engineering：提示词工程引导大语言模型
+- [[Generative AI]] ← uses ← Prompt Engineering：生成式 AI 应用提示词工程
+- [[Claude Skills]] ← relies_on ← Prompt Engineering：Claude Skills 基于提示词工程技术
--- a/wiki/concepts/Pull-Model.md
+++ b/wiki/concepts/Pull-Model.md
@@ -0,0 +1,38 @@
+---
+title: "Pull Model"
+type: concept
+tags: [DevOps, GitOps, CD, 部署]
+sources: [ctp-topic-33-an-introduction-to-gitops.md]
+last_updated: 2026-04-19
+---
+
+## Definition
+Pull Model（拉取模型）是 GitOps 推荐的一种持续交付实现模式，GitOps Agent 持续监控 Git 仓库和目标系统的状态，自动将 Git 中的期望状态同步到实际运行环境。
+
+## How It Works
+1. GitOps Agent 安装在目标环境（如 Kubernetes 集群）
+2. Agent 持续轮询 Git 仓库检测配置变化
+3. Agent 同时监控实际系统状态
+4. 当检测到差异时，自动将变更同步到目标系统
+
+## Advantages
+- 更安全：无需开放外部访问权限到集群
+- 更好的可见性：Agent 直接观察实际状态
+- 自我修复：自动纠正配置漂移
+- 简化网络架构：无需入站 webhook
+
+## Comparison with Push Model
+| 特性 | Pull Model | Push Model |
+|------|-----------|------------|
+| 触发方式 | Agent 主动拉取 | CI/CD 流水线推送 |
+| 部署位置 | Agent 运行在目标环境 | CI/CD 工具运行在外部 |
+| 安全性 | 更高，无需开放入站端口 | 需要开放 webhook 端口 |
+| 复杂度 | 较低（无外部依赖） | 较高（需要 CI/CD 集成） |
+
+## Related Concepts
+- [[GitOps]]
+- [[CI/CD 流水线]]
+- [[Idempotent Operation]]（幂等操作）
+
+## Related Sources
+- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
--- a/wiki/concepts/Rate-Optimization.md
+++ b/wiki/concepts/Rate-Optimization.md
@@ -0,0 +1,38 @@
+---
+title: "Rate Optimization"
+type: concept
+tags: [cloud, cost-management, AWS]
+sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]
+last_updated: 2026-04-19
+---
+
+## Summary
+Rate Optimization（费率优化）是通过承诺使用获取折扣的云成本优化策略。
+
+## Definition
+费率优化基于承诺使用期限（1-3年）获取折扣，分为资源级承诺（更高折扣但有限制）和灵活承诺（标准折扣但更灵活）。
+
+## AWS 费率优化工具
+- **Savings Plans**：EC2 Savings Plans、Compute Savings Plans
+- **Reserved Instances**：RDS、ElastiCache、CloudFront 等服务预留
+- **Spot Instances**：最高可达 90% 折扣，适用于容错工作负载
+
+## 费率优化工作流
+1. **预工作（Right Sizing）**：先完成资源配置优化
+2. **分析**：识别需要 24/7 运行的工作负载
+3. **沟通**：与财务团队分享详情
+4. **审批**：获取账户所有者批准
+5. **报告**：监控利用率
+
+## 关键约束
+- 仅 FinOps 团队可以实施承诺计划
+- 所有承诺计划仅支持无预付款选项
+- 最低交易价值：每年 5,000 美元
+
+## Connections
+- [[FinOps]] ← enables ← [[Rate Optimization]]：FinOps 推动费率优化
+- [[Cost Optimization]] ← implements ← [[Rate Optimization]]：费率优化是成本优化的一部分
+- [[Workload Optimization]] ← combines_with ← [[Rate Optimization]]：与工作负载优化配合实现最大节省
+- [[Savings Plans]] ← is_type_of ← [[Rate Optimization]]
+- [[Reserved Instances]] ← is_type_of ← [[Rate Optimization]]
+- [[Spot Instances]] ← is_type_of ← [[Rate Optimization]]
--- a/wiki/concepts/Renovate-Bot.md
+++ b/wiki/concepts/Renovate-Bot.md
@@ -0,0 +1,25 @@
+---
+title: "Renovate Bot"
+type: concept
+tags: [DevOps, CI/CD, Dependency-Update]
+date: 2026-04-14
+---
+
+## Definition
+开源依赖自动化更新工具，通过扫描代码并自动提交 Pull Request 来保持依赖项处于最新状态。适用于 Docker 镜像、Maven 依赖、Terraform 模块、Kubernetes Helm Charts 等多种依赖类型。
+
+## Aliases
+- Renovate
+- Renovate Bot
+
+## Key Features
+- Dependency Dashboard：在一个 GitHub Issue 中列出所有待更新的项，提供全局视角
+- Managers：支持多种技术栈的插件机制（terraform、dockerfile、maven 等）
+- Rate Limiting：限制每小时或同时开启的 PR 数量
+- 自动语义版本判断：基于 Semantic Versioning 规则判断更新级别
+
+## Connections
+- [[Dependency Management]]：自动化管理目标
+- [[GitOps]]：依赖更新是 GitOps 流程的一部分
+- [[Terraform]]：可管理 Terraform 模块依赖
+- [[Terragrunt]]：可管理 Terragrunt 配置依赖
--- a/wiki/concepts/Right-Sizing.md
+++ b/wiki/concepts/Right-Sizing.md
@@ -0,0 +1,23 @@
+---
+title: "Right Sizing"
+type: concept
+tags: [cloud, cost-management, AWS, EC2]
+sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]
+last_updated: 2026-04-19
+---
+
+## Summary
+Right Sizing（正确调整规格）是识别正确的资源规格以匹配工作负载性能和容量需求的过程。
+
+## Definition
+通过分析实际 CPU、内存、网络使用数据，推荐合适的实例规格，避免资源浪费。
+
+## Key Techniques
+- **EC2 Right Sizing Recommendation**：捕获 CPU、内存、网络数据提供推荐
+- **实例调度**：为非生产环境配置按业务时间开关机，可节省 60% 成本
+- **闲置资源清理**：识别和删除空闲负载均衡器、未关联弹性 IP、低利用率 EBS 卷
+
+## Connections
+- [[Cost Optimization]] ← implements ← [[Right Sizing]]：Right Sizing 是成本优化的核心实践
+- [[Workload Optimization]] ← includes ← [[Right Sizing]]：Right Sizing 属于工作负载优化范畴
+- [[Spot Instances]] ← complements ← [[Right Sizing]]：Right Sizing 与 Spot 实例配合使用效果最佳
--- a/wiki/concepts/S3-Intelligent-Tiering.md
+++ b/wiki/concepts/S3-Intelligent-Tiering.md
@@ -0,0 +1,36 @@
+---
+title: "S3 Intelligent Tiering"
+type: concept
+tags: [AWS, S3, Storage, Cost-Optimization]
+sources: []
+last_updated: 2026-04-19
+---
+
+## Definition
+S3 Intelligent Tiering（S3 智能分层）是 AWS S3 的一种存储类，可自动根据对象访问模式在不同的存储层之间移动数据，无需用户干预即可实现成本优化。
+
+## Key Features
+- **自动监控**：自动监控访问模式，识别不频繁访问的数据
+- **无转换费用**：在不同存储层之间移动时无需支付转换费用
+- **两层监控**：30 天无访问移至 Infrequent Access，90 天移至 Archive 或 Deep Archive
+- **支持所有对象大小**：适合任何大小的对象
+- **无检索费用**：从任何层检索数据无需支付费用
+
+## Pricing Model
+- 存储费用根据层级不同：
+  - Frequent Access：标准 S3 费率
+  - Infrequent Access：比标准层低约 40%
+  - Archive Instant Access：比标准层低约 70%
+  - Deep Archive：比标准层低约 95%
+- 监控费用：每 1,000 对象 $0.015/month
+
+## Use Cases
+- 日志文件归档（访问后 30 天内不访问）
+- 数据湖中的冷数据
+- 合规性保留数据
+- 备份文件的长期存储
+
+## Connections
+- [[Lifecycle-Policy]] → implements → [[S3-Intelligent-Tiering]]
+- [[S3-Standard]] ← compared_to ← [[S3-Intelligent-Tiering]]
+- [[Glacier]] ← compared_to ← [[S3-Intelligent-Tiering]]
--- a/wiki/concepts/STLC.md
+++ b/wiki/concepts/STLC.md
@@ -0,0 +1,23 @@
+---
+title: "STLC"
+type: concept
+tags: [Security, Development-Lifecycle, Micro-Focus]
+last_updated: 2026-04-19
+---
+
+## Definition
+STLC（Security Development Life Cycle，安全开发生命周期）是 Micro Focus 产品开发的基础框架，包含 13 个安全与隐私轨道。Product Privacy Framework 是 STLC 中 13 个安全与隐私轨道之一。
+
+## Components
+- 13 个安全与隐私轨道
+- Product Privacy Framework（产品隐私框架）是其中之一
+- SDL（Security Development Lifecycle）第五大支柱
+
+## Related Concepts
+- [[Product Privacy Framework]]
+- [[Security Development Lifecycle]]
+- [[PII]]
+
+## Related Entities
+- [[Micro Focus]]
+- [[Shlomi Ben-Hur]]
--- a/wiki/concepts/Serverless-Application-Model.md
+++ b/wiki/concepts/Serverless-Application-Model.md
@@ -0,0 +1,51 @@
+---
+title: "Serverless Application Model"
+type: concept
+tags:
+  - AWS
+  - Serverless
+  - IaC
+  - SAM
+date: 2024-09-03
+---
+
+## Definition
+Serverless Application Model（无服务器应用模型，SAM）是 AWS 提供的开源框架，用于简化无服务器应用的本地开发和部署。基于 CloudFormation，扩展了声明无服务器资源的简化的语法。
+
+## Key Features
+- SAM CLI：
+  - `sam init`：初始化项目
+  - `sam build`：本地构建
+  - `sam local`：本地运行和调试
+  - `sam deploy`：部署到 AWS
+- 模板简化：相比 CloudFormation 更简洁的语法
+- 本地测试：支持本地调用 Lambda 和 Step Functions
+
+## SAM Template Structure
+```yaml
+AWSTemplateFormatVersion: '2010-09-09'
+Transform: AWS::Serverless-2016-08-09
+Resources:
+  MyFunction:
+    Type: AWS::Serverless::Function
+    Properties:
+      Handler: index.handler
+      Runtime: nodejs18.x
+      Events:
+        Api:
+          Type: Api
+          Properties:
+            Path: /hello
+            Method: get
+```
+
+## Common Use Cases
+- Lambda 函数部署
+- API Gateway 集成
+- Step Functions 工作流
+- 事件驱动架构
+
+## Aliases
+- AWS SAM
+- SAM
+- Serverless Application Model
--- a/wiki/concepts/Service-Catalog.md
+++ b/wiki/concepts/Service-Catalog.md
@@ -0,0 +1,45 @@
+---
+id: Service-Catalog
+title: "Service Catalog"
+type: concept
+tags:
+  - DevOps
+  - IaC
+  - Terraform
+  - Landing-Zone
+last_updated: 2026-04-19
+---
+
+## Aliases
+- Service Catalog
+- 服务目录
+
+## Summary
+- **定义**：封装业务需求的基础设施模块分组，提供服务级别抽象
+- **用途**：跨团队、跨账户复用基础设施配置，实现独立发布周期
+- **云迁移价值**：通过分层抽象实现基础设施即服务模式
+
+## Key Details
+- **分层结构**：
+  - Terraform Service Catalog：全局共享，供所有产品团队使用
+  - Product Team Service Catalog：团队内部复用
+  - Account-level Module：单账户使用
+- **Service vs Module**：
+  - Service：业务需求封装，部署一组 Module
+  - Module：技术需求实现，单一功能单元
+  - 层级越高，配置选项越少（类似面向对象抽象）
+- **版本化管理**：
+  - 使用语义化版本（major.minor.patch）
+  - Terragrunt targeting 特定版本而非 master 分支
+  - 避免意外变更引入生产环境
+
+## Key Components
+- **main.tf**：定义模块引用和依赖关系
+- **terragrunt.hcl**：目标版本和输入变量配置
+- **outputs**：跨服务依赖值传递
+
+## Connections
+- [[Terraform]] ← uses ← [[Service-Catalog]]
+- [[TerraGrunt]] ← references ← [[Service-Catalog]]
+- [[Module]] ← contained_by ← [[Service-Catalog]]
+- [[Landing-Zone]] ← managed_by ← [[Service-Catalog]]
--- a/wiki/concepts/Step-Functions.md
+++ b/wiki/concepts/Step-Functions.md
@@ -0,0 +1,40 @@
+---
+title: "Step Functions"
+type: concept
+tags:
+  - AWS
+  - Serverless
+  - Orchestration
+  - Workflow
+date: 2024-09-03
+---
+
+## Definition
+Step Functions（步进函数）是 AWS 无服务器工作流服务，基于状态机编排多个 AWS 服务的业务流程。通过可视化工作流协调分布式应用程序和微服务的组件。
+
+## Two Flavors
+- **Standard Workflows（标准工作流）**：
+  - 长期运行（最多 1 年）
+  - 精确一次执行
+  - 每秒最多 2000 次执行
+
+- **Express Workflows（快速工作流）**：
+  - 短期运行（最多 5 分钟）
+  - 至少一次执行
+  - 每秒最多 100000 次执行
+  - 面向事件驱动工作负载
+
+## Key Concepts
+- **State Machine（状态机）**：定义工作流逻辑的结构
+- **States（状态）**：工作流中的步骤，包括 Pass、Task、Choice、Wait、Parallel、Map 等
+- **Transitions（转换）**：状态之间的流向控制
+
+## Use Cases
+- 顺序处理：ETL 流程、数据处理
+- 并行处理：批量数据处理
+- 分支逻辑：条件分支处理
+- 人类审批：集成审批工作流
+
+## Aliases
+- AWS Step Functions
+- Step Functions 状态机
--- a/wiki/concepts/TerraTest.md
+++ b/wiki/concepts/TerraTest.md
@@ -0,0 +1,32 @@
+---
+title: "TerraTest"
+type: concept
+tags:
+  - Testing
+  - IaC
+  - Terraform
+date Added: 2026-04-19
+---
+
+## Summary
+TerraTest 是使用 Golang 编写的自动化基础设施测试库，自动化 Terraform apply-test-destroy 周期，简化基础设施测试流程。
+
+## Definition
+Golang 编写的开源测试库，专门用于测试 Terraform 部署的基础设施。
+
+## Key Features
+- 自动 apply：自动应用 Terraform 配置
+- 自动 test：自动执行测试验证输出
+- 自动 destroy：测试完成后自动清理资源
+
+## Use Cases
+- 集成测试验证已部署基础设施的实际功能
+- 测试复杂 Terraform 模块
+- 测试驱动的基础设施开发（TDD）
+
+## Sources
+- [[ctp-topic-56-automated-infrastructure-testing]]
+
+## Aliases
+- TerraTest
+- Terratest
--- a/wiki/concepts/Terraform.md
+++ b/wiki/concepts/Terraform.md
@@ -0,0 +1,47 @@
+---
+id: Terraform
+title: "Terraform"
+type: concept
+tags:
+  - DevOps
+  - IaC
+  - AWS
+  - Infrastructure
+last_updated: 2026-04-19
+---
+
+## Aliases
+- Terraform
+- IaC (Infrastructure as Code)
+
+## Summary
+- **定义**：基础设施即代码工具，通过声明式配置定义云资源
+- **用途**：跨云平台（AWS、Azure、GCP）管理基础设施
+- **云迁移价值**：实现基础设施版本控制、可重复部署和环境一致性
+
+## Key Details
+- **核心概念**：
+  - Provider：云平台连接器（aws、azurerm 等）
+  - Resource：基础设施资源定义
+  - Data Source：只读数据查询
+  - Variable：输入变量
+  - Output：输出值
+  - Module：可复用配置单元
+- **工作流程**：
+  - init：初始化 provider 和 backend
+  - plan：预览变更
+  - apply：执行变更
+  - destroy：销毁资源
+- **状态管理**：
+  - 本地状态或远程状态（S3、DynamoDB）
+  - 状态锁防止并发冲突
+
+## Terraform vs Terragrunt
+- **Terraform**：底层 IaC 工具
+- **Terragrunt**：Terraform 包装器，提供模块变量共享、多环境管理、远程状态配置
+
+## Connections
+- [[TerraGrunt]] ← wraps ← [[Terraform]]
+- [[Service-Catalog]] ← uses ← [[Terraform]]
+- [[AWS]] ← managed_by ← [[Terraform]]
+- [[Module]] ← implemented_by ← [[Terraform]]
--- a/wiki/concepts/Test-Driven-Development.md
+++ b/wiki/concepts/Test-Driven-Development.md
@@ -0,0 +1,33 @@
+---
+title: "Test-Driven Development"
+type: concept
+tags:
+  - Testing
+  - Development
+  - TDD
+date Added: 2026-04-19
+---
+
+## Summary
+测试驱动开发（Test-Driven Development，TDD）是一种软件开发方法论，先写测试再实现功能，确保聚焦开发目标并构建全面的测试套件。
+
+## Definition
+测试驱动开发是一种迭代开发方法论，通过先编写测试来定义期望行为，然后编写最小代码通过测试，最后重构改进。
+
+## Workflow
+1. 编写测试（Red）：定义期望行为
+2. 实现代码（Green）：编写最小代码通过测试
+3. 重构（Refactor）：优化代码结构
+
+## Benefits
+- 确保功能可测试
+- 构建全面测试套件
+- 聚焦开发目标
+- 提高代码质量
+
+## Sources
+- [[ctp-topic-56-automated-infrastructure-testing]]
+
+## Aliases
+- TDD
+- Test-Driven Development
--- a/wiki/concepts/Workload-Optimization.md
+++ b/wiki/concepts/Workload-Optimization.md
@@ -0,0 +1,30 @@
+---
+title: "Workload Optimization"
+type: concept
+tags: [cloud, cost-management, AWS]
+sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]
+last_updated: 2026-04-19
+---
+
+## Summary
+Workload Optimization（工作负载优化）是通过现代化和 Right Sizing 优化资源配置以降低云成本的实践。
+
+## Definition
+工作负载优化涵盖两个主要方向：现代化（使用新一代服务）和 Right Sizing（调整资源规格匹配实际需求）。
+
+## Key Techniques
+- **现代化（Modernization）**：使用新一代服务实例
+  - Intel 迁移到 AMD：节省 6-10% 按需价格
+  - 迁移到 Graviton：节省 20-25% 按需价格
+  - GP2 升级到 GP3：直接节省 20% 存储成本
+  - EKS 集群升级到最新版本：避免高额扩展支持费用
+
+- **Right Sizing**：根据实际需求调整资源配置
+  - EC2 Right Sizing 推荐报告
+  - 实例调度（非生产环境按需开关）
+  - 闲置资源清理
+
+## Connections
+- [[FinOps]] ← enables ← [[Workload Optimization]]：FinOps 推动工作负载优化
+- [[Cost Optimization]] ← implements ← [[Workload Optimization]]：工作负载优化是成本优化的一部分
+- [[Rate Optimization]] ← combines_with ← [[Workload Optimization]]：与费率优化配合实现最大节省