Sync: add infrastructure as code notes

wiki/sources/ctp-topic-16-cross-account-terraform-modules.md

@@ -0,0 +1,55 @@
+---
+title: "CTP Topic 16 Cross-account Terraform modules"
+type: source
+tags: [Terraform, Cross-Account, Modules, CTP, IaC, DevOps, AWS-Landing-Zone]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules]]
+
+## Summary（用中文描述）
+- 核心主题：**跨账号 Terraform 模块的中心化部署方案**，解决多账号 AWS 环境中一个模块内跨账号创建资源的安全与自动化问题
+- 问题域：原有的 Gruntwork 流水线针对单账号设计，在多账号场景下存在安全风险（一账号被攻破可能波及全局）
+- 方法/机制：基于 **Shared Account（共享账号）** 的中心化部署架构，Jenkins + ECS Deploy Runner + Assume Role 三者联动
+- 结论/价值：实现安全性（账号间无直接信任关系）、自动化（Jenkins 自动识别跨账号模块）、可复用性（模块代码不硬编码特定账号角色）
+
+## Key Claims（用中文描述）
+- **Shared Account 作为中转站**：Jenkins 托管在 Shared Account，当检测到 `cross-account.json` 标记文件时触发 ECS Deploy Runner
+- **Assume Role 双角色机制**：ECS Deploy Runner 通过 Assume Role 访问目标账号的两个角色——`TF state bucket accessor`（读取状态文件）和 `cross-account ECS deploy runner role`（执行资源部署）
+- **Blast Radius 控制**：避免 Workload 账号之间直接互访，权限控制在受严格审计的 Shared Account
+- **Terragrunt HCL 全局配置**：通过根目录 `terragrunt.hcl` 定义远程状态存储和角色切换逻辑，支持本地开发与 Jenkins 自动部署的差异化角色处理
+
+## Key Quotes
+> "Cross-account Terraform Modules 指在一个模块内通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能" — Fibos，核心概念定义
+> "Shared Account 是整个 Landing Zone 的核心管理账号，托管 Jenkins、镜像仓库等公共服务，并作为跨账号部署的信任源" — Fibos，架构定位
+> "ECS Deploy Runner 运行在 ECS 上的 Docker 容器，负责执行 Terraform plan 和 apply 命令，是流水线中的实际执行单元" — Fibos，EDR 定义
+
+## Key Concepts
+- [[Cross-account Terraform Modules]]：在一个 Terraform 模块中通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能
+- [[Shared Account]]：Landing Zone 核心管理账号，托管 Jenkins 及公共服务，作为跨账号部署的信任源
+- [[ECS Deploy Runner]]：运行在 ECS 上的 Docker 容器，负责执行 Terraform plan/apply，是流水线的实际执行单元
+- [[TF State Bucket Accessor]]：专门定义的 IAM 角色，仅允许部署工具访问目标账号 S3 桶中的 Terraform 状态文件
+- [[Cross-account ECS Deploy Runner Role]]：部署在目标账号中的角色，允许 Shared Account 的执行器通过 Assume Role 获取资源创建权限
+- [[cross-account.json]]：约定俗成的标记文件，放置于模块目录中，用于告知 Jenkins 该模块需要调用跨账号部署逻辑
+- [[Root Terragrunt HCL]]：全局 Terragrunt 配置文件，定义远程状态存储和角色切换逻辑
+
+## Key Entities
+- **Fibos**：主讲人，分享了团队基于 Shared Account 的跨账号 Terraform 部署方案
+- **Gruntwork**：参考架构来源，原有 Gruntwork 流水线主要针对单账号设计
+- **Jenkins**：CI/CD 引擎，托管在 Shared Account，负责检测模块类型并触发部署流程
+- **AWS Landing Zone**：多账号架构框架，Shared Account + Workload Account 的分层设计
+
+## Connections
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← foundation ← [[ctp-topic-16-cross-account-terraform-modules]]
+- [[ECS Deploy Runner]] ← depends_on ← [[Shared Account]]
+- [[Cross-account Terraform Modules]] ← uses ← [[ECS Deploy Runner]]
+- [[ECS Deploy Runner]] ← assumes ← [[Cross-account ECS Deploy Runner Role]]
+- [[ECS Deploy Runner]] ← reads_state ← [[TF State Bucket Accessor]]
+- [[Root Terragrunt HCL]] ← configures ← [[Cross-account Terraform Modules]]
+- [[ctp-topic-48-terraform-vs-terragrunt]] ← related ← [[Root Terragrunt HCL]]
+- [[AWS-Landing-Zone]] ← enables ← [[Shared Account]]
+
+## Contradictions
+- 与 [[ctp-topic-9-ci-cd-with-gruntwork]]（单账号 Gruntwork 流水线）：原有 Gruntwork 流水线主要针对单账号设计，不处理跨账号场景；本方案通过 Shared Account 中心化架构扩展支持多账号，同时保留 Gruntwork 模块复用优势。两者为演进关系而非冲突。
+- 与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 替代 Jenkins）：Atlantis 在 merge 前应用变更，每个 Landing Zone 部署单台 EC2 实例；本方案的 ECS Deploy Runner 运行在容器中，更适合跨账号大规模部署。Atlantis 的跨账号访问通过各账户 IAM 角色实现，与本方案 Assume Role 机制类似，但执行载体不同。

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

@@ -0,0 +1,55 @@
+---
+title: "CTP Topic 48 Terraform vs Terragrunt"
+type: source
+tags:
+  - Terraform
+  - Terragrunt
+  - IaC
+  - DevOps
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[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 通过减少硬编码、提升可复用性来优化大规模企业部署；两者可互补使用
+
+## Key Claims（用中文描述）
+- Terraform（HashiCorp 出品）通过状态文件将期望状态与现有环境绑定，企业级使用须将状态文件存储在安全可访问的位置
+- Terragrunt 是 Terraform 的轻量封装，贯彻 DRY 原则，通过管理 provider 和 remote_state 块减少跨环境的重复声明
+- Terraform Enterprise 提供带 workspace 的 CI 平台，Gruntwork 提供预建可定制模块，Atlantis 实现 Git 驱动的自动化部署
+- tfsec 用于静态代码安全分析，Terratest 用于基础设施测试自动化
+
+## 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
+
+## Key Concepts
+- [[Infrastructure As Code]]：通过代码定义和版本控制基础设施资源的实践
+- [[DRY Principle]]：Don't Repeat Yourself — 避免重复配置，通过抽象层复用
+- [[State File Management]]：Terraform 用状态文件绑定期望状态与实际环境
+- [[IaC Testing]]：用 Terratest 等工具对基础设施代码进行自动化测试
+
+## Key Entities
+- [[HashiCorp]]：Terraform 创立公司，提供多云基础设施编排工具
+- [[Gruntwork]]：提供预建可定制的 Terraform 模块和 Terraform 原生 AWS Landing Zone
+- [[Atlantis]]：将 Terraform 与 GitHub 集成的开源 CI/CD 工具
+- [[Terraform]]：云厂商无关的基础设施即代码工具
+- [[Terragrunt]]：Terraform 的 DRY 封装层，管理多环境配置
+
+## 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]]
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的直接冲突

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

@@ -0,0 +1,52 @@
+---
+title: "Learning Sessions ECS Deployment using IAC - 20230808"
+type: source
+tags: [AWS, ECS, IaC, Terraform, CTP]
+date: 2023-08-08
+---
+
+## Source File
+- [[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 模块化封装降低了部署复杂度
+
+## 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 卷挂载
+
+## 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 集中管理方式
+
+## Key Concepts
+- [[Infrastructure-as-Code]]：Terraform IaC 驱动 ECS 部署的核心方法论
+- [[ECS-Module-Deployment]]：CTP/SRE 团队基于 Gruntwork 构建的 ECS 自动化部署模块
+- [[Listener-Approach]]：ECS 集中管理方式，避免各产品团队重复下载使用 Gruntwork 代码
+- [[Canary-Deployment]]：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 模块
+
+## 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 协同）
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异：
+  - 冲突点：ECS 与 EKS 哪个更适合企业容器化部署
+  - 当前观点：ECS 作为 AWS 原生技术与 AWS 服务深度集成，适合追求简单性和紧密集成的场景
+  - 对方观点：EKS 提供更强的可移植性和 Kubernetes 生态系统支持，适合需要多云或混合云策略的场景
+  - 注：两者并非互斥，ECS 和 EKS 可根据具体场景互补使用

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

@@ -0,0 +1,54 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106"
+type: source
+tags:
+  - AI
+  - Use-Cases
+  - OpenText
+  - AWS
+  - Generative-AI
+date: 2024-11-26
+---
+
+## Source File
+- [[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 需要培育实验文化、灵活选择模型、重视安全治理与合规
+
+## 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）
+
+## 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
+
+## Key Concepts
+- [[RAG]]：将生成式 AI 应用与企业现有业务数据集成，无需重训练即可控制输出结果
+- [[Fine-Tuning]]：通过领域数据微调基础模型，提升特定任务表现
+- [[Continued-Pre-Training]]：持续预训练，在基础模型上继续训练以扩展知识
+- [[Responsible-AI]]：公平性、可解释性、透明度的 AI 实施原则
+
+## Key Entities
+- [[AWS]]：亚马逊云科技，提供三层 AI 产品战略
+- [[Amazon-Bedrock]]：AWS 旗舰生成式 AI 服务，提供 API 访问多种基础模型（Anthropic/Titan 等），保证数据不与第三方共享
+- [[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]]
+
+## Contradictions
+- 无明显内容冲突。本来源与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] 和 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]] 共同构成 Serverless & AI 知识链路，内容互补而非冲突。

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

@@ -0,0 +1,51 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1"
+type: source
+tags:
+  - EDA
+  - Event-Driven
+  - AWS
+  - Architecture
+  - OpenText
+date: 2024-09-17
+last_updated: 2026-05-05
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]
+
+## Summary（用中文描述）
+- 核心主题：事件驱动架构（Event-Driven Architecture，EDA）入门与概述
+- 问题域：企业级云架构中的异步通信与松耦合集成设计
+- 方法/机制：主讲人 Dr. Anil Giri（AWS 解决方案架构师）介绍通过 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构；会议录音包含开场介绍与主持人协调过程（演示过程中遭遇 Teams 屏幕共享技术故障）
+- 结论/价值：帮助参与者掌握企业级集成模式（Enterprise Integration Patterns），学习实用的云计算技能，为解决现实世界业务挑战打下基础
+
+## Key Claims（用中文描述）
+- Amazon EventBridge、SQS 和 SNS 是实现事件驱动架构的核心 AWS 服务
+- 事件驱动架构能够帮助企业实现松耦合、可扩展的系统集成
+- 企业级集成模式（Enterprise Integration Patterns）是构建可靠分布式系统的理论基础
+
+## Key Quotes
+> "探索企业级集成模式，掌握实用的云计算技能，通过使用 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构，以解决现实世界中的业务挑战。" — Dr. Anil Giri，AWS 解决方案架构师，开场学习目标介绍
+
+> "Give me a second. I'm trying to log in. Just give me a second." — 会议期间 Teams 屏幕共享故障场景
+
+## Key Concepts
+- [[Event-Driven-Architecture]]：一种软件架构范式，其中组件通过事件的产生、消费和响应进行通信，强调松耦合
+- [[Enterprise-Integration-Patterns]]：企业集成模式，是构建可靠分布式系统时常见问题的可复用解决方案集合
+- [[Amazon-EventBridge]]：AWS 无服务器事件总线服务，用于连接应用程序与来自各种来源的事件
+- [[Amazon-SQS]]：AWS 简单队列服务，提供完全托管的消息队列服务
+- [[Amazon-SNS]]：AWS 简单通知服务，提供发布/订阅式的消息通知服务
+
+## Key Entities
+- [[Dr.-Anil-Giri]]：AWS 解决方案架构师，Event Driven Architecture 系列主讲人
+- [[AWS]]：Amazon Web Services，云服务提供商，EventBridge/SQS/SNS 的托管方
+- [[OpenText]]：会议主办方，Public Cloud Learning Sessions 系列活动的组织者
+- [[Micro-Focus]]：原公司名称，现已被 OpenText 收购，学习会话的参与群体来源
+
+## Connections
+- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] ← part_of ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（Part 1 与 Part 2 为同一系列，Part 2 包含具体演示内容）
+- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related_to ← [[Event-Driven-Architecture]]（Serverless 与 EDA 高度相关，Serverless 计算天然适合事件驱动场景）
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用

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

@@ -0,0 +1,62 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2"
+type: source
+tags:
+  - EDA
+  - Event-Driven
+  - Architecture
+  - OpenText
+date: 2024-09-17
+last_updated: 2026-05-05
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
+
+## Summary（用中文描述）
+- 核心主题：事件驱动架构（EDA）进阶实践——最佳实践、团队独立性、常见消息模式
+- 问题域：如何在企业云环境中设计、落地和治理事件驱动架构
+- 方法/机制：Dr. Anil Giri（AWS 解决方案架构师）详解 EDA 三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、团队去中心化所有权
+- 结论/价值：帮助团队掌握 EDA 生产级最佳实践，在保证弹性和可扩展性的同时实现团队独立自治
+
+## 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 规则将事件分发到不同团队
+
+## 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." — 容错设计哲学
+
+## Key Concepts
+- [[Event-Driven-Architecture]]：一种软件架构范式，通过事件的生产、消费和响应实现松耦合通信
+- [[Choreography]]：编排模式的一种，各微服务自主通信，无需中央协调者
+- [[Orchestration]]：编排模式的一种，通过中央协调者（如 AWS Step Functions）控制工作流步骤
+- [[Idempotency]]：幂等性——同一操作执行一次或多次产生相同结果的特性
+- [[Fan-Out-Pattern]]：一对多消息分发模式，通过 SNS 主题或 EventBridge 规则将事件广播给多个消费者
+- [[Competing-Consumer-Pattern]]：竞争消费者模式，同一时间只有一个消费者可处理消息（SQS 实现）
+- [[Dead-Letter-Queue-DLQ]]：死信队列，用于处理失败事件，防止消息丢失
+
+## 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 系列活动的组织者
+
+## 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 生产级落地的必要保障）
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用

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

@@ -0,0 +1,66 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112"
+type: source
+tags:
+  - Generative-AI
+  - Prompt-Engineering
+  - OpenText
+  - AWS
+date: 2024-11-12
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 生成式 AI 服务与提示工程基础，由 OpenText 技术客户经理 Shikad Holtzman 主讲
+- 问题域：企业如何在 AWS 上构建有业务价值的生成式 AI 应用
+- 方法/机制：Amazon Bedrock 全托管基础模型服务、RAG（检索增强生成）、微调、持续预训练、Amazon Q 助手、提示工程技巧
+- 结论/价值：企业数据是差异化关键，通过 Bedrock 连接自有数据，无需重训练即可构建专属生成式 AI 应用；提示工程通过清晰指令、上下文、示例和链式思维可显著提升 LLM 输出质量
+
+## 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）通过逐步推理引导模型解决复杂任务
+
+## 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 差异化的核心
+
+> "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 的数据隔离承诺
+
+## 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 护栏，允许用户配置自定义策略过滤有害内容的基础安全功能
+
+## 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 转型计划的云服务提供商
+
+## 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 专题）
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异：EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用

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

@@ -0,0 +1,62 @@
+---
+title: "Public Cloud Learning Sessions - Serverless Computing - 20240903"
+type: source
+tags:
+  - Serverless
+  - AWS
+  - Lambda
+  - Step-Functions
+  - API-Gateway
+  - OpenText
+date: 2026-04-14
+---
+
+## Source File
+- [[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
+
+## Key Claims（用中文描述）
+- AWS Lambda 将运维任务（负载均衡、自动扩展、安全）转移给云厂商，使开发团队专注业务逻辑
+- Lambda 函数支持同步、异步、事件源映射三种触发模式，可精细控制执行行为
+- Lambda 权限模型分为执行角色（决定函数能做什么）和资源策略（决定谁能触发函数）
+- Step Functions 提供 Standard 和 Express 两种工作流类型，分别适用于长时任务和高频场景
+- SAM（Serverless Application Model）基于 CloudFormation 构建，支持本地开发和测试 Lambda 函数
+- Lambda Layers 允许跨函数共享公共代码，提高复用率；ARM64 架构提供更优性价比
+
+## 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 版本发布的核心理念
+
+## 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 函数
+
+## 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 简化无服务器应用的本地开发和部署
+
+## 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]]
+
+## Contradictions
+- 无已知冲突