Auto-sync: 2026-04-20 00:02
This commit is contained in:
@@ -666,4 +666,9 @@ Please consult [these instructions](https://github.com/ChromeDevTools/chrome-dev
|
||||
|
||||
## Known limitations
|
||||
|
||||
See [Troubleshooting](https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md).
|
||||
See [Troubleshooting](https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md).
|
||||
|
||||
---
|
||||
|
||||
## Infographic
|
||||
|
||||
BIN
Hermes/xingzhi/chrome-devtools-mcp-infographic-2026-04-20.png
Normal file
BIN
Hermes/xingzhi/chrome-devtools-mcp-infographic-2026-04-20.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 3.0 MiB |
@@ -0,0 +1,169 @@
|
||||
# Chrome DevTools MCP - Infographic Prompts
|
||||
|
||||
Generated: 2026-04-20
|
||||
Layout: circular-flow
|
||||
Style: chalkboard
|
||||
Aspect: 16:9
|
||||
|
||||
---
|
||||
|
||||
## Part 1: System Prompt
|
||||
|
||||
```
|
||||
Create a professional infographic with the following specifications:
|
||||
|
||||
## Image Specifications
|
||||
- Type: Infographic
|
||||
- Layout: circular-flow (cyclic process showing continuous steps arranged in a circle)
|
||||
- Style: chalkboard (chalk on black board aesthetic)
|
||||
- Aspect Ratio: 16:9
|
||||
- Language: English
|
||||
|
||||
## Core Principles
|
||||
- Follow the circular-flow layout structure: arrange information nodes in a circle with directional arrows
|
||||
- Each section represents a tool category as a node on the circle
|
||||
- Use chalk-drawn style: imperfect hand-drawn lines, chalk dust effects, white/yellow/pink/blue chalk colors
|
||||
- Black chalkboard background (#1A1A1A)
|
||||
- Center can hold the main concept "Chrome DevTools MCP"
|
||||
- Maintain authentic chalk texture on all elements
|
||||
- Use circular arrangement to show the tool workflow cycle
|
||||
- Clear visual hierarchy with color variety
|
||||
|
||||
## Text Requirements
|
||||
- Main titles prominent and readable in chalk white
|
||||
- Key concepts emphasized with chalk yellow/pink
|
||||
- Labels clear and appropriately sized
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Part 2: Style Locking Prompt
|
||||
|
||||
```
|
||||
## Style Guidelines - chalkboard
|
||||
|
||||
### Background
|
||||
- Color: Chalkboard Black (#1A1A1A) or Dark Green-Black (#1C2B1C)
|
||||
- Texture: Realistic chalkboard texture with subtle scratches, dust particles
|
||||
|
||||
### Typography
|
||||
- Hand-drawn chalk lettering with visible chalk texture
|
||||
- White or bright colored chalk for emphasis
|
||||
|
||||
### Color Palette
|
||||
- Background: #1A1A1A (Chalkboard Black)
|
||||
- Primary Text: #F5F5F5 (Chalk White)
|
||||
- Accent 1: #FFE566 (Chalk Yellow) - highlights, emphasis
|
||||
- Accent 2: #FF9999 (Chalk Pink) - secondary highlights
|
||||
- Accent 3: #66B3FF (Chalk Blue) - links, connections
|
||||
- Accent 4: #90EE90 (Chalk Green) - success indicators
|
||||
|
||||
### Visual Elements
|
||||
- Hand-drawn chalk illustrations with sketchy, imperfect lines
|
||||
- Chalk dust effects around text and key elements
|
||||
- Doodles: stars, arrows, underlines, circles
|
||||
- Connection lines with hand-drawn feel
|
||||
- Directional arrows showing cycle flow
|
||||
|
||||
### Do
|
||||
- Maintain authentic chalk texture on all elements
|
||||
- Use imperfect, hand-drawn quality
|
||||
- Add subtle chalk dust and smudge effects
|
||||
- Create visual hierarchy with color variety
|
||||
- Include playful doodles and annotations
|
||||
|
||||
### Don't
|
||||
- Use perfect geometric shapes
|
||||
- Create clean digital-looking lines
|
||||
- Add photorealistic elements
|
||||
- Use gradients or glossy effects
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Part 3: Content Structure Prompt
|
||||
|
||||
```
|
||||
## Content Structure - circular-flow
|
||||
|
||||
### Center Element
|
||||
- "Chrome DevTools MCP" - main concept in center of circle
|
||||
|
||||
### Circle Nodes (6 categories, clockwise flow):
|
||||
1. INPUT AUTOMATION (9 tools)
|
||||
- click, drag, fill, fill_form, handle_dialog, hover, press_key, type_text, upload_file
|
||||
- Chalk Pink icon/node
|
||||
|
||||
2. NAVIGATION AUTOMATION (6 tools)
|
||||
- close_page, list_pages, navigate_page, new_page, select_page, wait_for
|
||||
- Chalk Blue icon/node
|
||||
|
||||
3. EMULATION (2 tools)
|
||||
- emulate, resize_page
|
||||
- Chalk Yellow icon/node
|
||||
|
||||
4. PERFORMANCE (4 tools)
|
||||
- performance_analyze_insight, performance_start_trace, performance_stop_trace, take_memory_snapshot
|
||||
- Chalk Green icon/node
|
||||
|
||||
5. NETWORK (2 tools)
|
||||
- get_network_request, list_network_requests
|
||||
- Chalk Pink icon/node
|
||||
|
||||
6. DEBUGGING (6 tools)
|
||||
- evaluate_script, get_console_message, lighthouse_audit, list_console_messages, take_screenshot, take_snapshot
|
||||
- Chalk Blue icon/node
|
||||
|
||||
### Supported Clients (around the outer edge):
|
||||
- Claude Code, Cline, Cursor, VS Code, Copilot, Codex, Gemini, JetBrains, Kiro, Windsurf, Amp, Antigravity, Command Code, Factory, Mistral, OpenCode, Qoder, Warp
|
||||
|
||||
### Configuration Options (bottom section):
|
||||
- --headless, --slim, --autoConnect, --browser-url, --channel, --viewport, --isolated, --user-data-dir
|
||||
|
||||
### Arrows
|
||||
- Curved directional arrows connecting each node in clockwise direction
|
||||
- Showing continuous workflow cycle
|
||||
|
||||
### Labels in English
|
||||
- All text labels in English
|
||||
- Use chalk white for main text, chalk yellow for emphasis
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Visual Layout Diagram
|
||||
|
||||
```
|
||||
[INPUT]
|
||||
↓
|
||||
↙ ↘
|
||||
[DEBUGGING] ← CENTER → [NAVIGATION]
|
||||
↗ ↣
|
||||
↙ ↘
|
||||
[NETWORK] ←─────────────────────→ [EMULATION]
|
||||
↘ ↙
|
||||
↗ ↣
|
||||
[PERFORMANCE] →
|
||||
↓
|
||||
[???]
|
||||
|
||||
Actually circular flow (clockwise):
|
||||
┌─────────────────────────────────────────┐
|
||||
│ │
|
||||
│ [EMULATION] → [PERFORMANCE] │
|
||||
│ ↗ ↗ │
|
||||
│ │ │ │
|
||||
│ [DEBUGGING] [NAVIGATION] │
|
||||
│ │ │ │
|
||||
│ ↖ ↘ │
|
||||
│ [NETWORK] ← [INPUT] │
|
||||
│ │
|
||||
│ Center: "Chrome DevTools MCP" │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Final Prompt Summary
|
||||
|
||||
Generate a chalkboard-style infographic showing Chrome DevTools MCP tool categories arranged in a circular flow pattern. The circle has 6 nodes representing the tool categories (Input Automation, Navigation, Emulation, Performance, Network, Debugging). Each node displays the tool count and key tool names in chalk-style lettering. The center shows "Chrome DevTools MCP" as the main concept. Arrows show clockwise flow indicating the continuous nature of browser automation workflow. Use authentic chalkboard aesthetic with black background (#1A1A1A), chalk white text, and colorful chalk accents (yellow, pink, blue, green) for visual hierarchy. Include chalk dust effects and hand-drawn imperfect lines throughout.
|
||||
@@ -14,6 +14,9 @@ tags: []
|
||||
|
||||
| 日期 | 时间 | 服务器 | 备份文件 | 状态 |
|
||||
| ---------- | ----- | -------- | ------------------------------------ | ---- |
|
||||
| 2026-04-19 | 22:00 | Mac Mini | openclaw-macmini-20260419220012.tar | ✅ 成功 |
|
||||
| 2026-04-19 | 22:00 | Ubuntu1 | openclaw-ubuntu1-20260419220012.tar | ✅ 成功 |
|
||||
| 2026-04-19 | 22:00 | Ubuntu2 | openclaw-ubuntu2-20260419220012.tar | ✅ 成功 |
|
||||
| 2026-04-18 | 22:00 | Mac Mini | openclaw-macmini-20260418220007.tar | ✅ 成功 |
|
||||
| 2026-04-18 | 22:00 | Ubuntu1 | openclaw-ubuntu1-20260418220033.tar | ✅ 成功 |
|
||||
| 2026-04-18 | 22:00 | Ubuntu2 | openclaw-ubuntu2-20260418220042.tar | ✅ 成功 |
|
||||
|
||||
236
openclaw/每日复盘/2026-04-19.md
Normal file
236
openclaw/每日复盘/2026-04-19.md
Normal file
@@ -0,0 +1,236 @@
|
||||
## 【xinghui】星辉 每日复盘 - 2026-04-19
|
||||
|
||||
**Session**: 7bdb1780-efb1-4c1e-adc8-b0c84ae5d309
|
||||
**时间范围**: 21:45 ~ 21:47
|
||||
**Model**: MiniMax-M2.7 | **Tokens**: 94,385 | **Cost**: $0.0000
|
||||
|
||||
---
|
||||
|
||||
### 主要活动
|
||||
|
||||
**Sessions同步Cron Job执行** (21:45:01)
|
||||
- 触发源: cron ID `83f21f14-d882-4dc7-88b0-f2979dc41333`
|
||||
- 执行内容: 在 Mac Mini、Ubuntu1、Ubuntu2 上运行 sync_sessions.py
|
||||
- 同步 sessions 和 cron jobs/runs 到 Django Admin
|
||||
|
||||
**SIGKILL 问题再次出现** (21:47:17)
|
||||
- 进程 session brisk-ocean (pid 16641) 被 SIGKILL 终止
|
||||
- 这是连续第二天出现同一 cron job SIGKILL 问题（4/18、4/19）
|
||||
- 根因: cron job 的 exec timeout=120s 不足以完成三台服务器同步
|
||||
|
||||
---
|
||||
|
||||
### 问题分析
|
||||
|
||||
1. **超时问题**: sync_sessions.py 在三台服务器上同步大量 session 数据时耗时较长，当前 120s 超时不够
|
||||
2. **进程被强制终止**: SIGKILL 表示进程被系统强制杀死，而非自然结束
|
||||
3. **重试失败**: 星辉尝试用更短超时(30s)重新执行，但仍失败
|
||||
|
||||
---
|
||||
|
||||
### 待改进项
|
||||
|
||||
1. 增加 cron job 超时时间（建议 300s+）
|
||||
2. 优化同步策略（串行执行或错峰）
|
||||
3. 参考 LRN-20260418-001 中关于 SIGKILL 的分析
|
||||
|
||||
---
|
||||
|
||||
### Pattern 追踪
|
||||
|
||||
- `cron.sync-sessions-SIGKILL`: 连续第二天出现，已记录两次
|
||||
- `cron.daily-self-review`: 第 18 次复盘
|
||||
---
|
||||
## 【xingjiang】星匠 每日复盘 - 2026-04-19
|
||||
|
||||
### 1. 主要活动
|
||||
- 成功读取笔记并调用 baoyu-infographic 技能，为 `Toggle-plaftform-offline-NG-for-Native-SACM` 知识库文档和 `Slack` 文档生成信息图，并自动追加至Markdown文件末尾。
|
||||
|
||||
### 2. 错误与教训
|
||||
- **自动化工作流配置故障**：在处理部分调用时，收到了未被正确渲染的模板变量（如 `{{args.vault_root}}`）。这暴露了上游自动化链路（如n8n Webhook节点）在传递 Payload 时的映射错误。
|
||||
|
||||
### 3. 改进建议
|
||||
- 建立对模板占位符的异常识别机制。当输入指令中包含类似 `{{...}}` 的未解析变量时，立即返回明确的诊断信息，要求修复自动化链路配置，避免盲目重试。
|
||||
|
||||
## 【xingyao】星曜 每日复盘 - 2026-04-19
|
||||
|
||||
### 📋 今日执行任务
|
||||
|
||||
| # | 时间 | 任务 | 结果 |
|
||||
|---|------|------|------|
|
||||
| 1 | 01:00 | 技能同步到Ubuntu服务器 | ✅ 318文件同步成功 |
|
||||
| 2 | 07:00 | OpenClaw安全检查 | ⚠️ 部分成功（Ubuntu1/2 openclaw命令失败） |
|
||||
| 3 | 07:15 | Mac Mini性能巡检 | ✅ 报告已发送Telegram |
|
||||
|
||||
---
|
||||
|
||||
### 🔍 关键发现
|
||||
|
||||
#### 1. 安全风险（Critical）
|
||||
- **baoyu-imagine skill**：14处 env-harvesting 凭证泄露风险，影响全三台服务器
|
||||
- **last30days skill**：2处 env-harvesting（Twitter API凭证风险）
|
||||
- **Mac Mini**：小模型(8B)配 web 工具，攻击面大
|
||||
- **Ubuntu1**：fengchi agent exec 权限过宽
|
||||
|
||||
#### 2. 运维问题
|
||||
- Ubuntu1/2：`openclaw healthcheck` SSH执行失败（PATH问题）
|
||||
- Mac Mini：`docker` 命令 SSH会话中找不到（需用完整路径）
|
||||
- Mac Mini：Glances API 长期无响应（监控缺位）
|
||||
- Mac Mini：内存接近满载（15GB/16GB used）
|
||||
|
||||
#### 3. 执行问题
|
||||
- 安全检查在Ubuntu上失败后自行恢复（重试后成功），说明是环境问题非代码问题
|
||||
- 性能巡检 Glances API 失败，使用系统命令备选方案正常完成
|
||||
|
||||
---
|
||||
|
||||
### 📊 量化统计
|
||||
|
||||
- **安全报告**: Critical 3 (Mac)/2 (Ubuntu1)/2 (Ubuntu2)
|
||||
- **同步数据**: 318 文件 × 2 服务器
|
||||
- **Telegram 消息**: 2 条（安全报告 + 性能报告）
|
||||
- **Token消耗**: 安全检查 37KB上下文，性能巡检 33KB上下文
|
||||
|
||||
---
|
||||
|
||||
### 🎯 改进建议
|
||||
|
||||
1. **立即处理**：删除或审查 baoyu-imagine / last30days skills
|
||||
2. **本周处理**：Ubuntu1 exec 权限收紧；Ubuntu2 清理 stale weixin 配置
|
||||
3. **定期维护**：每周重启 OpenClaw Gateway 释放内存；确保 Glances 服务运行
|
||||
4. **流程优化**：所有SSH cron任务统一使用完整命令路径
|
||||
|
||||
---
|
||||
|
||||
### 🔮 明日关注
|
||||
|
||||
- 跟进 baoyu-imagine skill 处理情况
|
||||
- 内存是否持续紧张，考虑 Gateway 重启
|
||||
- 安全检查是否所有服务器均正常完成
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 【xingshu】星枢 每日复盘 - 2026-04-19
|
||||
|
||||
**Session 活跃时间**: 12:20 ~ 12:48（约28分钟）
|
||||
**Model**: MiniMax-M2.7
|
||||
**Token 消耗**: 从约 21K 增至约 56K（单次会话内增长约 35K tokens）
|
||||
|
||||
---
|
||||
|
||||
### 1. 主要活动
|
||||
|
||||
#### ✅ 成功完成
|
||||
- **笔记摘要生成**：读取 `/Users/weishen/Workspace/nexus/openclaw/Slack.md`，整理成结构化摘要，保存至 `/Users/weishen/Workspace/nexus/summary_openclaw_Slack.md`
|
||||
- 内容涵盖 Slack Bot Manifest 配置、6步配置流程、3个现有Bot凭证信息
|
||||
|
||||
#### ❌ 失败任务
|
||||
- **note-infographic-mail Lobster 工作流**：多次尝试运行，最终失败
|
||||
|
||||
---
|
||||
|
||||
### 2. 错误与教训（LRN-20260419-001）
|
||||
|
||||
#### 问题链路分析
|
||||
| 尝试次序 | 时间 | 失败原因 | 错误信息 |
|
||||
|---------|------|---------|---------|
|
||||
| 第1次 | 12:21 | lobster工具路径 | `lobster not found` |
|
||||
| 第2次 | 12:22 | CLI语法错误 | `error: unknown option '--session'` |
|
||||
| 第3次 | 12:22 | exec预检拦截 | `complex interpreter invocation detected` |
|
||||
| 第4次 | 12:24 | clawdbot未配置 | `Tool not available: sessions_send` |
|
||||
| 第5次 | 12:27 | clawdbot安装但配置缺失 | `No .clawdbot directory` |
|
||||
| 第6次 | 12:47 | 模板变量转义失败 | `bad substitution` |
|
||||
| 第7次 | 12:48 | openclaw invoke被阻止 | `plugins.allow excludes "invoke"` |
|
||||
|
||||
#### 根本原因
|
||||
1. **工作流依赖了尚未稳定可用的工具**：`openclaw invoke` 命令需要 `plugins.allow` 配置，而 `sessions_send` 工具在 OpenClaw Gateway 中根本不存在
|
||||
2. **模板变量转义问题**：Lobster 工作流中 `${args.source_note}` 在 shell 上下文中触发 `bad substitution`
|
||||
3. **clawdbot 非内置工具**：需要独立安装和配置才能使用
|
||||
|
||||
#### 教训
|
||||
> **工作流设计原则**：必须先验证工具链可用性，再投入自动化执行。尤其跨系统调用（OpenClaw → Clawdbot）时，任何一个环节配置缺失都会导致整体失败。
|
||||
|
||||
---
|
||||
|
||||
### 3. 待处理项
|
||||
|
||||
- [ ] 修复 `note-infographic-mail` 工作流：改用不依赖 `sessions_send` 的方案
|
||||
- [ ] 在 `plugins.allow` 中添加 `invoke`（如需使用 `openclaw invoke`）
|
||||
- [ ] 清理 `/Users/weishen/.openclaw/temp/xingshu/workflows/` 下临时文件
|
||||
- [ ] 确认 `summary_openclaw_Slack.md` 是否需要生成信息图并发送邮件
|
||||
|
||||
---
|
||||
|
||||
### 4. Pattern 追踪
|
||||
|
||||
- `lobster.workflow.failed`: note-infographic-mail 连续失败，需要系统性修复
|
||||
- `toolchain.missing.deps`: 多个工具依赖缺失，应建立依赖检查机制
|
||||
- `session.tokens.high`: 单次复盘消耗 35K tokens，建议优化上下文策略
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 【yunce】云策 每日复盘 - 2026-04-19
|
||||
|
||||
**Session 活跃时间**: 15:25 ~ 15:30（约5分钟）
|
||||
**Model**: MiniMax-M2.5
|
||||
**Trigger**: Cron Job - [云策]每日复盘
|
||||
|
||||
---
|
||||
|
||||
### 1. 主要活动
|
||||
|
||||
执行每日复盘 cron 任务：
|
||||
- 通过 agent-browser 访问 Django Admin 日报页面
|
||||
- 目标 URL: http://192.168.3.45:8765/admin/daily-reports/yunce/2026-4-19/
|
||||
- 登录凭证: agent/agent123
|
||||
- 页面显示 254 条消息记录
|
||||
|
||||
## 【yunce】云策 每日复盘 - 2026-04-19
|
||||
|
||||
**Session 活跃时间**: 15:25 ~ 15:35（约10分钟）
|
||||
**Model**: MiniMax-M2.5
|
||||
**Trigger**: Cron Job - [云策]每日复盘
|
||||
|
||||
---
|
||||
|
||||
### 1. 主要活动
|
||||
|
||||
执行每日复盘 cron 任务：
|
||||
- 通过 agent-browser 访问 Django Admin 日报页面
|
||||
- 目标 URL: http://192.168.3.45:8765/admin/daily-reports/yunce/2026-4-19/
|
||||
- 登录凭证: agent/agent123
|
||||
- 页面显示 254 条消息记录
|
||||
|
||||
---
|
||||
|
||||
### 2. 实际对话内容
|
||||
|
||||
**Session ID**: 57cf302e-6e5d-4b83-be36-3d2582cf1e4b
|
||||
**Model**: MiniMax-M2.7
|
||||
**Token消耗**: 65,051
|
||||
|
||||
| Seq | Time | Role | Content |
|
||||
|-----|------|------|---------|
|
||||
| 4 | 10:12:54 | User | hi |
|
||||
| 5 | 10:12:58 | Assistant | 你好，比利哥。有什么可以效劳的？ |
|
||||
|
||||
**备注**: 当天只有一组简单对话，用户发送 hi 后助手问候回复。
|
||||
|
||||
---
|
||||
|
||||
### 3. 问题与发现
|
||||
|
||||
- Django Admin 页面显示 254 条消息，但实际当天只有 1 组对话（跨天数据）
|
||||
- agent-browser 无法直接提取消息文本内容，需要逐条点击
|
||||
- 建议：优化批量导出或通过 session jsonl 文件读取
|
||||
|
||||
---
|
||||
|
||||
### 4. Pattern 追踪
|
||||
|
||||
- cron.daily-review.yunce: 第 1 次执行
|
||||
- data-extraction.django-admin: 需要优化
|
||||
|
||||
25
wiki/concepts/AI.md
Normal file
25
wiki/concepts/AI.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "AI"
|
||||
type: concept
|
||||
tags: [technology, intelligence]
|
||||
sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
|
||||
last_updated: 2024-02-06
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI（人工智能）是复制需要人类智能才能完成的任务的系统，是计算机科学的一个分支。
|
||||
|
||||
## Definition
|
||||
Artificial Intelligence (AI) 是指能够复制以前需要人类智能才能完成的任务的系统，通常通过机器学习寻求概率性结果。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：技术/计算机科学
|
||||
- **子领域**：机器学习、深度学习、自然语言处理、计算机视觉
|
||||
- **核心方法**：监督学习、无监督学习、强化学习
|
||||
- **应用**：分类 AI、预测 AI、生成式 AI
|
||||
|
||||
## Connections
|
||||
- [[AI]] ← includes ← [[Machine Learning]]
|
||||
- [[AI]] ← includes ← [[Generative AI]]
|
||||
- [[AWS]] ← provides ← [[AI]]
|
||||
- [[Foundation Model]] ← powers ← [[AI]]
|
||||
41
wiki/concepts/API-Gateway.md
Normal file
41
wiki/concepts/API-Gateway.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "API Gateway"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- API
|
||||
- Gateway
|
||||
date: 2024-09-03
|
||||
---
|
||||
|
||||
## Definition
|
||||
API Gateway 是 AWS 托管服务，用于创建、发布、维护和保护 API。作为 API 的前端入口，将请求路由到后端服务（如 Lambda、EC2），并处理认证、限流、监控等功能。
|
||||
|
||||
## Endpoint Types
|
||||
- **Edge-optimized（边缘优化）**：
|
||||
- 通过 CloudFront CDN 分发
|
||||
- 降低延迟
|
||||
- 适合全球访问
|
||||
|
||||
- **Regional（区域）**：
|
||||
- 同区域部署
|
||||
- 更低延迟
|
||||
- 适合同区域客户端
|
||||
|
||||
- **Private（私有）**：
|
||||
- 仅 VPC 内部访问
|
||||
- 通过 VPC 端点访问
|
||||
- 适合内部服务
|
||||
|
||||
## Key Features
|
||||
- 请求验证：验证 API 密钥、JWT、IAM
|
||||
- 速率限制：防止 API 滥用
|
||||
- 缓存：减少后端调用
|
||||
- 监控：CloudWatch 集成
|
||||
- 自定义域名：绑定自有域名
|
||||
- API 版本管理：v1、v2 版本控制
|
||||
|
||||
## Aliases
|
||||
- Amazon API Gateway
|
||||
- API Gateway
|
||||
26
wiki/concepts/Amazon-Bedrock.md
Normal file
26
wiki/concepts/Amazon-Bedrock.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Amazon Bedrock"
|
||||
type: concept
|
||||
tags: [AWS, AI, generative-AI]
|
||||
sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
|
||||
last_updated: 2024-02-06
|
||||
---
|
||||
|
||||
## Summary
|
||||
Amazon Bedrock 是 AWS 提供的全托管服务，用于使用基础模型构建和扩展生成式 AI 应用。
|
||||
|
||||
## Definition
|
||||
Amazon Bedrock 是 AWS 的全托管服务，允许客户访问和定制强大的基础模型 (Foundation Models)，包括 Amazon Titan 和第三方模型，无需管理底层基础设施。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：AWS AI/ML 服务
|
||||
- **核心功能**：基础模型访问、微调、持续预训练、RAG、Agents
|
||||
- **数据安全**：数据仅在请求响应周期存储
|
||||
- **定制方法**：Fine-tuning、Continued Pre-training
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[Amazon Bedrock]]
|
||||
- [[Amazon Bedrock]] ← hosts ← [[Foundation Model]]
|
||||
- [[Amazon Bedrock]] ← implements ← [[RAG]]
|
||||
- [[Amazon Bedrock]] ← uses ← [[Agents]]
|
||||
- [[Generative AI]] ← powered_by ← [[Amazon Bedrock]]
|
||||
39
wiki/concepts/Budget-Control.md
Normal file
39
wiki/concepts/Budget-Control.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: "Budget Control"
|
||||
type: concept
|
||||
tags: []
|
||||
sources: [Public-Cloud-Learning-Sessions-Budget-Control]
|
||||
last_updated: 2024-03-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AWS Budget Control
|
||||
- 预算控制自动化
|
||||
|
||||
## Definition
|
||||
AWS账户预算控制自动化系统，提供账户所有者详细的支出警报和成本分析报告，实现成本控制。
|
||||
|
||||
## Mechanism
|
||||
- 警报类型：forecast（预测）、actual（实际）、severe（严重）、enforcement（强制执行）四级
|
||||
- 评估间隔：8小时
|
||||
- 执行机制：100%阈值触发SCP阻止新资源创建
|
||||
- 评分系统：考虑账户规模和月末时间，避免惩罚月末轻微超支的账户
|
||||
|
||||
## Components
|
||||
- AWS Budget Alerts：触发SNS主题
|
||||
- Lambda：解析邮件数据，创建详细消息
|
||||
- Step Functions：丰富账户信息、预算详情、联系人数据
|
||||
- SCP：Service Control Policy，限制AWS服务使用
|
||||
|
||||
## Reports
|
||||
- Top Services Report：展示月度服务成本占比（基于Athena数据）
|
||||
- Top Users Report：展示每日用户支出（基于Cost Explorer数据）
|
||||
- Detailed Excel Report：资源级别的成本明细（资源ID、创建者、成本）
|
||||
|
||||
## Related
|
||||
- [[FinOps Team]]
|
||||
- [[SRE Core Team]]
|
||||
- [[Public Cloud Learning Sessions - Budget Control - 20240319]]
|
||||
- [[SCP]]
|
||||
- [[Source Identity]]
|
||||
- [[AWS]]
|
||||
33
wiki/concepts/Cloud-Health.md
Normal file
33
wiki/concepts/Cloud-Health.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Cloud Health"
|
||||
type: concept
|
||||
tags:
|
||||
- FinOps
|
||||
- AWS
|
||||
- Cost-Monitoring
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 定义：云成本分析和监控工具，由 CloudHealth Technologies 开发，后被 VMware 收购
|
||||
- 用途：提供资源清单、成本分析和月度账单洞察
|
||||
- 价值：帮助企业实现云成本可视化、优化资源使用
|
||||
|
||||
## Aliases
|
||||
- AWS CloudHealth
|
||||
- VMware CloudHealth
|
||||
|
||||
## Key Features
|
||||
- 资源清单管理
|
||||
- 成本分析报告
|
||||
- 月度账单洞察
|
||||
- 优化建议生成
|
||||
- 多云支持
|
||||
|
||||
## Connections
|
||||
- [[PCG-Team]] — 使用 Cloud Health 进行成本监控
|
||||
- [[Cost-Optimization]] — 提供优化建议
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-19*
|
||||
37
wiki/concepts/Cross-Account-Event-Forwarding.md
Normal file
37
wiki/concepts/Cross-Account-Event-Forwarding.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: Cross-Account Event Forwarding
|
||||
type: concept
|
||||
tags: [aws, eventbridge, multi-account, event-driven]
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
跨账号事件转发（Cross-Account Event Forwarding）是指通过 Amazon EventBridge 将一个 AWS 账号中的事件路由到另一个 AWS 账号的机制。该机制允许组织在多账号架构中实现集中式事件管理。
|
||||
|
||||
## 核心机制
|
||||
|
||||
- **自定义事件总线**：在管理账号创建自定义事件总线，配置跨账号权限策略
|
||||
- **PutEvents API**：源账号通过 PutEvents API 将事件发送到目标账号的事件总线
|
||||
- **事件规则**：目标账号通过事件规则过滤和处理接收的事件
|
||||
|
||||
## 组件
|
||||
|
||||
- **Event Bus**：事件总线，事件的入口点
|
||||
- **Event Rule**：事件规则，用于过滤和路由事件
|
||||
- **Permission Policy**：事件总线的跨账号权限策略
|
||||
|
||||
## 应用场景
|
||||
|
||||
- **集中日志收集**：将多个账号的 CloudFormation 事件转发到管理账号
|
||||
- **集中告警**：跨账号统一告警通知
|
||||
- **安全事件集中**：安全相关事件集中到 SOC 账号
|
||||
|
||||
## 与集中式日志的关系
|
||||
|
||||
跨账号事件转发是实现集中式日志的关键技术基础。通过 EventBridge 将分散在各账号的事件汇聚到中央存储位置（如 CloudWatch Logs 或 OpenSearch），实现统一监控和查询。
|
||||
|
||||
## Connections
|
||||
- [[EventBridge]] ← implements ← [[Cross-Account Event Forwarding]]
|
||||
- [[Centralized Logging]] ← depends_on ← [[Cross-Account Event Forwarding]]
|
||||
- [[Multi-Account Strategy]] ← enables ← [[Cross-Account Event Forwarding]]
|
||||
30
wiki/concepts/Declarative-Configuration.md
Normal file
30
wiki/concepts/Declarative-Configuration.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Declarative Configuration"
|
||||
type: concept
|
||||
tags: [DevOps, GitOps, 配置管理]
|
||||
sources: [ctp-topic-33-an-introduction-to-gitops.md]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Declarative Configuration（声明式配置）是一种配置管理方法，通过描述系统的期望状态（what）而非具体步骤（how）来定义基础设施和应用配置。
|
||||
|
||||
## Key Characteristics
|
||||
- 定义期望的结果状态，而非实现步骤
|
||||
- 工具负责计算如何达到期望状态
|
||||
- 幂等性：多次应用产生相同结果
|
||||
- 易于理解和版本控制
|
||||
|
||||
## Examples
|
||||
- Kubernetes YAML 配置
|
||||
- Terraform HCL 配置
|
||||
- Docker Compose 配置
|
||||
- Ansible Playbook
|
||||
|
||||
## Related Concepts
|
||||
- [[Infrastructure as Code (IaC)]]
|
||||
- [[GitOps]]
|
||||
- [[Idempotent Operation]]（幂等操作）
|
||||
|
||||
## Related Sources
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
|
||||
26
wiki/concepts/Demand-Management.md
Normal file
26
wiki/concepts/Demand-Management.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Demand Management"
|
||||
type: concept
|
||||
tags: [ITSM, Cloud, FinOps]
|
||||
---
|
||||
|
||||
## Definition
|
||||
需求管理是一种平衡用户请求与可用容量的业务流程，确保组织能够有效地管理和分配资源。
|
||||
|
||||
## Context
|
||||
在云资源管理的背景下，需求管理用于平衡对超大规模云服务商（如 AWS、Azure、GCP）的资源请求与组织可用的计算、存储和网络容量。Oli 工作流通过三阶段审批流程实现需求管理：可行性验证、技术可行性验证和预算可用性验证。
|
||||
|
||||
## Key Points
|
||||
- 请求方负责推动其工作流获得批准
|
||||
- 审批流程包括：发起人、请求者经理、M5、实验室服务总监、基础设施 M5、云服务基础设施、云服务、最终审批（Shannon 或 MUI）
|
||||
- 机器应执行机器能做的事，实现自动化处理
|
||||
- 目标是让业务部门 80% 的时间能够自主选择所需服务
|
||||
|
||||
## Related Concepts
|
||||
- [[ITIL Framework]]
|
||||
- [[Service Catalog]]
|
||||
- [[Workflow Process]]
|
||||
|
||||
## Related Entities
|
||||
- [[FinOps Team]]
|
||||
- [[FPNA Team]]
|
||||
40
wiki/concepts/EBS-GP3.md
Normal file
40
wiki/concepts/EBS-GP3.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "EBS GP3"
|
||||
type: concept
|
||||
tags: [AWS, EBS, Storage, Cost-Optimization]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
EBS GP3（General Purpose SSD 第3代）是 AWS EBS 的一种卷类型，推荐作为通用型 SSD 的默认选择，成本比 GP2 低 20%，且可独立扩展 IOPS 和吞吐量。
|
||||
|
||||
## Key Features
|
||||
- **成本节省**：比 GP2 便宜约 20%
|
||||
- **独立扩展**：IOPS 和吞吐量可独立于卷大小进行扩展
|
||||
- **高 IOPS**：最大 16,000 IOPS（最高配置）
|
||||
- **高吞吐量**：最大 1,000 MB/s（最高配置）
|
||||
|
||||
## Specifications
|
||||
| 属性 | GP3 默认 | GP3 最大 |
|
||||
|------|---------|---------|
|
||||
| 卷大小 | 1 GiB - 16 TiB | 1 GiB - 16 TiB |
|
||||
| IOPS | 3,000 | 16,000 |
|
||||
| 吞吐量 | 125 MB/s | 1,000 MB/s |
|
||||
|
||||
## Use Cases
|
||||
- 数据库工作负载
|
||||
- 虚拟化桌面
|
||||
- 应用服务器
|
||||
- 开发测试环境
|
||||
- 企业应用
|
||||
|
||||
## Migration from GP2
|
||||
- 自动化工具应更新为默认创建 GP3 卷
|
||||
- GP2 迁移到 GP3 可立即节省成本
|
||||
- 无需停机即可完成迁移
|
||||
|
||||
## Connections
|
||||
- [[EBS-GP2]] ← improves ← [[EBS-GP3]]
|
||||
- [[EBS-Snapshot-Archive]] ← uses ← [[EBS]]
|
||||
- [[AWS]] ← provides ← [[EBS-GP3]]
|
||||
53
wiki/concepts/EBS-Snapshot-Archive.md
Normal file
53
wiki/concepts/EBS-Snapshot-Archive.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "EBS Snapshot Archive"
|
||||
type: concept
|
||||
tags: [AWS, EBS, Snapshot, Storage, Cost-Optimization]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
EBS Snapshot Archive（EBS 快照归档层）是 AWS EBS 快照的长期存储层，成本比标准快照层低 75%，适合很少需要访问的快照，但恢复时间更长且需保留 90 天。
|
||||
|
||||
## Key Features
|
||||
- **成本节省**：比标准快照层低约 75%
|
||||
- **长期保留**：最短保留期限 90 天
|
||||
- **恢复时间**：需要 24-72 小时恢复可用
|
||||
- **自动化管理**：通过 Data Lifecycle Manager (DLM) 或 AWS Backup 管理
|
||||
|
||||
## Pricing Comparison
|
||||
| 存储类型 | 价格（每 GB/月） |
|
||||
|---------|----------------|
|
||||
| 标准快照 | $0.05 |
|
||||
| 归档快照 | $0.0125 |
|
||||
|
||||
## Use Cases
|
||||
- 长期合规性快照备份
|
||||
- 灾难恢复基础镜像
|
||||
- 软件发布版本镜像
|
||||
- 历史数据存档
|
||||
|
||||
## Implementation
|
||||
通过 DLM 创建生命周期策略：
|
||||
```json
|
||||
{
|
||||
"LifecyclePolicy": {
|
||||
"TargetTags": ["Backup"],
|
||||
"PolicyRules": [
|
||||
{
|
||||
"RuleName": "Archive",
|
||||
"CopyTags": true,
|
||||
"TransitionToArchive": {
|
||||
"DaysAfterCreation": 90
|
||||
},
|
||||
"RetainUntilExpiration": false
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Connections
|
||||
- [[EBS-GP3]] ← uses ← [[EBS]]
|
||||
- [[Lifecycle-Policy]] → implements → [[EBS-Snapshot-Archive]]
|
||||
- [[AWS]] ← provides ← [[EBS-Snapshot-Archive]]
|
||||
46
wiki/concepts/EC2-Spot-Instances.md
Normal file
46
wiki/concepts/EC2-Spot-Instances.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "EC2 Spot Instances"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- EC2
|
||||
- Cost-Optimization
|
||||
- Spot
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
EC2 Spot Instances 是 AWS 提供的一种利用闲置计算容量的实例类型，相比按需定价最高可节省 90% 成本。
|
||||
|
||||
## Key Characteristics
|
||||
- 利用 AWS 数据中心的闲置容量
|
||||
- 相比按需实例最高可享 90% 折扣
|
||||
- 当 AWS 需要回收容量时可能会被中断
|
||||
- 提供中断前通知机制
|
||||
- 支持与 Auto Scaling、EKS、ECS 集成
|
||||
|
||||
## Use Cases
|
||||
- Web 服务（具备容错能力）
|
||||
- 容器化工作负载
|
||||
- 高性能计算批处理
|
||||
- 大数据分析
|
||||
- CI/CD 流水线
|
||||
|
||||
## Key Considerations
|
||||
- **容错能力**：应用需能处理实例中断
|
||||
- **灵活性**：支持跨多个实例类型和可用区
|
||||
- **无状态**：适合无状态工作负载
|
||||
- **中断风险**：AWS 提前 2 分钟通知回收
|
||||
|
||||
## Best Practices
|
||||
- 跨实例类型和可用区分散部署
|
||||
- 配置自动响应中断的机制
|
||||
- 结合 Graviton 使用进一步优化成本
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[EC2-Spot-Instances]]
|
||||
- [[Cost-Optimization]] ← achieved_by ← [[EC2-Spot-Instances]]
|
||||
- [[Spot-Interruption]] ← risk_of ← [[EC2-Spot-Instances]]
|
||||
- [[EKS]] ← supports ← [[EC2-Spot-Instances]]
|
||||
- [[ECS]] ← supports ← [[EC2-Spot-Instances]]
|
||||
43
wiki/concepts/EFS-Infrequent-Access.md
Normal file
43
wiki/concepts/EFS-Infrequent-Access.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "EFS Infrequent Access"
|
||||
type: concept
|
||||
tags: [AWS, EFS, Storage, Cost-Optimization]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
EFS Infrequent Access（EFS 不频繁访问层）是 AWS EFS 的一种存储层，适合很少访问的文件，通过生命周期策略自动将冷文件移动到低成本的存储层。
|
||||
|
||||
## Key Features
|
||||
- **成本节省**：比标准层低约 85%
|
||||
- **自动分层**：通过生命周期策略自动转移
|
||||
- **即时访问**：访问不频繁访问层数据时自动移回标准层
|
||||
- **最小计费对象**：128KB 以下文件不计费
|
||||
|
||||
## Pricing
|
||||
| 存储类型 | 价格（每 GB/月） |
|
||||
|---------|----------------|
|
||||
| 标准层 | $0.30 |
|
||||
| 不频繁访问层 | $0.045 |
|
||||
|
||||
## Lifecycle Policy
|
||||
```json
|
||||
{
|
||||
"LifecyclePolicies": [
|
||||
{
|
||||
"TransitionToIA": "After 30 days of last access"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Considerations
|
||||
- **最小计费对象大小**：128KB 以下文件计费为 128KB
|
||||
- **访问成本**：检索数据时有额外的访问费用
|
||||
- **适合场景**：日志文件、备份文件、归档数据
|
||||
|
||||
## Connections
|
||||
- [[EFS-Standard]] ← extends ← [[EFS]]
|
||||
- [[Lifecycle-Policy]] → implements → [[EFS-Infrequent-Access]]
|
||||
- [[AWS]] ← provides ← [[EFS-Infrequent-Access]]
|
||||
35
wiki/concepts/Event-Driven-Architecture.md
Normal file
35
wiki/concepts/Event-Driven-Architecture.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Event-Driven Architecture"
|
||||
type: concept
|
||||
tags: [Architecture, Event-Driven, Async, Serverless]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
事件驱动架构是一种以事件为核心驱动系统行为的架构模式，实现服务间松耦合。
|
||||
|
||||
## Definition
|
||||
Event-Driven Architecture（EDA）是一种软件架构范式，组件之间通过事件（状态变化或动作）进行通信和解耦。
|
||||
|
||||
## Core Characteristics
|
||||
- **异步通信**：事件生产者与消费者基于事件解耦
|
||||
- **事件驱动**：行为由事件触发，而非直接调用
|
||||
- **松耦合**：事件生产者不关心消费者实现
|
||||
- **可扩展性**：易于扩展新事件消费者
|
||||
|
||||
## Use Cases
|
||||
- 实时数据处理
|
||||
- 微服务异步通信
|
||||
- 物联网数据采集
|
||||
- 实时工作流触发
|
||||
|
||||
## Related Services
|
||||
- [[EventBridge]]：AWS 事件总线
|
||||
- [[Amazon SQS]]：消息队列
|
||||
- [[Amazon SNS]]：发布/订阅通知
|
||||
- [[Lambda]]：事件目标
|
||||
|
||||
## Related Patterns
|
||||
- [[Message Queue]]：消息队列模式
|
||||
- [[Pub/Sub]]：发布/订阅模式
|
||||
45
wiki/concepts/FSx-for-NetApp-ONTAP.md
Normal file
45
wiki/concepts/FSx-for-NetApp-ONTAP.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "FSx for NetApp ONTAP"
|
||||
type: concept
|
||||
tags: [AWS, FSx, NetApp, Storage, Cost-Optimization]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
FSx for NetApp ONTAP 是 AWS 提供的托管 NetApp ONTAP 文件系统服务，支持自动分层功能，可在 SSD 和 HDD 容量池之间自动移动数据以优化成本。
|
||||
|
||||
## Key Features
|
||||
- **自动分层**：在 SSD 和 HDD 容量池之间自动移动数据
|
||||
- **数据去重**：内置重复数据删除功能
|
||||
- **压缩**：支持数据压缩减少存储空间
|
||||
- **NetApp 兼容性**：与 ONTAP 原生协议兼容
|
||||
- **成本优化**：相比 EBS 可节省高达 60% 成本
|
||||
|
||||
## Architecture
|
||||
- **SSD 存储池**：高性能层，存储活跃数据
|
||||
- **HDD 容量池**：低成本层，存储冷数据
|
||||
- **自动迁移**：根据策略自动在层级之间移动数据
|
||||
|
||||
## Use Cases
|
||||
- 企业文件共享
|
||||
- 数据库存储
|
||||
- 媒体处理
|
||||
- 软件开发环境
|
||||
- 数据归档
|
||||
|
||||
## Pricing
|
||||
- SSD 存储：$0.08/GB/月
|
||||
- HDD 容量池：$0.02/GB/月
|
||||
- 数据传输：标准 AWS 数据Transfer rates
|
||||
|
||||
## Migration Example
|
||||
ADM 公司通过多次迁移最终选择 FSx for NetApp ONTAP：
|
||||
1. 初始迁移到 OpenZFS：成本高
|
||||
2. 自托管 NetApp on EC2：高数据传输成本
|
||||
3. 迁移到 FSx for NetApp ONTAP：**成本降低 60%**
|
||||
|
||||
## Connections
|
||||
- [[AWS-FSx]] ← extends ← [[FSx-for-NetApp-ONTAP]]
|
||||
- [[NetApp]] ← provides ← [[FSx-for-NetApp-ONTAP]]
|
||||
- [[AD]] ← migrated_to ← [[FSx-for-NetApp-ONTAP]]
|
||||
25
wiki/concepts/Fan-out-Pattern.md
Normal file
25
wiki/concepts/Fan-out-Pattern.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Fan-out Pattern"
|
||||
type: concept
|
||||
tags:
|
||||
- Messaging
|
||||
- EDA
|
||||
- Architecture
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Fan-out Pattern（扇出模式）是一种消息传递模式，一个事件可以同时分发给多个消费者。当一个事件需要触发多个独立的处理流程时，扇出模式可以高效实现一对多的通知机制。
|
||||
|
||||
## Implementation
|
||||
- **SNS Topic**：发布/订阅模式，一个消息发布到主题，多个订阅者接收
|
||||
- **EventBridge Rule**：基于规则将事件路由到多个目标
|
||||
|
||||
## Use Cases
|
||||
- 单个订单创建事件触发：库存更新、通知发送、数据分析、财务处理等多个独立流程
|
||||
- 用户注册事件触发：欢迎邮件、积分奖励、偏好初始化等多个独立业务逻辑
|
||||
|
||||
## Relationship
|
||||
- [[Event-Driven Architecture]] ← uses ← [[Fan-out Pattern]]
|
||||
- [[Fan-out Pattern]] ← implemented_by ← [[Amazon SNS]]
|
||||
- [[Fan-out Pattern]] ← implemented_by ← [[EventBridge]]
|
||||
26
wiki/concepts/Foundation-Model.md
Normal file
26
wiki/concepts/Foundation-Model.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Foundation Model"
|
||||
type: concept
|
||||
tags: [AI, generative-AI, ML]
|
||||
sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
|
||||
last_updated: 2024-02-06
|
||||
---
|
||||
|
||||
## Summary
|
||||
基础模型是具有数十亿参数的大规模预训练模型，能够执行多种任务，是生成式 AI 的核心。
|
||||
|
||||
## Definition
|
||||
Foundation Model（基础模型）是经过大规模预训练的大语言模型，具备零样本和少样本学习能力，可通过微调适应各种下游任务。
|
||||
|
||||
## Key Attributes
|
||||
- **参数规模**：数十亿参数
|
||||
- **训练方式**：大规模预训练
|
||||
- **特点**：零样本学习、少样本学习、多任务能力
|
||||
- **代表模型**：Amazon Titan、GPT-4、Claude、Llama
|
||||
|
||||
## Connections
|
||||
- [[AI]] ← powers ← [[Foundation Model]]
|
||||
- [[Generative AI]] ← powered_by ← [[Foundation Model]]
|
||||
- [[Amazon Bedrock]] ← hosts ← [[Foundation Model]]
|
||||
- [[Foundation Model]] ← supports ← [[Fine-Tuning]]
|
||||
- [[Foundation Model]] ← supports ← [[RAG]]
|
||||
@@ -31,4 +31,6 @@ Generative AI（生成式 AI）是指能够根据学习到的模式和数据创
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← 区别于 ← Generative AI：核心用途不同
|
||||
- [[LLM]] ← powers ← Generative AI：大语言模型是 GenAI 的技术基础
|
||||
- [[LLM]] ← powers ← Generative AI：大语言模型是 GenAI 的技术基础
|
||||
- [[Foundation Model]] ← powers ← Generative AI：基础模型是生成式 AI 的核心
|
||||
- [[Amazon Bedrock]] ← provides ← Generative AI：AWS 提供 Bedrock 服务
|
||||
38
wiki/concepts/Git.md
Normal file
38
wiki/concepts/Git.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Git"
|
||||
type: concept
|
||||
tags: [Git, VCS, 版本控制, DevOps]
|
||||
sources: [ctp-topic-2-git.md]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Git（分布式版本控制系统）是一种开源的分布式版本控制系统，用于跟踪代码变更、支持多人协作开发。每个开发人员都拥有完整的代码仓库副本，支持离线工作、分支合并和历史追溯。
|
||||
|
||||
## Core Features
|
||||
- 分布式架构：每个用户拥有完整仓库副本
|
||||
- 分支管理：支持轻量级分支和快速合并
|
||||
- 完整性保证：使用 SHA-1 哈希确保数据完整性
|
||||
- 性能：本地操作极快，网络操作按需拉取
|
||||
|
||||
## Common Commands
|
||||
- `git clone`：克隆远程仓库
|
||||
- `git add` / `git commit`：暂存和提交更改
|
||||
- `git push` / `git pull`：推送和拉取远程更改
|
||||
- `git branch` / `git checkout`：分支管理
|
||||
- `git merge` / `git rebase`：合并分支
|
||||
|
||||
## Related Concepts
|
||||
- [[Infrastructure as Code (IaC)]]
|
||||
- [[CI/CD 流水线]]
|
||||
- [[GitOps]]
|
||||
|
||||
## Related Entities
|
||||
- [[GitHub]]
|
||||
- [[GitLab]]
|
||||
- [[Gitea]]
|
||||
|
||||
## Aliases
|
||||
- Git
|
||||
- Git 版本控制
|
||||
- 分布式版本控制
|
||||
@@ -2,20 +2,52 @@
|
||||
title: "GitOps"
|
||||
type: concept
|
||||
tags: [DevOps, Git, 基础设施, 部署]
|
||||
sources: [DevOps-Culture-and-Transformation.md]
|
||||
last_updated: 2025-03-02
|
||||
sources: [DevOps-Culture-and-Transformation.md, ctp-topic-33-an-introduction-to-gitops.md]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
GitOps 是一种使用 Git 作为单一真相源（Single Source of Truth）来管理基础设施和部署的文化理念和运维框架，所有配置和部署声明都存储在 Git 仓库中。
|
||||
GitOps 是一种使用 Git 作为单一真相源（Single Source of Truth）来管理基础设施和部署的文化理念和运维框架，所有配置和部署声明都存储在 Git 仓库中。它是 DevOps 的逻辑演进，将软件开发原则应用于部署流程。
|
||||
|
||||
## Key Principles（关键原则）
|
||||
- 声明式基础设施
|
||||
- Git 作为单一真相源
|
||||
- 自动同步和部署
|
||||
- 可审计和可回滚
|
||||
## Key Principles（四大原则）
|
||||
1. **Declarative Configuration**（声明式配置）：系统以声明形式定义，描述期望状态而非具体步骤
|
||||
2. **Version Control**（版本控制）：所有配置存储在 Git 中，实现版本管理和审计追踪
|
||||
3. **CD Process Separation**（CD 流程分离）：CI 和 CD 解耦以增强安全性
|
||||
4. **Incremental Infrastructure**（增量基础设施）：渐进式实施基础设施变更
|
||||
|
||||
## Related Concepts
|
||||
- [[DevOps 文化]]
|
||||
- [[Infrastructure as Code (IaC)]]
|
||||
## Core Benefits（核心优势）
|
||||
- 使用开发者熟悉的工具提升开发生产力
|
||||
- 通过轻松的回滚能力最小化失败部署
|
||||
- 支持更快的功能发布
|
||||
- 通过 Git 特性实现实时审计和改进安全性
|
||||
|
||||
## Key Components（核心组件）
|
||||
- **Git**：存储部署基础设施和应用配置，作为唯一真相源
|
||||
- **GitOps Controller**：协调 Git 状态与实际系统状态的代理
|
||||
- **CD Pipeline**：自动化部署流程
|
||||
- **Infrastructure as Code**：通过代码管理基础设施
|
||||
|
||||
## Implementation Models（实现模型）
|
||||
- **Pull Model**（拉取模型）：GitOps 推荐模型，监控 Git 和目标系统，自动同步变更
|
||||
- **Push Model**（推送模型）：传统 CI/CD 部署模式，通过触发器推送变更
|
||||
|
||||
## Kubernetes Workflow
|
||||
1. 开发者提交代码
|
||||
2. 创建容器镜像
|
||||
3. 将部署配置存储在 Git 中
|
||||
4. GitOps Agent 监控变化
|
||||
5. 向环境推出镜像
|
||||
|
||||
## Key Concepts
|
||||
- [[Declarative Configuration]]（声明式配置）
|
||||
- [[Infrastructure as Code (IaC)]]（基础设施即代码）
|
||||
- [[CI/CD 流水线]]
|
||||
- [[Pull Model]]（拉取模型）
|
||||
- [[Idempotent Operation]]（幂等操作）
|
||||
|
||||
## Related Entities
|
||||
- [[Victor Etkin]] — GitOps 概念的演讲者和布道者
|
||||
|
||||
## Related Sources
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
|
||||
- [[DevOps-Culture-and-Transformation]] — DevOps 文化转型
|
||||
21
wiki/concepts/ITIL-Framework.md
Normal file
21
wiki/concepts/ITIL-Framework.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "ITIL Framework"
|
||||
type: concept
|
||||
tags: [ITSM, Service-Management]
|
||||
---
|
||||
|
||||
## Definition
|
||||
ITIL（Information Technology Infrastructure Library）是一个广泛使用的 IT 服务管理框架，将业务流程分为五个核心阶段：服务战略（Service Strategy）、服务设计（Service Design）、服务转换（Service Transition）、服务运营（Service Operation）和持续改进（Continual Improvement）。
|
||||
|
||||
## Context
|
||||
在 Oli 工作流流程中，ITIL 框架提供了需求管理的理论支撑。审批流程是请求处理的第一阶段，之后是需求管理和定义工作。云资源请求的完整端到端流程包括：审批阶段、需求管理和定义工作。
|
||||
|
||||
## Key Points
|
||||
- 审批流程是请求处理的第一阶段
|
||||
- 服务目录正在开发中，将合并云产品的标准化清单
|
||||
- 目标是简化业务部门从目录中识别和请求服务的过程
|
||||
|
||||
## Related Concepts
|
||||
- [[Demand Management]]
|
||||
- [[Service Catalog]]
|
||||
- [[Workflow Process]]
|
||||
34
wiki/concepts/Idempotent-Operation.md
Normal file
34
wiki/concepts/Idempotent-Operation.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Idempotent Operation"
|
||||
type: concept
|
||||
tags: [DevOps, GitOps, 基础概念]
|
||||
sources: [ctp-topic-33-an-introduction-to-gitops.md]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Idempotent Operation（幂等操作）是指可以多次执行而不会改变超出初始应用结果的操作。无论执行多少次，最终状态都与执行一次相同。
|
||||
|
||||
## Examples
|
||||
- Kubernetes 部署：多次 apply 相同配置不会导致重复创建
|
||||
- Terraform apply：重复执行会产生相同的基础设施状态
|
||||
- 文件权限设置：重复 chmod 相同权限
|
||||
- 数据库 UPSERT：重复插入或更新
|
||||
|
||||
## Non-Idempotent Examples
|
||||
- `curl` 请求：每次执行都会创建新资源
|
||||
- 计数器递增：每次执行都会改变值
|
||||
- 文件追加：重复执行会累积内容
|
||||
|
||||
## Importance in GitOps
|
||||
- 确保部署过程可重复执行
|
||||
- 支持自动重试和恢复
|
||||
- 简化故障处理和调试
|
||||
|
||||
## Related Concepts
|
||||
- [[GitOps]]
|
||||
- [[Declarative Configuration]]
|
||||
- [[Infrastructure as Code (IaC)]]
|
||||
|
||||
## Related Sources
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
|
||||
@@ -2,8 +2,8 @@
|
||||
title: "Infrastructure as Code (IaC)"
|
||||
type: concept
|
||||
tags: [DevOps, 基础设施, 自动化, 版本控制]
|
||||
sources: [DevOps-Culture-and-Transformation.md]
|
||||
last_updated: 2025-03-02
|
||||
sources: [DevOps-Culture-and-Transformation.md, ctp-topic-33-an-introduction-to-gitops.md]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
@@ -18,3 +18,5 @@ last_updated: 2025-03-02
|
||||
- [[DevOps 文化]]
|
||||
- [[CI/CD 流水线]]
|
||||
- [[GitOps]]
|
||||
- [[Declarative Configuration]]
|
||||
- [[Idempotent Operation]]
|
||||
|
||||
40
wiki/concepts/Instance-Scheduling.md
Normal file
40
wiki/concepts/Instance-Scheduling.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Instance Scheduling"
|
||||
type: concept
|
||||
tags:
|
||||
- FinOps
|
||||
- Cost-Optimization
|
||||
- Automation
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Instance Scheduler
|
||||
- EC2 Scheduling
|
||||
- RDS Scheduling
|
||||
- 定时启停
|
||||
|
||||
## Definition
|
||||
通过预设时间规则自动控制 EC2 和 RDS 实例启停的技术，实现非生产环境成本优化。
|
||||
|
||||
## Mechanism
|
||||
- 基于 CloudWatch Events 定时触发
|
||||
- Lambda 读取 DynamoDB 配置表中的调度规则
|
||||
- 根据实例标签（Schedule、Period）执行启停操作
|
||||
- 支持时区配置和自定义工作时间
|
||||
|
||||
## Use Cases
|
||||
- 开发/测试环境非工作时间自动关机
|
||||
- 按地区办公时间配置调度
|
||||
- 强制维护窗口配合（RDS）
|
||||
- Override 状态强制保持停机
|
||||
|
||||
## Related Entities
|
||||
- [[AWS Instance Scheduler]]
|
||||
- [[CloudWatch Events]]
|
||||
- [[DynamoDB Config Table]]
|
||||
|
||||
## Related Concepts
|
||||
- [[Cost Optimization]]
|
||||
- [[Right Sizing]]
|
||||
- [[Workload Optimization]]
|
||||
35
wiki/concepts/Lambda.md
Normal file
35
wiki/concepts/Lambda.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Lambda"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- Compute
|
||||
- Cloud-Native
|
||||
date: 2024-09-03
|
||||
---
|
||||
|
||||
## Definition
|
||||
AWS Lambda 是无服务器（Serverless）计算服务，开发者只需编写业务逻辑代码，AWS 自动处理服务器配置、扩展和运维。Lambda 函数由事件触发，当事件发生时执行相应的代码。
|
||||
|
||||
## Core Characteristics
|
||||
- 事件驱动：Lambda 函数由状态变化（事件）触发
|
||||
- 按需付费：按请求数和执行时长计费
|
||||
- 自动扩展：AWS 自动处理负载均衡和扩展
|
||||
- 支持语言：Node.js、Python、Java、C#、Go、Ruby 等
|
||||
|
||||
## Invocation Types
|
||||
- 同步调用：调用者等待响应
|
||||
- 异步调用：事件进入队列后立即返回
|
||||
- 事件源映射：根据流或队列事件触发
|
||||
|
||||
## Management Features
|
||||
- 版本控制：发布代码快照，通过别名指向特定版本
|
||||
- 别名：指向特定版本的指针，支持蓝绿部署
|
||||
- Layers：共享公共代码库
|
||||
- 并发控制：设置函数并发上限
|
||||
|
||||
## Aliases
|
||||
- AWS Lambda
|
||||
- Lambda 函数
|
||||
- Lambda Function
|
||||
43
wiki/concepts/Lifecycle-Policy.md
Normal file
43
wiki/concepts/Lifecycle-Policy.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Lifecycle Policy"
|
||||
type: concept
|
||||
tags: [AWS, Storage, Cost-Optimization]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
生命周期策略是一种自动化规则，用于在不同存储层之间自动转换数据、设置保留策略和管理过期对象，无需手动操作。
|
||||
|
||||
## Key Features
|
||||
- 自动存储层转换：根据预设规则将数据从热存储移动到冷存储
|
||||
- 保留策略：设置快照和对象的保留期限
|
||||
- 过期清理：自动删除过期对象和不完整的分段上传
|
||||
- 成本优化：减少存储费用，优化存储支出
|
||||
|
||||
## AWS Services
|
||||
- **S3 Lifecycle Policies**：转换对象到 S3 Standard → Intelligent-Tiering → Glacier 层级
|
||||
- **EFS Lifecycle Policies**：将文件在标准层和不频繁访问层之间移动
|
||||
- **EBS Snapshot Lifecycle**：归档快照到 Archive 层，使用 DLM 或 AWS Backup
|
||||
|
||||
## Implementation
|
||||
```json
|
||||
{
|
||||
"Rules": [
|
||||
{
|
||||
"ID": "MoveToGlacier",
|
||||
"Status": "Enabled",
|
||||
"Filter": {"Prefix": "archive/"},
|
||||
"Transitions": [
|
||||
{"Days": 365, "StorageClass": "GLACIER"}
|
||||
],
|
||||
"Expiration": {"Days": 1825}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Connections
|
||||
- [[S3-Intelligent-Tiering]] ← implements ← [[Lifecycle-Policy]]
|
||||
- [[EFS-Inrequent-Access]] ← implements ← [[Lifecycle-Policy]]
|
||||
- [[EBS-Snapshot-Archive]] ← uses ← [[Lifecycle-Policy]]
|
||||
23
wiki/concepts/ML-Ops.md
Normal file
23
wiki/concepts/ML-Ops.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "ML Ops"
|
||||
type: concept
|
||||
tags: [DevOps, ML, operations]
|
||||
sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
|
||||
last_updated: 2024-02-06
|
||||
---
|
||||
|
||||
## Summary
|
||||
ML Ops 结合机器学习和运营，涉及人员、技术和流程，以实现协作式 ML 解决方案。
|
||||
|
||||
## Definition
|
||||
ML Ops (Machine Learning Operations) 是将 DevOps 原则应用于机器学习系统的实践，包括数据管道、训练管道和推理管道的自动化和监控。
|
||||
|
||||
## Key Attributes
|
||||
- **核心组成**：数据管道、训练管道、推理管道
|
||||
- **关注点**：数据溯源、模型管理、部署工作流
|
||||
- **工具**：Amazon SageMaker、MLflow、Kubeflow
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[ML Ops]]
|
||||
- [[ML Ops]] ← manages ← [[Machine Learning]]
|
||||
- [[Amazon SageMaker]] ← implements ← [[ML Ops]]
|
||||
24
wiki/concepts/Machine-Learning.md
Normal file
24
wiki/concepts/Machine-Learning.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Machine Learning"
|
||||
type: concept
|
||||
tags: [AI, data-science]
|
||||
sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
|
||||
last_updated: 2024-02-06
|
||||
---
|
||||
|
||||
## Summary
|
||||
机器学习是 AI 的子领域，使用数据创建决策逻辑或模型，通过从数据中学习来改进预测和决策。
|
||||
|
||||
## Definition
|
||||
Machine Learning (ML) 是人工智能的一个分支，通过算法从数据中学习，自动改进模型以进行预测或决策，无需明确编程。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：AI 子领域
|
||||
- **核心方法**：监督学习、无监督学习、强化学习
|
||||
- **应用**：分类、预测、生成、推荐
|
||||
|
||||
## Connections
|
||||
- [[AI]] ← is_parent_of ← [[Machine Learning]]
|
||||
- [[Machine Learning]] ← enables ← [[Generative AI]]
|
||||
- [[Amazon SageMaker]] ← hosts ← [[Machine Learning]]
|
||||
- [[Machine Learning]] ← implements ← [[RAG]]
|
||||
32
wiki/concepts/Prompt-Engineering.md
Normal file
32
wiki/concepts/Prompt-Engineering.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "Prompt Engineering"
|
||||
type: concept
|
||||
tags:
|
||||
- AI
|
||||
- Prompt-Engineering
|
||||
- LLM
|
||||
date: 2024-11-12
|
||||
---
|
||||
|
||||
## Summary
|
||||
提示词工程（Prompt Engineering）是创建、设计和优化提示词以引导大语言模型（LLM）响应的过程，确保输出的准确性和相关性。
|
||||
|
||||
## Definition
|
||||
Prompt Engineering（提示词工程）是指通过精心设计提示词来提升 AI 输出质量的技术，涵盖需求拆解、结构化表达、场景共情、迭代优化四个维度。
|
||||
|
||||
## Key Components
|
||||
提示词由以下组件构成：
|
||||
- **指令（Instructions）**：明确告诉模型要做什么
|
||||
- **上下文（Context）**：提供背景信息
|
||||
- **用户输入（User Input）**：具体问题或任务
|
||||
- **输出指示器（Output Indicator）**：提示模型输出格式
|
||||
|
||||
## Basic Techniques
|
||||
- **One-shot Prompting**：提供一个示例
|
||||
- **Few-shot Prompting**：提供多个示例
|
||||
- **Chain of Thoughts**：提供逐步思考过程
|
||||
|
||||
## Connections
|
||||
- [[LLM]] ← guides ← Prompt Engineering：提示词工程引导大语言模型
|
||||
- [[Generative AI]] ← uses ← Prompt Engineering：生成式 AI 应用提示词工程
|
||||
- [[Claude Skills]] ← relies_on ← Prompt Engineering：Claude Skills 基于提示词工程技术
|
||||
38
wiki/concepts/Pull-Model.md
Normal file
38
wiki/concepts/Pull-Model.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Pull Model"
|
||||
type: concept
|
||||
tags: [DevOps, GitOps, CD, 部署]
|
||||
sources: [ctp-topic-33-an-introduction-to-gitops.md]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Pull Model（拉取模型）是 GitOps 推荐的一种持续交付实现模式，GitOps Agent 持续监控 Git 仓库和目标系统的状态，自动将 Git 中的期望状态同步到实际运行环境。
|
||||
|
||||
## How It Works
|
||||
1. GitOps Agent 安装在目标环境（如 Kubernetes 集群）
|
||||
2. Agent 持续轮询 Git 仓库检测配置变化
|
||||
3. Agent 同时监控实际系统状态
|
||||
4. 当检测到差异时，自动将变更同步到目标系统
|
||||
|
||||
## Advantages
|
||||
- 更安全：无需开放外部访问权限到集群
|
||||
- 更好的可见性：Agent 直接观察实际状态
|
||||
- 自我修复：自动纠正配置漂移
|
||||
- 简化网络架构：无需入站 webhook
|
||||
|
||||
## Comparison with Push Model
|
||||
| 特性 | Pull Model | Push Model |
|
||||
|------|-----------|------------|
|
||||
| 触发方式 | Agent 主动拉取 | CI/CD 流水线推送 |
|
||||
| 部署位置 | Agent 运行在目标环境 | CI/CD 工具运行在外部 |
|
||||
| 安全性 | 更高，无需开放入站端口 | 需要开放 webhook 端口 |
|
||||
| 复杂度 | 较低（无外部依赖） | 较高（需要 CI/CD 集成） |
|
||||
|
||||
## Related Concepts
|
||||
- [[GitOps]]
|
||||
- [[CI/CD 流水线]]
|
||||
- [[Idempotent Operation]]（幂等操作）
|
||||
|
||||
## Related Sources
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
|
||||
38
wiki/concepts/Rate-Optimization.md
Normal file
38
wiki/concepts/Rate-Optimization.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "Rate Optimization"
|
||||
type: concept
|
||||
tags: [cloud, cost-management, AWS]
|
||||
sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Rate Optimization（费率优化）是通过承诺使用获取折扣的云成本优化策略。
|
||||
|
||||
## Definition
|
||||
费率优化基于承诺使用期限（1-3年）获取折扣，分为资源级承诺（更高折扣但有限制）和灵活承诺（标准折扣但更灵活）。
|
||||
|
||||
## AWS 费率优化工具
|
||||
- **Savings Plans**：EC2 Savings Plans、Compute Savings Plans
|
||||
- **Reserved Instances**：RDS、ElastiCache、CloudFront 等服务预留
|
||||
- **Spot Instances**：最高可达 90% 折扣，适用于容错工作负载
|
||||
|
||||
## 费率优化工作流
|
||||
1. **预工作（Right Sizing）**：先完成资源配置优化
|
||||
2. **分析**：识别需要 24/7 运行的工作负载
|
||||
3. **沟通**：与财务团队分享详情
|
||||
4. **审批**：获取账户所有者批准
|
||||
5. **报告**：监控利用率
|
||||
|
||||
## 关键约束
|
||||
- 仅 FinOps 团队可以实施承诺计划
|
||||
- 所有承诺计划仅支持无预付款选项
|
||||
- 最低交易价值：每年 5,000 美元
|
||||
|
||||
## Connections
|
||||
- [[FinOps]] ← enables ← [[Rate Optimization]]：FinOps 推动费率优化
|
||||
- [[Cost Optimization]] ← implements ← [[Rate Optimization]]：费率优化是成本优化的一部分
|
||||
- [[Workload Optimization]] ← combines_with ← [[Rate Optimization]]：与工作负载优化配合实现最大节省
|
||||
- [[Savings Plans]] ← is_type_of ← [[Rate Optimization]]
|
||||
- [[Reserved Instances]] ← is_type_of ← [[Rate Optimization]]
|
||||
- [[Spot Instances]] ← is_type_of ← [[Rate Optimization]]
|
||||
25
wiki/concepts/Renovate-Bot.md
Normal file
25
wiki/concepts/Renovate-Bot.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Renovate Bot"
|
||||
type: concept
|
||||
tags: [DevOps, CI/CD, Dependency-Update]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
开源依赖自动化更新工具，通过扫描代码并自动提交 Pull Request 来保持依赖项处于最新状态。适用于 Docker 镜像、Maven 依赖、Terraform 模块、Kubernetes Helm Charts 等多种依赖类型。
|
||||
|
||||
## Aliases
|
||||
- Renovate
|
||||
- Renovate Bot
|
||||
|
||||
## Key Features
|
||||
- Dependency Dashboard：在一个 GitHub Issue 中列出所有待更新的项，提供全局视角
|
||||
- Managers：支持多种技术栈的插件机制（terraform、dockerfile、maven 等）
|
||||
- Rate Limiting：限制每小时或同时开启的 PR 数量
|
||||
- 自动语义版本判断：基于 Semantic Versioning 规则判断更新级别
|
||||
|
||||
## Connections
|
||||
- [[Dependency Management]]：自动化管理目标
|
||||
- [[GitOps]]：依赖更新是 GitOps 流程的一部分
|
||||
- [[Terraform]]：可管理 Terraform 模块依赖
|
||||
- [[Terragrunt]]：可管理 Terragrunt 配置依赖
|
||||
23
wiki/concepts/Right-Sizing.md
Normal file
23
wiki/concepts/Right-Sizing.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Right Sizing"
|
||||
type: concept
|
||||
tags: [cloud, cost-management, AWS, EC2]
|
||||
sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Right Sizing（正确调整规格）是识别正确的资源规格以匹配工作负载性能和容量需求的过程。
|
||||
|
||||
## Definition
|
||||
通过分析实际 CPU、内存、网络使用数据，推荐合适的实例规格，避免资源浪费。
|
||||
|
||||
## Key Techniques
|
||||
- **EC2 Right Sizing Recommendation**：捕获 CPU、内存、网络数据提供推荐
|
||||
- **实例调度**：为非生产环境配置按业务时间开关机，可节省 60% 成本
|
||||
- **闲置资源清理**：识别和删除空闲负载均衡器、未关联弹性 IP、低利用率 EBS 卷
|
||||
|
||||
## Connections
|
||||
- [[Cost Optimization]] ← implements ← [[Right Sizing]]：Right Sizing 是成本优化的核心实践
|
||||
- [[Workload Optimization]] ← includes ← [[Right Sizing]]：Right Sizing 属于工作负载优化范畴
|
||||
- [[Spot Instances]] ← complements ← [[Right Sizing]]：Right Sizing 与 Spot 实例配合使用效果最佳
|
||||
36
wiki/concepts/S3-Intelligent-Tiering.md
Normal file
36
wiki/concepts/S3-Intelligent-Tiering.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "S3 Intelligent Tiering"
|
||||
type: concept
|
||||
tags: [AWS, S3, Storage, Cost-Optimization]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
S3 Intelligent Tiering（S3 智能分层）是 AWS S3 的一种存储类，可自动根据对象访问模式在不同的存储层之间移动数据，无需用户干预即可实现成本优化。
|
||||
|
||||
## Key Features
|
||||
- **自动监控**：自动监控访问模式，识别不频繁访问的数据
|
||||
- **无转换费用**：在不同存储层之间移动时无需支付转换费用
|
||||
- **两层监控**：30 天无访问移至 Infrequent Access，90 天移至 Archive 或 Deep Archive
|
||||
- **支持所有对象大小**：适合任何大小的对象
|
||||
- **无检索费用**：从任何层检索数据无需支付费用
|
||||
|
||||
## Pricing Model
|
||||
- 存储费用根据层级不同：
|
||||
- Frequent Access：标准 S3 费率
|
||||
- Infrequent Access：比标准层低约 40%
|
||||
- Archive Instant Access：比标准层低约 70%
|
||||
- Deep Archive：比标准层低约 95%
|
||||
- 监控费用：每 1,000 对象 $0.015/month
|
||||
|
||||
## Use Cases
|
||||
- 日志文件归档（访问后 30 天内不访问）
|
||||
- 数据湖中的冷数据
|
||||
- 合规性保留数据
|
||||
- 备份文件的长期存储
|
||||
|
||||
## Connections
|
||||
- [[Lifecycle-Policy]] → implements → [[S3-Intelligent-Tiering]]
|
||||
- [[S3-Standard]] ← compared_to ← [[S3-Intelligent-Tiering]]
|
||||
- [[Glacier]] ← compared_to ← [[S3-Intelligent-Tiering]]
|
||||
23
wiki/concepts/STLC.md
Normal file
23
wiki/concepts/STLC.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "STLC"
|
||||
type: concept
|
||||
tags: [Security, Development-Lifecycle, Micro-Focus]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
STLC（Security Development Life Cycle，安全开发生命周期）是 Micro Focus 产品开发的基础框架，包含 13 个安全与隐私轨道。Product Privacy Framework 是 STLC 中 13 个安全与隐私轨道之一。
|
||||
|
||||
## Components
|
||||
- 13 个安全与隐私轨道
|
||||
- Product Privacy Framework（产品隐私框架）是其中之一
|
||||
- SDL（Security Development Lifecycle）第五大支柱
|
||||
|
||||
## Related Concepts
|
||||
- [[Product Privacy Framework]]
|
||||
- [[Security Development Lifecycle]]
|
||||
- [[PII]]
|
||||
|
||||
## Related Entities
|
||||
- [[Micro Focus]]
|
||||
- [[Shlomi Ben-Hur]]
|
||||
51
wiki/concepts/Serverless-Application-Model.md
Normal file
51
wiki/concepts/Serverless-Application-Model.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Serverless Application Model"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- IaC
|
||||
- SAM
|
||||
date: 2024-09-03
|
||||
---
|
||||
|
||||
## Definition
|
||||
Serverless Application Model（无服务器应用模型，SAM）是 AWS 提供的开源框架，用于简化无服务器应用的本地开发和部署。基于 CloudFormation，扩展了声明无服务器资源的简化的语法。
|
||||
|
||||
## Key Features
|
||||
- SAM CLI：
|
||||
- `sam init`：初始化项目
|
||||
- `sam build`：本地构建
|
||||
- `sam local`：本地运行和调试
|
||||
- `sam deploy`：部署到 AWS
|
||||
- 模板简化：相比 CloudFormation 更简洁的语法
|
||||
- 本地测试：支持本地调用 Lambda 和 Step Functions
|
||||
|
||||
## SAM Template Structure
|
||||
```yaml
|
||||
AWSTemplateFormatVersion: '2010-09-09'
|
||||
Transform: AWS::Serverless-2016-08-09
|
||||
Resources:
|
||||
MyFunction:
|
||||
Type: AWS::Serverless::Function
|
||||
Properties:
|
||||
Handler: index.handler
|
||||
Runtime: nodejs18.x
|
||||
Events:
|
||||
Api:
|
||||
Type: Api
|
||||
Properties:
|
||||
Path: /hello
|
||||
Method: get
|
||||
```
|
||||
|
||||
## Common Use Cases
|
||||
- Lambda 函数部署
|
||||
- API Gateway 集成
|
||||
- Step Functions 工作流
|
||||
- 事件驱动架构
|
||||
|
||||
## Aliases
|
||||
- AWS SAM
|
||||
- SAM
|
||||
- Serverless Application Model
|
||||
45
wiki/concepts/Service-Catalog.md
Normal file
45
wiki/concepts/Service-Catalog.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: Service-Catalog
|
||||
title: "Service Catalog"
|
||||
type: concept
|
||||
tags:
|
||||
- DevOps
|
||||
- IaC
|
||||
- Terraform
|
||||
- Landing-Zone
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Service Catalog
|
||||
- 服务目录
|
||||
|
||||
## Summary
|
||||
- **定义**：封装业务需求的基础设施模块分组，提供服务级别抽象
|
||||
- **用途**：跨团队、跨账户复用基础设施配置，实现独立发布周期
|
||||
- **云迁移价值**：通过分层抽象实现基础设施即服务模式
|
||||
|
||||
## Key Details
|
||||
- **分层结构**：
|
||||
- Terraform Service Catalog：全局共享，供所有产品团队使用
|
||||
- Product Team Service Catalog：团队内部复用
|
||||
- Account-level Module：单账户使用
|
||||
- **Service vs Module**：
|
||||
- Service：业务需求封装，部署一组 Module
|
||||
- Module：技术需求实现，单一功能单元
|
||||
- 层级越高，配置选项越少（类似面向对象抽象）
|
||||
- **版本化管理**：
|
||||
- 使用语义化版本（major.minor.patch）
|
||||
- Terragrunt targeting 特定版本而非 master 分支
|
||||
- 避免意外变更引入生产环境
|
||||
|
||||
## Key Components
|
||||
- **main.tf**：定义模块引用和依赖关系
|
||||
- **terragrunt.hcl**：目标版本和输入变量配置
|
||||
- **outputs**：跨服务依赖值传递
|
||||
|
||||
## Connections
|
||||
- [[Terraform]] ← uses ← [[Service-Catalog]]
|
||||
- [[TerraGrunt]] ← references ← [[Service-Catalog]]
|
||||
- [[Module]] ← contained_by ← [[Service-Catalog]]
|
||||
- [[Landing-Zone]] ← managed_by ← [[Service-Catalog]]
|
||||
40
wiki/concepts/Step-Functions.md
Normal file
40
wiki/concepts/Step-Functions.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Step Functions"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- Orchestration
|
||||
- Workflow
|
||||
date: 2024-09-03
|
||||
---
|
||||
|
||||
## Definition
|
||||
Step Functions（步进函数）是 AWS 无服务器工作流服务，基于状态机编排多个 AWS 服务的业务流程。通过可视化工作流协调分布式应用程序和微服务的组件。
|
||||
|
||||
## Two Flavors
|
||||
- **Standard Workflows（标准工作流）**：
|
||||
- 长期运行（最多 1 年）
|
||||
- 精确一次执行
|
||||
- 每秒最多 2000 次执行
|
||||
|
||||
- **Express Workflows（快速工作流）**：
|
||||
- 短期运行（最多 5 分钟）
|
||||
- 至少一次执行
|
||||
- 每秒最多 100000 次执行
|
||||
- 面向事件驱动工作负载
|
||||
|
||||
## Key Concepts
|
||||
- **State Machine（状态机）**：定义工作流逻辑的结构
|
||||
- **States（状态）**：工作流中的步骤，包括 Pass、Task、Choice、Wait、Parallel、Map 等
|
||||
- **Transitions（转换）**：状态之间的流向控制
|
||||
|
||||
## Use Cases
|
||||
- 顺序处理：ETL 流程、数据处理
|
||||
- 并行处理：批量数据处理
|
||||
- 分支逻辑：条件分支处理
|
||||
- 人类审批：集成审批工作流
|
||||
|
||||
## Aliases
|
||||
- AWS Step Functions
|
||||
- Step Functions 状态机
|
||||
32
wiki/concepts/TerraTest.md
Normal file
32
wiki/concepts/TerraTest.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "TerraTest"
|
||||
type: concept
|
||||
tags:
|
||||
- Testing
|
||||
- IaC
|
||||
- Terraform
|
||||
date Added: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
TerraTest 是使用 Golang 编写的自动化基础设施测试库，自动化 Terraform apply-test-destroy 周期，简化基础设施测试流程。
|
||||
|
||||
## Definition
|
||||
Golang 编写的开源测试库，专门用于测试 Terraform 部署的基础设施。
|
||||
|
||||
## Key Features
|
||||
- 自动 apply：自动应用 Terraform 配置
|
||||
- 自动 test：自动执行测试验证输出
|
||||
- 自动 destroy：测试完成后自动清理资源
|
||||
|
||||
## Use Cases
|
||||
- 集成测试验证已部署基础设施的实际功能
|
||||
- 测试复杂 Terraform 模块
|
||||
- 测试驱动的基础设施开发（TDD）
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-56-automated-infrastructure-testing]]
|
||||
|
||||
## Aliases
|
||||
- TerraTest
|
||||
- Terratest
|
||||
47
wiki/concepts/Terraform.md
Normal file
47
wiki/concepts/Terraform.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
id: Terraform
|
||||
title: "Terraform"
|
||||
type: concept
|
||||
tags:
|
||||
- DevOps
|
||||
- IaC
|
||||
- AWS
|
||||
- Infrastructure
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Terraform
|
||||
- IaC (Infrastructure as Code)
|
||||
|
||||
## Summary
|
||||
- **定义**：基础设施即代码工具，通过声明式配置定义云资源
|
||||
- **用途**：跨云平台（AWS、Azure、GCP）管理基础设施
|
||||
- **云迁移价值**：实现基础设施版本控制、可重复部署和环境一致性
|
||||
|
||||
## Key Details
|
||||
- **核心概念**：
|
||||
- Provider：云平台连接器（aws、azurerm 等）
|
||||
- Resource：基础设施资源定义
|
||||
- Data Source：只读数据查询
|
||||
- Variable：输入变量
|
||||
- Output：输出值
|
||||
- Module：可复用配置单元
|
||||
- **工作流程**：
|
||||
- init：初始化 provider 和 backend
|
||||
- plan：预览变更
|
||||
- apply：执行变更
|
||||
- destroy：销毁资源
|
||||
- **状态管理**：
|
||||
- 本地状态或远程状态（S3、DynamoDB）
|
||||
- 状态锁防止并发冲突
|
||||
|
||||
## Terraform vs Terragrunt
|
||||
- **Terraform**：底层 IaC 工具
|
||||
- **Terragrunt**：Terraform 包装器，提供模块变量共享、多环境管理、远程状态配置
|
||||
|
||||
## Connections
|
||||
- [[TerraGrunt]] ← wraps ← [[Terraform]]
|
||||
- [[Service-Catalog]] ← uses ← [[Terraform]]
|
||||
- [[AWS]] ← managed_by ← [[Terraform]]
|
||||
- [[Module]] ← implemented_by ← [[Terraform]]
|
||||
33
wiki/concepts/Test-Driven-Development.md
Normal file
33
wiki/concepts/Test-Driven-Development.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Test-Driven Development"
|
||||
type: concept
|
||||
tags:
|
||||
- Testing
|
||||
- Development
|
||||
- TDD
|
||||
date Added: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
测试驱动开发（Test-Driven Development，TDD）是一种软件开发方法论，先写测试再实现功能，确保聚焦开发目标并构建全面的测试套件。
|
||||
|
||||
## Definition
|
||||
测试驱动开发是一种迭代开发方法论，通过先编写测试来定义期望行为，然后编写最小代码通过测试，最后重构改进。
|
||||
|
||||
## Workflow
|
||||
1. 编写测试（Red）：定义期望行为
|
||||
2. 实现代码（Green）：编写最小代码通过测试
|
||||
3. 重构（Refactor）：优化代码结构
|
||||
|
||||
## Benefits
|
||||
- 确保功能可测试
|
||||
- 构建全面测试套件
|
||||
- 聚焦开发目标
|
||||
- 提高代码质量
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-56-automated-infrastructure-testing]]
|
||||
|
||||
## Aliases
|
||||
- TDD
|
||||
- Test-Driven Development
|
||||
30
wiki/concepts/Workload-Optimization.md
Normal file
30
wiki/concepts/Workload-Optimization.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Workload Optimization"
|
||||
type: concept
|
||||
tags: [cloud, cost-management, AWS]
|
||||
sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Workload Optimization（工作负载优化）是通过现代化和 Right Sizing 优化资源配置以降低云成本的实践。
|
||||
|
||||
## Definition
|
||||
工作负载优化涵盖两个主要方向：现代化（使用新一代服务）和 Right Sizing（调整资源规格匹配实际需求）。
|
||||
|
||||
## Key Techniques
|
||||
- **现代化（Modernization）**：使用新一代服务实例
|
||||
- Intel 迁移到 AMD：节省 6-10% 按需价格
|
||||
- 迁移到 Graviton：节省 20-25% 按需价格
|
||||
- GP2 升级到 GP3：直接节省 20% 存储成本
|
||||
- EKS 集群升级到最新版本：避免高额扩展支持费用
|
||||
|
||||
- **Right Sizing**：根据实际需求调整资源配置
|
||||
- EC2 Right Sizing 推荐报告
|
||||
- 实例调度（非生产环境按需开关）
|
||||
- 闲置资源清理
|
||||
|
||||
## Connections
|
||||
- [[FinOps]] ← enables ← [[Workload Optimization]]：FinOps 推动工作负载优化
|
||||
- [[Cost Optimization]] ← implements ← [[Workload Optimization]]：工作负载优化是成本优化的一部分
|
||||
- [[Rate Optimization]] ← combines_with ← [[Workload Optimization]]：与费率优化配合实现最大节省
|
||||
35
wiki/entities/AWS-Instance-Scheduler.md
Normal file
35
wiki/entities/AWS-Instance-Scheduler.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "AWS Instance Scheduler"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Product
|
||||
- Cost-Optimization
|
||||
- FinOps
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AWS Instance Scheduler for AWS EC2
|
||||
- AWS Instance Scheduler for RDS
|
||||
|
||||
## Definition
|
||||
AWS 官方提供的自动实例调度工具，通过定时启停 EC2 和 RDS 实例来降低非生产环境成本。
|
||||
|
||||
## Details
|
||||
- **类型**：AWS 官方解决方案
|
||||
- **部署方式**：CloudFormation
|
||||
- **支持服务**：EC2、RDS
|
||||
- **触发机制**：CloudWatch Events（默认 15 分钟）
|
||||
- **配置存储**：DynamoDB
|
||||
|
||||
## Relationships
|
||||
- 由 CCOE 集成在 Guardrails 部署方案中
|
||||
- 通过标签（Schedule、Period）关联实例
|
||||
|
||||
## Related Concepts
|
||||
- [[Instance Scheduling]]
|
||||
- [[CloudWatch Events]]
|
||||
- [[DynamoDB Config Table]]
|
||||
|
||||
## References
|
||||
@@ -22,3 +22,7 @@ AWS（Amazon Web Services）是亚马逊提供的全球最大公有云平台，
|
||||
- [[Kubernetes]] ← 支持（EKS）← [[AWS]]
|
||||
- [[Terraform]] ← 支持 ← [[AWS]]
|
||||
- [[Agentic AI]] ← 监控/分析 ← [[CloudWatch]]
|
||||
- [[Amazon Bedrock]] ← 提供服务 ← [[AWS]]
|
||||
- [[Amazon SageMaker]] ← 提供服务 ← [[AWS]]
|
||||
- [[AI]] ← 应用场景 ← [[AWS]]
|
||||
- [[Machine Learning]] ← 应用场景 ← [[AWS]]
|
||||
|
||||
34
wiki/entities/Amazon-Kinesis.md
Normal file
34
wiki/entities/Amazon-Kinesis.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Amazon Kinesis"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Data Stream
|
||||
- Real-time
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Amazon Kinesis 是 AWS 实时数据流处理服务，用于收集、处理和分析大量数据流。Kinesis Data Streams 可以实时处理 TB 级别的数据，适用于实时分析、日志和事件数据流等场景。
|
||||
|
||||
## Core Services
|
||||
- **Kinesis Data Streams**：实时数据流处理
|
||||
- **Kinesis Data Firehose**：将数据加载到目标存储（S3、Redshift、Elasticsearch）
|
||||
- **Kinesis Data Analytics**：实时流数据分析（ SQL 查询）
|
||||
- **Kinesis Video Streams**：视频流处理
|
||||
|
||||
## Key Features
|
||||
- **实时处理**：毫秒级数据处理延迟
|
||||
- **顺序保证**：保证数据顺序
|
||||
- **持久存储**：默认保留 24 小时，可扩展至 7 天
|
||||
- **并行消费**：多个消费者可以并行读取不同分片
|
||||
|
||||
## Use Cases
|
||||
- 日志和事件数据实时摄取
|
||||
- 实时分析仪表盘
|
||||
- 移动设备数据捕获
|
||||
- IoT 设备数据流处理
|
||||
|
||||
## Aliases
|
||||
- AWS Kinesis
|
||||
- Kinesis Data Streams
|
||||
32
wiki/entities/Amazon-Q.md
Normal file
32
wiki/entities/Amazon-Q.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "Amazon Q"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- AI-Assistant
|
||||
- Generative-AI
|
||||
date: 2024-11-12
|
||||
---
|
||||
|
||||
## Profile
|
||||
- **Name**: Amazon Q
|
||||
- **Type**: AI 助手（AI-powered Assistant）
|
||||
- **Provider**: Amazon Web Services (AWS)
|
||||
- **Category**: 生成式 AI 应用
|
||||
|
||||
## Description
|
||||
Amazon Q 是 AWS 提供的 AI 助手，主要有两种版本：
|
||||
|
||||
### Amazon Q for Business
|
||||
- 连接多个数据源
|
||||
- 支持搜索、摘要和洞察提取
|
||||
- 维持现有权限控制
|
||||
|
||||
### Amazon Q Developer
|
||||
- 专注于代码生成
|
||||
- 单元测试生成
|
||||
- 代码迁移
|
||||
|
||||
## Connections
|
||||
- [[Amazon]] ← provides ← [[Amazon Q]]
|
||||
- [[Generative AI]] ← powers ← [[Amazon Q]]
|
||||
24
wiki/entities/Amazon-SNS.md
Normal file
24
wiki/entities/Amazon-SNS.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Amazon SNS"
|
||||
type: entity
|
||||
tags: [AWS, Event-Driven, Serverless, Pub/Sub]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Amazon SNS 是 AWS 的发布/订阅消息通知服务，支持一对多消息广播。
|
||||
|
||||
## Definition
|
||||
Amazon Simple Notification Service（SNS）是 AWS 提供的完全托管式发布/订阅消息通知服务，支持一对多消息推送。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：消息通知服务
|
||||
- **开发商**：AWS
|
||||
- **核心功能**：发布/订阅、主题订阅、消息推送、移动推送、邮件
|
||||
- **定价**：按请求和消息大小计费
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← 提供 ← [[Amazon SNS]]
|
||||
- [[Lambda]] ← 触发 ← [[Amazon SNS]]
|
||||
- [[Amazon SQS]] ← 集成 ← [[Amazon SNS]]
|
||||
24
wiki/entities/Amazon-SQS.md
Normal file
24
wiki/entities/Amazon-SQS.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Amazon SQS"
|
||||
type: entity
|
||||
tags: [AWS, Event-Driven, Serverless, Queue]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Amazon SQS 是 AWS 的消息队列服务，提供点对点异步通信机制，实现服务间松耦合。
|
||||
|
||||
## Definition
|
||||
Amazon Simple Queue Service（SQS）是 AWS 提供的完全托管式消息队列服务，支持分布式系统异步通信和服务解耦。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：消息队列服务
|
||||
- **开发商**：AWS
|
||||
- **核心功能**：消息排队、点对点通信、消息持久化
|
||||
- **定价**：按请求数量计费
|
||||
- **队列类型**：标准队列（高吞吐）、FIFO 队列（先进先出）
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← 提供 ← [[Amazon SQS]]
|
||||
- [[Lambda]] ← 触发 ← [[Amazon SQS]]
|
||||
29
wiki/entities/Atlantis.md
Normal file
29
wiki/entities/Atlantis.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "Atlantis"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Atlantis
|
||||
|
||||
## Definition
|
||||
Atlantis 是一个开源、自托管的 Terraform CI/CD 自动化工具，旨在替代 Jenkins 进行基础设施部署。
|
||||
|
||||
## Core Features
|
||||
- 通过 GitHub Pull Request 评论触发 plan/apply 工作流
|
||||
- 部署在单个 EC2 实例上（每个 Landing Zone 共享账户一台）
|
||||
- 使用服务账号与 GitHub 交互（发布评论、执行合并、关闭 PR）
|
||||
- 目录锁定机制防止并行冲突
|
||||
- 支持并行构建，多模块同时执行 plan 和 apply
|
||||
- 合并前应用（pre-merge apply）确保代码与基础设施同步
|
||||
|
||||
## Use Cases
|
||||
- 替代 Jenkins 进行 Terraform 自动化部署
|
||||
- 多账户基础设施变更管理
|
||||
- GitOps 工作流实现
|
||||
|
||||
## Connections
|
||||
- [[Jenkins]] — 被替代的 CI/CD 工具
|
||||
- [[Terraform]] — 主要管理的 IaC 工具
|
||||
- [[GitHub Enterprise]] — 集成的代码托管平台
|
||||
22
wiki/entities/Dr-Anil-Giri.md
Normal file
22
wiki/entities/Dr-Anil-Giri.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Dr. Anil Giri"
|
||||
type: entity
|
||||
tags: [AWS, Solutions Architect, Speaker]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
AWS 解决方案架构师，主讲 Public Cloud Learning Sessions 事件驱动架构系列会议。
|
||||
|
||||
## Definition
|
||||
Dr. Anil Giri 是 AWS 的解决方案架构师，专注于云计算、企业集成模式和事件驱动架构领域。
|
||||
|
||||
## Role
|
||||
- **职位**：Solutions Architect
|
||||
- **雇主**：AWS
|
||||
- **专长**：Event-Driven Architecture、Enterprise Integration Patterns、AWS EventBridge
|
||||
|
||||
## Connections
|
||||
- [[Dr. Anil Giri]] → 受雇于 → [[AWS]]
|
||||
- [[EventBridge]] → 解决方案提供 → [[Dr. Anil Giri]]
|
||||
18
wiki/entities/FPNA-Team.md
Normal file
18
wiki/entities/FPNA-Team.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "FPNA Team"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- N/A
|
||||
|
||||
## Role
|
||||
- 负责预算可用性验证的团队
|
||||
|
||||
## Context
|
||||
FPNA 团队是 Oli 工作流三阶段审批流程的最后一个阶段，负责验证预算是否可用。在 FinOps 完成可行性验证、技术可行性验证后，FPNA 团队进行预算可用性验证。
|
||||
|
||||
## Related
|
||||
- [[Public Cloud Learning Sessions - Ollie Workflow and The Demand Process]]
|
||||
- [[Demand Management]]
|
||||
25
wiki/entities/FinOps-Team.md
Normal file
25
wiki/entities/FinOps-Team.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "FinOps Team"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- N/A
|
||||
|
||||
## Role
|
||||
- 负责 Oli 工作流管理的团队，正在将工作流过渡到其管理之下
|
||||
- 负责云成本优化策略制定与实施
|
||||
|
||||
## Context
|
||||
FinOps 团队由 Tom Bice 领导，正在将 Oli 工作流流程整合到 SMACs 系统中。该团队负责云资源请求的可行性验证，是 Oli 工作流三阶段审批流程的第一阶段。
|
||||
|
||||
2025年3月，团队成员 Vinay 在 Public Cloud Learning Sessions 上分享了云成本优化策略，涵盖工作负载优化和费率优化。
|
||||
|
||||
## Related
|
||||
- [[Public Cloud Learning Sessions - Ollie Workflow and The Demand Process]]
|
||||
- [[Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318]]
|
||||
- [[Tom Bice]]
|
||||
- [[Demand Management]]
|
||||
42
wiki/entities/Graviton.md
Normal file
42
wiki/entities/Graviton.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "AWS Graviton"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Processor
|
||||
- ARM
|
||||
- Cost-Optimization
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
AWS Graviton 是亚马逊网络服务（AWS）基于 ARM64 架构开发的处理器系列，旨在提供更高的性价比和更低的功耗。
|
||||
|
||||
## Key Characteristics
|
||||
- 基于 ARM64 架构
|
||||
- 相比同类 x86 实例提供最高 40% 性价比优势
|
||||
- 相比同类 x86 实例减少最多 60% 功耗
|
||||
- 支持多种实例类型：计算优化型、内存优化型、通用型
|
||||
- AWS 已推出第四代 Graviton 处理器
|
||||
|
||||
## Supported Services
|
||||
- EC2 实例（R 系列、C 系列、M 系列等）
|
||||
- RDS（Aurora、PostgreSQL、MySQL 等）
|
||||
- Lambda
|
||||
- ElastiCache
|
||||
- DocumentDB
|
||||
|
||||
## Migration Considerations
|
||||
- 迁移到 RDS Aurora 等服务相对简单
|
||||
- 不适合有状态服务（如数据库）的场景需谨慎评估
|
||||
|
||||
## Aliases
|
||||
- AWS Graviton
|
||||
- Graviton Processor
|
||||
- ARM64 Processor
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← developed_by ← [[Graviton]]
|
||||
- [[EC2-Instance-Types]] ← includes ← [[Graviton]]
|
||||
- [[Cost-Optimization]] ← enables ← [[Graviton]]
|
||||
18
wiki/entities/MUI.md
Normal file
18
wiki/entities/MUI.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "MUI"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- N/A
|
||||
|
||||
## Role
|
||||
- 审批决策者之一，负责超大规模云服务商支出的书面审批
|
||||
|
||||
## Context
|
||||
在 Oli 工作流流程中，MUI 与 Shannon 共同拥有对任何超大规模云服务商支出的最终审批权，无论金额大小。这一审批要求适用于工程实验室空间或商业工作负载空间的资源请求。
|
||||
|
||||
## Related
|
||||
- [[Public Cloud Learning Sessions - Ollie Workflow and The Demand Process]]
|
||||
- [[Shannon]]
|
||||
21
wiki/entities/Mark-Francis.md
Normal file
21
wiki/entities/Mark-Francis.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Mark Francis"
|
||||
type: entity
|
||||
tags:
|
||||
- Cloud
|
||||
- DevOps
|
||||
- CTP
|
||||
date Added: 2026-04-19
|
||||
---
|
||||
|
||||
## Summary
|
||||
Mark Francis 是 OpenText CTP（Cloud Transformation Program）的演讲者，主讲自动化基础设施测试相关主题。
|
||||
|
||||
## Role
|
||||
- CTP Topic 56 演讲者：自动化基础设施测试
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-56-automated-infrastructure-testing]]
|
||||
|
||||
## Aliases
|
||||
- Mark Francis
|
||||
@@ -17,6 +17,7 @@ Micro Focus 是一家企业软件公司，提供 SRE（站点可靠性工程）
|
||||
- [[CTP Topic 41 NFR's and Error Budgets]] — SRE 负责人 Brendan Standing 担任演讲者
|
||||
- [[CTP Topic 53 Why bother with Cloud]] — 云转型计划进展，成本优化与创新价值分析
|
||||
- [[CTP Topic 21 Supply Chain Security in Micro Focus]] — 产品安全小组 Shlomi Ben-Hur 主讲供应链安全
|
||||
- [[CTP Topic 24 Micro Focus Product Privacy Framework]] — 产品安全小组 Shlomi Ben-Hur 主讲产品隐私框架
|
||||
- [[Brendan Standing]] — Micro Focus SRE 负责人
|
||||
|
||||
## References
|
||||
|
||||
24
wiki/entities/Mike-Dukes.md
Normal file
24
wiki/entities/Mike-Dukes.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Mike Dukes"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Expert
|
||||
- Speaker
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Mike Dukes 是 AWS 专家，在 Public Cloud Learning Sessions 系列会议中担任演讲者，专注于云成本优化和 EC2 最佳实践主题。
|
||||
|
||||
## Role
|
||||
- AWS 解决方案架构师或技术专家
|
||||
- Public Cloud Learning Sessions 演讲者
|
||||
|
||||
## Sessions
|
||||
- [Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS](sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md)
|
||||
|
||||
## Connections
|
||||
- [[Public-Cloud-Learning-Sessions]] ← presented_by ← [[Mike-Dukes]]
|
||||
- [[AWS]] ← employs ← [[Mike-Dukes]]
|
||||
@@ -5,6 +5,7 @@ tags:
|
||||
- CTP
|
||||
- Platform
|
||||
- Support
|
||||
- FinOps
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
@@ -13,13 +14,20 @@ date: 2026-04-19
|
||||
- 角色：云转型计划核心技术团队
|
||||
- 职责：提供云环境支持、安全策略制定、协助产品组进行 POC
|
||||
|
||||
## 核心服务
|
||||
- **成本管理**：账单支付、showback/chargeback、预算管理
|
||||
- **成本优化**：组织级和账户级优化，包括购买 Reserved Instances 和识别未充分利用的资源
|
||||
- **治理与自动化**：集中式上线、策略开发、自动报告
|
||||
|
||||
## Aliases
|
||||
- Platform Control Group
|
||||
- PCG
|
||||
- Public Cloud Governance
|
||||
|
||||
## Connections
|
||||
- [[Gruntwork-Landing-Zone]] — 提供环境支持
|
||||
- [[CTP-Topic-20-Program-demand-process-flow-and-PoC-onboarding]]
|
||||
- [[Cloud-Health]] — 使用 Cloud Health 工具进行成本监控
|
||||
|
||||
---
|
||||
|
||||
|
||||
15
wiki/entities/Paul-Hopkins.md
Normal file
15
wiki/entities/Paul-Hopkins.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Paul Hopkins"
|
||||
type: entity
|
||||
tags: [person, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Summary
|
||||
OpenText/ Micro Focus 技术专家，CTP（Cloud Transformation Program）主题演讲者，主讲 Renovate Bot 自动化依赖管理。
|
||||
|
||||
## Aliases
|
||||
- Paul Hopkins
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 15 Working with Renovatebot]]：主讲人
|
||||
36
wiki/entities/Product-Team.md
Normal file
36
wiki/entities/Product-Team.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: Product-Team
|
||||
title: "Product Team"
|
||||
type: entity
|
||||
entity_type: team
|
||||
tags:
|
||||
- DevOps
|
||||
- Landing-Zone
|
||||
- Cloud-Transformation
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Product Team
|
||||
- 产品团队
|
||||
|
||||
## Summary
|
||||
- **定义**：在 CTP 云转型计划中，负责特定产品或服务基础设施部署的团队
|
||||
- **角色**：拥有独立的 Landing Zone 和 Workload 账户，部署满足业务需求的基础设施
|
||||
- **云迁移价值**：通过团队级隔离实现职责分离和资源配置
|
||||
|
||||
## Key Details
|
||||
- **账户结构**：
|
||||
- Landing Zone Account：基础设施账户
|
||||
- Workload Account：工作负载账户
|
||||
- **典型团队**：
|
||||
- DevTools：部署 Artifactory、Active Directory 等
|
||||
- **Git 仓库**：
|
||||
- Core Landing Zone Repository：核心配置
|
||||
- Terraform Service Catalog：全局模块
|
||||
- Product Team Service Catalog：团队级模块
|
||||
|
||||
## Connections
|
||||
- [[Landing-Zone]] ← uses ← [[Product-Team]]
|
||||
- [[Service-Catalog]] ← provides ← [[Product-Team]]
|
||||
- [[Gruntwork]] ← reference ← [[Product-Team]]
|
||||
23
wiki/entities/Public-Cloud-Learning-Sessions.md
Normal file
23
wiki/entities/Public-Cloud-Learning-Sessions.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions"
|
||||
type: entity
|
||||
tags: [学习, 培训, DevOps, 云转型]
|
||||
sources: [ctp-topic-2-git.md]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Public Cloud Learning Sessions（公有云学习会议）是 OpenText 内部的技术学习会议系列，覆盖云转型、DevOps、SRE、AWS/Azure/GCP 等主题。每期会议由内部专家或外部嘉宾主讲，记录视频并整理为知识沉淀。
|
||||
|
||||
## Related Entities
|
||||
- [[OpenText]]：主办方
|
||||
- [[CTP]]：云转型计划，学习会议的主要推动者
|
||||
|
||||
## Related Concepts
|
||||
- [[DevOps 文化]]
|
||||
- [[CI/CD 流水线]]
|
||||
- [[GitOps]]
|
||||
|
||||
## Aliases
|
||||
- Learning Sessions
|
||||
- PCLS
|
||||
21
wiki/entities/SRE-Core-Team.md
Normal file
21
wiki/entities/SRE-Core-Team.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "SRE Core Team"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: [Public-Cloud-Learning-Sessions-Budget-Control]
|
||||
last_updated: 2024-03-19
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- N/A
|
||||
|
||||
## Role
|
||||
- 负责开发和维护预算控制自动化的 SRE 团队
|
||||
|
||||
## Context
|
||||
SRE Core Team（Daniela、Evan、Alan）在 2024 年 3 月 19 日的 Public Cloud Learning Sessions 上展示了预算控制自动化。该自动化提供账户所有者详细的支出警报和成本分析报告，实现 AWS 账户成本控制。
|
||||
|
||||
## Related
|
||||
- [[Public Cloud Learning Sessions - Budget Control - 20240319]]
|
||||
- [[FinOps Team]]
|
||||
- [[Budget Control]]
|
||||
18
wiki/entities/Shannon.md
Normal file
18
wiki/entities/Shannon.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "Shannon"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- N/A
|
||||
|
||||
## Role
|
||||
- 审批决策者之一，负责超大规模云服务商支出的书面审批
|
||||
|
||||
## Context
|
||||
在 Oli 工作流流程中，Shannon 与 MUI 共同拥有对任何超大规模云服务商支出的最终审批权，无论金额大小。这一审批要求适用于工程实验室空间或商业工作负载空间的资源请求。
|
||||
|
||||
## Related
|
||||
- [[Public Cloud Learning Sessions - Ollie Workflow and The Demand Process]]
|
||||
- [[MUI]]
|
||||
28
wiki/entities/Shikad-Holtzman.md
Normal file
28
wiki/entities/Shikad-Holtzman.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Shikad Holtzman"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Technical-Account-Manager
|
||||
- Public-Cloud-Learning-Sessions
|
||||
date: 2024-11-12
|
||||
---
|
||||
|
||||
## Profile
|
||||
- **Role**: Technical Account Manager（技术客户经理）
|
||||
- **Employer**: Amazon Web Services (AWS)
|
||||
- **Location**: 以色列（Israel）
|
||||
- **Expertise**: 生成式 AI、AWS 服务、企业创新
|
||||
|
||||
## Contributions
|
||||
在 2024 年 11 月 12 日的 Public Cloud Learning Sessions 中，Shikad Holtzman 分享了 AWS 生成式 AI 与提示词工程的主题，介绍了：
|
||||
- 生成式 AI 的常见用例
|
||||
- AWS 生成式 AI 服务（Amazon Q、Amazon Bedrock、Amazon SageMaker）
|
||||
- 提示词工程基础与技巧
|
||||
|
||||
## Aliases
|
||||
- Shikad
|
||||
|
||||
## Connections
|
||||
- [[Public Cloud Learning Sessions]] ← speaker ← [[Shikad Holtzman]]
|
||||
- [[Amazon]] ← employs ← [[Shikad Holtzman]]
|
||||
@@ -9,12 +9,14 @@ tags:
|
||||
---
|
||||
|
||||
## Definition
|
||||
Micro Focus 产品安全小组（Product Security Team）成员，主讲供应链安全相关议题。
|
||||
Micro Focus 产品安全小组（PSAC）成员，主讲供应链安全和产品隐私框架相关议题。
|
||||
|
||||
## Role
|
||||
- 产品安全专家（Product Security Expert）
|
||||
- 在 CTP Topic 21 中主讲软件供应链安全的新方法
|
||||
- 在 CTP Topic 24 中主讲产品隐私框架
|
||||
|
||||
## Related
|
||||
- [[Supply Chain Security]]
|
||||
- [[Product Privacy Framework]]
|
||||
- [[Micro Focus]]
|
||||
24
wiki/entities/Steele-Taylor.md
Normal file
24
wiki/entities/Steele-Taylor.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Steele Taylor"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Expert
|
||||
- Speaker
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
Steele Taylor 是 AWS 专家，在 Public Cloud Learning Sessions 系列会议中担任演讲者，专注于云成本优化和 EC2 最佳实践主题。
|
||||
|
||||
## Role
|
||||
- AWS 解决方案架构师或技术专家
|
||||
- Public Cloud Learning Sessions 演讲者
|
||||
|
||||
## Sessions
|
||||
- [Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS](sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md)
|
||||
|
||||
## Connections
|
||||
- [[Public-Cloud-Learning-Sessions]] ← presented_by ← [[Steele-Taylor]]
|
||||
- [[AWS]] ← employs ← [[Steele-Taylor]]
|
||||
22
wiki/entities/Stephen-Frank.md
Normal file
22
wiki/entities/Stephen-Frank.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Stephen Frank"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- AI
|
||||
- Speaker
|
||||
---
|
||||
|
||||
## Profile
|
||||
- Role: AWS AI 专家（AI Specialist）
|
||||
- Company: [[AWS]]
|
||||
- Expertise: AI 创新、数据利用、AI 应用案例加速
|
||||
|
||||
## Aliases
|
||||
- Stephen Frank
|
||||
|
||||
## Related Sources
|
||||
- [[Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126]]
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← works_for ← [[Stephen-Frank]]
|
||||
23
wiki/entities/Suraav-Paul.md
Normal file
23
wiki/entities/Suraav-Paul.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Suraav Paul"
|
||||
type: entity
|
||||
tags: [person, AWS, speaker]
|
||||
sources: [public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206]
|
||||
last_updated: 2024-02-06
|
||||
---
|
||||
|
||||
## Summary
|
||||
Suraav Paul 是 AWS 高级解决方案架构师，专注于 AI/ML 领域。
|
||||
|
||||
## Definition
|
||||
AWS 高级解决方案架构师 (Senior Solutions Architect)，在 Public Cloud Learning Sessions 中主讲 AI/ML 相关主题。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**：个人
|
||||
- **职位**：高级解决方案架构师
|
||||
- **雇主**：AWS
|
||||
- **专长**：AI/ML、生成式 AI
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← 雇主 ← [[Suraav Paul]]
|
||||
- [[Amazon Bedrock]] ← 讲解 ← [[Suraav Paul]]
|
||||
24
wiki/entities/Victor-Etkin.md
Normal file
24
wiki/entities/Victor-Etkin.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Victor Etkin"
|
||||
type: entity
|
||||
tags: [DevOps, GitOps, CTP]
|
||||
sources: [ctp-topic-33-an-introduction-to-gitops.md]
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Role
|
||||
- DevOps 领域的演讲者和布道者
|
||||
|
||||
## Contributions
|
||||
- 在 CTP Topic 33 中介绍 GitOps 概念，阐述其如何补充和演进 DevOps
|
||||
|
||||
## Aliases
|
||||
- 无
|
||||
|
||||
## Related Concepts
|
||||
- [[GitOps]]
|
||||
- [[DevOps]]
|
||||
- [[CI/CD]]
|
||||
|
||||
## Related Sources
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] — GitOps 入门介绍
|
||||
@@ -28,12 +28,22 @@
|
||||
- [Obsidian CLI 命令全景速查表](sources/Obsidian-官方-CLI-命令-全景-速查表.md) — Obsidian 官方 CLI 命令速查与自动化工作流（版本要求 v1.12+）
|
||||
|
||||
## Sources
|
||||
- [Cloud Learning Master Index](sources/cloud-learning-master-index.md) — Public Cloud Learning Sessions 课程分类索引与统计信息（10 个类别，121 个视频）
|
||||
|
||||
- [Public Cloud Learning Sessions - EKS Optimization part 1 of 3 - Compute Optimization with Karpenter](sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md) — EKS 计算优化，使用 Karpenter 实现自动扩缩容
|
||||
- [Public Cloud Learning Sessions - EKS Optimization part 2 of 3 - Running Containers with Bottlerocket OS](sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md) — Bottlerocket OS 优化容器运行
|
||||
- [Public Cloud Learning Sessions - EKS Optimization part 3 of 3 - Introduction to EKS Auto Mode](sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-auto-mode.md) — EKS Auto Mode 介绍，自动管理数据平面实例、操作系统、补丁和安全更新
|
||||
|
||||
- [Public Cloud Learning Sessions - Introduction to AI/ML with AWS](sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206.md) — AWS AI/ML 介绍与实践，Suraav Paul 讲解生成式 AI、 Amazon Bedrock 和 ML Ops
|
||||
|
||||
- [Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318](sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md) — 云成本优化策略，涵盖工作负载优化（现代化+Right Sizing）和费率优化（Savings Plans、预留实例）
|
||||
|
||||
- [Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS](sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md) — EC2 成本优化最佳实践，涵盖 Graviton 迁移、Spot 实例利用和购买选项
|
||||
|
||||
- [Public Cloud Learning Sessions - Observability with OpenTelemetry](sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113-.md) — OpenTelemetry 可观测性框架在 AWS 环境中的应用（Metrics、Logs、Traces 三大信号）
|
||||
|
||||
- [Public Cloud Learning Sessions - Ollie Workflow and The Demand Process](sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416.md) — Oli 工作流流程，用于超大规模云服务商的支出审批、需求管理和请求处理
|
||||
|
||||
- [我做了个 Skill：让 AI 帮你生成 Logo 和图标](sources/我做了个-Skill-让-AI-帮你生成-Logo-和图标.md) — AI 生成 Logo 的 Skill 工作流，三步生成专业设计资产
|
||||
|
||||
- [AI Memory Tools：两大阵营的深度解析](sources/AI-Memory-Tools-Two-Camps.md) — AI Agent 记忆工具的两大技术路线：记忆后端（Memory Backend）vs 上下文基质（Context Substrate）
|
||||
@@ -66,6 +76,11 @@
|
||||
|
||||
- [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) — AWS AMI 路线图与 CCOE 标准化 AMI 发布计划
|
||||
|
||||
- [CTP Topic 63 Optimise resource cost using automation](sources/ctp-topic-63-optimise-resource-cost-using-automation.md) — 通过自动化技术降低云资源成本，涵盖批准区域、实例类型优化、承诺计划、存储优化和自动化调度
|
||||
- [CTP Topic 71 PCG's Guide to RightSizing, Why, How, When](sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md) — AWS 资源优化（Right Sizing）的全面指南，涵盖 Why、How、When 三大维度
|
||||
|
||||
- [CTP Topic 48 Terraform vs Terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md) — Terraform 与 Terragrunt 对比，Terraform 是云无关 IaC 工具，Terragrunt 是 DRY 包装器
|
||||
|
||||
- [养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战](sources/养虾日记1-我用-OpenClaw-管了-28-万张照片-一次真实的多设备照片整理实战.md) — 利用 AI Agent 自动化整理 28 万张照片（MD5 去重 + 批次任务 + Cron 定时执行）
|
||||
|
||||
- [教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報](sources/jiao-xue-chatgpt-xian-zuo-zhi-shi-zheng-li-zai-rang-canva-gamma-ai-shu-chu-jian-bao.md) — AI 简报制作四阶段工作流（ChatGPT 资料研究 + Canva/Gamma 设计）
|
||||
@@ -132,6 +147,7 @@
|
||||
- [RTO vs RPO: Key Differences for Modern Disaster Recovery](sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md) — RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及 Feature Flag 在现代持续交付中的应用
|
||||
- [These 6 Linux apps let you monitor system resources in style](sources/These-6-Linux-apps-let-you-monitor-system-resources-in-style.md) — 6 款 Linux 系统资源监控工具评测（TUI：btop++、htop、glances、bottom；GUI：Mission Center、Stacer）
|
||||
- [Public vs Private vs Hybrid: Cloud Differences Explained](sources/Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained.md) — 公有云、私有云和混合云的核心区别与选择指南
|
||||
- [Understanding Complete ITSM](sources/understanding-complete-itsm.md) — 现代 IT 服务管理的全面演进
|
||||
- [How Agentic AI can help for Cloud DevOps](sources/How-Agentic-AI-can-help-for-Cloud-DevOps.md) — Agentic AI 增强 Cloud DevOps 的七大领域（自动化事件响应、成本优化、安全合规等）
|
||||
- [The Myths and Misconceptions About Cloud Computing | LinkedIn](sources/The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md) — 云计算常见误解与真相
|
||||
- [How Can a Multi Cloud Strategy Transform Your Business ROI?](sources/How-Can-a-Multi-Cloud-Strategy-Transform-Your-Business-ROI.md) — 多云策略如何提升业务ROI（定义、优势、实施方法）
|
||||
@@ -277,6 +293,8 @@
|
||||
|
||||
- [CTP Topic 14 Octane Hub on AWS Real life experience](sources/ctp-topic-14-octane-hub-on-aws-real-life-experience.md) — Octane Hub 将生产服务迁移到 AWS 的真实经验分享
|
||||
|
||||
- [CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs](sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md) — 云 FinOps 最佳实践，PCG 成本管理三层服务、标签合规、Reserved Instances 集中管理
|
||||
|
||||
- [CTP Topic 4 Using Agile to run the Cloud Transformation Program](sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md) — 云转型计划中的敏捷实践应用，从 Scrum 过渡到 Kanban 的混合模式
|
||||
|
||||
- [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md) — AWS 标签验证工具，用于审计资源标签合规性
|
||||
@@ -295,6 +313,8 @@
|
||||
|
||||
- [CTP Topic 21 Supply Chain Security in Micro Focus](sources/ctp-topic-21-supply-chain-security-in-micro-focus.md) — Micro Focus 软件供应链安全的新方法，将供应链安全作为 SDL 第五大支柱
|
||||
|
||||
- [CTP Topic 24 Micro Focus Product Privacy Framework](sources/ctp-topic-24-micro-focus-product-privacy-framework.md) — Micro Focus 产品隐私框架，将 GDPR/CCPA 法律条款翻译为约 110 项技术要求
|
||||
|
||||
- [CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora](sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md) — PostgreSQL on RDS 与 Aurora 的详细对比（架构、性能、成本、故障切换）
|
||||
|
||||
- [CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup](sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md) — 使用 AWS Backup 实现企业级灾难恢复策略
|
||||
@@ -346,9 +366,17 @@
|
||||
|
||||
- [CTP Topic 55 AWS Firewall Manager](sources/ctp-topic-55-aws-firewall-manager.md) — AWS Firewall Manager 多账号安全策略集中管理，跨 Landing Zone 安全组统一配置与自动修复
|
||||
|
||||
- [CTP Topic 56 Automated Infrastructure Testing](sources/ctp-topic-56-automated-infrastructure-testing.md) — 自动化基础设施测试，TerraTest 框架和测试驱动开发在 IaC 中的应用
|
||||
|
||||
## Sources
|
||||
- [CTP Topic 31 Network Segregation and Secure Access to AWS Landing Zones](sources/ctp-topic-31-network-segregation-secure-access-aws-landing-zones.md) — AWS Landing Zone 网络隔离与安全访问解决方案
|
||||
|
||||
- [CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments](sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md) — Atlantis 替代 Jenkins 进行基础设施自动化部署，开源自托管 Terraform CI/CD 工具
|
||||
|
||||
- [CTP Topic 33 An introduction to GitOps](sources/ctp-topic-33-an-introduction-to-gitops.md) — GitOps 方法论，四大原则（声明式配置、版本控制、CD 流程分离、增量基础设施），与 DevOps 的关系，Pull Model vs Push Model
|
||||
|
||||
- [CTP Topic 15 Working with Renovatebot](sources/ctp-topic-15-working-with-renovatebot.md) — 利用 Renovate Bot 自动化管理云原生基础设施中的依赖项更新，支持 Terraform、Terragrunt、Docker 等技术栈
|
||||
|
||||
- [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) — AWS 云上 SaaS 数据库架构，SaaS 数据库团队全球运维实践
|
||||
|
||||
- [Learning Sessions Standard AMIs Updates 20231205](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) — AWS Standard AMIs 概述、更新和发布流程（每两个月发布、支持 23 种操作系统）
|
||||
@@ -369,13 +397,31 @@
|
||||
|
||||
- [Public Cloud Learning Sessions - Applicable Business Analysis Techniques](sources/Public-Cloud-Learning-Sessions-Applicable-Business-Analysis-Techniques-20240109.md) — OpenText 业务分析技术学习会议，介绍 BOSCARD、相关方轮盘和需求收集方法
|
||||
|
||||
- [Public Cloud Learning Sessions - Storage Cost Optimization](sources/public-cloud-learning-sessions-storage-cost-optimization-20240305.md) — AWS 存储服务（EBS、EFS、FSx、S3）成本优化最佳实践，包括存储类型选择、生命周期策略和智能分层
|
||||
|
||||
- [Public Cloud Learning Sessions - AWS End User Compute Services](sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430.md) — AWS 终端用户计算（EUC）服务介绍，涵盖 Workspaces 和 AppStream 2.0
|
||||
|
||||
- [Public Cloud Learning Sessions - Budget Control - 20240319](sources/Public-Cloud-Learning-Sessions-Budget-Control.md) — AWS账户预算控制自动化，提供账户所有者详细的支出警报和成本分析报告，实现成本控制
|
||||
|
||||
- [CTP Topic 1 Gruntwork Landing Zone Architecture](sources/ctp-topic-1-gruntwork-landing-zone-architecture.md) — 基于 Gruntwork 的 AWS Landing Zone 架构设计
|
||||
|
||||
- [CTP Topic 2 Git](sources/ctp-topic-2-git.md) — Git 版本控制系统基础与 DevOps 实践
|
||||
|
||||
- [CTP Topic 3 Deploy and maintain infrastructure](sources/ctp-topic-3-deploy-and-maintain-infrastructure.md) — CTP 云转型计划基础设施部署与维护，Terraform、Terragrunt、模块和服务目录在 Landing Zone 架构下的使用
|
||||
|
||||
- [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) — AWS Landing Zone 部署流程、数据收集策略、基于标签的安全控制机制
|
||||
|
||||
- [Public Cloud Learning Sessions (OpenText) - GIS Security Policies](sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md) — OpenText 全球信息安全团队（GIS）的安全策略框架与组织结构
|
||||
|
||||
- [Public Cloud Learning Sessions (OpenText) - Serverless Computing](sources/Public-Cloud-Learning-Sessions-OpenText-Serverless-Computing-20240903.md) — AWS 无服务器计算（Lambda、Step Functions、API Gateway、SAM）
|
||||
|
||||
- [Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-20241112.md) — AWS 生成式 AI 服务与提示词工程基础
|
||||
|
||||
- [Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126.md) — AWS AI 专家分享企业级 AI 应用案例与实践
|
||||
|
||||
- [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture - Part 1](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md) — 事件驱动架构（EDA）介绍，Amazon EventBridge、SQS、SNS
|
||||
- [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture - Part 2](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md) — 事件驱动架构（EDA）最佳实践与团队独立性
|
||||
|
||||
- [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) — AWS Landing Zone 设计更新，SaaS（生产）与 Labs（开发）环境区分
|
||||
|
||||
- [CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge](sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-bridge.md) — 使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 云监控的实施方案
|
||||
@@ -390,7 +436,15 @@
|
||||
|
||||
- [CTP Topic 11 AD Integration and Login using AD accounts](sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md) — Jenkins 与 AD 集成实现自动登录，以及 pre-commit 框架的 IaC 自动化安全检查
|
||||
|
||||
- [CTP Topic 9 CI CD with Gruntwork](sources/ctp-topic-9-ci-cd-with-gruntwork.md) — CI/CD 与 Gruntwork 集成
|
||||
|
||||
## Entities
|
||||
- [MUI](entities/MUI.md) — 审批决策者之一，负责超大规模云服务商支出的书面审批
|
||||
- [Shannon](entities/Shannon.md) — 审批决策者之一，负责超大规模云服务商支出的书面审批
|
||||
- [FinOps Team](entities/FinOps-Team.md) — 负责 Oli 工作流管理的团队，正在将工作流过渡到其管理之下
|
||||
- [AWS Instance Scheduler](entities/AWS-Instance-Scheduler.md) — AWS 官方实例调度工具，通过定时启停 EC2 和 RDS 实例实现成本优化
|
||||
- [FPNA Team](entities/FPNA-Team.md) — 负责预算可用性验证的团队
|
||||
- [Atlantis](entities/Atlantis.md) — 开源自托管 Terraform CI/CD 工具，替代 Jenkins 进行基础设施自动化部署
|
||||
- [IAM (AWS Identity and Access Management)](entities/IAM-AWS-Identity-and-Access-Management.md) — AWS 身份和访问管理服务，控制 AWS 资源的访问权限
|
||||
- [CCOE](entities/CCOE.md) — Cloud Center of Excellence，推动云采纳和治理的核心组织单元
|
||||
- [AWS Firewall Manager](entities/AWS-Firewall-Manager.md) — AWS 集中安全管理服务，跨账户配置防火墙规则和安全策略
|
||||
@@ -657,6 +711,9 @@
|
||||
- [Subscription](concepts/Subscription.md) — Azure 资源隔离的基本容器，每个订阅有独立的配额和访问控制
|
||||
- [PIM（Privileged Identity Management）](concepts/PIM-Privileged-Identity-Management.md) — Azure 特权身份管理，控制提升权限的访问
|
||||
|
||||
- [Demand Management](concepts/Demand-Management.md) — 平衡用户请求与可用容量的业务流程，确保组织有效管理和分配资源
|
||||
- [ITIL Framework](concepts/ITIL-Framework.md) — IT 服务管理框架，将业务流程分为服务战略、设计、转换、运营和改进五个阶段
|
||||
|
||||
- [Tagging Methodology](concepts/Tagging-Methodology.md) — 标签方法论，通过为资源定义标准化的元数据（如 Owner, BU, Product, Environment），作为自动化管理和安全策略执行的基础
|
||||
|
||||
- [Checkpoint Firewall](concepts/Checkpoint-Firewall.md) — 部署在云环境中的虚拟防火墙，通过集成 AWS 标签实现动态的对象识别和流量过滤
|
||||
@@ -777,6 +834,12 @@
|
||||
- [Serverless Computing](concepts/Serverless-Computing.md) — 无需管理服务器即可运行代码的云计算模式
|
||||
- [Cloud Service Delivery](concepts/Cloud-Service-Delivery.md) — 涵盖12个核心管理领域的云服务交付生命周期
|
||||
- [FinOps](concepts/FinOps.md) — 云财务运营，整合财务管理与云资源优化
|
||||
- [Instance Scheduling](concepts/Instance-Scheduling.md) — 实例定时调度，通过预设时间规则自动控制 EC2 和 RDS 实例启停，实现非生产环境成本优化
|
||||
- [Right Sizing](concepts/Right-Sizing.md) — 识别正确资源规格匹配工作负载需求，通过 EC2 Right Sizing 推荐、实例调度、闲置资源清理实现成本节省
|
||||
|
||||
- [CTP Topic 27 AWS Instance Scheduler](sources/ctp-topic-27-aws-instance-scheduler.md) — AWS 实例调度工具，通过定时启停 EC2 和 RDS 实例实现非生产环境成本优化，已通过 Guardrails 自动覆盖
|
||||
- [Workload Optimization](concepts/Workload-Optimization.md) — 通过现代化和 Right Sizing 优化资源配置，涵盖 Intel→AMD/Graviton 迁移、GP2→GP3 升级、EKS 版本升级
|
||||
- [Rate Optimization](concepts/Rate-Optimization.md) — 基于承诺使用获取折扣，Savings Plans/Reserved Instances/Spot Instances，最低交易价值每年 5,000 美元
|
||||
- [Cloud Operating Model](concepts/Cloud-Operating-Model.md) — 云运营模型，管理云资源、安全、成本和治理的框架
|
||||
- [DevOps 文化](concepts/DevOps-文化.md) — 打破开发与运维壁垒，优先协作、持续学习和客户导向的文化理念
|
||||
- [CI/CD 流水线](concepts/CI-CD-流水线.md) — 自动化测试、集成和部署的持续交付管道
|
||||
|
||||
237
wiki/log.md
237
wiki/log.md
@@ -1,3 +1,174 @@
|
||||
## [2026-04-19] ingest | CTP Topic 48 Terraform vs Terragrunt
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Terraform 与 Terragrunt 对比，Terraform 是云无关 IaC 工具，Terragrunt 是 DRY 包装器实现配置复用
|
||||
- Concepts created: Infrastructure-as-Code-IaC（已存在）, State-File（新增）
|
||||
- Entities created: HashiCorp（已存在）, Gruntwork（已存在）, Atlantis（已存在）
|
||||
- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
|
||||
- Notes: TerraGrunt 概念页面已存在，添加新的 Key Claims
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126
|
||||
- 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
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS AI 专家 Stephen Frank 分享企业级 AI 应用案例与实践，AWS 三层产品策略（基础设施 + Bedrock + AI 应用）、RAG、微调、负责任 AI
|
||||
- Concepts created: Generative-AI, RAG, Fine-Tuning, Amazon-Bedrock, Amazon-SageMaker, Responsible-AI
|
||||
- Entities created: Stephen Frank（新建）, OpenText（已存在）
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126.md
|
||||
- Notes: 与之前的 AI/ML Introduction 相关联，数据是差异化关键
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture - Part 2
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 事件驱动架构（EDA）最佳实践：Sparse vs Full State Events、幂等性、事件排序保障、团队独立性、扇出模式、竞争消费者模式
|
||||
- Concepts created: （已存在概念关联）
|
||||
- Entities created: Amazon Kinesis（新建）
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
|
||||
- Notes: Part 2 最佳实践，与 Part 1 关联
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture - Part 1
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 事件驱动架构（EDA）企业级集成模式学习，Amazon EventBridge、SQS、SNS
|
||||
- Concepts created: Event-Driven Architecture, Enterprise Integration Patterns
|
||||
- Entities created: Dr. Anil Giri（新建）, Amazon SQS（新建）, Amazon SNS（新建）
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
|
||||
- Notes: 与 EventBridge、Serverless Computing 关联，完成 EDA 基础概念
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions - Introduction to AI/ML with AWS
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS AI/ML 介绍与实践，Suraav Paul (AWS Senior Solutions Architect) 讲解 AI/ML 基础、生成式 AI、 Amazon Bedrock 和 ML Ops
|
||||
- Concepts created: Machine Learning, Amazon Bedrock, ML Ops, Foundation Model
|
||||
- Entities created: AWS（已存在，已关联）, Suraav Paul（新建）
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machine-learning-20240206.md
|
||||
- Notes: 与 Generative AI、RAG 概念关联；数据仅在请求响应周期存储，确保隐私
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - Serverless Computing
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 无服务器计算学习会议，涵盖 Lambda 事件触发机制、Step Functions 工作流编排、API Gateway API 管理、SAM 本地开发
|
||||
- Concepts created: Lambda, Step Functions, API Gateway, Serverless Application Model, Serverless Computing, Event-driven Computing, Execution Role, Resource-based Policy
|
||||
- Entities created: AWS（已存在）, OpenText（已存在）
|
||||
- Source page: wiki/sources/Public-Cloud-Learning-Sessions-OpenText-Serverless-Computing-20240903.md
|
||||
- Notes: 与传统 EC2 模式对比：无服务器计算帮助企业快速上市、聚焦业务、降低 TCO
|
||||
|
||||
## [2026-04-19] ingest | Cloud Learning Master Index
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: OpenText 内部 Public Cloud Learning Sessions 课程的分类索引与统计信息，涵盖 10 个云技术领域，共 121 个视频课程
|
||||
- Concepts created: AWS Landing Zone, IAM, Terraform, EKS, FinOps, GitOps, DevSecOps, Landing Zone
|
||||
- Entities created: OpenText（已存在，已关联）
|
||||
- Source page: wiki/sources/cloud-learning-master-index.md
|
||||
- Notes: 与现有 Public Cloud Learning Sessions 系列 source pages 关联；作为课程导航索引页面
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions - Budget Control - 20240319
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS账户预算控制自动化，提供四级警报类型（forecast、actual、severe、enforcement）和详细成本报告（top services、top users），通过SCP限制资源创建实现成本控制
|
||||
- Concepts created: Budget Control, SCP, Source Identity
|
||||
- Entities created: SRE Core Team（新建）, FinOps Team（已存在，已关联）
|
||||
- Source page: wiki/sources/Public-Cloud-Learning-Sessions-Budget-Control.md
|
||||
- Notes: 与 FinOps、Storage Cost Optimization、Right Sizing 概念关联；警报通过 Lambda 处理 AWS Budget Alerts 原始邮件生成详细报告；100%阈值触发SCP阻止新资源创建
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions - Storage Cost Optimization - 20240305
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 存储服务（EBS、EFS、FSx、S3）成本优化最佳实践，涵盖存储类型选择、生命周期策略和智能分层
|
||||
- Concepts created: Lifecycle Policy, S3 Intelligent Tiering, EBS GP3, EBS Snapshot Archive, EFS Infrequent Access, FSx for NetApp ONTAP
|
||||
- Entities created: AWS（已存在，已关联）
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-storage-cost-optimization-20240305.md
|
||||
- Notes: 与 FinOps、Storage Cost Optimization 概念关联；ADM 迁移案例显示成本降低 60%
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 63 Optimise resource cost using automation
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-63-optimise-resource-cost-using-automation.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 通过自动化技术降低云资源成本，涵盖批准区域、实例类型优化（Graviton 便宜 20-25%）、承诺计划（1年40%折扣，3年60-64%）、存储优化（GP2→GP3 节省20%）、自动化调度（每天10小时可节省70%）
|
||||
- Concepts created: Approved Region, Instance Type Selection, Commitment Plans, Storage Optimization, Automation Scheduler, Graviton
|
||||
- Entities created: AWS（已存在，已关联）, Micro Focus（已存在）, Pushka（已关联）
|
||||
- Source page: wiki/sources/ctp-topic-63-optimise-resource-cost-using-automation.md
|
||||
- Notes: 与 FinOps、Right Sizing、Rate Optimization、Storage Cost Optimization 概念关联；是 CTP Topic 71（Right Sizing）的补充内容
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 71 PCG's Guide to RightSizing, Why, How, When
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 资源优化（Right Sizing）的全面指南，涵盖 Why（为什么需要做）、How（如何实施）、When（什么时候做）三大维度
|
||||
- Concepts created: Right Sizing（已存在，已关联）
|
||||
- Entities created: PCG Team（已存在，已关联）
|
||||
- Source page: wiki/sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md
|
||||
- Notes: 与 FinOps、Cost Optimization 概念关联；与 CTP Topic 13（FinOps 最佳实践）、CTP Topic 27（实例调度器）形成关联
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS
|
||||
- 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
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS EC2 成本优化最佳实践，涵盖 Graviton 迁移（40% 性价比提升）、Spot 实例利用（最高 90% 折扣）、购买选项选择（On-Demand、Savings Plans、Spot）
|
||||
- Concepts created: EC2 Spot Instances, Spot Interruption
|
||||
- Entities created: Graviton, Mike Dukes, Steele Taylor
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md
|
||||
- Notes: 与 Cost Optimization 概念关联；Graviton 处理器比同类 x86 减少最多 60% 功耗
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 云成本优化策略，FINOPS 团队 Vinay 分享工作负载优化（现代化+Right Sizing）和费率优化（承诺使用折扣），涵盖 Intel→AMD（6-10%节省）、Graviton（20-25%节省）、GP2→GP3（20%节省）、Spot 实例（最高90%折扣）
|
||||
- Concepts created: Right Sizing, Workload Optimization, Rate Optimization
|
||||
- Entities created: FINOPS Team（已存在）
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md
|
||||
- Notes: 与 FinOps、Cost Optimization 概念关联；承诺计划最低交易价值每年 5,000 美元
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs
|
||||
- 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
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 云 FinOps 最佳实践，PCG 团队介绍成本管理三层服务（成本管理、成本优化、治理与自动化），标签合规、Reserved Instances 集中管理、Cloud Health 工具使用
|
||||
- Concepts created: Cloud Health, Cost-Optimization, Showback-Chargeback, Reserved-Instances, Savings-Plans, Graviton, Tagging-Methodology
|
||||
- Entities created: PCG-Team（已更新）
|
||||
- Source page: wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md
|
||||
- Notes: 与 CTP Topic 63（自动化调度优化）、CTP Topic 27（实例调度器）、CTP Topic 71（Rightsizing）形成关联
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 15 Working with Renovatebot
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-15-working-with-renovatebot.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 利用 Renovate Bot 自动化管理云原生基础设施中的依赖项更新，支持 Terraform、Terragrunt、Docker 等技术栈
|
||||
- Concepts created: Renovate Bot, Dependency Dashboard, Rate Limiting
|
||||
- Entities created: Paul Hopkins
|
||||
- Source page: wiki/sources/ctp-topic-15-working-with-renovatebot.md
|
||||
- Notes: 与 CTP Topic 33（GitOps）、CTP Topic 32（Atlantis）、Pre-commit Hooks and Linting Sessions 形成关联
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 56 Automated Infrastructure Testing
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-56-automated-infrastructure-testing.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 自动化基础设施测试，TerraTest 框架和测试驱动开发在 IaC 中的应用，自动化 apply-test-destroy 流程
|
||||
- Concepts created: TerraTest, Test-Driven Development
|
||||
- Entities created: Mark Francis
|
||||
- Source page: wiki/sources/ctp-topic-56-automated-infrastructure-testing.md
|
||||
- Notes: 与 CTP Topic 32（Atlantis）、CTP Topic 9（CI/CD）、CTP Topic 11（pre-commit）形成关联
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions - Ollie Workflow and The Demand Process
|
||||
- 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
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Oli 工作流流程，用于超大规模云服务商的支出审批、需求管理和请求处理。ITIL 框架下的三阶段审批流程（可行性验证→技术验证→预算验证）
|
||||
- Concepts created: Demand Management, ITIL Framework
|
||||
- Entities created: MUI, Shannon, FinOps Team, FPNA Team
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416.md
|
||||
- Notes: 与 Tom Bice（已存在）形成关联，机器自动化是核心目标
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 9 CI CD with Gruntwork
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: CI/CD 与 Gruntwork 集成，待视频转录后补充实质内容
|
||||
- Concepts: CI/CD 流水线、Gruntwork Landing Zone、Infrastructure as Code（已存在）
|
||||
- Entities: Gruntwork、OpenText（已存在）
|
||||
- Source page: wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md
|
||||
- Notes: 源文档标记为待转录状态，与 CTP Topic 32（Atlantis）、CTP Topic 33（GitOps）形成关联
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Atlantis 替代 Jenkins 进行基础设施自动化部署，开源自托管 Terraform CI/CD 工具，通过 GitHub PR 评论触发 plan/apply
|
||||
- Concepts created: Pre-merge Apply, Directory Locking, Parallel Builds
|
||||
- Entities created: Atlantis
|
||||
- Source page: wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md
|
||||
- Notes: 与 Jenkins（被替代）、Terraform（管理对象）、GitOps（工作流模式）形成关联
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 49 Container Lifecycle Hardening Standards
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -41,7 +212,14 @@
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md
|
||||
- Notes: 与 Modern ITSM 存在安全治理 vs 自动化优先的视角差异
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 64 Scaling out with Amazon EKS
|
||||
## [2026-04-19] ingest | RTO vs RPO: Key Differences for Modern Disaster Recovery
|
||||
- Source file: raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及在现代持续交付中的应用，Feature Flag 实现秒级回滚
|
||||
- Concepts created: RTO, RPO, Feature Flag, Kill Switch, 渐进式发布
|
||||
- Entities created: LaunchDarkly, HP, Christian Dior
|
||||
- Source page: wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md
|
||||
- Notes: RTO/RPO 已存在于 overview.md，与本 source page 形成概念与实例的关联
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Amazon EKS 水平扩展与垂直扩展机制，Suravpul (AWS) 演讲，涵盖 HPA、KEDA、Karpenter、Cluster Autoscaler、IPv6 网络解决方案
|
||||
@@ -390,7 +568,14 @@
|
||||
- Source page: wiki/sources/ctp-topic-30-managing-change.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance
|
||||
## [2026-04-19] ingest | Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 生成式 AI 服务与提示词工程基础，涵盖生成式 AI 用例、Amazon Bedrock、SageMaker、Amazon Q，提示词组件与技巧
|
||||
- Concepts created: 生成式 AI, RAG, Fine-Tuning, Prompt Engineering, Amazon Bedrock, Amazon SageMaker, Amazon Q, Foundation Model
|
||||
- Entities created: Shikad Holtzman（新建）, OpenText（已存在）
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-20241112.md
|
||||
- Notes: 与 Introduction to AI/ML with AWS 关联；数据是企业差异化的关键
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: DR 向 Recovery Assurance 演进，从被动响应转向主动式架构，通过设计、软件、构建、环境四个维度构建恢复保障能力
|
||||
@@ -2297,6 +2482,15 @@
|
||||
- Source page: wiki/sources/AI-Memory-Tools-Two-Camps.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 27 AWS Instance Scheduler
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Instance Scheduler 自动调度工具，通过定时启停 EC2 和 RDS 实例实现非生产环境成本优化，已通过 Guardrails 自动覆盖公司内绝大多数月消费超过 10 美元的 AWS 账号
|
||||
- Concepts created: Instance Scheduling
|
||||
- Entities created: AWS Instance Scheduler（新增）
|
||||
- Source page: wiki/sources/ctp-topic-27-aws-instance-scheduler.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 44 AWS Backup in Micro Focus
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -2351,10 +2545,10 @@
|
||||
- Source file: raw/Cloud & DevOps/How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md
|
||||
- Status: ✅ 成功摄入（更新）
|
||||
- Summary: AWS 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案，通过 EventBridge 跨账号事件转发 + CloudWatch Logs 集中存储实现单一管理界面监控
|
||||
- Concepts created: Centralized Logging（新增）, Cross-Account Event Forwarding（新增）
|
||||
- Concepts created: Centralized Logging（已有）, Cross-Account Event Forwarding（新增）
|
||||
- Entities created: StackSets（已有）, EventBridge（已有）, CloudWatch（已有）, AWS Organizations（已有）
|
||||
- Source page: wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md
|
||||
- Notes: 对同一主题的更新摄入，补充新发现的文档（旧版保留在 wiki/sources/how-to-simplify-multi-account-deployments-monitoring.md），新增概念：Centralized Logging
|
||||
- Notes: 对同一主题的更新摄入，补充新发现的文档（旧版保留在 wiki/sources/how-to-simplify-multi-account-deployments-monitoring.md），新增概念：Cross-Account Event Forwarding，补充 Cost Implications 和 Clean up 部分
|
||||
|
||||
## [2026-04-19] ingest | ZK Steward Agent
|
||||
- Source file: raw/Agent/agency-agents/specialized/zk-steward.md
|
||||
@@ -2391,3 +2585,38 @@
|
||||
- Entities created: Bottlerocket（新增）
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md
|
||||
- Notes: 与 EKS、Karpenter 形成 EKS 优化三部曲；与通用 Linux 发行版（Ubuntu、RHEL）对比，定位更精简、更安全
|
||||
## [2026-04-19] ingest | CTP Topic 24 Micro Focus Product Privacy Framework
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-24-micro-focus-product-privacy-framework.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Micro Focus 产品隐私框架，将 GDPR/CCPA 法律条款翻译为约 110 项具体技术要求，通过成熟度模型（0-4 级）和蜘蛛图评估合规现状，产出标准化《产品隐私设置文档》
|
||||
- Concepts created: STLC, PII, GDPR, CCPA, Spider Chart, Data Controller, Data Processor, Anonymization, Pseudonymization
|
||||
- Entities created: Micro Focus（已有）, Shlomi Ben-Hur（已有）
|
||||
- Source page: wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md
|
||||
- Notes: 隐私框架是 STLC 中 13 个安全与隐私轨道之一，与 CTP Topic 21（供应链安全）同属 Shlomi Ben-Hur 主讲
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 2 Git
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Git 版本控制系统基础与 DevOps 实践，涵盖分布式版本控制、分支管理、代码协作流程
|
||||
- Concepts created: Git, 版本控制
|
||||
- Entities created: Public Cloud Learning Sessions（新增）, CTP（已有）
|
||||
- Source page: wiki/sources/ctp-topic-2-git.md
|
||||
- Notes: 作为 CI/CD 与 GitOps 系列的前置基础课程，与 CTP Topic 11（AD 集成）形成开发流程链
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 3 Deploy and maintain infrastructure
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: CTP 云转型计划基础设施部署与维护，聚焦 Terraform、Terragrunt、模块和服务目录在 Landing Zone 架构下的使用
|
||||
- Concepts created: Terraform, Service-Catalog, Module
|
||||
- Entities created: Product-Team（新增）, Gruntwork（已有）
|
||||
- Source page: wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md
|
||||
- Notes: 承接 Topic 2 Git，介绍基础设施即代码的部署与管理，是 CI/CD 系列的核心内容
|
||||
|
||||
## [2026-04-19] ingest | CTP Topic 33 An introduction to GitOps
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-33-an-introduction-to-gitops.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: GitOps 方法论介绍，将软件开发原则应用于部署流程，解决失败部署、配置不一致等问题。四大原则：声明式配置、版本控制、CD 流程分离、增量基础设施。推荐 Pull Model 实现。
|
||||
- Concepts created: GitOps, Declarative Configuration, Infrastructure as Code (IaC), Pull Model, Idempotent Operation
|
||||
- Entities created: Victor Etkin
|
||||
- Source page: wiki/sources/ctp-topic-33-an-introduction-to-gitops.md
|
||||
- Notes: 更新了已有的 GitOps Concept 页面，增加了 Pull Model 和 Idempotent Operation 等关键概念
|
||||
|
||||
@@ -20,6 +20,14 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- Identity Governance（身份治理）：管理数字身份、降低风险并保持合规的框架，回答谁有权访问、谁应该访问、如何访问三个核心问题
|
||||
- Multi-Account Strategy（多账号策略）：AWS 推荐的企业级云架构模式，通过将工作负载分离到多个 AWS 账号来提升安全性、治理能力和故障隔离
|
||||
- Gruntwork Landing Zone：Gruntwork 提供的预配置 AWS 基础架构框架，基于 Reference Architecture 包含核心账户和工作负载账户
|
||||
- Landing Zone：云着陆区，标准化的多账户基础架构框架，用于托管产品团队的工作负载
|
||||
- Terraform：基础设施即代码工具，通过声明式配置定义云资源，实现跨平台基础设施管理
|
||||
- Terragrunt：Terraform 的包装工具，提供模块化、变量共享和环境隔离，跨多账户部署
|
||||
- TerraTest：Golang 编写的自动化基础设施测试库，自动化 Terraform apply-test-destroy 流程
|
||||
- Test-Driven Development：测试驱动开发方法论，先写测试再实现功能
|
||||
- Service Catalog：服务目录，封装业务需求的模块分组，提供服务级别抽象，实现跨团队复用
|
||||
- Module：Terraform 模块，可复用的基础设施配置单元
|
||||
|
||||
- CCOE（Cloud Center of Excellence）：推动云采纳和治理的核心组织单元，负责 AMI 标准制定和发布
|
||||
|
||||
- OpsBridge（运营桥）：Micro Focus 的企业级监控平台，支持 AWS 云监控，可部署在本地或 EKS 上
|
||||
@@ -41,6 +49,7 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- DevOps 文化：打破开发与运维壁垒，优先协作、持续学习和客户导向的文化理念
|
||||
- CI/CD 流水线：自动化测试、集成和部署的持续交付管道
|
||||
- Infrastructure as Code (IaC)：通过代码实现一致性、版本控制的基础设施管理
|
||||
- Renovate Bot：开源依赖自动化更新工具，通过扫描代码并自动提交 PR 保持依赖项处于最新状态
|
||||
- 敏捷实践：Scrum、Kanban 等迭代开发方法论
|
||||
- 事件驱动项目管理：使用数据库存储项目状态和历史事件，通过 AI Agent 自然语言交互替代静态 Kanban 看板
|
||||
- 内网穿透（NAT Penetration）：将内网服务通过公网服务器暴露给外部访问的技术，FRP 是常用方案之一
|
||||
@@ -90,6 +99,13 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- Zettelkasten：卢曼卡片盒知识管理系统，通过原子化笔记和索引入口构建知识网络
|
||||
- **fireworks-tech-graph**：AI 驱动技术图生成工具，将中文描述转化为 SVG/PNG 格式的架构图、流程图、UML 图
|
||||
|
||||
- Foundation Model（基础模型）：具有数十亿参数的大规模预训练模型，是生成式 AI 的核心
|
||||
- Amazon Bedrock：AWS 全托管服务，用于使用基础模型构建生成式 AI 应用
|
||||
- Amazon SageMaker：AWS 机器学习平台，用于构建、训练和部署模型
|
||||
- ML Ops：机器学习运维，结合 ML 和 DevOps 实践
|
||||
- Fine-Tuning：使用标记数据集定制基础模型
|
||||
- Responsible AI：负责任 AI，包括公平性、可解释性、健壮性、治理、透明度和隐私/安全
|
||||
|
||||
- 开源大语言模型：以 DeepSeek、Qwen 为代表的开源基座大模型
|
||||
- AI生图模型：以 Flux、Stable Diffusion 为代表的开源图像生成模型
|
||||
- AI生视频模型：以 HunyuanVideo 为代表的开源视频生成模型
|
||||
@@ -202,6 +218,8 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- **AI 工具分类** — 大脑类（XAR GPT、GEMALA）、设计师类（Midjourney、Nano Banana）、动效类（海螺AI、KAI）
|
||||
- **Synology NAS + Xiaoya Alist + CloudDrive2 + Plex 搭建家庭媒体平台** — 利用群晖NAS + Xiaoya Alist + CloudDrive2 + Plex 搭建家庭媒体平台（Docker 部署、Xiaoya 获取云盘资源、CloudDrive2 挂载为本地磁盘、Plex 媒体刮削）
|
||||
- **Cloud Operating Model: Key Strategies and Best Practices** — 云运营模型（COM）四大支柱：治理、自动化、安全、成本管理，涵盖行业用例（金融、医疗、零售、SaaS）和未来趋势（AI 驱动运维、可持续云计算、多云策略）
|
||||
|
||||
- **Serverless Computing（无服务器计算）** — 云原生架构模式，AWS 负责基础设施运维，客户只需编写业务代码，实现按需付费和自动扩展
|
||||
- **用Docker中安装Navidrome** — 使用 Docker Compose 部署 Navidrome 音乐流媒体服务器的配置文件示例
|
||||
- **Modern ITSM: Driving Efficiency, Security & Resilience** — 现代 IT 服务管理的演进趋势，AIOps、零信任架构、Policy-as-Code 等技术的应用
|
||||
- **How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets** — 多账号环境下 CloudFormation StackSets 部署监控的集中化日志解决方案，通过 EventBridge 跨账号事件转发 + CloudWatch Logs 实现单一管理界面监控（[旧版](sources/how-to-simplify-multi-account-deployments-monitoring.md)）
|
||||
@@ -224,6 +242,12 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - Applicable Business Analysis Techniques** — OpenText 业务分析技术学习会议，介绍 BOSCARD（背景、目标、范围、约束、假设、风险、角色、可交付成果）、相关方轮盘和需求收集方法（T 型技能、用户故事 + 元数据、SAFe 框架）
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - Serverless Computing** — AWS 无服务器计算学习会议，涵盖 Lambda 事件触发机制、Step Functions 工作流编排、API Gateway API 管理、SAM 本地开发
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - Event Driven Architecture - Part 2** — 事件驱动架构（EDA）最佳实践：Sparse vs Full State Events、幂等性、事件排序保障、团队独立性、扇出模式、竞争消费者模式
|
||||
|
||||
- **Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering** — AWS 生成式 AI 服务与提示词工程基础，涵盖 RAG、微调、提示词组件与技巧
|
||||
|
||||
- BOSCARD（Background、Objectives、Scope、Constraints、Assumptions、Risks、Roles、Deliverables）：定义复杂新工作的系统化技术，帮助在项目早期明确范围、目标和可交付成果，避免目标、时间线和交付物的混淆
|
||||
|
||||
- **Ubuntu 服务器通过 rsync 实现日常增量备份** — 使用 rsync 实现 Ubuntu 服务器到 NAS 的增量备份，涵盖 NFS 永久挂载和灾难恢复
|
||||
@@ -245,11 +269,25 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- **Bottlerocket OS** — 专为容器设计的最小化 Linux 操作系统，AWS 维护，开源免费，通过变体满足特定工作负载需求，具备安全更新和不可变根文件系统
|
||||
|
||||
- **CTP Topic 11 AD Integration and Login using AD accounts** — Jenkins 与 AD 集成实现自动登录，pre-commit 框架嵌入 terraform fmt、TFLint、Checkov 自动化安全检查，左移治理模式
|
||||
- **CTP Topic 3 Deploy and maintain infrastructure** — CTP 云转型计划基础设施部署与维护，Terraform、Terragrunt、模块和服务目录在 Landing Zone 架构下的使用
|
||||
|
||||
- **CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments** — Atlantis 替代 Jenkins 进行基础设施自动化部署，开源自托管 Terraform CI/CD 工具，通过 GitHub PR 评论触发 plan/apply，支持并行构建和目录锁定
|
||||
- **CTP Topic 40 SaaS Database Architecture On AWS Cloud** — AWS 云上 SaaS 数据库架构设计，SaaS 数据库团队全球运维实践（500+ 数据库、1000+ 服务器，Oracle/Postgres/DynamoDB 等多种数据库，高可用设计）
|
||||
- **CTP Topic 28 AWS Tag Validation Tool** — AWS 标签验证工具，通过 YAML 配置文件审计资源标签合规性，生成 CSV 报告
|
||||
- **CTP Topic 30 Managing Change** — 云转型项目中的变更管理流程，SRE 角色定义和三种变更类型（标准变更、正常变更、紧急变更）
|
||||
- **CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program** — AWS Backup 在 CTP 云转型计划中的实施，涵盖 SRE 备份模型、DR 账户备份、AWS Backup Audit Manager 审计
|
||||
|
||||
- **Public Cloud Learning Sessions - Reducing Cloud Costs** — 云成本优化策略，涵盖工作负载优化（现代化+Right Sizing）和费率优化（Savings Plans、预留实例、Spot 实例），FINOPS 团队分享
|
||||
|
||||
- **CTP Topic 71 PCG's Guide to RightSizing, Why, How, When** — AWS 资源优化（Right Sizing）的全面指南，涵盖为什么需要做、如何做、什么时候做三大维度
|
||||
|
||||
- **FinOps** — 云财务运营实践，整合财务管理与云资源优化，实现云支出可见性、控制和持续优化
|
||||
- **Budget Control** — AWS账户预算控制自动化，提供四级警报类型（forecast、actual、severe、enforcement）和详细成本报告（top services、top users），通过SCP限制资源创建实现成本控制
|
||||
- **Storage Cost Optimization** — AWS 存储服务（EBS、EFS、FSx、S3）成本优化，通过选择正确存储类型、使用生命周期策略和智能分层降低存储成本
|
||||
- **Right Sizing** — 识别正确资源规格匹配工作负载需求，通过 EC2 Right Sizing 推荐报告、实例调度、闲置资源清理实现成本节省
|
||||
- **Instance Scheduling** — 实例定时调度工具，通过预设时间规则自动控制 EC2 和 RDS 实例启停，实现非生产环境成本优化
|
||||
- **Rate Optimization** — 基于承诺使用（1-3年）获取折扣，AWS 提供 Savings Plans 和 Reserved Instances，最低交易价值每年 5,000 美元
|
||||
|
||||
- **CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana** — AWS 云监控与 Grafana 可观测性平台集成，Terraform 模块自动创建 Grafana 组织、仪表板，Optic DR 数据源集成，告警转发 OpsBridge
|
||||
- **CTP Topic 62 AWS Secrets Manager** — AWS Secrets Manager 企业级敏感信息管理，分阶段实施方法（集中化→自动化获取→轮换），Lambda 数据库密码轮换，JDBC Wrapper 无密码登录
|
||||
|
||||
@@ -264,6 +302,7 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
|
||||
- **CTP Topic 57 Product backlog managing demand** — Product Backlog 管理需求流程，SMACs 提交、Octane 入池、前置条件阶段
|
||||
- **CTP Topic 21 Supply Chain Security in Micro Focus** — Micro Focus 软件供应链安全的新方法，将供应链安全作为 SDL 第五大支柱
|
||||
- **CTP Topic 24 Micro Focus Product Privacy Framework** — Micro Focus 产品隐私框架，将 GDPR/CCPA 法律条款翻译为约 110 项具体技术要求，通过成熟度模型评估合规现状
|
||||
- **CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge** — 使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 云监控的实施方案（IAM Role 跨账户访问、Management Packs 动态监控）
|
||||
- **如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹** — 在 Ubuntu Server 上通过 NFS 协议挂载 Synology NAS 共享文件夹
|
||||
- **Ubuntu 禁用合盖休眠** — 在 Ubuntu 24.04 中通过修改 systemd-logind 配置禁用笔记本合盖休眠行为
|
||||
|
||||
@@ -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
|
||||
- 无冲突记录
|
||||
@@ -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 允许开发者聚焦业务逻辑
|
||||
@@ -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
|
||||
- （暂无）
|
||||
51
wiki/sources/cloud-learning-master-index.md
Normal file
51
wiki/sources/cloud-learning-master-index.md
Normal file
@@ -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
|
||||
- 无冲突记录
|
||||
@@ -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
|
||||
- 无明显冲突记录
|
||||
46
wiki/sources/ctp-topic-15-working-with-renovatebot.md
Normal file
46
wiki/sources/ctp-topic-15-working-with-renovatebot.md
Normal file
@@ -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
|
||||
- （文档中未发现明显冲突）
|
||||
34
wiki/sources/ctp-topic-2-git.md
Normal file
34
wiki/sources/ctp-topic-2-git.md
Normal file
@@ -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
|
||||
@@ -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]] 无冲突
|
||||
53
wiki/sources/ctp-topic-27-aws-instance-scheduler.md
Normal file
53
wiki/sources/ctp-topic-27-aws-instance-scheduler.md
Normal file
@@ -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
|
||||
@@ -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
|
||||
@@ -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
|
||||
67
wiki/sources/ctp-topic-33-an-introduction-to-gitops.md
Normal file
67
wiki/sources/ctp-topic-33-an-introduction-to-gitops.md
Normal file
@@ -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. 向环境推出镜像
|
||||
50
wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
Normal file
50
wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
Normal file
@@ -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
|
||||
@@ -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]]
|
||||
@@ -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 实例用于兼容的工作负载
|
||||
@@ -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 适合变化的工作负载
|
||||
37
wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md
Normal file
37
wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md
Normal file
@@ -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
|
||||
- 无
|
||||
@@ -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 角色。
|
||||
|
||||
**注意**：在删除管理账号日志设置之前，确保所有堆栈集操作已完成，以确保正确清理所有资源。
|
||||
@@ -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 实例不适合有状态服务（如数据库），需根据工作负载特性选择
|
||||
@@ -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 提供托管环境，数据仅在请求响应周期存储
|
||||
- 对方观点：本地部署可完全控制模型和数据，但需要管理基础设施
|
||||
@@ -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
|
||||
- 无
|
||||
@@ -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
|
||||
@@ -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*
|
||||
@@ -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
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user