Sync: expand data model and gitops notes

wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md

@@ -0,0 +1,62 @@
+---
+title: "CTP Topic 3 Deploy and maintain infrastructure"
+type: source
+tags:
+  - IaC
+  - Deployment
+  - CI/CD
+  - CTP
+  - Terraform
+  - Terragrunt
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Landing Zone 环境下通过 Terraform/Terragrunt 实现基础设施部署与维护的完整方法论
+- 问题域：多账户、多产品团队环境下 IaC 模块化复用、服务目录治理、Terragrunt 依赖管理
+- 方法/机制：Service Module（业务视角）vs Regular Module（技术视角）的分层抽象；Terragrunt HCL 引用特定版本模块；Service Catalog 三级复用（单账户→产品团队→跨团队）；Terragrunt 缓存目录预取依赖
+- 结论/价值：模块化 IaC 实现独立发布周期和可维护性；Service 层抽象减少配置复杂度，越高层抽象选项越少（类 OO 继承）；推荐使用专用 Service Catalog 而非相对路径引用
+
+## Key Claims（用中文描述）
+- Product Team 在 Landing Zone 中部署基础设施时，跨越多个账户（如 Artifactory 账户、AD 账户），涉及多个 Git 仓库协同
+- Service Module 由 main.tf 文件引用其他仓库模块组合而成，满足特定业务需求（如 AD 服务、DNS 服务）
+- Service 抽象层次高于 Regular Module，提供更少配置选项但更易使用
+- Terragrunt 优于直接引用 master 分支，target 特定版本确保环境一致性
+- 复用层次：单账户使用 → 产品团队 Service Catalog → Terraform Service Catalog（跨团队）
+- Terragrunt 在运行前预取所有引用，通过缓存目录存储克隆的仓库
+
+## Key Quotes
+> "A service is a business requirement, while a regular module is a technical requirement." — 核心区分：Service 解决业务问题，Module 解决技术问题
+
+> "When deploying infrastructure, Terragrunt HCL files are used to reference these services, targeting specific versions rather than the master branch." — 版本控制优于分支引用
+
+> "The higher up the chain, the less configuration options are available, similar to an object-oriented approach." — 抽象层次与配置灵活性的反向关系
+
+## Key Concepts
+- [[Landing Zone（落地区）]]：云环境的基础账户结构和资源隔离框架，产品团队在此之上部署工作负载
+- [[Service Module（服务模块）]]：满足业务需求的一组 Terraform 模块组合，相较于技术模块提供更高级抽象
+- [[Service Catalog（服务目录）]]：可复用模块的集中管理库，支持三级复用（账户/产品团队/跨团队）
+- [[Terragrunt]]：Terraform 的薄包装层，支持依赖管理、缓存和版本锁定
+- [[Terraform Module]]：Terraform 的可复用配置单元，版本化管理
+- [[Infrastructure as Code（IaC）]]：通过代码管理和配置基础设施的实践
+
+## Key Entities
+- [[AWS Landing Zone]]：AWS 多账户环境框架，是本文档讨论的基础部署上下文
+- [[Gruntwork]]：提供 Terraform 模块参考架构的公司，本文多次引用其作为最佳实践模型
+- [[Product Team]]：在 Landing Zone 中部署工作负载的业务团队，拥有独立的账户集合
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← foundational ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← related ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-33-an-introduction-to-gitops]] ← extends ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+
+## Contradictions
+- 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 的 Atlantis 部分存在约束差异：
+  - 冲突点：Atlantis 对 EKS 部署的支持能力
+  - 当前观点（Topic 3）：Terragrunt 可用于所有基础设施部署，包括 EKS
+  - 对方观点（Topic 39）：Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代
+  - 评估：Topic 39 提供更具体的实践经验，Topic 3 提供通用原则，两者约束条件不同不构成直接矛盾

wiki/sources/ctp-topic-33-an-introduction-to-gitops.md

@@ -0,0 +1,62 @@
+---
+title: "CTP Topic 33 An Introduction to GitOps"
+type: source
+tags:
+  - GitOps
+  - CI/CD
+  - Kubernetes
+  - DevOps
+  - Infrastructure as Code
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-33-an-introduction-to-gitops.md]]
+
+## Summary（用中文描述）
+- 核心主题：GitOps 方法论入门——将软件开发原则应用于部署流程，实现声明式基础设施自动化交付
+- 问题域：解决部署失败、配置不一致、手动操作风险等传统 CI/CD 问题
+- 方法/机制：四大原则（声明式配置 + 版本控制 + CD 流程分离 + 自修复协调器）+ Pull/Push 两种部署模型
+- 结论/价值：开发者只需掌握 Git 即可完成安全部署，代码变更分钟级上线，Git 日志即审计追踪
+
+## Key Claims（用中文描述）
+- GitOps 四大原则使部署过程完全自动化，代码变更可在数分钟内安全部署上线
+- Pull 模型比 Push 模型更适合 GitOps——部署代理同时监控 Git 和目标系统，提供额外安全层
+- 幂等（Idempotent）平台（如 Kubernetes）是 CD 流程顺利执行的必要条件
+- GitOps 是 DevOps 的逻辑演进，Git 提交日志天然构成合规审计追踪
+- CI 与 CD 应解耦——CI 专注构建和分析代码，CD 专注部署二进制文件，解耦增强安全性
+
+## Key Quotes
+> "The only tool a developer needs to know is Git." — Victor Etkin
+> "GitOps uses Git workflows, CD pipelines, and infrastructure as code. Observability is crucial for ensuring the desired and actual states align."
+> "An IDEMPOTENT operation is one that can be applied multiple times without changing the result beyond the initial application."
+> "GitOps is a logical evolution of DevOps, simplifying adoption and enhancing portability. Git commit logs become audit trails, streamlining compliance."
+
+## Key Concepts
+- [[GitOps]]：将软件开发原则（Git 版本控制 + Pull Request 协作）应用于基础设施和应用部署的方法论，核心是通过声明式配置描述期望状态，GitOps 控制器自动协调实际状态向期望状态收敛
+- [[Idempotent Deployment（幂等部署）]]：同一操作可重复执行而结果不变的特性，是 GitOps CD 流程顺利运行的必要前提，Kubernetes 是典型的幂等平台
+- [[Pull Model]]：GitOps 推荐部署模型——部署代理持续监控 Git 仓库和目标系统状态，检测到差异时自动从 Git 拉取变更并应用，天然提供额外安全层（系统状态不暴露给外部）
+- [[Push Model]]：CI/CD 管道主动推送变更到目标系统的部署模式，相比 Pull 模型安全性较低但实现更简单
+- [[Declarative Configuration（声明式配置）]]：通过代码描述"系统应该是什么状态"而非"如何一步步到达该状态"，是 GitOps 和 Infrastructure as Code 的核心原则
+- [[Infrastructure as Code（基础设施即代码）]]：用代码管理基础设施的实践，与 GitOps 高度协同，共同构成自动化部署的基础
+- [[GitOps Controller]]：运行在目标环境中的自动化代理，持续比对 Git 中声明的期望状态与系统实际状态，自动调和偏差，无需人工干预
+
+## Key Entities
+- [[Victor Etkin]]：GitOps 入门视频主讲人，阐述 GitOps 四大原则及 Pull 模型优势
+- [[Weaveworks]]：GitOps 概念的提出者和早期推广者（视频背景知识）
+- [[Kubernetes]]：GitOps 最常用的部署目标平台，其声明式 API 和自修复机制与 GitOps 高度契合
+- [[Atlantis]]：基于 Pull Request 的 Terraform IaC 自动化工具（参见 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]），属 GitOps 工具实践层
+
+## Connections
+- [[ctp-topic-2-git]] ← foundational_skill ← [[GitOps]]（Git 版本控制是 GitOps 的基础工具）
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← extends ← [[GitOps]]（CI/CD 是 GitOps 的核心组件）
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← implements ← [[GitOps]]（Atlantis 是 GitOps 工具实践）
+- [[GitOps]] ← complements ← [[DevOps]]（GitOps 是 DevOps 的逻辑演进）
+- [[Amazon EKS]] ← platform ← [[GitOps]]（K8s 是 GitOps 最常用目标平台）
+- [[GitOps]] ← extends ← [[Infrastructure as Code]]（GitOps 是 IaC 的部署编排层）
+
+## Contradictions
+- 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 存在实践约束差异：
+  - 冲突点：Atlantis 当前不支持 EKS 部署
+  - 当前观点（Topic 33）：Kubernetes 是 GitOps 的主要应用场景
+  - 对方观点（Topic 39）：Atlantis 需通过 Jenkins + Terragrunt 替代方案处理 EKS 工作负载

wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md

@@ -0,0 +1,58 @@
+---
+title: "Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416"
+type: source
+tags:
+  - Workflow
+  - Demand-Process
+  - FinOps
+  - ITIL
+  - SMACs
+date: 2024-04-16
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md]]
+
+## Summary（用中文描述）
+- 核心主题：Oli 工作流（超大规模云厂商支出审批流程）与需求管理全链路
+- 问题域：云转型过程中的 FinOps 支出审批治理、需求提交与自动化履约
+- 方法/机制：ITIL 服务管理框架下的三级审批工作流（FinOps 可行性→云服务技术可行性→FPNA 预算可用性），以及 OpenText 端到端需求管理流程（Octane/Qixi 提交 → 主服务目录 → SMACs 嵌入 → 自动化履约）
+- 结论/价值：所有超大规模云厂商支出（含工程实验室和商业工作负载）无论金额均需 MUI/Shannon 书面审批；推动"机器做机器能做的事"，目标是 80% 场景业务单元自助完成需求提交
+
+## Key Claims（用中文描述）
+- 所有超大规模云厂商支出（含工程实验室和商业工作负载空间）无论金额，均需 MUI 或 Shannon 书面审批
+- Oli 工作流由 Tom Bice 领导的 FinOps 团队接管，正在集成到 SMACs 平台
+- 提议的三阶段工作流：FinOps 可行性验证 → 云服务技术可行性验证 → FPNA 团队预算可用性验证
+- Oli 系统提供飞行中 CSV 报告，追踪工作流状态、申请人、成本中心、月成本及当前步骤
+- ITIL 框架将业务流程分为服务战略、设计、过渡、运营、持续改进五个阶段
+- 主服务目录（Combined Cloud Products Master Catalog）将嵌入 SMACs，目标是 80% 场景下业务单元可自助选择所需服务
+- ADM 和 ITOM 需求规划会议记录所需内容、数量和发布版本
+
+## Key Quotes
+> "If justification details are not provided, requests are subject to immediate rejection." — Oli 请求提交规范
+> "Machines should do what machines can do, enabling an automated fulfillment process." — OpenText 需求管理核心理念
+> "The goal is for business units to self-select what they need 80% of the time." — 需求管理自动化目标
+
+## Key Concepts
+- [[Demand-Management（需求管理）]]：平衡需求与可用容量的必要手段，是 ITIL 服务过渡阶段的关键活动
+- [[ITIL-Service-Management]]：将业务流程分为服务战略、服务设计、服务过渡、服务运营、持续服务改进五阶段，Oli 工作流对应请求履约的第一阶段
+- [[SMACs]]：Social、Mobile、Analytics、Cloud 的技术栈组合，Oli 工作流正在集成到 SMACs 平台
+- [[FinOps]]：财务运营，Tom Bice 团队负责 Oli 工作流接管，重点关注云支出的可视性与优化
+- [[Product-Backlog]]：产品待办列表，Oli 工作流产生的请求经审批后进入 Backlog 管理
+
+## Key Entities
+- [[Tom-Bice]]：FinOps 团队负责人，正在接管 Oli 工作流并集成到 SMACs
+- [[FPNA-Team]]：财务规划与分析团队，负责工作流第三阶段——预算可用性验证
+- [[MUI]]：超大规模云厂商支出审批人之一（与 Shannon 共同审批所有云支出请求）
+- [[Shannon]]：超大规模云厂商支出审批人之一（与 MUI 共同审批所有云支出请求）
+- [[Octane]]：超大规模云厂商 SaaS 产品需求管理平台，业务单元可直接向其提交需求
+- [[Qixi]]：Oli 需求提交流程的前端接口之一，业务单元通过其提交需求
+
+## Connections
+- [[ctp-topic-57-product-backlog-managing-demand]] ← extends ← 本文档（Oli 工作流审批通过的请求进入产品 Backlog 管理管道）
+- [[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]] ← depends_on ← 本文档（需求管理是价值交付量化框架的前置管道）
+- [[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]] ← related_to ← 本文档（BOSCARD 框架是需求分析的前置技法）
+- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] ← related_to ← 本文档（Kanban 敏捷实践为需求流转提供方法论支撑）
+
+## Contradictions
+- 无已知冲突页面