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

2026-04-24 04:02:45 +08:00
parent 4e9ee6f51e
commit a96baa8fb7
40 changed files with 1934 additions and 89 deletions
--- a/wiki/concepts/Agile-Ceremonies.md
+++ b/wiki/concepts/Agile-Ceremonies.md
@@ -0,0 +1,32 @@
+---
+title: "Agile Ceremonies"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## 定义
+敏捷仪式（Agile Ceremonies）是敏捷框架中定义的固定会议和活动，目的是促进团队协作、沟通和持续改进。
+
+## Scrum 标准仪式
+- **Sprint Planning（冲刺规划）：** Sprint 开始时，确定本 Sprint 要完成的工作
+- **Daily Stand-up（每日站会）：** 每天定时短会，回答三个问题：昨天完成什么、今天做什么、有什么阻碍
+  - 时长：15-30 分钟
+  - 围绕看板工具展开
+- **Sprint Review（冲刺评审）：** Sprint 结束时向利益相关方演示已完成的工作
+- **Sprint Retrospective（回顾会议）：** Sprint 结束时团队复盘，识别改进点
+
+## 仪式保留策略（混合框架）
+云转型团队保留 Scrum 的两个核心仪式：
+- **Daily Stand-up：** 确保快速同步团队状态
+- **Retrospective：** 驱动快速反馈循环，持续改进产品和开发文化
+
+放弃 Sprint 固定节奏以允许持续变更。
+
+## 最佳实践
+- 行动项必须带负责人（Owner）
+- 回顾会议输出具体可执行的改进措施
+
+## 来源
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
--- a/wiki/concepts/CAPA.md
+++ b/wiki/concepts/CAPA.md
@@ -0,0 +1,51 @@
+---
+title: "CAPA"
+type: concept
+tags: [Incident-Management, Post-mortem, Root-Cause, Preventive-Action]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+CAPA (Corrective and Preventive Action，纠正和预防措施) 是 Emergency Change 事后必须执行的流程，用于从事故中提取根本原因并预防同类问题再次发生。CAPA 通常与 Post-mortem 回顾结合使用。
+
+## Components
+
+### Corrective Action（纠正措施）
+- 修复当前事故的直接措施
+- 目标是恢复服务到期望状态
+- 通常在 Emergency Change 执行阶段完成
+
+### Preventive Action（预防措施）
+- 防止同类问题再次发生的长期措施
+- 目标是消除根本原因
+- 通常在 Post-mortem 分析后制定
+
+## Relationship with Emergency Change
+
+CAPA 是 Emergency Change 流程的关键组成部分：
+
+```
+Incident 发生
+    ↓
+Emergency Change 执行（Corrective Action）
+    ↓
+CAPA/Post-mortem 分析
+    ↓
+制定 Preventive Action
+    ↓
+可能转化为 Standard Change（避免未来同类事件）
+```
+
+## Process
+
+1. **Incident Review**：回顾事故经过
+2. **Root Cause Analysis**：识别根本原因
+3. **Corrective Action**：执行即时修复
+4. **Preventive Action**：制定长期预防措施
+5. **Follow-up**：跟踪措施执行情况
+6. **Closure**：完成 CAPA 记录
+
+## Sources
+
+- [[ctp-topic-30-managing-change]]
--- a/wiki/concepts/Continuous-Delivery.md
+++ b/wiki/concepts/Continuous-Delivery.md
@@ -0,0 +1,24 @@
+---
+title: "Continuous Delivery"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## 定义
+持续交付（Continuous Delivery）是一种软件工程方法，通过自动化流水线使代码变更可以在任何时候安全地部署到生产环境。
+
+## 核心特征
+- **随时可发布：** 代码变更经过自动化测试后，可随时部署
+- **无需等待固定周期：** 打破 Sprint/迭代边界
+- **自动化流水线：** 构建、测试、部署全流程自动化
+
+## 与 Kanban 的关系
+持续交付是 Kanban 框架的核心优势之一——当需求可以随时进入看板、完成即可交付时，团队可以更快地响应变化。
+
+## 与 Scrum 的对比
+Scrum 的批量发布模式（Sprint 结束时一次性发布）相比持续交付，延迟了价值交付时间，且积累的变更越多，发布风险越高。
+
+## 来源
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
--- a/wiki/concepts/Early-Live-Support.md
+++ b/wiki/concepts/Early-Live-Support.md
@@ -0,0 +1,61 @@
+---
+title: "Early Live Support"
+type: concept
+tags: [SRE, Cloud-Transformation, Go-Live, Support-Model]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+Early Live Support（早期上线支持）是 Build（构建）与 BAU（日常运维）之间的过渡阶段。在这个阶段，SRE 团队与产品团队紧密协作，确保新服务平稳上线并建立持续运营的支持模式。
+
+## Phase Overview
+
+```
+Build ──────→ Early Live Support ──────→ BAU
+  ↑              ↑                         ↑
+产品团队主导      ↑                         SRE 主导
+           SRE + 产品团队协作
+```
+
+## Key Activities
+
+### 1. Go-Live Checklist
+
+Early Live Support 阶段需要完成以下检查清单：
+
+| Item | Description |
+|------|-------------|
+| 监控覆盖 | 所有关键服务和基础设施都得到充分监控 |
+| 支持模型 | 明确 On-call Schedule 和升级路径 |
+| 事件响应流程 | 建立清晰的事件响应和升级流程 |
+| SLO/SLI 定义 | 定义服务等级目标和指标 |
+| 文档交接 | 完成技术文档和运维手册 |
+
+### 2. SRE Collaboration
+
+SRE 团队在此阶段：
+- 提供技术支持，协助解决上线问题
+- 验证监控和告警的有效性
+- 建立与产品团队的沟通渠道
+- 收集 BAU 阶段的运维需求
+
+### 3. Handoff Criteria
+
+从 Early Live Support 过渡到 BAU 的标准：
+- 所有监控面板正常运行
+- 事件响应流程经过演练
+- On-call Schedule 与 Service Desk 集成
+- 产品团队完成运维培训
+
+## Relationship with SRE
+
+Early Live Support 是 SRE 三阶段支持模型的关键环节：
+
+1. **Build**：SRE 参与架构评审，定义 SLO/SLI
+2. **Early Live Support**：SRE 提供上线支持，确保平稳过渡
+3. **BAU**：SRE 提供持续监控和可靠性保障
+
+## Sources
+
+- [[ctp-topic-30-managing-change]]
--- a/wiki/concepts/Emergency-Change.md
+++ b/wiki/concepts/Emergency-Change.md
@@ -0,0 +1,44 @@
+---
+title: "Emergency Change"
+type: concept
+tags: [Change-Management, ITSM, Incident-Response, CAPA]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+Emergency Change（紧急变更）是为了缓解事故（Incident）并尽快恢复服务到期望状态而需要立即执行的变更。与 Normal Change 不同，Emergency Change 可以在没有 CAB 预先批准的情况下执行，但事后必须通过 CAPA/Post-mortem 流程修复根因。
+
+## Characteristics
+
+|| Attribute | Value |
+|-----------|--------|
+| Approval Required | 事后审批 |
+| CAB Involvement | 事后汇报 |
+| Automation Level | 可部分自动化 |
+| Risk Level | 高（应急执行） |
+| Change Window | 即时执行 |
+| Post-Process | 必须 CAPA/Post-mortem |
+
+## Process Flow
+
+1. **Trigger**：Incident 触发应急响应
+2. **Assessment**：快速评估并决定是否执行 Emergency Change
+3. **Execution**：立即执行变更以缓解事故
+4. **Communication**：通知相关干系人
+5. **CAPA**：事后通过 CAPA 流程修复根因
+6. **Documentation**：完成变更记录和 Post-mortem
+
+## Key Principle
+
+> Emergency Change 的目标不是永久性补丁，而是通过 CAPA/Post-mortem 识别根本原因并制定长期解决方案。
+
+## CAPA Process
+
+CAPA（Corrective and Preventive Action）包含两个阶段：
+- **Corrective Action**：修复当前问题的即时措施
+- **Preventive Action**：预防同类问题再次发生的长期措施
+
+## Sources
+
+- [[ctp-topic-30-managing-change]]
--- a/wiki/concepts/HCX.md
+++ b/wiki/concepts/HCX.md
@@ -0,0 +1,37 @@
+---
+title: "Hybrid Cloud Extension (HCX)"
+type: concept
+tags:
+  - VMware
+  - Hybrid-Cloud
+  - Migration
+last_updated: 2026-04-25
+---
+
+## Hybrid Cloud Extension (HCX)
+
+VMware's hybrid cloud extension technology that enables any-to-any vSphere workload migration between on-premises and cloud environments.
+
+## Definition
+HCX enables bidirectional workload migration between any vSphere environments, supporting seamless movement of applications between on-premises data centers and VMware Cloud on AWS.
+
+## Key Features
+- **Any-to-Any Migration**: Migrate workloads between any vSphere environments
+- **Bidirectional**: Supports migration in both directions (on-prem → cloud and cloud → on-prem)
+- **Fast Migration**: Workloads can move in seconds
+- **No Re-architecture Required**: Applications can migrate without code changes
+
+## Use Cases
+- Cloud migration
+- Disaster recovery
+- Bursting to cloud
+- Data center evacuation
+- Cloud repatriation
+
+## Connections
+- [[VMware-Cloud-on-AWS]] ← enables ← [[HCX]]
+- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[HCX]]
+- [[ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]] ← related_to ← [[HCX]]
+
+## Sources
+- [[ctp-topic-43-vmware-cloud-on-aws]]
--- a/wiki/concepts/HybridDnsResolution.md
+++ b/wiki/concepts/HybridDnsResolution.md
@@ -0,0 +1,60 @@
+---
+title: "Hybrid DNS Resolution"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## Hybrid DNS Resolution
+
+混合 DNS 解析，指在 AWS VPC 环境与本地数据中心（On-prem）之间实现跨环境的域名解析能力，是企业云迁移和混合云架构的关键基础设施。
+
+## Problem
+
+在企业迁移到 AWS Landing Zone 的过程中，存在以下 DNS 解析需求：
+- AWS 内部的 VPC 需要解析本地数据中心的内部域名（如 `corp.internal`）
+- 本地数据中心的服务器需要解析 AWS VPC 内部的私有域名（如 `int-sas.local`）
+- 跨账号的 VPC 之间需要相互解析
+
+传统的分散式 DNS 管理无法有效解决这些问题。
+
+## Solution: Route 53 Resolver Endpoints
+
+AWS Route 53 Resolver 提供两个关键组件实现混合 DNS：
+
+### Inbound Endpoints（入站终端节点）
+
+- 用途：接收来自**本地数据中心**的 DNS 查询请求
+- 机制：本地 DNS 服务器将针对 AWS 私有域名的查询转发至 Inbound Endpoint 的 IP
+- 场景：本地用户访问 AWS 内部的私有服务（如 `*.int-sas.local`）
+
+### Outbound Endpoints（出站终端节点）
+
+- 用途：将** AWS VPC 内部**的 DNS 查询转发至本地 DNS 服务器
+- 机制：通过 Resolver Rules（解析规则）定义哪些域名需要转发，以及转发到哪个 IP
+- 场景：AWS 工作负载需要访问本地资源（如 GitHub Enterprise、遗留数据库）
+
+## Cross-Account Architecture
+
+在 AWS Landing Zone 中，集中化 DNS 管理的标准架构：
+
+1. **专用 DNS 账号**：在 Landing Zone 中设立专门的 DNS 账号（曾被称为 InfoBlocks 账号）
+2. **Private Hosted Zones (PHZ)**：在 DNS 账号中集中管理所有私有托管区
+3. **AWS RAM 共享**：通过 Resource Access Manager 将 Resolver Rules 共享给各业务账号
+4. **VPC 关联授权**：跨账号关联时，必须先由 PHZ 拥有者授权，再由 VPC 拥有者执行关联
+5. **Terraform 自动化**：新账号创建时自动完成规则共享与 VPC 关联
+
+## Key Concepts
+
+- [[Private Hosted Zone]]：AWS Route 53 私有托管区，在指定 VPC 内部解析自定义域名
+- [[Route 53 Resolver Rules]]：解析规则，定义域名的转发路径
+- [[VPC Association Authorization]]：跨账号关联的先授权后关联流程
+- [[AWS RAM]]：跨账号资源共享机制
+- [[AWS Landing Zone]]：DNS 架构的承载基础
+
+## Aliases
+
+- Hybrid DNS
+- Cross-Cloud DNS
+- On-Premises DNS Integration
--- a/wiki/concepts/Kanban.md
+++ b/wiki/concepts/Kanban.md
@@ -0,0 +1,33 @@
+---
+title: "Kanban"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## 定义
+Kanban 是一种敏捷框架，强调持续流动（continuous flow），无固定 Sprint 边界，允许随时调整优先级和需求。
+
+## 核心特征
+- **持续交付：** 无需等待 Sprint 结束即可发布
+- **随时变更：** 优先级可在任何时候调整
+- **可视化看板：** 通过列（列名）管理任务状态
+- **限制在制品（WIP）：** 控制同时进行的工作数量
+
+## 与 Scrum 的对比
+| 维度 | Scrum | Kanban |
+|------|-------|--------|
+| 迭代周期 | 固定 Sprint（1-4周） | 无固定周期 |
+| 变更时机 | Sprint 期间禁止 | 随时可调整 |
+| 发布节奏 | Sprint 结束时批量发布 | 持续交付 |
+| 仪式 | Sprint Planning/Review/Retrospective | 可选 ceremonies |
+
+## 企业实践：混合框架
+云转型团队采用以 Kanban 为主 + 保留 Scrum 仪式（每日站会和回顾会议）的混合方案，兼顾灵活性和反馈循环。
+
+## 来源
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
+
+## 别名
+- Kanban Framework
--- a/wiki/concepts/Normal-Change.md
+++ b/wiki/concepts/Normal-Change.md
@@ -0,0 +1,49 @@
+---
+title: "Normal Change"
+type: concept
+tags: [Change-Management, ITSM, CAB, Change-Window]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+Normal Change（正常变更）是一种包含一定风险或影响的变更类型，需要变更咨询委员会（CAB）的审批，并可能需要跨团队协调。与 Standard Change 不同，Normal Change 需要明确的变更窗口来执行。
+
+## Characteristics
+
+|| Attribute | Value |
+|-----------|--------|
+| Approval Required | 是（CAB 审批） |
+| CAB Involvement | 必须 |
+| Automation Level | 部分自动化或无 |
+| Risk Level | 中-高（需评估） |
+| Change Window | 需要明确的时间窗口 |
+
+## Process Flow
+
+1. **Request**：产品团队提交变更请求
+2. **Assessment**：评估变更的风险和影响
+3. **CAB Review**：变更咨询委员会审批
+4. **Scheduling**：安排变更窗口
+5. **Execution**：在变更窗口内执行
+6. **Verification**：验证变更结果
+7. **Closure**：完成变更记录
+
+## Relationship with Standard Change
+
+Normal Change 的理想状态是通过自动化逐步将其归入 Standard Change 范畴：
+
+- 识别重复的 Normal Change
+- 评估风险并制定标准化流程
+- 通过 IaC + CI/CD 实现自动化
+- 将 Normal Change 转化为 Standard Change
+
+## Example Use Cases
+
+- 跨账户的网络架构变更
+- 需要 CAB 审批的安全策略更新
+- 涉及多个团队协调的基础设施迁移
+
+## Sources
+
+- [[ctp-topic-30-managing-change]]
--- a/wiki/concepts/SDDC.md
+++ b/wiki/concepts/SDDC.md
@@ -0,0 +1,35 @@
+---
+title: "Software-Defined Data Center (SDDC)"
+type: concept
+tags:
+  - VMware
+  - SDDC
+  - Cloud
+last_updated: 2026-04-25
+---
+
+## Software-Defined Data Center (SDDC)
+
+A data center approach where all infrastructure is virtualized and delivered as a service. In the context of VMC on AWS, the SDDC is the core deployment unit managed through vCenter.
+
+## Definition
+SDDC extends the concept of software-defined computing (hypervisor), software-defined storage, and software-defined networking to the entire data center infrastructure. VMware Cloud on AWS deploys SDDCs on AWS infrastructure, managed through vCenter Server.
+
+## Key Characteristics
+- **Virtualized Compute**: VMware vSphere runs on bare metal servers
+- **Virtualized Storage**: Software-defined storage integrated with AWS storage
+- **Virtualized Networking**: NSX provides software-defined networking
+- **Unified Management**: vCenter Server manages the entire SDDC
+- **Cloud-Native Integration**: Native access to AWS services
+
+## SDDC Management
+- **VMware Cloud Services Portal**: Web-based portal for SDDC management
+- **Developer Center**: API Explorer for programmatic access
+- **Follow-Me-Help**: Access to VMware engineers for assistance
+
+## Connections
+- [[VMware-Cloud-on-AWS]] ← deploys ← [[SDDC]]
+- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[SDDC]]
+
+## Sources
+- [[ctp-topic-43-vmware-cloud-on-aws]]
--- a/wiki/concepts/Scrum.md
+++ b/wiki/concepts/Scrum.md
@@ -0,0 +1,29 @@
+---
+title: "Scrum"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## 定义
+Scrum 是一种敏捷框架，通过固定时长的 Sprint（冲刺）组织工作，每个 Sprint 通常为 1-4 周。
+
+## 核心组件
+- **Product Backlog：** 按优先级排序的需求列表
+- **Sprint Planning：** 每个 Sprint 开始时的规划会议
+- **Daily Scrum：** 每日站会（15 分钟内）
+- **Sprint Review：** Sprint 结束时演示已完成的工作
+- **Sprint Retrospective：** Sprint 结束时回顾改进点
+
+## 局限性
+- Sprint 期间不允许变更（no changes during sprint）
+- 固定节奏适合稳定需求，但不适合云转型等高变化频率的项目
+- 云转型团队因此转向 Kanban
+
+## 与其他框架的关系
+- **vs [[Kanban]]：** Scrum 有固定 Sprint 边界，Kanban 无固定迭代周期
+- **混合方案：** 企业实践中常见 Scrum 仪式（站会、回顾会议）+ Kanban 持续流动
+
+## 来源
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
--- a/wiki/concepts/Standard-Change.md
+++ b/wiki/concepts/Standard-Change.md
@@ -0,0 +1,56 @@
+---
+title: "Standard Change"
+type: concept
+tags: [Change-Management, ITSM, Automation, IaC, CI-CD]
+last_updated: 2026-04-14
+---
+
+## Definition
+
+Standard Change（标准变更）是一种预批准的变更类型，无需变更咨询委员会（CAB）的审批。在理想的 DevOps/SRE 实践中，标准变更应实现完全自动化，通过 IaC（基础设施即代码）+ CI/CD Pipeline 实现。
+
+## Characteristics
+
+|| Attribute | Value |
+|-----------|--------|
+| Approval Required | 否（预批准） |
+| CAB Involvement | 无需 |
+| Automation Level | 完全自动化（IaC + CI/CD） |
+| Risk Level | 低（已知变更，已评估） |
+| Change Window | 无限制 |
+
+## Implementation
+
+标准变更的实现依赖于以下技术栈：
+
+1. **IaC（基础设施即代码）**：Terraform/Terragrunt 声明式定义基础设施
+2. **CI/CD Pipeline**：Jenkins/GitHub Actions 自动执行 plan/apply
+3. **Automated Testing**：在部署前自动验证基础设施变更
+4. **Tagging Standards**：符合 AWS 标签规范，确保 Checkpoint 防火墙正确放行
+
+## Example Use Cases
+
+- AWS 标签验证（Tag Validation Tool）自动扫描资源合规性
+- VPC 自动化供给（Topic 61）：CIDR ≤ /22 自动审批
+- 标准 AMI 更新（Topic 50）：自动构建和发布
+
+## Relationship with Other Change Types
+
+```
+Standard Change ──(通过自动化提升)──→ Normal Change
+                                      ↑
+                                 CAB 审批
+                                 有风险影响
+
+Emergency Change ──(CAPA 修复根因)──→ Standard Change
+    ↓
+立即执行
+```
+
+## Goal
+
+将尽可能多的变更归类为标准变更，通过自动化减少人工审批负担，提高变更频率和可靠性。
+
+## Sources
+
+- [[ctp-topic-30-managing-change]]
--- a/wiki/concepts/Stretched-Cluster.md
+++ b/wiki/concepts/Stretched-Cluster.md
@@ -0,0 +1,37 @@
+---
+title: "Stretched Cluster"
+type: concept
+tags:
+  - VMware
+  - High-Availability
+  - AWS
+last_updated: 2026-04-25
+---
+
+## Stretched Cluster
+
+A cluster architecture that spans multiple availability zones, providing high availability and disaster recovery capabilities across geographic locations.
+
+## Definition
+In the context of VMware Cloud on AWS, a stretched cluster extends across availability zones (AZs) to provide increased resilience. If one AZ experiences failure, workloads can continue running in the other AZ.
+
+## Key Characteristics
+- **Cross-AZ Deployment**: Cluster nodes distributed across multiple availability zones
+- **High Availability**: Automatic failover if one AZ becomes unavailable
+- **Disaster Recovery**: Built-in DR capability without additional configuration
+- **Low Latency**: AWS AZs are designed for low latency interconnectivity
+
+## Use Cases
+- Mission-critical applications requiring high availability
+- Disaster recovery planning
+- Compliance requirements for geographic redundancy
+- Applications with strict RTO/RPO requirements
+
+## Connections
+- [[VMware-Cloud-on-AWS]] ← enables ← [[Stretched-Cluster]]
+- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[Stretched-Cluster]]
+- [[High-Availability]] ← implements ← [[Stretched-Cluster]]
+- [[Disaster-Recovery]] ← supports ← [[Stretched-Cluster]]
+
+## Sources
+- [[ctp-topic-43-vmware-cloud-on-aws]]
--- a/wiki/concepts/VMware-Cloud-on-AWS.md
+++ b/wiki/concepts/VMware-Cloud-on-AWS.md
@@ -0,0 +1,54 @@
+---
+title: "VMware Cloud on AWS (VMC on AWS)"
+type: concept
+tags:
+  - VMware
+  - AWS
+  - Hybrid-Cloud
+  - VMC
+last_updated: 2026-04-25
+---
+
+## VMware Cloud on AWS (VMC on AWS)
+
+A jointly engineered cloud service by VMware and AWS, where the VMware hypervisor runs natively on AWS bare metal servers. This is not simply deploying VMware software onto cloud infrastructure — it is a true joint engineering collaboration.
+
+## Definition
+VMC on AWS provides a middle ground for organizations not ready for a full native cloud migration. It allows vSphere workloads to move back and forth between on-premises and AWS cloud environments in seconds.
+
+## Key Characteristics
+- **Native Hypervisor**: VMware vSphere 8 runs natively on AWS hardware (i3.metal / i3en.metal)
+- **Joint Engineering**: Not a simple software deployment — VMware and Amazon engineers the service together
+- **Same Toolset**: Organizations use the same vSphere tools they use on-premises
+- **AWS Service Integration**: Native access to AWS services with low latency
+- **On-Demand Scalability**: Scale resources up or down as needed
+- **HCX Migration**: Hybrid Cloud Extension enables any-to-any vSphere workload migration
+- **27% Cost Savings**: Compared to using regular cloud compute services
+
+## Use Cases
+- Next-generation application development
+- Cloud migration
+- Virtual desktops (VDI)
+- Disaster recovery
+
+## Infrastructure
+- **Server Hosts**: i3.metal and i3en.metal bare metal servers
+- **Organization**: Clusters within availability zones and regions
+- **Stretched Clusters**: Cross-AZ clusters for increased resilience
+- **Management**: vCenter (same as on-premises)
+
+## Cost Model
+- VMware sells an entire host (enabling over-provisioning and cost reduction)
+- Cloud economics team can perform TCO (Total Cost of Ownership) calculations
+- Compare costs with on-premises or other hyperscalers
+
+## Connections
+- [[VMware]] ← provides ← [[VMware-Cloud-on-AWS]]
+- [[AWS]] ← hosts ← [[VMware-Cloud-on-AWS]]
+- [[HCX]] ← enables ← [[VMware-Cloud-on-AWS]] migration
+- [[SDDC]] ← architecture ← [[VMware-Cloud-on-AWS]]
+- [[Stretched-Cluster]] ← extends ← [[VMware-Cloud-on-AWS]] resilience
+- [[Hybrid-Cloud]] ← implements ← [[VMware-Cloud-on-AWS]]
+
+## Sources
+- [[ctp-topic-43-vmware-cloud-on-aws]]
--- a/wiki/entities/AWS.md
+++ b/wiki/entities/AWS.md
@@ -1,44 +1,34 @@
 ---
-title: AWS (Amazon Web Services)
-tags: [Cloud, Provider, Public-Cloud]
+title: "Amazon Web Services (AWS)"
+type: entity
+tags:
+  - AWS
+  - Cloud
+  - Hybrid-Cloud
+last_updated: 2026-04-25
 ---

-# AWS (Amazon Web Services)
+## Amazon Web Services (AWS)

-**AWS** is Amazon's cloud computing platform, providing a broad set of infrastructure and application services across 200+ fully featured services.
+Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally.

-## Overview
+## Aliases
+- AWS
+- Amazon Web Services

-AWS is one of the three major public cloud providers (alongside Azure and Google Cloud), offering the most extensive range of services.
+## Key Partnerships
+- **VMware Cloud on AWS (VMC on AWS)**: AWS partnered with VMware to run VMware workloads natively on AWS infrastructure. The underlying hardware consists of i3.metal and i3en.metal bare metal servers, organized into clusters within availability zones and regions.

-## Key Services Referenced
+## Infrastructure for VMC on AWS
+- **i3.metal**: Bare metal server instance used for VMware Cloud on AWS SDDC deployment
+- **i3en.metal**: Enhanced bare metal instance with larger storage capacity
+- **Clusters**: Organized within availability zones and regions globally
+- **Stretched Clusters**: Available across availability zones for increased resilience

-| Category | Services |
-|---------|----------|
-| Compute | EC2, Lambda |
-| Storage | S3, EBS |
-| Database | RDS, DynamoDB, Aurora |
-| AI/ML | SageMaker, Bedrock |
-| Analytics | Redshift, Athena |
-| Networking | VPC, Route 53, CloudFront |
-| IaC & Deployment | CloudFormation, **CloudFormation StackSets** |
-| Observability | **EventBridge**, **CloudWatch Logs**, CloudWatch Logs Insights, CloudWatch Alarms |
-| Security & Identity | **KMS**, IAM, CloudTrail, Security Hub |
-| Organization | **AWS Organizations** |
-
-## Multi-Cloud Context
-
-AWS is commonly used alongside Azure and Google Cloud in multi-cloud strategies:
- **General infrastructure** — Often primary compute and storage provider
- **Enterprise integration** — Strong Active Directory and enterprise app ecosystem
- **Market position** — Largest market share among cloud providers
-
-## Related Concepts
-
- [[Multi-Cloud-Strategy]] — AWS as one of multiple providers
- [[Cloud-Native]] — Building on AWS-native services
- [[FinOps]] — Managing AWS costs
+## Connections
+- [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]]
+- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]]
+- [[VMware]] ← partners ← [[AWS]]

 ## Sources
-
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
+- [[ctp-topic-43-vmware-cloud-on-aws]]
--- a/wiki/entities/Brendan-Starnig.md
+++ b/wiki/entities/Brendan-Starnig.md
@@ -0,0 +1,26 @@
+---
+title: "Brendan Starnig"
+type: entity
+tags: [SRE, Platform-Engineering, Change-Management]
+last_updated: 2026-04-14
+---
+
+## Overview
+
+Brendan Starnig is the SRE Function Lead in the Platform Engineering team. He is the primary presenter of CTP Topic 30 on Managing Change, which covers change management processes and SRE team collaboration patterns in cloud transformation projects.
+
+## Role
+
+- **Title**: SRE Function Lead, Platform Engineering
+- **Team**: Site Reliability Engineering (SRE)
+- **Topics**: Change Management, SRE Practices, Cloud Transformation
+
+## Key Contributions
+
+- Developed and presented the change management framework covering Standard Change, Normal Change, and Emergency Change
+- Defined SRE team collaboration model across three phases: Build / Early Live Support / BAU
+- Proposed Self-Healing automation initiative with product teams
+
+## Sources
+
+- [[ctp-topic-30-managing-change]]
--- a/wiki/entities/Heather-Norris.md
+++ b/wiki/entities/Heather-Norris.md
@@ -0,0 +1,22 @@
+---
+title: "Heather Norris"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## 基本信息
+- **角色：** 云转型计划（Cloud Transformation Programme）项目经理
+- **演讲主题：** 在云转型项目中应用敏捷方法论（CTP Topic 4）
+
+## 主要观点
+- 倡导 Scrum 向 Kanban 的框架演进，以适应云转型项目的高变化频率
+- 强调敏捷的核心价值是快速反馈循环，持续改进产品和开发文化
+- 推动 Microsoft Planner 作为团队统一的看板工具
+
+## 参与项目
+- Cloud Transformation Programme (CTP)
+
+## 来源
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
--- a/wiki/entities/Microsoft-Planner.md
+++ b/wiki/entities/Microsoft-Planner.md
@@ -0,0 +1,31 @@
+---
+title: "Microsoft Planner"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## 基本信息
+- **类型：** 项目管理工具 / 看板平台
+- **厂商：** Microsoft
+- **产品定位：** Microsoft 365 套件中的轻量级任务和项目可视化工具
+
+## 主要用途
+- 云转型计划（CTP）团队的统一任务管理平台
+- 支持 Kanban 结构的看板管理
+
+## 看板结构（CTP 场景）
+- **列：** Backlog → To Do → In Progress → Program Key Decisions → Icebox
+- **最佳实践：**
+  - 每张任务卡必须指定单一负责人，即使多人协作
+  - 明确角色定义（如 oversight）
+  - 链接依赖关系卡
+  - 设置优先级和截止日期
+  - 优先级、日期、负责人、进度变更须通过卡片评论沟通
+
+## 来源
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
+
+## 别名
+- Microsoft Planner Board
--- a/wiki/entities/SMACs.md
+++ b/wiki/entities/SMACs.md
@@ -0,0 +1,42 @@
+---
+title: "SMACs"
+type: entity
+tags: [ITSM, Service-Management, Change-Management, Incident-Management]
+last_updated: 2026-04-14
+---
+
+## Overview
+
+SMACs (Service Management Automation X) is the current ITSM (IT Service Management) tool used within the organization for managing Tickets, Incidents, Changes, and related service workflows. It replaces the legacy semantic messaging gateway for email and serves as the unified platform for IT service operations.
+
+## Full Name
+
+Service Management Automation X (formerly Micro Focus Operations Manager i / SMACKS)
+
+## Key Functions
+
+|| Function | Description |
+|---------|-------------|
+| Ticket Management | Create, track, and resolve IT service requests |
+| Incident Management | Handle low-level events that trigger alerts vs. major incidents |
+| Change Management | Manage Standard/Normal/Emergency change workflows |
+| Problem Management | Track root causes and CAPA/Post-mortem actions |
+
+## Relationship with Change Management
+
+In the change management framework (CTP Topic 30), SMACs is used to:
+- Log and track Change Records (CR)
+- Route Normal Changes to CAB for approval
+- Execute Emergency Changes with post-incident documentation
+- Link Changes to related Incidents for audit trail
+
+## Related Concepts
+
+- [[Standard-Change]]：预批准变更，在 SMACs 中可实现完全自动化审批
+- [[Normal-Change]]：需 CAB 审批，在 SMACs 中通过变更窗口管理
+- [[Emergency-Change]]：立即执行，在 SMACs 中事后通过 CAPA 补齐文档
+- [[CAPA]]：Corrective and Preventive Action，在 SMACs 中作为 Post-mortem 流程落地
+
+## Sources
+
+- [[ctp-topic-30-managing-change]]
--- a/wiki/entities/SRE-Team.md
+++ b/wiki/entities/SRE-Team.md
@@ -13,10 +13,11 @@ SRE Team（Site Reliability Engineering 团队）是该组织中负责 AWS Landi

 | 职责 | 说明 |
 |------|------|
-| 运维自动化 | 开发自动化工具减少人工重复操作 |
+| 运维自动化 | 开发自动化工具减少人工重复操作，通过 IaC + CI/CD 实现 Standard Change |
 | 工具开发 | 构建内部平台工具（如 Tag Validation Tool） |
-| 可靠性保障 | 确保 AWS 基础设施的高可用性和可观测性 |
+| 可靠性保障 | 确保 AWS 基础设施的高可用性和可观测性，定义 SLO/SLR 体系 |
 | 内部平台 | 维护 SRE Tools Repository 内部代码仓库 |
+| SRE 三阶段支持 | Build（构建）/Early Live Support（早期上线支持）/BAU（日常运维）三个阶段与产品团队协作 |

 ## SRE Tools Repository

@@ -37,3 +38,4 @@ SRE 团队维护的内部代码仓库（[[SRE-Tools-Repository]]），集中存
 ## Sources

 - [[ctp-topic-28-aws-tag-validation-tool]]
+- [[ctp-topic-30-managing-change]]
--- a/wiki/entities/SankarGopov.md
+++ b/wiki/entities/SankarGopov.md
@@ -0,0 +1,28 @@
+---
+title: "Sankar Gopov"
+type: entity
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## Sankar Gopov
+
+AWS 网络与混合云架构专家，Cloud Transformation Programme (CTP) 的核心讲师之一。
+
+## Role
+
+- **CTP Topic 19**：AWS Landing Zone DNS 配置专题讲师
+- **CTP Topic 22**：Global DNS Service Offerings 讲师（与 Vino 联合主讲）
+
+## Areas of Expertise
+
+- AWS Landing Zone 多账号架构设计
+- Route 53 混合 DNS 架构（Inbound/Outbound Endpoints）
+- 企业级 DNS 服务架构（Infoblox + Route 53）
+- 跨账号 VPC 网络互联
+
+## Connections
+
+- 通过 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 讲解 Landing Zone 内部 DNS 配置
+- 通过 [[ctp-topic-22-global-dns-service-offerings]] 讲解企业级全局 DNS 架构
--- a/wiki/entities/VMware.md
+++ b/wiki/entities/VMware.md
@@ -0,0 +1,40 @@
+---
+title: "VMware"
+type: entity
+tags:
+  - VMware
+  - Virtualization
+  - Hybrid-Cloud
+last_updated: 2026-04-25
+---
+
+## VMware
+
+Enterprise virtualization and cloud computing software provider. Headquartered in Palo Alto, California, VMware is known for its vSphere hypervisor and vCenter management platform.
+
+## Aliases
+- VMware, Inc.
+- VMware Cloud
+
+## Overview
+VMware partnered with AWS to develop **VMware Cloud on AWS (VMC on AWS)**, a jointly engineered cloud service where the VMware hypervisor runs natively on AWS bare metal servers (i3.metal / i3en.metal). This is not a simple deployment of VMware software onto cloud infrastructure — it is a true joint engineering effort between VMware and AWS.
+
+## Key Offerings
+- **vSphere**: Enterprise virtualization platform
+- **vCenter**: Centralized management for vSphere environments
+- **HCX (Hybrid Cloud Extension)**: Enables any-to-any vSphere workload migration between on-premises and cloud
+- **VMC on AWS**: VMware Cloud on AWS jointly engineered with Amazon Web Services
+
+## Key People
+- Brian Reeves — VMware speaker, discussed VMC on AWS economics (27% cost savings vs. regular cloud)
+- Michael Riley — VMware speaker
+- Mike Armstrong — VMware speaker
+- Mike O'Reilly — Staff Cloud Solutions Architect at VMware, explained VMC on AWS technical architecture
+
+## Connections
+- [[VMware-Cloud-on-AWS]] ← provides ← [[AWS]] infrastructure partnership
+- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[VMware]]
+- [[ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]] ← related_to ← [[VMware]]
+
+## Sources
+- [[ctp-topic-43-vmware-cloud-on-aws]]
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,21 @@
 - [Overview](overview.md) — living synthesis

 ## Sources
+- [2026-04-23] [CTP Topic 20 Program demand process flow and PoC onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md)
+- [2026-04-23] [CTP Topic 4 Using Agile to Run the Cloud Transformation Programme](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md)
+- [2026-04-23] [CTP Topic 65 Tracing the Value Delivered in Cloud Transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md)
+- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723](sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md)
+- [2026-04-23] [CTP Topic 30 Managing Change](sources/ctp-topic-30-managing-change.md)
+- [2026-04-23] [CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS](sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md)
+- [2026-04-23] [CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones](sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md)
+- [2026-04-23] [CTP Topic 18 Wide Area Networking in AWS Cloud](sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md)
+- [2026-04-23] [CTP Topic 43 VMware Cloud on AWS](sources/ctp-topic-43-vmware-cloud-on-aws.md)
+- [2026-04-23] [CTP Topic 61 Workload VPC provision with IPAM Automation](sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md)
+- [2026-04-23] [CTP Topic 45 Automatic IP address allocation with IPAM](sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md)
+- [2026-04-23] [CTP Topic 19 Configuring DNS within AWS LZs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md)
+- [2026-04-23] [CTP Topic 36 SendGrid as an Email Service](sources/ctp-topic-36-sendgrid-as-an-email-service.md)
+- [2026-04-23] [CTP Topic 22 Global DNS service offerings](sources/ctp-topic-22-global-dns-service-offerings.md)
+- [2026-04-23] [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md)
 - [2026-04-23] [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md)
 - [2026-04-23] [CTP Topic 26 Standard AMI – build, publish, share processes](sources/ctp-topic-26-standard-ami-build-publish-share-processes.md)
 - [2026-04-23] [CTP Topic 68 Introduction to Redshift](sources/ctp-topic-68-introduction-to-redshift.md)
@@ -13,7 +28,7 @@
 - [2026-04-23] [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md)
 - [2026-04-23] [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md)
 - [2026-04-23] [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md)
- [2026-04-23] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md)
+- [2026-04-14] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md)
 - [2026-04-23] [CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme](sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md)
 - [2026-04-23] [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md)
 - [2026-04-23] [CTP Topic 47 Enterprise Architecture Cloud Standards](sources/ctp-topic-47-enterprise-architecture-cloud-standards.md)
@@ -398,22 +413,6 @@
 - [2026-04-19] [public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20](sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md — source missing)
 - [2026-04-19] [public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md — source missing)
 - [2026-04-19] [ctp-topic-41-nfrs-and-error-budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md) — (expected: wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md — source missing)
- [2026-04-19] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md)
- [2026-04-19] [ctp-topic-20-program-demand-process-flow-and-poc-onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md) — (expected: wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md — source missing)
- [2026-04-19] [ctp-topic-4-using-agile-to-run-the-cloud-transformation-program](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md) — (expected: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md — source missing)
- [2026-04-19] [ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md) — (expected: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md — source missing)
- [2026-04-19] [public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2](sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md — source missing)
- [2026-04-19] [ctp-topic-30-managing-change](sources/ctp-topic-30-managing-change.md) — (expected: wiki/sources/ctp-topic-30-managing-change.md — source missing)
- [2026-04-19] [ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm](sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md) — (expected: wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md — source missing)
- [2026-04-19] [ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones](sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md) — (expected: wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md — source missing)
- [2026-04-19] [ctp-topic-18-wide-area-networking-in-aws-cloud](sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md) — (expected: wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md — source missing)
- [2026-04-19] [ctp-topic-43-vmware-cloud-on-aws](sources/ctp-topic-43-vmware-cloud-on-aws.md) — (expected: wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md — source missing)
- [2026-04-19] [ctp-topic-61-workload-vpc-provision-with-ipam-automation](sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md) — (expected: wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md — source missing)
- [2026-04-19] [ctp-topic-45-automatic-ip-address-allocation-with-ipam](sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md) — (expected: wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md — source missing)
- [2026-04-19] [ctp-topic-19-configuring-dns-within-aws-lzs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md) — (expected: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md — source missing)
- [2026-04-19] [ctp-topic-36-sendgrid-as-an-email-service](sources/ctp-topic-36-sendgrid-as-an-email-service.md) — (expected: wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md — source missing)
- [2026-04-18] [ctp-topic-22-global-dns-service-offerings](sources/ctp-topic-22-global-dns-service-offerings.md) — (expected: wiki/sources/ctp-topic-22-global-dns-service-offerings.md — source missing)
- [2026-04-14] [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) — CCOE AMI 路线图与 AWS 标准 AMI 生命周期规划
 - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
 - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
 - [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
@@ -568,6 +567,7 @@
 - [blackbox-exporter](entities/blackbox-exporter.md)
 - [BMC](entities/BMC.md)
 - [bottom](entities/bottom.md)
+- [Brendan-Starnig](entities/Brendan-Starnig.md)
 - [btop++](entities/btop++.md)
 - [Caddy](entities/Caddy.md)
 - [cAdvisor](entities/cAdvisor.md)
@@ -623,6 +623,7 @@
 - [GoogleCloud](entities/GoogleCloud.md)
 - [Grafana](entities/Grafana.md)
 - [Gruntwork](entities/Gruntwork.md)
+- [Heather-Norris](entities/Heather-Norris.md)
 - [hello-world](entities/hello-world.md)
 - [HemantSawant](entities/HemantSawant.md)
 - [HIPAA](entities/HIPAA.md)
@@ -654,6 +655,7 @@
 - [Mem0](entities/Mem0.md)
 - [Memsearch](entities/Memsearch.md)
 - [MerlinClash插件](entities/MerlinClash插件.md)
+- [Microsoft-Planner](entities/Microsoft-Planner.md)
 - [Midjourney](entities/Midjourney.md)
 - [Milvus](entities/Milvus.md)
 - [MinIO](entities/MinIO.md)
@@ -700,10 +702,12 @@
 - [rsync](entities/rsync.md)
 - [Rufus](entities/Rufus.md)
 - [RustDesk](entities/RustDesk.md)
+- [SankarGopov](entities/SankarGopov.md)
 - [shenwei](entities/shenwei.md)
 - [Simon-Hoiberg](entities/Simon-Hoiberg.md)
 - [Slack](entities/Slack.md)
 - [SMACKS](entities/SMACKS.md)
+- [SMACs](entities/SMACs.md)
 - [SONY](entities/SONY.md)
 - [SparkryAI](entities/SparkryAI.md)
 - [SRE-Team](entities/SRE-Team.md)
@@ -727,6 +731,7 @@
 - [Veeam](entities/Veeam.md)
 - [Vibe-Kanban](entities/Vibe-Kanban.md)
 - [VictoriaMetrics](entities/VictoriaMetrics.md)
+- [VMware](entities/VMware.md)
 - [WildCard](entities/WildCard.md)
 - [YishenTu](entities/YishenTu.md)
 - [Zipline](entities/Zipline.md)
@@ -755,6 +760,7 @@
 - [Agent-Routing-Rules](concepts/Agent-Routing-Rules.md)
 - [Agent-Specialization](concepts/Agent-Specialization.md)
 - [AGENTS.md](concepts/AGENTS.md.md)
+- [Agile-Ceremonies](concepts/Agile-Ceremonies.md)
 - [AgilePractices](concepts/AgilePractices.md)
 - [AI-Agent](concepts/AI-Agent.md)
 - [AI-Auto-Response](concepts/AI-Auto-Response.md)
@@ -799,6 +805,7 @@
 - [Call-Worthy-Threshold](concepts/Call-Worthy-Threshold.md)
 - [Canary-Release](concepts/Canary-Release.md)
 - [Canvas](concepts/Canvas.md)
+- [CAPA](concepts/CAPA.md)
 - [Centralized-Logging](concepts/Centralized-Logging.md)
 - [CEOPattern](concepts/CEOPattern.md)
 - [Chained Agents](concepts/Chained Agents.md)
@@ -837,6 +844,7 @@
 - [Content-Ingestion](concepts/Content-Ingestion.md)
 - [Context-Substrate](concepts/Context-Substrate.md)
 - [Context-Window](concepts/Context-Window.md)
+- [Continuous-Delivery](concepts/Continuous-Delivery.md)
 - [Continuous-Deployment](concepts/Continuous-Deployment.md)
 - [Continuous-Integration](concepts/Continuous-Integration.md)
 - [Conversational-Interface](concepts/Conversational-Interface.md)
@@ -875,11 +883,13 @@
 - [DRY原则](concepts/DRY原则.md)
 - [DuckDB](concepts/DuckDB.md)
 - [Dynamic-Dashboard](concepts/Dynamic-Dashboard.md)
+- [Early-Live-Support](concepts/Early-Live-Support.md)
 - [Earnings-Beat-Miss](concepts/Earnings-Beat-Miss.md)
 - [Earnings-Calendar](concepts/Earnings-Calendar.md)
 - [efibootmgr](concepts/efibootmgr.md)
 - [EFS-vs-EBS](concepts/EFS-vs-EBS.md)
 - [Email-Triage](concepts/Email-Triage.md)
+- [Emergency-Change](concepts/Emergency-Change.md)
 - [Error-Accountability](concepts/Error-Accountability.md)
 - [Error-Budget](concepts/Error-Budget.md)
 - [Error-Surface-vs-Root-Cause](concepts/Error-Surface-vs-Root-Cause.md)
@@ -911,6 +921,7 @@
 - [GitOps](concepts/GitOps.md)
 - [GPG-密钥验证](concepts/GPG-密钥验证.md)
 - [Green-Computing](concepts/Green-Computing.md)
+- [HCX](concepts/HCX.md)
 - [Headless-服务器](concepts/Headless-服务器.md)
 - [Heartbeat-Monitoring](concepts/Heartbeat-Monitoring.md)
 - [Hidden-Failure-Paths](concepts/Hidden-Failure-Paths.md)
@@ -921,6 +932,7 @@
 - [Human-Handoff](concepts/Human-Handoff.md)
 - [Hybrid-Cloud](concepts/Hybrid-Cloud.md)
 - [Hybrid-Search](concepts/Hybrid-Search.md)
+- [HybridDnsResolution](concepts/HybridDnsResolution.md)
 - [Hyperautomation](concepts/Hyperautomation.md)
 - [IAST](concepts/IAST.md)
 - [Idea-Density](concepts/Idea-Density.md)
@@ -939,6 +951,7 @@
 - [ITSM](concepts/ITSM.md)
 - [ITSM-2.0](concepts/ITSM-2.0.md)
 - [JFFS双清](concepts/JFFS双清.md)
+- [Kanban](concepts/Kanban.md)
 - [Keyword-Based-Monitoring](concepts/Keyword-Based-Monitoring.md)
 - [Kill-Switch](concepts/Kill-Switch.md)
 - [Knock-out-Pattern](concepts/Knock-out-Pattern.md)
@@ -982,6 +995,7 @@
 - [Multi-Tenancy](concepts/Multi-Tenancy.md)
 - [nas套件管理](concepts/nas套件管理.md)
 - [NFS网络备份](concepts/NFS网络备份.md)
+- [Normal-Change](concepts/Normal-Change.md)
 - [NVMe硬盘分区](concepts/NVMe硬盘分区.md)
 - [Obsidian-Agent-Client](concepts/Obsidian-Agent-Client.md)
 - [Obsidian-Bases](concepts/Obsidian-Bases.md)
@@ -1053,6 +1067,8 @@
 - [Scheduled-Reminder](concepts/Scheduled-Reminder.md)
 - [Scheduled-Task-Flywheel](concepts/Scheduled-Task-Flywheel.md)
 - [Scholar-Skill](concepts/Scholar-Skill.md)
+- [Scrum](concepts/Scrum.md)
+- [SDDC](concepts/SDDC.md)
 - [Second-Renaissance](concepts/Second-Renaissance.md)
 - [Security-and-Compliance](concepts/Security-and-Compliance.md)
 - [Self-Education](concepts/Self-Education.md)
@@ -1083,8 +1099,10 @@
 - [Split](concepts/Split.md)
 - [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md)
 - [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md)
+- [Standard-Change](concepts/Standard-Change.md)
 - [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md)
 - [Streak-Tracking](concepts/Streak-Tracking.md)
+- [Stretched-Cluster](concepts/Stretched-Cluster.md)
 - [StudyVault](concepts/StudyVault.md)
 - [Sub-Agent-Race-Condition](concepts/Sub-Agent-Race-Condition.md)
 - [symbolic-link](concepts/symbolic-link.md)
@@ -1126,6 +1144,7 @@
 - [Vibe-Coding](concepts/Vibe-Coding.md)
 - [Visual-Debugging](concepts/Visual-Debugging.md)
 - [vLLM](concepts/vLLM.md)
+- [VMware-Cloud-on-AWS](concepts/VMware-Cloud-on-AWS.md)
 - [Voice-Interface](concepts/Voice-Interface.md)
 - [Voice-Notification-Channel](concepts/Voice-Notification-Channel.md)
 - [Vulnerability-Scanning](concepts/Vulnerability-Scanning.md)
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,3 +1,191 @@
+## [2026-04-27] ingest | CTP Topic 20 Program demand process flow and PoC onboarding
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
+- Status: ✅ 成功摄入
+- Summary: 云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：需求来源（业务案例/战略优先级/产品路线图）、Gate Process 三阶段审批（Gate 0/1/3）、POC 目的（验证架构可行性+熟悉 Gruntwork Landing Zone）、新环境强调 IaC（Terraform/Terragrunt）自动化、PCG 团队职责、成功标准前置定义。
+- Concepts identified: Program-Demand-Process, Proof-of-Concept, Gate-Process, Solution-Design
+- Entities identified: Sergio, Damian, PCG-Team, Gruntwork, Terraform, Terragrunt
+- Source page: wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
+- Notes:
+  - 新增 1 个 Source Page
+  - 4 个 Concepts 以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
+  - 6 个 Entities 以 wikilink 形式建立关联，暂不创建独立页面（Sergio/Damian/PCG-Team 各仅出现 1 次；Gruntwork/Terraform/Terragrunt 已存在于 wiki/）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
+  - overview.md 更新：新增 CTP Topic 20 摘要段落（置于 ctp-topic-65 之后，ctp-topic-47 之前）；Key Concepts 列表新增 4 个概念（Program-Demand-Process/Proof-of-Concept/Gate-Process/Solution-Design）
+  - 冲突检测：与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 存在流程视角差异——Topic 4 强调 Kanban 持续流动允许随时调整优先级，Topic 20 强调 Gate Process 阶段性审批节点。两者非逻辑矛盾，而是适用场景不同（敏捷迭代 vs 迁移治理），已记录于 Source Page Contradictions 节
+
+## [2026-04-24] ingest | CTP Topic 4 Using Agile to Run the Cloud Transformation Programme
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
+- Status: ✅ 成功摄入
+- Summary: 云转型计划中敏捷实践落地经验——从 Scrum（两周 Sprint）因"Sprint 期间不允许变更"转向 Kanban 持续流动，采用混合框架（Kanban 为主 + 保留 Scrum 仪式）。Microsoft Planner 看板五列布局，最佳实践：单一负责人、依赖链接、优先级和截止日期。核心价值观：快速反馈驱动产品和开发文化持续改进。
+- Entities created: Heather-Norris, Microsoft-Planner
+- Concepts created: Scrum, Kanban, Agile-Ceremonies, Continuous-Delivery
+- Source page: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
+- Notes: 与 CTP Topic 30 (变更管理) 和 Topic 57 (需求管理) 共同构成项目管理知识体系
+
+## [2026-04-26] ingest | CTP Topic 65 Tracing the Value Delivered in Cloud Transformation
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
+- Status: ✅ 成功摄入
+- Summary: 云转型价值交付量化框架——涵盖 Process/Value/Value-Stream 基础概念、Lean 三类活动识别、收益四维度量化（财务/生产力/质量/体验）、WSJF 优先级排序（Cost of Delay / Size of Job）、功能级价值拆解方法。核心理念："以最小投入尽早交付最大价值"。
+- Concepts identified: Process, Value, Value-Stream, Value-Adding, Waste, Benefits-Quantification, Cost-of-Delay, WSJF, SOM, Feature-Level-Value-Breakdown
+- Entities identified: CTP（Cloud Transformation Programme），Scaled-Agile（WSJF 来源框架）
+- Source page: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
+
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md）
+  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
+  - overview.md 更新：新增 CTP Topic 65 摘要段落（置于 ctp-topic-30 之后，ctp-topic-47 之前）；Key Concepts 列表新增 10 个概念
+  - 冲突检测：与 [[ctp-topic-53-why-bother-with-cloud]] 存在视角张力——Topic 53 质疑迁移必要性，Topic 65 假设迁移已决策并聚焦如何量化交付价值。两者互补而非逻辑矛盾——前者回答"是否迁移"，后者回答"如何衡量价值"。已记录于 Source Page Contradictions 节。
+
+
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change.md
+- Status: ✅ 成功摄入
+- Summary: 云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性；②变更分类——Standard Change（预批准，完全自动化）→ Normal Change（需 CAB 审批）→ Emergency Change（立即执行，事后 CAPA）；③SRE 三阶段协作——Build/Early Live Support/BAU；④Self-Healing 演进方向。
+- Concepts created: Standard-Change, Normal-Change, Emergency-Change, CAPA, Early-Live-Support
+- Entities created: Brendan-Starnig, SMACs
+- Source page: wiki/sources/ctp-topic-30-managing-change.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-30-managing-change.md）
+  - 新增 2 个 Entity 页面（Brendan-Starnig.md, SMACs.md）
+  - 新增 5 个 Concept 页面（Standard-Change.md, Normal-Change.md, Emergency-Change.md, CAPA.md, Early-Live-Support.md）
+  - 更新现有 Entity：SRE-Team.md（添加三阶段支持职责和 Topic 30 来源）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
+  - overview.md 更新：新增 CTP Topic 30 摘要段落
+  - 冲突检测：与 [[ctp-topic-53-why-bother-with-cloud]] 的观点张力——Topic 30 假设迁移决策已做出，聚焦执行层面变更管理；Topic 53 质疑迁移必要性。已记录于 Source Page Contradictions 节。
+
+## [2026-04-25] ingest | CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md
+- Status: ✅ 成功摄入
+- Summary: VMC on AWS 虚拟机迁移最佳实践——HCX 多云管理（每次迭代最多 200 台 VM）、UI 和 CCOE 脚本两种迁移方案、Direct Connect + Virtual Transit Gateway 混合云连接、预/后迁移自动化、Brown to Manage 系统集成 SMACS + HCMX 实现后迁移管理。
+- Concepts created: Direct Connect, Virtual Transit Gateway, BGP, EC2-Bare-Metal, CCOE, SMACS Suite, HCMX
+- Source page: wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md）
+  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
+  - overview.md 更新：新增 CTP Topic 69 摘要段落（置于 ctp-topic-43 之后），补充 HCX 和迁移执行层面的详细信息
+  - 冲突检测：与 [[ctp-topic-43-vmware-cloud-on-aws]] 互补而非冲突——Topic 43 提供 VMC on AWS 概述，Topic 69 提供迁移执行细节，已记录于 Source Page Contradictions 节
+
+## [2026-04-24] ingest | Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
+- Status: ✅ 成功摄入
+- Summary: OpenText DR 向 Recovery Assurance 演进框架——Jim Rose 主讲，涵盖 CrowdStrike 事件警示、RTO/RPO 合同差异、DR 测试瓶颈（被动/手动/按客户时间表）、多云复杂性（AWS/GCP/Azure）、混合架构挑战，以及 Design/Software/Build/Environments 四位框架转型路径。SRE + 可观测性工程是核心驱动力。
+- Concepts identified: RTO, RPO, SRE, Observability-Engineering, Disaster-Recovery, Business-Continuity-Plan, Self-Healing, Customer-Zero-Environment
+- Entities identified: OpenText, Jim-Rose, CrowdStrike
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
+- Notes:
+  - 新增 1 个 Source Page
+  - Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
+  - index.md 更新：插入至 Sources 顶部，日期 2026-04-24
+  - overview.md 更新：无需更新（已有 ctp-topic-72 覆盖 DR 核心内容，本视频内容已通过 Connections 节与相关 Topic 建立关联）
+  - 冲突检测：无冲突——与现有 Wiki DR 内容互补，记录于 Source Page Contradictions 节
+
+## [2026-04-25] ingest | CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md
+- Status: ✅ 成功摄入
+- Summary: AWS Landing Zone 网络隔离与安全远程访问方案。核心：①网络隔离——Checkpoint 防火墙 SPI default-deny 阻断内部网络直连 AWS；②安全访问——AWS SSM 替代 VPN，IAM 角色假设 + SSM Agent 实现浏览器/CLI 远程访问。定位为 SD-WAN 实施前过渡方案；长期目标 IaC 化消除控制台访问。与 Topic 18 互补（打通 vs 限制）。
+- Concepts created: (已存在: SD-WAN, AWS-Landing-Zone, Network-Segregation, AWS-Systems-Manager-SSM, SPI-Security-Policy-Infrastructure; 新增 wikilinks 于 source page)
+- Entities created: (已存在: Checkpoint)
+- Source page: wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md
+- Notes:
+  - 新增 1 个 Source Page
+  - 冲突记录：与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 的视角张力——Topic 18 关注打通网络，Topic 31 关注限制网络；已记录于 source page Contradictions 章节
+
+## [2026-04-25] ingest | CTP Topic 18 Wide Area Networking in AWS Cloud
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md
+- Status: ✅ 成功摄入
+- Summary: AWS Transit Gateway 全球广域网架构与 SD-WAN 演进路径——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub，Landing Zones 通过 TGW Peering 以星型拓扑接入 Hub，区域 Hub 之间全网状互联。现状依赖静态路由缺乏 BGP，DR 需人工干预。未来演进：引入 Silver Peak SD-WAN 实现动态路径选择，Pulse VPN 迁移至 Prisma Access (SASE) 实现就近接入。
+- Concepts created: AWS-Transit-Gateway, Hub-and-Spoke, SD-WAN, Overlay-Network, Static-Routing, Prisma-Access, TGW-Peering
+- Entities created: (已存在: Micro Focus, AWS, Christian Deckelman, Silver Peak, Palo Alto Networks)
+- Source page: wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md）
+  - 新增 7 个 Concept 页面
+  - index.md 更新：Sources 节新增条目（日期 2026-04-14）
+  - overview.md 更新：新增 Topic 18 的完整段落
+  - 冲突检测：无已知冲突
+
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md
+- Status: ✅ 成功摄入
+- Summary: VMware Cloud on AWS（VMC on AWS）混合云服务介绍——VMware与AWS联合开发，在AWS裸金属服务器（i3.metal/i3en.metal）上原生安装vSphere 8。工作负载可在数秒内往返迁移于本地与云端之间，通过HCX实现any-to-any vSphere迁移。相比常规云方案节省27%成本，云经济学团队可提供TCO计算。
+- Concepts created: VMware-Cloud-on-AWS, HCX, SDDC, Stretched-Cluster, Hybrid-Cloud
+- Entities created: VMware, AWS
+- Source page: wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md）
+  - 新增 2 个 Entity 页面（VMware.md, AWS.md）
+  - 新增 4 个 Concept 页面（VMware-Cloud-on-AWS.md, HCX.md, SDDC.md, Stretched-Cluster.md）
+  - index.md 更新：Sources 节新增条目（日期 2026-04-25，置顶于所有条目最前）；Entities 节新增 VMware 和 AWS；Concepts 节新增 4 个概念
+  - overview.md 更新：新增 Topic 43 的完整段落；Key Concepts 新增 VMware-Cloud-on-AWS、VMware、HCX、SDDC、Stretched-Cluster、Hybrid-Cloud
+  - 冲突检测：与 ctp-topic-53-why-bother-with-cloud 存在是否应迁移至云端的观点张力，已在 source page 中记录为 Contradictions
+
+## [2026-04-24] ingest | CTP Topic 61 Workload VPC provision with IPAM Automation
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md
+- Status: ✅ 成功摄入
+- Summary:
+- Concepts created: VPC-自动化供给, CIDR-审批流程, Availability-Zone-ID
+- Source page: wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md）
+  - index.md 更新：Sources 节新增条目（日期 2026-04-24，置顶于所有条目最前）；移除原有的 source missing 条目
+  - overview.md 更新：新增 Topic 45 和 Topic 61 的完整段落，描述 IPAM 的"机制 → 应用"完整链路；Key Concepts 新增 [[VPC-自动化供给]] 和 [[CIDR-审批流程]]
+  - 冲突检测：无已知冲突内容
+  - IPAM（IP Address Management）和 Infoblox Grid 概念已在 overview.md Key Concepts 中，无需单独 Concept 页面
+
+## [2026-04-24] ingest | CTP Topic 45 Automatic IP address allocation with IPAM
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
+- Status: ✅ 成功摄入
+- Summary: 使用 Infoblox NIOS IPAM 实现 AWS VPC 自动化 IP 地址分配的架构实践。核心内容：①传统方式（手工请求→网络团队计算CIDR→电子表格→手工配置YAML）效率低下；②Infoblox NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；③新 YAML 配置仅声明期望子网大小和区域父 CIDR，不含硬编码 IP；④销毁 VPC 时自动从 IPAM Grid 清除条目，支持撤销保护；⑤向后兼容旧配置。目标：创建 VPC 无需网络团队参与，建立单一可信数据源。
+- Concepts created: IPAM（IP Address Management），Infoblox-NIOS，VPC-自动化供给
+- Source page: wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md）
+  - index.md 更新：将原有的 source missing 条目替换为正式条目（日期 2026-04-24）
+  - IPAM 关键概念在 source page 内已有详细说明，无需单独 Concept 页面
+  - 冲突检测：无已知冲突内容
+
+## [2026-04-24] ingest | CTP Topic 19 Configuring DNS within AWS LZs
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md
+- Status: ✅ 成功摄入
+- Summary: AWS Landing Zone 多账号环境中的集中化 DNS 配置架构——Sankar Gopov 主讲。核心内容：①设立专用 DNS 账号集中管理所有私有托管区（优于分散管理）；②Route 53 Resolver Inbound/Outbound Endpoints 打通混合 DNS（Inbound 接收本地请求，Outbound 转发 AWS 请求至本地）；③AWS RAM 跨账号共享 Resolver Rules；④跨账号 VPC 关联必须先授权（Authorization）再关联（Association）；⑤Terraform 自动化实现新账号上线即具备完整解析能力。
+- Concepts created: Hybrid DNS Resolution, Route 53 Resolver Rules, VPC Association Authorization, Terraform DNS Automation
+- Entities created: Sankar Gopov
+- Source page: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md）
+  - 新增 1 个 Entity 页面（wiki/entities/SankarGopov.md）
+  - 新增 1 个 Concept 页面（wiki/concepts/HybridDnsResolution.md）
+  - index.md 更新：Sources 节新增条目（日期 2026-04-24，置顶于所有条目最前）
+  - overview.md 更新：更新 CTP Topic 22 段落，移除"（待摄入）"标注，补全两条 DNS 视频的知识体系关系描述
+  - 冲突检测：与 [[ctp-topic-22-global-dns-service-offerings]] 存在潜在视角差异——DNS 账号是否应包含公共托管区；前者侧重落地配置，后者侧重服务提供架构；两者的冲突是视角互补而非逻辑矛盾
+
+## [2026-04-26] ingest | CTP Topic 36 SendGrid as an Email Service
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md
+- Status: ✅ 成功摄入
+- Summary: SendGrid 被选定为 CTP 标准邮件服务，替换 Port 25 不安全的语义消息网关和每封限制 50 收件人的 SES。SendGrid 支持每封最多 1,000 收件人、TLS 端到端加密、双因素认证；两种架构（直连 vs 中继）；配置要求 software.microcopy.com 域名、smtp.sendgrid.net:587、TLS；SPF/DKIM 必要；API 密钥 180 天轮换；日志 7 天保留。同期更新了 Cyber Suite 加密标准（FIPS/Java/Golang/Node.js/OpenCell 等），可选套件因含 CBC 弱加密仅作向后兼容。
+- Concepts created: SPF, DKIM, TLS, API-Key-Rotation, Cyber-Suite, CBC-Mode
+- Entities touched: SendGrid, Twilio, Rejoy Ganapati, Rajiv, Yu-Yan, PSAC
+- Source page: wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md）
+  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
+  - index.md 更新：Sources 节新增条目（日期 2026-04-14，置顶于 CTP Topic 34 之后）
+  - overview.md 更新：新增 CTP Topic 36 摘要段落（置于 ctp-topic-22 之后，ctp-topic-17 之前）；Key Concepts 列表新增 8 个概念（SPF/DKIM/TLS/API-Key-Rotation/Cyber-Suite/CBC-Mode/SendGrid/Twilio）
+  - 冲突检测：与 [[ctp-topic-12-using-ses-smtp-service-terraform-module]] 存在冲突——SES 作为标准邮件服务 vs SendGrid 被选定为新标准；SES 适合 AWS 原生集成场景，SendGrid 为大规模需求首选
+
+
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md
+- Status: ✅ 成功摄入
+- Summary: 企业级全球 DNS 服务架构详解——Sankar 和 Vino 主讲。核心架构：Route 53 Private Hosted Zone + AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络 DNS 查询；Outbound Endpoint 配置多区域 AD 域控制器 IP 实现故障自动切换；Infoblox Anycast 提供本地 DNS 全球低延迟和高可用；AWS EC2 不支持 Anycast；DNS 安全涵盖防隧道攻击、缓存污染等；就近解析优化 Office 365 访问
+- Concepts touched: Hybrid DNS Resolution、Route 53 Private Hosted Zone、Route 53 Resolver、DNS Anycast、Infoblox Grid、IPAM（IP Address Management）、Active Directory DNS、Landing Zone
+- Entities touched: AWS、Infoblox、Microsoft Active Directory、Office 365、Sankar、Vino
+- Source page: wiki/sources/ctp-topic-22-global-dns-service-offerings.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-22-global-dns-service-offerings.md）
+  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
+  - index.md 更新：Sources 节替换预期占位符为正式条目（日期修正为 2026-04-14）
+  - overview.md 更新：新增 CTP Topic 22 摘要段落（置于 ctp-topic-14 之后，ctp-topic-17 之前）；Key Concepts 列表新增 7 个 DNS 相关概念
+  - 冲突检测：ctp-topic-19（configuring DNS within AWS LZs）尚未摄入，无法进行完整对比；source page Contradictions 节已记录，待 ctp-topic-19 摄入后补充对比
+
 ## [2026-04-26] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs
 - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md
 - Status: ✅ 成功摄入
--- a/wiki/overview.md
+++ b/wiki/overview.md
@@ -41,8 +41,14 @@ Key concepts: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Refer
 ### Cloud Transformation & DevOps
 Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps.

+**[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]**（CTP Topic 4）：云转型计划中敏捷实践的落地经验——Heather Norris 主讲。核心内容：①框架演进——从 Scrum（两周 Sprint，含 Product Backlog/Sprint Planning/Retrospectives/Reviews/Daily Scrum）因"Sprint 期间不允许变更"的问题而转向 Kanban 持续流动模式；②混合方案——以 Kanban 为主（随时可调整优先级、持续交付），同时保留 Scrum 的固定仪式（每日站会和回顾会议）；③Microsoft Planner 看板——五列布局（Backlog/To Do/In Progress/Program Key Decisions/Icebox），每张卡必须指定单一负责人、链接依赖、设置优先级和截止日期；④核心价值观——"Agile is all about getting that rapid feedback to make the product and make the development culture better"。属 [[Agile Ceremonies]] 和 [[Scrum]] vs [[Kanban]] 在企业级云迁移场景下的实战案例，与 [[ctp-topic-57-product-backlog-managing-demand]]（需求管理）和 [[ctp-topic-30-managing-change]]（变更管理）共同构成 CTP 项目管理知识体系。
+
+**[[ctp-topic-18-wide-area-networking-in-aws-cloud]]**（CTP Topic 18）：AWS 广域网架构设计——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub（如 EMEA 伦敦、AMS 俄勒冈），所有 Landing Zones 通过 TGW Peering 以星型拓扑接入区域 Hub，区域 Hub 之间全网状互联。现阶段 TGW 间路由依赖静态前缀列表，缺乏 BGP 动态路由，DR 场景需人工干预。演进路线：引入 Silver Peak SD-WAN 作为叠加网络实现动态路径选择；Pulse VPN 迁移至 Palo Alto Prisma Access (SASE) 实现就近接入并打通 SD-WAN 骨干。属 [[AWS-Transit-Gateway]] 架构实践，与 [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]（Labs LZ 网络）和 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]（网络分段）共同构成 Landing Zone 网络知识体系。
+
 **[[ctp-topic-25-labs-landing-zone-overview-itom-teams]]**（CTP Topic 25）：Labs Landing Zone 运维团队视角——Labs LZ 基于 Gruntwork 参考架构，采用多账户策略，全部资源通过 Terraform/Terragrunt 管理（Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply）；核心账户包括：Shared（托管 Jenkins 主节点和加固 AMI）、Logs（CloudTrail/Config 日志集中存储）、Security（联邦用户和跨账户访问）、Core（AD 管理 Windows 实例和 IDP、DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙管理所有互联网流量，Pulse VPN 提供 Micro Focus 网络访问）、Shared Services（45 Arc Site 监控、Qualys 漏洞扫描）。Product Account 通过 Terraform 模块部署 subnet，需与网络团队协调 IP 范围和标签策略，防火墙通过标签自动配置网络访问策略。属 [[AWS-Landing-Zone]] Labs 视角的运维实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系。

+**[[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]**（CTP Topic 31）：AWS Landing Zone 网络隔离与安全远程访问方案——解决 On-prem 系统和 VPN 用户因共享网络配置而可直接访问生产工作负载的安全风险。核心方案：①网络隔离通过 Checkpoint 防火墙启用 SPI 特性（default-deny），阻断内部网络对 AWS 网段的直接连通；②安全访问通过 AWS Systems Manager (SSM) 替代 VPN，用户假设 IAM 角色访问目标 EC2 实例上的 SSM Agent，支持浏览器会话和 AWS CLI 两种模式，提供双因素认证和 AWS 网络内安全连接。定位为 SD-WAN 实施前的过渡方案；长期演进目标为 IaC 化以消除控制台访问，break-glass 访问仅保留用于紧急场景。与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]]（广域网架构）互补——后者关注如何打通网络，Topic 31 关注如何限制网络访问；两者共同构成 Landing Zone 网络知识体系。属 [[AWS-Landing-Zone]] 网络安全层的核心实践。
+
 **[[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]**（CTP Topic 35）：AWS Landing Zone 设计复习——重点明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS Landing Zone 为每个产品区域提供客户专属环境，产品账户连接至共享服务账户（安全、日志、网络）；核心账户组包含 AD、DNS 和 Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断对 SaaS 工作负载的直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一审计；入站流量拟通过 Network 账户 Checkpoint 重新路由；原生 AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：**SaaS = 生产，Labs = 开发**；PoC Landing Zone 将并入 Labs 以最大化资源共享；Cloud Technology Design Forum 推动 Micro Focus 云交付标准化。

 **[[ctp-topic-7-saas-landing-zone-design]]**（CTP Topic 7）：SAS 生产 Landing Zone 顶层架构设计——定义了完整的四层账户体系：①核心账户（Core Accounts）：Shared 托管 AMI + 主 Jenkins 服务器通过 Lambda 触发各账户 Jenkins slave；Logs 集中管理所有账户日志（CloudTrail/Config/Flowlogs）；Security 托管 IAM 角色。②基线账户（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 监控入站流量。自动化部署链路：GitHub 仓库变更 → Jenkins（GitHub Hook 触发）→ Management VPC → Lambda → ECS Cluster，Staging 测试后才部署生产。远程访问从 Checkpoint VPN 迁移至 Pulse VPN（通过 AD 认证）。属 [[AWS-Landing-Zone]] 的原始设计规范，与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（近期变更）共同构成 SAS LZ 的设计演进脉络。
@@ -55,12 +61,20 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter

 **[[ctp-topic-26-standard-ami-build-publish-share-processes]]**（CTP Topic 26）：Foundation AMI 全生命周期管理详解——Srihari、Alan 和 Praveen 三位专家主讲。Foundation AMI 基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + SSM Agent + SiteScope 监控；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化；通过跨账号共享（AMI Sharing）分发至全球多区域（俄勒冈/法兰克福/悉尼），而非物理复制（AMI Copying），避免额外存储成本；每两个月更新，采用 N-2 版本保留策略。责任共担模型：CCOE 提供安全基础镜像，产品团队在其上构建产品特定 AMI。属 [[AWS-Landing-Zone]] AMI 层的核心基础，与 [[ctp-topic-58-aws-ec2-image-builder]]（演进方向 EC2 Image Builder）和 [[learning-sessions-standard-amis-updates]]（2023年更新机制）共同构成完整的 AMI 管理知识体系。

-**CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging]]）：AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容：①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性；②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化；③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性，转向利用 AWS 标签作为安全凭证；④**SCP 强制执行标签规范**——通过"显式拒绝"逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制。属 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展，与 [[ctp-topic-28-aws-tag-validation-tool]]（标签审计）共同构成标签治理闭环。
+**CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]）：AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容：①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性；②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化；③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性，转向利用 AWS 标签作为安全凭证；④**SCP 强制执行标签规范**——通过「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制；⑥Inline 层基于账号号的父子规则架构，简化跨账户策略管理。与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展，与 [[ctp-topic-28-aws-tag-validation-tool]]（标签审计）共同构成标签治理闭环。

-Key concepts: [[Landing Zone Architecture]], [[GitOps]], [[FinOps]], [[Event Sourcing]], [[Container Lifecycle Hardening]], [[AWS Backup]], [[ITSM]], [[ITSM-2.0]], [[Hyperautomation]], [[AIOps]], [[Self-Healing-Systems]], [[Zero-Trust-Architecture]], [[Policy-as-Code]], [[Immutable-Infrastructure]], [[Foundation AMI]], [[OS Hardening]], [[CIS Benchmarks]], [[AMI Sharing]], [[Central Repository]], [[Error Budgets]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], **[[Serverless Computing]]**, **[[Edge Computing]]**, **[[Green Computing]]**, [[Data-Warehouse]], [[MPP]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[SLA]], [[SLO]], [[Incident Management]], [[Change Management]], **[[Disaster Recovery]]**, **[[AWS Backup]]**（CTP Topic 44：AWS Backup 托管服务 vs Micro Focus 当前分散式快照管理，四级 DR 策略——Backup and Restore / Pilot Light / Warm Standby / Active-Active；不可变性防勒索软件；法律保留满足合规；局限：无法选择性排除 EC2 附加卷，快照为崩溃一致而非热备份）、**[[高可用（High Availability）]]**（HA 关注系统运行时间，MTBF 为衡量指标；与 DR 互补——HA 保运行，DR 保数据；CTP Topic 72：Sabith 主讲 HA 与 DR 的本质区别）、**[[灾难恢复架构模式]]**（CTP Topic 72：Backup and Restore / Pilot Light / Warm Standby / Active-Active 四级递进，成本与弹性权衡）、**[[Vault Lock]]**（CTP Topic 72：合规模式下即使根用户也无法删除恢复点，防勒索软件核心机制）、**[[跨账户备份]]**（CTP Topic 72：AWS Organizations 集成，Bunker Account 隔离存储，Forensic Account 定期测试）、**[[增量备份]]** vs [[全量备份]]（CTP Topic 72：增量仅捕获变更，节省存储成本）、**[[AWS Backup Audit Manager]]**（BAM，CTP Topic 72：合规审计报告）、**[[AWS-Tagging-Standards]]**（CTP Topic 28：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略；与 Checkpoint 防火墙安全策略直接关联，标签缺失导致流量拦截）、**[[Tag-Validation-Tool]]**（CTP Topic 28：SRE 团队开发的 Python/Boto3 工具，通过 YAML 配置扫描 AWS 资源标签合规性）、**[[Service-Control-Policies-SCPs]]**（AWS Organizations 策略类型，用于阻止不合规资源创建）、**[[Variables-YAML]]**（Tag Validation Tool 核心配置文件，定义每个账户的合法标签键及允许值）、**[[Checkpoint-Firewall]]**（防火墙供应商，依赖 AWS 标签值配置网络访问策略）、**[[SRE-Tools-Repository]]**（内部代码仓库，存放 Tag Validation Tool 等 SRE 自动化脚本）：[[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]]
+**[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**（CTP Topic 45）：Infoblox NIOS IPAM 自动分配 AWS VPC IP 地址——通过 YAML 配置文件声明期望子网大小和区域父 CIDR，NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；销毁 VPC 时自动从 IPAM Grid 清除条目；建立单一可信数据源，消除手工电子表格记录。属 [[IPAM（IP Address Management）]] 的机制层详解。
+
+**[[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]**（CTP Topic 61）：Workload VPC 完整自动化供给方案——Pushka（Principal SRE）主讲，在 Topic 45 的 IPAM 自动分配机制基础上，展示了端到端 VPC 供给流程。核心增强：多 VPC 批量供给支持、邮件通知机制、CIDR /22 阈值自动审批（更大 CIDR 自动，更小需理由审批）、非路由 IP 地址（如 10.2.0.0/16）支持、使用 AZ ID 避免跨账号不一致。Infoblox Grid 作为全局唯一 IP 地址数据源防止重叠，架构包含休斯顿数据中心主库及冗余 DNS/NTP/DHCP 服务。核心理念：**"只需把信息放到正确位置，一切自动完成。"** 属 [[IPAM（IP Address Management）]] 的应用层扩展，与 [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] 共同构成 IPAM 的"机制 → 应用"完整链路。
+
+Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Waste]], [[Benefits-Quantification]], [[Cost-of-Delay]], [[WSJF]], [[SOM]], [[Feature-Level-Value-Breakdown]], [[Program-Demand-Process]], [[Proof-of-Concept]], [[Gate-Process]], [[Solution-Design]], [[Landing Zone Architecture]], [[Hybrid DNS Resolution]], [[VMware-Cloud-on-AWS]], [[VMware]], [[HCX]], [[SDDC]], [[Stretched-Cluster]], [[Hybrid-Cloud]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], [[Serverless Computing]], [[Edge Computing]], [[Green Computing]], [[Data-Warehouse]], [[MPP]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[SLA]], [[SLO]], [[Incident Management]], [[Change Management]], [[Disaster Recovery]], [[AWS Backup]], [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[跨账户备份]], [[增量备份]], [[SPF]], [[DKIM]], [[TLS]], [[API-Key-Rotation]], [[Cyber-Suite]], [[CBC-Mode]], [[SendGrid]], [[Twilio]] vs [[全量备份]]（CTP Topic 72：增量仅捕获变更，节省存储成本）、**[[AWS Backup Audit Manager]]**（BAM，CTP Topic 72：合规审计报告）、**[[AWS-Tagging-Standards]]**（CTP Topic 28：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略；与 Checkpoint 防火墙安全策略直接关联，标签缺失导致流量拦截）、**[[Tag-Validation-Tool]]**（CTP Topic 28：SRE 团队开发的 Python/Boto3 工具，通过 YAML 配置扫描 AWS 资源标签合规性）、**[[Service-Control-Policies-SCPs]]**（AWS Organizations 策略类型，通过「显式拒绝」逻辑强制执行标签规范）、**[[OU-Layered-Security]]**（通过组织单元分层结构检查标签确保正确归属）、**[[Tag-Based-Security]]**（将资源标签作为安全凭证替代传统 IP 规则）、**[[Checkpoint-Firewall]]**（防火墙供应商，依赖 AWS 标签值配置网络访问策略）、**[[Variables-YAML]]**（Tag Validation Tool 核心配置文件，定义每个账户的合法标签键及允许值）、**[[SRE-Tools-Repository]]**（内部代码仓库，存放 Tag Validation Tool 等 SRE 自动化脚本）：[[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]]

 **[[ctp-topic-40-saas-database-architecture]]**（CTP Topic 40）：SAS 数据库团队在 AWS 云上的架构与运维实践——团队分布于美国/加拿大/印度/以色列，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移。属 [[AWS-Landing-Zone]] 数据库层的核心实践，与 [[ctp-topic-51-purpose-built-databases]]（数据库品类全景）和 [[ctp-topic-66-rds-vs-aurora]]（关系型选型）共同构成完整的 AWS 数据库知识体系。

+**[[ctp-topic-43-vmware-cloud-on-aws]]**（CTP Topic 43）：VMware Cloud on AWS 混合云服务介绍——VMware 与 AWS 联合开发，在 AWS 裸金属服务器（i3.metal/i3en.metal）上原生安装 vSphere 8，为不完全准备完全迁移至原生云的企业提供中间路线。工作负载可在数秒内往返迁移于本地与云端之间，通过 HCX 实现 any-to-any vSphere 迁移。Brian Reeves 讨论经济学效益：相比常规云方案节省 27% 成本，云经济学团队可提供 TCO 计算。Mike O'Reilly（VMware Staff Cloud Solutions Architect）强调这是真正的联合工程而非简单地将 VMware 软件部署到云端。支持 SDDC 部署，通过 vCenter 管理，支持跨可用区的 Stretched Cluster 高可用架构。属 [[Hybrid-Cloud]] 在 AWS 落地的核心实践，与 [[ctp-topic-53-why-bother-with-cloud]] 存在是否应迁移至云端的观点张力。
+
+**[[ctp-topic-69-vmware-vm-migration-best-practices]]**（CTP Topic 69）：VMC on AWS 虚拟机迁移最佳实践——基于 VMware 顾问支持的经验分享。核心内容：①架构——VMware Cloud 托管于 AWS 基础设施，通过 Direct Connect 和 Virtual Transit Gateway 实现与本地数据中心的混合云连接；②HCX 多云管理——每次迭代最多支持 200 台 VM 迁移，支持从 STDC 查看本地 vSphere 环境和反向操作；③两种迁移方法——UI 方式（VMware Cloud 原生）和 CCOE 脚本方案（使用输入文件定义 VM 详情）；④成本原则——"Anything which leaves definitely attracts cost"，数据传输产生费用；⑤后迁移管理——通过 Brown to Manage (BHM) 系统集成 SMACS Suite 和 HCMX 实现虚拟机管理。属 [[VMware-Cloud-on-AWS]] 迁移执行层面的核心补充，与 [[ctp-topic-43-vmware-cloud-on-aws]] 互补构成完整的"概述→迁移执行"知识链路。
+
 **[[ctp-topic-46-netapps-on-aws]]**（CTP Topic 46）：NetApp 存储系统 AWS 实践——Sandeep 和 Yael 主讲。覆盖传统 NetApp 架构（ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM）和 AWS 云版本 Cloud Volume ONTAP (CVO)。CVO 通过 EC2 实例提供软件定义存储，支持单节点或 HA 配对（跨多 AZ 同步复制）；数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3；SnapMirror 实现块级跨集群复制；支持的迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据，使用 Cloud Manager 集中管理，计划引入 FSX for NetApp（POC）和 Terraform 自动化部署。属 [[AWS-Landing-Zone]] 存储层架构的核心补充。

 **[[ctp-topic-51-purpose-built-databases]]**（CTP Topic 51）：AWS 数据库专家 Femi George 分享专用数据库选型与架构原则——核心思维：现代应用"为正确的工作选择正确的专用数据库"，避免一刀切。AWS 提供完整数据库品类：关系型（RDS、Aurora MySQL/PostgreSQL）、NoSQL 键值（ DynamoDB，日处理万亿请求）、文档（DocumentDB，MongoDB 兼容）、宽列（Keyspaces，Cassandra 兼容）、内存（ElastiCache Redis/Memcached）、图（Neptune）、时序（Timestream）、账本。实战案例：Duolingo 用 DynamoDB + ElastiCache + Aurora 组合；Netflix 用 DynamoDB 做高弹性 JSON 文档；Peloton 用 ElastiCache Redis 提供即时客户反馈。云时代 DBA 职能从底层平台管理转向应用创新（查询优化/架构设计）。属 [[AWS-Landing-Zone]] 数据库层的完整品类指南，与 [[ctp-topic-66-rds-vs-aurora]]（关系型内部选型）互补。
@@ -71,10 +85,20 @@ Key concepts: [[Landing Zone Architecture]], [[GitOps]], [[FinOps]], [[Event Sou

 **[[ctp-topic-14-octane-hub-on-aws]]**（CTP Topic 14）：Octane Hub CTO 实战案例——Docker 容器化工作负载从 Bibling Lab 物理服务器迁移到 AWS Landing Zone。核心技术要点：Packer 构建 AMI + Terraform/TerraGrunt 替代控制台脚本（IaC 演进路径）；EFS 适合备份、EBS 适合实时数据库（存储选型原则）；VPC Transit Gateway 实现多 VPC 互联；"紧密镜像现有设置"作为无缝迁移策略。下一步：DR 改进、MSSQL→Postgres 迁移、ECS 演进。属 [[AWS-Landing-Zone]] 从设计到落地的完整案例补充。

+**[[ctp-topic-22-global-dns-service-offerings]]**（CTP Topic 22）：企业级全球 DNS 服务架构详解——Sankar 和 Vino 主讲。核心架构：Route 53 Private Hosted Zone（私有托管区域）配合 AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络的 DNS 查询；Outbound Endpoint 出站规则配置多个区域 AD 域控制器 IP，单区域故障时自动切换确保弹性。本地 Infoblox 平台利用 DNS Anycast 实现全球低延迟和自动故障转移；AWS EC2 不支持 Anycast，需手动维护 IP 列表。DNS 安全涵盖防隧道攻击、防数据外泄及缓存污染；"就近解析"原则优化 Office 365 等全球化 SaaS 访问性能。属 [[AWS-Landing-Zone]] 网络层 DNS 专题，与 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 共同构成 Landing Zone DNS 知识体系——后者（前文）介绍 Route 53 Resolver Inbound/Outbound Endpoints 打通混合 DNS 架构，本视频（后者）聚焦 Landing Zone 内部集中化 DNS 账号的配置实践，Terraform 自动化实现新账号上线即具备完整解析能力。
+
+**[[ctp-topic-36-sendgrid-as-an-email-service]]**（CTP Topic 36）：SendGrid 被选定为经典和新 Landing Zone 的标准邮件服务，替换现有语义消息网关（Port 25 不安全、即将停用本地网络）和 SES（每封限制 50 收件人）。SendGrid 支持每封最多 1,000 收件人、全云兼容、TLS 端到端加密和双因素认证；支持计划覆盖每月 500 万封邮件；提供直连 SendGrid（需 TLS）和中继服务器（不支持 TLS 的应用）两种架构，数据通过全球中继节点（伦敦/印度/东京）走私有线路汇至美国数据中心。配置要求：使用 software.microcopy.com 域名、连接 smtp.sendgrid.net:587、启用 TLS；SPF/DKIM 记录为邮件送达必要条件；API 密钥每 180 天轮换，日志保留 7 天。同期 Yu-Yan 分享了 Cyber Suite 加密标准更新，涵盖 FIPS/Java/Golang/Node.js/OpenCell 等行业标准合规模件，可选套件因包含 CBC 模式（弱加密）仅作向后兼容，使用非标准套件的产品需经 PSAC 审查。属 [[AWS-Landing-Zone]] 通信层基础组件，与 [[ctp-topic-37-secrets-certificates-management]] 同属安全运维范畴。
+
 **[[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]**（CTP Topic 17）：Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成——双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell/Shell 脚本，通过 Terraform `user_data` 实现自动化域加入；旧域名 `infra` 和 `AST` 已废弃，提供明确迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。属 [[AWS-Landing-Zone]] AD 集成的核心实践参考。

 **[[ctp-topic-28-aws-tag-validation-tool]]**（CTP Topic 28）：AWS 标签验证工具——Lewis Brown 主讲，SRE 团队开发的 Python/Boto3 工具。Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略，标签缺失或无效将导致流量被拦截；SCPs 可阻止不合规资源创建但无法修复存量资源。该工具通过 `variables.yaml` 定义每个账户的合法标签值，自动扫描 EC2/安全组/负载均衡器/Lambda，生成 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签策略还计划用于未来成本核算，区分同一账户下不同产品的资源消耗。属 [[AWS-Landing-Zone]] 标签治理闭环的核心补充——制定规范（Topic 10）→ 强制执行（SCPs）→ 审计发现（Topic 28）。

+**[[ctp-topic-30-managing-change]]**（CTP Topic 30）：云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒；②变更分类——Standard Change（预批准，完全自动化 IaC+CI/CD，无需 CAB）→ Normal Change（需 CAB 审批，目标是通过自动化逐步归入 Standard Change）→ Emergency Change（立即执行缓解事故，事后 CAPA/Post-mortem 修复根因）；③SRE 三阶段协作——构建（Build）/早期上线支持（Early Live Support）/BAU；④Self-Healing 演进方向——各产品组分享实践，SRE 协助在监控产品中落地。属 [[AWS-Landing-Zone]] 运维治理层的核心补充，与 [[ctp-topic-28-aws-tag-validation-tool]]（IaC 变更的 Tagging 标准属于 Standard Change 范畴）共同构成变更管理知识体系。
+
+**[[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]**（CTP Topic 65）：云转型中的价值交付量化框架——提供系统性衡量、捕获和优先排序云转型业务价值的方法论。核心内容：①基础概念——过程（Process）将输入转化为产出/成果，成果分硬性（时间/成本/质量）和软性（健康/安全）；Lean 识别三类活动：增值活动、价值赋能活动、浪费；价值（Value）由客户决定，体现为公平回报；②价值流（Value Stream）分为运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）；③收益量化框架——涵盖财务、生产力、质量和体验四个维度，聚焦收入增长、成本降低、风险改善和服务可获得市场规模（SOM）；④WSJF 优先级排序——通过 Cost of Delay / Size of Job 比值对工作排序，实现"最小投入尽早交付最大价值"；延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会；⑤功能级价值拆解——可按单一功能归属、均分或不均匀分配（基于触达/影响/努力等标准）。属 [[AWS-Landing-Zone]] 价值治理层的核心方法论，与 [[ctp-topic-30-managing-change]]（变更管理）和 [[ctp-topic-20-program-demand-process-flow]]（需求流程）共同构成完整的 CTP 治理知识体系。
+
+**[[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]**（CTP Topic 20）：云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：①需求来源——主要由业务案例（如数据中心关闭）、高层管理人员战略优先级及产品路线图驱动；②Gate Process——Gate 0 评估准入、Gate 1 负责 Design Authority 审批、Gate 3 作为启动迁移的最终准入；③POC 目的——不仅验证架构和技术可行性，还包括让团队熟悉基于 Gruntwork 的新一代 Landing Zone；④新环境特点——强调 IaC（Terraform/Terragrunt）自动化部署，严禁手动构建；⑤PCG 团队——平台控制组，负责提供云环境支持、安全策略制定及协助产品组进行 POC；⑥成功标准——POC 成功标准必须在启动前明确定义。属 CTP 治理知识体系入口，与 [[ctp-topic-65]]（价值量化）、[[ctp-topic-57]]（需求管理）、[[ctp-topic-30]]（变更管理）共同构成完整的治理框架链条。
+
 **[[ctp-topic-47-enterprise-architecture-cloud-standards]]**（CTP Topic 47）：Lindsay 分享企业架构云标准——核心概念：Landing Zone 框架聚焦安全、合规和可管理性，为云工作负载提供托管基础，包含账户结构（dev/stage/prod）、网络、安全、访问管理和遥测；账户结构与环境和角色对齐，通过零信任和最小权限原则定义访问控制；Terraform/Terragrunt 实现 IaC，促进标准化和可测试性；云防护栏文档捕获强制性要求和最佳实践，指导可扩展性、成本最小化和灵活性；功能分区将单体应用拆分为更小的独立模块或无服务器函数。强调需要应用团队的输入来完善防护栏并纳入实践经验。属 [[AWS-Landing-Zone]] 企业架构层的理论补充。

 **[[ctp-topic-72-enterprise-dr-strategy-aws-backup]]**（CTP Topic 72）：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计——核心内容：HA（高可用）关注系统运行时间和 MTBF，DR（灾难恢复）专注于防止数据丢失和系统恢复，两者互补；RPO（恢复点目标）定义可接受的最大数据丢失量，RTO（恢复时间目标）定义可接受的最大停机时间；AWS Backup 完全托管、基于策略，通过 Backup Plans 定义何时备份什么，Backup Vaults 存储恢复点，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）提供从低成本到高弹性的递进选择；增量备份仅捕获变更，节省成本；Vault Lock 合规模式防止任何人（包括根用户）提前删除恢复点，有效防勒索软件；建议使用独立的 Vault/Bunker Account 存储备份副本，取证账户（Forensic Account）定期测试恢复点并扫描恶意软件。属 [[AWS-Landing-Zone]] DR 与数据保护层的理论基础补充，与 [[ctp-topic-44-aws-backup-in-micro-focus]]（聚焦 Micro Focus 内部评估）和 [[ctp-topic-73-aws-backup-implementation]]（聚焦 CTP 迁移实施）构成完整的 AWS Backup 知识体系。
--- a/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
+++ b/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
@@ -2,56 +2,67 @@
 title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
 type: source
 tags:
-  - AWS
-  - Landing-Zone
-  - Tagging
-  - Security
-  - CTP
+  - aws
+  - landing-zone
+  - tagging
+  - security
+  - cloud-transformation
+  - 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]]
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/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 标签治理闭环（制定规范 → 强制执行 → 流量控制）提供了完整的端到端设计思路
+- 核心主题：AWS Landing Zone 部署过程中数据收集策略，以及基于资源标签的云原生安全架构
+- 问题域：企业云迁移过程中如何理解待上云资产、如何通过标签机制实现精细化的访问控制和安全策略
+- 方法/机制：
+  - **OU + SCP 分层治理**：通过组织单元（OU）和 Service Control Policies（SCP）强制执行标签规范
+  - **标签即凭证**：将 AWS 资源标签作为防火墙策略的动态匹配条件，替代传统基于 IP 的静态规则
+  - **Checkpoint 有序层防火墙**：按优先级执行地理屏蔽 → 类型检查 → BU 隔离 → 产品隔离 → 环境隔离 → 角色检查
+  - **Inline 层结构**：基于账号号的父子规则架构，简化跨账户策略管理
+- 结论/价值：从"IP 地址"到"标签"的策略范式转变，使动态云环境无需频繁更新防火墙规则；标签缺失或篡改会触发 SCP 拒绝策略，确保安全合规

 ## Key Claims（用中文描述）
- SRE 团队通过自动化脚本实现了 DNS 和 Transit Gateway 等基础服务的高度自动化，部署前必须先完成 BU 资产清单和数据敏感性评估
- 基于标签的安全控制机制替代传统基于 IP 的防火墙规则，Checkpoint 防火墙通过读取 AWS 标签动态配置网络访问策略
- SCP 的"显式拒绝"逻辑能够强制执行标签规范，防止用户通过篡改标签绕过安全审计
- Checkpoint 防火墙的有序层（Ordered Layer）按顺序执行地理屏蔽、BU 隔离、产品隔离、环境隔离（Dev vs Prod）等策略
+- 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 层检查账号号，简化规则管理并支持自动化

 ## Key Quotes
-> "在部署 Landing Zone 前，必须深入了解业务部门的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态。" — Steve Jarman，部署规划原则
-> "通过 SCP 的显式拒绝逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属（BU、产品、环境）。" — Pradeep，标签强制机制
+> "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，描述产品间隔离的默认安全策略

 ## 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 的防火墙规则，是云原生安全架构的核心转型方向
+- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略类型，通过「显式拒绝」逻辑强制执行标签规范，阻止不合规资源创建
+- [[Checkpoint-Firewall]]：防火墙供应商，依赖 AWS 标签值配置动态网络访问策略
+- [[AWS-Landing-Zone]]：AWS 云环境的最佳实践起点框架，定义账户结构、网络、安全和访问管理
+- [[Tag-Based-Security]]：将资源标签作为安全凭证，替代传统基于 IP 的防火墙规则
+- [[OU-Layered-Security]]：通过组织单元（OU）的分层结构检查标签，确保正确归属和访问控制

 ## Key Entities
- [[Steve-Jarman]]：CTP 系列讲师，主导本次 Landing Zone 部署规划与自动化策略分享
- [[Pradeep]]：CTP 系列讲师，演示基于标签的 SCP 强制执行机制与 Checkpoint 防火墙策略
- [[Checkpoint]]：防火墙供应商，依赖 AWS 标签值配置网络访问策略的有序层（Ordered Layer）
- SRE-Team：站点可靠性工程团队，负责 Landing Zone 部署中的 DNS、Transit Gateway 等基础服务的自动化脚本编写
+- [[Steve-Jarman]]：CTP Topic 10 主讲人之一，阐述云迁移前的准备工作
+- [[Pradeep]]：CTP Topic 10 主讲人，演示 Checkpoint 防火墙配置和 EC2 部署示例
+- [[Checkpoint]]：防火墙供应商，负责基于标签的动态网络安全策略
+- [[AWS-Organizations]]：AWS 服务，提供 SCP 策略机制支持标签强制执行

 ## 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-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-47-enterprise-architecture-cloud-standards]] ← 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]]

 ## 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 补充了标签驱动的安全运营闭环
+- 与 [[ctp-topic-28-aws-tag-validation-tool]] 在标签治理覆盖范围上存在差异：
+  - 冲突点：SCPs 的标签强制能力边界
+  - 当前观点（Topic 10）：SCPs 通过「显式拒绝」阻止不合规资源创建，确保标签在资源创建时就正确
+  - 对方观点（Topic 28）：SCPs 可阻止不合规资源创建，但无法修复存量资源，存量合规性需通过 Tag Validation Tool 审计发现
+  - 协调说明：两者互补而非矛盾——SCP 负责预防（新资源准入控制），Tag Validation Tool 负责发现（存量资源合规审计）
--- a/wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md
+++ b/wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md
@@ -0,0 +1,59 @@
+---
+title: "CTP Topic 18 Wide Area Networking in AWS Cloud"
+type: source
+tags:
+  - AWS
+  - WAN
+  - Networking
+  - Transit Gateway
+  - SD-WAN
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 云环境中的广域网（WAN）架构设计与演进路径
+- 问题域：大型跨国企业如何通过 AWS Transit Gateway 构建跨区域全球网络连接，并规划向 SD-WAN 演进的路径
+- 方法/机制：通过 Transit Gateway (TGW) 星型拓扑（Hub-and-Spoke）连接全球 Landing Zones，区域 Hub 之间全网状互联；使用静态前缀列表路由；未来引入 Silver Peak SD-WAN 叠加网络和 Prisma Access SASE 远程访问
+- 结论/价值：为企业级云广域网提供了从传统静态路由到智能化 SD-WAN 的完整演进参考，涵盖连接性、容灾、远程访问三大维度的设计决策
+
+## Key Claims（用中文描述）
+- AWS Transit Gateway 作为区域级网络中转服务，可有效连接 VPCs、跨区域对等连接及 Landing Zones，形成星型拓扑
+- 现有 TGW 间路由依赖静态前缀列表，缺乏动态 BGP 协议支持，DR 场景需要人工干预切换路由
+- Silver Peak SD-WAN 作为叠加网络可实现动态路径选择和自动化流量调度，解决静态路由局限性
+- Pulse VPN 迁移至 Prisma Access (SASE) 可实现就近接入，显著降低访问延迟并直接打通 SD-WAN 骨干网
+
+## Key Quotes
+> "所有 Landing Zones 通过 TGW Peering 接入区域 Hub，形成星型拓扑（Hub-and-Spoke），各区域 Hub 之间则通过全网状（Full Mesh）连接，确保全球流量的可达性。" — 架构概述
+
+> "计划引入 Silver Peak 的 SD-WAN 方案作为叠加网络（Overlay）。通过在 AWS 中部署虚拟 SD-WAN 设备，实现动态路径选择和自动化流量调度，解决静态路由的局限性。" — 未来演进
+
+> "计划将传统的 Pulse VPN 迁移至 Palo Alto 的 Prisma Access（SASE 架构）。通过在全球部署更多的接入网关，让用户就近接入，显著降低访问延迟，并直接打通 SD-WAN 骨干网。" — 远程访问优化
+
+## Key Concepts
+- [[AWS Transit Gateway (TGW)]]：区域级网络中转服务，连接 VPC、本地网络及其他 Transit Gateway，充当云上路由器角色
+- [[Hub-and-Spoke]]：星型网络拓扑结构，所有分支（Spoke）连接到中心节点（Hub），分支间通信经过 Hub 中转
+- [[SD-WAN (Software-Defined WAN)]]：软件定义广域网，通过软件控制层对物理网络进行抽象，实现动态路径选择和负载均衡
+- [[Overlay Network]]：叠加网络，在现有物理网络（Underlay）之上构建的逻辑网络，用于实现复杂的路由和隧道功能
+- [[Static Routing]]：静态路由，手动配置的固定路由条目，在网络拓扑变化时无法自动更新
+- [[Prisma Access]]：Palo Alto Networks 提供的基于云的安全访问服务（SASE），用于替代传统 VPN
+- [[TGW Peering]]：在不同区域或同一区域的两个 Transit Gateway 之间建立的连接，用于跨网段流量传输
+
+## Key Entities
+- [[Christian Deckelman]]：Micro Focus IT 网络架构师，CTP Topic 18 讲师
+- [[AWS]]：Amazon Web Services，提供 Transit Gateway 等云网络服务
+- [[Silver Peak]]：SD-WAN 解决方案供应商，计划引入其 SD-WAN 方案作为叠加网络
+- [[Palo Alto Networks]]：网络安全公司，Prisma Access SASE 方案供应商
+- [[Micro Focus]]：Christian Deckelman 所在公司，AWS 云转型计划（CTP）的主导企业
+
+## Connections
+- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← depends_on ← [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
+- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
+- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] ← related_to ← [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← extends ← [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
+
+## Contradictions
+- 无已知冲突
--- a/wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
+++ b/wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
@@ -0,0 +1,57 @@
+---
+title: "CTP Topic 19 Configuring DNS within AWS LZs"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs]]
+
+## Summary（用中文描述）
+- 核心主题：在 AWS Landing Zone 多账号环境中配置集中化 DNS 管理架构
+- 问题域：跨账号、跨云与本地数据中心（On-prem）之间的域名解析难题
+- 方法/机制：设立专用 DNS 账号集中管理 Route 53 私有托管区，通过 Route 53 Resolver Inbound/Outbound Endpoints 打通 AWS 与本地 DNS，AWS RAM 跨账号共享解析规则，Terraform 实现自动化部署
+- 结论/价值：集中化 DNS 管理优于分散式，是多账号 AWS 环境的标准最佳实践
+
+## Key Claims（用中文描述）
+- 集中化 DNS 管理优于分散管理：应在 Landing Zone 中设立专门的 DNS 账号，而非在每个业务账号中分散创建私有托管区，便于统一维护路由规则和域名记录
+- Route 53 Resolver 是混合 DNS 架构的核心组件：Inbound Endpoints 接收来自本地数据中心的解析请求，Outbound Endpoints 将 AWS 内部请求转发至本地 DNS 服务器
+- AWS RAM 实现跨账号规则共享：通过 AWS Resource Access Manager 将 DNS 账号中定义的 Resolver Rules 共享给各个业务账号
+- 跨账号 VPC 与私有托管区关联必须先授权再关联：授权（Authorization）必须在关联（Association）之前完成
+- Terraform 是自动化部署 DNS 架构的核心工具：新业务 VPC 创建时自动完成规则共享与 VPC 关联，确保新账号上线即具备完整解析能力
+
+## Key Quotes
+> "我们推荐在 Landing Zone 中设立一个专门的 DNS 账号，所有私有托管区都集中在这里管理，而不是在每个业务账号中创建各自的托管区。" — Sankar Gopov，解释集中化 DNS 管理的优势
+> "Inbound Endpoints 用于接收来自本地数据中心的 DNS 查询请求；Outbound Endpoints 用于将 AWS 内部的 DNS 查询转发到本地 DNS 服务器。" — Sankar Gopov，Route 53 Resolver Endpoints 的双向作用
+> "跨账号关联时，必须先由托管区拥有者进行授权（Authorization），然后才能由 VPC 拥有者执行关联（Association）。" — Sankar Gopov，跨账号关联的必须步骤
+
+## Key Concepts
+- [[Route 53 Resolver]]：AWS Route 53 的 DNS 解析组件，通过 Inbound/Outbound Endpoints 实现混合云 DNS 架构
+- [[Private Hosted Zone]]：AWS Route 53 的私有托管区，用于在指定 VPC 内部解析自定义域名，不对互联网开放
+- [[Route 53 Resolver Rules]]：解析规则，定义特定域名的解析路径（如将某后缀的域名转发至本地数据中心）
+- [[VPC Association Authorization]]：跨账号关联流程，PHZ 拥有者先授权，VPC 拥有者再执行关联
+- [[AWS RAM]]：Resource Access Manager，用于在组织内跨账号共享 Resolver Rules 等资源
+- [[Hybrid DNS Resolution]]：混合 DNS 解析，AWS VPC 与本地数据中心之间的跨环境域名解析机制
+- [[Terraform DNS Automation]]：使用 Terraform 自动化部署 DNS 架构的实践
+
+## Key Entities
+- [[Sankar Gopov]]：本次视频讲师，AWS Landing Zone DNS 架构专家
+- [[AWS Landing Zone]]：AWS 多账号环境规范，是 DNS 架构的承载基础
+
+## Connections
+- [[ctp-topic-22-global-dns-service-offerings]] ← extends ← [[ctp-topic-19-configuring-dns-within-aws-lzs]]
+  - 两者同属 DNS 专题，后者（前文）讲企业级全局 DNS 服务架构（Infoblox + Route 53），后者（本文）聚焦 Landing Zone 内部的具体配置实施
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← depends_on ← [[ctp-topic-19-configuring-dns-within-aws-lzs]]
+  - Landing Zone 顶层设计包含 DNS 账户的规划
+- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← relates_to ← [[ctp-topic-19-configuring-dns-within-aws-lzs]]
+  - Labs LZ 中 Core 账户托管 DNS 服务（Swimford.net）
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← depends_on ← [[ctp-topic-19-configuring-dns-within-aws-lzs]]
+  - AD 服务依赖 DNS 完成域名解析，int-sas.local 等域名的解析由 DNS 架构提供
+
+## Contradictions
+- 与 [[ctp-topic-22-global-dns-service-offerings]] 潜在视角差异：
+  - 冲突点：DNS 账号是否应包含公共托管区（Public Hosted Zone）
+  - 当前观点（Topic 19）：DNS 账号专注于私有托管区和 Route 53 Resolver 管理
+  - 对方观点（Topic 22）：Route 53 还需管理公共域名解析（Route 53 Hosted Zone + Route 53 Resolver）
+  - 注：两者可能适用于不同的环境（Topic 22 侧重 DNS 服务提供者的全局架构，Topic 19 侧重 Landing Zone 内部的落地配置）
--- a/wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
+++ b/wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
@@ -0,0 +1,60 @@
+---
+title: "CTP Topic 20 Program demand process flow and PoC onboarding"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]
+
+## Summary（用中文描述）
+- 核心主题：云转型计划（CTP）的程序需求流程与概念验证（POC）入职流程
+- 问题域：企业级云迁移的治理框架、需求管理、POC 实施路径
+- 方法/机制：多阶段网关审批流程（Gate 0/1/3）、POC 验证框架、IaC（Terraform/Terragrunt）自动化部署、基于 Gruntwork Landing Zone 的新一代云环境
+- 结论/价值：POC 是降低迁移风险的核心手段；Landing Zone 需全部通过 IaC 自动化构建，严禁手动操作；Gate Process 确保治理严谨性
+
+## Key Claims（用中文描述）
+- CTP 需求主要由业务案例（数据中心关闭）、高层战略优先级和产品路线图驱动
+- POC 阶段必须完成解决方案设计并经过 Design Authority 审批
+- 新一代 Landing Zone 基于 Gruntwork 架构，强调 IaC（Terraform/Terragrunt），禁止手动构建
+- PCG 团队负责提供云环境支持、安全策略制定及协助产品组进行 POC
+- POC 成功标准必须在启动前明确定义
+
+## Key Quotes
+> "本次会议是云转型计划（Cloud Transformation Programme）系列学习课的一部分，由专家 Sergio 和 Damian 主讲，核心内容围绕'程序需求流程（Program Demand Process Flow）'以及'概念验证（POC）'的实施路径展开。" — 视频摘要开场
+
+## Key Concepts
+- [[Program-Demand-Process]]: 程序需求处理流程，指从业务需求产生、优先级排序到最终交付迁移的端到端管理路径
+- [[Proof-of-Concept]]: 概念验证，在正式迁移前用于证明架构可行性、测试复杂网络需求及验证迁移方法的实验性阶段
+- [[Landing-Zone]]: 落地分区，指云端预配置的、符合安全与合规标准的标准化基础架构环境
+- [[Infrastructure-as-Code]]: 基础设施即代码，通过脚本（如 Terraform）而非手动操作来定义和管理云资源
+- [[Gate-Process]]: 网关审批流程，用于治理项目进度的关键决策点，例如 Gate 0（评估准入）和 Gate 3（迁移准入）
+- [[Solution-Design]]: 解决方案设计，在 POC 阶段需完成并经过 Design Authority 审批的架构文档
+
+## Key Entities
+- [[Sergio]]: CTP 系列课程讲师，主讲程序需求流程
+- [[Damian]]: CTP 系列课程讲师，提及 Cloud Transformation Strategy Overview
+- [[PCG-Team]]: 平台控制组，负责提供云环境支持、安全策略制定及协助产品组进行 POC
+- [[Gruntwork]]: Landing Zone 参考架构提供商，其基础设施代码库支撑新一代云环境
+- [[Terraform]]: 核心 IaC 工具
+- [[Terragrunt]]: Terraform 的包装器，简化多环境管理
+
+## Connections
+- [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]] ← extends ← [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]
+  - Topic 65 提供价值量化框架，Topic 20 提供需求流程入口
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← depends_on ← [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]
+  - Topic 20 定义 PoC Landing Zone 并入 Labs，Topic 35 补充 SaaS vs Labs 职责划分
+- [[ctp-topic-57-product-backlog-managing-demand]] ← extends ← [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]
+  - Topic 57 深入需求管理层面，Topic 20 提供整体需求流程框架
+- [[ctp-topic-30-managing-change]] ← extends ← [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]
+  - 两者同属 CTP 治理知识体系，Topic 30 聚焦变更管理，Topic 20 聚焦需求入口
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← depends_on ← [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]
+  - Topic 1 提供 Gruntwork Landing Zone 架构基础，Topic 20 引用其作为目标环境
+
+## Contradictions
+- 与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 存在流程视角差异：
+  - 冲突点：Topic 4 强调 Kanban 持续流动模式允许随时调整优先级，Topic 20 强调 Gate Process 的阶段性审批节点
+  - 当前观点：CTP 采用固定 Gate 审批流程治理迁移决策，确保严谨性
+  - 对方观点：敏捷方法建议减少固定审批节点，通过持续反馈驱动决策
+  - 说明：两者非逻辑矛盾，而是适用场景不同——Gate Process 适用于大范围迁移决策，敏捷方法适用于迭代式产品开发
--- a/wiki/sources/ctp-topic-22-global-dns-service-offerings.md
+++ b/wiki/sources/ctp-topic-22-global-dns-service-offerings.md
@@ -0,0 +1,58 @@
+---
+title: "CTP Topic 22 Global DNS service offerings"
+type: source
+tags: [DNS, Networking, AWS, Hybrid-Cloud, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md]]
+
+## Summary（用中文描述）
+- 核心主题：企业级全球 DNS 服务架构设计，聚焦 AWS 云环境与 On-premises 数据中心之间的混合云 DNS 协作方案
+- 问题域：如何在多区域 AWS Landing Zone 与本地数据中心之间实现高可用、可弹性扩展的统一域名解析
+- 方法/机制：Route 53 Private Hosted Zone（私有托管区域）+ Route 53 Resolver 入站/出站终端节点实现跨 VPC 与本地网络的 DNS 查询转发；Infoblox Anycast 提供本地 DNS 的全球低延迟和自动故障转移；Route 53 Outbound Endpoint 配置多条 AD 域控制器 IP 实现故障时的自动切换
+- 结论/价值：混合云 DNS 架构必须兼顾安全（防 DNS 隧道/缓存污染）、性能（就近解析优化 Office 365 访问）和弹性（多路径故障转移）；AWS EC2 目前不支持 Anycast，需通过手动配置多 IP 实现冗余
+
+## Key Claims（用中文描述）
+- 企业云转型背景下，采用 Route 53 Private Hosted Zones 作为 AWS 端核心 DNS 服务，配合 AD 托管 DNS，可实现跨区域混合云的域名统一解析
+- Route 53 Resolver 的入站（Inbound）和出站（Outbound）终端节点是打通 AWS VPC 与本地网络 DNS 查询的关键机制
+- 通过在 Outbound Endpoint 出站规则中配置多个区域的 AD 域控制器 IP，可在单区域故障时自动切换到备用路径，确保 DNS 解析持续可用
+- 本地 Infoblox 平台利用 DNS Anycast 技术实现全球低延迟和自动故障转移，而 AWS EC2 基础架构目前不支持 Anycast
+- DNS 安全方案涵盖防 DNS 隧道攻击、防数据外泄及缓存污染等高级特性
+- "就近解析" 原则用于优化 Office 365 等全球化 SaaS 服务的访问性能
+
+## Key Quotes
+> "公司正在进行云转型计划，Landing Zone 架构中 DNS 是核心基础设施，必须能够同时服务云端和本地环境。" — Sankar & Vino，讲座背景说明
+> "AWS EC2 基础架构目前不支持 Anycast，因此需要手动维护 IP 列表来实现高可用冗余。" — 技术限制说明
+> "Route 53 Resolver Outbound Endpoint 的出站规则配置了多个区域的 AD 域控制器 IP，即使某个区域发生故障，DNS 解析仍能保持弹性。" — 弹性架构设计
+
+## Key Concepts
+- [[Route 53 Private Hosted Zone]]：AWS 提供的私有托管区域，仅对指定的 VPC 可见，用于管理内部网络域名
+- [[Route 53 Resolver]]：AWS VPC 内置 DNS 解析服务，通过入站/出站终端节点实现跨网络 DNS 查询转发
+- [[DNS Anycast]]：一种网络寻址和路由方法，使多个 DNS 服务器共享同一个 IP 地址，将请求路由至地理位置最近的节点
+- [[IPAM（IP Address Management）]]：IP 地址管理工具（如 Infoblox），用于规划、追踪和管理 IP 地址空间及 DNS/DHCP 服务
+- [[Landing Zone]]：一种预先配置好的多账号 AWS 环境，包含安全、网络和身份管理等基础设置
+- [[Hybrid DNS Resolution]]：混合云 DNS 解析，通过配置转发规则使云端资源能解析本地域名，本地资源也能解析云端域名
+- [[Infoblox Grid]]：一种分布式架构，通过 Grid Master 统一管理全球分布的 DNS/DHCP 器具，确保配置一致性和高可用性
+- [[Active Directory DNS]]：Windows AD 域环境中托管的 DNS 服务，是企业混合云 DNS 架构的核心组件
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，提供 Route 53、EC2、VPC 等 DNS 和计算服务
+- [[Infoblox]]：企业级 DNS/DHCP/IPAM 解决方案提供商，其 Grid 架构支持 Anycast
+- [[Sankar]]：CTP Topic 22 主讲人之一
+- [[Vino]]：CTP Topic 22 主讲人之一
+- [[Microsoft Active Directory]]：Windows 域服务，提供 DNS 托管能力
+- [[Office 365]]：Microsoft 365 SaaS 办公套件，其全球访问优化依赖就近 DNS 解析
+
+## Connections
+- [[ctp-topic-19-configuring-dns-within-aws-lzs]] ← extends ← [[ctp-topic-22-global-dns-service-offerings]]
+- [[ctp-topic-7-saas-landing-zone-design]] ← depends_on ← [[ctp-topic-22-global-dns-service-offerings]]
+- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] ← related_to ← [[ctp-topic-22-global-dns-service-offerings]]
+- [[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 摄入后补充对比
--- a/wiki/sources/ctp-topic-30-managing-change.md
+++ b/wiki/sources/ctp-topic-30-managing-change.md
@@ -0,0 +1,62 @@
+---
+title: "CTP Topic 30 Managing Change"
+type: source
+tags:
+  - Change-Management
+  - SRE
+  - ITSM
+  - DevOps
+  - Cloud-Transformation
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change]]
+
+## Summary（用中文描述）
+- 核心主题：云转型项目中的变更管理流程，以及 SRE 团队在不同阶段与产品团队的协作模式
+- 问题域：企业云迁移过程中的变更审批效率、自动化程度不足、SRE 与产品团队协作边界不清
+- 方法/机制：区分标准变更/正常变更/紧急变更三类流程；引入自动化（IaC+CI/CD）将变更转为标准变更；SRE 团队在构建/上线支持/BAU 三阶段提供差异化支持
+- 结论/价值：通过自动化减少人工审批，通过明确流程减少变更风险，SRE 团队是云转型中连接运维与产品的关键桥梁
+
+## Key Claims（用中文描述）
+- SRE 团队通过软件工程思维解决运维问题，核心在于自动化重复性工作，提高系统可靠性和可测试性
+- 标准变更（Standard Change）应实现完全自动化（IaC + CI/CD Pipeline），无需 CAB 审批，是理想状态
+- 正常变更（Normal Change）需 CAB 批准和变更窗口，目标是通过自动化逐步将其归入标准变更
+- 紧急变更（Emergency Change）需立即执行以缓解事故，事后通过 CAPA/Post-mortem 修复根因
+- SRE 团队在三个阶段（构建/早期上线支持/BAU）与产品团队以不同方式协作
+- Self-Healing（基于 ML 的自动化监控系统）是未来演进方向，各产品组分享实践，SRE 协助落地
+
+## Key Quotes
+> "SRE 用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒。" — Brendan Starnig
+> "Standard Change 应完全自动化（IaC + CI/CD Pipeline），无需 CAB 审批。" — Brendan Starnig
+> "Emergency Change 事后通过 CAPA/Post-mortem 修复根因，而非永久性补丁。" — Brendan Starnig
+
+## Key Concepts
+- [[SRE]]：Site Reliability Engineering，站点可靠性工程，通过软件工程思维解决运维问题
+- [[Standard-Change]]：标准变更，预批准变更，无需 CAB 审批，应完全自动化（IaC + CI/CD Pipeline）
+- [[Normal-Change]]：正常变更，有风险/影响，需 CAB 审批和变更窗口，理想状态是逐步归入 Standard Change
+- [[Emergency-Change]]：紧急变更，为缓解事故需立即执行的变更，事后通过 CAPA/Post-mortem 修复根因
+- [[CAPA]]：Corrective and Preventive Action，即 Post-mortem 回顾，从事故中提取根因并预防同类问题
+- [[SLO]]：Service Level Objective，服务等级目标，用于定义监控指标并向上汇总至 KPI
+- [[SLR]]：Service Level Requirement，服务等级需求，与 SLO 配套使用
+- [[Early-Live-Support]]：Build 与 BAU 之间的过渡阶段，需完成 Go-Live Checklist（监控覆盖、支持模型、事件响应流程）
+- [[Self-Healing]]：通过机器学习驱动的自动化监控系统，基于告警趋势自动决策和缓解问题
+
+## Key Entities
+- [[Brendan-Starnig]]：SRE Function Lead, Platform Engineering，本次会议主讲人
+- [[SMACs]]：Service Management Automation X，当前的 ITSM 工具，用于 Ticket、Incident、Change 管理
+- [[Vinaya]]：内部成员，提议各产品组分享 Self-healing 实践，SRE 将协助落地
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← context_for ← [[ctp-topic-30-managing-change]]
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← related_to ← [[ctp-topic-30-managing-change]]
+- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-30-managing-change]]（IaC 变更的 Tagging 标准属于 Standard Change 范畴）
+- [[ctp-topic-19-configuring-dns-within-aws-lzs]] ← related_to ← [[ctp-topic-30-managing-change]]
+
+## Contradictions
+- 与 [[ctp-topic-53-why-bother-with-cloud]] 的关系：
+  - 冲突点：是否应迁移至云端
+  - 当前观点（Topic 30）：接受云转型，聚焦如何在转型中有效管理变更
+  - 对方观点（Topic 53）：质疑云转型的必要性
+  - 说明：两者处于不同讨论层面，Topic 53 质疑迁移决策，Topic 30 假设迁移决策已做出，聚焦执行层面的变更管理
--- a/wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md
+++ b/wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md
@@ -0,0 +1,63 @@
+---
+title: "CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones"
+type: source
+tags:
+  - AWS
+  - Network-Security
+  - Landing-Zone
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Landing Zone 网络隔离与安全远程访问方案
+- 问题域：内部网络（On-prem / VPN 用户）对 AWS Landing Zone 生产工作负载的未授权访问风险
+- 方法/机制：① 网络隔离——Checkpoint 防火墙实现 default-deny 的 SPI 模型，阻断内部网络对 AWS 网段的直接连通；② 安全访问——AWS Systems Manager (SSM) 替代 VPN，提供基于浏览器的安全远程连接
+- 结论/价值：该方案作为 SD-WAN 实施前的过渡方案，以更低成本和更快速度解决紧急安全风险；长期目标是 IaC 化以消除控制台访问
+
+## Key Claims（用中文描述）
+- 内部网络与 VPN 用户因共享网络配置而可访问 AWS Landing Zone 生产工作负载，构成安全与合规风险
+- Checkpoint 防火墙启用 SPI（Security Policy Infrastructure）特性，默认 deny，仅放行必要服务和网段到 Landing Zone
+- AWS SSM 通过 IAM 角色假设 + SSM Agent 实现远程访问，无需 VPN，支持浏览器会话和 AWS CLI 两种模式
+- SSM 远程访问提供双因素认证保障，连接位于 AWS 网络内部，安全性高于传统 VPN
+- 当前方案定位于 SD-WAN 实施前的临时/备份方案，主要优势是降低成本和提升部署速度
+- 长期安全演进方向：IaC 化以减少控制台访问，break-glass 访问仅保留用于紧急场景
+- 当前方案聚焦网络隔离，不解决凭证被盗问题
+
+## Key Quotes
+> "The primary driver for this initiative is to address security concerns related to internal systems accessing production workloads in the new AWS landing zones." — 背景动机：内部系统对生产工作负载的访问安全风险
+
+> "The SPI features will be enabled with default deny enabled and allowances made for require services and network segments into the landing zones." — 核心机制：Checkpoint SPI 默认拒绝策略
+
+> "Authenticated users will assume roles granting access to the SSM agent on the target EC2 instance, leveraging existing access controls." — SSM 访问控制机制：基于 IAM 角色假设
+
+> "SSM gives users remote access via a browser based session." — SSM 核心价值：浏览器远程会话替代 VPN
+
+## Key Concepts
+- [[AWS-Landing-Zone]]：AWS 多账户架构框架，包含核心账户、基线账户、共享服务账户和产品账户
+- [[AWS-Systems-Manager-SSM]]：AWS 托管的远程管理服务，通过 SSM Agent 实现安全的无 VPN 远程访问，支持浏览器会话和 AWS CLI 模式
+- [[Network-Segregation]]：网络隔离策略，通过 Checkpoint 防火墙实现默认拒绝（default-deny），仅放行经授权的服务和网段通信
+- [[SPI-Security-Policy-Infrastructure]]：安全策略基础设施，在 Checkpoint 防火墙上强制执行网络分段，控制服务器间通信并阻断内部网络对 AWS 网段的直接访问
+- [[SD-WAN]]：软件定义广域网，组织的长期远程访问演进目标，当前 SSM 方案作为 SD-WAN 实施前的过渡方案
+
+## Key Entities
+- [[Checkpoint]]：网络安全设备供应商，提供 Landing Zone 间网段隔离的防火墙能力，依赖 AWS 标签值动态配置访问策略
+
+## Connections
+- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← related_to ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]
+  - 关联点：同属 AWS Landing Zone 网络知识体系，Topic 18 聚焦广域网架构（Transit Gateway / SD-WAN），Topic 31 聚焦网络隔离与安全访问
+- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]
+  - 关联点：Topic 25 的 Labs LZ 运维视角涉及 VPN 远程访问需求，与 Topic 31 的 SSM 安全访问方案存在技术演进关系
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← extends ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]
+  - 关联点：Topic 35 明确提及"网络分段阻断对 SaaS 工作负载的直接连通性"，是 Topic 31 所描述方案的设计依据
+
+## Contradictions
+- 与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 存在视角差异：
+  - 冲突点：Topic 18 强调广域网连通性（Transit Gateway Peering / SD-WAN / Pulse VPN 迁移至 Prisma Access），关注如何打通网络
+  - Topic 31 视角：网络隔离的首要目标是阻断内部网络对 AWS 的直接访问，关注如何限制连通性
+  - 对方观点：Topic 18 的演进路线中，Prisma Access (SASE) 将提供更安全的远程接入方案
+  - 当前观点：Topic 31 主张 SSM 作为过渡方案，在 SD-WAN 实施前优先解决网络安全隔离问题
+  - 调和建议：两者互补——Topic 31 解决内部网络隔离的短期安全问题，Topic 18 规划长期广域网演进路径（SD-WAN / SASE）
--- a/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
+++ b/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
@@ -0,0 +1,64 @@
+---
+title: "CTP Topic 36 SendGrid as an Email Service"
+type: source
+tags:
+  - SendGrid
+  - Email
+  - AWS
+  - CTP
+  - Cloud-Email
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service]]
+
+## Summary（用中文描述）
+- 核心主题：SendGrid 被选定为经典和新 Landing Zone 的标准邮件服务，同时更新了 Cyber Suite 加密套件标准。
+- 问题域：企业邮件服务迁移——现有邮件网关（Port 25 不安全、即将下线）和 SES（每封限制 50 收件人）无法满足云环境需求。
+- 方法/机制：SendGrid 支持每封最多 1,000 收件人、全云兼容、TLS 端到端加密、双因素认证；提供两种架构（直连 SendGrid vs 中继服务器），通过全球中继节点（伦敦/印度/东京）走私有线路汇至美国数据中心处理；支持计划覆盖每月 500 万封邮件。
+- 结论/价值：SendGrid 统一替换现有分散邮件方案，提升安全性（TLS/2FA）、扩展性（1,000 收件人）和云就绪度；Cyber Suite 标准更新了行业标准合规加密套件清单。
+
+## 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 团队审查。
+
+## 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
+
+> "SPF and DKIM records are essential for valid email sending to avoid emails landing in junk folders or being rejected." — CTP Topic 36
+
+> "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
+
+## 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）而被视为弱加密方式，不推荐使用。
+
+## 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 隶属其下，是全球大规模邮件发送的基础设施提供商。
+
+## 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 密钥轮换同属安全运维范畴）
+
+## Contradictions
+- 与 [[ctp-topic-12-using-ses-smtp-service-terraform-module]] 冲突：
+  - 冲突点：SES SMTP 作为企业标准邮件服务与 SendGrid 被选定为新标准之间的矛盾。
+  - 当前观点：SendGrid 取代 SES 成为新标准邮件服务（SES 每封限制 50 收件人，无法满足大规模需求）。
+  - 对方观点：SES 通过 Terraform 模块化管理，适合特定 AWS 原生集成场景。
--- a/wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
+++ b/wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
@@ -0,0 +1,47 @@
+---
+title: "CTP Topic 4 Using Agile to Run the Cloud Transformation Programme"
+type: source
+tags: []
+sources: []
+last_updated: 2026-04-24
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md]]
+
+## Summary（用中文描述）
+- 核心主题：云转型计划（Cloud Transformation Programme）中敏捷实践的落地经验
+- 问题域：大型企业云迁移项目如何选择和调整敏捷框架
+- 方法/机制：Scrum → Kanban 的框架演进；Microsoft Planner 作为看板工具；每日站会 + 回顾会议保留 Scrum 仪式
+- 结论/价值：Scrum 的固定 Sprint 节奏不适合快速变化的云转型项目，Kanban 持续流动 + 固定仪式是更优的混合方案
+
+## Key Claims（用中文描述）
+- 云转型团队从 Scrum（两周 Sprint）转向 Kanban，因为 Sprint 期间不允许变更，无法应对项目中的频繁变化
+- 混合框架（Kanban 为主 + 保留 Scrum 仪式）是当前最优方案
+- 每日站会应简短（15-30 分钟），围绕 Planner 看板回答三个问题：昨天完成什么、今天做什么、有什么阻碍
+- 回顾会议是快速反馈循环的核心，通过行动项（带负责人）驱动团队持续改进
+- Microsoft Planner 看板列：Backlog → To Do → In Progress → Program Key Decisions → Icebox
+- 每张任务卡必须指定单一负责人，即使多人协作；明确角色（如 oversight）；链接依赖卡；使用优先级和截止日期
+
+## Key Quotes
+> "The big problem with Scrum, in my opinion, is that you can't make changes throughout the sprints, we are not advised to." — Heather Norris，解释为何从 Scrum 转向 Kanban
+
+> "Agile is all about getting that rapid feedback to make the product and make the, you know, the development culture better." — Heather Norris，阐述敏捷的核心价值
+
+## Key Concepts
+- [[Scrum]]：两周一迭代的敏捷框架，包含 Product Backlog、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective；因 Sprint 期间禁止变更而被云转型团队放弃
+- [[Kanban]]：持续流动的敏捷框架，允许随时调整优先级，无固定 Sprint 边界；适合变化频繁的云转型项目
+- [[Agile Ceremonies]]：Scrum 的固定仪式——Sprint Planning（冲刺规划）、Daily Stand-up（每日站会）、Sprint Review（冲刺评审）、Retrospective（回顾会议）；云转型团队保留站会和回顾会议
+- [[Continuous Delivery]]：持续交付，Kanban 的核心优势，无需等待 Sprint 结束即可发布
+- [[Microsoft Planner Board]]：微软看板工具，云转型团队的项目管理平台，支持卡片管理、依赖链接、优先级设置
+
+## Key Entities
+- [[Heather Norris]]：云转型计划项目经理，主讲本次分享，介绍敏捷方法论实践
+- [[Microsoft Planner]]：团队使用的项目管理看板工具
+
+## Connections
+- [[ctp-topic-57-product-backlog-managing-demand]] ← related_to ← [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
+- [[ctp-topic-30-managing-change]] ← extends ← [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
+
+## Contradictions
+- 无已知冲突
--- a/wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md
+++ b/wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md
@@ -0,0 +1,57 @@
+---
+title: "CTP Topic 43 VMware Cloud on AWS"
+type: source
+tags:
+  - VMware
+  - AWS
+  - Hybrid-Cloud
+  - CTP
+  - Networking
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws]]
+
+## Summary（用中文描述）
+- 核心主题：VMware Cloud on AWS（VMC on AWS）混合云服务介绍
+- 问题域：企业混合云迁移策略、云端运行 VMware 工作负载
+- 方法/机制：VMware 与 AWS 联合工程，在 AWS 裸机服务器（i3.metal/i3en.metal）上原生安装 VMware vSphere 8，提供与本地一致的运维体验
+- 结论/价值：VMC on AWS 为不完全准备完全迁移至原生云的企业提供中间路线，相比常规云方案节省 27% 成本，支持 HCX 任意迁移
+
+## Key Claims（用中文描述）
+- VMware 与 AWS 联合工程：VMware hypervisor 在 AWS 硬件上原生安装，不是简单地将软件部署到云端
+- 应用双向迁移能力：工作负载可在数秒内往返迁移于本地与云端之间
+- 27% 成本节省：相比直接使用常规云方案，VMC on AWS 提供更优的经济性
+- 单一工具集：与本地环境使用相同的 vSphere 工具集，降低运维学习曲线
+- TCO 计算支持：云经济学团队可提供总拥有成本计算，比较本地与其他超大规模云提供商的成本
+
+## Key Quotes
+> "This is not just something where VMware showed up at Amazon and dropped off a box of CDs." — Mike O'Reilly，Staff Cloud Solutions Architect at VMware
+> "VMware sells an entire host, enabling over-provisioning and cost reduction." — Brian Reeves
+> "VMC on AWS offers a 27% cost saving compared to going to a regular cloud."
+
+## Key Concepts
+- [[VMware-Cloud-on-AWS]]：VMware 与 AWS 联合开发的混合云服务，在 AWS 基础设施上原生运行 VMware vSphere 工作负载
+- [[SDDC]]：软件定义数据中心，VMC on AWS 通过 vCenter 进行管理的核心架构单元
+- [[HCX]]：Hybrid Cloud Extension，支持任意 vSphere 环境之间的双向工作负载迁移
+- [[Stretched-Cluster]]：跨可用区的拉伸集群，提供跨 AZ 的高可用和灾难恢复能力
+- [[TCO]]：总拥有成本，云经济学团队用于评估迁移成本效益的核心指标
+
+## Key Entities
+- [[VMware]]：企业级虚拟化和云计算软件提供商，与 AWS 合作开发 VMC on AWS
+- [[AWS]]：Amazon Web Services，提供 VMC on AWS 的底层裸机服务器基础设施（i3.metal/i3en.metal）
+- Brian Reeves：VMware 演讲者，讨论 VMC on AWS 的经济学效益
+- Michael Riley：VMware 演讲者
+- Mike Armstrong：VMware 演讲者
+- Mike O'Reilly：VMware Staff Cloud Solutions Architect，主讲 VMC on AWS 技术架构
+
+## Connections
+- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[ctp-topic-43-vmware-cloud-on-aws]]（两者均涉及 AWS 基础设施上的企业工作负载部署）
+- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← related_to ← [[ctp-topic-43-vmware-cloud-on-aws]]（混合云是 Landing Zone 设计的重要扩展方向）
+
+## Contradictions
+- 与 [[ctp-topic-53-why-bother-with-cloud]] 潜在冲突：
+  - 冲突点：是否应迁移至云端
+  - 当前观点：本视频主张 VMC on AWS 作为平滑迁移路径，降低上云门槛
+  - 对方观点：质疑云迁移的必要性，强调需评估真实 ROI
--- a/wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
+++ b/wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
@@ -0,0 +1,52 @@
+---
+title: "CTP Topic 45 Automatic IP address allocation with IPAM"
+type: source
+tags:
+  - AWS
+  - IPAM
+  - Networking
+  - CTP
+  - Infoblox
+  - VPC
+  - Terragrunt
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam]]
+
+## Summary（用中文描述）
+- 核心主题：使用 Infoblox NIOS 实现 AWS VPC 自动化 IP 地址分配，替代传统手工电子表格管理方式
+- 问题域：IP 地址管理效率低下（手工请求→网络团队计算CIDR→手工填表→人工配置YAML），新增VPC需要反复与网络团队交接
+- 方法/机制：Infoblox NIOS IPAM 系统自动查询下一个可用 IP 地址块，按需自动审批（≤/24自动，>/24需网络团队审批），Terragrunt YAML 配置文件不再包含硬编码 IP，改由 NIOS 动态注入
+- 结论/价值：实现"创建 VPC 无需网络团队参与"的完全自动化目标，消除 Excel 表格管理，建立单一可信数据源，向后兼容旧 YAML 配置
+
+## Key Claims（用中文描述）
+- Infoblox NIOS 通过 API 自动分配下一个可用 IP 地址块，替代人工计算 CIDR 范围和手动更新电子表格
+- 当所需网络地址 ≤/24 时，VPC 模块自动运行，无需人工干预
+- 当所需网络地址 >/24 时，系统自动触发网络团队审批流程，而非直接拒绝
+- 新 YAML 配置文件中不再包含 CIDR 子网 IP 地址，仅声明期望的子网大小（如 /22）和区域级父 CIDR 常量
+- VPC 名称被纳入 YAML 文件，支持一次性配置多个 VPC
+- 销毁 VPC 时自动从 IPAM Grid 中清除所有相关条目，支持撤销保护（Terragrunt.hcl 需特殊 flag 防止误删）
+- 新系统向后兼容现有 VPC 配置，旧 YAML 文件继续工作
+
+## Key Quotes
+> "Managing the IP address in a spreadsheet takes time and it's not a good approach." — 当前电子表格管理方式的低效痛点
+> "We are not asking for IP address from the network team." — 新系统的核心价值：消除网络团队交接
+> "The goal is for any new VPC that we don't have to engage the network team every time we want to create a VPC with the subnets." — 自动化愿景
+
+## Key Concepts
+- [[IPAM（IP Address Management）]]：IP 地址管理系统的核心概念，NIOS 提供集中化管理、控制、监控和分配 IP 地址空间的能力
+- [[Infoblox-NIOS]]：Infoblox NIOS 是 IPAM 功能的核心实现，作为分布式 Grid 框架的扩展，集成 DNS/DHCP，提供统一管理控制台
+- [[VPC-自动化供给]]：通过 Terragrunt YAML 配置文件声明式定义 VPC 需求，由 NIOS 自动分配 IP 地址，无需手工配置
+
+## Key Entities
+- [[Grid-Master]]：Infoblox Grid 架构中的核心节点，管理 API 调用和各 AWS 云账户的 IP 地址分配
+
+## Connections
+- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← relates_to ← 本页：均涉及 VPC 供给与 IPAM 自动化的实践
+- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← depends_on ← 本页：Labs Landing Zone 的 VPC 供给依赖 IPAM 自动分配
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← related_to ← 本页：均涉及标签驱动的 AWS 基础设施自动化
+
+## Contradictions
+- 无已知冲突内容
--- a/wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md
+++ b/wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md
@@ -0,0 +1,58 @@
+---
+title: "CTP Topic 61 Workload VPC provision with IPAM Automation"
+type: source
+tags:
+  - AWS
+  - VPC
+  - IPAM
+  - Automation
+  - CTP
+  - Infoblox
+date: 2026-04-24
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation]]
+
+## Summary（用中文描述）
+- 核心主题：IPAM（IP 地址管理）与 Workload VPC 自动化供给的完整集成方案，包括近期功能增强。
+- 问题域：企业多账号 AWS 环境中，如何在不依赖网络团队手工介入的情况下，自动完成 VPC 的 IP 地址规划与供给。
+- 方法/机制：使用 Infoblox Grid 作为核心 IPAM 引擎，通过声明式 YAML 配置文件触发自动化供给流程；/22 及更大 CIDR 自动审批，更小 CIDR 触发邮件审批流程；Availability Zone ID（而非 AZ Name）避免跨区域不一致；多 VPC 批量供给和非路由 IP 地址（如 10.2.0.0/16）支持。
+- 结论/价值：**"只需把信息放到正确位置，一切自动完成。"** 用户只需声明业务联系人和父 CIDR，无需关心 IP 地址分配细节；Infoblox Grid 作为唯一可信数据源，防止 IP 地址重叠。
+
+## Key Claims（用中文描述）
+- IPAM 通过 Infoblox Grid 自动管理 IP 地址，消除手工操作，显著降低配置错误率。
+- 工作负载 VPC 供给完全自动化，YAML 文件仅声明业务联系人、工程联系人和父 CIDR，不再包含硬编码 IP 地址。
+- CIDR 块大小决定审批流程：/22 或更大自动批准，更小（如 /24）需提交理由并由网络团队审批。
+- Infoblox Grid 作为全局唯一 IP 地址数据源，防止多账号环境中的 IP 地址重叠冲突。
+- 使用 AZ ID（可用区标识符）而非 AZ Name（可用区名称）避免不同 AWS 账户对同一物理位置命名不一致的问题。
+- 邮件通知机制覆盖用户和网络团队，全程透明可追溯。
+- Infoblox 架构包含位于休斯顿数据中心的主数据库，以及冗余的 DNS、NTP 和 DHCP 服务。
+
+## Key Quotes
+> "We don't need to worry about IP address. If it's beyond IP address is 22 or greater, then only we need to take the approval." — Pushka，IPAM 自动化审批阈值说明
+
+> "So we just need to put the information at the right place and everything will work." — Pushka，用户只需提供正确信息，IPAM 自动完成其余工作
+
+## Key Concepts
+- [[IPAM（IP Address Management）]]：企业级 IP 地址管理自动化平台，通过声明式配置替代手工分配。本视频展示了 IPAM 与 AWS VPC 供给的深度集成。
+- [[Infoblox-Grid]]：核心 IPAM 引擎，包含容器、IP地址及可扩展属性（元数据，如 owner、company、status），维护全局唯一 IP 地址记录。
+- [[VPC-自动化供给]]：通过 YAML 配置文件声明业务参数，自动触发 VPC 创建流程，无需网络团队手工介入。
+- [[CIDR-审批流程]]：/22 及更大 CIDR 自动批准；/22 以下需提交理由经网络团队审批后供给。
+- [[Availability-Zone-ID]]：AWS 可用区标识符（az-id），用于避免多账号环境中 AZ 名称（az-name）不一致问题。
+
+## Key Entities
+- [[Pushka]]（Principal SRE）：IPAM 与 VPC 自动化方案的发起人和演示者，Topic 61 主讲人。
+- [[Infoblox]]：IPAM 供应商，提供 Grid 架构及 NIOS 平台，负责管理所有账号的 IP 地址分配记录。
+- [[AWS-Landing-Zone]]：本方案的实施背景——企业级多账号 AWS 环境，IPAM 作为 LZ 网络层的核心组件。
+
+## Connections
+- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← extends ← [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]
+  - Topic 45 介绍 IPAM 自动分配机制；Topic 61 展示该机制在 Workload VPC 供给中的完整应用。
+- [[ctp-topic-22-global-dns-service-offerings]] ← shares_infra ← [[Infoblox-Grid]]
+  - Infoblox 同时支撑 DNS Anycast 和 IPAM 服务，是网络层多服务的统一基础设施。
+- [[ctp-topic-31-network-segregation-and-secure-access]] ← depends_on ← [[VPC-自动化供给]]
+  - VPC 自动化供给是网络分段和安全访问策略的基础前提。
+
+## Contradictions
+- 无已知冲突内容。
--- a/wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
+++ b/wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
@@ -0,0 +1,56 @@
+---
+title: "CTP Topic 65 Tracing the Value Delivered in Cloud Transformation"
+type: source
+tags:
+  - Value-Tracing
+  - Cloud-Transformation
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md]]
+
+## Summary（用中文描述）
+- 核心主题：云转型中的价值交付量化框架与工作优先级排序方法
+- 问题域：如何系统性地衡量、捕获和优先排序云转型工作中的业务价值
+- 方法/机制：①定义过程（Process）和价值流（Value Stream）概念；②建立全局收益框架（财务、生产力、质量、体验四维度）；③使用加权最短作业优先（WSJF）方法对工作进行经济性排序；④在功能级别拆解价值归属
+- 结论/价值：云转型工作应以"最小投入尽早交付最大价值"为原则，通过量化收益和成本延迟比来优化工作排序，实现经济收益最大化
+
+## Key Claims（用中文描述）
+- 过程（Process）是由输入（数据、资源、时间、资金、专业知识）驱动的系统性步骤，将输入转化为产出和成果，成果分为硬性（时间、成本、质量）和软性（健康、安全）
+- 价值（Value）由客户决定，体现为公平回报或等价商品；Lean 识别三类活动：增值活动、价值赋能活动、浪费
+- 价值流（Value Stream）是向客户交付产品或服务的系列活动，分为运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）
+- 收益捕获需要全局框架，涵盖财务、生产力、质量和体验四个维度，聚焦收入增长、成本降低、风险改善和服务可获得市场规模（SOM）
+- 加权最短作业优先（WSJF）方法通过"延迟成本/作业规模"比值对工作排序，实现最大经济收益
+- 延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会
+
+## Key Quotes
+> "What we want to do is deliver the maximum value early back into the business for the least amount of effort." — CTP Topic 65 核心目标
+> "A simple way of thinking of an outcome is that there's usually going to be a desirable change in some important attribute or indicator." — 成果的定义
+> "For each demand, the demand manager captures these five things from the product team. Financial figures should be annualized." — 需求管理流程
+> "The weighted shortest job first method prioritizes work based on cost of delay divided by size of job." — WSJF 优先级排序公式
+
+## Key Concepts
+- [[Process]]：由输入驱动的系统性步骤，将输入转化为产出和成果
+- [[Value]]：由客户决定的货币价值，体现为公平回报
+- [[Value-Stream]]：向客户交付产品或服务的系列活动，包含 OVS（运营价值流）和 DVS（开发价值流）
+- [[Value-Adding]]：Lean 中的增值活动类型
+- [[Waste]]：Lean 中的浪费活动类型
+- [[Benefits-Quantification]]：财务、生产力、质量、体验四维度收益量化框架
+- [[Cost-of-Delay]]：延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会
+- [[WSJF]]：Weighted Shortest Job First，通过 Cost of Delay / Size of Job 比值排序工作
+- [[SOM]]：Serviceable Obtainable Market，可服务可获得市场规模
+- [[Feature-Level-Value-Breakdown]]：在功能级别拆解和分配价值的方法
+
+## Key Entities
+- [[CTP]]：Cloud Transformation Programme，云转型计划（本视频来源项目）
+- [[Scaled-Agile]]：SAFe 框架定义了 OVS 和 DVS 概念（本视频引用）
+
+## Connections
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ← relates_to ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（均涉及敏捷方法管理云转型）
+- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] ← extends ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（需求流程与价值量化协同）
+- [[ctp-topic-30-managing-change]] ← relates_to ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（变更管理与价值交付的关系）
+
+## Contradictions
+- 与 [[ctp-topic-53-why-bother-with-cloud]] 的视角张力：Topic 53 质疑迁移必要性，Topic 65 假设迁移已决策并聚焦如何量化交付价值。两者互补而非逻辑矛盾——前者回答"是否迁移"，后者回答"如何衡量价值"。
--- a/wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md
+++ b/wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md
@@ -0,0 +1,69 @@
+---
+title: "CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS"
+type: source
+tags:
+  - VMware
+  - Migration
+  - VMWare-Cloud-AWS
+  - CTP
+  - HCX
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]]
+
+## Summary（用中文描述）
+- 核心主题：VMware Cloud on AWS 环境中的本地虚拟机迁移最佳实践
+- 问题域：IOD (Internet of Things/Devices) 虚拟化基础设施向 VMware Cloud on AWS 的迁移规划与执行
+- 方法/机制：
+  - HCX (Hybrid Cloud Extension) 实现多云管理和 any-to-any vSphere 迁移
+  - Direct Connect + Virtual Transit Gateway 实现混合云连接
+  - UI 迁移方式（VMware Cloud 原生）和 CCOE 脚本自动化迁移两种方案
+  - 预迁移评估（计算规格、配置、网络需求）和后迁移自动化配置
+  - Brown to Manage (BHM) 系统集成 SMACS + HCMX 进行虚拟机管理
+- 结论/价值：工作负载可在几分钟内完成迁移并在云基础设施运行，显著降低停机时间，节省成本
+
+## Key Claims（用中文描述）
+- HCX 每次迭代最多支持 200 台虚拟机迁移
+- 任何离开云环境的数据传输都会产生费用（Anything which leaves definitely attracts cost）
+- STDC (VMware Cloud on AWS Software-Defined Data Center) 集群和 ESX 节点（EC2 裸金属实例）由 VMware 管理
+- CCOE 团队开发的脚本化迁移方案使用输入文件定义 VM 详情，实现自动化批量迁移
+- 迁移后通过 Brown to Manage 系统集成 SMACS Suite 和 HCMX Content Pack 实现用户管理
+
+## Key Quotes
+> "The session covers best practices for migrating on-premises virtual machines to VMware Cloud on AWS, based on experience and consultant support from VMware." — 会议主题
+
+> "It hardly takes a VM migration with few minutes, which will enable them operated in the cloud infrastructure." — 迁移效率
+
+> "HCX (Hybrid Cloud Extender) facilitates multi-cloud management, allowing viewing of on-premises vSphere from STDC and vice versa." — HCX 双向管理能力
+
+> "Anything which leaves definitely attracts cost." — 数据传输成本原则
+
+## Key Concepts
+- [[VMware-Cloud-on-AWS]]：AWS 基础设施上托管的 VMware SDDC 环境，提供 vSphere、连接性和防火墙服务
+- [[HCX]]：Hybrid Cloud Extension，支持任意 vSphere 环境之间的双向工作负载迁移，每次迭代最多支持 200 台 VM
+- [[SDDC]]：Software-Defined Data Center，VMC on AWS 的核心部署单元，通过 vCenter 管理
+- [[Direct Connect]]：AWS 混合云连接服务，用于将本地数据中心连接至 AWS
+- [[Virtual Transit Gateway]]：虚拟Transit Gateway，实现无缝迁移连接的组件
+- [[BGP]]：Border Gateway Protocol，通过 BGP 协议连接客户机房与 VMware Cloud
+- [[EC2-Bare-Metal]]：EC2 裸金属实例，i3.metal/i3en.metal，用于部署 VMC on AWS
+
+## Key Entities
+- [[VMware]]：云平台提供商，管理 STDC、ESX 节点和 vSphere 环境
+- [[AWS]]：云基础设施提供商，EC2 裸金属实例所在平台
+- [[CCOE]]：Cloud Center of Excellence，开发了脚本化迁移解决方案
+- [[SMACS Suite]]：Brown to Manage 系统的组成套件
+- [[HCMX]]：Hybrid Cloud Manager X，用于 VMware Cloud 与本地环境集成的管理工具
+
+## Connections
+- [[ctp-topic-43-vmware-cloud-on-aws]] ← extends ← [[ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]]（Topic 43 介绍 VMC on AWS 概述，Topic 69 深入迁移最佳实践）
+- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← depends_on ← [[ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]]（广域网架构为混合云迁移提供网络基础）
+- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] ← related_to ← [[ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]]（网络隔离和安全访问是迁移后环境的重要考量）
+
+## Contradictions
+- 与 [[ctp-topic-43-vmware-cloud-on-aws]] 的视角差异：
+  - 冲突点：Topic 43 强调 VMC on AWS 的概述和经济性，Topic 69 侧重具体迁移执行流程
+  - 当前观点：Topic 69 提供迁移操作的详细步骤和技术考量
+  - 对方观点：Topic 43 聚焦服务介绍和战略价值，属于迁移决策前的评估阶段
+  - 结论：两者互补，Topic 43 用于理解 VMC on AWS 是什么，Topic 69 用于执行实际迁移
--- a/wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
@@ -0,0 +1,58 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723"
+type: source
+tags:
+  - OpenText
+  - DR
+  - Recovery
+  - BCP
+  - SRE
+  - Observability
+date: 2024-07-23
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText 灾难恢复（DR）机制向"恢复保证（Recovery Assurance）"的演进路径
+- 问题域：企业级 DR 测试的被动性、手动性、无一致组织方法等问题；多云（AWS/GCP/Azure）托管环境下的 DR 复杂性
+- 方法/机制：四位框架（Design / Software / Build / Environments）+ SRE + 可观测性工程
+- 结论/价值：从被动应对转向主动设计，将可恢复性作为架构设计原则，通过自动化和可观测性提升弹性能力
+
+## Key Claims（用中文描述）
+- **CrowdStrike 事件警示**：单点软件漏洞可导致全球大规模系统中断，OpenText 虽未受直接影响，但必须强化端到端系统管理
+- **RTO/RPO 因合同而异**：OpenText 的恢复时间目标和恢复点目标跨度从分钟到数天不等，测试以反应式为主
+- **DR 测试现状瓶颈**：依赖人工、按客户时间表安排，涉及多个 SME 团队，协同成本高且缺乏可扩展性
+- **多云加剧复杂性**：超大规模云平台（AWS/GCP/Azure）的测试主要关注区域故障，缺乏对其他故障模式（账户级/服务级）的覆盖
+- **混合架构挑战**：仅部分服务可故障切换的混合方案增加了 DR 编排难度
+- **四位框架转型**：Design（可恢复性前置设计）→ Software（遥测+自愈）→ Build（Customer Zero 验证）→ Environments（SRE+可观测性）
+
+## Key Quotes
+> "CrowdStrike was not us, but we have had some disruptions." — Jim Rose，强调即使未直接受 CrowdStrike 影响，OpenText 自身也经历过多次中断事件
+> "Every person who is a SME on some part of this has to be involved in developing a plan." — Jim Rose，说明当前 DR 测试的人力密集型瓶颈
+> "Recoverability should be a design principle." — Jim Rose，倡导将可恢复性作为架构设计的核心原则
+
+## Key Concepts
+- [[RTO]]（Recovery Time Objective）：事件发生后恢复服务所需时间，OpenText 跨度从分钟到数天
+- [[RPO]]（Recovery Point Objective）：可接受的最大数据丢失量，同样因客户合同而异
+- [[SRE]]（Site Reliability Engineering）：用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性
+- [[Observability Engineering]]（可观测性工程）：通过遥测数据持续理解系统健康状态，是 Recovery Assurance 的技术基础
+- [[Disaster Recovery]]（灾难恢复）：保护系统免受灾难性事件影响的策略与实践
+- [[Business Continuity Plan]]（业务连续性计划）：确保业务在灾难期间持续运营的规划框架
+- [[Self-Healing]]（自愈能力）：软件应具备持续监控系统健康并在无需人工干预情况下自动恢复的能力
+- [[Customer Zero Environment]]：新版本发布前的内部验证环境，用于在真实流量前发现潜在问题
+
+## Key Entities
+- [[OpenText]]：企业信息管理公司，托管于 AWS/GCP/Azure 多云环境，由 Jim Rose 主讲本次学习会议
+- [[Jim Rose]]：OpenText 技术负责人/演讲者，分享 DR 向 Recovery Assurance 演进的实践与思考
+- [[CrowdStrike]]：2024 年引发全球大规模系统中断的安全软件公司，作为 DR 重要性案例被引用
+
+## Connections
+- [[ctp-topic-72-enterprise-dr-strategy-aws-backup]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（均涉及企业 DR 策略，CTP Topic 72 提供 AWS Backup 层面的具体实现，本视频提供组织层面的演进思维）
+- [[ctp-topic-41-nfrs-and-error-budgets]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（NFR/Error Budget 是 SRE 度量弹性目标的工具，与本视频的 SRE 转型方向一致）
+- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（可观测性工程是 Recovery Assurance 的技术基础，OpenTelemetry 是具体实现路径）
+- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（EKS 可靠性工程实践与本视频的四位框架中的 Environments 层对应）
+
+## Contradictions
+- 无已知冲突。本视频提供 DR 向 Recovery Assurance 演进的方法论框架，与现有 Wiki 中的 DR 相关内容（CTP Topic 72 AWS Backup 实施、CTP Topic 44 AWS Backup 评估）互补而非冲突，共同构成完整的 DR 知识体系。