Auto-sync: 2026-04-19 06:32

wiki/concepts/AWS-Landing-Zone.md

@@ -0,0 +1,25 @@
+---
+title: "AWS Landing Zone"
+type: concept
+tags:
+  - AWS
+  - Architecture
+  - Multi-Account
+---
+
+## Definition
+AWS Landing Zone 是 AWS 推荐的企业级云基础架构框架，通过多账号策略、安全基线、网络架构等组件提供安全、可扩展的云环境起点。
+
+## Key Components
+- **多账号策略**：通过 AWS Organizations 管理多个账户
+- **安全基线**：安全组、SCP、密码策略等
+- **网络架构**：VPC、Transit Gateway、VPN/Direct Connect
+- **身份管理**：IAM 角色、SSO、AD 集成
+
+## Related Concepts
+- [[Network-Segregation]]
+- [[SSM-Access]]
+- [[Gruntwork-Landing-Zone]]
+
+## Related Entities
+- [[AWS]]

wiki/concepts/Break-Glass-Access.md

@@ -0,0 +1,24 @@
+---
+title: "Break-Glass Access"
+type: concept
+tags:
+  - Security
+  - Emergency
+---
+
+## Definition
+Break-Glass Access（紧急访问）是指在紧急情况下绕过正常安全控制流程，获得系统访问权限的机制。通常作为备份方案，仅在无法通过正常渠道访问时使用。
+
+## Application
+在 AWS Landing Zone 安全策略中，长期目标是基础设施即代码（IaC）以减少控制台访问和 break-glass access 需求，紧急访问仅作为极端情况的最后手段。
+
+## Best Practices
+- 严格限制使用频率
+- 完整记录访问日志
+- 事后审查和报告
+- 逐步减少对它的依赖
+
+## Related Concepts
+- [[Zero-Trust-Access]]
+- [[AWS-Landing-Zone]]
+- [[Infrastructure-as-Code-IaC]]

wiki/concepts/CAPA.md

@@ -0,0 +1,31 @@
+---
+title: "CAPA"
+type: concept
+tags: [incident-management, postmortem]
+sources: [ctp-topic-30-managing-change]
+last_updated: 2026-04-19
+---
+
+## Summary
+CAPA（Corrective and Preventive Action，纠正和预防措施）是事故管理的重要组成部分，通过根因分析防止同类问题再次发生。
+
+## Definition
+CAPA 即 Post-mortem 回顾，目的是从事故中提取根因并预防同类问题再次发生。
+
+## Aliases
+- Corrective and Preventive Action：纠正和预防措施
+- Post-mortem：事故回顾
+
+## Process
+1. 事故响应：立即采取行动缓解影响
+2. 根因分析：识别问题的根本原因
+3. 纠正措施：修复已发现的问题
+4. 预防措施：制定措施防止同类问题再次发生
+5. 文档记录：完整记录分析和改进措施
+
+## Related Concepts
+- [[Incident Management]]：事件管理，CAPA 的上游流程
+- [[SRE]]：CAPA 的执行者
+
+## Connections
+- [[ctp-topic-30-managing-change]] ← is_the_source_for

wiki/concepts/Change-Management.md

@@ -0,0 +1,43 @@
+---
+title: "Change Management"
+type: concept
+tags: [ITSM, change-management, SRE]
+sources: [ctp-topic-30-managing-change]
+last_updated: 2026-04-19
+---
+
+## Summary
+变更管理是 ITSM 的核心流程之一，用于控制和管理 IT 环境的任何变更，降低变更风险并确保服务质量。
+
+## Definition
+在云转型项目中，变更管理涉及对生产环境或基础设施的任何修改的控制、审批和跟踪。
+
+## Change Types
+
+### 标准变更 (Standard Change)
+- 预批准变更，无需变更咨询委员会（CAB）批准
+- 风险低、影响小、高度可预测
+- 应尽可能实现完全自动化（IaC + CI/CD Pipeline）
+- 示例：标签更新、配置参数调整等
+
+### 正常变更 (Normal Change)
+- 包含一定风险或影响的变更
+- 需要 CAB 批准，并可能需要跨团队协调
+- 有预定义的变更窗口
+- 示例：新服务部署、架构变更等
+
+### 紧急变更 (Emergency Change)
+- 为了缓解事故并尽快恢复服务到期望状态而需要立即执行的变更
+- 事后通过 CAPA/Post-mortem 修复根因
+- 示例：紧急安全补丁、热故障修复等
+
+## Related Concepts
+- [[ITSM]]：IT 服务管理框架
+- [[SRE]]：站点可靠性工程，变更管理的执行方
+- [[SMACKS Ticket]]：变更记录和管理工具
+
+## Related Entities
+- [[Brendan Starnig]]：CTP Topic 30 讲师
+
+## Connections
+- [[ctp-topic-30-managing-change]] ← is_the_source_for

wiki/concepts/Cyber-Suite.md

@@ -0,0 +1,40 @@
+---
+title: Cyber Suite Standards
+type: concept
+tags:
+  - Security
+  - CTP
+  - Standards
+---
+
+## Description
+
+Cyber Suite（网络安全套件标准）是由 PSAC（Product Security Approval Committee）团队发布的网络安全标准文档，定义了 CTP 项目中产品必须遵循的加密算法和安全配置。
+
+## Updated Standards
+
+更新后的 Cyber Suite 标准包括：
+
+### Considered Standard（标准套件）
+- 符合 FIPS 标准
+- Java、Golang、Node.js、OpenCel for CNC++ 兼容
+
+### Optional（可选套件）
+- 为向后兼容提供
+- 但包含 CBC（Cipher Block Chaining）模式，被认为安全性较弱
+
+### Cipher Selection
+
+产品可从不同类别选择加密套件：
+- 密钥交换（Key Exchange）
+- 认证（Authentication）
+- 加密（Encryption）
+- 哈希（Hash）
+
+### Review Requirement
+
+使用非标准和可选套件之外加密算法的产品需经过 PSAC 团队审查。
+
+## References
+
+- [[CTP Topic 36 SendGrid as an email service]]

wiki/concepts/Early-Live-Support.md

@@ -0,0 +1,36 @@
+---
+title: "Early Live Support"
+type: concept
+tags: [SRE, cloud-transition]
+sources: [ctp-topic-30-managing-change]
+last_updated: 2026-04-19
+---
+
+## Summary
+Early Live Support（早期上线支持）是 Build 与 BAU 之间的过渡阶段，确保服务平稳上线。
+
+## Definition
+在云转型项目中，Early Live Support 是构建阶段完成后的上线过渡阶段，需要完成 Go-Live Checklist。
+
+## Key Requirements
+- 监控覆盖：确保所有关键服务和基础设施都得到充分监控
+- 支持模型：明确各团队与 SRE 团队的交互方式和责任范围
+- 事件响应流程：建立清晰的事件响应和升级流程
+- SLO/SLI 定义：定义明确的服务等级目标和指标
+
+## Go-Live Checklist Items
+- [ ] 监控覆盖完整
+- [ ] 支持模型已定义
+- [ ] 事件响应流程已建立
+- [ ] SLO/SLI 已定义
+- [ ] On-call Schedule 已配置
+
+## Related Concepts
+- [[SRE]]：早期上线支持的主要执行者
+- [[Change Management]]：与变更管理流程相关
+
+## Related Entities
+- [[Brendan Starnig]]：CTP Topic 30 讲师
+
+## Connections
+- [[ctp-topic-30-managing-change]] ← is_the_source_for

wiki/concepts/Enterprise-Architecture-EA.md

@@ -0,0 +1,29 @@
+---
+id: enterprise-architecture-ea
+title: "Enterprise Architecture (EA)"
+type: concept
+tags:
+  - Technical-Architecture
+  - Cloud-Architecture
+---
+
+## Definition
+企业架构（Enterprise Architecture，EA）是架构体系的高层，负责将业务目标转化为技术原则和标准，确保技术投资与商业战略一致。
+
+## Position in Architecture Hierarchy
+- **企业架构（Enterprise Architecture, EA）**：高层，负责将业务目标转化为技术原则和标准
+- **方案架构（Solution Architecture, SA）**：中间层，负责特定项目或服务的优化实施
+- **技术架构（Technical Architecture, TA）**：底层，负责具体基础设施的设计和实施治理
+
+## Responsibilities
+- 对接业务战略
+- 制定技术原则和标准
+- 确保技术投资与商业战略一致
+
+## Related Concepts
+- [[Technical-Architecture-TA]]
+- [[Solution-Architecture-SA]]
+
+---
+
+*最后更新: 2026-04-19*

wiki/concepts/Error-Budget.md

@@ -0,0 +1,45 @@
+---
+id: error-budget
+title: "Error Budget（错误预算）"
+type: concept
+tags: [sre, reliability, availability]
+last_updated: 2026-04-19
+---
+
+## Definition
+Error Budget（错误预算）是系统在不影响客户的前提下可以不可靠的最大时间量。它弥合了开发与运维之间的鸿沟，将失败正常化为开发过程的一部分。
+
+## Calculation
+```
+Error Budget = 1 - 可用性 SLO
+```
+
+例如：
+- 99.9% SLO → 0.1% Error Budget
+- 99.99% SLO → 0.01% Error Budget
+
+完美可用性是 100%，Error Budget 落在 SLO 和 100% 之间。
+
+## Usage
+- **在预算内**：开发者可以承担更多风险，快速交付功能
+- **超出预算**：开发者必须做出更保守的选择，优先保证稳定性
+
+## Measurement
+- [[SLI（服务等级指标）]]：可靠性的可量化度量指标
+- [[SLO（服务等级目标）]]：服务应该达到的性能/可靠性目标
+- [[SLA（服务等级协议）]]：客户级别的正式协议
+
+## Importance
+1. **监控能力**：快速显示 Error Budget 是否未充分利用或已超出
+2. **小幅度变更**：小迭代变更和充分测试的部署是管理 Error Budget 的关键
+3. **混沌工程**：通过故意引发故障测试系统韧性，确保满足 NFR
+
+## Relationship
+- [[SRE]] ← uses ← Error Budget
+- Error Budget ← derives ← [[SLO（服务等级目标）]]
+- [[SLO（服务等级目标）]] ← measures ← [[SLI（服务等级指标）]]
+
+## References
+- [[CTP Topic 41 NFR's and Error Budgets]] — Error Budget 概念详解
+- [[Brendan Standing]] — Micro Focus SRE 负责人
+- [[NFR（非功能需求）]] — Error Budget 服务的目标

wiki/concepts/Gate-Process.md

@@ -0,0 +1,29 @@
+---
+title: "Gate Process"
+type: concept
+tags:
+  - CTP
+  - Governance
+  - Approval
+date: 2026-04-19
+---
+
+## Summary
+- 定义：网关审批流程，用于治理项目进度的关键决策点
+- 目的：确保项目在进入下一阶段前满足特定条件和标准
+
+## Gate 节点
+
+| Gate | 名称 | 目的 |
+|------|------|------|
+| Gate 0 | 评估准入 | 初步评估需求是否满足进入 POC 的基本条件 |
+| Gate 1 | 设计权威审批 | 设计权威（Design Authority）审批解决方案设计，确保符合云原生原则 |
+| Gate 3 | 迁移准入 | 最终批准启动生产环境迁移 |
+
+## Related Concepts
+- [[Proof-of-Concept-POC]] — POC 阶段涉及 Gate 0、Gate 1
+- [[Solution-Design]] — Gate 1 审批的核心对象
+
+---
+
+*最后更新: 2026-04-19*

wiki/concepts/GitHub-Enterprise-to-GitLab-Migration.md

@@ -0,0 +1,45 @@
+---
+title: "GitHub-Enterprise to GitLab Migration"
+type: concept
+tags:
+  - DevOps
+  - Migration
+  - GitHub
+  - GitLab
+date-added: 2026-04-19
+---
+
+## Definition
+GitHub-Enterprise to GitLab Migration（GitHub Enterprise 到 GitLab 迁移）是 OpenText 将源代码仓库从 GitHub Enterprise 迁移到 GitLab 的企业级迁移项目。
+
+## Migration Approaches
+- **Mirroring**：将 GitHub 仓库同步到 GitLab，保持持续更新
+- **Shift and Lift**：将代码复制到 GitLab 并同时转换 CI/CD 管道
+
+## Migration Tracking
+- 通过 PHT（Product Hub platform）跟踪进度
+- 定期向开发经理和构建倡导者更新
+- 规划指南：清点 GitHub 资产、识别管道、了解网络连接
+
+## Key Milestones
+1. 安装 GitLab 插件
+2. 早期访问 GitLab
+3. 映射仓库到 PHT
+4. 设置服务账户
+5. 更新管道
+
+## Network Connectivity
+- GitLab proxy 位于 Brook Park，可通过 SD1 访问
+- 商业实例连接 GitLab 可能需要 GIS 团队批准例外
+
+## Related Entities
+- [[GitHub-Enterprise]]
+- [[GitLab]]
+- [[OpenText]]
+- [[Build-Hub]]
+- [[Project-Thor]]
+
+## Connections
+- [[GitHub-Enterprise]] → replaced_by → [[GitLab]]
+- [[Self-Serve-Migration]] ← applies_to ← [[GitHub-Enterprise-to-GitLab-Migration]]
+- [[Build-Hub]] ← supports ← [[GitHub-Enterprise-to-GitLab-Migration]]

wiki/concepts/HCX.md

@@ -0,0 +1,14 @@
+---
+title: "HCX (Hybrid Cloud Extender)"
+type: concept
+tags: [VMware, Migration, Hybrid-Cloud]
+---
+
+## Description
+VMware 提供的混合云扩展工具，实现 on-premises vSphere 和 SDDC 的双向可视化管理，支持每次迁移最多 200 台 VM。
+
+## Type
+- 产品/工具
+
+## Related
+- 用于 [[VMware-Cloud-on-AWS]] 的多云管理

wiki/concepts/Hub-and-Spoke.md

@@ -0,0 +1,34 @@
+---
+title: "Hub-and-Spoke"
+type: concept
+tags:
+  - networking
+  - topology
+---
+
+## Aliases
+- Hub-and-Spoke
+- 星型拓扑
+- Hub and Spoke
+
+## Description
+一种网络拓扑结构，所有分支（Spoke）连接到中心节点（Hub），分支间的通信通常经过 Hub 中转。在 AWS 云网络架构中，Transit Gateway 充当 Hub，VPC 和 Landing Zones 作为 Spoke，实现集中化的网络管理。
+
+## Use Cases
+- AWS Transit Gateway 连接多个 VPC
+- 企业广域网架构
+- 跨区域网络互联
+
+## Related Concepts
+- [[Transit Gateway]]
+- [[SD-WAN]]
+- [[Overlay Network]]
+
+## Related Entities
+- [[AWS]]
+
+## Sources
+- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]
+
+## Related Sources
+- [[ctp-topic-14-octane-hub-on-aws-real-life-experience]]

wiki/concepts/NFR.md

@@ -0,0 +1,30 @@
+---
+id: nfr
+title: "NFR（非功能需求）"
+type: concept
+tags: [sre, requirements, reliability]
+last_updated: 2026-04-19
+---
+
+## Definition
+NFR（Non-Functional Requirements，非功能需求）是评判系统运行状况的标准，决定可用性、性能、安全性、可扩展性等属性。
+
+## Key Aspects
+- **可用性（Availability）**：系统正常运行时间比例（如 99.9%、99.99%）
+- **性能（Performance）**：响应时间、吞吐量等
+- **安全性（Security）**：数据加密、访问控制等
+- **可扩展性（Scalability）**：水平/垂直扩展能力
+
+## Cloud Context
+在云端，NFR 应更规范化，利用云原生服务：
+- AWS Backup 定义备份策略和测试频率
+- DR 规划包含季度测试和 IaC 基础设施
+- NFR Epic 集成到 Sprint backlog
+
+## Relationship with SRE
+- [[SRE]] 通过 [[Error Budget（错误预算）]] 和 [[SLO（服务等级目标）]] 实现 NFR
+- [[混沌工程]] 验证 NFR 是否满足
+
+## References
+- [[CTP Topic 41 NFR's and Error Budgets]] — NFR 在云和敏捷开发中的应用
+- [[Brendan Standing]] — Micro Focus SRE 负责人

wiki/concepts/Network-Segregation.md

@@ -0,0 +1,21 @@
+---
+title: "Network Segregation"
+type: concept
+tags:
+  - Network-Security
+  - AWS
+---
+
+## Definition
+网络隔离是通过防火墙或其他安全设备控制不同网络区域之间通信的安全策略，确保敏感 workloads 与不受信任的网络区域分离。
+
+## Application
+在 AWS Landing Zone 环境中，通过 Checkpoint 防火墙控制服务器间通信（server-to-server communications），阻断内部网络（on-prem、VPN）直接访问 AWS 生产网段。
+
+## Related Concepts
+- [[Checkpoint-Firewall]]
+- [[SPI-Features]]
+- [[AWS-Landing-Zone]]
+
+## Related Entities
+- [[AWS]]

wiki/concepts/Observability-Engineering.md

@@ -0,0 +1,31 @@
+---
+title: "Observability Engineering"
+type: concept
+tags: [monitoring, sre]
+---
+
+## Definition
+可观测性工程是通过收集、分析和利用系统运行时数据（指标、日志、追踪）来持续理解系统健康状态的能力。
+
+## Three Pillars
+1. **Metrics（指标）**：数值型数据，如 CPU 使用率、请求延迟
+2. **Logs（日志）**：事件记录，详细描述系统活动
+3. **Traces（追踪）**：请求在系统中的完整调用链路
+
+## Goal
+不仅知道"系统是否正常运行"，更能理解"系统为什么这样运行"，实现：
+- 问题快速定位
+- 根因分析
+- 主动式运维
+- 容量规划
+
+## Related Tools
+- Prometheus：指标收集和存储
+- Grafana：可视化
+- Jaeger：分布式追踪
+- ELK Stack：日志分析
+
+## Related Concepts
+- [[SRE]]：站点可靠性工程
+- [[Monitoring]]：监控
+- [[Alerting]]：告警

wiki/concepts/Overlay-Network.md

@@ -0,0 +1,30 @@
+---
+title: "Overlay Network"
+type: concept
+tags:
+  - networking
+  - virtualization
+---
+
+## Aliases
+- Overlay Network
+- 叠加网络
+
+## Description
+叠加网络（Overlay Network）是在现有物理网络（Underlay）之上构建的逻辑网络，用于实现复杂的路由和隧道功能。常见的 Overlay 协议包括 VXLAN、GRE、IPsec 等。在 SD-WAN 架构中，Overlay 网络负责路径选择和流量调度，与底层的物理网络解耦。
+
+## Use Cases
+- SD-WAN 叠加网络
+- 容器网络（如 Kubernetes CNI）
+- VPN 隧道
+- 云间互联
+
+## Related Concepts
+- [[SD-WAN]]
+- [[Hub-and-Spoke]]
+
+## Related Entities
+- [[AWS]]
+
+## Sources
+- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]

wiki/concepts/Product-Backlog.md

@@ -0,0 +1,21 @@
+# Product Backlog
+
+Product Backlog（产品待办列表）是一个存放待开发功能和需求的区域，高亮显示需求、收益和优先级。
+
+## 核心特征
+
+- 需求容器：存放所有待处理的功能请求
+- 优先级排序：基于价值、重要性和复杂度进行排序
+- 透明度：确保所有需求在同一标准下被审视
+- 持续演进：随着项目进展不断更新和调整
+
+## 组成部分
+
+- 新需求：通过 SMACs 提交
+- 评估工具：约 20 个问题的计算器，评估简洁性、成本和野心
+- 入池机制：评估后移入 Octane 作为特性
+
+## 相关实践
+
+- [[前置条件阶段]]：新团队加入前的准备流程
+- [[Sprint-规划]]：通常提前 6 个迭代规划

wiki/concepts/Program-Demand-Process.md

@@ -0,0 +1,27 @@
+---
+title: "Program Demand Process"
+type: concept
+tags:
+  - CTP
+  - Process
+  - Demand-Management
+date: 2026-04-19
+---
+
+## Summary
+- 定义：从业务需求产生、优先级排序到最终交付迁移的端到端管理路径
+- 驱动因素：业务案例（如数据中心关闭）、高层管理人员战略优先级、产品组路线图
+- 关键环节：需求录入 → 优先级排序 → POC 决策 → Gate 审批 → 迁移至 Labs 或 SaaS
+
+## Related Concepts
+- [[Proof-of-Concept-POC]] — 在需求处理流程中用于验证可行性的阶段
+- [[Gate-Process]] — 治理项目进度的关键决策点
+- [[Landing-Zone]] — 最终交付的目标云环境
+
+## Connections
+- [[Sergio]] — 流程讲解专家
+- [[Damian]] — 流程讲解专家
+
+---
+
+*最后更新: 2026-04-19*

wiki/concepts/Project-Thor.md

@@ -0,0 +1,23 @@
+---
+title: "Project Thor"
+type: concept
+tags: [DevOps, Platform, OpenText]
+---
+
+## Summary
+OpenText 云平台标准化项目，通过五大支柱框架实现工具链统一和供应链安全。
+
+## Five Pillars
+- 敏捷和正确的周期管理（Agile and Right Cycle Management）
+- 产品和发布治理（Product and Release Governance）
+- Developer Portal（基于 Backstage）
+- Security as Governance（安全作为治理）
+- Build Hub（构建中心）
+
+## Goal
+标准化工具链，整合治理模型，推广 GitLab、Artifactory 等工具，提升开发者体验和供应链安全。
+
+## Connections
+- [[GitLab]] — 源代码托管
+- [[Artifactory]] — 制品仓库
+- [[OpenText]] — 所属公司

wiki/concepts/Proof-of-Concept-POC.md

@@ -0,0 +1,34 @@
+---
+title: "Proof of Concept (POC)"
+type: concept
+tags:
+  - CTP
+  - Validation
+  - Risk-Management
+date: 2026-04-19
+---
+
+## Summary
+- 定义：概念验证，在正式迁移前用于证明架构可行性、测试复杂网络需求及验证迁移方法的实验性阶段
+- 核心目的：降低迁移风险，验证架构和技术可行性，让团队熟悉基于 Gruntwork 构建的新一代 Landing Zone
+- 预期成果：
+  - 经过验证的解决方案设计
+  - 准备就绪的 IaC 脚本（Terraform/Terragrunt）
+  - 明确的迁移时间表
+
+## Success Criteria
+- POC 的成功标准应在启动前明确定义
+- 测试活动需有效证明产品已具备进入生产环境迁移的条件
+
+## Related Concepts
+- [[Program-Demand-Process]] — POC 的前置流程
+- [[Gate-Process]] — POC 需要通过的审批关卡
+- [[Infrastructure-as-Code-IaC]] — POC 阶段需要准备的核心交付物
+- [[Landing-Zone]] — POC 熟悉的目标环境
+
+## Connections
+- [[PCG-Team]] — 协助产品组进行 POC 的核心团队
+
+---
+
+*最后更新: 2026-04-19*

wiki/concepts/Recovery-Assurance.md

@@ -0,0 +1,28 @@
+---
+title: "Recovery Assurance"
+type: concept
+tags: [dr, reliability, sre]
+---
+
+## Definition
+恢复保障（Recovery Assurance）是一种从设计层面确保系统具备恢复能力的架构理念，与传统的灾难恢复（DR）不同，它强调主动式而非被动式响应。
+
+## Key Differences from DR
+- **DR（灾难恢复）**：被动响应，事件发生后尝试恢复
+- **Recovery Assurance**：主动设计，在设计阶段就考虑恢复能力
+
+## Core Principles
+1. **Design for Failure**：假设组件会故障，设计容错机制
+2. **Observability**：持续监控系统健康状态
+3. **Automation**：自动检测和恢复能力
+4. **Test-Driven**：通过测试验证恢复能力
+
+## Related Metrics
+- [[RTO]]（Recovery Time Objective）：恢复时间目标
+- [[RPO]]（Recovery Point Objective）：恢复点目标
+
+## Related Concepts
+- [[Self-Healing Systems]]：自愈系统
+- [[SRE]]：站点可靠性工程
+- [[Observability Engineering]]：可观测性工程
+- [[Chaos Engineering]]：混沌工程

wiki/concepts/SD-WAN.md

@@ -0,0 +1,32 @@
+---
+title: "SD-WAN"
+type: concept
+tags:
+  - networking
+  - wan
+---
+
+## Aliases
+- SD-WAN
+- Software-Defined Wide Area Network
+- 软件定义广域网
+
+## Description
+软件定义广域网（SD-WAN）是一种通过软件控制层对物理网络进行抽象的技术，实现动态路径选择和负载均衡。在企业云架构中，SD-WAN 通常作为 Overlay Network（叠加网络）部署在 AWS 等公有云上，解决静态路由的局限性。
+
+## Use Cases
+- 多分支机构网络互联
+- 动态路径选择和流量调度
+- 替代传统 MPLS 专线
+- Silver Peak 等 SD-WAN 方案集成
+
+## Related Concepts
+- [[Hub-and-Spoke]]
+- [[Overlay Network]]
+- [[Transit Gateway]]
+
+## Related Entities
+- [[AWS]]
+
+## Sources
+- [[ctp-topic-18-wide-area-networking-in-aws-cloud]]

wiki/concepts/SLA.md

@@ -0,0 +1,27 @@
+---
+id: sla
+title: "SLA（服务等级协议）"
+type: concept
+tags: [sre, reliability, contract]
+last_updated: 2026-04-19
+---
+
+## Definition
+SLA（Service Level Agreement，服务等级协议）是客户级别的正式协议，定义了服务提供者对客户的承诺。
+
+## Key Characteristics
+- **具有法律约束力**：违反可能涉及经济赔偿
+- **比 SLO 更宽松**：SLO 是团队内部目标，SLA 是对客户的承诺
+- **基于 SLO**：SLA 通常基于内部 SLO 制定
+
+## Relationship
+- [[SLA（服务等级协议）]] ← based_on ← [[SLO（服务等级目标）]]
+- [[SLO（服务等级目标）]] ← measures ← [[SLI（服务等级指标）]]
+
+## Example
+- SLO: 99.9% 可用性（内部目标）
+- SLA: 99.5% 可用性（对客户承诺，更宽松）
+
+## References
+- [[CTP Topic 41 NFR's and Error Budgets]] — SLI/SLO/SLA 体系详解
+- [[SRE]] — 站点可靠性工程实践

wiki/concepts/SLI.md

@@ -0,0 +1,28 @@
+---
+id: sli
+title: "SLI（服务等级指标）"
+type: concept
+tags: [sre, reliability, metrics]
+last_updated: 2026-04-19
+---
+
+## Definition
+SLI（Service Level Indicator，服务等级指标）是可靠性的可量化度量指标，用于衡量系统健康状态。
+
+## Common SLIs
+- **可用性**：成功请求占总请求的比例
+- **延迟**：请求响应时间（如 P99 延迟）
+- **错误率**：失败请求占总请求的比例
+- **吞吐量**：每秒处理的请求数（QPS）
+
+## Usage
+SLI 被 [[SLO（服务等级目标）]] 引用，用于测量服务是否达到预期可靠性水平。
+
+## Relationship
+- [[SLI（服务等级指标）]] ← measures ← [[SLO（服务等级目标）]]
+- [[SLO（服务等级目标）]] ← derives ← [[Error Budget（错误预算）]]
+- [[SLA（服务等级协议）]] ← based_on ← [[SLO（服务等级目标）]]
+
+## References
+- [[CTP Topic 41 NFR's and Error Budgets]] — SLI/SLO/SLA 体系详解
+- [[SRE]] — 站点可靠性工程实践

wiki/concepts/SLO.md

@@ -0,0 +1,32 @@
+---
+id: slo
+title: "SLO（服务等级目标）"
+type: concept
+tags: [sre, reliability, metrics]
+last_updated: 2026-04-19
+---
+
+## Definition
+SLO（Service Level Objective，服务等级目标）定义了服务应该达到的性能/可靠性目标，是团队努力实现的具体指标。
+
+## Common SLOs
+- **可用性目标**：99.9%（三个九）、99.99%（四个九）
+- **延迟目标**：P99 响应时间 < 200ms
+- **错误目标**：错误率 < 0.1%
+
+## Relationship with Error Budget
+SLO 与 Error Budget 直接关联：
+```
+Error Budget = 1 - 可用性 SLO
+```
+
+例如：99.9% SLO → 0.1% Error Budget
+
+## Hierarchy
+- [[SLI（服务等级指标）]] → measures → SLO
+- SLO → derives → [[Error Budget（错误预算）]]
+- SLO → satisfies → [[SLA（服务等级协议）]]
+
+## References
+- [[CTP Topic 41 NFR's and Error Budgets]] — SLO 与 Error Budget 关系详解
+- [[SRE]] — 站点可靠性工程实践

wiki/concepts/SMACs.md

@@ -0,0 +1,20 @@
+# SMACs
+
+SMACs（Service Management Access）是一个需求提交的标准化入口，用于启动计时器和确保需求被追踪。
+
+## 核心特征
+
+- 标准化提交：所有新需求必须通过 SMACs 提交
+- 计时启动：提交后开始计时
+- 追踪保证：确保需求被完整记录
+
+## 使用方式
+
+- 提交新需求
+- 追踪需求状态
+- 关联评审会议
+
+## 替代方案
+
+- 邮件或聊天可作为初始联系方式
+- SMACs 是最可靠的追踪方式

wiki/concepts/SPI-Features.md

@@ -0,0 +1,17 @@
+---
+title: "SPI Features"
+type: concept
+tags:
+  - Network-Security
+  - Firewall
+---
+
+## Definition
+SPI（Stateful Packet Inspection）是一种状态包检查防火墙功能，能够追踪活跃连接的状态，基于连接状态做出过滤决策，而非仅依赖静态规则。
+
+## Application
+在 AWS Landing Zone 网络隔离场景中，Checkpoint 防火墙启用 SPI 功能，默认拒绝（default deny）策略，仅允许必需的服务和网络段进入 Landing Zone。
+
+## Related Concepts
+- [[Network-Segregation]]
+- [[Checkpoint-Firewall]]

wiki/concepts/SSM-Access.md

@@ -0,0 +1,21 @@
+---
+title: "SSM Access"
+type: concept
+tags:
+  - AWS
+  - Security
+  - Remote-Access
+---
+
+## Definition
+SSM Access（AWS Systems Manager Access）是一种通过 AWS Systems Manager 实现安全远程访问的方案，用户通过扮演 IAM 角色获得目标 EC2 实例的 SSM agent 访问权限，无需 VPN 即可实现安全连接。
+
+## Application
+替代传统 VPN，通过浏览器会话或 AWS CLI 访问 AWS 环境内的 EC2 实例。优势包括：双因素认证、安全连接位于 AWS 网络内、成本低、部署快。
+
+## Related Concepts
+- [[AWS-Landing-Zone]]
+- [[Zero-Trust-Access]]
+
+## Related Entities
+- [[AWS]]

wiki/concepts/Self-Serve-Migration.md

@@ -0,0 +1,33 @@
+---
+title: "Self-Serve Migration"
+type: concept
+tags:
+  - DevOps
+  - Migration
+  - GitHub
+  - GitLab
+date-added: 2026-04-19
+---
+
+## Definition
+Self-Serve Migration（自服务迁移）是一种迁移模式，在这种模式下，各团队自行定义需求、规划迁移方案并执行管道转换，而非由中央团队统一执行。在 OpenText 的 GitHub 到 GitLab 迁移中采用此模式。
+
+## Characteristics
+- 各团队自行定义在 GitHub 中拥有的资产
+- 各团队规划如何移动代码和转换 CI/CD 管道
+- Build Hub 团队仅在需要时提供协助
+- 权限通过 PHT（Product Hub platform）进行自服务管理
+
+## Related Concepts
+- [[CI/CD-流水线]]
+- [[GitOps]]
+
+## Related Entities
+- [[GitHub-Enterprise]]
+- [[GitLab]]
+- [[Build-Hub]]
+- [[OpenText]]
+
+## Connections
+- [[Self-Serve-Migration]] → enabled_by → [[GitLab]]
+- [[Build-Hub]] ← supports ← [[Self-Serve-Migration]]

wiki/concepts/Solution-Architecture-SA.md

@@ -0,0 +1,29 @@
+---
+id: solution-architecture-sa
+title: "Solution Architecture (SA)"
+type: concept
+tags:
+  - Technical-Architecture
+  - Cloud-Architecture
+---
+
+## Definition
+方案架构（Solution Architecture，SA）是架构体系的中间层，专注于特定项目或服务的优化实施，确保系统组件间的高效协作。
+
+## Position in Architecture Hierarchy
+- **企业架构（Enterprise Architecture, EA）**：高层，负责将业务目标转化为技术原则和标准
+- **方案架构（Solution Architecture, SA）**：中间层，负责特定项目或服务的优化实施
+- **技术架构（Technical Architecture, TA）**：底层，负责具体基础设施的设计和实施治理
+
+## Responsibilities
+- 负责中间件与服务优化
+- 确保系统组件间的高效协作
+- 特定项目或服务的架构设计
+
+## Related Concepts
+- [[Enterprise-Architecture-EA]]
+- [[Technical-Architecture-TA]]
+
+---
+
+*最后更新: 2026-04-19*

wiki/concepts/Tagging-Methodology.md

@@ -36,4 +36,18 @@ date_added: 2026-04-18
 
 ## Related Entities
 - [[AWS]]
-- [[Gruntwork]]
+- [[Gruntwork]]
+
+## OpenText Tagging Standard V2
+OpenText Tagging Standard V2 是标签方法论的具体实现，由 Phenops 团队于 2023 年发起，扩展了以下应用范围：
+- 云账号
+- 云资源（计算、存储、网络）
+- Kubernetes 对象（namespace、pod、deployment、service、configmap）
+- 容器镜像
+
+### 标签规范特点
+- 使用小写下划线语法（如 `ot_business_unit`）
+- 前缀标签确保语义明确：
+  - OT_ 用于云标签
+  - app.opentext.com 用于 Kubernetes 标签
+  - com.opentext.image 用于容器镜像标签

wiki/concepts/Technical-Architecture-TA.md

@@ -0,0 +1,33 @@
+---
+id: technical-architecture-ta
+title: "Technical Architecture (TA)"
+type: concept
+tags:
+  - Technical-Architecture
+  - Cloud-Architecture
+---
+
+## Definition
+技术架构（Technical Architecture，TA）是三种架构职能中最贴近技术的层级，负责底层技术实施与基础设施治理。
+
+## Position in Architecture Hierarchy
+- **企业架构（Enterprise Architecture, EA）**：高层，负责将业务目标转化为技术原则和标准
+- **方案架构（Solution Architecture, SA）**：中间层，负责特定项目或服务的优化实施
+- **技术架构（Technical Architecture, TA）**：底层，负责具体基础设施的设计和实施治理
+
+## Responsibilities
+- 维护AWS Enterprise Landing Zones（企业落地分区）
+- 制定技术路线图（12-24个月前瞻性规划）
+- 推行"云优先（Cloud-first）"策略
+- 技术领域（Technical Domains）的生命周期管理
+
+## Related Concepts
+- [[Enterprise-Architecture-EA]]
+- [[Solution-Architecture-SA]]
+- [[Technical-Domains]]
+- [[AWS-Enterprise-Landing-Zones]]
+- [[Cloud-First-Strategy]]
+
+---
+
+*最后更新: 2026-04-19*

wiki/concepts/Technical-Domains.md

@@ -0,0 +1,29 @@
+---
+id: technical-domains
+title: "Technical Domains"
+type: concept
+tags:
+  - Technical-Architecture
+  - Cloud-Governance
+---
+
+## Definition
+将公司技术栈划分为特定的领域（如身份认证、网络、Microsoft堆栈等），每个领域由专人负责其生命周期与路线图。
+
+## Purpose
+- 通过首席架构师负责制，实现12-24个月前瞻性路线图规划
+- 帮助业务部门规避潜在风险、优化预算并提升交付速度
+- 从"救火式"响应转变为预测性规划
+
+## Examples
+- 身份认证领域（Identity & Access）
+- 网络领域（Networking）
+- Microsoft堆栈领域
+
+## Related Concepts
+- [[Technical-Architecture-TA]]
+- [[Enterprise-Architecture-EA]]
+
+---
+
+*最后更新: 2026-04-19*

wiki/concepts/WSJF.md

@@ -0,0 +1,35 @@
+---
+title: "WSJF (Weighted Shortest Job First)"
+type: concept
+tags: [Prioritization, CTP, Value-Delivery]
+last_updated: 2026-04-19
+---
+
+## Definition
+WSJF（加权最短作业优先）是一种用于序列 CTP（云转型计划）工作的优先级排序方法，基于成本效益最大化原则。
+
+## Formula
+```
+WSJF = (业务价值 + 时间关键性 + 风险与机会) / 作业规模
+```
+
+## Components
+- **业务价值 (Business Value)**：收入增加、成本降低、风险改善
+- **时间关键性 (Time Criticality)**：工作的时间敏感性
+- **风险与机会 (Risk & Opportunity)**：潜在风险和机会评估
+- **作业规模 (Size of Job)**：完成工作所需的 effort
+
+## Application
+用于在多个需求之间进行优先级排序，以实现：
+- 最小 effort 实现最大 value
+- 早期价值交付回业务
+- 最大化经济利益
+
+## Connections
+- [[WSJF]] ← prioritizes ← [[CTP]]
+- [[Demand Manager]] ← provides ← [[Business Value]]
+- [[Delivery Manager]] ← estimates ← [[Size of Job]]
+
+## Aliases
+- Weighted Shortest Job First
+- Cost of Delay

wiki/concepts/Zero-Trust-Access.md

@@ -0,0 +1,18 @@
+---
+title: "Zero Trust Access"
+type: concept
+tags:
+  - Security
+  - AWS
+---
+
+## Definition
+零信任访问（Zero Trust Access）是一种安全框架，遵循"永不信任、始终验证"原则，每次访问请求都需经过身份验证和授权，无论请求来自网络内部还是外部。
+
+## Application
+在 AWS Landing Zone 中，通过 SSM 实现零信任访问：用户需扮演 IAM 角色获得目标 EC2 实例的 SSM agent 访问权限，依赖现有访问控制并启用双因素认证。
+
+## Related Concepts
+- [[SSM-Access]]
+- [[AWS-Landing-Zone]]
+- [[Break-Glass-Access]]

wiki/concepts/敏捷实践.md

@@ -19,3 +19,6 @@ last_updated: 2025-03-02
 - [[CI/CD 流水线]]
 - [[价值流映射]]
 - [[DevSecOps]]
+
+## Occurrences
+- [[CTP Topic 4 Using Agile to run the Cloud Transformation Program]] — 案例：从 Scrum 过渡到 Kanban 最终采用混合模式