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

wiki/overview.md

@@ -43,6 +43,8 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter
 
 **[[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 项目管理知识体系。
 
+**[[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]**（Public Cloud Learning Sessions 20240109）：业务分析（Business Analysis）基础技能与三大核心技法——T型技能模型、BOSCARD框架、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集。业务分析将业务需求与技术变更解决方案对齐，涵盖IT系统变更、流程变更、培训和角色转换。BOSCARD（Background/Objectives/Scope/Constraints/Assumptions/Risks/Roles/Deliverables）通过澄清背景、目标、范围等8个维度定义复杂新工作，"早期锁定范围无价"。干系人轮盘从客户出发顺时针识别所有项目干系人。INVEST原则（Independent/Negotiable/Valuable/Estimable/Small/Testable）用于检查需求质量。属 [[Product-Backlog]] 和 [[Demand-Management]] 的前置技法层，与 [[ctp-topic-4]]（敏捷实践）和 [[ctp-topic-57]]（需求管理）共同构成云转型计划的完整方法论（规划→需求→执行）。
+
 **[[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 知识体系。
@@ -51,6 +53,10 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter
 
 **[[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-6-aws-workspaces-demo]]**（CTP Topic 6）：AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面（Windows Server 2016），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号，接收注册码和用户名后登录，可立即访问 AWS Console（Federation）和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行，达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（基础架构）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 流程）共同构成完整的"架构→交付→使用"链路。
+
+**[[public-cloud-learning-sessions-aws-end-user-compute-services-20240430]]**（Public Cloud Learning Sessions，Christian O'Donough 主讲）：AWS 终端用户计算（EUC）服务全景介绍——覆盖四大服务：① **Workspaces**（全持久虚拟桌面，适合知识工作者一对一实例管理）；② **AppStream 2.0**（选择持久/非持久应用流，多租户模式降低成本，适合实验室/培训/堡垒主机）；③ **Workspace Core**（提供 VDI 基础设施 API，支持 Horizon View、Citrix 等第三方集成）；④ **Workspace Web**（低成本安全浏览器）。核心选型原则：需要完整桌面 → Workspaces；非持久桌面/应用流 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 Active Directory 集成、加密、IAM 配置文件、SAML 认证和多因素认证。属 [[AWS-Landing-Zone]] 用户端计算层的理论基础，与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）共同构成完整的 EUC 知识体系。
+
 **[[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 的设计演进脉络。
 
 **[[ctp-topic-1-gruntwork-landing-zone-architecture]]**（CTP Topic 1）：Gruntwork AWS Landing Zone 架构基础——核心概念：参考架构（Reference Architecture）是包含核心账户 Shared/Logs/Security 和工作负载账户 Prod/Stage/Dev 的最佳实践起点；Landing Zone 基于 Gruntwork 仓库但由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User），通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流。属整个 CTP Landing Zone 系列的基础入门篇。
@@ -67,12 +73,14 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter
 
 **[[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]]
+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]], [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]], [[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]], [[NFR（非功能需求）]], [[Error Budget（错误预算）]], [[Chaos Engineering]], [[高可用（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-53-why-bother-with-cloud]]**（CTP Topic 53）：云转型商业价值论证——用数据说明"为何要上云"。Micro Focus 拥有全球最大的商业数据中心足迹——14个数据中心、近20,000台资产；尽管年营收25亿美元，但 VMware 足迹比规模大8倍的公司还大，硬件利用率不足40%。三个产品从 Bublikan 迁出后下线575台物理服务器，云端仅需240台虚拟服务器替代；Redding 退出时40%的应用直接关机，Houston 有89个空机架和360台未使用服务器。核心理念：**云迁移不仅是成本节约，更是创新催化剂**——赋能产品增强、改善灾备、开拓新市场。当前55%的 AWS 成本发生在 Landing Zone 之外，亟需治理。属 [[Cloud Transformation Programme]] 的战略论证层，与 [[ctp-topic-43-vmware-cloud-on-aws]]（混合云中间路线）共同构成完整的云迁移决策框架。
+
 **[[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]] 存储层架构的核心补充。
@@ -91,16 +99,32 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast
 
 **[[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-5-aws-identity-and-access-management-iam]]**（CTP Topic 5）：AWS IAM 核心组件与联邦访问机制——涵盖 IAM Dashboard 四大资源（用户、组、客户托管策略、角色、身份提供商）；联邦用户通过 Active Directory 组映射到 IAM 角色实现单点登录；`accounts.json` 位于每个 Landing Zone 根目录，包含账户号列表；IAM 用户主要用于服务账号，人工用户优先使用联邦访问；角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联；策略分为 AWS 托管和客户托管两种，Terraform 模块可定义 IAM 角色（假设角色策略 + 内联策略块）；PFSSO 工具实现 CLI 联邦访问；最小权限原则贯穿始终。属 [[AWS-Landing-Zone]] 身份与访问管理层的入门基础，与 [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]（AD 集成）、[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]（AD 登录）、[[learning-sessions-identity-governance-vsm-replacement]]（身份治理）共同构成完整的身份治理知识体系。
+
+**[[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]**（CTP Topic 11，Niranjan 主讲）：Jenkins 与企业 Active Directory (AD) 的集成，以及 Terraform 代码的自动化质量检查——核心内容：① Jenkins 与 SW Infra AD 的安全域集成，用户入离职通过 AD 账号实现自动化管理，无需手动维护本地用户；② 通过 AD 组策略实现 RBAC 精细化权限控制（只读、读写、流水线创建权限）；③ pre-commit 框架集成 terraform fmt（格式统一）、TFLint（逻辑验证）、Checkov（安全扫描）三款工具，在代码提交阶段自动嵌入安全检查；④ CI/CD 流水线分层治理模式：Commit 阶段仅触发自动化检查 → PR 阶段触发检查+terraform plan → Master 分支人工审核后执行 terraform apply。核心理念：**"左移"（Shift-Left）将安全问题从生产阶段提前到开发早期**，通过分层治理实现基础设施即代码的安全性与稳定性。属 [[AWS-Landing-Zone]] 身份与访问管理层的实践延伸，与 [[ctp-topic-5-aws-identity-and-access-management-iam]]（AWS IAM 联邦访问）共同构成身份治理知识体系。
+
+**[[public-cloud-learning-sessions-opentext-tagging-standard-v2]]**（Learning Sessions，Martin Rosler 主讲）：OpenText 云资源标签标准 v2——三大驱动力（成本优化/风险降低/自动化效率）；覆盖云账户、云资源（compute/storage/network）、Kubernetes 对象（namespaces/pods/deployments/services/config maps）和容器镜像；通过标准化前缀（OT\_ / app.opentext.com / com.opentext.image）确保跨平台标签语义无歧义；最佳实践：IaC 自动化替代手动打标、禁止标签存储敏感数据、对频繁变更标签谨慎处理。属 [[AWS-Tagging-Standards]]（CTP Topic 28）同一标签治理领域的补充——前者定义 AWS 内部规范，后者定义 OpenText 跨云统一标准，两者互补。
+
+**[[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]**（Learning Sessions）：OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab——Project Thor 整合 Micro Focus 和 OpenText 工具链，GitLab 作为源代码控制黄金标准；GitHub 许可证12月底到期不续；各团队自主盘点资产、识别流水线并规划迁移（self-serve 模式），Build Hub 提供辅助支持；两种迁移方案（镜像同步 / 搬移重构）；迁移完成标准：代码迁移 + 流水线转型 + PHT 更新；网络连通性挑战通过 Brook Park GitLab 代理解决。属 [[DevOps Culture]] 中企业级工具链标准化转型的典型案例。
+
+**[[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]**（Learning Sessions，Arnold Dacan 主讲）：Project Thor 平台架构与数据流设计详解——五大支柱框架（敏捷周期治理、产品发布治理、开发者门户 Backstage、安全与治理、Build Hub）；核心数据流：源代码流（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境；地理分布：工具链主站点 Brook Park + 灾备站点 Sacramento；标准化目标：统一 GitLab/Artifactory/UCMDB 工具链，夯实供应链安全基础。属 [[DevOps Culture]] 企业级工具链标准化与供应链安全的深度补充，与 GitHub→GitLab 迁移文档共同构成 Project Thor 知识体系。
+
 **[[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-41-nfrs-and-error-budgets]]**（CTP Topic 41）：NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——Micro Focus SRE 负责人 Brendan Standing 主讲。核心内容：①NFR 定义——评判系统运行的准则（可用性、性能、安全性、可扩展性），云环境下应更具规范性，充分利用云原生服务（如 AWS Backup 定时备份 + IaC 基础设施代码化）；②NFR Epic 模板——将 NFR 集成到 Sprint Backlog，确保任何重大变更都考虑非功能需求；③AWS 共享责任模型——云提供商负责基础设施，公司在云中架构和管理服务以满足 NFR；④Error Budget 机制——Error Budget = 1 - 可用性 SLO（如 99.9% SLO → 0.1% Error Budget），用于衡量系统在影响客户前可承受的不可靠程度，驱动开发和运维决策；⑤SLR/SLO/SLA 三层体系——SLR 是可量化的可靠性指标，SLO 定义服务应如何表现，SLA 是客户级别协议；⑥混沌工程——主动注入故障测试系统韧性，确保 NFR 得到满足。核心理念：**Error Budget 将失败归一化为开发流程的一部分，弥合了开发与运维之间的文化鸿沟**。属 [[AWS-Landing-Zone]] SRE 可靠性工程层的核心补充，与 [[ctp-topic-30-managing-change]]（SRE 变更管理）和 [[ctp-topic-72-enterprise-dr-strategy-aws-backup]]（DR 可用性目标）共同构成完整的 SRE 知识体系。
+
+**[[ctp-topic-57-product-backlog-managing-demand]]**（CTP Topic 57）：CTP 产品待办列表（Backlog）需求管理完整管道——①需求提交（通过 SMACs 启动计时器和追踪）→ ②双周评审会议（Matthew Chapman/David Grant/Brendan）评估理解度、价值和优先级，约20题评估问卷判断简洁性、成本和野心程度 → ③Octane 特性化（带任务列表）→ ④Sprint 规划（提前6个 Sprint，50% 新需求 / 50% 支持+技术债）→ ⑤Prerequisite Phase（新产品组入职：介绍会议→AWS账户创建→解决方案设计→GitHub仓库→防火墙标签，产品团队约2小时，1-2周）→ ⑥SRE 构建账号并交接（提供控制台/GitHub访问详情）→ ⑦2周 Hyper Care 支持。现有产品组通过 SMACs/邮件/Teams 请求支持，Teams 频道连接产品组、SRE工程师、解决方案架构师和交付经理。核心理念：**透明化需求管道，确保所有工作以同一标准评估**。属 [[AWS-Landing-Zone]] 需求治理层的核心补充，与 [[ctp-topic-20-program-demand-process-flow]]（Gate Process 和 POC 入职）、[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]（敏捷实践）、[[ctp-topic-30-managing-change]]（变更管理与 SRE 协作）共同构成完整的 CTP 治理知识体系。
+
 **[[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-23-introduction-to-the-technical-architecture-team-and-function]]**（CTP Topic 23）：技术架构团队职能与云转型价值——Martin Nash（技术架构经理）主讲。核心内容：①组织变革背景——PSTC 与 IT 部门整合至 CIO 统一领导下，实现两个大型组织的深度融合；②云优先策略——除非数据主权、合规性或极端成本原因必须保留在本地，否则所有新业务优先上云；③三层架构分工——EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理；④技术领域划分——将技术栈划分为身份认证、网络、Microsoft 堆栈等领域，每个领域由首席架构师负责其生命周期与路线图；⑤主动规划转型——通过制定 12-24 个月技术路线图，从被动响应转向预测性规划，帮助业务部门规避风险、优化预算、提升交付速度。属 [[AWS-Landing-Zone]] 架构治理层的核心补充，与 [[ctp-topic-47-enterprise-architecture-cloud-standards]]（EA 云标准）共同构成企业架构知识体系。
+
 **[[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 知识体系。
 
 **[[Install WSL]]**（[[install-wsl]]）：微软官方 WSL 完整安装指南——`wsl --install` 一键安装（Windows 10/11 Build 19041+），支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装，`wsl.exe --set-default-version` 切换 WSL1/WSL2；离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform；运行入口推荐 Windows Terminal（含多标签、自定义快捷键）。[[Install WSL]] 与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装问题，后者解决网络配置问题。
@@ -373,6 +397,8 @@ Key concepts: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Suff
 - **[[Amazon RDS]]** — 关系型数据库服务，计算与存储分离（EBS），支持 Multi-AZ 部署
 - **[[Amazon Aurora]]** — 云原生关系型数据库，6 副本跨 3 AZ 共享集群卷架构
 - [[Greg Klau]] — CTP Topic 66 讲师，主讲 PostgreSQL RDS vs Aurora 差异对比
+- [[Martin Rosler]] — Learning Sessions 讲师，主讲 OpenText Tagging Standard v2，聚焦云资源标签标准化
+- [[Phenops-Team]] — OpenText 内部团队，2023 年发起云资源标签标准化项目
 - **[[Google-Cloud]]** — Google Cloud Platform
 - [[Btop++]] — TUI系统监控器，作者首选
 - [[Htop]] — 轻量级TUI进程监控器