Auto-sync: 2026-04-28 20:03

wiki/sources/ai-memory-tools-two-camps.md

@@ -7,7 +7,7 @@ last_updated: 2026-04-15
 ---
 
 ## Source File
-- [[Agent/AI-Memory-Tools-Two-Camps.md]]
+- [[raw/Agent/AI-Memory-Tools-Two-Camps.md]]
 
 ## Summary（用中文描述）
 - 核心主题：AI Agent 记忆工具的全景分类——作者系统梳理了 450+ 个 GitHub 仓库，将 AI 记忆工具划分为两个根本不同的范式阵营

wiki/sources/blogwatcher-daily收藏.md

@@ -6,7 +6,7 @@ date: 2026-04-18
 ---
 
 ## Source File
-- [[Skills/blogwatcher-daily收藏.md]]
+- [[raw/Skills/blogwatcher-daily收藏.md]]
 
 ## Summary（用中文描述）
 - 核心主题：Hermes Agent 自定义技能 blogwatcher-daily，实现 RSS/YouTube 订阅自动化监控与每日摘要生成

wiki/sources/building-your-quartz.md

@@ -9,7 +9,7 @@ date: 2026-04-17
 ---
 
 ## Source File
-- [[Home Office/Building your Quartz]]
+- [[raw/Home Office/Building your Quartz.md]]
 
 ## Summary（用中文描述）
 - 核心主题：Quartz 静态网站构建与部署完整指南

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

@@ -2,67 +2,54 @@
 title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
 type: source
 tags:
-  - aws
-  - landing-zone
-  - tagging
-  - security
-  - cloud-transformation
-  - ctp
-date: 2026-04-14
+  - AWS
+  - Landing-Zone
+  - Tagging
+  - Security
+  - CTP
+last_updated: 2026-04-14
 ---
 
 ## Source File
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]]
 
 ## Summary（用中文描述）
-- 核心主题：AWS Landing Zone 部署过程中数据收集策略，以及基于资源标签的云原生安全架构
-- 问题域：企业云迁移过程中如何理解待上云资产、如何通过标签机制实现精细化的访问控制和安全策略
+- 核心主题：AWS Landing Zone 的数据收集策略与基于标签的安全控制机制
+- 问题域：企业云迁移过程中的网络安全与访问控制
 - 方法/机制：
-  - **OU + SCP 分层治理**：通过组织单元（OU）和 Service Control Policies（SCP）强制执行标签规范
-  - **标签即凭证**：将 AWS 资源标签作为防火墙策略的动态匹配条件，替代传统基于 IP 的静态规则
-  - **Checkpoint 有序层防火墙**：按优先级执行地理屏蔽 → 类型检查 → BU 隔离 → 产品隔离 → 环境隔离 → 角色检查
-  - **Inline 层结构**：基于账号号的父子规则架构，简化跨账户策略管理
-- 结论/价值：从"IP 地址"到"标签"的策略范式转变，使动态云环境无需频繁更新防火墙规则；标签缺失或篡改会触发 SCP 拒绝策略，确保安全合规
+  - 部署前通过业务部门（BU）资产清单、IP 地址空间及数据敏感性调研，制定 Landing Zone 安全姿态
+  - 利用 AWS 标签（Tagging）替代传统基于 IP 的防火墙规则，作为安全凭证
+  - 引入 OU（组织单元）和 SCP（服务控制策略）防止用户篡改标签绕过安全审计
+  - Checkpoint 防火墙通过"有序层（Ordered Layer）"逻辑实现流量分层过滤
+- 结论/价值：实现从传统网络安全向基于身份和元数据的云原生安全转型
 
 ## Key Claims（用中文描述）
-- Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性
-- DNS、Transit Gateway 等基础服务通过 SRE 团队实现高度自动化
-- **基于标签的安全控制**：传统基于 IP 的防火墙规则无法适应云环境动态性，标签机制将安全凭证嵌入资源本身
-- **SCP 强制标签规范**：「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属
-- **Checkpoint 防火墙有序层**：按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制
-- 标签示例包括：机器名、Owner（优先使用 PDL）、Type（R&D 等）、Business Unit、Product、Environment（production 等）、Server Role、Account、App ID
-- 产品间通信默认禁止（Inter product is not allowed）
-- Inline 层检查账号号，简化规则管理并支持自动化
+- Steve Jarman + Pradeep 通过 SCP 的"显式拒绝"逻辑，强制执行标签规范，确保资源在创建时即具备正确的归属标签（BU、产品、环境）
+- Checkpoint 防火墙根据标签对流量进行分层过滤（地理屏蔽、BU 隔离、产品隔离、环境隔离），实现跨 VPC、On-prem 及互联网流量的精细化策略约束
+- DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现高度自动化
 
 ## Key Quotes
-> "We ask a lot of questions so that we can then turn around and make sure we're putting the appropriate posture in the cloud and that we're protecting the resources appropriately."
-> — Steve Jarman，阐述云迁移前的准备工作重心
-
-> "Inter product is not allowed. Inter product is communications allowed."
-> — Pradeep，描述产品间隔离的默认安全策略
+> "在部署前，必须深入了解业务部门（BU）的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态" — Steve Jarman，部署前规划原则
+> "通过 SCP 的'显式拒绝'逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属" — Pradeep，标签安全控制机制
 
 ## Key Concepts
-- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略类型，通过「显式拒绝」逻辑强制执行标签规范，阻止不合规资源创建
-- [[Checkpoint-Firewall]]：防火墙供应商，依赖 AWS 标签值配置动态网络访问策略
-- [[AWS-Landing-Zone]]：AWS 云环境的最佳实践起点框架，定义账户结构、网络、安全和访问管理
-- [[Tag-Based-Security]]：将资源标签作为安全凭证，替代传统基于 IP 的防火墙规则
-- [[OU-Layered-Security]]：通过组织单元（OU）的分层结构检查标签，确保正确归属和访问控制
+- [[AWS Landing Zones]]：按照最佳实践快速设置安全且多账号 AWS 环境的基础架构框架
+- [[Tagging Methodology]]：通过为资源定义标准化元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础
+- [[SCP Service Control Policies]]：AWS Organizations 中的服务控制策略，用于管理组织中的权限，本视频中用于强制执行标签合规性
+- [[OU Organizational Unit]]：AWS Organizations 中账号的分组容器，用于分层应用安全策略（SCP）
+- [[Checkpoint Firewall Ordered Layer]]：防火墙策略的组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑
+- [[Transit Gateway]]：传输网关，作为网络中心枢纽连接 VPC 与本地网络，是跨环境流量经过防火墙检查的关键节点
+- [[SRE Automation]]：站点可靠性工程，负责 Landing Zone 部署中的自动化脚本编写与基础架构维护
 
 ## Key Entities
-- [[Steve-Jarman]]：CTP Topic 10 主讲人之一，阐述云迁移前的准备工作
-- [[Pradeep]]：CTP Topic 10 主讲人，演示 Checkpoint 防火墙配置和 EC2 部署示例
-- [[Checkpoint]]：防火墙供应商，负责基于标签的动态网络安全策略
-- [[AWS-Organizations]]：AWS 服务，提供 SCP 策略机制支持标签强制执行
+- [[Steve Jarman]]：Cloud Transformation Programme 技术分享主持人，Landing Zone 规划与自动化专家
+- [[Pradeep]]：Checkpoint 防火墙与网络隔离技术演示主讲人
 
 ## Connections
-- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← foundational ← [[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-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] ← related ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
-- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]
+- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← builds_upon ← [[CTP Topic 10]]
+- [[CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones]] ← extends ← [[CTP Topic 10]]
+- [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]] ← related_to ← [[CTP Topic 10]]
+- [[AWS_Organizations_and_SCP_Deep_Dive]] ← deep_dive ← [[CTP Topic 10]]（SCP 强制执行标签合规性）
 
 ## Contradictions
-- 与 [[ctp-topic-28-aws-tag-validation-tool]] 在标签治理覆盖范围上存在差异：
-  - 冲突点：SCPs 的标签强制能力边界
-  - 当前观点（Topic 10）：SCPs 通过「显式拒绝」阻止不合规资源创建，确保标签在资源创建时就正确
-  - 对方观点（Topic 28）：SCPs 可阻止不合规资源创建，但无法修复存量资源，存量合规性需通过 Tag Validation Tool 审计发现
-  - 协调说明：两者互补而非矛盾——SCP 负责预防（新资源准入控制），Tag Validation Tool 负责发现（存量资源合规审计）
+- 暂无已知冲突

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

@@ -12,7 +12,7 @@ last_updated: 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]]
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md]]
 
 ## Summary（用中文描述）
 

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

@@ -11,7 +11,7 @@ date: 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.md]]
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md]]
 
 ## Summary（用中文描述）
 - 核心主题：在 Gruntwork AWS Landing Zones 架构中集成与管理 Active Directory 服务

wiki/sources/ctp-topic-22-global-dns-service-offerings.md

@@ -52,7 +52,7 @@ date: 2026-04-14
 - [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← related_to ← [[ctp-topic-22-global-dns-service-offerings]]
 
 ## Contradictions
-- 与 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 潜在关系：
-  - 当前观点：CTP Topic 22 详细描述了 Route 53 Private Hosted Zone + Resolver Endpoint 的完整混合云 DNS 架构，含 Infoblox Anycast 对比
-  - 对方观点：CTP Topic 19 尚未被摄入，具体内容待确认
-  - 状态：待 ctp-topic-19 摄入后补充对比
+- 与 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 关系（视角互补，非冲突）：
+  - 当前观点（CTP Topic 22）：企业级全局 DNS 架构视角——Route 53 Private Hosted Zone + AD 托管 DNS + Route 53 Resolver Endpoints 完整混合云方案，含 Infoblox Anycast 对比和"就近解析"优化
+  - 对方观点（CTP Topic 19）：Landing Zone 内部 DNS 配置实施视角——集中化 DNS 账号设计 + AWS RAM 跨账号规则共享 + Terraform 自动化部署
+  - 状态：两视频共同构成 DNS 专题完整体系（Topic 19 讲配置实施 → Topic 22 讲企业架构），属深度递进关系

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

@@ -35,28 +35,25 @@ date: 2026-04-14
 > "CCOE 负责提供安全的基础镜像，而产品团队则被鼓励在 Foundation AMI 之上构建自定义的'产品特定 AMI'，以满足各自应用的特殊需求，并负责其后续的生命周期管理。" — 责任共担模型说明
 
 ## Key Concepts
-- [[Foundation AMI]]：经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像
-- [[OS Hardening]]：操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面
-- [[CIS Benchmarks]]：由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践
-- [[HashiCorp Packer]]：开源工具，用于从单一源配置为多个云平台自动创建一致的机器镜像
-- [[SSM Agent]]：AWS 系统管理器代理，用于实现实例的远程管理、自动化补丁更新和配置同步
-- [[AMI Sharing]]：镜像共享机制，通过授权其他账号访问中央镜像，避免跨账号复制带来的额外存储成本
-- [[Central Repository]]：中央仓库，用于统一存放和管理经过验证的官方镜像，确保分发源的唯一性
+- [[Foundation-AMI]]：经过安全加固、集成标准组件并预配置好的操作系统模板，是 Micro Focus 云环境的标准化基础镜像
+- [[OS-Hardening]]：操作系统加固，通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面
+- [[CIS-Benchmark]]：由互联网安全中心制定的安全配置基准，用于衡量镜像是否符合行业最佳安全实践
+- [[HashiCorp]]：开源基础设施自动化工具公司，[[HashiCorp]] 出品的 Packer 用于镜像构建自动化（本来源中称 HashiCorp Packer）
+- [[AWS-SSM]]：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]]
+- [[Foundation-AMI]] ← uses ← [[HashiCorp]] Packer + [[Jenkins]]
+- [[Foundation-AMI]] ← extends ← [[CIS-Benchmark]]（安全加固标准）
+- [[Foundation-AMI]] ← depends_on ← [[AWS-SSM]]（实例管理能力）
+- [[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]]
+- [[Foundation-AMI]] ← provides ← [[AMI-Sharing]]
+- Product-Specific AMI ← extends ← [[Foundation-AMI]]
 
 ## Contradictions
 - 与 [[ctp-topic-58-aws-ec2-image-builder]] 描述不同 AMI 生命周期阶段：

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

@@ -4,53 +4,56 @@ type: source
 tags:
   - Azure
   - Landing-Zone
-  - Cloud-Transformation
   - CTP
+  - Cloud-Transformation-Programme
 date: 2026-04-14
+last_updated: 2026-05-06
 ---
 
 ## Source File
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md]]
 
 ## 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 实现精细化访问控制
+- 核心主题：Micro Focus 内部 Azure Landing Zone（着陆区）架构规划，旨在简化团队采用 Azure 云
+- 问题域：跨团队依赖、手动部署瓶颈、Azure 企业级接入与合规管控
+- 方法/机制：使用 Azure 管理组（Management Groups）分层组织订阅；平台/着陆区/退役/沙盒四区分离；Terraform Cloud 实现基础设施自动化；PIM 强制最小权限访问
+- 结论/价值：Landing Zone 以模板化为核心，提供身份访问管理、审计、合规、安全监控、网络四大支柱；团队可在自动化保障下独立部署创新工作负载，减少跨团队依赖
 
 ## 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 管理跨订阅依赖，支持分层架构
+- Kishore Garlopati（演讲人）通过 Azure Enterprise Enrollment + Azure AD 完成企业接入，目标是让各团队以最小依赖部署 Azure 工作负载
+- Azure 管理组类似 Windows 父目录，按四区组织：platform（身份/连接）、landing zones（模板化项目）、decommission（停用资源）、sandbox（隔离实验）
+- 连接订阅（Connectivity）作为所有入站/出站 Azure 流量的中心枢纽，集成了 DDoS 防护和 Checkpoint 防火墙
+- Landing Zone 的核心设计原则：可扩展（Scalable）、模块化（Modular）、全自动化（Fully Automated）
+- Terraform Cloud 通过 Terraform State 管理订阅间依赖关系，实现跨订阅基础设施编排
+- Privileged Identity Management (PIM) 和特权访问组确保用户获得恰到好处的角色权限
 
 ## 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 环境允许团队在隔离环境中实验工作负载
+> "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." — 沙盒订阅的灵活性价值
 
 ## 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 的组成部分，通过访问组管理用户权限，支持基于角色的策略执行
+- [[Azure-Landing-Zone]]：微软推荐的云采用框架，通过管理组和订阅层次结构为 Azure 工作负载提供可扩展、模块化、自动化的基础平台
+- [[Management-Groups]]：Azure 组织实体的高层容器，类似 Windows 父目录，用于分层管理策略和访问权限
+- [[Privileged-Identity-Management-PIM]]：Azure AD 功能，通过实时特权访问减少持久性管理员权限，降低凭证被盗风险
+- [[Terraform-Cloud]]：HashiCorp 基础设施即代码平台，支持 Terraform State 跨订阅依赖管理
+- [[Cloud-Transformation-Programme]]：Micro Focus 云转型计划，覆盖 AWS/Azure 多云 Landing Zone 建设
 
 ## Key Entities
-- [[Kishore Garlopati]]：演讲者，Azure Landing Zone 架构overview主讲人
-- [[Micro Focus]]：使用 Azure Landing Zone 进行云转型的企业组织，参考 [[AWS Landing Zone]] 在 Micro Focus 的实践经验
+- [[Kishore-Garlopati]]：Micro Focus 云架构师，Azure Landing Zone 方案主讲人
+- [[Micro-Focus]]：企业软件公司，其云转型计划（CTP）推进多云 Landing Zone 架构落地
+- [[Azure-Enterprise-Enrollment]]：Azure 企业协议接入点，是组织使用 Azure 的前提条件
+- [[Azure-Active-Directory]]：Azure 身份与访问管理服务，用于用户认证和策略控制
 
 ## 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 的云端编排平台）
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← comparable_to ← [[ctp-topic-34-azure-landing-zone-architecture-overview]]
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← related_to ← [[ctp-topic-34-azure-landing-zone-architecture-overview]]
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[ctp-topic-1-gruntwork-landing-zone-architecture]]
+- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← related_to ← [[ctp-topic-34-azure-landing-zone-architecture-overview]]
 
 ## Contradictions
-- 无已知冲突内容
+- 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 对比：
+  - 冲突点：AWS 侧使用 Gruntwork 基础设施模块 + Jenkins 构建 Landing Zone，Azure 侧使用 Terraform Cloud + 管理组
+  - 当前观点：Azure Landing Zone 通过 Terraform Cloud 管理订阅间状态，适合 Micro Focus 多云战略
+  - 对方观点：AWS Gruntwork LZ 通过 Jenkins CI/CD 管道，强调产品服务应有业务上下文（AWS Service Catalog）
+  - 说明：两者均为 CTP 下的 Landing Zone 实现，技术栈差异由多云战略驱动，非矛盾冲突

wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md

@@ -6,59 +6,55 @@ tags:
   - Email
   - AWS
   - CTP
-  - Cloud-Email
+  - Cloud-Transformation
 date: 2026-04-14
 ---
 
 ## Source File
-- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]]
 
 ## Summary（用中文描述）
-- 核心主题：SendGrid 被选定为经典和新 Landing Zone 的标准邮件服务，同时更新了 Cyber Suite 加密套件标准。
-- 问题域：企业邮件服务迁移——现有邮件网关（Port 25 不安全、即将下线）和 SES（每封限制 50 收件人）无法满足云环境需求。
-- 方法/机制：SendGrid 支持每封最多 1,000 收件人、全云兼容、TLS 端到端加密、双因素认证；提供两种架构（直连 SendGrid vs 中继服务器），通过全球中继节点（伦敦/印度/东京）走私有线路汇至美国数据中心处理；支持计划覆盖每月 500 万封邮件。
-- 结论/价值：SendGrid 统一替换现有分散邮件方案，提升安全性（TLS/2FA）、扩展性（1,000 收件人）和云就绪度；Cyber Suite 标准更新了行业标准合规加密套件清单。
+- 核心主题：Cloud Transformation Program（CTP）正式采用 SendGrid 作为标准邮件服务，取代原有的语义消息网关和 SES 方案；同时更新了 Cyber Suite 安全加密标准。
+- 问题域：企业邮件服务选型、云环境兼容性、安全合规要求
+- 方法/机制：SendGrid 提供两种架构——直连发送（需 TLS）和中继发送（供不支持 TLS 的应用使用）；数据通过伦敦、印度、东京等中继服务器经私有链路汇至美国数据中心处理。
+- 结论/价值：SendGrid 支持每封邮件最多 1000 名收件人（对比 SES 仅 50 人），完全云兼容，支持实时监控日志、双因素认证和 TLS 端到端加密，月支持额度 500 万封邮件，SPF/DKIM 记录为有效发送的必要条件。
 
 ## Key Claims（用中文描述）
-- SendGrid 通过支持每封邮件最多 1,000 收件人，解决了 SES 每封仅 50 收件人的限制。
-- 现有语义消息网关通过 Port 25 向公共互联网中继邮件，存在安全漏洞，且托管在即将停用的本地网络上。
-- SendGrid 直连模式要求使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587 并启用 TLS。
-- SPF 和 DKIM 记录是确保邮件正常送达（避免进入垃圾箱或被拒收）的必要配置。
-- API 密钥每 180 天轮换一次，邮件日志保留七天。
-- Cyber Suite 标准中的可选套件因包含 CBC（Cipher Block Chaining）模式而被视为弱加密，使用非标准加密套件的产品需经 PSAC 团队审查。
+- SendGrid 被 CTP 采纳为经典和新 Landing Zone 的标准邮件服务，取代存在安全风险且即将退役的本地语义消息网关（通过不安全的 25 端口中继邮件）
+- SES 现有限制为每封邮件仅 50 名收件人，SendGrid 扩展至 1000 名收件人
+- SendGrid 全云兼容，月处理约 300 亿封邮件，提供实时监控日志、双因素认证和 TLS 端到端加密
+- 直连发送架构要求：使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587、启用 TLS、发件地址必须为 software.microcopy.com 域；不支持按域名屏蔽邮件
+- 邮件日志保留 7 天，API 密钥每 180 天轮换一次，SPF 和 DKIM 记录是避免邮件进入垃圾箱或被拒收的必要条件
+- Cyber Suite 标准文档已更新，列出 FIPS/Java/Golang/Node.js/OpenCel 等标准中认可的安全加密套件
 
 ## Key Quotes
-> "SendGrid overcomes these issues by allowing up to 1,000 recipients per message and being fully cloud-compatible. Almost 30 billion emails per month customers are already used across the whole country." — Rejoy Ganapati & Rajiv, CTP Topic 36
+> "SendGrid is being adopted as the standard email service for both classic and new landing zones, replacing the existing semantic message gateway and SES solutions." — Rejoy Ganapati & Rajiv, CTP Session
 
-> "SPF and DKIM records are essential for valid email sending to avoid emails landing in junk folders or being rejected." — CTP Topic 36
+> "The existing semantic message gateway has security concerns because it relays mail to the public internet through port 25, which is not secure." — CTP Session 背景说明
 
-> "An optional Cyber Suite is available for backward compatibility, but it includes CBC (Cipher Block Chaining) which is considered weak." — Yu-Yan, PSAC Cyber Suite Update
+> "SendGrid overcomes these issues by allowing up to 1,000 recipients per message and being fully cloud-compatible." — CTP Session 核心优势
+
+> "SPF and DKIM records are essential for valid email sending to avoid emails landing in junk folders or being rejected." — SendGrid 配置要求
 
 ## Key Concepts
-- [[SPF]]：发件人策略框架（Sender Policy Framework），DNS 记录类型，用于声明哪些邮件服务器被授权代表域名发送邮件，防止邮件伪造和垃圾邮件。
-- [[DKIM]]：域名密钥识别邮件（DomainKeys Identified Mail），通过加密签名验证邮件内容在传输过程中未被篡改，确保发件人身份真实性。
-- [[TLS]]：传输层安全协议（Transport Layer Security），在 SendGrid 中用于端到端加密邮件传输，防止中间人攻击和数据窃听。
-- [[API-Key-Rotation]]：API 密钥定期轮换策略，SendGrid 要求每 180 天轮换一次 API 密钥，是安全运维的基本规范。
-- [[Cyber-Suite]]：行业标准加密套件集合（如 FIPS、Java、Golang、Node.js、OpenCell for CNC++），PSAC 负责维护和更新。
-- [[CBC-Mode]]：密码块链接模式（Cipher Block Chaining），一种分组加密工作模式，因存在已知攻击向量（如 POODLE）而被视为弱加密方式，不推荐使用。
+- [[SendGrid]]：企业云邮件服务，支持直连和中继两种架构，月处理约 300 亿封邮件
+- [[Landing Zone]]：AWS Landing Zone，云基础设施标准架构
+- [[SPF]]：发件人策略框架，用于邮件身份验证
+- [[DKIM]]：域名密钥识别邮件，用于邮件身份验证
+- [[Cyber Suite]]：企业加密套件标准，涵盖 FIPS/Java/Golang/Node.js/OpenCel 等
 
 ## Key Entities
-- [[Rejoy Ganapati]]：SendGrid 演讲者之一，CTP Topic 36 讲师。
-- [[Rajiv]]：SendGrid 演讲者之一，CTP Topic 36 讲师。
-- [[Yu-Yan]]：PSAC（Product Security Advisory Committee）成员，负责 Cyber Suite 标准的更新与宣讲。
-- [[PSAC]]：Product Security Advisory Committee，产品安全咨询委员会，负责维护 Cyber Suite 加密标准。
-- [[SendGrid]]：Twilio 旗下的云邮件服务，作为 CTP 标准邮件服务被采纳，支持大规模邮件发送、企业级安全和云原生架构。
-- [[Twilio]]：云通信平台，SendGrid 隶属其下，是全球大规模邮件发送的基础设施提供商。
+- [[Rejoy Ganapati]]：SendGrid 方案的联合主讲人之一
+- [[Rajiv]]：SendGrid 方案的联合主讲人之一
+- [[Yu-Yan]]：PSAC 团队成员，Cyber Suite 标准更新主讲人
+- [[PSAC]]：Product Security Architecture Committee，负责 Cyber Suite 标准制定
 
 ## Connections
-- [[CTP-Topic-12-SES-SMTP]] ← replaces ← [[ctp-topic-36-sendgrid-as-an-email-service]]（SendGrid 替换 SES SMTP 模块作为标准邮件服务）
-- [[ctp-topic-36-sendgrid-as-an-email-service]] ← extends ← [[AWS-Landing-Zone]]（SendGrid 接入是 Landing Zone 通信层的基础组件）
-- [[ctp-topic-36-sendgrid-as-an-email-service]] ← depends_on ← [[SPF]]（SPF 记录是 SendGrid 邮件送达的必要条件）
-- [[ctp-topic-36-sendgrid-as-an-email-service]] ← depends_on ← [[DKIM]]（DKIM 签名是 SendGrid 邮件验证的必要条件）
-- [[ctp-topic-36-sendgrid-as-an-email-service]] ← relates_to ← [[ctp-topic-37-secrets-certificates-management]]（TLS 加密和 API 密钥轮换同属安全运维范畴）
+- [[CTP Topic 12 Using SES SMTP service terraform module]] ← related_to ← [[CTP Topic 36 SendGrid as an Email Service]]（同一邮件服务主题，SES 为旧方案）
+- [[CTP Topic 47 Enterprise Architecture Cloud Standards]] ← extends ← [[CTP Topic 36 SendGrid as an Email Service]]（企业云标准的一部分）
 
 ## Contradictions
-- 与 [[ctp-topic-12-using-ses-smtp-service-terraform-module]] 冲突：
-  - 冲突点：SES SMTP 作为企业标准邮件服务与 SendGrid 被选定为新标准之间的矛盾。
-  - 当前观点：SendGrid 取代 SES 成为新标准邮件服务（SES 每封限制 50 收件人，无法满足大规模需求）。
-  - 对方观点：SES 通过 Terraform 模块化管理，适合特定 AWS 原生集成场景。
+- 与 [[CTP Topic 12 Using SES SMTP service terraform module]] 存在内容重叠：
+  - 冲突点：两期 CTP 主题均涉及邮件服务，但 Topic 12 介绍 SES SMTP，本期介绍 SendGrid
+  - 当前观点：SendGrid 取代 SES 作为标准方案（每封邮件收件人从 50 人扩展至 1000 人）
+  - 对方观点：SES 仍通过 Terraform 模块提供服务（可能用于遗留场景）

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

@@ -14,48 +14,47 @@ date: 2026-04-14
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md]]
 
 ## Summary（用中文描述）
-- 核心主题：SAS 数据库团队在 AWS 云上的数据库架构与运维实践
-- 问题域：企业级 SaaS 数据库管理、跨区域多数据库引擎运维、数据库高可用架构
+- 核心主题：CTP（CSP Transformation Programme）主题 40 —— AWS 云上 SaaS 数据库架构，介绍企业级数据库团队如何设计、管理和运维多租户 SaaS 数据库解决方案
+- 问题域：企业数据库团队在公有云（AWS）环境中的运维管理、高可用设计、成本优化和迁移实践
 - 方法/机制：
-  - 全球分布式团队（美国/加拿大/印度/以色列）提供 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）的集成
+  - 多数据库引擎支持（Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL）
+  - 多可用区高可用架构（主备分离 + Witness）
+  - 监控工具链（Sidescope、Oracle OEM、CloudWatch、Foglight）
+  - 自动化运维（Shell、Terraform、AWS CLI、PowerShell）
+- 结论/价值：提供企业级 SaaS 数据库架构的完整运维视图，涵盖团队协作、SLA 支持、迁移策略和未来规划
 
 ## Key Claims（用中文描述）
-- SAS 数据库团队在全球 4 个国家设有办公地点，管理 500+ 数据库和 1000+ DB 服务器
-- 数据库主要部署在 Application VPC 内，集成安全措施
-- 高可用架构采用三可用区部署模式：一区主库、二区备用库、三区见证节点
-- 报告数据库在第三可用区部署只读仓库，通过 VPN 安全访问
-- Oracle GoldenGate 用于多租户场景，支持平滑迁移（零停机或最小停机）
-- 日常运维每月处理 400-500 个 SSR 和 IM，每月至少执行 10 个变更
+- SAS 数据库团队通过 Oracle Data Guard、Postgres Active-Passive 和 RDS HA 实现多可用区高可用部署，确保业务连续性
+- 企业级数据库迁移需实现无缝迁移（无缝或不间断），通过 Oracle Golden Gate 支持多租户场景
+- 多租户 SaaS 数据库运行在应用 VPC 中，集成安全措施，支持客户通过 VPN 访问只读报表仓库
 
 ## Key Quotes
-> "The idea was to move those databases seamless without downtime or with minimum downtime." — 描述 Oracle GoldenGate 数据中心迁移项目的核心目标
+> "The idea was to move those databases seamless without downtime or with minimum downtime." — 数据中心迁移的核心目标
 
-> "Databases reside mostly on application VPCs with integrated security measures." — 数据库安全部署原则
+> "Databases are run in two availability zones within a region, with a primary database in one zone, a standby database in the second, and a witness in the third to observe and manage failovers." — 多可用区高可用架构描述
 
 ## Key Concepts
-- [[高可用（High Availability）]]：关注系统运行时间，MTBF 为衡量指标
-- [[Oracle Data Guard]]：Oracle 数据库的高可用解决方案，用于主备复制和故障切换
-- [[Multi-AZ Deployment]]：跨多个可用区部署数据库，确保故障隔离和灾难恢复能力
-- [[Database Migration]]：使用 Oracle GoldenGate 实现零停机或最小停机迁移
-- [[DB-as-a-Service]]：托管数据库服务模式（AWS RDS、Aurora）
+- [[Multi-AZ High Availability]]：多可用区高可用架构，在区域内两个 AZ 部署主备数据库，第三个 AZ 部署 Witness 观察器和管理器
+- [[Oracle Data Guard]]：Oracle 数据库的高可用和灾难恢复技术，用于实现主备复制和故障切换
+- [[AWS RDS High Availability]]：AWS RDS 的多可用区部署模式，提供自动故障切换能力
+- [[Database Migration]]：数据中心迁移项目，目标是无缝或最小停机迁移
+- [[Multi-Tenancy]]：多租户 SaaS 数据库架构，支持多个客户共享基础设施
 
 ## Key Entities
-- [[AWS]]：Amazon Web Services，提供基础设施和托管数据库服务
-- [[Amazon RDS]]：关系型数据库服务，支持 Multi-AZ 部署
-- [[Amazon Aurora]]：云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构
-- [[AWS CloudWatch]]：监控和可观测性服务
-- [[Terraform]]：基础设施即代码工具
-- [[Micro Focus]]：SAS 产品的母公司，数据库团队隶属该组织
+- [[Micro Focus]]：企业 IT 运维解决方案提供商，其产品 Sidescope 和 Operations Bridge Manager 用于数据库监控
+- [[AWS Aurora]]：AWS 的云原生关系数据库，PostgreSQL 兼容版本
+- [[AWS RDS]]：AWS 托管数据库服务，支持多种数据库引擎
+- [[AWS CloudWatch]]：AWS 监控服务，用于数据库性能监控和告警
+- [[Oracle Golden Gate]]：Oracle 数据复制和集成软件，支持多租户场景
 
 ## 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]]
+- [[CTP Topic 7 SaaS Landing Zone Design]] ← related_to ← [[CTP Topic 40 SaaS Database Architecture On AWS Cloud]]
+- [[CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)]] ← related_to ← [[CTP Topic 40 SaaS Database Architecture On AWS Cloud]]
+- [[CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora]] ← related_to ← [[CTP Topic 40 SaaS Database Architecture On AWS Cloud]]
 
 ## Contradictions
-- 无明显冲突内容
+- 无明显内容冲突
+
+## Notes
+- 原始来源为 NAS 存储的视频文件（CTP Topic 40）
+- 状态：已通过 Gemini 生成摘要，待 Whisper 转录后可补充详细内容

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

@@ -31,9 +31,9 @@ date: 2026-04-14
 > "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 概念一致）
+- [[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 密钥分发给组织内所有账户
+- [[AMI-Sharing]]：跨账号 AMI 共享机制，将 AMI、EBS 卷和 KMS 密钥分发给组织内所有账户
 - [[ARM-AMI]]：ARM 处理器架构的 AMI，自 2023 年 5 月起纳入统一发布计划
 - [[CCOE]]：Cloud Center of Excellence，负责提供和维护企业标准 AMI
 - [[ADM]]：Architecture Decision Management，AMI 路线图优先级的主要驱动来源

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

@@ -1,57 +1,57 @@
 ---
 title: "CTP Topic 58 AWS EC2 Image Builder"
 type: source
-tags:
-  - AWS
-  - EC2
-  - Image-Builder
-  - CTP
-  - AMI
+tags: [AWS, EC2, Image-Builder, CTP, DevOps]
 date: 2026-04-14
+sources: []
+last_updated: 2026-04-28
 ---
 
 ## Source File
 - [[raw/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 安全扫描
+- 核心主题：AWS EC2 Image Builder 服务 — 自动化创建、管理和分发 AMIs 及 Docker 镜像的托管服务
+- 问题域：企业 AWS Landing Zone 环境中的标准化镜像构建与分发流程
+- 方法/机制：通过 Image Pipeline、Image Recipe、Infrastructure Configuration、Distribution Settings 等组件协同工作；使用 YAML 定义镜像配方；CCOE 提供 Golden AMI，产品团队可在此基础上追加自定义组件
+- 结论/价值：提升镜像构建效率、整合安全加固标准、跨账号/跨区域自动化分发，与 AWS Organizations 和 AWS RAM 深度集成
 
 ## 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 扫描集成正在评估中
+- Image Builder 通过组件化设计（Component）实现模块化镜像定制，每个组件是源 AMI 内执行的一个步骤
+- 当前 AMI 发布流程依赖 GitLab 仓库中的 OS 加固脚本 + Jenkins + Packer，存在交付周期长、跨 Landing Zone 兼容性差等问题
+- Image Builder 与 AWS Organizations 和 AWS RAM 集成，支持跨托管账户的 AMI 分发
+- POC 已实现 CentOS 7 和 Ubuntu 18 的端到端 Pipeline，CCOE 加固脚本已转换为独立组件
+- AWS Inspector 集成用于 AMI 安全扫描，Lambda 工作流触发扫描并通过邮件通知上传报告至 S3
 
 ## 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." — 产品团队通过服务模块添加组件的机制
+> "A component is basically just a particular step that you want to execute in order to achieve the output AMI." — 组件定义
+> "Due to these limitations, 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." — 当前痛点与团队应对方式
 
 ## 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 安全扫描工具
+- [[AMI-Image-Builder]]：AWS 托管服务，用于自动化 AMIs 和 Docker 镜像的创建、管理和分发
+- [[Image-Pipeline]]：定义 AMI 发布时间线，包含安装、安全加固和分发计划
+- [[Image-Recipe]]：YAML 编写的配方，定义源 AMI 与输出 AMI 的关系；Container Recipe 支持 Docker 镜像
+- [[Golden-AMI]]：CCOE 构建的基础镜像（Golden AMI），产品团队在其上追加组件
+- [[AWS-Organizations]] 与 [[AWS-RAM]]：跨账号分发 AMIs 的机制
+- [[AWS-Inspector]]：集成用于 AMI 安全扫描，发现安全漏洞和合规问题
+- [[AWS-Landing-Zone]]：背景上下文 — Image Builder 服务于 Landing Zone 环境的标准化需求
 
 ## Key Entities
-- [[AWS]]：Image Builder 服务的云提供商
+- [[AWS]]：服务提供商
+- [[AWS-Inspector]]：安全扫描集成
+- [[AWS-Organizations]]：跨账号管理
+- [[AWS-RAM]]：资源访问管理
+- [[AWS-CloudWatch]]：日志发布目标
+- [[AWS-Lambda]]：触发扫描和通知的工作流引擎
+- [[Qualys]]：安全扫描集成（评估中）
+- [[Packer]]：当前 AMI 构建工具（将被 Image Builder 替代）
+- [[Jenkins]]：当前 CI/CD 流程（将被 Image Builder 替代）
+- [[Terraform]]：用于创建 Image Builder 资源的 IaC 工具
 
 ## 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 自动化策略相关）
+- [[CTP-Topic-50-AMI-Roadmap]] ← relates_to ← [[CTP-Topic-58-AWS-EC2-Image-Builder]]
+- [[CTP-Topic-26-Standard-AMI-Process]] ← extends ← [[CTP-Topic-58-AWS-EC2-Image-Builder]]
+- [[CTP-Topic-35-AWS-Landing-Zone]] ← belongs_to ← [[CTP-Topic-58-AWS-EC2-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 页面的冲突）

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

@@ -11,7 +11,7 @@ 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.md]]
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md]]
 
 ## Summary（用中文描述）
 - 核心主题：PostgreSQL 在 Amazon RDS 与 Aurora 两种托管方案之间的技术差异对比，涵盖性能、成本、架构、灾备与高可用性等维度

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

@@ -13,51 +13,51 @@ date: 2026-04-14
 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md]]
 
 ## 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 是性能优化的关键配置
+- 核心主题：AWS Redshift 数据仓库的架构、核心组件及关键特性
+- 问题域：企业级云数据仓库设计与选型
+- 方法/机制：Redshift 集群架构（Leader Node + Compute Node）、列式存储 vs 行式存储、MPP 大规模并行处理、数据压缩、Sort Key 与 Dist Key 优化
+- 结论/价值：Redshift 是完全托管的 PB 级云数据仓库解决方案，专为 OLAP 场景设计，提供快速安装、自动备份、点时间恢复及跨区域灾难恢复能力
 
 ## Key Claims（用中文描述）
-- Redshift 通过 Leader Node 管理 Schema、元数据和查询计划，将指令分发至 Compute Node 执行，实现 MPP（大规模并行处理），显著提升查询速度和响应时间
-- Redshift 支持列式存储（适合数据仓库操作）和行式存储两种模式，列式存储因更快的查询性能和更高的内存利用率而更适合 OLAP 场景
-- RA3 实例类型因其成本效益和大规模存储容量而被推荐，底层使用 AWS 托管的 NVMe 存储
-- Sort Key（排序键）和 Dist Key（分布键）是 Redshift 性能优化的核心机制，决定数据分布和查询执行效率
+- Redshift 通过 Leader Node 管理 Schema、元数据和查询计划，由 Compute Node 在各 Slice 上并行执行查询，实现高速数据检索
+- Redshift 支持三种实例类型（Dense Compute、Dense Storage、RA3），RA3 以 AWS 托管 NVMe 存储提供成本效益和大规模存储容量
+- MPP（大规模并行处理）通过跨多个 Compute Node 并行处理查询，显著提升查询速度和响应时间
+- 列式存储专为数据仓库操作优化，相比行式存储具有更快的查询性能和更高的内存使用效率
+- Sort Key 和 Dist Key 在优化查询性能和管理 Compute Node 间数据分布方面起关键作用
 
 ## 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 实例优势
+> "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." — Redshift 核心定位
+> "The leader node manages schema, warehouse metadata, and query planning, distributing instructions to compute nodes." — 架构职责划分
+> "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 上执行查询并返回结果
+- [[MassivelyParallelProcessing]]：跨多个计算节点并行处理查询，提升查询速度和响应时间
+- [[ColumnarStorage]]：列式存储，专为数据仓库操作优化，具有更快的查询性能和更高的内存使用效率
+- [[RowBasedStorage]]：行式存储，适用于事务性操作
+- [[DataCompression]]：数据压缩技术（如 LZO），减少数据大小以提升性能
+- [[SortKey]]：排序键，用于优化查询和管理 Compute Node 间数据分布
+- [[DistributionKey]]：分布键（Dist Key），决定数据在 Compute Node 间的分布方式
+- [[SliceArchitecture]]：Compute Node 内部的数据处理单元，每个 Slice 独立执行查询片段
+- [[OLAP]]：在线分析处理，Redshift 的主要工作负载类型
 
 ## 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
+- [[AWSRedshift]]：AWS 提供的大规模并行云数据仓库服务，完全托管，支持 PB 级数据
+- [[LeaderNode]]：Redshift 集群中的协调节点，负责 Schema 管理、元数据维护和查询规划
+- [[ComputeNode]]：Redshift 集群中的计算节点，负责在 Slice 上执行查询并返回结果
+- [[JDBC]]：Java 数据库连接协议，Redshift 客户端连接方式之一
+- [[ODBC]]：开放数据库连接协议，Redshift 客户端连接方式之一
+- [[AWSManagedNVMe]]：RA3 实例使用的 AWS 托管 NVMe 存储，提供高性能和成本效益
 
 ## 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]]
+- [[CTP_Topic_58_AWS_EC2_Image_Builder]] ← topic_related ← [[AWSRedshift]]（同属 AWS Landing Zone 学习系列）
+- [[AWSRedshift]] ← uses ← [[MassivelyParallelProcessing]]
+- [[AWSRedshift]] ← uses ← [[ColumnarStorage]]
+- [[AWSRedshift]] ← uses ← [[DataCompression]]
+- [[LeaderNode]] ← coordinates ← [[ComputeNode]]
 
 ## 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 部署支持更灵活
+- 与 [[CTP_Topic_66_ExposingDifferencesBetweenPostgreSQLRDSandAurora]] 潜在关系：
+  - 冲突点：PostgreSQL RDS/Aurora 与 Redshift 在数据仓库场景下的取舍
+  - 当前观点：Redshift 专为 OLAP 设计（PB 级、列式存储、MPP）
+  - 对方观点：PostgreSQL RDS/Aurora 适合混合 OLTP/OLAP 场景
+  - 说明：两者定位不同，但均用于数据存储与查询，需根据具体场景选择

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

@@ -1,8 +1,9 @@
 ---
 title: "CTP Topic 7 SaaS Landing Zone Design"
 type: source
-tags: []
+tags: [AWS, Landing-Zone, SaaS, CTP, Multi-Account, Terraform, Jenkins]
 date: 2026-04-14
+last_updated: 2026-05-06
 ---
 
 ## Source File
@@ -49,9 +50,9 @@ date: 2026-04-14
 ## 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-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]] ← uses ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] ← related_to ← [[ctp-topic-7-saas-landing-zone-design]]
+- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] ← 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]]
 

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

@@ -4,53 +4,67 @@ type: source
 tags:
   - AWS
   - Backup
-  - Cloud Transformation Programme
+  - CTP
+  - Cloud Transformation
   - SRE
   - DR
 date: 2026-04-14
+sources: []
+last_updated: 2026-04-28
 ---
 
 ## Source File
 - [[raw/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 实现"集中管控 + 分散执行"的平衡，标准化备份流程同时保留产品团队灵活性
+- 核心主题：AWS Backup 在云转型计划中的具体落地实施
+- 问题域：企业级 AWS 环境中如何标准化备份流程，如何让各产品团队在统一框架下自主管理备份
+- 方法/机制：
+  - SRE Core/Product/Architecture 团队协作设计 SRE 备份模型
+  - 采用 AWS Backup 作为战略备份工具（原生托管、多资源支持）
+  - 产品组在 DRA 账户中独立创建和管理备份计划、对齐预设备份策略
+  - 初始备份在源账户完成，复制到远程 DR 账户（或 Databunker 集中账户）
+  - AWS Backup Audit Manager 提供合规报告和 SNS 告警
+- 结论/价值：通过 SRE 备份模型标准化 AWS 备份，降低产品团队接入复杂度，实现跨账户、跨区域的合规备份和即时恢复
 
 ## Key Claims（用中文描述）
-- SRE 核心团队通过开发 SRE Backup Model，简化了 AWS Backup 的采纳门槛，使产品组能够在其 DRA 账户内自主创建和管理备份
-- AWS Backup 选择原因：原生托管服务、支持 TAC-based 备份计划、跨账户跨区域复制、备份不可变性、开箱即用审计报告、S3/RDS 点时间恢复
-- 备份设计：初始备份在源账户执行，复制到远程 DR 账户和区域（如 DR 不可用则使用 Databunker 作为集中备份账户），确保即时恢复能力
-- AWS Backup Audit Manager 提供合规控制：备份计划保护、最小频率和保留期、防手动删除恢复点、加密验证、计划性跨区域和跨账户备份
+- SRE Core/Product/Architecture 团队协作设计了 SRE 备份模型，使产品团队能在各自 DRA 账户内独立完成备份和恢复操作
+- AWS Backup 被选为 CTP 战略备份工具，因其为 AWS 原生服务，支持多资源类型、跨账户/跨区域、备份不可变性、开箱即用审计报告及 S3/RDS 时间点恢复
+- 备份设计从源账户取初始备份，复制到专属 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 账户内以实现即时恢复
+
+> "The SRE models were adjusted to optionally create custom KMS keys, which is a fundamental requirement for having a remote account and region for the AWS backup processes." — KMS 自定义密钥是实现跨账户跨区域备份的基础前提
+
+> "This keeps backups within the DR account for immediate restore, avoiding time-consuming data copies." — 备份保留在 DR 账户内可实现即时恢复
+
+> "AWS backup audit manager framework includes controls that help evaluate backup practices, providing compliance reports." — Audit Manager 提供合规评估控制项
 
 ## Key Concepts
-- [[AWS Backup]]：AWS 原生托管备份服务，支持多资源类型的集中备份和恢复策略管理
-- [[SRE Model]]：Site Reliability Engineering 团队开发的备份管理模式，为产品组提供标准化但可定制的备份基础设施
-- [[AWS Backup Audit Manager]]：AWS Backup 内置合规审计框架，提供备份状态报告和合规控制评估
-- [[跨账户备份]]：通过 AWS Organizations 将备份从源账户复制到独立的 DR/Bunker 账户，实现备份隔离
-- [[Vault Lock]]：备份保险库合规锁定模式，防止任何人（包括根用户）提前删除恢复点
+- [[DisasterRecovery]]：灾备策略，DR 账户用于存储跨区域备份副本
+- [[ImmutableBackup]]：备份不可变性，防止恢复点被手动删除
+- [[LifecyclePolicy]]：生命周期策略，管理备份的存储层级和自动过期
+- [[PointInTimeRecovery]]：时间点恢复，支持 S3 和 RDS 的精确恢复
+- [[SRE-Model]]：SRE 备份模型，由 SRE 团队创建 AWS Backup 计划、Vault、KMS 策略等，产品组自主控制
+- [[MultiAccountArchitecture]]：多账户架构，DRA 账户隔离灾备资源
 
 ## 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 账户内管理自有备份
+- [[AWSBackup]]：AWS 原生备份服务，作为 CTP 战略备份工具，提供跨账户/跨区域、不可变性、审计报告等能力
+- [[AWSBackupAuditManager]]：AWS Backup Audit Manager，提供合规报告、控制项评估和 SNS 告警
+- [[DRA-Account]]（DRA 账户）：每个生产工作负载账户的专属灾备账户，存储跨区域备份副本
+- [[Databunker]]：集中备份账户，当 DR 账户不可用时作为备份存储的备选集中账户
+- [[KMS]]：AWS Key Management Service，用于加密备份恢复点，支持自定义密钥
+- [[SRE-Core-Team]]：SRE Core 团队，与 SRE Product/Architecture 协作设计备份模型
+- [[SNS]]：Simple Notification Service，用于备份状态告警通知
 
 ## 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 的核心能力）
+- [[AWSBackup]] ← uses ← [[AWSBackupAuditManager]]
+- [[AWSBackup]] ← uses ← [[KMS]]
+- [[AWSBackup]] ← notifies via ← [[SNS]]
+- [[CTP-Topic-72-Implementing-an-Enterprise-DR-Strategy-Using-AWS-Backup]] ← extends ← [[CTP-Topic-73-AWS-Backup-Implementation]]
+- [[AWSBackup]] ← stores backups in ← [[DRA-Account]]
+- [[DRA-Account]] ← fallback ← [[Databunker]]
 
 ## 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/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md

@@ -6,7 +6,7 @@ date: 2026-04-27
 ---
 
 ## Source File
-- [[AI/If you have multiple interests, do not waste the next 2-3 years  如果你有多项兴趣爱好，不要浪费接下来的两三年时间。]]
+- [[raw/AI/If you have multiple interests, do not waste the next 2-3 years  如果你有多项兴趣爱好，不要浪费接下来的两三年时间。.md]]
 
 ## Summary（用中文描述）
 - 核心主题：在 AI 时代，多重兴趣不是弱点，而是个人最大的竞争优势；传统专业化分工已过时，通才型思维才是通往独立与自由的道路。

wiki/sources/install-wsl.md

@@ -10,7 +10,7 @@ date: 2026-04-18
 ---
 
 ## Source File
-- [[Home Office/Install WSL]]
+- [[raw/Home Office/Install WSL.md]]
 
 ## Summary（用中文描述）
 - 核心主题：Windows Subsystem for Linux (WSL) 的安装与配置

wiki/sources/learn-ai-for-free-directly-from-top-companies.md

@@ -9,7 +9,7 @@ date: 2026-04-16
 ---
 
 ## Source File
-- [[AI/Learn AI for free directly from top companies.md]]
+- [[raw/AI/Learn AI for free directly from top companies.md]]
 
 ## Summary（用中文描述）
 - 核心主题：汇总顶级科技公司和AI组织提供的免费学习资源，帮助用户免费学习AI技能

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

@@ -3,6 +3,7 @@ title: "Learning Sessions: Standard AMI Updates 20231205"
 type: source
 tags: ["AWS", "AMI", "Landing-Zone", "DevOps", "Automation"]
 date: 2023-12-05
+last_updated: 2026-05-08
 ---
 
 ## Source File
@@ -50,4 +51,5 @@ date: 2023-12-05
 - [[ctp-topic-58-aws-ec2-image-builder]] ← related_to ← [[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]]
 
 ## Contradictions
-- 暂无已知冲突
+- 与 [[ctp-topic-50-ami-roadmap-for-aws-amis]] 无冲突，EOL 时间线一致（CentOS 7/RHEL 7：2024 年 6 月；OpenSUSE Leap 15/OEL 7：2024 年 12 月）
+- 与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 无冲突，属 AMI 生命周期不同视角（本文侧重更新机制和验证自动化，Topic 26 侧重构建发布共享流程）

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

@@ -8,7 +8,7 @@ last_updated: 2026-04-28
 ---
 
 ## Source File
-- [[Home Office/Mac必装软件清单-2026-04-17.md]]
+- [[raw/Home Office/Mac必装软件清单-2026-04-17.md]]
 
 ## Summary（用中文描述）
 - 核心主题：Mac 用户必备软件推荐清单

wiki/sources/obsidian-官方-cli-命令全景速查表.md

@@ -6,7 +6,7 @@ date: 2026-04-28
 ---
 
 ## Source File
-- [[Skills/Obsidian 官方 CLI 命令全景速查表.md]]
+- [[raw/Skills/Obsidian 官方 CLI 命令全景速查表.md]]
 
 ## Summary（用中文描述）
 - 核心主题：Obsidian v1.12+ 官方 CLI 命令完整参考，包含 80+ 条命令，涵盖所有功能模块

wiki/sources/obsidian-必装-skills.md

@@ -6,7 +6,7 @@ date: 2026-04-28
 ---
 
 ## Source File
-- [[Skills/Obsidian 必装 Skills]]
+- [[raw/Skills/Obsidian 必装 Skills.md]]
 
 ## Summary（用中文描述）
 - 核心主题：Obsidian 生态中值得安装的 AI Agent Skills 全景盘点与配置指南

wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md

@@ -6,7 +6,7 @@ date: 2026-04-28
 ---
 
 ## Source File
-- [[raw/跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md]]
+- [[Scrapy + Playwright 抓取TikTok Shop Data]]
 
 ## Summary（用中文描述）
 - 核心主题：使用 Scrapy + Playwright 抓取 TikTok Shop 店铺数据的技术配置与实践指南

wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md

@@ -6,7 +6,7 @@ date: 2026-04-28
 ---
 
 ## Source File
-- [[跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]]
+- [[raw/跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md]]
 
 ## Summary（用中文描述）
 - 核心主题：使用 Apache Superset 构建 TikTok Shop 电商选品分析 Dashboard 的完整设计指南

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

@@ -6,7 +6,7 @@ date: 2026-04-17
 ---
 
 ## Source File
-- [[Home Office/WSL2 启动与网络配置指南.md]]
+- [[raw/Home Office/WSL2 启动与网络配置指南.md]]
 
 ## Summary（用中文描述）
 - 核心主题：WSL2（Windows Subsystem for Linux 2）日常使用操作与网络配置

wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md

@@ -6,7 +6,7 @@ date: 2026-04-28
 ---
 
 ## Source File
-- [[AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B]]
+- [[raw/AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B.md]]
 
 ## Summary（用中文描述）
 - 核心主题：在 Ubuntu 系统上通过 Ollama 本地部署 Qwen2.5-Coder 7B 代码大模型，并支持 REST API 和多语言 SDK 调用

wiki/sources/如何利用sora接口实现视频自动化生成工作流.md

@@ -6,7 +6,7 @@ date: 2026-04-27
 ---
 
 ## Source File
-- [[AI/如何利用Sora接口实现视频自动化生成工作流.md]]
+- [[raw/AI/如何利用Sora接口实现视频自动化生成工作流.md]]
 
 ## Summary（用中文描述）
 - 核心主题：使用 Sora API 接口实现视频生成的完全自动化工作流

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

@@ -6,7 +6,7 @@ date: 2026-04-23
 ---
 
 ## Source File
-- [[Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅]]
+- [[raw/Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅.md]]
 
 ## Summary（用中文描述）
 - 核心主题：通过本地部署 RSSHub 解决 YouTube 频道订阅跟踪问题

wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md

@@ -7,7 +7,7 @@ last_updated: 2026-04-28
 ---
 
 ## Source File
-- [[Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标]]
+- [[raw/Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标.md]]
 
 ## Summary（用中文描述）
 - 核心主题：开源 Logo Generator Skill——用 AI 生成 SVG Logo + 高级展示图的完整工作流

wiki/sources/我用-gemini-3-一口气做了-10-个应用-附教程.md

@@ -6,7 +6,7 @@ date: 2025-11-24
 ---
 
 ## Source File
-- [[AI/我用 Gemini 3 一口气做了 10 个应用，附教程.md]]
+- [[raw/AI/我用 Gemini 3 一口气做了 10 个应用，附教程.md]]
 
 ## Summary（用中文描述）
 - 核心主题：作者分享如何利用 Gemini 3（大模型）+ 前端 SVG/HTML 可视化，在极短时间内快速构建 10 个实际可用的 AI 应用，并总结了一套通用的 AI 应用开发方法论。

wiki/sources/电商视频prompt.md

@@ -6,7 +6,7 @@ date: 2026-04-28
 ---
 
 ## Source File
-- [[跨境电商/电商视频Prompt.md]]
+- [[raw/跨境电商/电商视频Prompt.md]]
 
 ## Summary（用中文描述）
 - 核心主题：AI 图生视频（Image-to-Video）Prompt 模块化库，专为 TikTok 电商宠物用品带货场景设计

wiki/sources/超达物流定价.md

@@ -6,7 +6,7 @@ date: 2025-12-19
 ---
 
 ## Source File
-- [[跨境电商/超达物流定价]]
+- [[raw/跨境电商/超达物流定价.md]]
 
 ## Summary（用中文描述）
 - 核心主题：超达物流服务渠道的定价规则与操作注意事项，聚焦 TikTok Shop 美国市场发货场景。