Sync: expand data model and gitops notes
This commit is contained in:
@@ -1,28 +1,44 @@
|
||||
---
|
||||
title: "GitOps"
|
||||
type: concept
|
||||
tags: [devops, gitops, infrastructure, git]
|
||||
sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]
|
||||
last_updated: 2026-04-22
|
||||
tags:
|
||||
- DevOps
|
||||
- CI/CD
|
||||
- Kubernetes
|
||||
- Infrastructure as Code
|
||||
---
|
||||
|
||||
## Summary
|
||||
GitOps is a DevOps methodology that uses Git as the single source of truth for managing infrastructure and application deployments. All desired state is stored in Git repositories, and automated tools (like ArgoCD or Flux) continuously reconcile the actual cluster state with the desired state defined in Git. It is identified as a key future trend in DevOps for managing both infrastructure and deployments declaratively.
|
||||
## Definition
|
||||
GitOps 是一种将软件开发的版本控制与协作原则应用于云原生基础设施和应用部署的方法论。核心思想：**使用 Git 作为单一事实来源（Single Source of Truth）声明系统的期望状态，由自动化代理（GitOps Controller）持续协调实际状态向期望状态收敛。**
|
||||
|
||||
## Key Concepts
|
||||
## Four Principles
|
||||
1. **声明式配置（Declarative Configuration）**：所有基础设施和应用配置必须以声明式代码描述，而非命令式脚本
|
||||
2. **版本控制（Version Control）**：所有配置存储在 Git 仓库中，享受完整的变更历史、代码审查和回滚能力
|
||||
3. **CD 流程分离（CD Process Separation）**：CI 专注构建和分析代码，CD 专注部署，两者解耦增强安全性
|
||||
4. **自修复协调器（Automated Reconciliation）**：GitOps Controller 持续监控实际状态与 Git 声明状态，自动调和偏差
|
||||
|
||||
### Core Principles
|
||||
1. **The entire system described declaratively** — All infrastructure and application configurations are stored as code
|
||||
2. **The canonical desired state in Git** — Git is the source of truth; any change goes through Git workflow
|
||||
3. **Approved changes automatically pulled into the system** — Automated agents detect drift and reconcile
|
||||
## Key Benefits
|
||||
- 开发者只需掌握 Git 即可完成安全部署
|
||||
- 分钟级代码变更上线
|
||||
- 零停机回滚（Git 历史即回滚计划）
|
||||
- Git 提交日志天然构成合规审计追踪
|
||||
- 提高开发者生产力（使用熟悉的工具）
|
||||
|
||||
### Tools
|
||||
- **ArgoCD** — Kubernetes-native GitOps controller
|
||||
- **Flux** — GitOps toolkit for Kubernetes
|
||||
- **Atlantis** — Terraform GitOps automation (mentioned in CTP topics)
|
||||
## Pull Model vs Push Model
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture]] — GitOps is an operational pattern emerging from DevOps culture
|
||||
- [[Infrastructure as Code (IaC)]] — GitOps extends IaC with Git-centric workflows
|
||||
- [[CI/CD Pipeline]] — GitOps can be considered a specialized CI/CD pattern
|
||||
- [[Continuous Improvement (Kaizen)]] — GitOps enables continuous, auditable improvements
|
||||
| | Pull Model（推荐） | Push Model |
|
||||
|---|---|---|
|
||||
| 机制 | 部署代理主动监控 Git 和目标系统 | CI/CD 管道主动推送变更到目标 |
|
||||
| 安全性 | 更高——系统状态不暴露给外部 | 较低——需外部访问目标系统 |
|
||||
| 代表工具 | ArgoCD, Flux | Jenkins CI/CD, Terraform Cloud |
|
||||
| 适用场景 | GitOps 核心模式 | 传统 CI/CD 扩展 |
|
||||
|
||||
## Relationship with IaC
|
||||
GitOps 是 [[Infrastructure as Code]] 的部署编排层：
|
||||
- **IaC**：定义"基础设施应该是什么样的"（Terraform/Pulumi/HCL）
|
||||
- **GitOps**：定义"如何确保基础设施始终符合声明"（ArgoCD/Flux/Atlantis）
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 方法论入门，Victor Etkin 主讲
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] — Atlantis 作为 GitOps 工具实践
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] — Gruntwork CI/CD 与 GitOps 的关联
|
||||
|
||||
@@ -4,6 +4,9 @@
|
||||
- [Overview](overview.md) — living synthesis
|
||||
|
||||
## Sources
|
||||
- [2026-04-24] [Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416](sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md)
|
||||
- [2026-04-24] [CTP Topic 33 An Introduction to GitOps](sources/ctp-topic-33-an-introduction-to-gitops.md)
|
||||
- [2026-04-24] [CTP Topic 3 Deploy and maintain infrastructure](sources/ctp-topic-3-deploy-and-maintain-infrastructure.md)
|
||||
- [2026-04-24] [CTP Topic 9 CI CD with Gruntwork](sources/ctp-topic-9-ci-cd-with-gruntwork.md)
|
||||
- [2026-04-24] [CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments](sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md)
|
||||
- [2026-04-24] [CTP Topic 2 Git](sources/ctp-topic-2-git.md)
|
||||
@@ -411,9 +414,6 @@
|
||||
- [2026-04-19] [ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co](sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md) — (expected: wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md — source missing)
|
||||
- [2026-04-19] [ctp-topic-15-working-with-renovatebot](sources/ctp-topic-15-working-with-renovatebot.md) — (expected: wiki/sources/ctp-topic-15-working-with-renovatebot.md — source missing)
|
||||
- [2026-04-19] [ctp-topic-56-automated-infrastructure-testing](sources/ctp-topic-56-automated-infrastructure-testing.md) — (expected: wiki/sources/ctp-topic-56-automated-infrastructure-testing.md — source missing)
|
||||
- [2026-04-19] [public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16](sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md) — (expected: wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md — source missing)
|
||||
- [2026-04-19] [ctp-topic-33-an-introduction-to-gitops](sources/ctp-topic-33-an-introduction-to-gitops.md) — (expected: wiki/sources/ctp-topic-33-an-introduction-to-gitops.md — source missing)
|
||||
- [2026-04-19] [ctp-topic-3-deploy-and-maintain-infrastructure](sources/ctp-topic-3-deploy-and-maintain-infrastructure.md) — (expected: wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md — source missing)
|
||||
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
|
||||
- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
|
||||
- [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
|
||||
|
||||
35
wiki/log.md
35
wiki/log.md
@@ -1,3 +1,22 @@
|
||||
## [2026-04-24] ingest | Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416
|
||||
- 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
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Oli 工作流（超大规模云厂商支出审批三级工作流）+ 需求管理自动化端到端流程（ITIL 框架、Octane/Qixi 提交入口、主服务目录嵌入 SMACs、"机器做机器能做的事"理念）
|
||||
- Concepts identified: [[Demand-Management]], [[ITIL-Service-Management]], [[FinOps]], [[SMACs]]
|
||||
- Entities identified: [[Tom-Bice]], [[FPNA-Team]], [[MUI]], [[Shannon]], [[Octane]], [[Qixi]]
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md
|
||||
- Notes: entities 和 concepts 目录均为空（无历史页面）；未满足 ≥2 次出现条件，不新建独立页面，以 wikilink 形式记录于 Source page；index.md 已更新；overview.md Cloud Transformation 章节已补充（置于 ctp-topic-57 后）；已建立与 ctp-topic-57（Backlog 管理管道）、ctp-topic-65（价值量化）、public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109（需求分析前置技法）、ctp-topic-4（敏捷实践）的连接关系
|
||||
- Conflicts: （暂无）
|
||||
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Landing Zone 环境下通过 Terraform/Terragrunt 实现基础设施部署与维护的完整方法论；核心区分 Service Module（业务视角）与 Regular Module（技术视角）的分层抽象；Terragrunt HCL 版本锁定；Service Catalog 三级复用（单账户→产品团队→跨团队）
|
||||
- Concepts identified: [[Service Module]], [[Service Catalog]], [[Terragrunt]], [[Infrastructure as Code]], [[Terraform Module]]
|
||||
- Entities identified: [[Gruntwork]], [[AWS Landing Zone]]
|
||||
- Source page: wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md
|
||||
- Notes: 已建立与 ctp-topic-1（Gruntwork LZ 架构）、ctp-topic-9（CI/CD with Gruntwork）、ctp-topic-32（Atlantis CI/CD）、ctp-topic-33（GitOps 入门）、ctp-topic-39（EKS Atlantis 约束差异）的连接关系；Service Module/Service Catalog 仅出现 1 次，不满足 ≥2 次建页条件，以 wikilink 形式记录于 Source page；index.md 已更新；overview.md Cloud Transformation & DevOps 章节已更新
|
||||
- Conflicts: 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 存在 Atlantis EKS 支持约束差异（Topic 3 通用原则 vs Topic 39 具体实践）
|
||||
|
||||
## [2026-04-24] ingest | CTP Topic 9 CI CD with Gruntwork
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -2354,3 +2373,19 @@
|
||||
- 新增 Entity 页面：Jay-Comer.md
|
||||
- 新增 Concept 页面：OpenTelemetry.md
|
||||
- 冲突检测：与 ctp-topic-54-esm-saas-log-analytics（ELK 日志）、ctp-topic-67（CTP Topic 67 OpenTelemetry）互补，无冲突
|
||||
|
||||
## [2026-04-25] ingest | CTP Topic 33 An Introduction to GitOps
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-33-an-introduction-to-gitops.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: GitOps 方法论入门——将软件开发原则应用于部署流程；四大原则（声明式配置 + 版本控制 + CD 流程分离 + 自修复协调器）；Pull 模型优于 Push 模型；幂等平台（Kubernetes）是 CD 顺利运行的必要条件；Git 提交日志即合规审计追踪
|
||||
- Concepts created: [[GitOps]]
|
||||
- Entities identified: [[Victor Etkin]]
|
||||
- Source page: wiki/sources/ctp-topic-33-an-introduction-to-gitops.md
|
||||
- Notes:
|
||||
- 新增 1 个 Source Page
|
||||
- 新增 1 个 Concept 页面：GitOps.md（覆盖四大原则、Pull vs Push 模型、与 IaC 关系）
|
||||
- index.md 更新：新增条目于 CI_CD_GitOps 分类
|
||||
- overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节，GitOps 知识链路
|
||||
- Key Entities 中提及的 Victor Etkin 仅出现 1 次，不满足 ≥2 次条件，以 wikilink 形式记录于 Source page
|
||||
- Key Concepts 中 Kubernetes/Atlantis 已有 wikilink 指向其他 Source page
|
||||
- 冲突检测：与 ctp-topic-39（Atlantis 不支持 EKS）存在 Atlantis + Kubernetes 实践约束差异，已记录于 Source page Contradictions
|
||||
|
||||
@@ -39,12 +39,16 @@ Key concepts: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Refer
|
||||
**[[multi-source-tech-news-digest]]**：AI Agent 驱动的多源科技新闻自动聚合与投递系统——四层数据管道整合 46 个 RSS 源、44 个 Twitter/X KOL 账号、19 个 GitHub Releases 仓库和 4 个 Brave Search 主题，覆盖 109+ 信息源；通过标题相似度去重和多维度质量评分（priority source +3, multi-source +5, recency +2, engagement +1）生成精选简报；支持 Discord/Email/Telegram 三通道投递，30 秒内通过自然语言添加自定义来源。属 [[Daily-YouTube-Digest]] / [[Daily Reddit Digest]] 同款 Cron Job + AI 摘要模式的不同垂直场景（前者视频，后者 Reddit 社区，本方案文字新闻）。
|
||||
|
||||
### Cloud Transformation & DevOps
|
||||
Git 是云转型计划中 DevOps 与 CI/CD 流水线的基础技能。**[[ctp-topic-2-git]]**（CTP Topic 2）作为 CI/CD/GitOps 系列的开篇，涵盖 Git 版本控制系统基础概念与实践，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）和 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 入门）构成完整的学习链路。**[[ctp-topic-9-ci-cd-with-gruntwork]]**（CTP Topic 9）聚焦 CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践，基于 Gruntwork 参考架构通过 Terraform/Terragrunt 实现基础设施自动化交付（⚠️ 视频待 Whisper 转录后补充详细内容）。
|
||||
Git 是云转型计划中 DevOps 与 CI/CD 流水线的基础技能。**[[ctp-topic-2-git]]**（CTP Topic 2）作为 CI/CD/GitOps 系列的开篇，涵盖 Git 版本控制系统基础概念与实践，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）和 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 入门）构成完整的学习链路。**[[ctp-topic-3-deploy-and-maintain-infrastructure]]**（CTP Topic 3）深入 Landing Zone 环境下的基础设施部署方法论——核心区分：Service Module（业务视角，满足业务需求的一组模块组合）与 Regular Module（技术视角，单一技术构建块）；Terragrunt HCL 文件通过版本锁定而非 master 分支引用模块；Service Catalog 支持三级复用（单账户→产品团队→跨团队）。类 OO 继承原则：抽象层次越高，配置选项越少。Terragrunt 在运行前预取所有依赖，通过缓存目录管理克隆仓库。属 IaC 模块化治理的基础原则层，与 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 实践）和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）共同构成完整的 IaC 知识链路。注意：[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 提到 Atlantis 当前不支持 EKS 部署，两者存在实践约束差异，需通过 Jenkins + Terragrunt 替代。
|
||||
|
||||
**[[ctp-topic-9-ci-cd-with-gruntwork]]**（CTP Topic 9）聚焦 CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践，基于 Gruntwork 参考架构通过 Terraform/Terragrunt 实现基础设施自动化交付（⚠️ 视频待 Whisper 转录后补充详细内容）。
|
||||
|
||||
Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps.
|
||||
|
||||
**[[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]**（CTP Topic 32）：Atlantis 替代 Jenkins 用于 Terraform IaC 部署——针对当前 Jenkins 流水线初始化慢（多次代码克隆/顺序测试/ECS 预配置）和架构复杂（持续叠加功能导致脆弱）的双重痛点，Atlantis 提供 PR 评论式协作模型，开发者直接在 GitHub PR 上评论 `atlantis plan`/`apply` 即可触发变更，无需独立账号；每个 Landing Zone 共享账户部署单台 EC2 实例，通过 GitHub Enterprise Webhook 接收通知，服务账号负责评论/合并/关闭 PR；跨账户访问通过在各账户部署的 IAM 角色实现；并行构建支持多模块并发 plan/apply；锁定机制防止多 PR 同时操作同一模块产生冲突。Atlantis 在 merge 前即应用变更，确保代码与基础设施始终同步。属 [[GitOps]] 工具实践层，与 [[ctp-topic-33-an-introduction-to-gitops]]（GitOps 概念）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）共同构成完整链路。注意：[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 提到 Atlantis 当前不支持 EKS 部署，两者存在实践约束差异。
|
||||
|
||||
**[[ctp-topic-33-an-introduction-to-gitops]]**（CTP Topic 33）：Victor Etkin 讲解 GitOps 方法论入门——GitOps 将软件开发原则应用于部署流程，解决部署失败和配置不一致问题。四大原则：声明式配置、版本控制、CD 流程分离、自修复协调器；核心工具仅需 Git。GitOps Controller 持续比对 Git 声明的期望状态与系统实际状态，自动调和偏差。Pull 模型（代理同时监控 Git 和目标系统）比 Push 模型安全性更高，是 GitOps 推荐模式。CI 专注代码构建和分析，CD 专注二进制部署，两者解耦增强安全性。幂等平台（如 Kubernetes）是 CD 流程顺利运行的必要条件。Git 提交日志天然构成合规审计追踪。属 [[GitOps]] 概念层核心来源，与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 工具）和 [[ctp-topic-2-git]]（Git 基础）共同构成 CI/CD/GitOps 完整知识链路。
|
||||
|
||||
**[[ctp-topic-21-supply-chain-security-in-micro-focus]]**（CTP Topic 21）：Micro Focus 产品安全小组 Shlomi Ben-Hur 主讲的软件供应链安全新方法——核心议题：在云转型背景下，软件供应链安全已成为企业安全战略的重中之重。供应链（产品层面）涵盖源码管理（SCM）、构建组件（CI）、制品库到最终交付系统（CD）的所有环节，Micro Focus 内部存在 17 种不同 SCM 工具的极高多样性。主要驱动因素：SolarWinds 攻击事件（通过渗透构建过程注入恶意代码）、美国网络安全行政命令、以及向 AWS/SaaS 迁移带来的开放性风险。核心转变：从过去 99% 关注研发安全（代码扫描/渗透测试）转向全生命周期安全防护；供应链安全成为 SDL（安全开发生命周期）的第五大支柱，强调必须同时确保 CI 过程（构建环境/自动化服务器）和 CD 过程（交付系统）的完整性，防止黑客在任何环节篡改二进制文件。属 [[Supply Chain Security（供应链安全）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[DevSecOps]]（开发安全运维一体化）高度关联。
|
||||
|
||||
**[[ctp-topic-24-micro-focus-product-privacy-framework]]**（CTP Topic 24）：Micro Focus 产品隐私框架在云转型中的应用——PSAC（产品安全顾问委员会）与法律顾问合作，将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求；隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一；通过五类需求（架构类/文档类/法律类/实现类/SAS 运营类）和成熟度模型（0-4 级）评估产品隐私合规状态；通过"蜘蛛图"直观展示产品在安全去标识化、被遗忘权、数据可移植性等 KPI 上的合规现状；最终产出标准化《产品隐私设置文档》，确保客户获得一致的隐私信息参考。属 [[Product Privacy Framework（产品隐私框架）]] 在 [[Micro Focus]] 云转型场景的核心实践，与 [[Micro Focus Security Development Life Cycle (STLC) Overview]]（STLC 整体架构）直接关联。
|
||||
@@ -155,6 +159,8 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast
|
||||
|
||||
**[[ctp-topic-57-product-backlog-managing-demand]]**（CTP Topic 57）：CTP 产品待办列表（Backlog）需求管理完整管道——①需求提交（通过 SMACs 启动计时器和追踪）→ ②双周评审会议（Matthew Chapman/David Grant/Brendan）评估理解度、价值和优先级，约20题评估问卷判断简洁性、成本和野心程度 → ③Octane 特性化（带任务列表）→ ④Sprint 规划（提前6个 Sprint，50% 新需求 / 50% 支持+技术债）→ ⑤Prerequisite Phase（新产品组入职：介绍会议→AWS账户创建→解决方案设计→GitHub仓库→防火墙标签，产品团队约2小时，1-2周）→ ⑥SRE 构建账号并交接（提供控制台/GitHub访问详情）→ ⑦2周 Hyper Care 支持。现有产品组通过 SMACs/邮件/Teams 请求支持，Teams 频道连接产品组、SRE工程师、解决方案架构师和交付经理。核心理念：**透明化需求管道，确保所有工作以同一标准评估**。属 [[AWS-Landing-Zone]] 需求治理层的核心补充，与 [[ctp-topic-20-program-demand-process-flow]]（Gate Process 和 POC 入职）、[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]（敏捷实践）、[[ctp-topic-30-managing-change]]（变更管理与 SRE 协作）共同构成完整的 CTP 治理知识体系。
|
||||
|
||||
**[[public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16]]**（Public Cloud Learning Sessions，Oli Workflow）：超大规模云厂商支出审批工作流与需求管理端到端流程——涵盖两大部分：① **Oli 工作流审批机制**：所有超大规模云厂商支出无论金额均需 MUI 或 Shannon 书面审批；Oli 系统由 Tom Bice 领导的 FinOps 团队接管，正在集成到 SMACs 平台；提议的三阶段审批工作流（FinOps 可行性验证→云服务技术可行性验证→FPNA 团队预算可用性验证）；Oli 系统提供飞行中 CSV 报告追踪状态/申请人/成本中心/月成本。② **OpenText 需求管理全链路**：ITIL 框架下服务战略→设计→过渡→运营→持续改进五阶段；主服务目录（Combined Cloud Products Master Catalog）将嵌入 SMACs；Octane 和 Qixi 是两大需求提交入口；ADM/ITOM 需求规划会议捕获所需内容、数量和发布版本；核心理念：**"机器做机器能做的事"，目标 80% 场景业务单元自助完成需求选择**。属 [[Demand-Management]] 和 [[FinOps]] 在 OpenText 云转型场景的核心实践，与 [[ctp-topic-57-product-backlog-managing-demand]]（Backlog 管理管道）共同构成完整的需求治理知识体系。
|
||||
|
||||
**[[ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation]]**（CTP Topic 65）：云转型中的价值交付量化框架——提供系统性衡量、捕获和优先排序云转型业务价值的方法论。核心内容：①基础概念——过程（Process）将输入转化为产出/成果，成果分硬性（时间/成本/质量）和软性（健康/安全）；Lean 识别三类活动：增值活动、价值赋能活动、浪费；价值（Value）由客户决定，体现为公平回报；②价值流（Value Stream）分为运营价值流（OVS，面向客户）和开发价值流（DVS，内部产品）；③收益量化框架——涵盖财务、生产力、质量和体验四个维度，聚焦收入增长、成本降低、风险改善和服务可获得市场规模（SOM）；④WSJF 优先级排序——通过 Cost of Delay / Size of Job 比值对工作排序，实现"最小投入尽早交付最大价值"；延迟成本 = 业务价值 + 时间紧迫性 + 风险与机会；⑤功能级价值拆解——可按单一功能归属、均分或不均匀分配（基于触达/影响/努力等标准）。属 [[AWS-Landing-Zone]] 价值治理层的核心方法论，与 [[ctp-topic-30-managing-change]]（变更管理）和 [[ctp-topic-20-program-demand-process-flow]]（需求流程）共同构成完整的 CTP 治理知识体系。
|
||||
|
||||
**[[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]**（CTP Topic 20）：云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：①需求来源——主要由业务案例（如数据中心关闭）、高层管理人员战略优先级及产品路线图驱动；②Gate Process——Gate 0 评估准入、Gate 1 负责 Design Authority 审批、Gate 3 作为启动迁移的最终准入；③POC 目的——不仅验证架构和技术可行性，还包括让团队熟悉基于 Gruntwork 的新一代 Landing Zone；④新环境特点——强调 IaC（Terraform/Terragrunt）自动化部署，严禁手动构建；⑤PCG 团队——平台控制组，负责提供云环境支持、安全策略制定及协助产品组进行 POC；⑥成功标准——POC 成功标准必须在启动前明确定义。属 CTP 治理知识体系入口，与 [[ctp-topic-65]]（价值量化）、[[ctp-topic-57]]（需求管理）、[[ctp-topic-30]]（变更管理）共同构成完整的治理框架链条。
|
||||
|
||||
@@ -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 提供通用原则，两者约束条件不同不构成直接矛盾
|
||||
62
wiki/sources/ctp-topic-33-an-introduction-to-gitops.md
Normal file
62
wiki/sources/ctp-topic-33-an-introduction-to-gitops.md
Normal file
@@ -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 工作负载
|
||||
@@ -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
|
||||
- 无已知冲突页面
|
||||
Reference in New Issue
Block a user