From eedfafcae292f1e1c4e27e9cbde3a70381176598 Mon Sep 17 00:00:00 2001 From: weishen Date: Wed, 29 Apr 2026 04:03:31 +0800 Subject: [PATCH] Auto-sync: 2026-04-29 04:03 --- wiki/concepts/AWS-End-User-Computing.md | 76 ++++++++++++++ wiki/concepts/AWS-Identity-Center.md | 38 +++++++ wiki/concepts/Architecture-Roadmap.md | 30 ++++++ wiki/concepts/Artifact-Repo.md | 61 ++++++++++++ wiki/concepts/BOSCARD.md | 48 +++++++++ wiki/concepts/BYOD.md | 41 ++++++++ wiki/concepts/Business-Analysis.md | 61 ++++++++++++ wiki/concepts/Cloud-First-Policy.md | 53 ++++++++++ wiki/concepts/Code-Signing.md | 62 ++++++++++++ wiki/concepts/EA-SA-TA-Framework.md | 38 +++++++ wiki/concepts/GitLab-Geo.md | 55 +++++++++++ wiki/concepts/GitLab-Proxy.md | 48 +++++++++ wiki/concepts/IGA.md | 57 +++++++++++ wiki/concepts/INVEST.md | 44 +++++++++ wiki/concepts/OpenText-Tagging-Standard.md | 99 +++++++++++++++++++ wiki/concepts/Product-Hierarchy.md | 52 ++++++++++ wiki/concepts/Project-Thor.md | 64 ++++++++++++ wiki/concepts/RACI.md | 54 ++++++++++ wiki/concepts/Repo-Mirroring.md | 49 +++++++++ wiki/concepts/Requirements-Gathering.md | 60 +++++++++++ wiki/concepts/SAFe.md | 43 ++++++++ wiki/concepts/SAML-Authentication.md | 41 ++++++++ wiki/concepts/Self-Serve-Product-Request.md | 75 ++++++++++++++ wiki/concepts/Service-Control-Policy.md | 87 ++++++++++++++++ wiki/concepts/Shift-and-Lift.md | 63 ++++++++++++ wiki/concepts/Stakeholder-Wheel.md | 68 +++++++++++++ wiki/concepts/Supply-Chain-Security.md | 67 +++++++++++++ wiki/concepts/T-Shaped-Skills.md | 66 +++++++++++++ .../Technical-Architecture-Domains.md | 36 +++++++ wiki/concepts/Urban-Sprawl.md | 39 ++++++++ .../Virtual-Desktop-Infrastructure.md | 49 +++++++++ wiki/concepts/WSP-Protocol.md | 32 ++++++ wiki/entities/Amazon-Workspaces.md | 57 +++++++++++ wiki/entities/AppStream-2.md | 56 +++++++++++ wiki/entities/Arnold-Dacan.md | 41 ++++++++ wiki/entities/Artifactory.md | 50 ++++++++++ wiki/entities/BCS.md | 35 +++++++ wiki/entities/Backstage.md | 53 ++++++++++ wiki/entities/Build-Hub.md | 57 +++++++++++ wiki/entities/Christian-Odonough.md | 26 +++++ wiki/entities/GitHub-Enterprise.md | 51 ++++++++++ wiki/entities/GitLab.md | 56 +++++++++++ wiki/entities/IIBA.md | 47 +++++++++ wiki/entities/PHT-Product-Hub-Platform.md | 61 ++++++++++++ wiki/entities/UCMDB.md | 47 +++++++++ wiki/entities/Workspace-Core.md | 30 ++++++ wiki/entities/Workspace-Web.md | 30 ++++++ 47 files changed, 2453 insertions(+) create mode 100644 wiki/concepts/AWS-End-User-Computing.md create mode 100644 wiki/concepts/AWS-Identity-Center.md create mode 100644 wiki/concepts/Architecture-Roadmap.md create mode 100644 wiki/concepts/Artifact-Repo.md create mode 100644 wiki/concepts/BOSCARD.md create mode 100644 wiki/concepts/BYOD.md create mode 100644 wiki/concepts/Business-Analysis.md create mode 100644 wiki/concepts/Cloud-First-Policy.md create mode 100644 wiki/concepts/Code-Signing.md create mode 100644 wiki/concepts/EA-SA-TA-Framework.md create mode 100644 wiki/concepts/GitLab-Geo.md create mode 100644 wiki/concepts/GitLab-Proxy.md create mode 100644 wiki/concepts/IGA.md create mode 100644 wiki/concepts/INVEST.md create mode 100644 wiki/concepts/OpenText-Tagging-Standard.md create mode 100644 wiki/concepts/Product-Hierarchy.md create mode 100644 wiki/concepts/Project-Thor.md create mode 100644 wiki/concepts/RACI.md create mode 100644 wiki/concepts/Repo-Mirroring.md create mode 100644 wiki/concepts/Requirements-Gathering.md create mode 100644 wiki/concepts/SAFe.md create mode 100644 wiki/concepts/SAML-Authentication.md create mode 100644 wiki/concepts/Self-Serve-Product-Request.md create mode 100644 wiki/concepts/Service-Control-Policy.md create mode 100644 wiki/concepts/Shift-and-Lift.md create mode 100644 wiki/concepts/Stakeholder-Wheel.md create mode 100644 wiki/concepts/Supply-Chain-Security.md create mode 100644 wiki/concepts/T-Shaped-Skills.md create mode 100644 wiki/concepts/Technical-Architecture-Domains.md create mode 100644 wiki/concepts/Urban-Sprawl.md create mode 100644 wiki/concepts/Virtual-Desktop-Infrastructure.md create mode 100644 wiki/concepts/WSP-Protocol.md create mode 100644 wiki/entities/Amazon-Workspaces.md create mode 100644 wiki/entities/AppStream-2.md create mode 100644 wiki/entities/Arnold-Dacan.md create mode 100644 wiki/entities/Artifactory.md create mode 100644 wiki/entities/BCS.md create mode 100644 wiki/entities/Backstage.md create mode 100644 wiki/entities/Build-Hub.md create mode 100644 wiki/entities/Christian-Odonough.md create mode 100644 wiki/entities/GitHub-Enterprise.md create mode 100644 wiki/entities/GitLab.md create mode 100644 wiki/entities/IIBA.md create mode 100644 wiki/entities/PHT-Product-Hub-Platform.md create mode 100644 wiki/entities/UCMDB.md create mode 100644 wiki/entities/Workspace-Core.md create mode 100644 wiki/entities/Workspace-Web.md diff --git a/wiki/concepts/AWS-End-User-Computing.md b/wiki/concepts/AWS-End-User-Computing.md new file mode 100644 index 00000000..c1cb1dbe --- /dev/null +++ b/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]] diff --git a/wiki/concepts/AWS-Identity-Center.md b/wiki/concepts/AWS-Identity-Center.md new file mode 100644 index 00000000..7ecb5bd9 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Architecture-Roadmap.md b/wiki/concepts/Architecture-Roadmap.md new file mode 100644 index 00000000..036f0442 --- /dev/null +++ b/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]] — 路线图服务于云转型整体战略 diff --git a/wiki/concepts/Artifact-Repo.md b/wiki/concepts/Artifact-Repo.md new file mode 100644 index 00000000..5766de5a --- /dev/null +++ b/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]] diff --git a/wiki/concepts/BOSCARD.md b/wiki/concepts/BOSCARD.md new file mode 100644 index 00000000..148b622f --- /dev/null +++ b/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 +- 复杂工作定义框架 diff --git a/wiki/concepts/BYOD.md b/wiki/concepts/BYOD.md new file mode 100644 index 00000000..96cbbef8 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Business-Analysis.md b/wiki/concepts/Business-Analysis.md new file mode 100644 index 00000000..3a9716b6 --- /dev/null +++ b/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 +- 业务分析 diff --git a/wiki/concepts/Cloud-First-Policy.md b/wiki/concepts/Cloud-First-Policy.md new file mode 100644 index 00000000..5b49abcb --- /dev/null +++ b/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 核心战略 diff --git a/wiki/concepts/Code-Signing.md b/wiki/concepts/Code-Signing.md new file mode 100644 index 00000000..dc9dfc8d --- /dev/null +++ b/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]] diff --git a/wiki/concepts/EA-SA-TA-Framework.md b/wiki/concepts/EA-SA-TA-Framework.md new file mode 100644 index 00000000..d58d3f7b --- /dev/null +++ b/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]] — 三层架构体系的组织背景 diff --git a/wiki/concepts/GitLab-Geo.md b/wiki/concepts/GitLab-Geo.md new file mode 100644 index 00000000..376b0201 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/GitLab-Proxy.md b/wiki/concepts/GitLab-Proxy.md new file mode 100644 index 00000000..ad1a6151 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/IGA.md b/wiki/concepts/IGA.md new file mode 100644 index 00000000..97951612 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/INVEST.md b/wiki/concepts/INVEST.md new file mode 100644 index 00000000..d4ae5ebb --- /dev/null +++ b/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 diff --git a/wiki/concepts/OpenText-Tagging-Standard.md b/wiki/concepts/OpenText-Tagging-Standard.md new file mode 100644 index 00000000..873fa45b --- /dev/null +++ b/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） diff --git a/wiki/concepts/Product-Hierarchy.md b/wiki/concepts/Product-Hierarchy.md new file mode 100644 index 00000000..6b89fbde --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Project-Thor.md b/wiki/concepts/Project-Thor.md new file mode 100644 index 00000000..ba67a1b6 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/RACI.md b/wiki/concepts/RACI.md new file mode 100644 index 00000000..cc030f39 --- /dev/null +++ b/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 diff --git a/wiki/concepts/Repo-Mirroring.md b/wiki/concepts/Repo-Mirroring.md new file mode 100644 index 00000000..b8cf19ee --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Requirements-Gathering.md b/wiki/concepts/Requirements-Gathering.md new file mode 100644 index 00000000..efc49116 --- /dev/null +++ b/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 diff --git a/wiki/concepts/SAFe.md b/wiki/concepts/SAFe.md new file mode 100644 index 00000000..7f40fdba --- /dev/null +++ b/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 diff --git a/wiki/concepts/SAML-Authentication.md b/wiki/concepts/SAML-Authentication.md new file mode 100644 index 00000000..92498519 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Self-Serve-Product-Request.md b/wiki/concepts/Self-Serve-Product-Request.md new file mode 100644 index 00000000..2ab1ff3e --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Service-Control-Policy.md b/wiki/concepts/Service-Control-Policy.md new file mode 100644 index 00000000..52540134 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Shift-and-Lift.md b/wiki/concepts/Shift-and-Lift.md new file mode 100644 index 00000000..127f36c1 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/Stakeholder-Wheel.md b/wiki/concepts/Stakeholder-Wheel.md new file mode 100644 index 00000000..579a1013 --- /dev/null +++ b/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 +- 干系人识别工具 diff --git a/wiki/concepts/Supply-Chain-Security.md b/wiki/concepts/Supply-Chain-Security.md new file mode 100644 index 00000000..2915dfde --- /dev/null +++ b/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]] diff --git a/wiki/concepts/T-Shaped-Skills.md b/wiki/concepts/T-Shaped-Skills.md new file mode 100644 index 00000000..3ef7eb09 --- /dev/null +++ b/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型人才培养 +- 跨职能技能 diff --git a/wiki/concepts/Technical-Architecture-Domains.md b/wiki/concepts/Technical-Architecture-Domains.md new file mode 100644 index 00000000..a63770ea --- /dev/null +++ b/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]] — 技术领域划分的主要推动者 diff --git a/wiki/concepts/Urban-Sprawl.md b/wiki/concepts/Urban-Sprawl.md new file mode 100644 index 00000000..406979ee --- /dev/null +++ b/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 语境 diff --git a/wiki/concepts/Virtual-Desktop-Infrastructure.md b/wiki/concepts/Virtual-Desktop-Infrastructure.md new file mode 100644 index 00000000..deccd643 --- /dev/null +++ b/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]] diff --git a/wiki/concepts/WSP-Protocol.md b/wiki/concepts/WSP-Protocol.md new file mode 100644 index 00000000..d5eea5af --- /dev/null +++ b/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]] diff --git a/wiki/entities/Amazon-Workspaces.md b/wiki/entities/Amazon-Workspaces.md new file mode 100644 index 00000000..01addf70 --- /dev/null +++ b/wiki/entities/Amazon-Workspaces.md @@ -0,0 +1,57 @@ +--- +title: "Amazon Workspaces" +type: entity +tags: + - AWS + - End-User-Computing + - Virtual-Desktop + - VDI +sources: + - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee + - ctp-topic-6-aws-workspaces-demo +last_updated: 2026-05-11 +--- + +## Amazon Workspaces + +Amazon Workspaces is an AWS-managed **fully persistent virtual desktop** service that provides cloud-based Windows or Ubuntu desktops. It is part of the [[AWS-End-User-Computing]] portfolio and is designed for knowledge workers who need a complete desktop environment. + +## Key Characteristics + +| Feature | Description | +|---------|-------------| +| **Persistence** | Fully persistent — application states and user settings persist between sessions | +| **Instance model** | One-to-one instance management | +| **OS support** | Ubuntu and Windows | +| **Protocol** | WSP (Workspaces Streaming Protocol) — designed for high-latency networks | +| **Deployment** | Deployed from bundles; users can install applications with appropriate permissions | +| **Network** | Each workspace has two network interfaces (service VPC managed by AWS + customer VPC) | +| **Cost control** | Auto-stop feature to reduce idle costs | + +## Use Cases +- Knowledge workers needing full desktop environment +- Hybrid workforces +- BYOD (Bring Your Own Device) users +- Developers +- Compute-intensive workloads + +## Security Features +- Active Directory integration +- Encryption +- IAM profiles +- Multi-factor authentication (MFA) +- Device certificates +- VPC Interface Endpoints for private connectivity + +## Disaster Recovery +- Build out workspaces in another AWS region for cross-region DR +- Refer to [[Disaster-Recovery]] and [[RTO]]/[[RPO]] metrics + +## Connections +- [[AWS-End-User-Computing]] ← is_a ← [[Amazon-Workspaces]] +- [[ctp-topic-6-aws-workspaces-demo]] ← extends ← [[Amazon-Workspaces]] +- [[AppStream-2]] ← compared_to ← [[Amazon-Workspaces]] (persistent vs. selective persistence) + +## Sources +- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]] +- [[ctp-topic-6-aws-workspaces-demo]] diff --git a/wiki/entities/AppStream-2.md b/wiki/entities/AppStream-2.md new file mode 100644 index 00000000..336c904e --- /dev/null +++ b/wiki/entities/AppStream-2.md @@ -0,0 +1,56 @@ +--- +title: "Amazon AppStream 2.0" +type: entity +tags: + - AWS + - End-User-Computing + - Application-Streaming + - Virtual-Desktop +sources: + - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee +last_updated: 2026-05-11 +--- + +## Amazon AppStream 2.0 + +Amazon AppStream 2.0 is an AWS-managed **application and desktop streaming service** that provides selective persistence. It is part of the [[AWS-End-User-Computing]] portfolio and is designed for non-persistent desktop scenarios, labs, training environments, and bastion hosts. + +## Key Characteristics + +| Feature | Description | +|---------|-------------| +| **Persistence** | Selective persistence — fresh desktop at each logon, with optional application and storage connectors | +| **Deployment** | Instances created from base images — simplifies application management | +| **OS support** | Windows; exploring other Linux flavors | +| **Multi-tenancy** | Newer multi-tenant approach allows multiple users per instance (cost optimization) | +| **Concurrency** | Concurrency of use model for cost efficiency | +| **Auto-scaling** | Built-in auto-scaling capabilities for DR and load handling | +| **File transfer** | Supports file uploads/downloads | +| **Clients** | Web browser client, Windows native client for native application support | + +## Positioning +> *"AppStream 2.0 is a great low cost alternative for customers that don't require a fully persistent desktop."* — [[Christian-ODonough]] + +## Use Cases +- Non-persistent desktops +- Labs and training environments +- Bastion hosts / jump servers +- Secure access to corporate resources +- Online trials +- ISV application streaming with branding options + +## Security Features +- Secure streaming protocols +- Built-in data protection policies +- Device certificates +- Multi-factor authentication +- VPC Interface Endpoints for private connectivity +- SAML-based authentication + +## Connections +- [[AWS-End-User-Computing]] ← is_a ← [[AppStream-2]] +- [[Amazon-Workspaces]] ← compared_to ← [[AppStream-2]] (full persistence vs. selective persistence) +- [[Christian-ODonough]] ← presents ← [[AppStream-2]] + +## Sources +- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]] diff --git a/wiki/entities/Arnold-Dacan.md b/wiki/entities/Arnold-Dacan.md new file mode 100644 index 00000000..684ba91c --- /dev/null +++ b/wiki/entities/Arnold-Dacan.md @@ -0,0 +1,41 @@ +--- +title: "Arnold Dacan" +type: entity +tags: [Arnold-Dacan, OpenText, Project-Thor, Platform-Engineering, Cloud-Transformation] +sources: + - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet +last_updated: 2026-05-11 +--- + +## Arnold Dacan + +Arnold Dacan 是 OpenText 的技术负责人，主导 Project Thor 平台与数据流的分享与设计工作。 + +## Aliases +- Arnold Dacan + +## Role + +| 维度 | 说明 | +|------|------| +| 公司 | OpenText | +| 职能 | 技术负责人 / 平台架构师 | +| 关注领域 | Project Thor、供应链安全、工具链标准化 | +| 主讲内容 | Thor Platform & Flows（2024-12-10 Learning Sessions） | + +## Key Contributions + +- 提出"源代码是供应链的核心要素"（Source Code as Core IP） +- 阐述 Project Thor 五大支柱框架 +- 设计源代码供应链数据流架构（GitLab → Build Farms → Artifactory → 客户环境） +- 推动 GitLab/Artifactory/UCMDB 工具链标准化 + +## Connections + +- [[Arnold-Dacan]] → presents → [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] +- [[Arnold-Dacan]] → drives → [[Project-Thor]] +- [[Arnold-Dacan]] → works_for → [[OpenText]] + +## Sources + +- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/entities/Artifactory.md b/wiki/entities/Artifactory.md new file mode 100644 index 00000000..9e226015 --- /dev/null +++ b/wiki/entities/Artifactory.md @@ -0,0 +1,50 @@ +--- +title: "Artifactory" +type: entity +tags: [Artifactory, JFrog, Binary-Repository, DevOps, Artifact-Management, Project-Thor] +sources: + - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet +last_updated: 2026-05-11 +--- + +## Artifactory + +Artifactory（JFrog Artifactory）是 OpenText 选定的二进制制品仓库（Binary Repository Manager），是 Project Thor 工具链的核心组件之一。 + +## Aliases +- Artifactory +- JFrog Artifactory + +## Key Facts + +| 维度 | 说明 | +|------|------| +| 厂商 | JFrog | +| 类型 | 二进制制品仓库（Binary Repository Manager） | +| OpenText 定位 | Project Thor 工具链核心组件 | +| 标准化角色 | 构建产物存储黄金标准 | +| 定位层级 | 供应链数据流第三层（GitLab → Build Farms → Artifactory → 客户环境） | + +## 供应链中的角色 + +``` +源代码（GitLab） + ↓ Build Farms（制造流程） +Artifactory（制品仓库） + ↓ +客户环境 +``` + +Artifactory 存储所有构建产物（binaries/artifacts），是交付流程的关键节点。 + +## Connections + +- [[Artifactory]] ← stores ← [[Build-Hub]] 构建产物 +- [[Artifactory]] ← feeds ← Build Farms（制造流程） +- [[Artifactory]] → delivers → 客户环境 +- [[Project-Thor]] ← integrates ← [[Artifactory]]（五大支柱之一） +- [[GitLab]] → triggers → Build Farms → [[Artifactory]] + +## Sources + +- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/entities/BCS.md b/wiki/entities/BCS.md new file mode 100644 index 00000000..04c467ff --- /dev/null +++ b/wiki/entities/BCS.md @@ -0,0 +1,35 @@ +--- +title: "BCS" +type: entity +tags: [Professional-Body, Business-Analysis, Certification] +sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109] +last_updated: 2026-05-11 +--- + +## Definition + +BCS（British Computer Society，英国计算机学会）是英国领先的专业技术机构，致力于推动信息技术的最佳实践和标准，在业务分析和项目管理领域提供权威的培训课程和认证。 + +## Overview + +- **全称**：BCS, The Chartered Institute for IT +- **总部**：英国 +- **定位**：专业认证机构、知识传播组织 +- **与业务分析的关系**：BCS 提供业务分析（Business Analysis）的专业课程和认证体系 + +## Business Analysis Offerings + +BCS 在业务分析领域的主要贡献： +- **BCS Business Analysis 认证体系**：涵盖从基础到专家级别的 BA 培训 +- **方法论推广**：包括 BABOK（Business Analysis Body of Knowledge）等知识体系 +- **专业标准**：制定和维护业务分析领域的行业标准 + +## Relationship to Other Entities + +- [[IIBA]]：另一个主要的业务分析专业机构，提供 CBAP 等认证，与 BCS 互补 +- [[OpenText]]：OpenText 的 Public Cloud Learning Sessions 引用 BCS 作为业务分析学习资源来源之一 + +## Aliases +- British Computer Society +- BCS The Chartered Institute for IT +- 英国计算机学会 diff --git a/wiki/entities/Backstage.md b/wiki/entities/Backstage.md new file mode 100644 index 00000000..cd10f3b9 --- /dev/null +++ b/wiki/entities/Backstage.md @@ -0,0 +1,53 @@ +--- +title: "Backstage" +type: entity +tags: [Backstage, Developer-Portal, Platform-Engineering, OpenText, Project-Thor, CNCF] +sources: + - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet +last_updated: 2026-05-11 +--- + +## Backstage + +Backstage（backstage.io）是 CNCF 孵化项目，作为开发者门户（Developer Portal）集成到 Project Thor 的五大支柱框架中，为 OpenText 工程师提供统一的自服务平台。 + +## Aliases +- Backstage +- Backstage.io +- 开发者门户 + +## Key Facts + +| 维度 | 说明 | +|------|------| +| 厂商 | CNCF（云原生计算基金会） | +| 类型 | 开发者门户 / Internal Developer Platform（IDP） | +| 项目状态 | CNCF 孵化项目（Incubating） | +| OpenText 定位 | Project Thor 五大支柱之一 | +| 核心功能 | 开发者自助服务、工具发现、文档聚合、CI/CD 流水线可视化 | + +## Project Thor 中的角色 + +Backstage 作为 Project Thor 五大支柱之一，提供开发者门户能力： + +> "Developer Portal (Backstage) is one of the five pillars of Project Thor." — Arnold Dacan + +### 五大支柱中的 Backstage + +| 支柱 | 说明 | +|------|------| +| 敏捷周期治理 | 标准化开发流程 | +| 产品发布治理 | 统一发布审批 | +| **开发者门户 Backstage** | 开发者自助服务平台 | +| 安全与治理 | 安全扫描、合规审计 | +| Build Hub | 中心平台工程 | + +## Connections + +- [[Backstage]] ← implements ← [[Project-Thor]]（五大支柱之一） +- [[Backstage]] → serves → OpenText 工程师（开发者自助服务） +- [[Build-Hub]] → manages ← [[Backstage]]（平台工程团队运营） + +## Sources + +- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/entities/Build-Hub.md b/wiki/entities/Build-Hub.md new file mode 100644 index 00000000..d6609f40 --- /dev/null +++ b/wiki/entities/Build-Hub.md @@ -0,0 +1,57 @@ +--- +title: "Build Hub" +type: entity +tags: [Build-Hub, DevOps, Platform-Engineering, CI/CD, OpenText] +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 +--- + +## Build Hub + +Build Hub 是 OpenText/Micro Focus 云转型计划中的**中心平台工程团队**，负责管理核心 DevOps 工具并为产品团队的软件交付流水线提供技术支持。 + +## Aliases +- Build Hub + +## Key Facts + +| 维度 | 说明 | +|------|------| +| 职能 | 中心平台工程（Platform Engineering） | +| 核心职责 | 管理 GitLab 等中心工具、支持 CI/CD 流水线 | +| 定位 | 自服务支持模式（Teams self-serve, Build Hub assists） | +| 隶属 | [[Project-Thor]] 五大支柱之一 | + +## Responsibilities + +### 工具管理 +- 管理 GitLab（源代码控制的黄金标准平台） +- 维护中心构建工具链 + +### 迁移支持 +在 GitHub Enterprise → GitLab 迁移项目中： +- 为各团队提供辅助支持（assistance when needed） +- 不替代各团队自行规划迁移的责任 +- 确保迁移流水线符合企业标准 + +详见 [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] + +## Project Thor 中的角色 + +Build Hub 是 [[Project-Thor]] 五大支柱之一： + +> "Project Thor aims to integrate Micro-Focus and OpenText tooling, with GitLab as the centralized system for source control." — Build Hub 团队负责实现该目标的核心交付物 + +## Connections + +- [[Build-Hub]] → supports → 各产品团队（GitHub→GitLab 迁移） +- [[GitLab]] ← manages ← [[Build-Hub]] +- [[Project-Thor]] ← part_of ← [[Build-Hub]]（五大支柱之一） +- [[PHT-Product-Hub-Platform]] ← collaborates ← [[Build-Hub]]（迁移进度跟踪协作） + +## Sources + +- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] +- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/entities/Christian-Odonough.md b/wiki/entities/Christian-Odonough.md new file mode 100644 index 00000000..f8a8a17d --- /dev/null +++ b/wiki/entities/Christian-Odonough.md @@ -0,0 +1,26 @@ +--- +title: "Christian O'Donough" +type: entity +tags: + - AWS + - End-User-Computing + - Speaker +sources: + - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee +last_updated: 2026-05-11 +--- + +## Christian O'Donough + +Christian O'Donough is an AWS presenter and solutions architect who delivered the Public Cloud Learning Sessions workshop on AWS End User Computing (EUC) services. His session covered virtual desktops, application streaming, and security considerations for Amazon Workspaces and AppStream 2.0. + +## Role +- **Primary**: AWS EUC Services Presenter — introduced AWS EUC portfolio, service selection criteria, and security best practices + +## Connections +- [[Amazon-Workspaces]] ← presents ← [[Christian-ODonough]] +- [[AppStream-2]] ← presents ← [[Christian-ODonough]] +- [[AWS-End-User-Computing]] ← presents ← [[Christian-ODonough]] + +## Sources +- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]] diff --git a/wiki/entities/GitHub-Enterprise.md b/wiki/entities/GitHub-Enterprise.md new file mode 100644 index 00000000..4f3b8e1b --- /dev/null +++ b/wiki/entities/GitHub-Enterprise.md @@ -0,0 +1,51 @@ +--- +title: "GitHub Enterprise" +type: entity +tags: [GitHub, Source-Control, Version-Control, Enterprise, DevOps] +sources: + - public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20 +last_updated: 2026-05-09 +--- + +## GitHub Enterprise + +GitHub Enterprise 是 GitHub 的企业版（私有部署）版本，提供比公共 GitHub.com 更强的访问控制、合规和安全管理能力。 + +## Key Facts + +| 维度 | 说明 | +|------|------| +| 部署模式 | 私有化部署（On-premises） | +| 许可证 | 企业级订阅 | +| 核心功能 | 私有仓库、代码审查、CI/CD 集成、Enterprise SSO、审计日志 | +| 用户规模 | OpenText 原有 GitHub Enterprise 许可证覆盖其全球团队 | + +## OpenText 迁移背景 + +OpenText 的 GitHub Enterprise 许可证于每年 12 月底到期，公司决定**不再续约**，全面转向 GitLab 作为源代码控制的黄金标准（Golden Standard）。 + +迁移原因： +- **成本考量**：GitLab 许可证已覆盖高达 8,500 名用户，统一平台降低管理复杂度 +- **工具链整合**：Project Thor 推动 Micro Focus 和 OpenText 工具链统一，GitLab 是核心组件 +- **自服务模式**：GitLab 提供更开放的权限管理和流水线自动化能力 + +## Migration to GitLab + +详见 [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] + +迁移策略： +- 各团队自行盘点 GitHub 资产、识别 CI/CD 流水线 +- Build Hub 团队提供辅助支持 +- 通过 [[PHT（Product Hub Platform）]] 跟踪迁移进度 +- 迁移完成标准：代码迁移 + 流水线转型 + PHT 更新 + +## Connections + +- [[GitLab]] ← migrated_to ← [[GitHub-Enterprise]]（OpenText 源代码管理平台迁移） +- [[OpenText]] ← used_by ← [[GitHub-Enterprise]]（被 OpenText 使用至许可证到期） +- [[Build Hub]] → supports → [[GitHub-Enterprise]] 迁移到 [[GitLab]] +- [[PHT（Product Hub Platform）]] ← tracks ← [[GitHub-Enterprise]] 迁移进度 + +## Sources + +- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] diff --git a/wiki/entities/GitLab.md b/wiki/entities/GitLab.md new file mode 100644 index 00000000..8607024d --- /dev/null +++ b/wiki/entities/GitLab.md @@ -0,0 +1,56 @@ +--- +title: "GitLab" +type: entity +tags: [GitLab, Source-Control, CI/CD, DevOps, Git, Platform] +sources: + - public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20 + - ctp-topic-2-git + - ctp-topic-9-ci-cd-with-gruntwork + - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet +last_updated: 2026-05-11 +--- + +## GitLab + +GitLab 是一个完整的 DevOps 平台，涵盖从源代码管理、CI/CD 流水线到监控、安全和运维的全生命周期工具链。 + +## Key Facts + +| 维度 | 说明 | +|------|------| +| 类型 | 单一平台（All-in-One DevOps Platform） | +| 许可证 | 开源（Community Edition）+ 商业版（Ultimate/Enterprise） | +| 核心功能 | Git 仓库管理、CI/CD pipelines、容器注册表、监控、安全扫描 | +| OpenText 授权 | 覆盖高达 8,500 名用户 | +| OpenText 定位 | 源代码管理的黄金标准（Golden Standard） | + +## GitHub Enterprise 到 GitLab 迁移 + +详见 [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] + +OpenText 将 GitLab 定为源代码管理的统一平台，驱动因素包括： +- GitHub Enterprise 许可证到期不续 +- Project Thor 工具链统一战略 +- GitLab 自服务权限管理优势 + +## 迁移方案 + +### Mirroring（镜像同步） +将 GitHub 仓库同步到 GitLab，源仓库保持不变。适用于需要保持 GitHub 访问权限的场景。 + +### Shift and Lift（搬移重构） +将代码直接复制到 GitLab，同时转换 CI/CD 流水线。适用于已完成流水线规划的团队。 + +## Connections + +- [[GitLab]] ← uses ← [[OpenText]]（OpenText 作为源代码管理标准平台） +- [[GitHub-Enterprise]] → migrated_to → [[GitLab]]（OpenText 迁移项目） +- [[Build Hub]] → manages ← [[GitLab]]（Build Hub 团队管理 GitLab 中心工具） +- [[PHT（Product Hub Platform）]] ← controls ← [[GitLab]] 仓库权限 +- [[Project Thor]] ← integrates ← [[GitLab]]（作为集中化源代码控制系统） + +## Sources + +- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] +- [[ctp-topic-2-git]] +- [[ctp-topic-9-ci-cd-with-gruntwork]] diff --git a/wiki/entities/IIBA.md b/wiki/entities/IIBA.md new file mode 100644 index 00000000..07b98117 --- /dev/null +++ b/wiki/entities/IIBA.md @@ -0,0 +1,47 @@ +--- +title: "IIBA" +type: entity +tags: [Professional-Body, Business-Analysis, Certification] +sources: [public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109] +last_updated: 2026-05-11 +--- + +## Definition + +IIBA（International Institute of Business Analysis，国际商业分析协会）是全球领先的业务分析专业机构，致力于定义和推广业务分析的最佳实践、标准和认证。 + +## Overview + +- **全称**：International Institute of Business Analysis +- **总部**：加拿大多伦多 +- **定位**：国际性业务分析专业认证机构 +- **与业务分析的关系**：IIBA 提供全球认可的 BA 认证体系，BABOK（A Guide to the Business Analysis Body of Knowledge）是其核心知识标准 + +## Key Certifications + +IIBA 提供多个层次的业务分析认证： +- **ECBA**（Entry Certificate in Business Analysis）—— 入门级 +- **CCBA**（Certification of Competency in Business Analysis）—— 中级 +- **CBAP**（Certified Business Analysis Professional）—— 专家级 +- **AAC**（Agile Analysis Certification）—— 敏捷分析专项 + +## BABOK + +BABOK（Business Analysis Body of Knowledge）是 IIBA 发布的业务分析知识体系指南，定义了业务分析的六个知识领域： +1. Business Analysis Planning and Monitoring +2. Elicitation and Collaboration +3. Requirements Life Cycle Management +4. Strategy Analysis +5. Requirements Analysis and Design Definition +6. Solution Evaluation + +## Relationship to Other Entities + +- [[BCS]]：英国计算机学会，另一个 BA 认证机构，与 IIBA 互补 +- [[OpenText]]：OpenText 的 Public Cloud Learning Sessions 引用 IIBA 作为业务分析学习资源来源之一 + +## Aliases +- International Institute of Business Analysis +- 国际商业分析协会 +- BABOK +- CBAP diff --git a/wiki/entities/PHT-Product-Hub-Platform.md b/wiki/entities/PHT-Product-Hub-Platform.md new file mode 100644 index 00000000..64d52b37 --- /dev/null +++ b/wiki/entities/PHT-Product-Hub-Platform.md @@ -0,0 +1,61 @@ +--- +title: "PHT（Product Hub Platform）" +type: entity +tags: [PHT, Product-Hub, Platform, OpenText, Thor, Migration] +sources: + - public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20 + - public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806 +last_updated: 2026-05-09 +--- + +## PHT（Product Hub Platform） + +PHT（Product Hub Platform）是 OpenText 的产品中心化平台，负责管理产品组合信息、映射内部系统（如 GitLab 仓库）并跟踪云转型进度。 + +## Key Facts + +| 维度 | 说明 | +|------|------| +| 全称 | Product Hub Platform | +| 简称 | PHT | +| 定位 | 产品信息管理 + 内部系统映射 + 迁移进度跟踪 | +| 隶属 | [[Project Thor]] 生态核心组件 | +| GitLab 权限 | 通过 PHT 控制 GitLab 仓库权限映射 | + +## 在 GitHub→GitLab 迁移中的作用 + +### 1. 仓库映射 +- 将 GitHub 仓库映射到 GitLab 仓库 +- 跟踪每个仓库的迁移状态 + +### 2. 权限管理 +- GitLab 仓库权限通过 PHT 控制 +- 支持自助访问管理（Self-service access management） + +### 3. 进度跟踪 +- 迁移进度通过 PHT 跟踪 +- 定期向开发经理和 Build Advocates 更新进度 + +### 4. 迁移完成标准 +> "Definition of done includes code migration, pipeline transformation, and updating PHT." +> — PHT 是迁移完成的必要条件之一 + +详见 [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] + +## 与 Build Hub 的协作 + +- [[Build-Hub]] 团队管理 GitLab 等中心工具 +- [[PHT（Product Hub Platform）]] 管理仓库映射和权限 +- 两者共同支撑 GitHub→GitLab 迁移的自服务模式 + +## Connections + +- [[PHT（Product Hub Platform）]] ← manages ← [[GitLab]] 仓库权限 +- [[PHT（Product Hub Platform）]] ← tracks ← GitHub→GitLab 迁移进度 +- [[Project Thor]] ← part_of ← [[PHT（Product Hub Platform）]] +- [[OpenText]] ← used_by ← [[PHT（Product Hub Platform）]] + +## Sources + +- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] +- [[public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806]] diff --git a/wiki/entities/UCMDB.md b/wiki/entities/UCMDB.md new file mode 100644 index 00000000..6f24bd8b --- /dev/null +++ b/wiki/entities/UCMDB.md @@ -0,0 +1,47 @@ +--- +title: "UCMDB" +type: entity +tags: [UCMDB, Micro-Focus, Configuration-Management, ITOM, OpenText, Project-Thor] +sources: + - public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet +last_updated: 2026-05-11 +--- + +## UCMDB + +UCMDB（Unified Configuration Management Database）是 Micro Focus / OpenText 的统一配置管理数据库，属于 Project Thor 工具链中的后端服务组件，用于供应链安全的配置管理与可追溯性。 + +## Aliases +- UCMDB +- Universal CMDB +- Unified Configuration Management Database + +## Key Facts + +| 维度 | 说明 | +|------|------| +| 厂商 | Micro Focus → OpenText（收购后） | +| 类型 | 配置管理数据库（CMDB） | +| 所属领域 | ITOM（IT 运维管理） | +| OpenText 定位 | Project Thor 工具链后端服务组件 | +| 标准化角色 | 与 GitLab、Artifactory 共同构成供应链安全基础设施 | + +## 在 Project Thor 中的角色 + +Arnold Dacan 阐述 UCMDB 的定位： + +> "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 + +UCMDB 作为后端服务组件，与 GitLab、Artifactory 一起被列为 Project Thor 标准化目标的关键组成部分，随供应链安全需求增长而持续扩展。 + +## Connections + +- [[UCMDB]] ← supports ← [[Project-Thor]]（后端服务组件） +- [[UCMDB]] ← manages ← OpenText ITOM 团队 +- [[GitLab]] ← complements ← [[UCMDB]]（源代码 + 配置管理） +- [[Artifactory]] ← complements ← [[UCMDB]]（制品 + 配置管理） +- [[Micro-Focus]] → originally_provides ← [[UCMDB]] + +## Sources + +- [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]] diff --git a/wiki/entities/Workspace-Core.md b/wiki/entities/Workspace-Core.md new file mode 100644 index 00000000..484ef86a --- /dev/null +++ b/wiki/entities/Workspace-Core.md @@ -0,0 +1,30 @@ +--- +title: "AWS Workspace Core" +type: entity +tags: + - AWS + - End-User-Computing + - VDI +sources: + - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee +last_updated: 2026-05-11 +--- + +## AWS Workspace Core + +AWS Workspace Core provides API access to the Amazon Workspaces VDI (Virtual Desktop Infrastructure) for integration with **third-party VDI solutions** such as VMware Horizon View or Citrix. + +## Key Characteristics +- **Access method**: API-based access to Workspaces VDI infrastructure +- **Purpose**: Allows organizations to use existing third-party VDI management tools while leveraging AWS backend +- **Supported platforms**: Third-party solutions (e.g., Horizon View, Citrix) can connect via API + +## Positioning +Workspace Core sits alongside [[Amazon-Workspaces]] (fully managed service) and [[AppStream-2]] (managed application streaming) as an option for organizations that need third-party VDI control plane integration. + +## Connections +- [[Amazon-Workspaces]] ← underlying ← [[Workspace-Core]] +- [[AWS-End-User-Computing]] ← is_a ← [[Workspace-Core]] + +## Sources +- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]] diff --git a/wiki/entities/Workspace-Web.md b/wiki/entities/Workspace-Web.md new file mode 100644 index 00000000..4c9dff30 --- /dev/null +++ b/wiki/entities/Workspace-Web.md @@ -0,0 +1,30 @@ +--- +title: "AWS Workspace Web" +type: entity +tags: + - AWS + - End-User-Computing + - Secure-Browser +sources: + - public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee +last_updated: 2026-05-11 +--- + +## AWS Workspace Web + +AWS Workspace Web is a **low-cost, secure web browser** service within the [[AWS-End-User-Computing]] portfolio. It is designed for secure access to internal websites and SaaS applications without the overhead of a full virtual desktop. + +## Key Characteristics +- **Use case**: Secure browsing for internal websites and SaaS applications +- **Cost**: Low-cost alternative to full virtual desktop services +- **Deployment**: Fully managed by AWS — no infrastructure to manage +- **Security**: Built-in security policies and data protection + +## Positioning +Workspace Web is the entry-level option in the AWS EUC portfolio — suitable for task workers who only need web access, contrasting with [[Amazon-Workspaces]] (full desktop) and [[AppStream-2]] (application streaming). + +## Connections +- [[AWS-End-User-Computing]] ← is_a ← [[Workspace-Web]] + +## Sources +- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]