Auto-sync: 2026-04-28 20:03

wiki/overview.md

@@ -300,15 +300,15 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter
 
 **[[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]**（CTP Topic 35）：AWS Landing Zone 设计复习——重点明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS Landing Zone 为每个产品区域提供客户专属环境，产品账户连接至共享服务账户（安全、日志、网络）；核心账户组包含 AD、DNS 和 Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断对 SaaS 工作负载的直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一审计；入站流量拟通过 Network 账户 Checkpoint 重新路由；原生 AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：**SaaS = 生产，Labs = 开发**；PoC Landing Zone 将并入 Labs 以最大化资源共享；Cloud Technology Design Forum 推动 Micro Focus 云交付标准化。
 
-**[[ctp-topic-6-aws-workspaces-demo]]**（CTP Topic 6）：AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面（Windows Server 2016），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号，接收注册码和用户名后登录，可立即访问 AWS Console（Federation）和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行，达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（基础架构）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 流程）共同构成完整的"架构→交付→使用"链路。
+**[[ctp-topic-34-azure-landing-zone-architecture-overview]]**（CTP Topic 34）：Azure Landing Zone 架构概述——Kishore Garlopati 讲解 Micro Focus 内部 Azure 采用方案。核心架构：通过 Azure Enterprise Enrollment + Azure AD 完成企业接入；使用管理组（Management Groups）按四区组织订阅——platform（身份管理/连接）、landing zones（可扩展/模块化/全自动化模板）、decommission（停用资源）、sandbox（隔离实验）。连接订阅作为所有入站/出站 Azure 流量的中心枢纽，集成 DDoS 防护和 Checkpoint 防火墙。Terraform Cloud 通过 Terraform State 管理跨订阅依赖；PIM（Privileged Identity Management）强制最小权限访问。核心价值：团队在自动化保障下独立部署工作负载，减少跨团队依赖。与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（AWS LZ）和 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（Gruntwork LZ）共同体现 CTP 多云战略——AWS 侧用 Gruntwork/Jenkins，Azure 侧用 Terraform Cloud，平台差异由多云架构驱动。
 
-**[[public-cloud-learning-sessions-aws-end-user-compute-services-20240430]]**（Public Cloud Learning Sessions，Christian O'Donough 主讲）：AWS 终端用户计算（EUC）服务全景介绍——覆盖四大服务：① **Workspaces**（全持久虚拟桌面，适合知识工作者一对一实例管理）；② **AppStream 2.0**（选择持久/非持久应用流，多租户模式降低成本，适合实验室/培训/堡垒主机）；③ **Workspace Core**（提供 VDI 基础设施 API，支持 Horizon View、Citrix 等第三方集成）；④ **Workspace Web**（低成本安全浏览器）。核心选型原则：需要完整桌面 → Workspaces；非持久桌面/应用流 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 Active Directory 集成、加密、IAM 配置文件、SAML 认证和多因素认证。属 [[AWS-Landing-Zone]] 用户端计算层的理论基础，与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）共同构成完整的 EUC 知识体系。
+**[[ctp-topic-6-aws-workspaces-demo]]**（CTP Topic 6）：AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面（Windows Server 2016），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号，接收注册码和用户名后登录，可立即访问 AWS Console（Federation）和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行，达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（基础架构）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 流程）共同构成完整的"架构→交付→使用"链路。
 
 **[[ctp-topic-7-saas-landing-zone-design]]**（CTP Topic 7）：SAS 生产 Landing Zone 顶层架构设计——定义了完整的四层账户体系：①核心账户（Core Accounts）：Shared 托管 AMI + 主 Jenkins 服务器通过 Lambda 触发各账户 Jenkins slave；Logs 集中管理所有账户日志（CloudTrail/Config/Flowlogs）；Security 托管 IAM 角色。②基线账户（Baseline Accounts）：Network 账户部署区域级 Transit Gateway + Checkpoint Appliance 按标签监控跨账户流量；DNS 账户托管 Route 53，各产品拥有独立托管区；Active Directory 账户提供双 AD 节点实现域加入和资源访问控制。③共享服务账户（Shared Services Accounts）：Software Factory（45 个 hub + Octane Hub + Artifactory）、Cyber（Qalis）、ARC Site、Monitoring（OBM/Sitescope）。④产品账户（Product Accounts）：工作负载置于私有子网，公有子网通过负载均衡器和互联网网关对外暴露，WAF 监控入站流量。自动化部署链路：GitHub 仓库变更 → Jenkins（GitHub Hook 触发）→ Management VPC → Lambda → ECS Cluster，Staging 测试后才部署生产。远程访问从 Checkpoint VPN 迁移至 Pulse VPN（通过 AD 认证）。属 [[AWS-Landing-Zone]] 的原始设计规范，与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（近期变更）共同构成 SAS LZ 的设计演进脉络。
 
 **[[ctp-topic-1-gruntwork-landing-zone-architecture]]**（CTP Topic 1）：Gruntwork AWS Landing Zone 架构基础——核心概念：参考架构（Reference Architecture）是包含核心账户 Shared/Logs/Security 和工作负载账户 Prod/Stage/Dev 的最佳实践起点；Landing Zone 基于 Gruntwork 仓库但由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User），通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流。属整个 CTP Landing Zone 系列的基础入门篇。
 
-**[[learning-sessions-standard-amis-updates]]**（Learning Sessions 20231205）：AWS 标准 AMI 更新机制与生命周期管理——Jenkins 多分支流水线构建测试 AMI，验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；机器人框架自动化验证是该优化流程的核心。属 [[AWS-Landing-Zone]] AMI 管理层的实践补充。
+**[[learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2]]**（Learning Sessions 20231205）：AWS 标准 AMI 更新机制与生命周期管理——Jenkins 多分支流水线构建测试 AMI，验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；机器人框架自动化验证是该优化流程的核心。属 [[AWS-Landing-Zone]] AMI 管理层的实践补充。
 
 **[[ctp-topic-50-ami-roadmap-for-aws-amis]]**（CTP Topic 50）：CCOE AMI 路线图详解——涵盖 CCOE AMI 路线图规划、操作系统 EOL 时间线（Windows Server 2008/2008 R2 已 EOL；CentOS 8 已 EOL；Windows Server 2012 将于 2023 年 10 月 EOL；RHEL 7 和 CentOS 7 将于 2024 年 6 月 EOL）、AMI 通知机制、变更日志（CCRE 门户）、新 AMI 添加流程（服务集成→功能启用→构建测试）、当前支持的 AMI 清单及未来路线图（SLES 15/RHEL 9 2022年11月；openSUSE 15/Amazon Linux 2022 2023年1月；Rocky 8/9 2023年3月；RHEL 9.4 ARM/Ubuntu 22.04 ARM 2023年5月）。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。属 [[AWS-Landing-Zone]] AMI 层的路线图补充，与 [[ctp-topic-26-standard-ami-build-publish-share-processes]]（生命周期管理）和 [[ctp-topic-58-aws-ec2-image-builder]]（未来演进方向 EC2 Image Builder）共同构成完整的 AMI 管理知识体系。
 
@@ -410,7 +410,9 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast
 
 **[[ctp-topic-23-introduction-to-the-technical-architecture-team-and-function]]**（CTP Topic 23）：技术架构团队职能与云转型价值——Martin Nash（技术架构经理）主讲。核心内容：①组织变革背景——PSTC 与 IT 部门整合至 CIO 统一领导下，实现两个大型组织的深度融合；②云优先策略——除非数据主权、合规性或极端成本原因必须保留在本地，否则所有新业务优先上云；③三层架构分工——EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理；④技术领域划分——将技术栈划分为身份认证、网络、Microsoft 堆栈等领域，每个领域由首席架构师负责其生命周期与路线图；⑤主动规划转型——通过制定 12-24 个月技术路线图，从被动响应转向预测性规划，帮助业务部门规避风险、优化预算、提升交付速度。属 [[AWS-Landing-Zone]] 架构治理层的核心补充，与 [[ctp-topic-47-enterprise-architecture-cloud-standards]]（EA 云标准）共同构成企业架构知识体系。
 
-**[[ctp-topic-72-enterprise-dr-strategy-aws-backup]]**（CTP Topic 72）：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计——核心内容：HA（高可用）关注系统运行时间和 MTBF，DR（灾难恢复）专注于防止数据丢失和系统恢复，两者互补；RPO（恢复点目标）定义可接受的最大数据丢失量，RTO（恢复时间目标）定义可接受的最大停机时间；AWS Backup 完全托管、基于策略，通过 Backup Plans 定义何时备份什么，Backup Vaults 存储恢复点，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）提供从低成本到高弹性的递进选择；增量备份仅捕获变更，节省成本；Vault Lock 合规模式防止任何人（包括根用户）提前删除恢复点，有效防勒索软件；建议使用独立的 Vault/Bunker Account 存储备份副本，取证账户（Forensic Account）定期测试恢复点并扫描恶意软件。属 [[AWS-Landing-Zone]] DR 与数据保护层的理论基础补充，与 [[ctp-topic-44-aws-backup-in-micro-focus]]（聚焦 Micro Focus 内部评估）和 [[ctp-topic-73-aws-backup-implementation]]（聚焦 CTP 迁移实施）构成完整的 AWS Backup 知识体系。
+**[[ctp-topic-72-enterprise-dr-strategy-aws-backup]]**（CTP Topic 72）：AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计——核心内容：HA（高可用）关注系统运行时间和 MTBF，DR（灾难恢复）专注于防止数据丢失和系统恢复，两者互补；RPO（恢复点目标）定义可接受的最大数据丢失量，RTO（恢复时间目标）定义可接受的最大停机时间；AWS Backup 完全托管、基于策略，通过 Backup Plans 定义何时备份什么，Backup Vaults 存储恢复点，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）提供从低成本到高弹性的递进选择；增量备份仅捕获变更，节省成本；Vault Lock 合规模式防止任何人（包括根用户）提前删除恢复点，有效防勒索软件；建议使用独立的 Vault/Bunker Account 存储备份副本，取证账户（Forensic Account）定期测试恢复点并扫描恶意软件。属 [[AWS-Landing-Zone]] DR 与数据保护层的理论基础补充，与 [[ctp-topic-44-aws-backup-in-micro-focus]]（聚焦 Micro Focus 内部评估）和 [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]]（聚焦 CTP 迁移落地）构成完整的 AWS Backup 知识体系。
+
+**[[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]]**（CTP Topic 73）：AWS Backup 在云转型计划（CTP）中的具体落地实施——SRE Core/Product/Architecture 团队协作设计 SRE 备份模型，使产品团队能在各自 DRA 账户内独立管理备份。预设备份策略：生产工作负载客户数据至少每 24 小时备份一次，保留期至少 30 天，备份存储于两个位置。AWS Backup 被选为 CTP 战略备份工具，因其原生托管、支持 80+ AWS 资源类型、跨账户/跨区域备份、不可变性、开箱即用审计报告及 S3/RDS 时间点恢复（PITR）。架构设计：初始备份在源账户完成，复制到专属 DR 账户（每个生产工作负载账户对应一个 DR 账户），确保备份保留在 DR 账户内实现即时恢复，无需耗时数据拷贝；DR 账户不可用时回退至 Databunker 集中账户。SRE 备份模型简化 AWS Backup 接入：自动创建 Backup Plans、Selections、Local AWS Backup Vaults、KMS 密钥策略、DR 账户额外 Vault、注册策略、生命周期策略、SNS 主题、审计报告及可选 PITR。AWS Backup Audit Manager 提供合规框架，包括备份覆盖率检查、最小频率和保留期验证、手动删除防护、加密验证及计划性跨区域/跨账户备份。属 [[AWS-Landing-Zone]] DR 与数据保护层的实施层补充，与 [[ctp-topic-72-enterprise-dr-strategy-aws-backup]]（理论基础）和 [[ctp-topic-44-aws-backup-in-micro-focus]]（Micro Focus 评估）共同构成"理论→实施→内部评估"完整体系。
 
 **[[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]**（RTO vs RPO: Key Differences for Modern Disaster Recovery）：RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）在现代灾难恢复与持续交付中的关键区别与实践应用——核心区分：RTO 衡量系统停机时长容忍度（从故障时刻开始计时），RPO 衡量数据丢失容忍度（从上一备份时刻向前测量）；现代部署环境下软件故障（Bug/错误迁移/AI 模型异常）比硬件灾难更频繁，每日常规发布即潜在 RTO/RPO 场景。Feature Flag 驱动的新范式：通过部署与发布解耦（Deploy whenever you want, release when you're ready）、渐进式灰度发布（1%→5%→25%→100%）和 Kill Switch（即时禁用故障功能），将 RTO 从"小时级紧急回滚部署"缩短至"秒级配置开关切换"，RPO 通过 Feature Flag 保护数据完整性避免回滚时数据损坏。应用分层恢复策略：Tier 1 Critical（支付/认证，RTO<5min/RPO<1min）→ Tier 2 Important（管理后台/报表，RTO<1h/RPO<15min）→ Tier 3 Nice-to-have（内部工具，RTO<4h/RPO<1h）。成本效益原则：若停机1小时损失 $10K，不要每年花 $100K 基础设施预防——Feature Flag 方案比传统热备基础设施成本更低、效果更好（HP/Christian Dior 案例）。属 [[ctp-topic-72-enterprise-dr-strategy-aws-backup]]（AWS 基础设施层 DR）在软件交付层的互补——前者聚焦备份基础设施，后者聚焦代码层快速恢复，共同构成完整 DR 知识体系；与 [[what-i-know-about-cloud-service-delivery-1]]（"备份恢复与灾难管理"第12领域）形成引用关系；与 [[cloud-devop-maturity-guideline]] 的 DORA MTTR 指标关联（MTTR 直接量化 RTO）。