Auto-sync: 2026-04-20 00:02

wiki/sources/Public-Cloud-Learning-Sessions-Budget-Control.md

@@ -0,0 +1,51 @@
+---
+title: "Public Cloud Learning Sessions - Budget Control - 20240319"
+type: source
+tags:
+  - AWS
+  - Budget-Control
+  - FinOps
+  - Cloud-Monitoring
+date: 2024-03-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md]]
+
+## Summary
+- 核心主题：AWS账户预算控制自动化，提供账户所有者详细的支出警报和成本分析报告，实现成本控制
+- 问题域：AWS账户成本失控、无法识别成本驱动因素、缺乏 enforce 机制
+- 方法/机制：AWS Budget Alerts + Lambda 处理 + Step Functions + SNS 触发 + SCP 限制
+- 结论/价值：
+
+  - 警报类型：forecast、actual、severe、enforcement 四级
+  - 详细报告：top services、top users、资源级别的成本明细
+  - 执行机制：8小时评估间隔，100%阈值触发SCP阻止新资源创建
+
+## Key Claims
+- 预算控制自动化解决 AWS 账户蔓延和成本削减不可持续的问题
+- 源身份追踪确保跨角色切换时 CloudTrail 仍能追踪原始登录身份
+- 评分系统考虑账户规模和月末时间，避免惩罚月末轻微超支的账户
+
+## Key Quotes
+> "The budget control automation aims to address uncontrolled AWS account sprawl and unsustainable cost reduction efforts."
+
+> "This is the first time that we were able to get to this level of granularity."
+
+## Key Concepts
+- [[Budget Control]]：AWS账户预算控制自动化系统
+- [[AWS Budget Alerts]]：AWS预算警报服务，四级警报类型
+- [[SCP]]：Service Control Policy，组织策略用于限制AWS服务使用
+- [[Source Identity]]：源身份追踪，记录跨角色切换前的原始登录身份
+
+## Key Entities
+- [[SRE Core Team]]：预算控制自动化开发团队（Daniela、Evan、Alan）
+- [[FinOps]]：云财务运营团队，负责预算审批和成本管理
+
+## Connections
+- [[AWS]] ← uses ← [[Budget Alerts]]
+- [[SRE Core Team]] ← develops ← [[Budget Control]]
+- [[FinOps]] ← approves ← [[Budget Enforcement Actions]]
+
+## Contradictions
+- 无冲突记录

wiki/sources/Public-Cloud-Learning-Sessions-OpenText-Serverless-Computing-20240903.md

@@ -0,0 +1,52 @@
+---
+title: "Public Cloud Learning Sessions (OpenText)- Serverless Computing - 20240903"
+type: source
+tags:
+  - Serverless
+  - AWS
+  - Lambda
+  - OpenText
+  - Cloud Learning
+date: 2024-09-03
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md]]
+
+## Summary
+- 核心主题：AWS 无服务器计算（Serverless Computing）学习会议
+- 问题域：云原生架构、事件驱动计算、无服务器函数
+- 方法/机制：Lambda 事件触发机制、Step Functions 工作流编排、API Gateway API 管理、SAM 本地开发
+- 结论/价值：Serverless 模式帮助企业快速上市、聚焦业务、降低 TCO、按需付费、自动扩展
+
+## Key Claims
+- Lambda 函数由事件触发（状态变化），支持同步、异步、事件源映射三种调用方式
+- AWS 与客户共担运维责任，AWS 负责基础设施，客户负责代码
+- Lambda 版本和别名用于管理代码变更，发布新版本后可通过别名指向
+- Lambda Layers 支持跨函数共享公共代码
+
+## Key Quotes
+> "Lambda functions are triggered by events, which are changes in state."
+> Whenever you see that you have written code and you want that this code is final, you can publish as a new version.
+
+## Key Concepts
+- [[Lambda]]：AWS 无服务器计算服务，开发者只需编写业务逻辑，AWS 处理基础设施
+- [[Step Functions]]：无服务器工作流服务，基于状态机编排多个 AWS 服务
+- [[API Gateway]]：托管服务，用于创建、发布和保护 API
+- [[Serverless Application Model]]：SAM，本地开发和部署无服务器应用的工具，基于 CloudFormation
+- [[Event-driven Computing]]：事件驱动计算，Lambda 函数的触发机制
+- [[Execution Role]]：Lambda 执行角色，定义函数可以执行的操作
+- [[Resource-based Policy]]：基于资源的策略，定义谁可以触发函数
+
+## Key Entities
+- [[AWS]]：云服务提供商
+- [[OpenText]]：企业软件公司
+
+## Connections
+- [[Lambda]] ← powers ← [[Step Functions]]
+- [[Lambda]] ← exposed_by ← [[API Gateway]]
+- [[Lambda]] ← deployed_with ← [[Serverless Application Model]]
+- [[AWS Lambda]] ← manages_infrastructure ← [[Event-driven Computing]]
+
+## Contradictions
+- 与传统 EC2 对比：EC2 提供灵活性和控制，Lambda 允许开发者聚焦业务逻辑

wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md

@@ -1,7 +1,7 @@
 ---
 title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
 type: source
-tags: [灾难恢复, 业务连续性, 持续交付, 特性管理]
+tags: [disaster-recovery, RTO, RPO, feature-flag, launchdarkly]
 date: 2019-01-18
 sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
 last_updated: 2026-04-19
@@ -19,35 +19,38 @@ last_updated: 2026-04-19
 ## Key Claims
 - RTO 衡量系统恢复速度：允许的最大停机时间
 - RPO 衡量数据保护：可接受的最大数据丢失量
-- 传统灾备聚焦硬件故障，现代风险更多来自代码变更
+- 传统灾备聚焦硬件故障，现代风险更多来自代码变更（部署 bug、数据库迁移、AI 模型更新等）
 - Feature Flag 将 RTO 从小时级降至秒级，同时保护 RPO
 - 应用分层策略：Critical（<5分钟 RTO，<1分钟 RPO）、Important（<1小时 RTO，<15分钟 RPO）、Nice-to-have（<4小时 RTO，<1小时 RPO）
 
 ## Key Quotes
+> "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose." — 核心区别定义
+
 > "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users." — 部署与发布分离的核心价值
 
 > "The best approach is to build both into your deployment process. Feature flags enable you to resolve issues in seconds (a great RTO) while preserving user state and data integrity (a great RPO)." — Feature Flag 双重优势
 
 > "Prevention beats cure. Your RPO stays low because you're not losing data during rollbacks. Your RTO drops to seconds because fixing issues becomes a configuration change, not a code deployment." — 预防优于恢复
 
+> "Ultimately, you can't just optimize for one. Having backups every 30 seconds (a great RPO) doesn't help if it takes you 6 hours to restore from those backups (a terrible RTO)." — RTO 与 RPO 必须同时优化
+
 ## Key Concepts
-- [[RTO (Recovery Time Objective)]]：系统允许的最大停机时间
-- [[RPO (Recovery Point Objective)]]：可接受的最大数据丢失量
+- [[RTO]]：Recovery Time Objective，系统允许的最大停机时间
+- [[RPO]]：Recovery Point Objective，可接受的最大数据丢失量
 - [[Feature Flag]]：特性开关，控制代码路径而不需要重新部署
 - [[Kill Switch]]：紧急关闭机制，用于快速回滚问题功能
 - [[渐进式发布]]：分阶段向用户群 rollout，减少影响范围
 
 ## Key Entities
-- [[LaunchDarkly]]：Feature Flag 管理平台
+- [[LaunchDarkly]]：Feature Flag 管理平台，帮助实现秒级回滚和渐进式发布
 - [[HP]]：通过 Feature Flag 将回滚时间从小时降至分钟
 - [[Christian Dior]]：通过 Feature Flag 将回滚时间从15分钟降至即时切换
 
 ## Connections
-- [[RTO (Recovery Time Objective)]] ← 核心指标 ← [[持续交付]]
-- [[RPO (Recovery Point Objective)]] ← 核心指标 ← [[持续交付]]
-- [[Feature Flag]] ← 实现工具 ← [[RTO (Recovery Time Objective)]]
-- [[Feature Flag]] ← 实现工具 ← [[RPO (Recovery Point Objective)]]
-- [[持续交付]] ← 适用场景 ← [[RTO (Recovery Time Objective)]], [[RPO (Recovery Point Objective)]]
+- [[RTO]] ← depends_on ← [[Feature Flag]]
+- [[RPO]] ← depends_on ← [[Feature Flag]]
+- [[LaunchDarkly]] → provides ← [[Feature Flag]]
+- [[Feature Flag]] ← enables ← [[渐进式发布]]
 
 ## Contradictions
 - （暂无）

wiki/sources/cloud-learning-master-index.md

@@ -0,0 +1,51 @@
+---
+title: "Cloud Learning Master Index"
+type: source
+tags: ["cloud-learning", "DevOps", "SRE", "AWS", "master-index", "index"]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md]]
+
+## Summary
+- 核心主题：OpenText 内部 Public Cloud Learning Sessions 课程的分类索引与统计信息
+- 问题域：云原生、DevOps、SRE、AWS、Azure、FinOps、安全
+- 方法/机制：按主题分类（10 个类别），提供 NAS 源文件链接和视频数量统计
+- 结论/价值：为企业内部云技术学习提供结构化课程导航
+
+## Key Claims
+- Public Cloud Learning Sessions 涵盖 10 个核心技术领域，共 121 个视频课程
+- 课程涵盖 AWS Landing Zone (22)、IAM & Identity (3)、Terraform & IaC (6)、EKS & Kubernetes (14)、FinOps & Cost (10)、CI/CD & GitOps (8)、Security (9)、Networking (9)、Serverless & AI (9)、OpenText Series (21)
+- 学习资源存储于 NAS `/volume2/work/Public Cloud Learning Sessions/`
+
+## Key Quotes
+> "NAS源: /volume2/work/Public Cloud Learning Sessions/ | Total: 0 videos processed"
+
+## Key Concepts
+- [[AWS Landing Zone]]：AWS 云基础设施着陆区架构
+- [[IAM]]：身份与访问管理
+- [[Terraform]]：基础设施即代码工具
+- [[EKS]]：Amazon Elastic Kubernetes Service
+- [[FinOps]]：云财务运营
+- [[GitOps]]：基于 Git 的运维实践
+- [[DevSecOps]]：安全集成的开发运维
+- [[Landing Zone]]：云着陆区
+
+## Key Entities
+- [[OpenText]]：主办 Public Cloud Learning Sessions 的企业
+
+## Connections
+- [[Cloud Learning Master Index]] ← contains ← [[AWS Landing Zone]]
+- [[Cloud Learning Master Index]] ← contains ← [[IAM & Identity]]
+- [[Cloud Learning Master Index]] ← contains ← [[Terraform & IaC]]
+- [[Cloud Learning Master Index]] ← contains ← [[EKS & Kubernetes]]
+- [[Cloud Learning Master Index]] ← contains ← [[FinOps & Cost]]
+- [[Cloud Learning Master Index]] ← contains ← [[CI/CD & GitOps]]
+- [[Cloud Learning Master Index]] ← contains ← [[Security]]
+- [[Cloud Learning Master Index]] ← contains ← [[Networking]]
+- [[Cloud Learning Master Index]] ← contains ← [[Serverless & AI]]
+- [[Cloud Learning Master Index]] ← contains ← [[OpenText Series]]
+
+## Contradictions
+- 无冲突记录

wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md

@@ -0,0 +1,50 @@
+---
+title: "CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs"
+type: source
+tags: [AWS, FinOps, Cost-Optimization, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md]]
+
+## Summary
+- 核心主题：云成本优化最佳实践与 Micro Focus 政策
+- 问题域：企业云成本管理、成本可见性、资源优化
+- 方法/机制：PCG 服务分层、标签合规、Reserved Instances、集中管理、实例标准化
+- 结论/价值：通过可见性、标准化和自动化实现云成本优化
+
+## Key Claims
+- PCG 团队通过三层服务（成本管理、成本优化、治理与自动化）实现云成本控制
+- 标签合规是成本可视化的基础，强制要求所有资源使用标准标签
+- 集中管理 Reserved Instances 和 Savings Plans 可实现组织级成本优化
+- Cloud Health 是核心工具，提供资源清单、成本分析和月度账单洞察
+- 标准化实例类型（M/T/C/R/X 系列）和 Graviton 实例可显著降低计算成本
+
+## Key Quotes
+> "确保账单可见是成本管理的第一步" — Uday (PCG)
+> "账户负责人负责控制在预算内" — Vinay (PCG)
+
+## Key Concepts
+- [[PCG-Public-Cloud-Governance]]：公共云治理框架，提供工作负载放置、成本和优化指导
+- [[Cost-Optimization]]：成本优化，通过技术手段降低云资源支出
+- [[Showback-Chargeback]]：成本分摊机制，用于内部成本核算
+- [[Cloud-Health]]：云成本分析和监控工具
+- [[Reserved-Instances]]：预留实例，承诺使用量换取价格折扣
+- [[Savings-Plans]]： savings plans，与 Reserved Instances 类似的价格优化方案
+- [[Graviton]]：AWS ARM 处理器实例，比 Intel 更具成本效益
+- [[Tagging-Methodology]]：标签方法论，通过标准化元数据实现资源管理
+
+## Key Entities
+- [[PCG-Team]]：Public Cloud Governance 团队，主讲云 FinOps 政策
+- [[AWS]]：云服务提供商
+
+## Connections
+- [[PCG-Team]] ← provides ← [[Cost-Optimization]]
+- [[Cloud-Health]] ← monitors ← [[AWS]]
+- [[Reserved-Instances]] ← reduces_cost ← [[AWS]]
+- [[Graviton]] ← alternative_to ← [[Intel-Instances]]
+- [[Tagging-Methodology]] ← enables ← [[Cost-Visibility]]
+
+## Contradictions
+- 无明显冲突记录

wiki/sources/ctp-topic-15-working-with-renovatebot.md

@@ -0,0 +1,46 @@
+---
+title: "CTP Topic 15 Working with Renovatebot"
+type: source
+tags: [Renovatebot, Dependency-Update, GitOps, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-15-working-with-renovatebot.md]]
+
+## Summary
+- 核心主题：利用 Renovate Bot 自动化管理云原生基础设施中的依赖项更新
+- 问题域：云原生依赖管理、CI/CD 自动化、手动更新版本号耗时耗力
+- 方法/机制：通过 Renovate Bot 扫描代码库，识别过时版本标签，自动发起 Pull Request
+- 结论/价值：提升基础设施安全性，确保开发与生产环境配置一致性
+
+## Key Claims
+- Renovate Bot 能实时扫描代码库，识别过时的版本标签并自动发起 PR
+- Dependency Dashboard 在一个 GitHub Issue 中列出所有待更新的项，提供全局视角
+- 团队通过配置 renovate.json 文件定义管理策略，支持 Terraform、Terragrunt、Docker 等多种技术栈
+- 方案已集成到 Jenkins 流水线，通过本地 Podman 容器化运行和速率限制配置实现自动化
+
+## Key Quotes
+> "在复杂的云架构中，依赖项无处不在，包括 Docker 基础镜像、Maven 依赖、Terraform 模块、Kubernetes Helm Charts 等。" — Paul Hopkins
+
+> "团队在维护大量基于 Gruntwork 的 Terraform 模块和 Terragrunt 配置时，面临着手动更新版本号耗时耗力且极易滞后的挑战。" — Paul Hopkins
+
+## Key Concepts
+- [[Renovate Bot]]：开源依赖自动化更新工具
+- [[Dependency Management]]：依赖管理
+- [[Semantic Versioning]]：语义化版本控制
+- [[Dependency Dashboard]]：依赖仪表板
+- [[Rate Limiting]]：速率限制
+- [[Pre-commit Hooks]]：提交前钩子
+
+## Key Entities
+- [[Paul Hopkins]]：本次会议主讲人
+- [[Gruntwork]]：Terraform 模块供应商
+- [[Renovate]]：开源依赖更新工具
+
+## Connections
+- [[Terraform and Terragrunt Best Practices]] ← extends ← [[CTP Topic 15 Working with Renovatebot]]
+- [[Pre-commit Hooks and Linting Sessions]] ← related_to ← [[CTP Topic 15 Working with Renovatebot]]
+
+## Contradictions
+- （文档中未发现明显冲突）

wiki/sources/ctp-topic-2-git.md

@@ -0,0 +1,34 @@
+---
+title: "CTP Topic 2 Git"
+type: source
+tags: [Git, VCS, CTP, CI/CD, GitOps]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md]]
+
+## Summary
+- 核心主题：Git 版本控制系统
+- 问题域：DevOps 与 CI/CD 基础
+- 方法/机制：版本控制、代码协作、分支管理
+- 结论/价值：掌握 Git 是 DevOps 实践的基础技能
+
+## Key Claims
+- Git 是现代软件开发中最流行的分布式版本控制系统
+
+## Key Concepts
+- [[Git]]：分布式版本控制系统，用于跟踪代码变更
+- [[版本控制]]：记录文件内容变化，以便将来查阅特定版本
+- [[Infrastructure as Code (IaC)]]：通过代码实现基础设施管理
+
+## Key Entities
+- [[CTP]]：Cloud Transformation Program，云转型计划
+- [[Public Cloud Learning Sessions]]：OpenText 内部云学习会议系列
+- [[GitHub]]：代码托管平台
+- [[GitLab]]：DevOps 平台
+
+## Connections
+- [[CTP Topic 11 AD Integration and Login using AD accounts]] ← prerequisite ← [[CTP Topic 2 Git]]
+
+## Contradictions

wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md

@@ -0,0 +1,49 @@
+---
+title: "CTP Topic 24 Micro Focus Product Privacy Framework"
+type: source
+tags: [Privacy, Compliance, Product-Privacy, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-24-micro-focus-product-privacy-framework.md]]
+
+## Summary
+- 核心主题：Micro Focus 产品隐私框架（Product Privacy Framework），解决法律合规要求与技术实现之间的鸿沟
+- 问题域：GDPR 和 CCPA 等隐私法规的技术落地
+- 方法/机制：通过结构化 Excel 工具将法律条款翻译为约 110 项具体技术要求，成熟度模型（0-4 级）评估
+- 结论/价值：产出标准化《产品隐私设置文档》，确保客户在不同产品中获得一致的隐私信息
+
+## Key Claims
+- 法律条文晦涩难懂，研发人员难以将合规要求直接转化为技术需求
+- 隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一
+- 框架将合规要求分为五种类型：架构类、文档类、法律类、实现类、SAS 运营类
+- 成熟度模型通过"蜘蛛图"直观展示产品在安全去标识化、被遗忘权、数据可移植性等关键指标上的合规现状
+
+## Key Quotes
+> "随着 GDPR 和 CCPA 的生效，产品团队面临严峻的合规压力" — Shlomi Ben-Hur
+> "通过成熟度模型和蜘蛛图，直观展示产品隐私合规现状与目标" — 框架设计核心
+
+## Key Concepts
+- [[STLC]]：Security Development Life Cycle，安全开发生命周期，包含 13 个安全和隐私轨道
+- [[PII]]：Personally Identifiable Information，个人身份识别信息
+- [[GDPR]]：欧盟通用数据保护条例
+- [[CCPA]]：加州消费者隐私法案
+- [[Spider Chart]]：蜘蛛图，可视化工具展示产品隐私维度成熟度
+- [[Data Controller]]：数据控制者
+- [[Data Processor]]：数据处理者
+- [[Anonymization]]：匿名化
+- [[Pseudonymization]]：去标识化
+
+## Key Entities
+- [[Micro Focus]]：产品隐私框架的制定者
+- [[Shlomi Ben-Hur]]：Micro Focus 产品安全小组（PSAC）主讲人
+
+## Connections
+- [[STLC]] ← contains ← [[Product Privacy Framework]]
+- [[CTP]] ← requires ← [[Product Privacy Framework]]
+- [[GDPR]] ← regulates ← [[Product Privacy Framework]]
+- [[CCPA]] ← regulates ← [[Product Privacy Framework]]
+
+## Contradictions
+- 与 [[CTP Topic 21 Supply Chain Security in Micro Focus]] 无冲突

wiki/sources/ctp-topic-27-aws-instance-scheduler.md

@@ -0,0 +1,53 @@
+---
+title: "CTP Topic 27 AWS Instance Scheduler"
+type: source
+tags:
+  - AWS
+  - Instance-Scheduler
+  - Cost-Optimization
+  - FinOps
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md]]
+
+## Summary
+- 核心主题：AWS Instance Scheduler 自动调度工具，用于定时启停 EC2 和 RDS 实例以降低非生产环境成本
+- 问题域：云成本优化、FinOps 实践
+- 方法/机制：基于 CloudFormation 部署，通过 CloudWatch Events 定时触发 Lambda，读取 DynamoDB 配置表中的调度规则，根据实例标签决定启停操作
+- 结论/价值：该工具已通过 Guardrails 自动化覆盖公司内绝大多数月消费超过 10 美元的 AWS 账号
+
+## Key Claims
+- AWS Instance Scheduler 通过定时启停 EC2 和 RDS 实例实现非生产环境成本节省
+- 该工具基于时间表触发，非空闲率触发
+- 实例关机行为必须设置为"停止"而非"终止"以保留数据
+- Instance Scheduler 能智能处理 RDS 七天一次的强制维护窗口
+
+## Key Quotes
+> "该工具基于时间表触发，不是基于空闲率" — Gustavo 在 Q&A 环节澄清
+
+## Key Concepts
+- [[Instance Scheduling]]：通过预设时间规则自动控制实例启停的技术
+- [[Cost Optimization]]：通过多种手段降低云资源支出的实践
+- [[CloudWatch Events]]：AWS 定时触发服务，触发 Lambda 函数执行调度逻辑
+- [[DynamoDB Config Table]]：存储调度配置（Schedule 和 Period 定义）的数据库表
+- [[Tagging]]：通过标签将实例关联到预定义调度逻辑的机制
+- [[RDS Maintenance Window]]：RDS 数据库维护窗口，Instance Scheduler 能识别并配合该窗口
+- [[Override Status]]：强制将实例保持在停止状态的高级配置
+
+## Key Entities
+- [[AWS Instance Scheduler]]：AWS 官方提供的实例调度工具
+- [[Guardrails]]：CCOE 实施的自动化合规与治理框架
+- [[CCOE]]：云卓越中心，负责云资源治理和成本控制
+- [[Gustavo]]：本次会议讲师
+
+## Connections
+- [[AWS Instance Scheduler]] ← deployed_by ← [[Guardrails]]
+- [[CloudWatch Events]] ← triggers ← [[AWS Lambda]]
+- [[AWS Lambda]] ← reads ← [[DynamoDB Config Table]]
+- [[Instance Scheduling]] ← applies_to ← [[EC2]]
+- [[Instance Scheduling]] ← applies_to ← [[RDS]]
+- [[Guardrails]] ← implements ← [[CCOE]]
+
+## Contradictions

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

@@ -0,0 +1,49 @@
+---
+title: "CTP Topic 3 Deploy and maintain infrastructure"
+type: source
+tags:
+  - CTP
+  - IaC
+  - Terraform
+  - Terragrunt
+  - Service-Catalog
+  - Landing-Zone
+  - DevOps
+sources:
+  - raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md
+last_updated: 2026-04-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md]]
+
+## Summary
+- 核心主题：CTP 云转型计划中的基础设施部署与维护，聚焦 Terraform、Terragrunt、模块和服务目录在 Landing Zone 架构下的使用
+- 问题域：云基础设施自动化部署、多账户管理、模块化复用
+- 方法/机制：Service Catalog 抽象业务需求→Module 实现技术细节→Terragrunt 编排版本化部署
+- 结论/价值：通过分层服务目录实现跨产品团队的基础设施复用和独立发布周期
+
+## Key Claims
+- Landing Zone provisioning 后，产品团队被分组，每个团队拥有 landing zone 和 workload 账户
+- Service 是业务需求的封装，Module 是技术需求的实现，Service 部署一组 Module，抽象层级越高配置选项越少
+- Terragrunt HCL 文件引用服务时 targeting 特定版本而非 master branch，避免意外变更
+- 推荐使用专用 service catalog 包含 modules 目录，实现独立发布周期和更好的可维护性
+
+## Key Concepts
+- [[Terraform]]：基础设施即代码工具
+- [[Terragrunt]]：Terraform 的 wrapper 工具，提供变量继承、远程状态管理
+- [[Service-Catalog]]：服务目录，封装业务需求的模块分组
+- [[Landing-Zone]]：云着陆区，标准化的多账户基础架构框架
+- [[Module]]：Terraform 模块，可复用的基础设施配置单元
+
+## Key Entities
+- [[Gruntwork]]：参考模型，提供生产级 Terraform 模块
+- [[Product-Team]]：产品团队，拥有独立的 landing zone 和 workload 账户
+
+## Connections
+- [[Product-Team]] ← uses ← [[Landing-Zone]]
+- [[Terragrunt]] ← references ← [[Service-Catalog]]
+- [[Service-Catalog]] ← contains ← [[Module]]
+- [[Terraform]] ← implements ← [[Module]]
+
+## Contradictions

wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md

@@ -0,0 +1,43 @@
+---
+title: "CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments"
+type: source
+tags: []
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md]]
+
+## Summary
+- 核心主题：使用 Atlantis 替代 Jenkins 进行基础设施自动化部署
+- 问题域：当前 Jenkins 流水线存在初始化时间长、多代码克隆、顺序测试、ECS 部署器配置慢等问题，且复杂度高、脆弱性强
+- 方法/机制：Atlantis 是开源、自托管的 Terraform 自动化工具，通过 GitHub Pull Request 评论触发 plan/apply，支持并行构建、目录锁定、依赖触发
+- 结论/价值：Atlantis 提供更好的协作模型、简化网络架构（减少 VPC 终端节点需求）、合并前应用确保代码与基础设施同步
+
+## Key Claims
+- Atlantis 部署在每个 Landing Zone 共享账户的单个 EC2 实例上
+- Atlantis 通过 GitHub Enterprise Webhook 通知，使用服务账号与 GitHub 交互、发布评论、执行合并和关闭 PR
+- Atlantis 锁定机制在 plan 运行期间锁定模块目录，直至 PR 合并、关闭或 plan 被丢弃
+- Atlantis 支持并行构建，多个模块的 plan 和 apply 命令同时运行
+
+## Key Quotes
+> "The current pipeline is practically very slow due to significant initialization time, multiple code cloning, sequential testing, and ECS deployer provisioning." — 当前流水线问题
+
+> "When a plan is run, the directory of each module is locked until the pull request that has this folder locked is merged or closed, or the plan is manually discarded." — Atlantis 锁定机制
+
+## Key Concepts
+- [[Atlantis]]：开源、自托管的 Terraform CI/CD 自动化工具，通过 GitHub PR 评论触发工作流
+- [[Infrastructure-as-Code-IaC]]：通过代码管理基础设施，Atlantis 自动化 Terraform 执行
+- [[CI-CD-流水线]]：持续集成/持续部署管道，Atlantis 替代 Jenkins 作为新方案
+
+## Key Entities
+- [[Jenkins]]：现有 CI/CD 工具，被 Atlantis 替代的目标
+- [[Terraform]]：基础设施即代码工具，Atlantis 的主要自动化对象
+- [[GitHub Enterprise]]：代码托管平台，Atlantis 通过 Webhook 集成
+
+## Connections
+- [[Jenkins]] ← replaced_by ← [[Atlantis]]
+- [[Terraform]] ← managed_by ← [[Atlantis]]
+- [[GitHub Enterprise]] ← notifies ← [[Atlantis]]
+
+## Contradictions

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

@@ -0,0 +1,67 @@
+---
+id: ctp-topic-33-an-introduction-to-gitops
+title: "CTP Topic 33 An introduction to GitOps"
+type: source
+tags: [GitOps, CI/CD, DevOps, CTP]
+sources: [raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-33-an-introduction-to-gitops.md]
+last_updated: 2026-04-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-33-an-introduction-to-gitops.md]]
+
+## Summary
+- 核心主题：GitOps（一种将软件开发原则应用于部署流程的方法论）
+- 问题域：解决传统部署中的失败部署、配置不一致、审计困难等问题
+- 方法/机制：基于 Git 的声明式配置、CD 流水线、基础设施即代码，通过 GitOps Controller 协调期望状态与实际状态
+- 结论/价值：提升开发生产力、最小化失败部署、实现快速发布、实时审计和改进安全性
+
+## Key Claims
+- GitOps 通过使用开发者熟悉的工具提升开发生产力
+- GitOps 可最大限度减少失败部署，通过轻松的回滚能力
+- GitOps 支持更快的功能发布
+- GitOps 通过 Git 特性实现实时审计和改进安全性
+- Git 是开发者唯一需要知道的工具
+- CI 和 CD 应该解耦以增强安全性
+- GitOps 的拉取模型（Pull Model）监控 Git 和目标系统，推荐用于 GitOps
+
+## Key Quotes
+> "GitOps applies software development principles to deployment processes, potentially resolving challenges like failed deployments and configuration inconsistencies."
+> "The only tool a developer needs to know is Git."
+> "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."
+
+## Key Concepts
+- [[GitOps]]：将软件开发原则应用于部署流程的方法论
+- [[Declarative Configuration]]（声明式配置）：以声明形式定义系统期望状态而非具体步骤
+- [[Infrastructure as Code]]（基础设施即代码）：通过代码管理基础设施的实践
+- [[CD Pipeline]]（持续交付流水线）：自动化部署流程
+- [[GitOps Controller]]：协调 Git 状态与实际系统状态的代理
+- [[Pull Model]]（拉取模型）：GitOps 推荐的 CD 实现模式，监控 Git 和目标系统
+- [[Push Model]]（推送模型）：传统的 CI/CD 部署模式
+- [[Idempotent Operation]]（幂等操作）：可多次应用而不改变结果的操怍
+
+## Key Entities
+- [[Victor Etkin]]：本次分享的演讲者，介绍 GitOps 概念
+
+## Connections
+- [[DevOps]] ← extends ← [[GitOps]]
+- [[CI/CD]] ← uses ← [[GitOps]]
+- [[Kubernetes]] ← often_used_with ← [[GitOps]]
+- [[Infrastructure as Code]] ← implements ← [[GitOps]]
+
+## Contradictions
+- 无
+
+## Four Principles of GitOps
+1. **Declarative Configuration**（声明式配置）：系统以声明形式定义
+2. **Version Control**（版本控制）：所有配置存储在 Git 中
+3. **CD Process Separation**（CD 流程分离）：CI 和 CD 解耦
+4. **Incremental Infrastructure**（增量基础设施）：渐进式实施基础设施
+
+## GitOps Workflow (Kubernetes)
+1. 开发者提交代码
+2. 创建容器镜像
+3. 将部署配置存储在 Git 中
+4. GitOps Agent 监控变化
+5. 向环境推出镜像

wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md

@@ -0,0 +1,50 @@
+---
+title: "CTP Topic 48 Terraform vs Terragrunt"
+type: source
+tags: [Terraform, Terragrunt, IaC, CTP]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md]]
+
+## Summary
+- 核心主题：Terraform 与 Terragrunt 的对比与选型
+- 问题域：基础设施即代码（IaC）工具选择，企业级多环境部署管理
+- 方法/机制：Terraform 提供声明式配置和状态管理，Terragrunt 作为包装器实现 DRY 原则和变量复用
+- 结论/价值：Terraform 适合单一环境，Terragrunt 适合多环境企业级部署
+
+## Key Claims
+- Terraform 是云无关的基础设施即代码工具，通过状态文件将期望状态与实际环境关联
+- Terragrunt 是 Terraform 的轻量级包装器，遵循 DRY 原则实现配置复用
+- Terragrunt 可以重复使用信息而无需硬编码值，管理 provider 和 remote state 块
+- Terraform Enterprise 是包含工作区的 CI 平台
+- Gruntwork 提供预构建可定制模块和 Terraform 原生 AWS Landing Zone
+
+## Key Quotes
+> "Terraform 是 Golang 应用程序，用于跨各种环境配置、变更和版本控制资源"
+> "Terragrunt 提供一种可重复使用信息而不硬编码值的方式"
+
+## Key Concepts
+- [[Terraform]]：基础设施即代码工具，通过声明式配置定义云资源
+- [[Terragrunt]]：Terraform 的包装工具，提供模块化和变量共享
+- [[Infrastructure as Code (IaC)]]：通过代码实现基础设施管理的一致性和版本控制
+- [[State File]]：Terraform 用于将期望状态关联到实际环境的文件
+
+## Key Entities
+- [[HashiCorp]]：Terraform 的开发商
+- [[Gruntwork]]：提供预构建 Terraform 模块和 Landing Zone
+- [[Atlantis]]：集成 Terraform 与 GitHub 的开源 CI/CD 工具
+
+## Connections
+- [[Terraform]] ← wraps ← [[Terragrunt]]
+- [[Terragrunt]] ← uses ← [[Infrastructure as Code (IaC)]]
+- [[Gruntwork Landing Zone]] ← built_with ← [[Terraform]]
+
+## Contradictions
+- 无
+
+---
+
+## 相关资源
+- NAS: /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 48_ Terraform vs Terragrunt.mp4

wiki/sources/ctp-topic-56-automated-infrastructure-testing.md

@@ -0,0 +1,45 @@
+---
+title: "CTP Topic 56 Automated infrastructure testing"
+type: source
+tags:
+  - Testing
+  - IaC
+  - Automation
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-56-automated-infrastructure-testing.md]]
+
+## Summary
+- 核心主题：自动化基础设施测试，介绍 TerraTest 框架和测试驱动开发（TDD）在基础设施即代码中的应用
+- 问题域：CI/CD、基础设施即代码（IaC）、DevOps
+- 方法/机制：使用 TerraTest 自动化 Terraform apply-test-destroy 周期；采用测试驱动开发工作流
+- 结论/价值：自动化测试可提升基础设施部署质量，减少生产故障，提高团队信心
+
+## Key Claims
+- TerraTest（Golang 库）可自动执行 apply-test-destroy 流程，简化基础设施测试
+- 集成测试验证已部署基础设施的实际功能，超出语法检查范围
+- 测试驱动开发（TDD）通过先写测试再实现功能，确保聚焦开发目标
+- 自动化测试长期收益（减少 bug、提高信心）远超初期投入
+
+## Key Quotes
+> "重复性工作交给计算机，复杂的人类思考留给人脑。" — Mark Francis
+
+> "把测试视为头等公民，延伸基础设施即代码的价值。" — Mark Francis
+
+## Key Concepts
+- [[TerraTest]]：Golang 编写的自动化基础设施测试库
+- [[Test-Driven Development]]：测试驱动开发方法论
+- [[Infrastructure as Code]]：通过代码管理基础设施
+- [[Integration Testing]]：集成测试验证已部署基础设施
+- [[Automated Testing]]：自动化测试提升部署质量
+
+## Key Entities
+- [[Mark Francis]]：CTP Topic 56 演讲者
+
+## Connections
+- [[CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments]] ← relates_to ← [[TerraTest]]
+- [[CTP Topic 9 CI CD with Gruntwork]] ← relates_to ← [[Automated Testing]]
+- [[CTP Topic 11 AD Integration and Login using AD accounts]] ← precedes ← [[Test-Driven Development]]

wiki/sources/ctp-topic-63-optimise-resource-cost-using-automation.md

@@ -0,0 +1,61 @@
+---
+id: ctp-topic-63-optimise-resource-cost-using-automation
+title: "CTP Topic 63 Optimise resource cost using automation"
+type: source
+tags:
+  - AWS
+  - Cost-Optimization
+  - Automation
+  - FinOps
+  - CTP
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-63-optimise-resource-cost-using-automation.md]]
+
+## Summary
+- 核心主题：通过自动化技术降低云资源成本
+- 问题域：云成本优化、基础设施自动化
+- 方法/机制：批准区域标准化、实例类型优化、承诺计划、存储优化、自动化调度
+- 结论/价值：综合运用多种策略可显著降低云支出，自动化调度可节省高达 70% 成本
+
+## Key Claims
+- 使用批准区域可提高安全性、标准化管理和成本优化
+- Graviton ARM 实例比同规格 Intel 便宜 20-25%
+- 1年承诺计划可获约 40% 折扣，3年可达 60-64%
+- GP2 迁移到 GP3 可直接节省 20% 存储成本
+- 自动化调度（非工作时间停止实例）可节省高达 70% 成本
+
+## Key Quotes
+> "如果每天只运行 10 小时，可节省 70% 成本" — 自动化调度演示
+
+## Key Concepts
+- [[Approved Region]]：推荐的云资源部署区域，有助于提高安全性、标准化管理和优化成本
+- [[Instance Type Selection]]：根据工作负载选择合适的实例家族以优化性能和成本
+- [[Commitment Plans]]：通过预先承诺使用云资源获得折扣价格
+- [[Storage Optimization]]：通过选择合适的存储类型和及时清理降低存储成本
+- [[Automation Scheduler]]：通过定时任务自动启动和停止云资源
+- [[Graviton]]：AWS ARM 处理器，性价比更高
+
+## Key Entities
+- [[AWS]]：云服务提供商
+- [[Micro Focus]]：组织名称（CTP 云转型计划所属）
+- [[Pushka]]：演示者
+
+## Connections
+- [[FinOps]] ← related_to ← [[CTP Topic 63]]
+- [[Right Sizing]] ← related_to ← [[CTP Topic 63]]
+- [[Rate Optimization]] ← related_to ← [[CTP Topic 63]]
+- [[Storage Cost Optimization]] ← related_to ← [[CTP Topic 63]]
+
+## Contradictions
+- 无明显冲突
+
+## Action Items
+- [ ] 评估现有云资源的使用情况，确定可以迁移到批准区域的资源
+- [ ] 分析不同工作负载的资源需求，选择合适的实例类型
+- [ ] 评估现有云资源的使用率，考虑购买承诺计划
+- [ ] 在研发环境中实施自动化调度
+- [ ] 定期清理未使用的存储卷和快照
+- [ ] 探索 Graviton 实例用于兼容的工作负载

wiki/sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md

@@ -0,0 +1,58 @@
+---
+title: "CTP Topic 71 PCG's Guide to RightSizing, Why, How, When"
+type: source
+tags:
+  - AWS
+  - RightSizing
+  - Cost-Optimization
+  - CTP
+  - FinOps
+date: 2026-04-14
+---
+
+## Source File
+
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md]]
+
+## Summary
+
+- **核心主题**：AWS 资源优化（Right Sizing）的全面指南
+- **问题域**：云成本优化、资源效率提升
+- **方法/机制**：通过识别正确规格的云资源匹配实际工作负载需求，实现成本节省
+- **结论/价值**：Right Sizing 是 FinOps 成本优化的核心手段之一，可通过多种方式实施
+
+## Key Claims
+
+- Right Sizing 是识别正确资源规格以匹配工作负载需求的过程
+- EC2 Right Sizing 推荐报告是实施 Right Sizing 的主要工具
+- 实例调度和闲置资源清理是 Right Sizing 的补充手段
+- Right Sizing 与费率优化（Savings Plans、Reserved Instances）结合使用效果更佳
+
+## Key Quotes
+
+> "Right Sizing is the process of identifying the right size of resources to match your workload requirements."
+
+## Key Concepts
+
+- [[Right-Sizing]]：识别正确资源规格匹配工作负载需求的过程
+- [[FinOps]]：云财务运营实践，整合财务管理与云资源优化
+- [[Cost-Optimization]]：成本优化，通过多种手段降低云支出
+- [[Rate-Optimization]]：费率优化，通过 Savings Plans 和 Reserved Instances 获取折扣
+- [[EC2-Right-Sizing]]：AWS EC2 实例 Right Sizing 推荐功能
+
+## Key Entities
+
+- [[AWS]]：云服务提供商，提供 Right Sizing 推荐功能
+- [[PCG]]：Public Cloud Guide，负责本次分享的团队
+
+## Connections
+
+- [[FinOps]] ← core_practice ← [[Right-Sizing]]
+- [[Cost-Optimization]] ← includes ← [[Right-Sizing]]
+- [[Rate-Optimization]] ← complements ← [[Right-Sizing]]
+- [[Right-Sizing]] ← uses ← [[EC2-Right-Sizing]]
+
+## Contradictions
+
+- 与过度配置策略冲突：有些人倾向于过度配置资源以确保性能，Right Sizing 主张精确匹配
+- 与预留实例策略冲突：Reserved Instances 适合稳定工作负载，Right Sizing 适合变化的工作负载

wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md

@@ -0,0 +1,37 @@
+---
+title: "CTP Topic 9 CI CD with Gruntwork"
+type: source
+tags: [CI/CD, Gruntwork, IaC, CTP, DevOps]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md]]
+
+## Summary
+- 核心主题：CI/CD 与 Gruntwork 集成
+- 问题域：持续集成、持续部署、基础设施即代码
+- 方法/机制：待转录后补充
+- 结论/价值：待转录后补充
+
+## Key Claims
+- 待视频转录后生成
+
+## Key Quotes
+> 待转录后补充
+
+## Key Concepts
+- [[CI/CD 流水线]]：自动化测试、集成和部署的持续交付管道
+- [[Gruntwork Landing Zone]]：Gruntwork 提供的预配置 AWS 基础架构框架
+- [[Infrastructure as Code]]：通过代码实现一致性、版本控制的基础设施管理
+
+## Key Entities
+- [[Gruntwork]]：提供 IaC 库和工具的公司
+- [[OpenText]]：视频来源公司
+
+## Connections
+- [[CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments]] ← relates_to ← [[CTP Topic 9 CI CD with Gruntwork]]
+- [[CTP Topic 33 An Introduction to GitOps]] ← extends ← [[CI/CD 流水线]]
+
+## Contradictions
+- 无

wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md

@@ -39,4 +39,21 @@ date: 2025-10-25
 - [[CloudWatch]] ← receives ← [[EventBridge]]
 - [[AWS Organizations]] ← manages ← [[StackSets]]
 
-## Contradictions
+## Contradictions
+
+## Cost Implications
+
+实施集中式监控解决方案时需考虑以下成本组件：
+
+- **Amazon EventBridge 定价**：跨账号发布事件到中央事件总线的相关费用
+- **Amazon CloudWatch 定价**：存储来自所有账号的 CloudFormation 事件的集中日志组的存储费用，以及查询集中日志的费用
+- **AWS Key Management Service 定价**：用于日志加密的客户管理密钥的相关费用
+
+## Clean up
+
+清理本方案创建的资源的步骤：
+
+1. 首先从 AWS CloudFormation 控制台在管理账号中删除通用资源堆栈集（common-resources-stackset）。这将删除部署到所有成员账号的资源。
+2. 堆栈集操作完成后，删除管理账号日志设置堆栈（log-setup-management），以移除集中式日志基础设施，包括事件总线、日志组和关联的 IAM 角色。
+
+**注意**：在删除管理账号日志设置之前，确保所有堆栈集操作已完成，以确保正确清理所有资源。

wiki/sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md

@@ -0,0 +1,54 @@
+---
+title: "Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS"
+type: source
+tags:
+  - AWS
+  - EC2
+  - Cost-Optimization
+  - FinOps
+date: 2024-05-29
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md]]
+
+## Summary
+- 核心主题：AWS EC2 成本优化最佳实践
+- 问题域：云成本控制、计算资源优化
+- 方法/机制：Graviton 迁移、Spot 实例利用、购买选项选择
+- 结论/价值：通过架构优化和正确的实例类型选择，可显著降低 EC2 成本
+
+## Key Claims
+- Graviton 实例比同类 x86 实例提供最高 40% 的性价比优势
+- Graviton 处理器比同类 x86 实例减少最多 60% 的功耗
+- EC2 Spot 实例相比按需定价最高可节省 90% 成本
+- 云效率架构使客户只需为实际使用的资源付费
+
+## Key Quotes
+> "When we start talking about architecting and using best practice efficiency in the cloud, you effectively only pay for what you use when you use AWS." — AWS 专家
+
+> "Graviton Free actually uses up to 60% less power consumption than comparable X86-based instances." — AWS 专家
+
+## Key Concepts
+- [[Graviton]]：AWS 基于 ARM64 架构的处理器，提供更高性价比和更低功耗
+- [[EC2-Spot-Instances]]：利用闲置容量，最高可享 90% 折扣的实例类型
+- [[Savings-Plans]]：AWS 预留容量定价模型
+- [[EC2-Instance-Types]]：AWS 提供超过 750 种实例类型满足各种工作负载需求
+- [[AWS-Nitro]]：AWS 自研系统，将网络、存储和安全功能外置以提升效率
+- [[Cost-Optimization]]：云成本优化策略
+
+## Key Entities
+- [[AWS]]：云计算服务提供商
+- [[Mike-Dukes]]：AWS 专家，演讲者
+- [[Steele-Taylor]]：AWS 专家，演讲者
+- [[Public-Cloud-Learning-Sessions]]：AWS 内部学习会议系列
+
+## Connections
+- [[AWS]] ← hosts ← [[Public-Cloud-Learning-Sessions]]
+- [[Graviton]] ← is_type_of ← [[EC2-Instance-Types]]
+- [[EC2-Spot-Instances]] ← offers_discount ← [[AWS]]
+- [[Cost-Optimization]] ← applies_to ← [[EC2]]
+- [[Spot-Interruption]] ← risk_of ← [[EC2-Spot-Instances]]
+
+## Contradictions
+- 与传统预留实例相比，Spot 实例不适合有状态服务（如数据库），需根据工作负载特性选择

wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206.md

@@ -0,0 +1,61 @@
+---
+title: "Public Cloud Learning Sessions - Introduction to Artificial Intelligence (AI) Machine Learning (ML) - 20240206"
+type: source
+tags:
+  - AI
+  - ML
+  - AWS
+  - Machine-Learning
+  - Serverless
+date: 2024-02-06
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md]]
+
+## Summary
+- 核心主题：AWS AI/ML 介绍与实践，生成式 AI 应用
+- 问题域：企业如何采用 AI/ML 技术进行数字化转型
+- 方法/机制：Amazon Bedrock、SageMaker、Foundation Models、ML Ops
+- 结论/价值：AWS 提供完整的 AI/ML 工具链，降低企业采用门槛， Bedrock 是构建生成式 AI 应用的核心服务
+
+## Key Claims
+- AI 是复制需要人类智能才能完成的任务的系统，通常通过机器学习寻求概率性结果
+- Amazon 投资机器学习 20 年，用于推荐系统、机器人技术、预测和 Alexa
+- AWS 在四个领域帮助客户使用 AI：增强客户体验、支持更好决策、改善运营、创造新产品
+- Amazon Bedrock 是全托管服务，可通过基础模型构建和扩展生成式 AI 应用
+- ML Ops 结合机器学习和运营，涉及数据管道、训练管道和推理管道
+
+## Key Quotes
+> "We believe most customer experiences and applications will be reinvented with generative AI, powered by foundation models with billions of parameters."
+> — Suraav Paul, AWS Senior Solutions Architect
+
+> "AI is a way to describe any system that can replicate tasks that previously required human intelligence."
+
+## Key Concepts
+- [[AI]]：复制需要人类智能才能完成的任务的系统
+- [[Machine Learning]]：使用数据创建决策逻辑或模型的 AI 子领域
+- [[Foundation Model]]：基础模型，具有数十亿参数的大规模预训练模型
+- [[Amazon Bedrock]]：全托管服务，用于使用基础模型构建生成式 AI 应用
+- [[Amazon SageMaker]]：AWS 机器学习平台，用于构建、训练和部署模型
+- [[ML Ops]]：机器学习运维，结合 ML 和 DevOps 实践
+- [[RAG]]：检索增强生成，从公司数据源获取相关响应
+- [[Fine-Tuning]]：使用标记数据集定制基础模型
+- [[Responsible AI]]：负责任 AI，包括公平性、可解释性、健壮性、治理、透明度和隐私/安全
+
+## Key Entities
+- [[AWS]]：亚马逊云服务，提供 AI/ML 工具和服务
+- [[Suraav Paul]]：AWS 高级解决方案架构师，本次演讲者
+
+## Connections
+- [[AWS]] ← provides ← [[Amazon Bedrock]]
+- [[AWS]] ← provides ← [[Amazon SageMaker]]
+- [[Machine Learning]] ← is_subcategory_of ← [[AI]]
+- [[Foundation Model]] ← powers ← [[Generative AI]]
+- [[RAG]] ← enhances ← [[Amazon Bedrock]]
+
+## Contradictions
+- 与本地模型部署方案对比：
+  - 冲突点：数据隐私与模型控制权
+  - 当前观点：Bedrock 提供托管环境，数据仅在请求响应周期存储
+  - 对方观点：本地部署可完全控制模型和数据，但需要管理基础设施

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

@@ -0,0 +1,48 @@
+---
+title: "Public Cloud Learning Sessions - Ollie Workflow and The Demand Process"
+type: source
+tags: [Workflow, Demand-Process, Agile, DevOps]
+date: 2024-04-16
+---
+
+## Source File
+- [[raw/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 工作流流程，用于超大规模云服务商的支出审批、需求管理和请求处理
+- 问题域：IT 服务管理、需求管理、云资源审批流程
+- 方法/机制：ITIL 框架下的三阶段审批流程（可行性验证→技术验证→预算验证）
+- 结论/价值：通过标准化工作流实现云资源请求的透明化管理，确保预算控制和资源合理分配
+
+## Key Claims
+- MUI 或 Shannon 的书面审批是任何超大规模云服务商支出的强制要求
+- Oli 工作流正在过渡到 FinOps 团队，由 Tom Bice 负责管理
+- 请求缺失理由说明将导致即时拒绝
+- 机器应执行机器能做的事，实现自动化处理
+
+## Key Quotes
+> "The current mandate requires written approval from MUI or Shannon for any hyperscaler spend, regardless of the amount." — 审批要求
+> "If justification details are not provided, requests are subject to immediate rejection." — 拒绝机制
+> "Machines should do what machines can do, enabling an automated fulfillment process." — 自动化目标
+
+## Key Concepts
+- [[Demand Management]]：需求管理，平衡请求与可用容量
+- [[ITIL Framework]]：ITIL 框架将业务流程分为服务战略、设计、转换、运营和改进五个阶段
+- [[Workflow Process]]：审批流程是请求处理的第一阶段
+- [[Service Catalog]]：服务目录，云产品和服务的标准化清单
+
+## Key Entities
+- [[MUI]]：审批决策者之一
+- [[Shannon]]：审批决策者之一
+- [[Tom Bice]]：FinOps 团队负责人
+- [[FinOps Team]]：负责 Oli 工作流管理的团队
+- [[FPNA Team]]：负责预算可用性验证的团队
+
+## Connections
+- [[Demand Management]] ← depends_on ← [[ITIL Framework]]
+- [[Workflow Process]] ← part_of ← [[ITIL Framework]]
+- [[Service Catalog]] ← enables ← [[Demand Management]]
+- [[FinOps Team]] ← manages ← [[Workflow Process]]
+
+## Contradictions
+- 无

wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126.md

@@ -0,0 +1,51 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126"
+type: source
+tags:
+  - AI
+  - Use-Cases
+  - OpenText
+  - AWS
+date: 2024-11-26
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md]]
+
+## Summary
+- 核心主题：AWS AI 专家分享企业级 AI 应用案例与实践
+- 问题域：企业如何利用生成式 AI 创造价值
+- 方法/机制：AWS 三层产品策略（基础设施 + Bedrock + AI 应用）、RAG、微调、持续预训练
+- 结论/价值：数据是差异化关键，负责任 AI 实践至关重要
+
+## Key Claims
+- 生成式 AI 自 2000 年代数据量爆发以来快速增长
+- 企业软件公司是生成式 AI 的早期采用者
+- 数据是差异化的关键，生成式 AI 与现有业务数据集成控制输出结果
+- AWS 三层产品策略：基础设施层 → Amazon Bedrock → 即用型 AI 应用
+
+## Key Quotes
+> "Data is key to differentiation, as generative AI applications integrate with existing business data to control outcomes."
+
+> "When implementing your services, we do have to look at this more holistically."
+
+## Key Concepts
+- [[Generative-AI]]：利用大语言模型生成新内容的 AI 技术
+- [[RAG]]：检索增强生成，通过检索增强解决 LLM 幻觉问题
+- [[Fine-Tuning]]：使用标记数据集定制基础模型
+- [[Amazon-Bedrock]]：AWS 全托管基础模型服务
+- [[Amazon-SageMaker]]：AWS 机器学习平台
+- [[Responsible-AI]]：负责任 AI，包括公平性、可解释性、透明度和治理
+
+## Key Entities
+- [[Stephen-Frank]]：AWS AI 专家
+- [[AWS]]：亚马逊云服务
+- [[OpenText]]：企业软件公司
+
+## Connections
+- [[AWS]] ← provides ← [[Amazon-Bedrock]]
+- [[AWS]] ← provides ← [[Amazon-SageMaker]]
+- [[Generative-AI]] ← uses ← [[RAG]]
+- [[Generative-AI]] ← requires ← [[Responsible-AI]]
+
+## Contradictions

wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md

@@ -0,0 +1,46 @@
+---
+title: "Public Cloud Learning Sessions (OpenText)-Event Driven Architecture - Part 1"
+type: source
+tags: [EDA, Event-Driven, Architecture, OpenText, AWS]
+sources: []
+date: 2024-09-17
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md]]
+
+## Summary
+- 核心主题：事件驱动架构（Event-Driven Architecture，EDA）企业级集成模式学习
+- 问题域：云原生架构设计、服务异步通信、微服务解耦
+- 方法/机制：Amazon EventBridge、SQS、SNS 事件驱动服务实现异步通信
+- 结论/价值：掌握企业级事件驱动架构设计模式和 AWS 事件服务选择依据
+
+## Key Claims
+- 事件驱动架构通过异步通信实现服务间松耦合，提高系统弹性和可扩展性
+- Amazon EventBridge 是云原生事件总线，支持事件路由、过滤和目标调用
+- Amazon SQS 提供消息队列服务，实现点对点异步通信
+- Amazon SNS 提供发布/订阅模式，实现一对多消息广播
+
+## Key Concepts
+- [[Event-Driven Architecture]]：事件驱动架构，一种以事件为核心驱动系统行为的架构模式
+- [[EventBridge]]：AWS 云原生事件总线服务
+- [[Amazon SQS]]：AWS 简单队列服务
+- [[Amazon SNS]]：AWS 简单通知服务
+- [[Enterprise Integration Patterns]]：企业集成模式，EIP 是一套标准化的系统集成设计模式
+
+## Key Entities
+- [[Dr. Anil Giri]]：AWS 解决方案架构师，本次会议主讲人
+- [[OpenText]]：会议主办方
+
+## Connections
+- [[EventBridge]] ← implements ← [[Event-Driven Architecture]]
+- [[Amazon-SQS]] ← implements ← [[Message Queue]]
+- [[Amazon-SNS]] ← implements ← [[Pub/Sub]]
+
+## Action Items
+- 观看后续部分的录像以了解 EDA 的具体演示细节
+- 查阅 Amazon EventBridge, SQS, SNS 的官方文档
+
+---
+
+*最后更新: 2026-04-19*

wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md

@@ -0,0 +1,53 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture - Part 2"
+type: source
+tags:
+  - EDA
+  - Event-Driven
+  - Architecture
+  - OpenText
+  - AWS
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md]]
+
+## Summary
+- 核心主题：事件驱动架构（EDA）最佳实践与团队独立性与通用消息模式
+- 问题域：事件驱动架构设计、团队协作模式、消息传递模式
+- 方法/机制：事件生产者/消费者/代理三角模型、Sparse vs Full State Events、幂等性、事件排序保障、团队独立性
+- 结论/价值：去耦应用、实现独立扩展和监控、最小化故障影响
+
+## Key Claims
+- 事件驱动架构通过将应用解耦，实现业务功能的逻辑分解，支持进程的独立扩展和监控
+- 稀疏事件（sparse events）体积小适合频繁变化的数据，而完整状态事件（full state events）包含更多细节但受 EventBridge 负载大小限制
+- 幂等性确保同一请求多次执行产生相同结果，是处理 AWS Lambda 自动重试的关键
+- SQS FIFO 或 Kinesis Data Streams 可以保证事件顺序，对于无序事件可使用 EventBridge 或标准 SQS
+- 去中心化团队所有权优于集中式所有权，SNS 主题或 EventBridge 规则可实现扇出模式分发事件
+
+## Key Quotes
+> "Event is nothing but it's like a change in the state or an update" — 事件即状态变化或更新
+> "Everything fails every time means like whatever you have designed and whatever workload you are running it may fail any time" — 任何设计的系统都可能在任何时候失败
+
+## Key Concepts
+- [[Event-Driven Architecture]]：事件驱动架构，一种以事件为核心驱动系统行为的架构模式
+- [[EventBridge]]：AWS 事件路由服务，功能比 SNS 更丰富
+- [[SQS]]：AWS 简单队列服务，用作事件存储
+- [[Step Functions]]：AWS 工作流服务，基于状态机编排业务流程
+- [[Kinesis]]：AWS 数据流服务，用于实时数据流处理
+- Idempotency（幂等性）：同一操作多次执行结果相同
+- Fan-out Pattern（扇出模式）：一个事件分发多个消费者
+- Competing Consumer Pattern（竞争消费者模式）：只有一个消费者可以消费消息
+
+## Key Entities
+- [[OpenText]]：云服务提供商，举办本次学习 sessions
+- [[AWS]]：云服务平台，提供 EventBridge、SQS、Step Functions、Kinesis 等服务
+
+## Connections
+- [[EventBridge]] ← implements ← [[Event-Driven Architecture]]
+- [[SQS]] ← implements ← [[Event-Driven Architecture]]
+- [[Kinesis]] ← implements ← [[Event-Driven Architecture]]
+- [[Step Functions]] ← orchestrates ← [[Event-Driven Architecture]]
+- [[Event-Driven Architecture]] ← enables ← Team Independence
+- [[Event-Driven Architecture]] ← enables ← Process Isolation

wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-20241112.md

@@ -0,0 +1,55 @@
+---
+title: "Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112"
+type: source
+tags:
+  - Generative-AI
+  - Prompt-Engineering
+  - AWS
+  - OpenText
+date: 2024-11-12
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md]]
+
+## Summary
+- 核心主题：AWS 生成式 AI 服务与提示词工程基础
+- 问题域：企业如何利用生成式 AI 创造业务价值
+- 方法/机制：检索增强生成（RAG）、微调（Fine-tuning）、持续重训练；提示词工程组件与技巧
+- 结论/价值：数据是企业差异化的关键，通过 RAG/微调/重训练技术，结合提示词工程，可构建特定领域的生成式 AI 应用
+
+## Key Claims
+- 生成式 AI 通过创造新体验、提升员工生产力、提取洞察和促进创造力来创造价值
+- 你的数据是通用应用与能够带来业务价值的特定应用之间的差异点
+- RAG 是最便宜和最简单的技术，连接多个数据源无需重训练模型
+- 提示词工程是创建、设计和优化提示词以引导 LLM 响应的过程
+- 提示词由指令、上下文、用户输入和输出指示器组成
+
+## Key Quotes
+> "Your data is your differentiator and it is what makes the difference between generic application to a specific application that can actually bring business to your value."
+
+> "None of your data nor the prompts, not the data that you are using for customizing the model is being shared with the model providers."
+
+## Key Concepts
+- [[生成式 AI]]：能够创造新内容（文本、图像、音频）的 AI 技术
+- [[RAG]]：检索增强生成，连接多个数据源无需重训练模型
+- [[Fine-Tuning]]：使用标记示例重新训练模型
+- [[Prompt Engineering]]：创建、设计和优化提示词的过程
+- [[Amazon Bedrock]]：全托管服务，提供对多种基础模型的访问
+- [[Amazon SageMaker]]：用于构建、训练和部署模型的托管服务
+- [[Amazon Q]]：AI 助手，面向业务和开发者
+- [[Foundation Model]]：基础模型，具有数十亿参数的大规模预训练模型
+
+## Key Entities
+- [[Shikad Holtzman]]：AWS 技术客户经理（以色列），本次分享讲师
+- [[OpenText]]：主办 Public Cloud Learning Sessions 的企业内容管理公司
+- [[Amazon]]：云服务提供商，提供 AWS 生成式 AI 堆栈
+
+## Connections
+- [[Public Cloud Learning Sessions]] ← hosts ← [[生成式 AI]]
+- [[Amazon Bedrock]] ← provides_access_to ← [[Foundation Model]]
+- [[RAG]] ← cheaper_than ← [[Fine-Tuning]]
+- [[Amazon Q for Business]] ← connects_to ← multiple_data_sources
+- [[Amazon Q Developer]] ← focuses_on ← code_generation
+
+## Contradictions

wiki/sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md

@@ -0,0 +1,59 @@
+---
+title: "Public Cloud Learning Sessions- Reducing Cloud Costs - 20250318"
+type: source
+tags:
+  - AWS
+  - Cost-Optimization
+  - FinOps
+date: 2025-03-18
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md]]
+
+## Summary
+- 核心主题：云成本优化（FinOps）
+- 问题域：公有云成本控制与优化
+- 方法/机制：工作负载优化（现代化+Right Sizing）、费率优化（承诺使用折扣）
+- 结论/价值：通过现代化升级、Right Sizing 和承诺折扣可显著降低云支出
+
+## Key Claims
+- 新一代实例通常比旧代更便宜，性能更优（M6 之后定价模型有变化）
+- 从 Intel 迁移到 AMD 可节省 6-10% 按需价格
+- Graviton 实例可为 Linux 工作负载节省 20-25% 成本
+- GP2 升级到 GP3 可直接节省 20% 成本，无需停机
+- EKS 集群升级到最新版本可避免高额的扩展支持费用
+- Spot 实例可提供高达 90% 的折扣
+- Right Sizing 可通过配置实例调度节省 40% 成本
+- 承诺计划最低交易价值为每年 5,000 美元
+
+## Key Quotes
+> "Whenever there's a new family launched by the hyperscale, the latest families are almost cheaper." — Vinay, FINOPS team
+
+> "Rather than spending up unnecessary moment on the extended support, you can deploy additional four or five cluster, right." — 关于 EKS 升级成本
+
+## Key Concepts
+- [[Workload Optimization]]：通过现代化和 Right Sizing 优化工作负载资源配置
+- [[Rate Optimization]]：基于承诺使用获取费率折扣
+- [[Right Sizing]]：识别正确的资源规格以匹配工作负载需求
+- [[Savings Plans]]：AWS 承诺使用折扣计划
+- [[Reserved Instances]]：预留实例，承诺使用折扣
+- [[Spot Instances]]：竞价实例，最高可达 90% 折扣
+- [[Graviton]]：AWS ARM 架构实例，节省 20-25% 成本
+
+## Key Entities
+- [[AWS]]：云服务提供商
+- [[FINOPS Team]]：云财务管理团队
+- [[EKS]]：Amazon Elastic Kubernetes Service
+- [[EC2]]：Amazon Elastic Compute Cloud
+
+## Connections
+- [[AWS]] ← provides ← [[EC2]]
+- [[AWS]] ← provides ← [[EKS]]
+- [[FINOPS Team]] ← owns ← [[Rate Optimization]]
+- [[Workload Optimization]] ← includes ← [[Right Sizing]]
+- [[Workload Optimization]] ← includes ← [[Modernization]]
+
+## Contradictions
+- 认知误区：认为新一代实例更贵 — 实际上新代实例通常更便宜且性能更好
+- EKS 定价变化：M6 之后 M7/M8 定价略高，需要根据实际情况评估

wiki/sources/public-cloud-learning-sessions-storage-cost-optimization-20240305.md

@@ -0,0 +1,49 @@
+---
+title: "Public Cloud Learning Sessions-Storage Cost Optimization - 20240305"
+type: source
+tags: [AWS, Storage, Cost-Optimization, FinOps]
+sources: []
+last_updated: 2026-04-19
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md]]
+
+## Summary
+- 核心主题：AWS 存储服务成本优化最佳实践
+- 问题域：云成本优化、存储分层、存储服务选型
+- 方法/机制：存储类型选择、生命周期策略、数据分层、智能分层
+- 结论/价值：通过合理选择存储类型和使用生命周期策略可显著降低存储成本
+
+## Key Claims
+- GP3 卷相比 GP2 成本降低 20%，且可独立扩展 IOPS 和吞吐量
+- EBS 快照归档层相比标准层成本降低 75%，但恢复时间更长，需保留 90 天
+- EFS 不频繁访问层最小计费对象大小为 128KB
+- S3 智能分层可自动根据访问模式将数据在不同存储层之间移动
+- ADM 迁移到 FSx for NetApp ONTAP 后成本降低 60%
+
+## Key Quotes
+> "With GP3, you can scale IOPS and throughput independently of the volume size." — AWS Storage 最佳实践
+> "With intelligent tiering we can automatically move data from warmer to colder color storage tiers based on object access patterns." — S3 智能分层说明
+
+## Key Concepts
+- [[EBS-GP3]]：通用型 SSD 卷，推荐作为默认存储类型，成本比 GP2 低 20%
+- [[EBS-Snapshot-Archive]]：EBS 快照归档层，成本比标准层低 75%
+- [[EFS-Inrequent-Access]]：EFS 不频繁访问层，适合很少访问的文件
+- [[S3-Intelligent-Tiering]]：S3 智能分层，自动根据访问模式移动数据
+- [[FSx-for-NetApp-ONTAP]]：AWS 文件存储服务，支持自动分层
+- [[Lifecycle-Policy]]：生命周期策略，自动转换存储层
+
+## Key Entities
+- [[ADM]]：一家公司，通过多次迁移最终使用 FSx for NetApp ONTAP 实现 60% 成本降低
+- [[AWS]]：亚马逊云服务提供商
+
+## Connections
+- [[EBS-GP3]] ← improves ← [[EBS-GP2]]
+- [[S3-Intelligent-Tiering]] ← implements ← [[Lifecycle-Policy]]
+- [[EFS-Inrequent-Access]] ← implements ← [[Lifecycle-Policy]]
+- [[FSx-for-NetApp-ONTAP]] ← extends ← [[AWS-FSx]]
+- [[ADM]] ← migrated_to ← [[FSx-for-NetApp-ONTAP]]
+
+## Contradictions
+- 无

wiki/sources/understanding-complete-itsm.md

@@ -0,0 +1,56 @@
+---
+title: "Understanding Complete ITSM"
+type: source
+tags: []
+date: 2025-03-01
+---
+
+## Source File
+- [[raw/Cloud & DevOps/Understanding Complete ITSM.md]]
+
+## Summary
+- 核心主题：现代 IT 服务管理（ITSM）的全面演进，从传统工单系统转变为战略推动者
+- 问题域：IT 运维效率、安全合规、业务连续性
+- 方法/机制：AIOps、零信任架构、Policy-as-Code、基础设施即代码
+- 结论/价值：ITSM 成为运营卓越、风险缓解和创新加速的战略推动者
+
+## Key Claims
+- ITSM 不再仅仅是工单系统，而是运营卓越、风险缓解和创新加速的战略推动者
+- AI 驱动的异常检测和预测分析消除重复性故障，聚焦根本原因而非症状管理
+- 实时可观测性、自动修复和自愈 IT 生态系统正在转变传统响应模式
+- 零信任架构、自动化风险评分和 AI 威胁情报强化 ITSM 对抗网络威胁
+- AIOps、超自动化和 ITSM 2.0 的融合定义了自我学习、预测和自主IT运维的新范式
+
+## Key Quotes
+> "IT Service Management (ITSM) is no longer just about ticketing—it’s the strategic enabler of operational excellence, risk mitigation, and innovation acceleration."
+
+> "The convergence of AIOps, hyperautomation, and ITSM 2.0 is defining a new paradigm: self-learning, predictive, and autonomous IT operations."
+
+## Key Concepts
+- [[AIOps]]：AI 运维，将人工智能应用于 IT 运维，实现异常检测、预测分析和自动化修复
+- [[零信任架构]]（Zero Trust Architecture, ZTA）：永不信任、始终验证的安全框架
+- [[Policy-as-Code]]（PaC）：将安全策略编写为代码，实现自动化合规
+- [[基础设施即代码]]（Infrastructure as Code, IaC）：通过代码管理基础设施的配置和部署
+- [[CMDB]]：配置管理数据库，存储 IT 资产和配置项的关系映射
+- [[RTO]]（Recovery Time Objective）：恢复时间目标，系统允许的最大停机时间
+- [[RPO]]（Recovery Point Objective）：恢复点目标，可接受的最大数据丢失量
+- [[DevOps]]：开发与运维协作的文化和实践
+- [[蓝绿部署]]（Blue-Green Deployment）：零停机部署策略
+- [[金丝雀发布]]（Canary Release）：渐进式发布策略
+- [[超自动化]]（Hyperautomation）：将多种自动化技术结合，实现端到端流程自动化
+
+## Key Entities
+- LinkedIn：文章发布平台
+
+## Connections
+- [[ITSM]] ← extends ← [[传统IT运维]]
+- [[AIOps]] ← enables ← [[事件管理]]
+- [[零信任架构]] ← enforces ← [[安全与合规管理]]
+- [[IaC]] ← enables ← [[变更管理]]
+- [[CMDB]] ← supports ← [[配置管理]]
+
+## Contradictions
+- 与传统 ITSM 观点冲突：
+  - 冲突点：传统 ITSM 聚焦工单处理和流程合规
+  - 当前观点：ITSM 是战略推动者，聚焦业务价值交付
+  - 对方观点：ITSM 是成本中心，以流程效率衡量价值