ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Auto-sync: 2026-04-26 20:02

Browse Source
This commit is contained in:
weishen
2026-04-26 20:02:45 +08:00
parent d42bc16120
commit b7d9d0f5d1
54 changed files with 3196 additions and 3021 deletions
Download Patch File Download Diff File Expand all files Collapse all files

111
wiki/concepts/AIOps.md
View File

@@ -1,55 +1,56 @@
---
title: AIOps
tags:
- ai
- devops
- it-operations
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
]
```

103
wiki/concepts/Caddy.md Normal file
View File

@@ -0,0 +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

147
wiki/concepts/Cloud-Cost-Optimization.md
View File

@@ -1,73 +1,74 @@
---
title: "Cloud Cost Optimization"
type: concept
tags: [Cloud, FinOps, Cost Management, Cloud Operations]
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]]

137
wiki/concepts/Cloud-Governance.md
View File

@@ -1,68 +1,69 @@
---
title: "Cloud Governance"
type: concept
tags: [Cloud, Governance, Compliance, Security, Cloud Operations]
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]]

251
wiki/concepts/Cloud-Operating-Model.md
View File

@@ -1,125 +1,126 @@
---
title: "Cloud Operating Model"
type: concept
tags: [Cloud, Cloud Strategy, Cloud Governance, Cloud Operations]
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)

116
wiki/concepts/DAST.md
View File

@@ -1,64 +1,52 @@
# DAST (Dynamic Application Security Testing)
## Definition
DAST tools simulate external attacks on applications to uncover vulnerabilities from an outsider's viewpoint. These tools are essential for identifying weaknesses that attackers could exploit.
## Aliases
- Dynamic Application Security Testing
- Black-box testing
- Vulnerability scanning
## Characteristics
- **运行时分析**：在应用运行时进行测试
- **黑盒测试**：不了解内部代码结构
- **测试/部署阶段适用**：在应用运行时进行测试
- **模拟真实攻击**：从攻击者角度发现漏洞
## What DAST Detects
- 认证和授权问题
- API 安全漏洞
- 配置错误
- 会话管理问题
- 业务逻辑漏洞
- API 端点暴露
## Tools
- OWASP ZAP (Zed Attack Proxy)
- Burp Suite
- Acunetix
- Netsparker
- AppScan
## Integration
DAST 工具通常用于：
- CI/CD 管道中的集成测试
- 预发布安全扫描
- 定期渗透测试
- 生产环境监控
## Comparison with Other Testing Methods
| 维度 | SAST | DAST | IAST |
|------|------|------|------|
| **测试方式** | 白盒（静态） | 黑盒（动态） | 灰盒（运行时） |
| **需要代码** | 是 | 否 | 部分 |
| **误报率** | 中等 | 低 | 低 |
| **检测范围** | 代码层 | 应用层 | 代码+应用层 |
| **适用阶段** | 开发 | 测试/部署 | 测试 |
## Limitations
- 无法定位具体代码行
- 无法检测源代码级别的漏洞
- 扫描速度相对较慢
- 可能产生误报
## Related Concepts
- [[DevSecOps]] — DAST 是其重要组件
- [[SAST]] — 静态应用安全测试（白盒）
- [[IAST]] — 交互式应用安全测试
- [[SCA]] — 软件组成分析
- [[Penetration-Testing]] — 渗透测试
- [[Vulnerability-Scanning]] — 漏洞扫描
## Sources
- [[what-is-devsecops-best-practices-benefits-and-tools]]
---
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 扫描

116
wiki/concepts/DevSecOps.md
View File

@@ -1,61 +1,55 @@
# DevSecOps
## Definition
DevSecOps（Development-Security-Operations）是将安全实践深度集成到软件开发全生命周期的方法论，使安全成为开发、运维、安全团队的共同责任，而非独立环节。
## Core Principles
- **安全即代码**：安全策略、测试和合规检查均以代码形式实现
- **共享责任**：安全是每个人的责任，而非仅安全团队的工作
- **自动化优先**：通过自动化减少人为错误，提高安全检查效率
- **持续安全**：安全贯穿开发、测试、部署、运营全阶段
## Key Components
### 1. Collaboration（协作）
安全任务在开发和运维团队间共享，安全团队确保安全标准嵌入整个开发流程。
### 2. Communication（沟通）
安全专业人员需要用开发者理解的简单语言解释安全控制，建立共同的安全认知。
### 3. Automation（自动化）
- 将自动化安全测试添加到 CI/CD 管道
- "Break the Build" 机制在安全风险过高时停止构建
- 确保软件依赖保持最新
### 4. Tool & Architecture Security（工具与架构安全）
- 选择和审查安全工具
- 谨慎管理用户访问（多因素认证、最小权限）
- 定期监控漏洞和打补丁
- 扫描代码中的敏感数据
### 5. Testing（测试）
在每个开发阶段集成安全测试，使用 SAST/DAST/IAST/SCA 等工具。
## DevSecOps vs DevOps
| 维度 | DevOps | DevSecOps |
|------|--------|-----------|
| **定义** | 强调开发与运维协作加速交付 | 将安全实践集成到开发过程 |
| **安全角色** | 安全单独处理或最后处理 | 从一开始就将安全嵌入每个步骤 |
| **团队参与** | 开发与运维协作 | 开发、运维、安全三方协作 |
| **合规方式** | 开发后进行合规检查 | 开发部署全程确保合规 |
## Benefits
- 早期发现漏洞，修复成本降低可达 100 倍
- 70% 的上线后发现的安全漏洞可在开发阶段预防
- 安全与开发速度实现双赢
- 持续合规，减少审计压力
## Related Concepts
- [[Shift-Left-Security]] — 安全测试左移到开发早期
- [[Shift-Right-Security]] — 生产环境持续安全监控
- [[SAST]] — 静态应用安全测试
- [[DAST]] — 动态应用安全测试
- [[IAST]] — 交互式应用安全测试
- [[SCA]] — 软件组成分析
- [[CI/CD Pipeline]] — DevSecOps 的载体
- [[Policy-as-Code]] — 以代码管理安全策略
- [[Break-the-Build]] — 安全失败时停止构建
## Sources
- [[what-is-devsecops-best-practices-benefits-and-tools]]
---
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

216
wiki/concepts/FinOps.md
View File

@@ -1,105 +1,111 @@
# 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 指标

60
wiki/concepts/Fstab.md Normal file
View File

@@ -0,0 +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 配置详细说明

38
wiki/concepts/GPT分区表.md Normal file
View File

@@ -0,0 +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进行全盘镜像备份]]

149
wiki/concepts/Green-Computing.md
View File

@@ -1,74 +1,75 @@
---
title: "Green Computing"
type: concept
tags: [Cloud, Sustainability, Environmental, Cloud Operations]
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]]

98
wiki/concepts/Infrastructure-as-Code.md
View File

@@ -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]
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 协作工具

268
wiki/concepts/Multi-Cloud-Strategy.md
View File

@@ -1,131 +1,137 @@
# 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]] — 云财务管理

75
wiki/concepts/NVMe硬盘分区.md
View File

@@ -1,37 +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工作站笔记本上]]
---
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进行全盘镜像备份]]

105
wiki/concepts/SAST.md
View File

@@ -1,52 +1,53 @@
# SAST (Static Application Security Testing)
## Definition
SAST tools analyze an application's source code to identify security vulnerabilities without executing the code. They excel at spotting common issues such as SQL injection, cross-site scripting, and buffer overflows.
## Aliases
- Static Application Security Testing
- White-box testing
- Static analysis
## Characteristics
- **无需运行代码**：在静态状态下分析源代码
- **白盒测试**：能看到代码内部结构
- **开发阶段适用**：在编码和代码审查时使用
- **速度快**：可以快速扫描大量代码
## Common Vulnerabilities Detected
- SQL 注入（SQL Injection）
- 跨站脚本（XSS, Cross-Site Scripting）
- 缓冲区溢出（Buffer Overflow）
- 硬编码凭证（Hardcoded Credentials）
- 不安全的加密使用
- 路径遍历（Path Traversal）
## Tools
- [[SonarQube]] — 代码质量和安全分析
- Checkmarx
- Veracode
- Fortify
- Semgrep
## Integration
SAST 工具通常集成到：
- IDE 开发环境
- CI/CD 构建管道
- 代码审查流程
## Limitations
- 可能产生误报（False Positives）
- 无法检测运行时问题
- 需要源代码访问权限
- 不检测配置问题
## Related Concepts
- [[DevSecOps]] — SAST 是其重要组件
- [[DAST]] — 动态应用安全测试（黑盒测试）
- [[IAST]] — 交互式应用安全测试
- [[SCA]] — 软件组成分析
- [[Shift-Left-Security]] — SAST 是左移策略的重要工具
## Sources
- [[what-is-devsecops-best-practices-benefits-and-tools]]
---
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 是其核心实践

159
wiki/concepts/TCP隧道.md
View File

@@ -1,112 +1,47 @@
---
title: "TCP 隧道"
type: concept
aliases: [TCP Tunnel, TCP端口转发, TCP代理]
tags: [network, tunneling, protocol]
---
# TCP 隧道
## Definition
**TCP 隧道**是通过在两个端点之间建立虚拟连接，将本地 TCP 端口的流量透明传输到远程端点的技术。TCP 隧道是构建 VPN、反向代理和内网穿透的基础机制之一。
## How It Works
```
┌─────────────┐ ┌─────────────┐
│ 本地机器 │ │ VPS │
│ │ │ │
│ 应用 → :22 │ ──── TCP 隧道 ──── → │ :60022 ← ──│──── 外部 SSH 客户端
│ │ (frp/nc/socat) │ │
└─────────────┘ └─────────────┘
```
## TCP vs HTTP/HTTPS 隧道
| 特性 | TCP 隧道 | HTTP/HTTPS 隧道 |
|------|----------|----------------|
| **协议** | 任意 TCP | HTTP/HTTPS |
| **应用层解析** | ❌ 不解析 | ✅ 可解析 |
| **WebSocket** | ❌ 不支持 | ✅ 支持 |
| **使用场景** | SSH、数据库、任意 TCP | Web 服务 |
| **Caddy 支持** | ❌ 不支持 | ✅ 支持 |
## frp TCP 映射
### 配置示例
```ini
# frpc.ini
[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 60022
```
### 访问链路
```
外部 SSH 客户端
↓
ssh -p 60022 user@vps-ip
↓
VPS :60022 (frps 监听)
↓
frp 隧道
↓
内网机器 :22
↓
本地 SSH 服务
```
## Common Tools for TCP Tunneling
| 工具 | 特点 | 使用场景 |
|------|------|---------|
| **frp** | 高性能、支持 Dashboard | 内网穿透 |
| **socat** | 简单单次转发 | 临时调试 |
| **netcat (nc)** | 基础端口转发 | 快速测试 |
| **ssh -L** | SSH 内置隧道 | 临时访问 |
| **stunnel** | SSL 隧道加密 | 安全转发 |
## SSH 原生隧道 (替代方案)
### 临时隧道
```bash
# 本地端口转发：访问远程内网服务
ssh -L 8080:internal:80 user@vps
# 远程端口转发：暴露本地服务到公网
ssh -R 60022:localhost:22 user@vps
```
### 持久化问题
SSH 隧道在网络中断后不会自动重连，生产环境推荐使用 frp。
## Security Considerations
### TCP 隧道注意事项
1. **不经过 HTTP 代理**：TCP 流量不被 Caddy/Nginx 解析
2. **直接暴露端口**：SSH 22 端口不宜直接暴露，使用非标准端口
3. **IP 白名单**：防火墙限制来源 IP
4. **公钥认证**：禁用密码登录
### 建议配置
```bash
# VPS 防火墙：只允许特定 IP
sudo ufw allow from <home_ip> to any port 60022 proto tcp
# SSH 配置：禁用密码
sudo nano /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
```
## Related Concepts
- [[内网穿透]] — TCP 隧道的典型应用场景
- [[frp]] — 实现 TCP 隧道的工具
- [[反向代理]] — HTTP/HTTPS 层面的代理（与 TCP 层互补）
- [[VPS]] — TCP 隧道的公网端点
## References
- frp TCP: https://gofrp.org/docs/features/common-address-types/#tcp
- SSH Tunneling: https://www.ssh.com/academy/ssh/tunneling
---
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

135
wiki/concepts/Zero-Trust-Architecture.md
View File

@@ -1,67 +1,68 @@
---
title: "Zero Trust Architecture (ZTA)"
type: concept
tags: [security, cloud, compliance]
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中的应用

70
wiki/concepts/Zero-Trust.md
View File

@@ -1,35 +1,35 @@
---
title: "Zero-Trust"
type: concept
tags: [security, identity, authorization]
sources: [agentic-identity-trust.md]
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]]

98
wiki/concepts/frp.md Normal file
View File

@@ -0,0 +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

176
wiki/concepts/内网穿透.md
View File

@@ -1,122 +1,54 @@
---
title: "内网穿透"
type: concept
aliases: [NAT穿透, 内网访问, 穿透技术]
tags: [network, tunneling, infrastructure]
---
# 内网穿透
## Definition
**内网穿透**（NAT Traversal / Reverse Proxy Tunneling）是一种使位于私有网络（内网）中的设备能够被公网访问的技术。家用网络设备通常位于 NAT（网络地址转换）后面，无法直接接收公网连接，内网穿透通过在公网服务器建立反向隧道来解决这一问题。
## Core Principle
传统正向代理：客户端 → 公网代理服务器 → 目标服务器
内网穿透（反向隧道）：公网服务器 → 反向隧道 → 内网客户端
```
Internet
│
│ ← 发起连接（公网）
▼
┌───────────────┐
│ VPS (公网) │
│ frps/Caddy │
└───────┬───────┘
│ ← 反向隧道建立
▼
┌───────────────┐
│ 内网机器 (frpc) │
│ 192.168.x.x │
└───────────────┘
```
## Common Tools
| 工具 | 协议 | 特点 | 适用场景 |
|------|------|------|---------|
| **frp** | TCP/UDP/HTTP | 高性能、支持 Dashboard | 多服务穿透 |
| **ngrok** | TCP/HTTP | 简单易用、托管服务 | 临时测试 |
| **natapp** | TCP/HTTP | 国内服务 | 国内访问 |
| **花生壳** | TCP/HTTP | 老牌、商业化 | 企业用户 |
| **ZeroTier** | VPN | 虚拟局域网 | 远程办公 |
## frp 实现方案
### 架构组件
1. **frps (Server)**：部署在公网 VPS，监听端口（默认 7000）
2. **frpc (Client)**：部署在内网机器，主动连接 frps
### 典型配置流程
1. VPS 安装 frps，配置 systemd 服务
2. 内网机器安装 frpc，配置连接参数
3. frpc 配置端口映射（local_port → remote_port）
4. Caddy/Nginx 在 VPS 做反向代理
### 映射示例
```ini
# frpc.ini
[nas]
type = tcp
local_ip = 127.0.0.1
local_port = 5000
remote_port = 15000
```
### 完整访问链路
```
用户浏览器 → https://nas.domain.com
↓
阿里云 DNS → VPS 公网 IP
↓
Caddy (443) → reverse_proxy 127.0.0.1:15000
↓
frps 在 VPS :15000 监听
↓
frp 隧道
↓
frpc 在内网 :5000 监听
↓
NAS Web UI
```
## Security Considerations
### 认证保护
- frps 配置 `token` 与 frpc 匹配
- Caddy 可添加 HTTP Basic Auth
- 使用非标准端口避免扫描
### 访问控制
```bash
# UFW 防火墙限制来源 IP
sudo ufw allow from <your_home_ip> to any port 60022 proto tcp
```
### SSH 安全
```bash
# 使用公钥认证，禁用密码
# 编辑 /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
```
## Trade-offs
| 优势 | 劣势 |
|------|------|
| 无需公网 IP | 依赖 VPS 稳定性 |
| 支持任意 TCP/UDP 服务 | 增加延迟 |
| 可绑定独立域名 | 需要维护 frps/frpc |
| 成本低（月付几美元 VPS） | 安全配置复杂 |
## Related Concepts
- [[frp]] — 实现内网穿透的工具
- [[反向代理]] — 内网穿透的上层组件
- [[TCP 隧道]] — 内网穿透的底层机制
- [[VPS]] — 内网穿透的公网中转站
- [[Let's Encrypt]] — 自动 HTTPS 证书
## References
- frp 官方文档: https://gofrp.org/docs/
---
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

190
wiki/concepts/反向代理.md
View File

@@ -1,149 +1,41 @@
---
title: "反向代理"
type: concept
aliases: [Reverse Proxy, 反向代理服务器]
tags: [network, proxy, infrastructure, web-server]
---
# 反向代理
## Definition
**反向代理**（Reverse Proxy）是一种服务器架构模式，代理服务器位于客户端与源服务器之间，代表源服务器接收客户端请求，并对请求进行转发、负载均衡或缓存。与正向代理（代理客户端）不同，反向代理对客户端透明，客户端不知道真实服务器的存在。
## Architecture
```
┌─────────────────────────────────────┐
│ Reverse Proxy │
│ (Caddy / Nginx / Apache) │
│ │
Client Request → │ example.com → localhost:8080 │
(隐藏真实服务器) │ api.example.com → localhost:3000 │
└──────────────┬──────────────────────┘
│
┌──────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Server 1 │ │ Server 2 │ ... │ Server N │
│ :8080 │ │ :3000 │ │ :5000 │
└──────────┘ └──────────┘ └──────────┘
```
## Common Use Cases
### 1. 多服务域名复用
单台 VPS 通过不同子域名代理到不同内网服务：
```
nas.ishenwei.online → 127.0.0.1:15000 (NAS)
n8n.ishenwei.online → 127.0.0.1:15678 (n8n)
grafana.ishenwei.online → 127.0.0.1:13000 (Grafana)
```
### 2. 自动 HTTPS
反向代理自动处理 SSL 证书申请和续期：
```
Caddy: 自动从 Let's Encrypt 获取证书
Nginx: 需要手动配置 certbot
```
### 3. 负载均衡
```
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
```
### 4. 缓存加速
静态资源缓存，减少源服务器负载：
```
location /static/ {
proxy_cache_valid 200 60m;
proxy_cache_use_stale error timeout updating;
}
```
## Comparison of Tools
| 工具 | 语言 | 配置复杂度 | 自动 HTTPS | 内存占用 | 适用场景 |
|------|------|-----------|------------|----------|---------|
| **Caddy** | Go | ⭐ 简单 | ✅ 内置 | ~20MB | 个人/小型服务 |
| **Nginx** | C | ⭐⭐⭐ 中等 | 需配置 | ~5MB | 生产环境 |
| **Traefik** | Go | ⭐⭐ 简单 | ✅ 内置 | ~50MB | 容器编排 |
| **Apache** | C | ⭐⭐⭐⭐ 复杂 | 需配置 | ~50MB | 传统企业 |
## Caddy Configuration
### 基本反向代理
```caddyfile
example.com {
reverse_proxy localhost:8080
}
```
### 多域名代理
```caddyfile
nas.ishenwei.online {
reverse_proxy 127.0.0.1:15000
}
n8n.ishenwei.online {
reverse_proxy 127.0.0.1:15678
}
```
### 带路径重写
```caddyfile
example.com/api/* {
rewrite /api
reverse_proxy localhost:3000
}
```
### 带负载均衡
```caddyfile
example.com {
reverse_proxy localhost:8080 localhost:8081 localhost:8082 {
lb_policy round_robin
}
}
```
## Integration with frp
典型架构：frp 隧道 → 反向代理 → 自动 HTTPS
```
┌──────────────────────────────────────────────────────────┐
│ VPS │
│ │
│ Internet → :443 → Caddy (反向代理) → 127.0.0.1:15000 │
│ ↓ │
│ frps 监听 :15000 │
│ ↓ │
│ frp 隧道 │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 内网机器 │
│ │
│ frpc 连接 VPS:7000 │
│ ↓ │
│ frpc 映射 localhost:5000 → VPS:15000 │
│ ↓ │
│ NAS Web UI (5000端口) │
└──────────────────────────────────────────────────────────┘
```
## Related Concepts
- [[Caddy]] — 自动 HTTPS 的反向代理工具
- [[内网穿透]] — 反向代理在内网服务访问中的应用
- [[TCP 隧道]] — 反向代理的底层机制之一
- [[Let's Encrypt]] — 自动 HTTPS 证书来源
- [[负载均衡]] — 反向代理的高级功能
## References
- Caddy: https://caddyserver.com/docs/
- Nginx: https://nginx.org/en/docs/
---
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/