Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,76 +1,76 @@
|
||||
---
|
||||
title: "ACI 318"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ACI 318-19 / ACI 318-22（当前版本）
|
||||
- Building Code Requirements for Structural Concrete
|
||||
- 美国钢筋混凝土设计规范
|
||||
- American Concrete Institute 318
|
||||
|
||||
## Description
|
||||
|
||||
ACI 318 是美国钢筋混凝土结构设计的权威规范，全称 *Building Code Requirements for Structural Concrete*，由美国混凝土协会（ACI）发布，被 IBC 引用为混凝土结构设计的核准方法。ACI 318 采用与 AISC 360 相同的 LRFD（荷载抗力系数设计）和 SD（ Strength Design）方法体系。
|
||||
|
||||
## Core Content
|
||||
|
||||
- **Chapter 2** – General Requirements（一般要求）
|
||||
- **Chapter 3** – Loads（荷载）
|
||||
- **Chapter 4** – Structural Systems（结构体系）
|
||||
- **Chapter 5** – Load Effects（荷载效应）
|
||||
- **Chapter 6** – Load Effects Combinations（荷载组合）
|
||||
- **Chapter 7** – Member Design – One-Way Systems（单向构件设计）
|
||||
- **Chapter 9** – Member Design – Two-Way Action（双向构件设计）
|
||||
- **Chapter 10** – Shear and Torsion（抗剪与扭转）
|
||||
- **Chapter 11** – Development and Splices（钢筋锚固与搭接）
|
||||
- **Chapter 12** – Foundations（基础）
|
||||
- **Chapter 18** – Earthquake-Resistant Structures（抗震结构）
|
||||
|
||||
## Strength Design (SD) — LRFD 方法
|
||||
|
||||
ACI 318 采用 Strength Design（等同于 LRFD），核心公式：
|
||||
- **设计弯矩**：φMn ≥ Mu（φ = 0.90 抗弯，φ = 0.75 抗剪）
|
||||
- **抗压构件**：φPn ≥ Pu（φ = 0.65 螺旋箍筋柱，φ = 0.70 钢筋混凝土柱）
|
||||
- **荷载组合**（ACI 318-19 Eq. 5.3.1）：
|
||||
- U = 1.4D
|
||||
- U = 1.2D + 1.6L + 0.5(Lr 或 R)
|
||||
- U = 1.2D + 1.0E + L（地震组合）
|
||||
- U = 1.2D + 1.0W + L（风荷载组合）
|
||||
|
||||
## Seismic Provisions
|
||||
|
||||
ACI 318 Chapter 18 定义了特殊抗弯框架（Special Moment Frames, SMF）、中等抗弯框架（IMF）和普通抗弯框架（Ordinary Moment Frames）的细部构造要求：
|
||||
- **SMF**（ACI 318-19 §18.2–18.9）：梁柱节点区箍筋加密、强柱弱梁设计、钢筋延伸长度 ≥ 1.25Fy d（Flexural Tension）
|
||||
- **ACI 350**：Environmental Engineering Concrete Structures——供水厂、污水处理厂等耐久性要求更高的混凝土结构
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC 引用 ACI 318 作为混凝土结构设计标准，全美 50 个州 + 哥伦比亚特区采纳 IBC
|
||||
- **国际**：美国海外投资项目、海军设施、援建项目通常要求 ACI 318 合规；中东（UAE/沙特）部分项目同时要求 ACI 318 和本地规范
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 ACI 318 进行混凝土设计，计算包必须包含：
|
||||
1. ACI 318 版本年份（如 ACI 318-19）
|
||||
2. 混凝土 fc' 和钢筋 fy 强度值
|
||||
3. 抗弯设计（单筋/双筋/K 法/简化法）
|
||||
4. 抗剪设计（vcu + vsu，双向板冲切验算）
|
||||
5. 抗震细部检查（SMF/IMF 要求）
|
||||
6. 钢筋锚固与搭接长度验算
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：美国钢结构规范——ACI 318 的钢结构对应规范，同属 IBC 引用体系
|
||||
- [[Eurocode]] EN 1992：欧洲混凝土规范——与 ACI 318 并列，但 Eurocode 采用 K 法单筋设计（限制相对受压区高度），ACI 318 采用 φMn ≥ Mu 直接法，两者公式和参数体系不同，不可混用
|
||||
- [[ASCE-7]]：美国荷载规范——ACI 318 的荷载来源规范
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[LRFD]]（荷载抗力系数设计）：ACI 318 的主要设计方法
|
||||
- [[ULS]]（极限状态设计）：ACI 318 Strength Design 的核心哲学——以乘以系数的名义荷载与除以系数的名义抗力比较
|
||||
- [[SLS]]（正常使用极限状态）：ACI 318 在 Appendix B 中定义挠度控制要求（ACI 318-19 §20.3.1）
|
||||
- [[Basis-of-Design]]（设计依据报告）：须记录 ACI 318 版本、fc'/fy、特殊荷载组合及所有偏离默认值的参数
|
||||
---
|
||||
title: "ACI 318"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ACI 318-19 / ACI 318-22（当前版本）
|
||||
- Building Code Requirements for Structural Concrete
|
||||
- 美国钢筋混凝土设计规范
|
||||
- American Concrete Institute 318
|
||||
|
||||
## Description
|
||||
|
||||
ACI 318 是美国钢筋混凝土结构设计的权威规范，全称 *Building Code Requirements for Structural Concrete*，由美国混凝土协会（ACI）发布，被 IBC 引用为混凝土结构设计的核准方法。ACI 318 采用与 AISC 360 相同的 LRFD（荷载抗力系数设计）和 SD（ Strength Design）方法体系。
|
||||
|
||||
## Core Content
|
||||
|
||||
- **Chapter 2** – General Requirements（一般要求）
|
||||
- **Chapter 3** – Loads（荷载）
|
||||
- **Chapter 4** – Structural Systems（结构体系）
|
||||
- **Chapter 5** – Load Effects（荷载效应）
|
||||
- **Chapter 6** – Load Effects Combinations（荷载组合）
|
||||
- **Chapter 7** – Member Design – One-Way Systems（单向构件设计）
|
||||
- **Chapter 9** – Member Design – Two-Way Action（双向构件设计）
|
||||
- **Chapter 10** – Shear and Torsion（抗剪与扭转）
|
||||
- **Chapter 11** – Development and Splices（钢筋锚固与搭接）
|
||||
- **Chapter 12** – Foundations（基础）
|
||||
- **Chapter 18** – Earthquake-Resistant Structures（抗震结构）
|
||||
|
||||
## Strength Design (SD) — LRFD 方法
|
||||
|
||||
ACI 318 采用 Strength Design（等同于 LRFD），核心公式：
|
||||
- **设计弯矩**：φMn ≥ Mu（φ = 0.90 抗弯，φ = 0.75 抗剪）
|
||||
- **抗压构件**：φPn ≥ Pu（φ = 0.65 螺旋箍筋柱，φ = 0.70 钢筋混凝土柱）
|
||||
- **荷载组合**（ACI 318-19 Eq. 5.3.1）：
|
||||
- U = 1.4D
|
||||
- U = 1.2D + 1.6L + 0.5(Lr 或 R)
|
||||
- U = 1.2D + 1.0E + L（地震组合）
|
||||
- U = 1.2D + 1.0W + L（风荷载组合）
|
||||
|
||||
## Seismic Provisions
|
||||
|
||||
ACI 318 Chapter 18 定义了特殊抗弯框架（Special Moment Frames, SMF）、中等抗弯框架（IMF）和普通抗弯框架（Ordinary Moment Frames）的细部构造要求：
|
||||
- **SMF**（ACI 318-19 §18.2–18.9）：梁柱节点区箍筋加密、强柱弱梁设计、钢筋延伸长度 ≥ 1.25Fy d（Flexural Tension）
|
||||
- **ACI 350**：Environmental Engineering Concrete Structures——供水厂、污水处理厂等耐久性要求更高的混凝土结构
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC 引用 ACI 318 作为混凝土结构设计标准，全美 50 个州 + 哥伦比亚特区采纳 IBC
|
||||
- **国际**：美国海外投资项目、海军设施、援建项目通常要求 ACI 318 合规；中东（UAE/沙特）部分项目同时要求 ACI 318 和本地规范
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 ACI 318 进行混凝土设计，计算包必须包含：
|
||||
1. ACI 318 版本年份（如 ACI 318-19）
|
||||
2. 混凝土 fc' 和钢筋 fy 强度值
|
||||
3. 抗弯设计（单筋/双筋/K 法/简化法）
|
||||
4. 抗剪设计（vcu + vsu，双向板冲切验算）
|
||||
5. 抗震细部检查（SMF/IMF 要求）
|
||||
6. 钢筋锚固与搭接长度验算
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：美国钢结构规范——ACI 318 的钢结构对应规范，同属 IBC 引用体系
|
||||
- [[Eurocode]] EN 1992：欧洲混凝土规范——与 ACI 318 并列，但 Eurocode 采用 K 法单筋设计（限制相对受压区高度），ACI 318 采用 φMn ≥ Mu 直接法，两者公式和参数体系不同，不可混用
|
||||
- [[ASCE-7]]：美国荷载规范——ACI 318 的荷载来源规范
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[LRFD]]（荷载抗力系数设计）：ACI 318 的主要设计方法
|
||||
- [[ULS]]（极限状态设计）：ACI 318 Strength Design 的核心哲学——以乘以系数的名义荷载与除以系数的名义抗力比较
|
||||
- [[SLS]]（正常使用极限状态）：ACI 318 在 Appendix B 中定义挠度控制要求（ACI 318-19 §20.3.1）
|
||||
- [[Basis-of-Design]]（设计依据报告）：须记录 ACI 318 版本、fc'/fy、特殊荷载组合及所有偏离默认值的参数
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
---
|
||||
title: "ADK"
|
||||
type: entity
|
||||
tags: [Google, AI, Agent, Development Kit]
|
||||
sources: [google-5个agent-skill设计模式-2026-03-19]
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
Agent Development Kit (ADK) 是 Google Cloud 发布的 Agent 开发工具包，提供了完整的代码示例和 5 种经过验证的 Skill 设计模式。
|
||||
|
||||
## Key Features
|
||||
- **SkillToolset**：支持多个 Skill 组合使用的工具集
|
||||
- **渐进式披露机制**：Agent 只在运行时需要时才消耗上下文 token 加载特定模式
|
||||
- **5 种设计模式**：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline
|
||||
|
||||
## Related Entities
|
||||
- [[GoogleCloud]]：ADK 的发布主体
|
||||
- [[ClaudeCode]]：类似的 Agent 开发工具（Anthropic）
|
||||
- [[SkillToolset]]：ADK 中的 Skill 组合机制
|
||||
|
||||
## Connections
|
||||
- [[Google5个AgentSkill设计模式]] ← documented_in ← [[ADK]]
|
||||
- [[ToolWrapper]] ← part_of ← [[ADK]]
|
||||
- [[Generator]] ← part_of ← [[ADK]]
|
||||
- [[Reviewer]] ← part_of ← [[ADK]]
|
||||
- [[Inversion]] ← part_of ← [[ADK]]
|
||||
- [[Pipeline]] ← part_of ← [[ADK]]
|
||||
---
|
||||
title: "ADK"
|
||||
type: entity
|
||||
tags: [Google, AI, Agent, Development Kit]
|
||||
sources: [google-5个agent-skill设计模式-2026-03-19]
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
Agent Development Kit (ADK) 是 Google Cloud 发布的 Agent 开发工具包，提供了完整的代码示例和 5 种经过验证的 Skill 设计模式。
|
||||
|
||||
## Key Features
|
||||
- **SkillToolset**：支持多个 Skill 组合使用的工具集
|
||||
- **渐进式披露机制**：Agent 只在运行时需要时才消耗上下文 token 加载特定模式
|
||||
- **5 种设计模式**：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline
|
||||
|
||||
## Related Entities
|
||||
- [[GoogleCloud]]：ADK 的发布主体
|
||||
- [[ClaudeCode]]：类似的 Agent 开发工具（Anthropic）
|
||||
- [[SkillToolset]]：ADK 中的 Skill 组合机制
|
||||
|
||||
## Connections
|
||||
- [[Google5个AgentSkill设计模式]] ← documented_in ← [[ADK]]
|
||||
- [[ToolWrapper]] ← part_of ← [[ADK]]
|
||||
- [[Generator]] ← part_of ← [[ADK]]
|
||||
- [[Reviewer]] ← part_of ← [[ADK]]
|
||||
- [[Inversion]] ← part_of ← [[ADK]]
|
||||
- [[Pipeline]] ← part_of ← [[ADK]]
|
||||
|
||||
@@ -1,74 +1,74 @@
|
||||
---
|
||||
title: "AISC 360"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AISC 360-22（当前版本，AISC 360-16 为上一版）
|
||||
- American Institute of Steel Construction Specification
|
||||
- 美国钢结构设计规范
|
||||
- AISC Steel Construction Manual
|
||||
|
||||
## Description
|
||||
|
||||
AISC 360 是美国钢结构设计的权威规范，全称 *Specification for Structural Steel Buildings*，由美国钢结构协会（AISC）发布，被 IBC（国际建筑规范）引用为钢结构设计的核准方法。提供 LRFD（荷载抗力系数设计）和 ASD（容许应力设计）双轨制。
|
||||
|
||||
## Core Content
|
||||
|
||||
- **Chapter A**: General Provisions（总则）
|
||||
- **Chapter B**: Design Requirements（设计要求）
|
||||
- **Chapter C**: Design for Stability（稳定性设计）
|
||||
- **Chapter D**: Design of Members for Tension（轴拉构件）
|
||||
- **Chapter E**: Design of Members for Compression（轴压构件）
|
||||
- **Chapter F**: Design of Members for Flexure（受弯构件）
|
||||
- **Chapter G**: Design of Members for Shear（受剪构件）
|
||||
- **Chapter H**: Design of Members for Combined Forces（组合力构件）
|
||||
- **Chapter I**: Design of Composite Members（组合构件）
|
||||
- **Chapter J**: Design of Connections（连接设计）
|
||||
- **Chapter K**: Design for HSS and Box Members（HSS 和箱形截面）
|
||||
|
||||
## LRFD vs ASD
|
||||
|
||||
| | LRFD | ASD |
|
||||
|--|------|-----|
|
||||
| 设计方法 | 荷载抗力系数设计 | 容许应力设计 |
|
||||
| 荷载系数 | 1.2D + 1.6L（主力） | D + L（容许应力） |
|
||||
| 抗力系数 | φ（< 1.0，如 φ=0.90 抗弯） | Ω（如 Ω=1.67） |
|
||||
| 应用场景 | 新建结构首选 | 抗风/抗震校核、加固改造 |
|
||||
| 关系 | φRn ≥ ΣγiQi | Rn/Ω ≥ ΣQi |
|
||||
|
||||
## Key Provisions
|
||||
|
||||
- **截面分类**（Chapter B）：compact / noncompact / slender 分类决定屈曲验算方法
|
||||
- **直接分析法**（Chapter C）：AISC 360-10 引入，直接考虑几何和残余应力非线性，比有效长度法更精确
|
||||
- **抗震条款**：AISC 341（*Seismic Provisions for Structural Steel Buildings*）提供 SMF/IMF/SCBF/EBF/BRB 抗震体系详细要求
|
||||
- **连接设计**：AISC 358（*Prequalified Connections for Special Moment Frames*）提供预认证连接类型
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC（International Building Code）在全美 50 个州 + 哥伦比亚特区被采纳为建筑法规基准，IBC 引用 AISC 360 作为钢结构设计标准
|
||||
- **国际**：AISC 标准通过美国国际开发署（USAID）项目、全球石油/化工设施、美国跨国公司在海外的建设项目被广泛采用
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 AISC 360 LRFD 进行钢结构设计，计算包必须包含：
|
||||
1. 所引用的 AISC 360 版本年份
|
||||
2. 截面属性（W/HSS/Box 截面型号及牌号 A992/A572 Gr50）
|
||||
3. LRFD 荷载组合及对应的 φ 系数
|
||||
4. 截面 compactness 判定
|
||||
5. 抗弯/抗剪/稳定性验算全过程
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Eurocode]] EN 1993：欧洲钢结构规范——与 AISC 360 并列，但 Eurocode 采用截面分类（Class 1-4）替代 compactness 概念，荷载分项系数体系不同，不可混用
|
||||
- [[ACI-318]]：美国混凝土规范——AISC 360 的混凝土对应规范，同属美国 IBC 引用体系
|
||||
- [[ASCE-7]]：美国荷载规范——AISC 360 的荷载来源规范，风荷载、地震荷载、重力荷载均引用 ASCE 7
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[LRFD]]（荷载抗力系数设计）：AISC 360 的主要设计方法
|
||||
- [[ULS]]（极限状态设计）：AISC 360 LRFD 的设计哲学基础
|
||||
- [[Basis-of-Design]]（设计依据报告）：AISC 360 项目须记录所选用的设计方法（LRFD/ASD）
|
||||
---
|
||||
title: "AISC 360"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AISC 360-22（当前版本，AISC 360-16 为上一版）
|
||||
- American Institute of Steel Construction Specification
|
||||
- 美国钢结构设计规范
|
||||
- AISC Steel Construction Manual
|
||||
|
||||
## Description
|
||||
|
||||
AISC 360 是美国钢结构设计的权威规范，全称 *Specification for Structural Steel Buildings*，由美国钢结构协会（AISC）发布，被 IBC（国际建筑规范）引用为钢结构设计的核准方法。提供 LRFD（荷载抗力系数设计）和 ASD（容许应力设计）双轨制。
|
||||
|
||||
## Core Content
|
||||
|
||||
- **Chapter A**: General Provisions（总则）
|
||||
- **Chapter B**: Design Requirements（设计要求）
|
||||
- **Chapter C**: Design for Stability（稳定性设计）
|
||||
- **Chapter D**: Design of Members for Tension（轴拉构件）
|
||||
- **Chapter E**: Design of Members for Compression（轴压构件）
|
||||
- **Chapter F**: Design of Members for Flexure（受弯构件）
|
||||
- **Chapter G**: Design of Members for Shear（受剪构件）
|
||||
- **Chapter H**: Design of Members for Combined Forces（组合力构件）
|
||||
- **Chapter I**: Design of Composite Members（组合构件）
|
||||
- **Chapter J**: Design of Connections（连接设计）
|
||||
- **Chapter K**: Design for HSS and Box Members（HSS 和箱形截面）
|
||||
|
||||
## LRFD vs ASD
|
||||
|
||||
| | LRFD | ASD |
|
||||
|--|------|-----|
|
||||
| 设计方法 | 荷载抗力系数设计 | 容许应力设计 |
|
||||
| 荷载系数 | 1.2D + 1.6L（主力） | D + L（容许应力） |
|
||||
| 抗力系数 | φ（< 1.0，如 φ=0.90 抗弯） | Ω（如 Ω=1.67） |
|
||||
| 应用场景 | 新建结构首选 | 抗风/抗震校核、加固改造 |
|
||||
| 关系 | φRn ≥ ΣγiQi | Rn/Ω ≥ ΣQi |
|
||||
|
||||
## Key Provisions
|
||||
|
||||
- **截面分类**（Chapter B）：compact / noncompact / slender 分类决定屈曲验算方法
|
||||
- **直接分析法**（Chapter C）：AISC 360-10 引入，直接考虑几何和残余应力非线性，比有效长度法更精确
|
||||
- **抗震条款**：AISC 341（*Seismic Provisions for Structural Steel Buildings*）提供 SMF/IMF/SCBF/EBF/BRB 抗震体系详细要求
|
||||
- **连接设计**：AISC 358（*Prequalified Connections for Special Moment Frames*）提供预认证连接类型
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC（International Building Code）在全美 50 个州 + 哥伦比亚特区被采纳为建筑法规基准，IBC 引用 AISC 360 作为钢结构设计标准
|
||||
- **国际**：AISC 标准通过美国国际开发署（USAID）项目、全球石油/化工设施、美国跨国公司在海外的建设项目被广泛采用
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 AISC 360 LRFD 进行钢结构设计，计算包必须包含：
|
||||
1. 所引用的 AISC 360 版本年份
|
||||
2. 截面属性（W/HSS/Box 截面型号及牌号 A992/A572 Gr50）
|
||||
3. LRFD 荷载组合及对应的 φ 系数
|
||||
4. 截面 compactness 判定
|
||||
5. 抗弯/抗剪/稳定性验算全过程
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Eurocode]] EN 1993：欧洲钢结构规范——与 AISC 360 并列，但 Eurocode 采用截面分类（Class 1-4）替代 compactness 概念，荷载分项系数体系不同，不可混用
|
||||
- [[ACI-318]]：美国混凝土规范——AISC 360 的混凝土对应规范，同属美国 IBC 引用体系
|
||||
- [[ASCE-7]]：美国荷载规范——AISC 360 的荷载来源规范，风荷载、地震荷载、重力荷载均引用 ASCE 7
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[LRFD]]（荷载抗力系数设计）：AISC 360 的主要设计方法
|
||||
- [[ULS]]（极限状态设计）：AISC 360 LRFD 的设计哲学基础
|
||||
- [[Basis-of-Design]]（设计依据报告）：AISC 360 项目须记录所选用的设计方法（LRFD/ASD）
|
||||
|
||||
@@ -1,81 +1,81 @@
|
||||
---
|
||||
title: "ASCE 7"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ASCE 7-22（当前版本，ASCE 7-16 为上一版）
|
||||
- Minimum Design Loads and Associated Criteria for Buildings and Other Structures
|
||||
- 美国建筑结构最小设计荷载规范
|
||||
- ASCE Standard 7
|
||||
|
||||
## Description
|
||||
|
||||
ASCE 7 是美国建筑及其他结构最小设计荷载规范的权威标准，全称 *Minimum Design Loads and Associated Criteria for Buildings and Other Structures*，由美国土木工程师协会（ASCE）发布，被 IBC（International Building Code）引用为所有建筑结构荷载计算的核准方法。涵盖重力荷载、风荷载、地震荷载、雪荷载、雨荷载、温度作用、冲击荷载等。
|
||||
|
||||
## Core Content — Chapters
|
||||
|
||||
| Chapter | 主题 | 核心内容 |
|
||||
|---------|------|---------|
|
||||
| Ch 1 | Scope and General Requirements | 规范范围、荷载分类 |
|
||||
| Ch 2 | Load Combinations | 基于 LRFD 和 ASD 的荷载组合 |
|
||||
| Ch 3 | Dead Loads and Collateral Loads | 恒荷载、固定设备荷载 |
|
||||
| Ch 4 | Live Loads | 楼面活荷载、屋顶活荷载 |
|
||||
| Ch 5 | Flood Loads | 洪水荷载 |
|
||||
| Ch 6 | Reserved | 保留章节 |
|
||||
| Ch 7 | Tsunami Loads | 海啸荷载 |
|
||||
| Ch 8 | Wind Loads | 风荷载——速度压力公式、围护结构/主体结构 |
|
||||
| Ch 9 | Seismic Loads | 地震荷载——反应谱、侧向力法、等效侧向力 |
|
||||
| Ch 10 | Snow Loads | 雪荷载——地面雪荷载、屋面雪荷载 |
|
||||
| Ch 11 | Rain Loads | 雨荷载 |
|
||||
| Ch 12 | Load Combinations for Strength Design (LRFD) | LRFD 荷载组合 |
|
||||
| Ch 13 | Load Combinations for Allowable Stress Design | ASD 荷载组合 |
|
||||
| Ch 26 | Reliability Provisions | 可靠性条款 |
|
||||
|
||||
## Key Methods
|
||||
|
||||
### Wind Load (Chapter 8)
|
||||
- **速度压力公式**：q = 0.613 Kz Kzt Kd V² I（psf，US 单位）
|
||||
- **主建筑系统（Main Wind Force Resisting System）**：建筑整体风荷载
|
||||
- **围护结构（Components & Cladding）**：屋面、墙面、窗户的风荷载
|
||||
- **风压高度变化系数 Kz**：根据地面粗糙度和高度确定
|
||||
- **地形系数 Kzt**：山峰、悬崖等陡峭地形的放大系数
|
||||
- **方向系数 Kd**：风向对不同建筑形状的影响
|
||||
|
||||
### Seismic Load (Chapter 9)
|
||||
- **反应谱分析**：SDS（短周期加速度）、SD1（一秒周期加速度）——从 USGS 地震危害数据库获取
|
||||
- **等效侧向力法**（ELF）：V = Cs W，Cs = SDS / (R/I)
|
||||
- **建筑重要性系数 I**：Occupancy Category I/II/III/IV
|
||||
- **响应修正系数 R**：结构体系延性折减（SMF R=8, SCBF R=6, OMF R=3.5）
|
||||
- **高度限制**：超过 160 ft（~48.8 m）的建筑需进行动态分析
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC 引用 ASCE 7，全美 50 个州 + 哥伦比亚特区采纳 IBC 作为建筑法规基准
|
||||
- **国际**：美国海外投资项目采用 ASCE 7 作为荷载计算标准；部分加勒比海/太平洋岛国（受美国援助影响）也采用 ASCE 7
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 ASCE 7 进行荷载计算，计算包必须包含：
|
||||
1. ASCE 7 版本年份
|
||||
2. 建筑使用类别（Occupancy Category）和重要性系数 I
|
||||
3. 地面粗糙度类别（Exposure B/C/D）
|
||||
4. 基本风速 V（mph）和风向系数 Kd
|
||||
5. 地震参数 SDS、SD1（来自 USGS EHP 或项目地震报告）
|
||||
6. 响应修正系数 R 和结构体系类型
|
||||
7. 所有荷载组合及其对应的抗力系数
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：使用 ASCE 7 的风荷载和地震荷载作为钢结构的输入
|
||||
- [[ACI-318]]：使用 ASCE 7 的荷载组合作为混凝土结构的输入
|
||||
- [[Eurocode]] EN 1991：欧洲作用（荷载）规范——与 ASCE 7 并列，但风荷载谱（孟加拉风谱 vs ASCE 7 对数风谱）、地震反应谱（中国标准 GB 50011 vs ASCE 7）完全不同
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ULS]]（极限状态设计）：ASCE 7 荷载组合服务于 LRFD/SD 极限状态设计
|
||||
- [[LRFD]]（荷载抗力系数设计）：ASCE 7 Chapter 12 定义 LRFD 荷载组合，AISC 360 和 ACI 318 均引用
|
||||
- [[Basis-of-Design]]（设计依据报告）：须记录 ASCE 7 版本、建筑使用类别、基本风速、地震参数、地面粗糙度类别等所有输入
|
||||
---
|
||||
title: "ASCE 7"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ASCE 7-22（当前版本，ASCE 7-16 为上一版）
|
||||
- Minimum Design Loads and Associated Criteria for Buildings and Other Structures
|
||||
- 美国建筑结构最小设计荷载规范
|
||||
- ASCE Standard 7
|
||||
|
||||
## Description
|
||||
|
||||
ASCE 7 是美国建筑及其他结构最小设计荷载规范的权威标准，全称 *Minimum Design Loads and Associated Criteria for Buildings and Other Structures*，由美国土木工程师协会（ASCE）发布，被 IBC（International Building Code）引用为所有建筑结构荷载计算的核准方法。涵盖重力荷载、风荷载、地震荷载、雪荷载、雨荷载、温度作用、冲击荷载等。
|
||||
|
||||
## Core Content — Chapters
|
||||
|
||||
| Chapter | 主题 | 核心内容 |
|
||||
|---------|------|---------|
|
||||
| Ch 1 | Scope and General Requirements | 规范范围、荷载分类 |
|
||||
| Ch 2 | Load Combinations | 基于 LRFD 和 ASD 的荷载组合 |
|
||||
| Ch 3 | Dead Loads and Collateral Loads | 恒荷载、固定设备荷载 |
|
||||
| Ch 4 | Live Loads | 楼面活荷载、屋顶活荷载 |
|
||||
| Ch 5 | Flood Loads | 洪水荷载 |
|
||||
| Ch 6 | Reserved | 保留章节 |
|
||||
| Ch 7 | Tsunami Loads | 海啸荷载 |
|
||||
| Ch 8 | Wind Loads | 风荷载——速度压力公式、围护结构/主体结构 |
|
||||
| Ch 9 | Seismic Loads | 地震荷载——反应谱、侧向力法、等效侧向力 |
|
||||
| Ch 10 | Snow Loads | 雪荷载——地面雪荷载、屋面雪荷载 |
|
||||
| Ch 11 | Rain Loads | 雨荷载 |
|
||||
| Ch 12 | Load Combinations for Strength Design (LRFD) | LRFD 荷载组合 |
|
||||
| Ch 13 | Load Combinations for Allowable Stress Design | ASD 荷载组合 |
|
||||
| Ch 26 | Reliability Provisions | 可靠性条款 |
|
||||
|
||||
## Key Methods
|
||||
|
||||
### Wind Load (Chapter 8)
|
||||
- **速度压力公式**：q = 0.613 Kz Kzt Kd V² I（psf，US 单位）
|
||||
- **主建筑系统（Main Wind Force Resisting System）**：建筑整体风荷载
|
||||
- **围护结构（Components & Cladding）**：屋面、墙面、窗户的风荷载
|
||||
- **风压高度变化系数 Kz**：根据地面粗糙度和高度确定
|
||||
- **地形系数 Kzt**：山峰、悬崖等陡峭地形的放大系数
|
||||
- **方向系数 Kd**：风向对不同建筑形状的影响
|
||||
|
||||
### Seismic Load (Chapter 9)
|
||||
- **反应谱分析**：SDS（短周期加速度）、SD1（一秒周期加速度）——从 USGS 地震危害数据库获取
|
||||
- **等效侧向力法**（ELF）：V = Cs W，Cs = SDS / (R/I)
|
||||
- **建筑重要性系数 I**：Occupancy Category I/II/III/IV
|
||||
- **响应修正系数 R**：结构体系延性折减（SMF R=8, SCBF R=6, OMF R=3.5）
|
||||
- **高度限制**：超过 160 ft（~48.8 m）的建筑需进行动态分析
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **美国**：IBC 引用 ASCE 7，全美 50 个州 + 哥伦比亚特区采纳 IBC 作为建筑法规基准
|
||||
- **国际**：美国海外投资项目采用 ASCE 7 作为荷载计算标准；部分加勒比海/太平洋岛国（受美国援助影响）也采用 ASCE 7
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 ASCE 7 进行荷载计算，计算包必须包含：
|
||||
1. ASCE 7 版本年份
|
||||
2. 建筑使用类别（Occupancy Category）和重要性系数 I
|
||||
3. 地面粗糙度类别（Exposure B/C/D）
|
||||
4. 基本风速 V（mph）和风向系数 Kd
|
||||
5. 地震参数 SDS、SD1（来自 USGS EHP 或项目地震报告）
|
||||
6. 响应修正系数 R 和结构体系类型
|
||||
7. 所有荷载组合及其对应的抗力系数
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：使用 ASCE 7 的风荷载和地震荷载作为钢结构的输入
|
||||
- [[ACI-318]]：使用 ASCE 7 的荷载组合作为混凝土结构的输入
|
||||
- [[Eurocode]] EN 1991：欧洲作用（荷载）规范——与 ASCE 7 并列，但风荷载谱（孟加拉风谱 vs ASCE 7 对数风谱）、地震反应谱（中国标准 GB 50011 vs ASCE 7）完全不同
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ULS]]（极限状态设计）：ASCE 7 荷载组合服务于 LRFD/SD 极限状态设计
|
||||
- [[LRFD]]（荷载抗力系数设计）：ASCE 7 Chapter 12 定义 LRFD 荷载组合，AISC 360 和 ACI 318 均引用
|
||||
- [[Basis-of-Design]]（设计依据报告）：须记录 ASCE 7 版本、建筑使用类别、基本风速、地震参数、地面粗糙度类别等所有输入
|
||||
|
||||
@@ -1,39 +1,39 @@
|
||||
---
|
||||
title: AWS CloudFormation StackSets
|
||||
type: entity
|
||||
tags: [AWS, IaC, Multi-Account, Deployment]
|
||||
date: 2025-10-24
|
||||
---
|
||||
|
||||
## Overview
|
||||
**AWS CloudFormation StackSets** 是 AWS 原生的跨多个 AWS 账户和区域部署和管理 CloudFormation 堆栈的服务。StackSets 扩展了 CloudFormation 的能力，使组织能够在整个 AWS Organization 中一致地部署基础设施，同时保持集中管理和治理。
|
||||
|
||||
## Key Capabilities
|
||||
- **跨账户/跨区域部署**：单次操作同时在多个账户和区域部署
|
||||
- **自动部署（Auto-Deployment）**：新增账户加入组织时自动部署预设 StackSet
|
||||
- **并行区域容错**：配置并发部署区域数量和容错设置
|
||||
- **操作偏好设置**：定义并发限制、容错百分比等操作级参数
|
||||
|
||||
## Architecture Components
|
||||
- **Stack Set**：定义要部署的 CloudFormation 模板和参数
|
||||
- **Stack Instances**：Stack Set 在特定账户/区域的实例
|
||||
- **StackSet Operations**：部署、更新、删除操作的历史记录
|
||||
|
||||
## Related Concepts
|
||||
- [[Multi-Account Deployment]]：StackSets 是多账户部署的核心工具
|
||||
- [[Infrastructure as Code]]：StackSets 扩展了 IaC 的多账户场景
|
||||
- [[StackSets Deployment Visibility]]：StackSets 部署可观测性是该服务的核心运营挑战
|
||||
- [[AWS Organizations]]：StackSets 依赖 Organizations 提供账户层级结构
|
||||
- [[Landing Zone Architecture]]：Landing Zone 推荐使用 StackSets 实现跨账户资源部署
|
||||
- [[GitOps]]：StackSets 可与 GitOps 工作流集成实现声明式部署
|
||||
- [[AWS]]（entity）：StackSets 是 AWS IaC 生态的核心成员
|
||||
|
||||
## Monitoring Integration
|
||||
StackSets 部署通过 EventBridge 事件与 CloudWatch Logs 集成：
|
||||
- EventBridge Rules 捕获 StackSets 操作事件
|
||||
- CloudWatch Logs Insights 提供跨账户部署状态查询
|
||||
- 详见 [[StackSets Deployment Visibility]]
|
||||
|
||||
## Sources
|
||||
- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]]
|
||||
- AWS CloudFormation StackSets 官方文档
|
||||
---
|
||||
title: AWS CloudFormation StackSets
|
||||
type: entity
|
||||
tags: [AWS, IaC, Multi-Account, Deployment]
|
||||
date: 2025-10-24
|
||||
---
|
||||
|
||||
## Overview
|
||||
**AWS CloudFormation StackSets** 是 AWS 原生的跨多个 AWS 账户和区域部署和管理 CloudFormation 堆栈的服务。StackSets 扩展了 CloudFormation 的能力，使组织能够在整个 AWS Organization 中一致地部署基础设施，同时保持集中管理和治理。
|
||||
|
||||
## Key Capabilities
|
||||
- **跨账户/跨区域部署**：单次操作同时在多个账户和区域部署
|
||||
- **自动部署（Auto-Deployment）**：新增账户加入组织时自动部署预设 StackSet
|
||||
- **并行区域容错**：配置并发部署区域数量和容错设置
|
||||
- **操作偏好设置**：定义并发限制、容错百分比等操作级参数
|
||||
|
||||
## Architecture Components
|
||||
- **Stack Set**：定义要部署的 CloudFormation 模板和参数
|
||||
- **Stack Instances**：Stack Set 在特定账户/区域的实例
|
||||
- **StackSet Operations**：部署、更新、删除操作的历史记录
|
||||
|
||||
## Related Concepts
|
||||
- [[Multi-Account Deployment]]：StackSets 是多账户部署的核心工具
|
||||
- [[Infrastructure as Code]]：StackSets 扩展了 IaC 的多账户场景
|
||||
- [[StackSets Deployment Visibility]]：StackSets 部署可观测性是该服务的核心运营挑战
|
||||
- [[AWS Organizations]]：StackSets 依赖 Organizations 提供账户层级结构
|
||||
- [[Landing Zone Architecture]]：Landing Zone 推荐使用 StackSets 实现跨账户资源部署
|
||||
- [[GitOps]]：StackSets 可与 GitOps 工作流集成实现声明式部署
|
||||
- [[AWS]]（entity）：StackSets 是 AWS IaC 生态的核心成员
|
||||
|
||||
## Monitoring Integration
|
||||
StackSets 部署通过 EventBridge 事件与 CloudWatch Logs 集成：
|
||||
- EventBridge Rules 捕获 StackSets 操作事件
|
||||
- CloudWatch Logs Insights 提供跨账户部署状态查询
|
||||
- 详见 [[StackSets Deployment Visibility]]
|
||||
|
||||
## Sources
|
||||
- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]]
|
||||
- AWS CloudFormation StackSets 官方文档
|
||||
|
||||
@@ -1,78 +1,78 @@
|
||||
---
|
||||
title: "AWS Lambda"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- Compute
|
||||
- Lambda
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Lambda
|
||||
- AWS Lambda
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Lambda 是 AWS 的无服务器（Serverless）计算服务——开发者只需编写业务逻辑函数（Handler），AWS 负责所有底层运维：负载均衡、自动扩展、安全补丁和容量管理。Lambda 函数由事件（event）触发，事件即云资源状态的任何变化。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| 触发模式 | 同步调用、异步调用、事件源映射 |
|
||||
| 权限模型 | 执行角色（Execution Role）+ 资源策略（Resource-Based Policy） |
|
||||
| 代码管理 | 版本（Version）、别名（Alias）、Layers（共享公共依赖） |
|
||||
| 架构支持 | x86 和 ARM64（ARM64 提供更优性价比） |
|
||||
| 监控 | CloudWatch 指标（请求数、错误数、延迟、节流） |
|
||||
| 调试工具 | Amazon Q（集成 AI 辅助调试） |
|
||||
| 性能调优 | Lambda Power Tuning（比较不同配置的性能和成本） |
|
||||
|
||||
## Lambda Handler 模式
|
||||
|
||||
Lambda 函数接收三个核心参数：
|
||||
|
||||
1. **Handler** — 入口函数，事件触发时执行
|
||||
2. **Event Object** — 触发事件的数据结构（API Gateway 请求、S3 对象变更等）
|
||||
3. **Context Object** — 运行时信息（超时设置、内存限制、日志句柄等）
|
||||
|
||||
## Invocation Patterns
|
||||
|
||||
- **同步调用（Synchronous）**：调用方等待响应，如 API Gateway → Lambda
|
||||
- **异步调用（Asynchronous）**：Lambda 自动处理重试（最多 2 次），如 S3 事件 → Lambda
|
||||
- **事件源映射（Event Source Mapping）**：Lambda 轮询流式服务（Kinesis、DynamoDB Stream、SQS）批量处理记录
|
||||
|
||||
## Permissions Model
|
||||
|
||||
Lambda 权限模型基于 IAM 的最小权限原则：
|
||||
|
||||
| 权限类型 | 作用对象 | 说明 |
|
||||
|---------|---------|------|
|
||||
| Execution Role | Lambda 函数 | 定义函数能调用哪些 AWS 资源和服务 |
|
||||
| Resource-Based Policy | 其他 AWS 账号/服务 | 定义谁能/什么能触发该 Lambda 函数 |
|
||||
|
||||
## Lambda Layers
|
||||
|
||||
Lambda Layers 允许跨多个 Lambda 函数共享公共代码和依赖：
|
||||
- 运行时环境（如 Python boto3 库）
|
||||
- 自定义运行时
|
||||
- 配置和脚本
|
||||
|
||||
Layers 避免了每个函数重复打包相同依赖，减少部署包大小和更新成本。
|
||||
|
||||
## Connections
|
||||
- [[Serverless-Computing]] ← is_core_service_of ← [[AWS-Lambda]]
|
||||
- [[AWS-Lambda]] ← triggered_by ← [[Amazon-EventBridge]]
|
||||
- [[AWS-Lambda]] ← exposed_via ← [[Amazon-API-Gateway]]
|
||||
- [[AWS-Lambda]] ← orchestrated_by ← [[AWS-Step-Functions]]
|
||||
- [[AWS-Lambda]] ← monitored_by ← [[CloudWatch]]
|
||||
- [[SAM-Serverless-Application-Model]] ← deploys ← [[AWS-Lambda]]
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-API-Gateway]] — Lambda 的 API 暴露层
|
||||
- [[AWS-Step-Functions]] — Lambda 的工作流编排层
|
||||
- [[Amazon-EventBridge]] — Lambda 的事件驱动触发源
|
||||
- [[CloudWatch]] — Lambda 的监控和日志层
|
||||
---
|
||||
title: "AWS Lambda"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- Compute
|
||||
- Lambda
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Lambda
|
||||
- AWS Lambda
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Lambda 是 AWS 的无服务器（Serverless）计算服务——开发者只需编写业务逻辑函数（Handler），AWS 负责所有底层运维：负载均衡、自动扩展、安全补丁和容量管理。Lambda 函数由事件（event）触发，事件即云资源状态的任何变化。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| 触发模式 | 同步调用、异步调用、事件源映射 |
|
||||
| 权限模型 | 执行角色（Execution Role）+ 资源策略（Resource-Based Policy） |
|
||||
| 代码管理 | 版本（Version）、别名（Alias）、Layers（共享公共依赖） |
|
||||
| 架构支持 | x86 和 ARM64（ARM64 提供更优性价比） |
|
||||
| 监控 | CloudWatch 指标（请求数、错误数、延迟、节流） |
|
||||
| 调试工具 | Amazon Q（集成 AI 辅助调试） |
|
||||
| 性能调优 | Lambda Power Tuning（比较不同配置的性能和成本） |
|
||||
|
||||
## Lambda Handler 模式
|
||||
|
||||
Lambda 函数接收三个核心参数：
|
||||
|
||||
1. **Handler** — 入口函数，事件触发时执行
|
||||
2. **Event Object** — 触发事件的数据结构（API Gateway 请求、S3 对象变更等）
|
||||
3. **Context Object** — 运行时信息（超时设置、内存限制、日志句柄等）
|
||||
|
||||
## Invocation Patterns
|
||||
|
||||
- **同步调用（Synchronous）**：调用方等待响应，如 API Gateway → Lambda
|
||||
- **异步调用（Asynchronous）**：Lambda 自动处理重试（最多 2 次），如 S3 事件 → Lambda
|
||||
- **事件源映射（Event Source Mapping）**：Lambda 轮询流式服务（Kinesis、DynamoDB Stream、SQS）批量处理记录
|
||||
|
||||
## Permissions Model
|
||||
|
||||
Lambda 权限模型基于 IAM 的最小权限原则：
|
||||
|
||||
| 权限类型 | 作用对象 | 说明 |
|
||||
|---------|---------|------|
|
||||
| Execution Role | Lambda 函数 | 定义函数能调用哪些 AWS 资源和服务 |
|
||||
| Resource-Based Policy | 其他 AWS 账号/服务 | 定义谁能/什么能触发该 Lambda 函数 |
|
||||
|
||||
## Lambda Layers
|
||||
|
||||
Lambda Layers 允许跨多个 Lambda 函数共享公共代码和依赖：
|
||||
- 运行时环境（如 Python boto3 库）
|
||||
- 自定义运行时
|
||||
- 配置和脚本
|
||||
|
||||
Layers 避免了每个函数重复打包相同依赖，减少部署包大小和更新成本。
|
||||
|
||||
## Connections
|
||||
- [[Serverless-Computing]] ← is_core_service_of ← [[AWS-Lambda]]
|
||||
- [[AWS-Lambda]] ← triggered_by ← [[Amazon-EventBridge]]
|
||||
- [[AWS-Lambda]] ← exposed_via ← [[Amazon-API-Gateway]]
|
||||
- [[AWS-Lambda]] ← orchestrated_by ← [[AWS-Step-Functions]]
|
||||
- [[AWS-Lambda]] ← monitored_by ← [[CloudWatch]]
|
||||
- [[SAM-Serverless-Application-Model]] ← deploys ← [[AWS-Lambda]]
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-API-Gateway]] — Lambda 的 API 暴露层
|
||||
- [[AWS-Step-Functions]] — Lambda 的工作流编排层
|
||||
- [[Amazon-EventBridge]] — Lambda 的事件驱动触发源
|
||||
- [[CloudWatch]] — Lambda 的监控和日志层
|
||||
|
||||
@@ -1,55 +1,55 @@
|
||||
---
|
||||
title: "AWS OpenSearch"
|
||||
type: entity
|
||||
entity_type: Product
|
||||
tags: [AWS, Database, Observability, Logging, OpenSource]
|
||||
sources: [ctp-topic-54-esm-saas-log-analytics]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
# AWS OpenSearch
|
||||
|
||||
**AWS OpenSearch** 是 AWS 提供的托管式 OpenSearch 服务，是 Elasticsearch 的开源分支（基于 Elasticsearch 7.10.2）的 AWS 托管版本，提供全文搜索和日志分析能力。
|
||||
|
||||
## Overview
|
||||
|
||||
OpenSearch 起源于 Elasticsearch 与 HashiCorp 之间的许可证变更（2021 年），AWS 创建了 OpenSearch 作为 Elasticsearch 的开源替代，并将其作为托管服务提供（Amazon OpenSearch Service）。
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
| Attribute | Value |
|
||||
|-----------|-------|
|
||||
| **Type** | 托管式分布式搜索和日志分析引擎 |
|
||||
| **License** | Apache 2.0 |
|
||||
| **Origin** | Elasticsearch 7.10.2 分支，AWS 主导 |
|
||||
| **API Compatibility** | 与 Elasticsearch OSS 7.x API 兼容 |
|
||||
| **Managed Service** | Amazon OpenSearch Service (Serverless / Standard) |
|
||||
|
||||
## Cost Comparison (per Month)
|
||||
|
||||
基于单农场、14天数据保留、每日处理 100GB 的估算：
|
||||
|
||||
| Solution | Estimated Cost | SLA | Notes |
|
||||
|----------|---------------|-----|-------|
|
||||
| **AWS OpenSearch** | ~$1,500 | 99.9% | 推荐方案，含自动快照 DR |
|
||||
| **Logz.io** | ~$4,000 | 99.8% | 托管 ELK 方案 |
|
||||
| **Self-hosted ELK** | 很低 | 视自建方案 | 成本低但维护复杂 |
|
||||
| **Microfocus OBA** | 商业版 | 商业支持 | 更成熟，支持列级访问控制 |
|
||||
|
||||
## Key Claims
|
||||
|
||||
- AWS OpenSearch 相比 Logz.io 成本降低约 60%（$1,500 vs $4,000/月）
|
||||
- AWS OpenSearch 提供 99.9% SLA，高于 Logz.io 的 99.8%
|
||||
- AWS OpenSearch 内置自动快照（Automated Snapshots），开箱即用的 DR 能力
|
||||
- OpenSearch 是 Elasticsearch 的开源分支，API 兼容，无需大规模代码改动即可迁移
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ELK-Stack]]：OpenSearch 是 ELK 栈中 Elasticsearch 的开源替代
|
||||
- [[Elasticsearch]]：OpenSearch 的上游来源
|
||||
- [[Kibana]]：OpenSearch 的官方可视化前端（OpenSearch Dashboards）
|
||||
- [[AWS-Landing-Zone]]：OpenSearch 常作为 Landing Zone 日志账户的核心组件
|
||||
|
||||
## Sources
|
||||
|
||||
- [[ctp-topic-54-esm-saas-log-analytics]]
|
||||
---
|
||||
title: "AWS OpenSearch"
|
||||
type: entity
|
||||
entity_type: Product
|
||||
tags: [AWS, Database, Observability, Logging, OpenSource]
|
||||
sources: [ctp-topic-54-esm-saas-log-analytics]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
# AWS OpenSearch
|
||||
|
||||
**AWS OpenSearch** 是 AWS 提供的托管式 OpenSearch 服务，是 Elasticsearch 的开源分支（基于 Elasticsearch 7.10.2）的 AWS 托管版本，提供全文搜索和日志分析能力。
|
||||
|
||||
## Overview
|
||||
|
||||
OpenSearch 起源于 Elasticsearch 与 HashiCorp 之间的许可证变更（2021 年），AWS 创建了 OpenSearch 作为 Elasticsearch 的开源替代，并将其作为托管服务提供（Amazon OpenSearch Service）。
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
| Attribute | Value |
|
||||
|-----------|-------|
|
||||
| **Type** | 托管式分布式搜索和日志分析引擎 |
|
||||
| **License** | Apache 2.0 |
|
||||
| **Origin** | Elasticsearch 7.10.2 分支，AWS 主导 |
|
||||
| **API Compatibility** | 与 Elasticsearch OSS 7.x API 兼容 |
|
||||
| **Managed Service** | Amazon OpenSearch Service (Serverless / Standard) |
|
||||
|
||||
## Cost Comparison (per Month)
|
||||
|
||||
基于单农场、14天数据保留、每日处理 100GB 的估算：
|
||||
|
||||
| Solution | Estimated Cost | SLA | Notes |
|
||||
|----------|---------------|-----|-------|
|
||||
| **AWS OpenSearch** | ~$1,500 | 99.9% | 推荐方案，含自动快照 DR |
|
||||
| **Logz.io** | ~$4,000 | 99.8% | 托管 ELK 方案 |
|
||||
| **Self-hosted ELK** | 很低 | 视自建方案 | 成本低但维护复杂 |
|
||||
| **Microfocus OBA** | 商业版 | 商业支持 | 更成熟，支持列级访问控制 |
|
||||
|
||||
## Key Claims
|
||||
|
||||
- AWS OpenSearch 相比 Logz.io 成本降低约 60%（$1,500 vs $4,000/月）
|
||||
- AWS OpenSearch 提供 99.9% SLA，高于 Logz.io 的 99.8%
|
||||
- AWS OpenSearch 内置自动快照（Automated Snapshots），开箱即用的 DR 能力
|
||||
- OpenSearch 是 Elasticsearch 的开源分支，API 兼容，无需大规模代码改动即可迁移
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ELK-Stack]]：OpenSearch 是 ELK 栈中 Elasticsearch 的开源替代
|
||||
- [[Elasticsearch]]：OpenSearch 的上游来源
|
||||
- [[Kibana]]：OpenSearch 的官方可视化前端（OpenSearch Dashboards）
|
||||
- [[AWS-Landing-Zone]]：OpenSearch 常作为 Landing Zone 日志账户的核心组件
|
||||
|
||||
## Sources
|
||||
|
||||
- [[ctp-topic-54-esm-saas-log-analytics]]
|
||||
|
||||
@@ -1,46 +1,46 @@
|
||||
---
|
||||
title: AWS Organizations
|
||||
type: entity
|
||||
tags: [AWS, Multi-Account, Security, Governance]
|
||||
date: 2025-10-24
|
||||
---
|
||||
|
||||
## Overview
|
||||
**AWS Organizations** 是 AWS 的账户管理服务，使组织能够创建和管理多个 AWS 账户，实现集中化的安全策略、成本管理和运维治理。AWS Organizations 是 AWS 多账户策略的基础设施，也是 CloudFormation StackSets 跨账户部署的前提条件。
|
||||
|
||||
## Key Capabilities
|
||||
- **Organization**：组织根节点，管理整个组织的策略和成员
|
||||
- **Organizational Units (OUs)**：组织单元，分组管理多个账户
|
||||
- **Member Accounts**：成员账户，受组织策略约束的工作负载账户
|
||||
- **Management Account**：管理账户，组织的管理平面，承载集中监控和计费
|
||||
- **Service Control Policies (SCPs)**：服务控制策略，定义 OU/账户级别的权限边界
|
||||
- **Trusted Access**：受信任访问，允许 AWS 服务在成员账户中执行操作
|
||||
|
||||
## In This Solution
|
||||
AWS Organizations 在多账户 CloudFormation StackSets 监控方案中的角色：
|
||||
1. **账户层级结构**：提供管理账户和成员账户的层级关系
|
||||
2. **OU 范围界定**：StackSets 通过 OU ID 指定部署范围，一次性部署 EventBridge 规则到所有成员账户
|
||||
3. **Organization ID**：用于配置跨账户 IAM 权限
|
||||
4. **Trusted Access**：必须启用 CloudFormation StackSets 的受信任访问才能跨账户操作
|
||||
|
||||
## Prerequisites for StackSets
|
||||
- AWS Organization with Management Account
|
||||
- Member Accounts under OU(s)
|
||||
- Trusted Access enabled for CloudFormation StackSets
|
||||
- IAM permissions to create StackSets from Management Account
|
||||
|
||||
## Related Concepts
|
||||
- [[Multi-Account Deployment]]：Organizations 提供多账户部署的账户基础设施
|
||||
- [[Cross-Account Monitoring]]：Organizations 支撑跨账户监控的权限和账户模型
|
||||
- [[Landing Zone Architecture]]：AWS Landing Zone 架构基于 Organizations 构建
|
||||
- [[AWS CloudFormation StackSets]]：依赖 Organizations 提供账户层级和受信任访问
|
||||
- [[Centralized Logging]]：Organizations 支撑集中日志的账户范围配置
|
||||
- [[DevOps Culture]]：Organizations 的 SCPs 是 DevSecOps 治理的基础
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]（entity）：Organizations 是 AWS 账户管理服务的核心成员
|
||||
- [[AWS CloudFormation StackSets]]：依赖 Organizations 的账户层级结构
|
||||
|
||||
## Sources
|
||||
- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]]
|
||||
- AWS Organizations 官方文档
|
||||
---
|
||||
title: AWS Organizations
|
||||
type: entity
|
||||
tags: [AWS, Multi-Account, Security, Governance]
|
||||
date: 2025-10-24
|
||||
---
|
||||
|
||||
## Overview
|
||||
**AWS Organizations** 是 AWS 的账户管理服务，使组织能够创建和管理多个 AWS 账户，实现集中化的安全策略、成本管理和运维治理。AWS Organizations 是 AWS 多账户策略的基础设施，也是 CloudFormation StackSets 跨账户部署的前提条件。
|
||||
|
||||
## Key Capabilities
|
||||
- **Organization**：组织根节点，管理整个组织的策略和成员
|
||||
- **Organizational Units (OUs)**：组织单元，分组管理多个账户
|
||||
- **Member Accounts**：成员账户，受组织策略约束的工作负载账户
|
||||
- **Management Account**：管理账户，组织的管理平面，承载集中监控和计费
|
||||
- **Service Control Policies (SCPs)**：服务控制策略，定义 OU/账户级别的权限边界
|
||||
- **Trusted Access**：受信任访问，允许 AWS 服务在成员账户中执行操作
|
||||
|
||||
## In This Solution
|
||||
AWS Organizations 在多账户 CloudFormation StackSets 监控方案中的角色：
|
||||
1. **账户层级结构**：提供管理账户和成员账户的层级关系
|
||||
2. **OU 范围界定**：StackSets 通过 OU ID 指定部署范围，一次性部署 EventBridge 规则到所有成员账户
|
||||
3. **Organization ID**：用于配置跨账户 IAM 权限
|
||||
4. **Trusted Access**：必须启用 CloudFormation StackSets 的受信任访问才能跨账户操作
|
||||
|
||||
## Prerequisites for StackSets
|
||||
- AWS Organization with Management Account
|
||||
- Member Accounts under OU(s)
|
||||
- Trusted Access enabled for CloudFormation StackSets
|
||||
- IAM permissions to create StackSets from Management Account
|
||||
|
||||
## Related Concepts
|
||||
- [[Multi-Account Deployment]]：Organizations 提供多账户部署的账户基础设施
|
||||
- [[Cross-Account Monitoring]]：Organizations 支撑跨账户监控的权限和账户模型
|
||||
- [[Landing Zone Architecture]]：AWS Landing Zone 架构基于 Organizations 构建
|
||||
- [[AWS CloudFormation StackSets]]：依赖 Organizations 提供账户层级和受信任访问
|
||||
- [[Centralized Logging]]：Organizations 支撑集中日志的账户范围配置
|
||||
- [[DevOps Culture]]：Organizations 的 SCPs 是 DevSecOps 治理的基础
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]（entity）：Organizations 是 AWS 账户管理服务的核心成员
|
||||
- [[AWS CloudFormation StackSets]]：依赖 Organizations 的账户层级结构
|
||||
|
||||
## Sources
|
||||
- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]]
|
||||
- AWS Organizations 官方文档
|
||||
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "AWS Step Functions"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- Workflow
|
||||
- Orchestration
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Step Functions
|
||||
- AWS Step Functions
|
||||
- Amazon Step Functions
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Step Functions 是 AWS 的无服务器工作流编排服务，基于状态机（State Machine）协调多个 Lambda 函数和 AWS 服务的执行顺序和错误处理逻辑，使开发者无需编写复杂的编排代码即可构建可靠的多步骤业务流程。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| 核心抽象 | 状态机（Standard 和 Express 两种） |
|
||||
| Standard 工作流 | 长时运行，最长 1 年，支持精确执行历史 |
|
||||
| Express 工作流 | 高频场景，最长 5 分钟，支持极高吞吐量 |
|
||||
| 状态类型 | Task、Choice、Wait、Pass、Parallel、Map、End、Throw |
|
||||
| 错误处理 | 内置 Retry、Catch 和 Error 字段 |
|
||||
| 可视化 | 自动生成工作流图形，直观展示执行路径 |
|
||||
|
||||
## Workflow Flavors
|
||||
|
||||
| 类型 | 适用场景 | 执行时长 | 计费模式 |
|
||||
|------|---------|---------|---------|
|
||||
| Standard | 长时业务流程、审批流、数据处理管道 | 最长 1 年 | 按状态转换计费 |
|
||||
| Express | 高频事件处理、IoT 数据流水线、实时流处理 | 最长 5 分钟 | 按执行次数+GB/s计费 |
|
||||
|
||||
## State Types
|
||||
|
||||
Step Functions 提供丰富的状态类型构建复杂工作流：
|
||||
|
||||
- **Task**：执行单个原子工作单元（如调用 Lambda、DynamoDB 操作）
|
||||
- **Choice**：条件分支，基于数据动态路由执行路径
|
||||
- **Wait**：等待指定时间（用于轮询、重试间隔）
|
||||
- **Pass**：直接传递输入到输出（数据转换）
|
||||
- **Parallel**：并行执行多个分支，汇合结果
|
||||
- **Map**：迭代处理数组中的每个元素
|
||||
- **End/Try-Throw**：终止和错误处理
|
||||
|
||||
## Connections
|
||||
- [[AWS-Step-Functions]] ← orchestrates ← [[AWS-Lambda]]
|
||||
- [[AWS-Step-Functions]] ← is_a ← [[Serverless-Computing]]
|
||||
- [[AWS-Step-Functions]] ← triggers ← [[Amazon-EventBridge]]
|
||||
---
|
||||
title: "AWS Step Functions"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- Workflow
|
||||
- Orchestration
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Step Functions
|
||||
- AWS Step Functions
|
||||
- Amazon Step Functions
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Step Functions 是 AWS 的无服务器工作流编排服务，基于状态机（State Machine）协调多个 Lambda 函数和 AWS 服务的执行顺序和错误处理逻辑，使开发者无需编写复杂的编排代码即可构建可靠的多步骤业务流程。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| 核心抽象 | 状态机（Standard 和 Express 两种） |
|
||||
| Standard 工作流 | 长时运行，最长 1 年，支持精确执行历史 |
|
||||
| Express 工作流 | 高频场景，最长 5 分钟，支持极高吞吐量 |
|
||||
| 状态类型 | Task、Choice、Wait、Pass、Parallel、Map、End、Throw |
|
||||
| 错误处理 | 内置 Retry、Catch 和 Error 字段 |
|
||||
| 可视化 | 自动生成工作流图形，直观展示执行路径 |
|
||||
|
||||
## Workflow Flavors
|
||||
|
||||
| 类型 | 适用场景 | 执行时长 | 计费模式 |
|
||||
|------|---------|---------|---------|
|
||||
| Standard | 长时业务流程、审批流、数据处理管道 | 最长 1 年 | 按状态转换计费 |
|
||||
| Express | 高频事件处理、IoT 数据流水线、实时流处理 | 最长 5 分钟 | 按执行次数+GB/s计费 |
|
||||
|
||||
## State Types
|
||||
|
||||
Step Functions 提供丰富的状态类型构建复杂工作流：
|
||||
|
||||
- **Task**：执行单个原子工作单元（如调用 Lambda、DynamoDB 操作）
|
||||
- **Choice**：条件分支，基于数据动态路由执行路径
|
||||
- **Wait**：等待指定时间（用于轮询、重试间隔）
|
||||
- **Pass**：直接传递输入到输出（数据转换）
|
||||
- **Parallel**：并行执行多个分支，汇合结果
|
||||
- **Map**：迭代处理数组中的每个元素
|
||||
- **End/Try-Throw**：终止和错误处理
|
||||
|
||||
## Connections
|
||||
- [[AWS-Step-Functions]] ← orchestrates ← [[AWS-Lambda]]
|
||||
- [[AWS-Step-Functions]] ← is_a ← [[Serverless-Computing]]
|
||||
- [[AWS-Step-Functions]] ← triggers ← [[Amazon-EventBridge]]
|
||||
|
||||
@@ -1,34 +1,34 @@
|
||||
---
|
||||
title: "Amazon Web Services (AWS)"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Cloud
|
||||
- Hybrid-Cloud
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Amazon Web Services (AWS)
|
||||
|
||||
Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally.
|
||||
|
||||
## Aliases
|
||||
- AWS
|
||||
- Amazon Web Services
|
||||
|
||||
## Key Partnerships
|
||||
- **VMware Cloud on AWS (VMC on AWS)**: AWS partnered with VMware to run VMware workloads natively on AWS infrastructure. The underlying hardware consists of i3.metal and i3en.metal bare metal servers, organized into clusters within availability zones and regions.
|
||||
|
||||
## Infrastructure for VMC on AWS
|
||||
- **i3.metal**: Bare metal server instance used for VMware Cloud on AWS SDDC deployment
|
||||
- **i3en.metal**: Enhanced bare metal instance with larger storage capacity
|
||||
- **Clusters**: Organized within availability zones and regions globally
|
||||
- **Stretched Clusters**: Available across availability zones for increased resilience
|
||||
|
||||
## Connections
|
||||
- [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]]
|
||||
- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]]
|
||||
- [[VMware]] ← partners ← [[AWS]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-43-vmware-cloud-on-aws]]
|
||||
---
|
||||
title: "Amazon Web Services (AWS)"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Cloud
|
||||
- Hybrid-Cloud
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Amazon Web Services (AWS)
|
||||
|
||||
Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally.
|
||||
|
||||
## Aliases
|
||||
- AWS
|
||||
- Amazon Web Services
|
||||
|
||||
## Key Partnerships
|
||||
- **VMware Cloud on AWS (VMC on AWS)**: AWS partnered with VMware to run VMware workloads natively on AWS infrastructure. The underlying hardware consists of i3.metal and i3en.metal bare metal servers, organized into clusters within availability zones and regions.
|
||||
|
||||
## Infrastructure for VMC on AWS
|
||||
- **i3.metal**: Bare metal server instance used for VMware Cloud on AWS SDDC deployment
|
||||
- **i3en.metal**: Enhanced bare metal instance with larger storage capacity
|
||||
- **Clusters**: Organized within availability zones and regions globally
|
||||
- **Stretched Clusters**: Available across availability zones for increased resilience
|
||||
|
||||
## Connections
|
||||
- [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]]
|
||||
- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]]
|
||||
- [[VMware]] ← partners ← [[AWS]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-43-vmware-cloud-on-aws]]
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: "Acemoglu"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **全名**：Daron Acemoglu
|
||||
- **领域**：制度经济学、政治经济学、发展经济学
|
||||
- **机构**：MIT 经济学教授
|
||||
- **代表著作**：《国家为什么会失败》（*Why Nations Fail*, 2012，与 James A. Robinson 合著）
|
||||
|
||||
## 核心观点
|
||||
- **制度作为经济发展的关键**：包容性制度（inclusive institutions）和汲取性制度（extractive institutions）是国家繁荣与否的根本原因
|
||||
- **批评地理决定论**：认为 Diamond 等学者的地理决定论夸大了地理因素的作用，制度因素更为重要
|
||||
- **技术进步与政治博弈**：技术变革虽具有普遍性，但其收益分配取决于政治制度
|
||||
|
||||
## 被引用方式
|
||||
在 [[academic-geographer]] 中，Acemoglu 作为批评[[Jared Diamond]]地理框架的学者被引用，用于平衡[[Environmental Determinism]]——提醒 Agent 避免走向极端地理决定论，承认人类能动性和制度因素的重要性。
|
||||
|
||||
## 来源
|
||||
- [[academic-geographer]]
|
||||
---
|
||||
title: "Acemoglu"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **全名**：Daron Acemoglu
|
||||
- **领域**：制度经济学、政治经济学、发展经济学
|
||||
- **机构**：MIT 经济学教授
|
||||
- **代表著作**：《国家为什么会失败》（*Why Nations Fail*, 2012，与 James A. Robinson 合著）
|
||||
|
||||
## 核心观点
|
||||
- **制度作为经济发展的关键**：包容性制度（inclusive institutions）和汲取性制度（extractive institutions）是国家繁荣与否的根本原因
|
||||
- **批评地理决定论**：认为 Diamond 等学者的地理决定论夸大了地理因素的作用，制度因素更为重要
|
||||
- **技术进步与政治博弈**：技术变革虽具有普遍性，但其收益分配取决于政治制度
|
||||
|
||||
## 被引用方式
|
||||
在 [[academic-geographer]] 中，Acemoglu 作为批评[[Jared Diamond]]地理框架的学者被引用，用于平衡[[Environmental Determinism]]——提醒 Agent 避免走向极端地理决定论，承认人类能动性和制度因素的重要性。
|
||||
|
||||
## 来源
|
||||
- [[academic-geographer]]
|
||||
|
||||
@@ -1,80 +1,80 @@
|
||||
---
|
||||
title: "Acronis"
|
||||
type: entity
|
||||
aliases: [Acronis Cyber Protect]
|
||||
tags: [cloud, disaster-recovery, backup, security, enterprise, infrastructure]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
# Acronis
|
||||
|
||||
**Acronis** 是一个融合数据保护和网络安全的一体化平台，提供跨区域复制、备份和灾难恢复能力，是传统灾备工具的代表。
|
||||
|
||||
## Overview
|
||||
|
||||
Acronis 提供：
|
||||
|
||||
- **跨区域复制**：异地数据复制
|
||||
- **备份解决方案**：文件、系统、虚拟机备份
|
||||
- **灾难恢复**：BC/DR 规划工具
|
||||
- **网络安全**：防恶意软件、防勒索
|
||||
- **云原生集成**：AWS、Azure、GCP
|
||||
|
||||
## 定位：传统灾备 + 安全
|
||||
|
||||
Acronis 与 [[Veeam]] 类似，代表传统灾备思路，但其融合了网络安全功能（Acronis Cyber Protect）。
|
||||
|
||||
| 维度 | Acronis（传统） | [[Feature Flag]]（现代） |
|
||||
|------|-----------------|------------------------|
|
||||
| 保护对象 | 基础设施、数据 | 代码、功能、部署 |
|
||||
| 故障类型 | 硬件故障、勒索软件 | 代码变更、Bug |
|
||||
| RTO | 小时级（从备份恢复） | 秒级（配置变更） |
|
||||
| 故障频率 | 低 | 高（每周可能发生） |
|
||||
| 安全集成 | 有（Acronis Cyber Protect） | 无（专注于代码层） |
|
||||
|
||||
## 与 [[RTO]]/[[RPO]] 的关系
|
||||
|
||||
Acronis 优化的是基础设施级别的 RTO 和 RPO：
|
||||
|
||||
| 场景 | RTO | RPO | 说明 |
|
||||
|------|-----|-----|------|
|
||||
| 从 Acronis 备份恢复 | 小时级 | 取决于备份频率 | 需要重建基础设施 |
|
||||
| 跨区域复制恢复 | 分钟级 | 取决于复制频率 | 数据已预复制到异地 |
|
||||
| Acronis 即时恢复 | 分钟级 | 小时级 | 仍然需要恢复数据 |
|
||||
|
||||
## 典型部署场景
|
||||
|
||||
- **硬件故障**：服务器损坏后的快速恢复
|
||||
- **勒索软件防护**：Acronis Cyber Protect 提供勒索软件防御和恢复
|
||||
- **跨数据中心灾备**：异地数据复制
|
||||
- **合规数据保留**：长期归档和保留
|
||||
|
||||
## 竞品
|
||||
|
||||
| 工具 | 定位 |
|
||||
|------|------|
|
||||
| Acronis | 数据保护 + 网络安全 |
|
||||
| [[Veeam]] | 企业级虚拟机备份 |
|
||||
| Rubrik | 云原生数据保护 |
|
||||
| Commvault | 企业数据管理 |
|
||||
|
||||
## 局限性
|
||||
|
||||
与 Veeam 类似，Acronis 无法解决**软件层面的问题**：
|
||||
|
||||
- 无法防止 Bug 部署
|
||||
- 无法实现 Feature Flag 级别的快速回滚
|
||||
- 无法支持渐进放量
|
||||
- 灾备触发频率低，无法应对日常代码变更风险
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Disaster Recovery]] — Acronis 是传统灾备工具
|
||||
- [[RTO]] — Acronis 优化基础设施级 RTO
|
||||
- [[RPO]] — Acronis 优化数据保护级 RPO
|
||||
- [[Veeam]] — 竞品灾备工具
|
||||
- [[LaunchDarkly]] — 代表现代软件层灾备方案
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
|
||||
---
|
||||
title: "Acronis"
|
||||
type: entity
|
||||
aliases: [Acronis Cyber Protect]
|
||||
tags: [cloud, disaster-recovery, backup, security, enterprise, infrastructure]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
# Acronis
|
||||
|
||||
**Acronis** 是一个融合数据保护和网络安全的一体化平台，提供跨区域复制、备份和灾难恢复能力，是传统灾备工具的代表。
|
||||
|
||||
## Overview
|
||||
|
||||
Acronis 提供：
|
||||
|
||||
- **跨区域复制**：异地数据复制
|
||||
- **备份解决方案**：文件、系统、虚拟机备份
|
||||
- **灾难恢复**：BC/DR 规划工具
|
||||
- **网络安全**：防恶意软件、防勒索
|
||||
- **云原生集成**：AWS、Azure、GCP
|
||||
|
||||
## 定位：传统灾备 + 安全
|
||||
|
||||
Acronis 与 [[Veeam]] 类似，代表传统灾备思路，但其融合了网络安全功能（Acronis Cyber Protect）。
|
||||
|
||||
| 维度 | Acronis（传统） | [[Feature Flag]]（现代） |
|
||||
|------|-----------------|------------------------|
|
||||
| 保护对象 | 基础设施、数据 | 代码、功能、部署 |
|
||||
| 故障类型 | 硬件故障、勒索软件 | 代码变更、Bug |
|
||||
| RTO | 小时级（从备份恢复） | 秒级（配置变更） |
|
||||
| 故障频率 | 低 | 高（每周可能发生） |
|
||||
| 安全集成 | 有（Acronis Cyber Protect） | 无（专注于代码层） |
|
||||
|
||||
## 与 [[RTO]]/[[RPO]] 的关系
|
||||
|
||||
Acronis 优化的是基础设施级别的 RTO 和 RPO：
|
||||
|
||||
| 场景 | RTO | RPO | 说明 |
|
||||
|------|-----|-----|------|
|
||||
| 从 Acronis 备份恢复 | 小时级 | 取决于备份频率 | 需要重建基础设施 |
|
||||
| 跨区域复制恢复 | 分钟级 | 取决于复制频率 | 数据已预复制到异地 |
|
||||
| Acronis 即时恢复 | 分钟级 | 小时级 | 仍然需要恢复数据 |
|
||||
|
||||
## 典型部署场景
|
||||
|
||||
- **硬件故障**：服务器损坏后的快速恢复
|
||||
- **勒索软件防护**：Acronis Cyber Protect 提供勒索软件防御和恢复
|
||||
- **跨数据中心灾备**：异地数据复制
|
||||
- **合规数据保留**：长期归档和保留
|
||||
|
||||
## 竞品
|
||||
|
||||
| 工具 | 定位 |
|
||||
|------|------|
|
||||
| Acronis | 数据保护 + 网络安全 |
|
||||
| [[Veeam]] | 企业级虚拟机备份 |
|
||||
| Rubrik | 云原生数据保护 |
|
||||
| Commvault | 企业数据管理 |
|
||||
|
||||
## 局限性
|
||||
|
||||
与 Veeam 类似，Acronis 无法解决**软件层面的问题**：
|
||||
|
||||
- 无法防止 Bug 部署
|
||||
- 无法实现 Feature Flag 级别的快速回滚
|
||||
- 无法支持渐进放量
|
||||
- 灾备触发频率低，无法应对日常代码变更风险
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Disaster Recovery]] — Acronis 是传统灾备工具
|
||||
- [[RTO]] — Acronis 优化基础设施级 RTO
|
||||
- [[RPO]] — Acronis 优化数据保护级 RPO
|
||||
- [[Veeam]] — 竞品灾备工具
|
||||
- [[LaunchDarkly]] — 代表现代软件层灾备方案
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]]
|
||||
|
||||
@@ -1,39 +1,39 @@
|
||||
---
|
||||
title: "Adam Smith"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Identity
|
||||
|
||||
古典经济学家，现代经济学之父，《国富论》（The Wealth of Nations, 1776）作者。在本文中被引用来揭示专业化分工对人类智识和自主性的负面影响。
|
||||
|
||||
## Role in This Source
|
||||
|
||||
本文引用 Adam Smith 在《国富论》开篇论分工的段落：
|
||||
|
||||
> "一个人如果一生只从事几项简单的操作，通常会变得愚蠢无知到极致。"
|
||||
|
||||
作者以此论证专业化分工的历史代价——正是 Smith 本人创造了分工制度，而后人至今仍受其反噬。
|
||||
|
||||
## Key Ideas (Relevant to This Source)
|
||||
|
||||
- 分工理论（Division of Labor）：专业化分工使生产效率大幅提升（针厂案例：从20针/天到48,000针/天）
|
||||
- 市场的"看不见的手"：个人追求私利在制度设计合理时可促进公共利益
|
||||
- 但在本文语境中：分工制度被政府和公司利用来压制个人自主性
|
||||
|
||||
## Aliases
|
||||
|
||||
- 亚当·斯密
|
||||
- Smith
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Generalist]] — Smith 的分工理论是通才概念的反面参照
|
||||
- [[Self-Sufficiency]] — 对抗分工制度对个人自主性的侵蚀
|
||||
|
||||
## Sources
|
||||
|
||||
- [[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]]
|
||||
---
|
||||
title: "Adam Smith"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Identity
|
||||
|
||||
古典经济学家，现代经济学之父，《国富论》（The Wealth of Nations, 1776）作者。在本文中被引用来揭示专业化分工对人类智识和自主性的负面影响。
|
||||
|
||||
## Role in This Source
|
||||
|
||||
本文引用 Adam Smith 在《国富论》开篇论分工的段落：
|
||||
|
||||
> "一个人如果一生只从事几项简单的操作，通常会变得愚蠢无知到极致。"
|
||||
|
||||
作者以此论证专业化分工的历史代价——正是 Smith 本人创造了分工制度，而后人至今仍受其反噬。
|
||||
|
||||
## Key Ideas (Relevant to This Source)
|
||||
|
||||
- 分工理论（Division of Labor）：专业化分工使生产效率大幅提升（针厂案例：从20针/天到48,000针/天）
|
||||
- 市场的"看不见的手"：个人追求私利在制度设计合理时可促进公共利益
|
||||
- 但在本文语境中：分工制度被政府和公司利用来压制个人自主性
|
||||
|
||||
## Aliases
|
||||
|
||||
- 亚当·斯密
|
||||
- Smith
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Generalist]] — Smith 的分工理论是通才概念的反面参照
|
||||
- [[Self-Sufficiency]] — 对抗分工制度对个人自主性的侵蚀
|
||||
|
||||
## Sources
|
||||
|
||||
- [[if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间]]
|
||||
|
||||
@@ -1,33 +1,33 @@
|
||||
---
|
||||
title: "AdsPower"
|
||||
type: entity
|
||||
tags: [fingerprint-browser, tool, account-management]
|
||||
date: 2025-12-31
|
||||
---
|
||||
|
||||
# AdsPower
|
||||
|
||||
## 基本信息
|
||||
- **类型**: 工具/产品
|
||||
- **官网**: https://share.adspower.net
|
||||
- **用途**: 指纹浏览器，多账号管理
|
||||
|
||||
## 功能特性
|
||||
- **浏览器指纹隔离**: 模拟不同设备和网络环境
|
||||
- **多账号管理**: 每个浏览器环境相互隔离，防止账号关联
|
||||
- **免费版限制**: 最多5个浏览器环境
|
||||
- **代理配置**: 支持Socks5代理配置
|
||||
- **谷歌授权登录**: 支持
|
||||
|
||||
## Aliases
|
||||
- 无
|
||||
|
||||
## 相关页面
|
||||
- [[指纹浏览器]]
|
||||
- [[IP纯净度]]
|
||||
- [[PingMe]]
|
||||
- [[WildCard]]
|
||||
- [[Claude Pro]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
---
|
||||
title: "AdsPower"
|
||||
type: entity
|
||||
tags: [fingerprint-browser, tool, account-management]
|
||||
date: 2025-12-31
|
||||
---
|
||||
|
||||
# AdsPower
|
||||
|
||||
## 基本信息
|
||||
- **类型**: 工具/产品
|
||||
- **官网**: https://share.adspower.net
|
||||
- **用途**: 指纹浏览器，多账号管理
|
||||
|
||||
## 功能特性
|
||||
- **浏览器指纹隔离**: 模拟不同设备和网络环境
|
||||
- **多账号管理**: 每个浏览器环境相互隔离，防止账号关联
|
||||
- **免费版限制**: 最多5个浏览器环境
|
||||
- **代理配置**: 支持Socks5代理配置
|
||||
- **谷歌授权登录**: 支持
|
||||
|
||||
## Aliases
|
||||
- 无
|
||||
|
||||
## 相关页面
|
||||
- [[指纹浏览器]]
|
||||
- [[IP纯净度]]
|
||||
- [[PingMe]]
|
||||
- [[WildCard]]
|
||||
- [[Claude Pro]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
|
||||
@@ -1,94 +1,94 @@
|
||||
---
|
||||
title: "Agentic AI"
|
||||
type: entity
|
||||
tags:
|
||||
- ai
|
||||
- devops
|
||||
- automation
|
||||
created: 2026-04-25
|
||||
---
|
||||
|
||||
# Agentic AI
|
||||
|
||||
## Definition
|
||||
|
||||
Agentic AI (Agentic Artificial Intelligence) 是具有**自主决策和任务执行能力**的 AI 系统，能够感知环境、规划行动、执行任务并从反馈中学习。与传统 AI 不同，Agentic AI 不仅响应查询，而是能够自主完成复杂的多步骤工作流。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Autonomous AI
|
||||
- AI Agents
|
||||
- AI Automation
|
||||
- Intelligent Automation
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
| Capability | Description | Example |
|
||||
|------------|-------------|---------|
|
||||
| **感知 (Perceive)** | 感知环境和数据 | 监控云指标、日志分析 |
|
||||
| **规划 (Plan)** | 制定行动策略 | 部署策略选择、回滚决策 |
|
||||
| **执行 (Act)** | 自主执行任务 | 自动修复、配置变更 |
|
||||
| **学习 (Learn)** | 从反馈中优化 | 历史模式学习、预测性维护 |
|
||||
|
||||
## Agentic AI vs Traditional AI
|
||||
|
||||
| Dimension | Traditional AI | Agentic AI |
|
||||
|-----------|---------------|------------|
|
||||
| Interaction | Request-Response | Goal-Directed |
|
||||
| Autonomy | Low | High |
|
||||
| Task Duration | Single Turn | Multi-Step Workflow |
|
||||
| Human Oversight | Required | Minimal (Guardrails) |
|
||||
| Adaptability | Static | Dynamic |
|
||||
|
||||
## Applications in Cloud DevOps
|
||||
|
||||
Agentic AI 在 Cloud DevOps 中的 7 大应用领域：
|
||||
|
||||
1. **[[Self-Healing Systems]]** — 自动检测异常并修复
|
||||
2. **[[Root Cause Analysis (RCA)]]** — AI 驱动的根因分析
|
||||
3. **[[Predictive Maintenance]]** — 基于历史模式预防故障
|
||||
4. **[[Deployment Automation]]** — AI 作为 Release Manager
|
||||
5. **[[Rightsizing]]** — 智能成本优化
|
||||
6. **[[Automated Security Audit]]** — 持续安全态势管理
|
||||
7. **[[AI ChatOps]]** — 自然语言运维协作
|
||||
|
||||
## Architecture Pattern
|
||||
|
||||
```
|
||||
Agentic AI System:
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Agentic AI │
|
||||
├─────────────────────────────────────────────────┤
|
||||
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||||
│ │感知层 │ │规划层 │ │执行层 │ │
|
||||
│ │Sensors │ │Planner │ │Executor │ │
|
||||
│ └────┬────┘ └────┬────┘ └────┬────┘ │
|
||||
│ │ │ │ │
|
||||
│ ┌────┴────────────┴────────────┴────┐ │
|
||||
│ │ Tool Integration │ │
|
||||
│ │ (CloudWatch, IAM, K8s, etc.) │ │
|
||||
│ └──────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Self-Healing Systems]]
|
||||
- [[Root Cause Analysis (RCA)]]
|
||||
- [[Predictive Maintenance]]
|
||||
- [[Deployment Automation]]
|
||||
- [[Rightsizing]]
|
||||
- [[Automated Security Audit]]
|
||||
- [[AI ChatOps]]
|
||||
- [[What-If Simulation]]
|
||||
- [[AIOps]]
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[how-agentic-ai-can-help-for-cloud-devops]]
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Kubernetes]] — 主要管理和修复目标
|
||||
- [[Terraform]] — IaC 审查对象
|
||||
- [[CloudWatch]] — 监控数据来源
|
||||
---
|
||||
title: "Agentic AI"
|
||||
type: entity
|
||||
tags:
|
||||
- ai
|
||||
- devops
|
||||
- automation
|
||||
created: 2026-04-25
|
||||
---
|
||||
|
||||
# Agentic AI
|
||||
|
||||
## Definition
|
||||
|
||||
Agentic AI (Agentic Artificial Intelligence) 是具有**自主决策和任务执行能力**的 AI 系统，能够感知环境、规划行动、执行任务并从反馈中学习。与传统 AI 不同，Agentic AI 不仅响应查询，而是能够自主完成复杂的多步骤工作流。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Autonomous AI
|
||||
- AI Agents
|
||||
- AI Automation
|
||||
- Intelligent Automation
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
| Capability | Description | Example |
|
||||
|------------|-------------|---------|
|
||||
| **感知 (Perceive)** | 感知环境和数据 | 监控云指标、日志分析 |
|
||||
| **规划 (Plan)** | 制定行动策略 | 部署策略选择、回滚决策 |
|
||||
| **执行 (Act)** | 自主执行任务 | 自动修复、配置变更 |
|
||||
| **学习 (Learn)** | 从反馈中优化 | 历史模式学习、预测性维护 |
|
||||
|
||||
## Agentic AI vs Traditional AI
|
||||
|
||||
| Dimension | Traditional AI | Agentic AI |
|
||||
|-----------|---------------|------------|
|
||||
| Interaction | Request-Response | Goal-Directed |
|
||||
| Autonomy | Low | High |
|
||||
| Task Duration | Single Turn | Multi-Step Workflow |
|
||||
| Human Oversight | Required | Minimal (Guardrails) |
|
||||
| Adaptability | Static | Dynamic |
|
||||
|
||||
## Applications in Cloud DevOps
|
||||
|
||||
Agentic AI 在 Cloud DevOps 中的 7 大应用领域：
|
||||
|
||||
1. **[[Self-Healing Systems]]** — 自动检测异常并修复
|
||||
2. **[[Root Cause Analysis (RCA)]]** — AI 驱动的根因分析
|
||||
3. **[[Predictive Maintenance]]** — 基于历史模式预防故障
|
||||
4. **[[Deployment Automation]]** — AI 作为 Release Manager
|
||||
5. **[[Rightsizing]]** — 智能成本优化
|
||||
6. **[[Automated Security Audit]]** — 持续安全态势管理
|
||||
7. **[[AI ChatOps]]** — 自然语言运维协作
|
||||
|
||||
## Architecture Pattern
|
||||
|
||||
```
|
||||
Agentic AI System:
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Agentic AI │
|
||||
├─────────────────────────────────────────────────┤
|
||||
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||||
│ │感知层 │ │规划层 │ │执行层 │ │
|
||||
│ │Sensors │ │Planner │ │Executor │ │
|
||||
│ └────┬────┘ └────┬────┘ └────┬────┘ │
|
||||
│ │ │ │ │
|
||||
│ ┌────┴────────────┴────────────┴────┐ │
|
||||
│ │ Tool Integration │ │
|
||||
│ │ (CloudWatch, IAM, K8s, etc.) │ │
|
||||
│ └──────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Self-Healing Systems]]
|
||||
- [[Root Cause Analysis (RCA)]]
|
||||
- [[Predictive Maintenance]]
|
||||
- [[Deployment Automation]]
|
||||
- [[Rightsizing]]
|
||||
- [[Automated Security Audit]]
|
||||
- [[AI ChatOps]]
|
||||
- [[What-If Simulation]]
|
||||
- [[AIOps]]
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[how-agentic-ai-can-help-for-cloud-devops]]
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Kubernetes]] — 主要管理和修复目标
|
||||
- [[Terraform]] — IaC 审查对象
|
||||
- [[CloudWatch]] — 监控数据来源
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: "AionUi"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# AionUi
|
||||
|
||||
免费开源的桌面多 Agent 应用（macOS/Windows/Linux），将 OpenClaw 作为一等公民 Agent 运行，同时支持 Claude Code、Codex、Qwen Code 等 12+ 外部 Agent 的统一接入。
|
||||
|
||||
## Aliases
|
||||
- AionUi
|
||||
- Aion UI
|
||||
|
||||
## 核心能力
|
||||
|
||||
### Cowork 工作空间
|
||||
提供文件感知的工作界面，用户可直接看到 Agent 读写文件、运行命令、浏览网页——而非仅终端日志输出。OpenClaw 作为 Cowork Agent 运行，享有完整可视化操作体验。
|
||||
|
||||
### OpenClaw 远程救援专家
|
||||
内置 OpenClaw 部署专家助手，可通过 Telegram 或 WebUI 远程访问，执行以下修复操作：
|
||||
- 运行 `openclaw doctor` 诊断问题
|
||||
- 修复配置文件
|
||||
- 重启 Gateway 服务
|
||||
|
||||
这对在另一台机器或无头（headless）模式下运行 OpenClaw 的用户尤为重要——当 OpenClaw 无法连接时，不再需要物理访问该机器。
|
||||
|
||||
### 多 Agent 统一管理
|
||||
- 在同一应用中并行运行 OpenClaw + 内置 Agent（Gemini/OpenAI/Anthropic/Ollama）+ Claude Code + Codex 等
|
||||
- 切换 Agent 或并行运行，无需重复配置
|
||||
- **MCP 一次配置，所有 Agent 共享**：在 AionUi 中配置 MCP 服务器，自动同步到 OpenClaw 和所有其他 Agent
|
||||
|
||||
### 远程访问
|
||||
支持 WebUI、Telegram、Lark、DingTalk 多渠道远程连接同一个 AionUi 实例（及 OpenClaw）。
|
||||
|
||||
### 自动化调度
|
||||
AionUi Cron 可定时运行 OpenClaw 或其他 Agent，执行 24/7 自动化任务。
|
||||
|
||||
## 安装与配置
|
||||
|
||||
1. 从 [AionUi Releases](https://github.com/iOfficeAI/AionUi/releases) 下载安装
|
||||
2. 安装 OpenClaw（如尚未安装）：`npm install -g openclaw@latest`
|
||||
3. 可选安装守护进程：`openclaw onboard --install-daemon`
|
||||
4. 打开 AionUi，自动检测 OpenClaw（或使用内置 OpenClaw Setup 助手引导）
|
||||
5. 创建 Cowork Session，选择 OpenClaw，即可使用
|
||||
|
||||
## 相关链接
|
||||
- [AionUi GitHub](https://github.com/iOfficeAI/AionUi)
|
||||
- [AionUi Website](https://www.aionui.com)
|
||||
- [OpenClaw GitHub](https://github.com/openclaw/openclaw)
|
||||
---
|
||||
title: "AionUi"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# AionUi
|
||||
|
||||
免费开源的桌面多 Agent 应用（macOS/Windows/Linux），将 OpenClaw 作为一等公民 Agent 运行，同时支持 Claude Code、Codex、Qwen Code 等 12+ 外部 Agent 的统一接入。
|
||||
|
||||
## Aliases
|
||||
- AionUi
|
||||
- Aion UI
|
||||
|
||||
## 核心能力
|
||||
|
||||
### Cowork 工作空间
|
||||
提供文件感知的工作界面，用户可直接看到 Agent 读写文件、运行命令、浏览网页——而非仅终端日志输出。OpenClaw 作为 Cowork Agent 运行，享有完整可视化操作体验。
|
||||
|
||||
### OpenClaw 远程救援专家
|
||||
内置 OpenClaw 部署专家助手，可通过 Telegram 或 WebUI 远程访问，执行以下修复操作：
|
||||
- 运行 `openclaw doctor` 诊断问题
|
||||
- 修复配置文件
|
||||
- 重启 Gateway 服务
|
||||
|
||||
这对在另一台机器或无头（headless）模式下运行 OpenClaw 的用户尤为重要——当 OpenClaw 无法连接时，不再需要物理访问该机器。
|
||||
|
||||
### 多 Agent 统一管理
|
||||
- 在同一应用中并行运行 OpenClaw + 内置 Agent（Gemini/OpenAI/Anthropic/Ollama）+ Claude Code + Codex 等
|
||||
- 切换 Agent 或并行运行，无需重复配置
|
||||
- **MCP 一次配置，所有 Agent 共享**：在 AionUi 中配置 MCP 服务器，自动同步到 OpenClaw 和所有其他 Agent
|
||||
|
||||
### 远程访问
|
||||
支持 WebUI、Telegram、Lark、DingTalk 多渠道远程连接同一个 AionUi 实例（及 OpenClaw）。
|
||||
|
||||
### 自动化调度
|
||||
AionUi Cron 可定时运行 OpenClaw 或其他 Agent，执行 24/7 自动化任务。
|
||||
|
||||
## 安装与配置
|
||||
|
||||
1. 从 [AionUi Releases](https://github.com/iOfficeAI/AionUi/releases) 下载安装
|
||||
2. 安装 OpenClaw（如尚未安装）：`npm install -g openclaw@latest`
|
||||
3. 可选安装守护进程：`openclaw onboard --install-daemon`
|
||||
4. 打开 AionUi，自动检测 OpenClaw（或使用内置 OpenClaw Setup 助手引导）
|
||||
5. 创建 Cowork Session，选择 OpenClaw，即可使用
|
||||
|
||||
## 相关链接
|
||||
- [AionUi GitHub](https://github.com/iOfficeAI/AionUi)
|
||||
- [AionUi Website](https://www.aionui.com)
|
||||
- [OpenClaw GitHub](https://github.com/openclaw/openclaw)
|
||||
|
||||
@@ -1,75 +1,75 @@
|
||||
---
|
||||
title: "Alertmanager"
|
||||
type: entity
|
||||
aliases: [Prometheus Alertmanager, Alertmanager OSS]
|
||||
tags: [alerting, prometheus, notification, devops, observability]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
# Alertmanager
|
||||
|
||||
## Overview
|
||||
Alertmanager 是 Prometheus 生态系统中的告警分发和路由组件。当 Prometheus 的告警规则触发时，告警被发送给 Alertmanager，由 Alertmanager 负责抑制（inhibition）、分组（grouping）、静默（silencing）和路由（routing）到最终的通知通道（邮件、Slack、PagerDuty、WeChat 等）。
|
||||
|
||||
## Key Characteristics
|
||||
- **告警分组**：将相似告警合并为一条通知，避免告警风暴
|
||||
- **抑制机制**：当一个严重告警触发时，自动抑制相关的次要告警
|
||||
- **静默规则**：基于时间窗口的告警静默，支持重复告警抑制
|
||||
- **多通道路由**：邮件、Slack、WeChat、Telegram、PagerDuty、Webhook
|
||||
- **重复间隔**：未解决的告警按可配置间隔重复发送
|
||||
|
||||
## Prometheus Configuration
|
||||
```yaml
|
||||
# prometheus.yml
|
||||
alerting:
|
||||
alertmanagers:
|
||||
- static_configs:
|
||||
- targets: ['alertmanager:9093']
|
||||
```
|
||||
|
||||
## Alertmanager Configuration
|
||||
```yaml
|
||||
# alertmanager/config.yml
|
||||
global:
|
||||
resolve_timeout: 5m
|
||||
|
||||
route:
|
||||
receiver: default
|
||||
group_wait: 10s # 新告警等待 10s 再发送（收集同组告警）
|
||||
group_interval: 5m # 告警组更新间隔
|
||||
repeat_interval: 3h # 重复告警间隔
|
||||
|
||||
receivers:
|
||||
- name: default
|
||||
email_configs:
|
||||
- to: "youremail@example.com"
|
||||
from: "monitor@example.com"
|
||||
smarthost: "smtp.example.com:587"
|
||||
auth_username: "monitor@example.com"
|
||||
auth_password: "yourpassword"
|
||||
# Slack 配置示例
|
||||
slack_configs:
|
||||
- api_url: 'https://hooks.slack.com/services/xxx'
|
||||
channel: '#alerts'
|
||||
```
|
||||
|
||||
## Alertmanager vs Grafana Alerting
|
||||
| 维度 | Alertmanager | Grafana Alerting |
|
||||
|------|-------------|-----------------|
|
||||
| 数据源 | Prometheus 原生 | 多数据源 |
|
||||
| 告警规则 | Prometheus YAML | Grafana UI / YAML |
|
||||
| 通知通道 | 原生多通道 | 原生 + 插件扩展 |
|
||||
| 告警历史 | 需额外存储 | 内置告警历史 |
|
||||
| 适用场景 | 标准化告警 | 仪表盘联动告警 |
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Entities
|
||||
- [[Prometheus]] — 告警规则源和发送方
|
||||
- [[Grafana]] — 可替代 Prometheus Alerting 的告警方案
|
||||
|
||||
## Related Concepts
|
||||
- [[Prometheus告警规则]] — 告警条件定义
|
||||
- [[PromQL]] — 告警触发条件语言
|
||||
- [[System Monitoring]] — 上游应用领域
|
||||
---
|
||||
title: "Alertmanager"
|
||||
type: entity
|
||||
aliases: [Prometheus Alertmanager, Alertmanager OSS]
|
||||
tags: [alerting, prometheus, notification, devops, observability]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
# Alertmanager
|
||||
|
||||
## Overview
|
||||
Alertmanager 是 Prometheus 生态系统中的告警分发和路由组件。当 Prometheus 的告警规则触发时，告警被发送给 Alertmanager，由 Alertmanager 负责抑制（inhibition）、分组（grouping）、静默（silencing）和路由（routing）到最终的通知通道（邮件、Slack、PagerDuty、WeChat 等）。
|
||||
|
||||
## Key Characteristics
|
||||
- **告警分组**：将相似告警合并为一条通知，避免告警风暴
|
||||
- **抑制机制**：当一个严重告警触发时，自动抑制相关的次要告警
|
||||
- **静默规则**：基于时间窗口的告警静默，支持重复告警抑制
|
||||
- **多通道路由**：邮件、Slack、WeChat、Telegram、PagerDuty、Webhook
|
||||
- **重复间隔**：未解决的告警按可配置间隔重复发送
|
||||
|
||||
## Prometheus Configuration
|
||||
```yaml
|
||||
# prometheus.yml
|
||||
alerting:
|
||||
alertmanagers:
|
||||
- static_configs:
|
||||
- targets: ['alertmanager:9093']
|
||||
```
|
||||
|
||||
## Alertmanager Configuration
|
||||
```yaml
|
||||
# alertmanager/config.yml
|
||||
global:
|
||||
resolve_timeout: 5m
|
||||
|
||||
route:
|
||||
receiver: default
|
||||
group_wait: 10s # 新告警等待 10s 再发送（收集同组告警）
|
||||
group_interval: 5m # 告警组更新间隔
|
||||
repeat_interval: 3h # 重复告警间隔
|
||||
|
||||
receivers:
|
||||
- name: default
|
||||
email_configs:
|
||||
- to: "youremail@example.com"
|
||||
from: "monitor@example.com"
|
||||
smarthost: "smtp.example.com:587"
|
||||
auth_username: "monitor@example.com"
|
||||
auth_password: "yourpassword"
|
||||
# Slack 配置示例
|
||||
slack_configs:
|
||||
- api_url: 'https://hooks.slack.com/services/xxx'
|
||||
channel: '#alerts'
|
||||
```
|
||||
|
||||
## Alertmanager vs Grafana Alerting
|
||||
| 维度 | Alertmanager | Grafana Alerting |
|
||||
|------|-------------|-----------------|
|
||||
| 数据源 | Prometheus 原生 | 多数据源 |
|
||||
| 告警规则 | Prometheus YAML | Grafana UI / YAML |
|
||||
| 通知通道 | 原生多通道 | 原生 + 插件扩展 |
|
||||
| 告警历史 | 需额外存储 | 内置告警历史 |
|
||||
| 适用场景 | 标准化告警 | 仪表盘联动告警 |
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Entities
|
||||
- [[Prometheus]] — 告警规则源和发送方
|
||||
- [[Grafana]] — 可替代 Prometheus Alerting 的告警方案
|
||||
|
||||
## Related Concepts
|
||||
- [[Prometheus告警规则]] — 告警条件定义
|
||||
- [[PromQL]] — 告警触发条件语言
|
||||
- [[System Monitoring]] — 上游应用领域
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
---
|
||||
title: "Alex Ewerlöf"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
# Alex Ewerlöf
|
||||
|
||||
## 基本信息
|
||||
- **角色**：资深Staff Engineer（27年经验），KTH（瑞典皇家理工学院）系统工程硕士
|
||||
- **专注领域**：Reliability Engineering（可靠性工程）+ Resilient Architecture（弹性架构）
|
||||
- **LLM专攻时间**：2023年起
|
||||
- **个人网站**：alexewerlof.com
|
||||
|
||||
## 核心观点
|
||||
- 反对拟人化LLM，主张将LLM视为分布式系统中不可靠的组件
|
||||
- 强调架构约束（而非提示词约束）是提升AI系统可靠性的关键
|
||||
- 借鉴人类协作系统（军队、公司、国家）的反馈回路与制衡机制设计多智能体系统
|
||||
|
||||
## 主要著作
|
||||
- [[multi-agent-system-reliability]]：《Multi-Agent System Reliability》，2023-01-09
|
||||
- SRE系列博客
|
||||
|
||||
## Aliases
|
||||
- Alex Ewerlof
|
||||
- A. Ewerlöf
|
||||
---
|
||||
title: "Alex Ewerlöf"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
# Alex Ewerlöf
|
||||
|
||||
## 基本信息
|
||||
- **角色**：资深Staff Engineer（27年经验），KTH（瑞典皇家理工学院）系统工程硕士
|
||||
- **专注领域**：Reliability Engineering（可靠性工程）+ Resilient Architecture（弹性架构）
|
||||
- **LLM专攻时间**：2023年起
|
||||
- **个人网站**：alexewerlof.com
|
||||
|
||||
## 核心观点
|
||||
- 反对拟人化LLM，主张将LLM视为分布式系统中不可靠的组件
|
||||
- 强调架构约束（而非提示词约束）是提升AI系统可靠性的关键
|
||||
- 借鉴人类协作系统（军队、公司、国家）的反馈回路与制衡机制设计多智能体系统
|
||||
|
||||
## 主要著作
|
||||
- [[multi-agent-system-reliability]]：《Multi-Agent System Reliability》，2023-01-09
|
||||
- SRE系列博客
|
||||
|
||||
## Aliases
|
||||
- Alex Ewerlof
|
||||
- A. Ewerlöf
|
||||
|
||||
@@ -1,29 +1,29 @@
|
||||
---
|
||||
title: "Alex Finn"
|
||||
type: entity
|
||||
tags: [content-creator, openclaw-community]
|
||||
sources: [market-research-product-factory, content-factory, custom-morning-brief, second-brain, overnight-mini-app-builder]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Alex Finn 是 OpenClaw 社区的内容创作者和资深用户，通过 YouTube 视频分享 OpenClaw 高阶用法，推动了多个 OpenClaw 自动化工作流的流行。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Alex Finn
|
||||
- Alex Finn (OpenClaw YouTuber)
|
||||
|
||||
## Role in System
|
||||
|
||||
- 通过 YouTube 视频激发了 [[market-research-product-factory]] 和 [[custom-morning-brief]] 等工作流的实践
|
||||
- 其视频内容是 OpenClaw 社区高阶用法的重要传播渠道
|
||||
- 专注于展示 AI Agent 在个人生产力场景中的实际应用价值
|
||||
|
||||
## Key Relationships
|
||||
|
||||
- [[OpenClaw]] — Alex Finn 的主要研究和推广对象
|
||||
- [[market-research-product-factory]] — 受 Alex Finn 视频启发的 OpenClaw 工作流
|
||||
- [[custom-morning-brief]] — 受 Alex Finn 视频启发的 OpenClaw 工作流
|
||||
- [[content-factory]] — 受 Alex Finn 视频启发的 Discord 多 Agent 内容工厂
|
||||
---
|
||||
title: "Alex Finn"
|
||||
type: entity
|
||||
tags: [content-creator, openclaw-community]
|
||||
sources: [market-research-product-factory, content-factory, custom-morning-brief, second-brain, overnight-mini-app-builder]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Alex Finn 是 OpenClaw 社区的内容创作者和资深用户，通过 YouTube 视频分享 OpenClaw 高阶用法，推动了多个 OpenClaw 自动化工作流的流行。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Alex Finn
|
||||
- Alex Finn (OpenClaw YouTuber)
|
||||
|
||||
## Role in System
|
||||
|
||||
- 通过 YouTube 视频激发了 [[market-research-product-factory]] 和 [[custom-morning-brief]] 等工作流的实践
|
||||
- 其视频内容是 OpenClaw 社区高阶用法的重要传播渠道
|
||||
- 专注于展示 AI Agent 在个人生产力场景中的实际应用价值
|
||||
|
||||
## Key Relationships
|
||||
|
||||
- [[OpenClaw]] — Alex Finn 的主要研究和推广对象
|
||||
- [[market-research-product-factory]] — 受 Alex Finn 视频启发的 OpenClaw 工作流
|
||||
- [[custom-morning-brief]] — 受 Alex Finn 视频启发的 OpenClaw 工作流
|
||||
- [[content-factory]] — 受 Alex Finn 视频启发的 Discord 多 Agent 内容工厂
|
||||
|
||||
@@ -1,60 +1,60 @@
|
||||
---
|
||||
title: "Amazon API Gateway"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- API
|
||||
- Networking
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- API Gateway
|
||||
- Amazon API Gateway
|
||||
- AWS API Gateway
|
||||
|
||||
## Definition
|
||||
|
||||
Amazon API Gateway 是 AWS 的全托管 API 管理服务，用于创建、发布、维护和监控安全的企业级 REST、HTTP 和 WebSocket API。API Gateway 作为 Lambda 函数和其他后端服务的统一入口，提供流量管理、授权和访问控制、监控等企业级能力。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| API 类型 | REST API、HTTP API、WebSocket API |
|
||||
| 部署选项 | Edge-Optimized、Regional、Private |
|
||||
| 认证方式 | IAM 角色、Lambda Authorizer、Cognito、API Key |
|
||||
| 协议 | HTTPS（TLS 终止由 AWS 管理） |
|
||||
| 限流 | 按账户/按 API/按客户多级限流 |
|
||||
| 缓存 | 可选 API 缓存，提升响应速度 |
|
||||
| 监控 | CloudWatch 集成，提供延迟、错误率等指标 |
|
||||
|
||||
## Deployment Options
|
||||
|
||||
| 选项 | 说明 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| Edge-Optimized | 通过 CloudFront CDN 全球分发，低延迟 | 面向全球用户的公共 API |
|
||||
| Regional | 部署在单一区域，自带高可用 | 面向同区域用户、VPC 内的 API |
|
||||
| Private | 仅可通过 VPC 内部端点访问 | 企业内部 API、微服务间通信 |
|
||||
|
||||
## Typical Architecture
|
||||
|
||||
```
|
||||
客户端 → API Gateway → Lambda Function → DynamoDB/SQS/etc.
|
||||
```
|
||||
|
||||
API Gateway 负责：
|
||||
1. TLS 终止（安全）
|
||||
2. 请求验证（格式、参数）
|
||||
3. 限流和配额管理
|
||||
4. 授权和身份验证
|
||||
5. 请求路由到后端 Lambda
|
||||
6. 响应转换和格式统一
|
||||
|
||||
## Connections
|
||||
- [[Amazon-API-Gateway]] ← exposes ← [[AWS-Lambda]]
|
||||
- [[Amazon-API-Gateway]] ← provides ← [[Serverless-Computing]]
|
||||
- [[Amazon-API-Gateway]] ← monitored_by ← [[CloudWatch]]
|
||||
---
|
||||
title: "Amazon API Gateway"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- API
|
||||
- Networking
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- API Gateway
|
||||
- Amazon API Gateway
|
||||
- AWS API Gateway
|
||||
|
||||
## Definition
|
||||
|
||||
Amazon API Gateway 是 AWS 的全托管 API 管理服务，用于创建、发布、维护和监控安全的企业级 REST、HTTP 和 WebSocket API。API Gateway 作为 Lambda 函数和其他后端服务的统一入口，提供流量管理、授权和访问控制、监控等企业级能力。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| API 类型 | REST API、HTTP API、WebSocket API |
|
||||
| 部署选项 | Edge-Optimized、Regional、Private |
|
||||
| 认证方式 | IAM 角色、Lambda Authorizer、Cognito、API Key |
|
||||
| 协议 | HTTPS（TLS 终止由 AWS 管理） |
|
||||
| 限流 | 按账户/按 API/按客户多级限流 |
|
||||
| 缓存 | 可选 API 缓存，提升响应速度 |
|
||||
| 监控 | CloudWatch 集成，提供延迟、错误率等指标 |
|
||||
|
||||
## Deployment Options
|
||||
|
||||
| 选项 | 说明 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| Edge-Optimized | 通过 CloudFront CDN 全球分发，低延迟 | 面向全球用户的公共 API |
|
||||
| Regional | 部署在单一区域，自带高可用 | 面向同区域用户、VPC 内的 API |
|
||||
| Private | 仅可通过 VPC 内部端点访问 | 企业内部 API、微服务间通信 |
|
||||
|
||||
## Typical Architecture
|
||||
|
||||
```
|
||||
客户端 → API Gateway → Lambda Function → DynamoDB/SQS/etc.
|
||||
```
|
||||
|
||||
API Gateway 负责：
|
||||
1. TLS 终止（安全）
|
||||
2. 请求验证（格式、参数）
|
||||
3. 限流和配额管理
|
||||
4. 授权和身份验证
|
||||
5. 请求路由到后端 Lambda
|
||||
6. 响应转换和格式统一
|
||||
|
||||
## Connections
|
||||
- [[Amazon-API-Gateway]] ← exposes ← [[AWS-Lambda]]
|
||||
- [[Amazon-API-Gateway]] ← provides ← [[Serverless-Computing]]
|
||||
- [[Amazon-API-Gateway]] ← monitored_by ← [[CloudWatch]]
|
||||
|
||||
@@ -1,48 +1,48 @@
|
||||
---
|
||||
title: "Amazon Aurora"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Cloud-Native
|
||||
- Relational Database
|
||||
sources:
|
||||
- ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Aurora 是 AWS 提供的云原生关系型数据库，采用 6 副本跨 3 可用区（AZ）的共享集群卷架构，相比传统 RDS 提供更高的性能、可用性和自动扩展能力。
|
||||
|
||||
## Core Architecture
|
||||
- **Shared Cluster Volume**：跨 3 AZ 的 6 块 EBS 卷组成的共享存储，写入时自动复制到所有副本
|
||||
- **无需数据复制**：新增读副本时直接连接同一集群卷，无需重新复制数据
|
||||
- **Writer/Reader Endpoints**：独立的写入端点和读取端点，支持自动负载均衡
|
||||
|
||||
## Key Advantages
|
||||
- **RTO 30 秒**：AZ 故障时恢复时间目标仅 30 秒
|
||||
- **自动扩缩容**：Aurora Serverless v2 支持按需自动扩缩（实例类型/版本/区域有限制）
|
||||
- **Aurora Global**：跨区域复制方案，支持托管式切换和故障转移
|
||||
- **Blue-Green Deployment**：Aurora MySQL 支持 Blue-Green 大版本升级（PostgreSQL 不支持）
|
||||
|
||||
## Key Limitations
|
||||
- 最小规格和成本高于 RDS
|
||||
- Serverless v2 对实例类型、版本和区域有限制
|
||||
- 按 IO 收费，高 IO 场景成本可能较高
|
||||
- PostgreSQL 不支持 Blue-Green 部署
|
||||
|
||||
## Cost Considerations
|
||||
Aurora 按 IO 计数收费，IO 理论上无上限（AWS 鼓励提供尽可能高的 IO 以增加收入）。适合超过 10-20 TB 的数据库或对 IO 性能有严格要求的场景。
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon RDS]]：传统关系型数据库托管服务
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[EBS]]：Elastic Block Store，Aurora 的底层存储
|
||||
- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]：AWS 专用数据库架构
|
||||
- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：RDS vs Aurora 详细对比
|
||||
|
||||
## Aliases
|
||||
- Aurora
|
||||
- Aurora PostgreSQL
|
||||
- Aurora MySQL
|
||||
- Amazon Aurora Database
|
||||
---
|
||||
title: "Amazon Aurora"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Cloud-Native
|
||||
- Relational Database
|
||||
sources:
|
||||
- ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Aurora 是 AWS 提供的云原生关系型数据库，采用 6 副本跨 3 可用区（AZ）的共享集群卷架构，相比传统 RDS 提供更高的性能、可用性和自动扩展能力。
|
||||
|
||||
## Core Architecture
|
||||
- **Shared Cluster Volume**：跨 3 AZ 的 6 块 EBS 卷组成的共享存储，写入时自动复制到所有副本
|
||||
- **无需数据复制**：新增读副本时直接连接同一集群卷，无需重新复制数据
|
||||
- **Writer/Reader Endpoints**：独立的写入端点和读取端点，支持自动负载均衡
|
||||
|
||||
## Key Advantages
|
||||
- **RTO 30 秒**：AZ 故障时恢复时间目标仅 30 秒
|
||||
- **自动扩缩容**：Aurora Serverless v2 支持按需自动扩缩（实例类型/版本/区域有限制）
|
||||
- **Aurora Global**：跨区域复制方案，支持托管式切换和故障转移
|
||||
- **Blue-Green Deployment**：Aurora MySQL 支持 Blue-Green 大版本升级（PostgreSQL 不支持）
|
||||
|
||||
## Key Limitations
|
||||
- 最小规格和成本高于 RDS
|
||||
- Serverless v2 对实例类型、版本和区域有限制
|
||||
- 按 IO 收费，高 IO 场景成本可能较高
|
||||
- PostgreSQL 不支持 Blue-Green 部署
|
||||
|
||||
## Cost Considerations
|
||||
Aurora 按 IO 计数收费，IO 理论上无上限（AWS 鼓励提供尽可能高的 IO 以增加收入）。适合超过 10-20 TB 的数据库或对 IO 性能有严格要求的场景。
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon RDS]]：传统关系型数据库托管服务
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[EBS]]：Elastic Block Store，Aurora 的底层存储
|
||||
- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]：AWS 专用数据库架构
|
||||
- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：RDS vs Aurora 详细对比
|
||||
|
||||
## Aliases
|
||||
- Aurora
|
||||
- Aurora PostgreSQL
|
||||
- Aurora MySQL
|
||||
- Amazon Aurora Database
|
||||
|
||||
@@ -1,53 +1,53 @@
|
||||
---
|
||||
title: Amazon CloudWatch Logs
|
||||
type: entity
|
||||
tags: [AWS, Observability, Logging, CloudOps]
|
||||
date: 2025-10-24
|
||||
---
|
||||
|
||||
## Overview
|
||||
**Amazon CloudWatch Logs** 是 AWS 的监控日志服务，用于监控、存储和访问来自 AWS 资源、应用程序和服务的日志。本方案中 central-cloudformation-logs Log Group 作为所有账户 CloudFormation 事件的集中存储。
|
||||
|
||||
## Key Capabilities
|
||||
- **Log Groups**：日志组，定义日志流的保留、加密和监控设置
|
||||
- **Log Streams**：日志流，来自同一来源的日志序列
|
||||
- **CloudWatch Logs Insights**：交互式日志分析和查询服务
|
||||
- **Metric Filters**：从日志中提取指标用于 CloudWatch Alarms
|
||||
- **Subscription Filters**：实时流式日志到 Kinesis/EventBridge/Lambda
|
||||
|
||||
## In This Solution
|
||||
CloudWatch Logs 在多账户 CloudFormation StackSets 监控方案中的角色：
|
||||
- **central-cloudformation-logs**：中心 Log Group，存储所有成员账户的 CloudFormation 事件
|
||||
- **加密**：使用客户管理的 AWS KMS 密钥加密日志
|
||||
- **查询**：CloudWatch Logs Insights 支持跨账户、跨区域的日志分析
|
||||
|
||||
## Log Group: central-cloudformation-logs
|
||||
- **Purpose**：聚合所有 AWS 账户的 CloudFormation 部署事件
|
||||
- **Encryption**：客户托管 KMS 密钥（encryption at rest）
|
||||
- **Retention**：可配置保留期（本方案未指定具体值）
|
||||
- **Access**：管理账户可访问，成员账户通过 EventBridge 写入
|
||||
|
||||
## CloudWatch Logs Insights 查询
|
||||
```sql
|
||||
fields @timestamp, account, region
|
||||
| parse @message /"resource-type":"(?<resource_type>[^"]+)"/
|
||||
| parse @message /"status":"(?<status>[^"]+)"/
|
||||
| parse @message /"logical-resource-id":"(?<logical_resource_id>[^"]+)"/
|
||||
| sort @timestamp desc
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[Centralized Logging]]：CloudWatch Logs 是 AWS 集中日志存储的核心
|
||||
- [[StackSets Deployment Visibility]]：CloudWatch Logs 存储 StackSets 部署事件
|
||||
- [[Cross-Account Monitoring]]：CloudWatch Logs Insights 支持跨账户查询
|
||||
- [[Cloud Service Delivery]]：CloudWatch Logs 是云服务交付可观测性的基础设施
|
||||
- [[APM]]（Application Performance Monitoring）：CloudWatch Logs 与 CloudWatch Metrics/Dashboards 共同构成 APM 能力
|
||||
|
||||
## Related Entities
|
||||
- [[AWS CloudFormation StackSets]]：CloudWatch Logs 存储其部署事件
|
||||
- [[Amazon EventBridge]]：EventBridge 将事件路由到 CloudWatch Logs
|
||||
- [[AWS]]（entity）：CloudWatch Logs 是 AWS 监控服务家族的核心成员
|
||||
|
||||
## Sources
|
||||
- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]]
|
||||
- AWS CloudWatch Logs 官方文档
|
||||
---
|
||||
title: Amazon CloudWatch Logs
|
||||
type: entity
|
||||
tags: [AWS, Observability, Logging, CloudOps]
|
||||
date: 2025-10-24
|
||||
---
|
||||
|
||||
## Overview
|
||||
**Amazon CloudWatch Logs** 是 AWS 的监控日志服务，用于监控、存储和访问来自 AWS 资源、应用程序和服务的日志。本方案中 central-cloudformation-logs Log Group 作为所有账户 CloudFormation 事件的集中存储。
|
||||
|
||||
## Key Capabilities
|
||||
- **Log Groups**：日志组，定义日志流的保留、加密和监控设置
|
||||
- **Log Streams**：日志流，来自同一来源的日志序列
|
||||
- **CloudWatch Logs Insights**：交互式日志分析和查询服务
|
||||
- **Metric Filters**：从日志中提取指标用于 CloudWatch Alarms
|
||||
- **Subscription Filters**：实时流式日志到 Kinesis/EventBridge/Lambda
|
||||
|
||||
## In This Solution
|
||||
CloudWatch Logs 在多账户 CloudFormation StackSets 监控方案中的角色：
|
||||
- **central-cloudformation-logs**：中心 Log Group，存储所有成员账户的 CloudFormation 事件
|
||||
- **加密**：使用客户管理的 AWS KMS 密钥加密日志
|
||||
- **查询**：CloudWatch Logs Insights 支持跨账户、跨区域的日志分析
|
||||
|
||||
## Log Group: central-cloudformation-logs
|
||||
- **Purpose**：聚合所有 AWS 账户的 CloudFormation 部署事件
|
||||
- **Encryption**：客户托管 KMS 密钥（encryption at rest）
|
||||
- **Retention**：可配置保留期（本方案未指定具体值）
|
||||
- **Access**：管理账户可访问，成员账户通过 EventBridge 写入
|
||||
|
||||
## CloudWatch Logs Insights 查询
|
||||
```sql
|
||||
fields @timestamp, account, region
|
||||
| parse @message /"resource-type":"(?<resource_type>[^"]+)"/
|
||||
| parse @message /"status":"(?<status>[^"]+)"/
|
||||
| parse @message /"logical-resource-id":"(?<logical_resource_id>[^"]+)"/
|
||||
| sort @timestamp desc
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[Centralized Logging]]：CloudWatch Logs 是 AWS 集中日志存储的核心
|
||||
- [[StackSets Deployment Visibility]]：CloudWatch Logs 存储 StackSets 部署事件
|
||||
- [[Cross-Account Monitoring]]：CloudWatch Logs Insights 支持跨账户查询
|
||||
- [[Cloud Service Delivery]]：CloudWatch Logs 是云服务交付可观测性的基础设施
|
||||
- [[APM]]（Application Performance Monitoring）：CloudWatch Logs 与 CloudWatch Metrics/Dashboards 共同构成 APM 能力
|
||||
|
||||
## Related Entities
|
||||
- [[AWS CloudFormation StackSets]]：CloudWatch Logs 存储其部署事件
|
||||
- [[Amazon EventBridge]]：EventBridge 将事件路由到 CloudWatch Logs
|
||||
- [[AWS]]（entity）：CloudWatch Logs 是 AWS 监控服务家族的核心成员
|
||||
|
||||
## Sources
|
||||
- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]]
|
||||
- AWS CloudWatch Logs 官方文档
|
||||
|
||||
@@ -1,42 +1,42 @@
|
||||
---
|
||||
title: "Amazon DocumentDB"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Document
|
||||
- MongoDB
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon DocumentDB 是 AWS 全托管的 MongoDB 兼容文档数据库（Document Database），支持灵活 schema（Flexible Schema），适合存储 JSON 类半结构化数据。
|
||||
|
||||
## Key Characteristics
|
||||
- **兼容性**：MongoDB 3.6、4.0、5.0 API 兼容
|
||||
- **数据模型**：文档（Document），存储为 BSON 格式
|
||||
- **Schema 灵活性**：无需预定义 schema，可随时添加/修改字段
|
||||
- **查询能力**：支持深度嵌套查询、数组查询、聚合管道
|
||||
- **规模**：存储和计算分离，支持横向扩展至数 TB
|
||||
|
||||
## Key Use Cases
|
||||
- **内容管理**：CMS、博客、产品目录
|
||||
- **用户档案**：灵活属性的用户配置文件
|
||||
- **物联网数据**：设备配置和状态文档
|
||||
- **实时分析**：日志和事件数据的快速写入
|
||||
|
||||
## Aliases
|
||||
- DocumentDB
|
||||
- Amazon DocumentDB
|
||||
- AWS DocumentDB
|
||||
- Amazon DocumentDB (with MongoDB compatibility)
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-DynamoDB]]：均为 NoSQL，DocumentDB 支持更深的查询能力，DynamoDB 提供更简单的 API 和更高的一致性保证
|
||||
- [[Amazon-RDS]]：关系型数据库，DocumentDB 提供 schema 灵活性，RDS 提供强 schema 和事务支持
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：DocumentDB 是 AWS 专用数据库家族中的文档数据库成员
|
||||
- [[Document-Database]]：文档数据库核心概念——无 schema JSON/BSON 存储、嵌套文档、聚合管道
|
||||
---
|
||||
title: "Amazon DocumentDB"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Document
|
||||
- MongoDB
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon DocumentDB 是 AWS 全托管的 MongoDB 兼容文档数据库（Document Database），支持灵活 schema（Flexible Schema），适合存储 JSON 类半结构化数据。
|
||||
|
||||
## Key Characteristics
|
||||
- **兼容性**：MongoDB 3.6、4.0、5.0 API 兼容
|
||||
- **数据模型**：文档（Document），存储为 BSON 格式
|
||||
- **Schema 灵活性**：无需预定义 schema，可随时添加/修改字段
|
||||
- **查询能力**：支持深度嵌套查询、数组查询、聚合管道
|
||||
- **规模**：存储和计算分离，支持横向扩展至数 TB
|
||||
|
||||
## Key Use Cases
|
||||
- **内容管理**：CMS、博客、产品目录
|
||||
- **用户档案**：灵活属性的用户配置文件
|
||||
- **物联网数据**：设备配置和状态文档
|
||||
- **实时分析**：日志和事件数据的快速写入
|
||||
|
||||
## Aliases
|
||||
- DocumentDB
|
||||
- Amazon DocumentDB
|
||||
- AWS DocumentDB
|
||||
- Amazon DocumentDB (with MongoDB compatibility)
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-DynamoDB]]：均为 NoSQL，DocumentDB 支持更深的查询能力，DynamoDB 提供更简单的 API 和更高的一致性保证
|
||||
- [[Amazon-RDS]]：关系型数据库，DocumentDB 提供 schema 灵活性，RDS 提供强 schema 和事务支持
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：DocumentDB 是 AWS 专用数据库家族中的文档数据库成员
|
||||
- [[Document-Database]]：文档数据库核心概念——无 schema JSON/BSON 存储、嵌套文档、聚合管道
|
||||
|
||||
@@ -1,41 +1,41 @@
|
||||
---
|
||||
title: "Amazon DynamoDB"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- NoSQL
|
||||
- Key-Value
|
||||
- Document
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon DynamoDB 是 AWS 全托管的 NoSQL 键值和文档数据库，提供单位数毫秒（single-digit millisecond）性能，支撑日处理万亿级请求规模。
|
||||
|
||||
## Key Characteristics
|
||||
- **数据类型**：键值（Key-Value）和文档（Document，JSON）
|
||||
- **性能**：单-digit 毫秒延迟，任何规模下均保持一致性能
|
||||
- **规模**：可扩展至日处理万亿级请求
|
||||
- **管理模式**：全托管（无服务器），无需容量规划
|
||||
- **API**：支持 CRUD 操作，自动分区
|
||||
|
||||
## Aliases
|
||||
- DynamoDB
|
||||
- AWS DynamoDB
|
||||
- Amazon DynamoDB
|
||||
|
||||
## Used By
|
||||
- **Netflix**：使用 DynamoDB 实现高弹性和低延迟的 JSON 文档访问（来源：[[ctp-topic-51-purpose-built-databases]]）
|
||||
- **Duolingo**：使用 DynamoDB 存储个性化学习数据（来源：[[ctp-topic-51-purpose-built-databases]]）
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-Aurora]]：关系型数据库，Aurora 是 DynamoDB 在强一致性事务场景的替代方案
|
||||
- [[Amazon-RDS]]：关系型数据库，固定 schema vs DynamoDB 的无 schema 灵活性
|
||||
- [[Amazon-ElastiCache]]：缓存层，可与 DynamoDB 组合使用提升读取性能
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：DynamoDB 是 AWS 专用数据库家族的核心成员
|
||||
- [[Multi-Database-Architecture]]：DynamoDB 常与其他数据库（如 ElastiCache、Aurora）组合使用
|
||||
---
|
||||
title: "Amazon DynamoDB"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- NoSQL
|
||||
- Key-Value
|
||||
- Document
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon DynamoDB 是 AWS 全托管的 NoSQL 键值和文档数据库，提供单位数毫秒（single-digit millisecond）性能，支撑日处理万亿级请求规模。
|
||||
|
||||
## Key Characteristics
|
||||
- **数据类型**：键值（Key-Value）和文档（Document，JSON）
|
||||
- **性能**：单-digit 毫秒延迟，任何规模下均保持一致性能
|
||||
- **规模**：可扩展至日处理万亿级请求
|
||||
- **管理模式**：全托管（无服务器），无需容量规划
|
||||
- **API**：支持 CRUD 操作，自动分区
|
||||
|
||||
## Aliases
|
||||
- DynamoDB
|
||||
- AWS DynamoDB
|
||||
- Amazon DynamoDB
|
||||
|
||||
## Used By
|
||||
- **Netflix**：使用 DynamoDB 实现高弹性和低延迟的 JSON 文档访问（来源：[[ctp-topic-51-purpose-built-databases]]）
|
||||
- **Duolingo**：使用 DynamoDB 存储个性化学习数据（来源：[[ctp-topic-51-purpose-built-databases]]）
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-Aurora]]：关系型数据库，Aurora 是 DynamoDB 在强一致性事务场景的替代方案
|
||||
- [[Amazon-RDS]]：关系型数据库，固定 schema vs DynamoDB 的无 schema 灵活性
|
||||
- [[Amazon-ElastiCache]]：缓存层，可与 DynamoDB 组合使用提升读取性能
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：DynamoDB 是 AWS 专用数据库家族的核心成员
|
||||
- [[Multi-Database-Architecture]]：DynamoDB 常与其他数据库（如 ElastiCache、Aurora）组合使用
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: "Amazon ElastiCache"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- In-Memory
|
||||
- Cache
|
||||
- Redis
|
||||
- Memcached
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon ElastiCache 是 AWS 全托管的内存缓存服务，支持 Redis 和 Memcached 两种引擎，是降低数据库负载和提升应用响应速度的核心组件。
|
||||
|
||||
## Key Characteristics
|
||||
- **双引擎**：Redis（全功能，支持数据结构丰富）和 Memcached（简单，高并发多核）
|
||||
- **性能**：内存访问，微秒至毫秒级延迟
|
||||
- **全托管**：自动补丁、故障恢复、备份
|
||||
- **复制**：支持只读副本，提升读取吞吐量
|
||||
|
||||
## Key Use Cases
|
||||
- **数据库缓存**：将高频读取数据缓存，减少数据库负载（典型命中率 80%+）
|
||||
- **会话存储**：用户会话数据（登录状态、购物车）
|
||||
- **实时分析**：排行榜、计数器、实时指标
|
||||
- **媒体流缓存**：视频/音乐流媒体缓存热点内容
|
||||
- **消息队列**：Redis Pub/Sub 实现发布/订阅模式
|
||||
|
||||
## Notable Users
|
||||
- **Peloton**：使用 ElastiCache Redis 为健身用户提供即时反馈（来源：[[ctp-topic-51-purpose-built-databases]]）
|
||||
- **Duolingo**：使用 ElastiCache 缓存高频词和短语（来源：[[ctp-topic-51-purpose-built-databases]]）
|
||||
|
||||
## Aliases
|
||||
- ElastiCache
|
||||
- Amazon ElastiCache
|
||||
- AWS ElastiCache
|
||||
- Amazon ElastiCache for Redis
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-RDS]]：数据库层，ElastiCache 作为缓存层配合使用
|
||||
- [[Amazon-DynamoDB]]：NoSQL 数据库，ElastiCache 可作为 DynamoDB 的读取加速层
|
||||
- [[Amazon-Aurora]]：关系型数据库，ElastiCache 可缓存 Aurora 的热点查询结果
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：ElastiCache 是 AWS 专用数据库家族中的内存缓存数据库成员
|
||||
- [[In-Memory-Database]]：内存数据库核心概念——数据驻留内存 vs 磁盘，权衡成本与性能
|
||||
- [[Multi-Database-Architecture]]：ElastiCache 常作为 Aurora/DynamoDB/RDS 的缓存层，与主数据库构成读写分离架构
|
||||
---
|
||||
title: "Amazon ElastiCache"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- In-Memory
|
||||
- Cache
|
||||
- Redis
|
||||
- Memcached
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon ElastiCache 是 AWS 全托管的内存缓存服务，支持 Redis 和 Memcached 两种引擎，是降低数据库负载和提升应用响应速度的核心组件。
|
||||
|
||||
## Key Characteristics
|
||||
- **双引擎**：Redis（全功能，支持数据结构丰富）和 Memcached（简单，高并发多核）
|
||||
- **性能**：内存访问，微秒至毫秒级延迟
|
||||
- **全托管**：自动补丁、故障恢复、备份
|
||||
- **复制**：支持只读副本，提升读取吞吐量
|
||||
|
||||
## Key Use Cases
|
||||
- **数据库缓存**：将高频读取数据缓存，减少数据库负载（典型命中率 80%+）
|
||||
- **会话存储**：用户会话数据（登录状态、购物车）
|
||||
- **实时分析**：排行榜、计数器、实时指标
|
||||
- **媒体流缓存**：视频/音乐流媒体缓存热点内容
|
||||
- **消息队列**：Redis Pub/Sub 实现发布/订阅模式
|
||||
|
||||
## Notable Users
|
||||
- **Peloton**：使用 ElastiCache Redis 为健身用户提供即时反馈（来源：[[ctp-topic-51-purpose-built-databases]]）
|
||||
- **Duolingo**：使用 ElastiCache 缓存高频词和短语（来源：[[ctp-topic-51-purpose-built-databases]]）
|
||||
|
||||
## Aliases
|
||||
- ElastiCache
|
||||
- Amazon ElastiCache
|
||||
- AWS ElastiCache
|
||||
- Amazon ElastiCache for Redis
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-RDS]]：数据库层，ElastiCache 作为缓存层配合使用
|
||||
- [[Amazon-DynamoDB]]：NoSQL 数据库，ElastiCache 可作为 DynamoDB 的读取加速层
|
||||
- [[Amazon-Aurora]]：关系型数据库，ElastiCache 可缓存 Aurora 的热点查询结果
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：ElastiCache 是 AWS 专用数据库家族中的内存缓存数据库成员
|
||||
- [[In-Memory-Database]]：内存数据库核心概念——数据驻留内存 vs 磁盘，权衡成本与性能
|
||||
- [[Multi-Database-Architecture]]：ElastiCache 常作为 Aurora/DynamoDB/RDS 的缓存层，与主数据库构成读写分离架构
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: Amazon EventBridge
|
||||
type: entity
|
||||
tags: [AWS, Event-Driven, Serverless, Observability]
|
||||
date: 2025-10-24
|
||||
---
|
||||
|
||||
## Overview
|
||||
**Amazon EventBridge** 是 AWS 的无服务器事件总线服务，用于构建事件驱动的架构。它可以接收来自 AWS 服务、SaaS 应用程序和自定义应用程序的事件，并根据定义的规则路由到目标。本方案中 EventBridge 作为跨账户事件转发的核心组件。
|
||||
|
||||
## Key Capabilities
|
||||
- **Event Bus**：默认事件总线和自定义事件总线
|
||||
- **Event Rules**：基于事件模式匹配捕获特定事件
|
||||
- **Cross-Account Event Routing**：跨账户事件转发（该方案的核心功能）
|
||||
- **Event Filtering**：基于内容的事件过滤
|
||||
- **Schema Registry**：事件模式注册和管理
|
||||
|
||||
## In This Solution
|
||||
EventBridge 在多账户 CloudFormation StackSets 监控方案中的角色：
|
||||
1. **事件捕获**：在每个成员账户部署 EventBridge Rules，捕获 CloudFormation 事件
|
||||
2. **跨账户转发**：通过 Event Bus 的跨账户访问策略，将事件转发到管理账户的 Custom Event Bus
|
||||
3. **路由到 CloudWatch**：管理账户 Event Bus 将事件路由到 central-cloudformation-logs Log Group
|
||||
|
||||
## Event Flow
|
||||
```
|
||||
Member Account: CloudFormation event
|
||||
→ EventBridge Rule (pattern match)
|
||||
→ Event Bus (custom, member account)
|
||||
→ [Cross-account permission via IAM]
|
||||
→ Event Bus (custom, management account)
|
||||
→ CloudWatch Logs (central-cloudformation-logs)
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[Cross-Account Monitoring]]：EventBridge 是跨账户监控的核心事件路由机制
|
||||
- [[Centralized Logging]]：EventBridge 将事件路由到 CloudWatch Logs 进行集中存储
|
||||
- [[Event-Driven Architecture]]：EventBridge 是 AWS 事件驱动架构的基础设施
|
||||
- [[AWS]]（entity）：EventBridge 是 AWS 无服务器服务家族的重要成员
|
||||
- [[Amazon CloudWatch Logs]]：EventBridge 将事件发送到 CloudWatch Logs
|
||||
|
||||
## Related Entities
|
||||
- [[AWS CloudFormation StackSets]]：EventBridge 监控的目标服务
|
||||
- [[AWS Organizations]]：提供跨账户权限的基础设施
|
||||
|
||||
## Sources
|
||||
- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]]
|
||||
- AWS EventBridge 官方文档
|
||||
---
|
||||
title: Amazon EventBridge
|
||||
type: entity
|
||||
tags: [AWS, Event-Driven, Serverless, Observability]
|
||||
date: 2025-10-24
|
||||
---
|
||||
|
||||
## Overview
|
||||
**Amazon EventBridge** 是 AWS 的无服务器事件总线服务，用于构建事件驱动的架构。它可以接收来自 AWS 服务、SaaS 应用程序和自定义应用程序的事件，并根据定义的规则路由到目标。本方案中 EventBridge 作为跨账户事件转发的核心组件。
|
||||
|
||||
## Key Capabilities
|
||||
- **Event Bus**：默认事件总线和自定义事件总线
|
||||
- **Event Rules**：基于事件模式匹配捕获特定事件
|
||||
- **Cross-Account Event Routing**：跨账户事件转发（该方案的核心功能）
|
||||
- **Event Filtering**：基于内容的事件过滤
|
||||
- **Schema Registry**：事件模式注册和管理
|
||||
|
||||
## In This Solution
|
||||
EventBridge 在多账户 CloudFormation StackSets 监控方案中的角色：
|
||||
1. **事件捕获**：在每个成员账户部署 EventBridge Rules，捕获 CloudFormation 事件
|
||||
2. **跨账户转发**：通过 Event Bus 的跨账户访问策略，将事件转发到管理账户的 Custom Event Bus
|
||||
3. **路由到 CloudWatch**：管理账户 Event Bus 将事件路由到 central-cloudformation-logs Log Group
|
||||
|
||||
## Event Flow
|
||||
```
|
||||
Member Account: CloudFormation event
|
||||
→ EventBridge Rule (pattern match)
|
||||
→ Event Bus (custom, member account)
|
||||
→ [Cross-account permission via IAM]
|
||||
→ Event Bus (custom, management account)
|
||||
→ CloudWatch Logs (central-cloudformation-logs)
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[Cross-Account Monitoring]]：EventBridge 是跨账户监控的核心事件路由机制
|
||||
- [[Centralized Logging]]：EventBridge 将事件路由到 CloudWatch Logs 进行集中存储
|
||||
- [[Event-Driven Architecture]]：EventBridge 是 AWS 事件驱动架构的基础设施
|
||||
- [[AWS]]（entity）：EventBridge 是 AWS 无服务器服务家族的重要成员
|
||||
- [[Amazon CloudWatch Logs]]：EventBridge 将事件发送到 CloudWatch Logs
|
||||
|
||||
## Related Entities
|
||||
- [[AWS CloudFormation StackSets]]：EventBridge 监控的目标服务
|
||||
- [[AWS Organizations]]：提供跨账户权限的基础设施
|
||||
|
||||
## Sources
|
||||
- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]]
|
||||
- AWS EventBridge 官方文档
|
||||
|
||||
@@ -1,42 +1,42 @@
|
||||
---
|
||||
title: "Amazon Keyspaces"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Wide-Column
|
||||
- Cassandra
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Keyspaces 是 AWS 全托管的 Apache Cassandra 兼容数据库（Wide-Column Database），提供无服务器选项，无需管理底层基础设施。
|
||||
|
||||
## Key Characteristics
|
||||
- **兼容性**：与 Apache Cassandra Query Language (CQL) 兼容
|
||||
- **部署模式**：提供有服务器（预置容量）和无服务器（按请求计费）两种模式
|
||||
- **规模**：支持大规模无结构 schema 的工作负载
|
||||
- **可用性**：多 AZ 部署，自动复制保证持久性
|
||||
- **管理模式**：全托管，无需运维 Cassandra 集群
|
||||
|
||||
## Key Use Cases
|
||||
- **大规模时间序列数据**：IoT 事件日志
|
||||
- **产品目录**：灵活属性的电商产品数据
|
||||
- **用户事件追踪**：高写入吞吐的用户行为分析
|
||||
- **消息历史**：聊天记录、邮件等时序消息存储
|
||||
|
||||
## Aliases
|
||||
- Keyspaces
|
||||
- Amazon Keyspaces
|
||||
- AWS Keyspaces
|
||||
- Amazon Keyspaces for Apache Cassandra
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-DynamoDB]]：均为 NoSQL，DynamoDB 是 AWS 自研的键值/文档数据库，Keyspaces 是托管版 Cassandra
|
||||
- [[Amazon-Neptune]]：图数据库，Keyspaces 是宽列数据库，适用场景不同
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：Keyspaces 是 AWS 专用数据库家族中的宽列数据库成员
|
||||
- [[Wide-Column-Database]]：宽列数据库核心概念——Cassandra 数据模型（Row Key / Column Family / Super Column）
|
||||
---
|
||||
title: "Amazon Keyspaces"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Wide-Column
|
||||
- Cassandra
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Keyspaces 是 AWS 全托管的 Apache Cassandra 兼容数据库（Wide-Column Database），提供无服务器选项，无需管理底层基础设施。
|
||||
|
||||
## Key Characteristics
|
||||
- **兼容性**：与 Apache Cassandra Query Language (CQL) 兼容
|
||||
- **部署模式**：提供有服务器（预置容量）和无服务器（按请求计费）两种模式
|
||||
- **规模**：支持大规模无结构 schema 的工作负载
|
||||
- **可用性**：多 AZ 部署，自动复制保证持久性
|
||||
- **管理模式**：全托管，无需运维 Cassandra 集群
|
||||
|
||||
## Key Use Cases
|
||||
- **大规模时间序列数据**：IoT 事件日志
|
||||
- **产品目录**：灵活属性的电商产品数据
|
||||
- **用户事件追踪**：高写入吞吐的用户行为分析
|
||||
- **消息历史**：聊天记录、邮件等时序消息存储
|
||||
|
||||
## Aliases
|
||||
- Keyspaces
|
||||
- Amazon Keyspaces
|
||||
- AWS Keyspaces
|
||||
- Amazon Keyspaces for Apache Cassandra
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-DynamoDB]]：均为 NoSQL，DynamoDB 是 AWS 自研的键值/文档数据库，Keyspaces 是托管版 Cassandra
|
||||
- [[Amazon-Neptune]]：图数据库，Keyspaces 是宽列数据库，适用场景不同
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：Keyspaces 是 AWS 专用数据库家族中的宽列数据库成员
|
||||
- [[Wide-Column-Database]]：宽列数据库核心概念——Cassandra 数据模型（Row Key / Column Family / Super Column）
|
||||
|
||||
@@ -1,34 +1,34 @@
|
||||
---
|
||||
title: "Amazon Neptune"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Graph
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Neptune 是 AWS 全托管的图数据库（Graph Database），专为高度互连数据设计，支持 Apache TinkerPop Gremlin 和 SPARQL 查询语言。
|
||||
|
||||
## Key Use Cases
|
||||
- **欺诈检测**：发现传统关系型数据库难以识别的关联模式
|
||||
- **社交网络**：好友推荐、共同联系人分析
|
||||
- **推荐系统**：基于用户行为图的个性化推荐
|
||||
- **知识图谱**：实体关系的存储与查询
|
||||
|
||||
## Aliases
|
||||
- Neptune
|
||||
- Amazon Neptune
|
||||
- AWS Neptune
|
||||
- Amazon Neptune Graph Database
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-DynamoDB]]：NoSQL 键值数据库，Neptune 处理高度互连数据，DynamoDB 处理简单键值访问
|
||||
- [[Amazon-RDS]]：关系型数据库，Neptune 在关联复杂度的场景优于关系型数据库
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：Neptune 是 AWS 专用数据库家族中的图数据库成员
|
||||
- [[Graph-Database]]：图数据库的核心概念——节点（实体）、边（关系）、属性
|
||||
---
|
||||
title: "Amazon Neptune"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Graph
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Neptune 是 AWS 全托管的图数据库（Graph Database），专为高度互连数据设计，支持 Apache TinkerPop Gremlin 和 SPARQL 查询语言。
|
||||
|
||||
## Key Use Cases
|
||||
- **欺诈检测**：发现传统关系型数据库难以识别的关联模式
|
||||
- **社交网络**：好友推荐、共同联系人分析
|
||||
- **推荐系统**：基于用户行为图的个性化推荐
|
||||
- **知识图谱**：实体关系的存储与查询
|
||||
|
||||
## Aliases
|
||||
- Neptune
|
||||
- Amazon Neptune
|
||||
- AWS Neptune
|
||||
- Amazon Neptune Graph Database
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-DynamoDB]]：NoSQL 键值数据库，Neptune 处理高度互连数据，DynamoDB 处理简单键值访问
|
||||
- [[Amazon-RDS]]：关系型数据库，Neptune 在关联复杂度的场景优于关系型数据库
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：Neptune 是 AWS 专用数据库家族中的图数据库成员
|
||||
- [[Graph-Database]]：图数据库的核心概念——节点（实体）、边（关系）、属性
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "Amazon RDS"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Relational Database
|
||||
- Managed Service
|
||||
sources:
|
||||
- ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon RDS（Relational Database Service）是 AWS 提供的托管关系型数据库服务，计算（EC2）与存储（EBS）分离，支持 Multi-AZ 部署，相比 Aurora 成本更低、存储选项更灵活。
|
||||
|
||||
## Core Architecture
|
||||
- **Compute + Storage Separation**：EC2 计算节点 + EBS 存储卷的分离架构
|
||||
- **Multi-AZ Deployment**：主节点 + 备用节点（独立计算和存储），故障时备用节点接管
|
||||
- **Single Endpoint**：每个集群一个端点（不同于 Aurora 的 Writer/Reader 分离）
|
||||
|
||||
## Key Advantages
|
||||
- **更低入门成本**：提供更小规格实例，适合小型数据库
|
||||
- **存储灵活性**：支持 GP2、GP3、预置 IOPS、磁性存储多种类型
|
||||
- **广泛引擎支持**：PostgreSQL、MySQL、MariaDB、Oracle、SQL Server 等
|
||||
- **更成熟**：发布更久，文档和社区资源更丰富
|
||||
|
||||
## Key Limitations
|
||||
- **RTO 2 分钟**：AZ 故障时恢复时间目标约 2 分钟
|
||||
- **读副本需数据复制**：新增读副本需重新复制数据
|
||||
- **无 Blue-Green Deployment**（PostgreSQL/MySQL 均不支持跨版本 Blue-Green）
|
||||
- **最大 IO 受 EBS 限制**：不如 Aurora 的无上限 IO 能力
|
||||
|
||||
## Storage Types
|
||||
| 类型 | 特点 | 适用场景 |
|
||||
|------|------|----------|
|
||||
| GP2 | 通用 SSD，平衡性能与成本 | 大多数工作负载 |
|
||||
| GP3 | 通用 SSD，独立性能配置 | 需要成本优化的场景 |
|
||||
| 预置 IOPS | 高性能，稳定的 IOPS | IO 密集型应用 |
|
||||
| 磁性 | 低成本，较低性能 | 归档/不常访问的数据 |
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon Aurora]]：云原生数据库，性能更高但成本更高
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[EBS]]：Elastic Block Store，RDS 的存储后端
|
||||
- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]：AWS 专用数据库架构
|
||||
- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：RDS vs Aurora 详细对比
|
||||
|
||||
## Aliases
|
||||
- RDS
|
||||
- Amazon RDS
|
||||
- RDS PostgreSQL
|
||||
- Amazon Relational Database Service
|
||||
- AWS RDS
|
||||
---
|
||||
title: "Amazon RDS"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Relational Database
|
||||
- Managed Service
|
||||
sources:
|
||||
- ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon RDS（Relational Database Service）是 AWS 提供的托管关系型数据库服务，计算（EC2）与存储（EBS）分离，支持 Multi-AZ 部署，相比 Aurora 成本更低、存储选项更灵活。
|
||||
|
||||
## Core Architecture
|
||||
- **Compute + Storage Separation**：EC2 计算节点 + EBS 存储卷的分离架构
|
||||
- **Multi-AZ Deployment**：主节点 + 备用节点（独立计算和存储），故障时备用节点接管
|
||||
- **Single Endpoint**：每个集群一个端点（不同于 Aurora 的 Writer/Reader 分离）
|
||||
|
||||
## Key Advantages
|
||||
- **更低入门成本**：提供更小规格实例，适合小型数据库
|
||||
- **存储灵活性**：支持 GP2、GP3、预置 IOPS、磁性存储多种类型
|
||||
- **广泛引擎支持**：PostgreSQL、MySQL、MariaDB、Oracle、SQL Server 等
|
||||
- **更成熟**：发布更久，文档和社区资源更丰富
|
||||
|
||||
## Key Limitations
|
||||
- **RTO 2 分钟**：AZ 故障时恢复时间目标约 2 分钟
|
||||
- **读副本需数据复制**：新增读副本需重新复制数据
|
||||
- **无 Blue-Green Deployment**（PostgreSQL/MySQL 均不支持跨版本 Blue-Green）
|
||||
- **最大 IO 受 EBS 限制**：不如 Aurora 的无上限 IO 能力
|
||||
|
||||
## Storage Types
|
||||
| 类型 | 特点 | 适用场景 |
|
||||
|------|------|----------|
|
||||
| GP2 | 通用 SSD，平衡性能与成本 | 大多数工作负载 |
|
||||
| GP3 | 通用 SSD，独立性能配置 | 需要成本优化的场景 |
|
||||
| 预置 IOPS | 高性能，稳定的 IOPS | IO 密集型应用 |
|
||||
| 磁性 | 低成本，较低性能 | 归档/不常访问的数据 |
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon Aurora]]：云原生数据库，性能更高但成本更高
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[EBS]]：Elastic Block Store，RDS 的存储后端
|
||||
- [[ctp-topic-51-architecting-with-aws-purpose-built-databases]]：AWS 专用数据库架构
|
||||
- [[ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora]]：RDS vs Aurora 详细对比
|
||||
|
||||
## Aliases
|
||||
- RDS
|
||||
- Amazon RDS
|
||||
- RDS PostgreSQL
|
||||
- Amazon Relational Database Service
|
||||
- AWS RDS
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "Amazon Redshift"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Data-Warehouse
|
||||
- OLAP
|
||||
- Managed Service
|
||||
sources:
|
||||
- ctp-topic-68-introduction-to-redshift
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Redshift 是 AWS 提供的大规模并行处理（MPP）云数据仓库服务，支持 PB 级数据存储，面向 OLAP（在线分析处理）工作负载。完全托管，无需自行管理基础设施，具备自动备份、点时间恢复和跨区域灾难恢复能力。
|
||||
|
||||
## Core Architecture
|
||||
- **Leader Node**：协调节点，负责客户端连接（JDBC/ODBC）、Schema 管理、仓库元数据和查询计划生成，将查询指令分发至 Compute Node
|
||||
- **Compute Node**：执行节点，根据实例类型决定节点数量，每个节点在 Slices 上并行处理数据，完成后返回结果至 Leader Node
|
||||
- **Slices**：Compute Node 内部的虚拟分区，每个 Slice 独立处理数据子集，实现并行计算
|
||||
|
||||
## Instance Types
|
||||
| 类型 | 特点 | 适用场景 |
|
||||
|------|------|----------|
|
||||
| Dense Compute | 高 CPU + 内存，适合计算密集型查询 | 大规模数据分析 |
|
||||
| Dense Storage | 高存储，适合存储密集型工作负载 | 历史数据归档 |
|
||||
| RA3 | 性价比最优，AWS 托管 NVMe 存储，可独立扩展计算和存储 | 大容量数据仓库（推荐） |
|
||||
|
||||
## Key Features
|
||||
- **MPP（大规模并行处理）**：跨多个 Compute Node 并行执行查询，显著提升查询速度和响应时间
|
||||
- **列式存储（Columnar Storage）**：数据按列存储，适合聚合查询和全表扫描，相比行式存储 I/O 效率更高
|
||||
- **行式存储（Row Storage）**：适合少量行的精确查询和点查询
|
||||
- **数据压缩**：采用 ZSTD/LZO 等压缩算法，减少存储空间和 I/O 开销
|
||||
- **Sort Key（排序键）**：决定数据在磁盘上的物理排序顺序，优化范围查询和过滤操作
|
||||
- **Distribution Key（分布键）**：决定数据在 Compute Node 间的分布方式，影响数据倾斜和跨节点数据传输
|
||||
|
||||
## Comparison with Other AWS Databases
|
||||
- **vs Amazon RDS/Aurora**：RDS/Aurora 面向 OLTP（事务处理），Redshift 面向 OLAP（分析处理）；RDS/Aurora 适合写入密集型，Redshift 适合读取/分析密集型
|
||||
- **vs Amazon DynamoDB**：DynamoDB 面向 NoSQL 键值/文档场景，Redshift 面向复杂 SQL 分析查询
|
||||
- **vs Amazon Aurora**：Aurora 共享存储架构（6副本跨3 AZ），Redshift 独立 Compute Node 架构；Aurora 适合 10TB 以下场景，Redshift 适合 PB 级分析
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon RDS]]：托管关系型数据库，面向 OLTP
|
||||
- [[Amazon Aurora]]：云原生关系型数据库，共享存储架构
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[ctp-topic-68-introduction-to-redshift]]：Redshift 入门介绍
|
||||
- [[ctp-topic-51-purpose-built-databases]]：AWS 专用数据库选型全景
|
||||
- [[ctp-topic-66-rds-vs-aurora]]：RDS 与 Aurora 对比参考
|
||||
|
||||
## Aliases
|
||||
- Redshift
|
||||
- Amazon Redshift
|
||||
- AWS Redshift
|
||||
- Redshift Data Warehouse
|
||||
---
|
||||
title: "Amazon Redshift"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Data-Warehouse
|
||||
- OLAP
|
||||
- Managed Service
|
||||
sources:
|
||||
- ctp-topic-68-introduction-to-redshift
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Redshift 是 AWS 提供的大规模并行处理（MPP）云数据仓库服务，支持 PB 级数据存储，面向 OLAP（在线分析处理）工作负载。完全托管，无需自行管理基础设施，具备自动备份、点时间恢复和跨区域灾难恢复能力。
|
||||
|
||||
## Core Architecture
|
||||
- **Leader Node**：协调节点，负责客户端连接（JDBC/ODBC）、Schema 管理、仓库元数据和查询计划生成，将查询指令分发至 Compute Node
|
||||
- **Compute Node**：执行节点，根据实例类型决定节点数量，每个节点在 Slices 上并行处理数据，完成后返回结果至 Leader Node
|
||||
- **Slices**：Compute Node 内部的虚拟分区，每个 Slice 独立处理数据子集，实现并行计算
|
||||
|
||||
## Instance Types
|
||||
| 类型 | 特点 | 适用场景 |
|
||||
|------|------|----------|
|
||||
| Dense Compute | 高 CPU + 内存，适合计算密集型查询 | 大规模数据分析 |
|
||||
| Dense Storage | 高存储，适合存储密集型工作负载 | 历史数据归档 |
|
||||
| RA3 | 性价比最优，AWS 托管 NVMe 存储，可独立扩展计算和存储 | 大容量数据仓库（推荐） |
|
||||
|
||||
## Key Features
|
||||
- **MPP（大规模并行处理）**：跨多个 Compute Node 并行执行查询，显著提升查询速度和响应时间
|
||||
- **列式存储（Columnar Storage）**：数据按列存储，适合聚合查询和全表扫描，相比行式存储 I/O 效率更高
|
||||
- **行式存储（Row Storage）**：适合少量行的精确查询和点查询
|
||||
- **数据压缩**：采用 ZSTD/LZO 等压缩算法，减少存储空间和 I/O 开销
|
||||
- **Sort Key（排序键）**：决定数据在磁盘上的物理排序顺序，优化范围查询和过滤操作
|
||||
- **Distribution Key（分布键）**：决定数据在 Compute Node 间的分布方式，影响数据倾斜和跨节点数据传输
|
||||
|
||||
## Comparison with Other AWS Databases
|
||||
- **vs Amazon RDS/Aurora**：RDS/Aurora 面向 OLTP（事务处理），Redshift 面向 OLAP（分析处理）；RDS/Aurora 适合写入密集型，Redshift 适合读取/分析密集型
|
||||
- **vs Amazon DynamoDB**：DynamoDB 面向 NoSQL 键值/文档场景，Redshift 面向复杂 SQL 分析查询
|
||||
- **vs Amazon Aurora**：Aurora 共享存储架构（6副本跨3 AZ），Redshift 独立 Compute Node 架构；Aurora 适合 10TB 以下场景，Redshift 适合 PB 级分析
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon RDS]]：托管关系型数据库，面向 OLTP
|
||||
- [[Amazon Aurora]]：云原生关系型数据库，共享存储架构
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[ctp-topic-68-introduction-to-redshift]]：Redshift 入门介绍
|
||||
- [[ctp-topic-51-purpose-built-databases]]：AWS 专用数据库选型全景
|
||||
- [[ctp-topic-66-rds-vs-aurora]]：RDS 与 Aurora 对比参考
|
||||
|
||||
## Aliases
|
||||
- Redshift
|
||||
- Amazon Redshift
|
||||
- AWS Redshift
|
||||
- Redshift Data Warehouse
|
||||
|
||||
@@ -1,41 +1,41 @@
|
||||
---
|
||||
title: "Amazon Timestream"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Time-Series
|
||||
- IoT
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Timestream 是 AWS 全托管的时序数据库（Time-Series Database），专为高吞吐量时序数据设计，支持自动数据分层（热存储/冷存储）。
|
||||
|
||||
## Key Use Cases
|
||||
- **IoT 传感器数据**：温度、压力、位置等设备遥测数据
|
||||
- **应用监控**：指标、日志、追踪数据的存储与分析
|
||||
- **工业遥测**：生产线设备状态监控
|
||||
- **金融数据**：股票价格、交易事件等时间序列分析
|
||||
|
||||
## Key Characteristics
|
||||
- **数据模型**：时间戳 + 测量值 + 维度
|
||||
- **自动分层**：热存储（Recent data）→ 冷存储（Historical data），自动降本
|
||||
- **查询引擎**：内置时序分析函数（插值、聚合、窗口函数）
|
||||
- **性能**：专为高写入吞吐量优化，支持数百万设备并发写入
|
||||
|
||||
## Aliases
|
||||
- Timestream
|
||||
- Amazon Timestream
|
||||
- AWS Timestream
|
||||
- Amazon Timestream for IoT Analytics
|
||||
|
||||
## Related Entities
|
||||
- [[Prometheus]]：时序监控数据采集器，Timestream 可作为其长期存储后端
|
||||
- [[Amazon-DynamoDB]]：通用 NoSQL 数据库，Timestream 在时序场景有 10-100 倍成本优势
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：Timestream 是 AWS 专用数据库家族中的时序数据库成员
|
||||
- [[Time-Series-Database]]：时序数据库核心概念——时间戳索引、数据分层、降采样查询
|
||||
---
|
||||
title: "Amazon Timestream"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Database
|
||||
- Time-Series
|
||||
- IoT
|
||||
sources:
|
||||
- ctp-topic-51-architecting-with-aws-purpose-built-databases
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Amazon Timestream 是 AWS 全托管的时序数据库（Time-Series Database），专为高吞吐量时序数据设计，支持自动数据分层（热存储/冷存储）。
|
||||
|
||||
## Key Use Cases
|
||||
- **IoT 传感器数据**：温度、压力、位置等设备遥测数据
|
||||
- **应用监控**：指标、日志、追踪数据的存储与分析
|
||||
- **工业遥测**：生产线设备状态监控
|
||||
- **金融数据**：股票价格、交易事件等时间序列分析
|
||||
|
||||
## Key Characteristics
|
||||
- **数据模型**：时间戳 + 测量值 + 维度
|
||||
- **自动分层**：热存储（Recent data）→ 冷存储（Historical data），自动降本
|
||||
- **查询引擎**：内置时序分析函数（插值、聚合、窗口函数）
|
||||
- **性能**：专为高写入吞吐量优化，支持数百万设备并发写入
|
||||
|
||||
## Aliases
|
||||
- Timestream
|
||||
- Amazon Timestream
|
||||
- AWS Timestream
|
||||
- Amazon Timestream for IoT Analytics
|
||||
|
||||
## Related Entities
|
||||
- [[Prometheus]]：时序监控数据采集器，Timestream 可作为其长期存储后端
|
||||
- [[Amazon-DynamoDB]]：通用 NoSQL 数据库，Timestream 在时序场景有 10-100 倍成本优势
|
||||
|
||||
## Related Concepts
|
||||
- [[Purpose-Built-Databases]]：Timestream 是 AWS 专用数据库家族中的时序数据库成员
|
||||
- [[Time-Series-Database]]：时序数据库核心概念——时间戳索引、数据分层、降采样查询
|
||||
|
||||
@@ -1,30 +1,30 @@
|
||||
---
|
||||
title: "Amazon Ads"
|
||||
type: entity
|
||||
tags: ["paid-media", "advertising", "ecommerce", "platform"]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Amazon Advertising
|
||||
- Amazon PPC
|
||||
- AMS (Amazon Marketing Services)
|
||||
|
||||
## Overview
|
||||
Amazon Ads 是亚马逊的广告平台，在电商购买场景下触达高购买意图用户。是 [[PaidMediaPpcStrategist]] 跨平台预算分配的关键组成部分。
|
||||
|
||||
## Key Capabilities
|
||||
- **Sponsored Products**: 关键词驱动的产品广告，出现在搜索结果和详情页
|
||||
- **Sponsored Brands**: 品牌展示广告，展示多个产品或品牌旗舰店
|
||||
- **Sponsored Display**: 展示型广告，覆盖亚马逊站内及站外受众
|
||||
- **Amazon DSP**: 需求方平台，支持程序化购买站内外优质广告位
|
||||
- **Amazon Marketing Cloud (AMC)**: 数据分析平台，支持跨触点归因分析
|
||||
|
||||
## Key Features Used by PPC Strategist
|
||||
- 购物广告系列与 Google Shopping 协同
|
||||
- 基于购买意向的受众触达
|
||||
- 站内搜索场景的竞争情报
|
||||
|
||||
## Connections
|
||||
- [[PaidMediaPpcStrategist]] 将 Amazon Ads 纳入跨平台预算分配框架
|
||||
- [[GoogleAds]] Shopping 与 Amazon Sponsored Products 在产品广告策略上有相似性
|
||||
---
|
||||
title: "Amazon Ads"
|
||||
type: entity
|
||||
tags: ["paid-media", "advertising", "ecommerce", "platform"]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Amazon Advertising
|
||||
- Amazon PPC
|
||||
- AMS (Amazon Marketing Services)
|
||||
|
||||
## Overview
|
||||
Amazon Ads 是亚马逊的广告平台，在电商购买场景下触达高购买意图用户。是 [[PaidMediaPpcStrategist]] 跨平台预算分配的关键组成部分。
|
||||
|
||||
## Key Capabilities
|
||||
- **Sponsored Products**: 关键词驱动的产品广告，出现在搜索结果和详情页
|
||||
- **Sponsored Brands**: 品牌展示广告，展示多个产品或品牌旗舰店
|
||||
- **Sponsored Display**: 展示型广告，覆盖亚马逊站内及站外受众
|
||||
- **Amazon DSP**: 需求方平台，支持程序化购买站内外优质广告位
|
||||
- **Amazon Marketing Cloud (AMC)**: 数据分析平台，支持跨触点归因分析
|
||||
|
||||
## Key Features Used by PPC Strategist
|
||||
- 购物广告系列与 Google Shopping 协同
|
||||
- 基于购买意向的受众触达
|
||||
- 站内搜索场景的竞争情报
|
||||
|
||||
## Connections
|
||||
- [[PaidMediaPpcStrategist]] 将 Amazon Ads 纳入跨平台预算分配框架
|
||||
- [[GoogleAds]] Shopping 与 Amazon Sponsored Products 在产品广告策略上有相似性
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
---
|
||||
title: "Andrej Karpathy"
|
||||
type: entity
|
||||
tags: [ai, deep-learning, openai]
|
||||
---
|
||||
|
||||
## Profile
|
||||
AI 领域知名专家，曾任特斯拉 AI 总监、OpenAI 创始成员之一，现活跃于 AI 教育与开源社区。以深入浅出的技术讲解著称，创办了知名的斯坦福 CS231n 课程。
|
||||
|
||||
## Role
|
||||
- **Vibe Coding 概念推广者**：提出"我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来"的经典描述
|
||||
- **AI 教育者**：通过 YouTube 视频普及深度学习、LLM 应用等知识
|
||||
- **LLM Wiki 倡导者**：分享用 LLM 构建个人知识库的理念，倡导"让 AI 增量构建 Wiki，页面间互链，知识越积越厚"
|
||||
|
||||
## Sources
|
||||
- [[github-上-5000-人收藏的-vibe-coding-神级指南]]
|
||||
- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]]
|
||||
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
|
||||
|
||||
## Aliases
|
||||
- Karpathy
|
||||
- Andrej
|
||||
---
|
||||
title: "Andrej Karpathy"
|
||||
type: entity
|
||||
tags: [ai, deep-learning, openai]
|
||||
---
|
||||
|
||||
## Profile
|
||||
AI 领域知名专家，曾任特斯拉 AI 总监、OpenAI 创始成员之一，现活跃于 AI 教育与开源社区。以深入浅出的技术讲解著称，创办了知名的斯坦福 CS231n 课程。
|
||||
|
||||
## Role
|
||||
- **Vibe Coding 概念推广者**：提出"我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来"的经典描述
|
||||
- **AI 教育者**：通过 YouTube 视频普及深度学习、LLM 应用等知识
|
||||
- **LLM Wiki 倡导者**：分享用 LLM 构建个人知识库的理念，倡导"让 AI 增量构建 Wiki，页面间互链，知识越积越厚"
|
||||
|
||||
## Sources
|
||||
- [[github-上-5000-人收藏的-vibe-coding-神级指南]]
|
||||
- [[karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环]]
|
||||
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
|
||||
|
||||
## Aliases
|
||||
- Karpathy
|
||||
- Andrej
|
||||
|
||||
@@ -1,30 +1,30 @@
|
||||
---
|
||||
title: "Anthropic"
|
||||
type: entity
|
||||
tags: [AI, Claude, Anthropic]
|
||||
sources: [google-5个agent-skill设计模式-2026-03-19]
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
Anthropic 是一家 AI 安全公司，开发了 Claude 系列大语言模型和 Claude Code CLI Agent。其在 Skill 设计方面的实践经验（9 类分类、3 条铁律）被 Google ADK 指南引用。
|
||||
|
||||
## Key Contributions
|
||||
- **Claude Code**：Anthropic 的 CLI Agent，支持 SKILL.md 格式标准化
|
||||
- **9 类 Skill 分类**：从参考手册到故障排查，每类有明确场景
|
||||
- **3 条铁律**：
|
||||
1. 只写 Agent 不知道的东西
|
||||
2. 重点写踩坑清单
|
||||
3. 给工具不给指令
|
||||
|
||||
## Key Insight
|
||||
> "最好的 Skill 不是写得好的提示词，而是一个「工具箱」。" — Anthropic
|
||||
|
||||
## Related Entities
|
||||
- [[GoogleCloud]]：引用了 Anthropic 的 Skill 实践经验
|
||||
- [[ClaudeCode]]：Anthropic 开发的 CLI Agent
|
||||
- [[ADK]]：Google Cloud 的 Agent 开发工具包
|
||||
|
||||
## Connections
|
||||
- [[AnthropicSkill实践]] ← authored_by ← [[Anthropic]]
|
||||
- [[Google5个AgentSkill设计模式]] ← extends ← [[AnthropicSkill实践]]
|
||||
---
|
||||
title: "Anthropic"
|
||||
type: entity
|
||||
tags: [AI, Claude, Anthropic]
|
||||
sources: [google-5个agent-skill设计模式-2026-03-19]
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
Anthropic 是一家 AI 安全公司，开发了 Claude 系列大语言模型和 Claude Code CLI Agent。其在 Skill 设计方面的实践经验（9 类分类、3 条铁律）被 Google ADK 指南引用。
|
||||
|
||||
## Key Contributions
|
||||
- **Claude Code**：Anthropic 的 CLI Agent，支持 SKILL.md 格式标准化
|
||||
- **9 类 Skill 分类**：从参考手册到故障排查，每类有明确场景
|
||||
- **3 条铁律**：
|
||||
1. 只写 Agent 不知道的东西
|
||||
2. 重点写踩坑清单
|
||||
3. 给工具不给指令
|
||||
|
||||
## Key Insight
|
||||
> "最好的 Skill 不是写得好的提示词，而是一个「工具箱」。" — Anthropic
|
||||
|
||||
## Related Entities
|
||||
- [[GoogleCloud]]：引用了 Anthropic 的 Skill 实践经验
|
||||
- [[ClaudeCode]]：Anthropic 开发的 CLI Agent
|
||||
- [[ADK]]：Google Cloud 的 Agent 开发工具包
|
||||
|
||||
## Connections
|
||||
- [[AnthropicSkill实践]] ← authored_by ← [[Anthropic]]
|
||||
- [[Google5个AgentSkill设计模式]] ← extends ← [[AnthropicSkill实践]]
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: "Apache Superset"
|
||||
type: entity
|
||||
aliases:
|
||||
- Superset
|
||||
- Apache Superset
|
||||
tags: [apache, bi, docker, data-visualization]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
# Apache Superset
|
||||
|
||||
## Overview
|
||||
Apache Superset 是 Apache 软件基金会旗下的开源 **Business Intelligence (BI) 平台**，提供数据可视化、仪表盘构建、SQL 查询和数据分析功能。Superset 基于 **Flask-AppBuilder**（Fab）框架构建，支持通过插件扩展图表类型，并与多种数据源集成（MySQL、PostgreSQL、SQLite、Druid 等）。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**: Product / Open Source Project
|
||||
- **维护方**: Apache Software Foundation
|
||||
- **编程语言**: Python (Flask)
|
||||
- **前端**: React
|
||||
- **默认端口**: 8088
|
||||
- **默认数据库**: SQLite（生产环境建议外挂 PostgreSQL 或 MySQL）
|
||||
|
||||
## Docker 部署
|
||||
通过 Docker 镜像容器化部署是 Home Server 场景的推荐方式：
|
||||
- **镜像**: `apache/superset:GHA-*`（GitHub Actions 构建版本）
|
||||
- **6 步初始化流程**:
|
||||
1. `docker pull apache/superset:GHA-*`
|
||||
2. `docker run -d -p 8777:8088 -e SUPERSET_SECRET_KEY=... --name superset apache/superset:GHA-*`
|
||||
3. `docker exec -it superset superset fab create-admin`（创建管理员账户）
|
||||
4. `docker exec -it superset superset db upgrade`（数据库迁移）
|
||||
5. `docker exec -it superset superset load_examples`（加载示例数据）
|
||||
6. `docker exec -it superset superset init`（完成初始化）
|
||||
- **端口映射**: 宿主机 8777 → 容器 8088
|
||||
|
||||
## Related Entities
|
||||
- [[Docker]] — 部署底座
|
||||
- [[MySQL]] — 支持的外挂数据库后端
|
||||
- [[Portainer]] — 可用于管理 Superset 容器生命周期
|
||||
- [[Jellyfin]] — 同属 Home Server 可视化服务系列（视频 vs 数据）
|
||||
- [[Prometheus]] — 可作为数据源接入 Superset
|
||||
- [[Grafana]] — 功能重叠的替代方案，Superset 更偏重 BI/Gallery，Grafana 更偏重监控
|
||||
|
||||
## Related Concepts
|
||||
- [[BI平台]] — 核心概念定义
|
||||
- [[数据可视化]] — 核心应用场景
|
||||
- [[Docker容器化部署]] — 部署方法论
|
||||
|
||||
## Sources
|
||||
- [[用docker安装apache-superset]]
|
||||
---
|
||||
title: "Apache Superset"
|
||||
type: entity
|
||||
aliases:
|
||||
- Superset
|
||||
- Apache Superset
|
||||
tags: [apache, bi, docker, data-visualization]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
# Apache Superset
|
||||
|
||||
## Overview
|
||||
Apache Superset 是 Apache 软件基金会旗下的开源 **Business Intelligence (BI) 平台**，提供数据可视化、仪表盘构建、SQL 查询和数据分析功能。Superset 基于 **Flask-AppBuilder**（Fab）框架构建，支持通过插件扩展图表类型，并与多种数据源集成（MySQL、PostgreSQL、SQLite、Druid 等）。
|
||||
|
||||
## Key Attributes
|
||||
- **类型**: Product / Open Source Project
|
||||
- **维护方**: Apache Software Foundation
|
||||
- **编程语言**: Python (Flask)
|
||||
- **前端**: React
|
||||
- **默认端口**: 8088
|
||||
- **默认数据库**: SQLite（生产环境建议外挂 PostgreSQL 或 MySQL）
|
||||
|
||||
## Docker 部署
|
||||
通过 Docker 镜像容器化部署是 Home Server 场景的推荐方式：
|
||||
- **镜像**: `apache/superset:GHA-*`（GitHub Actions 构建版本）
|
||||
- **6 步初始化流程**:
|
||||
1. `docker pull apache/superset:GHA-*`
|
||||
2. `docker run -d -p 8777:8088 -e SUPERSET_SECRET_KEY=... --name superset apache/superset:GHA-*`
|
||||
3. `docker exec -it superset superset fab create-admin`（创建管理员账户）
|
||||
4. `docker exec -it superset superset db upgrade`（数据库迁移）
|
||||
5. `docker exec -it superset superset load_examples`（加载示例数据）
|
||||
6. `docker exec -it superset superset init`（完成初始化）
|
||||
- **端口映射**: 宿主机 8777 → 容器 8088
|
||||
|
||||
## Related Entities
|
||||
- [[Docker]] — 部署底座
|
||||
- [[MySQL]] — 支持的外挂数据库后端
|
||||
- [[Portainer]] — 可用于管理 Superset 容器生命周期
|
||||
- [[Jellyfin]] — 同属 Home Server 可视化服务系列（视频 vs 数据）
|
||||
- [[Prometheus]] — 可作为数据源接入 Superset
|
||||
- [[Grafana]] — 功能重叠的替代方案，Superset 更偏重 BI/Gallery，Grafana 更偏重监控
|
||||
|
||||
## Related Concepts
|
||||
- [[BI平台]] — 核心概念定义
|
||||
- [[数据可视化]] — 核心应用场景
|
||||
- [[Docker容器化部署]] — 部署方法论
|
||||
|
||||
## Sources
|
||||
- [[用docker安装apache-superset]]
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
---
|
||||
title: "Asana"
|
||||
type: entity
|
||||
tags: [productivity, task-management, collaboration]
|
||||
sources: [multi-channel-assistant, custom-morning-brief]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Asana 是一个企业级工作管理平台，支持项目追踪、团队协作和任务管理，被 OpenClaw 多 Agent 工作流广泛集成作为任务数据来源。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Asana
|
||||
- asana
|
||||
|
||||
## Role in System
|
||||
|
||||
- 作为 [[OpenClaw]] Agent 工作流的标准任务集成目标之一（与 Todoist / Apple Reminders 并列）
|
||||
- 在 [[custom-morning-brief]] 中用于拉取当日待办事项，纳入晨间简报
|
||||
- 在 [[multi-channel-assistant]] 中作为统一任务管理后端
|
||||
|
||||
## Key Relationships
|
||||
|
||||
- [[OpenClaw]] — 集成 Asana 作为任务管理后端
|
||||
- [[Todoist]] — Asana 的竞品，同为待办列表集成选项
|
||||
- [[Apple Reminders]] — Asana 的竞品，同为待办列表集成选项
|
||||
---
|
||||
title: "Asana"
|
||||
type: entity
|
||||
tags: [productivity, task-management, collaboration]
|
||||
sources: [multi-channel-assistant, custom-morning-brief]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Asana 是一个企业级工作管理平台，支持项目追踪、团队协作和任务管理，被 OpenClaw 多 Agent 工作流广泛集成作为任务数据来源。
|
||||
|
||||
## Aliases
|
||||
|
||||
- Asana
|
||||
- asana
|
||||
|
||||
## Role in System
|
||||
|
||||
- 作为 [[OpenClaw]] Agent 工作流的标准任务集成目标之一（与 Todoist / Apple Reminders 并列）
|
||||
- 在 [[custom-morning-brief]] 中用于拉取当日待办事项，纳入晨间简报
|
||||
- 在 [[multi-channel-assistant]] 中作为统一任务管理后端
|
||||
|
||||
## Key Relationships
|
||||
|
||||
- [[OpenClaw]] — 集成 Asana 作为任务管理后端
|
||||
- [[Todoist]] — Asana 的竞品，同为待办列表集成选项
|
||||
- [[Apple Reminders]] — Asana 的竞品，同为待办列表集成选项
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: "Ashish"
|
||||
type: entity
|
||||
tags: [Micro Focus, Security, Container, Kubernetes]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Basic Information
|
||||
- **Role:** Member, Product Security Group
|
||||
- **Organization:** [[Micro Focus]]
|
||||
- **Expertise:** Container Security, Kubernetes Hardening
|
||||
|
||||
## Description
|
||||
Ashish 是 Micro Focus Product Security Group 的成员，在 CTP Topic 49 分享了容器镜像构建阶段的安全加固标准。演讲涵盖了 11 条可操作的安全实践，通过 Demo 演示了配置效果。
|
||||
|
||||
## Aliases
|
||||
- Ashish
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-49-container-lifecycle-hardening-standards]]
|
||||
---
|
||||
title: "Ashish"
|
||||
type: entity
|
||||
tags: [Micro Focus, Security, Container, Kubernetes]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Basic Information
|
||||
- **Role:** Member, Product Security Group
|
||||
- **Organization:** [[Micro Focus]]
|
||||
- **Expertise:** Container Security, Kubernetes Hardening
|
||||
|
||||
## Description
|
||||
Ashish 是 Micro Focus Product Security Group 的成员，在 CTP Topic 49 分享了容器镜像构建阶段的安全加固标准。演讲涵盖了 11 条可操作的安全实践，通过 Demo 演示了配置效果。
|
||||
|
||||
## Aliases
|
||||
- Ashish
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-49-container-lifecycle-hardening-standards]]
|
||||
|
||||
@@ -1,95 +1,95 @@
|
||||
---
|
||||
title: "Atlantis"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- terraform
|
||||
- gitops
|
||||
- cicd
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# Atlantis
|
||||
|
||||
## Definition
|
||||
|
||||
Atlantis 是一个开源的**Terraform CI/CD 工具**，通过与 GitHub/GitLab 深度集成，将 Terraform 的 plan 和 apply 操作转移到 Pull Request（PR）评论层面，实现基础设施即代码的协作式自动化部署。
|
||||
|
||||
## Core Model: PR-Driven IaC
|
||||
|
||||
Atlantis 的核心理念：**每个 Pull Request 都是一次 Terraform 操作**。
|
||||
|
||||
```
|
||||
Developer Atlantis AWS Accounts
|
||||
│ │ │
|
||||
│ 1. Open PR │ │
|
||||
│───────────────────────>│ │
|
||||
│ │ 2. !atlantis plan │
|
||||
│ │───────────────────────>│
|
||||
│ │<───────────────────────│ 3. terraform plan
|
||||
│ 4. Post plan result │ │
|
||||
│<───────────────────────│ │
|
||||
│ 5. Review & Approve │ │
|
||||
│───────────────────────>│ │
|
||||
│ │ 6. !atlantis apply │
|
||||
│ │───────────────────────>│
|
||||
│ │<───────────────────────│ 7. terraform apply
|
||||
│ 8. Merge PR │ │
|
||||
│───────────────────────>│ │
|
||||
```
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Key Features
|
||||
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| **PR 评论触发** | 无需独立 CI 账号，开发者在 PR 上评论即可 |
|
||||
| **并行 plan/apply** | 多模块并发执行，提升部署效率 |
|
||||
| **锁定机制** | 防止多 PR 同时操作同一模块产生冲突 |
|
||||
| **跨账户访问** | 通过 IAM 角色实现多 AWS 账户部署 |
|
||||
| **零额外基础设施** | 只需一台 EC2 共享账户实例 |
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Comparison: Atlantis vs Jenkins
|
||||
|
||||
| 维度 | Atlantis | Jenkins |
|
||||
|------|----------|---------|
|
||||
| 触发方式 | PR 评论 | SCM 轮询/定时 |
|
||||
| 初始化速度 | 快速（按需） | 慢（Jenkins 预配置） |
|
||||
| 代码克隆 | 单次 | 多次 |
|
||||
| 测试执行 | 并行 | 顺序 |
|
||||
| 架构复杂度 | 简单 | 复杂（持续叠加功能） |
|
||||
| Terraform 专用 | ✅ 是 | ❌ 通用（需配置） |
|
||||
| PR 协作 | ✅ 原生 | ❌ 无 |
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Micro Focus Usage
|
||||
|
||||
Micro Focus 在 Labs Landing Zone 中使用 Atlantis 替代 Jenkins 进行 Terraform IaC 部署：
|
||||
- 每个 Landing Zone 共享账户部署单台 EC2 实例
|
||||
- GitHub Enterprise Webhook 接收 PR 事件
|
||||
- 服务账号负责评论/合并/关闭 PR
|
||||
- Atlantis 在 merge 前即应用变更
|
||||
|
||||
**局限性**: Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]], [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — Atlantis 操作的核心 IaC 工具
|
||||
- [[Gruntwork]] — Terragrunt 的开发者（Atlantis 生态伙伴）
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[GitOps]] — Atlantis 是 GitOps 在 Terraform 领域的实现工具
|
||||
- [[CI/CD Pipeline]] — Atlantis 提供 CI/CD 能力
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
---
|
||||
title: "Atlantis"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- terraform
|
||||
- gitops
|
||||
- cicd
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# Atlantis
|
||||
|
||||
## Definition
|
||||
|
||||
Atlantis 是一个开源的**Terraform CI/CD 工具**，通过与 GitHub/GitLab 深度集成，将 Terraform 的 plan 和 apply 操作转移到 Pull Request（PR）评论层面，实现基础设施即代码的协作式自动化部署。
|
||||
|
||||
## Core Model: PR-Driven IaC
|
||||
|
||||
Atlantis 的核心理念：**每个 Pull Request 都是一次 Terraform 操作**。
|
||||
|
||||
```
|
||||
Developer Atlantis AWS Accounts
|
||||
│ │ │
|
||||
│ 1. Open PR │ │
|
||||
│───────────────────────>│ │
|
||||
│ │ 2. !atlantis plan │
|
||||
│ │───────────────────────>│
|
||||
│ │<───────────────────────│ 3. terraform plan
|
||||
│ 4. Post plan result │ │
|
||||
│<───────────────────────│ │
|
||||
│ 5. Review & Approve │ │
|
||||
│───────────────────────>│ │
|
||||
│ │ 6. !atlantis apply │
|
||||
│ │───────────────────────>│
|
||||
│ │<───────────────────────│ 7. terraform apply
|
||||
│ 8. Merge PR │ │
|
||||
│───────────────────────>│ │
|
||||
```
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Key Features
|
||||
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| **PR 评论触发** | 无需独立 CI 账号，开发者在 PR 上评论即可 |
|
||||
| **并行 plan/apply** | 多模块并发执行，提升部署效率 |
|
||||
| **锁定机制** | 防止多 PR 同时操作同一模块产生冲突 |
|
||||
| **跨账户访问** | 通过 IAM 角色实现多 AWS 账户部署 |
|
||||
| **零额外基础设施** | 只需一台 EC2 共享账户实例 |
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Comparison: Atlantis vs Jenkins
|
||||
|
||||
| 维度 | Atlantis | Jenkins |
|
||||
|------|----------|---------|
|
||||
| 触发方式 | PR 评论 | SCM 轮询/定时 |
|
||||
| 初始化速度 | 快速（按需） | 慢（Jenkins 预配置） |
|
||||
| 代码克隆 | 单次 | 多次 |
|
||||
| 测试执行 | 并行 | 顺序 |
|
||||
| 架构复杂度 | 简单 | 复杂（持续叠加功能） |
|
||||
| Terraform 专用 | ✅ 是 | ❌ 通用（需配置） |
|
||||
| PR 协作 | ✅ 原生 | ❌ 无 |
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Micro Focus Usage
|
||||
|
||||
Micro Focus 在 Labs Landing Zone 中使用 Atlantis 替代 Jenkins 进行 Terraform IaC 部署：
|
||||
- 每个 Landing Zone 共享账户部署单台 EC2 实例
|
||||
- GitHub Enterprise Webhook 接收 PR 事件
|
||||
- 服务账号负责评论/合并/关闭 PR
|
||||
- Atlantis 在 merge 前即应用变更
|
||||
|
||||
**局限性**: Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]], [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — Atlantis 操作的核心 IaC 工具
|
||||
- [[Gruntwork]] — Terragrunt 的开发者（Atlantis 生态伙伴）
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[GitOps]] — Atlantis 是 GitOps 在 Terraform 领域的实现工具
|
||||
- [[CI/CD Pipeline]] — Atlantis 提供 CI/CD 能力
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
|
||||
@@ -1,30 +1,30 @@
|
||||
---
|
||||
title: "Axton"
|
||||
type: entity
|
||||
tags: [obsidian, developer, skills]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Basic Info
|
||||
- **Role**: 技术博主
|
||||
- **Platform**: B站 @回到Axton
|
||||
- **GitHub**: `axtonliu/axton-obsidian-visual-skills`
|
||||
|
||||
## Aliases
|
||||
- Axton
|
||||
- @回到Axton
|
||||
|
||||
## Key Contributions
|
||||
发布了一套 Obsidian 可视化 Skills，解决了原生 json-canvas skill 的节点重叠和空间分布不均问题：
|
||||
|
||||
| Skill | 功能 | 推荐度 |
|
||||
|-------|------|--------|
|
||||
| [[Obsidian-Canvas-Creator]] | 径向布局（MindMap）和自由排版（Freeform）算法，自动计算节点坐标和连线 | ✅ |
|
||||
| [[Mermaid-Visualizer]] | 将文本逻辑转换为专业 Mermaid 架构图或流程图，带 Obsidian 语法纠错 | ✅ |
|
||||
| [[Excalidraw-Diagram]] | 将文本逻辑转换为手绘风格的 Excalidraw 图表 | ✅ |
|
||||
|
||||
## Connections
|
||||
- [[obsidian-必装-skills]] — 主要贡献者
|
||||
- [[Obsidian-Canvas-Creator]] — Axton 发布的 Skill
|
||||
- [[Mermaid-Visualizer]] — Axton 发布的 Skill
|
||||
- [[Excalidraw-Diagram]] — Axton 发布的 Skill
|
||||
---
|
||||
title: "Axton"
|
||||
type: entity
|
||||
tags: [obsidian, developer, skills]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Basic Info
|
||||
- **Role**: 技术博主
|
||||
- **Platform**: B站 @回到Axton
|
||||
- **GitHub**: `axtonliu/axton-obsidian-visual-skills`
|
||||
|
||||
## Aliases
|
||||
- Axton
|
||||
- @回到Axton
|
||||
|
||||
## Key Contributions
|
||||
发布了一套 Obsidian 可视化 Skills，解决了原生 json-canvas skill 的节点重叠和空间分布不均问题：
|
||||
|
||||
| Skill | 功能 | 推荐度 |
|
||||
|-------|------|--------|
|
||||
| [[Obsidian-Canvas-Creator]] | 径向布局（MindMap）和自由排版（Freeform）算法，自动计算节点坐标和连线 | ✅ |
|
||||
| [[Mermaid-Visualizer]] | 将文本逻辑转换为专业 Mermaid 架构图或流程图，带 Obsidian 语法纠错 | ✅ |
|
||||
| [[Excalidraw-Diagram]] | 将文本逻辑转换为手绘风格的 Excalidraw 图表 | ✅ |
|
||||
|
||||
## Connections
|
||||
- [[obsidian-必装-skills]] — 主要贡献者
|
||||
- [[Obsidian-Canvas-Creator]] — Axton 发布的 Skill
|
||||
- [[Mermaid-Visualizer]] — Axton 发布的 Skill
|
||||
- [[Excalidraw-Diagram]] — Axton 发布的 Skill
|
||||
|
||||
@@ -1,40 +1,40 @@
|
||||
---
|
||||
title: Azure (Microsoft Azure)
|
||||
tags: [Cloud, Provider, Public-Cloud]
|
||||
---
|
||||
|
||||
# Azure (Microsoft Azure)
|
||||
|
||||
**Microsoft Azure** is a cloud computing platform operated by Microsoft, providing a broad range of services for application and workload hosting.
|
||||
|
||||
## Overview
|
||||
|
||||
Azure is one of the three major public cloud providers, particularly strong in enterprise environments with Microsoft ecosystem integration.
|
||||
|
||||
## Key Services Referenced
|
||||
|
||||
| Category | Services |
|
||||
|----------|----------|
|
||||
| Compute | Virtual Machines, Azure Functions |
|
||||
| Storage | Blob Storage, Azure Files |
|
||||
| Database | Azure SQL, Cosmos DB |
|
||||
| AI/ML | Azure AI, Azure OpenAI Service |
|
||||
| Analytics | Synapse, Databricks |
|
||||
| Enterprise | Active Directory, Microsoft 365 integration |
|
||||
|
||||
## Multi-Cloud Context
|
||||
|
||||
Azure is commonly used alongside AWS and Google Cloud in multi-cloud strategies:
|
||||
- **Enterprise workloads** — Strong Windows Server and SQL Server integration
|
||||
- **AI services** — Azure OpenAI Service for enterprise AI applications
|
||||
- **Hybrid cloud** — Deep integration with on-premises Windows environments
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud-Strategy]] — Azure as one of multiple providers
|
||||
- [[Cloud-Native]] — Building on Azure-native services
|
||||
- [[FinOps]] — Managing Azure costs
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
---
|
||||
title: Azure (Microsoft Azure)
|
||||
tags: [Cloud, Provider, Public-Cloud]
|
||||
---
|
||||
|
||||
# Azure (Microsoft Azure)
|
||||
|
||||
**Microsoft Azure** is a cloud computing platform operated by Microsoft, providing a broad range of services for application and workload hosting.
|
||||
|
||||
## Overview
|
||||
|
||||
Azure is one of the three major public cloud providers, particularly strong in enterprise environments with Microsoft ecosystem integration.
|
||||
|
||||
## Key Services Referenced
|
||||
|
||||
| Category | Services |
|
||||
|----------|----------|
|
||||
| Compute | Virtual Machines, Azure Functions |
|
||||
| Storage | Blob Storage, Azure Files |
|
||||
| Database | Azure SQL, Cosmos DB |
|
||||
| AI/ML | Azure AI, Azure OpenAI Service |
|
||||
| Analytics | Synapse, Databricks |
|
||||
| Enterprise | Active Directory, Microsoft 365 integration |
|
||||
|
||||
## Multi-Cloud Context
|
||||
|
||||
Azure is commonly used alongside AWS and Google Cloud in multi-cloud strategies:
|
||||
- **Enterprise workloads** — Strong Windows Server and SQL Server integration
|
||||
- **AI services** — Azure OpenAI Service for enterprise AI applications
|
||||
- **Hybrid cloud** — Deep integration with on-premises Windows environments
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud-Strategy]] — Azure as one of multiple providers
|
||||
- [[Cloud-Native]] — Building on Azure-native services
|
||||
- [[FinOps]] — Managing Azure costs
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: BMC
|
||||
---
|
||||
|
||||
# BMC
|
||||
|
||||
**BMC**（BMC Software, Inc.）是一家全球企业IT管理解决方案提供商，专注于帮助企业自动化关键应用、系统和服务，以充分利用云、数据和新兴AI技术。
|
||||
|
||||
## About
|
||||
|
||||
BMC 成立于1980年，总部位于美国德克萨斯州休斯顿，是企业软件领域的老牌厂商。其产品组合涵盖：
|
||||
|
||||
- **BMC Helix**：AI驱动的IT运维平台，整合了AIOps、可观测性和服务管理
|
||||
- **BMC Control-M**：企业级工作负载自动化
|
||||
- **BMC AMI**：大型机和存储管理解决方案
|
||||
- **BMC Discovery**：自动发现和依赖关系映射
|
||||
|
||||
## Key Facts
|
||||
|
||||
| 项目 | 描述 |
|
||||
|------|------|
|
||||
| **成立年份** | 1980年 |
|
||||
| **总部** | 美国德克萨斯州休斯顿 |
|
||||
| **核心业务** | 企业IT管理、运维自动化、AIOps |
|
||||
| **目标客户** | 全球《财富》500强企业 |
|
||||
| **标志性产品** | BMC Helix、Control-M、AMI |
|
||||
| **市场定位** | 企业级ITOM/AIOps领导者 |
|
||||
|
||||
## BMC in the Wiki
|
||||
|
||||
BMC 是本文档库中以下文章的来源：
|
||||
|
||||
- [[Public vs Private vs Hybrid Cloud Differences Explained|sources/public-vs-private-vs-hybrid-cloud-differences-explained]] — BMC Blog 关于三种云部署模型的对比分析
|
||||
|
||||
## BMC Helix
|
||||
|
||||
BMC Helix 是 BMC 的旗舰AI运维平台：
|
||||
|
||||
- **AIOps**：利用机器学习进行事件关联和异常检测
|
||||
- **可观测性**：统一的指标、日志和追踪
|
||||
- **服务管理**：ITIL兼容的服务台和事件管理
|
||||
- **自助服务门户**：最终用户自助服务
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Cloud Computing]] — 云计算基础（本文档来源文章主题）
|
||||
- [[BMC Helix]] — BMC AI运维平台
|
||||
|
||||
## See Also
|
||||
|
||||
- [BMC官网](https://www.bmc.com)
|
||||
- [BMC Helix](https://www.bmc.com/products/brands/bmc-helix.html)
|
||||
---
|
||||
title: BMC
|
||||
---
|
||||
|
||||
# BMC
|
||||
|
||||
**BMC**（BMC Software, Inc.）是一家全球企业IT管理解决方案提供商，专注于帮助企业自动化关键应用、系统和服务，以充分利用云、数据和新兴AI技术。
|
||||
|
||||
## About
|
||||
|
||||
BMC 成立于1980年，总部位于美国德克萨斯州休斯顿，是企业软件领域的老牌厂商。其产品组合涵盖：
|
||||
|
||||
- **BMC Helix**：AI驱动的IT运维平台，整合了AIOps、可观测性和服务管理
|
||||
- **BMC Control-M**：企业级工作负载自动化
|
||||
- **BMC AMI**：大型机和存储管理解决方案
|
||||
- **BMC Discovery**：自动发现和依赖关系映射
|
||||
|
||||
## Key Facts
|
||||
|
||||
| 项目 | 描述 |
|
||||
|------|------|
|
||||
| **成立年份** | 1980年 |
|
||||
| **总部** | 美国德克萨斯州休斯顿 |
|
||||
| **核心业务** | 企业IT管理、运维自动化、AIOps |
|
||||
| **目标客户** | 全球《财富》500强企业 |
|
||||
| **标志性产品** | BMC Helix、Control-M、AMI |
|
||||
| **市场定位** | 企业级ITOM/AIOps领导者 |
|
||||
|
||||
## BMC in the Wiki
|
||||
|
||||
BMC 是本文档库中以下文章的来源：
|
||||
|
||||
- [[Public vs Private vs Hybrid Cloud Differences Explained|sources/public-vs-private-vs-hybrid-cloud-differences-explained]] — BMC Blog 关于三种云部署模型的对比分析
|
||||
|
||||
## BMC Helix
|
||||
|
||||
BMC Helix 是 BMC 的旗舰AI运维平台：
|
||||
|
||||
- **AIOps**：利用机器学习进行事件关联和异常检测
|
||||
- **可观测性**：统一的指标、日志和追踪
|
||||
- **服务管理**：ITIL兼容的服务台和事件管理
|
||||
- **自助服务门户**：最终用户自助服务
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Cloud Computing]] — 云计算基础（本文档来源文章主题）
|
||||
- [[BMC Helix]] — BMC AI运维平台
|
||||
|
||||
## See Also
|
||||
|
||||
- [BMC官网](https://www.bmc.com)
|
||||
- [BMC Helix](https://www.bmc.com/products/brands/bmc-helix.html)
|
||||
|
||||
@@ -1,44 +1,44 @@
|
||||
---
|
||||
title: "Backend Architect"
|
||||
type: entity
|
||||
tags: [the-agency, engineering, multi-agent]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Overview
|
||||
The Agency 工程部门的资深后端架构师 Agent，专门负责可扩展系统设计、数据库架构、API 开发与云基础设施构建。
|
||||
|
||||
## Role
|
||||
- **Division**: Engineering
|
||||
- **Personality**: Strategic, security-focused, scalability-minded, reliability-obsessed
|
||||
- **Type**: Person（AI Agent 角色）
|
||||
|
||||
## Core Deliverables
|
||||
- 系统架构设计文档（高阶架构/服务分解/数据流）
|
||||
- 数据库 Schema 设计（PostgreSQL/MySQL 及索引规范）
|
||||
- API 设计与规范（REST/GraphQL/gRPC）
|
||||
- 云基础设施配置（AWS/GCP/Azure）
|
||||
|
||||
## Memory Integration
|
||||
Backend Architect 是 The Agency 中首批深度集成 MCP Memory 的 Agent 之一：
|
||||
|
||||
- **会话启动**：检索标签含 `backend-architect` + 项目名的历史记忆，防止重复讨论已做决策
|
||||
- **架构决策**：以标签化快照持久化（`backend-architect` + 项目名 + 主题标签如 `database-schema`/`api-design`/`auth-strategy`），包含决策理由
|
||||
- **交付物完成**：主动记忆并标记接收方（如 `frontend-developer` + `api-spec`），供下游 Agent 查找
|
||||
- **QA 失败**：检索最近良好检查点并回滚，而非手动撤销变更链
|
||||
|
||||
## Success Metrics
|
||||
- API 响应时间 95 百分位持续低于 200ms
|
||||
- 系统可用性超过 99.9%
|
||||
- 数据库查询平均低于 100ms（含正确索引）
|
||||
- 安全审计零高危漏洞
|
||||
- 峰值负载下成功处理 10 倍正常流量
|
||||
|
||||
## References
|
||||
- Source: [[backend-architect-with-memory]]
|
||||
- Coordinated by: [[agents-orchestrator]]
|
||||
- Enabled by: [[mcp-builder-agent]]
|
||||
|
||||
## Aliases
|
||||
- Backend Architect with Memory
|
||||
- backend-architect-with-memory
|
||||
---
|
||||
title: "Backend Architect"
|
||||
type: entity
|
||||
tags: [the-agency, engineering, multi-agent]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Overview
|
||||
The Agency 工程部门的资深后端架构师 Agent，专门负责可扩展系统设计、数据库架构、API 开发与云基础设施构建。
|
||||
|
||||
## Role
|
||||
- **Division**: Engineering
|
||||
- **Personality**: Strategic, security-focused, scalability-minded, reliability-obsessed
|
||||
- **Type**: Person（AI Agent 角色）
|
||||
|
||||
## Core Deliverables
|
||||
- 系统架构设计文档（高阶架构/服务分解/数据流）
|
||||
- 数据库 Schema 设计（PostgreSQL/MySQL 及索引规范）
|
||||
- API 设计与规范（REST/GraphQL/gRPC）
|
||||
- 云基础设施配置（AWS/GCP/Azure）
|
||||
|
||||
## Memory Integration
|
||||
Backend Architect 是 The Agency 中首批深度集成 MCP Memory 的 Agent 之一：
|
||||
|
||||
- **会话启动**：检索标签含 `backend-architect` + 项目名的历史记忆，防止重复讨论已做决策
|
||||
- **架构决策**：以标签化快照持久化（`backend-architect` + 项目名 + 主题标签如 `database-schema`/`api-design`/`auth-strategy`），包含决策理由
|
||||
- **交付物完成**：主动记忆并标记接收方（如 `frontend-developer` + `api-spec`），供下游 Agent 查找
|
||||
- **QA 失败**：检索最近良好检查点并回滚，而非手动撤销变更链
|
||||
|
||||
## Success Metrics
|
||||
- API 响应时间 95 百分位持续低于 200ms
|
||||
- 系统可用性超过 99.9%
|
||||
- 数据库查询平均低于 100ms（含正确索引）
|
||||
- 安全审计零高危漏洞
|
||||
- 峰值负载下成功处理 10 倍正常流量
|
||||
|
||||
## References
|
||||
- Source: [[backend-architect-with-memory]]
|
||||
- Coordinated by: [[agents-orchestrator]]
|
||||
- Enabled by: [[mcp-builder-agent]]
|
||||
|
||||
## Aliases
|
||||
- Backend Architect with Memory
|
||||
- backend-architect-with-memory
|
||||
|
||||
@@ -1,38 +1,38 @@
|
||||
---
|
||||
title: "Behavioral Nudge Engine"
|
||||
type: entity
|
||||
entity_type: Product
|
||||
tags: [agent, behavioral-ai, nudge, productivity, user-engagement]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Description
|
||||
基于行为心理学和习惯形成原理的 AI Agent，专为软件产品设计，通过个性化交互节奏和激励策略最大化用户任务完成率。扮演世界级个人教练角色，在适当时机推动用户行动或庆祝微胜利。
|
||||
|
||||
## Role & Mission
|
||||
- **Cadence Personalization**：根据用户偏好调整交互频率（每日 vs 每周）和渠道（SMS/Email/应用内）
|
||||
- **Cognitive Load Reduction**：将大量待办拆解为微小可完成的微冲刺，防止用户决策瘫痪
|
||||
- **Momentum Building**：游戏化与即时正强化，维持用户行动动量
|
||||
- **Default Exploitation**：利用默认偏差提供预填内容和一键确认选项
|
||||
|
||||
## Four-Phase Workflow
|
||||
1. **Preference Discovery**： onboarding 时询问用户偏好（语气、频率、渠道）
|
||||
2. **Task Deconstruction**：分析任务队列，拆解为最小摩擦单元
|
||||
3. **The Nudge**：通过最优渠道在最适时间推送单一可操作项
|
||||
4. **The Celebration**：即时正强化并提供温和退出选项
|
||||
|
||||
## Success Metrics
|
||||
- **Action Completion Rate**：用户实际完成任务的比例提升
|
||||
- **User Retention**：降低因软件过载或通知疲劳导致的流失
|
||||
- **Engagement Health**：推送打开率/点击率维持高位
|
||||
|
||||
## Example Output
|
||||
```
|
||||
"Hey! You've got a few quick follow-ups pending.
|
||||
Let's see how many we can knock out in the next 5 mins.
|
||||
I'll tee up the first draft. Ready?"
|
||||
[Start 5 Min Sprint]
|
||||
```
|
||||
|
||||
## Source
|
||||
- [[product-behavioral-nudge-engine]] — 完整 Agent 规范文档
|
||||
---
|
||||
title: "Behavioral Nudge Engine"
|
||||
type: entity
|
||||
entity_type: Product
|
||||
tags: [agent, behavioral-ai, nudge, productivity, user-engagement]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Description
|
||||
基于行为心理学和习惯形成原理的 AI Agent，专为软件产品设计，通过个性化交互节奏和激励策略最大化用户任务完成率。扮演世界级个人教练角色，在适当时机推动用户行动或庆祝微胜利。
|
||||
|
||||
## Role & Mission
|
||||
- **Cadence Personalization**：根据用户偏好调整交互频率（每日 vs 每周）和渠道（SMS/Email/应用内）
|
||||
- **Cognitive Load Reduction**：将大量待办拆解为微小可完成的微冲刺，防止用户决策瘫痪
|
||||
- **Momentum Building**：游戏化与即时正强化，维持用户行动动量
|
||||
- **Default Exploitation**：利用默认偏差提供预填内容和一键确认选项
|
||||
|
||||
## Four-Phase Workflow
|
||||
1. **Preference Discovery**： onboarding 时询问用户偏好（语气、频率、渠道）
|
||||
2. **Task Deconstruction**：分析任务队列，拆解为最小摩擦单元
|
||||
3. **The Nudge**：通过最优渠道在最适时间推送单一可操作项
|
||||
4. **The Celebration**：即时正强化并提供温和退出选项
|
||||
|
||||
## Success Metrics
|
||||
- **Action Completion Rate**：用户实际完成任务的比例提升
|
||||
- **User Retention**：降低因软件过载或通知疲劳导致的流失
|
||||
- **Engagement Health**：推送打开率/点击率维持高位
|
||||
|
||||
## Example Output
|
||||
```
|
||||
"Hey! You've got a few quick follow-ups pending.
|
||||
Let's see how many we can knock out in the next 5 mins.
|
||||
I'll tee up the first draft. Ready?"
|
||||
[Start 5 Min Sprint]
|
||||
```
|
||||
|
||||
## Source
|
||||
- [[product-behavioral-nudge-engine]] — 完整 Agent 规范文档
|
||||
|
||||
@@ -1,31 +1,31 @@
|
||||
---
|
||||
title: "Boss Zhipin（BOSS直聘）"
|
||||
type: entity
|
||||
tags: [hiring-platform, china]
|
||||
sources: [recruitment-specialist]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- BOSS直聘
|
||||
- Boss Zhipin
|
||||
|
||||
## 定义
|
||||
中国领先的直聊式招聘平台，以"直聊"为核心差异化特性，连接招聘方与求职者，实现即时沟通。简历获取成本约为猎聘（Liepin）的三分之一，适合大量招聘初级岗位。
|
||||
|
||||
## 在 [[Recruitment Specialist Agent]] 中的定位
|
||||
- 优化公司页面和职位卡片设计
|
||||
- 掌握"直聊"互动技巧，提升候选人响应率
|
||||
- 利用人才推荐和定向邀请功能
|
||||
- 分析职位曝光量与简历转化率
|
||||
- ROI 分析：简历成本低，适合初级岗位批量招聘
|
||||
|
||||
## 核心指标
|
||||
- 简历成本：约为 Liepin 的 1/3
|
||||
- 适用岗位层级：初级至中级
|
||||
- 核心优势：直聊即时性、简历数量大、成本可控
|
||||
|
||||
## 连接
|
||||
- [[Recruitment Specialist Agent]] — 使用该平台进行初级岗位招聘
|
||||
- [[Liepin]] — 对比：Liepin 适合中高端岗位，简历质量更高但成本更高
|
||||
- [[Lagou]] — 另一互联网招聘平台，专注科技岗位
|
||||
---
|
||||
title: "Boss Zhipin（BOSS直聘）"
|
||||
type: entity
|
||||
tags: [hiring-platform, china]
|
||||
sources: [recruitment-specialist]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- BOSS直聘
|
||||
- Boss Zhipin
|
||||
|
||||
## 定义
|
||||
中国领先的直聊式招聘平台，以"直聊"为核心差异化特性，连接招聘方与求职者，实现即时沟通。简历获取成本约为猎聘（Liepin）的三分之一，适合大量招聘初级岗位。
|
||||
|
||||
## 在 [[Recruitment Specialist Agent]] 中的定位
|
||||
- 优化公司页面和职位卡片设计
|
||||
- 掌握"直聊"互动技巧，提升候选人响应率
|
||||
- 利用人才推荐和定向邀请功能
|
||||
- 分析职位曝光量与简历转化率
|
||||
- ROI 分析：简历成本低，适合初级岗位批量招聘
|
||||
|
||||
## 核心指标
|
||||
- 简历成本：约为 Liepin 的 1/3
|
||||
- 适用岗位层级：初级至中级
|
||||
- 核心优势：直聊即时性、简历数量大、成本可控
|
||||
|
||||
## 连接
|
||||
- [[Recruitment Specialist Agent]] — 使用该平台进行初级岗位招聘
|
||||
- [[Liepin]] — 对比：Liepin 适合中高端岗位，简历质量更高但成本更高
|
||||
- [[Lagou]] — 另一互联网招聘平台，专注科技岗位
|
||||
|
||||
@@ -1,77 +1,77 @@
|
||||
---
|
||||
title: "Bottlerocket"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Container OS
|
||||
- Linux
|
||||
- EKS
|
||||
sources:
|
||||
- public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
|
||||
- public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
# Bottlerocket
|
||||
|
||||
AWS 主导维护的容器专用开源 Linux 操作系统，Bottlerocket OS 的命名灵感来自装满蝌蚪的瓶子（tadpole-containing bottle），旨在为容器工作负载提供最小化、安全加固的运行时环境。
|
||||
|
||||
## 核心设计理念
|
||||
|
||||
### 最小化（Minimalism）
|
||||
- 去除所有非必要组件：无包管理器、无默认 Shell 解释器、无默认 SSH 访问
|
||||
- 仅打包必要内核组件到 OS 镜像，攻击面降至最低
|
||||
- Bottlerocket 可运行于笔记本电脑、工作站和数据中心环境
|
||||
|
||||
### Variant 机制
|
||||
Variant 是 Bottlerocket 的核心定制机制——在构建时组合以下维度：
|
||||
- **平台**（platform）：AWS（用于 EC2）、Bare Metal 等
|
||||
- **处理器架构**：x86_64、ARM64 (Graviton)
|
||||
- **工作负载组件**：Kubernetes 节点、NVIDIA GPU 支持、自定义包
|
||||
|
||||
Variant 允许按需定制（如 Bottlerocket with Kubernetes + NVIDIA GPU），避免通用 OS 的臃肿。
|
||||
|
||||
### 安全更新（Safe Updates）
|
||||
- **分区镜像更新（Partition Updates）**：A/B 双分区机制，在线下载新版本镜像到非活动分区，重启后切换，确保更新原子性
|
||||
- **Data Volume**：独立数据卷缓存容器镜像，支持快照预填充
|
||||
- **in-place 更新**：无需替换节点即可完成 OS 升级
|
||||
|
||||
### 安全加固（Security Hardening）
|
||||
- **dm-verity**：对根文件系统进行加密哈希验证，检测任何未授权篡改
|
||||
- **只读根文件系统**：默认只读，运行时无法修改根目录内容
|
||||
- **SE Linux enforcing**：默认启用 enforcing 模式，基于标签的强制访问控制（MAC）
|
||||
- **Secure Boot**：启动时验证引导加载程序和内核签名
|
||||
- **CIS Benchmark**：Bottlerocket 提供专用 CIS benchmark 安全加固指南
|
||||
|
||||
## 与 EKS 的集成
|
||||
|
||||
Bottlerocket 支持与 Amazon EKS 的三种集成方式：
|
||||
|
||||
| 集成方式 | 说明 |
|
||||
|---------|------|
|
||||
| Bottlerocket for EKS AMI | 自管理节点组（Self-Managed Node Groups），通过 eksctl 或 launch template 指定 |
|
||||
| 托管节点组（Managed Node Groups） | EKS 自动管理的节点组，可指定 Bottlerocket AMI |
|
||||
| Carpenter 节点池 | EKS Auto Mode 的节点池，Carpenter Controller 自动管理，Bottlerocket 为默认 OS |
|
||||
|
||||
## 配置方式
|
||||
|
||||
- **API 接口**：通过 Bottlerocket API 远程配置节点
|
||||
- **TOML 用户数据**：在实例启动时通过 userdata 传递 TOML 格式配置
|
||||
- **EKS 工具集成**：eksctl、Carpenter 等工具原生支持 Bottlerocket
|
||||
|
||||
## 最佳实践
|
||||
|
||||
- **锁定 AMI 版本**：生产环境应将 Bottlerocket AMI 锁定到特定版本，避免自动升级导致意外中断
|
||||
- **通过 Bottlerocket API 配置**：而非手动 SSH 登录修改配置（默认禁用了交互式 Shell）
|
||||
- **监控更新状态**：通过 API 检查当前活动的分区版本和待切换版本
|
||||
|
||||
## 相关资源
|
||||
|
||||
- GitHub：https://github.com/bottlerocket-os/bottlerocket
|
||||
- 文档：https://bottlerocket.dev/
|
||||
- AWS Bottlerocket AMI：AWS Marketplace 和 SSM 参数提供
|
||||
|
||||
## Aliases
|
||||
- Bottlerocket OS
|
||||
- 火箭瓶（中文社区昵称）
|
||||
- Bottlerocket for EKS
|
||||
---
|
||||
title: "Bottlerocket"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Container OS
|
||||
- Linux
|
||||
- EKS
|
||||
sources:
|
||||
- public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w
|
||||
- public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
# Bottlerocket
|
||||
|
||||
AWS 主导维护的容器专用开源 Linux 操作系统，Bottlerocket OS 的命名灵感来自装满蝌蚪的瓶子（tadpole-containing bottle），旨在为容器工作负载提供最小化、安全加固的运行时环境。
|
||||
|
||||
## 核心设计理念
|
||||
|
||||
### 最小化（Minimalism）
|
||||
- 去除所有非必要组件：无包管理器、无默认 Shell 解释器、无默认 SSH 访问
|
||||
- 仅打包必要内核组件到 OS 镜像，攻击面降至最低
|
||||
- Bottlerocket 可运行于笔记本电脑、工作站和数据中心环境
|
||||
|
||||
### Variant 机制
|
||||
Variant 是 Bottlerocket 的核心定制机制——在构建时组合以下维度：
|
||||
- **平台**（platform）：AWS（用于 EC2）、Bare Metal 等
|
||||
- **处理器架构**：x86_64、ARM64 (Graviton)
|
||||
- **工作负载组件**：Kubernetes 节点、NVIDIA GPU 支持、自定义包
|
||||
|
||||
Variant 允许按需定制（如 Bottlerocket with Kubernetes + NVIDIA GPU），避免通用 OS 的臃肿。
|
||||
|
||||
### 安全更新（Safe Updates）
|
||||
- **分区镜像更新（Partition Updates）**：A/B 双分区机制，在线下载新版本镜像到非活动分区，重启后切换，确保更新原子性
|
||||
- **Data Volume**：独立数据卷缓存容器镜像，支持快照预填充
|
||||
- **in-place 更新**：无需替换节点即可完成 OS 升级
|
||||
|
||||
### 安全加固（Security Hardening）
|
||||
- **dm-verity**：对根文件系统进行加密哈希验证，检测任何未授权篡改
|
||||
- **只读根文件系统**：默认只读，运行时无法修改根目录内容
|
||||
- **SE Linux enforcing**：默认启用 enforcing 模式，基于标签的强制访问控制（MAC）
|
||||
- **Secure Boot**：启动时验证引导加载程序和内核签名
|
||||
- **CIS Benchmark**：Bottlerocket 提供专用 CIS benchmark 安全加固指南
|
||||
|
||||
## 与 EKS 的集成
|
||||
|
||||
Bottlerocket 支持与 Amazon EKS 的三种集成方式：
|
||||
|
||||
| 集成方式 | 说明 |
|
||||
|---------|------|
|
||||
| Bottlerocket for EKS AMI | 自管理节点组（Self-Managed Node Groups），通过 eksctl 或 launch template 指定 |
|
||||
| 托管节点组（Managed Node Groups） | EKS 自动管理的节点组，可指定 Bottlerocket AMI |
|
||||
| Carpenter 节点池 | EKS Auto Mode 的节点池，Carpenter Controller 自动管理，Bottlerocket 为默认 OS |
|
||||
|
||||
## 配置方式
|
||||
|
||||
- **API 接口**：通过 Bottlerocket API 远程配置节点
|
||||
- **TOML 用户数据**：在实例启动时通过 userdata 传递 TOML 格式配置
|
||||
- **EKS 工具集成**：eksctl、Carpenter 等工具原生支持 Bottlerocket
|
||||
|
||||
## 最佳实践
|
||||
|
||||
- **锁定 AMI 版本**：生产环境应将 Bottlerocket AMI 锁定到特定版本，避免自动升级导致意外中断
|
||||
- **通过 Bottlerocket API 配置**：而非手动 SSH 登录修改配置（默认禁用了交互式 Shell）
|
||||
- **监控更新状态**：通过 API 检查当前活动的分区版本和待切换版本
|
||||
|
||||
## 相关资源
|
||||
|
||||
- GitHub：https://github.com/bottlerocket-os/bottlerocket
|
||||
- 文档：https://bottlerocket.dev/
|
||||
- AWS Bottlerocket AMI：AWS Marketplace 和 SSM 参数提供
|
||||
|
||||
## Aliases
|
||||
- Bottlerocket OS
|
||||
- 火箭瓶（中文社区昵称）
|
||||
- Bottlerocket for EKS
|
||||
|
||||
@@ -1,26 +1,26 @@
|
||||
---
|
||||
title: "Brendan Starnig"
|
||||
type: entity
|
||||
tags: [SRE, Platform-Engineering, Change-Management]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Brendan Starnig is the SRE Function Lead in the Platform Engineering team. He is the primary presenter of CTP Topic 30 on Managing Change, which covers change management processes and SRE team collaboration patterns in cloud transformation projects.
|
||||
|
||||
## Role
|
||||
|
||||
- **Title**: SRE Function Lead, Platform Engineering
|
||||
- **Team**: Site Reliability Engineering (SRE)
|
||||
- **Topics**: Change Management, SRE Practices, Cloud Transformation
|
||||
|
||||
## Key Contributions
|
||||
|
||||
- Developed and presented the change management framework covering Standard Change, Normal Change, and Emergency Change
|
||||
- Defined SRE team collaboration model across three phases: Build / Early Live Support / BAU
|
||||
- Proposed Self-Healing automation initiative with product teams
|
||||
|
||||
## Sources
|
||||
|
||||
- [[ctp-topic-30-managing-change]]
|
||||
---
|
||||
title: "Brendan Starnig"
|
||||
type: entity
|
||||
tags: [SRE, Platform-Engineering, Change-Management]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Brendan Starnig is the SRE Function Lead in the Platform Engineering team. He is the primary presenter of CTP Topic 30 on Managing Change, which covers change management processes and SRE team collaboration patterns in cloud transformation projects.
|
||||
|
||||
## Role
|
||||
|
||||
- **Title**: SRE Function Lead, Platform Engineering
|
||||
- **Team**: Site Reliability Engineering (SRE)
|
||||
- **Topics**: Change Management, SRE Practices, Cloud Transformation
|
||||
|
||||
## Key Contributions
|
||||
|
||||
- Developed and presented the change management framework covering Standard Change, Normal Change, and Emergency Change
|
||||
- Defined SRE team collaboration model across three phases: Build / Early Live Support / BAU
|
||||
- Proposed Self-Healing automation initiative with product teams
|
||||
|
||||
## Sources
|
||||
|
||||
- [[ctp-topic-30-managing-change]]
|
||||
|
||||
@@ -1,136 +1,136 @@
|
||||
---
|
||||
title: "Caddy"
|
||||
type: entity
|
||||
aliases: [Caddy Web Server, Caddy反代]
|
||||
tags: [web-server, reverse-proxy, https, open-source]
|
||||
---
|
||||
|
||||
# Caddy
|
||||
|
||||
## Overview
|
||||
**Caddy** 是一个用 Go 语言编写的开源 Web 服务器，以自动 HTTPS 和简洁配置著称。相比 Nginx，Caddy 默认启用 HTTPS（Let's Encrypt 自动证书），配置语法更简洁直观。
|
||||
|
||||
## Core Features
|
||||
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| **自动 HTTPS** | 自动从 Let's Encrypt 申请和续期 SSL 证书 |
|
||||
| **自动 HTTP→HTTPS 重定向** | 无需手动配置 |
|
||||
| **TLS 1.3 支持** | 现代加密标准 |
|
||||
| **配置热加载** | 修改配置无需重启服务 |
|
||||
| **反向代理** | 支持 HTTP/2、WebSocket |
|
||||
| **Markdown 渲染** | 内置静态文件服务 |
|
||||
|
||||
## Installation (Ubuntu/Debian)
|
||||
```bash
|
||||
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
|
||||
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
|
||||
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
|
||||
sudo apt update
|
||||
sudo apt install caddy
|
||||
```
|
||||
|
||||
## Basic Configuration (Caddyfile)
|
||||
|
||||
### 简单反向代理
|
||||
```
|
||||
n8n.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:15678
|
||||
}
|
||||
```
|
||||
|
||||
### 多域名配置
|
||||
```
|
||||
nas.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:15000
|
||||
}
|
||||
|
||||
grafana.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:13000
|
||||
}
|
||||
```
|
||||
|
||||
### 带认证的反向代理
|
||||
```
|
||||
n8n.ishenwei.online {
|
||||
basicauth /* {
|
||||
admin JDJhJDE0JDN3ZXVhV2YyZG9SY2hvYzVmZ2h3QUlVblpOMU4vS1ptcENrSlhySElMb3l5dytOMkh0Tk93
|
||||
}
|
||||
reverse_proxy 127.0.0.1:15678
|
||||
}
|
||||
```
|
||||
|
||||
## Integration with frp
|
||||
|
||||
典型架构：frp 建立内网隧道 → Caddy 反向代理到本地端口 → 自动 HTTPS
|
||||
|
||||
```
|
||||
用户请求 https://n8n.ishenwei.online
|
||||
↓
|
||||
阿里云 DNS → VPS 公网 IP
|
||||
↓
|
||||
Caddy (443端口) 接收请求
|
||||
↓
|
||||
Caddyfile 配置匹配 n8n.ishenwei.online
|
||||
↓
|
||||
reverse_proxy 127.0.0.1:15678
|
||||
↓
|
||||
frpc 在 VPS 15000 端口监听
|
||||
↓
|
||||
frp 隧道 → 内网 Ubuntu 5678 端口
|
||||
↓
|
||||
n8n 服务
|
||||
```
|
||||
|
||||
## Common Commands
|
||||
|
||||
```bash
|
||||
# 验证配置文件语法
|
||||
sudo caddy validate --config /etc/caddy/Caddyfile
|
||||
|
||||
# 重载配置（热加载）
|
||||
sudo systemctl reload caddy
|
||||
|
||||
# 重启服务
|
||||
sudo systemctl restart caddy
|
||||
|
||||
# 查看状态
|
||||
sudo systemctl status caddy
|
||||
|
||||
# 紧急恢复（服务卡死时）
|
||||
sudo systemctl stop caddy
|
||||
sudo pkill -9 caddy
|
||||
sudo systemctl start caddy
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Caddyfile 语法检查
|
||||
```bash
|
||||
sudo caddy validate --config /etc/caddy/Caddyfile
|
||||
# 输出 "Valid configuration" 表示语法正确
|
||||
```
|
||||
|
||||
### 端口被占用
|
||||
如果 Caddy 启动失败，检查端口是否被占用：
|
||||
```bash
|
||||
ss -ltnp | grep ':80\|:443'
|
||||
```
|
||||
|
||||
### Caddy 意外占用端口
|
||||
某些一键脚本可能配置 Caddy 监听非标准端口，检查是否有：
|
||||
```
|
||||
:7000 {
|
||||
reverse_proxy ...
|
||||
}
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[反向代理]] — Caddy 的核心功能
|
||||
- [[Let's Encrypt]] — Caddy 自动使用的 SSL 证书提供商
|
||||
- [[frp]] — Caddy 常与 frp 配合使用
|
||||
- [[VPS]] — Caddy 通常部署在公网 VPS
|
||||
|
||||
## References
|
||||
- 官网: https://caddyserver.com/
|
||||
- 文档: https://caddyserver.com/docs/
|
||||
---
|
||||
title: "Caddy"
|
||||
type: entity
|
||||
aliases: [Caddy Web Server, Caddy反代]
|
||||
tags: [web-server, reverse-proxy, https, open-source]
|
||||
---
|
||||
|
||||
# Caddy
|
||||
|
||||
## Overview
|
||||
**Caddy** 是一个用 Go 语言编写的开源 Web 服务器，以自动 HTTPS 和简洁配置著称。相比 Nginx，Caddy 默认启用 HTTPS（Let's Encrypt 自动证书），配置语法更简洁直观。
|
||||
|
||||
## Core Features
|
||||
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| **自动 HTTPS** | 自动从 Let's Encrypt 申请和续期 SSL 证书 |
|
||||
| **自动 HTTP→HTTPS 重定向** | 无需手动配置 |
|
||||
| **TLS 1.3 支持** | 现代加密标准 |
|
||||
| **配置热加载** | 修改配置无需重启服务 |
|
||||
| **反向代理** | 支持 HTTP/2、WebSocket |
|
||||
| **Markdown 渲染** | 内置静态文件服务 |
|
||||
|
||||
## Installation (Ubuntu/Debian)
|
||||
```bash
|
||||
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
|
||||
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
|
||||
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
|
||||
sudo apt update
|
||||
sudo apt install caddy
|
||||
```
|
||||
|
||||
## Basic Configuration (Caddyfile)
|
||||
|
||||
### 简单反向代理
|
||||
```
|
||||
n8n.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:15678
|
||||
}
|
||||
```
|
||||
|
||||
### 多域名配置
|
||||
```
|
||||
nas.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:15000
|
||||
}
|
||||
|
||||
grafana.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:13000
|
||||
}
|
||||
```
|
||||
|
||||
### 带认证的反向代理
|
||||
```
|
||||
n8n.ishenwei.online {
|
||||
basicauth /* {
|
||||
admin JDJhJDE0JDN3ZXVhV2YyZG9SY2hvYzVmZ2h3QUlVblpOMU4vS1ptcENrSlhySElMb3l5dytOMkh0Tk93
|
||||
}
|
||||
reverse_proxy 127.0.0.1:15678
|
||||
}
|
||||
```
|
||||
|
||||
## Integration with frp
|
||||
|
||||
典型架构：frp 建立内网隧道 → Caddy 反向代理到本地端口 → 自动 HTTPS
|
||||
|
||||
```
|
||||
用户请求 https://n8n.ishenwei.online
|
||||
↓
|
||||
阿里云 DNS → VPS 公网 IP
|
||||
↓
|
||||
Caddy (443端口) 接收请求
|
||||
↓
|
||||
Caddyfile 配置匹配 n8n.ishenwei.online
|
||||
↓
|
||||
reverse_proxy 127.0.0.1:15678
|
||||
↓
|
||||
frpc 在 VPS 15000 端口监听
|
||||
↓
|
||||
frp 隧道 → 内网 Ubuntu 5678 端口
|
||||
↓
|
||||
n8n 服务
|
||||
```
|
||||
|
||||
## Common Commands
|
||||
|
||||
```bash
|
||||
# 验证配置文件语法
|
||||
sudo caddy validate --config /etc/caddy/Caddyfile
|
||||
|
||||
# 重载配置（热加载）
|
||||
sudo systemctl reload caddy
|
||||
|
||||
# 重启服务
|
||||
sudo systemctl restart caddy
|
||||
|
||||
# 查看状态
|
||||
sudo systemctl status caddy
|
||||
|
||||
# 紧急恢复（服务卡死时）
|
||||
sudo systemctl stop caddy
|
||||
sudo pkill -9 caddy
|
||||
sudo systemctl start caddy
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Caddyfile 语法检查
|
||||
```bash
|
||||
sudo caddy validate --config /etc/caddy/Caddyfile
|
||||
# 输出 "Valid configuration" 表示语法正确
|
||||
```
|
||||
|
||||
### 端口被占用
|
||||
如果 Caddy 启动失败，检查端口是否被占用：
|
||||
```bash
|
||||
ss -ltnp | grep ':80\|:443'
|
||||
```
|
||||
|
||||
### Caddy 意外占用端口
|
||||
某些一键脚本可能配置 Caddy 监听非标准端口，检查是否有：
|
||||
```
|
||||
:7000 {
|
||||
reverse_proxy ...
|
||||
}
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[反向代理]] — Caddy 的核心功能
|
||||
- [[Let's Encrypt]] — Caddy 自动使用的 SSL 证书提供商
|
||||
- [[frp]] — Caddy 常与 frp 配合使用
|
||||
- [[VPS]] — Caddy 通常部署在公网 VPS
|
||||
|
||||
## References
|
||||
- 官网: https://caddyserver.com/
|
||||
- 文档: https://caddyserver.com/docs/
|
||||
|
||||
@@ -1,57 +1,57 @@
|
||||
# Calibre
|
||||
|
||||
> Calibre，开源电子书库管理工具，在 Synology NAS 上以 Docker 方式部署，提供电子书管理、格式转换和 Web 阅读界面。
|
||||
|
||||
## Overview
|
||||
Calibre 是功能最强大的开源电子书库管理工具，支持电子书格式转换、元数据编辑、新闻订阅、Web服务器等功能。本方案中通过 Docker Compose 在 Synology NAS DS718 上部署 Calibre-Web，提供公网访问。
|
||||
|
||||
## Deployment
|
||||
|
||||
|| 项目 | 配置 |
|
||||
|------|------|
|
||||
| 部署位置 | Synology NAS DS718（192.168.3.17）|
|
||||
| 容器名称 | calibre |
|
||||
| 内网端口 | 8083 |
|
||||
| 公网域名 | calibre.ishenwei.online |
|
||||
| FRP remotePort | 18083 |
|
||||
| FRP 客户端 | NAS frpc |
|
||||
| Docker 镜像 | ghcr.io/linuxserver/calibre-web（推测）|
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
[用户]
|
||||
│
|
||||
│ HTTPS: calibre.ishenwei.online
|
||||
▼
|
||||
[Cloudflare DNS → RackNerd VPS]
|
||||
│
|
||||
│ HTTPS 反向代理
|
||||
▼
|
||||
[Caddy (VPS)]
|
||||
│
|
||||
│ FRP 隧道 (端口 18083)
|
||||
▼
|
||||
[NAS:8083]
|
||||
Calibre-Web
|
||||
```
|
||||
|
||||
## Key Features
|
||||
|
||||
1. **电子书管理**：支持 EPUB/MOBI/AZW3/PDF/TXT 等格式
|
||||
2. **元数据编辑**：封面、作者、出版商、ISBN 等信息管理
|
||||
3. **格式转换**：Calibre 内核支持 20+ 格式转换
|
||||
4. **Web 服务器**：内置 Web UI，支持多设备阅读
|
||||
5. **新闻订阅**：支持 RSS/Atom 格式新闻自动下载
|
||||
|
||||
## Related Concepts
|
||||
- [[媒体服务器]] — 与 Jellyfin/Navidrome 构成家庭媒体服务矩阵
|
||||
- [[Docker堆栈]] — NAS 上通过 Docker Compose 部署
|
||||
- [[反向代理]] — 通过 Caddy + FRP 暴露公网访问
|
||||
|
||||
## Related Entities
|
||||
- [[Synology NAS DS718]] — 部署宿主
|
||||
- [[RackNerd]] — 公网 VPS（Caddy）
|
||||
- [[frp]] — 内网穿透机制
|
||||
- [[Jellyfin]] — 视频媒体服务（同一 NAS）
|
||||
- [[Navidrome]] — 音乐流媒体服务（同一 NAS）
|
||||
# Calibre
|
||||
|
||||
> Calibre，开源电子书库管理工具，在 Synology NAS 上以 Docker 方式部署，提供电子书管理、格式转换和 Web 阅读界面。
|
||||
|
||||
## Overview
|
||||
Calibre 是功能最强大的开源电子书库管理工具，支持电子书格式转换、元数据编辑、新闻订阅、Web服务器等功能。本方案中通过 Docker Compose 在 Synology NAS DS718 上部署 Calibre-Web，提供公网访问。
|
||||
|
||||
## Deployment
|
||||
|
||||
|| 项目 | 配置 |
|
||||
|------|------|
|
||||
| 部署位置 | Synology NAS DS718（192.168.3.17）|
|
||||
| 容器名称 | calibre |
|
||||
| 内网端口 | 8083 |
|
||||
| 公网域名 | calibre.ishenwei.online |
|
||||
| FRP remotePort | 18083 |
|
||||
| FRP 客户端 | NAS frpc |
|
||||
| Docker 镜像 | ghcr.io/linuxserver/calibre-web（推测）|
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
[用户]
|
||||
│
|
||||
│ HTTPS: calibre.ishenwei.online
|
||||
▼
|
||||
[Cloudflare DNS → RackNerd VPS]
|
||||
│
|
||||
│ HTTPS 反向代理
|
||||
▼
|
||||
[Caddy (VPS)]
|
||||
│
|
||||
│ FRP 隧道 (端口 18083)
|
||||
▼
|
||||
[NAS:8083]
|
||||
Calibre-Web
|
||||
```
|
||||
|
||||
## Key Features
|
||||
|
||||
1. **电子书管理**：支持 EPUB/MOBI/AZW3/PDF/TXT 等格式
|
||||
2. **元数据编辑**：封面、作者、出版商、ISBN 等信息管理
|
||||
3. **格式转换**：Calibre 内核支持 20+ 格式转换
|
||||
4. **Web 服务器**：内置 Web UI，支持多设备阅读
|
||||
5. **新闻订阅**：支持 RSS/Atom 格式新闻自动下载
|
||||
|
||||
## Related Concepts
|
||||
- [[媒体服务器]] — 与 Jellyfin/Navidrome 构成家庭媒体服务矩阵
|
||||
- [[Docker堆栈]] — NAS 上通过 Docker Compose 部署
|
||||
- [[反向代理]] — 通过 Caddy + FRP 暴露公网访问
|
||||
|
||||
## Related Entities
|
||||
- [[Synology NAS DS718]] — 部署宿主
|
||||
- [[RackNerd]] — 公网 VPS（Caddy）
|
||||
- [[frp]] — 内网穿透机制
|
||||
- [[Jellyfin]] — 视频媒体服务（同一 NAS）
|
||||
- [[Navidrome]] — 音乐流媒体服务（同一 NAS）
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: "Canva"
|
||||
type: entity
|
||||
tags: [AI, 设计, 簡報]
|
||||
sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Canva 是在线可视化设计平台（canva.com），支持简报、海报、社交媒体图片、logo、名片等多种设计类型。提供海量模板和设计素材，用户可通过拖拽操作快速完成设计。
|
||||
|
||||
## Key Features
|
||||
- 海量专业模板库
|
||||
- 品牌套件（Logo、色彩、字体）
|
||||
- AI 辅助设计功能（Magic Design、文本生成图片等）
|
||||
- 团队协作与共享
|
||||
- 支持简报、海报、社交媒体等多种输出格式
|
||||
|
||||
## Role in AI簡報工作流
|
||||
在 AI 簡報工作流中，Canva 担任"设计师"角色——接收 ChatGPT 整理好的结构化内容，快速生成视觉精美的演示文稿。
|
||||
|
||||
## Related
|
||||
- [[Gamma AI]]：AI 简报工具的另一个选择，更侧重 AI 驱动的一键生成
|
||||
- [[AI簡報工作流]]：Canva 在此工作流中负责视觉呈现
|
||||
---
|
||||
title: "Canva"
|
||||
type: entity
|
||||
tags: [AI, 设计, 簡報]
|
||||
sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Canva 是在线可视化设计平台（canva.com），支持简报、海报、社交媒体图片、logo、名片等多种设计类型。提供海量模板和设计素材，用户可通过拖拽操作快速完成设计。
|
||||
|
||||
## Key Features
|
||||
- 海量专业模板库
|
||||
- 品牌套件（Logo、色彩、字体）
|
||||
- AI 辅助设计功能（Magic Design、文本生成图片等）
|
||||
- 团队协作与共享
|
||||
- 支持简报、海报、社交媒体等多种输出格式
|
||||
|
||||
## Role in AI簡報工作流
|
||||
在 AI 簡報工作流中，Canva 担任"设计师"角色——接收 ChatGPT 整理好的结构化内容，快速生成视觉精美的演示文稿。
|
||||
|
||||
## Related
|
||||
- [[Gamma AI]]：AI 简报工具的另一个选择，更侧重 AI 驱动的一键生成
|
||||
- [[AI簡報工作流]]：Canva 在此工作流中负责视觉呈现
|
||||
|
||||
@@ -1,34 +1,34 @@
|
||||
---
|
||||
title: "ChatGPT"
|
||||
type: entity
|
||||
tags: [ai, llm, product, openai]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
# ChatGPT
|
||||
|
||||
## Type
|
||||
Product
|
||||
|
||||
## Aliases
|
||||
- Chat Generative Pre-trained Transformer
|
||||
- ChatGPT
|
||||
|
||||
## Description
|
||||
ChatGPT 是 OpenAI 开发的大语言模型对话产品，基于 GPT 系列模型，支持自定义指令（Custom Instructions）功能，允许用户配置 AI 的响应风格、交互偏好和输出格式。
|
||||
|
||||
## Custom Instructions（自定义指令）
|
||||
ChatGPT 的个性化配置功能，包含两个维度：
|
||||
1. **自定义指令**：定义 AI 的响应风格和交互偏好（如"高度有条理"、"主动预判需求"）
|
||||
2. **你的详情**：描述用户背景信息（如专业领域、技术水平、使用场景）
|
||||
|
||||
用户可设置：错误零容忍、提供详细解释、引用来源放末尾、不进行道德说教等个性化要求。
|
||||
|
||||
## Relevance to This Wiki
|
||||
- [[openai-chatgpt-个性化定义]]：用户的完整 ChatGPT 个性化配置定义
|
||||
- [[AI簡報工作流]]：ChatGPT 担任"知识整理者"角色
|
||||
- [[designing-for-agentic-ai]]：ChatGPT 是个性化配置的典型案例
|
||||
|
||||
## Sources
|
||||
- [[openai-chatgpt-个性化定义]]
|
||||
- [[教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]]
|
||||
---
|
||||
title: "ChatGPT"
|
||||
type: entity
|
||||
tags: [ai, llm, product, openai]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
# ChatGPT
|
||||
|
||||
## Type
|
||||
Product
|
||||
|
||||
## Aliases
|
||||
- Chat Generative Pre-trained Transformer
|
||||
- ChatGPT
|
||||
|
||||
## Description
|
||||
ChatGPT 是 OpenAI 开发的大语言模型对话产品，基于 GPT 系列模型，支持自定义指令（Custom Instructions）功能，允许用户配置 AI 的响应风格、交互偏好和输出格式。
|
||||
|
||||
## Custom Instructions（自定义指令）
|
||||
ChatGPT 的个性化配置功能，包含两个维度：
|
||||
1. **自定义指令**：定义 AI 的响应风格和交互偏好（如"高度有条理"、"主动预判需求"）
|
||||
2. **你的详情**：描述用户背景信息（如专业领域、技术水平、使用场景）
|
||||
|
||||
用户可设置：错误零容忍、提供详细解释、引用来源放末尾、不进行道德说教等个性化要求。
|
||||
|
||||
## Relevance to This Wiki
|
||||
- [[openai-chatgpt-个性化定义]]：用户的完整 ChatGPT 个性化配置定义
|
||||
- [[AI簡報工作流]]：ChatGPT 担任"知识整理者"角色
|
||||
- [[designing-for-agentic-ai]]：ChatGPT 是个性化配置的典型案例
|
||||
|
||||
## Sources
|
||||
- [[openai-chatgpt-个性化定义]]
|
||||
- [[教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]]
|
||||
|
||||
@@ -1,57 +1,57 @@
|
||||
---
|
||||
title: "Checkpoint"
|
||||
type: entity
|
||||
tags: [Firewall, Network-Security, AWS, Cloud-Security]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Checkpoint（Check Point Software Technologies）是全球领先的网络安全解决方案提供商，其防火墙产品在该组织的 AWS Landing Zone 架构中扮演关键角色。Checkpoint 防火墙通过读取 AWS 资源的标签值（Tags）来动态配置网络访问策略，这意味着资源标签的有效性直接影响网络连通性。
|
||||
|
||||
## Role in AWS Landing Zone
|
||||
|
||||
在企业 AWS 架构中，Checkpoint 防火墙与 AWS 资源标签紧密集成：
|
||||
|
||||
- **读取标签来源**：EC2 实例、安全组（Security Groups）、负载均衡器（Load Balancers）
|
||||
- **基于标签决策**：根据标签键值对判断资源所属环境（dev/staging/prod）、成本中心、负责人等属性
|
||||
- **动态网络策略**：根据标签值自动应用相应的网络访问控制规则
|
||||
|
||||
### 网络安全依赖链
|
||||
|
||||
```
|
||||
AWS 资源标签（Tag）→ Checkpoint 防火墙读取 → 网络访问策略配置
|
||||
↑
|
||||
标签缺失或无效
|
||||
↓
|
||||
相关网络流量被拦截
|
||||
```
|
||||
|
||||
## Impact of Tag Non-Compliance
|
||||
|
||||
当 AWS 资源缺少必需标签或标签值不在允许列表中时：
|
||||
1. Checkpoint 防火墙无法识别资源身份
|
||||
2. 无法将资源匹配到正确的网络策略
|
||||
3. 防火墙执行默认拒绝策略，**拦截该资源的所有网络流量**
|
||||
4. 导致服务中断或连接失败
|
||||
|
||||
这使得 **标签合规性从"可选管理实践"变为"网络安全硬性要求"**。
|
||||
|
||||
## Solutions
|
||||
|
||||
| 机制 | 作用 | 局限性 |
|
||||
|------|------|--------|
|
||||
| [[Service-Control-Policies-SCPs]] | 阻止不合规新资源创建 | 无法修复存量资源 |
|
||||
| [[Tag-Validation-Tool]] | 审计存量资源标签合规性 | 仅审计，需人工修复 |
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[AWS-Tags]]：Checkpoint 读取的元数据
|
||||
- [[AWS-Tagging-Standards]]：标签规范的定义
|
||||
- [[Tag-Validation-Tool]]：确保标签合规性的工具
|
||||
- [[Service-Control-Policies-SCPs]]：强制执行标签规范的上游机制
|
||||
- [[Checkpoint-Firewall]]：（同义词，可互链）
|
||||
|
||||
## Sources
|
||||
|
||||
- [[ctp-topic-28-aws-tag-validation-tool]]
|
||||
---
|
||||
title: "Checkpoint"
|
||||
type: entity
|
||||
tags: [Firewall, Network-Security, AWS, Cloud-Security]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Checkpoint（Check Point Software Technologies）是全球领先的网络安全解决方案提供商，其防火墙产品在该组织的 AWS Landing Zone 架构中扮演关键角色。Checkpoint 防火墙通过读取 AWS 资源的标签值（Tags）来动态配置网络访问策略，这意味着资源标签的有效性直接影响网络连通性。
|
||||
|
||||
## Role in AWS Landing Zone
|
||||
|
||||
在企业 AWS 架构中，Checkpoint 防火墙与 AWS 资源标签紧密集成：
|
||||
|
||||
- **读取标签来源**：EC2 实例、安全组（Security Groups）、负载均衡器（Load Balancers）
|
||||
- **基于标签决策**：根据标签键值对判断资源所属环境（dev/staging/prod）、成本中心、负责人等属性
|
||||
- **动态网络策略**：根据标签值自动应用相应的网络访问控制规则
|
||||
|
||||
### 网络安全依赖链
|
||||
|
||||
```
|
||||
AWS 资源标签（Tag）→ Checkpoint 防火墙读取 → 网络访问策略配置
|
||||
↑
|
||||
标签缺失或无效
|
||||
↓
|
||||
相关网络流量被拦截
|
||||
```
|
||||
|
||||
## Impact of Tag Non-Compliance
|
||||
|
||||
当 AWS 资源缺少必需标签或标签值不在允许列表中时：
|
||||
1. Checkpoint 防火墙无法识别资源身份
|
||||
2. 无法将资源匹配到正确的网络策略
|
||||
3. 防火墙执行默认拒绝策略，**拦截该资源的所有网络流量**
|
||||
4. 导致服务中断或连接失败
|
||||
|
||||
这使得 **标签合规性从"可选管理实践"变为"网络安全硬性要求"**。
|
||||
|
||||
## Solutions
|
||||
|
||||
| 机制 | 作用 | 局限性 |
|
||||
|------|------|--------|
|
||||
| [[Service-Control-Policies-SCPs]] | 阻止不合规新资源创建 | 无法修复存量资源 |
|
||||
| [[Tag-Validation-Tool]] | 审计存量资源标签合规性 | 仅审计，需人工修复 |
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[AWS-Tags]]：Checkpoint 读取的元数据
|
||||
- [[AWS-Tagging-Standards]]：标签规范的定义
|
||||
- [[Tag-Validation-Tool]]：确保标签合规性的工具
|
||||
- [[Service-Control-Policies-SCPs]]：强制执行标签规范的上游机制
|
||||
- [[Checkpoint-Firewall]]：（同义词，可互链）
|
||||
|
||||
## Sources
|
||||
|
||||
- [[ctp-topic-28-aws-tag-validation-tool]]
|
||||
|
||||
@@ -1,34 +1,34 @@
|
||||
---
|
||||
title: "Choi Wontak"
|
||||
type: entity
|
||||
tags: [obsidian, skills, learning]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Basic Info
|
||||
- **Role**: tutor-skills 作者
|
||||
- **GitHub**: `RoundTable02/tutor-skills`
|
||||
|
||||
## Aliases
|
||||
- Choi Wontak
|
||||
|
||||
## Key Contributions
|
||||
开发了 **tutor-skills** — Obsidian "输入-内化-检测" 完整学习闭环系统，包含两个 Skill：
|
||||
|
||||
| Skill | 功能 |
|
||||
|-------|------|
|
||||
| [[Tutor-Setup]] | 将任意本地文档或源代码工程自动解析，生成带双链、MOC 和复习题的 StudyVault |
|
||||
| [[Tutor]] | 读取知识库进度数据，在终端内生成互动式测验，追踪并攻克知识薄弱点 |
|
||||
|
||||
### 核心机制
|
||||
- **模式自动侦测**：无需手动指定，自动识别 `package.json`/`pom.xml` 等工程文件进入"代码库模式"，PDF/纯文本则进入"文档模式"
|
||||
- **输入-内化-检测闭环**：文档解析 → 知识库构建 → 互动测验 → 薄弱点追踪
|
||||
|
||||
### 风险提示
|
||||
- "代码库模式"会递归读取大量源文件并进行架构溯源（Phase C1-C9 循环），短时间内消耗大量 Token 额度
|
||||
|
||||
## Connections
|
||||
- [[obsidian-必装-skills]] — 技能来源
|
||||
- [[Tutor-Skills]] — Choi Wontak 开发的 Skill 套件
|
||||
- [[StudyVault]] — tutor-setup 生成的学习知识库格式
|
||||
- [[OpenClaw]] — tutor-skills 的运行基础环境
|
||||
---
|
||||
title: "Choi Wontak"
|
||||
type: entity
|
||||
tags: [obsidian, skills, learning]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Basic Info
|
||||
- **Role**: tutor-skills 作者
|
||||
- **GitHub**: `RoundTable02/tutor-skills`
|
||||
|
||||
## Aliases
|
||||
- Choi Wontak
|
||||
|
||||
## Key Contributions
|
||||
开发了 **tutor-skills** — Obsidian "输入-内化-检测" 完整学习闭环系统，包含两个 Skill：
|
||||
|
||||
| Skill | 功能 |
|
||||
|-------|------|
|
||||
| [[Tutor-Setup]] | 将任意本地文档或源代码工程自动解析，生成带双链、MOC 和复习题的 StudyVault |
|
||||
| [[Tutor]] | 读取知识库进度数据，在终端内生成互动式测验，追踪并攻克知识薄弱点 |
|
||||
|
||||
### 核心机制
|
||||
- **模式自动侦测**：无需手动指定，自动识别 `package.json`/`pom.xml` 等工程文件进入"代码库模式"，PDF/纯文本则进入"文档模式"
|
||||
- **输入-内化-检测闭环**：文档解析 → 知识库构建 → 互动测验 → 薄弱点追踪
|
||||
|
||||
### 风险提示
|
||||
- "代码库模式"会递归读取大量源文件并进行架构溯源（Phase C1-C9 循环），短时间内消耗大量 Token 额度
|
||||
|
||||
## Connections
|
||||
- [[obsidian-必装-skills]] — 技能来源
|
||||
- [[Tutor-Skills]] — Choi Wontak 开发的 Skill 套件
|
||||
- [[StudyVault]] — tutor-setup 生成的学习知识库格式
|
||||
- [[OpenClaw]] — tutor-skills 的运行基础环境
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: "Claude Desktop"
|
||||
type: entity
|
||||
tags: [anthropic, ai, mcp, desktop-app]
|
||||
last_updated: 2025-12-31
|
||||
---
|
||||
|
||||
## Overview
|
||||
**Claude Desktop** 是 Anthropic 官方发布的 Claude AI 桌面客户端应用，支持通过 MCP（Model Context Protocol）协议扩展集成外部工具和服务。与 Claude Code（CLI）和 Claude API（编程接口）不同，Claude Desktop 提供图形界面，适合日常用户和终端用户使用。
|
||||
|
||||
## MCP Integration
|
||||
Claude Desktop 内置 MCP 支持，可在开发者设置（Developer settings）中编辑 `claude_desktop_config.json` 配置文件，添加 MCP 服务器连接。典型集成包括：
|
||||
- **n8n-mcp**：连接 n8n 工作流引擎，通过自然语言生成 N8N 工作流
|
||||
- **其他 MCP 服务器**：文件系统、数据库、API 等外部工具调用
|
||||
|
||||
## Related
|
||||
- [[Claude Code]] — Anthropic CLI agent（命令行版本）
|
||||
- [[Claude Pro]] — Claude Pro 订阅服务
|
||||
- [[n8n-mcp]] — 连接 Claude Desktop 与 n8n 的 MCP 服务器
|
||||
- [[MCP（Model Context Protocol）]] — 使 Claude Desktop 扩展外部工具的协议
|
||||
---
|
||||
title: "Claude Desktop"
|
||||
type: entity
|
||||
tags: [anthropic, ai, mcp, desktop-app]
|
||||
last_updated: 2025-12-31
|
||||
---
|
||||
|
||||
## Overview
|
||||
**Claude Desktop** 是 Anthropic 官方发布的 Claude AI 桌面客户端应用，支持通过 MCP（Model Context Protocol）协议扩展集成外部工具和服务。与 Claude Code（CLI）和 Claude API（编程接口）不同，Claude Desktop 提供图形界面，适合日常用户和终端用户使用。
|
||||
|
||||
## MCP Integration
|
||||
Claude Desktop 内置 MCP 支持，可在开发者设置（Developer settings）中编辑 `claude_desktop_config.json` 配置文件，添加 MCP 服务器连接。典型集成包括：
|
||||
- **n8n-mcp**：连接 n8n 工作流引擎，通过自然语言生成 N8N 工作流
|
||||
- **其他 MCP 服务器**：文件系统、数据库、API 等外部工具调用
|
||||
|
||||
## Related
|
||||
- [[Claude Code]] — Anthropic CLI agent（命令行版本）
|
||||
- [[Claude Pro]] — Claude Pro 订阅服务
|
||||
- [[n8n-mcp]] — 连接 Claude Desktop 与 n8n 的 MCP 服务器
|
||||
- [[MCP（Model Context Protocol）]] — 使 Claude Desktop 扩展外部工具的协议
|
||||
|
||||
@@ -1,37 +1,37 @@
|
||||
---
|
||||
title: "Claude Pro"
|
||||
type: entity
|
||||
tags: [ai-service, subscription, anthropic]
|
||||
date: 2025-12-31
|
||||
---
|
||||
|
||||
# Claude Pro
|
||||
|
||||
## 基本信息
|
||||
- **类型**: AI服务/产品
|
||||
- **提供方**: Anthropic
|
||||
- **官网**: https://claude.ai
|
||||
- **月费**: 20美元
|
||||
- **支付方式**: 需要海外信用卡
|
||||
|
||||
## 功能特性
|
||||
- **访问Claude 3.5 Sonnet**: 更高性能的语言模型
|
||||
- **优先访问权**: 在高峰时段享受优先访问
|
||||
- **早期功能体验**: 优先体验新功能
|
||||
|
||||
## 订阅挑战（中国用户）
|
||||
- 国内信用卡无法直接支付
|
||||
- 需要虚拟信用卡（如WildCard）
|
||||
- 需要美国区手机号验证
|
||||
- 需要稳定的美国IP地址
|
||||
|
||||
## 相关页面
|
||||
- [[Claude]]
|
||||
- [[WildCard]]
|
||||
- [[AdsPower]]
|
||||
- [[PingMe]]
|
||||
- [[指纹浏览器]]
|
||||
- [[虚拟信用卡]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
---
|
||||
title: "Claude Pro"
|
||||
type: entity
|
||||
tags: [ai-service, subscription, anthropic]
|
||||
date: 2025-12-31
|
||||
---
|
||||
|
||||
# Claude Pro
|
||||
|
||||
## 基本信息
|
||||
- **类型**: AI服务/产品
|
||||
- **提供方**: Anthropic
|
||||
- **官网**: https://claude.ai
|
||||
- **月费**: 20美元
|
||||
- **支付方式**: 需要海外信用卡
|
||||
|
||||
## 功能特性
|
||||
- **访问Claude 3.5 Sonnet**: 更高性能的语言模型
|
||||
- **优先访问权**: 在高峰时段享受优先访问
|
||||
- **早期功能体验**: 优先体验新功能
|
||||
|
||||
## 订阅挑战（中国用户）
|
||||
- 国内信用卡无法直接支付
|
||||
- 需要虚拟信用卡（如WildCard）
|
||||
- 需要美国区手机号验证
|
||||
- 需要稳定的美国IP地址
|
||||
|
||||
## 相关页面
|
||||
- [[Claude]]
|
||||
- [[WildCard]]
|
||||
- [[AdsPower]]
|
||||
- [[PingMe]]
|
||||
- [[指纹浏览器]]
|
||||
- [[虚拟信用卡]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
|
||||
@@ -1,25 +1,25 @@
|
||||
---
|
||||
title: "ClawHub"
|
||||
type: entity
|
||||
tags: [ClawHub, OpenClaw, Skill, Marketplace]
|
||||
sources: [daily-youtube-digest, phone-call-notifications]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ClawHub
|
||||
- clawhub.ai
|
||||
|
||||
## Definition
|
||||
|
||||
ClawHub（clawhub.ai）是 OpenClaw 的官方 Skill 市场，托管 OpenClaw Agent 可安装的技能包（Skills）。用户可以通过自然语言让 AI Agent 安装 Skill（如 "Install the youtube-full skill"），或通过 `npx clawhub@latest install <skill-name>` 命令行安装。安装后 Skill 自动配置 API Key 并存储到正确的系统位置。
|
||||
|
||||
## Key Skills on ClawHub
|
||||
|
||||
- **youtube-full** — 自动获取 YouTube 频道最新视频、提取字幕并摘要
|
||||
- **clawr.ing** — 为 Agent 提供主动拨打电话通知能力，通过 PSTN 电话触达用户（参见 [[phone-call-notifications]]）
|
||||
- 持续扩充中（官网 clawhub.ai 浏览全部）
|
||||
|
||||
## Connections
|
||||
- [[clawhub.ai]] ← hosts ← [[youtube-full skill]], [[clawr.ing]]
|
||||
- [[OpenClaw]] ← extends via ← [[clawhub.ai]] skills
|
||||
---
|
||||
title: "ClawHub"
|
||||
type: entity
|
||||
tags: [ClawHub, OpenClaw, Skill, Marketplace]
|
||||
sources: [daily-youtube-digest, phone-call-notifications]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- ClawHub
|
||||
- clawhub.ai
|
||||
|
||||
## Definition
|
||||
|
||||
ClawHub（clawhub.ai）是 OpenClaw 的官方 Skill 市场，托管 OpenClaw Agent 可安装的技能包（Skills）。用户可以通过自然语言让 AI Agent 安装 Skill（如 "Install the youtube-full skill"），或通过 `npx clawhub@latest install <skill-name>` 命令行安装。安装后 Skill 自动配置 API Key 并存储到正确的系统位置。
|
||||
|
||||
## Key Skills on ClawHub
|
||||
|
||||
- **youtube-full** — 自动获取 YouTube 频道最新视频、提取字幕并摘要
|
||||
- **clawr.ing** — 为 Agent 提供主动拨打电话通知能力，通过 PSTN 电话触达用户（参见 [[phone-call-notifications]]）
|
||||
- 持续扩充中（官网 clawhub.ai 浏览全部）
|
||||
|
||||
## Connections
|
||||
- [[clawhub.ai]] ← hosts ← [[youtube-full skill]], [[clawr.ing]]
|
||||
- [[OpenClaw]] ← extends via ← [[clawhub.ai]] skills
|
||||
|
||||
@@ -1,33 +1,33 @@
|
||||
---
|
||||
title: "ClawdTalk"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# ClawdTalk
|
||||
|
||||
## Overview
|
||||
ClawdTalk 是由 Telnyx 团队出品的电话集成客户端库（[@team-telnyx/clawdtalk-client](https://github.com/team-telnyx/clawdtalk-client)），使 [[OpenClaw]] 能够接收和拨打电话，将任意手机变成 AI 助理的语音入口。
|
||||
|
||||
## Core Functions
|
||||
- **来电接收**：AI Agent 可接收用户拨打的电话
|
||||
- **去电发起**：AI Agent 可主动拨打电话联系用户
|
||||
- **语音对话**：通过电话实现与 AI Agent 的实时语音交互
|
||||
|
||||
## Architecture
|
||||
- 作为 [[OpenClaw]] 的电话技能（phone skill）集成
|
||||
- 底层依赖 [[Telnyx]] API 提供电信连接
|
||||
- 属于 [[OpenClaw Skills]] 生态，通过 OpenClaw 的 skills 接口调用
|
||||
|
||||
## Related Links
|
||||
- [ClawdTalk Website](https://clawdtalk.com)
|
||||
- [ClawdTalk GitHub](https://github.com/team-telnyx/clawdtalk-client)
|
||||
|
||||
## Sources
|
||||
- [[phone-based-personal-assistant]]
|
||||
|
||||
## Aliases
|
||||
- clawdtalk
|
||||
- ClawdTalk Client
|
||||
---
|
||||
title: "ClawdTalk"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
# ClawdTalk
|
||||
|
||||
## Overview
|
||||
ClawdTalk 是由 Telnyx 团队出品的电话集成客户端库（[@team-telnyx/clawdtalk-client](https://github.com/team-telnyx/clawdtalk-client)），使 [[OpenClaw]] 能够接收和拨打电话，将任意手机变成 AI 助理的语音入口。
|
||||
|
||||
## Core Functions
|
||||
- **来电接收**：AI Agent 可接收用户拨打的电话
|
||||
- **去电发起**：AI Agent 可主动拨打电话联系用户
|
||||
- **语音对话**：通过电话实现与 AI Agent 的实时语音交互
|
||||
|
||||
## Architecture
|
||||
- 作为 [[OpenClaw]] 的电话技能（phone skill）集成
|
||||
- 底层依赖 [[Telnyx]] API 提供电信连接
|
||||
- 属于 [[OpenClaw Skills]] 生态，通过 OpenClaw 的 skills 接口调用
|
||||
|
||||
## Related Links
|
||||
- [ClawdTalk Website](https://clawdtalk.com)
|
||||
- [ClawdTalk GitHub](https://github.com/team-telnyx/clawdtalk-client)
|
||||
|
||||
## Sources
|
||||
- [[phone-based-personal-assistant]]
|
||||
|
||||
## Aliases
|
||||
- clawdtalk
|
||||
- ClawdTalk Client
|
||||
|
||||
@@ -1,25 +1,25 @@
|
||||
---
|
||||
title: "Cline"
|
||||
type: entity
|
||||
tags: [AI编码, 开源平替, Cursor, VS-Code]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Definition
|
||||
**Cline** 是 VS Code 生态中公认最强大的开源自主编程插件，被广泛认为是 [[Cursor]] 的最佳开源平替。
|
||||
|
||||
## Key Characteristics
|
||||
- 直接嵌入现有 VS Code 工作流，将编辑器变身为能深度理解项目上下文、自动读取/修改文件、运行终端命令的全自动 AI 工程师
|
||||
- 支持 MCP（Model Context Protocol）扩展，可连接本地数据库或外部工具
|
||||
- 执行敏感操作（写入文件、运行 Shell 命令）时请求用户授权，兼顾自主性和安全性
|
||||
- 硬核开发者 2025 年实现本地化 AI 编程的首选工具
|
||||
|
||||
## GitHub
|
||||
- https://github.com/cline/cline
|
||||
|
||||
## Related
|
||||
- [[Cursor]] — Cline 对标的开源平替对象
|
||||
- [[Claude Code]] — 被定义为"基于终端的 AI Agent"，与 Cline 同属 AI 编程工具生态
|
||||
|
||||
## Sources
|
||||
- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]
|
||||
---
|
||||
title: "Cline"
|
||||
type: entity
|
||||
tags: [AI编码, 开源平替, Cursor, VS-Code]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Definition
|
||||
**Cline** 是 VS Code 生态中公认最强大的开源自主编程插件，被广泛认为是 [[Cursor]] 的最佳开源平替。
|
||||
|
||||
## Key Characteristics
|
||||
- 直接嵌入现有 VS Code 工作流，将编辑器变身为能深度理解项目上下文、自动读取/修改文件、运行终端命令的全自动 AI 工程师
|
||||
- 支持 MCP（Model Context Protocol）扩展，可连接本地数据库或外部工具
|
||||
- 执行敏感操作（写入文件、运行 Shell 命令）时请求用户授权，兼顾自主性和安全性
|
||||
- 硬核开发者 2025 年实现本地化 AI 编程的首选工具
|
||||
|
||||
## GitHub
|
||||
- https://github.com/cline/cline
|
||||
|
||||
## Related
|
||||
- [[Cursor]] — Cline 对标的开源平替对象
|
||||
- [[Claude Code]] — 被定义为"基于终端的 AI Agent"，与 Cline 同属 AI 编程工具生态
|
||||
|
||||
## Sources
|
||||
- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]
|
||||
|
||||
@@ -1,64 +1,64 @@
|
||||
---
|
||||
title: "Clonezilla"
|
||||
tags: [backup, opensource, disk-imaging, dr]
|
||||
date: 2026-04-28
|
||||
---
|
||||
|
||||
# Clonezilla (再生龙)
|
||||
|
||||
## Aliases
|
||||
- Clonezilla
|
||||
- 再生龙
|
||||
|
||||
## Definition
|
||||
Clonezilla 是一款开源的磁盘镜像/克隆工具，类似于 Norton Ghost，提供完整的系统级备份与还原功能。支持将整个磁盘或单个分区备份为镜像文件，存储到本地磁盘、NFS、SMB、SFTP 等多种目标位置。
|
||||
|
||||
## Core Capabilities
|
||||
- **savedisk**: 将整个磁盘备份为镜像文件
|
||||
- **saveparts**: 仅备份指定分区
|
||||
- **restoredisk**: 从镜像还原整个磁盘
|
||||
- **restoreparts**: 从镜像还原指定分区
|
||||
- **device-image 模式**: 将磁盘映射为镜像文件存储（区别于直接磁盘对磁盘克隆）
|
||||
|
||||
## Key Features
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| 备份介质 | 本地磁盘、外置硬盘、NFS、SMB、SFTP、SSH |
|
||||
| 压缩选项 | -z1p (高压缩率), -z2p, -z3p, -z4p |
|
||||
| 文件系统支持 | ext2/3/4, NTFS, FAT, HFS+, XFS, Btrfs 等 |
|
||||
| 分区表支持 | MBR 和 GPT |
|
||||
| 模式 | Beginner（初学者）/ Expert（专家） |
|
||||
| 启动介质 | Live CD, Live USB, PXE 网络启动 |
|
||||
|
||||
## Backup Workflow
|
||||
```
|
||||
1. 制作 Clonezilla 启动 U 盘 (Rufus ISO 模式)
|
||||
2. 从 U 盘启动源机器，进入 Clonezilla Live
|
||||
3. 选择 device-image 模式
|
||||
4. 挂载 NAS/外置硬盘作为备份目标
|
||||
5. 选择 savedisk → 选择源磁盘 → 配置参数
|
||||
6. 等待镜像生成
|
||||
```
|
||||
|
||||
## Restore Workflow
|
||||
```
|
||||
1. 从 U 盘启动目标机器（或原机器）
|
||||
2. 进入 Clonezilla，选择 device-image 模式
|
||||
3. 挂载存储镜像的 NAS/外置硬盘
|
||||
4. 选择 restoredisk → 选择镜像文件 → 选择目标磁盘
|
||||
5. 确认覆盖 → 等待还原完成 → 系统即刻复活
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[全盘镜像备份]] — Clonezilla 实现的备份方法
|
||||
- [[NFS网络备份]] — Clonezilla 推荐的网络存储方案
|
||||
- [[裸机恢复]] — Clonezilla 支持的核心场景
|
||||
- [[增量备份]] — Clonezilla 镜像备份 vs rsync 增量备份（互补方案）
|
||||
|
||||
## Related Sources
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]]
|
||||
|
||||
## Related Entities
|
||||
- [[Rufus]] — U 盘启动盘制作工具
|
||||
- [[Synology NAS]] — 备份镜像存储目标
|
||||
- [[HP ZBook]] — 源笔记本设备
|
||||
---
|
||||
title: "Clonezilla"
|
||||
tags: [backup, opensource, disk-imaging, dr]
|
||||
date: 2026-04-28
|
||||
---
|
||||
|
||||
# Clonezilla (再生龙)
|
||||
|
||||
## Aliases
|
||||
- Clonezilla
|
||||
- 再生龙
|
||||
|
||||
## Definition
|
||||
Clonezilla 是一款开源的磁盘镜像/克隆工具，类似于 Norton Ghost，提供完整的系统级备份与还原功能。支持将整个磁盘或单个分区备份为镜像文件，存储到本地磁盘、NFS、SMB、SFTP 等多种目标位置。
|
||||
|
||||
## Core Capabilities
|
||||
- **savedisk**: 将整个磁盘备份为镜像文件
|
||||
- **saveparts**: 仅备份指定分区
|
||||
- **restoredisk**: 从镜像还原整个磁盘
|
||||
- **restoreparts**: 从镜像还原指定分区
|
||||
- **device-image 模式**: 将磁盘映射为镜像文件存储（区别于直接磁盘对磁盘克隆）
|
||||
|
||||
## Key Features
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| 备份介质 | 本地磁盘、外置硬盘、NFS、SMB、SFTP、SSH |
|
||||
| 压缩选项 | -z1p (高压缩率), -z2p, -z3p, -z4p |
|
||||
| 文件系统支持 | ext2/3/4, NTFS, FAT, HFS+, XFS, Btrfs 等 |
|
||||
| 分区表支持 | MBR 和 GPT |
|
||||
| 模式 | Beginner（初学者）/ Expert（专家） |
|
||||
| 启动介质 | Live CD, Live USB, PXE 网络启动 |
|
||||
|
||||
## Backup Workflow
|
||||
```
|
||||
1. 制作 Clonezilla 启动 U 盘 (Rufus ISO 模式)
|
||||
2. 从 U 盘启动源机器，进入 Clonezilla Live
|
||||
3. 选择 device-image 模式
|
||||
4. 挂载 NAS/外置硬盘作为备份目标
|
||||
5. 选择 savedisk → 选择源磁盘 → 配置参数
|
||||
6. 等待镜像生成
|
||||
```
|
||||
|
||||
## Restore Workflow
|
||||
```
|
||||
1. 从 U 盘启动目标机器（或原机器）
|
||||
2. 进入 Clonezilla，选择 device-image 模式
|
||||
3. 挂载存储镜像的 NAS/外置硬盘
|
||||
4. 选择 restoredisk → 选择镜像文件 → 选择目标磁盘
|
||||
5. 确认覆盖 → 等待还原完成 → 系统即刻复活
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[全盘镜像备份]] — Clonezilla 实现的备份方法
|
||||
- [[NFS网络备份]] — Clonezilla 推荐的网络存储方案
|
||||
- [[裸机恢复]] — Clonezilla 支持的核心场景
|
||||
- [[增量备份]] — Clonezilla 镜像备份 vs rsync 增量备份（互补方案）
|
||||
|
||||
## Related Sources
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]]
|
||||
|
||||
## Related Entities
|
||||
- [[Rufus]] — U 盘启动盘制作工具
|
||||
- [[Synology NAS]] — 备份镜像存储目标
|
||||
- [[HP ZBook]] — 源笔记本设备
|
||||
|
||||
@@ -1,107 +1,107 @@
|
||||
# Cloud Maturity Model
|
||||
|
||||
> **Cloud Maturity Model (CMM)** — 企业云成熟度评估框架，用于衡量组织在云采用旅程中所处的阶段，并指导其向更高成熟度水平演进。
|
||||
|
||||
## Definition
|
||||
|
||||
云成熟度模型（Cloud Maturity Model, CMM）是一个结构化框架，用于评估组织在云采用旅程中的当前状态，并提供通往更高成熟度的明确路径。根据 Open Alliance for Cloud Adoption (OACA) 的定义，CMM 协助组织：
|
||||
|
||||
- 识别云采用或混合 IT 环境的定制化解决方案
|
||||
- 评估云采用就绪度
|
||||
- 评估当前云服务使用情况
|
||||
- 设定未来目标以制定云迁移战略
|
||||
- 进行 GAP 分析并基于业务目标识别云基础设施改进领域
|
||||
|
||||
## Industry Context
|
||||
|
||||
| 指标 | 数据 |
|
||||
|------|------|
|
||||
| 行业规模（2022） | 7.5 亿美元 |
|
||||
| 预测规模（2025） | 15 亿美元 |
|
||||
| 已实施 CMM 的组织 | 60%+ |
|
||||
| 来源 | Forrester + Gartner |
|
||||
|
||||
## 5 Levels of Cloud Maturity
|
||||
|
||||
| Level | 名称 | 特征 |
|
||||
|-------|------|------|
|
||||
| **Level 0** | 无云就绪（Legacy） | 完全不使用云，纯本地遗留系统 |
|
||||
| **Level 1** | 初始就绪（Ad hoc） | 初步评估，部分 SaaS 使用，无整体战略 |
|
||||
| **Level 2** | 可重复（Repeatable） | 建立流程，广泛使用云服务，方法尚不系统 |
|
||||
| **Level 3** | 系统化（Systematic） | 文档化实践，托管服务，外包管理 |
|
||||
| **Level 4** | 可衡量（Measured） | 云原生应用广泛采用，治理模型透明 |
|
||||
| **Level 5** | 优化级（Optimized） | 数据驱动决策，跨平台灵活迁移工作负载 |
|
||||
|
||||
> ⚠️ **Level 5 通常更具理想性** — 许多公司可能开发开放互通的云环境，但在流程优化和数据充分利用方面仍有差距。
|
||||
|
||||
## Key Components
|
||||
|
||||
### Business Capability Areas
|
||||
- Finance（CAPEX → OPEX）
|
||||
- Enterprise Strategy
|
||||
- Organizational Structure
|
||||
- Culture
|
||||
- Governance
|
||||
- Skills & Training
|
||||
- Compliance
|
||||
- Business Processes
|
||||
- Procurement
|
||||
- Commercial Management
|
||||
- Portfolio Management
|
||||
- Projects
|
||||
|
||||
### Technical Capability Areas
|
||||
- IT Architecture
|
||||
- Applications
|
||||
- Management Tools
|
||||
- IT Operations Processes
|
||||
- DevOps
|
||||
- Security
|
||||
- IaaS / PaaS / SaaS
|
||||
- IPaaS / STaaS
|
||||
- Data & Information Services
|
||||
- Network
|
||||
- AI / ML
|
||||
- IoT
|
||||
- APIs
|
||||
|
||||
### Evaluation Dimensions
|
||||
- **People** — 人员能力与新技能培养
|
||||
- **Processes** — 流程优化与更新
|
||||
- **Technology** — 技术基础设施适配
|
||||
|
||||
## Benefits
|
||||
|
||||
1. **Enhanced Strategic Planning** — 聚焦高影响领域
|
||||
2. **Improved Team Communications** — 共享目标与进度
|
||||
3. **Enhanced Application Performance** — 提升可用性与响应
|
||||
4. **Enhanced Security** — 改进访问控制、加密、合规
|
||||
5. **Faster Time to Market** — 快速响应市场需求
|
||||
6. **Industry Benchmarking** — 与同行对标
|
||||
7. **Cost Savings** — 效率提升与自动化降低运营成本
|
||||
|
||||
## Related Maturity Models
|
||||
|
||||
- **CMM 4.8** — 跨域和云服务类型评估
|
||||
- **Cloud Native Maturity Model** — CNCF 云原生采用
|
||||
- **Cloud Security Maturity Model (CSMM)** — 云安全成熟度
|
||||
- **Software Assurance Maturity Model (SAMM)** — 软件开发生命周期
|
||||
- **AWS Cloud Adoption Framework** — AWS 特定最佳实践
|
||||
- **Azure Cloud Adoption Framework** — Azure 采用框架
|
||||
- **Google Cloud Adoption Framework** — GCP 采用框架
|
||||
|
||||
## See Also
|
||||
|
||||
- [[Cloud Maturity Levels]] — 5级成熟度详细定义
|
||||
- [[Cloud Adoption Strategy]] — 云采用策略
|
||||
- [[Cloud Governance]] — 云治理
|
||||
- [[Cloud-Native]] — 云原生
|
||||
- [[Multi-Cloud Strategy]] — 多云策略
|
||||
- [[FinOps]] — 云财务管理
|
||||
- [[DevOps Maturity]] — DevOps 成熟度
|
||||
- [[DORA Metrics]] — DORA 指标
|
||||
|
||||
## Sources
|
||||
|
||||
- [Bacancy Technology: Cloud Maturity Model](https://www.bacancytechnology.com/blog/cloud-maturity-model)
|
||||
- [[sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption]]
|
||||
# Cloud Maturity Model
|
||||
|
||||
> **Cloud Maturity Model (CMM)** — 企业云成熟度评估框架，用于衡量组织在云采用旅程中所处的阶段，并指导其向更高成熟度水平演进。
|
||||
|
||||
## Definition
|
||||
|
||||
云成熟度模型（Cloud Maturity Model, CMM）是一个结构化框架，用于评估组织在云采用旅程中的当前状态，并提供通往更高成熟度的明确路径。根据 Open Alliance for Cloud Adoption (OACA) 的定义，CMM 协助组织：
|
||||
|
||||
- 识别云采用或混合 IT 环境的定制化解决方案
|
||||
- 评估云采用就绪度
|
||||
- 评估当前云服务使用情况
|
||||
- 设定未来目标以制定云迁移战略
|
||||
- 进行 GAP 分析并基于业务目标识别云基础设施改进领域
|
||||
|
||||
## Industry Context
|
||||
|
||||
| 指标 | 数据 |
|
||||
|------|------|
|
||||
| 行业规模（2022） | 7.5 亿美元 |
|
||||
| 预测规模（2025） | 15 亿美元 |
|
||||
| 已实施 CMM 的组织 | 60%+ |
|
||||
| 来源 | Forrester + Gartner |
|
||||
|
||||
## 5 Levels of Cloud Maturity
|
||||
|
||||
| Level | 名称 | 特征 |
|
||||
|-------|------|------|
|
||||
| **Level 0** | 无云就绪（Legacy） | 完全不使用云，纯本地遗留系统 |
|
||||
| **Level 1** | 初始就绪（Ad hoc） | 初步评估，部分 SaaS 使用，无整体战略 |
|
||||
| **Level 2** | 可重复（Repeatable） | 建立流程，广泛使用云服务，方法尚不系统 |
|
||||
| **Level 3** | 系统化（Systematic） | 文档化实践，托管服务，外包管理 |
|
||||
| **Level 4** | 可衡量（Measured） | 云原生应用广泛采用，治理模型透明 |
|
||||
| **Level 5** | 优化级（Optimized） | 数据驱动决策，跨平台灵活迁移工作负载 |
|
||||
|
||||
> ⚠️ **Level 5 通常更具理想性** — 许多公司可能开发开放互通的云环境，但在流程优化和数据充分利用方面仍有差距。
|
||||
|
||||
## Key Components
|
||||
|
||||
### Business Capability Areas
|
||||
- Finance（CAPEX → OPEX）
|
||||
- Enterprise Strategy
|
||||
- Organizational Structure
|
||||
- Culture
|
||||
- Governance
|
||||
- Skills & Training
|
||||
- Compliance
|
||||
- Business Processes
|
||||
- Procurement
|
||||
- Commercial Management
|
||||
- Portfolio Management
|
||||
- Projects
|
||||
|
||||
### Technical Capability Areas
|
||||
- IT Architecture
|
||||
- Applications
|
||||
- Management Tools
|
||||
- IT Operations Processes
|
||||
- DevOps
|
||||
- Security
|
||||
- IaaS / PaaS / SaaS
|
||||
- IPaaS / STaaS
|
||||
- Data & Information Services
|
||||
- Network
|
||||
- AI / ML
|
||||
- IoT
|
||||
- APIs
|
||||
|
||||
### Evaluation Dimensions
|
||||
- **People** — 人员能力与新技能培养
|
||||
- **Processes** — 流程优化与更新
|
||||
- **Technology** — 技术基础设施适配
|
||||
|
||||
## Benefits
|
||||
|
||||
1. **Enhanced Strategic Planning** — 聚焦高影响领域
|
||||
2. **Improved Team Communications** — 共享目标与进度
|
||||
3. **Enhanced Application Performance** — 提升可用性与响应
|
||||
4. **Enhanced Security** — 改进访问控制、加密、合规
|
||||
5. **Faster Time to Market** — 快速响应市场需求
|
||||
6. **Industry Benchmarking** — 与同行对标
|
||||
7. **Cost Savings** — 效率提升与自动化降低运营成本
|
||||
|
||||
## Related Maturity Models
|
||||
|
||||
- **CMM 4.8** — 跨域和云服务类型评估
|
||||
- **Cloud Native Maturity Model** — CNCF 云原生采用
|
||||
- **Cloud Security Maturity Model (CSMM)** — 云安全成熟度
|
||||
- **Software Assurance Maturity Model (SAMM)** — 软件开发生命周期
|
||||
- **AWS Cloud Adoption Framework** — AWS 特定最佳实践
|
||||
- **Azure Cloud Adoption Framework** — Azure 采用框架
|
||||
- **Google Cloud Adoption Framework** — GCP 采用框架
|
||||
|
||||
## See Also
|
||||
|
||||
- [[Cloud Maturity Levels]] — 5级成熟度详细定义
|
||||
- [[Cloud Adoption Strategy]] — 云采用策略
|
||||
- [[Cloud Governance]] — 云治理
|
||||
- [[Cloud-Native]] — 云原生
|
||||
- [[Multi-Cloud Strategy]] — 多云策略
|
||||
- [[FinOps]] — 云财务管理
|
||||
- [[DevOps Maturity]] — DevOps 成熟度
|
||||
- [[DORA Metrics]] — DORA 指标
|
||||
|
||||
## Sources
|
||||
|
||||
- [Bacancy Technology: Cloud Maturity Model](https://www.bacancytechnology.com/blog/cloud-maturity-model)
|
||||
- [[sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption]]
|
||||
|
||||
@@ -1,40 +1,40 @@
|
||||
---
|
||||
title: Cloud Provider
|
||||
tags: [Cloud, Infrastructure, IaaS]
|
||||
---
|
||||
|
||||
# Cloud Provider
|
||||
|
||||
## Overview
|
||||
|
||||
**Cloud Provider** 指提供云计算服务的企业或组织，通过互联网按需提供计算资源、存储、应用和服务。主要云提供商形成了一个竞争激烈的市场，企业可通过多云策略在不同提供商之间分配工作负载以优化性能和成本。
|
||||
|
||||
## Major Cloud Providers
|
||||
|
||||
| Provider | Full Name | Key Strengths |
|
||||
|----------|-----------|---------------|
|
||||
| AWS | Amazon Web Services | 最早、最大生态，计算/存储/AI 最全面 |
|
||||
| Azure | Microsoft Azure | 企业级集成、Microsoft 365 深度整合、混合云 |
|
||||
| GCP | Google Cloud Platform | 数据分析、AI/ML、Kubernetes 原生 |
|
||||
| OCI | Oracle Cloud Infrastructure | 数据库、企业应用、Exadata |
|
||||
| Alibaba Cloud | 阿里云 | 亚太市场份额、中国市场首选 |
|
||||
| IBM Cloud | IBM Cloud | 企业 AI、混合云、红帽集成 |
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **IaaS** (Infrastructure as a Service): 基础架构级云服务（VM、存储、网络）
|
||||
- **PaaS** (Platform as a Service): 平台级云服务（数据库、开发框架）
|
||||
- **SaaS** (Software as a Service): 软件级云服务（CRM、ERP、协作工具）
|
||||
- **多云策略 (Multi-Cloud)**: 同时使用多个云提供商的策略
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud Strategy]]
|
||||
- [[Vendor Lock-In]]
|
||||
- [[Cloud Migration]]
|
||||
- [[High Availability]]
|
||||
- [[Scalability]]
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
---
|
||||
title: Cloud Provider
|
||||
tags: [Cloud, Infrastructure, IaaS]
|
||||
---
|
||||
|
||||
# Cloud Provider
|
||||
|
||||
## Overview
|
||||
|
||||
**Cloud Provider** 指提供云计算服务的企业或组织，通过互联网按需提供计算资源、存储、应用和服务。主要云提供商形成了一个竞争激烈的市场，企业可通过多云策略在不同提供商之间分配工作负载以优化性能和成本。
|
||||
|
||||
## Major Cloud Providers
|
||||
|
||||
| Provider | Full Name | Key Strengths |
|
||||
|----------|-----------|---------------|
|
||||
| AWS | Amazon Web Services | 最早、最大生态，计算/存储/AI 最全面 |
|
||||
| Azure | Microsoft Azure | 企业级集成、Microsoft 365 深度整合、混合云 |
|
||||
| GCP | Google Cloud Platform | 数据分析、AI/ML、Kubernetes 原生 |
|
||||
| OCI | Oracle Cloud Infrastructure | 数据库、企业应用、Exadata |
|
||||
| Alibaba Cloud | 阿里云 | 亚太市场份额、中国市场首选 |
|
||||
| IBM Cloud | IBM Cloud | 企业 AI、混合云、红帽集成 |
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **IaaS** (Infrastructure as a Service): 基础架构级云服务（VM、存储、网络）
|
||||
- **PaaS** (Platform as a Service): 平台级云服务（数据库、开发框架）
|
||||
- **SaaS** (Software as a Service): 软件级云服务（CRM、ERP、协作工具）
|
||||
- **多云策略 (Multi-Cloud)**: 同时使用多个云提供商的策略
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud Strategy]]
|
||||
- [[Vendor Lock-In]]
|
||||
- [[Cloud Migration]]
|
||||
- [[High Availability]]
|
||||
- [[Scalability]]
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
|
||||
@@ -1,25 +1,25 @@
|
||||
---
|
||||
title: "CodeCrafters"
|
||||
type: entity
|
||||
tags: [education, programming, platform, byox]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- codecrafters.io
|
||||
- CodeCrafters Inc.
|
||||
|
||||
## Definition
|
||||
CodeCrafters（旧金山教育科技创业公司）是一家提供实战编程挑战的在线教育平台，以"Build Your Own X"理念为核心。平台提供分步骤练习，手把手教开发者从零重建 Git、Docker、Redis、Web Server 等主流技术，让学习者通过动手实践深入理解系统内部原理。
|
||||
|
||||
## Details
|
||||
- **Website**: codecrafters.io
|
||||
- **GitHub**: codecrafters-io/build-your-own-x（该列表由 CodeCrafters 维护，收录 26+ 技术领域）
|
||||
- **创始人**: Daniel Stefanovic（最初由其创建 build-your-own-x 项目）
|
||||
- **融资**: Y Combinator W24 批次
|
||||
- **商业模式**: 提供配套在线编程挑战平台，通过实战练习强化 build-your-own-x 学习路径
|
||||
|
||||
## Connections
|
||||
- [[Build-Your-Own-X]] ← maintained_by ← [[CodeCrafters]]
|
||||
- [[Learn-By-Building]] ← embodied_in ← [[Build-Your-Own-X]]
|
||||
- [[CodeCrafters]] ← contributed_by ← [[DanielStefanovic]]
|
||||
---
|
||||
title: "CodeCrafters"
|
||||
type: entity
|
||||
tags: [education, programming, platform, byox]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- codecrafters.io
|
||||
- CodeCrafters Inc.
|
||||
|
||||
## Definition
|
||||
CodeCrafters（旧金山教育科技创业公司）是一家提供实战编程挑战的在线教育平台，以"Build Your Own X"理念为核心。平台提供分步骤练习，手把手教开发者从零重建 Git、Docker、Redis、Web Server 等主流技术，让学习者通过动手实践深入理解系统内部原理。
|
||||
|
||||
## Details
|
||||
- **Website**: codecrafters.io
|
||||
- **GitHub**: codecrafters-io/build-your-own-x（该列表由 CodeCrafters 维护，收录 26+ 技术领域）
|
||||
- **创始人**: Daniel Stefanovic（最初由其创建 build-your-own-x 项目）
|
||||
- **融资**: Y Combinator W24 批次
|
||||
- **商业模式**: 提供配套在线编程挑战平台，通过实战练习强化 build-your-own-x 学习路径
|
||||
|
||||
## Connections
|
||||
- [[Build-Your-Own-X]] ← maintained_by ← [[CodeCrafters]]
|
||||
- [[Learn-By-Building]] ← embodied_in ← [[Build-Your-Own-X]]
|
||||
- [[CodeCrafters]] ← contributed_by ← [[DanielStefanovic]]
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: "CodeWeaver"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2025-12-30
|
||||
---
|
||||
|
||||
## Basic Info
|
||||
|
||||
- **Name**: CodeWeaver
|
||||
- **Type**: 开源工具/项目
|
||||
- **Repository**: [github.com/tesserato/CodeWeaver](https://github.com/tesserato/CodeWeaver)
|
||||
|
||||
## Description
|
||||
|
||||
CodeWeaver 将代码库编织成可导航 Markdown 文档的工具，可处理"屎山代码"，生成树形结构的清晰文档。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[CodeWeaver]]（Concept 版本）：详细功能描述
|
||||
|
||||
## Sources
|
||||
|
||||
- [[vibe-coding经验收集]]
|
||||
---
|
||||
title: "CodeWeaver"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2025-12-30
|
||||
---
|
||||
|
||||
## Basic Info
|
||||
|
||||
- **Name**: CodeWeaver
|
||||
- **Type**: 开源工具/项目
|
||||
- **Repository**: [github.com/tesserato/CodeWeaver](https://github.com/tesserato/CodeWeaver)
|
||||
|
||||
## Description
|
||||
|
||||
CodeWeaver 将代码库编织成可导航 Markdown 文档的工具，可处理"屎山代码"，生成树形结构的清晰文档。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[CodeWeaver]]（Concept 版本）：详细功能描述
|
||||
|
||||
## Sources
|
||||
|
||||
- [[vibe-coding经验收集]]
|
||||
|
||||
@@ -1,39 +1,39 @@
|
||||
---
|
||||
title: "Coze（扣子）"
|
||||
type: entity
|
||||
tags: [ai-agent, platform]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- 扣子
|
||||
- coze.cn
|
||||
- coze.com
|
||||
- Coze
|
||||
|
||||
## Summary
|
||||
字节跳动旗下的 AI Agent（智能体）低代码开发平台，提供 Bot 创建、Workflow 编排、知识库管理、插件系统等完整能力。用户可通过可视化界面快速构建覆盖多行业的 AI Agent，无需编程基础。国内版（coze.cn）和海外版（coze.com）分别独立运营。
|
||||
|
||||
## Key Capabilities
|
||||
- **Bot（智能体）**：基于大模型的对话式 Agent，支持 Prompt 设定、角色定义、知识库挂载、插件调用
|
||||
- **Workflow（工作流）**：可视化编排多个 Bot 和插件，实现复杂业务流程自动化
|
||||
- **知识库（Knowledge Base）**：上传文档自动向量化，支持 RAG 检索增强问答
|
||||
- **插件（Plugins）**：扩展 Agent 能力，如天气查询、地图、代码执行、数据库查询等
|
||||
- **Function Call**：Agent 可调用外部 API，实现真实业务系统集成
|
||||
|
||||
## Industry Use Cases
|
||||
Coze 平台上积累了大量跨行业 Agent Demo，包括：
|
||||
- **金融**：客户分层营销助手、智能客服
|
||||
- **医疗**：分诊助手、影像识别问诊
|
||||
- **教育**：知识库问答、拍照搜题、组卷出题、知识点掌握评估
|
||||
- **电商**：混剪助手、AI 换衣、抖音直播间自动回复
|
||||
- **人力资源**：招聘打分、面试对练、AI 培训对练
|
||||
- **泛娱乐**：AI 证件照、AI 生成视频工作流
|
||||
- **在线客服**：AI 助教、AI 销售
|
||||
|
||||
## Key Links
|
||||
- Coze 国内版：https://www.coze.cn
|
||||
- Coze 海外版：https://www.coze.com
|
||||
|
||||
## Source
|
||||
- [[AI 解决方案专家培训课程]]
|
||||
---
|
||||
title: "Coze（扣子）"
|
||||
type: entity
|
||||
tags: [ai-agent, platform]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- 扣子
|
||||
- coze.cn
|
||||
- coze.com
|
||||
- Coze
|
||||
|
||||
## Summary
|
||||
字节跳动旗下的 AI Agent（智能体）低代码开发平台，提供 Bot 创建、Workflow 编排、知识库管理、插件系统等完整能力。用户可通过可视化界面快速构建覆盖多行业的 AI Agent，无需编程基础。国内版（coze.cn）和海外版（coze.com）分别独立运营。
|
||||
|
||||
## Key Capabilities
|
||||
- **Bot（智能体）**：基于大模型的对话式 Agent，支持 Prompt 设定、角色定义、知识库挂载、插件调用
|
||||
- **Workflow（工作流）**：可视化编排多个 Bot 和插件，实现复杂业务流程自动化
|
||||
- **知识库（Knowledge Base）**：上传文档自动向量化，支持 RAG 检索增强问答
|
||||
- **插件（Plugins）**：扩展 Agent 能力，如天气查询、地图、代码执行、数据库查询等
|
||||
- **Function Call**：Agent 可调用外部 API，实现真实业务系统集成
|
||||
|
||||
## Industry Use Cases
|
||||
Coze 平台上积累了大量跨行业 Agent Demo，包括：
|
||||
- **金融**：客户分层营销助手、智能客服
|
||||
- **医疗**：分诊助手、影像识别问诊
|
||||
- **教育**：知识库问答、拍照搜题、组卷出题、知识点掌握评估
|
||||
- **电商**：混剪助手、AI 换衣、抖音直播间自动回复
|
||||
- **人力资源**：招聘打分、面试对练、AI 培训对练
|
||||
- **泛娱乐**：AI 证件照、AI 生成视频工作流
|
||||
- **在线客服**：AI 助教、AI 销售
|
||||
|
||||
## Key Links
|
||||
- Coze 国内版：https://www.coze.cn
|
||||
- Coze 海外版：https://www.coze.com
|
||||
|
||||
## Source
|
||||
- [[AI 解决方案专家培训课程]]
|
||||
|
||||
@@ -1,43 +1,43 @@
|
||||
---
|
||||
title: "Cursor"
|
||||
type: entity
|
||||
tags: [ai, ide, code-editor]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
Cursor是基于VS Code的AI增强代码编辑器，集成了AI模型辅助代码生成及多任务代理操作。可免费使用，支持付费升级获取更多生成额度。
|
||||
|
||||
## Aliases
|
||||
- Cursor 2.0
|
||||
- Cursor IDE
|
||||
|
||||
## Key Features
|
||||
- 基于VS Code构建，继承VS Code的完整功能
|
||||
- 集成AI模型辅助代码生成（Composer模型，比同类快4倍）
|
||||
- 支持多AI代理并行操作
|
||||
- 支持MCP（Model Context Protocol）扩展
|
||||
- 提供Diff功能审查AI生成的代码改动
|
||||
- 支持项目规则自定义（如强制生成文档注释）
|
||||
|
||||
## Agent Modes
|
||||
- **Plan（规划模式）**：让AI拆解步骤，形成清晰的开发路线图
|
||||
- **Agent（执行模式）**：AI代理执行计划任务，逐步生成代码，会修改文件
|
||||
- **Ask（咨询模式）**：仅返回文本答案，不改动代码，安全性最高
|
||||
|
||||
## Connections
|
||||
- [[VS Code]] — Cursor基于VS Code构建
|
||||
- [[Composer]] — Cursor自研AI模型
|
||||
- [[MCP（Model Context Protocol）]] — Cursor支持的扩展协议
|
||||
- [[Vibe Coding]] — Cursor是Vibe Coding的典型工具
|
||||
- [[Claude Code]] — 类似产品，AI代码编辑工具
|
||||
|
||||
## Sources
|
||||
- [[cursor-2-0初学者使用指南]]
|
||||
- [[mcp在cursor中的集成与应用详解]]
|
||||
|
||||
## New Insights (from MCP in Cursor Integration)
|
||||
- Composer 支持 Agent 模式和 Normal 模式两种交互方式，Agent 模式可自动执行 MCP 工具链
|
||||
- MCP Server 在 Cursor 中有两种接入方式：SSE 服务端模式和本地 Command 命令行方式
|
||||
- Agent 模式下的 Yolo Mode 会无确认执行所有命令，存在误操作风险（默认关闭）
|
||||
- 典型 MCP 工具：热点新闻服务（smisery 提供九个新闻来源）、Sequential Thinking 逻辑推理工具
|
||||
---
|
||||
title: "Cursor"
|
||||
type: entity
|
||||
tags: [ai, ide, code-editor]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
Cursor是基于VS Code的AI增强代码编辑器，集成了AI模型辅助代码生成及多任务代理操作。可免费使用，支持付费升级获取更多生成额度。
|
||||
|
||||
## Aliases
|
||||
- Cursor 2.0
|
||||
- Cursor IDE
|
||||
|
||||
## Key Features
|
||||
- 基于VS Code构建，继承VS Code的完整功能
|
||||
- 集成AI模型辅助代码生成（Composer模型，比同类快4倍）
|
||||
- 支持多AI代理并行操作
|
||||
- 支持MCP（Model Context Protocol）扩展
|
||||
- 提供Diff功能审查AI生成的代码改动
|
||||
- 支持项目规则自定义（如强制生成文档注释）
|
||||
|
||||
## Agent Modes
|
||||
- **Plan（规划模式）**：让AI拆解步骤，形成清晰的开发路线图
|
||||
- **Agent（执行模式）**：AI代理执行计划任务，逐步生成代码，会修改文件
|
||||
- **Ask（咨询模式）**：仅返回文本答案，不改动代码，安全性最高
|
||||
|
||||
## Connections
|
||||
- [[VS Code]] — Cursor基于VS Code构建
|
||||
- [[Composer]] — Cursor自研AI模型
|
||||
- [[MCP（Model Context Protocol）]] — Cursor支持的扩展协议
|
||||
- [[Vibe Coding]] — Cursor是Vibe Coding的典型工具
|
||||
- [[Claude Code]] — 类似产品，AI代码编辑工具
|
||||
|
||||
## Sources
|
||||
- [[cursor-2-0初学者使用指南]]
|
||||
- [[mcp在cursor中的集成与应用详解]]
|
||||
|
||||
## New Insights (from MCP in Cursor Integration)
|
||||
- Composer 支持 Agent 模式和 Normal 模式两种交互方式，Agent 模式可自动执行 MCP 工具链
|
||||
- MCP Server 在 Cursor 中有两种接入方式：SSE 服务端模式和本地 Command 命令行方式
|
||||
- Agent 模式下的 Yolo Mode 会无确认执行所有命令，存在误操作风险（默认关闭）
|
||||
- 典型 MCP 工具：热点新闻服务（smisery 提供九个新闻来源）、Sequential Thinking 逻辑推理工具
|
||||
|
||||
@@ -1,41 +1,41 @@
|
||||
---
|
||||
title: "Curve Finance"
|
||||
type: entity
|
||||
tags: [blockchain, defi, amm, exploit, compiler-bug]
|
||||
sources: [blockchain-security-auditor]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **时间**：2023 年 7 月 30 日
|
||||
- **平台**：Ethereum（多链，影响 ETH、ARB、CRV、MSRP 等池）
|
||||
- **损失**：超过 7,000 万美元
|
||||
- **根本原因**：Vyper 0.3.0 编译器的重入锁（Reentrancy Guard）实现 bug
|
||||
- **特点**：这是 DeFi 历史上罕见的**编译器 bug 导致的安全事件**，而非业务逻辑漏洞
|
||||
|
||||
## 攻击原理
|
||||
|
||||
Curve Finance 使用 Vyper 语言编写合约，Vyper 0.3.0 的 `nonreentrant` 修饰符存在 bug：当合约存在多个相同名称的回调函数（如 `receive()` 和 `fallback()`）时，重入锁未能正确生效。
|
||||
|
||||
攻击者利用此漏洞对多个 Curve 池发起攻击：
|
||||
1. 在 AMM 池中进行兑换（swap）
|
||||
2. 触发 `receive()` 回调
|
||||
3. 在回调中调用池的敏感函数（添加流动性/移除流动性）
|
||||
4. 由于重入锁失效，攻击者可以在单笔交易内重复执行操作
|
||||
5. 操纵池子的虚拟价格后执行大额提款，获取超额资产
|
||||
|
||||
CRV 池的流动性枯竭（攻击者大量提取 CRV）导致 Curve 创始人 Michael Egorov 的健康仓位差点被清算，引发 CRV 价格闪崩。
|
||||
|
||||
## 关键教训
|
||||
- **编译器不等于安全**：开发者通常信任编译器后端，但 Vyper 0.3.0 的 bug 打破了这一假设
|
||||
- **语言级安全机制不可信**：即使合约使用了 `nonreentrant` 修饰符，编译器实现 bug 可使其完全失效
|
||||
- **多池风险传染**：Curve 的池共享相同的合约模板，一个漏洞影响多条链上的多个池
|
||||
- **DeFi 可组合性放大风险**：CRV 池的风险传导至借贷协议（Aave），引发连环清算风险
|
||||
|
||||
## 关联漏洞类型
|
||||
- [[Reentrancy]] — 核心漏洞类型，虽然是编译器 bug 导致，但最终表现为重入攻击
|
||||
- AMM Invariant Violation（AMM 不变量破坏）：攻击者在交易中操纵价格
|
||||
|
||||
## 关联页面
|
||||
- [[blockchain-security-auditor]] — 区块链安全审计 Agent，将 Curve Finance 作为关键记忆模式收录于 Pattern Library
|
||||
- [[The-DAO-2016]] — 同为重入攻击案例，但前者是智能合约逻辑漏洞，后者是编译器 bug
|
||||
---
|
||||
title: "Curve Finance"
|
||||
type: entity
|
||||
tags: [blockchain, defi, amm, exploit, compiler-bug]
|
||||
sources: [blockchain-security-auditor]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **时间**：2023 年 7 月 30 日
|
||||
- **平台**：Ethereum（多链，影响 ETH、ARB、CRV、MSRP 等池）
|
||||
- **损失**：超过 7,000 万美元
|
||||
- **根本原因**：Vyper 0.3.0 编译器的重入锁（Reentrancy Guard）实现 bug
|
||||
- **特点**：这是 DeFi 历史上罕见的**编译器 bug 导致的安全事件**，而非业务逻辑漏洞
|
||||
|
||||
## 攻击原理
|
||||
|
||||
Curve Finance 使用 Vyper 语言编写合约，Vyper 0.3.0 的 `nonreentrant` 修饰符存在 bug：当合约存在多个相同名称的回调函数（如 `receive()` 和 `fallback()`）时，重入锁未能正确生效。
|
||||
|
||||
攻击者利用此漏洞对多个 Curve 池发起攻击：
|
||||
1. 在 AMM 池中进行兑换（swap）
|
||||
2. 触发 `receive()` 回调
|
||||
3. 在回调中调用池的敏感函数（添加流动性/移除流动性）
|
||||
4. 由于重入锁失效，攻击者可以在单笔交易内重复执行操作
|
||||
5. 操纵池子的虚拟价格后执行大额提款，获取超额资产
|
||||
|
||||
CRV 池的流动性枯竭（攻击者大量提取 CRV）导致 Curve 创始人 Michael Egorov 的健康仓位差点被清算，引发 CRV 价格闪崩。
|
||||
|
||||
## 关键教训
|
||||
- **编译器不等于安全**：开发者通常信任编译器后端，但 Vyper 0.3.0 的 bug 打破了这一假设
|
||||
- **语言级安全机制不可信**：即使合约使用了 `nonreentrant` 修饰符，编译器实现 bug 可使其完全失效
|
||||
- **多池风险传染**：Curve 的池共享相同的合约模板，一个漏洞影响多条链上的多个池
|
||||
- **DeFi 可组合性放大风险**：CRV 池的风险传导至借贷协议（Aave），引发连环清算风险
|
||||
|
||||
## 关联漏洞类型
|
||||
- [[Reentrancy]] — 核心漏洞类型，虽然是编译器 bug 导致，但最终表现为重入攻击
|
||||
- AMM Invariant Violation（AMM 不变量破坏）：攻击者在交易中操纵价格
|
||||
|
||||
## 关联页面
|
||||
- [[blockchain-security-auditor]] — 区块链安全审计 Agent，将 Curve Finance 作为关键记忆模式收录于 Pattern Library
|
||||
- [[The-DAO-2016]] — 同为重入攻击案例，但前者是智能合约逻辑漏洞，后者是编译器 bug
|
||||
|
||||
@@ -1,23 +1,23 @@
|
||||
# DORA Metrics
|
||||
|
||||
## Source
|
||||
- [[sources/cloud-devop-maturity-guideline.md]]
|
||||
|
||||
## Summary
|
||||
The DORA (DevOps Research and Assessment) metrics are four key measures used to assess DevOps performance and maturity:
|
||||
|
||||
1. **Deployment Frequency** — How often code is deployed to production
|
||||
2. **Lead Time for Changes** — Time from code commit to production deployment
|
||||
3. **Change Failure Rate** — Percentage of deployments causing failures
|
||||
4. **Mean Time to Recovery (MTTR)** — Time to restore service after failures
|
||||
|
||||
## Related Sources
|
||||
- [[sources/cloud-devop-maturity-guideline.md]]
|
||||
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
|
||||
|
||||
## Related Concepts
|
||||
- [[concepts/DevOps-Maturity]]
|
||||
- [[concepts/CI-CD-Pipeline]]
|
||||
|
||||
## Ingested
|
||||
- Date: 2026-04-21
|
||||
# DORA Metrics
|
||||
|
||||
## Source
|
||||
- [[sources/cloud-devop-maturity-guideline.md]]
|
||||
|
||||
## Summary
|
||||
The DORA (DevOps Research and Assessment) metrics are four key measures used to assess DevOps performance and maturity:
|
||||
|
||||
1. **Deployment Frequency** — How often code is deployed to production
|
||||
2. **Lead Time for Changes** — Time from code commit to production deployment
|
||||
3. **Change Failure Rate** — Percentage of deployments causing failures
|
||||
4. **Mean Time to Recovery (MTTR)** — Time to restore service after failures
|
||||
|
||||
## Related Sources
|
||||
- [[sources/cloud-devop-maturity-guideline.md]]
|
||||
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
|
||||
|
||||
## Related Concepts
|
||||
- [[concepts/DevOps-Maturity]]
|
||||
- [[concepts/CI-CD-Pipeline]]
|
||||
|
||||
## Ingested
|
||||
- Date: 2026-04-21
|
||||
|
||||
@@ -1,32 +1,32 @@
|
||||
---
|
||||
title: "DXC VSM"
|
||||
type: entity
|
||||
tags:
|
||||
- Identity-Governance
|
||||
- IAM
|
||||
- CTP
|
||||
sources:
|
||||
- learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re
|
||||
last_updated: 2023-11-28
|
||||
---
|
||||
|
||||
## DXC VSM
|
||||
|
||||
DXC Virtual SM（VSM）是一款 DXC 提供的身份治理工具，将被 Micro Focus IGA 替换。
|
||||
|
||||
## Description
|
||||
|
||||
DXC Virtual SM（VSM）是 DXC Technology 提供的虚拟服务管理（Virtual Service Management）工具，用于身份治理场景。VSM 在 Micro Focus 环境中原用于管理 AD 组和工作流，提供权限审批和访问审计能力。
|
||||
|
||||
## Replacement Plan
|
||||
|
||||
VSM 将被 Micro Focus IGA 全面替换：
|
||||
- **替换策略**：保持原有架构不变，IGA 接入 Coptum 域而非原 DXC 域
|
||||
- **验证阶段**：POC（概念验证）正在进行，以验证替换架构和审批流程
|
||||
- **目标**：实现无缝过渡，确保权限治理能力不中断
|
||||
|
||||
## Aliases
|
||||
- VSM
|
||||
- Virtual SM
|
||||
- DXC Virtual Service Management
|
||||
- DXC Virtual Service Manager
|
||||
---
|
||||
title: "DXC VSM"
|
||||
type: entity
|
||||
tags:
|
||||
- Identity-Governance
|
||||
- IAM
|
||||
- CTP
|
||||
sources:
|
||||
- learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re
|
||||
last_updated: 2023-11-28
|
||||
---
|
||||
|
||||
## DXC VSM
|
||||
|
||||
DXC Virtual SM（VSM）是一款 DXC 提供的身份治理工具，将被 Micro Focus IGA 替换。
|
||||
|
||||
## Description
|
||||
|
||||
DXC Virtual SM（VSM）是 DXC Technology 提供的虚拟服务管理（Virtual Service Management）工具，用于身份治理场景。VSM 在 Micro Focus 环境中原用于管理 AD 组和工作流，提供权限审批和访问审计能力。
|
||||
|
||||
## Replacement Plan
|
||||
|
||||
VSM 将被 Micro Focus IGA 全面替换：
|
||||
- **替换策略**：保持原有架构不变，IGA 接入 Coptum 域而非原 DXC 域
|
||||
- **验证阶段**：POC（概念验证）正在进行，以验证替换架构和审批流程
|
||||
- **目标**：实现无缝过渡，确保权限治理能力不中断
|
||||
|
||||
## Aliases
|
||||
- VSM
|
||||
- Virtual SM
|
||||
- DXC Virtual Service Management
|
||||
- DXC Virtual Service Manager
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
---
|
||||
title: "DXY（丁香园）"
|
||||
type: entity
|
||||
tags: [platform, healthcare, china]
|
||||
sources: [healthcare-marketing-compliance]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
丁香园（Dingxiang Yuan / DXY），中国最大的医师专业社区平台，同时运营丁香医生（面向大众的健康科普平台）和丁香通（医药企业营销平台）。在医疗营销合规中承担医师认证体系建设和健康科普内容专业审核职能。
|
||||
|
||||
## Key Roles
|
||||
- **互联网医疗平台合规**：医师入驻资质审核（须提交医师资格证+执业证）、患者评价管理、图文/视频问诊标准
|
||||
- **健康科普内容专业审核**：健康教育内容须基于循证医学，引用文献须注明来源
|
||||
- **商业合作与编辑独立性分离**：商业合作内容须标注，编辑内容须保持独立性
|
||||
- **保健食品合规内容平台**：在健康内容中不得嵌入产品推广
|
||||
|
||||
## Role in Healthcare Marketing Compliance
|
||||
- 健康教育内容与广告边界——不得在科普文章中嵌入产品推广
|
||||
- 医师个人品牌合规——医师须以真实身份出现，展示医师资格证和执业证
|
||||
- 商业合作内容须标注"广告"或"推广"标签
|
||||
|
||||
## Aliases
|
||||
- 丁香园
|
||||
- Dingxiang Yuan
|
||||
- Dingxiang Doctor
|
||||
- 丁香医生
|
||||
- 丁香通
|
||||
---
|
||||
title: "DXY（丁香园）"
|
||||
type: entity
|
||||
tags: [platform, healthcare, china]
|
||||
sources: [healthcare-marketing-compliance]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
丁香园（Dingxiang Yuan / DXY），中国最大的医师专业社区平台，同时运营丁香医生（面向大众的健康科普平台）和丁香通（医药企业营销平台）。在医疗营销合规中承担医师认证体系建设和健康科普内容专业审核职能。
|
||||
|
||||
## Key Roles
|
||||
- **互联网医疗平台合规**：医师入驻资质审核（须提交医师资格证+执业证）、患者评价管理、图文/视频问诊标准
|
||||
- **健康科普内容专业审核**：健康教育内容须基于循证医学，引用文献须注明来源
|
||||
- **商业合作与编辑独立性分离**：商业合作内容须标注，编辑内容须保持独立性
|
||||
- **保健食品合规内容平台**：在健康内容中不得嵌入产品推广
|
||||
|
||||
## Role in Healthcare Marketing Compliance
|
||||
- 健康教育内容与广告边界——不得在科普文章中嵌入产品推广
|
||||
- 医师个人品牌合规——医师须以真实身份出现，展示医师资格证和执业证
|
||||
- 商业合作内容须标注"广告"或"推广"标签
|
||||
|
||||
## Aliases
|
||||
- 丁香园
|
||||
- Dingxiang Yuan
|
||||
- Dingxiang Doctor
|
||||
- 丁香医生
|
||||
- 丁香通
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
---
|
||||
title: "DanielStefanovic"
|
||||
type: entity
|
||||
tags: [individual, github, build-your-own-x]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- danistefanovic
|
||||
|
||||
## Definition
|
||||
Daniel Stefanovic 是 GitHub 用户 danistefanovic，build-your-own-x 项目的原始创建者。该项目后来由 [[CodeCrafters]] 接手维护和发展。
|
||||
|
||||
## Details
|
||||
- **GitHub**: github.com/danistefanovic
|
||||
- **Known for**: 创建 build-your-own-x GitHub 仓库，该仓库成为程序员学习"从零重建技术"的标杆资源
|
||||
- **Current**: 项目已转由 CodeCrafters 团队维护
|
||||
|
||||
## Connections
|
||||
- [[DanielStefanovic]] ← created ← [[Build-Your-Own-X]]
|
||||
- [[DanielStefanovic]] ← succeeded_by ← [[CodeCrafters]]
|
||||
---
|
||||
title: "DanielStefanovic"
|
||||
type: entity
|
||||
tags: [individual, github, build-your-own-x]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- danistefanovic
|
||||
|
||||
## Definition
|
||||
Daniel Stefanovic 是 GitHub 用户 danistefanovic，build-your-own-x 项目的原始创建者。该项目后来由 [[CodeCrafters]] 接手维护和发展。
|
||||
|
||||
## Details
|
||||
- **GitHub**: github.com/danistefanovic
|
||||
- **Known for**: 创建 build-your-own-x GitHub 仓库，该仓库成为程序员学习"从零重建技术"的标杆资源
|
||||
- **Current**: 项目已转由 CodeCrafters 团队维护
|
||||
|
||||
## Connections
|
||||
- [[DanielStefanovic]] ← created ← [[Build-Your-Own-X]]
|
||||
- [[DanielStefanovic]] ← succeeded_by ← [[CodeCrafters]]
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
---
|
||||
title: "DeepLearning.AI"
|
||||
type: entity
|
||||
tags:
|
||||
- "AI教育"
|
||||
- "深度学习"
|
||||
- "吴恩达"
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
DeepLearning.AI 是由 Andrew Ng（吴恩达）创立的在线教育平台，专注于提供高质量的深度学习和机器学习课程。该平台与 [[Hugging Face]] 等开源 AI 社区紧密合作，共同推动 AI 教育的普及。
|
||||
|
||||
## Resources
|
||||
|
||||
- 官方网站：https://deeplearning.ai
|
||||
- [[learn-ai-for-free-directly-from-top-companies]] 中收录，提供免费 AI 学习课程
|
||||
|
||||
## Aliases
|
||||
- DeepLearning.AI
|
||||
- deeplearning.ai
|
||||
---
|
||||
title: "DeepLearning.AI"
|
||||
type: entity
|
||||
tags:
|
||||
- "AI教育"
|
||||
- "深度学习"
|
||||
- "吴恩达"
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
DeepLearning.AI 是由 Andrew Ng（吴恩达）创立的在线教育平台，专注于提供高质量的深度学习和机器学习课程。该平台与 [[Hugging Face]] 等开源 AI 社区紧密合作，共同推动 AI 教育的普及。
|
||||
|
||||
## Resources
|
||||
|
||||
- 官方网站：https://deeplearning.ai
|
||||
- [[learn-ai-for-free-directly-from-top-companies]] 中收录，提供免费 AI 学习课程
|
||||
|
||||
## Aliases
|
||||
- DeepLearning.AI
|
||||
- deeplearning.ai
|
||||
|
||||
@@ -1,27 +1,27 @@
|
||||
---
|
||||
title: "DeepSeek"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Overview
|
||||
DeepSeek 是一家专注于通用人工智能（AGI）的中国科技公司，以开源推理模型 DeepSeek-R1 闻名。
|
||||
|
||||
## Aliases
|
||||
- DeepSeek AI
|
||||
- 深度求索
|
||||
|
||||
## Key Products
|
||||
- **DeepSeek-R1**：开源推理模型，以处理复杂任务见长，在国际 AI 领域备受瞩目。2025 年春节爆火，拉开了中国通过开源策略与国外 AI 巨头差异化竞争的叙事
|
||||
- **DeepSeek-R3**：(来自 [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]）
|
||||
- **DeepSeek-V3**：（同上）
|
||||
|
||||
## Key People
|
||||
- [[余梦珑]]：DeepSeek 使用手册合作作者
|
||||
|
||||
## Key Events
|
||||
- 2025年：发布 DeepSeek-R1 推理模型，震惊全球 AI 界
|
||||
- 2025年2月：与清华大学合作发布《DeepSeek从入门到精通2025》官方使用手册
|
||||
|
||||
## Sources
|
||||
- [[清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）]]
|
||||
---
|
||||
title: "DeepSeek"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Overview
|
||||
DeepSeek 是一家专注于通用人工智能（AGI）的中国科技公司，以开源推理模型 DeepSeek-R1 闻名。
|
||||
|
||||
## Aliases
|
||||
- DeepSeek AI
|
||||
- 深度求索
|
||||
|
||||
## Key Products
|
||||
- **DeepSeek-R1**：开源推理模型，以处理复杂任务见长，在国际 AI 领域备受瞩目。2025 年春节爆火，拉开了中国通过开源策略与国外 AI 巨头差异化竞争的叙事
|
||||
- **DeepSeek-R3**：(来自 [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]）
|
||||
- **DeepSeek-V3**：（同上）
|
||||
|
||||
## Key People
|
||||
- [[余梦珑]]：DeepSeek 使用手册合作作者
|
||||
|
||||
## Key Events
|
||||
- 2025年：发布 DeepSeek-R1 推理模型，震惊全球 AI 界
|
||||
- 2025年2月：与清华大学合作发布《DeepSeek从入门到精通2025》官方使用手册
|
||||
|
||||
## Sources
|
||||
- [[清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）]]
|
||||
|
||||
@@ -1,36 +1,36 @@
|
||||
---
|
||||
title: "DeepSider"
|
||||
type: entity
|
||||
tags: [AI工具, 浏览器插件, Gemini, Claude, GPT]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- DeepSider
|
||||
- deepsider.ai
|
||||
|
||||
## Overview
|
||||
DeepSider 是一款 Edge 浏览器插件（deepsider.ai），国内用户可通过该插件直接访问 Nano Banana 2、Gemini 3.0、GPT-5.1 等数十款 AI 大模型，无需特殊网络环境，无需海外账户。
|
||||
|
||||
## Key Facts
|
||||
- **类型**：浏览器扩展插件（Edge）
|
||||
- **官网**：https://deepsider.ai
|
||||
- **适用平台**：Edge 浏览器
|
||||
- **中文支持**：专为中文用户设计
|
||||
- **网络要求**：无需特殊网络，无需 VPN
|
||||
|
||||
## Supported Models
|
||||
- GPT5、GPT4.1 全系列（包括 GPT-4o 绘图、GPT5-Codex）
|
||||
- Claude 全系列（包括 Claude Opus）
|
||||
- Gemini 2.5 Pro 全系列
|
||||
- Grok 全系列
|
||||
- Nano Banana（包括高清图片生成模式）
|
||||
- Sora 2（包括最长 25 秒视频生成模式）
|
||||
|
||||
## Usage
|
||||
1. 打开 Edge 浏览器，打开扩展商店
|
||||
2. 搜索 **deepsider**，安装插件到浏览器
|
||||
3. 打开 DeepSider 侧边栏，切换到所需模型
|
||||
|
||||
## Source
|
||||
- [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]
|
||||
---
|
||||
title: "DeepSider"
|
||||
type: entity
|
||||
tags: [AI工具, 浏览器插件, Gemini, Claude, GPT]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- DeepSider
|
||||
- deepsider.ai
|
||||
|
||||
## Overview
|
||||
DeepSider 是一款 Edge 浏览器插件（deepsider.ai），国内用户可通过该插件直接访问 Nano Banana 2、Gemini 3.0、GPT-5.1 等数十款 AI 大模型，无需特殊网络环境，无需海外账户。
|
||||
|
||||
## Key Facts
|
||||
- **类型**：浏览器扩展插件（Edge）
|
||||
- **官网**：https://deepsider.ai
|
||||
- **适用平台**：Edge 浏览器
|
||||
- **中文支持**：专为中文用户设计
|
||||
- **网络要求**：无需特殊网络，无需 VPN
|
||||
|
||||
## Supported Models
|
||||
- GPT5、GPT4.1 全系列（包括 GPT-4o 绘图、GPT5-Codex）
|
||||
- Claude 全系列（包括 Claude Opus）
|
||||
- Gemini 2.5 Pro 全系列
|
||||
- Grok 全系列
|
||||
- Nano Banana（包括高清图片生成模式）
|
||||
- Sora 2（包括最长 25 秒视频生成模式）
|
||||
|
||||
## Usage
|
||||
1. 打开 Edge 浏览器，打开扩展商店
|
||||
2. 搜索 **deepsider**，安装插件到浏览器
|
||||
3. 打开 DeepSider 侧边栏，切换到所需模型
|
||||
|
||||
## Source
|
||||
- [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]]
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "DenchClaw"
|
||||
type: entity
|
||||
tags: ["openclaw", "crm", "product", "automation"]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
MIT 许可证开源框架，通过 `npx denchclaw` 一键将 [[OpenClaw]] 转化为完整的本地 CRM、销售自动化和生产力平台。
|
||||
|
||||
## Aliases
|
||||
- Dench Claw
|
||||
- DenchClaw
|
||||
|
||||
## Details
|
||||
- **官网**: https://denchclaw.com
|
||||
- **GitHub**: https://github.com/DenchHQ/DenchClaw
|
||||
- **许可证**: MIT
|
||||
- **Discord 社区**: https://discord.gg/PDFXNVQj9n
|
||||
|
||||
## Key Features
|
||||
1. **One-command setup**: 自动安装 DuckDB、Web UI、OpenClaw Profile、Gateway、浏览器自动化和 Skills
|
||||
2. **Natural language CRM**: 自然语言查询实时更新视图，无需手动过滤器
|
||||
3. **Chrome profile cloning**: 复制浏览器认证状态，Agent 可直接操作用户已登录的 Web 应用
|
||||
4. **Multiple views**: Table、Kanban、Calendar、Timeline、Gallery、List 视图
|
||||
5. **App builder**: OpenClaw 构建自包含 Web 应用，运行在 workspace 内并访问数据库
|
||||
6. **File-system-first**: 所有设置/视图以 YAML/Markdown 文件存储，Agent 可直接读写
|
||||
|
||||
## Architecture
|
||||
- **Database**: [[DuckDB]] — 嵌入式分析型数据库
|
||||
- **Agent Engine**: [[OpenClaw]]
|
||||
- **Web UI**: localhost:3100
|
||||
- **Gateway**: port 19001
|
||||
|
||||
## Bundled Skills
|
||||
- **CRM Skill**: DuckDB 后端结构化数据管理（对象/字段/条目/多视图）
|
||||
- **App Builder Skill**: 构建运行在 workspace 内、访问数据库的 Web 应用
|
||||
- **Browser Automation Skill**: Chromium 浏览器，继承用户 Chrome 认证状态
|
||||
|
||||
## Key Insight
|
||||
> "File-system = agent-native UI: Because every setting, filter, and view is stored as a YAML/markdown file, OpenClaw can modify the UI as naturally as it edits code. No API wrappers needed."
|
||||
|
||||
## Related
|
||||
- [[OpenClaw]] — 底层 Agent 引擎
|
||||
- [[DuckDB]] — 数据存储
|
||||
- [[Chrome Profile Cloning]] — 浏览器自动化机制
|
||||
- [[File-System-First-UI]] — 设计哲学
|
||||
---
|
||||
title: "DenchClaw"
|
||||
type: entity
|
||||
tags: ["openclaw", "crm", "product", "automation"]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Overview
|
||||
MIT 许可证开源框架，通过 `npx denchclaw` 一键将 [[OpenClaw]] 转化为完整的本地 CRM、销售自动化和生产力平台。
|
||||
|
||||
## Aliases
|
||||
- Dench Claw
|
||||
- DenchClaw
|
||||
|
||||
## Details
|
||||
- **官网**: https://denchclaw.com
|
||||
- **GitHub**: https://github.com/DenchHQ/DenchClaw
|
||||
- **许可证**: MIT
|
||||
- **Discord 社区**: https://discord.gg/PDFXNVQj9n
|
||||
|
||||
## Key Features
|
||||
1. **One-command setup**: 自动安装 DuckDB、Web UI、OpenClaw Profile、Gateway、浏览器自动化和 Skills
|
||||
2. **Natural language CRM**: 自然语言查询实时更新视图，无需手动过滤器
|
||||
3. **Chrome profile cloning**: 复制浏览器认证状态，Agent 可直接操作用户已登录的 Web 应用
|
||||
4. **Multiple views**: Table、Kanban、Calendar、Timeline、Gallery、List 视图
|
||||
5. **App builder**: OpenClaw 构建自包含 Web 应用，运行在 workspace 内并访问数据库
|
||||
6. **File-system-first**: 所有设置/视图以 YAML/Markdown 文件存储，Agent 可直接读写
|
||||
|
||||
## Architecture
|
||||
- **Database**: [[DuckDB]] — 嵌入式分析型数据库
|
||||
- **Agent Engine**: [[OpenClaw]]
|
||||
- **Web UI**: localhost:3100
|
||||
- **Gateway**: port 19001
|
||||
|
||||
## Bundled Skills
|
||||
- **CRM Skill**: DuckDB 后端结构化数据管理（对象/字段/条目/多视图）
|
||||
- **App Builder Skill**: 构建运行在 workspace 内、访问数据库的 Web 应用
|
||||
- **Browser Automation Skill**: Chromium 浏览器，继承用户 Chrome 认证状态
|
||||
|
||||
## Key Insight
|
||||
> "File-system = agent-native UI: Because every setting, filter, and view is stored as a YAML/markdown file, OpenClaw can modify the UI as naturally as it edits code. No API wrappers needed."
|
||||
|
||||
## Related
|
||||
- [[OpenClaw]] — 底层 Agent 引擎
|
||||
- [[DuckDB]] — 数据存储
|
||||
- [[Chrome Profile Cloning]] — 浏览器自动化机制
|
||||
- [[File-System-First-UI]] — 设计哲学
|
||||
|
||||
@@ -1,60 +1,60 @@
|
||||
# DevOps Maturity Model
|
||||
|
||||
## Source
|
||||
- [[sources/cloud-devop-maturity-guideline.md]]
|
||||
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
A framework for evaluating an organization's progress in adopting DevOps practices, typically ranging from ad-hoc processes to highly optimized and automated environments. The model defines **five maturity stages**:
|
||||
|
||||
| Stage | Name | Key Characteristics |
|
||||
|-------|------|---------------------|
|
||||
| Phase 1 | Initial/Ad-Hoc | Siloed teams, waterfall approach, manual infrastructure, reactive monitoring, security only at release |
|
||||
| Phase 2 | DevOps in Pockets | Small cross-functional teams, Agile introduction, version control, superficial automation, unit/integration testing |
|
||||
| Phase 3 | Automated and Defined | Standardized processes, most infrastructure automated, security integrated into development process |
|
||||
| Phase 4 | Highly Optimized | CI pipeline, immutable infrastructure, MVP and tech debt management, continuous security monitoring |
|
||||
| Phase 5 | Fully Mature | Self-sufficient full-stack teams, multiple daily deployments, zero human intervention in pipeline |
|
||||
|
||||
## Key Focus Areas
|
||||
|
||||
1. **Culture and Strategy** — Teamwork, transparency, customer-centric mindset
|
||||
2. **Automation** — AutoDevOps for continuous delivery and deployment
|
||||
3. **Structure and Process** — Standardized, small-batch, transparent processes
|
||||
4. **Collaboration and Sharing** — Cohesive teams leveraging diverse skill sets
|
||||
5. **Technology** — Tool selection aligned with team needs
|
||||
|
||||
## Quality Criteria
|
||||
|
||||
- Assessment criteria (standards for evaluating maturity)
|
||||
- Five maturity levels
|
||||
- Core DevOps practices (release management, CI/CD, IaC, security)
|
||||
- Relevant metrics (deployment frequency, MTTR, change failure rate)
|
||||
- Cultural guides
|
||||
- Tools and technologies
|
||||
- Roles and responsibilities
|
||||
|
||||
## Business Benefits
|
||||
|
||||
- Quicker adjustment to market changes
|
||||
- Capability to seize new opportunities
|
||||
- Better scalability via IaC
|
||||
- Enhanced operational performance
|
||||
- Faster delivery times
|
||||
- Improved quality via continuous monitoring and feedback
|
||||
|
||||
## Security Integration (DevSecOps)
|
||||
|
||||
The model emphasizes merging development, operations, and security into a unified process. Security progression: ad-hoc compliance scans → separate security team → security in design/architecture discussions → security updates in product workflow → preventing non-compliant code from production.
|
||||
|
||||
## Related Concepts
|
||||
- [[concepts/DevOps-Maturity]]
|
||||
- [[concepts/DORA-Metrics]]
|
||||
- [[concepts/DevSecOps]]
|
||||
- [[concepts/CI-CD-Pipeline]]
|
||||
- [[concepts/Infrastructure-as-Code]]
|
||||
- [[concepts/Continuous-Deployment]]
|
||||
|
||||
## Ingested
|
||||
- Date: 2026-04-21 (initial)
|
||||
- Date: 2026-04-24 (updated with Phase 1-5 details)
|
||||
# DevOps Maturity Model
|
||||
|
||||
## Source
|
||||
- [[sources/cloud-devop-maturity-guideline.md]]
|
||||
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
A framework for evaluating an organization's progress in adopting DevOps practices, typically ranging from ad-hoc processes to highly optimized and automated environments. The model defines **five maturity stages**:
|
||||
|
||||
| Stage | Name | Key Characteristics |
|
||||
|-------|------|---------------------|
|
||||
| Phase 1 | Initial/Ad-Hoc | Siloed teams, waterfall approach, manual infrastructure, reactive monitoring, security only at release |
|
||||
| Phase 2 | DevOps in Pockets | Small cross-functional teams, Agile introduction, version control, superficial automation, unit/integration testing |
|
||||
| Phase 3 | Automated and Defined | Standardized processes, most infrastructure automated, security integrated into development process |
|
||||
| Phase 4 | Highly Optimized | CI pipeline, immutable infrastructure, MVP and tech debt management, continuous security monitoring |
|
||||
| Phase 5 | Fully Mature | Self-sufficient full-stack teams, multiple daily deployments, zero human intervention in pipeline |
|
||||
|
||||
## Key Focus Areas
|
||||
|
||||
1. **Culture and Strategy** — Teamwork, transparency, customer-centric mindset
|
||||
2. **Automation** — AutoDevOps for continuous delivery and deployment
|
||||
3. **Structure and Process** — Standardized, small-batch, transparent processes
|
||||
4. **Collaboration and Sharing** — Cohesive teams leveraging diverse skill sets
|
||||
5. **Technology** — Tool selection aligned with team needs
|
||||
|
||||
## Quality Criteria
|
||||
|
||||
- Assessment criteria (standards for evaluating maturity)
|
||||
- Five maturity levels
|
||||
- Core DevOps practices (release management, CI/CD, IaC, security)
|
||||
- Relevant metrics (deployment frequency, MTTR, change failure rate)
|
||||
- Cultural guides
|
||||
- Tools and technologies
|
||||
- Roles and responsibilities
|
||||
|
||||
## Business Benefits
|
||||
|
||||
- Quicker adjustment to market changes
|
||||
- Capability to seize new opportunities
|
||||
- Better scalability via IaC
|
||||
- Enhanced operational performance
|
||||
- Faster delivery times
|
||||
- Improved quality via continuous monitoring and feedback
|
||||
|
||||
## Security Integration (DevSecOps)
|
||||
|
||||
The model emphasizes merging development, operations, and security into a unified process. Security progression: ad-hoc compliance scans → separate security team → security in design/architecture discussions → security updates in product workflow → preventing non-compliant code from production.
|
||||
|
||||
## Related Concepts
|
||||
- [[concepts/DevOps-Maturity]]
|
||||
- [[concepts/DORA-Metrics]]
|
||||
- [[concepts/DevSecOps]]
|
||||
- [[concepts/CI-CD-Pipeline]]
|
||||
- [[concepts/Infrastructure-as-Code]]
|
||||
- [[concepts/Continuous-Deployment]]
|
||||
|
||||
## Ingested
|
||||
- Date: 2026-04-21 (initial)
|
||||
- Date: 2026-04-24 (updated with Phase 1-5 details)
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: "Dify"
|
||||
type: entity
|
||||
tags: [LLM应用, 开源, 工作流自动化, 知识库]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Definition
|
||||
**Dify** 是目前市面上最主流的 LLM 应用开发平台，专为企业和个人快速搭建带知识库的 AI 机器人设计。
|
||||
|
||||
## Key Characteristics
|
||||
- 将复杂的模型调试、提示词编排和工作流都做成可视化界面
|
||||
- 不懂后端代码也能像搭积木一样构建逻辑严密的智能体
|
||||
- 更像是成熟的 AI 后端中台，能将不稳定的模型变成稳定好用的服务
|
||||
- 支持知识库集成，可直接集成到产品或团队协作中
|
||||
|
||||
## GitHub
|
||||
- https://github.com/langgenius/dify
|
||||
|
||||
## Related
|
||||
- [[n8n]] — 同为工作流自动化平台，Dify 侧重 LLM 应用开发，n8n 侧重通用流程自动化
|
||||
|
||||
## Sources
|
||||
- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]
|
||||
---
|
||||
title: "Dify"
|
||||
type: entity
|
||||
tags: [LLM应用, 开源, 工作流自动化, 知识库]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Definition
|
||||
**Dify** 是目前市面上最主流的 LLM 应用开发平台，专为企业和个人快速搭建带知识库的 AI 机器人设计。
|
||||
|
||||
## Key Characteristics
|
||||
- 将复杂的模型调试、提示词编排和工作流都做成可视化界面
|
||||
- 不懂后端代码也能像搭积木一样构建逻辑严密的智能体
|
||||
- 更像是成熟的 AI 后端中台，能将不稳定的模型变成稳定好用的服务
|
||||
- 支持知识库集成，可直接集成到产品或团队协作中
|
||||
|
||||
## GitHub
|
||||
- https://github.com/langgenius/dify
|
||||
|
||||
## Related
|
||||
- [[n8n]] — 同为工作流自动化平台，Dify 侧重 LLM 应用开发，n8n 侧重通用流程自动化
|
||||
|
||||
## Sources
|
||||
- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]
|
||||
|
||||
@@ -1,30 +1,30 @@
|
||||
---
|
||||
title: "Docker Desktop"
|
||||
type: entity
|
||||
tags: [docker, container, desktop]
|
||||
sources: [n8n-configure-telegram-trigger]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Docker Desktop
|
||||
|
||||
## Overview
|
||||
Docker Desktop 是一款桌面级 Docker 容器运行环境，支持在 macOS、Windows 上运行 Docker 容器，内置 Kubernetes 支持。在 Docker Desktop 中可以通过图形界面或 `docker run` 命令配置容器环境变量。
|
||||
|
||||
## Key Capabilities
|
||||
- **图形化容器管理**：Docker Dashboard 管理运行中的容器、日志、文件
|
||||
- **环境变量配置**：通过 GUI 添加 `KEY=VALUE` 格式的环境变量
|
||||
- **端口映射**：容器端口与宿主机端口映射
|
||||
- **卷挂载**：宿主机目录与容器内目录挂载
|
||||
|
||||
## Docker Desktop 配置 n8n WEBHOOK_URL
|
||||
在 Docker Desktop 中为 n8n 容器添加环境变量：
|
||||
```
|
||||
WEBHOOK_URL=https://n8n.cpolar.top
|
||||
```
|
||||
此配置用于解决 n8n Telegram Trigger 的 "bad webhook: An HTTPS URL must be provided" 错误。
|
||||
|
||||
## Related Entities
|
||||
- [[n8n]] — 在 Docker Desktop 中运行的自动化工作流平台
|
||||
- [[Docker]] — Docker Desktop 的底层容器技术
|
||||
---
|
||||
title: "Docker Desktop"
|
||||
type: entity
|
||||
tags: [docker, container, desktop]
|
||||
sources: [n8n-configure-telegram-trigger]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Docker Desktop
|
||||
|
||||
## Overview
|
||||
Docker Desktop 是一款桌面级 Docker 容器运行环境，支持在 macOS、Windows 上运行 Docker 容器，内置 Kubernetes 支持。在 Docker Desktop 中可以通过图形界面或 `docker run` 命令配置容器环境变量。
|
||||
|
||||
## Key Capabilities
|
||||
- **图形化容器管理**：Docker Dashboard 管理运行中的容器、日志、文件
|
||||
- **环境变量配置**：通过 GUI 添加 `KEY=VALUE` 格式的环境变量
|
||||
- **端口映射**：容器端口与宿主机端口映射
|
||||
- **卷挂载**：宿主机目录与容器内目录挂载
|
||||
|
||||
## Docker Desktop 配置 n8n WEBHOOK_URL
|
||||
在 Docker Desktop 中为 n8n 容器添加环境变量：
|
||||
```
|
||||
WEBHOOK_URL=https://n8n.cpolar.top
|
||||
```
|
||||
此配置用于解决 n8n Telegram Trigger 的 "bad webhook: An HTTPS URL must be provided" 错误。
|
||||
|
||||
## Related Entities
|
||||
- [[n8n]] — 在 Docker Desktop 中运行的自动化工作流平台
|
||||
- [[Docker]] — Docker Desktop 的底层容器技术
|
||||
|
||||
@@ -1,88 +1,88 @@
|
||||
---
|
||||
title: "Docker Network"
|
||||
tags: [docker, networking, container]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
# Docker Network
|
||||
|
||||
## Definition
|
||||
Docker Network 是 Docker 提供的容器网络连接机制，支持多种网络驱动（bridge / host / overlay / macvlan / none），使容器能够相互通信并与外部网络交互。
|
||||
|
||||
## Network Drivers
|
||||
|
||||
| 驱动 | 用途 | 特点 |
|
||||
|------|------|------|
|
||||
| **bridge** | 默认网络驱动 | 容器通过虚拟网桥通信，默认 bridge IP 为 172.17.0.1 |
|
||||
| **host** | 移除网络隔离 | 容器直接使用宿主机网络栈 |
|
||||
| **overlay** | Docker Swarm 多主机通信 | 跨多个 Docker daemon |
|
||||
| **macvlan** | 给容器分配真实 MAC | 容器像物理机一样出现在网络中 |
|
||||
|
||||
## 查看与管理命令
|
||||
```bash
|
||||
# 查看所有网络
|
||||
docker network ls
|
||||
|
||||
# 查看特定网络的详细信息（驱动、容器、IP）
|
||||
docker network inspect bridge
|
||||
|
||||
# 查看连接了某网络的容器
|
||||
docker network inspect <network_name> --format '{{range .Containers}}{{.Name}} {{end}}'
|
||||
|
||||
# 创建自定义 bridge 网络
|
||||
docker network create --driver bridge my_network
|
||||
|
||||
# 删除网络
|
||||
docker network rm my_network
|
||||
|
||||
# 删除前先断开容器连接
|
||||
docker network disconnect my_network container_name
|
||||
```
|
||||
|
||||
## Docker Compose 中的 Network
|
||||
```yaml
|
||||
services:
|
||||
app:
|
||||
networks:
|
||||
- frontend
|
||||
- backend
|
||||
|
||||
networks:
|
||||
frontend:
|
||||
driver: bridge
|
||||
backend:
|
||||
driver: bridge
|
||||
```
|
||||
|
||||
## Compose 项目间命名冲突
|
||||
Docker Compose 默认以**项目目录名**作为网络名前缀：
|
||||
- 项目 A（目录 `~/portainer`）→ 网络名 `portainer_default`
|
||||
- 项目 B（目录 `~/portainer-stack`）→ 网络名 `portainer-stack_default`
|
||||
|
||||
当两个项目名不同但都声明了 `portainer_network` 时，会产生警告：
|
||||
> WARN: Network portainer_network declared as external, but it does not exist
|
||||
|
||||
**解决方案**：
|
||||
1. 删除旧网络：`docker network rm portainer_network`
|
||||
2. 或在 compose 中声明 `external: true` 复用已存在的网络
|
||||
|
||||
## External Mode（复用外部网络）
|
||||
```yaml
|
||||
networks:
|
||||
portainer_network:
|
||||
external: true
|
||||
```
|
||||
声明 `external: true` 后，Compose 不会尝试创建网络，而是直接使用已存在的同名网络。
|
||||
|
||||
## Related Concepts
|
||||
- [[Docker Compose]] — compose 中声明式定义网络
|
||||
- [[Docker堆栈]] — 堆栈中多服务共享网络
|
||||
- [[桥接网络]] — Docker bridge 网络驱动
|
||||
|
||||
## Related Entities
|
||||
- [[Portainer]] — Docker 可视化管理工具，提供网络管理 Web UI
|
||||
- [[群晖 NAS]] — Docker 网络配置的平台
|
||||
- [[Docker]] — 网络系统的底层平台
|
||||
|
||||
## See Also
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] — Prometheus 部署涉及 Docker 网络配置
|
||||
---
|
||||
title: "Docker Network"
|
||||
tags: [docker, networking, container]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
# Docker Network
|
||||
|
||||
## Definition
|
||||
Docker Network 是 Docker 提供的容器网络连接机制，支持多种网络驱动（bridge / host / overlay / macvlan / none），使容器能够相互通信并与外部网络交互。
|
||||
|
||||
## Network Drivers
|
||||
|
||||
| 驱动 | 用途 | 特点 |
|
||||
|------|------|------|
|
||||
| **bridge** | 默认网络驱动 | 容器通过虚拟网桥通信，默认 bridge IP 为 172.17.0.1 |
|
||||
| **host** | 移除网络隔离 | 容器直接使用宿主机网络栈 |
|
||||
| **overlay** | Docker Swarm 多主机通信 | 跨多个 Docker daemon |
|
||||
| **macvlan** | 给容器分配真实 MAC | 容器像物理机一样出现在网络中 |
|
||||
|
||||
## 查看与管理命令
|
||||
```bash
|
||||
# 查看所有网络
|
||||
docker network ls
|
||||
|
||||
# 查看特定网络的详细信息（驱动、容器、IP）
|
||||
docker network inspect bridge
|
||||
|
||||
# 查看连接了某网络的容器
|
||||
docker network inspect <network_name> --format '{{range .Containers}}{{.Name}} {{end}}'
|
||||
|
||||
# 创建自定义 bridge 网络
|
||||
docker network create --driver bridge my_network
|
||||
|
||||
# 删除网络
|
||||
docker network rm my_network
|
||||
|
||||
# 删除前先断开容器连接
|
||||
docker network disconnect my_network container_name
|
||||
```
|
||||
|
||||
## Docker Compose 中的 Network
|
||||
```yaml
|
||||
services:
|
||||
app:
|
||||
networks:
|
||||
- frontend
|
||||
- backend
|
||||
|
||||
networks:
|
||||
frontend:
|
||||
driver: bridge
|
||||
backend:
|
||||
driver: bridge
|
||||
```
|
||||
|
||||
## Compose 项目间命名冲突
|
||||
Docker Compose 默认以**项目目录名**作为网络名前缀：
|
||||
- 项目 A（目录 `~/portainer`）→ 网络名 `portainer_default`
|
||||
- 项目 B（目录 `~/portainer-stack`）→ 网络名 `portainer-stack_default`
|
||||
|
||||
当两个项目名不同但都声明了 `portainer_network` 时，会产生警告：
|
||||
> WARN: Network portainer_network declared as external, but it does not exist
|
||||
|
||||
**解决方案**：
|
||||
1. 删除旧网络：`docker network rm portainer_network`
|
||||
2. 或在 compose 中声明 `external: true` 复用已存在的网络
|
||||
|
||||
## External Mode（复用外部网络）
|
||||
```yaml
|
||||
networks:
|
||||
portainer_network:
|
||||
external: true
|
||||
```
|
||||
声明 `external: true` 后，Compose 不会尝试创建网络，而是直接使用已存在的同名网络。
|
||||
|
||||
## Related Concepts
|
||||
- [[Docker Compose]] — compose 中声明式定义网络
|
||||
- [[Docker堆栈]] — 堆栈中多服务共享网络
|
||||
- [[桥接网络]] — Docker bridge 网络驱动
|
||||
|
||||
## Related Entities
|
||||
- [[Portainer]] — Docker 可视化管理工具，提供网络管理 Web UI
|
||||
- [[群晖 NAS]] — Docker 网络配置的平台
|
||||
- [[Docker]] — 网络系统的底层平台
|
||||
|
||||
## See Also
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] — Prometheus 部署涉及 Docker 网络配置
|
||||
|
||||
@@ -1,75 +1,75 @@
|
||||
---
|
||||
title: "Docker卷"
|
||||
tags: [docker, storage, container]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Docker卷 (Docker Volume)
|
||||
|
||||
## Definition
|
||||
Docker 卷是 Docker 容器用于持久化数据的首选机制。与容器层不同，卷存储在宿主机文件系统上，由 Docker 管理，独立于容器的生命周期。
|
||||
|
||||
## Key Properties
|
||||
- **持久性**: 数据在容器删除后依然保留
|
||||
- **独立性**: 卷与容器文件系统隔离
|
||||
- **共享性**: 多个容器可挂载同一卷
|
||||
- **Host 管理**: Docker CLI 可直接管理卷
|
||||
|
||||
## Default Location
|
||||
Linux 系统中，Docker 卷默认存储在：
|
||||
```
|
||||
/var/lib/docker/volumes/
|
||||
```
|
||||
|
||||
## Docker卷备份策略
|
||||
|
||||
### Method 1: rsync 直接同步 (不推荐数据库)
|
||||
```bash
|
||||
rsync -azR --delete \
|
||||
/var/lib/docker/volumes/ \
|
||||
/mnt/nas_backup/docker_backups/
|
||||
```
|
||||
**⚠️ 警告**: 直接同步二进制数据库文件可能导致恢复后无法启动。
|
||||
|
||||
### Method 2: mysqldump + rsync (推荐用于数据库)
|
||||
```bash
|
||||
# 在容器中执行 mysqldump
|
||||
docker exec <mysql_container> mysqldump -u root -p --all-databases > dump.sql
|
||||
|
||||
# rsync 同步导出文件
|
||||
rsync -az /path/to/dump.sql /mnt/nas_backup/docker_backups/
|
||||
```
|
||||
|
||||
### Method 3: docker save / docker load
|
||||
```bash
|
||||
# 导出镜像
|
||||
docker save -o images.tar image_name:tag
|
||||
|
||||
# rsync 传输
|
||||
rsync -az images.tar user@nas:/backup/
|
||||
|
||||
# 导入镜像
|
||||
docker load < images.tar
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[增量备份]] — Docker 卷备份是增量备份策略的重要组成部分
|
||||
- [[Docker-Image]] — 镜像备份使用 docker save/load
|
||||
- [[Docker-Save]] — 镜像导出命令
|
||||
- [[Docker-Load]] — 镜像导入命令
|
||||
|
||||
## Related Entities
|
||||
- [[Navidrome]] — 音乐流媒体服务使用 Docker 卷存储音乐文件和数据库
|
||||
- [[群晖 NAS]] — 网络存储作为 Docker 卷备份的目标位置
|
||||
- [[Portainer]] — Docker 可视化管理工具，通过 Web UI 查看/管理卷；Portainer 重装前可通过 `docker volume ls | grep portainer` 查找 `portainer_data` 卷，删除前需确认是否需要保留数据
|
||||
|
||||
## Best Practices
|
||||
1. **数据库一致性**: 使用 mysqldump 而非直接复制
|
||||
2. **定期快照**: 结合 LVM/ZFS 快照实现应用一致性
|
||||
3. **增量同步**: rsync 仅传输变更的卷数据
|
||||
4. **备份验证**: 定期测试从备份恢复的可行性
|
||||
|
||||
## See Also
|
||||
- [[Disaster-Recovery]] — Docker 卷备份是灾备策略的核心
|
||||
- [[RTO]] — 恢复时间目标受备份策略影响
|
||||
- [[RPO]] — 恢复点目标由备份频率决定
|
||||
---
|
||||
title: "Docker卷"
|
||||
tags: [docker, storage, container]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Docker卷 (Docker Volume)
|
||||
|
||||
## Definition
|
||||
Docker 卷是 Docker 容器用于持久化数据的首选机制。与容器层不同，卷存储在宿主机文件系统上，由 Docker 管理，独立于容器的生命周期。
|
||||
|
||||
## Key Properties
|
||||
- **持久性**: 数据在容器删除后依然保留
|
||||
- **独立性**: 卷与容器文件系统隔离
|
||||
- **共享性**: 多个容器可挂载同一卷
|
||||
- **Host 管理**: Docker CLI 可直接管理卷
|
||||
|
||||
## Default Location
|
||||
Linux 系统中，Docker 卷默认存储在：
|
||||
```
|
||||
/var/lib/docker/volumes/
|
||||
```
|
||||
|
||||
## Docker卷备份策略
|
||||
|
||||
### Method 1: rsync 直接同步 (不推荐数据库)
|
||||
```bash
|
||||
rsync -azR --delete \
|
||||
/var/lib/docker/volumes/ \
|
||||
/mnt/nas_backup/docker_backups/
|
||||
```
|
||||
**⚠️ 警告**: 直接同步二进制数据库文件可能导致恢复后无法启动。
|
||||
|
||||
### Method 2: mysqldump + rsync (推荐用于数据库)
|
||||
```bash
|
||||
# 在容器中执行 mysqldump
|
||||
docker exec <mysql_container> mysqldump -u root -p --all-databases > dump.sql
|
||||
|
||||
# rsync 同步导出文件
|
||||
rsync -az /path/to/dump.sql /mnt/nas_backup/docker_backups/
|
||||
```
|
||||
|
||||
### Method 3: docker save / docker load
|
||||
```bash
|
||||
# 导出镜像
|
||||
docker save -o images.tar image_name:tag
|
||||
|
||||
# rsync 传输
|
||||
rsync -az images.tar user@nas:/backup/
|
||||
|
||||
# 导入镜像
|
||||
docker load < images.tar
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[增量备份]] — Docker 卷备份是增量备份策略的重要组成部分
|
||||
- [[Docker-Image]] — 镜像备份使用 docker save/load
|
||||
- [[Docker-Save]] — 镜像导出命令
|
||||
- [[Docker-Load]] — 镜像导入命令
|
||||
|
||||
## Related Entities
|
||||
- [[Navidrome]] — 音乐流媒体服务使用 Docker 卷存储音乐文件和数据库
|
||||
- [[群晖 NAS]] — 网络存储作为 Docker 卷备份的目标位置
|
||||
- [[Portainer]] — Docker 可视化管理工具，通过 Web UI 查看/管理卷；Portainer 重装前可通过 `docker volume ls | grep portainer` 查找 `portainer_data` 卷，删除前需确认是否需要保留数据
|
||||
|
||||
## Best Practices
|
||||
1. **数据库一致性**: 使用 mysqldump 而非直接复制
|
||||
2. **定期快照**: 结合 LVM/ZFS 快照实现应用一致性
|
||||
3. **增量同步**: rsync 仅传输变更的卷数据
|
||||
4. **备份验证**: 定期测试从备份恢复的可行性
|
||||
|
||||
## See Also
|
||||
- [[Disaster-Recovery]] — Docker 卷备份是灾备策略的核心
|
||||
- [[RTO]] — 恢复时间目标受备份策略影响
|
||||
- [[RPO]] — 恢复点目标由备份频率决定
|
||||
|
||||
@@ -1,53 +1,39 @@
|
||||
---
|
||||
title: "Douyin（抖音）"
|
||||
type: entity
|
||||
tags: [platform, healthcare, china, social-media]
|
||||
sources: [healthcare-marketing-compliance]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
抖音（Douyin），字节跳动旗下短视频平台，中国最大的短视频/直播平台之一。在医疗健康内容合规中具有特殊地位——医疗行业广告须满足行业准入标准，认证医师账号须遵守严格的直播和内容规则。
|
||||
|
||||
## Healthcare Industry Access Requirements
|
||||
- 须提交《医疗机构执业许可证》或药品/医疗器械资质文件进行行业认证
|
||||
- 认证后方可发布医疗健康相关内容和广告
|
||||
|
||||
## Content Review Rules
|
||||
- 禁止展示外科手术过程
|
||||
- 禁止使用患者推荐/见证疗效内容
|
||||
- 禁止展示处方药信息
|
||||
- 健康科普内容须经平台人工审核
|
||||
|
||||
## Physician Account Certification
|
||||
- 须提交医师资格证
|
||||
- 认证后获得"认证医师"标识
|
||||
- 认证医师可在合规范围内发布健康科普内容
|
||||
|
||||
## Livestream Restrictions
|
||||
- 医疗账号直播期间禁止推荐具体药品或治疗方案
|
||||
- 禁止进行在线诊断
|
||||
- 违反规定可能导致账号封禁或流量限制
|
||||
|
||||
## Advertising Placement
|
||||
- 医疗广告须经过行业资质审核
|
||||
- 创意内容须经平台人工审核
|
||||
|
||||
## Marketing & Short-Video Strategy
|
||||
- **推荐算法优先级**：完播率 > 点赞率 > 评论率 > 分享率
|
||||
- **黄金3秒原则**：前三秒决定视频生死，必须用冲突/悬念/价值钩子开场
|
||||
- **内容矩阵类型**：教育类、剧情类、产品测评类、Vlog类
|
||||
- **热门BGM**：每周追踪平台趋势热点
|
||||
- **限流红线**：视频内禁止引流外部平台
|
||||
|
||||
## Key Agents
|
||||
- [[MarketingDouyinStrategist]]：The Agency 抖音短视频营销与直播带货策略专家
|
||||
|
||||
## Connections
|
||||
- [[MarketingDouyinStrategist]] ← 核心 Agent ← [[MarketingShortVideoEditingCoach]]（内容剪辑支撑）
|
||||
- [[OceanEngine]] ← 广告投放平台 ← Douyin
|
||||
|
||||
## Aliases
|
||||
- 抖音
|
||||
- Douyin
|
||||
- TikTok China
|
||||
---
|
||||
title: "Douyin（抖音）"
|
||||
type: entity
|
||||
tags: [platform, healthcare, china, social-media]
|
||||
sources: [healthcare-marketing-compliance]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Overview
|
||||
抖音（Douyin），字节跳动旗下短视频平台，中国最大的短视频/直播平台之一。在医疗健康内容合规中具有特殊地位——医疗行业广告须满足行业准入标准，认证医师账号须遵守严格的直播和内容规则。
|
||||
|
||||
## Healthcare Industry Access Requirements
|
||||
- 须提交《医疗机构执业许可证》或药品/医疗器械资质文件进行行业认证
|
||||
- 认证后方可发布医疗健康相关内容和广告
|
||||
|
||||
## Content Review Rules
|
||||
- 禁止展示外科手术过程
|
||||
- 禁止使用患者推荐/见证疗效内容
|
||||
- 禁止展示处方药信息
|
||||
- 健康科普内容须经平台人工审核
|
||||
|
||||
## Physician Account Certification
|
||||
- 须提交医师资格证
|
||||
- 认证后获得"认证医师"标识
|
||||
- 认证医师可在合规范围内发布健康科普内容
|
||||
|
||||
## Livestream Restrictions
|
||||
- 医疗账号直播期间禁止推荐具体药品或治疗方案
|
||||
- 禁止进行在线诊断
|
||||
- 违反规定可能导致账号封禁或流量限制
|
||||
|
||||
## Advertising Placement
|
||||
- 医疗广告须经过行业资质审核
|
||||
- 创意内容须经平台人工审核
|
||||
|
||||
## Aliases
|
||||
- 抖音
|
||||
- Douyin
|
||||
- TikTok China
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: "DracoVibeCoding"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Overview
|
||||
公众号"Draco正在VibeCoding"作者，专注 Vibe Coding 与 AI Agent 实战分享，是 [[multi-source-tech-news-digest]] 等多个 OpenClaw Agent 自动化方案的提出者。
|
||||
|
||||
## Type
|
||||
人物 / 内容创作者
|
||||
|
||||
## Aliases
|
||||
- DracoVibeCoding
|
||||
|
||||
## Related Links
|
||||
- [[ClawHub]] — 作者方案的发布平台
|
||||
---
|
||||
title: "DracoVibeCoding"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Overview
|
||||
公众号"Draco正在VibeCoding"作者，专注 Vibe Coding 与 AI Agent 实战分享，是 [[multi-source-tech-news-digest]] 等多个 OpenClaw Agent 自动化方案的提出者。
|
||||
|
||||
## Type
|
||||
人物 / 内容创作者
|
||||
|
||||
## Aliases
|
||||
- DracoVibeCoding
|
||||
|
||||
## Related Links
|
||||
- [[ClawHub]] — 作者方案的发布平台
|
||||
|
||||
@@ -1,44 +1,44 @@
|
||||
---
|
||||
title: "EESJGong"
|
||||
type: entity
|
||||
tags: [obsidian, skills, academic]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Basic Info
|
||||
- **Role**: scholar-skill 作者
|
||||
- **GitHub**: `EESJGong/scholar-skill`
|
||||
|
||||
## Aliases
|
||||
- EESJGong
|
||||
|
||||
## Key Contributions
|
||||
开发了 **scholar-skill** — 基于 OpenClaw 框架的学术研究 Skill，通过 L1/L2/L3 分级阅读策略深度解构论文。
|
||||
|
||||
### 三级阅读体系
|
||||
| 级别 | 名称 | 说明 |
|
||||
|------|------|------|
|
||||
| L1 | 分发级 | 快速评估，优先级判定 |
|
||||
| L2 | 标准阅读 | 结构化笔记 + 双链卡片 |
|
||||
| L3 | 深度解构 | 完整论文分析，生成 MOC + 反思报告，最长 2.5 小时异步任务 |
|
||||
|
||||
### 依赖环境
|
||||
- 基础环境：Python + Obsidian 客户端
|
||||
- 核心框架：OpenClaw + OpenClaw Skill 体系
|
||||
- 必须依赖：`obsidian-direct`（暴力文件 I/O）、`arxiv-watcher`（ArXiv API）、`durable-task-runner`（长时间任务调度）
|
||||
- 可选依赖：`tavily`（联网抓取）、`pdf`（文本解析）
|
||||
|
||||
### 特殊机制
|
||||
- **超长周期任务编排**：L3 级深度阅读最长 2.5 小时，依赖 durable-task-runner 处理 API 限流和崩溃恢复
|
||||
- **周期性反思**：时间触发器在周末/月末强制 L2/L3 反思
|
||||
- **Human-in-the-loop**：发现新论文推翻旧笔记时，不直接覆写，生成确认单等待人工审核
|
||||
|
||||
### 风险预警
|
||||
⚠️ 财务风险：L3 循环和高频历史知识检索（RAG）消耗大量 Token，商用前沿模型可能带来高昂 API 账单
|
||||
⚠️ 数据覆写风险：`obsidian-direct` 使用暴力文件 I/O，在 iCloud/Obsidian Sync 多端同步期间易引发文件冲突，建议独立测试库 + Git 快照
|
||||
|
||||
## Connections
|
||||
- [[obsidian-必装-skills]] — 技能来源
|
||||
- [[Scholar-Skill]] — EESJGong 开发的 Skill
|
||||
- [[OpenClaw]] — scholar-skill 的运行基础框架
|
||||
- [[ClawHub]] — scholar-skill 的分发平台
|
||||
---
|
||||
title: "EESJGong"
|
||||
type: entity
|
||||
tags: [obsidian, skills, academic]
|
||||
last_updated: 2026-04-21
|
||||
---
|
||||
|
||||
## Basic Info
|
||||
- **Role**: scholar-skill 作者
|
||||
- **GitHub**: `EESJGong/scholar-skill`
|
||||
|
||||
## Aliases
|
||||
- EESJGong
|
||||
|
||||
## Key Contributions
|
||||
开发了 **scholar-skill** — 基于 OpenClaw 框架的学术研究 Skill，通过 L1/L2/L3 分级阅读策略深度解构论文。
|
||||
|
||||
### 三级阅读体系
|
||||
| 级别 | 名称 | 说明 |
|
||||
|------|------|------|
|
||||
| L1 | 分发级 | 快速评估，优先级判定 |
|
||||
| L2 | 标准阅读 | 结构化笔记 + 双链卡片 |
|
||||
| L3 | 深度解构 | 完整论文分析，生成 MOC + 反思报告，最长 2.5 小时异步任务 |
|
||||
|
||||
### 依赖环境
|
||||
- 基础环境：Python + Obsidian 客户端
|
||||
- 核心框架：OpenClaw + OpenClaw Skill 体系
|
||||
- 必须依赖：`obsidian-direct`（暴力文件 I/O）、`arxiv-watcher`（ArXiv API）、`durable-task-runner`（长时间任务调度）
|
||||
- 可选依赖：`tavily`（联网抓取）、`pdf`（文本解析）
|
||||
|
||||
### 特殊机制
|
||||
- **超长周期任务编排**：L3 级深度阅读最长 2.5 小时，依赖 durable-task-runner 处理 API 限流和崩溃恢复
|
||||
- **周期性反思**：时间触发器在周末/月末强制 L2/L3 反思
|
||||
- **Human-in-the-loop**：发现新论文推翻旧笔记时，不直接覆写，生成确认单等待人工审核
|
||||
|
||||
### 风险预警
|
||||
⚠️ 财务风险：L3 循环和高频历史知识检索（RAG）消耗大量 Token，商用前沿模型可能带来高昂 API 账单
|
||||
⚠️ 数据覆写风险：`obsidian-direct` 使用暴力文件 I/O，在 iCloud/Obsidian Sync 多端同步期间易引发文件冲突，建议独立测试库 + Git 快照
|
||||
|
||||
## Connections
|
||||
- [[obsidian-必装-skills]] — 技能来源
|
||||
- [[Scholar-Skill]] — EESJGong 开发的 Skill
|
||||
- [[OpenClaw]] — scholar-skill 的运行基础框架
|
||||
- [[ClawHub]] — scholar-skill 的分发平台
|
||||
|
||||
@@ -1,42 +1,42 @@
|
||||
---
|
||||
title: "Euler Finance"
|
||||
type: entity
|
||||
tags: [blockchain, defi, exploit, lending, eoa-donation]
|
||||
sources: [blockchain-security-auditor]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **时间**：2023 年 3 月 13 日
|
||||
- **平台**：Ethereum
|
||||
- **损失**：1.97 亿美元（Euler Finance 无辜用户存款几乎全损）
|
||||
- **根本原因**：donate-to-reserves 操纵攻击（Euler 白帽事后命名）
|
||||
- **攻击者**：关联 Lazarus Group（朝鲜黑客组织）
|
||||
- **白帽救援**：攻击者后归还全部资金（通过协商）
|
||||
|
||||
## 攻击原理
|
||||
|
||||
Euler Finance 的 `donateToReserves()` 函数允许任意用户将自己的 ETH 转入储备池。当攻击者先存款、后捐赠、后借款时，其健康因子（health factor）在 `eToken.balanceOf()` 更新前被错误计算，导致超额借款：
|
||||
|
||||
1. 攻击者存入 30 ETH（获得 30 eETH）
|
||||
2. 攻击者调用 `donateToReserves(30 ETH)`，将 30 eETH 转入储备
|
||||
3. 此时攻击者的真实余额（3000 ETH）远高于名义余额（0），但清算逻辑基于名义余额
|
||||
4. 攻击者以极低抵押率（10 倍杠杆）借入 10 倍存款规模的资产
|
||||
5. 抵押品价值下跌时，清算机器人按错误健康因子执行清算，攻击者获超额清算收益
|
||||
|
||||
关键漏洞：`donateToReserves()` 的实现没有考虑对内部 accounting 的影响，健康因子计算依赖于可被操纵的 `eToken.balanceOf()` 而非内部余额追踪。
|
||||
|
||||
## 关键教训
|
||||
- **不要相信任何"管理员"函数是安全的**：看似无害的 `donateToReserves()` 影响了整个清算引擎
|
||||
- **协议不变量必须考虑所有代码路径**：包括看似无害的辅助函数
|
||||
- **白帽救援**：最终攻击者归还资金（否则 1.97 亿无法追回），成为 DeFi 历史上最大白帽救援案例
|
||||
|
||||
## 关联漏洞类型
|
||||
- [[Flash-Loan-Attack]] — 攻击使用闪电贷提供初始资金
|
||||
- [[Oracle-Manipulation]] — 健康因子计算依赖可操纵的内部状态
|
||||
- 经济攻击（Economic Exploit）：利用 DeFi 协议的会计逻辑错误
|
||||
|
||||
## 关联页面
|
||||
- [[blockchain-security-auditor]] — 区块链安全审计 Agent，将 Euler Finance 作为关键记忆模式收录于 Exploit Pattern Library
|
||||
- [[The-DAO-2016]] — 同为 DeFi 安全史上的里程碑事件，但攻击类型不同
|
||||
- [[Curve-Finance]] — 2023 年另一大 DeFi 安全事件
|
||||
---
|
||||
title: "Euler Finance"
|
||||
type: entity
|
||||
tags: [blockchain, defi, exploit, lending, eoa-donation]
|
||||
sources: [blockchain-security-auditor]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **时间**：2023 年 3 月 13 日
|
||||
- **平台**：Ethereum
|
||||
- **损失**：1.97 亿美元（Euler Finance 无辜用户存款几乎全损）
|
||||
- **根本原因**：donate-to-reserves 操纵攻击（Euler 白帽事后命名）
|
||||
- **攻击者**：关联 Lazarus Group（朝鲜黑客组织）
|
||||
- **白帽救援**：攻击者后归还全部资金（通过协商）
|
||||
|
||||
## 攻击原理
|
||||
|
||||
Euler Finance 的 `donateToReserves()` 函数允许任意用户将自己的 ETH 转入储备池。当攻击者先存款、后捐赠、后借款时，其健康因子（health factor）在 `eToken.balanceOf()` 更新前被错误计算，导致超额借款：
|
||||
|
||||
1. 攻击者存入 30 ETH（获得 30 eETH）
|
||||
2. 攻击者调用 `donateToReserves(30 ETH)`，将 30 eETH 转入储备
|
||||
3. 此时攻击者的真实余额（3000 ETH）远高于名义余额（0），但清算逻辑基于名义余额
|
||||
4. 攻击者以极低抵押率（10 倍杠杆）借入 10 倍存款规模的资产
|
||||
5. 抵押品价值下跌时，清算机器人按错误健康因子执行清算，攻击者获超额清算收益
|
||||
|
||||
关键漏洞：`donateToReserves()` 的实现没有考虑对内部 accounting 的影响，健康因子计算依赖于可被操纵的 `eToken.balanceOf()` 而非内部余额追踪。
|
||||
|
||||
## 关键教训
|
||||
- **不要相信任何"管理员"函数是安全的**：看似无害的 `donateToReserves()` 影响了整个清算引擎
|
||||
- **协议不变量必须考虑所有代码路径**：包括看似无害的辅助函数
|
||||
- **白帽救援**：最终攻击者归还资金（否则 1.97 亿无法追回），成为 DeFi 历史上最大白帽救援案例
|
||||
|
||||
## 关联漏洞类型
|
||||
- [[Flash-Loan-Attack]] — 攻击使用闪电贷提供初始资金
|
||||
- [[Oracle-Manipulation]] — 健康因子计算依赖可操纵的内部状态
|
||||
- 经济攻击（Economic Exploit）：利用 DeFi 协议的会计逻辑错误
|
||||
|
||||
## 关联页面
|
||||
- [[blockchain-security-auditor]] — 区块链安全审计 Agent，将 Euler Finance 作为关键记忆模式收录于 Exploit Pattern Library
|
||||
- [[The-DAO-2016]] — 同为 DeFi 安全史上的里程碑事件，但攻击类型不同
|
||||
- [[Curve-Finance]] — 2023 年另一大 DeFi 安全事件
|
||||
|
||||
@@ -1,63 +1,63 @@
|
||||
---
|
||||
title: "Eurocode"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- EN 1990–1999（欧洲规范编号体系）
|
||||
- EC（Eurocode 缩写）
|
||||
- 欧盟结构设计标准
|
||||
- European Structural Design Standards
|
||||
|
||||
## Description
|
||||
|
||||
Eurocode 是欧洲结构工程设计标准体系，涵盖 EN 1990 至 EN 1999 九大领域，是全球最全面的结构设计规范框架之一，被欧盟成员国及全球多国（中东、亚洲、非洲）广泛采用或参考。
|
||||
|
||||
## Core Standards
|
||||
|
||||
| 编号 | 主题 | 核心内容 |
|
||||
|------|------|---------|
|
||||
| EN 1990 | 结构设计基础 | 荷载组合、可靠度分类、极限状态原则 |
|
||||
| EN 1991 | 结构上的作用 | 恒荷载、活荷载、风荷载、雪荷载、温度作用、偶然作用 |
|
||||
| EN 1992 | 混凝土结构 | 钢筋混凝土与预应力混凝土设计 |
|
||||
| EN 1993 | 钢结构 | 钢构件与连接设计 |
|
||||
| EN 1994 | 钢-混凝土组合结构 | 组合梁、组合柱设计 |
|
||||
| EN 1995 | 木结构 | 木结构设计 |
|
||||
| EN 1996 | 砌体结构 | 砌体结构设计 |
|
||||
| EN 1997 | 岩土设计 | 浅基础、深基础、挡土结构、边坡稳定 |
|
||||
| EN 1998 | 抗震设计 | 地震作用下的结构设计，含延性等级 DCL/DCM/DCH |
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **部分系数法**（Partial Factor Method）：EN 1990 定义了三套设计方法（DA1/DA2/DA3），对作用和抗力分别应用分项系数
|
||||
- **National Annex（NDPs）**：各成员国通过 National Annex 修订国家确定参数（NDPs），可显著改变设计结果——同一结构在不同国家的验算结果可能不同
|
||||
- **延性等级**：EN 1998 抗震设计分为 DCL（低延性）、DCM（中延性）、DCH（高延性）三级，对应不同的细部构造要求
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **欧洲**：欧盟 27 国 + 英国（UK National Annex）、瑞士、土耳其
|
||||
- **国际**：中东（阿联酋、沙特等在 Eurocode 基础上增加本地附录）、亚洲（部分国家将 Eurocode 作为参考标准）、全球基础设施项目（欧洲银行融资项目通常要求 Eurocode 合规）
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 Eurocode 作为全球设计标准之一，必须在计算包开头注明：
|
||||
1. 适用的 EN 标准编号和年份版本
|
||||
2. 所采用的 National Annex（如 DE-NA、UK-NA）
|
||||
3. 选用的 NDPs（与 EN 默认值的偏差）
|
||||
4. 设计方法（DA1/DA2/DA3）
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：美国钢结构规范——与 Eurocode EN 1993 并列，同为核心钢结构设计标准，但荷载分项系数和截面分类方法不同，不可混用
|
||||
- [[ACI-318]]：美国混凝土规范——与 Eurocode EN 1992 并列，LRFD 方法与 Eurocode 部分系数法思路相近但系数体系不同
|
||||
- [[ASCE-7]]：美国荷载规范——与 Eurocode EN 1991 并列，同为荷载标准，但风荷载谱、地震反应谱划分、荷载组合公式均有差异
|
||||
- [[EN-1997]]：岩土设计——Eurocode 岩土部分，是独立的岩土工程设计框架
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ULS]]（极限状态设计）：Eurocode 核心设计哲学，同时验证 ULS 和 SLS
|
||||
- [[National-Annex]]（国家附录）：Eurocode 各成员国的本地化修订机制，是 Eurocode 体系内规范冲突的主要来源
|
||||
- [[Basis-of-Design]]（设计依据报告）：记录所有规范选择和假设的文件
|
||||
---
|
||||
title: "Eurocode"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- EN 1990–1999（欧洲规范编号体系）
|
||||
- EC（Eurocode 缩写）
|
||||
- 欧盟结构设计标准
|
||||
- European Structural Design Standards
|
||||
|
||||
## Description
|
||||
|
||||
Eurocode 是欧洲结构工程设计标准体系，涵盖 EN 1990 至 EN 1999 九大领域，是全球最全面的结构设计规范框架之一，被欧盟成员国及全球多国（中东、亚洲、非洲）广泛采用或参考。
|
||||
|
||||
## Core Standards
|
||||
|
||||
| 编号 | 主题 | 核心内容 |
|
||||
|------|------|---------|
|
||||
| EN 1990 | 结构设计基础 | 荷载组合、可靠度分类、极限状态原则 |
|
||||
| EN 1991 | 结构上的作用 | 恒荷载、活荷载、风荷载、雪荷载、温度作用、偶然作用 |
|
||||
| EN 1992 | 混凝土结构 | 钢筋混凝土与预应力混凝土设计 |
|
||||
| EN 1993 | 钢结构 | 钢构件与连接设计 |
|
||||
| EN 1994 | 钢-混凝土组合结构 | 组合梁、组合柱设计 |
|
||||
| EN 1995 | 木结构 | 木结构设计 |
|
||||
| EN 1996 | 砌体结构 | 砌体结构设计 |
|
||||
| EN 1997 | 岩土设计 | 浅基础、深基础、挡土结构、边坡稳定 |
|
||||
| EN 1998 | 抗震设计 | 地震作用下的结构设计，含延性等级 DCL/DCM/DCH |
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **部分系数法**（Partial Factor Method）：EN 1990 定义了三套设计方法（DA1/DA2/DA3），对作用和抗力分别应用分项系数
|
||||
- **National Annex（NDPs）**：各成员国通过 National Annex 修订国家确定参数（NDPs），可显著改变设计结果——同一结构在不同国家的验算结果可能不同
|
||||
- **延性等级**：EN 1998 抗震设计分为 DCL（低延性）、DCM（中延性）、DCH（高延性）三级，对应不同的细部构造要求
|
||||
|
||||
## Jurisdiction
|
||||
|
||||
- **欧洲**：欧盟 27 国 + 英国（UK National Annex）、瑞士、土耳其
|
||||
- **国际**：中东（阿联酋、沙特等在 Eurocode 基础上增加本地附录）、亚洲（部分国家将 Eurocode 作为参考标准）、全球基础设施项目（欧洲银行融资项目通常要求 Eurocode 合规）
|
||||
|
||||
## Usage in Civil Engineer Agent
|
||||
|
||||
Civil Engineer Agent 使用 Eurocode 作为全球设计标准之一，必须在计算包开头注明：
|
||||
1. 适用的 EN 标准编号和年份版本
|
||||
2. 所采用的 National Annex（如 DE-NA、UK-NA）
|
||||
3. 选用的 NDPs（与 EN 默认值的偏差）
|
||||
4. 设计方法（DA1/DA2/DA3）
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[AISC-360]]：美国钢结构规范——与 Eurocode EN 1993 并列，同为核心钢结构设计标准，但荷载分项系数和截面分类方法不同，不可混用
|
||||
- [[ACI-318]]：美国混凝土规范——与 Eurocode EN 1992 并列，LRFD 方法与 Eurocode 部分系数法思路相近但系数体系不同
|
||||
- [[ASCE-7]]：美国荷载规范——与 Eurocode EN 1991 并列，同为荷载标准，但风荷载谱、地震反应谱划分、荷载组合公式均有差异
|
||||
- [[EN-1997]]：岩土设计——Eurocode 岩土部分，是独立的岩土工程设计框架
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[ULS]]（极限状态设计）：Eurocode 核心设计哲学，同时验证 ULS 和 SLS
|
||||
- [[National-Annex]]（国家附录）：Eurocode 各成员国的本地化修订机制，是 Eurocode 体系内规范冲突的主要来源
|
||||
- [[Basis-of-Design]]（设计依据报告）：记录所有规范选择和假设的文件
|
||||
|
||||
@@ -1,25 +1,25 @@
|
||||
---
|
||||
title: "Flux"
|
||||
type: entity
|
||||
tags: [AI生图, 开源, 扩散模型, Stable-Diffusion]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Definition
|
||||
**Flux** 是由前 Stable Diffusion 核心团队成员创立的 AI 生图开源模型，被评价为"开源界的 Midjourney"，是目前人体解剖学最正确的开源生图模型。
|
||||
|
||||
## Aliases
|
||||
- Flux AI
|
||||
- flux (GitHub 小写)
|
||||
|
||||
## Key Characteristics
|
||||
- 出自前 SD（Stable Diffusion）核心团队之手
|
||||
- 手指生成精度极高，连指甲盖光泽都能还原
|
||||
- 精准的文字渲染能力，能在图像中准确写出指定单词，适用于海报、Logo 设计
|
||||
- 在人体解剖学正确性上领先其他开源模型
|
||||
|
||||
## GitHub
|
||||
- https://github.com/black-forest-labs/flux
|
||||
|
||||
## Sources
|
||||
- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]
|
||||
---
|
||||
title: "Flux"
|
||||
type: entity
|
||||
tags: [AI生图, 开源, 扩散模型, Stable-Diffusion]
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## Definition
|
||||
**Flux** 是由前 Stable Diffusion 核心团队成员创立的 AI 生图开源模型，被评价为"开源界的 Midjourney"，是目前人体解剖学最正确的开源生图模型。
|
||||
|
||||
## Aliases
|
||||
- Flux AI
|
||||
- flux (GitHub 小写)
|
||||
|
||||
## Key Characteristics
|
||||
- 出自前 SD（Stable Diffusion）核心团队之手
|
||||
- 手指生成精度极高，连指甲盖光泽都能还原
|
||||
- 精准的文字渲染能力，能在图像中准确写出指定单词，适用于海报、Logo 设计
|
||||
- 在人体解剖学正确性上领先其他开源模型
|
||||
|
||||
## GitHub
|
||||
- https://github.com/black-forest-labs/flux
|
||||
|
||||
## Sources
|
||||
- [[2025-年-11-个神级-ai-开源平替-github-杀疯了]]
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "GDPR"
|
||||
type: entity
|
||||
tags: [security, compliance, privacy]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
# GDPR
|
||||
|
||||
**GDPR**（General Data Protection Regulation，通用数据保护条例）是欧盟 2018 年 5 月生效的数据保护法规，是全球最严格的数据隐私法律之一。
|
||||
|
||||
## Overview
|
||||
|
||||
GDPR 适用于处理欧盟居民个人数据的所有组织，无论该组织位于何处。主流云服务商通过 GDPR 合规，为全球客户提供数据保护。
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **合法性、公平性和透明度**：数据处理必须有合法依据
|
||||
2. **目的限制**：数据仅用于指定目的
|
||||
3. **数据最小化**：仅收集必要数据
|
||||
4. **准确性**：保持数据准确
|
||||
5. **存储限制**：不超过必要时间存储
|
||||
6. **完整性和保密性**：确保数据安全
|
||||
7. **问责制**：数据控制者负责合规
|
||||
|
||||
## Key Rights
|
||||
|
||||
| Right | Description |
|
||||
|-------|-------------|
|
||||
| **访问权** | 了解是否处理其数据及如何处理 |
|
||||
| **更正权** | 要求更正不准确数据 |
|
||||
| **删除权（被遗忘权）** | 要求删除数据 |
|
||||
| **限制处理权** | 限制特定处理活动 |
|
||||
| **数据可携权** | 以结构化格式获取其数据 |
|
||||
| **拒绝权** | 拒绝自动化决策 |
|
||||
| **撤回同意权** | 随时撤回同意 |
|
||||
|
||||
## Cloud Provider GDPR Compliance
|
||||
|
||||
| Provider | Key Mechanisms |
|
||||
|----------|---------------|
|
||||
| **AWS** | GDPR Data Processing Addendum, Data Privacy Center |
|
||||
| **Azure** | GDPR DPA, Compliance Manager, Data Subject Requests |
|
||||
| **Google Cloud** | GDPR Commitments, Data Processing Amendment |
|
||||
|
||||
## Cloud Myths Context
|
||||
|
||||
GDPR 是反驳"云不安全"误解的关键证据：
|
||||
- 通过 GDPR 合规的云服务商必须满足全球最严格的数据保护标准
|
||||
- 云平台的数据加密、访问控制、审计日志等能力直接支持 GDPR 合规
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Data-Sovereignty]] — 数据主权（GDPR 核心概念）
|
||||
- [[cloud-security]] — 云安全实践
|
||||
- [[ISO-27001]] — 信息安全管理体系
|
||||
- [[HIPAA]] — 医疗数据保护（对比）
|
||||
- [[SOC-2]] — 通用安全控制报告
|
||||
|
||||
## Sources
|
||||
|
||||
- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]]
|
||||
---
|
||||
title: "GDPR"
|
||||
type: entity
|
||||
tags: [security, compliance, privacy]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
# GDPR
|
||||
|
||||
**GDPR**（General Data Protection Regulation，通用数据保护条例）是欧盟 2018 年 5 月生效的数据保护法规，是全球最严格的数据隐私法律之一。
|
||||
|
||||
## Overview
|
||||
|
||||
GDPR 适用于处理欧盟居民个人数据的所有组织，无论该组织位于何处。主流云服务商通过 GDPR 合规，为全球客户提供数据保护。
|
||||
|
||||
## Key Principles
|
||||
|
||||
1. **合法性、公平性和透明度**：数据处理必须有合法依据
|
||||
2. **目的限制**：数据仅用于指定目的
|
||||
3. **数据最小化**：仅收集必要数据
|
||||
4. **准确性**：保持数据准确
|
||||
5. **存储限制**：不超过必要时间存储
|
||||
6. **完整性和保密性**：确保数据安全
|
||||
7. **问责制**：数据控制者负责合规
|
||||
|
||||
## Key Rights
|
||||
|
||||
| Right | Description |
|
||||
|-------|-------------|
|
||||
| **访问权** | 了解是否处理其数据及如何处理 |
|
||||
| **更正权** | 要求更正不准确数据 |
|
||||
| **删除权（被遗忘权）** | 要求删除数据 |
|
||||
| **限制处理权** | 限制特定处理活动 |
|
||||
| **数据可携权** | 以结构化格式获取其数据 |
|
||||
| **拒绝权** | 拒绝自动化决策 |
|
||||
| **撤回同意权** | 随时撤回同意 |
|
||||
|
||||
## Cloud Provider GDPR Compliance
|
||||
|
||||
| Provider | Key Mechanisms |
|
||||
|----------|---------------|
|
||||
| **AWS** | GDPR Data Processing Addendum, Data Privacy Center |
|
||||
| **Azure** | GDPR DPA, Compliance Manager, Data Subject Requests |
|
||||
| **Google Cloud** | GDPR Commitments, Data Processing Amendment |
|
||||
|
||||
## Cloud Myths Context
|
||||
|
||||
GDPR 是反驳"云不安全"误解的关键证据：
|
||||
- 通过 GDPR 合规的云服务商必须满足全球最严格的数据保护标准
|
||||
- 云平台的数据加密、访问控制、审计日志等能力直接支持 GDPR 合规
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Data-Sovereignty]] — 数据主权（GDPR 核心概念）
|
||||
- [[cloud-security]] — 云安全实践
|
||||
- [[ISO-27001]] — 信息安全管理体系
|
||||
- [[HIPAA]] — 医疗数据保护（对比）
|
||||
- [[SOC-2]] — 通用安全控制报告
|
||||
|
||||
## Sources
|
||||
|
||||
- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]]
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: "Gamma AI"
|
||||
type: entity
|
||||
tags: [AI, 設計, 簡報]
|
||||
sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Gamma AI（gamma.app）是一款 AI 驱动的演示文稿生成工具，用户只需输入主题或内容，Gamma AI 即可一键生成完整的演示文稿，支持主题定制和内容编辑。
|
||||
|
||||
## Key Features
|
||||
- 一键生成完整演示文稿
|
||||
- 支持多种主题和风格选择
|
||||
- AI 自动排版和视觉设计
|
||||
- 内置编辑功能，可修改 AI 生成的内容
|
||||
- 支持网页模式（可作为网页发布）
|
||||
|
||||
## Role in AI簡報工作流
|
||||
在 AI 簡報工作流中，Gamma AI 与 Canva 共同担任"设计师"角色。相比 Canva，Gamma AI 更侧重 AI 驱动的一键生成，适合快速从零制作简报的场景。
|
||||
|
||||
## Related
|
||||
- [[Canva]]：另一个 AI 简报工具，更侧重模板和手动设计
|
||||
- [[AI簡報工作流]]：Gamma AI 在此工作流中负责视觉呈现与排版
|
||||
---
|
||||
title: "Gamma AI"
|
||||
type: entity
|
||||
tags: [AI, 設計, 簡報]
|
||||
sources: [教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Gamma AI（gamma.app）是一款 AI 驱动的演示文稿生成工具，用户只需输入主题或内容，Gamma AI 即可一键生成完整的演示文稿，支持主题定制和内容编辑。
|
||||
|
||||
## Key Features
|
||||
- 一键生成完整演示文稿
|
||||
- 支持多种主题和风格选择
|
||||
- AI 自动排版和视觉设计
|
||||
- 内置编辑功能，可修改 AI 生成的内容
|
||||
- 支持网页模式（可作为网页发布）
|
||||
|
||||
## Role in AI簡報工作流
|
||||
在 AI 簡報工作流中，Gamma AI 与 Canva 共同担任"设计师"角色。相比 Canva，Gamma AI 更侧重 AI 驱动的一键生成，适合快速从零制作简报的场景。
|
||||
|
||||
## Related
|
||||
- [[Canva]]：另一个 AI 简报工具，更侧重模板和手动设计
|
||||
- [[AI簡報工作流]]：Gamma AI 在此工作流中负责视觉呈现与排版
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
---
|
||||
title: "GitHubCopilot"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Identity
|
||||
GitHub Copilot — GitHub 开发的 AI 编程助手，通过 GitHub 官方集成支持用户自定义 agent。
|
||||
|
||||
## Role in Wiki
|
||||
- 使用 [[AgentFileFormat]] 作为 agent 定义标准
|
||||
- 通过 [[TheAgency]] 提供 147+ 专业化 agent
|
||||
- 用户级别全局生效（安装到 `~/.github/agents/` 或 `~/.copilot/agents/`）
|
||||
|
||||
## Related
|
||||
- [[github-copilot]] — 集成文档
|
||||
- [[AgentFileFormat]] — 支持的文件格式
|
||||
- [[TheAgency]] — agent 来源
|
||||
---
|
||||
title: "GitHubCopilot"
|
||||
type: entity
|
||||
tags: []
|
||||
---
|
||||
|
||||
## Identity
|
||||
GitHub Copilot — GitHub 开发的 AI 编程助手，通过 GitHub 官方集成支持用户自定义 agent。
|
||||
|
||||
## Role in Wiki
|
||||
- 使用 [[AgentFileFormat]] 作为 agent 定义标准
|
||||
- 通过 [[TheAgency]] 提供 147+ 专业化 agent
|
||||
- 用户级别全局生效（安装到 `~/.github/agents/` 或 `~/.copilot/agents/`）
|
||||
|
||||
## Related
|
||||
- [[github-copilot]] — 集成文档
|
||||
- [[AgentFileFormat]] — 支持的文件格式
|
||||
- [[TheAgency]] — agent 来源
|
||||
|
||||
@@ -1,25 +1,25 @@
|
||||
---
|
||||
title: "Gitea"
|
||||
type: entity
|
||||
tags: [Git, 版本控制, 自托管]
|
||||
sources: []
|
||||
last_updated: 2026-04-09
|
||||
---
|
||||
|
||||
# Gitea
|
||||
|
||||
## 描述
|
||||
轻量级的自托管 Git 服务，托管笔记的版本控制，所有历史版本完整保留。
|
||||
|
||||
## 与 Obsidian 笔记系统的集成
|
||||
|
||||
通过 Obsidian Git 插件，笔记每次更新都对应一个 Git commit：
|
||||
- **任何时候都能回溯** — 三个月前某台服务器上跑的什么服务，一个 `git log` 就能找到
|
||||
- **变更有据可查** — "这个端口是什么时候改的？" → commit message 里写得清清楚楚
|
||||
- **多人协作预留** — 未来如果想让其他 AI Agent 也参与协作，Gitea 的权限体系天然支持
|
||||
|
||||
## 核心价值
|
||||
AI 批量改文件的能力越强，越需要版本管理来兜底。自建服务确保私有数据不出内网。
|
||||
|
||||
## 相关来源
|
||||
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
|
||||
---
|
||||
title: "Gitea"
|
||||
type: entity
|
||||
tags: [Git, 版本控制, 自托管]
|
||||
sources: []
|
||||
last_updated: 2026-04-09
|
||||
---
|
||||
|
||||
# Gitea
|
||||
|
||||
## 描述
|
||||
轻量级的自托管 Git 服务，托管笔记的版本控制，所有历史版本完整保留。
|
||||
|
||||
## 与 Obsidian 笔记系统的集成
|
||||
|
||||
通过 Obsidian Git 插件，笔记每次更新都对应一个 Git commit：
|
||||
- **任何时候都能回溯** — 三个月前某台服务器上跑的什么服务，一个 `git log` 就能找到
|
||||
- **变更有据可查** — "这个端口是什么时候改的？" → commit message 里写得清清楚楚
|
||||
- **多人协作预留** — 未来如果想让其他 AI Agent 也参与协作，Gitea 的权限体系天然支持
|
||||
|
||||
## 核心价值
|
||||
AI 批量改文件的能力越强，越需要版本管理来兜底。自建服务确保私有数据不出内网。
|
||||
|
||||
## 相关来源
|
||||
- [[养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统]]
|
||||
|
||||
@@ -1,49 +1,49 @@
|
||||
---
|
||||
title: "Gitmoji"
|
||||
type: entity
|
||||
tags: ["tool", "git", "commit-standards"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- gitmoji
|
||||
- Gitmoji
|
||||
|
||||
## Type
|
||||
Commit Standard Tool
|
||||
|
||||
## Description
|
||||
|
||||
Gitmoji 是一个标准化 Emoji 提交规范工具，通过在 Git commit message 前缀标准化的 Emoji，使开发团队能够在 git log 中通过视觉标签快速识别变更类型和意图。
|
||||
|
||||
## Official References
|
||||
|
||||
- **Primary**: [gitmoji.dev](https://gitmoji.dev/) — 当前 emoji 目录和标准含义
|
||||
- **Source of truth**: [github.com/carloscuesta/gitmoji](https://github.com/carloscuesta/gitmoji) — 上游项目和最佳实践模型
|
||||
|
||||
## Key Gitmojis
|
||||
|
||||
| Emoji | 含义 | Gitmoji 官方定义 |
|
||||
|-------|------|----------------|
|
||||
| ✨ | 新功能 | Introducing new features |
|
||||
| 🐛 | 缺陷修复 | Fixing a bug |
|
||||
| ♻️ | 重构 | Refactoring code |
|
||||
| 📚 | 文档 | Updating docs |
|
||||
| 🧪 | 测试 | Adding tests |
|
||||
| 💄 | 样式 | Updating UI/style |
|
||||
| 🔧 | 配置 | Changing config files |
|
||||
| 📦 | 依赖 | Updating packages |
|
||||
| 🚀 | 部署 | Deploying stuff |
|
||||
|
||||
## Usage in The Agency
|
||||
|
||||
[[Jira Workflow Steward]] Agent 使用 Gitmoji 作为 [[Gitmoji-Commit]] 规范的视觉层：
|
||||
- 格式：`<Gitmoji> JIRA-ID: short description`
|
||||
- 选择依据：变更的实际类型，而非个人偏好
|
||||
- 新增新 agent（catalog 功能）→ 优先 `✨`（因为 Gitmoji 定义为新功能）
|
||||
- 仅更新现有文档 → 使用 `📚`
|
||||
|
||||
Gitmoji 同时用于 commit-msg hook 的正则表达式验证，不符合规范的提交会被拒绝。
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]（主要来源）
|
||||
---
|
||||
title: "Gitmoji"
|
||||
type: entity
|
||||
tags: ["tool", "git", "commit-standards"]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- gitmoji
|
||||
- Gitmoji
|
||||
|
||||
## Type
|
||||
Commit Standard Tool
|
||||
|
||||
## Description
|
||||
|
||||
Gitmoji 是一个标准化 Emoji 提交规范工具，通过在 Git commit message 前缀标准化的 Emoji，使开发团队能够在 git log 中通过视觉标签快速识别变更类型和意图。
|
||||
|
||||
## Official References
|
||||
|
||||
- **Primary**: [gitmoji.dev](https://gitmoji.dev/) — 当前 emoji 目录和标准含义
|
||||
- **Source of truth**: [github.com/carloscuesta/gitmoji](https://github.com/carloscuesta/gitmoji) — 上游项目和最佳实践模型
|
||||
|
||||
## Key Gitmojis
|
||||
|
||||
| Emoji | 含义 | Gitmoji 官方定义 |
|
||||
|-------|------|----------------|
|
||||
| ✨ | 新功能 | Introducing new features |
|
||||
| 🐛 | 缺陷修复 | Fixing a bug |
|
||||
| ♻️ | 重构 | Refactoring code |
|
||||
| 📚 | 文档 | Updating docs |
|
||||
| 🧪 | 测试 | Adding tests |
|
||||
| 💄 | 样式 | Updating UI/style |
|
||||
| 🔧 | 配置 | Changing config files |
|
||||
| 📦 | 依赖 | Updating packages |
|
||||
| 🚀 | 部署 | Deploying stuff |
|
||||
|
||||
## Usage in The Agency
|
||||
|
||||
[[Jira Workflow Steward]] Agent 使用 Gitmoji 作为 [[Gitmoji-Commit]] 规范的视觉层：
|
||||
- 格式：`<Gitmoji> JIRA-ID: short description`
|
||||
- 选择依据：变更的实际类型，而非个人偏好
|
||||
- 新增新 agent（catalog 功能）→ 优先 `✨`（因为 Gitmoji 定义为新功能）
|
||||
- 仅更新现有文档 → 使用 `📚`
|
||||
|
||||
Gitmoji 同时用于 commit-msg hook 的正则表达式验证，不符合规范的提交会被拒绝。
|
||||
|
||||
## Sources
|
||||
- [[project-management-jira-workflow-steward]]（主要来源）
|
||||
|
||||
@@ -1,41 +1,41 @@
|
||||
---
|
||||
title: Google Cloud Platform (GCP)
|
||||
tags: [Cloud, Provider, Public-Cloud]
|
||||
---
|
||||
|
||||
# Google Cloud Platform (GCP)
|
||||
|
||||
**Google Cloud Platform (GCP)** is Google's cloud computing platform, providing infrastructure and application services with strengths in AI/ML, data analytics, and container technologies.
|
||||
|
||||
## Overview
|
||||
|
||||
GCP is one of the three major public cloud providers, particularly known for Kubernetes (originated at Google), data analytics, and machine learning capabilities.
|
||||
|
||||
## Key Services Referenced
|
||||
|
||||
| Category | Services |
|
||||
|----------|----------|
|
||||
| Compute | Compute Engine, Cloud Functions, GKE |
|
||||
| Storage | Cloud Storage, Filestore |
|
||||
| Database | Cloud SQL, BigQuery, Firestore, Spanner |
|
||||
| AI/ML | Vertex AI, TensorFlow, Gemini |
|
||||
| Analytics | BigQuery, Dataflow, Looker |
|
||||
| Networking | VPC, Cloud CDN, Cloud Load Balancing |
|
||||
|
||||
## Multi-Cloud Context
|
||||
|
||||
GCP is commonly used alongside AWS and Azure in multi-cloud strategies:
|
||||
- **Machine Learning** — Often preferred for ML/AI workloads (Vertex AI, TensorFlow)
|
||||
- **Data Analytics** — BigQuery for data warehousing and analytics
|
||||
- **Container-native** — GKE (Google Kubernetes Engine) for container orchestration
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud-Strategy]] — GCP as one of multiple providers
|
||||
- [[Cloud-Native]] — Building on GCP-native services
|
||||
- [[Kubernetes]] — GKE as managed Kubernetes
|
||||
- [[FinOps]] — Managing GCP costs
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
---
|
||||
title: Google Cloud Platform (GCP)
|
||||
tags: [Cloud, Provider, Public-Cloud]
|
||||
---
|
||||
|
||||
# Google Cloud Platform (GCP)
|
||||
|
||||
**Google Cloud Platform (GCP)** is Google's cloud computing platform, providing infrastructure and application services with strengths in AI/ML, data analytics, and container technologies.
|
||||
|
||||
## Overview
|
||||
|
||||
GCP is one of the three major public cloud providers, particularly known for Kubernetes (originated at Google), data analytics, and machine learning capabilities.
|
||||
|
||||
## Key Services Referenced
|
||||
|
||||
| Category | Services |
|
||||
|----------|----------|
|
||||
| Compute | Compute Engine, Cloud Functions, GKE |
|
||||
| Storage | Cloud Storage, Filestore |
|
||||
| Database | Cloud SQL, BigQuery, Firestore, Spanner |
|
||||
| AI/ML | Vertex AI, TensorFlow, Gemini |
|
||||
| Analytics | BigQuery, Dataflow, Looker |
|
||||
| Networking | VPC, Cloud CDN, Cloud Load Balancing |
|
||||
|
||||
## Multi-Cloud Context
|
||||
|
||||
GCP is commonly used alongside AWS and Azure in multi-cloud strategies:
|
||||
- **Machine Learning** — Often preferred for ML/AI workloads (Vertex AI, TensorFlow)
|
||||
- **Data Analytics** — BigQuery for data warehousing and analytics
|
||||
- **Container-native** — GKE (Google Kubernetes Engine) for container orchestration
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud-Strategy]] — GCP as one of multiple providers
|
||||
- [[Cloud-Native]] — Building on GCP-native services
|
||||
- [[Kubernetes]] — GKE as managed Kubernetes
|
||||
- [[FinOps]] — Managing GCP costs
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
|
||||
@@ -1,26 +1,26 @@
|
||||
---
|
||||
title: "Google"
|
||||
type: entity
|
||||
tags: [company, ai, productivity]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Google（谷歌）是全球领先的科技公司，隶属于 Alphabet 集团。旗下拥有 NotebookLM 等 AI 驱动的生产力工具，在 AI 笔记助手领域具有标杆地位。
|
||||
|
||||
## Aliases
|
||||
- Google LLC
|
||||
- Alphabet Inc.（母公司）
|
||||
- 谷歌
|
||||
|
||||
## Key Products
|
||||
- [[Google AI Studio]] — Google 官方 AI 开发平台，支持 Nano Banana Pro 图像生成
|
||||
- [[Nano Banana Pro]] — Google 的专业级多模态图像生成模型，支持文本渲染、角色一致性、4K 输出和 Google Search 信息锚定
|
||||
- [[NotebookLM]] — AI 笔记助手，支持文档问答和播客生成
|
||||
- Google Gemini — 多模态大语言模型
|
||||
- Google Workspace — 办公套件
|
||||
- [[Google Colab]] — 云端代码笔记本环境
|
||||
|
||||
## Role in This Wiki
|
||||
Nano Banana Pro 是本文档讨论的核心图像生成模型，Google AI Studio 是其官方使用平台。NotebookLM 是 AI 笔记助手领域的标杆产品，所有开源平替均以其为参照系。
|
||||
---
|
||||
title: "Google"
|
||||
type: entity
|
||||
tags: [company, ai, productivity]
|
||||
sources: [google-神级生产力工具-所有-github-开源平替都找到了]
|
||||
last_updated: 2026-04-23
|
||||
---
|
||||
|
||||
## Overview
|
||||
Google（谷歌）是全球领先的科技公司，隶属于 Alphabet 集团。旗下拥有 NotebookLM 等 AI 驱动的生产力工具，在 AI 笔记助手领域具有标杆地位。
|
||||
|
||||
## Aliases
|
||||
- Google LLC
|
||||
- Alphabet Inc.（母公司）
|
||||
- 谷歌
|
||||
|
||||
## Key Products
|
||||
- [[Google AI Studio]] — Google 官方 AI 开发平台，支持 Nano Banana Pro 图像生成
|
||||
- [[Nano Banana Pro]] — Google 的专业级多模态图像生成模型，支持文本渲染、角色一致性、4K 输出和 Google Search 信息锚定
|
||||
- [[NotebookLM]] — AI 笔记助手，支持文档问答和播客生成
|
||||
- Google Gemini — 多模态大语言模型
|
||||
- Google Workspace — 办公套件
|
||||
- [[Google Colab]] — 云端代码笔记本环境
|
||||
|
||||
## Role in This Wiki
|
||||
Nano Banana Pro 是本文档讨论的核心图像生成模型，Google AI Studio 是其官方使用平台。NotebookLM 是 AI 笔记助手领域的标杆产品，所有开源平替均以其为参照系。
|
||||
|
||||
@@ -1,32 +1,32 @@
|
||||
---
|
||||
title: "Google Ads"
|
||||
type: entity
|
||||
tags: ["paid-media", "advertising", "platform"]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Google AdWords
|
||||
- GoogleAds
|
||||
|
||||
## Overview
|
||||
Google Ads 是全球最大的在线广告平台，由 Google 运营，支持搜索、展示、视频、购物、Performance Max 等全类型广告格式。是 [[PaidMediaPpcStrategist]] 的核心投放渠道。
|
||||
|
||||
## Key Capabilities
|
||||
- **Search Ads**: 基于关键词的文本广告，出现在 Google 搜索结果页
|
||||
- **Shopping Ads**: 产品购物广告，带图片、价格、商家信息
|
||||
- **Performance Max**: AI 驱动的全渠道自动化广告，覆盖所有 Google 广告位
|
||||
- **Demand Gen**: 触达高意图消费者的发现型广告
|
||||
- **Display Ads**: 展示广告，覆盖 200 万+ 网站和应用
|
||||
- **Video Ads**: YouTube 视频广告
|
||||
|
||||
## Key Features Used by PPC Strategist
|
||||
- 自动竞价策略（tCPA/tROAS/Max Conversions/Max Conversion Value）
|
||||
- Customer Match 受众定向
|
||||
- Auction Insights 竞争情报
|
||||
- Google Ads API 大规模账户管理
|
||||
- MCC（My Client Center）多账户管理
|
||||
|
||||
## Connections
|
||||
- [[PaidMediaPpcStrategist]] 使用 Google Ads 作为核心投放平台
|
||||
- [[GoogleAdsAPI]] 提供编程接口支撑自动化运营
|
||||
---
|
||||
title: "Google Ads"
|
||||
type: entity
|
||||
tags: ["paid-media", "advertising", "platform"]
|
||||
last_updated: 2026-04-20
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Google AdWords
|
||||
- GoogleAds
|
||||
|
||||
## Overview
|
||||
Google Ads 是全球最大的在线广告平台，由 Google 运营，支持搜索、展示、视频、购物、Performance Max 等全类型广告格式。是 [[PaidMediaPpcStrategist]] 的核心投放渠道。
|
||||
|
||||
## Key Capabilities
|
||||
- **Search Ads**: 基于关键词的文本广告，出现在 Google 搜索结果页
|
||||
- **Shopping Ads**: 产品购物广告，带图片、价格、商家信息
|
||||
- **Performance Max**: AI 驱动的全渠道自动化广告，覆盖所有 Google 广告位
|
||||
- **Demand Gen**: 触达高意图消费者的发现型广告
|
||||
- **Display Ads**: 展示广告，覆盖 200 万+ 网站和应用
|
||||
- **Video Ads**: YouTube 视频广告
|
||||
|
||||
## Key Features Used by PPC Strategist
|
||||
- 自动竞价策略（tCPA/tROAS/Max Conversions/Max Conversion Value）
|
||||
- Customer Match 受众定向
|
||||
- Auction Insights 竞争情报
|
||||
- Google Ads API 大规模账户管理
|
||||
- MCC（My Client Center）多账户管理
|
||||
|
||||
## Connections
|
||||
- [[PaidMediaPpcStrategist]] 使用 Google Ads 作为核心投放平台
|
||||
- [[GoogleAdsAPI]] 提供编程接口支撑自动化运营
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: "Google Cloud"
|
||||
type: entity
|
||||
tags: [Google, Cloud, AI, ADK]
|
||||
sources: [google-5个agent-skill设计模式-2026-03-19]
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
Google Cloud Platform 的云计算部门，发布了 Agent Development Kit (ADK) 及配套的 5 种 Agent Skill 设计模式指南。
|
||||
|
||||
## Key Contributions
|
||||
- **ADK (Agent Development Kit)**：Google Cloud 发布的 Agent 开发工具包
|
||||
- **5 种 Skill 设计模式**：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline
|
||||
- **SkillToolset 机制**：支持渐进式披露，Agent 按需加载 Skill
|
||||
|
||||
## Related Entities
|
||||
- [[Anthropic]]：Claude Code 开发者，其 Skill 实践经验被 ADK 指南引用
|
||||
- [[ADK]]：Google Cloud 的 Agent 开发工具包
|
||||
- [[Google5个AgentSkill设计模式]]：本文档的核心来源
|
||||
|
||||
## Connections
|
||||
- [[Google5个AgentSkill设计模式]] ← published_by ← [[GoogleCloud]]
|
||||
- [[AnthropicSkill实践]] ← related_to ← [[GoogleCloud]]
|
||||
---
|
||||
title: "Google Cloud"
|
||||
type: entity
|
||||
tags: [Google, Cloud, AI, ADK]
|
||||
sources: [google-5个agent-skill设计模式-2026-03-19]
|
||||
last_updated: 2026-03-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
Google Cloud Platform 的云计算部门，发布了 Agent Development Kit (ADK) 及配套的 5 种 Agent Skill 设计模式指南。
|
||||
|
||||
## Key Contributions
|
||||
- **ADK (Agent Development Kit)**：Google Cloud 发布的 Agent 开发工具包
|
||||
- **5 种 Skill 设计模式**：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline
|
||||
- **SkillToolset 机制**：支持渐进式披露，Agent 按需加载 Skill
|
||||
|
||||
## Related Entities
|
||||
- [[Anthropic]]：Claude Code 开发者，其 Skill 实践经验被 ADK 指南引用
|
||||
- [[ADK]]：Google Cloud 的 Agent 开发工具包
|
||||
- [[Google5个AgentSkill设计模式]]：本文档的核心来源
|
||||
|
||||
## Connections
|
||||
- [[Google5个AgentSkill设计模式]] ← published_by ← [[GoogleCloud]]
|
||||
- [[AnthropicSkill实践]] ← related_to ← [[GoogleCloud]]
|
||||
|
||||
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: "Grafana"
|
||||
type: entity
|
||||
aliases: [Grafana OSS, Grafana Labs]
|
||||
tags: [visualization, dashboard, monitoring, observability, grafana]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
# Grafana
|
||||
|
||||
## Overview
|
||||
Grafana 是开源的可视化和监控平台，由 Grafana Labs 开发和维护。它能连接多种数据源（Prometheus、Loki、VictoriaMetrics、Elasticsearch、InfluxDB 等），提供丰富的仪表盘模板、查询编辑器和告警管理功能。家庭监控方案中，Grafana 通过 Dashboard ID 直接导入官方模板，快速搭建可视化界面。
|
||||
|
||||
## Key Characteristics
|
||||
- **多数据源支持**：Prometheus、Loki、VictoriaMetrics、Elasticsearch、MySQL、PostgreSQL 等
|
||||
- **Dashboard 即代码**：JSON 格式导出存储，纳入 Git 版本控制（GitOps）
|
||||
- **官方 Dashboard 市场**：Dashboard ID 直接导入，1860（Node Exporter Full）、14282（cAdvisor）、7587（Blackbox）
|
||||
- **告警管理**：原生告警支持，可替代 Prometheus Alerting 独立使用
|
||||
- **变量和模板**：支持动态仪表盘、级联选择器
|
||||
- **权限控制**：组织（Org）、团队、用户三级权限体系
|
||||
|
||||
## Home Server Deployment
|
||||
```yaml
|
||||
# docker-compose.yml 片段
|
||||
grafana:
|
||||
image: grafana/grafana:latest
|
||||
container_name: grafana
|
||||
ports:
|
||||
- "3000:3000"
|
||||
environment:
|
||||
- GF_AUTH_ANONYMOUS_ENABLED=true
|
||||
- GF_AUTH_ANONYMOUS_ORG_NAME=Main Org
|
||||
- GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
|
||||
- GF_SECURITY_ADMIN_USER=admin
|
||||
- GF_SECURITY_ADMIN_PASSWORD=admin
|
||||
volumes:
|
||||
- grafana-storage:/var/lib/grafana
|
||||
```
|
||||
|
||||
## Quick Dashboard Import
|
||||
1. 访问 `http://localhost:3000`，admin/admin 登录
|
||||
2. 添加数据源：`http://prometheus:9090`
|
||||
3. Dashboards → Import → 输入 Dashboard ID：
|
||||
- **1860** — Node Exporter Full（主机指标）
|
||||
- **14282** — cAdvisor Container Metrics（容器指标）
|
||||
- **7587** — Blackbox Exporter Probe（HTTP 探测）
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Entities
|
||||
- [[Prometheus]] — 主要数据源
|
||||
- [[Grafana Labs]] — 维护组织
|
||||
- [[Alertmanager]] — 告警接收
|
||||
|
||||
## Related Concepts
|
||||
- [[System Monitoring]] — 上游领域
|
||||
- [[Centralized Logging]] — Grafana Loki 补充日志可视化
|
||||
- [[Observability]] — 可观测性三大支柱之一（可视化层）
|
||||
---
|
||||
title: "Grafana"
|
||||
type: entity
|
||||
aliases: [Grafana OSS, Grafana Labs]
|
||||
tags: [visualization, dashboard, monitoring, observability, grafana]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
# Grafana
|
||||
|
||||
## Overview
|
||||
Grafana 是开源的可视化和监控平台，由 Grafana Labs 开发和维护。它能连接多种数据源（Prometheus、Loki、VictoriaMetrics、Elasticsearch、InfluxDB 等），提供丰富的仪表盘模板、查询编辑器和告警管理功能。家庭监控方案中，Grafana 通过 Dashboard ID 直接导入官方模板，快速搭建可视化界面。
|
||||
|
||||
## Key Characteristics
|
||||
- **多数据源支持**：Prometheus、Loki、VictoriaMetrics、Elasticsearch、MySQL、PostgreSQL 等
|
||||
- **Dashboard 即代码**：JSON 格式导出存储，纳入 Git 版本控制（GitOps）
|
||||
- **官方 Dashboard 市场**：Dashboard ID 直接导入，1860（Node Exporter Full）、14282（cAdvisor）、7587（Blackbox）
|
||||
- **告警管理**：原生告警支持，可替代 Prometheus Alerting 独立使用
|
||||
- **变量和模板**：支持动态仪表盘、级联选择器
|
||||
- **权限控制**：组织（Org）、团队、用户三级权限体系
|
||||
|
||||
## Home Server Deployment
|
||||
```yaml
|
||||
# docker-compose.yml 片段
|
||||
grafana:
|
||||
image: grafana/grafana:latest
|
||||
container_name: grafana
|
||||
ports:
|
||||
- "3000:3000"
|
||||
environment:
|
||||
- GF_AUTH_ANONYMOUS_ENABLED=true
|
||||
- GF_AUTH_ANONYMOUS_ORG_NAME=Main Org
|
||||
- GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
|
||||
- GF_SECURITY_ADMIN_USER=admin
|
||||
- GF_SECURITY_ADMIN_PASSWORD=admin
|
||||
volumes:
|
||||
- grafana-storage:/var/lib/grafana
|
||||
```
|
||||
|
||||
## Quick Dashboard Import
|
||||
1. 访问 `http://localhost:3000`，admin/admin 登录
|
||||
2. 添加数据源：`http://prometheus:9090`
|
||||
3. Dashboards → Import → 输入 Dashboard ID：
|
||||
- **1860** — Node Exporter Full（主机指标）
|
||||
- **14282** — cAdvisor Container Metrics（容器指标）
|
||||
- **7587** — Blackbox Exporter Probe（HTTP 探测）
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Entities
|
||||
- [[Prometheus]] — 主要数据源
|
||||
- [[Grafana Labs]] — 维护组织
|
||||
- [[Alertmanager]] — 告警接收
|
||||
|
||||
## Related Concepts
|
||||
- [[System Monitoring]] — 上游领域
|
||||
- [[Centralized Logging]] — Grafana Loki 补充日志可视化
|
||||
- [[Observability]] — 可观测性三大支柱之一（可视化层）
|
||||
|
||||
@@ -1,32 +1,32 @@
|
||||
---
|
||||
title: "Gruntwork"
|
||||
type: entity
|
||||
tags: [AWS, IaC, DevOps, Terraform]
|
||||
sources: [ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
# Gruntwork
|
||||
|
||||
## Overview
|
||||
Gruntwork 是一家专注于 AWS 基础设施即代码（IaC）的公司，提供预构建、可定制的 Terraform 模块库，帮助团队快速构建生产级云基础设施。
|
||||
|
||||
## Products
|
||||
- **Gruntwork Landing Zone Architecture**：基于 Terraform/Terragrunt 的 AWS Landing Zone 参考架构，涵盖账户结构、网络、安全、运维等基础设施层
|
||||
- **Gruntwork Infrastructure Live**：生产级 Terraform 模块库，支持多账户、多区域部署
|
||||
- **Pipelines**：Gruntwork 推荐的 CI/CD 流水线方案，集成 GitHub Actions/Jenkins
|
||||
|
||||
## Key Modules
|
||||
- **ECS 模块**：Docker 容器部署模块，CTP/SRE 团队在此基础上构建了自己的 ECS 模块（实现 Listener 集中管理）
|
||||
- **EKS 模块**：Kubernetes 集群部署模块
|
||||
- **Landing Zone 模块**：AWS 组织、账户、OU 架构
|
||||
|
||||
## Gruntwork in CTP Context
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]]：CTP Topic 9 深入 Gruntwork CI/CD 实践
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比，Gruntwork 作为辅助工具推荐
|
||||
- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：CTP 团队在 Gruntwork 仓库基础上开发 ECS 模块
|
||||
|
||||
## Connections
|
||||
- [[HashiCorp]] ← provider_of ← [[Terraform]] ← uses ← [[Gruntwork]]
|
||||
- [[Atlantis]] ← alternative_to ← [[Gruntwork-Pipelines]]
|
||||
- [[Gruntwork]] ← builds_on ← [[Infrastructure-as-Code]]
|
||||
---
|
||||
title: "Gruntwork"
|
||||
type: entity
|
||||
tags: [AWS, IaC, DevOps, Terraform]
|
||||
sources: [ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
# Gruntwork
|
||||
|
||||
## Overview
|
||||
Gruntwork 是一家专注于 AWS 基础设施即代码（IaC）的公司，提供预构建、可定制的 Terraform 模块库，帮助团队快速构建生产级云基础设施。
|
||||
|
||||
## Products
|
||||
- **Gruntwork Landing Zone Architecture**：基于 Terraform/Terragrunt 的 AWS Landing Zone 参考架构，涵盖账户结构、网络、安全、运维等基础设施层
|
||||
- **Gruntwork Infrastructure Live**：生产级 Terraform 模块库，支持多账户、多区域部署
|
||||
- **Pipelines**：Gruntwork 推荐的 CI/CD 流水线方案，集成 GitHub Actions/Jenkins
|
||||
|
||||
## Key Modules
|
||||
- **ECS 模块**：Docker 容器部署模块，CTP/SRE 团队在此基础上构建了自己的 ECS 模块（实现 Listener 集中管理）
|
||||
- **EKS 模块**：Kubernetes 集群部署模块
|
||||
- **Landing Zone 模块**：AWS 组织、账户、OU 架构
|
||||
|
||||
## Gruntwork in CTP Context
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]]：CTP Topic 9 深入 Gruntwork CI/CD 实践
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比，Gruntwork 作为辅助工具推荐
|
||||
- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：CTP 团队在 Gruntwork 仓库基础上开发 ECS 模块
|
||||
|
||||
## Connections
|
||||
- [[HashiCorp]] ← provider_of ← [[Terraform]] ← uses ← [[Gruntwork]]
|
||||
- [[Atlantis]] ← alternative_to ← [[Gruntwork-Pipelines]]
|
||||
- [[Gruntwork]] ← builds_on ← [[Infrastructure-as-Code]]
|
||||
|
||||
@@ -1,57 +1,57 @@
|
||||
---
|
||||
title: "HIPAA"
|
||||
type: entity
|
||||
tags: [security, compliance, healthcare]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
# HIPAA
|
||||
|
||||
**HIPAA**（Health Insurance Portability and Accountability Act）是美国 1996 年颁布的联邦法律，主要规范医疗健康信息的隐私和安全。
|
||||
|
||||
## Overview
|
||||
|
||||
HIPAA 是医疗行业云采用的关键合规门槛。主流云服务商通过 HIPAA 合规认证，使其能够服务医疗健康行业客户。
|
||||
|
||||
## Key Rules
|
||||
|
||||
### Privacy Rule（隐私规则）
|
||||
- 保护个人医疗信息（PHI / Protected Health Information）
|
||||
- 规定谁可以访问 PHI
|
||||
- 赋予患者访问和控制自己信息的权利
|
||||
|
||||
### Security Rule（安全规则）
|
||||
- **Administrative Safeguards**: 安全管理和流程
|
||||
- **Physical Safeguards**: 物理设施安全
|
||||
- **Technical Safeguards**: 技术保护措施
|
||||
|
||||
### Breach Notification Rule（违约通知规则）
|
||||
- 超过 500 人受影响必须在 60 天内通知
|
||||
- 向 HHS 和媒体通报
|
||||
|
||||
## Cloud Provider HIPAA Compliance
|
||||
|
||||
主流云服务商通过 HIPAA 合规，允许医疗客户在云中处理 PHI：
|
||||
|
||||
| Provider | HIPAA Compliance |
|
||||
|----------|-----------------|
|
||||
| **AWS** | BAA (Business Associate Agreement) 可用，HIPAA Eligible Services |
|
||||
| **Azure** | HIPAA BAA，覆盖大量 Azure 服务 |
|
||||
| **Google Cloud** | HIPAA BAA，支持 PHI 工作负载 |
|
||||
|
||||
## Relevance to Cloud Myths
|
||||
|
||||
HIPAA 认证是反驳"云不安全"误解的重要证据：
|
||||
- 云服务商支持 HIPAA 合规 = 可安全处理最敏感的医疗数据
|
||||
- 通过 HIPAA 认证的云环境在某些方面优于传统本地医疗系统
|
||||
|
||||
## Related Standards
|
||||
|
||||
- [[ISO-27001]] — 信息安全管理体系
|
||||
- [[GDPR]] — 欧盟数据保护条例（跨地区对比）
|
||||
- [[SOC-2]] — 通用安全控制报告
|
||||
- [[PHI]] — Protected Health Information
|
||||
|
||||
## Sources
|
||||
|
||||
- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]]
|
||||
---
|
||||
title: "HIPAA"
|
||||
type: entity
|
||||
tags: [security, compliance, healthcare]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
# HIPAA
|
||||
|
||||
**HIPAA**（Health Insurance Portability and Accountability Act）是美国 1996 年颁布的联邦法律，主要规范医疗健康信息的隐私和安全。
|
||||
|
||||
## Overview
|
||||
|
||||
HIPAA 是医疗行业云采用的关键合规门槛。主流云服务商通过 HIPAA 合规认证，使其能够服务医疗健康行业客户。
|
||||
|
||||
## Key Rules
|
||||
|
||||
### Privacy Rule（隐私规则）
|
||||
- 保护个人医疗信息（PHI / Protected Health Information）
|
||||
- 规定谁可以访问 PHI
|
||||
- 赋予患者访问和控制自己信息的权利
|
||||
|
||||
### Security Rule（安全规则）
|
||||
- **Administrative Safeguards**: 安全管理和流程
|
||||
- **Physical Safeguards**: 物理设施安全
|
||||
- **Technical Safeguards**: 技术保护措施
|
||||
|
||||
### Breach Notification Rule（违约通知规则）
|
||||
- 超过 500 人受影响必须在 60 天内通知
|
||||
- 向 HHS 和媒体通报
|
||||
|
||||
## Cloud Provider HIPAA Compliance
|
||||
|
||||
主流云服务商通过 HIPAA 合规，允许医疗客户在云中处理 PHI：
|
||||
|
||||
| Provider | HIPAA Compliance |
|
||||
|----------|-----------------|
|
||||
| **AWS** | BAA (Business Associate Agreement) 可用，HIPAA Eligible Services |
|
||||
| **Azure** | HIPAA BAA，覆盖大量 Azure 服务 |
|
||||
| **Google Cloud** | HIPAA BAA，支持 PHI 工作负载 |
|
||||
|
||||
## Relevance to Cloud Myths
|
||||
|
||||
HIPAA 认证是反驳"云不安全"误解的重要证据：
|
||||
- 云服务商支持 HIPAA 合规 = 可安全处理最敏感的医疗数据
|
||||
- 通过 HIPAA 认证的云环境在某些方面优于传统本地医疗系统
|
||||
|
||||
## Related Standards
|
||||
|
||||
- [[ISO-27001]] — 信息安全管理体系
|
||||
- [[GDPR]] — 欧盟数据保护条例（跨地区对比）
|
||||
- [[SOC-2]] — 通用安全控制报告
|
||||
- [[PHI]] — Protected Health Information
|
||||
|
||||
## Sources
|
||||
|
||||
- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]]
|
||||
|
||||
@@ -1,46 +1,46 @@
|
||||
---
|
||||
title: "HP ZBook"
|
||||
type: entity
|
||||
tags: [hp, workstation, laptop, uefi]
|
||||
date: 2026-04-14
|
||||
aliases: [ZBook, HP ZBook, HP ZBook Workstation, HP ZBook移动工作站]
|
||||
---
|
||||
|
||||
# HP ZBook
|
||||
|
||||
## Overview
|
||||
HP ZBook 是 HP 公司的移动工作站笔记本系列，定位专业级图形/计算工作负载，配备高性能 CPU、NVMe 固态硬盘和 UEFI 固件。
|
||||
|
||||
## Key Hardware Characteristics
|
||||
- **CPU**：Intel Core 或 Xeon 系列
|
||||
- **存储**：NVMe PCIe SSD（需 AHCI 模式，RAID/Intel RST 不兼容 Ubuntu）
|
||||
- **固件**：UEFI（带传统 BIOS 兼容层）
|
||||
- **启动键**：F9（启动菜单）、F10（BIOS 设置）
|
||||
|
||||
## Ubuntu Installation Issues
|
||||
HP ZBook 在安装 Ubuntu 24.04 时遇到的核心问题是 **BIOS 固执行为**：
|
||||
1. Ubuntu 成功注册到 NVRAM（`Boot0005: Ubuntu`）
|
||||
2. 但该启动项未被加入 `BootOrder`
|
||||
3. 每次重启后，BIOS 忽略 Ubuntu 启动项
|
||||
|
||||
### BIOS Recommended Settings
|
||||
| 设置项 | 建议值 | 原因 |
|
||||
|--------|--------|------|
|
||||
| SATA Mode | AHCI | Ubuntu 不兼容 Intel RST RAID |
|
||||
| Secure Boot | Disabled | 避免第三方驱动安装麻烦 |
|
||||
| Fast Boot | Disabled | 确保 U 盘顺利引导 |
|
||||
| Legacy Support | Disabled / UEFI Only | 消除 BBS 遗留项干扰 |
|
||||
|
||||
## Solutions Applied
|
||||
1. **efibootmgr 强制重写**：将 0005 写入 BootOrder 首位
|
||||
2. **EFI 路径伪装**：复制 shimx64.efi → /EFI/BOOT/BOOTX64.EFI
|
||||
3. **UEFI Only 模式**（终极方案）：切换后所有 Legacy 项自动消失
|
||||
|
||||
## Related
|
||||
- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] — 完整安装与故障排除记录
|
||||
- [[Rufus]] — 启动盘制作工具
|
||||
- [[efibootmgr]] — NVRAM 启动项管理
|
||||
- [[UEFI Only]] — 终极启动修复方案
|
||||
- [[NVMe硬盘分区]] — 硬盘分区规范
|
||||
- [[HP ZBook]] ← 安装目标 ← [[Rufus]]
|
||||
- [[HP ZBook]] ← 受影响平台 ← [[efibootmgr]]
|
||||
---
|
||||
title: "HP ZBook"
|
||||
type: entity
|
||||
tags: [hp, workstation, laptop, uefi]
|
||||
date: 2026-04-14
|
||||
aliases: [ZBook, HP ZBook, HP ZBook Workstation, HP ZBook移动工作站]
|
||||
---
|
||||
|
||||
# HP ZBook
|
||||
|
||||
## Overview
|
||||
HP ZBook 是 HP 公司的移动工作站笔记本系列，定位专业级图形/计算工作负载，配备高性能 CPU、NVMe 固态硬盘和 UEFI 固件。
|
||||
|
||||
## Key Hardware Characteristics
|
||||
- **CPU**：Intel Core 或 Xeon 系列
|
||||
- **存储**：NVMe PCIe SSD（需 AHCI 模式，RAID/Intel RST 不兼容 Ubuntu）
|
||||
- **固件**：UEFI（带传统 BIOS 兼容层）
|
||||
- **启动键**：F9（启动菜单）、F10（BIOS 设置）
|
||||
|
||||
## Ubuntu Installation Issues
|
||||
HP ZBook 在安装 Ubuntu 24.04 时遇到的核心问题是 **BIOS 固执行为**：
|
||||
1. Ubuntu 成功注册到 NVRAM（`Boot0005: Ubuntu`）
|
||||
2. 但该启动项未被加入 `BootOrder`
|
||||
3. 每次重启后，BIOS 忽略 Ubuntu 启动项
|
||||
|
||||
### BIOS Recommended Settings
|
||||
| 设置项 | 建议值 | 原因 |
|
||||
|--------|--------|------|
|
||||
| SATA Mode | AHCI | Ubuntu 不兼容 Intel RST RAID |
|
||||
| Secure Boot | Disabled | 避免第三方驱动安装麻烦 |
|
||||
| Fast Boot | Disabled | 确保 U 盘顺利引导 |
|
||||
| Legacy Support | Disabled / UEFI Only | 消除 BBS 遗留项干扰 |
|
||||
|
||||
## Solutions Applied
|
||||
1. **efibootmgr 强制重写**：将 0005 写入 BootOrder 首位
|
||||
2. **EFI 路径伪装**：复制 shimx64.efi → /EFI/BOOT/BOOTX64.EFI
|
||||
3. **UEFI Only 模式**（终极方案）：切换后所有 Legacy 项自动消失
|
||||
|
||||
## Related
|
||||
- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] — 完整安装与故障排除记录
|
||||
- [[Rufus]] — 启动盘制作工具
|
||||
- [[efibootmgr]] — NVRAM 启动项管理
|
||||
- [[UEFI Only]] — 终极启动修复方案
|
||||
- [[NVMe硬盘分区]] — 硬盘分区规范
|
||||
- [[HP ZBook]] ← 安装目标 ← [[Rufus]]
|
||||
- [[HP ZBook]] ← 受影响平台 ← [[efibootmgr]]
|
||||
|
||||
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: "HashiCorp"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- infrastructure
|
||||
- tools
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# HashiCorp
|
||||
|
||||
## Definition
|
||||
|
||||
HashiCorp 是全球领先的**云基础设施自动化**软件公司，总部位于旧金山，创立于 2012 年。HashiCorp 提供一套完整的基础设施生命周期管理工具，覆盖配置管理、机密管理、服务网格和网络自动化等领域。
|
||||
|
||||
## Core Products
|
||||
|
||||
| 产品 | 用途 | 类别 |
|
||||
|------|------|------|
|
||||
| **Terraform** | 云厂商无关的基础设施即代码 | IaC |
|
||||
| **Vault** | 机密管理与加密即服务 | 安全 |
|
||||
| **Nomad** | 容器和工作负载调度器 | 编排 |
|
||||
| **Consul** | 服务网格与服务发现 | 网络 |
|
||||
| **Packer** | 机器镜像构建自动化 | 镜像 |
|
||||
| **Vagrant** | 开发环境管理 | 开发环境 |
|
||||
|
||||
## Terraform
|
||||
|
||||
HashiCorp 最知名的产品。Terraform 是用 Golang 编写的云无关 IaC 工具，通过声明式 HCL（HashiCorp Configuration Language）管理跨多云和混合云环境的基础设施资源。
|
||||
|
||||
**关键特性：**
|
||||
- 云厂商无关（AWS/Azure/GCP/On-prem）
|
||||
- `terraform plan` 预览变更
|
||||
- 状态文件管理实际资源与期望状态的绑定
|
||||
- 丰富的 Provider 生态系统和 Module 市场
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Business Model
|
||||
|
||||
- **开源**：所有产品的开源版本
|
||||
- **Enterprise**：企业级功能（SSO、RBAC、审计日志、Sentinel 策略）
|
||||
- **HCP（HashiCorp Cloud Platform）**：SaaS 托管版本
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — HashiCorp 出品的核心 IaC 产品
|
||||
- [[Terragrunt]] — 第三方 Terraform 封装工具（贯彻 DRY 原则）
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — HashiCorp 产品的核心方法论
|
||||
- [[Multi-Cloud Strategy]] — Terraform 云无关定位的战略价值
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
---
|
||||
title: "HashiCorp"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- infrastructure
|
||||
- tools
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# HashiCorp
|
||||
|
||||
## Definition
|
||||
|
||||
HashiCorp 是全球领先的**云基础设施自动化**软件公司，总部位于旧金山，创立于 2012 年。HashiCorp 提供一套完整的基础设施生命周期管理工具，覆盖配置管理、机密管理、服务网格和网络自动化等领域。
|
||||
|
||||
## Core Products
|
||||
|
||||
| 产品 | 用途 | 类别 |
|
||||
|------|------|------|
|
||||
| **Terraform** | 云厂商无关的基础设施即代码 | IaC |
|
||||
| **Vault** | 机密管理与加密即服务 | 安全 |
|
||||
| **Nomad** | 容器和工作负载调度器 | 编排 |
|
||||
| **Consul** | 服务网格与服务发现 | 网络 |
|
||||
| **Packer** | 机器镜像构建自动化 | 镜像 |
|
||||
| **Vagrant** | 开发环境管理 | 开发环境 |
|
||||
|
||||
## Terraform
|
||||
|
||||
HashiCorp 最知名的产品。Terraform 是用 Golang 编写的云无关 IaC 工具，通过声明式 HCL（HashiCorp Configuration Language）管理跨多云和混合云环境的基础设施资源。
|
||||
|
||||
**关键特性：**
|
||||
- 云厂商无关（AWS/Azure/GCP/On-prem）
|
||||
- `terraform plan` 预览变更
|
||||
- 状态文件管理实际资源与期望状态的绑定
|
||||
- 丰富的 Provider 生态系统和 Module 市场
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Business Model
|
||||
|
||||
- **开源**：所有产品的开源版本
|
||||
- **Enterprise**：企业级功能（SSO、RBAC、审计日志、Sentinel 策略）
|
||||
- **HCP（HashiCorp Cloud Platform）**：SaaS 托管版本
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — HashiCorp 出品的核心 IaC 产品
|
||||
- [[Terragrunt]] — 第三方 Terraform 封装工具（贯彻 DRY 原则）
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — HashiCorp 产品的核心方法论
|
||||
- [[Multi-Cloud Strategy]] — Terraform 云无关定位的战略价值
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
---
|
||||
title: "Heather Norris"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **角色：** 云转型计划（Cloud Transformation Programme）项目经理
|
||||
- **演讲主题：** 在云转型项目中应用敏捷方法论（CTP Topic 4）
|
||||
|
||||
## 主要观点
|
||||
- 倡导 Scrum 向 Kanban 的框架演进，以适应云转型项目的高变化频率
|
||||
- 强调敏捷的核心价值是快速反馈循环，持续改进产品和开发文化
|
||||
- 推动 Microsoft Planner 作为团队统一的看板工具
|
||||
|
||||
## 参与项目
|
||||
- Cloud Transformation Programme (CTP)
|
||||
|
||||
## 来源
|
||||
- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
|
||||
---
|
||||
title: "Heather Norris"
|
||||
type: entity
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-24
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **角色：** 云转型计划（Cloud Transformation Programme）项目经理
|
||||
- **演讲主题：** 在云转型项目中应用敏捷方法论（CTP Topic 4）
|
||||
|
||||
## 主要观点
|
||||
- 倡导 Scrum 向 Kanban 的框架演进，以适应云转型项目的高变化频率
|
||||
- 强调敏捷的核心价值是快速反馈循环，持续改进产品和开发文化
|
||||
- 推动 Microsoft Planner 作为团队统一的看板工具
|
||||
|
||||
## 参与项目
|
||||
- Cloud Transformation Programme (CTP)
|
||||
|
||||
## 来源
|
||||
- [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: "Hemant Sawant"
|
||||
type: entity
|
||||
tags: [devops, author, linkedin]
|
||||
sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md]]
|
||||
|
||||
## Summary
|
||||
Hemant Sawant is a DevOps practitioner and thought leader who publishes articles on LinkedIn about DevOps culture, organizational transformation, Agile practices, and cloud-native engineering. The ingested article covers a comprehensive DevOps transformation framework including the four foundational pillars, Agile integration strategies, and a strategic transformation playbook.
|
||||
|
||||
## Key Claims
|
||||
- DevOps transformation requires dismantling silos between Development and Operations through cross-functional teams
|
||||
- Four foundational pillars: Collaboration, Automation, Continuous Improvement (Kaizen), Customer-Centricity
|
||||
- Agile and DevOps are symbiotic — DevOps extends Agile agility to operations
|
||||
- Transformation requires leadership buy-in, upskilling investment, and pilot-driven quick wins
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture]] — Primary topic of his writing
|
||||
- [[DevSecOps]] — Future trend mentioned in his article
|
||||
- [[GitOps]] — Future trend mentioned in his article
|
||||
---
|
||||
title: "Hemant Sawant"
|
||||
type: entity
|
||||
tags: [devops, author, linkedin]
|
||||
sources: [devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin]
|
||||
last_updated: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn.md]]
|
||||
|
||||
## Summary
|
||||
Hemant Sawant is a DevOps practitioner and thought leader who publishes articles on LinkedIn about DevOps culture, organizational transformation, Agile practices, and cloud-native engineering. The ingested article covers a comprehensive DevOps transformation framework including the four foundational pillars, Agile integration strategies, and a strategic transformation playbook.
|
||||
|
||||
## Key Claims
|
||||
- DevOps transformation requires dismantling silos between Development and Operations through cross-functional teams
|
||||
- Four foundational pillars: Collaboration, Automation, Continuous Improvement (Kaizen), Customer-Centricity
|
||||
- Agile and DevOps are symbiotic — DevOps extends Agile agility to operations
|
||||
- Transformation requires leadership buy-in, upskilling investment, and pilot-driven quick wins
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture]] — Primary topic of his writing
|
||||
- [[DevSecOps]] — Future trend mentioned in his article
|
||||
- [[GitOps]] — Future trend mentioned in his article
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user