From c961c6a394a0dfe2c6637099ad583f7396f42d68 Mon Sep 17 00:00:00 2001 From: weishen Date: Wed, 29 Apr 2026 15:44:38 +0800 Subject: [PATCH] Auto-sync: update nexus workspace --- wiki/concepts/AWS-Firewall-Manager.md | 73 ++++++++ wiki/concepts/AWS-Instance-Scheduler.md | 69 ++++++++ wiki/concepts/Assume-Role.md | 76 +++++++++ wiki/concepts/Blast-Radius.md | 73 ++++++++ wiki/concepts/CI-CD-Secrets.md | 110 ++++++++++++ wiki/concepts/Canary-Deployment.md | 84 ++++------ wiki/concepts/Choreography.md | 43 +++++ wiki/concepts/CloudHealth.md | 31 ++++ wiki/concepts/CloudWatch-Events.md | 37 +++++ wiki/concepts/Competing-Consumer-Pattern.md | 39 +++++ wiki/concepts/Demand-Management.md | 51 ++++++ wiki/concepts/Dependency-Dashboard.md | 32 ++++ wiki/concepts/DynamoDB-Config-Table.md | 51 ++++++ wiki/concepts/ECS-Deploy-Runner.md | 43 +++++ wiki/concepts/ECS-Module.md | 39 +++++ wiki/concepts/ECS.md | 6 +- wiki/concepts/Event-Driven-Architecture.md | 157 ++++++------------ wiki/concepts/Fan-Out-Pattern.md | 34 ++++ wiki/concepts/FinOps.md | 151 +++++------------ wiki/concepts/Fine-Tuning.md | 40 +++++ wiki/concepts/Foundation-Models.md | 33 ++++ wiki/concepts/GitOps.md | 123 +++++++++----- wiki/concepts/ITIL-Service-Management.md | 49 ++++++ wiki/concepts/Idempotency.md | 29 ++++ wiki/concepts/InfrastructureAsCode.md | 33 ++++ wiki/concepts/JDBCWrapper.md | 92 ++++++++++ wiki/concepts/MLOps.md | 59 +++++++ wiki/concepts/Oli-Workflow.md | 71 ++++++++ wiki/concepts/Orchestration.md | 44 +++++ wiki/concepts/Override-Status.md | 51 ++++++ wiki/concepts/Pre-commit-Hooks.md | 34 ++++ wiki/concepts/Privileged-Access-Management.md | 89 ++++++++++ wiki/concepts/Product-Backlog.md | 51 ++++++ wiki/concepts/Prompt-Engineering.md | 58 +++++++ wiki/concepts/RDS-Maintenance-Window.md | 49 ++++++ wiki/concepts/Rate-Limiting.md | 33 ++++ wiki/concepts/ReservedInstances.md | 39 +++++ wiki/concepts/Responsible-AI.md | 47 ++++++ wiki/concepts/Root-Terragrunt-HCL.md | 68 ++++++++ wiki/concepts/SMACs.md | 50 ++++++ wiki/concepts/SavingsPlans.md | 36 ++++ wiki/concepts/SecretRotation.md | 92 ++++++++++ wiki/concepts/SecretsManagement.md | 63 +++++++ wiki/concepts/Security-Group-Policy.md | 68 ++++++++ wiki/concepts/Shared-Account.md | 55 ++++++ wiki/concepts/TF-State-Bucket-Accessor.md | 70 ++++++++ wiki/concepts/Tagging.md | 55 ++++++ wiki/concepts/TerraformState.md | 30 ++++ wiki/concepts/cross-account-json.md | 59 +++++++ wiki/entities/AWS-EventBridge.md | 48 ++++++ wiki/entities/AWS.md | 50 +++--- wiki/entities/Amazon-Bedrock.md | 5 +- wiki/entities/Amazon-Q.md | 42 +++++ wiki/entities/Amazon-SageMaker.md | 41 +++++ wiki/entities/Amazon-Titan.md | 32 ++++ wiki/entities/Anil-Giri.md | 31 ++++ wiki/entities/Anthropic.md | 42 ++--- wiki/entities/Atlantis.md | 131 ++++----------- wiki/entities/CCLE.md | 41 +++++ wiki/entities/CTP-SRE-Team.md | 30 ++++ .../Cross-account-ECS-Deploy-Runner-Role.md | 47 ++++++ wiki/entities/CyberArk.md | 53 ++++++ wiki/entities/ECS-Deploy-Runner.md | 45 +++++ wiki/entities/FPNA-Team.md | 32 ++++ wiki/entities/Fibos.md | 31 ++++ wiki/entities/Godrails.md | 60 +++++++ wiki/entities/Gruntwork.md | 44 ++--- wiki/entities/Gustavo.md | 26 +++ wiki/entities/HashiCorp.md | 94 ++++------- wiki/entities/JP.md | 24 +++ wiki/entities/Jenkins.md | 67 +++++--- wiki/entities/MUI.md | 32 ++++ wiki/entities/Meta-AI.md | 35 ++++ wiki/entities/Octane.md | 62 ++++--- wiki/entities/PCG.md | 34 ++++ wiki/entities/PCGTeam.md | 43 +++-- wiki/entities/Paul-Hopkins.md | 29 ++++ wiki/entities/Qixi.md | 32 ++++ wiki/entities/Raja-M.md | 33 ++++ wiki/entities/SRE-Team.md | 1 + wiki/entities/Shannon.md | 32 ++++ wiki/entities/Shared-Account.md | 55 ++++++ wiki/entities/Shikad-Holtzman.md | 35 ++++ wiki/entities/Stephen-Frank.md | 44 +++++ wiki/entities/Suraav-Paul.md | 26 +++ wiki/entities/TF-State-Bucket-Accessor.md | 59 +++++++ wiki/entities/Tom-Bice.md | 26 +++ wiki/entities/Uday.md | 24 +++ wiki/entities/Vinay.md | 61 +++---- .../cloud-transformation-programme.md | 46 ++--- wiki/index.md | 90 +++++++--- wiki/log.md | 117 ++++++++++++- wiki/overview.md | 16 +- wiki/sources/cloud-learning-master-index.md | 70 ++++---- ...icies-best-practices-to-optimize-the-co.md | 61 +++---- wiki/sources/ctp-topic-2-git.md | 40 ++--- .../ctp-topic-27-aws-instance-scheduler.md | 76 ++++----- ...ic-3-deploy-and-maintain-infrastructure.md | 82 +++++---- ...tis-cicd-for-infrastructure-deployments.md | 96 +++++------ .../ctp-topic-33-an-introduction-to-gitops.md | 1 + ...opic-37-secrets-certificates-management.md | 15 +- .../ctp-topic-48-terraform-vs-terragrunt.md | 61 +++---- ...container-lifecycle-hardening-standards.md | 82 +++++---- .../ctp-topic-55-aws-firewall-manager.md | 72 ++++---- .../ctp-topic-62-aws-secrets-manager.md | 74 ++++----- .../ctp-topic-9-ci-cd-with-gruntwork.md | 47 +++--- ...ogramme-20230808-183322-meeting-recordi.md | 2 +- ...g-iac-20230808-183322-meeting-recording.md | 84 ++++++---- ...ntrol-20240319-160204-meeting-recording.md | 76 +++++---- ...on-to-artificial-intelligence-ai-machin.md | 65 ++++---- ...i-use-cases-20241126-160106-meeting-rec.md | 58 ++++--- ...vent-driven-architecture-part-2-2024091.md | 78 ++++----- ...enerative-ai-prompt-engineering-2024111.md | 74 ++++----- ...erverless-computing-20240903-160139-mee.md | 87 +++++----- 114 files changed, 4784 insertions(+), 1334 deletions(-) create mode 100644 wiki/concepts/AWS-Firewall-Manager.md create mode 100644 wiki/concepts/AWS-Instance-Scheduler.md create mode 100644 wiki/concepts/Assume-Role.md create mode 100644 wiki/concepts/Blast-Radius.md create mode 100644 wiki/concepts/CI-CD-Secrets.md create mode 100644 wiki/concepts/Choreography.md create mode 100644 wiki/concepts/CloudHealth.md create mode 100644 wiki/concepts/CloudWatch-Events.md create mode 100644 wiki/concepts/Competing-Consumer-Pattern.md create mode 100644 wiki/concepts/Demand-Management.md create mode 100644 wiki/concepts/Dependency-Dashboard.md create mode 100644 wiki/concepts/DynamoDB-Config-Table.md create mode 100644 wiki/concepts/ECS-Deploy-Runner.md create mode 100644 wiki/concepts/ECS-Module.md create mode 100644 wiki/concepts/Fan-Out-Pattern.md create mode 100644 wiki/concepts/Fine-Tuning.md create mode 100644 wiki/concepts/Foundation-Models.md create mode 100644 wiki/concepts/ITIL-Service-Management.md create mode 100644 wiki/concepts/Idempotency.md create mode 100644 wiki/concepts/InfrastructureAsCode.md create mode 100644 wiki/concepts/JDBCWrapper.md create mode 100644 wiki/concepts/MLOps.md create mode 100644 wiki/concepts/Oli-Workflow.md create mode 100644 wiki/concepts/Orchestration.md create mode 100644 wiki/concepts/Override-Status.md create mode 100644 wiki/concepts/Pre-commit-Hooks.md create mode 100644 wiki/concepts/Privileged-Access-Management.md create mode 100644 wiki/concepts/Product-Backlog.md create mode 100644 wiki/concepts/Prompt-Engineering.md create mode 100644 wiki/concepts/RDS-Maintenance-Window.md create mode 100644 wiki/concepts/Rate-Limiting.md create mode 100644 wiki/concepts/ReservedInstances.md create mode 100644 wiki/concepts/Responsible-AI.md create mode 100644 wiki/concepts/Root-Terragrunt-HCL.md create mode 100644 wiki/concepts/SMACs.md create mode 100644 wiki/concepts/SavingsPlans.md create mode 100644 wiki/concepts/SecretRotation.md create mode 100644 wiki/concepts/SecretsManagement.md create mode 100644 wiki/concepts/Security-Group-Policy.md create mode 100644 wiki/concepts/Shared-Account.md create mode 100644 wiki/concepts/TF-State-Bucket-Accessor.md create mode 100644 wiki/concepts/Tagging.md create mode 100644 wiki/concepts/TerraformState.md create mode 100644 wiki/concepts/cross-account-json.md create mode 100644 wiki/entities/AWS-EventBridge.md create mode 100644 wiki/entities/Amazon-Q.md create mode 100644 wiki/entities/Amazon-SageMaker.md create mode 100644 wiki/entities/Amazon-Titan.md create mode 100644 wiki/entities/Anil-Giri.md create mode 100644 wiki/entities/CCLE.md create mode 100644 wiki/entities/CTP-SRE-Team.md create mode 100644 wiki/entities/Cross-account-ECS-Deploy-Runner-Role.md create mode 100644 wiki/entities/CyberArk.md create mode 100644 wiki/entities/ECS-Deploy-Runner.md create mode 100644 wiki/entities/FPNA-Team.md create mode 100644 wiki/entities/Fibos.md create mode 100644 wiki/entities/Godrails.md create mode 100644 wiki/entities/Gustavo.md create mode 100644 wiki/entities/JP.md create mode 100644 wiki/entities/MUI.md create mode 100644 wiki/entities/Meta-AI.md create mode 100644 wiki/entities/PCG.md create mode 100644 wiki/entities/Paul-Hopkins.md create mode 100644 wiki/entities/Qixi.md create mode 100644 wiki/entities/Raja-M.md create mode 100644 wiki/entities/Shannon.md create mode 100644 wiki/entities/Shared-Account.md create mode 100644 wiki/entities/Shikad-Holtzman.md create mode 100644 wiki/entities/Stephen-Frank.md create mode 100644 wiki/entities/Suraav-Paul.md create mode 100644 wiki/entities/TF-State-Bucket-Accessor.md create mode 100644 wiki/entities/Tom-Bice.md create mode 100644 wiki/entities/Uday.md diff --git a/wiki/concepts/AWS-Firewall-Manager.md b/wiki/concepts/AWS-Firewall-Manager.md new file mode 100644 index 00000000..15f624aa --- /dev/null +++ b/wiki/concepts/AWS-Firewall-Manager.md @@ -0,0 +1,73 @@ +--- +title: "AWS Firewall Manager" +type: concept +tags: + - AWS + - Security + - Multi-Account + - Firewall + - Compliance +sources: + - ctp-topic-55-aws-firewall-manager +last_updated: 2026-04-14 +--- + +## Definition + +AWS Firewall Manager 是 AWS 提供的集中化管理服务，用于在组织级别（Organization）跨账户和跨应用程序统一配置防火墙规则和安全策略。它提供了一个合规仪表板视图，支持 WAF、Network Firewall、Shield Advanced 和安全组（Security Group）四种策略类型的统一管理。 + +## Core Capabilities + +### 1. Centralized Policy Management +- 在单一账户（Firewall Manager Admin Account）中定义策略，自动分发到目标账户或 OU +- 支持跨多个 Landing Zone（如 RLABS、R&D、SAS、CAT）的统一纳管 +- Firewall Manager 账户独立于任何单一 Landing Zone + +### 2. Security Group Policy Types +- **Common Security Group Policy**：附加基线安全组，允许产品团队在其上继续添加额外规则 +- **Audit & Enforcement Security Group Policy**：拒绝过度宽松的安全组规则，支持手动修复或自动修复 +- **Cleanup Security Group Policy**：清理未使用的冗余安全组 + +### 3. Automatic Remediation +- 依赖 AWS Config 作为合规评估引擎，检测不合规资源 +- 通过 AWS Lambda 触发修复事件，自动执行策略 +- 新建 EC2 实例自动附加基线安全组，删除策略自动从实例剥离安全组 + +### 4. Cross-Account Rule Distribution +- 通过 Prefix List 定义 CIDR 范围 +- 通过 AWS RAM（Resource Access Manager）跨账户共享 Prefix List，实现规则同步更新 + +## Prerequisites +- 需要在组织（Organization）级别启用 Firewall Manager +- Firewall Manager 管理员必须在目标 OU 内拥有管理员权限 +- 所有目标账户必须启用 AWS Config + +## Use Cases +- 多 Landing Zone 环境下的安全基线统一实施 +- 替代 Checkpoint Firewall 无法覆盖的公网子网流量管控 +- 集中化 WAF 规则管理，支持产品团队在基线规则上叠加自定义规则集 + +## Architecture Pattern +``` +Firewall Manager Admin Account + ├── Security Group Policy Definition + │ ├── Target: Account / OU + │ └── Baseline Security Group + ├── AWS Config (Compliance Engine) + └── AWS Lambda (Remediation Trigger) + ↓ (RAM: Prefix List Sharing) +Target Accounts + └── EC2 Instances (Auto-attached) +``` + +## Related Concepts +- [[AWS Config]]：合规评估引擎 +- [[AWS Lambda]]：自动化修复执行 +- [[Security Group Policy]]：策略类型分类 +- [[AWS-Landing-Zone]]：上层基础设施框架 +- [[Terraform]] + [[Terragrunt]]：IaC 自动化部署 + +## Tooling +- Terraform provider for Firewall Manager +- Terragrunt for Landing Zone multi-account orchestration +- Atlantis CI/CD pipeline for automated policy deployment diff --git a/wiki/concepts/AWS-Instance-Scheduler.md b/wiki/concepts/AWS-Instance-Scheduler.md new file mode 100644 index 00000000..0b32d314 --- /dev/null +++ b/wiki/concepts/AWS-Instance-Scheduler.md @@ -0,0 +1,69 @@ +--- +title: "AWS Instance Scheduler" +type: concept +tags: + - AWS + - Cost-Optimization + - FinOps + - Automation + - EC2 + - RDS +sources: + - ctp-topic-27-aws-instance-scheduler + - ctp-topic-63-optimise-resource-cost-using-automation +last_updated: 2026-05-12 +--- + +## AWS Instance Scheduler + +AWS 官方提供的自动化解决方案，通过定时控制 EC2 和 RDS 实例的启动和停止状态来降低非生产环境（开发和测试）的云成本。 + +## Core Mechanism + +技术架构（四层）： + +1. **CloudFormation**：一键部署完整解决方案栈 +2. **CloudWatch Events**：定时触发器，默认每 15 分钟触发一次 Lambda 函数 +3. **Lambda 函数**：读取调度配置并执行实例启停操作 +4. **DynamoDB Config Table**：存储调度定义（Schedules）和周期定义（Periods） + +## Key Features + +- **基于时间表触发**：按预设时间表（而非空闲率）执行启停操作 +- **多时区支持**：可配置不同办公时间（西雅图时间、英国时间等） +- **标签化关联**：通过实例上的 `Schedule` 和 `Period` 标签关联调度逻辑 +- **RDS 维护窗口兼容**：智能配合 RDS 每 7 天强制维护窗口，维护完成后恢复调度状态 +- **Override Status**：高级配置，强制将实例保持在停止状态 +- **数据保留**：实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）" + +## Deployment Model + +- **独立部署**：通过 AWS 官方 CloudFormation 模板一键部署 +- **Guardrails 集成**（Micro Focus CTP）：CCOE 通过 Guardrails 框架将 Instance Scheduler 自动推送至公司内月消费 10 美元以上的 AWS 账号，用户无需手动配置 + +## Relationship to FinOps + +Instance Scheduler 是 [[FinOps（云财务管理）]] 核心技术手段"自动化调度"的具体实现方案： + +- **CTP Topic 13**：首次提出"实例调度器"作为 FinOps 5 大策略之一 +- **CTP Topic 27**：详解 AWS 原生 Instance Scheduler 的技术架构和运营要点 +- **CTP Topic 63**：作为自动化成本优化的 5 大策略之一再次引用 + +## Cost Impact + +非 7×24 工作负载（如开发/测试环境）每天只运行 10 小时，相比 24 小时运行可节省约 **70%** 的实例成本。 + +## Aliases +- Instance Scheduler +- AWS EC2 Instance Scheduler +- AWS RDS Instance Scheduler + +## Related Pages +- [[CloudWatch-Events]] — 触发机制 +- [[DynamoDB-Config-Table]] — 调度配置存储 +- [[Tagging]] — 实例关联方式 +- [[RDS-Maintenance-Window]] — RDS 兼容性 +- [[Override-Status]] — 高级覆盖配置 +- [[Godrails]] — CTP 中的自动化部署框架 +- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 +- [[ctp-topic-63-optimise-resource-cost-using-automation]] — 技术实施参考 diff --git a/wiki/concepts/Assume-Role.md b/wiki/concepts/Assume-Role.md new file mode 100644 index 00000000..099c46cd --- /dev/null +++ b/wiki/concepts/Assume-Role.md @@ -0,0 +1,76 @@ +--- +title: "Assume Role" +type: concept +tags: [AWS, IAM, Security, Cross-Account, Authentication] +sources: + - ctp-topic-16-cross-account-terraform-modules.md + - ctp-topic-5-aws-identity-and-access-management-iam.md +last_updated: 2026-05-15 +--- + +## Overview + +Assume Role 是 AWS IAM 的一种安全机制，允许一个 AWS 实体（用户、服务或角色）通过调用 `sts:AssumeRole` API 获取另一个 IAM 角色的临时安全凭证，从而在不同的安全上下文中执行操作。这是 AWS 跨账号访问的核心机制。 + +## How It Works + +```python +# 1. 源实体（如 ECS Deploy Runner）调用 STS AssumeRole +response = sts.assume_role( + RoleArn="arn:aws:iam::TARGET_ACCOUNT:role/Cross-account-ECS-Deploy-Runner-Role", + RoleSessionName="ecs-deploy-runner-session" +) + +# 2. 获取临时凭证 +temp_access_key = response['Credentials']['AccessKeyId'] +temp_secret_key = response['Credentials']['SecretAccessKey'] +temp_token = response['Credentials']['SessionToken'] + +# 3. 使用临时凭证访问目标账号资源 +ec2_client = boto3.client('ec2', + aws_access_key_id=temp_access_key, + aws_secret_access_key=temp_secret_key, + aws_session_token=temp_token +) +``` + +## Key Properties + +- **临时凭证**：有效期通常为 1-12 小时，过期后无法使用 +- **最小权限**：仅获取所 Assume 角色的权限 +- **审计可追溯**：所有 Assume 操作都会记录在 CloudTrail 中 +- **无持久凭证泄露**：无需存储长期 Access Key + +## Use Cases + +| 场景 | 说明 | +|------|------| +| 跨账号部署 | Shared Account 的 EDR Assume 目标账号的角色执行 Terraform | +| 跨账号数据访问 | 账户 A 访问账户 B 的 S3 资源 | +| 服务间授权 | Lambda 函数 Assume 特定角色访问其他服务 | +| 联邦访问 | 跨账户的 IAM Role 信任关系 | + +## Relationship with Cross-Account Terraform + +在 [[Cross-account-Terraform-Modules]] 方案中： + +``` +[[Shared-Account]] (EDR) + ↓ sts:AssumeRole +[[TF-State-Bucket-Accessor]] (目标账号) → 读写 Terraform 状态文件 + ↓ +[[Cross-account-ECS-Deploy-Runner-Role]] (目标账号) → 执行资源部署 +``` + +## Relationships + +- [[Shared-Account]] ← uses ← [[Assume-Role]] +- [[ECS-Deploy-Runner]] ← uses ← [[Assume-Role]] +- [[Blast-Radius]] ← enables ← [[Assume-Role]] +- [[Cross-account-Terraform-Modules]] ← mechanism ← [[Assume-Role]] + +## Related Concepts + +- [[IAM-Policy]]：Assume Role 的权限边界由 IAM Policy 定义 +- [[Blast-Radius]]：Assume Role 是控制爆炸半径的关键工具 +- [[Cross-account-Terraform-Modules]]：Assume Role 是跨账号 Terraform 方案的核心技术 diff --git a/wiki/concepts/Blast-Radius.md b/wiki/concepts/Blast-Radius.md new file mode 100644 index 00000000..b490ab6d --- /dev/null +++ b/wiki/concepts/Blast-Radius.md @@ -0,0 +1,73 @@ +--- +title: "Blast Radius" +type: concept +tags: [Security, AWS, IAM, Risk-Management, Architecture] +sources: + - ctp-topic-16-cross-account-terraform-modules.md + - ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md +last_updated: 2026-05-15 +--- + +## Overview + +Blast Radius（爆炸半径）是一个安全概念，描述在云基础设施中某个组件（如一个 AWS 账号）被攻破或出现故障时，其影响范围的大小。**目标是最小化爆炸半径**，确保单个组件的问题不会波及其他系统。 + +## In AWS Multi-Account Architecture + +在 AWS Landing Zone 多账号架构中，Blast Radius 控制是核心设计原则： + +### Without Blast Radius Control（高风险） + +``` +Workload Account A + ↓ 直接互信 +Workload Account B + +风险：Account A 被攻破 → Account B 同时沦陷 +``` + +### With Blast Radius Control（推荐架构） + +``` +Workload Account A + ↓ (受限) +[[Shared-Account]] + ↓ (受限) +Workload Account B + +风险：Account A 被攻破 → 仅影响与 Shared Account 的受限连接 + Shared Account → Account B 的连接受独立角色控制 +``` + +## Key Mechanisms + +| 机制 | 说明 | +|------|------| +| **独立账号隔离** | 每个 Workload 独立账号，无直接互信 | +| **最小权限角色** | [[TF-State-Bucket-Accessor]] 和 [[Cross-account-ECS-Deploy-Runner-Role]] 仅授予最小必要权限 | +| **Assume Role 临时凭证** | 无长期凭证泄露风险 | +| **审计追踪** | CloudTrail 记录所有跨账号操作 | + +## Blast Radius vs. Blast Width + +- **Blast Radius**：组件被攻破时的**潜在影响范围** +- **Blast Width**：跨账号直接信任连接的**数量和密度** + +降低 Blast Radius 的策略： +1. 减少账号间的直接信任关系 +2. 使用 Shared Account 作为唯一信任中介 +3. 实施最小权限原则 +4. 定期轮换 IAM 角色凭证 + +## Relationships + +- [[Shared-Account]] ← enables ← [[Blast-Radius-Control]] +- [[Cross-account-Terraform-Modules]] ← secures_via ← [[Blast-Radius]] +- [[Assume-Role]] ← minimizes ← [[Blast-Radius]] +- [[AWS-Landing-Zone]] ← designed_for ← [[Blast-Radius-Control]] + +## Related Concepts + +- [[IAM-Policy]]：最小权限是控制 Blast Radius 的工具 +- [[Cross-account-Terraform-Modules]]：Blast Radius 控制是该方案的核心安全价值 +- [[Assume-Role]]：临时凭证机制是控制 Blast Radius 的关键技术 diff --git a/wiki/concepts/CI-CD-Secrets.md b/wiki/concepts/CI-CD-Secrets.md new file mode 100644 index 00000000..043fb401 --- /dev/null +++ b/wiki/concepts/CI-CD-Secrets.md @@ -0,0 +1,110 @@ +--- +title: "CI/CD-Secrets" +type: concept +tags: + - CI/CD + - Security + - DevOps + - Cloud +--- + +## Definition + +CI/CD Secrets 是指在持续集成/持续部署（CI/CD）流水线中管理敏感信息（密码、API Key、证书、私钥等）的最佳实践。传统 CI/CD 流程中这些 secrets 通常以明文形式硬编码在配置文件、环境变量或脚本中，造成严重的安全风险。 + +## Security Problems with Plain-Text Secrets + +1. **代码仓库泄露**：Secrets 可能意外提交到 Git 等版本控制系统 +2. **日志暴露**：Secrets 在构建日志中可见 +3. **网络传输**：Secrets 在流水线各阶段间传输时可能被截获 +4. **审计缺失**：无法追踪谁在何时访问了哪些凭据 +5. **轮换困难**：硬编码的 Secrets 难以定期轮换 + +## Best Practices for CI/CD Secrets Management + +### 1. Centralized Secrets Management + +将所有 Secrets 集中存储在专用服务中： +- AWS Secrets Manager +- HashiCorp Vault +- Azure Key Vault +- GCP Secret Manager + +### 2. Dynamic Credentials + +使用动态临时凭证替代静态密钥： +```yaml +# ❌ 危险：静态密钥 +environment: + DB_PASSWORD: "static_password_123" + +# ✅ 推荐：动态获取 +environment: + DB_PASSWORD: + from_secret: aws:database-password +``` + +### 3. Pipeline Integration Pattern + +``` +┌─────────────┐ Request ┌─────────────────┐ +│ CI/CD │ ──────────────→│ Secrets │ +│ Pipeline │ │ Manager │ +└─────────────┘←────────────── └─────────────────┘ + Dynamic Secret +``` + +### 4. GitOps with Secrets + +使用 Sealed Secrets、Vault Agent 或 cloud-native solutions 实现 Git 安全存储： +- **Sealed Secrets**：将 secrets 加密后存储在 Git 中 +- **External Secrets Operator**：Kubernetes 原生 secrets 管理 +- **AWS Secrets Manager + SSM**：AWS 原生解决方案 + +## AWS Implementation Example + +```python +# Lambda function for secrets retrieval in CI/CD +import boto3 +import os + +def get_db_credentials(): + client = boto3.client('secretsmanager') + response = client.get_secret_value( + SecretId='prod/database/credentials' + ) + return json.loads(response['SecretString']) +``` + +## Security Controls + +1. **最小权限**：CI/CD 服务账号仅授予必要的 secrets 读取权限 +2. **网络隔离**：Secrets 服务在私有网络中，不暴露给公网 +3. **审计日志**：记录所有 secrets 访问操作 +4. **自动轮换**：Secrets 定期自动轮换，无需人工干预 +5. **临时凭证**：使用 STS 临时凭证替代长期密钥 + +## Related Concepts + +- [[SecretsManagement]]：敏感信息管理的整体框架 +- [[SecretRotation]]：密钥轮换机制 +- [[GitOps]]：基础设施即代码的 Git 工作流 +- [[Infrastructure-as-Code]]：基础设施即代码 + +## Related Entities + +- [[AWS]]：AWS Secrets Manager 提供方 +- [[HashiCorp]]：HashiCorp Vault 提供方 +- [[ControlTower]]：AWS 多账户治理框架 + +## Sources + +- [[ctp-topic-37-secrets-certificates-management]] — CI/CD secrets cleanup implementation phase +- [[ctp-topic-62-aws-secrets-manager]] — JDBC Wrapper + CI/CD integration details + +## Aliases + +- Pipeline Secrets +- Build Secrets +- Deployment Credentials +- GitOps Secrets diff --git a/wiki/concepts/Canary-Deployment.md b/wiki/concepts/Canary-Deployment.md index 1d0218bd..45015ef7 100644 --- a/wiki/concepts/Canary-Deployment.md +++ b/wiki/concepts/Canary-Deployment.md @@ -1,56 +1,28 @@ ---- -title: "Canary Deployment" -type: concept -tags: [DevOps, Deployment, Kubernetes, ECS, AWS] -sources: [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording] -last_updated: 2026-05-05 ---- - -# Canary Deployment - -## Definition -金丝雀部署（Canary Deployment）是一种软件发布策略，通过将新版本逐步推向一小部分用户来降低风险——在新版本全面推广前，先将少量流量导向新版本，观察其行为和性能，验证无误后再逐步扩大比例。 - -## Core Mechanism -1. **流量分割**：将用户流量按比例分割（如 5%/10%/50%/100%） -2. **逐步提升**：从低比例开始，逐步增加新版本流量 -3. **快速回滚**：发现问题时，立即将流量切回旧版本 - -## Implementation in AWS - -### ECS (Elastic Container Service) -ECS 模块支持金丝雀部署，通过 Target Group 权重调整实现流量控制： -- 创建新旧两个 Task Definition -- 通过 ALB/NLB 的 Target Group 逐步调整权重 -- 结合 CloudWatch 监控自动决策扩缩比例 - -### EKS (Elastic Kubernetes Service) -Kubernetes 原生支持金丝雀部署，通过以下机制： -- `ReplicaSet` 控制新旧版本副本数 -- `Service` 选择器配合金丝雀标签 -- Argo Rollouts 等高级工具提供声明式金丝雀策略 - -### AWS Tools -- **AWS CodeDeploy**：原生支持 ECS 和 Lambda 的金丝雀部署策略 -- **ALB Target Groups**：权重路由实现流量分割 -- **CloudWatch**：金丝雀指标监控 - -## Comparison with Other Deployment Strategies - -| 策略 | 风险 | 成本 | 适用场景 | -|------|------|------|----------| -| **Blue-Green** | 中 | 高（双倍资源） | 快速回滚需求 | -| **Canary** | 低 | 中 | 生产验证 | -| **Rolling** | 中 | 低 | 资源受限环境 | -| **A/B Testing** | 低 | 中 | 功能验证 | - -## Key Metrics to Monitor -- 错误率（5xx） -- 延迟（P50/P95/P99） -- 业务指标（转化率/点击率） -- 资源利用率 - -## Related Concepts -- [[Blue-Green-Deployment]]：双环境切换策略 -- [[ECS-Module-Deployment]]：ECS 场景的模块化部署 -- [[Infrastructure-as-Code]]：部署自动化基础 +--- +title: "Canary Deployment" +type: concept +tags: + - Deployment + - ECS + - IaC +sources: + - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi +last_updated: 2023-08-08 +--- + +## Definition +Canary Deployment（金丝雀部署）是一种渐进式发布策略，通过逐步将流量从旧版本切换到新版本，降低新版本上线风险——先让少量用户（"金丝雀"）使用新版本，观察无异常后再全量发布。 + +## How It Works +1. **小流量引入**：新版本部署后，仅将少量流量（如 5-10%）引导至新版本实例 +2. **监控验证**：通过 CloudWatch/Grafana 等监控指标对比新旧版本表现 +3. **渐进切换**：验证通过后，逐步增加新版本流量比例（如 25% → 50% → 100%） +4. **自动回滚**：若新版本指标异常，自动将流量切回旧版本 + +## ECS Context +ECS 模块内置 Canary Deployment 支持，结合 ALB（Application Load Balancer）的目标组权重规则，实现零停机渐进式发布。 + +## Connections +- [[ECS-Module]] ← includes ← Canary Deployment +- [[Infrastructure-as-Code]]：Canary 部署通过 Terraform IaC 定义 +- [[Auto-Scaling]]：常与自动扩缩容配合使用 diff --git a/wiki/concepts/Choreography.md b/wiki/concepts/Choreography.md new file mode 100644 index 00000000..a3c06028 --- /dev/null +++ b/wiki/concepts/Choreography.md @@ -0,0 +1,43 @@ +--- +title: "Choreography" +type: concept +tags: + - EDA + - Architecture + - Microservices +last_updated: 2026-04-14 +--- + +## Aliases +- Choreography Pattern +- 编舞模式 +- 去中心化事件协调 + +## Definition +编舞模式（Choreography）是一种微服务间通过事件进行自发协调的模式，各服务自主响应事件并发布新事件，无需中央协调器。服务通过事件总线了解全局状态和下一步操作。 + +## Characteristics +- **Decentralized**：无中央协调器，各服务平等 +- **Autonomous**：每个服务自主决定如何响应事件 +- **Loosely Coupled**：服务之间完全解耦，通过事件总线交互 +- **Resilient**：局部故障不影响其他服务 +- **Harder to Track**：整体业务流程不直观，调试复杂 + +## Example +1. 订单服务发布 `OrderCreated` 事件 +2. 库存服务订阅并发布 `InventoryReserved` 事件 +3. 支付服务订阅并发布 `PaymentProcessed` 事件 +4. 通知服务订阅并发送确认通知 + +## Comparison with Orchestration +| 维度 | Choreography（编舞） | Orchestration（编排） | +|------|---------------------|---------------------| +| 控制 | 去中心化 | 集中式 | +| 协调器 | 无 | 有（Step Functions） | +| 复杂度 | 局部低，整体高 | 局部高，整体低 | +| 可观测性 | 较难追踪 | 易于追踪 | +| 适用场景 | 简单、独立的服务 | 复杂、有明确业务流程 | + +## Sources +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] +- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] diff --git a/wiki/concepts/CloudHealth.md b/wiki/concepts/CloudHealth.md new file mode 100644 index 00000000..c32b38f6 --- /dev/null +++ b/wiki/concepts/CloudHealth.md @@ -0,0 +1,31 @@ +--- +title: "Cloud Health" +type: concept +tags: + - AWS + - Cost-Optimization + - Monitoring +aliases: + - Cloud Health + - CloudHealth + - 云计算健康 +last_updated: 2026-05-12 +--- + +## Overview + +Cloud Health 是 AWS 提供的云成本分析和监控工具，帮助组织了解、优化和管理云支出。提供资源清单、成本分解、月度账单洞察和趋势分析。 + +## Key Features + +- **资源清单**：全面了解云资源使用情况 +- **成本分析**：按账户、服务、标签等维度分析成本 +- **账单洞察**：月度账单详细分解和趋势追踪 +- **异常检测**：识别异常支出和浪费 +- **RightSizing 建议**：基于使用数据提供优化建议 + +## Related Pages + +- [[FinOps]] +- [[PCG Team]] +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] diff --git a/wiki/concepts/CloudWatch-Events.md b/wiki/concepts/CloudWatch-Events.md new file mode 100644 index 00000000..43b000ac --- /dev/null +++ b/wiki/concepts/CloudWatch-Events.md @@ -0,0 +1,37 @@ +--- +title: "CloudWatch Events" +type: concept +tags: + - AWS + - Event-Driven + - Serverless + - Scheduling +sources: + - ctp-topic-27-aws-instance-scheduler +last_updated: 2026-05-12 +--- + +## CloudWatch Events + +AWS 事件驱动服务（原名 Amazon EventBridge），用于构建事件驱动的架构，实现 AWS 资源变更与应用程序之间的自动化响应。 + +## Role in AWS Instance Scheduler + +在 AWS Instance Scheduler 架构中，CloudWatch Events 充当**定时触发器**： + +- **默认触发间隔**：每 15 分钟触发一次 +- **触发目标**：Lambda 函数 +- **事件内容**：包含当前时间戳和调度评估所需的上下文信息 +- Lambda 函数读取 DynamoDB 中的调度配置，根据实例标签决定是否执行启停操作 + +## Key Characteristics + +- **完全托管**：无需管理服务器或基础设施 +- **近实时**：支持分钟级定时触发 +- **规则驱动**：通过规则（Rule）定义事件模式和目标 +- **多目标支持**：可触发 Lambda、ECS 任务、SQS 队列等多种目标 +- **跨账户事件**：配合 EventBridge Bus 实现跨账户事件路由 + +## Related Pages +- [[AWS-Instance-Scheduler]] — 主要使用场景 +- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 diff --git a/wiki/concepts/Competing-Consumer-Pattern.md b/wiki/concepts/Competing-Consumer-Pattern.md new file mode 100644 index 00000000..4da507d4 --- /dev/null +++ b/wiki/concepts/Competing-Consumer-Pattern.md @@ -0,0 +1,39 @@ +--- +title: "Competing Consumer Pattern" +type: concept +tags: + - EDA + - Architecture + - Messaging + - Cloud +last_updated: 2026-04-14 +--- + +## Aliases +- Competing Consumers +- 竞争消费者模式 +- 多消费者竞争模式 + +## Definition +竞争消费者模式（Competing Consumer Pattern）指多个消费者共享同一个消息队列，但每条消息只被其中一个消费者处理。确保消息处理的负载均衡和故障容错。 + +## Implementation +- **AWS SQS**：设置多个消费者从同一标准队列拉取消息，SQS 自动将消息分配给可用的消费者 +- 消费者之间的竞争通过 SQS 的隐式负载均衡机制实现 + +## Key Characteristics +- **Mutual Exclusion**：每条消息只被一个消费者处理 +- **Load Balancing**：消息自动分配给空闲的消费者 +- **Fault Tolerance**：某消费者失败，其获取的消息会重新入队供其他消费者处理 +- **Ordering Not Guaranteed**：标准 SQS 不保证消息顺序 + +## Use Cases +- 并行处理大量独立任务（如图片处理、文件转换） +- 将工作负载分发到多个 Lambda 函数或 ECS 任务 +- 实现工作线程池的消息分发 + +## Ordered Alternative +如需保证消息顺序，使用 **SQS FIFO 队列** + **单一消费者**，或在 Kinesis 中使用分片键保证同类型消息有序处理。 + +## Sources +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/Demand-Management.md b/wiki/concepts/Demand-Management.md new file mode 100644 index 00000000..4930aeae --- /dev/null +++ b/wiki/concepts/Demand-Management.md @@ -0,0 +1,51 @@ +--- +title: Demand Management +type: concept +tags: [ITIL, Cloud-Governance, Process] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] +--- + +# Demand Management + +**需求管理（Demand Management）** 是平衡需求与可用容量的必要手段，是 ITIL 服务过渡阶段的关键活动。 + +## Overview + +需求管理在云转型过程中的核心价值： +- 平衡业务单元需求与可用云资源容量 +- 通过标准化流程确保公平的资源分配 +- 支持端到端需求履约流程的透明化 + +## Key Processes + +| 阶段 | 活动 | +|------|------| +| 需求提交 | 业务单元通过 Octane/Qixi 提交需求 | +| 需求评审 | ADM/ITOM 需求规划会议评估 | +| 需求审批 | Oli Workflow 三阶段审批 | +| 需求履约 | SMACs 嵌入式自动化履约 | + +## Goals + +- **80% 自助服务**：业务单元能够自行识别和请求所需服务 +- **自动化履约**：机器完成机器能完成的工作 +- **透明管道**：需求处理流程全程可见 + +## Related Concepts + +- [[ITIL-Service-Management]] — ITIL 框架 +- [[Oli-Workflow]] — 支出审批工作流 +- [[Product-Backlog]] — 产品待办列表 +- [[SMACs]] — 技术栈组合 +- [[FinOps]] — 云财务运营 + +## Related Entities + +- [[Tom-Bice]] — FinOps 团队负责人 +- [[FPNA-Team]] — 预算验证团队 +- [[Octane]] — 需求管理平台 +- [[Qixi]] — 需求提交入口 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/concepts/Dependency-Dashboard.md b/wiki/concepts/Dependency-Dashboard.md new file mode 100644 index 00000000..f4059d13 --- /dev/null +++ b/wiki/concepts/Dependency-Dashboard.md @@ -0,0 +1,32 @@ +--- +title: "Dependency Dashboard" +type: concept +tags: + - Renovatebot + - Dependency-Update + - GitOps +last_updated: 2026-05-11 +--- + +# Dependency Dashboard + +## Definition +Renovate Bot 在 GitHub 仓库中自动创建的一个 GitHub Issue，用于汇总所有依赖状态、待处理的 Pull Request 以及更新选项，提供全局依赖状态视角。 + +## Core Functions +- 汇总所有检测到的依赖项及其当前版本 +- 列出所有待处理/已打开的 Pull Request +- 提供批量合并、更新策略配置等交互选项 +- 作为单一入口，方便团队在一个界面内查看和管理所有依赖更新 + +## Related Concepts +- [[Renovate-Bot]] — 依赖 Dashboard 由 Renovate Bot 自动生成 +- [[Dependency-Management]] — Dashboard 是依赖管理的可视化工具 +- [[Semantic-Versioning]] — Dashboard 中显示的版本号遵循 SemVer 规范 + +## Related Sources +- [[ctp-topic-15-working-with-renovatebot]] + +## Aliases +- Renovate Dashboard +- Dependency Issue diff --git a/wiki/concepts/DynamoDB-Config-Table.md b/wiki/concepts/DynamoDB-Config-Table.md new file mode 100644 index 00000000..bfff8b61 --- /dev/null +++ b/wiki/concepts/DynamoDB-Config-Table.md @@ -0,0 +1,51 @@ +--- +title: "DynamoDB Config Table" +type: concept +tags: + - AWS + - DynamoDB + - Configuration + - Scheduling +sources: + - ctp-topic-27-aws-instance-scheduler +last_updated: 2026-05-12 +--- + +## DynamoDB Config Table + +AWS Instance Scheduler 架构中的核心数据存储组件，用于持久化调度规则和周期定义。 + +## Schema Design + +DynamoDB Config Table 通常包含两张表： + +### Schedules 表 +- **ScheduleName**：调度名称（如 `Seattle-9-5`、`UK-9-5`） +- **Timezone**：时区配置 +- **Description**：调度描述 + +### Periods 表 +- **PeriodName**：周期名称 +- **BeginTime**：开始时间 +- **EndTime**：结束时间 +- **Weekdays**：适用工作日（周一至周五） +- **InstanceType**：应用实例类型（EC2/RDS） + +## Role in AWS Instance Scheduler + +DynamoDB Config Table 是 Instance Scheduler 的**逻辑核心**： + +1. Lambda 函数通过 DynamoDB SDK 读取 Schedules 和 Periods 定义 +2. 根据当前时间和实例标签（`Schedule`、`Period`）匹配适用的调度规则 +3. 返回匹配结果后决定执行启动或停止操作 + +## Key Advantages + +- **无服务器**：无需管理任何基础设施，按需扩展 +- **低延迟**：毫秒级读取性能，满足高频调度查询 +- **高可用**：多可用区自动复制，无单点故障 +- **成本效益**：按请求计费，零管理工作负载 + +## Related Pages +- [[AWS-Instance-Scheduler]] — 主要使用场景 +- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 diff --git a/wiki/concepts/ECS-Deploy-Runner.md b/wiki/concepts/ECS-Deploy-Runner.md new file mode 100644 index 00000000..58cb62c7 --- /dev/null +++ b/wiki/concepts/ECS-Deploy-Runner.md @@ -0,0 +1,43 @@ +--- +title: "ECS Deploy Runner" +type: concept +tags: [Terraform, ECS, Deployment, IaC, Docker, CI/CD] +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +ECS Deploy Runner（EDR）是运行在 AWS ECS 上的 Docker 容器，负责在跨账号 Terraform 部署流水线中执行 `terraform plan` 和 `terraform apply` 命令。它是流水线的实际执行单元。 + +## How It Works + +1. **触发**：Jenkins（托管在 [[Shared-Account]]）检测到模块目录中的 `cross-account.json` 标记文件 +2. **启动**：ECS Deploy Runner 在 Shared Account 的 ECS 集群中启动 +3. **Assume Role**：通过 Assume Role 获取两个目标账号 IAM 角色的临时凭证： + - `[[TF-State-Bucket-Accessor]]`：读取目标账号的 Terraform 状态文件 + - `[[Cross-account-ECS-Deploy-Runner-Role]]`：在目标账号中执行资源部署 +4. **执行**：运行 Terraform CLI 命令完成部署 + +## Key Characteristics + +- **容器化**：运行在 Docker 容器中，环境一致性好 +- **按需启动**：每次部署触发一次容器启动，无长期占用 +- **临时凭证**：通过 Assume Role 获取的短期凭证，最小化密钥暴露时间 +- **与 Terragrunt 配合**：Terragrunt HCL 文件配置角色切换逻辑 + +## Local vs CI/CD Difference + +| 环境 | 角色处理 | +|------|---------| +| 本地开发 | Terragrunt 自动处理角色切换，无需手动 Assume Role | +| Jenkins CI/CD | EDR 通过 Assume Role 获取两个专用角色的临时凭证 | + +## Relationships + +- [[CI/CD Pipeline]]：EDR 是 CI/CD 流水线的执行层 +- [[Cross-account-Terraform-Modules]]：EDR 是跨账号 Terraform 模块方案的核心执行组件 +- [[Shared-Account]]：EDR 运行在 Shared Account 的 ECS 集群中 +- [[Assume-Role]]：EDR 通过 Assume Role 获取跨账号权限 +- [[Docker-Containerization]]：EDR 以 Docker 容器形式运行 diff --git a/wiki/concepts/ECS-Module.md b/wiki/concepts/ECS-Module.md new file mode 100644 index 00000000..e755cc15 --- /dev/null +++ b/wiki/concepts/ECS-Module.md @@ -0,0 +1,39 @@ +--- +title: "ECS Module" +type: concept +tags: + - ECS + - Terraform + - IaC + - Modules +sources: + - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi +last_updated: 2023-08-08 +--- + +## Definition +ECS Module 是 CTP/SRE 团队基于 Gruntwork 仓库构建的 Terraform 模块，用于在 AWS 上自动化部署和管理 ECS（Elastic Container Service）容器化应用。 + +## Core Features +- **Docker 容器化**：将应用封装为 Docker 容器作为逻辑部署单元 +- **多部署模式**：支持 EC2 实例部署 +- **自动扩缩容（Auto-Scaling）**：根据负载动态调整容器实例数量 +- **自动故障恢复（Auto-Healing）**：自动重启失败的容器任务 +- **金丝雀部署（Canary Deployment）**：支持渐进式流量切换 +- **集中管理**：通过 Listener 方式统一管理各产品团队的 ECS 部署 + +## Architecture +- 基于 Gruntwork terraform-aws-ecs 模块 +- 使用 VPC、ELB 安全组、EFS 卷作为前置条件 +- 支持 YAML/JSON 配置传递 +- 集成 CloudWatch、Splunk、Grafana、Prometheus 监控 + +## Listener Approach（集中管理） +避免各产品团队直接下载 Gruntwork 模板并本地使用导致的碎片化问题，改为统一通过 Listener 机制集中管理和更新 ECS 配置。 + +## Connections +- [[Gruntwork]] ← based_on ← ECS Module（技术基础来源） +- [[ECS]] ← manages ← ECS Module（AWS ECS 服务层面） +- [[Canary-Deployment]] ← included_in ← ECS Module +- [[Cloud-Transformation-Programme]] ← implements ← ECS Module（CTP 核心产出） +- [[Terraform]] ← tool ← ECS Module（模块实现工具） diff --git a/wiki/concepts/ECS.md b/wiki/concepts/ECS.md index 45cbd47b..9f3bd72f 100644 --- a/wiki/concepts/ECS.md +++ b/wiki/concepts/ECS.md @@ -9,8 +9,10 @@ tags: aliases: - ECS - Elastic Container Service - - Amazon ECS -last_updated: 2026-05-12 +sources: + - learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording + - ctp-topic-48-terraform-vs-terragrunt.md +last_updated: 2026-05-13 --- ## Overview diff --git a/wiki/concepts/Event-Driven-Architecture.md b/wiki/concepts/Event-Driven-Architecture.md index a4192edc..9015e1df 100644 --- a/wiki/concepts/Event-Driven-Architecture.md +++ b/wiki/concepts/Event-Driven-Architecture.md @@ -1,108 +1,49 @@ ---- -title: "Event-Driven Architecture" -type: concept -tags: - - Architecture - - Event-Driven - - Serverless - - AWS -sources: - - public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee - - public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091 - - public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091 -last_updated: 2026-05-05 ---- - -## Definition - -Event-Driven Architecture（事件驱动架构）是一种软件设计范式，在该模式下，系统组件通过产生和消费事件（Event）进行异步通信，而非通过直接的函数调用或请求-响应模式。事件是系统中发生的重要动作或状态变化的声明式通知，事件消费者无需知道事件产生者的存在。 - -## Core Principles - -| 原则 | 描述 | -|------|------| -| 异步通信 | 生产者和消费者解耦，无需同步等待响应 | -| 事件声明 | 事件代表"发生了什么"，而非"该做什么" | -| 松耦合 | 生产者和消费者之间无直接依赖 | -| 可扩展 | 新增消费者无需修改生产者代码 | - -## Event Anatomy - -典型事件包含： - -```json -{ - "event_id": "uuid", - "event_type": "ORDER_CREATED", - "source": "order-service", - "timestamp": "2026-04-14T10:00:00Z", - "data": { /* 业务相关数据 */ } -} -``` - -## AWS Event-Driven Stack - -| 组件 | 角色 | 说明 | -|------|------|------| -| [[Amazon-EventBridge]] | 事件总线 | 接收、过滤、路由事件到目标 | -| [[AWS-Lambda]] | 事件消费者 | 响应事件执行处理逻辑 | -| [[Amazon-SNS]] | 事件发布/订阅 | 一对多广播消息 | -| [[Amazon-SQS]] | 事件队列 | 可靠的事件持久化和顺序处理 | -| [[Amazon-DynamoDB]] | 事件源 | DynamoDB Streams 触发 Lambda | -| [[Amazon-S3]] | 事件源 | S3 事件通知触发 Lambda | - -## Serverless 中的事件驱动 - -[[AWS-Lambda]] 是事件驱动架构的核心执行单元： - -- **事件即触发器**：Lambda 函数不主动运行，由事件触发 -- **事件源映射**：Lambda 轮询 Kinesis、DynamoDB Stream、SQS 获取事件 -- **状态变化即事件**：S3 对象上传、API Gateway 请求、DynamoDB 写入等均为事件 - -## Event Patterns -## EDA 三组件与事件代理类型 - -| 组件 | 角色 | 说明 | -|------|------|------| -| 事件生产者（Producer） | 产生事件 | 服务检测到状态变化时发布事件 | -| 事件消费者（Consumer） | 消费事件 | 订阅并处理事件，执行对应业务逻辑 | -| 事件代理（Broker） | 路由/存储 | 分事件路由器和事件存储两类 | - -**事件路由器（Event Routers）**——按规则过滤事件并路由到正确消费者： -- [[Amazon-EventBridge]]：更丰富，支持 Schema 注册、跨服务触发 -- [[Amazon-SNS]]：一对多广播（Fan-out） - -**事件存储（Event Stores）**——流式持久化事件，消费者自行过滤： -- [[Amazon-SQS]]：标准队列（乱序/高性能）/ FIFO 队列（有序/Exactly-Once） -- [[Kinesis-Data-Streams]]：有序事件流，支持重放 - -## 编排模式：Choreography vs Orchestration - -| 模式 | 特点 | 适用场景 | -|------|------|---------| -| Choreography（编排） | 各微服务自主通信，无中央协调者 | 简单、独立的跨服务交互 | -| Orchestration（编排） | 中央协调者（如 [[AWS-Step-Functions]]）控制工作流步骤 | 复杂业务流程、需要事务保障 | - -## 生产级最佳实践 - -1. **幂等性（Idempotency）**：同一操作执行一次或多次产生相同结果。[[AWS-Lambda]] 异步调用会自动重试，因此幂等性是处理重复消息的关键——尤其适用于订单、支付等场景。 - -2. **事件排序**： - - **有序**：SQS FIFO 或 Kinesis Data Streams - - **乱序可接受**：标准 SQS 或 EventBridge（消费者自行处理乱序） - -3. **团队独立性**：采用去中心化所有权，平台团队提供基础设防（Cloud CoE），消费者团队自主按需消费事件。 - -## Event Patterns -1. **Pub/Sub**：SNS 主题广播，多消费者订阅同一事件类型 -2. **Event Streaming**：Kinesis/DynamoDB Stream 持久化事件流，支持重放 -3. **Fan-Out**：SNS 主题或 EventBridge 规则将事件分发到多个消费者 -4. **Competing Consumer**：同一消息同一时间只有一个消费者处理（SQS） -5. **Dead-Letter Queue（DLQ）**：处理失败事件，防止消息丢失 -6. **Saga Pattern**：通过事件序列协调分布式事务 -7. **Event Sourcing**：完整记录所有状态变化事件作为唯一真相来源 - -## Connections -- [[Event-Driven-Architecture]] ← is_execution_model_of ← [[Serverless-Computing]] -- [[Event-Driven-Architecture]] ← uses ← [[Amazon-EventBridge]] -- [[Event-Driven-Architecture]] ← executed_by ← [[AWS-Lambda]] +--- +title: "Event-Driven Architecture" +type: concept +tags: + - EDA + - Architecture + - Cloud + - Microservices +last_updated: 2026-04-14 +--- + +## Aliases +- EDA +- Event Driven Architecture +- 事件驱动架构 + +## Definition +事件驱动架构（EDA）是一种软件架构范式，通过在松耦合的生产者（Producer）和消费者（Consumer）之间传递事件（Event）来实现系统解耦。事件是状态变化或更新的通知，触发异步处理和响应。 + +## Core Components +- **Event Producer**：事件的产生者，感知状态变化并发布事件 +- **Event Consumer**：事件的订阅者和处理者，响应事件执行相应逻辑 +- **Event Broker**：事件的中介路由器，负责分发和传递事件 + +## Event Broker Types +- **Event Router**（事件路由器）：过滤并路由事件到正确的消费者（SNS / EventBridge） +- **Event Store**（事件存储）：流式存储事件，消费者自行过滤所需事件（SQS / Kinesis） + +## Key Design Principles +- **Decoupling**：生产者和消费者完全解耦，独立演进 +- **Scalability**：各组件可独立扩展 +- **Resilience**：局部故障不影响整体系统 +- **Idempotency**：幂等性保证异步重试不产生副作用 + +## Best Practices +- 稀疏事件（sparse events）适合频繁变化的数据，但消费者可能需要额外查询详情 +- 完整状态事件（full state）包含更多细节，但受 EventBridge 负载大小限制 +- 事件排序需使用 SQS FIFO 或 Kinesis Data Streams +- EventBridge 最佳实践：每个订阅者使用单一规则、避免为自定义事件使用默认事件总线、使用死信队列处理失败事件 + +## Related Messaging Patterns +- [[Fan-Out-Pattern]]：扇出模式 +- [[Competing-Consumer-Pattern]]：竞争消费者模式 +- [[Choreography]]：编舞模式 +- [[Orchestration]]：编排模式 + +## Sources +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]] +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/Fan-Out-Pattern.md b/wiki/concepts/Fan-Out-Pattern.md new file mode 100644 index 00000000..e37948d7 --- /dev/null +++ b/wiki/concepts/Fan-Out-Pattern.md @@ -0,0 +1,34 @@ +--- +title: "Fan-Out Pattern" +type: concept +tags: + - EDA + - Architecture + - Messaging + - Cloud +last_updated: 2026-04-14 +--- + +## Aliases +- Fan-out +- 扇出模式 + +## Definition +扇出模式（Fan-Out Pattern）指将一个事件同时分发给多个消费者（订阅者）的模式。在事件驱动架构中，生产者发布一条消息，通过事件代理自动分发给所有感兴趣的消费者。 + +## Implementation +- **SNS Topic**：发布到 SNS Topic，多个 SQS 队列或 Lambda 函数订阅同一主题 +- **EventBridge Rules**：基于规则路由，将事件分发给不同的目标服务 + +## Use Cases +- 同一订单事件触发库存服务、支付服务、通知服务 +- 日志事件同时发送到 CloudWatch Logs、S3 和第三方监控系统 +- 数据同步：同一数据变更同步到多个下游系统 + +## Best Practices +- SNS Topic 订阅多个 SQS 队列实现可靠的消息传递 +- EventBridge 每个订阅者使用单一规则，便于维护和调试 +- 消费者独立扩展，不影响其他消费者 + +## Sources +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/FinOps.md b/wiki/concepts/FinOps.md index 28f84650..cfddcad6 100644 --- a/wiki/concepts/FinOps.md +++ b/wiki/concepts/FinOps.md @@ -1,111 +1,40 @@ ---- -title: "FinOps" -type: concept -sources: [cloud-operating-model-key-strategies-and-best-practices] ---- - -# FinOps - -> **FinOps** — Cloud Financial Management，云财务管理，是一种将财务责任、跨团队协作和业务价值最大化相结合的云成本管理实践。 - -## Definition - -FinOps（Financial Operations）是云时代的一种运营框架： - -- **可见性** — 了解云支出去向 -- **优化** — 持续减少浪费 -- **业务价值** — 最大化云投资回报 - -## FinOps Core Principles - -| 原则 | 描述 | -|------|------| -| **云是一个 marketplaces** | 实时价格，竞争驱动 | -| **财务责任人人有责** | 集中团队无法独自优化 | -| **按需 vs 承诺** | 两者混合以平衡灵活性和成本 | -| **持续优化** | 定期评估和调整 | -| **业务价值驱动** | 成本透明支撑业务决策 | - -## FinOps Maturity Model - -| Level | 描述 | 特征 | -|-------|------|------| -| **Crawl** | 可见性 | 建立标签、成本分配、基础监控 | -| **Walk** | 优化 | .right-sizing、预留购买、自动化 | -| **Run** | 自动化 | 实时优化、自动策略执行 | - -## Key Practices - -### 1. Chargeback / Showback - -| 模型 | 描述 | 适用场景 | -|------|------|---------| -| **Showback** | 向部门展示成本 | 培养成本意识 | -| **Chargeback** | 部门承担实际成本 | 强化责任 | - -### 2. Resource Tagging - -**必需标签** -| 标签 | 示例 | 用途 | -|------|------|------| -| `Environment` | prod, staging | 环境隔离 | -| `Owner` | alice@example.com | 责任追踪 | -| `CostCenter` | CC-12345 | 财务归因 | -| `Application` | billing-api | 应用关联 | - -### 3. Cost Optimization - -**技术** -- .Right-sizing（资源优化） -- Reserved Instances / Savings Plans -- Spot/Preemptible 实例 -- 生命周期策略（存储） -- 闲置资源清理 - -**流程** -- 定期成本审视（Weekly/Monthly） -- 预算告警 -- 成本异常检测 -- 优化建议 Review - -### 4. Unit Economics - -| 指标 | 公式 | 目标 | -|------|------|------| -| **Cost per Transaction** | 总成本 / 交易数 | 持续降低 | -| **Cost per User** | 总成本 / 用户数 | 持续降低 | -| **Cost per Revenue** | 总成本 / 收入 | 稳定或降低 | - -## Tools - -| 类别 | 工具 | -|------|------| -| **原生** | AWS Cost Explorer, Azure Cost Management, GCP Billing | -| **第三方** | Spot.io, CloudHealth, Densify, Kubecost | -| **BI/可视化** | Tableau, Looker, Power BI | - -## FinOps Team Roles - -| 角色 | 职责 | -|------|------| -| **FinOps Practitioner** | 日常成本监控和分析 | -| **FinOps Lead** | 策略制定、跨团队协调 | -| **Cloud Economist** | 云经济学、成本建模 | -| **Business Partner** | 业务部门对接 | - -## Integration with Other Practices - -| 实践 | 关系 | -|------|------| -| **DevOps** | FinOps-aware 开发 | -| **SRE** | 可靠性与成本平衡（SLO vs 成本） | -| **Cloud Governance** | 成本策略是治理一部分 | -| **Cloud Security** | 安全成本量化 | - -## See Also - -- [[Cloud Cost Optimization]] — 云成本优化 -- [[Cloud Governance]] — 云治理 -- [[Cloud Adoption Strategy]] — 云采用策略 -- [[Multi-Cloud Strategy]] — 多云策略 -- [[DORA Metrics]] — DORA 指标 +--- +title: "FinOps (Cloud Financial Management)" +type: concept +tags: + - AWS + - FinOps + - Cost-Optimization +aliases: + - FinOps + - 云财务管理 +last_updated: 2026-05-12 +--- + +## Overview + +FinOps（云财务管理）是一种云资源管理学科，通过可见性、优化和治理实现云投资最大化价值。核心目标是在云环境中建立成本意识文化，实现工程速度与财务问责制的平衡。 + +## Core Principles + +- **可见性**：确保所有云支出的可见性，按责任单元拆分 +- **优化**：持续优化资源使用，降低单位成本 +- **治理**：建立策略和控制，确保支出在预算内 + +## Key Practices + +- **Showback/Chargeback**：成本分摊机制，Showback 展示成本数据，Chargeback 强制成本归属 +- **Reserved Instances / Savings Plans**：承诺计划用于长期工作负载成本优化 +- **RightSizing**：根据实际使用情况调整实例规格 +- **Spot Instances**：可中断工作负载使用竞价实例降低 60-90% 成本 +- **Graviton ARM 实例**：相比 Intel x86 实例成本更低、能耗更低 + +## Related Pages + +- [[PCG Team]] +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] +- [[ctp-topic-63-optimise-resource-cost-using-automation]] +- [[SpotInstances]] +- [[ReservedInstances]] +- [[SavingsPlans]] +- [[Graviton]] diff --git a/wiki/concepts/Fine-Tuning.md b/wiki/concepts/Fine-Tuning.md new file mode 100644 index 00000000..49184bd6 --- /dev/null +++ b/wiki/concepts/Fine-Tuning.md @@ -0,0 +1,40 @@ +--- +title: "Fine-Tuning" +type: concept +tags: [AI, ML, fine-tuning, foundation-model, customization] +sources: [public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec] +last_updated: 2026-05-12 +--- + +## Aliases +- Fine-tuning +- Model Fine-tuning +- 模型的微调 + +## Definition +Fine-Tuning（微调）是在预训练基础模型之上，使用特定领域或任务的数据进一步训练模型，使其适应特定业务场景。与 RAG 不同，微调直接修改模型权重，而非在推理时注入外部知识。 + +## Key Facts +- 属于三大数据整合方法之一（RAG / Fine-tuning / Continued Pre-training） +- 与 RAG 的核心区别：RAG 保留原始模型权重，通过检索增强回答；Fine-tuning 修改模型权重，改变模型本身 +- 适用场景：特定领域术语、风格、任务类型的深度适配 +- 成本：需要额外的训练资源和时间 +- AWS Amazon Bedrock 支持 Fine-tuning 基础模型 + +## Comparison with RAG + +| 维度 | Fine-Tuning | RAG | +|------|-------------|-----| +| 修改模型权重 | 是 | 否 | +| 推理延迟 | 无额外延迟 | 有检索开销 | +| 外部知识库 | 不依赖 | 依赖 | +| 适用场景 | 风格/任务适配 | 知识密集型问答 | +| 成本 | 训练成本高 | 索引/检索成本 | + +## Related Concepts +- [[Foundation-Models]]：微调作用于基础模型 +- [[RAG]]：另一种数据整合方法，与微调互补 +- [[Amazon-Bedrock]]：提供 Fine-tuning 能力 + +## Sources +- [[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]] diff --git a/wiki/concepts/Foundation-Models.md b/wiki/concepts/Foundation-Models.md new file mode 100644 index 00000000..8fcb35e9 --- /dev/null +++ b/wiki/concepts/Foundation-Models.md @@ -0,0 +1,33 @@ +--- +title: "Foundation Models" +type: concept +tags: [AI, ML, foundation-model, generative-AI, LLM] +sources: + - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin + - public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec +last_updated: 2026-05-12 +--- + +## Definition +Foundation Models（基础模型）是拥有数十亿参数的大规模预训练模型，是生成式 AI 的核心驱动力。Amazon 认为大多数客户体验和应用将被生成式 AI 重塑，而生成式 AI 的力量来自于基础模型。 + +## Key Properties +- **规模**: 数十亿参数（billions of parameters） +- **预训练**: 在大规模通用数据上预训练 +- **可定制**: 支持微调（Fine-tuning）、持续预训练、RAG 等数据定制技术 +- **多模态**: 可处理文本、图像、代码等多种模态 + +## Related Concepts +- [[Generative-AI]]：基础模型是生成式 AI 的核心技术 +- [[RAG]]：检索增强生成，用于在基础模型上整合私有数据 +- [[Amazon-Bedrock]]：提供基础模型访问的全托管服务 +- [[Amazon-Titan]]：Amazon 开发的基础模型系列 + +## Examples +- Amazon Titan（Amazon Bedrock 内置） +- Anthropic Claude +- Meta Llama +- OpenAI GPT 系列 + +## Sources +- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] diff --git a/wiki/concepts/GitOps.md b/wiki/concepts/GitOps.md index 7d712eed..deddafa8 100644 --- a/wiki/concepts/GitOps.md +++ b/wiki/concepts/GitOps.md @@ -1,44 +1,79 @@ ---- -title: "GitOps" -type: concept -tags: - - DevOps - - CI/CD - - Kubernetes - - Infrastructure as Code ---- - -## Definition -GitOps 是一种将软件开发的版本控制与协作原则应用于云原生基础设施和应用部署的方法论。核心思想：**使用 Git 作为单一事实来源（Single Source of Truth）声明系统的期望状态，由自动化代理（GitOps Controller）持续协调实际状态向期望状态收敛。** - -## Four Principles -1. **声明式配置（Declarative Configuration）**：所有基础设施和应用配置必须以声明式代码描述，而非命令式脚本 -2. **版本控制（Version Control）**：所有配置存储在 Git 仓库中，享受完整的变更历史、代码审查和回滚能力 -3. **CD 流程分离（CD Process Separation）**：CI 专注构建和分析代码，CD 专注部署，两者解耦增强安全性 -4. **自修复协调器（Automated Reconciliation）**：GitOps Controller 持续监控实际状态与 Git 声明状态，自动调和偏差 - -## Key Benefits -- 开发者只需掌握 Git 即可完成安全部署 -- 分钟级代码变更上线 -- 零停机回滚（Git 历史即回滚计划） -- Git 提交日志天然构成合规审计追踪 -- 提高开发者生产力（使用熟悉的工具） - -## Pull Model vs Push Model - -| | Pull Model（推荐） | Push Model | -|---|---|---| -| 机制 | 部署代理主动监控 Git 和目标系统 | CI/CD 管道主动推送变更到目标 | -| 安全性 | 更高——系统状态不暴露给外部 | 较低——需外部访问目标系统 | -| 代表工具 | ArgoCD, Flux | Jenkins CI/CD, Terraform Cloud | -| 适用场景 | GitOps 核心模式 | 传统 CI/CD 扩展 | - -## Relationship with IaC -GitOps 是 [[Infrastructure as Code]] 的部署编排层： -- **IaC**：定义"基础设施应该是什么样的"（Terraform/Pulumi/HCL） -- **GitOps**：定义"如何确保基础设施始终符合声明"（ArgoCD/Flux/Atlantis） - -## Sources -- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 方法论入门，Victor Etkin 主讲 -- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] — Atlantis 作为 GitOps 工具实践 -- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 与 GitOps 的关联 +--- +title: "GitOps" +type: concept +tags: + - GitOps + - IaC + - DevOps + - CD +sources: + - ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments + - ctp-topic-33-an-introduction-to-gitops + - ctp-topic-9-ci-cd-with-gruntwork +last_updated: 2026-04-29 +--- + +# GitOps + +## Definition + +GitOps 是将软件开发原则（尤其是 Git 版本控制）应用于基础设施和应用程序部署的方法论。其核心思想是：**将 Git 仓库作为声明式配置的单一事实来源（Single Source of Truth），通过自动化机制确保实际环境与 Git 中声明的期望状态保持一致。** + +## Core Principles + +1. **Declarative Configuration（声明式配置）** + 所有基础设施和应用配置以声明式语言（如 Terraform HCL、Kubernetes YAML）描述，而非命令式步骤。 + +2. **Version Control（版本控制）** + 所有配置存储在 Git 仓库中，享受版本历史、代码审查（Pull Request）和回滚能力。 + +3. **Automated CD（自动化持续交付）** + CI 专注代码构建和分析，CD 专注部署；两者解耦，增强安全性和可靠性。 + +4. **Self-Healing（自修复协调）** + GitOps Controller 持续监控实际状态与 Git 声明状态，自动调和偏差（drift correction）。 + +## Architecture Patterns + +### Pull Model（推荐） +- GitOps Agent（如 ArgoCD、Flux）同时监控 Git 仓库和目标系统 +- Agent 通过 Pull 方式主动检测变更，无需外部系统推送 +- 安全性更高，符合零信任原则 + +### Push Model +- CI/CD 流水线（如 Jenkins、GitHub Actions）在代码变更后主动推送到目标环境 +- 配置相对简单，但安全性较低 + +## Tooling Ecosystem + +| Tool | Role | Model | +|------|------|-------| +| [[Atlantis]] | Terraform 自动化 Plan/Apply | Pull（PR-based）| +| ArgoCD | Kubernetes 应用部署 | Pull | +| Flux | Kubernetes 持续交付 | Pull | +| Terraform Cloud/Enterprise | Terraform 协作与状态管理 | Hybrid | + +## GitOps vs Traditional CI/CD + +| Dimension | Traditional CI/CD | GitOps | +|-----------|------------------|--------| +| Source of Truth | Pipeline definition | Git repository | +| Trigger | Push to repo | Automated pull + diff detection | +| State Drift Detection | Manual or periodic | Continuous automatic | +| Rollback | Manual or scripted | Git revert + auto-sync | +| Audit Trail | Build logs | Git commit history | +| Security Model | Token-based push | Agent has minimal permissions | + +## Related Concepts +- [[Infrastructure as Code (IaC)]]：GitOps 的核心技术基础 +- [[CI/CD Pipeline]]：GitOps 的前身和组成部分 +- [[Terraform]]：主流 IaC 工具，Atlantis 是其 GitOps 工具 + +## Related Entities +- [[Atlantis]]：Terraform GitOps 的核心工具实现 +- [[Jenkins]]：传统 CI/CD 模式（非 GitOps 原生） + +## Related Sources +- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] — Atlantis 工具实践层 +- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 概念层（Victor Etkin 讲解） +- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 实践 diff --git a/wiki/concepts/ITIL-Service-Management.md b/wiki/concepts/ITIL-Service-Management.md new file mode 100644 index 00000000..dc6264fd --- /dev/null +++ b/wiki/concepts/ITIL-Service-Management.md @@ -0,0 +1,49 @@ +--- +title: ITIL Service Management +type: concept +tags: [ITIL, Framework, Process] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] +--- + +# ITIL Service Management + +**ITIL（Information Technology Infrastructure Library）服务管理框架** 将业务流程分为五个阶段，是企业 IT 服务管理的国际标准方法论。 + +## Five Stages + +| 阶段 | 描述 | +|------|------| +| **Service Strategy（服务战略）** | 定义服务如何为客户创造价值 | +| **Service Design（服务设计）** | 设计新服务或变更服务 | +| **Service Transition（服务过渡）** | 构建和部署服务，需求管理对应此阶段 | +| **Service Operation（服务运营）** | 日常运维和支持 | +| **Continual Service Improvement（持续服务改进）** | 优化服务质量和效率 | + +## Application in Cloud Transformation + +在 OpenText 云转型过程中： +- **Oli Workflow** 对应请求履约的第一阶段（服务过渡阶段） +- **Demand Management** 是服务过渡阶段的关键活动 +- **Product Backlog** 支持持续服务改进 + +## Core Principles + +1. **以服务为导向**：一切活动都围绕服务交付 +2. **持续改进**：PDCA 循环不断优化 +3. **端到端治理**：覆盖服务全生命周期 + +## Related Concepts + +- [[Demand-Management]] — 需求管理 +- [[Oli-Workflow]] — 审批工作流 +- [[SMACs]] — 技术栈组合 +- [[FinOps]] — 云财务运营 + +## Related Entities + +- [[MUI]] — 审批人 +- [[Shannon]] — 审批人 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/concepts/Idempotency.md b/wiki/concepts/Idempotency.md new file mode 100644 index 00000000..c5e60245 --- /dev/null +++ b/wiki/concepts/Idempotency.md @@ -0,0 +1,29 @@ +--- +title: "Idempotency" +type: concept +tags: + - Architecture + - Reliability + - Cloud +last_updated: 2026-04-14 +--- + +## Definition +幂等性（Idempotency）是指一个操作被执行一次和被执行多次，产生的结果是相同的。在分布式系统和事件驱动架构中，这是确保系统可靠性的关键设计原则。 + +## Why It Matters in EDA +Lambda 异步调用会自动重试（通常重试 2-3 次），因此服务在处理事件时必须考虑幂等性，避免因重复处理导致的数据不一致或副作用（如重复下单、重复扣款）。 + +## Implementation Strategies +- 为每个事件分配唯一标识符（Event ID），消费者维护已处理事件记录 +- 使用数据库唯一约束或乐观锁防止重复写入 +- 基于业务语义的去重（如订单号唯一性检查） + +## Applicable Scenarios +- 订单处理和支付 +- 库存扣减 +- 消息确认 +- 状态更新 + +## Sources +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/InfrastructureAsCode.md b/wiki/concepts/InfrastructureAsCode.md new file mode 100644 index 00000000..be86916e --- /dev/null +++ b/wiki/concepts/InfrastructureAsCode.md @@ -0,0 +1,33 @@ +--- +title: "Infrastructure as Code" +type: concept +tags: + - IaC + - DevOps + - Cloud +sources: + - ctp-topic-48-terraform-vs-terragrunt.md +- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] +last_updated: 2026-05-15 +--- + +## Definition +Infrastructure as Code（IaC）是通过代码定义和管理基础设施的实践，实现基础设施的版本控制、自动化部署和一致性管理，而非手动配置。 + +## Key Characteristics +- **声明式配置**：定义期望的最终状态，而非步骤 +- **版本控制**：所有基础设施定义纳入 Git 管理 +- **幂等性**：重复执行产生相同结果 +- **自动化**：与 CI/CD 流程深度集成 + +## Core Tools +- [[Terraform]] — 云无关的 IaC 工具 +- [[Terragrunt]] — Terraform 的 DRY 包装器 +- AWS CloudFormation — AWS 原生 IaC +- Pulumi — 编程语言驱动的 IaC +- Ansible — 配置管理工具 + +## Connections +- [[Terraform]] ← implements ← [[InfrastructureAsCode]] +- [[Terragrunt]] ← extends ← [[Terraform]]（多环境管理） +- [[Atlantis]] ← enables ← [[GitOps]]（PR 驱动的 IaC 部署） diff --git a/wiki/concepts/JDBCWrapper.md b/wiki/concepts/JDBCWrapper.md new file mode 100644 index 00000000..a1f1af97 --- /dev/null +++ b/wiki/concepts/JDBCWrapper.md @@ -0,0 +1,92 @@ +--- +title: "JDBCWrapper" +type: concept +tags: + - AWS + - Java + - Database + - Security + - SDK +--- + +## Definition + +JDBC Wrapper（JDBC 包装器）是一种通过包装 JDBC 连接，配合 AWS SDK 从 AWS Secrets Manager 动态获取数据库凭据的编程模式，使应用程序无需硬编码数据库密码即可连接数据库。 + +## Problem Statement + +传统数据库连接方式： +``` +应用程序 → 配置文件/环境变量 → 数据库 + ↑ + 硬编码明文密码（安全风险） +``` + +**问题**： +- 密码在代码、配置文件或环境变量中明文存储 +- 密码变更需要修改配置并重启应用 +- 无法实现细粒度的访问控制 +- 密码泄露风险高 + +## Solution: JDBC Wrapper Pattern + +使用 JDBC Wrapper 的连接方式： +``` +应用程序 → JDBC Wrapper + AWS SDK → AWS Secrets Manager → 数据库 +``` + +**工作流程**： +1. 应用程序通过 JDBC Wrapper 建立连接 +2. JDBC Wrapper 调用 AWS SDK 向 Secrets Manager 请求凭据 +3. Secrets Manager 返回动态获取的数据库密码 +4. JDBC Wrapper 使用临时凭据建立数据库连接 +5. 连接完成后，凭据不在应用内存中长期保留 + +## Key Benefits + +| 优势 | 说明 | +|------|------| +| **无密码访问** | 用户无需知道数据库密码，通过 IAM 角色授权 | +| **动态轮换** | 数据库密码轮换时，应用无需重启 | +| **集中审计** | 所有数据库访问通过 Secrets Manager 记录 | +| **最小权限** | 基于 IAM 角色控制数据库访问权限 | +| **审计追溯** | 用户名由角色控制，可追溯数据库操作 | + +## Implementation Architecture + +``` +┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ ┌──────────────┐ +│ Application │────▶│ JDBC Wrapper │────▶│ AWS SDK │────▶│ Secrets │ +│ │ │ (密码获取) │ │ (调用API) │ │ Manager │ +└─────────────┘ └──────────────┘ └─────────────────┘ └──────────────┘ + │ + ▼ + ┌──────────────┐ + │ Oracle/MySQL │ + │ Database │ + └──────────────┘ +``` + +## Access Control Model + +- **用户名**：由 IAM 角色控制，根据角色映射数据库用户 +- **密码**：由 AWS Secrets Manager 动态提供，无需人工知晓 +- **访问权限**：通过 IAM Policy 控制谁能访问哪些 Secrets + +## Related Concepts + +- [[SecretsManagement]]：敏感信息管理的整体框架 +- [[SecretRotation]]：密码轮换机制，与 JDBC Wrapper 配合实现无停机轮换 +- [[AWS-SDK]]：AWS 服务调用开发工具包 +- [[IAM-Roles]]：基于角色的访问控制机制 + +## Sources + +- [[CTP-Topic-62-AWS-Secrets-Manager]] — Victor 演示使用 JDBC Wrapper + AWS SDK 实现无密码 Oracle 数据库登录 + +## Aliases + +- Database Credential Provider +- Secrets Manager JDBC Driver +- Dynamic Database Credentials +- AWS SDK Database Wrapper diff --git a/wiki/concepts/MLOps.md b/wiki/concepts/MLOps.md new file mode 100644 index 00000000..d71cb804 --- /dev/null +++ b/wiki/concepts/MLOps.md @@ -0,0 +1,59 @@ +--- +title: "MLOps" +type: concept +tags: [ML, DevOps, machine-learning, operations, CI/CD] +sources: + - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin +last_updated: 2026-05-12 +--- + +## Definition +MLOps（Machine Learning Operations，机器学习运维）将机器学习与运维结合，涉及人员、技术和流程，以实现协作式 ML 解决方案。ML Ops 需要多元化团队和鼓励协作的文化，扩展了 DevOps 的原则和方法。 + +## Key Components + +### Three Pipelines + +#### 1. Data Pipeline（数据管道） +- 数据收集（Data Collection） +- 数据集成（Data Integration） +- 数据准备（Data Preparation） +- **工具**: Amazon S3, Amazon Redshift + +#### 2. Training Pipeline（训练管道） +- 特征工程（Feature Engineering） +- 模型训练（Model Training） +- 超参数调优（Hyperparameter Tuning） +- **工具**: Amazon SageMaker + +#### 3. Inference Pipeline（推理管道） +- 模型部署（Model Deployment） +- 模型监控（Model Monitoring） +- **工具**: Amazon SageMaker Real-time Endpoints + +## Key Challenges +- 数据溯源（Data Provenance） +- 模型管理（Model Management） +- 部署工作流（Deployment Workflows） +- 持续集成/持续部署（CI/CD） +- 监控与可观测性 + +## Relationship to DevOps +MLOps 在 DevOps 实践基础上增加了 ML 特有的挑战： +- 模型版本控制 +- 实验追踪 +- A/B 测试 +- 模型性能监控 +- 数据漂移检测 + +## Related Concepts +- [[DevOps]] +- [[Amazon-SageMaker]] +- [[Foundation-Models]] +- [[Responsible-AI]] + +## Related Entities +- [[AWS]] + +## Sources +- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] diff --git a/wiki/concepts/Oli-Workflow.md b/wiki/concepts/Oli-Workflow.md new file mode 100644 index 00000000..d9b2d268 --- /dev/null +++ b/wiki/concepts/Oli-Workflow.md @@ -0,0 +1,71 @@ +--- +title: Oli Workflow +type: concept +tags: [Workflow, Cloud-Governance, FinOps] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] +--- + +# Oli Workflow + +**Oli Workflow** 是 OpenText 超大规模云厂商支出审批工作流，所有云支出请求必须经过此流程审批。 + +## Overview + +Oli Workflow 是企业云治理的核心流程： +- **强制审批**：所有超大规模云厂商支出，无论金额，均需 MUI 或 Shannon 书面审批 +- **团队接管**：由 Tom Bice 领导的 FinOps 团队接管 +- **平台集成**：正在集成到 SMACs 平台 + +## Three-Stage Approval Process + +| 阶段 | 负责方 | 验证内容 | +|------|--------|----------| +| 1. 可行性验证 | FinOps | 评估需求的技术和财务可行性 | +| 2. 技术可行性验证 | Cloud Services | 评估技术实现可行性 | +| 3. 预算可用性验证 | FPNA Team | 确认预算可用性 | + +## Request Form Fields + +| 字段 | 说明 | +|------|------| +| 员工信息 | 从企业 AD 自动拉取 | +| 组织选择 | 下拉菜单选择 | +| 成本中心 | 来自 Talent Central | +| 请求类型 | 预算增加 vs 新建实验室空间 | +| 云服务商 | 下拉选择 | +| 区域 | 必须是活跃区域列表中的区域 | +| 理由说明 | 评论区域提交 | + +## Key Features + +- **CSV 报告**：飞行中 CSV 报告追踪工作流状态、申请人、成本中心、月成本、当前步骤 +- **自动化整合**：与 Confluence 基础说明、AD 员工信息、Talent Central 成本中心集成 +- **拒绝机制**：未提供理由详情的请求将被立即拒绝 + +## Approval Authority + +| 审批人 | 职责 | +|--------|------| +| MUI | 超大规模云厂商支出审批人 | +| Shannon | 超大规模云厂商支出审批人 | + +## Related Concepts + +- [[FinOps]] — 云财务运营 +- [[Demand-Management]] — 需求管理 +- [[SMACs]] — 技术栈组合 +- [[ITIL-Service-Management]] — ITIL 框架 +- [[Product-Backlog]] — 产品待办列表 + +## Related Entities + +- [[Tom-Bice]] — FinOps 团队负责人 +- [[FPNA-Team]] — 预算验证团队 +- [[MUI]] — 审批人 +- [[Shannon]] — 审批人 +- [[Octane]] — 需求管理平台 +- [[Qixi]] — 需求提交入口 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/concepts/Orchestration.md b/wiki/concepts/Orchestration.md new file mode 100644 index 00000000..41cbb936 --- /dev/null +++ b/wiki/concepts/Orchestration.md @@ -0,0 +1,44 @@ +--- +title: "Orchestration" +type: concept +tags: + - EDA + - Architecture + - Microservices + - AWS +last_updated: 2026-04-14 +--- + +## Aliases +- Orchestration Pattern +- 编排模式 +- 集中式服务协调 + +## Definition +编排模式（Orchestration）是一种由中央协调器（Orchestrator）集中控制和协调多个服务执行复杂业务流程的模式。与编舞模式（Choreography）的去中心化不同，编排模式通过中央工作流引擎驱动各服务按顺序执行任务。 + +## AWS Implementation +- **AWS Step Functions**：AWS 提供的工作流服务，用于构建状态机 + - **State Machine**：状态机由多个 State（状态）组成，每个 State 代表一个工作步骤 + - **Transitions**：状态转换定义从一个状态到下一个状态的条件和路径 + - **Standard Workflows**：长时运行工作流，适合人工审批、长时间处理流程 + - **Express Workflows**：高频短时工作流，适合毫秒级响应的大规模事件处理 + +## Characteristics +- **Centralized**：中央协调器控制整体流程 +- **Visible**：业务流程和状态转换清晰可见，便于监控和追踪 +- **Easier Debugging**：工作流失败时可准确定位到具体状态 +- **Tight Coupling Risk**：中央协调器与各服务存在一定耦合 + +## Comparison with Choreography +| 维度 | Orchestration（编排） | Choreography（编舞） | +|------|---------------------|---------------------| +| 控制 | 集中式 | 去中心化 | +| 协调器 | 有（Step Functions） | 无 | +| 复杂度 | 局部高，整体低 | 局部低，整体高 | +| 可观测性 | 易于追踪 | 较难追踪 | +| 适用场景 | 复杂、有明确业务流程 | 简单、独立的服务 | + +## Sources +- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/concepts/Override-Status.md b/wiki/concepts/Override-Status.md new file mode 100644 index 00000000..cb775097 --- /dev/null +++ b/wiki/concepts/Override-Status.md @@ -0,0 +1,51 @@ +--- +title: "Override Status" +type: concept +tags: + - AWS + - Scheduling + - Control + - AWS-Instance-Scheduler +sources: + - ctp-topic-27-aws-instance-scheduler +last_updated: 2026-05-12 +--- + +## Override Status + +AWS Instance Scheduler 中的高级配置机制，允许管理员强制覆盖正常的调度规则，将实例保持在特定状态（通常为停止状态）。 + +## Core Mechanism + +通过在实例上设置 `Override` 标签来激活： + +- **`Override = true`**：强制将实例保持在停止状态，即使在预设的启动时间内也不启动 +- **`Override = false`**：恢复正常调度逻辑 + +## Use Cases + +### 1. 紧急维护场景 +- 实例正在进行紧急安全补丁更新 +- 临时禁用调度以避免干扰关键操作 + +### 2. 资源保留场景 +- 保留特定环境（如 UAT/预生产）在特定时期保持运行 +- 临时排除特定实例从自动调度 + +### 3. 故障规避 +- 实例上运行的任务无法接受意外重启 +- 生产等效环境需要更精细的控制 + +## Relationship to Tagging + +Override Status 通过 `Override` 标签实现，是 Instance Scheduler [[Tagging]] 机制的重要组成部分： + +| 标签键 | 作用 | 优先级 | +|--------|------|--------| +| `Schedule` | 指定调度名称 | 正常调度 | +| `Override = true` | 强制停止覆盖 | 最高优先级 | + +## Related Pages +- [[AWS-Instance-Scheduler]] — 主要使用场景 +- [[Tagging]] — 实现机制 +- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 diff --git a/wiki/concepts/Pre-commit-Hooks.md b/wiki/concepts/Pre-commit-Hooks.md new file mode 100644 index 00000000..41709282 --- /dev/null +++ b/wiki/concepts/Pre-commit-Hooks.md @@ -0,0 +1,34 @@ +--- +title: "Pre-commit Hooks" +type: concept +tags: + - GitOps + - DevOps + - CI/CD + - Automation +last_updated: 2026-05-11 +--- + +# Pre-commit Hooks + +## Definition +在提交代码前运行的脚本工具，通常用于代码格式化、linting、安全扫描等。Renovate Bot 可以自动检测并更新这些钩子插件的版本号。 + +## Core Functions +- 在 `git commit` 前自动执行检查脚本 +- 常用场景：代码格式化（Prettier）、linting（ESLint）、安全扫描（Trivy）、Secrets 检测 +- 版本管理：保持钩子插件版本与最新安全修复同步 +- Renovate 集成：自动为 pre-commit 配置文件（如 `.pre-commit-config.yaml`）中的版本标签创建更新 PR + +## Related Concepts +- [[Renovate-Bot]] — Renovate Bot 可自动更新 pre-commit 钩子插件版本 +- [[Dependency-Management]] — pre-commit 钩子是项目依赖的一部分 +- [[GitOps]] — pre-commit 是 GitOps 工作流中的质量门禁 + +## Related Sources +- [[ctp-topic-15-working-with-renovatebot]] + +## Aliases +- Git Hooks +- Pre-commit Framework +- pre-commit-config.yaml diff --git a/wiki/concepts/Privileged-Access-Management.md b/wiki/concepts/Privileged-Access-Management.md new file mode 100644 index 00000000..2df4e9a5 --- /dev/null +++ b/wiki/concepts/Privileged-Access-Management.md @@ -0,0 +1,89 @@ +--- +title: "Privileged-Access-Management" +type: concept +tags: + - Security + - PAM + - Compliance + - Cloud + - DevOps +--- + +## Definition + +Privileged Access Management（PAM，特权访问管理）是一类安全解决方案，用于管理和监控具有 elevated permissions 的账号访问权限。特权账号包括系统管理员、数据库管理员、安全管理员等拥有超出普通用户权限的账号，以及应用程序服务账号、API 账号等非人工身份。 + +## Core Objectives + +1. **凭据保护**：集中存储和管理特权账号密码、SSH 密钥、API Key 等敏感凭据 +2. **访问控制**：实施最小权限原则，确保用户仅获得完成任务所需的最小权限 +3. **会话监控**：记录和审计所有特权会话，支持事后追溯和合规审查 +4. **威胁检测**：实时检测异常特权行为，防止凭据滥用和横向移动攻击 + +## PAM Architecture + +``` +┌─────────────────────────────────────────────────────────────┐ +│ PAM Solution │ +├─────────────────────────────────────────────────────────────┤ +│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ +│ │ Credential │ │ Session │ │ Risk │ │ +│ │ Vault │ │ Manager │ │ Engine │ │ +│ └─────────────┘ └─────────────┘ └─────────────┘ │ +│ │ +│ ┌─────────────────────────────────────────────┐ │ +│ │ Access Control Layer │ │ +│ │ (RBAC, MFA, Policy-based Access) │ │ +│ └─────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────┘ + ↑ + ┌─────────────────┼─────────────────┐ + ↓ ↓ ↓ + ┌─────────┐ ┌─────────┐ ┌─────────┐ + │ Root │ │ DB │ │ API │ + │ Account │ │ Admin │ │ Service │ + └─────────┘ └─────────┘ └─────────┘ +``` + +## Cloud-Native vs Traditional PAM + +| Aspect | Traditional PAM | Cloud-Native (AWS Secrets Manager) | +|--------|-----------------|----------------------------------| +| Deployment | On-prem / Hybrid | Fully managed SaaS | +| Client Agent | Required | Not required | +| Scalability | Manual scaling | Auto-scaling | +| Cost Model | Perpetual license + maintenance | Pay-per-use | +| Integration | Manual configuration | Native AWS integration | + +## Key Vendors + +- **CyberArk**：Enterprise PAM market leader, on-prem and cloud offerings +- **AWS Secrets Manager**：Cloud-native secrets management +- **HashiCorp Vault**：Cloud-agnostic secrets and privileged access +- **BeyondTrust**：Endpoint privilege management +- **Thycotic**：Privileged access management + +## Related Concepts + +- [[SecretsManagement]]：敏感信息管理的整体框架 +- [[SecretRotation]]：密钥轮换机制 +- [[IAM-Roles]]：基于角色的访问控制 +- [[Zero-Trust]]：零信任安全模型 + +## Related Entities + +- [[CyberArk]]：Enterprise PAM vendor +- [[AWS]]：Cloud-native secrets management provider +- [[HashiCorp]]：Cloud-agnostic secrets management + +## Sources + +- [[ctp-topic-37-secrets-certificates-management]] — CyberArk Micro Focus PAM evaluation +- [[ctp-topic-62-aws-secrets-manager]] — AWS-native PAM implementation + +## Aliases + +- PAM +- Privileged Access Management +- Privileged Identity Management +- PIM diff --git a/wiki/concepts/Product-Backlog.md b/wiki/concepts/Product-Backlog.md new file mode 100644 index 00000000..30856d8d --- /dev/null +++ b/wiki/concepts/Product-Backlog.md @@ -0,0 +1,51 @@ +--- +title: Product Backlog +type: concept +tags: [Agile, Scrum, Product-Management] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16, ctp-topic-57-product-backlog-managing-demand] +--- + +# Product Backlog + +**产品待办列表（Product Backlog）** 是敏捷开发中的核心工件，是已排序的需求、特性、技术任务和缺陷的列表，是 Sprint 规划的输入来源。 + +## Overview + +在 OpenText 云转型中： +- Oli Workflow 审批通过的请求进入 Product Backlog 管理管道 +- 通过双周评审会议评估需求的理解度、价值和优先级 +- Sprint 规划采用 50% 新需求 / 50% 支持+技术债的配比 + +## Key Processes + +| 阶段 | 活动 | +|------|------| +| 需求提交 | 通过 Octane 提交 | +| 评审会议 | 评估理解度、价值、优先级 | +| 特性化 | 带任务列表的详细需求 | +| Sprint 规划 | 提前6个 Sprint 规划 | +| 履约 | Prerequisite Phase → Sprint | + +## Attributes + +- **优先级排序**：基于 WSJF（Weighted Shortest Job First） +- **估算**：评估工作量大小 +- **细化（Refinement）**：持续完善需求细节 +- **渐进明细**：随着理解加深不断完善 + +## Related Concepts + +- [[Demand-Management]] — 需求管理 +- [[Oli-Workflow]] — 审批工作流 +- [[SMACs]] — 技术栈组合 +- [[WSJF]] — 加权最短工作优先 + +## Related Entities + +- [[Octane]] — 需求管理平台 +- [[Qixi]] — 需求提交入口 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] +- [[sources/ctp-topic-57-product-backlog-managing-demand.md]] diff --git a/wiki/concepts/Prompt-Engineering.md b/wiki/concepts/Prompt-Engineering.md new file mode 100644 index 00000000..1eb4480a --- /dev/null +++ b/wiki/concepts/Prompt-Engineering.md @@ -0,0 +1,58 @@ +--- +title: "Prompt Engineering" +type: concept +tags: [generative-ai, llm, prompt, aws, amazon-bedrock] +sources: [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111] +last_updated: 2026-05-12 +--- + +## Aliases +- 提示词工程 +- Prompt Design +- 提示工程 + +## Summary + +**Prompt Engineering**（提示词工程）是创建、设计和优化提示词（Prompt）以引导大语言模型（LLM）产生准确、相关输出的技术实践。它是一个迭代过程，需要针对具体用例反复测试和调整提示词。 + +## Key Properties + +- **类型**：方法 / 技术实践 +- **核心目标**：确保 LLM 输出的准确性和相关性 +- **过程性质**：迭代式（测试 → 调整 → 优化） + +## Prompt 四大组件 + +1. **指令（Instruction）**：明确告诉模型要执行什么任务 +2. **上下文（Context）**：提供背景信息，帮助模型理解场景 +3. **用户输入（User Input）**：具体的问题或请求 +4. **输出指示器（Output Indicator）**：指定期望的输出格式或风格 + +## 基础技巧 + +### One-shot Prompting（单样本提示） +- 提供一个示例，让模型理解任务模式 +- 适合简单、结构清晰的任务 + +### Few-shot Prompting（少样本提示） +- 提供 2~5 个示例，帮助模型理解多样性 +- 适合需要格式一致性但示例丰富的场景 + +### Chain-of-Thought（思维链） +- 在提示词中引导模型逐步思考 +- 提供 step-by-step 推理示例 +- 适合复杂推理和多步骤任务 + +## 最佳实践 + +- **清晰准确**：指令应具体、无歧义 +- **结构化**：使用明确的分隔符组织各组件 +- **考虑人类响应**：LLM 训练数据来自人类，因此提示词应符合人类沟通习惯 +- **迭代优化**：针对具体用例持续测试和调整 + +## Connections + +- 核心技术：[[GenerativeAI]]（LLM 是 Prompt Engineering 的载体） +- 应用平台：[[AmazonBedrock]]（Bedrock 上的基础模型均支持 Prompt Engineering） +- 相关工具：[[AmazonQ]]（Amazon Q Developer 利用 Prompt Engineering 优化代码生成） +- 相关概念：[[RAG从入门到精通系列1：基础RAG]]（RAG 系统中的 Prompt Engineering 是关键调优点） diff --git a/wiki/concepts/RDS-Maintenance-Window.md b/wiki/concepts/RDS-Maintenance-Window.md new file mode 100644 index 00000000..f1b0887e --- /dev/null +++ b/wiki/concepts/RDS-Maintenance-Window.md @@ -0,0 +1,49 @@ +--- +title: "RDS Maintenance Window" +type: concept +tags: + - AWS + - RDS + - Database + - Maintenance +sources: + - ctp-topic-27-aws-instance-scheduler +last_updated: 2026-05-12 +--- + +## RDS Maintenance Window + +AWS RDS（Relational Database Service）维护窗口是数据库实例进行必要维护操作（如补丁升级、系统升级）的时间段，由 AWS 预先定义或由用户指定。 + +## Core Characteristics + +- **频率**：每个 RDS 实例每 7 天强制执行一次维护 +- **持续时间**：通常 30-60 分钟 +- **可中断性**：维护期间实例可能不可用 +- **用户控制**：用户可指定首选维护窗口（每周一次，每次 30 分钟） + +## AWS Instance Scheduler 中的处理 + +Instance Scheduler 具备智能感知 RDS 维护窗口的能力： + +1. **维护前**：在维护窗口开始前将 RDS 实例状态记录为"即将进入维护" +2. **维护期间**：暂停调度操作，不执行启停指令 +3. **维护完成后**：自动识别维护结束，恢复正常的调度状态 + +## Key Considerations + +- **停止 vs 终止**：RDS 实例的关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"，否则维护窗口结束后实例不会重新启动 +- **多可用区**：Multi-AZ 实例的维护通常自动在备用实例上进行，对主实例影响较小 +- **蓝绿部署**：使用蓝绿部署进行数据库升级可减少停机时间 + +## Relationship to Instance Scheduler + +RDS Maintenance Window 是 Instance Scheduler 在调度 RDS 实例时必须考虑的特殊约束： + +- 实例的 `InstanceType` 标签用于区分 EC2 和 RDS +- RDS 实例需要额外的维护窗口逻辑判断 +- 调度算法需查询 RDS API 获取实例维护状态 + +## Related Pages +- [[AWS-Instance-Scheduler]] — 依赖此机制 +- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 diff --git a/wiki/concepts/Rate-Limiting.md b/wiki/concepts/Rate-Limiting.md new file mode 100644 index 00000000..1f5b2f32 --- /dev/null +++ b/wiki/concepts/Rate-Limiting.md @@ -0,0 +1,33 @@ +--- +title: "Rate Limiting" +type: concept +tags: + - CI/CD + - DevOps + - GitOps +last_updated: 2026-05-11 +--- + +# Rate Limiting + +## Definition +速率限制，为防止自动化工具（如 Renovate Bot）瞬间产生过多 Pull Request 导致 CI/CD 系统（如 Jenkins）崩溃，Renovate 允许限制每小时或同时开启的 PR 数量。 + +## Core Functions +- 限制每小时创建的 PR 数量 +- 限制同时打开的 PR 数量上限 +- 防止 GitHub API 触发速率限制（429 Too Many Requests） +- 避免给 CI/CD 系统带来突发负载 + +## Related Concepts +- [[Renovate-Bot]] — Rate Limiting 是 Renovate Bot 的重要配置选项 +- [[Dependency-Management]] — Rate Limiting 支撑依赖管理的稳定运行 +- [[CI-CD]] — CI/CD 流水线是 Rate Limiting 的保护对象 + +## Related Sources +- [[ctp-topic-15-working-with-renovatebot]] + +## Aliases +- API Rate Limiting +- Request Throttling +- PR Rate Limit diff --git a/wiki/concepts/ReservedInstances.md b/wiki/concepts/ReservedInstances.md new file mode 100644 index 00000000..233b842c --- /dev/null +++ b/wiki/concepts/ReservedInstances.md @@ -0,0 +1,39 @@ +--- +title: "Reserved Instances" +type: concept +tags: + - AWS + - Cost-Optimization + - FinOps +aliases: + - Reserved Instances + - RI + - 预留实例 +last_updated: 2026-05-12 +--- + +## Overview + +Reserved Instances（预留实例）通过预付费或无预付承诺，获得相比 On-Demand 最高 60-72% 的折扣。适用于稳定运行的长期工作负载。 + +## Key Characteristics + +- **承诺期限**：1年或3年 +- **支付选项**：全额预付、部分预付、无预付 +- **范围**：区域级或可用区级 +- **类型**：Standard（可交换）、Convertible（可转换） + +## When to Use + +- 生产环境中的稳定工作负载 +- 数据库实例 +- 核心业务应用 +- 7×24 运行的服务 + +## Related Pages + +- [[FinOps]] +- [[SavingsPlans]] +- [[SpotInstances]] +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] +- [[ctp-topic-63-optimise-resource-cost-using-automation]] diff --git a/wiki/concepts/Responsible-AI.md b/wiki/concepts/Responsible-AI.md new file mode 100644 index 00000000..d2456ce0 --- /dev/null +++ b/wiki/concepts/Responsible-AI.md @@ -0,0 +1,47 @@ +--- +title: "Responsible AI" +type: concept +tags: [AI, ethics, governance, responsible-AI, transparency] +sources: + - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin + - public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec +last_updated: 2026-05-12 +--- + +## Definition +Responsible AI（负责任 AI）是一套确保 AI 系统安全、公平、透明和合规的原则和实践。AWS 在 Amazon Bedrock 中提供了 Guardrails for Amazon Bedrock，用于根据应用需求和负责任 AI 政策定制安全保障措施。 + +## Six Key Principles + +| 原则 | 描述 | +|------|------| +| **Fairness（公平性）** | 确保 AI 系统不会对特定群体产生偏见 | +| **Explainability（可解释性）** | 使 AI 决策过程透明可理解 | +| **Robustness（鲁棒性）** | 确保 AI 系统在各种条件下稳定可靠 | +| **Governance（治理）** | 建立清晰的 AI 使用和决策责任框架 | +| **Transparency（透明度）** | 公开 AI 系统的能力、局限和使用方式 | +| **Privacy & Security（隐私与安全）** | 保护用户数据，遵守隐私法规 | + +## AWS Implementation + +### Guardrails for Amazon Bedrock +Amazon Bedrock 提供的安全护栏服务，允许客户： +- 根据应用需求定制安全保障措施 +- 过滤有害内容 +- 实施负责任 AI 政策 +- 监控和审计 AI 交互 + +### Data Privacy +Amazon Bedrock 在数据隐私方面的保证： +- 用户数据不与第三方模型提供商共享 +- 提示词（Prompts）不与模型提供商共享 +- 仅在请求-响应周期内存储数据 +- 符合 GDPR 合规要求 + +## Related Concepts +- [[Amazon-Bedrock]] +- [[Guardrails-for-Amazon-Bedrock]] +- [[Foundation-Models]] + +## Sources +- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] diff --git a/wiki/concepts/Root-Terragrunt-HCL.md b/wiki/concepts/Root-Terragrunt-HCL.md new file mode 100644 index 00000000..a55e456d --- /dev/null +++ b/wiki/concepts/Root-Terragrunt-HCL.md @@ -0,0 +1,68 @@ +--- +title: "Root Terragrunt HCL" +type: concept +tags: [Terraform, Terragrunt, IaC, Configuration, AWS] +sources: + - ctp-topic-16-cross-account-terraform-modules.md + - ctp-topic-48-terraform-vs-terragrunt.md +last_updated: 2026-05-15 +--- + +## Overview + +Root Terragrunt HCL 是项目根目录下的 `terragrunt.hcl` 配置文件，用于定义所有 Terraform 模块通用的远程状态存储（Remote State）和角色切换逻辑。它是 Terragrunt DRY（Don't Repeat Yourself）原则的核心体现。 + +## Key Responsibilities + +### 1. Remote State Configuration + +```hcl +remote_state { + backend = "s3" + config = { + bucket = "my-terraform-state" + key = "${path_relative_to_include()}/terraform.tfstate" + region = "us-east-1" + encrypt = true + dynamodb_table = "terraform-locks" + } +} +``` + +### 2. Cross-Account Role Switching + +```hcl +inputs = { + # 在跨账号场景中，通过 assume_role 切换到目标账号的角色 + assume_role_arn = "arn:aws:iam::TARGET_ACCOUNT:role/Cross-account-ECS-Deploy-Runner-Role" +} +``` + +## How It Works + +Terragrunt 通过继承机制将根目录的配置自动应用于所有子模块： + +1. **检测模块**：Jenkins 检测到模块目录 +2. **加载配置**：Terragrunt 加载根目录的 `terragrunt.hcl` +3. **注入变量**：自动将 remote_state 和 assume_role_arn 注入子模块 +4. **执行命令**：运行 `terragrunt plan/apply` + +## Relationship with Terragrunt + +- [[Terragrunt]] ← uses ← [[Root-Terragrunt-HCL]] +- [[Cross-account-Terraform-Modules]] ← configured_by ← [[Root-Terragrunt-HCL]] +- [[ECS-Deploy-Runner]] ← configured_by ← [[Root-Terragrunt-HCL]] + +## Key Differences: Local vs CI/CD + +| 环境 | Role 处理 | +|------|----------| +| **本地开发** | Terragrunt 自动从 HCL 配置 Assume Role，无需手动干预 | +| **Jenkins CI/CD** | EDR 使用 HCL 中配置的 assume_role_arn，通过 ECS 容器环境 Assume | + +## Related Concepts + +- [[Terragrunt]]：Terragrunt 是该配置的解析和执行引擎 +- [[TerraformState]]：remote_state 配置定义了状态文件存储位置 +- [[Assume-Role]]：assume_role_arn 配置控制跨账号角色切换 +- [[DRY-Principle]]：Root HCL 是 DRY 原则在 IaC 中的应用 diff --git a/wiki/concepts/SMACs.md b/wiki/concepts/SMACs.md new file mode 100644 index 00000000..02cd16fa --- /dev/null +++ b/wiki/concepts/SMACs.md @@ -0,0 +1,50 @@ +--- +title: SMACs +type: concept +tags: [Technology-Stack, Cloud, Digital-Transformation] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16, ctp-topic-57-product-backlog-managing-demand] +--- + +# SMACs + +**SMACs** 是 Social（社交）、Mobile（移动）、Analytics（分析）、Cloud（云）四种技术的组合，代表现代数字化转型的核心技术栈。 + +## Components + +| 字母 | 含义 | 技术示例 | +|------|------|----------| +| **S** | Social（社交） | 企业社交平台、协作工具 | +| **M** | Mobile（移动） | 移动应用、物联网设备 | +| **A** | Analytics（分析） | 大数据分析、机器学习 | +| **C** | Cloud（云） | 公有云、私有云、混合云 | + +## In OpenText Cloud Transformation + +在 OpenText 云转型中： +- **Oli Workflow** 正在集成到 SMACs 平台 +- **主服务目录（Combined Cloud Products Master Catalog）** 将嵌入 SMACs +- **Enterprise Iton 项目**（标准 OT SMACS 租户）正在进行中 + +## Goals + +- 统一数字化平台，提升服务交付效率 +- 支持业务单元 80% 场景下自助选择所需服务 +- 自动化履约流程，减少人工干预 + +## Related Concepts + +- [[Demand-Management]] — 需求管理 +- [[FinOps]] — 云财务运营 +- [[ITIL-Service-Management]] — ITIL 框架 +- [[Oli-Workflow]] — 审批工作流 + +## Related Entities + +- [[Tom-Bice]] — FinOps 团队负责人，推动 SMACS 集成 +- [[Octane]] — 需求管理平台 +- [[FPNA-Team]] — 预算验证团队 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] +- [[sources/ctp-topic-57-product-backlog-managing-demand.md]] diff --git a/wiki/concepts/SavingsPlans.md b/wiki/concepts/SavingsPlans.md new file mode 100644 index 00000000..54ec9031 --- /dev/null +++ b/wiki/concepts/SavingsPlans.md @@ -0,0 +1,36 @@ +--- +title: "Savings Plans" +type: concept +tags: + - AWS + - Cost-Optimization + - FinOps +aliases: + - Savings Plans + - SP + - 节省计划 +last_updated: 2026-05-12 +--- + +## Overview + +Savings Plans（节省计划）是 AWS 提供的灵活定价模型，通过承诺一定使用量（以美元/小时计算）获得相比 On-Demand 最高 72% 的折扣。比 Reserved Instances 更灵活。 + +## Types + +- **Compute Savings Plans**：最灵活，覆盖 EC2、Lambda、ECS 等 +- **EC2 Instance Savings Plans**：针对特定实例家族的承诺 +- **SageMaker Savings Plans**：针对 SageMaker 服务 + +## Key Advantages + +- 相比 RI 更灵活，无需指定具体实例类型 +- 自动应用于任何符合条件的资源 +- 与 Reserved Instances 可叠加使用 + +## Related Pages + +- [[FinOps]] +- [[ReservedInstances]] +- [[SpotInstances]] +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] diff --git a/wiki/concepts/SecretRotation.md b/wiki/concepts/SecretRotation.md new file mode 100644 index 00000000..7dbdfdc0 --- /dev/null +++ b/wiki/concepts/SecretRotation.md @@ -0,0 +1,92 @@ +--- +title: "SecretRotation" +type: concept +tags: + - AWS + - Security + - Automation + - DevOps +--- + +## Definition + +Secret Rotation（密钥轮换）是指定期自动更换敏感凭据（密码、API Key、证书等）的安全机制，旨在防止长期密钥泄露导致的安全风险。 + +## Why Rotate Secrets? + +1. **降低泄露风险**：即使密钥被意外泄露，轮换机制可限制暴露窗口 +2. **合规要求**：满足 SOC 2、PCI-DSS 等安全合规标准 +3. **密钥生命周期管理**：遵循安全最佳实践中的密钥生命周期原则 +4. **应对内部威胁**：限制离职员工或恶意内部人员的凭据滥用 + +## AWS Secrets Manager Rotation Strategies + +### Built-in Rotation Lambdas + +AWS Secrets Manager 为以下服务提供开箱即用的轮换 Lambda 函数： +- **RDS 数据库**：MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Aurora +- **Redshift** +- **DocumentDB** + +### Custom Rotation Patterns + +#### Oracle Database Password Rotation + +``` +用户密码存储在 Secrets Manager + ↓ +Lambda 函数被触发（或定时） + ↓ +Lambda 连接 Oracle 实例（使用当前凭据） + ↓ +生成新密码 + ↓ +更新数据库中的用户密码 + ↓ +更新 Secrets Manager 中的密码 + ↓ +完成轮换 +``` + +**关键优势**：无需通过邮件发送新密码，通过 AWS 角色授权访问 Secrets + +#### SendGrid API Key Rotation + +- **问题**：多个团队各自管理 SendGrid API Key，轮换需要代码变更和重启应用 +- **解决方案**：集中式 SMTP 服务统一处理 SendGrid 轮换，应用只连接内部 SMTP 服务器 +- **实现**：SMTP 服务在端口 1025 提供服务，应用无需感知后端 API Key 变更 + +## Rotation Triggers + +| 触发方式 | 说明 | +|---------|------| +| 定时轮换 | 按固定间隔（天数）自动触发 | +| 手动触发 | 通过 AWS CLI 或 Console 手动启动 | +| API 调用 | 通过 `rotateSecret` API 编程触发 | +| 事件驱动 | CloudWatch Events 触发 Lambda | + +## Best Practices + +1. **先集中，后轮换**：先完成 Secrets 集中化管理，再启用轮换 +2. **测试回滚**：轮换失败时的回滚机制测试 +3. **应用兼容性**：确保应用支持动态获取新凭据（使用 JDBC Wrapper、SDK 等） +4. **监控告警**：轮换失败时的告警通知机制 +5. **分阶段实施**：先低风险系统试点，再推广至生产环境 + +## Related Concepts + +- [[SecretsManagement]]：敏感信息管理的整体框架 +- [[JDBCWrapper]]：数据库应用获取动态凭据的方式 +- [[Lambda]]：用于执行轮换逻辑的无服务器函数 +- [[ControlTower]]：企业级 Secrets 管理的治理框架 + +## Sources + +- [[CTP-Topic-62-AWS-Secrets-Manager]] — Oracle 数据库和 SendGrid API Key 轮换实施案例 + +## Aliases + +- Key Rotation +- Credential Rotation +- Password Rotation +- API Key Rotation diff --git a/wiki/concepts/SecretsManagement.md b/wiki/concepts/SecretsManagement.md new file mode 100644 index 00000000..58aaad0d --- /dev/null +++ b/wiki/concepts/SecretsManagement.md @@ -0,0 +1,63 @@ +--- +title: "SecretsManagement" +type: concept +tags: + - AWS + - Security + - Cloud + - DevOps +--- + +## Definition + +Secrets Management（敏感信息管理）是指在云环境中集中存储、管理、安全轮换敏感凭据（密码、API Key、证书、加密密钥等）的实践，旨在消除硬编码明文密码和密钥的安全风险。 + +## Core Principles + +1. **集中化存储**：所有 Secrets 存储在集中式保险库（Vault）中，而非代码、配置文件或环境变量 +2. **最小权限访问**：通过 IAM 角色和策略控制谁可以访问哪些 Secrets +3. **自动轮换**：定期自动更换 Secrets，减少长期密钥泄露风险 +4. **审计追踪**：记录所有 Secrets 访问和变更操作 +5. **加密传输**：Secrets 在传输和存储时均加密保护 + +## AWS Secrets Manager Implementation + +### Three-Phase Approach + +1. **集中 Secrets**：将所有密码、密钥集中到 AWS Secrets Manager +2. **调整自动化**：修改 CI/CD 和应用程序，从 Secrets Manager 动态获取凭据 +3. **启动轮换**：启用自动轮换机制，定期更换凭据 + +### Key Benefits + +- 开发者无需直接访问 Secrets，通过角色和 AWS 凭证授权 +- 无需客户端软件（对比 HashiCorp Vault） +- 与 AWS Control Tower 集成实现企业级标准化 +- 成本比自托管 Vault 方案更低 + +## AWS Alternatives + +| Feature | AWS Secrets Manager | HashiCorp Vault | +|---------|-------------------|-----------------| +| 客户端依赖 | 无 | 需要 | +| 托管服务 | 完全托管 | 自托管/托管 | +| 成本 | 按 API 调用计费 | 基础设施+运维成本 | +| Lambda 集成 | 原生支持 | 需要额外配置 | + +## Related Concepts + +- [[SecretRotation]]：定期自动更换 Secrets 的机制 +- [[JDBCWrapper]]：通过包装器动态获取数据库凭据 +- [[IAM-Roles]]：基于角色的访问控制 +- [[ControlTower]]：AWS 多账户治理 + +## Sources + +- [[CTP-Topic-62-AWS-Secrets-Manager]] — AWS Secrets Manager 企业实施经验 +- [[CTP-Topic-37-Secrets-Certificates-Management]] — Secrets 和证书管理最佳实践 + +## Aliases + +- Secret Management +- Credentials Management +- API Key Management diff --git a/wiki/concepts/Security-Group-Policy.md b/wiki/concepts/Security-Group-Policy.md new file mode 100644 index 00000000..bcfefb82 --- /dev/null +++ b/wiki/concepts/Security-Group-Policy.md @@ -0,0 +1,68 @@ +--- +title: "Security Group Policy" +type: concept +tags: + - AWS + - Security + - Security-Group + - Firewall-Manager + - Compliance +sources: + - ctp-topic-55-aws-firewall-manager +last_updated: 2026-04-14 +--- + +## Definition + +Security Group Policy 是 AWS Firewall Manager 中的安全组策略类型，用于在组织级别对安全组进行集中化管理和合规性控制。Policy 定义在 Firewall Manager 管理员账户中，通过 AWS Config + Lambda 机制自动分发和强制执行到目标账户的 EC2 实例。 + +## Policy Types + +### 1. Common Security Group Policy（通用安全组策略） +- **作用**：将基线安全组附加到所有目标账户的 EC2 实例 +- **特点**：允许产品团队在基线之上继续添加自定义安全组规则 +- **适用场景**：需要统一安全基线但保留团队灵活性的场景 + +### 2. Audit & Enforcement Security Group Policy（审计与强制执行策略） +- **作用**：检测并拒绝过度宽松（over-permissive）的安全组规则 +- **两种修复模式**： + - **手动修复（Manual Remediation）**：仅告警，由管理员手动处理 + - **自动修复（Auto Remediation）**：通过 Lambda 自动纠正不合规规则 +- **适用场景**：强制最小权限原则，防止安全组配置错误导致风险暴露 + +### 3. Cleanup Security Group Policy（清理策略） +- **作用**：自动识别并清理未使用的冗余安全组 +- **适用场景**：减少安全组管理复杂度，避免过期规则堆积 + +## Policy Lifecycle +``` +Policy Created in Firewall Manager Admin Account + ↓ +Target Account / OU Association + ↓ +AWS Config Compliance Check + ├── Compliant → No Action + └── Non-Compliant → Lambda Triggered + ↓ +Auto-Remediation (if enabled) + ↓ +New EC2 Instance → Auto-attach Security Group +Policy Deleted → Auto-detach Security Group from all instances +``` + +## Prerequisites +- Firewall Manager 管理员账户已配置 +- 目标账户必须启用 AWS Config +- 目标账户所在 OU 必须授予 Firewall Manager 管理员相应权限 + +## Relationship with Other Concepts +- **[[AWS Firewall Manager]]**：Security Group Policy 的上层管理平台 +- **[[AWS Config]]**：提供合规性评估数据 +- **[[AWS Lambda]]**：执行自动化修复逻辑 +- **[[Prefix List]]**：定义允许的 IP CIDR 范围，供安全组规则引用 +- **[[AWS RAM]]**：跨账户共享 Prefix List + +## Design Patterns +- **分层叠加模式**：Common SG（基线）+ 产品团队自定义 SG（叠加）= 完整安全策略 +- **黑名单模式**：Audit & Enforcement Policy 拒绝特定危险规则（如 0.0.0.0/0 全开放） +- **白名单模式**：只允许明确声明的 CIDR 范围访问 diff --git a/wiki/concepts/Shared-Account.md b/wiki/concepts/Shared-Account.md new file mode 100644 index 00000000..5dec70ff --- /dev/null +++ b/wiki/concepts/Shared-Account.md @@ -0,0 +1,55 @@ +--- +title: "Shared Account" +type: concept +tags: [AWS, Multi-Account, Landing-Zone, Architecture, IAM] +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +Shared Account（共享账号）是 AWS Landing Zone 多账号架构中的核心管理账号，托管 CI/CD 平台（[[Jenkins]]）、镜像仓库等公共服务，并作为跨账号部署的**信任源**（Trust Source）。 + +## Role in Multi-Account Architecture + +在 AWS Landing Zone 中，Shared Account 是 Workload 账号之间的**唯一信任中间人**： + +``` +Workload Account A → 不直接访问 → Workload Account B + ↑ ↓ + └── ← Shared Account (Assume Role) ────┘ +``` + +这种架构通过[[Blast-Radius]]控制实现了： +- Workload 账号之间无直接信任关系 +- 所有跨账号操作通过 Shared Account 中转 +- 安全策略集中管控和审计 + +## Responsibilities + +| 职责 | 说明 | +|------|------| +| CI/CD 托管 | Jenkins、构建代理 | +| 镜像仓库 | ECR 中的容器镜像 | +| 跨账号部署 | [[ECS-Deploy-Runner]] 运行在此账号，通过 Assume Role 访问目标账号 | +| 公共服务 | DNS（NTP 等）供给 | + +## Security Principles + +1. **最小权限**：仅持有部署所需的两个专用角色（State Accessor + Deploy Runner Role） +2. **审计追踪**：所有操作集中记录 +3. **隔离保护**：Shared Account 本身受到严格的安全控制和定期审计 + +## Relationships + +- [[AWS-Landing-Zone]]：Shared Account 是 Landing Zone 架构的支柱 +- [[ECS-Deploy-Runner]]：运行在 Shared Account 的 ECS 集群 +- [[Jenkins]]：托管在 Shared Account +- [[Blast-Radius]]：Shared Account 架构是 Blast Radius 控制的核心机制 +- [[Assume-Role]]：Shared Account 通过 Assume Role 访问 Workload 账号 + +## Related Concepts + +- [[Cross-account-Terraform-Modules]]：Shared Account 支撑的核心功能 +- [[Infrastructure-as-Code]]：Shared Account 中的 Jenkins 驱动 IaC 部署 diff --git a/wiki/concepts/TF-State-Bucket-Accessor.md b/wiki/concepts/TF-State-Bucket-Accessor.md new file mode 100644 index 00000000..6ab63043 --- /dev/null +++ b/wiki/concepts/TF-State-Bucket-Accessor.md @@ -0,0 +1,70 @@ +--- +title: "TF State Bucket Accessor" +type: concept +tags: [Terraform, IAM, S3, State-Management, AWS, Security] +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +TF State Bucket Accessor 是跨账号 Terraform 部署方案中的两个核心 IAM 角色之一，专门用于在目标 AWS 账号中读取和写入 Terraform 状态文件（S3 存储）。 + +## Purpose + +Terraform 状态文件记录了基础设施的当前期望状态。在跨账号场景中： + +- **状态文件存储位置**：每个 Workload 账号拥有独立的 S3 存储桶 +- **访问挑战**：Shared Account 的 [[ECS-Deploy-Runner]] 需要读写这些状态文件 +- **安全约束**：不能直接赋予 Shared Account 对所有 S3 桶的完全访问权限 +- **解决方案**：在每个目标账号中创建专门的 IAM 角色，仅允许部署工具 Assume + +## Security Design + +遵循最小权限原则（Principle of Least Privilege）： + +```json +{ + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::role/ecs-deploy-runner-execution-role" + }, + "Action": [ + "s3:GetObject", + "s3:PutObject", + "s3:ListBucket" + ], + "Resource": [ + "arn:aws:s3:::-terraform-state", + "arn:aws:s3:::-terraform-state/*" + ] +} +``` + +## Relationship with Terraform State + +- [[TerraformState]]：状态文件管理是 IaC 的核心问题 +- [[Blast-Radius]]：专用角色限制了凭证泄露时的影响范围 +- [[Assume-Role]]：EDR 通过 Assume Role 获取该角色的临时凭证 + +## Dual Role Pattern + +跨账号 Terraform 部署使用**双角色模式**，将状态访问和资源部署分离： + +| 角色 | 职责 | 托管位置 | +|------|------|---------| +| **TF State Bucket Accessor** | 读取/写入 Terraform 状态文件 | 目标账号 | +| [[Cross-account-ECS-Deploy-Runner-Role]] | 执行资源部署（plan/apply） | 目标账号 | + +## Relationships + +- [[TerraformState]] ← protected_by ← [[TF-State-Bucket-Accessor]] +- [[ECS-Deploy-Runner]] ← uses ← [[TF-State-Bucket-Accessor]] +- [[Assume-Role]] ← mechanism ← [[TF-State-Bucket-Accessor]] +- [[Blast-Radius]] ← controls ← [[TF-State-Bucket-Accessor]] + +## Related Entities + +- [[ECS-Deploy-Runner]]：使用该角色的执行器 +- [[Cross-account-ECS-Deploy-Runner-Role]]：双角色模式中的另一个角色 diff --git a/wiki/concepts/Tagging.md b/wiki/concepts/Tagging.md new file mode 100644 index 00000000..283556d4 --- /dev/null +++ b/wiki/concepts/Tagging.md @@ -0,0 +1,55 @@ +--- +title: "Tagging" +type: concept +tags: + - AWS + - Resource-Management + - Governance + - Cost-Optimization +sources: + - ctp-topic-27-aws-instance-scheduler + - ctp-topic-28-aws-tag-validation-tool +last_updated: 2026-05-12 +--- + +## Tagging + +AWS 资源标签化（Tagging）是通过在 AWS 资源上附加键值对元数据来实现资源分组、归类和自动化策略关联的管理机制。 + +## Role in AWS Instance Scheduler + +Instance Scheduler 通过实例上的特定标签来关联调度逻辑： + +| 标签键 | 说明 | 示例值 | +|--------|------|--------| +| `Schedule` | 关联调度名称 | `Seattle-9-5` | +| `Period` | 关联周期名称 | `Weekdays-Business-Hours` | +| `Override` | 覆盖状态 | `true`（强制停止）/ `false`（正常调度） | + +## Key Tags for Instance Scheduler + +- **`Schedule`**：将实例关联到 DynamoDB Config Table 中的调度定义 +- **`Period`**：将实例关联到具体的周期（开始/结束时间、工作日） +- **`InstanceType`**：标识实例类型（EC2/RDS），影响调度行为差异 + +## AWS Tagging Best Practices + +- **一致性命名**：使用标准化前缀（如 `Environment:`、`Team:`、`CostCenter:`） +- **必填标签**：Enforce Tag 策略要求所有资源必须附有特定标签 +- **自动化标签**：通过 AWS Config Rules 或 Lambda 自动补全缺失标签 +- **标签验证**：使用 Tag Editor 或第三方工具（如 ctp-topic-28-aws-tag-validation-tool）确保标签合规 + +## Relationship to Governance + +Tagging 是 AWS 云治理的基石，支持： + +- **成本归因**：按团队/项目/环境追踪云支出 +- **访问控制**：基于标签的 IAM 策略 +- **自动化操作**：Instance Scheduler、自动化备份等均依赖标签 +- **资源分组**：跨服务和账户的资源发现与分组 + +## Related Pages +- [[AWS-Instance-Scheduler]] — 核心使用场景 +- [[ctp-topic-27-aws-instance-scheduler]] — 原始来源 +- [[ctp-topic-28-aws-tag-validation-tool]] — 标签验证工具 +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] — FinOps 标签策略 diff --git a/wiki/concepts/TerraformState.md b/wiki/concepts/TerraformState.md new file mode 100644 index 00000000..a8f42597 --- /dev/null +++ b/wiki/concepts/TerraformState.md @@ -0,0 +1,30 @@ +--- +title: "Terraform State" +type: concept +tags: + - Terraform + - IaC + - State Management +sources: + - ctp-topic-48-terraform-vs-terragrunt.md +last_updated: 2026-05-13 +--- + +## Definition +Terraform State 是 Terraform 内部维护的 JSON 文件，记录了真实世界基础设施资源与 HCL 代码定义之间的映射关系，是 Terraform 将期望状态与实际运行环境绑定的核心机制。 + +## Core Mechanism +- **状态锁定（State Locking）**：防止并发执行导致状态冲突 +- **状态后端（State Backend）**：本地存储适用于个人开发，企业级使用需配置远程后端（S3 + DynamoDB、Terraform Cloud、Consul 等） +- **状态漂移检测（Drift Detection）**：对比状态文件与实际资源，发现非 Terraform 管理的变更 + +## State Management Best Practices +- **永远不要手动修改状态文件**——使用 `terraform import` 导入已有资源 +- **使用远程后端**：本地状态在团队协作下会导致状态文件冲突和丢失 +- **启用状态加密**：敏感信息（密码、密钥）可能存在于状态中 +- **版本化存储**：使用支持版本控制的远程后端（如 S3 + DynamoDB） + +## Connections +- [[Terraform]] ← uses ← [[TerraformState]] +- [[Terragrunt]] ← abstracts_away ← [[TerraformState]]（通过模板化管理 remote state 块） +- [[TerraformEnterprise]] ← provides_managed ← [[TerraformState]]（远程工作区状态管理） diff --git a/wiki/concepts/cross-account-json.md b/wiki/concepts/cross-account-json.md new file mode 100644 index 00000000..95884e47 --- /dev/null +++ b/wiki/concepts/cross-account-json.md @@ -0,0 +1,59 @@ +--- +title: "cross-account.json" +type: concept +tags: [Terraform, CI/CD, Jenkins, Deployment, IaC] +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +`cross-account.json` 是部署在 Terraform 模块目录中的一个约定俗成的**标记文件**（Marker File），用于告知 Jenkins CI/CD 流水线该模块需要调用跨账号部署逻辑。 + +## Purpose + +在复杂的 AWS Landing Zone 环境中，并非所有 Terraform 模块都需要跨账号部署： + +- **普通模块**：仅在单一账号内运行，使用标准 Jenkins → EDR 流水线 +- **跨账号模块**：需要在多个账号中同时创建资源（如 DNS 配置 + 应用部署） + +`cross-account.json` 作为信号标记，区分这两类模块。 + +## How It Works + +``` +module-directory/ +├── main.tf +├── variables.tf +├── outputs.tf +└── cross-account.json ← 标记文件（Jenkins 检测此文件） +``` + +1. **Jenkins 扫描**：Jenkins 在检测模块时，检查目录中是否存在 `cross-account.json` +2. **识别类型**：存在 → 触发跨账号部署流程；不存在 → 标准单账号流程 +3. **调用 EDR**：触发 [[ECS-Deploy-Runner]] 执行跨账号 Terraform 操作 + +## Content Example + +`cross-account.json` 通常可以为空文件（文件名本身即标记），或包含简单配置： + +```json +{ + "description": "This module deploys resources across multiple accounts", + "target_accounts": ["InfoBlocks", "Workload"], + "execution_order": ["InfoBlocks", "Workload"] +} +``` + +## Relationships + +- [[Jenkins]] ← detects ← [[cross-account.json]] +- [[ECS-Deploy-Runner]] ← triggered_by ← [[cross-account.json]] +- [[Cross-account-Terraform-Modules]] ← signaled_by ← [[cross-account.json]] + +## Related Concepts + +- [[CI/CD Pipeline]]：Jenkins 是 CI/CD 流水线的大脑，通过此标记决定执行路径 +- [[Cross-account-Terraform-Modules]]：该标记是跨账号 Terraform 模块的识别机制 +- [[Marker-Pattern]]：约定优于配置（Convention over Configuration）的典型应用 diff --git a/wiki/entities/AWS-EventBridge.md b/wiki/entities/AWS-EventBridge.md new file mode 100644 index 00000000..66420356 --- /dev/null +++ b/wiki/entities/AWS-EventBridge.md @@ -0,0 +1,48 @@ +--- +title: "AWS EventBridge" +type: entity +tags: + - AWS + - Event Broker + - EDA +last_updated: 2026-04-14 +--- + +## Aliases +- Amazon EventBridge +- EventBridge + +## Role in EDA +AWS 事件代理服务，属于 **Event Router**（事件路由器）类型，比 SNS 功能更丰富，支持基于规则的过滤和路由。 + +## Key Features +- **Rule-Based Routing**：基于规则将事件从源产品路由到目标 AWS 服务或 SaaS 应用 +- **Event Bus**：默认事件总线（Default Event Bus）和自定义事件总线（Custom Event Bus） +- **Schema Registry**：事件模式注册表，自动发现和验证事件结构 +- **API Destinations**：将事件转发到外部 HTTP 端点 +- **Third-Party Integration**：原生集成 100+ AWS 服务和 SaaS 应用（如 Datadog、Shopify、PagerDuty） + +## Best Practices +- **每个订阅者使用单一规则**（Single Rule per Subscriber） +- **避免为自定义事件使用默认事件总线**，创建专用自定义事件总线 +- **使用死信队列（DLQ）** 处理无法路由的事件 +- 避免在规则中使用过于宽泛的事件模式导致误匹配 + +## Comparison with SNS +| 特性 | EventBridge | SNS | +|------|------------|-----| +| 过滤能力 | 基于 JSON Schema 的精细过滤 | 消息属性过滤 | +| 第三方集成 | 原生支持 100+ SaaS 应用 | 需额外配置 | +| Schema Registry | 有 | 无 | +| API Destinations | 有 | 无 | +| 定价 | 按事件数量 | 按消息数量 | +| 适用场景 | 复杂路由、多服务协调 | 简单发布/订阅 | + +## Related Services +- [[AWS-SQS]]：事件存储，队列模式 +- [[AWS-SNS]]：事件路由器，简单发布/订阅 +- [[AWS-Kinesis]]：流数据平台 + +## Sources +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]] diff --git a/wiki/entities/AWS.md b/wiki/entities/AWS.md index 01a71c50..31f1dd99 100644 --- a/wiki/entities/AWS.md +++ b/wiki/entities/AWS.md @@ -1,39 +1,31 @@ --- -title: "Amazon Web Services (AWS)" +title: "AWS" type: entity tags: - - AWS - Cloud - - Hybrid-Cloud -sources: [cloud-operating-model-key-strategies-and-best-practices, public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2] -last_updated: 2026-04-29 + - ECS + - IaC +sources: + - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi +last_updated: 2023-08-08 --- -## Amazon Web Services (AWS) +## Profile +Amazon Web Services（AWS），亚马逊旗下云计算平台，提供覆盖计算、存储、容器、数据库等领域的 200+ 云服务。 -Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. +## Core Services Referenced +- **ECS（Elastic Container Service）**：AWS 原生容器编排服务，支持 EC2 和 Fargate 两种运行模式 +- **EKS（Elastic Kubernetes Service）**：托管 Kubernetes 服务，强调可移植性 +- **VPC**：虚拟私有云 +- **ELB**：弹性负载均衡 +- **EFS**：弹性文件系统 +- **CloudWatch**：云监控 +- **Prometheus/Grafana**：可集成的监控栈 -## Aliases -- AWS -- Amazon Web Services - -## Key Partnerships -- **VMware Cloud on AWS (VMC on AWS)**: AWS partnered with VMware to run VMware workloads natively on AWS infrastructure. The underlying hardware consists of i3.metal and i3en.metal bare metal servers, organized into clusters within availability zones and regions. - -## Infrastructure for VMC on AWS -- **i3.metal**: Bare metal server instance used for VMware Cloud on AWS SDDC deployment -- **i3en.metal**: Enhanced bare metal instance with larger storage capacity -- **Clusters**: Organized within availability zones and regions globally -- **Stretched Clusters**: Available across availability zones for increased resilience +## IaC Context +AWS 云基础设施通过 Terraform IaC 进行管理，ECS 是 AWS 原生容器技术，与 AWS 服务深度集成。 ## Connections -- [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]] -- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]] -- [[VMware]] ← partners ← [[AWS]] -- [[AWS-Transit-Gateway-TGW]] ← 服务 ← [[AWS]] -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 平台 ← [[AWS]] - -## Sources -- [[ctp-topic-43-vmware-cloud-on-aws]] -- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] +- [[ECS]]：AWS 弹性容器服务 +- [[EKS]]：AWS 托管 Kubernetes（ECS 的替代方案） +- [[Cloud-Transformation-Programme]]：AWS 作为 CTP 的云服务提供商 diff --git a/wiki/entities/Amazon-Bedrock.md b/wiki/entities/Amazon-Bedrock.md index 8ad08817..e320eeba 100644 --- a/wiki/entities/Amazon-Bedrock.md +++ b/wiki/entities/Amazon-Bedrock.md @@ -1,8 +1,8 @@ --- title: "Amazon Bedrock" tags: [aws, cloud, ai, bedrock, api] -sources: [如何利用sora接口实现视频自动化生成工作流] -last_updated: 2026-04-27 +sources: [如何利用sora接口实现视频自动化生成工作流, public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111, public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin, public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec] +last_updated: 2026-05-12 --- ## Aliases @@ -68,6 +68,7 @@ Amazon Bedrock 保证： - [[如何利用Sora接口实现视频自动化生成工作流]] — Sora + Bedrock 完整教程 - [[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]] — AWS AI 三层架构 +- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] — AWS AI/ML 入门：Bedrock 全托管生成式 AI 服务详解 ## Connections diff --git a/wiki/entities/Amazon-Q.md b/wiki/entities/Amazon-Q.md new file mode 100644 index 00000000..aa9ffee2 --- /dev/null +++ b/wiki/entities/Amazon-Q.md @@ -0,0 +1,42 @@ +--- +title: "Amazon Q" +type: entity +tags: [aws, ai, assistant, generative-ai] +sources: [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111, public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec] +last_updated: 2026-05-12 +--- + +## Aliases +- AWS Amazon Q +- Amazon Q Business +- Amazon Q Developer + +## Summary + +**Amazon Q** 是 AWS 推出的 AI 驱动助手，提供面向业务和开发者两大版本：Amazon Q for Business 连接多数据源进行搜索、总结与洞察提取；Amazon Q Developer 专注代码生成、单元测试和代码迁移。 + +## Key Properties + +- **类型**：AWS AI 助手 / 产品 +- **开发商**：Amazon Web Services (AWS) +- **版本**：Business 版 / Developer 版 + +## Key Capabilities + +### Amazon Q for Business +- 连接多个企业数据源（文档、知识库、企业系统） +- 自然语言搜索与问答 +- 文档总结与洞察提取 +- 继承现有权限体系，保障数据访问安全 + +### Amazon Q Developer +- 代码生成（基于自然语言描述生成代码） +- 单元测试自动生成 +- 代码迁移（跨语言/跨框架） +- 构建于 [[AmazonBedrock]] 之上 + +## Connections + +- 底层服务：[[AmazonBedrock]] +- 同类服务：[[AmazonSageMaker]]（ML 全生命周期管理） +- 关联公司：[[OpenText]]（举办 AWS 学习会议分享 Amazon Q 实践） diff --git a/wiki/entities/Amazon-SageMaker.md b/wiki/entities/Amazon-SageMaker.md new file mode 100644 index 00000000..ab642f78 --- /dev/null +++ b/wiki/entities/Amazon-SageMaker.md @@ -0,0 +1,41 @@ +--- +title: "Amazon SageMaker" +type: entity +tags: [AWS, ML, AI, machine-learning, platform] +sources: + - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin + - public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec +last_updated: 2026-05-12 +--- + +## Aliases +- AWS SageMaker +- SageMaker +- 亚马逊 SageMaker + +## Overview +Amazon SageMaker 是 AWS 提供的全面托管机器学习平台，帮助开发者快速构建、训练和部署机器学习模型，是 ML Ops 训练管道和推理管道的核心工具。 + +## Key Capabilities + +### Training Pipeline +- 特征工程（Feature Engineering） +- 模型训练（Model Training） +- 超参数调优（Hyperparameter Tuning） + +### Inference Pipeline +- 实时端点部署（Real-time Endpoints） +- 模型监控（Model Monitoring） + +## Role in MLOps +SageMaker 在 ML Ops 三管道中扮演核心角色： +1. **数据管道**：使用 SageMaker Data Wrangler 进行数据准备 +2. **训练管道**：使用 SageMaker Training 进行模型训练和超参数调优 +3. **推理管道**：使用 SageMaker Endpoints 部署和管理推理端点 + +## Related +- [[MLOps]] +- [[Amazon-Bedrock]] +- [[Foundation-Models]] +- [[AWS]] +- AWS AI 三层产品战略：SageMaker 属于基础设施层（ML 平台工程师用），Bedrock 属于中间层（应用开发者用） diff --git a/wiki/entities/Amazon-Titan.md b/wiki/entities/Amazon-Titan.md new file mode 100644 index 00000000..4673f5bc --- /dev/null +++ b/wiki/entities/Amazon-Titan.md @@ -0,0 +1,32 @@ +--- +title: "Amazon Titan" +type: entity +tags: [AWS, AI, foundation-model, generative-AI] +sources: + - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin +last_updated: 2026-05-12 +--- + +## Aliases +- AWS Titan +- Amazon Titan +- Titan +- Titan Models + +## Overview +Amazon Titan 是 Amazon 基础模型系列（Amazon Titan Family），是 AWS 官方开发的基础模型，可在 Amazon Bedrock 上使用，提供强大的生成式 AI 能力，具有竞争力的定价和卓越性能。 + +## Key Properties +- **开发商**: Amazon Web Services (AWS) +- **平台**: Amazon Bedrock +- **类型**: Foundation Model（基础模型） +- **核心能力**: 文本生成、内容创作、对话式 AI + +## Positioning +Amazon Titan 是 Amazon Bedrock 提供的多种基础模型之一，补充了第三方基础模型（如 Anthropic Claude 等），为客户提供了 AWS 原生的生成式 AI 选择。 + +## Related +- [[Foundation-Models]] +- [[Amazon-Bedrock]] +- [[Generative-AI]] +- [[AWS]] diff --git a/wiki/entities/Anil-Giri.md b/wiki/entities/Anil-Giri.md new file mode 100644 index 00000000..56d7d7ae --- /dev/null +++ b/wiki/entities/Anil-Giri.md @@ -0,0 +1,31 @@ +--- +title: "Anil Giri" +type: entity +tags: + - Speaker + - AWS + - Solutions Architect +last_updated: 2026-04-14 +--- + +## Aliases +- Dr. Anil Giri +- Anil Giri + +## Role +AWS 解决方案架构师（Solutions Architect），在 Public Cloud Learning Sessions 系列中主讲事件驱动架构（EDA）主题。 + +## Sessions Delivered +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（Part 1：EDA 入门与概述） +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]（Part 2：EDA 进阶最佳实践） + +## Topics Covered +- 事件驱动架构（Event-Driven Architecture） +- 事件代理（Event Broker）：EventBridge / SNS / SQS / Kinesis +- 微服务通信模式：Choreography vs Orchestration +- AWS Step Functions 状态机编排 +- 团队独立性和去中心化所有权 + +## Sources +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]] +- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] diff --git a/wiki/entities/Anthropic.md b/wiki/entities/Anthropic.md index 51669516..725552fb 100644 --- a/wiki/entities/Anthropic.md +++ b/wiki/entities/Anthropic.md @@ -1,34 +1,34 @@ --- title: "Anthropic" type: entity -tags: ["llm-provider", "anthropic"] -sources: ["engineering-autonomous-optimization-architect"] -last_updated: 2026-04-26 +tags: [ai, llm, foundation-model, aws, claude] +sources: [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111, public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin] +last_updated: 2026-05-12 --- ## Aliases -- Anthropic -- Anthropic PBC +- Anthropic AI +- Claude (model family) -## Definition -Anthropic 是主要的 LLM Provider，提供 Claude 系列模型（Claude Opus、Claude Sonnet、Claude Haiku 等）。在 [[AutonomousOptimizationArchitect]] 系统中作为高精度基准模型，其输出常被用作 [[LLMasJudge]] 评估其他模型时的参照标准。 +## Summary -## Role in LLM Routing -- Claude Opus 常作为高精度基准——如果其他模型要替代 Claude，必须达到其 98%+ 精度 -- Claude Sonnet/Haiku 提供性价比选项，供 [[AutonomousOptimizationArchitect]] 按任务难度分配 -- Anthropic API 不可用时触发 [[CircuitBreaker]] 切换至 [[OpenAI]] 或 [[GoogleGemini]] +**Anthropic** 是一家专注于 AI 安全与对齐的 AI 研究公司，由前 OpenAI 研究人员创立。其开发的 Claude 系列大语言模型（Claude 3.5 Sonnet/Opus/Haiku 等）通过 [[AmazonBedrock]] 提供 AWS 企业用户访问。 ## Key Properties -- **Token 成本**：$3-15 / 1M tokens -- **延迟**：低至中等 -- **常见用途**：复杂推理、长文本分析、安全敏感任务 -## Claude Skills -- **官方 Skills 仓库**：github.com/anthropic/skills，3.2万+星，将 Claude.ai 生产级能力原封不动拆解公开 -- 涵盖三大类：办公自动化（Word/PDF/PPT/Excel）、开发者工具（MCP Server/Web 测试/Artifacts 构建）、创意类技能 -- 官方 Skills 仓库本质上是 Anthropic 官方教你「怎么像我们一样开发 AI 应用」 +- **类型**：AI 研究公司 / 基础模型提供商 +- **代表模型**：Claude 3.5 Sonnet、Claude 3.5 Opus、Claude 3 Haiku +- **AWS 合作**：Claude 模型通过 Amazon Bedrock 全托管服务提供 + +## Key Facts + +- 成立于 2021 年，总部位于美国旧金山 +- 专注于 AI 安全和有益的 AGI +- Claude 模型以安全性、长上下文和高能力著称 +- Bedrock 上的 Claude 模型：用户数据不与 Anthropic 共享（Bedrock 数据隐私保证） ## Connections -- [[OpenAI]] — 同为 LLM Provider，共同参与 [[SemanticRouting]] -- [[GoogleGemini]] — 在成本优化场景中与 Gemini Flash 形成对比 -- [[Claude Skills]] — Anthropic 发布的官方 Skills 仓库是其核心产品资源 + +- 合作平台：[[AmazonBedrock]] +- 关联产品：[[AmazonQ]]（Q Developer 基于 Bedrock/Calude 能力） +- 相关人物：[[Shikad-Holtzman]]（分享 Bedrock+Claude 应用实践） diff --git a/wiki/entities/Atlantis.md b/wiki/entities/Atlantis.md index ad6e9c27..c0abfece 100644 --- a/wiki/entities/Atlantis.md +++ b/wiki/entities/Atlantis.md @@ -1,95 +1,36 @@ ---- -title: "Atlantis" -type: entity -tags: - - devops - - iac - - terraform - - gitops - - cicd -created: 2026-04-26 ---- - -# Atlantis - -## Definition - -Atlantis 是一个开源的**Terraform CI/CD 工具**，通过与 GitHub/GitLab 深度集成，将 Terraform 的 plan 和 apply 操作转移到 Pull Request（PR）评论层面，实现基础设施即代码的协作式自动化部署。 - -## Core Model: PR-Driven IaC - -Atlantis 的核心理念：**每个 Pull Request 都是一次 Terraform 操作**。 - -``` -Developer Atlantis AWS Accounts - │ │ │ - │ 1. Open PR │ │ - │───────────────────────>│ │ - │ │ 2. !atlantis plan │ - │ │───────────────────────>│ - │ │<───────────────────────│ 3. terraform plan - │ 4. Post plan result │ │ - │<───────────────────────│ │ - │ 5. Review & Approve │ │ - │───────────────────────>│ │ - │ │ 6. !atlantis apply │ - │ │───────────────────────>│ - │ │<───────────────────────│ 7. terraform apply - │ 8. Merge PR │ │ - │───────────────────────>│ │ -``` - -**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] - -## Key Features - -| 特性 | 说明 | -|------|------| -| **PR 评论触发** | 无需独立 CI 账号，开发者在 PR 上评论即可 | -| **并行 plan/apply** | 多模块并发执行，提升部署效率 | -| **锁定机制** | 防止多 PR 同时操作同一模块产生冲突 | -| **跨账户访问** | 通过 IAM 角色实现多 AWS 账户部署 | -| **零额外基础设施** | 只需一台 EC2 共享账户实例 | - -**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] - -## Comparison: Atlantis vs Jenkins - -| 维度 | Atlantis | Jenkins | -|------|----------|---------| -| 触发方式 | PR 评论 | SCM 轮询/定时 | -| 初始化速度 | 快速（按需） | 慢（Jenkins 预配置） | -| 代码克隆 | 单次 | 多次 | -| 测试执行 | 并行 | 顺序 | -| 架构复杂度 | 简单 | 复杂（持续叠加功能） | -| Terraform 专用 | ✅ 是 | ❌ 通用（需配置） | -| PR 协作 | ✅ 原生 | ❌ 无 | - -**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] - -## Micro Focus Usage - -Micro Focus 在 Labs Landing Zone 中使用 Atlantis 替代 Jenkins 进行 Terraform IaC 部署： -- 每个 Landing Zone 共享账户部署单台 EC2 实例 -- GitHub Enterprise Webhook 接收 PR 事件 -- 服务账号负责评论/合并/关闭 PR -- Atlantis 在 merge 前即应用变更 - -**局限性**: Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。 - -**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]], [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] - -## Related Entities - -- [[Terraform]] — Atlantis 操作的核心 IaC 工具 -- [[Gruntwork]] — Terragrunt 的开发者（Atlantis 生态伙伴） - -## Related Concepts - -- [[GitOps]] — Atlantis 是 GitOps 在 Terraform 领域的实现工具 -- [[CI/CD Pipeline]] — Atlantis 提供 CI/CD 能力 - -## Related Sources - -- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] -- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] +--- +title: "Atlantis" +type: entity +entity_type: tool +tags: + - IaC + - DevOps + - Terraform + - GitOps + - CI/CD +sources: + - ctp-topic-48-terraform-vs-terragrunt.md +last_updated: 2026-05-13 +--- + +## Overview +Atlantis 是一个开源的 Pull Request 驱动的 Terraform 自动化工具，将 Terraform 与 GitHub/GitLab 等 Git 平台深度集成，实现基础设施即代码的协作式管理。 + +## Core Mechanism +- **PR 触发**：当 Pull Request 打开或更新时，自动运行 `terraform plan` +- **自动化 apply**：在 PR 合并后，自动执行 `terraform apply` +- **工作流控制**：通过 `atlantis.yaml` 配置文件定义项目和工作流 +- **多云支持**：支持所有 Terraform Provider（AWS、GCP、Azure 等） + +## GitOps Workflow +1. 开发者提交 PR 修改 Terraform 代码 +2. Atlantis 自动检测 PR，运行 `terraform plan` 并将计划结果以评论形式发布到 PR +3. 团队成员审查计划变更 +4. PR 合并后，Atlantis 执行 `terraform apply` +5. Apply 结果同样发布到 PR 评论 + +## Connections +- [[Atlantis]] ← extends ← [[Terraform]] +- [[Atlantis]] ← implements ← [[GitOps]] +- [[Atlantis]] ← integrates_with ← [[GitHub]] +- [[Atlantis]] ← integrates_with ← [[GitLab]] diff --git a/wiki/entities/CCLE.md b/wiki/entities/CCLE.md new file mode 100644 index 00000000..8a037349 --- /dev/null +++ b/wiki/entities/CCLE.md @@ -0,0 +1,41 @@ +--- +title: "CCLE" +type: entity +tags: + - MicroFocus + - Cloud + - Center-of-Excellence + - Security +--- + +## Definition + +CCLE（Cloud Center of Excellence，云卓越中心团队）是 Micro Focus 内部负责推动云标准化、合规与治理的核心职能部门。在云转型计划（CTP）中，CCLE 承担了密钥管理解决方案评估的关键角色。 + +## Role in Cloud Transformation + +### Secrets Management Evaluation + +2022年3月，CCLE 被指定负责探索 Micro Focus 用例并评估潜在的密钥管理解决方案，评估范围涵盖： +- AWS Secrets Manager +- HashiCorp Vault +- CyberArk Micro Focus PAM + +评估结果最终选定 AWS Secrets Manager 作为企业标准方案。 + +## Related Entities + +- [[CCOE]]：Cloud Center of Excellence — CCLE 为其别名/子团队 +- [[MicroFocus]]：CCLE 所属企业主体 +- [[AWS]]：AWS Secrets Manager 提供方 +- [[HashiCorp]]：Vault 产品提供方 +- [[CyberArk]]：PAM 技术提供方 + +## Sources + +- [[ctp-topic-37-secrets-certificates-management]] — CCLE 主导的密钥管理解决方案选型评估 + +## Aliases + +- Cloud Center of Excellence +- CCOE diff --git a/wiki/entities/CTP-SRE-Team.md b/wiki/entities/CTP-SRE-Team.md new file mode 100644 index 00000000..6b4b6ed6 --- /dev/null +++ b/wiki/entities/CTP-SRE-Team.md @@ -0,0 +1,30 @@ +--- +title: "CTP SRE Team" +type: entity +tags: + - CTP + - SRE + - IaC + - ECS +sources: + - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi +last_updated: 2023-08-08 +--- + +## Profile +CTP/SRE 团队，负责 Cloud Transformation Programme 中 ECS Terraform 模块的技术构建与维护。 + +## Responsibilities +- 基于 Gruntwork 仓库构建和扩展 ECS Terraform 模块 +- 实现 Listener 集中管理模式，统一管理 ECS 部署 +- 定义 ECS 部署前置条件和标准化配置 +- 集成 CloudWatch、Splunk、Grafana、Prometheus 监控栈 + +## Key Outputs +- ECS Terraform 模块 +- Listener 集中管理方案 + +## Connections +- [[Raja-M]]：团队核心成员 +- [[ECS-Module]]：核心产出 +- [[Cloud-Transformation-Programme]]：所属项目 diff --git a/wiki/entities/Cross-account-ECS-Deploy-Runner-Role.md b/wiki/entities/Cross-account-ECS-Deploy-Runner-Role.md new file mode 100644 index 00000000..ee1bff4c --- /dev/null +++ b/wiki/entities/Cross-account-ECS-Deploy-Runner-Role.md @@ -0,0 +1,47 @@ +--- +title: "Cross-account ECS Deploy Runner Role" +type: entity +entity_type: product +tags: + - Terraform + - IAM + - ECS + - Deployment + - AWS +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +Cross-account ECS Deploy Runner Role 是部署在目标 AWS 账号中的一种 IAM 角色，允许 Shared Account 的 ECS Deploy Runner 通过 Assume Role 获取在该账号内执行 Terraform 资源部署的权限。 + +## Purpose + +这是跨账号 Terraform 部署的第二个核心角色（与 [[TF-State-Bucket-Accessor]] 并列），专门用于**执行**资源创建/更新操作，而非读取状态文件。 + +## Permission Model + +| 角色 | 用途 | 托管位置 | +|------|------|---------| +| [[TF-State-Bucket-Accessor]] | 读取/写入 Terraform 状态文件 | 目标账号 | +| **Cross-account ECS Deploy Runner Role** | 执行资源部署（plan/apply） | 目标账号 | + +两个角色各司其职，严格遵循最小权限原则。 + +## Relationship with cross-account.json + +`cross-account.json` 是部署在模块目录中的**标记文件**（约定俗成），用于告知 Jenkins 该模块需要跨账号部署，从而触发对 [[ECS-Deploy-Runner]] 的调用，EDR 再通过该角色获取目标账号的部署权限。 + +## Relationships + +- [[ECS-Deploy-Runner]] ← assumes ← [[Cross-account-ECS-Deploy-Runner-Role]] +- [[TF-State-Bucket-Accessor]] ← sibling_role ← [[Cross-account-ECS-Deploy-Runner-Role]] +- [[cross-account.json]] ← triggers ← [[Cross-account-ECS-Deploy-Runner-Role]] + +## Related Concepts + +- [[Assume-Role]]：跨账号身份切换的核心机制 +- [[Blast-Radius]]：最小权限角色设计限制了安全影响范围 +- [[Cross-account-Terraform-Modules]]：该角色是跨账号 Terraform 部署方案的核心组件 diff --git a/wiki/entities/CyberArk.md b/wiki/entities/CyberArk.md new file mode 100644 index 00000000..65ea96fc --- /dev/null +++ b/wiki/entities/CyberArk.md @@ -0,0 +1,53 @@ +--- +title: "CyberArk" +type: entity +tags: + - Security + - PAM + - Privileged-Access + - Cloud +--- + +## Definition + +CyberArk 是全球领先的**特权访问管理（Privileged Access Management, PAM）**安全软件公司，总部位于以色列佩塔提克瓦，在纳斯达克上市（股票代码：CYBR）。CyberArk 专注于保护企业内部的特权账号、密钥和证书，防止凭据窃取和横向移动攻击。 + +## Core Products + +- **CyberArk Privileged Access Manager (PAM)**：核心特权访问管理平台 +- **CyberArk Endpoint Privilege Manager**：端点特权管理 +- **CyberArk Application Access Manager**：应用访问管理 +- **CyberArk Secrets Manager**：应用级密钥管理（对标 AWS Secrets Manager、HashiCorp Vault） + +## CyberArk in Micro Focus Context + +在 Micro Focus 云转型计划（CTP）的密钥管理解决方案评估中，CyberArk Micro Focus PAM 是三款候选产品之一（另外两款为 AWS Secrets Manager 和 HashiCorp Vault）。 + +### Evaluation Outcome + +- **结论**：因需要大量投资才能具备与 AWS Secrets Manager 相当的竞争力，且缺乏明确的投资计划而被放弃 +- **评估机构**：CCLE（Cloud Center of Excellence）团队 +- **评估时间**：2022年3月起 + +### Competitive Gap Analysis + +CyberArk PAM 相比 AWS Secrets Manager 的主要差距： +1. 成本：PAM 方案总体拥有成本（TCO）高于云原生方案 +2. 集成复杂度：需要额外的客户端代理，AWS Secrets Manager 无需客户端 +3. 运维负担：自托管模式带来更高的运维成本 + +## Related Entities + +- [[MicroFocus]]：评估方，CyberArk PAM 的目标客户 +- [[CCLE]]：负责评估的组织团队 +- [[AWS]]：AWS Secrets Manager 提供方，CyberArk 的竞争对手 +- [[HashiCorp]]：HashiCorp Vault 提供方，CyberArk 的竞争对手 + +## Related Concepts + +- [[Privileged-Access-Management]]：特权访问管理 +- [[SecretsManagement]]：敏感信息管理 + +## Sources + +- [[ctp-topic-37-secrets-certificates-management]] — CyberArk Micro Focus PAM 评估记录 diff --git a/wiki/entities/ECS-Deploy-Runner.md b/wiki/entities/ECS-Deploy-Runner.md new file mode 100644 index 00000000..8fd70f8f --- /dev/null +++ b/wiki/entities/ECS-Deploy-Runner.md @@ -0,0 +1,45 @@ +--- +title: "ECS Deploy Runner" +type: entity +entity_type: product +tags: + - Terraform + - ECS + - Deployment + - IaC + - Docker +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +ECS Deploy Runner（EDR）是运行在 ECS 上的 Docker 容器，负责执行 Terraform plan 和 apply 命令，是跨账号部署流水线中的实际执行单元。 + +## Architecture + +- **托管位置**：Shared Account 的 ECS 集群 +- **运行环境**：Docker 容器镜像（预装 Terraform CLI） +- **触发方式**：Jenkins 检测到 `cross-account.json` 标记文件后触发 +- **权限获取**：通过 Assume Role 访问目标账号的 IAM 角色 + +## Key Responsibilities + +1. **读取 Terraform State**：通过 `TF state bucket accessor` 角色读取目标账号 S3 桶中的状态文件 +2. **执行 Plan**：运行 `terraform plan` 生成变更计划 +3. **执行 Apply**：通过 `cross-account ECS deploy runner role` 在目标账号中创建/更新资源 +4. **本地开发差异**：本地开发时 Terragrunt 自动处理角色切换，无需显式 Assume Role + +## Relationships + +- [[Shared-Account]] ← runs_on ← [[ECS-Deploy-Runner]] +- [[ECS-Deploy-Runner]] ← assumes ← [[Cross-account-ECS-Deploy-Runner-Role]] +- [[ECS-Deploy-Runner]] ← reads_state_via ← [[TF-State-Bucket-Accessor]] +- [[Fibos]] ← implemented_by ← [[ECS-Deploy-Runner]] + +## Related Concepts + +- [[CI/CD Pipeline]]：EDR 是 CI/CD 流水线中的执行层 +- [[Cross-account-Terraform-Modules]]：EDR 是该方案的核心执行组件 +- [[Assume-Role]]：EDR 通过 Assume Role 获取跨账号权限 diff --git a/wiki/entities/FPNA-Team.md b/wiki/entities/FPNA-Team.md new file mode 100644 index 00000000..80401da2 --- /dev/null +++ b/wiki/entities/FPNA-Team.md @@ -0,0 +1,32 @@ +--- +title: FPNA Team +type: entity +tags: [Finance, Budget, Cloud-Governance] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] +--- + +# FPNA Team + +**FPNA (Financial Planning & Analysis)** 团队负责 Oli 工作流第三阶段——预算可用性验证。 + +## Role & Responsibilities + +- **预算可用性验证**：作为三阶段审批工作流的最后一步，验证请求是否有可用预算 +- **财务规划支持**：为云转型项目提供财务规划与分析 + +## Workflow Position + +Oli 工作流三阶段审批： +1. **FinOps** → 可行性验证 +2. **Cloud Services** → 技术可行性验证 +3. **FPNA Team** → 预算可用性验证 + +## Related Concepts + +- [[Demand-Management]] — 需求管理流程 +- [[FinOps]] — 云财务运营 +- [[Oli-Workflow]] — 超大规模云厂商支出审批工作流 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/entities/Fibos.md b/wiki/entities/Fibos.md new file mode 100644 index 00000000..d0c38be2 --- /dev/null +++ b/wiki/entities/Fibos.md @@ -0,0 +1,31 @@ +--- +title: "Fibos" +type: entity +entity_type: person +tags: + - Terraform + - AWS + - IaC + - DevOps +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +Fibos 是 Cloud Transformation Programme（CTP）团队的 DevOps/SRE 工程师，主导了基于 Shared Account 的跨账号 Terraform 部署方案设计。 + +## Contributions + +在 [[ctp-topic-16-cross-account-terraform-modules]] 中，Fibos 详细介绍了： + +- **Cross-account Terraform Modules** 的设计动机与安全问题 +- **Shared Account** 中心化部署架构 +- **ECS Deploy Runner** 的 Assume Role 机制 +- **Terragrunt HCL** 全局配置管理跨账号角色切换逻辑 + +## Connections +- [[ECS-Deploy-Runner]] ← implemented_by ← [[Fibos]] +- [[Shared-Account]] ← deployed_in ← [[Fibos]] +- [[Gruntwork]] ← referenced_by ← [[Fibos]] diff --git a/wiki/entities/Godrails.md b/wiki/entities/Godrails.md new file mode 100644 index 00000000..1ebe6427 --- /dev/null +++ b/wiki/entities/Godrails.md @@ -0,0 +1,60 @@ +--- +title: "Godrails" +type: entity +tags: + - Security + - AWS + - Cloud-Governance + - FinOps + - CTP +sources: + - ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co + - ctp-topic-27-aws-instance-scheduler +last_updated: 2026-05-12 +--- + +## Overview + +Godrails（Guardrails 的变体拼写）是预安装在云账户中的安全与治理控制措施，作为云环境初始化流程的一部分提供基础防护，并作为 CCOE 自动化合规框架的核心组成部分。 + +## Details + +- **预安装安全控制**：作为账号初始化流程的一部分自动部署 +- **供应商告警重定向**：告警自动转发至安全团队 +- **CCOE 自动化框架**：CCOE（Cloud Center of Excellence）通过 CloudFormation StackSets 自动推送至公司各 AWS 账号 +- **FinOps 执行机制**：作为 FinOps 治理"政策→执行→监控"闭环中的执行层 + +## Role in FinOps + +Godrails/Guardrails 是 [[FinOps（云财务管理）]] 在 Micro Focus/AWS CTP 中的**执行层机制**： + +1. **策略制定**：PCG FinOps 团队制定成本优化政策 +2. **自动化部署**：CCOE 通过 Godrails/Guardrails 框架将策略自动化推送至各账号 +3. **持续监控**：CloudHealth 提供账单和资源使用洞察 + +## Role in Cost Optimization + +在 CTP Topic 13 中，Godrails 包含以下关键组件： + +- 预安装安全策略 +- 联合身份管理（Federated Identity）与 MFA 强制 +- 告警重定向至安全团队 + +在 CTP Topic 27 中，Godrails/Guardrails **集成了 AWS Instance Scheduler**： + +- CCOE 将 AWS Instance Scheduler 作为 Guardrails 框架的成本控制组件自动推送 +- 自动覆盖公司内月消费 10 美元以上的绝大多数 AWS 账号 +- 用户无需手动配置，即可享受自动启停优化 + +## Aliases +- Godrails +- Guardrails +- AWS Guardrails +- CCOE Guardrails + +## Related Pages +- [[CCOE]] — 负责维护和部署 Godrails/Guardrails 框架的团队 +- [[CloudHealth]] — FinOps 监控工具，与 Godrails 共同构成"执行→监控"闭环 +- [[PCG]] — FinOps 政策制定团队 +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] — Godrails 作为安全控制组件的来源 +- [[ctp-topic-27-aws-instance-scheduler]] — Guardrails 集成 AWS Instance Scheduler 的来源 diff --git a/wiki/entities/Gruntwork.md b/wiki/entities/Gruntwork.md index 69270d02..464c4e00 100644 --- a/wiki/entities/Gruntwork.md +++ b/wiki/entities/Gruntwork.md @@ -1,32 +1,32 @@ --- title: "Gruntwork" type: entity -tags: [AWS, IaC, DevOps, Terraform] -sources: [ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs] -last_updated: 2026-05-05 +tags: + - Terraform + - IaC + - Modules +sources: + - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi + - ctp-topic-9-ci-cd-with-gruntwork + - ctp-topic-16-cross-account-terraform-modules +last_updated: 2023-08-08 --- -# Gruntwork +## Profile +Gruntwork，基础设施即代码（IaC）平台，提供生产级的 Terraform 模块库，帮助团队快速搭建云基础设施。 -## Overview -Gruntwork 是一家专注于 AWS 基础设施即代码（IaC）的公司，提供预构建、可定制的 Terraform 模块库，帮助团队快速构建生产级云基础设施。 +## Aliases +- Gruntwork +- Gruntwork.io -## Products -- **Gruntwork Landing Zone Architecture**：基于 Terraform/Terragrunt 的 AWS Landing Zone 参考架构，涵盖账户结构、网络、安全、运维等基础设施层 -- **Gruntwork Infrastructure Live**：生产级 Terraform 模块库，支持多账户、多区域部署 -- **Pipelines**：Gruntwork 推荐的 CI/CD 流水线方案，集成 GitHub Actions/Jenkins +## Key Products +- **Terraform 模块库**：生产级、可复用的 Terraform 模块，覆盖 VPC、ECS、EKS、RDS 等 AWS 资源 +- **Terragrunt**：轻量级包装器，践行 DRY 原则 -## Key Modules -- **ECS 模块**：Docker 容器部署模块，CTP/SRE 团队在此基础上构建了自己的 ECS 模块（实现 Listener 集中管理） -- **EKS 模块**：Kubernetes 集群部署模块 -- **Landing Zone 模块**：AWS 组织、账户、OU 架构 - -## Gruntwork in CTP Context -- [[ctp-topic-9-ci-cd-with-gruntwork]]：CTP Topic 9 深入 Gruntwork CI/CD 实践 -- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比，Gruntwork 作为辅助工具推荐 -- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：CTP 团队在 Gruntwork 仓库基础上开发 ECS 模块 +## Role in CTP Context +CTP/SRE 团队以 Gruntwork 仓库为基础，构建了 ECS Terraform 模块，实现容器化应用在 AWS 上的标准化部署。 ## Connections -- [[HashiCorp]] ← provider_of ← [[Terraform]] ← uses ← [[Gruntwork]] -- [[Atlantis]] ← alternative_to ← [[Gruntwork-Pipelines]] -- [[Gruntwork]] ← builds_on ← [[Infrastructure-as-Code]] +- [[ECS-Module]] ← based_on ← Gruntwork（CTP 在 Gruntwork 基础上构建） +- [[Terraform]]：核心工具 +- [[Infrastructure-as-Code]]：方法论基础 diff --git a/wiki/entities/Gustavo.md b/wiki/entities/Gustavo.md new file mode 100644 index 00000000..11a68eac --- /dev/null +++ b/wiki/entities/Gustavo.md @@ -0,0 +1,26 @@ +--- +title: "Gustavo" +type: entity +tags: + - AWS + - CTP + - Cloud +sources: + - ctp-topic-27-aws-instance-scheduler +last_updated: 2026-05-12 +--- + +## Gustavo + +Cloud Transformation Programme (CTP) 技术分享讲师，主讲 AWS 成本优化与云财务管理相关主题。 + +## Role + +- **CTP Topic 27** 主讲人：介绍 AWS Instance Scheduler 原生方案的机制、使用场景和运营要点 +- 分享内容涵盖：CloudWatch Events + Lambda + DynamoDB 调度架构、RDS 维护窗口配合、调度标签配置（Schedule / Period） + +## Aliases +- Gustavo（CTP 讲师） + +## Sources +- [[ctp-topic-27-aws-instance-scheduler]] — AWS Instance Scheduler 核心机制与使用场景介绍 diff --git a/wiki/entities/HashiCorp.md b/wiki/entities/HashiCorp.md index c08fe01f..58c54883 100644 --- a/wiki/entities/HashiCorp.md +++ b/wiki/entities/HashiCorp.md @@ -1,60 +1,34 @@ ---- -title: "HashiCorp" -type: entity -tags: - - devops - - iac - - infrastructure - - tools -sources: [cloud-operating-model-key-strategies-and-best-practices] -created: 2026-04-26 ---- - -# HashiCorp - -## Definition - -HashiCorp 是全球领先的**云基础设施自动化**软件公司，总部位于旧金山，创立于 2012 年。HashiCorp 提供一套完整的基础设施生命周期管理工具，覆盖配置管理、机密管理、服务网格和网络自动化等领域。 - -## Core Products - -| 产品 | 用途 | 类别 | -|------|------|------| -| **Terraform** | 云厂商无关的基础设施即代码 | IaC | -| **Vault** | 机密管理与加密即服务 | 安全 | -| **Nomad** | 容器和工作负载调度器 | 编排 | -| **Consul** | 服务网格与服务发现 | 网络 | -| **Packer** | 机器镜像构建自动化 | 镜像 | -| **Vagrant** | 开发环境管理 | 开发环境 | - -## Terraform - -HashiCorp 最知名的产品。Terraform 是用 Golang 编写的云无关 IaC 工具，通过声明式 HCL（HashiCorp Configuration Language）管理跨多云和混合云环境的基础设施资源。 - -**关键特性：** -- 云厂商无关（AWS/Azure/GCP/On-prem） -- `terraform plan` 预览变更 -- 状态文件管理实际资源与期望状态的绑定 -- 丰富的 Provider 生态系统和 Module 市场 - -**来源**: [[ctp-topic-48-terraform-vs-terragrunt]] - -## Business Model - -- **开源**：所有产品的开源版本 -- **Enterprise**：企业级功能（SSO、RBAC、审计日志、Sentinel 策略） -- **HCP（HashiCorp Cloud Platform）**：SaaS 托管版本 - -## Related Entities - -- [[Terraform]] — HashiCorp 出品的核心 IaC 产品 -- [[Terragrunt]] — 第三方 Terraform 封装工具（贯彻 DRY 原则） - -## Related Concepts - -- [[Infrastructure-as-Code]] — HashiCorp 产品的核心方法论 -- [[Multi-Cloud Strategy]] — Terraform 云无关定位的战略价值 - -## Related Sources - -- [[ctp-topic-48-terraform-vs-terragrunt]] +--- +title: "HashiCorp" +type: entity +entity_type: company +tags: + - IaC + - DevOps + - Cloud +sources: + - ctp-topic-48-terraform-vs-terragrunt.md +last_updated: 2026-05-13 +--- + +## Overview +HashiCorp 是全球领先的云基础设施自动化公司，总部位于美国旧金山，成立于 2012 年。由 Mitchell Hashimoto 和 Armon Dadgar 联合创立，2021 年在 NASDAQ 上市（股票代码：HCP），2023 年被 IBM 以约 64 亿美元收购并退市。 + +## Key Products +- **Terraform** — 云无关的基础设施即代码（IaC）工具 +- **Vault** — 密钥管理和 Secrets 管理 +- **Consul** — 服务发现和配置 +- **Nomad** — 容器和应用程序调度器 +- **Packer** — 机器镜像构建工具 +- **Vagrant** — 开发环境管理 + +## Terraform Ecosystem +- **Terraform Open Source** — 核心引擎 +- **Terraform Enterprise** — 企业版（含 CI 平台和 workspaces） +- **Terraform Cloud** — SaaS 版，提供免费和付费计划 +- **Terraform Provider Registry** — 社区驱动的云/服务提供商插件生态 + +## Connections +- [[Terraform]] ← developed_by ← [[HashiCorp]] +- [[TerraformEnterprise]] ← is_enterprise_of ← [[HashiCorp]] +- [[TerraformState]] ← managed_by ← [[Terraform]] ← from ← [[HashiCorp]] diff --git a/wiki/entities/JP.md b/wiki/entities/JP.md new file mode 100644 index 00000000..210bad82 --- /dev/null +++ b/wiki/entities/JP.md @@ -0,0 +1,24 @@ +--- +title: "JP" +type: entity +tags: + - CTP + - ECS + - IaC +sources: + - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi +last_updated: 2023-08-08 +--- + +## Profile +JP，Cloud Transformation Programme 学习课程讲师。 + +## Aliases +- JP + +## Role in Sources +- **ECS Deployment using IaC**（2023-08-08）：主讲人之一，介绍 ECS 的业务和技术背景，阐述企业面临的不可预测性挑战与 IaC 的核心价值 + +## Connections +- [[Raja-M]]：同场讲师，详解 ECS Terraform 模块技术实现 +- [[Cloud-Transformation-Programme]]：所属组织 diff --git a/wiki/entities/Jenkins.md b/wiki/entities/Jenkins.md index 494b788d..c5035b50 100644 --- a/wiki/entities/Jenkins.md +++ b/wiki/entities/Jenkins.md @@ -1,33 +1,58 @@ --- title: "Jenkins" type: entity -tags: ["CI/CD", "Automation", "DevOps"] -sources: ["learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2", "ctp-topic-26-standard-ami-build-publish-share-processes", "ctp-topic-1-gruntwork-landing-zone-architecture", "ctp-topic-7-saas-landing-zone-design"] -last_updated: 2026-05-08 +tags: + - CI/CD + - Automation + - DevOps +sources: + - ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments +last_updated: 2026-04-29 --- +# Jenkins + ## Overview -Jenkins 是开源的 CI/CD 自动化服务器，在 Micro Focus AWS Landing Zone 中承担基础设施即代码（IaC）部署和 AMI 构建的双重角色。每个 Landing Zone 配置独立的 Jenkins 服务器，通过多分支流水线（Multi-Branch Pipeline）管理 Terraform/TerraGrunt 模块的 plan 和 apply 流程，以及标准 AMI 的构建和测试。 + +Jenkins 是最广泛使用的开源自动化服务器之一，在 IaC 场景中曾被用于执行 Terraform 部署流水线。然而在 Atlantis 的对比中，Jenkins 流水线暴露出多个运维痛点。 + +## In This Context + +**[[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]** 指出原 Jenkins 流水线存在以下问题： + +### Speed Issues +- 显著的初始化时间（每次构建需重新初始化环境） +- 多次代码克隆（每个 stage 重复克隆仓库） +- 顺序测试（无法并行化，瓶颈明显） +- ECS Deployer 预配置耗时 + +### Complexity Issues +- 持续叠加功能以覆盖更多场景和边缘情况 +- 架构脆弱，易产生配置漂移（drift） +- 维护成本高，改动风险大 + +## Contrast with Atlantis + +| Aspect | Jenkins | Atlantis | +|--------|---------|----------| +| Trigger Method | Push (pipeline job) | Pull (PR comment) | +| Plan Timing | Pre-merge testing | Pre-merge apply | +| Module Locking | Requires plugin/config | Built-in automatic | +| Parallel Builds | Configurable, complex | Native support | +| Setup Complexity | High (many integrations) | Low (single EC2) | +| Cost (VPC Endpoints) | High | Low (removes many endpoints) | ## Aliases - Jenkins CI -- Jenkins Master -- Jenkins Slave -- Jenkins Multi-Branch Pipeline +- Jenkins Server -## Role in AWS Landing Zone -- **Shared 账户**：托管 Jenkins 主节点（Master），通过 Lambda 触发各账户 Jenkins 从节点 -- **AMI 构建**：Jenkins 多分支流水线驱动 Packer 镜像构建，包含脚本化测试和 AWS Inspector 安全扫描 -- **IaC 部署**：扫描 GitHub 仓库变更，触发 Terraform Plan/Apply 流水线 -- **每个 LZ 独立**：Gruntwork 参考架构中每个 Landing Zone 有自己的 Jenkins 服务器 +## Related Concepts +- [[CI/CD Pipeline]]：Jenkins 和 Atlantis 都属于 CI/CD 工具范畴 +- [[GitOps]]：Atlantis 更贴近 GitOps 理念，Jenkins 为传统 Push 模型 +- [[Infrastructure as Code (IaC)]]：两者均可用于 IaC 部署 -## Key Processes -- Feature Branch Pipeline：功能分支开发 → 合并到集成分支 → 构建测试 → 发布 -- Jenkinsfile 定义构建、测试、发布各阶段 -- 与 GitHub 集成实现自动化触发 +## Related Entities +- [[Atlantis]]：在 IaC 部署场景下替代 Jenkins 的方案 -## Connections -- [[AWS-Landing-Zone]] — Jenkins 是核心自动化基础设施 -- [[Terraform-IaC]] — Jenkins 流水线编排 Terraform 部署 -- [[Terragrunt]] — 与 Jenkins 配合的 IaC 工具 -- [[Gruntwork]] — Gruntwork 参考架构中的 Jenkins 配置模式 +## References +- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] diff --git a/wiki/entities/MUI.md b/wiki/entities/MUI.md new file mode 100644 index 00000000..34f724e4 --- /dev/null +++ b/wiki/entities/MUI.md @@ -0,0 +1,32 @@ +--- +title: MUI (Approval Authority) +type: entity +tags: [Cloud-Governance, Approval] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] +--- + +# MUI + +**MUI** 是 OpenText 超大规模云厂商支出审批人之一，与 Shannon 共同负责所有云支出的书面审批。 + +## Role & Responsibilities + +- **审批权限**：所有超大规模云厂商支出（含工程实验室和商业工作负载空间）无论金额，均需 MUI 书面审批 +- **审批范围**：工程实验室空间、商业工作负载空间 + +## Approval Authority + +| 审批人 | 职责 | +|--------|------| +| MUI | 超大规模云厂商支出审批人 | +| Shannon | 超大规模云厂商支出审批人 | + +## Related Concepts + +- [[Oli-Workflow]] — 超大规模云厂商支出审批工作流 +- [[FinOps]] — 云财务运营 +- [[Demand-Management]] — 需求管理 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/entities/Meta-AI.md b/wiki/entities/Meta-AI.md new file mode 100644 index 00000000..9dcdd6b1 --- /dev/null +++ b/wiki/entities/Meta-AI.md @@ -0,0 +1,35 @@ +--- +title: "Meta AI" +type: entity +tags: [ai, llm, foundation-model, aws, llama, open-source] +sources: [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111] +last_updated: 2026-05-12 +--- + +## Aliases +- Meta AI +- Meta Artificial Intelligence +- Llama (model family) + +## Summary + +**Meta AI** 是 Meta（原 Facebook）旗下的人工智能研究部门，开发 Llama 系列开源大语言模型（Llama 2、Llama 3 等）。Llama 模型通过 [[AmazonBedrock]] 全托管服务向 AWS 企业用户提供访问。 + +## Key Properties + +- **类型**：AI 研究部门 / 基础模型提供商 +- **代表模型**：Llama 2、Llama 3（开源，参数规模 7B~405B） +- **AWS 合作**：Llama 模型通过 Amazon Bedrock 提供 + +## Key Facts + +- 开源模型：Llama 系列允许研究者和开发者免费使用和微调 +- 多模态能力：Llama 3 新增多模态支持 +- 企业应用：通过 Bedrock 使用，企业无需自行部署 +- Bedrock 数据隐私：用户数据不与 Meta 共享 + +## Connections + +- 合作平台：[[AmazonBedrock]] +- 同类提供商：[[Anthropic]]（Claude 系列）、Amazon Titan +- 关联公司：[[OpenText]]（在 AWS 学习会议中介绍 Bedrock 上的 Llama 模型） diff --git a/wiki/entities/Octane.md b/wiki/entities/Octane.md index 960cb984..68236a04 100644 --- a/wiki/entities/Octane.md +++ b/wiki/entities/Octane.md @@ -1,43 +1,41 @@ --- -title: "Octane" +title: Octane type: entity -tags: - - MicroFocus - - SaaS - - Kubernetes - - EKS -sources: - - ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone - - ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i -last_updated: 2026-04-28 +tags: [Platform, SaaS, Demand-Management] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16, ctp-topic-57-product-backlog-managing-demand] --- +# Octane + +**Octane** 是 OpenText 超大规模云厂商 SaaS 产品需求管理平台，业务单元可直接向其提交需求。 + ## Overview -Octane 是 Micro Focus（现 OpenText）旗下一款 SaaS 应用，以 IP 地址密集型（IP-hungry）workload 著称，是推动 EKS 在 AWS Lab Landing Zone 中实施的核心业务驱动因素。 -## Aliases -- Octane -- Micro Focus Octane -- Octane SaaS +Octane 是 OpenText 需求管理流程的核心平台之一，支持： +- 业务单元直接提交云产品需求 +- 产品待办列表（Product Backlog）管理 +- 需求特性化与 Sprint 规划 -## Key Characteristics -- SaaS 模式部署 -- IP 地址密集型应用，对 IP 分配有大量需求 -- 在 AWS 环境中需要 Kubernetes 容器编排能力 -- 驱动了 OpenText/Micro Focus 团队对 EKS 自定义网络方案的探索 +## Role in Demand Management -## Context -Octane 是 CTP Topic 39 中 EKS 部署的驱动用例。标准 EKS 部署方案无法满足其 IP 需求，团队通过以下方案解决： -- 创建独立私有子网（非主 VPC 子网） -- 启用 EKS 模块的自定义网络配置标志 -- 在 Pod 规范中设置 `hostNetwork: true` +| 入口 | 用途 | +|------|------| +| Octane | SaaS 产品需求管理平台 | +| Qixi | Oli 需求提交流程的前端接口 | + +## Related Concepts + +- [[Demand-Management]] — 需求管理 +- [[Product-Backlog]] — 产品待办列表 +- [[SMACs]] — 技术栈组合 +- [[Qixi]] — 另一个需求提交入口 ## Related Entities -- [[Amazon-EKS]]：Octane 部署的容器编排平台 -- [[AWS-Landing-Zone]]：Octane 运行的 AWS 基础设施环境 -- [[MicroFocus]]：（历史）开发 Octane 的公司 -- [[OpenText]]：（现母公司） -## Related Sources -- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] -- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] +- [[FPNA-Team]] — 预算验证团队 +- [[Tom-Bice]] — FinOps 团队负责人 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] +- [[sources/ctp-topic-57-product-backlog-managing-demand.md]] diff --git a/wiki/entities/PCG.md b/wiki/entities/PCG.md new file mode 100644 index 00000000..59f76c03 --- /dev/null +++ b/wiki/entities/PCG.md @@ -0,0 +1,34 @@ +--- +title: "PCG (Public Cloud Governance)" +type: entity +tags: + - AWS + - Governance + - Cloud +aliases: + - PCG + - Public Cloud Governance +last_updated: 2026-05-12 +--- + +## Overview + +PCG（Public Cloud Governance，公共云治理）团队是负责制定和执行 AWS 公共云治理策略的核心团队，为工作负载放置、成本和优化提供指导。 + +## Roles & Responsibilities + +- **成本管理**：账单支付、showback/chargeback、预算管理 +- **成本优化**：组织级和账户级优化，包括购买 Reserved Instances 和识别未充分利用的资源 +- **治理与自动化**：集中式上线、策略开发、自动报告 + +## Key Members + +- [[Uday]]：PCG 团队成员，FinOps 主题讲师 +- [[Vinay]]：PCG 团队成员，FinOps 主题讲师 + +## Related Pages + +- [[FinOps（云财务管理）]] +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] +- [[ctp-topic-63-optimise-resource-cost-using-automation]] +- [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]] diff --git a/wiki/entities/PCGTeam.md b/wiki/entities/PCGTeam.md index 9c0ba646..e7df90cc 100644 --- a/wiki/entities/PCGTeam.md +++ b/wiki/entities/PCGTeam.md @@ -1,37 +1,48 @@ --- -title: "PCG Team" +title: "PCG Team (Public Cloud Governance)" type: entity -tags: [CTP, Cloud, AWS, Platform] -sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] -last_updated: 2026-04-14 +tags: + - AWS + - Governance + - Cloud + - FinOps +aliases: + - PCG + - PCGTeam + - Public Cloud Governance +sources: + - ctp-topic-20-program-demand-process-flow-and-poc-onboarding + - ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co +last_updated: 2026-05-12 --- -## PCG Team +## Overview -Platform Control Group（PCG，平台控制组），是云转型计划（CTP）中负责提供云环境支持、安全策略制定及协助产品团队进行 POC 的核心技术团队。 +PCG（Public Cloud Governance，公共云治理）团队是负责制定和执行 AWS 公共云治理策略的核心团队，为工作负载放置、成本和优化提供指导。 ## Role - **云环境支持**：为产品团队提供 AWS Landing Zone 环境的部署与运维支持 - **安全策略制定**：定义和维护云环境的安全基线与合规标准 - **POC 协助**：在概念验证阶段为产品团队提供技术指导和架构评审 +- **FinOps 治理**：云成本管理、优化和治理自动化 -## Responsibilities +## FinOps Responsibilities -- 管理基于 Gruntwork 的 Landing Zone 参考架构 -- 提供 IaC（Terraform/Terragrunt）部署支持 -- 执行 Design Authority 审批（Gate 1），确保解决方案设计符合云原生原则 -- 定义 POC 成功标准，验证产品具备进入生产环境迁移的条件 +- **成本管理**：账单支付、showback/chargeback、预算管理 +- **成本优化**：组织级和账户级优化，包括购买 Reserved Instances 和识别未充分利用的资源 +- **治理与自动化**：集中式上线、策略开发、自动报告 -## Key Deliverables +## Key Members -- 预配置的标准化 Landing Zone 环境 -- 安全策略与合规基线 -- IaC 自动化部署流水线 -- 迁移时间表与路线图 +- [[Uday]]：PCG 团队成员，FinOps 主题讲师 +- [[Vinay]]：PCG 团队成员，FinOps 主题讲师 ## Connections - 为 [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] 提供 POC 支持 - 与 [[Gruntwork]] 合作提供 Landing Zone 参考架构 - 通过 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 提供架构基础 +- 主讲 [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] FinOps 治理框架 +- 主讲 [[ctp-topic-63-optimise-resource-cost-using-automation]] 成本自动化优化 +- 主讲 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]] Rightsizing 方法论 diff --git a/wiki/entities/Paul-Hopkins.md b/wiki/entities/Paul-Hopkins.md new file mode 100644 index 00000000..6cc920dc --- /dev/null +++ b/wiki/entities/Paul-Hopkins.md @@ -0,0 +1,29 @@ +--- +title: "Paul Hopkins" +type: entity +tags: + - CTP + - DevOps + - Cloud-Transformation +last_updated: 2026-05-11 +--- + +# Paul Hopkins + +## Role +DevOps / Cloud Transformation 领域专家，CTP（Cloud Transformation Programme）系列学习会议主讲人之一。 + +## Contributions +- 主讲 **CTP Topic 15: Working with Renovatebot** — 分享 Renovate Bot 自动化管理云原生基础设施依赖项的实践经验 +- 在会议中介绍依赖地狱（Dependency Hell）问题背景及 Renovate Bot 解决方案 + +## Related Concepts +- [[Renovate-Bot]] — 演讲主题 +- [[Dependency-Management]] — 演讲主题 +- [[GitOps]] — 演讲上下文 + +## Related Sources +- [[ctp-topic-15-working-with-renovatebot]] + +## Aliases +- Paul Hopkins（Paul Hopkins 是唯一标准名称） diff --git a/wiki/entities/Qixi.md b/wiki/entities/Qixi.md new file mode 100644 index 00000000..4d008717 --- /dev/null +++ b/wiki/entities/Qixi.md @@ -0,0 +1,32 @@ +--- +title: Qixi +type: entity +tags: [Platform, Demand-Management, Workflow] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] +--- + +# Qixi + +**Qixi** 是 Oli 需求提交流程的前端接口之一，业务单元通过其提交需求。 + +## Overview + +Qixi 是 OpenText 需求提交入口之一，与 Octane 共同支持业务单元的云服务请求。 + +## Role in Demand Management + +| 入口 | 用途 | +|------|------| +| Octane | SaaS 产品需求管理平台 | +| Qixi | Oli 需求提交流程的前端接口 | + +## Related Concepts + +- [[Demand-Management]] — 需求管理 +- [[Oli-Workflow]] — 超大规模云厂商支出审批工作流 +- [[Octane]] — 另一个需求提交入口 +- [[SMACs]] — 目标集成平台 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/entities/Raja-M.md b/wiki/entities/Raja-M.md new file mode 100644 index 00000000..0e66324c --- /dev/null +++ b/wiki/entities/Raja-M.md @@ -0,0 +1,33 @@ +--- +title: "Raja M" +type: entity +tags: + - CTP + - SRE + - ECS + - IaC +sources: + - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recording +last_updated: 2023-08-08 +--- + +## Profile +Raja M，CTP/SRE 团队成员，负责 ECS Terraform 模块的技术构建与实现。 + +## Aliases +- Raja M +- RajaM + +## Role in Sources +- **ECS Deployment using IaC**（2023-08-08）：详细讲解 CTP/SRE 团队基于 Gruntwork 仓库构建的 ECS Terraform 模块实现方式 + +## Key Contributions +- 设计并实现 ECS Terraform 模块（基于 Gruntwork） +- 提出 Listener 集中管理模式，避免各产品团队直接下载 Gruntwork 模板导致的碎片化问题 +- 定义 ECS 部署前置条件（VPC、ELB 安全组、EFS 卷挂载） + +## Connections +- [[JP]]：同场讲师，负责业务背景介绍 +- [[ECS-Module]]：核心产出 +- [[Gruntwork]]：技术基础来源 +- [[CTP-SRE-Team]]：所属团队 diff --git a/wiki/entities/SRE-Team.md b/wiki/entities/SRE-Team.md index c3a9e2f9..3ac7007a 100644 --- a/wiki/entities/SRE-Team.md +++ b/wiki/entities/SRE-Team.md @@ -39,3 +39,4 @@ SRE 团队维护的内部代码仓库（[[SRE-Tools-Repository]]），集中存 - [[ctp-topic-28-aws-tag-validation-tool]] - [[ctp-topic-30-managing-change]] - [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] +- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]（ECS Terraform 模块设计与维护） diff --git a/wiki/entities/Shannon.md b/wiki/entities/Shannon.md new file mode 100644 index 00000000..e3ba7ae4 --- /dev/null +++ b/wiki/entities/Shannon.md @@ -0,0 +1,32 @@ +--- +title: Shannon (Approval Authority) +type: entity +tags: [Cloud-Governance, Approval] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] +--- + +# Shannon + +**Shannon** 是 OpenText 超大规模云厂商支出审批人之一，与 MUI 共同负责所有云支出的书面审批。 + +## Role & Responsibilities + +- **审批权限**：所有超大规模云厂商支出（含工程实验室和商业工作负载空间）无论金额，均需 Shannon 书面审批 +- **审批范围**：工程实验室空间、商业工作负载空间 + +## Approval Authority + +| 审批人 | 职责 | +|--------|------| +| MUI | 超大规模云厂商支出审批人 | +| Shannon | 超大规模云厂商支出审批人 | + +## Related Concepts + +- [[Oli-Workflow]] — 超大规模云厂商支出审批工作流 +- [[FinOps]] — 云财务运营 +- [[Demand-Management]] — 需求管理 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/entities/Shared-Account.md b/wiki/entities/Shared-Account.md new file mode 100644 index 00000000..de8b05d5 --- /dev/null +++ b/wiki/entities/Shared-Account.md @@ -0,0 +1,55 @@ +--- +title: "Shared Account" +type: entity +entity_type: concept +tags: + - AWS + - Multi-Account + - Landing-Zone + - Architecture +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +Shared Account（共享账号）是 AWS Landing Zone 架构中的核心管理账号，托管 Jenkins CI/CD 平台、镜像仓库等公共服务，并作为跨账号部署的信任源（Trust Source）。在整个落地分区中，它是唯一被允许通过 Assume Role 访问 Workload 账号的账户。 + +## Role in Landing Zone + +在 AWS Landing Zone 多账号架构中，Shared Account（也称 Shared Services Account）承担以下职责： + +| 职责 | 说明 | +|------|------| +| CI/CD 托管 | 托管 Jenkins、构建代理等持续交付基础设施 | +| 镜像仓库 | 存储 Docker AMI、ECS 容器镜像等 | +| 跨账号部署 | 作为唯一信任源，通过 Assume Role 访问目标 Workload 账号 | +| 公共服务供给 | 提供 DNS（InfoBlocks 账号）、NTP 等跨账号共享服务 | + +## Security Model + +- **Blast Radius 控制**：Workload 账号之间无直接信任关系，权限集中于 Shared Account +- **最小权限原则**：EDR 仅持有执行部署所需的最小 IAM 权限（两个专用角色） +- **审计可追溯**：Shared Account 的所有操作集中记录，便于安全审计 + +## Relationship with ECS Deploy Runner + +[[ECS-Deploy-Runner]] 运行在 Shared Account 的 ECS 集群中，当 Jenkins 触发部署时，EDR 以 Shared Account 身份通过 Assume Role 访问目标账号： + +``` +Shared Account (EDR) → Assume Role → TF State Bucket Accessor (目标账号) +Shared Account (EDR) → Assume Role → Cross-account ECS Deploy Runner Role (目标账号) +``` + +## Related Entities + +- [[AWS-Landing-Zone]]：Shared Account 是 Landing Zone 架构的核心组件 +- [[ECS-Deploy-Runner]]：运行在 Shared Account 中 +- [[Fibos]]：Shared Account 部署方案的设计者 + +## Related Concepts + +- [[Blast-Radius]]：Shared Account 的核心安全价值 +- [[Assume-Role]]：跨账号身份切换机制 +- [[Cross-account-Terraform-Modules]]：Shared Account 支撑的核心功能 diff --git a/wiki/entities/Shikad-Holtzman.md b/wiki/entities/Shikad-Holtzman.md new file mode 100644 index 00000000..d2aa0a91 --- /dev/null +++ b/wiki/entities/Shikad-Holtzman.md @@ -0,0 +1,35 @@ +--- +title: "Shikad Holtzman" +type: entity +tags: [opentext, aws, generative-ai, prompt-engineering] +sources: [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111] +last_updated: 2026-05-12 +--- + +## Aliases +- Shikad + +## Summary + +**Shikad Holtzman** 是 OpenText 的技术客户经理（Technical Account Manager），常驻以色列。在 OpenText 主办的 Public Cloud Learning Sessions 中担任主讲，分享 AWS 生成式 AI 与 Prompt Engineering 实践。 + +## Key Properties + +- **类型**：人物 / 技术客户经理 +- **公司**：OpenText +- **地点**：以色列 +- **专业领域**：AWS 生成式 AI、Prompt Engineering、企业 AI 应用 + +## Key Contributions + +在 2024年11月12日的学习会议中，Shikad 分享了： +- AWS 生成式 AI 价值创造四维度（新体验、生产力提升、洞察提取、创造力激发） +- 领域专属生成式应用的三大构建技术（RAG、Fine-tuning、持续预训练） +- Prompt Engineering 基础（四大组件 + One-shot/Few-shot/Chain-of-Thought 技巧） +- AWS Generative AI 技术栈分层架构 + +## Connections + +- 所属公司：[[OpenText]] +- 关联服务：[[AmazonBedrock]]、[[AmazonQ]] +- 相关会议：Public Cloud Learning Sessions 系列 diff --git a/wiki/entities/Stephen-Frank.md b/wiki/entities/Stephen-Frank.md new file mode 100644 index 00000000..12b9cb00 --- /dev/null +++ b/wiki/entities/Stephen-Frank.md @@ -0,0 +1,44 @@ +--- +title: "Stephen Frank" +type: entity +tags: [AWS, AI, expert, OpenText, learning-session] +sources: [public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec] +last_updated: 2026-05-12 +--- + +## Aliases +- Stephen Frank (AWS) +- AWS Stephen Frank + +## Summary +**Stephen Frank** 是 AWS AI 专家（AI Specialist），在 OpenText Public Cloud Learning Sessions 中分享了 AWS Gen2 生成式 AI 发展驱动力与企业在生产环境中的 AI 应用场景，涵盖 AI 演进历程、数据整合方法、AWS 三层产品战略和负责任 AI 实践。 + +## Key Properties +- **类型**：AWS 内部专家 / AI 专家 +- **所属**：Amazon Web Services (AWS) +- **角色**：AI Specialist +- **分享主题**：AWS AI Use Cases（AI 使用场景） + +## Key Contributions +- 阐述 AI 四代演进：模仿人类行为 → 机器学习 → 深度学习 → Gen2 大语言模型 +- 揭示 Gen2 AI 崛起两大驱动力：数据爆发式增长 + 更大算力可获得性 +- 总结通用 AI 应用场景（创造新体验/推断洞察/流程自动化/内容生成） +- 总结企业软件 AI 应用（优化内部流程/启用新功能/创造新产品） +- 强调"数据是企业差异化关键"，详解 RAG / Fine-tuning / 持续预训练三大数据整合方法 +- 介绍 AWS 三层产品战略（基础设施 / Amazon Bedrock / AI 应用） +- 强调负责任 AI（公平性、可解释性、透明性）和安全治理合规 + +## Related Entities +- [[Amazon-Bedrock]]：AWS 旗舰生成式 AI 产品，Stephen Frank 重点介绍 +- [[Amazon-Q]]：AWS AI 助手，属于 AWS AI 应用层 +- [[Amazon-SageMaker]]：AWS 全托管 ML 平台 +- [[OpenText]]：学习会话主办方 + +## Related Concepts +- [[Foundation-Models]]：基础模型是 Gen2 AI 的核心 +- [[RAG]]：数据整合方法之一 +- [[Fine-Tuning]]：数据整合方法之一 +- [[Responsible-AI]]：AWS AI 落地的核心原则 + +## Related Sources +- [[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]] — Stephen Frank 主讲的 AI Use Cases 分享 diff --git a/wiki/entities/Suraav-Paul.md b/wiki/entities/Suraav-Paul.md new file mode 100644 index 00000000..7c68015e --- /dev/null +++ b/wiki/entities/Suraav-Paul.md @@ -0,0 +1,26 @@ +--- +title: "Suraav Paul" +type: entity +tags: [AWS, Solutions-Architect, AI, ML] +sources: + - public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin +last_updated: 2026-05-12 +--- + +## Overview +Suraav Paul 是 Amazon Web Services（AWS）的高级解决方案架构师（Senior Solutions Architect），专注于 AI/ML 和生成式 AI 领域，主讲 Public Cloud Learning Sessions 的 AI/ML 入门课程。 + +## Aliases +- Suraav Paul +- Suraav Paul (AWS) + +## Role +- **Organization**: Amazon Web Services (AWS) +- **Title**: Senior Solutions Architect +- **Focus Areas**: AI/ML, Generative AI, Amazon Bedrock, MLOps + +## Key Contributions +- Public Cloud Learning Sessions：AWS AI/ML 入门（2024-02-06）—— 介绍 AI 三层分类（分类 AI / 预测 AI / 生成式 AI）、Amazon Bedrock 基础模型服务、ML Ops 全生命周期实践 + +## Sources +- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] diff --git a/wiki/entities/TF-State-Bucket-Accessor.md b/wiki/entities/TF-State-Bucket-Accessor.md new file mode 100644 index 00000000..8a31f757 --- /dev/null +++ b/wiki/entities/TF-State-Bucket-Accessor.md @@ -0,0 +1,59 @@ +--- +title: "TF State Bucket Accessor" +type: entity +entity_type: product +tags: + - Terraform + - IAM + - S3 + - State-Management + - AWS +sources: + - ctp-topic-16-cross-account-terraform-modules.md +last_updated: 2026-05-15 +--- + +## Overview + +TF State Bucket Accessor 是部署在目标 AWS 账号中的一种专门 IAM 角色，仅允许部署工具（ECS Deploy Runner）访问存储在该账号 S3 桶中的 Terraform 状态文件。 + +## Purpose + +Terraform 通过状态文件（state file）追踪基础设施的实际部署状态。在跨账号场景中： + +- **状态文件位置**：存储在目标 Workload 账号的 S3 桶中 +- **访问控制问题**：Shared Account 的 ECS Deploy Runner 需要读取这些状态文件，但直接赋予 S3 访问权限存在安全风险 +- **解决方案**：创建专门的 IAM 角色，仅允许特定的部署执行器 Assume 该角色 + +## IAM Policy Design + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::role/ecs-deploy-runner-execution-role" + }, + "Action": [ + "s3:GetObject", + "s3:PutObject" + ], + "Resource": "arn:aws:s3:::-terraform-state/*" + } + ] +} +``` + +## Relationships + +- [[ECS-Deploy-Runner]] ← reads_state ← [[TF-State-Bucket-Accessor]] +- [[Cross-account-ECS-Deploy-Runner-Role]] ← sibling_role ← [[TF-State-Bucket-Accessor]] +- [[TerraformState]] ← protected_by ← [[TF-State-Bucket-Accessor]] + +## Related Concepts + +- [[TerraformState]]：状态文件管理是 IaC 的核心问题 +- [[Assume-Role]]：EDR 通过 Assume Role 获取该角色的临时凭证 +- [[Blast-Radius]]：专门角色限制了凭证泄露时的爆炸半径 diff --git a/wiki/entities/Tom-Bice.md b/wiki/entities/Tom-Bice.md new file mode 100644 index 00000000..e44a8ab2 --- /dev/null +++ b/wiki/entities/Tom-Bice.md @@ -0,0 +1,26 @@ +--- +title: Tom Bice +type: entity +tags: [FinOps, Cloud-Governance] +sources: [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16] +--- + +# Tom Bice + +**Tom Bice** 是 FinOps 团队的负责人，负责 OpenText 超大规模云厂商支出审批工作流（Oli Workflow）的接管与集成工作。 + +## Role & Responsibilities + +- **FinOps 团队负责人**：主导云支出可视性与成本优化 +- **Oli Workflow 接管**：将 Oli 工作流从原有系统迁移至 FinOps 团队管辖 +- **SMACs 集成**：推动 Oli 工作流集成到 SMACs（Social, Mobile, Analytics, Cloud）平台 + +## Related Concepts + +- [[FinOps]] — 云财务运营实践 +- [[SMACs]] — 技术栈组合，Oli 工作流的目标集成平台 +- [[Demand-Management]] — 需求管理是 Oli 工作流的核心功能 + +## Sources + +- [[sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]] diff --git a/wiki/entities/Uday.md b/wiki/entities/Uday.md new file mode 100644 index 00000000..8de629f1 --- /dev/null +++ b/wiki/entities/Uday.md @@ -0,0 +1,24 @@ +--- +title: "Uday" +type: entity +tags: + - FinOps + - Cloud +aliases: + - Uday +last_updated: 2026-05-12 +--- + +## Overview + +Uday 是 PCG（Public Cloud Governance）团队成员，专注于 FinOps（云财务管理）和成本优化领域。 + +## Contributions + +- 主讲 CTP Topic 13：Cloud FinOps 政策与最佳实践（与 Vinay 联合主讲） + +## Related Pages + +- [[PCG]] +- [[FinOps（云财务管理）]] +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] diff --git a/wiki/entities/Vinay.md b/wiki/entities/Vinay.md index 5c74ef45..0bcf504e 100644 --- a/wiki/entities/Vinay.md +++ b/wiki/entities/Vinay.md @@ -1,35 +1,26 @@ ---- -title: "Vinay" -type: entity -tags: - - person - - FinOps - - AWS -sources: - - ctp-topic-13-cloud-finops-policies - - ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana - - public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco -last_updated: 2026-04-24 ---- - -# Vinay - -FinOps 团队成员，OpenText/Micro Focus 云转型计划中的云财务管理专家。 - -## Aliases -- Vinay - -## Role & Contributions -- 主讲 [[ctp-topic-13-cloud-finops-policies]]（CTP Topic 13）：与 Uday 共同主讲 Cloud FinOps 成本优化政策与最佳实践 -- 主讲 [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]]（CTP Topic 60）：代替休假的 Sashi 主持 Grafana 可观测性监控学习会议 -- 主讲本条来源：Public Cloud Learning Sessions 云成本优化技术实践（工作负载优化 + 费率优化） - -## Key Quotes -- "Whenever there's a new family launched by the hyperscale, the latest families are almost cheaper." -- "Rather than spending up unnecessary moment on the extended support, you can deploy additional four or five cluster, right." -- "Spot instances can provide up to 90% discount compared to on-demand, suitable for big data, CI/CD pipelines, web servers, and HPC." -- "Only the Phenops's team can implement commitment plans." - -## Connections -- 与 [[Uday]]（PCG 团队成员）共同主导 FinOps 政策制定 -- 与 [[Vinay]] 关联的团队：[[Phenops-Team]]（负责实施费率承诺计划） +--- +title: "Vinay" +type: entity +tags: + - FinOps + - Cloud +aliases: + - Vinay +last_updated: 2026-05-12 +--- + +## Overview + +Vinay 是 PCG（Public Cloud Governance）团队成员，专注于 FinOps（云财务管理）和成本优化领域。 + +## Contributions + +- 主讲 CTP Topic 13：Cloud FinOps 政策与最佳实践（与 Uday 联合主讲） +- 主讲 AWS 云成本优化技术深度实践（public-cloud-learning-sessions-reducing-cloud-costs-20250318） + +## Related Pages + +- [[PCG]] +- [[FinOps（云财务管理）]] +- [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]] +- [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]] diff --git a/wiki/entities/cloud-transformation-programme.md b/wiki/entities/cloud-transformation-programme.md index d1feaa1e..cbb5ec85 100644 --- a/wiki/entities/cloud-transformation-programme.md +++ b/wiki/entities/cloud-transformation-programme.md @@ -1,33 +1,35 @@ --- title: "Cloud Transformation Programme (CTP)" type: entity -entity_type: Project tags: - - Cloud-Transformation - - OpenText - - CTP - - AWS + - Cloud + - Transformation + - Program sources: - - ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation -last_updated: 2026-04-28 + - learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi + - ctp-topic-3-deploy-and-maintain-infrastructure + - ctp-topic-4-using-agile-to-run-the-cloud-transformation-program +last_updated: 2023-08-08 --- -## Description - -OpenText 的 Cloud Transformation Programme（云转型计划，简称 CTP）是一个跨多个业务单元的系统性云迁移与转型项目，旨在将传统本地基础设施迁移至 AWS 等公有云平台，并通过 [[Lean]] 方法论和 [[Scaled Agile]] 框架实现价值最大化交付。 - -## Related Concepts - -- [[Value Stream]]：CTP 的工作组织方式 -- [[Weighted Shortest Job First (WSJF)]]：CTP 工作的优先级排序方法 -- [[Cost of Delay (CoD)]]：CTP 价值评估的核心指标 - -## Related Sources - -- [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]] -- （其他 CTP Topic source pages，见 index.md） +## Profile +Cloud Transformation Programme（云转型计划），组织发起的基础设施现代化计划，旨在通过云技术实现业务敏捷性和运营效率提升。 ## Aliases - CTP - Cloud Transformation Programme -- 云转型计划 +- Cloud Transformation Program + +## Programme Overview +每周二定期举办 Learning Sessions 学习课程，邀请内部专家分享云技术实践，覆盖 Terraform、ECS、EKS、Serverless、FinOps 等主题。 + +## Key Initiatives +- **基础设施即代码（IaC）**：通过 Terraform/Terragrunt 实现云资源标准化管理 +- **ECS 容器化部署**：基于 Gruntwork 构建可复用 ECS 模块 +- **CI/CD 集成**：与 Gruntwork、Atlantis 工具链结合 + +## Connections +- [[Infrastructure-as-Code]] ← implements ← CTP（IaC 是 CTP 的核心实现手段） +- [[ECS-Module]]：CTP/SRE 团队核心产出 +- [[JP]] / [[Raja-M]]：CTP 讲师 +- [[Gruntwork]]：技术基础 diff --git a/wiki/index.md b/wiki/index.md index ca17ec6f..8bffd41a 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,6 +4,23 @@ - [Overview](overview.md) — living synthesis ## Sources +- [2026-04-29] [Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording](sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md) +- [2026-04-29] [CTP Topic 16 Cross-account Terraform modules](sources/ctp-topic-16-cross-account-terraform-modules.md) +- [2026-04-29] [Learning Sessions ECS Deployment using IAC - 20230808](sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md) +- [2026-04-29] [CTP Topic 48 Terraform vs Terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md) +- [2026-04-29] [Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md) +- [2026-04-29] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md) +- [2026-04-29] [Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md) +- [2026-04-29] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md) +- [2026-04-29] [Public Cloud Learning Sessions (OpenText) - Serverless Computing - 20240903](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md) +- [2026-04-29] [Public Cloud Learning Sessions - Introduction to AI/ML with AWS](sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md) +- [2026-04-29] [Cloud Learning Master Index](sources/cloud-learning-master-index.md) +- [2026-04-29] [CTP Topic 27 AWS Instance Scheduler](sources/ctp-topic-27-aws-instance-scheduler.md) +- [2026-04-29] [Public Cloud Learning Sessions - Budget Control - 20240319 160204-Meeting Recording](sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md) +- [2026-04-29] [CTP Topic 63 Optimise resource cost using automation](sources/ctp-topic-63-optimise-resource-cost-using-automation.md) +- [2026-04-29] [Public Cloud Learning Sessions - Storage Cost Optimization - 20240305](sources/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md) +- [2026-04-29] [CTP Topic 71 PCG's guide to RightSizing, why, how when](sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md) +- [2026-04-29] [Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529](sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md) - [2026-04-29] [Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318](sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md) - [2026-04-29] [CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs](sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md) - [2026-04-29] [CTP Topic 15 Working with Renovatebot](sources/ctp-topic-15-working-with-renovatebot.md) @@ -282,24 +299,7 @@ - [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing) - [n8n-docker-配置-telegram-代理-troubleshooting](sources/n8n-docker-配置-telegram-代理-troubleshooting.md) — (expected: wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md — source missing) - [sre-weekly-issue-513](sources/sre-weekly-issue-513.md) — (expected: wiki/sources/sre-weekly-issue-513.md — source missing) -- [Cloud Learning Master Index](sources/cloud-learning-master-index.md) -- [Public Cloud Learning Sessions - Serverless Computing - 20240903](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md) -- [Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md) -- [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md) -- [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md) -- [Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md) -- [Public Cloud Learning Sessions - Introduction to AI/ML with AWS](sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md) -- [Public Cloud Learning Sessions - Storage Cost Optimization - 20240305](sources/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md) -- [Public Cloud Learning Sessions - Budget Control - 20240319](sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md) -- [2024-05-29] [Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529](sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md) — AWS EC2 成本优化最佳实践：Graviton（40% 性价比提升）、Spot 竞价（90% 折扣）、Nitro 系统、购买选项策略 -- [CTP Topic 71 PCG's guide to RightSizing, why, how when](sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md) -- [CTP Topic 63 Optimise resource cost using automation](sources/ctp-topic-63-optimise-resource-cost-using-automation.md) -- [CTP Topic 27 AWS Instance Scheduler](sources/ctp-topic-27-aws-instance-scheduler.md) -- [Learning Sessions ECS Deployment using IAC - 20230808](sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md) - [Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform](sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md) -- [Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording](sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md) -- [CTP Topic 48 Terraform vs Terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md) -- [CTP Topic 16 Cross-account Terraform modules](sources/ctp-topic-16-cross-account-terraform-modules.md) - [CTP Topic 12 Using SES SMTP service terraform module](sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md) - [n8n调用hermes-agents的工作流架构](sources/n8n调用hermes-agents的工作流架构.md) — (expected: wiki/sources/n8n调用hermes-agents的工作流架构.md — source missing) - [n8n-调用openclaw-agents的工作流架构](sources/n8n-调用openclaw-agents的工作流架构.md) — (expected: wiki/sources/n8n-调用openclaw-agents的工作流架构.md — source missing) @@ -560,12 +560,16 @@ - [Amazon-EventBridge](entities/Amazon-EventBridge.md) - [Amazon-Keyspaces](entities/Amazon-Keyspaces.md) - [Amazon-Neptune](entities/Amazon-Neptune.md) +- [Amazon-Q](entities/Amazon-Q.md) - [Amazon-RDS](entities/Amazon-RDS.md) - [Amazon-Redshift](entities/Amazon-Redshift.md) +- [Amazon-SageMaker](entities/Amazon-SageMaker.md) - [Amazon-Timestream](entities/Amazon-Timestream.md) +- [Amazon-Titan](entities/Amazon-Titan.md) - [Amazon-Workspaces](entities/Amazon-Workspaces.md) - [AmazonAds](entities/AmazonAds.md) - [Andrej-Karpathy](entities/Andrej-Karpathy.md) +- [Anil-Giri](entities/Anil-Giri.md) - [Anki](entities/Anki.md) - [Anthropic](entities/Anthropic.md) - [Apache-Superset](entities/Apache-Superset.md) @@ -580,6 +584,7 @@ - [AWS-Backup](entities/AWS-Backup.md) - [AWS-Backup-Audit-Manager](entities/AWS-Backup-Audit-Manager.md) - [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md) +- [AWS-EventBridge](entities/AWS-EventBridge.md) - [AWS-Lambda](entities/AWS-Lambda.md) - [AWS-Landing-Zone](entities/AWS-Landing-Zone.md) - [AWS-OpenSearch](entities/AWS-OpenSearch.md) @@ -645,6 +650,8 @@ - [Content-Creator](entities/Content-Creator.md) - [Coze](entities/Coze.md) - [CrewAI](entities/CrewAI.md) +- [Cross-account-ECS-Deploy-Runner-Role](entities/Cross-account-ECS-Deploy-Runner-Role.md) +- [CTP-SRE-Team](entities/CTP-SRE-Team.md) - [Cursor](entities/Cursor.md) - [Curve-Finance](entities/Curve-Finance.md) - [CyberArk](entities/CyberArk.md) @@ -675,10 +682,12 @@ - [Duolingo](entities/Duolingo.md) - [DXC-VSM](entities/DXC-VSM.md) - [DXY](entities/DXY.md) +- [ECS-Deploy-Runner](entities/ECS-Deploy-Runner.md) - [Ed](entities/Ed.md) - [EESJGong](entities/EESJGong.md) - [Euler-Finance](entities/Euler-Finance.md) - [Eurocode](entities/Eurocode.md) +- [Fibos](entities/Fibos.md) - [Final-Cut-Pro](entities/Final-Cut-Pro.md) - [fireworks-tech-graph](entities/fireworks-tech-graph.md) - [Flux](entities/Flux.md) @@ -710,6 +719,7 @@ - [Grafana](entities/Grafana.md) - [Growth-Hacker](entities/Growth-Hacker.md) - [Gruntwork](entities/Gruntwork.md) +- [Gustavo](entities/Gustavo.md) - [Hailuo-AI](entities/Hailuo-AI.md) - [HashiCorp](entities/HashiCorp.md) - [Heather-Norris](entities/Heather-Norris.md) @@ -736,6 +746,7 @@ - [Jira](entities/Jira.md) - [Jira-Workflow-Steward](entities/Jira-Workflow-Steward.md) - [JohnWilliams](entities/JohnWilliams.md) +- [JP](entities/JP.md) - [K3s](entities/K3s.md) - [KAI](entities/KAI.md) - [KakaoTalk](entities/KakaoTalk.md) @@ -769,6 +780,7 @@ - [Memsearch](entities/Memsearch.md) - [MerlinClash插件](entities/MerlinClash插件.md) - [Meta-Ads-Manager](entities/Meta-Ads-Manager.md) +- [Meta-AI](entities/Meta-AI.md) - [MichaelRiley](entities/MichaelRiley.md) - [Micro-Focus](entities/Micro-Focus.md) - [Micro-Focus-IGA](entities/Micro-Focus-IGA.md) @@ -777,8 +789,8 @@ - [MicrosoftAdvertising](entities/MicrosoftAdvertising.md) - [Midjourney](entities/Midjourney.md) - [Mike](entities/Mike.md) +- [Mike-Dukes](entities/Mike-Dukes.md) - [MikeArmstrong](entities/MikeArmstrong.md) -- [Mike-Dukes](entities/Mike-Dukes.md) — AWS 专家，EC2 成本优化讲师 - [MikeOReily](entities/MikeOReily.md) - [Milvus](entities/Milvus.md) - [MinIO](entities/MinIO.md) @@ -854,6 +866,7 @@ - [RackNerd](entities/RackNerd.md) - [RAIT-09](entities/RAIT-09.md) - [Raj-Vardhan-Singh](entities/Raj-Vardhan-Singh.md) +- [Raja-M](entities/Raja-M.md) - [Rapid-Prototyper](entities/Rapid-Prototyper.md) - [Raycast](entities/Raycast.md) - [Reality-Checker](entities/Reality-Checker.md) @@ -874,8 +887,9 @@ - [Sentinel-1](entities/Sentinel-1.md) - [Sergio](entities/Sergio.md) - [Shannon](entities/Shannon.md) +- [Shared-Account](entities/Shared-Account.md) - [shenwei](entities/shenwei.md) -- [Steele-Taylor](entities/Steele-Taylor.md) — AWS 专家，EC2 成本优化讲师 +- [Shikad-Holtzman](entities/Shikad-Holtzman.md) - [SilverPeak](entities/SilverPeak.md) - [Simon-Hoiberg](entities/Simon-Hoiberg.md) - [Slack](entities/Slack.md) @@ -884,15 +898,18 @@ - [SONY](entities/SONY.md) - [Sora](entities/Sora.md) - [SparkryAI](entities/SparkryAI.md) -- [Spot-Invaders](entities/Spot-Invaders.md) — EKS + Spot 实例容错混沌工程游戏 +- [Spot-Invaders](entities/Spot-Invaders.md) - [Sprint-Prioritizer](entities/Sprint-Prioritizer.md) - [SRE-Team](entities/SRE-Team.md) - [SSE](entities/SSE.md) - [Stable-Diffusion](entities/Stable-Diffusion.md) - [stacer](entities/stacer.md) +- [Steele-Taylor](entities/Steele-Taylor.md) +- [Stephen-Frank](entities/Stephen-Frank.md) - [SteveJarman](entities/SteveJarman.md) - [Studio-Producer](entities/Studio-Producer.md) - [Supermemory](entities/Supermemory.md) +- [Suraav-Paul](entities/Suraav-Paul.md) - [Suravpul](entities/Suravpul.md) - [SurfSense](entities/SurfSense.md) - [Swinford.net](entities/Swinford.net.md) @@ -904,6 +921,7 @@ - [Terraform](entities/Terraform.md) - [TerraGrant](entities/TerraGrant.md) - [Terragrunt](entities/Terragrunt.md) +- [TF-State-Bucket-Accessor](entities/TF-State-Bucket-Accessor.md) - [The-Agency](entities/The-Agency.md) - [The-DAO-2016](entities/The-DAO-2016.md) - [Thoth](entities/Thoth.md) @@ -1068,6 +1086,7 @@ - [arXiv-API](concepts/arXiv-API.md) - [Asset-Management](concepts/Asset-Management.md) - [Asset-Pipeline](concepts/Asset-Pipeline.md) +- [Assume-Role](concepts/Assume-Role.md) - [Atomic-Commit](concepts/Atomic-Commit.md) - [Attachment-Theory](concepts/Attachment-Theory.md) - [Attach容器](concepts/Attach容器.md) @@ -1085,6 +1104,8 @@ - [AWS-Firewall-Manager](concepts/AWS-Firewall-Manager.md) - [AWS-Identity-Center](concepts/AWS-Identity-Center.md) - [AWS-Inspector](concepts/AWS-Inspector.md) +- [AWS-Instance-Scheduler](concepts/AWS-Instance-Scheduler.md) +- [AWS-Nitro](concepts/AWS-Nitro.md) - [AWS-Secrets-Manager](concepts/AWS-Secrets-Manager.md) - [AWS-Service-Catalog](concepts/AWS-Service-Catalog.md) - [AWS-Source-Identity](concepts/AWS-Source-Identity.md) @@ -1102,6 +1123,7 @@ - [Big-Five-Personality](concepts/Big-Five-Personality.md) - [BindMount](concepts/BindMount.md) - [BI平台](concepts/BI平台.md) +- [Blast-Radius](concepts/Blast-Radius.md) - [Blocking](concepts/Blocking.md) - [Blockout-Discipline](concepts/Blockout-Discipline.md) - [Bloom-认知分类](concepts/Bloom-认知分类.md) @@ -1145,6 +1167,7 @@ - [CheckinFatigue](concepts/CheckinFatigue.md) - [ChinaLaborLawCompliance](concepts/ChinaLaborLawCompliance.md) - [Choice-Architecture](concepts/Choice-Architecture.md) +- [Choreography](concepts/Choreography.md) - [CI-CD-Pipeline](concepts/CI-CD-Pipeline.md) - [CI-CD-Secrets](concepts/CI-CD-Secrets.md) - [CICDPipeline](concepts/CICDPipeline.md) @@ -1175,6 +1198,7 @@ - [Cloud-Service-Delivery](concepts/Cloud-Service-Delivery.md) - [CloudHealth](concepts/CloudHealth.md) - [CloudWatch-Agent](concepts/CloudWatch-Agent.md) +- [CloudWatch-Events](concepts/CloudWatch-Events.md) - [Cluster-Autoscaler](concepts/Cluster-Autoscaler.md) - [CMDB](concepts/CMDB.md) - [Cockpit-Ergonomics](concepts/Cockpit-Ergonomics.md) @@ -1187,6 +1211,7 @@ - [Command-Theater-Interface](concepts/Command-Theater-Interface.md) - [Community-Credibility](concepts/Community-Credibility.md) - [Compaction](concepts/Compaction.md) +- [Competing-Consumer-Pattern](concepts/Competing-Consumer-Pattern.md) - [Competition-Analysis](concepts/Competition-Analysis.md) - [CompletionRate](concepts/CompletionRate.md) - [Compliance-Automation](concepts/Compliance-Automation.md) @@ -1231,6 +1256,7 @@ - [Credential-Isolation](concepts/Credential-Isolation.md) - [Credit-Efficient-Processing](concepts/Credit-Efficient-Processing.md) - [Cron定时任务](concepts/Cron定时任务.md) +- [cross-account-json](concepts/cross-account-json.md) - [Cross-Account-Monitoring](concepts/Cross-Account-Monitoring.md) - [Cross-account-Terraform-Modules](concepts/Cross-account-Terraform-Modules.md) - [Cross-Platform-Strategy](concepts/Cross-Platform-Strategy.md) @@ -1295,20 +1321,22 @@ - [DRY原则](concepts/DRY原则.md) - [DuckDB](concepts/DuckDB.md) - [Dynamic-Dashboard](concepts/Dynamic-Dashboard.md) +- [DynamoDB-Config-Table](concepts/DynamoDB-Config-Table.md) - [EA-SA-TA-Framework](concepts/EA-SA-TA-Framework.md) - [Early-Live-Support](concepts/Early-Live-Support.md) - [Earnings-Beat-Miss](concepts/Earnings-Beat-Miss.md) - [Earnings-Calendar](concepts/Earnings-Calendar.md) - [EC2-Purchase-Options](concepts/EC2-Purchase-Options.md) -- [EC2-Spot-Instances](concepts/EC2-Spot-Instances.md) — 竞价实例，Spot 折扣高达 90% +- [EC2-Spot-Instances](concepts/EC2-Spot-Instances.md) - [Economy-Balance](concepts/Economy-Balance.md) +- [ECS](concepts/ECS.md) +- [ECS-Deploy-Runner](concepts/ECS-Deploy-Runner.md) +- [ECS-Module](concepts/ECS-Module.md) - [efibootmgr](concepts/efibootmgr.md) - [EFS-vs-EBS](concepts/EFS-vs-EBS.md) - [EKS-Auto-Mode](concepts/EKS-Auto-Mode.md) - [EKS-Custom-Networking](concepts/EKS-Custom-Networking.md) -- [AWS-Nitro](concepts/AWS-Nitro.md) — AWS 虚拟化平台，网络/存储/安全组件外部化 - [ELK-Stack](concepts/ELK-Stack.md) -- [ECS](concepts/ECS.md) — Amazon Elastic Container Service，托管容器编排 - [Email-Triage](concepts/Email-Triage.md) - [Embedding](concepts/Embedding.md) - [Emergency-Change](concepts/Emergency-Change.md) @@ -1338,6 +1366,7 @@ - [Fact-Recall-vs-Compounding](concepts/Fact-Recall-vs-Compounding.md) - [Fail-Closed](concepts/Fail-Closed.md) - [Failover](concepts/Failover.md) +- [Fan-Out-Pattern](concepts/Fan-Out-Pattern.md) - [Feature-Flag](concepts/Feature-Flag.md) - [FeatureList](concepts/FeatureList.md) - [Federated-Access](concepts/Federated-Access.md) @@ -1346,6 +1375,7 @@ - [FIA-Framework](concepts/FIA-Framework.md) - [File-System-First-UI](concepts/File-System-First-UI.md) - [File-Watcher](concepts/File-Watcher.md) +- [Fine-Tuning](concepts/Fine-Tuning.md) - [FinOps](concepts/FinOps.md) - [Five-Phase-Script-Framework](concepts/Five-Phase-Script-Framework.md) - [Fix-Pack](concepts/Fix-Pack.md) @@ -1354,6 +1384,7 @@ - [FluentBit](concepts/FluentBit.md) - [Food-Sensitivity-Tracking](concepts/Food-Sensitivity-Tracking.md) - [Foundation-AMI](concepts/Foundation-AMI.md) +- [Foundation-Models](concepts/Foundation-Models.md) - [frp](concepts/frp.md) - [Fstab](concepts/Fstab.md) - [Full-Draft-Generation](concepts/Full-Draft-Generation.md) @@ -1422,6 +1453,7 @@ - [ICP-Ideal-Customer-Profile](concepts/ICP-Ideal-Customer-Profile.md) - [Idea-Density](concepts/Idea-Density.md) - [Idea-Museum](concepts/Idea-Museum.md) +- [Idempotency](concepts/Idempotency.md) - [Identity-Governance](concepts/Identity-Governance.md) - [Identity-Resolution](concepts/Identity-Resolution.md) - [IDENTITY.md](concepts/IDENTITY.md.md) @@ -1439,6 +1471,7 @@ - [Infoblox-Grid](concepts/Infoblox-Grid.md) - [Infoblox-NIOS](concepts/Infoblox-NIOS.md) - [Infrastructure-as-Code](concepts/Infrastructure-as-Code.md) +- [InfrastructureAsCode](concepts/InfrastructureAsCode.md) - [Inline-Layer](concepts/Inline-Layer.md) - [Innovation-Pipeline](concepts/Innovation-Pipeline.md) - [IntegrationGovernance](concepts/IntegrationGovernance.md) @@ -1530,6 +1563,7 @@ - [Micro-Recovery](concepts/Micro-Recovery.md) - [MicroInfluencerPartnership](concepts/MicroInfluencerPartnership.md) - [Miping](concepts/Miping.md) +- [MLOps](concepts/MLOps.md) - [ModalContextProtocol](concepts/ModalContextProtocol.md) - [Model-Context-Protocol](concepts/Model-Context-Protocol.md) - [Model-Fallback](concepts/Model-Fallback.md) @@ -1589,11 +1623,13 @@ - [OpenTelemetry](concepts/OpenTelemetry.md) - [OpenText-Tagging-Standard](concepts/OpenText-Tagging-Standard.md) - [Oracle-Manipulation](concepts/Oracle-Manipulation.md) +- [Orchestration](concepts/Orchestration.md) - [Ordered-Layer](concepts/Ordered-Layer.md) - [Organic-Traffic-Amplification](concepts/Organic-Traffic-Amplification.md) - [OS-End-of-Life](concepts/OS-End-of-Life.md) - [OS-Hardening](concepts/OS-Hardening.md) - [Overlay-Network](concepts/Overlay-Network.md) +- [Override-Status](concepts/Override-Status.md) - [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md) - [Pacing-Architecture](concepts/Pacing-Architecture.md) - [PagedAttention](concepts/PagedAttention.md) @@ -1661,6 +1697,7 @@ - [ProjectState](concepts/ProjectState.md) - [Prometheus告警规则](concepts/Prometheus告警规则.md) - [Prompt](concepts/Prompt.md) +- [Prompt-Engineering](concepts/Prompt-Engineering.md) - [PromQL](concepts/PromQL.md) - [Proof-of-Concept](concepts/Proof-of-Concept.md) - [Propp-Morphology](concepts/Propp-Morphology.md) @@ -1680,6 +1717,7 @@ - [RACI](concepts/RACI.md) - [RAG](concepts/RAG.md) - [Rate-Limiting](concepts/Rate-Limiting.md) +- [RDS-Maintenance-Window](concepts/RDS-Maintenance-Window.md) - [Reality-Signal](concepts/Reality-Signal.md) - [RealityKit-SwiftUI-Integration](concepts/RealityKit-SwiftUI-Integration.md) - [RealitySignal](concepts/RealitySignal.md) @@ -1709,6 +1747,7 @@ - [Resolver-Rules](concepts/Resolver-Rules.md) - [Resource-Allocation](concepts/Resource-Allocation.md) - [Resource-Tagging](concepts/Resource-Tagging.md) +- [Responsible-AI](concepts/Responsible-AI.md) - [ResponsiveSearchAds](concepts/ResponsiveSearchAds.md) - [Retrieval](concepts/Retrieval.md) - [Reviewer](concepts/Reviewer.md) @@ -1719,6 +1758,7 @@ - [ROI](concepts/ROI.md) - [Rollback-Rate](concepts/Rollback-Rate.md) - [Root-Cause-Analysis](concepts/Root-Cause-Analysis.md) +- [Root-Terragrunt-HCL](concepts/Root-Terragrunt-HCL.md) - [Route-53-Resolver](concepts/Route-53-Resolver.md) - [RPC-Remote-Procedure-Call](concepts/RPC-Remote-Procedure-Call.md) - [RPO](concepts/RPO.md) @@ -1782,6 +1822,7 @@ - [Shader](concepts/Shader.md) - [ShadowTraffic](concepts/ShadowTraffic.md) - [SHAP](concepts/SHAP.md) +- [Shared-Account](concepts/Shared-Account.md) - [Shared-Memory-Architecture](concepts/Shared-Memory-Architecture.md) - [Shared-Responsibility-Model](concepts/Shared-Responsibility-Model.md) - [SharedMemory](concepts/SharedMemory.md) @@ -1854,6 +1895,7 @@ - [T-Shaped-Skills](concepts/T-Shaped-Skills.md) - [Tag-Validation-Tool](concepts/Tag-Validation-Tool.md) - [TagBasedIndexing](concepts/TagBasedIndexing.md) +- [Tagging](concepts/Tagging.md) - [TAIL-Strategy](concepts/TAIL-Strategy.md) - [Task-Query](concepts/Task-Query.md) - [TaskAutomation](concepts/TaskAutomation.md) @@ -1872,10 +1914,12 @@ - [Template-Based-Production](concepts/Template-Based-Production.md) - [Terraform-IaC](concepts/Terraform-IaC.md) - [Terraform-Modules](concepts/Terraform-Modules.md) +- [TerraformState](concepts/TerraformState.md) - [Test-Mode](concepts/Test-Mode.md) - [Text-and-Search](concepts/Text-and-Search.md) - [TextToSpeech](concepts/TextToSpeech.md) - [TextToVideo](concepts/TextToVideo.md) +- [TF-State-Bucket-Accessor](concepts/TF-State-Bucket-Accessor.md) - [TGW-Peering](concepts/TGW-Peering.md) - [Third Party Penetration Testing](concepts/Third Party Penetration Testing.md) - [Thought-Leadership](concepts/Thought-Leadership.md) diff --git a/wiki/log.md b/wiki/log.md index 6cdae037..82f2cc99 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,88 @@ +## [2026-05-15] ingest | Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md +- Status: ✅ 成功摄入（已存在，更新 + 修复） +- Summary: 通过 Terraform IaC 实现 ECS 容器化应用的自动化部署——JP 和 Raja M 主讲，CTP/SRE 团队基于 Gruntwork 构建 ECS Terraform 模块，支持 Docker 容器/EC2 部署，具备自动扩缩容、自动故障恢复、金丝雀部署能力；采用 Listener 集中管理方式；前置条件包括 VPC、ELB 安全组和 EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus +- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md（已存在，更新了 Connections 节的 self-reference bug 并追加新连接） +- Entities created: JP.md（CTP 讲师，ECS 业务/技术背景介绍）、Raja-M.md（CTP/SRE 成员，ECS 模块构建者）、CTP-SRE-Team.md（CTP/SRE 团队）、AWS.md（更新 sources 引用）、Gruntwork.md（更新 sources 引用） +- Entities already existed: cloud-transformation-programme.md（index.md 第 642 行，已包含本来源引用）、Gruntwork.md（index.md 第 720 行，已追加来源引用）、AWS.md（index.md 第 583 行，已追加来源引用） +- Concepts created/updated: Canary-Deployment.md（新建，金丝雀部署策略）、ECS-Module.md（新建，ECS Terraform 模块）、InfrastructureAsCode.md（追加来源引用） +- Concepts already existed: Infrastructure-as-Code.md（index.md 第 1469 行）、Canary-Deployment.md（index.md 第 1150 行） +- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 存在，修复第 46 行 self-reference bug 并追加与 learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform 的关联；步骤4完成：index.md 第 302 行已有条目；追加 CTP-SRE-Team/JP/Raja-M 至 Entities 节，追加 ECS-Module 至 Concepts 节；步骤5完成：overview.md 第 255 行已有该来源综合摘要，无需修订；步骤6完成：新建4个 Entity 页面（JP/Raja-M/CTP-SRE-Team/AWS/Gruntwork 追加来源），更新 index.md Entities 节；步骤7完成：新建 Canary-Deployment.md/ECS-Module.md Concept 页面，更新 InfrastructureAsCode.md sources 引用，更新 index.md Concepts 节；步骤8完成：与 ctp-topic-64_scaling-out-with-amazon-eks 存在容器编排选型差异已在 Contradictions 节记录；步骤9完成：log.md 追加记录 + +## [2026-05-15] ingest | CTP Topic 16 Cross-account Terraform modules +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules.md +- Status: ✅ 成功摄入 +- Summary: 跨账号 Terraform 模块的中心化部署方案——基于 Shared Account 作为中转站，Jenkins 检测 cross-account.json 标记文件触发 ECS Deploy Runner，通过 Assume Role 访问目标账号的 TF State Bucket Accessor 和 Cross-account ECS Deploy Runner Role 两个角色，实现安全性（账号间无直接信任）、自动化（Jenkins 自动识别模块类型）、可复用性（模块不硬编码特定账号角色） +- Concepts created/updated: Cross-account-Terraform-Modules.md（已存在，补充 Source 引用）, ECS-Deploy-Runner.md（entities+concepts 双页）, Shared-Account.md（entities+concepts 双页）, TF-State-Bucket-Accessor.md（entities+concepts 双页）, Assume-Role.md, Blast-Radius.md, Root-Terragrunt-HCL.md, cross-account-json.md +- Entities created: Fibos.md, ECS-Deploy-Runner.md（entities 页）, Shared-Account.md（entities 页）, TF-State-Bucket-Accessor.md（entities 页）, Cross-account-ECS-Deploy-Runner-Role.md +- Source page: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md（已存在且格式完整） +- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 已存在无需重建；步骤4完成：index.md 第302行已有条目；步骤5完成：overview.md 无需修订（source page 已有完整摘要）；步骤6完成：新建5个 Entity 页面（Fibo/ECS-Deploy-Runner/Shared-Account/TF-State-Bucket-Accessor/Cross-account-ECS-Deploy-Runner-Role）并更新 index.md Entities 节；步骤7完成：新建8个 Concept 页面并更新 index.md Concepts 节；步骤8完成：无内容冲突（与 Gruntwork/Atlantis 为演进关系）；步骤9完成：log.md 追加记录 + +## [2026-05-13] ingest | CTP Topic 48 Terraform vs Terragrunt +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md +- Status: ✅ 成功摄入 +- Summary: Terraform 与 Terragrunt 深度对比——Terraform（HashiCorp）通过状态文件将期望状态绑定到实际环境，支持多云；Terragrunt 轻量封装践行 DRY 原则，管理 provider/remote_state 块减少跨环境重复声明；两者命令语法完全一致；辅助工具链：Terraform Enterprise、Gruntwork、Atlantis、tfsec、Terratest +- Concepts created: InfrastructureAsCode.md, TerraformState.md +- Entities created: HashiCorp.md, Gruntwork.md, Atlantis.md +- Entities already existed: HashiCorp（index.md 第720行）、Gruntwork（index.md 第717行）、Atlantis（index.md 第582行） +- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md +- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第301行已有条目，无需重复添加；步骤5完成：overview.md 第253行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 HashiCorp.md/Gruntwork.md/Atlantis.md Entity 页面（HashiCorp/Gruntwork/Atlantis 在 index.md 中已存在，故在各自页面内追加 sources 引用）；步骤7完成：新建 InfrastructureAsCode.md/TerraformState.md Concept 页面，index.md Concepts 节追加对应条目；步骤8完成：无冲突；步骤9完成：log.md 追加记录 + +## [2026-05-12] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md +- Status: ✅ 成功摄入 +- Summary: 事件驱动架构（EDA）进阶最佳实践与团队协作模式——三组件（生产者/消费者/代理）、Event Router vs Event Store、Choreography vs Orchestration、幂等性、事件排序（SQS FIFO/Kinesis）、去中心化团队所有权、Fan-out 模式（SNS/EventBridge）、竞争消费者模式（Compete Consumer）、死信队列（DLQ）和 EventBridge 最佳实践 +- Concepts created: Event-Driven-Architecture.md, Idempotency.md, Fan-Out-Pattern.md, Competing-Consumer-Pattern.md, Choreography.md, Orchestration.md +- Entities created: Anil-Giri.md, AWS-EventBridge.md +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md +- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第296行已有条目，补充日期前缀（2024-09-17）和一行摘要；步骤5完成：overview.md 第407行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Anil-Giri.md/AWS-EventBridge.md Entity 页面，index.md Entities 节追加 Anil-Giri/AWS-EventBridge；步骤7完成：新建 Event-Driven-Architecture/Idempotency/Fan-Out-Pattern/Competing-Consumer-Pattern/Choreography/Orchestration 共6个 Concept 页面，index.md Concepts 节追加对应条目；步骤8完成：无冲突（Part 2 与 Part 1 为互补关系）；步骤9完成：log.md 追加记录 + +## [2026-05-12] ingest | Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md +- Status: ✅ 成功摄入 +- Summary: AWS 生成式 AI 服务生态与 Prompt Engineering 实践——OpenText 技术客户经理 Shikad Holtzman 主讲；生成式 AI 四大价值路径、AWS 三层技术栈；数据是差异化关键；Bedrock（RAG/微调/Agents/Guardrails）+ Amazon Q（Business/Developer）；Prompt Engineering 四大组件与 One-shot/Few-shot/Chain-of-Thought 技巧 +- Concepts created: Prompt-Engineering.md +- Entities created: Shikad-Holtzman.md, Amazon-Q.md, Anthropic.md, Meta-AI.md +- Entities updated: Amazon-Bedrock.md（追加来源引用） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md +- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第295行已有条目（2026-04-28 先前摄入痕迹），无需重复添加；步骤5完成：overview.md 第401行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Shikad-Holtzman.md/Amazon-Q.md/Anthropic.md/Meta-AI.md Entity 页面，更新 Amazon-Bedrock.md 追加来源引用；步骤7完成：新建 Prompt-Engineering.md Concept 页面；步骤8完成：记录与 llms-rag-ai-agent-三个到底什么区别 的 RAG 运维复杂度视角冲突；步骤9完成：log.md 追加记录 + +## [2026-05-12] ingest | Public Cloud Learning Sessions (OpenText) - Serverless Computing - 20240903 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md +- Status: ✅ 成功摄入 +- Summary: AWS 无服务器计算深度解析——OpenText 主办，聚焦 AWS Lambda（事件驱动/权限模型/版本/Layers/ARM64）、Step Functions（状态机/Standard&Express）、API Gateway（边缘优化/区域/私有）和 SAM（基于 CloudFormation 的本地开发和部署工具） +- Concepts: 无新 Entity 页面创建（Lambda/Step Functions/API Gateway/SAM 为 AWS 官方服务，overview.md 已有充分描述） +- Entities: 无新 Entity 页面创建（同上） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md +- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第293行添加日期前缀（2024-09-03）和中文摘要；步骤5完成：overview.md 第405行已有该来源详细综合摘要，内容一致无需修订；步骤6-7完成：无需创建新 Entity/Concept 页面（AWS 官方服务 overview 已有描述）；步骤8完成：无冲突（与 EDA Part 1/2 共享事件驱动模型属互补关系）；步骤9完成：log.md 追加记录 + +## [2026-05-12] ingest | Public Cloud Learning Sessions - Introduction to AI/ML with AWS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md +- Status: ✅ 成功摄入 +- Summary: AWS AI/ML 入门——Suraav Paul（AWS 高级解决方案架构师）主讲，AI 三层分类（分类 AI/预测 AI/生成式 AI）、Amazon Bedrock 全托管生成式 AI 服务（基础模型+微调+RAG+Agents+Guardrails）、ML Ops 三管道（数据/训练/推理）；强调 Bedrock 数据隐私保证和负责任 AI 六大原则 +- Concepts created: Foundation-Models.md, MLOps.md, Responsible-AI.md +- Entities created: Suraav-Paul.md, Amazon-SageMaker.md, Amazon-Titan.md +- Entities updated: Amazon-Bedrock.md（追加来源引用） +- Source page: wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md +- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行添加日期前缀和摘要；步骤5完成：overview.md 第399行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Suraav-Paul.md/Amazon-SageMaker.md/Amazon-Titan.md Entity 页面，更新 Amazon-Bedrock.md 追加来源引用；步骤7完成：新建 Foundation-Models.md/MLOps.md/Responsible-AI.md Concept 页面，index.md Entities 节追加 Amazon-SageMaker/Amazon-Titan/Suraav-Paul，Concepts 节追加 Foundation-Models/Responsible-AI/MLOps；步骤8完成：无冲突；步骤9完成：log.md 追加记录 + +## [2026-05-12] ingest | Cloud Learning Master Index +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md +- Status: ✅ 成功摄入 +- Summary: Cloud Learning Master Index — Public Cloud Learning Sessions 全部111个视频的分类索引目录（10大类：AWS Landing Zone 22、OpenText Series 21、EKS & Kubernetes 14、Security 9、Networking 9、Serverless & AI 9、FinOps & Cost 10、CI/CD & GitOps 8、IAM & Identity 3、Terraform & IaC 6） +- Entities created: （无新建 — Gruntwork/Grafana/Karpenter/Bottlerocket 等将在子视频 source pages 摄入时创建） +- Source page: wiki/sources/cloud-learning-master-index.md +- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第291行补充日期前缀和一行摘要；步骤5完成：overview.md 第219行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：无需新建 Entity（OpenText.md/MicroFocus.md/Atlantis.md 等已存在；Gruntwork/Grafana/Karpenter 等将在子视频 source pages 摄入时创建）；步骤7完成：无需新建 Concept（FinOps.md/GitOps.md/Karpenter.md 等已存在；Landing-Zone/EKS/Terraform/IAM 等作为顶层框架将在子视频 source pages 摄入时精确定义）；步骤8完成：记录与 ctp-topic-34-azure-landing-zone-architecture-overview 的跨平台差异冲突；步骤9完成：log.md 追加记录 + +## [2026-05-12] ingest | CTP Topic 27 AWS Instance Scheduler +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md +- Status: ✅ 成功摄入 +- Summary: AWS Instance Scheduler — 通过 CloudWatch Events 每15分钟触发 Lambda → 读取 DynamoDB 调度配置 → 根据实例标签（Schedule/Period/Override）自动启停 EC2/RDS；CCOE Guardrails 框架自动部署，覆盖月消费10美元以上 AWS 账号；RDS 维护窗口智能配合； Gustavo 主讲 +- Concepts created: AWS-Instance-Scheduler.md, CloudWatch-Events.md, DynamoDB-Config-Table.md, Tagging.md, RDS-Maintenance-Window.md, Override-Status.md +- Entities created/updated: Gustavo.md（新建）, Godrails.md（已有，更新添加 Topic 27 来源和详情） +- Source page: wiki/sources/ctp-topic-27-aws-instance-scheduler.md +- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行添加日期前缀和摘要；步骤5完成：overview.md 第389行已有该来源详细摘要，内容一致无需修订；步骤6完成：新建 Gustavo.md Entity 页面，更新 Godrails.md（含 Aliases、Topic 13+27 来源、Guardrails 机制详情）；删除错误创建的 Guardrails.md（与 Godrails 为同一实体）；步骤7完成：新建 AWS-Instance-Scheduler/CloudWatch-Events/DynamoDB-Config-Table/Tagging/RDS-Maintenance-Window/Override-Status 共6个 Concept 页面；步骤8完成：无冲突（与 Topic 13/63 引用一致的 instance scheduler FinOps 策略）；步骤9完成：log.md 追加记录 + ## [2026-05-12] ingest | Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529 - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md - Status: ✅ 成功摄入 @@ -2719,6 +2804,18 @@ - Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md - Notes: 视频由 Gemini 摘要，原文状态为 "summarized (Gemini 摘要)"；来源 NAS 路径为 `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 48_ Terraform vs Terragrunt.mp4` +## [2026-05-12] ingest (complete) | Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md +- Status: ✅ 成功摄入（完整版，含 Entity/Concept 页面创建） +- Summary: AWS AI 专家 Stephen Frank 分享 Gen2 生成式 AI 落地实践——AI 四代演进、Gen2 崛起两大驱动力（数据爆发+算力）、通用/企业 AI 应用场景、数据整合三大方法（RAG/Fine-tuning/持续预训练）、AWS 三层产品战略（基础设施/Bedrock/AI 应用）、负责任 AI 原则 +- Concepts created: Fine-Tuning.md +- Entities created: Stephen-Frank.md +- Entities updated: Amazon-Bedrock.md、Amazon-Q.md、Amazon-SageMaker.md（均追加来源引用） +- Concepts updated: Foundation-Models.md、Responsible-AI.md（均追加来源引用） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md +- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行已有条目，补充日期前缀（2024-11-26）和一行摘要；步骤5完成：overview.md 第403行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Stephen-Frank.md Entity 页面，更新 Amazon-Bedrock.md/Amazon-Q.md/Amazon-SageMaker.md 追加来源引用，index.md Entities 节追加 Stephen-Frank；步骤7完成：新建 Fine-Tuning.md Concept 页面，更新 Foundation-Models.md/Responsible-AI.md 追加来源引用，index.md Concepts 节追加 Fine-Tuning；步骤8完成：记录与 Generative AI & Prompt Engineering 分享的视角冲突（数据整合 vs Prompt Engineering）；步骤9完成：log.md 追加记录 +- Conflicts: 与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md]] 视角差异——Stephen Frank 强调数据整合是差异化关键；Prompt Engineering 分享更侧重技巧本身；当前观点：两者互补，数据整合决定 AI 能说什么，Prompt Engineering 决定 AI 怎么说 + ## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106 - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md - Status: ✅ 成功摄入 @@ -2784,7 +2881,16 @@ - Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（FinOps 章节新增段落，置于 ctp-topic-63 后）；已建立与 ctp-topic-13（政策框架）、ctp-topic-63（Terraform Scheduler 互补）、ctp-topic-71（RightSizing 互补）的 Connections 关系；冲突记录：与 ctp-topic-63 在实现路径上的差异（AWS 原生 vs Terraform 层）已于 Contradictions 节说明为互补而非互斥 - Conflicts: 与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 就 EC2/RDS 自动调度的实现路径差异——Instance Scheduler（AWS 原生方案）覆盖广账户层，Terraform Scheduler（IaC 层）提供细粒度控制，两者互补而非互斥 -## [2026-04-25] ingest | CTP Topic 63 Optimise resource cost using automation +## [2026-04-30] ingest | Public Cloud Learning Sessions - Budget Control - 20240319 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md +- Status: ✅ 成功摄入 +- Summary: AWS 账户预算控制自动化解决方案 — 通过 AWS Budget + SNS + Lambda + Step Functions 实现多层级告警（forecast/actual/severe/enforcement）和 SCP 强制执行，引入评分系统和宽限期避免误罚，支持细粒度资源级和用户级成本可视化 +- Concepts created: FinOps, AWS Budget Service, Service Control Policy (SCP), Source Identity, Scoring System, Grace Period +- Entities mentioned: Daniela, Evan, Alan, Daniel, Oli, FinOps Team, SRE Core Team +- Source page: wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md +- Notes: Source Identity 属性可在多角色切换场景下追踪原始登录身份；Top Services Report 数据来源于 Athena，Top Users Report 数据来源于 Cost Explorer；预算评估每 8 小时执行一次 + +## [2026-04-29] ingest | CTP Topic 63 Optimise resource cost using automation - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-63-optimise-resource-cost-using-automation.md - Status: ✅ 成功摄入 - Summary: 使用自动化手段优化 AWS 云资源成本——五大策略：批准区域标准化、Graviton ARM 实例选型（比 Intel 便宜 20-25%）、承诺计划（1年 40% / 3年 64% 折扣）、GP2→GP3 存储优化（节省 20%）、基于标签的 EC2/RDS 自动化调度（每天只运行 10 小时可节省 70% 成本） @@ -6240,3 +6346,12 @@ - Entities created: [[CCLE]], [[CyberArk]] - Source page: wiki/sources/ctp-topic-37-secrets-certificates-management.md - Notes: 步骤3完成：规范化 Source 页面 Key Concepts/Key Entities 引用格式，修正 HashiCorp-Vault（应属 Entity 而非 Concept）；步骤4完成：index.md 条目已存在（第279行），无需更新；步骤5完成：overview.md 补充 Topic 37 独立条目（与 Topic 62 构成"评估→实施"两阶段链路）；步骤6完成：新建2个 Entity 页面（CCLE.md、CYBERArk.md）；步骤7完成：新建2个 Concept 页面（Privileged-Access-Management.md、CI/CD-Secrets.md）；步骤8完成：与 [[ctp-topic-62-aws-secrets-manager]] 存在视角差异但非冲突（前者快速试点 vs 后者深度实施），已在 Contradictions 节记录；步骤9完成：log.md 追加记录 + +## [2026-05-13] ingest | Learning Sessions ECS Deployment using IAC - 20230808（重新摄入） +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md +- Status: ✅ 成功摄入 +- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容（Auto Scaling）、自动故障恢复（Auto Healing）、金丝雀部署（Canary Deployment）；通过 Listener 方式集中管理（避免各产品团队重复下载 Gruntwork 代码）；前置条件：VPC、ELB 安全组、EFS 卷挂载；配置通过 YAML/JSON 传递；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成，适合 AWS 优先策略。 +- Concepts updated: [[ECS]]（追加来源引用） +- Entities updated: [[SRE-Team]]（追加来源引用，说明 ECS Terraform 模块设计与维护职责） +- Source page: wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md +- Notes: 本次为重新规范化摄入（该来源已于 2026-05-05 初次摄入，source page 格式已符合当前规范）。步骤3完成：source page 已存在，验证内容符合规范（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第299行条目已存在，补充日期前缀（2023-08-08）和中文摘要；步骤5完成：overview.md 第255行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：[[ECS]] 追加来源引用，[[SRE-Team]] 追加来源引用（ECS Terraform 模块设计与维护）；无需新建 Entity 页面（JP 和 Raja M 各出现 1 次，不足建页阈值，以 wikilink 形式记录于 Source page）；步骤7完成：[[Canary-Deployment]] 已有来源引用，无需更新；步骤8完成：ECS vs EKS 冲突已在 Contradictions 节记录，无需新增；步骤9完成：log.md 追加记录 diff --git a/wiki/overview.md b/wiki/overview.md index 2e8cb25e..9dc7c6a5 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -266,7 +266,7 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **[[ctp-topic-24-micro-focus-product-privacy-framework]]**（CTP Topic 24）：Micro Focus 产品隐私框架在云转型中的应用——PSAC（产品安全顾问委员会）与法律顾问合作，将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求；隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一；通过五类需求（架构类/文档类/法律类/实现类/SAS 运营类）和成熟度模型（0-4 级）评估产品隐私合规状态；通过"蜘蛛图"直观展示产品在安全去标识化、被遗忘权、数据可移植性等 KPI 上的合规现状；最终产出标准化《产品隐私设置文档》，确保客户获得一致的隐私信息参考。属 [[Product Privacy Framework（产品隐私框架）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[Micro Focus Security Development Life Cycle (STLC) Overview]]（STLC 整体架构）直接关联。 -**[[ctp-topic-49-container-lifecycle-hardening-standards]]**（CTP Topic 49）： +**[[ctp-topic-49-container-lifecycle-hardening-standards]]**（CTP Topic 49）：Micro Focus Product Security Group 制定的容器镜像构建阶段安全加固标准——由 Ashish 主讲，聚焦容器生命周期的 Build 阶段。涵盖 11 项安全标准：①使用 Micro Focus 基础镜像（配置为安全模式，无可信/非可信组件混合）；②集成 Init 系统（tini/teeny）防止僵尸进程；③镜像不含敏感信息，改用 Kubernetes Secrets 运行时注入；④设置 readOnlyRootFilesystem=true 阻止恶意写入；⑤使用 emptyDir 卷替代 hostPath 确保 Pod 删除时数据清理；⑥镜像扫描发现 CVE；⑦单应用容器化防止进程干扰；⑧禁用 Kubernetes API 访问（automountServiceAccountToken=false）；⑨使用私有服务账号配合 RBAC；⑩避免 host 网络；⑪避免 host 端口。属 [[Container Security]] 在 [[Micro Focus]] 企业云场景的核心实践，与 [[ctp-topic-21-supply-chain-security-in-micro-focus]]（供应链安全）和 [[ctp-topic-37-secrets-certificates-management]]（密钥管理）共同构成 Micro Focus 安全体系，与 [[Bottlerocket]] 的操作系统层加固互补。 **[[public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]]**（Public Cloud Learning Sessions，EKS 计算优化专题 Part 2）：Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版，核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。属 [[Bottlerocket]] 在 [[Amazon EKS]] 场景的核心实践，与 Part 1（Karpenter 计算优化）和 Part 3（EKS Auto Mode）共同构成 EKS 优化三专题完整链路；Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统。 @@ -348,6 +348,8 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast **[[ctp-topic-36-sendgrid-as-an-email-service]]**（CTP Topic 36）：SendGrid 被选定为经典和新 Landing Zone 的标准邮件服务，替换现有语义消息网关（Port 25 不安全、即将停用本地网络）和 SES（每封限制 50 收件人）。SendGrid 支持每封最多 1,000 收件人、全云兼容、TLS 端到端加密和双因素认证；支持计划覆盖每月 500 万封邮件；提供直连 SendGrid（需 TLS）和中继服务器（不支持 TLS 的应用）两种架构，数据通过全球中继节点（伦敦/印度/东京）走私有线路汇至美国数据中心。配置要求：使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587、启用 TLS；SPF/DKIM 记录为邮件送达必要条件；API 密钥每 180 天轮换，日志保留 7 天。同期 Yu-Yan 分享了 Cyber Suite 加密标准更新，涵盖 FIPS/Java/Golang/Node.js/OpenCell 等行业标准合规模件，可选套件因包含 CBC 模式（弱加密）仅作向后兼容，使用非标准套件的产品需经 PSAC 审查。属 [[AWS-Landing-Zone]] 通信层基础组件，与 [[ctp-topic-37-secrets-certificates-management]] 同属安全运维范畴。 +**[[ctp-topic-37-secrets-certificates-management]]**（CTP Topic 37）：CCLE 团队主导的密钥与证书管理解决方案选型——2022年3月起探索 Micro Focus 用例并评估密钥管理方案。评估了三款产品：AWS Secrets Manager（托管服务，原生集成 RDS/Redshift/DynamoDB，按用量计费，支持高可用和 DR）、HashiCorp Vault（企业版自托管，云厂商无关，支持动态密钥和嵌入式证书签名，按用户数收费，但免费版缺乏 HA 和多租户）、CyberArk Micro Focus PAM（因需大量投资才能具备竞争力且缺乏投资计划而被放弃）。30天试点结论：AWS Secrets Manager 以"easy and simple to implement"胜出，同时识别出缺失功能（SSH 密钥轮换、用户集成密码轮换）；AWS 在账户级别管理密钥可降低成本并提升安全性。实施阶段从 Control Tower 开始，从 CI/CD 流程清除明文密码和密钥，集中化存储并自动化密钥获取。属 [[SecretsManagement]] 选型评估阶段的原始记录，与 [[ctp-topic-62-aws-secrets-manager]]（企业级深度实施）构成 Secrets 管理知识体系的"评估→实施"两阶段完整链路。 + **[[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]**（CTP Topic 17）：Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成——双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell/Shell 脚本，通过 Terraform `user_data` 实现自动化域加入；旧域名 `infra` 和 `AST` 已废弃，提供明确迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。属 [[AWS-Landing-Zone]] AD 集成的核心实践参考。 **[[ctp-topic-5-aws-identity-and-access-management-iam]]**（CTP Topic 5）：AWS IAM 核心组件与联邦访问机制——涵盖 IAM Dashboard 四大资源（用户、组、客户托管策略、角色、身份提供商）；联邦用户通过 Active Directory 组映射到 IAM 角色实现单点登录；`accounts.json` 位于每个 Landing Zone 根目录，包含账户号列表；IAM 用户主要用于服务账号，人工用户优先使用联邦访问；角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联；策略分为 AWS 托管和客户托管两种，Terraform 模块可定义 IAM 角色（假设角色策略 + 内联策略块）；PFSSO 工具实现 CLI 联邦访问；最小权限原则贯穿始终。属 [[AWS-Landing-Zone]] 身份与访问管理层的入门基础，与 [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]（AD 集成）、[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]（AD 登录）、[[learning-sessions-identity-governance-vsm-replacement]]（身份治理）共同构成完整的身份治理知识体系。 @@ -378,21 +380,21 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast **[[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]**（CTP Topic 65）：云转型中的价值交付量化框架——提供系统性衡量、捕获和优先排序云转型业务价值的方法论。核心内容：①基础概念——过程（Process）将输入转化为产出/成果，成果分硬性（时间/成本/质量）和软性（健康/安全）；Lean 识别三类活动：增值活动、价值赋能活动、浪费；价值（Value）由客户决定，体现为公平回报；②价值流（Value Stream）分为运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）；③收益量化框架——涵盖财务、生产力、质量和体验四个维度，聚焦收入增长、成本降低、风险改善和服务可获得市场规模（SOM）；④WSJF 优先级排序——通过 Cost of Delay / Size of Job 比值对工作排序，实现"最小投入尽早交付最大价值"；延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会；⑤功能级价值拆解——可按单一功能归属、均分或不均匀分配（基于触达/影响/努力等标准）。属 [[AWS-Landing-Zone]] 价值治理层的核心方法论，与 [[ctp-topic-30-managing-change]]（变更管理）和 [[ctp-topic-20-program-demand-process-flow]]（需求流程）共同构成完整的 CTP 治理知识体系。 -**[[ctp-topic-13-cloud-finops-policies]]**（CTP Topic 13）：PCG 团队 Uday 和 Vinay 主讲 Cloud FinOps 成本优化政策与最佳实践——核心架构：PCG 三层服务模型（成本管理：账单支付/showback-chargeback/预算管理 → 成本优化：Reserved Instances 集中购买与资源去优化 → 治理与自动化：集中式上线/策略开发/自动报告）；5 大核心策略（账单可见性、标签合规、账户负责人预算责任、Reserved Instances 集中管理、区域限制）；安全控制（预安装 Godrails、联合身份管理 MFA、告警重定向至安全团队）；Cloud Health 工具提供资源清单和月度账单洞察；标准化实例选型（M/T/C/R/X 系列）+ Graviton ARM 实例节省成本；研发环境三合一优化（突发性实例 + Spot 实例 + 实例调度器）。属 [[FinOps（云财务管理）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[ctp-topic-63-optimise-resource-cost-using-automation]]（自动化调度优化）和 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]（Rightsizing 最佳实践）共同构成完整的 FinOps 知识链路。 +**[[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]**（CTP Topic 13）：PCG 团队 Uday 和 Vinay 主讲 Cloud FinOps 成本优化政策与最佳实践——核心架构：PCG 三层服务模型（成本管理：账单支付/showback-chargeback/预算管理 → 成本优化：Reserved Instances 集中购买与资源去优化 → 治理与自动化：集中式上线/策略开发/自动报告）；5 大核心策略（账单可见性、标签合规、账户负责人预算责任、Reserved Instances 集中管理、区域限制）；安全控制（预安装 Godrails、联合身份管理 MFA、告警重定向至安全团队）；Cloud Health 工具提供资源清单和月度账单洞察；标准化实例选型（M/T/C/R/X 系列）+ Graviton ARM 实例节省成本；研发环境三合一优化（突发性实例 + Spot 实例 + 实例调度器）。属 [[FinOps（云财务管理）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[ctp-topic-63-optimise-resource-cost-using-automation]]（自动化调度优化）和 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]（Rightsizing 最佳实践）共同构成完整的 FinOps 知识链路。 -**[[public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting]]**（Public Cloud Learning Sessions）：AWS 存储服务成本优化全景——覆盖 EBS（GP3 推荐，比 GP2 便宜 20%，可独立扩展 IOPS/吞吐量；快照支持归档层比标准层低 75% 成本）、EFS/FSx（生命周期策略和分层机制）、S3（Intelligent Tiering 自动冷热迁移无转换费用；生命周期策略管理非当前版本和多段上传过期；数据传输费用需注意，PrivateLink 可规避）和 ADM 迁移案例（OpenZFS → 自管理 NetApp on EC2 → FSx for NetApp ONTAP 实现 60% 成本削减）。属 [[FinOps（云财务管理）]] 存储优化专题，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）和 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（综合成本优化）共同构成完整 FinOps 知识链路。 +**[[public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting]]**（Public Cloud Learning Sessions）：AWS 存储服务成本优化全景——覆盖 EBS（GP3 推荐，比 GP2 便宜 20%，可独立扩展 IOPS/吞吐量；快照支持归档层比标准层低 75% 成本）、EFS/FSx（生命周期策略和分层机制）、S3（Intelligent Tiering 自动冷热迁移无转换费用；生命周期策略管理非当前版本和多段上传过期；数据传输费用需注意，PrivateLink 可规避）和 ADM 迁移案例（OpenZFS → 自管理 NetApp on EC2 → FSx for NetApp ONTAP 实现 60% 成本削减）。属 [[FinOps（云财务管理）]] 存储优化专题，与 [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]（政策框架）和 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（综合成本优化）共同构成完整 FinOps 知识链路。 -**[[ctp-topic-63-optimise-resource-cost-using-automation]]**（CTP Topic 63）：使用自动化手段优化 AWS 云资源成本——涵盖五大核心策略：①批准区域（Approved Region）标准化（Oregon/NVirginia/Frankfurt/London/Sydney/Singapore），提高安全性和成本可预测性；②实例类型选择（M6i/M6g 通用型、T3/T4g 经济型、C 系列计算型、R 系列内存型），同配置 M→R 切换节省 35%，Graviton ARM 比 Intel 便宜 20-25%；③承诺计划（1年约 40% 折扣、3年约 60-64% 折扣）；④存储优化（GP2→GP3 节省 20%，及时清理未使用 EBS 卷）；⑤自动化调度（基于标签的 EC2/RDS 启动/停止，通过 Lambda + EventBridge + Terraform Scheduler 模块实现，非 7×24 工作负载每天只运行 10 小时可节省 70% 成本）。属 [[FinOps（云财务管理）]] 技术实施层，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）和 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]（RightSizing）共同构成完整 FinOps 知识链路。 +**[[ctp-topic-63-optimise-resource-cost-using-automation]]**（CTP Topic 63）：使用自动化手段优化 AWS 云资源成本——涵盖五大核心策略：①批准区域（Approved Region）标准化（Oregon/NVirginia/Frankfurt/London/Sydney/Singapore），提高安全性和成本可预测性；②实例类型选择（M6i/M6g 通用型、T3/T4g 经济型、C 系列计算型、R 系列内存型），同配置 M→R 切换节省 35%，Graviton ARM 比 Intel 便宜 20-25%；③承诺计划（1年约 40% 折扣、3年约 60-64% 折扣）；④存储优化（GP2→GP3 节省 20%，及时清理未使用 EBS 卷）；⑤自动化调度（基于标签的 EC2/RDS 启动/停止，通过 Lambda + EventBridge + Terraform Scheduler 模块实现，非 7×24 工作负载每天只运行 10 小时可节省 70% 成本）。属 [[FinOps（云财务管理）]] 技术实施层，与 [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]（政策框架）和 [[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]（RightSizing）共同构成完整 FinOps 知识链路。 **[[ctp-topic-27-aws-instance-scheduler]]**（CTP Topic 27）：Gustavo 主讲 AWS Instance Scheduler 原生方案——通过 CloudFormation 一键部署，由 CCOE Guardrails 框架自动集成推送至公司绝大多数月消费 10 美元以上的 AWS 账号，无需用户手动配置。核心技术栈：CloudWatch Events 定时触发（默认每 15 分钟）→ Lambda 函数读取 DynamoDB 调度配置（Schedules + Periods）→ 根据实例标签（`Schedule`、`Period`）执行启动或停止操作。核心要点：①调度基于"时间表"而非"空闲率"触发；②支持多时区办公时间配置（西雅图时间、英国时间等）；③RDS 实例智能配合每 7 天维护窗口，确保维护完成后恢复正常调度状态；④实例关机行为必须设置为"停止（Stop）"而非"终止（Terminate）"以保留数据。与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 的 Terraform Scheduler 模块（`auto_shutdown` 标签）构成互补方案——Instance Scheduler 覆盖广账户层，Terraform Scheduler 提供 IaC 层细粒度控制。 **[[ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when]]**（CTP Topic 71）：PCG 团队讲解 AWS EC2 RightSizing 系统性方法论——核心主题：为何要做 RightSizing、何时做、如何执行的完整指南。问题域聚焦过度配置（over-provisioned）EC2 实例导致的资源浪费。RightSizing 通过分析实例实际资源使用情况，将过度配置的实例调整为合适规格，在不影响性能的前提下实现成本节省。是 [[FinOps（云财务管理）]] 核心技术手段之一。⚠️ 视频尚未完成 Whisper 转录，完整内容待补充。 -**[[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]**（Public Cloud Learning Sessions，Vinay 主讲）：AWS 云成本优化技术深度实践——**工作负载优化**聚焦现代化（EC2 新代际/Graviton 20-25% 节省/AMD 6-10% 节省/GP2→GP3 存储 20% 节省/EKS 最新版避免扩展支持费/Spot 实例 90% 折扣）和 Right Sizing（EC2 Right Sizing 报告/实例调度/闲置资源清理）。**费率优化**讲解 Savings Plans 和 Reserved Instances 的两种承诺类别（资源级 vs 灵活），以及完整实施流程（前置 Right Sizing → 分析 24/7 工作负载 → 财务沟通 → 账户所有者审批 → 利用率监控报告）。关键规则：承诺计划仅支持无预付选项，最低交易金额 $5k/年，仅由 Phenops 团队实施。属 FinOps 技术实施层，与 [[ctp-topic-13-cloud-finops-policies]]（政策框架）互补，共同构成"政策 → 技术实施"完整链路。 +**[[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]**（Public Cloud Learning Sessions，Vinay 主讲）：AWS 云成本优化技术深度实践——**工作负载优化**聚焦现代化（EC2 新代际/Graviton 20-25% 节省/AMD 6-10% 节省/GP2→GP3 存储 20% 节省/EKS 最新版避免扩展支持费/Spot 实例 90% 折扣）和 Right Sizing（EC2 Right Sizing 报告/实例调度/闲置资源清理）。**费率优化**讲解 Savings Plans 和 Reserved Instances 的两种承诺类别（资源级 vs 灵活），以及完整实施流程（前置 Right Sizing → 分析 24/7 工作负载 → 财务沟通 → 账户所有者审批 → 利用率监控报告）。关键规则：承诺计划仅支持无预付选项，最低交易金额 $5k/年，仅由 Phenops 团队实施。属 FinOps 技术实施层，与 [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]（政策框架）互补，共同构成"政策 → 技术实施"完整链路。 -**[[public-cloud-learning-sessions-budget-control-20240319]]**（Public Cloud Learning Sessions，SRE Core 团队 Daniela/Evan/Alan 主讲）：AWS 预算控制自动化深度实践——解决 AWS 账户蔓延导致的成本失控问题。核心架构：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）的完整告警与执行链路；告警类型分 4 种（Forecast/Actual 80-98%/Severe/Enforcement），评分系统计算宽限期避免月末轻微超支账户被误处罚；Source Identity（STS SourceIdentity 属性）通过 CloudTrail 追踪联邦登录跨角色切换的原始用户身份，实现成本责任到人；初始范围仅限 Lab 账户。属 [[FinOps（云财务管理）]] Enforcement 执行层，与 [[ctp-topic-13-cloud-finops-policies]]（治理与自动化政策）和 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（主动优化手段）共同构成 FinOps 完整闭环（告警→Enforcement→优化）。 +**[[public-cloud-learning-sessions-budget-control-20240319]]**（Public Cloud Learning Sessions，SRE Core 团队 Daniela/Evan/Alan 主讲）：AWS 预算控制自动化深度实践——解决 AWS 账户蔓延导致的成本失控问题。核心架构：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）的完整告警与执行链路；告警类型分 4 种（Forecast/Actual 80-98%/Severe/Enforcement），评分系统计算宽限期避免月末轻微超支账户被误处罚；Source Identity（STS SourceIdentity 属性）通过 CloudTrail 追踪联邦登录跨角色切换的原始用户身份，实现成本责任到人；初始范围仅限 Lab 账户。属 [[FinOps（云财务管理）]] Enforcement 执行层，与 [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]（治理与自动化政策）和 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（主动优化手段）共同构成 FinOps 完整闭环（告警→Enforcement→优化）。 -**[[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]]**（Public Cloud Learning Sessions，Mike Dukes 和 Steele Taylor 主讲）：AWS EC2 成本优化最佳实践深度解析——核心主题覆盖计算效率、Nitro 系统、Graviton 使用、EC2 Spot 竞价实例和容器化成本部署。AWS Nitro 系统通过将网络、存储和安全组件外部化来提升效率；Graviton 处理器基于 ARM64 架构，提供高达 40% 更好的性价比，功耗比同等 x86 实例减少高达 60%；EC2 Spot 实例利用 AWS 闲置容量提供高达 90% 的按需价格折扣；购买选项包括 On-Demand、Savings Plans 和 Spot Instances。Spot Invaders 游戏作为容错混沌工程的实践案例，展示了在 EKS 上使用 Spot 实例构建弹性应用的最佳实践。Graviton 适用于大多数工作负载（Web 服务、容器、HPC 批处理、大数据、CI/CD），但排除有状态服务（如数据库）；Spot 和 Graviton 可组合使用以最大化成本节省。属 [[FinOps（云财务管理）]] 技术实践层，与 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（成本优化技术）和 [[ctp-topic-13-cloud-finops-policies]]（政策框架）共同构成完整的 EC2 成本优化知识链路。 +**[[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]]**（Public Cloud Learning Sessions，Mike Dukes 和 Steele Taylor 主讲）：AWS EC2 成本优化最佳实践深度解析——核心主题覆盖计算效率、Nitro 系统、Graviton 使用、EC2 Spot 竞价实例和容器化成本部署。AWS Nitro 系统通过将网络、存储和安全组件外部化来提升效率；Graviton 处理器基于 ARM64 架构，提供高达 40% 更好的性价比，功耗比同等 x86 实例减少高达 60%；EC2 Spot 实例利用 AWS 闲置容量提供高达 90% 的按需价格折扣；购买选项包括 On-Demand、Savings Plans 和 Spot Instances。Spot Invaders 游戏作为容错混沌工程的实践案例，展示了在 EKS 上使用 Spot 实例构建弹性应用的最佳实践。Graviton 适用于大多数工作负载（Web 服务、容器、HPC 批处理、大数据、CI/CD），但排除有状态服务（如数据库）；Spot 和 Graviton 可组合使用以最大化成本节省。属 [[FinOps（云财务管理）]] 技术实践层，与 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]（成本优化技术）和 [[ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co]]（政策框架）共同构成完整的 EC2 成本优化知识链路。 **[[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]**（Public Cloud Learning Sessions，AWS 高级解决方案架构师 Suraav Paul 主讲）：AWS AI/ML 与生成式 AI 入门——AI 复制需要人类智能的任务，通过机器学习使用数据创建决策模型；分类 AI 识别模式，预测 AI 预判趋势，生成式 AI 利用基础模型（Foundation Models）创造内容。Amazon 在 ML 领域深耕 20 年，AWS 在四大领域帮助客户应用 AI：提升客户体验、实现更优决策、改善运营、创造新产品。Amazon Bedrock 是全托管生成式 AI 服务，提供 Titan 等多种基础模型，支持微调、持续预训练、RAG 和 Bedrock Agents 等数据定制技术；Guardrails for Bedrock 提供负责任 AI 安全护栏。ML Ops 将机器学习与运维融合，涵盖数据流水线（数据收集/集成/准备）、训练流水线（特征工程/模型训练/超参调优）和推理流水线（部署/监控）。属 Cloud Transformation Programme 的 Serverless & AI 专题入门，与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（Generative AI & Prompt Engineering，OpenText 技术客户经理 Shikad Holtzman 主讲）和 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]（无服务器计算）共同构成 Serverless & AI 知识链路。 diff --git a/wiki/sources/cloud-learning-master-index.md b/wiki/sources/cloud-learning-master-index.md index 16c266d2..10f2a48f 100644 --- a/wiki/sources/cloud-learning-master-index.md +++ b/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 同样需要学习 diff --git a/wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md b/wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md index 4bdc0858..40fdb70c 100644 --- a/wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md +++ b/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]] 聚焦是否应迁移的决策论证 - - 当前观点：默认已在云上，专注于持续优化成本 - - 对方观点：云迁移决策本身需要商业价值论证 +- （无） diff --git a/wiki/sources/ctp-topic-2-git.md b/wiki/sources/ctp-topic-2-git.md index 3cfa3cb7..63f58745 100644 --- a/wiki/sources/ctp-topic-2-git.md +++ b/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 +- （暂无，待视频内容补充） diff --git a/wiki/sources/ctp-topic-27-aws-instance-scheduler.md b/wiki/sources/ctp-topic-27-aws-instance-scheduler.md index 9400ef94..43e39393 100644 --- a/wiki/sources/ctp-topic-27-aws-instance-scheduler.md +++ b/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 层细粒度控制，企业可同时使用 +- 无显著内容冲突 diff --git a/wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md b/wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md index f32ec170..645cab6b 100644 --- a/wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md +++ b/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 的详细对比 diff --git a/wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md b/wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md index 72c47e35..d28311bb 100644 --- a/wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md +++ b/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 最佳实践 diff --git a/wiki/sources/ctp-topic-33-an-introduction-to-gitops.md b/wiki/sources/ctp-topic-33-an-introduction-to-gitops.md index 987e28c1..a9f8db82 100644 --- a/wiki/sources/ctp-topic-33-an-introduction-to-gitops.md +++ b/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 diff --git a/wiki/sources/ctp-topic-37-secrets-certificates-management.md b/wiki/sources/ctp-topic-37-secrets-certificates-management.md index c05acfcf..dda01aad 100644 --- a/wiki/sources/ctp-topic-37-secrets-certificates-management.md +++ b/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 产品提供方，开源版和商业企业版均参与评估 diff --git a/wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md b/wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md index 260dcc8b..90185e8d 100644 --- a/wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md +++ b/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 模块管理 diff --git a/wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md b/wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md index aeb0b521..b3a977c5 100644 --- a/wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md +++ b/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）操作系统层，两种方案各有适用场景 diff --git a/wiki/sources/ctp-topic-55-aws-firewall-manager.md b/wiki/sources/ctp-topic-55-aws-firewall-manager.md index d7f1be21..1a7bdafc 100644 --- a/wiki/sources/ctp-topic-55-aws-firewall-manager.md +++ b/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 页面的直接内容冲突 diff --git a/wiki/sources/ctp-topic-62-aws-secrets-manager.md b/wiki/sources/ctp-topic-62-aws-secrets-manager.md index d1e691ee..1abac805 100644 --- a/wiki/sources/ctp-topic-62-aws-secrets-manager.md +++ b/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 阶段被评估，但因成本原因未被采用 diff --git a/wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md b/wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md index e6da2279..fd910759 100644 --- a/wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md +++ b/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 +- **转录后需补充**：摘要、关键概念、行动项、相关视频链接 diff --git a/wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md b/wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md index 975d17b3..2c8bfd3e 100644 --- a/wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md +++ b/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]] diff --git a/wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md b/wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md index 76f53133..61065141 100644 --- a/wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md +++ b/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 一致性的多云环境。 diff --git a/wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md b/wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md index be3f5fd9..8038aa95 100644 --- a/wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md +++ b/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 页面的冲突内容 diff --git a/wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md b/wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md index ebb58e4f..5521a0e1 100644 --- a/wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md +++ b/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） +- （无已知冲突） diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md b/wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md index 44aa97a6..9b733aa8 100644 --- a/wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md +++ b/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 优化手段 diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md b/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md index 1110c411..156bf08c 100644 --- a/wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md +++ b/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 聚焦最佳实践和团队协作） diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md b/wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md index d8ee2cc0..214b1991 100644 --- a/wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md +++ b/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. 运维复杂度） diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md b/wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md index 15cd09d6..86b233c8 100644 --- a/wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md +++ b/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 是一个更宽泛的架构模式，涵盖消息队列、事件总线等多种实现