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/
|
||||
|
||||
Reference in New Issue
Block a user