Auto-sync: 2026-04-16 17:30
This commit is contained in:
@@ -1,35 +0,0 @@
|
||||
---
|
||||
id: AI Agent 思维方式
|
||||
title: "AI Agent 思维方式"
|
||||
type: concept
|
||||
tags: [ai-agent, thinking-mode, problem-framing]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI Agent 与传统工具的根本区别：先通过提问澄清需求，再制定可执行方案，而非直接执行。
|
||||
|
||||
## Core Mechanism
|
||||
- Step 1：问关键问题（不直接推荐工具）
|
||||
- Step 2：将模糊想法转化为清晰结构
|
||||
- Step 3：拆解为可执行的小步骤
|
||||
- Step 4：制定风险控制策略
|
||||
- Step 5：自动化执行 + 定期报告
|
||||
|
||||
## Key Questions Pattern
|
||||
- 问题边界是什么？
|
||||
- 重复/高质量/删除的定义是什么？
|
||||
- 风险承受范围多大？
|
||||
- 执行结果如何验证？
|
||||
|
||||
## 与传统工具的对比
|
||||
- 传统工具：接收指令 → 执行（假设用户已经想清楚）
|
||||
- AI Agent：提问澄清 → 结构化方案 → 执行（帮助用户想清楚再动手）
|
||||
|
||||
## Related Concepts
|
||||
- [[OpenClaw]]：AI Agent 思维方式的执行平台
|
||||
- [[精确去重]]：AI Agent 思维方式的具体应用
|
||||
- [[分批执行]]：AI Agent 处理大任务的策略
|
||||
|
||||
## Sources
|
||||
- [[养虾日记1-OpenClaw照片整理实战]]
|
||||
28
wiki/concepts/AI-ChatOps.md
Normal file
28
wiki/concepts/AI-ChatOps.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "AI ChatOps"
|
||||
type: concept
|
||||
tags: [ChatOps, AI, collaboration]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI ChatOps 是将 AI 能力集成到协作平台（如 Slack、Teams）中，实现通过自然语言进行故障排除和运维操作的工作方式。
|
||||
|
||||
## Definition
|
||||
通过聊天界面与 AI 代理交互，查询日志、获取性能洞察、执行故障排除操作的工作模式。
|
||||
|
||||
## Key Platforms
|
||||
- [[Slack]]
|
||||
- [[Teams]]
|
||||
- CLI 终端
|
||||
|
||||
## Key Capabilities
|
||||
- **自然语言查询**：用自然语言查询日志和指标
|
||||
- **AI 驱动洞察**：获取 AI 分析的问题原因
|
||||
- **自动化操作**：通过聊天触发自动化修复
|
||||
- **上下文保持**：AI 记住对话上下文，支持多轮对话
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← powers ← [[AI ChatOps]]：Agentic AI 驱动 ChatOps 交互
|
||||
- [[监控可观测性]] ← enhanced_by ← [[AI ChatOps]]：AI ChatOps 增强可观测性
|
||||
28
wiki/concepts/AI-driven-RCA.md
Normal file
28
wiki/concepts/AI-driven-RCA.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "AI-driven RCA"
|
||||
type: concept
|
||||
tags: [AI, root-cause-analysis, incident-management]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI-driven RCA（AI 驱动的根因分析）利用机器学习分析日志和指标，自动识别故障根本原因。
|
||||
|
||||
## Definition
|
||||
使用 AI 算法分析来自多个来源的日志、指标和事件数据，自动定位系统故障的根本原因。
|
||||
|
||||
## Key Techniques
|
||||
- **日志关联分析**：跨服务、跨时间关联日志事件
|
||||
- **异常模式识别**：识别与历史 outage 类似的模式
|
||||
- **因果链路推断**：构建故障传播链路，确定因果关系
|
||||
- **多维度分析**：同时分析计算、网络、存储、应用层
|
||||
|
||||
## Tools
|
||||
- [[CloudWatch]]（AWS）
|
||||
- [[Stackdriver]]/Cloud Monitoring（GCP）
|
||||
- Azure Monitor（Azure）
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← uses ← [[AI-driven RCA]]：Agentic AI 集成 RCA 能力
|
||||
- [[MTTR]] ← reduces ← [[AI-driven RCA]]：AI RCA 缩短平均修复时间
|
||||
23
wiki/concepts/AI-powered-Runbooks.md
Normal file
23
wiki/concepts/AI-powered-Runbooks.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "AI-powered Runbooks"
|
||||
type: concept
|
||||
tags: [runbooks, automation, AI]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
AI-powered Runbooks（AI 驱动运维手册）是利用 AI 推荐最佳运维操作手册和处理流程的系统。
|
||||
|
||||
## Definition
|
||||
AI 分析历史 incident 和最佳实践，自动推荐或生成处理当前事件的运维手册。
|
||||
|
||||
## Key Features
|
||||
- **智能推荐**：基于当前事件推荐最相关的操作手册
|
||||
- **动态生成**：根据上下文动态生成处理步骤
|
||||
- **历史学习**：从历史 incident 学习改进建议
|
||||
- **自动化执行**：可自动执行手册中的步骤
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← powers ← [[AI-powered Runbooks]]：Agentic AI 实现智能运维手册
|
||||
- [[无责复盘 (Blameless Postmortem)]] ← informs ← [[AI-powered Runbooks]]：无责复盘结果改进运维手册
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: "AI产品经理"
|
||||
type: concept
|
||||
tags: [产品管理, AI工作流, 超级个体, 能力结构]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI产品经理：掌握将大模型嵌入工作流以产生实际价值的产品经理，而非浅尝辄止的豆包用户。核心能力是 [[精准表达]] 和 [[结构化思维]]，而非大模型 API 调用技术。
|
||||
|
||||
## 能力要求
|
||||
- 能掌握大模型（深度使用），而非仅浅尝辄止
|
||||
- 能把大模型"嵌入"工作流，产生实际价值
|
||||
- 掌握 FeatureList 共创、PRD 自动生成、Mermaid 逻辑图等 AI 协作方法
|
||||
- 具备市场洞察（产品经理最稀缺也最重要的能力）
|
||||
|
||||
## 核心洞察
|
||||
- 大模型是"知识渊博但不带脑子的苦工"，表述越准、执行越准
|
||||
- AI 是横向扩展工具，非充分条件：[[超级个体]] 本就具备把事情做对的能力
|
||||
- 不能把时代新东西嵌入自己的工作者，会被淘汰
|
||||
- AI进化速度超出预期，量变到质变在多个细分场景中悄然发生
|
||||
|
||||
## 与超级个体的关系
|
||||
- [[超级个体]] = 某领域做到八九十分 + AI 放大横向扩展能力
|
||||
- 本身只能做到六十分的人：被工具化，嵌入 AI 流程，而非真正用好 AI
|
||||
- 市场洞察力 = 产品经理最稀缺最重要的能力，AI 时代此能力更重要
|
||||
|
||||
## Connections
|
||||
- [[不会Gemini的产品经理真的要被淘汰了]] ← 来源
|
||||
- [[FeatureList]] ← 核心工具
|
||||
- [[PRD自动生成]] ← 核心工具
|
||||
- [[超级个体]] ← 相关概念
|
||||
- [[精准表达]] ← 核心能力
|
||||
- [[结构化思维]] ← 核心能力
|
||||
- [[Gemini]] ← 主要工具
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: "AI代码编辑器"
|
||||
type: concept
|
||||
tags: [ai, code-editor, vibe-coding]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
集成 AI 辅助能力（代码生成/补全/审查/规划）的代码编辑器，相比传统 IDE 新增 AI 代理交互界面。
|
||||
|
||||
## 主流工具
|
||||
- [[Cursor]]：基于 VS Code，Composer 模型，多代理并行
|
||||
- [[Windsurf]]：Codeium 推出的 AI 代码编辑器
|
||||
- [[Trae]]：字节跳动推出的 AI 代码编辑器
|
||||
- [[Cline]]：VS Code 扩展，将 VS Code 变身为全自动 AI 工程师
|
||||
|
||||
## 核心功能对比
|
||||
| 功能 | Cursor | Windsurf | Trae | Cline |
|
||||
|------|--------|----------|------|-------|
|
||||
| 底层框架 | VS Code | VS Code | VS Code | VS Code |
|
||||
| 自研模型 | Composer（4倍速） | Codeium | 豆包/其他 | Claude |
|
||||
| 多代理 | ✅ | ✅ | ✅ | ✅ |
|
||||
| MCP 支持 | ✅ | ✅ | ✅ | ✅ |
|
||||
| Diff 审查 | ✅ | ❓ | ❓ | ✅ |
|
||||
|
||||
## 核心工作流
|
||||
明确需求 → AI 规划（Plan）→ 代码生成（Agent）→ Diff 审查 → Git 版本控制
|
||||
|
||||
## 关联
|
||||
- [[Vibe Coding]] 的工具层实现
|
||||
- [[AI编程]] 的具体工具形态
|
||||
|
||||
## Aliases
|
||||
- AI IDE
|
||||
- AI 代码生成器
|
||||
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "AI工作流自动生成"
|
||||
type: concept
|
||||
tags: [ai, workflow-automation, n8n]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
# AI工作流自动生成
|
||||
|
||||
## 定义
|
||||
通过自然语言描述需求，由 AI 自动设计并生成工作流代码的过程。
|
||||
|
||||
## 核心机制
|
||||
1. 用户输入自然语言需求描述
|
||||
2. AI 理解任务目标并选择合适节点
|
||||
3. AI 自动生成节点连接和配置代码
|
||||
4. 用户验证并修正错误
|
||||
|
||||
## 典型案例
|
||||
- [[使用Claude自动生成N8N工作流的实操教程]]：Claude + n8n-mcp 实现 80%-90% 完成度
|
||||
|
||||
## 局限性
|
||||
- AI 生成工作流约 10%-20% 错误率需人工修正
|
||||
- 需选择专用模型（如 Opensea）和开启 extended thinking 提升质量
|
||||
|
||||
## Connections
|
||||
- [[n8n]]：目标工作流平台
|
||||
- [[Claude]]：生成执行方
|
||||
- [[n8n mcp]]：桥接工具
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "AI工具命名框架"
|
||||
type: concept
|
||||
tags: [ai, product, social-cognition]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI工具命名框架指 AI 产品的名称、话语和营销策略如何折射并强化社会对特定职业的认知。研究以 AI SRE 和编码助手为例，揭示命名差异背后的价值判断。
|
||||
|
||||
## Two Contrasting Frameworks
|
||||
| 维度 | AI SRE 框架 | 编码助手框架 |
|
||||
|------|------------|------------|
|
||||
| 定位 | 替代者/消除者 | 协作者/增强者 |
|
||||
| 人名命名 | 极少数（Cleric） | 普遍（Claude、Cline） |
|
||||
| 核心话语 | "消除负担""救火" | "增强能力""赋予控制" |
|
||||
| 目标受众 | 买家（管理者） | 员工+买家 |
|
||||
| 隐含价值 | 低估 SRE 工作价值 | 尊重工程师创造力 |
|
||||
|
||||
## Social Implications
|
||||
- 命名差异反映了买卖双方对职业价值的社会认知分裂
|
||||
- 当工具被定位为替代时，只需要与管理者对话
|
||||
- 当工具被定位为协作者时，需要同时说服员工和雇主
|
||||
- 接受某种框架 = 在社会层面放大该框架并赋予其合法性
|
||||
|
||||
## Connections
|
||||
- [[Taylorism]] ← 理论基础 ← AI SRE 框架本质是泰勒制的职业替代观
|
||||
- [[超级个体]] ← 对立 ← 超级个体强调人的价值，AI工具命名框架低估人的价值
|
||||
- [[AI产品经理]] ← 关联 ← AI产品经理的命名和定位同样反映其职业认知
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "AI技能封装"
|
||||
type: concept
|
||||
tags: [ai, skill, workflow]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI 技能封装（AI Skill Encapsulation）是将固定流程任务拆解为 AI 可理解、可复用、可自动执行的结构化流程的方法论。
|
||||
|
||||
## Core Mechanism
|
||||
1. 识别反复执行且有固定流程的任务
|
||||
2. 将流程拆解为 AI 能理解的步骤
|
||||
3. 编写 Skill.md（说明书 + SOP）
|
||||
4. AI 依据 Skill 稳定复用流程
|
||||
|
||||
## Key Properties
|
||||
- 可理解：结构化描述，非模糊自然语言
|
||||
- 可复用：同一 Skill 可多次触发相同结果
|
||||
- 可自动执行：无需人工干预即可完成全流程
|
||||
|
||||
## Relationship to Prompt Engineering
|
||||
提示词工程优化单次输出质量，技能封装优化整套流程的稳定性与可复用性。
|
||||
|
||||
## Connections
|
||||
- [[流程工程]] ← 上位概念
|
||||
- [[Claude Skills]] ← 具体实现
|
||||
- [[Anthropic Skills 官方库]] ← 资源来源
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: AI搜索
|
||||
type: concept
|
||||
tags: [AI, 搜索, Search]
|
||||
aliases: [AI Search, AI搜索引擎]
|
||||
---
|
||||
|
||||
## 定义
|
||||
结合AI能力理解用户意图、直接提供整理好答案的搜索方式。
|
||||
|
||||
## 核心创新
|
||||
不返回链接列表，而是直接整理总结答案。
|
||||
|
||||
## 开源实现
|
||||
Perplexica：
|
||||
- 完全本地化部署
|
||||
- 接SearXNG避免Google API费用
|
||||
- 支持OpenAI API或本地大模型
|
||||
- 注重隐私保护
|
||||
|
||||
## Connections
|
||||
- [[AI搜索]] ← 基座 ← [[大语言模型]]
|
||||
- [[Perplexica]] ← 开源平替 ← [[Perplexity]]
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: AI数据处理
|
||||
type: concept
|
||||
tags: [AI, data-processing, LLM, workflow]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
通过大语言模型对采集的原始数据进行智能化处理，包括摘要、分类、特征提取、翻译、异常检测等，输出结构化数据供下游使用。
|
||||
|
||||
## 典型任务
|
||||
- **内容摘要**：产品描述压缩为 30 字摘要
|
||||
- **分类**：按类目/品牌/价格区间归类
|
||||
- **特征提取**：从非结构化文本提取品牌、型号、规格等字段
|
||||
- **多语言翻译**：产品信息翻译为多语言版本
|
||||
- **异常检测**：识别异常价格、缺图、缺失字段等
|
||||
|
||||
## 调用方式
|
||||
- **外部 API**：OpenAI GPT-4、Claude 等，高质量但有成本
|
||||
- **本地模型**：[Ollama] + Llama3/Mistral，免费但需 GPU/CPU 资源
|
||||
|
||||
## 在 Wiki 中的角色
|
||||
- [[可自动化可扩展AI增强的电商数据采集与处理系统]] AI 处理层
|
||||
- [[n8n Workflow自动化]] 通过 HTTP Request Node 调用 [[Ollama]] 本地模型
|
||||
|
||||
## n8n 集成示例
|
||||
```
|
||||
Prompt: "从以下JSON中提取每个产品的简短摘要（不超过30字）并分类。输入：{{$json['title']}}，价格：{{$json['price']}}，评分：{{$json['rating']}}"
|
||||
```
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: "AI时代赚钱三原则"
|
||||
type: concept
|
||||
tags: [ai-era, wealth, taste, end-to-end, death-filter, entrepreneurship]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## 定义
|
||||
以乔布斯视角提出的 AI 时代赚钱思维框架，核心是「品味值钱、做端到端、用死亡过滤器筛选热爱」。
|
||||
|
||||
## 三原则
|
||||
|
||||
### 1. 品味值钱
|
||||
- AI 工具民主化后，90% 的人用 AI 生成的是 shit
|
||||
- 品味 = 判断什么是真正好的（insanely great）的能力
|
||||
- 能从 AI 给的 10 个方案里判断哪个是最好的，就比只会点"生成"的人强一百倍
|
||||
- **品味是护城河**
|
||||
|
||||
### 2. 端到端做事
|
||||
- 别做别人 AI 流水线上的螺丝钉
|
||||
- 做从 idea 到 product 的完整闭环
|
||||
- 一个人用 AI 做完整 App，比在 100 人团队当"AI 提示词工程师"强一万倍
|
||||
- **端到端优于零件**
|
||||
|
||||
### 3. 死亡过滤器
|
||||
- 每天问自己：如果今天是最后一天，我还会做今天要做的事吗？
|
||||
- 如果答案 No，说明这不是真正热爱的事
|
||||
- **用死亡过滤器筛选真正的热爱**
|
||||
|
||||
## 正确问题框架
|
||||
- ❌ 错误：「普通人怎么在AI时代赚钱」（被动挨打）
|
||||
- ✅ 正确：「AI 让我能做到什么以前做不到的事」（主动创造）
|
||||
|
||||
## 与一人公司的关系
|
||||
AI 时代赚钱三原则是一人公司框架（[[天才地带]] + [[产品漏斗]] + [[内容矩阵]]）的思维基础。
|
||||
|
||||
## Connections
|
||||
- [[AI时代赚钱三原则]] ← 来源 ← [[乔布斯.skill]]
|
||||
- [[品味]] ← 原则一 ← [[AI时代赚钱三原则]]
|
||||
- [[端到端]] ← 原则二 ← [[AI时代赚钱三原则]]
|
||||
- [[死亡过滤器]] ← 原则三 ← [[AI时代赚钱三原则]]
|
||||
- [[一人公司]] ← 上层框架 ← [[AI时代赚钱三原则]]
|
||||
@@ -1,21 +0,0 @@
|
||||
---
|
||||
title: AI生图
|
||||
type: concept
|
||||
tags: [AI, 生图, 扩散模型]
|
||||
aliases: [AI Image Generation, AI绘图]
|
||||
---
|
||||
|
||||
## 定义
|
||||
利用扩散模型等AI技术根据文本提示生成图像的技术。
|
||||
|
||||
## 2025年格局
|
||||
- 闭源顶流：Nano Banana、Midjourney V7
|
||||
- 开源主导：Flux、Stable Diffusion 3.5
|
||||
|
||||
## 开源核心能力
|
||||
- Flux：人体解剖学最正确，能精准在图中写单词
|
||||
- Stable Diffusion：LoRA和ControlNet生态最丰富，适合动漫角色和姿势控制
|
||||
|
||||
## Connections
|
||||
- [[AI生图]] ← 依赖 ← [[大语言模型]]
|
||||
- [[Flux]] ← 竞争 ← [[Stable Diffusion]]
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: AI生视频
|
||||
type: concept
|
||||
tags: [AI, 视频生成]
|
||||
aliases: [AI Video Generation]
|
||||
---
|
||||
|
||||
## 定义
|
||||
根据文本提示生成视频内容的AI技术。
|
||||
|
||||
## 2025年格局
|
||||
- 闭源顶流：Google Veo 3
|
||||
- 国内可灵、海螺、即梦
|
||||
- 开源最强：HunyuanVideo
|
||||
|
||||
## 开源关键指标
|
||||
- 参数量：HunyuanVideo是开源界最大之一
|
||||
- 中文Prompt理解：天花板级别
|
||||
- 动作连贯性：极强，符合物理直觉
|
||||
|
||||
## Connections
|
||||
- [[AI生视频]] ← 依赖 ← [[大语言模型]]
|
||||
- [[HunyuanVideo]] ← 开源平替 ← [[Veo 3]]
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: AI知识库
|
||||
type: concept
|
||||
tags: [AI, 知识库, 学习]
|
||||
aliases: [AI Knowledge Base, 知识管理]
|
||||
---
|
||||
|
||||
## 定义
|
||||
利用AI技术管理和利用知识文档的系统。
|
||||
|
||||
## 代表产品
|
||||
Google NotebookLM：
|
||||
- 核心创新：双人播客功能
|
||||
- 将文档转为生动播客
|
||||
- 2024年底爆火，2025年封神
|
||||
|
||||
## 开源生态
|
||||
GitHub上有七八个NotebookLM相关开源项目。
|
||||
|
||||
## Connections
|
||||
- [[AI知识库]] ← 基座 ← [[大语言模型]]
|
||||
- [[NotebookLM]] → 开源平替 → [[OpenNotebookLM]]
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
title: "AI 结对执行"
|
||||
type: concept
|
||||
tags: [vibe-coding, AI, pair-programming]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AI 结对执行（AI Pair Programming）是 Vibe Coding 范式的第三原则：开发者扮演导演角色，AI 扮演执行者角色，类似结对编程（Pair Programming）但人类提供方向判断和审美决策，AI 负责具体实现。
|
||||
|
||||
## Human vs AI Responsibilities
|
||||
| 角色 | 人类（导演） | AI（执行者） |
|
||||
|------|------------|-------------|
|
||||
| 架构决策 | ✅ | ❌ |
|
||||
| 需求理解 | ✅ | ✅（辅助澄清） |
|
||||
| 代码编写 | ❌ | ✅ |
|
||||
| 测试验证 | ✅（审查） | ✅（自测脚本） |
|
||||
| 审美判断 | ✅ | ❌ |
|
||||
| Bug 修复 | ✅（引导） | ✅（执行） |
|
||||
|
||||
## Tools That Enable It
|
||||
- **Cursor**：Composer 模型支持多文件编辑和 AI 对话
|
||||
- **Windsurf**：Tab 自动补全 + AI 建议
|
||||
- **Trae**：Remote SSH 开发环境
|
||||
- **Claude Code**：Print Mode 非交互批量执行
|
||||
|
||||
## Relationship to Vibe Coding Formula
|
||||
Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行
|
||||
- 规划驱动：确定做什么
|
||||
- 上下文固定：保证 AI 不跑偏
|
||||
- AI 结对执行：具体怎么做
|
||||
|
||||
## Related Concepts
|
||||
- [[Vibe Coding]]：AI 结对执行是 Vibe Coding 三要素之一
|
||||
- [[规划驱动]]：结对前的人类准备工作
|
||||
- [[上下文固定]]：结对时的行为约束机制
|
||||
- [[Cursor]]：AI 结对执行的首选 IDE
|
||||
|
||||
## Aliases
|
||||
- AI Pair Programming
|
||||
- 氛围结对
|
||||
- 导演模式
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: AI编程
|
||||
type: concept
|
||||
tags: [AI, 编程, Coding]
|
||||
aliases: [AI Coding, AI辅助编程]
|
||||
---
|
||||
|
||||
## 定义
|
||||
利用AI辅助或自主完成代码编写、调试、重构的技术。
|
||||
|
||||
## 2025年格局
|
||||
- 终端AI Agent：Claude Code、Codex
|
||||
- IDE集成：Cursor
|
||||
- 开源平替：Cline
|
||||
|
||||
## Cline核心机制
|
||||
- 嵌入VS Code工作流
|
||||
- 深度理解项目上下文
|
||||
- 自动读取/修改文件
|
||||
- 支持MCP扩展
|
||||
- 敏感操作需用户授权
|
||||
|
||||
## Connections
|
||||
- [[AI编程]] ← 基座 ← [[大语言模型]]
|
||||
- [[Cline]] ← 开源平替 ← [[Cursor]]
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "AI配音"
|
||||
type: concept
|
||||
tags: [ai-voice, tts, content-creation]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
文字转语音（Text-to-Speech）技术，通过AI生成带自然情感的人类语音，广泛应用于视频旁白、有声书、游戏配音等场景。
|
||||
|
||||
## Core Capabilities
|
||||
- 文字转语音（TTS）
|
||||
- 多语言/多方言支持
|
||||
- 情感控制（开心/生气/平静等）
|
||||
- 声音克隆（用少量样本复制特定音色）
|
||||
|
||||
## Tool Landscape（2025年主流）
|
||||
| 层级 | 工具 | 特点 |
|
||||
|------|------|------|
|
||||
| 国际顶流 | [[ElevenLabs]] | 30+语言，情感丰富，API灵活 |
|
||||
| 国内免费 | [[海螺AI]] | MiniMax出品，30秒克隆，免费 |
|
||||
| 开源本地 | [[F5-TTS]] | 2秒克隆，开源MIT，数据安全 |
|
||||
| 打工人必备 | TTSMaker | 3万字/周，商用免费，无需注册 |
|
||||
| 短视频集成 | 剪映 | 抖音官方，小帅小美音色，VIP |
|
||||
| 企业级 | 魔音工坊 | 500+音色，明星声音模仿，会员制 |
|
||||
|
||||
## Selection Framework
|
||||
- 追求高品质 → ElevenLabs
|
||||
- 日常免费 → 海螺AI/TTSMaker/AnyVoice
|
||||
- 技术流/企业 → F5-TTS本地部署
|
||||
- 短视频新手 → 剪映
|
||||
|
||||
## Related Concepts
|
||||
- [[声音克隆]]：AI配音的高级能力，3秒到30秒样本即可克隆
|
||||
- [[AI生视频]]：AI配音的下一个链路——视频+配音=完整内容
|
||||
|
||||
## Source
|
||||
- [[二创视频必不可少-AI配音声音克隆]]
|
||||
22
wiki/concepts/AWS-Cloud-Adoption-Framework.md
Normal file
22
wiki/concepts/AWS-Cloud-Adoption-Framework.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "AWS Cloud Adoption Framework"
|
||||
type: concept
|
||||
tags: [Cloud, Framework, AWS]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
AWS Cloud Adoption Framework（AWS CAF）是一种帮助组织识别和优先处理转型机会、增强云就绪度的框架。
|
||||
|
||||
## Definition
|
||||
AWS CAF 提供最佳实践指导，帮助组织逐步完善转型路线图。
|
||||
|
||||
## Key Capabilities
|
||||
- 识别和优先处理转型机会
|
||||
- 增强云就绪度
|
||||
- 逐步完善转型路线图
|
||||
- AWS 特定的术语和实践
|
||||
|
||||
## Connections
|
||||
- [[AWS-Cloud-Adoption-Framework]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "AWS Organizations"
|
||||
type: concept
|
||||
tags: [aws, governance, multi-account, security]
|
||||
date: 2025-10-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
AWS Organizations，AWS 账户集中管理服务，通过组织单位（OU）树形结构对多个 AWS 账户进行分组治理，实现统一策略管理、账单整合和跨账户服务委托。
|
||||
|
||||
## Key Properties
|
||||
- **组织单元（OU）**：账户的逻辑分组，支持嵌套，策略继承
|
||||
- **服务控制策略（SCP）**：在 OU 或账户级别限制 IAM 权限，超越账户内 IAM 策略
|
||||
- **可信访问（Trusted Access）**：授权 AWS 服务（如 StackSets）跨账户AssumeRole，无需手动配置
|
||||
- ** delegated administrator**：为特定服务指定委派管理员账户
|
||||
|
||||
## Multi-Account DevOps Role
|
||||
StackSets 集中日志方案依赖：
|
||||
- 启用 StackSets 可信访问（Organization 级别授权）
|
||||
- 指定管理账户为 delegated administrator
|
||||
- OU ID 作为 StackSets 部署目标范围
|
||||
|
||||
## Related Concepts
|
||||
- [[CloudFormation StackSets]]：依赖 Organizations 实现跨账户授权
|
||||
- [[Multi-Cloud-Governance]]：Organizations 是 AWS 侧多账户治理的核心框架
|
||||
- [[Zero-Trust]]：Organizations + SCP 是 Zero Trust 在 AWS 环境的策略实施层
|
||||
|
||||
## Source
|
||||
[[AWS-CloudFormation-StackSets-多账户集中日志监控]]
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
title: "Agent Skill 设计模式"
|
||||
type: concept
|
||||
tags: [agent, skill, design-pattern]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
# Agent Skill 设计模式
|
||||
|
||||
## 定义
|
||||
Google 发布的 5 种 Skill 内容结构化设计模式，用于解决 SKILL.md 格式标准化后执行效果差异大的问题。
|
||||
|
||||
## 5 种模式
|
||||
|
||||
### 1. Tool Wrapper
|
||||
- **用途**：让 agent 快速成为某个领域专家
|
||||
- **机制**：监听特定库关键词，动态加载规范文档
|
||||
- **适用**：团队内部编码规范、特定框架最佳实践
|
||||
|
||||
### 2. Generator
|
||||
- **用途**：从模板生成结构化输出
|
||||
- **机制**："填空"流程，assets/ 模板 + references/ 样式指南
|
||||
- **适用**：统一 API 文档、标准化 commit 信息、脚手架项目
|
||||
|
||||
### 3. Reviewer
|
||||
- **用途**：把检查清单和检查逻辑分开
|
||||
- **机制**：审查标准存放在 references/review-checklist.md，换清单即换审计类型
|
||||
- **适用**：代码审查、安全审计、合规检查
|
||||
|
||||
### 4. Inversion
|
||||
- **用途**：agent 先问你再做
|
||||
- **机制**：通过不可协商的门控指令逐阶段收集信息
|
||||
- **适用**：项目规划、需求收集
|
||||
|
||||
### 5. Pipeline
|
||||
- **用途**：带硬性检查点的严格工作流
|
||||
- **机制**：明确前置条件和门控条件，强制顺序执行
|
||||
- **适用**：复杂任务、文档流水线、多阶段生成
|
||||
|
||||
## 模式组合
|
||||
- Pipeline 可包含 Reviewer 步骤（double-check 成果）
|
||||
- Generator 可依赖 Inversion 收集缺失变量
|
||||
|
||||
## Anthropic 补充
|
||||
- 最好的 Skill 不是"写好的提示词"，而是"工具箱"
|
||||
- Skill = 说明书 + SOP
|
||||
- 写 Skill 三条铁律：只写 Agent 不知道的东西、重点写踩坑清单、给工具不给指令
|
||||
|
||||
## Connections
|
||||
- [[Tool Wrapper]]：模式之一
|
||||
- [[Generator]]：模式之一
|
||||
- [[Reviewer]]：模式之一
|
||||
- [[Inversion]]：模式之一
|
||||
- [[Pipeline]]：模式之一
|
||||
- [[渐进式披露]]：ADK 机制支撑
|
||||
- [[AI技能封装]]：相关领域
|
||||
@@ -1,34 +1,32 @@
|
||||
---
|
||||
title: "Agentic AI"
|
||||
type: concept
|
||||
tags: [ai-agent, autonomy]
|
||||
last_updated: 2026-04-15
|
||||
tags: [AI, Autonomous-AI, Agentic-AI]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
能感知环境、做出决策、预判需求并自主采取行动的 AI 系统。与 GenAI（生成内容）的被动响应不同，Agentic AI 强调行动导向，与环境持续交互。
|
||||
## Summary
|
||||
Agentic AI（智能体 AI）是指具备自主决策和任务执行能力的 AI 系统，能够在没有人类干预的情况下完成复杂任务。
|
||||
|
||||
## Core Loop
|
||||
1. **感知（Perceive）**：获取任务，扫描环境上下文
|
||||
2. **思考（Reason）**：使用 LLM 进行推理，制定行动计划
|
||||
3. **行动（Act）**：调用工具（API、代码、数据库）
|
||||
4. **观察（Observe）**：将行动结果加入上下文，循环迭代
|
||||
## Definition
|
||||
具备自主决策、规划和执行能力的 AI 系统，可感知环境、制定计划并自动执行任务以达成目标。
|
||||
|
||||
## Key Characteristics
|
||||
- 主动性：预判用户需求而非被动响应
|
||||
- 自主性：在无人工干预下完成任务循环
|
||||
- 上下文感知：整合环境信息和历史记忆
|
||||
- **自主决策**：无需人类干预即可做出决策
|
||||
- **任务执行**：自动执行多步骤复杂工作流
|
||||
- **环境感知**：感知和理解运行环境状态
|
||||
- **自我修复**：检测异常并自动修复问题
|
||||
- **持续学习**：从历史数据学习并优化决策
|
||||
|
||||
## Relationship to Other Concepts
|
||||
- [[GenAI]]：Agentic AI 的内容生成基础
|
||||
- [[RAG]]：为 Agentic AI 提供实时信息获取能力
|
||||
- [[LLM]]：Agentic AI 的"大脑"，提供推理能力
|
||||
## Key Applications in Cloud DevOps
|
||||
- 自主事件检测与响应（MTTR 缩短）
|
||||
- 智能成本优化（动态扩缩、Spot 实例优化）
|
||||
- 自动化安全审计与合规执行
|
||||
- 智能日志分析与可观测性
|
||||
- AI 辅助决策（What-If 模拟）
|
||||
|
||||
## Related Concepts
|
||||
- [[AI Agent 设计原则]]：透明度、控制感、个性化、对话、预判
|
||||
- [[Multi Agent Hierarchy]]：多 Agent 协作架构之一
|
||||
|
||||
## Aliases
|
||||
- AI Agent
|
||||
- 智能体
|
||||
- 自主AI
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[Agentic AI]]：Agentic AI 扩展 DevOps 自动化能力
|
||||
- [[Cloud Security]] ← enhanced_by ← [[Agentic AI]]：Agentic AI 增强云安全自动化
|
||||
- [[Auto-scaling]] ← extends ← [[Agentic AI]]：Agentic AI 提供更智能的动态扩缩
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "Agent模式"
|
||||
type: concept
|
||||
tags: [cursor, mcp, ai-agent]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
# Agent模式
|
||||
|
||||
## 定义
|
||||
Cursor Composer 中的自动执行模式，可自动调用 MCP 工具链完成任务。
|
||||
|
||||
## 与 Normal 模式对比
|
||||
| 特性 | Agent 模式 | Normal 模式 |
|
||||
|------|-----------|-------------|
|
||||
| 命令执行 | 自动执行 | 手动复制 |
|
||||
| 工具调用 | 工具链自动串联 | 单步手动触发 |
|
||||
| 效率 | 高 | 低 |
|
||||
| 风险 | 可能误操作 | 可控 |
|
||||
|
||||
## 风险提示
|
||||
- "enable yolo mode" 开启后会默认执行所有命令，可能造成误操作
|
||||
- 建议默认关闭
|
||||
|
||||
## Connections
|
||||
- [[Composer]]：所属模块
|
||||
- [[Cursor]]：所属平台
|
||||
- [[MCP工具链]]：调用对象
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: Agile
|
||||
type: concept
|
||||
tags: [敏捷, 软件工程, 方法论, 迭代开发]
|
||||
sources: ["sources/DevOps-Culture-and-Transformation.md"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
Agile（敏捷）是一类迭代式软件开发方法论，强调适应性规划、快速交付、跨职能协作和持续改进。2001 年发布的《敏捷宣言》奠定了其核心理念。
|
||||
|
||||
## 核心价值观
|
||||
- 个体与交互高于流程与工具
|
||||
- 可工作软件高于详尽文档
|
||||
- 客户协作高于合同谈判
|
||||
- 响应变化高于遵循计划
|
||||
|
||||
## 主流框架
|
||||
- **Scrum**：结构化冲刺（sprint）管理，适合固定迭代周期
|
||||
- **Kanban**：可视化持续流管理，适合持续交付场景
|
||||
- **SAFe (Scaled Agile Framework)**：大规模敏捷框架
|
||||
|
||||
## 与 DevOps 的关系
|
||||
- Agile 聚焦于开发侧的迭代管理
|
||||
- [[DevOps]] 将 Agile 的迭代理念延伸至运维全生命周期
|
||||
- [[CI/CD Pipelines]] 是 Agile 实践的自动化加速器
|
||||
- Shift-Left 实践将运营考量前置到开发阶段
|
||||
|
||||
## 关键实践
|
||||
- 迭代式开发与定期演示
|
||||
- 每日站会（Daily Standup）
|
||||
- 回顾会议（Retrospective）
|
||||
- Sprint 规划与回顾
|
||||
|
||||
## Aliases
|
||||
- Agile
|
||||
- 敏捷开发
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: "Anthropic Skills 官方库"
|
||||
type: concept
|
||||
tags: [anthropic, claude, skill, github, open-source]
|
||||
last_updated: 2026-01-08
|
||||
---
|
||||
|
||||
## Definition
|
||||
Anthropic 官方在 GitHub 发布的 Skills 仓库（github.com/anthropics/skills），收藏数突破 3.2 万，原封不动地拆解了 Claude.ai 网页版的生产级能力。
|
||||
|
||||
## Source
|
||||
- GitHub: https://github.com/anthropics/skills
|
||||
|
||||
## Core Content
|
||||
|
||||
### 三大类别
|
||||
|
||||
#### 1. 办公自动化四大件（Office Suite）
|
||||
- Word/PDF/PPT/Excel 的创建、编辑、分析、重写
|
||||
- 格式控制、边界处理、容错策略
|
||||
- 每一步包含 Prompt 结构、参数含义
|
||||
|
||||
#### 2. 开发者工具箱（Developer Tools）
|
||||
- MCP Server
|
||||
- Web 应用测试
|
||||
- Artifacts 构建
|
||||
- 自动化验证流程
|
||||
|
||||
#### 3. 创意类 Skills（Creative）
|
||||
- 算法艺术
|
||||
- Canvas 设计
|
||||
- 主题生成工厂
|
||||
- 重点：设计思路可复用、输入约束、输出稳定
|
||||
|
||||
## Key Value
|
||||
"它是 Anthropic 把 Claude 线上真正在跑的生产级能力，原封不动地拆解开来，摊在桌面上给你看。"
|
||||
|
||||
本质上是官方在教你"怎么像我们一样开发 AI 应用"。
|
||||
|
||||
## Connections
|
||||
- [[Anthropic]] ← 发布者
|
||||
- [[Claude Skills]] ← 具体实现
|
||||
- [[Awesome-Claude-Skills]] ← 第三方精选仓库
|
||||
25
wiki/concepts/Auto-scaling.md
Normal file
25
wiki/concepts/Auto-scaling.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Auto-scaling
|
||||
type: concept
|
||||
tags: [Cloud, Cost-Optimization, Elasticity]
|
||||
sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md, How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
自动扩展（Auto-scaling）是一种根据实时负载自动调整计算资源的技术，确保系统在高峰期有足够资源，在低峰期避免资源浪费。
|
||||
|
||||
## Core Features
|
||||
- 动态资源分配：根据负载自动增减实例
|
||||
- 成本优化：在低需求时自动缩减资源
|
||||
- 性能保障：在高负载时自动扩容
|
||||
- 预测性扩展：基于历史数据预测未来需求
|
||||
|
||||
## Key Claims
|
||||
- 自动扩展是降低云成本的关键策略之一
|
||||
- 云平台提供灵活的定价，配合自动扩展帮助企业实现成本效益
|
||||
|
||||
## Connections
|
||||
- [[Pay-as-you-go]] ← optimizes ← [[Auto-scaling]]：自动扩展优化按需付费成本
|
||||
- [[Cloud-Native]] ← uses ← [[Auto-scaling]]：云原生应用广泛使用自动扩展
|
||||
- [[IaaS]] ← provides ← [[Auto-scaling]]：IaaS 提供自动扩展功能
|
||||
22
wiki/concepts/Azure-Cloud-Adoption-Framework.md
Normal file
22
wiki/concepts/Azure-Cloud-Adoption-Framework.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Azure Cloud Adoption Framework"
|
||||
type: concept
|
||||
tags: [Cloud, Framework, Azure]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
Azure Cloud Adoption Framework（Azure CAF）是微软 Azure 的云采纳框架，提供针对 Azure 的指导和最佳实践。
|
||||
|
||||
## Definition
|
||||
Azure CAF 使组织能够采用云技术并有信心地实现业务目标。
|
||||
|
||||
## Key Capabilities
|
||||
- 针对 Azure 的定制指导
|
||||
- 最佳实践
|
||||
- 业务目标对齐
|
||||
- 迁移支持
|
||||
|
||||
## Connections
|
||||
- [[Azure-Cloud-Adoption-Framework]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "BBR"
|
||||
type: concept
|
||||
tags: [networking, tcp, performance]
|
||||
sources: []
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
BBR（ Bottleneck Bandwidth and Round-trip propagation time）是 Google 开发的 TCP 拥塞控制算法，通过实时探测带宽和延迟调整发送速率，提升网络传输性能。
|
||||
|
||||
## Core Attributes
|
||||
- 开发者：Google
|
||||
- 类型：TCP 拥塞控制算法
|
||||
- 启用方式：3X-UI 面板选项 23
|
||||
- 作用：提升跨境网络传输速度
|
||||
|
||||
## Mechanism
|
||||
BBR 通过两个核心指标调整发送行为：
|
||||
1. Bottleneck Bandwidth（瓶颈带宽）
|
||||
2. Round-trip propagation time（往返传播时间）
|
||||
|
||||
相比传统 Cubic 算法，BBR 在高延迟高带宽网络中表现更优。
|
||||
|
||||
## Connections
|
||||
- [[BBR]] ← enabled_by ← [[3X-UI]]
|
||||
@@ -1,27 +0,0 @@
|
||||
# Bandwagon Effect
|
||||
|
||||
## Definition
|
||||
A psychological phenomenon where people adopt beliefs or actions because they see others doing the same, regardless of the underlying evidence. In multi-agent systems, it causes agents to converge on popular answers rather than independently reasoning to correct conclusions.
|
||||
|
||||
## Risk in Multi-Agent Consensus
|
||||
- Agents may be influenced by implicit ordering or presentation of options
|
||||
- If one answer appears first or is more salient, later agents may favor it
|
||||
- The effect can override actual reasoning
|
||||
- Correlated responses reduce the benefit of voting
|
||||
|
||||
## Prevention
|
||||
- Ensure agents are truly independent (no feedback loops)
|
||||
- Present information in randomized order where applicable
|
||||
- Use diverse models with different training to reduce shared biases
|
||||
- Treat the consensus as a blind experiment — agents don't know they're voting
|
||||
|
||||
## Key Principle
|
||||
- Diversity in human systems helps solve novel problems
|
||||
- The same applies to LLM ensembles
|
||||
- Different models, different fine-tuning, different prompts
|
||||
- Maximize variance in responses for maximum cancellation of noise
|
||||
|
||||
## Related Concepts
|
||||
- [[Groupthink]]
|
||||
- [[Multi-Agent Consensus]]
|
||||
- [[Sycophancy]]
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: Bind-Mount
|
||||
title: "Bind Mount"
|
||||
type: concept
|
||||
tags: [docker, storage, development]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Bind Mount（绑定挂载）是 Docker 的一种存储卷类型，将宿主机文件系统上的特定目录/文件直接映射到容器内，容器内对此路径的读写操作直接作用于宿主机文件系统，实现代码修改实时生效。
|
||||
|
||||
## vs Named Volume
|
||||
| 维度 | Bind Mount | Named Volume |
|
||||
|------|-----------|-------------|
|
||||
| 数据位置 | 宿主机任意路径 | Docker 管理（/var/lib/docker/volumes） |
|
||||
| 适用场景 | 开发（代码热更新） | 生产（数据持久化） |
|
||||
| 可移植性 | 依赖宿主机路径 | Docker 自动管理 |
|
||||
| 备份 | 随宿主机备份 | 需单独备份 |
|
||||
|
||||
## Use Case
|
||||
- 开发环境：宿主机源码目录挂载到容器内，修改文件无需重建镜像
|
||||
- 生产环境：使用 Named Volume 或直接使用 Synology NAS 存储路径
|
||||
|
||||
## Related Concepts
|
||||
- [[Docker Compose]]：定义 Bind Mount 的方式
|
||||
- [[Docker Attach模式]]：Attach 模式适合 Bind Mount 开发
|
||||
- [[Synology NAS]]：NAS 存储路径直接挂载到容器（/volume1/docker/...）
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Bugs First Policy"
|
||||
type: concept
|
||||
tags: [software-engineering, autonomous-agent, workflow]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
Agent 工作流中的强制优先级策略：任何新任务开始前，必须先检查并修复 bugs/ 目录下的第一个文件（按字母顺序），在修复完成前不允许处理任何新功能。
|
||||
|
||||
## Why It Works
|
||||
- 阻止 Agent 的"快速实现冲动"，强制回归稳定性
|
||||
- 每次修复后自然触发新一轮审查循环
|
||||
- 与人类开发中的"消防员模式"相同：最紧急的先处理
|
||||
|
||||
## Contrast
|
||||
| 模式 | 行为 |
|
||||
|------|------|
|
||||
| Bugs First | 停下所有新功能，只修 bugs/ 下第一个文件 |
|
||||
| Feature First | 优先实现新功能，bug 在 backlog 中积累 |
|
||||
|
||||
## Connections
|
||||
- [[Autonomous-Educational-Game-Development-Pipeline]]：强制使用此策略的项目
|
||||
- [[Self-Healing-Systems]]：类似自愈逻辑，但 Self-Healing 更广（不限 bug 修复）
|
||||
22
wiki/concepts/CAPEX-to-OPEX.md
Normal file
22
wiki/concepts/CAPEX-to-OPEX.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "CAPEX to OPEX"
|
||||
type: concept
|
||||
tags: [Cloud, Finance]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
CAPEX to OPEX（从资本支出到运营支出）是云采纳带来的财务模式转变。
|
||||
|
||||
## Definition
|
||||
传统 IT 采用资本支出（CAPEX）模式购买硬件，而云采纳转向运营支出（OPEX）模式按需付费使用服务。
|
||||
|
||||
## Key Benefits
|
||||
- 将固定成本转化为可变成本
|
||||
- 按需扩展
|
||||
- 无需前期大量投资
|
||||
- 通过云采纳管理成本
|
||||
|
||||
## Connections
|
||||
- [[CAPEX-to-OPEX]] ← enabled_by ← [[Cloud-Adoption]]
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: CI/CD Pipelines
|
||||
type: concept
|
||||
tags: [CI/CD, 自动化, 持续集成, 持续交付]
|
||||
sources: ["sources/DevOps-Culture-and-Transformation.md"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
CI/CD Pipelines（持续集成/持续交付流水线）是一套自动化流程，用于代码从提交到生产部署的全生命周期管理。
|
||||
|
||||
## 核心阶段
|
||||
1. **持续集成（CI）**：代码提交后自动触发构建、测试和集成
|
||||
2. **持续交付（CD）**：通过自动化部署将代码交付至预生产环境
|
||||
3. **持续部署（Continuous Deployment）**：全自动将代码部署至生产环境
|
||||
|
||||
## 关键工具
|
||||
- [[Jenkins]]：开源 CI/CD 自动化服务器
|
||||
- [[GitHub]] Actions：GitHub 内置 CI/CD
|
||||
- [[GitLab]] CI：GitLab 内置 CI/CD
|
||||
- [[Kubernetes]]：容器化应用编排平台
|
||||
- [[Docker]]：容器化 runtime
|
||||
|
||||
## 在 DevOps 中的角色
|
||||
- CI/CD 是 DevOps 自动化的核心引擎，将反馈周期从数周压缩至分钟级
|
||||
- 与 [[Agile]] 框架（Scrum/Kanban）协同，实现迭代式交付
|
||||
- 支撑 [[DevSecOps]]：安全扫描集成至流水线各阶段
|
||||
|
||||
## 关键指标
|
||||
- 部署频率（Deployment Frequency）
|
||||
- 变更前置时间（Lead Time for Changes）
|
||||
- 平均恢复时间（MTTR）
|
||||
- 变更失败率（Change Failure Rate）
|
||||
|
||||
## Aliases
|
||||
- CI/CD Pipelines
|
||||
- 持续集成/持续交付
|
||||
26
wiki/concepts/CI-CD-流水线.md
Normal file
26
wiki/concepts/CI-CD-流水线.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "CI/CD 流水线"
|
||||
type: concept
|
||||
tags: [devops, automation, continuous-integration, continuous-delivery]
|
||||
sources: [cloud-devop-maturity-guideline]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
CI/CD 流水线（持续集成/持续交付流水线）是自动化软件构建、测试和部署的流程管道，实现从代码提交到生产发布的全自动化。
|
||||
|
||||
## Components
|
||||
- **持续集成（CI）**：代码提交后自动构建、编译、单元测试
|
||||
- **持续交付（CD）**：通过自动化测试后将代码部署到预生产环境
|
||||
- **持续部署（Continuous Deployment）**：自动部署到生产环境
|
||||
|
||||
## Key Tools
|
||||
- [[Terraform]]：IaC 配置
|
||||
- [[Ansible]]：配置管理
|
||||
- [[Jenkins]]：（常见但未在本源文件中提及）
|
||||
- [[GitLab CI]]：（常见但未在本源文件中提及）
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← 技术基础 ← [[CI/CD 流水线]]
|
||||
- [[IaC]] ← 依赖 ← [[CI/CD 流水线]]
|
||||
- [[DORA 指标]] ← 受影响 ← [[CI/CD 流水线]]
|
||||
26
wiki/concepts/CMMI.md
Normal file
26
wiki/concepts/CMMI.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "CMMI"
|
||||
type: concept
|
||||
tags: [maturity-model, process-improvement, capability]
|
||||
sources: [cloud-devop-maturity-guideline]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是一套过程改进框架，用于评估和改进组织流程能力。
|
||||
|
||||
## Maturity Levels
|
||||
1. **初始级（Initial）**：过程不可预测，依赖个人能力
|
||||
2. **可管理级（Managed）**：过程已建立但依赖经验
|
||||
3. **已定义级（Defined）**：过程标准化和文档化
|
||||
4. **量化管理级（Quantitatively Managed）**：基于数据的量化管理
|
||||
5. **优化级（Optimizing）**：持续过程改进
|
||||
|
||||
## Relationship with DevOps
|
||||
- CMMI 是 DevOps 成熟度模型的先驱和理论基础
|
||||
- DevOps 成熟度模型借鉴了 CMMI 的分级方法论
|
||||
- CMMI 更通用，DevOps 成熟度模型更专注于交付实践
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← 借鉴 ← [[CMMI]]
|
||||
- [[DORA 指标]] ← 量化评估 ← [[CMMI]] 相关方法
|
||||
@@ -1,33 +0,0 @@
|
||||
# Cattle vs Pets
|
||||
|
||||
## Definition
|
||||
An SRE principle contrasting two approaches to managing compute resources. "Pets" are unique, manually nurtured servers treated as irreplaceable individuals. "Cattle" are identical, replaceable units that can be killed and regenerated without ceremony. The Knock-out multi-agent pattern applies this principle to LLM agents.
|
||||
|
||||
## Pets (Don't Do This)
|
||||
- Named, individual servers you care about personally
|
||||
- Hand-fed, manually configured, lovingly maintained
|
||||
- You try to heal them when sick
|
||||
- Failure of a pet is a crisis
|
||||
|
||||
## Cattle (Do This)
|
||||
- Identical, replaceable instances
|
||||
- No names, no emotional attachment
|
||||
- If one fails, you kill it and spin up a new one
|
||||
- Failure of cattle is routine — the system continues
|
||||
|
||||
## Application to LLM Agents
|
||||
- Don't name your agents or hope they "do well"
|
||||
- Spin up agent → check its work → kill it if it fails
|
||||
- Each agent is interchangeable with the next
|
||||
- The process (not the individual) is what matters
|
||||
|
||||
## Why This Matters
|
||||
- LLMs are inherently stochastic and unreliable
|
||||
- Treating them as pets leads to emotional attachment to broken processes
|
||||
- Enterprise AI needs reliability through architecture, not through hoping individual agents succeed
|
||||
- Kill failing agents quickly to reduce cost and noise
|
||||
|
||||
## Related Concepts
|
||||
- [[Multi-Agent Knock-out]]
|
||||
- [[LLM Reliability Engineering]]
|
||||
- [[Fitness Function]]
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "Claude Skills"
|
||||
type: concept
|
||||
tags: [claude, anthropic, skill, workflow]
|
||||
last_updated: 2026-01-08
|
||||
---
|
||||
|
||||
## Definition
|
||||
Claude Skills 是 Anthropic 官方发布的 AI 技能指南，本质是"写给 Claude 的说明书 + SOP（标准作业程序）"。
|
||||
|
||||
## Core Properties
|
||||
- **说明书**：清晰描述任务目标、输入约束、输出格式
|
||||
- **SOP**：将反复执行、有固定流程的任务拆解为 AI 可理解、稳定复用、自动执行的步骤
|
||||
- **可组合**：多个 Skills 可串联形成复杂工作流
|
||||
|
||||
## Key Distinction from Prompt Engineering
|
||||
| Prompt Engineering | Skills |
|
||||
|---|---|
|
||||
| 优化单次输出质量 | 优化整套流程的稳定性与可复用性 |
|
||||
| 依赖模型能力 | 结构化流程，降低模型依赖 |
|
||||
| 单点优化 | 系统化、工程化 |
|
||||
|
||||
## Official Resources
|
||||
- [[Anthropic Skills 官方库]]：github.com/anthropics/skills，3.2 万收藏
|
||||
- [[Awesome-Claude-Skills]]：ComposioHQ、VoltAgent、BehiSecc 维护的精选仓库
|
||||
- [[Skill 聚合站]]：skillsmp.com、aitmpl.com/skills、claudemarketplaces.com
|
||||
|
||||
## Connections
|
||||
- [[AI技能封装]] ← 具体实现
|
||||
- [[Prompt工程]] ← 范式升级来源
|
||||
- [[Anthropic Skills 官方库]] ← 官方资源
|
||||
- [[Agent Skill 设计模式]] ← 设计模式框架
|
||||
33
wiki/concepts/Cloud-Adoption.md
Normal file
33
wiki/concepts/Cloud-Adoption.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "Cloud Adoption"
|
||||
type: concept
|
||||
tags: [Cloud, Process]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Adoption（云采纳）是将工作负载和服务从本地基础设施迁移到云环境的过程。
|
||||
|
||||
## Definition
|
||||
云采纳涉及将应用程序、数据和工作负载从本地数据中心迁移到公有云、私有云或混合云环境。
|
||||
|
||||
## Key Stages
|
||||
根据 Cloud Maturity Model，云采纳分为 6 个成熟度等级：
|
||||
1. Level 0: 无云准备
|
||||
2. Level 1: 初始就绪
|
||||
3. Level 2: 可重复机会主义
|
||||
4. Level 3: 系统化和文档化
|
||||
5. Level 4: 可测量
|
||||
6. Level 5: 优化级
|
||||
|
||||
## Best Practices
|
||||
1. 设定清晰的云采纳目标
|
||||
2. 评估当前成熟度等级
|
||||
3. 选择合适的云成熟度模型
|
||||
4. 遵循治理和合规要求
|
||||
5. 实施安全和风险管理
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Maturity-Model]] ← defines ← [[Cloud-Adoption]]
|
||||
- [[Cloud-Adoption]] ← enables ← [[CAPEX-to-OPEX]]
|
||||
22
wiki/concepts/Cloud-Center-of-Excellence-CCOE.md
Normal file
22
wiki/concepts/Cloud-Center-of-Excellence-CCOE.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Cloud Center of Excellence (CCOE)"
|
||||
type: concept
|
||||
tags: [Cloud, Organization]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Center of Excellence（云卓越中心，CCOE）是推动云采纳和治理的核心组织单元。
|
||||
|
||||
## Definition
|
||||
CCOE 是一个专门的团队，负责制定云策略、标准和最佳实践，指导组织内的云采纳工作。
|
||||
|
||||
## Key Responsibilities
|
||||
- 建立云治理框架
|
||||
- 制定云标准和策略
|
||||
- 提供云专业知识
|
||||
- 支持云迁移项目
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Center-of-Excellence-CCOE]] ← supports ← [[Cloud-Maturity-Model]]
|
||||
51
wiki/concepts/Cloud-Computing.md
Normal file
51
wiki/concepts/Cloud-Computing.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Cloud Computing"
|
||||
type: concept
|
||||
tags: [Cloud, Computing-Model]
|
||||
sources: [Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained]
|
||||
last_updated: 2025-06-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Computing（云计算）是一种通过互联网远程访问计算资源（服务器、存储、应用程序）的服务模式，用户无需管理本地硬件。
|
||||
|
||||
## Definition
|
||||
云计算是指通过互联网（"云"）远程使用计算资源和服务的方式。应用程序、数据和处理都在第三方服务器上运行，用户通过终端设备访问。与传统本地部署相比，云计算具有弹性扩展、按需付费和免维护等优势。
|
||||
|
||||
## Key Characteristics
|
||||
- 远程访问：通过互联网连接使用
|
||||
- 资源共享：多个用户共享同一基础设施
|
||||
- 弹性扩展：根据需求快速增减资源
|
||||
- 按需付费：按实际使用量计费
|
||||
- 免维护：由服务商负责硬件管理和更新
|
||||
|
||||
## Service Models
|
||||
- [[IaaS]]（基础设施即服务）：提供虚拟计算资源
|
||||
- [[PaaS]]（平台即服务）：提供应用开发和部署平台
|
||||
- [[SaaS]]（软件即服务）：以订阅方式提供软件应用
|
||||
|
||||
## Deployment Models
|
||||
- [[Public-Cloud]]：公有云，共享交付
|
||||
- [[Private-Cloud]]：私有云，专属部署
|
||||
- [[Hybrid-Cloud]]：混合云，结合公有和私有云
|
||||
|
||||
## Shared Responsibility Model
|
||||
云计算采用共享责任模型：
|
||||
- 云服务商负责：基础设施运营、物理安全、服务器维护
|
||||
- 客户负责：访问权限管理、数据安全、加密、灾难恢复
|
||||
|
||||
## Key Drivers
|
||||
- 减少复杂性
|
||||
- 优化 DevOps
|
||||
- CapEx 转 OpEx
|
||||
- 为未来做准备
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Computing]] ← delivers ← [[IaaS]]
|
||||
- [[Cloud-Computing]] ← delivers ← [[PaaS]]
|
||||
- [[Cloud-Computing]] ← delivers ← [[SaaS]]
|
||||
- [[Cloud-Computing]] ← implements ← [[Public-Cloud]]
|
||||
- [[Cloud-Computing]] ← implements ← [[Private-Cloud]]
|
||||
- [[Cloud-Computing]] ← implements ← [[Hybrid-Cloud]]
|
||||
- [[Cloud-Computing]] ← enables ← [[Cloud-Migration]]
|
||||
- [[Cloud-Computing]] ← requires ← [[Cloud-Security]]
|
||||
52
wiki/concepts/Cloud-Maturity-Model.md
Normal file
52
wiki/concepts/Cloud-Maturity-Model.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Cloud Maturity Model"
|
||||
type: concept
|
||||
tags: [Cloud, Framework, Maturity-Model]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Maturity Model（云成熟度模型，CMM）是一种用于评估组织云采纳就绪程度的框架，适用于各种规模和云经验水平的组织。
|
||||
|
||||
## Definition
|
||||
CMM 通过 5 个等级帮助组织评估当前云采纳状态并规划迁移路径，同时覆盖业务和技术两大维度的多项能力领域。
|
||||
|
||||
## Key Components
|
||||
### 5 成熟度等级
|
||||
- **Level 0: No Cloud Readiness** — 无云准备，完全依赖遗留系统
|
||||
- **Level 1: Initial Readiness** — 初始就绪，有少量云服务使用但无清晰策略
|
||||
- **Level 2: Repeatable, opportunistic** — 可重复，已建立 IT 和采购流程
|
||||
- **Level 3: Systematic and Documented** — 系统化，有文档化实践和合规性
|
||||
- **Level 4: Measured** — 可测量，有透明治理模型
|
||||
- **Level 5: Optimized** — 优化级，开放互操作的云环境
|
||||
|
||||
### 业务能力领域 (16项)
|
||||
Finance、Enterprise Strategy、Organizational Structure、Culture、Governance、Skills、Compliance、Business Processes、Procurement、Commercial、Portfolio Management、Projects
|
||||
|
||||
### 技术能力领域 (18项)
|
||||
IT Architecture、Applications、Management Tools、Operations (IT) Processes、DevOps、Security、IaaS、PaaS、STaaS、SaaS、IPaaS、Information Services、Data、Network、AI、IoT、APIs
|
||||
|
||||
## Benefits
|
||||
1. 增强战略规划
|
||||
2. 改善团队沟通
|
||||
3. 提升应用性能
|
||||
4. 增强安全性和性能
|
||||
5. 缩短上市时间
|
||||
6. 行业基准对比
|
||||
7. 成本节约
|
||||
|
||||
## Best Practices
|
||||
1. 设定云采纳目标
|
||||
2. 确定当前成熟度等级
|
||||
3. 选择合适的云成熟度模型
|
||||
4. 遵循治理和合规
|
||||
5. 遵循安全和风险管理
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Maturity-Model]] ← extends ← [[Cloud-Security-Maturity-Model-CSMM]]
|
||||
- [[Cloud-Maturity-Model]] ← extends ← [[AWS-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Maturity-Model]] ← extends ← [[Azure-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Maturity-Model]] ← extends ← [[Google-Cloud-Adoption-Framework]]
|
||||
- [[Cloud-Center-of-Excellence-CCOE]] ← supports ← [[Cloud-Maturity-Model]]
|
||||
- [[Open-Alliance-for-Cloud-Adoption-OACA]] ← defines ← [[Cloud-Maturity-Model]]
|
||||
25
wiki/concepts/Cloud-Migration.md
Normal file
25
wiki/concepts/Cloud-Migration.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Cloud Migration
|
||||
type: concept
|
||||
tags: [Cloud, Migration, DevOps]
|
||||
sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
云迁移是指将工作负载、应用程序和数据从本地基础设施迁移到云环境的过程。
|
||||
|
||||
## Migration Strategies
|
||||
- 阶段式迁移（Phased Migration）：分阶段逐步迁移工作负载
|
||||
- 混合云迁移（Hybrid Cloud Migration）：保留部分本地工作负载
|
||||
- 云迁移服务（Cloud Migration Services）：专业迁移工具和支持
|
||||
|
||||
## Key Claims
|
||||
- 虽然迁移到云需要仔细规划，但云提供商提供广泛的工具和支持来促进这一过程
|
||||
- 阶段式迁移、混合云解决方案和专业云迁移服务有助于降低风险并确保平滑过渡
|
||||
- 借助正确的方法，企业可以以最小 disruption 将工作负载迁移到云
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Adoption]] ← includes ← [[Cloud-Migration]]：云采纳包含迁移阶段
|
||||
- [[Hybrid-Cloud]] ← uses ← [[Cloud-Migration]]：混合云是迁移策略之一
|
||||
- [[DevOps]] ← supports ← [[Cloud-Migration]]：DevOps 实践支持平滑迁移
|
||||
22
wiki/concepts/Cloud-Native.md
Normal file
22
wiki/concepts/Cloud-Native.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Cloud Native"
|
||||
type: concept
|
||||
tags: [Cloud, Architecture]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Native（云原生）是一种利用云平台原生特性构建和运行应用程序的方法论。
|
||||
|
||||
## Definition
|
||||
云原生应用充分利用云平台的动态特性，在公有云、私有云和混合云环境中运行。
|
||||
|
||||
## Key Characteristics
|
||||
- 容器化部署
|
||||
- 微服务架构
|
||||
- 动态管理
|
||||
- 利用 CNCF 生态系统
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Native]] ← part_of ← [[Cloud-Maturity-Model]]
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: Cloud-Operating-Model
|
||||
title: "Cloud Operating Model"
|
||||
type: concept
|
||||
tags: [cloud, governance, strategy]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
云运营模型（Cloud Operating Model，COM）是一套标准化框架，用于组织管理云资源、安全、自动化和成本，确保云投资有效、安全和可持续。
|
||||
|
||||
## Core Pillars
|
||||
1. **治理与合规**：安全策略、访问控制、合规政策
|
||||
2. **自动化与编排**：IaC、CI/CD、事件驱动自动化
|
||||
3. **安全与风险管理**：Zero Trust、实时威胁检测、自动化安全修复
|
||||
4. **云财务管理（FinOps）**：实时成本追踪、Reserved Instances、Auto-Scaling
|
||||
|
||||
## Maturity Levels
|
||||
- Ad-hoc Cloud Adoption：无清晰战略，成本和安全问题突出
|
||||
- Cloud-First Strategy：有定义的流程，但需优化
|
||||
- Cloud-Native Enterprise：自动化驱动，多云复杂性管理
|
||||
|
||||
## Key Quotes
|
||||
> "A Cloud Operating Model is no longer optional—it is the backbone of modern cloud strategy." — Bacancy Technology
|
||||
|
||||
## Related Concepts
|
||||
- [[FinOps]]：云财务管理
|
||||
- [[Zero Trust]]：零信任安全模型
|
||||
- [[Multi-Cloud]]：多云策略
|
||||
- [[DevOps]]：DevOps 文化与 COM 高度重叠
|
||||
19
wiki/concepts/Cloud-Security-Maturity-Model-CSMM.md
Normal file
19
wiki/concepts/Cloud-Security-Maturity-Model-CSMM.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "Cloud Security Maturity Model (CSMM)"
|
||||
type: concept
|
||||
tags: [Cloud, Security, Maturity-Model]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Security Maturity Model（云安全成熟度模型，CSMM）是一种评估云安全计划成熟度的框架。
|
||||
|
||||
## Definition
|
||||
CSMM 评估组织云安全在 12 个类别和 3 个不同领域中的成熟度水平，通常由 IANS 或 Securosis 提供。
|
||||
|
||||
## Key Domains
|
||||
CSMM 涵盖 12 个类别，分布在 3 个不同领域中。
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Security-Maturity-Model-CSMM]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
32
wiki/concepts/Cloud-Security.md
Normal file
32
wiki/concepts/Cloud-Security.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Cloud Security
|
||||
type: concept
|
||||
tags: [Cloud, Security, Compliance]
|
||||
sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
云安全是指保护云计算环境中的数据、应用程序和基础设施免受未经授权访问、泄露、盗窃和破坏的措施和技术的总称。
|
||||
|
||||
## Core Components
|
||||
- 加密（Encryption）：数据传输和存储加密
|
||||
- 防火墙（Firewall）：网络边界防护
|
||||
- 多因素认证（Multi-factor Authentication）：增强身份验证
|
||||
- 自动化安全更新：持续漏洞修复
|
||||
- 24/7 监控：实时威胁检测
|
||||
|
||||
## Compliance Standards
|
||||
- [[ISO-27001]]：信息安全管理系统国际标准
|
||||
- [[HIPAA]]：美国健康保险便携性和责任法案
|
||||
- [[GDPR]]：欧盟通用数据保护条例
|
||||
|
||||
## Key Claims
|
||||
- 云安全通常比本地解决方案更 robust，云提供商投入大量资源于安全措施
|
||||
- 许多云平台符合 ISO 27001、HIPAA、GDPR 等严苛行业标准
|
||||
- 云提供商提供自动化安全更新和 24/7 监控，降低违规风险
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Adoption]] ← depends_on ← [[Cloud-Security]]：云采纳必须以云安全为基础
|
||||
- [[Cloud-Security-Maturity-Model-CSMM]] ← related_to ← [[Cloud-Security]]：CSMM 是云安全成熟度评估框架
|
||||
- [[DevSecOps]] ← extends ← [[Cloud-Security]]：DevSecOps 在 CI/CD 中集成安全
|
||||
51
wiki/concepts/Cloud-Service-Delivery.md
Normal file
51
wiki/concepts/Cloud-Service-Delivery.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Cloud Service Delivery"
|
||||
type: concept
|
||||
tags: [Cloud, DevOps, Cloud Operations]
|
||||
sources: [What-I-know-about-Cloud-Service-Delivery-1]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
Cloud Service Delivery（云服务交付）是连接云技术能力（IaaS、PaaS、SaaS）与最终用户实际消费服务之间的桥梁，涵盖使云服务可操作、可访问、安全、高性能和有价值 的整个生命周期。
|
||||
|
||||
## Core Components（核心组成部分）
|
||||
|
||||
### Cloud Service Delivery Team Roles（团队角色）
|
||||
- Cloud Infrastructure Engineer
|
||||
- Cloud Operation Engineer (DevOps/SRE)
|
||||
- Cloud Security Specialists
|
||||
- Cloud Support Engineer
|
||||
- Cloud FinOps Engineer
|
||||
|
||||
### 12 Core Management Areas（12个核心管理领域）
|
||||
1. **Service Provisioning & Deployment**：服务配置与部署
|
||||
2. **Infrastructure Management**：基础设施管理
|
||||
3. **Platform Management (for PaaS)**：平台管理
|
||||
4. **Application Operations & Management**：应用运维管理
|
||||
5. **Security & Compliance Management**：安全与合规管理
|
||||
6. **Performance & Availability Monitoring**：性能与可用性监控
|
||||
7. **Incident & Problem Management**：事件与问题管理
|
||||
8. **Change & Configuration Management**：变更与配置管理
|
||||
9. **Cost Management & Optimization**：成本管理与优化
|
||||
10. **Customer Onboarding & Support**：客户支持与 onboarding
|
||||
11. **Service Governance & Lifecycle Management**：服务治理与生命周期管理
|
||||
12. **Backup, Recovery & Disaster Management**：备份恢复与灾难管理
|
||||
|
||||
## Related Concepts
|
||||
- [[DevOps]]：云服务交付的重要方法论基础
|
||||
- [[IaaS]]：云服务交付的底层服务模式
|
||||
- [[PaaS]]：云服务交付的平台层
|
||||
- [[SaaS]]：云服务交付的应用层
|
||||
- [[Cloud Native]]：云服务交付的目标架构状态
|
||||
- [[Cloud Maturity Model]]：评估云服务交付能力的成熟度框架
|
||||
- [[DevSecOps]]：云服务交付中安全管理的最佳实践
|
||||
- [[IaC]]：云服务交付中变更配置管理的核心方法
|
||||
|
||||
## Best Practices Mentioned（最佳实践）
|
||||
- AWS CloudWatch 作为 Grafana 的数据源进行监控
|
||||
- Service Availability Check 使用 APM/BPM、New Relic、AWS CloudWatch Synthetic、Health Page
|
||||
- WAF（Web Application Firewall）管理
|
||||
- IP 白名单支持到租户级别
|
||||
- Planned Change vs Emergency Change 区分
|
||||
- SLA 99.9% vs 99.99% 可用性对比（参考 uptime.is）
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "CloudFormation StackSets"
|
||||
type: concept
|
||||
tags: [aws, iac, devops, multi-account]
|
||||
date: 2025-10-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
AWS CloudFormation StackSets，允许在多个 AWS 账户和区域中通过单一操作创建、更新或删除 CloudFormation 堆栈的托管服务。管理员在管理账户定义模板，StackSets 自动将操作传播到指定的组织单位（OU）或账户列表。
|
||||
|
||||
## Key Properties
|
||||
- **跨账户/跨区域**：一张模板同时部署到多个目标账户和区域
|
||||
- **自动部署**：启用自动部署后，新增账户自动获得预定义资源
|
||||
- **故障容忍度**：parallel regions + fault tolerance 设置控制并发数
|
||||
- **服务托管（Service-Managed）**：使用 AWS Organizations 的服务委托角色，无需手动创建跨账户 IAM 角色
|
||||
|
||||
## Use Cases
|
||||
- 安全基线批量部署（安全组、Config Rules、SCP）
|
||||
- 合规性配置跨账户统一落地
|
||||
- 多账户监控、日志、网络基础设施一键部署
|
||||
|
||||
## Related Concepts
|
||||
- [[Infrastructure-as-Code]]：StackSets 是 IaC 在多账户场景的扩展
|
||||
- [[EventBridge]]：StackSets 操作生成事件，可被 EventBridge 规则捕获
|
||||
- [[AWS Organizations]]：StackSets 依赖组织框架进行跨账户授权
|
||||
|
||||
## Source
|
||||
[[AWS-CloudFormation-StackSets-多账户集中日志监控]]
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
title: "CloudWatch Logs Insights"
|
||||
type: concept
|
||||
tags: [aws, observability, logging, analytics]
|
||||
date: 2025-10-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
CloudWatch Logs Insights，CloudWatch Logs 的结构化查询引擎，提供类 SQL 查询语言对日志进行实时分析、可视化和告警配置。
|
||||
|
||||
## Key Properties
|
||||
- **查询语法**：`fields` + `filter` + `parse` + `sort` + `limit` 管道化组合
|
||||
- **跨账户查询**：可在管理账户跨所有成员账户查询集中日志
|
||||
- **结构化解析**：`parse` 命令支持正则表达式提取 JSON 嵌套字段（如 resource-type、status、logical-resource-id）
|
||||
- **可视化**：查询结果可直接绑定 CloudWatch Dashboard 图表
|
||||
|
||||
## Example Query（StackSets 场景）
|
||||
```
|
||||
fields @timestamp, account, region
|
||||
| parse @message /"resource-type":"(?<resource_type>[^"]+)"/
|
||||
| parse @message /"status":"(?<status>[^"]+)"/"
|
||||
| sort @timestamp desc
|
||||
```
|
||||
提取：时间戳、账户 ID、区域、资源类型、部署状态。
|
||||
|
||||
## Related Concepts
|
||||
- [[CloudWatch Logs]]：Logs Insights 的数据来源
|
||||
- [[可观测性]]：Logs Insights 是可观测性体系的核心查询层
|
||||
- [[CloudFormation StackSets]]：典型查询对象为 StackSets 部署事件
|
||||
|
||||
## Source
|
||||
[[AWS-CloudFormation-StackSets-多账户集中日志监控]]
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
title: "CloudWatch Logs"
|
||||
type: concept
|
||||
tags: [aws, observability, logging, devops]
|
||||
date: 2025-10-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Amazon CloudWatch Logs，AWS 日志存储与分析服务，支持从 AWS 服务、本地服务器、第三方应用收集日志，并以结构化或非结构化文本形式持久化。
|
||||
|
||||
## Key Properties
|
||||
- **日志组（Log Group）**：日志流的组织单元，可设置保留期和加密策略
|
||||
- **KMS 加密**：日志组可使用客户托管 KMS 密钥（CMK）加密，满足合规要求
|
||||
- **订阅过滤器（Subscription Filter）**：将日志实时流式传输至 Lambda、Kinesis Firehose 或第三方目标
|
||||
- **跨账户日志**：通过 CloudWatch Logs Insights 跨账户查询（Cross-Account Query）
|
||||
|
||||
## Use Cases in This Context
|
||||
- StackSets 场景：central-cloudformation-logs 日志组存储来自所有成员账户的 CloudFormation 事件
|
||||
- 与 [[EventBridge]] 配合，作为跨账户事件转发后的集中存储层
|
||||
- 通过 CloudWatch Logs Insights 提供跨账户查询能力
|
||||
|
||||
## Related Concepts
|
||||
- [[可观测性]]：CloudWatch Logs 是 Metrics/Logs/Traces 三大支柱之一
|
||||
- [[CloudWatch Logs Insights]]：结构化日志查询引擎
|
||||
- [[EventBridge]]：CloudWatch Logs 的事件来源之一
|
||||
|
||||
## Source
|
||||
[[AWS-CloudFormation-StackSets-多账户集中日志监控]]
|
||||
31
wiki/concepts/Compliance-Enforcement.md
Normal file
31
wiki/concepts/Compliance-Enforcement.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "Compliance Enforcement"
|
||||
type: concept
|
||||
tags: [security, compliance, automation]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
Compliance Enforcement（合规执行）是通过自动化工具持续监控和确保系统符合 SOC 2、FedRAMP、PCI DSS 等安全合规要求的实践。
|
||||
|
||||
## Definition
|
||||
自动化监控、检测和修复安全合规违规行为，确保系统始终符合监管要求。
|
||||
|
||||
## Key Frameworks
|
||||
- **SOC 2**：服务组织控制评估
|
||||
- **FedRAMP**：联邦风险和授权管理计划
|
||||
- **PCI DSS**：支付卡行业数据安全标准
|
||||
- **HIPAA**：美国健康保险便携性和责任法案
|
||||
- **GDPR**：欧盟通用数据保护条例
|
||||
|
||||
## Key Mechanisms
|
||||
- **持续监控**：实时检测合规违规
|
||||
- **自动修复**：违规发生时自动修复
|
||||
- **审计追踪**：记录所有合规相关活动
|
||||
- **报告生成**：自动生成合规报告
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← implements ← [[Compliance Enforcement]]：Agentic AI 实现自动化合规执行
|
||||
- [[DevSecOps]] ← extends ← [[Compliance Enforcement]]：DevSecOps 强调自动化合规
|
||||
- [[Cloud Security]] ← depends_on ← [[Compliance Enforcement]]：云安全依赖合规执行
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "Composer模型"
|
||||
type: concept
|
||||
tags: [ai, code-generation, cursor, llm]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
Cursor 自研的 AI 代码生成模型，主打生成速度优势，官方声称比其他同类模型快 4 倍。
|
||||
|
||||
## 核心特点
|
||||
- **速度优势**：4 倍生成速度，降低等待成本
|
||||
- **深度集成**：与 Cursor 编辑器深度绑定，支持多代理并行
|
||||
- **上下文感知**：基于整个项目文件结构生成代码
|
||||
|
||||
## 技术定位
|
||||
- [[Cursor]] 的核心 AI 能力
|
||||
- 属于通用代码生成模型，非垂直领域定制
|
||||
|
||||
## 关联
|
||||
- [[Composer模型]] ← 属于 ← [[Cursor]]
|
||||
- [[AI代码编辑器]] ← 增强 ← [[Composer模型]]
|
||||
|
||||
## Aliases
|
||||
- Cursor Composer
|
||||
- Cursor 自研模型
|
||||
|
||||
@@ -1,27 +0,0 @@
|
||||
# Context Drift
|
||||
|
||||
## Definition
|
||||
A failure mode in LLM interactions where the model gradually loses focus on the original task or context, veering off-topic as the conversation progresses. The LLM "forgets" the original goal and generates responses that may be locally coherent but globally irrelevant.
|
||||
|
||||
## Causes
|
||||
- Long conversations that exceed the model's effective context window
|
||||
- Cumulative token budget leading to attention dilution
|
||||
- Poor initial prompt definition
|
||||
- Model's tendency to follow the most recent instructions over original ones
|
||||
|
||||
## Impact on Multi-Agent Systems
|
||||
- Can propagate errors through agent chains
|
||||
- Workers in a Hierarchy may drift from Planner's intended tasks
|
||||
- Debates may veer off the original proposition being evaluated
|
||||
- Knock-out agents may lose sight of the evaluation criteria
|
||||
|
||||
## Mitigation
|
||||
- Break long tasks into atomic steps (Hierarchy pattern)
|
||||
- Use explicit task validation at each step
|
||||
- Keep agent contexts focused and limited
|
||||
- Reset context periodically rather than accumulating
|
||||
|
||||
## Related Concepts
|
||||
- [[Hallucination]]
|
||||
- [[Multi-Agent Hierarchy]]
|
||||
- [[Validator]]
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: "Conventional Commits"
|
||||
type: concept
|
||||
tags: [git, software-engineering, automation]
|
||||
date: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
语义化提交格式规范：`<type>: <description>`，其中 type 包括 feat/fix/docs/style/refactor/test/chore 等，描述用祈使语气。
|
||||
|
||||
## Example
|
||||
```
|
||||
feat: add memory search integration
|
||||
fix: resolve cron timezone issue
|
||||
chore: update dependencies
|
||||
```
|
||||
|
||||
## Why It Matters
|
||||
- 自动化 CHANGELOG 生成
|
||||
- 语义化版本管理（semver）
|
||||
- 人类和机器均可解析提交历史
|
||||
|
||||
## Connections
|
||||
- [[Autonomous-Educational-Game-Development-Pipeline]]：使用 conventional commits 生成 CHANGELOG
|
||||
- [[GitOps]]：Git 提交历史作为系统状态的审计日志
|
||||
25
wiki/concepts/Cost-Optimization.md
Normal file
25
wiki/concepts/Cost-Optimization.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Cost Optimization"
|
||||
type: concept
|
||||
tags: [cloud, cost-management, FinOps]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cost Optimization（成本优化）是通过策略和技术最大化云资源价值、减少不必要开销的实践。
|
||||
|
||||
## Definition
|
||||
在保持性能和可靠性的前提下，通过资源 rightsizing、自动扩缩、实例类型选择等方式降低云支出。
|
||||
|
||||
## Key Techniques
|
||||
- **AI-based Rightsizing**：AI 分析使用趋势，推荐合适大小的实例
|
||||
- **Spot Instance Optimization**：智能切换 Spot/Preemptible 实例
|
||||
- **Reserved Instance Planning**：优化预留实例购买策略
|
||||
- **Multi-Cloud Cost Governance**：跨云成本分析与优化
|
||||
- **存储优化**：识别和清理未使用存储
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← implements ← [[Cost Optimization]]：Agentic AI 实现智能成本优化
|
||||
- [[Pay-as-you-go]] ← optimizes ← [[Cost Optimization]]：成本优化提升按需付费效益
|
||||
- [[CAPEX to OPEX]] ← enables ← [[Cost Optimization]]：成本优化支持财务模式转型
|
||||
24
wiki/concepts/DORA-指标.md
Normal file
24
wiki/concepts/DORA-指标.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "DORA 指标"
|
||||
type: concept
|
||||
tags: [devops, metrics, performance-measurement]
|
||||
sources: [cloud-devop-maturity-guideline]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
DORA（DevOps Research & Assessment）指标是用于衡量组织 DevOps 性能和交付能力的关键度量标准。
|
||||
|
||||
## Four Key Metrics
|
||||
1. **部署频率（Deployment Frequency）**：代码部署到生产的频率
|
||||
2. **变更前置时间（Lead Time for Changes）**：从代码提交到生产部署的时间
|
||||
3. **变更失败率（Change Failure Rate）**：部署导致生产环境失败的比例
|
||||
4. **平均恢复时间（MTTR）**：Mean Time to Recovery，服务从故障中恢复的平均时间
|
||||
|
||||
## Significance
|
||||
- DORA 指标是评估 DevOps 成熟度的核心量化工具
|
||||
- 高绩效组织通常：部署频率高、前置时间短、变更失败率低、MTTR 短
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← 评估框架 ← [[DORA 指标]]
|
||||
- [[CI/CD 流水线]] ← 影响 ← [[DORA 指标]]
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "DORA指标 - DevOps效能四指标"
|
||||
type: concept
|
||||
tags: [DevOps, 效能, 指标]
|
||||
sources: ["DevOps Culture and Transformation", "Cloud DevOp Maturity - Guideline"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
DORA（DevOps Research and Assessment）四指标是衡量 DevOps 效能的核心量化框架，被 Google 团队研究成果验证。
|
||||
|
||||
## 四个核心指标
|
||||
1. **部署频率（Deployment Frequency）**：组织能多频繁地向用户交付新功能
|
||||
2. **变更前置时间（Lead Time for Changes）**：从代码提交到生产部署的时间
|
||||
3. **变更失败率（Change Failure Rate）**：部署失败的百分比
|
||||
4. **平均恢复时间（Mean Time to Recovery, MTTR）**：从故障恢复到服务正常的时间
|
||||
|
||||
## 精英团队特征
|
||||
- 部署频率：每天多次到每月多次
|
||||
- 变更前置时间：少于一天到一周
|
||||
- 变更失败率：0-15%
|
||||
- 平均恢复时间：少于一小时
|
||||
|
||||
## 在 Wiki 中的角色
|
||||
- 是 [[DevOps Culture and Transformation]] 和 [[Cloud-DevOp-Maturity-Guideline]] 的核心评估框架
|
||||
- 关联概念：[[Kaizen]]（持续改进）、[[CI/CD Pipelines]]
|
||||
26
wiki/concepts/Data-Governance.md
Normal file
26
wiki/concepts/Data-Governance.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Data Governance
|
||||
type: concept
|
||||
tags: [Cloud, Data-Management, Compliance]
|
||||
sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
数据治理是指在云环境中管理数据的安全性、完整性、可用性和合规性的框架和实践。
|
||||
|
||||
## Core Components
|
||||
- 权限管理（Access Control）：基于角色的数据访问控制
|
||||
- 数据加密（Encryption）：静态和动态数据加密
|
||||
- 访问日志监控（Access Logs）：追踪数据访问行为
|
||||
- 合规管理（Compliance Management）：满足法规要求
|
||||
- 数据存储位置控制（Data Residency）：控制数据地理存储位置
|
||||
|
||||
## Key Claims
|
||||
- 云服务提供强大的数据治理工具，允许组织管理权限、加密数据和监控访问日志
|
||||
- 许多云服务提供混合云和多云选项，使企业能够维持对数据存储位置和方式的控制
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Security]] ← depends_on ← [[Data-Governance]]：数据治理是云安全的核心组成部分
|
||||
- [[GDPR]] ← requires ← [[Data-Governance]]：GDPR 要求数据治理合规性
|
||||
- [[Hybrid-Cloud]] ← enables ← [[Data-Governance]]：混合云支持数据主权要求
|
||||
25
wiki/concepts/Data-Sovereignty.md
Normal file
25
wiki/concepts/Data-Sovereignty.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Data Sovereignty"
|
||||
type: concept
|
||||
tags: [Cloud, Compliance, Regulation]
|
||||
sources: [How-Can-a-Multi-Cloud-Strategy-Transform-Your-Business-ROI]
|
||||
last_updated: 2025-03-01
|
||||
---
|
||||
|
||||
## Summary
|
||||
Data Sovereignty（数据主权）是指数据受其存储所在国家或地区的法律法规约束的原则，强调政府对其境内数据的管辖权。
|
||||
|
||||
## Definition
|
||||
数据主权指数据应当受到其物理存储地点所属国家或地区法律法规约束的原则。不同地区对数据存储、访问、传输有不同规定，企业必须遵守当地合规要求。
|
||||
|
||||
## Key Examples
|
||||
- **GDPR（欧盟）**：要求数据在欧盟境内处理
|
||||
- **HIPAA（美国）**：医疗数据存储合规要求
|
||||
- **数据本地化法律**：某些国家要求数据必须存储在境内
|
||||
|
||||
## How Multi-Cloud Supports It
|
||||
多云策略允许企业选择在不同地区选择符合当地法规的云服务商，将数据存储在合规的数据中心，从而满足数据主权要求。
|
||||
|
||||
## Connections
|
||||
- [[Data Sovereignty]] ← addressed_by ← [[Multi-Cloud]]
|
||||
- [[Data Sovereignty]] → relates_to → [[Cloud Compliance]]
|
||||
@@ -1,28 +0,0 @@
|
||||
# Dependency Graph
|
||||
|
||||
## Definition
|
||||
A structure that enforces collaboration between agents in the Hierarchy pattern by making certain agents unable to start until others have completed. The Planner feeds tasks to Workers, and the Validator gates progress, creating a directed acyclic graph of dependencies.
|
||||
|
||||
## Role in Multi-Agent Hierarchy
|
||||
- Forces Workers to wait until Planner provides input
|
||||
- Prevents Workers from cheating or skipping steps
|
||||
- Validator catches any violations of the dependency order
|
||||
- Creates accountability through structural enforcement
|
||||
|
||||
## Key Properties
|
||||
- Workers literally cannot start until Planner feeds them
|
||||
- If Worker tries to skip or cheat, Validator catches it
|
||||
- Models collaborate not because they "like each other" but because the graph forces them to
|
||||
- Enables parallel execution where dependencies allow
|
||||
|
||||
## Why It Works
|
||||
- Instead of asking nicely ("please be careful"), architecture enforces correctness
|
||||
- No agent can proceed without completing its predecessors
|
||||
- The Validator verifies the chain at each step
|
||||
- Errors are caught early rather than propagating
|
||||
|
||||
## Related Concepts
|
||||
- [[Multi-Agent Hierarchy]]
|
||||
- [[Planner]]
|
||||
- [[Worker]]
|
||||
- [[Validator]]
|
||||
46
wiki/concepts/DevOps-成熟度模型.md
Normal file
46
wiki/concepts/DevOps-成熟度模型.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "DevOps 成熟度模型"
|
||||
type: concept
|
||||
tags: [DevOps, Maturity Model, Assessment]
|
||||
sources: [DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps, cloud-devop-maturity-guideline]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
DevOps 成熟度模型是一种用于评估组织 DevOps 实践水平的分级框架，通常包含五个阶段：从初始/应急阶段到完全成熟阶段。
|
||||
|
||||
## Definition
|
||||
DevOps 成熟度模型是一个结构化框架，用于指导组织采用和实施 DevOps 原则。该模型帮助组织评估当前的 DevOps 实践水平，识别改进领域，并规划向更高成熟度等级迈进的步骤。
|
||||
|
||||
## Key Aspects
|
||||
### 五个成熟度阶段
|
||||
1. **初始/应急阶段（Phase 1）**：传统瀑布式开发，团队孤立工作，手动流程，响应式监控
|
||||
2. **局部 DevOps 阶段（Phase 2）**：小团队试点 DevOps 实践，引入版本控制和基础自动化
|
||||
3. **自动化与定义阶段（Phase 3）**：标准化流程，广泛自动化，安全集成到开发流程
|
||||
4. **高度优化阶段（Phase 4）**：持续集成流水线，不可变基础设施，持续安全监控
|
||||
5. **完全成熟阶段（Phase 5）**：持续部署，多个每日部署，自主全栈团队
|
||||
|
||||
### 评估关键领域
|
||||
- **文化与战略**：团队协作、透明度、以客户为中心的产品导向思维
|
||||
- **自动化**：持续集成/持续部署（CI/CD）、基础设施即代码（IaC）
|
||||
- **结构与流程**：标准化流程、小块工作、透明进度
|
||||
- **协作与共享**：跨功能团队协作、技能整合
|
||||
- **技术**：工具选择、现代监控、容器化
|
||||
|
||||
### 业务收益
|
||||
- 更快的市场响应能力
|
||||
- 更好的扩展性
|
||||
- 增强的运营绩效
|
||||
- 更快的交付时间
|
||||
- 改进的质量
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← extends ← [[DevOps]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[CI/CD 流水线]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[Infrastructure as Code (IaC)]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[DevSecOps]]
|
||||
- [[DevOps 成熟度模型]] ← includes ← [[敏捷实践]]
|
||||
- [[DevOps 成熟度模型]] ← evaluated_by ← [[DevOps]]
|
||||
|
||||
## Aliases
|
||||
- DevOps Maturity Model
|
||||
31
wiki/concepts/DevOps-文化.md
Normal file
31
wiki/concepts/DevOps-文化.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "DevOps 文化"
|
||||
type: concept
|
||||
tags: [DevOps, 文化, 协作, 敏捷]
|
||||
sources: [DevOps-Culture-and-Transformation.md]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
DevOps 文化是一种优先考虑协作、持续学习和客户导向的文化与运营理念，旨在打破开发（Dev）与运维（Ops）之间的组织壁垒，实现整个软件生命周期的共同所有权。
|
||||
|
||||
## Core Principles（核心原则）
|
||||
- **协作优先于孤立**：通过跨职能团队消除信息孤岛
|
||||
- **自动化赋能**：用工具和自动化加速反馈循环
|
||||
- **持续改进 (Kaizen)**：通过迭代学习和无责复盘不断优化
|
||||
- **客户导向**：以真实用户问题解决为核心目标
|
||||
|
||||
## Key Practices（关键实践）
|
||||
- 跨职能团队建设
|
||||
- CI/CD 流水线实施
|
||||
- 基础设施即代码 (IaC)
|
||||
- 监控与可观测性
|
||||
- 混沌工程
|
||||
- 无责复盘 (Blameless Post-mortems)
|
||||
|
||||
## Related Concepts
|
||||
- [[CI/CD 流水线]]
|
||||
- [[Infrastructure as Code (IaC)]]
|
||||
- [[敏捷实践]]
|
||||
- [[DevSecOps]]
|
||||
- [[持续改进]]
|
||||
@@ -1,51 +1,23 @@
|
||||
---
|
||||
title: DevOps
|
||||
title: "DevOps"
|
||||
type: concept
|
||||
tags: [DevOps, 企业文化, 敏捷, 自动化]
|
||||
sources: ["sources/DevOps-Culture-and-Transformation.md"]
|
||||
last_updated: 2026-04-15
|
||||
tags: [DevOps, Methodology]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption, DevOps-Culture-and-Transformation.md, DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps, How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## 定义
|
||||
DevOps 是一种文化和运营变革方法论，旨在弥合软件开发（Dev）与运维（Ops）团队之间的鸿沟，通过跨职能协作、自动化和持续反馈加速软件交付。
|
||||
## Summary
|
||||
DevOps（开发运维一体化）是一种结合软件开发与 IT 运营的方法论，旨在实现持续软件交付。
|
||||
|
||||
## 核心原则
|
||||
- **协作优先于孤岛**：打破开发与运维之间的组织壁垒
|
||||
- **自动化赋能**：通过工具链自动化减少人工错误和等待时间
|
||||
- **持续改进（Kaizen）**：通过无责复盘和迭代优化实现渐进式提升
|
||||
- **客户中心**：每个发布都应解决真实用户问题
|
||||
## Definition
|
||||
DevOps 通过打破开发和运营团队之间的壁垒，实现更快、更可靠的软件部署和更新。
|
||||
|
||||
## 四大支柱
|
||||
1. 协作优先于孤岛
|
||||
2. 自动化即赋能者
|
||||
3. 持续改进（Kaizen）
|
||||
4. 客户中心
|
||||
## Key Aspects
|
||||
- 结合开发和运营团队
|
||||
- 实现无缝、持续的软件交付
|
||||
- 自动化部署流程
|
||||
- 缩短上市时间
|
||||
|
||||
## 关键实践
|
||||
- [[CI/CD Pipelines]]
|
||||
- [[Infrastructure as Code]]
|
||||
- [[DevSecOps]]
|
||||
- [[GitOps]]
|
||||
- 监控与可观测性（[[Prometheus]], [[Grafana]], [[Datadog]]）
|
||||
- 混沌工程
|
||||
|
||||
## 工具生态
|
||||
- CI/CD：[[Jenkins]], [[GitHub]] Actions, [[GitLab]] CI
|
||||
- IaC：[[Terraform]], AWS CloudFormation
|
||||
- 容器化：[[Docker]], [[Kubernetes]]
|
||||
- 监控：[[Prometheus]], [[Grafana]], [[Datadog]]
|
||||
- 安全：[[SonarSource]] SonarQube, [[Snyk]]
|
||||
|
||||
## 与 Agile 的关系
|
||||
- Agile 聚焦于迭代开发
|
||||
- DevOps 将 Agile 的迭代理念延伸至运维全生命周期
|
||||
- 两者协同实现端到端的交付速度和质量保障
|
||||
|
||||
## 未来趋势
|
||||
- AI/ML 赋能 DevOps（智能自动化、异常检测、自愈基础设施）
|
||||
- [[GitOps]]：以 Git 为唯一真实源
|
||||
- [[Serverless DevOps]]：FaaS 减少运维开销
|
||||
- [[Edge Computing DevOps]]：边缘节点实时应用优化
|
||||
|
||||
## Aliases
|
||||
- DevOps
|
||||
## Connections
|
||||
- [[DevOps]] ← part_of ← [[Cloud-Maturity-Model]]
|
||||
- [[DevOps]] ← is_extended_by ← [[DevOps 成熟度模型]]
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
title: "DevOps成熟度模型"
|
||||
type: concept
|
||||
tags: [devops, maturity-model, organizational-change, dora]
|
||||
sources: [DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps, Cloud-DevOp-Maturity-Guideline]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
DevOps 成熟度模型是评估组织 DevOps 实践能力的 5 阶段框架，帮助组织了解当前水平、识别改进方向、制定进阶路线图。
|
||||
|
||||
## 5 阶段成熟度
|
||||
|
||||
| 阶段 | 名称 | 核心特征 |
|
||||
|------|------|----------|
|
||||
| Phase 1 | Ad-Hoc | 团队孤立、瀑布式交付、手动基础设施、安全仅在发布前介入 |
|
||||
| Phase 2 | Pockets | 小规模试点、引入 Agile 版本控制、自动化降低发布风险 |
|
||||
| Phase 3 | Defined | 标准化流程、大部分基础设施自动化、安全融入设计阶段 |
|
||||
| Phase 4 | Optimized | 不可变基础设施、CI/CD 流水线成熟、技术债务管理 |
|
||||
| Phase 5 | Mature | 每天多次部署、零人工干预、实时数据驱动决策 |
|
||||
|
||||
## 4 大焦点领域
|
||||
1. **Culture & Strategy**：团队协作方式、客户中心思维
|
||||
2. **Automation**：CI/CD 自动化、基础设施即代码
|
||||
3. **Structure & Process**：标准化流程、小块交付
|
||||
4. **Collaboration**：跨团队协作、知识共享
|
||||
|
||||
## 关键指标
|
||||
- [[DORA指标]]：部署频率、变更前置时间、变更失败率、MTTR
|
||||
- MTTD（Mean Time to Detect）：平均问题发现时间
|
||||
- MTTA（Mean Time to Acknowledge）：平均问题确认时间
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← 上位概念
|
||||
- [[DORA指标]] ← 量化框架
|
||||
- [[DevSecOps]] ← 安全融合
|
||||
- [[Kaizen]] ← 持续改进理念
|
||||
@@ -1,40 +1,27 @@
|
||||
---
|
||||
title: DevSecOps
|
||||
title: "DevSecOps"
|
||||
type: concept
|
||||
tags: [DevSecOps, 安全, CI/CD, 敏捷]
|
||||
sources: ["sources/DevOps-Culture-and-Transformation.md"]
|
||||
last_updated: 2026-04-15
|
||||
tags: [devops, security, automation]
|
||||
sources: [cloud-devop-maturity-guideline, How-Agentic-AI-can-help-for-Cloud-DevOps, what-is-devsecops-best-practices-benefits-and-tools]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## 定义
|
||||
DevSecOps 是在 DevOps 流程中内置安全实践的方法论，通过将安全扫描、合规检查和漏洞修复集成到 CI/CD 流水线的每个阶段，实现"安全左移"（Shift-Left）。
|
||||
## Definition
|
||||
DevSecOps 是将安全实践集成到 DevOps 流程中的方法论，强调通过自动化、持续合规和主动漏洞管理实现"安全左移"。DevSecOps 将安全职责从单独的安全团队转移到整个开发团队，使安全成为每个人的责任。
|
||||
|
||||
## 核心原则
|
||||
- **安全左移**：在开发早期阶段引入安全检测，而非等到生产环境
|
||||
- **自动化安全扫描**：在构建、测试、部署各阶段自动执行安全检查
|
||||
- **共享所有权**：安全是开发、运维和安全团队共同责任
|
||||
## Core Principles
|
||||
- **安全左移（Shift Left）**：在开发生命周期早期嵌入安全检查
|
||||
- **自动化安全**：将安全扫描集成到 CI/CD 流水线
|
||||
- **持续合规**：自动化合规性检查和报告
|
||||
- **主动漏洞管理**：持续扫描和修复漏洞
|
||||
|
||||
## 关键实践
|
||||
- **静态应用安全测试（SAST）**：代码级别安全分析
|
||||
- **动态应用安全测试（DAST）**：运行时行为安全测试
|
||||
- **软件成分分析（SCA）**：依赖项漏洞扫描
|
||||
- **容器镜像扫描**：检查基础镜像和依赖漏洞
|
||||
## Key Practices
|
||||
- 自动化 SAST（静态应用安全测试）
|
||||
- 自动化 DAST（动态应用安全测试）
|
||||
- 容器镜像安全扫描
|
||||
- secrets 管理
|
||||
|
||||
## 关键工具
|
||||
- [[SonarSource]] SonarQube：代码质量与安全静态分析
|
||||
- [[Snyk]]：开源依赖与容器安全扫描
|
||||
- SonarCloud：云端代码分析
|
||||
|
||||
## 在 DevOps 中的角色
|
||||
- DevSecOps 是 DevOps 成熟度的重要标志
|
||||
- 与 [[CI/CD Pipelines]] 深度集成，在部署前阻断安全漏洞
|
||||
- 支撑 [[Agile]] 和 [[DevOps]] 的快速迭代同时保障安全合规
|
||||
|
||||
## 未来趋势
|
||||
- AI 驱动的安全漏洞预测
|
||||
- 零信任架构（Zero Trust Architecture）深度集成
|
||||
- 实时威胁检测与响应自动化
|
||||
|
||||
## Aliases
|
||||
- DevSecOps
|
||||
- 安全左移
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← 安全维度 ← [[DevSecOps]]
|
||||
- [[CI/CD 流水线]] ← 集成 ← [[DevSecOps]]
|
||||
- [[监控可观测性]] ← 依赖 ← [[DevSecOps]]
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: "Diff审查"
|
||||
type: concept
|
||||
tags: [code-review, cursor, ai, git]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
通过文件对比视图（Diff View）逐文件或整体审查 AI 生成代码改动的机制，是 AI 编程工具中的核心安全机制。
|
||||
|
||||
## 核心功能
|
||||
- **逐文件审查**：逐个查看每个文件的改动内容
|
||||
- **整体接收/撤销**：Accept All 或 Undo All
|
||||
- **逐文件操作**：Accept 或 Undo 单个文件
|
||||
|
||||
## 关键风险
|
||||
- AI 生成代码即写入文件，未点击撤销前持续保留
|
||||
- 关闭文件或多次修改后 Undo All 可能失效
|
||||
- **必须先测试再确认保存**
|
||||
|
||||
## 最佳实践
|
||||
1. 生成代码后进入"待审查"状态
|
||||
2. 使用 Diff 功能逐文件查看改动
|
||||
3. 运行测试验证代码正确性
|
||||
4. 确认无误后 Accept All
|
||||
5. 结合 Git 版本控制以便回滚
|
||||
|
||||
## 关联
|
||||
- [[Cursor]] 的核心审查机制
|
||||
- [[Git]] 版本控制的前置保障
|
||||
- [[AI代码编辑器]] 的标准安全流程
|
||||
|
||||
## Aliases
|
||||
- 代码改动审查
|
||||
- Diff View
|
||||
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
id: Docker-Attach-mode
|
||||
title: "Docker Attach模式"
|
||||
type: concept
|
||||
tags: [docker, development, remote]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Docker Attach 模式是一种远程开发方式：Trae/VS Code 直接"进入"已在服务器运行的 Docker 容器，在容器内部启动编辑器后端，实现完全隔离的开发环境。
|
||||
|
||||
## vs 宿主机编辑模式
|
||||
| 维度 | Attach 模式 | 宿主机编辑模式 |
|
||||
|------|------------|-------------|
|
||||
| 编辑器位置 | 容器内 | 宿主机（Ubuntu） |
|
||||
| 环境 | 容器定义的环境 | 宿主机环境 |
|
||||
| Git 凭证 | 需 SSH Agent 转发 | 自动复用宿主机配置 |
|
||||
| 文件权限 | 容器内生成文件属 root | 正常 |
|
||||
| 适合场景 | 深度定制化环境 | docker-compose 管理 |
|
||||
|
||||
## Workflow (Trae)
|
||||
1. Remote SSH 连接到 Ubuntu 服务器
|
||||
2. Docker 插件中找到目标容器
|
||||
3. 右键 → "Attach Visual Studio Code"
|
||||
4. Trae 在容器内安装 Trae Server
|
||||
|
||||
## Related Concepts
|
||||
- [[Remote SSH]]：Attach 模式的前置条件
|
||||
- [[Bind Mount]]：容器内文件与宿主机共享的挂载机制
|
||||
- [[Docker Compose]]：定义开发环境容器的配置文件
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
id: Docker-Compose
|
||||
title: "Docker Compose"
|
||||
type: concept
|
||||
tags: [docker, orchestration, containers]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Docker Compose 是一个定义和运行多容器 Docker 应用的工具，通过 YAML 文件声明式定义服务、网络、卷和依赖关系，使用 docker compose up 一键启动完整应用栈。
|
||||
|
||||
## Core Concepts
|
||||
- services：定义每个容器（image/build、ports、volumes、environment、depends_on）
|
||||
- volumes：持久化数据存储，named volumes 由 Docker 管理
|
||||
- networks：容器间通信网络，默认 bridge 模式
|
||||
- depends_on：声明服务启动顺序依赖
|
||||
|
||||
## MinIO/Zipline Stack Example
|
||||
```yaml
|
||||
services:
|
||||
minio:
|
||||
image: minio/minio:latest
|
||||
ports: ["9000:9000", "9001:9001"]
|
||||
volumes: [/volume1/docker/zipline-stack/minio/minio_data:/data]
|
||||
postgres:
|
||||
image: postgres:16
|
||||
volumes: [/volume1/docker/zipline-stack/zipline/pg_data:/var/lib/postgresql/data]
|
||||
zipline:
|
||||
depends_on: [minio, postgres]
|
||||
ports: ["3333:3000"]
|
||||
```
|
||||
|
||||
## Update Workflow
|
||||
docker compose pull && docker compose down && docker compose up -d
|
||||
|
||||
## Related Concepts
|
||||
- [[Docker]]：容器化平台
|
||||
- [[MinIO]]：MinIO 部署示例
|
||||
- [[n8n]]：n8n 生产环境推荐 Docker Compose 部署
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
id: docker-daemon-proxy
|
||||
title: Docker Daemon 代理
|
||||
type: concept
|
||||
tags: [Docker, 代理, Ubuntu, systemd]
|
||||
sources: []
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Docker 守护进程（Daemon）级代理配置。`docker pull` 等操作由 Daemon 执行，不读取用户环境变量，必须通过 systemd 环境变量注入。
|
||||
|
||||
## Configuration
|
||||
|
||||
创建 `/etc/systemd/system/docker.service.d/http-proxy.conf`：
|
||||
|
||||
```ini
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=http://127.0.0.1:10808/"
|
||||
Environment="HTTPS_PROXY=http://127.0.0.1:10808/"
|
||||
Environment="NO_PROXY=localhost,127.0.0.1"
|
||||
```
|
||||
|
||||
执行生效：`sudo systemctl daemon-reload && sudo systemctl restart docker`
|
||||
|
||||
验证：`docker info | grep -i proxy`
|
||||
|
||||
## Key Distinction
|
||||
|
||||
| 层级 | 配置文件 | 作用范围 |
|
||||
|------|---------|---------|
|
||||
| Daemon 级 | systemd unit override | docker pull/build 等 |
|
||||
| 容器内应用级 | ~/.docker/config.json | 容器内 apt-get/pip 等 |
|
||||
| Compose 环境变量 | docker-compose.yml | 单个服务 |
|
||||
|
||||
## Connections
|
||||
- [[Docker]] ← Docker 守护进程配置
|
||||
- [[SOCKS5 代理]] ← Daemon 通常连接 SOCKS5 转换 HTTP
|
||||
- [[V2RayN]] ← 提供本地代理端口
|
||||
23
wiki/concepts/Dynamic-Configuration-Management.md
Normal file
23
wiki/concepts/Dynamic-Configuration-Management.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Dynamic Configuration Management"
|
||||
type: concept
|
||||
tags: [configuration, automation, runtime]
|
||||
sources: [How-Agentic-AI-can-help-for-Cloud-DevOps]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
Dynamic Configuration Management（动态配置管理）是指在运行时根据性能、成本和业务需求自动调整应用配置的管理方式。
|
||||
|
||||
## Definition
|
||||
基于实时监控数据和预设策略，在不重启应用的情况下动态调整配置参数，实现性能和成本的最优化。
|
||||
|
||||
## Key Mechanisms
|
||||
- **Parameter Store**：AWS 参数存储服务
|
||||
- **Secrets Manager**：AWS 密钥管理服务
|
||||
- **ConfigMaps**：Kubernetes 配置映射
|
||||
- **实时性能反馈**：根据性能指标自动调优
|
||||
|
||||
## Connections
|
||||
- [[Agentic AI]] ← implements ← [[Dynamic Configuration Management]]：Agentic AI 实现动态配置调整
|
||||
- [[Auto-scaling]] ← coordinates ← [[Dynamic Configuration Management]]：动态配置与扩缩容协同工作
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Edge Computing DevOps
|
||||
type: concept
|
||||
tags: [Edge Computing, IoT, DevOps, 分布式]
|
||||
sources: ["sources/DevOps-Culture-and-Transformation.md"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
Edge Computing DevOps 是在边缘节点（Edge Nodes）上进行应用部署、运维和优化的 DevOps 实践模式，通过将计算能力下沉至靠近终端用户的位置，实现低延迟和高实时性。
|
||||
|
||||
## 核心挑战
|
||||
- **分布式运维**：大量边缘节点的统一管理和配置
|
||||
- **网络延迟**：边缘与中心云/数据中心通信受限
|
||||
- **离线自治**：边缘节点需在断网情况下仍能正常运行
|
||||
- **资源受限**：边缘设备通常计算和存储资源有限
|
||||
- **一致性管理**：跨地理分布的节点一致性保证
|
||||
|
||||
## 关键场景
|
||||
- 自动驾驶汽车的实时决策
|
||||
- 工业 IoT 传感器数据处理
|
||||
- 视频流媒体边缘缓存与转码
|
||||
- 智慧城市的实时分析
|
||||
|
||||
## 关键工具
|
||||
- [[Kubernetes]] K3s：轻量级 Kubernetes 发行版，适合边缘
|
||||
- K3d：本地 Kubernetes 开发环境
|
||||
- [[Docker]]：边缘应用容器化 runtime
|
||||
- Weave Net / Flannel：边缘网络插件
|
||||
|
||||
## 在 DevOps 中的角色
|
||||
- Edge Computing DevOps 是 [[DevOps]] 在分布式场景下的扩展
|
||||
- 支撑 [[Serverless DevOps]] 在边缘的落地
|
||||
- 运维模式需支持弱网/断网环境下的自治运行
|
||||
|
||||
## 未来趋势
|
||||
- 6G 网络推动边缘算力进一步下沉
|
||||
- AI 推理能力向边缘迁移（Edge AI）
|
||||
- 零信任安全模型在边缘的深度应用
|
||||
|
||||
## Aliases
|
||||
- Edge DevOps
|
||||
- 边缘计算 DevOps
|
||||
- 边缘原生
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: "Embedding"
|
||||
type: concept
|
||||
tags: [embedding, vector, rag, nlp]
|
||||
sources: ["RAG从入门到精通系列1：基础RAG"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
将文本（Word、Sentence、Document）转换为固定长度的数值向量（Embedding Vector）的技术，捕获文本的语义信息使得语义相似的内容在向量空间中距离相近。
|
||||
|
||||
## Technical Details
|
||||
- 输出为固定长度向量（如 768维、1024维、1536维）
|
||||
- 语义相近的文本在向量空间中距离更近
|
||||
- 支持余弦相似度、点积等多种相似度衡量方法
|
||||
|
||||
## Embedding Model
|
||||
- **BAAI BGE 系列**：开源中文优化 Embedding Model
|
||||
- **OpenAI text-embedding-3**：OpenAI 官方 Embedding API
|
||||
- Context Window 通常 512~8192 token
|
||||
|
||||
## Applications
|
||||
- [[RAG]]：文档和问题的向量化，支持语义检索
|
||||
- 文本相似度计算
|
||||
- 聚类分析
|
||||
- 推荐系统
|
||||
|
||||
## Related Concepts
|
||||
- [[向量数据库]]：存储 Embedding Vector 的数据库
|
||||
- [[RAG]]：Embedding 的主要应用场景
|
||||
- [[Token]]：文本被分词后的基本单位
|
||||
|
||||
## Sources
|
||||
- [[RAG从入门到精通系列1：基础RAG]]
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "EventBridge"
|
||||
type: concept
|
||||
tags: [aws, event-driven, serverless, devops]
|
||||
date: 2025-10-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
Amazon EventBridge，AWS 无服务器事件总线服务，将应用程序与来自 SaaS 工具和 AWS 服务的事件连接起来。核心机制是事件规则（Event Rules）匹配模式，将匹配的事件路由到目标（Targets）。
|
||||
|
||||
## Key Properties
|
||||
- **事件规则**：基于事件模式（Event Pattern）匹配，支持前缀/后缀/精确匹配
|
||||
- **跨账户转发**：通过资源访问策略（Resource-Based Policy）将事件从成员账户转发至管理账户事件总线
|
||||
- **目标类型**：Lambda、SSM、CloudWatch Logs、SQS、SNS、Kinesis Firehose 等
|
||||
- **自定义事件总线**：每个 AWS 账户可创建多个自定义事件总线，按来源隔离
|
||||
|
||||
## Multi-Account Pattern
|
||||
在 StackSets 集中日志场景中：
|
||||
1. 成员账户 EventBridge 规则捕获 CloudFormation 事件
|
||||
2. 通过跨账户权限转发至管理账户自定义事件总线
|
||||
3. 管理账户 EventBridge 将事件路由至 CloudWatch Logs
|
||||
|
||||
## Related Concepts
|
||||
- [[CloudFormation StackSets]]：EventBridge 事件来源之一
|
||||
- [[Serverless-DevOps]]：EventBridge 是无服务器 DevOps 的核心事件中枢
|
||||
- [[CloudWatch Logs]]：EventBridge 的常用目标服务
|
||||
|
||||
## Source
|
||||
[[AWS-CloudFormation-StackSets-多账户集中日志监控]]
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: "FRP内网穿透"
|
||||
type: concept
|
||||
tags: [networking, self-hosted, reverse-proxy, tunneling]
|
||||
---
|
||||
|
||||
## 定义
|
||||
FRP（Fast Reverse Proxy）是一个高性能的内网穿透工具，通过在公网 VPS 上部署 frps 服务端（FRPS），在内网机器上部署 frpc 客户端，将内网服务暴露到公网。
|
||||
|
||||
## 架构
|
||||
|
||||
```
|
||||
[内网服务] ←localhost:port← [frpc 客户端] ←TCP/UDP← [frps 服务端] ←公网← [用户]
|
||||
```
|
||||
|
||||
- **frps（FRP Server）**：运行在有公网 IP 的 VPS 上，监听连接请求
|
||||
- **frpc（FRP Client）**：运行在内网机器上，与 frps 保持心跳，转发请求到内网服务
|
||||
|
||||
## 核心配置（frpc.toml）
|
||||
|
||||
```toml
|
||||
[[proxies]]
|
||||
name = "ssh-tunnel"
|
||||
type = "tcp"
|
||||
localIP = "127.0.0.1"
|
||||
localPort = 22
|
||||
remotePort = 60022 # 公网 VPS 暴露的端口
|
||||
```
|
||||
|
||||
## 在家庭基础设施中的应用
|
||||
|
||||
| 节点 | frpc 版本 | frps 服务器 |
|
||||
|------|-----------|-------------|
|
||||
| [[Mac Mini]] | 0.65.0 darwin arm64 | VPS1 :7000 |
|
||||
| [[Synology NAS DS718]] | 0.65.0 linux amd64 | VPS1 :7000 |
|
||||
| [[Ubuntu1]] | 0.65.0 linux amd64 | VPS1 :7000 |
|
||||
| [[Ubuntu2]] | 0.65.0 linux amd64 | VPS1 :7000 |
|
||||
|
||||
## 关键优势
|
||||
- 不需要公网 IP，利用 VPS 中转实现内网暴露
|
||||
- 支持 TCP/UDP/HTTP/HTTPS多种协议
|
||||
- 可配置 auth_method 实现加密通信
|
||||
- 通过 ini 或 toml 配置文件管理，版本可控
|
||||
|
||||
## 管理命令
|
||||
|
||||
| 服务器 | 启动方式 | 重启命令 |
|
||||
|--------|---------|---------|
|
||||
| Mac Mini | launchd（plist） | launchctl unload/load plist |
|
||||
| Ubuntu1/2 | systemd --user | systemctl --user restart frpc |
|
||||
|
||||
## 与其他方案的比较
|
||||
- **frp vs ngrok**：frp 完全自托管，无带宽限制，配置灵活
|
||||
- **frp vs Cloudflare Tunnel**：frp 需要 VPS，Cloudflare Tunnel 依赖 Cloudflare 基础设施
|
||||
|
||||
## 相关工具
|
||||
- [[反向代理]]：Caddy 作为 HTTP 层反向代理
|
||||
- [[内网穿透]]：frp 属于内网穿透工具类别
|
||||
35
wiki/concepts/Feature-Flag.md
Normal file
35
wiki/concepts/Feature-Flag.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Feature Flag"
|
||||
type: concept
|
||||
tags: [持续交付, 特性管理, 发布工程]
|
||||
sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
|
||||
last_updated: 2025-07-26
|
||||
---
|
||||
|
||||
## Definition
|
||||
Feature Flag（特性开关）是一种将代码部署与功能发布分离的技术，允许在不重新部署的情况下通过配置切换代码执行路径。
|
||||
|
||||
## Key Concepts
|
||||
- Deploy != Release：部署代码但不立即向用户开放
|
||||
- Kill Switch：紧急关闭机制，用于快速禁用问题功能
|
||||
- 渐进式 Rollout：分阶段向用户群发布（1% → 5% → 25% → 100%）
|
||||
|
||||
## Benefits for RTO/RPO
|
||||
- RTO：从小时级降至秒级（只需关闭开关）
|
||||
- RPO：Rollback 时不丢失数据，只需切换代码路径
|
||||
|
||||
## Code Example
|
||||
```javascript
|
||||
if (featureFlag.enabled('new-checkout-flow')) {
|
||||
return newCheckoutProcess();
|
||||
} else {
|
||||
return oldCheckoutProcess();
|
||||
}
|
||||
```
|
||||
|
||||
## Connections
|
||||
- [[Kill Switch]] ← 紧急机制 → [[Feature Flag]]
|
||||
- [[渐进式发布]] ← 发布策略 → [[Feature Flag]]
|
||||
- [[RTO (Recovery Time Objective)]] ← 降低工具 → [[Feature Flag]]
|
||||
- [[RPO (Recovery Point Objective)]] ← 保护工具 → [[Feature Flag]]
|
||||
- [[LaunchDarkly]] ← 平台 → [[Feature Flag]]
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "FeatureList"
|
||||
type: concept
|
||||
tags: [产品管理, 需求管理, AI辅助]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
FeatureList：分层级展开的需求表，用于需求创意阶段与 AI 共创。与传统脑图本质相同，核心关注三方面：（1）功能模块分层分类合理性；（2）细分功能点全面性与划分合理性；（3）每个功能点的优先级评估合理性。
|
||||
|
||||
## AI协作方法
|
||||
1. 提供 FeatureList 表头模板（功能模块/功能点/优先级/备注）
|
||||
2. 用自然语言描述业务场景和核心功能模块划分
|
||||
3. 让 Gemini 生成第一版 FL
|
||||
4. 回答 Gemini 的关键业务问题
|
||||
5. 指出遗漏层级或缺失字段，迭代至终版
|
||||
|
||||
## AI协作要点
|
||||
- FeatureList = 想，PRD = 写；大模型只负责写，不负责想
|
||||
- Gemini 处理表格可能出错（格式丢失、制表符文本），可用 Google 表格导出解决
|
||||
- 调教方式：严厉指出错误，大模型不需要情绪价值
|
||||
|
||||
## Connections
|
||||
- [[PRD自动生成]] ← 下游输出
|
||||
- [[结构化思维]] ← 核心能力要求
|
||||
- [[Gemini]] ← 主要工具
|
||||
- [[不会Gemini的产品经理真的要被淘汰了]] ← 来源
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
id: FinOps
|
||||
title: "FinOps"
|
||||
type: concept
|
||||
tags: [cloud, cost-optimization, financial-management]
|
||||
sources: []
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
云财务运营（FinOps，Cloud Financial Operations）是通过实时追踪、分析和优化云成本，防止云超支并最大化投资回报的管理实践。
|
||||
|
||||
## Core Practices
|
||||
- **Reserved Instances + Spot Instances**：计算成本降低 40-70%
|
||||
- **Auto-Scaling + Right-Sizing**：资源按需匹配实际负载
|
||||
- **实时成本监控**：AWS Cost Explorer、Azure Cost Management、GCP Billing Reports
|
||||
- **资源标签化**：按团队、项目、工作负载追踪支出
|
||||
|
||||
## Key Stats
|
||||
- 59% 企业经历云成本管理困难（Flexera 2024）
|
||||
- 全球电商公司通过 AWS+Azure 双云 Reserved Instances 节省 $500,000/年
|
||||
- SaaS 公司通过 Auto-Scaling + Reserved Instances 降低 35% 云成本
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Operating Model]]：FinOps 是 COM 的四大支柱之一
|
||||
- [[Multi-Cloud]]：多云环境下的成本管理更复杂
|
||||
- [[DevOps]]：DevOps 团队需与 FinOps 协作
|
||||
@@ -1,28 +0,0 @@
|
||||
# Fitness Function
|
||||
|
||||
## Definition
|
||||
A metric used in the Knock-out multi-agent pattern to evaluate how well each agent performs a task. The function determines which agents survive and which are eliminated. It can be deterministic (e.g., unit tests, exact match) or LLM-based (e.g., quality scoring).
|
||||
|
||||
## Role in Multi-Agent Knock-out
|
||||
- Evaluates output of each agent
|
||||
- Produces a score or boolean pass/fail
|
||||
- Used to rank agents and identify worst performers
|
||||
- Guides the selection/elimination process
|
||||
|
||||
## Key Properties
|
||||
- Must be fast — if humans need to verify all branches, the process is too slow
|
||||
- Should be deterministic where possible (unit tests over LLM judgment)
|
||||
- Can be composite: multiple criteria combined into single score
|
||||
- Is where "Evals" come in (critical infrastructure for agent development)
|
||||
|
||||
## Examples
|
||||
- Unit test pass rate
|
||||
- Exact string match against expected output
|
||||
- LLM-based quality scoring (with rubric)
|
||||
- Latency or token cost as secondary factors
|
||||
|
||||
## Related Concepts
|
||||
- [[Genetic Algorithms]]
|
||||
- [[Multi-Agent Knock-out]]
|
||||
- [[Validator]]
|
||||
- [[Evals]]
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: "GPT 与 MBR 分区表"
|
||||
type: concept
|
||||
tags: [分区表, UEFI, BIOS, 运维]
|
||||
date: 2025-12-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
两种磁盘分区表格式：MBR（Master Boot Record）是传统 BIOS 标准，GPT（GUID Partition Table）是现代 UEFI 标准。启动模式决定分区表类型，而非硬盘容量。
|
||||
|
||||
## Comparison
|
||||
| 维度 | MBR | GPT |
|
||||
|------|-----|-----|
|
||||
| 最大磁盘 | 2TB（512字节扇区） | 9.4ZB（理论） |
|
||||
| 分区数量 | 4 个主分区（或 3 主+1 扩展） | 128 个（Windows 标准） |
|
||||
| 启动模式 | BIOS 传统启动 | UEFI 安全启动 |
|
||||
| 兼容性 | 老旧硬件 | 新硬件默认 |
|
||||
| 损坏恢复 | MBR 损坏即无法启动 | GPT 保存副本，容错性高 |
|
||||
|
||||
## Decision Rule
|
||||
```
|
||||
启动模式 → 分区表类型
|
||||
BIOS (传统) → MBR
|
||||
UEFI (现代) → GPT
|
||||
```
|
||||
|
||||
## Common Pitfalls
|
||||
- 在 UEFI 机器上使用 MBR：系统无法从 GPT 磁盘的 BIOS 模式启动
|
||||
- 在 BIOS 机器上使用 GPT：大多数 BIOS 不支持从 GPT 磁盘启动
|
||||
- Rufus DD 模式 vs ISO 模式：ISOHybrid 镜像建议先试 ISO 模式，失败再用 DD
|
||||
|
||||
## Connections
|
||||
- [[GPT与MBR]] ← 决定于 ← [[UEFI启动]] vs [[BIOS启动]]
|
||||
- [[GPT与MBR]] ← 影响 ← [[Clonezilla备份]] 时的分区方案选择
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: "GenAI"
|
||||
type: concept
|
||||
tags: [genai, generative-ai, content-generation]
|
||||
sources: ["Designing for Agentic AI.md"]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
Generative AI（生成式AI），擅长创建新内容（文本、图像、音乐等）的AI系统。作为"创意助手"能生成创意或翻译语言。
|
||||
|
||||
## Key Characteristics
|
||||
- 被动响应：等待用户输入后生成内容
|
||||
- 内容创作：擅长生成文本、图像、音乐等创意内容
|
||||
- 知识截止：基于训练数据，知识有时效性限制
|
||||
- 无行动能力：仅能"思考"，无法执行外部操作
|
||||
|
||||
## Comparison with Agentic AI
|
||||
|
||||
| 维度 | GenAI | Agentic AI |
|
||||
|------|-------|------------|
|
||||
| 核心能力 | 内容创作 | 行动执行 |
|
||||
| 交互模式 | 被动响应用户输入 | 主动预判并自主行动 |
|
||||
| 知识状态 | 训练数据截止日期 | 可通过RAG获取实时信息 |
|
||||
| 执行能力 | 无 | 有（API调用、代码执行等）|
|
||||
| 典型场景 | 写作、摘要、翻译、图像生成 | 任务自动化、复杂工作流 |
|
||||
|
||||
## Relationship to Other Concepts
|
||||
- [[Agentic-AI]]：GenAI是Agentic AI的内容生成基础；Agentic AI = GenAI + 行动框架
|
||||
- [[LLM]]：LLM是GenAI的核心技术架构之一
|
||||
- [[RAG]]：RAG为GenAI提供实时信息获取能力，解决知识时效性问题
|
||||
|
||||
## Examples
|
||||
- 写作助手：生成诗歌、文章
|
||||
- 图像生成：Midjourney、Stable Diffusion、DALL-E
|
||||
- 音乐生成：Suno AI
|
||||
- 代码生成：Claude Code、Cline
|
||||
|
||||
## Aliases
|
||||
- 生成式AI
|
||||
- 生成式人工智能
|
||||
- Generative AI
|
||||
|
||||
## Sources
|
||||
- [[Designing-for-Agentic-AI]]
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "Generator"
|
||||
type: concept
|
||||
tags: [agent, skill, design-pattern]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
# Generator
|
||||
|
||||
## 定义
|
||||
Google 5 种 Agent Skill 设计模式之一，通过"填空"流程强制一致输出格式的 Skill 模式。
|
||||
|
||||
## 核心机制
|
||||
利用两个可选目录：
|
||||
- assets/：存放输出模板
|
||||
- references/：存放样式指南
|
||||
|
||||
SKILL.md 扮演项目经理角色，指示 agent 加载模板→读取样式指南→向用户询问缺失变量→填充文档。
|
||||
|
||||
## 适用场景
|
||||
- 统一格式的 API 文档生成
|
||||
- 标准化 commit 信息
|
||||
- 脚手架项目结构生成
|
||||
|
||||
## Connections
|
||||
- [[Agent Skill 设计模式]]：所属分类
|
||||
- [[Inversion]]：可组合，收集缺失变量
|
||||
@@ -1,28 +0,0 @@
|
||||
# Genetic Algorithms
|
||||
|
||||
## Definition
|
||||
A class of ML algorithms inspired by biological evolution that uses selection, crossover, and mutation to iteratively improve solutions. The Knock-out multi-agent pattern is a lean implementation of genetic algorithms applied to LLM agents.
|
||||
|
||||
## Core Components
|
||||
1. **Genetic Representation** — A model and its context represent a solution candidate
|
||||
2. **Fitness Function** — Evaluates how well each candidate solves the problem
|
||||
3. **Selection** — Winners are chosen based on fitness scores
|
||||
4. **Crossover** — Combining traits from successful candidates (optional in basic knock-out)
|
||||
5. **Mutation** — Random variation in candidate traits (optional)
|
||||
|
||||
## Application to Multi-Agent Knock-out
|
||||
- N agents work on the same task
|
||||
- Validator (fitness function) evaluates each
|
||||
- Worst performers are eliminated (selection pressure)
|
||||
- [Optional] New agents created by combining prompts of survivors (crossover)
|
||||
- Process repeats until satisfactory solution emerges
|
||||
|
||||
## Key Insight
|
||||
- Since we can't punish or threaten LLM agents, we simply delete underperformers
|
||||
- This mirrors "survival of the fittest" in biological evolution
|
||||
- No attachment to individual agents — treat them as cattle, not pets
|
||||
|
||||
## Related Concepts
|
||||
- [[Fitness Function]]
|
||||
- [[Multi-Agent Knock-out]]
|
||||
- [[Cattle vs Pets]]
|
||||
@@ -1,36 +1,21 @@
|
||||
---
|
||||
title: GitOps
|
||||
title: "GitOps"
|
||||
type: concept
|
||||
tags: [GitOps, DevOps, 基础设施, 声明式]
|
||||
sources: ["sources/DevOps-Culture-and-Transformation.md"]
|
||||
last_updated: 2026-04-15
|
||||
tags: [DevOps, Git, 基础设施, 部署]
|
||||
sources: [DevOps-Culture-and-Transformation.md]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## 定义
|
||||
GitOps 是一种以 Git 为单一真实源（Single Source of Truth）来管理基础设施和应用配置的方法论，所有变更通过 Pull Request 驱动，实现声明式基础设施管理。
|
||||
## Definition
|
||||
GitOps 是一种使用 Git 作为单一真相源（Single Source of Truth）来管理基础设施和部署的文化理念和运维框架，所有配置和部署声明都存储在 Git 仓库中。
|
||||
|
||||
## 核心原则
|
||||
- **声明式配置**：以代码形式声明期望状态
|
||||
- **Git 单一真实源**：所有配置存储在 Git 仓库中
|
||||
- **自动同步**：系统自动检测并纠正与期望状态的偏差
|
||||
- **变更可追溯**：所有变更通过 Pull Request 记录和审查
|
||||
## Key Principles（关键原则）
|
||||
- 声明式基础设施
|
||||
- Git 作为单一真相源
|
||||
- 自动同步和部署
|
||||
- 可审计和可回滚
|
||||
|
||||
## 关键工具
|
||||
- [[GitHub]] Actions + Flux 或 Argo CD：GitOps 核心引擎
|
||||
- [[Kubernetes]]：GitOps 的典型承载平台
|
||||
- Weave GitOps：GitOps 实现工具
|
||||
- Argo CD：Kubernetes 专用 GitOps 工具
|
||||
|
||||
## 在 DevOps 中的角色
|
||||
- GitOps 是 [[DevOps]] 自动化的演进方向
|
||||
- 与 [[CI/CD Pipelines]] 互补：CI/CD 关注应用交付，GitOps 关注基础设施和应用配置的声明式管理
|
||||
- 天然支撑 [[Infrastructure as Code]] 实践
|
||||
|
||||
## 优势
|
||||
- 提高变更可追溯性和安全性
|
||||
- 简化回滚操作（git revert）
|
||||
- 提升部署一致性
|
||||
- 降低人为错误
|
||||
|
||||
## Aliases
|
||||
- GitOps
|
||||
## Related Concepts
|
||||
- [[DevOps 文化]]
|
||||
- [[Infrastructure as Code (IaC)]]
|
||||
- [[CI/CD 流水线]]
|
||||
|
||||
@@ -1,48 +0,0 @@
|
||||
---
|
||||
title: "Git HTTP/SOCKS5 代理配置"
|
||||
type: concept
|
||||
tags: [git, proxy, socks5, http, github]
|
||||
---
|
||||
|
||||
## Definition
|
||||
Git 代理配置是通过 `git config --global http.proxy` 和 `git config --global https.proxy` 全局设置，让 Git 的 HTTP/HTTPS/SSH 操作通过本地代理服务器进行。
|
||||
|
||||
## Commands
|
||||
### HTTP 代理
|
||||
```bash
|
||||
git config --global http.proxy http://127.0.0.1:10809
|
||||
git config --global https.proxy http://127.0.0.1:10809
|
||||
```
|
||||
|
||||
### SOCKS5 代理（速度通常更快）
|
||||
```bash
|
||||
git config --global http.proxy socks5://127.0.0.1:10808
|
||||
git config --global https.proxy socks5://127.0.0.1:10808
|
||||
```
|
||||
|
||||
### 取消代理
|
||||
```bash
|
||||
git config --global --unset http.proxy
|
||||
git config --global --unset https.proxy
|
||||
```
|
||||
|
||||
### 查看当前配置
|
||||
```bash
|
||||
git config --global --get http.proxy
|
||||
```
|
||||
|
||||
## Core Insight
|
||||
设置代理后，Git 的所有网络流量通过本地代理转发。GFW 只能看到通向本地代理的连接，无法识别目标域名，从根本上规避 TCP RST 攻击。
|
||||
|
||||
## Scope
|
||||
- 全局（`--global`）：影响当前用户所有 Git 仓库
|
||||
- 本地（无 `--global`）：仅影响当前仓库
|
||||
- 仅影响 Git 命令，不影响终端其他程序
|
||||
|
||||
## Relationship to Other Concepts
|
||||
- [[TCP RST 攻击]] ← solves：代理让 GFW 无法检测 GitHub 域名
|
||||
- [[SOCKS5 代理]] ← transport_layer：SOCKS5 比 HTTP 代理更底层，支持更多协议
|
||||
- [[V2RayN]] ← provides：V2RayN 同时提供 HTTP 和 SOCKS5 代理端口
|
||||
|
||||
## Source
|
||||
- [[Git Push 连接重置问题修复]]
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: "Git自动同步"
|
||||
type: concept
|
||||
tags: [Obsidian, Git, 版本控制]
|
||||
sources: ["养虾日记3-Obsidian-Gitea持久化笔记系统.md"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Git自动同步指 Obsidian Git 插件设置为 Auto commit-and-sync interval（如 10 分钟），插件自动 commit + push，无需手动操作。
|
||||
|
||||
## Key Value
|
||||
AI 批量改文件的能力越强，越需要版本管理来兜底。Git 自动同步让这个兜底机制完全无需人工干预。
|
||||
|
||||
## Mechanism
|
||||
- Obsidian Git 插件（社区插件）→ Auto commit interval
|
||||
- commit + push 全自动
|
||||
- Gitea 私有仓库存储，历史版本任意回溯
|
||||
|
||||
## Related Concepts
|
||||
- [[LLM Wiki]]：Git自动同步是 LLM Wiki 版本控制的实现层
|
||||
- [[Gitea]]：承载仓库的 Git 服务
|
||||
- [[Obsidian]]：笔记前端
|
||||
21
wiki/concepts/Google-Cloud-Adoption-Framework.md
Normal file
21
wiki/concepts/Google-Cloud-Adoption-Framework.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "Google Cloud Adoption Framework"
|
||||
type: concept
|
||||
tags: [Cloud, Framework, Google]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
Google Cloud Adoption Framework 是一种帮助组织识别关键活动目标的框架，以有效加速向云端的转型。
|
||||
|
||||
## Definition
|
||||
Google Cloud Adoption Framework 协助组织确定关键活动，帮助加速云迁移过程。
|
||||
|
||||
## Key Focus Areas
|
||||
- 识别关键活动和目标
|
||||
- 加速云转型
|
||||
- 最佳实践指导
|
||||
|
||||
## Connections
|
||||
- [[Google-Cloud-Adoption-Framework]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
@@ -1,29 +0,0 @@
|
||||
---
|
||||
title: "Google Search Grounding"
|
||||
type: concept
|
||||
tags: [nano-banana-pro, google-search, grounding, real-time-data, hallucination-reduction]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## 定义
|
||||
Nano-Banana Pro 结合 Google 实时搜索结果驱动图像生成，减少时效性话题的幻觉，并支持天气、股票、新闻等动态数据可视化。
|
||||
|
||||
## 核心机制
|
||||
1. 用户请求实时数据可视化（天气/股票/新闻）
|
||||
2. 模型调用 Google Search 获取当前信息
|
||||
3. 模型"思考"（reason）搜索结果后再生成图像
|
||||
4. 输出包含实时数据洞察的可视化图像
|
||||
|
||||
## 应用场景
|
||||
- **股票趋势可视化**：当前科技公司股价和趋势分析图
|
||||
- **旅行指南**：2025 年美国国家公园最佳游览时间（基于当前旅行趋势）
|
||||
- **事件可视化**：新闻事件相关的数据图
|
||||
|
||||
## 与 RAG 的关系
|
||||
- Google Search Grounding 是 RAG 思想在图像生成领域的应用
|
||||
- RAG：检索增强文本生成
|
||||
- Search Grounding：检索增强图像生成
|
||||
|
||||
## Connections
|
||||
- [[Google Search Grounding]] ← 能力 ← [[Nano-Banana Pro]]
|
||||
- [[Google Search Grounding]] ← 类比 ← [[RAG]]
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
title: "Google Workspace CLI"
|
||||
type: concept
|
||||
tags: [cli, google-workspace, automation, macos]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## 定义
|
||||
通过命令行界面（CLI）管理 Google Workspace 全部服务（Gmail/Calendar/Drive/Contacts/Docs/Sheets）的工具，支撑脚本化与自动化工作流。
|
||||
|
||||
## 核心工具
|
||||
- [[gog CLI]]：macOS 专属，Homebrew 安装，支持 Gmail/Calendar/Drive/Contacts/Docs/Sheets
|
||||
|
||||
## 关键机制
|
||||
- **OAuth 双层验证**：OAuth 凭证（身份）+ API Enablement（权限）缺一不可
|
||||
- **账号级默认设置**：export GOG_ACCOUNT=ishenwei@gmail.com 避免每次指定账号
|
||||
- **故障排除关键**：403 accessNotConfigured 的根因是 API 未启用而非 OAuth 问题
|
||||
|
||||
## 应用场景
|
||||
- 邮件自动化（定时搜索/发送/归档）
|
||||
- 日历自动化（定时检查日程/创建事件）
|
||||
- 文档导出自动化（定时备份 Docs 内容）
|
||||
|
||||
## 关联
|
||||
- [[gog CLI]] 是 Google Workspace CLI 在 macOS 的具体实现
|
||||
- [[n8n Workflow自动化]] 可通过 gog CLI 作为节点调用 Google 服务
|
||||
|
||||
## Aliases
|
||||
- Google CLI
|
||||
- gog
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
---
|
||||
title: "Graph View"
|
||||
type: concept
|
||||
tags: [Obsidian, 知识管理]
|
||||
sources: ["养虾日记3-Obsidian-Gitea持久化笔记系统.md"]
|
||||
last_updated: 2026-04-15
|
||||
---
|
||||
|
||||
## Definition
|
||||
Obsidian 的 Graph View 将所有 Wiki 页面以节点展示，双链关系自动连线，是知识网络的可视化健康检查工具。
|
||||
|
||||
## Two Usage Patterns
|
||||
- **健康检查**：没有任何页面链接指向它 → 孤岛页面，需要补上交叉引用
|
||||
- **发现盲区**：某个概念被很多页面提到但自己还没有独立页面 → 图谱里显示为灰色幽灵节点
|
||||
|
||||
## Karpathy's Insight
|
||||
Graph View 是 LLM Wiki 的"知识盲区探测器"：灰色幽灵节点提醒应该为它建一个专页。
|
||||
|
||||
## Related Concepts
|
||||
- [[LLM Wiki]]：Graph View 是 LLM Wiki 范式的重要工具
|
||||
- [[知识可发现性]]：双向链接 + Graph View 让知识形成网络而非孤岛
|
||||
@@ -1,27 +0,0 @@
|
||||
# Groupthink
|
||||
|
||||
## Definition
|
||||
A psychological phenomenon in which a group of individuals prioritizes consensus and harmony over critical evaluation of alternatives, leading to poor decision-making. In multi-agent systems, it occurs when agents influence each other rather than making independent judgments.
|
||||
|
||||
## Risk in Multi-Agent Consensus
|
||||
- If agents have feedback loops between them
|
||||
- Earlier agents' conclusions influence later agents
|
||||
- The group converges on the first plausible answer rather than truth
|
||||
- Results become correlated, defeating the purpose of voting
|
||||
|
||||
## Prevention
|
||||
- Agents must run like a **blind experiment** — no communication between them
|
||||
- Same input provided independently to each agent
|
||||
- No knowledge of what other agents concluded
|
||||
- Results aggregated only after all agents have responded
|
||||
|
||||
## The "Blind Experiment" Principle
|
||||
- Agents should not know they're part of a consensus
|
||||
- Each agent should independently evaluate the same input
|
||||
- Only the aggregator knows the full set of responses
|
||||
- This maximizes diversity and minimizes correlation
|
||||
|
||||
## Related Concepts
|
||||
- [[Bandwagon Effect]]
|
||||
- [[Multi-Agent Consensus]]
|
||||
- [[Sycophancy]]
|
||||
@@ -1,38 +0,0 @@
|
||||
# Hallucination (幻觉)
|
||||
|
||||
## Definition
|
||||
|
||||
The phenomenon where an LLM generates information that appears plausible but is actually false, fabricated, or not grounded in its input or training data. The model "makes things up" with confidence, presenting fiction as fact.
|
||||
|
||||
In the context of Chinese documentation: 大模型总是一本正经的回答问题，但其实是在胡说八道。LLM 在面对陌生领域时，只会在答案中写一个"解"字（因为 LLM 的知识局限于特定数据集），然后就开始放飞自我生成看似合理但实际错误的内容。
|
||||
|
||||
## Key Statistics
|
||||
- If a single model hallucinates 20% of the time
|
||||
- 3 models hallucinating the exact same lie: 0.8% (0.2³ = 0.008)
|
||||
- This mathematical property is the foundation of Consensus voting
|
||||
|
||||
## Causes
|
||||
- Stochastic nature of LLM token generation
|
||||
- Training data includes conflicting or incorrect information
|
||||
- Model may lack specific knowledge but generates plausible substitutes
|
||||
- Prompting that asks for creative or speculative content
|
||||
|
||||
## Impact on Multi-Agent Systems
|
||||
- Errors propagate through agent topologies
|
||||
- Can make entire system unreliable if not contained
|
||||
- Multiple architectures address this: Consensus, Validator, etc.
|
||||
|
||||
## Mitigation
|
||||
- [[Multi-Agent Consensus]] — majority voting cancels noise
|
||||
- [[Validator]] checkpoints to catch errors
|
||||
- Deterministic code validation where possible
|
||||
- Don't anthropomorphize — force correctness architecturally
|
||||
|
||||
## Related Concepts
|
||||
- [[Sycophancy]]
|
||||
- [[Context Drift]]
|
||||
- [[Multi-Agent Consensus]]
|
||||
- [[Validator]]
|
||||
- [[LLM Reliability Engineering]]
|
||||
- [[RAG]] — 检索增强生成，通过外部知识检索解决幻觉问题，可将正确率从 60% 提升至 90%
|
||||
- [[Embedding]] — 向量化技术，支撑 RAG 的语义检索基础
|
||||
26
wiki/concepts/High-Availability.md
Normal file
26
wiki/concepts/High-Availability.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: High Availability
|
||||
type: concept
|
||||
tags: [Cloud, Reliability, Infrastructure]
|
||||
sources: [The-Myths-and-Misconceptions-About-Cloud-Computing-LinkedIn.md]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
高可用性（High Availability）是指通过冗余设计、自动故障转移和分布式基础设施确保系统在任意时刻均可访问的设计原则。
|
||||
|
||||
## Core Mechanisms
|
||||
- 冗余基础设施（Redundant Infrastructure）：关键组件多点部署
|
||||
- 自动故障转移（Automated Failover）：故障时自动切换到备用系统
|
||||
- 全球数据中心分布（Global Data Center Distribution）：跨地域部署
|
||||
- SLA 保障：服务级别协议保证 uptime 通常超过 99.99%
|
||||
|
||||
## Key Claims
|
||||
- 主要云提供商提供保证 uptime 超过 99.99% 的 SLA
|
||||
- 冗余基础设施、自动故障转移和全球数据中心分布增强了可靠性
|
||||
- 云解决方案具有高度弹性
|
||||
|
||||
## Connections
|
||||
- [[Cloud-Native]] ← requires ← [[High-Availability]]：云原生应用依赖高可用性
|
||||
- [[Multi-Cloud]] ← enables ← [[High-Availability]]：多云部署增强高可用性
|
||||
- [[混沌工程]] ← tests ← [[High-Availability]]：混沌工程主动测试系统韧性
|
||||
37
wiki/concepts/Hybrid-Cloud.md
Normal file
37
wiki/concepts/Hybrid-Cloud.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Hybrid Cloud"
|
||||
type: concept
|
||||
tags: [Cloud, Deployment-Model]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption, Public-vs-Private-vs-Hybrid-Cloud-Differences-Explained]
|
||||
last_updated: 2025-06-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
Hybrid Cloud（混合云）是一种组合使用公有云和私有云的云计算部署模式。
|
||||
|
||||
## Definition
|
||||
混合云将公有云的可扩展性与私有云的安全性和控制性相结合，允许工作负载在两种环境之间灵活移动。典型用例包括：使用私有云处理敏感工作负载，使用公有云应对流量峰值，以及实现业务连续性和灾难恢复。
|
||||
|
||||
## Key Characteristics
|
||||
- 结合公有云弹性和私有云安全性
|
||||
- 支持 policy-driven deployment（策略驱动部署）
|
||||
- 可实现跨混合环境的工作负载优化
|
||||
- 支持同构（单一供应商）或异构（多供应商）架构
|
||||
|
||||
## Advantages
|
||||
- 灵活性：根据安全、性能、成本需求分配工作负载
|
||||
- 扩展性：无需高额资本支出即可获得额外计算能力
|
||||
- 可靠性：分布式架构提升系统韧性
|
||||
- 成本效率：敏感工作负载在私有云，普通负载在公有云
|
||||
|
||||
## Limitations
|
||||
- 复杂的成本管理
|
||||
- 跨云集成挑战
|
||||
- 额外的架构复杂性
|
||||
- 数据传输安全风险
|
||||
|
||||
## Connections
|
||||
- [[Hybrid-Cloud]] ← type_of ← [[Cloud-Adoption]]
|
||||
- [[Hybrid-Cloud]] ← combines ← [[Public-Cloud]]
|
||||
- [[Hybrid-Cloud]] ← combines ← [[Private-Cloud]]
|
||||
|
||||
22
wiki/concepts/Hyperautomation.md
Normal file
22
wiki/concepts/Hyperautomation.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "Hyperautomation"
|
||||
type: concept
|
||||
tags: [Automation, DevOps, ITSM]
|
||||
sources: [modern-itsm-driving-efficiency-security-resilience]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
Hyperautomation（超级自动化）是结合 AI、ML 和多种自动化工具实现端到端流程自动化的方法论。
|
||||
|
||||
## Definition
|
||||
Hyperautomation 是 Gartner 提出的技术趋势，融合机器人流程自动化（RPA）、AI、ML 和低代码平台，实现复杂业务流程的端到端自动化。与传统自动化不同，Hyperautomation 可处理非结构化数据和做出智能决策。
|
||||
|
||||
## Key Attributes
|
||||
- **核心组件**：RPA、AI、ML、低代码/无代码平台、流程挖掘
|
||||
- **应用场景**：ITSM 流程自动化、业务流程优化、决策自动化
|
||||
- **与 ITSM 结合**：实现自学习、预测性和自主 IT 运营
|
||||
|
||||
## Connections
|
||||
- [[ITSM]] ← 演进 ← [[Hyperautomation]]
|
||||
- [[AIOps]] ← 集成 ← [[Hyperautomation]]
|
||||
21
wiki/concepts/IAST.md
Normal file
21
wiki/concepts/IAST.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "IAST（交互式应用安全测试）"
|
||||
type: concept
|
||||
tags: [安全, 测试, 运行时]
|
||||
sources: [what-is-devsecops-best-practices-benefits-and-tools]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
IAST（Interactive Application Security Testing）在应用程序运行时动态分析行为，检测运行时刻的安全问题，可发现 SAST 和 DAST 可能遗漏的漏洞。
|
||||
|
||||
## Characteristics
|
||||
- 在测试和部署阶段使用
|
||||
- 通过插桩技术监控应用行为
|
||||
- 实时检测运行时漏洞
|
||||
- 适合测试环境
|
||||
|
||||
## Connections
|
||||
- [[DevSecOps]] ← uses ← [[IAST]]
|
||||
- [[SAST]] ← complements ← [[IAST]]
|
||||
- [[DAST]] ← complements ← [[IAST]]
|
||||
23
wiki/concepts/ITSM.md
Normal file
23
wiki/concepts/ITSM.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "ITSM"
|
||||
type: concept
|
||||
tags: [IT, Service Management, DevOps]
|
||||
sources: [modern-itsm-driving-efficiency-security-resilience]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Summary
|
||||
ITSM（IT 服务管理）是管理 IT 服务交付和支持的框架，从传统工单系统演变为战略推动者。
|
||||
|
||||
## Definition
|
||||
IT Service Management（IT 服务管理）是确保 IT 服务以满足业务需求的方式交付和支持的实践和方法论。现代 ITSM 融合 AIOps、Hyperautomation 和零信任架构，演变为 ITSM 2.0。
|
||||
|
||||
## Key Attributes
|
||||
- **核心领域**：Problem Management、Incident Management、Change Management、Release Management、Configuration Management、Asset Management、Security & Compliance、DR/BC
|
||||
- **技术演进**：AIOps、Hyperautomation、自愈 IT 生态
|
||||
- **业务价值**：运营卓越、风险缓解、创新加速
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] → 集成 → [[ITSM]]
|
||||
- [[AIOps]] → 驱动 → [[ITSM]]
|
||||
- [[Zero Trust Architecture]] → 保护 → [[ITSM]]
|
||||
25
wiki/concepts/IaC.md
Normal file
25
wiki/concepts/IaC.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "IaC"
|
||||
type: concept
|
||||
tags: [devops, infrastructure, automation]
|
||||
sources: [cloud-devop-maturity-guideline, DevOps-Culture-and-Transformation]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## Definition
|
||||
IaC（Infrastructure as Code，基础设施即代码）是一种通过代码和版本控制管理基础设施的方法，替代手动配置和交互式界面操作。
|
||||
|
||||
## Key Benefits
|
||||
- **可重复性**：相同配置可多次部署
|
||||
- **可版本化**：配置变更可追溯
|
||||
- **可测试性**：基础设施变更可自动化测试
|
||||
- **一致性**：消除人工配置差异
|
||||
|
||||
## Key Tools
|
||||
- [[Terraform]]：声明式 IaC 工具
|
||||
- [[Ansible]]：命令式配置管理
|
||||
- AWS CloudFormation：（仅在另一源文件中提及）
|
||||
|
||||
## Connections
|
||||
- [[DevOps 成熟度模型]] ← 技术支柱 ← [[IaC]]
|
||||
- [[CI/CD 流水线]] ← 依赖 ← [[IaC]]
|
||||
22
wiki/concepts/IaaS.md
Normal file
22
wiki/concepts/IaaS.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "IaaS (Infrastructure as a Service)"
|
||||
type: concept
|
||||
tags: [Cloud, Service-Model]
|
||||
sources: [Cloud-Maturity-Model-A-Detailed-Guide-For-Cloud-Adoption]
|
||||
last_updated: 2025-02-28
|
||||
---
|
||||
|
||||
## Summary
|
||||
IaaS（基础设施即服务）是云计算三大服务模型之一，提供虚拟化的计算资源。
|
||||
|
||||
## Definition
|
||||
IaaS 通过互联网提供虚拟化的计算资源，包括服务器、存储和网络设备。
|
||||
|
||||
## Example Providers
|
||||
- Amazon Web Services (AWS) EC2
|
||||
- Microsoft Azure Virtual Machines
|
||||
- Google Compute Engine
|
||||
|
||||
## Connections
|
||||
- [[IaaS]] ← part_of ← [[Cloud-Maturity-Model]]
|
||||
- [[IaaS]] ← type_of ← [[Cloud-Service-Models]]
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: "Identity Locking"
|
||||
type: concept
|
||||
tags: [nano-banana-pro, image-generation, character-consistency, reference-image]
|
||||
last_updated: 2026-04-16
|
||||
---
|
||||
|
||||
## 定义
|
||||
通过多张参考图锁定角色/人物身份，在新场景保持面部一致性的技术。Nano-Banana Pro 支持 14 张参考图（6 张高精度模式）。
|
||||
|
||||
## 核心机制
|
||||
1. 上传参考图像（最多 14 张，高精度模式 6 张）
|
||||
2. 明确指令："Keep the person's facial features exactly the same as Image 1"
|
||||
3. 描述场景/表情/动作的变化，保持身份不变
|
||||
|
||||
## 应用场景
|
||||
- **品牌资产生成**：同一人物/模特出现在不同场景
|
||||
- **故事创作**：角色跨多个图像保持一致
|
||||
- ** Viral Thumbnail**：Identity + Text + Graphics 一体化生成
|
||||
|
||||
## 与微调 LoRA 的区别
|
||||
- Identity Locking：即时生效，无需训练，支持 14 张参考图组合
|
||||
- LoRA：需额外训练，永久保留风格
|
||||
|
||||
## Connections
|
||||
- [[Identity Locking]] ← 技术基础 ← [[Nano-Banana Pro]]
|
||||
- [[主体一致性]] ← 相关概念 ← [[Identity Locking]]
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user