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

2026-04-24 08:02:47 +08:00
parent cc8ebc60e3
commit 7cecf10c79
28 changed files with 2350 additions and 29 deletions
--- a/wiki/concepts/Enterprise-Architecture.md
+++ b/wiki/concepts/Enterprise-Architecture.md
@@ -0,0 +1,56 @@
+---
+title: "Enterprise Architecture (EA)"
+type: concept
+tags: [Architecture, Cloud, Strategy, Enterprise]
+sources: [ctp-topic-23-introduction-to-the-technical-architecture-team-and-function, ctp-topic-47-enterprise-architecture-cloud-standards]
+last_updated: 2026-04-14
+---
+
+# Enterprise Architecture (EA)
+
+## Definition
+**Enterprise Architecture (EA)** 是架构体系中的最高层，负责将业务目标转化为技术原则和标准，确保技术投资与商业战略保持一致。
+
+## Responsibilities
+
+| Responsibility | Description |
+|----------------|-------------|
+| Business Strategy Alignment | 将业务目标映射到技术投资 |
+| Technology Standards | 制定和维护技术标准和最佳实践 |
+| Governance | 确保技术决策符合组织目标 |
+| Roadmap Planning | 制定长期（12-24个月）技术路线图 |
+
+## Relationship with Other Architecture Layers
+
+```
+Enterprise Architecture (EA)
+         │
+         ├── Business Strategy Alignment
+         │
+         ▼
+Solution Architecture (SA) ◄── Middle Layer
+         │
+         └── Solution Design
+         │
+         ▼
+Technical Architecture (TA) ◄── Implementation Layer
+```
+
+## Key Activities
+
+1. **Strategic Planning**: 制定技术愿景和路线图
+2. **Standard Setting**: 定义技术标准和框架
+3. **Portfolio Management**: 管理技术资产组合
+4. **Stakeholder Communication**: 向业务利益相关者传达技术战略
+
+## Related Concepts
+
+- [[Solution Architecture (SA)]]
+- [[Technical Architecture (TA)]]
+- [[Cloud-First Strategy]]
+- [[Landing Zone Architecture]]
+
+## Sources
+
+- [[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]
+- [[ctp-topic-47-enterprise-architecture-cloud-standards]]
--- a/wiki/concepts/Identity-Governance.md
+++ b/wiki/concepts/Identity-Governance.md
@@ -0,0 +1,69 @@
+---
+title: "Identity Governance"
+type: concept
+tags:
+  - Identity-Governance
+  - IAM
+  - Compliance
+  - Access-Management
+sources:
+  - learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re
+last_updated: 2023-11-28
+---
+
+## Identity Governance
+
+身份治理（Identity Governance）是一个用于高效管理数字身份、最小化风险并保持合规的框架。
+
+## Core Framework
+
+身份治理围绕三个核心问题展开：
+
+1. **谁当前有访问权限？** — 当前权限状态审计（Who currently has access to our systems?）
+2. **谁应该有访问权限？** — 权限需求评估（Who should have access?）
+3. **如何执行访问？** — 访问控制机制（How is the access being done?）
+
+## Components
+
+### Identity Management（身份管理）
+- 数字身份的创建、维护和生命周期管理
+- 用户、组和角色的定义
+
+### Access Management（访问管理）
+- 控制谁可以访问哪些资源
+- 认证（Authentication）和授权（Authorization）
+
+### Identity Auditing（身份审计）
+- 权限变更追踪
+- 合规性报告
+- 异常检测
+
+## Identity Governance vs IAM
+
+| 维度 | 身份治理（IG） | 身份与访问管理（IAM） |
+|------|----------------|----------------------|
+| 焦点 | 治理、合规、策略 | 操作、技术实现 |
+| 问题 | 谁应该有权访问？ | 如何实现访问控制？ |
+| 受众 | 审计员、合规官、业务经理 | IT 管理员、安全工程师 |
+| 工具 | 审批工作流、策略引擎 | 目录服务、SSO、MFA |
+
+## Use Cases
+
+- **内部用户治理**：员工入职/转岗/离职的权限生命周期管理
+- **外部用户治理**：承包商、合作伙伴的临时权限管理
+- **合规审计**：SOX、HIPAA、GDPR 等合规要求的身份报告
+- **权限优化**：发现并清理过度授权（Privilege Creep）
+
+## Implementation Example
+
+Micro Focus IGA 的实现架构：
+```
+User → IGA Portal (申请) → 审批工作流 → AD 组更新 → AWS IAM → 云资源访问
+```
+
+## Related Concepts
+
+- [[Micro-Focus-IGA]]：身份治理的具体产品实现
+- [[AWS-Identity-Center]]：AWS 云平台的身份治理服务
+- [[Federated-Access]]：联合身份认证
+- [[Service-Control-Policies-SCPs]]：AWS 组织层面的权限控制策略
--- a/wiki/concepts/Solution-Architecture.md
+++ b/wiki/concepts/Solution-Architecture.md
@@ -0,0 +1,53 @@
+---
+title: "Solution Architecture (SA)"
+type: concept
+tags: [Architecture, Cloud, Solution, Middleware]
+sources: [ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]
+last_updated: 2026-04-14
+---
+
+# Solution Architecture (SA)
+
+## Definition
+**Solution Architecture (SA)** 是架构体系的中间层，专注于特定项目或服务的优化实施，确保系统组件间的高效协作。
+
+## Responsibilities
+
+| Responsibility | Description |
+|----------------|-------------|
+| Project-Specific Design | 为特定项目设计解决方案架构 |
+| Middleware Optimization | 优化中间件和服务集成 |
+| Component Coordination | 协调各系统组件的交互 |
+| Technical Guidance | 为开发团队提供技术指导 |
+
+## Relationship with Other Architecture Layers
+
+```
+Enterprise Architecture (EA) ◄── Strategy Layer
+         │
+         ▼
+Solution Architecture (SA) ◄── Middle Layer
+         │
+         ├── Middleware & Services
+         │
+         ▼
+Technical Architecture (TA) ◄── Implementation Layer
+```
+
+## Key Activities
+
+1. **Requirements Analysis**: 分析业务需求和技术约束
+2. **Architecture Design**: 设计解决方案架构
+3. **Technology Selection**: 选择合适的技术和工具
+4. **Integration Planning**: 规划系统集成方案
+
+## Related Concepts
+
+- [[Enterprise Architecture (EA)]]
+- [[Technical Architecture (TA)]]
+- [[Multi-Database-Architecture]]
+- [[CI-CD-Pipeline]]
+
+## Sources
+
+- [[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]
--- a/wiki/concepts/Technical-Architecture.md
+++ b/wiki/concepts/Technical-Architecture.md
@@ -0,0 +1,65 @@
+---
+title: "Technical Architecture (TA)"
+type: concept
+tags: [Architecture, Cloud, Infrastructure, Technical]
+sources: [ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]
+last_updated: 2026-04-14
+---
+
+# Technical Architecture (TA)
+
+## Definition
+**Technical Architecture (TA)** 是最贴近技术的架构层，负责具体基础设施的设计、实施治理以及技术路线图的维护。
+
+## Responsibilities
+
+| Responsibility | Description |
+|----------------|-------------|
+| Infrastructure Design | 设计底层基础设施架构 |
+| Governance | 实施技术标准和治理 |
+| Roadmap Maintenance | 维护技术路线图（12-24个月） |
+| Domain Ownership | 负责特定技术领域的所有权 |
+
+## Technical Domains
+
+| Domain | Description |
+|--------|-------------|
+| Identity & Access | 身份认证和访问管理 |
+| Networking | 网络架构和安全 |
+| Microsoft Stack | Microsoft 技术栈集成 |
+| Security | 安全控制和合规 |
+
+## Relationship with Other Architecture Layers
+
+```
+Enterprise Architecture (EA) ◄── Strategy Layer
+         │
+         ▼
+Solution Architecture (SA) ◄── Middle Layer
+         │
+         ▼
+Technical Architecture (TA) ◄── Implementation Layer
+         │
+         ├── Infrastructure Design
+         ├── Governance
+         └── Technical Roadmaps
+```
+
+## Key Activities
+
+1. **Infrastructure Governance**: 确保基础设施符合标准
+2. **Landing Zone Maintenance**: 维护 AWS Enterprise Landing Zones
+3. **Technical Roadmapping**: 制定和维护技术路线图
+4. **Domain Leadership**: 领导特定技术领域的长期发展
+
+## Related Concepts
+
+- [[Enterprise Architecture (EA)]]
+- [[Solution Architecture (SA)]]
+- [[Cloud-First Strategy]]
+- [[AWS-Tagging-Standards]]
+- [[Service-Control-Policies-SCPs]]
+
+## Sources
+
+- [[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]
--- a/wiki/entities/DXC-VSM.md
+++ b/wiki/entities/DXC-VSM.md
@@ -0,0 +1,32 @@
+---
+title: "DXC VSM"
+type: entity
+tags:
+  - Identity-Governance
+  - IAM
+  - CTP
+sources:
+  - learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re
+last_updated: 2023-11-28
+---
+
+## DXC VSM
+
+DXC Virtual SM（VSM）是一款 DXC 提供的身份治理工具，将被 Micro Focus IGA 替换。
+
+## Description
+
+DXC Virtual SM（VSM）是 DXC Technology 提供的虚拟服务管理（Virtual Service Management）工具，用于身份治理场景。VSM 在 Micro Focus 环境中原用于管理 AD 组和工作流，提供权限审批和访问审计能力。
+
+## Replacement Plan
+
+VSM 将被 Micro Focus IGA 全面替换：
+- **替换策略**：保持原有架构不变，IGA 接入 Coptum 域而非原 DXC 域
+- **验证阶段**：POC（概念验证）正在进行，以验证替换架构和审批流程
+- **目标**：实现无缝过渡，确保权限治理能力不中断
+
+## Aliases
+- VSM
+- Virtual SM
+- DXC Virtual Service Management
+- DXC Virtual Service Manager
--- a/wiki/entities/Martin-Nash.md
+++ b/wiki/entities/Martin-Nash.md
@@ -0,0 +1,39 @@
+---
+title: "Martin Nash"
+type: entity
+tags: [Person, Technical Architecture, Cloud Transformation]
+sources: [ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]
+last_updated: 2026-04-14
+---
+
+# Martin Nash
+
+## Role
+**Technical Architecture Manager**（技术架构经理）
+
+## Organization
+[[Cloud Transformation Office]] — 云转型办公室
+
+## Responsibilities
+- 领导技术架构团队
+- 维护 AWS Enterprise Landing Zones
+- 制定技术路线图（12-24个月）
+- 推动云优先策略落地
+
+## Key Contributions
+- 主讲 CTP Topic 23：技术架构团队职能介绍
+- 推动 PSTC 与 IT 部门整合至 CIO 统一领导
+- 倡导从被动响应转向主动规划
+
+## Related People
+- [[Brendan Starnig]] — SRE Function Lead
+- [[Heather Norris]] — CTP Topic 4 主讲人
+
+## Related Concepts
+- [[Technical Architecture Team]]
+- [[Enterprise Architecture (EA)]]
+- [[Solution Architecture (SA)]]
+- [[Technical Architecture (TA)]]
+
+## Sources
+- [[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]
--- a/wiki/entities/Micro-Focus-IGA.md
+++ b/wiki/entities/Micro-Focus-IGA.md
@@ -0,0 +1,48 @@
+---
+title: "Micro Focus IGA"
+type: entity
+tags:
+  - Identity-Governance
+  - IAM
+  - CTP
+sources:
+  - learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re
+last_updated: 2023-11-28
+---
+
+## Micro Focus IGA
+
+Micro Focus 身份治理与管理（Identity Governance and Administration）工具。
+
+## Description
+
+Micro Focus IGA 是企业级身份治理平台，用于管理数字身份的访问权限、最小化风险并保持合规。IGA 通过资源工作流（workflow）控制权限的审批、撤销和监控，支持内部用户和外部用户（含承包商）的有时限访问权。
+
+## Key Capabilities
+
+- **权限治理**：通过 Active Directory 组管理角色映射，管控组的成员关系和访问审批工作流
+- **工作流引擎**：支持权限申请→审批→自动授权的完整流程
+- **云集成**：通过 AWS Identity Center + IAM 提供云资源访问控制
+- **认证桥梁**：配合 Azure AD Domain Services 实现跨域身份认证
+- **时间限制访问**：适合承包商和临时用户的权限生命周期管理
+- **监控与审计**：记录所有身份变更和访问事件
+
+## Architecture
+
+```
+User → IGA Portal → AD Groups (role mapping) → AWS Identity Center → IAM → AWS Resources
+         ↑                              ↑
+         └── Azure AD Domain Services (auth bridge)
+```
+
+## VSM Replacement
+
+Micro Focus IGA 将替换 DXC 提供的 Virtual SM（VSM）工具。替换策略：
+- 保持原有架构设计不变
+- 将连接从 DXC 域迁移至 Coptum 域
+- POC 正在进行以验证架构和流程
+
+## Aliases
+- IGA
+- Identity Governance and Administration
+- Micro Focus Identity Governance
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,23 @@
 - [Overview](overview.md) — living synthesis

 ## Sources
+- [2026-04-14] [CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge Manager](sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md) — OBM AWS 监控架构，IAM Role 跨账户 CloudWatch 采集，无需被监控账户安装代理
+- [2026-04-23] [CTP Topic 11 AD Integration and Login using AD Accounts](sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md)
+- [2026-04-23] [CTP Topic 5 - AWS Identity and Access Management (IAM)](sources/ctp-topic-5-aws-identity-and-access-management-iam.md)
+- [2026-04-23] [Learning Sessions Identity Governance VSM Replacement - 20231128](sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md)
+- [2026-04-23] [Public Cloud Learning Sessions - AWS End User Compute Services - 20240430](sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md)
+- [2026-04-23] [Public Cloud Learning Sessions- Applicable Business Analysis Techniques - 20240109](sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md)
+- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806](sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md)
+- [2026-04-23] [Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123](sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md)
+- [2026-04-23] [CTP Topic 23 Introduction to the Technical Architecture Team and Function](sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md)
+- [2026-04-23] [CTP Topic 57 Product backlog managing demand](sources/ctp-topic-57-product-backlog-managing-demand.md)
+- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows](sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md)
+- [2026-04-23] [CTP Topic 6 AWS Workspaces Demo](sources/ctp-topic-6-aws-workspaces-demo.md)
+- [2026-04-23] [CTP Topic 53 Why bother with Cloud](sources/ctp-topic-53-why-bother-with-cloud.md)
+- [2026-04-23] [Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration](sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md)
+- [2026-04-23] [Public Cloud Learning Sessions - OpenText Tagging Standard v2 - 20250429](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md)
+- [2026-04-23] [CTP Topic 41 NFR's and Error Budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md)
+- [2026-04-23] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md)
 - [2026-04-23] [CTP Topic 20 Program demand process flow and PoC onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md)
 - [2026-04-23] [CTP Topic 4 Using Agile to Run the Cloud Transformation Programme](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md)
 - [2026-04-23] [CTP Topic 65 Tracing the Value Delivered in Cloud Transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md)
@@ -28,7 +45,7 @@
 - [2026-04-23] [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md)
 - [2026-04-23] [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md)
 - [2026-04-23] [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md)
- [2026-04-14] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md)
+- [2026-04-23] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md)
 - [2026-04-23] [CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme](sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md)
 - [2026-04-23] [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md)
 - [2026-04-23] [CTP Topic 47 Enterprise Architecture Cloud Standards](sources/ctp-topic-47-enterprise-architecture-cloud-standards.md)
@@ -398,21 +415,6 @@
 - [2026-04-19] [ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana](sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md) — (expected: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md — source missing)
 - [2026-04-19] [public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks](sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md) — (expected: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md — source missing)
 - [2026-04-19] [ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid](sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md) — (expected: wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md — source missing)
- [2026-04-19] [ctp-topic-11-ad-integration-and-login-using-ad-accounts](sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md) — (expected: wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md — source missing)
- [2026-04-19] [ctp-topic-5-aws-identity-and-access-management-iam](sources/ctp-topic-5-aws-identity-and-access-management-iam.md) — (expected: wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md — source missing)
- [2026-04-19] [learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re](sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md) — (expected: wiki/sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md — source missing)
- [2026-04-19] [public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee](sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md) — (expected: wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md — source missing)
- [2026-04-19] [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109](sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md) — (expected: wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md — source missing)
- [2026-04-19] [public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806](sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md — source missing)
- [2026-04-19] [public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1](sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md) — (expected: wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md — source missing)
- [2026-04-19] [ctp-topic-23-introduction-to-the-technical-architecture-team-and-function](sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md) — (expected: wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md — source missing)
- [2026-04-19] [ctp-topic-57-product-backlog-managing-demand](sources/ctp-topic-57-product-backlog-managing-demand.md) — (expected: wiki/sources/ctp-topic-57-product-backlog-managing-demand.md — source missing)
- [2026-04-19] [public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet](sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md — source missing)
- [2026-04-19] [ctp-topic-6-aws-workspaces-demo](sources/ctp-topic-6-aws-workspaces-demo.md) — (expected: wiki/sources/ctp-topic-6-aws-workspaces-demo.md — source missing)
- [2026-04-19] [ctp-topic-53-why-bother-with-cloud](sources/ctp-topic-53-why-bother-with-cloud.md) — (expected: wiki/sources/ctp-topic-53-why-bother-with-cloud.md — source missing)
- [2026-04-19] [public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20](sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md — source missing)
- [2026-04-19] [public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md — source missing)
- [2026-04-19] [ctp-topic-41-nfrs-and-error-budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md) — (expected: wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md — source missing)
 - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
 - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
 - [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
@@ -608,6 +610,7 @@
 - [Docker卷](entities/Docker卷.md)
 - [DORA-Metrics](entities/DORA-Metrics.md)
 - [DracoVibeCoding](entities/DracoVibeCoding.md)
+- [DXC-VSM](entities/DXC-VSM.md)
 - [EESJGong](entities/EESJGong.md)
 - [fireworks-tech-graph](entities/fireworks-tech-graph.md)
 - [Flux](entities/Flux.md)
@@ -651,10 +654,12 @@
 - [Mac-Mini-M4](entities/Mac-Mini-M4.md)
 - [Manus](entities/Manus.md)
 - [MariaDB](entities/MariaDB.md)
+- [Martin-Nash](entities/Martin-Nash.md)
 - [MCP（Model Context Protocol）](entities/MCP（Model Context Protocol）.md)
 - [Mem0](entities/Mem0.md)
 - [Memsearch](entities/Memsearch.md)
 - [MerlinClash插件](entities/MerlinClash插件.md)
+- [Micro-Focus-IGA](entities/Micro-Focus-IGA.md)
 - [Microsoft-Planner](entities/Microsoft-Planner.md)
 - [Midjourney](entities/Midjourney.md)
 - [Milvus](entities/Milvus.md)
@@ -890,6 +895,7 @@
 - [EFS-vs-EBS](concepts/EFS-vs-EBS.md)
 - [Email-Triage](concepts/Email-Triage.md)
 - [Emergency-Change](concepts/Emergency-Change.md)
+- [Enterprise-Architecture](concepts/Enterprise-Architecture.md)
 - [Error-Accountability](concepts/Error-Accountability.md)
 - [Error-Budget](concepts/Error-Budget.md)
 - [Error-Surface-vs-Root-Cause](concepts/Error-Surface-vs-Root-Cause.md)
@@ -937,6 +943,7 @@
 - [IAST](concepts/IAST.md)
 - [Idea-Density](concepts/Idea-Density.md)
 - [Idea-Museum](concepts/Idea-Museum.md)
+- [Identity-Governance](concepts/Identity-Governance.md)
 - [IDENTITY.md](concepts/IDENTITY.md.md)
 - [Ikigai框架](concepts/Ikigai框架.md)
 - [Immutable-Infrastructure](concepts/Immutable-Infrastructure.md)
@@ -1094,6 +1101,7 @@
 - [Socket-登录](concepts/Socket-登录.md)
 - [SOCKS5代理](concepts/SOCKS5代理.md)
 - [Software-Assurance-Maturity-Model](concepts/Software-Assurance-Maturity-Model.md)
+- [Solution-Architecture](concepts/Solution-Architecture.md)
 - [SOUL.md](concepts/SOUL.md.md)
 - [Source-Grounding](concepts/Source-Grounding.md)
 - [Split](concepts/Split.md)
@@ -1114,6 +1122,7 @@
 - [TaskAutomation](concepts/TaskAutomation.md)
 - [Taylorism](concepts/Taylorism.md)
 - [TCP隧道](concepts/TCP隧道.md)
+- [Technical-Architecture](concepts/Technical-Architecture.md)
 - [Telegram-Trigger](concepts/Telegram-Trigger.md)
 - [Telephony-Integration](concepts/Telephony-Integration.md)
 - [Terraform-Modules](concepts/Terraform-Modules.md)
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,3 +1,182 @@
+## [2026-04-25] ingest | CTP Topic 11 AD Integration and Login using AD Accounts
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md
+- Status: ✅ 成功摄入
+- Summary: Jenkins 与 SW Infra AD 安全域集成，实现基于 AD 账号的统一身份认证与自动化用户管理（入离职无需手动维护本地用户）；通过 AD 组策略实现 RBAC 精细化权限控制（只读/读写/流水线创建）；pre-commit 框架集成 terraform fmt/TFLint/Checkov 三款工具在代码提交阶段嵌入自动化安全检查；CI/CD 流水线分层治理模式（Commit 检查 → PR 检查+plan → Master 人工审核后 apply），核心理念为"左移"（Shift-Left）将安全问题提前到开发早期。
+- Concepts identified: [[Active Directory Integration]], [[RBAC (Role-Based Access Control)]], [[Pre-commit Framework]], [[Terraform Fmt]], [[TFLint]], [[Checkov]], [[Shift-Left Security]], [[CI/CD Pipeline Governance]]（均以 wikilink 形式记录于 Source page；各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面）
+- Entities identified: [[Niranjan]]（仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page）
+- Source page: wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md）
+  - index.md 更新：新增 CTP Topic 11 条目于 Sources 节顶部
+  - overview.md 更新：新增 CTP Topic 11 详细条目于身份治理知识体系段落
+  - Contradictions 记录：与 Atlantis（ctp-topic-32）关于 terraform apply 审批权的差异已记录
+
+## [2026-04-24] ingest | CTP Topic 5 - AWS Identity and Access Management (IAM)
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-5-aws-identity-and-access-management-iam.md
+- Status: ✅ 成功摄入
+- Summary: AWS IAM 核心组件与联邦访问机制——IAM Dashboard 四大资源（用户、组、客户托管策略、角色、身份提供商）；联邦用户通过 Active Directory 组映射到 IAM 角色；accounts.json 位于 Landing Zone 根目录；IAM 用户主要用于服务账号，人工用户优先使用联邦访问；角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联；策略分为 AWS 托管和客户托管，Terraform 模块可定义 IAM 角色；PFSSO 工具实现 CLI 联邦访问；最小权限原则贯穿始终。
+- Concepts identified: [[IAM（身份和访问管理）]], [[Federation（联邦身份）]], [[Least Privilege（最小权限）]], [[IAM Role（IAM 角色）]], [[IAM Policy（IAM 策略）]], [[Managed Policy vs Inline Policy]], [[Cross-Account Role Assumption]], [[PFSSO]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值，暂不创建独立页面）
+- Entities identified: [[accounts.json]], [[VSM]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值）
+- Source page: wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md）
+  - index.md 更新：替换原有缺失条目为完整条目（日期 2026-04-24）
+  - overview.md 更新：新增 CTP Topic 5 条目于身份治理知识体系段落
+
+## [2026-04-24] ingest | Public Cloud Learning Sessions - AWS End User Compute Services - 20240430
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md
+- Status: ✅ 成功摄入
+- Summary: AWS EUC 服务全景介绍——覆盖 Workspaces（全持久虚拟桌面）、AppStream 2.0（选择持久/非持久应用流，多租户降本）、Workspace Core（第三方 VDI 集成）、Workspace Web（低成本安全浏览器）四大服务。选型原则：知识工作者完整桌面 → Workspaces；实验室/培训/非持久 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 AD 集成、加密、IAM 配置文件、SAML 认证、多因素认证。
+- Concepts identified: [[Amazon-Workspaces]], [[AppStream-2.0]], [[AWS-End-User-Computing]], [[Virtual-Desktop-Infrastructure]], [[WSP-Protocol]], [[BYOD]], [[VDI]], [[SAML-Authentication]], [[VPC-Interface-Endpoints]]（均以 wikilink 形式记录于 Source page；各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面）
+- Entities identified: [[Christian-O'Donough]]（仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page）
+- Source page: wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md）
+  - index.md 更新：在 Sources 节顶部新增条目（日期 2026-04-24）
+  - overview.md 更新：在 ctp-topic-6-aws-workspaces-demo 之后新增摘要段落；与 [[ctp-topic-6-aws-workspaces-demo]] 建立关联关系
+  - Connections 已建立：与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）、[[AWS-Landing-Zone]]（VPC 架构）建立 depends_on 关系
+  - 冲突检测：无已知冲突内容
+
+## [2026-04-30] ingest | Public Cloud Learning Sessions - Applicable Business Analysis Techniques - 20240109
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md
+- Status: ✅ 成功摄入
+- Summary: 业务分析（Business Analysis）基础技能与三大核心技法——T型技能模型（连接业务与技术）、BOSCARD框架（复杂新工作定义）、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集。INVEST原则检查需求质量，SAFe框架补充Features/Capabilities/NFR。核心理念：业务分析将业务需求与技术变更解决方案对齐，帮助定义企业架构中哪些变更是有益的。
+- Concepts identified: [[Business-Analysis]], [[T-Shaped-Skills]], [[BOSCARD]], [[Stakeholder-Wheel]], [[Requirements-Gathering]], [[INVEST]], [[SAFe]], [[RACI]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值，暂不创建独立页面）
+- Entities identified: [[BCS]], [[IIBA]], [[OpenText]]（均仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page）
+- Source page: wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2024-01-09，添加摘要）
+  - overview.md 更新：在 Cloud Transformation & DevOps 部分新增摘要段落（置于 ctp-topic-4 之后）；Key Concepts 新增 Business-Analysis、T-Shaped-Skills、BOSCARD、Stakeholder-Wheel、Requirements-Gathering、INVEST、SAFe
+  - Connections 已建立：与 ctp-topic-4（敏捷实践）、ctp-topic-57（需求管理）、ctp-topic-20（需求流程）、ctp-topic-41（NFR）建立 related_to 关系
+  - 冲突检测：与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 互补而非冲突——Topic 4 提供敏捷持续流动实践框架，本视频提供需求定义前置技法，构成云转型计划完整方法论（规划→需求→执行）
+
+## [2026-04-14] ingest | CTP Topic 23 Introduction to the Technical Architecture Team and Function
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md
+- Status: ✅ 成功摄入
+- Summary: Martin Nash（技术架构经理）介绍技术架构团队的核心职能、组织架构及在云转型中的价值。核心主题：从被动响应转向主动规划。团队推行"云优先"策略，维护 AWS Enterprise Landing Zones。三层架构分工：EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理。通过划分"技术领域"并由首席架构师负责，制定 12-24 个月前瞻性路线图。
+- Concepts created: [[Enterprise-Architecture]], [[Solution-Architecture]], [[Technical-Architecture]]（均已创建独立页面）
+- Entities created: [[Martin-Nash]]（Technical Architecture Manager，已创建独立页面）
+- Source page: wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md
+- Notes:
+  - 新增 1 个 Source Page
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要）
+  - overview.md 更新：在 CTP Topics 部分添加 Topic 23 摘要条目（位于 Topic 47 和 Topic 72 之间）
+  - 新增 3 个 Concept 页面：Enterprise-Architecture.md, Solution-Architecture.md, Technical-Architecture.md
+  - 新增 1 个 Entity 页面：Martin-Nash.md
+  - Key Concepts 新增：[[Cloud-First Strategy]], [[AWS Enterprise Landing Zones]], [[Technical Domains]], [[Enterprise Architecture (EA)]], [[Solution Architecture (SA)]], [[Technical Architecture (TA)]], [[Roadmaps]], [[ITIL Alignment]]
+  - 无冲突内容
+
+## [2026-04-25] ingest | CTP Topic 57 Product backlog managing demand
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand.md
+- Status: ✅ 成功摄入
+- Summary: CTP 产品待办列表（Backlog）需求管理完整管道——SMACs提交→双周评审（20题问卷）→Octane特性化→Sprint规划（50%新需求/50%支持+技术债）→Prerequisite Phase→SRE构建账号→2周Hyper Care。核心理念：透明化需求管道，确保所有工作以同一标准评估。
+- Concepts identified: [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Sprint-Planning]], [[Octane]]（均以 wikilink 形式记录于 Source page）
+- Entities identified: [[Matthew Chapman]], [[David Grant]], [[Brendan Starnig]], [[ADM]], [[ITOM]], [[PCG]], [[SRE]]（均以 wikilink 形式记录于 Source page；Matthew Chapman/David Grant 仅出现1-2次，未达 ≥2 阈值，暂不创建独立 Entity 页面）
+- Source page: wiki/sources/ctp-topic-57-product-backlog-managing-demand.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-57-product-backlog-managing-demand.md）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要）
+  - overview.md 更新：在 CTP Topics 部分添加 Topic 57 摘要条目（位于 Topic 41 和 Topic 65 之间）；Key concepts 新增 [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]]
+  - Connections 已建立：与 CTP Topic 20（需求流程）、CTP Topic 4（敏捷实践）、CTP Topic 30（变更管理）建立 related_to 关系
+  - 无冲突内容
+
+## [2026-04-25] ingest | Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md
+- Status: ✅ 成功摄入
+- Summary: Arnold Dacan 详解 Project Thor 平台架构与数据流——五大支柱框架（敏捷周期治理、产品发布治理、开发者门户 Backstage、安全治理、Build Hub）；核心数据流：源代码（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境；地理分布：主站点 Brook Park + 灾备站点 Sacramento；标准化目标：统一 GitLab/Artifactory/UCMDB 工具链，夯实供应链安全基础。
+- Concepts identified: Project Thor, Supply Chain Security, Build Hub, GitLab Proxy, GitLab Geo, Code Signing（均以 wikilink 形式记录于 Source page，暂不创建独立 Concept 页面）
+- Entities identified: Arnold Dacan（仅出现1次，未达 ≥2 阈值，以 wikilink 形式记录于 Source page）；GitLab/Artifactory/Backstage/UCMDB（通用工具名称，不创建独立 Entity 页面）
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md）
+  - index.md 更新：替换预期占位符为正式条目（添加摘要）
+  - overview.md 更新：在 GitHub→GitLab 迁移条目后新增 Thor Platform & Flows 摘要条目
+  - Connections 已建立：与 GitHub→GitLab 迁移文档建立 extends 关系；与 CTP Topic 21 建立 related_to 关系
+  - 无冲突内容
+
+## [2026-04-25] ingest | CTP Topic 6 AWS Workspaces Demo
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo.md
+- Status: ✅ 成功摄入
+- Summary: AWS Workspaces 虚拟桌面演示——Windows Server 2016 托管桌面，预装 PFSSO/Terraform/TerraGrunt/Git/VS Code；21分钟完成 TerraGrunt Plan；通过 Federation 访问 AWS Console，GitHub Enterprise 登录（已过期，应为 GitLab）
+- Concepts identified: [[AWS Workspaces]], [[Terraform]], [[TerraGrunt]], [[PFSSO]], [[AWS Federation]]（均已存在于 Wiki 或通过 Source page 内 wikilink 引用，暂不创建独立页面）
+- Entities identified: [[Naga]]（仅出现1次，未达 ≥2 阈值，以 wikilink 形式记录于 Source page）
+- Source page: wiki/sources/ctp-topic-6-aws-workspaces-demo.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-6-aws-workspaces-demo.md）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要）
+  - overview.md 更新：在 Cloud Transformation & DevOps 部分新增 Topic 6 摘要条目
+  - Contradiction 已记录：与 GitHub→GitLab 迁移文档冲突（视频录制时仍使用 GitHub Enterprise，当前已被 GitLab 替代）
+
+## [2026-04-25] ingest | CTP Topic 53 Why bother with Cloud
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md
+- Status: ✅ 成功摄入
+- Summary: Micro Focus 云转型计划商业价值论证——14个数据中心近20,000台资产，年营收25亿美元但VMware利用率不足40%；三个产品从Bublikan迁出后下线575台物理服务器，云端仅需240台虚拟服务器；Redding退出时40%应用直接关机；当前55% AWS成本发生在LZ之外。云迁移不仅是成本节约，更是创新催化剂。
+- Concepts identified: Cloud Transformation Programme, Landing Zone (Labs/SAS/Corporate), AWS Account Tagging Framework, Enterprise Platform, Multi-Cloud Strategy（均已在 overview.md 中以 wikilink 关联，暂不创建独立 Concept 页面）
+- Entities identified: Micro Focus, ELT, Bublikan, Redding, Houston, Dart, CCOE, SRE（均已在 overview.md 中以 wikilink 关联，暂不创建独立 Entity 页面）
+- Source page: wiki/sources/ctp-topic-53-why-bother-with-cloud.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-53-why-bother-with-cloud.md）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要）
+  - overview.md 更新：在 Cloud Transformation & DevOps 部分添加 Topic 53 摘要条目
+  - Contradiction 已记录：与 ctp-topic-43-vmware-cloud-on-aws 的观点张力（完全迁移 vs 混合云中间路线）
+
+## [2026-04-24] ingest | Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md
+- Status: ✅ 成功摄入
+- Summary: OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab——Project Thor 整合工具链，GitLab 作为源代码控制黄金标准；GitHub 许可证12月底到期不续；各团队自服务模式规划迁移；两种迁移方案（镜像同步 / 搬移重构）；PHT 跟踪进度；网络挑战通过 Brook Park GitLab 代理解决。
+- Concepts identified: Project Thor（企业工具链整合）, Build Hub（中心工具支持团队）, Self-Serve Migration（自服务迁移模式）, Mirroring（镜像同步迁移）, Shift and Lift（搬移重构迁移）, Service Account Standard（服务账号标准）
+- Entities identified: OpenText, GitHub Enterprise, GitLab, Build Hub, PHT（均未达 ≥2 次阈值，暂不创建独立页面，以 wikilink 关联）
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-24）
+  - overview.md 更新：新增摘要段落（置于 tagging-standard-v2 之后，ctp-topic-28 之前）
+  - 冲突检测：未发现与其他 Wiki 页面的矛盾冲突
+
+## [2026-04-29] ingest | Public Cloud Learning Sessions - OpenText Tagging Standard v2
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md
+- Status: ✅ 成功摄入
+- Summary: OpenText 云资源标签标准 v2，Martin Rosler 主讲——三大驱动力（成本优化/风险降低/自动化效率）；覆盖云账户、云资源、Kubernetes 对象和容器镜像；标准化前缀（OT\_/app.opentext.com/com.opentext.image）确保跨平台语义无歧义；最佳实践：IaC 自动化、禁止标签存敏感数据。
+- Concepts identified: Cloud-Cost-Optimization（成本优化）, Tag-Standardization（标签标准化）, Kubernetes-Labeling（Kubernetes 标签）, Container-Image-Tagging（容器镜像标签）, IaC-Tagging-Automation（IaC 标签自动化）
+- Entities identified: Martin-Rosler（讲师，出现 1 次，未达 ≥2 次阈值，以 wikilink 关联）, Phenops-Team（发起团队，出现 1 次，未达 ≥2 次阈值，以 wikilink 关联）
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md
+- Notes:
+  - 新增 1 个 Source Page（替换 index.md 占位符条目，日期修正为 2026-04-14）
+  - overview.md 新增摘要段落（置于 ctp-topic-17 之后，ctp-topic-28 之前）；Key Entities 新增 Martin Rosler 和 Phenops-Team
+  - 冲突检测：与 [[ctp-topic-28-aws-tag-validation-tool]] 无矛盾——标签标准定义「应该怎么标」，验证工具发现「谁没标好」，两者互补
+  - Terraform/Kubernetes/Container-Images 已在 Key Concepts 中存在，以 wikilink 关联
+
+
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md
+- Status: ✅ 成功摄入
+- Summary: NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——Brendan Standing（Head of SRE）主讲。核心：NFR Epic 模板将 NFR 集成到 Sprint Backlog；AWS 共享责任模型；Error Budget = 1 - SLO，量化系统可容忍的不可靠程度；SLR/SLO/SLA 三层体系；混沌工程主动注入故障验证韧性。核心理念：Error Budget 将失败归一化为开发流程的一部分，弥合开发与运维的文化鸿沟。
+- Concepts identified: NFR（非功能需求）, Error Budget（错误预算）, Chaos Engineering
+- Entities identified: Brendan-Standing, AWS, Micro Focus（各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面）
+- Source page: wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md
+- Notes:
+  - 新增 1 个 Source Page（wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md）
+  - NFR/Error Budget/Chaos Engineering 以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
+  - Brendan-Standing 以 wikilink 形式建立关联，暂不创建独立页面（仅出现 1 次，未达 ≥2 次阈值）
+  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
+  - overview.md 更新：新增 CTP Topic 41 摘要段落（置于 ctp-topic-30 之后，ctp-topic-65 之前）；Key Concepts 新增 NFR（非功能需求）、Error Budget（错误预算）、Chaos Engineering
+  - 冲突检测：与 [[ctp-topic-30-managing-change]] 在 SRE 职责范围上存在视角差异——Topic 30 强调变更管理，Topic 41 强调可靠性工程，两者互补而非矛盾，已记录于 Source Page Contradictions 节
+
+## [2026-04-28] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
+- Status: ✅ 成功摄入
+- Summary: AWS Landing Zone 部署数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心：OU+SCP 分层治理、标签即凭证（替代 IP 规则）、Checkpoint 有序层防火墙（地理→类型→BU→产品→环境→角色）、Inline 层账号号父子规则。标签缺失/篡改触发 SCP 拒绝策略，确保合规。
+- Concepts identified: Service-Control-Policies-SCPs, Checkpoint-Firewall, AWS-Landing-Zone, Tag-Based-Security, OU-Layered-Security
+- Entities identified: Steve-Jarman, Pradeep, Checkpoint, AWS-Organizations
+- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
+- Notes:
+  - 新增 1 个 Source Page（替换 2 个占位符条目）
+  - 5 个 Concepts 以 wikilink 形式建立关联，暂不创建独立页面（Service-Control-Policies-SCPs/Checkpoint 已存在于 entities/；其余各仅出现 1-2 次，未达 ≥2 次阈值）
+  - 4 个 Entities 以 wikilink 形式建立关联，暂不创建独立页面（Checkpoint 已存在于 entities/；Steve-Jarman/Pradeep/AWS-Organizations 各仅出现 1-2 次，未达 ≥2 次阈值）
+  - index.md 更新：修正日期为 2026-04-14，移除重复占位符条目（line 416）
+  - overview.md 更新：修正 CTP Topic 10 段落的 wikilink 指向新 source page；Key Concepts 新增 3 个概念（Service-Control-Policies-SCPs/OU-Layered-Security/Tag-Based-Security）
+  - 冲突检测：与 [[ctp-topic-28-aws-tag-validation-tool]] 在 SCP 标签强制能力边界上存在视角差异——Topic 10 认为 SCP 可「阻止不合规资源创建」，Topic 28 认为「无法修复存量资源」。两者互补：SCP 负责预防（准入控制），Tag Validation Tool 负责发现（存量审计）
+
 ## [2026-04-27] ingest | CTP Topic 20 Program demand process flow and PoC onboarding
 - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
 - Status: ✅ 成功摄入
@@ -1869,3 +2048,45 @@
  - index.md 更新：Sources 节新增条目（置顶于 CTP Topic 34 之前），移除旧 "source missing" 标记
  - 冲突检测：无冲突
  - 属 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系
+
+## [2026-04-24] ingest | Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md
+- Status: ✅ 成功摄入
+- Summary: OpenText 跨 AWS/Azure/GCP 的统一标签标准，目标将云浪费从 30% 降至 15%，预计年节省 2500 万美元。标准采用 OT_ 前缀标签、GCP 限制性字符集作为最低通用标准，通过 Terraform 默认标签注入和 SCP 强制执行实现合规化。
+- Concepts referenced: [[FinOps]], [[Service-Control-Policies-SCPs]], [[Tag-Based-Security]], [[Terraform-Tagging]], [[Multi-Cloud-Governance]]（均已在其他页面定义，无需新建）
+- Entities referenced: [[Tom Bice]]（仅出现 1 次，不满足 ≥2 次建页条件，未创建独立页面）
+- Source page: wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md
+- Notes:
+  - 新增 1 个 Source Page
+  - 无新增 Concept/Entity 页面
+  - index.md 更新：移除 "source missing" 标记，添加正式条目
+  - 冲突检测：无冲突
+  - 属 [[public-cloud-learning-sessions-opentext-tagging-standard-v2]]（v2 扩展 v1，覆盖 K8s 和容器镜像标签）、[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（基于标签的安全控制机制）、[[ctp-topic-28-aws-tag-validation-tool]]（标签合规审计）共同构成完整的标签治理知识体系
+
+## [2026-04-25] ingest | Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md
+- Status: ✅ 成功摄入
+- Summary: OpenText Product Hub（PhD/PHT）产品层次结构追踪器功能概述——三层层级（业务单元→业务线→产品）、自助服务新建流程、与 Jira/Value Edge/PSMQ/ITLS/OSS 等外部系统集成、Source Repo 和 Artifact Repo 权限管理。
+- Concepts created: [[Product Hub (PhD)]]（已引用）
+- Entities created: 无（OpenText 相关 Entity 仅出现 1 次，不满足 ≥2 次建页条件）
+- Source page: wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md
+- Notes:
+  - 新增 1 个 Source Page
+  - 无新增 Concept/Entity 页面
+  - index.md 更新：移除 "source missing" 标记，添加正式条目
+  - 冲突检测：无冲突
+
+## [2026-04-30] ingest | Learning Sessions Identity Governance VSM Replacement - 20231128
+- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md
+- Status: ✅ 成功摄入
+- Summary: 身份治理（Identity Governance）框架与 VSM→Micro Focus IGA 替换计划——身份治理三问：谁当前有访问/谁该访问/如何访问；Micro Focus IGA 通过 AD 组工作流管控权限审批，配合 AWS Identity Center + IAM 提供云资源访问；VSM 将被 IGA 全面替换，保持原架构但改接 Coptum 域，POC 正在进行。
+- Concepts created: [[Identity-Governance]]
+- Entities created: [[Micro-Focus-IGA]], [[DXC-VSM]]
+- Source page: wiki/sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md
+- Notes:
+  - 新增 1 个 Source Page
+  - 新增 1 个 Concept 页面（wiki/concepts/Identity-Governance.md）
+  - 新增 2 个 Entity 页面（wiki/entities/Micro-Focus-IGA.md, wiki/entities/DXC-VSM.md）
+  - index.md 更新：移除 "source missing" 标记，添加正式条目；在 Entities 和 Concepts 节添加新页面
+  - overview.md 新增条目，位于 CTP Topic 17（AD 集成）之后
+  - 冲突检测：无已知冲突内容
--- a/wiki/overview.md
+++ b/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进程监控器
--- a/wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md
+++ b/wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md
@@ -0,0 +1,77 @@
+---
+title: "CTP Topic 11 AD Integration and Login using AD Accounts"
+type: source
+tags:
+  - AWS
+  - AD
+  - IAM
+  - SSO
+  - CTP
+  - Jenkins
+  - RBAC
+  - Pre-commit
+  - Terraform
+  - IaC
+  - DevSecOps
+sources: []
+last_updated: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+
+## Summary（用中文描述）
+- 核心主题：Jenkins 与企业 Active Directory (AD) 的集成，以及 Terraform 代码的自动化质量检查
+- 问题域：企业级 CI/CD 系统的身份认证管理与基础设施代码安全治理
+- 方法/机制：
+  - Jenkins Security Realm 与 SW Infra AD 集成，实现基于 AD 账号的统一身份认证与自动化用户管理
+  - 通过 AD 组策略实现 RBAC（基于角色的访问控制），精细化管理 Jenkins 权限（只读/读写/流水线创建）
+  - pre-commit 框架集成 terraform fmt、TFLint、Checkov 三款工具，在代码提交阶段嵌入自动化安全检查
+  - CI/CD 流水线分层治理：Commit 阶段检查 → PR 阶段 plan → Master 分支人工审核后 apply
+- 结论/价值：告别手动创建本地用户，实现"入离职账号自动化管理"；通过"左移"策略在开发早期发现并修复基础设施代码的安全问题
+
+## Key Claims（用中文描述）
+- Jenkins 与 AD 集成后，用户入离职可通过 AD 账号实现自动化管理，无需手动维护本地用户账户
+- 通过 AD 组策略可将用户映射为不同角色（只读、读写、流水线创建），实现基于 AD 的 RBAC 权限控制
+- pre-commit 框架可在功能分支提交时自动触发 terraform fmt（格式统一）、TFLint（逻辑验证）、Checkov（安全扫描），防止"坏代码"进入生产环境
+- "左移"（Shift-Left）治理模式将安全问题从生产阶段提前到开发阶段，通过分层 CI/CD 流水线实现渐进式质量门禁
+
+## Key Quotes
+> "通过 AD 集成，我们告别了过去手动创建本地用户的繁琐流程，实现了基于 AD 账号的自动登录。" — Niranjan
+
+> "terraform fmt 用于统一代码格式，TFLint 用于验证配置逻辑与参数完整性，而 Checkov 则负责静态安全分析。" — Niranjan
+
+> "在功能分支的每次提交时仅触发自动化检查；在 PR 阶段触发检查与 terraform plan；只有在代码合并至 Master 分支并经过人工审核后，才会执行最终的 terraform apply。" — Niranjan
+
+## Key Concepts
+- [[Active Directory Integration]]：将 Jenkins 的安全域与企业活动目录关联，实现用户身份的统一认证与自动化管理
+- [[RBAC (Role-Based Access Control)]]：基于角色的访问控制，通过 AD 组策略决定用户在 Jenkins 中拥有的具体操作权限
+- [[Pre-commit Framework]]：一个用于管理和维护多语言预提交钩子的框架，旨在代码提交至仓库前识别简单问题
+- [[Terraform Fmt]]：Terraform 内置的格式化工具，用于将配置文件重写为符合官方规范的标准格式
+- [[TFLint]]：一种针对 Terraform 的静态分析工具，用于检查代码中的人为错误、过时语法及缺失的参数
+- [[Checkov]]：一种静态代码分析工具，专门用于扫描基础设施即代码 (IaC) 中的安全性与合规性配置错误
+- [[Shift-Left Security]]：将安全检查从生产阶段提前到开发早期的实践，通过 CI/CD 流水线分层实现
+- [[CI/CD Pipeline Governance]]：CI/CD 流水线的分层治理模式——提交检查 → PR 检查+plan → 人工审核+apply
+
+## Key Entities
+- [[Niranjan]]：CTP Topic 11 主讲人，DevOps Cloud Learning Session 讲师
+- [[Jenkins]]：开源自动化服务器，本视频中与 AD 集成实现统一身份认证
+- [[SW Infra Active Directory]]：SW Infra 团队的 Active Directory 服务域，用于 Jenkins 的安全域集成
+- [[GitHub]]：源代码仓库，与 Jenkins 流水线通过 Webhook 触发集成（交叉引用来源）
+
+## Connections
+- [[ctp-topic-5-aws-identity-and-access-management-iam]] ← foundational ← [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+  - Topic 5 介绍 AWS IAM 联邦访问机制，Topic 11 将其延伸至 Jenkins 与企业 AD 的集成实践
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related ← [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+  - 均涉及 Jenkins CI/CD 流水线实践，Topic 9 聚焦 Gruntwork 框架，Topic 11 聚焦 AD 认证与安全检查
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← extends ← [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+  - Atlantis 是 Topic 11 中 terraform plan/apply 分层治理理念的具体实现工具
+- [[GitHub and Jenkins Integration]] ← depends_on ← [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+  - Jenkins 与 AD 集成的前置依赖：GitHub 仓库与 Jenkins 流水线的触发与反馈机制已就绪
+
+## Contradictions
+- 与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] 在 terraform apply 审批模式上存在差异：
+  - 冲突点：谁拥有 terraform apply 的最终审批权（人 vs 机器）
+  - Topic 11 观点：Master 分支人工审核后执行 terraform apply，强调人工把关
+  - Atlantis 观点：通过 PR 评论自动触发 apply，强调机器自动化
+  - 当前整合观点：两者互补——Topic 11 定义治理原则（人工审核），Atlantis 实现具体执行机制
--- 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,58 @@
+---
+title: "CTP Topic 23 Introduction to the Technical Architecture Team and Function"
+type: source
+tags:
+  - Technical-Architecture
+  - Cloud-Transformation
+  - Team-Structure
+  - CTP
+sources: []
+last_updated: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]
+
+## Summary（用中文描述）
+- 核心主题：技术架构团队的职能、组织架构及其在公司云转型中的价值
+- 问题域：PSTC 与 IT 部门整合至 CIO 统一领导后的架构融合挑战
+- 方法/机制：推行"云优先"策略，维护 AWS Enterprise Landing Zones，制定 12-24 个月技术路线图
+- 结论/价值：从被动响应转向主动规划，通过标准化和治理确保云环境安全与高效，帮助业务部门规避风险、优化预算并提升交付速度
+
+## Key Claims（用中文描述）
+- 技术架构团队将 PSTC 与 IT 整合为统一领导，实现两个大型组织的深度融合
+- 技术架构团队通过维护 AWS Enterprise Landing Zones 实现云环境标准化和治理
+- 团队推行"云优先"策略，新业务优先上云，除非数据主权、合规性或极端成本原因必须保留在本地
+- 三层架构分工：EA 对接业务战略，SA 负责中间件与服务优化，TA 专注底层技术实施与基础设施治理
+- 通过划分"技术领域"并由首席架构师负责，制定 12-24 个月前瞻性路线图
+- 技术路线图帮助业务部门规避风险、优化预算、提升交付速度，从基础设施维护中解放出来专注客户价值
+
+## Key Quotes
+> "从被动响应转向主动规划" — Martin Nash，技术架构经理
+> "除非因数据主权、合规性或极端成本原因必须保留在本地，否则所有新业务应优先上云" — 云优先策略核心原则
+> "技术架构团队帮助业务部门从繁杂的基础设施维护中解放出来，专注于为客户创造价值" — 团队价值定位
+
+## Key Concepts
+- [[Cloud-First Strategy]]：架构原则，规定新服务部署首选云解决方案，仅在明确限制时考虑本地部署
+- [[AWS Enterprise Landing Zones]]：预配置的、符合最佳实践的 AWS 多账号环境，提供统一治理、安全和网络连接标准
+- [[Technical Domains]]：将技术栈划分为特定领域（身份认证、网络、Microsoft 堆栈等），每个领域由专人负责生命周期与路线图
+- [[Enterprise Architecture (EA)]]：架构体系高层，将业务目标转化为技术原则和标准
+- [[Solution Architecture (SA)]]：架构体系中间层，专注于特定项目或服务的优化实施
+- [[Technical Architecture (TA)]]：最贴近技术的架构层，负责基础设施设计、实施治理及技术路线图维护
+- [[Roadmaps]]：针对各技术领域制定的 12-24 个月前瞻性规划
+- [[ITIL Alignment]]：将架构工作与 IT 服务管理框架结合，确保技术交付系统性
+
+## Key Entities
+- [[Martin Nash]]：技术架构经理（Technical Architecture Manager），本次演讲主讲人
+- [[Cloud Transformation Office]]：云转型办公室，主办本次学习会议
+- [[Technical Architecture Team]]：技术架构团队，负责维护 AWS Enterprise Landing Zones 和技术路线图
+- [[Chief Architects]]：首席架构师，负责各技术领域的生命周期与路线图
+
+## Connections
+- [[ctp-topic-47-enterprise-architecture-cloud-standards]] ← aligns_with ← [[Technical Architecture Team]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← depends_on ← [[AWS Enterprise Landing Zones]]
+- [[ctp-topic-57-product-backlog-managing-demand]] ← extends ← [[Technical Architecture Team]]
+- [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]] ← supports ← [[Roadmaps]]
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的内容冲突
--- 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,55 @@
+---
+title: "CTP Topic 41 NFR's and Error Budgets"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md]]
+
+## Summary（用中文描述）
+- 核心主题：NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——SRE 团队如何驱动产品组与运维协作，满足客户期望，以敏捷方式确保运维要求，并理解错误预算边界以快速可靠地交付功能。
+- 问题域：云环境下的可靠性工程、敏捷开发中的运维融合、NFR 的云原生落地
+- 方法/机制：NFR Epic 模板将需求集成到 Sprint Backlog；Error Budget 通过 SLO/SLI 量化系统可容忍的不可靠程度；混沌工程主动注入故障验证系统韧性
+- 结论/价值：Error Budget 归一化失败弥合开发与运维的鸿沟；NFR 应更具规范性并利用云原生服务；监控能力是衡量 Error Budget 是否达标的关键
+
+## Key Claims（用中文描述）
+- NFR 是评判系统运行的准则，Error Budget 是系统可容忍的最大故障时间，两者共同构成云环境下可靠性工程的基石
+- AWS 共享责任模型将基础设施管理责任转移给云提供商，但公司必须在云中架构和管理服务以满足 NFR
+- Error Budget = 1 - 可用性 SLO（如 99.9% SLO → 0.1% Error Budget），用于衡量系统在影响客户前可承受的不可靠程度
+- Error Budget 将失败归一化为开发流程的一部分，弥合了开发与运维之间的文化鸿沟
+- 混沌工程通过主动注入故障测试系统韧性，确保 NFR 得到满足
+
+## Key Quotes
+> "We want to drive collaboration across our product groups and operations to ensure our obligation to our customers." — Brendan Standing，SRE 协作目标
+> "Error budgets normalize failure as part of the development process." — Error Budget 的核心理念
+> "SLRs are quantifiable measures of reliability, SLOs define how a service should perform, and SLAs are customer-level agreements." — 三层服务等级体系
+
+## Key Concepts
+- [[NFR（非功能需求）]]：评判系统运行的准则，涵盖可用性、性能、安全性、可扩展性等维度；云环境下应更具规范性，充分利用云原生服务
+- [[Error Budget（错误预算）]]：系统可容忍的最大故障时间，由 SLO 推导而来；用于归一化失败并驱动开发和运维决策
+- [[SLO（服务等级目标）]]：定义服务应如何表现的绩效目标
+- [[SLI（服务等级指标）]]：可量化的可靠性度量指标
+- [[SLA（服务等级协议）]]：客户级别的正式协议
+- [[SLR（服务等级需求）]]：服务等级需求，与 SLO 配套使用
+- [[NFR Epic]]：将 NFR 模板集成到 Sprint Backlog 的敏捷实践，确保任何重大变更都考虑非功能需求
+- [[Chaos Engineering（混沌工程）]]：主动注入故障以测试系统韧性，确保 NFR 得到满足
+
+## Key Entities
+- [[Brendan-Standing]]：Micro Focus SRE 负责人（Head of SRE），本视频主讲人
+- [[AWS]]：Amazon Web Services，提供共享责任模型和云原生服务
+- [[Micro-Focus]]：企业云转型主体，OpenText 旗下公司
+
+## Connections
+- [[ctp-topic-30-managing-change]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR/Error Budget 与 SRE 变更管理实践高度关联，SRE 团队是 Error Budget 度量体系的核心执行者）
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR 中的可用性目标和 DR 策略直接相关，Error Budget 是衡量恢复能力的量化工具）
+- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← extends ← [[ctp-topic-41-nfrs-and-error-budgets]]（监控能力是衡量 Error Budget 是否达标的必要前提）
+- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR/Error Budget 是 SRE 度量弹性目标的工具，与 SRE 转型的方向一致）
+- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] ← extends ← [[ctp-topic-41-nfrs-and-error-budgets]]（DevOps 成熟度模型将 Error Budget 作为衡量系统可靠性和运维能力的核心指标）
+
+## Contradictions
+- 与 [[ctp-topic-30-managing-change]] 在 SRE 职责范围上存在视角差异：
+  - 冲突点：Topic 30 强调 SRE 的变更管理职责（Standard/Normal/Emergency Change），Topic 41 强调 SRE 的可靠性工程职责（NFR/Error Budget）
+  - 当前观点：两者是 SRE 职责的一体两面——变更管理是 SRE 的运营职责，NFR/Error Budget 是 SRE 的工程职责，共同构成完整的 SRE 能力体系
+  - 对方观点：Topic 30 侧重"如何处理变更"，Topic 41 侧重"如何定义可靠性目标"，两者互补而非矛盾
--- a/wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md
+++ b/wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md
@@ -0,0 +1,61 @@
+---
+title: "CTP Topic 5 - AWS Identity and Access Management (IAM)"
+type: source
+tags:
+  - AWS
+  - IAM
+  - Security
+  - CTP
+  - Identity
+  - Federation
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-5-aws-identity-and-access-management-iam.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS IAM 的核心组件（用户、组、角色、策略）及其在联邦访问中的应用
+- 问题域：企业 AWS Landing Zone 中的身份认证与访问授权管理
+- 方法/机制：联邦用户通过 Active Directory 组映射到 IAM 角色；PFSSO 工具实现 CLI 联邦访问；最小权限原则指导策略定义
+- 结论/价值：IAM 用户主要用于服务账号，人工用户应通过联邦机制管理；角色是串联身份与权限的核心纽带
+
+## Key Claims（用中文描述）
+- Active Directory 组通过角色映射为联邦用户提供 Landing Zone 账号访问权限
+- 角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联起来
+- IAM 用户主要用于服务账号，人工用户应优先使用联邦访问
+- 策略应遵循最小权限原则，只授予严格必要的权限
+- VSM 请求是通过联邦获取账号访问的必经流程
+- 支持跨账号角色假设，允许指定账户的主体担任特定角色
+- Terraform 模块可用于定义 IAM 角色，包括假设角色策略和内联策略块
+
+## Key Quotes
+> "Roles don't enable actions; they tie together who can do something and what they can do." — 角色是连接身份与权限的纽带，而非直接启用操作的实体
+> "We only want to allow the access that is strictly required." — 最小权限原则
+> "IAM users are primarily for service accounts; federation is the preferred method for user management." — 联邦优先于 IAM 用户管理
+
+## Key Concepts
+- [[IAM（身份和访问管理）]]：AWS 服务，用于管理用户身份、组、角色和策略，控制对 AWS 资源的访问
+- [[Federation（联邦身份）]]：通过 Active Directory 组映射到 IAM 角色，实现单点登录访问 AWS
+- [[Least Privilege（最小权限）]]：只授予用户完成工作所需的最小权限的安全原则
+- [[IAM Role（IAM 角色）]]：一种 IAM 身份，具有特定权限，可由用户、服务或外部实体担任
+- [[IAM Policy（IAM 策略）]]：定义权限的 JSON 文档，指定允许或拒绝的操作及资源
+- [[Managed Policy vs Inline Policy]]：托管策略可在多个角色间复用，内联策略绑定到特定角色
+- [[Cross-Account Role Assumption]]：跨账号角色假设，允许指定账户的主体担任目标账户的角色
+- [[PFSSO]]：用于通过联邦身份实现 AWS CLI 访问的工具
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，云服务提供商，IAM 为其原生身份访问管理服务
+- [[Active Directory（AD）]]：微软目录服务，用于管理用户身份和组，通过联邦机制与 IAM 集成
+- [[accounts.json]]：位于每个 Landing Zone 根目录的文件，包含账户号列表
+- [[VSM]]：Virtual SMACKS 系统，通过联邦请求获取账号访问权限
+
+## Connections
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← related_to ← [[IAM（身份和访问管理）]]
+- [[learning-sessions-identity-governance-vsm-replacement]] ← related_to ← [[Federation（联邦身份）]]
+- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] ← related_to ← [[Federation（联邦身份）]]
+- [[AWS-Landing-Zone]] ← depends_on ← [[IAM（身份和访问管理）]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← related_to ← [[Least Privilege（最小权限）]]
+
+## Contradictions
+- 无已知内容冲突
--- 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,58 @@
+---
+title: "CTP Topic 53 Why bother with Cloud"
+type: source
+tags: [Cloud, Strategy, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md]]
+
+## Summary（用中文描述）
+- 核心主题：Micro Focus 云转型计划的商业价值论证——用数据说明为何要迁移到云端
+- 问题域：企业数据中心资产利用率低、成本高昂，云转型不仅是成本节约，更是创新催化剂
+- 方法/机制：ELT（高管团队）演示 → 数据支撑论点 → 落地进展展示（LZ 交付、账户标签框架、Dart 资产剥离）
+- 结论/价值：云迁移不是"是否"的问题，而是"速度"的问题；当前 55% AWS 成本发生在 LZ 之外，亟需治理
+
+## Key Claims（用中文描述）
+- Micro Focus 拥有全球最大的商业数据中心足迹——14个数据中心、近20,000台资产
+- 尽管年营收25亿美元，但 VMware 足迹比规模大8倍的公司还大，硬件利用率不足40%
+- 三个产品迁出 Bublikan 后，下线575台物理服务器，云端仅需240台虚拟服务器替代
+- Redding 退出时40%的应用直接关机无需迁移，Houston 有89个空机架和360台未使用服务器
+- 云迁移的收益不仅是成本节约，更能促进产品创新、改善灾备、开拓新市场
+- 当前55%的 AWS 成本发生在 Landing Zone 之外，缺乏自动化、安全和财务管控
+
+## Key Quotes
+> "Micro Focus has the world's largest commercial footprint." — ELT 2022 演示
+> "We're trying to give them the information so that they can understand how they are spending." — 成本可见性目标
+> "The benefits of moving to the cloud extend beyond cost savings, fostering innovation and increasing revenue." — 云转型核心论点
+
+## Key Concepts
+- [[Cloud Transformation Programme]]：Micro Focus 的云转型计划，目标整合基础设施、降低成本、促进创新
+- [[Landing Zone]]：三类 LZ（Labs/SAS/Corporate）分别支撑不同隔离级别的云环境
+- [[AWS Account Tagging Framework]]：609个 AWS 账户统一标签框架，用于成本追踪和产品组消费告知
+- [[Enterprise Platform]]：企业级平台包含公共云供应商（AWS）、SRE、CCOE、架构组、自动化、安全和财务管控
+- [[Multi-Cloud Strategy]]：本视频论证了云转型战略的必要性
+
+## Key Entities
+- [[Micro Focus]]：年收入25亿美元的 Enterprise Software 公司，拥有全球最大商业数据中心足迹
+- [[Executive Leadership Team (ELT)]]：高管团队，2022年听取数据中心规模汇报后推动云转型
+- [[Bublikan]]：数据中心名称，三个产品从该中心迁出后下线575台物理服务器
+- [[Redding]]：数据中心名称，退出时40%应用直接关机
+- [[Houston]]：数据中心名称，拥有89个空机架和360台未使用服务器
+- [[Dart]]：资产剥离项目，云转型计划已完成 Dart 资产剥离
+- [[CCOE (Cloud Center of Excellence)]]：云卓越中心，负责企业平台和安全策略
+- [[SRE (Site Reliability Engineering)]]：可靠性工程团队，SRE/CCOE/架构组共同构成企业平台
+
+## Connections
+- [[ctp-topic-43-vmware-cloud-on-aws]] ← tensions_with ← [[ctp-topic-53-why-bother-with-cloud]]
+- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[ctp-topic-53-why-bother-with-cloud]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-53-why-bother-with-cloud]]
+- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-53-why-bother-with-cloud]]
+
+## Contradictions
+- 与 [[ctp-topic-43-vmware-cloud-on-aws]] 存在观点张力：
+  - 冲突点：是否应将工作负载迁移到云端
+  - 当前观点（本视频）：应积极迁移至云端，数据中心规模庞大、利用率低，云迁移成本效益显著
+  - 对方观点（Topic 43）：VMware Cloud on AWS 提供混合云中间路线，适合不完全准备完全迁移的企业
+  - 当前处理方式：两种路线并存——原生 AWS LZ 适合新建工作负载，VMC on AWS 适合已有 VMware 环境的渐进迁移
--- 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,62 @@
+---
+title: "CTP Topic 57 Product backlog managing demand"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand]]
+
+## Summary（用中文描述）
+- 核心主题：产品待办列表（Product Backlog）管理 —— 企业级云转型计划中如何接收、评估、优先级排序和交付需求
+- 问题域：CTP（Cloud Transformation Programme）需求治理、团队资源规划、产品组入职与支持
+- 方法/机制：通过 SMACs 提交需求 → 双周评审会议（Matthew Chapman/David Grant/Brendan）→ 20题评估问卷 → Octane 特性化 → Sprint 规划（50%新需求/50%支持+技术债）→ 准备阶段（Prerequisite Phase）→ SRE 账号构建与交接 → Hyper Care 支持
+- 结论/价值：透明化需求管道，确保所有工作以同一标准评估；Sprint 分配 50% 保护容量给新需求，防止支持工作吞噬创新带宽
+
+## Key Claims（用中文描述）
+- 产品待办列表是需求缓冲区，存放即将推出的功能，标注需求来源、收益和优先级
+- 新请求必须通过 SMACs 提交以启动计时器和确保可追踪性；邮件或聊天仅用于初步接触
+- 需求通过双周评审会议（Matthew Chapman/David Grant/Brendan 等）评估理解度、价值和优先级
+- 约20题的评估问卷帮助判断每项请求的简洁性、成本和野心程度
+- 机会评估通过后进入 Octane 作为特性（Feature），附带任务列表
+- 新团队需经历准备阶段（Prerequisite Phase）以对齐期望并理解产品需求
+- Sprint 规划通常提前6个 Sprint 展开，分配约50%给新需求、50%给支持工单和技术债
+- 大型产品组（如 ADM 和 ITOM）举行双周会议以对齐计划与优先级
+- 准备阶段关键步骤：介绍会议 → AWS 账户创建（PCG 团队审核）→ 解决方案设计与精炼 → GitHub 仓库创建 → 防火墙标签定义；产品团队工作量约2小时，跨越1-2周
+- SRE 工程师构建账户并交接，提供控制台和 GitHub 访问详情；交接后提供2周 Hyper Care 支持
+- 现有产品组可通过 SMACs/邮件/Teams 请求支持；缺陷在当前 Sprint 解决并分配给原始 Squad
+- Teams 频道连接产品组、SRE 工程师、解决方案架构师和交付经理
+- 变更请求或增强与解决方案架构师讨论后集成到现有账户
+- 公有子网通常仅限于生产环境；团队提供 Atlantis 或 Grant 表单用于自助任务
+
+## 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." — 关于 Sprint 规划对 ADM 产品组的价值
+
+## Key Concepts
+- [[Product-Backlog]]: 产品待办列表，作为需求缓冲区存放即将推出的功能，包含来源、收益和优先级信息
+- [[Demand-Management]]: 需求管理，通过标准化流程（提交→评审→分配→交付）确保透明度和公平优先级排序
+- [[SMACs]]: Service Management and Customer Service，系统化服务管理工具，用于提交和追踪需求请求
+- [[Prerequisite-Phase]]: 准备阶段，新产品团队加入云转型旅程时的入职流程，对齐期望并完成技术准备
+- [[Hyper-Care]]: 交接后支持期，SRE 工程师在产品组接管后提供2周强化支持
+- [[Sprint-Planning]]: Sprint 规划，提前6个 Sprint 展开，50% 容量分配给新需求，50% 给支持工单和技术债
+- [[Octane]]: Micro Focus 的工作追踪平台，需求评估通过后进入 Octane 作为 Feature 并附带任务列表
+
+## Key Entities
+- [[Matthew Chapman]]: 需求评审会议主持人之一
+- [[David Grant]]: 需求评审会议参与者
+- [[Brendan Starnig]]: 需求评审会议参与者，SRE Function Lead（CTP Topic 30 讲师）
+- [[ADM]]: Application Development and Management，产品组之一，定期双周对齐会议
+- [[ITOM]]: IT Operations Management，产品组之一，定期双周对齐会议
+- [[PCG]]: Platform Control Group，准备阶段中审核 AWS 账户创建并提供云环境支持
+- [[SRE]]: Site Reliability Engineer，负责账号构建、交接和 Hyper Care 支持
+
+## Connections
+- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] ← related_to ← [[ctp-topic-57-product-backlog-managing-demand]]（两者均属 CTP 需求治理框架，本 Topic 聚焦 Backlog 管理，Topic 20 聚焦 Gate Process 和 POC 入职）
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ← related_to ← [[ctp-topic-57-product-backlog-managing-demand]]（两者均涉及 CTP 敏捷实践，Sprint 规划分配比例在 Topic 4 有更详细讨论）
+- [[ctp-topic-30-managing-change]] ← related_to ← [[ctp-topic-57-product-backlog-managing-demand]]（两者均涉及 SRE 与产品团队的协作，Brendan Starnig 在两个 Topic 中均有参与）
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的冲突内容。
--- a/wiki/sources/ctp-topic-6-aws-workspaces-demo.md
+++ b/wiki/sources/ctp-topic-6-aws-workspaces-demo.md
@@ -0,0 +1,65 @@
+---
+title: "CTP Topic 6 AWS Workspaces Demo"
+type: source
+tags:
+  - AWS
+  - Workspaces
+  - Demo
+  - CTP
+  - End-User Computing
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Workspaces 虚拟桌面解决方案的演示与实操体验
+- 问题域：如何为云转型团队快速提供预配置的开发工作站环境，实现"半小时内从申请到跑通 Terraform"的目标
+- 方法/机制：通过 AWS Workspaces 提供托管 Windows 虚拟桌面，内置 PFSSO、Terraform、TerraGrunt、Git、VS Code 等工具，用户通过邮件接收注册码和用户名即可登录使用
+- 结论/价值：AWS Workspaces 可在 21-45 分钟内为用户交付可用的云端开发环境，消除本地配置负担，提升云转型计划中基础设施团队的工作效率
+
+## Key Claims（用中文描述）
+- AWS Workspaces 为用户提供通过 Web 浏览器或客户端应用访问的托管桌面环境，可预配置特定工具或提供原生 Windows 安装
+- 目标是在提出申请后的半小时至 45 分钟内，使用户能够运行 TerraGrunt Plan 针对基础设施执行部署
+- 工作站运行 Windows Server 2016（因 Pulse UI 兼容性原因未选用 Amazon Linux），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code
+- 用户需联系 Naga 申请账号，未来计划与 Active Directory 集成
+- 登录后可访问 AWS Console（通过 Federation）、GitHub Enterprise 并生成 SSH 密钥
+- 演示中克隆仓库、认证 PFSSO 并运行 TerraGrunt Plan，全程约 21 分钟完成
+- 工作站使用后保留约一小时的活跃状态，可根据需要额外安装工具
+
+## Key Quotes
+> "The hope 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."
+> — 演示目标：快速交付可用开发环境
+
+> "As you can see, we can successfully access GitHub Enterprise as well."
+> — 工作站可同时访问 AWS Console 和 GitHub Enterprise
+
+## Key Concepts
+- [[AWS Workspaces]]：AWS 托管的虚拟桌面解决方案（VDI），通过 Web 浏览器或客户端提供预配置 Windows 环境
+- [[Terraform]]：基础设施即代码（IaC）工具，用于声明式定义和配置云资源
+- [[TerraGrunt]]：Terraform 的包装器，提供锁文件管理、远程状态和目录结构管理
+- [[PFSSO]]：Pulse Federation SSO，企业单点登录解决方案，用于 AWS 资源访问认证
+- [[AWS Federation]]：AWS 联合身份，基于 SAML 2.0 实现外部身份提供商对 AWS Console 的访问
+- [[GitHub Enterprise]]：GitHub 企业版，内部源代码管理平台（已迁移至 GitLab，参考 ctp-topic-53 相关内容）
+
+## Key Entities
+- [[Naga]]：负责 AWS Workspaces 账号创建的联系人，用户需通过邮件联系 Naga 申请工作站
+- [[AWS]]：Amazon Web Services，云桌面服务（Workspaces）的提供商
+- [[Micro Focus]]：演示所属组织，云转型计划（CTP）的重要组成部分
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← extends ← [[ctp-topic-6-aws-workspaces-demo]]
+  - Topic 6 演示的工作站环境基于 Topic 1 中定义的 Gruntwork Landing Zone 架构
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related ← [[ctp-topic-6-aws-workspaces-demo]]
+  - 工作站中运行 TerraGrunt Plan 的能力是 CI/CD 流程的一部分
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← future_integration ← [[ctp-topic-6-aws-workspaces-demo]]
+  - 当前通过邮件（Naga）手动创建账号，未来计划与 Active Directory 集成实现自动化账号管理
+
+## Contradictions
+- 与 [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] 冲突：
+  - 冲突点：Topic 6 演示中提及访问 GitHub Enterprise
+  - 当前观点：AWS Workspaces 预装工具中包含 GitHub Enterprise 访问能力
+  - 对方观点：Project Thor 已将源代码管理平台从 GitHub Enterprise 迁移至 GitLab，GitHub Enterprise 许可证已于 12 月底到期不再续约
+  - 说明：视频录制时间早于 GitHub→GitLab 迁移完成，当前 GitHub Enterprise 已不可用，迁移后的 Workspaces 镜像应预装 GitLab 而非 GitHub Enterprise
+
--- a/wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md
+++ b/wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md
@@ -0,0 +1,59 @@
+---
+title: "CTP Topic 8 - Implementation of Cloud Monitoring using Micro Focus Operations Bridge Manager"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md]]
+
+## Summary（用中文描述）
+- **核心主题**：使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案，填补传统 Sitescope 监控工具在云环境中的能力缺口。
+- **问题域**：云环境动态性强、资源生命周期短，传统监控工具依赖静态服务器部署，无法有效覆盖 AWS 多账户多区域场景；OBM 通过 Management Pack 策略化方案实现云原生的动态监控能力。
+- **方法/机制**：OBM AWS Account 部署 OBM 应用 + Postgres RDS + Operation Agent；Agent 通过 AWS Management Pack 利用 IAM Role 跨账户收集 CloudWatch 指标/日志；Global OBM 作为 Manager of Managers 汇聚多区域 Regional OBM 数据；事件通过 SMACKS 与 OSE 团队工单系统集成。
+- **结论/价值**：OBM Management Pack 支持任意公有云（AWS/Azure/GCP）的 CloudWatch 兼容服务，无需在被监控账户中安装任何代理，通过 IAM Role 信任关系实现安全无密钥的跨账户数据采集；新增实例自动发现和策略自动下发能力解决了云环境动态性问题。
+
+## Key Claims（用中文描述）
+- **OBM 相比 Sitescope 的优势**：提供更动态的云监控能力、更强的安全性和更广泛的 AWS 核心服务覆盖，适合公有云环境。
+- **OBM 架构**：Regional OBM 收集数据 → Global OBM 汇聚 → SMACKS 触发工单；OBM AWS Account 包含 OBM 应用、RDS 数据库和 Operation Agent 三层组件。
+- **跨账户监控机制**：Operation Agent 通过 AWS Management Pack 定义的 Policy，以 IAM Role 身份调用 CloudWatch API，无需在被监控账户安装服务器或共享 Access Key。
+- **动态监控能力**：当新实例添加到被监控账户时，Policy 自动部署，监控立即生效，无需人工干预。
+- **客户上云流程**：客户账户创建具有 CloudWatch Read-Only 访问权限的 IAM Role → 将 OBM Account 添加到信任关系 → 将 Role ARN 添加到 OBM Policy → 指定监控的命名空间/服务/指标/阈值/频率。
+- **多云支持**：OBM Management Pack 方案可监控任何将数据暴露给 CloudWatch 的公有云供应商和 AWS 服务，兼顾指标和日志。
+
+## Key Quotes
+> "The operation agent collects data using OBM management packs, specifically the AWS management pack, which instructs the agent to gather data from different accounts." — OBM AWS 监控的核心数据采集机制
+
+> "The agent uses role-based access to collect data from CloudWatch API, eliminating the need to install servers in customer accounts and share sensitive access keys." — IAM Role 机制的安全价值：无需密钥共享
+
+> "Whenever new instances are added, policies are automatically deployed, and monitoring begins, offering dynamic monitoring capabilities." — 动态监控的关键特性：自动发现与自动部署
+
+## Key Concepts
+- [[CloudWatch]]: AWS 监控数据源，OBM 通过 CloudWatch API 采集所有监控指标和日志
+- [[Cloud-Monitoring]]: 公有云监控的核心挑战——动态环境、多账户、免代理采集
+- [[OBM]]: Micro Focus Operations Bridge Manager，企业级监控管理平台，支持多云环境
+- [[Management-Pack]]: OBM 的策略包机制，定义监控间隔、指标、阈值和数据采集规则
+- [[IAM-Role]]: AWS IAM 角色，OBM Agent 通过角色信任关系实现跨账户安全访问 CloudWatch，无需共享密钥
+- [[Multi-Account-Monitoring]]: AWS Organizations 多账户环境下的集中监控架构
+- [[Landing-Zone-Monitoring]]: Landing Zone 架构中的监控组件，OBM Account 作为独立账户与 Shared/Logs/Security 账户交互
+- [[Dynamic-Monitoring]]: 云环境特有的动态监控能力——新增资源自动发现、策略自动下发
+
+## Key Entities
+- **[[Micro-Focus]]**: OBM 产品的供应商，提供 Operations Bridge Manager 企业级监控平台
+- **[[Sitescope]]**: Micro Focus 传统监控工具，被 OBM 替代，用于描述 OBM 相比旧方案的改进
+- **[[SMACKS]]**: Micro Focus 工单系统，OBM 事件通过 SMACKS 与 OSE 团队集成，实现事件升级和工单创建
+- **[[AWS-CloudWatch]]**: AWS 监控指标和日志服务，OBM Agent 的数据采集来源
+- **[[AWS-Operation-Agent]]**: 部署在 OBM AWS Account 的操作代理，负责跨账户收集 CloudWatch 数据
+- **[[Global-OBM]]**: 全球级 OBM，作为 Manager of Managers，汇聚各 Regional OBM 的数据
+- **[[Regional-OBM]]**: 区域级 OBM，收集本区域内各账户的监控数据并转发给 Global OBM
+- **[[Digital-Factory]]**: OBM AWS Account 所属的 Landing Zone 组成部分，与 Shared/Logs/Security 账户交互
+
+## Connections
+- [[CTP-Topic-29-Cloud-Monitoring-SAAS-LZ-Accounts]] ← related_to ← [[CTP-Topic-8-OBM-Cloud-Monitoring]]: Topic 29 讨论 SaaS Landing Zone 的云监控账户设计，Topic 8 详解 OBM 技术实现方案
+- [[CTP-Topic-60-Monitor-AWS-Grafana]] ← related_to ← [[CTP-Topic-8-OBM-Cloud-Monitoring]]: Grafana 作为可视化层，OBM 作为数据采集和策略管理层，两者互补
+- [[CTP-Topic-25-Labs-Landing-Zone]] ← extends ← [[AWS-Landing-Zone]]: Labs LZ 概述中提到的 ARC Site 监控组件与 OBM 的功能定位重叠
+- [[CTP-Topic-7-SAAS-Landing-Zone-Design]] ← extends ← [[AWS-Landing-Zone]]: SaaS LZ 设计中提到 Shared Services Account 包含 OBM/Sitescope 监控服务
+
+## Contradictions
+- 与 [[CTP-Topic-67-OpenTelemetry]]: Topic 67 倡导云原生可观测性标准（OTel），强调统一的数据模型和 Vendor-Neutral 采集；OBM 作为传统商业监控平台，数据模型封闭，与 OTelp 倡导的开放标准存在理念差异。当前实现选择 OBM 而非 OTelp，可能是出于企业既有投资保护（Micro Focus 工具链）和与 SMACKS 工单系统深度集成的考量。
--- a/wiki/sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md
+++ b/wiki/sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md
@@ -0,0 +1,57 @@
+---
+title: "Learning Sessions Identity Governance VSM Replacement - 20231128"
+type: source
+tags:
+  - Identity-Governance
+  - VSM
+  - CTP
+  - IAM
+  - AWS-Identity-Center
+date: 2023-11-28
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md]]
+
+## Summary（用中文描述）
+- 核心主题：身份治理（Identity Governance）框架，以及用 Micro Focus IGA 替换 DXC 虚拟 SM（VSM）工具的计划
+- 问题域：企业数字身份管理——谁来访问、谁该访问、如何访问；内部/外部用户（含承包商）的权限治理
+- 方法/机制：Micro Focus IGA 通过资源控制工作流实现权限审批/撤销/监控；Active Directory 组映射角色；AWS Identity Center + IAM 提供云资源访问；IG 治理 AD 组工作流
+- 结论/价值：VSM 将被 IG 全面替换，采用相同架构但连接 Coptum 域；POC 正在进行中以验证架构和流程；用户通过 IGA Portal 申请权限，审批后自动授权
+
+## Key Claims（用中文描述）
+- 身份治理通过三个核心问题（谁当前有访问权限、谁应该有访问权限、如何执行访问）驱动数字化风险管理和合规
+- Micro Focus IGA 通过工作流管控 Active Directory 组的权限审批与撤销，并配合 AWS IAM + Azure AD Domain Services 实现云资源访问
+- IG 支持内部和外部用户（含承包商）的有时限访问权，适合临时权限管理场景
+- VSM → IG 替换计划将保持原有架构不变，但 IG 连接至 Coptum 域（而非原 DXC 域）
+- POC（概念验证）正在进行，以验证替换架构和审批流程的可行性
+- IGA Portal 用户体验：搜索资源 → 申请权限 → 填写表单 → 审批流 → 自动授权
+
+## Key Quotes
+> "Identity governance is a framework for managing digital identities efficiently, minimizing risk, and maintaining compliance." — 身份治理定义
+
+> "IG integrates with AWS Identity Center to provide access to resources via IAM. Groups in Active Directory represent roles, and IG governs access to these groups." — IG + AD + AWS Identity Center 集成架构
+
+> "The plan is to replace VSM with IG for all accounts, using the same architecture as VSM, but with IG connected to Coptum domain." — VSM 替换计划核心策略
+
+## Key Concepts
+- [[Identity-Governance]]：数字化身份管理框架，最小化风险、保持合规，核心三问：谁有访问/谁该访问/如何访问
+- [[IGA（Identity Governance and Administration）]]：身份治理与管理，Micro Focus IGA 是该领域的具体产品实现
+- [[AWS-Identity-Center]]：AWS 身份中心（原 AWS SSO），通过 IAM 提供云资源访问控制
+- [[Micro-Focus-IGA]]：Micro Focus 身份治理与管理工具，管控 AD 组工作流并连接 AWS Identity Center
+- [[Active-Directory]]：微软目录服务，AD 组映射角色，IGA 治理这些组的成员关系
+
+## Key Entities
+- [[Micro Focus]]：会议来源组织，其 IGA 产品线用于替换 DXC VSM 工具
+- [[DXC-VSM]]：DXC Virtual SM，DXC 提供的老一代身份治理工具，将被 Micro Focus IGA 替换
+- [[AWS-Identity-Center]]：AWS 身份中心，提供跨账户单点登录和权限管理
+- [[Azure-AD-Domain-Services]]：Azure AD 域服务，作为身份认证桥梁连接 DXC 域
+
+## Connections
+- [[Micro-Focus-IGA]] ← depends_on ← [[Active-Directory]]
+- [[AWS-Identity-Center]] ← depends_on ← [[Micro-Focus-IGA]]
+- [[Micro-Focus-IGA]] ← replaces ← [[DXC-VSM]]
+- [[Azure-AD-Domain-Services]] ← bridges_auth ← [[Active-Directory]]
+
+## Contradictions
+- 暂无已知冲突内容
--- a/wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md
+++ b/wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md
@@ -0,0 +1,54 @@
+---
+title: "Public Cloud Learning Sessions- Applicable Business Analysis Techniques - 20240109"
+type: source
+tags: [Business-Analysis, Techniques]
+date: 2024-01-09
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md]]
+
+## Summary（用中文描述）
+- 核心主题：业务分析（Business Analysis）基础技能与核心技法，聚焦云转型背景下的需求定义与干系人管理
+- 问题域：敏捷团队中业务与技术之间的沟通鸿沟；新工作（需求、变更、项目）定义不清晰导致的混乱
+- 方法/机制：三大技法——BOSCARD（复杂新工作定义框架）、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集；T型技能模型连接业务与技术
+- 结论/价值：业务分析将业务需求与技术变更解决方案对齐；BOSCARD早期锁定范围"无价"；T型技能在敏捷 Squad 中的核心价值
+
+## Key Claims（用中文描述）
+- 业务分析通过调查现状、分析需求、识别方案、评估选项、定义需求，将业务需求与技术变更解决方案对齐，包括IT系统变更、流程变更、培训和角色转换
+- T型技能在敏捷 Squad 中极具价值，结合核心专业深度与相关技能的广度，业务分析技能是连接业务问题与技术解决方案的桥梁
+- BOSCARD通过澄清背景、目标、范围、约束、假设、风险、角色和交付物来定义复杂新工作，帮助避免目标和交付物混淆
+- 干系人轮盘从客户出发顺时针识别所有项目干系人（客户、合作伙伴、监管机构、员工、管理层、所有者、竞争对手），早期识别可防止变更和揭示风险
+- 结合用户故事与元数据的Requirements Gathering为需求捕获增加严谨性；SAFe框架在用户故事之外还包含Features、Capabilities和非功能需求
+- INVEST原则（Independent/Negotiable/Valuable/Estimable/Small/Testable）用于检查需求质量
+
+## Key Quotes
+> "Business analysis helps us work out what changes will be beneficial in our business architecture, including changes to IST systems and defining the requirements for those changes." — 业务分析核心价值定位
+
+> "If you can get scope tied down early on and agreed, that's priceless." — BOSCARD的价值
+
+> "Every requirement should be independent, meaning not duplicating something else, that's the I in INVEST, negotiable, so the business should state what they need, but be open to how it's implemented." — INVEST原则核心
+
+## Key Concepts
+- [[Business-Analysis]]：将业务需求与变更解决方案对齐的过程——调查现状、分析需求、识别方案、评估选项、定义需求；涵盖IT系统变更、流程变更、培训和角色转换
+- [[T-Shaped-Skills]]：结合核心专业深度与相关技能广度的技能模型；在敏捷 Squad 中弥合业务与技术之间的鸿沟
+- [[BOSCARD]]：复杂新工作定义框架——Background（背景）、Objectives（目标）、Scope（范围）、Constraints（约束）、Assumptions（假设）、Risks（风险）、Roles（角色）、Deliverables（交付物）
+- [[Stakeholder-Wheel]]：干系人识别工具，从客户出发顺时针识别所有项目干系人；可配合权力/影响矩阵或RACI矩阵使用
+- [[Requirements-Gathering]]：需求收集方法，结合用户故事（what/who/why）与元数据（版本、依赖、可追溯性、时间、验收标准、分类）
+- [[INVEST]]：优质用户故事检查原则——Independent（独立）、Negotiable（可协商）、Valuable（有价值）、Estimable（可估算）、Small（小型）、Testable（可测试）
+- [[SAFe]]：Scaled Agile Framework，在用户故事之外还包含Features（功能）、Capabilities（能力）和非功能需求（NFR）
+- [[RACI]]：责任分配矩阵——Responsible（负责）、Accountable（问责）、Consulted（咨询）、Informed（知情）
+
+## Key Entities
+- [[BCS]]：英国计算机学会，业务分析学习资源来源之一
+- [[IIBA]]：国际商业分析协会，业务分析学习资源来源之一
+- [[OpenText]]：主办 Public Cloud Learning Sessions 的公司
+
+## Connections
+- [[ctp-topic-57-product-backlog-managing-demand]] ← related_to ← [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]
+- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] ← related_to ← [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ← related_to ← [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]
+- [[ctp-topic-41-nfrs-and-error-budgets]] ← related_to ← [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]（NFR属于业务分析的需求定义范畴）
+
+## Contradictions
+- 与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 在流程视角上存在互补关系：Topic 4 提供敏捷持续流动的实践框架，本视频提供需求定义的前置技法；前者强调执行节奏，后者强调规划严谨性，两者共同构成云转型计划管理的完整方法论
--- a/wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md
+++ b/wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md
@@ -0,0 +1,63 @@
+---
+title: "Public Cloud Learning Sessions - AWS End User Compute Services - 20240430"
+type: source
+tags:
+  - AWS
+  - End-User-Computing
+  - Workspaces
+  - AppStream
+date: 2026-04-14
+---
+
+## Source File
+- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 终端用户计算（EUC）服务全景介绍——虚拟桌面与应用程序流
+- 问题域：远程/混合工作模式下的终端用户计算基础设施选型与安全设计
+- 方法/机制：Amazon Workspaces（全持久虚拟桌面）、AppStream 2.0（选择持久/非持久应用流）、Workspace Core（第三方 VDI 集成）、Workspace Web（低成本安全浏览器）四类服务的对比与适用场景分析
+- 结论/价值：帮助组织根据用户类型（知识工作者/任务工作者）和用例（完整桌面/应用流/安全浏览）选择最适合的 AWS EUC 服务方案
+
+## Key Claims（用中文描述）
+- Workspaces 适合需要完整桌面环境的知识工作者，AppStream 适合实验室、培训和堡垒主机场景
+- AppStream 提供多租户模式允许多用户共享实例，有效降低成本
+- 全持久桌面（Workspaces）提供一对一实例管理，应用状态和设置在会话之间保持
+- 非持久桌面（AppStream）提供每次登录全新桌面，支持应用连接器和存储连接器实现部分持久化
+- 成本优化通过 AppStream 并发使用和 Workspaces 自动停止功能实现
+- WSP 协议专为高延迟网络设计，支持灾难恢复策略（跨区域构建 Workspaces 或利用 AppStream 自动扩展）
+- 安全措施包括 Active Directory 集成、加密、IAM 配置文件和多因素认证
+
+## Key Quotes
+> "With so many remote workers organizations are struggling to protect endpoints, as well as their IP and data from bad actors." — AWS EUC 安全背景说明
+
+> "AppStream 2.0 is a great low cost alternative for customers that don't require a fully persistent desktop." — AppStream 2.0 定位
+
+## Key Concepts
+- [[Amazon Workspaces]]：全持久虚拟桌面服务，提供一对一实例管理，应用状态和设置在会话之间保持
+- [[AppStream 2.0]]：安全的应用流服务，提供选择性持久化，支持多租户模式，适合非持久桌面场景
+- [[AWS End User Computing]]：AWS 终端用户计算服务组合，包含 Workspaces、AppStream 2.0、Workspace Core、Workspace Web 四大服务
+- [[Virtual Desktop Infrastructure]]：虚拟桌面基础设施，通过虚拟化技术在云端交付桌面环境
+- [[WSP Protocol]]：Workspaces Streaming Protocol，专为高延迟网络设计的流传输协议
+- [[BYOD（Bring Your Own Device）]]：自带设备工作模式，员工使用个人设备访问企业资源
+- [[VDI（Virtual Desktop Infrastructure）]]：虚拟桌面基础设施，Workspace Core 提供对 Workspaces VDI 基础设施的 API 访问
+- [[SAML Authentication]]：基于 SAML 的身份认证，增强安全性的同时简化用户体验
+- [[VPC Interface Endpoints]]：VPC 接口终端节点，用于通过私有连接安全访问 AWS 服务
+
+## Key Entities
+- [[Christian O'Donough]]：AWS 主讲人，分享 AWS EUC 服务学习课程
+- [[Amazon Workspaces]]：AWS 全持久虚拟桌面服务
+- [[AppStream 2.0]]：AWS 应用程序流服务
+- [[Workspace Core]]：提供 Workspaces VDI 基础设施 API 访问，支持 Horizon View、Citrix 等第三方集成
+- [[Workspace Web]]：低成本安全 Web 浏览器，用于访问内部网站和 SaaS 应用
+- [[Amazon VPC]]：AWS 虚拟私有云，EUC 架构包含服务 VPC（AWS 托管）和客户 VPC
+- [[Active Directory]]：活动目录集成，EUC 服务的身份认证基础
+- [[CloudWatch]]：AWS 监控服务，支持 EUC 运营指标监控
+
+## Connections
+- [[ctp-topic-6-aws-workspaces-demo]] ← extends ← [[AWS End User Computing]]
+- [[AWS End User Computing]] ← depends_on ← [[Amazon VPC]]
+- [[AWS End User Computing]] ← depends_on ← [[Active Directory]]
+- [[AppStream 2.0]] ← extends ← [[AWS End User Computing]]
+
+## Contradictions
+- 无已知冲突内容
--- 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,59 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration"
+type: source
+tags:
+  - GitHub
+  - GitLab
+  - Migration
+  - OpenText
+  - DevOps
+  - Source Control
+date: 2024-06-25
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab
+- 问题域：企业级版本控制系统迁移、多团队协同转型、CI/CD 流水线重构
+- 方法/机制：Project Thor 统一工具链；Build Hub 团队提供支持；各团队自主规划迁移；两种迁移方案（镜像同步 / 搬移重构）；通过 PHT（Product Hub Platform）跟踪进度
+- 结论/价值：GitHub 许可证12月底到期不续，GitLab 许可证覆盖8,500用户；迁移是自服务模式（self-serve），Build Hub 提供辅助支持
+
+## Key Claims（用中文描述）
+- OpenText 决定将 GitLab 作为源代码控制的黄金标准（golden standard）
+- GitHub Enterprise 许可证12月底到期，公司不打算续约
+- GitLab 许可证覆盖高达 8,500 名用户
+- 各团队需自行盘点 GitHub 资产、识别流水线、规划迁移
+- 迁移完成标准：代码迁移完成 + 流水线转型 + PHT 更新
+- GitLab 仓库权限由 PHT 控制，支持自助访问管理
+- 个人仓库允许存在于 GitLab，但不得包含产品源代码，且不会被 PHT 映射
+- 网络连通性挑战通过在 Brook Park 创建 GitLab 代理解决
+
+## Key Quotes
+> "Project Thor aims to integrate Micro-Focus and OpenText tooling, with GitLab as the centralized system for source control." — 迁移背景说明
+> "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." — GitLab 代理方案评价
+
+## Key Concepts
+- [[Project Thor]]：整合 Micro Focus 和 OpenText 工具链的项目，GitLab 作为源代码控制的集中系统
+- [[Build Hub]]：负责管理 GitLab 等中心工具并为软件交付流水线提供支持
+- [[PHT（Product Hub Platform）]]：产品 Hub 平台，用于管理 GitLab 仓库权限映射和迁移进度跟踪
+- [[Mirroring]]：镜像方案，将 GitHub 仓库同步到 GitLab
+- [[Shift and Lift]]：搬移重构方案，将代码复制到 GitLab 并同时转换流水线
+- [[Service Account Standard]]：服务账号标准，要求服务账号必须关联到个人，密码设有到期时间
+
+## Key Entities
+- [[OpenText]]：本次迁移的主体公司，合并了 Micro Focus
+- [[GitHub Enterprise]]：被迁移的源代码管理平台，许可证12月底到期
+- [[GitLab]]：迁移目标平台，作为源代码控制的黄金标准
+- [[Build Hub]]：Build Hub 团队，负责中心工具管理和流水线支持
+
+## Connections
+- [[OpenText]] ← uses ← [[GitLab]]（作为源代码管理标准平台）
+- [[OpenText]] ← deprecated ← [[GitHub Enterprise]]（12月底到期停用）
+- [[Build Hub]] → supports → 各团队迁移
+- [[PHT（Product Hub Platform）]] ← manages ← GitLab 仓库权限
+
+## Contradictions
+- 无已知冲突内容
--- 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,54 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806"
+type: source
+tags: []
+date: 2024-08-06
+---
+
+## Source File
+- [[public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText Product Hub（产品层次结构追踪器，简称 PhD 或 PHT）的功能概述与操作演示
+- 问题域：企业内部软件产品资产治理、CI/CD 流水线管理、跨团队产品信息标准化
+- 方法/机制：通过层级结构（业务单元→业务线→产品）和自助服务流程实现产品信息集中管理；与 Jira、Value Edge、PSMQ、ITLS、OSS 等外部系统集成
+- 结论/价值：统一产品视图，支持 Source Repo 和 Artifact Repo 权限管理，实现跨工具链的产品信息一致性
+
+## Key Claims（用中文描述）
+- Product Hub (PhD) 由产品经理或开发经理驱动，收集和管理官方产品及其部门信息，区别于官方产品命名注册表中的主产品
+- Product 定义为具有独立 CI/CD 流水线或发布周期的软件分发；若某组件有自己独立的发布周期（如独立 CI/CD 流水线），应作为 Product 而非 Component 处理
+- PhD 层级结构：业务单元（含工程和 PM 负责人）→ 业务线（含负责人和 PM Lead）→ 产品（含 PM 和开发经理，并关联主产品）
+- 新建 Product 是自助服务流程：提交后经业务线审批；Source Repo 在 GitLab 创建后需 24 小时才在 PhD 中反映，空 Group/Repo 无法被搜索到
+- Product 有三种状态：Active（常规发布）、Maintenance（仅热修复/Bug 修复）、Inactive（无发布）
+- Component 是没有 CI/CD 流水线的库，如需 ITLS 审查或扫描应创建为 Product
+- Source Repo 权限可共享给子产品（只读访问）；Product Team 可配置为 Engineering（全权访问）或 Moderator（维护者访问）类型
+
+## Key Quotes
+> "A product is a software distribution with its own CI/CD pipeline or release cycle." — Product 与 Component 的核心区分标准
+> "A product may also be part of another parent product, but if that particular product has its own cycle, like its own CI/CD pipeline, then we may treat that particular component or module as a product in PhD." — Product 的层级归属逻辑
+> "Requesting for a new product is a self-serve process." — 自助服务是 PhD 的核心理念
+> "Source repo creation in GitLab takes 24 hours to reflect in PhD, and empty groups/repositories cannot be searched." — GitLab 与 PhD 同步的已知限制
+> "For product name/status changes, contact erphd@opentext.com; for technical questions, contact aangetoolsupport@opentext.com." — 支持渠道
+
+## Key Concepts
+- [[Product Hub (PhD)]]：OpenText 产品层次结构追踪器，统一管理业务单元、业务线、产品的层级关系和元数据
+- [[CI/CD Pipeline]]：产品定义的核心属性之一，独立流水线是将 Component 升级为 Product 的判断标准
+- [[Source Repo]]：源代码仓库，与 GitLab 集成，PhD 中映射 Source Repo 权限；创建后 24 小时同步
+- [[Artifact Repo]]：制品仓库，PhD 中管理 Artifact Repo 权限，新结构默认启用
+- [[Product Hierarchy]]：业务单元（BU）→ 业务线（LOB）→ 产品（Product）的三层结构
+
+## Key Entities
+- [[OpenText]]：企业软件公司，主导本次 Public Cloud Learning Sessions
+- [[Product Manager]]：产品经理，PhD 中承担产品创建和维护职责
+- [[Development Manager]]：开发经理，产品管理的核心角色
+- [[ITLS]]：Integrated Tool Lifecycle System，PhD 集成的外部系统之一
+- [[PSMQ]]：Product Service Management Queue，PhD 集成的外部应用
+- [[Value Edge]]：外部应用集成，PhD 打通数据流
+- [[Jira]]：项目跟踪工具，PhD 与其集成
+
+## Connections
+- [[Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows]] ← depends_on ← [[Product Hub (PhD)]]
+- [[Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration]] ← extends ← [[Product Hub (PhD)]]
+
+## Contradictions
+- 无已知冲突内容
--- 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,41 @@
+---
+title: "Public Cloud Learning Sessions - OpenText Tagging Standard v2 - 20250429"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText 云资源标签标准 v2——覆盖云账户、云资源、Kubernetes 对象和容器镜像的统一标签规范
+- 问题域：云成本优化、资源安全合规、服务交付自动化
+- 方法/机制：通过标准化标签前缀（OT\_ / app.opentext.com / com.opentext.image）实现跨云平台的统一标签语义；IaC 自动化标签创建与维护
+- 结论/价值：标签标准化是 FinOps 成本优化的基础，同时支撑安全合规、资源组织和自动化工作流
+
+## Key Claims（用中文描述）
+- OpenText 通过标准化标签驱动成本优化的三大机制：成本分配、风险降低（快速定位技术联系人）、自动化效率提升
+- Phenops 团队 2023 年发起的标签标准现已扩展至 Kubernetes 对象和容器镜像，覆盖 3,500 个云账户和 48 种 landing zone 类型
+- 标签治理最佳实践：IaC 自动化替代手动打标、检测报告发现缺失标签、禁止在标签中存储敏感数据
+
+## Key Quotes
+> "Tags are key-value pairs that typically have a tag key and an optionally a key value, which you can attach to cloud resources, cloud accounts, container images, Kubernetes objects and other things." — 标签的核心定义
+> "It is about taking resources and you will learn more in the presentation about what kinds of object and what exactly and so on." — 标签标准的适用对象概述
+
+## Key Concepts
+- [[Terraform]]：基础设施即代码工具，用于自动化标签创建和维护
+- [[Kubernetes]]：容器编排平台，标签标准扩展至其对象（namespaces、pods、deployments、services、config maps）
+- [[Container-Images]]：容器镜像，标签标准包含 product、title、description、vendor 等元数据标签
+
+## Key Entities
+- [[Martin-Rosler]]：讲师，介绍 OpenText Tagging Standard V2 的核心内容和三大驱动力
+- [[Phenops-Team]]：发起标签标准（2023年）的团队，原始版本已扩展 Kubernetes 和容器镜像指南
+
+## Connections
+- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← [[OpenText-Tagging-Standard-v2]]（两者均关注标签合规审计与强制执行）
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← relates_to ← [[OpenText-Tagging-Standard-v2]]（标签即凭证的云原生安全架构理念一致）
+- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（审计工具是对 SCP 预防控制的存量检查补充）
+
+## Contradictions
+- 与 [[ctp-topic-28-aws-tag-validation-tool]] 在标签强制能力边界上无矛盾，两者互补：标签标准定义「应该怎么标」，验证工具发现「谁没标好」
--- 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,58 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows"
+type: source
+tags:
+  - Thor
+  - Platform
+  - OpenText
+  - Project Thor
+  - DevOps
+  - Supply Chain Security
+date: 2024-12-10
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText Project Thor 平台架构与数据流设计——源代码供应链安全与开发者体验标准化
+- 问题域：Micro Focus 与 OpenText 合并后的工具链整合、源代码治理、构建系统标准化
+- 方法/机制：五大支柱框架（敏捷周期治理、产品发布治理、开发者门户、安全治理、Build Hub）+ GitLab + Artifactory + Backstage + UCMDB 工具链整合
+- 结论/价值：标准化工具链、统一治理模型、提升开发者体验、保障供应链安全
+
+## Key Claims（用中文描述）
+- Arnold Dacan 提出：源代码是供应链的核心要素（"The main ingredient in the supply chain is our source code, our IP that is intended to live in GitLab"）
+- Project Thor 五大支柱：①敏捷与周期管理 ②产品与发布治理 ③开发者门户（Backstage） ④安全与治理 ⑤Build Hub
+- 标准化目标：在 GitLab、Artifactory、UCMDB 基础上统一工具链，为供应链安全奠定基础
+- 地理分布：主要工具链、源代码、构建系统位于 Brook Park；Sacramento 用于灾难恢复与业务连续性
+- 数据流架构：源代码流（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境
+
+## Key Quotes
+> "The main ingredient in the supply chain is our source code, our IP that is intended to live in GitLab." — Arnold Dacan，阐述源代码作为供应链核心的战略定位
+
+> "We are trying to standardize in GitLab, Artifactory, PMS and UCMDB are backend services that have started to grow and will grow further for supply chain security." — Arnold Dacan，阐述工具链标准化与供应链安全的关联
+
+## Key Concepts
+- [[Project Thor]]：OpenText 主导的源代码供应链安全与开发者平台标准化项目，五大支柱涵盖敏捷治理、发布治理、开发者门户、安全和 Build Hub
+- [[Supply Chain Security]]：源代码供应链安全——源代码作为核心 IP，通过 GitLab 集中管理，构建流程全程可追溯
+- [[Build Hub]]：Project Thor 五大支柱之一，构建系统集中化管理平台
+- [[GitLab Proxy]]：通过 GitLab 代理解决网络连通性问题，支持分布式团队访问源代码
+- [[GitLab Geo]]：GitLab 地理分布式部署，支持灾难恢复与业务连续性
+- [[Code Signing]]：代码签名流程，确保构建产物的完整性与来源可信
+
+## Key Entities
+- [[Arnold Dacan]]：Project Thor 平台与数据流分享的主讲人，OpenText 技术负责人
+- [[GitLab]]：OpenText 选定的源代码控制黄金标准（替代 GitHub Enterprise）
+- [[Artifactory]]：构建产物仓库，Project Thor 工具链核心组件
+- [[Backstage]]：开发者门户（Backstage.io），Project Thor 五大支柱之一
+- [[UCMDB]]：统一配置管理数据库，后端服务组件
+- [[Brook Park]]：OpenText 网络工具链主站点（源代码、构建系统所在）
+- [[Sacramento]]：灾难恢复与业务连续性站点
+- [[Micro Focus]]：OpenText 收购的公司，Project Thor 整合了其原有工具链
+
+## Connections
+- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] ← extends ← [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]
+- [[ctp-topic-21-supply-chain-security-in-micro-focus]] ← related_to ← [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]
+
+## Contradictions
+- 无已知冲突内容
--- 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,60 @@
+---
+title: "Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123"
+type: source
+tags:
+  - Tagging-Standard
+  - FinOps
+  - AWS
+  - Azure
+  - GCP
+  - Cloud-Governance
+date: 2024-01-23
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText 跨超大规模云厂商（AWS、Azure、GCP）的统一标签标准
+- 问题域：云成本优化、FinOps 治理、资源归属追踪
+- 方法/机制：OT_ 前缀标签设计、GCP 限制性字符集作为最低通用标准、Terraform 默认标签注入、SCP 强制执行标签合规
+- 结论/价值：标准于 10 月 3 日获批，目标将云资源浪费从行业平均 30% 降至 15%，预计每年节省约 2500 万美元，提升可持续性
+
+## Key Claims（用中文描述）
+- OpenText 未来三年超大规模云支出预计约 5 亿美元，统一标签标准可将浪费率从 30% 降至 15%
+- 将云浪费率降低 50% 可为 OpenText 每年节省约 2500 万美元，同时改善可持续性
+- 正式财务组织由 Tom Bice 领导，专注于跨业务部门提供报告，要求通过标签实现资源详细标注
+- 标签管道：计费控制台启用特定标签 → COST 和使用报告（CUR）包含标签值 → 通过 HCMX、Phenops、QuickSight、Power BI 报告
+- 标准采用最低通用标准原则：GCP 的限制性字符集（小写、数字、连字符、下划线）
+- 标签使用 OT_ 前缀区分，但环境、BU、成本中心等已有标签除外
+- 标准由工作组历时三个月开发，已于去年 10 月 3 日批准
+- Terraform 模块（如 AWS 实例模块）可通过 tags 参数实现默认标签注入
+- 未来计划通过 SCP 或标签策略强制执行 99% 资源标签率目标
+
+## 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, so like the AWS instance module there, there's a tags parameter that you could use." — 关于 Terraform 标签实现的最佳实践
+
+## Key Concepts
+- [[FinOps]]：云财务管理，通过标签实现成本分配、优化和报告
+- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略，通过「显式拒绝」逻辑强制执行标签规范
+- [[Tag-Based-Security]]：基于标签的安全控制机制，将资源标签作为安全凭证替代传统 IP 规则
+- [[Terraform-Tagging]]：通过 Terraform provider 定义和模块 tags 参数实现默认标签注入
+- [[Multi-Cloud-Governance]]：跨 AWS、Azure、GCP 的统一标签治理标准
+
+## Key Entities
+- [[Tom Bice]]：OpenText 财务组织负责人，主导跨业务部门的 FinOps 报告工作
+
+## Connections
+- [[public-cloud-learning-sessions-opentext-tagging-standard-v2]] ← extends ← 本页
+  - v2 在 v1 基础上扩展，覆盖 Kubernetes 对象和容器镜像标签
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← relates_to ← 本页
+  - Topic 10 详细描述了基于标签的安全控制机制和 SCP 强制执行
+- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← 本页
+  - Tag Validation Tool 实现了对 AWS 资源标签合规性的自动化审计
+- [[AWS-Tagging-Standards]] ← is_part_of ← [[OpenText-Tagging-Standard]]
+  - OpenText 标签标准是 AWS 标签规范的扩展，定义了跨云统一标准
+
+## Contradictions
+- 无明显冲突。该标准与现有 AWS 标签实践互补，统一了跨 AWS、Azure、GCP 的标签语义