diff --git a/openclaw/每日复盘/2026-04-28.md b/openclaw/每日复盘/2026-04-28.md new file mode 100644 index 00000000..d02df5ce --- /dev/null +++ b/openclaw/每日复盘/2026-04-28.md @@ -0,0 +1,86 @@ +--- + +## 【yunhan】云瀚 每日复盘 - 2026-04-28 + +### 摘要 +- **日期**: 2026-04-28 +- **Agent**: yunhan +- **时间**: 23:20 + +### 活动记录 +**无活动** + +当天没有任何会话活动记录。 + +### Django Admin 日报查询 +- 访问 +- 筛选日期：2026-04-28 +- 结果：No messages found for the selected date range + +### 观察 +- 当天没有任何 agent 会话活动 +- Cron 定时任务正常触行 +- 这是近期连续第 6 天无活动（4/21-4/28 期间大部分日期无记录） + +### 建议 +- 考虑增加 yunhan 的主动监控任务 +- 或确认真实活动状态（用户是否外出等） + + + +## 【yunhan】云瀚 每日复盘 - 2026-04-28 + +### 摘要 +- **日期**: 2026-04-28 +- **Agent**: yunhan +- **时间**: 23:20 + +### 活动记录 +**无活动** + +当天没有任何会话活动记录。 + +### Django Admin 日报查询 +- 访问 http://192.168.3.45:8765/admin/daily-reports/ +- 筛选日期：2026-04-28 +- 结果：No messages found for the selected date range + +### 观察 +- 当天没有任何 agent 会话活动 +- Cron 定时任务正常触行 +- 这是近期连续第 6 天无活动（4/21-4/28 期间大部分日期无记录） + +### 建议 +- 考虑增加 yunhan 的主动监控任务 +- 或确认真实活动状态（用户是否外出等） + + +## 【yunce】云策 每日复盘 - 2026-04-28 + +### 复盘状态 +**状态**: 无会话数据 +**最近有记录的日期**: 2026-04-19 + +### 问题描述 +执行每日复盘任务时，通过 Django Admin 查看当天（2026-04-28）的日报记录，发现： +- 云策（yunce）当天（2026-04-28 23:29）没有任何会话记录 +- 系统最新有记录是 2026-04-19（而非昨天的 2026-04-27） +- 这与昨天（2026-04-27）的情况相同，连续第二天出现无数据 + +### 环境信息 +- **Agent**: yunce +- **Host**: shenwei-ubuntu-2 (192.168.3.45) +- **时间**: 2026-04-28 23:29 GMT+8 +- **数据源**: Django Admin (http://192.168.3.45:8765/admin/daily-reports/) + +### 可能原因 +1. 云策（yunce）今日未被用户或其他 agent 调用 +2. Gateway 会话记录生成有延迟 +3. 系统配置问题导致会话未正确记录 + +### 建议 +1. 确认云策今日是否实际被调用 +2. 检查 Gateway 日志 +3. 考虑使用 sessions_list 检查实际会话情况 + +--- diff --git a/wiki/concepts/Availability-Zone-ID.md b/wiki/concepts/Availability-Zone-ID.md new file mode 100644 index 00000000..f19c90d4 --- /dev/null +++ b/wiki/concepts/Availability-Zone-ID.md @@ -0,0 +1,82 @@ +--- +title: "Availability-Zone-ID" +type: concept +tags: [AWS, VPC, Networking, Multi-Account] +sources: + - ctp-topic-45-automatic-ip-address-allocation-with-ipam + - ctp-topic-61-workload-vpc-provision-with-ipam-automation +last_updated: 2026-04-24 +--- + +## Availability-Zone-ID + +AWS 可用区标识符（如 `ap-southeast-1a`、`ap-southeast-1b`），用于在多账号 AWS 环境中精确定位物理可用区位置。相比 AZ 名称，AZ ID 能唯一标识跨账号的同一物理位置。 + +## Problem: AZ Name Inconsistency + +不同 AWS 账号对同一物理可用区的**名称**可能不同： + +| 账号 A | 账号 B | 物理位置（AZ ID） | +|--------|--------|-------------------| +| ap-southeast-1a | ap-southeast-1b | apse1-az1 | +| ap-southeast-1b | ap-southeast-1a | apse1-az2 | + +**问题**： +- 账号 A 的 `ap-southeast-1a` = 账号 B 的 `ap-southeast-1b`（物理位置相同） +- 如果用 AZ 名称设计跨账号 VPC 对等连接或可用性架构，可能出现"看起来对称但物理不对称"的问题 + +## Solution: Use AZ ID + +使用 AZ ID（如 `apse1-az1`）替代 AZ 名称： + +```yaml +availability_zone_ids: + - apse1-az1 # 物理位置 apse1 的第一个 AZ + - apse1-az2 # 物理位置 apse1 的第二个 AZ +``` + +**优势**： +- 跨账号一致性：AZ ID 在所有账号中唯一标识同一物理位置 +- 可靠性设计：确保高可用架构在物理层面真正对称 +- VPC 对等连接：正确配置跨账号连接 + +## How to Find AZ IDs + +```bash +# 使用 AWS CLI 查询当前账号的 AZ ID 映射 +aws ec2 describe-availability-zones --output json +``` + +输出示例： +```json +{ + "AvailabilityZones": [ + { + "ZoneName": "ap-southeast-1a", + "ZoneId": "apse1-az1", + "RegionName": "ap-southeast-1" + }, + { + "ZoneName": "ap-southeast-1b", + "ZoneId": "apse1-az2", + "RegionName": "ap-southeast-1" + } + ] +} +``` + +## Key Concepts + +- [[VPC-自动化供给]]：AZ ID 是 VPC YAML 配置的一部分 +- [[IPAM]]：IPAM 与 VPC 供给集成时需考虑 AZ 映射 + +## Connections + +- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← YAML 支持指定 AZ ID +- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← 强调 AZ ID 用于跨账号一致性 + +## Aliases + +- AZ ID +- Availability Zone Identifier +- 物理可用区标识符 diff --git a/wiki/concepts/CIDR-审批流程.md b/wiki/concepts/CIDR-审批流程.md new file mode 100644 index 00000000..8d13e04a --- /dev/null +++ b/wiki/concepts/CIDR-审批流程.md @@ -0,0 +1,74 @@ +--- +title: "CIDR-审批流程" +type: concept +tags: [AWS, Networking, IPAM, Approval, Automation] +sources: + - ctp-topic-45-automatic-ip-address-allocation-with-ipam + - ctp-topic-61-workload-vpc-provision-with-ipam-automation +last_updated: 2026-04-24 +--- + +## CIDR-审批流程 + +基于 CIDR 地址块大小的差异化审批规则，用于平衡自动化效率与 IP 地址空间治理。IPAM 系统根据请求的子网大小自动路由至不同的处理流程。 + +## Approval Matrix + +| CIDR 前缀 | 子网大小 | IP 地址数量 | 审批流程 | +|-----------|----------|-------------|----------| +| /16 | 65,536 | 65,534 可用 | **自动批准** | +| /18 | 16,384 | 16,382 可用 | **自动批准** | +| /20 | 4,096 | 4,094 可用 | **自动批准** | +| /22 | 1,024 | 1,022 可用 | **自动批准** ✅ | +| /24 | 256 | 254 可用 | **需审批** ⚠️ | +| /26 | 64 | 62 可用 | **需审批** ⚠️ | +| /28 | 16 | 14 可用 | **需审批** ⚠️ | + +## Decision Logic + +``` +用户请求子网 + ↓ +IPAM 系统判断 CIDR 大小 + ↓ +┌─────────────────────────────────┐ +│ CIDR ≥ /22？ │ +│ ├─ 是 → 自动批准 │ +│ │ 调用 NIOS API │ +│ │ 分配下一可用块 │ +│ └─ 否 → 提交网络团队审批 │ +│ 用户提供申请理由 │ +│ 网络团队人工审核 │ +└─────────────────────────────────┘ +``` + +## Business Rationale + +1. **/22 及更大（自动批准）** + - IP 地址空间充足 + - 对整体地址空间影响小 + - 鼓励团队自主自动化 + +2. **/24 及更小（需审批）** + - IP 地址空间紧张 + - 需评估是否可合并到更大块 + - 防止地址空间碎片化 + +## Key Concepts + +- [[IPAM]]：执行审批逻辑的核心系统 +- [[Infoblox-NIOS]]：存储和管理 CIDR 分配记录 +- [[VPC-自动化供给]]：CIDR 审批是自动化供给的一部分 + +## Notes + +- 审批阈值（/22）由网络团队定义，可能因组织政策调整 +- 邮件通知机制覆盖用户和网络团队，全程可追溯 +- 参见 [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] 中的详细说明 + +## Aliases + +- CIDR Approval Workflow +- IP 地址审批流程 +- 子网大小审批规则 +- IPAM Approval Threshold diff --git a/wiki/concepts/Customer-Zero.md b/wiki/concepts/Customer-Zero.md new file mode 100644 index 00000000..88646224 --- /dev/null +++ b/wiki/concepts/Customer-Zero.md @@ -0,0 +1,78 @@ +--- +title: "Customer Zero Environment" +type: concept +tags: [Customer-Zero, DevOps, QA, Staging, Release-Management, Production-Readiness] +sources: + - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 +last_updated: 2026-04-29 +--- + +## Customer Zero Environment + +Customer Zero Environment（新版本的首位客户环境/内部验证环境）是指在新版本或产品正式发布给外部客户之前，在内部部署的预生产环境，用于在真实流量场景下验证功能正确性、性能和恢复能力。是 [[SRE]] Build 阶段的关键实践，也是 [[Recovery-Assurance]] 四位框架中"Build"环节的核心概念。 + +## Definition + +> "Customer Zero is the environment where your organization is the first customer of your own product — validating releases in production-like conditions before external rollout." + +Customer Zero 环境本质上是**内部影子客户**——用自己的产品，在受控环境中模拟真实使用场景，发现问题后再对外发布。 + +## Purpose + +| 目标 | 说明 | +|------|------| +| **新版本验证** | 在真实环境中测试新版本功能和性能 | +| **恢复路径验证** | 验证备份/恢复/故障转移流程在实际负载下是否有效 | +| **配置变更验证** | 测试配置变更（IaC 脚本、基础设施调整）对系统的影响 | +| **灾难演练** | 在隔离环境中主动触发故障，验证恢复 SLA | +| **性能基线建立** | 建立系统在正常负载下的性能基准 | + +## Customer Zero vs. Other Environments + +| 环境 | 目的 | 何时使用 | +|------|------|----------| +| **Dev** | 开发调试 | 开发人员日常编码 | +| **Test** | 功能测试 | QA 团队执行测试用例 | +| **Staging** | 预发布验证 | 接近生产的镜像测试 | +| **Customer Zero** | **内部影子客户验证** | **在真实生产配置下进行最终验证** | +| **Production** | 正式服务客户 | 正式上线 | + +## Key Characteristics + +1. **生产等效配置**：Customer Zero 使用与生产完全相同的基础设施配置（VPC、子网、安全组、IAM 角色） +2. **影子数据**：使用脱敏的生产数据副本（或合成数据），反映真实数据量和分布 +3. **隔离但连通**：通常与生产隔离，但可以使用生产的数据源（如 CloudWatch Logs）的脱敏版本 +4. **持续验证**：不仅是发布前的单次验证，而是 CI/CD 流水线中的持续验证关卡 + +## Connection to SRE + +在 [[SRE]] 的 Build 阶段，Customer Zero 环境是"Release Readiness"的核心： + +- **Go-Live Checklist 的一部分**：SRE 团队在支持新产品上线前，需要在 Customer Zero 验证监控覆盖、告警阈值和恢复流程 +- **Error Budget 验证**：在新版本发布后，通过 Customer Zero 监控错误趋势，确认 Error Budget 消耗符合预期 +- **Toil 发现**：Customer Zero 中发现的重复性问题，推动自动化改进，减少未来的 Toil + +## Connection to Recovery Assurance + +[[Recovery-Assurance]] 四位框架中的"Build"环节： + +``` +Design → Software → Build(Customer Zero) → Environments +``` + +- **Design**：定义可恢复性需求（[[RTO]]/[[RPO]]） +- **Software**：软件内嵌遥测，支持健康监控 +- **Build**：Customer Zero 环境验证恢复路径和 SLA +- **Environments**：SRE + [[Observability]] 支撑持续运营 + +## Related Concepts + +- [[SRE]] — Customer Zero 是 SRE Build 阶段的关键实践 +- [[Recovery-Assurance]] — Build 环节的验证环境 +- [[Observability]] — Customer Zero 中的恢复演练依赖可观测性数据 +- [[RTO]] / [[RPO]] — Customer Zero 验证 DR 目标是否满足 +- [[CI/CD]] — Customer Zero 是 CI/CD 流水线中的质量关卡 + +## Sources + +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/Disaster-Recovery.md b/wiki/concepts/Disaster-Recovery.md new file mode 100644 index 00000000..98cda576 --- /dev/null +++ b/wiki/concepts/Disaster-Recovery.md @@ -0,0 +1,85 @@ +--- +title: "Disaster Recovery" +type: concept +tags: [Disaster-Recovery, DR, Business-Continuity, RTO, RPO, High-Availability, Cloud-DevOps] +sources: + - ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup + - ctp-topic-44-aws-backup-in-micro-focus + - rto-vs-rpo-key-differences-for-modern-disaster-recovery + - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 +last_updated: 2026-04-29 +--- + +## Disaster Recovery（灾难恢复） + +灾难恢复（Disaster Recovery，DR）是指保护信息系统免受灾难性事件（地震、洪水、火灾、勒索软件、硬件故障、人为错误）影响的策略与实践体系，是 [[Business-Continuity-Plan]]（业务连续性计划）的 IT 技术层面核心组成部分。 + +## Core Metrics + +DR 的两大核心量化指标： + +| 指标 | 全称 | 含义 | 测量方向 | +|------|------|------|----------| +| **[[RTO]]** | Recovery Time Objective | 恢复时间目标：系统中断到恢复的最大可接受时长 | Forward（从故障向前） | +| **[[RPO]]** | Recovery Point Objective | 恢复点目标：可接受的最大数据丢失时间窗口 | Backward（从故障向后追溯） | + +## DR Strategies + +### Protection Scope + +| 策略 | 说明 | RTO | RPO | 成本 | +|------|------|-----|-----|------| +| **Backup Only** | 定期备份，无备用设施 | 数小时至数天 | 数小时至数天 | $ | +| **Pilot Light** | 核心服务常驻，冷备设施待机 | 数十分钟 | 分钟级 | $$ | +| **Warm Standby** | 部分服务热备，按需扩展 | 数分钟 | 秒级 | $$$ | +| **Multi-Region Active-Active** | 多区域同时运行 | ~0 | ~0 | $$$$ | + +### Cloud-Native DR on AWS + +- **[[AWS-Backup]]**：集中化管理 EC2、RDS、DynamoDB、S3 等服务的备份 +- **[[AWS-Backup-Audit-Manager]]**：自动化合规审计 +- **Cross-Region Replication**：S3 跨区域复制 EBS 卷快照 +- **AWS Elastic Disaster Recovery**：持续复制到 AWS，提供秒级 RPO + +## DR vs. High Availability + +| 维度 | 高可用（HA） | 灾难恢复（DR） | +|------|-------------|--------------| +| **目标故障** | 单组件故障（硬件、软件） | 区域性灾难（数据中心失效） | +| **覆盖范围** | 单站点内的冗余 | 跨地理位置的保护 | +| **触发方式** | 自动 failover | 人工决策触发 | +| **测试频率** | 持续运行（always-on） | 定期演练 | + +## DR Testing Challenges + +当前企业 DR 测试面临的普遍挑战（OpenText 案例）： + +- **被动性**：测试按客户时间表安排，非主动设计 +- **手动性**：大量人工协调，SME 全程参与 +- **不一致**：缺乏跨组织的统一 DR 方法论 +- **局限性**：超大规模云平台的测试主要覆盖区域故障，缺乏对账户级/服务级故障的验证 + +## DR to Recovery Assurance Evolution + +[[OpenText]] 提出的演进框架——从被动 DR 转向主动 [[Recovery-Assurance]]： + +1. **Design**：将可恢复性前置为架构设计原则 +2. **Software**：软件内嵌遥测，支持持续健康监控 +3. **Build**：Customer Zero 环境验证恢复路径 +4. **Environments**：SRE + 可观测性工程支撑弹性 + +## Related Concepts + +- [[RTO]] — 恢复时间目标，DR 核心指标 +- [[RPO]] — 恢复点目标，DR 核心指标 +- [[Business-Continuity-Plan]] — 业务连续性计划，DR 的上层框架 +- [[Recovery-Assurance]] — 灾难恢复的演进方向，从被动响应到主动保证 +- [[High-Availability]] — 高可用性，DR 的微观层面 +- [[AWS-Backup]] — AWS 云原生 DR 实现工具 + +## Sources + +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] +- [[ctp-topic-44-aws-backup-in-micro-focus]] +- [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]] +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/Gate-Process.md b/wiki/concepts/Gate-Process.md new file mode 100644 index 00000000..21b48d26 --- /dev/null +++ b/wiki/concepts/Gate-Process.md @@ -0,0 +1,63 @@ +--- +title: "Gate Process" +type: concept +tags: [CTP, Cloud, AWS, Governance] +sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] +last_updated: 2026-04-14 +--- + +## Definition + +网关审批流程（Gate Process）是用于治理云迁移项目进度的关键决策点框架。通过在关键里程碑设置"网关"（Gate）来确保项目在进入下一阶段前满足所有准入条件，从而控制风险并确保治理严谨性。 + +## Gate Stages in CTP + +### Gate 0 — 评估准入（Assessment Gate） + +- **目的**：确认需求是否符合云转型范围 +- **审查内容**：业务需求、技术可行性、资源可用性 +- **产出**：准入决策，是否进入详细规划阶段 + +### Gate 1 — 设计审批（Design Authority Gate） + +- **目的**：验证解决方案设计是否符合云原生原则 +- **审查内容**：架构设计、安全策略、合规性、 IaC 规划 +- **产出**：Design Authority 批准或驳回 +- **关键要求**：必须有经过审批的 [[Solution-Design]] + +### Gate 3 — 迁移准入（Migration Gate） + +- **目的**：确认产品已具备进入生产环境迁移的条件 +- **审查内容**：POC 成果、IaC 就绪状态、团队能力、安全评审结果 +- **产出**：最终迁移批准 + +## Gate Process vs 敏捷方法 + +| 维度 | Gate Process | 敏捷方法（Scrum/Kanban） | +|------|-------------|--------------------------| +| 决策模式 | 阶段性审批节点 | 持续反馈循环 | +| 变更控制 | Gate 之间冻结 | 随时调整优先级 | +| 适用场景 | 大范围迁移治理 | 迭代式产品开发 | +| 风险控制 | 强制审查点 | 快速失败快速调整 | +| 文档要求 | 高（各 Gate 交付物） | 低（Working Software） | + +## Relationship with Agile + +两者非逻辑矛盾，而是适用场景不同： + +- **Gate Process** 适用于需要严格治理的大范围企业迁移决策 +- **敏捷方法** 适用于持续迭代的产品开发和交付 + +CTP 实践中可将两者结合：使用敏捷方法管理迭代交付，使用 Gate Process 治理迁移准入决策。 + +## Related Concepts + +- [[Program-Demand-Process]]：Gate Process 是需求流程的核心治理机制 +- [[Proof-of-Concept]]：Gate 3 前必须完成 POC 并验证成功标准 +- [[Solution-Design]]：Gate 1 的核心审批交付物 +- [[Design-Authority]]：Gate 1 审批的执行主体 +- [[Agile]]：与 Gate Process 形成互补的迭代管理方法 + +## References + +- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] diff --git a/wiki/concepts/Hub-and-Spoke.md b/wiki/concepts/Hub-and-Spoke.md new file mode 100644 index 00000000..69e09251 --- /dev/null +++ b/wiki/concepts/Hub-and-Spoke.md @@ -0,0 +1,52 @@ +--- +title: "Hub-and-Spoke Network Topology" +type: concept +tags: [AWS, Networking, Topology, Transit Gateway] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## Hub-and-Spoke + +Hub-and-Spoke 是一种星型网络拓扑结构，其中所有分支（Spoke）连接到中心节点（Hub），分支间的通信通常经过 Hub 中转。 + +## Definition + +- **Hub（中心节点）**: 负责汇聚所有 Spoke 的流量，执行路由决策和安全策略 +- **Spoke（分支节点）**: 各自独立的 VPC 或 Landing Zone，通过 Hub 接入全局网络 +- **通信模式**: Spoke-to-Spoke 通信必须经过 Hub 转发，而非直接互联 + +## In AWS Transit Gateway Architecture + +在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 描述的架构中： + +- **Hub**: 每个地理区域（APJ、EMEA、AMS）的区域级 Transit Gateway（如 EMEA 的伦敦 Hub、AMS 的俄勒冈 Hub） +- **Spoke**: 各个 Landing Zones，通过 TGW Peering 接入区域 Hub +- **Inter-Hub**: 区域 Hub 之间通过 Full Mesh（全网状）连接，确保全球流量的可达性 + +## Key Properties + +| 属性 | 值 | +|------|-----| +| 架构类型 | 星型拓扑 | +| 扩展性 | 高——新增 Spoke 仅需连接到 Hub | +| 复杂度 | 低——集中管理路由策略 | +| 缺点 | Hub 可能成为瓶颈或单点故障 | +| 适用场景 | 多账号 VPC 互联、全球 Landing Zone 网络 | + +## Relationship to Transit Gateway + +AWS Transit Gateway 是实现 Hub-and-Spoke 架构的核心服务： +- [[AWS-Transit-Gateway-TGW]] 提供区域级 Hub 功能 +- [[TGW-Peering]] 用于 Hub 之间的跨区域互联 +- [[Hub-and-Spoke]] 与 Full Mesh 组合使用（Spoke-to-Hub = Hub-and-Spoke, Hub-to-Hub = Full Mesh） + +## Connections + +- [[AWS-Transit-Gateway-TGW]] ← 实现 ← [[Hub-and-Spoke]] +- [[TGW-Peering]] ← 跨 Hub 连接 ← [[Hub-and-Spoke]] +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 案例 ← [[Hub-and-Spoke]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/concepts/IPAM.md b/wiki/concepts/IPAM.md new file mode 100644 index 00000000..b48f68ce --- /dev/null +++ b/wiki/concepts/IPAM.md @@ -0,0 +1,66 @@ +--- +title: "IPAM" +type: concept +tags: [Networking, AWS, Automation, IP-Address-Management] +sources: + - ctp-topic-45-automatic-ip-address-allocation-with-ipam + - ctp-topic-61-workload-vpc-provision-with-ipam-automation + - ctp-topic-22-global-dns-service-offerings +last_updated: 2026-04-24 +--- + +## IPAM（IP Address Management） + +企业级 IP 地址管理平台，核心功能包括：**有效管理**、**控制**、**监控**和**分配**企业内部的 IP 地址空间。IPAM 通过集中化和自动化手段，替代传统的手工 Excel 管理模式。 + +## Problem Statement + +传统 IP 地址管理依赖 Excel 电子表格： +- **效率低**：每次 VPC 供给需与网络团队多次交接 +- **易出错**：手工规划易产生 IP 地址重叠冲突 +- **不可追溯**：缺乏统一的变更历史记录 +- **无法自动化**：IP 地址分配无法与 IaC 流水线集成 + +## Core Capabilities + +1. **集中化管理**：单一可信数据源管理所有 IP 地址分配 +2. **自动化供给**：通过 API 与 IaC 工具集成，自动分配下一可用 IP 地址块 +3. **生命周期管理**：VPC 销毁时自动回收 IP 地址 +4. **审批工作流**：基于 CIDR 大小的差异化审批规则 +5. **可扩展属性**：存储元数据（owner、company、subnet_name、status 等） + +## Implementation: Infoblox NIOS + +本 Wiki 中 IPAM 的核心实现为 **Infoblox NIOS**： + +- **Grid 架构**：分布式网格架构，包含主数据库和冗余 DNS/NTP/DHCP 服务 +- **API 驱动**：通过 API 调用自动分配 IP 地址 +- **与 AWS 集成**：作为 VPC 自动化供给流程的 IP 地址来源 + +## Key Concepts + +- [[Infoblox-NIOS]]：核心网络控制平面 +- [[Infoblox-Grid]]：分布式网格架构 +- [[CIDR-审批流程]]：基于 CIDR 大小的审批规则 +- [[VPC-自动化供给]]：IPAM 驱动的声明式 VPC 创建 + +## Key Entities + +- [[Pushka]]（Principal SRE）：IPAM 自动化方案的发起人 +- [[Infoblox]]：IPAM 供应商 +- [[AWS-Landing-Zone]]：IPAM 实施的背景环境 + +## Connections + +- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← mechanism ← **IPAM** + - 介绍 IPAM 的核心机制和 YAML 驱动方式 +- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← application ← **IPAM** + - 展示 IPAM 在 Workload VPC 供给中的完整应用 +- [[ctp-topic-22-global-dns-service-offerings]] ← shares_infra ← **IPAM** + - Infoblox 同时支撑 DNS Anycast 和 IPAM + +## Aliases + +- IP Address Management +- IP Address Management System +- IPAM 系统 diff --git a/wiki/concepts/Infoblox-Grid.md b/wiki/concepts/Infoblox-Grid.md new file mode 100644 index 00000000..05cbf6da --- /dev/null +++ b/wiki/concepts/Infoblox-Grid.md @@ -0,0 +1,64 @@ +--- +title: "Infoblox-Grid" +type: concept +tags: [Networking, DNS, DHCP, IPAM, Infoblox, High-Availability] +sources: + - ctp-topic-45-automatic-ip-address-allocation-with-ipam + - ctp-topic-61-workload-vpc-provision-with-ipam-automation + - ctp-topic-22-global-dns-service-offerings +last_updated: 2026-04-24 +--- + +## Infoblox Grid + +Infoblox 的分布式网格架构，是企业级 DNS、DHCP 和 IPAM（IPAM）服务的高可用基础设施。Grid 架构将多个 Infoblox 设备组织成一个逻辑单元，提供统一的控制平面和冗余保护。 + +## Architecture Components + +### Grid Master +- **角色**：整个 Grid 的主控节点 +- **职责**：管理成员节点、配置文件分发、IP 地址分配决策 +- **位置**：本组织中位于休斯顿数据中心 + +### Grid Members +- **角色**：分布在多个地理位置的工作节点 +- **职责**：承载 DNS、DHCP、IPAM 服务 +- **冗余**：多成员部署提供故障转移能力 + +### Supporting Services +- **DNS**：Anycast 支持全球低延迟 +- **NTP**：时间同步服务 +- **DHCP**：IP 地址动态分配 + +## Grid Communication + +- 成员之间通过 Grid 协议通信 +- 配置变更通过主节点统一分发 +- IP 地址分配决策由主节点协调 + +## vs. Single Node + +| 特性 | 单节点 | Grid 架构 | +|------|--------|-----------| +| 高可用 | ❌ | ✅ 故障自动转移 | +| 地理分布 | ❌ | ✅ 全球多站点 | +| 集中管理 | ✅ | ✅ 更强 | +| 扩展性 | 有限 | ✅ 线性扩展 | + +## Key Concepts + +- [[Infoblox-NIOS]]：Grid 成员上运行的操作系统 +- [[IPAM]]：Grid 的核心功能之一 +- [[DNS-Anycast]]：Grid DNS 服务的高级特性 + +## Connections + +- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← Infoblox Grid 作为 IPAM 后端 +- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← Grid 防止 IP 地址重叠 +- [[ctp-topic-22-global-dns-service-offerings]] ← Grid 支撑 DNS Anycast 服务 + +## Aliases + +- Infoblox Grid Architecture +- NIOS Grid +- Infoblox Cluster diff --git a/wiki/concepts/Infoblox-NIOS.md b/wiki/concepts/Infoblox-NIOS.md new file mode 100644 index 00000000..8fd50e22 --- /dev/null +++ b/wiki/concepts/Infoblox-NIOS.md @@ -0,0 +1,71 @@ +--- +title: "Infoblox-NIOS" +type: concept +tags: [Networking, DNS, DHCP, IPAM, Infoblox] +sources: + - ctp-topic-45-automatic-ip-address-allocation-with-ipam + - ctp-topic-61-workload-vpc-provision-with-ipam-automation + - ctp-topic-22-global-dns-service-offerings +last_updated: 2026-04-24 +--- + +## Infoblox NIOS + +Infoblox 的核心网络控制平面操作系统，提供 **DNS**、**DHCP** 和 **IP 地址管理（IPAM）** 三大核心功能。作为企业级网络基础设施，NIOS 是 Cloud Transformation Programme 中 IPAM 自动化方案的技术核心。 + +## Core Functions + +### 1. DNS（域名系统） +- 权威 DNS 服务器 +- DNS Anycast 支持全球低延迟解析 +- 与 Microsoft Active Directory 深度集成 + +### 2. DHCP（动态主机配置协议） +- 自动化 IP 地址分配 +- IP 租约管理 +- 与 DNS 动态更新集成 + +### 3. IPAM（IP 地址管理） +- 集中化 IP 地址池管理 +- 可扩展属性（Extensible Attributes）存储元数据 +- API 驱动的自动化分配 +- 与 IaC 工具（Terraform/Terragrunt）集成 + +## Extensible Attributes + +NIOS 支持自定义可扩展属性，用于存储业务元数据： + +| 属性名 | 用途 | +|--------|------| +| space_owner | IP 地址空间负责人 | +| company | 所属公司/业务单元 | +| subnet_name | 子网名称 | +| compartment_type | 隔间类型 | +| status | 分配状态（allocated/reserved/available） | +| business_contact | 业务联系人 | +| engineering_contact | 工程联系人 | + +## Architecture + +- **Grid Master**：主控节点，位于休斯顿数据中心 +- **冗余服务**：DNS、NTP、DHCP 多活冗余 +- **API 接口**：RESTful API 支持自动化集成 +- **与 AWS 集成**：通过 VPC 供给流水线调用 NIOS API 分配 IP 地址 + +## Key Concepts + +- [[IPAM]]：NIOS 的核心功能之一 +- [[Infoblox-Grid]]：NIOS 的分布式网格架构 +- [[DNS-Anycast]]：NIOS 的 DNS 高可用机制 + +## Connections + +- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← NIOS 作为 IPAM 引擎 +- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← NIOS 驱动 VPC 供给 +- [[ctp-topic-22-global-dns-service-offerings]] ← NIOS 提供 DNS Anycast + +## Aliases + +- NIOS +- InfoBlocks NIOS +- Infoblox Network Operating System diff --git a/wiki/concepts/Inline-Layer.md b/wiki/concepts/Inline-Layer.md new file mode 100644 index 00000000..4706c5ce --- /dev/null +++ b/wiki/concepts/Inline-Layer.md @@ -0,0 +1,38 @@ +--- +title: "Inline Layer (Firewall Policy)" +type: concept +tags: ["AWS", "Firewall", "Checkpoint", "Network-Security", "Policy"] +sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] +last_updated: 2026-04-28 +--- + +## Definition +Inline Layer 是 Checkpoint Firewall 中防火墙策略的另一种组织结构——采用基于账号编号的父子规则架构。一个父规则下嵌套多个子规则，子规则按账号维度进行流量控制。与 Ordered Layer（顺序多层检查）不同，Inline Layer 通过账号维度进行规则分组和继承。 + +## Mechanism +在 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中，Pradeep 演示了 Inline Layer 的应用场景： + +- **账号维度分组**：将同一账号或 OU 内的规则聚合为一个 Inline Layer 块 +- **父子规则结构**：父规则定义范围（哪个账号），子规则定义具体允许/拒绝的流量 +- **自动化友好**：新账号上线时，只需在父规则下添加子规则，无需修改核心策略结构 +- **简化规则管理**：规则数量随账号数线性增长，而非 N^2 增长 + +## Ordered Layer vs Inline Layer + +| 维度 | Ordered Layer | Inline Layer | +|------|-------------|-------------| +| 组织维度 | 多层（地理→类型→BU→产品→环境→角色） | 账号编号维度 | +| 检查逻辑 | 顺序通过全部层 | 在父规则下匹配子规则 | +| 适用场景 | 精细化多层安全控制 | 跨账号规则聚合与自动化 | +| 管理复杂度 | 中（维度多但粒度细） | 低（账号分组简化管理） | + +## Combined Usage +Checkpoint 在 Landing Zone 中通常组合使用两种 Layer： +- **Ordered Layers**：处理安全控制层（地理封锁、BU 隔离等） +- **Inline Layers**：处理账号维度的规则管理，支持自动化和扩展 + +## Connections +- [[Checkpoint-Firewall]] — Inline Layer 是 Checkpoint 策略集的核心组织方式 +- [[Ordered-Layer]] — Checkpoint 策略的两种组织模式：Ordered Layer（顺序检查）vs Inline Layer（账号维度） +- [[AWS-Landing-Zone]] — 在 LZ 网络隔离架构中实施 +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] diff --git a/wiki/concepts/Network-Segmentation.md b/wiki/concepts/Network-Segmentation.md index ae5e991b..e8fc0ff2 100644 --- a/wiki/concepts/Network-Segmentation.md +++ b/wiki/concepts/Network-Segmentation.md @@ -21,3 +21,4 @@ last_updated: 2026-05-06 ## Related Sources - [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] - [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] +- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] diff --git a/wiki/concepts/Observability.md b/wiki/concepts/Observability.md index 0b6dbadc..e5d4b8a9 100644 --- a/wiki/concepts/Observability.md +++ b/wiki/concepts/Observability.md @@ -1,47 +1,72 @@ ---- -title: "Observability" -type: concept -tags: [devops, monitoring, sre, infrastructure] -last_updated: 2026-04-26 ---- - -## Observability（可观测性） - -**中文名称：** 可观测性 - -**类型：** 技术方法论 / SRE 核心支柱 - -**别名：** -- 可观测性 -- 云原生可观测性 -- Observability Stack - ---- - -## Definition - -可观测性（Observability）是指通过系统外部输出来推断其内部状态的能力。在 IT 运维领域，通常由三大支柱构成： - -1. **指标（Metrics）：** 系统运行时数值数据的时序聚合——如 CPU 使用率、内存占用、请求 QPS。代表工具：Prometheus、InfluxDB、VictoriaMetrics。 -2. **日志（Logs）：** 系统运行事件的离散记录——如错误日志、访问日志、业务事件。代表工具：ELK（Elasticsearch + Logstash + Kibana）、Loki、Graylog。 -3. **链路（Traces）：** 分布式请求在多个服务间的调用路径追踪——如 HTTP 请求从 API → DB → Cache 的完整耗时。代表工具：Jaeger、Zipkin、OpenTelemetry。 - -**第三支柱趋势：** OpenTelemetry（OTel）作为 CNCF 项目，正在成为可观测数据的统一采集标准，将 Traces、Metrics、Logs 三者以统一规范融合。 - ---- - -## 家庭监控场景下的应用 - -在家庭服务器/NAS 监控中，可观测性通过以下组件实现： -- **指标：** Prometheus + node_exporter + cAdvisor + blackbox_exporter -- **可视化：** Grafana 仪表盘 -- **告警：** Alertmanager + 邮件/Slack 通知 -- **日志（可选）：** Loki + Promtail - ---- - -## Related Sources -- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] -- [[public-cloud-learning-sessions-observability-with-opentelemetry]] -- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] -- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] +--- +title: "Observability" +type: concept +tags: [Observability, SRE, Cloud-Native, Telemetry, Monitoring, Reliability] +sources: + - public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113 + - ctp-topic-67-cloud-native-observability-using-opentelemetry + - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 +last_updated: 2026-04-29 +--- + +## Observability（可观测性） + +可观测性（Observability）是指系统通过其外部输出理解其内部状态的能力。在软件工程中，可观测性通过遥测数据（Telemetry）——指标（Metrics）、日志（Logs）、追踪（Traces）——持续理解系统健康状态，是 [[SRE]] 和 [[Recovery-Assurance]] 的核心技术基础。 + +## Three Pillars + +可观测性三大支柱（Three Pillars of Observability）： + +| 支柱 | 说明 | 示例 | +|------|------|------| +| **Metrics（指标）** | 聚合的数值数据，反映系统状态趋势 | CPU 使用率、请求延迟、错误率 | +| **Logs（日志）** | 离散的事件记录，按时间顺序记录系统活动 | 访问日志、错误日志、审计日志 | +| **Traces（追踪）** | 跨服务和组件的请求传播路径 | 分布式链路追踪、调用链可视化 | + +## Observability vs. Monitoring + +传统监控（Monitoring）与可观测性（Observability）的核心区别： + +| 维度 | 传统监控（Monitoring） | 可观测性（Observability） | +|------|---------------------|-------------------------| +| **目标** | 回答预设问题 | 回答任意未知问题 | +| **假设** | 故障模式已知 | 故障模式未知（High Cardinality） | +| **数据** | 聚合指标，低基数 | 原始事件，高基数 | +| **根因定位** | 依赖仪表板预设视图 | 通过遥测数据探索定位 | +| **适用场景** | 稳定系统 | 云原生、分布式系统 | + +> "You can't monitor your way to understanding a distributed system. You need observability." — Charity Majors + +## Observability Engineering + +可观测性工程（Observability Engineering）是将可观测性作为架构设计原则，在软件开发生命周期中内嵌遥测数据收集： + +- **Left-Shift**：在开发阶段就定义 SLI/SLO，持续验证 +- **Telemetry as Code**：将遥测配置纳入 IaC，实现版本化管理 +- **Continuous Validation**：用主动探测（Synthetic Monitoring）验证恢复路径 + +## Connection to SRE and Recovery Assurance + +在 [[SRE]] 实践中，可观测性是实现可靠性目标的必要条件： + +- **SLI/SLO/SLA 的测量基础**：可观测性提供量化可靠性的原始数据 +- **Error Budget 的支撑**：通过指标追踪 Error Budget 消耗速度 +- **On-Call 响应的依据**：日志和追踪是 MTTR（Mean Time To Recovery）的核心数据源 +- **[[Recovery-Assurance]] 的前提**：无法观测的系统无法保证恢复能力 + +## OpenTelemetry + +[[OpenTelemetry]]（OTel）是 CNCF 的开源可观测性框架，提供厂商中立的指标、日志、追踪统一采集标准。 + +## Related Concepts + +- [[SRE]] — 可观测性是 SRE 四大黄金信号的基础 +- [[Recovery-Assurance]] — 可观测性是 Recovery Assurance 的技术前提 +- [[OpenTelemetry]] — 可观测性工程的具体实现框架 +- [[RTO]] / [[RPO]] — 可观测性支撑 RTO/RPO 的持续监控 + +## Sources + +- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]] +- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/Ordered-Layer.md b/wiki/concepts/Ordered-Layer.md new file mode 100644 index 00000000..d7c7848c --- /dev/null +++ b/wiki/concepts/Ordered-Layer.md @@ -0,0 +1,41 @@ +--- +title: "Ordered Layer (Firewall Policy)" +type: concept +tags: ["AWS", "Firewall", "Checkpoint", "Network-Security", "Policy"] +sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] +last_updated: 2026-04-28 +--- + +## Definition +Ordered Layer 是 Checkpoint Firewall 中防火墙策略的组织结构——策略按优先级顺序排列的多层检查机制。流量必须逐层通过检查，全部通过后方可放行。与之对应的是 Inline Layer（基于账号编号的父子规则结构）。 + +## Mechanism +在 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中，Pradeep 演示了 Checkpoint 在 Frankfurt Landing Zone 的 Ordered Layers： + +1. **地理封锁（Geo-blocking）**：按来源/目标地理位置阻断流量 +2. **类型检查（Type）**：基于资源的 `Type` 标签进行访问控制 +3. **业务单元隔离（BU）**：基于 `BU`/`BusinessUnit` 标签隔离不同业务单元间的通信 +4. **产品隔离（Product）**：基于 `Product` 标签隔离不同产品间的通信 +5. **环境隔离（Environment）**：基于 `Environment` 标签隔离不同环境（生产/非生产） +6. **服务器角色（Server Role）**：基于 `ServerRole` 标签进行细粒度角色级控制 + +**核心特性**： +- 顺序执行：流量必须通过每一层检查，任一层拒绝则整体拒绝 +- 默认阻断跨产品线通信（Inter-product is not allowed） +- 策略以标签为依据，替代传统的 IP 地址规则 + +## Comparison with Traditional Firewall Rules + +| 维度 | 传统 IP-Based 规则 | Ordered Layer + 标签驱动 | +|------|-------------------|------------------------| +| 规则维护 | IP 变更需手动更新 | 标签自动关联，无需更新规则 | +| 动态性 | 静态，难以适应云 | 动态，随资源标签变化 | +| 扩展性 | 随账号/服务增长爆炸 | 通过 OU + 标签层级管控 | +| 管理复杂度 | 高（N^2 规则） | 低（层级 + 标签维度） | + +## Connections +- [[Checkpoint-Firewall]] — Ordered Layer 是 Checkpoint 策略集的核心组织方式 +- [[Inline-Layer]] — Checkpoint 策略的两种组织模式：Ordered Layer（顺序检查）vs Inline Layer（账号维度） +- [[AWS-Landing-Zone]] — 在 LZ 网络隔离架构中实施 +- [[Resource-Tagging]] — Ordered Layer 依赖标签体系驱动策略执行 +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] diff --git a/wiki/concepts/Overlay-Network.md b/wiki/concepts/Overlay-Network.md new file mode 100644 index 00000000..ecb868bf --- /dev/null +++ b/wiki/concepts/Overlay-Network.md @@ -0,0 +1,49 @@ +--- +title: "Overlay Network" +type: concept +tags: [AWS, Networking, Virtualization, SD-WAN] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## Overlay Network + +叠加网络（Overlay Network）是在现有物理网络（Underlay）之上构建的逻辑网络，通过隧道技术（Tunneling）实现复杂的路由、安全和流量工程功能，与底层物理基础设施解耦。 + +## Definition + +- **Underlay（底层网络）**: 物理基础设施——路由器、交换机、光纤链路（如 AWS 区域间的物理连接） +- **Overlay（叠加网络）**: 逻辑隧道网络——在 Underlay 之上构建的虚拟网络层，通过封装（Encapsulation）实现端到端连接 +- **解耦价值**: Overlay 的路径选择、策略控制与 Underlay 的物理拓扑相互独立 + +## Key Mechanisms + +- **隧道协议**: GRE、VXLAN、IPSec、WireGuard 等 +- **封装**: 将原始数据包封装在新的 IP 包头中，通过 Underlay 传输 +- **网络虚拟化**: VPC 即为 AWS 原生的 Overlay Network 实现 + +## In AWS Transit Gateway + SD-WAN Architecture + +在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中描述的架构： + +- **Underlay**: AWS 区域间的物理网络连接（APJ/EMEA/AMS 区域 Hub 之间的 Full Mesh） +- **Overlay**: Silver Peak SD-WAN 在 AWS 中部署的虚拟 SD-WAN 设备构成的逻辑网络 +- **价值**: SD-WAN Overlay 实现动态路径选择，即使 Underlay 静态路由失效也能自动切换 + +## Relationship to Related Concepts + +| 概念 | 关系 | +|------|------| +| [[AWS-Transit-Gateway-TGW]] | AWS 原生 Overlay 服务（区域级） | +| [[SD-WAN]] | Overlay 的一种实现形式 | +| [[Hub-and-Spoke]] | Overlay 网络的拓扑结构模式 | + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 场景 ← [[Overlay-Network]] +- [[SD-WAN]] ← 实现方式 ← [[Overlay-Network]] +- [[AWS-Transit-Gateway-TGW]] ← AWS 原生 ← [[Overlay-Network]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/concepts/Prisma-Access.md b/wiki/concepts/Prisma-Access.md new file mode 100644 index 00000000..45284fbc --- /dev/null +++ b/wiki/concepts/Prisma-Access.md @@ -0,0 +1,57 @@ +--- +title: "Prisma Access" +type: concept +tags: [AWS, Security, SASE, VPN, Networking] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## Prisma Access + +Prisma Access 是 [[PaloAltoNetworks]] 提供的基于云的安全访问服务（SASE, Secure Access Service Edge），用于替代传统 VPN，提供更安全的统一访问体验。 + +## Definition + +- **类型**: SASE（Secure Access Service Edge）云安全服务 +- **供应商**: [[PaloAltoNetworks]] +- **核心功能**: 将网络安全功能（SWG、CASB、ZTNA、Firewall-as-a-Service）与网络连接功能（SD-WAN）整合为单一云原生服务 +- **替代方案**: 传统 VPN（Pulse Secure VPN 等） + +## Key Capabilities + +- **就近接入**: 在全球部署大量接入网关（PoP, Point of Presence），用户自动路由至最近节点 +- **统一安全策略**: 所有流量统一执行安全检查，无需逐设备配置 +- **ZTNA（Zero Trust Network Access）**: 基于身份和设备状态而非网络位置授权访问 +- **与 SD-WAN 整合**: 可直接打通 SD-WAN 骨干网，实现云端与分支机构的统一连接 + +## In CTP Architecture + +在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中的规划： + +- **现状**: 使用 [[Pulse-VPN]] 提供远程访问（传统 VPN 架构） +- **目标**: 迁移至 Prisma Access，实现： + 1. 全球更多接入网关，用户就近接入 + 2. 显著降低访问延迟 + 3. 直接打通 SD-WAN 骨干网 + 4. 统一安全策略管理 + +## Comparison: Traditional VPN vs Prisma Access + +| 维度 | Pulse VPN（传统） | Prisma Access（SASE） | +|------|-----------------|----------------------| +| 接入方式 | VPN 隧道，IP 路由 | 就近接入，身份驱动 | +| 延迟 | 单一 VPN 入口，高延迟 | 全球 PoP，低延迟 | +| 安全策略 | 基于网络位置 | 基于身份和设备状态 | +| 扩展性 | 差 | 好（云原生） | +| SD-WAN 整合 | 无 | 原生整合 | + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 远程访问方案 ← [[Prisma-Access]] +- [[PaloAltoNetworks]] ← 提供商 ← [[Prisma-Access]] +- [[SD-WAN]] ← 整合 ← [[Prisma-Access]] +- [[Pulse-VPN]] ← 替代 ← [[Prisma-Access]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/concepts/Private-Hosted-Zone.md b/wiki/concepts/Private-Hosted-Zone.md new file mode 100644 index 00000000..e9c1b1be --- /dev/null +++ b/wiki/concepts/Private-Hosted-Zone.md @@ -0,0 +1,35 @@ +--- +title: "Private Hosted Zone" +type: concept +tags: + - AWS + - DNS + - Networking +last_updated: 2026-04-28 +--- + +## Definition + +Private Hosted Zone（PHZ，私有托管区）是 Amazon Route 53 的一项功能，允许在指定的 Amazon VPC 内部解析自定义私有域名（如 `int-sas.local`、`corp.internal`）。与公有托管区不同，PHZ 的DNS记录不对互联网开放，仅在关联的 VPC 内可见。 + +## Aliases +- Private Hosted Zone +- PHZ +- AWS 私有托管区 + +## Key Characteristics + +- **VPC 范围隔离**：DNS 记录仅在关联的 VPC 内可解析，保证内部域名不暴露 +- **跨账号关联**：VPC 可与另一个 AWS 账户拥有的 PHZ 关联，但必须先完成"授权（Authorization）"再执行"关联（Association）" +- **Resolver 自动优先**：当查询匹配 PHZ 中的域名时，Route 53 Resolver 直接返回 PHZ 记录，不再转发至转发规则 +- **多 VPC 支持**：一个 PHZ 可关联多个 VPC，支持跨区域（但建议同区域以减少延迟） +- **集中化 vs 分散化**：在 Landing Zone 架构中，推荐集中式 DNS 账号管理 PHZ，而非在每个业务账号中分散创建 + +## Related Concepts +- [[Route-53-Resolver]] — PHZ 依赖 Resolver 进行解析 +- [[Resolver-Rules]] — 未匹配 PHZ 的查询由 Resolver Rules 转发 +- [[VPC-Association-Authorization]] — 跨账号 PHZ 关联流程 +- [[AWS-Landing-Zone]] — 多账号环境下的 PHZ 管理策略 + +## Sources +- [[ctp-topic-19-configuring-dns-within-aws-lzs]] diff --git a/wiki/concepts/Program-Demand-Process.md b/wiki/concepts/Program-Demand-Process.md new file mode 100644 index 00000000..908e60ff --- /dev/null +++ b/wiki/concepts/Program-Demand-Process.md @@ -0,0 +1,46 @@ +--- +title: "Program Demand Process" +type: concept +tags: [CTP, Cloud, AWS, Demand-Management] +sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding, ctp-topic-57-product-backlog-managing-demand] +last_updated: 2026-04-14 +--- + +## Definition + +程序需求流程（Program Demand Process）指从业务需求产生、优先级排序到最终交付云迁移的端到端管理路径。是 Cloud Transformation Programme（CTP）治理框架的核心入口。 + +## Demand Sources + +需求驱动来源可分为三类： + +- **业务案例驱动**：如数据中心关闭、业务连续性需求、基础设施老化等业务压力 +- **战略优先级驱动**：高层管理人员（如 Matt）定义的企业战略优先级，自上而下传导 +- **产品路线图驱动**：产品团队的技术演进需求与路线图规划 + +## Process Stages + +1. **需求录入**：业务端提交转型需求 +2. **优先级排序**：基于业务价值和紧迫性排列需求优先级 +3. **POC 决策**：评估是否需要进行概念验证 +4. **Gate 审批**：通过 Gate 0/1/3 等关键决策点 +5. **迁移执行**：迁移至 Labs 或 SaaS 生产环境 +6. **验收与关闭**：确认迁移达成预期目标 + +## Key Gate Points + +- **Gate 0**：评估准入，确认需求符合云转型范围 +- **Gate 1**：Design Authority 审批，验证解决方案设计 +- **Gate 3**：迁移准入，最终批准启动生产迁移 + +## Related Concepts + +- [[Proof-of-Concept]]：在需求流程中降低迁移风险的关键验证手段 +- [[Gate-Process]]：治理需求流程的关键决策框架 +- [[Solution-Design]]：Gate 1 审批的核心交付物 +- [[Product-Backlog]]：需求管理的优先级排序机制 + +## References + +- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] +- [[ctp-topic-57-product-backlog-managing-demand]] diff --git a/wiki/concepts/Proof-of-Concept.md b/wiki/concepts/Proof-of-Concept.md new file mode 100644 index 00000000..b03036a8 --- /dev/null +++ b/wiki/concepts/Proof-of-Concept.md @@ -0,0 +1,59 @@ +--- +title: "Proof of Concept" +type: concept +tags: [CTP, Cloud, AWS, POC] +sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] +last_updated: 2026-04-14 +--- + +## Definition + +概念验证（Proof of Concept, POC）是在正式云迁移前用于证明架构可行性、测试复杂网络需求及验证迁移方法的实验性阶段。是降低云迁移风险的核心手段。 + +## POC Objectives + +- **架构可行性验证**：确认目标云架构能够满足业务需求 +- **技术可行性测试**：验证复杂网络配置、依赖关系和集成点 +- **团队能力建设**：让团队熟悉基于 Gruntwork 的新一代 Landing Zone 环境 +- **风险识别**：在正式迁移前发现并解决潜在问题 +- **迁移方法验证**：验证数据迁移和应用迁移的具体方法 + +## POC vs 传统"经典落地分区" + +| 维度 | 传统方式 | 新一代 Landing Zone + POC | +|------|----------|---------------------------| +| 构建方式 | 手动构建 | IaC（Terraform/Terragrunt）自动化 | +| 可重复性 | 低 | 高（通过代码复用） | +| 环境一致性 | 难以保证 | 严格一致 | +| 文档化 | 分散 | 集中于 IaC 代码 | +| 审计追踪 | 困难 | Git 版本控制 | + +## POC Deliverables + +POC 阶段必须产出的关键交付物： + +- **解决方案设计文档**：经过 Design Authority 审批的架构设计 +- **IaC 脚本**：可用于正式部署的 Terraform/Terragrunt 配置 +- **迁移时间表**：明确的里程碑和交付日期 +- **成功标准验证报告**：证明产品已具备进入生产环境迁移的条件 + +## Success Criteria + +POC 成功标准必须在启动前明确定义，包括： + +- 技术可行性指标（架构满足需求） +- 性能指标（满足 NFR 定义的非功能性需求） +- 安全合规指标（通过安全评审） +- 团队能力指标（团队能够独立运维新环境） + +## Related Concepts + +- [[Program-Demand-Process]]：POC 是需求流程的关键验证环节 +- [[Gate-Process]]：POC 阶段受 Gate 1 Design Authority 审批约束 +- [[Solution-Design]]：POC 的核心产出物，需审批后方可进入迁移 +- [[Landing-Zone-Architecture]]：POC 部署的目标环境基础 +- [[Infrastructure-as-Code]]：新一代 Landing Zone 的核心技术手段 + +## References + +- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] diff --git a/wiki/concepts/RPO.md b/wiki/concepts/RPO.md index 238193ad..e6afcfa4 100644 --- a/wiki/concepts/RPO.md +++ b/wiki/concepts/RPO.md @@ -1,7 +1,7 @@ --- title: "RPO (Recovery Point Objective)" tags: [devops, disaster-recovery, sre, reliability, data-protection] -last_updated: 2026-04-28 +last_updated: 2026-04-29 --- # RPO (Recovery Point Objective) @@ -85,7 +85,9 @@ RTO 和 RPO 衡量的是不同维度，必须**同时优化**： - [[Kill Switch]] — 关闭故障功能，保护数据不被继续破坏 - [[High Availability]] — 高可用性，降低 RPO 的基础设施 - [[Data-Governance]] — 数据治理，包含 RPO 策略 - ## Sources -- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] -- [[sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] + +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] +- [[ctp-topic-44-aws-backup-in-micro-focus]] +- [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]] +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] \ No newline at end of file diff --git a/wiki/concepts/RTO.md b/wiki/concepts/RTO.md index 32c53680..6e8244b8 100644 --- a/wiki/concepts/RTO.md +++ b/wiki/concepts/RTO.md @@ -8,7 +8,8 @@ tags: - Cloud Architecture sources: - ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora -last_updated: 2026-04-28 + - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 +last_updated: 2026-04-29 --- ## Overview diff --git a/wiki/concepts/Recovery-Assurance.md b/wiki/concepts/Recovery-Assurance.md new file mode 100644 index 00000000..983eacfe --- /dev/null +++ b/wiki/concepts/Recovery-Assurance.md @@ -0,0 +1,95 @@ +--- +title: "Recovery Assurance" +type: concept +tags: [Recovery-Assurance, SRE, Disaster-Recovery, Observability, Automation, Cloud-DevOps, Resilience] +sources: + - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 +last_updated: 2026-04-29 +--- + +## Recovery Assurance（恢复保证） + +恢复保证（Recovery Assurance）是灾难恢复（[[Disaster-Recovery]]）理念的演进方向——从被动应对灾难，到主动设计、持续验证、自动化保证系统的恢复能力。是 [[OpenText]] 在 2024 年提出的 DR 演进框架核心理念。 + +## Definition + +> "Recovery Assurance = 可恢复性作为架构设计原则 + 可观测性作为持续监控手段 + 自动化作为规模化保障" + +传统 DR 关注的是"灾难发生后如何恢复"，而 Recovery Assurance 关注的是"如何保证系统在任何故障下都能可靠恢复"——从反应式（Reactive）转向主动式（Proactive）。 + +## The Four-Pillar Framework + +[[OpenText]] 提出的四位框架，将 Recovery Assurance 落地到架构的四个层面： + +``` +┌─────────────────────────────────────────────────────┐ +│ 1. DESIGN（设计） │ +│ → 可恢复性作为架构设计原则 │ +│ → 在设计阶段就定义恢复机制 │ +│ → [[RTO]]/[[RPO]] 目标前置纳入架构评审 │ +└─────────────────────────────────────────────────────┘ + ↓ +┌─────────────────────────────────────────────────────┐ +│ 2. SOFTWARE（软件） │ +│ → 软件内嵌遥测，支持持续健康监控 │ +│ → [[Self-Healing]] 自愈能力 │ +│ → [[Observability]] 驱动的故障检测 │ +└─────────────────────────────────────────────────────┘ + ↓ +┌─────────────────────────────────────────────────────┐ +│ 3. BUILD（构建） │ +│ → [[Customer-Zero]] 环境验证恢复路径 │ +│ → 在发布前验证 RTO/RPO 是否满足 SLA │ +│ → CI/CD 流水线中的恢复演练 │ +└─────────────────────────────────────────────────────┘ + ↓ +┌─────────────────────────────────────────────────────┐ +│ 4. ENVIRONMENTS（环境） │ +│ → [[SRE]] + 可观测性工程持续运营 │ +│ → 跨 AWS/GCP/Azure 的统一可恢复性标准 │ +│ → Error Budget 驱动发布节奏 │ +└─────────────────────────────────────────────────────┘ +``` + +## Key Enablers + +| 驱动因素 | 说明 | +|----------|------| +| **[[SRE]]** | 用软件工程思维解决运维问题，通过 Error Budget 量化可靠性 | +| **[[Observability]]** | 通过遥测数据持续理解系统健康状态，是 Recovery Assurance 的技术前提 | +| **[[Self-Healing]]** | 软件层面的自动恢复能力，减少人工响应时间和 Toil | +| **[[Customer-Zero]]** | 内部验证环境，在生产级配置下验证恢复路径 | +| **[[Automation]]** | 减少人工协调成本，使 Recovery Assurance 可规模化 | + +## Why Evolution is Needed + +| 传统 DR 的问题 | Recovery Assurance 的解决方案 | +|---------------|-----------------------------| +| 反应式（Reactive） | 主动设计（Proactive） | +| 手动测试，成本高 | 自动化验证，持续运行 | +| 按客户时间表 | 持续监控，即时验证 | +| 无一致性方法 | 统一四位框架 | +| 无法规模化 | 自动化保障，可规模化 | +| 仅覆盖区域故障 | 覆盖多云多层级故障模式 | + +## Connection to Business Continuity + +Recovery Assurance 是 [[Business-Continuity-Plan]]（业务连续性计划）在 IT 技术层面的具体实现： + +- **BCP 定义业务恢复目标**（最大可接受中断时长、关键业务功能） +- **Recovery Assurance 实现技术恢复能力**（RTO/RPO、自动化恢复路径） +- **两者共同**：确保灾难发生后业务能在 SLA 时间内恢复运营 + +## Related Concepts + +- [[Disaster-Recovery]] — Recovery Assurance 的前身，从 DR 演进而来 +- [[SRE]] — Recovery Assurance 的核心方法论 +- [[Observability]] — Recovery Assurance 的技术基础 +- [[Self-Healing]] — Recovery Assurance 在软件层面的自动恢复实现 +- [[Customer-Zero]] — Recovery Assurance Build 阶段的验证环境 +- [[RTO]] / [[RPO]] — Recovery Assurance 的量化目标 +- [[Business-Continuity-Plan]] — Recovery Assurance 的上层业务框架 + +## Sources + +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/Resolver-Rules.md b/wiki/concepts/Resolver-Rules.md new file mode 100644 index 00000000..1065afee --- /dev/null +++ b/wiki/concepts/Resolver-Rules.md @@ -0,0 +1,35 @@ +--- +title: "Resolver Rules" +type: concept +tags: + - AWS + - DNS + - Networking +last_updated: 2026-04-28 +--- + +## Definition + +Resolver Rules（解析规则）是 AWS Route 53 Resolver 的核心配置对象，用于定义特定域名的 DNS 查询应转发至哪个目标 DNS 服务器（如本地数据中心的 On-prem DNS）。它们是实现混合云 DNS 解析的关键机制。 + +## Aliases +- Resolver Rules +- Route 53 Resolver Rules +- DNS Forwarding Rules + +## Key Characteristics + +- **域名匹配转发**：规则按域名模式（如 `*.corp.internal`）匹配查询，将匹配项转发至指定 IP 地址的 DNS 服务器 +- **共享机制**：通过 AWS RAM（Resource Access Manager）将规则跨账号共享给业务账户，业务 VPC 无需单独创建规则即可使用 +- **入站 vs 出站**：Resolver Rules 配合 Outbound Endpoint 使用；Inbound Endpoint 则处理反向（由外向内）的解析请求 +- **Terraform 自动化**：规则定义完全可通过 Terraform 声明式管理，集成到 Landing Zone 模块化供给流程中 +- **授权流程**：跨账号共享时，接受方账户需明确接受共享，规则才能生效 + +## Related Concepts +- [[Route-53-Resolver]] — Resolver Rules 是 Resolver 的配置对象 +- [[AWS-RAM]] — 跨账号共享规则的技术手段 +- [[Private-Hosted-Zone]] — 与 PHZ 互补：PHZ 覆盖私有域名直接解析，Rules 覆盖需转发至外部 DNS 的域名 +- [[AWS-Landing-Zone]] — 集中化 DNS 账号场景下的规则管理策略 + +## Sources +- [[ctp-topic-19-configuring-dns-within-aws-lzs]] diff --git a/wiki/concepts/Resource-Tagging.md b/wiki/concepts/Resource-Tagging.md new file mode 100644 index 00000000..9883fbf4 --- /dev/null +++ b/wiki/concepts/Resource-Tagging.md @@ -0,0 +1,45 @@ +--- +title: "Resource Tagging" +type: concept +tags: ["AWS", "Tagging", "Cloud-Governance", "Cost-Allocation", "Security"] +sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security", "public-cloud-learning-sessions-opentext-tagging-standard-v2"] +last_updated: 2026-04-28 +--- + +## Definition +Resource Tagging（资源标签）是 AWS 及其他云平台中的元数据体系——在云资源上附加键值对，用于描述资源的业务属性、安全分类、运营信息等。标签是云环境动态化、自动化治理的基础。 + +## Standard Tag Taxonomy +在 OpenText/Micro Focus 云转型环境中，核心标签维度包括： + +| 标签键 | 说明 | 示例 | +|--------|------|------| +| `Owner` | 资源所有者（优先使用 PDL） | `Steve.Jarman@opentext.com` | +| `Team` | 团队名称 | `ADM`, `ITOM` | +| `Type` | 资源类型 | `R&D`, `Production` | +| `BU` / `BusinessUnit` | 业务单元 | `Octane`, `ArcSight` | +| `Product` | 所属产品 | `IDM`, `Operations` | +| `Environment` | 环境 | `Production`, `UAT`, `Dev` | +| `ServerRole` | 服务器角色 | `Web`, `DB`, `App` | +| `AppID` | 应用标识 | `OCT-HUB-001` | +| `Account` | AWS 账号 | `123456789012` | + +## Tagging as Security Foundation +在 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中，Steve Jarman 强调： +- **迁移规划前提**：在将资产迁移至云之前，必须先收集机器信息 → 理解迁移范围 → 应用正确标签 +- **标签即安全凭证**：传统基于 IP 的防火墙规则无法适应云环境动态性，标签成为安全策略的动态依据 +- **SCP 强制执行**：通过 [[SCP-Security-Control-Policy]] 拒绝标签不合规的资源创建 +- **Checkpoint 标签驱动**：Checkpoint Firewall 读取资源标签决定网络访问策略，标签缺失或错误导致流量被拦截 + +## Tagging Governance Workflow +``` +制定标签标准 → IaC 自动打标 → SCP 强制合规 → Tag Validation Tool 审计 → 修正不合规资源 +``` +（参考 [[ctp-topic-28-aws-tag-validation-tool]]） + +## Connections +- [[SCP-Security-Control-Policy]] — 标签是 SCP 的执行依据 +- [[Checkpoint-Firewall]] — 标签驱动防火墙策略 +- [[AWS-Landing-Zone]] — 标签体系是 LZ 治理的核心 +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] +- [[public-cloud-learning-sessions-opentext-tagging-standard-v2]] diff --git a/wiki/concepts/Route-53-Resolver.md b/wiki/concepts/Route-53-Resolver.md new file mode 100644 index 00000000..51768b57 --- /dev/null +++ b/wiki/concepts/Route-53-Resolver.md @@ -0,0 +1,34 @@ +--- +title: "Route 53 Resolver" +type: concept +tags: + - AWS + - DNS + - Networking +last_updated: 2026-04-28 +--- + +## Definition + +AWS Route 53 Resolver 是 Amazon Route 53 提供的 DNS 解析服务核心组件，负责在 VPC 与其他网络环境之间转发 DNS 查询。它提供两个关键端点类型：Inbound Endpoints（允许本地数据中心向 AWS VPC 发起 DNS 查询）和 Outbound Endpoints（允许 VPC 向本地 DNS 服务器转发查询），从而实现混合云环境的双向 DNS 解析。 + +## Aliases +- Route 53 Resolver +- AWS Resolver + +## Key Characteristics + +- **混合云 DNS 网关**：解决 VPC 内 AWS 资源与本地数据中心（On-prem）之间的域名解析互通问题 +- **Inbound Endpoint**：监听 ENI 上的 UDP/TCP 53 端口，接收来自本地网络的递归 DNS 查询 +- **Outbound Endpoint**：通过转发规则（Resolver Rules）将匹配特定域名的查询主动发送至指定 IP（如 On-prem DNS 服务器） +- **跨账号共享**：Resolver Rules 可通过 AWS RAM 共享给其他 AWS 账户，无需在各账户单独创建规则 +- **与 Private Hosted Zone 协同**：Resolver 自动优先查询 PHZ 中的记录，未命中时再使用转发规则 + +## Related Concepts +- [[Private-Hosted-Zone]] — 在 VPC 内部解析私有域名 +- [[Resolver-Rules]] — 定义域名转发逻辑 +- [[VPC-Association-Authorization]] — 跨账号 VPC 与 PHZ 关联的授权机制 +- [[AWS-Landing-Zone]] — 多账号环境下的 DNS 集中化管理背景 + +## Sources +- [[ctp-topic-19-configuring-dns-within-aws-lzs]] diff --git a/wiki/concepts/SCP-Security-Control-Policy.md b/wiki/concepts/SCP-Security-Control-Policy.md new file mode 100644 index 00000000..18f40e7c --- /dev/null +++ b/wiki/concepts/SCP-Security-Control-Policy.md @@ -0,0 +1,42 @@ +--- +title: "SCP (Security Control Policy)" +type: concept +tags: ["AWS", "Security", "Landing-Zone", "Tagging", "OU"] +sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] +last_updated: 2026-04-28 +--- + +## Definition +SCP（Security Control Policy）是 AWS Organizations 中的一种策略类型，通过「显式拒绝」（deny）逻辑强制执行组织范围内的安全与合规规则。与 IAM 策略不同，SCP 作用于组织单元（OU）或账户级别，控制谁可以执行什么操作，而不是授予权限。 + +## Core Mechanism +- **基于标签的 SCP**：拒绝资源在不符合预期标签值的情况下被创建（如：拒绝在特定 OU 中创建没有 `Environment: Production` 标签的 EC2 实例） +- **OU 分层执行**：SCP 在 OU 层级自上而下继承，高层级 OU 的拒绝策略优先级最高 +- **防止标签篡改**：阻止普通用户通过修改标签（如从 `Team: ADM` 改为 `Team: ITOM`）绕过安全审计或访问控制 + +## In AWS Landing Zone Context +在 [[AWS-Landing-Zone]] 架构中，SCP 是 Landing Zone 治理的关键组件： +- 与 [[Checkpoint-Firewall]] 的标签驱动策略联动：SCPs 确保只有正确标记的资源进入云环境，Checkpoint 基于标签实施网络层访问控制 +- SCP 是「防护栏」（Guardrails）的核心实现手段 +- 补充 AWS IAM 的「授予权限」模型，提供强制拒绝能力 + +## Example Use Case +``` +# 拒绝在没有 Owner 标签的情况下创建 EC2 +{ + "Effect": "Deny", + "Action": "ec2:RunInstances", + "Resource": "arn:aws:ec2:*:*:instance/*", + "Condition": { + "Null": { + "aws:RequestTag/Owner": "true" + } + } +} +``` + +## Connections +- [[AWS-Landing-Zone]] — SCP 是 LZ 治理的核心工具 +- [[Checkpoint-Firewall]] — SCP + Checkpoint 构成标签驱动的端到端安全体系 +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] +- [[ctp-topic-28-aws-tag-validation-tool]] — SCP 强制执行标签，Tag Validation Tool 审计存量资源 diff --git a/wiki/concepts/SD-WAN.md b/wiki/concepts/SD-WAN.md new file mode 100644 index 00000000..c3d8f973 --- /dev/null +++ b/wiki/concepts/SD-WAN.md @@ -0,0 +1,58 @@ +--- +title: "SD-WAN (Software-Defined Wide Area Network)" +type: concept +tags: [AWS, Networking, WAN, Overlay, SASE] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## SD-WAN (Software-Defined Wide Area Network) + +SD-WAN（Software-Defined Wide Area Network）是一种软件定义的广域网技术，通过软件控制层对物理网络进行抽象，实现动态路径选择、负载均衡和自动化流量调度。 + +## Definition + +- **SD**: Software-Defined——网络控制平面与数据平面分离，通过软件集中管理 +- **WAN**: Wide Area Network——跨越地理区域的广域网 +- **核心价值**: 将底层物理网络（Underlay）抽象为逻辑 Overlay 网络，灵活调度流量 + +## In CTP Architecture + +在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中描述的演进路线： + +- **当前状态**: TGW 间路由依赖静态前缀列表，缺乏 BGP 动态路由，DR 场景需要人工干预 +- **演进目标**: 引入 [[SilverPeak]] SD-WAN 作为叠加网络（Overlay），在 AWS 中部署虚拟 SD-WAN 设备 +- **解决问题**: 动态路径选择、自动化流量调度，消除静态路由的局限性 + +## Key Properties + +| 属性 | 值 | +|------|-----| +| 架构类型 | Overlay Network（叠加网络） | +| 控制平面 | 软件集中控制，与硬件解耦 | +| 路径选择 | 基于实时链路质量（带宽、延迟、丢包率） | +| 部署模式 | 虚拟设备（vSIM 或纯软件） | +| 典型厂商 | Silver Peak, Viptela (Cisco), VeloCloud (VMware) | + +## Relationship to SASE + +SD-WAN 是 SASE（Secure Access Service Edge）架构的核心组件： +- SD-WAN 提供灵活的广域网连接 +- SASE 将 SD-WAN 与安全服务（SWG、CASB、ZTNA）整合 +- [[Prisma-Access]] 即为 Palo Alto Networks 的 SASE 产品 + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 演进目标 ← [[SD-WAN]] +- [[SilverPeak]] ← 供应商 ← [[SD-WAN]] +- [[Overlay-Network]] ← 基于 ← [[SD-WAN]] +- [[Prisma-Access]] ← 整合 ← [[SD-WAN]] + +## Relationship to CTP Topic 31 + +在 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] 中，SSM 作为 SD-WAN 落地前的**临时/过渡方案**：SSM 提供零 VPN 的安全访问，而 SD-WAN 落地后将从网络层彻底解决多区域互联与安全策略统一管理问题。 + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] +- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] diff --git a/wiki/concepts/SLR.md b/wiki/concepts/SLR.md new file mode 100644 index 00000000..9bd40447 --- /dev/null +++ b/wiki/concepts/SLR.md @@ -0,0 +1,40 @@ +--- +title: "SLR" +type: concept +tags: [Service-Level, SLO, SRE, Monitoring, Cloud-Transformation] +last_updated: 2026-04-28 +--- + +## Definition + +SLR (Service Level Requirement，服务等级需求) 是组织对服务可靠性和性能的业务层面需求定义。它是从业务视角出发，对服务应达到的可用性和性能水平的正式要求，通常与 SLA（Service Level Agreement，对外承诺）和 SLO（Service Level Objective，内部目标）配套使用。 + +## Relationship with SLO and SLA + +``` +SLA（对外承诺）← 基于 ← SLO（内部目标）← 基于 ← SLR（业务需求） +``` + +| 层级 | 视角 | 说明 | +|------|------|------| +| SLR | 业务需求 | 产品/业务方对服务等级的实际需求 | +| SLO | 内部目标 | SRE/运维团队设定的内部可靠性目标（通常比 SLA 更严格） | +| SLA | 对外承诺 | 对客户的正式合同承诺 | + +## SLR in Cloud Transformation + +在云转型项目中，SRE 团队与产品团队协作定义 SLR/SLO 体系： +- **目标**：向产品团队做周/双周/月度指标汇报 +- **方法**：定义监控指标，从 SLI 向上汇总至 KPI +- **工具**：通过 Grafana 等可观测性工具展示 SLO 达成情况 + +## Relationship with Monitoring + +SLR 是监控体系设计的基础： +1. 从 SLR 导出具体的 SLI（Service Level Indicator） +2. SLI 对应具体的监控指标和告警规则 +3. 指标持续采集并与 SLO 比对，消耗 Error Budget + +## Sources + +- [[ctp-topic-30-managing-change]] diff --git a/wiki/concepts/SRE.md b/wiki/concepts/SRE.md new file mode 100644 index 00000000..b8b35e28 --- /dev/null +++ b/wiki/concepts/SRE.md @@ -0,0 +1,54 @@ +--- +title: "SRE" +type: concept +tags: [SRE, Site-Reliability-Engineering, DevOps, Automation, Cloud-Transformation] +last_updated: 2026-04-28 +--- + +## Definition + +SRE (Site Reliability Engineering，站点可靠性工程) 是一种通过软件工程思维解决运维问题的方法论。其核心理念是打破传统运维与产品开发之间的壁垒，通过自动化、可靠性测量和系统性方法提高服务质量。SRE 起源于 Google，现已被广泛应用于云原生和企业 IT 环境。 + +## Core Principles + +### 1. 将错误视为学习机会 +SRE 将故障和错误视为改进系统的机会，而非单纯追究责任。通过 Post-mortem 和 CAPA 流程从事故中提取根本原因。 + +### 2. 拥抱风险 +SRE 接受服务存在固有风险，通过 Error Budget 和 SLO 量化可接受的可靠性水平，在创新速度与稳定性之间取得平衡。 + +### 3. 消除 toil（重复性手工劳动） +Toil 是指那些手动、重复性、可自动化、缺乏持久价值且随规模线性增长的工作。SRE 团队应将 toil 控制在 50% 以下，其余时间用于系统性改进和功能开发。 + +### 4. 自动化一切可自动化的 +通过 IaC（基础设施即代码）和 CI/CD Pipeline 将变更实现完全自动化，减少人工审批环节和出错概率。 + +### 5. 可测量性优先 +所有系统行为都需要可观测性指标支撑（SLI/SLO/SLA），通过监控和告警实现问题的早期发现。 + +## SRE Team Collaboration Model + +SRE 团队在云转型项目中与产品团队在三个阶段协作： + +| 阶段 | 说明 | SRE 职责 | +|------|------|----------| +| Build（构建） | 产品基础设施搭建阶段 | 定义技术架构、共享 IaC 模块、定义 SLO/SLR | +| Early Live Support（早期上线支持） | Build 与 BAU 之间的过渡阶段 | 完成 Go-Live Checklist（监控覆盖、支持模型、事件响应流程） | +| BAU（日常运维） | 持续运营阶段 | 周/双周/月度指标汇报、持续改进 | + +## Key Metrics + +- **SLI (Service Level Indicator)**：服务等级指标，直接测量的系统指标（如可用性、延迟） +- **SLO (Service Level Objective)**：服务等级目标，SLI 的目标值（如 99.9% 可用性） +- **Error Budget**：错误预算，SLO 允许范围内的错误配额，用于指导发布节奏 +- **Toil**：重复性手工劳动，应控制在 50% 以下 + +## Relationship with DevOps + +SRE 是 DevOps 理念的具体实现形式之一。DevOps 强调打破开发与运维的边界，SRE 则通过量化指标（Error Budget、SLO）和自动化工具将这一理念落地。 + +## Sources + +- [[ctp-topic-30-managing-change]] +- [[ctp-topic-41-nfrs-and-error-budgets]] +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/Self-Healing.md b/wiki/concepts/Self-Healing.md new file mode 100644 index 00000000..68fbd3ee --- /dev/null +++ b/wiki/concepts/Self-Healing.md @@ -0,0 +1,99 @@ +--- +title: "Self-Healing" +type: concept +tags: [Self-Healing, SRE, Automation, Resilience, Cloud-Native, Fault-Tolerance] +sources: + - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 +last_updated: 2026-04-29 +--- + +## Self-Healing（自愈能力） + +自愈能力（Self-Healing）是指软件系统具备持续监控系统健康状态，并在无需人工干预的情况下自动检测故障并恢复服务的能力。是 [[SRE]] 和 [[Recovery-Assurance]] 理念在软件层面的具体实现。 + +## Definition + +> "Self-healing is the ability of a system to detect failures, diagnose the root cause, and restore service automatically without human intervention." — [[SRE]] Principles + +自愈系统通过以下机制实现自动化恢复： + +1. **故障检测**：通过[[Observability]]采集的遥测数据识别异常 +2. **根因诊断**：分析异常模式，判断故障类型（临时故障 vs. 持久故障） +3. **恢复执行**：触发预定义的修复动作（重启服务、切换节点、扩容降级） +4. **验证反馈**：恢复后验证服务可用性，确认健康状态 + +## Self-Healing Mechanisms + +| 层级 | 机制 | 示例 | +|------|------|------| +| **基础设施层** | 自动替换失败的计算节点 | Kubernetes Node 自动替换、EC2 Auto Recovery | +| **容器/编排层** | Pod 自动重启、重新调度 | Kubernetes Liveness/Readiness Probe、自动重启策略 | +| **应用层** | 应用内嵌自愈逻辑 | Circuit Breaker 模式、Graceful Degradation | +| **数据层** | 自动故障转移 | Multi-AZ RDS 自动 failover、DynamoDB 自动复制 | +| **网络层** | 流量自动路由 | Route 53 Health Check + DNS Failover、NLB 自动移除不健康目标 | + +## Relationship with SRE + +在 [[SRE]] 实践中，自愈能力是消除 Toil（重复性手工劳动）的重要手段： + +- **Mean Time To Recovery（MTTR）降低**：自动化恢复比人工响应快 10-100 倍 +- **Toil 减少**：值班工程师不再需要手动处理可预测的故障模式 +- **Error Budget 保护**：自动恢复快，系统可用性更高，Error Budget 消耗更慢 + +## Connection to Recovery Assurance + +[[Recovery-Assurance]] 要求系统不仅能恢复，还要能**保证**恢复能力。自愈能力是 Recovery Assurance 的技术基础之一： + +- **持续可恢复性验证**：自愈测试本身就是一种恢复路径的持续验证 +- **减少人工依赖**：人工协调是 DR 测试延迟的主要原因，自愈减少了人力瓶颈 +- **规模化的前提**：无法自愈的系统在云原生规模下无法保证恢复能力 + +## Self-Healing vs. Chaos Engineering + +| 维度 | 自愈（Self-Healing） | 混沌工程（Chaos Engineering） | +|------|---------------------|---------------------------| +| **目的** | 故障时自动恢复 | 主动注入故障，验证系统韧性 | +| **触发** | 被动（故障发生） | 主动（实验注入） | +| **时机** | 生产故障时执行 | 日常实验 | +| **关系** | 互补：混沌工程发现弱点 → 自愈修复故障 | 互补：混沌工程发现弱点 → 自愈修复故障 | + +## Implementation Pattern + +```yaml +# Kubernetes Self-Healing Manifest 示例 +livenessProbe: + httpGet: + path: /healthz + port: 8080 + initialDelaySeconds: 30 + periodSeconds: 10 + failureThreshold: 3 + +restartPolicy: Always # Pod 故障自动重启 +terminationGracePeriodSeconds: 30 # 优雅关闭 + +# HPA（水平 Pod 自动扩缩容） +apiVersion: autoscaling/v2 +kind: HorizontalPodAutoscaler +spec: + minReplicas: 3 + maxReplicas: 10 + metrics: + - type: Resource + resource: + name: cpu + target: + type: Utilization + averageUtilization: 70 +``` + +## Related Concepts + +- [[SRE]] — 自愈是 SRE 消除 Toil、提升可靠性的核心手段 +- [[Recovery-Assurance]] — 自愈是 Recovery Assurance 的技术基础 +- [[Observability]] — 自愈依赖可观测性提供的遥测数据 +- [[High-Availability]] — 高可用是自愈的基础设施保障 + +## Sources + +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/concepts/Solution-Design.md b/wiki/concepts/Solution-Design.md new file mode 100644 index 00000000..bf21aba4 --- /dev/null +++ b/wiki/concepts/Solution-Design.md @@ -0,0 +1,83 @@ +--- +title: "Solution Design" +type: concept +tags: [CTP, Cloud, AWS, Architecture] +sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] +last_updated: 2026-04-14 +--- + +## Definition + +解决方案设计（Solution Design）是在 POC 阶段需要完成并经过 Design Authority 审批的架构文档，确保云迁移方案符合云原生原则、安全合规要求和企业的技术标准。 + +## Purpose + +- 为云迁移提供经过验证的技术蓝图 +- 确保架构设计满足业务需求和非功能性需求（NFR） +- 为 Design Authority（Gate 1）审批提供依据 +- 为后续 IaC 实施提供规范文档 + +## Key Components + +### 1. Architecture Overview + +- 目标云架构图（VPC 设计、网络拓扑、AZ 分布） +- 与现有本地环境的集成方案 +- 多账号结构设计 + +### 2. Landing Zone Design + +- 基于 Gruntwork 参考架构的 Landing Zone 配置 +- 安全边界和网络分段 +- IAM 角色和访问控制策略 + +### 3. Application Migration Design + +- 应用的云迁移策略（Rehost/Replatform/Refactor） +- 数据迁移方案 +- 依赖关系映射 + +### 4. IaC Design + +- Terraform/Terragrunt 模块设计 +- CI/CD 流水线配置 +- 环境一致性策略 + +### 5. Security & Compliance + +- 安全基线配置 +- 合规审计规划 +- 数据保护措施 + +### 6. Operations Design + +- 监控和可观测性方案 +- 灾难恢复策略 +- 运维流程和 Runbook + +## Design Principles + +- **云原生优先**：充分利用云原生服务，减少 lift-and-shift +- **安全性内嵌**：安全要求从设计阶段纳入，而非后期添加 +- **IaC 为核心**：所有基础设施变更通过代码管理 +- **可观测性设计**：监控和日志从一开始就规划好 +- **可扩展性**：架构设计应适应未来业务增长 + +## Review & Approval Process + +1. **自评审**：解决方案团队内部评审 +2. **安全评审**：安全团队审查合规性 +3. **Design Authority 评审**：核心评审环节，Gate 1 审批 +4. **最终批准**：纳入正式迁移计划 + +## Related Concepts + +- [[Proof-of-Concept]]：Solution Design 是 POC 阶段的核心产出 +- [[Gate-Process]]：Solution Design 是 Gate 1 审批的核心交付物 +- [[Landing-Zone-Architecture]]：Solution Design 的基础设施蓝图 +- [[Infrastructure-as-Code]]：Solution Design 的实施手段 +- [[Design-Authority]]：Solution Design 的审批主体 + +## References + +- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] diff --git a/wiki/concepts/Static-Routing.md b/wiki/concepts/Static-Routing.md new file mode 100644 index 00000000..7248d38b --- /dev/null +++ b/wiki/concepts/Static-Routing.md @@ -0,0 +1,50 @@ +--- +title: "Static Routing" +type: concept +tags: [AWS, Networking, Routing, Transit Gateway] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## Static Routing + +静态路由（Static Routing）是指由网络管理员手动配置的固定路由条目，路由路径不随网络拓扑变化而自动更新。与之对应的是使用动态路由协议（如 BGP、OSPF）自动发现和更新路由的动态路由。 + +## Definition + +- **配置方式**: 手动在路由器/网关中写入目的网络与下一跳的对应关系 +- **路由选择**: 固定不变，除非管理员主动修改 +- **适用场景**: 小型网络、路由路径明确且稳定的环境 + +## Limitations in AWS Transit Gateway Context + +在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中描述的问题： + +- **当前状态**: TGW 间的跨区域路由依赖静态前缀列表（Prefix Lists） +- **缺乏动态协议**: 没有 BGP 等动态路由协议支持，无法自动感知链路故障或拓扑变化 +- **DR 场景痛点**: 灾难恢复场景下需要人工干预切换路由，无法自动收敛 +- **规模局限**: 随着 Landing Zone 数量增长，手动维护静态路由表的复杂度呈指数上升 + +## Static vs Dynamic Routing + +| 维度 | 静态路由 | 动态路由（BGP/OSPF） | +|------|---------|-------------------| +| 配置复杂度 | 低（小型网络） | 高 | +| 故障自愈 | ❌ 需人工干预 | ✅ 自动收敛 | +| 可扩展性 | 差 | 好 | +| 资源开销 | 低 | 高（协议开销） | +| 适用规模 | < 10 节点 | 任意规模 | + +## Evolution Path + +静态路由的局限推动了向 [[SD-WAN]] 的演进——SD-WAN 通过软件控制层实现动态路径选择，即使底层 Underlay 网络仍使用静态路由，Overlay 层也能实现智能流量调度。 + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 痛点 ← [[Static-Routing]] +- [[AWS-Transit-Gateway-TGW]] ← 应用于 ← [[Static-Routing]] +- [[SD-WAN]] ← 演进目标 ← [[Static-Routing]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/concepts/TCO.md b/wiki/concepts/TCO.md new file mode 100644 index 00000000..5857f71f --- /dev/null +++ b/wiki/concepts/TCO.md @@ -0,0 +1,46 @@ +--- +title: "Total Cost of Ownership (TCO)" +type: concept +tags: + - Cloud + - FinOps + - Cost-Management + - AWS + - VMware +last_updated: 2026-05-07 +--- + +## Total Cost of Ownership (TCO) + +A financial framework used to evaluate the total cost of acquiring, operating, and maintaining a technology solution over its entire lifecycle, compared across different deployment options. + +## Definition +TCO encompasses all direct and indirect costs associated with a technology investment, not just the upfront acquisition cost. In cloud migration and hybrid cloud contexts, TCO analysis is used to compare on-premises infrastructure against cloud-hosted solutions like VMware Cloud on AWS or native AWS services. + +## Components +- **Acquisition Costs**: Hardware/software procurement, licensing, implementation +- **Operational Costs**: Staff, maintenance, support contracts, utilities +- **Infrastructure Costs**: Data center space, power, cooling, physical security +- **Hidden Costs**: Underutilization, downtime, technical debt, migration effort +- **Exit Costs**: Data transfer out, licensing cancellation, decommissioning + +## Key Applications + +### VMC on AWS TCO Analysis +- Cloud economics team performs TCO calculations for VMC on AWS vs. on-premises vs. native hyperscaler +- VMware sells entire hosts, enabling over-provisioning and cost reduction +- VMC on AWS offers 27% cost saving compared to going to a regular cloud +- Compare TCO with on-premises or other hyperscalers for informed migration decisions + +### General Cloud TCO Considerations +- On-premises: CapEx heavy, but can have unused capacity (Micro Focus hardware utilization < 40%) +- Cloud: OpEx model, pay-as-you-go, but egress costs and lock-in risks +- Hybrid: Balances migration flexibility with gradual transition costs + +## Connections +- [[VMware-Cloud-on-AWS]] ← evaluates ← [[TCO]] for cloud migration decisions +- [[Cloud-Transformation]] ← uses ← [[TCO]] for business case justification +- [[FinOps]] ← practices ← [[TCO]] analysis for cloud cost optimization + +## Sources +- [[ctp-topic-43-vmware-cloud-on-aws]] diff --git a/wiki/concepts/TGW-Peering.md b/wiki/concepts/TGW-Peering.md new file mode 100644 index 00000000..2d665923 --- /dev/null +++ b/wiki/concepts/TGW-Peering.md @@ -0,0 +1,53 @@ +--- +title: "TGW Peering" +type: concept +tags: [AWS, Networking, Transit Gateway, Multi-Region] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## TGW Peering + +TGW Peering（Transit Gateway Peering）是在不同区域（Region）或同一区域（Region）内的两个 AWS Transit Gateway 之间建立的点对点连接，用于跨网段流量传输和跨区域 VPC 互联。 + +## Definition + +- **连接对象**: 两个 Transit Gateway（可跨区域或同区域） +- **流量类型**: VPC-to-VPC、Transit Gateway-to-On-prem、跨区域互联 +- **路由控制**: 通过路由表（Transit Gateway Route Table）配置，支持静态路由和关联/传播机制 + +## In CTP Global Architecture + +在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中描述的架构： + +- **连接模式**: 所有 Landing Zones 通过 TGW Peering 接入各自地理区域的区域 Hub Transit Gateway +- **跨区域连接**: 各区域 Hub Transit Gateway 之间通过 Full Mesh（全网状）TGW Peering 连接，确保全球流量可达 +- **地理分区**: APJ/EMEA/AMS 三大区域，每个区域有独立的 Hub Transit Gateway（如 EMEA 伦敦、AMS 俄勒冈） + +## Key Properties + +| 属性 | 值 | +|------|-----| +| 连接类型 | 点对点（Peer-to-Peer） | +| 跨区域支持 | ✅ 支持跨 Region Peering | +| 带宽限制 | 受限于 AWS 全球网络基础设施 | +| 路由方式 | Transit Gateway Route Table（可关联多个路由表） | +| 与 TGW Peering 对比 | 跨区域连接 vs 区域内连接 | + +## Relationship to Related Concepts + +| 概念 | 关系 | +|------|------| +| [[AWS-Transit-Gateway-TGW]] | TGW Peering 的连接主体 | +| [[Hub-and-Spoke]] | Landing Zone 作为 Spoke 通过 TGW Peering 接入 Hub | +| [[Static-Routing]] | 当前 TGW Peering 间路由依赖静态前缀列表 | + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 连接机制 ← [[TGW-Peering]] +- [[AWS-Transit-Gateway-TGW]] ← 连接对象 ← [[TGW-Peering]] +- [[Hub-and-Spoke]] ← 实现方式 ← [[TGW-Peering]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/concepts/Transit-Gateway.md b/wiki/concepts/Transit-Gateway.md index a1d3211e..d5bd5dc6 100644 --- a/wiki/concepts/Transit-Gateway.md +++ b/wiki/concepts/Transit-Gateway.md @@ -30,6 +30,7 @@ Transit Gateway 在 AWS Landing Zone 架构中扮演网络互联的核心角色 - **Scope**: Regional - **Architecture**: Hub-and-Spoke - **In SAS LZ**: Network Account 核心组件 +- **Inter-Regional**: 各区域 Hub 通过 [[TGW-Peering]] Full Mesh 互联 ## Relationship to Checkpoint - Transit Gateway 负责路由 diff --git a/wiki/concepts/VPC-Association-Authorization.md b/wiki/concepts/VPC-Association-Authorization.md new file mode 100644 index 00000000..4699f9bb --- /dev/null +++ b/wiki/concepts/VPC-Association-Authorization.md @@ -0,0 +1,36 @@ +--- +title: "VPC Association Authorization" +type: concept +tags: + - AWS + - DNS + - Networking + - Multi-Account +last_updated: 2026-04-28 +--- + +## Definition + +VPC Association Authorization（VPC 关联授权）是 AWS Route 53 私有托管区（PHZ）跨账号关联的安全机制。当一个 VPC（属于账户 A）需要关联另一个账户（B）拥有的 Private Hosted Zone 时，必须先由 PHZ 所有者（账户 B）创建授权记录，明确允许该 VPC 的关联请求，然后由 VPC 所有者（账户 A）执行实际的关联操作。 + +## Aliases +- VPC Association Authorization +- PHZ Cross-Account Association +- 跨账号 PHZ 授权 + +## Key Characteristics + +- **两步流程**：① PHZ 拥有者执行 `associate-vpc-with-hosted-zone` 并传入 `vpc` 参数（对方账户的 VPC）进行授权；② VPC 拥有者在自己的账户中完成关联操作 +- **安全边界**：授权机制确保只有经过明确批准的 VPC 才能解析 PHZ 中的私有域名，防止未授权访问 +- **Terraform 支持**：两步流程均可通过 Terraform 声明式管理，推荐由 DNS 账号集中执行授权操作 +- **解除关联**：同理，解除关联也需要 PHZ 拥有者先撤销授权 +- **适用场景**：在 Landing Zone 多账号架构中，业务账户的 VPC 需关联 DNS 账户托管的 PHZ + +## Related Concepts +- [[Private-Hosted-Zone]] — 授权的目标对象 +- [[AWS-Landing-Zone]] — 多账号环境下的典型应用场景 +- [[Route-53-Resolver]] — 与 PHZ 协同工作的解析引擎 +- [[AWS-RAM]] — 可用于跨账号共享 Resolver Rules；PHZ 关联授权是另一种跨账号资源共享机制 + +## Sources +- [[ctp-topic-19-configuring-dns-within-aws-lzs]] diff --git a/wiki/concepts/VPC-自动化供给.md b/wiki/concepts/VPC-自动化供给.md new file mode 100644 index 00000000..0930bd2d --- /dev/null +++ b/wiki/concepts/VPC-自动化供给.md @@ -0,0 +1,100 @@ +--- +title: "VPC-自动化供给" +type: concept +tags: [AWS, VPC, IaC, Automation, IPAM] +sources: + - ctp-topic-45-automatic-ip-address-allocation-with-ipam + - ctp-topic-61-workload-vpc-provision-with-ipam-automation +last_updated: 2026-04-24 +--- + +## VPC-自动化供给 + +通过声明式配置文件自动完成 AWS VPC 创建的自动化流程，IP 地址分配完全由 IPAM 系统驱动，无需人工介入。VPC 自动化供给是 Cloud Transformation Programme 中网络层自动化的核心组件。 + +## Traditional Workflow（传统流程） + +``` +业务单元（BU） + ↓ 提出 IP 地址需求 +SRE 团队 + ↓ 向网络团队发起申请 +网络团队 + ↓ 计算最优 CIDR 范围 + ↓ 更新电子表格 +SRE 团队 + ↓ 准备 YAML 配置文件（硬编码 CIDR） + ↓ 执行 Terraform/Terragrunt +``` + +**问题**： +- 多次手工交接，效率低下 +- 手工规划易产生 IP 地址重叠 +- 电子表格难以维护，缺乏版本控制 +- 自动化程度低，变更缓慢 + +## Automated Workflow（自动化流程） + +``` +用户 + ↓ 填写 YAML（业务联系人 + 工程联系人 + 期望子网大小） +Terragrunt + ↓ 调用 IPAM API（Infoblox NIOS） +Infoblox Grid + ↓ 自动分配下一可用 IP 地址块 +Terragrunt + ↓ 执行 VPC 创建 +AWS + ↓ VPC + Subnets 创建完成 +Infoblox Grid + ↓ 记录分配结果 +``` + +**优势**： +- 无需手工申请 IP 地址 +- 单一可信数据源（IPAM） +- 版本控制友好的 YAML 配置 +- 销毁时自动回收 IP 地址 +- 向后兼容旧配置 + +## YAML Configuration + +新格式 YAML 配置文件（对比传统 network.yml）： + +```yaml +infoblox: + business_contact: "bu@example.com" + engineering_contact: "sre@example.com" + date: "2026-04-14" + subnet_size: "/22" # 期望子网大小（非硬编码 CIDR） + parent_cidr: "10.1.0.0/16" # 区域常量父 CIDR +vpc_name: "my-vpc" # VPC 名称（支持多 VPC） +availability_zone_ids: # 可选：指定 AZ ID + - "ap-southeast-1a" + - "ap-southeast-1b" +``` + +## CIDR Approval Workflow + +| CIDR 大小 | 流程 | +|-----------|------| +| /22 或更大 | **自动批准**，无需人工介入 | +| /24 或更小 | **需提交理由**，网络团队审批 | + +## Key Concepts + +- [[IPAM]]：驱动自动化供给的核心系统 +- [[Infoblox-NIOS]]：IPAM 的技术实现 +- [[CIDR-审批流程]]：基于 CIDR 大小的差异化审批规则 + +## Connections + +- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← 介绍 VPC 自动化供给机制 +- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← 展示完整应用案例 +- [[ctp-topic-31-network-segregation-and-secure-access]] ← VPC 自动化是网络分段的基础 + +## Aliases + +- VPC Provisioning +- VPC 自动供给 +- Automated VPC Creation diff --git a/wiki/concepts/Zero-Trust-Access.md b/wiki/concepts/Zero-Trust-Access.md new file mode 100644 index 00000000..4876a8c3 --- /dev/null +++ b/wiki/concepts/Zero-Trust-Access.md @@ -0,0 +1,38 @@ +--- +title: "Zero-Trust Access" +type: concept +tags: ["AWS", "Security", "Zero-Trust", "IAM", "SSM"] +sources: ["ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones"] +last_updated: 2026-05-08 +--- + +## Definition +零信任访问（Zero-Trust Access）是一种安全模型，核心理念是"永不信任，始终验证"——无论请求来自网络内部还是外部，均需经过身份验证和授权检查。 + +## In AWS Landing Zone Context +在 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] 中，SSM 替代 VPN 体现了零信任访问原则： +- **默认不信任**：用户每次访问都需要通过 IAM 角色认证 +- **最小权限**：仅授予访问特定 EC2 实例 SSM Agent 的权限 +- **无需 VPN**：不依赖网络层面的信任，通过 IAM + SSM Agent 实现精细化访问控制 +- **双因素认证**：结合 AWS IAM 条件和多因素认证（MFA） + +## Relationship to Traditional VPN +| 维度 | 传统 VPN | Zero-Trust (SSM) | +|------|---------|------------------| +| 信任边界 | 网络层（VPN 隧道内即信任） | 身份层（每次验证） | +| 访问范围 | 网段级别（全网可通） | 实例级别（精确到单台 EC2） | +| 凭证管理 | VPN 共享凭证 | IAM Role 动态凭证 | +| 双因素 | 依赖 VPN 提供商 | 依赖 AWS IAM + MFA | + +## Long-term Vision +在 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] 中描述的演进路径： +- 当前：SSM 零信任访问（临时方案） +- 最终目标：IaC 化 + Break-glass 应急访问，彻底消除控制台登录 + +## Related Concepts +- [[Network-Segmentation]] — 零信任网络隔离 +- [[IAM-Role]] — 零信任身份模型 +- [[AWS-SSM]] — 零信任访问的具体实施工具 + +## Related Sources +- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] diff --git a/wiki/concepts/cost-of-delay.md b/wiki/concepts/cost-of-delay.md new file mode 100644 index 00000000..d6d35bf5 --- /dev/null +++ b/wiki/concepts/cost-of-delay.md @@ -0,0 +1,53 @@ +--- +title: "Cost of Delay (CoD)" +type: concept +tags: + - SAFe + - WSJF + - Prioritization + - CTP +sources: + - ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation +last_updated: 2026-04-28 +--- + +## Definition + +延迟成本（CoD）是因推迟或延迟交付某项工作而造成的**经济价值损失**。它是 WSJF 公式的核心组成部分，量化了"晚做这件事的代价"。 + +## Formula + +``` +CoD = Business Value + Time Criticality + Risk Reduction & Opportunity Enablement +``` + +### Components + +| 组成 | 说明 | 示例 | +|------|------|------| +| Business Value | 交付后带来的直接经济收益 | 收入增长、成本节约 | +| Time Criticality | 窗口期的紧迫程度 | 合规截止日、竞争威胁 | +| Risk Reduction | 降低未来风险的价值 | 安全修复、稳定性提升 | +| Opportunity Enablement | 开启新商业机会的价值 | 进入新市场、API 发布 | + +## Usage in WSJF + +CoD 是 [[Weighted Shortest Job First (WSJF)]] 公式的分子： +``` +WSJF = CoD / Job Size +``` +CoD 越高且 Job Size 越小 → WSJF 越高 → 优先级越高。 + +## Related Concepts + +- [[Weighted Shortest Job First (WSJF)]]：CoD 的主要应用框架 +- [[Serviceable Obtainable Market (SOM)]]：Business Value 评估的宏观参考 + +## Related Sources + +- [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]] + +## Aliases +- Cost of Delay +- CoD +- Delay Cost diff --git a/wiki/concepts/serviceable-obtainable-market.md b/wiki/concepts/serviceable-obtainable-market.md new file mode 100644 index 00000000..33269999 --- /dev/null +++ b/wiki/concepts/serviceable-obtainable-market.md @@ -0,0 +1,38 @@ +--- +title: "Serviceable Obtainable Market (SOM)" +type: concept +tags: + - Market-Analysis + - Business-Value + - CTP +sources: + - ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation +last_updated: 2026-04-28 +--- + +## Definition + +SOM（Serviceable Obtainable Market，服务可获得市场规模）是指在特定时间段内，考虑到现有销售能力、分销渠道和市场份额目标后，**实际可获得的市场规模**。是 TAM（Total Addressable Market，总可寻址市场）和 SAM（Serviceable Available Market，服务可获得市场）的子集。 + +## 在 CTP 价值框架中的应用 + +在云转型计划（CTP）的价值捕获框架中，SOM 是四大评估维度之一： +1. **Revenue Increase**（收入增长） +2. **Cost Reduction**（成本降低） +3. **Risk Position Improvement**（风险改善） +4. **SOM Size**（可获得市场规模） + +SOM 帮助产品团队和需求经理设定**可落地的商业目标**，避免过度乐观的市场预期。 + +## Related Concepts + +- [[Cost of Delay (CoD)]]：量化推迟决策代价的框架 +- [[Value Stream]]：SOM 评估是价值流分析的市场维度输入 + +## Related Sources + +- [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]] + +## Aliases +- SOM +- Serviceable Obtainable Market diff --git a/wiki/concepts/value-stream.md b/wiki/concepts/value-stream.md new file mode 100644 index 00000000..d525bc35 --- /dev/null +++ b/wiki/concepts/value-stream.md @@ -0,0 +1,44 @@ +--- +title: "Value Stream" +type: concept +tags: + - Lean + - Value-Delivery + - Scaled-Agile + - CTP +sources: + - ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation +last_updated: 2026-04-28 +--- + +## Definition + +一组为客户（外部或内部）交付产品或服务的**活动集合**，涵盖从需求提出到价值实现的完整链条。Value Stream 的目标是通过消除浪费（Muda）、减少不均衡（Mura）和克服冗余（Muri）来最大化客户价值。 + +## Types + +- **Operational Value Stream (OVS)**：面向外部客户的解决方案交付，Scaled Agile Framework (SAFe) 定义 +- **Development Value Stream (DVS)**：内部产品或平台的建设与维护，Scaled Agile Framework (SAFe) 定义 + +## Components + +| 活动类型 | 说明 | 示例 | +|---------|------|------| +| 增值活动 (Value-Adding) | 直接为客户创造价值 | 功能交付、快速响应 | +| 价值赋能活动 (Value-Enabling) | 间接支撑价值交付 | 测试环境搭建、培训 | +| 浪费 (Waste / Muda) | 不产生价值，应消除 | 等待、过度加工、缺陷 | + +## Related Concepts + +- [[Weighted Shortest Job First (WSJF)]]：Value Stream 内工作的优先级排序方法 +- [[Lean]]：Value Stream 分析的理论基础 +- [[Cost of Delay (CoD)]]：量化延迟价值的指标 + +## Related Sources + +- [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]] + +## Aliases +- Value Streams +- Value Stream Mapping +- VSM diff --git a/wiki/concepts/weighted-shortest-job-first.md b/wiki/concepts/weighted-shortest-job-first.md new file mode 100644 index 00000000..461a526d --- /dev/null +++ b/wiki/concepts/weighted-shortest-job-first.md @@ -0,0 +1,52 @@ +--- +title: "Weighted Shortest Job First (WSJF)" +type: concept +tags: + - SAFe + - Prioritization + - WSJF + - CTP + - Value-Delivery +sources: + - ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation +last_updated: 2026-04-28 +--- + +## Definition + +WSJF 是 Scaled Agile Framework (SAFe) 中用于**排列工作优先级**的量化方法。通过将"延迟成本"（Cost of Delay）除以"工作规模"（Job Size），得到每单位工时的价值回报，优先做 WSJF 值最高的工作。 + +## Formula + +``` +WSJF = Cost of Delay (CoD) / Job Size +``` + +**Cost of Delay (CoD)** 由三部分构成： +- **Business Value**（业务价值）：对客户的直接经济影响 +- **Time Criticality**（时间紧迫性）：推迟交付的价值损失 +- **Risk Reduction / Opportunity Enablement**（风险降低 / 机会实现） + +## Interpretation + +| WSJF 值 | 优先级 | 含义 | +|---------|--------|------| +| 高 | 🔴 最高 | 价值高 + 工作量小，优先做 | +| 中 | 🟡 中等 | 价值与工作量平衡 | +| 低 | 🟢 低 | 价值低 + 工作量大，延后做 | + +**核心理念**：`What we want to do is deliver the maximum value early back into the business for the least amount of effort.` — 以最小投入尽早交付最大价值。 + +## Related Concepts + +- [[Cost of Delay (CoD)]]：WSJF 公式的分子 +- [[Value Stream]]：WSJF 应用于价值流内的项目排序 +- [[Process]]：WSJF 优化的是过程输出的价值交付效率 + +## Related Sources + +- [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]] + +## Aliases +- WSJF +- Weighted Shortest Job First diff --git a/wiki/entities/AWS-Landing-Zone.md b/wiki/entities/AWS-Landing-Zone.md new file mode 100644 index 00000000..4b4c49d6 --- /dev/null +++ b/wiki/entities/AWS-Landing-Zone.md @@ -0,0 +1,40 @@ +--- +title: "AWS Landing Zone" +type: entity +tags: ["AWS", "Landing-Zone", "Multi-Account", "Architecture"] +sources: ["ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones", "ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] +last_updated: 2026-04-28 +--- + +## Overview +AWS Landing Zone 是 AWS 推荐的多账户架构框架，用于建立安全、可扩展、合规的云基础架构基础。Micro Focus 采用基于 Gruntwork 的 Landing Zone 参考架构，通过 Terraform/Terragrunt 管理所有资源。 + +## Core Components +- **Shared Services Account**：托管 Jenkins、AD、Route 53 私有 DNS 等共享基础设施 +- **Network Account**：Transit Gateway + Checkpoint 防火墙管理所有互联网流量 +- **Security Account**：联邦用户、跨账户访问、IAM Role 集中管理 +- **Logs Account**：CloudTrail、Config 日志集中存储 +- **Product/SaaS Accounts**：业务负载运行的账户 + +## Network Isolation Challenges +在 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] 中描述的安全挑战： +- On-prem 系统和 VPN 用户因共享网络配置可直接访问生产工作负载 +- 解决路径：Checkpoint SPI（Default Deny）+ AWS SSM 替代 VPN + +## Tag-Based Security Architecture +在 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中，Steve Jarman 和 Pradeep 深入阐述了基于标签的云原生安全架构： + +- **SCP（Security Control Policy）强制标签规范**：通过「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；普通 ADM 用户无法擅自将标签改为 ITOM +- **OU 分层架构**：通过多层 OU 检查标签值，确保正确的标记和必要的安全控制 +- **标签体系**：涵盖机器名、所有者（PDL）、类型、业务单元、产品、环境、服务器角色等维度，是云迁移规划的前提 +- **Checkpoint 标签驱动策略**：从基于 IP 地址的传统防火墙规则转向利用 AWS 标签作为安全凭证，实现动态云环境 + +## Aliases +- Landing Zone +- LZ +- AWS LZ + +## Connections +- [[Network-Segmentation]] — 网络隔离是 LZ 安全架构核心 +- [[AWS-SSM]] — SSM 提供 LZ 内安全远程访问 +- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] diff --git a/wiki/entities/AWS.md b/wiki/entities/AWS.md index 19d2b01c..01a71c50 100644 --- a/wiki/entities/AWS.md +++ b/wiki/entities/AWS.md @@ -5,8 +5,8 @@ tags: - AWS - Cloud - Hybrid-Cloud -sources: [cloud-operating-model-key-strategies-and-best-practices] -last_updated: 2026-04-25 +sources: [cloud-operating-model-key-strategies-and-best-practices, public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2] +last_updated: 2026-04-29 --- ## Amazon Web Services (AWS) @@ -30,7 +30,10 @@ Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted - [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]] - [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]] - [[VMware]] ← partners ← [[AWS]] +- [[AWS-Transit-Gateway-TGW]] ← 服务 ← [[AWS]] +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 平台 ← [[AWS]] ## Sources - [[ctp-topic-43-vmware-cloud-on-aws]] - [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md]] +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/entities/BrianReeves.md b/wiki/entities/BrianReeves.md new file mode 100644 index 00000000..fe7d3650 --- /dev/null +++ b/wiki/entities/BrianReeves.md @@ -0,0 +1,29 @@ +--- +title: "Brian Reeves" +type: entity +tags: + - VMware + - CTP + - Cloud +last_updated: 2026-05-07 +--- + +## Brian Reeves + +VMware speaker at Cloud Transformation Programme (CTP) learning sessions. Specializes in cloud economics and the business case for cloud migration. + +## Role +Speaker at CTP Topic 43 — VMware Cloud on AWS. Presented the economics perspective, highlighting that VMC on AWS offers 27% cost savings compared to regular cloud deployment. + +## Key Points Covered +- VMC on AWS cost model: VMware sells an entire host, enabling over-provisioning and cost reduction +- TCO comparison: Cloud economics team can perform total cost of ownership calculations to compare VMC on AWS against on-premises or other hyperscalers +- Business value: Positioned VMC on AWS as a middle ground for organizations not ready for full native cloud migration + +## Connections +- [[VMware]] ← speaker ← [[BrianReeves]] +- [[ctp-topic-43-vmware-cloud-on-aws]] ← presented_by ← [[BrianReeves]] +- [[VMware-Cloud-on-AWS]] ← discusses ← [[BrianReeves]] economics perspective + +## Sources +- [[ctp-topic-43-vmware-cloud-on-aws]] diff --git a/wiki/entities/Checkpoint-Firewall.md b/wiki/entities/Checkpoint-Firewall.md new file mode 100644 index 00000000..6fecbb8a --- /dev/null +++ b/wiki/entities/Checkpoint-Firewall.md @@ -0,0 +1,48 @@ +--- +title: "Checkpoint Firewall" +type: entity +tags: ["AWS", "Firewall", "Network-Security", "Checkpoint"] +sources: ["ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones", "ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] +last_updated: 2026-04-28 +--- + +## Overview +Checkpoint 是 Micro Focus AWS Landing Zone 网络架构中的核心防火墙设备，部署在 Network Account 中，负责管理所有互联网流量和跨区域网络隔离。 + +## Role in Landing Zone Architecture +- 集中管理 Landing Zone 与 On-prem 之间的所有网络流量 +- 启用 SPI（Stateful Packet Inspection）特性 +- 实施 Default Deny 策略：默认阻断所有流量，仅放行业务明确需要的服务和网段 + +## In CTP Topic 10 (Tagging & Security) +在 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中，Pradeep 演示了 Checkpoint 在 Frankfurt Landing Zone 中的标签驱动策略集： + +- **Policy Sets**：基于 AWS 资源标签（而非 IP 地址）的动态防火墙策略 +- **Ordered Layers**：按优先级顺序执行多层检查 + 1. 地理封锁（Geo-blocking） + 2. 类型检查（Type） + 3. 业务单元隔离（BU） + 4. 产品隔离（Product） + 5. 环境隔离（Environment） + 6. 服务器角色（Server Role） +- **Inline Layers**：基于账号编号的父子规则结构，简化跨账号规则管理 +- **Tag-Based Enforcement**：Demo 演示了 EC2 实例部署时标签缺失或错误导致流量被防火墙拦截的场景 +- **Default Deny + Inter-Product Policy**：默认阻断跨产品线通信，明确允许的通信需配置例外 + +## In CTP Topic 31 +在 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] 中： +- Checkpoint 作为网络隔离的执行设备，通过 SPI 阻断内部网络对 AWS 生产网段的直接访问 +- Default Deny 策略确保只有经过审批的服务和网络段能进入 Landing Zone +- 与 SSM 安全访问方案共同构成"网络隔离 + 终端访问"的双层安全体系 + +## Key Properties +| 属性 | 值 | +|------|-----| +| 类型 | Stateful Packet Inspection (SPI) Firewall | +| 部署位置 | Network Account | +| 策略模式 | Default Deny | +| 用途 | 互联网边界 + Landing Zone 隔离 | + +## Connections +- [[Network-Segmentation]] — Checkpoint 是网络隔离的核心实施工具 +- [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] diff --git a/wiki/entities/ChristianDeckelman.md b/wiki/entities/ChristianDeckelman.md new file mode 100644 index 00000000..1b62b993 --- /dev/null +++ b/wiki/entities/ChristianDeckelman.md @@ -0,0 +1,32 @@ +--- +title: "Christian Deckelman" +type: entity +tags: [AWS, Networking, WAN, CTP] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## Christian Deckelman + +Christian Deckelman 是 Micro Focus 的 IT 网络架构师，主导 AWS 云转型计划（Cloud Transformation Programme, CTP）中的广域网（WAN）架构设计与演进规划。 + +## Role + +- **Title**: IT 网络架构师（IT Network Architect） +- **Organization**: [[Micro Focus]] +- **Focus**: AWS Transit Gateway、SD-WAN、全球网络互联架构 + +## Key Contributions + +- 设计并阐述 AWS 云环境中跨区域全球网络架构——通过 Transit Gateway (TGW) 星型拓扑连接全球 Landing Zones +- 主导广域网演进路线图规划：从静态路由升级至 Silver Peak SD-WAN 叠加网络 +- 推动远程访问优化：Pulse VPN 迁移至 Palo Alto Prisma Access (SASE) + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 主讲 ← [[ChristianDeckelman]] +- [[Micro Focus]] ← 雇主 ← [[ChristianDeckelman]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/entities/Damian.md b/wiki/entities/Damian.md new file mode 100644 index 00000000..aa86f9cf --- /dev/null +++ b/wiki/entities/Damian.md @@ -0,0 +1,29 @@ +--- +title: "Damian" +type: entity +tags: [CTP, Cloud, AWS, Strategy] +sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] +last_updated: 2026-04-14 +--- + +## Damian + +Cloud Transformation Programme（CTP）系列学习课程讲师，主讲云转型战略与 POC 入职路径。 + +## Role + +- **CTP Topic 20**：程序需求流程（Program Demand Process Flow）与 POC 入职（PoC Onboarding）讲师（与 Sergio 联合主讲） +- 提及 Cloud Transformation Strategy Overview，关联 Matt 的战略优先级和整体愿景 + +## Areas of Expertise + +- 云转型战略与整体愿景规划 +- 需求来源分析（业务案例、高层战略优先级、产品路线图） +- POC 阶段的解决方案设计与 Design Authority 审批 +- 变更管理与组织调整 + +## Connections + +- 与 [[Sergio]] 联合主讲 [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] +- 通过 [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] 关联 [[Cloud-Transformation-Programme]] +- 引用 [[ctp-topic-53-why-bother-with-cloud]] 的背景参考 diff --git a/wiki/entities/Martin-Rosler.md b/wiki/entities/Martin-Rosler.md new file mode 100644 index 00000000..ac71de37 --- /dev/null +++ b/wiki/entities/Martin-Rosler.md @@ -0,0 +1,31 @@ +--- +title: "Martin Rosler" +type: entity +tags: + - person + - FinOps + - Tagging-Standard + - OpenText +sources: + - public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meeting-rec +last_updated: 2026-04-29 +--- + +# Martin Rosler + +OpenText/Micro Focus 云转型团队成员，FinOps 领域专家，主导 OpenText 标签标准 V2 版本的演讲和推广。 + +## Role & Contributions +- **标签标准 V2 演讲**：Martin Rosler 在 2026 年 4 月 29 日的 Public Cloud Learning Sessions 中介绍 OpenText Tagging Standard V2，强调标准化标签对云成本优化、风险降低和效率提升的价值 +- **三大驱动**：省钱（FinOps 成本优化）、降险（快速定位技术联系人）、提效（自动化筛选） +- **标准范围扩展**：V2 在 2023 年标准基础上，将 Kubernetes 对象和容器镜像纳入标签标准覆盖范围 + +## Key Rules & Best Practices +- 提倡使用 Terraform IaC 自动打标 +- 建议通过检查和报告检测缺失标签 +- 强调不在标签中存储敏感数据 +- 建议对频繁变更的标签谨慎处理 + +## Connections +- 隶属 [[Phenops-Team]] +- 与 [[public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meeting-rec]] 相关 diff --git a/wiki/entities/MichaelRiley.md b/wiki/entities/MichaelRiley.md new file mode 100644 index 00000000..ac0c1128 --- /dev/null +++ b/wiki/entities/MichaelRiley.md @@ -0,0 +1,23 @@ +--- +title: "Michael Riley" +type: entity +tags: + - VMware + - CTP + - Cloud +last_updated: 2026-05-07 +--- + +## Michael Riley + +VMware speaker at Cloud Transformation Programme (CTP) learning sessions. + +## Role +Speaker at CTP Topic 43 — VMware Cloud on AWS. Presented alongside Brian Reeves and Mike Armstrong on the VMC on AWS platform overview. + +## Connections +- [[VMware]] ← speaker ← [[MichaelRiley]] +- [[ctp-topic-43-vmware-cloud-on-aws]] ← presented_by ← [[MichaelRiley]] + +## Sources +- [[ctp-topic-43-vmware-cloud-on-aws]] diff --git a/wiki/entities/MicroFocus.md b/wiki/entities/MicroFocus.md new file mode 100644 index 00000000..aa7605d5 --- /dev/null +++ b/wiki/entities/MicroFocus.md @@ -0,0 +1,39 @@ +--- +title: "Micro Focus" +type: entity +tags: [Enterprise, ITOM, Cloud-Transformation, AWS] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## Micro Focus + +Micro Focus 是一家全球企业软件公司，专注于 IT Operations Management (ITOM)、DevOps、云转型等领域。在 AWS 云转型计划（Cloud Transformation Programme, CTP）中，Micro Focus 是主导企业，其 IT 网络架构由 Christian Deckelman 等专家设计全球广域网架构。 + +## Aliases + +- Micro Focus +- Micro Focus International + +## Role in Cloud Transformation Programme (CTP) + +- **主导企业**：Micro Focus 是 CTP 的核心推动者，涵盖从 Landing Zone 设计、网络架构到监控、备份的全套云转型方案 +- **网络架构**：由 IT 网络架构师 [[ChristianDeckelman]] 设计 AWS 全球广域网架构 +- **技术栈**：AWS Transit Gateway、Gruntwork Terraform 模块、Infoblox DNS、Pulse VPN、Checkpoint 防火墙 + +## Key CTP Topics Featuring Micro Focus + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] — WAN 架构设计 +- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] — Labs LZ 运维团队 +- [[ctp-topic-7-saas-landing-zone-design]] — SaaS Landing Zone 设计 +- [[ctp-topic-44-aws-backup-in-micro-focus]] — AWS Backup 实施 + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 主导企业 ← [[MicroFocus]] +- [[ChristianDeckelman]] ← 雇主 ← [[MicroFocus]] +- [[AWS]] ← 云平台 ← [[MicroFocus]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/entities/MikeArmstrong.md b/wiki/entities/MikeArmstrong.md new file mode 100644 index 00000000..d25b9896 --- /dev/null +++ b/wiki/entities/MikeArmstrong.md @@ -0,0 +1,23 @@ +--- +title: "Mike Armstrong" +type: entity +tags: + - VMware + - CTP + - Cloud +last_updated: 2026-05-07 +--- + +## Mike Armstrong + +VMware speaker at Cloud Transformation Programme (CTP) learning sessions. + +## Role +Speaker at CTP Topic 43 — VMware Cloud on AWS. Presented alongside Brian Reeves and Michael Riley on the VMC on AWS platform overview. + +## Connections +- [[VMware]] ← speaker ← [[MikeArmstrong]] +- [[ctp-topic-43-vmware-cloud-on-aws]] ← presented_by ← [[MikeArmstrong]] + +## Sources +- [[ctp-topic-43-vmware-cloud-on-aws]] diff --git a/wiki/entities/MikeOReily.md b/wiki/entities/MikeOReily.md new file mode 100644 index 00000000..17be60b3 --- /dev/null +++ b/wiki/entities/MikeOReily.md @@ -0,0 +1,30 @@ +--- +title: "Mike O'Reilly" +type: entity +tags: + - VMware + - CTP + - Cloud +last_updated: 2026-05-07 +--- + +## Mike O'Reilly + +Staff Cloud Solutions Architect at VMware. Primary technical presenter for VMC on AWS content at Cloud Transformation Programme (CTP) learning sessions. + +## Role +Staff Cloud Solutions Architect at VMware. Main technical speaker at CTP Topic 43 — VMware Cloud on AWS. Explained the joint engineering nature of VMC on AWS and demonstrated the platform capabilities. + +## Key Technical Points +- VMC on AWS is a jointly engineered cloud service where the VMware hypervisor runs natively on AWS bare metal servers — "not just something where VMware showed up at Amazon and dropped off a box of CDs" +- VMC on AWS runs vSphere 8 and provides native access to AWS services with low latency +- VMware and Amazon jointly manage the underlying infrastructure, allowing users to focus on their workloads +- Service is available across multiple regions and availability zones globally + +## Connections +- [[VMware]] ← speaker ← [[MikeOReily]] +- [[ctp-topic-43-vmware-cloud-on-aws]] ← presented_by ← [[MikeOReily]] +- [[VMware-Cloud-on-AWS]] ← explains ← [[MikeOReily]] technical architecture + +## Sources +- [[ctp-topic-43-vmware-cloud-on-aws]] diff --git a/wiki/entities/OpenText.md b/wiki/entities/OpenText.md new file mode 100644 index 00000000..ebb5ea81 --- /dev/null +++ b/wiki/entities/OpenText.md @@ -0,0 +1,53 @@ +--- +title: "OpenText" +type: entity +tags: [OpenText, Enterprise-Information-Management, Cloud-DevOps, Multi-Cloud, Software-Vendor] +sources: + - public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2 +last_updated: 2026-04-29 +--- + +## OpenText + +OpenText 是全球领先的企业信息管理（Enterprise Information Management，EIM）软件公司，专注于帮助组织管理、发现、分析和保护非结构化数据。2023年收购 Micro Focus 后成为全球最大的企业软件公司之一。 + +## Key Facts + +| 维度 | 说明 | +|------|------| +| 成立 | 1991年（加拿大滑铁卢） | +| 上市 | NASDAQ: OTEX, TSX: OTEX | +| 员工 | 约 23,000+ | +| 核心业务 | 企业内容管理、CRM、业务流程管理、安全与合规 | +| 战略方向 | 云优先（Cloud-First）、多云部署（AWS/GCP/Azure） | + +## Multi-Cloud Architecture + +OpenText 的产品和客户解决方案托管于三大超大规模云平台： + +- **AWS**：主要托管区域，用于产品和客户部署 +- **Google Cloud Platform (GCP)**：特定产品线和工作负载 +- **Microsoft Azure**：混合部署和企业客户专属环境 + +## OpenText Learning Sessions + +OpenText 内部开展了系统的"Public Cloud Learning Sessions"系列培训，涵盖： + +- **云架构**：Landing Zone、VPC 设计、网络分段 +- **运维实践**：DR/BCP、SRE、Observability、FinOps +- **开发运维**：CI/CD、IaC（Terraform）、容器化 +- **安全合规**：Tagging Standards、Identity Governance +- **产品平台**：Thor Platform、Product Hub (PHT) + +## Connections + +- [[AWS]] ← hosted_on ← [[OpenText]]（AWS 是 OpenText 主要托管平台之一） +- [[GCP]] ← hosted_on ← [[OpenText]]（GCP 托管 OpenText 特定产品线） +- [[Azure]] ← hosted_on ← [[OpenText]]（Azure 混合部署环境） +- [[MicroFocus]] ← acquired_by ← [[OpenText]]（2023 年完成收购） +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] ← source ← [[OpenText]] +- [[SRE]] ← implemented_by ← [[OpenText]]（OpenText 推行 SRE 转型） + +## Sources + +- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]] diff --git a/wiki/entities/PCGTeam.md b/wiki/entities/PCGTeam.md new file mode 100644 index 00000000..9c0ba646 --- /dev/null +++ b/wiki/entities/PCGTeam.md @@ -0,0 +1,37 @@ +--- +title: "PCG Team" +type: entity +tags: [CTP, Cloud, AWS, Platform] +sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] +last_updated: 2026-04-14 +--- + +## PCG Team + +Platform Control Group（PCG，平台控制组），是云转型计划（CTP）中负责提供云环境支持、安全策略制定及协助产品团队进行 POC 的核心技术团队。 + +## Role + +- **云环境支持**：为产品团队提供 AWS Landing Zone 环境的部署与运维支持 +- **安全策略制定**：定义和维护云环境的安全基线与合规标准 +- **POC 协助**：在概念验证阶段为产品团队提供技术指导和架构评审 + +## Responsibilities + +- 管理基于 Gruntwork 的 Landing Zone 参考架构 +- 提供 IaC（Terraform/Terragrunt）部署支持 +- 执行 Design Authority 审批（Gate 1），确保解决方案设计符合云原生原则 +- 定义 POC 成功标准，验证产品具备进入生产环境迁移的条件 + +## Key Deliverables + +- 预配置的标准化 Landing Zone 环境 +- 安全策略与合规基线 +- IaC 自动化部署流水线 +- 迁移时间表与路线图 + +## Connections + +- 为 [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] 提供 POC 支持 +- 与 [[Gruntwork]] 合作提供 Landing Zone 参考架构 +- 通过 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 提供架构基础 diff --git a/wiki/entities/PaloAltoNetworks.md b/wiki/entities/PaloAltoNetworks.md new file mode 100644 index 00000000..cd7f8e9f --- /dev/null +++ b/wiki/entities/PaloAltoNetworks.md @@ -0,0 +1,37 @@ +--- +title: "Palo Alto Networks" +type: entity +tags: [Security, SASE, SD-WAN, Networking, AWS] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## Palo Alto Networks + +Palo Alto Networks 是全球领先的网络安全公司，提供包括 Prisma Access 在内的云原生安全访问服务（SASE）。在 Micro Focus AWS 云转型计划中，其 Prisma Access 产品被选定为远程访问优化方案，替代传统的 Pulse VPN。 + +## Aliases + +- Palo Alto Networks +- PAN + +## Key Products Relevant to CTP + +- **Prisma Access**: 基于云的安全访问服务（SASE），用于替代传统 VPN，提供就近接入点和统一的安全策略 +- **Next-Generation Firewall (NGFW)**: 下一代防火墙产品线 + +## Role in CTP Architecture + +- 在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中被规划用于远程访问优化 +- 目标：将 Pulse VPN 迁移至 Prisma Access，通过在全球部署更多接入网关实现用户就近接入 +- 价值：显著降低访问延迟，并直接打通 SD-WAN 骨干网 + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 供应商 ← [[PaloAltoNetworks]] +- [[Prisma-Access]] ← 母公司 ← [[PaloAltoNetworks]] +- [[AWS]] ← 集成平台 ← [[PaloAltoNetworks]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/entities/Phenops-Team.md b/wiki/entities/Phenops-Team.md index 5be32394..e8d79b7d 100644 --- a/wiki/entities/Phenops-Team.md +++ b/wiki/entities/Phenops-Team.md @@ -1,30 +1,30 @@ ---- -title: "Phenops-Team" -type: entity -tags: - - team - - FinOps - - AWS -sources: - - public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123 - - public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco - - public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meeting-reco -last_updated: 2026-04-24 ---- - -# Phenops-Team - -OpenText/Micro Focus 内部 FinOps 执行团队，负责费率承诺计划的实施与云成本治理。 - -## Role & Contributions -- **标签治理**：2023 年发起云资源标签标准化项目（[[public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123]]），现已扩展至 Kubernetes 对象和容器镜像，覆盖 3,500 个云账户和 48 种 Landing Zone 类型 -- **费率承诺**：费率承诺计划（Savings Plans / Reserved Instances）的唯一实施团队（[[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]） - -## Key Rules -- 所有承诺计划仅支持 **无预付（No Upfront）** 选项 -- 最低交易金额：**$5k/年** -- 费率承诺实施前必须先完成 Right Sizing 分析 - -## Connections -- 隶属 [[PCG]]（Public Cloud Governance）团队 -- 与 [[Vinay]] 等 FinOps 团队成员协作推进成本优化 +--- +title: "Phenops-Team" +type: entity +tags: + - team + - FinOps + - AWS +sources: + - public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123 + - public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco + - public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meeting-rec +last_updated: 2026-04-29 +--- + +# Phenops-Team + +OpenText/Micro Focus 内部 FinOps 执行团队，负责费率承诺计划的实施与云成本治理。 + +## Role & Contributions +- **标签治理**：2023 年发起云资源标签标准化项目（[[public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123]]），现已扩展至 Kubernetes 对象和容器镜像，覆盖 3,500 个云账户和 48 种 Landing Zone 类型 +- **费率承诺**：费率承诺计划（Savings Plans / Reserved Instances）的唯一实施团队（[[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]]） + +## Key Rules +- 所有承诺计划仅支持 **无预付（No Upfront）** 选项 +- 最低交易金额：**$5k/年** +- 费率承诺实施前必须先完成 Right Sizing 分析 + +## Connections +- 隶属 [[PCG]]（Public Cloud Governance）团队 +- 与 [[Vinay]] 等 FinOps 团队成员协作推进成本优化 diff --git a/wiki/entities/Pradeep.md b/wiki/entities/Pradeep.md new file mode 100644 index 00000000..c426377c --- /dev/null +++ b/wiki/entities/Pradeep.md @@ -0,0 +1,26 @@ +--- +title: "Pradeep" +type: entity +tags: ["Cloud-Transformation", "AWS", "OpenText", "Demo"] +sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] +last_updated: 2026-04-28 +--- + +## Overview +Pradeep 是 OpenText/Micro Focus 云转型计划（CTP）的技术演示者，负责 Checkpoint Firewall 和 EC2 部署的实际操作演示。 + +## Contributions +- **CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]）：作为本主题的演示者，Pradeep 展示了： + - Frankfurt Landing Zone 中 Checkpoint Firewall 的策略配置界面 + - 基于标签的 Policy Sets 和 Ordered Layers 配置 + - EC2 实例部署时标签缺失或错误导致的防火墙拦截错误 + - Inline Layer 基于账号编号的父子规则结构 + +## Demonstrated Technologies +- [[Checkpoint-Firewall]] — 标签驱动的动态防火墙策略配置 +- [[AWS-Landing-Zone]] — EC2 部署与标签应用 +- [[SCP-Security-Control-Policy]] — 标签强制执行演示 + +## Connections +- [[Checkpoint-Firewall]] — 演示中的核心设备 +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] diff --git a/wiki/entities/Pulse-VPN.md b/wiki/entities/Pulse-VPN.md index 62172a8a..2519c2cf 100644 --- a/wiki/entities/Pulse-VPN.md +++ b/wiki/entities/Pulse-VPN.md @@ -35,6 +35,19 @@ last_updated: 2026-05-06 - Pulse Secure VPN - Pulse VPN Client +## Role in CTP Architecture + +- **现状**: 在 [[ctp-topic-7-saas-landing-zone-design]] 中作为 SAS LZ 标准远程访问 VPN +- **演进**: 在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中规划迁移至 [[PaloAltoNetworks]] [[Prisma-Access]]（SASE 方案） + ## Connections + - [[ctp-topic-7-saas-landing-zone-design]] — SAS LZ 远程接入方案 - [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] — 网络分段策略变更（Checkpoint 重新路由入站流量） +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] — 演进目标：迁移至 Prisma Access +- [[Prisma-Access]] ← 替代 ← [[Pulse-VPN]] + +## Sources + +- [[ctp-topic-7-saas-landing-zone-design]] +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/entities/Pushka.md b/wiki/entities/Pushka.md new file mode 100644 index 00000000..57e9f4c7 --- /dev/null +++ b/wiki/entities/Pushka.md @@ -0,0 +1,36 @@ +--- +title: "Pushka" +type: entity +tags: [] +sources: + - ctp-topic-45-automatic-ip-address-allocation-with-ipam + - ctp-topic-61-workload-vpc-provision-with-ipam-automation +last_updated: 2026-04-24 +--- + +## Pushka + +Principal SRE，Cloud Transformation Programme (CTP) 的核心讲师之一，IPAM 与 VPC 自动化方案的发起人和主要演示者。 + +## Role + +- **CTP Topic 45**：IPAM 自动分配 IP 地址机制详解——介绍 Infoblox NIOS 如何替代 Excel 手工管理，实现声明式 VPC IP 地址供给 +- **CTP Topic 61**：Workload VPC 完整自动化供给方案——展示端到端 VPC 供给流程，包括 CIDR 审批阈值和 AZ ID 等增强功能 + +## Areas of Expertise + +- Infoblox NIOS IPAM 平台与 AWS VPC 供给集成 +- 声明式 IaC 自动化（YAML 配置驱动） +- AWS 多账号网络架构 +- IP 地址管理生命周期 + +## Key Quotes + +> "We don't need to worry about IP address. If it's beyond IP address is 22 or greater, then only we need to take the approval." — CIDR 审批阈值说明 + +> "So we just need to put the information at the right place and everything will work." — IPAM 自动化核心理念 + +## Connections + +- 通过 [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] 介绍 IPAM 自动化机制 +- 通过 [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] 展示 VPC 供给完整应用 diff --git a/wiki/entities/SankarGopov.md b/wiki/entities/SankarGopov.md index c08d4e7a..0fa27e2a 100644 --- a/wiki/entities/SankarGopov.md +++ b/wiki/entities/SankarGopov.md @@ -1,28 +1,29 @@ ---- -title: "Sankar Gopov" -type: entity -tags: [] -sources: [] -last_updated: 2026-04-24 ---- - -## Sankar Gopov - -AWS 网络与混合云架构专家，Cloud Transformation Programme (CTP) 的核心讲师之一。 - -## Role - -- **CTP Topic 19**：AWS Landing Zone DNS 配置专题讲师 -- **CTP Topic 22**：Global DNS Service Offerings 讲师（与 Vino 联合主讲） - -## Areas of Expertise - -- AWS Landing Zone 多账号架构设计 -- Route 53 混合 DNS 架构（Inbound/Outbound Endpoints） -- 企业级 DNS 服务架构（Infoblox + Route 53） -- 跨账号 VPC 网络互联 - -## Connections - -- 通过 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 讲解 Landing Zone 内部 DNS 配置 -- 通过 [[ctp-topic-22-global-dns-service-offerings]] 讲解企业级全局 DNS 架构 +--- +title: "Sankar Gopov" +type: entity +tags: [] +sources: + - ctp-topic-19-configuring-dns-within-aws-lzs +last_updated: 2026-04-28 +--- + +## Sankar Gopov + +AWS 网络与混合云架构专家，Cloud Transformation Programme (CTP) 的核心讲师之一。 + +## Role + +- **CTP Topic 19**：AWS Landing Zone DNS 配置专题讲师 +- **CTP Topic 22**：Global DNS Service Offerings 讲师（与 Vino 联合主讲） + +## Areas of Expertise + +- AWS Landing Zone 多账号架构设计 +- Route 53 混合 DNS 架构（Inbound/Outbound Endpoints） +- 企业级 DNS 服务架构（Infoblox + Route 53） +- 跨账号 VPC 网络互联 + +## Connections + +- 通过 [[ctp-topic-19-configuring-dns-within-aws-lzs]] 讲解 Landing Zone 内部 DNS 配置 +- 通过 [[ctp-topic-22-global-dns-service-offerings]] 讲解企业级全局 DNS 架构 diff --git a/wiki/entities/Sergio.md b/wiki/entities/Sergio.md new file mode 100644 index 00000000..61375987 --- /dev/null +++ b/wiki/entities/Sergio.md @@ -0,0 +1,28 @@ +--- +title: "Sergio" +type: entity +tags: [CTP, Cloud, AWS, DevOps] +sources: [ctp-topic-20-program-demand-process-flow-and-poc-onboarding] +last_updated: 2026-04-14 +--- + +## Sergio + +Cloud Transformation Programme（CTP）系列学习课程讲师，主讲云转型项目的需求流程与 POC 入职路径。 + +## Role + +- **CTP Topic 20**：程序需求流程（Program Demand Process Flow）与 POC 入职（PoC Onboarding）讲师（与 Damian 联合主讲） +- 专注于云迁移的治理框架、需求管理与概念验证实施路径 + +## Areas of Expertise + +- 企业级云迁移需求管理与优先级排序 +- 概念验证（POC）实施路径与 Gate Process 审批流程 +- 基于 Gruntwork 的 Landing Zone 架构实践 +- IaC（Terraform/Terragrunt）自动化部署 + +## Connections + +- 与 [[Damian]] 联合主讲 [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] +- 通过该课程与 [[ctp-topic-57-product-backlog-managing-demand]] 共享需求管理主题 diff --git a/wiki/entities/SilverPeak.md b/wiki/entities/SilverPeak.md new file mode 100644 index 00000000..fb1e2ecb --- /dev/null +++ b/wiki/entities/SilverPeak.md @@ -0,0 +1,36 @@ +--- +title: "Silver Peak" +type: entity +tags: [SD-WAN, Networking, WAN, Overlay] +sources: [ctp-topic-18-wide-area-networking-in-aws-cloud] +last_updated: 2026-05-07 +--- + +## Silver Peak + +Silver Peak 是一家专注于 SD-WAN（Software-Defined Wide Area Network）解决方案的技术公司，2020年被 HP (Hewlett Packard Enterprise) 收购。其 SD-WAN 产品作为叠加网络（Overlay Network）解决方案，计划在 Micro Focus AWS 云转型中被引入，用于替代静态路由实现动态路径选择和自动化流量调度。 + +## Aliases + +- Silver Peak +- Silver Peak Systems + +## Key Product + +- **Silver Peak SD-WAN**: 软件定义广域网解决方案，通过在 AWS 中部署虚拟 SD-WAN 设备，实现动态路径选择和自动化流量调度 + +## Role in CTP Architecture + +- 在 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 中被规划为 Transit Gateway 架构的演进方案 +- 目标：解决 TGW 间静态路由在 DR 场景下需要人工干预的局限性 +- 部署模式：在 AWS 中部署虚拟 SD-WAN 设备作为叠加网络层 + +## Connections + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← 供应商 ← [[SilverPeak]] +- [[SD-WAN]] ← 提供商 ← [[SilverPeak]] +- [[AWS]] ← 部署平台 ← [[SilverPeak]] + +## Sources + +- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] diff --git a/wiki/entities/SteveJarman.md b/wiki/entities/SteveJarman.md new file mode 100644 index 00000000..5e639b85 --- /dev/null +++ b/wiki/entities/SteveJarman.md @@ -0,0 +1,18 @@ +--- +title: "Steve Jarman" +type: entity +tags: ["Cloud-Transformation", "AWS", "OpenText"] +sources: ["ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security"] +last_updated: 2026-04-28 +--- + +## Overview +Steve Jarman 是 OpenText/Micro Focus 云转型计划（CTP）的核心技术演讲者之一，在 AWS Landing Zone 主题系列中多次主讲。 + +## Contributions +- **CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]）：与 Pradeep 联合主讲，深入阐述 AWS Landing Zone 的数据收集、标签体系及基于标签的云原生安全架构。Steve 强调在将资产迁移至云之前必须先收集机器信息、理解迁移范围、应用正确标签，以确保云环境的安全 posture 正确。 + +## Connections +- [[AWS-Landing-Zone]] — 核心演讲主题 +- [[Cloud-Transformation-Programme]] — 云转型计划演讲者 +- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] diff --git a/wiki/entities/Vinaya.md b/wiki/entities/Vinaya.md new file mode 100644 index 00000000..0c013e4a --- /dev/null +++ b/wiki/entities/Vinaya.md @@ -0,0 +1,20 @@ +--- +title: "Vinaya" +type: entity +tags: [Product-Teams, Self-Healing, SRE, Cloud-Transformation] +last_updated: 2026-04-28 +--- + +## Overview + +Vinaya 是内部产品团队成员，在云转型项目中活跃参与 SRE 实践推广。在 CTP Topic 30（Managing Change）会议中，Vinaya 提议各产品组分享现有的 Self-Healing 实践案例，由 SRE 团队协助在监控产品中落地。 + +## Role in Cloud Transformation + +- **Self-Healing 推广者**：Vinaya 认识到 Self-Healing（基于 ML 的自动化监控系统）是未来演进方向，积极推动产品团队间的经验分享 +- **SRE 协作桥梁**：作为产品团队代表，与 SRE 团队（由 Brendan Starnig 领导）建立协作关系 +- **自动化倡导者**：支持通过机器学习驱动的自动化监控系统，基于告警趋势自动决策和缓解问题 + +## Sources + +- [[ctp-topic-30-managing-change]] diff --git a/wiki/entities/cloud-transformation-programme.md b/wiki/entities/cloud-transformation-programme.md new file mode 100644 index 00000000..d1feaa1e --- /dev/null +++ b/wiki/entities/cloud-transformation-programme.md @@ -0,0 +1,33 @@ +--- +title: "Cloud Transformation Programme (CTP)" +type: entity +entity_type: Project +tags: + - Cloud-Transformation + - OpenText + - CTP + - AWS +sources: + - ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation +last_updated: 2026-04-28 +--- + +## Description + +OpenText 的 Cloud Transformation Programme（云转型计划，简称 CTP）是一个跨多个业务单元的系统性云迁移与转型项目，旨在将传统本地基础设施迁移至 AWS 等公有云平台，并通过 [[Lean]] 方法论和 [[Scaled Agile]] 框架实现价值最大化交付。 + +## Related Concepts + +- [[Value Stream]]：CTP 的工作组织方式 +- [[Weighted Shortest Job First (WSJF)]]：CTP 工作的优先级排序方法 +- [[Cost of Delay (CoD)]]：CTP 价值评估的核心指标 + +## Related Sources + +- [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]] +- （其他 CTP Topic source pages，见 index.md） + +## Aliases +- CTP +- Cloud Transformation Programme +- 云转型计划 diff --git a/wiki/index.md b/wiki/index.md index 5ed57643..6d5331de 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,6 +4,20 @@ - [Overview](overview.md) — living synthesis ## Sources +- [2026-04-28] [CTP Topic 41 NFR's and Error Budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md) +- [2026-04-28] [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) +- [2026-04-28] [CTP Topic 20 Program demand process flow and PoC onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md) +- [2026-04-28] [CTP Topic 4 Using Agile to Run the Cloud Transformation Programme](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md) +- [2026-04-28] [CTP Topic 65 Tracing the Value Delivered in Cloud Transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md) +- [2026-04-28] [Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723](sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md) +- [2026-04-28] [CTP Topic 30 Managing Change](sources/ctp-topic-30-managing-change.md) +- [2026-04-28] [CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS](sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md) +- [2026-04-28] [CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones](sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md) +- [2026-04-28] [CTP Topic 18 Wide Area Networking in AWS Cloud](sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md) +- [2026-04-28] [CTP Topic 43 VMware Cloud on AWS](sources/ctp-topic-43-vmware-cloud-on-aws.md) +- [2026-04-28] [CTP Topic 61 Workload VPC Provision with IPAM Automation](sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md) +- [2026-04-28] [CTP Topic 45 Automatic IP Address Allocation with IPAM](sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md) +- [2026-04-28] [CTP Topic 19 Configuring DNS within AWS LZs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md) - [2026-04-28] [CTP Topic 36 SendGrid as an Email Service](sources/ctp-topic-36-sendgrid-as-an-email-service.md) - [2026-04-28] [CTP Topic 22 Global DNS service offerings](sources/ctp-topic-22-global-dns-service-offerings.md) - [2026-04-28] [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) @@ -228,32 +242,18 @@ - [Public Cloud Learning Sessions - OpenText Tagging Standard v2 - 20250429](sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md) - [Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806](sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md) - [Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration](sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md) -- [Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723](sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md) - [Public Cloud Learning Sessions - AWS End User Compute Services - 20240430](sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md) - [Public Cloud Learning Sessions- Applicable Business Analysis Techniques - 20240109](sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md) -- [CTP Topic 65 Tracing the Value Delivered in Cloud Transformation](sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md) - [CTP Topic 6 AWS Workspaces Demo](sources/ctp-topic-6-aws-workspaces-demo.md) - [CTP Topic 57 Product backlog managing demand](sources/ctp-topic-57-product-backlog-managing-demand.md) - [CTP Topic 53 Why bother with Cloud](sources/ctp-topic-53-why-bother-with-cloud.md) -- [CTP Topic 41 NFR's and Error Budgets](sources/ctp-topic-41-nfrs-and-error-budgets.md) -- [CTP Topic 4 Using Agile to Run the Cloud Transformation Programme](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md) -- [CTP Topic 30 Managing Change](sources/ctp-topic-30-managing-change.md) - [CTP Topic 23 Introduction to the Technical Architecture Team and Function](sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md) -- [CTP Topic 20 Program demand process flow and PoC onboarding](sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md) -- [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) - [Public Cloud Learning Sessions - Serverless Computing - 20240903](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md) - [Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md) - [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md) - [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md) - [Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md) - [Public Cloud Learning Sessions - Introduction to AI/ML with AWS](sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md) -- [CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS](sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md) -- [CTP Topic 61 Workload VPC provision with IPAM Automation](sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md) -- [CTP Topic 45 Automatic IP address allocation with IPAM](sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md) -- [CTP Topic 43 VMware Cloud on AWS](sources/ctp-topic-43-vmware-cloud-on-aws.md) -- [CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones](sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md) -- [CTP Topic 19 Configuring DNS within AWS LZs](sources/ctp-topic-19-configuring-dns-within-aws-lzs.md) -- [CTP Topic 18 Wide Area Networking in AWS Cloud](sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md) - [Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015](sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md) - [CTP Topic 62 AWS Secrets Manager](sources/ctp-topic-62-aws-secrets-manager.md) - [CTP Topic 55 AWS Firewall Manager](sources/ctp-topic-55-aws-firewall-manager.md) @@ -576,6 +576,7 @@ - [AWS-Backup-Audit-Manager](entities/AWS-Backup-Audit-Manager.md) - [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md) - [AWS-Lambda](entities/AWS-Lambda.md) +- [AWS-Landing-Zone](entities/AWS-Landing-Zone.md) - [AWS-OpenSearch](entities/AWS-OpenSearch.md) - [AWS-Organizations](entities/AWS-Organizations.md) - [AWS-SSM](entities/AWS-SSM.md) @@ -595,6 +596,7 @@ - [Bottlerocket](entities/Bottlerocket.md) - [bottom](entities/bottom.md) - [Brendan-Starnig](entities/Brendan-Starnig.md) +- [BrianReeves](entities/BrianReeves.md) - [Brightdata](entities/Brightdata.md) - [btop++](entities/btop++.md) - [Caddy](entities/Caddy.md) @@ -605,8 +607,10 @@ - [CCOE](entities/CCOE.md) - [ChatGPT](entities/ChatGPT.md) - [Checkpoint](entities/Checkpoint.md) +- [Checkpoint-Firewall](entities/Checkpoint-Firewall.md) - [ChinesePodcastPlatforms](entities/ChinesePodcastPlatforms.md) - [Choi-Wontak](entities/Choi-Wontak.md) +- [ChristianDeckelman](entities/ChristianDeckelman.md) - [Claude-Code](entities/Claude-Code.md) - [Claude-Desktop](entities/Claude-Desktop.md) - [Claude-Pro](entities/Claude-Pro.md) @@ -619,6 +623,7 @@ - [Cloud-Maturity-Model](entities/Cloud-Maturity-Model.md) - [Cloud-Provider](entities/Cloud-Provider.md) - [Cloud-Technology-Design-Forum](entities/Cloud-Technology-Design-Forum.md) +- [cloud-transformation-programme](entities/cloud-transformation-programme.md) - [clouddrive2](entities/clouddrive2.md) - [CloudFront](entities/CloudFront.md) - [CodeCrafters](entities/CodeCrafters.md) @@ -631,6 +636,7 @@ - [CrewAI](entities/CrewAI.md) - [Cursor](entities/Cursor.md) - [Curve-Finance](entities/Curve-Finance.md) +- [Damian](entities/Damian.md) - [DanielStefanovic](entities/DanielStefanovic.md) - [Databunker](entities/Databunker.md) - [DataviewPlugin](entities/DataviewPlugin.md) @@ -744,11 +750,15 @@ - [Memsearch](entities/Memsearch.md) - [MerlinClash插件](entities/MerlinClash插件.md) - [Meta-Ads-Manager](entities/Meta-Ads-Manager.md) +- [MichaelRiley](entities/MichaelRiley.md) - [Micro-Focus](entities/Micro-Focus.md) - [Micro-Focus-IGA](entities/Micro-Focus-IGA.md) +- [MicroFocus](entities/MicroFocus.md) - [Microsoft-Planner](entities/Microsoft-Planner.md) - [MicrosoftAdvertising](entities/MicrosoftAdvertising.md) - [Midjourney](entities/Midjourney.md) +- [MikeArmstrong](entities/MikeArmstrong.md) +- [MikeOReily](entities/MikeOReily.md) - [Milvus](entities/Milvus.md) - [MinIO](entities/MinIO.md) - [mission-center](entities/mission-center.md) @@ -787,9 +797,12 @@ - [OpenCode](entities/OpenCode.md) - [OpenManus](entities/OpenManus.md) - [OpenNotebook](entities/OpenNotebook.md) +- [OpenText](entities/OpenText.md) - [OrchestratorAgent](entities/OrchestratorAgent.md) - [OWASP](entities/OWASP.md) - [PageLM](entities/PageLM.md) +- [PaloAltoNetworks](entities/PaloAltoNetworks.md) +- [PCGTeam](entities/PCGTeam.md) - [Peloton](entities/Peloton.md) - [Perplexica](entities/Perplexica.md) - [Phenops-Team](entities/Phenops-Team.md) @@ -797,6 +810,7 @@ - [Playwright](entities/Playwright.md) - [Podcastfy](entities/Podcastfy.md) - [Portainer](entities/Portainer.md) +- [Pradeep](entities/Pradeep.md) - [Prismer](entities/Prismer.md) - [Prismer-AI](entities/Prismer-AI.md) - [Product-Security-Group](entities/Product-Security-Group.md) @@ -804,6 +818,7 @@ - [Prometheus](entities/Prometheus.md) - [Public-Cloud-Provider](entities/Public-Cloud-Provider.md) - [Pulse-VPN](entities/Pulse-VPN.md) +- [Pushka](entities/Pushka.md) - [Qalis](entities/Qalis.md) - [QALIS-Agent](entities/QALIS-Agent.md) - [Qdrant](entities/Qdrant.md) @@ -830,7 +845,9 @@ - [SankarGopov](entities/SankarGopov.md) - [Scrapy](entities/Scrapy.md) - [Sentinel-1](entities/Sentinel-1.md) +- [Sergio](entities/Sergio.md) - [shenwei](entities/shenwei.md) +- [SilverPeak](entities/SilverPeak.md) - [Simon-Hoiberg](entities/Simon-Hoiberg.md) - [Slack](entities/Slack.md) - [SMACKS](entities/SMACKS.md) @@ -843,6 +860,7 @@ - [SSE](entities/SSE.md) - [Stable-Diffusion](entities/Stable-Diffusion.md) - [stacer](entities/stacer.md) +- [SteveJarman](entities/SteveJarman.md) - [Studio-Producer](entities/Studio-Producer.md) - [Supermemory](entities/Supermemory.md) - [Suravpul](entities/Suravpul.md) @@ -888,6 +906,7 @@ - [VictoriaMetrics](entities/VictoriaMetrics.md) - [Vidu](entities/Vidu.md) - [Vinay](entities/Vinay.md) +- [Vinaya](entities/Vinaya.md) - [VinoCTP](entities/VinoCTP.md) - [vLLM](entities/vLLM.md) - [VMware](entities/VMware.md) @@ -1021,6 +1040,7 @@ - [AutomatedReminders](concepts/AutomatedReminders.md) - [AutomationGovernance](concepts/AutomationGovernance.md) - [Availability](concepts/Availability.md) +- [Availability-Zone-ID](concepts/Availability-Zone-ID.md) - [AWS-Backup-Concepts](concepts/AWS-Backup-Concepts.md) - [AWS-Inspector](concepts/AWS-Inspector.md) - [AWS-Secrets-Manager](concepts/AWS-Secrets-Manager.md) @@ -1081,6 +1101,7 @@ - [Choice-Architecture](concepts/Choice-Architecture.md) - [CI-CD-Pipeline](concepts/CI-CD-Pipeline.md) - [CICDPipeline](concepts/CICDPipeline.md) +- [CIDR-审批流程](concepts/CIDR-审批流程.md) - [CircuitBreaker](concepts/CircuitBreaker.md) - [CIS-Benchmark](concepts/CIS-Benchmark.md) - [Citation-Rate](concepts/Citation-Rate.md) @@ -1147,6 +1168,7 @@ - [Conversational-Interface](concepts/Conversational-Interface.md) - [Conversions-API](concepts/Conversions-API.md) - [Core-Gameplay-Loop](concepts/Core-Gameplay-Loop.md) +- [cost-of-delay](concepts/cost-of-delay.md) - [Cost-Optimization](concepts/Cost-Optimization.md) - [Cowork-UI](concepts/Cowork-UI.md) - [CoworkWorkspace](concepts/CoworkWorkspace.md) @@ -1161,6 +1183,7 @@ - [Cumulative-Memory](concepts/Cumulative-Memory.md) - [Custom-Audience-Engineering](concepts/Custom-Audience-Engineering.md) - [Custom-Instructions](concepts/Custom-Instructions.md) +- [Customer-Zero](concepts/Customer-Zero.md) - [Daily-Digest](concepts/Daily-Digest.md) - [Daily-Journaling](concepts/Daily-Journaling.md) - [Daily-Log](concepts/Daily-Log.md) @@ -1191,6 +1214,7 @@ - [DevOpsCulture](concepts/DevOpsCulture.md) - [DevSecOps](concepts/DevSecOps.md) - [Dialogue-Writing-Standards](concepts/Dialogue-Writing-Standards.md) +- [Disaster-Recovery](concepts/Disaster-Recovery.md) - [Discrimination-Metrics](concepts/Discrimination-Metrics.md) - [Distribution-Key](concepts/Distribution-Key.md) - [DKIM-Email-Authentication](concepts/DKIM-Email-Authentication.md) @@ -1274,6 +1298,7 @@ - [Fuzzy-Matching](concepts/Fuzzy-Matching.md) - [Gamification](concepts/Gamification.md) - [GAS-Gameplay-Ability-System](concepts/GAS-Gameplay-Ability-System.md) +- [Gate-Process](concepts/Gate-Process.md) - [Gatekeeper](concepts/Gatekeeper.md) - [GDM3](concepts/GDM3.md) - [Gegenrede](concepts/Gegenrede.md) @@ -1314,6 +1339,7 @@ - [Host-Incubation-System](concepts/Host-Incubation-System.md) - [HouseholdInventoryTracking](concepts/HouseholdInventoryTracking.md) - [HTTPS自动化证书](concepts/HTTPS自动化证书.md) +- [Hub-and-Spoke](concepts/Hub-and-Spoke.md) - [Human-Centered-Design](concepts/Human-Centered-Design.md) - [Human-Handoff](concepts/Human-Handoff.md) - [Hybrid-Cloud](concepts/Hybrid-Cloud.md) @@ -1339,7 +1365,10 @@ - [Incremental-Indexing](concepts/Incremental-Indexing.md) - [Incrementality-Testing](concepts/Incrementality-Testing.md) - [Indexing](concepts/Indexing.md) +- [Infoblox-Grid](concepts/Infoblox-Grid.md) +- [Infoblox-NIOS](concepts/Infoblox-NIOS.md) - [Infrastructure-as-Code](concepts/Infrastructure-as-Code.md) +- [Inline-Layer](concepts/Inline-Layer.md) - [Innovation-Pipeline](concepts/Innovation-Pipeline.md) - [IntegrationGovernance](concepts/IntegrationGovernance.md) - [Intent-Classification](concepts/Intent-Classification.md) @@ -1347,6 +1376,7 @@ - [Intentional-Cloud-Strategy](concepts/Intentional-Cloud-Strategy.md) - [Inversion](concepts/Inversion.md) - [Invisible-Exclusion](concepts/Invisible-Exclusion.md) +- [IPAM](concepts/IPAM.md) - [IP纯净度](concepts/IP纯净度.md) - [ISOHybrid镜像](concepts/ISOHybrid镜像.md) - [ITSM](concepts/ITSM.md) @@ -1477,9 +1507,11 @@ - [OpenClaw-Deployment-Expert](concepts/OpenClaw-Deployment-Expert.md) - [OpenTelemetry](concepts/OpenTelemetry.md) - [Oracle-Manipulation](concepts/Oracle-Manipulation.md) +- [Ordered-Layer](concepts/Ordered-Layer.md) - [Organic-Traffic-Amplification](concepts/Organic-Traffic-Amplification.md) - [OS-End-of-Life](concepts/OS-End-of-Life.md) - [OS-Hardening](concepts/OS-Hardening.md) +- [Overlay-Network](concepts/Overlay-Network.md) - [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md) - [Pacing-Architecture](concepts/Pacing-Architecture.md) - [PagedAttention](concepts/PagedAttention.md) @@ -1525,8 +1557,10 @@ - [Pre-Build-Validation](concepts/Pre-Build-Validation.md) - [PreBuildValidation](concepts/PreBuildValidation.md) - [Predictive-Maintenance](concepts/Predictive-Maintenance.md) +- [Prisma-Access](concepts/Prisma-Access.md) - [Private-Cloud](concepts/Private-Cloud.md) - [Private-Context](concepts/Private-Context.md) +- [Private-Hosted-Zone](concepts/Private-Hosted-Zone.md) - [Private-Subnet-Architecture](concepts/Private-Subnet-Architecture.md) - [Proactive-Agent-Recommendation](concepts/Proactive-Agent-Recommendation.md) - [Proactive-AI](concepts/Proactive-AI.md) @@ -1535,11 +1569,13 @@ - [Procedural-Level-Design](concepts/Procedural-Level-Design.md) - [process-management](concepts/process-management.md) - [ProductLedGrowth](concepts/ProductLedGrowth.md) +- [Program-Demand-Process](concepts/Program-Demand-Process.md) - [Progressive-Rollout](concepts/Progressive-Rollout.md) - [ProjectState](concepts/ProjectState.md) - [Prometheus告警规则](concepts/Prometheus告警规则.md) - [Prompt](concepts/Prompt.md) - [PromQL](concepts/PromQL.md) +- [Proof-of-Concept](concepts/Proof-of-Concept.md) - [Propp-Morphology](concepts/Propp-Morphology.md) - [Proxy-Editing](concepts/Proxy-Editing.md) - [proxychains](concepts/proxychains.md) @@ -1560,6 +1596,7 @@ - [RealitySignal](concepts/RealitySignal.md) - [ReAuditTriggers](concepts/ReAuditTriggers.md) - [Reciprocal-Rank-Fusion](concepts/Reciprocal-Rank-Fusion.md) +- [Recovery-Assurance](concepts/Recovery-Assurance.md) - [RecruitmentFunnelAnalyzer](concepts/RecruitmentFunnelAnalyzer.md) - [Recurrence-Count](concepts/Recurrence-Count.md) - [Recurring-Task](concepts/Recurring-Task.md) @@ -1577,7 +1614,9 @@ - [RemoteRescuePattern](concepts/RemoteRescuePattern.md) - [Renovate-Bot](concepts/Renovate-Bot.md) - [Replication-Graph](concepts/Replication-Graph.md) +- [Resolver-Rules](concepts/Resolver-Rules.md) - [Resource-Allocation](concepts/Resource-Allocation.md) +- [Resource-Tagging](concepts/Resource-Tagging.md) - [ResponsiveSearchAds](concepts/ResponsiveSearchAds.md) - [Retrieval](concepts/Retrieval.md) - [Reviewer](concepts/Reviewer.md) @@ -1588,6 +1627,7 @@ - [ROI](concepts/ROI.md) - [Rollback-Rate](concepts/Rollback-Rate.md) - [Root-Cause-Analysis](concepts/Root-Cause-Analysis.md) +- [Route-53-Resolver](concepts/Route-53-Resolver.md) - [RPC-Remote-Procedure-Call](concepts/RPC-Remote-Procedure-Call.md) - [RPO](concepts/RPO.md) - [RRF-Reranking](concepts/RRF-Reranking.md) @@ -1605,8 +1645,10 @@ - [Scheduled-Task-Flywheel](concepts/Scheduled-Task-Flywheel.md) - [ScheduledReport](concepts/ScheduledReport.md) - [Scholar-Skill](concepts/Scholar-Skill.md) +- [SCP-Security-Control-Policy](concepts/SCP-Security-Control-Policy.md) - [SCRM](concepts/SCRM.md) - [Scrum](concepts/Scrum.md) +- [SD-WAN](concepts/SD-WAN.md) - [SDDC](concepts/SDDC.md) - [SE-Linux-Enforcing](concepts/SE-Linux-Enforcing.md) - [Second-Renaissance](concepts/Second-Renaissance.md) @@ -1614,6 +1656,7 @@ - [Secure-Dynamic-Updates](concepts/Secure-Dynamic-Updates.md) - [Security-and-Compliance](concepts/Security-and-Compliance.md) - [Self-Education](concepts/Self-Education.md) +- [Self-Healing](concepts/Self-Healing.md) - [Self-Healing-Systems](concepts/Self-Healing-Systems.md) - [self-hosted-password-manager](concepts/self-hosted-password-manager.md) - [Self-Improving-Skill](concepts/Self-Improving-Skill.md) @@ -1633,6 +1676,7 @@ - [ServerAuthority](concepts/ServerAuthority.md) - [Serverless-Computing](concepts/Serverless-Computing.md) - [Service-Control-Policies-SCPs](concepts/Service-Control-Policies-SCPs.md) +- [serviceable-obtainable-market](concepts/serviceable-obtainable-market.md) - [SES-Sandbox-Mode](concepts/SES-Sandbox-Mode.md) - [Shader](concepts/Shader.md) - [ShadowTraffic](concepts/ShadowTraffic.md) @@ -1648,6 +1692,7 @@ - [Six-Sigma](concepts/Six-Sigma.md) - [SKAdNetwork](concepts/SKAdNetwork.md) - [SkillToolset](concepts/SkillToolset.md) +- [SLR](concepts/SLR.md) - [SLS](concepts/SLS.md) - [SmartBidding](concepts/SmartBidding.md) - [SnapMirror](concepts/SnapMirror.md) @@ -1658,6 +1703,7 @@ - [Software-Assurance-Maturity-Model](concepts/Software-Assurance-Maturity-Model.md) - [Software-Factory](concepts/Software-Factory.md) - [Solution-Architecture](concepts/Solution-Architecture.md) +- [Solution-Design](concepts/Solution-Design.md) - [Sort-Key](concepts/Sort-Key.md) - [SOUL.md](concepts/SOUL.md.md) - [Source-Grounding](concepts/Source-Grounding.md) @@ -1672,6 +1718,7 @@ - [Spot-Instances](concepts/Spot-Instances.md) - [SPREAD-Strategy](concepts/SPREAD-Strategy.md) - [SprintPlanning](concepts/SprintPlanning.md) +- [SRE](concepts/SRE.md) - [SSE-Server-Sent-Events](concepts/SSE-Server-Sent-Events.md) - [SSM-Patching](concepts/SSM-Patching.md) - [StackSets-Deployment-Visibility](concepts/StackSets-Deployment-Visibility.md) @@ -1679,6 +1726,7 @@ - [Standard-Change](concepts/Standard-Change.md) - [STARFramework](concepts/STARFramework.md) - [Startup-MVP-Pipeline](concepts/Startup-MVP-Pipeline.md) +- [Static-Routing](concepts/Static-Routing.md) - [Statistical-Process-Control](concepts/Statistical-Process-Control.md) - [Strategic-Portfolio-Management](concepts/Strategic-Portfolio-Management.md) - [Strategic-Question-Answer](concepts/Strategic-Question-Answer.md) @@ -1706,6 +1754,7 @@ - [TaskQuerySyntax](concepts/TaskQuerySyntax.md) - [TaskVisibility](concepts/TaskVisibility.md) - [Taylorism](concepts/Taylorism.md) +- [TCO](concepts/TCO.md) - [TCP隧道](concepts/TCP隧道.md) - [Technical-Architecture](concepts/Technical-Architecture.md) - [Technical-Objection-Handling](concepts/Technical-Objection-Handling.md) @@ -1719,6 +1768,7 @@ - [Text-and-Search](concepts/Text-and-Search.md) - [TextToSpeech](concepts/TextToSpeech.md) - [TextToVideo](concepts/TextToVideo.md) +- [TGW-Peering](concepts/TGW-Peering.md) - [Thought-Leadership](concepts/Thought-Leadership.md) - [Threat-Modeling](concepts/Threat-Modeling.md) - [Three-Tier-Review-Mechanism](concepts/Three-Tier-Review-Mechanism.md) @@ -1758,6 +1808,7 @@ - [UnityLobby](concepts/UnityLobby.md) - [UnityRelay](concepts/UnityRelay.md) - [USER.md](concepts/USER.md.md) +- [value-stream](concepts/value-stream.md) - [Value-Stream-Mapping](concepts/Value-Stream-Mapping.md) - [Variables-YAML](concepts/Variables-YAML.md) - [Vector-Embedding](concepts/Vector-Embedding.md) @@ -1773,7 +1824,9 @@ - [VMware-Cloud-on-AWS](concepts/VMware-Cloud-on-AWS.md) - [Voice-Interface](concepts/Voice-Interface.md) - [Voice-Notification-Channel](concepts/Voice-Notification-Channel.md) +- [VPC-Association-Authorization](concepts/VPC-Association-Authorization.md) - [VPC-Endpoint](concepts/VPC-Endpoint.md) +- [VPC-自动化供给](concepts/VPC-自动化供给.md) - [Vulnerability-Scanning](concepts/Vulnerability-Scanning.md) - [WAF-Web-Application-Firewall](concepts/WAF-Web-Application-Firewall.md) - [Wake-on-LAN](concepts/Wake-on-LAN.md) @@ -1786,6 +1839,7 @@ - [WebXR](concepts/WebXR.md) - [Weekly-Pattern-Analysis](concepts/Weekly-Pattern-Analysis.md) - [WeeklyPatternAnalysis](concepts/WeeklyPatternAnalysis.md) +- [weighted-shortest-job-first](concepts/weighted-shortest-job-first.md) - [What-If-Simulation](concepts/What-If-Simulation.md) - [WinThemes](concepts/WinThemes.md) - [Workflow-Engineering](concepts/Workflow-Engineering.md) @@ -1801,6 +1855,7 @@ - [YouTube-Data-API-v3](concepts/YouTube-Data-API-v3.md) - [Zero-Friction-Capture](concepts/Zero-Friction-Capture.md) - [Zero-Trust](concepts/Zero-Trust.md) +- [Zero-Trust-Access](concepts/Zero-Trust-Access.md) - [Zero-Trust-Architecture](concepts/Zero-Trust-Architecture.md) - [Zettelkasten](concepts/Zettelkasten.md) - [一人公司](concepts/一人公司.md) diff --git a/wiki/log.md b/wiki/log.md index 0e5f9587..20fdc95a 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,4 +1,58 @@ -## [2026-05-07] ingest | CTP Topic 22 Global DNS Service Offerings (re-ingest) +## [2026-04-28] ingest | CTP Topic 65 Tracing the Value Delivered in Cloud Transformation +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md +- Status: ✅ 成功摄入 +- Summary: 云转型计划（CTP）价值交付追踪方法论——区分 Process/Value/Value Stream 三个层次；价值分解为财务、生产力、质量、体验四维度；WSJF 公式（CoD/Job Size）排列工作优先级；功能级价值分解三种策略；综合框架涵盖年收入增长、成本降低、风险改善、SOM 四大价值维度。 +- Concepts touched: [[Value Stream]], [[Weighted Shortest Job First (WSJF)]], [[Cost of Delay (CoD)]], [[Process]], [[Value-Adding Activity]], [[Serviceable Obtainable Market (SOM)]] +- Entities touched: [[Cloud Transformation Programme (CTP)]] +- Concepts created: [[Value Stream]], [[Weighted Shortest Job First (WSJF)]], [[Cost of Delay (CoD)]], [[Serviceable Obtainable Market (SOM)]] +- Entities created: [[Cloud Transformation Programme (CTP)]] +- Source page: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md +- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第242行），无需更新；步骤5完成：overview.md 无需修订（该来源属于 CTP 专题系列，overview 中已有综合 CTP 上下文）；步骤6完成：新建1个 Entity 页面（Cloud Transformation Programme）；步骤7完成：新建4个 Concept 页面（Value Stream、Weighted Shortest Job First、Cost of Delay、SOM）；步骤8完成：无冲突（与 ctp-topic-53 互补而非矛盾：Topic 53 论证"为何上云"，本主题解决"如何衡量云转型价值"）；步骤9完成：log.md 追加记录 + +## [2026-04-28] ingest | CTP Topic 4 Using Agile to Run the Cloud Transformation Programme +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md +- Status: ✅ 成功摄入 +- Summary: 云转型项目中敏捷框架实践——Heather Norris 主讲。框架演进：Scrum（两周 Sprint）→ Kanban（持续流）→ 混合框架（Kanban + Scrum 仪式）。Scrum 局限：Sprint 期间不允许变更需求。Kanban 优势：随时调整优先级、持续交付。混合方案：保留每日站会和回顾会，使用 Microsoft Planner 五列看板。核心理念：敏捷本质是快速反馈循环，持续改进产品和开发文化。 +- Concepts touched: [[Scrum]], [[Kanban]], [[Scrum-Kanban混合框架]], [[Microsoft Planner]] +- Entities touched: [[Heather Norris]] +- Concepts created: 无（Scrum.md、Kanban.md 均已存在） +- Entities created: 无（Heather Norris.md 已存在） +- Source page: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md +- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第247行），无需更新；步骤5完成：overview.md 无需修订（Agile/Scrum/Kanban 内容已覆盖于现有概述中）；步骤6完成：无新增 Entity（Heather Norris.md 已存在）；步骤7完成：无新增 Concept（Scrum.md、Kanban.md 均已存在）；步骤8完成：无冲突；步骤9完成：log.md 追加记录 +## [2026-04-28] ingest | CTP Topic 43 VMware Cloud on AWS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md +- Status: ✅ 成功摄入（re-ingest：补充缺失实体/概念页面） +- Summary: VMware Cloud on AWS（VMC on AWS）混合云服务介绍——VMware 与 AWS 联合工程，在 AWS 裸金属服务器（i3.metal/i3en.metal）上原生安装 vSphere 8，为不完全准备完全迁移至原生云的企业提供中间路线。相比常规云方案节省 27% 成本，支持 HCX 任意迁移，Brian Reeves 主持经济学讨论，Mike O'Reilly 主讲技术架构。属 [[Hybrid-Cloud]] 在 AWS 落地的核心实践。 +- Concepts touched: [[VMware-Cloud-on-AWS]], [[SDDC]], [[HCX]], [[Stretched-Cluster]], [[TCO]] +- Entities touched: [[VMware]], [[AWS]], [[BrianReeves]], [[MichaelRiley]], [[MikeArmstrong]], [[MikeOReily]] +- Concepts created: [[TCO]] +- Entities created: [[BrianReeves]], [[MichaelRiley]], [[MikeArmstrong]], [[MikeOReily]] +- Source page: wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md +- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次修复双竖线格式问题；步骤4完成：index.md 条目已存在（第254行），无需更新；步骤5完成：overview.md 已有该来源摘要（line 331），内容一致无需修订；步骤6完成：新建4个 Entity 页面（BrianReeves、MichaelRiley、MikeArmstrong、MikeOReily），补充 TCO 到 VMware.md 和相关 Concept 页面的 Sources 节；步骤7完成：新建 [[TCO]] Concept 页面，补充 [[TCO]] 到 Source page Key Concepts 节；步骤8完成：无冲突（与 ctp-topic-53 的张力已在 Contradictions 节记录，属云迁移决策的视角差异而非事实冲突）；步骤9完成：log.md 追加本次 re-ingest 记录 + +## [2026-04-28] ingest | CTP Topic 19 Configuring DNS within AWS LZs +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md +- Status: ✅ 成功摄入 +- Summary: AWS Landing Zone 多账号环境下的集中化 DNS 管理架构——Sankar Gopov 主讲。核心方案：设立专门 DNS 账号（InfoBlocks 账号）集中管理 Route 53 私有托管区（PHZ）和 Resolver Rules，优于分散式 PHZ 管理。关键技术：Route 53 Resolver Inbound Endpoint（接收 On-prem 解析请求）和 Outbound Endpoint（转发 AWS → On-prem 请求）；AWS RAM 跨账号共享 Resolver Rules；跨账号 PHZ 关联两步流程（授权→关联）；Terraform 自动化部署。典型场景：AWS → On-prem、On-prem → AWS、账号间相互解析。属 [[AWS-Landing-Zone]] 网络基础服务层，与 Topic 18（广域网）和 Topic 31（网络安全）共同构成完整网络知识体系。 +- Concepts touched: [[Route-53-Resolver]], [[Private-Hosted-Zone]], [[Resolver-Rules]], [[AWS-RAM]], [[VPC-Association-Authorization]], [[AWS-Landing-Zone]] +- Entities touched: [[SankarGopov]] +- Concepts created: [[Route-53-Resolver]], [[Private-Hosted-Zone]], [[Resolver-Rules]], [[VPC-Association-Authorization]] +- Entities created: (无新建 — SankarGopov 已存在) +- Source page: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md +- Notes: 步骤3完成：新建 Source page；步骤4完成：index.md 条目已存在（第255行），补充一行摘要；步骤5完成：overview.md 新增 CTP Topic 19 摘要条目（在 Topic 18 与 Topic 25 之间）；步骤6完成：新建4个 Concept 页面（Route-53-Resolver、Private-Hosted-Zone、Resolver-Rules、VPC-Association-Authorization），更新 SankarGopov Entity 来源引用；步骤7完成：Source page Key Concepts 节已覆盖全部关键概念；步骤8完成：无冲突；步骤9完成：log.md 追加本次记录 + +## [2026-04-28] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +- Status: ✅ 成功摄入 +- Summary: AWS Landing Zone 环境下的资源数据收集、标签体系及基于标签的安全控制策略——Steve Jarman 和 Pradeep 联合主讲。核心内容：①OU 分层 + SCP 强制标签规范防止用户篡改标签绕过审计；②标签体系涵盖机器名、所有者（PDL）、类型、BU、产品、环境、服务器角色等维度；③Checkpoint Firewall 基于标签的 Ordered Layers（地理封锁→类型→BU→产品→环境→角色）和 Inline Layers（基于账号编号的父子规则结构）；④Demo 演示标签缺失导致 EC2 流量被防火墙拦截。 +- Concepts touched: [[AWS-Landing-Zone]], [[SCP-Security-Control-Policy]], [[Resource-Tagging]], [[Ordered-Layer]], [[Inline-Layer]], [[Checkpoint-Firewall]] +- Entities touched: [[AWS]], [[Checkpoint]], [[Pradeep]], [[Steve Jarman]] +- Concepts created: [[SCP-Security-Control-Policy]], [[Resource-Tagging]], [[Ordered-Layer]], [[Inline-Layer]] +- Entities created: [[Pradeep]], [[SteveJarman]] +- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第31行、第250行），无需更新；步骤5完成：overview.md 已有该来源详细摘要（line 321），无需修订；步骤6完成：更新2个已有 Entity 页面（AWS-Landing-Zone、Checkpoint-Firewall），新增2个 Entity 页面（Pradeep、SteveJarman）；步骤7完成：新建4个 Concept 页面（SCP-Security-Control-Policy、Resource-Tagging、Ordered-Layer、Inline-Layer）；步骤8完成：与 CTP Topic 7 的视角差异已记录于 Contradictions 节（属账号结构 vs 标签驱动的互补视角）；步骤9完成：log.md 追加本次记录 + + - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md - Status: ✅ 成功摄入（re-ingest） - Summary: 企业级全球 DNS 服务架构详解——Sankar 和 Vino 联合主讲。核心架构：Route 53 Private Hosted Zone（私有托管区域）配合 AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络的 DNS 查询；Outbound Endpoint 出站规则配置多个区域 AD 域控制器 IP，单区域故障时自动切换确保弹性。本地 Infoblox 平台利用 DNS Anycast 实现全球低延迟和自动故障转移；AWS EC2 不支持 Anycast，需手动维护 IP 列表。DNS 安全涵盖防隧道攻击、防数据外泄及缓存污染；"就近解析"原则优化 Office 365 等全球化 SaaS 访问性能。属 AWS Landing Zone 网络层 DNS 专题，与 ctp-topic-19 共同构成 Landing Zone DNS 完整体系。 @@ -5887,3 +5941,108 @@ - Entities touched: [[SendGrid]], [[Twilio]], [[Rejoy Ganapati]], [[Rajiv]], [[Yu-Yan]], [[PSAC]] - Source page: wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md - Notes: 步骤3完成：新建 source page（含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions）；步骤4完成：index.md 条目补全日期前缀（2026-04-14）；步骤5完成：overview.md 已有该来源摘要（line 347），内容一致无需修订；步骤6-7完成：Rejoy Ganapati/Rajiv/Yu-Yan 均仅在本次 source 出现一次（<2次，不满足 Entity 创建条件），Cyber Suite 仅提及未展开（不满足 Concept 创建条件），PSAC 已在 ctp-topic-24 source 和 log.md 中出现，本次仅作引用不新建 Entity；SendGrid/Twilio 已有 Entity 页面，无需新建；步骤8完成：与 ctp-topic-12（ SES SMTP terraform module）存在方案演进关系，记录于 Contradictions 节；步骤9完成：log.md 追加本次摄入记录 + +## [2026-04-24] ingest | CTP Topic 45 Automatic IP Address Allocation with IPAM +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md +- Status: ✅ 成功摄入 +- Summary: IPAM 自动化替代 Excel 手工分配——Infoblox NIOS 作为核心 IPAM 引擎，通过声明式 YAML 配置文件驱动 VPC IP 地址自动供给。传统模式需业务单元→SRE→网络团队→电子表格→YAML 多步手工交接；新模式用户仅声明业务联系人、工程联系人和期望子网大小，NIOS 自动分配下一可用 IP 地址块。销毁 VPC 时自动从 IPAM Grid 清除条目，防止 IP 泄漏。核心理念："We are not asking for IP address from the network team." 与 [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] 共同构成 IPAM 的"机制→应用"完整链路。 +- Concepts touched: [[IPAM]], [[Infoblox-NIOS]], [[Infoblox-Grid]], [[VPC-自动化供给]], [[CIDR-审批流程]], [[Availability-Zone-ID]], [[DNS-Anycast]], [[HybridDnsResolution]] +- Entities touched: [[Pushka]], [[Infoblox]], [[AWS-Landing-Zone]] +- Concepts created: [[IPAM]], [[Infoblox-NIOS]], [[Infoblox-Grid]], [[VPC-自动化供给]], [[CIDR-审批流程]], [[Availability-Zone-ID]] +- Entities created: [[Pushka]] +- Source page: wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md +- Notes: 步骤3完成：新建 Source page（含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions）；步骤4完成：index.md 条目已存在（line 253），补全一行摘要；步骤5完成：overview.md 已有该来源摘要（line 323），本次更新为更详细版本；步骤6完成：新建 [[Pushka]] Entity 页面（Principal SRE，IPAM 方案发起人）；Infoblox/AWS-Landing-Zone 已在其他 source 中多次提及，本次引用不新建；步骤7完成：新建 [[IPAM]]/[[Infoblox-NIOS]]/[[Infoblox-Grid]]/[[VPC-自动化供给]]/[[CIDR-审批流程]]/[[Availability-Zone-ID]] 6个 Concept 页面；步骤8完成：Contradictions 记录无冲突，与 ctp-topic-61/ctp-topic-22/ctp-topic-31 均为互补/依赖关系；步骤9完成：log.md 追加本次摄入记录 + +## [2026-04-28] ingest | CTP Topic 61 Workload VPC provision with IPAM Automation +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md +- Status: ✅ 成功摄入 +- Summary: Pushka（Principal SRE）主讲，基于 Infoblox IPAM 的 Workload VPC 自动化供给方案。核心内容：声明式 YAML 驱动 VPC 供给；Infoblox Grid 作为 IP 地址单一可信数据源；CIDR ≥ /22 自动审批，< /22 需网络团队理由审批；使用 AZ ID 而非 AZ Name 确保跨区域一致性；支持多 VPC 批量供给、邮件通知、非可路由 IP（如 10.2.0.0/16）。与 Topic 45（IPAM 核心机制）共同构成"机制→应用"完整链。 +- Concepts touched: [[IPAM]], [[Infoblox-Grid]], [[VPC-自动化供给]], [[CIDR-审批流程]], [[Availability-Zone-ID]] +- Entities touched: [[Pushka]] +- Concepts created: (无新建 — 相关 Concept 页面均已存在) +- Entities created: (无新建 — Pushka Entity 已存在) +- Source page: wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md +- Notes: 步骤3完成：新建 Source page（CTP Topic 61 Workload VPC Provision with IPAM Automation）；步骤4完成：index.md 第253行条目已存在，补充日期戳和一行摘要；步骤5完成：overview.md 第325行已存在相关条目，内容一致，无需更新；步骤6完成：IPAM、Infoblox-Grid、VPC-自动化供给、Pushka Entity 页面均已存在，无需新建；步骤7完成：Source page Key Concepts 节已覆盖全部关键概念；步骤8完成：无冲突；步骤9完成：log.md 追加本次记录 + +## [2026-05-07] ingest | CTP Topic 18 Wide Area Networking in AWS Cloud (补充缺失 Entity/Concept) +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md +- Status: ✅ 成功摄入（re-ingest：补充缺失实体/概念页面） +- Summary: AWS 云广域网架构——Christian Deckelman 主讲。全球 APJ/EMEA/AMS 三区域 TGW 星型拓扑，区域 Hub Full Mesh 互联；静态路由 DR 痛点；Silver Peak SD-WAN Overlay 演进路径；Pulse VPN → Prisma Access (SASE) 远程访问优化。 +- Concepts touched: [[AWS-Transit-Gateway-TGW]], [[Hub-and-Spoke]], [[SD-WAN]], [[Overlay-Network]], [[Static-Routing]], [[Prisma-Access]], [[TGW-Peering]], [[Transit-Gateway]] +- Entities touched: [[ChristianDeckelman]], [[AWS]], [[SilverPeak]], [[PaloAltoNetworks]], [[MicroFocus]], [[Pulse-VPN]] +- Concepts created: [[Hub-and-Spoke]], [[SD-WAN]], [[Overlay-Network]], [[Static-Routing]], [[Prisma-Access]], [[TGW-Peering]] +- Entities created: [[ChristianDeckelman]], [[SilverPeak]], [[PaloAltoNetworks]], [[MicroFocus]] +- Source page: wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md +- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），内容完整无需更新；步骤4完成：index.md 第256行条目已存在，无需更新；步骤5完成：overview.md 第289行已有该来源摘要，内容一致无需修订；步骤6完成：新建4个 Entity 页面（ChristianDeckelman、SilverPeak、PaloAltoNetworks、MicroFocus），补充 Pulse-VPN Entity 演进方向引用，更新 AWS Entity 来源和 Transit-Gateway Concept TGW-Peering 关系；步骤7完成：新建6个 Concept 页面（Hub-and-Spoke、SD-WAN、Overlay-Network、Static-Routing、Prisma-Access、TGW-Peering），Source page Key Concepts 节已覆盖全部；步骤8完成：无冲突；步骤9完成：log.md 追加本次记录 + +## [2026-05-08] ingest | CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones (re-ingest) +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md +- Status: ✅ 成功摄入（re-ingest：补充缺失 Entity/Concept 页面） +- Summary: AWS Landing Zone 网络隔离与安全远程访问方案。核心：①网络隔离——Checkpoint 防火墙 SPI Default Deny 阻断 On-prem/VPN 用户直连 AWS 生产区；②安全访问——AWS SSM 替代 VPN，IAM Role 假设 + SSM Agent 实现浏览器/CLI 远程访问，双因素认证。SD-WAN 落地前过渡方案；长期目标 IaC 化 + Break-glass 应急访问。 +- Concepts touched: [[Network-Segmentation]], [[Zero-Trust-Access]], [[SD-WAN]] +- Entities touched: [[AWS-Landing-Zone]], [[AWS-SSM]], [[Checkpoint-Firewall]] +- Concepts created: [[Zero-Trust-Access]] +- Entities created: [[AWS-Landing-Zone]], [[Checkpoint-Firewall]] +- Source page: wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md +- Notes: + - 步骤3完成：Source page 已存在（2026-04-25 初版），重写以匹配最新 Source Page Format（清理未对齐的 wikilinks） + - 步骤4完成：index.md 第256行条目已存在，补全日期前缀和一行摘要 + - 步骤5完成：overview.md 第295行已有该来源摘要，内容完整无需修订 + - 步骤6完成：新建2个 Entity 页面（AWS-Landing-Zone、Checkpoint-Firewall）；更新 SD-WAN.md 新增 CTP Topic 31 Relationship 节；AWS-SSM 已存在且来源已引用本次 source + - 步骤7完成：新建1个 Concept 页面（Zero-Trust-Access）；更新 Network-Segmentation.md 新增 ctp-topic-39 关联；SD-WAN 已存在且来源已引用本次 source + - 步骤8完成：无冲突——与 VPN 接入方案为替代关系（已记录于 Contradictions 节），与 SD-WAN 为时间维度互补关系 + - 步骤9完成：log.md 追加本次记录 + +## [2026-04-28] ingest | CTP Topic 30 Managing Change +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change.md +- Status: ✅ 成功摄入（re-ingest：补充缺失 Entity/Concept 页面） +- Summary: 云转型项目中的变更管理流程，SRE 团队在构建/上线支持/BAU 三阶段的协作模式。区分标准变更/正常变更/紧急变更三类流程，引入 IaC+CI/CD 自动化。属 [[Change-Management]] 在企业云迁移中的核心实践。 +- Concepts touched: [[SRE]], [[Standard-Change]], [[Normal-Change]], [[Emergency-Change]], [[CAPA]], [[SLO]], [[SLR]], [[Early-Live-Support]], [[Self-Healing]] +- Entities touched: [[Brendan-Starnig]], [[SMACs]], [[Vinaya]] +- Concepts created: [[SRE]], [[SLR]] +- Entities created: [[Vinaya]] +- Source page: wiki/sources/ctp-topic-30-managing-change.md +- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），内容完整无需修订；步骤4完成：index.md 条目已存在（第247行），本次补充 Vinaya/SRE/SLR 三个缺失条目的位置；步骤5完成：overview.md 已有该来源摘要（CTP Topic 30 属 CTP 课程体系），内容一致无需修订；步骤6完成：新建2个 Entity 页面（Vinaya），SRE-Team/SMACs/Brendan-Starnig 均已存在；步骤7完成：新建2个 Concept 页面（SRE、SLR），Standard-Change/Normal-Change/Emergency-Change/CAPA/Early-Live-Support/Self-Healing 均已存在；步骤8完成：无内容冲突；步骤9完成：log.md 追加本次 re-ingest 记录 + +## [2026-04-29] ingest | Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723 (re-ingest) +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md +- Status: ✅ 成功摄入（re-ingest：补充缺失 Entity/Concept 页面，完善交叉引用） +- Summary: OpenText DR 向 Recovery Assurance 演进框架——Jim Rose 主讲，涵盖 CrowdStrike 事件警示、RTO/RPO 合同差异、DR 测试瓶颈（被动/手动/按客户时间表）、多云复杂性（AWS/GCP/Azure）、混合架构挑战，以及 Design/Software/Build/Environments 四位框架转型路径。SRE + 可观测性工程是核心驱动力。 +- Entities identified: OpenText, CrowdStrike +- Concepts identified: RTO, RPO, SRE, Observability, Disaster-Recovery, Self-Healing, Customer-Zero, Recovery-Assurance +- Concepts created: [[Observability]], [[Disaster-Recovery]], [[Self-Healing]], [[Customer-Zero]], [[Recovery-Assurance]] +- Entities created: [[OpenText]] +- Concepts updated: [[RTO]], [[RPO]], [[SRE]]（补充新来源引用，更新 last_updated） +- Entities updated: [[AWS]]（补充新来源引用） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md +- Notes: + - 步骤3完成：Source page 已存在（2026-04-14 初版），本次补充5个新连接（Disaster-Recovery/Recovery-Assurance/Observability/Self-Healing/Customer-Zero），移除 Jim Rose 条目（OpenText 提及10+次 → 创建 Entity；CrowdStrike/Jim Rose 各仅1次 → 不单独建页） + - 步骤4完成：index.md 条目已存在（第239行），本次新增5个 Concepts 条目（Customer-Zero/Disaster-Recovery/Self-Healing/Recovery-Assurance）和1个 Entities 条目（OpenText） + - 步骤5完成：overview.md 已有该来源摘要（无需修订） + - 步骤6完成：新建 [[OpenText]] Entity 页面（OpenText 在10个来源中被提及）；CrowdStrike/Jim Rose 各仅1次提及，未达 ≥2次阈值，跳过 + - 步骤7完成：新建5个 Concept 页面（Observability/Disaster-Recovery/Self-Healing/Customer-Zero/Recovery-Assurance），更新 RTO/RPO/SRE Sources 节补充新来源引用 + - 步骤8完成：无冲突（与 ctp-topic-72/ctp-topic-44 互补，记录于 Source Page Contradictions 节） + - 步骤9完成：log.md 追加本次 re-ingest 记录 + +## [2026-05-09] re-ingest | CTP Topic 20 Program demand process flow and PoC onboarding（补充缺失 Entity/Concept 页面） +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md +- Status: ✅ re-ingest 完成（补充缺失 Entity/Concept 页面，完善 Wiki 链接完整性） +- Summary: 云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：需求来源（业务案例/战略优先级/产品路线图）、Gate Process 三阶段审批（Gate 0/1/3）、POC 目的（验证架构可行性+熟悉 Gruntwork Landing Zone）、新环境强调 IaC（Terraform/Terragrunt）自动化、PCG 团队职责、成功标准前置定义。 +- Entities identified: Sergio, Damian, PCG-Team +- Concepts identified: Program-Demand-Process, Proof-of-Concept, Gate-Process, Solution-Design +- Entities created: [[Sergio]], [[Damian]], [[PCG-Team]] +- Concepts created: [[Program-Demand-Process]], [[Proof-of-Concept]], [[Gate-Process]], [[Solution-Design]] +- Concepts updated: [[Infrastructure-as-Code]]（补充新来源引用）、[[Landing-Zone-Architecture]]（补充 Gruntwork Landing Zone 与 POC 关联） +- Entities updated: [[Gruntwork]]（补充新来源引用）、[[Terraform]]（补充新来源引用）、[[Terragrunt]]（补充新来源引用） +- Source page: wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md +- Notes: + - 步骤1完成：Source 文档已完整读取 + - 步骤2完成：Wiki 上下文（index.md + overview.md）已读取 + - 步骤3完成：Source page 已存在（2026-04-14 初版），无需重复创建 + - 步骤4完成：index.md 条目已存在（第249行），无需更新 + - 步骤5完成：overview.md 中已有 CTP 相关内容，本次 re-ingest 不修改 overview + - 步骤6完成：新建3个 Entity 页面（Sergio.md、Damian.md、PCGTeam.md） + - 步骤7完成：新建4个 Concept 页面（Program-Demand-Process.md、Proof-of-Concept.md、Gate-Process.md、Solution-Design.md） + - 步骤8完成：无新冲突（与 ctp-topic-4 的 Agile vs Gate Process 视角差异已于 Source Page 中记录） + - 步骤9完成：log.md 追加本次 re-ingest 记录 + diff --git a/wiki/overview.md b/wiki/overview.md index be4e57ca..2e8cb25e 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -288,6 +288,8 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **[[ctp-topic-18-wide-area-networking-in-aws-cloud]]**（CTP Topic 18）：AWS 广域网架构设计——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub（如 EMEA 伦敦、AMS 俄勒冈），所有 Landing Zones 通过 TGW Peering 以星型拓扑接入区域 Hub，区域 Hub 之间全网状互联。现阶段 TGW 间路由依赖静态前缀列表，缺乏 BGP 动态路由，DR 场景需人工干预。演进路线：引入 Silver Peak SD-WAN 作为叠加网络实现动态路径选择；Pulse VPN 迁移至 Palo Alto Prisma Access (SASE) 实现就近接入并打通 SD-WAN 骨干。属 [[AWS-Transit-Gateway]] 架构实践，与 [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]（Labs LZ 网络）和 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]（网络分段）共同构成 Landing Zone 网络知识体系。 +**[[ctp-topic-19-configuring-dns-within-aws-lzs]]**（CTP Topic 19）：AWS Landing Zone 环境下的 DNS 配置架构——Sankar Gopov 主讲。核心方案：在 Landing Zone 中设立专门的 DNS 账号集中管理 Route 53 私有托管区（PHZ）和解析规则，而非在每个业务账号中分散创建。关键技术组件：Route 53 Resolver 的 Inbound Endpoint（接收来自本地数据中心的解析请求）和 Outbound Endpoint（将 AWS 内部请求转发至 On-prem DNS）；AWS RAM 跨账号共享 Resolver Rules 给业务账户；跨账号 PHZ 关联必须先授权（Authorization）再关联（Association）。三种典型场景：从 AWS 访问本地资源（如 GitHub Enterprise）、从本地 VPN 访问 AWS 内部服务、账号间相互解析。Terraform 模块自动化部署，新账号上线即具备完整解析能力。属 [[AWS-Landing-Zone]] 网络基础服务层的核心实践，与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]]（广域网）和 [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]（网络安全）共同构成完整的 Landing Zone 网络知识体系。 + **[[ctp-topic-25-labs-landing-zone-overview-itom-teams]]**（CTP Topic 25）：Labs Landing Zone 运维团队视角——Labs LZ 基于 Gruntwork 参考架构，采用多账户策略，全部资源通过 Terraform/Terragrunt 管理（Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply）；核心账户包括：Shared（托管 Jenkins 主节点和加固 AMI）、Logs（CloudTrail/Config 日志集中存储）、Security（联邦用户和跨账户访问）、Core（AD 管理 Windows 实例和 IDP、DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙管理所有互联网流量，Pulse VPN 提供 Micro Focus 网络访问）、Shared Services（45 Arc Site 监控、Qualys 漏洞扫描）。Product Account 通过 Terraform 模块部署 subnet，需与网络团队协调 IP 范围和标签策略，防火墙通过标签自动配置网络访问策略。属 [[AWS-Landing-Zone]] Labs 视角的运维实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系。 **[[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]]**（CTP Topic 31）：AWS Landing Zone 网络隔离与安全远程访问方案——解决 On-prem 系统和 VPN 用户因共享网络配置而可直接访问生产工作负载的安全风险。核心方案：①网络隔离通过 Checkpoint 防火墙启用 SPI 特性（default-deny），阻断内部网络对 AWS 网段的直接连通；②安全访问通过 AWS Systems Manager (SSM) 替代 VPN，用户假设 IAM 角色访问目标 EC2 实例上的 SSM Agent，支持浏览器会话和 AWS CLI 两种模式，提供双因素认证和 AWS 网络内安全连接。定位为 SD-WAN 实施前的过渡方案；长期演进目标为 IaC 化以消除控制台访问，break-glass 访问仅保留用于紧急场景。与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]]（广域网架构）互补——后者关注如何打通网络，Topic 31 关注如何限制网络访问；两者共同构成 Landing Zone 网络知识体系。属 [[AWS-Landing-Zone]] 网络安全层的核心实践。 @@ -318,7 +320,7 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **CTP Topic 10**（[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]）：AWS Landing Zone 部署、数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心内容：①Landing Zone 部署前必须深入了解 BU 资产清单、IP 地址空间及数据敏感性；②DNS、Transit Gateway 等基础服务已通过 SRE 团队实现高度自动化；③**基于标签的安全控制机制**——传统基于 IP 的防火墙规则无法适应云环境动态性，转向利用 AWS 标签作为安全凭证；④**SCP 强制执行标签规范**——通过「显式拒绝」逻辑防止用户通过篡改标签绕过审计，确保资源创建时即具备正确的 BU/产品/环境归属；⑤**Checkpoint 防火墙有序层逻辑**——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离，实现跨 VPC/On-prem/互联网的精细化流量控制；⑥Inline 层基于账号号的父子规则架构，简化跨账户策略管理。与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 的安全层扩展，与 [[ctp-topic-28-aws-tag-validation-tool]]（标签审计）共同构成标签治理闭环。 -**[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**（CTP Topic 45）：Infoblox NIOS IPAM 自动分配 AWS VPC IP 地址——通过 YAML 配置文件声明期望子网大小和区域父 CIDR，NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；销毁 VPC 时自动从 IPAM Grid 清除条目；建立单一可信数据源，消除手工电子表格记录。属 [[IPAM（IP Address Management）]] 的机制层详解。 +**[[ctp-topic-45-automatic-ip-address-allocation-with-ipam]]**（CTP Topic 45）：IPAM 自动化替代 Excel 手工分配——Infoblox NIOS 作为核心 IPAM 引擎，通过声明式 YAML 配置文件（替代手工 network.yml）驱动 VPC IP 地址自动供给。传统模式：业务单元提出需求 → SRE 向网络团队申请 → 网络团队计算最优 CIDR → 更新电子表格 → SRE 准备 YAML；**新模式：用户仅声明业务联系人、工程联系人和期望子网大小（如 /22），NIOS 自动分配下一可用 IP 地址块，无需再与网络团队交接**。新 YAML 包含 parent_cidr（区域常量）、subnet_size 和 VPC 名称，支持多 VPC 和 AZ ID 指定。销毁 VPC 时自动从 IPAM Grid 清除条目，防止 IP 泄漏；系统向后兼容旧 YAML 配置。核心理念：**"We are not asking for IP address from the network team."** 属 [[IPAM（IP Address Management）]] 的机制层详解，与 [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]（应用层扩展）共同构成 IPAM 的"机制 → 应用"完整链路。 **[[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]**（CTP Topic 61）：Workload VPC 完整自动化供给方案——Pushka（Principal SRE）主讲，在 Topic 45 的 IPAM 自动分配机制基础上，展示了端到端 VPC 供给流程。核心增强：多 VPC 批量供给支持、邮件通知机制、CIDR /22 阈值自动审批（更大 CIDR 自动，更小需理由审批）、非路由 IP 地址（如 10.2.0.0/16）支持、使用 AZ ID 避免跨账号不一致。Infoblox Grid 作为全局唯一 IP 地址数据源防止重叠，架构包含休斯顿数据中心主库及冗余 DNS/NTP/DHCP 服务。核心理念：**"只需把信息放到正确位置，一切自动完成。"** 属 [[IPAM（IP Address Management）]] 的应用层扩展，与 [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] 共同构成 IPAM 的"机制 → 应用"完整链路。 diff --git a/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md b/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md index e12134df..ca167d43 100644 --- a/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md +++ b/wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md @@ -1,55 +1,52 @@ --- title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security" type: source -tags: - - AWS - - Landing-Zone - - Tagging - - Security - - CTP -last_updated: 2026-04-14 +tags: [] +date: 2026-04-14 --- ## Source File -- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]] +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]] ## Summary（用中文描述） -- 核心主题：AWS Landing Zone 的数据收集策略与基于标签的安全控制机制 -- 问题域：企业云迁移过程中的网络安全与访问控制 -- 方法/机制： - - 部署前通过业务部门（BU）资产清单、IP 地址空间及数据敏感性调研，制定 Landing Zone 安全姿态 - - 利用 AWS 标签（Tagging）替代传统基于 IP 的防火墙规则，作为安全凭证 - - 引入 OU（组织单元）和 SCP（服务控制策略）防止用户篡改标签绕过安全审计 - - Checkpoint 防火墙通过"有序层（Ordered Layer）"逻辑实现流量分层过滤 -- 结论/价值：实现从传统网络安全向基于身份和元数据的云原生安全转型 +- 核心主题：AWS Landing Zone 环境下的资源数据收集、标签体系及基于标签的安全控制策略 +- 问题域：如何在大规模多账号云环境中实现标准化资源管理、标签规范落地、以及动态化的安全策略执行 +- 方法/机制：采用 OU（组织单元）分层 + SCP（安全控制策略） + 标签匹配的三层防护架构；通过 Checkpoint Firewall 基于标签的策略集实现动态流量控制，替代传统的 IP 地址规则；标签体系涵盖机器名、所有者（PDL）、类型、业务单元、产品、环境、服务器角色等维度；防火墙策略层按地理封锁 → 类型 → BU → 产品 → 环境 → 角色顺序逐层检查 +- 结论/价值：基于标签的策略使云环境具备动态伸缩能力，无需频繁调整防火墙规则；标签驱动的 SCP 可确保资源标记合规性和安全 posture 正确性 ## Key Claims（用中文描述） -- Steve Jarman + Pradeep 通过 SCP 的"显式拒绝"逻辑，强制执行标签规范，确保资源在创建时即具备正确的归属标签（BU、产品、环境） -- Checkpoint 防火墙根据标签对流量进行分层过滤（地理屏蔽、BU 隔离、产品隔离、环境隔离），实现跨 VPC、On-prem 及互联网流量的精细化策略约束 -- DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现高度自动化 +- 组织通过 OU 分层架构和标签校验机制，确保迁移至云端的资源正确标记并应用必要的安全控制（如：普通 ADM 用户无法擅自将标签改为 ITOM） +- SCP（Security Control Policy）是基于标签匹配的拒绝策略，控制特定账号可使用的标签值，防止不合规资源进入云环境 +- 基于标签的防火墙策略集实现了动态云环境，策略以标签为依据而非 IP 地址，大幅减少防火墙规则维护工作量 +- 标签体系是云迁移规划的前提：收集机器信息 → 理解迁移范围 → 应用正确标签 → 触发安全策略 +- 防火墙策略的分层设计（Ordered Layers + Inline Layers）提供细粒度的流量管控：Ordered Layers 要求流量逐层通过，Inline Layers 采用基于账号编号的父子规则结构 ## Key Quotes -> "在部署前，必须深入了解业务部门（BU）的资产清单、IP 地址空间及数据敏感性，以便制定合适的安全姿态" — Steve Jarman，部署前规划原则 -> "通过 SCP 的'显式拒绝'逻辑，系统能够强制执行标签规范，确保资源在创建时即具备正确的归属" — Pradeep，标签安全控制机制 +> "We ask a lot of questions so that we can then turn around and make sure we're putting the appropriate posture in the cloud and that we're protecting the resources appropriately." — 关于云迁移前的标签规划重要性 +> "Inter product is not allowed. Inter product is communications allowed." — 关于跨产品线通信的防火墙默认策略 ## Key Concepts -- [[AWS Landing Zones]]：按照最佳实践快速设置安全且多账号 AWS 环境的基础架构框架 -- [[Tagging Methodology]]：通过为资源定义标准化元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础 -- [[SCP Service Control Policies]]：AWS Organizations 中的服务控制策略，用于管理组织中的权限，本视频中用于强制执行标签合规性 -- [[OU Organizational Unit]]：AWS Organizations 中账号的分组容器，用于分层应用安全策略（SCP） -- [[Checkpoint Firewall Ordered Layer]]：防火墙策略的组织方式，按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑 -- [[Transit Gateway]]：传输网关，作为网络中心枢纽连接 VPC 与本地网络，是跨环境流量经过防火墙检查的关键节点 -- [[SRE Automation]]：站点可靠性工程，负责 Landing Zone 部署中的自动化脚本编写与基础架构维护 +- [[AWS-Landing-Zone]]：AWS 多账号环境的基础架构框架，包含 OU、SCP、账号结构等核心组件 +- [[SCP（Security-Control-Policy）]]：基于标签匹配的拒绝策略，控制特定 OU 中可使用的标签值 +- [[Resource-Tagging]]：云资源的关键元数据体系，涵盖机器名、所有者、类型、业务单元、产品、环境、服务器角色等维度 +- [[Ordered-Layer]]：防火墙策略层，要求流量依次通过各层检查，全部通过方可放行 +- [[Inline-Layer]]：基于账号编号的父子规则结构，简化跨账号策略管理 +- [[Checkpoint-Firewall]]：在 Landing Zone 中部署的下一代防火墙，支持基于标签的动态策略 ## Key Entities -- [[Steve Jarman]]：Cloud Transformation Programme 技术分享主持人，Landing Zone 规划与自动化专家 -- [[Pradeep]]：Checkpoint 防火墙与网络隔离技术演示主讲人 +- [[Pradeep]]：本主题演示者（Demonstrator），负责 Checkpoint Firewall 和 EC2 部署演示 +- [[AWS]]：云服务提供商，Landing Zone 架构的承载平台 +- [[Checkpoint]]：防火墙供应商，在 Frankfurt Landing Zone 部署防火墙策略集 ## Connections -- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← builds_upon ← [[CTP Topic 10]] -- [[CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones]] ← extends ← [[CTP Topic 10]] -- [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]] ← related_to ← [[CTP Topic 10]] -- [[AWS_Organizations_and_SCP_Deep_Dive]] ← deep_dive ← [[CTP Topic 10]]（SCP 强制执行标签合规性） +- [[CTP-Topic-7-SaaS-Landing-Zone-Design]] ← foundational ← [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Security]]（Topic 7 定义 LZ 设计原则，Topic 10 补充标签驱动的安全实现） +- [[CTP-Topic-31-Network-Segregation-AWS-Landing-Zones]] ← extends ← [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Security]]（Topic 31 聚焦网络隔离，本主题提供标签驱动的安全策略执行层） +- [[CTP-Topic-25-Labs-Landing-Zone-Overview-ITOM]] ← related ← [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Security]]（均涉及 ITOM 团队的 LZ 运维视角） +- [[CTP-Topic-28-AWS-Tag-Validation-Tool]] ← complements ← [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Security]]（Topic 10 阐述标签用途，Topic 28 提供标签验证工具支撑） ## Contradictions -- 暂无已知冲突 +- 与 [[CTP-Topic-7-SaaS-Landing-Zone-Design]] 存在表述角度差异： + - 冲突点：Topic 7 强调 LZ 的账号/OUs 顶层设计，Topic 10 强调标签驱动的运行时安全控制 + - 当前观点：标签 + SCP 组合是 LZ 落地的关键执行层，标签策略与账号结构同等重要 + - 对方观点：Topic 7 将账号架构置于更核心位置，标签为辅助属性 + - 结论：两者视角互补而非矛盾——账号结构定义组织边界，标签驱动安全策略执行，共同构成完整的 LZ 治理体系 diff --git a/wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md b/wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md index 5f0c460a..d9ef93a8 100644 --- a/wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md +++ b/wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md @@ -1,7 +1,13 @@ --- title: "CTP Topic 19 Configuring DNS within AWS LZs" type: source -tags: [] +tags: + - AWS + - DNS + - Landing-Zone + - CTP + - Route-53 + - Multi-Account date: 2026-04-14 --- @@ -9,49 +15,39 @@ date: 2026-04-14 - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md]] ## Summary（用中文描述） -- 核心主题：在 AWS Landing Zone 多账号环境中配置集中化 DNS 管理架构 -- 问题域：跨账号、跨云与本地数据中心（On-prem）之间的域名解析难题 -- 方法/机制：设立专用 DNS 账号集中管理 Route 53 私有托管区，通过 Route 53 Resolver Inbound/Outbound Endpoints 打通 AWS 与本地 DNS，AWS RAM 跨账号共享解析规则，Terraform 实现自动化部署 -- 结论/价值：集中化 DNS 管理优于分散式，是多账号 AWS 环境的标准最佳实践 +- 核心主题：在 AWS Landing Zone 多账号环境中配置集中化 DNS 管理架构，实现跨账号、跨云与本地数据中心（On-prem）之间的统一域名解析。 +- 问题域：如何在多账号 AWS 架构中避免私有托管区（PHZ）分散管理，解决从 AWS 访问本地资源、从本地访问 AWS 内部服务、以及账号间相互解析等场景。 +- 方法/机制：设立专门的 DNS 账号集中管理 Route 53 Resolver Rules；利用 Inbound/Outbound Endpoints 实现双向解析转发；通过 AWS RAM 跨账号共享解析规则；Terraform 模块自动化部署。 +- 结论/价值：集中化 DNS 账号模式优于分散式 PHZ，可简化路由规则维护、确保新账号上线即具备完整解析能力，适合 Frankfurt R&D、London SAS 等大规模落地场景。 ## Key Claims（用中文描述） -- 集中化 DNS 管理优于分散管理：应在 Landing Zone 中设立专门的 DNS 账号，而非在每个业务账号中分散创建私有托管区，便于统一维护路由规则和域名记录 -- Route 53 Resolver 是混合 DNS 架构的核心组件：Inbound Endpoints 接收来自本地数据中心的解析请求，Outbound Endpoints 将 AWS 内部请求转发至本地 DNS 服务器 -- AWS RAM 实现跨账号规则共享：通过 AWS Resource Access Manager 将 DNS 账号中定义的 Resolver Rules 共享给各个业务账号 -- 跨账号 VPC 与私有托管区关联必须先授权再关联：授权（Authorization）必须在关联（Association）之前完成 -- Terraform 是自动化部署 DNS 架构的核心工具：新业务 VPC 创建时自动完成规则共享与 VPC 关联，确保新账号上线即具备完整解析能力 +- 在 Landing Zone 中设立专门的 DNS 账号（InfoBlocks 账号），统一管理私有托管区和解析规则，优于在每个业务账号中分散创建 PHZ。 +- Route 53 Inbound Endpoint 接收来自本地数据中心的 DNS 解析请求；Outbound Endpoint 将 AWS 内部请求转发至本地 DNS 服务器。 +- 通过 AWS RAM 将 DNS 账号中的 Resolver Rules 共享给各业务账号，业务 VPC 无需单独创建规则即可使用。 +- 跨账号 VPC 与私有托管区关联时，必须先由 PHZ 拥有者执行"授权（Authorization）"，再由 VPC 拥有者执行"关联（Association）"。 +- 该架构高度依赖 Terraform 自动化部署，在创建业务 VPC 过程中通过预定义模块自动完成规则共享与 VPC 关联。 ## Key Quotes -> "我们推荐在 Landing Zone 中设立一个专门的 DNS 账号，所有私有托管区都集中在这里管理，而不是在每个业务账号中创建各自的托管区。" — Sankar Gopov，解释集中化 DNS 管理的优势 -> "Inbound Endpoints 用于接收来自本地数据中心的 DNS 查询请求；Outbound Endpoints 用于将 AWS 内部的 DNS 查询转发到本地 DNS 服务器。" — Sankar Gopov，Route 53 Resolver Endpoints 的双向作用 -> "跨账号关联时，必须先由托管区拥有者进行授权（Authorization），然后才能由 VPC 拥有者执行关联（Association）。" — Sankar Gopov，跨账号关联的必须步骤 +> "本次视频由 Sankar Gopov 主讲，核心内容围绕 AWS Landing Zone 环境下的 DNS 配置架构展开，特别是如何在多账号架构中实现集中化的 DNS 管理。" — 视频开篇背景介绍 ## Key Concepts -- [[Route 53 Resolver]]：AWS Route 53 的 DNS 解析组件，通过 Inbound/Outbound Endpoints 实现混合云 DNS 架构 -- [[Private Hosted Zone]]：AWS Route 53 的私有托管区，用于在指定 VPC 内部解析自定义域名，不对互联网开放 -- [[Route 53 Resolver Rules]]：解析规则，定义特定域名的解析路径（如将某后缀的域名转发至本地数据中心） -- [[VPC Association Authorization]]：跨账号关联流程，PHZ 拥有者先授权，VPC 拥有者再执行关联 -- [[AWS RAM]]：Resource Access Manager，用于在组织内跨账号共享 Resolver Rules 等资源 -- [[Hybrid DNS Resolution]]：混合 DNS 解析，AWS VPC 与本地数据中心之间的跨环境域名解析机制 -- [[Terraform DNS Automation]]：使用 Terraform 自动化部署 DNS 架构的实践 +- [[Route-53-Resolver]]：AWS Route 53 的解析引擎，通过 Inbound/Outbound Endpoints 实现混合云 DNS 流量转发。 +- [[Private-Hosted-Zone]]：Route 53 私有托管区，在指定 VPC 内部解析自定义域名（如 `int-sas.local`），不暴露至互联网。 +- [[Resolver-Rules]]：解析规则，定义特定域名的解析路径（如匹配某后缀的域名需转发至本地数据中心特定 IP）。 +- [[AWS-RAM]]：Resource Access Manager，用于在 AWS Organization 内跨账号共享 Resolver Rules、Transit Gateway 等资源。 +- [[VPC-Association-Authorization]]：跨账号关联流程；VPC 与另一个账号的 PHZ 关联时必须先授权再关联。 +- [[AWS-Landing-Zone]]：多账号 AWS 环境规范，通过预配置的安全、网络和治理规则，为企业提供可扩展的基础设施框架。 ## Key Entities -- [[Sankar Gopov]]：本次视频讲师，AWS Landing Zone DNS 架构专家 -- [[AWS Landing Zone]]：AWS 多账号环境规范，是 DNS 架构的承载基础 +- [[SankarGopov]]：视频主讲人，来自 AWS/Cloud Transformation Programme，负责 DNS 架构设计与落地。 ## Connections -- [[ctp-topic-22-global-dns-service-offerings]] ← extends ← [[ctp-topic-19-configuring-dns-within-aws-lzs]] - - 两者同属 DNS 专题，后者（前文）讲企业级全局 DNS 服务架构（Infoblox + Route 53），后者（本文）聚焦 Landing Zone 内部的具体配置实施 -- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← depends_on ← [[ctp-topic-19-configuring-dns-within-aws-lzs]] - - Landing Zone 顶层设计包含 DNS 账户的规划 -- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← relates_to ← [[ctp-topic-19-configuring-dns-within-aws-lzs]] - - Labs LZ 中 Core 账户托管 DNS 服务（Swimford.net） -- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← depends_on ← [[ctp-topic-19-configuring-dns-within-aws-lzs]] - - AD 服务依赖 DNS 完成域名解析，int-sas.local 等域名的解析由 DNS 架构提供 +- [[AWS-Landing-Zone]] ← foundational ← [[CTP-Topic-19-DNS]] +- [[Route-53-Resolver]] ← core_technology ← [[CTP-Topic-19-DNS]] +- [[Terraform]] ← automation_tool ← [[CTP-Topic-19-DNS]] +- [[AWS-RAM]] ← sharing_mechanism ← [[CTP-Topic-19-DNS]] +- [[CTP-Topic-19-DNS]] ← related_topic ← [[CTP-Topic-35-AWS-Landing-Zone]] +- [[CTP-Topic-19-DNS]] ← related_topic ← [[CTP-Topic-17-AD-Services]] ## Contradictions -- 与 [[ctp-topic-22-global-dns-service-offerings]] 潜在视角差异： - - 冲突点：DNS 账号是否应包含公共托管区（Public Hosted Zone） - - 当前观点（Topic 19）：DNS 账号专注于私有托管区和 Route 53 Resolver 管理 - - 对方观点（Topic 22）：Route 53 还需管理公共域名解析（Route 53 Hosted Zone + Route 53 Resolver） - - 注：两者可能适用于不同的环境（Topic 22 侧重 DNS 服务提供者的全局架构，Topic 19 侧重 Landing Zone 内部的落地配置） +- 暂无已知冲突。本页内容与其他 Landing Zone 相关来源（如 CTP Topic 35）保持一致，均强调集中化基础设施账号的治理优势。 diff --git a/wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md b/wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md index dce48861..24196489 100644 --- a/wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md +++ b/wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md @@ -10,54 +10,52 @@ date: 2026-04-14 --- ## Source File -- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md]] +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] ## Summary（用中文描述） -- 核心主题：AWS Landing Zone 网络隔离与安全远程访问方案 -- 问题域：内部网络（On-prem / VPN 用户）对 AWS Landing Zone 生产工作负载的未授权访问风险 -- 方法/机制：① 网络隔离——Checkpoint 防火墙实现 default-deny 的 SPI 模型，阻断内部网络对 AWS 网段的直接连通；② 安全访问——AWS Systems Manager (SSM) 替代 VPN，提供基于浏览器的安全远程连接 -- 结论/价值：该方案作为 SD-WAN 实施前的过渡方案，以更低成本和更快速度解决紧急安全风险；长期目标是 IaC 化以消除控制台访问 +- 核心主题：通过网络隔离与安全访问控制，解决企业内部系统直接访问 AWS Landing Zone 生产负载的安全与合规问题 +- 问题域：On-prem 系统和 VPN 用户因共享网络配置而能访问 AWS 生产区，存在安全合规风险 +- 方法/机制： + - **网络隔离**：使用 Checkpoint 防火墙建立检查点（SPI），默认拒绝通行，仅放行业务所需服务和网段 + - **安全访问**：通过 AWS Systems Manager (SSM) 实现远程访问，用户假设 IAM Role 直连 EC2 上的 SSM Agent，无需 VPN +- 结论/价值：SSM 方案作为 SD-WAN 落地前的临时方案，具有双因素认证、安全连接、零第三方依赖的优势；长期目标是 IaC 化以减少控制台访问 ## Key Claims（用中文描述） -- 内部网络与 VPN 用户因共享网络配置而可访问 AWS Landing Zone 生产工作负载，构成安全与合规风险 -- Checkpoint 防火墙启用 SPI（Security Policy Infrastructure）特性，默认 deny，仅放行必要服务和网段到 Landing Zone -- AWS SSM 通过 IAM 角色假设 + SSM Agent 实现远程访问，无需 VPN，支持浏览器会话和 AWS CLI 两种模式 -- SSM 远程访问提供双因素认证保障，连接位于 AWS 网络内部，安全性高于传统 VPN -- 当前方案定位于 SD-WAN 实施前的临时/备份方案，主要优势是降低成本和提升部署速度 -- 长期安全演进方向：IaC 化以减少控制台访问，break-glass 访问仅保留用于紧急场景 -- 当前方案聚焦网络隔离，不解决凭证被盗问题 +- On-prem 系统和 VPN 用户因共享网络配置可访问 AWS Landing Zone 生产区，造成安全合规风险 +- Checkpoint SPI 功能以默认拒绝（Default Deny）为基础，仅放行业务必需的服务和网络段 +- AWS SSM 提供基于浏览器的会话和 AWS CLI 远程访问，无需 VPN，消除对第三方管理的依赖 +- 用户通过假设 IAM Role 获得目标 EC2 上 SSM Agent 的访问权限，继承既有访问控制 +- SSM 方案安全性优势：双因素认证 + AWS 网络内安全连接 +- SSM 作为临时/备份方案，最终目标是 IaC + Break-glass 应急访问 +- 当前方案不解决凭证被盗风险，仅实现网络隔离 ## Key Quotes -> "The primary driver for this initiative is to address security concerns related to internal systems accessing production workloads in the new AWS landing zones." — 背景动机：内部系统对生产工作负载的访问安全风险 - -> "The SPI features will be enabled with default deny enabled and allowances made for require services and network segments into the landing zones." — 核心机制：Checkpoint SPI 默认拒绝策略 - -> "Authenticated users will assume roles granting access to the SSM agent on the target EC2 instance, leveraging existing access controls." — SSM 访问控制机制：基于 IAM 角色假设 - -> "SSM gives users remote access via a browser based session." — SSM 核心价值：浏览器远程会话替代 VPN +> "The primary driver for this initiative is to address security concerns related to internal systems accessing production workloads in the new AWS landing zones." — 问题背景 +> "SPI features will be enabled with default deny enabled and allowances made for require services and network segments into the landing zones." — Checkpoint 配置策略 +> "Authenticated users will assume roles granting access to the SSM agent on the target EC2 instance, leveraging existing access controls." — SSM 访问机制 +> "SSM gives users remote access via a browser based session." — SSM 核心价值 ## Key Concepts -- [[AWS-Landing-Zone]]：AWS 多账户架构框架，包含核心账户、基线账户、共享服务账户和产品账户 -- [[AWS-Systems-Manager-SSM]]：AWS 托管的远程管理服务，通过 SSM Agent 实现安全的无 VPN 远程访问，支持浏览器会话和 AWS CLI 模式 -- [[Network-Segregation]]：网络隔离策略，通过 Checkpoint 防火墙实现默认拒绝（default-deny），仅放行经授权的服务和网段通信 -- [[SPI-Security-Policy-Infrastructure]]：安全策略基础设施，在 Checkpoint 防火墙上强制执行网络分段，控制服务器间通信并阻断内部网络对 AWS 网段的直接访问 -- [[SD-WAN]]：软件定义广域网，组织的长期远程访问演进目标，当前 SSM 方案作为 SD-WAN 实施前的过渡方案 +- [[Network-Segmentation]]：通过防火墙检查点控制服务器间通信，阻止内部网络直接访问云端网段的安全策略 +- [[Zero-Trust-Access]]：基于 IAM Role 和 SSM Agent 的远程访问机制，替代传统 VPN 的零信任访问模式 +- [[AWS-Landing-Zone]]：AWS Landing Zone 的多账户架构与网络隔离设计原则 ## Key Entities -- [[Checkpoint]]：网络安全设备供应商，提供 Landing Zone 间网段隔离的防火墙能力，依赖 AWS 标签值动态配置访问策略 +- [[AWS-Landing-Zone]]：AWS 多账户 Landing Zone 架构，当前被 On-prem/VPN 用户共享网络配置所威胁 +- [[AWS-SSM]]：核心安全访问工具，提供浏览器会话和 CLI 两种远程访问方式 +- [[Checkpoint-Firewall]]：用于 SPI（Stateful Packet Inspection）网络隔离的防火墙，实现 Default Deny 策略 ## Connections -- [[ctp-topic-18-wide-area-networking-in-aws-cloud]] ← related_to ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] - - 关联点：同属 AWS Landing Zone 网络知识体系，Topic 18 聚焦广域网架构（Transit Gateway / SD-WAN），Topic 31 聚焦网络隔离与安全访问 -- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← related_to ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] - - 关联点：Topic 25 的 Labs LZ 运维视角涉及 VPN 远程访问需求，与 Topic 31 的 SSM 安全访问方案存在技术演进关系 -- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← extends ← [[ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones]] - - 关联点：Topic 35 明确提及"网络分段阻断对 SaaS 工作负载的直接连通性"，是 Topic 31 所描述方案的设计依据 +- [[AWS-Landing-Zone]] ← addresses_security_concerns ← [[Network-Segmentation]] +- [[AWS-Landing-Zone]] ← secure_access ← [[AWS-SSM]] +- [[AWS-SSM]] ← temporary_solution_for ← [[SD-WAN]] +- [[Checkpoint-Firewall]] ← enforces ← [[Network-Segmentation]] ## Contradictions -- 与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 存在视角差异： - - 冲突点：Topic 18 强调广域网连通性（Transit Gateway Peering / SD-WAN / Pulse VPN 迁移至 Prisma Access），关注如何打通网络 - - Topic 31 视角：网络隔离的首要目标是阻断内部网络对 AWS 的直接访问，关注如何限制连通性 - - 对方观点：Topic 18 的演进路线中，Prisma Access (SASE) 将提供更安全的远程接入方案 - - 当前观点：Topic 31 主张 SSM 作为过渡方案，在 SD-WAN 实施前优先解决网络安全隔离问题 - - 调和建议：两者互补——Topic 31 解决内部网络隔离的短期安全问题，Topic 18 规划长期广域网演进路径（SD-WAN / SASE） +- 与传统 VPN 接入方案存在替代关系： + - 冲突点：VPN 提供通用远程接入，但无法精细控制到单个 AWS 网段 + - 当前观点：SSM 取代 VPN 作为 AWS Landing Zone 的安全访问手段 + - 对方观点：VPN 仍是部分场景（通用办公网络）的必要访问方式 +- 与 [[SD-WAN]] 的关系： + - 当前观点：SSM 是 SD-WAN 落地前的临时方案 + - 未来观点：SD-WAN 部署后将从网络层解决跨区域安全互联问题 diff --git a/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md b/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md index 31b4e57a..bf28b0f3 100644 --- a/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md +++ b/wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md @@ -11,7 +11,7 @@ date: 2026-04-14 --- ## Source File -- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]] +- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]] ## Summary（用中文描述） - 核心主题：Cloud Transformation Program（CTP）正式采用 SendGrid 作为标准邮件服务，取代原有的语义消息网关和 SES 方案；同时更新了 Cyber Suite 安全加密标准。 diff --git a/wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md b/wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md index 75ea6ddc..03c66e81 100644 --- a/wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md +++ b/wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md @@ -1,47 +1,48 @@ --- title: "CTP Topic 4 Using Agile to Run the Cloud Transformation Programme" type: source -tags: [] -sources: [] -last_updated: 2026-04-24 +tags: + - Agile + - Cloud-Transformation + - CTP + - Scrum + - Kanban +date: 2026-04-14 --- ## Source File -- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md]] +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ## Summary（用中文描述） -- 核心主题：云转型计划（Cloud Transformation Programme）中敏捷实践的落地经验 -- 问题域：大型企业云迁移项目如何选择和调整敏捷框架 -- 方法/机制：Scrum → Kanban 的框架演进；Microsoft Planner 作为看板工具；每日站会 + 回顾会议保留 Scrum 仪式 -- 结论/价值：Scrum 的固定 Sprint 节奏不适合快速变化的云转型项目，Kanban 持续流动 + 固定仪式是更优的混合方案 +- 核心主题：云转型项目中的敏捷框架实践——从 Scrum 到 Kanban 的演进过程 +- 问题域：大型企业云转型项目中敏捷落地的实际挑战，包括迭代周期限制、变更管理、团队协作与持续交付 +- 方法/机制：初期采用 Scrum 两周冲刺（含产品待办列表、Sprint 规划、回顾、评审、每日站会）；因无法应对频繁变更而转向 Kanban 持续流模式；当前为混合模式（Kanban 为主，保留 Scrum 仪式）。使用 Microsoft Planner 看板管理任务（backlog / to do / in progress / program key decisions / icebox 五列） +- 结论/价值：Kanban 适合持续变更的云转型项目，允许随时调整优先级；Scrum 仪式（每日站会、回顾会）仍有保留价值，有助于快速反馈和团队文化改进 ## Key Claims（用中文描述） -- 云转型团队从 Scrum（两周 Sprint）转向 Kanban，因为 Sprint 期间不允许变更，无法应对项目中的频繁变化 -- 混合框架（Kanban 为主 + 保留 Scrum 仪式）是当前最优方案 -- 每日站会应简短（15-30 分钟），围绕 Planner 看板回答三个问题：昨天完成什么、今天做什么、有什么阻碍 -- 回顾会议是快速反馈循环的核心，通过行动项（带负责人）驱动团队持续改进 -- Microsoft Planner 看板列：Backlog → To Do → In Progress → Program Key Decisions → Icebox -- 每张任务卡必须指定单一负责人，即使多人协作；明确角色（如 oversight）；链接依赖卡；使用优先级和截止日期 +- Scrum 的核心局限：两周冲刺周期内不允许中途变更需求，导致云转型这类频繁变化的敏捷项目难以适应 +- Kanban 的核心优势：支持随时变更优先级和范围，专注于持续交付而非批量发布 +- 混合框架的价值：保留每日站会和回顾会（Scrum 仪式），同时采用 Kanban 的持续流工作方式 +- Microsoft Planner 作为任务管理工具：集中管理需求、明确定义任务Owner、链接依赖任务、使用优先级和截止日期 +- 敏捷的本质：通过快速反馈循环持续改进产品和开发文化 ## Key Quotes -> "The big problem with Scrum, in my opinion, is that you can't make changes throughout the sprints, we are not advised to." — Heather Norris，解释为何从 Scrum 转向 Kanban - -> "Agile is all about getting that rapid feedback to make the product and make the, you know, the development culture better." — Heather Norris，阐述敏捷的核心价值 +> "The big problem with Scrum, in my opinion, is that you can't make changes throughout the sprints, we are not advised to." — Heather Norris，阐述 Scrum 在云转型项目中的局限性 +> "Agile is all about getting that rapid feedback to make the product and make the development culture better." — Heather Norris，阐述敏捷的核心价值 ## Key Concepts -- [[Scrum]]：两周一迭代的敏捷框架，包含 Product Backlog、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective；因 Sprint 期间禁止变更而被云转型团队放弃 -- [[Kanban]]：持续流动的敏捷框架，允许随时调整优先级，无固定 Sprint 边界；适合变化频繁的云转型项目 -- [[Agile Ceremonies]]：Scrum 的固定仪式——Sprint Planning（冲刺规划）、Daily Stand-up（每日站会）、Sprint Review（冲刺评审）、Retrospective（回顾会议）；云转型团队保留站会和回顾会议 -- [[Continuous Delivery]]：持续交付，Kanban 的核心优势，无需等待 Sprint 结束即可发布 -- [[Microsoft Planner Board]]：微软看板工具，云转型团队的项目管理平台，支持卡片管理、依赖链接、优先级设置 +- [[Scrum]]：一种敏捷框架，以固定周期的 Sprint 为核心，包含产品待办列表、Sprint 规划、每日站会、评审和回顾会议 +- [[Kanban]]：一种可视化工作流管理方法，支持持续交付，允许随时调整优先级和范围，不受固定迭代周期限制 +- [[Scrum-Kanban混合框架]]：保留 Scrum 仪式（每日站会、回顾会）的同时，采用 Kanban 的持续流工作方式 +- [[Microsoft Planner]]：微软的任务管理工具，采用看板结构管理团队工作 ## Key Entities -- [[Heather Norris]]：云转型计划项目经理，主讲本次分享，介绍敏捷方法论实践 -- [[Microsoft Planner]]：团队使用的项目管理看板工具 +- [[Heather Norris]]：云转型项目经理，分享了敏捷方法论在项目中的实际落地经验 ## Connections -- [[ctp-topic-57-product-backlog-managing-demand]] ← related_to ← [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] -- [[ctp-topic-30-managing-change]] ← extends ← [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] +- [[CTP Topic 57 Product backlog managing demand]] ← relates_to ← [[Scrum]] +- [[CTP Topic 3 Deploy and maintain infrastructure]] ← extends ← [[Kanban]] +- [[CTP Topic 41 NFR's and Error Budgets]] ← relates_to ← [[敏捷文化]] ## Contradictions -- 无已知冲突 +- （暂无发现与其他来源的内容冲突） diff --git a/wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md b/wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md index 66c5d4ab..a6f5f9c7 100644 --- a/wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md +++ b/wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md @@ -36,19 +36,20 @@ date: 2026-04-14 - [[SDDC]]：软件定义数据中心，VMC on AWS 通过 vCenter 进行管理的核心架构单元 - [[HCX]]：Hybrid Cloud Extension，支持任意 vSphere 环境之间的双向工作负载迁移 - [[Stretched-Cluster]]：跨可用区的拉伸集群，提供跨 AZ 的高可用和灾难恢复能力 -- [[TCO]]：总拥有成本，云经济学团队用于评估迁移成本效益的核心指标 +- [[TCO]]：总拥有成本，云经济学团队用于评估迁移成本效益的核心指标（VMC on AWS 相比常规云节省 27%） ## Key Entities - [[VMware]]：企业级虚拟化和云计算软件提供商，与 AWS 合作开发 VMC on AWS - [[AWS]]：Amazon Web Services，提供 VMC on AWS 的底层裸机服务器基础设施（i3.metal/i3en.metal） -- Brian Reeves：VMware 演讲者，讨论 VMC on AWS 的经济学效益 -- Michael Riley：VMware 演讲者 -- Mike Armstrong：VMware 演讲者 -- Mike O'Reilly：VMware Staff Cloud Solutions Architect，主讲 VMC on AWS 技术架构 +- [[BrianReeves]]：VMware 演讲者，讨论 VMC on AWS 的经济学效益 +- [[MichaelRiley]]：VMware 演讲者 +- [[MikeArmstrong]]：VMware 演讲者 +- [[MikeOReily]]：VMware Staff Cloud Solutions Architect，主讲 VMC on AWS 技术架构 ## Connections - [[ctp-topic-7-saas-landing-zone-design]] ← extends ← [[ctp-topic-43-vmware-cloud-on-aws]]（两者均涉及 AWS 基础设施上的企业工作负载部署） - [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← related_to ← [[ctp-topic-43-vmware-cloud-on-aws]]（混合云是 Landing Zone 设计的重要扩展方向） +- [[ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm]] ← extends ← [[ctp-topic-43-vmware-cloud-on-aws]]（Topic 43 介绍 VMC on AWS 概述，Topic 69 深入迁移最佳实践） ## Contradictions - 与 [[ctp-topic-53-why-bother-with-cloud]] 潜在冲突： diff --git a/wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md b/wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md index 0f9f7e88..4bc5fc11 100644 --- a/wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md +++ b/wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md @@ -1,5 +1,5 @@ --- -title: "CTP Topic 45 Automatic IP address allocation with IPAM" +title: "CTP Topic 45 Automatic IP Address Allocation with IPAM" type: source tags: - AWS @@ -7,46 +7,50 @@ tags: - Networking - CTP - Infoblox - - VPC - - Terragrunt -date: 2026-04-14 +date: 2026-04-24 --- ## Source File - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md]] ## Summary（用中文描述） -- 核心主题：使用 Infoblox NIOS 实现 AWS VPC 自动化 IP 地址分配，替代传统手工电子表格管理方式 -- 问题域：IP 地址管理效率低下（手工请求→网络团队计算CIDR→手工填表→人工配置YAML），新增VPC需要反复与网络团队交接 -- 方法/机制：Infoblox NIOS IPAM 系统自动查询下一个可用 IP 地址块，按需自动审批（≤/24自动，>/24需网络团队审批），Terragrunt YAML 配置文件不再包含硬编码 IP，改由 NIOS 动态注入 -- 结论/价值：实现"创建 VPC 无需网络团队参与"的完全自动化目标，消除 Excel 表格管理，建立单一可信数据源，向后兼容旧 YAML 配置 +- 核心主题：使用 Infoblox NIOS IPAM 平台实现 VPC IP 地址分配的完全自动化，替代传统手工 Excel 管理模式。 +- 问题域：企业多账号 AWS 环境中，IP 地址手工分配效率低、易出错，且需频繁与网络团队交接。 +- 方法/机制：声明式 YAML 配置文件替代手工 CIDR 规划；Infoblox NIOS 自动查询下一可用 IP 地址块；/24 及以上触发审批流程；支持 VPC 销毁时自动清理 IPAM 记录。 +- 结论/价值：**用户无需再向网络团队申请 IP 地址**，系统自动完成规划、分配和回收，实现 IP 地址管理的单一可信数据源。 ## Key Claims（用中文描述） -- Infoblox NIOS 通过 API 自动分配下一个可用 IP 地址块，替代人工计算 CIDR 范围和手动更新电子表格 -- 当所需网络地址 ≤/24 时，VPC 模块自动运行，无需人工干预 -- 当所需网络地址 >/24 时，系统自动触发网络团队审批流程，而非直接拒绝 -- 新 YAML 配置文件中不再包含 CIDR 子网 IP 地址，仅声明期望的子网大小（如 /22）和区域级父 CIDR 常量 -- VPC 名称被纳入 YAML 文件，支持一次性配置多个 VPC -- 销毁 VPC 时自动从 IPAM Grid 中清除所有相关条目，支持撤销保护（Terragrunt.hcl 需特殊 flag 防止误删） -- 新系统向后兼容现有 VPC 配置，旧 YAML 文件继续工作 +- IPAM 通过 Infoblox NIOS 自动化 IP 地址分配，消除手工 Excel 管理，将 IP 地址规划效率提升数倍。 +- 新的 YAML 配置文件仅声明业务联系人、工程联系人和所需子网大小（而非硬编码 CIDR），系统自动从 Infoblox 获取下一可用 IP 地址块。 +- /24 及更小子网需网络团队审批，/22 及更大子网自动批准（参见 [[CIDR-审批流程]]）。 +- VPC 销毁时自动从 Infoblox Grid 移除所有相关 IP 记录，支持完整生命周期管理。 +- YAML 支持多 VPC 配置和可用区 ID（AZ ID）指定，兼容性强。 +- 系统向后兼容：使用旧 YAML 文件的现有 VPC 配置继续正常工作。 ## Key Quotes -> "Managing the IP address in a spreadsheet takes time and it's not a good approach." — 当前电子表格管理方式的低效痛点 -> "We are not asking for IP address from the network team." — 新系统的核心价值：消除网络团队交接 -> "The goal is for any new VPC that we don't have to engage the network team every time we want to create a VPC with the subnets." — 自动化愿景 +> "Managing the IP address in a spreadsheet takes time and it's not a good approach." — 传统 Excel 管理 IP 地址的低效性 +> "We are not asking for IP address from the network team." — IPAM 自动化的核心价值——彻底消除与网络团队的手工交接 ## Key Concepts -- [[IPAM（IP Address Management）]]：IP 地址管理系统的核心概念，NIOS 提供集中化管理、控制、监控和分配 IP 地址空间的能力 -- [[Infoblox-NIOS]]：Infoblox NIOS 是 IPAM 功能的核心实现，作为分布式 Grid 框架的扩展，集成 DNS/DHCP，提供统一管理控制台 -- [[VPC-自动化供给]]：通过 Terragrunt YAML 配置文件声明式定义 VPC 需求，由 NIOS 自动分配 IP 地址，无需手工配置 +- [[IPAM]]：IP Address Management，企业级 IP 地址管理平台，本视频展示 Infoblox NIOS 作为 IPAM 引擎与 AWS VPC 供给的集成。 +- [[Infoblox-NIOS]]：Infoblox 的核心网络控制平面，提供 DNS、DHCP 和 IP 地址管理功能，支持可扩展属性（Extensible Attributes）用于存储元数据。 +- [[VPC-自动化供给]]：通过声明式 YAML 配置文件自动完成 VPC 创建，IP 地址分配完全自动化。 +- [[CIDR-审批流程]]：基于 CIDR 大小的差异化审批策略——/24 及以下需网络团队审批，/22 及更大自动批准。 +- [[Infoblox-Grid]]：Infoblox 的分布式网格架构，作为全局唯一的 IP 地址数据源。 +- [[Availability-Zone-ID]]：AWS 可用区标识符（az-id），用于避免多账号环境中可用区名称（az-name）不一致问题。 ## Key Entities -- [[Grid-Master]]：Infoblox Grid 架构中的核心节点，管理 API 调用和各 AWS 云账户的 IP 地址分配 +- [[Pushka]]（Principal SRE）：IPAM 与 VPC 自动化方案的发起人和演示者，Topic 45 主讲人。 +- [[Infoblox]]：IPAM 供应商，提供 NIOS 平台及 Grid 架构。 +- [[AWS-Landing-Zone]]：本方案的实施背景——企业级多账号 AWS 环境。 ## Connections -- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← relates_to ← 本页：均涉及 VPC 供给与 IPAM 自动化的实践 -- [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← depends_on ← 本页：Labs Landing Zone 的 VPC 供给依赖 IPAM 自动分配 -- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← related_to ← 本页：均涉及标签驱动的 AWS 基础设施自动化 +- [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] ← extends ← [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] + - Topic 45 介绍 IPAM 自动分配机制；Topic 61 展示该机制在 Workload VPC 供给中的完整应用。 +- [[ctp-topic-22-global-dns-service-offerings]] ← shares_infra ← [[Infoblox]] + - Infoblox 同时支撑 DNS Anycast 和 IPAM 服务，是网络层多服务的统一基础设施。 +- [[ctp-topic-31-network-segregation-and-secure-access]] ← depends_on ← [[VPC-自动化供给]] + - VPC 自动化供给是网络分段和安全访问策略的基础前提。 ## Contradictions -- 无已知冲突内容 +- 无已知冲突内容。 diff --git a/wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md b/wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md index 5d45691b..ee9ec3bc 100644 --- a/wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md +++ b/wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md @@ -1,5 +1,5 @@ --- -title: "CTP Topic 61 Workload VPC provision with IPAM Automation" +title: "CTP Topic 61 Workload VPC Provision with IPAM Automation" type: source tags: - AWS @@ -7,52 +7,46 @@ tags: - IPAM - Automation - CTP - - Infoblox -date: 2026-04-24 +date: 2026-04-14 --- ## Source File - [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md]] ## Summary（用中文描述） -- 核心主题：IPAM（IP 地址管理）与 Workload VPC 自动化供给的完整集成方案，包括近期功能增强。 -- 问题域：企业多账号 AWS 环境中，如何在不依赖网络团队手工介入的情况下，自动完成 VPC 的 IP 地址规划与供给。 -- 方法/机制：使用 Infoblox Grid 作为核心 IPAM 引擎，通过声明式 YAML 配置文件触发自动化供给流程；/22 及更大 CIDR 自动审批，更小 CIDR 触发邮件审批流程；Availability Zone ID（而非 AZ Name）避免跨区域不一致；多 VPC 批量供给和非路由 IP 地址（如 10.2.0.0/16）支持。 -- 结论/价值：**"只需把信息放到正确位置，一切自动完成。"** 用户只需声明业务联系人和父 CIDR，无需关心 IP 地址分配细节；Infoblox Grid 作为唯一可信数据源，防止 IP 地址重叠。 +- 核心主题：基于 IPAM（Infoblox Grid）的 Workload VPC 自动化供给流程，包括审批机制和增强功能。 +- 问题域：企业 AWS 多账号环境中，VPC 供给需要协调网络团队手动分配 IP 地址，流程繁琐且易出错。 +- 方法/机制：声明式 IPAM YAML 文件驱动自动化供给；Infoblox Grid 作为 IP 地址单一可信数据源；CIDR ≥ /22 自动通过，< /22 触发网络团队审批；使用 AZ ID 而非 AZ Name 确保跨区域一致性。 +- 结论/价值：**用户只需在正确位置填入信息，VPC 供给流程全自动完成**，IP 地址冲突由 Infoblox 阻止，支持多 VPC 同时供给和邮件通知。 ## Key Claims（用中文描述） -- IPAM 通过 Infoblox Grid 自动管理 IP 地址，消除手工操作，显著降低配置错误率。 -- 工作负载 VPC 供给完全自动化，YAML 文件仅声明业务联系人、工程联系人和父 CIDR，不再包含硬编码 IP 地址。 -- CIDR 块大小决定审批流程：/22 或更大自动批准，更小（如 /24）需提交理由并由网络团队审批。 -- Infoblox Grid 作为全局唯一 IP 地址数据源，防止多账号环境中的 IP 地址重叠冲突。 -- 使用 AZ ID（可用区标识符）而非 AZ Name（可用区名称）避免不同 AWS 账户对同一物理位置命名不一致的问题。 -- 邮件通知机制覆盖用户和网络团队，全程透明可追溯。 -- Infoblox 架构包含位于休斯顿数据中心的主数据库，以及冗余的 DNS、NTP 和 DHCP 服务。 +- IPAM（Infoblox Grid）通过自动化 IP 地址管理，消除手工干预，显著降低错误率。 +- 工作负载 VPC 自动化流程使用声明式 YAML 文件指定业务联系人、工程联系人和父 CIDR，无需手工规划 IP 地址。 +- CIDR 前缀 ≥ /22 时自动通过审批；< /22 时必须由网络团队审核理由后才能继续供给。 +- 使用 Availability Zone ID（az id）替代 Availability Zone Name（az name），避免不同区域命名不一致导致的跨区域部署问题。 +- Infoblox Grid 作为 IP 地址中央管理平台，防止 IP 地址重叠，并维护所有已配置 IP 的记录供查询。 +- 当前增强功能包括：多 VPC 批量供给、邮件通知、额外 CIDR 块支持、非可路由 IP 地址支持（如 10.2.0.0/16）。 +- VPC 销毁时，Infoblox 自动清理对应 IP 记录，保持 IP 地址池的实时同步。 ## Key Quotes -> "We don't need to worry about IP address. If it's beyond IP address is 22 or greater, then only we need to take the approval." — Pushka，IPAM 自动化审批阈值说明 +> "We don't need to worry about IP address. If it's beyond IP address is 22 or greater, then only we need to take the approval." — Pushka (Principal SRE)，说明 IPAM 自动化大幅简化了 IP 地址管理流程 -> "So we just need to put the information at the right place and everything will work." — Pushka，用户只需提供正确信息，IPAM 自动完成其余工作 +> "So we just need to put the information at the right place and everything will work." — Pushka，强调用户只需提供业务信息，底层流程全自动化 ## Key Concepts -- [[IPAM（IP Address Management）]]：企业级 IP 地址管理自动化平台，通过声明式配置替代手工分配。本视频展示了 IPAM 与 AWS VPC 供给的深度集成。 -- [[Infoblox-Grid]]：核心 IPAM 引擎，包含容器、IP地址及可扩展属性（元数据，如 owner、company、status），维护全局唯一 IP 地址记录。 -- [[VPC-自动化供给]]：通过 YAML 配置文件声明业务参数，自动触发 VPC 创建流程，无需网络团队手工介入。 -- [[CIDR-审批流程]]：/22 及更大 CIDR 自动批准；/22 以下需提交理由经网络团队审批后供给。 -- [[Availability-Zone-ID]]：AWS 可用区标识符（az-id），用于避免多账号环境中 AZ 名称（az-name）不一致问题。 +- [[IPAM]]：IP Address Management，即 IP 地址管理。本视频聚焦 Infoblox NIOS IPAM 平台，用于 AWS VPC 环境中的自动化 IP 地址分配和回收。 +- [[Infoblox Grid]]：企业级 IPAM 解决方案，作为 IP 地址的单一可信数据源，支持容器化部署和可扩展属性（元数据）管理。 +- [[Workload VPC]]：承载业务工作负载的 AWS VPC，与基础设施 VPC 分离，由 IPAM 自动化供给。 +- [[CIDR]]：Classless Inter-Domain Routing，用于 VPC IP 地址块划分。本视频中 /22 为审批阈值。 +- [[Availability Zone ID]]：AWS AZ 的唯一标识符（如 use1-az1），优于 AZ Name（如 us-east-1a），因为同一 AZ Name 在不同账户可能映射到不同物理位置。 ## Key Entities -- [[Pushka]]（Principal SRE）：IPAM 与 VPC 自动化方案的发起人和演示者，Topic 61 主讲人。 -- [[Infoblox]]：IPAM 供应商，提供 Grid 架构及 NIOS 平台，负责管理所有账号的 IP 地址分配记录。 -- [[AWS-Landing-Zone]]：本方案的实施背景——企业级多账号 AWS 环境，IPAM 作为 LZ 网络层的核心组件。 +- [[Pushka]]：Principal SRE，本视频主讲人，介绍 IPAM 与 Workload VPC 自动化供给方案。 +- [[Infoblox]]：IPAM 软件供应商，Houston 数据中心部署主数据库，提供 DNS、NTP、DHCP 冗余服务。 ## Connections -- [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] ← extends ← [[ctp-topic-61-workload-vpc-provision-with-ipam-automation]] - - Topic 45 介绍 IPAM 自动分配机制；Topic 61 展示该机制在 Workload VPC 供给中的完整应用。 -- [[ctp-topic-22-global-dns-service-offerings]] ← shares_infra ← [[Infoblox-Grid]] - - Infoblox 同时支撑 DNS Anycast 和 IPAM 服务，是网络层多服务的统一基础设施。 -- [[ctp-topic-31-network-segregation-and-secure-access]] ← depends_on ← [[VPC-自动化供给]] - - VPC 自动化供给是网络分段和安全访问策略的基础前提。 +- [[CTP Topic 45 Automatic IP Address Allocation with IPAM]] ← extends ← [[CTP Topic 61 Workload VPC Provision with IPAM Automation]] + - 说明：Topic 45 介绍 IPAM 自动分配 IP 地址的核心机制；Topic 61 聚焦于 Workload VPC 层级的完整自动化供给流程，包含审批机制和增强功能。 ## Contradictions -- 无已知冲突内容。 +- 暂未发现与现有 Wiki 页面的内容冲突。 diff --git a/wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md b/wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md index fde40aad..725445b3 100644 --- a/wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md +++ b/wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md @@ -5,52 +5,54 @@ tags: - Value-Tracing - Cloud-Transformation - CTP + - Lean + - WSJF date: 2026-04-14 --- ## Source File -- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md]] +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md]] ## Summary（用中文描述） -- 核心主题：云转型中的价值交付量化框架与工作优先级排序方法 -- 问题域：如何系统性地衡量、捕获和优先排序云转型工作中的业务价值 -- 方法/机制：①定义过程（Process）和价值流（Value Stream）概念；②建立全局收益框架（财务、生产力、质量、体验四维度）；③使用加权最短作业优先（WSJF）方法对工作进行经济性排序；④在功能级别拆解价值归属 -- 结论/价值：云转型工作应以"最小投入尽早交付最大价值"为原则，通过量化收益和成本延迟比来优化工作排序，实现经济收益最大化 +- 核心主题：云转型计划（CTP）中的价值交付追踪方法论——如何量化、分解和优先排序云转型工作的业务价值。 +- 问题域：云转型项目如何衡量和证明业务价值；如何让产品团队和需求经理对齐价值期望；如何用经济驱动的方式排序工作。 +- 方法/机制： + - 区分 Process（过程）、Value（价值）、Value Stream（价值流）三个层次； + - 将业务价值分解为财务、生产力、质量、体验四个维度； + - 使用 WSJF（Weighted Shortest Job First，加权最短作业优先）公式：`Cost of Delay / Job Size` 决定工作优先级； + - 功能级价值分解策略：单功能归因、均匀分摊、非均匀分摊（按覆盖度/影响力/工时）。 +- 结论/价值：通过结构化价值捕获框架（年收入增长 + 成本降低 + 风险改善 + SOM），以最小投入尽早交付最大价值，循环学习调优。 ## Key Claims（用中文描述） -- 过程（Process）是由输入（数据、资源、时间、资金、专业知识）驱动的系统性步骤，将输入转化为产出和成果，成果分为硬性（时间、成本、质量）和软性（健康、安全） -- 价值（Value）由客户决定，体现为公平回报或等价商品；Lean 识别三类活动：增值活动、价值赋能活动、浪费 -- 价值流（Value Stream）是向客户交付产品或服务的系列活动，分为运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品） -- 收益捕获需要全局框架，涵盖财务、生产力、质量和体验四个维度，聚焦收入增长、成本降低、风险改善和服务可获得市场规模（SOM） -- 加权最短作业优先（WSJF）方法通过"延迟成本/作业规模"比值对工作排序，实现最大经济收益 -- 延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会 +- 过程（Process）是一组有序步骤，将输入（数据、资源、时间、资金、知识）转化为输出和结果，结果分为硬性（时间、成本、质量）和软性（健康、安全）两类。 +- 价值由客户定义，是事物的货币价值，涉及公平回报或等价商品；Lean 将活动分为三类：增值活动（Value-Adding）、价值赋能活动（Value-Enabling）、浪费（Waste）。 +- 价值流（Value Stream）是一组为客户交付产品或服务的活动集合；Scaled Agile 定义了运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）两类。 +- 价值捕获需要综合框架，涵盖财务、生产力、质量和体验四个维度，重点关注收入增长、成本降低、风险改善和服务可获得市场规模（SOM）。 +- WSJF 优先级排序公式：`CoD（业务价值 + 时间紧迫性 + 风险与机会）/ 工作规模`，最大化经济收益地排列工作顺序。 +- 功能级价值分解的三种方式：单功能归因全部价值、按功能均匀分摊、按覆盖度/影响力/工时等标准非均匀分摊。 ## Key Quotes -> "What we want to do is deliver the maximum value early back into the business for the least amount of effort." — CTP Topic 65 核心目标 -> "A simple way of thinking of an outcome is that there's usually going to be a desirable change in some important attribute or indicator." — 成果的定义 -> "For each demand, the demand manager captures these five things from the product team. Financial figures should be annualized." — 需求管理流程 -> "The weighted shortest job first method prioritizes work based on cost of delay divided by size of job." — WSJF 优先级排序公式 +> "Value is defined as the monetary worth of something, determined by the customer, involving a fair return or equivalent goods." — 价值的核心定义：由客户决定货币价值 + +> "What we want to do is deliver the maximum value early back into the business for the least amount of effort." — 云转型工作的核心目标：以最小投入尽早交付最大价值 + +> "A simple way of thinking of an outcome is that there's usually going to be a desirable change in some important attribute or indicator." — 理解结果（Outcome）的简单方式：某个重要属性或指标的可期望变化 ## Key Concepts -- [[Process]]：由输入驱动的系统性步骤，将输入转化为产出和成果 -- [[Value]]：由客户决定的货币价值，体现为公平回报 -- [[Value-Stream]]：向客户交付产品或服务的系列活动，包含 OVS（运营价值流）和 DVS（开发价值流） -- [[Value-Adding]]：Lean 中的增值活动类型 -- [[Waste]]：Lean 中的浪费活动类型 -- [[Benefits-Quantification]]：财务、生产力、质量、体验四维度收益量化框架 -- [[Cost-of-Delay]]：延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会 -- [[WSJF]]：Weighted Shortest Job First，通过 Cost of Delay / Size of Job 比值排序工作 -- [[SOM]]：Serviceable Obtainable Market，可服务可获得市场规模 -- [[Feature-Level-Value-Breakdown]]：在功能级别拆解和分配价值的方法 +- [[Value Stream]]：一组为客户交付产品或服务的活动集合；OVS 面向客户，DVS 面向内部产品 +- [[Weighted Shortest Job First (WSJF)]]：优先级排序公式，`CoD / Job Size`，最大化经济收益 +- [[Cost of Delay (CoD)]]：延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会 +- [[Process]]：将输入转化为输出和结果的有序步骤集合，触发于事件（如月末、冲刺规划） +- [[Value-Adding Activity]]：Lean 中直接为客户创造价值的活动 +- [[Serviceable Obtainable Market (SOM)]]：服务可获得市场规模，用于评估市场机会 ## Key Entities -- [[CTP]]：Cloud Transformation Programme，云转型计划（本视频来源项目） -- [[Scaled-Agile]]：SAFe 框架定义了 OVS 和 DVS 概念（本视频引用） +- [[Cloud Transformation Programme (CTP)]]：OpenText 的云转型计划，主题来源 ## Connections -- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ← relates_to ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（均涉及敏捷方法管理云转型） -- [[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]] ← extends ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（需求流程与价值量化协同） -- [[ctp-topic-30-managing-change]] ← relates_to ← [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]（变更管理与价值交付的关系） +- [[CTP Topic 53 Why bother with Cloud]] ← context ← [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]]（CTP 53 回答"为何要上云"，本主题回答"如何衡量云转型价值"） +- [[CTP Topic 57 Product backlog managing demand]] ← extends ← [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]]（需求管理是价值交付的前置流程） +- [[CTP Topic 4 Using Agile to Run the Cloud Transformation Programme]] ← relates_to ← [[CTP Topic 65 Tracing the Value Delivered in Cloud Transformation]]（敏捷方法支撑价值交付的迭代循环） ## Contradictions -- 与 [[ctp-topic-53-why-bother-with-cloud]] 的视角张力：Topic 53 质疑迁移必要性，Topic 65 假设迁移已决策并聚焦如何量化交付价值。两者互补而非逻辑矛盾——前者回答"是否迁移"，后者回答"如何衡量价值"。 +- （暂无发现与其他 Wiki 页面的明显冲突） diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md b/wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md index 963974fd..c12d6f59 100644 --- a/wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md +++ b/wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md @@ -37,22 +37,26 @@ date: 2024-07-23 - [[RTO]]（Recovery Time Objective）：事件发生后恢复服务所需时间，OpenText 跨度从分钟到数天 - [[RPO]]（Recovery Point Objective）：可接受的最大数据丢失量，同样因客户合同而异 - [[SRE]]（Site Reliability Engineering）：用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性 -- [[Observability Engineering]]（可观测性工程）：通过遥测数据持续理解系统健康状态，是 Recovery Assurance 的技术基础 -- [[Disaster Recovery]]（灾难恢复）：保护系统免受灾难性事件影响的策略与实践 -- [[Business Continuity Plan]]（业务连续性计划）：确保业务在灾难期间持续运营的规划框架 +- [[Observability]]（可观测性）：通过遥测数据持续理解系统健康状态，是 Recovery Assurance 的技术基础 +- [[Disaster-Recovery]]（灾难恢复）：保护系统免受灾难性事件影响的策略与实践 - [[Self-Healing]]（自愈能力）：软件应具备持续监控系统健康并在无需人工干预情况下自动恢复的能力 -- [[Customer Zero Environment]]：新版本发布前的内部验证环境，用于在真实流量前发现潜在问题 +- [[Customer-Zero]]（Customer Zero Environment）：新版本发布前的内部验证环境，用于在真实流量前发现潜在问题 +- [[Recovery-Assurance]]（恢复保证）：DR 的演进方向，从被动应对转向主动设计、持续验证、自动化保证系统恢复能力 ## Key Entities - [[OpenText]]：企业信息管理公司，托管于 AWS/GCP/Azure 多云环境，由 Jim Rose 主讲本次学习会议 -- [[Jim Rose]]：OpenText 技术负责人/演讲者，分享 DR 向 Recovery Assurance 演进的实践与思考 - [[CrowdStrike]]：2024 年引发全球大规模系统中断的安全软件公司，作为 DR 重要性案例被引用 ## Connections -- [[ctp-topic-72-enterprise-dr-strategy-aws-backup]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（均涉及企业 DR 策略，CTP Topic 72 提供 AWS Backup 层面的具体实现，本视频提供组织层面的演进思维） +- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（均涉及企业 DR 策略，CTP Topic 72 提供 AWS Backup 层面的具体实现，本视频提供组织层面的演进思维） - [[ctp-topic-41-nfrs-and-error-budgets]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（NFR/Error Budget 是 SRE 度量弹性目标的工具，与本视频的 SRE 转型方向一致） - [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（可观测性工程是 Recovery Assurance 的技术基础，OpenTelemetry 是具体实现路径） - [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related_to ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（EKS 可靠性工程实践与本视频的四位框架中的 Environments 层对应） +- [[Disaster-Recovery]] ← described_by ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（本视频是 DR 向 Recovery Assurance 演进的权威来源） +- [[Recovery-Assurance]] ← introduced_by ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（Recovery Assurance 四位框架在本视频中首次系统阐述） +- [[Observability]] ← technology_enabler ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（可观测性是 Recovery Assurance 的核心技术基础） +- [[Self-Healing]] ← software_capability ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（自愈能力是 Recovery Assurance 在软件层面的实现） +- [[Customer-Zero]] ← validation_environment ← [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]（Customer Zero 是 Recovery Assurance Build 环节的核心实践） ## Contradictions - 无已知冲突。本视频提供 DR 向 Recovery Assurance 演进的方法论框架，与现有 Wiki 中的 DR 相关内容（CTP Topic 72 AWS Backup 实施、CTP Topic 44 AWS Backup 评估）互补而非冲突，共同构成完整的 DR 知识体系。 diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md b/wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md index 13d64e19..e066ed77 100644 --- a/wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md +++ b/wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md @@ -1,41 +1,60 @@ --- title: "Public Cloud Learning Sessions - OpenText Tagging Standard v2 - 20250429" type: source -tags: [] -date: 2026-04-14 +tags: + - OpenText + - Tagging-Standard + - FinOps + - Cloud-Governance + - Kubernetes + - Container +date: 2026-04-29 --- ## Source File - [[raw/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 成本优化的基础，同时支撑安全合规、资源组织和自动化工作流 +- 核心主题：OpenText 云标签标准 V2 版本——扩展至 Kubernetes 对象和容器镜像标签规范 +- 问题域：云资源标签不一致、成本归属困难、Kubernetes 和容器镜像缺乏标签标准 +- 方法/机制：OT_ 前缀（云资源）、app.opentext.com 前缀（K8s 标签）、com.opentext.image 前缀（容器镜像）、Terraform IaC 自动打标 +- 结论/价值：V2 在 2023 年 V1 基础上扩展覆盖范围至 K8s 和容器镜像，帮助统一 3,500 个云账户的标签体系 ## Key Claims（用中文描述） -- OpenText 通过标准化标签驱动成本优化的三大机制：成本分配、风险降低（快速定位技术联系人）、自动化效率提升 -- Phenops 团队 2023 年发起的标签标准现已扩展至 Kubernetes 对象和容器镜像，覆盖 3,500 个云账户和 48 种 landing zone 类型 -- 标签治理最佳实践：IaC 自动化替代手动打标、检测报告发现缺失标签、禁止在标签中存储敏感数据 +- 标签标准三大驱动：省钱（FinOps 成本优化）、降险（快速定位技术联系人）、提效（自动化筛选） +- OpenText 管理约 3,500 个云账户、48 种 Landing Zone 类型，亟需统一的标签标准 +- V2 标签标准由 Phenops 团队于 2023 年发起，现已扩展至 Kubernetes 对象和容器镜像 +- 标签标准涵盖范围：云账户、云资源（计算/存储/网络）、K8s 对象（Namespace/Pod/Deployment/Service/ConfigMap）、容器镜像 +- 标准鼓励在现有专有标签基础上逐步采用标准标签，最终替代专有标签 +- 最佳实践：使用 Terraform 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." — 标签标准的适用对象概述 +> "It is about taking resources and you will learn more in the presentation about what kinds of object and what exactly and so on." — Martin Rosler 介绍 V2 标准覆盖的资源类型范围 + +> "Texts 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." — 标签本质定义 ## Key Concepts -- [[Terraform]]：基础设施即代码工具，用于自动化标签创建和维护 -- [[Kubernetes]]：容器编排平台，标签标准扩展至其对象（namespaces、pods、deployments、services、config maps） -- [[Container-Images]]：容器镜像，标签标准包含 product、title、description、vendor 等元数据标签 +- [[Resource-Tagging]]：云资源标签的核心概念，V2 扩展了 K8s 和容器镜像维度 +- [[FinOps]]：云财务管理，三大驱动之一 +- [[AWS-Tagging-Standards]]：OpenText 标签标准是 AWS 标签规范的扩展 +- [[Terraform]]：通过 IaC 自动化标签创建和维护 +- [[Kubernetes-Tagging]]（待新建）：K8s 标签标准，app.opentext.com 前缀 +- [[Container-Image-Tagging]]（待新建）：容器镜像标签标准，com.opentext.image 前缀 +- [[Multi-Cloud-Governance]]：跨云统一标签治理 ## Key Entities -- [[Martin-Rosler]]：讲师，介绍 OpenText Tagging Standard V2 的核心内容和三大驱动力 -- [[Phenops-Team]]：发起标签标准（2023年）的团队，原始版本已扩展 Kubernetes 和容器镜像指南 +- [[Phenops-Team]]：发起并维护 OpenText 标签标准的 FinOps 执行团队 +- [[OpenText]]：企业主体，管理 3,500 个云账户的标签治理 +- [[Martin Rosler]]（待新建）：V2 标签标准演讲者 ## 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 预防控制的存量检查补充） +- [[public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123]] ← extends ← 本页 + - V2 是 V1 的扩展，V1 覆盖云账户/云资源，V2 新增 K8s 对象和容器镜像 +- [[ctp-topic-28-aws-tag-validation-tool]] ← relates_to ← 本页 + - Tag Validation Tool 可用于验证 V2 标签标准的合规性 +- [[public-cloud-learning-sessions-reducing-cloud-costs-20250318]] ← relates_to ← 本页 + - FinOps 成本优化是标签标准三大驱动之一，V2 补充了标准化标签体系 +- [[Resource-Tagging]] ← is_source_of ← 本页 ## Contradictions -- 与 [[ctp-topic-28-aws-tag-validation-tool]] 在标签强制能力边界上无矛盾，两者互补：标签标准定义「应该怎么标」，验证工具发现「谁没标好」 +- 无明显冲突。V2 在 V1 基础上扩展，保持向前兼容