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

wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md

@@ -0,0 +1,77 @@
+---
+title: "CTP Topic 11 AD Integration and Login using AD Accounts"
+type: source
+tags:
+  - AWS
+  - AD
+  - IAM
+  - SSO
+  - CTP
+  - Jenkins
+  - RBAC
+  - Pre-commit
+  - Terraform
+  - IaC
+  - DevSecOps
+sources: []
+last_updated: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+
+## Summary（用中文描述）
+- 核心主题：Jenkins 与企业 Active Directory (AD) 的集成，以及 Terraform 代码的自动化质量检查
+- 问题域：企业级 CI/CD 系统的身份认证管理与基础设施代码安全治理
+- 方法/机制：
+  - Jenkins Security Realm 与 SW Infra AD 集成，实现基于 AD 账号的统一身份认证与自动化用户管理
+  - 通过 AD 组策略实现 RBAC（基于角色的访问控制），精细化管理 Jenkins 权限（只读/读写/流水线创建）
+  - pre-commit 框架集成 terraform fmt、TFLint、Checkov 三款工具，在代码提交阶段嵌入自动化安全检查
+  - CI/CD 流水线分层治理：Commit 阶段检查 → PR 阶段 plan → Master 分支人工审核后 apply
+- 结论/价值：告别手动创建本地用户，实现"入离职账号自动化管理"；通过"左移"策略在开发早期发现并修复基础设施代码的安全问题
+
+## Key Claims（用中文描述）
+- Jenkins 与 AD 集成后，用户入离职可通过 AD 账号实现自动化管理，无需手动维护本地用户账户
+- 通过 AD 组策略可将用户映射为不同角色（只读、读写、流水线创建），实现基于 AD 的 RBAC 权限控制
+- pre-commit 框架可在功能分支提交时自动触发 terraform fmt（格式统一）、TFLint（逻辑验证）、Checkov（安全扫描），防止"坏代码"进入生产环境
+- "左移"（Shift-Left）治理模式将安全问题从生产阶段提前到开发阶段，通过分层 CI/CD 流水线实现渐进式质量门禁
+
+## Key Quotes
+> "通过 AD 集成，我们告别了过去手动创建本地用户的繁琐流程，实现了基于 AD 账号的自动登录。" — Niranjan
+
+> "terraform fmt 用于统一代码格式，TFLint 用于验证配置逻辑与参数完整性，而 Checkov 则负责静态安全分析。" — Niranjan
+
+> "在功能分支的每次提交时仅触发自动化检查；在 PR 阶段触发检查与 terraform plan；只有在代码合并至 Master 分支并经过人工审核后，才会执行最终的 terraform apply。" — Niranjan
+
+## Key Concepts
+- [[Active Directory Integration]]：将 Jenkins 的安全域与企业活动目录关联，实现用户身份的统一认证与自动化管理
+- [[RBAC (Role-Based Access Control)]]：基于角色的访问控制，通过 AD 组策略决定用户在 Jenkins 中拥有的具体操作权限
+- [[Pre-commit Framework]]：一个用于管理和维护多语言预提交钩子的框架，旨在代码提交至仓库前识别简单问题
+- [[Terraform Fmt]]：Terraform 内置的格式化工具，用于将配置文件重写为符合官方规范的标准格式
+- [[TFLint]]：一种针对 Terraform 的静态分析工具，用于检查代码中的人为错误、过时语法及缺失的参数
+- [[Checkov]]：一种静态代码分析工具，专门用于扫描基础设施即代码 (IaC) 中的安全性与合规性配置错误
+- [[Shift-Left Security]]：将安全检查从生产阶段提前到开发早期的实践，通过 CI/CD 流水线分层实现
+- [[CI/CD Pipeline Governance]]：CI/CD 流水线的分层治理模式——提交检查 → PR 检查+plan → 人工审核+apply
+
+## Key Entities
+- [[Niranjan]]：CTP Topic 11 主讲人，DevOps Cloud Learning Session 讲师
+- [[Jenkins]]：开源自动化服务器，本视频中与 AD 集成实现统一身份认证
+- [[SW Infra Active Directory]]：SW Infra 团队的 Active Directory 服务域，用于 Jenkins 的安全域集成
+- [[GitHub]]：源代码仓库，与 Jenkins 流水线通过 Webhook 触发集成（交叉引用来源）
+
+## Connections
+- [[ctp-topic-5-aws-identity-and-access-management-iam]] ← foundational ← [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+  - Topic 5 介绍 AWS IAM 联邦访问机制，Topic 11 将其延伸至 Jenkins 与企业 AD 的集成实践
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related ← [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+  - 均涉及 Jenkins CI/CD 流水线实践，Topic 9 聚焦 Gruntwork 框架，Topic 11 聚焦 AD 认证与安全检查
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← extends ← [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+  - Atlantis 是 Topic 11 中 terraform plan/apply 分层治理理念的具体实现工具
+- [[GitHub and Jenkins Integration]] ← depends_on ← [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]]
+  - Jenkins 与 AD 集成的前置依赖：GitHub 仓库与 Jenkins 流水线的触发与反馈机制已就绪
+
+## Contradictions
+- 与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] 在 terraform apply 审批模式上存在差异：
+  - 冲突点：谁拥有 terraform apply 的最终审批权（人 vs 机器）
+  - Topic 11 观点：Master 分支人工审核后执行 terraform apply，强调人工把关
+  - Atlantis 观点：通过 PR 评论自动触发 apply，强调机器自动化
+  - 当前整合观点：两者互补——Topic 11 定义治理原则（人工审核），Atlantis 实现具体执行机制

wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md

@@ -0,0 +1,58 @@
+---
+title: "CTP Topic 23 Introduction to the Technical Architecture Team and Function"
+type: source
+tags:
+  - Technical-Architecture
+  - Cloud-Transformation
+  - Team-Structure
+  - CTP
+sources: []
+last_updated: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]
+
+## Summary（用中文描述）
+- 核心主题：技术架构团队的职能、组织架构及其在公司云转型中的价值
+- 问题域：PSTC 与 IT 部门整合至 CIO 统一领导后的架构融合挑战
+- 方法/机制：推行"云优先"策略，维护 AWS Enterprise Landing Zones，制定 12-24 个月技术路线图
+- 结论/价值：从被动响应转向主动规划，通过标准化和治理确保云环境安全与高效，帮助业务部门规避风险、优化预算并提升交付速度
+
+## Key Claims（用中文描述）
+- 技术架构团队将 PSTC 与 IT 整合为统一领导，实现两个大型组织的深度融合
+- 技术架构团队通过维护 AWS Enterprise Landing Zones 实现云环境标准化和治理
+- 团队推行"云优先"策略，新业务优先上云，除非数据主权、合规性或极端成本原因必须保留在本地
+- 三层架构分工：EA 对接业务战略，SA 负责中间件与服务优化，TA 专注底层技术实施与基础设施治理
+- 通过划分"技术领域"并由首席架构师负责，制定 12-24 个月前瞻性路线图
+- 技术路线图帮助业务部门规避风险、优化预算、提升交付速度，从基础设施维护中解放出来专注客户价值
+
+## Key Quotes
+> "从被动响应转向主动规划" — Martin Nash，技术架构经理
+> "除非因数据主权、合规性或极端成本原因必须保留在本地，否则所有新业务应优先上云" — 云优先策略核心原则
+> "技术架构团队帮助业务部门从繁杂的基础设施维护中解放出来，专注于为客户创造价值" — 团队价值定位
+
+## Key Concepts
+- [[Cloud-First Strategy]]：架构原则，规定新服务部署首选云解决方案，仅在明确限制时考虑本地部署
+- [[AWS Enterprise Landing Zones]]：预配置的、符合最佳实践的 AWS 多账号环境，提供统一治理、安全和网络连接标准
+- [[Technical Domains]]：将技术栈划分为特定领域（身份认证、网络、Microsoft 堆栈等），每个领域由专人负责生命周期与路线图
+- [[Enterprise Architecture (EA)]]：架构体系高层，将业务目标转化为技术原则和标准
+- [[Solution Architecture (SA)]]：架构体系中间层，专注于特定项目或服务的优化实施
+- [[Technical Architecture (TA)]]：最贴近技术的架构层，负责基础设施设计、实施治理及技术路线图维护
+- [[Roadmaps]]：针对各技术领域制定的 12-24 个月前瞻性规划
+- [[ITIL Alignment]]：将架构工作与 IT 服务管理框架结合，确保技术交付系统性
+
+## Key Entities
+- [[Martin Nash]]：技术架构经理（Technical Architecture Manager），本次演讲主讲人
+- [[Cloud Transformation Office]]：云转型办公室，主办本次学习会议
+- [[Technical Architecture Team]]：技术架构团队，负责维护 AWS Enterprise Landing Zones 和技术路线图
+- [[Chief Architects]]：首席架构师，负责各技术领域的生命周期与路线图
+
+## Connections
+- [[ctp-topic-47-enterprise-architecture-cloud-standards]] ← aligns_with ← [[Technical Architecture Team]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← depends_on ← [[AWS Enterprise Landing Zones]]
+- [[ctp-topic-57-product-backlog-managing-demand]] ← extends ← [[Technical Architecture Team]]
+- [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]] ← supports ← [[Roadmaps]]
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的内容冲突

wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md

@@ -0,0 +1,55 @@
+---
+title: "CTP Topic 41 NFR's and Error Budgets"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md]]
+
+## Summary（用中文描述）
+- 核心主题：NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——SRE 团队如何驱动产品组与运维协作，满足客户期望，以敏捷方式确保运维要求，并理解错误预算边界以快速可靠地交付功能。
+- 问题域：云环境下的可靠性工程、敏捷开发中的运维融合、NFR 的云原生落地
+- 方法/机制：NFR Epic 模板将需求集成到 Sprint Backlog；Error Budget 通过 SLO/SLI 量化系统可容忍的不可靠程度；混沌工程主动注入故障验证系统韧性
+- 结论/价值：Error Budget 归一化失败弥合开发与运维的鸿沟；NFR 应更具规范性并利用云原生服务；监控能力是衡量 Error Budget 是否达标的关键
+
+## Key Claims（用中文描述）
+- NFR 是评判系统运行的准则，Error Budget 是系统可容忍的最大故障时间，两者共同构成云环境下可靠性工程的基石
+- AWS 共享责任模型将基础设施管理责任转移给云提供商，但公司必须在云中架构和管理服务以满足 NFR
+- Error Budget = 1 - 可用性 SLO（如 99.9% SLO → 0.1% Error Budget），用于衡量系统在影响客户前可承受的不可靠程度
+- Error Budget 将失败归一化为开发流程的一部分，弥合了开发与运维之间的文化鸿沟
+- 混沌工程通过主动注入故障测试系统韧性，确保 NFR 得到满足
+
+## Key Quotes
+> "We want to drive collaboration across our product groups and operations to ensure our obligation to our customers." — Brendan Standing，SRE 协作目标
+> "Error budgets normalize failure as part of the development process." — Error Budget 的核心理念
+> "SLRs are quantifiable measures of reliability, SLOs define how a service should perform, and SLAs are customer-level agreements." — 三层服务等级体系
+
+## Key Concepts
+- [[NFR（非功能需求）]]：评判系统运行的准则，涵盖可用性、性能、安全性、可扩展性等维度；云环境下应更具规范性，充分利用云原生服务
+- [[Error Budget（错误预算）]]：系统可容忍的最大故障时间，由 SLO 推导而来；用于归一化失败并驱动开发和运维决策
+- [[SLO（服务等级目标）]]：定义服务应如何表现的绩效目标
+- [[SLI（服务等级指标）]]：可量化的可靠性度量指标
+- [[SLA（服务等级协议）]]：客户级别的正式协议
+- [[SLR（服务等级需求）]]：服务等级需求，与 SLO 配套使用
+- [[NFR Epic]]：将 NFR 模板集成到 Sprint Backlog 的敏捷实践，确保任何重大变更都考虑非功能需求
+- [[Chaos Engineering（混沌工程）]]：主动注入故障以测试系统韧性，确保 NFR 得到满足
+
+## Key Entities
+- [[Brendan-Standing]]：Micro Focus SRE 负责人（Head of SRE），本视频主讲人
+- [[AWS]]：Amazon Web Services，提供共享责任模型和云原生服务
+- [[Micro-Focus]]：企业云转型主体，OpenText 旗下公司
+
+## Connections
+- [[ctp-topic-30-managing-change]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR/Error Budget 与 SRE 变更管理实践高度关联，SRE 团队是 Error Budget 度量体系的核心执行者）
+- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR 中的可用性目标和 DR 策略直接相关，Error Budget 是衡量恢复能力的量化工具）
+- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← extends ← [[ctp-topic-41-nfrs-and-error-budgets]]（监控能力是衡量 Error Budget 是否达标的必要前提）
+- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] ← related_to ← [[ctp-topic-41-nfrs-and-error-budgets]]（NFR/Error Budget 是 SRE 度量弹性目标的工具，与 SRE 转型的方向一致）
+- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] ← extends ← [[ctp-topic-41-nfrs-and-error-budgets]]（DevOps 成熟度模型将 Error Budget 作为衡量系统可靠性和运维能力的核心指标）
+
+## Contradictions
+- 与 [[ctp-topic-30-managing-change]] 在 SRE 职责范围上存在视角差异：
+  - 冲突点：Topic 30 强调 SRE 的变更管理职责（Standard/Normal/Emergency Change），Topic 41 强调 SRE 的可靠性工程职责（NFR/Error Budget）
+  - 当前观点：两者是 SRE 职责的一体两面——变更管理是 SRE 的运营职责，NFR/Error Budget 是 SRE 的工程职责，共同构成完整的 SRE 能力体系
+  - 对方观点：Topic 30 侧重"如何处理变更"，Topic 41 侧重"如何定义可靠性目标"，两者互补而非矛盾

wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md

@@ -0,0 +1,61 @@
+---
+title: "CTP Topic 5 - AWS Identity and Access Management (IAM)"
+type: source
+tags:
+  - AWS
+  - IAM
+  - Security
+  - CTP
+  - Identity
+  - Federation
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-5-aws-identity-and-access-management-iam.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS IAM 的核心组件（用户、组、角色、策略）及其在联邦访问中的应用
+- 问题域：企业 AWS Landing Zone 中的身份认证与访问授权管理
+- 方法/机制：联邦用户通过 Active Directory 组映射到 IAM 角色；PFSSO 工具实现 CLI 联邦访问；最小权限原则指导策略定义
+- 结论/价值：IAM 用户主要用于服务账号，人工用户应通过联邦机制管理；角色是串联身份与权限的核心纽带
+
+## Key Claims（用中文描述）
+- Active Directory 组通过角色映射为联邦用户提供 Landing Zone 账号访问权限
+- 角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联起来
+- IAM 用户主要用于服务账号，人工用户应优先使用联邦访问
+- 策略应遵循最小权限原则，只授予严格必要的权限
+- VSM 请求是通过联邦获取账号访问的必经流程
+- 支持跨账号角色假设，允许指定账户的主体担任特定角色
+- Terraform 模块可用于定义 IAM 角色，包括假设角色策略和内联策略块
+
+## Key Quotes
+> "Roles don't enable actions; they tie together who can do something and what they can do." — 角色是连接身份与权限的纽带，而非直接启用操作的实体
+> "We only want to allow the access that is strictly required." — 最小权限原则
+> "IAM users are primarily for service accounts; federation is the preferred method for user management." — 联邦优先于 IAM 用户管理
+
+## Key Concepts
+- [[IAM（身份和访问管理）]]：AWS 服务，用于管理用户身份、组、角色和策略，控制对 AWS 资源的访问
+- [[Federation（联邦身份）]]：通过 Active Directory 组映射到 IAM 角色，实现单点登录访问 AWS
+- [[Least Privilege（最小权限）]]：只授予用户完成工作所需的最小权限的安全原则
+- [[IAM Role（IAM 角色）]]：一种 IAM 身份，具有特定权限，可由用户、服务或外部实体担任
+- [[IAM Policy（IAM 策略）]]：定义权限的 JSON 文档，指定允许或拒绝的操作及资源
+- [[Managed Policy vs Inline Policy]]：托管策略可在多个角色间复用，内联策略绑定到特定角色
+- [[Cross-Account Role Assumption]]：跨账号角色假设，允许指定账户的主体担任目标账户的角色
+- [[PFSSO]]：用于通过联邦身份实现 AWS CLI 访问的工具
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，云服务提供商，IAM 为其原生身份访问管理服务
+- [[Active Directory（AD）]]：微软目录服务，用于管理用户身份和组，通过联邦机制与 IAM 集成
+- [[accounts.json]]：位于每个 Landing Zone 根目录的文件，包含账户号列表
+- [[VSM]]：Virtual SMACKS 系统，通过联邦请求获取账号访问权限
+
+## Connections
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← related_to ← [[IAM（身份和访问管理）]]
+- [[learning-sessions-identity-governance-vsm-replacement]] ← related_to ← [[Federation（联邦身份）]]
+- [[ctp-topic-11-ad-integration-and-login-using-ad-accounts]] ← related_to ← [[Federation（联邦身份）]]
+- [[AWS-Landing-Zone]] ← depends_on ← [[IAM（身份和访问管理）]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← related_to ← [[Least Privilege（最小权限）]]
+
+## Contradictions
+- 无已知内容冲突

wiki/sources/ctp-topic-53-why-bother-with-cloud.md

@@ -0,0 +1,58 @@
+---
+title: "CTP Topic 53 Why bother with Cloud"
+type: source
+tags: [Cloud, Strategy, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md]]
+
+## Summary（用中文描述）
+- 核心主题：Micro Focus 云转型计划的商业价值论证——用数据说明为何要迁移到云端
+- 问题域：企业数据中心资产利用率低、成本高昂，云转型不仅是成本节约，更是创新催化剂
+- 方法/机制：ELT（高管团队）演示 → 数据支撑论点 → 落地进展展示（LZ 交付、账户标签框架、Dart 资产剥离）
+- 结论/价值：云迁移不是"是否"的问题，而是"速度"的问题；当前 55% AWS 成本发生在 LZ 之外，亟需治理
+
+## Key Claims（用中文描述）
+- Micro Focus 拥有全球最大的商业数据中心足迹——14个数据中心、近20,000台资产
+- 尽管年营收25亿美元，但 VMware 足迹比规模大8倍的公司还大，硬件利用率不足40%
+- 三个产品迁出 Bublikan 后，下线575台物理服务器，云端仅需240台虚拟服务器替代
+- Redding 退出时40%的应用直接关机无需迁移，Houston 有89个空机架和360台未使用服务器
+- 云迁移的收益不仅是成本节约，更能促进产品创新、改善灾备、开拓新市场
+- 当前55%的 AWS 成本发生在 Landing Zone 之外，缺乏自动化、安全和财务管控
+
+## Key Quotes
+> "Micro Focus has the world's largest commercial footprint." — ELT 2022 演示
+> "We're trying to give them the information so that they can understand how they are spending." — 成本可见性目标
+> "The benefits of moving to the cloud extend beyond cost savings, fostering innovation and increasing revenue." — 云转型核心论点
+
+## Key Concepts
+- [[Cloud Transformation Programme]]：Micro Focus 的云转型计划，目标整合基础设施、降低成本、促进创新
+- [[Landing Zone]]：三类 LZ（Labs/SAS/Corporate）分别支撑不同隔离级别的云环境
+- [[AWS Account Tagging Framework]]：609个 AWS 账户统一标签框架，用于成本追踪和产品组消费告知
+- [[Enterprise Platform]]：企业级平台包含公共云供应商（AWS）、SRE、CCOE、架构组、自动化、安全和财务管控
+- [[Multi-Cloud Strategy]]：本视频论证了云转型战略的必要性
+
+## Key Entities
+- [[Micro Focus]]：年收入25亿美元的 Enterprise Software 公司，拥有全球最大商业数据中心足迹
+- [[Executive Leadership Team (ELT)]]：高管团队，2022年听取数据中心规模汇报后推动云转型
+- [[Bublikan]]：数据中心名称，三个产品从该中心迁出后下线575台物理服务器
+- [[Redding]]：数据中心名称，退出时40%应用直接关机
+- [[Houston]]：数据中心名称，拥有89个空机架和360台未使用服务器
+- [[Dart]]：资产剥离项目，云转型计划已完成 Dart 资产剥离
+- [[CCOE (Cloud Center of Excellence)]]：云卓越中心，负责企业平台和安全策略
+- [[SRE (Site Reliability Engineering)]]：可靠性工程团队，SRE/CCOE/架构组共同构成企业平台
+
+## Connections
+- [[ctp-topic-43-vmware-cloud-on-aws]] ← tensions_with ← [[ctp-topic-53-why-bother-with-cloud]]
+- [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[ctp-topic-53-why-bother-with-cloud]]
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← extends ← [[ctp-topic-53-why-bother-with-cloud]]
+- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-53-why-bother-with-cloud]]
+
+## Contradictions
+- 与 [[ctp-topic-43-vmware-cloud-on-aws]] 存在观点张力：
+  - 冲突点：是否应将工作负载迁移到云端
+  - 当前观点（本视频）：应积极迁移至云端，数据中心规模庞大、利用率低，云迁移成本效益显著
+  - 对方观点（Topic 43）：VMware Cloud on AWS 提供混合云中间路线，适合不完全准备完全迁移的企业
+  - 当前处理方式：两种路线并存——原生 AWS LZ 适合新建工作负载，VMC on AWS 适合已有 VMware 环境的渐进迁移

wiki/sources/ctp-topic-57-product-backlog-managing-demand.md

@@ -0,0 +1,62 @@
+---
+title: "CTP Topic 57 Product backlog managing demand"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand]]
+
+## Summary（用中文描述）
+- 核心主题：产品待办列表（Product Backlog）管理 —— 企业级云转型计划中如何接收、评估、优先级排序和交付需求
+- 问题域：CTP（Cloud Transformation Programme）需求治理、团队资源规划、产品组入职与支持
+- 方法/机制：通过 SMACs 提交需求 → 双周评审会议（Matthew Chapman/David Grant/Brendan）→ 20题评估问卷 → Octane 特性化 → Sprint 规划（50%新需求/50%支持+技术债）→ 准备阶段（Prerequisite Phase）→ SRE 账号构建与交接 → Hyper Care 支持
+- 结论/价值：透明化需求管道，确保所有工作以同一标准评估；Sprint 分配 50% 保护容量给新需求，防止支持工作吞噬创新带宽
+
+## Key Claims（用中文描述）
+- 产品待办列表是需求缓冲区，存放即将推出的功能，标注需求来源、收益和优先级
+- 新请求必须通过 SMACs 提交以启动计时器和确保可追踪性；邮件或聊天仅用于初步接触
+- 需求通过双周评审会议（Matthew Chapman/David Grant/Brendan 等）评估理解度、价值和优先级
+- 约20题的评估问卷帮助判断每项请求的简洁性、成本和野心程度
+- 机会评估通过后进入 Octane 作为特性（Feature），附带任务列表
+- 新团队需经历准备阶段（Prerequisite Phase）以对齐期望并理解产品需求
+- Sprint 规划通常提前6个 Sprint 展开，分配约50%给新需求、50%给支持工单和技术债
+- 大型产品组（如 ADM 和 ITOM）举行双周会议以对齐计划与优先级
+- 准备阶段关键步骤：介绍会议 → AWS 账户创建（PCG 团队审核）→ 解决方案设计与精炼 → GitHub 仓库创建 → 防火墙标签定义；产品团队工作量约2小时，跨越1-2周
+- SRE 工程师构建账户并交接，提供控制台和 GitHub 访问详情；交接后提供2周 Hyper Care 支持
+- 现有产品组可通过 SMACs/邮件/Teams 请求支持；缺陷在当前 Sprint 解决并分配给原始 Squad
+- Teams 频道连接产品组、SRE 工程师、解决方案架构师和交付经理
+- 变更请求或增强与解决方案架构师讨论后集成到现有账户
+- 公有子网通常仅限于生产环境；团队提供 Atlantis 或 Grant 表单用于自助任务
+
+## Key Quotes
+> "We need a way to make sure it's transparent and we're holding everything up to the light and looking everything for the same lens as we are." — 关于需求管理透明化的核心理念
+
+> "It means that for ADM they can effectively plan all of the work that's going into their sprints with the engineers that are working solidly on their work." — 关于 Sprint 规划对 ADM 产品组的价值
+
+## Key Concepts
+- [[Product-Backlog]]: 产品待办列表，作为需求缓冲区存放即将推出的功能，包含来源、收益和优先级信息
+- [[Demand-Management]]: 需求管理，通过标准化流程（提交→评审→分配→交付）确保透明度和公平优先级排序
+- [[SMACs]]: Service Management and Customer Service，系统化服务管理工具，用于提交和追踪需求请求
+- [[Prerequisite-Phase]]: 准备阶段，新产品团队加入云转型旅程时的入职流程，对齐期望并完成技术准备
+- [[Hyper-Care]]: 交接后支持期，SRE 工程师在产品组接管后提供2周强化支持
+- [[Sprint-Planning]]: Sprint 规划，提前6个 Sprint 展开，50% 容量分配给新需求，50% 给支持工单和技术债
+- [[Octane]]: Micro Focus 的工作追踪平台，需求评估通过后进入 Octane 作为 Feature 并附带任务列表
+
+## Key Entities
+- [[Matthew Chapman]]: 需求评审会议主持人之一
+- [[David Grant]]: 需求评审会议参与者
+- [[Brendan Starnig]]: 需求评审会议参与者，SRE Function Lead（CTP Topic 30 讲师）
+- [[ADM]]: Application Development and Management，产品组之一，定期双周对齐会议
+- [[ITOM]]: IT Operations Management，产品组之一，定期双周对齐会议
+- [[PCG]]: Platform Control Group，准备阶段中审核 AWS 账户创建并提供云环境支持
+- [[SRE]]: Site Reliability Engineer，负责账号构建、交接和 Hyper Care 支持
+
+## Connections
+- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] ← related_to ← [[ctp-topic-57-product-backlog-managing-demand]]（两者均属 CTP 需求治理框架，本 Topic 聚焦 Backlog 管理，Topic 20 聚焦 Gate Process 和 POC 入职）
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ← related_to ← [[ctp-topic-57-product-backlog-managing-demand]]（两者均涉及 CTP 敏捷实践，Sprint 规划分配比例在 Topic 4 有更详细讨论）
+- [[ctp-topic-30-managing-change]] ← related_to ← [[ctp-topic-57-product-backlog-managing-demand]]（两者均涉及 SRE 与产品团队的协作，Brendan Starnig 在两个 Topic 中均有参与）
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的冲突内容。

wiki/sources/ctp-topic-6-aws-workspaces-demo.md

@@ -0,0 +1,65 @@
+---
+title: "CTP Topic 6 AWS Workspaces Demo"
+type: source
+tags:
+  - AWS
+  - Workspaces
+  - Demo
+  - CTP
+  - End-User Computing
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Workspaces 虚拟桌面解决方案的演示与实操体验
+- 问题域：如何为云转型团队快速提供预配置的开发工作站环境，实现"半小时内从申请到跑通 Terraform"的目标
+- 方法/机制：通过 AWS Workspaces 提供托管 Windows 虚拟桌面，内置 PFSSO、Terraform、TerraGrunt、Git、VS Code 等工具，用户通过邮件接收注册码和用户名即可登录使用
+- 结论/价值：AWS Workspaces 可在 21-45 分钟内为用户交付可用的云端开发环境，消除本地配置负担，提升云转型计划中基础设施团队的工作效率
+
+## Key Claims（用中文描述）
+- AWS Workspaces 为用户提供通过 Web 浏览器或客户端应用访问的托管桌面环境，可预配置特定工具或提供原生 Windows 安装
+- 目标是在提出申请后的半小时至 45 分钟内，使用户能够运行 TerraGrunt Plan 针对基础设施执行部署
+- 工作站运行 Windows Server 2016（因 Pulse UI 兼容性原因未选用 Amazon Linux），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code
+- 用户需联系 Naga 申请账号，未来计划与 Active Directory 集成
+- 登录后可访问 AWS Console（通过 Federation）、GitHub Enterprise 并生成 SSH 密钥
+- 演示中克隆仓库、认证 PFSSO 并运行 TerraGrunt Plan，全程约 21 分钟完成
+- 工作站使用后保留约一小时的活跃状态，可根据需要额外安装工具
+
+## Key Quotes
+> "The hope is that within half an hour, 45 minutes of making a request for a workspace, you've run a Terra Grunt plan against a piece of infrastructure."
+> — 演示目标：快速交付可用开发环境
+
+> "As you can see, we can successfully access GitHub Enterprise as well."
+> — 工作站可同时访问 AWS Console 和 GitHub Enterprise
+
+## Key Concepts
+- [[AWS Workspaces]]：AWS 托管的虚拟桌面解决方案（VDI），通过 Web 浏览器或客户端提供预配置 Windows 环境
+- [[Terraform]]：基础设施即代码（IaC）工具，用于声明式定义和配置云资源
+- [[TerraGrunt]]：Terraform 的包装器，提供锁文件管理、远程状态和目录结构管理
+- [[PFSSO]]：Pulse Federation SSO，企业单点登录解决方案，用于 AWS 资源访问认证
+- [[AWS Federation]]：AWS 联合身份，基于 SAML 2.0 实现外部身份提供商对 AWS Console 的访问
+- [[GitHub Enterprise]]：GitHub 企业版，内部源代码管理平台（已迁移至 GitLab，参考 ctp-topic-53 相关内容）
+
+## Key Entities
+- [[Naga]]：负责 AWS Workspaces 账号创建的联系人，用户需通过邮件联系 Naga 申请工作站
+- [[AWS]]：Amazon Web Services，云桌面服务（Workspaces）的提供商
+- [[Micro Focus]]：演示所属组织，云转型计划（CTP）的重要组成部分
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← extends ← [[ctp-topic-6-aws-workspaces-demo]]
+  - Topic 6 演示的工作站环境基于 Topic 1 中定义的 Gruntwork Landing Zone 架构
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related ← [[ctp-topic-6-aws-workspaces-demo]]
+  - 工作站中运行 TerraGrunt Plan 的能力是 CI/CD 流程的一部分
+- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← future_integration ← [[ctp-topic-6-aws-workspaces-demo]]
+  - 当前通过邮件（Naga）手动创建账号，未来计划与 Active Directory 集成实现自动化账号管理
+
+## Contradictions
+- 与 [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] 冲突：
+  - 冲突点：Topic 6 演示中提及访问 GitHub Enterprise
+  - 当前观点：AWS Workspaces 预装工具中包含 GitHub Enterprise 访问能力
+  - 对方观点：Project Thor 已将源代码管理平台从 GitHub Enterprise 迁移至 GitLab，GitHub Enterprise 许可证已于 12 月底到期不再续约
+  - 说明：视频录制时间早于 GitHub→GitLab 迁移完成，当前 GitHub Enterprise 已不可用，迁移后的 Workspaces 镜像应预装 GitLab 而非 GitHub Enterprise
+

wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md

@@ -0,0 +1,59 @@
+---
+title: "CTP Topic 8 - Implementation of Cloud Monitoring using Micro Focus Operations Bridge Manager"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md]]
+
+## Summary（用中文描述）
+- **核心主题**：使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案，填补传统 Sitescope 监控工具在云环境中的能力缺口。
+- **问题域**：云环境动态性强、资源生命周期短，传统监控工具依赖静态服务器部署，无法有效覆盖 AWS 多账户多区域场景；OBM 通过 Management Pack 策略化方案实现云原生的动态监控能力。
+- **方法/机制**：OBM AWS Account 部署 OBM 应用 + Postgres RDS + Operation Agent；Agent 通过 AWS Management Pack 利用 IAM Role 跨账户收集 CloudWatch 指标/日志；Global OBM 作为 Manager of Managers 汇聚多区域 Regional OBM 数据；事件通过 SMACKS 与 OSE 团队工单系统集成。
+- **结论/价值**：OBM Management Pack 支持任意公有云（AWS/Azure/GCP）的 CloudWatch 兼容服务，无需在被监控账户中安装任何代理，通过 IAM Role 信任关系实现安全无密钥的跨账户数据采集；新增实例自动发现和策略自动下发能力解决了云环境动态性问题。
+
+## Key Claims（用中文描述）
+- **OBM 相比 Sitescope 的优势**：提供更动态的云监控能力、更强的安全性和更广泛的 AWS 核心服务覆盖，适合公有云环境。
+- **OBM 架构**：Regional OBM 收集数据 → Global OBM 汇聚 → SMACKS 触发工单；OBM AWS Account 包含 OBM 应用、RDS 数据库和 Operation Agent 三层组件。
+- **跨账户监控机制**：Operation Agent 通过 AWS Management Pack 定义的 Policy，以 IAM Role 身份调用 CloudWatch API，无需在被监控账户安装服务器或共享 Access Key。
+- **动态监控能力**：当新实例添加到被监控账户时，Policy 自动部署，监控立即生效，无需人工干预。
+- **客户上云流程**：客户账户创建具有 CloudWatch Read-Only 访问权限的 IAM Role → 将 OBM Account 添加到信任关系 → 将 Role ARN 添加到 OBM Policy → 指定监控的命名空间/服务/指标/阈值/频率。
+- **多云支持**：OBM Management Pack 方案可监控任何将数据暴露给 CloudWatch 的公有云供应商和 AWS 服务，兼顾指标和日志。
+
+## Key Quotes
+> "The operation agent collects data using OBM management packs, specifically the AWS management pack, which instructs the agent to gather data from different accounts." — OBM AWS 监控的核心数据采集机制
+
+> "The agent uses role-based access to collect data from CloudWatch API, eliminating the need to install servers in customer accounts and share sensitive access keys." — IAM Role 机制的安全价值：无需密钥共享
+
+> "Whenever new instances are added, policies are automatically deployed, and monitoring begins, offering dynamic monitoring capabilities." — 动态监控的关键特性：自动发现与自动部署
+
+## Key Concepts
+- [[CloudWatch]]: AWS 监控数据源，OBM 通过 CloudWatch API 采集所有监控指标和日志
+- [[Cloud-Monitoring]]: 公有云监控的核心挑战——动态环境、多账户、免代理采集
+- [[OBM]]: Micro Focus Operations Bridge Manager，企业级监控管理平台，支持多云环境
+- [[Management-Pack]]: OBM 的策略包机制，定义监控间隔、指标、阈值和数据采集规则
+- [[IAM-Role]]: AWS IAM 角色，OBM Agent 通过角色信任关系实现跨账户安全访问 CloudWatch，无需共享密钥
+- [[Multi-Account-Monitoring]]: AWS Organizations 多账户环境下的集中监控架构
+- [[Landing-Zone-Monitoring]]: Landing Zone 架构中的监控组件，OBM Account 作为独立账户与 Shared/Logs/Security 账户交互
+- [[Dynamic-Monitoring]]: 云环境特有的动态监控能力——新增资源自动发现、策略自动下发
+
+## Key Entities
+- **[[Micro-Focus]]**: OBM 产品的供应商，提供 Operations Bridge Manager 企业级监控平台
+- **[[Sitescope]]**: Micro Focus 传统监控工具，被 OBM 替代，用于描述 OBM 相比旧方案的改进
+- **[[SMACKS]]**: Micro Focus 工单系统，OBM 事件通过 SMACKS 与 OSE 团队集成，实现事件升级和工单创建
+- **[[AWS-CloudWatch]]**: AWS 监控指标和日志服务，OBM Agent 的数据采集来源
+- **[[AWS-Operation-Agent]]**: 部署在 OBM AWS Account 的操作代理，负责跨账户收集 CloudWatch 数据
+- **[[Global-OBM]]**: 全球级 OBM，作为 Manager of Managers，汇聚各 Regional OBM 的数据
+- **[[Regional-OBM]]**: 区域级 OBM，收集本区域内各账户的监控数据并转发给 Global OBM
+- **[[Digital-Factory]]**: OBM AWS Account 所属的 Landing Zone 组成部分，与 Shared/Logs/Security 账户交互
+
+## Connections
+- [[CTP-Topic-29-Cloud-Monitoring-SAAS-LZ-Accounts]] ← related_to ← [[CTP-Topic-8-OBM-Cloud-Monitoring]]: Topic 29 讨论 SaaS Landing Zone 的云监控账户设计，Topic 8 详解 OBM 技术实现方案
+- [[CTP-Topic-60-Monitor-AWS-Grafana]] ← related_to ← [[CTP-Topic-8-OBM-Cloud-Monitoring]]: Grafana 作为可视化层，OBM 作为数据采集和策略管理层，两者互补
+- [[CTP-Topic-25-Labs-Landing-Zone]] ← extends ← [[AWS-Landing-Zone]]: Labs LZ 概述中提到的 ARC Site 监控组件与 OBM 的功能定位重叠
+- [[CTP-Topic-7-SAAS-Landing-Zone-Design]] ← extends ← [[AWS-Landing-Zone]]: SaaS LZ 设计中提到 Shared Services Account 包含 OBM/Sitescope 监控服务
+
+## Contradictions
+- 与 [[CTP-Topic-67-OpenTelemetry]]: Topic 67 倡导云原生可观测性标准（OTel），强调统一的数据模型和 Vendor-Neutral 采集；OBM 作为传统商业监控平台，数据模型封闭，与 OTelp 倡导的开放标准存在理念差异。当前实现选择 OBM 而非 OTelp，可能是出于企业既有投资保护（Micro Focus 工具链）和与 SMACKS 工单系统深度集成的考量。

wiki/sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md

@@ -0,0 +1,57 @@
+---
+title: "Learning Sessions Identity Governance VSM Replacement - 20231128"
+type: source
+tags:
+  - Identity-Governance
+  - VSM
+  - CTP
+  - IAM
+  - AWS-Identity-Center
+date: 2023-11-28
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md]]
+
+## Summary（用中文描述）
+- 核心主题：身份治理（Identity Governance）框架，以及用 Micro Focus IGA 替换 DXC 虚拟 SM（VSM）工具的计划
+- 问题域：企业数字身份管理——谁来访问、谁该访问、如何访问；内部/外部用户（含承包商）的权限治理
+- 方法/机制：Micro Focus IGA 通过资源控制工作流实现权限审批/撤销/监控；Active Directory 组映射角色；AWS Identity Center + IAM 提供云资源访问；IG 治理 AD 组工作流
+- 结论/价值：VSM 将被 IG 全面替换，采用相同架构但连接 Coptum 域；POC 正在进行中以验证架构和流程；用户通过 IGA Portal 申请权限，审批后自动授权
+
+## Key Claims（用中文描述）
+- 身份治理通过三个核心问题（谁当前有访问权限、谁应该有访问权限、如何执行访问）驱动数字化风险管理和合规
+- Micro Focus IGA 通过工作流管控 Active Directory 组的权限审批与撤销，并配合 AWS IAM + Azure AD Domain Services 实现云资源访问
+- IG 支持内部和外部用户（含承包商）的有时限访问权，适合临时权限管理场景
+- VSM → IG 替换计划将保持原有架构不变，但 IG 连接至 Coptum 域（而非原 DXC 域）
+- POC（概念验证）正在进行，以验证替换架构和审批流程的可行性
+- IGA Portal 用户体验：搜索资源 → 申请权限 → 填写表单 → 审批流 → 自动授权
+
+## Key Quotes
+> "Identity governance is a framework for managing digital identities efficiently, minimizing risk, and maintaining compliance." — 身份治理定义
+
+> "IG integrates with AWS Identity Center to provide access to resources via IAM. Groups in Active Directory represent roles, and IG governs access to these groups." — IG + AD + AWS Identity Center 集成架构
+
+> "The plan is to replace VSM with IG for all accounts, using the same architecture as VSM, but with IG connected to Coptum domain." — VSM 替换计划核心策略
+
+## Key Concepts
+- [[Identity-Governance]]：数字化身份管理框架，最小化风险、保持合规，核心三问：谁有访问/谁该访问/如何访问
+- [[IGA（Identity Governance and Administration）]]：身份治理与管理，Micro Focus IGA 是该领域的具体产品实现
+- [[AWS-Identity-Center]]：AWS 身份中心（原 AWS SSO），通过 IAM 提供云资源访问控制
+- [[Micro-Focus-IGA]]：Micro Focus 身份治理与管理工具，管控 AD 组工作流并连接 AWS Identity Center
+- [[Active-Directory]]：微软目录服务，AD 组映射角色，IGA 治理这些组的成员关系
+
+## Key Entities
+- [[Micro Focus]]：会议来源组织，其 IGA 产品线用于替换 DXC VSM 工具
+- [[DXC-VSM]]：DXC Virtual SM，DXC 提供的老一代身份治理工具，将被 Micro Focus IGA 替换
+- [[AWS-Identity-Center]]：AWS 身份中心，提供跨账户单点登录和权限管理
+- [[Azure-AD-Domain-Services]]：Azure AD 域服务，作为身份认证桥梁连接 DXC 域
+
+## Connections
+- [[Micro-Focus-IGA]] ← depends_on ← [[Active-Directory]]
+- [[AWS-Identity-Center]] ← depends_on ← [[Micro-Focus-IGA]]
+- [[Micro-Focus-IGA]] ← replaces ← [[DXC-VSM]]
+- [[Azure-AD-Domain-Services]] ← bridges_auth ← [[Active-Directory]]
+
+## Contradictions
+- 暂无已知冲突内容

wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md

@@ -0,0 +1,54 @@
+---
+title: "Public Cloud Learning Sessions- Applicable Business Analysis Techniques - 20240109"
+type: source
+tags: [Business-Analysis, Techniques]
+date: 2024-01-09
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md]]
+
+## Summary（用中文描述）
+- 核心主题：业务分析（Business Analysis）基础技能与核心技法，聚焦云转型背景下的需求定义与干系人管理
+- 问题域：敏捷团队中业务与技术之间的沟通鸿沟；新工作（需求、变更、项目）定义不清晰导致的混乱
+- 方法/机制：三大技法——BOSCARD（复杂新工作定义框架）、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集；T型技能模型连接业务与技术
+- 结论/价值：业务分析将业务需求与技术变更解决方案对齐；BOSCARD早期锁定范围"无价"；T型技能在敏捷 Squad 中的核心价值
+
+## Key Claims（用中文描述）
+- 业务分析通过调查现状、分析需求、识别方案、评估选项、定义需求，将业务需求与技术变更解决方案对齐，包括IT系统变更、流程变更、培训和角色转换
+- T型技能在敏捷 Squad 中极具价值，结合核心专业深度与相关技能的广度，业务分析技能是连接业务问题与技术解决方案的桥梁
+- BOSCARD通过澄清背景、目标、范围、约束、假设、风险、角色和交付物来定义复杂新工作，帮助避免目标和交付物混淆
+- 干系人轮盘从客户出发顺时针识别所有项目干系人（客户、合作伙伴、监管机构、员工、管理层、所有者、竞争对手），早期识别可防止变更和揭示风险
+- 结合用户故事与元数据的Requirements Gathering为需求捕获增加严谨性；SAFe框架在用户故事之外还包含Features、Capabilities和非功能需求
+- INVEST原则（Independent/Negotiable/Valuable/Estimable/Small/Testable）用于检查需求质量
+
+## Key Quotes
+> "Business analysis helps us work out what changes will be beneficial in our business architecture, including changes to IST systems and defining the requirements for those changes." — 业务分析核心价值定位
+
+> "If you can get scope tied down early on and agreed, that's priceless." — BOSCARD的价值
+
+> "Every requirement should be independent, meaning not duplicating something else, that's the I in INVEST, negotiable, so the business should state what they need, but be open to how it's implemented." — INVEST原则核心
+
+## Key Concepts
+- [[Business-Analysis]]：将业务需求与变更解决方案对齐的过程——调查现状、分析需求、识别方案、评估选项、定义需求；涵盖IT系统变更、流程变更、培训和角色转换
+- [[T-Shaped-Skills]]：结合核心专业深度与相关技能广度的技能模型；在敏捷 Squad 中弥合业务与技术之间的鸿沟
+- [[BOSCARD]]：复杂新工作定义框架——Background（背景）、Objectives（目标）、Scope（范围）、Constraints（约束）、Assumptions（假设）、Risks（风险）、Roles（角色）、Deliverables（交付物）
+- [[Stakeholder-Wheel]]：干系人识别工具，从客户出发顺时针识别所有项目干系人；可配合权力/影响矩阵或RACI矩阵使用
+- [[Requirements-Gathering]]：需求收集方法，结合用户故事（what/who/why）与元数据（版本、依赖、可追溯性、时间、验收标准、分类）
+- [[INVEST]]：优质用户故事检查原则——Independent（独立）、Negotiable（可协商）、Valuable（有价值）、Estimable（可估算）、Small（小型）、Testable（可测试）
+- [[SAFe]]：Scaled Agile Framework，在用户故事之外还包含Features（功能）、Capabilities（能力）和非功能需求（NFR）
+- [[RACI]]：责任分配矩阵——Responsible（负责）、Accountable（问责）、Consulted（咨询）、Informed（知情）
+
+## Key Entities
+- [[BCS]]：英国计算机学会，业务分析学习资源来源之一
+- [[IIBA]]：国际商业分析协会，业务分析学习资源来源之一
+- [[OpenText]]：主办 Public Cloud Learning Sessions 的公司
+
+## Connections
+- [[ctp-topic-57-product-backlog-managing-demand]] ← related_to ← [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]
+- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] ← related_to ← [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ← related_to ← [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]
+- [[ctp-topic-41-nfrs-and-error-budgets]] ← related_to ← [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]（NFR属于业务分析的需求定义范畴）
+
+## Contradictions
+- 与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 在流程视角上存在互补关系：Topic 4 提供敏捷持续流动的实践框架，本视频提供需求定义的前置技法；前者强调执行节奏，后者强调规划严谨性，两者共同构成云转型计划管理的完整方法论

wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md

@@ -0,0 +1,63 @@
+---
+title: "Public Cloud Learning Sessions - AWS End User Compute Services - 20240430"
+type: source
+tags:
+  - AWS
+  - End-User-Computing
+  - Workspaces
+  - AppStream
+date: 2026-04-14
+---
+
+## Source File
+- [[public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee]]
+
+## Summary（用中文描述）
+- 核心主题：AWS 终端用户计算（EUC）服务全景介绍——虚拟桌面与应用程序流
+- 问题域：远程/混合工作模式下的终端用户计算基础设施选型与安全设计
+- 方法/机制：Amazon Workspaces（全持久虚拟桌面）、AppStream 2.0（选择持久/非持久应用流）、Workspace Core（第三方 VDI 集成）、Workspace Web（低成本安全浏览器）四类服务的对比与适用场景分析
+- 结论/价值：帮助组织根据用户类型（知识工作者/任务工作者）和用例（完整桌面/应用流/安全浏览）选择最适合的 AWS EUC 服务方案
+
+## Key Claims（用中文描述）
+- Workspaces 适合需要完整桌面环境的知识工作者，AppStream 适合实验室、培训和堡垒主机场景
+- AppStream 提供多租户模式允许多用户共享实例，有效降低成本
+- 全持久桌面（Workspaces）提供一对一实例管理，应用状态和设置在会话之间保持
+- 非持久桌面（AppStream）提供每次登录全新桌面，支持应用连接器和存储连接器实现部分持久化
+- 成本优化通过 AppStream 并发使用和 Workspaces 自动停止功能实现
+- WSP 协议专为高延迟网络设计，支持灾难恢复策略（跨区域构建 Workspaces 或利用 AppStream 自动扩展）
+- 安全措施包括 Active Directory 集成、加密、IAM 配置文件和多因素认证
+
+## Key Quotes
+> "With so many remote workers organizations are struggling to protect endpoints, as well as their IP and data from bad actors." — AWS EUC 安全背景说明
+
+> "AppStream 2.0 is a great low cost alternative for customers that don't require a fully persistent desktop." — AppStream 2.0 定位
+
+## Key Concepts
+- [[Amazon Workspaces]]：全持久虚拟桌面服务，提供一对一实例管理，应用状态和设置在会话之间保持
+- [[AppStream 2.0]]：安全的应用流服务，提供选择性持久化，支持多租户模式，适合非持久桌面场景
+- [[AWS End User Computing]]：AWS 终端用户计算服务组合，包含 Workspaces、AppStream 2.0、Workspace Core、Workspace Web 四大服务
+- [[Virtual Desktop Infrastructure]]：虚拟桌面基础设施，通过虚拟化技术在云端交付桌面环境
+- [[WSP Protocol]]：Workspaces Streaming Protocol，专为高延迟网络设计的流传输协议
+- [[BYOD（Bring Your Own Device）]]：自带设备工作模式，员工使用个人设备访问企业资源
+- [[VDI（Virtual Desktop Infrastructure）]]：虚拟桌面基础设施，Workspace Core 提供对 Workspaces VDI 基础设施的 API 访问
+- [[SAML Authentication]]：基于 SAML 的身份认证，增强安全性的同时简化用户体验
+- [[VPC Interface Endpoints]]：VPC 接口终端节点，用于通过私有连接安全访问 AWS 服务
+
+## Key Entities
+- [[Christian O'Donough]]：AWS 主讲人，分享 AWS EUC 服务学习课程
+- [[Amazon Workspaces]]：AWS 全持久虚拟桌面服务
+- [[AppStream 2.0]]：AWS 应用程序流服务
+- [[Workspace Core]]：提供 Workspaces VDI 基础设施 API 访问，支持 Horizon View、Citrix 等第三方集成
+- [[Workspace Web]]：低成本安全 Web 浏览器，用于访问内部网站和 SaaS 应用
+- [[Amazon VPC]]：AWS 虚拟私有云，EUC 架构包含服务 VPC（AWS 托管）和客户 VPC
+- [[Active Directory]]：活动目录集成，EUC 服务的身份认证基础
+- [[CloudWatch]]：AWS 监控服务，支持 EUC 运营指标监控
+
+## Connections
+- [[ctp-topic-6-aws-workspaces-demo]] ← extends ← [[AWS End User Computing]]
+- [[AWS End User Computing]] ← depends_on ← [[Amazon VPC]]
+- [[AWS End User Computing]] ← depends_on ← [[Active Directory]]
+- [[AppStream 2.0]] ← extends ← [[AWS End User Computing]]
+
+## Contradictions
+- 无已知冲突内容

wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md

@@ -0,0 +1,59 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration"
+type: source
+tags:
+  - GitHub
+  - GitLab
+  - Migration
+  - OpenText
+  - DevOps
+  - Source Control
+date: 2024-06-25
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab
+- 问题域：企业级版本控制系统迁移、多团队协同转型、CI/CD 流水线重构
+- 方法/机制：Project Thor 统一工具链；Build Hub 团队提供支持；各团队自主规划迁移；两种迁移方案（镜像同步 / 搬移重构）；通过 PHT（Product Hub Platform）跟踪进度
+- 结论/价值：GitHub 许可证12月底到期不续，GitLab 许可证覆盖8,500用户；迁移是自服务模式（self-serve），Build Hub 提供辅助支持
+
+## Key Claims（用中文描述）
+- OpenText 决定将 GitLab 作为源代码控制的黄金标准（golden standard）
+- GitHub Enterprise 许可证12月底到期，公司不打算续约
+- GitLab 许可证覆盖高达 8,500 名用户
+- 各团队需自行盘点 GitHub 资产、识别流水线、规划迁移
+- 迁移完成标准：代码迁移完成 + 流水线转型 + PHT 更新
+- GitLab 仓库权限由 PHT 控制，支持自助访问管理
+- 个人仓库允许存在于 GitLab，但不得包含产品源代码，且不会被 PHT 映射
+- 网络连通性挑战通过在 Brook Park 创建 GitLab 代理解决
+
+## Key Quotes
+> "Project Thor aims to integrate Micro-Focus and OpenText tooling, with GitLab as the centralized system for source control." — 迁移背景说明
+> "Each team will define what they have in GitHub today, how they're using it, and they will plan to move it and change their pipelines." — 自服务迁移模式
+> "The current solution that is working and is efficient and is actually reporting to scale." — GitLab 代理方案评价
+
+## Key Concepts
+- [[Project Thor]]：整合 Micro Focus 和 OpenText 工具链的项目，GitLab 作为源代码控制的集中系统
+- [[Build Hub]]：负责管理 GitLab 等中心工具并为软件交付流水线提供支持
+- [[PHT（Product Hub Platform）]]：产品 Hub 平台，用于管理 GitLab 仓库权限映射和迁移进度跟踪
+- [[Mirroring]]：镜像方案，将 GitHub 仓库同步到 GitLab
+- [[Shift and Lift]]：搬移重构方案，将代码复制到 GitLab 并同时转换流水线
+- [[Service Account Standard]]：服务账号标准，要求服务账号必须关联到个人，密码设有到期时间
+
+## Key Entities
+- [[OpenText]]：本次迁移的主体公司，合并了 Micro Focus
+- [[GitHub Enterprise]]：被迁移的源代码管理平台，许可证12月底到期
+- [[GitLab]]：迁移目标平台，作为源代码控制的黄金标准
+- [[Build Hub]]：Build Hub 团队，负责中心工具管理和流水线支持
+
+## Connections
+- [[OpenText]] ← uses ← [[GitLab]]（作为源代码管理标准平台）
+- [[OpenText]] ← deprecated ← [[GitHub Enterprise]]（12月底到期停用）
+- [[Build Hub]] → supports → 各团队迁移
+- [[PHT（Product Hub Platform）]] ← manages ← GitLab 仓库权限
+
+## Contradictions
+- 无已知冲突内容

wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md

@@ -0,0 +1,54 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806"
+type: source
+tags: []
+date: 2024-08-06
+---
+
+## Source File
+- [[public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText Product Hub（产品层次结构追踪器，简称 PhD 或 PHT）的功能概述与操作演示
+- 问题域：企业内部软件产品资产治理、CI/CD 流水线管理、跨团队产品信息标准化
+- 方法/机制：通过层级结构（业务单元→业务线→产品）和自助服务流程实现产品信息集中管理；与 Jira、Value Edge、PSMQ、ITLS、OSS 等外部系统集成
+- 结论/价值：统一产品视图，支持 Source Repo 和 Artifact Repo 权限管理，实现跨工具链的产品信息一致性
+
+## Key Claims（用中文描述）
+- Product Hub (PhD) 由产品经理或开发经理驱动，收集和管理官方产品及其部门信息，区别于官方产品命名注册表中的主产品
+- Product 定义为具有独立 CI/CD 流水线或发布周期的软件分发；若某组件有自己独立的发布周期（如独立 CI/CD 流水线），应作为 Product 而非 Component 处理
+- PhD 层级结构：业务单元（含工程和 PM 负责人）→ 业务线（含负责人和 PM Lead）→ 产品（含 PM 和开发经理，并关联主产品）
+- 新建 Product 是自助服务流程：提交后经业务线审批；Source Repo 在 GitLab 创建后需 24 小时才在 PhD 中反映，空 Group/Repo 无法被搜索到
+- Product 有三种状态：Active（常规发布）、Maintenance（仅热修复/Bug 修复）、Inactive（无发布）
+- Component 是没有 CI/CD 流水线的库，如需 ITLS 审查或扫描应创建为 Product
+- Source Repo 权限可共享给子产品（只读访问）；Product Team 可配置为 Engineering（全权访问）或 Moderator（维护者访问）类型
+
+## Key Quotes
+> "A product is a software distribution with its own CI/CD pipeline or release cycle." — Product 与 Component 的核心区分标准
+> "A product may also be part of another parent product, but if that particular product has its own cycle, like its own CI/CD pipeline, then we may treat that particular component or module as a product in PhD." — Product 的层级归属逻辑
+> "Requesting for a new product is a self-serve process." — 自助服务是 PhD 的核心理念
+> "Source repo creation in GitLab takes 24 hours to reflect in PhD, and empty groups/repositories cannot be searched." — GitLab 与 PhD 同步的已知限制
+> "For product name/status changes, contact erphd@opentext.com; for technical questions, contact aangetoolsupport@opentext.com." — 支持渠道
+
+## Key Concepts
+- [[Product Hub (PhD)]]：OpenText 产品层次结构追踪器，统一管理业务单元、业务线、产品的层级关系和元数据
+- [[CI/CD Pipeline]]：产品定义的核心属性之一，独立流水线是将 Component 升级为 Product 的判断标准
+- [[Source Repo]]：源代码仓库，与 GitLab 集成，PhD 中映射 Source Repo 权限；创建后 24 小时同步
+- [[Artifact Repo]]：制品仓库，PhD 中管理 Artifact Repo 权限，新结构默认启用
+- [[Product Hierarchy]]：业务单元（BU）→ 业务线（LOB）→ 产品（Product）的三层结构
+
+## Key Entities
+- [[OpenText]]：企业软件公司，主导本次 Public Cloud Learning Sessions
+- [[Product Manager]]：产品经理，PhD 中承担产品创建和维护职责
+- [[Development Manager]]：开发经理，产品管理的核心角色
+- [[ITLS]]：Integrated Tool Lifecycle System，PhD 集成的外部系统之一
+- [[PSMQ]]：Product Service Management Queue，PhD 集成的外部应用
+- [[Value Edge]]：外部应用集成，PhD 打通数据流
+- [[Jira]]：项目跟踪工具，PhD 与其集成
+
+## Connections
+- [[Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows]] ← depends_on ← [[Product Hub (PhD)]]
+- [[Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration]] ← extends ← [[Product Hub (PhD)]]
+
+## Contradictions
+- 无已知冲突内容

wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md

@@ -0,0 +1,41 @@
+---
+title: "Public Cloud Learning Sessions - OpenText Tagging Standard v2 - 20250429"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText 云资源标签标准 v2——覆盖云账户、云资源、Kubernetes 对象和容器镜像的统一标签规范
+- 问题域：云成本优化、资源安全合规、服务交付自动化
+- 方法/机制：通过标准化标签前缀（OT\_ / app.opentext.com / com.opentext.image）实现跨云平台的统一标签语义；IaC 自动化标签创建与维护
+- 结论/价值：标签标准化是 FinOps 成本优化的基础，同时支撑安全合规、资源组织和自动化工作流
+
+## Key Claims（用中文描述）
+- OpenText 通过标准化标签驱动成本优化的三大机制：成本分配、风险降低（快速定位技术联系人）、自动化效率提升
+- Phenops 团队 2023 年发起的标签标准现已扩展至 Kubernetes 对象和容器镜像，覆盖 3,500 个云账户和 48 种 landing zone 类型
+- 标签治理最佳实践：IaC 自动化替代手动打标、检测报告发现缺失标签、禁止在标签中存储敏感数据
+
+## Key Quotes
+> "Tags are key-value pairs that typically have a tag key and an optionally a key value, which you can attach to cloud resources, cloud accounts, container images, Kubernetes objects and other things." — 标签的核心定义
+> "It is about taking resources and you will learn more in the presentation about what kinds of object and what exactly and so on." — 标签标准的适用对象概述
+
+## Key Concepts
+- [[Terraform]]：基础设施即代码工具，用于自动化标签创建和维护
+- [[Kubernetes]]：容器编排平台，标签标准扩展至其对象（namespaces、pods、deployments、services、config maps）
+- [[Container-Images]]：容器镜像，标签标准包含 product、title、description、vendor 等元数据标签
+
+## Key Entities
+- [[Martin-Rosler]]：讲师，介绍 OpenText Tagging Standard V2 的核心内容和三大驱动力
+- [[Phenops-Team]]：发起标签标准（2023年）的团队，原始版本已扩展 Kubernetes 和容器镜像指南
+
+## Connections
+- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← [[OpenText-Tagging-Standard-v2]]（两者均关注标签合规审计与强制执行）
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← relates_to ← [[OpenText-Tagging-Standard-v2]]（标签即凭证的云原生安全架构理念一致）
+- [[ctp-topic-28-aws-tag-validation-tool]] ← extends ← [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（审计工具是对 SCP 预防控制的存量检查补充）
+
+## Contradictions
+- 与 [[ctp-topic-28-aws-tag-validation-tool]] 在标签强制能力边界上无矛盾，两者互补：标签标准定义「应该怎么标」，验证工具发现「谁没标好」

wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md

@@ -0,0 +1,58 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows"
+type: source
+tags:
+  - Thor
+  - Platform
+  - OpenText
+  - Project Thor
+  - DevOps
+  - Supply Chain Security
+date: 2024-12-10
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText Project Thor 平台架构与数据流设计——源代码供应链安全与开发者体验标准化
+- 问题域：Micro Focus 与 OpenText 合并后的工具链整合、源代码治理、构建系统标准化
+- 方法/机制：五大支柱框架（敏捷周期治理、产品发布治理、开发者门户、安全治理、Build Hub）+ GitLab + Artifactory + Backstage + UCMDB 工具链整合
+- 结论/价值：标准化工具链、统一治理模型、提升开发者体验、保障供应链安全
+
+## Key Claims（用中文描述）
+- Arnold Dacan 提出：源代码是供应链的核心要素（"The main ingredient in the supply chain is our source code, our IP that is intended to live in GitLab"）
+- Project Thor 五大支柱：①敏捷与周期管理 ②产品与发布治理 ③开发者门户（Backstage） ④安全与治理 ⑤Build Hub
+- 标准化目标：在 GitLab、Artifactory、UCMDB 基础上统一工具链，为供应链安全奠定基础
+- 地理分布：主要工具链、源代码、构建系统位于 Brook Park；Sacramento 用于灾难恢复与业务连续性
+- 数据流架构：源代码流（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境
+
+## Key Quotes
+> "The main ingredient in the supply chain is our source code, our IP that is intended to live in GitLab." — Arnold Dacan，阐述源代码作为供应链核心的战略定位
+
+> "We are trying to standardize in GitLab, Artifactory, PMS and UCMDB are backend services that have started to grow and will grow further for supply chain security." — Arnold Dacan，阐述工具链标准化与供应链安全的关联
+
+## Key Concepts
+- [[Project Thor]]：OpenText 主导的源代码供应链安全与开发者平台标准化项目，五大支柱涵盖敏捷治理、发布治理、开发者门户、安全和 Build Hub
+- [[Supply Chain Security]]：源代码供应链安全——源代码作为核心 IP，通过 GitLab 集中管理，构建流程全程可追溯
+- [[Build Hub]]：Project Thor 五大支柱之一，构建系统集中化管理平台
+- [[GitLab Proxy]]：通过 GitLab 代理解决网络连通性问题，支持分布式团队访问源代码
+- [[GitLab Geo]]：GitLab 地理分布式部署，支持灾难恢复与业务连续性
+- [[Code Signing]]：代码签名流程，确保构建产物的完整性与来源可信
+
+## Key Entities
+- [[Arnold Dacan]]：Project Thor 平台与数据流分享的主讲人，OpenText 技术负责人
+- [[GitLab]]：OpenText 选定的源代码控制黄金标准（替代 GitHub Enterprise）
+- [[Artifactory]]：构建产物仓库，Project Thor 工具链核心组件
+- [[Backstage]]：开发者门户（Backstage.io），Project Thor 五大支柱之一
+- [[UCMDB]]：统一配置管理数据库，后端服务组件
+- [[Brook Park]]：OpenText 网络工具链主站点（源代码、构建系统所在）
+- [[Sacramento]]：灾难恢复与业务连续性站点
+- [[Micro Focus]]：OpenText 收购的公司，Project Thor 整合了其原有工具链
+
+## Connections
+- [[public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20]] ← extends ← [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]
+- [[ctp-topic-21-supply-chain-security-in-micro-focus]] ← related_to ← [[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]
+
+## Contradictions
+- 无已知冲突内容

wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md

@@ -0,0 +1,60 @@
+---
+title: "Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123"
+type: source
+tags:
+  - Tagging-Standard
+  - FinOps
+  - AWS
+  - Azure
+  - GCP
+  - Cloud-Governance
+date: 2024-01-23
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md]]
+
+## Summary（用中文描述）
+- 核心主题：OpenText 跨超大规模云厂商（AWS、Azure、GCP）的统一标签标准
+- 问题域：云成本优化、FinOps 治理、资源归属追踪
+- 方法/机制：OT_ 前缀标签设计、GCP 限制性字符集作为最低通用标准、Terraform 默认标签注入、SCP 强制执行标签合规
+- 结论/价值：标准于 10 月 3 日获批，目标将云资源浪费从行业平均 30% 降至 15%，预计每年节省约 2500 万美元，提升可持续性
+
+## Key Claims（用中文描述）
+- OpenText 未来三年超大规模云支出预计约 5 亿美元，统一标签标准可将浪费率从 30% 降至 15%
+- 将云浪费率降低 50% 可为 OpenText 每年节省约 2500 万美元，同时改善可持续性
+- 正式财务组织由 Tom Bice 领导，专注于跨业务部门提供报告，要求通过标签实现资源详细标注
+- 标签管道：计费控制台启用特定标签 → COST 和使用报告（CUR）包含标签值 → 通过 HCMX、Phenops、QuickSight、Power BI 报告
+- 标准采用最低通用标准原则：GCP 的限制性字符集（小写、数字、连字符、下划线）
+- 标签使用 OT_ 前缀区分，但环境、BU、成本中心等已有标签除外
+- 标准由工作组历时三个月开发，已于去年 10 月 3 日批准
+- Terraform 模块（如 AWS 实例模块）可通过 tags 参数实现默认标签注入
+- 未来计划通过 SCP 或标签策略强制执行 99% 资源标签率目标
+
+## Key Quotes
+> "If we can agree the tags that need to go here, we don't have to do this and we can get out the analysis results." — 关于统一标签标准的必要性，强调一致标签可避免临时标签映射的混乱管理
+
+> "Typically what you do is almost every module that you've got inside Terraform, so like the AWS instance module there, there's a tags parameter that you could use." — 关于 Terraform 标签实现的最佳实践
+
+## Key Concepts
+- [[FinOps]]：云财务管理，通过标签实现成本分配、优化和报告
+- [[Service-Control-Policies-SCPs]]：AWS Organizations 策略，通过「显式拒绝」逻辑强制执行标签规范
+- [[Tag-Based-Security]]：基于标签的安全控制机制，将资源标签作为安全凭证替代传统 IP 规则
+- [[Terraform-Tagging]]：通过 Terraform provider 定义和模块 tags 参数实现默认标签注入
+- [[Multi-Cloud-Governance]]：跨 AWS、Azure、GCP 的统一标签治理标准
+
+## Key Entities
+- [[Tom Bice]]：OpenText 财务组织负责人，主导跨业务部门的 FinOps 报告工作
+
+## Connections
+- [[public-cloud-learning-sessions-opentext-tagging-standard-v2]] ← extends ← 本页
+  - v2 在 v1 基础上扩展，覆盖 Kubernetes 对象和容器镜像标签
+- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← relates_to ← 本页
+  - Topic 10 详细描述了基于标签的安全控制机制和 SCP 强制执行
+- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← 本页
+  - Tag Validation Tool 实现了对 AWS 资源标签合规性的自动化审计
+- [[AWS-Tagging-Standards]] ← is_part_of ← [[OpenText-Tagging-Standard]]
+  - OpenText 标签标准是 AWS 标签规范的扩展，定义了跨云统一标准
+
+## Contradictions
+- 无明显冲突。该标准与现有 AWS 标签实践互补，统一了跨 AWS、Azure、GCP 的标签语义