Auto-sync: 2026-04-19 06:32

2026-04-19 06:32:15 +08:00
parent 56f49ecd5b
commit a1636ec67a
92 changed files with 3251 additions and 5 deletions
--- 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,57 @@
+---
+title: "CTP Topic 18 Wide Area Networking in AWS Cloud"
+type: source
+tags:
+  - AWS
+  - WAN
+  - Networking
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md]]
+
+## Summary
+- 核心主题：AWS 云环境中的广域网（WAN）架构设计及其演进路径
+- 问题域：大型企业跨国云网络管理、跨区域连接、远程访问优化
+- 方法/机制：Transit Gateway (TGW) 星型拓扑、SD-WAN 叠加网络、Prisma Access SASE 架构
+- 结论/价值：展示从传统静态路由到智能SD-WAN演进的完整路径，为企业云网络架构提供实践参考
+
+## Key Claims
+- Transit Gateway 是 AWS 区域级网络中转服务，连接 VPC、本地网络及跨区域 TGW
+
+## Key Quotes
+> "将全球划分为三个地理区域（APJ、EMEA、AMS），每个区域设立一个核心 Hub（如 EMEA 的伦敦，AMS 的俄勒冈）。所有 Landing Zones 通过 TGW Peering 接入区域 Hub，形成星型拓扑"
+
+> "当前 TGW 间的路由主要基于静态前缀列表（Prefix Lists），缺乏动态路由协议（如 BGP）支持"
+
+> "计划引入 Silver Peak 的 SD-WAN 方案作为叠加网络（Overlay），实现动态路径选择和自动化流量调度"
+
+> "计划将传统 Pulse VPN 迁移至 Palo Alto 的 Prisma Access（SASE 架构）"
+
+## Key Concepts
+- [[Transit Gateway]]：AWS 区域级网络中转服务
+- [[Landing Zone]]：企业标准化的 AWS 多账号环境
+- [[Hub-and-Spoke]]：星型拓扑结构
+- [[SD-WAN]]：软件定义广域网
+- [[Prisma Access]]：Palo Alto 的 SASE 安全访问服务
+- [[Overlay Network]]：叠加网络
+
+## Key Entities
+- [[AWS]]：亚马逊云服务平台
+- [[Christian Deckelman]]：Micro Focus IT 网络架构师，演讲人
+
+## Connections
+- [[CTP Topic 34 Azure Landing Zone Architecture Overview]] ← relates_to ← [[Landing Zone]]
+- [[CTP Topic 22 Global DNS service offerings]] ← relates_to ← [[WAN]]
+- [[CTP Topic 19 Configuring DNS within AWS LZs]] ← relates_to ← [[Landing Zone]]
+
+## Contradictions
+- （暂无）
+
+## Source
+- NAS: /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 18_ Wide Area Networking in AWS Cloud.mp4
+
+---
+*last_updated: 2026-04-14*
--- 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,52 @@
+---
+title: "CTP Topic 19: Configuring DNS within AWS LZs"
+type: source
+tags:
+  - AWS
+  - DNS
+  - Landing-Zone
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md]]
+
+## Summary
+- 核心主题：在 AWS Landing Zone 多账号环境下实现 DNS 集中化管理
+- 问题域：解决跨账号、跨云与本地数据中心（On-prem）之间的域名解析难题
+- 方法/机制：通过专用 DNS 账号集中管理 Private Hosted Zones，利用 Route 53 Resolver 的 Inbound/Outbound Endpoints 处理混合云 DNS 流量，通过 AWS RAM 跨账号共享 Resolver Rules
+- 结论/价值：推荐设立专门的 DNS 账号（曾被称为 InfoBlocks 账号）进行集中管理，便于统一维护路由规则和域名记录
+
+## Key Claims
+- 在 Landing Zone 中设立专门的 DNS 账号进行集中管理，而非在每个业务账号中分散创建私有托管区
+- Route 53 Resolver 的 Inbound Endpoints 接收来自本地数据中心的解析请求，Outbound Endpoints 将 AWS 内部请求转发至本地 DNS 服务器
+- 利用 AWS RAM 将 DNS 账号中定义的解析规则共享给各个业务账号，跨账号 VPC 与私有托管区关联时必须先授权再关联
+
+## Key Quotes
+> "推荐在 Landing Zone 中设立专门的 DNS 账号（曾被称为 InfoBlocks 账号），而非在每个业务账号中分散创建私有托管区。这种方式便于统一维护路由规则和域名记录。" — Sankar Gopov
+
+> "通过 Inbound Endpoints 接收来自本地数据中心的解析请求，通过 Outbound Endpoints 将 AWS 内部请求转发至本地 DNS 服务器。" — Sankar Gopov
+
+## Key Concepts
+- [[Route-53-Private-Hosted-Zone]]：AWS Route 53 私有托管区域，用于在指定 VPC 内部解析自定义域名
+- [[Route-53-Resolver-Endpoint]]：Route 53 Resolver 的入站/出站终端节点，处理混合云 DNS 流量
+- [[AWS-RAM]]：Resource Access Manager，用于跨账号共享 DNS 解析规则
+- [[Landing-Zone]]：AWS 多账号环境规范，预配置安全、网络和治理框架
+- [[VPC-Association-Authorization]]：跨账号关联流程，需先授权再关联
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，主题云平台
+- [[Gruntwork]]：提供 Landing Zone 框架
+- [[Route-53]]：AWS DNS 服务
+
+## Connections
+- [[CTP-Topic-22-Global-DNS-Service-Offerings]] ← extends ← 本页面：DNS 服务架构的延续
+- [[Gruntwork-Landing-Zone]] ← depends_on ← 本页面：DNS 配置依赖 Landing Zone 架构
+- [[Route-53-Private-Hosted-Zone]] ← implements ← 本页面：具体实现机制
+
+## Contradictions
+- （暂无）
+
+## Notes
+- Terraform 用于自动化 DNS 配置，在创建业务 VPC 过程中通过预定义模块自动完成规则共享与 VPC 关联
--- 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,59 @@
+---
+title: "CTP Topic 20 Program demand process flow and PoC onboarding"
+type: source
+tags:
+  - Demand-Process
+  - PoC
+  - Onboarding
+  - CTP
+  - Cloud-Transformation
+date: 2026-04-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md]]
+
+## Summary
+- 核心主题：云转型计划（CTP）的程序需求流程与概念验证（POC）入站流程
+- 问题域：企业云迁移的需求管理、风险控制与治理流程
+- 方法/机制：Gate 审批流程（Gate 0/1/3）、POC 验证、IaC 自动化部署
+- 结论/价值：POC 是降低迁移风险的核心环节，需验证架构可行性并熟悉 Gruntwork Landing Zone
+
+## Key Claims
+- 程序需求流程始于业务端转型需求，经过优先级排序后决定是否进行 POC
+- Gate 0 用于评估准入，Gate 1 负责设计权威审批，Gate 3 作为迁移最终准入
+- POC 主要目的是验证架构和技术可行性，让团队熟悉基于 Gruntwork 的新一代 Landing Zone
+- 新环境强调 IaC，要求使用 Terraform 和 Terragrunt 自动化部署，严禁手动构建
+- POC 预期成果包括：验证的解决方案设计、准备就绪的 IaC 脚本、明确的迁移时间表
+
+## Key Quotes
+> "POC 被强调为降低迁移风险的核心环节" — Sergio
+> "Gate 1 负责设计权威（Design Authority）审批" — Damian
+
+## Key Concepts
+- [[Program-Demand-Process]]：从业务需求产生、优先级排序到最终交付迁移的端到端管理路径
+- [[Proof-of-Concept-POC]]：概念验证阶段，用于证明架构可行性和测试复杂网络需求
+- [[Landing-Zone]]：云端预配置的标准化基础架构环境
+- [[Infrastructure-as-Code-IaC]]：通过脚本（如 Terraform）而非手动操作管理云资源
+- [[Gate-Process]]：网关审批流程，用于治理项目进度的关键决策点
+- [[Terraform]]：核心 IaC 工具，用于编写和管理云基础设施配置脚本
+- [[Solution-Design]]：解决方案设计，在 POC 阶段需完成并经过设计权威审批
+- [[PCG-Team]]：平台控制组，负责云环境支持、安全策略制定及协助产品组进行 POC
+
+## Key Entities
+- [[Sergio]]：云转型计划专家，本次会议主讲人之一
+- [[Damian]]：云转型计划专家，本次会议主讲人之一
+- [[PCG-Team]]：平台控制组，提供云环境支持和技术协助
+- [[Gruntwork]]：提供 Landing Zone 框架的核心技术提供商
+
+## Connections
+- [[CTP-Topic-25-Labs-Landing-Zone]] ← extends ← [[Gruntwork-Landing-Zone]]
+- [[CTP-Topic-1-Gruntwork-Landing-Zone-Architecture]] ← depends_on ← [[Landing-Zone]]
+- [[PCG-Team]] ← supports ← [[Proof-of-Concept-POC]]
+
+## Contradictions
+- （暂无记录）
+
+---
+
+*最后更新: 2026-04-19*
--- a/wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md
+++ b/wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md
@@ -0,0 +1,55 @@
+---
+id: ctp-topic-23-introduction-to-the-technical-architecture-team-and-function
+title: "CTP Topic 23 Introduction to the Technical Architecture team and function"
+type: source
+tags:
+  - Technical-Architecture
+  - Team
+  - CTP
+  - OpenText
+date-added: 2026-04-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md]]
+
+## Summary
+- 核心主题：技术架构团队（Technical Architecture Team）的职能、组织架构及在公司云转型中的价值
+- 问题域：云转型过程中的技术治理与架构规划
+- 方法/机制：从被动响应转向主动规划，通过"技术领域（Technical Domains）"划分和首席架构师负责制实现12-24个月前瞻性路线图
+- 结论/价值：技术架构团队通过维护AWS Enterprise Landing Zones、推行"云优先（Cloud-first）"策略，帮助业务部门规避风险、优化预算、提升交付速度
+
+## Key Claims
+- 技术架构团队核心转变：从被动响应转向主动规划，通过12-24个月路线图从"救火式"响应转变为预测性规划
+- 三种架构职能分工：企业架构（EA）对接业务战略、方案架构（SA）负责中间件与服务优化、技术架构（TA）专注于底层技术实施与基础设施治理
+- 云优先策略：除非因数据主权、合规性或极端成本原因必须保留在本地，否则所有新业务应优先上云
+
+## Key Quotes
+> "从两个大型组织的合并，涉及基础设施、流程与治理模式的深度融合" — 背景：PSTC与IT部门整合至CIO统一领导
+> "技术架构团队在维护AWS Enterprise Landing Zones方面的努力，旨在通过标准化和治理确保云环境的安全与高效"
+> "通过将技术划分为不同的'技术领域（Technical Domains）'并由首席架构师负责"
+
+## Key Concepts
+- [[Technical-Domains]]：将公司技术栈划分为特定领域（如身份认证、网络、Microsoft堆栈等），每个领域由专人负责其生命周期与路线图
+- [[Technical-Architecture-TA]]：最贴近技术的架构层，负责具体基础设施的设计、实施治理以及技术路线图的维护
+- [[Enterprise-Architecture-EA]]：架构体系的高层，主要负责将业务目标转化为技术原则和标准
+- [[Solution-Architecture-SA]]：架构体系的中间层，专注于特定项目或服务的优化实施
+- [[Cloud-First-Strategy]]：云优先策略，优先选择云解决方案而非本地部署
+- [[AWS-Enterprise-Landing-Zones]]：AWS企业落地分区，一套预配置的、符合最佳实践的AWS多账号环境
+
+## Key Entities
+- [[Martin-Nash]]：技术架构经理（Technical Architecture Manager），本次演讲主讲人
+- [[Cloud-Transformation-Office]]：云转型办公室（CTO），主办方
+- [[PSTC]]：Professional Services and Technology Company，合并前的组织
+- [[IT]]：信息技术部门，合并前的组织
+
+## Connections
+- [[CTP-Topic-47-Enterprise-Architecture-Cloud-Standards]] ← provides_architecture_framework ← [[Martin-Nash]]
+- [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Related-Security]] ← related_topic ← [[AWS-Enterprise-Landing-Zones]]
+
+## Contradictions
+- （暂无）
+
+---
+
+*最后更新: 2026-04-19*
--- a/wiki/sources/ctp-topic-30-managing-change.md
+++ b/wiki/sources/ctp-topic-30-managing-change.md
@@ -0,0 +1,56 @@
+---
+title: "CTP Topic 30 Managing Change"
+type: source
+tags: [cloud-learning, change-management, SRE]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change.md]]
+
+## Summary
+- 核心主题：云转型项目中的变更管理流程，以及 SRE 团队在变更管理中的角色
+- 问题域：IT 服务管理、变更管理流程、SRE 职责
+- 方法/机制：三种变更类型（标准变更、正常变更、紧急变更）的分类和处理流程，SRE 团队与产品团队的协作模式
+- 结论/价值：明确 SRE 角色定义和变更管理流程，确保云转型项目中各团队的有效协作
+
+## Key Claims
+- SRE 团队的核心职责是通过软件工程思维方式解决运维问题，自动化重复性工作，提高系统可靠性和可测试性
+- 变更分为三种类型：标准变更（预批准，无需 CAB）、正常变更（需 CAB 批准）、紧急变更（为缓解事故而立即执行）
+- 事件是触发警报的低级别事件，事故是超出计划外的服务中断或服务质量下降，对客户影响较大
+- SRE 团队与产品团队的协作分为三个阶段：构建和设置、早期上线支持（Early Live Support）、BAU（日常运营）
+
+## Key Quotes
+> "SRE 的核心在于自动化重复性工作，提高系统可靠性和可测试性" — Brendan Starnig
+
+> "标准变更应尽可能实现完全自动化，通过 IaC + CI/CD Pipeline" — Brendan Starnig
+
+> "事件的 CAPA（Corrective and Preventive Action）目的是从事故中提取根因并预防同类问题再次发生" — Brendan Starnig
+
+## Key Concepts
+- [[SRE]]：站点可靠性工程，将软件工程方法应用于运维问题
+- [[Change Management]]：变更管理，三种类型（标准变更、正常变更、紧急变更）
+- [[SMACs]]：Service Management Automation X，当前使用的 ITSM 工具
+- [[CAPA]]：Corrective and Preventive Action，纠正和预防措施，即 Post-mortem 回顾
+- [[SLO]]：Service Level Objective，服务等级目标
+- [[SLR]]：Service Level Requirement，服务等级需求
+- [[Early Live Support]]：Build 与 BAU 之间的过渡阶段
+
+## Key Entities
+- [[Brendan Starnig]]：SRE Function Lead, Platform Engineering，讲师
+- [[SMACs Ticket]]：内部服务管理工单系统，用于 Ticket、Incident、Change 管理
+
+## Connections
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← related_to ← [[SRE]]：AD 服务与 SRE 协作流程相关
+- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← [[Standard Change]]：IaC 变更的 Tagging 标准属于 Standard Change 范畴
+- [[ctp-topic-19-configuring-dns-within-aws-lzs]] ← relates_to ← [[SRE Support Model]]：DNS 配置与 SRE 支持模型的关系
+
+## Contradictions
+- （暂无记录）
+
+## Action Items
+- [ ] 评估现有变更流程，识别可自动化并转化为标准变更的环节
+- [ ] 明确各团队与 SRE 团队在不同阶段的交互方式和责任范围
+- [ ] 确保所有团队成员正确使用 PPM、SMACs 和 Octane 等工具
+- [ ] 完善监控覆盖，确保所有关键服务和基础设施都得到充分监控
+- [ ] 建立清晰的事件响应和升级流程
--- a/wiki/sources/ctp-topic-31-network-segregation-secure-access-aws-landing-zones.md
+++ b/wiki/sources/ctp-topic-31-network-segregation-secure-access-aws-landing-zones.md
@@ -0,0 +1,52 @@
+---
+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
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md]]
+
+## Summary
+- 核心主题：AWS Landing Zone 网络隔离与安全访问解决方案
+- 问题域：内部系统（on-prem 和 VPN 用户）可直接访问生产环境 workloads 的安全合规问题
+- 方法/机制：网络隔离（通过 Checkpoint 防火墙控制服务器间通信）+ 安全访问（通过 AWS Systems Manager (SSM) 替代 VPN）
+- 结论/价值：解决紧急安全风险，提供临时方案直到 SD-WAN 实施
+
+## Key Claims
+- 内部系统和 VPN 用户由于共享网络配置可访问 AWS 生产环境，存在安全合规风险
+- 网络隔离通过 Checkpoint 启用 SPI（Stateful Packet Inspection）功能，默认拒绝仅允许必需服务和网络段
+- SSM 通过浏览器会话或 AWS CLI 提供远程访问，用户通过扮演角色获得目标 EC2 实例的 SSM agent 访问权限
+- SSM 方案成本低、部署快，但长期目标是基础设施即代码（IaC）以减少控制台访问
+
+## 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."
+
+> "Secure access will be facilitated through AWS Systems Manager (SSM), which provides remote access via a browser-based session or AWS CLI, eliminating the need for VPN."
+
+> "The long-term goal is to move towards infrastructure as code to minimize console access and enhance security, with break-glass access reserved for emergencies."
+
+## Key Concepts
+- [[Network-Segregation]]：通过 Checkpoint 防火墙控制服务器间通信，阻断内部网络直接访问 AWS 网段
+- [[SPI-Features]]：Stateful Packet Inspection，启用默认拒绝，仅允许必需服务和网络段
+- [[SSM-Access]]：通过 AWS Systems Manager 实现安全的远程访问，替代传统 VPN
+- [[AWS-Landing-Zone]]：AWS 多账号基础架构框架，用于安全合规部署
+- [[Zero-Trust-Access]]：零信任访问模式，通过角色扮演和双因素认证实现安全访问
+- [[Break-Glass-Access]]：紧急访问，仅在紧急情况下使用，优先目标是 IaC 减少此类需求
+
+## Key Entities
+- [[AWS]]：云平台，提供 SSM、VPC 等服务
+- [[Checkpoint-Firewall]]：云环境虚拟防火墙，用于网络隔离
+
+## Connections
+- [[CTP-Topic-35-AWS-Landing-Zone-Design-Refresher]] ← related_to ← [[CTP-Topic-31-Network-Segregation]]
+- [[CTP-Topic-18-Wide-Area-Networking-in-AWS-Cloud]] ← extends ← [[CTP-Topic-31-Network-Segregation]]
+- [[Gruntwork-Landing-Zone]] ← implements ← [[AWS-Landing-Zone]]
+
+## Contradictions
+- （暂无）
--- 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,51 @@
+---
+id: ctp-topic-4-using-agile-to-run-the-cloud-transformation-program
+title: "CTP Topic 4 Using Agile to run the Cloud Transformation Program"
+type: source
+tags: [Agile, Cloud-Transformation, CTP, Scrum, Kanban]
+sources: [NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 4_ Using Agile to run the Cloud Transformation Program.mp4]
+date: 2026-04-14
+last_updated: 2026-04-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md]]
+
+## Summary
+- 核心主题：云转型计划中的敏捷实践应用
+- 问题域：如何选择和改进敏捷框架以适应云转型项目
+- 方法/机制：从 Scrum 过渡到 Kanban，最终采用混合模式
+- 结论/价值：敏捷需要根据项目特点灵活调整，混合模式可能更适合持续变化的云转型项目
+
+## Key Claims
+- Scrum 框架的问题在于冲刺期间无法接受变更，这在云转型项目中难以满足
+- Kanban 允许随时变更，专注于持续交付而非冲刺结束时发布
+- 当前混合模式结合了 Kanban 的灵活性和 Scrum 的固定仪式
+- 每日站会应该简短（15-30分钟），聚焦昨天完成、今天计划和任何阻碍
+- 回顾会议是获得快速反馈和改进开发文化的关键
+- Microsoft Planner 看板使用 Kanban 结构，包含 backlog、to do、in progress、program key decisions、icebox 等列
+
+## 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
+> "Agile is all about getting that rapid feedback to make the product and make the, you know, the development culture better."
+
+## Key Concepts
+- [[Scrum]]：两周冲刺框架，包含产品待办、冲刺计划、回顾、评审和每日站会
+- [[Kanban]]：持续流框架，允许随时变更，专注于持续交付
+- [[每日站会]]：每日Brief会议（15-30分钟），分享昨天完成、今天计划和阻碍
+- [[回顾会议]]：回顾和改进开发文化的会议，产出带负责人的行动项
+- [[Microsoft Planner]]：项目管理看板工具，使用 Kanban 结构管理需求
+
+## Key Entities
+- [[Heather Norris]]：云转型计划的项目经理，演讲者
+
+## Connections
+- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← uses ← [[Scrum]]
+- [[CTP Topic 30 Managing Change]] ← relates_to ← [[敏捷实践]]
+
+## Contradictions
+- 无
+
+## Aliases
+- CTP Topic 4
+- Using Agile to run the Cloud Transformation Program
--- a/wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md
+++ b/wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md
@@ -0,0 +1,62 @@
+---
+id: ctp-topic-41-nfrs-and-error-budgets
+title: "CTP Topic 41 NFR's and Error Budgets"
+type: source
+tags: [cloud-learning, devops, sre]
+date: 2026-04-14
+sources:
+  - raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md]]
+
+## Summary
+- 核心主题：NFR（非功能需求）与 Error Budget（错误预算）在云和敏捷开发中的应用
+- 问题域：如何平衡功能快速交付与系统可靠性要求
+- 方法/机制：SRE 实践、SLI/SLO/SLA 体系、混沌工程
+- 结论/价值：Error Budget 将失败正常化，弥合开发与运维之间的鸿沟
+
+## Key Claims
+- NFR（Non-Functional Requirements，非功能需求）是评判系统运行状况的标准，决定可用性、性能、安全等属性
+- Error Budget（错误预算）是系统在不影响客户的前提下可以不可靠的最大时间量
+- Error Budget = 1 - 可用性 SLO，例如 99.9% SLO 对应 0.1% Error Budget
+- 混沌工程（Chaos Engineering）通过故意引发故障来测试系统韧性，确保满足 NFR
+- AWS 共享责任模型下，企业必须自行架构和管理云服务以满足 NFR
+
+## Key Quotes
+> "We want to drive collaboration across our product groups and operations to ensure our obligation to our customers." — Brendan Standing
+
+> "Error budgets normalize failure as part of the development process." — Brendan Standing
+
+> "Perfect availability is 100%, and the error budget falls between the SLO and 100%." — Brendan Standing
+
+## Key Concepts
+- [[NFR（非功能需求）]]：评判系统运行状况的标准，如可用性、性能、安全性
+- [[Error Budget（错误预算）]]：系统可不可靠而不影响客户的允许时间量
+- [[SLI（服务等级指标）]]：可靠性的可量化度量指标
+- [[SLO（服务等级目标）]]：服务应该达到的性能/可靠性目标
+- [[SLA（服务等级协议）]]：客户级别的正式协议
+- [[混沌工程]]：主动引入故障测试系统韧性的实践
+- [[SRE（站点可靠性工程）]]：将软件工程方法应用于运维问题的学科
+
+## Key Entities
+- [[Brendan Standing]]：Micro Focus SRE 负责人，演讲者
+- [[AWS]]：Amazon Web Services，云服务提供商，共享责任模型
+- [[Micro Focus]]：软件公司，SRE 团队所在组织
+
+## Connections
+- [[SRE]] ← implements ← [[NFR（非功能需求）]]
+- [[SRE]] ← uses ← [[Error Budget（错误预算）]]
+- [[SLO（服务等级目标）]] ← derives ← [[Error Budget（错误预算）]]
+- [[SLI（服务等级指标）]] ← measures ← [[SLO（服务等级目标）]]
+- [[混沌工程]] ← validates ← [[NFR（非功能需求）]]
+
+## Contradictions
+- （暂无）
+
+## Notes
+- NFR Epic 目标：将 NFR 模板集成到 Sprint backlog，确保任何重大变更都考虑 NFR
+- NFR 在云端应更规范化，利用云原生服务（如 AWS Backup 定义备份策略和测试频率）
+- 监控能力对于衡量 Error Budget 是否耗尽至关重要
+- 下一步：与产品团队合作，将 NFR 集成到 backlog，制定 SLO
--- 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,42 @@
+---
+title: "CTP Topic 43 VMware Cloud on AWS"
+type: source
+tags: [VMware, AWS, Networking, Hybrid-Cloud, CTP]
+date: 2026-04-14
+sources: []
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md]]
+
+## Summary
+- 核心主题：VMware Cloud on AWS（VMC on AWS）是一项 VMware 和 AWS 联合设计的云服务，在 AWS 硬件上原生运行 vSphere 8
+- 问题域：为企业提供介于完全本地部署和纯原生云迁移之间的中间地带方案
+- 方法/机制：通过在 AWS 服务器上原生安装 VMware 虚拟化层，实现应用在本地和云端之间的秒级迁移，访问 AWS 原生服务，享受 27% 成本节省
+- 结论/价值：VMC on AWS 降低了云迁移风险，提供了熟悉的工具集和运维体验，同时具备云端弹性扩展能力
+
+## Key Claims
+- VMC on AWS 是一项 VMware 和 Amazon 联合设计的云服务，VMware 虚拟机管理程序原生运行在 AWS 硬件上，而非简单地在 AWS 上运行 VMware
+- VMC on AWS 提供与本地环境相同的工具集，使现有 VMware 技能可直接复用
+- VMC on AWS 支持通过 HCX 实现任意位置之间的 vSphere 工作负载迁移
+- VMC on AWS 提供 27% 的成本节省，相比传统云部署具有成本优势
+- VMC on AWS 基础设施基于 i3.metal 和 i3en.metal 服务器主机，构建可用区内的集群，可实现跨可用区的扩展集群
+
+## Key Quotes
+> "This is not just something where VMware showed up at Amazon and dropped off a box of CDs" — 强调 VMC 是深度集成的联合工程产品
+
+> "VMC on AWS is running vSphere 8 and provides access to AWS services with low latency" — vSphere 8 运行在 AWS 基础设施上
+
+> "The service is available across multiple regions and availability zones globally" — 全球多区域和多可用区支持
+
+## Key Entities
+
+## Key Concepts
+
+## Connections
+- [[AWS]] ← 基础设施提供商 ← [[VMware Cloud on AWS]]
+- [[VMware]] ← 联合工程设计 → [[VMware Cloud on AWS]]
+- [[Hybrid Cloud]] ← 实现方案 ← [[VMware Cloud on AWS]]
+
+## Contradictions
+- （暂无）
--- 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,53 @@
+---
+title: "CTP Topic 45 Automatic IP address allocation with IPAM"
+type: source
+tags: [AWS, IPAM, Networking, CTP]
+date: 2026-04-14
+source_file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
+---
+
+## Summary
+- 核心主题：使用 Infoblox NIOS 实现 VPC IP 地址自动化分配
+- 问题域：传统手动管理 IP 地址效率低下，需与网络团队手动协调 CIDR
+- 方法/机制：通过 Infoblox IPAM 自动查询可用 IP 块并预置 VPC，YAML 文件仅指定子网大小而非具体 IP
+- 结论/价值：减少跨团队协作，实现单一数据源，支持 VPC 销毁时自动清理 IPAM 条目
+
+## Key Claims
+- IPAM（IP 地址管理）提供集中化管理、控制、监控和分配 IP 地址空间的能力
+- 当前使用 Excel 管理 IP 地址效率低下，Infoblox NIOS 作为无缝扩展的解决方案
+- 新方案无需手动向网络团队请求 IP 地址，NIOS 自动提供下一个可用 IP 块
+- 新 YAML 文件不包含具体 CIDR 子网 IP，仅指定所需子网大小（如 /22）和父 CIDR
+- 系统向后兼容，现有使用旧 YAML 文件的 VPC 配置将继续工作
+
+## Key Quotes
+> "Managing the IP address in a spreadsheet takes time and it's not a good approach." — 描述传统 Excel 管理方式的低效性
+> "We are not asking for IP address from the network team." — 新方案的核心价值
+> "The system is backward compatible, meaning existing VPC configurations using the old YAML file will continue to work." — 向后兼容性保证
+
+## Key Concepts
+- [[IPAM]]：IP 地址管理工具，用于规划、追踪和管理 IP 地址空间
+- [[VPC]]：Virtual Private Cloud，AWS 虚拟私有云
+- [[CIDR]]：无类别域间路由，用于指定 IP 地址范围
+- Extensible Attributes：可扩展属性，用于定义云使用相关元数据（如 space owner、subnet name、compartment type）
+
+## Key Entities
+- [[Infoblox]]：企业级 DNS/DHCP 和 IPAM 解决方案提供商，提供 NIOS 设备
+- [[AWS]]：公有云平台，VPC 部署环境
+- Grid Master：IPAM 架构中的主节点
+- SRE 团队：负责 VPC 预置的团队
+- Network Team：负责计算最优 CIDR 范围的团队（旧流程）
+
+## Connections
+- [[Infoblox]] ← provides_ipam_capability ← [[VPC]]
+- SRE 团队 ← automates_vpc_provisioning ← [[IPAM]]
+- 新流程 ← eliminates_manual_coordination ← Network Team
+
+## Contradictions
+- （暂无冲突记录）
+
+## Notes
+- 视频状态：已通过 Gemini 摘要
+- 新 YAML 文件包含 business contact、engineering contact、date 字段
+- 支持指定可用区 ID 创建子网
+- 销毁 VPC 时会移除 IPAM grid 中的所有条目
+- 防止意外删除 VPC 的保护措施：Terragrant.hcl 中需要特殊标志
--- a/wiki/sources/ctp-topic-53-why-bother-with-cloud.md
+++ b/wiki/sources/ctp-topic-53-why-bother-with-cloud.md
@@ -0,0 +1,47 @@
+---
+title: "CTP Topic 53 Why bother with Cloud"
+type: source
+tags: [cloud, ctp, opentext, strategy, landing-zone]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md]]
+
+## Summary
+- 核心主题：Micro Focus 云转型计划（Cloud Transformation Program）的进展与价值
+- 问题域：企业云迁移决策、基础设施整合、成本优化
+- 方法/机制：Landing Zone 框架、标签方法论、财务管控
+- 结论/价值：云迁移带来显著成本降低和创新机会，但需克服惯性思维
+
+## Key Claims
+- Micro Focus 拥有全球最大的商业数据中心足迹，14 个数据中心近 20000 项资产
+- 从 Bublikan 迁出 3 个产品后，575 台物理服务器被 240 台虚拟服务器替代
+- 云迁移使产品团队能够更快响应客户、开拓新区域、增加收入
+- 当前 55% 的 AWS 成本发生在 Landing Zone 之外，缺乏自动化和安全管控
+
+## Key Quotes
+> "We're trying to give them the information so that they can understand how they are spending."
+
+> "The Cloud Transformation Program aims to consolidate infrastructure, reduce costs, and enable innovation across Micro Focus."
+
+## Key Concepts
+- [[Landing Zone]]：云基础架构的逻辑边界，分为 Labs、SAS、Corporate 三种类型
+- [[Cloud Transformation Program]]：Micro Focus 的云转型计划
+- [[Tagging Methodology]]：标签方法论，通过标准化元数据实现成本追踪和管理
+- [[FinOps]]：云财务运营，整合财务管理与云资源优化
+- [[CCOE]]：Cloud Center of Excellence，推动云采纳和治理的核心组织
+
+## Key Entities
+- [[OpenText]]：企业内容管理软件公司，主办 Cloud Transformation Program
+- [[AWS]]：公有云平台，CTP 的主要云服务商
+- [[SRE]]：站点可靠性工程团队，负责云平台运维
+
+## Connections
+- [[AWS]] ← provides ← [[Landing Zone]]
+- [[OpenText]] ← operates_via ← [[Cloud Transformation Program]]
+- [[CCOE]] ← governs ← [[Tagging Methodology]]
+- [[FinOps]] ← monitors ← [[AWS]]
+
+## Contradictions
+- （暂无冲突记录）
--- a/wiki/sources/ctp-topic-57-product-backlog-managing-demand.md
+++ b/wiki/sources/ctp-topic-57-product-backlog-managing-demand.md
@@ -0,0 +1,51 @@
+---
+title: "CTP Topic 57 Product backlog managing demand"
+type: source
+tags:
+  - Product-Backlog
+  - Demand-Management
+  - Agile
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand.md]]
+
+## Summary
+- 核心主题：Product Backlog（产品待办列表）管理需求
+- 问题域：云转型计划（CTP）中的需求管理与优先级排序
+- 方法/机制：通过 SMACs 提交需求、双周会议评审、20题计算器评估、Octane 入池、前置条件准备阶段
+- 结论/价值：实现需求透明度和优先级评估标准化，确保所有需求在同一标准下被审视
+
+## Key Claims
+- 需求必须通过 SMACs 提交以启动计时器和确保追踪
+- 每周双次会议评审需求的价值和优先级，计算器评估复杂度、成本和野心
+- 新团队需经过前置条件准备阶段才能进入 Octane
+- Sprint 规划通常提前 6 个迭代，50% 分配给新需求，50% 给支持工单和技术债务
+
+## Key Quotes
+> "We need a way to make sure it's transparent and we're holding everything up to the light and looking everything for the same lens as we are."
+
+> "It means that for ADM they can effectively plan all of the work that's going into their sprints with the engineers that are working solidly on their work."
+
+## Key Concepts
+- [[Product-Backlog]]：存放待开发功能的区域，高亮需求、收益和优先级
+- [[SMACs]]：Service Management Access，用于提交新需求的标准化入口
+- [[Octane]]：数字化产品管理平台，需求评估后移入为特性
+- [[前置条件阶段]]：产品团队进入企业级 Landing Zone 转型旅程的准备阶段
+- [[Sprint-规划]]：提前约 6 个迭代规划工作，50% 新需求 + 50% 支持工单/技术债务
+
+## Key Entities
+- [[Matthew-Chapman]]：需求评审会议主持人
+- [[David-Grant]]：需求评审会议参与人
+- [[Brendan]]：需求评审会议参与人
+
+## Connections
+- [[CTP]] ← manages_demand ← [[Product-Backlog]]
+- [[SMACs]] ← triggers ← [[Demand-Tracking]]
+- [[前置条件阶段]] ← precedes ← [[Octane]]
+- [[Sprint-规划]] ← includes ← [[Demand-Allocation]]
+
+## Contradictions
+- 邮件或聊天可作为初始联系方式，但 SMACs 是最可靠的追踪方式
--- a/wiki/sources/ctp-topic-6-aws-workspaces-demo.md
+++ b/wiki/sources/ctp-topic-6-aws-workspaces-demo.md
@@ -0,0 +1,44 @@
+---
+title: "CTP Topic 6 AWS Workspaces Demo"
+type: source
+tags:
+  - AWS
+  - Workspaces
+  - Demo
+  - CTP
+  - CloudLearning
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo.md]]
+
+## Summary
+- 核心主题：AWS Workspaces 远程桌面解决方案的演示与配置流程
+- 问题域：云桌面环境预配置与快速生产力工具链部署
+- 方法/机制：AWS Workspaces 提供基于浏览器或客户端访问的远程 Windows 桌面，预装 PF SSO、Terraform、TerraGrunt、Git、VS Code 等工具，目标是在申请后 30-45 分钟内运行 Terraform 计划
+- 结论/价值：通过预配置工作区实现用户快速上手，解决环境搭建耗时长的问题
+
+## Key Claims
+- AWS Workspaces 提供即用型远程桌面，可通过 Web 浏览器或客户端应用访问
+- 工作站预装 PF SSO、Terraform、TerraGrunt、Git、VS Code 等开发工具
+- 使用 Windows Server 2016 配合 Pulse UI（Amazon Linux 存在兼容性问题）
+- 用户申请后约 21 分钟可完成 TerraGrunt 计划执行
+
+## Key Quotes
+> "The goal is that within half an hour, 45 minutes of making a request for a workspace, you've run a Terra Grunt plan against a piece of infrastructure." — 演示目标
+
+> "Once logged in, users can access the AWS console using Federation, GitHub Enterprise, and generate SSH keys." — 登录后能力
+
+## Key Concepts
+- [[AWS Workspaces]]：AWS 提供的托管桌面即服务（DaaS）解决方案
+- [[TerraGrunt]]：Terraform 的包装工具，简化配置管理和远程状态
+- [[PF SSO]]：某种单点登录解决方案
+
+## Key Entities
+- [[AWS]]：云服务提供商
+- [[OpenText]]：主办本次 CTP 学习活动的公司
+
+## Connections
+- [[CTP Topic 58 AWS EC2 Image Builder]] ← uses ← [[AWS Workspaces]]
+- [[CTP Topic 26 Standard AMI – build, publish, share processes]] ← related_to ← [[AWS Workspaces]]
--- 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,40 @@
+---
+title: "CTP Topic 61 Workload VPC provision with IPAM Automation"
+type: source
+tags: [AWS, VPC, IPAM, Automation, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md]]
+
+## Summary
+- 核心主题：IPAM（IP 地址管理）与 Workload VPC 自动化 provisioning
+- 问题域：企业级 VPC IP 地址分配的手动干预问题
+- 方法/机制：Infoblox NIOS（Grid 架构）、YAML 配置文件定义 VPC 参数、Availability Zone ID（az id）代替 az name
+- 结论/价值：消除手动 IP 地址管理，减少错误，支持多 VPC 同时 provisioning，/22 及以上 CIDR 需审批
+
+## Key Claims
+- IPAM 自动化消除手动干预，减少人为错误
+- Infoblox Grid 架构防止重叠 IP 地址
+- 使用 az id 替代 az name 避免可用区命名不一致
+- /22 及以下 CIDR 块需要审批流程
+
+## 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, Principal SRE
+
+> "So we just need to put the information at the right place and everything will work."
+- Pushka, Principal SRE
+
+## Key Concepts
+- [[IPAM]]：IP 地址管理工具，用于规划、追踪和管理 IP 地址空间
+- [[VPC]]：虚拟私有云，AWS 网络隔离的基本单位
+
+## Key Entities
+- [[Infoblox]]：企业级 DNS/DHCP 和 IPAM 解决方案提供商，Grid 架构由 Houston 数据中心的主数据库管理
+
+## Connections
+- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← extends ← [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]
+- [[IPAM]] ← used_by ← [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]
+- [[Infoblox]] ← provides ← [[IPAM]]
--- 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,52 @@
+---
+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
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md]]
+
+## Summary
+- 核心主题：CTP 工作中的价值交付量化与优先级排序方法
+- 问题域：云转型中的价值评估与工作优先级排序
+- 方法/机制：加权最短作业优先（WSJF）方法、价值流分解、利益相关者分析
+- 结论/价值：通过经济价值最大化原则序列 CTP 工作，实现早期价值交付
+
+## Key Claims
+- Process（流程）是将输入转化为输出和结果的方法论步骤，由数据、资源、时间、资金和知识等输入驱动
+- Outcome（结果）可以是硬性结果（时间、成本、质量）或软性结果（健康、安全）
+- Value（价值）由客户定义，体现为公平的回报或等值 goods，涉及收入增加、成本降低、风险改善和市场规模
+- 价值流（Value Stream）是一组向客户交付产品或服务的活动，分为运营价值流（OVS）和开发价值流（DVS）
+- 加权最短作业优先（WSJF）= (业务价值 + 时间关键性 + 风险与机会) / 作业规模，用于优先级排序
+
+## Key Quotes
+> "A process is a methodical set of steps designed to achieve a specific output and outcome" — CTP 价值交付定义
+
+> "What we want to do is deliver the maximum value early back into the business for the least amount of effort." — 价值交付目标
+
+> "The goal is to sequence CTP work for maximum economic benefit" — CTP 工作优先级目标
+
+## Key Concepts
+- [[Process]]：将输入转化为输出的方法论步骤
+- [[Outcome]]：流程产生的结果，分为硬性和软性
+- [[Value]]：客户定义的monetary worth
+- [[Value Stream]]：向客户交付价值的一组活动
+- [[WSJF]]：加权最短作业优先，用于工作优先级排序
+- [[Cost of Delay]]：延迟成本，业务价值+时间关键性+风险与机会
+- [[CTP]]：Cloud Transformation Program，云转型计划
+- [[Business Value]]：业务价值量化指标
+- [[Demand Manager]]：需求经理，负责捕获业务利益
+- [[Delivery Manager]]：交付经理，负责估算工作规模
+
+## Key Entities
+- [[OpenText]]：主办 Public Cloud Learning Sessions 的企业内容管理公司
+
+## Connections
+- [[CTP]] ← depends_on ← [[Value Delivery]]
+- [[Demand Manager]] ← captures ← [[Business Value]]
+- [[WSJF]] ← prioritizes ← [[CTP Work]]
+
+## Contradictions
+- （暂无）
--- 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,52 @@
+---
+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]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md]]
+
+## Summary
+- 核心主题：将本地虚拟机迁移到 VMware Cloud on AWS 的最佳实践
+- 问题域：混合云迁移、网络连接、安全配置
+- 方法/机制：HCX（Hybrid Cloud Extender）多云管理、Direct Connect 直连、CCOE 迁移脚本
+- 结论/价值：通过 VMware Cloud 实现无缝迁移，最小化改动、降低停机时间
+
+## Key Claims
+- VMware Cloud 环境托管在 AWS infrastructure 上运行，提供 vSphere、connectivity 和 firewalls
+- 通过 Direct Connect 连接到 Frankfurt AWS region，使用虚拟 Transit Gateway 实现无缝迁移连接
+- HCX 支持每次迁移最多 200 台 VM，实现 on-premises vSphere 和 SDDC 的双向可视化管理
+- 迁移成本包括数据出站费用，SDDC 数量和 region 决定最终成本
+- 两种迁移方法：VMware Cloud UI 方法和 CCOE 团队开发的 oversell 自动化脚本
+
+## 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."
+
+> "Anything which leaves definitely attracts cost." — 数据离开云环境会产生费用
+
+> "It hardly takes a VM migration with few minutes, which will enable them operated in the cloud infrastructure."
+
+## Key Concepts
+- [[VMware-Cloud-on-AWS]]：在 AWS 硬件上原生运行 vSphere 的 VMware 云服务
+- [[HCX]]：Hybrid Cloud Extender，实现多云管理的工具
+- [[SDDC]]：Software-Defined Data Center，由 VMware 管理的集群和 ESX nodes（EC2 bare metal instances）
+- [[Direct-Connect]]：AWS 直连服务，连接本地云到 AWS region
+- [[CCOE]]：Cloud Center of Excellence，推动云采纳和治理的核心组织
+
+## Key Entities
+- [[VMware]]：云虚拟化解决方案提供商
+- [[AWS]]：公有云平台
+- [[ESX]]：VMware vSphere 虚拟化平台的 hypervisor
+
+## Connections
+- [[VMware-Cloud-on-AWS]] ← runs_on ← [[AWS]]
+- [[HCX]] ← manages ← [[SDDC]]
+- [[Direct-Connect]] ← connects ← [[VMware-Cloud-on-AWS]]
+
+## Contradictions
+- 与 [[ctp-topic-43-vmware-cloud-on-aws]] 冲突：
+  - 冲突点：该 topic 更专注于 VMware Cloud 架构，本次 topic 侧重迁移实践
+  - 当前观点：通过 HCX 实现无缝迁移，最小化改动
+  - 对方观点：VMware Cloud 架构设计和部署模式
--- 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,42 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance"
+type: source
+tags: [OpenText, DR, Recovery, BCP, SRE]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md]]
+
+## Summary
+- 核心主题：灾难恢复（DR）向恢复保障（Recovery Assurance）的演进
+- 问题域：企业级 DR 策略改进与 SRE 实践
+- 方法/机制：通过设计、软件、构建、环境四个维度构建恢复保障能力
+- 结论/价值：从被动响应式测试转向主动式恢复保障架构
+
+## Key Claims
+- DR 需要从被动响应转向Recovery Assurance的主动式架构
+- RTO（恢复时间目标）和RPO（恢复点目标）是DR策略的核心指标
+- 恢复保障应是设计原则，而非事后补救
+- SRE和可观测性工程是提升恢复能力的关键技术
+
+## Key Quotes
+> "CrowdStrike was not us, but we have had some disruptions." — Jim Rose, 提及基础设施安全事件对DR策略的影响
+
+> "Every person who is a SME on some part of this has to be involved in developing a plan." — Jim Rose, 描述DR测试的复杂性
+
+## Key Concepts
+- [[Recovery Assurance]]：恢复保障，从设计层面确保系统具备恢复能力
+- [[SRE]]：站点可靠性工程，将软件工程方法应用于运维
+- [[Observability Engineering]]：可观测性工程，通过持续监控理解系统健康状态
+
+## Key Entities
+- [[OpenText]]：企业解决方案公司，主办本次学习活动
+- [[Jim Rose]]：演讲者，DR/Recovery Assurance专家
+- [[CrowdStrike]]：安全公司，其安全事件推动了行业对DR的重视
+
+## Connections
+- [[DR]] ← evolves_to ← [[Recovery Assurance]]
+- [[RTO]] ← core_metric ← [[Recovery Assurance]]
+- [[RPO]] ← core_metric ← [[Recovery Assurance]]
+- [[SRE]] ← enables ← [[Recovery Assurance]]
--- a/wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md
@@ -0,0 +1,67 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab migration - 20240625"
+type: source
+tags:
+  - GitHub
+  - GitLab
+  - Migration
+  - OpenText
+date: 2024-06-25
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md]]
+
+## Summary
+- 核心主题：OpenText 将代码仓库从 GitHub Enterprise 迁移到 GitLab
+- 问题域：企业级源代码管理平台迁移
+- 方法/机制：self-serve 模式，团队自行定义需求并转换 CI/CD 管道
+- 结论/价值：GitHub 许可证12月底到期不再续约，GitLab 许可证覆盖8500用户，Project Thor 整合 Micro Focus 和 OpenText 工具，GitLab 作为源代码控制的集中系统
+
+## Key Claims
+- GitHub Enterprise 许可证将于12月底到期，公司决定不再续约
+- GitLab 许可证覆盖最多8500名用户
+- Project Thor 目标是将 Micro Focus 和 OpenText 工具集成，GitLab 作为集中式源代码控制系统
+- Build Hub 团队管理 GitLab 等中央工具，为软件交付管道提供支持
+- 迁移方式为 self-serve，各团队定义自身需求并规划迁移和管道转换
+
+## Key Quotes
+> "Each team will define what they have in GitHub today, how they're using it, and they will plan to move it and change their pipelines."
+
+> "The current solution that is working and is efficient and is actually reporting to scale."
+
+## Key Concepts
+- [[GitHub-Enterprise]] → [[GitLab]] 迁移的两种方式：mirroring（同步）和 shift and lift（复制代码并转换管道）
+- [[Build-Hub]]：管理 GitLab 等中央工具的团队，为软件交付管道提供支持
+- [[Project-Thor]]：整合 Micro Focus 和 OpenText 工具的项目，GitLab 作为集中式源代码控制
+- [[PHT]]：Product Hub platform，GitLab 仓库权限控制平台
+- [[Service-Account-Standard]]：服务账户必须关联到个人，密码有有效期
+
+## Key Entities
+- [[OpenText]] — 企业内容管理软件公司，主办 Public Cloud Learning Sessions
+- [[GitHub]] — 全球最大代码托管平台，Enterprise 版本许可证即将到期
+- [[GitLab]] — 代码托管和 DevOps 平台，将作为新的集中式源代码控制系统
+
+## Connections
+- [[OpenText]] ← hosts ← [[Public-Cloud-Learning-Sessions]]
+- [[GitHub-Enterprise]] → replaced_by → [[GitLab]]
+- [[Build-Hub]] ← supports ← [[Project-Thor]]
+- [[PHT]] ← controls ← [[GitLab]] permissions
+
+## Contradictions
+- （暂无）
+
+## Implementation Steps
+1. 安装 GitLab 插件
+2. 早期访问 GitLab
+3. 映射仓库到 PHT
+4. 设置服务账户
+5. 更新管道
+
+## Network Connectivity
+- GitLab proxy 位于 Brook Park，可通过 SD1 访问
+- 商业实例连接 GitLab 可能需要 GIS 团队批准例外
+
+## Migration Tracking
+- 通过 PHT 跟踪，定期向开发经理和构建倡导者更新进度
+- 规划指南：清点 GitHub 资产、识别管道、了解网络连接
--- a/wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md
@@ -0,0 +1,52 @@
+---
+title: "Public Cloud Learning Sessions (OpenText)- Product Hub (PHT) Overview and Q&A - 20240806"
+type: source
+tags:
+  - Product-Hub
+  - PHT
+  - OpenText
+  - cloud-learning
+date: 2026-04-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md]]
+
+## Summary
+- 核心主题：Product Hub (PHT) 产品层级追踪器概述与问答
+- 问题域：OpenText 云产品管理平台的产品注册、层级结构和权限管理
+- 方法/机制：通过自助服务流程请求新产品，层级结构管理（业务单元→业务线→产品），集成外部系统（PSMQ、P2M、ITLS、Backstage）
+- 结论/价值：PHT 提供统一的产品信息管理，通过标准化的产品请求流程和层级结构，实现产品元数据的集中存储和外部系统集成
+
+## Key Claims
+- Product Hub (PHT) 是产品层级追踪器，存储官方产品和部门信息（业务单元、业务线），与官方产品命名注册表中的母版产品不同
+- 产品是具有独立 CI/CD 流水线或发布周期的软件分发，如果组件需要自己的 CI/CD 流水线则应作为产品创建
+- 层级结构包括业务单元（有工程和 PM 负责人）、业务线（有所有者和 PM 负责人）、产品（由产品和开发经理管理，与母版产品关联）
+- 请求新产品是自助流程，提交后由业务线所有者审批；产品状态包括活跃、维护模式和非活跃
+- GitLab 中源仓库创建需要 24 小时才能在 PHT 中反映，空的组/仓库无法搜索
+
+## Key Quotes
+> "A product is a software distribution with its own CI/CD pipeline or release cycle. If a component needs its own cycle, like its own CI/CD pipeline or its own distribution, then we may treat that particular component or module as a product."
+
+> "Requesting for a new product is a self-serve process; after submission, it goes to LOB approval, where the line of business owner reviews it."
+
+> "Source repo creation in GitLab takes 24 hours to reflect in PhD, and empty groups/repositories cannot be searched."
+
+## Key Concepts
+- [[Product-Hub-PHT]]：Product Hub 产品层级追踪器，OpenText 产品信息管理平台
+- [[Product]]：具有独立 CI/CD 流水线或发布周期的软件分发
+- [[Component]]：没有 CI/CD 流水线的库，可能属于某个产品
+- [[Business-Unit]]：业务单元，产品层级结构的最高层
+- [[Line-of-Business]]：业务线，业务单元下的产品组织单元
+- [[Master-Product]]：母版产品，官方产品命名注册表中的产品定义
+
+## Key Entities
+- [[OpenText]]：企业内容管理软件公司，主办 Public Cloud Learning Sessions
+
+## Connections
+- [[Product]] ← has_parent ← [[Master-Product]]
+- [[Product]] ← belongs_to ← [[Line-of-Business]]
+- [[Line-of-Business]] ← belongs_to ← [[Business-Unit]]
+- [[Product]] ← integrates_with ← [[PSMQ]]
+- [[Product]] ← integrates_with ← [[P2M]]
+- [[Product]] ← integrates_with ← [[ITLS]]
--- a/wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md
@@ -0,0 +1,50 @@
+---
+title: "Public Cloud Learning Sessions - OpenText Tagging Standard V2 - 20250429 170111 Meeting Recording"
+type: source
+tags:
+  - OpenText
+  - Tagging-Standard
+  - Cloud-DevOps
+  - Meeting
+date: 2026-04-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md]]
+
+## Summary
+- 核心主题：OpenText Tagging Standard V2（标签标准 V2 版），为云资源、容器镜像和 Kubernetes 对象定义标准化标签
+- 问题域：云资源标签标准化、成本优化、风险降低、自动化效率提升
+- 方法/机制：
+  - 使用小写下划线语法（如 `ot_business_unit`）
+  - 前缀标签确保语义明确（OT_ 用于云标签，app.opentext.com 用于 Kubernetes 标签，com.opentext.image 用于容器镜像标签）
+  - 明确 customer（客户）和 tenant（租户）概念
+  - 区分 environment（OpenText 视角）和 service instance（客户视角）
+- 结论/价值：帮助组织实现成本优化、风险降低和自动化效率提升，当前 OpenText 管理约 3,500 个云账号，跨越 48 种 landing zone 类型
+
+## Key Claims
+- 标签标准三大驱动因素：通过成本优化省钱、通过轻松识别技术联系人降低风险、通过标签作为过滤器和选择器提高自动化效率
+- 标签标准范围包括：云账号、云资源（计算、存储、网络）、Kubernetes 对象（namespace、pod、deployment、service、configmap）、容器镜像
+- 最佳实践：使用 IaC（如 Terraform）自动化标签创建和维护、创建检查和报告检测缺失标签、避免在标签中存储敏感数据
+
+## Key Quotes
+> "It is about taking resources and you will learn more in the presentation about what kinds of object and what exactly and so on."
+> "The standard helps with cost allocation, improved security and compliance, cloud service delivery, and resource organization."
+
+## Key Concepts
+- [[Tagging-Methodology]]：标签方法论，通过为资源定义标准化的元数据实现自动化管理和安全策略执行
+- [[Terraform]]：基础设施即代码工具，用于自动化标签创建和维护
+- [[Kubernetes]]：开源容器编排平台，本次标准的应用对象之一
+
+## Key Entities
+- [[OpenText]]：企业内容管理软件公司，主办本次学习会议
+- Martin Rosler：本次会议演讲者，介绍 OpenText Tagging Standard V2
+- Phenops：标签标准发起团队，2023 年启动该标准
+
+## Connections
+- [[OpenText]] ← hosts ← [[Public Cloud Learning Sessions]]
+- [[Tagging-Methodology]] ← applies_to ← [[Terraform]]
+- [[Tagging-Methodology]] ← applies_to ← [[Kubernetes]]
+
+## Contradictions
+- （暂无）
--- a/wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md
+++ b/wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md
@@ -0,0 +1,48 @@
+---
+title: "Public Cloud Learning Sessions (OpenText)- Thor Platform & Flows - 20241210 160056-Meeting Recording"
+type: source
+tags: [Thor, Platform, OpenText, DevOps, SRE]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md]]
+
+## Summary
+- 核心主题：Project Thor 平台架构与供应链数据流
+- 问题域：OpenText 云平台标准化、工具整合、供应链安全
+- 方法/机制：五支柱框架（敏捷周期管理、产品发布治理、Developer Portal、Security Governance、Build Hub）、GitLab + Artifactory 工具整合、代码签名流程
+- 结论/价值：统一工具链标准、提升开发者体验、增强供应链安全
+
+## Key Claims
+- Project Thor 的五大支柱：敏捷和正确的周期管理、产品和发布治理、Developer Portal（Backstage）、Security 作为治理、Build Hub
+- "供应链的核心是我们的源代码，我们的 IP，托管在 GitLab 中"
+- 当前状态：源代码从 GitLab 流经制造流程（build farms）到 Artifactory，最终到达客户环境
+
+## Key Quotes
+> "We are trying to standardize in GitLab, Artifactory, PMS and UCMDB are backend services that started to grow and will grow further for supply chain security."
+
+## Key Concepts
+- [[Project Thor]]：OpenText 云平台标准化项目，五大支柱框架
+- [[GitLab]]：源代码管理和 CI/CD 平台
+- [[Artifactory]]：制品仓库管理
+- [[Source Code Supply Chain]]：源代码供应链，从 GitLab 到 Artifactory 的流程
+- [[GitLab Proxy]]：GitLab 代理，用于工具间数据流
+- [[GitLab Geo]]：GitLab 地理复制，用于业务连续性
+- [[Code Signing]]：代码签名，确保软件完整性
+- [[Developer Portal]]：开发者门户，基于 Backstage
+- [[Build Hub]]：构建中心，统一构建环境
+- [[Supply Chain Security]]：供应链安全
+
+## Key Entities
+- [[Arnold Dacan]]：OpenText 技术专家，Thor Platform 演讲者
+
+## Connections
+- [[GitLab]] ← hosts ← [[Source Code Supply Chain]]
+- [[Artifactory]] ← stores ← [[Build Hub]]
+- [[Project Thor]] ← implements ← [[Supply Chain Security]]
+
+## Geographical Distribution
+- 主要工具、源代码和构建资源位于 Brook Park
+- Sacramento 用于灾难恢复和业务连续性
+- 区分传统 Micro Focus 网络和 OpenText 网络
--- a/wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md
+++ b/wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md
@@ -0,0 +1,101 @@
+---
+title: "Public Cloud Learning Sessions - Tagging Standards for all hyperscalers - 20240123 160135 Meeting Recording"
+type: source
+tags:
+  - Tagging-Standard
+  - FinOps
+  - Cloud-Governance
+  - OpenText
+date: 2026-04-14
+---
+
+## Source File
+
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md]]
+
+## Summary
+
+- **核心主题**：建立跨 AWS、GCP、Azure 三大云服务商的统一标签标准
+- **问题域**：云成本优化、资源治理、FinOps 实践
+- **方法/机制**：通过标准化标签（Tag）实现成本分配、资源优化、责任追踪和分类管理
+- **结论/价值**：将云浪费从行业平均 30% 降至 15%，预计年省 2500 万美元，同时提升可持续性
+
+## Key Claims
+
+- 统一标签标准是云成本优化的基础，可避免临时标签映射的混乱管理
+- 标签需在计费控制台启用后才会包含在成本和使用报告中
+- 采用 GCP 的限制性字符集（小写、数字、连字符、下划线）作为最低通用标准
+- 标签前缀使用 OT_ 进行区分，例外情况包括 environment、BU、cost center
+- 99% 资源标签合规率可通过 SCP（Service Control Policies）或标签策略强制执行
+
+## Key Quotes
+
+> "If we can agree the tags that need to go here, we don't have to do this and we can get out the analysis results." — 统一标签的价值在于避免临时映射
+
+> "Typically what you do is almost every module that you've got inside Terraform, there is a tags parameter that you could use." — Terraform 中设置标签的标准做法
+
+## Key Concepts
+
+- [[Tagging-Methodology]]：通过标准化标签实现资源元数据管理的方法论
+- [[FinOps]]：云财务运营，整合财务管理与资源优化
+- [[Service-Control-Policies]]：AWS 组织策略，用于强制标签合规
+
+## Key Entities
+
+- [[Tom-Bice]]：OpenText 财务组织负责人，标签标准制定发起人
+- [[Phenops]]：OpenText 团队，2023 年发起标签标准化工作
+- [[OpenText]]：企业内容管理软件公司，主办 Public Cloud Learning Sessions
+- [[AWS]]：Amazon Web Services，三大云服务商之一
+- [[GCP]]：Google Cloud Platform，三大云服务商之一
+- [[Azure]]：Microsoft Azure，三大云服务商之一
+- [[Terraform]]：基础设施即代码工具，用于标签设置
+
+## Connections
+
+- [[Tom-Bice]] ← leads ← [[Tagging-Standard]]
+- [[Phenops]] ← initiated ← [[Tagging-Standard]]
+- [[OpenText]] ← hosts ← [[Public-Cloud-Learning-Sessions]]
+- [[Tagging-Standard]] → enables → [[FinOps]]
+- [[Tagging-Standard]] → enforces → [[Service-Control-Policies]]
+
+## Contradictions
+
+- 无明显冲突
+
+---
+
+## 附录：标签标准详情
+
+### 目标
+
+- 支持关键业务报表
+- 适用于所有云服务商的所有账户
+- 实际可行，快速实施
+
+### 术语
+
+- Tag（AWS/Azure）：标签
+- Label（Google Cloud）：标签
+
+### 建议标签
+
+| 标签名称 | 描述 |
+|---------|------|
+| business_unit (BU) | 业务单元 |
+| OT_technical_contact | 技术联系人 |
+| cost_center | 成本中心 |
+| customer | 客户 |
+| tenant | 租户 |
+| environment | 环境（生产/实验室等） |
+| OT_master_product | 主产品 |
+| custom_fields | 自定义字段 |
+| platform | 平台 |
+| cost_type | 成本类型 |
+| customer_data | 数据分类 |
+
+### 非必需标签
+
+- account：可直接获取
+- region：可直接获取
+- hyperscaler：可直接获取
+- resource_name：可直接获取