Auto-sync: update nexus workspace

wiki/sources/cloud-learning-master-index.md

@@ -6,48 +6,56 @@ date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Micro Focus / OpenText 云转型学习会话（Public Cloud Learning Sessions）的视频课程总索引，涵盖 AWS Landing Zone、IAM、IaC、EKS、FinOps、CI/CD、Security、Networking、Serverless/AI、OpenText Series 共 10 大领域。
-- 问题域：为企业云转型提供系统性学习路径，覆盖架构设计、身份治理、成本管理、安全合规、可观测性、容器化、自动化运维等全技术栈。
-- 方法/机制：以 NAS 共享文件系统（`/volume2/work/Public Cloud Learning Sessions/`）为视频源，按技术领域分类组织学习会话，由 CTP（Cloud Transformation Programme）团队定期录制分享。
-- 结论/价值：作为云转型知识库的总入口，为工程师和架构师提供按主题索引的参考导航，支持快速定位特定领域的学习资源。
+- 核心主题：Public Cloud Learning Sessions（公共云学习课程）全部视频的分类索引目录
+- 问题域：Micro Focus/OpenText 云转型计划（Cloud Transformation Programme）内部培训视频资源管理
+- 方法/机制：通过 NAS 共享存储（`/volume2/work/Public Cloud Learning Sessions/`）集中管理，按主题分为 10 大类共 111 个视频；每个视频以 topic ID 或完整文件名作为链接键
+- 结论/价值：为云工程师提供体系化的 DevOps/SRE/FinOps/安全/网络等领域的视频学习资源目录；是构建 Cloud & DevOps 领域知识图谱的核心入口
 
 ## Key Claims（用中文描述）
-- 该索引覆盖 Micro Focus / OpenText 云转型计划的全部技术领域，从基础设施（AWS Landing Zone）到应用层（Serverless/AI）形成完整知识体系。
-- 视频总数 **111 个**（截至 2026-04-14），分布在 10 个技术分类中，其中 AWS Landing Zone（22）和 OpenText Series（21）内容最丰富。
-- 所有视频通过 NAS 集中存储（`/volume2/work/Public Cloud Learning Sessions/`），统一命名规范（ctp-topic-NN / learning-sessions-xxx / public-cloud-learning-sessions-xxx）。
+- OpenText 云转型计划通过 10 大类 111 个视频覆盖 DevOps 全栈知识体系
+- AWS Landing Zone 是视频资源最丰富的类别（22 个视频），涵盖基础设施、安全、数据库等核心主题
+- OpenText Series 是第二大类别（21 个视频），聚焦组织流程、需求管理和产品运营
+- EKS & Kubernetes 类别（14 个视频）提供从入门到生产实践的完整学习路径
+- FinOps & Cost 类别（10 个视频）支持云成本治理与优化实践落地
 
 ## Key Quotes
-> "NAS源: `/volume2/work/Public Cloud Learning Sessions/` | Total: **0 videos processed**" — 索引文件元数据声明（videos processed 计数器未更新，实际视频数按分类统计为 111 个）
+> "NAS源: `/volume2/work/Public Cloud Learning Sessions/` | Total: **0 videos processed**" — 当前索引状态标注，尚未完成视频内容处理
 
 ## Key Concepts
-- [[Cloud-Transformation-Programme]]：云转型计划，本索引所属的学习会话系列由 CTP 团队主导录制。
-- [[AWS-Landing-Zone]]：AWS Landing Zone 是索引中最核心的分类之一（22 个视频），涵盖架构设计、账号管理、网络隔离。
-- [[EKS-Optimization]]：EKS 优化三专题（Bottlerocket OS / Karpenter / EKS Auto Mode）是容器化学习的高频主题。
-- [[FinOps]]：FinOps 与成本优化专题覆盖 Instance Scheduler / Rightsizing / Savings Plans / Spot Instances 等核心技术。
-- [[GitOps]]：GitOps 与 CI/CD 专题包括 Git / Renovate Bot / Atlantis / Gruntwork / IaC Testing 等工具链。
-- [[Security-Governance]]：安全专题涵盖供应链安全、3LoD 框架、Firewall Manager、Secrets Manager、CSPM 等。
+- [[Landing-Zone]]：多账号 AWS 架构框架，是 AWS Landing Zone 类别（22 视频）的核心概念
+- [[FinOps]]：云成本治理学科，FinOps & Cost 类别（10 视频）覆盖该领域
+- [[GitOps]]：基于 Git 的基础设施运维方法，CI/CD & GitOps 类别（8 视频）涵盖
+- [[EKS]]：Amazon Elastic Kubernetes Service，EKS & Kubernetes 类别（14 视频）聚焦
+- [[Terraform]]：基础设施即代码工具，Terraform & IaC 类别（6 视频）涵盖
+- [[IAM]]：身份与访问管理，IAM & Identity 类别（3 视频）覆盖
 
 ## Key Entities
-- [[CTP-Team]]（Cloud Transformation Programme Team）：学习会话系列的发起和组织团队，涵盖 AWS Landing Zone / FinOps / EKS / CI/CD / Security 等多领域内容。
-- [[OpenText]]：索引中 OpenText Series（21 个视频）专题由 OpenText 全球团队分享，覆盖 Thor Platform、产品策略、GIS 安全政策、GitLab 迁移等。
-- [[AWS]]：所有视频的云平台基础，涵盖 AWS 生态中的 EC2/EKS/S3/IAM/VPC/Lambda 等全栈服务。
-- [[Gruntwork]]：IaC 工具链核心，Gruntwork Landing Zone 架构在索引中出现多次（Topic 1 / Topic 3 / Topic 9 等）。
-- [[Micro-Focus]]：早期视频的发起公司，已被 OpenText 收购，部分内容反映 Micro Focus 时期的架构决策。
+- [[Gruntwork]]：提供 Landing Zone 参考架构和基础设施模块的关键合作伙伴（AWS Landing Zone 类别多次引用）
+- [[OpenText]]：收购 Micro Focus 后主导云转型计划，OpenText Series 类别（21 视频）由其团队生产
+- [[AWS]]：主要云平台，所有 10 大类别均围绕 AWS 服务展开
+- [[Micro-Focus]]：被 OpenText 收购的原企业软件公司，其 OpsBridge 产品仍在使用（Security/EKS 类别引用）
+- [[Atlantis]]：开源 Terraform CI/CD 工具（CI/CD & GitOps 类别引用）
+- [[Renovatebot]]：自动化依赖更新工具（CI/CD & GitOps 类别引用）
+- [[Grafana]]：可观测性仪表盘（EKS & Kubernetes 类别多处引用）
+- [[Karpenter]]：AWS 原生 Kubernetes 节点自动扩缩容器（EKS 优化类别引用）
+- [[Bottlerocket-OS]]：AWS 容器专用操作系统（EKS 优化 Part 2 引用）
 
 ## Connections
-- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← depends_on ← cloud-learning-master-index（索引入口）
-- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← cloud-learning-master-index（专题延伸）
-- [[ctp-topic-34-azure-landing-zone-architecture-overview]] ← extends ← cloud-learning-master-index（多云扩展）
-- [[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]] ← depends_on ← cloud-learning-master-index（EKS 专题入口）
-- [[public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]] ← extends ← cloud-learning-master-index
-- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] ← extends ← cloud-learning-master-index
-- [[public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording]] ← depends_on ← cloud-learning-master-index（FinOps 成本管控）
-- [[ctp-topic-33-an-introduction-to-gitops]] ← depends_on ← cloud-learning-master-index（GitOps 入门）
-- [[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]] ← depends_on ← cloud-learning-master-index（OpenText 安全专题）
+- [[cloud-learning-master-index]] ← index_of ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+- [[cloud-learning-master-index]] ← index_of ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[cloud-learning-master-index]] ← index_of ← [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
+- [[cloud-learning-master-index]] ← index_of ← [[ctp-topic-33-an-introduction-to-gitops]]
+- [[cloud-learning-master-index]] ← index_of ← [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
+- [[cloud-learning-master-index]] ← index_of ← [[ctp-topic-59-achieving-reliability-with-amazon-eks]]
+- [[cloud-learning-master-index]] ← index_of ← [[ctp-topic-63-optimise-resource-cost-using-automation]]
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-34-azure-landing-zone-architecture-overview]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]
 
 ## Contradictions
-- 与 [[ctp-topic-14-octane-hub-on-aws]] 可能的冲突：索引本身仅为元数据，不存在内容冲突。
-- 与 [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]] 无冲突：EKS 可观测性专题与 OpenTelemetry 专题互补。
+- 与 [[ctp-topic-34-azure-landing-zone-architecture-overview]] 的跨平台差异：
+  - 冲突点：AWS Landing Zone 类别以 AWS 为中心，但索引中包含 Azure Landing Zone 视频
+  - 当前观点：主要聚焦 AWS Landing Zone 最佳实践（Gruntwork 参考架构）
+  - 对方观点：多云策略同等重要，Azure Landing Zone 同样需要学习

wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md

@@ -2,51 +2,56 @@
 title: "CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs"
 type: source
 tags:
+  - AWS
   - FinOps
   - Cost-Optimization
-  - AWS
-  - PCG
   - CTP
-date: 2026-04-14
+date: 2026-05-12
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
 
 ## Summary（用中文描述）
-- 核心主题：Cloud FinOps 成本优化政策与最佳实践，由 PCG 团队的 Uday 和 Vinay 主讲
-- 问题域：公共云账单可见性、标签合规、预算责任、Reserved Instances 集中管理、研发环境成本优化
-- 方法/机制：PCG 三层服务模型（成本管理→成本优化→治理与自动化）、5 大核心策略、安全控制（Godrails/MFA/告警重定向）、标准化实例选型
-- 结论/价值：建立系统化的 FinOps 流程，通过集中 Reserved Instances 购买、标准化实例类型、Graviton 迁移和实例调度器实现持续成本优化
+- 核心主题：Cloud FinOps 微聚焦策略与成本优化最佳实践，由 PCG 团队 Uday 和 Vinay 主讲
+- 问题域：公共云环境下的成本可见性、标签合规、预算责任、Reserved Instances 集中管理
+- 方法/机制：PCG 服务分层（成本管理/成本优化/治理与自动化）、安全策略（Godrails/联合身份管理）、Cloud Health 监控工具、实例类型标准化、Graviton ARM 实例降本
+- 结论/价值：提供完整的 FinOps 治理框架，强调可见性→合规→集中管理→持续优化的递进路径
 
 ## Key Claims（用中文描述）
-- PCG 通过三层服务分层（成本管理→成本优化→治理与自动化）为云账单提供完整的可见性和优化机制
-- 强制标签合规是实现 showback/chargeback 和预算责任的基础
-- Reserved Instances 和 Savings Plans 必须集中购买才能实现规模效益
-- Graviton ARM 实例比 Intel 实例更具成本优势，可直接节省成本
-- 研发环境通过突发性实例 + Spot 实例 + 实例调度器三重组合可大幅降低费用
+- PCG 团队通过服务分层（成本管理+成本优化+治理自动化）实现云成本全生命周期管理
+- 标签合规是实现成本可见性的基础，强制标签要求确保账单按责任单元拆分
+- Reserved Instances 和 Savings Plans 必须集中管理才能发挥规模效益
+- Cloud Health 是关键监控工具，提供资源清单、成本分析和月度账单洞察
+- Graviton ARM 实例相比 Intel 可显著降低计算成本
+- 研发环境应使用突发性实例、实例调度器和 Spot 实例降低闲置成本
 
 ## Key Quotes
-> "使用 Cloud Health 工具查看资源清单、月度账单洞察和成本分析" — Cloud Health 是成本优化的核心监控工具
+> "PCG 服务分层：成本管理（账单支付、showback/chargeback、预算管理）→ 成本优化（组织级和账户级优化，包括购买 Reserved Instances 和识别未充分利用的资源）→ 治理与自动化（集中式上线、策略开发、自动报告）" — PCG FinOps 框架三层次
+
+> "使用计算器了解成本 → 检查资源清单 → 监控月度账单 → 使用 Cloud Health 进行成本分析" — 最佳实践四步法
+
+> "M 系列通用、T 系列突发性、C 系列计算密集、R/X 系列内存优化、Graviton ARM 最便宜" — AWS EC2 实例选型指南
 
 ## Key Concepts
-- [[FinOps（云财务管理）]]：云成本优化学科，平衡云使用量、速度和成本
-- [[Showback/Chargeback]]：成本分摊机制，showback 让团队看到成本数据，chargeback 向团队直接收取成本
-- [[AWS-Instance-Families]]：AWS EC2 实例类型分类（M/T/C/R/X 系列），选型直接影响成本
-- [[Reserved-Instances-Savings-Plans]]：承诺使用计划，通过预留容量换取折扣
-- [[Graviton-Instances]]：AWS ARM 架构处理器实例，相比 Intel 实例成本更低
+- [[FinOps]]：云财务管理学科，通过可见性、优化和治理实现云投资最大化价值
+- [[Reserved Instances]]：预付费预留实例，用于稳定工作负载的长期成本优化
+- [[Savings Plans]]：灵活定价模型，相比 RI 更灵活但需要一定使用承诺
+- [[Spot Instances]]：竞价实例，可中断工作负载用，成本可降低 60-90%
+- [[Graviton]]：AWS ARM 处理器，比 Intel/AMD x86 实例成本更低、能耗更低
+- [[Cloud Health]]：云成本分析和监控工具，提供资源清单、成本分解和账单洞察
+- [[Showback/Chargeback]]：成本分摊机制，Showback 展示成本数据，Chargeback 强制成本归属
 
 ## Key Entities
-- [[PCG]]：Public Cloud Governance 团队，由 Uday 和 Vinay 主导，负责云治理、成本管理和 FinOps 政策
-- [[Cloud-Health]]：Ansys Cloud Health 云成本分析和监控工具
+- [[PCG]]（Public Cloud Governance）：公共云治理团队，提供工作负载放置、成本和优化指导
+- [[Uday]]：PCG 团队成员，FinOps 主题讲师
+- [[Vinay]]：PCG 团队成员，FinOps 主题讲师
+- [[Godrails]]：预安装安全控制措施，内置于云账户初始化流程
 
 ## Connections
-- [[ctp-topic-63-optimise-resource-cost-using-automation]] ← depends_on ← [[ctp-topic-13-cloud-finops-policies]]
-- [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]] ← depends_on ← [[ctp-topic-13-cloud-finops-policies]]
-- [[ctp-topic-27-aws-instance-scheduler]] ← extends ← [[ctp-topic-13-cloud-finops-policies]]
+- [[CTP-Topic-63-Optimise-Resource-Cost-Using-Automation]] ← extends ← [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
+- [[CTP-Topic-27-AWS-Instance-Scheduler]] ← depends_on ← [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
+- [[CTP-Topic-71-PCGs-Guide-to-RightSizing]] ← extends ← [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]
 
 ## Contradictions
-- 与 [[ctp-topic-53-why-bother-with-cloud]] 冲突：
-  - 冲突点：[[ctp-topic-13]] 假设业务已上云，聚焦优化；[[ctp-topic-53]] 聚焦是否应迁移的决策论证
-  - 当前观点：默认已在云上，专注于持续优化成本
-  - 对方观点：云迁移决策本身需要商业价值论证
+- （无）

wiki/sources/ctp-topic-2-git.md

@@ -1,45 +1,37 @@
 ---
 title: "CTP Topic 2 Git"
 type: source
-tags:
-  - Git
-  - VCS
-  - CTP
-last_updated: 2026-04-14
+tags: [Git, VCS, CTP]
+date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md]]
 
 ## Summary（用中文描述）
 - 核心主题：Git 版本控制系统基础与实践
-- 问题域：云转型计划中的源代码版本控制与协作工作流
-- 方法/机制：视频讲座形式，CTP Topic 2 系列课程
-- 结论/价值：掌握 Git 是 DevOps 与 IaC 实践的基础技能
+- 问题域：CTP 云转型计划中的版本控制标准化与团队协作
+- 方法/机制：视频学习材料，内容待 Whisper 转录后补充
+- 结论/价值：待视频内容转录后生成
 
 ## Key Claims（用中文描述）
-- CTP Topic 2 涵盖 Git 版本控制系统的核心概念与实操技能
+- （⚠️ 待视频转录后补充——源文件 status: Awaiting Whisper transcription）
 
 ## Key Quotes
-> "待 Whisper 转录后补充详细内容" — 当前状态：待转录
+> （待视频转录后补充）
 
 ## Key Concepts
-- [[Git]]：分布式版本控制系统，DevOps 与 CI/CD 流水线的基础工具
-- [[Version Control]]：代码变更追踪与协作管理机制
-- [[DevOps]]：开发与运维协作的文化与实践体系
+- [[VersionControl]]：版本控制系统，记录文件变更、支持多人协作、回溯历史
+- [[Git]]：分布式版本控制系统，CTP 项目中的核心代码管理工具
 
 ## Key Entities
-- [[Cloud Transformation Programme]]：云转型计划，CTP Topic 系列课程的组织框架
+- [[CloudTransformationProgramme]]：云转型计划（CTP），该学习主题的所属项目背景
 
 ## Connections
-- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[ctp-topic-2-git]]
-- [[ctp-topic-33-an-introduction-to-gitops]] ← depends_on ← [[ctp-topic-2-git]]
-- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration]] ← related_to ← [[ctp-topic-2-git]]
+- [[GitOps]] ← foundational ← [[CTP Topic 2 Git]]
+- [[AtlantisCICD]] ← related ← [[CTP Topic 2 Git]]（均属 CI/CD GitOps 主题分类）
+- [[CTP Topic 9 CI CD with Gruntwork]] ← sibling ← [[CTP Topic 2 Git]]（同属 06_CI_CD_GitOps 分类）
+- [[GitHub Enterprise to GitLab Migration]] ← related ← [[CTP Topic 2 Git]]（Git 平台迁移相关）
 
 ## Contradictions
-- 无已知冲突
-
-## Notes
-- 原始文档状态为"待转录"（Awaiting Whisper transcription → Summary）
-- 视频源：NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 2_ Git.mp4`
-- 类别：DevOps & SRE / 06_CI_CD_GitOps
+- （暂无，待视频内容补充）

wiki/sources/ctp-topic-27-aws-instance-scheduler.md

@@ -5,63 +5,57 @@ tags:
   - AWS
   - Instance-Scheduler
   - Cost-Optimization
-  - CTP
   - FinOps
+  - CTP
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS Instance Scheduler —— 通过定时自动化控制 EC2 和 RDS 实例启停，实现非生产环境（开发/测试）的成本优化
-- 问题域：非生产 AWS 账号中 EC2/RDS 实例 24/7 运行导致成本浪费，Cloud FinOps 需要自动化手段降低这部分支出
-- 方法/机制：
-  - CloudFormation 一键部署，由 CCOE 的 Guardrails 框架自动集成推送至所有相关账号
-  - CloudWatch Events 定时触发（默认每 15 分钟）
-  - Lambda 函数读取 DynamoDB 中的调度配置（Schedules + Periods）
-  - 通过实例标签（`Schedule`、`Period`）关联调度规则
-  - 支持多时区办公时间配置（如西雅图时间、英国时间）
-- 结论/价值：
-  - 自动覆盖公司内部绝大多数月消费超过 10 美元的 AWS 账号
-  - 与基于空闲率的调度不同，本工具基于"时间表"触发
-  - RDS 实例智能配合每 7 天维护窗口，确保维护完成后恢复正常调度状态
-  - 实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"以保留数据
+- 核心主题：AWS Instance Scheduler — 通过定时自动化控制 EC2/RDS 实例启停以节省云成本
+- 问题域：非生产环境（开发/测试）云资源利用率低导致的成本浪费
+- 方法/机制：CloudFormation 部署 → CloudWatch Events 每15分钟触发 → Lambda 读取 DynamoDB 配置 → 根据实例标签执行启停操作
+- 结论/价值：CCOE 通过 Guardrails 自动部署，覆盖公司内月消费超10美元的绝大多数 AWS 账号，显著降低非生产环境云成本
 
 ## Key Claims（用中文描述）
-- AWS Instance Scheduler 通过时间表驱动（非空闲率驱动）的定时任务，可为非生产环境实例节省最高 70% 的运行成本
-- 通过 Guardrails 框架集成，Instance Scheduler 自动部署至公司绝大多数月消费超过 10 美元的 AWS 账号，无需用户手动配置
-- CloudWatch Events 每 15 分钟触发 Lambda 检查，结合 DynamoDB 中定义的 Schedules 和 Periods，实现精细化的多时区调度
-- RDS 实例的每 7 天维护窗口与调度系统智能协同，确保维护完成后实例恢复到预期的调度状态
+- AWS Instance Scheduler（AWS 官方方案）+ CCOE Guardrails 集成 → 非生产环境实例自动启停 → 降低云成本
+- CloudWatch Events 每15分钟（默认）触发 Lambda → 读取 DynamoDB 中的调度配置（Schedules + Periods）→ 根据实例标签执行操作
+- 实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"以保留数据
+- RDS 调度需考虑每七天一次的强制维护窗口，维护完成后实例能恢复至预期调度状态
+- 该工具基于"时间表（Schedule）"触发，而非"空闲率（Idle time）"触发
+- 通过 Guardrails 部署后，自动覆盖公司内月消费超10美元的 AWS 账号
 
 ## Key Quotes
-> "该工具是基于'时间表'（Schedule）而非'空闲率'（Idle time）触发的" — Gustavo，澄清核心触发机制
-> "通过 Guardrails，该功能已自动覆盖了公司内部绝大多数月消费超过 10 美元的 AWS 账号" — Gustavo，说明部署覆盖范围
-> "实例的关机行为必须设置为'停止（Stop）'而非'终止（Terminate）'" — Gustavo，操作注意事项
+> "AWS Instance Scheduler 是一项由 AWS 官方提供并由 CCOE（云卓越中心）集成在 Guardrails 部署方案中的成本优化工具。该方案的核心目标是通过自动化的定时任务来控制 EC2 和 RDS 实例的运行状态，从而降低非生产环境（如开发和测试环境）的云端成本。" — Gustavo，CTP Topic 27 摘要
+
+> "实例的关机行为必须设置为'停止（Stop）'而非'终止（Terminate）'以保留数据。" — Gustavo，CTP Topic 27 问答
+
+> "该工具是基于'时间表'而非'空闲率（Idle time）'触发的。" — Gustavo，CTP Topic 27 问答
 
 ## Key Concepts
-- [[AWS Instance Scheduler]]：AWS 官方提供的开源解决方案，通过 CloudFormation 部署，自动定时启动和停止 EC2 及 RDS 实例以节省成本
-- [[Guardrails]]：CCOE 团队实施的自动化合规与治理框架，Instance Scheduler 作为其中的成本控制组件被自动部署
-- [[CloudWatch Events]]：系统的触发器，按照预设的时间间隔（如 15 分钟）激活 Lambda 函数
-- [[DynamoDB Config Table]]：用于存储调度定义（Schedules）和周期定义（Periods）的 NoSQL 数据库，是调度的逻辑核心
-- [[Tag-Based Scheduling]]：用户通过在实例上添加特定标签（如 `Schedule`、`Period`）将其关联到预定义的调度逻辑
-- [[RDS Maintenance Window]]：RDS 特有的每 7 天维护窗口，Instance Scheduler 能够识别并配合该窗口，确保数据库在维护后正确关闭
-- [[Override Status]]：高级配置，允许管理员强制将实例保持在停止状态，即使在预设的启动时间内也不启动
+- [[AWS-Instance-Scheduler]]：AWS 官方提供的解决方案，用于自动启动和停止 EC2 及 RDS 实例以节省成本，基于 CloudFormation + CloudWatch Events + Lambda + DynamoDB 架构
+- [[CloudWatch-Events]]：系统的触发器，按照预设的时间间隔（如每15分钟）激活 Lambda 函数
+- [[DynamoDB-Config-Table]]：用于存储调度定义（Schedules）和周期定义（Periods）的数据库，是调度的逻辑核心
+- [[Tagging]]：用户通过在实例上添加特定的标签（如 `Schedule`）来将其关联到预定义的调度逻辑
+- [[RDS-Maintenance-Window]]：RDS 特有的维护窗口，Instance Scheduler 能够识别并配合该窗口，确保数据库在维护后正确关闭
+- [[Override-Status]]：一种高级配置，允许管理员强制将实例保持在停止状态，即使在预设的启动时间内也不启动
 
 ## Key Entities
-- [[Gustavo]]：CCOE 团队成员，Instance Scheduler 主题讲师
-- [[CCOE（云卓越中心）]]：负责 Guardrails 框架实施和 Instance Scheduler 集成的内部团队
-- [[AWS]]：Instance Scheduler 的官方服务提供方
+- [[CCOE]]：Cloud Center of Excellence，负责将 Instance Scheduler 集成到 Guardrails 自动化部署方案中
+- [[Gustavo]]：CTP Topic 27 主讲人，介绍 AWS Instance Scheduler 的核心机制和使用场景
+- [[Godrails]]：CCOE 自动化合规框架，Instance Scheduler 作为成本控制组件被集成推送
 
 ## Connections
-- [[ctp-topic-13-cloud-finops-policies-best-practices-to-optimize-the-co]] ← depends_on ← [[ctp-topic-27-aws-instance-scheduler]]：Topic 13 定义 FinOps 政策层（标签合规、成本可见性），Topic 27 提供具体技术实现（Instance Scheduler）
-- [[ctp-topic-63-optimise-resource-cost-using-automation]] ← related_to ← [[ctp-topic-27-aws-instance-scheduler]]：两专题均覆盖 EC2/RDS 自动化调度，Topic 63 侧重 Terraform 层面的 `auto_shutdown` 标签方案，Topic 27 侧重 AWS 原生 Instance Scheduler 方案
-- [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]] ← extends ← [[ctp-topic-27-aws-instance-scheduler]]：Right Sizing 从实例规格层面降低容量，Instance Scheduler 从运行时间层面降低浪费，构成互补的成本优化策略
-- [[public-cloud-learning-sessions-budget-control-20240319]] ← related_to ← [[ctp-topic-27-aws-instance-scheduler]]：两专题同属 FinOps 范畴，分别聚焦预算告警强制封禁和实例调度自动节能
+- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] ← extends ← [[ctp-topic-27-aws-instance-scheduler]]
+  - Topic 13 提出 FinOps 治理框架（含"实例调度器"策略），Topic 27 详解该策略的具体实现方案
+- [[ctp-topic-27-aws-instance-scheduler]] ← depends_on ← [[AWS-Instance-Scheduler]]
+  - Source 依赖 AWS-Instance-Scheduler 概念页（AWS 官方方案）
+- [[AWS-Instance-Scheduler]] ← extends ← [[Guardrails]]
+  - Instance Scheduler 作为 Guardrails 合规框架中的成本控制组件
+- [[ctp-topic-27-aws-instance-scheduler]] ← relates_to ← [[ctp-topic-28-aws-tag-validation-tool]]
+  - 两者均依赖 Tagging 机制，Tag 规范是调度的前提条件
 
 ## Contradictions
-- 与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 可能的实现路径差异：
-  - 冲突点：EC2/RDS 自动调度的实现方案选择
-  - 当前观点：Topic 27 推荐 AWS 原生 Instance Scheduler（CloudFormation + CloudWatch + Lambda + DynamoDB），通过 Guardrails 自动推送覆盖全公司账号
-  - 对方观点：Topic 63 推荐 Terraform Scheduler 模块（`auto_shutdown = yes` 标签），在 Terraform 层面实现
-  - 说明：两者并不互斥——Instance Scheduler 是 AWS 原生方案覆盖广账户层，Terraform Scheduler 是 IaC 层细粒度控制，企业可同时使用
+- 无显著内容冲突

wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md

@@ -1,62 +1,78 @@
 ---
-title: "CTP Topic 3 Deploy and maintain infrastructure"
+title: "CTP Topic 3 Deploy and Maintain Infrastructure"
 type: source
 tags:
   - IaC
   - Deployment
   - CI/CD
-  - CTP
   - Terraform
   - Terragrunt
+  - Landing-Zone
+  - CTP
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS Landing Zone 环境下通过 Terraform/Terragrunt 实现基础设施部署与维护的完整方法论
-- 问题域：多账户、多产品团队环境下 IaC 模块化复用、服务目录治理、Terragrunt 依赖管理
-- 方法/机制：Service Module（业务视角）vs Regular Module（技术视角）的分层抽象；Terragrunt HCL 引用特定版本模块；Service Catalog 三级复用（单账户→产品团队→跨团队）；Terragrunt 缓存目录预取依赖
-- 结论/价值：模块化 IaC 实现独立发布周期和可维护性；Service 层抽象减少配置复杂度，越高层抽象选项越少（类 OO 继承）；推荐使用专用 Service Catalog 而非相对路径引用
+- 核心主题：AWS Landing Zone 环境下的基础设施部署与维护机制
+- 问题域：产品团队如何在 Landing Zone 多账号架构中高效、一致、可复用地部署基础设施
+- 方法/机制：通过 Terraform 模块化 + Terragrunt 版本控制 + 多层 Service Catalog 实现跨账户、跨团队的基础设施即代码部署
+- 结论/价值：Service（业务需求封装）优于 Module（技术实现）的抽象层级越高，可用性越强；推荐使用专用 Service Catalog 而非相对路径，以实现独立发布周期和更好的可维护性
 
 ## Key Claims（用中文描述）
-- Product Team 在 Landing Zone 中部署基础设施时，跨越多个账户（如 Artifactory 账户、AD 账户），涉及多个 Git 仓库协同
-- Service Module 由 main.tf 文件引用其他仓库模块组合而成，满足特定业务需求（如 AD 服务、DNS 服务）
-- Service 抽象层次高于 Regular Module，提供更少配置选项但更易使用
-- Terragrunt 优于直接引用 master 分支，target 特定版本确保环境一致性
-- 复用层次：单账户使用 → 产品团队 Service Catalog → Terraform Service Catalog（跨团队）
-- Terragrunt 在运行前预取所有引用，通过缓存目录存储克隆的仓库
+- **产品团队通过 Landing Zone 分组**：每个产品团队拥有独立的 Landing Zone 和工作负载账号（如 DevTools 团队部署 Artifactory 和 Active Directory）
+- **三层 Git 仓库架构**：核心 Landing Zone 仓库 + Terraform Service Catalog + 产品团队 Service Catalog，三者分离实现独立生命周期
+- **Service 模块 = 业务封装**：Service 模块由 main.tf 组成，引用多个 Module 以满足单一业务需求（如 AD 服务或 DNS 服务）
+- **Terragrunt HCL 优先使用依赖而非读取状态文件**：通过 dependencies 声明跨服务引用，支持版本锁定而非直接引用 master 分支
+- **Service 优于 Module 的抽象层级**：Service 是业务需求视角，Module 是技术实现视角；层级越高，配置选项越少（类似面向对象抽象）
+- **Terragrunt 缓存机制**：运行前预取所有引用，使用 Terragrunt 缓存目录存储克隆的仓库
+- **Apply 前必须验证**：不经验证直接 apply 是不推荐的做法
 
 ## Key Quotes
-> "A service is a business requirement, while a regular module is a technical requirement." — 核心区分：Service 解决业务问题，Module 解决技术问题
+> "A service is a business requirement, while a regular module is a technical requirement." — 区分 Service 与 Module 的本质定义
 
-> "When deploying infrastructure, Terragrunt HCL files are used to reference these services, targeting specific versions rather than the master branch." — 版本控制优于分支引用
+> "When deploying infrastructure, Terragrunt HCL files are used to reference these services, targeting specific versions rather than the master branch." — 版本控制优于直接引用 master
 
-> "The higher up the chain, the less configuration options are available, similar to an object-oriented approach." — 抽象层次与配置灵活性的反向关系
+> "Modules can be used within one account, reused within a product team (in the product team service catalog), or used across product teams (in the Terraform service catalog)." — 模块三层复用模型
 
 ## Key Concepts
-- [[Landing Zone（落地区）]]：云环境的基础账户结构和资源隔离框架，产品团队在此之上部署工作负载
-- [[Service Module（服务模块）]]：满足业务需求的一组 Terraform 模块组合，相较于技术模块提供更高级抽象
-- [[Service Catalog（服务目录）]]：可复用模块的集中管理库，支持三级复用（账户/产品团队/跨团队）
-- [[Terragrunt]]：Terraform 的薄包装层，支持依赖管理、缓存和版本锁定
-- [[Terraform Module]]：Terraform 的可复用配置单元，版本化管理
-- [[Infrastructure as Code（IaC）]]：通过代码管理和配置基础设施的实践
+- [[Infrastructure-as-Code]]：通过代码定义和管理基础设施，Terraform/Terragrunt 为核心工具
+- [[Terraform]]：基础设施即代码工具，HCL 配置文件定义云资源
+- [[Terragrunt]]：Terraform 包装器，支持 DRY 配置、依赖管理和版本控制
+- [[Service-Catalog]]：服务目录，分 Terraform Service Catalog（跨产品团队）和产品团队 Service Catalog 两层
+- [[Module]]：Terraform 模块，技术层面的可复用组件
+- [[Service]]：业务服务视角的封装，抽象多个 Module 满足单一业务需求
+- [[Landing-Zone]]：AWS Landing Zone，多账号基础设施框架
 
 ## Key Entities
-- [[AWS Landing Zone]]：AWS 多账户环境框架，是本文档讨论的基础部署上下文
-- [[Gruntwork]]：提供 Terraform 模块参考架构的公司，本文多次引用其作为最佳实践模型
-- [[Product Team]]：在 Landing Zone 中部署工作负载的业务团队，拥有独立的账户集合
+- [[Terraform]]：IaC 工具，HCL 配置文件定义云资源
+- [[Terragrunt]]：Terraform 包装器，实现 DRY 配置和依赖管理
+- [[Gruntwork]]：参考架构和服务目录提供商
+- [[Jenkins]]：CI/CD 工具，可与 Terraform/Terragrunt 集成
+- [[DevTools]]：示例产品团队，部署 Artifactory 和 Active Directory
 
 ## Connections
 - [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← foundational ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
-- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
-- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← related ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
-- [[ctp-topic-33-an-introduction-to-gitops]] ← extends ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← extends ← [[Terraform]]（核心 IaC 工具）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← extends ← [[Terragrunt]]（版本控制和依赖管理）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← extends ← [[Service-Catalog]]（模块复用架构）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← related ← [[ctp-topic-48-terraform-vs-terragrunt]]（Terragrunt 详细对比）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← related ← [[ctp-topic-56-automated-infrastructure-testing]]（自动化测试）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← related ← [[ctp-topic-16-cross-account-terraform-modules]]（跨账户模块）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← related ← [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 上下文）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← related ← [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD 集成）
 
 ## Contradictions
-- 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 的 Atlantis 部分存在约束差异：
-  - 冲突点：Atlantis 对 EKS 部署的支持能力
-  - 当前观点（Topic 3）：Terragrunt 可用于所有基础设施部署，包括 EKS
-  - 对方观点（Topic 39）：Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代
-  - 评估：Topic 39 提供更具体的实践经验，Topic 3 提供通用原则，两者约束条件不同不构成直接矛盾
+- 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]：
+  - 冲突点：Topic 1 强调 Gruntwork Reference Architecture 提供最佳实践起点；Topic 3 强调产品团队自主定义具体服务
+  - 当前观点：Topic 3 认为产品团队在 LZ 框架内自主管理 Service Catalog
+  - 对方观点：Topic 1 认为 Gruntwork Reference Architecture 是标准化起点，产品团队基于此定制
+  - 说明：两者实际互补——Topic 1 提供架构框架，Topic 3 描述具体部署机制
+
+- 与 [[ctp-topic-48-terraform-vs-terragrunt]]：
+  - 冲突点：Topic 3 明确推荐 Terragrunt HCL 引用版本（而非 master）；Topic 48 可能涉及 Terragrunt 选型讨论
+  - 当前观点：Terragrunt 版本锁定是最佳实践
+  - 对方观点：（待交叉验证）
+  - 说明：属深度递进关系，Topic 48 补充 Terragrunt vs Terraform 的详细对比

wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md

@@ -1,79 +1,57 @@
 ---
 title: "CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments"
 type: source
-tags: [Atlantis, CI/CD, IaC, Terraform, GitOps, CTP]
-date: 2026-04-14
+tags:
+  - Atlantis
+  - CI/CD
+  - IaC
+  - Terraform
+  - GitOps
+date: 2026-04-29
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md]]
 
 ## Summary（用中文描述）
-
-### 核心主题
-Atlantis 作为 Terraform IaC 自动化工具，替代 Jenkins 用于 AWS Landing Zone 的基础设施部署流水线。
-
-### 问题域
-当前 Jenkins 流水线面临两大核心痛点：
-- **速度慢**：初始化时间长、多次代码克隆、顺序测试、ECS Deployer 预配置导致整个流程极慢
-- **复杂度高**：持续叠加功能以覆盖更多场景和边缘用例，导致流水线脆弱且易漂移
-
-### 方法/机制
-- **架构**：Atlantis 以单台 EC2 实例形式部署于每个 Landing Zone 的共享账户，通过 GitHub Enterprise Webhook 接收通知
-- **协作模型**：开发者直接在 GitHub Pull Request 上评论即可与 Atlantis 交互，无需单独账号和复杂集成
-- **跨账户访问**：通过在每个账户部署的 IAM 角色实现，支持简单和跨账户模块部署
-- **权限控制**：用户管理基于 GitHub 构建，构建日志以评论形式存储用于审计
-- **并行构建**：支持多模块 plan 和 apply 命令并发执行
-
-### 结论/价值
-Atlantis 提供更好的协作模型、简化的网络架构（Jenkins 需要大量 VPC Endpoints）、代码与基础设施同步更新（merge 前即应用变更），是替换 Jenkins 的理想方案。
+- 核心主题：Atlantis 作为 Terraform IaC 自动化工具，用于替代 Jenkins 执行基础设施部署
+- 问题域：当前 CI/CD 流水线速度慢（初始化时间长、多次代码克隆、顺序测试、ECS Deployer 预配置）、复杂度高（持续修修补补导致脆弱和漂移）
+- 方法/机制：Atlantis 部署在每个 Landing Zone 的 Shared Account 中单一 EC2 实例上，通过 GitHub Enterprise Webhook 接收通知，用户在 PR 上评论 `atlantis plan/apply` 触发操作；内置 Locking 机制防止并发冲突，支持并行构建和跨账户角色访问
+- 结论/价值：Atlantis 通过合并前 Apply 的机制确保代码与基础设施同步，提供更优协作模型、简化网络架构、节省 VPC 端点成本
 
 ## Key Claims（用中文描述）
-
-- Atlantis 团队通过在 PR 上评论即可完成 plan/apply，无需独立的 Jenkins 账号和集成
-- Atlantis 在代码 merge 前即执行变更，确保代码始终与基础设施同步
-- Atlantis 锁定机制防止多 PR 同时对同一模块执行 plan 产生冲突
-- Atlantis 通过 Webhook 接收 GitHub 通知，服务账号负责与 GitHub 交互（评论、合并、关闭 PR）
+- Atlantis 团队使用 Atlantis 替代 Jenkins 进行基础设施部署，解决了原流水线速度慢的问题
+- Atlantis 部署在每个 Landing Zone 的 Shared Account 中单一 EC2 实例上，通过 GitHub Enterprise Webhook 与代码库集成
+- Atlantis 支持模块级 Locking：Plan 运行时锁定模块目录，直到 PR 合并、关闭或 Plan 被丢弃才释放，防止并发冲突
+- Atlantis 通过声明模块和数据文件依赖关系实现依赖触发计划（依赖变更自动触发相关模块的 Plan）
+- Atlantis 支持并行构建，对多个模块同时运行 Plan 和 Apply 命令
 
 ## Key Quotes
-
-> "The current pipeline is practically very slow due to significant initialization time, multiple code cloning, sequential testing, and ECS deployer provisioning." — 当前 Jenkins 流水线的性能痛点
-
-> "Atlantis applies changes before merging, ensuring code in sync with infrastructure." — Atlantis 的核心价值主张
-
-> "When a plan is run, the directory of each module is locked until the pull request that has this folder locked is merged or closed, or the plan is manually discarded." — Atlantis 锁定机制
+> "The current pipeline is practically very slow due to significant initialization time, multiple code cloning, sequential testing, and ECS deployer provisioning." — 原流水线速度瓶颈描述
+> "Atlantis applies changes before merging, ensuring code in sync with infrastructure." — Atlantis 核心价值：合并前 Apply，确保代码与基础设施同步
+> "When a plan is run, the directory of each module is locked until the pull request that has this folder locked is merged or closed, or the plan is manually discarded." — Atlantis Locking 机制说明
 
 ## Key Concepts
-
-- [[Infrastructure-as-Code]]：通过 Terraform 代码声明式管理 AWS 基础设施，Atlantis 是其 CI/CD 执行层
-- [[GitOps]]：以 Git 为单一事实来源，通过 PR 协作和 Atlantis 自动化 apply 实现 GitOps 工作流
-- [[CI/CD Pipeline]]：持续集成/持续部署流水线，Atlantis 替代传统 Jenkins 流水线用于 IaC 场景
-- [[Terraform]]：HashiCorp 的基础设施即代码工具，Atlantis 的核心执行对象
+- [[Atlantis]]：开源、自托管的 Terraform 自动化工具，通过 GitHub PR 评论触发 Plan/Apply 操作，替代传统 CI/CD 流水线执行 IaC 部署
+- [[Terraform]]：基础设施即代码（IaC）工具，用于声明式定义和配置云基础设施
+- [[GitOps]]：基于 Git 仓库作为单一事实来源的基础设施和应用程序交付方法论，Atlantis 是 GitOps 落地的核心工具
+- [[Infrastructure as Code (IaC)]]：通过代码管理和配置基础设施的实践，Terraform 是主流 IaC 工具之一
+- [[CI/CD Pipeline]]：持续集成/持续交付流水线，Atlantis 在 IaC 场景下替代了传统 Jenkins 流水线
 
 ## Key Entities
-
-- [[Terraform]]：Atlantis 管理的基础设施即代码工具，替代手动控制台操作
-- [[Jenkins]]：被 Atlantis 替代的现有 CI/CD 系统，存在初始化慢和架构复杂的问题
-- [[GitHub Enterprise]]：Atlantis 的事件来源，通过 Webhook 通知 Atlantis 执行 plan/apply
+- [[Atlantis]]：本视频核心产品 — 开源 Terraform CI/CD 自动化工具，替代 Jenkins 用于基础设施部署
+- [[Jenkins]]：Atlantis 所替代的传统 CI/CD 工具 — 存在初始化慢、复杂度高、脆弱等问题
+- [[GitHub Enterprise]]：Atlantis 的协作平台 — 通过 Webhook 与 Atlantis 通信，用户通过 PR 评论触发 Plan/Apply
 
 ## Connections
-
-- [[ctp-topic-33-an-introduction-to-gitops]] ← extends ← [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Topic 33 介绍 GitOps 概念，Topic 32 展示 Atlantis 工具实现）
-- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Topic 9 介绍 Gruntwork CI/CD，Topic 32 进一步细化为 Atlantis 替代方案）
-- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← depends_on ← [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Topic 3 部署和维护基础设施，Topic 32 提供具体 CI/CD 工具）
-- [[ctp-topic-16-cross-account-terraform-modules]] ← relates_to ← [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（跨账户 Terraform 模块与 Atlantis 跨账户访问机制关联）
+- [[CTP Topic 33 An Introduction to GitOps]] ← is_implemented_by ← [[CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments]]
+- [[CTP Topic 9 CI CD with Gruntwork]] ← shares_pattern ← [[CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments]]（均涉及 IaC 自动化）
+- [[CTP Topic 56 Automated Infrastructure Testing]] ← relates_to ← [[CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments]]（Terraform 测试为 Atlantis Plan 阶段的一部分）
+- [[CTP Topic 55 AWS Firewall Manager]] ← uses ← [[Atlantis]]（Firewall Manager 策略通过 Atlantis CI/CD 流水线部署）
+- [[Jenkins]] ← replaced_by → [[Atlantis]]（在 IaC 部署场景下的替代关系）
 
 ## Contradictions
-
-- 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]：
-  - **冲突点**：EKS 部署是否支持 Atlantis
-  - **当前观点（Topic 39）**：Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代
-  - **对方观点（Topic 32）**：Atlantis 可替代 Jenkins 用于所有 Terraform IaC 部署
-  - **分析**：两者描述的语境不同——Topic 39 聚焦特定 EKS 场景下的实践经验，Topic 32 描述 Atlantis 整体优势。可能 Atlantis 在某些复杂场景（如 EKS 特定依赖）下存在限制，需进一步验证
-
-## Source Metadata
-
-- **Category**: DevOps & SRE / 06_CI_CD_GitOps
-- **Type**: Video（CTP Learning Session）
-- **Status**: Summarized（Gemini 摘要）
-- **Video Source**: NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4`
+- 与 [[Jenkins]] 的传统 CI/CD 模式：
+  - 冲突点：Atlantis 主张合并前 Apply，Jenkins 传统模式通常为合并后部署
+  - 当前观点：Atlantis 认为合并前 Apply 能确保代码与基础设施始终同步，减少漂移风险
+  - 对方观点：传统 Jenkins 流水线通过自动化测试后合并部署，更符合 DevOps 最佳实践

wiki/sources/ctp-topic-33-an-introduction-to-gitops.md

@@ -8,6 +8,7 @@ tags:
   - DevOps
   - Infrastructure as Code
 date: 2026-04-14
+last_updated: 2026-05-09
 ---
 
 ## Source File

wiki/sources/ctp-topic-37-secrets-certificates-management.md

@@ -17,12 +17,12 @@ date: 2026-04-14
 - 核心主题：云转型计划中的密钥与证书管理解决方案选型与实施
 - 问题域：工作负载迁移至公有云过程中的密钥管理标准化需求，涉及应用服务特权账号、API密钥、Tokens等敏感凭证的安全管理
 - 方法/机制：通过30天试点对比评估 AWS Secrets Manager 与 HashiCorp Vault，最终选定 AWS Secrets Manager；实施阶段从 CI/CD 流程中清除明文密码和密钥，集中化管理并自动化密钥获取
-- 结论/价值：AWS Secrets Manager 以更低成本和更简实施胜出；AWS 在账户级别管理密钥可降低成本并提升安全性
+- 结论/价值：AWS Secrets Manager 以更低成本和更简实施体验胜出；AWS 在账户级别管理密钥可降低成本并提升安全性
 
 ## Key Claims（用中文描述）
 - AWS Secrets Manager 通过内置集成 RDS/Redshift/DynamoDB 和高可用/DR 能力，以按用量计费模式提供简单实施体验
 - HashiCorp Vault 免费版缺乏企业级能力（高可用、多租户），企业版按用户数收费
-- Micro Focus PAM 因需要大量投资才能具备竞争力且缺乏投资计划而被放弃
+- CyberArk Micro Focus PAM 因需要大量投资才能具备竞争力且缺乏投资计划而被放弃
 - AWS Secrets Manager 的 30 天试点验证了开箱即用功能，同时识别出缺失功能（SSH 密钥轮换、用户密码轮换）
 - 实施阶段首先从 Control Tower 开始，从 CI/CD 流程中清除明文密码和密钥
 
@@ -32,15 +32,14 @@ date: 2026-04-14
 > "AWS manages secrets at the account level, which can reduce costs and increase security." — 实施阶段核心理念
 
 ## Key Concepts
-- [[Secrets-Management]]：数字认证凭证（密码、密钥、API、Tokens）的管理工具和方法论，确保应用服务、特权账号等敏感信息的安全存储与访问控制
-- [[AWS-Secrets-Manager]]：AWS 托管的密钥管理服务，提供内置 RDS/Redshift/DynamoDB 集成，支持高可用和灾难恢复，按用量计费
-- [[HashiCorp-Vault]]：自托管、云厂商无关的密钥管理解决方案，支持按需动态密钥和嵌入式证书签名，按用户数收费
-- [[PAM（Privileged-Access-Management）]]：特权访问管理，通过 CyberArk Micro Focus PAM 实现特权账号的安全管控
-- [[Secret-Rotation]]：密钥轮换机制，自动定期更换密钥以降低泄露风险，AWS Secrets Manager 支持数据库凭证自动轮换
+- [[SecretsManagement]]：数字认证凭证（密码、密钥、API、Tokens）的管理工具和方法论，确保应用服务、特权账号等敏感信息的安全存储与访问控制
+- [[SecretRotation]]：密钥轮换机制，自动定期更换密钥以降低泄露风险，AWS Secrets Manager 支持数据库凭证自动轮换
+- [[Privileged-Access-Management]]：特权访问管理，通过 CyberArk Micro Focus PAM 实现特权账号的安全管控
 - [[CI/CD-Secrets]]：CI/CD 流程中的密钥管理，从明文存储迁移至集中化密钥管理服务
+- [[HashiCorp]]（Entity）：Vault 产品提供方，开源版和商业企业版均参与评估
 
 ## Key Entities
-- [[Micro-Focus]]：企业客户，云转型计划（CTP）的主体，评估并选定 AWS Secrets Manager 作为密钥管理方案
+- [[MicroFocus]]：企业客户，云转型计划（CTP）的主体，评估并选定 AWS Secrets Manager 作为密钥管理方案
 - [[CCLE]]：Cloud Center of Excellence 团队，2022年3月负责探索 Micro Focus 用例并评估密钥管理解决方案
 - [[AWS]]：云服务提供商，AWS Secrets Manager 的提供方
 - [[HashiCorp]]：Vault 产品提供方，开源版和商业企业版均参与评估

wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md

@@ -5,51 +5,54 @@ tags:
   - Terraform
   - Terragrunt
   - IaC
-  - DevOps
   - CTP
+  - DevOps
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md]]
 
 ## Summary（用中文描述）
-- 核心主题：Terraform 与 Terragrunt 的对比选型，涵盖企业级 IaC 实践
-- 问题域：多环境配置管理、基础设施代码复用、状态文件管理
-- 方法/机制：Terraform 作为核心 IaC 工具（云厂商无关），Terragrunt 作为 Terraform 的 DRY 封装层，处理跨环境变量和远程状态的重复声明
-- 结论/价值：Terraform 与 Terragrunt 命令和语法高度一致，但 Terragrunt 通过减少硬编码、提升可复用性来优化大规模企业部署；两者可互补使用
+- 核心主题：Terraform 与 Terragrunt 的深度对比分析，帮助工程师在战略设计层面和开发调试层面理解两者的差异与适用场景
+- 问题域：IaC 工具选型、多云环境管理、企业级 Terraform 状态管理
+- 方法/机制：Terraform 由 HashiCorp 开发的 Golang 应用，通过状态文件将期望状态绑定到实际环境；Terragrunt 作为 Terraform 的轻量级包装器，践行 DRY 原则，通过模板化管理 provider 和 remote state 块，避免多环境重复声明
+- 结论/价值：两者命令和语言高度一致，但定位不同——Terraform 保持云无关的核心能力，Terragrunt 优化跨环境的可复用性和配置 DRY
 
 ## Key Claims（用中文描述）
-- Terraform（HashiCorp 出品）通过状态文件将期望状态与现有环境绑定，企业级使用须将状态文件存储在安全可访问的位置
-- Terragrunt 是 Terraform 的轻量封装，贯彻 DRY 原则，通过管理 provider 和 remote_state 块减少跨环境的重复声明
-- Terraform Enterprise 提供带 workspace 的 CI 平台，Gruntwork 提供预建可定制模块，Atlantis 实现 Git 驱动的自动化部署
-- tfsec 用于静态代码安全分析，Terratest 用于基础设施测试自动化
+- Terraform 由 HashiCorp 开发，通过状态文件将基础设施的期望状态与实际运行环境绑定，企业级使用必须将状态文件存放在安全可访问的位置
+- Terragrunt 是 Terraform 的轻量包装器，践行 DRY 原则，将 provider 和 remote state 配置抽取为可复用模板，避免跨多环境重复硬编码
+- Terraform 与 Terragrunt 在命令和语言层面高度一致，Terragrunt plan 即 Terraform plan，HCL 语法完全兼容
+- Terraform Enterprise 提供 CI 平台和 workspaces；Gruntwork 提供预构建可定制模块和原生 AWS landing zone 方案
+- Atlantis 将 Terraform 与 GitHub 深度集成，实现 Pull Request 驱动的自动化基础设施部署
 
 ## Key Quotes
-> "Terraform ties the desired state to the existing environment using a state file. For enterprise-scale use, storing this file in a safe, accessible location is crucial." — Bob, AWS Solutions Architect
-> "Terragrunt offers a way to use information in a repeatable way without hard coding values." — Bob
-> "All Terraform commands work with Terragrunt; a Terraform plan becomes a Terragrunt plan." — Bob
+> "To run Terraform consistently, it ties the desired state to the existing environment using a state file." — Terraform 状态管理的核心机制说明
+> "Terragrunt offers a way to use information in a repeatable way without hard coding values." — Terragrunt 践行 DRY 原则的核心价值
+> "Terraform's core is cloud-agnostic, while its vendor-specific parts require separate modules for each cloud provider." — Terraform 厂商相关性的局限
 
 ## Key Concepts
-- [[Infrastructure As Code]]：通过代码定义和版本控制基础设施资源的实践
-- [[DRY Principle]]：Don't Repeat Yourself — 避免重复配置，通过抽象层复用
-- [[State File Management]]：Terraform 用状态文件绑定期望状态与实际环境
-- [[IaC Testing]]：用 Terratest 等工具对基础设施代码进行自动化测试
+- [[InfrastructureAsCode]]：通过代码定义和管理基础设施，实现版本控制和自动化部署
+- [[DrYPrinciple]]（Don't Repeat Yourself）：Terragrunt 的核心理念，通过模板复用减少配置重复
+- [[TerraformState]]：Terraform 通过状态文件将代码定义的期望状态与实际运行环境绑定
+- [[Terragrunt]]：Terraform 的轻量包装器，优化多环境配置管理
 
 ## Key Entities
-- [[HashiCorp]]：Terraform 创立公司，提供多云基础设施编排工具
-- [[Gruntwork]]：提供预建可定制的 Terraform 模块和 Terraform 原生 AWS Landing Zone
-- [[Atlantis]]：将 Terraform 与 GitHub 集成的开源 CI/CD 工具
-- [[Terraform]]：云厂商无关的基础设施即代码工具
-- [[Terragrunt]]：Terraform 的 DRY 封装层，管理多环境配置
+- [[HashiCorp]]：Terraform 的创始公司，开发和维护 Terraform 核心产品
+- [[Gruntwork]]：提供预构建 Terraform 模块库和 AWS landing zone 方案的 SaaS 平台
+- [[Atlantis]]：开源工具，将 Terraform 与 GitHub/GitLab 集成，实现 PR 驱动的 IaC 自动化
+- [[TerraformEnterprise]]：HashiCorp 提供的 Terraform 企业版，包含 CI 平台和 workspace 功能
 
 ## Connections
-- [[Terraform]] ← uses ← [[State File Management]]
-- [[Terragrunt]] ← wraps ← [[Terraform]]
-- [[Terraform]] ← provided_by ← [[HashiCorp]]
-- [[Gruntwork]] ← provides_modules_for ← [[Terraform]]
-- [[Atlantis]] ← integrates_with ← [[Terraform]]
-- [[Terraform]] ← related_concept ← [[Infrastructure As Code]]
+- [[Gruntwork]] ← uses ← [[Terraform]]
+- [[Gruntwork]] ← uses ← [[Terragrunt]]
+- [[Atlantis]] ← extends ← [[Terraform]]（CI/CD 集成）
+- [[TerraformEnterprise]] ← is_enterprise_version_of ← [[Terraform]]
 
 ## Contradictions
-- 暂无发现与其他 Wiki 页面的直接冲突
+- 无已知冲突内容
+
+## Related Pages
+- [[CTP Topic 9 CI CD with Gruntwork]] — Gruntwork 在 CI/CD 中的实际应用
+- [[CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments]] — Atlantis 集成详解
+- [[CTP Topic 16 Cross-account Terraform modules]] — 跨账户 Terraform 模块管理

wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md

@@ -1,62 +1,60 @@
 ---
 title: "CTP Topic 49 Container Lifecycle Hardening Standards"
 type: source
-tags: [Container, Security, Hardening, CTP, Kubernetes, Docker]
-sources: []
-last_updated: 2026-04-24
+tags:
+  - Container
+  - Security
+  - Hardening
+  - Kubernetes
+  - CTP
+date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards]]
 
 ## Summary（用中文描述）
-- 核心主题：Micro Focus 产品安全小组（Product Security Group）制定的容器镜像构建阶段（Building）安全加固标准，提供 11 条可操作的安全实践指南。
-- 问题域：容器镜像构建安全——如何避免引入已知漏洞、敏感信息和错误配置到容器化工作负载中。
-- 方法/机制：围绕 11 条安全标准逐条说明背景风险（Why）和缓解措施（How），辅以 Kubernetes YAML 配置示例演示。
-- 结论/价值：为容器镜像构建提供标准化安全基线，配合 Demo 直观展示配置效果，是 [[DevSecOps]] 实践在容器层面的具体落地。
+- 核心主题：Micro Focus 容器镜像构建安全加固标准，聚焦容器生命周期的构建（Build）阶段
+- 问题域：企业级 Kubernetes 容器环境的安全基线配置
+- 方法/机制：11 项安全标准，涵盖基础镜像选择、文件系统权限、进程管理、网络隔离、身份认证等
+- 结论/价值：提供可落地的容器安全加固实践，配合 Demo 演示验证风险缓解效果
 
 ## Key Claims（用中文描述）
-- Micro Focus 基础镜像（Micro Focus Base Image）比开源默认镜像更安全——经过安全配置，内置非 root 和非特权（non-root and non-privileged）设置，避免开源默认镜像中的已知漏洞。
-- 引入 Init 系统（如 [[tini]] / [[tini Init System]]）可防止僵尸进程（Zombie Process）耗尽系统资源——Demo 展示了 [[tini]] 在 Kubernetes 环境中阻止僵尸进程的效果。
-- 将容器根文件系统设为只读（readOnlyRootFilesystem: true）可阻止攻击者篡改文件系统——Demo 展示了设置该标志后容器内无法创建未授权文件。
-- 使用 [[Kubernetes Secrets]] 替代将敏感信息硬编码在镜像中——敏感数据应在运行时从 Secret 管理机制获取，而非构建时嵌入镜像。
-- [[emptyDir Volume]] 用于临时文件系统比主机路径更安全——数据随 Pod 删除自动清理，防止敏感信息残留。
-- 每个容器仅运行单一应用——防止单个应用被攻陷后干扰同一容器中其他应用的进程。
-- 设置 automountServiceAccountToken: false 禁用 Kubernetes API 自动挂载——限制被攻陷容器对集群 API 的访问范围，降低权限提升风险。
-- 使用私有服务账号（Private Service Account）配合精确的 Namespace Role 和 Role Binding——替代默认服务账号，遵循最小权限原则。
-- 避免使用 hostNetwork 和 hostPort——防止端口冲突和维护网络隔离，减少容器逃逸攻击面。
+- 使用 Micro Focus 基础镜像可避免开源默认镜像的安全漏洞（配置为安全模式，无可信/非可信组件混合）
+- 集成 Init 系统（如 tini/teeny）可防止僵尸进程耗尽资源，影响容器稳定性
+- 设置 readOnlyRootFilesystem=true 可阻止恶意攻击者向容器写入文件
+- 使用 emptyDir 卷替代 hostPath 可确保 Pod 删除时敏感数据自动清理
+- 禁用 automountServiceAccountToken 可限制容器被攻破后访问 Kubernetes API 的风险
+- 每个容器只运行单一应用可防止进程间相互干扰，一个应用被攻破不会影响其他应用
+- 避免使用 host 网络和 host 端口可维护网络隔离，防止端口冲突
 
 ## Key Quotes
-> "If one application is compromised process in one application can interfere with the process of other application in the same container." — Ashish, Product Security Group, 说明为何容器应运行单一应用
-> "Use micro focus base image which are configured to be secure with non and trust weighted components." — Ashish, 说明 Micro Focus 基础镜像的安全配置特性
-> "teeny prevents zombie processes in Kubernetes." — Ashish, 演示 [[tini]] Init 系统在 Kubernetes 中的作用
+> "Use Micro Focus base image which are configured to be secure with non and trust weighted components." — Micro Focus 基础镜像安全配置原则
+> "If one application is compromised process in one application can interfere with the process of other application in the same container." — 单应用容器化原则的原因
+> "Setting automountServiceAccountToken to false can limit the impact of potential compromises." — Kubernetes API 访问控制
 
 ## Key Concepts
-- [[Container Lifecycle Hardening]]：容器全生命周期安全加固，涵盖构建（Build）、部署（Deploy）、运行（Run）三个阶段。本视频聚焦构建阶段。
-- [[tini Init System]]：轻量级 Init 系统，用于容器内正确处理信号和收割僵尸进程，与 [[tini]] 同义。
-- [[Kubernetes RBAC]]：基于角色的访问控制，通过 Role/RoleBinding/Namespace 机制实现最小权限服务账号管理。
-- [[Kubernetes Secrets]]：Kubernetes Secret 对象，用于在运行时向容器安全传递敏感信息（如密码、API 密钥），而非将其嵌入镜像。
-- [[Pod Security Context]]：Pod 安全上下文，定义 Pod 级别的安全设置（如 readOnlyRootFilesystem、automountServiceAccountToken）。
-- [[emptyDir Volume]]：Kubernetes emptyDir 卷类型，挂载临时文件系统，数据随 Pod 生命周期自动清理。
-- [[Container Image Scanning]]：镜像漏洞扫描，通过自动化工具识别镜像中的已知安全漏洞并提供修复建议。
-- [[Kubernetes RBAC]]：Role-Based Access Control，基于角色的访问控制，用于限制 Service Account 对 Kubernetes API 的访问权限。
+- [[Container Hardening]]：通过配置和策略提升容器安全性的一组最佳实践
+- [[Read-Only Root Filesystem]]：将容器根文件系统设为只读，防止运行时写入恶意文件
+- [[Init System in Containers]]：容器内的初始化进程（如 tini/teeny），负责处理信号和回收僵尸进程
+- [[Kubernetes Security Context]]：Pod/容器级别的安全配置，包括 readOnlyRootFilesystem、automountServiceAccountToken 等
+- [[Container Image Scanning]]：使用扫描工具识别镜像中的已知漏洞（CVE）
+- [[Principle of Least Privilege]]：最小权限原则——使用私有服务账号而非默认账号
+- [[Network Isolation]]：避免 host 网络/端口以维持容器的网络边界隔离
 
 ## Key Entities
-- [[Ashish]]：Micro Focus Product Security Group 成员，本视频主讲人，负责介绍容器生命周期安全加固标准。
-- [[Micro Focus]]：企业软件公司，拥有自己的容器基础镜像仓库和安全加固标准体系。
-- [[Product Security Group]]：Micro Focus 产品安全小组，制定容器安全标准和最佳实践。
-- [[Kubernetes]]：容器编排平台，是本视频所有安全配置的实施环境。
-- [[tini]]：容器 Init 系统开源项目，解决容器内僵尸进程和信号转发问题。
+- [[Ashish]]：Product Security Group 成员，本主题演讲者
+- [[Micro Focus]]：容器加固标准的制定者，提供安全配置的基础镜像
+- [[Product Security Group]]：负责制定和维护 Micro Focus 容器安全标准的团队
+- [[Kubernetes]]：容器编排平台，相关的安全配置包括 ServiceAccount、RBAC、NetworkPolicy
 
 ## Connections
-- [[ctp-topic-21-supply-chain-security-in-micro-focus]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：供应链安全与容器镜像安全同属 [[DevSecOps]] 范畴，供应链安全关注 CI/CD 过程完整性，容器安全关注镜像内容安全。
-- [[DevSecOps]] ← extends ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：容器镜像加固是 DevSecOps 在容器领域的具体实践，DevSecOps 强调安全左移（Shift-Left）。
-- [[ctp-topic-70-eks-deployment-using-iac]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：EKS 部署的容器运行时安全配置与本视频的镜像构建标准互补，共同构成容器全生命周期安全。
-- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：EKS 可靠性最佳实践中的 Pod 安全配置与本视频标准一致。
+- [[CTP Topic 21 Supply Chain Security in Micro Focus]] ← related_to ← [[CTP Topic 49 Container Lifecycle Hardening Standards]]
+- [[CTP Topic 37 Secrets Certificates Management]] ← extends ← [[CTP Topic 49 Container Lifecycle Hardening Standards]]（密钥管理是容器安全的一部分）
+- [[CTP Topic 64 Scaling out with Amazon EKS]] ← depends_on ← [[CTP Topic 49 Container Lifecycle Hardening Standards]]（EKS 运行需要遵循容器加固标准）
 
 ## Contradictions
-- 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 的 hostNetwork 配置存在潜在冲突：
-  - 冲突点：Topic 39 中提到 Pod 规范设置 `hostNetwork: true` 以访问内部 Micro Focus 网络和外部资源。
-  - 当前观点（Topic 49）：应避免使用 hostNetwork 以维护网络隔离和防止端口冲突。
-  - 对方观点（Topic 39）：在受限 Lab Landing Zone 网络环境下，hostNetwork 是打通混合网络的必要手段。
-  - 说明：两者的差异源于场景不同——Topic 39 针对的是 IP 地址池不足的受限 Lab 环境，是特例；Topic 49 是通用安全最佳实践，适用于大多数生产场景。
+- 与 [[Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS]] 可能的冲突：
+  - 冲突点：Bottlerocket OS 使用自己的安全模型，CTP Topic 49 推荐 Micro Focus 基础镜像
+  - 当前观点：企业内使用 Micro Focus 基础镜像进行统一安全管理
+  - 对方观点：Bottlerocket OS 提供原生硬化（hardened）操作系统层，两种方案各有适用场景

wiki/sources/ctp-topic-55-aws-firewall-manager.md

@@ -1,49 +1,65 @@
 ---
 title: "CTP Topic 55 AWS Firewall Manager"
 type: source
-tags: [AWS, Firewall-Manager, Security, CTP, Landing-Zones]
+tags:
+  - AWS
+  - Firewall-Manager
+  - Security
+  - CTP
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-55-aws-firewall-manager.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-55-aws-firewall-manager]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践
-- 问题域：跨多个 Landing Zone（RLABS、R&D、SAS、CAT）管理安全策略的复杂性，Checkpoint Firewall 无法覆盖的流量安全问题
-- 方法/机制：通过 Firewall Manager 账户创建安全组策略，使用 AWS Config + Lambda 触发事件自动修复，结合 RAM 共享前缀列表实现跨账户规则同步
-- 结论/价值：集中化管理、缩短安全策略部署时间、解决 QALIS 等共享服务扫描问题；支持 WAF 规则统一管理
+- 核心主题：AWS Firewall Manager 在多 Landing Zone 环境下的集中化安全策略管理
+- 问题域：跨多个 Landing Zone（RLABS、R&D、SAS、CAT）统一管理和执行安全组规则
+- 方法/机制：
+  - 三类安全策略：通用安全组（Common SG）、审计与强制执行（Audit & Enforcement SG）、冗余清理（Cleanup SG）
+  - 利用 AWS Config + Lambda 触发事件并强制执行策略
+  - 通过 RAM（Resource Access Manager）共享 Prefix List，实现跨账户规则分发
+  - Firewall Manager 账户独立部署，支持跨 Landing Zone 统一纳管
+  - 支持通过 Terraform + Terragrunt 自动化部署策略
+- 结论/价值：将安全策略从各 Landing Zone 分散管理转变为集中管控，大幅降低策略推广时间，支持 WAF 规则统一管理
 
 ## Key Claims（用中文描述）
-- Firewall Manager 可跨多个 Landing Zone 统一部署基线安全组策略，解决多环境安全策略不一致问题
-- 三种安全策略类型：通用安全组（附加基线允许产品团队自增）、审计与强制安全组规则（拒绝过度宽松规则，支持自动修复）、清理未使用冗余安全组
-- Firewall Manager 账户独立于任何 Landing Zone，支持跨 Landing Zone 部署
-- RAM 前缀列表机制可跨账户轻松共享和更新安全组规则
+- Firewall Manager 通过 AWS Config + Lambda 机制自动检测并修复不合规资源，实现跨账户统一安全策略执行
+- 三类安全组策略分别承担"附加基线"、"拒绝过度宽松规则"、"清理冗余"职责，形成完整的安全管控闭环
+- Prefix List + RAM 组合实现安全规则在账户间的便捷共享与同步更新，无需手动逐账户配置
+- Firewall Manager 账户独立于任何单一 Landing Zone，可同时纳管 RLABS、R&D、SAS、CAT 等多个环境
+- SAS Landing Zone 账户的所有安全组均作为基线安全组应用，由 Firewall Manager 统一管控
 
 ## Key Quotes
-> "We have gone through these policies and we come up with some baseline security groups." — 团队审查现有策略后制定基线安全组
-> "RAM is like it's a tool available within this AWS where you can specify or you can share your AWS resources to any other account that you wanted to specify." — RAM 用于跨账户资源共享
-> Demo 演示：在 Firewall Manager 账户创建通用安全组策略后，关联的 playground 账户中已存在的 EC2 实例和新启动的 EC2 实例均自动附加了安全组；删除策略后安全组自动从实例移除
+> "Firewall Manager is a management service to centrally configure firewall rules and security rules across accounts and applications within organizations." — AWS Firewall Manager 核心定义
+> "RAM is like it's a tool available within this AWS where you can specify or you can share your AWS resources to any other account that you wanted to specify." — Prefix List 通过 RAM 共享的机制说明
+> "We have gone through these policies and we come up with some baseline security groups." — 多 Landing Zone 环境下的基线安全组制定背景
+> "Deleting the policy in the Firewall Manager account automatically removed the security group from the instances." — 策略删除自动清理附着实例
 
 ## Key Concepts
-- [[Security-Group]]：AWS 安全组，作为实例级别的有状态防火墙规则；Firewall Manager 三种策略均围绕安全组展开
-- [[Prefix-List]]：前缀列表，用于跨账户共享和更新安全组规则；通过 RAM 共享
-- [[Auto-Remediation]]：自动修复，Firewall Manager 策略可自动修复不合规的安全组规则
-- [[WAF-Rules-Management]]：Firewall Manager 还支持集中管理 WAF 规则，允许产品团队在基线规则上追加额外规则集
+- [[AWS Firewall Manager]]：AWS 集中化防火墙和安全规则管理服务，支持跨账户和跨应用程序的配置
+- [[Security Group Policy]]：Firewall Manager 中的安全组策略，分为 Common、Audit & Enforcement、Cleanup 三种类型
+- [[AWS Config]]：AWS 配置合规性评估服务，与 Firewall Manager 联动触发自动修复
+- [[AWS Lambda]]：无服务器计算服务，在 Firewall Manager 中用于执行策略事件处理逻辑
+- [[Prefix List]]：IP 前缀列表，用于定义 CIDR 范围，通过 RAM 在账户间共享安全规则
+- [[Resource Access Manager (RAM)]]：AWS 资源分享服务，允许跨账户共享 VPC Prefix List 等资源
+- [[Landing Zone]]：AWS 多账户环境的规范化基础设施架构，本文档涉及 RLABS、R&D、SAS、CAT 四个 Landing Zone
 
 ## Key Entities
-- [[AWS-Firewall-Manager]]：AWS Firewall Manager 是集中配置防火墙规则和安全规则的管理服务，支持跨组织和账户的统一安全策略部署
-- [[Landing-Zones]]：AWS Landing Zones，Grand Torque 存在 RLABS、R&D、SAS、CAT 多个 Landing Zone，各有不同的安全要求
-- [[QALIS]]：产品账户实例扫描服务，通过 Firewall Manager 解决跨账户扫描的网络可达性问题
-- [[Checkpoint-Firewall]]：原有防火墙方案，存在安全组规则过于宽松的问题，无法完全覆盖通过公网子网的流量
+- [[Grand Torque Landing Zone]]：整体 Landing Zone 架构，Firewall Manager 在此背景下被采用以应对多 Landing Zone 安全策略管理挑战
+- [[LAPS Landing Zone]]：早期使用 Checkpoint Firewall 的 Landing Zone，安全组规则较为宽松
+- [[SAS Landing Zone]]：面向外部客户的 Landing Zone，拥有公有子网，需要额外的安全规则保护
+- [[Digital Factory Landing Zone]]：部署 Atlantis 服务器的 Landing Zone，通过 IaC pipeline 向 Firewall Manager 推送变更
+- [[Atlantis Server]]：Digital Factory 中的 Terraform/Terragrunt 执行服务器，用于自动化部署 Firewall Manager 策略
+- [[QALIS]]：共享服务，扫描产品账户中的实例
 
 ## Connections
-- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← relates_to ← [[ctp-topic-55-aws-firewall-manager]]
-- [[ctp-topic-37-secrets-certificates-management]] ← same_domain ← [[ctp-topic-55-aws-firewall-manager]]（均属于 07_Security 类别）
-- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← related_security ← [[ctp-topic-55-aws-firewall-manager]]
+- [[AWS Firewall Manager]] ← 管理 ← [[Security Group Policy]]
+- [[Security Group Policy]] ← 触发执行 ← [[AWS Config]] + [[AWS Lambda]]
+- [[Security Group Policy]] ← 规则分发 ← [[Prefix List]] + [[Resource Access Manager (RAM)]]
+- [[AWS Firewall Manager]] ← 独立部署于 ← [[Digital Factory Landing Zone]]
+- [[AWS Firewall Manager]] ← 纳管 ← [[LAPS Landing Zone]]、[[SAS Landing Zone]] 等多个 Landing Zone
+- [[Terraform]] + [[Terragrunt]] ← 自动化部署 ← [[AWS Firewall Manager]] Policy
 
 ## Contradictions
-- 与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中的 Checkpoint Firewall 方案关系：
-  - 冲突点：Checkpoint Firewall 原有安全组规则过于宽松，新方案引入 Firewall Manager 基线安全组
-  - 当前观点：Firewall Manager 补充 Checkpoint，提供更细粒度的安全组基线控制
-  - 对方观点：Checkpoint 作为网络边界防火墙，Firewall Manager 覆盖实例级别安全策略（互补而非冲突）
+- 暂无发现与其他 Wiki 页面的直接内容冲突

wiki/sources/ctp-topic-62-aws-secrets-manager.md

@@ -1,59 +1,57 @@
 ---
 title: "CTP Topic 62 AWS Secrets Manager"
 type: source
-tags: []
+tags:
+  - AWS
+  - Secrets-Manager
+  - Security
+  - CTP
+  - Cloud-Transformation
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-62-aws-secrets-manager.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-62-aws-secrets-manager.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS Secrets Manager 企业级密钥管理方案，包括选型对比、实施标准和落地案例
-- 问题域：云转型过程中密钥安全存储与轮换的标准化治理
-- 方法/机制：分阶段实施策略（集中化密钥 → 自动化获取 → 轮换）；Lambda 函数驱动 Oracle 数据库密码轮换；SendGrid 集中邮件服务的密钥轮换方案；JDBC Wrapper + AWS SDK 无需应用感知密钥
-- 结论/价值：AWS Secrets Manager 相比 HashiCorp Vault 成本更低、实施更简单，无需客户端；开发者无需直接访问密钥，通过角色和标签实现安全访问控制
+- 核心主题：AWS Secrets Manager 在企业云转型项目中的实施与标准化
+- 问题域：如何在多账户、多团队的企业环境中集中管理 Secrets，实现安全的密码轮换
+- 方法/机制：采用渐进式方法：集中 Secrets → 调整自动化工具 → 启动自动轮换；通过 Lambda 函数配合 JDBC Wrapper 实现无密码数据库访问
+- 结论/价值：AWS Secrets Manager 相较 HashiCorp Vault 成本更低、实现更简单，无需客户端；与 Control Tower 集成可实现企业级 Secrets 管理标准化
 
 ## Key Claims（用中文描述）
-- AWS Secrets Manager 比 HashiCorp Vault 更具成本效益，被选定为最终方案
-- AWS Secrets Manager 易于实施，缺失功能可用多种语言自行开发
-- 分阶段实施策略：集中化密钥 → 调整自动化获取 → 启动轮换
-- 开发者无需直接访问密钥，密钥访问通过 IAM 角色控制
-- Lambda 函数可执行 Oracle 数据库密码轮换，无需人工介入
-- SendGrid 集中邮件服务实现 API 密钥轮换，无需应用重启
-- AWS Secrets Manager 无需客户端软件（对比 HashiCorp Vault）
+- AWS Secrets Manager 被选为 Secrets 管理平台，相比 HashiCorp Vault 更具成本效益
+- 三阶段实施方法：集中 Secrets → 调整自动化获取流程 → 启动轮换机制
+- 开发者无需直接访问 Secrets，通过角色和 AWS 凭证授权
+- Lambda 函数可连接 Oracle 数据库执行密码轮换，无需通过邮件发送密码
+- SendGrid API Key 轮换可通过集中式 SMTP 服务实现，无需应用重启
 
 ## Key Quotes
-> "AWS Secrets Manager is easy and simple to implement. Missing features can be developed in multiple languages." — Nurit & Daniel
-> "With that idea, developers actually do not need to have direct access to their Secrets." — Daniel
-> "Secrets can be tagged for classification and access control. AWS Secrets Manager does not require clients, unlike HashiCorp Vault." — Victor（Demo）
+> "AWS Secrets Manager is easy and simple to implement." — Nurit & Daniel, 实施经验总结
+> "With that idea, developers actually do not need to have direct access to their Secrets." — Secrets Management 标准化文档核心理念
+> "AWS Secrets Manager does not require clients, unlike HashiCorp Vault." — 技术对比结论
 
 ## Key Concepts
-- [[Secrets-Management（密钥管理）]]：云环境下集中存储、获取和轮换敏感凭证（密码、API 密钥、证书）的标准化实践
-- [[AWS-Secrets-Manager]]：AWS 托管的密钥管理服务，支持密钥轮换、IAM 角色访问控制和标签分类，无需客户端软件
-- [[Secret-Rotation（密钥轮换）]]：定期自动更新密钥的机制，AWS Secrets Manager 内置 Lambda 函数支持主流数据库和服务密钥轮换
-- [[JDBC-Wrapper]]：JDBC 包装器封装数据库连接，通过 AWS SDK 从 Secrets Manager 动态获取凭证，应用无需硬编码密码
-- [[AWS-Lambda]]：无服务器函数，用于执行 Oracle 数据库密码轮换等自动化任务
-- [[SendGrid]]：云邮件服务，API 密钥轮换通过集中化 SMTP 服务实现，无需应用重启
+- [[SecretsManagement]]：在云环境中集中存储、管理、安全轮换敏感凭据（密码、API Key、证书）的实践
+- [[SecretRotation]]：定期自动更换 Secrets 的机制，防止长期密钥泄露风险
+- [[JDBCWrapper]]：通过 JDBC 包装器配合 AWS SDK 从 Secrets Manager 动态获取数据库凭据，无需硬编码密码
+- [[ControlTower]]：AWS Control Tower 提供多账户治理和合规性管理
 
 ## Key Entities
-- [[Nurit]]：CTP Topic 62 主持人，AWS Secrets Manager 实施分享
-- [[Daniel]]：CTP Topic 62 主持人，AWS Secrets Management Standard 文档作者，深度解析实施机会
-- [[Victor]]：Demo 演示者，展示使用 JDBC Wrapper + AWS SDK 免密登录 Oracle 数据库
-- [[AWS-Secrets-Manager]]：AWS 密钥管理服务，企业选型最终方案
-- [[HashiCorp-Vault]]：密钥管理备选方案，POC 阶段对比后未被采用
-- [[AWS-Control-Tower]]：AWS 多账户治理服务，密钥管理方案基于其环境实施
-- [[SendGrid]]：邮件服务，API 密钥轮换通过集中化服务方案解决
+- [[Nurit]]：演讲者，AWS Secrets Manager 实施经验分享
+- [[Daniel]]：演讲者，AWS Secrets Management Standard 文档负责人
+- [[Victor]]：现场演示无需密码的 Oracle 数据库登录
+- [[HashiCorpVault]]：AWS Secrets Manager 的替代方案，POC 阶段被否决
+- [[AWSControlTower]]：多账户 AWS 环境治理平台
+- [[SendGrid]]：邮件服务提供商，API Key 轮换是实施机会之一
 
 ## Connections
-- [[ctp-topic-37-secrets-certificates-management]] ← relates_to ← [[ctp-topic-62-aws-secrets-manager]]
-- [[ctp-topic-36-sendgrid-as-an-email-service]] ← extends ← [[ctp-topic-62-aws-secrets-manager]]
-- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← depends_on ← [[AWS-Secrets-Manager]]
-- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-62-aws-secrets-manager]]
+- [[CTP-Topic-37-Secrets-Certificates-Management]] ← related_to ← [[CTP-Topic-62-AWS-Secrets-Manager]]
+- [[AWS-Control-Tower]] ← centralizes ← [[Secrets-Management]]
+- [[CTP-Topic-36-SendGrid-as-an-Email-Service]] ← relates_to ← [[SendGrid-API-Rotation]]
 
 ## Contradictions
-- 与 [[ctp-topic-37-secrets-certificates-management]] 存在覆盖范围差异：
-  - 冲突点：Topic 37 覆盖 Secrets 和 Certificates 两大类；Topic 62 仅聚焦 Secrets Management
-  - 当前观点：Topic 62 通过 AWS Secrets Manager 标准化 Secrets 管理，涵盖 Oracle DB 密码和 SendGrid API 密钥轮换
-  - 对方观点：Topic 37 认为密钥与证书管理应统一为同一标准框架
-  - 说明：两者可视为互补——证书管理（Certificates）由 Topic 37 覆盖，密钥管理（Secrets）由 Topic 62 深化
+- 与 [[HashiCorp-Vault]] 对比：
+  - 冲突点：两种 Secrets 管理方案的选型
+  - 当前观点：AWS Secrets Manager 被选中，因其成本更低、实现更简单
+  - 对方观点：HashiCorp Vault 在 POC 阶段被评估，但因成本原因未被采用

wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md

@@ -6,45 +6,44 @@ tags:
   - Gruntwork
   - IaC
   - CTP
-  - DevOps
-  - AWS
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md]]
 
 ## Summary（用中文描述）
-- 核心主题：CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践
-- 问题域：云转型计划（Cloud Transformation Programme, CTP）中的基础设施自动化交付
-- 方法/机制：基于 Gruntwork 参考架构，通过 CI/CD 流水线实现 Terraform/Terragrunt 代码的自动化部署
-- 结论/价值：待视频转录后补充
-
-> ⚠️ **注意**：原始视频尚未完成 Whisper 转录，以上信息基于文件元数据生成。详见 Source File 链接获取完整内容。
+- 核心主题：CTP Topic 9 — CI/CD 与 Gruntwork 基础设施即代码集成
+- 问题域：公有云学习课程系列，DevOps 与 GitOps 持续集成/持续部署实践
+- 方法/机制：使用 Gruntwork 基础设施即代码（IaC）框架实现自动化 CI/CD 流水线
+- 结论/价值：视频待 Whisper 转录后补充完整摘要
 
 ## Key Claims（用中文描述）
-- （待视频转录后补充）
+- （视频尚未转录，核心论点待补充）
 
 ## Key Quotes
-> （待视频转录后补充）
+> （视频尚未转录，引用待补充）
 
 ## Key Concepts
-- [[CI/CD Pipeline]]：持续集成/持续交付流水线，自动化代码构建、测试和部署流程
-- [[Infrastructure as Code (IaC)]]：通过代码管理云基础设施，实现可重复、可审计的部署
-- [[Gruntwork]]：提供生产级 Terraform 模块和参考架构的 IaC 库
-- [[Terraform]]：HashiCorp 开源的 IaC 工具，用于声明式定义云资源
-- [[Terragrunt]]：Terraform 的包装器，提供状态管理和模块复用能力
+- [[CI/CD]]：持续集成与持续部署（Continuous Integration / Continuous Deployment），通过自动化流水线实现代码到生产环境的快速、可靠交付
+- [[GitOps]]：（关联概念）基于 Git 声明式管理的运维实践，与 CI/CD 紧密相关
+- [[Infrastructure-as-Code]]：（关联概念）通过代码管理云基础设施，Gruntwork 是 IaC 框架的代表
 
 ## Key Entities
-- [[Gruntwork]]：IaC 基础设施库提供商，提供可复用的 Terraform 模块
-- [[AWS Landing Zone]]：AWS 多账户架构框架，为云工作负载提供安全、合规的基础设施
-- [[Cloud Transformation Programme (CTP)]]：云转型计划，Micro Focus 将工作负载从本地数据中心迁移至 AWS 的企业级项目
+- [[Gruntwork]]：提供 Terraform 模块、Packer AMI、Terragrunt 等 IaC 工具的公司，专注于 AWS 云基础设施自动化
 
 ## Connections
-- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← foundational ← [[ctp-topic-9-ci-cd-with-gruntwork]]
-- [[ctp-topic-2-git]] ← related ← [[ctp-topic-9-ci-cd-with-gruntwork]]
-- [[ctp-topic-33-an-introduction-to-gitops]] ← extends ← [[ctp-topic-9-ci-cd-with-gruntwork]]
-- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← alternative_tool ← [[ctp-topic-9-ci-cd-with-gruntwork]]
+- [[CTP Topic 33 An Introduction to GitOps]] ← related_to ← [[CTP Topic 9 CI CD with Gruntwork]]
+- [[CTP Topic 48 Terraform vs Terragrunt]] ← related_to ← [[CTP Topic 9 CI CD with Gruntwork]]
+- [[CTP Topic 3 Deploy and maintain infrastructure]] ← related_to ← [[CTP Topic 9 CI CD with Gruntwork]]
+- [[Gruntwork]] ← provides_IaC_framework ← [[CTP Topic 9 CI CD with Gruntwork]]
+- [[CI/CD]] ← core_practice ← [[CTP Topic 9 CI CD with Gruntwork]]
 
 ## Contradictions
-- （暂无，待视频转录后补充）
+- （暂无冲突记录）
+
+## Notes
+- **视频状态**：待 Whisper 转录（status: 🟡 Awaiting Whisper transcription → Summary）
+- **视频来源**：NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 9_ CI_CD with Gruntwork.mp4`
+- **类别**：DevOps & SRE / 06_CI_CD_GitOps
+- **转录后需补充**：摘要、关键概念、行动项、相关视频链接

wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md

@@ -43,7 +43,7 @@ date: 2023-08-08
 - [[Cloud-Transformation-Programme]]：云转型计划，组织发起的基础设施现代化计划
 
 ## Connections
-- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]] ← same_topic ← [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]
+- [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]] ← related ← [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]（同一 CTP 系列，ECS 部署 + RDS 部署）
 - [[Infrastructure-as-Code]] ← implements ← [[Cloud-Transformation-Programme]]
 - [[ECS-Module]] ← based_on ← [[Gruntwork]]
 

wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md

@@ -1,52 +1,74 @@
 ---
 title: "Learning Sessions ECS Deployment using IAC - 20230808"
 type: source
-tags: [AWS, ECS, IaC, Terraform, CTP]
+tags:
+  - AWS
+  - ECS
+  - IaC
+  - Terraform
+  - CTP
 date: 2023-08-08
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md]]
 
 ## Summary（用中文描述）
-- 核心主题：通过 IaC（Terraform）实现 ECS（Elastic Container Service）容器化应用的自动化部署，由 JP 和 Raja M 主讲
-- 问题域：企业在云端部署容器化应用时面临的不可预测性、敏捷性需求，以及 ECS 与 EKS/Kubernetes 的选型权衡
-- 方法/机制：CTP/SRE 团队基于 Gruntwork 仓库构建的 Terraform ECS 模块，支持 Docker 容器创建、自动扩缩容、自动故障恢复和金丝雀部署；通过 Listener 方式集中管理 ECS；配置文件支持 YAML/JSON；集成 CloudWatch、Splunk、Grafana、Prometheus
-- 结论/价值：ECS 作为 AWS 原生技术，与 AWS 服务深度集成，适合追求简单性和 AWS 紧密集成的场景；Terraform IaC 模块化封装降低了部署复杂度
+- 核心主题：通过基础设施即代码（IaC）使用 Terraform 模块部署 Amazon ECS 容器服务，涵盖 ECS 业务背景、技术架构、CTP/SRE 团队开发的 Terraform 模块详解及最佳实践。
+- 问题域：企业如何在 AWS 云中通过 Terraform IaC 模块标准化、可重复地部署和管理 ECS 容器集群，实现动态扩缩和自动化运维。
+- 方法/机制：
+  - **业务背景**：企业面临不可预测性和敏捷性挑战，动态扩缩能力是关键，ECS 作为 AWS 原生容器编排服务集成 AWS 生态。
+  - **ECS 模块架构**：基于 Gruntwork 模块构建，支持 Docker 容器创建、EC2 实例或 Fargate 部署目标；提供自动扩缩容（Auto Scaling）、自动恢复（Auto Healing）和金丝雀部署（Canary Deployment）能力。
+  - **Listener 模式**：实现集中式 ECS 管理，避免各产品团队直接下载 Gruntwork 模块本地使用。
+  - **前置条件**：VPC、ELB 安全组、EFS 卷挂载；配置通过 YAML/JSON 传递；集成 CloudWatch、Splunk、Grafana、Prometheus。
+- 结论/价值：CTP/SRE ECS Terraform 模块提供企业级容器编排方案，通过 IaC 实现标准化部署，通过 Listener 模式实现集中管控，通过 ELB + Target Group 实现金丝雀部署和灰度发布。
 
 ## Key Claims（用中文描述）
-- JP 指出行业面临不可预测性和敏捷性挑战，企业必须在这些挑战中生存，而这一切由代码驱动（"Businesses have to thrive in the middle of all these challenges and it is forged by code."）
-- 动态扩缩容对于不可预测的负载模式至关重要，技术必须持续演进以应对
-- ECS (Elastic Container Services) 是 AWS 专有技术，与 AWS 服务深度集成，相比 EKS 或原生 Kubernetes 有其独特优势和挑战
-- CTP/SRE 团队在 Gruntwork 仓库基础上构建了 ECS 模块，将 Docker 容器作为逻辑单元创建，支持 EC2 实例或目标部署
-- ECS 模块实现了 Listener 方式集中管理，因为许多产品团队从 Gruntwork 下载代码后本地使用
-- 使用模块的前置条件包括：VPC、ELB 安全组、EFS 卷挂载
+- 企业必须在不可预测性和敏捷性挑战中生存，代码（Code）是应对之道，基础设施即代码使企业能够在挑战中锻造（forged by code）。
+- 动态扩缩容（Dynamic Scaling）是应对不可预测负载模式的关键技术能力，技术必须不断演进。
+- ECS 是 AWS 原生专有技术，相比 EKS 或原生 Kubernetes 具有集成优势，但同时也面临云厂商锁定的挑战。
+- CTP/SRE 团队基于 Gruntwork 模块构建了企业级 ECS Terraform 模块，支持 Docker 容器化部署。
+- Listener 模式实现集中式 ECS 管理，防止各产品团队重复下载和使用 Gruntwork 模块。
+- ECS 模块支持自动扩缩容（Auto Scaling）、自动恢复（Auto Healing）和金丝雀部署（Canary Deployment）。
+- 监控集成支持 AWS CloudWatch、Splunk、Grafana 和 Prometheus。
 
 ## Key Quotes
-> "Businesses have to thrive in the middle of all these challenges and it is forged by code." — JP，阐述企业如何在云转型挑战中通过代码驱动适应
-> "We have implemented the listener approach because we have seen many of the products are downloading the quotes from the gruntwork and using locally." — Raja M，解释为何 CTP 团队实现 Listener 集中管理方式
+> "Businesses have to thrive in the middle of all these challenges and it is forged by code." — ECS IaC 部署的核心驱动力：业务敏捷性
+
+> "We have implemented the listener approach because we have seen many of the products are you know they are downloading the quotes from the grant work and using locally." — Listener 模式实施原因：避免本地重复使用 Gruntwork 模块
+
+> "ECS (Elastic Container Services) is an AWS proprietary technology that integrates with AWS services, offering advantages and challenges compared to EKS or native Kubernetes." — ECS vs EKS 权衡
 
 ## Key Concepts
-- [[Infrastructure-as-Code]]：Terraform IaC 驱动 ECS 部署的核心方法论
-- [[ECS-Module-Deployment]]：CTP/SRE 团队基于 Gruntwork 构建的 ECS 自动化部署模块
-- [[Listener-Approach]]：ECS 集中管理方式，避免各产品团队重复下载使用 Gruntwork 代码
-- [[Canary-Deployment]]：ECS 模块支持的金丝雀部署策略
+- [[ECS]]：AWS 托管容器编排服务，支持 Docker 容器在 EC2 或 Fargate 上的运行和管理。
+- [[Infrastructure-as-Code]]：通过声明式代码管理 ECS 基础设施，实现标准化、可重复的部署。
+- [[Terraform]]：HashiCorp 出品的 IaC 工具，用于定义和部署 ECS 集群模块。
+- [[Gruntwork]]：提供生产级 Terraform 模块的基础设施库，CTP ECS 模块基于 Gruntwork 构建。
+- [[Auto-Scaling]]：ECS 自动扩缩容能力，根据负载动态调整容器实例数量。
+- [[Canary-Deployment]]：金丝雀部署策略，通过 Target Group 权重逐步将流量导向新版本。
+- [[Listener]]：集中式 ECS 管理模式，实现统一入口和流量分发控制。
+- [[ELB]]（Elastic Load Balancing）：弹性负载均衡，与 ECS 集成实现流量分发和高可用。
 
 ## Key Entities
-- [[AWS]]：Amazon Web Services，提供 ECS 容器服务及配套生态（CloudWatch、VPC、ELB、EFS）
-- [[Gruntwork]]：IaC 基础设施代码库，CTP 的 ECS 模块基于 Gruntwork 仓库构建
-- [[CTP]]（Cloud Transformation Programme）：云转型计划，每周定期举办 Learning Sessions 学习会议
-- [[JP]]：演讲者之一，讲解 ECS 的业务和技术背景
-- [[Raja-M]]：演讲者之一，详细介绍 CTP 和 SRE 团队开发的 ECS 模块
+- [[AWS]]：Amazon Web Services，提供 ECS 容器编排服务和相关 AWS 生态集成。
+- [[Gruntwork]]：提供生产级 Terraform 模块的基础设施库，CTP ECS 模块的构建基础。
+- [[JP]]：CTP 技术专家，负责讲解 ECS 的业务和技术背景。
+- [[Raja-M]]：CTP/SRE 技术专家，负责详解 CTP/SRE 团队开发的 ECS Terraform 模块。
+- [[SRE]]（Site Reliability Engineering）：SRE 团队，负责 ECS 模块的设计、开发和维护。
 
 ## Connections
-- [[ctp-topic-70-eks-deployment-using-iac]] ← extends ← [[Infrastructure-as-Code]]（同一 IaC 主题，EKS 与 ECS 两条路径）
-- [[ctp-topic-9-ci-cd-with-gruntwork]] ← builds_on ← [[Gruntwork]]（Gruntwork CI/CD 实践是 ECS 模块的基础）
-- [[ctp-topic-33-an-introduction-to-gitops]] ← related_to ← [[Infrastructure-as-Code]]（GitOps 与 IaC 协同）
+- [[ECS]] ← deployed_by ← [[Terraform]]
+- [[ECS]] ← built_on ← [[Gruntwork]]
+- [[ECS]] ← managed_by ← [[Listener]]
+- [[ECS]] ← scales_with ← [[Auto-Scaling]]
+- [[ECS]] ← deploys_with ← [[Canary-Deployment]]
+- [[ECS]] ← monitored_by ← CloudWatch / Splunk / Grafana / Prometheus
+- [[ECS]] ← load_balanced_by ← [[ELB]]
+- [[Gruntwork]] ← extended_by ← [[Terraform-IaC]]（CTP ECS 模块）
 
 ## Contradictions
-- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异：
-  - 冲突点：ECS 与 EKS 哪个更适合企业容器化部署
-  - 当前观点：ECS 作为 AWS 原生技术与 AWS 服务深度集成，适合追求简单性和紧密集成的场景
-  - 对方观点：EKS 提供更强的可移植性和 Kubernetes 生态系统支持，适合需要多云或混合云策略的场景
-  - 注：两者并非互斥，ECS 和 EKS 可根据具体场景互补使用
+- ECS vs EKS：
+  - 冲突点：选择 ECS 还是 EKS 作为容器编排平台。
+  - 当前观点（本 session）：ECS 是 AWS 专有技术，与 AWS 服务深度集成，具有原生优势，适合 AWS 优先策略。
+  - 对方观点（其他来源）：EKS 提供 Kubernetes 标准生态，跨云可移植性更强，适合多云策略。
+  - 说明：两者各有适用场景，ECS 适合 AWS 深度集成场景，EKS 适合需要 Kubernetes 一致性的多云环境。

wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md

@@ -1,52 +1,64 @@
 ---
-title: "Public Cloud Learning Sessions - Budget Control - 20240319"
+title: "Public Cloud Learning Sessions - Budget Control - 20240319 160204-Meeting Recording"
 type: source
-tags: [FinOps, AWS, Cost-Optimization, Budget-Control, Alerting]
+tags: []
 date: 2024-03-19
-sources: [Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]
-last_updated: 2026-04-26
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS 预算控制自动化系统——面向 SRE Core 团队（Daniela、Evan、Alan）的内部学习分享
-- 问题域：AWS 账户蔓延导致的成本失控，以及现有成本削减措施不可持续的问题
-- 方法/机制：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）的完整告警与执行链路；Source Identity 追踪跨角色切换的原始登录身份
-- 结论/价值：提供账户级别的详细告警（支出预测/实际支出/成本驱动因素），并将 Enforcement 从手动审批逐步演进为自动封禁
+- 核心主题：AWS 账户预算控制自动化解决方案，旨在解决云账户蔓延和成本削减不可持续的问题
+- 问题域：公有云成本管理、FinOps 云财务管理、SRE 运维成本控制
+- 方法/机制：通过 AWS Budget Service + SNS + Lambda + Step Functions 构建多层级告警和执行机制，支持 SCP 服务控制策略进行资源创建阻断，并引入评分系统和宽限期机制避免误罚
+- 结论/价值：SRE Core 团队（Daniela, Evan, Alan）实现了细粒度（资源级、用户级）的成本可视化，支持按账户负责人发送详细告警邮件，并为 FinOps 提供自动化执行手段
 
 ## Key Claims（用中文描述）
-- SRE Core 团队通过 AWS Budget 服务 + 自定义 Lambda/Step Functions 构建的自动化预算控制，解决了 AWS 账户蔓延导致的成本失控问题
-- 告警类型分为 4 种：Forecast（预测超支）、Actual（实际超支 80%/90%/95%/98%）、Severe（100% 且评分制触发）、Enforcement（100% 且启用强制执行则触发 SCP 封禁）
-- Source Identity（AWS Source Identity 属性）通过 CloudTrail 跨角色切换追踪原始登录用户，解决了联邦登录（NetIQ）中"假设角色后无法识别原始身份"的问题
-- 评分系统（Scoring System）根据账户规模和月末时间节点计算宽限期（Grace Period），避免轻微超支的账户被误处罚
-- 初始实施范围仅限 Lab 账户，其他账户继续接收标准超预算告警
+- SRE Core 团队通过预算控制自动化为账户所有者提供详细告警，包含账户支出和成本驱动因素信息，使其能够识别成本削减领域
+- 当账户达到 100% 预算阈值时，系统通过评分系统决定触发严重告警或强制执行（附加 SCP 阻断新资源创建）
+- AWS Budget Service 原生定制能力有限，团队通过解析邮件正文提取数据，再用 Lambda 丰富信息后发送
+- Source Identity 属性实现后，即使通过角色扮演（role assumed）切换身份，CloudTrail 仍能追踪原始登录身份
 
 ## Key Quotes
-> "This is the first time that we were able to get to this level of granularity." — Daniel，描述通过 Athena + Cost Explorer 实现的资源级成本粒度
+> "This is the first time that we were able to get to this level of granularity." — Daniel 描述资源级成本报告的突破性
+
+> "The scoring system and grace period calculations aim to avoid penalizing accounts that slightly exceed their budget near the end of the month." — 评分系统与宽限期设计目的
+
+> "The source identity ensures that the original login identity is maintained across role changes, allowing CloudTrail and other services to track user activity accurately." — Source Identity 在多角色环境下的追踪价值
 
 ## Key Concepts
-- [[AWS-Source-Identity]]：通过 `sts:SourceIdentity` 属性在假设角色后保留原始登录身份，使 CloudTrail 可追踪跨角色用户活动
-- [[FinOps]]：云财务管理，本质是将财务责任与工程实践结合，本 Source 展示 FinOps 执行层（告警→Enforcement）的自动化实现
-- [[AWS-Budget-Alerts]]：AWS Budget 服务原生的预算告警机制，通过 SNS → Lambda → Step Functions 扩展为详细告警邮件
-- [[SCP-Enforcement]]：Service Control Policy，在 100% 预算触发时自动封禁账户新资源创建，实现成本治理的"硬执行"
-- [[CloudTrail]]：AWS 审计日志服务，Source Identity 机制使其能追踪联邦登录跨角色切换的完整用户链
-- [[Step-Functions]]：AWS Step Functions 编排 Lambda 和数据增强逻辑，实现告警流程自动化
-- [[Cost-Explorer]]：AWS 成本分析工具，提供用户维度的日度支出数据，用于 top users 报告
+- [[FinOps]]：云财务管理，通过流程和技术手段优化云成本
+- [[AWS Budget Service]]：AWS 原生预算告警服务，支持设定阈值触发 SNS 通知
+- [[Service Control Policy (SCP)]]：AWS Organizations 服务控制策略，用于限制账户内资源操作
+- [[Source Identity]]：AWS 属性，用于在多角色切换场景下追踪原始操作者身份
+- [[CloudTrail]]：AWS 审计日志服务，记录账户内所有 API 操作
+- [[Step Functions]]：AWS 无服务器工作流编排服务，用于告警数据丰富流程
+- [[Scoring System]]：评分系统，根据账户规模和月末接近程度计算宽限期评分
+- [[Grace Period]]：宽限期，避免在月末最后几天轻微超预算的账户被立即处罚
 
 ## Key Entities
-- [[Daniela]]：SRE Core 团队成员，负责图表和详细成本报告讲解（提及 <2 次，wikilink 记录）
-- [[Evan]]：SRE Core 团队成员（提及 <2 次，wikilink 记录）
-- [[Alan]]：SRE Core 团队成员，负责 AWS Budget Alerts and Actions 实现细节讲解（提及 <2 次，wikilink 记录）
-- [[SRE-Core-Team]]：预算控制自动化系统的开发团队，由 Daniela、Evan、Alan 三人组成
-- [[Phenops-Team]]：FinOps 执行团队，本 Source 中负责预算分配和 Enforcement 审批决策
-- [[NetIQ]]：联邦身份管理系统（NetIQ Access Manager），用于用户认证并提供 Source Identity 的上游身份
+- [[Daniela]]：SRE Core 团队成员，预算控制自动化项目负责人
+- [[Evan]]：SRE Core 团队成员
+- [[Alan]]：SRE Core 团队成员，负责 AWS Budget Alerts and Actions 实现
+- [[Daniel]]：负责图表和详细成本报告的创建与讲解
+- [[Oli]]：提供 Oli workflow 用于预算增加申请流程
+- [[FinOps]]：财务运营团队，负责账户分类、预算更新及强制执行审批
+- [[SRE Core Team]]：SRE 核心团队，开发并维护预算控制自动化系统
 
 ## Connections
-- [[ctp-topic-13-cloud-finops-policies]] ← extends ← [[public-cloud-learning-sessions-budget-control-20240319]]：Topic 13 定义 FinOps 政策框架（成本管理→成本优化→治理自动化三层），本 Source 展示"治理与自动化"层（Budget Enforcement）的具体技术实现
-- [[ctp-topic-63-optimise-resource-cost-using-automation]] ← relates_to ← [[public-cloud-learning-sessions-budget-control-20240319]]：Topic 63 聚焦 RightSizing/承诺计划等主动优化手段，本 Source 聚焦被动告警+强制执行机制，两者互补构成 FinOps 完整闭环
-- [[public-cloud-learning-sessions-reducing-cloud-costs-20250318]] ← extends ← [[public-cloud-learning-sessions-budget-control-20240319]]：2025 版主讲 Vinay（FinOps Lead），补充了 Savings Plans/RI 承诺计划，本 Source 是 2024 早期版本，两者构成 FinOps 知识演进
+- [[AWS Budget Service]] ← triggers ← [[SNS Topic]]
+- [[SNS Topic]] ← invokes ← [[Lambda Function]]
+- [[Lambda Function]] ← enriches data via ← [[Step Functions]]
+- [[Step Functions]] ← enriches with ← Account Information + Budget Details + Owner/Manager Contacts
+- [[100% Threshold Alert]] ← scores via ← [[Scoring System]]
+- [[Scoring System]] ← produces ← [[Severe Alert]] or [[Enforcement Action]]
+- [[Enforcement Action]] ← applies ← [[Service Control Policy (SCP)]]
+- [[FinOps]] ← receives ← Notification for enforcement approval
+- [[Source Identity]] ← tracked by ← [[CloudTrail]]
+- [[Budget Increase Request]] ← routed via ← [[Oli Workflow]]
+- [[Top Services Report]] ← data source ← [[Athena]]
+- [[Top Users Report]] ← data source ← [[Cost Explorer]]
 
 ## Contradictions
-- 与 [[ctp-topic-13-cloud-finops-policies]] 关于 Enforcement 方式：Topic 13 提到"集中式上线/策略开发/自动报告"，本 Source 明确提出 SCP 自动封禁新资源作为 Enforcement 手段；两者不矛盾，Topic 13 描述政策层面，本 Source 描述执行层面
+- 暂无发现与其他 Wiki 页面的冲突内容

wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md

@@ -1,60 +1,53 @@
 ---
 title: "Public Cloud Learning Sessions - Introduction to AI/ML with AWS"
 type: source
-tags: [AI, ML, AWS, Serverless-AI, Generative-AI, Amazon-Bedrock]
+tags: [AI, ML, AWS, Machine-Learning, Generative-AI, Foundation-Models, Amazon-Bedrock, MLOps]
 date: 2024-02-06
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS 上的 AI/ML 与生成式 AI 入门，由 AWS 高级解决方案架构师 Suraav Paul 主讲
-- 问题域：企业如何在 AWS 云上落地 AI/ML 能力，包括传统 AI（分类/预测）和生成式 AI（基础模型）
-- 方法/机制：Amazon Bedrock 全托管生成式 AI 服务、Amazon SageMaker Canvas 无代码 ML 工具、ML Ops 完整生命周期管理（数据流水线→训练流水线→推理流水线）
-- 结论/价值：AWS 通过预置算法/模型/SageMaker Canvas 民主化 AI 访问；Bedrock 支持微调/持续预训练/RAG/Agent/Guardrails 全套定制能力；ML Ops 融合 DevOps 文化、人员和流程，实现协同 ML 解决方案
+- 核心主题：AWS AI/ML 入门与生成式 AI 实践——Suraav Paul（AWS 高级解决方案架构师）主讲，介绍 AI/ML 基本概念、Amazon Bedrock 基础模型服务、ML Ops 全生命周期实践
+- 问题域：企业如何在 AWS 上落地 AI/ML 能力，如何选择合适的工具和服务
+- 方法/机制：AI 三层分类（分类 AI / 预测 AI / 生成式 AI）→ Amazon Bedrock 全托管服务（基础模型 + 微调 + RAG + Agents + Guardrails）→ ML Ops 三管道（数据管道 + 训练管道 + 推理管道）
+- 结论/价值：AWS 通过 Bedrock 民主化 AI 访问，ML Ops 结合 DevOps 实践实现 ML 生命周期自动化，强调数据隐私和负责任 AI
 
 ## Key Claims（用中文描述）
-- AI 指任何能复制此前需要人类智能才能完成任务的系统，通常通过机器学习使用数据创建决策逻辑或模型来寻求概率性结果
-- AWS 认为大多数客户体验和应用程序将被生成式 AI 重塑，由拥有数十亿参数的基础模型驱动
-- Amazon Bedrock 是全托管服务，用于构建和扩展生成式 AI 应用，支持使用自有数据定制基础模型，同时保持安全与隐私
-- ML Ops 结合机器学习与运维，涉及人员、技术和流程的协作，以实现协同 ML 解决方案
+- AI 复制需要人类智能的任务，通过机器学习从数据中创建决策逻辑或模型
+- 生成式 AI 通过基础模型（Foundation Models）创作内容，Amazon 相信大多数客户体验和应用将被生成式 AI 重塑
+- Amazon Bedrock 是全托管服务，通过统一 API 提供多种基础模型访问，支持微调、持续预训练、RAG 和 Agents
+- ML Ops 将机器学习与运维结合，涵盖数据管道、训练管道和推理管道，解决数据溯源、模型管理和部署工作流问题
+- Bedrock 仅在请求-响应周期内存储数据，确保数据隐私；公司训练数据不会被模型提供商使用
 
 ## Key Quotes
 > "We believe most customer experiences and applications will be reinvented with generative AI, powered by foundation models with billions of parameters." — Suraav Paul, AWS Senior Solutions Architect
 
 > "AI is a way to describe any system that can replicate tasks that previously required human intelligence." — Suraav Paul, AWS Senior Solutions Architect
 
-> "ML Ops combines machine learning and operations, involving people, technology, and processes for collaborative ML solutions." — Suraav Paul, AWS Senior Solutions Architect
-
 ## Key Concepts
-- [[RAG]]：Retrieval Augmented Generation，从企业数据源获取相关数据以生成响应，是 Bedrock 数据定制技术之一
-- [[MLOps]]：Machine Learning Operations，将 ML 与运维结合，涉及人员、技术和流程的协作框架
-- [[Foundation-Models]]：基础模型，具有数十亿参数，支持分类、预测和生成式 AI，是生成式 AI 的核心驱动
-- [[Amazon-Bedrock]]：AWS 全托管生成式 AI 服务，提供基础模型访问、数据定制（微调/持续预训练/RAG/Agent）和安全保障
-- [[Amazon-SageMaker-Canvas]]：AWS 无代码机器学习工具，民主化 AI/ML 访问
-- [[Responsible-AI]]：负责任 AI 原则，包括公平性、可解释性、鲁棒性、治理、透明度和隐私/安全
+- [[Generative-AI]]：通过基础模型（Foundation Models）创作新内容的 AI 类型，不同于分类 AI（识别模式）和预测 AI（预测趋势）
+- [[Foundation-Models]]：拥有数十亿参数的基础模型，是生成式 AI 的核心驱动力
+- [[Amazon-Bedrock]]：AWS 全托管生成式 AI 服务，提供对多种 FM 的统一 API 访问，内置 RAG、Agents、Guardrails
+- [[RAG]]：检索增强生成（Retrieval Augmented Generation），从公司数据源获取相关信息以生成准确响应
+- [[MLOps]]：将机器学习与运维结合，通过数据管道、训练管道、推理管道实现 ML 生命周期自动化
+- [[Responsible-AI]]：负责任 AI 原则，包括公平性、可解释性、鲁棒性、治理、透明度和隐私安全
 
 ## Key Entities
-- [[AWS]]：Amazon Web Services，云服务商，提供 AI/ML 全套工具和服务
-- [[Amazon-Bedrock]]：AWS 全托管生成式 AI 服务平台
-- [[Amazon-Titan]]：Bedrock 提供的基础模型系列之一
+- [[Suraav-Paul]]：AWS 高级解决方案架构师，本期主讲人
+- [[Amazon-Bedrock]]：AWS 提供的全托管生成式 AI 服务
+- [[Amazon-SageMaker]]：AWS ML 平台，用于训练、调参与推理部署
+- [[Amazon-Titan]]：Amazon 基础模型系列之一
+- [[AWS]]：Amazon Web Services，云服务商
 
 ## Connections
-- [[ctp-topic-13-cloud-finops-policies]] ← extends ← [[FinOps（云财务管理）]]
-- [[ctp-topic-63-optimise-resource-cost-using-automation]] ← depends_on ← [[FinOps（云财务管理）]]
-- [[ctp-topic-27-aws-instance-scheduler]] ← depends_on ← [[FinOps（云财务管理）]]
-- [[public-cloud-learning-sessions-budget-control-20240319]] ← depends_on ← [[FinOps（云财务管理）]]
-- [[public-cloud-learning-sessions-storage-cost-optimization-20240305]] ← depends_on ← [[FinOps（云财务管理）]]
-- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← extends ← [[OpenTelemetry]]
-- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← extends ← [[Amazon EKS]]
-- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] ← extends ← [[Amazon EKS]]
+- [[Generative-AI]] ← powered_by ← [[Foundation-Models]]
+- [[Amazon-Bedrock]] ← extends ← [[Generative-AI]]
+- [[RAG]] ← used_by ← [[Amazon-Bedrock]]
+- [[Amazon-Bedrock]] ← part_of ← [[AWS-AI-Services]]
+- [[MLOps]] ← uses ← [[Amazon-SageMaker]]
+- [[MLOps]] ← extends ← [[DevOps]]
 
 ## Contradictions
-- 无
-
-## Notes
-- Suraav Paul（AWS 高级解决方案架构师）仅出现 1 次，以 wikilink 形式记录于 Source page，无需独立建页
-- [[RAG]] 在本 Wiki 中已有多个来源引用（LangChain、Milvus、Qdrant、Knowledge Base RAG 等），无需新建概念页
-- MLOps/Responsible AI 出现频次不足独立建页阈值，以 wikilink 形式记录于 Source page
-- 本来源属于 Cloud Transformation Programme 的 Serverless & AI 专题（09_Serverless_AI）
+- （无已知冲突）

wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md

@@ -11,44 +11,50 @@ date: 2024-11-26
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS AI 专家 Stephen Frank 分享 Gen2 AI（生成式 AI）的发展驱动力、企业级应用场景及 AWS 三层产品战略
-- 问题域：企业软件公司如何利用生成式 AI 实现差异化竞争，AI 数据策略选择（RAG / Fine-tuning / Continued Pre-training）
-- 方法/机制：AWS 三层产品架构（基础设施 → Amazon Bedrock → AI 应用）；Amazon Q 企业知识问答；数据与 AI 模型集成的三种方法
-- 结论/价值：数据是差异化关键；RAG 可在无需重训练的情况下连接自有业务数据；实施 AI 需要培育实验文化、灵活选择模型、重视安全治理与合规
+- 核心主题：AWS AI 使用场景与 Gen2 生成式 AI 落地实践，由 AWS AI 专家 Stephen Frank 分享
+- 问题域：企业如何在 AWS 平台上规模化落地生成式 AI，整合业务数据，控制生成结果
+- 方法/机制：AWS 三层产品策略（基础设施 / Amazon Bedrock / AI 应用）；数据整合三大方法（RAG / Fine-tuning / Continued Pre-training）；企业级 AI 落地关键考量
+- 结论/价值：数据是企业差异化关键；AI 落地需兼顾实验文化、模型灵活性、安全合规与负责任 AI
 
 ## Key Claims（用中文描述）
-- 自 2000 年代以来数据量爆发式增长，加上算力提升，驱动了 Gen2 AI 的崛起
-- Amazon 在核心产品和服务中应用 AI/ML 已达 25 年
-- 生成式 AI 应用的差异化关键在于数据——通过 RAG/Fine-tuning/持续预训练与现有业务数据集成
-- AWS 三层产品战略：基础设施层（基础模型训练/推理）→ Amazon Bedrock（旗舰 API 访问）→ 即用型 AI 应用
-- Amazon Bedrock 确保用户数据与提示词不与第三方模型提供商共享，符合 GDPR 合规要求
-- 负责任 AI 的核心原则：公平性（Fairness）、可解释性（Explainability）、透明度（Transparency）
+- AWS 已在核心产品中应用 AI/ML 达 25 年，持续将经验转化为客户新服务
+- 企业软件公司是生成式 AI 早期采用者，将其集成到核心产品面向客户的应用中
+- 生成式 AI 应用通过与现有业务数据整合来控制结果，数据是差异化关键
+- Amazon Bedrock 确保无第三方数据访问，满足 GDPR 合规要求
+- AI 落地需培养实验文化、保持模型选择灵活性，并优先考虑安全、治理与合规
+- 负责任 AI 实践（公平性、可解释性、透明性）至关重要
 
 ## Key Quotes
-> "Data is key to differentiation, as generative AI applications integrate with existing business data to control outcomes." — Stephen Frank, AWS AI Specialist
-> "When implementing your services, we do have to look at this more holistically." — Stephen Frank, AWS AI Specialist
+> "When implementing your services, we do have to look at this more holistically." — Stephen Frank on holistic AI implementation
+> "Data is key to differentiation, as generative AI applications integrate with existing business data to control outcomes." — Stephen Frank on data as competitive advantage
+> "Various methods exist for working with data, including retrieval-augmented generation (RAG), fine-tuning, and continued pre-training." — Stephen Frank on data integration methods
 
 ## Key Concepts
-- [[RAG]]：将生成式 AI 应用与企业现有业务数据集成，无需重训练即可控制输出结果
-- [[Fine-Tuning]]：通过领域数据微调基础模型，提升特定任务表现
-- [[Continued-Pre-Training]]：持续预训练，在基础模型上继续训练以扩展知识
-- [[Responsible-AI]]：公平性、可解释性、透明度的 AI 实施原则
+- [[Foundation-Models]]：基础模型是大语言模型（LLM）的核心，AWS Bedrock 提供多种基础模型 API 访问
+- [[RAG]]：检索增强生成，通过整合企业现有业务数据来控制 AI 生成结果，是数据整合的关键方法之一
+- [[Fine-Tuning]]：微调基础模型以适应特定业务场景，三大数据整合方法之一
+- [[Responsible-AI]]：负责任 AI 包含公平性、可解释性、透明性原则，是 AWS AI 落地的核心考量
 
 ## Key Entities
-- [[AWS]]：亚马逊云科技，提供三层 AI 产品战略
-- [[Amazon-Bedrock]]：AWS 旗舰生成式 AI 服务，提供 API 访问多种基础模型（Anthropic/Titan 等），保证数据不与第三方共享
+- [[Stephen-Frank]]：AWS AI 专家，主讲本期 AI Use Cases 分享，涵盖 AI 演进、Gen2 AI、AWS 三层产品策略
+- [[Amazon-Bedrock]]：AWS 旗舰生成式 AI 产品，通过 API 提供多种基础模型访问，确保无第三方数据访问，满足 GDPR 合规
+- [[Amazon-Q]]：AWS 预构建 AI 系统，支持知识摘要、内容创作和洞察提取，通过自然语言提示连接多种数据源
 - [[Amazon-SageMaker]]：AWS 全托管机器学习平台，面向数据科学家和平台工程师
-- [[Amazon-Q]]：AWS 预构建 AI 系统，支持知识摘要、内容创建和洞察提取，自然语言连接多种数据源
-- [[Stephen-Frank]]：AWS AI 专家，主讲本次会议
 
 ## Connections
-- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] ← extends ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]
-- [[Amazon-Bedrock]] ← is part of ← [[AWS]] AI 三层产品战略
-- [[Amazon-Q]] ← is part of ← [[AWS]] AI 三层产品战略
-- [[RAG]] ← depends_on ← [[Fine-Tuning]]
+- [[Foundation-Models]] ← builds_on ← [[Responsible-AI]]
+- [[Amazon-Bedrock]] ← provides ← [[Foundation-Models]]
+- [[Amazon-Q]] ← uses ← [[Foundation-Models]]
+- [[Amazon-SageMaker]] ← related_to ← [[Amazon-Bedrock]]
+- [[RAG]] ← enables ← [[Amazon-Bedrock]]
+- [[Fine-Tuning]] ← integrates_with ← [[Amazon-Bedrock]]
+- [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md]] ← related_to ← [[Amazon-Bedrock]]
 
 ## Contradictions
-- 无明显内容冲突。本来源与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] 和 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]] 共同构成 Serverless & AI 知识链路，内容互补而非冲突。
+- 与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md]] 存在视角差异：
+  - 冲突点：Stephen Frank 强调数据整合（RAG/Fine-tuning/Continued Pre-training）是生成式 AI 差异化关键；Generative AI & Prompt Engineering 分享更侧重 Prompt Engineering 技巧本身
+  - 当前观点：两者互补——数据整合决定 AI 能说什么，Prompt Engineering 决定 AI 怎么说
+  - 对方观点：Generative AI & Prompt Engineering 分享认为 Prompt Engineering 是最灵活、成本最低的 AI 优化手段

wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md

@@ -1,62 +1,64 @@
 ---
-title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2"
+title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917"
 type: source
 tags:
   - EDA
   - Event-Driven
   - Architecture
   - OpenText
-date: 2024-09-17
-last_updated: 2026-05-05
+date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md]]
 
 ## Summary（用中文描述）
-- 核心主题：事件驱动架构（EDA）进阶实践——最佳实践、团队独立性、常见消息模式
-- 问题域：如何在企业云环境中设计、落地和治理事件驱动架构
-- 方法/机制：Dr. Anil Giri（AWS 解决方案架构师）详解 EDA 三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、团队去中心化所有权
-- 结论/价值：帮助团队掌握 EDA 生产级最佳实践，在保证弹性和可扩展性的同时实现团队独立自治
+- 核心主题：事件驱动架构（EDA）进阶最佳实践与团队协作模式
+- 问题域：如何在云原生环境下构建可扩展、松耦合、高可用的分布式事件驱动系统
+- 方法/机制：事件代理（Event Router / Event Store）、编排与编排、幂等性、事件排序、团队自主权、去中心化所有权
+- 结论/价值：EDA 的核心价值在于解耦应用、实现逻辑分解；事件代理选型（EventBridge vs SNS vs SQS vs Kinesis）需根据功能丰富度和过滤能力权衡；幂等性是处理异步重试的关键；SQS FIFO / Kinesis 保证事件顺序；去中心化团队所有权优于集中式
 
 ## Key Claims（用中文描述）
-- 事件代理分两类：事件路由器（EventBridge/SNS，按规则过滤路由）和事件存储（SQS/Kinesis，由消费者自己过滤）
-- EventBridge 比 SNS 功能更丰富，支持跨 AWS 服务的事件触发和工作流编排
-- 幂等性（Idempotency）是处理 EDA 消息重复的关键机制，AWS Lambda 异步调用会自动重试
-- SQS FIFO 和 Kinesis Data Streams 可保证事件顺序；标准 SQS 和 EventBridge 支持乱序处理
-- 团队独立性应采用去中心化所有权，云卓越中心（Cloud CoE）提供基础设防，团队自主消费事件
-- Fan-out 模式通过 SNS 主题或 EventBridge 规则将事件分发到不同团队
+- 事件驱动架构通过解耦应用，实现业务功能的逻辑分解，支持独立扩展和监控，最小化故障影响范围
+- 事件代理分为两类：事件路由器（SNS / EventBridge，支持过滤和路由）和事件存储（SQS / Kinesis，需消费者自行过滤）
+- EventBridge 比 SNS 功能更丰富，可让源产品的事件触发其他 AWS 服务
+- 编排（Orchestration）发生于同一微服务内部，而编舞（Choreography）则是不同微服务之间的通信模式；AWS Step Functions 是状态机工作流服务
+- 稀疏事件（sparse events）体积小、适合频繁变化数据，但消费者可能需要额外查询详情；完整状态事件包含更多细节，但受 EventBridge 负载大小限制
+- Lambda 异步调用会自动重试，因此幂等性对于处理订单和支付等场景至关重要
+- 无序事件可使用 EventBridge 或标准 SQS；有序事件必须使用 SQS FIFO 或 Kinesis Data Streams
+- 去中心化团队所有权优于集中式所有权，SNS Topic / EventBridge Rules 实现扇出模式
+- EventBridge 最佳实践：每个订阅者使用单一规则、避免为自定义事件使用默认事件总线、使用死信队列处理失败事件
 
 ## Key Quotes
-> "Event is nothing but it's like a change in the state or an update." — Dr. Anil Giri，EDA 定义
-
-> "Everything fails every time means like whatever you have designed and whatever workload you is running it may fail any time." — 容错设计哲学
+> "Event is nothing but it's like a change in the state or an update." — 事件即状态变化
+> "Everything fails every time means like whatever you have designed and whatever workload you are running it may fail any time." — 一切皆可能失败
 
 ## Key Concepts
-- [[Event-Driven-Architecture]]：一种软件架构范式，通过事件的生产、消费和响应实现松耦合通信
-- [[Choreography]]：编排模式的一种，各微服务自主通信，无需中央协调者
-- [[Orchestration]]：编排模式的一种，通过中央协调者（如 AWS Step Functions）控制工作流步骤
-- [[Idempotency]]：幂等性——同一操作执行一次或多次产生相同结果的特性
-- [[Fan-Out-Pattern]]：一对多消息分发模式，通过 SNS 主题或 EventBridge 规则将事件广播给多个消费者
-- [[Competing-Consumer-Pattern]]：竞争消费者模式，同一时间只有一个消费者可处理消息（SQS 实现）
-- [[Dead-Letter-Queue-DLQ]]：死信队列，用于处理失败事件，防止消息丢失
+- [[Event-Driven-Architecture]]：通过事件在生产者和消费者之间传递信息，实现松耦合的架构模式
+- [[EventBroker]]：事件代理，分事件路由器（Event Router）和事件存储（Event Store）两种类型
+- [[Idempotency]]：幂等性，确保同一请求多次执行结果相同，避免异步重试导致副作用
+- [[Choreography]]：编舞模式，不同微服务之间通过事件进行通信和协作
+- [[Orchestration]]：编排模式，在同一微服务内部协调多个步骤的状态转换
+- [[Fan-Out-Pattern]]：扇出模式，通过 SNS Topic 或 EventBridge Rules 将事件分发给多个消费者
+- [[Competing-Consumer-Pattern]]：竞争消费者模式，同一时间只有一个消费者能消费消息，通过 SQS 实现
+- [[Dead-Letter-Queue]]：死信队列，用于处理失败的事件
 
 ## Key Entities
-- [[AWS]]：Amazon Web Services，EventBridge/SQS/SNS/Lambda/Kinesis/AWS Step Functions 的托管方
-- [[Amazon-EventBridge]]：AWS 事件路由器，支持规则过滤、跨服务触发、Schema 注册
-- [[Amazon-SQS]]：AWS 消息队列服务，分标准队列（乱序/高效）和 FIFO 队列（有序/Exactly-Once）
-- [[Amazon-SNS]]：AWS 发布/订阅通知服务，实现 Fan-out 分发
-- [[AWS-Lambda]]：AWS 无服务器函数，EDA 的核心事件消费者，异步调用自动重试
-- [[AWS-Step-Functions]]：AWS 状态机编排服务，实现 Orchestration 模式
-- [[Kinesis-Data-Streams]]：AWS 流数据服务，支持事件持久化和有序处理
-- [[Dr.-Anil-Giri]]：AWS 解决方案架构师，Event Driven Architecture 系列主讲人
-- [[OpenText]]：会议主办方，Public Cloud Learning Sessions 系列活动的组织者
+- [[AWS-EventBridge]]：AWS 事件代理服务，功能比 SNS 更丰富，支持基于规则的路由和第三方集成
+- [[AWS-SNS]]：AWS 简单通知服务，事件路由器，支持主题订阅和扇出
+- [[AWS-SQS]]：AWS 简单队列服务，事件存储，支持标准队列和 FIFO 队列
+- [[AWS-Kinesis]]：AWS 流数据平台，支持有序事件流
+- [[AWS-Step-Functions]]：AWS 状态机工作流服务，用于服务编排
+- [[AWS-Lambda]]：AWS 无服务器计算服务，事件驱动执行的典型载体
+- [[OpenText]]：会议主办方，提供 Public Cloud Learning Sessions 系列培训
+- [[Cloud-Center-of-Excellence]]：云卓越中心，负责基础平台建设
 
 ## Connections
-- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]] ← part_of ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]（Part 1 与 Part 2 为同一系列，Part 2 补充具体演示内容）
-- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related_to ← [[Event-Driven-Architecture]]（Serverless 天然适合事件驱动，Lambda 是 EDA 的核心执行单元）
-- [[Event-Driven-Architecture]] ← depends_on ← [[Amazon-EventBridge]]（EventBridge 是 AWS EDA 的核心事件总线）
-- [[Event-Driven-Architecture]] ← uses ← [[Idempotency]]（幂等性是 EDA 生产级落地的必要保障）
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]] ← part_of ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
+- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← extends ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
+- [[AWS-EventBridge]] ← used_by ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
+- [[AWS-SQS]] ← used_by ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
+- [[AWS-Lambda]] ← integrates_with ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
 
 ## Contradictions
-- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用
+- 无明显冲突；本 Part 2 与 Part 1 为互补关系（Part 1 聚焦基础概念和核心组件，Part 2 聚焦最佳实践和团队协作）

wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md

@@ -4,63 +4,57 @@ type: source
 tags:
   - Generative-AI
   - Prompt-Engineering
-  - OpenText
   - AWS
+  - Amazon-Bedrock
+  - Amazon-Q
+  - RAG
 date: 2024-11-12
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS 生成式 AI 服务与提示工程基础，由 OpenText 技术客户经理 Shikad Holtzman 主讲
-- 问题域：企业如何在 AWS 上构建有业务价值的生成式 AI 应用
-- 方法/机制：Amazon Bedrock 全托管基础模型服务、RAG（检索增强生成）、微调、持续预训练、Amazon Q 助手、提示工程技巧
-- 结论/价值：企业数据是差异化关键，通过 Bedrock 连接自有数据，无需重训练即可构建专属生成式 AI 应用；提示工程通过清晰指令、上下文、示例和链式思维可显著提升 LLM 输出质量
+- 核心主题：AWS 云上的生成式 AI 服务生态与 Prompt Engineering 基础实践
+- 问题域：企业如何在 AWS 上利用自有数据构建差异化的生成式 AI 应用
+- 方法/机制：AWS Generative AI 技术栈分层（基础设施→Amazon Bedrock→应用层），RAG/Fine-tuning/持续预训练三种模型定制技术，Prompt Engineering 四大组件与基础技巧（One-shot/Few-shot/Chain-of-Thought）
+- 结论/价值：数据是企业差异化关键；Bedrock 保证数据不外泄；Amazon Q 提供开箱即用的业务助手与开发者工具
 
 ## Key Claims（用中文描述）
-- Shikad Holtzman（以色列技术客户经理）通过 AWS 生成式 AI 堆栈三层架构（基础设施/服务/应用）介绍了创新机会与行业通用场景
-- 生成式 AI 通过创造新体验、提升员工生产力、提取洞察、激发创造力四大路径为企业创造价值；应用场景涵盖客服聊天机器人、代码生成摘要、文档处理和图像生成
-- 企业数据是生成式 AI 应用从通用走向专属、产生实际业务价值的关键差异化因素
-- RAG（检索增强生成）是成本最低、最快速的定制化方法，连接多数据源无需重训练模型；微调通过标注示例重训练模型；持续预训练用无标签数据适配特定领域
-- Amazon Bedrock 是全托管服务，提供来自 Anthropic、Meta、Amazon（Titan）的多种基础模型（含多模态和图像模型），并内置 RAG 知识库、微调、Agents 和 Responsible AI 能力，且用户数据和提示不会与模型提供商共享
-- Amazon Bedrock Guardrails 允许用户根据自身策略过滤有害内容
-- Amazon Q 分为企业版（连接多数据源进行搜索/摘要/洞察提取，维持现有权限）和开发者版（专注代码生成、单元测试和代码迁移）
-- 提示工程是创建、设计和优化提示词以引导 LLM 响应的过程，需清晰、准确、具体，遵循迭代测试优化；提示包含指令、上下文、用户输入和输出指示器四部分
-- 少样本提示（One-shot/Few-shot）通过提供示例帮助模型理解任务模式；链式思维（Chain of Thoughts）通过逐步推理引导模型解决复杂任务
+- 生成式 AI 通过创造新体验、提升员工生产力、提取洞察、激发创造力四个维度创造商业价值
+- 领域专属生成式应用的三大构建技术中，RAG 成本最低、最易实现，无需重训练即可连接多数据源
+- AWS 生成式 AI 技术栈分三层：基础设施层（含 Trainium/Inferentia 专用芯片）、服务层（Amazon Bedrock）、应用层
+- Amazon Bedrock 完全托管，不共享用户数据与提示词给模型提供商，并提供 Guardrails 过滤有害内容
+- Prompt Engineering 是迭代过程，提示词应包含指令（Instruction）、上下文（Context）、用户输入、输出指示器四个组件
 
 ## Key Quotes
-> "Your data is your differentiator and it is what makes the difference between generic application to a specific application that can actually bring business to your value." — Shikad Holtzman，强调企业数据是生成式 AI 差异化的核心
+> "Your data is your differentiator and it is what makes the difference between generic application to a specific application that can actually bring business to your value." — Shikad Holtzman，阐述数据作为企业生成式 AI 差异化核心的重要性
 
-> "None of your data nor not the prompts, not the data that you are using for customizing the model is being shared with the model providers." — 强调 Amazon Bedrock 的数据隔离承诺
+> "None of your data nor the prompts, not the data that you are using for customizing the model is being shared with the model providers." — Bedrock 数据隐私保障声明
 
 ## Key Concepts
-- [[RAG]]：检索增强生成，通过连接外部数据源，无需重训练即可让基础模型回答特定领域问题，是成本最低的定制化路径
-- [[Prompt-Engineering]]：提示工程，通过设计清晰指令、上下文、示例和输出指示器引导 LLM 生成准确相关响应的技术和迭代过程
-- [[Chain-of-Thought]]：链式思维，一种提示工程技巧，通过让模型展示逐步推理过程来提升复杂任务表现
-- [[One-Shot-Prompting]]：单样本提示，一种提示技巧，通过提供一个示例帮助模型理解任务格式和期望
-- [[Few-Shot-Prompting]]：少样本提示，通过提供多个示例（通常2-5个）让模型从示例中学习模式和规则
-- [[Responsible-AI]]：负责任 AI，Amazon Bedrock 内置的能力，包括内容过滤和道德准则实施
-- [[Guardrails-for-Amazon-Bedrock]]：Bedrock 护栏，允许用户配置自定义策略过滤有害内容的基础安全功能
+- [[GenerativeAI]]：能够生成新内容（文本、图像、代码等）的人工智能技术，通过创造新体验、提升生产力、提取洞察、激发创造力创造商业价值
+- [[RetrievalAugmentedGeneration|RAG]]（检索增强生成）：连接多个数据源无需重训练模型即可构建领域专属应用，成本最低、最易实现的定制技术
+- [[PromptEngineering]]：创建、设计和优化提示词以引导大语言模型响应的技术，确保输出准确性和相关性；包含 One-shot、Few-shot、Chain-of-Thought 等技巧
+- [[AmazonBedrock]]：AWS 完全托管的生成式 AI 服务层，提供 Anthropic、Meta、Amazon 等多种基础模型，支持 RAG、Fine-tuning、Agents 和 Guardrails
+- [[AmazonQ]]：AWS AI 助手，分为面向业务的 Amazon Q（连接多数据源进行搜索/总结/洞察提取）和面向开发者的 Amazon Q（代码生成/单元测试/代码迁移）
 
 ## Key Entities
-- [[Shikad-Holtzman]]：OpenText 技术客户经理（驻以色列），本次学习会议讲师，专注于 AWS 生成式 AI 应用与创新机会分享
-- [[Amazon-Bedrock]]：AWS 全托管基础模型服务，提供多提供商模型（Anthropic/Amazon Titan/Meta），内置 RAG、微调、Agents 和 Responsible AI 能力
-- [[Amazon-SageMaker]]：AWS 托管服务，覆盖基础模型构建、训练和部署全生命周期；SageMaker JumpStart 提供公开可用基础模型和第三方模型访问
-- [[Amazon-Q]]：AWS AI 助手，分企业版（多数据源连接、搜索摘要）和开发者版（代码生成、单元测试、代码迁移）
-- [[AWS-Trainium]]：AWS 专用训练芯片，用于基础模型训练
-- [[AWS-Inferentia]]：AWS 专用推理芯片，用于模型推理部署
-- [[AWS]]：Amazon Web Services，OpenText Cloud 转型计划的云服务提供商
+- [[ShikadHoltzman]]：OpenText 技术客户经理（以色列），本次学习会议主讲人，分享 AWS 生成式 AI 创新机会与 Prompt Engineering 实践
+- [[OpenText]]：企业信息管理公司，主办本次 Public Cloud Learning Sessions
+- [[AmazonSageMaker]]：AWS 全生命周期管理服务，用于构建、训练和部署基础模型；SageMaker JumpStart 提供公开基础模型和第三方模型访问
+- [[Anthropic]]：Amazon Bedrock 提供的模型提供商之一（Claude 系列）
+- [[MetaAI]]：Amazon Bedrock 提供的模型提供商之一（Llama 系列）
 
 ## Connections
-- [[Amazon-Bedrock]] ← extends ← [[Foundation-Models]]
-- [[RAG]] ← part_of ← [[Amazon-Bedrock]]
-- [[Amazon-Q]] ← part_of ← [[AWS-Generative-AI-Stack]]
-- [[Prompt-Engineering]] ← uses ← [[Chain-of-Thought]]
-- [[Prompt-Engineering]] ← uses ← [[Few-Shot-Prompting]]
-- [[Amazon-SageMaker]] ← part_of ← [[AWS-Generative-AI-Stack]]
-- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] ← related ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（同属 AWS AI/ML 入门系列）
-- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（同属 OpenText Serverless & AI 专题）
+- [[RAG从入门到精通系列1：基础RAG]] ← related_to ← [[GenerativeAI]]（RAG 是构建领域专属生成式应用的核心技术）
+- [[llms-rag-ai-agent-三个到底什么区别]] ← related_to ← [[AmazonBedrock]]（Bedrock 是 AWS 上 RAG 和 Agent 的主要承载平台）
+- [[大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏]] ← contains ← [[PromptEngineering]]（该文总结了大模型相关术语，Prompt Engineering 是重要组成部分）
+- [[AmazonQ]] ← builds_on ← [[AmazonBedrock]]（Amazon Q 开发者版构建于 Bedrock 之上）
 
 ## Contradictions
-- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异：EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用
+- 与 [[llms-rag-ai-agent-三个到底什么区别]] 可能的视角差异：
+  - 冲突点：RAG 是否"最容易"的定制方案
+  - 当前观点（RAG 最便宜最易实现，无需重训练）
+  - 对方观点：RAG 系统复杂度（向量数据库、检索策略、chunk 策略）可能带来运维挑战
+  - 注：两者均认可 RAG 的核心价值，差异在于评估维度（成本/易用性 vs. 运维复杂度）

wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md

@@ -1,62 +1,73 @@
 ---
-title: "Public Cloud Learning Sessions - Serverless Computing - 20240903"
+title: "Public Cloud Learning Sessions (OpenText) - Serverless Computing - 20240903"
 type: source
 tags:
   - Serverless
   - AWS
   - Lambda
-  - Step-Functions
-  - API-Gateway
+  - Step Functions
+  - API Gateway
   - OpenText
-date: 2026-04-14
+date: 2024-09-03
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS 无服务器计算（Serverless Computing），聚焦 AWS Lambda、Step Functions 和 API Gateway
-- 问题域：企业如何在云环境中简化应用管理、降低运维负担、加快上市时间
-- 方法/机制：Lambda 事件驱动函数 → Step Functions 工作流编排 → API Gateway API 管理，AWS 与客户共担运维责任（AWS 管基础设施，客户管代码）
-- 结论/价值：Serverless 模式通过"按需付费、自动扩展、内置安全"实现更快的市场响应和更低的 TCO
+
+- 核心主题：AWS 无服务器计算技术详解，聚焦 Lambda、Step Functions 和 API Gateway
+- 问题域：现代企业在云上快速创新、保证安全合规、降低 TCO 时面临的运维负担
+- 方法/机制：AWS 无服务器服务将运维任务转移给云厂商，让开发团队专注业务代码；Lambda 由事件驱动，支持同步/异步/事件源映射三种调用方式
+- 结论/价值：无服务器模式实现更快的上市时间、业务聚焦、按需付费、自动扩展和内置安全
 
 ## Key Claims（用中文描述）
-- AWS Lambda 将运维任务（负载均衡、自动扩展、安全）转移给云厂商，使开发团队专注业务逻辑
-- Lambda 函数支持同步、异步、事件源映射三种触发模式，可精细控制执行行为
-- Lambda 权限模型分为执行角色（决定函数能做什么）和资源策略（决定谁能触发函数）
-- Step Functions 提供 Standard 和 Express 两种工作流类型，分别适用于长时任务和高频场景
-- SAM（Serverless Application Model）基于 CloudFormation 构建，支持本地开发和测试 Lambda 函数
-- Lambda Layers 允许跨函数共享公共代码，提高复用率；ARM64 架构提供更优性价比
+
+- Lambda 函数由事件触发，AWS 负责负载均衡、自动扩展和安全防护
+- Lambda 支持执行角色（定义函数权限）和基于资源的策略（控制谁能触发函数）
+- Step Functions 是基于状态机的无服务器工作流编排服务，分标准和快速两种类型
+- API Gateway 提供边缘优化、地域和私有三种部署选项
+- SAM（Serverless Application Model）基于 CloudFormation，支持本地开发和测试 Lambda 函数
 
 ## Key Quotes
-> "Whenever you see that you have written code and you want that this code is final, you can publish as a new version." — Lambda 版本发布的核心理念
+
+> "Whenever you see that you have written code and you want that this code is final, you can publish as a new version." — Lambda 版本管理机制说明
+
+> "Lambda functions are triggered by events, which are changes in state." — Lambda 核心触发机制
 
 ## Key Concepts
-- [[Serverless-Computing]]：将运维任务（负载均衡、自动扩展、安全补丁）转移给云厂商，使开发团队专注业务代码，无需管理服务器
-- [[Event-Driven-Architecture]]：Lambda 函数由事件触发——状态的任何变化即为事件，是 Serverless 的核心执行模型
-- [[Lambda-Permissions-Model]]：执行角色（Execution Role）决定函数能调用哪些 AWS 资源，资源策略（Resource-Based Policy）决定谁能触发该函数，两者分离实现最小权限原则
-- [[Step-Functions]]：无服务器工作流编排服务，基于状态机协调多个 AWS 服务，支持 Standard（长时）和 Express（高频）两种工作流类型
-- [[API-Gateway]]：托管式 API 创建、发布和安全服务，提供边缘优化（Edge-Optimized）、区域（Regional）和私有（Private）三种部署选项
-- [[SAM-Serverless-Application-Model]]：基于 CloudFormation 的无服务器应用开发工具，支持本地测试和部署 Lambda 函数
+
+- [[Serverless Computing]]：将运维任务转移给云厂商，开发者专注业务代码，无需管理服务器
+- [[AWS Lambda]]：事件驱动的无服务器计算服务，支持同步/异步/事件源映射三种触发方式
+- [[AWS Step Functions]]：基于状态机的无服务器工作流服务，分 Standard 和 Express 两种模式
+- [[Amazon API Gateway]]：托管服务，用于创建、发布和保护 API，提供边缘优化/地域/私有三种部署选项
+- [[AWS SAM]]（Serverless Application Model）：基于 CloudFormation 的无服务器应用本地开发和部署工具
+- [[Lambda Layers]]：在多个 Lambda 函数间共享公共代码的机制
+- [[Lambda Versioning and Aliases]]：Lambda 的版本管理和别名机制，用于管理代码变更
 
 ## Key Entities
-- [[AWS Lambda]]：AWS 无服务器计算核心服务，开发者只需提供业务逻辑，AWS 负责其余所有运维工作
-- [[AWS Step Functions]]：AWS 无服务器工作流编排服务，用于协调多个 Lambda 函数和 AWS 服务的执行顺序
-- [[Amazon API Gateway]]：AWS 托管式 API 管理服务，用于创建、发布和维护安全的企业级 API
-- [[Amazon EventBridge]]：AWS 事件总线服务，用于在应用程序之间路由事件（属于 AWS Serverless 服务组合）
-- [[AWS Fargate]]：AWS 无服务器容器计算服务（与 Lambda 互补，提供容器层的 Serverless 选项）
-- [[Amazon Q]]：AWS AI 助手，可用于调试 Lambda 函数（CloudWatch 集成）
-- [[CloudWatch]]：AWS 监控服务，Lambda 将指标（请求数、错误数、延迟、节流）上报至此
-- [[Serverless-Application-Model-SAM]]：AWS 官方开源工具，基于 CloudFormation 简化无服务器应用的本地开发和部署
+
+- [[AWS Lambda]]：AWS 提供的核心无服务器计算服务
+- [[Amazon Q]]：AWS AI 助手，可用于调试 Lambda 函数
+- [[Amazon CloudWatch]]：Lambda 指标（请求数、错误数、延迟、限流）监控服务
+- [[AWS Fargate]]：AWS 无服务器容器计算服务
+- [[Amazon EventBridge]]：AWS 无服务器事件总线服务
+- [[OpenText]]：本次学习课程的主办方
 
 ## Connections
-- [[AWS-Lambda]] ← is_a ← [[Serverless-Computing]]
-- [[AWS-Step-Functions]] ← orchestrates ← [[AWS-Lambda]]
-- [[Amazon-API-Gateway]] ← exposes ← [[AWS-Lambda]]
-- [[Amazon-EventBridge]] ← triggers ← [[AWS-Lambda]]
-- [[SAM-Serverless-Application-Model]] ← builds_on ← [[CloudFormation]]
-- [[CloudWatch]] ← monitors ← [[AWS-Lambda]]
-- [[Serverless-Computing]] ← extends ← [[Cloud-Transformation-Programme]]
+
+- [[AWS Lambda]] ← 核心服务 ← [[Public Cloud Learning Sessions (OpenText) - Serverless Computing]]
+- [[AWS Step Functions]] ← 工作流编排 ← [[AWS Lambda]]
+- [[Amazon API Gateway]] ← API 暴露层 ← [[AWS Lambda]]
+- [[AWS SAM]] ← 部署工具 ← [[AWS Lambda]]
+- [[Amazon CloudWatch]] ← 监控层 ← [[AWS Lambda]]
+- [[Amazon Q]] ← 调试辅助 ← [[AWS Lambda]]
+- [[AWS Fargate]] ← 同级服务 ← [[AWS Lambda]]
+- [[Amazon EventBridge]] ← 事件驱动源 ← [[AWS Lambda]]
 
 ## Contradictions
-- 无已知冲突
+
+- 与 [[Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1]] 可能存在观点交叉：
+  - 冲突点：Event Driven Architecture 与 Lambda 事件驱动模型的边界定义
+  - 当前观点：Lambda 是 Event Driven Architecture 的具体实现之一
+  - 对方观点：Event Driven Architecture 是一个更宽泛的架构模式，涵盖消息队列、事件总线等多种实现