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

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 负责发现（存量资源合规审计）

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
+- 无已知冲突

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 内部的落地配置）

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 适用于大范围迁移决策，敏捷方法适用于迭代式产品开发

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 摄入后补充对比

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 假设迁移决策已做出，聚焦执行层面的变更管理

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）

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 原生集成场景。

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
+- 无已知冲突

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

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
+- 无已知冲突内容

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
+- 无已知冲突内容。

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 假设迁移已决策并聚焦如何量化交付价值。两者互补而非逻辑矛盾——前者回答"是否迁移"，后者回答"如何衡量价值"。

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 用于执行实际迁移

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 知识体系。