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

wiki/sources/blogwatcher-daily收藏.md

@@ -0,0 +1,58 @@
+---
+title: "Blogwatcher Daily 技能收藏"
+type: source
+tags: [hermes-agent, rss, automation, daily-digest]
+date: 2026-04-18
+---
+
+## Source File
+- [[Skills/blogwatcher-daily收藏.md]]
+
+## Summary（用中文描述）
+- 核心主题：RSS/YouTube 订阅频道的自动化监控与每日摘要生成
+- 问题域：个人资讯获取效率——手动逐个打开各频道耗时且容易遗漏更新
+- 方法/机制：Hermes Agent 自定义 Skill，定时抓取 31 个订阅频道，SQLite 去重，每日追加写入 Markdown 日报
+- 结论/价值：将信息获取自动化，用户每天早上只需阅读一篇摘要即可掌握所有频道动态
+
+## Key Claims（用中文描述）
+- Hermes Agent 通过自定义 Skill `blogwatcher-daily` 实现 31 个订阅频道的自动化监控
+- 每日扫描（Cron Job）自动追加新文章到 `YYYY-MM-DD.md` 日报，避免覆盖历史内容
+- YouTube 频道通过 RSSHub 本地部署代理转换为 RSS Feed，绕过直接访问限制
+- SQLite 数据库按 URL 去重，已读链接不重复写入
+- 强制回扫（`--all`）写入独立文件 `all-YYYY-MM-DD.md`，不污染日常日报
+- 支持 `--scan-only` 调试模式，只打印结果不写文件
+
+## Key Quotes
+> "📊 扫描完成: 共发现 12 篇新文章" — 日常扫描输出示例
+
+> "新增订阅需要补历史、某个频道很久没看想批量回顾" — 强制回扫适用场景
+
+> "wikiHow 禁止所有爬虫，无法抓取，永远返回 0 篇" — 已知限制说明
+
+## Key Concepts
+- [[RSS Monitoring]]：通过 RSS/Atom Feed 订阅网站和 YouTube 频道更新的标准化协议
+- [[Cron Job]]：定时任务调度，每天早上 6:00 自动执行扫描
+- [[RSSHub]]：开源 RSS 生成器，将不支持 RSS 的网站（如 YouTube）转换为 RSS Feed
+- [[feedparser]]：Python RSS 解析库，支持 RSS 1.0/2.0/Atom 及 GB2312/GBK 编码
+- [[Deduplication]]：SQLite 按 URL 排重，避免重复写入
+- [[每日日报]]：追加模式日记文件，每天一篇，持续积累
+- [[增量写入]]：日常扫描追加到日报，强制回扫写入独立文件，二者互不干扰
+
+## Key Entities
+- [[Hermes Agent]]：运行 blogwatcher-daily Skill 的 AI Agent 平台，通过 Cron Job 调度
+- [[RSSHub]]：本地部署的 RSSHub 实例（`http://192.168.3.45:1200`），用于转换 YouTube 频道为 RSS
+- [[blogwatcher-daily]]：Hermes Agent 自定义 Skill，核心脚本为 `blogwatcher-daily.py`
+- [[feedparser]]：Python RSS 解析库，解决 RSS 1.0、GB2312 乱码、畸形 XML 等兼容性问题
+
+## Connections
+- [[blogwatcher-daily收藏]] ← depends_on ← [[RSSHub]]
+- [[blogwatcher-daily收藏]] ← depends_on ← [[feedparser]]
+- [[blogwatcher-daily收藏]] ← depends_on ← [[每日日报]]
+- [[blogwatcher-daily收藏]] ← extends ← [[multi-source-tech-news-digest]]
+
+## Contradictions
+- 与 [[multi-source-tech-news-digest]]：
+  - 冲突点：两者都是 RSS 多源新闻聚合方案
+  - 当前观点：blogwatcher-daily 侧重 YouTube + RSS 直订的本地化方案，覆盖 31 个固定频道
+  - 对方观点：multi-source-tech-news-digest 侧重多平台（RSS + Twitter + GitHub）的大规模聚合，支持动态添加来源
+  - 说明：两者定位互补，blogwatcher-daily 是轻量级固定订阅方案，后者是大规模动态监控方案

wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md

@@ -0,0 +1,56 @@
+---
+title: "CTP Topic 1 Gruntwork Landing Zone Architecture"
+type: source
+tags: [AWS, Landing-Zone, Gruntwork, CTP, Terraform, CI/CD]
+sources: []
+last_updated: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture]]
+
+## Summary（用中文描述）
+- 核心主题：基于 Gruntwork 的 AWS Landing Zone 架构设计，包括参考架构、多账户结构和 CI/CD 流水线。
+- 问题域：如何在云转型项目中快速构建符合最佳实践的多账户 AWS 基础设施。
+- 方法/机制：参考架构（Reference Architecture）提供起点 → Landing Zone 基于 Gruntwork 仓库由产品团队自定义 → Jenkins CI/CD 自动化部署 → Git 特性分支工作流。
+- 结论/价值：Gruntwork 提供经过实战验证的 Terraform 模块，是 AWS 基础设施最佳实践的集合；Landing Zone 在此基础上由各产品团队填充具体业务服务。
+
+## Key Claims（用中文描述）
+- Gruntwork 是拥有大量 Terraform 代码的组织，其代码经过多次实践验证，被认为是最佳实践。
+- 参考架构（Reference Architecture）是包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点。
+- Landing Zone 基于 Gruntwork 但由产品团队自行定义具体服务，不包含 ECS 集群或 RDS 数据库等具体实现。
+- 安全账户使用联邦用户（Federated User），通过 AD 组映射到 IAM 角色，替代传统 IAM 用户。
+- 每个 Landing Zone 配备独立的 Jenkins 服务器来部署基础设施变更，每个产品团队也有自己的 Jenkins 任务。
+- Git 工作流采用特性分支开发，通过 Pull Request 合并到主分支。
+- Gruntwork 的 Terraform AWS 服务目录强调服务应具有业务上下文，而非简单的资源堆砌。
+
+## Key Quotes
+> "Gruntwork is a company that has put together a lot of Terraform code, and it's a collection of best practices." — Gruntwork Landing Zone 核心价值定位
+
+> "Landing Zone is based on Gruntwork, but it doesn't have ECS clusters or RDS databases — it's defined by the product team." — Landing Zone vs Reference Architecture 的关键区别
+
+> "Security account uses federated users, mapping AD groups to IAM roles, instead of traditional IAM users." — 联邦用户替代 IAM 用户的身份管理策略
+
+## Key Concepts
+- [[Reference-Architecture]]：包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点。
+- [[Landing-Zone-Architecture]]：基于 Gruntwork 仓库的 AWS 多账户基础设施部署单元，每个 Zone 有独立 GitHub 仓库管理 IaC。
+- [[Terraform-Modules]]：Gruntwork 提供的经过实战验证的 Terraform 模块，强调服务具有业务上下文。
+- [[Federated-Access]]：通过 AD 组映射到 IAM 角色的联邦身份访问，简化安全账户管理。
+- [[CI-CD-Pipeline]]：基于特性分支 + Pull Request + Jenkins 的 Terraform 基础设施变更自动化流程。
+
+## Key Entities
+- [[Gruntwork]]：AWS Landing Zones 基础设施框架提供方，提供经过实战验证的 Terraform 模块库。
+
+## Connections
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（CI/CD 流水线是 Landing Zone 部署的核心机制）
+- [[ctp-topic-2-git]] ← depends_on ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（Git 工作流是 CI/CD 的前提）
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（Terraform 部署是 Landing Zone 的 IaC 实践）
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（AD 集成是 Landing Zone 安全账户的核心）
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]（数据标签是 Landing Zone 安全配置的基础）
+
+## Contradictions
+- 与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 冲突：
+  - 冲突点：Landing Zone 中产品的定义粒度
+  - 当前观点（CTP Topic 1）：Landing Zone 由产品团队自行定义具体服务（ECS/RDS 等），产品团队有较大自主权
+  - 对方观点（CTP Topic 35）：Landing Zone 产品定义应更严格，由架构团队统一规划
+  - 状态：视角互补而非直接矛盾——CTP Topic 1 强调灵活性，CTP Topic 35 强调标准化，可能反映不同组织规模和治理成熟度的差异

wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md

@@ -0,0 +1,57 @@
+---
+title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
+type: source
+tags:
+  - AWS
+  - Landing-Zone
+  - Tagging
+  - Security
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Landing Zone 部署流程中的数据收集策略，以及基于标签（Tagging）的云原生安全架构设计
+- 问题域：企业从传统基于 IP 的网络安全向基于身份和元数据的云安全转型过程中，如何规划 Landing Zone 并确保标签策略被强制执行
+- 方法/机制：①部署前摸底 BU 资产清单、IP 地址空间及数据敏感性；②用 AWS 标签替代 IP 作为安全凭证；③通过 OU + SCP 强制标签合规；④Checkpoint 防火墙有序层（Ordered Layer）实现基于标签的流量过滤
+- 结论/价值：为 CTP 系列的 Landing Zone 标签治理闭环（制定规范 → 强制执行 → 流量控制）提供了完整的端到端设计思路
+
+## Key Claims（用中文描述）
+- SRE 团队通过自动化脚本实现了 DNS 和 Transit Gateway 等基础服务的高度自动化，部署前必须先完成 BU 资产清单和数据敏感性评估
+- 基于标签的安全控制机制替代传统基于 IP 的防火墙规则，Checkpoint 防火墙通过读取 AWS 标签动态配置网络访问策略
+- SCP 的"显式拒绝"逻辑能够强制执行标签规范，防止用户通过篡改标签绕过安全审计
+- Checkpoint 防火墙的有序层（Ordered Layer）按顺序执行地理屏蔽、BU 隔离、产品隔离、环境隔离（Dev vs Prod）等策略
+
+## Key Quotes
+> "在部署 Landing Zone 前，必须深入了解业务部门的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态。" — Steve Jarman，部署规划原则
+> "通过 SCP 的显式拒绝逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属（BU、产品、环境）。" — Pradeep，标签强制机制
+
+## Key Concepts
+- [[Landing-Zone-Architecture]]：AWS Landing Zone 是一种按照最佳实践快速设置安全且多账号 AWS 环境的基础架构框架，本视频是其标签治理设计的重要实践补充
+- [[AWS-Tagging-Standards]]：标签方法论，通过为资源定义标准化的元数据（如 Owner、BU、Product、Environment）作为自动化管理和安全策略执行的基础，本视频是该方法论的核心设计来源
+- [[Service-Control-Policies-SCPs]]：服务控制策略，本视频中用于强制执行标签合规性，防止未经授权的标签更改，属于标签治理闭环的强制执行层
+- Ordered Layer（有序层）：Checkpoint 防火墙策略的组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑，是基于标签的流量过滤实现机制
+- Tagging-Based Security Control（基于标签的安全控制）：用 AWS 标签作为安全凭证替代传统基于 IP 的防火墙规则，是云原生安全架构的核心转型方向
+
+## Key Entities
+- [[Steve-Jarman]]：CTP 系列讲师，主导本次 Landing Zone 部署规划与自动化策略分享
+- [[Pradeep]]：CTP 系列讲师，演示基于标签的 SCP 强制执行机制与 Checkpoint 防火墙策略
+- [[Checkpoint]]：防火墙供应商，依赖 AWS 标签值配置网络访问策略的有序层（Ordered Layer）
+- SRE-Team：站点可靠性工程团队，负责 Landing Zone 部署中的 DNS、Transit Gateway 等基础服务的自动化脚本编写
+
+## Connections
+- [[Landing-Zone-Architecture]] ← foundational ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
+- [[AWS-Tagging-Standards]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
+- [[Service-Control-Policies-SCPs]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
+- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
+- [[ctp-topic-47-enterprise-architecture-cloud-standards]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
+
+## Contradictions
+- 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 视角差异：
+  - 冲突点：Landing Zone 部署的自动化粒度
+  - 当前观点（Topic 10）：DNS、Transit Gateway 等基础服务已由 SRE 团队高度自动化，强调标签驱动的安全控制
+  - 对方观点（Topic 1）：强调 Gruntwork 架构中 Jenkins 服务器和 Git 分支工作流作为自动化核心，标签治理描述相对简略
+  - 说明：两者互补而非冲突——Topic 1 提供账户结构和 IaC 基础，Topic 10 补充了标签驱动的安全运营闭环

wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md

@@ -0,0 +1,69 @@
+---
+title: "CTP Topic 14 Octane Hub on AWS Real Life Experience Moving Production Services"
+type: source
+tags:
+  - AWS
+  - Octane-Hub
+  - Migration
+  - CTP
+  - Landing-Zone
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]
+
+## Summary（用中文描述）
+- 核心主题：Octane Hub CTO Holger Rode 分享将生产服务从 Bibling Lab 数据中心迁移到 AWS Landing Zone 的实战经验
+- 问题域：企业级 Docker 容器化工作负载的云迁移规划与实施
+- 方法/机制：使用 AWS Landing Zone 账户体系，结合 Packer 构建 AMI、Terraform/TerraGrunt 部署、VPC Transit Gateway 网络互联、Route 53 DNS 管理
+- 结论/价值：提供从物理数据中心向 AWS 云端无缝迁移的具体路径，涵盖存储选型（EFS vs EBS）、网络配置、DNS 设置及 IaC 部署演进过程
+
+## Key Claims（用中文描述）
+- Octane Hub 团队通过 Docker 容器化主要 Web 应用（QuickSee、Release Manager、Patch Manager、安全程序板等），结合约 10TB 文件存储和 MSSQL 数据库，实现从 Bibling Lab 三台物理服务器向 AWS 的完整迁移
+- 云迁移动因源于 Bibling 数据中心即将关闭，云转型计划提供 POC Landing Zone（5月）和生产账户（6月），团队目标是无缝过渡、紧密镜像现有设置以避免 Go Live 期间进行重大技术变更
+- EFS 不适用于需要高性能数据库场景（数据库无法直接在 EFS 上运行），EBS 更适合实时数据库，EFS 适用于备份存储
+- IaC 部署从控制台脚本演进为 Packer 构建 AMI + Terraform/TerraGrunt 部署，实现了可重复、可审计的部署流程
+
+## Key Quotes
+> "Holger Rode（Octane Hub CTO 软件工厂团队负责人）分享了 Octane Hub 云设计考虑因素、学习曲线、网络和安全要求以及常见陷阱。" — 视频演讲主题介绍
+
+> "从控制台脚本演变为使用 Packer 构建 AMI，使用 Terraform/TerraGrunt 部署。" — IaC 演进路径
+
+## Key Concepts
+- [[Docker-Containerization]]：Octane Hub 的主要部署模式，运行 QuickSee、Release Manager、Patch Manager 等 Web 应用
+- [[Packer]] + [[Terraform]]/TerraGrunt：基础设施即代码的部署流程，从控制台脚本演进而来
+- [[VPC-Transit-Gateway]]：AWS 网络互联解决方案，实现多 VPC 之间的安全通信
+- [[EFS-vs-EBS]]：文件存储与块存储的性能差异——EFS 适合备份，EBS 适合实时数据库
+- [[AWS-Landing-Zone]]：多账户 AWS 环境架构，提供 POC 和生产账户分离
+
+## Key Entities
+- [[Holger-Rode]]：Octane Hub CTO，软件工厂团队负责人，云迁移项目负责人
+- [[Octane-Hub]]：软件工厂团队名称，主导从 Bibling Lab 向 AWS 的生产服务迁移
+- [[Bibing-Lab]]：Octane Hub 原有数据中心，即将关闭，触发云迁移
+- [[QuickSee]]：Octane Hub 托管的 Web 应用之一
+- [[Release-Manager]]：Octane Hub 托管的 Web 应用之一
+- [[Patch-Manager]]：Octane Hub 托管的 Web 应用之一
+- [[MSSQL]]：Octane Hub 原有数据库，计划迁移到 Postgres
+- [[AWS]]：目标云平台
+- [[Packer]]：AMI 构建工具
+- [[Terraform]]/TerraGrunt：基础设施即代码部署工具
+
+## Connections
+- [[AWS-Landing-Zone]] ← depends_on ← [[VPC-Transit-Gateway]]
+- [[Octane-Hub]] ← migrated_from ← [[Bibing-Lab]]
+- [[Docker-Containerization]] ← uses ← [[Packer]] + [[Terraform]]
+- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[AWS-Landing-Zone]]
+- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[AWS-Landing-Zone]]
+
+## Contradictions
+- 与 [[ctp-topic-7-saas-landing-zone-design]] 的设计视角：
+  - 冲突点：SaaS Landing Zone 侧重多租户架构设计，本视频侧重单体团队的实际迁移路径
+  - 当前观点：Octane Hub 案例强调紧密镜像现有设置、避免 Go Live 期间重大变更
+  - 对方观点：SaaS Landing Zone 设计更关注长期架构演进和租户隔离
+
+## Next Steps（迁移路线图）
+- 改进 DR（灾难恢复）和高可用性
+- 通过最佳匹配存储选项（S3）进行成本优化
+- 从 MSSQL 迁移到 Postgres
+- 可能迁移到 AWS ECS 服务

wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md

@@ -0,0 +1,59 @@
+---
+title: "CTP Topic 17 Active Directory Services in Gruntwork AWS LZs"
+type: source
+tags: [AWS, Landing-Zone, AD, Gruntwork, CTP]
+sources: []
+last_updated: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]
+
+## Summary（用中文描述）
+- 核心主题：在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践
+- 问题域：企业级 AWS 多环境（研发/生产）的 AD 域名规划、自动化域加入、以及开发者自助服务
+- 方法/机制：
+  - 双域名策略：`swinford.net`（研发实验室 R&D Labs）vs `intsas.local`（生产/SAS 环境）
+  - SRE 团队预制 AMI，内置 PowerShell（Windows）/Shell（Linux）域加入脚本
+  - Terraform `user_data` 触发自动域加入流程
+  - MIM（Microsoft Identity Manager）提供研发环境安全组自助管理
+  - SMACKS 工单系统处理生产环境账号申请
+- 结论/价值：旧域名（`infra`、`AST`）已在 Gruntwork LZ 中废弃，提供了清晰的迁移路径和所有权归属建议
+
+## Key Claims（用中文描述）
+- Gruntwork Landing Zones 按环境类型（研发 vs 生产）分别使用不同的 AD 域名，以满足隔离性和合规审计需求
+- Windows 实例通过 Terraform `user_data` 调用 SRE 预制 AMI 中的 PowerShell 脚本，实现自动化域加入、旧对象清理和本地管理员分配
+- Linux 实例通过安全动态更新（Secure Dynamic Updates）机制自动向 Windows DNS 服务器注册 DNS A 记录
+- 旧域名 `infra` 和 `AST` 在新 Gruntwork LZ 中已被废弃，开发者必须迁移至新域名架构
+- R&D 环境支持 MIM 自助服务工具，生产/SAS 环境通过 SMACKS 工单系统申请账号
+
+## Key Quotes
+> "本次视频是 DevOps 云学习系列课程之一，重点介绍了在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory (AD) 服务的核心实践。演讲者 Paul 详细阐述了两种主要环境的域名配置：研发实验室（R&D Labs）统一使用 `swinford.net` 域名，而生产与分阶段 SAS 环境则采用 `intsas.local`。" — 视频摘要
+
+> "旧有的 `infra` 和 `AST` 域名在新的 Gruntwork 落地页中已被废弃，并为用户提供了相应的迁移路径和所有权归属建议。" — 视频摘要
+
+## Key Concepts
+- [[Gruntwork Landing Zones]]：预配置的、基于最佳实践的 AWS 基础架构框架，分为 R&D Labs 和 SAS 两种环境类型
+- [[swinford.net]]：专门用于研发实验室（R&D Labs）环境的 Active Directory 域名，支持 MIM 自助服务管理
+- [[intsas.local]]：用于生产和分阶段 SAS 环境的内部 Active Directory 域名，强调资源所有权归属和审计合规
+- [[SRE-provided AMIs]]：由 SRE 团队预先构建的机器镜像，内置了用于自动加入域的 PowerShell（Windows）和 Shell（Linux）脚本
+- [[User Data]]：在 AWS EC2 实例启动时执行的脚本数据，本视频中用于触发自动化的域加入流程
+- [[MIM (Microsoft Identity Manager)]]：用于 R&D 环境中安全组管理和权限申请的自助服务解决方案
+- [[SMACKS Ticket]]：内部服务管理工单系统，用于申请新账号、重置密码或处理复杂的生产环境变更
+- [[Secure Dynamic Updates]]：一种 DNS 安全机制，允许 Linux 系统在加入域时向 Windows DNS 服务器安全地注册其 A 记录
+
+## Key Entities
+- [[Paul]]：CTP Topic 17 讲师，Gruntwork AWS LZs AD 集成方案的讲解者
+- [[Gruntwork]]：提供 Landing Zones 基础设施框架的团队/组织
+- [[SRE Team]]：负责构建和维护预制 AMI 的 Site Reliability Engineering 团队
+- [[MIM]]：Microsoft Identity Manager，R&D 环境的安全组自助管理工具
+- [[SMACKS]]：内部服务管理工单系统，用于生产/SAS 环境的账号申请和变更处理
+
+## Connections
+- [[Gruntwork AWS Landing Zones Overview]] ← foundational ← [[CTP Topic 17 Active Directory Services]]
+- [[SRE Standard AMIs and Image Building]] ← source ← [[SRE-provided AMIs]]
+- [[Terraform Single Server Module Deep Dive]] ← deployment mechanism ← [[User Data]]
+- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] ← related ← [[AD Integration in AWS LZs]]
+
+## Contradictions
+- 暂无检测到与其他 Wiki 页面的冲突

wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md

@@ -0,0 +1,70 @@
+---
+title: "CTP Topic 25 Labs Landing Zone Overview - ITOM Teams"
+type: source
+tags:
+  - AWS
+  - Landing-Zone
+  - Labs
+  - ITOM
+  - CTP
+  - Gruntworks
+  - Terraform
+  - Terragrunt
+  - Multi-Account
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams]]
+
+## Summary（用中文描述）
+- 核心主题：
+  Labs Landing Zone 基于 Gruntwork 参考架构和 AWS 标准，采用多账户策略，通过 Terraform/Terragrunt 实现基础设施即代码（IaC）管理。所有资源必须通过代码机制管理，不可手动操作。
+- 问题域：
+  如何在 Labs 环境中建立标准化、可扩展、安全的多账户 AWS 基础设施架构，覆盖 CI/CD 流水线、网络安全、身份认证、日志管理等企业级运维需求。
+- 方法/机制：
+  - 基于 Gruntworks 参考架构的多账户策略
+  - 全部资源通过 Terraform/Terragrunt 代码化管理
+  - Jenkins 多分支流水线扫描 GitHub 仓库变更，触发 Terragrunt plan/apply
+  - Checkpoint 防火墙通过标签（Tags）机制控制网络访问
+  - 联邦认证（Federated Access）管理跨账户访问
+- 结论/价值：
+  Labs Landing Zone 提供企业级标准化基础设施模板，各团队基于标准 Terraform 模块快速部署工作负载，通过标签驱动的网络策略实现安全隔离，通过 Jenkins 流水线实现自动化部署和安全扫描。
+
+## Key Claims（用中文描述）
+- Labs Landing Zone 基于 Gruntwork 参考架构，所有资源必须通过 Terraform 或其他代码机制管理，不可手动操作。
+- Labs 采用多账户策略，核心账户组包括 Active Directory（管理 Windows 实例和 IDP）和 DNS（管理 AWS Swimford.net）。
+- Network 账户作为中央网络枢纽，通过 Transit Gateway 和 JetPult 防火墙管理所有互联网流量，所有防火墙访问均通过标签（Tags）控制。
+- Product Account 是主要工作环境，基于标准 IaC 模块构建，可包含多个子账户（生产/预发/开发）。
+- Jenkins 流水线扫描 GitHub Enterprise 仓库变更，根据分支触发 Terragrunt plan 或 apply，并通过 pre-commit 检查和 Fortify 安全扫描提升鲁棒性。
+
+## Key Quotes
+> "Everything should be managed using Terraform or some other code-based mechanism." — Labs Landing Zone 核心原则
+> "Access through that firewall is all managed by tags." — 网络防火墙访问控制机制
+> "The standard Jenkins-based pipelines scan GitHub Enterprise repositories for changes, running Terragrunt plans or applies based on the branch." — CI/CD 部署流程
+
+## Key Concepts
+- [[Landing Zone Architecture]]：多账户 AWS 基础设施的顶层框架，包含账户结构、网络、安全、访问管理和遥测
+- [[Terraform]]：基础设施即代码工具，Labs LZ 中用于管理所有 AWS 资源
+- [[Terragrunt]]：Terraform 的包装器，提供更简洁的多账户/多环境管理能力
+- [[Gruntwork]]：提供生产级 IaC 模块库的专业公司，参考架构的提供者
+- [[Jenkins]]：CI/CD 流水线工具，扫描 GitHub 仓库变更触发 Terragrunt plan/apply
+- [[Transit Gateway]]：AWS 网络服务，Network 账户通过它作为中央枢纽管理所有 VPC 间的流量路由
+- [[Federated Access]]：联邦访问，通过 AD 组映射到 IAM 角色实现跨账户身份认证
+- [[Tag-Based Access Control]]：基于标签的访问控制，防火墙通过资源标签动态配置网络策略
+
+## Key Entities
+- [[Swimford.net]]：Labs Landing Zone 中使用的 DNS 域名（所有 AD 和 DNS 服务均在此域名下）
+- [[JetPult]]：防火墙产品，Network 账户中用于管理网络流量
+- [[Pulse VPN]]：VPN 解决方案，Network 账户中用于提供对 Micro Focus 网络的访问
+- [[Qualys]]：安全扫描服务，Shared Service Accounts 中提供漏洞扫描能力
+- [[45 Arc Site]]：监控服务，Shared Service Accounts 中提供站点监控能力
+- [[Hardened AMIs]]：安全加固的 Amazon Machine Images，由 Shared Account 托管
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← foundational ← [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← related ← [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]
+- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]
+
+## Contradictions
+- 无已知冲突

wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md

@@ -0,0 +1,66 @@
+---
+title: "CTP Topic 26 Standard AMI – build, publish, share processes"
+type: source
+tags:
+  - AWS
+  - AMI
+  - Build-Process
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md]]
+
+## Summary（用中文描述）
+- 核心主题：Foundation AMI（基础亚马逊机器镜像）的构建、加固与分发全生命周期管理
+- 问题域：企业 AWS 云环境中如何标准化、安全化、可复用地管理 EC2 实例镜像
+- 方法/机制：基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建全自动化；通过跨账号共享（AMI Sharing）而非物理复制分发到全球多个区域（俄勒冈、法兰克福、悉尼等）；遵循 N-2 版本保留策略，每两个月更新一次
+- 结论/价值：CCOE 提供安全的基础镜像（Foundation AMI），产品团队在此之上构建自定义"产品特定 AMI"，实现安全合规与灵活定制兼顾的责任共担模型
+
+## Key Claims（用中文描述）
+- CCOE 通过 HashiCorp Packer + Jenkins 构建自动化流水线，使镜像创建完全自动化
+- Foundation AMI 集成 CIS 安全基准 + McAfee EPO 防病毒 + SSM Agent + SiteScope 监控，确保所有实例从启动起即符合 Micro Focus 安全合规标准
+- AMI 通过跨账号共享（AMI Sharing）分发至全球多区域，而非物理复制（AMI Copying），避免额外存储成本
+- Foundation AMI 每两个月更新一次，采用 N-2 版本保留策略
+- 责任共担：CCOE 负责 Foundation AMI，产品团队负责在其之上构建产品特定 AMI
+
+## Key Quotes
+> "Foundation AMI 是基于市场主流操作系统（如 CentOS, Ubuntu, Windows 等）进行深度加固的镜像，集成了 CIS 安全基准、防病毒软件（McAfee EPO）、日志管理（Syslog-ng）以及单点登录（AD 集成）。" — Foundation AMI 定义与集成组件说明
+
+> "镜像通过跨账号共享（Sharing）而非物理复制（Copying）的方式分发到全球多个区域（如俄勒冈、法兰克福、悉尼等）。" — AMI 分发机制说明
+
+> "Foundation AMI 每两个月更新一次，遵循 N-2 的版本保留策略。" — AMI 更新与版本管理策略
+
+> "CCOE 负责提供安全的基础镜像，而产品团队则被鼓励在 Foundation AMI 之上构建自定义的'产品特定 AMI'，以满足各自应用的特殊需求，并负责其后续的生命周期管理。" — 责任共担模型说明
+
+## Key Concepts
+- [[Foundation AMI]]：经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像
+- [[OS Hardening]]：操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面
+- [[CIS Benchmarks]]：由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践
+- [[HashiCorp Packer]]：开源工具，用于从单一源配置为多个云平台自动创建一致的机器镜像
+- [[SSM Agent]]：AWS 系统管理器代理，用于实现实例的远程管理、自动化补丁更新和配置同步
+- [[AMI Sharing]]：镜像共享机制，通过授权其他账号访问中央镜像，避免跨账号复制带来的额外存储成本
+- [[Central Repository]]：中央仓库，用于统一存放和管理经过验证的官方镜像，确保分发源的唯一性
+
+## Key Entities
+- [[Srihari]]：本次会议主讲人之一
+- [[Alan]]：本次会议主讲人之一
+- [[Praveen]]：本次会议主讲人之一
+- [[CCOE]]（Cloud Center of Excellence）：负责提供安全的基础镜像（Foundation AMI）
+
+## Connections
+- [[Foundation AMI]] ← uses ← [[HashiCorp Packer]] + [[Jenkins]]
+- [[Foundation AMI]] ← extends ← [[CIS Benchmarks]]（安全加固标准）
+- [[Foundation AMI]] ← depends_on ← [[SSM Agent]]（实例管理能力）
+- [[AMI Sharing]] ← uses ← [[Central Repository]]
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] ← extends ← [[ctp-topic-58-aws-ec2-image-builder]]
+- [[Foundation AMI]] ← provides ← [[AMI Sharing]]
+- [[Product-Specific AMI]] ← extends ← [[Foundation AMI]]
+
+## Contradictions
+- 与 [[ctp-topic-58-aws-ec2-image-builder]] 描述不同 AMI 生命周期阶段：
+  - 冲突点：ctp-topic-26 描述现有 Packer + Jenkins 自动化构建流程；ctp-topic-58 描述 EC2 Image Builder 作为替代方案
+  - 当前观点（ctp-topic-26）：Packer + Jenkins 是当前生产级 AMI 构建标准
+  - 对方观点（ctp-topic-58）：EC2 Image Builder 是 CCOE 加固脚本转换为可复用组件的未来演进方向
+  - 结论：非冲突，而是同一 AMI 生命周期管理在不同时期的技术选型——当前实践 vs 未来演进方向

wiki/sources/ctp-topic-28-aws-tag-validation-tool.md

@@ -0,0 +1,52 @@
+---
+title: "CTP Topic 28 AWS Tag Validation Tool"
+type: source
+tags: [AWS, Tagging, Validation, Tool, CTP, Boto3, Checkpoint]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-28-aws-tag-validation-tool]]
+
+## Summary（用中文描述）
+- 核心主题：SRE 团队开发的 AWS 标签验证工具，用于审计和报告 AWS 资源标签合规性。
+- 问题域：Checkpoint 防火墙依赖资源标签配置网络访问策略，标签缺失或无效将导致网络拦截；同时 SCPs 仅能阻止新资源创建，无法处理存量不合规资源。
+- 方法/机制：Python + Boto3 工具，通过 `variables.yaml` 配置文件定义每个账户的合法标签值，自动扫描 EC2/安全组/负载均衡器/Lambda 函数，比对预期值，输出 CSV 报告。使用 Poetry 管理 Python 环境。
+- 结论/价值：该工具极大提高了标签审计效率，可识别缺失或值错误的资源 ID 和具体问题；标签还可在未来用于成本核算（按产品分摊资源消耗）。
+
+## Key Claims（用中文描述）
+- Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略，标签无效或缺失时防火墙将拦截相关流量。
+- Service Control Policies（SCPs）可在组织层面阻止不合规资源的新建，但不能修复已存在的存量资源。
+- AWS 标签验证工具通过 YAML 配置文件定义每个账户的合法标签键和允许值，自动扫描多种 AWS 资源并生成 CSV 审计报告。
+- 该工具由 SRE 团队开发和维护，存放于 SRE Tools Repository，使用 Poetry 管理 Python 依赖。
+- 标签策略除网络安全用途外，未来还计划用于成本核算，区分同一账户下不同产品的资源消耗。
+
+## Key Quotes
+> "Checkpoint Firewall reads the tags on EC2 instances, security groups, and load balancers to configure network access policies — if the tags are missing or invalid, the firewall will block that traffic." — Lewis Brown，阐述标签与网络安全的直接关联
+
+> "The validation tool reads from a YAML file that contains all the expected tag keys and allowed values for a given AWS account." — Lewis Brown，阐述工具的核心工作机制
+
+## Key Concepts
+- [[AWS-Tags]]：附加在 AWS 资源上的元数据（键值对），用于识别管理和安全策略执行。
+- [[Tag-Validation-Tool]]：SRE 团队开发的 Python 工具，通过 Boto3 扫描 AWS 资源并比对 YAML 配置中的预期标签值。
+- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略类型，用于集中强制执行标签规范，阻止不合规资源创建。
+- [[Variables-YAML]]：该验证工具的核心配置文件，定义特定账户所期望的合法标签键及允许值列表。
+- [[AWS-Tagging-Standards]]：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略等。
+- [[Poetry]]：Python 依赖管理和打包工具，用于该验证工具的环境隔离和依赖管理。
+- [[Boto3]]：Python AWS SDK，该验证工具通过 Boto3 调用 AWS API 扫描资源标签。
+
+## Key Entities
+- [[Lewis-Brown]]：SRE 团队成员，本次视频讲师，介绍 AWS 标签验证工具。
+- [[Checkpoint]]：防火墙供应商，其防火墙产品读取 AWS 资源标签以配置网络访问策略。
+- [[SRE-Team]]：开发和维护该标签验证工具的团队，存放工具于 SRE Tools Repository。
+- [[SRE-Tools-Repository]]：内部代码仓库，存放该验证工具及其他 SRE 自动化脚本。
+- [[Boto3]]：AWS 官方 Python SDK，该工具的技术基础。
+- [[Poetry]]：Python 包管理工具，该工具的环境管理方案。
+
+## Connections
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-28-aws-tag-validation-tool]]
+- [[ctp-topic-10-aws-tagging-deep-dive]] ← related ← [[ctp-topic-28-aws-tag-validation-tool]]
+- [[AWS-Landing-Zone-Governance]] ← context ← [[ctp-topic-28-aws-tag-validation-tool]]
+
+## Contradictions
+- 无冲突检测。该工具与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 构成互补关系——后者聚焦标签收集机制和 Checkpoint 防火墙的安全策略上下文，前者聚焦如何检测和报告不合规资源。两者共同构成完整的标签治理闭环（制定规范 → 强制执行 → 审计发现）。

wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md

@@ -0,0 +1,56 @@
+---
+title: "CTP Topic 34 Azure Landing Zone Architecture Overview"
+type: source
+tags:
+  - Azure
+  - Landing-Zone
+  - Cloud-Transformation
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview]]
+
+## Summary（用中文描述）
+- 核心主题：Azure Landing Zone 在 Micro Focus 内部的实施架构概述
+- 问题域：企业级多云治理（Azure 部分）——如何通过 Landing Zone 简化 Azure 接入、减少跨团队依赖、实现自动化部署
+- 方法/机制：Azure Enterprise Enrollment → 管理组（Management Groups）分层 → 独立订阅隔离目的 → Terraform Cloud IaC 自动化
+- 结论/价值：四个管理组区域（Platform / Landing Zones / Decommission / Sandbox）实现资源隔离与职责分离；Terraform Cloud 管理跨订阅依赖；PIM/PAG 实现精细化访问控制
+
+## Key Claims（用中文描述）
+- Azure Landing Zone 通过管理组（Management Groups）将组织实体分为 Platform、Landing Zones、Decommission、Sandbox 四个层级，实现分层治理
+- Platform 层包含 Identity 和 Connectivity 两个独立订阅，各自承担特定安全职责，避免职责混淆
+- Connectivity 订阅作为中心枢纽，汇聚所有入站和出站 Azure 流量，集成 DDoS 防护和 Checkpoint 防火墙
+- Landing Zones 设计为可扩展、模块化、全自动化，提供基于模板的方案供新项目使用
+- 独立订阅的核心原因是按特定目的隔离，每个订阅服务单一用途
+- Privileged Identity Management (PIM) 和 Privileged Access Groups 管理用户访问，确保角色和策略的正确执行
+- Terraform Cloud 利用 Terraform State 管理跨订阅依赖，支持分层架构
+
+## Key Quotes
+> "The primary goal is to minimize cross-team dependencies through automation, granting teams greater independence in deploying innovative solutions within the Azure environment." — Kishore Garlopati，演讲核心目标
+
+> "The core reason of these individual or isolated subscriptions is you are basically containing a subscription for a specific purpose." — 独立订阅的核心设计原则
+
+> "This sandbox is an interesting one because these landings on subscriptions allows your workloads." — Sandbox 环境允许团队在隔离环境中实验工作负载
+
+## Key Concepts
+- [[Azure Landing Zone]]：Azure 云环境的托管基础框架，通过管理组和订阅分层实现安全、合规和可管理性，为工作负载提供标准化入口。与 [[AWS Landing Zone]] 同属多云 Landing Zone 架构的两种实现
+- [[Management Groups]]：Azure 管理组，类似于 Windows 父目录结构，用于组织和治理 Azure 租户内的实体，可分层级继承策略和访问控制
+- [[Terraform Cloud]]：HashiCorp 的 Terraform 云平台，提供 IaC 状态管理、工作流自动化和团队协作能力，用于管理跨订阅的基础设施依赖
+- [[Privileged Identity Management (PIM)]]：Azure AD 的特权身份管理服务，实现实时细粒度访问控制，确保用户仅在需要时获得特权
+- [[Privileged Access Groups]]：PIM 的组成部分，通过访问组管理用户权限，支持基于角色的策略执行
+
+## Key Entities
+- [[Kishore Garlopati]]：演讲者，Azure Landing Zone 架构overview主讲人
+- [[Micro Focus]]：使用 Azure Landing Zone 进行云转型的企业组织，参考 [[AWS Landing Zone]] 在 Micro Focus 的实践经验
+
+## Connections
+- [[AWS Landing Zone]] ← related_to ← [[Azure Landing Zone]]（同属 Landing Zone 架构，AWS 与 Azure 的不同实现）
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← related_to ← [[AWS Landing Zone]]（AWS Landing Zone 基础入门）
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← related_to ← [[AWS Landing Zone]]（AWS Landing Zone 设计复习）
+- [[ctp-topic-47-enterprise-architecture-cloud-standards]] ← extends ← [[AWS Landing Zone]]（企业架构云标准扩展）
+- [[Terraform]] ← implements ← [[Terraform Cloud]]（Terraform Cloud 是 Terraform 的云端编排平台）
+
+## Contradictions
+- 无已知冲突内容

wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md

@@ -0,0 +1,52 @@
+---
+title: "CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Landing Zone 设计复习，重点对比 SaaS（生产）与 Labs（开发）两种 Landing Zone 环境的架构差异与近期变更
+- 问题域：企业多账户 AWS 环境下的账户结构设计、共享服务架构、网络分段策略、以及 SaaS 与 Labs 的职责划分
+- 方法/机制：基于 Gruntwork Terraform 模板构建 Landing Zone IaC；通过 CCOEs CloudTrail 替代 Gruntworks CloudTrail 实现统一审计；网络账户 Checkpoint 重新路由入站流量；网络分段阻断 SaaS 工作负载的直接连通性
+- 结论/价值：明确 SaaS = 生产、Labs = 开发的核心定位；PoC Landing Zone 将并入 Labs 以最大化资源共享；Cloud Technology Design Forum 推动 Micro Focus 云交付标准化
+
+## Key Claims（用中文描述）
+- Gruntwork 框架的 Landing Zone 通过 Terraform 模板以 IaC 方式构建
+- SaaS Landing Zone 为每个产品区域提供客户专属的产品账户，通过共享服务账户实现安全、日志和网络互联
+- Gruntwork 账户跨所有账户管理 AMI、日志和安全策略
+- 网络分段策略将阻断对 SaaS 工作负载的直接连通性
+- CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一云审计
+- 入站流量拟通过 Network 账户的 Checkpoint 重新路由
+- 原生 AWS Backup 有望成为强制要求
+- 新账户可能取消 Management VPC
+- SaaS 用于生产环境，Labs 用于开发环境（PoC Landing Zone 将并入 Labs）
+
+## Key Quotes
+> "Our AWS landing zones, they're built infrastructure as code as you'd expect on terraform templates using the grunt work framework." — Landing Zone 的 IaC 实现方式
+> "Basically, the only answer is that SAS is production, Labs is development." — SaaS 与 Labs 的本质区别
+
+## Key Concepts
+- [[AWS-Landing-Zone]]：AWS 多账户架构的基础框架，通过账户隔离实现安全、合规和可管理性
+- [[Gruntwork]]：提供生产级 Terraform 模块的基础设施库，Micro Focus 基于此构建 Landing Zone
+- [[Shared-Services-Account]]：托管共享服务（Artifactory、Cyber Eupriva、ArcSight、监控等）的集中账户
+- [[Core-Accounts]]：包含 Active Directory、DNS 和 Network 账户，支持 IT 服务和 Micro Focus 基础设施
+- [[Product-Accounts]]：托管各产品线的 IT 产品、项目、应用程序及相关 AWS 资源，由各项目团队管理
+- [[Gruntwork-Accounts]]：跨所有账户管理 AMI、日志和安全策略的集中账户
+- [[CCOEs-CloudTrail]]：由 CCOE 团队管理的统一 CloudTrail，替代原有的 Gruntworks CloudTrail
+- [[Network-Segmentation]]：通过 Checkpoint 防火墙和网络分段策略阻断对 SaaS 工作负载的直接连通性
+
+## Key Entities
+- [[Cloud-Technology-Design-Forum]]：Micro Focus 云技术设计论坛，致力于标准化和集中化云交付产品（包括 Landing Zone 设计）
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← extends ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]
+- [[ctp-topic-7-saas-landing-zone-design]] ← related_to ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]
+- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging]] ← related_to ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]
+
+## Contradictions
+- （暂无检测到与其他 Wiki 页面的明显冲突）

wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md

@@ -0,0 +1,61 @@
+---
+title: "CTP Topic 40 SaaS Database Architecture On AWS Cloud"
+type: source
+tags:
+  - SaaS
+  - Database
+  - Architecture
+  - AWS
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud]]
+
+## Summary（用中文描述）
+- 核心主题：SAS 数据库团队在 AWS 云上的数据库架构与运维实践
+- 问题域：企业级 SaaS 数据库管理、跨区域多数据库引擎运维、数据库高可用架构
+- 方法/机制：
+  - 全球分布式团队（美国/加拿大/印度/以色列）提供 24/7 支持
+  - 支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多种数据库引擎
+  - 多可用区高可用部署（Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA）
+  - 使用 Terraform、AWS CLI、Shell/PowerShell 脚本实现基础设施自动化
+- 结论/价值：提供企业级数据库运维的最佳实践参考，包括多数据库引擎管理、多可用区高可用设计、以及与 AWS 原生服务（CloudWatch、CloudTrail、Config）的集成
+
+## Key Claims（用中文描述）
+- SAS 数据库团队在全球 4 个国家设有办公地点，管理 500+ 数据库和 1000+ DB 服务器
+- 数据库主要部署在 Application VPC 内，集成安全措施
+- 高可用架构采用三可用区部署模式：一区主库、二区备用库、三区见证节点
+- 报告数据库在第三可用区部署只读仓库，通过 VPN 安全访问
+- Oracle GoldenGate 用于多租户场景，支持平滑迁移（零停机或最小停机）
+- 日常运维每月处理 400-500 个 SSR 和 IM，每月至少执行 10 个变更
+
+## Key Quotes
+> "The idea was to move those databases seamless without downtime or with minimum downtime." — 描述 Oracle GoldenGate 数据中心迁移项目的核心目标
+
+> "Databases reside mostly on application VPCs with integrated security measures." — 数据库安全部署原则
+
+## Key Concepts
+- [[高可用（High Availability）]]：关注系统运行时间，MTBF 为衡量指标
+- [[Oracle Data Guard]]：Oracle 数据库的高可用解决方案，用于主备复制和故障切换
+- [[Multi-AZ Deployment]]：跨多个可用区部署数据库，确保故障隔离和灾难恢复能力
+- [[Database Migration]]：使用 Oracle GoldenGate 实现零停机或最小停机迁移
+- [[DB-as-a-Service]]：托管数据库服务模式（AWS RDS、Aurora）
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，提供基础设施和托管数据库服务
+- [[Amazon RDS]]：关系型数据库服务，支持 Multi-AZ 部署
+- [[Amazon Aurora]]：云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构
+- [[AWS CloudWatch]]：监控和可观测性服务
+- [[Terraform]]：基础设施即代码工具
+- [[Micro Focus]]：SAS 产品的母公司，数据库团队隶属该组织
+
+## Connections
+- [[ctp-topic-7-saas-landing-zone-design]] ← related_to ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
+- [[ctp-topic-51-purpose-built-databases]] ← extends ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
+- [[ctp-topic-66-rds-vs-aurora]] ← related_to ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
+- [[ctp-topic-44-aws-backup-in-micro-focus]] ← related_to ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
+
+## Contradictions
+- 无明显冲突内容

wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md

@@ -0,0 +1,61 @@
+---
+title: "CTP Topic 44 AWS Backup in Micro Focus"
+type: source
+tags:
+  - AWS
+  - Backup
+  - DR
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Backup 托管服务与 Micro Focus 当前备份流程的差距分析，以及向 AWS Backup 迁移的评估。
+- 问题域：企业级数据保护、灾难恢复策略、跨账户/跨区域备份合规性。
+- 方法/机制：
+  - 四级 DR 策略（RTO/RPO 从数小时到近乎零）
+  - AWS Backup 集中化备份保管库 + 备份计划 + 时间点恢复
+  - 基于角色的访问控制（IAM）+ CloudWatch 监控
+  - 不可变性（Immutability）防勒索软件
+  - 法律保留（Legal Holds）满足合规要求
+- 结论/价值：AWS Backup 相比当前分散式快照管理有明显优势（集中化、不可变性、跨账户/跨区域），但存在卷粒度限制、崩溃一致快照等局限性，需根据 RTO/RPO 需求选择合适策略。
+
+## Key Claims（用中文描述）
+- AWS Backup 通过集中化备份保管库和备份计划，消除了当前多团队分散管理快照的错误风险。
+- 不可变性（Immutability）是防止勒索软件攻击备份数据的核心机制，当前 CCIE vault 无法提供此保障。
+- Pilot Light 策略可在 1 小时内恢复，Warm Standby 可在数分钟内恢复，Active-Active 提供近乎零停机，但成本递增。
+- AWS Backup 对附加到 EC2 的多个卷强制备份所有卷，无法选择性排除特定卷。
+- Amazon 建议数据库不再使用热备份，快照是崩溃一致的，支持增量备份。
+
+## Key Quotes
+> "AWS Backup 是一个托管服务，用于在 AWS 云中集中化和自动化数据保护。它支持跨账户和跨区域备份，并提供不可变性以防止勒索软件等威胁。" — 视频摘要
+> "AWS Backup 加密所有备份，包括静态和传输中的数据。" — 视频摘要
+> "Amazon 不再建议数据库使用热备份，指出快照是崩溃一致的，支持增量备份。" — 视频摘要
+
+## Key Concepts
+- [[AWS Backup]]：AWS 托管的集中化数据保护服务，支持跨账户和跨区域备份，提供不可变性和法律保留功能。
+- [[不可变性（Immutability）]]：防止备份被篡改或删除的机制，是防勒索软件的关键。
+- [[RTO（Recovery Time Objective）]]：恢复时间目标，衡量从故障恢复到服务可用的时间。
+- [[RPO（Recovery Point Objective）]]：恢复点目标，衡量可接受的最大数据丢失时间窗口。
+- [[灾难恢复策略]]：Backup and Restore / Pilot Light / Warm Standby / Active-Active 四级递进策略。
+- [[法律保留（Legal Holds）]]：用于合规性保留特定备份，隔离而不被删除。
+- [[Pilot Light]]：DR 策略之一，数据持续复制到 DR 区域，可在 1 小时内恢复核心服务。
+- [[Warm Standby]]：DR 策略之一，应用在生产 DR 区域以较小规模持续运行，可在数分钟内完全扩缩。
+- [[Active-Active]]：DR 策略之一，应用在两个区域同时运行，提供近乎零停机和零数据丢失。
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，提供 AWS Backup 托管服务的云平台。
+- [[CCIE 门户]]：当前管理快照的内部 Micro Focus 平台，通过标签跟踪备份过程和错误通知。
+- [[Cloud Transformation Programme (CTP)]]：云转型计划，该视频属于 01_AWS-Landing-Zone 系列第 44 个主题。
+
+## Connections
+- [[ctp-topic-44-aws-backup-in-micro-focus]] ← extends ← [[AWS Backup]]
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← depends_on ← [[AWS Backup]]
+- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] ← extends ← [[ctp-topic-44-aws-backup-in-micro-focus]]
+- [[RTO vs RPO]] ← related ← [[AWS Backup]]
+
+## Contradictions
+- 无明显内容冲突。本视频内容与 [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] 和 [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] 构成递进关系。

wiki/sources/ctp-topic-46-netapps-on-aws.md

@@ -0,0 +1,67 @@
+---
+title: "CTP Topic 46 NetApps on AWS"
+type: source
+tags: [NetApp, AWS, Storage, CTP, Cloud-Storage]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-46-netapps-on-aws]]
+
+## Summary（用中文描述）
+- 核心主题：NetApp 存储系统（传统 + AWS 云版本）的架构、组件、数据分层、安全、备份/DR、迁移工具及企业实际使用情况
+- 问题域：企业如何将 NetApp 存储从本地扩展到 AWS 云端，实现统一存储管理
+- 方法/机制：Cloud Volume ONTAP (CVO) 通过 EC2 实例提供企业级存储；EBS 作为底层存储介质；Data Tiering 自动在 EBS 和 S3 之间分层；SnapMirror 实现跨集群数据复制
+- 结论/价值：NetApp on AWS 是企业云存储转型的成熟方案，支持单节点/HA架构，提供块级复制、S3 分层、统一管理（Cloud Manager），组织已在 15 个 AWS 区域部署约 1.3 PB 数据
+
+## Key Claims（用中文描述）
+- NetApp ONTAP 是统一的存储操作系统，支持 SMB、NFS、FC、FCOE、iSCSI 等多种协议
+- Cloud Volume ONTAP (CVO) 通过 EC2 实例在 AWS 上提供软件定义的存储，支持单节点或 HA 配对
+- 数据分层机制：活跃数据存储在 EBS，非活跃数据（30天以上）自动迁移到 S3，访问时拉回 EBS
+- SnapMirror 通过块级复制实现 NetApp 集群间的数据同步，基线复制后仅传输增量变更
+- 从本地迁移到 AWS 的工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync、Silver Peak WAN Optimizer
+
+## Key Quotes
+> "NetApp primarily supports SMB, NFS, FC, FCOE, and ISCSI protocols, often configured as a single node or HA pair." — NetApp 传统架构概述
+> "The organization has around 15 NetApp clusters in various AWS regions, hosting approximately 1.3 petabytes of data." — 企业实际使用规模
+> "Data inactive for 30 days or more is automatically moved to S3 and pulled back to EBS when accessed." — CVO 数据分层机制
+> "SnapMirror copies volumes and their snapshots, with baseline copies performing initial full data replication, subsequent updates copy only the changes." — SnapMirror 复制策略
+
+## Key Concepts
+- [[Cloud Volume ONTAP (CVO)]]：NetApp ONTAP 的 AWS 云版本，通过 EC2 实例运行，支持单节点或 HA 架构，使用 EBS 作为存储后端
+- [[ONTAP]]：NetApp 统一存储操作系统，管理聚合、卷、Qtree、LIF、SVM 等存储组件
+- [[Aggregate]]：由多个磁盘组成的 RAID 组，构成 NetApp 的基础存储池
+- [[FlexVol]]：托管在 Aggregate 之上的灵活数据容器，通过 NFS 或 CIFS 呈现给主机
+- [[Qtree]]：卷的进一步细分，支持权限和配额管理等特殊属性
+- [[LUN (Logical Unit Number)]]：块级存储的逻辑表示，通过 FC 或 iSCSI 呈现给主机
+- [[LIF (Logical Interface)]]：物理网卡之上的接口，承载 IP 地址或 WWPN，用于节点管理、数据复制和数据服务
+- [[SVM (Storage Virtual Machine)]]：NetApp 系统的虚拟隔离，支持多租户，每个 SVM 视为独立操作系统
+- [[Data Tiering]]：利用 EBS 和 S3 实现存储成本优化，活跃数据在 EBS，非活跃数据自动迁移至 S3
+- [[SnapMirror]]：NetApp 数据复制工具，支持跨集群块级同步，基线全量复制后仅同步增量变更
+- [[Snapshot]]：点-in-time 只读文件系统镜像，通过指针创建，最小化空间消耗
+- [[HA Pair (High Availability)]]：高可用配对，通过故障转移机制确保存储服务连续性
+- [[Floating IP]]：HA 架构中的浮动 IP，客户端通过唯一 IP 地址访问，故障时 IP 漂移到备用节点
+- [[Takeover/Giveback]]：HA 接管和归还过程，故障节点的服务切换和恢复
+- [[NetApp Encryption]]：256-bit 加密，支持 AWS KMS 和 NetApp 自身加密解决方案
+
+## Key Entities
+- [[NetApp]]：全球领先的存储和数据管理解决方案提供商，ONTAP 为其核心操作系统
+- [[Cloud Manager]]：NetApp 的集中管理平台，用于管理 AWS 中的 Cloud Volume ONTAP
+- [[FSX for NetApp]]：AWS 原生托管 NetApp 服务（under POC），提供更简化的部署体验
+- [[AWS EBS]]：Elastic Block Store，CVO 的存储后端，支持 GP3、GP2、IO1、IO2、ST1 等多种卷类型
+- [[AWS KMS]]：Key Management Service，NetApp 加密方案的密钥管理集成
+- [[McAfee VSES]]：McAfee 杀毒集成，NetApp 用于 SMB/CIFS 和 NFS 的按访问和按需扫描
+- [[Terraform]]：IaC 工具（under plan），计划用于 NetApp 部署自动化
+- [[Cityscope]]：[监控工具]，组织当前使用的 NetApp 监控平台之一
+- [[WebTool]]：[监控工具]，组织当前使用的 NetApp 监控平台之一
+
+## Connections
+- [[ctp-topic-44-aws-backup-in-micro-focus]] ← relates_to ← [[ctp-topic-46-netapps-on-aws]]（均涉及企业数据备份与灾备策略）
+- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services]] ← relates_to ← [[ctp-topic-46-netapps-on-aws]]（均涉及工作负载从本地向 AWS 迁移）
+- [[Cloud Volume ONTAP (CVO)]] ← extends ← [[ONTAP]]（ONTAP 的云版本）
+- [[FSX for NetApp]] ← extends ← [[Cloud Volume ONTAP (CVO)]]（AWS 原生管理的 NetApp 服务）
+- [[Data Tiering]] ← depends_on ← [[AWS EBS]] + [[AWS S3]]
+- [[SnapMirror]] ← used_in ← [[ctp-topic-46-netapps-on-aws]]（灾备复制方案）
+
+## Contradictions
+- 暂无发现内容冲突。本文档主要聚焦 NetApp 存储技术，与 Wiki 中其他 CTP Topic（如 RDS vs Aurora、AWS Backup）属不同技术领域（块存储 vs 数据库备份），互补关系大于冲突。

wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md

@@ -0,0 +1,46 @@
+---
+title: "CTP Topic 47 Enterprise Architecture Cloud Standards"
+type: source
+tags: [Enterprise-Architecture, Cloud-Standards, CTP, Landing-Zone, Terraform]
+sources: []
+last_updated: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-47-enterprise-architecture-cloud-standards]]
+
+## Summary（用中文描述）
+- 核心主题：企业架构云标准、Landing Zone、云防护栏（Guardrails）
+- 问题域：如何在云环境中标准化企业架构，指导应用团队了解可用资源和需求
+- 方法/机制：Landing Zone 框架（账户结构+网络+安全+访问管理+遥测）、Terraform/Terragrunt IaC、云防护栏文档（设计概念+最佳实践）
+- 结论/价值：标准化云架构、预配置安全模型、降低应用团队安全审查负担、减少重复造轮子
+
+## Key Claims（用中文描述）
+- Landing Zone 框架通过聚焦安全、合规和可管理性，为云工作负载提供托管基础
+- 账户结构与开发/预发布/生产环境对齐，角色通过零信任和最小权限原则定义访问控制
+- Terraform 允许以代码形式指定期望环境，促进标准化和可测试性
+- 云防护栏文档捕获强制性要求和最佳实践，指导可扩展性、成本最小化和灵活性
+- 功能分区将单体应用拆分为更小的独立模块或无服务器函数
+
+## Key Quotes
+> "A landing zone is a framework for hosting cloud workloads, focusing on security, compliance, and manageability." — Lindsay，企业架构师
+> "We want your knowledge collected here for reuse and help other app developers down the road." — Lindsay，号召应用团队贡献防护栏内容
+
+## Key Concepts
+- [[Landing Zone]]：托管云工作负载的框架，聚焦安全、合规和可管理性，包含账户结构、网络、安全、访问管理和遥测
+- [[Zero Trust Architecture]]：零信任安全架构，通过最小权限原则定义访问控制
+- [[Infrastructure as Code]]：基础设施即代码，使用 Terraform 实现环境标准化和可测试性
+- [[Cloud Guardrails]]：云防护栏文档，捕获强制性要求和最佳实践
+- [[Functional Partitioning]]：功能分区，将单体应用拆分为更小的独立块或无服务器函数
+- [[Terragrunt]]：Terraform 的包装器，用于生成不同环境
+
+## Key Entities
+- [[Lindsay]]：企业架构师，具有开发背景，以学习者视角分享云架构知识
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← related_to ← [[Landing Zone]]（Topic 1 是 Gruntwork Landing Zone 基础）
+- [[Terraform]] ← uses ← [[Infrastructure as Code]]
+- [[Cloud Guardrails]] ← guides ← [[Enterprise Architecture Cloud Standards]]
+
+## Contradictions
+- 无已知冲突内容

wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md

@@ -0,0 +1,64 @@
+---
+title: "CTP Topic 50 AMI Roadmap for AWS AMIs"
+type: source
+tags: [AWS, AMI, Roadmap, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis]]
+
+## Summary（用中文描述）
+- 核心主题：CCOE AMI 路线图与 AWS 标准 AMI 生命周期规划
+- 问题域：企业 AWS 云环境中操作系统镜像的版本规划、EOL 时间线管理、新 AMI 添加流程
+- 方法/机制：CCOE 每两个月发布一次加固 AMI；路线图按 ADM 需求制定优先级；变更日志通过 CCRE 门户发布；新 AMI 需经过服务集成→功能启用→构建测试三阶段验证
+- 结论/价值：统一企业级 AMI 治理标准；提前规划 OS EOL 迁移；AMI 通过跨账号共享机制分发至所有组织账户
+
+## Key Claims（用中文描述）
+- CCOE 提供每两个月一次的对齐安全标准的加固 AMI
+- 自 2023 年 5 月起，所有 ARM 处理器相关的 AMI 将同步发布
+- AMI 路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交
+- Windows Server 2008/2008 R2 已于 2020 年 1 月 EOL，CentOS 8 已于 2021 年 12 月 EOL，Windows Server 2012 将于 2023 年 10 月 EOL，Red Hat 7 和 CentOS 7 将于 2024 年 6 月 EOL
+- AMI 通知通过邮件发送至 CCOE notifications PDL 订阅者
+- CCRE 门户现提供变更日志，记录 CCRE 所做的最新变更
+- AMI 功能包含：域加入服务、启用 SSH、集成 McAfee 防病毒服务、启用 DNS 设置、更新云初始化流程、启用 SSM 客户端、边缘安装
+- AMI 通过跨账号共享（AMI Sharing）分发给组织内所有账户，包括 AMI 本身、EBS 卷和 KMS 密钥
+
+## Key Quotes
+> "The CCOE provides hardened AMIs on a bi-monthly basis aligned with security standards." — CCOE AMI 发布节奏说明
+> "Starting May 2023, all ARM processors related to AMIs will be released." — ARM AMI 同步发布里程碑
+> "The order was created mainly by ADM requirements. Any requirements to change the prioritization of the roadmap should go through the demand pipeline process." — 路线图优先级机制
+> "The AMIs are shared with every account in the organization, including the AMI itself, EBS volumes, and KMS keys." — 跨账号分发机制
+
+## Key Concepts
+- [[Foundation AMI]]：CCOE 提供的安全加固基础镜像，是产品团队构建产品特定 AMI 的基础（本话题中称"CCOE AMI"，与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 中的 Foundation AMI 概念一致）
+- [[OS-End-of-Life]]：操作系统生命周期终止管理，包括 Windows Server 2008/2008 R2、CentOS 8、Windows Server 2012、RHEL 7、CentOS 7 等多个 EOL 时间节点
+- [[AMI Sharing]]：跨账号 AMI 共享机制，将 AMI、EBS 卷和 KMS 密钥分发给组织内所有账户
+- [[ARM-AMI]]：ARM 处理器架构的 AMI，自 2023 年 5 月起纳入统一发布计划
+- [[CCOE]]：Cloud Center of Excellence，负责提供和维护企业标准 AMI
+- [[ADM]]：Architecture Decision Management，AMI 路线图优先级的主要驱动来源
+
+## Key Entities
+- [[CCOE]]（组织）：Cloud Center of Excellence，负责提供安全加固 AMI 和维护 AMI 路线图
+- [[AWS]]：提供 EC2 AMI 服务，是本话题所有 AMI 的底层平台
+- [[Amazon Linux]]：AWS 自有 Linux 发行版，当前版本包括 Amazon Linux 2 及规划中的 Amazon Linux 2022
+- [[Ubuntu]]：社区支持的 Linux 发行版，CCOE AMI 支持多个 Ubuntu 版本，包括 ARM 版本（自 2023 年 5 月）
+- [[CentOS]]：Red Hat 赞助的社区 Linux 发行版，CentOS 7 和 CentOS 8 分别将于 2024 年 6 月和 2021 年 12 月 EOL
+- [[Rocky Linux]]：CentOS 替代方案，Rocky 8 和 Rocky 9 纳入 AMI 路线图（2023 年 3 月）
+- [[Red Hat Enterprise Linux]]：企业级 Linux 发行版，RHEL 7 将于 2024 年 6 月 EOL
+- [[SLES]]（SUSE Linux Enterprise Server）：企业级 Linux 发行版，SLES 15 纳入 AMI 路线图（2022 年 11 月）
+- [[Windows Server]]：微软服务器操作系统，Windows 2008/2008 R2 已 EOL，Windows Server 2012 即将 EOL
+- [[McAfee]]：企业级防病毒解决方案，集成于 CCOE AMI 中
+
+## Connections
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] ← extends ← [[ctp-topic-50-ami-roadmap-for-aws-amis]]
+- [[ctp-topic-58-aws-ec2-image-builder]] ← extends ← [[ctp-topic-26-standard-ami-build-publish-share-processes]]
+- [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]] ← depends_on ← [[ctp-topic-50-ami-roadmap-for-aws-amis]]
+- [[ctp-topic-50-ami-roadmap-for-aws-amis]] ← extends ← [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]
+
+## Contradictions
+- 与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 存在描述角度差异：
+  - 冲突点：AMI 叫法不统一——本话题称为"CCOE AMI"，Topic 26 称为"Foundation AMI"
+  - 当前观点：CCOE AMI 即 Foundation AMI，两者描述的是同一个实体
+  - 对方观点：Topic 26 从生命周期管理角度描述（构建→发布→共享），本话题从路线图规划角度描述（版本规划→EOL→新 AMI 添加）
+  - 结论：非矛盾而是互补关系，共同构成完整的 AMI 管理体系

wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md

@@ -0,0 +1,64 @@
+---
+title: "CTP Topic 51 Architecting with AWS Purpose-Built Databases"
+type: source
+tags:
+  - AWS
+  - Database
+  - Purpose-Built
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-51-architecting-with-aws-purpose-built-databases]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 专用数据库（Purpose-Built Databases）选型与架构设计原则
+- 问题域：现代应用的数据层设计——如何在多种数据类型和访问模式下选择最优数据库
+- 方法/机制：从用例出发 → 选择最佳工具 → 避免一刀切思维；AWS 提供关系型/NoSQL/内存/图/时序/账本/宽列等全品类专用数据库；DBA 角色从平台管理转向应用创新
+- 结论/价值：正确的数据库选型是应用性能的基础；数据库类型与访问模式的匹配度比"最新最贵"更重要；Duolingo/Netflix/Peloton 等真实案例验证了多数据库混合架构的价值
+
+## Key Claims（用中文描述）
+- AWS 数据库专家 Femi George 认为：现代应用需要"为正确的应用选择正确的专用数据库"，避免用单一关系型数据库解决所有问题
+- 专用数据库选型应考虑：应用规模、用户数量、访问模式、流量峰值、性能需求（延迟、可用性）
+- Duolingo 的多数据库架构：DynamoDB 存储个性化数据 + ElastiCache 缓存高频词/短语 + Aurora 处理事务数据
+- Netflix 使用 DynamoDB 实现高弹性和低延迟 JSON 文档访问
+- Peloton 使用 ElastiCache Redis 为客户提供即时反馈
+- 云时代 DBA 的职能转变：从底层平台管理（备份、补丁）转向应用层创新和查询优化
+
+## Key Quotes
+> "We need to start thinking of the right purpose-built database for the right application." — Femi George, AWS Database Sales Specialist
+> "Amazon Aurora has two flavors, MySQL and PostgreSQL." — Femi George, 强调 Aurora 的双引擎特性
+> "The role of the DBA is evolving in the cloud." — 云时代 DBA 从平台管理转向应用创新
+
+## Key Concepts
+- [[Purpose-Built-Databases]]：AWS 全品类专用数据库体系——关系型/NoSQL/键值/文档/内存/图/时序/账本/宽列，覆盖所有数据模型
+- [[DBA-Role-Evolution]]：云时代数据库管理员职能转变——从平台管理（备份/补丁）转向应用创新（查询优化/架构设计）
+- [[Multi-Database-Architecture]]：多数据库混合架构——根据数据类型选择最优数据库（如 Duolingo：DynamoDB + ElastiCache + Aurora）
+
+## Key Entities
+- [[Amazon-DynamoDB]]：AWS 全托管键值和文档数据库，单位数毫秒性能，日处理万亿级请求
+- [[Amazon-Aurora]]：云原生关系型数据库，支持 MySQL 和 PostgreSQL，存储与计算分离架构
+- [[Amazon-RDS]]：AWS 全托管关系型数据库服务，支持多引擎（MySQL/PostgreSQL/MariaDB/Oracle/SQL Server）
+- [[Amazon-ElastiCache]]：AWS 全托管内存缓存服务，支持 Redis 和 Memcached
+- [[Amazon-Neptune]]：AWS 图数据库，用于欺诈检测、社交网络、推荐系统
+- [[Amazon-Timestream]]：AWS 时序数据库，专为 IoT 和运维监控场景优化
+- [[Amazon-Keyspaces]]：AWS 托管 Apache Cassandra 兼容数据库，提供无服务器选项
+- [[Amazon-DocumentDB]]：AWS MongoDB 兼容文档数据库，支持灵活 schema
+- [[Duolingo]]：多数据库架构实战案例——DynamoDB + ElastiCache + Aurora
+- [[Netflix]]：DynamoDB 生产级用户——高弹性、低延迟 JSON 文档访问
+- [[Peloton]]：ElastiCache Redis 生产级用户——即时客户反馈
+
+## Connections
+- [[Amazon-Aurora]] ← extends ← [[Amazon-RDS]]：Aurora 是 RDS 的云原生演进版本
+- [[Amazon-DynamoDB]] ← alternative_to ← [[Amazon-RDS]]：NoSQL 键值 vs 传统关系型的选型对比
+- [[Amazon-ElastiCache]] ← complements ← [[Amazon-RDS]]：缓存层补充数据库层，提升读取性能
+- [[Amazon-Neptune]] ← specialized_for ← Graph-Use-Cases：图数据库用于关系复杂的场景
+- [[Amazon-Timestream]] ← specialized_for ← Time-Series-Data：时序数据库用于 IoT/监控场景
+- [[ctp-topic-66-rds-vs-aurora]] ← related_to ← [[ctp-topic-51-purpose-built-databases]]：RDS vs Aurora 是关系型数据库内部的选型，本文档覆盖全品类数据库选型
+
+## Contradictions
+- 与 [[ctp-topic-66-rds-vs-aurora]] 的视角互补而非冲突：
+  - 冲突点：无实质性冲突，两者是不同维度的对比
+  - 当前观点（本文档）：Aurora 是 RDS 的云原生演进，提供存储计算分离和更高 IO 性能
+  - 对方观点（CTP 66）：从 PostgreSQL 迁移视角对比，RDS 更适合小规模低成本场景，Aurora 更适合大规模高性能场景

wiki/sources/ctp-topic-58-aws-ec2-image-builder.md

@@ -0,0 +1,57 @@
+---
+title: "CTP Topic 58 AWS EC2 Image Builder"
+type: source
+tags:
+  - AWS
+  - EC2
+  - Image-Builder
+  - CTP
+  - AMI
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS EC2 Image Builder 替代 Packer/Jenkins 实现企业级 AMI 生命周期自动化管理
+- 问题域：当前 AMI 发布流程依赖 GitLab 加固脚本 + Jenkins + Packer，存在修改周期长、跨 Landing Zone 兼容性差、手动 Bakery 自动化不足等问题
+- 方法/机制：Image Builder 通过 Pipeline（流水线）/Recipe（配方）/Component（组件）/Infrastructure Config 四层抽象，将 CCOE 加固脚本模块化为可复用组件，产品团队通过服务模块向 Golden AMI 添加组件
+- 结论/价值：提升生产力（自动化）、构建时内建测试、合规加固标准、跨账户跨区域分发；与 AWS Organizations/RAM 集成；支持 AWS Inspector Lambda 工作流做 AMI 安全扫描
+
+## Key Claims（用中文描述）
+- Image Builder 通过 Pipeline/Recipe/Component/Infrastructure Config 四层组件实现 AMI 构建全生命周期自动化
+- 当前 AMI 发布流程（GitLab + Jenkins + Packer）存在修改周期长、跨 LZ 兼容性差、手动 Bakery 自动化不足等缺陷
+- POC 已实现 CentOS 7 和 Ubuntu 18 端到端流水线，CCOE 加固脚本转换为独立组件
+- Lambda 工作流触发 AWS Inspector 扫描、邮件通知、S3 报告归档，维护历史 AMI 数据
+- Qualys 扫描集成正在评估中
+
+## Key Quotes
+> "A component is basically just a particular step that you want to execute in order to achieve the output AMI." — Image Builder 组件定义
+> "Due to these limitations, eventually the product teams try to cater to their requirements by developing some kind of workflow or CI CD pipelines wherein they consume that CCOE AMI and they try to update or install whatever packages they require." — 当前流程的局限性驱动产品团队自建 CI/CD
+> "Product groups can use a service module to add components to the golden AMI. A component is a script, and components should be added in alphabetical order." — 产品团队通过服务模块添加组件的机制
+
+## Key Concepts
+- [[Golden-AMI]]：由 CCOE 维护的标准化基础镜像，产品团队在其上添加自定义组件
+- [[CCOE]]（Cloud Center of Excellence）：云卓越中心，负责维护 Golden AMI 和加固脚本
+- [[Image-Pipeline]]：定义 AMI 发布时间线、安装步骤、安全加固和分发策略
+- [[Image-Recipe]]：YAML 格式定义源 AMI 到输出 AMI 的转换规则
+- [[Image-Component]]：在源 AMI 内执行的具体步骤（安装包、运行脚本）
+- [[Infrastructure-Configuration]]：定义构建 AMI 所需的 EC2 实例属性（类型/VPC/子网/安全组）
+- [[Distribution-Settings]]：管理 AMI 跨区域跨账户的分发配置
+- [[AWS-Inspector]]：AWS 原生 AMI 安全扫描工具
+
+## Key Entities
+- [[AWS]]：Image Builder 服务的云提供商
+
+## Connections
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] ← builds_on ← [[ctp-topic-58-aws-ec2-image-builder]]（Image Builder 是对 Packer/Jenkins AMI 流程的升级）
+- [[ctp-topic-58-aws-ec2-image-builder]] ← depends_on ← [[learning-sessions-standard-amis-updates]]（CCOE 加固脚本和标准 AMI 生命周期管理是 Image Builder 的输入）
+- [[ctp-topic-50-ami-roadmap-for-aws-amis]] ← related_to ← [[ctp-topic-58-aws-ec2-image-builder]]（AMI 路线图与 Image Builder 自动化策略相关）
+
+## Contradictions
+- 与 [[ctp-topic-26-standard-ami-build-publish-share-processes]]：
+  - 冲突点：当前 AMI 流程（GitLab + Jenkins + Packer）vs Image Builder 自动化流程
+  - 当前观点：Packer/Jenkins 流程是现状，存在修改周期长、跨 LZ 兼容性差等问题
+  - 对方观点：Jenkins 多分支流水线 + 机器人框架验证已将验证周期从 3-4 天缩短至 60 分钟
+  - 说明：两者并非完全矛盾——Image Builder 替代 Packer 作为镜像构建工具，而 Jenkins 流水线可能继续用于 Terraform 部署触发

wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md

@@ -0,0 +1,69 @@
+---
+title: "CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora"
+type: source
+tags:
+  - AWS
+  - RDS
+  - Aurora
+  - PostgreSQL
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]
+
+## Summary（用中文描述）
+- 核心主题：PostgreSQL 在 Amazon RDS 与 Aurora 两种托管方案之间的核心差异对比
+- 问题域：AWS 云数据库选型——何时选 RDS，何时选 Aurora，成本与性能的权衡
+- 方法/机制：从架构设计、最小实例规格、最大扩展能力、自动扩缩容、故障恢复时间、存储灵活性、端点设计、Blue-Green 部署、监控方案及高可用性能调优等多维度进行系统对比
+- 结论/价值：数据库规模 < 10-20TB 优先选 RDS（成本更低、存储选项更灵活）；超过该规模或有严格 RTO 要求（30 秒）则选 Aurora（跨 AZ 六副本架构、自动故障恢复）
+
+## Key Claims（用中文描述）
+- RDS 因架构简单、提供更小规格实例，初始成本低于 Aurora；Aurora 最小规格较高
+- Aurora 单集群最大容量和 IO 性能优于 RDS，适合超过 10-20 TB 的数据库
+- Aurora Serverless v2 支持自动扩缩容，但对实例类型、版本和区域有限制
+- Aurora 的 RTO（恢复时间目标）为 30 秒，RDS 为 2 分钟（AZ 故障场景）
+- RDS 提供多种存储类型（GP2、GP3、预置 IOPS、磁性），Aurora 按 IO 计数收费
+- Aurora 采用跨 3 个 AZ 的 6 块 EBS 卷组成的共享集群卷，读副本无需重新复制数据
+- Aurora MySQL 支持 Blue-Green 部署，PostgreSQL 不支持
+- Aurora 使用临时 SSD（短暂存储）用于临时工作，RDS 使用 EBS
+
+## Key Quotes
+> "Aurora IO is generally unbounded because they're motivated to give you as much IO as you can consume because they're charging you per IO." — Aurora 按 IO 收费机制使其有动力提供尽可能高的 IO
+
+> "With Aurora, you get six EBS volumes. They're spread across three availability zones." — Aurora 跨 3 AZ 的六副本架构是高性能和高可用的基础
+
+> "With RDS, you get to choose multiple different storage mechanisms." — RDS 存储灵活性优势
+
+## Key Concepts
+- [[RTO（Recovery Time Objective）]]：从故障中恢复的时间目标，Aurora 为 30 秒，RDS 为 2 分钟
+- [[Shared Cluster Volume]]：Aurora 的跨 AZ 共享存储卷，6 块 EBS 卷组成，读副本共享同一数据副本无需重新复制
+- [[Blue-Green Deployment]]：Aurora MySQL 支持主备环境切换式部署，用于大版本升级，PostgreSQL 不支持
+- [[Endpoint Architecture]]：Aurora 提供独立的 Writer Endpoint 和 Reader Endpoint，RDS 仅有一个集群端点
+- [[Aurora Global]]：Aurora 跨区域复制方案，支持干净的托管式切换和故障转移
+- [[Temporary Storage]]：Aurora 使用临时 SSD（短暂存储）处理临时工作，固定大小取决于实例类型
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，提供 RDS 和 Aurora 两款托管数据库服务
+- [[Amazon RDS]]：关系型数据库服务，计算与存储分离（EBS），支持 Multi-AZ 部署
+- [[Amazon Aurora]]：云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构
+- [[Greg Klau]]：CTP Topic 66 讲师，主讲 PostgreSQL RDS vs Aurora 差异对比
+- [[EBS]]：Elastic Block Store，RDS 的存储后端；Aurora 的底层存储（6 块卷跨 3 AZ）
+- [[CloudWatch]]：AWS 监控服务，RDS 和 Aurora 均支持
+- [[Performance Insights]]：AWS 数据库性能监控工具，Aurora 和 RDS 均支持
+- [[JDBC]]：Java Database Connectivity，连接串可配置 reader/writer 端点以提升韧性
+
+## Connections
+- [[Amazon Aurora]] ← extends ← [[Amazon RDS]]
+- [[RTO（Recovery Time Objective）]] ← depends_on ← [[Shared Cluster Volume]]
+- [[Blue-Green Deployment]] ← supports ← [[Aurora Global]]
+- [[Aurora Global]] ← enables ← [[Multi-Region Failover]]
+- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]] ← related_to ← 本页（AWS 数据库选型）
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← related_to ← 本页（灾备策略）
+
+## Contradictions
+- 与 [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]] 冲突：
+  - 冲突点：Terraform 部署 RDS 时对存储类型的选择
+  - 当前观点：Aurora 按 IO 收费适合高 IO 场景，RDS 提供多种存储类型（GP2/GP3/预置 IOPS）适合成本敏感型场景
+  - 对方观点：Terraform IaC 部署关注点是资源标准化和可重复性，存储选型属于运维决策

wiki/sources/ctp-topic-68-introduction-to-redshift.md

@@ -0,0 +1,63 @@
+---
+title: "CTP Topic 68 Introduction to Redshift"
+type: source
+tags:
+  - AWS
+  - Redshift
+  - Data-Warehouse
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Redshift 数据仓库服务的基础架构、核心组件及关键特性
+- 问题域：云端 PB 级数据仓库的选型与架构设计
+- 方法/机制：Leader Node + Compute Node MPP 并行架构、列式存储、行式存储、数据压缩（ZSTD/LZO）、Sort Key、Distribution Key
+- 结论/价值：Redshift 是完全托管的 PB 级云数据仓库，支持 OLAP，提供 Leader Node 负责查询规划和元数据管理，Compute Node 通过 Slices 执行并行查询；RA3 实例类型性价比最优，支持 AWS 托管 NVMe 存储；Sort Key 和 Dist Key 是性能优化的关键配置
+
+## Key Claims（用中文描述）
+- Redshift 通过 Leader Node 管理 Schema、元数据和查询计划，将指令分发至 Compute Node 执行，实现 MPP（大规模并行处理），显著提升查询速度和响应时间
+- Redshift 支持列式存储（适合数据仓库操作）和行式存储两种模式，列式存储因更快的查询性能和更高的内存利用率而更适合 OLAP 场景
+- RA3 实例类型因其成本效益和大规模存储容量而被推荐，底层使用 AWS 托管的 NVMe 存储
+- Sort Key（排序键）和 Dist Key（分布键）是 Redshift 性能优化的核心机制，决定数据分布和查询执行效率
+
+## Key Quotes
+> "Redshift is a fully managed, petabyte-scale data warehouse solution in the cloud. It is designed for data warehousing, enabling quick data retrieval from large datasets." — 视频摘要
+
+> "The leader node manages schema, warehouse metadata, and query planning, distributing instructions to compute nodes." — Redshift 架构说明
+
+> "Compute nodes, determined by the instance type, execute queries across slices, processing data and returning results to the leader node." — Compute Node 工作机制
+
+> "RA3 is noted for its cost-effectiveness and large storage capacity, utilizing AWS-managed NVMe storage." — RA3 实例优势
+
+## Key Concepts
+- [[MPP (Massively Parallel Processing)]]：通过多个 Compute Node 并行处理查询，提升大规模数据集的查询速度和响应时间
+- [[列式存储（Columnar Storage)]]：数据按列而非按行存储，适合数据仓库的聚合查询和扫描操作，提供更快的查询性能和更高的内存效率
+- [[数据压缩（Data Compression)]]：采用 ZSTD/LZO 等压缩算法减少数据大小，提升 I/O 效率和查询性能
+- [[Sort Key（排序键)]]：决定数据在磁盘上的物理排序顺序，对范围查询和过滤操作性能影响显著
+- [[Distribution Key（分布键)]]：决定数据在 Compute Node 间如何分布，影响数据倾斜和节点间数据传输
+- [[OLAP（在线分析处理)]]：面向复杂分析查询的工作负载类型，Redshift 的核心设计目标
+- [[Leader Node（主节点)]]：Redshift 架构中的协调节点，负责客户端连接、Schema 管理、元数据存储和查询计划生成
+- [[Compute Node（计算节点)]]：Redshift 架构中的执行节点，负责在 Slices 上执行查询并返回结果
+
+## Key Entities
+- [[Amazon Redshift]]：AWS 提供的大规模并行处理数据仓库服务，支持 PB 级数据存储，面向 OLAP 工作负载
+- [[AWS]]：Amazon Web Services，云服务提供商，Redshift 的托管平台
+- [[RA3]]：Redshift 的高性价比实例类型，配备 AWS 托管 NVMe 存储，适合大容量存储场景
+- [[Dense Compute]]：Redshift 高计算密度实例类型，适合计算密集型查询
+- [[Dense Storage]]：Redshift 高存储密度实例类型，适合存储密集型工作负载
+- [[JDBC/ODBC]]：Redshift 客户端驱动协议，客户端应用通过 JDBC/ODBC 连接至 Redshift Cluster
+
+## Connections
+- [[ctp-topic-51-purpose-built-databases]] ← related_to ← [[Amazon Redshift]]
+- [[ctp-topic-66-rds-vs-aurora]] ← related_to ← [[Amazon Redshift]]
+- [[ctp-topic-40-saas-database-architecture-on-aws-cloud]] ← related_to ← [[Amazon Redshift]]
+
+## Contradictions
+- 与 [[ctp-topic-66-rds-vs-aurora]] 的数据写入模式：
+  - 冲突点：Aurora 采用共享存储架构（6副本跨3 AZ），而 Redshift 采用独立 Compute Node 架构；Aurora 更适合写入密集型 OLTP，Redshift 更适合分析密集型 OLAP
+  - 当前观点：Redshift 的列式存储 + MPP 是大规模数据分析的最优架构
+  - 对方观点：Aurora 的共享存储简化了 HA 和 DR，且 Blue-Green 部署支持更灵活

wiki/sources/ctp-topic-7-saas-landing-zone-design.md

@@ -0,0 +1,63 @@
+---
+title: "CTP Topic 7 SaaS Landing Zone Design"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md]]
+
+## Summary（用中文描述）
+- 核心主题：SAS（生产）Landing Zone 的顶层设计——采用单一 Landing Zone 统一承载所有产品组，而非按产品组（PG）分别构建，以降低开销和成本
+- 问题域：企业多账户 AWS 生产环境下的账户结构设计、共享基础设施规划、自动化部署流水线及远程安全接入方案
+- 方法/机制：核心账户（Shared/Logs/Security）提供集中 AMI/Jenkins/日志/IAM 角色；基线账户（Network/DNS/AD）支撑网络互联和身份认证；共享服务账户（Software Factory/Cyber/ARC/Monitoring）向产品账户提供内部生产服务；Terraform IaC + GitHub/Jenkins CI/CD 实现自动化部署；Checkpoint → Pulse VPN 实现远程安全接入
+- 结论/价值：确立了 SAS LZ 的四大账户层级架构，以及 Terraform + Jenkins + Lambda + ECS 的端到端自动化部署路径
+
+## Key Claims（用中文描述）
+- SAS Landing Zone 采用单一 Landing Zone 承载所有产品组，区别于 dev labs 中按产品组各自构建 Landing Zone 的模式，以减少开销和成本
+- 核心账户（Core Accounts）包含 Shared（托管 AMI + 主 Jenkins 服务器）、Logs（集中日志账户，仅安全团队可写，产品团队只读自身日志）和 Security（托管 IAM 角色）三个子账户
+- 主 Jenkins 服务器通过 Lambda 函数触发各账户内的 Jenkins slave，禁止将主 Jenkins 直接暴露给任务或凭证，从而增强安全性
+- 基线账户（Baseline Accounts）包括 Network 账户（区域级 Transit Gateway + Checkpoint Appliance）、DNS 账户（Route 53，每个产品拥有独立托管区）和 Active Directory 账户（双 AD 节点用于域加入和资源访问控制）
+- 共享服务账户（Shared Services Accounts）提供 Software Factory（45 个 hub + Octane Hub + Artifactory）、Cyber（Qalis）、ARC Site 和 Monitoring（OBM/Sitescope）服务
+- 产品账户（Product Accounts）中，工作负载置于私有子网，通过公有子网的负载均衡器和互联网网关对外暴露；WAF 监控入站流量，CloudFront 可选作为 CDN
+- 自动化部署：每个账户对应独立 GitHub 仓库，代码变更通过 GitHub Hook 触发 Jenkins → Management VPC → Lambda → ECS Cluster 链路执行部署；Staging 环境测试后才部署生产
+- 远程访问从 Checkpoint VPN 迁移至 Pulse VPN，要求操作员使用 VPN 客户端并通过 AD 认证；未来计划使用 SD1 替换部分网络组件
+
+## Key Quotes
+> "The SAS landing zone will use a single landing zone for all the product groups." — SAS LZ 的核心设计原则：单一 Landing Zone 服务所有产品组
+> "The workload itself is going to be under private subnet." — 产品账户工作负载必须部署于私有子网
+
+## Key Concepts
+- [[Landing-Zone-Architecture]]：AWS 多账户基础设施部署单元，本文档定义了 SAS LZ 的账户层级体系（Core/Baseline/Shared Services/Product Accounts）
+- [[Active-Directory-Integration]]：通过双 AD 节点实现域加入和资源访问控制，属于 AWS LZ 身份认证基线服务
+- [[Transit-Gateway]]：区域级 Transit Gateway 连接所有账户，Checkpoint Appliance 按标签监控流量，属于 Network 账户核心组件
+- [[WAF-Web-Application-Firewall]]：Web 应用防火墙，监控入站流量，属于产品账户入站安全层
+- [[Private-Subnet-Architecture]]：工作负载部署于私有子网，通过负载均衡器和互联网网关对外暴露，属于产品账户网络架构原则
+- [[Terraform-IaC]]：使用 Terraform 实现 IaC 自动化，每个账户拥有独立 GitHub 仓库管理 Terraform 代码
+
+## Key Entities
+- [[Gruntwork]]：提供 Landing Zone 参考架构和 Terraform 模块，SAS LZ 基于 Grant Work 架构构建
+- [[TerraGrant]]（TerraGrunt）：用于简化 Terraform 状态管理和跨账户部署的工具
+- [[Jenkins]]：主 Jenkins 服务器托管于 Shared 账户，通过 Lambda 触发各账户 Jenkins slave；每个账户配置独立 Jenkins 服务器
+- [[Checkpoint]]：Checkpoint Appliance 部署于 Network 账户，按标签监控跨账户流量（互联网/On-prem）；当前远程访问使用 Checkpoint VPN（正迁移至 Pulse）
+- [[Pulse-VPN]]：新一代远程访问 VPN，通过 AD 认证，要求操作员使用 VPN 客户端
+- [[CloudFront]]：CDN 服务，可选部署于产品账户入站链路
+- [[Qalis]]：Cyber 共享服务账户中的网络安全服务
+- [[OBM]]（Operations Bridge Manager）：Monitoring 共享服务账户中的监控平台
+
+## Connections
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← extends ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← extends ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[ctp-topic-14-octane-hub-on-aws]] ← uses ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[ctp-topic-31-network-segregation-and-secure-access]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[ctp-topic-11-ad-integration-and-login]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[ctp-topic-19-configuring-dns-within-aws-lzs]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]]
+
+## Contradictions
+- 与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 的关系：
+  - 冲突点：ctp-topic-7 定义了 SAS LZ 的详细架构（Core/Baseline/Shared Services/Product 四层账户体系），ctp-topic-35 补充了近期变更（网络分段阻断直接连通性；Checkpoint VPN 迁移至 Pulse VPN）
+  - 当前观点（ctp-topic-35）：网络分段策略阻断对 SaaS 工作负载的直接连通性；入站流量通过 Network 账户 Checkpoint 重新路由
+  - 对方观点（ctp-topic-7）：产品账户的公有子网通过负载均衡器和互联网网关对外暴露；远程访问通过 Checkpoint VPN
+  - 结论：两个文档描述的是不同时间点的设计状态——ctp-topic-35 反映近期架构变更，ctp-topic-7 反映早期设计原貌，属于设计演进而非冲突

wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md

@@ -0,0 +1,75 @@
+---
+title: "CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup"
+type: source
+tags:
+  - AWS
+  - DR
+  - Backup
+  - Enterprise
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略，以及如何利用 AWS Backup 服务实现 DR 自动化。
+- 问题域：企业级灾难恢复（DR）规划、高可用（HA）与 DR 的区别、RTO/RPO 指标定义与架构设计。
+- 方法/机制：
+  - HA（高可用）关注系统运行时间和可用性，DR（灾难恢复）关注数据丢失预防和恢复能力
+  - RPO（恢复点目标）定义可接受的数据丢失量，RTO（恢复时间目标）定义可接受的停机时间
+  - AWS Backup 集中化备份服务，支持跨账户、跨区域复制，Vault Lock 防勒索软件
+  - 四级 DR 架构模式：Backup and Restore → Pilot Light → Warm Standby → Active-Active
+  - 增量备份（Incremental Backup）仅备份自上次备份以来的变更，全量备份（Full Backup）每次捕获所有数据
+  - 不可变恢复点（Immutable Recovery Points）+ Vault Lock 合规模式阻止删除
+  - Forensic Account（取证账户）定期测试恢复点并扫描恶意软件
+- 结论/价值：为 Micro Focus 云转型计划提供了完整的 DR 策略框架，从基本概念到 AWS Backup 架构设计，是 [[ctp-topic-44-aws-backup-in-micro-focus]] 的理论基础补充。
+
+## Key Claims（用中文描述）
+- 高可用（HA）衡量系统执行其功能的持续性，通过平均故障间隔时间（MTBF）衡量；灾难恢复（DR）专注于防止数据丢失和系统恢复，HA 专注于系统运行时间和可用性。
+- RPO 定义组织可接受的最大数据丢失量（时间窗口），RTO 定义组织可接受的最大停机时间，两者共同决定 DR 架构选型和成本投入。
+- AWS Backup 是完全托管的、基于策略的备份服务，通过 Backup Plans（备份计划）定义何时备份什么、通过什么方式备份，并将恢复点存储在 Backup Vaults（备份保管库）中。
+- AWS Backup 支持与 AWS Organizations 集成，实现跨账户备份复制（Cross-Account Backup），建议使用独立的 Vault/Bunker Account 存储备份副本，与工作负载账户隔离。
+- 完整备份（Full Backup）每次捕获所有数据，增量备份（Incremental Backup）仅捕获自上次备份以来的变更，节省存储成本。
+- Vault Lock 合规模式（Compliance Mode）防止包括根用户在内的任何人删除恢复点，直至其生命周期结束，有效防御勒索软件攻击。
+- Forensic Account（取证账户）用于定期测试恢复点、扫描恶意软件，确保备份数据的可用性和安全性。
+- AWS Backup Audit Manager（BAM）提供合规报告能力，支持审计备份活动的合规性。
+
+## Key Quotes
+> "We should always be prepared for a situation that everything falls all the time." — Sabith, AWS 解决方案架构师
+> "High availability ensures a system performs its functions, measured by mean time between failures. Disaster recovery focuses on data loss prevention and recovery, while high availability focuses on system uptime and service availability." — 视频摘要
+> "AWS Backup uses backup plans to define what, when, and how to back up, storing recovery points in backup vaults." — 视频摘要
+> "Vault Lock in compliance mode prevents even root users from deleting recovery points until their lifecycle ends, deterring ransomware." — 视频摘要
+
+## Key Concepts
+- [[AWS Backup]]：AWS 托管的集中化数据保护服务，通过备份计划（Backup Plans）自动化跨账户、跨区域的数据备份，支持不可变性和合规报告。
+- [[灾难恢复（Disaster Recovery）]]：防止数据丢失和系统停机的策略体系，与高可用（HA）互补，HA 保运行，DR 保数据。
+- [[高可用（High Availability）]]：通过冗余和快速故障转移保持系统持续可用的架构模式，MTBF 是其核心衡量指标。
+- [[RTO（Recovery Time Objective）]]：恢复时间目标，定义从故障恢复到服务可用的最大可接受时间窗口。
+- [[RPO（Recovery Point Objective）]]：恢复点目标，定义可接受的最大数据丢失时间窗口。
+- [[增量备份（Incremental Backup）]]：仅备份自上次备份以来的变更，与全量备份相比节省存储成本和备份时间。
+- [[全量备份（Full Backup）]]：每次备份捕获所有数据，恢复速度快但存储成本高。
+- [[Vault Lock]]：AWS Backup 保管库的合规锁定机制，合规模式下即使根用户也无法提前删除恢复点。
+- [[跨账户备份复制（Cross-Account Backup）]]：通过 AWS Organizations 在不同账户间复制备份，增强隔离性和安全性。
+- [[Bunker Account]]：专用存储备份副本的账户，与工作负载账户隔离，防止单点妥协。
+- [[Forensic Account]]：取证账户，用于定期测试恢复点可用性和恶意软件扫描。
+- [[共享责任模型（Shared Responsibility Model）]]：AWS 与客户在云弹性环境中的责任划分框架。
+- [[AWS Backup Audit Manager（BAM）]]：AWS Backup 的合规审计功能，支持备份活动的合规性报告。
+- [[灾难恢复架构模式]]：Backup and Restore / Pilot Light / Warm Standby / Active-Active 四级递进模式，从低成本低恢复到高成本高弹性。
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，AWS Backup 服务的提供方。
+- [[Sabith]]：AWS 解决方案架构师，本视频的主讲人。
+- [[Cloud Transformation Programme (CTP)]]：云转型计划，该视频属于 01_AWS-Landing-Zone 系列第 72 个主题。
+- [[Micro Focus]]：企业客户，CTP 的参与方。
+
+## Connections
+- [[ctp-topic-44-aws-backup-in-micro-focus]] ← extends ← [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]
+- [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] ← extends ← [[ctp-topic-44-aws-backup-in-micro-focus]]
+- [[AWS Backup]] ← related ← [[RTO]]
+- [[AWS Backup]] ← related ← [[RPO]]
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← depends_on ← [[AWS Backup]]
+
+## Contradictions
+- 无明显内容冲突。本视频与 [[ctp-topic-44-aws-backup-in-micro-focus]] 构成互补关系——Topic 72 提供 DR 策略和 AWS Backup 的理论框架，Topic 44 聚焦 Micro Focus 内部评估和迁移路径，两者共同构成完整的 AWS Backup 知识体系。

wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md

@@ -0,0 +1,56 @@
+---
+title: "CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme"
+type: source
+tags:
+  - AWS
+  - Backup
+  - Cloud Transformation Programme
+  - SRE
+  - DR
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Backup 在云转型计划中的企业级实施落地
+- 问题域：如何在多账户 AWS 环境中标准化备份流程，同时给予产品团队自主管理灵活性
+- 方法/机制：SRE 团队开发 SRE Backup Model，为每个产品组提供预置的 AWS Backup Plans、Selections、Vaults、KMS 密钥策略等模板，支持在 DRA 账户内独立执行备份和恢复；设计从源账户初始备份并复制到远程 DR 账户和区域；AWS Backup Audit Manager 提供合规审计报告
+- 结论/价值：AWS Backup 作为战略性备份工具，通过 SRE Model 实现"集中管控 + 分散执行"的平衡，标准化备份流程同时保留产品团队灵活性
+
+## Key Claims（用中文描述）
+- SRE 核心团队通过开发 SRE Backup Model，简化了 AWS Backup 的采纳门槛，使产品组能够在其 DRA 账户内自主创建和管理备份
+- AWS Backup 选择原因：原生托管服务、支持 TAC-based 备份计划、跨账户跨区域复制、备份不可变性、开箱即用审计报告、S3/RDS 点时间恢复
+- 备份设计：初始备份在源账户执行，复制到远程 DR 账户和区域（如 DR 不可用则使用 Databunker 作为集中备份账户），确保即时恢复能力
+- AWS Backup Audit Manager 提供合规控制：备份计划保护、最小频率和保留期、防手动删除恢复点、加密验证、计划性跨区域和跨账户备份
+
+## Key Quotes
+> "AWS backup was adopted as the strategic tool for backup in AWS for the cloud transformation program to standardize backup processes." — AWS Backup 被选为云转型计划的战略性备份工具
+> "An SRE model was developed to allow product groups to create and control their own backups, aligned with the assumed backup policy." — SRE Model 赋予产品组自主创建和管理备份的能力
+> "This keeps backups within the DR account for immediate restore, avoiding time-consuming data copies." — 备份保留在 DR 账户内以实现即时恢复
+
+## Key Concepts
+- [[AWS Backup]]：AWS 原生托管备份服务，支持多资源类型的集中备份和恢复策略管理
+- [[SRE Model]]：Site Reliability Engineering 团队开发的备份管理模式，为产品组提供标准化但可定制的备份基础设施
+- [[AWS Backup Audit Manager]]：AWS Backup 内置合规审计框架，提供备份状态报告和合规控制评估
+- [[跨账户备份]]：通过 AWS Organizations 将备份从源账户复制到独立的 DR/Bunker 账户，实现备份隔离
+- [[Vault Lock]]：备份保险库合规锁定模式，防止任何人（包括根用户）提前删除恢复点
+
+## Key Entities
+- [[AWS]]：云服务提供商，AWS Backup 为其原生备份服务
+- [[Cloud Transformation Programme]]（CTP）：企业级云转型计划，本视频为其 Topic 73，聚焦 AWS Backup 实施
+- SRE（Site Reliability Engineering）Core/Product/Architecture Teams：SRE 核心、产品和架构团队协作设计备份策略
+- DRA Accounts：Disaster Recovery Application Accounts，各产品组在其 DRA 账户内管理自有备份
+
+## Connections
+- [[ctp-topic-72-enterprise-dr-strategy-aws-backup]] ← extends ← [[ctp-topic-73-aws-backup-implementation]]（Topic 72 提供理论基础，Topic 73 聚焦实施落地）
+- [[ctp-topic-44-aws-backup-in-micro-focus]] ← relates_to ← [[ctp-topic-73-aws-backup-implementation]]（两者均讨论 AWS Backup，Topic 44 聚焦 Micro Focus 内部评估）
+- [[AWS Backup]] ← depends_on ← [[AWS Backup Audit Manager]]（Audit Manager 是 AWS Backup 的合规增强组件）
+- [[AWS Backup]] ← supports ← [[跨账户备份]]（跨账户跨区域复制是 AWS Backup 的核心能力）
+
+## Contradictions
+- 与 [[ctp-topic-44-aws-backup-in-micro-focus]] 存在视角差异：
+  - 冲突点：Topic 44 讨论 Micro Focus 现有备份评估（快照管理 vs AWS Backup 选型）
+  - 当前观点：Topic 73 作为 CTP 实施指南，确认 AWS Backup 为标准工具
+  - 对方观点：Topic 44 提及 AWS Backup 的局限性（无法选择性排除 EC2 附加卷、崩溃一致而非热备份）

wiki/sources/fireworks-tech-graph.md

@@ -0,0 +1,49 @@
+---
+title: "fireworks-tech-graph"
+type: source
+tags: []
+date: 2026-04-18
+---
+
+## Source File
+- [[raw/Skills/fireworks-tech-graph.md]]
+
+## Summary（用中文描述）
+- 核心主题：用自然语言描述系统，几秒内生成可直接发布的 SVG + PNG 技术图
+- 问题域：技术文档/博客/演示缺乏高质量可视化图表，手动绘图耗时且风格不统一
+- 方法/机制：内置 7 种视觉风格（扁平图标/暗黑极客/工程蓝图/Notion极简/玻璃态/Claude官方/OpenAI官方）、14 种 UML 图类型、AI/Agent 领域内建 Pattern，通过 `rsvg-convert` 导出 1920px PNG
+- 结论/价值：AI Agent 可快速生成专业级技术图，无需手动绘制，支持 SVG 可编辑 + PNG 无损发布
+
+## Key Claims（用中文描述）
+- fireworks-tech-graph 将自然语言描述转化为精美的 SVG 技术图，通过 rsvg-convert 导出高分辨率 PNG
+- 内置 7 种视觉风格，深度覆盖 AI/Agent 领域常见图类型（RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 流程等）
+- 完整支持全部 14 种 UML 图类型
+- AI/Agent 领域内建知识：RAG、Agentic Search、Mem0、Multi-Agent、Tool Call 等常见 Pattern 开箱即用
+- 语义形状词汇表：LLM = 双边框圆角矩形，Agent = 六边形，Vector Store = 带内环圆柱
+- 语义箭头系统：颜色 + 虚线样式编码含义（写入/读取/异步/循环）
+- SVG + PNG 双输出：SVG 可编辑，1920px PNG 可直接嵌入文章
+
+## Key Quotes
+> "不用手画图了。用中文描述你的系统，几秒钟得到可直接发布的 SVG + PNG 技术图。" — 项目 tagline
+> "所有示例图均以 1920px 宽度（2× 视网膜分辨率）通过 rsvg-convert 导出为 PNG 格式。技术图应选 PNG（无损），JPG 有损压缩会在文字和线条边缘产生噪点。" — 导出格式建议
+
+## Key Concepts
+- [[技术图生成]]：用自然语言生成 SVG/PNG 格式的技术架构图、流程图、UML 图
+- [[7种视觉风格系统]]：扁平图标风（默认）、暗黑极客风、工程蓝图风、Notion极简风、玻璃态卡片风、Claude官方风格、OpenAI官方风格
+- [[语义形状词汇表]]：每种概念类型（LLM/Agent/VectorStore/工具等）对应特定 SVG 形状
+- [[语义箭头系统]]：颜色 + 虚线样式编码数据流向（主数据流/控制触发/记忆读取/记忆写入/异步/反馈循环）
+- [[14种UML图]]：类图/组件图/部署图/包图/复合结构图/对象图/用例图/活动图/状态机图/序列图/通信图/时序图/交互概览图/ER图
+
+## Key Entities
+- [[fireworks-tech-graph]]：Claude Code Skill，将自然语言转化为 SVG 技术图，支持 7 种风格和 14 种 UML 图类型
+- [[rsvg-convert]]：librsvg 工具，用于将 SVG 渲染为高分辨率 PNG
+
+## Connections
+- [[fireworks-tech-graph]] ← uses ← [[语义形状词汇表]]
+- [[fireworks-tech-graph]] ← uses ← [[语义箭头系统]]
+- [[fireworks-tech-graph]] ← implements ← [[7种视觉风格系统]]
+- [[fireworks-tech-graph]] ← supports ← [[14种UML图]]
+- [[fireworks-tech-graph]] ← outputs ← [[rsvg-convert]]
+
+## Contradictions
+- 无冲突内容

wiki/sources/install-wsl.md

@@ -0,0 +1,49 @@
+---
+title: "Install WSL"
+type: source
+tags: []
+date: 2026-04-18
+---
+
+## Source File
+- [[Home Office/Install WSL]]
+
+## Summary（用中文描述）
+- 核心主题：Windows Subsystem for Linux（WSL）的官方安装与配置完整指南
+- 问题域：Windows 10/11 系统上快速安装 Linux 开发环境，包括单命令安装、多发行版支持、版本管理、离线安装等场景
+- 方法/机制：① `wsl --install` 一键安装；② `-d` 参数切换默认发行版；③ `wsl.exe --set-default-version` 切换 WSL 1/2；④ MSI 包 + DISM 命令离线安装；⑤ Windows Terminal / 开始菜单 / PowerShell 多入口运行
+- 结论/价值：微软官方权威安装文档，提供从零到生产可用的完整路径，WSL2 为默认版本，支持并行运行多个不同 Linux 发行版
+
+## Key Claims（用中文描述）
+- `wsl --install` 一条命令完成 WSL 全部组件启用和 Ubuntu 默认发行版安装，适用于 Windows 10 version 2004+（Build 19041+）和 Windows 11
+- WSL2 默认使用 NAT 网络模式，通过 `.wslconfig` 配置 `networkingMode=mirrored` 可实现与 Windows 共享网络堆栈（参考 [[WSL2 启动与网络配置指南]]）
+- 支持并行安装多个 Linux 发行版（Ubuntu/Debian/SUSE/Kali/Fedora 等），可从 Microsoft Store 下载或导入自定义 TAR 分发版
+- 新安装的 Linux 发行版默认使用 WSL 2，可通过 `wsl.exe --set-version <Distro> 1` 降级到 WSL 1
+- 离线安装需从 GitHub releases 下载 MSI 安装包，并通过 DISM 命令启用 Virtual Machine Platform 组件
+
+## Key Quotes
+> "You can now install everything you need to run WSL with a single command." — 微软官方文档
+> "New Linux installations, installed using the `wsl --install` command, will be set to WSL 2 by default." — 微软官方文档
+
+## Key Concepts
+- [[WSL2]]：Windows Subsystem for Linux 2，Windows 10/11 内置 Linux 虚拟机环境，默认版本，支持完整 Linux 内核
+- [[WSL1]]：WSL 第一代，基于翻译层，性能较差但兼容性好，新发行版默认不使用
+- [[WSL 安装命令]]：`wsl --install` 单命令安装，启用所需功能并安装默认 Ubuntu 发行版
+- [[多发行版支持]]：WSL 支持并行安装运行多个不同 Linux 发行版，可通过 `--distribution` 参数指定运行哪个
+- [[离线安装]]：通过 MSI 包 + DISM 命令手动启用 Virtual Machine Platform 组件，适用于无法联网的环境
+
+## Key Entities
+- [[Microsoft]]：WSL 官方文档发布方
+- [[Ubuntu]]：WSL 默认安装的 Linux 发行版
+- [[PowerShell]]：Windows 命令行环境，执行 `wsl --install` 的工具（需管理员模式）
+- [[Windows Terminal]]：微软官方终端应用，推荐用于运行 WSL，支持多标签页
+
+## Connections
+- [[WSL2 启动与网络配置指南]] ← related_to ← [[Install WSL]]（安装完成后需参考网络配置指南解决代理问题）
+- [[Ubuntu Server]] ← related_to ← [[WSL2]]（WSL2 中的 Ubuntu 与 Ubuntu Server 同属 Ubuntu 系 Linux 环境）
+
+## Contradictions
+- 与 [[WSL2 启动与网络配置指南]] 的侧重点差异：
+  - 冲突点：本文档聚焦安装过程，未涉及网络配置；[[WSL2 启动与网络配置指南]] 聚焦安装后的网络配置
+  - 当前观点：先安装（本文档）→ 后配置网络（[[WSL2 启动与网络配置指南]]），两篇互补
+  - 对方观点：WSL2 默认 NAT 网络模式下 localhost 代理不可用，需配置镜像模式才能与 Windows 共享代理

wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md

@@ -0,0 +1,53 @@
+---
+title: "Learning Sessions: Standard AMI Updates 20231205"
+type: source
+tags: ["AWS", "AMI", "Landing-Zone", "DevOps", "Automation"]
+date: 2023-12-05
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 标准 AMI（Amazon Machine Image）的更新机制、构建发布流程及生命周期管理
+- 问题域：企业 AWS Landing Zone 中的操作系统镜像标准化与自动化运维
+- 方法/机制：Jenkins 多分支流水线构建与测试、AWS Inspector 安全扫描、机器人框架自动化验证、SSM 按需打补丁
+- 结论/价值：每两个月发布一次标准化 AMI，将验证周期从 3-4 天缩短至 60 分钟，CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代
+
+## Key Claims（用中文描述）
+- 标准 AMI 基于 AWS 原生镜像，增加了 OS 加固、最新补丁、安全更新、域名加入、安全工具、端点保护、QALIS Agent、SSM Agent、DNS 设置和 GP3 EBS 存储
+- Jenkins 多分支流水线用于构建和测试 AMI，包括脚本化测试和 AWS Inspector 安全扫描，验证无功能退化
+- AMI 发布流程遵循标准软件开发流程：功能分支开发 → 合并到集成分支 → 构建测试 → 跨区域复制 → 加密共享 → 完整测试套件验证
+- 机器人框架集成将单个 AMI 的验证时间从 3-4 天缩短至 60 分钟
+- 目前支持 23 种不同 AMI，涵盖 Amazon Linux、CentOS、Oracle Enterprise Linux、Red Hat、Rocky Linux、SUSE Linux、Ubuntu 和 Windows Server
+- CentOS 7 和 Red Hat 7 将于 2024 年 6 月 EOL，CentOS 7 将由 Rocky Linux 替代（已作为标准 AMI 可用）
+- OpenSUSE Leap 15 和 OEL 7 将于 2024 年 12 月 EOL
+- AMI 利用率被监控以追踪使用频率和数量
+- SSM 打补丁方案适用于无法频繁刷新的长期运行实例
+
+## Key Quotes
+> "The AMIs are thrown through all of the test suites, and we'll see a couple of those as they come up in later slides, and then we verify that nothing seems to have regressed at that point." — AMI 测试验证流程说明
+
+## Key Concepts
+- [[Amazon-Machine-Image]]：AWS 托管的虚拟机镜像模板，标准 AMI 在此基础上增加了 OS 加固、安全补丁、SSM Agent、QALIS Agent 等企业级组件
+- [[Jenkins-Multi-Branch-Pipeline]]：Jenkins 的多分支流水线功能，用于 AMI 的自动化构建、测试和发布，支持功能分支开发和集成分支合并
+- [[AWS-Inspector]]：AWS 安全扫描服务，集成到 AMI 测试流程中用于漏洞检测
+- [[Robotic-Framework]]：自动化测试框架，该会话中用于将 AMI 验证周期从 3-4 天缩短至 60 分钟
+- [[SSM-Patching]]：AWS Systems Manager 补丁管理器，提供适用于长期运行实例的按需打补丁方案
+- [[GP3-EBS-Storage]]：AWS EBS 的第三代通用型固态硬盘存储类型，标准 AMI 默认采用
+- [[OS-End-of-Life]]：操作系统生命周期终止，CentOS 7 和 RHEL 7 将于 2024 年 6 月 EOL，需迁移到 Rocky Linux 等替代品
+
+## Key Entities
+- [[Rocky-Linux]]：CentOS 7 的官方替代品，已作为标准 AMI 提供，用于应对 CentOS EOL 迁移
+- [[Jenkins]]：CI/CD 平台，托管 AMI 的多分支构建和测试流水线
+- [[QALIS-Agent]]：企业端点保护 Agent，集成在标准 AMI 中
+- [[Sentinel-1]]：新的端点保护方案，正在替代 Trellix（Migrated from Trellix to Sentinel-1）
+- [[AWS-SSM]]：AWS Systems Manager，提供 SSM Agent 和补丁管理功能
+
+## Connections
+- [[ctp-topic-50-ami-roadmap-for-aws-amis]] ← extends ← [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]]
+- [[ctp-topic-26-standard-ami-build-publish-share-processes]] ← depends_on ← [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]]
+- [[ctp-topic-58-aws-ec2-image-builder]] ← related_to ← [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]]
+
+## Contradictions
+- 暂无已知冲突

wiki/sources/mac必装软件清单-2026-04-17.md

@@ -0,0 +1,47 @@
+---
+title: "Mac必装软件清单"
+type: source
+tags: []
+date: 2026-04-17
+---
+
+## Source File
+- [[Home Office/Mac必装软件清单-2026-04-17.md]]
+
+## Summary（用中文描述）
+- 核心主题：Mac 用户必装软件推荐清单
+- 问题域：macOS 效率工具与生产力软件选型
+- 方法/机制：精选 8 款软件，涵盖 AI、知识管理、浏览器、效率工具、开发工具等类别，每款附推荐理由
+- 结论/价值：用最少的软件达到最高的效率，适合从 Windows 转 Mac 的用户和追求效率的 macOS 用户
+
+## Key Claims（用中文描述）
+- Claude 是 AI 时代必备工具，桌面版 Cowork 功能专为文字工作者打造
+- Obsidian 搭配 Claudian 插件可打造 AI 驱动的终极个人知识库
+- Raycast 是替代 Spotlight 的万能启动器，计算器和剪贴板功能超好用
+- Homebrew 是用 Claude Code 搭 Agent 的前置依赖
+
+## Key Quotes
+> "用最少的软件，达到最高的效率。" — Claw小龙虾
+
+## Key Concepts
+- [[Raycast]]：替代 Spotlight 的 macOS 万能启动器，支持计算器、剪贴板历史等功能
+- [[Obsidian]]：本地优先的笔记与知识管理工具，支持双向链接
+- [[Homebrew]]：macOS 包管理器，是开发工具安装的事实标准
+
+## Key Entities
+- [[Claude]]：Anthropic 开发的 AI 助手，桌面版 Cowork 功能专为文字工作者设计
+- [[Chrome]]：Google 浏览器，比 Safari 更好用，Gmail 用户的不二之选
+- [[Rectangle]]：免费分屏工具，大屏办公必备
+- [[iShot]]：简洁免费的 macOS 截图工具，支持圆角截图
+- [[Lemon]]：轻量 Mac 系统清理工具
+- [[Homebrew]]：macOS 包管理器
+- [[Claw小龙虾]]：Telegram频道「Hermes爱马仕&🦞OpenClaw小龙虾」作者
+
+## Connections
+- [[Obsidian]] ← 搭配 ← [[Claudian插件]]
+- [[Obsidian]] ← 关联 ← [[Second Brain]]
+- [[Homebrew]] ← 依赖 ← [[Claude Code]]
+- [[Raycast]] ← 替代 ← [[Spotlight]]
+
+## Contradictions
+- 无冲突内容

wiki/sources/wsl2-启动与网络配置指南.md

@@ -0,0 +1,42 @@
+---
+title: "WSL2 启动与网络配置指南"
+type: source
+tags: []
+date: 2026-04-17
+---
+
+## Source File
+- [[Home Office/WSL2 启动与网络配置指南]]
+
+## Summary（用中文描述）
+- 核心主题：WSL2（Windows Subsystem for Linux 2）的安装启动与网络配置实操指南
+- 问题域：Windows 环境下 Linux 开发环境搭建，重点解决 WSL2 网络隔离导致的 GitHub/海外资源访问障碍
+- 方法/机制：① `wsl --install` 快速安装；② `.wslconfig` 启用镜像网络模式（mirrored mode）实现 WSL2 与 Windows 共享网络堆栈；③ 终端代理环境变量手动配置；④ ghproxy.com 反向代理绕过网络限制
+- 结论/价值：提供从零安装到生产可用的完整 WSL2 配置路径，镜像网络模式是最稳妥的解决方案，避免 NAT 模式下的 localhost 代理失效问题
+
+## Key Claims（用中文描述）
+- WSL2 默认使用 NAT 模式，导致 Windows 宿主机 localhost 代理无法被 WSL2 内部正确访问，这是 GitHub/海外资源连接失败的根本原因
+- 在 `.wslconfig` 中设置 `networkingMode=mirrored` + `dnsTunneling=true` + `autoProxy=true` 可使 WSL2 与 Windows 共享网络堆栈，是解决网络问题的推荐方案
+- 使用 `ghproxy.com` 反向代理可绕过 GitHub 访问限制，适用于 uv 安装器、Hermes Agent 等工具的下载场景
+
+## Key Quotes
+> "WSL2 默认使用 NAT 模式，常会出现'localhost 代理无法镜像'或无法访问海外资源的情况。" — 背景说明
+> "在 PowerShell 执行 `wsl --shutdown` 后重启 WSL。" — 镜像模式生效操作
+
+## Key Concepts
+- [[WSL2]]：Windows Subsystem for Linux 2，Windows 10/11 内置的 Linux 虚拟机环境，默认使用 NAT 网络模式
+- [[镜像网络模式]]（Mirrored Network Mode）：WSL2 与 Windows 共享网络堆栈的配置模式，使 WSL2 能直接访问 Windows 代理
+- [[NAT模式]]：WSL2 默认网络模式，WSL2 拥有独立 IP，localhost 代理不可用
+- [[ghproxy]]：ghproxy.com，反向代理服务，将 GitHub 资源 URL 替换为代理地址以绕过网络限制
+
+## Key Entities
+- [[Ubuntu]]：WSL2 默认安装的 Linux 分发版
+- [[Windows]]：宿主操作系统，WSL2 运行其上
+- [[PowerShell]]：Windows 命令行环境，用于执行 wsl 管理命令
+
+## Connections
+- [[Ubuntu Server]] ← related_to ← [[WSL2]]（WSL2 是 Ubuntu 在 Windows 上的轻量运行方式）
+- [[ubuntu-server科学上网]] ← related_to ← [[WSL2 网络配置]]（均涉及 Linux 环境代理配置）
+
+## Contradictions
+- （无已知冲突）

wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md

@@ -0,0 +1,51 @@
+---
+title: "实战笔记：本地部署 RSSHub 并获取 YouTube 订阅"
+type: source
+tags: ["Home Office", "RSSHub", "YouTube", "Docker"]
+date: 2026-04-21
+---
+
+## Source File
+- [[Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅]]
+
+## Summary（用中文描述）
+- 核心主题：本地自托管 RSSHub 并通过其生成 YouTube 频道 RSS 订阅源
+- 问题域：YouTube 官方不直接提供 RSS，且第三方在线 RSS 服务不稳定
+- 方法/机制：
+  - Docker Compose 一键部署 RSSHub（port 1200）
+  - 获取 YouTube 频道 ID（浏览器 view-source 方式）
+  - RSSHub 路由格式 `/youtube/channel/{channel_id}` 生成 RSS 源
+  - 支持订阅列表监控
+- 结论/价值：完全自托管，稳定可靠，绕过 YouTube 官方限制
+
+## Key Claims（用中文描述）
+- RSSHub Docker 部署命令：`docker run -d --name rsshub -p 1200:1200 diygod/rsshub`
+- YouTube 频道 ID 获取方式：浏览器访问频道页面 URL，`view-source:` 查看源码搜索 `channel_id`
+- RSSHub YouTube RSS 路由：`http://localhost:1200/youtube/channel/{channel_id}`
+- 支持订阅列表路由：`/youtube/channel/{channel_id}/videos` 获取该频道视频列表
+
+## Key Quotes
+> "RSSHub 是一个开源、简单易用、方便扩展的 RSS 生成器" — RSSHub 官方定位
+
+> "获取 YouTube 频道 ID 的方法：访问频道页面 → view-source → 搜索 channel_id" — 频道 ID 获取技巧
+
+## Key Concepts
+- [[RSSHub]]：开源 RSS 聚合生成器，可为不支持 RSS 的网站生成订阅源
+- [[Docker]]：容器化平台，RSSHub 通过 Docker 一键部署
+- [[RSS]]：Really Simple Syndication，网站内容聚合订阅协议
+
+## Key Entities
+- [[diygod]]（DIYgod）：RSSHub 项目的主要维护者，Docker 镜像 `diygod/rsshub` 的发布者
+- [[YouTube]]：视频平台，本场景的 RSS 订阅目标
+
+## Connections
+- [[RSSHub]] ← 使用 Docker 部署 ← [[Docker]]
+- [[RSSHub]] ← 为 [[YouTube]] 生成 RSS ← [[YouTube Content Pipeline]]
+- [[YouTube Content Pipeline]] ← 依赖 RSS 监控 ← [[RSSHub]]
+
+## Contradictions
+- 与 [[How to Get the RSS Feed For Any YouTube Channel]] 略有差异：
+  - 冲突点：在线获取 vs 本地生成
+  - 当前观点：本地 RSSHub 部署更稳定可靠
+  - 对方观点：在线服务无需维护，适合临时使用
+  - 结论：两者互补使用——RSSHub 主用 + 在线工具备用