chore: sync local project changes
This commit is contained in:
Shen Wei
@@ -1,32 +1,32 @@
|
||||
---
|
||||
title: "AIFinOps"
|
||||
type: concept
|
||||
tags: ["finops", "cost-optimization", "cloud-economics"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AI FinOps
|
||||
- AI Financial Operations
|
||||
- LLM Cost Management
|
||||
|
||||
## Definition
|
||||
AI FinOps（Financial Operations）是 [[AutonomousOptimizationArchitect]] 的成本管理框架——持续追踪每个 LLM Provider 的 Token 消耗、成本、延迟和输出质量，建立历史性能数据库，为 [[SemanticRouting]] 提供成本感知的决策依据。目标是实现 AI 运营成本的可预测性和可控性。
|
||||
|
||||
## Mechanism
|
||||
1. **遥测数据收集**：每次 API 调用记录 Token 数量、响应时间、错误率、成本
|
||||
2. **成本建模**：按 Provider、模型、任务类型建立成本分解模型
|
||||
3. **异常检测**：检测异常流量模式（如 500% 流量突增，可能为 bot 攻击）
|
||||
4. **预算告警**：当成本接近阈值时触发告警
|
||||
5. **优化建议**：基于历史数据生成成本优化建议（如切换到 Gemini Flash）
|
||||
|
||||
## Key Properties
|
||||
- **成本透明**：每百万 Token 成本精确追踪
|
||||
- **可预测性**：基于历史趋势预测未来成本
|
||||
- **与治理对齐**：为 [[CircuitBreaker]] 提供成本异常检测数据
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — AIFinOps 是成本管理的核心框架
|
||||
- [[SemanticRouting]] — 成本数据是路由决策的关键输入
|
||||
- [[CircuitBreaker]] — 异常成本流量触发熔断保护
|
||||
---
|
||||
title: "AIFinOps"
|
||||
type: concept
|
||||
tags: ["finops", "cost-optimization", "cloud-economics"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AI FinOps
|
||||
- AI Financial Operations
|
||||
- LLM Cost Management
|
||||
|
||||
## Definition
|
||||
AI FinOps（Financial Operations）是 [[AutonomousOptimizationArchitect]] 的成本管理框架——持续追踪每个 LLM Provider 的 Token 消耗、成本、延迟和输出质量，建立历史性能数据库，为 [[SemanticRouting]] 提供成本感知的决策依据。目标是实现 AI 运营成本的可预测性和可控性。
|
||||
|
||||
## Mechanism
|
||||
1. **遥测数据收集**：每次 API 调用记录 Token 数量、响应时间、错误率、成本
|
||||
2. **成本建模**：按 Provider、模型、任务类型建立成本分解模型
|
||||
3. **异常检测**：检测异常流量模式（如 500% 流量突增，可能为 bot 攻击）
|
||||
4. **预算告警**：当成本接近阈值时触发告警
|
||||
5. **优化建议**：基于历史数据生成成本优化建议（如切换到 Gemini Flash）
|
||||
|
||||
## Key Properties
|
||||
- **成本透明**：每百万 Token 成本精确追踪
|
||||
- **可预测性**：基于历史趋势预测未来成本
|
||||
- **与治理对齐**：为 [[CircuitBreaker]] 提供成本异常检测数据
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — AIFinOps 是成本管理的核心框架
|
||||
- [[SemanticRouting]] — 成本数据是路由决策的关键输入
|
||||
- [[CircuitBreaker]] — 异常成本流量触发熔断保护
|
||||
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: AIOps
|
||||
tags:
|
||||
- ai
|
||||
- devops
|
||||
- it-operations
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
created: 2026-04-22
|
||||
---
|
||||
|
||||
# AIOps
|
||||
|
||||
## Definition
|
||||
|
||||
AIOps (Artificial Intelligence for IT Operations) is the application of artificial intelligence and machine learning to IT operations. It automates the detection, diagnosis, and resolution of operational issues in cloud environments.
|
||||
|
||||
## Purpose
|
||||
|
||||
AIOps enables:
|
||||
- **Proactive issue detection** — Identifying problems before they impact users
|
||||
- **Intelligent alerting** — Reducing noise and focusing on actionable alerts
|
||||
- **Automated root cause analysis** — Accelerating incident resolution
|
||||
- **Predictive analytics** — Forecasting capacity needs and potential failures
|
||||
|
||||
## Relationship with Cloud Service Delivery
|
||||
|
||||
AIOps is a natural extension of the [[Cloud Service Delivery]] operational model, specifically supporting:
|
||||
- [[Performance & Availability Monitoring]]
|
||||
- [[Incident Management]]
|
||||
- [[Problem Management]]
|
||||
- [[Change Management]]
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Cloud Service Delivery]]
|
||||
- [[Cloud DevOps Maturity Model]]
|
||||
- [[Observability]]
|
||||
- [[Incident Management]]
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[what-i-know-about-cloud-service-delivery-1]]
|
||||
|
||||
## AIOps Capabilities
|
||||
|
||||
```python
|
||||
# Typical AIOps capabilities
|
||||
aiops_capabilities = [
|
||||
"Anomaly Detection", # Identify unusual patterns
|
||||
"Root Cause Analysis", # Automatic diagnosis
|
||||
"Predictive Maintenance", # Forecast failures
|
||||
"Smart Alerting", # Reduce alert fatigue
|
||||
"Automated Remediation", # Self-healing systems
|
||||
"Capacity Optimization" # Resource optimization
|
||||
]
|
||||
```
|
||||
---
|
||||
title: AIOps
|
||||
tags:
|
||||
- ai
|
||||
- devops
|
||||
- it-operations
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
created: 2026-04-22
|
||||
---
|
||||
|
||||
# AIOps
|
||||
|
||||
## Definition
|
||||
|
||||
AIOps (Artificial Intelligence for IT Operations) is the application of artificial intelligence and machine learning to IT operations. It automates the detection, diagnosis, and resolution of operational issues in cloud environments.
|
||||
|
||||
## Purpose
|
||||
|
||||
AIOps enables:
|
||||
- **Proactive issue detection** — Identifying problems before they impact users
|
||||
- **Intelligent alerting** — Reducing noise and focusing on actionable alerts
|
||||
- **Automated root cause analysis** — Accelerating incident resolution
|
||||
- **Predictive analytics** — Forecasting capacity needs and potential failures
|
||||
|
||||
## Relationship with Cloud Service Delivery
|
||||
|
||||
AIOps is a natural extension of the [[Cloud Service Delivery]] operational model, specifically supporting:
|
||||
- [[Performance & Availability Monitoring]]
|
||||
- [[Incident Management]]
|
||||
- [[Problem Management]]
|
||||
- [[Change Management]]
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Cloud Service Delivery]]
|
||||
- [[Cloud DevOps Maturity Model]]
|
||||
- [[Observability]]
|
||||
- [[Incident Management]]
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[what-i-know-about-cloud-service-delivery-1]]
|
||||
|
||||
## AIOps Capabilities
|
||||
|
||||
```python
|
||||
# Typical AIOps capabilities
|
||||
aiops_capabilities = [
|
||||
"Anomaly Detection", # Identify unusual patterns
|
||||
"Root Cause Analysis", # Automatic diagnosis
|
||||
"Predictive Maintenance", # Forecast failures
|
||||
"Smart Alerting", # Reduce alert fatigue
|
||||
"Automated Remediation", # Self-healing systems
|
||||
"Capacity Optimization" # Resource optimization
|
||||
]
|
||||
```
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "Alert Management"
|
||||
type: concept
|
||||
tags: [monitoring, alerting, devops, sre]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Alert Management（告警管理）
|
||||
|
||||
**中文名称：** 告警管理
|
||||
|
||||
**类型：** 运维流程与方法论
|
||||
|
||||
**别名：**
|
||||
- 告警管理
|
||||
- 告警分发
|
||||
- Alert Routing
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
告警管理（Alert Management）是指从告警**生成 → 接收 → 分类 → 分发 → 响应 → 关闭**的全生命周期管理流程，目的是在关键系统异常时及时通知相关人员，同时避免告警风暴和告警疲劳。
|
||||
|
||||
**告警生命周期：**
|
||||
1. **生成（Generate）：** 监控系统（Prometheus）基于规则判断是否触发告警
|
||||
2. **转发（Forward）：** Prometheus 通过 Alertmanager API 发送告警
|
||||
3. **分发表单（Dismiss）：** Alertmanager 执行抑制、分组、静默
|
||||
4. **路由（Route）：** 按标签/严重级别路由到对应通知渠道
|
||||
5. **响应（Respond）：** 值班人员收到通知并处理
|
||||
6. **关闭（Resolve）：** 问题解决后告警自动消失
|
||||
|
||||
**告警治理最佳实践：**
|
||||
- **SLO/SLA 驱动：** 告警应与业务关键指标绑定，而非基础设施细节
|
||||
- **分级告警：** Critical / Warning / Info 三级，避免所有告警同等紧急
|
||||
- **抑制规则：** 根因告警触发时自动抑制派生告警
|
||||
- **静默期：** 维护窗口内临时屏蔽告警
|
||||
- **On-call Rotation：** 值班轮换确保 24/7 有人响应
|
||||
|
||||
**告警评估黄金法则：** 每条告警必须有明确处理步骤；无法立即采取行动的告警应该被抑制或降低级别
|
||||
|
||||
---
|
||||
|
||||
## Prometheus 告警管理架构
|
||||
|
||||
```
|
||||
Prometheus (规则判断) → Alertmanager (抑制/分组/路由) → 通知渠道 (邮件/Slack/PagerDuty/电话)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
---
|
||||
title: "Alert Management"
|
||||
type: concept
|
||||
tags: [monitoring, alerting, devops, sre]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Alert Management（告警管理）
|
||||
|
||||
**中文名称：** 告警管理
|
||||
|
||||
**类型：** 运维流程与方法论
|
||||
|
||||
**别名：**
|
||||
- 告警管理
|
||||
- 告警分发
|
||||
- Alert Routing
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
告警管理（Alert Management）是指从告警**生成 → 接收 → 分类 → 分发 → 响应 → 关闭**的全生命周期管理流程，目的是在关键系统异常时及时通知相关人员，同时避免告警风暴和告警疲劳。
|
||||
|
||||
**告警生命周期：**
|
||||
1. **生成（Generate）：** 监控系统（Prometheus）基于规则判断是否触发告警
|
||||
2. **转发（Forward）：** Prometheus 通过 Alertmanager API 发送告警
|
||||
3. **分发表单（Dismiss）：** Alertmanager 执行抑制、分组、静默
|
||||
4. **路由（Route）：** 按标签/严重级别路由到对应通知渠道
|
||||
5. **响应（Respond）：** 值班人员收到通知并处理
|
||||
6. **关闭（Resolve）：** 问题解决后告警自动消失
|
||||
|
||||
**告警治理最佳实践：**
|
||||
- **SLO/SLA 驱动：** 告警应与业务关键指标绑定，而非基础设施细节
|
||||
- **分级告警：** Critical / Warning / Info 三级，避免所有告警同等紧急
|
||||
- **抑制规则：** 根因告警触发时自动抑制派生告警
|
||||
- **静默期：** 维护窗口内临时屏蔽告警
|
||||
- **On-call Rotation：** 值班轮换确保 24/7 有人响应
|
||||
|
||||
**告警评估黄金法则：** 每条告警必须有明确处理步骤；无法立即采取行动的告警应该被抑制或降低级别
|
||||
|
||||
---
|
||||
|
||||
## Prometheus 告警管理架构
|
||||
|
||||
```
|
||||
Prometheus (规则判断) → Alertmanager (抑制/分组/路由) → 通知渠道 (邮件/Slack/PagerDuty/电话)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
|
||||
@@ -1,103 +1,103 @@
|
||||
---
|
||||
title: "Caddy"
|
||||
type: concept
|
||||
tags: [networking, web-server, https, reverse-proxy, golang]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Caddy Server
|
||||
- Caddy Web Server
|
||||
- Caddyfile
|
||||
|
||||
## Definition
|
||||
Caddy 是一款由 Go 语言编写的开源 Web 服务器，以其零配置自动 HTTPS 特性著称——首次访问域名时自动向 Let's Encrypt 申请并续期 SSL/TLS 证书，无需手动配置。支持反向代理、静态文件服务、FastCGI、负载均衡等常用功能。Caddyfile 是其独特的配置格式，简洁易读，适合个人和小型部署。
|
||||
|
||||
## Core Features
|
||||
- **自动 HTTPS**：首次访问自动申请 Let's Encrypt 证书，支持 ACME DNS-01 挑战（适合内网）
|
||||
- **HTTP/3 支持**：默认启用 QUIC/HTTP3
|
||||
- **反向代理**：简洁的 `reverse_proxy` 指令
|
||||
- **Caddyfile**：人类可读的配置文件格式
|
||||
- **默认 TLS 1.3**：安全开箱即用
|
||||
- **热重载**：配置修改自动生效，无需重启
|
||||
|
||||
## Caddyfile 语法示例
|
||||
```caddy
|
||||
# 基础反向代理
|
||||
example.com {
|
||||
reverse_proxy localhost:8080
|
||||
}
|
||||
|
||||
# 多域名配置
|
||||
nas.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:15000
|
||||
}
|
||||
|
||||
n8n.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:15678
|
||||
}
|
||||
|
||||
# 带基础认证
|
||||
admin.example.com {
|
||||
basicauth /* {
|
||||
admin <hashed_password>
|
||||
}
|
||||
reverse_proxy localhost:5678
|
||||
}
|
||||
```
|
||||
|
||||
## 常用命令
|
||||
```bash
|
||||
# 验证配置语法
|
||||
sudo caddy validate --config /etc/caddy/Caddyfile
|
||||
|
||||
# 热重载配置
|
||||
sudo caddy reload
|
||||
|
||||
# 彻底重启
|
||||
sudo systemctl restart caddy
|
||||
|
||||
# 查看状态
|
||||
sudo systemctl status caddy
|
||||
|
||||
# 生成密码哈希
|
||||
caddy hash-password
|
||||
```
|
||||
|
||||
## 与 Nginx 的对比
|
||||
| 特性 | Caddy | Nginx |
|
||||
|------|-------|-------|
|
||||
| 自动 HTTPS | ✅ 默认 | ❌ 需手动配置 |
|
||||
| 配置语法 | 简洁 Caddyfile | 复杂块结构 |
|
||||
| 性能 | 略低于 Nginx | 极高 |
|
||||
| 热重载 | ✅ 原生支持 | ❌ 需 signal |
|
||||
| HTTP/3 | ✅ 默认 | 需额外编译 |
|
||||
| 学习曲线 | 低 | 中高 |
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：Caddy 反向代理到 frp 映射端口，提供 `*.ishenwei.online` HTTPS 访问
|
||||
- 映射关系：
|
||||
- `nas.ishenwei.online` → `127.0.0.1:15000`
|
||||
- `n8n.ishenwei.online` → `127.0.0.1:15678`
|
||||
- `transmission.ishenwei.online` → `127.0.0.1:19091`
|
||||
- `grafana.ishenwei.online` → `127.0.0.1:13000`
|
||||
- `navidrome.ishenwei.online` → `127.0.0.1:14533`
|
||||
- `calibre.ishenwei.online` → `127.0.0.1:18083`
|
||||
|
||||
## 重要限制
|
||||
- **Caddy 不处理 SSH**：SSH 穿透（TCP 映射）不走 Caddy，只依赖 frps + frpc
|
||||
- **Caddy 不处理 UDP**：UDP 流量（如 DNS）需要其他方案
|
||||
|
||||
## Related Concepts
|
||||
- [[反向代理]]：Caddy 是反向代理的具体实现
|
||||
- [[内网穿透]]：Caddy 通常与 frp 配合，Caddy 提供 HTTPS，frp 建立隧道
|
||||
- [[TCP隧道]]：Caddy 处理 HTTP/HTTPS 层；TCP 隧道（Caddy 不参与）
|
||||
|
||||
## Related Entities
|
||||
- [[RackNerd]]：Caddy 部署的 VPS 提供商
|
||||
- [[VPS]]：运行 Caddy 的公网服务器
|
||||
|
||||
## References
|
||||
- 官网: https://caddyserver.com/
|
||||
- 文档: https://caddyserver.com/docs/
|
||||
- Caddyfile 语法: https://caddyserver.com/docs/caddyfile
|
||||
---
|
||||
title: "Caddy"
|
||||
type: concept
|
||||
tags: [networking, web-server, https, reverse-proxy, golang]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Caddy Server
|
||||
- Caddy Web Server
|
||||
- Caddyfile
|
||||
|
||||
## Definition
|
||||
Caddy 是一款由 Go 语言编写的开源 Web 服务器，以其零配置自动 HTTPS 特性著称——首次访问域名时自动向 Let's Encrypt 申请并续期 SSL/TLS 证书，无需手动配置。支持反向代理、静态文件服务、FastCGI、负载均衡等常用功能。Caddyfile 是其独特的配置格式，简洁易读，适合个人和小型部署。
|
||||
|
||||
## Core Features
|
||||
- **自动 HTTPS**：首次访问自动申请 Let's Encrypt 证书，支持 ACME DNS-01 挑战（适合内网）
|
||||
- **HTTP/3 支持**：默认启用 QUIC/HTTP3
|
||||
- **反向代理**：简洁的 `reverse_proxy` 指令
|
||||
- **Caddyfile**：人类可读的配置文件格式
|
||||
- **默认 TLS 1.3**：安全开箱即用
|
||||
- **热重载**：配置修改自动生效，无需重启
|
||||
|
||||
## Caddyfile 语法示例
|
||||
```caddy
|
||||
# 基础反向代理
|
||||
example.com {
|
||||
reverse_proxy localhost:8080
|
||||
}
|
||||
|
||||
# 多域名配置
|
||||
nas.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:15000
|
||||
}
|
||||
|
||||
n8n.ishenwei.online {
|
||||
reverse_proxy 127.0.0.1:15678
|
||||
}
|
||||
|
||||
# 带基础认证
|
||||
admin.example.com {
|
||||
basicauth /* {
|
||||
admin <hashed_password>
|
||||
}
|
||||
reverse_proxy localhost:5678
|
||||
}
|
||||
```
|
||||
|
||||
## 常用命令
|
||||
```bash
|
||||
# 验证配置语法
|
||||
sudo caddy validate --config /etc/caddy/Caddyfile
|
||||
|
||||
# 热重载配置
|
||||
sudo caddy reload
|
||||
|
||||
# 彻底重启
|
||||
sudo systemctl restart caddy
|
||||
|
||||
# 查看状态
|
||||
sudo systemctl status caddy
|
||||
|
||||
# 生成密码哈希
|
||||
caddy hash-password
|
||||
```
|
||||
|
||||
## 与 Nginx 的对比
|
||||
| 特性 | Caddy | Nginx |
|
||||
|------|-------|-------|
|
||||
| 自动 HTTPS | ✅ 默认 | ❌ 需手动配置 |
|
||||
| 配置语法 | 简洁 Caddyfile | 复杂块结构 |
|
||||
| 性能 | 略低于 Nginx | 极高 |
|
||||
| 热重载 | ✅ 原生支持 | ❌ 需 signal |
|
||||
| HTTP/3 | ✅ 默认 | 需额外编译 |
|
||||
| 学习曲线 | 低 | 中高 |
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：Caddy 反向代理到 frp 映射端口，提供 `*.ishenwei.online` HTTPS 访问
|
||||
- 映射关系：
|
||||
- `nas.ishenwei.online` → `127.0.0.1:15000`
|
||||
- `n8n.ishenwei.online` → `127.0.0.1:15678`
|
||||
- `transmission.ishenwei.online` → `127.0.0.1:19091`
|
||||
- `grafana.ishenwei.online` → `127.0.0.1:13000`
|
||||
- `navidrome.ishenwei.online` → `127.0.0.1:14533`
|
||||
- `calibre.ishenwei.online` → `127.0.0.1:18083`
|
||||
|
||||
## 重要限制
|
||||
- **Caddy 不处理 SSH**：SSH 穿透（TCP 映射）不走 Caddy，只依赖 frps + frpc
|
||||
- **Caddy 不处理 UDP**：UDP 流量（如 DNS）需要其他方案
|
||||
|
||||
## Related Concepts
|
||||
- [[反向代理]]：Caddy 是反向代理的具体实现
|
||||
- [[内网穿透]]：Caddy 通常与 frp 配合，Caddy 提供 HTTPS，frp 建立隧道
|
||||
- [[TCP隧道]]：Caddy 处理 HTTP/HTTPS 层；TCP 隧道（Caddy 不参与）
|
||||
|
||||
## Related Entities
|
||||
- [[RackNerd]]：Caddy 部署的 VPS 提供商
|
||||
- [[VPS]]：运行 Caddy 的公网服务器
|
||||
|
||||
## References
|
||||
- 官网: https://caddyserver.com/
|
||||
- 文档: https://caddyserver.com/docs/
|
||||
- Caddyfile 语法: https://caddyserver.com/docs/caddyfile
|
||||
|
||||
@@ -1,31 +1,31 @@
|
||||
---
|
||||
title: "CircuitBreaker"
|
||||
type: concept
|
||||
tags: ["reliability", "fault-tolerance", "llm-ops"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Circuit Breaker
|
||||
- 熔断器
|
||||
- Circuit Breaker Pattern
|
||||
|
||||
## Definition
|
||||
熔断器模式是 [[AutonomousOptimizationArchitect]] 的核心安全机制——当某个 LLM Provider 的失败频率超过阈值（如 HTTP 402/429 错误、响应超时）时，自动切断该 Provider 并切换至廉价兜底方案，同时触发告警通知人工介入。
|
||||
|
||||
## Mechanism
|
||||
1. **监测**：追踪每个 Provider 的失败计数和失败率
|
||||
2. **触发**：当失败次数超过 `maxRetries` 阈值，或检测到 HTTP 402/429 错误流时，立即 trip 熔断器
|
||||
3. **降级**：所有请求切换到预配置的廉价兜底 Provider（如 Gemini Flash）
|
||||
4. **恢复**：人工确认问题解决后手动重置，或经过冷却期后自动尝试恢复
|
||||
|
||||
## Key Properties
|
||||
- **防止成本失控**：阻止 Token 消耗攻击（如恶意 bot 短时间内大量请求）
|
||||
- **防止无限重试**：每个 Provider 配置最大重试次数 `maxRetries`
|
||||
- **分级降级**：逐级切换到更便宜的备用 Provider，直到找到可用路径
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — 使用 CircuitBreaker 作为金融护栏的核心实现
|
||||
- [[LLMasJudge]] — 评估 Provider 降级后输出质量是否可接受
|
||||
- [[ShadowTraffic]] — 熔断触发后可异步在影子流量中测试备用 Provider
|
||||
---
|
||||
title: "CircuitBreaker"
|
||||
type: concept
|
||||
tags: ["reliability", "fault-tolerance", "llm-ops"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Circuit Breaker
|
||||
- 熔断器
|
||||
- Circuit Breaker Pattern
|
||||
|
||||
## Definition
|
||||
熔断器模式是 [[AutonomousOptimizationArchitect]] 的核心安全机制——当某个 LLM Provider 的失败频率超过阈值（如 HTTP 402/429 错误、响应超时）时，自动切断该 Provider 并切换至廉价兜底方案，同时触发告警通知人工介入。
|
||||
|
||||
## Mechanism
|
||||
1. **监测**：追踪每个 Provider 的失败计数和失败率
|
||||
2. **触发**：当失败次数超过 `maxRetries` 阈值，或检测到 HTTP 402/429 错误流时，立即 trip 熔断器
|
||||
3. **降级**：所有请求切换到预配置的廉价兜底 Provider（如 Gemini Flash）
|
||||
4. **恢复**：人工确认问题解决后手动重置，或经过冷却期后自动尝试恢复
|
||||
|
||||
## Key Properties
|
||||
- **防止成本失控**：阻止 Token 消耗攻击（如恶意 bot 短时间内大量请求）
|
||||
- **防止无限重试**：每个 Provider 配置最大重试次数 `maxRetries`
|
||||
- **分级降级**：逐级切换到更便宜的备用 Provider，直到找到可用路径
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — 使用 CircuitBreaker 作为金融护栏的核心实现
|
||||
- [[LLMasJudge]] — 评估 Provider 降级后输出质量是否可接受
|
||||
- [[ShadowTraffic]] — 熔断触发后可异步在影子流量中测试备用 Provider
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: "Cloud Computing"
|
||||
type: concept
|
||||
tags: [cloud, infrastructure, iaas, paas, saas]
|
||||
sources: [the-myths-and-misconceptions-about-cloud-computing-linkedin, what-i-know-about-cloud-service-delivery-1, cloud-maturity-model-a-detailed-guide-for-cloud-adoption]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Cloud computing is the delivery of computing services—including servers, storage, databases, networking, software, analytics, and intelligence—over the Internet ("the cloud") to offer faster innovation, flexible resources, and economies of scale.
|
||||
|
||||
## Service Models
|
||||
|
||||
- **IaaS (Infrastructure as a Service)**: Provides virtualized computing resources over the internet (e.g., AWS EC2, Azure VMs)
|
||||
- **PaaS (Platform as a Service)**: Provides a platform for developing, running, and managing applications without dealing with infrastructure (e.g., AWS Elastic Beanstalk, Azure App Service)
|
||||
- **SaaS (Software as a Service)**: Provides software applications over the internet on a subscription basis (e.g., Microsoft 365, Salesforce)
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **On-demand self-service**: Provision resources as needed without human intervention
|
||||
- **Broad network access**: Access services over the network via standard mechanisms
|
||||
- **Resource pooling**: Multiple customers share infrastructure with logical separation
|
||||
- **Rapid elasticity**: Scale resources up or down dynamically
|
||||
- **Measured service**: Pay-as-you-go pricing model
|
||||
|
||||
## Common Misconceptions
|
||||
|
||||
According to [[the-myths-and-misconceptions-about-cloud-computing-linkedin]], the following misconceptions are prevalent:
|
||||
|
||||
1. **Cloud is not secure** → Reality: Major providers invest heavily in security (encryption, MFA, ISO 27001, HIPAA, GDPR compliance)
|
||||
2. **Cloud is just "someone else's computer"** → Reality: Cloud is a sophisticated network of data centers with redundancy and high availability
|
||||
3. **Cloud is too expensive** → Reality: Pay-as-you-go model with proper management can be cost-effective
|
||||
4. **You lose control of your data** → Reality: Cloud provides robust data governance and control tools
|
||||
5. **Cloud is only for large enterprises** → Reality: SMBs can leverage enterprise-grade technology without large upfront investments
|
||||
6. **Migration is too complex** → Reality: Phased migration and hybrid cloud solutions mitigate risks
|
||||
7. **Cloud performance is unreliable** → Reality: SLAs often guarantee 99.99%+ uptime
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Hybrid-Cloud]]: Combining on-premises infrastructure with public cloud
|
||||
- [[Multi-Cloud]]: Using multiple cloud providers simultaneously
|
||||
- [[Cloud-Migration]]: The process of moving workloads to the cloud
|
||||
- [[Cloud-Security]]: Security practices in cloud environments
|
||||
- [[Pay-as-you-go]]: Cost model based on actual usage
|
||||
- [[High-Availability]]: Design principle for minimizing downtime
|
||||
- [[Serverless-Computing]]: Event-driven computing without server management
|
||||
|
||||
## Aliases
|
||||
|
||||
- Cloud
|
||||
- 云计算
|
||||
---
|
||||
title: "Cloud Computing"
|
||||
type: concept
|
||||
tags: [cloud, infrastructure, iaas, paas, saas]
|
||||
sources: [the-myths-and-misconceptions-about-cloud-computing-linkedin, what-i-know-about-cloud-service-delivery-1, cloud-maturity-model-a-detailed-guide-for-cloud-adoption]
|
||||
last_updated: 2025-03-02
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Cloud computing is the delivery of computing services—including servers, storage, databases, networking, software, analytics, and intelligence—over the Internet ("the cloud") to offer faster innovation, flexible resources, and economies of scale.
|
||||
|
||||
## Service Models
|
||||
|
||||
- **IaaS (Infrastructure as a Service)**: Provides virtualized computing resources over the internet (e.g., AWS EC2, Azure VMs)
|
||||
- **PaaS (Platform as a Service)**: Provides a platform for developing, running, and managing applications without dealing with infrastructure (e.g., AWS Elastic Beanstalk, Azure App Service)
|
||||
- **SaaS (Software as a Service)**: Provides software applications over the internet on a subscription basis (e.g., Microsoft 365, Salesforce)
|
||||
|
||||
## Key Characteristics
|
||||
|
||||
- **On-demand self-service**: Provision resources as needed without human intervention
|
||||
- **Broad network access**: Access services over the network via standard mechanisms
|
||||
- **Resource pooling**: Multiple customers share infrastructure with logical separation
|
||||
- **Rapid elasticity**: Scale resources up or down dynamically
|
||||
- **Measured service**: Pay-as-you-go pricing model
|
||||
|
||||
## Common Misconceptions
|
||||
|
||||
According to [[the-myths-and-misconceptions-about-cloud-computing-linkedin]], the following misconceptions are prevalent:
|
||||
|
||||
1. **Cloud is not secure** → Reality: Major providers invest heavily in security (encryption, MFA, ISO 27001, HIPAA, GDPR compliance)
|
||||
2. **Cloud is just "someone else's computer"** → Reality: Cloud is a sophisticated network of data centers with redundancy and high availability
|
||||
3. **Cloud is too expensive** → Reality: Pay-as-you-go model with proper management can be cost-effective
|
||||
4. **You lose control of your data** → Reality: Cloud provides robust data governance and control tools
|
||||
5. **Cloud is only for large enterprises** → Reality: SMBs can leverage enterprise-grade technology without large upfront investments
|
||||
6. **Migration is too complex** → Reality: Phased migration and hybrid cloud solutions mitigate risks
|
||||
7. **Cloud performance is unreliable** → Reality: SLAs often guarantee 99.99%+ uptime
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Hybrid-Cloud]]: Combining on-premises infrastructure with public cloud
|
||||
- [[Multi-Cloud]]: Using multiple cloud providers simultaneously
|
||||
- [[Cloud-Migration]]: The process of moving workloads to the cloud
|
||||
- [[Cloud-Security]]: Security practices in cloud environments
|
||||
- [[Pay-as-you-go]]: Cost model based on actual usage
|
||||
- [[High-Availability]]: Design principle for minimizing downtime
|
||||
- [[Serverless-Computing]]: Event-driven computing without server management
|
||||
|
||||
## Aliases
|
||||
|
||||
- Cloud
|
||||
- 云计算
|
||||
|
||||
@@ -1,74 +1,74 @@
|
||||
---
|
||||
title: "Cloud Cost Optimization"
|
||||
type: concept
|
||||
tags: [Cloud, FinOps, Cost Management, Cloud Operations]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Cloud Cost Optimization (云成本优化)
|
||||
|
||||
## Definition
|
||||
**Cloud Cost Optimization** is the practice of reducing unnecessary cloud spending while maintaining performance, security, and reliability. It involves monitoring, analyzing, and adjusting cloud resource usage to achieve maximum value.
|
||||
|
||||
## Key Tactics
|
||||
|
||||
### 1. Reserved Instances & Spot Instances
|
||||
- **Reserved Instances**: 40-70% cost reduction compared to on-demand
|
||||
- **Spot Instances**: Up to 90% discount for interruptible workloads
|
||||
- Strategic commitment for predictable workloads
|
||||
|
||||
### 2. Auto-Scaling & Right-Sizing
|
||||
- Automatically adjust resources based on demand
|
||||
- Match instance types to actual workload needs
|
||||
- Terminate underutilized resources
|
||||
|
||||
### 3. Resource Tagging & Monitoring
|
||||
- Track spending by teams, projects, and workloads
|
||||
- Real-time cost visibility
|
||||
- Budget alerts and anomaly detection
|
||||
|
||||
### 4. Storage Optimization
|
||||
- Delete unused snapshots and volumes
|
||||
- Use lifecycle policies
|
||||
- Choose appropriate storage classes
|
||||
|
||||
### 5. Network Cost Optimization
|
||||
- Minimize data transfer costs
|
||||
- Use VPC endpoints
|
||||
- Optimize traffic routes
|
||||
|
||||
## Cloud Provider Cost Management Tools
|
||||
|
||||
| Provider | Tool | Key Features |
|
||||
|----------|------|-------------|
|
||||
| AWS | AWS Cost Explorer | Real-time cost monitoring, savings plans, budget alerts |
|
||||
| Azure | Azure Cost Management | Cost tracking, reserved instances, predictive analysis |
|
||||
| GCP | GCP Billing Reports | AI-driven cost insights, budget tracking |
|
||||
|
||||
## FinOps Integration
|
||||
- Cloud Cost Optimization is a core component of [[FinOps]]
|
||||
- Continuous optimization cycle: Inform → Optimize → Operate
|
||||
- Collaboration between finance, engineering, and operations
|
||||
|
||||
## Case Studies
|
||||
|
||||
### E-commerce Company
|
||||
- Leveraged Auto-Scaling and Reserved Instances across AWS and Azure
|
||||
- **Result**: $500,000 annual billing savings
|
||||
|
||||
### SaaS Company
|
||||
- Used Reserved Instances and Autoscaling Policies
|
||||
- **Result**: 35% reduction in cloud costs
|
||||
|
||||
## Related Concepts
|
||||
- [[FinOps]]
|
||||
- [[Cloud Operating Model]]
|
||||
- [[Cloud Governance]]
|
||||
- [[Rightsizing]]
|
||||
- [[Pay-as-you-go]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Azure]]
|
||||
- [[Google-Cloud]]
|
||||
---
|
||||
title: "Cloud Cost Optimization"
|
||||
type: concept
|
||||
tags: [Cloud, FinOps, Cost Management, Cloud Operations]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Cloud Cost Optimization (云成本优化)
|
||||
|
||||
## Definition
|
||||
**Cloud Cost Optimization** is the practice of reducing unnecessary cloud spending while maintaining performance, security, and reliability. It involves monitoring, analyzing, and adjusting cloud resource usage to achieve maximum value.
|
||||
|
||||
## Key Tactics
|
||||
|
||||
### 1. Reserved Instances & Spot Instances
|
||||
- **Reserved Instances**: 40-70% cost reduction compared to on-demand
|
||||
- **Spot Instances**: Up to 90% discount for interruptible workloads
|
||||
- Strategic commitment for predictable workloads
|
||||
|
||||
### 2. Auto-Scaling & Right-Sizing
|
||||
- Automatically adjust resources based on demand
|
||||
- Match instance types to actual workload needs
|
||||
- Terminate underutilized resources
|
||||
|
||||
### 3. Resource Tagging & Monitoring
|
||||
- Track spending by teams, projects, and workloads
|
||||
- Real-time cost visibility
|
||||
- Budget alerts and anomaly detection
|
||||
|
||||
### 4. Storage Optimization
|
||||
- Delete unused snapshots and volumes
|
||||
- Use lifecycle policies
|
||||
- Choose appropriate storage classes
|
||||
|
||||
### 5. Network Cost Optimization
|
||||
- Minimize data transfer costs
|
||||
- Use VPC endpoints
|
||||
- Optimize traffic routes
|
||||
|
||||
## Cloud Provider Cost Management Tools
|
||||
|
||||
| Provider | Tool | Key Features |
|
||||
|----------|------|-------------|
|
||||
| AWS | AWS Cost Explorer | Real-time cost monitoring, savings plans, budget alerts |
|
||||
| Azure | Azure Cost Management | Cost tracking, reserved instances, predictive analysis |
|
||||
| GCP | GCP Billing Reports | AI-driven cost insights, budget tracking |
|
||||
|
||||
## FinOps Integration
|
||||
- Cloud Cost Optimization is a core component of [[FinOps]]
|
||||
- Continuous optimization cycle: Inform → Optimize → Operate
|
||||
- Collaboration between finance, engineering, and operations
|
||||
|
||||
## Case Studies
|
||||
|
||||
### E-commerce Company
|
||||
- Leveraged Auto-Scaling and Reserved Instances across AWS and Azure
|
||||
- **Result**: $500,000 annual billing savings
|
||||
|
||||
### SaaS Company
|
||||
- Used Reserved Instances and Autoscaling Policies
|
||||
- **Result**: 35% reduction in cloud costs
|
||||
|
||||
## Related Concepts
|
||||
- [[FinOps]]
|
||||
- [[Cloud Operating Model]]
|
||||
- [[Cloud Governance]]
|
||||
- [[Rightsizing]]
|
||||
- [[Pay-as-you-go]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Azure]]
|
||||
- [[Google-Cloud]]
|
||||
|
||||
@@ -1,69 +1,69 @@
|
||||
---
|
||||
title: "Cloud Governance"
|
||||
type: concept
|
||||
tags: [Cloud, Governance, Compliance, Security, Cloud Operations]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Cloud Governance (云治理)
|
||||
|
||||
## Definition
|
||||
**Cloud Governance** is the set of policies, processes, and controls that ensure cloud resources are used securely, efficiently, and in compliance with regulatory requirements. It provides the framework for managing cloud chaos, security loopholes, and cost overruns.
|
||||
|
||||
## Key Components
|
||||
|
||||
### 1. Identity & Access Management (IAM)
|
||||
- Role-based access control (RBAC)
|
||||
- Principle of least privilege
|
||||
- Multi-factor authentication
|
||||
|
||||
### 2. Security & Compliance
|
||||
- Policy-as-Code for automated enforcement
|
||||
- Continuous compliance monitoring
|
||||
- Automated compliance checks
|
||||
|
||||
### 3. Cost Management & Governance
|
||||
- Real-time cost tracking
|
||||
- Budget alerts and allocation
|
||||
- Resource tagging strategies
|
||||
|
||||
### 4. Resource Governance
|
||||
- Guardrails for resource provisioning
|
||||
- Tagging standards
|
||||
- Resource lifecycle management
|
||||
|
||||
## Cloud Governance by Provider
|
||||
|
||||
| Aspect | AWS | Azure | GCP |
|
||||
|--------|-----|-------|-----|
|
||||
| IAM | AWS IAM | Azure AD | Google IAM |
|
||||
| Security Tools | AWS Security Hub | Microsoft Defender | Security Command Center |
|
||||
| Cost Control | AWS Cost Explorer | Azure Cost Management | GCP Billing Reports |
|
||||
| Policy Enforcement | AWS Organizations & SCPs | Azure Policy | GCP Organization Policies |
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Define IAM roles and policies upfront** — avoid giving excessive permissions
|
||||
2. **Use automated compliance checks** — detect misconfigurations
|
||||
3. **Implement guardrails** — prevent unauthorized resource provisioning
|
||||
4. **Establish tagging standards** — track resources by teams, projects, workloads
|
||||
5. **Enable real-time monitoring** — detect anomalies and compliance violations
|
||||
|
||||
## Relationship to Cloud Operating Model
|
||||
- Cloud Governance is a **core pillar** of the Cloud Operating Model
|
||||
- Provides the guardrails that enable secure and efficient cloud operations
|
||||
- Works alongside Automation, Security, and FinOps
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Operating Model]]
|
||||
- [[Policy-as-Code]]
|
||||
- [[Compliance-Automation]]
|
||||
- [[FinOps]]
|
||||
- [[Zero-Trust-Architecture]]
|
||||
- [[IAM]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Azure]]
|
||||
- [[Google-Cloud]]
|
||||
---
|
||||
title: "Cloud Governance"
|
||||
type: concept
|
||||
tags: [Cloud, Governance, Compliance, Security, Cloud Operations]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Cloud Governance (云治理)
|
||||
|
||||
## Definition
|
||||
**Cloud Governance** is the set of policies, processes, and controls that ensure cloud resources are used securely, efficiently, and in compliance with regulatory requirements. It provides the framework for managing cloud chaos, security loopholes, and cost overruns.
|
||||
|
||||
## Key Components
|
||||
|
||||
### 1. Identity & Access Management (IAM)
|
||||
- Role-based access control (RBAC)
|
||||
- Principle of least privilege
|
||||
- Multi-factor authentication
|
||||
|
||||
### 2. Security & Compliance
|
||||
- Policy-as-Code for automated enforcement
|
||||
- Continuous compliance monitoring
|
||||
- Automated compliance checks
|
||||
|
||||
### 3. Cost Management & Governance
|
||||
- Real-time cost tracking
|
||||
- Budget alerts and allocation
|
||||
- Resource tagging strategies
|
||||
|
||||
### 4. Resource Governance
|
||||
- Guardrails for resource provisioning
|
||||
- Tagging standards
|
||||
- Resource lifecycle management
|
||||
|
||||
## Cloud Governance by Provider
|
||||
|
||||
| Aspect | AWS | Azure | GCP |
|
||||
|--------|-----|-------|-----|
|
||||
| IAM | AWS IAM | Azure AD | Google IAM |
|
||||
| Security Tools | AWS Security Hub | Microsoft Defender | Security Command Center |
|
||||
| Cost Control | AWS Cost Explorer | Azure Cost Management | GCP Billing Reports |
|
||||
| Policy Enforcement | AWS Organizations & SCPs | Azure Policy | GCP Organization Policies |
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Define IAM roles and policies upfront** — avoid giving excessive permissions
|
||||
2. **Use automated compliance checks** — detect misconfigurations
|
||||
3. **Implement guardrails** — prevent unauthorized resource provisioning
|
||||
4. **Establish tagging standards** — track resources by teams, projects, workloads
|
||||
5. **Enable real-time monitoring** — detect anomalies and compliance violations
|
||||
|
||||
## Relationship to Cloud Operating Model
|
||||
- Cloud Governance is a **core pillar** of the Cloud Operating Model
|
||||
- Provides the guardrails that enable secure and efficient cloud operations
|
||||
- Works alongside Automation, Security, and FinOps
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Operating Model]]
|
||||
- [[Policy-as-Code]]
|
||||
- [[Compliance-Automation]]
|
||||
- [[FinOps]]
|
||||
- [[Zero-Trust-Architecture]]
|
||||
- [[IAM]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Azure]]
|
||||
- [[Google-Cloud]]
|
||||
|
||||
@@ -1,126 +1,126 @@
|
||||
---
|
||||
title: "Cloud Operating Model"
|
||||
type: concept
|
||||
tags: [Cloud, Cloud Strategy, Cloud Governance, Cloud Operations]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Cloud Operating Model (云运营模型)
|
||||
|
||||
## Definition
|
||||
A **Cloud Operating Model (COM)** is a framework that standardizes how organizations manage cloud resources, security, automation, and costs across cloud environments. It provides guardrails for constructing a secure framework for cloud operations and management from cost and risk standpoint.
|
||||
|
||||
## Core Pillars
|
||||
|
||||
### 1. Governance & Compliance (治理与合规)
|
||||
- Standardized policies ensuring compliance across cloud environments
|
||||
- Security, access control, and compliance policies
|
||||
- Teams follow best practices while maintaining agility
|
||||
|
||||
### 2. Automation & Orchestration (自动化与编排)
|
||||
- Infrastructure as Code (IaC) for deployment automation
|
||||
- CI/CD pipelines for continuous software delivery
|
||||
- Event-driven automation (e.g., AWS Lambda, Azure Functions)
|
||||
|
||||
### 3. Security & Risk Management (安全与风险管理)
|
||||
- Zero Trust Security Model (no implicit trust, continuous verification)
|
||||
- Real-time threat detection
|
||||
- Automated security patching
|
||||
|
||||
### 4. Cloud Financial Management - FinOps (云财务管理)
|
||||
- Real-time cost tracking and allocation
|
||||
- Reserved Instances & Spot Instances for cost optimization
|
||||
- Budget alerts and predictive analysis
|
||||
|
||||
## Six-Step Design Process
|
||||
|
||||
1. **Assess Cloud Maturity & Business Objectives**
|
||||
- Ad-hoc Cloud Adoption → Cloud-First Strategy → Cloud-Native Enterprise
|
||||
|
||||
2. **Create Governance & Compliance Framework**
|
||||
- Define IAM roles and policies
|
||||
- Automated compliance checks
|
||||
- Guardrails for resource provisioning
|
||||
|
||||
3. **Automate Cloud Operations (IaC, DevOps)**
|
||||
- Terraform, CloudFormation, Azure Bicep
|
||||
- CI/CD with GitHub Actions, CodePipeline
|
||||
- Serverless automation
|
||||
|
||||
4. **Implement Cost Management & Optimization (FinOps)**
|
||||
- Reserved/Spot Instances (40-70% compute cost reduction)
|
||||
- Auto-scaling & Right-sizing
|
||||
- Resource tagging and monitoring
|
||||
|
||||
5. **Strengthen Security & Risk Mitigation**
|
||||
- Zero Trust Security Model
|
||||
- Real-time threat detection (GuardDuty, Sentinel)
|
||||
- Automated security patching
|
||||
|
||||
6. **Continuous Monitoring & AI-Driven Optimization**
|
||||
- Observability & AIOps
|
||||
- Real-time cloud monitoring (CloudWatch, Azure Monitor)
|
||||
- Self-healing systems
|
||||
|
||||
## Key Benefits
|
||||
|
||||
| Benefit | Description |
|
||||
|---------|-------------|
|
||||
| Standardized Governance | Ensures compliance across cloud environments |
|
||||
| Cost Optimization | Implements FinOps strategies to prevent overspending |
|
||||
| Improved Security | Automates security policies and access controls |
|
||||
| Operational Agility | Enables DevOps, CI/CD, and auto-scaling |
|
||||
| Multi-Cloud Flexibility | Reduces vendor lock-in and enhances resilience |
|
||||
|
||||
## Industry Use Cases
|
||||
|
||||
### Financial Services
|
||||
- Regulatory compliance automation (GDPR, PCI-DSS, SOC 2)
|
||||
- FinOps for cost tracking and optimization
|
||||
- Zero Trust security model for data protection
|
||||
|
||||
### Healthcare
|
||||
- HIPAA, HITRUST, GDPR compliance enforcement
|
||||
- Data encryption and multi-layer access control
|
||||
- AI/ML for diagnostics
|
||||
|
||||
### Retail & E-Commerce
|
||||
- Auto-scaling for peak demand
|
||||
- Multi-cloud strategy to avoid vendor lock-in
|
||||
- Personalized customer experiences via AI
|
||||
|
||||
### SaaS & Tech Companies
|
||||
- CI/CD pipelines for continuous updates
|
||||
- Serverless and containerized architectures
|
||||
- DevSecOps for security-first development
|
||||
|
||||
## Challenges & Solutions
|
||||
|
||||
| Challenge | Solution |
|
||||
|-----------|----------|
|
||||
| Vendor Lock-In | Multi-cloud strategy + Docker/Kubernetes + Terraform |
|
||||
| Cost Overruns | FinOps + Reserved/Spot instances + automated shutdown |
|
||||
| Compliance Risks | Policy-as-Code + AWS Config/Azure Policy + RBAC |
|
||||
| Skills Gap | Automation tools + workforce upskilling |
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Governance]]
|
||||
- [[FinOps]]
|
||||
- [[Zero-Trust-Security]]
|
||||
- [[Multi-Cloud Strategy]]
|
||||
- [[Infrastructure as Code]]
|
||||
- [[AIOps]]
|
||||
- [[Cloud Cost Optimization]]
|
||||
- [[DevOps Maturity]]
|
||||
- [[Policy-as-Code]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Azure]]
|
||||
- [[Google-Cloud]]
|
||||
- [[Terraform]]
|
||||
- [[Kubernetes]]
|
||||
|
||||
## References
|
||||
- [Bacancy Technology: Cloud Operating Model](https://www.bacancytechnology.com/blog/cloud-operating-model)
|
||||
---
|
||||
title: "Cloud Operating Model"
|
||||
type: concept
|
||||
tags: [Cloud, Cloud Strategy, Cloud Governance, Cloud Operations]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Cloud Operating Model (云运营模型)
|
||||
|
||||
## Definition
|
||||
A **Cloud Operating Model (COM)** is a framework that standardizes how organizations manage cloud resources, security, automation, and costs across cloud environments. It provides guardrails for constructing a secure framework for cloud operations and management from cost and risk standpoint.
|
||||
|
||||
## Core Pillars
|
||||
|
||||
### 1. Governance & Compliance (治理与合规)
|
||||
- Standardized policies ensuring compliance across cloud environments
|
||||
- Security, access control, and compliance policies
|
||||
- Teams follow best practices while maintaining agility
|
||||
|
||||
### 2. Automation & Orchestration (自动化与编排)
|
||||
- Infrastructure as Code (IaC) for deployment automation
|
||||
- CI/CD pipelines for continuous software delivery
|
||||
- Event-driven automation (e.g., AWS Lambda, Azure Functions)
|
||||
|
||||
### 3. Security & Risk Management (安全与风险管理)
|
||||
- Zero Trust Security Model (no implicit trust, continuous verification)
|
||||
- Real-time threat detection
|
||||
- Automated security patching
|
||||
|
||||
### 4. Cloud Financial Management - FinOps (云财务管理)
|
||||
- Real-time cost tracking and allocation
|
||||
- Reserved Instances & Spot Instances for cost optimization
|
||||
- Budget alerts and predictive analysis
|
||||
|
||||
## Six-Step Design Process
|
||||
|
||||
1. **Assess Cloud Maturity & Business Objectives**
|
||||
- Ad-hoc Cloud Adoption → Cloud-First Strategy → Cloud-Native Enterprise
|
||||
|
||||
2. **Create Governance & Compliance Framework**
|
||||
- Define IAM roles and policies
|
||||
- Automated compliance checks
|
||||
- Guardrails for resource provisioning
|
||||
|
||||
3. **Automate Cloud Operations (IaC, DevOps)**
|
||||
- Terraform, CloudFormation, Azure Bicep
|
||||
- CI/CD with GitHub Actions, CodePipeline
|
||||
- Serverless automation
|
||||
|
||||
4. **Implement Cost Management & Optimization (FinOps)**
|
||||
- Reserved/Spot Instances (40-70% compute cost reduction)
|
||||
- Auto-scaling & Right-sizing
|
||||
- Resource tagging and monitoring
|
||||
|
||||
5. **Strengthen Security & Risk Mitigation**
|
||||
- Zero Trust Security Model
|
||||
- Real-time threat detection (GuardDuty, Sentinel)
|
||||
- Automated security patching
|
||||
|
||||
6. **Continuous Monitoring & AI-Driven Optimization**
|
||||
- Observability & AIOps
|
||||
- Real-time cloud monitoring (CloudWatch, Azure Monitor)
|
||||
- Self-healing systems
|
||||
|
||||
## Key Benefits
|
||||
|
||||
| Benefit | Description |
|
||||
|---------|-------------|
|
||||
| Standardized Governance | Ensures compliance across cloud environments |
|
||||
| Cost Optimization | Implements FinOps strategies to prevent overspending |
|
||||
| Improved Security | Automates security policies and access controls |
|
||||
| Operational Agility | Enables DevOps, CI/CD, and auto-scaling |
|
||||
| Multi-Cloud Flexibility | Reduces vendor lock-in and enhances resilience |
|
||||
|
||||
## Industry Use Cases
|
||||
|
||||
### Financial Services
|
||||
- Regulatory compliance automation (GDPR, PCI-DSS, SOC 2)
|
||||
- FinOps for cost tracking and optimization
|
||||
- Zero Trust security model for data protection
|
||||
|
||||
### Healthcare
|
||||
- HIPAA, HITRUST, GDPR compliance enforcement
|
||||
- Data encryption and multi-layer access control
|
||||
- AI/ML for diagnostics
|
||||
|
||||
### Retail & E-Commerce
|
||||
- Auto-scaling for peak demand
|
||||
- Multi-cloud strategy to avoid vendor lock-in
|
||||
- Personalized customer experiences via AI
|
||||
|
||||
### SaaS & Tech Companies
|
||||
- CI/CD pipelines for continuous updates
|
||||
- Serverless and containerized architectures
|
||||
- DevSecOps for security-first development
|
||||
|
||||
## Challenges & Solutions
|
||||
|
||||
| Challenge | Solution |
|
||||
|-----------|----------|
|
||||
| Vendor Lock-In | Multi-cloud strategy + Docker/Kubernetes + Terraform |
|
||||
| Cost Overruns | FinOps + Reserved/Spot instances + automated shutdown |
|
||||
| Compliance Risks | Policy-as-Code + AWS Config/Azure Policy + RBAC |
|
||||
| Skills Gap | Automation tools + workforce upskilling |
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Governance]]
|
||||
- [[FinOps]]
|
||||
- [[Zero-Trust-Security]]
|
||||
- [[Multi-Cloud Strategy]]
|
||||
- [[Infrastructure as Code]]
|
||||
- [[AIOps]]
|
||||
- [[Cloud Cost Optimization]]
|
||||
- [[DevOps Maturity]]
|
||||
- [[Policy-as-Code]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Azure]]
|
||||
- [[Google-Cloud]]
|
||||
- [[Terraform]]
|
||||
- [[Kubernetes]]
|
||||
|
||||
## References
|
||||
- [Bacancy Technology: Cloud Operating Model](https://www.bacancytechnology.com/blog/cloud-operating-model)
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: "DAST"
|
||||
type: concept
|
||||
tags: [security, dynamic-analysis, penetration-testing, devsecops]
|
||||
sources: ["what-is-devsecops-best-practices-benefits-and-tools"]
|
||||
last_updated: 2025-12-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
DAST（Dynamic Application Security Testing，动态应用安全测试）是一种在应用程序运行时模拟外部攻击，从攻击者视角发现安全漏洞的黑盒测试方法。DAST 工具无需访问源代码，通过发送恶意请求并分析响应来识别漏洞。
|
||||
|
||||
## Characteristics
|
||||
|
||||
- **黑盒测试**：无需源代码，独立于应用实现
|
||||
- **测试和部署阶段使用**：在应用运行状态下进行扫描
|
||||
- **真实攻击模拟**：模拟真实黑客的攻击手法
|
||||
- **低误报率**：发现的漏洞通常是真实可利用的
|
||||
|
||||
## Capabilities
|
||||
|
||||
DAST 工具擅长发现以下类型的漏洞：
|
||||
- SQL 注入（SQL Injection）
|
||||
- 跨站脚本（XSS）
|
||||
- 认证和会话管理缺陷
|
||||
- 信息泄露
|
||||
- 服务器配置错误
|
||||
- API 安全问题
|
||||
|
||||
## Limitations
|
||||
|
||||
- 覆盖率受限（无法扫描未访问的代码路径）
|
||||
- 无法定位具体漏洞代码位置
|
||||
- 可能对生产环境造成影响（需在测试环境运行）
|
||||
|
||||
## Typical Tools
|
||||
|
||||
- OWASP ZAP (Zed Attack Proxy)
|
||||
- Burp Suite
|
||||
- Acunetix
|
||||
- Netsparker
|
||||
|
||||
## Relationship with DevSecOps
|
||||
|
||||
DAST 是 [[DevSecOps]] CI/CD 流水线的重要环节，通常在集成测试或预生产环境阶段执行。与 [[SAST]] 互补——SAST 发现代码层漏洞，DAST 发现运行时和架构层漏洞。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[SAST]] — 静态应用安全测试，白盒分析，与 DAST 互补
|
||||
- [[IAST]] — 交互式应用安全测试，结合两者优势
|
||||
- [[OWASP Top Ten]] — DAST 扫描的核心参考标准
|
||||
- [[Shift Right]] — 右移策略，上线后持续 DAST 扫描
|
||||
---
|
||||
title: "DAST"
|
||||
type: concept
|
||||
tags: [security, dynamic-analysis, penetration-testing, devsecops]
|
||||
sources: ["what-is-devsecops-best-practices-benefits-and-tools"]
|
||||
last_updated: 2025-12-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
DAST（Dynamic Application Security Testing，动态应用安全测试）是一种在应用程序运行时模拟外部攻击，从攻击者视角发现安全漏洞的黑盒测试方法。DAST 工具无需访问源代码，通过发送恶意请求并分析响应来识别漏洞。
|
||||
|
||||
## Characteristics
|
||||
|
||||
- **黑盒测试**：无需源代码，独立于应用实现
|
||||
- **测试和部署阶段使用**：在应用运行状态下进行扫描
|
||||
- **真实攻击模拟**：模拟真实黑客的攻击手法
|
||||
- **低误报率**：发现的漏洞通常是真实可利用的
|
||||
|
||||
## Capabilities
|
||||
|
||||
DAST 工具擅长发现以下类型的漏洞：
|
||||
- SQL 注入（SQL Injection）
|
||||
- 跨站脚本（XSS）
|
||||
- 认证和会话管理缺陷
|
||||
- 信息泄露
|
||||
- 服务器配置错误
|
||||
- API 安全问题
|
||||
|
||||
## Limitations
|
||||
|
||||
- 覆盖率受限（无法扫描未访问的代码路径）
|
||||
- 无法定位具体漏洞代码位置
|
||||
- 可能对生产环境造成影响（需在测试环境运行）
|
||||
|
||||
## Typical Tools
|
||||
|
||||
- OWASP ZAP (Zed Attack Proxy)
|
||||
- Burp Suite
|
||||
- Acunetix
|
||||
- Netsparker
|
||||
|
||||
## Relationship with DevSecOps
|
||||
|
||||
DAST 是 [[DevSecOps]] CI/CD 流水线的重要环节，通常在集成测试或预生产环境阶段执行。与 [[SAST]] 互补——SAST 发现代码层漏洞，DAST 发现运行时和架构层漏洞。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[SAST]] — 静态应用安全测试，白盒分析，与 DAST 互补
|
||||
- [[IAST]] — 交互式应用安全测试，结合两者优势
|
||||
- [[OWASP Top Ten]] — DAST 扫描的核心参考标准
|
||||
- [[Shift Right]] — 右移策略，上线后持续 DAST 扫描
|
||||
|
||||
@@ -1,31 +1,31 @@
|
||||
---
|
||||
title: "DarkLaunching"
|
||||
type: concept
|
||||
tags: ["deployment", "release-management", "feature-rollout"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Dark Launch
|
||||
- 暗启动
|
||||
- 灰度发布
|
||||
- Feature Flag Deployment
|
||||
|
||||
## Definition
|
||||
暗启动是 [[AutonomousOptimizationArchitect]] 的模型引入策略——在不完全暴露给用户的前提下，将新模型部署到生产环境，通过 [[ShadowTraffic]] 验证其性能。分为三个阶段：影子测试（不返回用户）→ 灰度流量（5% 用户）→ 全量切换。
|
||||
|
||||
## Mechanism
|
||||
1. **Phase 1 - Shadow Deployment**：新模型接收影子流量，完全不影响用户
|
||||
2. **Phase 2 - Canary**：5% 真实流量切换到新模型，监控错误率和用户满意度
|
||||
3. **Phase 3 - Full Rollout**：新模型通过所有检查后，全量替换旧模型
|
||||
|
||||
## Key Properties
|
||||
- **风险可控**：任何阶段发现问题均可立即回滚
|
||||
- **数据驱动**：每个阶段都有明确的量化指标门槛
|
||||
- **与 CI/CD 集成**：暗启动可作为自动化发布流水线的组成部分
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — 使用暗启动作为新模型引入框架
|
||||
- [[ShadowTraffic]] — 暗启动 Phase 1 的核心实现方式
|
||||
- [[CircuitBreaker]] — 提供暗启动失败时的自动保护机制
|
||||
---
|
||||
title: "DarkLaunching"
|
||||
type: concept
|
||||
tags: ["deployment", "release-management", "feature-rollout"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Dark Launch
|
||||
- 暗启动
|
||||
- 灰度发布
|
||||
- Feature Flag Deployment
|
||||
|
||||
## Definition
|
||||
暗启动是 [[AutonomousOptimizationArchitect]] 的模型引入策略——在不完全暴露给用户的前提下，将新模型部署到生产环境，通过 [[ShadowTraffic]] 验证其性能。分为三个阶段：影子测试（不返回用户）→ 灰度流量（5% 用户）→ 全量切换。
|
||||
|
||||
## Mechanism
|
||||
1. **Phase 1 - Shadow Deployment**：新模型接收影子流量，完全不影响用户
|
||||
2. **Phase 2 - Canary**：5% 真实流量切换到新模型，监控错误率和用户满意度
|
||||
3. **Phase 3 - Full Rollout**：新模型通过所有检查后，全量替换旧模型
|
||||
|
||||
## Key Properties
|
||||
- **风险可控**：任何阶段发现问题均可立即回滚
|
||||
- **数据驱动**：每个阶段都有明确的量化指标门槛
|
||||
- **与 CI/CD 集成**：暗启动可作为自动化发布流水线的组成部分
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — 使用暗启动作为新模型引入框架
|
||||
- [[ShadowTraffic]] — 暗启动 Phase 1 的核心实现方式
|
||||
- [[CircuitBreaker]] — 提供暗启动失败时的自动保护机制
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "DevOps Maturity Model"
|
||||
type: concept
|
||||
tags: [DevOps, Maturity Assessment, CI/CD]
|
||||
sources: [devops-maturity-model-from-traditional-it-to-advanced-devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
DevOps 成熟度模型（DevOps Maturity Model）是一种结构化框架，用于评估组织当前 DevOps 实践水平，识别改进领域，并规划向更高成熟度等级的演进路径。
|
||||
|
||||
该模型涵盖四个核心评估维度：**文化与战略**、**自动化**、**结构与流程**、**协作与共享**、**技术**，并通过五个递进阶段量化组织 DevOps 能力。
|
||||
|
||||
## 成熟度五阶段
|
||||
|
||||
| 阶段 | 名称 | 关键特征 |
|
||||
|------|------|----------|
|
||||
| Phase 1 | 初始/临时阶段 | 瀑布式开发，团队孤立，手动流程，反应式监控 |
|
||||
| Phase 2 | 局部试点 | 小范围 DevOps 实践，版本控制引入，单元/集成测试 |
|
||||
| Phase 3 | 自动化与定义 | 基础设施自动化，敏捷跨团队协作，安全扫描集成 |
|
||||
| Phase 4 | 高度优化 | CI/CD 流水线，不可变基础设施，第三方依赖管理 |
|
||||
| Phase 5 | 完全成熟 | 连续部署，零人工干预，数据驱动决策 |
|
||||
|
||||
## 关键衡量指标
|
||||
|
||||
- **部署频率（Deployment Frequency）**：在设定周期内代码部署的频率
|
||||
- **变更前置时间（Lead Time）**：从代码提交到部署的时间
|
||||
- **变更失败率（Change Failure Rate）**：部署后引发故障或回滚的比例
|
||||
- **平均恢复时间（MTTR）**：从故障恢复到正常运行的时间
|
||||
- **错误预算（Error Budget）**：允许的生产环境错误和失败率
|
||||
|
||||
## 核心评估维度
|
||||
|
||||
1. **文化与战略**：团队协作、透明度、以客户为中心的产品思维
|
||||
2. **自动化**：CI/CD 流水线、基础设施即代码、测试自动化
|
||||
3. **结构与流程**：标准化流程、小批量工作、消除浪费
|
||||
4. **协作与共享**：开发与运维协同、知识共享、统一目标
|
||||
5. **技术选型**：工具链集成、监控告警、容器化解决方案
|
||||
|
||||
## 常见演进障碍
|
||||
|
||||
- 团队间沟通不畅
|
||||
- 缺乏清晰目标和策略
|
||||
- 抗拒变革
|
||||
- 投入不足
|
||||
- 治理薄弱
|
||||
- 流程僵化
|
||||
|
||||
## 来源
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]]
|
||||
---
|
||||
title: "DevOps Maturity Model"
|
||||
type: concept
|
||||
tags: [DevOps, Maturity Assessment, CI/CD]
|
||||
sources: [devops-maturity-model-from-traditional-it-to-advanced-devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
DevOps 成熟度模型（DevOps Maturity Model）是一种结构化框架，用于评估组织当前 DevOps 实践水平，识别改进领域，并规划向更高成熟度等级的演进路径。
|
||||
|
||||
该模型涵盖四个核心评估维度：**文化与战略**、**自动化**、**结构与流程**、**协作与共享**、**技术**，并通过五个递进阶段量化组织 DevOps 能力。
|
||||
|
||||
## 成熟度五阶段
|
||||
|
||||
| 阶段 | 名称 | 关键特征 |
|
||||
|------|------|----------|
|
||||
| Phase 1 | 初始/临时阶段 | 瀑布式开发，团队孤立，手动流程，反应式监控 |
|
||||
| Phase 2 | 局部试点 | 小范围 DevOps 实践，版本控制引入，单元/集成测试 |
|
||||
| Phase 3 | 自动化与定义 | 基础设施自动化，敏捷跨团队协作，安全扫描集成 |
|
||||
| Phase 4 | 高度优化 | CI/CD 流水线，不可变基础设施，第三方依赖管理 |
|
||||
| Phase 5 | 完全成熟 | 连续部署，零人工干预，数据驱动决策 |
|
||||
|
||||
## 关键衡量指标
|
||||
|
||||
- **部署频率（Deployment Frequency）**：在设定周期内代码部署的频率
|
||||
- **变更前置时间（Lead Time）**：从代码提交到部署的时间
|
||||
- **变更失败率（Change Failure Rate）**：部署后引发故障或回滚的比例
|
||||
- **平均恢复时间（MTTR）**：从故障恢复到正常运行的时间
|
||||
- **错误预算（Error Budget）**：允许的生产环境错误和失败率
|
||||
|
||||
## 核心评估维度
|
||||
|
||||
1. **文化与战略**：团队协作、透明度、以客户为中心的产品思维
|
||||
2. **自动化**：CI/CD 流水线、基础设施即代码、测试自动化
|
||||
3. **结构与流程**：标准化流程、小批量工作、消除浪费
|
||||
4. **协作与共享**：开发与运维协同、知识共享、统一目标
|
||||
5. **技术选型**：工具链集成、监控告警、容器化解决方案
|
||||
|
||||
## 常见演进障碍
|
||||
|
||||
- 团队间沟通不畅
|
||||
- 缺乏清晰目标和策略
|
||||
- 抗拒变革
|
||||
- 投入不足
|
||||
- 治理薄弱
|
||||
- 流程僵化
|
||||
|
||||
## 来源
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]]
|
||||
|
||||
@@ -1,55 +1,55 @@
|
||||
---
|
||||
title: "DevSecOps"
|
||||
type: concept
|
||||
tags: [devops, security, sdlc, automation, ci-cd]
|
||||
sources: ["what-is-devsecops-best-practices-benefits-and-tools"]
|
||||
last_updated: 2025-12-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
DevSecOps（Development + Security + Operations）是一种将安全实践深度嵌入软件开发生命周期（SDLC）全程的工作方法论，使安全成为开发、安全、运营三团队的共同责任，而非独立的末端检查环节。
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **Security as Code**：以代码形式定义安全策略，实现自动化执行和版本控制
|
||||
- **Shift Left**：在开发周期早期发现并修复安全漏洞，降低修复成本
|
||||
- **Shift Right**：在应用上线后持续进行安全监控，快速响应新发现漏洞
|
||||
- **Shared Responsibility**：全员对安全负责，而非仅依赖安全团队
|
||||
- **Automation First**：将安全测试集成到 CI/CD 流水线，减少人工干预
|
||||
|
||||
## Key Tools
|
||||
|
||||
| 工具类型 | 说明 | 典型工具 |
|
||||
|---------|------|---------|
|
||||
| [[SAST]] | 静态代码分析，编码阶段使用 | SonarQube, Checkmarx |
|
||||
| [[DAST]] | 动态渗透测试，模拟外部攻击 | OWASP ZAP, Burp Suite |
|
||||
| [[SCA]] | 软件成分分析，扫描第三方依赖漏洞 | Snyk, Dependabot |
|
||||
| [[IAST]] | 运行时交互式测试，测试阶段使用 | Contrast Security |
|
||||
|
||||
## Relationship with DevOps
|
||||
|
||||
DevSecOps 是 [[DevOps]] 的安全扩展：
|
||||
- DevOps 强调开发与运营协作，追求速度与效率
|
||||
- DevSecOps 在 DevOps 基础上全程嵌入安全实践
|
||||
- 两者共享 CI/CD 流水线文化，但 DevSecOps 在每个阶段加入安全门控
|
||||
|
||||
## Key Metrics
|
||||
|
||||
- 据报告，**70% 的上线后发现的安全漏洞**可通过 DevSecOps 实践预防
|
||||
- "break the build" 机制：在安全风险超阈值时自动停止构建流程
|
||||
- 安全漏洞修复成本：开发早期修复成本仅为上线后的 1/100 ~ 1/10
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Shift Left]] — 在开发早期识别安全缺陷
|
||||
- [[Shift Right]] — 上线后持续安全监控
|
||||
- [[Policy as Code]] — 安全策略即代码
|
||||
- [[CI/CD 安全]] — CI/CD 流水线中的安全自动化
|
||||
- [[OWASP Top Ten]] — Web 应用安全标准
|
||||
|
||||
## Aliases
|
||||
|
||||
- SecOps (Security Operations)
|
||||
- DevOpsSec
|
||||
- Secure DevOps
|
||||
---
|
||||
title: "DevSecOps"
|
||||
type: concept
|
||||
tags: [devops, security, sdlc, automation, ci-cd]
|
||||
sources: ["what-is-devsecops-best-practices-benefits-and-tools"]
|
||||
last_updated: 2025-12-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
DevSecOps（Development + Security + Operations）是一种将安全实践深度嵌入软件开发生命周期（SDLC）全程的工作方法论，使安全成为开发、安全、运营三团队的共同责任，而非独立的末端检查环节。
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **Security as Code**：以代码形式定义安全策略，实现自动化执行和版本控制
|
||||
- **Shift Left**：在开发周期早期发现并修复安全漏洞，降低修复成本
|
||||
- **Shift Right**：在应用上线后持续进行安全监控，快速响应新发现漏洞
|
||||
- **Shared Responsibility**：全员对安全负责，而非仅依赖安全团队
|
||||
- **Automation First**：将安全测试集成到 CI/CD 流水线，减少人工干预
|
||||
|
||||
## Key Tools
|
||||
|
||||
| 工具类型 | 说明 | 典型工具 |
|
||||
|---------|------|---------|
|
||||
| [[SAST]] | 静态代码分析，编码阶段使用 | SonarQube, Checkmarx |
|
||||
| [[DAST]] | 动态渗透测试，模拟外部攻击 | OWASP ZAP, Burp Suite |
|
||||
| [[SCA]] | 软件成分分析，扫描第三方依赖漏洞 | Snyk, Dependabot |
|
||||
| [[IAST]] | 运行时交互式测试，测试阶段使用 | Contrast Security |
|
||||
|
||||
## Relationship with DevOps
|
||||
|
||||
DevSecOps 是 [[DevOps]] 的安全扩展：
|
||||
- DevOps 强调开发与运营协作，追求速度与效率
|
||||
- DevSecOps 在 DevOps 基础上全程嵌入安全实践
|
||||
- 两者共享 CI/CD 流水线文化，但 DevSecOps 在每个阶段加入安全门控
|
||||
|
||||
## Key Metrics
|
||||
|
||||
- 据报告，**70% 的上线后发现的安全漏洞**可通过 DevSecOps 实践预防
|
||||
- "break the build" 机制：在安全风险超阈值时自动停止构建流程
|
||||
- 安全漏洞修复成本：开发早期修复成本仅为上线后的 1/100 ~ 1/10
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Shift Left]] — 在开发早期识别安全缺陷
|
||||
- [[Shift Right]] — 上线后持续安全监控
|
||||
- [[Policy as Code]] — 安全策略即代码
|
||||
- [[CI/CD 安全]] — CI/CD 流水线中的安全自动化
|
||||
- [[OWASP Top Ten]] — Web 应用安全标准
|
||||
|
||||
## Aliases
|
||||
|
||||
- SecOps (Security Operations)
|
||||
- DevOpsSec
|
||||
- Secure DevOps
|
||||
|
||||
@@ -1,69 +1,69 @@
|
||||
---
|
||||
title: "Docker Daemon Proxy"
|
||||
type: concept
|
||||
tags: [docker, proxy, systemd, container]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
# Docker Daemon Proxy
|
||||
|
||||
## Aliases
|
||||
- Docker Daemon Proxy
|
||||
- Docker 守护进程代理
|
||||
- Dockerd Proxy
|
||||
- HTTP_PROXY for Docker Daemon
|
||||
- Docker Daemon HTTP 代理
|
||||
|
||||
## Definition
|
||||
Docker Daemon Proxy 是指通过 systemd 环境变量（`HTTP_PROXY`/`HTTPS_PROXY`）为 Docker 守护进程（`dockerd`）配置显式代理，使所有 `docker pull`、`docker build` 和容器出站流量走指定代理服务器。这是透明代理失效时（尤其在群晖 DSM/Ubuntu Server 环境中）的推荐替代方案。
|
||||
|
||||
## When to Use
|
||||
- 透明代理（V2RayA/Clash）对 Docker Daemon 网络栈无效
|
||||
- 需要可靠、可预测的 `docker pull` 代理行为
|
||||
- 生产环境/多容器部署中需要与系统路由表解耦
|
||||
- 群晖 DSM 7.x（服务名 `pkg-ContainerManager-dockerd`）
|
||||
|
||||
## Implementation Pattern
|
||||
|
||||
### Step 1: Create systemd override directory
|
||||
```bash
|
||||
sudo mkdir -p /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/
|
||||
```
|
||||
|
||||
### Step 2: Create proxy config file
|
||||
```bash
|
||||
sudo vi /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/http-proxy.conf
|
||||
```
|
||||
|
||||
### Step 3: Write environment variables
|
||||
```ini
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=http://127.0.0.1:20171"
|
||||
Environment="HTTPS_PROXY=http://127.0.0.1:20171"
|
||||
Environment="NO_PROXY=localhost,127.0.0.1,192.168.*,*.synology.me"
|
||||
```
|
||||
|
||||
### Step 4: Reload and restart
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart pkg-ContainerManager-dockerd
|
||||
```
|
||||
|
||||
## Key Distinction from Transparent Proxy
|
||||
| 维度 | 透明代理（Transparent Proxy） | Docker Daemon Proxy |
|
||||
|------|------------------------------|-------------------|
|
||||
| 作用层级 | iptables（内核网络层） | systemd 环境变量 |
|
||||
| 生效范围 | 所有出站流量（NAS 本机） | 仅 Docker Daemon 进程 |
|
||||
| DSM 兼容性 | 可能失效（网络栈差异） | 稳定可靠 |
|
||||
| 对其他服务的影响 | 可能影响 NAS 其他网络服务 | 仅影响 Docker |
|
||||
| 维护难度 | 高（修改系统路由表） | 低（配置分离） |
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]] — DSM 7.x 环境下的 Docker Daemon Proxy 完整配置
|
||||
- [[Ubuntu-Server科学上网]] — Ubuntu Server 环境下的 Docker Daemon Proxy 配置
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 的默认透明代理机制（在 DSM 中对 Docker Daemon 失效）
|
||||
- [[V2RayA]] — Docker Daemon Proxy 的上游代理服务提供者
|
||||
- [[分流模式]] — V2RayA 的流量路由策略
|
||||
- [[iptables]] — 透明代理依赖的内核规则
|
||||
---
|
||||
title: "Docker Daemon Proxy"
|
||||
type: concept
|
||||
tags: [docker, proxy, systemd, container]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
# Docker Daemon Proxy
|
||||
|
||||
## Aliases
|
||||
- Docker Daemon Proxy
|
||||
- Docker 守护进程代理
|
||||
- Dockerd Proxy
|
||||
- HTTP_PROXY for Docker Daemon
|
||||
- Docker Daemon HTTP 代理
|
||||
|
||||
## Definition
|
||||
Docker Daemon Proxy 是指通过 systemd 环境变量（`HTTP_PROXY`/`HTTPS_PROXY`）为 Docker 守护进程（`dockerd`）配置显式代理，使所有 `docker pull`、`docker build` 和容器出站流量走指定代理服务器。这是透明代理失效时（尤其在群晖 DSM/Ubuntu Server 环境中）的推荐替代方案。
|
||||
|
||||
## When to Use
|
||||
- 透明代理（V2RayA/Clash）对 Docker Daemon 网络栈无效
|
||||
- 需要可靠、可预测的 `docker pull` 代理行为
|
||||
- 生产环境/多容器部署中需要与系统路由表解耦
|
||||
- 群晖 DSM 7.x（服务名 `pkg-ContainerManager-dockerd`）
|
||||
|
||||
## Implementation Pattern
|
||||
|
||||
### Step 1: Create systemd override directory
|
||||
```bash
|
||||
sudo mkdir -p /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/
|
||||
```
|
||||
|
||||
### Step 2: Create proxy config file
|
||||
```bash
|
||||
sudo vi /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/http-proxy.conf
|
||||
```
|
||||
|
||||
### Step 3: Write environment variables
|
||||
```ini
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=http://127.0.0.1:20171"
|
||||
Environment="HTTPS_PROXY=http://127.0.0.1:20171"
|
||||
Environment="NO_PROXY=localhost,127.0.0.1,192.168.*,*.synology.me"
|
||||
```
|
||||
|
||||
### Step 4: Reload and restart
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart pkg-ContainerManager-dockerd
|
||||
```
|
||||
|
||||
## Key Distinction from Transparent Proxy
|
||||
| 维度 | 透明代理（Transparent Proxy） | Docker Daemon Proxy |
|
||||
|------|------------------------------|-------------------|
|
||||
| 作用层级 | iptables（内核网络层） | systemd 环境变量 |
|
||||
| 生效范围 | 所有出站流量（NAS 本机） | 仅 Docker Daemon 进程 |
|
||||
| DSM 兼容性 | 可能失效（网络栈差异） | 稳定可靠 |
|
||||
| 对其他服务的影响 | 可能影响 NAS 其他网络服务 | 仅影响 Docker |
|
||||
| 维护难度 | 高（修改系统路由表） | 低（配置分离） |
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]] — DSM 7.x 环境下的 Docker Daemon Proxy 完整配置
|
||||
- [[Ubuntu-Server科学上网]] — Ubuntu Server 环境下的 Docker Daemon Proxy 配置
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 的默认透明代理机制（在 DSM 中对 Docker Daemon 失效）
|
||||
- [[V2RayA]] — Docker Daemon Proxy 的上游代理服务提供者
|
||||
- [[分流模式]] — V2RayA 的流量路由策略
|
||||
- [[iptables]] — 透明代理依赖的内核规则
|
||||
|
||||
@@ -1,63 +1,63 @@
|
||||
---
|
||||
title: "Error Budget"
|
||||
type: concept
|
||||
tags: [SRE, Reliability, DevOps Metrics]
|
||||
sources: [devops-maturity-model-from-traditional-it-to-advanced-devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
错误预算（Error Budget）是允许的、一定时间段内系统可以承受的错误和失败的数量或比例。它是一个平衡可靠性目标与创新速度的风险管理工具。
|
||||
|
||||
## 核心概念
|
||||
|
||||
错误预算源于 SRE（Site Reliability Engineering）理念，核心思想是：
|
||||
|
||||
> 如果你的服务可靠性目标是 99.9%，那么你有 0.1% 的"错误预算"可以用于实验和发布。
|
||||
|
||||
## 计算方式
|
||||
|
||||
```
|
||||
Error Budget = (1 - Reliability SLO) × Time Period
|
||||
|
||||
例如：
|
||||
- 月 SLO = 99.9%
|
||||
- 月错误预算 = 0.1% × 30天 × 24小时 = 0.72 小时（约 43 分钟）
|
||||
```
|
||||
|
||||
## 在 DevOps 成熟度模型中的位置
|
||||
|
||||
在 DevOps 成熟度衡量指标体系中，错误预算是一个重要指标：
|
||||
|
||||
> "Error Budget — The permissible rate of errors and failures in production."
|
||||
|
||||
错误预算的使用策略因 DevOps 成熟度阶段不同而异：
|
||||
|
||||
| 成熟度阶段 | 错误预算使用方式 |
|
||||
|-----------|----------------|
|
||||
| Phase 1-2 | 无正式错误预算概念 |
|
||||
| Phase 3 | 开始建立 SLO，但未充分利用错误预算 |
|
||||
| Phase 4 | 明确的错误预算政策，用于平衡创新与可靠性 |
|
||||
| Phase 5 | 数据驱动决策，团队自主利用错误预算进行实验 |
|
||||
|
||||
## 与相关概念的关系
|
||||
|
||||
- [[MTTR]]：错误预算与 MTTR 共同定义系统可靠性曲线
|
||||
- [[Change Failure Rate]]：高变更失败率会快速消耗错误预算
|
||||
- [[Deployment Frequency]]：高部署频率需要配合错误预算管理以维持可靠性目标
|
||||
- [[DevOps Maturity Model]]：错误预算是衡量组织成熟度的重要指标之一
|
||||
|
||||
## 错误预算政策示例
|
||||
|
||||
```yaml
|
||||
SLO: 99.9%（每月 43 分钟错误预算）
|
||||
策略:
|
||||
- 错误预算充足（>50%）：可自由发布和实验
|
||||
- 错误预算中等（25-50%）：谨慎发布
|
||||
- 错误预算不足（<25%）：冻结发布，专注可靠性
|
||||
- 错误预算耗尽：停止所有非关键变更
|
||||
```
|
||||
|
||||
## 来源
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]]
|
||||
---
|
||||
title: "Error Budget"
|
||||
type: concept
|
||||
tags: [SRE, Reliability, DevOps Metrics]
|
||||
sources: [devops-maturity-model-from-traditional-it-to-advanced-devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
错误预算（Error Budget）是允许的、一定时间段内系统可以承受的错误和失败的数量或比例。它是一个平衡可靠性目标与创新速度的风险管理工具。
|
||||
|
||||
## 核心概念
|
||||
|
||||
错误预算源于 SRE（Site Reliability Engineering）理念，核心思想是：
|
||||
|
||||
> 如果你的服务可靠性目标是 99.9%，那么你有 0.1% 的"错误预算"可以用于实验和发布。
|
||||
|
||||
## 计算方式
|
||||
|
||||
```
|
||||
Error Budget = (1 - Reliability SLO) × Time Period
|
||||
|
||||
例如：
|
||||
- 月 SLO = 99.9%
|
||||
- 月错误预算 = 0.1% × 30天 × 24小时 = 0.72 小时（约 43 分钟）
|
||||
```
|
||||
|
||||
## 在 DevOps 成熟度模型中的位置
|
||||
|
||||
在 DevOps 成熟度衡量指标体系中，错误预算是一个重要指标：
|
||||
|
||||
> "Error Budget — The permissible rate of errors and failures in production."
|
||||
|
||||
错误预算的使用策略因 DevOps 成熟度阶段不同而异：
|
||||
|
||||
| 成熟度阶段 | 错误预算使用方式 |
|
||||
|-----------|----------------|
|
||||
| Phase 1-2 | 无正式错误预算概念 |
|
||||
| Phase 3 | 开始建立 SLO，但未充分利用错误预算 |
|
||||
| Phase 4 | 明确的错误预算政策，用于平衡创新与可靠性 |
|
||||
| Phase 5 | 数据驱动决策，团队自主利用错误预算进行实验 |
|
||||
|
||||
## 与相关概念的关系
|
||||
|
||||
- [[MTTR]]：错误预算与 MTTR 共同定义系统可靠性曲线
|
||||
- [[Change Failure Rate]]：高变更失败率会快速消耗错误预算
|
||||
- [[Deployment Frequency]]：高部署频率需要配合错误预算管理以维持可靠性目标
|
||||
- [[DevOps Maturity Model]]：错误预算是衡量组织成熟度的重要指标之一
|
||||
|
||||
## 错误预算政策示例
|
||||
|
||||
```yaml
|
||||
SLO: 99.9%（每月 43 分钟错误预算）
|
||||
策略:
|
||||
- 错误预算充足（>50%）：可自由发布和实验
|
||||
- 错误预算中等（25-50%）：谨慎发布
|
||||
- 错误预算不足（<25%）：冻结发布，专注可靠性
|
||||
- 错误预算耗尽：停止所有非关键变更
|
||||
```
|
||||
|
||||
## 来源
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]]
|
||||
|
||||
@@ -1,111 +1,111 @@
|
||||
---
|
||||
title: "FinOps"
|
||||
type: concept
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
---
|
||||
|
||||
# FinOps
|
||||
|
||||
> **FinOps** — Cloud Financial Management，云财务管理，是一种将财务责任、跨团队协作和业务价值最大化相结合的云成本管理实践。
|
||||
|
||||
## Definition
|
||||
|
||||
FinOps（Financial Operations）是云时代的一种运营框架：
|
||||
|
||||
- **可见性** — 了解云支出去向
|
||||
- **优化** — 持续减少浪费
|
||||
- **业务价值** — 最大化云投资回报
|
||||
|
||||
## FinOps Core Principles
|
||||
|
||||
| 原则 | 描述 |
|
||||
|------|------|
|
||||
| **云是一个 marketplaces** | 实时价格，竞争驱动 |
|
||||
| **财务责任人人有责** | 集中团队无法独自优化 |
|
||||
| **按需 vs 承诺** | 两者混合以平衡灵活性和成本 |
|
||||
| **持续优化** | 定期评估和调整 |
|
||||
| **业务价值驱动** | 成本透明支撑业务决策 |
|
||||
|
||||
## FinOps Maturity Model
|
||||
|
||||
| Level | 描述 | 特征 |
|
||||
|-------|------|------|
|
||||
| **Crawl** | 可见性 | 建立标签、成本分配、基础监控 |
|
||||
| **Walk** | 优化 | .right-sizing、预留购买、自动化 |
|
||||
| **Run** | 自动化 | 实时优化、自动策略执行 |
|
||||
|
||||
## Key Practices
|
||||
|
||||
### 1. Chargeback / Showback
|
||||
|
||||
| 模型 | 描述 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| **Showback** | 向部门展示成本 | 培养成本意识 |
|
||||
| **Chargeback** | 部门承担实际成本 | 强化责任 |
|
||||
|
||||
### 2. Resource Tagging
|
||||
|
||||
**必需标签**
|
||||
| 标签 | 示例 | 用途 |
|
||||
|------|------|------|
|
||||
| `Environment` | prod, staging | 环境隔离 |
|
||||
| `Owner` | alice@example.com | 责任追踪 |
|
||||
| `CostCenter` | CC-12345 | 财务归因 |
|
||||
| `Application` | billing-api | 应用关联 |
|
||||
|
||||
### 3. Cost Optimization
|
||||
|
||||
**技术**
|
||||
- .Right-sizing（资源优化）
|
||||
- Reserved Instances / Savings Plans
|
||||
- Spot/Preemptible 实例
|
||||
- 生命周期策略（存储）
|
||||
- 闲置资源清理
|
||||
|
||||
**流程**
|
||||
- 定期成本审视（Weekly/Monthly）
|
||||
- 预算告警
|
||||
- 成本异常检测
|
||||
- 优化建议 Review
|
||||
|
||||
### 4. Unit Economics
|
||||
|
||||
| 指标 | 公式 | 目标 |
|
||||
|------|------|------|
|
||||
| **Cost per Transaction** | 总成本 / 交易数 | 持续降低 |
|
||||
| **Cost per User** | 总成本 / 用户数 | 持续降低 |
|
||||
| **Cost per Revenue** | 总成本 / 收入 | 稳定或降低 |
|
||||
|
||||
## Tools
|
||||
|
||||
| 类别 | 工具 |
|
||||
|------|------|
|
||||
| **原生** | AWS Cost Explorer, Azure Cost Management, GCP Billing |
|
||||
| **第三方** | Spot.io, CloudHealth, Densify, Kubecost |
|
||||
| **BI/可视化** | Tableau, Looker, Power BI |
|
||||
|
||||
## FinOps Team Roles
|
||||
|
||||
| 角色 | 职责 |
|
||||
|------|------|
|
||||
| **FinOps Practitioner** | 日常成本监控和分析 |
|
||||
| **FinOps Lead** | 策略制定、跨团队协调 |
|
||||
| **Cloud Economist** | 云经济学、成本建模 |
|
||||
| **Business Partner** | 业务部门对接 |
|
||||
|
||||
## Integration with Other Practices
|
||||
|
||||
| 实践 | 关系 |
|
||||
|------|------|
|
||||
| **DevOps** | FinOps-aware 开发 |
|
||||
| **SRE** | 可靠性与成本平衡（SLO vs 成本） |
|
||||
| **Cloud Governance** | 成本策略是治理一部分 |
|
||||
| **Cloud Security** | 安全成本量化 |
|
||||
|
||||
## See Also
|
||||
|
||||
- [[Cloud Cost Optimization]] — 云成本优化
|
||||
- [[Cloud Governance]] — 云治理
|
||||
- [[Cloud Adoption Strategy]] — 云采用策略
|
||||
- [[Multi-Cloud Strategy]] — 多云策略
|
||||
- [[DORA Metrics]] — DORA 指标
|
||||
---
|
||||
title: "FinOps"
|
||||
type: concept
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
---
|
||||
|
||||
# FinOps
|
||||
|
||||
> **FinOps** — Cloud Financial Management，云财务管理，是一种将财务责任、跨团队协作和业务价值最大化相结合的云成本管理实践。
|
||||
|
||||
## Definition
|
||||
|
||||
FinOps（Financial Operations）是云时代的一种运营框架：
|
||||
|
||||
- **可见性** — 了解云支出去向
|
||||
- **优化** — 持续减少浪费
|
||||
- **业务价值** — 最大化云投资回报
|
||||
|
||||
## FinOps Core Principles
|
||||
|
||||
| 原则 | 描述 |
|
||||
|------|------|
|
||||
| **云是一个 marketplaces** | 实时价格，竞争驱动 |
|
||||
| **财务责任人人有责** | 集中团队无法独自优化 |
|
||||
| **按需 vs 承诺** | 两者混合以平衡灵活性和成本 |
|
||||
| **持续优化** | 定期评估和调整 |
|
||||
| **业务价值驱动** | 成本透明支撑业务决策 |
|
||||
|
||||
## FinOps Maturity Model
|
||||
|
||||
| Level | 描述 | 特征 |
|
||||
|-------|------|------|
|
||||
| **Crawl** | 可见性 | 建立标签、成本分配、基础监控 |
|
||||
| **Walk** | 优化 | .right-sizing、预留购买、自动化 |
|
||||
| **Run** | 自动化 | 实时优化、自动策略执行 |
|
||||
|
||||
## Key Practices
|
||||
|
||||
### 1. Chargeback / Showback
|
||||
|
||||
| 模型 | 描述 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| **Showback** | 向部门展示成本 | 培养成本意识 |
|
||||
| **Chargeback** | 部门承担实际成本 | 强化责任 |
|
||||
|
||||
### 2. Resource Tagging
|
||||
|
||||
**必需标签**
|
||||
| 标签 | 示例 | 用途 |
|
||||
|------|------|------|
|
||||
| `Environment` | prod, staging | 环境隔离 |
|
||||
| `Owner` | alice@example.com | 责任追踪 |
|
||||
| `CostCenter` | CC-12345 | 财务归因 |
|
||||
| `Application` | billing-api | 应用关联 |
|
||||
|
||||
### 3. Cost Optimization
|
||||
|
||||
**技术**
|
||||
- .Right-sizing（资源优化）
|
||||
- Reserved Instances / Savings Plans
|
||||
- Spot/Preemptible 实例
|
||||
- 生命周期策略（存储）
|
||||
- 闲置资源清理
|
||||
|
||||
**流程**
|
||||
- 定期成本审视（Weekly/Monthly）
|
||||
- 预算告警
|
||||
- 成本异常检测
|
||||
- 优化建议 Review
|
||||
|
||||
### 4. Unit Economics
|
||||
|
||||
| 指标 | 公式 | 目标 |
|
||||
|------|------|------|
|
||||
| **Cost per Transaction** | 总成本 / 交易数 | 持续降低 |
|
||||
| **Cost per User** | 总成本 / 用户数 | 持续降低 |
|
||||
| **Cost per Revenue** | 总成本 / 收入 | 稳定或降低 |
|
||||
|
||||
## Tools
|
||||
|
||||
| 类别 | 工具 |
|
||||
|------|------|
|
||||
| **原生** | AWS Cost Explorer, Azure Cost Management, GCP Billing |
|
||||
| **第三方** | Spot.io, CloudHealth, Densify, Kubecost |
|
||||
| **BI/可视化** | Tableau, Looker, Power BI |
|
||||
|
||||
## FinOps Team Roles
|
||||
|
||||
| 角色 | 职责 |
|
||||
|------|------|
|
||||
| **FinOps Practitioner** | 日常成本监控和分析 |
|
||||
| **FinOps Lead** | 策略制定、跨团队协调 |
|
||||
| **Cloud Economist** | 云经济学、成本建模 |
|
||||
| **Business Partner** | 业务部门对接 |
|
||||
|
||||
## Integration with Other Practices
|
||||
|
||||
| 实践 | 关系 |
|
||||
|------|------|
|
||||
| **DevOps** | FinOps-aware 开发 |
|
||||
| **SRE** | 可靠性与成本平衡（SLO vs 成本） |
|
||||
| **Cloud Governance** | 成本策略是治理一部分 |
|
||||
| **Cloud Security** | 安全成本量化 |
|
||||
|
||||
## See Also
|
||||
|
||||
- [[Cloud Cost Optimization]] — 云成本优化
|
||||
- [[Cloud Governance]] — 云治理
|
||||
- [[Cloud Adoption Strategy]] — 云采用策略
|
||||
- [[Multi-Cloud Strategy]] — 多云策略
|
||||
- [[DORA Metrics]] — DORA 指标
|
||||
|
||||
@@ -1,60 +1,60 @@
|
||||
---
|
||||
title: "Fstab"
|
||||
type: concept
|
||||
tags: [linux, mount, filesystem, startup, nfs]
|
||||
date: 2026-04-28
|
||||
---
|
||||
|
||||
# Fstab
|
||||
|
||||
## Aliases
|
||||
- /etc/fstab
|
||||
- fstab
|
||||
- 文件系统表
|
||||
|
||||
## Definition
|
||||
`/etc/fstab`（Filesystem Table）是 Linux 系统中定义文件系统挂载关系的配置文件，每行描述一个文件系统（设备/UUID/标签、网络挂载等）及其挂载参数，系统启动时通过 `mount -a` 读取并自动挂载所有条目。相比手动 `mount` 命令，fstab 配置的挂载在重启后自动生效，是实现永久挂载的标准方法。
|
||||
|
||||
## Format
|
||||
```
|
||||
<设备/UUID/标签> <挂载点> <文件系统类型> <选项> <dump> <pass>
|
||||
```
|
||||
|
||||
## Example: NFS 永久挂载
|
||||
```
|
||||
192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0
|
||||
```
|
||||
|
||||
## Key Parameters for NFS Mount
|
||||
| 参数 | 说明 |
|
||||
|------|------|
|
||||
| `defaults` | 使用默认挂载选项（rw, suid, dev, exec, auto, nouser, async） |
|
||||
| `timeo=900` | 超时时间 90 秒（单位 1/10 秒），NFS 网络延迟大时需要增大 |
|
||||
| `retrans=5` | 超时后重试 5 次 |
|
||||
| `_netdev` | **关键参数**：通知系统这是网络设备，等待网络服务就绪后再挂载，防止开机卡死 |
|
||||
| `bg` | 挂载失败时放入后台，避免阻塞启动进程 |
|
||||
|
||||
## Critical Safety Rule
|
||||
> **修改 fstab 后，禁止直接重启！** 必须先用 `sudo mount -a` 验证配置正确性。如果 fstab 写错导致挂载失败，系统可能无法正常启动。
|
||||
|
||||
## Verification Workflow
|
||||
```bash
|
||||
# 1. 卸载当前挂载（如有）
|
||||
sudo umount /mnt/nas_backup
|
||||
|
||||
# 2. 模拟开机自动挂载
|
||||
sudo mount -a
|
||||
|
||||
# 3. 检查挂载是否成功
|
||||
df -h | grep nas_backup
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[永久挂载]] — fstab 是实现永久挂载的核心配置文件
|
||||
- [[挂载点检查]] — 备份脚本需检查 fstab 配置的挂载点是否生效
|
||||
- [[NFS]] — NFS 挂载必须通过 fstab 才能在重启后持久化
|
||||
- [[rsync]] — rsync 备份前应确认 fstab 挂载点就绪
|
||||
|
||||
## Related Sources
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — fstab NFS 挂载配置的实际应用
|
||||
- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] — fstab 配置详细说明
|
||||
---
|
||||
title: "Fstab"
|
||||
type: concept
|
||||
tags: [linux, mount, filesystem, startup, nfs]
|
||||
date: 2026-04-28
|
||||
---
|
||||
|
||||
# Fstab
|
||||
|
||||
## Aliases
|
||||
- /etc/fstab
|
||||
- fstab
|
||||
- 文件系统表
|
||||
|
||||
## Definition
|
||||
`/etc/fstab`（Filesystem Table）是 Linux 系统中定义文件系统挂载关系的配置文件，每行描述一个文件系统（设备/UUID/标签、网络挂载等）及其挂载参数，系统启动时通过 `mount -a` 读取并自动挂载所有条目。相比手动 `mount` 命令，fstab 配置的挂载在重启后自动生效，是实现永久挂载的标准方法。
|
||||
|
||||
## Format
|
||||
```
|
||||
<设备/UUID/标签> <挂载点> <文件系统类型> <选项> <dump> <pass>
|
||||
```
|
||||
|
||||
## Example: NFS 永久挂载
|
||||
```
|
||||
192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0
|
||||
```
|
||||
|
||||
## Key Parameters for NFS Mount
|
||||
| 参数 | 说明 |
|
||||
|------|------|
|
||||
| `defaults` | 使用默认挂载选项（rw, suid, dev, exec, auto, nouser, async） |
|
||||
| `timeo=900` | 超时时间 90 秒（单位 1/10 秒），NFS 网络延迟大时需要增大 |
|
||||
| `retrans=5` | 超时后重试 5 次 |
|
||||
| `_netdev` | **关键参数**：通知系统这是网络设备，等待网络服务就绪后再挂载，防止开机卡死 |
|
||||
| `bg` | 挂载失败时放入后台，避免阻塞启动进程 |
|
||||
|
||||
## Critical Safety Rule
|
||||
> **修改 fstab 后，禁止直接重启！** 必须先用 `sudo mount -a` 验证配置正确性。如果 fstab 写错导致挂载失败，系统可能无法正常启动。
|
||||
|
||||
## Verification Workflow
|
||||
```bash
|
||||
# 1. 卸载当前挂载（如有）
|
||||
sudo umount /mnt/nas_backup
|
||||
|
||||
# 2. 模拟开机自动挂载
|
||||
sudo mount -a
|
||||
|
||||
# 3. 检查挂载是否成功
|
||||
df -h | grep nas_backup
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[永久挂载]] — fstab 是实现永久挂载的核心配置文件
|
||||
- [[挂载点检查]] — 备份脚本需检查 fstab 配置的挂载点是否生效
|
||||
- [[NFS]] — NFS 挂载必须通过 fstab 才能在重启后持久化
|
||||
- [[rsync]] — rsync 备份前应确认 fstab 挂载点就绪
|
||||
|
||||
## Related Sources
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — fstab NFS 挂载配置的实际应用
|
||||
- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] — fstab 配置详细说明
|
||||
|
||||
@@ -1,38 +1,38 @@
|
||||
---
|
||||
title: "GPT分区表"
|
||||
type: concept
|
||||
tags: [partition, uefi, gpt, mbr, storage]
|
||||
date: 2026-04-26
|
||||
aliases: [GUID Partition Table, GPT]
|
||||
---
|
||||
|
||||
# GPT分区表
|
||||
|
||||
## Definition
|
||||
GPT（GUID Partition Table，全局唯一标识分区表）是 UEFI 规范推荐的现代磁盘分区方案，用于替代传统 MBR 分区表。GPT 支持超过 2TB 磁盘、最多 128 个主分区、与 UEFI 引导完美兼容，是现代工作站和服务器的必选分区标准。
|
||||
|
||||
## GPT vs MBR
|
||||
| 特性 | GPT | MBR |
|
||||
|------|-----|-----|
|
||||
| 磁盘容量限制 | 无（>2TB） | 2TB |
|
||||
| 最大分区数 | 128 | 4 个主分区 |
|
||||
| 启动兼容性 | UEFI Only | BIOS/Legacy |
|
||||
| 元数据备份 | 磁盘头部 + 尾部双备份 | 仅头部 |
|
||||
| 校验机制 | CRC32 校验 | 无 |
|
||||
|
||||
## HP ZBook 分区要求
|
||||
- **必须使用 GPT**：HP ZBook 属于现代 UEFI 设备，不再建议使用 MBR
|
||||
- Rufus 制作启动盘时，分区方案必须选择 **GPT**
|
||||
- GPT 配合 UEFI 启动：目标系统类型自动变为 `UEFI (non CSM)`
|
||||
- 文件系统：EFI 分区使用 FAT32（UEFI 标准格式），数据分区推荐 ext4
|
||||
|
||||
## Related
|
||||
- [[UEFI启动]] — GPT 是 UEFI 的配套分区标准
|
||||
- [[NVMe硬盘分区]] — GPT 是 NVMe 硬盘的标准分区表方案
|
||||
- [[HP ZBook]] — 必须使用 GPT 的目标设备
|
||||
- [[ISOHybrid镜像]] — Rufus 写入镜像时的分区表兼容性
|
||||
- [[MBR分区表]] — GPT 取代的传统分区方案
|
||||
|
||||
## Sources
|
||||
- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]]
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]]
|
||||
---
|
||||
title: "GPT分区表"
|
||||
type: concept
|
||||
tags: [partition, uefi, gpt, mbr, storage]
|
||||
date: 2026-04-26
|
||||
aliases: [GUID Partition Table, GPT]
|
||||
---
|
||||
|
||||
# GPT分区表
|
||||
|
||||
## Definition
|
||||
GPT（GUID Partition Table，全局唯一标识分区表）是 UEFI 规范推荐的现代磁盘分区方案，用于替代传统 MBR 分区表。GPT 支持超过 2TB 磁盘、最多 128 个主分区、与 UEFI 引导完美兼容，是现代工作站和服务器的必选分区标准。
|
||||
|
||||
## GPT vs MBR
|
||||
| 特性 | GPT | MBR |
|
||||
|------|-----|-----|
|
||||
| 磁盘容量限制 | 无（>2TB） | 2TB |
|
||||
| 最大分区数 | 128 | 4 个主分区 |
|
||||
| 启动兼容性 | UEFI Only | BIOS/Legacy |
|
||||
| 元数据备份 | 磁盘头部 + 尾部双备份 | 仅头部 |
|
||||
| 校验机制 | CRC32 校验 | 无 |
|
||||
|
||||
## HP ZBook 分区要求
|
||||
- **必须使用 GPT**：HP ZBook 属于现代 UEFI 设备，不再建议使用 MBR
|
||||
- Rufus 制作启动盘时，分区方案必须选择 **GPT**
|
||||
- GPT 配合 UEFI 启动：目标系统类型自动变为 `UEFI (non CSM)`
|
||||
- 文件系统：EFI 分区使用 FAT32（UEFI 标准格式），数据分区推荐 ext4
|
||||
|
||||
## Related
|
||||
- [[UEFI启动]] — GPT 是 UEFI 的配套分区标准
|
||||
- [[NVMe硬盘分区]] — GPT 是 NVMe 硬盘的标准分区表方案
|
||||
- [[HP ZBook]] — 必须使用 GPT 的目标设备
|
||||
- [[ISOHybrid镜像]] — Rufus 写入镜像时的分区表兼容性
|
||||
- [[MBR分区表]] — GPT 取代的传统分区方案
|
||||
|
||||
## Sources
|
||||
- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]]
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]]
|
||||
|
||||
@@ -1,75 +1,75 @@
|
||||
---
|
||||
title: "Green Computing"
|
||||
type: concept
|
||||
tags: [Cloud, Sustainability, Environmental, Cloud Operations]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Green Computing (绿色计算)
|
||||
|
||||
## Definition
|
||||
**Green Computing** refers to environmentally sustainable computing practices that reduce energy consumption, minimize carbon footprint, and promote eco-friendly technology usage in data centers and cloud environments.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
### Environmental Impact
|
||||
- **Data centers consume 1% of global electricity** — a number expected to rise (International Energy Agency)
|
||||
- Growing cloud infrastructure increases energy demands
|
||||
- Regulatory bodies pressuring organizations for sustainable solutions
|
||||
|
||||
### Business Benefits
|
||||
- Reduce operational costs through energy efficiency
|
||||
- Meet corporate sustainability goals
|
||||
- Comply with environmental regulations
|
||||
- Enhance brand reputation
|
||||
|
||||
## Key Strategies
|
||||
|
||||
### 1. Serverless Computing
|
||||
- Eliminates unnecessary resource consumption
|
||||
- Pay-only-for-execution model
|
||||
- Automatic resource optimization
|
||||
|
||||
### 2. Sustainable Data Centers
|
||||
- Major providers investing in carbon-neutral infrastructure
|
||||
- AWS, Azure, and Google Cloud commitment to renewable energy
|
||||
- Efficient cooling and power systems
|
||||
|
||||
### 3. Workload Optimization
|
||||
- Shift workloads to energy-efficient regions
|
||||
- Right-size resources to actual needs
|
||||
- Schedule non-critical workloads for off-peak times
|
||||
|
||||
### 4. Cloud Sustainability Tools
|
||||
- Carbon footprint tracking
|
||||
- Energy efficiency dashboards
|
||||
- Resource usage optimization
|
||||
|
||||
## Industry Trends
|
||||
|
||||
### Cloud Provider Commitments
|
||||
- **AWS**: Carbon-neutral by 2040
|
||||
- **Microsoft Azure**: Carbon-negative by 2030
|
||||
- **Google Cloud**: Carbon-free by 2030
|
||||
|
||||
### Regulatory Pressures
|
||||
- Corporate sustainability mandates
|
||||
- Environmental reporting requirements
|
||||
- Carbon tax implications
|
||||
|
||||
## Relationship to Cloud Operating Model
|
||||
- Green Computing is an emerging pillar of modern [[Cloud Operating Model]]
|
||||
- 8% of organizations now prioritize sustainability in cloud adoption
|
||||
- Part of future trends in cloud management
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Operating Model]]
|
||||
- [[Serverless Computing]]
|
||||
- [[Cloud Cost Optimization]]
|
||||
- [[Multi-Cloud Strategy]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Azure]]
|
||||
- [[Google-Cloud]]
|
||||
---
|
||||
title: "Green Computing"
|
||||
type: concept
|
||||
tags: [Cloud, Sustainability, Environmental, Cloud Operations]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# Green Computing (绿色计算)
|
||||
|
||||
## Definition
|
||||
**Green Computing** refers to environmentally sustainable computing practices that reduce energy consumption, minimize carbon footprint, and promote eco-friendly technology usage in data centers and cloud environments.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
### Environmental Impact
|
||||
- **Data centers consume 1% of global electricity** — a number expected to rise (International Energy Agency)
|
||||
- Growing cloud infrastructure increases energy demands
|
||||
- Regulatory bodies pressuring organizations for sustainable solutions
|
||||
|
||||
### Business Benefits
|
||||
- Reduce operational costs through energy efficiency
|
||||
- Meet corporate sustainability goals
|
||||
- Comply with environmental regulations
|
||||
- Enhance brand reputation
|
||||
|
||||
## Key Strategies
|
||||
|
||||
### 1. Serverless Computing
|
||||
- Eliminates unnecessary resource consumption
|
||||
- Pay-only-for-execution model
|
||||
- Automatic resource optimization
|
||||
|
||||
### 2. Sustainable Data Centers
|
||||
- Major providers investing in carbon-neutral infrastructure
|
||||
- AWS, Azure, and Google Cloud commitment to renewable energy
|
||||
- Efficient cooling and power systems
|
||||
|
||||
### 3. Workload Optimization
|
||||
- Shift workloads to energy-efficient regions
|
||||
- Right-size resources to actual needs
|
||||
- Schedule non-critical workloads for off-peak times
|
||||
|
||||
### 4. Cloud Sustainability Tools
|
||||
- Carbon footprint tracking
|
||||
- Energy efficiency dashboards
|
||||
- Resource usage optimization
|
||||
|
||||
## Industry Trends
|
||||
|
||||
### Cloud Provider Commitments
|
||||
- **AWS**: Carbon-neutral by 2040
|
||||
- **Microsoft Azure**: Carbon-negative by 2030
|
||||
- **Google Cloud**: Carbon-free by 2030
|
||||
|
||||
### Regulatory Pressures
|
||||
- Corporate sustainability mandates
|
||||
- Environmental reporting requirements
|
||||
- Carbon tax implications
|
||||
|
||||
## Relationship to Cloud Operating Model
|
||||
- Green Computing is an emerging pillar of modern [[Cloud Operating Model]]
|
||||
- 8% of organizations now prioritize sustainability in cloud adoption
|
||||
- Part of future trends in cloud management
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud Operating Model]]
|
||||
- [[Serverless Computing]]
|
||||
- [[Cloud Cost Optimization]]
|
||||
- [[Multi-Cloud Strategy]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Azure]]
|
||||
- [[Google-Cloud]]
|
||||
|
||||
@@ -1,72 +1,72 @@
|
||||
---
|
||||
title: "Immutable Infrastructure"
|
||||
type: concept
|
||||
tags: [Infrastructure as Code, DevOps, Cloud Native]
|
||||
sources: [devops-maturity-model-from-traditional-it-to-advanced-devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
不可变基础设施（Immutable Infrastructure）是一种基础设施管理范式，服务器一旦部署就不再进行原地修改。当需要更新配置或修复问题时，整个服务器被替换为新版本，而不是在原有服务器上打补丁或更新。
|
||||
|
||||
## 核心原则
|
||||
|
||||
1. **不修改已部署的服务器**：任何变更都生成新服务器镜像
|
||||
2. **完整镜像部署**：使用预构建的镜像完整部署
|
||||
3. **自动化替换**：通过自动化流水线处理服务器生命周期
|
||||
4. **环境一致性**：所有环境使用相同的基础镜像
|
||||
|
||||
## 在 DevOps 成熟度模型中的位置
|
||||
|
||||
不可变基础设施是 **Phase 4（高度优化阶段）** 的关键特征：
|
||||
|
||||
> "Immutable infrastructure replaces old servers rather than updating them."
|
||||
|
||||
在该阶段，组织通过流水线管理基础设施和代码更新，不再依赖手动服务器修改。
|
||||
|
||||
## 不可变 vs 可变基础设施
|
||||
|
||||
| 维度 | 不可变基础设施 | 可变基础设施 |
|
||||
|------|---------------|-------------|
|
||||
| 更新方式 | 替换整个服务器 | 在原服务器上打补丁 |
|
||||
| 一致性 | 所有环境高度一致 | 环境间可能存在差异 |
|
||||
| 回滚难度 | 简单（切换回旧镜像） | 困难（需反向补丁） |
|
||||
| 调试复杂度 | 低（快照确定） | 高（变化累积） |
|
||||
| 部署速度 | 快（预构建镜像） | 慢（需逐步更新） |
|
||||
|
||||
## 实现方式
|
||||
|
||||
### 容器化（推荐）
|
||||
```dockerfile
|
||||
# 每次构建生成新镜像
|
||||
FROM base-image:latest
|
||||
RUN ./build.sh
|
||||
# 部署时拉取新镜像，不修改原容器
|
||||
```
|
||||
|
||||
### 虚拟机镜像
|
||||
```bash
|
||||
# Packer 创建镜像
|
||||
packer build template.json
|
||||
# Terraform 用新 AMI 替换旧实例
|
||||
terraform apply
|
||||
```
|
||||
|
||||
### 云基础设施
|
||||
```yaml
|
||||
# Kubernetes 中使用 Immutable Pod
|
||||
spec:
|
||||
containers:
|
||||
- image: myapp:v2.0 # 替换镜像而非修改容器
|
||||
```
|
||||
|
||||
## 与相关概念的关系
|
||||
|
||||
- [[Infrastructure as Code]]：不可变基础设施通常依赖 IaC 工具（Terraform、CloudFormation）实现
|
||||
- [[CI/CD Pipeline]]：不可变基础设施通过 CI/CD 流水线自动化构建和部署
|
||||
- [[DevOps Maturity Model]]：是 Phase 4 高度优化阶段的核心特征
|
||||
- [[Container-Lifecycle-Hardening]]：容器天然支持不可变范式，结合使用可提升安全性和一致性
|
||||
|
||||
## 来源
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]]
|
||||
---
|
||||
title: "Immutable Infrastructure"
|
||||
type: concept
|
||||
tags: [Infrastructure as Code, DevOps, Cloud Native]
|
||||
sources: [devops-maturity-model-from-traditional-it-to-advanced-devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
不可变基础设施（Immutable Infrastructure）是一种基础设施管理范式，服务器一旦部署就不再进行原地修改。当需要更新配置或修复问题时，整个服务器被替换为新版本，而不是在原有服务器上打补丁或更新。
|
||||
|
||||
## 核心原则
|
||||
|
||||
1. **不修改已部署的服务器**：任何变更都生成新服务器镜像
|
||||
2. **完整镜像部署**：使用预构建的镜像完整部署
|
||||
3. **自动化替换**：通过自动化流水线处理服务器生命周期
|
||||
4. **环境一致性**：所有环境使用相同的基础镜像
|
||||
|
||||
## 在 DevOps 成熟度模型中的位置
|
||||
|
||||
不可变基础设施是 **Phase 4（高度优化阶段）** 的关键特征：
|
||||
|
||||
> "Immutable infrastructure replaces old servers rather than updating them."
|
||||
|
||||
在该阶段，组织通过流水线管理基础设施和代码更新，不再依赖手动服务器修改。
|
||||
|
||||
## 不可变 vs 可变基础设施
|
||||
|
||||
| 维度 | 不可变基础设施 | 可变基础设施 |
|
||||
|------|---------------|-------------|
|
||||
| 更新方式 | 替换整个服务器 | 在原服务器上打补丁 |
|
||||
| 一致性 | 所有环境高度一致 | 环境间可能存在差异 |
|
||||
| 回滚难度 | 简单（切换回旧镜像） | 困难（需反向补丁） |
|
||||
| 调试复杂度 | 低（快照确定） | 高（变化累积） |
|
||||
| 部署速度 | 快（预构建镜像） | 慢（需逐步更新） |
|
||||
|
||||
## 实现方式
|
||||
|
||||
### 容器化（推荐）
|
||||
```dockerfile
|
||||
# 每次构建生成新镜像
|
||||
FROM base-image:latest
|
||||
RUN ./build.sh
|
||||
# 部署时拉取新镜像，不修改原容器
|
||||
```
|
||||
|
||||
### 虚拟机镜像
|
||||
```bash
|
||||
# Packer 创建镜像
|
||||
packer build template.json
|
||||
# Terraform 用新 AMI 替换旧实例
|
||||
terraform apply
|
||||
```
|
||||
|
||||
### 云基础设施
|
||||
```yaml
|
||||
# Kubernetes 中使用 Immutable Pod
|
||||
spec:
|
||||
containers:
|
||||
- image: myapp:v2.0 # 替换镜像而非修改容器
|
||||
```
|
||||
|
||||
## 与相关概念的关系
|
||||
|
||||
- [[Infrastructure as Code]]：不可变基础设施通常依赖 IaC 工具（Terraform、CloudFormation）实现
|
||||
- [[CI/CD Pipeline]]：不可变基础设施通过 CI/CD 流水线自动化构建和部署
|
||||
- [[DevOps Maturity Model]]：是 Phase 4 高度优化阶段的核心特征
|
||||
- [[Container-Lifecycle-Hardening]]：容器天然支持不可变范式，结合使用可提升安全性和一致性
|
||||
|
||||
## 来源
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]]
|
||||
|
||||
@@ -1,49 +1,49 @@
|
||||
---
|
||||
title: "Infrastructure as Code"
|
||||
type: concept
|
||||
tags: [DevOps, AWS, Terraform, Automation]
|
||||
sources: [ctp-topic-3-deploy-and-maintain-infrastructure, ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments, ctp-topic-33-an-introduction-to-gitops, ctp-topic-56-automated-infrastructure-testing, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, cloud-operating-model-key-strategies-and-best-practices]
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
# Infrastructure as Code
|
||||
|
||||
## Definition
|
||||
基础设施即代码（Infrastructure as Code, IaC）是一种通过机器可读的定义文件（而非物理硬件配置或交互式配置工具）管理和配置计算基础设施的方法。
|
||||
|
||||
## Core Principles
|
||||
- **声明式配置**：描述期望的最终状态，而非执行的具体步骤
|
||||
- **版本控制**：所有基础设施定义文件存储在 Git 中
|
||||
- **幂等性**：多次执行产生相同结果
|
||||
- **可重复性**：同一模板可在不同环境快速部署
|
||||
- **自动化**：与 CI/CD 流水线集成
|
||||
|
||||
## Key Tools
|
||||
- **Terraform**：HashiCorp 出品，云厂商无关的 IaC 工具，通过状态文件管理资源
|
||||
- **Terragrunt**：Terraform 轻量封装，贯彻 DRY 原则
|
||||
- **AWS CloudFormation**：AWS 原生 IaC 服务，JSON/YAML 模板
|
||||
- **Pulumi**：编程语言驱动的 IaC 平台
|
||||
- **Ansible**：配置管理和应用部署工具
|
||||
|
||||
## Terraform Ecosystem
|
||||
- **Gruntwork**：预建 Terraform 模块库，生产级参考架构
|
||||
- **Atlantis**：Git 集成 Terraform 部署，PR 评论式协作
|
||||
- **Terratest**：Terraform 代码的 Go 测试框架
|
||||
- **tfsec**：Terraform 静态安全分析工具
|
||||
- **TFLint**：Terraform 代码规范检查
|
||||
|
||||
## IaC in CTP Context
|
||||
CTP（Cloud Transformation Programme）使用 Terraform/Terragrunt 构建 AWS Landing Zone：
|
||||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]]：Terragrunt HCL 文件与模块化管理
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]]：Gruntwork CI/CD 流水线实践
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比选型
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]：Atlantis 替代 Jenkins
|
||||
- [[ctp-topic-56-automated-infrastructure-testing]]：TerraTest 自动化测试
|
||||
- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：ECS IaC 部署实践
|
||||
|
||||
## Related Concepts
|
||||
- [[GitOps]]：Git 作为 IaC 的单一真相来源
|
||||
- [[CI/CD Pipeline]]：IaC 与 CI/CD 流水线的集成
|
||||
- [[Policy-as-Code]]：IaC 扩展至安全合规策略
|
||||
- [[Canary-Deployment]]：基于 IaC 的金丝雀部署策略
|
||||
- [[Atlantis]]：GitOps 驱动的 Terraform 协作工具
|
||||
---
|
||||
title: "Infrastructure as Code"
|
||||
type: concept
|
||||
tags: [DevOps, AWS, Terraform, Automation]
|
||||
sources: [ctp-topic-3-deploy-and-maintain-infrastructure, ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments, ctp-topic-33-an-introduction-to-gitops, ctp-topic-56-automated-infrastructure-testing, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, cloud-operating-model-key-strategies-and-best-practices]
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
# Infrastructure as Code
|
||||
|
||||
## Definition
|
||||
基础设施即代码（Infrastructure as Code, IaC）是一种通过机器可读的定义文件（而非物理硬件配置或交互式配置工具）管理和配置计算基础设施的方法。
|
||||
|
||||
## Core Principles
|
||||
- **声明式配置**：描述期望的最终状态，而非执行的具体步骤
|
||||
- **版本控制**：所有基础设施定义文件存储在 Git 中
|
||||
- **幂等性**：多次执行产生相同结果
|
||||
- **可重复性**：同一模板可在不同环境快速部署
|
||||
- **自动化**：与 CI/CD 流水线集成
|
||||
|
||||
## Key Tools
|
||||
- **Terraform**：HashiCorp 出品，云厂商无关的 IaC 工具，通过状态文件管理资源
|
||||
- **Terragrunt**：Terraform 轻量封装，贯彻 DRY 原则
|
||||
- **AWS CloudFormation**：AWS 原生 IaC 服务，JSON/YAML 模板
|
||||
- **Pulumi**：编程语言驱动的 IaC 平台
|
||||
- **Ansible**：配置管理和应用部署工具
|
||||
|
||||
## Terraform Ecosystem
|
||||
- **Gruntwork**：预建 Terraform 模块库，生产级参考架构
|
||||
- **Atlantis**：Git 集成 Terraform 部署，PR 评论式协作
|
||||
- **Terratest**：Terraform 代码的 Go 测试框架
|
||||
- **tfsec**：Terraform 静态安全分析工具
|
||||
- **TFLint**：Terraform 代码规范检查
|
||||
|
||||
## IaC in CTP Context
|
||||
CTP（Cloud Transformation Programme）使用 Terraform/Terragrunt 构建 AWS Landing Zone：
|
||||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]]：Terragrunt HCL 文件与模块化管理
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]]：Gruntwork CI/CD 流水线实践
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比选型
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]：Atlantis 替代 Jenkins
|
||||
- [[ctp-topic-56-automated-infrastructure-testing]]：TerraTest 自动化测试
|
||||
- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：ECS IaC 部署实践
|
||||
|
||||
## Related Concepts
|
||||
- [[GitOps]]：Git 作为 IaC 的单一真相来源
|
||||
- [[CI/CD Pipeline]]：IaC 与 CI/CD 流水线的集成
|
||||
- [[Policy-as-Code]]：IaC 扩展至安全合规策略
|
||||
- [[Canary-Deployment]]：基于 IaC 的金丝雀部署策略
|
||||
- [[Atlantis]]：GitOps 驱动的 Terraform 协作工具
|
||||
|
||||
@@ -1,31 +1,31 @@
|
||||
---
|
||||
title: "LLMasJudge"
|
||||
type: concept
|
||||
tags: ["evaluation", "llm-evaluation", "quality-assurance"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- LLM as a Judge
|
||||
- LLM-as-Judge
|
||||
- LLM-as-a-Judge Grading
|
||||
|
||||
## Definition
|
||||
LLM-as-a-Judge 是 [[AutonomousOptimizationArchitect]] 的评分机制——使用一个独立的 LLM（如 Claude Opus）作为"裁判"，对实验模型和生产模型的输出进行客观评分，避免人工评审的主观偏差。评分维度包括：JSON 格式正确性（5分）、延迟（3分）、幻觉检测（-10分）等。
|
||||
|
||||
## Mechanism
|
||||
1. **评分标准预先建立**：在 [[ShadowTraffic]] 测试前，[[AutonomousOptimizationArchitect]] 明确建立数学评分标准
|
||||
2. **异步评估**：实验模型和生产模型同时处理任务，裁判 LLM 盲评两者输出
|
||||
3. **统计分析**：累积足够样本后进行统计显著性检验
|
||||
4. **自主决策**：实验模型显著优于基准时，更新路由权重
|
||||
|
||||
## Key Properties
|
||||
- **客观性**：消除人工评分的主观偏差
|
||||
- **可扩展**：可同时评估多个 Provider 的输出
|
||||
- **数据驱动**：评分结果直接驱动 [[SemanticRouting]] 决策
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — LLM-as-Judge 是核心评估工具
|
||||
- [[ShadowTraffic]] — 提供实验与基准并行执行的流量环境
|
||||
- [[SemanticRouting]] — 评分结果更新路由权重
|
||||
---
|
||||
title: "LLMasJudge"
|
||||
type: concept
|
||||
tags: ["evaluation", "llm-evaluation", "quality-assurance"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- LLM as a Judge
|
||||
- LLM-as-Judge
|
||||
- LLM-as-a-Judge Grading
|
||||
|
||||
## Definition
|
||||
LLM-as-a-Judge 是 [[AutonomousOptimizationArchitect]] 的评分机制——使用一个独立的 LLM（如 Claude Opus）作为"裁判"，对实验模型和生产模型的输出进行客观评分，避免人工评审的主观偏差。评分维度包括：JSON 格式正确性（5分）、延迟（3分）、幻觉检测（-10分）等。
|
||||
|
||||
## Mechanism
|
||||
1. **评分标准预先建立**：在 [[ShadowTraffic]] 测试前，[[AutonomousOptimizationArchitect]] 明确建立数学评分标准
|
||||
2. **异步评估**：实验模型和生产模型同时处理任务，裁判 LLM 盲评两者输出
|
||||
3. **统计分析**：累积足够样本后进行统计显著性检验
|
||||
4. **自主决策**：实验模型显著优于基准时，更新路由权重
|
||||
|
||||
## Key Properties
|
||||
- **客观性**：消除人工评分的主观偏差
|
||||
- **可扩展**：可同时评估多个 Provider 的输出
|
||||
- **数据驱动**：评分结果直接驱动 [[SemanticRouting]] 决策
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — LLM-as-Judge 是核心评估工具
|
||||
- [[ShadowTraffic]] — 提供实验与基准并行执行的流量环境
|
||||
- [[SemanticRouting]] — 评分结果更新路由权重
|
||||
|
||||
@@ -1,49 +1,49 @@
|
||||
---
|
||||
title: "MVP"
|
||||
type: concept
|
||||
tags: [Product Development, Agile, Lean Startup]
|
||||
sources: [devops-maturity-model-from-traditional-it-to-advanced-devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
MVP（Minimum Viable Product，最小可行产品）是指具有最小功能集的产品版本，仅包含核心功能足以满足早期用户需求并收集验证性反馈。
|
||||
|
||||
## 核心特征
|
||||
|
||||
- **最小功能集**：只实现解决核心问题所必需的最小功能
|
||||
- **快速验证**：尽早发布以获得真实用户反馈
|
||||
- **学习导向**：优先获取市场验证数据而非追求功能完备
|
||||
- **迭代演进**：基于反馈快速迭代改进
|
||||
|
||||
## 与 DevOps 成熟度的关系
|
||||
|
||||
在 DevOps 成熟度模型中，MVP 是 **Phase 4（高度优化阶段）** 的关键实践：
|
||||
|
||||
> "Use of MVPs and management of tech debt to speed up releases."
|
||||
|
||||
在该阶段，组织已建立成熟的 CI/CD 流水线，可以：
|
||||
1. 快速构建和部署 MVP
|
||||
2. 收集生产环境真实反馈
|
||||
3. 缩短从想法到验证的周期
|
||||
4. 降低大功能发布的风险
|
||||
|
||||
## MVP vs 完整产品
|
||||
|
||||
| 维度 | MVP | 完整产品 |
|
||||
|------|-----|---------|
|
||||
| 功能范围 | 最小核心功能 | 完整功能集 |
|
||||
| 目标 | 验证假设 | 全面满足需求 |
|
||||
| 发布时间 | 尽早发布 | 功能完备后发布 |
|
||||
| 反馈来源 | 早期用户 | 广泛用户群 |
|
||||
| 风险 | 低投入高学习 | 高投入风险大 |
|
||||
|
||||
## 与相关概念的关系
|
||||
|
||||
- [[Agile]]：MVP 是敏捷开发的核心实践之一，支持快速迭代
|
||||
- [[Technical Debt]]：MVP 策略需要平衡快速交付与技术债务管理
|
||||
- [[DevOps Maturity Model]]：在 Phase 4 高度优化阶段，MVP 被用于加速发布周期
|
||||
|
||||
## 来源
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]]
|
||||
---
|
||||
title: "MVP"
|
||||
type: concept
|
||||
tags: [Product Development, Agile, Lean Startup]
|
||||
sources: [devops-maturity-model-from-traditional-it-to-advanced-devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## 定义
|
||||
|
||||
MVP（Minimum Viable Product，最小可行产品）是指具有最小功能集的产品版本，仅包含核心功能足以满足早期用户需求并收集验证性反馈。
|
||||
|
||||
## 核心特征
|
||||
|
||||
- **最小功能集**：只实现解决核心问题所必需的最小功能
|
||||
- **快速验证**：尽早发布以获得真实用户反馈
|
||||
- **学习导向**：优先获取市场验证数据而非追求功能完备
|
||||
- **迭代演进**：基于反馈快速迭代改进
|
||||
|
||||
## 与 DevOps 成熟度的关系
|
||||
|
||||
在 DevOps 成熟度模型中，MVP 是 **Phase 4（高度优化阶段）** 的关键实践：
|
||||
|
||||
> "Use of MVPs and management of tech debt to speed up releases."
|
||||
|
||||
在该阶段，组织已建立成熟的 CI/CD 流水线，可以：
|
||||
1. 快速构建和部署 MVP
|
||||
2. 收集生产环境真实反馈
|
||||
3. 缩短从想法到验证的周期
|
||||
4. 降低大功能发布的风险
|
||||
|
||||
## MVP vs 完整产品
|
||||
|
||||
| 维度 | MVP | 完整产品 |
|
||||
|------|-----|---------|
|
||||
| 功能范围 | 最小核心功能 | 完整功能集 |
|
||||
| 目标 | 验证假设 | 全面满足需求 |
|
||||
| 发布时间 | 尽早发布 | 功能完备后发布 |
|
||||
| 反馈来源 | 早期用户 | 广泛用户群 |
|
||||
| 风险 | 低投入高学习 | 高投入风险大 |
|
||||
|
||||
## 与相关概念的关系
|
||||
|
||||
- [[Agile]]：MVP 是敏捷开发的核心实践之一，支持快速迭代
|
||||
- [[Technical Debt]]：MVP 策略需要平衡快速交付与技术债务管理
|
||||
- [[DevOps Maturity Model]]：在 Phase 4 高度优化阶段，MVP 被用于加速发布周期
|
||||
|
||||
## 来源
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]]
|
||||
|
||||
@@ -1,137 +1,137 @@
|
||||
---
|
||||
title: "Multi-Cloud Strategy"
|
||||
type: concept
|
||||
sources: [how-can-a-multi-cloud-strategy-transform-your-business-roi, cloud-operating-model-key-strategies-and-best-practices]
|
||||
---
|
||||
|
||||
# Multi-Cloud Strategy
|
||||
|
||||
> **Multi-Cloud Strategy** — 使用多个云服务提供商（公有云、私有云或两者结合）来托管工作负载和服务，以避免供应商锁定、增强弹性和优化成本。
|
||||
|
||||
## Definition
|
||||
|
||||
多云策略（Multi-Cloud Strategy）是指组织同时使用两个或多个云服务提供商的服务。这种策略可以结合不同云服务商的优势，实现：
|
||||
|
||||
- **避免供应商锁定** — 不依赖单一提供商
|
||||
- **增强弹性和可用性** — 跨云冗余
|
||||
- **优化性能和成本** — 选择最适合每个工作负载的云
|
||||
- **满足合规和数据主权要求** — 地理位置控制
|
||||
|
||||
## Multi-Cloud vs Hybrid Cloud
|
||||
|
||||
| 维度 | Multi-Cloud | Hybrid Cloud |
|
||||
|------|------------|-------------|
|
||||
| **定义** | 使用多个公有/私有云 | 公有云 + 私有/本地 |
|
||||
| **连接** | 可选互联 | 强互联 |
|
||||
| **用例** | 避免锁定、优化、成本 | 核心在本地、弹性在云 |
|
||||
| **复杂性** | 中-高 | 中 |
|
||||
| **成本** | 取决于设计 | 可能更优化 |
|
||||
|
||||
## 8 Business Benefits
|
||||
|
||||
### 1. Avoiding Vendor Lock-In
|
||||
|
||||
- 保留谈判筹码
|
||||
- 避免单一供应商涨价风险
|
||||
- 灵活迁移工作负载
|
||||
|
||||
### 2. Enhanced Resilience
|
||||
|
||||
- 跨云冗余消除单点故障
|
||||
- 99.99%+ 可用性目标
|
||||
- 灾难恢复能力增强
|
||||
|
||||
### 3. Improved Security
|
||||
|
||||
- 隔离敏感工作负载
|
||||
- 利用各云最佳安全功能
|
||||
- 满足合规要求
|
||||
|
||||
### 4. Unlimited Scalability
|
||||
|
||||
- 按需扩展计算资源
|
||||
- 全球分布式部署
|
||||
- 应对流量高峰
|
||||
|
||||
### 5. Cost Optimization
|
||||
|
||||
- 选择最具成本效益的云服务
|
||||
- 持续成本监控和优化
|
||||
- 避免过度配置
|
||||
|
||||
### 6. Accelerated Innovation
|
||||
|
||||
- 访问最新云服务
|
||||
- 快速试验和原型
|
||||
- 缩短上市时间
|
||||
|
||||
### 7. Compliance Fulfillment
|
||||
|
||||
- 数据主权控制
|
||||
- 满足地区合规要求
|
||||
- 审计和报告能力
|
||||
|
||||
### 8. Performance Optimization
|
||||
|
||||
- 选择最近/最快的云区域
|
||||
- 针对工作负载优化
|
||||
- 降低延迟
|
||||
|
||||
## ROI Maximization Framework
|
||||
|
||||
### 4 Paths to ROI
|
||||
|
||||
1. **Cost Reduction** — 30% 成本降低
|
||||
2. **Resource Optimization** — 资源利用率提升
|
||||
3. **Efficiency Gains** — 运营效率提升
|
||||
4. **Elastic Scaling** — 弹性扩展节省
|
||||
|
||||
### Industry Adoption
|
||||
|
||||
- 78% 的组织已采用多云策略
|
||||
- 平均使用 2-5 个云服务商
|
||||
- 混合云和多云是主流趋势
|
||||
|
||||
## Implementation Roadmap
|
||||
|
||||
```
|
||||
Phase 1: Assessment & Strategy
|
||||
├── 云就绪度评估
|
||||
├── 工作负载分析
|
||||
└── 供应商选择
|
||||
|
||||
Phase 2: Foundation
|
||||
├── 网络连接设计
|
||||
├── 安全架构
|
||||
└── 治理框架
|
||||
|
||||
Phase 3: Migration
|
||||
├── 低风险工作负载优先
|
||||
├── 渐进式迁移
|
||||
└── 验证和测试
|
||||
|
||||
Phase 4: Optimization
|
||||
├── 成本监控
|
||||
├── 性能调优
|
||||
└── 自动化运维
|
||||
```
|
||||
|
||||
## Key Risks and Mitigation
|
||||
|
||||
| 风险 | 缓解措施 |
|
||||
|------|---------|
|
||||
| 复杂性增加 | 统一管理平台 |
|
||||
| 数据一致性 | 跨云数据同步策略 |
|
||||
| 安全挑战 | 统一安全策略 |
|
||||
| 成本超支 | FinOps 实践 |
|
||||
| 技能缺口 | 培训和认证 |
|
||||
|
||||
## See Also
|
||||
|
||||
- [[Cloud Adoption Strategy]] — 云采用策略
|
||||
- [[Cloud Maturity Model]] — 云成熟度模型
|
||||
- [[Cloud Governance]] — 云治理
|
||||
- [[Cloud Cost Optimization]] — 云成本优化
|
||||
- [[Cloud-Native]] — 云原生
|
||||
- [[Hybrid Cloud]] — 混合云
|
||||
- [[FinOps]] — 云财务管理
|
||||
---
|
||||
title: "Multi-Cloud Strategy"
|
||||
type: concept
|
||||
sources: [how-can-a-multi-cloud-strategy-transform-your-business-roi, cloud-operating-model-key-strategies-and-best-practices]
|
||||
---
|
||||
|
||||
# Multi-Cloud Strategy
|
||||
|
||||
> **Multi-Cloud Strategy** — 使用多个云服务提供商（公有云、私有云或两者结合）来托管工作负载和服务，以避免供应商锁定、增强弹性和优化成本。
|
||||
|
||||
## Definition
|
||||
|
||||
多云策略（Multi-Cloud Strategy）是指组织同时使用两个或多个云服务提供商的服务。这种策略可以结合不同云服务商的优势，实现：
|
||||
|
||||
- **避免供应商锁定** — 不依赖单一提供商
|
||||
- **增强弹性和可用性** — 跨云冗余
|
||||
- **优化性能和成本** — 选择最适合每个工作负载的云
|
||||
- **满足合规和数据主权要求** — 地理位置控制
|
||||
|
||||
## Multi-Cloud vs Hybrid Cloud
|
||||
|
||||
| 维度 | Multi-Cloud | Hybrid Cloud |
|
||||
|------|------------|-------------|
|
||||
| **定义** | 使用多个公有/私有云 | 公有云 + 私有/本地 |
|
||||
| **连接** | 可选互联 | 强互联 |
|
||||
| **用例** | 避免锁定、优化、成本 | 核心在本地、弹性在云 |
|
||||
| **复杂性** | 中-高 | 中 |
|
||||
| **成本** | 取决于设计 | 可能更优化 |
|
||||
|
||||
## 8 Business Benefits
|
||||
|
||||
### 1. Avoiding Vendor Lock-In
|
||||
|
||||
- 保留谈判筹码
|
||||
- 避免单一供应商涨价风险
|
||||
- 灵活迁移工作负载
|
||||
|
||||
### 2. Enhanced Resilience
|
||||
|
||||
- 跨云冗余消除单点故障
|
||||
- 99.99%+ 可用性目标
|
||||
- 灾难恢复能力增强
|
||||
|
||||
### 3. Improved Security
|
||||
|
||||
- 隔离敏感工作负载
|
||||
- 利用各云最佳安全功能
|
||||
- 满足合规要求
|
||||
|
||||
### 4. Unlimited Scalability
|
||||
|
||||
- 按需扩展计算资源
|
||||
- 全球分布式部署
|
||||
- 应对流量高峰
|
||||
|
||||
### 5. Cost Optimization
|
||||
|
||||
- 选择最具成本效益的云服务
|
||||
- 持续成本监控和优化
|
||||
- 避免过度配置
|
||||
|
||||
### 6. Accelerated Innovation
|
||||
|
||||
- 访问最新云服务
|
||||
- 快速试验和原型
|
||||
- 缩短上市时间
|
||||
|
||||
### 7. Compliance Fulfillment
|
||||
|
||||
- 数据主权控制
|
||||
- 满足地区合规要求
|
||||
- 审计和报告能力
|
||||
|
||||
### 8. Performance Optimization
|
||||
|
||||
- 选择最近/最快的云区域
|
||||
- 针对工作负载优化
|
||||
- 降低延迟
|
||||
|
||||
## ROI Maximization Framework
|
||||
|
||||
### 4 Paths to ROI
|
||||
|
||||
1. **Cost Reduction** — 30% 成本降低
|
||||
2. **Resource Optimization** — 资源利用率提升
|
||||
3. **Efficiency Gains** — 运营效率提升
|
||||
4. **Elastic Scaling** — 弹性扩展节省
|
||||
|
||||
### Industry Adoption
|
||||
|
||||
- 78% 的组织已采用多云策略
|
||||
- 平均使用 2-5 个云服务商
|
||||
- 混合云和多云是主流趋势
|
||||
|
||||
## Implementation Roadmap
|
||||
|
||||
```
|
||||
Phase 1: Assessment & Strategy
|
||||
├── 云就绪度评估
|
||||
├── 工作负载分析
|
||||
└── 供应商选择
|
||||
|
||||
Phase 2: Foundation
|
||||
├── 网络连接设计
|
||||
├── 安全架构
|
||||
└── 治理框架
|
||||
|
||||
Phase 3: Migration
|
||||
├── 低风险工作负载优先
|
||||
├── 渐进式迁移
|
||||
└── 验证和测试
|
||||
|
||||
Phase 4: Optimization
|
||||
├── 成本监控
|
||||
├── 性能调优
|
||||
└── 自动化运维
|
||||
```
|
||||
|
||||
## Key Risks and Mitigation
|
||||
|
||||
| 风险 | 缓解措施 |
|
||||
|------|---------|
|
||||
| 复杂性增加 | 统一管理平台 |
|
||||
| 数据一致性 | 跨云数据同步策略 |
|
||||
| 安全挑战 | 统一安全策略 |
|
||||
| 成本超支 | FinOps 实践 |
|
||||
| 技能缺口 | 培训和认证 |
|
||||
|
||||
## See Also
|
||||
|
||||
- [[Cloud Adoption Strategy]] — 云采用策略
|
||||
- [[Cloud Maturity Model]] — 云成熟度模型
|
||||
- [[Cloud Governance]] — 云治理
|
||||
- [[Cloud Cost Optimization]] — 云成本优化
|
||||
- [[Cloud-Native]] — 云原生
|
||||
- [[Hybrid Cloud]] — 混合云
|
||||
- [[FinOps]] — 云财务管理
|
||||
|
||||
@@ -1,38 +1,38 @@
|
||||
---
|
||||
title: "NVMe硬盘分区"
|
||||
type: concept
|
||||
tags: [nvme, linux, partition, ubuntu]
|
||||
date: 2026-04-14
|
||||
aliases: [NVMe, NVMe SSD, PCIe SSD]
|
||||
---
|
||||
|
||||
# NVMe硬盘分区
|
||||
|
||||
## Definition
|
||||
针对 NVMe PCIe 固态硬盘的分区策略与对齐优化。Ubuntu 24.04 自动识别 ZBook 等设备上的 NVMe 硬盘并进行对齐优化，但仍建议手动分区时遵循标准规范。
|
||||
|
||||
## HP ZBook NVMe 分区方案
|
||||
| 分区 | 挂载点 | 大小 | 文件系统 | 说明 |
|
||||
|------|--------|------|----------|------|
|
||||
| EFI System | /boot/efi | 512MB - 1GB | FAT32 | 存储 UEFI 引导程序（必须） |
|
||||
| Root | / | 100GB - 200GB | ext4 | 系统文件、Docker、应用程序 |
|
||||
| Home | /home | 剩余空间 | ext4 | 独立分区，重装可保留数据 |
|
||||
| Swap | swap | 8GB - 32GB | swap | 根据内存大小，建议为内存 1 倍 |
|
||||
|
||||
## Key Alignment Rules
|
||||
- 分区起始扇区：默认 2048（与 NVMe 块大小对齐）
|
||||
- Ubuntu 24.04 自动应用最佳对齐
|
||||
- 分区方案：**GPT**（NVMe 2TB+ 支持必须）
|
||||
|
||||
## Why ext4 for NVMe
|
||||
虽然 Ubuntu 24.04 支持 ZFS/Btrfs 高级文件系统，但对 Docker 环境和 HP ZBook 来说，ext4 的兼容性、稳定性和性能预测性最优。
|
||||
|
||||
## Related
|
||||
- [[HP ZBook]] — 目标设备（NVMe 硬盘）
|
||||
- [[GPT分区表]] — 分区表方案
|
||||
- [[Ubuntu 24.04]] — 操作系统
|
||||
- [[NVMe硬盘分区]] ← 针对 [[HP ZBook]] ← [[GPT分区表]]
|
||||
|
||||
## Sources
|
||||
- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] — HP ZBook NVMe 分区方案（GPT/ext4/+swap/swap）
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]]
|
||||
---
|
||||
title: "NVMe硬盘分区"
|
||||
type: concept
|
||||
tags: [nvme, linux, partition, ubuntu]
|
||||
date: 2026-04-14
|
||||
aliases: [NVMe, NVMe SSD, PCIe SSD]
|
||||
---
|
||||
|
||||
# NVMe硬盘分区
|
||||
|
||||
## Definition
|
||||
针对 NVMe PCIe 固态硬盘的分区策略与对齐优化。Ubuntu 24.04 自动识别 ZBook 等设备上的 NVMe 硬盘并进行对齐优化，但仍建议手动分区时遵循标准规范。
|
||||
|
||||
## HP ZBook NVMe 分区方案
|
||||
| 分区 | 挂载点 | 大小 | 文件系统 | 说明 |
|
||||
|------|--------|------|----------|------|
|
||||
| EFI System | /boot/efi | 512MB - 1GB | FAT32 | 存储 UEFI 引导程序（必须） |
|
||||
| Root | / | 100GB - 200GB | ext4 | 系统文件、Docker、应用程序 |
|
||||
| Home | /home | 剩余空间 | ext4 | 独立分区，重装可保留数据 |
|
||||
| Swap | swap | 8GB - 32GB | swap | 根据内存大小，建议为内存 1 倍 |
|
||||
|
||||
## Key Alignment Rules
|
||||
- 分区起始扇区：默认 2048（与 NVMe 块大小对齐）
|
||||
- Ubuntu 24.04 自动应用最佳对齐
|
||||
- 分区方案：**GPT**（NVMe 2TB+ 支持必须）
|
||||
|
||||
## Why ext4 for NVMe
|
||||
虽然 Ubuntu 24.04 支持 ZFS/Btrfs 高级文件系统，但对 Docker 环境和 HP ZBook 来说，ext4 的兼容性、稳定性和性能预测性最优。
|
||||
|
||||
## Related
|
||||
- [[HP ZBook]] — 目标设备（NVMe 硬盘）
|
||||
- [[GPT分区表]] — 分区表方案
|
||||
- [[Ubuntu 24.04]] — 操作系统
|
||||
- [[NVMe硬盘分区]] ← 针对 [[HP ZBook]] ← [[GPT分区表]]
|
||||
|
||||
## Sources
|
||||
- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] — HP ZBook NVMe 分区方案（GPT/ext4/+swap/swap）
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]]
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "Observability"
|
||||
type: concept
|
||||
tags: [devops, monitoring, sre, infrastructure]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Observability（可观测性）
|
||||
|
||||
**中文名称：** 可观测性
|
||||
|
||||
**类型：** 技术方法论 / SRE 核心支柱
|
||||
|
||||
**别名：**
|
||||
- 可观测性
|
||||
- 云原生可观测性
|
||||
- Observability Stack
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
可观测性（Observability）是指通过系统外部输出来推断其内部状态的能力。在 IT 运维领域，通常由三大支柱构成：
|
||||
|
||||
1. **指标（Metrics）：** 系统运行时数值数据的时序聚合——如 CPU 使用率、内存占用、请求 QPS。代表工具：Prometheus、InfluxDB、VictoriaMetrics。
|
||||
2. **日志（Logs）：** 系统运行事件的离散记录——如错误日志、访问日志、业务事件。代表工具：ELK（Elasticsearch + Logstash + Kibana）、Loki、Graylog。
|
||||
3. **链路（Traces）：** 分布式请求在多个服务间的调用路径追踪——如 HTTP 请求从 API → DB → Cache 的完整耗时。代表工具：Jaeger、Zipkin、OpenTelemetry。
|
||||
|
||||
**第三支柱趋势：** OpenTelemetry（OTel）作为 CNCF 项目，正在成为可观测数据的统一采集标准，将 Traces、Metrics、Logs 三者以统一规范融合。
|
||||
|
||||
---
|
||||
|
||||
## 家庭监控场景下的应用
|
||||
|
||||
在家庭服务器/NAS 监控中，可观测性通过以下组件实现：
|
||||
- **指标：** Prometheus + node_exporter + cAdvisor + blackbox_exporter
|
||||
- **可视化：** Grafana 仪表盘
|
||||
- **告警：** Alertmanager + 邮件/Slack 通知
|
||||
- **日志（可选）：** Loki + Promtail
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
|
||||
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
---
|
||||
title: "Observability"
|
||||
type: concept
|
||||
tags: [devops, monitoring, sre, infrastructure]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Observability（可观测性）
|
||||
|
||||
**中文名称：** 可观测性
|
||||
|
||||
**类型：** 技术方法论 / SRE 核心支柱
|
||||
|
||||
**别名：**
|
||||
- 可观测性
|
||||
- 云原生可观测性
|
||||
- Observability Stack
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
可观测性（Observability）是指通过系统外部输出来推断其内部状态的能力。在 IT 运维领域，通常由三大支柱构成：
|
||||
|
||||
1. **指标（Metrics）：** 系统运行时数值数据的时序聚合——如 CPU 使用率、内存占用、请求 QPS。代表工具：Prometheus、InfluxDB、VictoriaMetrics。
|
||||
2. **日志（Logs）：** 系统运行事件的离散记录——如错误日志、访问日志、业务事件。代表工具：ELK（Elasticsearch + Logstash + Kibana）、Loki、Graylog。
|
||||
3. **链路（Traces）：** 分布式请求在多个服务间的调用路径追踪——如 HTTP 请求从 API → DB → Cache 的完整耗时。代表工具：Jaeger、Zipkin、OpenTelemetry。
|
||||
|
||||
**第三支柱趋势：** OpenTelemetry（OTel）作为 CNCF 项目，正在成为可观测数据的统一采集标准，将 Traces、Metrics、Logs 三者以统一规范融合。
|
||||
|
||||
---
|
||||
|
||||
## 家庭监控场景下的应用
|
||||
|
||||
在家庭服务器/NAS 监控中，可观测性通过以下组件实现：
|
||||
- **指标：** Prometheus + node_exporter + cAdvisor + blackbox_exporter
|
||||
- **可视化：** Grafana 仪表盘
|
||||
- **告警：** Alertmanager + 邮件/Slack 通知
|
||||
- **日志（可选）：** Loki + Promtail
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
|
||||
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
|
||||
@@ -1,53 +1,53 @@
|
||||
---
|
||||
title: "SAST"
|
||||
type: concept
|
||||
tags: [security, static-analysis, devsecops, sast]
|
||||
sources: ["what-is-devsecops-best-practices-benefits-and-tools"]
|
||||
last_updated: 2025-12-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
SAST（Static Application Security Testing，静态应用安全测试）是一种在不运行应用程序的情况下，通过分析源代码、字节码或二进制文件的结构和逻辑来发现安全漏洞的测试方法。
|
||||
|
||||
## Characteristics
|
||||
|
||||
- **白盒测试**：需要访问源代码
|
||||
- **编码阶段使用**：在开发人员编写代码时即时发现漏洞
|
||||
- **零运行时开销**：无需执行程序，不影响性能
|
||||
- **高覆盖率**：可扫描整个代码库，发现逻辑复杂的安全问题
|
||||
|
||||
## Capabilities
|
||||
|
||||
SAST 工具擅长发现以下类型的漏洞：
|
||||
- SQL 注入（SQL Injection）
|
||||
- 跨站脚本（XSS, Cross-Site Scripting）
|
||||
- 缓冲区溢出（Buffer Overflow）
|
||||
- 硬编码凭据
|
||||
- 不安全的直接对象引用
|
||||
- 缺少输入验证
|
||||
|
||||
## Limitations
|
||||
|
||||
- 误报率较高（可能报告非真实漏洞）
|
||||
- 无法发现运行时漏洞和配置问题
|
||||
- 对第三方库的分析能力有限（见 [[SCA]]）
|
||||
|
||||
## Typical Tools
|
||||
|
||||
- SonarQube
|
||||
- Checkmarx
|
||||
- Fortify
|
||||
- Semgrep
|
||||
- Bandit (Python)
|
||||
|
||||
## Relationship with DevSecOps
|
||||
|
||||
SAST 是 DevSecOps CI/CD 流水线的核心组成部分，通常在代码提交后自动触发，为开发人员提供即时反馈。属于 [[DevSecOps]] 工具链中的"左移"环节。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[DAST]] — 动态应用安全测试，与 SAST 互补
|
||||
- [[IAST]] — 交互式应用安全测试，运行时分析
|
||||
- [[SCA]] — 软件成分分析，扫描第三方依赖
|
||||
- [[Shift Left]] — 左移策略，SAST 是其核心实践
|
||||
---
|
||||
title: "SAST"
|
||||
type: concept
|
||||
tags: [security, static-analysis, devsecops, sast]
|
||||
sources: ["what-is-devsecops-best-practices-benefits-and-tools"]
|
||||
last_updated: 2025-12-19
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
SAST（Static Application Security Testing，静态应用安全测试）是一种在不运行应用程序的情况下，通过分析源代码、字节码或二进制文件的结构和逻辑来发现安全漏洞的测试方法。
|
||||
|
||||
## Characteristics
|
||||
|
||||
- **白盒测试**：需要访问源代码
|
||||
- **编码阶段使用**：在开发人员编写代码时即时发现漏洞
|
||||
- **零运行时开销**：无需执行程序，不影响性能
|
||||
- **高覆盖率**：可扫描整个代码库，发现逻辑复杂的安全问题
|
||||
|
||||
## Capabilities
|
||||
|
||||
SAST 工具擅长发现以下类型的漏洞：
|
||||
- SQL 注入（SQL Injection）
|
||||
- 跨站脚本（XSS, Cross-Site Scripting）
|
||||
- 缓冲区溢出（Buffer Overflow）
|
||||
- 硬编码凭据
|
||||
- 不安全的直接对象引用
|
||||
- 缺少输入验证
|
||||
|
||||
## Limitations
|
||||
|
||||
- 误报率较高（可能报告非真实漏洞）
|
||||
- 无法发现运行时漏洞和配置问题
|
||||
- 对第三方库的分析能力有限（见 [[SCA]]）
|
||||
|
||||
## Typical Tools
|
||||
|
||||
- SonarQube
|
||||
- Checkmarx
|
||||
- Fortify
|
||||
- Semgrep
|
||||
- Bandit (Python)
|
||||
|
||||
## Relationship with DevSecOps
|
||||
|
||||
SAST 是 DevSecOps CI/CD 流水线的核心组成部分，通常在代码提交后自动触发，为开发人员提供即时反馈。属于 [[DevSecOps]] 工具链中的"左移"环节。
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[DAST]] — 动态应用安全测试，与 SAST 互补
|
||||
- [[IAST]] — 交互式应用安全测试，运行时分析
|
||||
- [[SCA]] — 软件成分分析，扫描第三方依赖
|
||||
- [[Shift Left]] — 左移策略，SAST 是其核心实践
|
||||
|
||||
@@ -1,74 +1,74 @@
|
||||
# SOCKS5代理
|
||||
|
||||
> SOCKS5，本地科学上网代理协议，监听 127.0.0.1:10808，在 Mac Mini、Ubuntu1、Ubuntu2 上正常运行，NAS 上仅本机监听。
|
||||
|
||||
## Overview
|
||||
SOCKS5 代理是一种网络协议，通过 SOCKS 代理服务器转发客户端的网络请求，支持 TCP 和 UDP。本方案中各节点通过 v2rayA 或类似代理客户端在本地启动 SOCKS5 代理服务，供本机应用走科学上网通道。
|
||||
|
||||
## Node Status
|
||||
|
||||
|| 节点 | IP | 端口 | 状态 | FRP 暴露 |
|
||||
|------|-----|-----|------|----------|
|
||||
| Mac Mini M4 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Ubuntu Server 1 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Ubuntu Server 2 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Synology NAS | 127.0.0.1 | 20170 | ❌ 仅本机监听 | 否 |
|
||||
|
||||
## Usage Patterns
|
||||
|
||||
### 终端命令级（ProxyChains）
|
||||
ProxyChains 通过 LD_PRELOAD 劫持 socket 调用，强制任意终端命令走 SOCKS5 代理：
|
||||
```bash
|
||||
# /etc/proxychains4.conf
|
||||
socks5 127.0.0.1 10808
|
||||
|
||||
# 使用
|
||||
proxychains4 curl https://google.com
|
||||
```
|
||||
|
||||
### Git 全局代理
|
||||
Git 不读取系统环境变量，必须显式配置：
|
||||
```bash
|
||||
git config --global http.proxy socks5://127.0.0.1:10808
|
||||
git config --global https.proxy socks5://127.0.0.1:10808
|
||||
```
|
||||
|
||||
### Docker Daemon 代理
|
||||
通过 systemd drop-in 文件注入环境变量：
|
||||
```bash
|
||||
# /etc/systemd/system/docker.service.d/http-proxy.conf
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=socks5://127.0.0.1:10808"
|
||||
Environment="HTTPS_PROXY=socks5://127.0.0.1:10808"
|
||||
```
|
||||
|
||||
### Docker 容器环境变量
|
||||
```bash
|
||||
# 容器内使用 ALL_PROXY 环境变量
|
||||
docker run -e ALL_PROXY=socks5://172.24.0.1:10808 ...
|
||||
```
|
||||
|
||||
## Key Distinction: socks5 vs socks5h
|
||||
- **socks5**：DNS 解析在本地完成，可能 DNS 污染
|
||||
- **socks5h**：DNS 解析由代理服务器完成，防止本地 DNS 污染
|
||||
```bash
|
||||
curl -x socks5h://127.0.0.1:10808 https://google.com
|
||||
```
|
||||
|
||||
## Docker 网络网关 IP
|
||||
Docker 容器内访问宿主机的 IP 不是 127.0.0.1（那是容器自身），而是 Docker 网络网关 IP：
|
||||
- bridge 网络默认：`172.17.0.1`
|
||||
- 自定义网络（如 compose 项目）：`172.24.0.1`
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 通过 iptables 劫持系统出站流量
|
||||
- [[环境变量代理]] — HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量
|
||||
- [[Docker-Daemon-Proxy]] — systemd drop-in 方式为 docker pull 配置代理
|
||||
- [[ProxyChains]] — 终端命令级流量劫持工具
|
||||
- [[Git 全局代理]] — Git 专用代理配置
|
||||
|
||||
## Related Entities
|
||||
- [[v2rayA]] — NAS 上的 SOCKS5 代理来源（端口20170）
|
||||
- [[Mac Mini M4]] — SOCKS5 代理节点之一
|
||||
- [[Ubuntu Server]] — SOCKS5 代理节点
|
||||
- [[Synology NAS DS718]] — v2rayA 部署位置（仅本机监听）
|
||||
# SOCKS5代理
|
||||
|
||||
> SOCKS5，本地科学上网代理协议，监听 127.0.0.1:10808，在 Mac Mini、Ubuntu1、Ubuntu2 上正常运行，NAS 上仅本机监听。
|
||||
|
||||
## Overview
|
||||
SOCKS5 代理是一种网络协议，通过 SOCKS 代理服务器转发客户端的网络请求，支持 TCP 和 UDP。本方案中各节点通过 v2rayA 或类似代理客户端在本地启动 SOCKS5 代理服务，供本机应用走科学上网通道。
|
||||
|
||||
## Node Status
|
||||
|
||||
|| 节点 | IP | 端口 | 状态 | FRP 暴露 |
|
||||
|------|-----|-----|------|----------|
|
||||
| Mac Mini M4 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Ubuntu Server 1 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Ubuntu Server 2 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Synology NAS | 127.0.0.1 | 20170 | ❌ 仅本机监听 | 否 |
|
||||
|
||||
## Usage Patterns
|
||||
|
||||
### 终端命令级（ProxyChains）
|
||||
ProxyChains 通过 LD_PRELOAD 劫持 socket 调用，强制任意终端命令走 SOCKS5 代理：
|
||||
```bash
|
||||
# /etc/proxychains4.conf
|
||||
socks5 127.0.0.1 10808
|
||||
|
||||
# 使用
|
||||
proxychains4 curl https://google.com
|
||||
```
|
||||
|
||||
### Git 全局代理
|
||||
Git 不读取系统环境变量，必须显式配置：
|
||||
```bash
|
||||
git config --global http.proxy socks5://127.0.0.1:10808
|
||||
git config --global https.proxy socks5://127.0.0.1:10808
|
||||
```
|
||||
|
||||
### Docker Daemon 代理
|
||||
通过 systemd drop-in 文件注入环境变量：
|
||||
```bash
|
||||
# /etc/systemd/system/docker.service.d/http-proxy.conf
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=socks5://127.0.0.1:10808"
|
||||
Environment="HTTPS_PROXY=socks5://127.0.0.1:10808"
|
||||
```
|
||||
|
||||
### Docker 容器环境变量
|
||||
```bash
|
||||
# 容器内使用 ALL_PROXY 环境变量
|
||||
docker run -e ALL_PROXY=socks5://172.24.0.1:10808 ...
|
||||
```
|
||||
|
||||
## Key Distinction: socks5 vs socks5h
|
||||
- **socks5**：DNS 解析在本地完成，可能 DNS 污染
|
||||
- **socks5h**：DNS 解析由代理服务器完成，防止本地 DNS 污染
|
||||
```bash
|
||||
curl -x socks5h://127.0.0.1:10808 https://google.com
|
||||
```
|
||||
|
||||
## Docker 网络网关 IP
|
||||
Docker 容器内访问宿主机的 IP 不是 127.0.0.1（那是容器自身），而是 Docker 网络网关 IP：
|
||||
- bridge 网络默认：`172.17.0.1`
|
||||
- 自定义网络（如 compose 项目）：`172.24.0.1`
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 通过 iptables 劫持系统出站流量
|
||||
- [[环境变量代理]] — HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量
|
||||
- [[Docker-Daemon-Proxy]] — systemd drop-in 方式为 docker pull 配置代理
|
||||
- [[ProxyChains]] — 终端命令级流量劫持工具
|
||||
- [[Git 全局代理]] — Git 专用代理配置
|
||||
|
||||
## Related Entities
|
||||
- [[v2rayA]] — NAS 上的 SOCKS5 代理来源（端口20170）
|
||||
- [[Mac Mini M4]] — SOCKS5 代理节点之一
|
||||
- [[Ubuntu Server]] — SOCKS5 代理节点
|
||||
- [[Synology NAS DS718]] — v2rayA 部署位置（仅本机监听）
|
||||
|
||||
@@ -1,32 +1,32 @@
|
||||
---
|
||||
title: "SemanticRouting"
|
||||
type: concept
|
||||
tags: ["routing", "llm-ops", "intelligent-routing"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Semantic Routing
|
||||
- 语义路由
|
||||
- Intent Routing
|
||||
- Task-Aware Routing
|
||||
|
||||
## Definition
|
||||
语义路由是 [[AutonomousOptimizationArchitect]] 的决策核心——根据任务类型、历史性能评分和当前 Provider 状态，动态选择最优的 LLM Provider。Provider 按"优化分数"（Speed + Cost + Accuracy 综合排名）排序，优先尝试排名最高的可用 Provider。
|
||||
|
||||
## Mechanism
|
||||
1. **任务分析**：理解用户请求的类型和复杂度（如代码生成 vs. 闲聊）
|
||||
2. **Provider 排名**：按历史优化分数对所有 Provider 排序
|
||||
3. **动态选择**：从最高排名 Provider 开始尝试，直到找到可用且在成本限制内的 Provider
|
||||
4. **持续学习**：[[LLMasJudge]] 评分结果更新各 Provider 在特定任务类型上的排名
|
||||
|
||||
## Key Properties
|
||||
- **成本感知**：始终追踪每百万 Token 成本，优先使用低成本模型
|
||||
- **性能自适应**：根据 [[ShadowTraffic]] 数据动态调整排名
|
||||
- **故障感知**：熔断器切断的 Provider 自动跳过
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — 语义路由是核心路由决策逻辑
|
||||
- [[CircuitBreaker]] — 提供故障感知的 Provider 过滤
|
||||
- [[LLMasJudge]] — 提供更新路由权重的数据
|
||||
---
|
||||
title: "SemanticRouting"
|
||||
type: concept
|
||||
tags: ["routing", "llm-ops", "intelligent-routing"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Semantic Routing
|
||||
- 语义路由
|
||||
- Intent Routing
|
||||
- Task-Aware Routing
|
||||
|
||||
## Definition
|
||||
语义路由是 [[AutonomousOptimizationArchitect]] 的决策核心——根据任务类型、历史性能评分和当前 Provider 状态，动态选择最优的 LLM Provider。Provider 按"优化分数"（Speed + Cost + Accuracy 综合排名）排序，优先尝试排名最高的可用 Provider。
|
||||
|
||||
## Mechanism
|
||||
1. **任务分析**：理解用户请求的类型和复杂度（如代码生成 vs. 闲聊）
|
||||
2. **Provider 排名**：按历史优化分数对所有 Provider 排序
|
||||
3. **动态选择**：从最高排名 Provider 开始尝试，直到找到可用且在成本限制内的 Provider
|
||||
4. **持续学习**：[[LLMasJudge]] 评分结果更新各 Provider 在特定任务类型上的排名
|
||||
|
||||
## Key Properties
|
||||
- **成本感知**：始终追踪每百万 Token 成本，优先使用低成本模型
|
||||
- **性能自适应**：根据 [[ShadowTraffic]] 数据动态调整排名
|
||||
- **故障感知**：熔断器切断的 Provider 自动跳过
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — 语义路由是核心路由决策逻辑
|
||||
- [[CircuitBreaker]] — 提供故障感知的 Provider 过滤
|
||||
- [[LLMasJudge]] — 提供更新路由权重的数据
|
||||
|
||||
@@ -1,32 +1,32 @@
|
||||
---
|
||||
title: "ShadowTraffic"
|
||||
type: concept
|
||||
tags: ["testing", "a-b-testing", "dark-launch"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Shadow Traffic
|
||||
- 影子流量
|
||||
- Shadow Testing
|
||||
- 暗测试
|
||||
|
||||
## Definition
|
||||
影子流量是 [[AutonomousOptimizationArchitect]] 的核心测试机制——将一小部分真实用户请求（通常 5%）异步复制到实验模型，与生产模型并行执行，但不返回给用户。实验结果通过 [[LLMasJudge]] 自动评分，用于决定是否将实验模型提升为生产模型。
|
||||
|
||||
## Mechanism
|
||||
1. **流量复制**：用户请求同时发送至生产模型和实验模型
|
||||
2. **异步评估**：实验模型结果不阻塞用户响应，通过 [[LLMasJudge]] 异步评分
|
||||
3. **统计分析**：累积 N 次（如 1000 次）执行后评估性能差距
|
||||
4. **自主升级**：实验模型统计显著优于基准时，自动更新路由权重
|
||||
|
||||
## Key Properties
|
||||
- **零用户影响**：实验在后台进行，用户永远获得生产模型响应
|
||||
- **真实数据**：使用真实用户请求，而非人工构造的测试用例
|
||||
- **持续运行**：可 24/7 不间断运行，持续监控新模型发布
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — 影子流量是核心测试基础设施
|
||||
- [[LLMasJudge]] — 对影子流量结果进行自动评分
|
||||
- [[DarkLaunching]] — 影子流量是暗启动的测试阶段
|
||||
---
|
||||
title: "ShadowTraffic"
|
||||
type: concept
|
||||
tags: ["testing", "a-b-testing", "dark-launch"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Shadow Traffic
|
||||
- 影子流量
|
||||
- Shadow Testing
|
||||
- 暗测试
|
||||
|
||||
## Definition
|
||||
影子流量是 [[AutonomousOptimizationArchitect]] 的核心测试机制——将一小部分真实用户请求（通常 5%）异步复制到实验模型，与生产模型并行执行，但不返回给用户。实验结果通过 [[LLMasJudge]] 自动评分，用于决定是否将实验模型提升为生产模型。
|
||||
|
||||
## Mechanism
|
||||
1. **流量复制**：用户请求同时发送至生产模型和实验模型
|
||||
2. **异步评估**：实验模型结果不阻塞用户响应，通过 [[LLMasJudge]] 异步评分
|
||||
3. **统计分析**：累积 N 次（如 1000 次）执行后评估性能差距
|
||||
4. **自主升级**：实验模型统计显著优于基准时，自动更新路由权重
|
||||
|
||||
## Key Properties
|
||||
- **零用户影响**：实验在后台进行，用户永远获得生产模型响应
|
||||
- **真实数据**：使用真实用户请求，而非人工构造的测试用例
|
||||
- **持续运行**：可 24/7 不间断运行，持续监控新模型发布
|
||||
|
||||
## Connections
|
||||
- [[AutonomousOptimizationArchitect]] — 影子流量是核心测试基础设施
|
||||
- [[LLMasJudge]] — 对影子流量结果进行自动评分
|
||||
- [[DarkLaunching]] — 影子流量是暗启动的测试阶段
|
||||
|
||||
@@ -1,45 +1,45 @@
|
||||
---
|
||||
title: "SymbolicLink"
|
||||
type: concept
|
||||
tags: [filesystem, macos, linux, unix]
|
||||
sources: [macos-创建与解除-symbolic-link-openclaw-目录映射]
|
||||
last_updated:
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Symbolic Link（符号链接，简称 Symlink）是 Unix/Linux/macOS 文件系统中的一种特殊类型文件，它指向另一个文件或目录的路径。访问符号链接时，系统会自动重定向到目标路径。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
```
|
||||
~/openclaw -> ~/.openclaw
|
||||
```
|
||||
|
||||
符号链接本身只存储目标路径字符串（轻量），不存储实际文件内容。删除符号链接不会影响目标文件/目录。
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
| 场景 | 命令 |
|
||||
|------|------|
|
||||
| 创建目录符号链接 | `ln -s /path/to/target /path/to/link` |
|
||||
| 删除符号链接 | `rm /path/to/link` |
|
||||
| 验证链接存在 | `ls -l ~ \| grep linkname` |
|
||||
| 查看链接目标 | `readlink /path/to/link` |
|
||||
|
||||
## Key Properties
|
||||
|
||||
- **非复制**：符号链接不复制数据，只存储路径引用
|
||||
- **可跨文件系统**：可以指向任意位置的文件或目录
|
||||
- **可链接目录**：目录也可以创建符号链接
|
||||
- **透明访问**：应用程序访问符号链接时无感知重定向
|
||||
- **危险操作**：`rm -rf` 指向目录的符号链接会删除目标数据（注意区分）
|
||||
|
||||
## Relationship to Related Concepts
|
||||
|
||||
- [[目录映射]]：符号链接是实现目录映射的常用手段
|
||||
- [[软链接策略]]：（如存在）符号链接的应用策略层
|
||||
- [[ObsidianVault]]：Obsidian 可通过符号链接访问非标准位置的笔记目录
|
||||
|
||||
## Related Entities
|
||||
- [[OpenClaw]]：通过符号链接将隐藏目录 `~/.openclaw` 映射为可见目录 `~/openclaw`
|
||||
---
|
||||
title: "SymbolicLink"
|
||||
type: concept
|
||||
tags: [filesystem, macos, linux, unix]
|
||||
sources: [macos-创建与解除-symbolic-link-openclaw-目录映射]
|
||||
last_updated:
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Symbolic Link（符号链接，简称 Symlink）是 Unix/Linux/macOS 文件系统中的一种特殊类型文件，它指向另一个文件或目录的路径。访问符号链接时，系统会自动重定向到目标路径。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
```
|
||||
~/openclaw -> ~/.openclaw
|
||||
```
|
||||
|
||||
符号链接本身只存储目标路径字符串（轻量），不存储实际文件内容。删除符号链接不会影响目标文件/目录。
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
| 场景 | 命令 |
|
||||
|------|------|
|
||||
| 创建目录符号链接 | `ln -s /path/to/target /path/to/link` |
|
||||
| 删除符号链接 | `rm /path/to/link` |
|
||||
| 验证链接存在 | `ls -l ~ \| grep linkname` |
|
||||
| 查看链接目标 | `readlink /path/to/link` |
|
||||
|
||||
## Key Properties
|
||||
|
||||
- **非复制**：符号链接不复制数据，只存储路径引用
|
||||
- **可跨文件系统**：可以指向任意位置的文件或目录
|
||||
- **可链接目录**：目录也可以创建符号链接
|
||||
- **透明访问**：应用程序访问符号链接时无感知重定向
|
||||
- **危险操作**：`rm -rf` 指向目录的符号链接会删除目标数据（注意区分）
|
||||
|
||||
## Relationship to Related Concepts
|
||||
|
||||
- [[目录映射]]：符号链接是实现目录映射的常用手段
|
||||
- [[软链接策略]]：（如存在）符号链接的应用策略层
|
||||
- [[ObsidianVault]]：Obsidian 可通过符号链接访问非标准位置的笔记目录
|
||||
|
||||
## Related Entities
|
||||
- [[OpenClaw]]：通过符号链接将隐藏目录 `~/.openclaw` 映射为可见目录 `~/openclaw`
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: "Synthetic Monitoring"
|
||||
type: concept
|
||||
tags: [monitoring, devops, uptime, availability]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Synthetic Monitoring（合成监控）
|
||||
|
||||
**中文名称：** 合成监控 / 主动式可用性监控
|
||||
|
||||
**类型：** 监控方法论
|
||||
|
||||
**别名：**
|
||||
- 合成监控
|
||||
- 主动监控
|
||||
- Blackbox Monitoring
|
||||
- Uptime Monitoring
|
||||
- Ping Monitoring
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
合成监控（Synthetic Monitoring）是通过**主动发起模拟请求**（HTTP/DNS/TCP/ICMP）来探测服务端点可用性、响应时间和功能正确性的监控方式，与之对应的是基于真实用户流量的 RUM（Real User Monitoring）。
|
||||
|
||||
**核心特点：**
|
||||
- 不依赖真实用户流量，可在服务上线前发现问题
|
||||
- 覆盖内网/外网所有端点
|
||||
- 支持 TLS 证书到期监控
|
||||
- DNS 解析可用性验证
|
||||
- 细粒度延迟和状态码追踪
|
||||
|
||||
**代表工具：**
|
||||
- **Blackbox Exporter（Prometheus 生态）：** 探测指标暴露到 Prometheus，支持 PromQL 告警规则集成
|
||||
- **Uptime Kuma：** 开源自托管 uptime monitoring，支持 HTTP/TCP/DNS/TLS，历史记录 + 告警通知
|
||||
|
||||
---
|
||||
|
||||
## 与 Real User Monitoring 的区别
|
||||
|
||||
| 维度 | 合成监控 | 真实用户监控 (RUM) |
|
||||
|------|---------|-----------------|
|
||||
| 数据来源 | 模拟探针主动探测 | 真实用户请求 |
|
||||
| 覆盖范围 | 全部端点（含无流量路径） | 仅被访问的路径 |
|
||||
| 时机 | 可在部署前发现问题 | 依赖真实流量触发 |
|
||||
| 适用场景 | 可用性 SLA 保障 | 真实用户体验感知 |
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
---
|
||||
title: "Synthetic Monitoring"
|
||||
type: concept
|
||||
tags: [monitoring, devops, uptime, availability]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Synthetic Monitoring（合成监控）
|
||||
|
||||
**中文名称：** 合成监控 / 主动式可用性监控
|
||||
|
||||
**类型：** 监控方法论
|
||||
|
||||
**别名：**
|
||||
- 合成监控
|
||||
- 主动监控
|
||||
- Blackbox Monitoring
|
||||
- Uptime Monitoring
|
||||
- Ping Monitoring
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
合成监控（Synthetic Monitoring）是通过**主动发起模拟请求**（HTTP/DNS/TCP/ICMP）来探测服务端点可用性、响应时间和功能正确性的监控方式，与之对应的是基于真实用户流量的 RUM（Real User Monitoring）。
|
||||
|
||||
**核心特点：**
|
||||
- 不依赖真实用户流量，可在服务上线前发现问题
|
||||
- 覆盖内网/外网所有端点
|
||||
- 支持 TLS 证书到期监控
|
||||
- DNS 解析可用性验证
|
||||
- 细粒度延迟和状态码追踪
|
||||
|
||||
**代表工具：**
|
||||
- **Blackbox Exporter（Prometheus 生态）：** 探测指标暴露到 Prometheus，支持 PromQL 告警规则集成
|
||||
- **Uptime Kuma：** 开源自托管 uptime monitoring，支持 HTTP/TCP/DNS/TLS，历史记录 + 告警通知
|
||||
|
||||
---
|
||||
|
||||
## 与 Real User Monitoring 的区别
|
||||
|
||||
| 维度 | 合成监控 | 真实用户监控 (RUM) |
|
||||
|------|---------|-----------------|
|
||||
| 数据来源 | 模拟探针主动探测 | 真实用户请求 |
|
||||
| 覆盖范围 | 全部端点（含无流量路径） | 仅被访问的路径 |
|
||||
| 时机 | 可在部署前发现问题 | 依赖真实流量触发 |
|
||||
| 适用场景 | 可用性 SLA 保障 | 真实用户体验感知 |
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "TCP隧道"
|
||||
type: concept
|
||||
tags: [networking, tunnel, tcp, ssh, frp]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- TCP Tunnel
|
||||
- TCP 隧道
|
||||
|
||||
## Definition
|
||||
TCP 隧道（TCP Tunnel）是一种通过已建立的连接传输 TCP 数据包的技术，允许将本地 TCP 端口的流量通过隧道传输到远程位置。常见实现方式包括 SSH 隧道（`ssh -L` / `ssh -R`）和 frp 的 TCP 类型映射。TCP 隧道与 HTTP 代理不同，它传输的是原始 TCP 数据，不解析应用层协议。
|
||||
|
||||
## SSH 隧道
|
||||
```bash
|
||||
# 本地端口转发（Local Port Forwarding）：将远程端口映射到本地
|
||||
ssh -L local_port:remote_host:remote_port user@gateway
|
||||
|
||||
# 反向端口转发（Reverse Port Forwarding）：将本地端口映射到远程
|
||||
ssh -R remote_port:local_host:local_port user@gateway
|
||||
```
|
||||
|
||||
### SSH 反向隧道限制
|
||||
- 需要保持 SSH 连接持续活跃（可用 `autossh` 自动重连）
|
||||
- 不适合多客户端并发访问
|
||||
- 无 Web 管理界面
|
||||
- 不支持 UDP
|
||||
|
||||
## frp TCP 隧道
|
||||
详见 [[frp]]
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：
|
||||
- frp TCP 映射 NAS 端口（5000→15000）
|
||||
- frp TCP 映射 Ubuntu 端口（5678→15678, 9091→19091, 3000→13000）
|
||||
- frp TCP 映射 SSH（22→60022）
|
||||
- SSH 穿透不走 Caddy（纯 TCP），Caddy 只处理 HTTP/HTTPS
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：TCP 隧道是内网穿透的底层实现机制
|
||||
- [[反向代理]]：HTTP/HTTPS 流量在 TCP 隧道之上还需要反向代理层（Caddy）
|
||||
- [[frp]]：frp 支持 TCP/UDP/HTTP/WebSocket 等多种隧道类型
|
||||
|
||||
## References
|
||||
- SSH tunneling: `man ssh`（搜索 "SSH_PORT_FORWARDING" 或 "-L/-R"）
|
||||
- frp TCP 类型: https://github.com/fatedier/frp#configuration
|
||||
---
|
||||
title: "TCP隧道"
|
||||
type: concept
|
||||
tags: [networking, tunnel, tcp, ssh, frp]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- TCP Tunnel
|
||||
- TCP 隧道
|
||||
|
||||
## Definition
|
||||
TCP 隧道（TCP Tunnel）是一种通过已建立的连接传输 TCP 数据包的技术，允许将本地 TCP 端口的流量通过隧道传输到远程位置。常见实现方式包括 SSH 隧道（`ssh -L` / `ssh -R`）和 frp 的 TCP 类型映射。TCP 隧道与 HTTP 代理不同，它传输的是原始 TCP 数据，不解析应用层协议。
|
||||
|
||||
## SSH 隧道
|
||||
```bash
|
||||
# 本地端口转发（Local Port Forwarding）：将远程端口映射到本地
|
||||
ssh -L local_port:remote_host:remote_port user@gateway
|
||||
|
||||
# 反向端口转发（Reverse Port Forwarding）：将本地端口映射到远程
|
||||
ssh -R remote_port:local_host:local_port user@gateway
|
||||
```
|
||||
|
||||
### SSH 反向隧道限制
|
||||
- 需要保持 SSH 连接持续活跃（可用 `autossh` 自动重连）
|
||||
- 不适合多客户端并发访问
|
||||
- 无 Web 管理界面
|
||||
- 不支持 UDP
|
||||
|
||||
## frp TCP 隧道
|
||||
详见 [[frp]]
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：
|
||||
- frp TCP 映射 NAS 端口（5000→15000）
|
||||
- frp TCP 映射 Ubuntu 端口（5678→15678, 9091→19091, 3000→13000）
|
||||
- frp TCP 映射 SSH（22→60022）
|
||||
- SSH 穿透不走 Caddy（纯 TCP），Caddy 只处理 HTTP/HTTPS
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：TCP 隧道是内网穿透的底层实现机制
|
||||
- [[反向代理]]：HTTP/HTTPS 流量在 TCP 隧道之上还需要反向代理层（Caddy）
|
||||
- [[frp]]：frp 支持 TCP/UDP/HTTP/WebSocket 等多种隧道类型
|
||||
|
||||
## References
|
||||
- SSH tunneling: `man ssh`（搜索 "SSH_PORT_FORWARDING" 或 "-L/-R"）
|
||||
- frp TCP 类型: https://github.com/fatedier/frp#configuration
|
||||
|
||||
@@ -1,68 +1,68 @@
|
||||
---
|
||||
title: "Zero Trust Architecture (ZTA)"
|
||||
type: concept
|
||||
tags: [security, cloud, compliance]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2025-03-01
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
零信任架构（Zero Trust Architecture）是一种安全框架，其核心原则是**"永不信任，始终验证"**（Never Trust, Always Verify）。与传统的边界安全模型不同，ZTA假设网络内部和外部都不可信，每个访问请求都必须经过验证。
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. Never Trust, Always Verify
|
||||
```
|
||||
传统模型: 边界内 = 可信
|
||||
ZTA模型: 无论位置，均需验证
|
||||
```
|
||||
|
||||
### 2. Least Privilege Access
|
||||
- 仅授予完成任务所需的最小权限
|
||||
- 细粒度访问控制
|
||||
- Just-in-Time (JIT) 访问
|
||||
|
||||
### 3. Assume Breach
|
||||
- 假设系统已被攻破
|
||||
- 持续监控和检测
|
||||
- 微分段隔离
|
||||
|
||||
## Implementation Pillars
|
||||
|
||||
| 支柱 | 描述 | 技术示例 |
|
||||
|------|------|---------|
|
||||
| 身份认证 | 强身份验证 | MFA, SSO |
|
||||
| 设备健康 | 终端安全状态 | MDM, EDR |
|
||||
| 网络分段 | 微隔离 | VPC, Service Mesh |
|
||||
| 应用控制 | 最小权限 | RBAC, ABAC |
|
||||
| 数据加密 | 传输和静态加密 | TLS, KMS |
|
||||
|
||||
## In ITSM Context
|
||||
|
||||
在[[ITSM]]中，ZTA是[[Security-and-Compliance]]的核心：
|
||||
|
||||
```
|
||||
Security & Compliance Management (ITSM 8.0)
|
||||
├── Zero Trust Architecture (ZTA)
|
||||
│ ├── 持续身份验证
|
||||
│ ├── 微分段隔离
|
||||
│ └── 最小权限原则
|
||||
├── AI-based Threat Intelligence
|
||||
│ ├── 行为分析
|
||||
│ └── 异常检测
|
||||
└── Policy-as-Code
|
||||
├── 合规自动化
|
||||
└── 审计追踪
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Policy-as-Code]] — 策略即代码，合规自动化
|
||||
- [[Security-and-Compliance]] — 安全与合规管理
|
||||
- [[Multi-factor-Authentication]] — 多因素认证
|
||||
- [[Cloud Security]] — 云安全
|
||||
|
||||
## Sources
|
||||
|
||||
- [[understanding-complete-itsm]] — ZTA在现代ITSM中的应用
|
||||
---
|
||||
title: "Zero Trust Architecture (ZTA)"
|
||||
type: concept
|
||||
tags: [security, cloud, compliance]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
date: 2025-03-01
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
零信任架构（Zero Trust Architecture）是一种安全框架，其核心原则是**"永不信任，始终验证"**（Never Trust, Always Verify）。与传统的边界安全模型不同，ZTA假设网络内部和外部都不可信，每个访问请求都必须经过验证。
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. Never Trust, Always Verify
|
||||
```
|
||||
传统模型: 边界内 = 可信
|
||||
ZTA模型: 无论位置，均需验证
|
||||
```
|
||||
|
||||
### 2. Least Privilege Access
|
||||
- 仅授予完成任务所需的最小权限
|
||||
- 细粒度访问控制
|
||||
- Just-in-Time (JIT) 访问
|
||||
|
||||
### 3. Assume Breach
|
||||
- 假设系统已被攻破
|
||||
- 持续监控和检测
|
||||
- 微分段隔离
|
||||
|
||||
## Implementation Pillars
|
||||
|
||||
| 支柱 | 描述 | 技术示例 |
|
||||
|------|------|---------|
|
||||
| 身份认证 | 强身份验证 | MFA, SSO |
|
||||
| 设备健康 | 终端安全状态 | MDM, EDR |
|
||||
| 网络分段 | 微隔离 | VPC, Service Mesh |
|
||||
| 应用控制 | 最小权限 | RBAC, ABAC |
|
||||
| 数据加密 | 传输和静态加密 | TLS, KMS |
|
||||
|
||||
## In ITSM Context
|
||||
|
||||
在[[ITSM]]中，ZTA是[[Security-and-Compliance]]的核心：
|
||||
|
||||
```
|
||||
Security & Compliance Management (ITSM 8.0)
|
||||
├── Zero Trust Architecture (ZTA)
|
||||
│ ├── 持续身份验证
|
||||
│ ├── 微分段隔离
|
||||
│ └── 最小权限原则
|
||||
├── AI-based Threat Intelligence
|
||||
│ ├── 行为分析
|
||||
│ └── 异常检测
|
||||
└── Policy-as-Code
|
||||
├── 合规自动化
|
||||
└── 审计追踪
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Policy-as-Code]] — 策略即代码，合规自动化
|
||||
- [[Security-and-Compliance]] — 安全与合规管理
|
||||
- [[Multi-factor-Authentication]] — 多因素认证
|
||||
- [[Cloud Security]] — 云安全
|
||||
|
||||
## Sources
|
||||
|
||||
- [[understanding-complete-itsm]] — ZTA在现代ITSM中的应用
|
||||
|
||||
@@ -1,35 +1,35 @@
|
||||
---
|
||||
title: "Zero-Trust"
|
||||
type: concept
|
||||
tags: [security, identity, authorization]
|
||||
sources: [agentic-identity-trust.md, cloud-operating-model-key-strategies-and-best-practices]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Zero-Trust 是一种安全架构范式——**永不信任，必须验证**（Never Trust, Always Verify）。在多 Agent 系统中，该原则要求每个 Agent 在执行操作前必须提供密码学可验证的身份证明，而非依赖自我声明。
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **身份与授权分离**：证明"我是谁"（身份验证）与证明"我被允许做这个"（授权验证）是两个独立步骤。
|
||||
- **最小权限原则**：Agent 仅被授予完成特定任务所需的最小权限范围。
|
||||
- **假设已失陷**：设计时假设网络中至少有一个 Agent 已失陷或被错误配置。
|
||||
- **显式验证**：每次交互都必须进行验证，不能依赖先前交互的信任状态。
|
||||
|
||||
## Application in Multi-Agent Systems
|
||||
|
||||
| 层面 | Zero-Trust 要求 |
|
||||
|------|----------------|
|
||||
| 身份验证 | Agent 必须提供密码学签名证明，而非声称身份 |
|
||||
| 授权验证 | 必须提供可验证的委托链，而非声称"我被授权了" |
|
||||
| 日志完整性 | 日志写入者不得同时具备修改日志的能力 |
|
||||
| 跨框架互操作 | 每个框架的信任模型必须可被其他框架独立验证 |
|
||||
|
||||
## Relationships
|
||||
- [[Evidence-Chain]]：Zero-Trust 日志层的实现机制
|
||||
- [[Trust-Scoring]]：Zero-Trust 信任评估的量化手段
|
||||
- [[Fail-Closed]]：Zero-Trust 失败时的默认行为
|
||||
|
||||
## Sources
|
||||
- [[agentic-identity-trust.md]]
|
||||
---
|
||||
title: "Zero-Trust"
|
||||
type: concept
|
||||
tags: [security, identity, authorization]
|
||||
sources: [agentic-identity-trust.md, cloud-operating-model-key-strategies-and-best-practices]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Zero-Trust 是一种安全架构范式——**永不信任，必须验证**（Never Trust, Always Verify）。在多 Agent 系统中，该原则要求每个 Agent 在执行操作前必须提供密码学可验证的身份证明，而非依赖自我声明。
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **身份与授权分离**：证明"我是谁"（身份验证）与证明"我被允许做这个"（授权验证）是两个独立步骤。
|
||||
- **最小权限原则**：Agent 仅被授予完成特定任务所需的最小权限范围。
|
||||
- **假设已失陷**：设计时假设网络中至少有一个 Agent 已失陷或被错误配置。
|
||||
- **显式验证**：每次交互都必须进行验证，不能依赖先前交互的信任状态。
|
||||
|
||||
## Application in Multi-Agent Systems
|
||||
|
||||
| 层面 | Zero-Trust 要求 |
|
||||
|------|----------------|
|
||||
| 身份验证 | Agent 必须提供密码学签名证明，而非声称身份 |
|
||||
| 授权验证 | 必须提供可验证的委托链，而非声称"我被授权了" |
|
||||
| 日志完整性 | 日志写入者不得同时具备修改日志的能力 |
|
||||
| 跨框架互操作 | 每个框架的信任模型必须可被其他框架独立验证 |
|
||||
|
||||
## Relationships
|
||||
- [[Evidence-Chain]]：Zero-Trust 日志层的实现机制
|
||||
- [[Trust-Scoring]]：Zero-Trust 信任评估的量化手段
|
||||
- [[Fail-Closed]]：Zero-Trust 失败时的默认行为
|
||||
|
||||
## Sources
|
||||
- [[agentic-identity-trust.md]]
|
||||
|
||||
@@ -1,98 +1,98 @@
|
||||
---
|
||||
title: "frp"
|
||||
type: concept
|
||||
tags: [networking, open-source, golang, tunneling, self-hosted]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Fast Reverse Proxy
|
||||
- fatedier/frp
|
||||
- frps
|
||||
- frpc
|
||||
|
||||
## Definition
|
||||
frp（Fast Reverse Proxy）是一款开源的高性能内网穿透工具，由 Go 语言编写，通过客户端-服务端架构建立反向隧道，使处于 NAT 或防火墙后的内网服务可以被公网访问。包含两个核心组件：frps（服务端，运行在公网 VPS）和 frpc（客户端，运行在内网设备）。
|
||||
|
||||
## Core Architecture
|
||||
```
|
||||
公网用户 → VPS:7000(frps) ←——— 反向隧道 ←——— frpc(内网设备)
|
||||
```
|
||||
|
||||
## Key Components
|
||||
- **frps**（frp server）：运行在公网 VPS，监听 7000 端口（默认），接收 frpc 连接，管理端口映射
|
||||
- **frpc**（frp client）：运行在内网设备，主动连接 frps，建立反向隧道
|
||||
- **frps.ini / frps.toml**：frps 配置文件
|
||||
- **frpc.ini / frpc.toml**：frpc 配置文件
|
||||
|
||||
## Supported Protocol Types
|
||||
| 类型 | 说明 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| TCP | 原始 TCP 流量 | SSH、任意 TCP 端口 |
|
||||
| UDP | 原始 UDP 流量 | DNS、视频流 |
|
||||
| HTTP/HTTPS | 应用层代理 | Web 服务 |
|
||||
| STCP | 加密 TCP | 安全内网访问 |
|
||||
| SUDP | 加密 UDP | 安全数据传输 |
|
||||
| XTCP | P2P UDP | 穿越对称型 NAT |
|
||||
|
||||
## Key Configuration Parameters
|
||||
**frps.ini**:
|
||||
```ini
|
||||
[common]
|
||||
bind_addr = 0.0.0.0
|
||||
bind_port = 7000
|
||||
token = <shared_secret> # 认证 token
|
||||
dashboard_addr = 0.0.0.0
|
||||
dashboard_port = 7500
|
||||
dashboard_user = admin
|
||||
dashboard_pwd = <password>
|
||||
```
|
||||
|
||||
**frpc.ini**:
|
||||
```ini
|
||||
[common]
|
||||
server_addr = <vps_ip>
|
||||
server_port = 7000
|
||||
token = <shared_secret> # 必须与 frps 一致
|
||||
|
||||
[service_name]
|
||||
type = tcp
|
||||
local_ip = 127.0.0.1
|
||||
local_port = <local_port>
|
||||
remote_port = <vps_port> # VPS 暴露端口
|
||||
```
|
||||
|
||||
## Version Used in This Wiki
|
||||
- **frp v0.65.0**（当前使用版本）
|
||||
- 配置文件格式：`frpc.ini` / `frps.ini`（TOML 格式为 v0.52+，本 Wiki 使用 INI 格式）
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：完整实践指南（frps + Caddy + 阿里云 DNS）
|
||||
- [[ubuntu-安装-frp-0-65-0-x86-64-操作笔记]]：Ubuntu frpc 客户端安装配置
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]]：Mac Mini ARM64 安装配置
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]：通过 frp 穿透 Grafana/Prometheus 端口
|
||||
|
||||
## SSH 穿透注意事项
|
||||
SSH 穿透使用 `type = tcp`，不走 HTTP/HTTPS 代理层（Caddy 不参与）。SSH 连接命令：`ssh -p 60022 user@vps_domain`（`60022` 是 remote_port）。
|
||||
|
||||
## Troubleshooting
|
||||
详见 [[通过VPS+内网反向代理实现域名访问内网穿透]] 故障排查章节：
|
||||
1. 确认 frps 监听端口 `ss -lntup | grep frps`
|
||||
2. 确认 token 与 frpc 一致 `journalctl -u frps -n 100`
|
||||
3. 确认防火墙放行 7000 端口
|
||||
4. telnet 诊断确认连接是否到达 frps
|
||||
5. 强制重启 frps + frpc
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：frp 是实现内网穿透的工具
|
||||
- [[TCP隧道]]：frp 的 TCP 类型映射建立 TCP 隧道
|
||||
- [[反向代理]]：Caddy 通常在 frp 上层提供 HTTPS 访问
|
||||
|
||||
## Related Entities
|
||||
- [[RackNerd]]：托管 frps 的 VPS 提供商
|
||||
- [[VPS]]：运行 frps 的公网服务器
|
||||
- [[阿里云 DNS]]：管理 frp 穿透所需的域名解析
|
||||
|
||||
## References
|
||||
- GitHub: https://github.com/fatedier/frp
|
||||
- 文档: https://github.com/fatedier/frp#configuration
|
||||
---
|
||||
title: "frp"
|
||||
type: concept
|
||||
tags: [networking, open-source, golang, tunneling, self-hosted]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Fast Reverse Proxy
|
||||
- fatedier/frp
|
||||
- frps
|
||||
- frpc
|
||||
|
||||
## Definition
|
||||
frp（Fast Reverse Proxy）是一款开源的高性能内网穿透工具，由 Go 语言编写，通过客户端-服务端架构建立反向隧道，使处于 NAT 或防火墙后的内网服务可以被公网访问。包含两个核心组件：frps（服务端，运行在公网 VPS）和 frpc（客户端，运行在内网设备）。
|
||||
|
||||
## Core Architecture
|
||||
```
|
||||
公网用户 → VPS:7000(frps) ←——— 反向隧道 ←——— frpc(内网设备)
|
||||
```
|
||||
|
||||
## Key Components
|
||||
- **frps**（frp server）：运行在公网 VPS，监听 7000 端口（默认），接收 frpc 连接，管理端口映射
|
||||
- **frpc**（frp client）：运行在内网设备，主动连接 frps，建立反向隧道
|
||||
- **frps.ini / frps.toml**：frps 配置文件
|
||||
- **frpc.ini / frpc.toml**：frpc 配置文件
|
||||
|
||||
## Supported Protocol Types
|
||||
| 类型 | 说明 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| TCP | 原始 TCP 流量 | SSH、任意 TCP 端口 |
|
||||
| UDP | 原始 UDP 流量 | DNS、视频流 |
|
||||
| HTTP/HTTPS | 应用层代理 | Web 服务 |
|
||||
| STCP | 加密 TCP | 安全内网访问 |
|
||||
| SUDP | 加密 UDP | 安全数据传输 |
|
||||
| XTCP | P2P UDP | 穿越对称型 NAT |
|
||||
|
||||
## Key Configuration Parameters
|
||||
**frps.ini**:
|
||||
```ini
|
||||
[common]
|
||||
bind_addr = 0.0.0.0
|
||||
bind_port = 7000
|
||||
token = <shared_secret> # 认证 token
|
||||
dashboard_addr = 0.0.0.0
|
||||
dashboard_port = 7500
|
||||
dashboard_user = admin
|
||||
dashboard_pwd = <password>
|
||||
```
|
||||
|
||||
**frpc.ini**:
|
||||
```ini
|
||||
[common]
|
||||
server_addr = <vps_ip>
|
||||
server_port = 7000
|
||||
token = <shared_secret> # 必须与 frps 一致
|
||||
|
||||
[service_name]
|
||||
type = tcp
|
||||
local_ip = 127.0.0.1
|
||||
local_port = <local_port>
|
||||
remote_port = <vps_port> # VPS 暴露端口
|
||||
```
|
||||
|
||||
## Version Used in This Wiki
|
||||
- **frp v0.65.0**（当前使用版本）
|
||||
- 配置文件格式：`frpc.ini` / `frps.ini`（TOML 格式为 v0.52+，本 Wiki 使用 INI 格式）
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：完整实践指南（frps + Caddy + 阿里云 DNS）
|
||||
- [[ubuntu-安装-frp-0-65-0-x86-64-操作笔记]]：Ubuntu frpc 客户端安装配置
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]]：Mac Mini ARM64 安装配置
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]：通过 frp 穿透 Grafana/Prometheus 端口
|
||||
|
||||
## SSH 穿透注意事项
|
||||
SSH 穿透使用 `type = tcp`，不走 HTTP/HTTPS 代理层（Caddy 不参与）。SSH 连接命令：`ssh -p 60022 user@vps_domain`（`60022` 是 remote_port）。
|
||||
|
||||
## Troubleshooting
|
||||
详见 [[通过VPS+内网反向代理实现域名访问内网穿透]] 故障排查章节：
|
||||
1. 确认 frps 监听端口 `ss -lntup | grep frps`
|
||||
2. 确认 token 与 frpc 一致 `journalctl -u frps -n 100`
|
||||
3. 确认防火墙放行 7000 端口
|
||||
4. telnet 诊断确认连接是否到达 frps
|
||||
5. 强制重启 frps + frpc
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：frp 是实现内网穿透的工具
|
||||
- [[TCP隧道]]：frp 的 TCP 类型映射建立 TCP 隧道
|
||||
- [[反向代理]]：Caddy 通常在 frp 上层提供 HTTPS 访问
|
||||
|
||||
## Related Entities
|
||||
- [[RackNerd]]：托管 frps 的 VPS 提供商
|
||||
- [[VPS]]：运行 frps 的公网服务器
|
||||
- [[阿里云 DNS]]：管理 frp 穿透所需的域名解析
|
||||
|
||||
## References
|
||||
- GitHub: https://github.com/fatedier/frp
|
||||
- 文档: https://github.com/fatedier/frp#configuration
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "内网穿透"
|
||||
type: concept
|
||||
tags: [networking, vpn, tunnel, self-hosted]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Intranet Penetration
|
||||
- NAT穿透
|
||||
- 内网穿透
|
||||
- Reverse Tunnel
|
||||
|
||||
## Definition
|
||||
内网穿透（Intranet Penetration）是一种网络技术，通过在公网服务器与内网设备之间建立反向隧道，使处于 NAT 或防火墙后的内网服务可以被公网访问。核心原理：内网设备主动连接公网服务器的指定端口建立持久隧道，公网请求到达服务器后被转发至隧道，从而绕过 NAT/防火墙限制。
|
||||
|
||||
## Key Mechanism
|
||||
|
||||
### 反向隧道 vs 正向隧道
|
||||
- **正向隧道（Forward Tunnel）**：公网 → 内网（需要公网可达内网，NAT 环境下不可行）
|
||||
- **反向隧道（Reverse Tunnel）**：内网 → 公网（内网设备主动连接公网，NAT 环境下天然可行）
|
||||
|
||||
### 典型架构
|
||||
```
|
||||
公网用户
|
||||
↓
|
||||
公网 VPS（frps / ngrok server）
|
||||
↓ 反向隧道
|
||||
内网设备（frpc / ngrok client）
|
||||
↓
|
||||
本地服务（127.0.0.1:xxxx）
|
||||
```
|
||||
|
||||
## Common Tools
|
||||
- **frp**：开源方案，frps（服务端）+ frpc（客户端），支持 TCP/UDP/HTTP/WEBSOCKET 等多种协议
|
||||
- **ngrok**：商业托管方案，开源免费版有端口限制，无需公网服务器
|
||||
- **Cloudflare Tunnel**：Zero Trust 方案，配合 Cloudflare 账号使用
|
||||
- **SSH 反向隧道**：利用 SSH `-R` 参数建立临时反向隧道，适合临时访问
|
||||
|
||||
## frp 方案详解
|
||||
详见 [[frp]]
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：完整实践指南，frps + Caddy + 阿里云 DNS
|
||||
- [[ubuntu-安装-frp-0-65-0-x86-64-操作笔记]]：Ubuntu 客户端安装配置
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]]：Mac Mini ARM64 安装配置
|
||||
|
||||
## Related Concepts
|
||||
- [[反向代理]]：在内网穿透上层提供 HTTPS 访问（Caddy 反向代理到 frp 映射端口）
|
||||
- [[TCP隧道]]：frp 建立的底层传输通道
|
||||
- [[VPS]]：内网穿透的公网中转站
|
||||
|
||||
## References
|
||||
- frp GitHub: https://github.com/fatedier/frp
|
||||
---
|
||||
title: "内网穿透"
|
||||
type: concept
|
||||
tags: [networking, vpn, tunnel, self-hosted]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Intranet Penetration
|
||||
- NAT穿透
|
||||
- 内网穿透
|
||||
- Reverse Tunnel
|
||||
|
||||
## Definition
|
||||
内网穿透（Intranet Penetration）是一种网络技术，通过在公网服务器与内网设备之间建立反向隧道，使处于 NAT 或防火墙后的内网服务可以被公网访问。核心原理：内网设备主动连接公网服务器的指定端口建立持久隧道，公网请求到达服务器后被转发至隧道，从而绕过 NAT/防火墙限制。
|
||||
|
||||
## Key Mechanism
|
||||
|
||||
### 反向隧道 vs 正向隧道
|
||||
- **正向隧道（Forward Tunnel）**：公网 → 内网（需要公网可达内网，NAT 环境下不可行）
|
||||
- **反向隧道（Reverse Tunnel）**：内网 → 公网（内网设备主动连接公网，NAT 环境下天然可行）
|
||||
|
||||
### 典型架构
|
||||
```
|
||||
公网用户
|
||||
↓
|
||||
公网 VPS（frps / ngrok server）
|
||||
↓ 反向隧道
|
||||
内网设备（frpc / ngrok client）
|
||||
↓
|
||||
本地服务（127.0.0.1:xxxx）
|
||||
```
|
||||
|
||||
## Common Tools
|
||||
- **frp**：开源方案，frps（服务端）+ frpc（客户端），支持 TCP/UDP/HTTP/WEBSOCKET 等多种协议
|
||||
- **ngrok**：商业托管方案，开源免费版有端口限制，无需公网服务器
|
||||
- **Cloudflare Tunnel**：Zero Trust 方案，配合 Cloudflare 账号使用
|
||||
- **SSH 反向隧道**：利用 SSH `-R` 参数建立临时反向隧道，适合临时访问
|
||||
|
||||
## frp 方案详解
|
||||
详见 [[frp]]
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：完整实践指南，frps + Caddy + 阿里云 DNS
|
||||
- [[ubuntu-安装-frp-0-65-0-x86-64-操作笔记]]：Ubuntu 客户端安装配置
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]]：Mac Mini ARM64 安装配置
|
||||
|
||||
## Related Concepts
|
||||
- [[反向代理]]：在内网穿透上层提供 HTTPS 访问（Caddy 反向代理到 frp 映射端口）
|
||||
- [[TCP隧道]]：frp 建立的底层传输通道
|
||||
- [[VPS]]：内网穿透的公网中转站
|
||||
|
||||
## References
|
||||
- frp GitHub: https://github.com/fatedier/frp
|
||||
|
||||
@@ -1,41 +1,41 @@
|
||||
---
|
||||
title: "反向代理"
|
||||
type: concept
|
||||
tags: [networking, web, proxy, https, caddy]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Reverse Proxy
|
||||
- Reverse Proxy Server
|
||||
|
||||
## Definition
|
||||
反向代理（Reverse Proxy）是一种服务器架构模式：代理服务器位于客户端与目标服务器之间，客户端请求发送到代理服务器，代理服务器将请求转发至后端真实服务器，并将响应返回给客户端。客户端通常不知道真实服务器的存在。对比：正向代理代表客户端访问互联网（代理客户端）；反向代理代表服务端接收请求（代理服务端）。
|
||||
|
||||
## Key Capabilities
|
||||
- **SSL/TLS 终止（SSL Termination）**：代理服务器处理 HTTPS 加密/解密，后端服务无需配置证书
|
||||
- **负载均衡**：将请求分发至多个后端服务器
|
||||
- **缓存静态内容**：加速重复请求
|
||||
- **隐藏后端架构**：提升安全性
|
||||
- **自动 HTTPS**：部分反向代理（如 Caddy）可自动申请和续期 Let's Encrypt 证书
|
||||
|
||||
## Common Tools
|
||||
- **Caddy**：Go 语言编写，默认启用自动 HTTPS，适合个人/小型部署
|
||||
- **Nginx**：功能最全面，性能高，配置灵活
|
||||
- **Traefik**：专为容器设计，自动服务发现
|
||||
- **HAProxy**：高性能负载均衡器
|
||||
|
||||
## Caddy 方案详解
|
||||
详见 [[Caddy]]
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：Caddy 反向代理到 frp 映射端口，提供 `*.ishenwei.online` HTTPS 访问
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：Caddy 通常与 frp 配合使用，frp 建立隧道，Caddy 提供 HTTPS
|
||||
- [[TCP隧道]]：Caddy 处理 HTTP/HTTPS 层，TCP 隧道处理非 HTTP 协议（如 SSH）
|
||||
- [[VPS]]：反向代理通常部署在公网 VPS 上
|
||||
|
||||
## References
|
||||
- Caddy 官网: https://caddyserver.com/
|
||||
- Nginx 官网: https://nginx.org/
|
||||
---
|
||||
title: "反向代理"
|
||||
type: concept
|
||||
tags: [networking, web, proxy, https, caddy]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Reverse Proxy
|
||||
- Reverse Proxy Server
|
||||
|
||||
## Definition
|
||||
反向代理（Reverse Proxy）是一种服务器架构模式：代理服务器位于客户端与目标服务器之间，客户端请求发送到代理服务器，代理服务器将请求转发至后端真实服务器，并将响应返回给客户端。客户端通常不知道真实服务器的存在。对比：正向代理代表客户端访问互联网（代理客户端）；反向代理代表服务端接收请求（代理服务端）。
|
||||
|
||||
## Key Capabilities
|
||||
- **SSL/TLS 终止（SSL Termination）**：代理服务器处理 HTTPS 加密/解密，后端服务无需配置证书
|
||||
- **负载均衡**：将请求分发至多个后端服务器
|
||||
- **缓存静态内容**：加速重复请求
|
||||
- **隐藏后端架构**：提升安全性
|
||||
- **自动 HTTPS**：部分反向代理（如 Caddy）可自动申请和续期 Let's Encrypt 证书
|
||||
|
||||
## Common Tools
|
||||
- **Caddy**：Go 语言编写，默认启用自动 HTTPS，适合个人/小型部署
|
||||
- **Nginx**：功能最全面，性能高，配置灵活
|
||||
- **Traefik**：专为容器设计，自动服务发现
|
||||
- **HAProxy**：高性能负载均衡器
|
||||
|
||||
## Caddy 方案详解
|
||||
详见 [[Caddy]]
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：Caddy 反向代理到 frp 映射端口，提供 `*.ishenwei.online` HTTPS 访问
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：Caddy 通常与 frp 配合使用，frp 建立隧道，Caddy 提供 HTTPS
|
||||
- [[TCP隧道]]：Caddy 处理 HTTP/HTTPS 层，TCP 隧道处理非 HTTP 协议（如 SSH）
|
||||
- [[VPS]]：反向代理通常部署在公网 VPS 上
|
||||
|
||||
## References
|
||||
- Caddy 官网: https://caddyserver.com/
|
||||
- Nginx 官网: https://nginx.org/
|
||||
|
||||
@@ -1,35 +1,35 @@
|
||||
---
|
||||
title: "Amazon Web Services (AWS)"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Cloud
|
||||
- Hybrid-Cloud
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Amazon Web Services (AWS)
|
||||
|
||||
Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally.
|
||||
|
||||
## Aliases
|
||||
- AWS
|
||||
- Amazon Web Services
|
||||
|
||||
## Key Partnerships
|
||||
- **VMware Cloud on AWS (VMC on AWS)**: AWS partnered with VMware to run VMware workloads natively on AWS infrastructure. The underlying hardware consists of i3.metal and i3en.metal bare metal servers, organized into clusters within availability zones and regions.
|
||||
|
||||
## Infrastructure for VMC on AWS
|
||||
- **i3.metal**: Bare metal server instance used for VMware Cloud on AWS SDDC deployment
|
||||
- **i3en.metal**: Enhanced bare metal instance with larger storage capacity
|
||||
- **Clusters**: Organized within availability zones and regions globally
|
||||
- **Stretched Clusters**: Available across availability zones for increased resilience
|
||||
|
||||
## Connections
|
||||
- [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]]
|
||||
- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]]
|
||||
- [[VMware]] ← partners ← [[AWS]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-43-vmware-cloud-on-aws]]
|
||||
---
|
||||
title: "Amazon Web Services (AWS)"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Cloud
|
||||
- Hybrid-Cloud
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
last_updated: 2026-04-25
|
||||
---
|
||||
|
||||
## Amazon Web Services (AWS)
|
||||
|
||||
Amazon Web Services (AWS) is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally.
|
||||
|
||||
## Aliases
|
||||
- AWS
|
||||
- Amazon Web Services
|
||||
|
||||
## Key Partnerships
|
||||
- **VMware Cloud on AWS (VMC on AWS)**: AWS partnered with VMware to run VMware workloads natively on AWS infrastructure. The underlying hardware consists of i3.metal and i3en.metal bare metal servers, organized into clusters within availability zones and regions.
|
||||
|
||||
## Infrastructure for VMC on AWS
|
||||
- **i3.metal**: Bare metal server instance used for VMware Cloud on AWS SDDC deployment
|
||||
- **i3en.metal**: Enhanced bare metal instance with larger storage capacity
|
||||
- **Clusters**: Organized within availability zones and regions globally
|
||||
- **Stretched Clusters**: Available across availability zones for increased resilience
|
||||
|
||||
## Connections
|
||||
- [[VMware-Cloud-on-AWS]] ← powered_by ← [[AWS]]
|
||||
- [[ctp-topic-43-vmware-cloud-on-aws]] ← source ← [[AWS]]
|
||||
- [[VMware]] ← partners ← [[AWS]]
|
||||
|
||||
## Sources
|
||||
- [[ctp-topic-43-vmware-cloud-on-aws]]
|
||||
|
||||
@@ -1,34 +1,34 @@
|
||||
---
|
||||
title: "AdsPower"
|
||||
type: entity
|
||||
tags: [fingerprint-browser, multi-account, browser-automation]
|
||||
last_updated: 2025-12-31
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AdsPower 指纹浏览器
|
||||
- adspower
|
||||
|
||||
## Overview
|
||||
AdsPower 是一款专为企业用户设计的多账号指纹浏览器，通过模拟不同设备指纹、网络环境实现浏览器环境隔离，广泛用于跨境电商、社媒营销、账号矩阵运营等场景。
|
||||
|
||||
## Key Features
|
||||
- **指纹隔离**：模拟不同操作系统（Windows、macOS、Linux）、浏览器版本（Chrome、Firefox）、屏幕分辨率、时区、语言等参数
|
||||
- **账号矩阵管理**：批量创建和管理多个独立浏览器环境，每个环境配置独立代理IP
|
||||
- **支持谷歌授权登录**：可直接导入 Google 授权配置文件
|
||||
- **免费额度**：普通用户可免费使用 5 个浏览器环境
|
||||
|
||||
## Claude Pro Registration Use Case
|
||||
在 Claude Pro 注册流程中，AdsPower 用于：
|
||||
1. 创建独立浏览器环境，模拟美国 Windows + Chrome 131 环境
|
||||
2. 为每个环境配置独立 SOCKS5 代理IP
|
||||
3. 隔离不同账号的浏览器指纹，防止关联封号
|
||||
4. 支持导入已有 Google 账号直接登录 Claude
|
||||
|
||||
## Related
|
||||
- [[指纹浏览器]]
|
||||
- [[SOCKS5代理]]
|
||||
- [[IP纯净度]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
---
|
||||
title: "AdsPower"
|
||||
type: entity
|
||||
tags: [fingerprint-browser, multi-account, browser-automation]
|
||||
last_updated: 2025-12-31
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AdsPower 指纹浏览器
|
||||
- adspower
|
||||
|
||||
## Overview
|
||||
AdsPower 是一款专为企业用户设计的多账号指纹浏览器，通过模拟不同设备指纹、网络环境实现浏览器环境隔离，广泛用于跨境电商、社媒营销、账号矩阵运营等场景。
|
||||
|
||||
## Key Features
|
||||
- **指纹隔离**：模拟不同操作系统（Windows、macOS、Linux）、浏览器版本（Chrome、Firefox）、屏幕分辨率、时区、语言等参数
|
||||
- **账号矩阵管理**：批量创建和管理多个独立浏览器环境，每个环境配置独立代理IP
|
||||
- **支持谷歌授权登录**：可直接导入 Google 授权配置文件
|
||||
- **免费额度**：普通用户可免费使用 5 个浏览器环境
|
||||
|
||||
## Claude Pro Registration Use Case
|
||||
在 Claude Pro 注册流程中，AdsPower 用于：
|
||||
1. 创建独立浏览器环境，模拟美国 Windows + Chrome 131 环境
|
||||
2. 为每个环境配置独立 SOCKS5 代理IP
|
||||
3. 隔离不同账号的浏览器指纹，防止关联封号
|
||||
4. 支持导入已有 Google 账号直接登录 Claude
|
||||
|
||||
## Related
|
||||
- [[指纹浏览器]]
|
||||
- [[SOCKS5代理]]
|
||||
- [[IP纯净度]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: "Alertmanager"
|
||||
type: entity
|
||||
tags: [monitoring, alerting, prometheus, devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Alertmanager — Prometheus 告警分发组件
|
||||
|
||||
**官方网址：** https://prometheus.io/docs/alerting/latest/alertmanager/
|
||||
|
||||
**类型：** 开源项目 / 告警分发系统
|
||||
|
||||
**别名：**
|
||||
- prometheus-alertmanager
|
||||
- Alertmanager
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Alertmanager 是 Prometheus 生态中的告警分发组件，负责接收 Prometheus Server 发送的告警，进行抑制（inhibition）、分组（grouping）处理后路由到邮件、Slack、PagerDuty、webhook 等通知渠道。
|
||||
|
||||
**核心功能：**
|
||||
- **抑制（Inhibition）：** 当某条告警触发时，自动抑制相关联的其他告警
|
||||
- **分组（Grouping）：** 将相似告警合并为一条通知，减少告警风暴
|
||||
- **静默（Silence）：** 临时屏蔽特定告警
|
||||
- **路由（Routing）：** 基于标签匹配将告警路由到不同接收人
|
||||
|
||||
**配置格式：** YAML 格式的 `config.yml`
|
||||
|
||||
**典型部署：**
|
||||
- Docker: `prom/alertmanager:latest`
|
||||
- 端口：`9093`
|
||||
- Prometheus 配置中通过 `alerting.alertmanagers` 指定 targets
|
||||
|
||||
**支持的通知渠道：**
|
||||
- Email
|
||||
- Slack
|
||||
- PagerDuty
|
||||
- OpsGenie
|
||||
- WeChat
|
||||
- Telegram
|
||||
- Webhook（通用 HTTP）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
---
|
||||
title: "Alertmanager"
|
||||
type: entity
|
||||
tags: [monitoring, alerting, prometheus, devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Alertmanager — Prometheus 告警分发组件
|
||||
|
||||
**官方网址：** https://prometheus.io/docs/alerting/latest/alertmanager/
|
||||
|
||||
**类型：** 开源项目 / 告警分发系统
|
||||
|
||||
**别名：**
|
||||
- prometheus-alertmanager
|
||||
- Alertmanager
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Alertmanager 是 Prometheus 生态中的告警分发组件，负责接收 Prometheus Server 发送的告警，进行抑制（inhibition）、分组（grouping）处理后路由到邮件、Slack、PagerDuty、webhook 等通知渠道。
|
||||
|
||||
**核心功能：**
|
||||
- **抑制（Inhibition）：** 当某条告警触发时，自动抑制相关联的其他告警
|
||||
- **分组（Grouping）：** 将相似告警合并为一条通知，减少告警风暴
|
||||
- **静默（Silence）：** 临时屏蔽特定告警
|
||||
- **路由（Routing）：** 基于标签匹配将告警路由到不同接收人
|
||||
|
||||
**配置格式：** YAML 格式的 `config.yml`
|
||||
|
||||
**典型部署：**
|
||||
- Docker: `prom/alertmanager:latest`
|
||||
- 端口：`9093`
|
||||
- Prometheus 配置中通过 `alerting.alertmanagers` 指定 targets
|
||||
|
||||
**支持的通知渠道：**
|
||||
- Email
|
||||
- Slack
|
||||
- PagerDuty
|
||||
- OpsGenie
|
||||
- WeChat
|
||||
- Telegram
|
||||
- Webhook（通用 HTTP）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
---
|
||||
title: "Alist"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Alist
|
||||
|
||||
开源网盘聚合工具（WebDAV/File listing program），支持将多个云存储（阿里云盘、百度网盘、Google Drive、OneDrive、S3 等）统一挂载为本地文件系统访问。
|
||||
|
||||
## Aliases
|
||||
- AList
|
||||
- aList
|
||||
|
||||
## Overview
|
||||
Alist 通过 Web 界面聚合多个网盘/云存储服务，提供统一的文件浏览和下载入口。用户无需在各平台间切换，通过 Alist 即可访问所有挂载的存储。支持 Docker 部署，镜像名为 `xiaoyaliu/alist`。
|
||||
|
||||
## Key References
|
||||
- [[如何传输Docker images 并且在另一个Docker安装]] — 在 Synology NAS 上通过 `docker load` 导入 xiaoyaliu/alist 镜像的示例操作
|
||||
---
|
||||
title: "Alist"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Alist
|
||||
|
||||
开源网盘聚合工具（WebDAV/File listing program），支持将多个云存储（阿里云盘、百度网盘、Google Drive、OneDrive、S3 等）统一挂载为本地文件系统访问。
|
||||
|
||||
## Aliases
|
||||
- AList
|
||||
- aList
|
||||
|
||||
## Overview
|
||||
Alist 通过 Web 界面聚合多个网盘/云存储服务，提供统一的文件浏览和下载入口。用户无需在各平台间切换，通过 Alist 即可访问所有挂载的存储。支持 Docker 部署，镜像名为 `xiaoyaliu/alist`。
|
||||
|
||||
## Key References
|
||||
- [[如何传输Docker images 并且在另一个Docker安装]] — 在 Synology NAS 上通过 `docker load` 导入 xiaoyaliu/alist 镜像的示例操作
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
---
|
||||
title: "Anthropic"
|
||||
type: entity
|
||||
tags: ["llm-provider", "anthropic"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Anthropic
|
||||
- Anthropic PBC
|
||||
|
||||
## Definition
|
||||
Anthropic 是主要的 LLM Provider，提供 Claude 系列模型（Claude Opus、Claude Sonnet、Claude Haiku 等）。在 [[AutonomousOptimizationArchitect]] 系统中作为高精度基准模型，其输出常被用作 [[LLMasJudge]] 评估其他模型时的参照标准。
|
||||
|
||||
## Role in LLM Routing
|
||||
- Claude Opus 常作为高精度基准——如果其他模型要替代 Claude，必须达到其 98%+ 精度
|
||||
- Claude Sonnet/Haiku 提供性价比选项，供 [[AutonomousOptimizationArchitect]] 按任务难度分配
|
||||
- Anthropic API 不可用时触发 [[CircuitBreaker]] 切换至 [[OpenAI]] 或 [[GoogleGemini]]
|
||||
|
||||
## Key Properties
|
||||
- **Token 成本**：$3-15 / 1M tokens
|
||||
- **延迟**：低至中等
|
||||
- **常见用途**：复杂推理、长文本分析、安全敏感任务
|
||||
|
||||
## Connections
|
||||
- [[OpenAI]] — 同为 LLM Provider，共同参与 [[SemanticRouting]]
|
||||
- [[GoogleGemini]] — 在成本优化场景中与 Gemini Flash 形成对比
|
||||
---
|
||||
title: "Anthropic"
|
||||
type: entity
|
||||
tags: ["llm-provider", "anthropic"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Anthropic
|
||||
- Anthropic PBC
|
||||
|
||||
## Definition
|
||||
Anthropic 是主要的 LLM Provider，提供 Claude 系列模型（Claude Opus、Claude Sonnet、Claude Haiku 等）。在 [[AutonomousOptimizationArchitect]] 系统中作为高精度基准模型，其输出常被用作 [[LLMasJudge]] 评估其他模型时的参照标准。
|
||||
|
||||
## Role in LLM Routing
|
||||
- Claude Opus 常作为高精度基准——如果其他模型要替代 Claude，必须达到其 98%+ 精度
|
||||
- Claude Sonnet/Haiku 提供性价比选项，供 [[AutonomousOptimizationArchitect]] 按任务难度分配
|
||||
- Anthropic API 不可用时触发 [[CircuitBreaker]] 切换至 [[OpenAI]] 或 [[GoogleGemini]]
|
||||
|
||||
## Key Properties
|
||||
- **Token 成本**：$3-15 / 1M tokens
|
||||
- **延迟**：低至中等
|
||||
- **常见用途**：复杂推理、长文本分析、安全敏感任务
|
||||
|
||||
## Connections
|
||||
- [[OpenAI]] — 同为 LLM Provider，共同参与 [[SemanticRouting]]
|
||||
- [[GoogleGemini]] — 在成本优化场景中与 Gemini Flash 形成对比
|
||||
|
||||
@@ -1,42 +1,42 @@
|
||||
---
|
||||
title: Azure (Microsoft Azure)
|
||||
type: entity
|
||||
tags: [Cloud, Provider, Public-Cloud]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
---
|
||||
|
||||
# Azure (Microsoft Azure)
|
||||
|
||||
**Microsoft Azure** is a cloud computing platform operated by Microsoft, providing a broad range of services for application and workload hosting.
|
||||
|
||||
## Overview
|
||||
|
||||
Azure is one of the three major public cloud providers, particularly strong in enterprise environments with Microsoft ecosystem integration.
|
||||
|
||||
## Key Services Referenced
|
||||
|
||||
| Category | Services |
|
||||
|----------|----------|
|
||||
| Compute | Virtual Machines, Azure Functions |
|
||||
| Storage | Blob Storage, Azure Files |
|
||||
| Database | Azure SQL, Cosmos DB |
|
||||
| AI/ML | Azure AI, Azure OpenAI Service |
|
||||
| Analytics | Synapse, Databricks |
|
||||
| Enterprise | Active Directory, Microsoft 365 integration |
|
||||
|
||||
## Multi-Cloud Context
|
||||
|
||||
Azure is commonly used alongside AWS and Google Cloud in multi-cloud strategies:
|
||||
- **Enterprise workloads** — Strong Windows Server and SQL Server integration
|
||||
- **AI services** — Azure OpenAI Service for enterprise AI applications
|
||||
- **Hybrid cloud** — Deep integration with on-premises Windows environments
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud-Strategy]] — Azure as one of multiple providers
|
||||
- [[Cloud-Native]] — Building on Azure-native services
|
||||
- [[FinOps]] — Managing Azure costs
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
---
|
||||
title: Azure (Microsoft Azure)
|
||||
type: entity
|
||||
tags: [Cloud, Provider, Public-Cloud]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
---
|
||||
|
||||
# Azure (Microsoft Azure)
|
||||
|
||||
**Microsoft Azure** is a cloud computing platform operated by Microsoft, providing a broad range of services for application and workload hosting.
|
||||
|
||||
## Overview
|
||||
|
||||
Azure is one of the three major public cloud providers, particularly strong in enterprise environments with Microsoft ecosystem integration.
|
||||
|
||||
## Key Services Referenced
|
||||
|
||||
| Category | Services |
|
||||
|----------|----------|
|
||||
| Compute | Virtual Machines, Azure Functions |
|
||||
| Storage | Blob Storage, Azure Files |
|
||||
| Database | Azure SQL, Cosmos DB |
|
||||
| AI/ML | Azure AI, Azure OpenAI Service |
|
||||
| Analytics | Synapse, Databricks |
|
||||
| Enterprise | Active Directory, Microsoft 365 integration |
|
||||
|
||||
## Multi-Cloud Context
|
||||
|
||||
Azure is commonly used alongside AWS and Google Cloud in multi-cloud strategies:
|
||||
- **Enterprise workloads** — Strong Windows Server and SQL Server integration
|
||||
- **AI services** — Azure OpenAI Service for enterprise AI applications
|
||||
- **Hybrid cloud** — Deep integration with on-premises Windows environments
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud-Strategy]] — Azure as one of multiple providers
|
||||
- [[Cloud-Native]] — Building on Azure-native services
|
||||
- [[FinOps]] — Managing Azure costs
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
|
||||
@@ -1,53 +1,53 @@
|
||||
---
|
||||
title: "Blackbox Exporter"
|
||||
type: entity
|
||||
tags: [monitoring, prometheus, blackbox, probe, devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Blackbox Exporter — Prometheus 黑盒探测 exporter
|
||||
|
||||
**官方网址：** https://prometheus.io/docs/guides/node-exporter/
|
||||
|
||||
**类型：** 开源项目 / Prometheus Exporter
|
||||
|
||||
**别名：**
|
||||
- blackbox_exporter
|
||||
- prometheus blackbox
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Blackbox Exporter 是 Prometheus 官方提供的黑盒探测 exporter，通过 HTTP、HTTPS、DNS、TCP、ICMP 等协议探测目标端点的可用性、响应时间和 TLS 证书状态，支持细粒度的服务层监控。
|
||||
|
||||
**支持模块：**
|
||||
- `http_2xx` — HTTP/HTTPS 可用性探测
|
||||
- `https_2xx` — 仅 HTTPS 探测
|
||||
- `dns` — DNS 解析探测
|
||||
- `tcp` — TCP 端口探测
|
||||
- `icmp` — ICMP ping 探测
|
||||
|
||||
**采集指标示例：**
|
||||
- `probe_success` — 探测是否成功（0/1）
|
||||
- `probe_duration_seconds` — 探测耗时（秒）
|
||||
- `probe_ssl_earliest_cert_expiry` — TLS 证书到期时间戳
|
||||
- `probe_http_status_code` — HTTP 响应码
|
||||
- `probe_dns_lookup_duration_seconds` — DNS 解析耗时
|
||||
|
||||
**典型部署：**
|
||||
- Docker: `prom/blackbox-exporter:latest`
|
||||
- 端口：`9115`
|
||||
- Prometheus 配置需使用 `metrics_path: /probe` 和 `params: module: [http_2xx]`
|
||||
|
||||
**关键告警规则示例：**
|
||||
- 站点不可达: `probe_success == 0`（持续 2 分钟）
|
||||
- TLS 证书到期: `probe_ssl_earliest_cert_expiry - time() < 86400 * 14`（剩余 < 14 天）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
---
|
||||
title: "Blackbox Exporter"
|
||||
type: entity
|
||||
tags: [monitoring, prometheus, blackbox, probe, devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Blackbox Exporter — Prometheus 黑盒探测 exporter
|
||||
|
||||
**官方网址：** https://prometheus.io/docs/guides/node-exporter/
|
||||
|
||||
**类型：** 开源项目 / Prometheus Exporter
|
||||
|
||||
**别名：**
|
||||
- blackbox_exporter
|
||||
- prometheus blackbox
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Blackbox Exporter 是 Prometheus 官方提供的黑盒探测 exporter，通过 HTTP、HTTPS、DNS、TCP、ICMP 等协议探测目标端点的可用性、响应时间和 TLS 证书状态，支持细粒度的服务层监控。
|
||||
|
||||
**支持模块：**
|
||||
- `http_2xx` — HTTP/HTTPS 可用性探测
|
||||
- `https_2xx` — 仅 HTTPS 探测
|
||||
- `dns` — DNS 解析探测
|
||||
- `tcp` — TCP 端口探测
|
||||
- `icmp` — ICMP ping 探测
|
||||
|
||||
**采集指标示例：**
|
||||
- `probe_success` — 探测是否成功（0/1）
|
||||
- `probe_duration_seconds` — 探测耗时（秒）
|
||||
- `probe_ssl_earliest_cert_expiry` — TLS 证书到期时间戳
|
||||
- `probe_http_status_code` — HTTP 响应码
|
||||
- `probe_dns_lookup_duration_seconds` — DNS 解析耗时
|
||||
|
||||
**典型部署：**
|
||||
- Docker: `prom/blackbox-exporter:latest`
|
||||
- 端口：`9115`
|
||||
- Prometheus 配置需使用 `metrics_path: /probe` 和 `params: module: [http_2xx]`
|
||||
|
||||
**关键告警规则示例：**
|
||||
- 站点不可达: `probe_success == 0`（持续 2 分钟）
|
||||
- TLS 证书到期: `probe_ssl_earliest_cert_expiry - time() < 86400 * 14`（剩余 < 14 天）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
@@ -1,65 +1,65 @@
|
||||
---
|
||||
title: "Clonezilla"
|
||||
tags: [backup, opensource, disk-imaging, dr]
|
||||
date: 2026-04-28
|
||||
---
|
||||
|
||||
# Clonezilla (再生龙)
|
||||
|
||||
## Aliases
|
||||
- Clonezilla
|
||||
- 再生龙
|
||||
|
||||
## Definition
|
||||
Clonezilla 是一款开源的磁盘镜像/克隆工具，类似于 Norton Ghost，提供完整的系统级备份与还原功能。支持将整个磁盘或单个分区备份为镜像文件，存储到本地磁盘、NFS、SMB、SFTP 等多种目标位置。
|
||||
|
||||
## Core Capabilities
|
||||
- **savedisk**: 将整个磁盘备份为镜像文件
|
||||
- **saveparts**: 仅备份指定分区
|
||||
- **restoredisk**: 从镜像还原整个磁盘
|
||||
- **restoreparts**: 从镜像还原指定分区
|
||||
- **device-image 模式**: 将磁盘映射为镜像文件存储（区别于直接磁盘对磁盘克隆）
|
||||
|
||||
## Key Features
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| 备份介质 | 本地磁盘、外置硬盘、NFS、SMB、SFTP、SSH |
|
||||
| 压缩选项 | -z1p (高压缩率), -z2p, -z3p, -z4p |
|
||||
| 文件系统支持 | ext2/3/4, NTFS, FAT, HFS+, XFS, Btrfs 等 |
|
||||
| 分区表支持 | MBR 和 GPT |
|
||||
| 模式 | Beginner（初学者）/ Expert（专家） |
|
||||
| 启动介质 | Live CD, Live USB, PXE 网络启动 |
|
||||
|
||||
## Backup Workflow
|
||||
```
|
||||
1. 制作 Clonezilla 启动 U 盘 (Rufus ISO 模式)
|
||||
2. 从 U 盘启动源机器，进入 Clonezilla Live
|
||||
3. 选择 device-image 模式
|
||||
4. 挂载 NAS/外置硬盘作为备份目标
|
||||
5. 选择 savedisk → 选择源磁盘 → 配置参数
|
||||
6. 等待镜像生成
|
||||
```
|
||||
|
||||
## Restore Workflow
|
||||
```
|
||||
1. 从 U 盘启动目标机器（或原机器）
|
||||
2. 进入 Clonezilla，选择 device-image 模式
|
||||
3. 挂载存储镜像的 NAS/外置硬盘
|
||||
4. 选择 restoredisk → 选择镜像文件 → 选择目标磁盘
|
||||
5. 确认覆盖 → 等待还原完成 → 系统即刻复活
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[全盘镜像备份]] — Clonezilla 实现的备份方法
|
||||
- [[NFS网络备份]] — Clonezilla 推荐的网络存储方案
|
||||
- [[裸机恢复]] — Clonezilla 支持的核心场景
|
||||
- [[增量备份]] — Clonezilla 镜像备份 vs rsync 增量备份（互补方案）
|
||||
|
||||
## Related Sources
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]]
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — rsync 增量备份与 Clonezilla 全盘镜像形成双层保护体系
|
||||
|
||||
## Related Entities
|
||||
- [[Rufus]] — U 盘启动盘制作工具
|
||||
- [[Synology-NAS]] — 备份镜像存储目标
|
||||
- [[HP ZBook]] — 源笔记本设备
|
||||
---
|
||||
title: "Clonezilla"
|
||||
tags: [backup, opensource, disk-imaging, dr]
|
||||
date: 2026-04-28
|
||||
---
|
||||
|
||||
# Clonezilla (再生龙)
|
||||
|
||||
## Aliases
|
||||
- Clonezilla
|
||||
- 再生龙
|
||||
|
||||
## Definition
|
||||
Clonezilla 是一款开源的磁盘镜像/克隆工具，类似于 Norton Ghost，提供完整的系统级备份与还原功能。支持将整个磁盘或单个分区备份为镜像文件，存储到本地磁盘、NFS、SMB、SFTP 等多种目标位置。
|
||||
|
||||
## Core Capabilities
|
||||
- **savedisk**: 将整个磁盘备份为镜像文件
|
||||
- **saveparts**: 仅备份指定分区
|
||||
- **restoredisk**: 从镜像还原整个磁盘
|
||||
- **restoreparts**: 从镜像还原指定分区
|
||||
- **device-image 模式**: 将磁盘映射为镜像文件存储（区别于直接磁盘对磁盘克隆）
|
||||
|
||||
## Key Features
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| 备份介质 | 本地磁盘、外置硬盘、NFS、SMB、SFTP、SSH |
|
||||
| 压缩选项 | -z1p (高压缩率), -z2p, -z3p, -z4p |
|
||||
| 文件系统支持 | ext2/3/4, NTFS, FAT, HFS+, XFS, Btrfs 等 |
|
||||
| 分区表支持 | MBR 和 GPT |
|
||||
| 模式 | Beginner（初学者）/ Expert（专家） |
|
||||
| 启动介质 | Live CD, Live USB, PXE 网络启动 |
|
||||
|
||||
## Backup Workflow
|
||||
```
|
||||
1. 制作 Clonezilla 启动 U 盘 (Rufus ISO 模式)
|
||||
2. 从 U 盘启动源机器，进入 Clonezilla Live
|
||||
3. 选择 device-image 模式
|
||||
4. 挂载 NAS/外置硬盘作为备份目标
|
||||
5. 选择 savedisk → 选择源磁盘 → 配置参数
|
||||
6. 等待镜像生成
|
||||
```
|
||||
|
||||
## Restore Workflow
|
||||
```
|
||||
1. 从 U 盘启动目标机器（或原机器）
|
||||
2. 进入 Clonezilla，选择 device-image 模式
|
||||
3. 挂载存储镜像的 NAS/外置硬盘
|
||||
4. 选择 restoredisk → 选择镜像文件 → 选择目标磁盘
|
||||
5. 确认覆盖 → 等待还原完成 → 系统即刻复活
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
- [[全盘镜像备份]] — Clonezilla 实现的备份方法
|
||||
- [[NFS网络备份]] — Clonezilla 推荐的网络存储方案
|
||||
- [[裸机恢复]] — Clonezilla 支持的核心场景
|
||||
- [[增量备份]] — Clonezilla 镜像备份 vs rsync 增量备份（互补方案）
|
||||
|
||||
## Related Sources
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]]
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — rsync 增量备份与 Clonezilla 全盘镜像形成双层保护体系
|
||||
|
||||
## Related Entities
|
||||
- [[Rufus]] — U 盘启动盘制作工具
|
||||
- [[Synology-NAS]] — 备份镜像存储目标
|
||||
- [[HP ZBook]] — 源笔记本设备
|
||||
|
||||
@@ -1,61 +1,61 @@
|
||||
# DevOps Maturity Model
|
||||
|
||||
## Source
|
||||
- [[sources/cloud-devop-maturity-guideline.md]]
|
||||
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
A framework for evaluating an organization's progress in adopting DevOps practices, typically ranging from ad-hoc processes to highly optimized and automated environments. The model defines **five maturity stages**:
|
||||
|
||||
| Stage | Name | Key Characteristics |
|
||||
|-------|------|---------------------|
|
||||
| Phase 1 | Initial/Ad-Hoc | Siloed teams, waterfall approach, manual infrastructure, reactive monitoring, security only at release |
|
||||
| Phase 2 | DevOps in Pockets | Small cross-functional teams, Agile introduction, version control, superficial automation, unit/integration testing |
|
||||
| Phase 3 | Automated and Defined | Standardized processes, most infrastructure automated, security integrated into development process |
|
||||
| Phase 4 | Highly Optimized | CI pipeline, immutable infrastructure, MVP and tech debt management, continuous security monitoring |
|
||||
| Phase 5 | Fully Mature | Self-sufficient full-stack teams, multiple daily deployments, zero human intervention in pipeline |
|
||||
|
||||
## Key Focus Areas
|
||||
|
||||
1. **Culture and Strategy** — Teamwork, transparency, customer-centric mindset
|
||||
2. **Automation** — AutoDevOps for continuous delivery and deployment
|
||||
3. **Structure and Process** — Standardized, small-batch, transparent processes
|
||||
4. **Collaboration and Sharing** — Cohesive teams leveraging diverse skill sets
|
||||
5. **Technology** — Tool selection aligned with team needs
|
||||
|
||||
## Quality Criteria
|
||||
|
||||
- Assessment criteria (standards for evaluating maturity)
|
||||
- Five maturity levels
|
||||
- Core DevOps practices (release management, CI/CD, IaC, security)
|
||||
- Relevant metrics (deployment frequency, MTTR, change failure rate)
|
||||
- Cultural guides
|
||||
- Tools and technologies
|
||||
- Roles and responsibilities
|
||||
|
||||
## Business Benefits
|
||||
|
||||
- Quicker adjustment to market changes
|
||||
- Capability to seize new opportunities
|
||||
- Better scalability via IaC
|
||||
- Enhanced operational performance
|
||||
- Faster delivery times
|
||||
- Improved quality via continuous monitoring and feedback
|
||||
|
||||
## Security Integration (DevSecOps)
|
||||
|
||||
The model emphasizes merging development, operations, and security into a unified process. Security progression: ad-hoc compliance scans → separate security team → security in design/architecture discussions → security updates in product workflow → preventing non-compliant code from production.
|
||||
|
||||
## Related Concepts
|
||||
- [[concepts/DevOps-Maturity]]
|
||||
- [[concepts/DORA-Metrics]]
|
||||
- [[concepts/DevSecOps]]
|
||||
- [[concepts/CI-CD-Pipeline]]
|
||||
- [[concepts/Infrastructure-as-Code]]
|
||||
- [[concepts/Continuous-Deployment]]
|
||||
|
||||
## Ingested
|
||||
- Date: 2026-04-21 (initial)
|
||||
- Date: 2026-04-24 (updated with Phase 1-5 details)
|
||||
- Date: 2026-04-26 (补充 DevOps 成熟度衡量指标、业务收益、安全集成的详细内容)
|
||||
# DevOps Maturity Model
|
||||
|
||||
## Source
|
||||
- [[sources/cloud-devop-maturity-guideline.md]]
|
||||
- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
A framework for evaluating an organization's progress in adopting DevOps practices, typically ranging from ad-hoc processes to highly optimized and automated environments. The model defines **five maturity stages**:
|
||||
|
||||
| Stage | Name | Key Characteristics |
|
||||
|-------|------|---------------------|
|
||||
| Phase 1 | Initial/Ad-Hoc | Siloed teams, waterfall approach, manual infrastructure, reactive monitoring, security only at release |
|
||||
| Phase 2 | DevOps in Pockets | Small cross-functional teams, Agile introduction, version control, superficial automation, unit/integration testing |
|
||||
| Phase 3 | Automated and Defined | Standardized processes, most infrastructure automated, security integrated into development process |
|
||||
| Phase 4 | Highly Optimized | CI pipeline, immutable infrastructure, MVP and tech debt management, continuous security monitoring |
|
||||
| Phase 5 | Fully Mature | Self-sufficient full-stack teams, multiple daily deployments, zero human intervention in pipeline |
|
||||
|
||||
## Key Focus Areas
|
||||
|
||||
1. **Culture and Strategy** — Teamwork, transparency, customer-centric mindset
|
||||
2. **Automation** — AutoDevOps for continuous delivery and deployment
|
||||
3. **Structure and Process** — Standardized, small-batch, transparent processes
|
||||
4. **Collaboration and Sharing** — Cohesive teams leveraging diverse skill sets
|
||||
5. **Technology** — Tool selection aligned with team needs
|
||||
|
||||
## Quality Criteria
|
||||
|
||||
- Assessment criteria (standards for evaluating maturity)
|
||||
- Five maturity levels
|
||||
- Core DevOps practices (release management, CI/CD, IaC, security)
|
||||
- Relevant metrics (deployment frequency, MTTR, change failure rate)
|
||||
- Cultural guides
|
||||
- Tools and technologies
|
||||
- Roles and responsibilities
|
||||
|
||||
## Business Benefits
|
||||
|
||||
- Quicker adjustment to market changes
|
||||
- Capability to seize new opportunities
|
||||
- Better scalability via IaC
|
||||
- Enhanced operational performance
|
||||
- Faster delivery times
|
||||
- Improved quality via continuous monitoring and feedback
|
||||
|
||||
## Security Integration (DevSecOps)
|
||||
|
||||
The model emphasizes merging development, operations, and security into a unified process. Security progression: ad-hoc compliance scans → separate security team → security in design/architecture discussions → security updates in product workflow → preventing non-compliant code from production.
|
||||
|
||||
## Related Concepts
|
||||
- [[concepts/DevOps-Maturity]]
|
||||
- [[concepts/DORA-Metrics]]
|
||||
- [[concepts/DevSecOps]]
|
||||
- [[concepts/CI-CD-Pipeline]]
|
||||
- [[concepts/Infrastructure-as-Code]]
|
||||
- [[concepts/Continuous-Deployment]]
|
||||
|
||||
## Ingested
|
||||
- Date: 2026-04-21 (initial)
|
||||
- Date: 2026-04-24 (updated with Phase 1-5 details)
|
||||
- Date: 2026-04-26 (补充 DevOps 成熟度衡量指标、业务收益、安全集成的详细内容)
|
||||
|
||||
@@ -1,31 +1,31 @@
|
||||
---
|
||||
title: "Docker"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Docker
|
||||
|
||||
开源容器化平台（Containerization Platform），用于打包、分发和运行应用程序及其依赖。
|
||||
|
||||
## Aliases
|
||||
- Docker Engine
|
||||
- Docker Desktop
|
||||
|
||||
## Overview
|
||||
Docker 通过容器（Container）将应用程序及其运行时环境打包为独立镜像，支持跨平台一致部署。核心组件包括：
|
||||
- **Dockerfile**：定义镜像构建步骤
|
||||
- **docker pull/push**：从 Registry 拉取/推送镜像
|
||||
- **docker save/load**：镜像离线打包（tar）与导入
|
||||
- **docker run**：基于镜像启动容器
|
||||
- **docker compose**：多容器编排
|
||||
|
||||
## Key References
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] — Docker + Docker Compose 安装
|
||||
- [[如何传输Docker images 并且在另一个Docker安装]] — 镜像离线迁移（save/load）
|
||||
- [[用Docker安装Portainer]] — 容器管理面板
|
||||
- [[用Docker安装Jellyfin]] — 媒体服务器
|
||||
- [[用Docker安装Homarr]] — 个人导航仪表盘
|
||||
- [[用Docker安装Apache Superset]] — BI 可视化平台
|
||||
- [[如何删除旧的废弃的 Docker Container + Volume]] — 容器清理
|
||||
---
|
||||
title: "Docker"
|
||||
type: entity
|
||||
tags: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Docker
|
||||
|
||||
开源容器化平台（Containerization Platform），用于打包、分发和运行应用程序及其依赖。
|
||||
|
||||
## Aliases
|
||||
- Docker Engine
|
||||
- Docker Desktop
|
||||
|
||||
## Overview
|
||||
Docker 通过容器（Container）将应用程序及其运行时环境打包为独立镜像，支持跨平台一致部署。核心组件包括：
|
||||
- **Dockerfile**：定义镜像构建步骤
|
||||
- **docker pull/push**：从 Registry 拉取/推送镜像
|
||||
- **docker save/load**：镜像离线打包（tar）与导入
|
||||
- **docker run**：基于镜像启动容器
|
||||
- **docker compose**：多容器编排
|
||||
|
||||
## Key References
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] — Docker + Docker Compose 安装
|
||||
- [[如何传输Docker images 并且在另一个Docker安装]] — 镜像离线迁移（save/load）
|
||||
- [[用Docker安装Portainer]] — 容器管理面板
|
||||
- [[用Docker安装Jellyfin]] — 媒体服务器
|
||||
- [[用Docker安装Homarr]] — 个人导航仪表盘
|
||||
- [[用Docker安装Apache Superset]] — BI 可视化平台
|
||||
- [[如何删除旧的废弃的 Docker Container + Volume]] — 容器清理
|
||||
|
||||
@@ -1,43 +1,43 @@
|
||||
---
|
||||
title: Google Cloud Platform (GCP)
|
||||
type: entity
|
||||
tags: [Cloud, Provider, Public-Cloud]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
---
|
||||
|
||||
# Google Cloud Platform (GCP)
|
||||
|
||||
**Google Cloud Platform (GCP)** is Google's cloud computing platform, providing infrastructure and application services with strengths in AI/ML, data analytics, and container technologies.
|
||||
|
||||
## Overview
|
||||
|
||||
GCP is one of the three major public cloud providers, particularly known for Kubernetes (originated at Google), data analytics, and machine learning capabilities.
|
||||
|
||||
## Key Services Referenced
|
||||
|
||||
| Category | Services |
|
||||
|----------|----------|
|
||||
| Compute | Compute Engine, Cloud Functions, GKE |
|
||||
| Storage | Cloud Storage, Filestore |
|
||||
| Database | Cloud SQL, BigQuery, Firestore, Spanner |
|
||||
| AI/ML | Vertex AI, TensorFlow, Gemini |
|
||||
| Analytics | BigQuery, Dataflow, Looker |
|
||||
| Networking | VPC, Cloud CDN, Cloud Load Balancing |
|
||||
|
||||
## Multi-Cloud Context
|
||||
|
||||
GCP is commonly used alongside AWS and Azure in multi-cloud strategies:
|
||||
- **Machine Learning** — Often preferred for ML/AI workloads (Vertex AI, TensorFlow)
|
||||
- **Data Analytics** — BigQuery for data warehousing and analytics
|
||||
- **Container-native** — GKE (Google Kubernetes Engine) for container orchestration
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud-Strategy]] — GCP as one of multiple providers
|
||||
- [[Cloud-Native]] — Building on GCP-native services
|
||||
- [[Kubernetes]] — GKE as managed Kubernetes
|
||||
- [[FinOps]] — Managing GCP costs
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
---
|
||||
title: Google Cloud Platform (GCP)
|
||||
type: entity
|
||||
tags: [Cloud, Provider, Public-Cloud]
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
---
|
||||
|
||||
# Google Cloud Platform (GCP)
|
||||
|
||||
**Google Cloud Platform (GCP)** is Google's cloud computing platform, providing infrastructure and application services with strengths in AI/ML, data analytics, and container technologies.
|
||||
|
||||
## Overview
|
||||
|
||||
GCP is one of the three major public cloud providers, particularly known for Kubernetes (originated at Google), data analytics, and machine learning capabilities.
|
||||
|
||||
## Key Services Referenced
|
||||
|
||||
| Category | Services |
|
||||
|----------|----------|
|
||||
| Compute | Compute Engine, Cloud Functions, GKE |
|
||||
| Storage | Cloud Storage, Filestore |
|
||||
| Database | Cloud SQL, BigQuery, Firestore, Spanner |
|
||||
| AI/ML | Vertex AI, TensorFlow, Gemini |
|
||||
| Analytics | BigQuery, Dataflow, Looker |
|
||||
| Networking | VPC, Cloud CDN, Cloud Load Balancing |
|
||||
|
||||
## Multi-Cloud Context
|
||||
|
||||
GCP is commonly used alongside AWS and Azure in multi-cloud strategies:
|
||||
- **Machine Learning** — Often preferred for ML/AI workloads (Vertex AI, TensorFlow)
|
||||
- **Data Analytics** — BigQuery for data warehousing and analytics
|
||||
- **Container-native** — GKE (Google Kubernetes Engine) for container orchestration
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Multi-Cloud-Strategy]] — GCP as one of multiple providers
|
||||
- [[Cloud-Native]] — Building on GCP-native services
|
||||
- [[Kubernetes]] — GKE as managed Kubernetes
|
||||
- [[FinOps]] — Managing GCP costs
|
||||
|
||||
## Sources
|
||||
|
||||
- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]]
|
||||
|
||||
@@ -1,30 +1,30 @@
|
||||
---
|
||||
title: "GoogleGemini"
|
||||
type: entity
|
||||
tags: ["llm-provider", "google", "gemini"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Gemini
|
||||
- Google Gemini
|
||||
- Gemini Flash
|
||||
- Gemini Pro
|
||||
|
||||
## Definition
|
||||
Google Gemini 是 Google 的 LLM 系列模型，涵盖从高性价比到高性能的多种版本。在 [[AutonomousOptimizationArchitect]] 系统中，Gemini Flash 因其极高的性价比（成本约为 Claude Opus 的 1/10）而被列为重要的路由目标。
|
||||
|
||||
## Role in LLM Routing
|
||||
- **Gemini Flash**：低成本高速度模型，如果精度达到基准的 98% 且成本远低于竞品，[[AutonomousOptimizationArchitect]] 会将流量自动路由至 Gemini
|
||||
- **Gemini Pro**：中端定位，提供能力与成本的平衡
|
||||
- 与 [[OpenAI]] 和 [[Anthropic]] 共同构成三足鼎立的 Provider 生态
|
||||
|
||||
## Key Properties
|
||||
- **Token 成本**：$0.075-0.5 / 1M tokens（Gemini Flash 极低）
|
||||
- **延迟**：低（Gemini Flash）
|
||||
- **优势**：极高的性价比，特别适合大规模、低成本推理
|
||||
|
||||
## Connections
|
||||
- [[OpenAI]] — 同为 LLM Provider
|
||||
- [[Anthropic]] — 高精度基准 Provider
|
||||
---
|
||||
title: "GoogleGemini"
|
||||
type: entity
|
||||
tags: ["llm-provider", "google", "gemini"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Gemini
|
||||
- Google Gemini
|
||||
- Gemini Flash
|
||||
- Gemini Pro
|
||||
|
||||
## Definition
|
||||
Google Gemini 是 Google 的 LLM 系列模型，涵盖从高性价比到高性能的多种版本。在 [[AutonomousOptimizationArchitect]] 系统中，Gemini Flash 因其极高的性价比（成本约为 Claude Opus 的 1/10）而被列为重要的路由目标。
|
||||
|
||||
## Role in LLM Routing
|
||||
- **Gemini Flash**：低成本高速度模型，如果精度达到基准的 98% 且成本远低于竞品，[[AutonomousOptimizationArchitect]] 会将流量自动路由至 Gemini
|
||||
- **Gemini Pro**：中端定位，提供能力与成本的平衡
|
||||
- 与 [[OpenAI]] 和 [[Anthropic]] 共同构成三足鼎立的 Provider 生态
|
||||
|
||||
## Key Properties
|
||||
- **Token 成本**：$0.075-0.5 / 1M tokens（Gemini Flash 极低）
|
||||
- **延迟**：低（Gemini Flash）
|
||||
- **优势**：极高的性价比，特别适合大规模、低成本推理
|
||||
|
||||
## Connections
|
||||
- [[OpenAI]] — 同为 LLM Provider
|
||||
- [[Anthropic]] — 高精度基准 Provider
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "Grafana"
|
||||
type: entity
|
||||
tags: [visualization, monitoring, dashboards, observability]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Grafana — 可视化与告警平台
|
||||
|
||||
**官方网址：** https://grafana.com/
|
||||
|
||||
**类型：** 开源项目 / 可视化平台
|
||||
|
||||
**别名：**
|
||||
- Grafana OSS
|
||||
- Grafana Labs
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Grafana 是开源的可视化和告警平台，支持从 Prometheus、VictoriaMetrics、Loki、InfluxDB、Elasticsearch 等多种数据源查询和展示时序数据，提供丰富的 Dashboard 模板和灵活的告警配置。
|
||||
|
||||
**核心特性：**
|
||||
- 多数据源支持（Prometheus、Elasticsearch、Loki、InfluxDB 等）
|
||||
- Dashboard 即代码（JSON 导出 + Git 管理）
|
||||
- 告警规则配置（支持邮件/Slack/PagerDuty 等通知渠道）
|
||||
- 用户权限管理
|
||||
- 插件生态
|
||||
|
||||
**典型部署端口：** `3000`（默认 admin/admin）
|
||||
|
||||
**常用 Dashboard ID：**
|
||||
- Node Exporter Full: `1860`
|
||||
- cAdvisor Container Metrics: `14282`
|
||||
- Blackbox Exporter Probe: `7587`
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]]
|
||||
- [[ctp-topic-42-grafana-observability-dashboard]]
|
||||
- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
|
||||
---
|
||||
title: "Grafana"
|
||||
type: entity
|
||||
tags: [visualization, monitoring, dashboards, observability]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Grafana — 可视化与告警平台
|
||||
|
||||
**官方网址：** https://grafana.com/
|
||||
|
||||
**类型：** 开源项目 / 可视化平台
|
||||
|
||||
**别名：**
|
||||
- Grafana OSS
|
||||
- Grafana Labs
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Grafana 是开源的可视化和告警平台，支持从 Prometheus、VictoriaMetrics、Loki、InfluxDB、Elasticsearch 等多种数据源查询和展示时序数据，提供丰富的 Dashboard 模板和灵活的告警配置。
|
||||
|
||||
**核心特性：**
|
||||
- 多数据源支持（Prometheus、Elasticsearch、Loki、InfluxDB 等）
|
||||
- Dashboard 即代码（JSON 导出 + Git 管理）
|
||||
- 告警规则配置（支持邮件/Slack/PagerDuty 等通知渠道）
|
||||
- 用户权限管理
|
||||
- 插件生态
|
||||
|
||||
**典型部署端口：** `3000`（默认 admin/admin）
|
||||
|
||||
**常用 Dashboard ID：**
|
||||
- Node Exporter Full: `1860`
|
||||
- cAdvisor Container Metrics: `14282`
|
||||
- Blackbox Exporter Probe: `7587`
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]]
|
||||
- [[ctp-topic-42-grafana-observability-dashboard]]
|
||||
- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
|
||||
|
||||
@@ -1,60 +1,60 @@
|
||||
---
|
||||
title: "HashiCorp"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- infrastructure
|
||||
- tools
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# HashiCorp
|
||||
|
||||
## Definition
|
||||
|
||||
HashiCorp 是全球领先的**云基础设施自动化**软件公司，总部位于旧金山，创立于 2012 年。HashiCorp 提供一套完整的基础设施生命周期管理工具，覆盖配置管理、机密管理、服务网格和网络自动化等领域。
|
||||
|
||||
## Core Products
|
||||
|
||||
| 产品 | 用途 | 类别 |
|
||||
|------|------|------|
|
||||
| **Terraform** | 云厂商无关的基础设施即代码 | IaC |
|
||||
| **Vault** | 机密管理与加密即服务 | 安全 |
|
||||
| **Nomad** | 容器和工作负载调度器 | 编排 |
|
||||
| **Consul** | 服务网格与服务发现 | 网络 |
|
||||
| **Packer** | 机器镜像构建自动化 | 镜像 |
|
||||
| **Vagrant** | 开发环境管理 | 开发环境 |
|
||||
|
||||
## Terraform
|
||||
|
||||
HashiCorp 最知名的产品。Terraform 是用 Golang 编写的云无关 IaC 工具，通过声明式 HCL（HashiCorp Configuration Language）管理跨多云和混合云环境的基础设施资源。
|
||||
|
||||
**关键特性：**
|
||||
- 云厂商无关（AWS/Azure/GCP/On-prem）
|
||||
- `terraform plan` 预览变更
|
||||
- 状态文件管理实际资源与期望状态的绑定
|
||||
- 丰富的 Provider 生态系统和 Module 市场
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Business Model
|
||||
|
||||
- **开源**：所有产品的开源版本
|
||||
- **Enterprise**：企业级功能（SSO、RBAC、审计日志、Sentinel 策略）
|
||||
- **HCP（HashiCorp Cloud Platform）**：SaaS 托管版本
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — HashiCorp 出品的核心 IaC 产品
|
||||
- [[Terragrunt]] — 第三方 Terraform 封装工具（贯彻 DRY 原则）
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — HashiCorp 产品的核心方法论
|
||||
- [[Multi-Cloud Strategy]] — Terraform 云无关定位的战略价值
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
---
|
||||
title: "HashiCorp"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- infrastructure
|
||||
- tools
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# HashiCorp
|
||||
|
||||
## Definition
|
||||
|
||||
HashiCorp 是全球领先的**云基础设施自动化**软件公司，总部位于旧金山，创立于 2012 年。HashiCorp 提供一套完整的基础设施生命周期管理工具，覆盖配置管理、机密管理、服务网格和网络自动化等领域。
|
||||
|
||||
## Core Products
|
||||
|
||||
| 产品 | 用途 | 类别 |
|
||||
|------|------|------|
|
||||
| **Terraform** | 云厂商无关的基础设施即代码 | IaC |
|
||||
| **Vault** | 机密管理与加密即服务 | 安全 |
|
||||
| **Nomad** | 容器和工作负载调度器 | 编排 |
|
||||
| **Consul** | 服务网格与服务发现 | 网络 |
|
||||
| **Packer** | 机器镜像构建自动化 | 镜像 |
|
||||
| **Vagrant** | 开发环境管理 | 开发环境 |
|
||||
|
||||
## Terraform
|
||||
|
||||
HashiCorp 最知名的产品。Terraform 是用 Golang 编写的云无关 IaC 工具，通过声明式 HCL（HashiCorp Configuration Language）管理跨多云和混合云环境的基础设施资源。
|
||||
|
||||
**关键特性：**
|
||||
- 云厂商无关（AWS/Azure/GCP/On-prem）
|
||||
- `terraform plan` 预览变更
|
||||
- 状态文件管理实际资源与期望状态的绑定
|
||||
- 丰富的 Provider 生态系统和 Module 市场
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Business Model
|
||||
|
||||
- **开源**：所有产品的开源版本
|
||||
- **Enterprise**：企业级功能（SSO、RBAC、审计日志、Sentinel 策略）
|
||||
- **HCP（HashiCorp Cloud Platform）**：SaaS 托管版本
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — HashiCorp 出品的核心 IaC 产品
|
||||
- [[Terragrunt]] — 第三方 Terraform 封装工具（贯彻 DRY 原则）
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — HashiCorp 产品的核心方法论
|
||||
- [[Multi-Cloud Strategy]] — Terraform 云无关定位的战略价值
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
@@ -1,77 +1,77 @@
|
||||
---
|
||||
title: "Jellyfin"
|
||||
type: entity
|
||||
tags: [video, media-server, self-hosted, open-source, docker]
|
||||
date: 2026-04-14
|
||||
sources: [用docker安装jellyfin, 用docker中安装navidrome]
|
||||
---
|
||||
|
||||
# Jellyfin
|
||||
|
||||
开源视频媒体服务器，提供网页端流媒体播放、管理界面和转码能力。
|
||||
|
||||
## Aliases
|
||||
- Jellyfin Media Server
|
||||
- Jellyfin Server
|
||||
|
||||
## Type
|
||||
开源自托管视频流媒体服务器（Emby 分支）
|
||||
|
||||
## Core Functionality
|
||||
- 视频播放与管理，支持电影、电视剧、体育节目等多种媒体类型
|
||||
- 硬件加速视频转码（Intel QuickSync / NVIDIA GPU / VA-API / AMD VCE）
|
||||
- 元数据刮削（TMDB/TheTVDB 等）
|
||||
- 多用户支持与播放进度追踪
|
||||
- DLNA / Chromecast / Apple TV / Roku 等设备投射
|
||||
- Web UI + 官方客户端（Android / iOS / TV 版）
|
||||
|
||||
## Key Images
|
||||
| 镜像 | 维护者 | 特点 |
|
||||
|------|--------|------|
|
||||
| linuxserver/jellyfin | LinuxServer.io | 官方稳定版 |
|
||||
| nyanmisaka/jellyfin | 社区维护 | 预装优化 FFmpeg，硬件转码开箱即用 |
|
||||
|
||||
## Docker 配置关键参数（nyanmisaka 镜像）
|
||||
```yaml
|
||||
services:
|
||||
jellyfin:
|
||||
image: nyanmisaka/jellyfin:latest
|
||||
user: "1026:100" # 群晖 UID:GID
|
||||
ports:
|
||||
- 8096:8096/tcp # Web UI
|
||||
- 7359:7359/udp # 自动发现
|
||||
volumes:
|
||||
- /volume1/docker/jellyfin/config:/config
|
||||
- /volume1/docker/jellyfin/cache:/cache
|
||||
- /volume2/movie:/media
|
||||
- "/volume1/TV shows:/media2"
|
||||
- /volume1/docker/jellyfin/fonts:/usr/local/share/fonts/custom:ro
|
||||
environment:
|
||||
- JELLYFIN_PublishedServerUrl=http://jellyfin.ishenwei.online
|
||||
- TZ=Asia/Shanghai
|
||||
devices:
|
||||
- /dev/dri:/dev/dri # Intel QuickSync 硬件转码
|
||||
restart: unless-stopped
|
||||
extra_hosts:
|
||||
- 'host.docker.internal:host-gateway'
|
||||
```
|
||||
|
||||
## Hardware Transcoding
|
||||
- **Intel QuickSync**：通过 `/dev/dri` 设备直通，nyanmisaka 镜像预装支持
|
||||
- **NVIDIA GPU**：需 nvidia-container-toolkit
|
||||
- **软件转码**：ffmpeg fallback，适合低功耗设备
|
||||
|
||||
## 性能考量
|
||||
- 媒体转码建议内存 2-4GB
|
||||
- 群晖 NAS 上优先使用 QuickSync / VA-API 硬件转码以降低 CPU 占用
|
||||
- cache 目录建议 SSD 以提升元数据和缩略图读写性能
|
||||
|
||||
## Connections
|
||||
- [[Transmission]] ← 下载端 → [[Jellyfin]]（播放端）— "下载→整理→播放" 家庭媒体工作流
|
||||
- [[Navidrome]] ← 对标竞品 → [[Jellyfin]] — Navidrome 服务音乐，Jellyfin 服务视频
|
||||
- [[群晖 NAS]] ← 宿主机 → [[Jellyfin]] — NAS 提供存储和 Docker 运行环境
|
||||
- [[nyanmisaka/jellyfin]] ← 优化镜像 → [[Jellyfin]] — 预装硬件转码支持的社区镜像
|
||||
- [[LinuxServer.io]] ← 官方镜像 → [[Jellyfin]] — 稳定版官方镜像维护组织
|
||||
|
||||
## Sources
|
||||
- [[用docker安装jellyfin]] — 在群晖 NAS 上部署 Jellyfin 的完整 Docker Compose 配置
|
||||
---
|
||||
title: "Jellyfin"
|
||||
type: entity
|
||||
tags: [video, media-server, self-hosted, open-source, docker]
|
||||
date: 2026-04-14
|
||||
sources: [用docker安装jellyfin, 用docker中安装navidrome]
|
||||
---
|
||||
|
||||
# Jellyfin
|
||||
|
||||
开源视频媒体服务器，提供网页端流媒体播放、管理界面和转码能力。
|
||||
|
||||
## Aliases
|
||||
- Jellyfin Media Server
|
||||
- Jellyfin Server
|
||||
|
||||
## Type
|
||||
开源自托管视频流媒体服务器（Emby 分支）
|
||||
|
||||
## Core Functionality
|
||||
- 视频播放与管理，支持电影、电视剧、体育节目等多种媒体类型
|
||||
- 硬件加速视频转码（Intel QuickSync / NVIDIA GPU / VA-API / AMD VCE）
|
||||
- 元数据刮削（TMDB/TheTVDB 等）
|
||||
- 多用户支持与播放进度追踪
|
||||
- DLNA / Chromecast / Apple TV / Roku 等设备投射
|
||||
- Web UI + 官方客户端（Android / iOS / TV 版）
|
||||
|
||||
## Key Images
|
||||
| 镜像 | 维护者 | 特点 |
|
||||
|------|--------|------|
|
||||
| linuxserver/jellyfin | LinuxServer.io | 官方稳定版 |
|
||||
| nyanmisaka/jellyfin | 社区维护 | 预装优化 FFmpeg，硬件转码开箱即用 |
|
||||
|
||||
## Docker 配置关键参数（nyanmisaka 镜像）
|
||||
```yaml
|
||||
services:
|
||||
jellyfin:
|
||||
image: nyanmisaka/jellyfin:latest
|
||||
user: "1026:100" # 群晖 UID:GID
|
||||
ports:
|
||||
- 8096:8096/tcp # Web UI
|
||||
- 7359:7359/udp # 自动发现
|
||||
volumes:
|
||||
- /volume1/docker/jellyfin/config:/config
|
||||
- /volume1/docker/jellyfin/cache:/cache
|
||||
- /volume2/movie:/media
|
||||
- "/volume1/TV shows:/media2"
|
||||
- /volume1/docker/jellyfin/fonts:/usr/local/share/fonts/custom:ro
|
||||
environment:
|
||||
- JELLYFIN_PublishedServerUrl=http://jellyfin.ishenwei.online
|
||||
- TZ=Asia/Shanghai
|
||||
devices:
|
||||
- /dev/dri:/dev/dri # Intel QuickSync 硬件转码
|
||||
restart: unless-stopped
|
||||
extra_hosts:
|
||||
- 'host.docker.internal:host-gateway'
|
||||
```
|
||||
|
||||
## Hardware Transcoding
|
||||
- **Intel QuickSync**：通过 `/dev/dri` 设备直通，nyanmisaka 镜像预装支持
|
||||
- **NVIDIA GPU**：需 nvidia-container-toolkit
|
||||
- **软件转码**：ffmpeg fallback，适合低功耗设备
|
||||
|
||||
## 性能考量
|
||||
- 媒体转码建议内存 2-4GB
|
||||
- 群晖 NAS 上优先使用 QuickSync / VA-API 硬件转码以降低 CPU 占用
|
||||
- cache 目录建议 SSD 以提升元数据和缩略图读写性能
|
||||
|
||||
## Connections
|
||||
- [[Transmission]] ← 下载端 → [[Jellyfin]]（播放端）— "下载→整理→播放" 家庭媒体工作流
|
||||
- [[Navidrome]] ← 对标竞品 → [[Jellyfin]] — Navidrome 服务音乐，Jellyfin 服务视频
|
||||
- [[群晖 NAS]] ← 宿主机 → [[Jellyfin]] — NAS 提供存储和 Docker 运行环境
|
||||
- [[nyanmisaka/jellyfin]] ← 优化镜像 → [[Jellyfin]] — 预装硬件转码支持的社区镜像
|
||||
- [[LinuxServer.io]] ← 官方镜像 → [[Jellyfin]] — 稳定版官方镜像维护组织
|
||||
|
||||
## Sources
|
||||
- [[用docker安装jellyfin]] — 在群晖 NAS 上部署 Jellyfin 的完整 Docker Compose 配置
|
||||
|
||||
@@ -1,114 +1,114 @@
|
||||
---
|
||||
title: "Kubernetes"
|
||||
type: entity
|
||||
tags:
|
||||
- cloud
|
||||
- container
|
||||
- orchestration
|
||||
- devops
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
created: 2026-04-25
|
||||
---
|
||||
|
||||
# Kubernetes
|
||||
|
||||
## Definition
|
||||
|
||||
Kubernetes (K8s) 是 Google 开源的**容器编排平台**，用于自动化容器化应用的部署、扩缩容和管理。是云原生 (Cloud-Native) 架构的核心基础设施，也是 Agentic AI 自主修复 (Self-Healing) 的主要目标环境。
|
||||
|
||||
## Aliases
|
||||
|
||||
- K8s
|
||||
- Kubernetes
|
||||
- Container Orchestration Platform
|
||||
|
||||
## Major Cloud Implementations
|
||||
|
||||
| Provider | Service | Description |
|
||||
|----------|---------|-------------|
|
||||
| AWS | EKS (Elastic Kubernetes Service) | 托管 Kubernetes on AWS |
|
||||
| GCP | GKE (Google Kubernetes Engine) | 托管 Kubernetes on GCP |
|
||||
| Azure | AKS (Azure Kubernetes Service) | 托管 Kubernetes on Azure |
|
||||
|
||||
## Kubernetes Self-Healing Capabilities
|
||||
|
||||
Kubernetes 原生提供基础 Self-Healing 能力：
|
||||
|
||||
```yaml
|
||||
# Kubernetes Self-Healing 原生机制
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
spec:
|
||||
replicas: 3
|
||||
strategy:
|
||||
type: RollingUpdate
|
||||
template:
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 30
|
||||
# 内置机制:
|
||||
# - 自动重启失败的容器
|
||||
# - 替换不健康的 Pod
|
||||
# - 滚动更新确保服务可用
|
||||
```
|
||||
|
||||
Agentic AI 在原生能力基础上提供**更高级的自我修复**：
|
||||
|
||||
| 能力 | Kubernetes 原生 | Agentic AI Enhanced |
|
||||
|------|---------------|-------------------|
|
||||
| Pod 重启 | ✅ 自动重启崩溃容器 | ✅ 智能分析根因 + 预防性重启 |
|
||||
| 扩缩容 | ✅ HPA 基于指标 | ✅ 预测性扩缩容 |
|
||||
| 节点恢复 | ✅ 节点故障迁移 | ✅ 主动健康检查 + 预防性迁移 |
|
||||
| 配置修复 | ❌ 需人工介入 | ✅ AI 自动修正 ConfigMap/Secret |
|
||||
|
||||
## Agentic AI Monitoring Targets
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Agentic AI for Kubernetes │
|
||||
├─────────────────────────────────────────────────┤
|
||||
│ 监控层 │
|
||||
│ ├── Pod Metrics (CPU/Memory/Network) │
|
||||
│ ├── Workload Health (Deployment/ReplicaSet) │
|
||||
│ ├── Node Status (Ready/Condition) │
|
||||
│ └── Cluster Components (etcd, API Server) │
|
||||
│ │
|
||||
│ 决策层 │
|
||||
│ ├── Anomaly Detection (AI) │
|
||||
│ ├── Root Cause Analysis (AI) │
|
||||
│ └── Action Planning (AI) │
|
||||
│ │
|
||||
│ 执行层 │
|
||||
│ ├── kubectl API (restart/migrate/scale) │
|
||||
│ ├── HPA Override (AI-driven scaling) │
|
||||
│ └── Config Updates (AI-driven fixes) │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
> An AI agent monitoring AWS EKS clusters detects high CPU usage due to a rogue pod:
|
||||
> - Pod `payment-service-v2-abc123` CPU usage: 95%
|
||||
> - AI correlates with recent deployment timestamp
|
||||
> - AI identifies: Memory leak in new version
|
||||
> - AI Actions:
|
||||
> 1. Scale deployment to 3 replicas (distribute load)
|
||||
> 2. Create rollback ticket
|
||||
> 3. Notify team via Slack
|
||||
> 4. Auto-rollback after approval
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Self-Healing Systems]] — Kubernetes 是 Self-Healing 的主要载体
|
||||
- [[Cloud-Native]] — Kubernetes 是 Cloud-Native 的核心
|
||||
- [[Deployment Automation]] — Kubernetes 部署的自动化
|
||||
- [[Container Lifecycle Hardening]] — 容器安全加固
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Agentic AI]] — Kubernetes 是 Agentic AI 的管理对象
|
||||
- EKS, GKE, AKS — 具体云服务商实现
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[how-agentic-ai-can-help-for-cloud-devops]]
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]]
|
||||
---
|
||||
title: "Kubernetes"
|
||||
type: entity
|
||||
tags:
|
||||
- cloud
|
||||
- container
|
||||
- orchestration
|
||||
- devops
|
||||
sources: [cloud-operating-model-key-strategies-and-best-practices]
|
||||
created: 2026-04-25
|
||||
---
|
||||
|
||||
# Kubernetes
|
||||
|
||||
## Definition
|
||||
|
||||
Kubernetes (K8s) 是 Google 开源的**容器编排平台**，用于自动化容器化应用的部署、扩缩容和管理。是云原生 (Cloud-Native) 架构的核心基础设施，也是 Agentic AI 自主修复 (Self-Healing) 的主要目标环境。
|
||||
|
||||
## Aliases
|
||||
|
||||
- K8s
|
||||
- Kubernetes
|
||||
- Container Orchestration Platform
|
||||
|
||||
## Major Cloud Implementations
|
||||
|
||||
| Provider | Service | Description |
|
||||
|----------|---------|-------------|
|
||||
| AWS | EKS (Elastic Kubernetes Service) | 托管 Kubernetes on AWS |
|
||||
| GCP | GKE (Google Kubernetes Engine) | 托管 Kubernetes on GCP |
|
||||
| Azure | AKS (Azure Kubernetes Service) | 托管 Kubernetes on Azure |
|
||||
|
||||
## Kubernetes Self-Healing Capabilities
|
||||
|
||||
Kubernetes 原生提供基础 Self-Healing 能力：
|
||||
|
||||
```yaml
|
||||
# Kubernetes Self-Healing 原生机制
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
spec:
|
||||
replicas: 3
|
||||
strategy:
|
||||
type: RollingUpdate
|
||||
template:
|
||||
spec:
|
||||
terminationGracePeriodSeconds: 30
|
||||
# 内置机制:
|
||||
# - 自动重启失败的容器
|
||||
# - 替换不健康的 Pod
|
||||
# - 滚动更新确保服务可用
|
||||
```
|
||||
|
||||
Agentic AI 在原生能力基础上提供**更高级的自我修复**：
|
||||
|
||||
| 能力 | Kubernetes 原生 | Agentic AI Enhanced |
|
||||
|------|---------------|-------------------|
|
||||
| Pod 重启 | ✅ 自动重启崩溃容器 | ✅ 智能分析根因 + 预防性重启 |
|
||||
| 扩缩容 | ✅ HPA 基于指标 | ✅ 预测性扩缩容 |
|
||||
| 节点恢复 | ✅ 节点故障迁移 | ✅ 主动健康检查 + 预防性迁移 |
|
||||
| 配置修复 | ❌ 需人工介入 | ✅ AI 自动修正 ConfigMap/Secret |
|
||||
|
||||
## Agentic AI Monitoring Targets
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────┐
|
||||
│ Agentic AI for Kubernetes │
|
||||
├─────────────────────────────────────────────────┤
|
||||
│ 监控层 │
|
||||
│ ├── Pod Metrics (CPU/Memory/Network) │
|
||||
│ ├── Workload Health (Deployment/ReplicaSet) │
|
||||
│ ├── Node Status (Ready/Condition) │
|
||||
│ └── Cluster Components (etcd, API Server) │
|
||||
│ │
|
||||
│ 决策层 │
|
||||
│ ├── Anomaly Detection (AI) │
|
||||
│ ├── Root Cause Analysis (AI) │
|
||||
│ └── Action Planning (AI) │
|
||||
│ │
|
||||
│ 执行层 │
|
||||
│ ├── kubectl API (restart/migrate/scale) │
|
||||
│ ├── HPA Override (AI-driven scaling) │
|
||||
│ └── Config Updates (AI-driven fixes) │
|
||||
└─────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
> An AI agent monitoring AWS EKS clusters detects high CPU usage due to a rogue pod:
|
||||
> - Pod `payment-service-v2-abc123` CPU usage: 95%
|
||||
> - AI correlates with recent deployment timestamp
|
||||
> - AI identifies: Memory leak in new version
|
||||
> - AI Actions:
|
||||
> 1. Scale deployment to 3 replicas (distribute load)
|
||||
> 2. Create rollback ticket
|
||||
> 3. Notify team via Slack
|
||||
> 4. Auto-rollback after approval
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Self-Healing Systems]] — Kubernetes 是 Self-Healing 的主要载体
|
||||
- [[Cloud-Native]] — Kubernetes 是 Cloud-Native 的核心
|
||||
- [[Deployment Automation]] — Kubernetes 部署的自动化
|
||||
- [[Container Lifecycle Hardening]] — 容器安全加固
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Agentic AI]] — Kubernetes 是 Agentic AI 的管理对象
|
||||
- EKS, GKE, AKS — 具体云服务商实现
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[how-agentic-ai-can-help-for-cloud-devops]]
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]]
|
||||
|
||||
@@ -1,35 +1,35 @@
|
||||
# MerlinClash插件
|
||||
|
||||
## Aliases
|
||||
- MerlinClash
|
||||
- 小猫咪插件
|
||||
- Merlin-Clash
|
||||
- MC
|
||||
|
||||
## Basic Info
|
||||
- **Type**: 梅林固件科学上网插件（第三方）
|
||||
- **Platform**: 梅林固件（ASUSWRT-Merlin）
|
||||
- **Engine**: Clash 核心
|
||||
- **Language**: 中文社区维护
|
||||
|
||||
## Description
|
||||
MerlinClash（又称"小猫咪插件"）是基于 Clash 核心的梅林固件科学上网插件，支持策略组分流、节点自动延迟测试和故障转移。相比同类插件（如科学上网插件 GitHub 版），功能更全面，是梅林固件上推荐使用的科学上网解决方案。
|
||||
|
||||
## Key Features
|
||||
- 策略组分流（按应用/地区/目标自动路由）
|
||||
- 节点自动延迟测试（定时 ping 测速）
|
||||
- 故障转移（主节点不可用时自动切换备用节点）
|
||||
- 订阅地址自动更新（定时抓取机场订阅）
|
||||
- 守护进程（保证插件持续稳定运行）
|
||||
- 支持 SSR/V2Ray/Trojan 等多协议
|
||||
|
||||
## Known Limitations
|
||||
- 与其他科学上网插件不可同时运行（二选一）
|
||||
- 需要足够 JFFS 分区空间（建议 Full 版本，内存充足时）
|
||||
|
||||
## Related
|
||||
- [[梅林固件]] — 插件运行平台
|
||||
- [[网件RAX50]] — 典型支持路由器
|
||||
- [[策略组分流]] — 插件核心功能
|
||||
- [[故障转移]] — 配套可靠性机制
|
||||
- [[订阅机制]] — 节点配置来源
|
||||
# MerlinClash插件
|
||||
|
||||
## Aliases
|
||||
- MerlinClash
|
||||
- 小猫咪插件
|
||||
- Merlin-Clash
|
||||
- MC
|
||||
|
||||
## Basic Info
|
||||
- **Type**: 梅林固件科学上网插件（第三方）
|
||||
- **Platform**: 梅林固件（ASUSWRT-Merlin）
|
||||
- **Engine**: Clash 核心
|
||||
- **Language**: 中文社区维护
|
||||
|
||||
## Description
|
||||
MerlinClash（又称"小猫咪插件"）是基于 Clash 核心的梅林固件科学上网插件，支持策略组分流、节点自动延迟测试和故障转移。相比同类插件（如科学上网插件 GitHub 版），功能更全面，是梅林固件上推荐使用的科学上网解决方案。
|
||||
|
||||
## Key Features
|
||||
- 策略组分流（按应用/地区/目标自动路由）
|
||||
- 节点自动延迟测试（定时 ping 测速）
|
||||
- 故障转移（主节点不可用时自动切换备用节点）
|
||||
- 订阅地址自动更新（定时抓取机场订阅）
|
||||
- 守护进程（保证插件持续稳定运行）
|
||||
- 支持 SSR/V2Ray/Trojan 等多协议
|
||||
|
||||
## Known Limitations
|
||||
- 与其他科学上网插件不可同时运行（二选一）
|
||||
- 需要足够 JFFS 分区空间（建议 Full 版本，内存充足时）
|
||||
|
||||
## Related
|
||||
- [[梅林固件]] — 插件运行平台
|
||||
- [[网件RAX50]] — 典型支持路由器
|
||||
- [[策略组分流]] — 插件核心功能
|
||||
- [[故障转移]] — 配套可靠性机制
|
||||
- [[订阅机制]] — 节点配置来源
|
||||
|
||||
@@ -1,60 +1,60 @@
|
||||
---
|
||||
title: "Navidrome"
|
||||
type: entity
|
||||
aliases: []
|
||||
tags: [music, media-server, self-hosted, open-source]
|
||||
sources: [用docker中安装navidrome]
|
||||
---
|
||||
|
||||
# Navidrome
|
||||
|
||||
## Basic Info
|
||||
- **Type**: Entity / Product / Open-source Project
|
||||
- **Description**: 开源音乐流媒体服务器，支持 Subsonic API 协议，可通过网页端或移动客户端访问个人音乐库
|
||||
- **Author**: Deluan
|
||||
- **Repository**: github.com/navidrome/navidrome
|
||||
- **License**: GPL v3
|
||||
|
||||
## Aliases
|
||||
- Navidrome
|
||||
- deluan/navidrome（Docker 镜像名）
|
||||
|
||||
## Key Capabilities
|
||||
1. **Subsonic API 兼容** — 与 Subsonic 协议兼容的客户端均可使用（Jellyfin/Subsonic 客户端通用）
|
||||
2. **网页播放器** — 内置响应式 Web UI，支持播放列表、专辑浏览、搜索
|
||||
3. **移动端支持** — 支持 DSub、Substreamer、Avanté 等 Subsonic 客户端
|
||||
4. **转码支持** — 按客户端网络情况自动转码为合适码率，节省带宽
|
||||
5. **元数据扫描** — 自动从音乐文件中读取 ID3 标签、封面信息
|
||||
6. **轻量部署** — 单 Docker 容器运行，最低 512MB 内存即可运行
|
||||
|
||||
## Configuration Highlights (Docker Compose)
|
||||
```yaml
|
||||
image: deluan/navidrome:latest
|
||||
user: "1026:100" # 以非 root 用户运行
|
||||
ports:
|
||||
- "4533:4533"
|
||||
volumes:
|
||||
- /volume1/music:/music:ro # 只读挂载音乐目录
|
||||
- /volume1/docker/navidrome/data:/data # 数据目录
|
||||
environment:
|
||||
- ND_LOGLEVEL=info
|
||||
- ND_ENABLETRANSCODINGCONFIG=true # 启用转码配置 UI
|
||||
- ND_AUTOTRANSCODEDOWNLOAD=true # 启用自动转码下载
|
||||
- ND_TRANSCODINGCACHESIZE=200MB # 转码缓存上限 200MB
|
||||
```
|
||||
|
||||
## Key Design Decisions
|
||||
- **只读音乐挂载（`:ro`）** — 防止容器误操作修改原始音乐文件
|
||||
- **非 root 用户运行** — 提升容器安全性，UID/GID 与宿主机用户对应
|
||||
- **转码缓存限制** — 200MB 上限防止磁盘空间被缓存占满
|
||||
- **端口 4533** — Navidrome 默认端口，局域网访问地址：`http://<host>:4533`
|
||||
|
||||
## Related Entities
|
||||
- [[Jellyfin]] — 视频媒体服务器，架构类似但服务视频内容
|
||||
- [[群晖 NAS]] — Navidrome 常见部署环境，音乐文件的存储位置
|
||||
- [[Docker-Image]] — Navidrome 的部署方式
|
||||
- [[Docker Compose]] — Navidrome 的配置管理方式
|
||||
- [[Deluan/Navidrome]] — 官方 Docker 镜像发布者
|
||||
|
||||
## Source
|
||||
- [[用docker中安装navidrome]] — Navidrome Docker 部署实战笔记
|
||||
---
|
||||
title: "Navidrome"
|
||||
type: entity
|
||||
aliases: []
|
||||
tags: [music, media-server, self-hosted, open-source]
|
||||
sources: [用docker中安装navidrome]
|
||||
---
|
||||
|
||||
# Navidrome
|
||||
|
||||
## Basic Info
|
||||
- **Type**: Entity / Product / Open-source Project
|
||||
- **Description**: 开源音乐流媒体服务器，支持 Subsonic API 协议，可通过网页端或移动客户端访问个人音乐库
|
||||
- **Author**: Deluan
|
||||
- **Repository**: github.com/navidrome/navidrome
|
||||
- **License**: GPL v3
|
||||
|
||||
## Aliases
|
||||
- Navidrome
|
||||
- deluan/navidrome（Docker 镜像名）
|
||||
|
||||
## Key Capabilities
|
||||
1. **Subsonic API 兼容** — 与 Subsonic 协议兼容的客户端均可使用（Jellyfin/Subsonic 客户端通用）
|
||||
2. **网页播放器** — 内置响应式 Web UI，支持播放列表、专辑浏览、搜索
|
||||
3. **移动端支持** — 支持 DSub、Substreamer、Avanté 等 Subsonic 客户端
|
||||
4. **转码支持** — 按客户端网络情况自动转码为合适码率，节省带宽
|
||||
5. **元数据扫描** — 自动从音乐文件中读取 ID3 标签、封面信息
|
||||
6. **轻量部署** — 单 Docker 容器运行，最低 512MB 内存即可运行
|
||||
|
||||
## Configuration Highlights (Docker Compose)
|
||||
```yaml
|
||||
image: deluan/navidrome:latest
|
||||
user: "1026:100" # 以非 root 用户运行
|
||||
ports:
|
||||
- "4533:4533"
|
||||
volumes:
|
||||
- /volume1/music:/music:ro # 只读挂载音乐目录
|
||||
- /volume1/docker/navidrome/data:/data # 数据目录
|
||||
environment:
|
||||
- ND_LOGLEVEL=info
|
||||
- ND_ENABLETRANSCODINGCONFIG=true # 启用转码配置 UI
|
||||
- ND_AUTOTRANSCODEDOWNLOAD=true # 启用自动转码下载
|
||||
- ND_TRANSCODINGCACHESIZE=200MB # 转码缓存上限 200MB
|
||||
```
|
||||
|
||||
## Key Design Decisions
|
||||
- **只读音乐挂载（`:ro`）** — 防止容器误操作修改原始音乐文件
|
||||
- **非 root 用户运行** — 提升容器安全性，UID/GID 与宿主机用户对应
|
||||
- **转码缓存限制** — 200MB 上限防止磁盘空间被缓存占满
|
||||
- **端口 4533** — Navidrome 默认端口，局域网访问地址：`http://<host>:4533`
|
||||
|
||||
## Related Entities
|
||||
- [[Jellyfin]] — 视频媒体服务器，架构类似但服务视频内容
|
||||
- [[群晖 NAS]] — Navidrome 常见部署环境，音乐文件的存储位置
|
||||
- [[Docker-Image]] — Navidrome 的部署方式
|
||||
- [[Docker Compose]] — Navidrome 的配置管理方式
|
||||
- [[Deluan/Navidrome]] — 官方 Docker 镜像发布者
|
||||
|
||||
## Source
|
||||
- [[用docker中安装navidrome]] — Navidrome Docker 部署实战笔记
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "Node Exporter"
|
||||
type: entity
|
||||
tags: [monitoring, exporter, prometheus, devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Node Exporter — Prometheus 主机指标采集器
|
||||
|
||||
**官方网址：** https://prometheus.io/docs/guides/node-exporter/
|
||||
|
||||
**类型：** 开源项目 / Prometheus Exporter
|
||||
|
||||
**别名：**
|
||||
- prometheus-node-exporter
|
||||
- node_exporter
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Node Exporter 是 Prometheus 官方提供的 exporter，用于采集主机（服务器/NAS/树莓派等）的硬件和操作系统指标。以 DaemonSet 或独立进程方式运行，采集 CPU、内存、磁盘、网络、文件系统等数据。
|
||||
|
||||
**采集指标示例：**
|
||||
- `node_cpu_seconds_total` — CPU 使用时间
|
||||
- `node_memory_MemAvailable_bytes` — 可用内存
|
||||
- `node_memory_MemTotal_bytes` — 总内存
|
||||
- `node_filesystem_avail_bytes` — 文件系统可用空间
|
||||
- `node_network_receive_bytes_total` — 网络接收字节
|
||||
- `node_load1` / `node_load5` / `node_load15` — 系统负载
|
||||
|
||||
**典型部署：**
|
||||
- Docker: `prom/node-exporter:latest`，需 `network_mode: host` + volume 挂载 `/proc`、`/sys`、`/`
|
||||
- 端口：`9100`
|
||||
|
||||
**关键告警规则示例：**
|
||||
- 磁盘剩余 < 10%: `node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.10`
|
||||
- CPU 使用率 > 85%: `avg(rate(node_cpu_seconds_total{mode="user"}[2m])) * 100 > 85`
|
||||
- 内存可用 < 15%: `node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15`
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
---
|
||||
title: "Node Exporter"
|
||||
type: entity
|
||||
tags: [monitoring, exporter, prometheus, devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Node Exporter — Prometheus 主机指标采集器
|
||||
|
||||
**官方网址：** https://prometheus.io/docs/guides/node-exporter/
|
||||
|
||||
**类型：** 开源项目 / Prometheus Exporter
|
||||
|
||||
**别名：**
|
||||
- prometheus-node-exporter
|
||||
- node_exporter
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Node Exporter 是 Prometheus 官方提供的 exporter，用于采集主机（服务器/NAS/树莓派等）的硬件和操作系统指标。以 DaemonSet 或独立进程方式运行，采集 CPU、内存、磁盘、网络、文件系统等数据。
|
||||
|
||||
**采集指标示例：**
|
||||
- `node_cpu_seconds_total` — CPU 使用时间
|
||||
- `node_memory_MemAvailable_bytes` — 可用内存
|
||||
- `node_memory_MemTotal_bytes` — 总内存
|
||||
- `node_filesystem_avail_bytes` — 文件系统可用空间
|
||||
- `node_network_receive_bytes_total` — 网络接收字节
|
||||
- `node_load1` / `node_load5` / `node_load15` — 系统负载
|
||||
|
||||
**典型部署：**
|
||||
- Docker: `prom/node-exporter:latest`，需 `network_mode: host` + volume 挂载 `/proc`、`/sys`、`/`
|
||||
- 端口：`9100`
|
||||
|
||||
**关键告警规则示例：**
|
||||
- 磁盘剩余 < 10%: `node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.10`
|
||||
- CPU 使用率 > 85%: `avg(rate(node_cpu_seconds_total{mode="user"}[2m])) * 100 > 85`
|
||||
- 内存可用 < 15%: `node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15`
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "OWASP"
|
||||
type: entity
|
||||
tags: [security, web-security, standards, devsecops]
|
||||
sources: ["what-is-devsecops-best-practices-benefits-and-tools"]
|
||||
last_updated: 2025-12-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
OWASP（Open Web Application Security Project，开放式 Web 应用安全项目）是一个开源的社区驱动的非营利组织，专注于提高软件安全性。OWASP 是全球应用安全领域最具影响力的社区之一，其工具、标准和技术文档被广泛应用于 [[DevSecOps]] 实践中。
|
||||
|
||||
## Key Deliverables
|
||||
|
||||
### OWASP Top Ten
|
||||
最知名的 OWASP 项目，列出 Web 应用最关键的 10 大安全风险，是 [[DevSecOps]] 安全测试的核心参考标准：
|
||||
1. Broken Access Control（访问控制失效）
|
||||
2. Cryptographic Failures（加密失败）
|
||||
3. Injection（注入攻击）
|
||||
4. Insecure Design（不安全设计）
|
||||
5. Security Misconfiguration（安全配置错误）
|
||||
6. Vulnerable and Outdated Components（易受攻击和过时的组件）
|
||||
7. Identification and Authentication Failures（识别和身份验证失败）
|
||||
8. Software and Data Integrity Failures（软件和数据完整性失败）
|
||||
9. Security Logging and Monitoring Failures（安全日志和监控失败）
|
||||
10. Server-Side Request Forgery（服务器端请求伪造）
|
||||
|
||||
### Other Key Projects
|
||||
- **OWASP ZAP**：开源 Web 应用安全扫描器（[[DAST]] 工具）
|
||||
- **OWASP ASVS**：应用安全验证标准
|
||||
- **OWASP SAMM**：软件保证成熟度模型
|
||||
- **OWASP Dependency-Check**：SCA 工具（[[SCA]]）
|
||||
|
||||
## Role in DevSecOps
|
||||
|
||||
在 [[DevSecOps]] 中，OWASP 提供：
|
||||
- [[DAST]] 测试的漏洞分类标准
|
||||
- [[SAST]] 工具的规则开发参考
|
||||
- 安全编码标准和最佳实践
|
||||
- 开源安全测试工具
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[DevSecOps]] — OWASP 是 DevSecOps 工具链的核心参考
|
||||
- [[DAST]] — OWASP ZAP 是主流 DAST 工具
|
||||
- [[SAST]] — OWASP 提供安全编码标准
|
||||
- [[OWASP Top Ten]] — Web 应用安全风险的权威列表
|
||||
---
|
||||
title: "OWASP"
|
||||
type: entity
|
||||
tags: [security, web-security, standards, devsecops]
|
||||
sources: ["what-is-devsecops-best-practices-benefits-and-tools"]
|
||||
last_updated: 2025-12-19
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
OWASP（Open Web Application Security Project，开放式 Web 应用安全项目）是一个开源的社区驱动的非营利组织，专注于提高软件安全性。OWASP 是全球应用安全领域最具影响力的社区之一，其工具、标准和技术文档被广泛应用于 [[DevSecOps]] 实践中。
|
||||
|
||||
## Key Deliverables
|
||||
|
||||
### OWASP Top Ten
|
||||
最知名的 OWASP 项目，列出 Web 应用最关键的 10 大安全风险，是 [[DevSecOps]] 安全测试的核心参考标准：
|
||||
1. Broken Access Control（访问控制失效）
|
||||
2. Cryptographic Failures（加密失败）
|
||||
3. Injection（注入攻击）
|
||||
4. Insecure Design（不安全设计）
|
||||
5. Security Misconfiguration（安全配置错误）
|
||||
6. Vulnerable and Outdated Components（易受攻击和过时的组件）
|
||||
7. Identification and Authentication Failures（识别和身份验证失败）
|
||||
8. Software and Data Integrity Failures（软件和数据完整性失败）
|
||||
9. Security Logging and Monitoring Failures（安全日志和监控失败）
|
||||
10. Server-Side Request Forgery（服务器端请求伪造）
|
||||
|
||||
### Other Key Projects
|
||||
- **OWASP ZAP**：开源 Web 应用安全扫描器（[[DAST]] 工具）
|
||||
- **OWASP ASVS**：应用安全验证标准
|
||||
- **OWASP SAMM**：软件保证成熟度模型
|
||||
- **OWASP Dependency-Check**：SCA 工具（[[SCA]]）
|
||||
|
||||
## Role in DevSecOps
|
||||
|
||||
在 [[DevSecOps]] 中，OWASP 提供：
|
||||
- [[DAST]] 测试的漏洞分类标准
|
||||
- [[SAST]] 工具的规则开发参考
|
||||
- 安全编码标准和最佳实践
|
||||
- 开源安全测试工具
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[DevSecOps]] — OWASP 是 DevSecOps 工具链的核心参考
|
||||
- [[DAST]] — OWASP ZAP 是主流 DAST 工具
|
||||
- [[SAST]] — OWASP 提供安全编码标准
|
||||
- [[OWASP Top Ten]] — Web 应用安全风险的权威列表
|
||||
|
||||
@@ -1,27 +1,27 @@
|
||||
---
|
||||
title: "OpenAI"
|
||||
type: entity
|
||||
tags: ["llm-provider", "openai"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- OpenAI
|
||||
- OpenAI Inc.
|
||||
|
||||
## Definition
|
||||
OpenAI 是主要的 LLM Provider 之一，提供 GPT 系列模型（GPT-4、GPT-4o、GPT-3.5 Turbo 等）。在 [[AutonomousOptimizationArchitect]] 系统中作为主要候选 Provider 之一参与性能排名和流量路由竞争。
|
||||
|
||||
## Role in LLM Routing
|
||||
- 提供多种规模的模型供 [[AutonomousOptimizationArchitect]] 按任务类型分配
|
||||
- 模型历史性能（token 延迟、幻觉率、成本）被 [[AutonomousOptimizationArchitect]] 持续追踪并纳入 Provider 排名
|
||||
|
||||
## Key Properties
|
||||
- **Token 成本**：$2.5-15 / 1M tokens（因模型而异）
|
||||
- **延迟**：中等至高（取决于模型规模）
|
||||
- **常见用途**：代码生成、复杂推理、长文档处理
|
||||
|
||||
## Connections
|
||||
- [[Anthropic]] — 同为 LLM Provider，竞争关系，共同参与 [[SemanticRouting]]
|
||||
- [[GoogleGemini]] — 同为 LLM Provider，在性价比上与 Gemini Flash 形成竞争
|
||||
---
|
||||
title: "OpenAI"
|
||||
type: entity
|
||||
tags: ["llm-provider", "openai"]
|
||||
sources: ["engineering-autonomous-optimization-architect"]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- OpenAI
|
||||
- OpenAI Inc.
|
||||
|
||||
## Definition
|
||||
OpenAI 是主要的 LLM Provider 之一，提供 GPT 系列模型（GPT-4、GPT-4o、GPT-3.5 Turbo 等）。在 [[AutonomousOptimizationArchitect]] 系统中作为主要候选 Provider 之一参与性能排名和流量路由竞争。
|
||||
|
||||
## Role in LLM Routing
|
||||
- 提供多种规模的模型供 [[AutonomousOptimizationArchitect]] 按任务类型分配
|
||||
- 模型历史性能（token 延迟、幻觉率、成本）被 [[AutonomousOptimizationArchitect]] 持续追踪并纳入 Provider 排名
|
||||
|
||||
## Key Properties
|
||||
- **Token 成本**：$2.5-15 / 1M tokens（因模型而异）
|
||||
- **延迟**：中等至高（取决于模型规模）
|
||||
- **常见用途**：代码生成、复杂推理、长文档处理
|
||||
|
||||
## Connections
|
||||
- [[Anthropic]] — 同为 LLM Provider，竞争关系，共同参与 [[SemanticRouting]]
|
||||
- [[GoogleGemini]] — 同为 LLM Provider，在性价比上与 Gemini Flash 形成竞争
|
||||
|
||||
@@ -1,40 +1,40 @@
|
||||
---
|
||||
title: "PingMe"
|
||||
type: entity
|
||||
tags: [sms-verification, phone-number, claude]
|
||||
last_updated: 2025-12-31
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- PingMe 接码平台
|
||||
|
||||
## Overview
|
||||
PingMe 是一款新兴的短信接码（SMS Verification）平台，提供全球多个国家和地区的临时/长期手机号码，用于接收验证码。与传统一次性号码不同，PingMe 支持订阅制长期号码，稳定性更高。
|
||||
|
||||
## Key Features
|
||||
- **支持中文界面**：界面友好，中文操作体验
|
||||
- **多平台支持**：提供 App（iOS/Android）和网页端
|
||||
- **美国号码可用**：支持获取美国（+1）手机号，用于 Claude 注册
|
||||
- **订阅制号码**：可获取长期有效号码，避免一次性号码被封
|
||||
- **低门槛充值**：最低充值 2 美元
|
||||
|
||||
## Claude Registration Use Case
|
||||
Claude 注册需要美国手机号接收短信验证码：
|
||||
1. 注册 PingMe 账号（支持手机号注册）
|
||||
2. 充值至少 2 美元
|
||||
3. 选择美国区 Claude 验证码服务
|
||||
4. 获取美国长期号码（如 +1 914-577-5122）
|
||||
5. 在 Claude 注册页面填入号码，PingMe 实时接收验证码
|
||||
|
||||
## Why Not Disposable Numbers
|
||||
- 一次性号码存在时间限制，验证码过期后无法重新获取
|
||||
- 平台可能识别并拒绝一次性号码段
|
||||
- 订阅制长期号码更稳定，不易被 Claude 判定为异常
|
||||
|
||||
## Related
|
||||
- [[接码平台]]
|
||||
- [[指纹浏览器]]
|
||||
- [[IP纯净度]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
---
|
||||
title: "PingMe"
|
||||
type: entity
|
||||
tags: [sms-verification, phone-number, claude]
|
||||
last_updated: 2025-12-31
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- PingMe 接码平台
|
||||
|
||||
## Overview
|
||||
PingMe 是一款新兴的短信接码（SMS Verification）平台，提供全球多个国家和地区的临时/长期手机号码，用于接收验证码。与传统一次性号码不同，PingMe 支持订阅制长期号码，稳定性更高。
|
||||
|
||||
## Key Features
|
||||
- **支持中文界面**：界面友好，中文操作体验
|
||||
- **多平台支持**：提供 App（iOS/Android）和网页端
|
||||
- **美国号码可用**：支持获取美国（+1）手机号，用于 Claude 注册
|
||||
- **订阅制号码**：可获取长期有效号码，避免一次性号码被封
|
||||
- **低门槛充值**：最低充值 2 美元
|
||||
|
||||
## Claude Registration Use Case
|
||||
Claude 注册需要美国手机号接收短信验证码：
|
||||
1. 注册 PingMe 账号（支持手机号注册）
|
||||
2. 充值至少 2 美元
|
||||
3. 选择美国区 Claude 验证码服务
|
||||
4. 获取美国长期号码（如 +1 914-577-5122）
|
||||
5. 在 Claude 注册页面填入号码，PingMe 实时接收验证码
|
||||
|
||||
## Why Not Disposable Numbers
|
||||
- 一次性号码存在时间限制，验证码过期后无法重新获取
|
||||
- 平台可能识别并拒绝一次性号码段
|
||||
- 订阅制长期号码更稳定，不易被 Claude 判定为异常
|
||||
|
||||
## Related
|
||||
- [[接码平台]]
|
||||
- [[指纹浏览器]]
|
||||
- [[IP纯净度]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
|
||||
@@ -1,44 +1,44 @@
|
||||
---
|
||||
title: "Prometheus"
|
||||
type: entity
|
||||
tags: [monitoring, time-series, devops, observability]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Prometheus — 开源监控系统与时序数据库
|
||||
|
||||
**官方网址：** https://prometheus.io/
|
||||
|
||||
**类型：** 开源项目 / 监控系统
|
||||
|
||||
**别名：**
|
||||
- prom
|
||||
- Prometheus TSDB
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Prometheus 是由 SoundCloud 开发的开源监控系统，现由 CNCF 托管。采用**拉取（pull）模式**从配置的 targets 收集指标，存储为时间序列数据，支持强大的 PromQL 查询语言和灵活的告警规则引擎。
|
||||
|
||||
**核心特性：**
|
||||
- 多维数据模型（metric + labels）
|
||||
- PromQL 强大查询能力
|
||||
- 拉取模式优于推送（网络可控、无侵入）
|
||||
- HTTP API（易于集成）
|
||||
- Alertmanager 集成
|
||||
|
||||
**典型部署端口：** `9090`（Web UI + API）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[家庭网络环境概览_2026-04-03]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]]
|
||||
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
|
||||
- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
|
||||
---
|
||||
title: "Prometheus"
|
||||
type: entity
|
||||
tags: [monitoring, time-series, devops, observability]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Prometheus — 开源监控系统与时序数据库
|
||||
|
||||
**官方网址：** https://prometheus.io/
|
||||
|
||||
**类型：** 开源项目 / 监控系统
|
||||
|
||||
**别名：**
|
||||
- prom
|
||||
- Prometheus TSDB
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Prometheus 是由 SoundCloud 开发的开源监控系统，现由 CNCF 托管。采用**拉取（pull）模式**从配置的 targets 收集指标，存储为时间序列数据，支持强大的 PromQL 查询语言和灵活的告警规则引擎。
|
||||
|
||||
**核心特性：**
|
||||
- 多维数据模型（metric + labels）
|
||||
- PromQL 强大查询能力
|
||||
- 拉取模式优于推送（网络可控、无侵入）
|
||||
- HTTP API（易于集成）
|
||||
- Alertmanager 集成
|
||||
|
||||
**典型部署端口：** `9090`（Web UI + API）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[家庭网络环境概览_2026-04-03]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]]
|
||||
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
|
||||
- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
|
||||
|
||||
@@ -1,35 +1,35 @@
|
||||
---
|
||||
title: "Synology DSM"
|
||||
type: entity
|
||||
tags: [synology, nas, dsm, linux, docker]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
# Synology DSM
|
||||
|
||||
## Aliases
|
||||
- Synology DSM
|
||||
- DSM
|
||||
- DSM 7.x
|
||||
- 群晖 DSM
|
||||
|
||||
## Definition
|
||||
Synology DiskStation Manager（DSM）是群晖 NAS 设备的操作系统，基于 Linux 内核，提供图形化 Web 管理界面。本文档中的部署环境为 DSM 7.x（DS718），Docker 服务名称为 `pkg-ContainerManager-dockerd`。
|
||||
|
||||
## Key Characteristics for Home Server Context
|
||||
- **Docker 服务名**：`pkg-ContainerManager-dockerd`（与标准 Linux 的 `dockerd` 不同）
|
||||
- **systemd 配置目录**：`/etc/systemd/system/pkg-ContainerManager-dockerd.service.d/`（用于配置 Docker Daemon 代理）
|
||||
- **IP 地址**：典型内网地址 `192.168.3.17`
|
||||
- **QuickConnect**：群晖远程访问服务，可作为透明代理失效时的备用连接方案
|
||||
|
||||
## Known Quirks
|
||||
- Docker Daemon 的网络栈不完全遵循 V2RayA 修改的 iptables 规则，需要显式配置 systemd 代理环境变量
|
||||
- 透明代理有极小概率导致局域网连接中断，远程操作时需谨慎
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]] — V2RayA 透明代理 + Docker Daemon 代理配置
|
||||
- [[Synology-NAS上安装CloudDrive2]] — CloudDrive2 套件安装
|
||||
|
||||
## Related Entities
|
||||
- [[Synology-NAS]] — Synology NAS 硬件设备
|
||||
- [[Docker]] — DSM 上的核心容器化平台
|
||||
---
|
||||
title: "Synology DSM"
|
||||
type: entity
|
||||
tags: [synology, nas, dsm, linux, docker]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
# Synology DSM
|
||||
|
||||
## Aliases
|
||||
- Synology DSM
|
||||
- DSM
|
||||
- DSM 7.x
|
||||
- 群晖 DSM
|
||||
|
||||
## Definition
|
||||
Synology DiskStation Manager（DSM）是群晖 NAS 设备的操作系统，基于 Linux 内核，提供图形化 Web 管理界面。本文档中的部署环境为 DSM 7.x（DS718），Docker 服务名称为 `pkg-ContainerManager-dockerd`。
|
||||
|
||||
## Key Characteristics for Home Server Context
|
||||
- **Docker 服务名**：`pkg-ContainerManager-dockerd`（与标准 Linux 的 `dockerd` 不同）
|
||||
- **systemd 配置目录**：`/etc/systemd/system/pkg-ContainerManager-dockerd.service.d/`（用于配置 Docker Daemon 代理）
|
||||
- **IP 地址**：典型内网地址 `192.168.3.17`
|
||||
- **QuickConnect**：群晖远程访问服务，可作为透明代理失效时的备用连接方案
|
||||
|
||||
## Known Quirks
|
||||
- Docker Daemon 的网络栈不完全遵循 V2RayA 修改的 iptables 规则，需要显式配置 systemd 代理环境变量
|
||||
- 透明代理有极小概率导致局域网连接中断，远程操作时需谨慎
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]] — V2RayA 透明代理 + Docker Daemon 代理配置
|
||||
- [[Synology-NAS上安装CloudDrive2]] — CloudDrive2 套件安装
|
||||
|
||||
## Related Entities
|
||||
- [[Synology-NAS]] — Synology NAS 硬件设备
|
||||
- [[Docker]] — DSM 上的核心容器化平台
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "Synology NAS"
|
||||
type: entity
|
||||
tags: [nas, storage, nfs, samba, backup]
|
||||
date: 2026-04-28
|
||||
---
|
||||
|
||||
# Synology NAS
|
||||
|
||||
## Aliases
|
||||
- Synology NAS
|
||||
- Synology DS718
|
||||
- 群晖 NAS
|
||||
|
||||
## Definition
|
||||
Synology NAS（网络附加存储）是由群晖科技生产的私有云存储设备，提供文件存储、备份、多媒体服务等功能。在 Home Office 架构中是核心数据存储节点，通过 NFS 或 Samba 协议向 Ubuntu 服务器提供备份存储空间。
|
||||
|
||||
## Docker 套件
|
||||
- V2RayA（透明代理 + Docker Daemon 代理）：通过 Docker 部署，为 NAS 本机和 Docker pull 提供科学上网能力
|
||||
- CloudDrive2：云盘挂载（矿神源安装）
|
||||
- Portainer：Docker 容器可视化管理
|
||||
|
||||
## Core Capabilities
|
||||
- **NFS 共享**：通过 DSM 控制面板启用 NFS 服务，配置导出路径和访问权限（IP 白名单、Squash 设置）
|
||||
- **SMB/CIFS 共享**：通过 Samba 协议向 Windows/macOS 机器提供文件共享
|
||||
- **Backup Target**：作为 rsync/Clonezilla 备份的目标存储
|
||||
- **Docker 宿主**：运行 CloudDrive2、Docker Compose 服务套件
|
||||
|
||||
## Key Configurations for Ubuntu Backup
|
||||
| 配置项 | 值 |
|
||||
|--------|-----|
|
||||
| NFS 导出路径 | `/volume2/backup` |
|
||||
| Ubuntu 挂载点 | `/mnt/nas_backup` |
|
||||
| NFS 服务器 IP | `192.168.3.17` |
|
||||
| 推荐 Squash | `admin`（映射为管理员权限） |
|
||||
| 安全模式 | `sys` |
|
||||
| fstab `_netdev` | 必须加，防止开机卡死 |
|
||||
|
||||
## Related Sources
|
||||
- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] — NFS 挂载完整配置
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — rsync 备份到 Synology NAS 的完整方案
|
||||
- [[用docker安装jellyfin]] — Jellyfin 部署在 Synology NAS Docker 环境
|
||||
- [[用docker中安装navidrome]] — Navidrome 音乐服务部署
|
||||
|
||||
## Related Concepts
|
||||
- [[永久挂载]] — Synology NFS 必须在 /etc/fstab 配置才能永久生效
|
||||
- [[挂载点检查]] — 备份脚本必须在 rsync 前验证挂载状态
|
||||
- [[增量备份]] — rsync 到 Synology NAS 是典型的增量备份场景
|
||||
|
||||
## Related Entities
|
||||
- [[rsync]] — 备份工具
|
||||
- [[Clonezilla]] — 全盘镜像备份目标
|
||||
- [[Ubuntu Server]] — NFS 客户端运行环境
|
||||
- [[NFS]] — 网络文件系统协议
|
||||
---
|
||||
title: "Synology NAS"
|
||||
type: entity
|
||||
tags: [nas, storage, nfs, samba, backup]
|
||||
date: 2026-04-28
|
||||
---
|
||||
|
||||
# Synology NAS
|
||||
|
||||
## Aliases
|
||||
- Synology NAS
|
||||
- Synology DS718
|
||||
- 群晖 NAS
|
||||
|
||||
## Definition
|
||||
Synology NAS（网络附加存储）是由群晖科技生产的私有云存储设备，提供文件存储、备份、多媒体服务等功能。在 Home Office 架构中是核心数据存储节点，通过 NFS 或 Samba 协议向 Ubuntu 服务器提供备份存储空间。
|
||||
|
||||
## Docker 套件
|
||||
- V2RayA（透明代理 + Docker Daemon 代理）：通过 Docker 部署，为 NAS 本机和 Docker pull 提供科学上网能力
|
||||
- CloudDrive2：云盘挂载（矿神源安装）
|
||||
- Portainer：Docker 容器可视化管理
|
||||
|
||||
## Core Capabilities
|
||||
- **NFS 共享**：通过 DSM 控制面板启用 NFS 服务，配置导出路径和访问权限（IP 白名单、Squash 设置）
|
||||
- **SMB/CIFS 共享**：通过 Samba 协议向 Windows/macOS 机器提供文件共享
|
||||
- **Backup Target**：作为 rsync/Clonezilla 备份的目标存储
|
||||
- **Docker 宿主**：运行 CloudDrive2、Docker Compose 服务套件
|
||||
|
||||
## Key Configurations for Ubuntu Backup
|
||||
| 配置项 | 值 |
|
||||
|--------|-----|
|
||||
| NFS 导出路径 | `/volume2/backup` |
|
||||
| Ubuntu 挂载点 | `/mnt/nas_backup` |
|
||||
| NFS 服务器 IP | `192.168.3.17` |
|
||||
| 推荐 Squash | `admin`（映射为管理员权限） |
|
||||
| 安全模式 | `sys` |
|
||||
| fstab `_netdev` | 必须加，防止开机卡死 |
|
||||
|
||||
## Related Sources
|
||||
- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] — NFS 挂载完整配置
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — rsync 备份到 Synology NAS 的完整方案
|
||||
- [[用docker安装jellyfin]] — Jellyfin 部署在 Synology NAS Docker 环境
|
||||
- [[用docker中安装navidrome]] — Navidrome 音乐服务部署
|
||||
|
||||
## Related Concepts
|
||||
- [[永久挂载]] — Synology NFS 必须在 /etc/fstab 配置才能永久生效
|
||||
- [[挂载点检查]] — 备份脚本必须在 rsync 前验证挂载状态
|
||||
- [[增量备份]] — rsync 到 Synology NAS 是典型的增量备份场景
|
||||
|
||||
## Related Entities
|
||||
- [[rsync]] — 备份工具
|
||||
- [[Clonezilla]] — 全盘镜像备份目标
|
||||
- [[Ubuntu Server]] — NFS 客户端运行环境
|
||||
- [[NFS]] — 网络文件系统协议
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "V2RayA"
|
||||
type: entity
|
||||
tags: [vpn, proxy, transparent-proxy, docker, v2ray, open-source]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
# V2RayA
|
||||
|
||||
## Aliases
|
||||
- V2RayA
|
||||
- v2raya
|
||||
- V2rayA
|
||||
|
||||
## Definition
|
||||
V2RayA 是基于 V2Ray 内核的轻量级透明代理 Web 管理界面，支持通过 Docker 部署在 NAS/服务器环境中，提供可视化的节点管理、分流规则配置和透明代理开关功能。
|
||||
|
||||
## Core Capabilities
|
||||
- **Web UI 管理**：通过浏览器配置代理节点、路由规则和透明代理开关
|
||||
- **透明代理**：劫持系统出站流量（基于 iptables），无需客户端显式配置
|
||||
- **Traffic Splitting（分流）**：支持多种分流规则，包括 GFWList、大陆白名单、全局代理等
|
||||
- **Docker 部署**：官方提供 Docker 镜像 `mzz2017/v2raya`，支持 Host 网络模式
|
||||
|
||||
## Key Configuration
|
||||
| 配置项 | 值 |
|
||||
|--------|-----|
|
||||
| Docker 镜像 | `mzz2017/v2raya` |
|
||||
| 推荐网络模式 | `--network=host` |
|
||||
| HTTP 代理端口 | 20171（默认） |
|
||||
| Web UI 端口 | 2017 |
|
||||
| 推荐分流模式 | "大陆白名单（Whitelist of Mainland China）" |
|
||||
| 环境变量 | `IPTABLES_MODE=legacy` |
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]] — V2RayA 在群晖 NAS 上的完整安装与 Docker Daemon 代理配置
|
||||
- [[Ubuntu-Server科学上网]] — V2RayA 在 Ubuntu Server 上的安装
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 的核心实现机制
|
||||
- [[分流模式]] — V2RayA 的路由策略
|
||||
- [[Docker-Daemon-Proxy]] — V2RayA 的替代方案，直接为 Docker 守护进程配置代理
|
||||
- [[iptables]] — 透明代理依赖的内核防火墙规则
|
||||
|
||||
## Related Entities
|
||||
- [[Synology-DSM]] — V2RayA 的典型部署平台之一
|
||||
- [[Docker]] — V2RayA 的运行环境和被代理对象
|
||||
- [[Xray]] — V2Ray 的上游核心，V2RayA 基于此运行
|
||||
---
|
||||
title: "V2RayA"
|
||||
type: entity
|
||||
tags: [vpn, proxy, transparent-proxy, docker, v2ray, open-source]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
# V2RayA
|
||||
|
||||
## Aliases
|
||||
- V2RayA
|
||||
- v2raya
|
||||
- V2rayA
|
||||
|
||||
## Definition
|
||||
V2RayA 是基于 V2Ray 内核的轻量级透明代理 Web 管理界面，支持通过 Docker 部署在 NAS/服务器环境中，提供可视化的节点管理、分流规则配置和透明代理开关功能。
|
||||
|
||||
## Core Capabilities
|
||||
- **Web UI 管理**：通过浏览器配置代理节点、路由规则和透明代理开关
|
||||
- **透明代理**：劫持系统出站流量（基于 iptables），无需客户端显式配置
|
||||
- **Traffic Splitting（分流）**：支持多种分流规则，包括 GFWList、大陆白名单、全局代理等
|
||||
- **Docker 部署**：官方提供 Docker 镜像 `mzz2017/v2raya`，支持 Host 网络模式
|
||||
|
||||
## Key Configuration
|
||||
| 配置项 | 值 |
|
||||
|--------|-----|
|
||||
| Docker 镜像 | `mzz2017/v2raya` |
|
||||
| 推荐网络模式 | `--network=host` |
|
||||
| HTTP 代理端口 | 20171（默认） |
|
||||
| Web UI 端口 | 2017 |
|
||||
| 推荐分流模式 | "大陆白名单（Whitelist of Mainland China）" |
|
||||
| 环境变量 | `IPTABLES_MODE=legacy` |
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]] — V2RayA 在群晖 NAS 上的完整安装与 Docker Daemon 代理配置
|
||||
- [[Ubuntu-Server科学上网]] — V2RayA 在 Ubuntu Server 上的安装
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 的核心实现机制
|
||||
- [[分流模式]] — V2RayA 的路由策略
|
||||
- [[Docker-Daemon-Proxy]] — V2RayA 的替代方案，直接为 Docker 守护进程配置代理
|
||||
- [[iptables]] — 透明代理依赖的内核防火墙规则
|
||||
|
||||
## Related Entities
|
||||
- [[Synology-DSM]] — V2RayA 的典型部署平台之一
|
||||
- [[Docker]] — V2RayA 的运行环境和被代理对象
|
||||
- [[Xray]] — V2Ray 的上游核心，V2RayA 基于此运行
|
||||
|
||||
@@ -1,39 +1,39 @@
|
||||
---
|
||||
title: "WildCard"
|
||||
type: entity
|
||||
tags: [virtual-card, payment, cross-border]
|
||||
last_updated: 2025-12-31
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- WildCard 虚拟信用卡
|
||||
- 野卡
|
||||
|
||||
## Overview
|
||||
WildCard 是一款面向中国用户的虚拟信用卡（Virtual Credit Card, VCC）服务，不依赖实体银行卡，通过线上注册和支付宝充值，解决国内用户跨境支付的难题。
|
||||
|
||||
## Key Features
|
||||
- **无实体卡**：纯线上运营，开卡即用
|
||||
- **支付宝充值**：支持支付宝账户直接充值，方便国内用户
|
||||
- **手机号注册**：仅需手机号验证，无需复杂资质审核
|
||||
- **多场景支持**：支持 OpenAI（ChatGPT Plus）、Claude Pro、Midjourney 等海外AI服务订阅
|
||||
- **邀请链接**：yeka.ai/i/UPHSP
|
||||
|
||||
## Claude Pro Subscription Use Case
|
||||
Claude Pro 订阅（月费 20 美元）国内信用卡无法直接支付，WildCard 解决方案：
|
||||
1. 注册 WildCard 账号（yeka.ai/i/UPHSP 邀请链接）
|
||||
2. 手机号验证 + 支付宝充值（建议充值 22 美元以上以覆盖月费）
|
||||
3. 充值成功后，绑定 WildCard 信用卡信息到 Claude Pro 订阅页面
|
||||
4. 完成支付，开通 Claude Pro 会员
|
||||
|
||||
## Why Virtual Cards for AI Subscriptions
|
||||
- 国内发行的 Visa/Mastercard 信用卡默认不支持境外AI服务消费
|
||||
- 虚拟卡可绕过地域限制，且可随时注销，控制风险
|
||||
- WildCard 专门针对中国用户优化，支付宝充值降低门槛
|
||||
|
||||
## Related
|
||||
- [[接码平台]]
|
||||
- [[指纹浏览器]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
---
|
||||
title: "WildCard"
|
||||
type: entity
|
||||
tags: [virtual-card, payment, cross-border]
|
||||
last_updated: 2025-12-31
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- WildCard 虚拟信用卡
|
||||
- 野卡
|
||||
|
||||
## Overview
|
||||
WildCard 是一款面向中国用户的虚拟信用卡（Virtual Credit Card, VCC）服务，不依赖实体银行卡，通过线上注册和支付宝充值，解决国内用户跨境支付的难题。
|
||||
|
||||
## Key Features
|
||||
- **无实体卡**：纯线上运营，开卡即用
|
||||
- **支付宝充值**：支持支付宝账户直接充值，方便国内用户
|
||||
- **手机号注册**：仅需手机号验证，无需复杂资质审核
|
||||
- **多场景支持**：支持 OpenAI（ChatGPT Plus）、Claude Pro、Midjourney 等海外AI服务订阅
|
||||
- **邀请链接**：yeka.ai/i/UPHSP
|
||||
|
||||
## Claude Pro Subscription Use Case
|
||||
Claude Pro 订阅（月费 20 美元）国内信用卡无法直接支付，WildCard 解决方案：
|
||||
1. 注册 WildCard 账号（yeka.ai/i/UPHSP 邀请链接）
|
||||
2. 手机号验证 + 支付宝充值（建议充值 22 美元以上以覆盖月费）
|
||||
3. 充值成功后，绑定 WildCard 信用卡信息到 Claude Pro 订阅页面
|
||||
4. 完成支付，开通 Claude Pro 会员
|
||||
|
||||
## Why Virtual Cards for AI Subscriptions
|
||||
- 国内发行的 Visa/Mastercard 信用卡默认不支持境外AI服务消费
|
||||
- 虚拟卡可绕过地域限制，且可随时注销，控制风险
|
||||
- WildCard 专门针对中国用户优化，支付宝充值降低门槛
|
||||
|
||||
## Related
|
||||
- [[接码平台]]
|
||||
- [[指纹浏览器]]
|
||||
|
||||
## 来源
|
||||
- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]]
|
||||
|
||||
@@ -1,48 +1,48 @@
|
||||
---
|
||||
title: "cAdvisor"
|
||||
type: entity
|
||||
tags: [monitoring, container, docker, prometheus, devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## cAdvisor — Google 容器指标采集器
|
||||
|
||||
**官方网址：** https://github.com/google/cadvisor
|
||||
|
||||
**类型：** 开源项目 / 容器监控工具
|
||||
|
||||
**别名：**
|
||||
- cadvisor
|
||||
- Google cAdvisor
|
||||
- Container Advisor
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
cAdvisor 是 Google 开发的容器监控工具，自动采集单个节点上运行的所有容器的资源使用情况（CPU、内存、网络、磁盘 I/O），并以 Prometheus 可抓取的格式暴露指标。
|
||||
|
||||
**采集指标示例：**
|
||||
- `container_cpu_usage_seconds_total` — 容器 CPU 使用
|
||||
- `container_memory_usage_bytes` — 容器内存使用
|
||||
- `container_network_receive_bytes_total` — 容器网络接收
|
||||
- `container_last_seen` — 容器最后活跃时间
|
||||
- `container_restart_total` — 容器重启次数
|
||||
|
||||
**典型部署：**
|
||||
- Docker: `gcr.io/cadvisor/cadvisor:latest`
|
||||
- 端口：`8080`
|
||||
- 需要挂载：`/var/run`（Docker socket）、`/sys`、`/var/lib/docker/`
|
||||
|
||||
**关键告警规则示例：**
|
||||
- 容器异常退出: `increase(container_last_seen[5m]) == 0`（容器未上报即可能已退出）
|
||||
|
||||
**安全注意：** 需审慎挂载 Docker socket（权限等同于宿主机 root）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
---
|
||||
title: "cAdvisor"
|
||||
type: entity
|
||||
tags: [monitoring, container, docker, prometheus, devops]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## cAdvisor — Google 容器指标采集器
|
||||
|
||||
**官方网址：** https://github.com/google/cadvisor
|
||||
|
||||
**类型：** 开源项目 / 容器监控工具
|
||||
|
||||
**别名：**
|
||||
- cadvisor
|
||||
- Google cAdvisor
|
||||
- Container Advisor
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
cAdvisor 是 Google 开发的容器监控工具，自动采集单个节点上运行的所有容器的资源使用情况（CPU、内存、网络、磁盘 I/O），并以 Prometheus 可抓取的格式暴露指标。
|
||||
|
||||
**采集指标示例：**
|
||||
- `container_cpu_usage_seconds_total` — 容器 CPU 使用
|
||||
- `container_memory_usage_bytes` — 容器内存使用
|
||||
- `container_network_receive_bytes_total` — 容器网络接收
|
||||
- `container_last_seen` — 容器最后活跃时间
|
||||
- `container_restart_total` — 容器重启次数
|
||||
|
||||
**典型部署：**
|
||||
- Docker: `gcr.io/cadvisor/cadvisor:latest`
|
||||
- 端口：`8080`
|
||||
- 需要挂载：`/var/run`（Docker socket）、`/sys`、`/var/lib/docker/`
|
||||
|
||||
**关键告警规则示例：**
|
||||
- 容器异常退出: `increase(container_last_seen[5m]) == 0`（容器未上报即可能已退出）
|
||||
|
||||
**安全注意：** 需审慎挂载 Docker socket（权限等同于宿主机 root）
|
||||
|
||||
---
|
||||
|
||||
## Used By
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
|
||||
@@ -1,68 +1,68 @@
|
||||
---
|
||||
title: "frp"
|
||||
type: entity
|
||||
tags: [networking, open-source, golang, tunneling, self-hosted]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
# frp
|
||||
|
||||
## Overview
|
||||
**frp（Fast Reverse Proxy）** 是一款开源的高性能内网穿透工具，由 Go 语言编写，通过客户端-服务端架构（frps + frpc）建立反向隧道，使处于 NAT 或防火墙后的内网服务可以被公网访问。本 Wiki 使用 **frp v0.65.0**（INI 配置文件格式）。
|
||||
|
||||
## Core Architecture
|
||||
```
|
||||
公网用户 → VPS:7000(frps) ←——— 反向隧道 ←——— frpc(内网设备)
|
||||
```
|
||||
|
||||
## Components
|
||||
- **frps**（frp server）：运行在公网 VPS，监听 7000 端口（默认），接收 frpc 连接，管理端口映射
|
||||
- **frpc**（frp client）：运行在内网设备，主动连接 frps，建立反向隧道
|
||||
|
||||
## Supported Protocol Types
|
||||
| 类型 | 说明 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| TCP | 原始 TCP 流量 | SSH、任意 TCP 端口 |
|
||||
| UDP | 原始 UDP 流量 | DNS、视频流 |
|
||||
| HTTP/HTTPS | 应用层代理 | Web 服务 |
|
||||
| STCP | 加密 TCP | 安全内网访问 |
|
||||
| SUDP | 加密 UDP | 安全数据传输 |
|
||||
| XTCP | P2P UDP | 穿越对称型 NAT |
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：完整实践指南（frps + Caddy + 阿里云 DNS）
|
||||
- [[ubuntu-安装-frp-0-65-0-x86-64-操作笔记]]：Ubuntu frpc 客户端安装配置
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]]：Mac Mini ARM64 安装配置
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]：通过 frp 穿透 Grafana/Prometheus 端口
|
||||
|
||||
## frpc 端口映射表（内网 Ubuntu 192.168.3.47）
|
||||
| 服务 | local_port | remote_port |
|
||||
|------|-----------|-------------|
|
||||
| n8n | 5678 | 15678 |
|
||||
| Transmission | 9091 | 19091 |
|
||||
| Grafana | 3000 | 13000 |
|
||||
| SSH | 22 | 60022 |
|
||||
|
||||
## SSH 穿透注意事项
|
||||
SSH 穿透使用 `type = tcp`，不走 Caddy（Caddy 只处理 HTTP/HTTPS）。SSH 连接命令：`ssh -p 60022 user@ubuntu1.ishenwei.online`
|
||||
|
||||
## Troubleshooting
|
||||
详见 [[通过VPS+内网反向代理实现域名访问内网穿透]] 故障排查章节：
|
||||
1. 确认 frps 监听端口 `ss -lntup | grep frps`
|
||||
2. 确认 token 与 frpc 一致 `journalctl -u frps -n 100`
|
||||
3. 确认防火墙放行 7000 端口
|
||||
4. telnet 诊断确认连接是否到达 frps
|
||||
5. 强制重启 frps + frpc
|
||||
|
||||
## Related Entities
|
||||
- [[RackNerd]]：托管 frps 的 VPS 提供商（IP: 192.227.222.142）
|
||||
- [[VPS]]：运行 frps 的公网服务器
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：frp 是实现内网穿透的工具
|
||||
- [[反向代理]]：Caddy 在 frp 上层提供 HTTPS 访问
|
||||
- [[TCP隧道]]：frp 的 TCP 类型映射建立 TCP 隧道
|
||||
|
||||
## References
|
||||
- GitHub: https://github.com/fatedier/frp
|
||||
- 文档: https://github.com/fatedier/frp#configuration
|
||||
---
|
||||
title: "frp"
|
||||
type: entity
|
||||
tags: [networking, open-source, golang, tunneling, self-hosted]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
# frp
|
||||
|
||||
## Overview
|
||||
**frp（Fast Reverse Proxy）** 是一款开源的高性能内网穿透工具，由 Go 语言编写，通过客户端-服务端架构（frps + frpc）建立反向隧道，使处于 NAT 或防火墙后的内网服务可以被公网访问。本 Wiki 使用 **frp v0.65.0**（INI 配置文件格式）。
|
||||
|
||||
## Core Architecture
|
||||
```
|
||||
公网用户 → VPS:7000(frps) ←——— 反向隧道 ←——— frpc(内网设备)
|
||||
```
|
||||
|
||||
## Components
|
||||
- **frps**（frp server）：运行在公网 VPS，监听 7000 端口（默认），接收 frpc 连接，管理端口映射
|
||||
- **frpc**（frp client）：运行在内网设备，主动连接 frps，建立反向隧道
|
||||
|
||||
## Supported Protocol Types
|
||||
| 类型 | 说明 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| TCP | 原始 TCP 流量 | SSH、任意 TCP 端口 |
|
||||
| UDP | 原始 UDP 流量 | DNS、视频流 |
|
||||
| HTTP/HTTPS | 应用层代理 | Web 服务 |
|
||||
| STCP | 加密 TCP | 安全内网访问 |
|
||||
| SUDP | 加密 UDP | 安全数据传输 |
|
||||
| XTCP | P2P UDP | 穿越对称型 NAT |
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：完整实践指南（frps + Caddy + 阿里云 DNS）
|
||||
- [[ubuntu-安装-frp-0-65-0-x86-64-操作笔记]]：Ubuntu frpc 客户端安装配置
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]]：Mac Mini ARM64 安装配置
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]：通过 frp 穿透 Grafana/Prometheus 端口
|
||||
|
||||
## frpc 端口映射表（内网 Ubuntu 192.168.3.47）
|
||||
| 服务 | local_port | remote_port |
|
||||
|------|-----------|-------------|
|
||||
| n8n | 5678 | 15678 |
|
||||
| Transmission | 9091 | 19091 |
|
||||
| Grafana | 3000 | 13000 |
|
||||
| SSH | 22 | 60022 |
|
||||
|
||||
## SSH 穿透注意事项
|
||||
SSH 穿透使用 `type = tcp`，不走 Caddy（Caddy 只处理 HTTP/HTTPS）。SSH 连接命令：`ssh -p 60022 user@ubuntu1.ishenwei.online`
|
||||
|
||||
## Troubleshooting
|
||||
详见 [[通过VPS+内网反向代理实现域名访问内网穿透]] 故障排查章节：
|
||||
1. 确认 frps 监听端口 `ss -lntup | grep frps`
|
||||
2. 确认 token 与 frpc 一致 `journalctl -u frps -n 100`
|
||||
3. 确认防火墙放行 7000 端口
|
||||
4. telnet 诊断确认连接是否到达 frps
|
||||
5. 强制重启 frps + frpc
|
||||
|
||||
## Related Entities
|
||||
- [[RackNerd]]：托管 frps 的 VPS 提供商（IP: 192.227.222.142）
|
||||
- [[VPS]]：运行 frps 的公网服务器
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：frp 是实现内网穿透的工具
|
||||
- [[反向代理]]：Caddy 在 frp 上层提供 HTTPS 访问
|
||||
- [[TCP隧道]]：frp 的 TCP 类型映射建立 TCP 隧道
|
||||
|
||||
## References
|
||||
- GitHub: https://github.com/fatedier/frp
|
||||
- 文档: https://github.com/fatedier/frp#configuration
|
||||
|
||||
@@ -1,98 +1,98 @@
|
||||
---
|
||||
title: "rsync"
|
||||
type: entity
|
||||
tags: [backup, linux, sync, incremental]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# rsync
|
||||
|
||||
## Overview
|
||||
**rsync**（Remote Sync）是一款开源增量文件同步工具，广泛用于 Linux/Unix 系统间的备份和同步操作。它通过高效差异算法，仅传输源文件和目标文件之间的差异部分，实现带宽和时间的高效利用。
|
||||
|
||||
## Key Characteristics
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| **增量同步** | 仅传输变更部分，支持 `-a`（归档）、`-v`（详细）、`-z`（压缩传输） |
|
||||
| **协议支持** | 本地、SSH、Rsync Daemon、NFS、Samba |
|
||||
| **权限保留** | `-a` 保留文件所有权、时间戳、权限等属性 |
|
||||
| **Dry Run** | `--dry-run` / `-n` 预览同步效果，不实际执行 |
|
||||
| **删除选项** | `--delete` 同步目标端多余文件（谨慎使用） |
|
||||
|
||||
## Common Usage Patterns
|
||||
|
||||
### 1. 本地到 NFS 挂载点（Home Server 备份）
|
||||
```bash
|
||||
# 同步 /home/user/data 到 NAS 挂载点
|
||||
rsync -avz --delete /home/user/data/ /mnt/nas_backup/user_data/
|
||||
```
|
||||
|
||||
### 2. 通过 SSH 远程同步
|
||||
```bash
|
||||
# 远程备份（需 SSH key 免密）
|
||||
rsync -avz -e ssh /local/path/ user@remote:/remote/path/
|
||||
```
|
||||
|
||||
### 3. 自动化备份脚本（推荐）
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# /usr/local/bin/rsync_backup.sh
|
||||
|
||||
SOURCE_DIR="/home/ubuntu/data"
|
||||
TARGET_DIR="/mnt/nas_backup"
|
||||
LOG_FILE="/var/log/rsync_backup.log"
|
||||
|
||||
# 挂载点安全检查
|
||||
if ! mountpoint -q $TARGET_DIR; then
|
||||
echo "$(date) 错误：NAS 未挂载，备份任务取消！" >> $LOG_FILE
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 执行增量同步
|
||||
rsync -avz --delete --bwlimit=5000 \
|
||||
$SOURCE_DIR/ $TARGET_DIR/ \
|
||||
>> $LOG_FILE 2>&1
|
||||
|
||||
echo "$(date) 备份完成" >> $LOG_FILE
|
||||
```
|
||||
|
||||
## Key Parameters for NAS Backup
|
||||
| 参数 | 用途 |
|
||||
|------|------|
|
||||
| `-a` | 归档模式（保留权限、时间戳、所有者） |
|
||||
| `-v` | 详细输出 |
|
||||
| `-z` | 压缩传输（节省带宽） |
|
||||
| `--delete` | 目标端删除源端不存在的文件 |
|
||||
| `--bwlimit=5000` | 限速 5000 KB/s，保护 NAS 性能 |
|
||||
| `-n` / `--dry-run` | 预览模式，正式运行前必测 |
|
||||
|
||||
## rsync + NFS 备份工作流
|
||||
```
|
||||
Ubuntu Server (rsync 客户端)
|
||||
→ 挂载点 /mnt/nas_backup (NFS)
|
||||
→ Synology NAS (NFS 服务端, volume2/backup)
|
||||
```
|
||||
|
||||
**关键依赖**：
|
||||
1. Synology DSM NFS 权限已配置（Squash=admin）
|
||||
2. Ubuntu 已通过 /etc/fstab 永久挂载 NFS
|
||||
3. 挂载点检查通过后再执行 rsync
|
||||
|
||||
## Related Concepts
|
||||
- [[永久挂载]] — rsync 备份目标端必须先完成 NFS 永久挂载
|
||||
- [[挂载点检查]] — rsync 备份脚本的安全前置检查
|
||||
- [[增量备份]] — rsync 是增量备份的核心工具
|
||||
- [[NFS]] — NFS 是 rsync 备份到 NAS 的网络传输层
|
||||
- [[Cron定时任务]] — rsync 通常通过 Cron 实现定时自动执行
|
||||
|
||||
## Related Sources
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — rsync + Cron + NFS 完整备份方案
|
||||
- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] — NFS 挂载配置
|
||||
|
||||
## Related Entities
|
||||
- [[Ubuntu Server]] — rsync 客户端运行环境
|
||||
- [[Synology-NAS]] — rsync 备份的目标 NAS 存储
|
||||
|
||||
## References
|
||||
- rsync 官网: https://rsync.samba.org/
|
||||
- man rsync (本地查看)
|
||||
---
|
||||
title: "rsync"
|
||||
type: entity
|
||||
tags: [backup, linux, sync, incremental]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
# rsync
|
||||
|
||||
## Overview
|
||||
**rsync**（Remote Sync）是一款开源增量文件同步工具，广泛用于 Linux/Unix 系统间的备份和同步操作。它通过高效差异算法，仅传输源文件和目标文件之间的差异部分，实现带宽和时间的高效利用。
|
||||
|
||||
## Key Characteristics
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| **增量同步** | 仅传输变更部分，支持 `-a`（归档）、`-v`（详细）、`-z`（压缩传输） |
|
||||
| **协议支持** | 本地、SSH、Rsync Daemon、NFS、Samba |
|
||||
| **权限保留** | `-a` 保留文件所有权、时间戳、权限等属性 |
|
||||
| **Dry Run** | `--dry-run` / `-n` 预览同步效果，不实际执行 |
|
||||
| **删除选项** | `--delete` 同步目标端多余文件（谨慎使用） |
|
||||
|
||||
## Common Usage Patterns
|
||||
|
||||
### 1. 本地到 NFS 挂载点（Home Server 备份）
|
||||
```bash
|
||||
# 同步 /home/user/data 到 NAS 挂载点
|
||||
rsync -avz --delete /home/user/data/ /mnt/nas_backup/user_data/
|
||||
```
|
||||
|
||||
### 2. 通过 SSH 远程同步
|
||||
```bash
|
||||
# 远程备份（需 SSH key 免密）
|
||||
rsync -avz -e ssh /local/path/ user@remote:/remote/path/
|
||||
```
|
||||
|
||||
### 3. 自动化备份脚本（推荐）
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# /usr/local/bin/rsync_backup.sh
|
||||
|
||||
SOURCE_DIR="/home/ubuntu/data"
|
||||
TARGET_DIR="/mnt/nas_backup"
|
||||
LOG_FILE="/var/log/rsync_backup.log"
|
||||
|
||||
# 挂载点安全检查
|
||||
if ! mountpoint -q $TARGET_DIR; then
|
||||
echo "$(date) 错误：NAS 未挂载，备份任务取消！" >> $LOG_FILE
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# 执行增量同步
|
||||
rsync -avz --delete --bwlimit=5000 \
|
||||
$SOURCE_DIR/ $TARGET_DIR/ \
|
||||
>> $LOG_FILE 2>&1
|
||||
|
||||
echo "$(date) 备份完成" >> $LOG_FILE
|
||||
```
|
||||
|
||||
## Key Parameters for NAS Backup
|
||||
| 参数 | 用途 |
|
||||
|------|------|
|
||||
| `-a` | 归档模式（保留权限、时间戳、所有者） |
|
||||
| `-v` | 详细输出 |
|
||||
| `-z` | 压缩传输（节省带宽） |
|
||||
| `--delete` | 目标端删除源端不存在的文件 |
|
||||
| `--bwlimit=5000` | 限速 5000 KB/s，保护 NAS 性能 |
|
||||
| `-n` / `--dry-run` | 预览模式，正式运行前必测 |
|
||||
|
||||
## rsync + NFS 备份工作流
|
||||
```
|
||||
Ubuntu Server (rsync 客户端)
|
||||
→ 挂载点 /mnt/nas_backup (NFS)
|
||||
→ Synology NAS (NFS 服务端, volume2/backup)
|
||||
```
|
||||
|
||||
**关键依赖**：
|
||||
1. Synology DSM NFS 权限已配置（Squash=admin）
|
||||
2. Ubuntu 已通过 /etc/fstab 永久挂载 NFS
|
||||
3. 挂载点检查通过后再执行 rsync
|
||||
|
||||
## Related Concepts
|
||||
- [[永久挂载]] — rsync 备份目标端必须先完成 NFS 永久挂载
|
||||
- [[挂载点检查]] — rsync 备份脚本的安全前置检查
|
||||
- [[增量备份]] — rsync 是增量备份的核心工具
|
||||
- [[NFS]] — NFS 是 rsync 备份到 NAS 的网络传输层
|
||||
- [[Cron定时任务]] — rsync 通常通过 Cron 实现定时自动执行
|
||||
|
||||
## Related Sources
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — rsync + Cron + NFS 完整备份方案
|
||||
- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] — NFS 挂载配置
|
||||
|
||||
## Related Entities
|
||||
- [[Ubuntu Server]] — rsync 客户端运行环境
|
||||
- [[Synology-NAS]] — rsync 备份的目标 NAS 存储
|
||||
|
||||
## References
|
||||
- rsync 官网: https://rsync.samba.org/
|
||||
- man rsync (本地查看)
|
||||
|
||||
@@ -1,31 +1,31 @@
|
||||
# 梅林固件
|
||||
|
||||
## Aliases
|
||||
- Merlin Firmware
|
||||
- ASUSWRT-Merlin
|
||||
- 梅林固件
|
||||
|
||||
## Basic Info
|
||||
- **Type**: 第三方路由器固件
|
||||
- **Developer**: Eric Sauvageau
|
||||
- **Based On**: 华硕官方固件（ASUSWRT）
|
||||
- **Platforms**: 华硕路由器、网件路由器（部分型号）
|
||||
|
||||
## Description
|
||||
梅林固件是基于华硕官方路由器固件的第三方改良版本，由开发者Eric Sauvageau维护。它在原厂固件基础上增加了更多高级功能和插件支持，是路由器玩家和科学上网用户最常使用的第三方固件之一。
|
||||
|
||||
## Key Features
|
||||
- 支持更多插件（软件中心）
|
||||
- 高级网络配置选项
|
||||
- JFFS 分区支持（用于安装插件）
|
||||
- 科学上网插件支持
|
||||
- SSH/Telnet 远程访问
|
||||
- 更灵活的安全设置
|
||||
|
||||
## Related
|
||||
- [[网件RAX50]] — 支持梅林固件的路由器型号
|
||||
- [[MerlinClash插件]] — 梅林固件上的科学上网插件
|
||||
- [[过渡固件]] — 刷入梅林固件的前置固件
|
||||
- [[策略组分流]] — MerlinClash 的核心功能
|
||||
- [[故障转移]] — MerlinClash 配套可靠性机制
|
||||
- [[订阅机制]] — MerlinClash 节点配置来源
|
||||
# 梅林固件
|
||||
|
||||
## Aliases
|
||||
- Merlin Firmware
|
||||
- ASUSWRT-Merlin
|
||||
- 梅林固件
|
||||
|
||||
## Basic Info
|
||||
- **Type**: 第三方路由器固件
|
||||
- **Developer**: Eric Sauvageau
|
||||
- **Based On**: 华硕官方固件（ASUSWRT）
|
||||
- **Platforms**: 华硕路由器、网件路由器（部分型号）
|
||||
|
||||
## Description
|
||||
梅林固件是基于华硕官方路由器固件的第三方改良版本，由开发者Eric Sauvageau维护。它在原厂固件基础上增加了更多高级功能和插件支持，是路由器玩家和科学上网用户最常使用的第三方固件之一。
|
||||
|
||||
## Key Features
|
||||
- 支持更多插件（软件中心）
|
||||
- 高级网络配置选项
|
||||
- JFFS 分区支持（用于安装插件）
|
||||
- 科学上网插件支持
|
||||
- SSH/Telnet 远程访问
|
||||
- 更灵活的安全设置
|
||||
|
||||
## Related
|
||||
- [[网件RAX50]] — 支持梅林固件的路由器型号
|
||||
- [[MerlinClash插件]] — 梅林固件上的科学上网插件
|
||||
- [[过渡固件]] — 刷入梅林固件的前置固件
|
||||
- [[策略组分流]] — MerlinClash 的核心功能
|
||||
- [[故障转移]] — MerlinClash 配套可靠性机制
|
||||
- [[订阅机制]] — MerlinClash 节点配置来源
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
# 网件RAX50
|
||||
|
||||
## Aliases
|
||||
- NETGEAR Nighthawk RAX50
|
||||
- 网件RAX50
|
||||
- RAX50
|
||||
|
||||
## Basic Info
|
||||
- **Type**: 路由器（网络硬件）
|
||||
- **Manufacturer**: NETGEAR（网件）
|
||||
- **Model**: Nighthawk RAX50
|
||||
- **WiFi Standard**: WiFi 6 (802.11ax)
|
||||
- **Bands**: 双频 (2.4GHz + 5GHz)
|
||||
- **Class**: AX3000
|
||||
|
||||
## Description
|
||||
网件RAX50是一款支持WiFi 6的双频路由器，型号为Nighthawk RAX50。它支持刷入第三方梅林固件以扩展功能，包括安装科学上网插件。
|
||||
|
||||
## Related
|
||||
- [[梅林固件]] — RAX50 支持的第三方固件
|
||||
- [[MerlinClash插件]] — 梅林固件上的科学上网插件
|
||||
- sources: [[网件rax50路由器刷梅林固件与科学上网插件安装教程]]
|
||||
# 网件RAX50
|
||||
|
||||
## Aliases
|
||||
- NETGEAR Nighthawk RAX50
|
||||
- 网件RAX50
|
||||
- RAX50
|
||||
|
||||
## Basic Info
|
||||
- **Type**: 路由器（网络硬件）
|
||||
- **Manufacturer**: NETGEAR（网件）
|
||||
- **Model**: Nighthawk RAX50
|
||||
- **WiFi Standard**: WiFi 6 (802.11ax)
|
||||
- **Bands**: 双频 (2.4GHz + 5GHz)
|
||||
- **Class**: AX3000
|
||||
|
||||
## Description
|
||||
网件RAX50是一款支持WiFi 6的双频路由器，型号为Nighthawk RAX50。它支持刷入第三方梅林固件以扩展功能，包括安装科学上网插件。
|
||||
|
||||
## Related
|
||||
- [[梅林固件]] — RAX50 支持的第三方固件
|
||||
- [[MerlinClash插件]] — 梅林固件上的科学上网插件
|
||||
- sources: [[网件rax50路由器刷梅林固件与科学上网插件安装教程]]
|
||||
|
||||
@@ -1,36 +1,36 @@
|
||||
---
|
||||
title: "阿里云 DNS"
|
||||
type: entity
|
||||
tags: [dns, domain, aliyun, cloud, hosting]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
# 阿里云 DNS
|
||||
|
||||
## Overview
|
||||
**阿里云 DNS**（Alibaba Cloud DNS）是阿里云提供的域名解析服务，用于管理域名的 DNS 记录，将域名指向服务器 IP 地址。本 Wiki 中用于管理 `ishenwei.online` 域名解析。
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：配置 `nas.ishenwei.online` 和 `n8n.ishenwei.online` A 记录指向 RackNerd VPS IP（192.227.222.142）
|
||||
|
||||
## DNS 记录配置示例
|
||||
| 主机记录 | 记录类型 | 记录值 | TTL |
|
||||
|---------|---------|--------|-----|
|
||||
| nas | A | 192.227.222.142 | 600 |
|
||||
| n8n | A | 192.227.222.142 | 600 |
|
||||
| ubuntu1 | A | 192.227.222.142 | 600 |
|
||||
| transmission | A | 192.227.222.142 | 600 |
|
||||
| grafana | A | 192.227.222.142 | 600 |
|
||||
|
||||
## 验证命令
|
||||
```bash
|
||||
dig nas.ishenwei.online +short # 应返回 192.227.222.142
|
||||
```
|
||||
|
||||
## Related Entities
|
||||
- [[RackNerd]]：VPS 提供商，运行托管域名解析目标的公网服务
|
||||
- [[VPS]]：DNS A 记录指向的公网服务器
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：DNS 解析是内网穿透方案的第一步
|
||||
- [[反向代理]]：域名解析后由 Caddy 处理反向代理
|
||||
---
|
||||
title: "阿里云 DNS"
|
||||
type: entity
|
||||
tags: [dns, domain, aliyun, cloud, hosting]
|
||||
last_updated: 2026-04-03
|
||||
---
|
||||
|
||||
# 阿里云 DNS
|
||||
|
||||
## Overview
|
||||
**阿里云 DNS**（Alibaba Cloud DNS）是阿里云提供的域名解析服务，用于管理域名的 DNS 记录，将域名指向服务器 IP 地址。本 Wiki 中用于管理 `ishenwei.online` 域名解析。
|
||||
|
||||
## 在本 Wiki 中的应用
|
||||
- [[通过VPS+内网反向代理实现域名访问内网穿透]]：配置 `nas.ishenwei.online` 和 `n8n.ishenwei.online` A 记录指向 RackNerd VPS IP（192.227.222.142）
|
||||
|
||||
## DNS 记录配置示例
|
||||
| 主机记录 | 记录类型 | 记录值 | TTL |
|
||||
|---------|---------|--------|-----|
|
||||
| nas | A | 192.227.222.142 | 600 |
|
||||
| n8n | A | 192.227.222.142 | 600 |
|
||||
| ubuntu1 | A | 192.227.222.142 | 600 |
|
||||
| transmission | A | 192.227.222.142 | 600 |
|
||||
| grafana | A | 192.227.222.142 | 600 |
|
||||
|
||||
## 验证命令
|
||||
```bash
|
||||
dig nas.ishenwei.online +short # 应返回 192.227.222.142
|
||||
```
|
||||
|
||||
## Related Entities
|
||||
- [[RackNerd]]：VPS 提供商，运行托管域名解析目标的公网服务
|
||||
- [[VPS]]：DNS A 记录指向的公网服务器
|
||||
|
||||
## Related Concepts
|
||||
- [[内网穿透]]：DNS 解析是内网穿透方案的第一步
|
||||
- [[反向代理]]：域名解析后由 Caddy 处理反向代理
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "3X-UI Xray on BandwagonVPS"
|
||||
type: source
|
||||
tags: [vps, xray, 3x-ui, 科学上网, 网络配置]
|
||||
date: 2026-02-10
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/3X-UI Xray on BandwagonVPS]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 BandwagonVPS 上部署 3X-UI 可视化面板管理 Xray 代理服务
|
||||
- 问题域：家庭网络的科学上网解决方案 —— VPS 服务端部署与配置
|
||||
- 方法/机制：通过官方一键安装脚本部署 3X-UI 面板（基于 mhsanaei/3x-ui 项目），使用 VLESS+Reality 协议配置入站规则，启用 BBR 加速，客户端使用 v2rayN（Windows/Linux）和 v2rayNG（Android）连接
|
||||
- 结论/价值：构建稳定、低维护成本的境外网络访问通道，配合 RAX50 路由器 MerlinClash 插件实现全屋透明代理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- BandwagonVPS（AS 104.194.92.x）作为家庭网络科学上网的 VPS 服务端，提供境外流量出口
|
||||
- 3X-UI 面板通过 Web UI 简化 Xray/V2Ray 的配置管理，支持 SSL 证书、BBR、Geo 文件更新等运维操作
|
||||
- VLESS+Reality 是当前抗封锁能力较强的代理协议方案，需要生成公钥/私钥对
|
||||
- Panel 与 xray 服务双进程均需保持 Running 状态才能正常代理
|
||||
- 启用 BBR 拥塞控制算法可提升跨境网络吞吐量和稳定性
|
||||
|
||||
## Key Quotes
|
||||
> "Panel state: Running ✅, xray state: Running ✅, Autostart: Enabled ✅" — 3X-UI 正常运行时三要素状态
|
||||
> "bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)" — 官方一键安装命令
|
||||
|
||||
## Key Concepts
|
||||
- [[3X-UI]]：基于 Go 的 Xray/V2Ray 可视化管理面板，提供 Web UI 和命令行两种管理方式，支持 SSL 证书、BBR、Geo 文件更新等
|
||||
- [[VLESS+Reality]]：一种抗封锁的代理协议方案，需要生成公钥和私钥，是当前较为推荐的配置方式
|
||||
- [[BBR]]：Google 开发的 TCP 拥塞控制算法，通过 `x-ui` → 输入 `23` 启用，可提升跨境网络吞吐量
|
||||
- [[Geo文件]]：Xray 的国家/地区 IP 规则数据库，通过 `x-ui` → 输入 `24` 更新，用于分流和过滤
|
||||
|
||||
## Key Entities
|
||||
- [[BandwagonHost]]：BandwagonHost（又称搬瓦工），美国 VPS 提供商，提供高性价比 KVM VPS
|
||||
- [[VPS2]]：BandwagonVPS 实例，IP 104.194.92.188，域名 kiwi.ishenwei.online，SSH 端口 22
|
||||
- [[3X-UI]]：mhsanaei/3x-ui 开源项目，提供 Xray 可视化管理界面
|
||||
- [[v2rayN]]：Windows/Linux 平台的 Xray/V2Ray 客户端
|
||||
- [[v2rayNG]]：Android 平台的 Xray/V2Ray 客户端
|
||||
|
||||
## Connections
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← depends_on ← [[群晖NAS科学上网方法]]
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← extends ← [[ubuntu-server科学上网]]
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← related_to ← [[网件RAX50路由器刷梅林固件与科学上网插件安装教程]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知内容冲突
|
||||
---
|
||||
title: "3X-UI Xray on BandwagonVPS"
|
||||
type: source
|
||||
tags: [vps, xray, 3x-ui, 科学上网, 网络配置]
|
||||
date: 2026-02-10
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/3X-UI Xray on BandwagonVPS]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 BandwagonVPS 上部署 3X-UI 可视化面板管理 Xray 代理服务
|
||||
- 问题域：家庭网络的科学上网解决方案 —— VPS 服务端部署与配置
|
||||
- 方法/机制：通过官方一键安装脚本部署 3X-UI 面板（基于 mhsanaei/3x-ui 项目），使用 VLESS+Reality 协议配置入站规则，启用 BBR 加速，客户端使用 v2rayN（Windows/Linux）和 v2rayNG（Android）连接
|
||||
- 结论/价值：构建稳定、低维护成本的境外网络访问通道，配合 RAX50 路由器 MerlinClash 插件实现全屋透明代理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- BandwagonVPS（AS 104.194.92.x）作为家庭网络科学上网的 VPS 服务端，提供境外流量出口
|
||||
- 3X-UI 面板通过 Web UI 简化 Xray/V2Ray 的配置管理，支持 SSL 证书、BBR、Geo 文件更新等运维操作
|
||||
- VLESS+Reality 是当前抗封锁能力较强的代理协议方案，需要生成公钥/私钥对
|
||||
- Panel 与 xray 服务双进程均需保持 Running 状态才能正常代理
|
||||
- 启用 BBR 拥塞控制算法可提升跨境网络吞吐量和稳定性
|
||||
|
||||
## Key Quotes
|
||||
> "Panel state: Running ✅, xray state: Running ✅, Autostart: Enabled ✅" — 3X-UI 正常运行时三要素状态
|
||||
> "bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)" — 官方一键安装命令
|
||||
|
||||
## Key Concepts
|
||||
- [[3X-UI]]：基于 Go 的 Xray/V2Ray 可视化管理面板，提供 Web UI 和命令行两种管理方式，支持 SSL 证书、BBR、Geo 文件更新等
|
||||
- [[VLESS+Reality]]：一种抗封锁的代理协议方案，需要生成公钥和私钥，是当前较为推荐的配置方式
|
||||
- [[BBR]]：Google 开发的 TCP 拥塞控制算法，通过 `x-ui` → 输入 `23` 启用，可提升跨境网络吞吐量
|
||||
- [[Geo文件]]：Xray 的国家/地区 IP 规则数据库，通过 `x-ui` → 输入 `24` 更新，用于分流和过滤
|
||||
|
||||
## Key Entities
|
||||
- [[BandwagonHost]]：BandwagonHost（又称搬瓦工），美国 VPS 提供商，提供高性价比 KVM VPS
|
||||
- [[VPS2]]：BandwagonVPS 实例，IP 104.194.92.188，域名 kiwi.ishenwei.online，SSH 端口 22
|
||||
- [[3X-UI]]：mhsanaei/3x-ui 开源项目，提供 Xray 可视化管理界面
|
||||
- [[v2rayN]]：Windows/Linux 平台的 Xray/V2Ray 客户端
|
||||
- [[v2rayNG]]：Android 平台的 Xray/V2Ray 客户端
|
||||
|
||||
## Connections
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← depends_on ← [[群晖NAS科学上网方法]]
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← extends ← [[ubuntu-server科学上网]]
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← related_to ← [[网件RAX50路由器刷梅林固件与科学上网插件安装教程]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知内容冲突
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "Clonezilla对Ubuntu Server进行全盘镜像备份"
|
||||
type: source
|
||||
tags: [backup, clonezilla, nas, rufus, ubuntu]
|
||||
date: 2026-05-06
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Clonezilla（再生龙）对 Ubuntu Server 进行全盘镜像备份到 NAS，灾难时可完整还原系统
|
||||
- 问题域：Linux 服务器数据保护、灾难恢复（DR）、NAS 存储集成
|
||||
- 方法/机制：Clonezilla live USB 启动 → device-image 模式 → NFS 网络存储挂载 → savedisk 全盘镜像 → restordisk 还原
|
||||
- 结论/价值：Clonezilla 提供类似 Ghost 的磁盘级镜像能力，是 rsync 增量备份之外的全量快照方案，两者互补构成完整备份策略
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Rufus 写入 Clonezilla ISO 时必须选择"ISO 镜像模式"，否则可能导致 U 盘启动失败
|
||||
- 针对较新笔记本，分区方案应选 GPT + UEFI（非 CSM）；老旧笔记本选 MBR + BIOS
|
||||
- NFS 是 NAS 备份场景下兼容性最好的网络协议，相比 SMB 更适合 Linux 环境
|
||||
- Clonezilla 备份完成后，新硬盘可通过 restoredisk 完整还原，系统即刻复活，无需重装
|
||||
|
||||
## Key Quotes
|
||||
> "Clonezilla live (Default settings, VGA 800x600)" — Clonezilla 启动菜单推荐选项，英文界面更稳定
|
||||
> "以 ISO 镜像模式写入 (推荐)" — Rufus 写入 ISOHybrid 镜像时的关键选择，DD 模式仅作备选
|
||||
|
||||
## Key Concepts
|
||||
- [[全盘镜像备份]]：将整个磁盘（所有分区 + 数据）打包为单个镜像文件，支持完整灾难恢复
|
||||
- [[NFS 网络存储]]：Network File System，Linux 原生网络文件系统，NAS 共享的标准协议
|
||||
- [[ISOHybrid 镜像]]：同时支持 ISO 和 DD 两种写入模式的混合镜像，Rufus 写入时需注意模式选择
|
||||
- [[GPT vs MBR]]：新一代分区表格式（GPT） vs 传统格式，UEFI 启动需要 GPT 分区
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：开源磁盘镜像工具（再生龙），支持保存和还原整块磁盘镜像
|
||||
- [[Rufus]]：Windows U 盘启动盘制作工具，用于将 Clonezilla ISO 写入 U 盘
|
||||
- [[Ubuntu Server]]：目标备份操作系统，HP ZBook 工作站上运行的服务器版本
|
||||
- [[NFS]]：Network File System，用于将 NAS 存储挂载到 Clonezilla 进行镜像存储
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← 互补方案 ← [[Clonezilla全盘镜像备份]]
|
||||
- Clonezilla 提供全量快照（低频），rsync 提供增量同步（高频），两者构成完整备份策略
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 依赖 ← [[Ubuntu Server]]
|
||||
- Ubuntu Server 是家庭监控系统的运行平台，其备份直接关系到监控系统可用性
|
||||
- [[NFS]] ← 存储后端 ← [[Clonezilla全盘镜像备份]]
|
||||
- NAS 通过 NFS 协议提供镜像存储空间
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Ubuntu服务器通过rsync实现日常增量备份]] 方法层面：
|
||||
- 冲突点：rsync 是文件级增量备份，Clonezilla 是磁盘级全量镜像
|
||||
- 当前观点：两者互补而非互斥——Clonezilla 做周期性全量快照（如每月），rsync 做每日增量同步
|
||||
- 对方观点：rsync 更适合不停机的日常备份场景，Clonezilla 更适合系统迁移或重大变更前的快照
|
||||
---
|
||||
title: "Clonezilla对Ubuntu Server进行全盘镜像备份"
|
||||
type: source
|
||||
tags: [backup, clonezilla, nas, rufus, ubuntu]
|
||||
date: 2026-05-06
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Clonezilla（再生龙）对 Ubuntu Server 进行全盘镜像备份到 NAS，灾难时可完整还原系统
|
||||
- 问题域：Linux 服务器数据保护、灾难恢复（DR）、NAS 存储集成
|
||||
- 方法/机制：Clonezilla live USB 启动 → device-image 模式 → NFS 网络存储挂载 → savedisk 全盘镜像 → restordisk 还原
|
||||
- 结论/价值：Clonezilla 提供类似 Ghost 的磁盘级镜像能力，是 rsync 增量备份之外的全量快照方案，两者互补构成完整备份策略
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Rufus 写入 Clonezilla ISO 时必须选择"ISO 镜像模式"，否则可能导致 U 盘启动失败
|
||||
- 针对较新笔记本，分区方案应选 GPT + UEFI（非 CSM）；老旧笔记本选 MBR + BIOS
|
||||
- NFS 是 NAS 备份场景下兼容性最好的网络协议，相比 SMB 更适合 Linux 环境
|
||||
- Clonezilla 备份完成后，新硬盘可通过 restoredisk 完整还原，系统即刻复活，无需重装
|
||||
|
||||
## Key Quotes
|
||||
> "Clonezilla live (Default settings, VGA 800x600)" — Clonezilla 启动菜单推荐选项，英文界面更稳定
|
||||
> "以 ISO 镜像模式写入 (推荐)" — Rufus 写入 ISOHybrid 镜像时的关键选择，DD 模式仅作备选
|
||||
|
||||
## Key Concepts
|
||||
- [[全盘镜像备份]]：将整个磁盘（所有分区 + 数据）打包为单个镜像文件，支持完整灾难恢复
|
||||
- [[NFS 网络存储]]：Network File System，Linux 原生网络文件系统，NAS 共享的标准协议
|
||||
- [[ISOHybrid 镜像]]：同时支持 ISO 和 DD 两种写入模式的混合镜像，Rufus 写入时需注意模式选择
|
||||
- [[GPT vs MBR]]：新一代分区表格式（GPT） vs 传统格式，UEFI 启动需要 GPT 分区
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：开源磁盘镜像工具（再生龙），支持保存和还原整块磁盘镜像
|
||||
- [[Rufus]]：Windows U 盘启动盘制作工具，用于将 Clonezilla ISO 写入 U 盘
|
||||
- [[Ubuntu Server]]：目标备份操作系统，HP ZBook 工作站上运行的服务器版本
|
||||
- [[NFS]]：Network File System，用于将 NAS 存储挂载到 Clonezilla 进行镜像存储
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← 互补方案 ← [[Clonezilla全盘镜像备份]]
|
||||
- Clonezilla 提供全量快照（低频），rsync 提供增量同步（高频），两者构成完整备份策略
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 依赖 ← [[Ubuntu Server]]
|
||||
- Ubuntu Server 是家庭监控系统的运行平台，其备份直接关系到监控系统可用性
|
||||
- [[NFS]] ← 存储后端 ← [[Clonezilla全盘镜像备份]]
|
||||
- NAS 通过 NFS 协议提供镜像存储空间
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Ubuntu服务器通过rsync实现日常增量备份]] 方法层面：
|
||||
- 冲突点：rsync 是文件级增量备份，Clonezilla 是磁盘级全量镜像
|
||||
- 当前观点：两者互补而非互斥——Clonezilla 做周期性全量快照（如每月），rsync 做每日增量同步
|
||||
- 对方观点：rsync 更适合不停机的日常备份场景，Clonezilla 更适合系统迁移或重大变更前的快照
|
||||
|
||||
@@ -1,49 +1,49 @@
|
||||
---
|
||||
title: "Cloud DevOp Maturity - Guideline"
|
||||
type: source
|
||||
tags: [cloud, devops, maturity, enterprise, saas]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Cloud DevOp Maturity - Guideline.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：企业级 SaaS 公司的云 DevOps 成熟度评估框架与提升路径
|
||||
- 问题域：如何定义、衡量和提升云端 DevOps 实践的成熟度
|
||||
- 方法/机制：基于 DORA 四大指标（部署频率、变更前置时间、变更失败率、平均恢复时间）和 CMMI 成熟度模型，从自动化、协作文化、监控可观测性、安全集成四大支柱进行评估
|
||||
- 结论/价值：DevOps 成熟度提升是持续迭代过程，需分阶段实施，从 CI/CD 和自动化入手，逐步建立 DevOps 卓越中心
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 企业通过评估 DevOps 成熟度，可缩短上市时间、提升运营效率并增强产品可靠性
|
||||
- DORA 四项核心指标（部署频率、变更前置时间、变更失败率、MTTR）是衡量 DevOps 绩效的行业标准
|
||||
- 成熟的 DevOps 组织需在自动化（CI/CD、IaC、测试自动化）、跨团队协作与文化、监控可观测性、安全集成（DevSecOps）四大支柱上均衡发展
|
||||
- 云原生架构（微服务、容器化、无服务器技术）可加速 DevOps 成熟度提升
|
||||
- DevOps 成熟度提升路径包括：进行成熟度评估 → 建立 DevOps 卓越中心 → 分阶段实施改进（从 CI/CD 和自动化开始）→ 持续迭代
|
||||
|
||||
## Key Quotes
|
||||
> "Focus on CI/CD pipelines, infrastructure as code (IaC), and test automation. Emphasize the importance of repeatable and reliable deployments." — 自动化是成熟 DevOps 的基石
|
||||
> "DevOps is a continuous improvement process, and even mature companies need to adapt to evolving technologies and practices." — DevOps 成熟度提升是持续迭代过程
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOpsMaturityModel]]：CMMI 和 DORA 模型定义的组织 DevOps 能力成熟度等级体系
|
||||
- [[DORAMetrics]]：DevOps Research & Assessment 的四大核心指标——部署频率、变更前置时间、变更失败率、平均恢复时间（MTTR）
|
||||
- [[CI/CDPipeline]]：持续集成/持续交付流水线，DevOps 自动化的核心机制
|
||||
- [[InfrastructureAsCode]]：通过代码管理基础设施，实现环境一致性和可重复部署
|
||||
- [[DevSecOps]]：将安全集成到 DevOps 全生命周期，实现持续安全合规
|
||||
- [[MicroservicesArchitecture]]：云原生微服务架构，支持独立部署和快速迭代
|
||||
- [[Observability]]：可观测性，通过持续监控、日志和追踪快速发现和解决生产问题
|
||||
|
||||
## Key Entities
|
||||
- [[CMMI]]：Capability Maturity Model Integration，能力成熟度模型集成，用于定义组织过程改进的成熟度等级
|
||||
- [[DORA]]：DevOps Research & Assessment，DevOps 研究与评估组织，提供行业标准的 DevOps 绩效指标
|
||||
|
||||
## Connections
|
||||
- [[DevOpsMaturityModel]] ← based_on ← [[DORAMetrics]]
|
||||
- [[CI/CDPipeline]] ← core_enabler ← [[DevOpsMaturityModel]]
|
||||
- [[InfrastructureAsCode]] ← supports ← [[CI/CDPipeline]]
|
||||
- [[DevSecOps]] ← extends ← [[DevOpsMaturityModel]]
|
||||
- [[MicroservicesArchitecture]] ← architectural_pattern ← [[CloudNativePractices]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知的 Wiki 内冲突内容
|
||||
---
|
||||
title: "Cloud DevOp Maturity - Guideline"
|
||||
type: source
|
||||
tags: [cloud, devops, maturity, enterprise, saas]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Cloud DevOp Maturity - Guideline.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：企业级 SaaS 公司的云 DevOps 成熟度评估框架与提升路径
|
||||
- 问题域：如何定义、衡量和提升云端 DevOps 实践的成熟度
|
||||
- 方法/机制：基于 DORA 四大指标（部署频率、变更前置时间、变更失败率、平均恢复时间）和 CMMI 成熟度模型，从自动化、协作文化、监控可观测性、安全集成四大支柱进行评估
|
||||
- 结论/价值：DevOps 成熟度提升是持续迭代过程，需分阶段实施，从 CI/CD 和自动化入手，逐步建立 DevOps 卓越中心
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 企业通过评估 DevOps 成熟度，可缩短上市时间、提升运营效率并增强产品可靠性
|
||||
- DORA 四项核心指标（部署频率、变更前置时间、变更失败率、MTTR）是衡量 DevOps 绩效的行业标准
|
||||
- 成熟的 DevOps 组织需在自动化（CI/CD、IaC、测试自动化）、跨团队协作与文化、监控可观测性、安全集成（DevSecOps）四大支柱上均衡发展
|
||||
- 云原生架构（微服务、容器化、无服务器技术）可加速 DevOps 成熟度提升
|
||||
- DevOps 成熟度提升路径包括：进行成熟度评估 → 建立 DevOps 卓越中心 → 分阶段实施改进（从 CI/CD 和自动化开始）→ 持续迭代
|
||||
|
||||
## Key Quotes
|
||||
> "Focus on CI/CD pipelines, infrastructure as code (IaC), and test automation. Emphasize the importance of repeatable and reliable deployments." — 自动化是成熟 DevOps 的基石
|
||||
> "DevOps is a continuous improvement process, and even mature companies need to adapt to evolving technologies and practices." — DevOps 成熟度提升是持续迭代过程
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOpsMaturityModel]]：CMMI 和 DORA 模型定义的组织 DevOps 能力成熟度等级体系
|
||||
- [[DORAMetrics]]：DevOps Research & Assessment 的四大核心指标——部署频率、变更前置时间、变更失败率、平均恢复时间（MTTR）
|
||||
- [[CI/CDPipeline]]：持续集成/持续交付流水线，DevOps 自动化的核心机制
|
||||
- [[InfrastructureAsCode]]：通过代码管理基础设施，实现环境一致性和可重复部署
|
||||
- [[DevSecOps]]：将安全集成到 DevOps 全生命周期，实现持续安全合规
|
||||
- [[MicroservicesArchitecture]]：云原生微服务架构，支持独立部署和快速迭代
|
||||
- [[Observability]]：可观测性，通过持续监控、日志和追踪快速发现和解决生产问题
|
||||
|
||||
## Key Entities
|
||||
- [[CMMI]]：Capability Maturity Model Integration，能力成熟度模型集成，用于定义组织过程改进的成熟度等级
|
||||
- [[DORA]]：DevOps Research & Assessment，DevOps 研究与评估组织，提供行业标准的 DevOps 绩效指标
|
||||
|
||||
## Connections
|
||||
- [[DevOpsMaturityModel]] ← based_on ← [[DORAMetrics]]
|
||||
- [[CI/CDPipeline]] ← core_enabler ← [[DevOpsMaturityModel]]
|
||||
- [[InfrastructureAsCode]] ← supports ← [[CI/CDPipeline]]
|
||||
- [[DevSecOps]] ← extends ← [[DevOpsMaturityModel]]
|
||||
- [[MicroservicesArchitecture]] ← architectural_pattern ← [[CloudNativePractices]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知的 Wiki 内冲突内容
|
||||
|
||||
@@ -1,84 +1,84 @@
|
||||
---
|
||||
title: "Cloud Maturity Model - A Detailed Guide For Cloud Adoption"
|
||||
type: source
|
||||
tags: [Cloud, Cloud Adoption, Maturity Model, CMM, Cloud Native, CSMM, SAMM, AWS CAF, Azure CAF, GCP CAF]
|
||||
date: 2024-07-08
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
|
||||
- **核心主题**：Cloud Maturity Model（CMM）云成熟度模型——系统性评估企业云采用成熟度并指导其向更高阶段演进的结构化框架
|
||||
- **问题域**：企业云转型过程中，如何评估当前状态、识别差距、制定演进路线
|
||||
- **方法/机制**：5级成熟度模型（Level 0–5）从业务维度（财务/战略/组织/文化/治理/合规/采购）和技术维度（架构/应用/DevOps/安全/IaaS/PaaS/SaaS/AI/IoT）进行三维评估（People/Processes/Technology）；7大收益；最佳实践；7种主流成熟度模型对比
|
||||
- **结论/价值**：CMM 是云转型成功的导航仪，帮助企业找到适合自身需求的平衡点，避免盲目追高或止步不前
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
|
||||
- Forrester 预测全球云成熟度模型行业到 2025 年将达 15 亿美元，反映企业云成熟度管理的巨大市场需求
|
||||
- Gartner 指出超过 60% 的组织正在积极实施云成熟度模型，说明其已成为云转型主流实践
|
||||
- Open Alliance for Cloud Adoption（OACA）定义的 CMM 帮助组织识别云采用痛点、评估当前状态、设定未来目标并执行 GAP 分析
|
||||
- 云成熟度模型不是追求完全上云，而是找到适合组织需求的平衡点
|
||||
- Level 5 是目标但往往更具理想性，建议选择性采纳带来明确业务价值的要素，避免跨越低级别导致后续挑战
|
||||
- 跨越低级别（如管理和流程定义）可能导致后续成熟度旅程中的挑战和不必要的成本
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "CMMs are crucial because they offer a structured approach to assessing your current cloud adoption strategy. They help you avoid common pitfalls and identify areas of improvement." — CMM 的核心价值定位
|
||||
|
||||
> "It is common for organizations only partially to reach level 4. Some parts of their cloud capabilities may still be at levels 2 or 3." — Level 4 部分成熟现象
|
||||
|
||||
> "Achieving this fifth level is often more aspirational than real for many." — Level 5 的理想与现实差距
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[Cloud Adoption]]：云采用——组织将工作负载和服务迁移至云平台并持续优化的过程
|
||||
- [[Cloud Migration]]：云迁移——将应用/数据/工作负载从本地迁移至云端的具体行动
|
||||
- [[Cloud Governance]]：云治理——建立云环境中的策略、角色、风险管理框架
|
||||
- [[Cloud Security]]：云安全——云环境中的数据保护、访问控制、合规遵循
|
||||
- [[FinOps]]：云财务管理——云资源使用的成本优化与财务可见性管理
|
||||
- [[Cloud-Native]]：云原生——充分利用云平台弹性、可扩展、自动化特性的架构方法
|
||||
- [[Cloud Cost Optimization]]：云成本优化——通过右置资源、自动化、监控实现云支出效率最大化
|
||||
- [[Multi-Cloud Strategy]]：多云策略——同时使用多个云服务商以避免供应商锁定
|
||||
- [[Hybrid Cloud]]：混合云——结合公有云弹性与私有云合规/安全的混合部署模式
|
||||
- [[People-Process-Technology]]：人-流程-技术三维评估框架——评估组织云成熟度的三个核心维度
|
||||
- [[Cloud Center of Excellence]]（CCoE）：云卓越中心——推动组织云能力的跨职能专家团队
|
||||
- [[GAP Analysis]]：差距分析——评估当前状态与目标状态之间差距的系统性方法
|
||||
- [[Cloud Compliance]]：云合规——确保云操作符合 HIPAA/PCI-DSS 等行业法规
|
||||
- [[CAPEX vs OPEX]]：资本支出 vs 运营支出——云迁移带来的财务模式转变
|
||||
- [[TCO (Total Cost of Ownership)]]：总拥有成本——包含直接成本、间接成本、隐性成本的全成本视角
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[Cloud Maturity Model]]：主体框架——5级成熟度评估模型
|
||||
- [[Cloud Native Maturity Model]]：CNCF 云原生成熟度模型——指导云原生技术采用的专项模型
|
||||
- [[Cloud Security Maturity Model]]（CSMM）：云安全成熟度模型——IANS/Securosis 的云安全评估框架
|
||||
- [[Software Assurance Maturity Model]]（SAMM）：软件保障成熟度模型——覆盖完整软件生命周期的技术/流程中立框架
|
||||
- [[AWS Cloud Adoption Framework]]（AWS CAF）：AWS 云采用框架——AWS 提供的云转型指导
|
||||
- [[Azure Cloud Adoption Framework]]（Azure CAF）：Azure 云采用框架——Microsoft Azure 提供的云转型最佳实践
|
||||
- [[Google Cloud Adoption Framework]]（GCP CAF）：Google Cloud 云采用框架——Google Cloud 的云转型路线
|
||||
- [[Open Alliance for Cloud Adoption]]（OACA）：云采用联盟——定义 CMM 的行业组织
|
||||
- [[Cloud Maturity Levels]]：成熟度5级——Level 0（Legacy）→ Level 5（Optimized）
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Cloud Maturity Model]] ← evaluates ← [[Cloud Adoption Strategy]]
|
||||
- [[Cloud Maturity Model]] ← defined_by ← [[Open Alliance for Cloud Adoption]]
|
||||
- [[Cloud Maturity Levels]] ← part_of ← [[Cloud Maturity Model]]
|
||||
- [[Cloud Native Maturity Model]] ← extends ← [[Cloud Maturity Model]]（专项领域扩展）
|
||||
- [[Cloud Security Maturity Model]] ← extends ← [[Cloud Maturity Model]]（安全专项）
|
||||
- [[AWS Cloud Adoption Framework]] ← competes_with ← [[Azure Cloud Adoption Framework]]
|
||||
- [[AWS Cloud Adoption Framework]] ← competes_with ← [[Google Cloud Adoption Framework]]
|
||||
- [[Cloud Cost Optimization]] ← enables ← [[FinOps]]
|
||||
- [[Cloud Governance]] ← depends_on ← [[Cloud Compliance]]
|
||||
- [[DevOps Maturity Model]] ← related_to ← [[Cloud Maturity Model]]（两者均评估组织技术能力成熟度）
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 与 [[DevOps Maturity Model]] 在"成熟度框架"上的视角差异：
|
||||
- 冲突点：DevOps 成熟度聚焦研发交付能力，CMM 聚焦云采用整体成熟度
|
||||
- 当前观点（本文）：CMM 是云转型的全面导航，覆盖人员/流程/技术全维度
|
||||
- 对方观点（DevOps）：DevOps 成熟度更聚焦软件交付速度和稳定性
|
||||
- 说明：两者为互补关系而非互斥，组织可同时评估和提升两个维度的成熟度
|
||||
---
|
||||
title: "Cloud Maturity Model - A Detailed Guide For Cloud Adoption"
|
||||
type: source
|
||||
tags: [Cloud, Cloud Adoption, Maturity Model, CMM, Cloud Native, CSMM, SAMM, AWS CAF, Azure CAF, GCP CAF]
|
||||
date: 2024-07-08
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
|
||||
- **核心主题**：Cloud Maturity Model（CMM）云成熟度模型——系统性评估企业云采用成熟度并指导其向更高阶段演进的结构化框架
|
||||
- **问题域**：企业云转型过程中，如何评估当前状态、识别差距、制定演进路线
|
||||
- **方法/机制**：5级成熟度模型（Level 0–5）从业务维度（财务/战略/组织/文化/治理/合规/采购）和技术维度（架构/应用/DevOps/安全/IaaS/PaaS/SaaS/AI/IoT）进行三维评估（People/Processes/Technology）；7大收益；最佳实践；7种主流成熟度模型对比
|
||||
- **结论/价值**：CMM 是云转型成功的导航仪，帮助企业找到适合自身需求的平衡点，避免盲目追高或止步不前
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
|
||||
- Forrester 预测全球云成熟度模型行业到 2025 年将达 15 亿美元，反映企业云成熟度管理的巨大市场需求
|
||||
- Gartner 指出超过 60% 的组织正在积极实施云成熟度模型，说明其已成为云转型主流实践
|
||||
- Open Alliance for Cloud Adoption（OACA）定义的 CMM 帮助组织识别云采用痛点、评估当前状态、设定未来目标并执行 GAP 分析
|
||||
- 云成熟度模型不是追求完全上云，而是找到适合组织需求的平衡点
|
||||
- Level 5 是目标但往往更具理想性，建议选择性采纳带来明确业务价值的要素，避免跨越低级别导致后续挑战
|
||||
- 跨越低级别（如管理和流程定义）可能导致后续成熟度旅程中的挑战和不必要的成本
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "CMMs are crucial because they offer a structured approach to assessing your current cloud adoption strategy. They help you avoid common pitfalls and identify areas of improvement." — CMM 的核心价值定位
|
||||
|
||||
> "It is common for organizations only partially to reach level 4. Some parts of their cloud capabilities may still be at levels 2 or 3." — Level 4 部分成熟现象
|
||||
|
||||
> "Achieving this fifth level is often more aspirational than real for many." — Level 5 的理想与现实差距
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[Cloud Adoption]]：云采用——组织将工作负载和服务迁移至云平台并持续优化的过程
|
||||
- [[Cloud Migration]]：云迁移——将应用/数据/工作负载从本地迁移至云端的具体行动
|
||||
- [[Cloud Governance]]：云治理——建立云环境中的策略、角色、风险管理框架
|
||||
- [[Cloud Security]]：云安全——云环境中的数据保护、访问控制、合规遵循
|
||||
- [[FinOps]]：云财务管理——云资源使用的成本优化与财务可见性管理
|
||||
- [[Cloud-Native]]：云原生——充分利用云平台弹性、可扩展、自动化特性的架构方法
|
||||
- [[Cloud Cost Optimization]]：云成本优化——通过右置资源、自动化、监控实现云支出效率最大化
|
||||
- [[Multi-Cloud Strategy]]：多云策略——同时使用多个云服务商以避免供应商锁定
|
||||
- [[Hybrid Cloud]]：混合云——结合公有云弹性与私有云合规/安全的混合部署模式
|
||||
- [[People-Process-Technology]]：人-流程-技术三维评估框架——评估组织云成熟度的三个核心维度
|
||||
- [[Cloud Center of Excellence]]（CCoE）：云卓越中心——推动组织云能力的跨职能专家团队
|
||||
- [[GAP Analysis]]：差距分析——评估当前状态与目标状态之间差距的系统性方法
|
||||
- [[Cloud Compliance]]：云合规——确保云操作符合 HIPAA/PCI-DSS 等行业法规
|
||||
- [[CAPEX vs OPEX]]：资本支出 vs 运营支出——云迁移带来的财务模式转变
|
||||
- [[TCO (Total Cost of Ownership)]]：总拥有成本——包含直接成本、间接成本、隐性成本的全成本视角
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[Cloud Maturity Model]]：主体框架——5级成熟度评估模型
|
||||
- [[Cloud Native Maturity Model]]：CNCF 云原生成熟度模型——指导云原生技术采用的专项模型
|
||||
- [[Cloud Security Maturity Model]]（CSMM）：云安全成熟度模型——IANS/Securosis 的云安全评估框架
|
||||
- [[Software Assurance Maturity Model]]（SAMM）：软件保障成熟度模型——覆盖完整软件生命周期的技术/流程中立框架
|
||||
- [[AWS Cloud Adoption Framework]]（AWS CAF）：AWS 云采用框架——AWS 提供的云转型指导
|
||||
- [[Azure Cloud Adoption Framework]]（Azure CAF）：Azure 云采用框架——Microsoft Azure 提供的云转型最佳实践
|
||||
- [[Google Cloud Adoption Framework]]（GCP CAF）：Google Cloud 云采用框架——Google Cloud 的云转型路线
|
||||
- [[Open Alliance for Cloud Adoption]]（OACA）：云采用联盟——定义 CMM 的行业组织
|
||||
- [[Cloud Maturity Levels]]：成熟度5级——Level 0（Legacy）→ Level 5（Optimized）
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Cloud Maturity Model]] ← evaluates ← [[Cloud Adoption Strategy]]
|
||||
- [[Cloud Maturity Model]] ← defined_by ← [[Open Alliance for Cloud Adoption]]
|
||||
- [[Cloud Maturity Levels]] ← part_of ← [[Cloud Maturity Model]]
|
||||
- [[Cloud Native Maturity Model]] ← extends ← [[Cloud Maturity Model]]（专项领域扩展）
|
||||
- [[Cloud Security Maturity Model]] ← extends ← [[Cloud Maturity Model]]（安全专项）
|
||||
- [[AWS Cloud Adoption Framework]] ← competes_with ← [[Azure Cloud Adoption Framework]]
|
||||
- [[AWS Cloud Adoption Framework]] ← competes_with ← [[Google Cloud Adoption Framework]]
|
||||
- [[Cloud Cost Optimization]] ← enables ← [[FinOps]]
|
||||
- [[Cloud Governance]] ← depends_on ← [[Cloud Compliance]]
|
||||
- [[DevOps Maturity Model]] ← related_to ← [[Cloud Maturity Model]]（两者均评估组织技术能力成熟度）
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 与 [[DevOps Maturity Model]] 在"成熟度框架"上的视角差异：
|
||||
- 冲突点：DevOps 成熟度聚焦研发交付能力，CMM 聚焦云采用整体成熟度
|
||||
- 当前观点（本文）：CMM 是云转型的全面导航，覆盖人员/流程/技术全维度
|
||||
- 对方观点（DevOps）：DevOps 成熟度更聚焦软件交付速度和稳定性
|
||||
- 说明：两者为互补关系而非互斥，组织可同时评估和提升两个维度的成熟度
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "Cursor 2.0初学者使用指南"
|
||||
type: source
|
||||
tags: [ai, cursor, ide, mcp]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Cursor 2.0初学者使用指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Cursor 2.0 AI代码编辑器的初学者完整使用教程，涵盖安装、界面、多代理操作、代码生成、审查与版本控制流程。
|
||||
- 问题域：AI辅助编程工具的入门学习，聚焦于如何高效使用Cursor的AI代理功能进行项目开发。
|
||||
- 方法/机制：通过Plan模式规划任务 → Agent模式执行代码生成 → Diff审查改动 → Git版本控制回滚的完整工作流。
|
||||
- 结论/价值：Cursor 2.0为开发者提供了一条从想法到实现的AI智能化路径，是现代AI辅助编程的重要工具。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Cursor基于VS Code构建，可免费使用，支持付费升级获取更多生成额度。
|
||||
- Cursor新增自有AI模型Composer，强调其速度优势（比同类模型快4倍）。
|
||||
- 多代理功能可以同时运行不同任务，互不干扰，提升代码生成效率。
|
||||
- AI代理支持三种模式：Plan（规划）、Agent（执行，会修改文件）、Ask（咨询，不改代码）。
|
||||
- 代码生成后进入待审查状态，可使用Diff功能逐个审查或整体接收改动。
|
||||
- MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。
|
||||
- 可设定项目规则（如强制为函数生成文档注释），实现代码规范自动化。
|
||||
|
||||
## Key Quotes
|
||||
> "Cursor是基于VS Code的AI代码编辑器，可免费使用，支持付费升级以获取更多生成额度。" — Cursor基本特性介绍
|
||||
> "启动构建任务时生成新代理，执行计划步骤。多代理功能可以同时运行不同任务，互不干扰。" — 多代理并行操作
|
||||
> "生成代码后进入待审查状态，可使用Diff功能查看具体改动，支持文件逐个审查或整体接收。" — 代码审查流程
|
||||
> "MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。" — MCP扩展能力
|
||||
|
||||
## Key Concepts
|
||||
- [[多代理并行]]：可同时运行不同AI代理任务，互不干扰，适合多线程项目开发。
|
||||
- [[Diff审查]]：通过Diff视图查看AI生成的代码改动，逐个文件或整体接收变更。
|
||||
- [[项目规则]]：自定义项目规则文件（如强制生成文档注释），实现代码规范自动化。
|
||||
- [[MCP服务器]]：Model Context Protocol，支持将外部API和工具集成到AI代理。
|
||||
|
||||
## Key Entities
|
||||
- [[Cursor]]：基于VS Code的AI增强代码编辑器，支持多代理并行操作和Composer自研模型。
|
||||
- [[VS Code]]：Cursor构建的基础编辑器，Cursor继承其完整功能。
|
||||
- [[Composer]]：Cursor自研AI模型，主打生成速度优势（比同类快4倍）。
|
||||
|
||||
## Connections
|
||||
- [[Cursor]] ← extends ← [[VS Code]]
|
||||
- [[Cursor]] ← uses ← [[Composer]]
|
||||
- [[Cursor]] ← supports ← [[MCP（Model Context Protocol）]]
|
||||
- [[Cursor]] ← enables ← [[Vibe Coding]]
|
||||
- [[Cursor]] ← similar_to ← [[Claude Code]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。本文档聚焦Cursor入门操作，与 [[MCP在Cursor中的集成与应用详解]] 互补（后者侧重MCP集成深度应用）。
|
||||
---
|
||||
title: "Cursor 2.0初学者使用指南"
|
||||
type: source
|
||||
tags: [ai, cursor, ide, mcp]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Cursor 2.0初学者使用指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Cursor 2.0 AI代码编辑器的初学者完整使用教程，涵盖安装、界面、多代理操作、代码生成、审查与版本控制流程。
|
||||
- 问题域：AI辅助编程工具的入门学习，聚焦于如何高效使用Cursor的AI代理功能进行项目开发。
|
||||
- 方法/机制：通过Plan模式规划任务 → Agent模式执行代码生成 → Diff审查改动 → Git版本控制回滚的完整工作流。
|
||||
- 结论/价值：Cursor 2.0为开发者提供了一条从想法到实现的AI智能化路径，是现代AI辅助编程的重要工具。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Cursor基于VS Code构建，可免费使用，支持付费升级获取更多生成额度。
|
||||
- Cursor新增自有AI模型Composer，强调其速度优势（比同类模型快4倍）。
|
||||
- 多代理功能可以同时运行不同任务，互不干扰，提升代码生成效率。
|
||||
- AI代理支持三种模式：Plan（规划）、Agent（执行，会修改文件）、Ask（咨询，不改代码）。
|
||||
- 代码生成后进入待审查状态，可使用Diff功能逐个审查或整体接收改动。
|
||||
- MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。
|
||||
- 可设定项目规则（如强制为函数生成文档注释），实现代码规范自动化。
|
||||
|
||||
## Key Quotes
|
||||
> "Cursor是基于VS Code的AI代码编辑器，可免费使用，支持付费升级以获取更多生成额度。" — Cursor基本特性介绍
|
||||
> "启动构建任务时生成新代理，执行计划步骤。多代理功能可以同时运行不同任务，互不干扰。" — 多代理并行操作
|
||||
> "生成代码后进入待审查状态，可使用Diff功能查看具体改动，支持文件逐个审查或整体接收。" — 代码审查流程
|
||||
> "MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。" — MCP扩展能力
|
||||
|
||||
## Key Concepts
|
||||
- [[多代理并行]]：可同时运行不同AI代理任务，互不干扰，适合多线程项目开发。
|
||||
- [[Diff审查]]：通过Diff视图查看AI生成的代码改动，逐个文件或整体接收变更。
|
||||
- [[项目规则]]：自定义项目规则文件（如强制生成文档注释），实现代码规范自动化。
|
||||
- [[MCP服务器]]：Model Context Protocol，支持将外部API和工具集成到AI代理。
|
||||
|
||||
## Key Entities
|
||||
- [[Cursor]]：基于VS Code的AI增强代码编辑器，支持多代理并行操作和Composer自研模型。
|
||||
- [[VS Code]]：Cursor构建的基础编辑器，Cursor继承其完整功能。
|
||||
- [[Composer]]：Cursor自研AI模型，主打生成速度优势（比同类快4倍）。
|
||||
|
||||
## Connections
|
||||
- [[Cursor]] ← extends ← [[VS Code]]
|
||||
- [[Cursor]] ← uses ← [[Composer]]
|
||||
- [[Cursor]] ← supports ← [[MCP（Model Context Protocol）]]
|
||||
- [[Cursor]] ← enables ← [[Vibe Coding]]
|
||||
- [[Cursor]] ← similar_to ← [[Claude Code]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。本文档聚焦Cursor入门操作，与 [[MCP在Cursor中的集成与应用详解]] 互补（后者侧重MCP集成深度应用）。
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps 文化转型 —— 如何通过打破开发与运维之间的壁垒，推动组织实现更快、更可靠的软件交付与持续创新。
|
||||
- 问题域：传统 IT 组织中开发团队与运维团队的目标冲突（开发追求快速交付，运维追求稳定），以及组织文化变革的挑战。
|
||||
- 方法/机制：四大 DevOps 文化支柱（协作、自动化、持续改进、客户导向）；Agile 与 DevOps 的融合实践；战略转型 playbook（领导层支持、团队赋能、小步试点、克服阻力）。
|
||||
- 结论/价值：DevOps 不仅是工具和自动化，而是一场文化变革；拥抱 DevOps 文化 tenets、赋能团队、整合 Agile 实践的组织将在数字时代获得竞争优势。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps 通过建立跨职能团队，使开发和运维共同承担整个软件生命周期的责任，从而打破传统 IT 组织中的孤岛现象。
|
||||
- 自动化（CI/CD 流水线、基础设施即代码、可观测性工具）是 DevOps 的核心驱动力，能消除人工重复劳动、减少错误、加速反馈循环。
|
||||
- DevOps 强调持续改进（Kaizen），通过无责事后分析（blameless post-mortems）、数据指标和混沌工程驱动团队迭代学习。
|
||||
- Agile 与 DevOps 具有共生关系 —— Agile 关注迭代开发，DevOps 将敏捷延伸到运维，两者共同实现端到端的速度与质量。
|
||||
- DevOps 转型需要领导层支持、小步试点快速验证、用成功案例建立势能，而非一次性大爆炸式推行。
|
||||
- DevOps 的未来趋势包括：AI/ML 赋能智能自动化、GitOps、Serverless DevOps、边缘计算与 IoT DevOps、以及 DevSecOps 的深化。
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity." — 核心论点：DevOps 本质是文化与思维转变
|
||||
> "Blameless post-mortems to dissect failures without finger-pointing." — DevOps 文化的关键实践：无惧失败、聚焦改进
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps Culture]]：一种打破开发与运维壁垒、以协作、自动化、持续学习和客户导向为核心的文化与运营模式
|
||||
- [[CI/CD Pipeline]]：自动化测试、集成和部署流水线，是 DevOps 自动化能力的关键实现
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施，实现一致性和版本控制的实践
|
||||
- [[Kaizen (Continuous Improvement)]]：持续改进理念，通过无责复盘、数据驱动决策和混沌工程推动迭代优化
|
||||
- [[Shift-Left]]：将安全、性能等运维关注点前移至开发阶段，DevSecOps 是其典型实践
|
||||
- [[Value Stream Mapping]]：价值流图析，通过可视化工作流识别等待、审批和测试环节的延迟，消除浪费
|
||||
- [[GitOps]]：使用 Git 作为唯一真实来源来管理基础设施和部署的运维模式，是 DevOps 的进化方向之一
|
||||
- [[Serverless DevOps]]：利用函数即服务（FaaS）等无服务器技术减少运维负担的 DevOps 实践
|
||||
- [[Agile-DevOps Integration]]：Agile 与 DevOps 的协同机制，Scrum/Kanban 提供方法论框架，CI/CD 提供工程加速能力
|
||||
|
||||
## Key Entities
|
||||
- [[Hemant Sawant]]：LinkedIn 文章原作者，DevOps 文化与转型领域的分享者
|
||||
- [[Shenwei]]：本文档的保存整理者
|
||||
|
||||
## Connections
|
||||
- [[DevOps Maturity Model]] ← extends ← [[DevOps Culture]]：本文聚焦 DevOps 文化转型，与成熟度模型互为补充（文化层 vs 能力层级）
|
||||
- [[DevSecOps Best Practices]] ← depends_on ← [[DevOps Culture]]：DevSecOps 是 DevOps 文化中"安全性嵌入"支柱的具体实现
|
||||
- [[Agile-DevOps Integration]] ← extends ← [[DevOps Culture]]：Agile 与 DevOps 的融合是本文第二大主题
|
||||
- [[How Agentic AI Can Help Cloud DevOps]] ← relates_to ← [[DevOps Culture]]：AI/ML 赋能 DevOps 是本文未来趋势之一
|
||||
|
||||
## Contradictions
|
||||
- （本文档为新摄入来源，暂无已知冲突点）
|
||||
---
|
||||
title: "DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps 文化转型 —— 如何通过打破开发与运维之间的壁垒，推动组织实现更快、更可靠的软件交付与持续创新。
|
||||
- 问题域：传统 IT 组织中开发团队与运维团队的目标冲突（开发追求快速交付，运维追求稳定），以及组织文化变革的挑战。
|
||||
- 方法/机制：四大 DevOps 文化支柱（协作、自动化、持续改进、客户导向）；Agile 与 DevOps 的融合实践；战略转型 playbook（领导层支持、团队赋能、小步试点、克服阻力）。
|
||||
- 结论/价值：DevOps 不仅是工具和自动化，而是一场文化变革；拥抱 DevOps 文化 tenets、赋能团队、整合 Agile 实践的组织将在数字时代获得竞争优势。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps 通过建立跨职能团队，使开发和运维共同承担整个软件生命周期的责任，从而打破传统 IT 组织中的孤岛现象。
|
||||
- 自动化（CI/CD 流水线、基础设施即代码、可观测性工具）是 DevOps 的核心驱动力，能消除人工重复劳动、减少错误、加速反馈循环。
|
||||
- DevOps 强调持续改进（Kaizen），通过无责事后分析（blameless post-mortems）、数据指标和混沌工程驱动团队迭代学习。
|
||||
- Agile 与 DevOps 具有共生关系 —— Agile 关注迭代开发，DevOps 将敏捷延伸到运维，两者共同实现端到端的速度与质量。
|
||||
- DevOps 转型需要领导层支持、小步试点快速验证、用成功案例建立势能，而非一次性大爆炸式推行。
|
||||
- DevOps 的未来趋势包括：AI/ML 赋能智能自动化、GitOps、Serverless DevOps、边缘计算与 IoT DevOps、以及 DevSecOps 的深化。
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity." — 核心论点：DevOps 本质是文化与思维转变
|
||||
> "Blameless post-mortems to dissect failures without finger-pointing." — DevOps 文化的关键实践：无惧失败、聚焦改进
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps Culture]]：一种打破开发与运维壁垒、以协作、自动化、持续学习和客户导向为核心的文化与运营模式
|
||||
- [[CI/CD Pipeline]]：自动化测试、集成和部署流水线，是 DevOps 自动化能力的关键实现
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施，实现一致性和版本控制的实践
|
||||
- [[Kaizen (Continuous Improvement)]]：持续改进理念，通过无责复盘、数据驱动决策和混沌工程推动迭代优化
|
||||
- [[Shift-Left]]：将安全、性能等运维关注点前移至开发阶段，DevSecOps 是其典型实践
|
||||
- [[Value Stream Mapping]]：价值流图析，通过可视化工作流识别等待、审批和测试环节的延迟，消除浪费
|
||||
- [[GitOps]]：使用 Git 作为唯一真实来源来管理基础设施和部署的运维模式，是 DevOps 的进化方向之一
|
||||
- [[Serverless DevOps]]：利用函数即服务（FaaS）等无服务器技术减少运维负担的 DevOps 实践
|
||||
- [[Agile-DevOps Integration]]：Agile 与 DevOps 的协同机制，Scrum/Kanban 提供方法论框架，CI/CD 提供工程加速能力
|
||||
|
||||
## Key Entities
|
||||
- [[Hemant Sawant]]：LinkedIn 文章原作者，DevOps 文化与转型领域的分享者
|
||||
- [[Shenwei]]：本文档的保存整理者
|
||||
|
||||
## Connections
|
||||
- [[DevOps Maturity Model]] ← extends ← [[DevOps Culture]]：本文聚焦 DevOps 文化转型，与成熟度模型互为补充（文化层 vs 能力层级）
|
||||
- [[DevSecOps Best Practices]] ← depends_on ← [[DevOps Culture]]：DevSecOps 是 DevOps 文化中"安全性嵌入"支柱的具体实现
|
||||
- [[Agile-DevOps Integration]] ← extends ← [[DevOps Culture]]：Agile 与 DevOps 的融合是本文第二大主题
|
||||
- [[How Agentic AI Can Help Cloud DevOps]] ← relates_to ← [[DevOps Culture]]：AI/ML 赋能 DevOps 是本文未来趋势之一
|
||||
|
||||
## Contradictions
|
||||
- （本文档为新摄入来源，暂无已知冲突点）
|
||||
|
||||
@@ -1,68 +1,68 @@
|
||||
---
|
||||
title: "DevOps Maturity Model From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: [DevOps, DevOps Maturity, CI/CD, Automation, DevSecOps]
|
||||
date: 2024-08-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps 成熟度模型的五阶段演进框架，从传统 IT 到完全成熟的 DevOps
|
||||
- 问题域：组织如何评估当前 DevOps 实践水平，识别改进领域，制定升级路线图
|
||||
- 方法/机制：通过四个核心关注领域（文化与战略、自动化、结构与流程、协作与共享、技术）评估组织 DevOps 成熟度，分为五个递进阶段
|
||||
- 结论/价值：DevOps 成熟度模型是组织规划 DevOps 转型路径的结构化工具，涵盖从初始/临时阶段到完全成熟连续部署的全过程，并提供衡量指标和常见障碍识别
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps 成熟度模型通过四个关键领域评估组织能力：文化与战略、自动化、结构与流程、协作与共享、技术
|
||||
- 五阶段成熟度模型依次为：Phase 1 初始/临时阶段 → Phase 2 局部试点 → Phase 3 自动化与定义 → Phase 4 高度优化 → Phase 5 完全成熟
|
||||
- 完全成熟的 DevOps 实践实现零人工干预的流水线、每日多次部署、高确定性低风险发布
|
||||
- DevOps 成熟度关键衡量指标包括：部署频率、变更前置时间（Lead Time）、平均恢复时间（MTTR）、变更失败率、错误预算（Error Budget）
|
||||
- DevSecOps 将安全集成到 DevOps 每个阶段，是高级成熟度阶段的核心要求
|
||||
- 团队协作是 DevOps 的基石，也是衡量团队效能和生产力的关键指标
|
||||
|
||||
## Key Quotes
|
||||
> "The DevOps Maturity Model is a powerful tool for guiding organizations through the evolution of their DevOps practices, from initial adoption to achieving full maturity." — DevOps 成熟度模型的核心定位
|
||||
> "DevOps automation or AutoDevOps is crucial for continuous delivery and deployment. It simplifies development, testing, and production by automating repetitive tasks, which saves time and improves resource efficiency in the CI/CD process." — 自动化在 DevOps 中的核心价值
|
||||
> "The core of DevOps security is merging development, operations, and security into a unified process." — DevSecOps 的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps]]：一种融合开发与运维的文化、实践和技术组合，强调协作、自动化和持续改进
|
||||
- [[DevSecOps]]：将安全实践集成到 DevOps 流程的每个阶段（通过 DevOps Maturity Model Phase 4-5 实现）
|
||||
- [[Continuous Delivery]]：持续交付，使代码变更可随时安全部署到生产环境
|
||||
- [[Agile]]：敏捷方法，从 Phase 2 开始引入，强调业务和用户价值而非仅项目规划
|
||||
- [[MVP]]：最小可行产品，在 Phase 4 高度优化阶段用于加速发布
|
||||
- [[Technical Debt]]：技术债务，在 Phase 3-4 阶段开始被优先管理和处理
|
||||
- [[Infrastructure as Code]]（IaC）：基础设施即代码，在 Phase 4 实现不可变基础设施替换旧服务器
|
||||
- [[MTTR]]（Mean Time to Recovery）：平均恢复时间，DevOps 成熟度关键衡量指标
|
||||
- [[Change Failure Rate]]：变更失败率，DevOps 关键绩效指标之一
|
||||
- [[Deployment Frequency]]：部署频率，完全成熟阶段实现每日多次部署
|
||||
- [[Lead Time]]：前置时间，从代码提交到部署的时间周期
|
||||
- [[concepts/Error-Budget]]：错误预算，允许的生产错误和失败率
|
||||
- [[concepts/Immutable-Infrastructure]]：不可变基础设施，在 Phase 4 替换旧服务器而非更新
|
||||
- [[Version Control]]：版本控制，从 Phase 2 开始用于管理环境和配置
|
||||
|
||||
## Key Entities
|
||||
- [[entities/DevOps-Maturity-Model]]：本文核心——评估和指导 DevOps 转型的五阶段成熟度模型
|
||||
- [[DevOps Culture and Transformation]]：DevOps 文化转型相关主题，与本文 Phase 1-2 的文化演进强相关
|
||||
- [[Release Management]]：发布管理，涵盖部署频率、变更失败率等关键指标，与本文衡量指标重叠
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture and Transformation]] ← foundational ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[DevOps]] ← encompasses ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[DevSecOps]] ← integrates ← [[DevOps]] + Security（本文 Phase 4-5 体现）
|
||||
- [[Continuous Delivery]] ← supports ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[Release Management]] ← measures ← DevOps Maturity（共享 Deployment Frequency, Lead Time, MTTR 等指标）
|
||||
- [[concepts/Error-Budget]] ← part of ← DORA Metrics
|
||||
- [[concepts/Immutable-Infrastructure]] ← enables ← Phase 4 高度优化
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Culture and Transformation]] 的潜在视角差异：
|
||||
- 冲突点：文化转型是 DevOps 成功的前提还是结果？
|
||||
- 当前观点（本文）：文化是成熟度的一个评估维度，从 Phase 1（孤立文化）到 Phase 5（自足全栈团队）
|
||||
- 对方观点：文化转型应该是最先启动的变革，需先改变团队协作方式才能推进其他实践
|
||||
- 与 [[Waterfall]] 的对比冲突：
|
||||
- 冲突点：传统瀑布式方法是否完全无法满足现代软件交付需求？
|
||||
- 当前观点（本文）：瀑布式是 Phase 1 的典型特征，以里程碑而非用户反馈驱动，是需要淘汰的落后模式
|
||||
- 对方观点：瀑布式在稳定需求、长周期硬件项目或合规要求严格的场景中仍有价值
|
||||
---
|
||||
title: "DevOps Maturity Model From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: [DevOps, DevOps Maturity, CI/CD, Automation, DevSecOps]
|
||||
date: 2024-08-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps 成熟度模型的五阶段演进框架，从传统 IT 到完全成熟的 DevOps
|
||||
- 问题域：组织如何评估当前 DevOps 实践水平，识别改进领域，制定升级路线图
|
||||
- 方法/机制：通过四个核心关注领域（文化与战略、自动化、结构与流程、协作与共享、技术）评估组织 DevOps 成熟度，分为五个递进阶段
|
||||
- 结论/价值：DevOps 成熟度模型是组织规划 DevOps 转型路径的结构化工具，涵盖从初始/临时阶段到完全成熟连续部署的全过程，并提供衡量指标和常见障碍识别
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps 成熟度模型通过四个关键领域评估组织能力：文化与战略、自动化、结构与流程、协作与共享、技术
|
||||
- 五阶段成熟度模型依次为：Phase 1 初始/临时阶段 → Phase 2 局部试点 → Phase 3 自动化与定义 → Phase 4 高度优化 → Phase 5 完全成熟
|
||||
- 完全成熟的 DevOps 实践实现零人工干预的流水线、每日多次部署、高确定性低风险发布
|
||||
- DevOps 成熟度关键衡量指标包括：部署频率、变更前置时间（Lead Time）、平均恢复时间（MTTR）、变更失败率、错误预算（Error Budget）
|
||||
- DevSecOps 将安全集成到 DevOps 每个阶段，是高级成熟度阶段的核心要求
|
||||
- 团队协作是 DevOps 的基石，也是衡量团队效能和生产力的关键指标
|
||||
|
||||
## Key Quotes
|
||||
> "The DevOps Maturity Model is a powerful tool for guiding organizations through the evolution of their DevOps practices, from initial adoption to achieving full maturity." — DevOps 成熟度模型的核心定位
|
||||
> "DevOps automation or AutoDevOps is crucial for continuous delivery and deployment. It simplifies development, testing, and production by automating repetitive tasks, which saves time and improves resource efficiency in the CI/CD process." — 自动化在 DevOps 中的核心价值
|
||||
> "The core of DevOps security is merging development, operations, and security into a unified process." — DevSecOps 的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps]]：一种融合开发与运维的文化、实践和技术组合，强调协作、自动化和持续改进
|
||||
- [[DevSecOps]]：将安全实践集成到 DevOps 流程的每个阶段（通过 DevOps Maturity Model Phase 4-5 实现）
|
||||
- [[Continuous Delivery]]：持续交付，使代码变更可随时安全部署到生产环境
|
||||
- [[Agile]]：敏捷方法，从 Phase 2 开始引入，强调业务和用户价值而非仅项目规划
|
||||
- [[MVP]]：最小可行产品，在 Phase 4 高度优化阶段用于加速发布
|
||||
- [[Technical Debt]]：技术债务，在 Phase 3-4 阶段开始被优先管理和处理
|
||||
- [[Infrastructure as Code]]（IaC）：基础设施即代码，在 Phase 4 实现不可变基础设施替换旧服务器
|
||||
- [[MTTR]]（Mean Time to Recovery）：平均恢复时间，DevOps 成熟度关键衡量指标
|
||||
- [[Change Failure Rate]]：变更失败率，DevOps 关键绩效指标之一
|
||||
- [[Deployment Frequency]]：部署频率，完全成熟阶段实现每日多次部署
|
||||
- [[Lead Time]]：前置时间，从代码提交到部署的时间周期
|
||||
- [[concepts/Error-Budget]]：错误预算，允许的生产错误和失败率
|
||||
- [[concepts/Immutable-Infrastructure]]：不可变基础设施，在 Phase 4 替换旧服务器而非更新
|
||||
- [[Version Control]]：版本控制，从 Phase 2 开始用于管理环境和配置
|
||||
|
||||
## Key Entities
|
||||
- [[entities/DevOps-Maturity-Model]]：本文核心——评估和指导 DevOps 转型的五阶段成熟度模型
|
||||
- [[DevOps Culture and Transformation]]：DevOps 文化转型相关主题，与本文 Phase 1-2 的文化演进强相关
|
||||
- [[Release Management]]：发布管理，涵盖部署频率、变更失败率等关键指标，与本文衡量指标重叠
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture and Transformation]] ← foundational ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[DevOps]] ← encompasses ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[DevSecOps]] ← integrates ← [[DevOps]] + Security（本文 Phase 4-5 体现）
|
||||
- [[Continuous Delivery]] ← supports ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[Release Management]] ← measures ← DevOps Maturity（共享 Deployment Frequency, Lead Time, MTTR 等指标）
|
||||
- [[concepts/Error-Budget]] ← part of ← DORA Metrics
|
||||
- [[concepts/Immutable-Infrastructure]] ← enables ← Phase 4 高度优化
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Culture and Transformation]] 的潜在视角差异：
|
||||
- 冲突点：文化转型是 DevOps 成功的前提还是结果？
|
||||
- 当前观点（本文）：文化是成熟度的一个评估维度，从 Phase 1（孤立文化）到 Phase 5（自足全栈团队）
|
||||
- 对方观点：文化转型应该是最先启动的变革，需先改变团队协作方式才能推进其他实践
|
||||
- 与 [[Waterfall]] 的对比冲突：
|
||||
- 冲突点：传统瀑布式方法是否完全无法满足现代软件交付需求？
|
||||
- 当前观点（本文）：瀑布式是 Phase 1 的典型特征，以里程碑而非用户反馈驱动，是需要淘汰的落后模式
|
||||
- 对方观点：瀑布式在稳定需求、长周期硬件项目或合规要求严格的场景中仍有价值
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: "Autonomous Optimization Architect"
|
||||
type: source
|
||||
tags: ["ai-finetuning", "llm-routing", "ai-fintech", "autonomous-agents", "cost-optimization"]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：LLM 驱动的自主优化与智能路由系统，通过影子测试持续评估和切换 AI 模型
|
||||
- 问题域：AI 系统运营成本失控、模型选择缺乏数据驱动、缺少金融级安全保障
|
||||
- 方法/机制：LLM-as-a-Judge 评分、影子流量测试、暗启动（Dark Launching）、熔断器（Circuit Breaker）、AI FinOps
|
||||
- 结论/价值：在保证 99.99% 稳定性的前提下，通过自动路由至更便宜/更快的模型实现 >40% 成本降低
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 影子流量（Shadow Traffic）异步测试新模型，不影响生产环境稳定性的同时收集真实对比数据
|
||||
- 自主流量路由（Autonomous Traffic Routing）：实验模型达到基准精度（如 98%）且成本更低（如 1/10）时，自动切换至该模型
|
||||
- 金融与安全护栏（Financial & Security Guardrails）：每个外部请求必须配置超时、重试上限和廉价兜底方案，防止无限循环
|
||||
- 异常熔断（Halt on Anomaly）：流量突增 500% 或出现 HTTP 402/429 错误时，立即触发熔断器并告警人工
|
||||
- 成本优先原则：提出 LLM 架构时必须同时给出每百万 Token 的主路径和兜底路径成本估算
|
||||
|
||||
## Key Quotes
|
||||
> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Autonomous Optimization Architect 通信风格
|
||||
> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — 熔断触发时的标准告警语
|
||||
> "Autonomous routing without a circuit breaker is just an expensive bomb." — 该 Agent 的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[CircuitBreaker]]：熔断器模式，当 Provider 失败频率超过阈值时自动切断并切换到廉价兜底方案
|
||||
- [[LLMasJudge]]：用 LLM 自动评估实验模型输出的质量，作为客观评分替代人工评审
|
||||
- [[ShadowTraffic]]：影子流量，将一小部分请求异步转发至实验模型，与生产结果对比评分
|
||||
- [[SemanticRouting]]：语义路由，根据任务类型和历史性能选择最优 Provider
|
||||
- [[DarkLaunching]]：暗启动/灰度发布，新模型在不影响用户的前提下逐步引入
|
||||
- [[AIFinOps]]：AI 云财务管理，跟踪每个 LLM 的 token 消耗、成本和延迟，建立历史性能排名
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAI]]：主要 LLM Provider 之一，提供 GPT 系列模型
|
||||
- [[Anthropic]]：主要 LLM Provider，提供 Claude 系列模型
|
||||
- [[GoogleGemini]]：主要 LLM Provider，提供 Gemini Flash 等高性价比模型
|
||||
- [[Firecrawl]]：网页抓取 API，当 LLM Provider 不可用时的备选数据获取方案
|
||||
|
||||
## Connections
|
||||
- [[testing-workflow-optimizer]] ← uses ← [[AutonomousOptimizationArchitect]]（工作流优化依赖路由决策）
|
||||
- [[backend-architect-with-memory]] ← depends_on ← [[AutonomousOptimizationArchitect]]（后端架构依赖成本追踪记忆）
|
||||
- [[automation-governance-architect]] ← shares_guardrails ← [[AutonomousOptimizationArchitect]]（自动化治理与本 Agent 均涉及安全护栏设计）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[testing-performance-benchmarker]] 冲突：
|
||||
- 冲突点：性能基准测试强调人工驱动的静态评估，本 Agent 强调机器驱动的动态 A/B 测试
|
||||
- 当前观点：持续自动的影子测试比定期人工测试更能反映生产环境真实性能
|
||||
- 对方观点：性能基准测试提供可控、可复现的实验室数据，而非真实流量噪声
|
||||
---
|
||||
title: "Autonomous Optimization Architect"
|
||||
type: source
|
||||
tags: ["ai-finetuning", "llm-routing", "ai-fintech", "autonomous-agents", "cost-optimization"]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：LLM 驱动的自主优化与智能路由系统，通过影子测试持续评估和切换 AI 模型
|
||||
- 问题域：AI 系统运营成本失控、模型选择缺乏数据驱动、缺少金融级安全保障
|
||||
- 方法/机制：LLM-as-a-Judge 评分、影子流量测试、暗启动（Dark Launching）、熔断器（Circuit Breaker）、AI FinOps
|
||||
- 结论/价值：在保证 99.99% 稳定性的前提下，通过自动路由至更便宜/更快的模型实现 >40% 成本降低
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 影子流量（Shadow Traffic）异步测试新模型，不影响生产环境稳定性的同时收集真实对比数据
|
||||
- 自主流量路由（Autonomous Traffic Routing）：实验模型达到基准精度（如 98%）且成本更低（如 1/10）时，自动切换至该模型
|
||||
- 金融与安全护栏（Financial & Security Guardrails）：每个外部请求必须配置超时、重试上限和廉价兜底方案，防止无限循环
|
||||
- 异常熔断（Halt on Anomaly）：流量突增 500% 或出现 HTTP 402/429 错误时，立即触发熔断器并告警人工
|
||||
- 成本优先原则：提出 LLM 架构时必须同时给出每百万 Token 的主路径和兜底路径成本估算
|
||||
|
||||
## Key Quotes
|
||||
> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Autonomous Optimization Architect 通信风格
|
||||
> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — 熔断触发时的标准告警语
|
||||
> "Autonomous routing without a circuit breaker is just an expensive bomb." — 该 Agent 的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[CircuitBreaker]]：熔断器模式，当 Provider 失败频率超过阈值时自动切断并切换到廉价兜底方案
|
||||
- [[LLMasJudge]]：用 LLM 自动评估实验模型输出的质量，作为客观评分替代人工评审
|
||||
- [[ShadowTraffic]]：影子流量，将一小部分请求异步转发至实验模型，与生产结果对比评分
|
||||
- [[SemanticRouting]]：语义路由，根据任务类型和历史性能选择最优 Provider
|
||||
- [[DarkLaunching]]：暗启动/灰度发布，新模型在不影响用户的前提下逐步引入
|
||||
- [[AIFinOps]]：AI 云财务管理，跟踪每个 LLM 的 token 消耗、成本和延迟，建立历史性能排名
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAI]]：主要 LLM Provider 之一，提供 GPT 系列模型
|
||||
- [[Anthropic]]：主要 LLM Provider，提供 Claude 系列模型
|
||||
- [[GoogleGemini]]：主要 LLM Provider，提供 Gemini Flash 等高性价比模型
|
||||
- [[Firecrawl]]：网页抓取 API，当 LLM Provider 不可用时的备选数据获取方案
|
||||
|
||||
## Connections
|
||||
- [[testing-workflow-optimizer]] ← uses ← [[AutonomousOptimizationArchitect]]（工作流优化依赖路由决策）
|
||||
- [[backend-architect-with-memory]] ← depends_on ← [[AutonomousOptimizationArchitect]]（后端架构依赖成本追踪记忆）
|
||||
- [[automation-governance-architect]] ← shares_guardrails ← [[AutonomousOptimizationArchitect]]（自动化治理与本 Agent 均涉及安全护栏设计）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[testing-performance-benchmarker]] 冲突：
|
||||
- 冲突点：性能基准测试强调人工驱动的静态评估，本 Agent 强调机器驱动的动态 A/B 测试
|
||||
- 当前观点：持续自动的影子测试比定期人工测试更能反映生产环境真实性能
|
||||
- 对方观点：性能基准测试提供可控、可复现的实验室数据，而非真实流量噪声
|
||||
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "Mobile App Builder Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-mobile-app-builder.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Mobile App Builder — 专注于原生 iOS/Android 开发和跨平台框架的移动应用开发 AI Agent 人格规范
|
||||
- 问题域：如何在移动端构建高性能、平台原生体验的应用；原生开发与跨平台开发的选型决策；移动端特有的性能、续航、离线场景约束
|
||||
- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 模式；Offline-First 架构；平台原生设计规范（Material Design / Human Interface Guidelines）
|
||||
- 结论/价值：移动开发 Agent 需要具备平台意识、性能优先、用户体验驱动的特质，同时保持跨平台的技术多样性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 原生 iOS/Android 开发必须遵循平台设计指南（Material Design、Human Interface Guidelines）
|
||||
- 移动应用必须实现离线优先架构和智能数据同步
|
||||
- 跨平台开发需在代码复用与平台原生体验之间找到平衡
|
||||
- 移动性能优化目标：冷启动 < 3 秒，内存占用 < 100MB，续航损耗 < 5%/小时
|
||||
|
||||
## Key Quotes
|
||||
> "Implemented iOS-native navigation with SwiftUI while maintaining Material Design patterns on Android" — 平台感知型开发示例
|
||||
> "Built offline-first architecture to handle poor network conditions gracefully" — 移动约束优先的设计理念
|
||||
> "Optimized app startup time to 2.1 seconds and reduced memory usage by 40%" — 性能优化的典型目标
|
||||
|
||||
## Key Concepts
|
||||
- [[Offline-First Architecture]]：离线优先架构 — 构建应用时默认以离线为基准，网络连接时进行数据同步，确保弱网环境下的用户体验
|
||||
- [[MVVM Pattern]]：Model-View-ViewModel — SwiftUI 和 Jetpack Compose 推荐的状态管理模式，ViewModel 持有 UI 状态和业务逻辑，View 负责渲染
|
||||
- [[Cross-Platform Mobile Development]]：跨平台移动开发 — 使用 React Native 或 Flutter 等框架在 iOS 和 Android 上共享代码，同时保持平台原生特性
|
||||
- [[Platform-Native UI]]：平台原生 UI — 遵循各平台设计规范（Material Design / HIG）实现符合用户预期的界面和交互
|
||||
- [[Biometric Authentication]]：生物特征认证 — 在移动应用中集成 Face ID、Touch ID 或指纹识别实现安全身份验证
|
||||
- [[Push Notification System]]：推送通知系统 — 针对不同平台（APNs/Firebase）实现精准推送，提升用户留存
|
||||
|
||||
## Key Entities
|
||||
- [[SwiftUI]]：Apple 声明式 UI 框架，用于构建现代 iOS/macOS 应用界面
|
||||
- [[Jetpack Compose]]：Google Jetpack 声明式 UI 工具包，Android 原生现代化 UI 开发
|
||||
- [[React Native]]：Facebook/Meta 开源跨平台框架，使用 JavaScript/TypeScript 构建原生移动应用
|
||||
- [[Flutter]]：Google 开源跨平台 UI 工具包，使用 Dart 语言，可编译为原生 ARM 代码
|
||||
- [[Swift]]：Apple iOS/macOS 开发语言，配合 SwiftUI 使用
|
||||
- [[Kotlin]]：Google 官方 Android 开发语言，配合 Jetpack Compose 使用
|
||||
|
||||
## Connections
|
||||
- [[agents-orchestrator]] ← orchestrates ← [[engineering-mobile-app-builder]]
|
||||
- [[engineering-mobile-app-builder]] ← shares_workflow ← [[unity-architect]]（平台策略和架构决策方法论）
|
||||
- [[engineering-mobile-app-builder]] ← extends ← [[software-architect]]（系统架构原则应用于移动端）
|
||||
- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]（Apple 生态移动开发扩展）
|
||||
- [[xr-immersive-developer]] ← related_to ← [[engineering-mobile-app-builder]]（XR 与移动平台的跨设备体验）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[unity-architect]] 跨平台理念存在框架差异：
|
||||
- 冲突点：原生开发 vs 跨平台框架的优先级
|
||||
- 当前观点：Mobile App Builder 默认支持多种框架（SwiftUI、Jetpack Compose、React Native、Flutter），按需选型
|
||||
- 对方观点：Unity Architect 专注于 Unity 引擎内的跨平台方案
|
||||
- 说明：两者解决的问题域不同，Mobile App Builder 面向通用移动应用，Unity Architect 面向游戏开发，属合理分工而非矛盾
|
||||
---
|
||||
title: "Mobile App Builder Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-mobile-app-builder.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Mobile App Builder — 专注于原生 iOS/Android 开发和跨平台框架的移动应用开发 AI Agent 人格规范
|
||||
- 问题域：如何在移动端构建高性能、平台原生体验的应用；原生开发与跨平台开发的选型决策；移动端特有的性能、续航、离线场景约束
|
||||
- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 模式；Offline-First 架构；平台原生设计规范（Material Design / Human Interface Guidelines）
|
||||
- 结论/价值：移动开发 Agent 需要具备平台意识、性能优先、用户体验驱动的特质，同时保持跨平台的技术多样性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 原生 iOS/Android 开发必须遵循平台设计指南（Material Design、Human Interface Guidelines）
|
||||
- 移动应用必须实现离线优先架构和智能数据同步
|
||||
- 跨平台开发需在代码复用与平台原生体验之间找到平衡
|
||||
- 移动性能优化目标：冷启动 < 3 秒，内存占用 < 100MB，续航损耗 < 5%/小时
|
||||
|
||||
## Key Quotes
|
||||
> "Implemented iOS-native navigation with SwiftUI while maintaining Material Design patterns on Android" — 平台感知型开发示例
|
||||
> "Built offline-first architecture to handle poor network conditions gracefully" — 移动约束优先的设计理念
|
||||
> "Optimized app startup time to 2.1 seconds and reduced memory usage by 40%" — 性能优化的典型目标
|
||||
|
||||
## Key Concepts
|
||||
- [[Offline-First Architecture]]：离线优先架构 — 构建应用时默认以离线为基准，网络连接时进行数据同步，确保弱网环境下的用户体验
|
||||
- [[MVVM Pattern]]：Model-View-ViewModel — SwiftUI 和 Jetpack Compose 推荐的状态管理模式，ViewModel 持有 UI 状态和业务逻辑，View 负责渲染
|
||||
- [[Cross-Platform Mobile Development]]：跨平台移动开发 — 使用 React Native 或 Flutter 等框架在 iOS 和 Android 上共享代码，同时保持平台原生特性
|
||||
- [[Platform-Native UI]]：平台原生 UI — 遵循各平台设计规范（Material Design / HIG）实现符合用户预期的界面和交互
|
||||
- [[Biometric Authentication]]：生物特征认证 — 在移动应用中集成 Face ID、Touch ID 或指纹识别实现安全身份验证
|
||||
- [[Push Notification System]]：推送通知系统 — 针对不同平台（APNs/Firebase）实现精准推送，提升用户留存
|
||||
|
||||
## Key Entities
|
||||
- [[SwiftUI]]：Apple 声明式 UI 框架，用于构建现代 iOS/macOS 应用界面
|
||||
- [[Jetpack Compose]]：Google Jetpack 声明式 UI 工具包，Android 原生现代化 UI 开发
|
||||
- [[React Native]]：Facebook/Meta 开源跨平台框架，使用 JavaScript/TypeScript 构建原生移动应用
|
||||
- [[Flutter]]：Google 开源跨平台 UI 工具包，使用 Dart 语言，可编译为原生 ARM 代码
|
||||
- [[Swift]]：Apple iOS/macOS 开发语言，配合 SwiftUI 使用
|
||||
- [[Kotlin]]：Google 官方 Android 开发语言，配合 Jetpack Compose 使用
|
||||
|
||||
## Connections
|
||||
- [[agents-orchestrator]] ← orchestrates ← [[engineering-mobile-app-builder]]
|
||||
- [[engineering-mobile-app-builder]] ← shares_workflow ← [[unity-architect]]（平台策略和架构决策方法论）
|
||||
- [[engineering-mobile-app-builder]] ← extends ← [[software-architect]]（系统架构原则应用于移动端）
|
||||
- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]（Apple 生态移动开发扩展）
|
||||
- [[xr-immersive-developer]] ← related_to ← [[engineering-mobile-app-builder]]（XR 与移动平台的跨设备体验）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[unity-architect]] 跨平台理念存在框架差异：
|
||||
- 冲突点：原生开发 vs 跨平台框架的优先级
|
||||
- 当前观点：Mobile App Builder 默认支持多种框架（SwiftUI、Jetpack Compose、React Native、Flutter），按需选型
|
||||
- 对方观点：Unity Architect 专注于 Unity 引擎内的跨平台方案
|
||||
- 说明：两者解决的问题域不同，Mobile App Builder 面向通用移动应用，Unity Architect 面向游戏开发，属合理分工而非矛盾
|
||||
|
||||
@@ -1,69 +1,69 @@
|
||||
---
|
||||
title: "How Can a Multi Cloud Strategy Transform Your Business ROI?"
|
||||
type: source
|
||||
tags: [Cloud, Multi-Cloud, ROI, DevOps]
|
||||
date: 2024-12-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：多云策略（Multi-Cloud Strategy）的商业价值——如何通过多云架构提升业务 ROI、降低风险、增强弹性
|
||||
- 问题域：企业在云迁移和云运营中面临的供应商锁定、成本失控、合规复杂、可用性不足等挑战
|
||||
- 方法/机制：跨多个云服务提供商（AWS/Azure/GCP）分配工作负载，利用各提供商优势实现成本优化、弹性扩展和安全增强
|
||||
- 结论/价值：78% 企业使用 3+ 公有云；86% 企业计划 2024 年底采用多云；优化后可实现 30% 运营成本降低；多云策略是企业在数字化竞争中保持敏捷的关键
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 78% 采用多云策略的企业使用 3+ 公有云以提升敏捷性和成本节约（Virtana）
|
||||
- 86% 企业计划 2024 年底采用多云策略以满足持续业务需求（New Horizons）
|
||||
- 优化资源和与不同云服务商谈判后，多数企业享受 30% 运营成本降低（Forrester）
|
||||
- 78% 企业已采用多云策略；平均使用 2-5 个云服务商；多云是主流趋势
|
||||
|
||||
## Key Quotes
|
||||
> "The multi cloud strategy is a distinctive approach in which we have instances of services on multiple clouds, i.e., Azure, GCP, and Amazon, instead of one cloud vendor." — Bacancy Technology，核心定义
|
||||
|
||||
> "A multi-cloud approach will provide businesses with more innovation and ensure they are always at the forefront of this rapidly evolving digital landscape." — Bacancy Technology，多云创新的价值
|
||||
|
||||
> "After optimizing resources and negotiating favorable prices with different cloud service providers, most companies enjoy a 30% reduction in operations costs." — Forrester，成本优化数据来源
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Cloud-Strategy]]：使用多个云服务提供商来避免锁定、增强弹性、优化成本，是本文核心主题
|
||||
- [[Vendor-Lock-In]]：多云策略的首要动因——企业通过多云摆脱对单一供应商的依赖
|
||||
- [[Data-Sovereignty]]：多云策略满足数据主权合规——不同地区选择符合当地法规的云服务商
|
||||
- [[High Availability]]：多云跨平台冗余实现 99.99%+ 可用性目标
|
||||
- [[Scalability]]：多云弹性扩展能力——跨提供商动态分配资源，应对流量高峰
|
||||
- [[Cost Optimization]]：多云实现 30% 运营成本降低——跨提供商比价、优化资源配置
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]] — 主要云提供商之一，可用于基础设施和通用计算
|
||||
- [[Azure]] — Microsoft Azure，多云策略中用于 AI 工具集成
|
||||
- [[Google-Cloud]] — GCP，ML/AI 工作负载的首选提供商
|
||||
- Bacancy Technology — 文章原始发布方，提供云托管服务
|
||||
|
||||
## Connections
|
||||
- [[Multi-Cloud-Strategy]] ← is_about ← 本文核心主题
|
||||
- [[Vendor-Lock-In]] ← solves ← [[Multi-Cloud-Strategy]] 的首要动机
|
||||
- [[Data-Sovereignty]] ← enables ← [[Multi-Cloud-Strategy]] 的合规能力
|
||||
- [[High Availability]] ← achieved_by ← [[Multi-Cloud-Strategy]] 跨云冗余
|
||||
- [[Cloud-Operating-Model]] ← includes ← [[Multi-Cloud-Strategy]] 作为核心组件
|
||||
- [[Cloud-Governance]] ← governs ← [[Multi-Cloud-Strategy]] 的实施
|
||||
- [[FinOps]] ← optimizes ← [[Multi-Cloud-Strategy]] 的成本管理
|
||||
|
||||
## Real-World Use Cases（原文关键案例）
|
||||
- **电商**：黑色星期五/网络星期一等高峰期跨多云弹性扩展，保障高可用和快速加载
|
||||
- **医疗**：符合 HIPAA 保护患者数据，符合区域数据主权要求，降低单一云依赖成本
|
||||
- **金融**：利用不同云最佳安全功能，满足严格监管要求，减少供应商锁定，获得更好 SLA
|
||||
|
||||
## Implementation Framework（原文实施路径）
|
||||
1. **评估需求**：明确目标（弹性/成本/规模）、预算分析、资源评估
|
||||
2. **选择提供商**：对齐服务与需求（如 AWS 基础设施、GCP 分析、Azure AI）
|
||||
3. **集成管理**：采用 Kubernetes/Terraform 等多云管理工具，确保数据互操作性
|
||||
4. **监控优化**：使用 CloudHealth/Datadog 持续监控性能和成本
|
||||
|
||||
## Contradictions
|
||||
- 与 [[cloud-operating-model-key-strategies-and-best-practices]] 中的"统一云治理"观点存在潜在张力：
|
||||
- 冲突点：多云策略天然带来管理复杂性
|
||||
- 当前观点（本文）：多云管理工具（Kubernetes/Terraform）可简化复杂性
|
||||
- 对方观点：需要统一的 Cloud Operating Model 治理框架来协调多云环境
|
||||
- 协调方向：两者互补——多云策略是选择层，Cloud Operating Model 是治理层
|
||||
---
|
||||
title: "How Can a Multi Cloud Strategy Transform Your Business ROI?"
|
||||
type: source
|
||||
tags: [Cloud, Multi-Cloud, ROI, DevOps]
|
||||
date: 2024-12-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：多云策略（Multi-Cloud Strategy）的商业价值——如何通过多云架构提升业务 ROI、降低风险、增强弹性
|
||||
- 问题域：企业在云迁移和云运营中面临的供应商锁定、成本失控、合规复杂、可用性不足等挑战
|
||||
- 方法/机制：跨多个云服务提供商（AWS/Azure/GCP）分配工作负载，利用各提供商优势实现成本优化、弹性扩展和安全增强
|
||||
- 结论/价值：78% 企业使用 3+ 公有云；86% 企业计划 2024 年底采用多云；优化后可实现 30% 运营成本降低；多云策略是企业在数字化竞争中保持敏捷的关键
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 78% 采用多云策略的企业使用 3+ 公有云以提升敏捷性和成本节约（Virtana）
|
||||
- 86% 企业计划 2024 年底采用多云策略以满足持续业务需求（New Horizons）
|
||||
- 优化资源和与不同云服务商谈判后，多数企业享受 30% 运营成本降低（Forrester）
|
||||
- 78% 企业已采用多云策略；平均使用 2-5 个云服务商；多云是主流趋势
|
||||
|
||||
## Key Quotes
|
||||
> "The multi cloud strategy is a distinctive approach in which we have instances of services on multiple clouds, i.e., Azure, GCP, and Amazon, instead of one cloud vendor." — Bacancy Technology，核心定义
|
||||
|
||||
> "A multi-cloud approach will provide businesses with more innovation and ensure they are always at the forefront of this rapidly evolving digital landscape." — Bacancy Technology，多云创新的价值
|
||||
|
||||
> "After optimizing resources and negotiating favorable prices with different cloud service providers, most companies enjoy a 30% reduction in operations costs." — Forrester，成本优化数据来源
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Cloud-Strategy]]：使用多个云服务提供商来避免锁定、增强弹性、优化成本，是本文核心主题
|
||||
- [[Vendor-Lock-In]]：多云策略的首要动因——企业通过多云摆脱对单一供应商的依赖
|
||||
- [[Data-Sovereignty]]：多云策略满足数据主权合规——不同地区选择符合当地法规的云服务商
|
||||
- [[High Availability]]：多云跨平台冗余实现 99.99%+ 可用性目标
|
||||
- [[Scalability]]：多云弹性扩展能力——跨提供商动态分配资源，应对流量高峰
|
||||
- [[Cost Optimization]]：多云实现 30% 运营成本降低——跨提供商比价、优化资源配置
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]] — 主要云提供商之一，可用于基础设施和通用计算
|
||||
- [[Azure]] — Microsoft Azure，多云策略中用于 AI 工具集成
|
||||
- [[Google-Cloud]] — GCP，ML/AI 工作负载的首选提供商
|
||||
- Bacancy Technology — 文章原始发布方，提供云托管服务
|
||||
|
||||
## Connections
|
||||
- [[Multi-Cloud-Strategy]] ← is_about ← 本文核心主题
|
||||
- [[Vendor-Lock-In]] ← solves ← [[Multi-Cloud-Strategy]] 的首要动机
|
||||
- [[Data-Sovereignty]] ← enables ← [[Multi-Cloud-Strategy]] 的合规能力
|
||||
- [[High Availability]] ← achieved_by ← [[Multi-Cloud-Strategy]] 跨云冗余
|
||||
- [[Cloud-Operating-Model]] ← includes ← [[Multi-Cloud-Strategy]] 作为核心组件
|
||||
- [[Cloud-Governance]] ← governs ← [[Multi-Cloud-Strategy]] 的实施
|
||||
- [[FinOps]] ← optimizes ← [[Multi-Cloud-Strategy]] 的成本管理
|
||||
|
||||
## Real-World Use Cases（原文关键案例）
|
||||
- **电商**：黑色星期五/网络星期一等高峰期跨多云弹性扩展，保障高可用和快速加载
|
||||
- **医疗**：符合 HIPAA 保护患者数据，符合区域数据主权要求，降低单一云依赖成本
|
||||
- **金融**：利用不同云最佳安全功能，满足严格监管要求，减少供应商锁定，获得更好 SLA
|
||||
|
||||
## Implementation Framework（原文实施路径）
|
||||
1. **评估需求**：明确目标（弹性/成本/规模）、预算分析、资源评估
|
||||
2. **选择提供商**：对齐服务与需求（如 AWS 基础设施、GCP 分析、Azure AI）
|
||||
3. **集成管理**：采用 Kubernetes/Terraform 等多云管理工具，确保数据互操作性
|
||||
4. **监控优化**：使用 CloudHealth/Datadog 持续监控性能和成本
|
||||
|
||||
## Contradictions
|
||||
- 与 [[cloud-operating-model-key-strategies-and-best-practices]] 中的"统一云治理"观点存在潜在张力：
|
||||
- 冲突点：多云策略天然带来管理复杂性
|
||||
- 当前观点（本文）：多云管理工具（Kubernetes/Terraform）可简化复杂性
|
||||
- 对方观点：需要统一的 Cloud Operating Model 治理框架来协调多云环境
|
||||
- 协调方向：两者互补——多云策略是选择层，Cloud Operating Model 是治理层
|
||||
|
||||
@@ -1,135 +1,135 @@
|
||||
---
|
||||
title: "Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记"
|
||||
type: source
|
||||
tags: [frp, frpc, gatekeeper, mac-mini, macos, arm64]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md]]
|
||||
|
||||
## Summary (用中文描述)
|
||||
- **核心主题**：在 Apple Silicon（ARM64）Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地服务
|
||||
- **问题域**：macOS 服务器化运维、内网穿透、远程访问、SSH 安全隧道
|
||||
- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，结合 tmux/nohup/launchd 三种方式实现后台持久运行；通过 SSH 客户端配置简化远程访问
|
||||
- **结论/价值**：提供完整的 Mac Mini 服务器化运维指南，包含 macOS 特有障碍（Gatekeeper）的解决方案和 SSH 客户端优化配置
|
||||
|
||||
## Key Claims (用中文描述)
|
||||
- macOS 默认 `/opt` 目录需要手动创建并授权才能使用
|
||||
- macOS Gatekeeper 会阻止未签名程序运行，必须通过 `xattr -rd com.apple.quarantine .` 解除限制
|
||||
- launchd 是 macOS 推荐的开机自启服务管理方式，可通过 `launchctl` 管理生命周期
|
||||
- 软链接（symlink）策略可实现 FRP 版本无缝切换
|
||||
- SSH 客户端配置（`~/.ssh/config`）可简化远程访问命令，只需 `ssh macmini` 即可登录
|
||||
|
||||
## Key Quotes
|
||||
> "macOS 默认 `/opt` 需要手动创建" — 说明了 macOS 与 Linux 目录结构的差异，需手动初始化系统目录
|
||||
> "xattr -rd com.apple.quarantine ." — macOS 特有的安全限制解除命令，针对整个目录递归执行
|
||||
> "launchd（推荐开机自启）" — macOS 原生服务管理器，是进程持久化的推荐方案
|
||||
> "ssh macmini" — SSH 客户端配置后的简化登录命令，通过 `~/.ssh/config` 定义 Host 别名
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务
|
||||
- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）
|
||||
- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器
|
||||
- [[launchd]]：macOS 原生服务管理器，用于管理系统级和用户级守护进程
|
||||
- [[SSH隧道]]：通过 SSH 协议建立的加密隧道，实现安全的远程端口转发
|
||||
|
||||
## Key Entities
|
||||
- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端
|
||||
- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142）
|
||||
- [[frpc]]：FRP 客户端程序，运行在 Mac Mini 上，建立与 frps 的连接
|
||||
- [[frps]]：FRP 服务端程序，运行在 VPS 上，接收公网请求并转发到 frpc
|
||||
- [[Gatekeeper]]：macOS 安全机制，阻止未签名应用运行
|
||||
- [[UFW防火墙]]：VPS 上的防火墙，需开放 FRP 映射端口
|
||||
|
||||
## Connections
|
||||
- [[Mac Mini M4]] ← runs_on ← [[frpc]]
|
||||
- [[VPS]] ← runs_on ← [[frps]]
|
||||
- [[frpc]] ← creates_tunnel ← [[frps]]
|
||||
- [[内网穿透]] ← enables ← [[远程SSH访问]]
|
||||
- [[launchd]] ← manages ← [[frpc]] 进程生命周期
|
||||
- [[Gatekeeper]] ← blocks ← [[frpc]] (需解除)
|
||||
- [[UFW防火墙]] ← controls_access ← [[SSH隧道]]（需开放 remotePort 60026）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Environment Details
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 系统 | macOS（Mac Mini M4）|
|
||||
| 架构 | Apple Silicon (ARM64) |
|
||||
| 软件 | FRP 0.65.0 |
|
||||
| 安装目录 | `/opt/frp/frp_0.65.0_darwin_arm64` |
|
||||
| 客户端程序 | `frpc` |
|
||||
| 配置文件 | `frpc.toml` |
|
||||
| frps服务器 | 192.227.222.142:7000 |
|
||||
| frps映射端口 | 6000（SSH），60026（实际案例端口）|
|
||||
|
||||
## Installation Steps
|
||||
1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp`
|
||||
2. 下载 ARM64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_darwin_arm64.tar.gz`
|
||||
3. 解压：`tar -xzf frp_0.65.0_darwin_arm64.tar.gz`
|
||||
4. 解除 Gatekeeper：`xattr -rd com.apple.quarantine .`
|
||||
5. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 proxies
|
||||
6. 启动 frpc：`./frpc -c frpc.toml`
|
||||
|
||||
## Background Running Methods
|
||||
1. **tmux**（推荐开发环境）：创建持久会话，断开 SSH 后仍保持运行
|
||||
2. **nohup**（简单后台）：重定向输出到日志文件，适合简单部署
|
||||
3. **launchd**（生产环境）：系统级服务，开机自启，推荐使用 plist 配置
|
||||
|
||||
## Best Practices
|
||||
- 统一安装路径：`/opt/frp/<version>` 便于版本管理
|
||||
- 创建软链接：`ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current` 简化启动命令
|
||||
- 日志独立存储：配置 StandardOutPath 和 StandardErrorPath 分离日志
|
||||
- 进程守护：使用 launchd KeepAlive=true 确保服务持续运行
|
||||
|
||||
## SSH 远程访问案例（完整配置）
|
||||
|
||||
### 网络架构
|
||||
```
|
||||
本地 Mac Mini
|
||||
│ SSH 22
|
||||
│
|
||||
frpc 客户端
|
||||
│ FRP 隧道
|
||||
│
|
||||
远端 VPS (frps)
|
||||
│ 60026
|
||||
│
|
||||
公网 SSH 访问：ssh username@VPS_IP -p 60026
|
||||
```
|
||||
|
||||
### VPS 防火墙配置（UFW）
|
||||
```bash
|
||||
sudo ufw allow 60026
|
||||
sudo ufw status
|
||||
# 输出：60026/tcp ALLOW Anywhere
|
||||
```
|
||||
|
||||
### frpc.toml SSH 代理配置
|
||||
```toml
|
||||
serverAddr = "VPS_IP"
|
||||
serverPort = 7000
|
||||
|
||||
auth.method = "token"
|
||||
auth.token = "your_token"
|
||||
|
||||
[[proxies]]
|
||||
name = "macmini-ssh"
|
||||
type = "tcp"
|
||||
localIP = "127.0.0.1"
|
||||
localPort = 22
|
||||
remotePort = 60026
|
||||
```
|
||||
|
||||
### SSH 客户端配置（~/.ssh/config）
|
||||
```ssh-config
|
||||
Host macmini
|
||||
HostName VPS_IP
|
||||
Port 60026
|
||||
User billy
|
||||
```
|
||||
|
||||
配置后可直接使用 `ssh macmini` 登录 Mac Mini，无需记忆 IP 和端口。
|
||||
---
|
||||
title: "Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记"
|
||||
type: source
|
||||
tags: [frp, frpc, gatekeeper, mac-mini, macos, arm64]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md]]
|
||||
|
||||
## Summary (用中文描述)
|
||||
- **核心主题**：在 Apple Silicon（ARM64）Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地服务
|
||||
- **问题域**：macOS 服务器化运维、内网穿透、远程访问、SSH 安全隧道
|
||||
- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，结合 tmux/nohup/launchd 三种方式实现后台持久运行；通过 SSH 客户端配置简化远程访问
|
||||
- **结论/价值**：提供完整的 Mac Mini 服务器化运维指南，包含 macOS 特有障碍（Gatekeeper）的解决方案和 SSH 客户端优化配置
|
||||
|
||||
## Key Claims (用中文描述)
|
||||
- macOS 默认 `/opt` 目录需要手动创建并授权才能使用
|
||||
- macOS Gatekeeper 会阻止未签名程序运行，必须通过 `xattr -rd com.apple.quarantine .` 解除限制
|
||||
- launchd 是 macOS 推荐的开机自启服务管理方式，可通过 `launchctl` 管理生命周期
|
||||
- 软链接（symlink）策略可实现 FRP 版本无缝切换
|
||||
- SSH 客户端配置（`~/.ssh/config`）可简化远程访问命令，只需 `ssh macmini` 即可登录
|
||||
|
||||
## Key Quotes
|
||||
> "macOS 默认 `/opt` 需要手动创建" — 说明了 macOS 与 Linux 目录结构的差异，需手动初始化系统目录
|
||||
> "xattr -rd com.apple.quarantine ." — macOS 特有的安全限制解除命令，针对整个目录递归执行
|
||||
> "launchd（推荐开机自启）" — macOS 原生服务管理器，是进程持久化的推荐方案
|
||||
> "ssh macmini" — SSH 客户端配置后的简化登录命令，通过 `~/.ssh/config` 定义 Host 别名
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务
|
||||
- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）
|
||||
- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器
|
||||
- [[launchd]]：macOS 原生服务管理器，用于管理系统级和用户级守护进程
|
||||
- [[SSH隧道]]：通过 SSH 协议建立的加密隧道，实现安全的远程端口转发
|
||||
|
||||
## Key Entities
|
||||
- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端
|
||||
- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142）
|
||||
- [[frpc]]：FRP 客户端程序，运行在 Mac Mini 上，建立与 frps 的连接
|
||||
- [[frps]]：FRP 服务端程序，运行在 VPS 上，接收公网请求并转发到 frpc
|
||||
- [[Gatekeeper]]：macOS 安全机制，阻止未签名应用运行
|
||||
- [[UFW防火墙]]：VPS 上的防火墙，需开放 FRP 映射端口
|
||||
|
||||
## Connections
|
||||
- [[Mac Mini M4]] ← runs_on ← [[frpc]]
|
||||
- [[VPS]] ← runs_on ← [[frps]]
|
||||
- [[frpc]] ← creates_tunnel ← [[frps]]
|
||||
- [[内网穿透]] ← enables ← [[远程SSH访问]]
|
||||
- [[launchd]] ← manages ← [[frpc]] 进程生命周期
|
||||
- [[Gatekeeper]] ← blocks ← [[frpc]] (需解除)
|
||||
- [[UFW防火墙]] ← controls_access ← [[SSH隧道]]（需开放 remotePort 60026）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Environment Details
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 系统 | macOS（Mac Mini M4）|
|
||||
| 架构 | Apple Silicon (ARM64) |
|
||||
| 软件 | FRP 0.65.0 |
|
||||
| 安装目录 | `/opt/frp/frp_0.65.0_darwin_arm64` |
|
||||
| 客户端程序 | `frpc` |
|
||||
| 配置文件 | `frpc.toml` |
|
||||
| frps服务器 | 192.227.222.142:7000 |
|
||||
| frps映射端口 | 6000（SSH），60026（实际案例端口）|
|
||||
|
||||
## Installation Steps
|
||||
1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp`
|
||||
2. 下载 ARM64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_darwin_arm64.tar.gz`
|
||||
3. 解压：`tar -xzf frp_0.65.0_darwin_arm64.tar.gz`
|
||||
4. 解除 Gatekeeper：`xattr -rd com.apple.quarantine .`
|
||||
5. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 proxies
|
||||
6. 启动 frpc：`./frpc -c frpc.toml`
|
||||
|
||||
## Background Running Methods
|
||||
1. **tmux**（推荐开发环境）：创建持久会话，断开 SSH 后仍保持运行
|
||||
2. **nohup**（简单后台）：重定向输出到日志文件，适合简单部署
|
||||
3. **launchd**（生产环境）：系统级服务，开机自启，推荐使用 plist 配置
|
||||
|
||||
## Best Practices
|
||||
- 统一安装路径：`/opt/frp/<version>` 便于版本管理
|
||||
- 创建软链接：`ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current` 简化启动命令
|
||||
- 日志独立存储：配置 StandardOutPath 和 StandardErrorPath 分离日志
|
||||
- 进程守护：使用 launchd KeepAlive=true 确保服务持续运行
|
||||
|
||||
## SSH 远程访问案例（完整配置）
|
||||
|
||||
### 网络架构
|
||||
```
|
||||
本地 Mac Mini
|
||||
│ SSH 22
|
||||
│
|
||||
frpc 客户端
|
||||
│ FRP 隧道
|
||||
│
|
||||
远端 VPS (frps)
|
||||
│ 60026
|
||||
│
|
||||
公网 SSH 访问：ssh username@VPS_IP -p 60026
|
||||
```
|
||||
|
||||
### VPS 防火墙配置（UFW）
|
||||
```bash
|
||||
sudo ufw allow 60026
|
||||
sudo ufw status
|
||||
# 输出：60026/tcp ALLOW Anywhere
|
||||
```
|
||||
|
||||
### frpc.toml SSH 代理配置
|
||||
```toml
|
||||
serverAddr = "VPS_IP"
|
||||
serverPort = 7000
|
||||
|
||||
auth.method = "token"
|
||||
auth.token = "your_token"
|
||||
|
||||
[[proxies]]
|
||||
name = "macmini-ssh"
|
||||
type = "tcp"
|
||||
localIP = "127.0.0.1"
|
||||
localPort = 22
|
||||
remotePort = 60026
|
||||
```
|
||||
|
||||
### SSH 客户端配置（~/.ssh/config）
|
||||
```ssh-config
|
||||
Host macmini
|
||||
HostName VPS_IP
|
||||
Port 60026
|
||||
User billy
|
||||
```
|
||||
|
||||
配置后可直接使用 `ssh macmini` 登录 Mac Mini，无需记忆 IP 和端口。
|
||||
|
||||
@@ -1,41 +1,41 @@
|
||||
---
|
||||
title: "macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）"
|
||||
type: source
|
||||
tags: [obsidian, openclaw, symbolic-link, macos]
|
||||
date:
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：macOS 下为 OpenClaw 隐藏目录创建和解除符号链接，使 Finder / Obsidian 可直接访问
|
||||
- 问题域：OpenClaw 默认使用 `~/.openclaw` 隐藏目录，不便于文件管理器直接操作
|
||||
- 方法/机制：通过 `ln -s` 创建符号链接，将隐藏目录映射为可见目录 `~/openclaw`；通过 `rm` 删除链接文件而非真实目录
|
||||
- 结论/价值：实现 OpenClaw 与 Obsidian 共用同一数据目录，无需复制文件，同时保留原 OpenClaw 的正常功能
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- OpenClaw 默认隐藏目录 `~/.openclaw` 不便于 Finder 或 Obsidian 直接访问
|
||||
- 使用 `ln -s ~/.openclaw ~/openclaw` 创建符号链接后，Obsidian 可将 `~/openclaw` 作为 Vault 打开
|
||||
- 使用 `rm ~/openclaw` 仅删除链接文件，不会影响真实目录 `~/.openclaw` 中的数据
|
||||
- 推荐长期方案：建立可见目录 `~/openclaw` 作为实际存储，反向链接 `~/.openclaw -> ~/openclaw`，便于 Git 管理和 Finder 访问
|
||||
|
||||
## Key Quotes
|
||||
> `ln -s ~/.openclaw ~/openclaw` — 创建符号链接的标准命令，将隐藏目录映射为可见目录
|
||||
> `rm ~/openclaw` — 删除符号链接（注意：不会删除真实目录中的数据）
|
||||
> `⚠️ 该操作只会删除链接文件，不会删除真实目录` — 强调操作安全性
|
||||
|
||||
## Key Concepts
|
||||
- [[SymbolicLink]]：Unix/Linux/macOS 中的符号链接（Symlink），是一种特殊类型的文件，指向另一个文件或目录路径
|
||||
- [[ObsidianVault]]：Obsidian 知识库的核心概念，以本地文件夹为单位的笔记管理方式
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：AI Agent 管理工具，默认使用隐藏目录存储记忆、Skills、Prompts 等数据
|
||||
- [[Obsidian]]：本地 Markdown 笔记应用，支持将任意文件夹作为 Vault 使用
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 使用 ← [[SymbolicLink]]
|
||||
- [[Obsidian]] ← 访问 ← [[OpenClaw]]（通过 [[SymbolicLink]] 映射后的可见目录）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
---
|
||||
title: "macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）"
|
||||
type: source
|
||||
tags: [obsidian, openclaw, symbolic-link, macos]
|
||||
date:
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：macOS 下为 OpenClaw 隐藏目录创建和解除符号链接，使 Finder / Obsidian 可直接访问
|
||||
- 问题域：OpenClaw 默认使用 `~/.openclaw` 隐藏目录，不便于文件管理器直接操作
|
||||
- 方法/机制：通过 `ln -s` 创建符号链接，将隐藏目录映射为可见目录 `~/openclaw`；通过 `rm` 删除链接文件而非真实目录
|
||||
- 结论/价值：实现 OpenClaw 与 Obsidian 共用同一数据目录，无需复制文件，同时保留原 OpenClaw 的正常功能
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- OpenClaw 默认隐藏目录 `~/.openclaw` 不便于 Finder 或 Obsidian 直接访问
|
||||
- 使用 `ln -s ~/.openclaw ~/openclaw` 创建符号链接后，Obsidian 可将 `~/openclaw` 作为 Vault 打开
|
||||
- 使用 `rm ~/openclaw` 仅删除链接文件，不会影响真实目录 `~/.openclaw` 中的数据
|
||||
- 推荐长期方案：建立可见目录 `~/openclaw` 作为实际存储，反向链接 `~/.openclaw -> ~/openclaw`，便于 Git 管理和 Finder 访问
|
||||
|
||||
## Key Quotes
|
||||
> `ln -s ~/.openclaw ~/openclaw` — 创建符号链接的标准命令，将隐藏目录映射为可见目录
|
||||
> `rm ~/openclaw` — 删除符号链接（注意：不会删除真实目录中的数据）
|
||||
> `⚠️ 该操作只会删除链接文件，不会删除真实目录` — 强调操作安全性
|
||||
|
||||
## Key Concepts
|
||||
- [[SymbolicLink]]：Unix/Linux/macOS 中的符号链接（Symlink），是一种特殊类型的文件，指向另一个文件或目录路径
|
||||
- [[ObsidianVault]]：Obsidian 知识库的核心概念，以本地文件夹为单位的笔记管理方式
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：AI Agent 管理工具，默认使用隐藏目录存储记忆、Skills、Prompts 等数据
|
||||
- [[Obsidian]]：本地 Markdown 笔记应用，支持将任意文件夹作为 Vault 使用
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 使用 ← [[SymbolicLink]]
|
||||
- [[Obsidian]] ← 访问 ← [[OpenClaw]]（通过 [[SymbolicLink]] 映射后的可见目录）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: "Public vs Private vs Hybrid Cloud Differences Explained"
|
||||
type: source
|
||||
tags: [cloud-computing, cloud-strategy, infrastructure]
|
||||
date: 2025-06-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题：** 公有云、私有云与混合云三种云计算部署模型的核心差异、优缺点及适用场景对比
|
||||
- **问题域：** 企业如何根据安全、成本、可扩展性、合规等需求选择合适的云部署模式
|
||||
- **方法/机制：** 系统性地从定义、优势、劣势、适用场景四个维度对比三种云模型；强调混合云作为折中方案的价值；提出"共享责任模型"概念
|
||||
- **结论/价值：** 三种云模型各有优劣，企业应根据工作负载特点制定有意图（intentional）的云策略，而非简单选择某一模型
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **公有云** 通过多租户共享模式提供高弹性、低成本、快速上线的计算服务，但在大规模企业场景下 TCO 可能指数级上升，且安全性和合规控制最弱
|
||||
- **私有云** 为单一组织提供专用环境，带来更高的安全性、控制力和合规灵活性，但成本最高、管理复杂、对远程用户不够友好
|
||||
- **混合云** 通过在同一架构中组合公私云实现"安全与扩展兼得"——敏感工作负载在私有云，普通负载在公有云，兼顾成本效率与安全韧性
|
||||
- **云选择决策** 应以工作负载需求为驱动，基于安全性、性能、成本三大维度制定有意图的云策略，且需持续评估和调整
|
||||
|
||||
## Key Quotes
|
||||
> "The public cloud is the shared cloud. In this model, third-party providers deliver storage, computing power, and applications to multiple users." — 公有云的定义：第三方提供商向多用户交付共享资源
|
||||
|
||||
> "The private cloud is dedicated to your organization, which you access over a secure private network." — 私有云的定义：组织专用的安全私有网络访问环境
|
||||
|
||||
> "The hybrid cloud is a computing environment that uses both the public and private cloud models, sharing data and apps between the two to take advantage of the benefits that each provides." — 混合云的定义：融合两种模型，通过数据和应用在两者间的共享实现优势互补
|
||||
|
||||
> "No matter which cloud environment you work in, your problems don't go away. Though you're purchasing services from third-party vendors, you still have to do your due diligence." — 共享责任模型：无论哪种云环境，用户组织仍需对访问控制、云安全和灾难恢复承担最终责任
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudComputing]]：通过互联网远程使用第三方服务器上的计算资源，无需本地部署硬件
|
||||
- [[PublicCloud]]：多租户共享模式，第三方提供商向多个组织交付存储、计算能力和应用，按用量付费
|
||||
- [[PrivateCloud]]：单一组织专用的云环境，通过安全私有网络访问，可本地托管或第三方管理，提供更高安全性、控制力和合规性
|
||||
- [[HybridCloud]]：同时使用公有云和私有云的计算环境，数据和应用在两者间共享，根据安全、性能、成本需求分配工作负载
|
||||
- [[SaaS-PaaS-IaaS]]：云计算服务交付模式的三层——软件即服务、平台即服务、基础设施即服务
|
||||
- [[SharedResponsibilityModel]]：云安全责任分配模型——供应商负责底层基础设施灵活性与敏捷性，用户组织负责访问控制、安全加密和灾难恢复规划
|
||||
- [[CloudStrategy]]：有意图的云战略——从工作负载需求出发，权衡公私混合各模型利弊，制定并持续调整的云部署策略
|
||||
|
||||
## Key Entities
|
||||
- [[BMC]]：BMC Software — 源文章的发布机构，全球企业软件公司，为 Forbes Global 50 中 86% 的企业提供自动化应用、系统和服务
|
||||
- BMC Helix：独立运营的公司，帮助企业将 AI 转化为行动
|
||||
- RaaS（Ransomware as a Service）：勒索软件即服务——网络犯罪分子利用云基础设施的"犯罪即服务"模式
|
||||
|
||||
## Connections
|
||||
- [[PublicCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[PrivateCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← combines ← [[PublicCloud]] + [[PrivateCloud]]
|
||||
- [[CloudStrategy]] ← drives ← [[PublicCloud]] + [[PrivateCloud]] + [[HybridCloud]]
|
||||
- [[SharedResponsibilityModel]] ← applies_to ← [[PublicCloud]] + [[PrivateCloud]] + [[HybridCloud]]
|
||||
- [[SaaS-PaaS-IaaS]] ← delivered_by ← [[PublicCloud]] + [[PrivateCloud]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[CloudComputing]]（来源：[[cloud-maturity-model]]）可能存在视角冲突：
|
||||
- **冲突点：** 本文强调"云消除了基础设施管理复杂性"，而云成熟度模型强调云迁移后运维复杂性的增加
|
||||
- **当前观点：** 公有云"减少复杂度"——供应商负责维护最新硬件和应用版本，降低内部 IT 专业知识需求
|
||||
- **对方观点：** 实际云迁移会增加运维复杂度——多租户安全治理、成本追踪、跨环境集成等问题需要专门的云运维能力
|
||||
---
|
||||
title: "Public vs Private vs Hybrid Cloud Differences Explained"
|
||||
type: source
|
||||
tags: [cloud-computing, cloud-strategy, infrastructure]
|
||||
date: 2025-06-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题：** 公有云、私有云与混合云三种云计算部署模型的核心差异、优缺点及适用场景对比
|
||||
- **问题域：** 企业如何根据安全、成本、可扩展性、合规等需求选择合适的云部署模式
|
||||
- **方法/机制：** 系统性地从定义、优势、劣势、适用场景四个维度对比三种云模型；强调混合云作为折中方案的价值；提出"共享责任模型"概念
|
||||
- **结论/价值：** 三种云模型各有优劣，企业应根据工作负载特点制定有意图（intentional）的云策略，而非简单选择某一模型
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **公有云** 通过多租户共享模式提供高弹性、低成本、快速上线的计算服务，但在大规模企业场景下 TCO 可能指数级上升，且安全性和合规控制最弱
|
||||
- **私有云** 为单一组织提供专用环境，带来更高的安全性、控制力和合规灵活性，但成本最高、管理复杂、对远程用户不够友好
|
||||
- **混合云** 通过在同一架构中组合公私云实现"安全与扩展兼得"——敏感工作负载在私有云，普通负载在公有云，兼顾成本效率与安全韧性
|
||||
- **云选择决策** 应以工作负载需求为驱动，基于安全性、性能、成本三大维度制定有意图的云策略，且需持续评估和调整
|
||||
|
||||
## Key Quotes
|
||||
> "The public cloud is the shared cloud. In this model, third-party providers deliver storage, computing power, and applications to multiple users." — 公有云的定义：第三方提供商向多用户交付共享资源
|
||||
|
||||
> "The private cloud is dedicated to your organization, which you access over a secure private network." — 私有云的定义：组织专用的安全私有网络访问环境
|
||||
|
||||
> "The hybrid cloud is a computing environment that uses both the public and private cloud models, sharing data and apps between the two to take advantage of the benefits that each provides." — 混合云的定义：融合两种模型，通过数据和应用在两者间的共享实现优势互补
|
||||
|
||||
> "No matter which cloud environment you work in, your problems don't go away. Though you're purchasing services from third-party vendors, you still have to do your due diligence." — 共享责任模型：无论哪种云环境，用户组织仍需对访问控制、云安全和灾难恢复承担最终责任
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudComputing]]：通过互联网远程使用第三方服务器上的计算资源，无需本地部署硬件
|
||||
- [[PublicCloud]]：多租户共享模式，第三方提供商向多个组织交付存储、计算能力和应用，按用量付费
|
||||
- [[PrivateCloud]]：单一组织专用的云环境，通过安全私有网络访问，可本地托管或第三方管理，提供更高安全性、控制力和合规性
|
||||
- [[HybridCloud]]：同时使用公有云和私有云的计算环境，数据和应用在两者间共享，根据安全、性能、成本需求分配工作负载
|
||||
- [[SaaS-PaaS-IaaS]]：云计算服务交付模式的三层——软件即服务、平台即服务、基础设施即服务
|
||||
- [[SharedResponsibilityModel]]：云安全责任分配模型——供应商负责底层基础设施灵活性与敏捷性，用户组织负责访问控制、安全加密和灾难恢复规划
|
||||
- [[CloudStrategy]]：有意图的云战略——从工作负载需求出发，权衡公私混合各模型利弊，制定并持续调整的云部署策略
|
||||
|
||||
## Key Entities
|
||||
- [[BMC]]：BMC Software — 源文章的发布机构，全球企业软件公司，为 Forbes Global 50 中 86% 的企业提供自动化应用、系统和服务
|
||||
- BMC Helix：独立运营的公司，帮助企业将 AI 转化为行动
|
||||
- RaaS（Ransomware as a Service）：勒索软件即服务——网络犯罪分子利用云基础设施的"犯罪即服务"模式
|
||||
|
||||
## Connections
|
||||
- [[PublicCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[PrivateCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← combines ← [[PublicCloud]] + [[PrivateCloud]]
|
||||
- [[CloudStrategy]] ← drives ← [[PublicCloud]] + [[PrivateCloud]] + [[HybridCloud]]
|
||||
- [[SharedResponsibilityModel]] ← applies_to ← [[PublicCloud]] + [[PrivateCloud]] + [[HybridCloud]]
|
||||
- [[SaaS-PaaS-IaaS]] ← delivered_by ← [[PublicCloud]] + [[PrivateCloud]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[CloudComputing]]（来源：[[cloud-maturity-model]]）可能存在视角冲突：
|
||||
- **冲突点：** 本文强调"云消除了基础设施管理复杂性"，而云成熟度模型强调云迁移后运维复杂性的增加
|
||||
- **当前观点：** 公有云"减少复杂度"——供应商负责维护最新硬件和应用版本，降低内部 IT 专业知识需求
|
||||
- **对方观点：** 实际云迁移会增加运维复杂度——多租户安全治理、成本追踪、跨环境集成等问题需要专门的云运维能力
|
||||
|
||||
@@ -1,73 +1,73 @@
|
||||
---
|
||||
title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: [cloud-devops, disaster-recovery, sre, feature-flags, continuous-delivery]
|
||||
date: 2019-01-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）在现代灾难恢复和持续交付中的关键区别与实践应用
|
||||
- 问题域：云原生/DevOps 环境下的灾难恢复规划、软件部署风险管控、Feature Flag 驱动的微恢复策略
|
||||
- 方法/机制：
|
||||
- RTO 衡量系统停机时长容忍度，RPO 衡量数据丢失容忍度
|
||||
- 应用分层（Tier 1/2/3）分配差异化恢复目标
|
||||
- Feature Flag 实现部署与发布解耦，支持渐进式灰度发布和即时 Kill Switch
|
||||
- Feature Flag 将 RTO 从"小时级回滚"缩短至"秒级开关切换"
|
||||
- 结论/价值：预防优于恢复；Feature Flag 是现代持续交付中实现激进 RTO/RPO 目标的最佳投资回报比方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Feature Flag 将部署（Deploy）与发布（Release）解耦，使回滚从"紧急代码部署（小时级）"变为"配置变更（秒级）"
|
||||
- 渐进式灰度发布（1%→5%→25%→100%）将故障影响范围限制在早期阶段，RTO 可降至秒级
|
||||
- 不能单独优化 RTO 或 RPO——高频备份（优秀 RPO）+ 慢速恢复（糟糕 RTO）等于无用功
|
||||
- 不同的应用/功能应拥有不同的恢复目标（Core Payment: 秒级 RTO + 零 RPO；Beta 功能: 分钟级 RTO）
|
||||
- 成本效益原则：若停机一小时损失 $10K，不要每年花 $100K 基础设施去预防它
|
||||
|
||||
## Key Quotes
|
||||
> "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose." — 核心概念区分
|
||||
> "Deploy whenever you want, release when you're ready." — Feature Flag 解耦哲学
|
||||
> "Having backups every 30 seconds (a great RPO) doesn't help if it takes you 6 hours to restore from those backups (a terrible RTO)." — RTO/RPO 必须同时优化
|
||||
> "Prevention beats cure: the best disaster recovery solution is the one you'll actually use when things go wrong." — HP 案例引出核心结论
|
||||
|
||||
## Key Concepts
|
||||
- [[概念页面待创建]]：**RTO（Recovery Time Objective）**——系统允许的最大停机时长，从故障发生时刻开始计时
|
||||
- [[概念页面待创建]]：**RPO（Recovery Point Objective）**——允许丢失的最大数据量，从上一备份时刻向前测量
|
||||
- [[概念页面待创建]]：**Feature Flag**——通过条件分支控制功能上线，无需重新部署即可启用/禁用功能
|
||||
- [[概念页面待创建]]：**Kill Switch**——紧急禁用故障功能的即时开关，Feature Flag 驱动的 RTO 保险机制
|
||||
- [[概念页面待创建]]：**Progressive Rollout**——渐进式功能发布（1%/5%/25%/100%），限制故障影响范围
|
||||
- [[概念页面待创建]]：**Micro-Recovery**——基于 Feature Flag 的功能级回滚，而非整应用回滚
|
||||
|
||||
## Key Entities
|
||||
- [[实体页面待创建]]：**LaunchDarkly**——Feature Flag 管理平台，本文档的主要案例引用来源（HP、Christian Dior 等案例）
|
||||
- [[实体页面待创建]]：**Veeam / Acronis**——传统 DR 工具（备份/服务器镜像/跨区域复制），作为传统方案对照组
|
||||
|
||||
## Connections
|
||||
- [[what-i-know-about-cloud-service-delivery-1]] ← 包含 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（本文档是云服务交付"备份恢复与灾难管理"领域的具体展开）
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] ← 支撑 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（DevOps 成熟度中"监控可观测性"和"错误预算"是 RTO/RPO 的量化手段）
|
||||
- [[cloud-devop-maturity-guideline]] ← 关联 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（DORA 四项指标中的 MTTR 直接对应 RTO）
|
||||
- [[continuous-delivery]]（概念尚待建立）← 核心应用场景 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统 DR 思维存在框架冲突：
|
||||
- 冲突点：传统 DR 关注硬件灾难（火灾/断电/硬件故障），本文档认为现代高频部署场景下软件故障（Bug/错误迁移/AI 模型异常）才是主要风险
|
||||
- 当前观点：Feature Flag + Kill Switch + 渐进式发布比传统热备基础设施更有效且成本更低
|
||||
- 对方观点：传统 DR 基础设施（Veeam/Acronis + 多数据中心热备）仍是不可替代的硬件级保障
|
||||
- 注：两者并不互斥——软件层面用 Feature Flag 快速止血，基础设施层面仍需传统 DR 兜底
|
||||
|
||||
## Tier System Reference（应用分级体系）
|
||||
|
||||
| Tier | 示例 | RTO 目标 | RPO 目标 | 策略 |
|
||||
|------|------|---------|---------|------|
|
||||
| (1) Critical | 支付处理、用户认证、核心产品 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动回滚 + 24/7 告警 |
|
||||
| (2) Important | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag + 手动回滚 + 工作时间监控 |
|
||||
| (3) Nice-to-have | 内部工具、开发环境、文档站 | < 4 小时 | < 1 小时 | 基础监控 + 人工恢复流程 |
|
||||
|
||||
## LaunchDarkly Business Impact Data
|
||||
- HP：将回滚时间从"小时级"缩短至"分钟级"
|
||||
- Christian Dior：将 15 分钟回滚缩短为"即时开关切换"
|
||||
- 86% 的 LaunchDarkly 客户在一天内从故障中恢复
|
||||
- 42% 的 LaunchDarkly 客户在"小时级（甚至分钟级）"内恢复
|
||||
- 8% 客户运营成本降低超过 50%
|
||||
- 59% 客户运营成本降低 11%-50%
|
||||
---
|
||||
title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: [cloud-devops, disaster-recovery, sre, feature-flags, continuous-delivery]
|
||||
date: 2019-01-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）在现代灾难恢复和持续交付中的关键区别与实践应用
|
||||
- 问题域：云原生/DevOps 环境下的灾难恢复规划、软件部署风险管控、Feature Flag 驱动的微恢复策略
|
||||
- 方法/机制：
|
||||
- RTO 衡量系统停机时长容忍度，RPO 衡量数据丢失容忍度
|
||||
- 应用分层（Tier 1/2/3）分配差异化恢复目标
|
||||
- Feature Flag 实现部署与发布解耦，支持渐进式灰度发布和即时 Kill Switch
|
||||
- Feature Flag 将 RTO 从"小时级回滚"缩短至"秒级开关切换"
|
||||
- 结论/价值：预防优于恢复；Feature Flag 是现代持续交付中实现激进 RTO/RPO 目标的最佳投资回报比方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Feature Flag 将部署（Deploy）与发布（Release）解耦，使回滚从"紧急代码部署（小时级）"变为"配置变更（秒级）"
|
||||
- 渐进式灰度发布（1%→5%→25%→100%）将故障影响范围限制在早期阶段，RTO 可降至秒级
|
||||
- 不能单独优化 RTO 或 RPO——高频备份（优秀 RPO）+ 慢速恢复（糟糕 RTO）等于无用功
|
||||
- 不同的应用/功能应拥有不同的恢复目标（Core Payment: 秒级 RTO + 零 RPO；Beta 功能: 分钟级 RTO）
|
||||
- 成本效益原则：若停机一小时损失 $10K，不要每年花 $100K 基础设施去预防它
|
||||
|
||||
## Key Quotes
|
||||
> "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose." — 核心概念区分
|
||||
> "Deploy whenever you want, release when you're ready." — Feature Flag 解耦哲学
|
||||
> "Having backups every 30 seconds (a great RPO) doesn't help if it takes you 6 hours to restore from those backups (a terrible RTO)." — RTO/RPO 必须同时优化
|
||||
> "Prevention beats cure: the best disaster recovery solution is the one you'll actually use when things go wrong." — HP 案例引出核心结论
|
||||
|
||||
## Key Concepts
|
||||
- [[概念页面待创建]]：**RTO（Recovery Time Objective）**——系统允许的最大停机时长，从故障发生时刻开始计时
|
||||
- [[概念页面待创建]]：**RPO（Recovery Point Objective）**——允许丢失的最大数据量，从上一备份时刻向前测量
|
||||
- [[概念页面待创建]]：**Feature Flag**——通过条件分支控制功能上线，无需重新部署即可启用/禁用功能
|
||||
- [[概念页面待创建]]：**Kill Switch**——紧急禁用故障功能的即时开关，Feature Flag 驱动的 RTO 保险机制
|
||||
- [[概念页面待创建]]：**Progressive Rollout**——渐进式功能发布（1%/5%/25%/100%），限制故障影响范围
|
||||
- [[概念页面待创建]]：**Micro-Recovery**——基于 Feature Flag 的功能级回滚，而非整应用回滚
|
||||
|
||||
## Key Entities
|
||||
- [[实体页面待创建]]：**LaunchDarkly**——Feature Flag 管理平台，本文档的主要案例引用来源（HP、Christian Dior 等案例）
|
||||
- [[实体页面待创建]]：**Veeam / Acronis**——传统 DR 工具（备份/服务器镜像/跨区域复制），作为传统方案对照组
|
||||
|
||||
## Connections
|
||||
- [[what-i-know-about-cloud-service-delivery-1]] ← 包含 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（本文档是云服务交付"备份恢复与灾难管理"领域的具体展开）
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] ← 支撑 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（DevOps 成熟度中"监控可观测性"和"错误预算"是 RTO/RPO 的量化手段）
|
||||
- [[cloud-devop-maturity-guideline]] ← 关联 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（DORA 四项指标中的 MTTR 直接对应 RTO）
|
||||
- [[continuous-delivery]]（概念尚待建立）← 核心应用场景 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统 DR 思维存在框架冲突：
|
||||
- 冲突点：传统 DR 关注硬件灾难（火灾/断电/硬件故障），本文档认为现代高频部署场景下软件故障（Bug/错误迁移/AI 模型异常）才是主要风险
|
||||
- 当前观点：Feature Flag + Kill Switch + 渐进式发布比传统热备基础设施更有效且成本更低
|
||||
- 对方观点：传统 DR 基础设施（Veeam/Acronis + 多数据中心热备）仍是不可替代的硬件级保障
|
||||
- 注：两者并不互斥——软件层面用 Feature Flag 快速止血，基础设施层面仍需传统 DR 兜底
|
||||
|
||||
## Tier System Reference（应用分级体系）
|
||||
|
||||
| Tier | 示例 | RTO 目标 | RPO 目标 | 策略 |
|
||||
|------|------|---------|---------|------|
|
||||
| (1) Critical | 支付处理、用户认证、核心产品 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动回滚 + 24/7 告警 |
|
||||
| (2) Important | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag + 手动回滚 + 工作时间监控 |
|
||||
| (3) Nice-to-have | 内部工具、开发环境、文档站 | < 4 小时 | < 1 小时 | 基础监控 + 人工恢复流程 |
|
||||
|
||||
## LaunchDarkly Business Impact Data
|
||||
- HP：将回滚时间从"小时级"缩短至"分钟级"
|
||||
- Christian Dior：将 15 分钟回滚缩短为"即时开关切换"
|
||||
- 86% 的 LaunchDarkly 客户在一天内从故障中恢复
|
||||
- 42% 的 LaunchDarkly 客户在"小时级（甚至分钟级）"内恢复
|
||||
- 8% 客户运营成本降低超过 50%
|
||||
- 59% 客户运营成本降低 11%-50%
|
||||
|
||||
@@ -1,58 +1,58 @@
|
||||
---
|
||||
title: "The Myths and Misconceptions About Cloud Computing | LinkedIn"
|
||||
type: source
|
||||
tags: [cloud-computing, misconceptions, cloud-security, cost-optimization]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：云计算领域的7大常见误解及其真相
|
||||
- 问题域：企业或个人在采用云计算时的认知误区
|
||||
- 方法/机制：通过逐一反驳误解，揭示云计算的实际能力与优势
|
||||
- 结论/价值：帮助决策者消除顾虑，正确认识云计算的安全性、成本效益和可靠性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 云安全往往比本地解决方案更强大：主流云服务商投入大量资源于加密、防火墙、多因素认证，符合 ISO 27001、HIPAA、GDPR 等严苛标准
|
||||
- 云远不止是"别人的电脑"：云是由冗余、可扩展、高可用的数据中心网络组成，远超典型本地解决方案
|
||||
- 通过适当管理，云计算具有成本效益：采用按需付费模式、预留实例、自动扩展和无服务器计算可显著降低成本
|
||||
- 云服务提供强大的数据治理工具：组织可管理权限、加密数据、监控访问日志，支持混合云和多云部署
|
||||
- 各类规模的企业都能从云计算中受益：中小企业可享受灵活定价，无需大额前期投资即可使用企业级技术
|
||||
- 适当的规划可使云迁移顺利推进：分阶段迁移、混合云方案和专业迁移服务可降低风险
|
||||
- 主要云服务商提供高可用性和冗余：SLA 保证可用性通常超过 99.99%
|
||||
|
||||
## Key Quotes
|
||||
> "Leading cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication." — 云服务商在安全措施上的持续投入
|
||||
|
||||
> "Cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed." — 按需付费的灵活性
|
||||
|
||||
> "Major cloud providers offer service-level agreements (SLAs) that guarantee uptime, often exceeding 99.99%." — 服务等级协议保证高可用性
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudComputing]]：通过互联网按需提供计算资源、存储和应用的服务模式
|
||||
- [[CloudSecurity]]：云环境下的安全实践，包括加密、MFA、安全合规认证
|
||||
- [[PayAsYouGo]]：按使用量付费的成本模型
|
||||
- [[HybridCloud]]：混合云，结合本地设施和公有云的部署模式
|
||||
- [[MultiCloud]]：多云战略，使用多个云服务商的服务
|
||||
- [[CloudMigration]]：将工作负载从本地迁移到云端的过程
|
||||
- [[HighAvailability]]：高可用性设计，确保服务持续运行
|
||||
- [[AutoScaling]]：根据负载自动调整资源的能力
|
||||
|
||||
## Key Entities
|
||||
- [[ISO27001]]：国际认可的信息安全管理标准
|
||||
- [[HIPAA]]：美国医疗保健信息保护法规
|
||||
- [[GDPR]]：欧盟通用数据保护条例
|
||||
|
||||
## Connections
|
||||
- [[CloudComputing]] ← topic ← [[The Myths and Misconceptions About Cloud Computing]]
|
||||
- [[CloudSecurity]] ← key_mechanism ← [[CloudComputing]]
|
||||
- [[PayAsYouGo]] ← cost_model ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← solution_type ← [[CloudMigration]]
|
||||
|
||||
## Contradictions
|
||||
- 与 On-Premises 相比的误解：
|
||||
- 冲突点：安全性、控制权、可靠性
|
||||
- 当前观点：云安全更强（专业团队 24/7 监控、自动更新）、数据控制完善、高可用 SLA
|
||||
- 对方观点：本地部署更安全、更可控、性能更稳定
|
||||
---
|
||||
title: "The Myths and Misconceptions About Cloud Computing | LinkedIn"
|
||||
type: source
|
||||
tags: [cloud-computing, misconceptions, cloud-security, cost-optimization]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：云计算领域的7大常见误解及其真相
|
||||
- 问题域：企业或个人在采用云计算时的认知误区
|
||||
- 方法/机制：通过逐一反驳误解，揭示云计算的实际能力与优势
|
||||
- 结论/价值：帮助决策者消除顾虑，正确认识云计算的安全性、成本效益和可靠性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 云安全往往比本地解决方案更强大：主流云服务商投入大量资源于加密、防火墙、多因素认证，符合 ISO 27001、HIPAA、GDPR 等严苛标准
|
||||
- 云远不止是"别人的电脑"：云是由冗余、可扩展、高可用的数据中心网络组成，远超典型本地解决方案
|
||||
- 通过适当管理，云计算具有成本效益：采用按需付费模式、预留实例、自动扩展和无服务器计算可显著降低成本
|
||||
- 云服务提供强大的数据治理工具：组织可管理权限、加密数据、监控访问日志，支持混合云和多云部署
|
||||
- 各类规模的企业都能从云计算中受益：中小企业可享受灵活定价，无需大额前期投资即可使用企业级技术
|
||||
- 适当的规划可使云迁移顺利推进：分阶段迁移、混合云方案和专业迁移服务可降低风险
|
||||
- 主要云服务商提供高可用性和冗余：SLA 保证可用性通常超过 99.99%
|
||||
|
||||
## Key Quotes
|
||||
> "Leading cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication." — 云服务商在安全措施上的持续投入
|
||||
|
||||
> "Cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed." — 按需付费的灵活性
|
||||
|
||||
> "Major cloud providers offer service-level agreements (SLAs) that guarantee uptime, often exceeding 99.99%." — 服务等级协议保证高可用性
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudComputing]]：通过互联网按需提供计算资源、存储和应用的服务模式
|
||||
- [[CloudSecurity]]：云环境下的安全实践，包括加密、MFA、安全合规认证
|
||||
- [[PayAsYouGo]]：按使用量付费的成本模型
|
||||
- [[HybridCloud]]：混合云，结合本地设施和公有云的部署模式
|
||||
- [[MultiCloud]]：多云战略，使用多个云服务商的服务
|
||||
- [[CloudMigration]]：将工作负载从本地迁移到云端的过程
|
||||
- [[HighAvailability]]：高可用性设计，确保服务持续运行
|
||||
- [[AutoScaling]]：根据负载自动调整资源的能力
|
||||
|
||||
## Key Entities
|
||||
- [[ISO27001]]：国际认可的信息安全管理标准
|
||||
- [[HIPAA]]：美国医疗保健信息保护法规
|
||||
- [[GDPR]]：欧盟通用数据保护条例
|
||||
|
||||
## Connections
|
||||
- [[CloudComputing]] ← topic ← [[The Myths and Misconceptions About Cloud Computing]]
|
||||
- [[CloudSecurity]] ← key_mechanism ← [[CloudComputing]]
|
||||
- [[PayAsYouGo]] ← cost_model ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← solution_type ← [[CloudMigration]]
|
||||
|
||||
## Contradictions
|
||||
- 与 On-Premises 相比的误解：
|
||||
- 冲突点：安全性、控制权、可靠性
|
||||
- 当前观点：云安全更强（专业团队 24/7 监控、自动更新）、数据控制完善、高可用 SLA
|
||||
- 对方观点：本地部署更安全、更可控、性能更稳定
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "These 6 Linux Apps Let You Monitor System Resources in Style"
|
||||
type: source
|
||||
tags: [linux, system-monitoring, open-source, devops, tooling]
|
||||
date: 2025-12-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Linux 系统资源监控工具横向评测，推荐 6 款替代桌面环境默认资源管理器的应用
|
||||
- 问题域：Linux 用户需要比桌面默认资源管理器更轻量、更美观或功能更丰富的系统监控方案
|
||||
- 方法/机制：按 TUI（命令行文本界面）和 GUI 两大类，分别评测 6 款工具的功能与体验
|
||||
- 结论/价值：作者首推 **Btop++**（TUI 类），理由是兼具美观与可用性；GUI 类首选 **Mission Center**（类 Task Manager 体验）和 **Stacer**（功能最丰富）；TUI 工具在 SSH 远程场景下尤为实用
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Btop++：主体（TUI 监控工具）+ 机制（多面板布局、支持进程信号/Nice 值/主题切换）+ 结果（作者首选）
|
||||
- Htop：主体（TUI 进程监控）+ 机制（键盘驱动/F 键操作）+ 结果（适合追求极简流程监控的用户）
|
||||
- Glances：主体（轻量 TUI 监控）+ 机制（全键盘导航/k 键杀进程）+ 结果（最轻最快）
|
||||
- Bottom：主体（实时图形化资源监控）+ 机制（专注 CPU/网络/内存图表，非任务管理器）+ 结果（纯图形监控，无交互）
|
||||
- Mission Center：主体（GNOME 原生 GUI 资源管理器）+ 机制（性能/应用/服务三标签页，类 Task Manager）+ 结果（Debian/Ubuntu 仅有 Snap 包）
|
||||
- Stacer：主体（功能最全面的 GUI 资源管理器）+ 机制（仪表盘/进程/服务/启动项/APT 仓库/缓存清理）+ 结果（唯一支持桌面定制和垃圾清理的工具）
|
||||
|
||||
## Key Quotes
|
||||
> "TUI apps make the best resource monitors, in my opinion. They're snappy and responsive, even when the GUI is lagging." — 作者偏好 TUI 的核心理由
|
||||
> "Btop++ always gets my vote. It features a nice balance between usability and aesthetics." — Btop++ 推荐结论
|
||||
> "Mission Center is your friend" if you want something close to the Windows Task Manager — Mission Center 推荐定位
|
||||
|
||||
## Key Concepts
|
||||
- [[TUI]]：文本用户界面，通过终端运行，响应迅速，适合 SSH 远程场景
|
||||
- [[System-Monitoring]]：系统资源监控，涵盖 CPU、内存、存储、网络、进程等维度
|
||||
- [[Process-Management]]：进程管理，包括查看、搜索、终止、优先级调整
|
||||
|
||||
## Key Entities
|
||||
- [[Btop++]]：作者首选 TUI 资源监控器，支持 Pacman 安装和 Snap 包（Debian/Ubuntu）
|
||||
- [[Htop]]：经典 TUI 进程监控器，全键盘驱动，适合进程优先场景
|
||||
- [[Glances]]：极轻量 TUI 监控器，全键盘操作，适合资源受限环境
|
||||
- [[Bottom]]：专注实时图形化监控的工具，支持进程树视图，非交互式任务管理器
|
||||
- [[Mission-Center]]：GNOME 原生 GUI 资源管理器，提供性能/应用/服务三标签页
|
||||
- [[Stacer]]：功能最丰富的 GUI 资源管理器，支持缓存清理、启动项管理、APT 仓库配置
|
||||
- [[HowToGeek]]：文章来源的技术博客
|
||||
|
||||
## Connections
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 应用层 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：本文工具为单机能见度层，与 Prometheus/Grafana 企业监控方案互补
|
||||
- [[linux-运维必会的-150-个命令]] ← 关联 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：系统监控是 Linux 运维基础技能，本文 6 款工具覆盖该技能核心场景
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 对比 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：企业级（Prometheus/Grafana）vs 轻量级（本文工具）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 定位差异：
|
||||
- 冲突点：监控方案选择
|
||||
- 当前观点：单机能见度优先，用 Btop++ 或 Mission Center 快速定位问题
|
||||
- 对方观点：企业级基础设施需 Prometheus + Grafana 实现集中可观测性
|
||||
- 说明：两者面向不同场景，不构成直接冲突；建议单节点用本文工具，多节点/生产环境用 Prometheus/Grafana
|
||||
---
|
||||
title: "These 6 Linux Apps Let You Monitor System Resources in Style"
|
||||
type: source
|
||||
tags: [linux, system-monitoring, open-source, devops, tooling]
|
||||
date: 2025-12-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Linux 系统资源监控工具横向评测，推荐 6 款替代桌面环境默认资源管理器的应用
|
||||
- 问题域：Linux 用户需要比桌面默认资源管理器更轻量、更美观或功能更丰富的系统监控方案
|
||||
- 方法/机制：按 TUI（命令行文本界面）和 GUI 两大类，分别评测 6 款工具的功能与体验
|
||||
- 结论/价值：作者首推 **Btop++**（TUI 类），理由是兼具美观与可用性；GUI 类首选 **Mission Center**（类 Task Manager 体验）和 **Stacer**（功能最丰富）；TUI 工具在 SSH 远程场景下尤为实用
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Btop++：主体（TUI 监控工具）+ 机制（多面板布局、支持进程信号/Nice 值/主题切换）+ 结果（作者首选）
|
||||
- Htop：主体（TUI 进程监控）+ 机制（键盘驱动/F 键操作）+ 结果（适合追求极简流程监控的用户）
|
||||
- Glances：主体（轻量 TUI 监控）+ 机制（全键盘导航/k 键杀进程）+ 结果（最轻最快）
|
||||
- Bottom：主体（实时图形化资源监控）+ 机制（专注 CPU/网络/内存图表，非任务管理器）+ 结果（纯图形监控，无交互）
|
||||
- Mission Center：主体（GNOME 原生 GUI 资源管理器）+ 机制（性能/应用/服务三标签页，类 Task Manager）+ 结果（Debian/Ubuntu 仅有 Snap 包）
|
||||
- Stacer：主体（功能最全面的 GUI 资源管理器）+ 机制（仪表盘/进程/服务/启动项/APT 仓库/缓存清理）+ 结果（唯一支持桌面定制和垃圾清理的工具）
|
||||
|
||||
## Key Quotes
|
||||
> "TUI apps make the best resource monitors, in my opinion. They're snappy and responsive, even when the GUI is lagging." — 作者偏好 TUI 的核心理由
|
||||
> "Btop++ always gets my vote. It features a nice balance between usability and aesthetics." — Btop++ 推荐结论
|
||||
> "Mission Center is your friend" if you want something close to the Windows Task Manager — Mission Center 推荐定位
|
||||
|
||||
## Key Concepts
|
||||
- [[TUI]]：文本用户界面，通过终端运行，响应迅速，适合 SSH 远程场景
|
||||
- [[System-Monitoring]]：系统资源监控，涵盖 CPU、内存、存储、网络、进程等维度
|
||||
- [[Process-Management]]：进程管理，包括查看、搜索、终止、优先级调整
|
||||
|
||||
## Key Entities
|
||||
- [[Btop++]]：作者首选 TUI 资源监控器，支持 Pacman 安装和 Snap 包（Debian/Ubuntu）
|
||||
- [[Htop]]：经典 TUI 进程监控器，全键盘驱动，适合进程优先场景
|
||||
- [[Glances]]：极轻量 TUI 监控器，全键盘操作，适合资源受限环境
|
||||
- [[Bottom]]：专注实时图形化监控的工具，支持进程树视图，非交互式任务管理器
|
||||
- [[Mission-Center]]：GNOME 原生 GUI 资源管理器，提供性能/应用/服务三标签页
|
||||
- [[Stacer]]：功能最丰富的 GUI 资源管理器，支持缓存清理、启动项管理、APT 仓库配置
|
||||
- [[HowToGeek]]：文章来源的技术博客
|
||||
|
||||
## Connections
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 应用层 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：本文工具为单机能见度层，与 Prometheus/Grafana 企业监控方案互补
|
||||
- [[linux-运维必会的-150-个命令]] ← 关联 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：系统监控是 Linux 运维基础技能，本文 6 款工具覆盖该技能核心场景
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 对比 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：企业级（Prometheus/Grafana）vs 轻量级（本文工具）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 定位差异：
|
||||
- 冲突点：监控方案选择
|
||||
- 当前观点：单机能见度优先，用 Btop++ 或 Mission Center 快速定位问题
|
||||
- 对方观点：企业级基础设施需 Prometheus + Grafana 实现集中可观测性
|
||||
- 说明：两者面向不同场景，不构成直接冲突；建议单节点用本文工具，多节点/生产环境用 Prometheus/Grafana
|
||||
|
||||
@@ -1,57 +1,57 @@
|
||||
---
|
||||
title: "Trae远程开发部署指南"
|
||||
type: source
|
||||
tags: [remote-ssh, trae, ubuntu]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Trae远程开发部署指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Trae IDE 通过 SSH 远程连接 Ubuntu 服务器进行 Docker 容器化项目的开发工作流配置
|
||||
- 问题域：远程开发环境搭建、Docker 与 IDE 集成、内网穿透访问
|
||||
- 方法/机制：SSH 免密登录 → Trae Remote-SSH 连接 → Docker 容器 Attach 或宿主机文件编辑 → Tailscale/FRP 公网访问
|
||||
- 结论/价值：提供一套完整的"本地 UI + 远程服务器开发"解决方案，支持 Attach 容器调试和 docker-compose 编排两种模式
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Trae 原生支持 VS Code 插件生态，通过 Remote-SSH 插件可远程连接 Ubuntu 服务器
|
||||
- 开发模式 A（Attach 容器）：适合调试，环境完全隔离，直接使用容器内语言环境
|
||||
- 开发模式 B（宿主机文件 + Docker CLI）：适合编排 docker-compose.yml 和管理多容器配置
|
||||
- 用户必须加入 docker 用户组才能让 Trae 的 Docker 插件正常工作
|
||||
- 文件权限（UID/GID）问题会导致 Volume 挂载生成的 Build 文件归属 root，宿主机无法操作
|
||||
|
||||
## Key Quotes
|
||||
> "开发环境的核心在于 Bind Mount（绑定挂载），实现代码修改实时生效" — 解释开发环境 docker-compose.yml 的设计原则
|
||||
|
||||
> "SSH 登录服务器执行：sudo usermod -aG docker $USER，必须注销并重新登录" — Docker 用户组配置关键步骤
|
||||
|
||||
> "不要直接暴露 SSH 端口，建议安装 Tailscale 或 Cloudflare Tunnel" — 内网穿透安全建议
|
||||
|
||||
## Key Concepts
|
||||
- [[Remote-SSH]]：通过 SSH 协议将本地 IDE 连接到远程服务器，代码运行在服务器端但 UI 在本地
|
||||
- [[Bind Mount]]：Docker Volume 挂载方式，将宿主机目录映射到容器内，实现代码修改实时生效
|
||||
- [[Attach 容器]]：将 IDE 直接连接到正在运行的 Docker 容器内部进行开发调试的模式
|
||||
- [[Docker 用户组]]：将用户加入 docker 组使其无需 sudo 即可运行 docker 命令
|
||||
- [[SSH Config]]：SSH 客户端配置文件（~/.ssh/config），定义 Host 别名和连接参数
|
||||
- [[SSH 免密登录]]：通过 ssh-copy-id 公钥分发实现无密码 SSH 连接
|
||||
- [[Docker Compose 开发模式]]：使用 docker-compose.yml 编排开发环境，通过 volumes 实现源码挂载
|
||||
|
||||
## Key Entities
|
||||
- [[Trae]]：国产 AI IDE，基于 VS Code，支持 Remote-SSH 远程开发，与 Cursor 功能类似
|
||||
- [[Ubuntu 2]]：开发服务器（192.168.3.45），存放源码，运行带 Bind Mount 的开发容器
|
||||
- [[Ubuntu 1]]：生产服务器（192.168.3.47），运行生产容器，通过 Docker 卷持久化数据
|
||||
- [[ThinkBook]]：本地笔记本，作为 Trae UI 端连接远程服务器
|
||||
- [[Tailscale]]：零配置 VPN 工具，可替代 FRP 提供安全的公网 SSH 访问
|
||||
- [[Docker]]：容器化平台，远程开发的核心载体
|
||||
|
||||
## Connections
|
||||
- [[Trae]] ← remote-ssh ← [[Ubuntu 2]]
|
||||
- [[Docker]] ← hosts ← [[Ubuntu 2]]
|
||||
- [[Docker Compose]] ← manages containers on ← [[Ubuntu 2]]
|
||||
- [[Remote-SSH]] ← 公网穿透方案 ← [[Tailscale]] / [[frp]]
|
||||
- [[Ubuntu 2]] ← 公网访问 ← [[frp]] (ubuntu2-ext: ubuntu2.ishenwei.online:60024)
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
---
|
||||
title: "Trae远程开发部署指南"
|
||||
type: source
|
||||
tags: [remote-ssh, trae, ubuntu]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Trae远程开发部署指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Trae IDE 通过 SSH 远程连接 Ubuntu 服务器进行 Docker 容器化项目的开发工作流配置
|
||||
- 问题域：远程开发环境搭建、Docker 与 IDE 集成、内网穿透访问
|
||||
- 方法/机制：SSH 免密登录 → Trae Remote-SSH 连接 → Docker 容器 Attach 或宿主机文件编辑 → Tailscale/FRP 公网访问
|
||||
- 结论/价值：提供一套完整的"本地 UI + 远程服务器开发"解决方案，支持 Attach 容器调试和 docker-compose 编排两种模式
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Trae 原生支持 VS Code 插件生态，通过 Remote-SSH 插件可远程连接 Ubuntu 服务器
|
||||
- 开发模式 A（Attach 容器）：适合调试，环境完全隔离，直接使用容器内语言环境
|
||||
- 开发模式 B（宿主机文件 + Docker CLI）：适合编排 docker-compose.yml 和管理多容器配置
|
||||
- 用户必须加入 docker 用户组才能让 Trae 的 Docker 插件正常工作
|
||||
- 文件权限（UID/GID）问题会导致 Volume 挂载生成的 Build 文件归属 root，宿主机无法操作
|
||||
|
||||
## Key Quotes
|
||||
> "开发环境的核心在于 Bind Mount（绑定挂载），实现代码修改实时生效" — 解释开发环境 docker-compose.yml 的设计原则
|
||||
|
||||
> "SSH 登录服务器执行：sudo usermod -aG docker $USER，必须注销并重新登录" — Docker 用户组配置关键步骤
|
||||
|
||||
> "不要直接暴露 SSH 端口，建议安装 Tailscale 或 Cloudflare Tunnel" — 内网穿透安全建议
|
||||
|
||||
## Key Concepts
|
||||
- [[Remote-SSH]]：通过 SSH 协议将本地 IDE 连接到远程服务器，代码运行在服务器端但 UI 在本地
|
||||
- [[Bind Mount]]：Docker Volume 挂载方式，将宿主机目录映射到容器内，实现代码修改实时生效
|
||||
- [[Attach 容器]]：将 IDE 直接连接到正在运行的 Docker 容器内部进行开发调试的模式
|
||||
- [[Docker 用户组]]：将用户加入 docker 组使其无需 sudo 即可运行 docker 命令
|
||||
- [[SSH Config]]：SSH 客户端配置文件（~/.ssh/config），定义 Host 别名和连接参数
|
||||
- [[SSH 免密登录]]：通过 ssh-copy-id 公钥分发实现无密码 SSH 连接
|
||||
- [[Docker Compose 开发模式]]：使用 docker-compose.yml 编排开发环境，通过 volumes 实现源码挂载
|
||||
|
||||
## Key Entities
|
||||
- [[Trae]]：国产 AI IDE，基于 VS Code，支持 Remote-SSH 远程开发，与 Cursor 功能类似
|
||||
- [[Ubuntu 2]]：开发服务器（192.168.3.45），存放源码，运行带 Bind Mount 的开发容器
|
||||
- [[Ubuntu 1]]：生产服务器（192.168.3.47），运行生产容器，通过 Docker 卷持久化数据
|
||||
- [[ThinkBook]]：本地笔记本，作为 Trae UI 端连接远程服务器
|
||||
- [[Tailscale]]：零配置 VPN 工具，可替代 FRP 提供安全的公网 SSH 访问
|
||||
- [[Docker]]：容器化平台，远程开发的核心载体
|
||||
|
||||
## Connections
|
||||
- [[Trae]] ← remote-ssh ← [[Ubuntu 2]]
|
||||
- [[Docker]] ← hosts ← [[Ubuntu 2]]
|
||||
- [[Docker Compose]] ← manages containers on ← [[Ubuntu 2]]
|
||||
- [[Remote-SSH]] ← 公网穿透方案 ← [[Tailscale]] / [[frp]]
|
||||
- [[Ubuntu 2]] ← 公网访问 ← [[frp]] (ubuntu2-ext: ubuntu2.ishenwei.online:60024)
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
|
||||
@@ -1,44 +1,44 @@
|
||||
---
|
||||
title: "Ubuntu 24.04 启动 SSH 服务"
|
||||
type: source
|
||||
tags: [ssh, ubuntu, linux]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Ubuntu 24.04 enable SSH.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu 24.04 中启用 SSH 远程访问服务的完整操作指南
|
||||
- 问题域：Linux 服务器远程管理、SSH 服务配置与防火墙设置
|
||||
- 方法/机制：安装 OpenSSH Server → 启动并设置开机自启 → 配置 UFW 防火墙 → 验证服务状态 → 远程连接；核心变化：Ubuntu 24.04 默认使用 `ssh.socket` 激活机制（按需启动而非持续运行）
|
||||
- 结论/价值：提供 Ubuntu 24.04 SSH 快速启用指南，附带进阶配置（自定义端口、切换传统模式）
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Ubuntu 24.04 默认使用 **ssh.socket 激活机制**：仅在连接请求进入时才启动 SSH 守护进程，与旧版本（持续运行后台进程）行为不同
|
||||
- SSH 服务可通过 `sudo systemctl start ssh` 和 `sudo systemctl enable ssh` 手动启动并设置开机自启
|
||||
- 防火墙配置：使用 `sudo ufw allow ssh` 或 `sudo ufw allow 22/tcp` 放行 SSH 流量
|
||||
- 进阶配置：可通过 `sudo systemctl edit ssh.socket` 修改监听端口，而非仅修改 `/etc/ssh/sshd_config`
|
||||
- 如需切换回传统模式：先禁用 socket 激活（`sudo systemctl disable --now ssh.socket`），再启用 service 模式（`sudo systemctl enable --now ssh.service`）
|
||||
|
||||
## Key Quotes
|
||||
> "在 Ubuntu 24.04 中开启 SSH 服务非常简单，但这个版本引入了一个重要的变化：默认使用 ssh.socket 激活机制" — Ubuntu 24.04 SSH 配置说明
|
||||
|
||||
> "如果你习惯了旧版本的管理方式，或者需要修改自定义端口（例如改为 2222），在 24.04 中你可能需要注意：现在推荐通过 sudo systemctl edit ssh.socket 来修改监听端口" — 进阶配置说明
|
||||
|
||||
## Key Concepts
|
||||
- [[SocketActivation]]：按需激活机制，ssh.socket 在接收到连接请求时才启动 sshd 守护进程，与传统持续运行的 ssh.service 不同
|
||||
- [[UFW]]（Uncomplicated Firewall）：Ubuntu 默认防火墙管理工具，通过 `ufw allow ssh` 简化 iptables 规则配置
|
||||
- [[OpenSSH]]：开源 SSH 协议实现，Ubuntu 通过 `openssh-server` 包提供服务端功能
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu-24.04]]：Canonical Ltd 发布的 Linux 发行版，引入 ssh.socket 默认激活机制
|
||||
- [[systemd]]：Linux 系统和服务管理器，通过 systemctl 管理 ssh.service 和 ssh.socket
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 是远程管理 Ubuntu 服务器的基础，用于执行 rsync 备份命令）
|
||||
- [[Ubuntu Server科学上网]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 隧道可用于建立安全通道）
|
||||
- [[Linux运维必会的150个命令]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 相关命令如 ssh/scp/sftp 是运维必备命令）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "Ubuntu 24.04 启动 SSH 服务"
|
||||
type: source
|
||||
tags: [ssh, ubuntu, linux]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Ubuntu 24.04 enable SSH.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu 24.04 中启用 SSH 远程访问服务的完整操作指南
|
||||
- 问题域：Linux 服务器远程管理、SSH 服务配置与防火墙设置
|
||||
- 方法/机制：安装 OpenSSH Server → 启动并设置开机自启 → 配置 UFW 防火墙 → 验证服务状态 → 远程连接；核心变化：Ubuntu 24.04 默认使用 `ssh.socket` 激活机制（按需启动而非持续运行）
|
||||
- 结论/价值：提供 Ubuntu 24.04 SSH 快速启用指南，附带进阶配置（自定义端口、切换传统模式）
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Ubuntu 24.04 默认使用 **ssh.socket 激活机制**：仅在连接请求进入时才启动 SSH 守护进程，与旧版本（持续运行后台进程）行为不同
|
||||
- SSH 服务可通过 `sudo systemctl start ssh` 和 `sudo systemctl enable ssh` 手动启动并设置开机自启
|
||||
- 防火墙配置：使用 `sudo ufw allow ssh` 或 `sudo ufw allow 22/tcp` 放行 SSH 流量
|
||||
- 进阶配置：可通过 `sudo systemctl edit ssh.socket` 修改监听端口，而非仅修改 `/etc/ssh/sshd_config`
|
||||
- 如需切换回传统模式：先禁用 socket 激活（`sudo systemctl disable --now ssh.socket`），再启用 service 模式（`sudo systemctl enable --now ssh.service`）
|
||||
|
||||
## Key Quotes
|
||||
> "在 Ubuntu 24.04 中开启 SSH 服务非常简单，但这个版本引入了一个重要的变化：默认使用 ssh.socket 激活机制" — Ubuntu 24.04 SSH 配置说明
|
||||
|
||||
> "如果你习惯了旧版本的管理方式，或者需要修改自定义端口（例如改为 2222），在 24.04 中你可能需要注意：现在推荐通过 sudo systemctl edit ssh.socket 来修改监听端口" — 进阶配置说明
|
||||
|
||||
## Key Concepts
|
||||
- [[SocketActivation]]：按需激活机制，ssh.socket 在接收到连接请求时才启动 sshd 守护进程，与传统持续运行的 ssh.service 不同
|
||||
- [[UFW]]（Uncomplicated Firewall）：Ubuntu 默认防火墙管理工具，通过 `ufw allow ssh` 简化 iptables 规则配置
|
||||
- [[OpenSSH]]：开源 SSH 协议实现，Ubuntu 通过 `openssh-server` 包提供服务端功能
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu-24.04]]：Canonical Ltd 发布的 Linux 发行版，引入 ssh.socket 默认激活机制
|
||||
- [[systemd]]：Linux 系统和服务管理器，通过 systemctl 管理 ssh.service 和 ssh.socket
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 是远程管理 Ubuntu 服务器的基础，用于执行 rsync 备份命令）
|
||||
- [[Ubuntu Server科学上网]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 隧道可用于建立安全通道）
|
||||
- [[Linux运维必会的150个命令]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 相关命令如 ssh/scp/sftp 是运维必备命令）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "Ubuntu服务器通过rsync实现日常增量备份"
|
||||
type: source
|
||||
tags: [backup, nas, rsync, ubuntu]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 rsync 在 Ubuntu Server 上实现自动化增量备份，将 Docker 数据和配置文件同步到 NAS 存储
|
||||
- 问题域：工作室级数据保护体系建设——在已完成 Clonezilla 全盘镜像备份的基础上，通过 rsync 实现不关机的日常增量同步
|
||||
- 方法/机制：
|
||||
- rsync 增量同步（仅传输变化文件）+ Crontab 凌晨自动执行
|
||||
- NFS 永久挂载通过 `/etc/fstab` 配置，配合 `_netdev` 参数确保网络就绪后再挂载
|
||||
- 备份脚本内置锁文件机制（防止并发运行）、挂载点检查（防止写入本地磁盘）
|
||||
- Docker 卷备份（直接同步 `/var/lib/docker/volumes`）+ 数据库一致性建议（mysqldump 优先）
|
||||
- 结论/价值：形成"全盘镜像（Clonezilla）+ 日常增量（rsync）"双层数据保护体系，兼顾灾难恢复与实时数据安全
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- rsync 可以在不关机的情况下运行，且只传输变化过的文件，适合作为日常增量备份工具
|
||||
- NFS 永久挂载必须写入 `/etc/fstab`，并使用 `_netdev` 参数防止开机时因网络未就绪而卡死
|
||||
- 备份脚本若不加挂载点检查，NAS 掉线时 rsync 会将数据写入本地挂载点目录，导致硬盘迅速爆满
|
||||
- Docker 卷（Volumes）默认存储路径为 `/var/lib/docker/volumes`，是备份的核心数据
|
||||
- 数据库类容器（MySQL）备份应先用 `mysqldump` 导出 SQL 文件再 rsync，避免二进制文件损坏
|
||||
- rsync 返回码 23 或 24 表示部分文件因权限或消失未传输，这在运行中的系统上属于正常情况
|
||||
- 使用 `killall`（SIGTERM）优雅停止 rsync 比 `kill -9`（SIGKILL）更安全，可防止临时文件残留
|
||||
|
||||
## Key Quotes
|
||||
> "不要直接在命令行输入长命令，建议创建一个专门的脚本。" — 备份脚本管理最佳实践
|
||||
> "`_netdev`：告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死。" — /etc/fstab NFS 挂载参数说明
|
||||
> "rsync 返回 23 表示部分文件由于权限或消失未传输，这在备份正在运行的系统时常见。" — 错误码处理说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Rsync-Incremental-Backup]]：rsync 通过其 delta-transfer 算法，只发送源文件和目标文件之间的差异部分，实现高效的增量备份；常用参数 `-azR --delete`（归档、压缩、保持相对路径、删除目标端多余文件）
|
||||
- [[NFS-Permanent-Mount]]：NFS 挂载通过 `/etc/fstab` 实现永久化，关键参数包括 `timeo=900`（90秒超时）、`retrans=5`（5次重试）、`_netdev`（等待网络就绪）；测试前必须用 `sudo mount -a` 验证，禁止直接重启
|
||||
- [[Docker-Volume-Backup]]：Docker 卷默认存储在 `/var/lib/docker/volumes`，备份时对数据库容器应先用 `docker exec <容器> mysqldump` 导出再做 rsync，避免二进制文件损坏
|
||||
- [[Fstab]]：Linux 文件系统表（/etc/fstab），用于定义开机自动挂载的设备和参数；修改后必须用 `mount -a` 测试，禁止直接重启
|
||||
- [[Backup-Strategy]]：双层备份体系——Clonezilla 全盘镜像（应对硬盘彻底损坏）+ rsync 增量备份（应对日常文件丢失）
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：用于整机镜像备份的工具，与 rsync 形成互补（全量 vs 增量）
|
||||
- [[Synology-NAS]]：NAS 存储设备，提供 NFS 共享作为 rsync 备份目标
|
||||
- [[Ubuntu-Server]]：运行 rsync 备份脚本的操作系统环境
|
||||
- [[Docker]]：容器化平台，其 volumes 和配置文件是备份的核心数据
|
||||
- [[NFS]]：网络文件系统协议，用于 Ubuntu Server 挂载 Synology NAS 共享目录
|
||||
|
||||
## Connections
|
||||
- [[Clonezilla对Ubuntu Server进行全盘镜像备份]] ← backup_strategy ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]] ← foundation ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Docker]] ← backup_target ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Synology-NAS]] ← backup_destination ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "Ubuntu服务器通过rsync实现日常增量备份"
|
||||
type: source
|
||||
tags: [backup, nas, rsync, ubuntu]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 rsync 在 Ubuntu Server 上实现自动化增量备份，将 Docker 数据和配置文件同步到 NAS 存储
|
||||
- 问题域：工作室级数据保护体系建设——在已完成 Clonezilla 全盘镜像备份的基础上，通过 rsync 实现不关机的日常增量同步
|
||||
- 方法/机制：
|
||||
- rsync 增量同步（仅传输变化文件）+ Crontab 凌晨自动执行
|
||||
- NFS 永久挂载通过 `/etc/fstab` 配置，配合 `_netdev` 参数确保网络就绪后再挂载
|
||||
- 备份脚本内置锁文件机制（防止并发运行）、挂载点检查（防止写入本地磁盘）
|
||||
- Docker 卷备份（直接同步 `/var/lib/docker/volumes`）+ 数据库一致性建议（mysqldump 优先）
|
||||
- 结论/价值：形成"全盘镜像（Clonezilla）+ 日常增量（rsync）"双层数据保护体系，兼顾灾难恢复与实时数据安全
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- rsync 可以在不关机的情况下运行，且只传输变化过的文件，适合作为日常增量备份工具
|
||||
- NFS 永久挂载必须写入 `/etc/fstab`，并使用 `_netdev` 参数防止开机时因网络未就绪而卡死
|
||||
- 备份脚本若不加挂载点检查，NAS 掉线时 rsync 会将数据写入本地挂载点目录，导致硬盘迅速爆满
|
||||
- Docker 卷（Volumes）默认存储路径为 `/var/lib/docker/volumes`，是备份的核心数据
|
||||
- 数据库类容器（MySQL）备份应先用 `mysqldump` 导出 SQL 文件再 rsync，避免二进制文件损坏
|
||||
- rsync 返回码 23 或 24 表示部分文件因权限或消失未传输，这在运行中的系统上属于正常情况
|
||||
- 使用 `killall`（SIGTERM）优雅停止 rsync 比 `kill -9`（SIGKILL）更安全，可防止临时文件残留
|
||||
|
||||
## Key Quotes
|
||||
> "不要直接在命令行输入长命令，建议创建一个专门的脚本。" — 备份脚本管理最佳实践
|
||||
> "`_netdev`：告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死。" — /etc/fstab NFS 挂载参数说明
|
||||
> "rsync 返回 23 表示部分文件由于权限或消失未传输，这在备份正在运行的系统时常见。" — 错误码处理说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Rsync-Incremental-Backup]]：rsync 通过其 delta-transfer 算法，只发送源文件和目标文件之间的差异部分，实现高效的增量备份；常用参数 `-azR --delete`（归档、压缩、保持相对路径、删除目标端多余文件）
|
||||
- [[NFS-Permanent-Mount]]：NFS 挂载通过 `/etc/fstab` 实现永久化，关键参数包括 `timeo=900`（90秒超时）、`retrans=5`（5次重试）、`_netdev`（等待网络就绪）；测试前必须用 `sudo mount -a` 验证，禁止直接重启
|
||||
- [[Docker-Volume-Backup]]：Docker 卷默认存储在 `/var/lib/docker/volumes`，备份时对数据库容器应先用 `docker exec <容器> mysqldump` 导出再做 rsync，避免二进制文件损坏
|
||||
- [[Fstab]]：Linux 文件系统表（/etc/fstab），用于定义开机自动挂载的设备和参数；修改后必须用 `mount -a` 测试，禁止直接重启
|
||||
- [[Backup-Strategy]]：双层备份体系——Clonezilla 全盘镜像（应对硬盘彻底损坏）+ rsync 增量备份（应对日常文件丢失）
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：用于整机镜像备份的工具，与 rsync 形成互补（全量 vs 增量）
|
||||
- [[Synology-NAS]]：NAS 存储设备，提供 NFS 共享作为 rsync 备份目标
|
||||
- [[Ubuntu-Server]]：运行 rsync 备份脚本的操作系统环境
|
||||
- [[Docker]]：容器化平台，其 volumes 和配置文件是备份的核心数据
|
||||
- [[NFS]]：网络文件系统协议，用于 Ubuntu Server 挂载 Synology NAS 共享目录
|
||||
|
||||
## Connections
|
||||
- [[Clonezilla对Ubuntu Server进行全盘镜像备份]] ← backup_strategy ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]] ← foundation ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Docker]] ← backup_target ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Synology-NAS]] ← backup_destination ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,45 +1,45 @@
|
||||
---
|
||||
title: "Ubuntu禁用合盖休眠"
|
||||
type: source
|
||||
tags: [ubuntu, systemd, 服务器配置]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Ubuntu禁用合盖休眠]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu 24.04 笔记本合盖休眠行为配置
|
||||
- 问题域：服务器场景下笔记本合盖后不应进入休眠状态
|
||||
- 方法/机制：通过修改 `systemd-logind` 的 `logind.conf` 配置文件，将 `HandleLidSwitch` 系列参数设为 `ignore`；进阶方法通过 `systemctl mask` 彻底禁用所有休眠目标
|
||||
- 结论/价值：提供两步完成服务器场景下笔记本合盖持续运行的生产级方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- systemd-logind 是 Ubuntu 24.04 控制笔记本合盖行为的登录管理器
|
||||
- 通过 `HandleLidSwitch`、`HandleLidSwitchExternalPower`、`HandleLidSwitchDocked` 三个配置项可覆盖不同场景
|
||||
- 将配置值设为 `ignore` 后系统合盖不执行任何操作，继续运行
|
||||
- 修改配置后需执行 `systemctl restart systemd-logind` 重启服务才能生效
|
||||
- 可通过 `systemctl mask` 从内核级别彻底禁止待机（sleep/suspend/hibernate/hybrid-sleep）
|
||||
- `mask` 与 `unmask` 可逆，恢复时将 mask 改为 unmask 即可
|
||||
|
||||
## Key Quotes
|
||||
> "在执行此命令时，你的当前会话（包括图形界面或当前的 SSH 连接）可能会短暂断开或重新加载。" — 重启 systemd-logind 服务的注意事项
|
||||
|
||||
## Key Concepts
|
||||
- [[systemd-logind]]：Linux 系统登录管理器，负责管理用户会话、电源管理和设备访问权限，合盖行为由其控制
|
||||
- [[HandleLidSwitch]]：systemd-logind 配置项，定义笔记本合盖时的电源行为
|
||||
- [[sleep.target suspend.target hibernate.target hybrid-sleep.target]]：Linux 休眠相关系统目标，通过 `systemctl mask` 可从内核级别彻底禁用
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu 24.04]]：Canonical 发布的长期支持版 Ubuntu，本配置方法的适用系统
|
||||
- [[systemd]]：Linux 系统和服务管理器，systemd-logind 为其组件之一
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu禁用合盖休眠]] ← relates_to ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Ubuntu禁用合盖休眠]] ← related_topic ← [[Mac Mini 服务器配置：防止自动锁屏与睡眠]]（不同 OS，方法不同，无冲突）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Mac Mini 服务器配置：防止自动锁屏与睡眠]] 无冲突：
|
||||
- 冲突点：无（macOS 使用 `pmset` 命令，与 Ubuntu systemd 配置完全不同）
|
||||
- 当前观点：Ubuntu 通过 systemd-logind 配置
|
||||
- 对方观点：macOS 通过 pmset 命令配置
|
||||
---
|
||||
title: "Ubuntu禁用合盖休眠"
|
||||
type: source
|
||||
tags: [ubuntu, systemd, 服务器配置]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Ubuntu禁用合盖休眠]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu 24.04 笔记本合盖休眠行为配置
|
||||
- 问题域：服务器场景下笔记本合盖后不应进入休眠状态
|
||||
- 方法/机制：通过修改 `systemd-logind` 的 `logind.conf` 配置文件，将 `HandleLidSwitch` 系列参数设为 `ignore`；进阶方法通过 `systemctl mask` 彻底禁用所有休眠目标
|
||||
- 结论/价值：提供两步完成服务器场景下笔记本合盖持续运行的生产级方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- systemd-logind 是 Ubuntu 24.04 控制笔记本合盖行为的登录管理器
|
||||
- 通过 `HandleLidSwitch`、`HandleLidSwitchExternalPower`、`HandleLidSwitchDocked` 三个配置项可覆盖不同场景
|
||||
- 将配置值设为 `ignore` 后系统合盖不执行任何操作，继续运行
|
||||
- 修改配置后需执行 `systemctl restart systemd-logind` 重启服务才能生效
|
||||
- 可通过 `systemctl mask` 从内核级别彻底禁止待机（sleep/suspend/hibernate/hybrid-sleep）
|
||||
- `mask` 与 `unmask` 可逆，恢复时将 mask 改为 unmask 即可
|
||||
|
||||
## Key Quotes
|
||||
> "在执行此命令时，你的当前会话（包括图形界面或当前的 SSH 连接）可能会短暂断开或重新加载。" — 重启 systemd-logind 服务的注意事项
|
||||
|
||||
## Key Concepts
|
||||
- [[systemd-logind]]：Linux 系统登录管理器，负责管理用户会话、电源管理和设备访问权限，合盖行为由其控制
|
||||
- [[HandleLidSwitch]]：systemd-logind 配置项，定义笔记本合盖时的电源行为
|
||||
- [[sleep.target suspend.target hibernate.target hybrid-sleep.target]]：Linux 休眠相关系统目标，通过 `systemctl mask` 可从内核级别彻底禁用
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu 24.04]]：Canonical 发布的长期支持版 Ubuntu，本配置方法的适用系统
|
||||
- [[systemd]]：Linux 系统和服务管理器，systemd-logind 为其组件之一
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu禁用合盖休眠]] ← relates_to ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Ubuntu禁用合盖休眠]] ← related_topic ← [[Mac Mini 服务器配置：防止自动锁屏与睡眠]]（不同 OS，方法不同，无冲突）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Mac Mini 服务器配置：防止自动锁屏与睡眠]] 无冲突：
|
||||
- 冲突点：无（macOS 使用 `pmset` 命令，与 Ubuntu systemd 配置完全不同）
|
||||
- 当前观点：Ubuntu 通过 systemd-logind 配置
|
||||
- 对方观点：macOS 通过 pmset 命令配置
|
||||
|
||||
@@ -1,57 +1,57 @@
|
||||
---
|
||||
title: "Vibe Coding 经验收集"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/vibe coding经验收集.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Vibe Coding 实战经验与最佳实践的精选合集
|
||||
- 问题域：AI 辅助编程的工作流优化、代码质量保证、多 AI 协作模式、文档与导航化工具
|
||||
- 方法/机制：设计文档→伪代码→代码的递进式开发、多 AI 协作验证、文件注释标准化、代码可导航化
|
||||
- 结论/价值：Vibe Coding 已从单纯提示词工程演变为系统性工程实践，强调验证而非理解、文档优于记忆
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **递进式开发工作流**：设计文档写细（含伪代码）→ AI 直出代码 → 另一 AI review → 跑测试用例 → AI 自动 commit+push，可一遍直出
|
||||
- **System Prompt 优化效果**：针对 Gemini 3 Pro 的系统 prompt 优化可使多代理基准测试性能提升约 5%
|
||||
- **点线体迭代方法**：逐级迭代（点→线→体），先用单个基础任务打磨，再基于此批量执行
|
||||
- **文件头注释规范**：一段话描述代码作用、上下游链路，降低认知负载，参考 Claude skill 格式
|
||||
- **代码验证优先**：未来软件工程核心不是"看懂代码"而是"验证代码按正确逻辑运行"，依赖自动化测试、静态分析、形式化验证
|
||||
- **激励式提示词**：如"如果第一次就做得好，我会打赏100美元"可提升生成效果
|
||||
- **CodeWeaver 工具**：将代码库编织成可导航的 Markdown 文档，简化 AI/ML 工具集成
|
||||
|
||||
## Key Quotes
|
||||
> "我是把设计文档写得很细，包括service层的具体逻辑都用伪代码写了，然后交给AI，一遍直出，再用另一个AI review一遍，根据review意见修改一下，跑一下测试用例，让AI自己生成commit后push" — 需求→伪代码→代码递进工作流
|
||||
|
||||
> "代码最终会被转换成机器码执行，高级语言只是一层方便人类理解的抽象，重要的是验证程序的执行逻辑" — 代码验证哲学
|
||||
|
||||
> "请你根据我的要求，用 Three.js 创建一个实时交互的3D粒子系统，如果你第一次就做得好，我将会打赏你100美元的小费" — 激励式提示词示例
|
||||
|
||||
> "CodeWeaver 将你的代码库编织成一个可导航的 Markdown 文档……所有代码都给你塞进代码块里，极大地简化了代码库的共享、文档化以及与 AI/ML 工具集成" — CodeWeaver 工具价值
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：使用 AI 辅助编程的实践方法论，强调人机协作而非纯自动生成
|
||||
- [[Design-to-Code Workflow]]：设计文档→伪代码→代码的递进式开发流程
|
||||
- [[Multi-AI Review]]：多 AI 协作验证，一个生成一个 review 的双人编程模式
|
||||
- [[Code Documentation]]：文件头注释规范，降低 AI 和人类认知负载
|
||||
- [[Verification-First Engineering]]：验证优先于理解，强调自动化测试和形式化验证
|
||||
- [[Iterative Scaling]]：点→线→体的逐级迭代，从单任务打磨到批量执行
|
||||
- [[CodeWeaver]]：将代码库转换为可导航 Markdown 文档的工具
|
||||
|
||||
## Key Entities
|
||||
- [[CodeWeaver]]：GitHub 开源项目，将代码库编织成可导航 Markdown 文档的工具
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← extends ← [[Agentic AI]]
|
||||
- [[Design-to-Code Workflow]] ← refines ← [[Vibe Coding]]
|
||||
- [[Multi-AI Review]] ← part_of ← [[Design-to-Code Workflow]]
|
||||
- [[CodeWeaver]] ← enables ← [[Vibe Coding]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统软件工程方法冲突：
|
||||
- 冲突点：传统方法强调"先理解代码再修改"，Vibe Coding 强调"验证而非理解"
|
||||
- 当前观点：通过自动化测试和验证确保行为正确，降低人类理解代码的必要性
|
||||
- 对方观点：人类开发者必须理解代码才能安全地进行修改和重构
|
||||
---
|
||||
title: "Vibe Coding 经验收集"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/vibe coding经验收集.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Vibe Coding 实战经验与最佳实践的精选合集
|
||||
- 问题域：AI 辅助编程的工作流优化、代码质量保证、多 AI 协作模式、文档与导航化工具
|
||||
- 方法/机制：设计文档→伪代码→代码的递进式开发、多 AI 协作验证、文件注释标准化、代码可导航化
|
||||
- 结论/价值：Vibe Coding 已从单纯提示词工程演变为系统性工程实践，强调验证而非理解、文档优于记忆
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **递进式开发工作流**：设计文档写细（含伪代码）→ AI 直出代码 → 另一 AI review → 跑测试用例 → AI 自动 commit+push，可一遍直出
|
||||
- **System Prompt 优化效果**：针对 Gemini 3 Pro 的系统 prompt 优化可使多代理基准测试性能提升约 5%
|
||||
- **点线体迭代方法**：逐级迭代（点→线→体），先用单个基础任务打磨，再基于此批量执行
|
||||
- **文件头注释规范**：一段话描述代码作用、上下游链路，降低认知负载，参考 Claude skill 格式
|
||||
- **代码验证优先**：未来软件工程核心不是"看懂代码"而是"验证代码按正确逻辑运行"，依赖自动化测试、静态分析、形式化验证
|
||||
- **激励式提示词**：如"如果第一次就做得好，我会打赏100美元"可提升生成效果
|
||||
- **CodeWeaver 工具**：将代码库编织成可导航的 Markdown 文档，简化 AI/ML 工具集成
|
||||
|
||||
## Key Quotes
|
||||
> "我是把设计文档写得很细，包括service层的具体逻辑都用伪代码写了，然后交给AI，一遍直出，再用另一个AI review一遍，根据review意见修改一下，跑一下测试用例，让AI自己生成commit后push" — 需求→伪代码→代码递进工作流
|
||||
|
||||
> "代码最终会被转换成机器码执行，高级语言只是一层方便人类理解的抽象，重要的是验证程序的执行逻辑" — 代码验证哲学
|
||||
|
||||
> "请你根据我的要求，用 Three.js 创建一个实时交互的3D粒子系统，如果你第一次就做得好，我将会打赏你100美元的小费" — 激励式提示词示例
|
||||
|
||||
> "CodeWeaver 将你的代码库编织成一个可导航的 Markdown 文档……所有代码都给你塞进代码块里，极大地简化了代码库的共享、文档化以及与 AI/ML 工具集成" — CodeWeaver 工具价值
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：使用 AI 辅助编程的实践方法论，强调人机协作而非纯自动生成
|
||||
- [[Design-to-Code Workflow]]：设计文档→伪代码→代码的递进式开发流程
|
||||
- [[Multi-AI Review]]：多 AI 协作验证，一个生成一个 review 的双人编程模式
|
||||
- [[Code Documentation]]：文件头注释规范，降低 AI 和人类认知负载
|
||||
- [[Verification-First Engineering]]：验证优先于理解，强调自动化测试和形式化验证
|
||||
- [[Iterative Scaling]]：点→线→体的逐级迭代，从单任务打磨到批量执行
|
||||
- [[CodeWeaver]]：将代码库转换为可导航 Markdown 文档的工具
|
||||
|
||||
## Key Entities
|
||||
- [[CodeWeaver]]：GitHub 开源项目，将代码库编织成可导航 Markdown 文档的工具
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← extends ← [[Agentic AI]]
|
||||
- [[Design-to-Code Workflow]] ← refines ← [[Vibe Coding]]
|
||||
- [[Multi-AI Review]] ← part_of ← [[Design-to-Code Workflow]]
|
||||
- [[CodeWeaver]] ← enables ← [[Vibe Coding]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统软件工程方法冲突：
|
||||
- 冲突点：传统方法强调"先理解代码再修改"，Vibe Coding 强调"验证而非理解"
|
||||
- 当前观点：通过自动化测试和验证确保行为正确，降低人类理解代码的必要性
|
||||
- 对方观点：人类开发者必须理解代码才能安全地进行修改和重构
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: "Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南"
|
||||
type: source
|
||||
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Ubuntu Server 上非 root 用户（shenwei）安装 Node 20、Vibe-Kanban、OpenCode，并通过 pm2 进程管理，实现 AI 辅助编程工作流
|
||||
- 问题域：Ubuntu Server 环境下的 AI Coding Agent 部署与长期运维
|
||||
- 方法/机制：使用 nvm 管理 Node 版本、npm/npx 安装工具、pm2 管理进程生命周期、权限配置确保非 root 用户正常运行
|
||||
- 结论/价值：完整记录了从零开始在 Ubuntu Server 上搭建 Vibe Coding 环境的全流程，含验证步骤和故障排查要点
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 使用 nvm 安装 Node 20 可确保版本兼容性和环境隔离
|
||||
- pm2 能可靠管理 Vibe-Kanban 和 OpenCode Executor 进程并支持开机自启
|
||||
- 权限配置（/var/tmp/vibe-kanban 和 ~/.vibe-kanban 归属 shenwei）是避免 I/O error 的关键
|
||||
- 不应以 root 用户启动 OpenCode serve，避免权限问题
|
||||
- Vibe-Kanban 会自动 spawn OpenCode executor（随机端口），无需手动固定端口
|
||||
|
||||
## Key Quotes
|
||||
> "不要用 root 启动 OpenCode serve，vibe-kanban 会自动 spawn executor" — 核心安全与架构原则
|
||||
> "遇到 I/O error 时，通常是 executor 没启动或端口被占用" — 常见故障排查方向
|
||||
> "pm2 只管理 vibe-kanban，executor 随进程一起管理" — 进程管理边界定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：使用自然语言与 AI 编程工具协作的开发方式，Vibe-Kanban + OpenCode 是其代表性工具栈
|
||||
- [[nvm]]（Node Version Manager）：Node.js 版本管理工具，通过 $NVM_DIR/$HOME/.nvm 安装，支持多版本共存和快速切换
|
||||
- [[pm2]]：Node.js 进程管理器，支持进程守护、负载均衡、日志管理和开机自启（systemd）
|
||||
- [[Node 20]]：LTS 版 Node.js，Vibe-Kanban 和 OpenCode 的推荐运行时版本
|
||||
|
||||
## Key Entities
|
||||
- [[Vibe-Kanban]]：AI 编程辅助工具，提供看板界面与 OpenCode executor 集成，通过 npx vibe-kanban 启动
|
||||
- [[OpenCode]]：开源 AI Coding CLI agent，与 Vibe-Kanban 配合使用，npm install -g opencode-ai 安装
|
||||
- [[shenwei]]：文档作者，非 root 普通用户，用于在 Ubuntu Server 上运行 Vibe-Kanban 和 OpenCode
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] ← extends ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
|
||||
- [[Vibe Coding 经验收集]] ← related_to ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
|
||||
- [[OpenCode]] ← depends_on ← [[Node 20]]
|
||||
- [[Vibe-Kanban]] ← depends_on ← [[OpenCode]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
|
||||
- 冲突点：两篇文档都介绍 Ubuntu 上安装 OpenCode 和 Vibe-Kanban
|
||||
- 当前观点：本篇更详细，覆盖完整 6 步流程、pm2 进程管理、权限配置和验证步骤
|
||||
- 对方观点：前篇侧重基础安装步骤
|
||||
---
|
||||
title: "Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南"
|
||||
type: source
|
||||
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Ubuntu Server 上非 root 用户（shenwei）安装 Node 20、Vibe-Kanban、OpenCode，并通过 pm2 进程管理，实现 AI 辅助编程工作流
|
||||
- 问题域：Ubuntu Server 环境下的 AI Coding Agent 部署与长期运维
|
||||
- 方法/机制：使用 nvm 管理 Node 版本、npm/npx 安装工具、pm2 管理进程生命周期、权限配置确保非 root 用户正常运行
|
||||
- 结论/价值：完整记录了从零开始在 Ubuntu Server 上搭建 Vibe Coding 环境的全流程，含验证步骤和故障排查要点
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 使用 nvm 安装 Node 20 可确保版本兼容性和环境隔离
|
||||
- pm2 能可靠管理 Vibe-Kanban 和 OpenCode Executor 进程并支持开机自启
|
||||
- 权限配置（/var/tmp/vibe-kanban 和 ~/.vibe-kanban 归属 shenwei）是避免 I/O error 的关键
|
||||
- 不应以 root 用户启动 OpenCode serve，避免权限问题
|
||||
- Vibe-Kanban 会自动 spawn OpenCode executor（随机端口），无需手动固定端口
|
||||
|
||||
## Key Quotes
|
||||
> "不要用 root 启动 OpenCode serve，vibe-kanban 会自动 spawn executor" — 核心安全与架构原则
|
||||
> "遇到 I/O error 时，通常是 executor 没启动或端口被占用" — 常见故障排查方向
|
||||
> "pm2 只管理 vibe-kanban，executor 随进程一起管理" — 进程管理边界定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：使用自然语言与 AI 编程工具协作的开发方式，Vibe-Kanban + OpenCode 是其代表性工具栈
|
||||
- [[nvm]]（Node Version Manager）：Node.js 版本管理工具，通过 $NVM_DIR/$HOME/.nvm 安装，支持多版本共存和快速切换
|
||||
- [[pm2]]：Node.js 进程管理器，支持进程守护、负载均衡、日志管理和开机自启（systemd）
|
||||
- [[Node 20]]：LTS 版 Node.js，Vibe-Kanban 和 OpenCode 的推荐运行时版本
|
||||
|
||||
## Key Entities
|
||||
- [[Vibe-Kanban]]：AI 编程辅助工具，提供看板界面与 OpenCode executor 集成，通过 npx vibe-kanban 启动
|
||||
- [[OpenCode]]：开源 AI Coding CLI agent，与 Vibe-Kanban 配合使用，npm install -g opencode-ai 安装
|
||||
- [[shenwei]]：文档作者，非 root 普通用户，用于在 Ubuntu Server 上运行 Vibe-Kanban 和 OpenCode
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] ← extends ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
|
||||
- [[Vibe Coding 经验收集]] ← related_to ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
|
||||
- [[OpenCode]] ← depends_on ← [[Node 20]]
|
||||
- [[Vibe-Kanban]] ← depends_on ← [[OpenCode]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
|
||||
- 冲突点：两篇文档都介绍 Ubuntu 上安装 OpenCode 和 Vibe-Kanban
|
||||
- 当前观点：本篇更详细，覆盖完整 6 步流程、pm2 进程管理、权限配置和验证步骤
|
||||
- 对方观点：前篇侧重基础安装步骤
|
||||
|
||||
@@ -1,66 +1,66 @@
|
||||
---
|
||||
title: "What I Know About Cloud Service Delivery 1"
|
||||
type: source
|
||||
tags: []
|
||||
date:
|
||||
author: shenwei
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/What I know about Cloud Service Delivery 1]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：云服务交付（Cloud Service Delivery）的完整生命周期管理框架，涵盖从基础设施到客户支持的 12 大领域
|
||||
- **问题域**：如何将云技术（IaaS/PaaS/SaaS）的能力可靠、安全、高性能且成本有效地传递给最终用户
|
||||
- **方法/机制**：由多角色 Cloud Service Delivery Team 驱动，通过 IaC、监控、合规、成本优化等手段实现端到端管理
|
||||
- **结论/价值**：云服务交付是连接云技术能力与企业/用户实际需求之间的桥梁，需要多学科协作和持续运营
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Cloud Service Delivery Team（多角色团队）→ 通过专业分工 → 实现完整的云服务生命周期管理
|
||||
- Service Provisioning & Deployment → 自动化部署 + 资源配置和扩缩容 → 提高部署效率、加快交付速度
|
||||
- Infrastructure Management → 监控 + 补丁更新 + 高可用设置 → 确保底层基础设施稳定运行
|
||||
- Platform Management（PaaS）→ 中间件、数据库、开发工具和运行时管理 → 保证平台可扩展、安全、高性能
|
||||
- Application Operations & Management → 应用性能监控 + 持续部署 + 配置和密钥管理 → 确保应用弹性和可扩展性
|
||||
- Security & Compliance Management → 防火墙、IDS/IPS、加密、IAM 合规审计 → 保障云环境安全和合规
|
||||
- Performance & Availability Monitoring → 24/7 全栈监控 + SLA/SLO 管理 + 主动检测 → 确保服务高可用和性能达标
|
||||
- Incident & Problem Management → 快速响应 + 全栈故障排除 + 根因分析 → 最小化服务中断时间和影响
|
||||
- Change & Configuration Management → IaC + 变更控制 + 测试和回滚 → 降低变更风险、保证环境一致性
|
||||
- Cost Management & Optimization → 消费监控 + 消除浪费 + 合理选型（Savings Plans）→ 降低云支出、提升 ROI
|
||||
- Customer Onboarding & Support → 用户引导 + 文档培训 + 服务台运营 → 提升用户体验和满意度
|
||||
- Backup, Recovery & Disaster Management → 备份策略 + 恢复测试 + DR 演练 → 确保业务连续性和数据安全
|
||||
|
||||
## Key Quotes
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud Service Delivery]]：将云技术（IaaS/PaaS/SaaS）能力可靠、安全、高性能且成本有效地传递给最终用户的完整生命周期管理
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施配置，确保一致性和可重复性（Change & Configuration Management）
|
||||
- [[Service Level Agreement (SLA)]]：服务等级协议，定义服务的可用性目标（如 99.9% vs 99.99%）
|
||||
- [[Service Level Objective (SLO)]]：服务等级目标，SLA 分解到具体服务的具体指标
|
||||
- [[FinOps]]：云财务管理，通过监控消费、消除浪费、合理选型来优化云成本
|
||||
- [[Incident Management]]：事件管理，快速响应和恢复服务中断
|
||||
- [[Problem Management]]：问题管理，识别根因并实施永久性修复
|
||||
- [[Disaster Recovery (DR)]]：灾难恢复，确保业务连续性的备份和故障切换机制
|
||||
- [[Cloud DevOps Maturity Model]]：云 DevOps 成熟度模型（本文件末尾提及，待扩展）
|
||||
- [[AIOps]]：人工智能运维（本文件末尾提及，待扩展）
|
||||
|
||||
## Key Entities
|
||||
- **AWS CloudWatch**：AWS 原生监控数据源，可接入 Grafana 实现统一可观测性
|
||||
- **Grafana**：监控可视化平台，支持 AWS CloudWatch 等多数据源
|
||||
- **New Relic**：APM/BPM 应用性能监控工具
|
||||
- **AWS CloudWatch Synthetic**：AWS 提供的服务可用性主动检测（Synthetic Monitoring）工具
|
||||
- **WAF (Web Application Firewall)**：云应用防火墙，管理云应用程序安全
|
||||
- **OpenText**：（作者所在组织）企业级云服务提供商
|
||||
|
||||
## Connections
|
||||
- [[Cloud Maturity Model - A Detailed Guide For Cloud Adoption]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]
|
||||
- [[DevOps Culture and Transformation]] ← extends ← [[What I Know About Cloud Service Delivery 1]]
|
||||
- [[Public Cloud Learning Sessions - Observability with OpenTelemetry]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（可观测性层面）
|
||||
- [[CTP Topic 8 - Implementation of Cloud Monitoring]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（监控实践）
|
||||
- [[Public Cloud Learning Sessions - Reducing Cloud Costs]] ← extends ← [[What I Know About Cloud Service Delivery 1]]（成本管理）
|
||||
- [[Public Cloud Learning Sessions - EKS Optimization]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（平台管理）
|
||||
- [[CTP Topic 73 AWS Backup Implementation]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（备份与灾难恢复）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Maturity Model From Traditional IT to Advanced DevOps]] 潜在交叉：两者均涉及 DevOps 文化成熟度，但本文更侧重运营层面，后者侧重文化转型；暂无实质性冲突
|
||||
---
|
||||
title: "What I Know About Cloud Service Delivery 1"
|
||||
type: source
|
||||
tags: []
|
||||
date:
|
||||
author: shenwei
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/What I know about Cloud Service Delivery 1]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：云服务交付（Cloud Service Delivery）的完整生命周期管理框架，涵盖从基础设施到客户支持的 12 大领域
|
||||
- **问题域**：如何将云技术（IaaS/PaaS/SaaS）的能力可靠、安全、高性能且成本有效地传递给最终用户
|
||||
- **方法/机制**：由多角色 Cloud Service Delivery Team 驱动，通过 IaC、监控、合规、成本优化等手段实现端到端管理
|
||||
- **结论/价值**：云服务交付是连接云技术能力与企业/用户实际需求之间的桥梁，需要多学科协作和持续运营
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Cloud Service Delivery Team（多角色团队）→ 通过专业分工 → 实现完整的云服务生命周期管理
|
||||
- Service Provisioning & Deployment → 自动化部署 + 资源配置和扩缩容 → 提高部署效率、加快交付速度
|
||||
- Infrastructure Management → 监控 + 补丁更新 + 高可用设置 → 确保底层基础设施稳定运行
|
||||
- Platform Management（PaaS）→ 中间件、数据库、开发工具和运行时管理 → 保证平台可扩展、安全、高性能
|
||||
- Application Operations & Management → 应用性能监控 + 持续部署 + 配置和密钥管理 → 确保应用弹性和可扩展性
|
||||
- Security & Compliance Management → 防火墙、IDS/IPS、加密、IAM 合规审计 → 保障云环境安全和合规
|
||||
- Performance & Availability Monitoring → 24/7 全栈监控 + SLA/SLO 管理 + 主动检测 → 确保服务高可用和性能达标
|
||||
- Incident & Problem Management → 快速响应 + 全栈故障排除 + 根因分析 → 最小化服务中断时间和影响
|
||||
- Change & Configuration Management → IaC + 变更控制 + 测试和回滚 → 降低变更风险、保证环境一致性
|
||||
- Cost Management & Optimization → 消费监控 + 消除浪费 + 合理选型（Savings Plans）→ 降低云支出、提升 ROI
|
||||
- Customer Onboarding & Support → 用户引导 + 文档培训 + 服务台运营 → 提升用户体验和满意度
|
||||
- Backup, Recovery & Disaster Management → 备份策略 + 恢复测试 + DR 演练 → 确保业务连续性和数据安全
|
||||
|
||||
## Key Quotes
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud Service Delivery]]：将云技术（IaaS/PaaS/SaaS）能力可靠、安全、高性能且成本有效地传递给最终用户的完整生命周期管理
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施配置，确保一致性和可重复性（Change & Configuration Management）
|
||||
- [[Service Level Agreement (SLA)]]：服务等级协议，定义服务的可用性目标（如 99.9% vs 99.99%）
|
||||
- [[Service Level Objective (SLO)]]：服务等级目标，SLA 分解到具体服务的具体指标
|
||||
- [[FinOps]]：云财务管理，通过监控消费、消除浪费、合理选型来优化云成本
|
||||
- [[Incident Management]]：事件管理，快速响应和恢复服务中断
|
||||
- [[Problem Management]]：问题管理，识别根因并实施永久性修复
|
||||
- [[Disaster Recovery (DR)]]：灾难恢复，确保业务连续性的备份和故障切换机制
|
||||
- [[Cloud DevOps Maturity Model]]：云 DevOps 成熟度模型（本文件末尾提及，待扩展）
|
||||
- [[AIOps]]：人工智能运维（本文件末尾提及，待扩展）
|
||||
|
||||
## Key Entities
|
||||
- **AWS CloudWatch**：AWS 原生监控数据源，可接入 Grafana 实现统一可观测性
|
||||
- **Grafana**：监控可视化平台，支持 AWS CloudWatch 等多数据源
|
||||
- **New Relic**：APM/BPM 应用性能监控工具
|
||||
- **AWS CloudWatch Synthetic**：AWS 提供的服务可用性主动检测（Synthetic Monitoring）工具
|
||||
- **WAF (Web Application Firewall)**：云应用防火墙，管理云应用程序安全
|
||||
- **OpenText**：（作者所在组织）企业级云服务提供商
|
||||
|
||||
## Connections
|
||||
- [[Cloud Maturity Model - A Detailed Guide For Cloud Adoption]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]
|
||||
- [[DevOps Culture and Transformation]] ← extends ← [[What I Know About Cloud Service Delivery 1]]
|
||||
- [[Public Cloud Learning Sessions - Observability with OpenTelemetry]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（可观测性层面）
|
||||
- [[CTP Topic 8 - Implementation of Cloud Monitoring]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（监控实践）
|
||||
- [[Public Cloud Learning Sessions - Reducing Cloud Costs]] ← extends ← [[What I Know About Cloud Service Delivery 1]]（成本管理）
|
||||
- [[Public Cloud Learning Sessions - EKS Optimization]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（平台管理）
|
||||
- [[CTP Topic 73 AWS Backup Implementation]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（备份与灾难恢复）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Maturity Model From Traditional IT to Advanced DevOps]] 潜在交叉：两者均涉及 DevOps 文化成熟度，但本文更侧重运营层面，后者侧重文化转型；暂无实质性冲突
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "What is DevSecOps? Best Practices, Benefits, and Tools"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2023-10-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/What is DevSecOps Best Practices, Benefits, and Tools]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevSecOps 将安全实践深度嵌入软件开发生命周期（SDLC），实现"安全即代码"
|
||||
- 问题域：传统 DevOps 在后期才引入安全导致漏洞修复成本高、交付速度慢的问题
|
||||
- 方法/机制：通过 Shift Left（左移）和 Shift Right（右移）策略，在 CI/CD 流水线中集成 SAST/DAST/SCA/IAST 等自动化安全工具，培养"全员安全责任"文化
|
||||
- 结论/价值：DevSecOps 能将 70% 的上线后发现的安全漏洞提前预防，实现安全与速度的平衡
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 70% 的软件漏洞可在 DevSecOps 实践中被预防
|
||||
- 安全左移（Shift Left）使团队能在开发早期发现并修复安全问题，降低修复成本
|
||||
- 自动化安全测试集成到 CI/CD 流水线中，可在不减缓开发速度的前提下保障安全
|
||||
- DevSecOps 通过"break the build"机制，当安全风险过高时停止构建流程
|
||||
- SAST、DAST、SCA、IAST 四类安全工具分别覆盖代码编写、运行时、第三方依赖和交互测试等不同阶段
|
||||
|
||||
## Key Quotes
|
||||
> "DevSecOps is a working methodology that includes security checks throughout the software development process." — DevSecOps 核心定义
|
||||
|
||||
> "70% of software vulnerabilities discovered post-launch could have been prevented with DevSecOps" — DevSecOps 价值量化
|
||||
|
||||
> "Everyone in the organization developing software is liable for security." — 全员安全责任文化
|
||||
|
||||
> "Shift left means identifying security flaws early in the software development lifecycle." — 左移策略定义
|
||||
|
||||
## Key Concepts
|
||||
- [[DevSecOps]]：在 DevOps 中全程集成安全实践的工作方法论
|
||||
- [[Shift Left]]：在软件开发生命周期早期识别并修复安全缺陷的策略
|
||||
- [[Shift Right]]：在应用上线后持续进行安全监控和问题修复的策略
|
||||
- [[SAST]]：静态应用安全测试，在代码编写阶段分析源代码以发现漏洞
|
||||
- [[DAST]]：动态应用安全测试，模拟外部攻击从运行时发现漏洞
|
||||
- [[SCA]]：软件成分分析，扫描第三方依赖库和框架的已知安全漏洞
|
||||
- [[IAST]]：交互式应用安全测试，在应用运行时检测其他工具遗漏的漏洞
|
||||
- [[CI/CD 安全]]：在持续集成/持续交付流水线中自动化执行安全扫描
|
||||
- [[Break the Build]]：当安全风险超过阈值时自动停止构建流程的机制
|
||||
- [[Policy as Code]]：以代码形式定义和自动执行安全策略的方法
|
||||
|
||||
## Key Entities
|
||||
- [[OWASP Top Ten]]：Web 应用安全标准，DevSecOps 测试中的重要参考框架
|
||||
- [[AWS CodePipeline]]：AWS 的 CI/CD 工具，可集成安全扫描
|
||||
- [[Amazon Inspector]]：AWS 漏洞管理自动化工具
|
||||
- [[Amazon CodeGuru Reviewer]]：AWS 代码安全和最佳实践审查工具
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[DevSecOps]]（DevSecOps 是 DevOps 的安全扩展）
|
||||
- [[CI/CD 安全]] ← depends_on ← [[SAST]] / [[DAST]] / [[SCA]] / [[IAST]]
|
||||
- [[DevSecOps]] ← applies ← [[Shift Left]]
|
||||
- [[DevSecOps]] ← applies ← [[Shift Right]]
|
||||
- [[Agile Development]] ← integrates ← [[DevSecOps]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统瀑布式开发相比：
|
||||
- 冲突点：传统方式在 SDLC 末期才进行安全测试
|
||||
- 当前观点：DevSecOps 强调安全全程嵌入
|
||||
- 对方观点：安全专家在开发完成后再统一介入更专业
|
||||
---
|
||||
title: "What is DevSecOps? Best Practices, Benefits, and Tools"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2023-10-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/What is DevSecOps Best Practices, Benefits, and Tools]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevSecOps 将安全实践深度嵌入软件开发生命周期（SDLC），实现"安全即代码"
|
||||
- 问题域：传统 DevOps 在后期才引入安全导致漏洞修复成本高、交付速度慢的问题
|
||||
- 方法/机制：通过 Shift Left（左移）和 Shift Right（右移）策略，在 CI/CD 流水线中集成 SAST/DAST/SCA/IAST 等自动化安全工具，培养"全员安全责任"文化
|
||||
- 结论/价值：DevSecOps 能将 70% 的上线后发现的安全漏洞提前预防，实现安全与速度的平衡
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 70% 的软件漏洞可在 DevSecOps 实践中被预防
|
||||
- 安全左移（Shift Left）使团队能在开发早期发现并修复安全问题，降低修复成本
|
||||
- 自动化安全测试集成到 CI/CD 流水线中，可在不减缓开发速度的前提下保障安全
|
||||
- DevSecOps 通过"break the build"机制，当安全风险过高时停止构建流程
|
||||
- SAST、DAST、SCA、IAST 四类安全工具分别覆盖代码编写、运行时、第三方依赖和交互测试等不同阶段
|
||||
|
||||
## Key Quotes
|
||||
> "DevSecOps is a working methodology that includes security checks throughout the software development process." — DevSecOps 核心定义
|
||||
|
||||
> "70% of software vulnerabilities discovered post-launch could have been prevented with DevSecOps" — DevSecOps 价值量化
|
||||
|
||||
> "Everyone in the organization developing software is liable for security." — 全员安全责任文化
|
||||
|
||||
> "Shift left means identifying security flaws early in the software development lifecycle." — 左移策略定义
|
||||
|
||||
## Key Concepts
|
||||
- [[DevSecOps]]：在 DevOps 中全程集成安全实践的工作方法论
|
||||
- [[Shift Left]]：在软件开发生命周期早期识别并修复安全缺陷的策略
|
||||
- [[Shift Right]]：在应用上线后持续进行安全监控和问题修复的策略
|
||||
- [[SAST]]：静态应用安全测试，在代码编写阶段分析源代码以发现漏洞
|
||||
- [[DAST]]：动态应用安全测试，模拟外部攻击从运行时发现漏洞
|
||||
- [[SCA]]：软件成分分析，扫描第三方依赖库和框架的已知安全漏洞
|
||||
- [[IAST]]：交互式应用安全测试，在应用运行时检测其他工具遗漏的漏洞
|
||||
- [[CI/CD 安全]]：在持续集成/持续交付流水线中自动化执行安全扫描
|
||||
- [[Break the Build]]：当安全风险超过阈值时自动停止构建流程的机制
|
||||
- [[Policy as Code]]：以代码形式定义和自动执行安全策略的方法
|
||||
|
||||
## Key Entities
|
||||
- [[OWASP Top Ten]]：Web 应用安全标准，DevSecOps 测试中的重要参考框架
|
||||
- [[AWS CodePipeline]]：AWS 的 CI/CD 工具，可集成安全扫描
|
||||
- [[Amazon Inspector]]：AWS 漏洞管理自动化工具
|
||||
- [[Amazon CodeGuru Reviewer]]：AWS 代码安全和最佳实践审查工具
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[DevSecOps]]（DevSecOps 是 DevOps 的安全扩展）
|
||||
- [[CI/CD 安全]] ← depends_on ← [[SAST]] / [[DAST]] / [[SCA]] / [[IAST]]
|
||||
- [[DevSecOps]] ← applies ← [[Shift Left]]
|
||||
- [[DevSecOps]] ← applies ← [[Shift Right]]
|
||||
- [[Agile Development]] ← integrates ← [[DevSecOps]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统瀑布式开发相比：
|
||||
- 冲突点：传统方式在 SDLC 末期才进行安全测试
|
||||
- 当前观点：DevSecOps 强调安全全程嵌入
|
||||
- 对方观点：安全专家在开发完成后再统一介入更专业
|
||||
|
||||
@@ -1,46 +1,46 @@
|
||||
---
|
||||
title: "在Synology NAS上安装CloudDrive2"
|
||||
type: source
|
||||
tags: [clouddrive2, nas, synology, 阿里云盘]
|
||||
date: 2025-12-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Synology NAS上安装CloudDrive2.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Synology NAS（DSM 7+）上安装并配置 CloudDrive2，实现阿里云盘的本地挂载
|
||||
- 问题域：群晖 NAS 用户希望将阿里云盘像本地硬盘一样挂载使用，无需手动同步
|
||||
- 方法/机制：通过 Synology 社群（矿神源）安装 CloudDrive2 → 执行 root 权限修复命令（DSM 7+ 专用）→ Web UI 配置 → 阿里云盘 App 扫码授权 → 挂载 Aliyun 目录
|
||||
- 结论/价值：CloudDrive2 提供了在 NAS 上原生挂载云盘的能力，适合影视、文件等大体积内容管理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 主体 + 机制 + 结果
|
||||
- Synology 社群安装方式：矿神源 → 社群 → CloudDrive2（标准流程）
|
||||
- DSM 7+ 特殊处理：需执行 `sed` 命令修改 CloudDrive2 权限文件，将 `package` 替换为 `root`，否则因权限不足无法正常运行
|
||||
- Web UI 访问：通过 `http://192.168.3.17:19798/` 访问 CloudDrive2 配置界面
|
||||
- 阿里云盘授权：使用阿里云盘 App 扫码授权，仅授权「资源目录」（不要授权「备份目录」）
|
||||
|
||||
## Key Quotes
|
||||
> "因为我的 DSM 是 7+ 版本，所以需要额外在 root 下执行一条命令" — DSM 7+ 权限修复说明
|
||||
> "请主要，不要授权备份目录，仅资源目录即可" — 安全提示，避免备份文件被挂载
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudDrive2]]：云盘挂载工具，支持阿里云盘、百度网盘等多种云存储，可将云端文件像本地硬盘一样在 NAS 上使用
|
||||
- [[Synology NAS]]：群晖网络附加存储设备，运行 DSM 操作系统；通过社群套件源安装第三方应用
|
||||
- [[矿神源]]：Synology 社群第三方套件源，提供大量社群维护的应用（如 CloudDrive2）
|
||||
|
||||
## Key Entities
|
||||
- [[阿里云盘]]：阿里巴巴旗下云盘服务，CloudDrive2 支持挂载的云存储之一；通过 App 扫码授权连接
|
||||
- [[CloudDrive2]]：云盘挂载应用，可在 NAS/PC 上将云盘映射为本地文件系统（WebDAV/SMB 等协议）
|
||||
|
||||
## Connections
|
||||
- [[群晖NAS科学上网方法]] ← related ← [[在Synology NAS上安装CloudDrive2]]（同一设备上的网络配置需求）
|
||||
- [[用Docker安装Jellyfin]] ← related ← [[在Synology NAS上安装CloudDrive2]]（Jellyfin 可读取 CloudDrive2 挂载的阿里云盘影视资源）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]]
|
||||
- [[用Docker安装Jellyfin]]
|
||||
---
|
||||
title: "在Synology NAS上安装CloudDrive2"
|
||||
type: source
|
||||
tags: [clouddrive2, nas, synology, 阿里云盘]
|
||||
date: 2025-12-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Synology NAS上安装CloudDrive2.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Synology NAS（DSM 7+）上安装并配置 CloudDrive2，实现阿里云盘的本地挂载
|
||||
- 问题域：群晖 NAS 用户希望将阿里云盘像本地硬盘一样挂载使用，无需手动同步
|
||||
- 方法/机制：通过 Synology 社群（矿神源）安装 CloudDrive2 → 执行 root 权限修复命令（DSM 7+ 专用）→ Web UI 配置 → 阿里云盘 App 扫码授权 → 挂载 Aliyun 目录
|
||||
- 结论/价值：CloudDrive2 提供了在 NAS 上原生挂载云盘的能力，适合影视、文件等大体积内容管理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 主体 + 机制 + 结果
|
||||
- Synology 社群安装方式：矿神源 → 社群 → CloudDrive2（标准流程）
|
||||
- DSM 7+ 特殊处理：需执行 `sed` 命令修改 CloudDrive2 权限文件，将 `package` 替换为 `root`，否则因权限不足无法正常运行
|
||||
- Web UI 访问：通过 `http://192.168.3.17:19798/` 访问 CloudDrive2 配置界面
|
||||
- 阿里云盘授权：使用阿里云盘 App 扫码授权，仅授权「资源目录」（不要授权「备份目录」）
|
||||
|
||||
## Key Quotes
|
||||
> "因为我的 DSM 是 7+ 版本，所以需要额外在 root 下执行一条命令" — DSM 7+ 权限修复说明
|
||||
> "请主要，不要授权备份目录，仅资源目录即可" — 安全提示，避免备份文件被挂载
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudDrive2]]：云盘挂载工具，支持阿里云盘、百度网盘等多种云存储，可将云端文件像本地硬盘一样在 NAS 上使用
|
||||
- [[Synology NAS]]：群晖网络附加存储设备，运行 DSM 操作系统；通过社群套件源安装第三方应用
|
||||
- [[矿神源]]：Synology 社群第三方套件源，提供大量社群维护的应用（如 CloudDrive2）
|
||||
|
||||
## Key Entities
|
||||
- [[阿里云盘]]：阿里巴巴旗下云盘服务，CloudDrive2 支持挂载的云存储之一；通过 App 扫码授权连接
|
||||
- [[CloudDrive2]]：云盘挂载应用，可在 NAS/PC 上将云盘映射为本地文件系统（WebDAV/SMB 等协议）
|
||||
|
||||
## Connections
|
||||
- [[群晖NAS科学上网方法]] ← related ← [[在Synology NAS上安装CloudDrive2]]（同一设备上的网络配置需求）
|
||||
- [[用Docker安装Jellyfin]] ← related ← [[在Synology NAS上安装CloudDrive2]]（Jellyfin 可读取 CloudDrive2 挂载的阿里云盘影视资源）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]]
|
||||
- [[用Docker安装Jellyfin]]
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "在Ubuntu上安装Vibe-Kanban"
|
||||
type: source
|
||||
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
|
||||
date: 2026-06-04
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/在Ubuntu上安装Vibe-Kanban.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Ubuntu Server 上安装和配置 Vibe-Kanban AI 任务管理工具
|
||||
- 问题域：AI 辅助编程工作流、任务管理工具的服务器端部署
|
||||
- 方法/机制：通过 npx 直接运行 Vibe-Kanban，使用 PM2 进程管理器实现后台运行和开机自启
|
||||
- 结论/价值：提供完整的 Vibe-Kanban 安装指南，包括可选的 GitHub CLI 和 MCP 集成
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Vibe Kanban 默认以 `--dangerously-skip-permissions/--yolo` 标志运行 AI 代理，允许自主操作无需持续审批
|
||||
- 每个任务在隔离的 git worktree 中运行，防止代理之间相互干扰
|
||||
- 使用 `PORT=8080 npx vibe-kanban` 可指定固定端口
|
||||
- PM2 可以实现进程自动重启和开机自启，通过 `pm2 startup` 配置
|
||||
- 使用 `HOST=0.0.0.0 PORT=9999 npx vibe-kanban` 可实现局域网访问
|
||||
|
||||
## Key Quotes
|
||||
> "Vibe Kanban runs AI agents with —dangerously-skip-permissions/—yolo flags by default so they can work autonomously without constant approval prompts." — 安全机制说明
|
||||
> "Each task runs in an isolated git worktree, preventing agents from interfering with each other." — 隔离机制说明
|
||||
> "Vibe Kanban uses the GitHub CLI for creating pull requests. Ensure gh is installed and authenticated on your system." — GitHub 集成依赖
|
||||
|
||||
## Key Concepts
|
||||
- [[PM2]]：Node.js 进程管理器，提供进程守护、自动重启和开机自启功能
|
||||
- [[npx]]：Node.js 包执行工具，无需全局安装即可运行包
|
||||
- [[Vibe Coding]]：AI 辅助编程范式，通过自然语言描述让 AI 代理完成编码任务
|
||||
- [[MCP Server]]：Model Context Protocol 服务器，用于标准化 AI 代理与外部工具的集成
|
||||
|
||||
## Key Entities
|
||||
- [[Vibe-Kanban]]：BloopAI 出品的 AI 任务管理看板工具，支持多种编码代理
|
||||
- [[BloopAI]]：开发 Vibe-Kanban 的 AI 代码工具公司
|
||||
- [[Node.js]]：Vibe-Kanban 运行所需的 JavaScript 运行时环境
|
||||
- [[GitHub CLI]]：用于创建 Pull Request 的命令行工具，Vibe-Kanban 可选集成
|
||||
|
||||
## Connections
|
||||
- [[Vibe-Kanban]] ← depends_on ← [[Node.js]]
|
||||
- [[Vibe-Kanban]] ← extends ← [[GitHub CLI]]
|
||||
- [[Vibe-Kanban]] ← optional_integration ← [[MCP Server]]
|
||||
- [[PM2]] ← manages ← [[Vibe-Kanban]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
|
||||
- 冲突点：两者都介绍 Vibe-Kanban 安装，但侧重点不同
|
||||
- 当前观点：本文档侧重官方标准安装流程和 PM2 进程管理
|
||||
- 对方观点：[[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 侧重 OpenCode 集成配置
|
||||
---
|
||||
title: "在Ubuntu上安装Vibe-Kanban"
|
||||
type: source
|
||||
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
|
||||
date: 2026-06-04
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/在Ubuntu上安装Vibe-Kanban.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Ubuntu Server 上安装和配置 Vibe-Kanban AI 任务管理工具
|
||||
- 问题域：AI 辅助编程工作流、任务管理工具的服务器端部署
|
||||
- 方法/机制：通过 npx 直接运行 Vibe-Kanban，使用 PM2 进程管理器实现后台运行和开机自启
|
||||
- 结论/价值：提供完整的 Vibe-Kanban 安装指南，包括可选的 GitHub CLI 和 MCP 集成
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Vibe Kanban 默认以 `--dangerously-skip-permissions/--yolo` 标志运行 AI 代理，允许自主操作无需持续审批
|
||||
- 每个任务在隔离的 git worktree 中运行，防止代理之间相互干扰
|
||||
- 使用 `PORT=8080 npx vibe-kanban` 可指定固定端口
|
||||
- PM2 可以实现进程自动重启和开机自启，通过 `pm2 startup` 配置
|
||||
- 使用 `HOST=0.0.0.0 PORT=9999 npx vibe-kanban` 可实现局域网访问
|
||||
|
||||
## Key Quotes
|
||||
> "Vibe Kanban runs AI agents with —dangerously-skip-permissions/—yolo flags by default so they can work autonomously without constant approval prompts." — 安全机制说明
|
||||
> "Each task runs in an isolated git worktree, preventing agents from interfering with each other." — 隔离机制说明
|
||||
> "Vibe Kanban uses the GitHub CLI for creating pull requests. Ensure gh is installed and authenticated on your system." — GitHub 集成依赖
|
||||
|
||||
## Key Concepts
|
||||
- [[PM2]]：Node.js 进程管理器，提供进程守护、自动重启和开机自启功能
|
||||
- [[npx]]：Node.js 包执行工具，无需全局安装即可运行包
|
||||
- [[Vibe Coding]]：AI 辅助编程范式，通过自然语言描述让 AI 代理完成编码任务
|
||||
- [[MCP Server]]：Model Context Protocol 服务器，用于标准化 AI 代理与外部工具的集成
|
||||
|
||||
## Key Entities
|
||||
- [[Vibe-Kanban]]：BloopAI 出品的 AI 任务管理看板工具，支持多种编码代理
|
||||
- [[BloopAI]]：开发 Vibe-Kanban 的 AI 代码工具公司
|
||||
- [[Node.js]]：Vibe-Kanban 运行所需的 JavaScript 运行时环境
|
||||
- [[GitHub CLI]]：用于创建 Pull Request 的命令行工具，Vibe-Kanban 可选集成
|
||||
|
||||
## Connections
|
||||
- [[Vibe-Kanban]] ← depends_on ← [[Node.js]]
|
||||
- [[Vibe-Kanban]] ← extends ← [[GitHub CLI]]
|
||||
- [[Vibe-Kanban]] ← optional_integration ← [[MCP Server]]
|
||||
- [[PM2]] ← manages ← [[Vibe-Kanban]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
|
||||
- 冲突点：两者都介绍 Vibe-Kanban 安装，但侧重点不同
|
||||
- 当前观点：本文档侧重官方标准安装流程和 PM2 进程管理
|
||||
- 对方观点：[[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 侧重 OpenCode 集成配置
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
|
||||
date: 2026-05-28
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
|
||||
- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission、SSH 等）如何通过自定义域名从公网安全访问
|
||||
- 方法/机制：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps（frp 服务端）和 Caddy → 内网主机运行 frpc（frp 客户端）将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS
|
||||
- 结论/价值：完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程，并提供了 7 步系统化故障排查指南
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- frp 内网穿透工具包含 frps（服务端）和 frpc（客户端），通过 TCP 反向隧道将内网端口暴露到公网 VPS，支持 NAT 穿透和自动重连
|
||||
- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
|
||||
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
|
||||
- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现（`type = tcp`，`remote_port = 60022`）
|
||||
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
|
||||
- frp 连接失败的主要原因包括：端口被占用/token 不一致/防火墙拦截/Caddy 误 proxy TCP 端口
|
||||
- 通过 `ssh -p 60022 user@ubuntu1.ishenwei.online` 可从公网 SSH 到内网 Ubuntu（需 DNS A 记录 + frpc 配置）
|
||||
|
||||
## Key Quotes
|
||||
> "思路：Cloudflare DNS 指向公网上的一台VPS，VPS 上运行 Caddy；内网主机通过 frp 将服务暴露到 VPS（本地 127.0.0.1 或某个端口），VPS 反向代理到该端口。" — 整体方案架构描述
|
||||
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
|
||||
|
||||
> "⚠️ **重点提醒（安全性）**：SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
|
||||
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
|
||||
|
||||
> "很多人遇到的问题是：他们编辑了 `/opt/frp/frps.ini`，但 systemd service 其实加载另一个路径，例如 `/etc/frp/frps.ini`。" — frps 配置加载路径的常见陷阱
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]：通过公网服务器中转，使 NAT/防火墙后的内网服务可被外部访问的技术，本方案使用 frp 反向隧道实现
|
||||
- [[反向代理]]：Caddy 作为反向代理，将公网 HTTPS 请求转发到本地 frp 映射端口，提供统一的 HTTPS 入口
|
||||
- [[TCP隧道]]：frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道，支持非 HTTP 协议（如 SSH、MySQL）
|
||||
- [[自动HTTPS]]：Caddy 内置 Let's Encrypt 证书自动申请和续期，无需手动管理 SSL 证书
|
||||
- [[DNS A记录]]：Cloudflare DNS 配置，将子域名（如 nas.ishenwei.online）指向 VPS 公网 IP
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd VPS]]：VPS 提供商（192.227.222.142），托管 frps 服务端和 Caddy 反向代理，作为内网穿透的公网中转站
|
||||
- [[Synology NAS DS718]]：内网 NAS 设备（192.168.3.17），运行 frpc 客户端，通过 frp 暴露 NAS 服务（5000端口 → VPS 15000）、Navidrome、Calibre、WebDAV、Miniflux、Zipline、MySQL、SSH 等多个服务
|
||||
- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0；通过 token 认证确保连接安全
|
||||
- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问；支持 `caddy validate` 命令验证配置语法
|
||||
- [[Cloudflare]]：域名 DNS 托管服务商，通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
|
||||
|
||||
## Connections
|
||||
- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（本文是该概览中内网穿透架构的详细展开）
|
||||
- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（FRP 安装是该方案的前置步骤）
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Mac Mini FRP 客户端配置参考）
|
||||
- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Ubuntu Server 24.04 是本方案的目标操作系统）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点：
|
||||
- 冲突点：监控方案中是否包含完整的公网访问配置
|
||||
- 当前观点：本文提供完整公网域名访问方案，包含 HTTPS 和 SSH 穿透的详细配置
|
||||
- 对方观点：监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置，未展开公网访问细节
|
||||
- 建议：在监控方案中补充指向本文内网穿透配置的外链，实现监控方案 + 公网访问的完整闭环
|
||||
---
|
||||
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
|
||||
date: 2026-05-28
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
|
||||
- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission、SSH 等）如何通过自定义域名从公网安全访问
|
||||
- 方法/机制：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps（frp 服务端）和 Caddy → 内网主机运行 frpc（frp 客户端）将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS
|
||||
- 结论/价值：完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程，并提供了 7 步系统化故障排查指南
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- frp 内网穿透工具包含 frps（服务端）和 frpc（客户端），通过 TCP 反向隧道将内网端口暴露到公网 VPS，支持 NAT 穿透和自动重连
|
||||
- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
|
||||
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
|
||||
- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现（`type = tcp`，`remote_port = 60022`）
|
||||
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
|
||||
- frp 连接失败的主要原因包括：端口被占用/token 不一致/防火墙拦截/Caddy 误 proxy TCP 端口
|
||||
- 通过 `ssh -p 60022 user@ubuntu1.ishenwei.online` 可从公网 SSH 到内网 Ubuntu（需 DNS A 记录 + frpc 配置）
|
||||
|
||||
## Key Quotes
|
||||
> "思路：Cloudflare DNS 指向公网上的一台VPS，VPS 上运行 Caddy；内网主机通过 frp 将服务暴露到 VPS（本地 127.0.0.1 或某个端口），VPS 反向代理到该端口。" — 整体方案架构描述
|
||||
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
|
||||
|
||||
> "⚠️ **重点提醒（安全性）**：SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
|
||||
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
|
||||
|
||||
> "很多人遇到的问题是：他们编辑了 `/opt/frp/frps.ini`，但 systemd service 其实加载另一个路径，例如 `/etc/frp/frps.ini`。" — frps 配置加载路径的常见陷阱
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]：通过公网服务器中转，使 NAT/防火墙后的内网服务可被外部访问的技术，本方案使用 frp 反向隧道实现
|
||||
- [[反向代理]]：Caddy 作为反向代理，将公网 HTTPS 请求转发到本地 frp 映射端口，提供统一的 HTTPS 入口
|
||||
- [[TCP隧道]]：frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道，支持非 HTTP 协议（如 SSH、MySQL）
|
||||
- [[自动HTTPS]]：Caddy 内置 Let's Encrypt 证书自动申请和续期，无需手动管理 SSL 证书
|
||||
- [[DNS A记录]]：Cloudflare DNS 配置，将子域名（如 nas.ishenwei.online）指向 VPS 公网 IP
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd VPS]]：VPS 提供商（192.227.222.142），托管 frps 服务端和 Caddy 反向代理，作为内网穿透的公网中转站
|
||||
- [[Synology NAS DS718]]：内网 NAS 设备（192.168.3.17），运行 frpc 客户端，通过 frp 暴露 NAS 服务（5000端口 → VPS 15000）、Navidrome、Calibre、WebDAV、Miniflux、Zipline、MySQL、SSH 等多个服务
|
||||
- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0；通过 token 认证确保连接安全
|
||||
- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问；支持 `caddy validate` 命令验证配置语法
|
||||
- [[Cloudflare]]：域名 DNS 托管服务商，通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
|
||||
|
||||
## Connections
|
||||
- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（本文是该概览中内网穿透架构的详细展开）
|
||||
- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（FRP 安装是该方案的前置步骤）
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Mac Mini FRP 客户端配置参考）
|
||||
- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Ubuntu Server 24.04 是本方案的目标操作系统）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点：
|
||||
- 冲突点：监控方案中是否包含完整的公网访问配置
|
||||
- 当前观点：本文提供完整公网域名访问方案，包含 HTTPS 和 SSH 穿透的详细配置
|
||||
- 对方观点：监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置，未展开公网访问细节
|
||||
- 建议：在监控方案中补充指向本文内网穿透配置的外链，实现监控方案 + 公网访问的完整闭环
|
||||
|
||||
@@ -1,44 +1,44 @@
|
||||
---
|
||||
title: "如何传输Docker images 并且在另一个Docker安装"
|
||||
type: source
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何传输Docker images 并且在另一个Docker安装]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Docker 镜像在两台 Docker 环境之间的离线传输方法
|
||||
- 问题域：无镜像仓库的内网环境或离线场景下的镜像迁移
|
||||
- 方法/机制：`docker save` 导出为 tar → 上传目标机器 → `docker load` 导入
|
||||
- 结论/价值：提供了无需镜像仓库的离线迁移标准流程，适用于家庭 NAS 与工作设备之间的镜像同步
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- `docker pull` 从远程仓库拉取镜像到本地 Docker 环境
|
||||
- `docker save -o <output.tar> <image>` 将镜像导出为 tar 归档文件，可离线拷贝
|
||||
- `docker load < <input.tar` 在目标机器从 tar 文件加载镜像，无需网络连接
|
||||
- 上传 tar 包到目标机器后，可在 Container Manager 等 Web UI 中直接看到已导入的镜像
|
||||
|
||||
## Key Quotes
|
||||
> "cd 到 xiaoya.tar 存放的路径之后运行以下命令 docker load < xiaoya.tar" — 在 Synology NAS 上通过 SSH 执行镜像导入
|
||||
> "再进入 NAS 的 Container Manager 界面后在 image 里就可以看到 xiaoya/alist 这个 image 了" — 验证镜像导入成功的方式
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker-Image]]：容器镜像，Docker 应用打包的标准格式
|
||||
- [[Docker-Save]]：`docker save` 命令将镜像导出为 tar 归档文件
|
||||
- [[Docker-Load]]：`docker load` 命令从 tar 文件加载镜像到本地 Docker 引擎
|
||||
- [[Docker-Registry]]：镜像仓库（本文未使用，但提及作为替代方案）
|
||||
|
||||
## Key Entities
|
||||
- [[Docker]]：容器化平台，本文的操作基础环境
|
||||
- [[Synology-NAS]]：群晖 NAS，运行 Docker（Container Manager），本文镜像迁移的目标端
|
||||
- [[Alist]]：开源网盘聚合工具（xiaoyaliu/alist），本文操作的示例镜像
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← extends ← [[如何传输Docker images 并且在另一个Docker安装]]
|
||||
- [[在Synology NAS上安装CloudDrive2]] ← related_to ← [[如何传输Docker images 并且在另一个Docker安装]]（同为 Synology NAS Docker 操作场景）
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突）
|
||||
---
|
||||
title: "如何传输Docker images 并且在另一个Docker安装"
|
||||
type: source
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何传输Docker images 并且在另一个Docker安装]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Docker 镜像在两台 Docker 环境之间的离线传输方法
|
||||
- 问题域：无镜像仓库的内网环境或离线场景下的镜像迁移
|
||||
- 方法/机制：`docker save` 导出为 tar → 上传目标机器 → `docker load` 导入
|
||||
- 结论/价值：提供了无需镜像仓库的离线迁移标准流程，适用于家庭 NAS 与工作设备之间的镜像同步
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- `docker pull` 从远程仓库拉取镜像到本地 Docker 环境
|
||||
- `docker save -o <output.tar> <image>` 将镜像导出为 tar 归档文件，可离线拷贝
|
||||
- `docker load < <input.tar` 在目标机器从 tar 文件加载镜像，无需网络连接
|
||||
- 上传 tar 包到目标机器后，可在 Container Manager 等 Web UI 中直接看到已导入的镜像
|
||||
|
||||
## Key Quotes
|
||||
> "cd 到 xiaoya.tar 存放的路径之后运行以下命令 docker load < xiaoya.tar" — 在 Synology NAS 上通过 SSH 执行镜像导入
|
||||
> "再进入 NAS 的 Container Manager 界面后在 image 里就可以看到 xiaoya/alist 这个 image 了" — 验证镜像导入成功的方式
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker-Image]]：容器镜像，Docker 应用打包的标准格式
|
||||
- [[Docker-Save]]：`docker save` 命令将镜像导出为 tar 归档文件
|
||||
- [[Docker-Load]]：`docker load` 命令从 tar 文件加载镜像到本地 Docker 引擎
|
||||
- [[Docker-Registry]]：镜像仓库（本文未使用，但提及作为替代方案）
|
||||
|
||||
## Key Entities
|
||||
- [[Docker]]：容器化平台，本文的操作基础环境
|
||||
- [[Synology-NAS]]：群晖 NAS，运行 Docker（Container Manager），本文镜像迁移的目标端
|
||||
- [[Alist]]：开源网盘聚合工具（xiaoyaliu/alist），本文操作的示例镜像
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← extends ← [[如何传输Docker images 并且在另一个Docker安装]]
|
||||
- [[在Synology NAS上安装CloudDrive2]] ← related_to ← [[如何传输Docker images 并且在另一个Docker安装]]（同为 Synology NAS Docker 操作场景）
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突）
|
||||
|
||||
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: "如何删除旧的废弃的 Docker Container + Volume"
|
||||
type: source
|
||||
tags: [docker, container, portainer, volume]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何删除旧的废弃的docker container +volume.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：清理 Docker 环境中废弃的 Portainer 容器、Volume 和 Network 的完整操作流程
|
||||
- 问题域：Docker 容器残留导致的端口冲突、卷数据残留、以及重启 Portainer 时出现的 WARN 警告
|
||||
- 方法/机制：通过 `docker stop/rm`、`docker volume ls/rm`、`docker network ls/rm` 系列命令手动清理；使用 `docker compose down` 一键清理整个 compose 项目；通过 `external: true` 配置避免 future 部署时的资源冲突
|
||||
- 结论/价值：提供了从手动单步清理到一键重装的完整操作链，以及 WARN 原因分析和解决方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- `docker compose down` 命令可同时删除容器、网络和匿名 Volume，但保留命名 Volume
|
||||
- `docker volume rm` 可显式删除指定 Volume（如 `portainer_data`），从而清除 Portainer 所有用户数据和配置
|
||||
- Docker WARN "Network already exists" 表示同名 network 由另一个 compose 项目创建，与当前项目冲突
|
||||
- Docker WARN "Volume is used by another service" 表示同名 volume 属于另一个 compose 项目的不同 project name
|
||||
- 在 compose 文件中设置 `external: true` 可让新项目复用旧 network/volume 而不触发冲突警告
|
||||
|
||||
## Key Quotes
|
||||
> "⚠️ 注意：这会删除 Portainer 所有数据（用户、配置）。如果你想保留数据，不要删 volume，只需要在 compose 文件里加：`external: true`" — 删除 portainer_data 的重要提示
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Container]]：Docker 镜像的运行实例，`docker ps -a` 查看所有容器，`docker rm` 删除已停止容器，`docker rm -f` 强制删除运行中容器
|
||||
- [[Docker Volume]]：持久化存储机制，挂载到容器内部用于保存数据；`docker volume ls` 列出所有卷，`docker volume rm` 删除指定卷
|
||||
- [[Docker Network]]：容器间通信的虚拟网络；同名 network 冲突是 compose 项目隔离机制导致的警告
|
||||
- [[Docker Compose]]：`docker compose down` 停止并删除整个 compose 项目中的容器、网络，以及（非 external 的）命名卷
|
||||
- [[Docker Socket]]：Docker 守护进程的 Unix Socket（通常为 `/var/run/docker.sock`），Portainer 通过挂载它实现对本地 Docker 的管理
|
||||
|
||||
## Key Entities
|
||||
- [[Portainer]]：开源 Docker 容器管理面板，本文档的清理目标；`portainer/portainer-ce` 为其 Community Edition 镜像
|
||||
- [[portainer_data]]：Portainer 的命名 Docker Volume，存储用户、配置等持久化数据
|
||||
|
||||
## Connections
|
||||
- [[用Docker安装Portainer]] ← depends_on ← [[如何删除旧的废弃的 Docker Container + Volume]]
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← related_to ← [[如何删除旧的废弃的 Docker Container + Volume]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## 完整操作流程速查
|
||||
|
||||
```bash
|
||||
# 最干净的重装流程
|
||||
docker stop portainer && docker rm portainer
|
||||
docker volume rm portainer_data
|
||||
docker network rm portainer_network
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
```bash
|
||||
# 一键清理（compose 部署）
|
||||
docker compose down # 删除容器+网络+匿名卷
|
||||
docker compose down -v # 额外删除命名卷（谨慎！）
|
||||
```
|
||||
---
|
||||
title: "如何删除旧的废弃的 Docker Container + Volume"
|
||||
type: source
|
||||
tags: [docker, container, portainer, volume]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何删除旧的废弃的docker container +volume.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：清理 Docker 环境中废弃的 Portainer 容器、Volume 和 Network 的完整操作流程
|
||||
- 问题域：Docker 容器残留导致的端口冲突、卷数据残留、以及重启 Portainer 时出现的 WARN 警告
|
||||
- 方法/机制：通过 `docker stop/rm`、`docker volume ls/rm`、`docker network ls/rm` 系列命令手动清理；使用 `docker compose down` 一键清理整个 compose 项目；通过 `external: true` 配置避免 future 部署时的资源冲突
|
||||
- 结论/价值：提供了从手动单步清理到一键重装的完整操作链，以及 WARN 原因分析和解决方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- `docker compose down` 命令可同时删除容器、网络和匿名 Volume，但保留命名 Volume
|
||||
- `docker volume rm` 可显式删除指定 Volume（如 `portainer_data`），从而清除 Portainer 所有用户数据和配置
|
||||
- Docker WARN "Network already exists" 表示同名 network 由另一个 compose 项目创建，与当前项目冲突
|
||||
- Docker WARN "Volume is used by another service" 表示同名 volume 属于另一个 compose 项目的不同 project name
|
||||
- 在 compose 文件中设置 `external: true` 可让新项目复用旧 network/volume 而不触发冲突警告
|
||||
|
||||
## Key Quotes
|
||||
> "⚠️ 注意：这会删除 Portainer 所有数据（用户、配置）。如果你想保留数据，不要删 volume，只需要在 compose 文件里加：`external: true`" — 删除 portainer_data 的重要提示
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Container]]：Docker 镜像的运行实例，`docker ps -a` 查看所有容器，`docker rm` 删除已停止容器，`docker rm -f` 强制删除运行中容器
|
||||
- [[Docker Volume]]：持久化存储机制，挂载到容器内部用于保存数据；`docker volume ls` 列出所有卷，`docker volume rm` 删除指定卷
|
||||
- [[Docker Network]]：容器间通信的虚拟网络；同名 network 冲突是 compose 项目隔离机制导致的警告
|
||||
- [[Docker Compose]]：`docker compose down` 停止并删除整个 compose 项目中的容器、网络，以及（非 external 的）命名卷
|
||||
- [[Docker Socket]]：Docker 守护进程的 Unix Socket（通常为 `/var/run/docker.sock`），Portainer 通过挂载它实现对本地 Docker 的管理
|
||||
|
||||
## Key Entities
|
||||
- [[Portainer]]：开源 Docker 容器管理面板，本文档的清理目标；`portainer/portainer-ce` 为其 Community Edition 镜像
|
||||
- [[portainer_data]]：Portainer 的命名 Docker Volume，存储用户、配置等持久化数据
|
||||
|
||||
## Connections
|
||||
- [[用Docker安装Portainer]] ← depends_on ← [[如何删除旧的废弃的 Docker Container + Volume]]
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← related_to ← [[如何删除旧的废弃的 Docker Container + Volume]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## 完整操作流程速查
|
||||
|
||||
```bash
|
||||
# 最干净的重装流程
|
||||
docker stop portainer && docker rm portainer
|
||||
docker volume rm portainer_data
|
||||
docker network rm portainer_network
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
```bash
|
||||
# 一键清理（compose 部署）
|
||||
docker compose down # 删除容器+网络+匿名卷
|
||||
docker compose down -v # 额外删除命名卷（谨慎！）
|
||||
```
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user