Auto-sync: 2026-04-29 04:03

wiki/concepts/AWS-End-User-Computing.md

@@ -0,0 +1,76 @@
+---
+title: "AWS End User Computing"
+type: concept
+tags:
+  - AWS
+  - End-User-Computing
+  - Virtual-Desktop
+  - Cloud-DevOps
+sources:
+  - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee
+last_updated: 2026-05-11
+---
+
+## AWS End User Computing（AWS 终端用户计算）
+
+AWS 终端用户计算（AWS End User Computing，EUC）服务组合是 AWS 为支持远程/混合工作模式而提供的虚拟桌面和应用程序流解决方案组合。核心价值：帮助组织在远程工作时代保护终端、保护 IP 和数据，同时维持生产力并控制成本。
+
+## AWS EUC Portfolio（四大服务）
+
+| 服务 | 类型 | 持久性 | 适用场景 |
+|------|------|--------|----------|
+| [[Amazon-Workspaces]] | 全持久虚拟桌面 | 完全持久 | 知识工作者、需要完整桌面环境 |
+| [[AppStream-2]] | 应用程序流/虚拟桌面 | 选择持久 | 实验室、培训、堡垒主机、非持久桌面 |
+| [[Workspace-Core]] | 第三方 VDI API 集成 | — | Horizon View、Citrix 等第三方 VDI |
+| [[Workspace-Web]] | 安全浏览器 | 非持久 | 访问内部网站和 SaaS 应用 |
+
+## Core Design Decisions
+
+### 持久性对比
+- **全持久桌面**（Workspaces）：一对一实例管理，应用状态和设置在会话之间保持
+- **非持久桌面**（AppStream）：每次登录全新桌面，可通过应用连接器和存储连接器实现部分持久化
+
+### 成本优化机制
+- **AppStream 并发使用**：多用户共享实例（多租户模式）
+- **Workspaces 自动停止**：减少空闲资源成本
+
+### 协议
+- **WSP 协议**（Workspaces Streaming Protocol）：专为高延迟网络设计的流传输协议
+
+## Security Posture（安全姿态）
+
+> *"With so many remote workers organizations are struggling to protect endpoints, as well as their IP and data from bad actors."* — [[Christian-ODonough]]
+
+安全措施包括：
+- Active Directory 集成
+- 加密（静态和传输中）
+- IAM 配置文件
+- 多因素认证（MFA）
+- 设备证书
+- VPC Interface Endpoints（私有连接）
+- SAML-based Authentication
+
+## Architecture
+
+AWS EUC 架构包含两类 VPC：
+1. **Service VPC**：AWS 托管
+2. **Customer VPC**：客户管理
+
+每个 Workspaces 有两个网络接口连接两类 VPC。
+
+## DR Considerations
+
+灾难恢复策略：
+- 跨 AWS 区域构建 Workspaces
+- 利用 AppStream 自动扩展能力
+
+## Connections
+- [[Amazon-Workspaces]] ← is_a ← [[AWS-End-User-Computing]]
+- [[AppStream-2]] ← is_a ← [[AWS-End-User-Computing]]
+- [[Workspace-Core]] ← is_a ← [[AWS-End-User-Computing]]
+- [[Workspace-Web]] ← is_a ← [[AWS-End-User-Computing]]
+- [[Amazon-VPC]] ← depends_on ← [[AWS-End-User-Computing]]
+- [[Active-Directory-Integration]] ← depends_on ← [[AWS-End-User-Computing]]
+
+## Sources
+- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]

wiki/concepts/AWS-Identity-Center.md

@@ -0,0 +1,38 @@
+---
+title: "AWS Identity Center"
+type: concept
+tags:
+  - AWS-Identity-Center
+  - IAM
+  - Identity-Governance
+  - SSO
+sources:
+  - learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re
+last_updated: 2023-11-28
+---
+
+## AWS Identity Center
+
+AWS Identity Center（AWS 单点登录服务，原 AWS SSO）是 AWS 提供的跨账户身份与访问管理服务，为多账户 AWS 环境提供统一的身份认证和权限管理。
+
+## Core Function
+
+AWS Identity Center 通过 IAM 提供云资源访问控制，是 Micro Focus IGA 身份治理平台与 AWS 云资源之间的关键集成点。
+
+## Architecture Integration
+
+```
+User → IGA Portal → AD Groups (role mapping) → AWS Identity Center → IAM → AWS Resources
+         ↑                              ↑
+         └── Azure AD Domain Services (auth bridge)
+```
+
+## Related Concepts
+
+- [[Identity-Governance]]：身份治理框架，AWS Identity Center 是其 AWS 云端的实现基础
+- [[Micro-Focus-IGA]]：Micro Focus 身份治理平台，通过 AWS Identity Center 连接 AWS 资源
+- [[Active-Directory-Integration]]：AD 组映射到 IAM 角色的联合身份机制
+
+## Sources
+
+- [[learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re]]

wiki/concepts/Architecture-Roadmap.md

@@ -0,0 +1,30 @@
+---
+title: "Architecture Roadmap"
+type: concept
+tags: [Architecture, Planning, Governance, Cloud-Transformation]
+sources: ["ctp-topic-23-introduction-to-the-technical-architecture-team-and-function"]
+last_updated: 2026-05-11
+---
+
+## Definition
+Architecture Roadmap（技术架构路线图）是技术架构团队制定的 12-24 个月前瞻性技术规划，通过将技术栈划分为不同的"技术领域（Technical Domains）"并由首席架构师负责，实现从"救火式"被动响应到预测性主动规划的转变。
+
+## Core Purpose
+- **风险规避**：帮助业务部门预见技术风险，提前规划应对措施
+- **预算优化**：通过前瞻性规划，避免临时采购和紧急开支
+- **交付加速**：减少技术债务积累，提升交付速度
+- **价值聚焦**：将业务部门从繁杂的基础设施维护中解放出来，专注于为客户创造价值
+
+## Planning Horizon
+- **12-24 个月**：短期至中期前瞻规划窗口
+- 覆盖身份认证、网络、Microsoft 堆栈等各技术领域
+- 每条路线图由对应技术领域的首席架构师负责
+
+## Relationship to Other Concepts
+- [[EA-SA-TA-Framework]] — 路线图由 TA 层制定，EA 层审核战略一致性
+- [[Technical-Architecture-Domains]] — 路线图按技术领域划分，每个领域独立规划
+- [[Cloud-First-Policy]] — 路线图遵循 Cloud-First 策略，除非有充分理由保留本地
+
+## Connections
+- [[Martin-Nash]] — 路线图规划的主要推动者
+- [[Cloud-Transformation-Programme]] — 路线图服务于云转型整体战略

wiki/concepts/Artifact-Repo.md

@@ -0,0 +1,61 @@
+---
+title: "Artifact Repo（制品仓库）"
+type: concept
+tags: [Artifact-Repo, DevOps, CI/CD, OpenText, Thor, Artifactory]
+sources:
+  - public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806
+last_updated: 2026-05-11
+---
+
+## Artifact Repo（制品仓库）
+
+Artifact Repo 是存储 CI/CD 流水线产出的二进制文件（如 JAR、Docker 镜像、安装包等）的仓库。在 OpenText 环境中，制品仓库通过 Artifactory 管理，并在 Product Hub（PHT）中映射权限。
+
+## 与 Source Repo 的区别
+
+| 维度 | Source Repo | Artifact Repo |
+|------|------------|----------------|
+| 存储内容 | 源代码 | 构建产物（二进制文件） |
+| 工具 | GitLab | Artifactory |
+| 权限管理 | PHT 中映射 Source Repo 权限 | PHT 中管理 Artifact Repo 权限 |
+| 新结构默认启用 | 否（需手动映射） | 是（自动启用）|
+
+## 在 Product Hub 中的管理
+
+- Product 可以在 PHT 中映射 Artifact Repo
+- Artifact Repo 权限为新结构默认启用
+- 与 Product Hierarchy 关联：每个 Product 可以关联多个 Source Repo 和 Artifact Repo
+
+## 与 CI/CD Pipeline 的关系
+
+[[CI/CD Pipeline]] 的产出（构建产物）存储于 Artifact Repo：
+
+```
+代码提交 → GitLab (Source Repo)
+       ↓
+  CI/CD Pipeline 执行
+       ↓
+  构建产物生成
+       ↓
+  Artifactory (Artifact Repo)
+       ↓
+  部署到客户环境
+```
+
+## 与 Product Hub 的集成
+
+[[Product Hub (PhD)]] 管理 Artifact Repo 的：
+- 权限配置
+- 与产品的关联关系
+- 跨团队访问控制
+
+## Connections
+
+- [[Artifact-Repo]] ← managed_by ← [[Product Hub (PhD)]]
+- [[Artifact-Repo]] ← stores ← CI/CD Pipeline 输出
+- [[Artifact-Repo]] ← provided_by ← Artifactory
+- [[Artifact-Repo]] ← associated_with ← Product Hierarchy
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806]]

wiki/concepts/BOSCARD.md

@@ -0,0 +1,48 @@
+---
+title: "BOSCARD"
+type: concept
+tags: [Business-Analysis, Requirements, Project-Management]
+sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
+last_updated: 2026-05-11
+---
+
+## Definition
+
+BOSCARD 是一个用于定义复杂新工作的结构化框架，通过八个维度全面澄清项目背景和关键要素。
+
+## BOSCARD 八要素
+
+| 字母 | 要素 | 含义 |
+|------|------|------|
+| **B** | Background | 背景——为什么需要这项工作？ |
+| **O** | Objectives | 目标——我们希望实现什么？ |
+| **S** | Scope | 范围——包含什么？不包含什么？ |
+| **C** | Constraints | 约束——时间、预算、技术等限制条件 |
+| **A** | Assumptions | 假设——我们认为哪些前提条件是成立的？ |
+| **R** | Risks | 风险——可能出错的因素有哪些？ |
+| **R** | Roles | 角色——谁负责什么？ |
+| **D** | Deliverables | 交付物——最终产出是什么？ |
+
+## Key Quote
+
+> "If you can get scope tied down early on and agreed, that's priceless."
+
+范围（Scope）的早期锁定和达成共识是无价的——这正是 BOSCARD 的核心价值所在。
+
+## Application Scenario
+
+BOSCARD 特别适用于：
+- 新项目的立项定义
+- 复杂需求的澄清会议
+- 变更请求的评估
+- 跨团队协作的初始对齐
+
+## Relationship to Other Concepts
+
+- [[Business-Analysis]]：BOSCARD 是业务分析的核心技法之一
+- [[Stakeholder-Wheel]]：BOSCARD 通常在识别干系人之后使用
+- [[Requirements-Gathering]]：BOSCARD 定义的范围指导后续的需求收集
+
+## Aliases
+- BOSCARD Technique
+- 复杂工作定义框架

wiki/concepts/BYOD.md

@@ -0,0 +1,41 @@
+---
+title: "BYOD"
+type: concept
+tags:
+  - BYOD
+  - End-User-Computing
+  - Security
+  - Hybrid-Work
+sources:
+  - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee
+last_updated: 2026-05-11
+---
+
+## BYOD（Bring Your Own Device）
+
+BYOD（自带设备）是一种企业工作模式，允许员工使用个人设备（笔记本、平板、手机）访问企业资源。[[AWS-End-User-Computing]] 将 BYOD 作为重要适用场景。
+
+## Why BYOD Matters for EUC
+
+BYOD 对终端安全带来挑战：
+- 数据可能存储在员工个人设备上
+- 设备安全状态不可控
+- 设备丢失/被盗风险
+
+VDI/EUC 解决方案通过将工作负载保留在云端（数据不落盘到端点）来缓解这些风险。
+
+## AWS EUC 支持 BYOD 的方式
+
+| 服务 | BYOD 支持方式 |
+|------|--------------|
+| [[Amazon-Workspaces]] | 虚拟桌面在云端运行，数据不存储在个人设备 |
+| [[AppStream-2]] | 应用流在云端运行，端点无数据残留 |
+| [[Workspace-Web]] | 纯浏览器访问，无本地数据 |
+
+## Related Concepts
+- [[AWS-End-User-Computing]]
+- [[Virtual-Desktop-Infrastructure]]
+- [[Zero-Trust-Access]]
+
+## Sources
+- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]

wiki/concepts/Business-Analysis.md

@@ -0,0 +1,61 @@
+---
+title: "Business Analysis"
+type: concept
+tags: [Business-Analysis, Requirements, Agile]
+sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
+last_updated: 2026-05-11
+---
+
+## Definition
+
+业务分析（Business Analysis）是将业务需求与变更解决方案对齐的过程——连接业务问题与技术实现方案的桥梁。
+
+## Core Activities
+
+业务分析的核心活动包括五个步骤：
+
+1. **调查现状**（Investigate Current Situation）
+2. **分析需求**（Analyze Needs）
+3. **识别方案**（Identify Solutions）
+4. **评估选项**（Evaluate Options）
+5. **定义需求**（Define Requirements）
+
+## Scope
+
+业务分析涵盖的范围包括：
+- **IT系统变更**：定义IT系统的需求和变更方案
+- **流程变更**：分析和优化业务流程
+- **培训需求**：识别和支持人员培训需求
+- **角色转换**：管理组织角色和职责的变更
+
+## Business Value
+
+> "Business analysis helps us work out what changes will be beneficial in our business architecture, including changes to IT systems and defining the requirements for those changes."
+
+业务分析的核心价值在于：
+- **清晰性**：明确目标和交付物
+- **一致性**：确保业务与技术对齐
+- **效率**：早期发现问题，避免返工
+
+## Key Techniques
+
+业务分析师使用的核心技法包括：
+- [[BOSCARD]]：复杂新工作的定义框架
+- [[Stakeholder-Wheel]]：干系人识别工具
+- [[Requirements-Gathering]]：结合元数据的需求收集方法
+- [[INVEST]]：优质用户故事检查原则
+
+## Related Concepts
+
+- [[T-Shaped-Skills]]：业务分析师所需的核心技能模型
+- [[SAFe]]：规模化敏捷框架中的需求层次
+- [[RACI]]：责任分配矩阵
+
+## Learning Resources
+
+- **BCS**（英国计算机学会）：业务分析课程与认证
+- **IIBA**（国际商业分析协会）：CBAP等专业认证
+
+## Aliases
+- BA
+- 业务分析

wiki/concepts/Cloud-First-Policy.md

@@ -0,0 +1,53 @@
+---
+title: "Cloud-First Policy"
+type: concept
+tags: [Cloud, Strategy, Policy, Governance]
+sources: ["ctp-topic-53-why-bother-with-cloud"]
+last_updated: 2026-05-10
+---
+
+## Definition
+
+Cloud-First Policy（云优先策略）是一种组织级技术政策，要求在同等条件下优先选择云解决方案而非本地部署。云优先不是简单的"必须上云"，而是将云视为新工作负载的首选部署目标，同时承认某些场景下本地部署仍有合理性。
+
+## Core Principles
+
+1. **新工作负载默认上云**：所有新应用和服务优先考虑云部署
+2. **迁移优先于新建**：新功能优先通过迁移现有工作负载实现，而非新建本地基础设施
+3. **云原生服务优先**：优先使用云平台提供的托管服务（如 RDS、Lambda），而非自建
+4. **持续评估**：定期评估现有工作负载，确定哪些应迁移到云
+
+## Benefits (from CTP Context)
+
+[[ctp-topic-53-why-bother-with-cloud]] 中阐述的云优先核心价值：
+
+- **创新赋能**：为产品团队提供安全、有韧性的平台，更快速地交付新功能
+- **成本优化**：按需付费模型 + 预留实例，消除本地基础设施的固定成本
+- **弹性扩展**：云平台天然支持业务高峰期的弹性伸缩
+- **灾备改善**：多可用区、多区域架构提供比本地更高的可用性
+- **市场拓展**：快速在新地区部署，开拓新收入机会
+
+## Cloud-First vs Cloud-Only
+
+| 维度 | Cloud-First | Cloud-Only |
+|------|------------|------------|
+| 本地部署 | 仅在有充分理由时保留 | 不允许 |
+| 遗留系统 | 制定迁移路线图 | 强制迁移 |
+| 混合云 | 接受作为过渡态 | 视为技术债 |
+| 合规要求 | 满足即可，云或本地均可 | 仅云满足 |
+
+## Challenges
+
+- **数据主权**：某些数据因合规原因不能上云
+- **延迟敏感**：高频交易等场景对延迟要求极高
+- **成本固定**：对于稳定的高负载，本地可能更经济
+- **技术债**：迁移遗留应用成本高、风险大
+
+## Related Concepts
+
+- [[Landing-Zone-Architecture]]：云优先策略在 AWS 的落地架构
+- [[Urban-Sprawl]]：云优先是对抗数据中心蔓延的战略
+
+## Related Sources
+
+- [[ctp-topic-53-why-bother-with-cloud]] — 云优先作为 CTP 核心战略

wiki/concepts/Code-Signing.md

@@ -0,0 +1,62 @@
+---
+title: "Code Signing"
+type: concept
+tags: [Code-Signing, Software-Supply-Chain, Security, Cryptography, DevOps, OpenText]
+sources:
+  - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet
+last_updated: 2026-05-11
+---
+
+## Code Signing
+
+Code Signing（代码签名）是软件供应链安全的关键机制，通过数字签名确保构建产物的完整性和来源可信，是 Project Thor 供应链安全战略的核心环节。
+
+## Code Signing
+
+Code Signing is a critical mechanism for software supply chain security that uses digital signatures to ensure the integrity and trustworthiness of build artifacts. It is a core component of Project Thor's supply chain security strategy.
+
+## Aliases
+- Code Signing
+- 代码签名
+- 软件签名
+
+## Key Facts
+
+| 维度 | 说明 |
+|------|------|
+| 目的 | 确保构建产物完整性 + 来源可信 |
+| 位置 | 供应链数据流：Build Farms → Artifactory 之间 |
+| 隶属于 | [[Project-Thor]] 安全与治理支柱 |
+| 关键原则 | 构建产物在交付客户环境前必须经过签名验证 |
+
+## 供应链安全中的角色
+
+```
+GitLab（源代码）
+    ↓
+Build Farms（制造流程）
+    ↓ Code Signing（签名）
+Artifactory（制品仓库）
+    ↓
+客户环境
+```
+
+Arnold Dacan 强调源代码的供应链核心地位，而 Code Signing 则确保从构建到交付的全链路可信赖。
+
+## 与 Supply Chain Security 的关系
+
+Code Signing 是 [[Supply Chain Security]] 的关键技术手段之一：
+- 确保制品未被篡改（完整性验证）
+- 验证构建来源（身份认证）
+- 防止供应链攻击（如依赖注入、恶意构建）
+
+## Connections
+
+- [[Code-Signing]] ← security_practice ← [[Project-Thor]]
+- [[Code-Signing]] ← secures ← [[Supply-Chain-Security]]
+- [[Code-Signing]] ← part_of ← 供应链数据流（Build Farms → Artifactory）
+- [[GitLab]] ← provides ← Source → [[Code-Signing]] 验证
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]

wiki/concepts/EA-SA-TA-Framework.md

@@ -0,0 +1,38 @@
+---
+title: "EA-SA-TA Framework"
+type: concept
+tags: [Enterprise-Architecture, Solution-Architecture, Technical-Architecture, Cloud-Governance]
+sources: ["ctp-topic-23-introduction-to-the-technical-architecture-team-and-function"]
+last_updated: 2026-05-11
+---
+
+## Definition
+EA-SA-TA Framework 是 OpenText 云转型办公室采用的三层架构职能分工体系，通过明确的职责边界实现从业务战略到技术实施的完整覆盖。
+
+## Layer Breakdown
+
+### Enterprise Architecture (EA) — 企业架构
+- **定位**：最顶层，对接业务战略
+- **职责**：将业务目标转化为技术原则和标准，确保技术投资与商业战略一致
+- **核心问题**：我们应该在哪些技术领域进行投资？如何与技术战略保持一致？
+
+### Solution Architecture (SA) — 方案架构
+- **定位**：中间层，连接 EA 与 TA
+- **职责**：专注于特定项目或服务的优化实施，确保系统组件间的高效协作
+- **核心问题**：针对特定项目，什么是最佳的技术解决方案？
+
+### Technical Architecture (TA) — 技术架构
+- **定位**：最底层，贴近技术实施
+- **职责**：负责具体基础设施的设计、实施治理以及技术路线图的维护
+- **核心问题**：如何实施和维护技术基础设施？技术路线图如何规划？
+
+## Design Rationale（from Martin Nash）
+- 大型组织（PSTC + IT 合并至 CIO）需要清晰的架构分工
+- 三层分工使技术治理从"救火式"转向"主动规划"
+- EA 负责战略方向，SA 负责方案优化，TA 负责落地执行，分工明确减少职责重叠
+
+## Connections
+- [[Cloud-First-Policy]] — EA 层制定的云优先技术原则
+- [[AWS-Enterprise-Landing-Zone]] — TA 层维护的标准化基础设施
+- [[Architecture-Roadmap]] — TA 层制定的 12-24 个月路线图
+- [[Cloud-Transformation-Programme]] — 三层架构体系的组织背景

wiki/concepts/GitLab-Geo.md

@@ -0,0 +1,55 @@
+---
+title: "GitLab Geo"
+type: concept
+tags: [GitLab-Geo, GitLab, Disaster-Recovery, Business-Continuity, Multi-Site, OpenText]
+sources:
+  - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet
+last_updated: 2026-05-11
+---
+
+## GitLab Geo
+
+GitLab Geo 是 GitLab 的地理分布式部署方案，支持跨地域数据复制和灾难恢复，是 OpenText Project Thor 业务连续性战略的关键组成部分。
+
+## GitLab Geo
+
+GitLab Geo is GitLab's geo-distributed deployment solution supporting cross-region data replication and disaster recovery, serving as a key component of OpenText's Project Thor business continuity strategy.
+
+## Aliases
+- GitLab Geo
+- GitLab Geo Replication
+
+## Key Facts
+
+| 维度 | 说明 |
+|------|------|
+| 部署模式 | 地理分布式多站点 |
+| 主站点 | Brook Park（GitLab 主实例） |
+| 灾备站点 | Sacramento（业务连续性） |
+| 功能 | 源代码仓库跨地域复制、读写分离 |
+| 隶属 | [[Project-Thor]] 基础设施层 |
+
+## 灾难恢复架构
+
+```
+Brook Park（主站点）
+    ↓ GitLab Geo 复制
+Sacramento（灾备站点）
+```
+
+OpenText 的 GitLab Geo 部署策略：
+- 主实例运行在 Brook Park（工具链主站点）
+- Sacramento 作为灾难恢复和业务连续性站点
+- 通过 GitLab 内置 Geo 功能实现实时数据同步
+
+## Connections
+
+- [[GitLab-Geo]] ← infrastructure ← [[Project-Thor]]
+- [[GitLab-Geo]] ← primary_site ← [[Brook-Park]]
+- [[GitLab-Geo]] ← disaster_recovery_site ← [[Sacramento]]
+- [[GitLab]] ← provides ← [[GitLab-Geo]]（GitLab 内置功能）
+- [[GitLab-Proxy]] ← complements ← [[GitLab-Geo]]（Proxy 管访问，Geo 管复制）
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]

wiki/concepts/GitLab-Proxy.md

@@ -0,0 +1,48 @@
+---
+title: "GitLab Proxy"
+type: concept
+tags: [GitLab-Proxy, GitLab, Network-Proxy, DevOps, Connectivity, OpenText]
+sources:
+  - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet
+last_updated: 2026-05-11
+---
+
+## GitLab Proxy
+
+GitLab Proxy 是 OpenText 在 Brook Park 部署的 GitLab 代理服务，用于解决分布式团队访问源代码的网络连通性问题，是 Project Thor 工具链基础设施的关键组件。
+
+## GitLab Proxy
+
+GitLab Proxy is a proxy service deployed at Brook Park by OpenText to resolve network connectivity issues for distributed teams accessing source code repositories. It is a key infrastructure component of the Project Thor toolchain.
+
+## Aliases
+- GitLab Proxy
+- GitLab Proxy Server
+
+## Key Facts
+
+| 维度 | 说明 |
+|------|------|
+| 部署位置 | Brook Park（OpenText 工具链主站点） |
+| 功能 | 源代码访问网络代理 |
+| 解决的问题 | 分布式团队跨网络的 GitLab 连通性 |
+| 隶属 | [[Project-Thor]] 基础设施层 |
+
+## 使用场景
+
+OpenText 工程师遍布多个地理位置，通过 GitLab Proxy 解决：
+
+- Micro Focus 遗留网络与 OpenText 网络之间的连通性差异
+- 外部网络访问内部 GitLab 仓库的需求
+- 灾难恢复场景下的备份访问路径
+
+## Connections
+
+- [[GitLab-Proxy]] ← infrastructure ← [[Project-Thor]]
+- [[GitLab-Proxy]] ← located_at ← [[Brook-Park]]
+- [[GitLab]] ← serves ← [[GitLab-Proxy]]（代理 GitLab 访问）
+- [[GitLab-Geo]] ← complements ← [[GitLab-Proxy]]（Geo 提供跨地域复制，Proxy 提供访问）
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]

wiki/concepts/IGA.md

@@ -0,0 +1,57 @@
+---
+title: "IGA"
+type: concept
+tags:
+  - Identity-Governance
+  - IAM
+  - Access-Management
+sources:
+  - learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re
+last_updated: 2026-05-11
+---
+
+## IGA (Identity Governance and Administration)
+
+IGA（身份治理与管理）是一个企业级身份管理框架，涵盖身份生命周期管理和访问治理两大支柱。
+
+## Core Components
+
+### Identity Management（身份管理）
+- 数字身份的创建、维护和生命周期管理
+- 用户、组和角色的定义
+- 入职/转岗/离职的权限变更
+
+### Access Management（访问管理）
+- 控制谁可以访问哪些资源
+- 认证（Authentication）和授权（Authorization）
+
+### Identity Auditing（身份审计）
+- 权限变更追踪
+- 合规性报告
+- 异常检测
+
+## IGA vs IAM
+
+| 维度 | IGA（身份治理） | IAM（身份与访问管理） |
+|------|----------------|----------------------|
+| 焦点 | 治理、合规、策略 | 操作、技术实现 |
+| 问题 | 谁应该有权访问？ | 如何实现访问控制？ |
+| 受众 | 审计员、合规官、业务经理 | IT 管理员、安全工程师 |
+| 工具 | 审批工作流、策略引擎 | 目录服务、SSO、MFA |
+
+## IGA Implementation
+
+Micro Focus IGA 的实现架构：
+```
+User → IGA Portal (申请) → 审批工作流 → AD 组更新 → AWS IAM → 云资源访问
+```
+
+## Related Concepts
+
+- [[Identity-Governance]]：IGA 是身份治理的具体实现
+- [[AWS-Identity-Center]]：AWS 身份中心的云端访问管理
+- [[Micro-Focus-IGA]]：Micro Focus 的 IGA 产品
+
+## Sources
+
+- [[learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re]]

wiki/concepts/INVEST.md

@@ -0,0 +1,44 @@
+---
+title: "INVEST"
+type: concept
+tags: [Agile, Requirements, User-Stories, Quality]
+sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
+last_updated: 2026-05-11
+---
+
+## Definition
+
+INVEST 是用于检查优质用户故事（User Story）的六项原则，由 Bill Wake 提出，是敏捷开发中需求质量保障的重要工具。
+
+## INVEST 六原则
+
+| 字母 | 原则 | 含义 | 反模式 |
+|------|------|------|--------|
+| **I** | Independent | 独立的——不与其他故事重复或依赖 | 包含另一个故事的内容 |
+| **N** | Negotiable | 可协商的——业务方描述需求，技术方开放实现方式 | 过于详细的规定实现细节 |
+| **V** | Valuable | 有价值的——对用户或客户有实际价值 | 只描述技术任务而无业务价值 |
+| **E** | Estimable | 可估算的——团队能够估算工作量 | 需求描述过于模糊无法估算 |
+| **S** | Small | 小型的——能在单个迭代中完成 | 需要跨越多个迭代才能完成 |
+| **T** | Testable | 可测试的——能够验证是否完成 | 没有明确的验收标准 |
+
+## Key Quote
+
+> "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."
+
+## Usage
+
+INVEST 常用于：
+- 冲刺规划前的故事评审
+- Product Backlog 的梳理会议
+- 需求审查和质量把控
+
+## Relationship to Other Concepts
+
+- [[Requirements-Gathering]]：INVEST 是需求收集的质量检查工具
+- [[SAFe]]：在 SAFe 框架中，Feature 和 User Story 均适用 INVEST 检查
+- [[Business-Analysis]]：业务分析师负责确保需求符合 INVEST 原则
+
+## Aliases
+- INVEST Criteria
+- INVEST 原则
+- Bill Wake INVEST

wiki/concepts/OpenText-Tagging-Standard.md

@@ -0,0 +1,99 @@
+---
+title: "OpenText Tagging Standard"
+type: concept
+tags:
+  - Cloud-Governance
+  - FinOps
+  - Tagging
+  - Multi-Cloud
+last_updated: 2026-04-14
+---
+
+## Definition
+OpenText 标签标准是一套跨 AWS、Azure、GCP 三大云厂商的统一资源标签规范，通过标准化前缀和标签值集，实现云成本的精确归属、资源责任的明确划分和安全分类的自动化执行。
+
+## Version History
+
+| 版本 | 日期 | 覆盖范围 |
+|------|------|---------|
+| V1 | 2023-10-03 | 云账户、云资源（计算/存储/网络） |
+| V2 | 2025-04-29 | V1 + Kubernetes 对象 + 容器镜像 |
+
+## Standard Design Principles
+
+1. **最低共同标准**：采用 GCP 最严格字符集（小写、数字、连字符、下划线）
+2. **OT_ 前缀约定**：区分 OpenText 专有标签（云资源层面）
+3. **分层扩展**：V2 新增 `app.opentext.com`（K8s）和 `com.opentext.image`（容器镜像）前缀
+4. **实际可行**：优先考虑快速实施，而非完美方案
+
+## Standardized Tags
+
+### V1 Core Tags
+- `OT_BU` — 业务单元
+- `OT_Technical_Contact` — OT 技术联系人
+- `OT_Cost_Center` — 成本中心
+- `OT_Customer` — 客户
+- `OT_Tenant` — 租户
+- `OT_Environment` — 环境（生产/实验室/客户数据）
+- `OT_Master_Product` — OT 主产品
+- `OT_Custom_Field_*` — 自定义字段
+- `OT_Platform` — 平台
+- `OT_Cost_Type` — 成本类型
+- `OT_Customer_Data` — 客户数据标识
+
+### V2 Extended Tags
+- **Kubernetes**: `app.opentext.com/*` 前缀
+- **Container Images**: `com.opentext.image/*` 前缀
+
+## Exceptions
+- `environment` — 已有通用约定，无需 OT_ 前缀
+- `BU` — 已有通用约定，无需 OT_ 前缀
+- `cost_center` — 已有通用约定，无需 OT_ 前缀
+- `name`（AWS）— AWS 保留标签，无需 OT_ 前缀
+
+## Implementation
+
+### Terraform Automation
+```hcl
+# 方式1: 模块参数
+aws_instance.example {
+  tags = {
+    OT_Environment  = "production"
+    OT_BU           = "engineering"
+    OT_Cost_Center  = "CC-12345"
+  }
+}
+
+# 方式2: Provider 默认标签
+provider "aws" {
+  default_tags {
+    tags = {
+      OT_Environment = "production"
+      OT_BU          = "engineering"
+    }
+  }
+}
+```
+
+### Tagging Pipeline
+```
+启用计费标签 → CUR (Cost and Usage Report) → 
+  → HCMX
+  → Phenops
+  → QuickSight
+  → Power BI
+```
+
+## Governance
+- **Owner**: FinOps 团队
+- **KPI**: 99% 可标签资源完成打标（通过 SCP 或标签策略强制）
+- **Documentation**: Confluence（产品短代码和 BU 列表）
+
+## Connections
+- [[FinOps]] — 标签标准由 FinOps 驱动，为成本优化提供基础设施
+- [[AWS-Tagging-Standards]] — OpenText 标准是 AWS 标签规范的扩展
+- [[Terraform]] — IaC 自动化打标工具
+
+## References
+- [[public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1]]（V1）
+- [[public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429]]（V2）

wiki/concepts/Product-Hierarchy.md

@@ -0,0 +1,52 @@
+---
+title: "Product Hierarchy（产品层级结构）"
+type: concept
+tags: [Product-Hub, PHT, Product-Management, OpenText, Thor]
+sources:
+  - public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806
+last_updated: 2026-05-11
+---
+
+## Product Hierarchy（产品层级结构）
+
+Product Hierarchy 是 OpenText Product Hub（PHT）中定义的三层组织结构，用于管理企业软件产品的归属关系和治理责任。
+
+## 结构定义
+
+| 层级 | 名称 | 说明 |
+|------|------|------|
+| 第一层 | Business Unit（业务单元，BU） | 含工程负责人和 PM 负责人 |
+| 第二层 | Line of Business（业务线，LOB） | 含业务线负责人和 PM Lead |
+| 第三层 | Product（产品） | 含产品经理（PM）和开发经理，关联主产品 |
+
+## 核心原则
+
+- **Product 定义**：具有独立 CI/CD 流水线或发布周期的软件分发
+- **Component 区分**：没有独立 CI/CD 流水线的库称为 Component；如果需要 ITLS 审查或扫描，应创建为 Product
+- **层级归属**：某组件可以是父产品的组成部分，但若其拥有独立的发布周期（独立 CI/CD 流水线），则应在 PHT 中作为独立 Product 处理
+
+## Product 状态
+
+| 状态 | 含义 |
+|------|------|
+| Active | 常规发布周期 |
+| Maintenance | 仅热修复/Bug 修复 |
+| Inactive | 无发布活动 |
+
+## 与 Product Hub 的关系
+
+[[Product Hub (PhD)]] 通过 Product Hierarchy 实现：
+- 统一产品视图
+- 跨工具链（元数据：属性、Source Repo、Artifact Repo、用户信息）一致性管理
+- 外部系统集成（Jira、Value Edge、PSMQ、ITLS、OSS、Backstage）
+
+## Connections
+
+- [[Product-Hierarchy]] ← managed_by ← [[Product Hub (PhD)]]
+- [[Product-Hierarchy]] ← belongs_to ← Business Unit
+- [[Product-Hierarchy]] ← belongs_to ← Line of Business
+- [[Product-Hierarchy]] ← defined_in ← [[Project Thor]]
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806]]

wiki/concepts/Project-Thor.md

@@ -0,0 +1,64 @@
+---
+title: "Project Thor"
+type: concept
+tags: [Project-Thor, OpenText, Micro-Focus, Toolchain, Integration]
+sources:
+  - public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20
+  - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet
+last_updated: 2026-05-11
+---
+
+## Project Thor
+
+Project Thor 是 OpenText 推动 Micro Focus 和 OpenText 工具链整合的核心战略项目，以 GitLab 作为集中化源代码控制系统，整合构建、发布、安全和治理全链条工具。
+
+## Overview
+
+Project Thor 的核心目标是将 Micro Focus 和 OpenText 的各类工具链统一为标准化平台，减少工具碎片化，提升供应链安全性和运维效率。
+
+## 五大支柱框架
+
+Project Thor 包含五大支柱（Five Pillars）：
+
+| 支柱 | 说明 |
+|------|------|
+| 敏捷周期治理 | 标准化开发流程和发布节奏 |
+| 产品发布治理 | 统一发布审批和版本管理 |
+| 开发者门户 Backstage | 开发者自助服务平台 |
+| 安全与治理 | 安全扫描、合规审计、供应链安全 |
+| Build Hub | 中心平台工程团队，管理核心构建工具 |
+
+## 核心数据流
+
+```
+源代码（GitLab）
+    ↓
+制造流程（Build Farms）
+    ↓
+制品库（Artifactory）
+    ↓
+客户环境
+```
+
+## 地理分布
+
+| 站点 | 角色 |
+|------|------|
+| Brook Park | 工具链主站点 |
+| Sacramento | 灾备站点 |
+
+## Key Quotes
+
+> "Project Thor aims to integrate Micro-Focus and OpenText tooling, with GitLab as the centralized system for source control." — [[Project-Thor]] 核心使命
+
+## Connections
+
+- [[GitLab]] ← integrates ← [[Project-Thor]]（GitLab 是 Thor 的集中化源代码控制核心）
+- [[Build-Hub]] ← implements ← [[Project-Thor]]（Build Hub 是五大支柱之一）
+- [[PHT-Product-Hub-Platform]] ← part_of ← [[Project-Thor]]
+- [[OpenText]] ← drives ← [[Project Thor]]
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]
+- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]

wiki/concepts/RACI.md

@@ -0,0 +1,54 @@
+---
+title: "RACI"
+type: concept
+tags: [Business-Analysis, Stakeholder-Management, Responsibility-Assignment]
+sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
+last_updated: 2026-05-11
+---
+
+## Definition
+
+RACI 是一个责任分配矩阵，用于明确项目或流程中每个干系人的角色和责任，确保职责清晰、避免责任真空或重叠。
+
+## RACI 四要素
+
+| 字母 | 角色 | 说明 | 示例 |
+|------|------|------|------|
+| **R** | Responsible（负责） | 执行具体任务的人 | 开发者编写代码 |
+| **A** | Accountable（问责） | 最终责任人，对结果负总责 | 技术负责人审批方案 |
+| **C** | Consulted（咨询） | 需要征询意见的人（双向沟通） | 安全团队审查设计 |
+| **I** | Informed（知情） | 需要被通知结果的人（单向沟通） | 项目经理接收进度更新 |
+
+## Key Rules
+
+- 每个任务**必须且仅有 1 个 A**（Accountable）——避免多头责任
+- R（Responsible）可以有多个——多人协作执行
+- C（Consulted）和 I（Informed）是可选的——根据需要添加
+
+## Application Scenario
+
+RACI 常用于：
+- 项目启动时的角色定义会议
+- 流程梳理和优化
+- 跨部门协作的责任明确
+- 变更管理中的角色澄清
+
+## Relationship to Other Concepts
+
+- [[Stakeholder-Wheel]]：RACI 是 Stakeholder Wheel 的深化工具，将干系人映射到具体任务
+- [[Business-Analysis]]：RACI 是业务分析师用于明确干系人责任的核心工具
+- [[BOSCARD]]：BOSCARD 中的 Roles 要素可进一步用 RACI 细化
+
+## Example
+
+| 任务 | 产品经理 | 开发者 | 测试工程师 | 技术负责人 |
+|------|---------|--------|-----------|----------|
+| 需求分析 | A | R | C | I |
+| 代码开发 | I | A/R | I | C |
+| 测试执行 | I | C | A/R | I |
+| 发布审批 | C | I | I | A |
+
+## Aliases
+- RACI Matrix
+- 责任分配矩阵
+- Responsibility Assignment Matrix

wiki/concepts/Repo-Mirroring.md

@@ -0,0 +1,49 @@
+---
+title: "Repo Mirroring"
+type: concept
+tags: [Repo-Mirroring, Git, Synchronization, Migration, GitHub, GitLab]
+sources:
+  - public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20
+last_updated: 2026-05-09
+---
+
+## Repo Mirroring
+
+Repo Mirroring（仓库镜像同步）是一种将源代码仓库从一个平台同步到另一个平台的方案，在 GitHub Enterprise → GitLab 迁移中作为两种主要迁移策略之一。
+
+## Definition
+
+镜像同步方案：在保留源 GitHub 仓库的同时，将仓库内容实时或定期同步到 GitLab，源仓库保持不变，允许双写（同时在两个平台操作）。
+
+## 适用场景
+
+- 需要在迁移过渡期保持 GitHub 仓库的外部访问权限
+- 有持续向 GitHub 提交的场景（如外部贡献者）
+- 团队希望在正式切换前有充足的验证时间
+
+## 优势
+
+- **降低风险**：源仓库保持不变，回滚成本低
+- **渐进迁移**：可以逐步增加 GitLab 的使用比例
+- **并行验证**：新旧平台同时可用，便于对比验证
+
+## 局限性
+
+- 双平台维护增加运营成本
+- 同步延迟可能导致代码不一致
+- 不解决 CI/CD 流水线迁移问题
+
+## 与 Shift and Lift 的对比
+
+| 维度 | Mirroring | Shift and Lift |
+|------|-----------|----------------|
+| 源仓库 | 保持不变 | 废弃 |
+| 流水线 | 保持原样 | 需重构 |
+| 风险 | 低 | 中高 |
+| 适用场景 | 过渡期验证 | 明确迁移决心后 |
+
+详见 [[Shift-and-Lift]] 迁移方案
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]

wiki/concepts/Requirements-Gathering.md

@@ -0,0 +1,60 @@
+---
+title: "Requirements Gathering"
+type: concept
+tags: [Business-Analysis, Requirements, Agile]
+sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
+last_updated: 2026-05-11
+---
+
+## Definition
+
+需求收集（Requirements Gathering）是将业务需求转化为可执行、可追踪的技术需求的过程。核心方法是将敏捷用户故事与结构化元数据相结合，为需求捕获增加严谨性。
+
+## User Story + Metadata Approach
+
+纯用户故事（As a... I want... So that...）虽然能捕获 what（做什么）、who（谁来做）和 why（为什么），但缺乏以下关键维度：
+
+| 元数据维度 | 说明 |
+|-----------|------|
+| **版本**（Version） | 需求的历史变更记录 |
+| **依赖**（Dependencies） | 与其他需求的关联关系 |
+| **可追溯性**（Traceability） | 从 Epic → Feature → Story 的完整链路 |
+| **时间**（Scheduling） | 计划交付时间 |
+| **验收标准**（Acceptance Criteria） | 如何判断需求完成 |
+| **分类**（Categorization） | 业务需求 / 技术需求 / 功能需求 |
+
+## Excel Template Example
+
+课程演示了车库业务（Garage Business）的需求管理 Excel 表，包含：
+- User Story 描述
+- 版本号
+- 依赖关系
+- 可追溯性链接
+- 计划时间
+- 验收标准
+- 分类标签（业务 / 技术 / 功能）
+
+## Relationship to SAFe
+
+在 [[SAFe]]（Scaled Agile Framework）中，需求层次为：
+- **Epic**（史诗）→ 大型业务价值单元
+- **Feature**（功能）→ 可独立交付的业务功能
+- **Capability**（能力）→ 跨团队的业务能力
+- **User Story**（用户故事）→ 具体用户视角的需求
+- **Non-Functional Requirements**（非功能需求）→ 性能、安全、可用性等
+
+## Relationship to Other Concepts
+
+- [[INVEST]]：INVEST 原则用于检查用户故事质量
+- [[BOSCARD]]：BOSCARD 定义的范围指导需求收集的方向
+- [[Business-Analysis]]：需求收集是业务分析的核心活动之一
+- [[Stakeholder-Wheel]]：干系人识别是需求收集的前提
+
+## Key Quote
+
+用户故事本身缺少严谨性，结合元数据后才能成为可管理的需求资产。
+
+## Aliases
+- 需求收集
+- 需求管理
+- User Story + Metadata

wiki/concepts/SAFe.md

@@ -0,0 +1,43 @@
+---
+title: "SAFe"
+type: concept
+tags: [Agile, Scaling, Framework, Requirements]
+sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
+last_updated: 2026-05-11
+---
+
+## Definition
+
+SAFe（Scaled Agile Framework，规模化敏捷框架）是一种将敏捷实践扩展到大型企业和跨团队组织的框架方法，提供从团队级到投资组合级的完整敏捷实施路径。
+
+## Requirements Hierarchy in SAFe
+
+SAFe 的需求层次与纯 Scrum 不同，包含更丰富的粒度：
+
+| 层级 | 名称 | 说明 |
+|------|------|------|
+| **Epic** | 史诗 | 最大业务价值单元，通常跨多个发布火车（Release Train） |
+| **Capability** | 能力 | 跨多个团队的业务能力，通常需要多个迭代 |
+| **Feature** | 功能 | 可独立交付的业务功能，有明确的投资回报 |
+| **User Story** | 用户故事 | 具体用户视角的需求，遵循 INVEST 原则 |
+| **Non-Functional Requirements (NFR)** | 非功能需求 | 性能、安全、可用性、可扩展性等质量属性 |
+
+## Why SAFe Matters
+
+纯用户故事（User Story）不足以管理大型企业的复杂需求：
+- **Epic** 提供战略对齐——确保每个功能都与业务目标关联
+- **Capability** 桥接战略与执行——跨团队的协调单元
+- **Feature** 是可度量的投资单元——支持 PI Planning（Program Increment Planning）
+- **NFR** 保障质量属性——避免只关注功能而忽视非功能需求
+
+## Relationship to Other Concepts
+
+- [[Requirements-Gathering]]：SAFe 提供了完整的需求层次结构
+- [[INVEST]]：User Story 层级需遵循 INVEST 原则
+- [[Business-Analysis]]：业务分析师负责定义 Epic 和 Feature 层级
+- [[T-Shaped-Skills]]：SAFe 团队需要 T 型技能人才
+
+## Aliases
+- Scaled Agile Framework
+- 规模化敏捷框架
+- SAFe Framework

wiki/concepts/SAML-Authentication.md

@@ -0,0 +1,41 @@
+---
+title: "SAML Authentication"
+type: concept
+tags:
+  - SAML
+  - Authentication
+  - SSO
+  - Security
+  - Identity
+sources:
+  - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee
+last_updated: 2026-05-11
+---
+
+## SAML Authentication
+
+SAML（Security Assertion Markup Language）是一种基于 XML 的开放标准身份认证协议，用于在身份提供商（IdP）和服务提供商（SP）之间交换认证和授权数据。[[AWS-End-User-Computing]] 中的 [[AppStream-2]] 支持 SAML-based Authentication。
+
+## How It Works in AWS EUC Context
+
+SAML 认证在 AWS EUC 中的典型流程：
+1. 用户向企业 IdP（如 Azure AD / Microsoft Entra ID）发起登录请求
+2. IdP 验证用户身份，生成 SAML 断言
+3. 断言转发给 AWS 服务（AppStream 2.0 或 Workspaces）
+4. AWS 基于断言授予访问权限
+
+## Benefits
+
+| 优势 | 说明 |
+|------|------|
+| **增强安全性** | 集中化身份管理，支持 MFA |
+| **简化用户体验** | 单点登录（SSO），无需单独记忆每个服务密码 |
+| **合规性** | 集中审计用户访问行为 |
+
+## Connections
+- [[AppStream-2]] ← uses ← [[SAML-Authentication]]
+- [[AWS-End-User-Computing]] ← supports ← [[SAML-Authentication]]
+- [[Active-Directory-Integration]] ← often_used_with ← [[SAML-Authentication]]
+
+## Sources
+- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]

wiki/concepts/Self-Serve-Product-Request.md

@@ -0,0 +1,75 @@
+---
+title: "Self-Serve Product Request（自助产品创建流程）"
+type: concept
+tags: [Product-Hub, PHT, Self-Serve, OpenText, Thor, Workflow]
+sources:
+  - public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806
+last_updated: 2026-05-11
+---
+
+## Self-Serve Product Request（自助产品创建流程）
+
+Self-Serve Product Request 是 OpenText Product Hub（PHT）中新建产品的核心理念——由产品经理或开发经理自行提交，经业务线（LOB）审批后生效，无需人工干预即可完成产品创建。
+
+## 流程概述
+
+```
+产品经理/开发经理
+        ↓
+   填写表单
+   - Business Unit (BU)
+   - Line of Business (LOB)
+   - Product Name
+   - Product Manager
+   - 开发经理
+   - 必需属性（如发布门控机制 P2M）
+        ↓
+   LOB 审批（业务线负责人审阅）
+        ↓
+   Product 创建完成
+```
+
+## 关键要求
+
+| 字段 | 说明 |
+|------|------|
+| Business Unit | 必填，产品归属的业务单元 |
+| Line of Business | 必填，产品归属的业务线 |
+| Product Name | 必填，官方产品名称 |
+| Product Manager | 必填，产品经理 |
+| 开发经理 | 必填 |
+| Release Gate Mechanism | 必填属性（如 P2M） |
+| Source Repo | 可选，源代码仓库映射 |
+| Artifact Repo | 可选，制品仓库映射 |
+| Dependencies | 可选，产品依赖关系 |
+| Product Teams/Guests | 可选，访问控制配置 |
+
+## 权限配置
+
+- **Engineering 类型**：全权访问（Owner）
+- **Moderator 类型**：维护者访问
+
+## GitLab 同步注意事项
+
+- Source Repo 在 GitLab 创建后，需 **24 小时**才在 PHT 中反映
+- 空的 Group/Repository 无法在 PHT 中被搜索到
+
+## 支持渠道
+
+- 产品名称/状态变更：`erphd@opentext.com`
+- 技术问题：`aangetoolsupport@opentext.com`
+
+## 与 Project Thor 的关系
+
+自助服务理念是 [[Project Thor]] 自服务模式的体现——各团队自主管理产品信息，平台提供基础设施支持，降低中央团队的行政负担。
+
+## Connections
+
+- [[Self-Serve-Product-Request]] ← managed_by ← [[Product Hub (PhD)]]
+- [[Self-Serve-Product-Request]] ← requires ← Product Hierarchy
+- [[Self-Serve-Product-Request]] ← part_of ← [[Project Thor]]
+- [[Self-Serve-Product-Request]] ← depends_on ← GitLab（Source Repo 同步延迟 24h）
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806]]

wiki/concepts/Service-Control-Policy.md

@@ -0,0 +1,87 @@
+---
+title: "Service Control Policy"
+type: concept
+tags:
+  - AWS
+  - Security
+  - Governance
+  - Multi-Account
+last_updated: 2026-04-14
+---
+
+## Definition
+AWS Service Control Policy（SCP，服务控制策略）是 AWS Organizations 中的一种策略类型，用于在组织单元（OU）或账户级别设置权限边界，限制成员账户可以使用的服务和操作。
+
+## Key Characteristics
+
+| 特性 | 描述 |
+|------|------|
+| **层级** | 组织级别（OU/账户），不覆盖 IAM 用户/角色 |
+| **效果** | Deny > Allow（显式拒绝优先） |
+| **评估逻辑** | 所有策略（SCP + IAM + 资源策略）取交集 |
+| **范围** | 仅限 AWS Organizations 中使用 |
+
+## SCP vs IAM Policy
+
+| 维度 | SCP | IAM Policy |
+|------|-----|------------|
+| **层级** | 组织/账户 | 用户/角色/资源 |
+| **默认效果** | 无限制（默认 FullAWSAccess） | 显式 Allow |
+| **继承** | 向下继承，OU 子级继承父级 SCP | 附加到身份/资源 |
+| **谁能修改** | Organization 管理账户 | IAM 管理员 |
+
+## Common Use Cases
+
+### 1. 限制Regions
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
+    {
+      "Sid": "DenyNonApprovedRegions",
+      "Effect": "Deny",
+      "NotAction": "*",
+      "Resource": "*",
+      "Condition": {
+        "StringNotEquals": {
+          "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
+        }
+      }
+    }
+  ]
+}
+```
+
+### 2. 强制标签合规
+SCP 可封禁未按要求添加特定标签（如 `OT_Environment`）的账户创建新资源。
+
+### 3. 阻止敏感服务
+```json
+{
+  "Effect": "Deny",
+  "Action": ["s3:*"],
+  "Resource": "*"
+}
+```
+
+## Connection to Tagging Standards
+
+OpenText 标签标准中提到，未来可能通过 SCP 强制执行 99% 打标率 KPI：
+- 要求所有云账户启用 OT_ 前缀标签
+- 拒绝未满足标签要求的资源创建请求
+- 与 [[Resource-Tagging]] 和 [[OpenText-Tagging-Standard]] 协同
+
+## Security Best Practices
+
+1. **最小权限原则**：始终从最严格开始，逐步放宽
+2. **测试环境优先**：在非生产 OU 测试 SCP 效果
+3. **FullAWSAccess 策略**：新 OU 默认允许全部，需显式限制
+4. **定期审计**：检查 SCP 是否影响新 AWS 服务/功能
+
+## Connections
+- [[AWS-Organizations]] — SCP 是 AWS Organizations 的核心功能
+- [[Multi-Cloud-Governance]] — SCP 是跨账户治理的 AWS 实现
+- [[OpenText-Tagging-Standard]] — SCP 用于强制执行标签合规性
+
+## References
+- [[public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1]]

wiki/concepts/Shift-and-Lift.md

@@ -0,0 +1,63 @@
+---
+title: "Shift and Lift"
+type: concept
+tags: [Shift-and-Lift, Migration, CI/CD, GitLab, GitHub, Refactoring]
+sources:
+  - public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20
+last_updated: 2026-05-09
+---
+
+## Shift and Lift
+
+Shift and Lift（搬移重构）是 GitHub Enterprise → GitLab 迁移中的两种主要策略之一：将代码直接复制到 GitLab，同时对 CI/CD 流水线进行转换和重构。
+
+## Definition
+
+Shift and Lift = 代码搬移（Shift）+ 流水线重构（Lift）
+- 将源代码一次性复制到 GitLab
+- 同时将 GitHub Actions/Jenkins 等流水线转换为 GitLab CI/CD
+- 源 GitHub 仓库在验证后废弃
+
+## 适用场景
+
+- 各团队已明确了解自身 GitHub 使用情况
+- 流水线可预测，重构工作量可控
+- 有足够技术能力进行 GitLab CI/CD 重构的团队
+
+## 迁移步骤（OpenText 建议）
+
+1. **盘点资产**：识别 GitHub 中所有仓库和流水线
+2. **规划流水线**：对照 GitLab CI/CD 语法设计目标流水线
+3. **代码迁移**：将代码复制到 GitLab 仓库
+4. **流水线实施**：配置 GitLab CI/CD pipelines
+5. **验证**：测试代码和流水线在 GitLab 的运行
+6. **废弃 GitHub**：确认无误后废弃源仓库
+7. **更新 PHT**：在 [[PHT（Product Hub Platform）]] 中更新映射状态
+
+## 迁移完成标准
+
+OpenText 定义的"Definition of Done"：
+1. ✅ 代码迁移完成
+2. ✅ 流水线转型完成
+3. ✅ [[PHT（Product Hub Platform）]] 更新完成
+
+## 核心挑战
+
+- **流水线复杂性**：GitHub Actions / Jenkins → GitLab CI 的语法差异
+- **凭证管理**：GitHub Secrets → GitLab CI Variables 的迁移
+- **网络连通性**：GitLab 代理配置（Brook Park GitLab Proxy）
+
+## 与 Repo Mirroring 的对比
+
+| 维度 | Shift and Lift | Mirroring |
+|------|----------------|-----------|
+| 源仓库 | 废弃 | 保持不变 |
+| 流水线 | 需重构 | 保持原样 |
+| 风险 | 中高 | 低 |
+| 适合团队 | 有规划能力 | 需要过渡期 |
+
+详见 [[Repo-Mirroring]] 迁移方案
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]

wiki/concepts/Stakeholder-Wheel.md

@@ -0,0 +1,68 @@
+---
+title: "Stakeholder Wheel"
+type: concept
+tags: [Business-Analysis, Stakeholder-Management, Communication]
+sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
+last_updated: 2026-05-11
+---
+
+## Definition
+
+干系人轮盘（Stakeholder Wheel）是一种结构化的干系人识别工具，从客户出发顺时针识别项目中所有类型的干系人，确保无一遗漏。
+
+## Wheel Structure（顺时针顺序）
+
+```
+         监管机构
+            ↑
+合作伙伴 ←  客户  → 竞争对手
+            ↓
+         员工
+            ↓
+         管理层
+            ↓
+         所有者
+```
+
+| 干系人类型 | 说明 | 示例 |
+|-----------|------|------|
+| **客户**（Customer） | 产品的直接使用者或购买者 | 内部用户、外部客户 |
+| **合作伙伴**（Partner） | 业务合作方 | 供应商、渠道商 |
+| **监管机构**（Regulator） | 行业或政府监管方 | GDPR 合规、PCI-DSS |
+| **员工**（Employee） | 组织内部成员 | 开发团队、运维团队 |
+| **管理层**（Management） | 决策层 | VP、Director、CIO |
+| **所有者**（Owner） | 投资方或资产所有者 | 股东、CFO |
+| **竞争对手**（Competitor） | 市场竞争者 | 竞品公司 |
+
+## Key Benefits
+
+- **早期识别**：在项目早期识别所有干系人，防止后期变更
+- **风险揭示**：发现可能被忽视的风险来源
+- **沟通规划**：为不同干系人制定针对性沟通策略
+
+## Complementary Tools
+
+### Power/Influence Grid
+根据干系人的权力（Power）和影响（Influence）进行优先级排序：
+- 高权力高影响 → 重点管理
+- 高权力低影响 → 保持满意
+- 低权力高影响 → 随时告知
+- 低权力低影响 → 最小关注
+
+### RACI Matrix
+RACI（Responsible/Accountable/Consulted/Informed）用于明确每个干系人在具体任务中的责任：
+- **R** — Responsible（负责）：执行者
+- **A** — Accountable（问责）：最终责任人
+- **C** — Consulted（咨询）：需要征询意见者
+- **I** — Informed（知情）：需要被通知者
+
+## Relationship to Other Concepts
+
+- [[Business-Analysis]]：干系人识别是业务分析的核心前置步骤
+- [[BOSCARD]]：BOSCARD 中的 Roles 要素与 Stakeholder Wheel 关联
+- [[RACI]]：RACI 矩阵是 Stakeholder Wheel 的深化工具
+
+## Aliases
+- 干系人轮盘
+- Stakeholder Mapping
+- 干系人识别工具

wiki/concepts/Supply-Chain-Security.md

@@ -0,0 +1,67 @@
+---
+title: "Supply Chain Security"
+type: concept
+tags: [Supply-Chain-Security, Software-Supply-Chain, DevSecOps, OpenText, Project-Thor, SBOM]
+sources:
+  - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet
+  - ctp-topic-21-supply-chain-security-in-micro-focus
+last_updated: 2026-05-11
+---
+
+## Supply Chain Security
+
+Supply Chain Security（供应链安全）是软件工程领域的核心安全实践，涵盖从源代码到客户交付全链路的安全性、可信赖性和可追溯性。OpenText 通过 Project Thor 将供应链安全作为工具链治理的核心理念。
+
+## Aliases
+- Supply Chain Security
+- 软件供应链安全
+- Supply Chain Security (SCS)
+
+## Key Facts
+
+| 维度 | 说明 |
+|------|------|
+| 核心要素 | 源代码（Source Code）作为供应链核心 IP |
+| 管理平台 | GitLab（集中化源代码控制） |
+| 标准化工具 | GitLab + Artifactory + UCMDB |
+| OpenText 战略 | Project Thor 五大支柱之一 |
+| 目标 | 全链路可追溯、防篡改、安全合规 |
+
+## 供应链数据流
+
+```
+GitLab（源代码 / IP）
+    ↓
+Build Farms（制造流程）
+    ↓ Code Signing（签名验证）
+Artifactory（制品仓库）
+    ↓
+客户环境
+```
+
+Arnold Dacan 的核心观点：
+
+> "The main ingredient in the supply chain is our source code, our IP that is intended to live in GitLab."
+
+## Project Thor 中的定位
+
+Supply Chain Security 是 [[Project-Thor]] 五大支柱之一（安全与治理支柱），与以下实践紧密关联：
+
+- [[Code-Signing]]：构建产物签名验证
+- [[GitLab]]：源代码集中化管理
+- [[Artifactory]]：制品仓库安全存储
+- [[UCMDB]]：配置管理可追溯性
+- [[GitLab-Geo]]：灾备与业务连续性
+
+## Connections
+
+- [[Supply-Chain-Security]] ← core_principle ← [[Project-Thor]]
+- [[Supply-Chain-Security]] ← protects ← 源代码（GitLab 作为核心 IP）
+- [[Supply-Chain-Security]] ← implements ← [[Code-Signing]]
+- [[Supply-Chain-Security]] ← stores ← [[Artifactory]]
+- [[Supply-Chain-Security]] ← relates_to ← [[DevSecOps]]
+
+## Sources
+
+- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]
+- [[ctp-topic-21-supply-chain-security-in-micro-focus]]

wiki/concepts/T-Shaped-Skills.md

@@ -0,0 +1,66 @@
+---
+title: "T-Shaped Skills"
+type: concept
+tags: [Skills, Agile, Business-Analysis]
+sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]
+last_updated: 2026-05-11
+---
+
+## Definition
+
+T 型技能（T-Shaped Skills）是一种人才技能模型，形容人才在某一领域具有深度专业能力（竖线），同时对相关领域具有广泛的理解和协作能力（横线）。
+
+## Visual Representation
+
+```
+        广度（相关技能理解）
+    ──────────────────────────────
+                │
+                │ 深度（核心专业能力）
+                │
+                │
+```
+
+## T 型技能的构成
+
+### 竖线（Depth）—— 核心专业深度
+在某一领域达到专家水平：
+- 深度技术技能
+- 领域专业知识
+- 解决问题的能力
+
+### 横线（Breadth）—— 相关技能广度
+对相关领域有基本理解和协作能力：
+- 业务流程理解
+- 跨职能沟通能力
+- 理解相邻领域的术语和约束
+
+## Why T-Shaped in Agile Squads
+
+在敏捷 Squad（特性团队）中，T 型技能弥合了业务与技术之间的鸿沟：
+
+| 技能类型 | 在敏捷中的价值 |
+|---------|--------------|
+| 业务分析技能 | 理解业务需求，转化为技术方案 |
+| 技术技能 | 实现技术解决方案 |
+| 沟通协作技能 | 跨职能团队的顺畅协作 |
+
+### 具体场景
+- **业务分析师 + T型技能**：不仅懂需求分析，还能理解技术约束和测试策略
+- **开发者 + T型技能**：不仅能写代码，还能理解业务背景和用户体验
+- **测试工程师 + T型技能**：不仅能测试，还能理解需求意图和代码结构
+
+## Relationship to Other Concepts
+
+- [[Business-Analysis]]：业务分析师的理想技能模型是 T 型技能
+- [[AgilePractices]]：敏捷 Squad 依赖 T 型技能人才实现跨职能协作
+- [[Requirements-Gathering]]：T 型技能帮助更好地收集和理解需求
+
+## Key Quote
+
+> "T-shaped skills are valuable in agile squads, combining core expertise with a broad understanding of related skills. Business analysis skills bridge the gap between business problems and technical solutions."
+
+## Aliases
+- T 型技能
+- T型人才培养
+- 跨职能技能

wiki/concepts/Technical-Architecture-Domains.md

@@ -0,0 +1,36 @@
+---
+title: "Technical Architecture Domains"
+type: concept
+tags: [Technical-Architecture, Cloud-Governance, AWS, Multi-Domain]
+sources: ["ctp-topic-23-introduction-to-the-technical-architecture-team-and-function"]
+last_updated: 2026-05-11
+---
+
+## Definition
+Technical Architecture Domains（技术架构领域）是技术架构团队将公司技术栈划分的特定管理单元，每个领域由首席架构师（Principal Architect）负责其完整的生命周期管理和路线图规划。
+
+## Domain Structure
+每个技术领域具有：
+- **明确的边界**：特定的技术栈或服务范围
+- **专属负责人**：首席架构师对该领域负全责
+- **独立路线图**：12-24 个月的领域专属前瞻规划
+- **治理标准**：该领域的架构原则和实施标准
+
+## Examples from OpenText Context
+基于 CTP Topic 23 文档，涉及的技术领域包括但不限于：
+- **身份认证（Identity）**：Active Directory、IAM 策略、SSO 方案
+- **网络（Networking）**：VPC 设计、网络隔离、安全访问
+- **Microsoft 堆栈**：Windows 工作负载、Exchange、SharePoint
+- **AWS Landing Zone**：多账号架构、安全与合规框架
+
+## Key Principles
+1. **单一责任**：每个领域由专人负责，避免职责真空
+2. **前瞻规划**：首席架构师负责制定并维护领域路线图
+3. **标准化**：领域内统一架构标准，减少技术碎片化
+4. **治理闭环**：设计 → 实施 → 监控 → 持续改进
+
+## Connections
+- [[EA-SA-TA-Framework]] — 技术领域是 TA 层的具体落地机制
+- [[Architecture-Roadmap]] — 每条路线图对应一个或多个技术领域
+- [[AWS-Enterprise-Landing-Zone]] — Landing Zone 是网络和安全领域的基础架构
+- [[Martin-Nash]] — 技术领域划分的主要推动者

wiki/concepts/Urban-Sprawl.md

@@ -0,0 +1,39 @@
+---
+title: "Urban Sprawl"
+type: concept
+tags: [Cloud, Infrastructure, Cost, Anti-Pattern]
+sources: ["ctp-topic-53-why-bother-with-cloud"]
+last_updated: 2026-05-10
+---
+
+## Definition
+
+Urban Sprawl（城市蔓延）是一个借喻概念，原指城市无计划扩张导致基础设施管理困难。在此语境下，用于描述企业数据中心规模的失控扩张——服务器、网络设备、存储资源的无序增长形成"技术债务"，带来高运维成本、低资源利用率和治理复杂性。
+
+## Application in Cloud Transformation Context
+
+在 [[ctp-topic-53-why-bother-with-cloud]] 中，Urban Sprawl 被量化为：
+- **规模**：14 个数据中心、近 20,000 项资产
+- **利用率**：硬件利用率不足 40%
+- **冗余**：Houston 有 89 个空机架和 360 台未使用服务器
+- **营收对比**：年营收 $25 亿的 Micro Focus，VMware 足迹比规模大 8 倍的公司还大
+
+## Why It's a Problem
+
+- **成本膨胀**：每个数据中心都需要电力、冷却、空间、机架和维护人员
+- **效率低下**：低利用率意味着大量资源被闲置浪费
+- **管理复杂性**：跨多个地点管理异构基础设施的协调成本
+- **敏捷性受限**：本地基础设施难以快速响应业务需求变化
+
+## Solution: Cloud Migration
+
+云迁移是对抗 Urban Sprawl 的核心策略。[[ctp-topic-53-why-bother-with-cloud]] 提供的数据证明：
+- 3 个产品从 Bublikan 迁出后，decommission 了 575 台物理服务器，云端仅需 240 台虚拟服务器
+- Redding 数据中心退出时，40% 的应用直接关机（说明这些应用可能从未被使用）
+
+## Related Concepts
+- [[Cloud-First-Policy]]：对抗 Urban Sprawl 的策略之一
+- [[Landing-Zone-Architecture]]：在云端建立有序的基础设施架构
+
+## Related Sources
+- [[ctp-topic-53-why-bother-with-cloud]] — 首次将 Urban Sprawl 概念引入 CTP 语境

wiki/concepts/Virtual-Desktop-Infrastructure.md

@@ -0,0 +1,49 @@
+---
+title: "Virtual Desktop Infrastructure"
+type: concept
+tags:
+  - VDI
+  - Virtual-Desktop
+  - End-User-Computing
+  - Cloud-DevOps
+sources:
+  - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee
+last_updated: 2026-05-11
+---
+
+## Virtual Desktop Infrastructure（虚拟桌面基础设施）
+
+虚拟桌面基础设施（Virtual Desktop Infrastructure，VDI）是通过虚拟化技术在云端交付桌面环境的解决方案。用户通过客户端设备连接到托管在数据中心的虚拟桌面，实现集中化管理、安全控制和随时随地访问。
+
+## VDI in AWS Context
+
+AWS 通过以下服务提供 VDI 能力：
+
+| AWS 服务 | VDI 模式 | 说明 |
+|----------|----------|------|
+| [[Amazon-Workspaces]] | 全托管 VDI | AWS 完全管理，适合知识工作者 |
+| [[Workspace-Core]] | API 访问 VDI | 提供 Workspaces VDI 基础设施 API，允许第三方 VDI 接入 |
+| [[AppStream-2]] | 应用流（非传统 VDI） | 流式应用而非完整桌面 |
+
+## Key Concepts
+
+### 持久性模型
+- **Persistent VDI**：用户状态、应用设置在会话之间保留
+- **Non-persistent VDI**：每次登录获得全新环境，适合共享池/临时场景
+
+### 协议
+- **WSP**（Workspaces Streaming Protocol）：AWS 专用，专为高延迟网络优化
+- 其他通用 VDI 协议：PCoIP、Blast（VMware）、RDP
+
+### 安全考量
+- 数据不存储在端点设备（保护 IP 和敏感数据）
+- 集中策略执行（MFA、设备认证、SAML）
+- VPC 隔离
+
+## Related Concepts
+- [[AWS-End-User-Computing]] — AWS VDI 服务组合
+- [[Amazon-Workspaces]] — AWS 全托管 VDI
+- [[Disaster-Recovery]] — VDI DR 策略（跨区域部署）
+
+## Sources
+- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]

wiki/concepts/WSP-Protocol.md

@@ -0,0 +1,32 @@
+---
+title: "WSP Protocol"
+type: concept
+tags:
+  - AWS
+  - WSP
+  - Streaming-Protocol
+  - Workspaces
+sources:
+  - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee
+last_updated: 2026-05-11
+---
+
+## WSP Protocol（Workspaces Streaming Protocol）
+
+WSP（Workspaces Streaming Protocol）是 Amazon Workspaces 专用的流传输协议，专为**高延迟网络**环境设计，确保远程用户在低质量网络条件下仍能获得可用的虚拟桌面体验。
+
+## Key Characteristics
+- **Purpose-built for latency**: Designed for high-latency (high ping) networks
+- **Used by**: [[Amazon-Workspaces]] exclusively
+- **Alternative to**: PCoIP, Blast (VMware), RDP for remote desktop
+
+## Why It Matters
+
+传统 VDI 协议在低延迟局域网表现良好，但在跨区域/远程办公场景下性能急剧下降。WSP 针对这一问题进行了专门优化，使 [[Amazon-Workspaces]] 能在全球范围内提供一致的桌面体验。
+
+## Connection to DR
+
+WSP 的高延迟容忍度是 [[AWS-End-User-Computing]] 跨区域灾难恢复策略的基础 —— 可以在另一个 AWS 区域部署 Workspaces，利用 WSP 协议保证用户体验。
+
+## Sources
+- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]