From de096f2f885d2c905fef03d2656408c8365384a0 Mon Sep 17 00:00:00 2001 From: weishen Date: Wed, 22 Apr 2026 04:03:04 +0800 Subject: [PATCH] Auto-sync: 2026-04-22 04:02 --- .../intent-ux-jakobnielsenphd-20260421.md | 291 +++++++++++++++ openclaw/openclaw备份任务.md | 3 + wiki/Caddy.md | 136 +++++++ wiki/LinuxServer.io.md | 64 ++++ wiki/PUID-PGID.md | 43 +++ wiki/TCP隧道.md | 112 ++++++ wiki/Transmission.md | 77 ++++ wiki/concepts/AI-ChatOps.md | 87 +++++ wiki/concepts/APT-仓库配置.md | 44 +++ wiki/concepts/Asset-Management.md | 79 ++++ wiki/concepts/Automated-Security-Audit.md | 83 +++++ wiki/concepts/Blue-Green-Deployment.md | 84 +++++ wiki/concepts/Break-the-Build.md | 64 ++++ wiki/concepts/Bug-Bounty.md | 63 ++++ wiki/concepts/Business-Impact-Analysis.md | 102 +++++ wiki/concepts/CMDB.md | 68 ++++ wiki/concepts/Canary-Release.md | 63 ++++ wiki/concepts/Centralized-Logging.md | 38 ++ wiki/concepts/Change-Management.md | 69 ++++ wiki/concepts/Cloud-Adoption-Strategy.md | 181 ++++++--- wiki/concepts/Cloud-Cost-Optimization.md | 73 ++++ wiki/concepts/Cloud-Governance.md | 68 ++++ wiki/concepts/Cloud-Maturity-Levels.md | 215 +++++++---- wiki/concepts/Cloud-Native-Maturity-Model.md | 134 +++++++ wiki/concepts/Cloud-Native.md | 173 +++++++-- wiki/concepts/Cloud-Operating-Model.md | 125 +++++++ .../concepts/Cloud-Security-Maturity-Model.md | 148 ++++++++ wiki/concepts/Compliance-Automation.md | 69 ++++ wiki/concepts/Configuration-Management.md | 72 ++++ wiki/concepts/Cron定时任务.md | 98 +++++ wiki/concepts/Cross-Account-Monitoring.md | 45 +++ wiki/concepts/DAST.md | 64 ++++ wiki/concepts/DRaaS.md | 77 ++++ wiki/concepts/Data-Governance.md | 74 ++++ wiki/concepts/Deployment-Automation.md | 75 ++++ wiki/concepts/Deployment-vs-Release.md | 102 +++++ wiki/concepts/DevSecOps.md | 86 +++-- wiki/concepts/Docker-Compose.md | 56 +++ wiki/concepts/Docker-用户组.md | 38 ++ wiki/concepts/Event-Correlation.md | 85 +++++ wiki/concepts/Exporter.md | 64 ++++ wiki/concepts/Failover.md | 57 +++ wiki/concepts/Feature-Flag.md | 123 +++++++ wiki/concepts/FinOps.md | 105 ++++++ wiki/concepts/GPG-密钥验证.md | 42 +++ wiki/concepts/Gatekeeper.md | 69 ++++ wiki/concepts/Green-Computing.md | 74 ++++ wiki/concepts/Hybrid-Cloud.md | 198 ++++++++++ wiki/concepts/Hyperautomation.md | 61 +++ wiki/concepts/IAST.md | 76 ++++ wiki/concepts/IP纯净度.md | 58 +++ wiki/concepts/ISOHybrid镜像.md | 35 ++ wiki/concepts/ITSM-2.0.md | 56 +++ wiki/concepts/ITSM.md | 54 +++ wiki/concepts/Immutable-Infrastructure.md | 75 ++++ wiki/concepts/Incident-Management.md | 74 ++++ wiki/concepts/Infrastructure-as-Code.md | 1 + wiki/concepts/Intentional-Cloud-Strategy.md | 105 ++++++ wiki/concepts/JFFS双清.md | 33 ++ wiki/concepts/Kill-Switch.md | 101 +++++ wiki/concepts/Micro-Recovery.md | 93 +++++ wiki/concepts/Multi-Account-Deployment.md | 48 +++ wiki/concepts/Multi-Cloud-Strategy.md | 220 +++++------ wiki/concepts/Multi-Tenancy.md | 75 ++++ wiki/concepts/Multi-factor-Authentication.md | 62 ++++ wiki/concepts/NFS网络备份.md | 46 +++ wiki/concepts/NVMe硬盘分区.md | 37 ++ wiki/concepts/OWASP-Top-Ten.md | 106 ++++++ wiki/concepts/Pay-as-you-go.md | 55 +++ wiki/concepts/Penetration-Testing.md | 81 ++++ wiki/concepts/Policy-as-Code.md | 75 ++++ wiki/concepts/Predictive-Maintenance.md | 69 ++++ wiki/concepts/Private-Cloud.md | 144 ++++++++ wiki/concepts/Problem-Management.md | 63 ++++ wiki/concepts/Progressive-Rollout.md | 106 ++++++ wiki/concepts/PromQL.md | 83 +++++ wiki/concepts/Prometheus告警规则.md | 116 ++++++ wiki/concepts/Public-Cloud.md | 129 +++++++ wiki/concepts/RPO.md | 91 +++++ wiki/concepts/RTO.md | 81 ++++ wiki/concepts/Release-Management.md | 68 ++++ wiki/concepts/Rightsizing.md | 79 ++++ wiki/concepts/Root-Cause-Analysis.md | 71 ++++ wiki/concepts/SAST.md | 52 +++ wiki/concepts/SCA.md | 71 ++++ wiki/concepts/Security-and-Compliance.md | 72 ++++ wiki/concepts/Self-Healing-Systems.md | 73 ++++ wiki/concepts/Serverless-Computing.md | 76 ++++ wiki/concepts/Shared-Responsibility-Model.md | 174 +++++++++ wiki/concepts/Shift-Left-Security.md | 56 +++ wiki/concepts/Shift-Right-Security.md | 50 +++ wiki/concepts/Socket-登录.md | 36 ++ .../Software-Assurance-Maturity-Model.md | 134 +++++++ .../StackSets-Deployment-Visibility.md | 57 +++ wiki/concepts/Threat-Modeling.md | 72 ++++ wiki/concepts/UEFI-Only.md | 34 ++ wiki/concepts/UEFI启动.md | 42 +++ wiki/concepts/Vulnerability-Scanning.md | 69 ++++ wiki/concepts/What-If-Simulation.md | 78 ++++ wiki/concepts/Zero-Trust-Architecture.md | 67 ++++ wiki/concepts/cloud-security.md | 162 ++++++-- wiki/concepts/efibootmgr.md | 40 ++ wiki/concepts/launchd.md | 111 ++++++ wiki/concepts/nas套件管理.md | 82 +++++ wiki/concepts/process-management.md | 39 ++ wiki/concepts/symbolic-link.md | 85 +++++ wiki/concepts/system-monitoring.md | 44 +++ wiki/concepts/systemd.md | 159 ++++++++ wiki/concepts/tui.md | 35 ++ wiki/concepts/云盘挂载.md | 72 ++++ wiki/concepts/全盘镜像备份.md | 52 +++ wiki/concepts/合成监控.md | 62 ++++ wiki/concepts/固件刷入.md | 25 ++ wiki/concepts/增量备份.md | 67 ++++ wiki/concepts/容器资源限制.md | 29 ++ wiki/concepts/容器重启策略.md | 26 ++ wiki/concepts/挂载点检查.md | 48 +++ wiki/concepts/指纹浏览器.md | 54 +++ wiki/concepts/接码平台.md | 66 ++++ wiki/concepts/故障转移.md | 28 ++ wiki/concepts/时序数据库.md | 57 +++ wiki/concepts/永久挂载.md | 83 +++++ wiki/concepts/用户权限.md | 44 +++ wiki/concepts/策略组分流.md | 33 ++ wiki/concepts/虚拟信用卡.md | 61 +++ wiki/concepts/裸机恢复.md | 36 ++ wiki/concepts/订阅机制.md | 36 ++ wiki/concepts/账号隔离.md | 67 ++++ wiki/concepts/跨境支付.md | 78 ++++ wiki/concepts/软链接策略.md | 120 ++++++ wiki/concepts/过渡固件.md | 28 ++ wiki/concepts/进程管理.md | 111 ++++++ wiki/entities/AWS-CloudFormation-StackSets.md | 39 ++ wiki/entities/AWS-Organizations.md | 46 +++ wiki/entities/AWS.md | 6 +- wiki/entities/Acronis.md | 80 ++++ wiki/entities/AdsPower.md | 33 ++ wiki/entities/Agentic-AI.md | 94 +++++ wiki/entities/Alertmanager.md | 75 ++++ wiki/entities/Amazon-CloudWatch-Logs.md | 53 +++ wiki/entities/Amazon-EventBridge.md | 47 +++ wiki/entities/BMC.md | 52 +++ wiki/entities/Claude-Pro.md | 37 ++ wiki/entities/Clonezilla.md | 64 ++++ wiki/entities/Cloud-Maturity-Model.md | 142 +++---- wiki/entities/Docker卷.md | 74 ++++ wiki/entities/GDPR.md | 62 ++++ wiki/entities/Grafana.md | 59 +++ wiki/entities/HIPAA.md | 57 +++ wiki/entities/HP-ZBook.md | 46 +++ wiki/entities/ISO-27001.md | 65 ++++ wiki/entities/KoolCenter固件服务器.md | 23 ++ wiki/entities/Kubernetes.md | 112 ++++++ wiki/entities/LaunchDarkly.md | 84 +++++ wiki/entities/Mac-Mini-M4.md | 98 +++++ wiki/entities/MariaDB.md | 69 ++++ wiki/entities/MerlinClash插件.md | 39 ++ wiki/entities/Navidrome.md | 59 +++ wiki/entities/Netdata.md | 76 ++++ .../Open-Alliance-for-Cloud-Adoption.md | 88 +++-- wiki/entities/PingMe.md | 37 ++ wiki/entities/Prometheus.md | 63 ++++ wiki/entities/Public-Cloud-Provider.md | 69 ++++ wiki/entities/Raj-Vardhan-Singh.md | 36 ++ wiki/entities/Rufus.md | 43 +++ wiki/entities/Terraform.md | 119 ++++++ wiki/entities/Ubuntu-Server.md | 154 ++++++++ wiki/entities/Uptime-Kuma.md | 64 ++++ wiki/entities/Veeam.md | 81 ++++ wiki/entities/VictoriaMetrics.md | 58 +++ wiki/entities/WildCard.md | 36 ++ wiki/entities/blackbox-exporter.md | 84 +++++ wiki/entities/bottom.md | 35 ++ wiki/entities/btop++.md | 41 +++ wiki/entities/cAdvisor.md | 67 ++++ wiki/entities/clouddrive2.md | 53 +++ wiki/entities/containerd.md | 28 ++ wiki/entities/docker-buildx-plugin.md | 22 ++ wiki/entities/docker-ce.md | 29 ++ wiki/entities/docker-compose-plugin.md | 35 ++ wiki/entities/docker-engine.md | 54 +++ wiki/entities/glances.md | 39 ++ wiki/entities/hello-world.md | 33 ++ wiki/entities/htop.md | 37 ++ wiki/entities/it-tools.md | 34 ++ wiki/entities/mission-center.md | 36 ++ wiki/entities/node-exporter.md | 70 ++++ wiki/entities/shenwei.md | 37 ++ wiki/entities/stacer.md | 40 ++ wiki/entities/机场.md | 32 ++ wiki/entities/梅林固件.md | 28 ++ wiki/entities/矿神源.md | 45 +++ wiki/entities/网件RAX50.md | 21 ++ wiki/frp.md | 142 +++++++ wiki/index.md | 68 ++-- wiki/log.md | 348 +++++++++++++++++- wiki/overview.md | 98 ++++- wiki/sources/3x-ui-xray-on-bandwagonvps.md | 60 +++ ...onezilla对ubuntu-server进行全盘镜像备份.md | 66 ++++ ...model-key-strategies-and-best-practices.md | 85 +++++ ...ow-agentic-ai-can-help-for-cloud-devops.md | 136 +++++++ ...d-logs-for-aws-cloudformation-stacksets.md | 86 +++++ wiki/sources/linux-运维必会的-150-个命令.md | 65 ++++ ...mac-mini-安装-frp-0-65-0-arm64-操作笔记.md | 81 ++++ ...建与解除-symbolic-link-openclaw-目录映射.md | 49 +++ wiki/sources/mysql-mariadb-数据库详细信息.md | 81 ++++ ...n-搬上-cloudflare-workers-彻底告别服务器.md | 87 +++++ ...e-vs-hybrid-cloud-differences-explained.md | 61 +++ .../rax50-路由器-更新merlin-clash订阅.md | 48 +++ ...ifferences-for-modern-disaster-recovery.md | 89 +++++ ...ceptions-about-cloud-computing-linkedin.md | 125 ++++--- ...t-you-monitor-system-resources-in-style.md | 63 ++++ wiki/sources/ubuntu-24-04-enable-ssh.md | 57 +++ .../ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md | 127 +++++++ .../ubuntu服务器通过rsync实现日常增量备份.md | 56 +++ wiki/sources/understanding-complete-itsm.md | 78 ++++ ...ecops-best-practices-benefits-and-tools.md | 112 ++++++ .../在synology-nas上安装clouddrive2.md | 42 +++ ...linux-服务器是-x64-也就是-x86_64-还是-arm64.md | 46 +++ ...在ubuntu-server安装-docker-docker-compose.md | 60 +++ ...纹浏览器安全注册并订阅claude-pro会员全攻略.md | 103 ++++++ ...装ubuntu-24-04-2在hp-zbook工作站笔记本上.md | 61 +++ ...theus-grafana-node-exporter-cadvisor-blackbox.md | 101 +++++ wiki/sources/用docker中安装navidrome.md | 49 +++ wiki/sources/用docker安装it-tools.md | 48 +++ wiki/sources/用docker安装transmission.md | 47 +++ ...x50路由器刷梅林固件与科学上网插件安装教程.md | 64 ++++ ...过vps-内网反向代理实现域名访问内网穿透.md | 89 +++++ wiki/内网穿透.md | 122 ++++++ wiki/反向代理.md | 149 ++++++++ wiki/桥接网络.md | 47 +++ wiki/端口映射.md | 43 +++ 232 files changed, 16604 insertions(+), 514 deletions(-) create mode 100644 openclaw/intent-ux-jakobnielsenphd-20260421.md create mode 100644 wiki/Caddy.md create mode 100644 wiki/LinuxServer.io.md create mode 100644 wiki/PUID-PGID.md create mode 100644 wiki/TCP隧道.md create mode 100644 wiki/Transmission.md create mode 100644 wiki/concepts/AI-ChatOps.md create mode 100644 wiki/concepts/APT-仓库配置.md create mode 100644 wiki/concepts/Asset-Management.md create mode 100644 wiki/concepts/Automated-Security-Audit.md create mode 100644 wiki/concepts/Blue-Green-Deployment.md create mode 100644 wiki/concepts/Break-the-Build.md create mode 100644 wiki/concepts/Bug-Bounty.md create mode 100644 wiki/concepts/Business-Impact-Analysis.md create mode 100644 wiki/concepts/CMDB.md create mode 100644 wiki/concepts/Canary-Release.md create mode 100644 wiki/concepts/Centralized-Logging.md create mode 100644 wiki/concepts/Change-Management.md create mode 100644 wiki/concepts/Cloud-Cost-Optimization.md create mode 100644 wiki/concepts/Cloud-Governance.md create mode 100644 wiki/concepts/Cloud-Native-Maturity-Model.md create mode 100644 wiki/concepts/Cloud-Operating-Model.md create mode 100644 wiki/concepts/Cloud-Security-Maturity-Model.md create mode 100644 wiki/concepts/Compliance-Automation.md create mode 100644 wiki/concepts/Configuration-Management.md create mode 100644 wiki/concepts/Cron定时任务.md create mode 100644 wiki/concepts/Cross-Account-Monitoring.md create mode 100644 wiki/concepts/DAST.md create mode 100644 wiki/concepts/DRaaS.md create mode 100644 wiki/concepts/Data-Governance.md create mode 100644 wiki/concepts/Deployment-Automation.md create mode 100644 wiki/concepts/Deployment-vs-Release.md create mode 100644 wiki/concepts/Docker-Compose.md create mode 100644 wiki/concepts/Docker-用户组.md create mode 100644 wiki/concepts/Event-Correlation.md create mode 100644 wiki/concepts/Exporter.md create mode 100644 wiki/concepts/Failover.md create mode 100644 wiki/concepts/Feature-Flag.md create mode 100644 wiki/concepts/FinOps.md create mode 100644 wiki/concepts/GPG-密钥验证.md create mode 100644 wiki/concepts/Gatekeeper.md create mode 100644 wiki/concepts/Green-Computing.md create mode 100644 wiki/concepts/Hybrid-Cloud.md create mode 100644 wiki/concepts/Hyperautomation.md create mode 100644 wiki/concepts/IAST.md create mode 100644 wiki/concepts/IP纯净度.md create mode 100644 wiki/concepts/ISOHybrid镜像.md create mode 100644 wiki/concepts/ITSM-2.0.md create mode 100644 wiki/concepts/ITSM.md create mode 100644 wiki/concepts/Immutable-Infrastructure.md create mode 100644 wiki/concepts/Incident-Management.md create mode 100644 wiki/concepts/Intentional-Cloud-Strategy.md create mode 100644 wiki/concepts/JFFS双清.md create mode 100644 wiki/concepts/Kill-Switch.md create mode 100644 wiki/concepts/Micro-Recovery.md create mode 100644 wiki/concepts/Multi-Account-Deployment.md create mode 100644 wiki/concepts/Multi-Tenancy.md create mode 100644 wiki/concepts/Multi-factor-Authentication.md create mode 100644 wiki/concepts/NFS网络备份.md create mode 100644 wiki/concepts/NVMe硬盘分区.md create mode 100644 wiki/concepts/OWASP-Top-Ten.md create mode 100644 wiki/concepts/Pay-as-you-go.md create mode 100644 wiki/concepts/Penetration-Testing.md create mode 100644 wiki/concepts/Policy-as-Code.md create mode 100644 wiki/concepts/Predictive-Maintenance.md create mode 100644 wiki/concepts/Private-Cloud.md create mode 100644 wiki/concepts/Problem-Management.md create mode 100644 wiki/concepts/Progressive-Rollout.md create mode 100644 wiki/concepts/PromQL.md create mode 100644 wiki/concepts/Prometheus告警规则.md create mode 100644 wiki/concepts/Public-Cloud.md create mode 100644 wiki/concepts/RPO.md create mode 100644 wiki/concepts/RTO.md create mode 100644 wiki/concepts/Release-Management.md create mode 100644 wiki/concepts/Rightsizing.md create mode 100644 wiki/concepts/Root-Cause-Analysis.md create mode 100644 wiki/concepts/SAST.md create mode 100644 wiki/concepts/SCA.md create mode 100644 wiki/concepts/Security-and-Compliance.md create mode 100644 wiki/concepts/Self-Healing-Systems.md create mode 100644 wiki/concepts/Serverless-Computing.md create mode 100644 wiki/concepts/Shared-Responsibility-Model.md create mode 100644 wiki/concepts/Shift-Left-Security.md create mode 100644 wiki/concepts/Shift-Right-Security.md create mode 100644 wiki/concepts/Socket-登录.md create mode 100644 wiki/concepts/Software-Assurance-Maturity-Model.md create mode 100644 wiki/concepts/StackSets-Deployment-Visibility.md create mode 100644 wiki/concepts/Threat-Modeling.md create mode 100644 wiki/concepts/UEFI-Only.md create mode 100644 wiki/concepts/UEFI启动.md create mode 100644 wiki/concepts/Vulnerability-Scanning.md create mode 100644 wiki/concepts/What-If-Simulation.md create mode 100644 wiki/concepts/Zero-Trust-Architecture.md create mode 100644 wiki/concepts/efibootmgr.md create mode 100644 wiki/concepts/launchd.md create mode 100644 wiki/concepts/nas套件管理.md create mode 100644 wiki/concepts/process-management.md create mode 100644 wiki/concepts/symbolic-link.md create mode 100644 wiki/concepts/system-monitoring.md create mode 100644 wiki/concepts/systemd.md create mode 100644 wiki/concepts/tui.md create mode 100644 wiki/concepts/云盘挂载.md create mode 100644 wiki/concepts/全盘镜像备份.md create mode 100644 wiki/concepts/合成监控.md create mode 100644 wiki/concepts/固件刷入.md create mode 100644 wiki/concepts/增量备份.md create mode 100644 wiki/concepts/容器资源限制.md create mode 100644 wiki/concepts/容器重启策略.md create mode 100644 wiki/concepts/挂载点检查.md create mode 100644 wiki/concepts/指纹浏览器.md create mode 100644 wiki/concepts/接码平台.md create mode 100644 wiki/concepts/故障转移.md create mode 100644 wiki/concepts/时序数据库.md create mode 100644 wiki/concepts/永久挂载.md create mode 100644 wiki/concepts/用户权限.md create mode 100644 wiki/concepts/策略组分流.md create mode 100644 wiki/concepts/虚拟信用卡.md create mode 100644 wiki/concepts/裸机恢复.md create mode 100644 wiki/concepts/订阅机制.md create mode 100644 wiki/concepts/账号隔离.md create mode 100644 wiki/concepts/跨境支付.md create mode 100644 wiki/concepts/软链接策略.md create mode 100644 wiki/concepts/过渡固件.md create mode 100644 wiki/concepts/进程管理.md create mode 100644 wiki/entities/AWS-CloudFormation-StackSets.md create mode 100644 wiki/entities/AWS-Organizations.md create mode 100644 wiki/entities/Acronis.md create mode 100644 wiki/entities/AdsPower.md create mode 100644 wiki/entities/Agentic-AI.md create mode 100644 wiki/entities/Alertmanager.md create mode 100644 wiki/entities/Amazon-CloudWatch-Logs.md create mode 100644 wiki/entities/Amazon-EventBridge.md create mode 100644 wiki/entities/BMC.md create mode 100644 wiki/entities/Claude-Pro.md create mode 100644 wiki/entities/Clonezilla.md create mode 100644 wiki/entities/Docker卷.md create mode 100644 wiki/entities/GDPR.md create mode 100644 wiki/entities/Grafana.md create mode 100644 wiki/entities/HIPAA.md create mode 100644 wiki/entities/HP-ZBook.md create mode 100644 wiki/entities/ISO-27001.md create mode 100644 wiki/entities/KoolCenter固件服务器.md create mode 100644 wiki/entities/Kubernetes.md create mode 100644 wiki/entities/LaunchDarkly.md create mode 100644 wiki/entities/Mac-Mini-M4.md create mode 100644 wiki/entities/MariaDB.md create mode 100644 wiki/entities/MerlinClash插件.md create mode 100644 wiki/entities/Navidrome.md create mode 100644 wiki/entities/Netdata.md create mode 100644 wiki/entities/PingMe.md create mode 100644 wiki/entities/Prometheus.md create mode 100644 wiki/entities/Public-Cloud-Provider.md create mode 100644 wiki/entities/Raj-Vardhan-Singh.md create mode 100644 wiki/entities/Rufus.md create mode 100644 wiki/entities/Terraform.md create mode 100644 wiki/entities/Ubuntu-Server.md create mode 100644 wiki/entities/Uptime-Kuma.md create mode 100644 wiki/entities/Veeam.md create mode 100644 wiki/entities/VictoriaMetrics.md create mode 100644 wiki/entities/WildCard.md create mode 100644 wiki/entities/blackbox-exporter.md create mode 100644 wiki/entities/bottom.md create mode 100644 wiki/entities/btop++.md create mode 100644 wiki/entities/cAdvisor.md create mode 100644 wiki/entities/clouddrive2.md create mode 100644 wiki/entities/containerd.md create mode 100644 wiki/entities/docker-buildx-plugin.md create mode 100644 wiki/entities/docker-ce.md create mode 100644 wiki/entities/docker-compose-plugin.md create mode 100644 wiki/entities/docker-engine.md create mode 100644 wiki/entities/glances.md create mode 100644 wiki/entities/hello-world.md create mode 100644 wiki/entities/htop.md create mode 100644 wiki/entities/it-tools.md create mode 100644 wiki/entities/mission-center.md create mode 100644 wiki/entities/node-exporter.md create mode 100644 wiki/entities/shenwei.md create mode 100644 wiki/entities/stacer.md create mode 100644 wiki/entities/机场.md create mode 100644 wiki/entities/梅林固件.md create mode 100644 wiki/entities/矿神源.md create mode 100644 wiki/entities/网件RAX50.md create mode 100644 wiki/frp.md create mode 100644 wiki/sources/3x-ui-xray-on-bandwagonvps.md create mode 100644 wiki/sources/clonezilla对ubuntu-server进行全盘镜像备份.md create mode 100644 wiki/sources/cloud-operating-model-key-strategies-and-best-practices.md create mode 100644 wiki/sources/how-agentic-ai-can-help-for-cloud-devops.md create mode 100644 wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md create mode 100644 wiki/sources/linux-运维必会的-150-个命令.md create mode 100644 wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md create mode 100644 wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md create mode 100644 wiki/sources/mysql-mariadb-数据库详细信息.md create mode 100644 wiki/sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md create mode 100644 wiki/sources/public-vs-private-vs-hybrid-cloud-differences-explained.md create mode 100644 wiki/sources/rax50-路由器-更新merlin-clash订阅.md create mode 100644 wiki/sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md create mode 100644 wiki/sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md create mode 100644 wiki/sources/ubuntu-24-04-enable-ssh.md create mode 100644 wiki/sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md create mode 100644 wiki/sources/ubuntu服务器通过rsync实现日常增量备份.md create mode 100644 wiki/sources/understanding-complete-itsm.md create mode 100644 wiki/sources/what-is-devsecops-best-practices-benefits-and-tools.md create mode 100644 wiki/sources/在synology-nas上安装clouddrive2.md create mode 100644 wiki/sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md create mode 100644 wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md create mode 100644 wiki/sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md create mode 100644 wiki/sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md create mode 100644 wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md create mode 100644 wiki/sources/用docker中安装navidrome.md create mode 100644 wiki/sources/用docker安装it-tools.md create mode 100644 wiki/sources/用docker安装transmission.md create mode 100644 wiki/sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md create mode 100644 wiki/sources/通过vps-内网反向代理实现域名访问内网穿透.md create mode 100644 wiki/内网穿透.md create mode 100644 wiki/反向代理.md create mode 100644 wiki/桥接网络.md create mode 100644 wiki/端口映射.md diff --git a/openclaw/intent-ux-jakobnielsenphd-20260421.md b/openclaw/intent-ux-jakobnielsenphd-20260421.md new file mode 100644 index 00000000..17c7fb9b --- /dev/null +++ b/openclaw/intent-ux-jakobnielsenphd-20260421.md @@ -0,0 +1,291 @@ +> **Summary**: AI is not just a better chat box. It changes the user’s role from operator to supervisor, which forces UX to move from command-based interaction toward intent-based delegation, new usability metrics, orchestration layers, calibrated friction, and ultimately exploration-based interaction to clarify the user’s needs. + +The most important thing about AI as an interface is not that it chats in natural language. It is that it changes the user’s *role*. AI changes computing from command-based interaction to intent-based outcome specification: the user states the result to be achieved, and the system determines the procedure. + +In **batch** systems, the user submitted the whole workflow at once. In **command** -based systems, the user and computer alternated turns. In **intent** -based systems, the AI will infer and execute the workflow itself: You no longer tell the computer *how*. You tell it *what* you want accomplished, and it figures out the rest. + +![](https://substackcdn.com/image/fetch/$s_!tLGV!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7329d00a-67bb-4d25-aa62-3e4fe5cf932e_937x522.jpeg) + +*In command-based interaction, you strike every blow (click every icon) to gradually produce what you want, inspecting and correcting the intermediate work product at every step. (NotebookLM)* + +![](https://substackcdn.com/image/fetch/$s_!A_il!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F30e034fd-610f-4209-862e-7350075afa1d_937x522.jpeg) + +*Intent-based outcome specification is similar to how a Viking jarl (chief) would order, “get me silver from an English monastery,” setting in motion a chain of events that starts with the weaponsmith making the shields and ending with the raid. He doesn’t have to specify these steps because the Vikings already know what to do. Using AI is the same. (NotebookLM)* + +An **intent** is not merely a wish expressed in natural language. A usable intent has at least three parts: the desired outcome, the constraints that bound acceptable behavior, and the delegation boundary that defines what the system is allowed to do. “Plan my Chicago trip” is underspecified unless the AI also knows the budget, the immovable meetings, and whether it may purchase tickets or only prepare options. Much of AI UX will therefore consist of helping users express not only what they want, but what the system is allowed to assume, optimize, and execute. + +Intent-driven interaction shifts the locus of control rather than being a cosmetic change in input modality. While the [GUI was a massive leap](https://www.uxtigers.com/post/gui-history), the shift from typing commands to clicking them was much smaller than the AI-driven change in interaction design. As I pointed out when I [identified intent-based outcome specification](https://www.uxtigers.com/post/ai-new-ui-paradigm) as the AI interaction modality at the dawn of modern AI in May 2023, this is an **entirely new UI paradigm**, and the first major shift in 60 years since we changed from batch processing to commands. + +With a paradigm change in the UI, it stands to reason that we also need a paradigm shift in design and usability. What users do is being flipped, and UX must change with our users. AI changes the *interaction grammar* more than it changes any one screen: intent-based interaction is not just a new input method. It changes **where decisions happen**, **who bears the cognitive load**, and **what “error” means**. + +In command-based interfaces (including GUIs), the human forms a plan internally and then executes it through controls. We’ve had the design goal to make the computer “transparent” precisely because it stays inside the user’s plan. This is one reason direct manipulation felt so powerful: operating on visible objects with immediate feedback let users focus on tasks rather than on the system. + +In intent-based interfaces, the user externalizes part of the plan: they are no longer navigating, but delegating. The system must now interpret the goal, choose subgoals, schedule actions, acquire permissions, and handle exceptions. That pushes the system into a classic automation role, which human factors research has studied for decades: once automation takes over planning and action selection, the user shifts from operator to supervisor. Supervisory control has different failure modes than direct manipulation, and it demands different design safeguards. + +![](https://substackcdn.com/image/fetch/$s_!JMPX!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1c13b6e7-c99a-495a-ae45-b75dd4003d61_937x1046.jpeg) + +*Users are changing from doing the work (operating the UI) to supervising the work. (NotebookLM)* + +The winning system of the next decade will not be the one with the most aesthetically pleasing buttons, nor will it be the one with the fewest screens. It will be the system that best understands the human’s “job to be done,” autonomously selects the right tools on their behalf, clearly shows the user what is about to happen, and gracefully recovers when the user’s context is incomplete or ambiguous. + +## The Three Eras of UX Goals + +UX design has never had one fixed goal. The goal has shifted twice already, and it’s shifting again. + +![](https://substackcdn.com/image/fetch/$s_!FXZx!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F26bccd85-1901-4438-8da7-5c780f3c5420_774x1295.jpeg) + +*The three goals of UX design: productivity, influence, and augmentation. (NotebookLM)* + +**Era 1, Business Computing (1960–1995).** The dominant applications were accounting software, word processors, payroll systems. The UX goal was **productivity**: help people learn the software faster, make fewer errors, get more done per hour. I used to tell clients that their training budget was a pork chop ready to be eaten by usability: a well-designed system could cut onboarding time in half. + +**Era 2, The Internet (1995–2025).** The web shifted the UX goal to **influence**: get users to buy, subscribe, share, or scroll long enough to see another ad. This era leaned heavily on [Robert Cialdini’s influence principles](https://www.uxtigers.com/post/explore-discover), such as reciprocity, social proof, scarcity. It also gave us [dark patterns](https://www.uxtigers.com/post/dark-design) and infinite scroll. If you don’t pay for the product, you *are* the product. + +**Era 3, AI (2026 onward).** The goal shifts again, to something harder to name: **augmenting human existence**. When AI handles execution of routine tasks, human energy is freed for imagination, judgment, and meaning-making. Doug Engelbart’s original vision was to “augment the human intellect.” That framing is too narrow now. The goal of UX in the AI era is to expand what humans can do and be, not only what we can accomplish in software, but what we can decide, imagine, and coordinate. Usability, therefore, shifts from removing friction in predetermined paths to expanding the range of viable paths, opening up possibilities we haven’t yet imagined. + +![](https://substackcdn.com/image/fetch/$s_!7zvl!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F384df653-fdd2-41d0-ae34-ed678a0a5b62_937x522.jpeg) + +*AI can help us reach new heights and explore fabulous new vistas. Our design goal is no longer simply productivity or selling; it’s augmenting human existence. (NotebookLM)* + +When I present this 3-stage process of changing UX goals, I often get pushback from naïve designers who resent the implication that the main goal of their existence has been to manipulate customers. However, while becoming master manipulators might not have been the reason they embarked on a design career as idealistic youngsters, it was what they needed to do to thrive in the Internet business environment. The reason companies pay for design is to get customers to buy more and users to look at more advertisements. + +In fact, one of the reasons I’m a big AI fan is that I never liked the business goals of Internet design. Of course, we’ll still need to persuade customers to buy. That will never change. But persuasion changes from manipulating humans by exploiting our many cognitive biases and weaknesses to providing clean information to AI agents that will do the buying. + +## The Short-Term Crisis: The Articulation Barrier + +Current chat-based AI interfaces suffer from severe usability problems. The intent-based paradigm demands that users write out their problems as prose text. However, as repeatedly demonstrated by literacy research, about half the population in rich countries like the United States and Germany is classified as low-literacy users, with results being even worse in poor countries. + +Writing new descriptive prose is cognitively more challenging than reading existing text. This creates an immense [articulation barrier](https://www.uxtigers.com/post/ai-articulation-barrier). It gives a massive advantage to the small fraction of the population with extraordinarily strong literacy skills. The very existence of “prompt engineering” advice is empirical evidence of this deep-rooted usability failure. If users are forced to learn arcane methods to tickle an AI into coughing up the right result, the interface fails human-centered design standards. + +![](https://substackcdn.com/image/fetch/$s_!sDuT!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6a49bdcc-d5ef-4ac2-a33c-375c3aaa034f_937x522.jpeg) + +*The articulation barrier is the problem of making your intent clear. It’s often hard to put something into words, especially if the goal is inherently nonverbal, like the shape of something, or if the user has low literacy skills. (NotebookLM)* + +In the short term, UX professionals must design to overcome this articulation barrier. We cannot rely on users generating perfect text from a blank canvas. [Prompt augmentation](https://www.uxtigers.com/post/prompt-augmentation) and [aided prompt understanding](https://www.uxtigers.com/post/prompt-understanding) are two sets of design patterns to help users refine their intent for AI. + +![](https://substackcdn.com/image/fetch/$s_!-4ow!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8333123e-7731-4b84-88c0-fba6d97b903a_937x522.jpeg) + +*Style galleries are one of the design patterns for prompt augmentation. It’s easier to select something you like from a range of styles than it is to describe the style in words. (NotebookLM)* + +The articulation barrier is also a memory problem. If users must restate their preferences, recurring constraints, tone of voice, risk tolerance, and exceptions in every session, the interface remains unusable no matter how fluent the model sounds. A mature intent-based system, therefore, needs a visible, editable user model: a place where people can inspect what the AI believes about them, correct it, override it temporarily, or tell it to forget. In the AI era, memory becomes a first-class UX surface. + +In the long run, we need a new approach to designing intent-based interactions. + +## Redefining Usability Metrics + +Because the locus of control has reversed, the [core usability metrics](https://www.uxtigers.com/post/what-is-ux) we have used for decades to evaluate UX must be completely rewritten. In the command-based paradigm, usability was measured by how efficiently a user could learn and execute the steps to accomplish a task. My [ten classic heuristics](https://www.uxtigers.com/post/10-heuristics-reimagined) assumed a human navigating a structured interface one step at a time. + +In an intent-based ecosystem, the [system acts probabilistically](https://www.uxtigers.com/post/ai-uncertainty-ux) rather than deterministically. Usability is no longer judged by the elegance of the steps on screen, but by the quality of the machine’s understanding and the safety of its execution. + +My classic usability heuristics will still hold, but must be reinterpreted. “Visibility of system status” used to mean: show progress through a sequence of steps the user chose. In an agentic workflow, it becomes: show *what the system believes the user intends*, what it is doing to satisfy that intention, and what it plans to do next, even when none of those steps were explicitly requested. “User control and freedom” used to mean: allow undo, cancel, and escape from a dialog or flow. In an intent-based environment, it becomes: allow interruption of an executing plan, allow correction of misunderstood intent, and allow safe rollback across multiple systems. Undo is harder when the system has already sent an email, booked a ticket, or modified a shared document. The old principle becomes more important, but also more expensive to implement. + +The evaluation of a successful interface shifts: + +- **From Discoverability to Intent Capture:** Can the system accurately map a vague natural-language request to a highly structured machine action? Did it infer the goal, constraints, and priorities correctly? +- **From Error Prevention to Clarification Quality:** Because we cannot [disable invalid buttons](https://www.uxtigers.com/post/inactive-buttons) to prevent hallucination, the metric shifts to how gracefully the system handles ambiguity. Does the system ask the right follow-up questions at the right time? The best clarifying question is the smallest intervention that prevents the largest mistake. +- **From “Time to Learn” to “Ease of Delegation”:** Traditional UI learnability becomes less relevant when there are no menu hierarchies to understand and navigate. The primary metric becomes how comfortably a user can delegate a multi-step objective without fearing catastrophic failure. Time-to-correct becomes far more important. +- **From Execution Efficiency to Verification Efficiency (Evaluability):** In command-based UIs, the user’s primary cognitive load was executing the task step-by-step. In intent-based systems, *execution* is cheap, but *evaluation* becomes the bottleneck. The usability metric shifts to how rapidly and accurately a user can verify that the AI’s output matches their actual goal. Interfaces must be optimized for “evaluability,” allowing users to judge quality and appropriateness (whether the AI’s work is fit for its external purpose) without painstakingly combing through every detail of the result. + +![](https://substackcdn.com/image/fetch/$s_!2N61!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0522bf33-3445-42d9-a598-b7e02afb8656_937x522.jpeg) + +*Changing the usability goal from making it easy to make something to making it easy to evaluate the quality and suitability of what was made. (NotebookLM)* + +- **From Visibility of System Status to Execution Transparency:** The system must project an accurate mental model of its operational plan *before* and *during* execution. It must show what it believes the user intends and what it plans to do next. +- **From User Satisfaction to Trust Calibration:** Do users rely on the agent appropriately, neither over-trusting nor under-using it? Trust is no longer a soft emotional byproduct; it is the primary functional metric of an intent-based system. Trust calibration also depends on showing why the system preferred one plan over another. A good orchestration UI should be able to say, in effect, “I chose Plan A over Plan B because cost mattered more than speed,” or “This recommendation would change if your deadline moved by two days.” Counterfactual explanation is often more useful than a generic confidence score because it teaches users the model’s decision logic and shows where intervention would matter. + +![](https://substackcdn.com/image/fetch/$s_!fNSM!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F521dae34-3c0b-4be0-8269-c44afd059711_937x522.jpeg) + +*How much do you trust your AI agent? Do you want to give it your entire sack of silver, or just a coin or two? (NotebookLM)* + +These changes imply a different UX measurement toolkit. *Time-on-task* is less important when the human contribution is “say what you want” (and the AI then spends hours performing the task), but *time-to-correct* becomes a central metric. Traditional *error counts* must be split into user slips versus system misinterpretations. *Satisfaction* becomes increasingly bound to perceived agency: users can be pleased with outcomes but still feel uneasy if they cannot tell what happened or why. + +## The Triple-Layered Design Model + +At first glance, [“UI is dead,”](https://www.uxtigers.com/post/ux-roundup-20250825) since users will interact with AI agents more than they’ll be clicking around apps or websites. + +However, the GUI will not disappear; it will be demoted. The screen stops being the place where work *begins*, and instead becomes the place where work is inspected, negotiated, and corrected. As software shifts from isolated apps toward task orchestration, mature intent-based systems will settle into a triple-layered design model. + +![](https://substackcdn.com/image/fetch/$s_!UbJb!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fdbf40c96-43ef-4994-be87-ae108199c242_774x1295.jpeg) + +*The three layers of AI user experience architecture: intent, orchestration, and direct manipulation. (NotebookLM)* + +**1\. The Intent Surface:** This is the first layer, where the user states an outcome. It must be highly context-aware, accepting multimodal inputs like voice, text, screen context, or camera data to overcome the articulation barrier. As this layer matures, it will increasingly rely on **implicit intent inference**. By synthesizing ambient context (e.g, calendar events, active screen content, cursor hesitations, and historical routines), the system can proactively offer high-probability intents for the user to simply confirm, overcoming the articulation barrier by drafting the prompt for them. + +**2\. The Orchestration Surface:** This is the critical negotiation layer. Before an agent executes high-stakes actions, it must reveal its proposed plan, expose the provenance of its data, and seek consent. This UI functions as an audit layer. It visualizes steps, provides execution transparency, and manages “permission choreography.” Preview is not enough. Intent-based systems also need explicit post-action receipts. After an agent completes a task, the UI should summarize what it changed, which systems it touched, what assumptions it used, and what can still be undone. In traditional GUIs, the user often knew what happened because they executed each step themselves. In agentic systems, that implicit knowledge disappears. The system must manufacture legibility after the fact. + +Most important work is not solitary. In organizations, the agent acts inside shared systems, shared budgets, and shared responsibilities. The orchestration layer must therefore show not only what it plans to do for *me*, but also *who else* will be affected, which policies constrain the action, and who inherits the consequences. Intent in enterprise UX is never just personal preference; it is personal preference filtered through institutional rules. The Orchestration surface must therefore resolve **collaborative intent** by flagging conflicting directives from multiple human stakeholders or specialized AI sub-agents, and negotiating consensus before execution. Recognizing the need to support and coordinate multiple users, rather than just a single user, becomes more important in AI systems than in traditional GUI design. + +**3\. The Direct-Manipulation Surface:** The traditional GUI remains intact as a fallback layer. This is the familiar world of tapping, dragging, and scrubbing, reserved for edge-case editing, granular corrections, and emergency overrides. In a mature intent UI, the screen becomes where work is **inspected**, **negotiated**, and **corrected**, because the work itself is done off-screen by AI. + +Thus, [direct manipulation](https://www.uxtigers.com/post/direct-manipulation) does not die; it migrates one level higher in the abstraction stack. Instead of manipulating raw controls, users will manipulate *plans*. They will drag a task from “later” to “now,” scrub through a proposed sequence on a timeline, tap a source chip to check provenance, or reorder a travel itinerary. That is still direct manipulation, retaining the biological satisfaction of shaping causality, just applied at a higher level of abstraction. + +## Supervisory Control and Intentional Cognitive Friction + +Because of the phenomenological gap introduced by intent-based interfaces, in which actions occur offscreen without direct bodily involvement, the user’s role shifts profoundly. The correct analogy is no longer *driving* a car; it is *managing* a chauffeur. + +This supervisory control requires a completely different set of design principles. The instinct of every UX designer trained in the command-based era is to ruthlessly eradicate friction. For routine, low-stakes tasks (sorting spam, scheduling a recurring meeting), the frictionless ideal remains correct. But for high-stakes tasks (e.g., financial transactions, medical decisions, sending sensitive emails), the interface must intentionally slow the user down. + +Autonomy should be earned rather than granted all at once. An effective agent should begin in a conservative mode that drafts, prepares, and asks for confirmation, while accumulating a performance history inside a bounded domain. As reliability becomes evident, the interface can let the user widen the agent’s action budget: first draft, then prepare, then execute low-risk actions, and only later touch high-stakes or externally visible systems. The right model is not binary autonomy versus manual control. It is progressive delegation. + +We must choreograph *intentional cognitive friction*. Generative AI often delivers synthesized answers that feel flawlessly authoritative, leading to the Plausibility Trap. Because the interface is clean and instant, authority bias takes over, tempting the user to skip critical analysis. + +To combat this dangerous automation bias, we must force a moment of reflection. When an AI proposes moving $500, we should not offer a frictionless “Approve All” button. We must use granular authorization, artificial time delays (like a three-second countdown), and provenance highlighting to ensure the human remains cognitively responsible for the outcome. + +![](https://substackcdn.com/image/fetch/$s_!lMwU!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe00598d5-ce03-490f-8ed8-9354c4636f96_937x522.jpeg) + +*At appropriate points in the workflow, make the user pause to ensure everything is right. (NotebookLM)* + +Friction shouldn’t just be a blanket delay; it should be applied surgically. The UX must visually communicate the AI’s confidence levels so the user knows exactly where to apply their cognitive effort. We need Epistemic UIs: interfaces that visually map the system’s uncertainty. Instead of presenting synthesized answers as monolithic, authoritative truths, the UI should highlight probabilistic leaps, flag data with weak provenance, and color-code confidence levels. By visualizing the AI’s own doubt, the interface directs human cognitive energy precisely to the areas requiring judgment, transforming friction from a blunt delay into a precision tool. + +![](https://substackcdn.com/image/fetch/$s_!mX5O!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc34f8f5c-e0c8-4c6c-8393-b1ba30c84cdd_937x522.jpeg) + +*Epistemic UI: when we don’t know what lies ahead (for example, what creature made this footprint), we should be explicit about our level of uncertainty to improve decision quality. (NotebookLM)* + +Naturally, the threshold for this friction must be deeply context-aware. A $500 transfer requires high friction in a personal banking app, but is a frictionless, automated rounding error for a corporate finance AI. Just as human organizations use escalating approval ladders for larger expenditures, AI UX must dynamically scale cognitive friction based on the user’s role, the organization’s risk tolerance, and the reversibility of the action. We will simply tweak traditional management heuristics to account for the unique vulnerabilities of machine intelligence. + +User experience for AI agents will be similar to traditional management techniques in many cases. Similar, not identical, of course: many existing management methods are intended to deal with managing human underlings who suffer from human weaknesses. When managing AI agents, we’ll tweak our old management lessons to account for AI’s weaknesses. + +## Slow AI: The Return of Zombie UX + +As we entrust AI with increasingly complex workflows, we face a bizarre blast from the past: the Zombie UX of batch processing is being revived. While simple chat queries take seconds, powerful AI tools like Deep Research or video-generation models can take 10 minutes to hours to complete a run. We are rapidly approaching a reality where AI agents will run independently for 30 hours or even days to orchestrate massive tasks. + +When turn-taking interaction is destroyed by extreme delays, we must design for “ [Slow AI](https://www.uxtigers.com/post/slow-ai).” Waiting hours for results creates intense anxiety regarding whether the AI is heading in the right direction. + +![](https://substackcdn.com/image/fetch/$s_!Fsa0!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fda4415bb-e6bb-4aec-93c7-ac5a403672a4_937x522.jpeg) + +*Sometimes AI takes forever to deliver results. We need to design for this reality, because it will only get worse with increasing AI capabilities and task horizons. (NotebookLM)* + +To maintain user control, Slow AI requires distinct UX interventions: + +**1\. Clarification and Run Contracts:** A slow AI should never guess a user’s intent. It must ask clarifying questions upfront. It should then present an explicit run contract showing the estimated time window, a cost cap, the definition of “done,” and hard boundaries (e.g., “will not email external parties”). We will need new usability research to replace our old response time guidelines + +**2\. Conceptual Breadcrumbs:** Traditional percentage bars are useless for 10-hour tasks. Instead of just showing technical logs, the AI must provide “Conceptual Breadcrumbs” as short, synthesized summaries of intermediate conclusions. If the AI reports a flawed conclusion early on, the user can intervene immediately. + +**3\. Context Reboarding:** When a task takes 30 hours, users will context switch and forget what they originally asked for. The UI must gracefully reboard the user with a Resumption Summary: reminding them of the original intent, key decisions made during the run, and the current status. + +**4\. Tiered Notifications:** We must employ context-aware attention management. Notifications should be tiered: immediate push notifications only for critical blocks requiring user intervention, low-priority emails for decisions that simply affect quality, and batched digests for task completions. + +**5\. Progressive Disclosure and Salvage Value:** Long-running tasks aggressively exacerbate the sunk cost fallacy. Users will accept substandard work simply because they waited 20 hours for it. The UI must progressively disclose partial results (rough outlines, wireframes) so users can course-correct early. Crucially, if a user stops a run, the UI must explicitly show the “salvage value” (which intermediate artifacts can be reused), making frictionless restarts less psychologically painful. + +![](https://substackcdn.com/image/fetch/$s_!ERCN!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd80fdd96-94b2-4120-a113-ac540395e365_937x522.jpeg) + +*Even when AI fails, you may be able to reuse part of what it did, reducing the pain of the sunk cost of an extended AI run. (NotebookLM)* + +## The Long-Term Vision: Exploring Latent Space + +Looking further ahead into the AI Era, [creativity shifts from making to discovery](https://www.uxtigers.com/post/explore-discover). We are moving away from **building** (pre-AI) and **describing** (current intent-based generation) toward **exploring** a latent solutions space created by AI. + +![](https://substackcdn.com/image/fetch/$s_!Grr-!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8ac199bc-411f-4b5b-bee2-8404644f6f78_937x522.jpeg) + +*Only as you are navigating through the latent space of AI options do you discover what is there and which turn you want to take next in the journey towards the as-yet unknown destination. (NotebookLM)* + +Since AI generates a thousand competent solutions in a minute, the user’s primary need is no longer production, but discovery. Iteration stops being mainly about fixing mistakes and becomes a way of exploring a multidimensional solution space. However, current UIs are far too linear, relying on the old-school “Back” button. The future of UX requires UI support for navigating a multi-branched exploration. We will need tools like “Look Lock” to freeze certain semantic styles or visual invariants while we explore adjacent dimensions. Future interfaces will feel less like pathways and more like collaborative playgrounds. + +**“Intent by discovery”** should become the future of human-AI interaction. Don’t assume that users know what they want. Help them recognize it progressively by reacting to alternatives, locking in what matters, and exploring adjacent possibilities. + +![](https://substackcdn.com/image/fetch/$s_!qqAD!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5eb68a90-083e-45c7-b467-52c344fb1988_937x522.jpeg) + +*Once you discover a new land, you may recognize it as your desired destination. (NotebookLM)* + +While highly effective, current design patterns for prompt augmentation are essentially putting training wheels on a text box. Prompt augmentation still forces the user through a linguistic bottleneck, assuming they *have* a specific intent but simply lack the vocabulary. To fully support intent by discovery, UX must abandon the chat box as the default AI interaction model and stretch into multi-modal, spatial, and behavioral paradigms. + +Here are my predictions for how UX design might evolve to support intent by discovery beyond simple prompting. + +## 1\. Spatial Navigation of Latent Space + +Currently, AI interfaces operate a bit like a slot machine: you pull the lever (prompt) and get a discrete result. In the future, UX will allow users to navigate the AI’s latent space (the multidimensional map of all possible solutions) visually and spatially. + +**Semantic Topographies:** Instead of typing “make the design more professional but slightly playful,” the user might be presented with an interactive 2D map of generated outputs. Dragging a cursor across this space morphs the output in real-time. The user discovers their intent by seamlessly exploring adjacent possibilities, stopping when the output simply “feels right.” Such visual exploration will require real-time AI generation of updated alternatives, and we’re luckily already seeing improved models that emphasize fast response time. + +**Divergent Routing:** Because humans are better at recognizing a solution than describing it, UIs will heavily leverage divergent generation. The AI generates edge-case variations and asks, “Better 1 or better 2?” The user’s selections iteratively narrow down the infinite possibility space through pure recognition, bypassing recall entirely. + +## 2\. Direct Object Manipulation (Blending GUI and AI) + +One of the major regressions of current chat-based AI is the loss of direct manipulation: the tactile tweaking we perfected in the GUI era. The future of intent by discovery will hybridize the two paradigms. + +Users will refine their intent by physically altering the AI’s output. If an AI generates a website mockup or a floor plan, and the user drags a hero image or a wall to make it larger, the AI doesn’t just register a coordinate change. It reverse-engineers the underlying intent (“Ah, the user prioritizes visual impact and open space”) and automatically adjusts the typography, lighting, or secondary elements to maintain coherence. The tactile action becomes the prompt. + +## 3\. Socratic Scaffolding + +To support discovery, the system must stop being a passive order taker waiting for a master prompt, and become an active interviewer. + +**Progressive Probing:** If a user’s initial intent is vague (“I need a strategy for a product launch”), the AI pauses instead of hallucinating a generic 10-page document. It responds with diagnostic questions or visual counterfactuals: “Are we optimizing for immediate revenue or long-term brand awareness?” By proactively presenting constraints, the AI helps the user chisel away at the marble until their exact intent is revealed. + +![](https://substackcdn.com/image/fetch/$s_!qHJB!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F708af64d-6e98-48b4-9f33-3d0b7913394b_937x522.jpeg) + +*The Greek philosopher Socrates famously taught his students by asking them questions. Similarly, AI can help users achieve their goals by asking insightful, probing questions. (NotebookLM)* + +## 4\. Ephemeral and Generative UIs + +We are accustomed to static interfaces where the controls (dropdowns, menus) are always the same. In an era of intent by discovery, [Generative UI](https://www.uxtigers.com/post/generative-ui-google) will make the interface itself on the fly based on the user’s emerging context. + +If the AI detects that a user is exploring the mood of a generated piece of music or the logic of a database schema, it will dynamically spawn bespoke UI controls (custom sliders, visual node-graphs, or reference boards) just for that specific moment of discovery. Once the intent is locked in, those specific UI controls dissolve. + +## 5\. Curation as Intent + +Text is a low-bandwidth way to communicate complex ideas, vibes, or aesthetics. Intent by discovery will increasingly rely on multimodal curation, similar to Midjourney’s Mood Boards. + +Instead of typing out a description, a user might dump a cluster of disorganized artifacts onto a digital canvas: a PDF of a competitor’s report, a color palette from a photograph, and a 10-second voice memo. The system organizes them, finds the conceptual overlaps, and synthesizes a starting point. The user discovers their intent by seeing how the AI conceptually connects their fragmented inspirations. + +![](https://substackcdn.com/image/fetch/$s_!cbFM!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F05b9bf4b-f0cb-48be-afe0-e8bdf05b08a7_937x522.jpeg) + +*As a Viking raider, you may discover that you like amber and arm rings by curating your preferred items from the loot. (NotebookLM)* + +## 6\. Subtractive Sculpting + +The current prompting paradigm is *additive*: the user builds an outcome by adding more words. But discovery is often much easier when it is *subtractive*. + +Future AI UX will frequently rely on generating an overwhelming, maximalist version of an artifact (a hyper-detailed document, a complex piece of code, a busy design). The user’s interaction model is then based on deleting, striking through, and whittling away the parts they don’t want. It is infinitely easier for a human to edit and remove than to generate from a blank screen. + +![](https://substackcdn.com/image/fetch/$s_!Kqti!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F86e00f09-5b00-4c39-9249-7d86e84a3e4f_937x522.jpeg) + +*Subtractive sculpting: start with something big and whittle away until only something much nicer remains. (NotebookLM)* + +## The Future Role of the UX Designer + +In this new paradigm, the role of the UX designer shifts dramatically. Instead of designing linear user flows (Screen A → Screen B → Screen C), designers will **architect** **possibility spaces**. + +They will design the boundary constraints, the physics of the latent space, and the feedback loops of these generative environments. Prompt augmentation is a vital bridge for the present moment, but by fully embracing my vision of “intent by discovery,” the UX of the future will treat AI not as a command-line terminal disguised as a chat window, but as a fluid, co-navigational environment where the need to write a “prompt” eventually disappears entirely. + +Yet, we must be cautious about the industry’s obsession with the zero-learning ideal. A utopian vision where users merely express a wish and the AI seamlessly executes it offscreen carries a hidden cost. If users never need to learn how a system works, navigate a hierarchy, or make decisions, they suffer cognitive offloading and deskilling. They become mere passengers in their digital lives, trapped in a “Cognitive Atrophy Loop” in which analytical engagement degrades. + +![](https://substackcdn.com/image/fetch/$s_!qT_Q!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F40f69b1f-3915-4216-a3cc-d4ebec8fed5f_937x522.jpeg) + +*If users have nothing to do, they risk cognitive atrophy from checking out and ignoring what goes on around them. (NotebookLM)* + +This is the ultimate imperative for UX professionals. Our designs must not act as cognitive wheelchairs that replace human agency; they must act as cognitive exoskeletons that support and enhance human flourishing, even as traditional work vanishes. Good AI UX will teach *just enough*, reveal plan structures, and leave a comprehensible trail of action so users can maintain digital judgment. + +What disappears is the assumption that the human is executing the tedious steps. We are entering a complex era of managing autonomous chauffeurs. The winning designs of the next decade will be those that understand the job to be done, orchestrate the solution transparently across a triple-layered interface, demand friction where stakes are high, and preserve unmistakable moments of human authority. + +Designing that delicate relationship of delegation without surrender is the great UX challenge of the next decade. Let’s get started. + +## Action Items + +If you’re designing AI interfaces now, here’s where to focus: + +- **Measure intent capture, not click efficiency.** Build evaluation frameworks around how accurately the system infers user goals, not how quickly users navigate menus that will no longer exist. +- **Design the orchestration layer.** The negotiation surface between intent and action is where trust is built or lost. Most teams are ignoring it. +- **Choreograph friction deliberately.** Map your task inventory by stakes. For high-stakes irreversible actions, friction is not a design failure, it’s safety. +- **Plan for slow tasks from day one.** Run contracts, conceptual breadcrumbs, and salvage-value disclosure are not edge cases. They’re core interaction patterns for anything that runs longer than a few minutes. +- **Resist the zero-learning trap.** Design systems that keep users cognitively engaged with what the AI is doing and why. Delegation without understanding is not empowerment. + +The command-based paradigm served us magnificently for sixty years. The heuristics and usability guidelines we developed for it represent genuine intellectual achievement. But the world is shifting under our feet, and the UX profession must shift with it: not by abandoning what we know, but by recognizing that the definition of usability itself is being rewritten. + +![](https://substackcdn.com/image/fetch/$s_!3MAp!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd5906a7d-df91-4555-9c66-84af0b05ed0d_937x937.jpeg) + +*Summary infographic. (NotebookLM)* + +## About the Author + +Jakob Nielsen, Ph.D., is a usability pioneer with [43 years experience in UX](https://www.uxtigers.com/post/41-years-in-ux) and the Founder of [UX Tigers](https://www.uxtigers.com/). He founded the discount usability movement for fast and cheap iterative design, including heuristic evaluation and the [10 usability heuristics](https://www.uxtigers.com/post/10-heuristics-reimagined). He formulated the eponymous [Jakob’s Law of the Internet User Experience](https://www.uxtigers.com/post/jakobs-law). Named “the king of usability” by *Internet Magazine*, “the guru of Web page usability” by *The New York Times*, and “the next best thing to a true time machine” by *USA Today*. + +Previously, Dr. Nielsen was a Sun Microsystems Distinguished Engineer and a Member of Research Staff at Bell Communications Research, the branch of Bell Labs owned by the Regional Bell Operating Companies. He is the author of 8 books, including the best-selling *Designing Web Usability: The Practice of Simplicity* (published in 22 languages), the foundational *Usability Engineering* ([30,073 citations in Google Scholar](https://scholar.google.com/citations?hl=en&user=y5uL3wUAAAAJ))*,* and the pioneering *Hypertext and Hypermedia* (published two years before the Web launched). + +Dr. Nielsen holds 79 United States patents, mainly on making the Internet easier to use. He received the Lifetime Achievement Award for Human–Computer Interaction Practice from ACM SIGCHI and was named a “Titan of Human Factors” by the Human Factors and Ergonomics Society. + +· Subscribe to [Jakob’s newsletter](https://jakobnielsenphd.substack.com/) to get the full text of new articles emailed to you as soon as they are published. + +· [Follow Jakob on LinkedIn](http://www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&followMember=jakobnielsenphd). + +· Read: [article about Jakob Nielsen’s career in UX](https://www.uxtigers.com/post/41-years-in-ux) + +· Watch: [Jakob Nielsen’s first 41 years in UX](https://www.youtube.com/watch?v=MPmVa_vKeF4) (8 min. video) \ No newline at end of file diff --git a/openclaw/openclaw备份任务.md b/openclaw/openclaw备份任务.md index 398a5848..e600be35 100644 --- a/openclaw/openclaw备份任务.md +++ b/openclaw/openclaw备份任务.md @@ -14,6 +14,9 @@ tags: [] | 日期 | 时间 | 服务器 | 备份文件 | 状态 | | ---------- | ----- | -------- | ------------------------------------ | ---- | +| 2026-04-21 | 22:00 | Mac Mini | openclaw-macmini-20260421220026.tar | ✅ 成功 | +| 2026-04-21 | 22:00 | Ubuntu1 | openclaw-ubuntu1-20260421220257.tar | ✅ 成功 | +| 2026-04-21 | 22:00 | Ubuntu2 | openclaw-ubuntu2-20260421220530.tar | ✅ 成功 | | 2026-04-20 | 22:00 | Mac Mini | openclaw-macmini-20260420220009.tar | ✅ 成功 | | 2026-04-20 | 22:00 | Ubuntu1 | openclaw-ubuntu1-20260420220049.tar | ✅ 成功 | | 2026-04-20 | 22:00 | Ubuntu2 | openclaw-ubuntu2-20260420220049.tar | ✅ 成功 | diff --git a/wiki/Caddy.md b/wiki/Caddy.md new file mode 100644 index 00000000..3499cfed --- /dev/null +++ b/wiki/Caddy.md @@ -0,0 +1,136 @@ +--- +title: "Caddy" +type: entity +aliases: [Caddy Web Server, Caddy反代] +tags: [web-server, reverse-proxy, https, open-source] +--- + +# Caddy + +## Overview +**Caddy** 是一个用 Go 语言编写的开源 Web 服务器，以自动 HTTPS 和简洁配置著称。相比 Nginx，Caddy 默认启用 HTTPS（Let's Encrypt 自动证书），配置语法更简洁直观。 + +## Core Features + +| 特性 | 说明 | +|------|------| +| **自动 HTTPS** | 自动从 Let's Encrypt 申请和续期 SSL 证书 | +| **自动 HTTP→HTTPS 重定向** | 无需手动配置 | +| **TLS 1.3 支持** | 现代加密标准 | +| **配置热加载** | 修改配置无需重启服务 | +| **反向代理** | 支持 HTTP/2、WebSocket | +| **Markdown 渲染** | 内置静态文件服务 | + +## Installation (Ubuntu/Debian) +```bash +sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl +curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg +curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list +sudo apt update +sudo apt install caddy +``` + +## Basic Configuration (Caddyfile) + +### 简单反向代理 +``` +n8n.ishenwei.online { + reverse_proxy 127.0.0.1:15678 +} +``` + +### 多域名配置 +``` +nas.ishenwei.online { + reverse_proxy 127.0.0.1:15000 +} + +grafana.ishenwei.online { + reverse_proxy 127.0.0.1:13000 +} +``` + +### 带认证的反向代理 +``` +n8n.ishenwei.online { + basicauth /* { + admin JDJhJDE0JDN3ZXVhV2YyZG9SY2hvYzVmZ2h3QUlVblpOMU4vS1ptcENrSlhySElMb3l5dytOMkh0Tk93 + } + reverse_proxy 127.0.0.1:15678 +} +``` + +## Integration with frp + +典型架构：frp 建立内网隧道 → Caddy 反向代理到本地端口 → 自动 HTTPS + +``` +用户请求 https://n8n.ishenwei.online + ↓ +阿里云 DNS → VPS 公网 IP + ↓ +Caddy (443端口) 接收请求 + ↓ +Caddyfile 配置匹配 n8n.ishenwei.online + ↓ +reverse_proxy 127.0.0.1:15678 + ↓ +frpc 在 VPS 15000 端口监听 + ↓ +frp 隧道 → 内网 Ubuntu 5678 端口 + ↓ +n8n 服务 +``` + +## Common Commands + +```bash +# 验证配置文件语法 +sudo caddy validate --config /etc/caddy/Caddyfile + +# 重载配置（热加载） +sudo systemctl reload caddy + +# 重启服务 +sudo systemctl restart caddy + +# 查看状态 +sudo systemctl status caddy + +# 紧急恢复（服务卡死时） +sudo systemctl stop caddy +sudo pkill -9 caddy +sudo systemctl start caddy +``` + +## Troubleshooting + +### Caddyfile 语法检查 +```bash +sudo caddy validate --config /etc/caddy/Caddyfile +# 输出 "Valid configuration" 表示语法正确 +``` + +### 端口被占用 +如果 Caddy 启动失败，检查端口是否被占用： +```bash +ss -ltnp | grep ':80\|:443' +``` + +### Caddy 意外占用端口 +某些一键脚本可能配置 Caddy 监听非标准端口，检查是否有： +``` +:7000 { + reverse_proxy ... +} +``` + +## Related Concepts +- [[反向代理]] — Caddy 的核心功能 +- [[Let's Encrypt]] — Caddy 自动使用的 SSL 证书提供商 +- [[frp]] — Caddy 常与 frp 配合使用 +- [[VPS]] — Caddy 通常部署在公网 VPS + +## References +- 官网: https://caddyserver.com/ +- 文档: https://caddyserver.com/docs/ diff --git a/wiki/LinuxServer.io.md b/wiki/LinuxServer.io.md new file mode 100644 index 00000000..adc807e8 --- /dev/null +++ b/wiki/LinuxServer.io.md @@ -0,0 +1,64 @@ +# LinuxServer.io + +## Type +- Entity +- Organization / Open Source Project + +## Description +LinuxServer.io 是一个社区驱动的开源组织，专门为流行的自托管应用维护高质量的 Docker 镜像。所有镜像均遵循标准化配置模式，支持 PUID/PGID 环境变量、统一的目录结构、Web UI 默认端口约定，以及完整的文档支持。 + +## Key Facts +- **Focus**: Self-hosted applications on Docker +- **Image Registry**: lscr.io (Docker Hub official partner) +- **Standard Variables**: PUID, PGID, TZ, UMASK_SET +- **Notable Images**: transmission, jellyfin, navidrome, plex, sonarr, radarr, jackett, SABnzbd, home-assistant, nginx, nextcloud, portainer, it-tools, etc. +- **License**: Various (per image) + +## Standard Configuration Pattern + +所有 LinuxServer.io 镜像遵循统一配置规范： + +### Environment Variables +```yaml +environment: + - PUID=1000 # Process UID (宿主用户ID) + - PGID=1000 # Process GID (宿主组ID) + - TZ=Etc/UTC # Timezone + # Image-specific variables below +``` + +### Volume Mounts +```yaml +volumes: + - /path/to/config:/config # 配置目录 + - /path/to/downloads:/downloads # 可选：下载目录 +``` + +### Restart Policy +```yaml +restart: unless-stopped # 容器异常退出后自动重启 +``` + +### Network Mode +```yaml +network_mode: bridge # 桥接网络，支持端口映射 +``` + +## Notable Images in shenwei's Home Server + +| Image | Purpose | Port | +|-------|---------|------| +| [[Transmission]] | BT 下载客户端 | 9091 | +| [[Jellyfin]] | 视频流媒体服务器 | 8096 | +| [[Navidrome]] | 音乐流媒体服务器 | 4533 | +| portainer | Docker 容器管理 | 9000 | +| it-tools | IT 工具集 | 8080 | +| home-assistant | 智能家居控制 | 8123 | + +## Connections +- [[Transmission]] — maintained image +- [[Jellyfin]] — maintained image +- [[Navidrome]] — maintained image +- [[Docker]] — deployment platform +- [[群晖 NAS]] — 常见部署平台 +- [[Docker Compose]] — recommended deployment method diff --git a/wiki/PUID-PGID.md b/wiki/PUID-PGID.md new file mode 100644 index 00000000..6fc6f7be --- /dev/null +++ b/wiki/PUID-PGID.md @@ -0,0 +1,43 @@ +# PUID/PGID + +## Type +- Concept + +## Definition +PUID（Process User ID）和 PGID（Process Group ID）是 LinuxServer.io Docker 镜像专用的环境变量，用于将容器内进程以宿主机指定用户/组的身份运行，从根本上解决 Docker 容器创建文件的权限归属问题。 + +## Mechanism + +### 核心原理 +``` +宿主机：用户 shenwei (UID=1000, GID=1000) + ↓ 设置 PUID=1000, PGID=1000 +容器内：Transmission 进程以 UID=1000, GID=1000 运行 + ↓ 结果 +容器创建的文件 → 归属 shenwei:shenwei → 宿主机可直接读写 +``` + +### 获取宿主机 UID/GID +```bash +id shenwei +# 输出：uid=1000(shenwei) gid=1000(shenwei) groups=1000(shenwei),... +``` + +### Docker Compose 配置示例 +```yaml +environment: + - PUID=1000 # 对应宿主机用户 ID + - PGID=1000 # 对应宿主机组 ID +``` + +## Key Claims +- PUID/PGID 是 LinuxServer.io 镜像的标准化用户配置，与非 root 用户运行（USER 环境变量）不同 +- 不设置 PUID/PGID 时，容器进程以 root（UID=0）运行，创建的文件归属 root:root，导致宿主机用户无法直接管理 +- PUID/PGID 解决了"容器内 root vs 宿主机普通用户"的跨环境文件权限冲突 +- 与 `user: "1000:1000"` Docker Compose 顶级键效果类似，但 PUID/PGID 由 LinuxServer.io 镜像内部脚本处理 + +## Relationship to [[LinuxServer.io]] +PUID/PGID 是 LinuxServer.io 所有镜像的标准化配置环境变量，属于其官方推荐的最佳实践。 + +## Sources +- [[用docker安装transmission]] diff --git a/wiki/TCP隧道.md b/wiki/TCP隧道.md new file mode 100644 index 00000000..ce2d543b --- /dev/null +++ b/wiki/TCP隧道.md @@ -0,0 +1,112 @@ +--- +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 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 diff --git a/wiki/Transmission.md b/wiki/Transmission.md new file mode 100644 index 00000000..8c36d584 --- /dev/null +++ b/wiki/Transmission.md @@ -0,0 +1,77 @@ +# Transmission + +## Type +- Entity +- Software + +## Description +Transmission 是一个开源的 BitTorrent 下载客户端，提供简洁的 Web UI 界面，支持远程管理和自动化下载。是 Home Server 媒体中心的核心组件，负责 BT 种子下载环节。 + +## Aliases +- Transmission BitTorrent +- lscr.io/linuxserver/transmission + +## Key Facts +- **License**: MIT +- **Language**: C ( GTK+ / Qt GUI / Web UI ) +- **Official Image**: lscr.io/linuxserver/transmission:latest +- **Deployment**: Docker Compose on Synology NAS / Home Server +- **Web UI Port**: 9091 +- **Peer Port**: 51413 (TCP + UDP) +- **Author**: shenwei + +## Configuration + +### Web UI Access +通过 http://host:9091 访问 Web 管理界面，支持： +- 种子管理（添加/暂停/删除/优先级） +- 下载/上传速度限制 +- 连接peer管理 +- RSS自动下载（需插件） + +### Authentication +Web UI 认证通过 USER/PASS 环境变量配置： +```yaml +environment: + - USER=shenwei + - PASS= +``` + +### Docker Deployment (shenwei) +```yaml +services: + transmission: + image: lscr.io/linuxserver/transmission:latest + container_name: transmission + restart: unless-stopped + network_mode: bridge + ports: + - "9091:9091" # Web UI + - "51413:51413" # Peer TCP + - "51413:51413/udp" # Peer UDP + environment: + - PUID=1000 + - PGID=1000 + - TZ=Etc/UTC + - USER=shenwei + - PASS= + volumes: + - /home/shenwei/Docker/transmission/data:/config + - /home/shenwei/Downloads:/downloads +``` + +## Connections + +### Upstream +- [[LinuxServer.io]] — 官方 Docker 镜像维护者 + +### Downstream +- [[Jellyfin]] — 视频播放（Transmission 下载 → Jellyfin 播放） +- [[Navidrome]] — 音乐播放（Transmission 下载 → Navidrome 播放） +- [[Docker Compose]] — 部署方式 + +### Related +- [[群晖 NAS]] — 部署平台（Synology NAS Docker 环境） + +## Sources +- [[用docker安装transmission]] diff --git a/wiki/concepts/AI-ChatOps.md b/wiki/concepts/AI-ChatOps.md new file mode 100644 index 00000000..962a60e7 --- /dev/null +++ b/wiki/concepts/AI-ChatOps.md @@ -0,0 +1,87 @@ +--- +title: "AI ChatOps" +tags: + - devops + - chatops + - ai + - collaboration + - observability +created: 2026-04-25 +--- + +# AI ChatOps + +## Definition + +AI ChatOps 是通过自然语言接口（Slack / Teams / CLI）进行故障排查，AI 提供日志分析和解决方案建议的运维协作模式。Agentic AI 作为 24/7 的运维助手，工程师随时可通过对话获取即时支持。 + +## 与 Traditional ChatOps 的区别 + +| 维度 | Traditional ChatOps | AI ChatOps | +|------|--------------------|------------| +| 响应能力 | 依赖人工在线 | 24/7 即时响应 | +| 问题诊断 | 人工搜索日志 | AI 自动分析 + 建议 | +| 知识依赖 | 依赖个人经验 | 跨团队知识聚合 | +| 学习能力 | 经验不可复制 | 持续学习 + 知识积累 | +| 平均响应 | 数分钟至数小时 | 毫秒级 | + +## Agentic AI ChatOps 能力 + +```python +ChatOps_Capabilities = { + "Log Query": "自然语言查询日志: 'Show me errors from API service in last hour'", + "Incident Summary": "AI 生成事故摘要: 'This is caused by X, fix is Y'", + "Runbook Suggestion": "AI 推荐运维手册: 'Based on error pattern, try runbook #42'", + "Metric Correlation": "AI 关联指标: 'CPU spike correlates with DB connection pool'", + "Action Execution": "AI 执行操作: '/runbook restart-service api-gateway'", + "Post-mortem": "AI 生成复盘报告: 自动生成 incident timeline" +} +``` + +## 示例 + +> Engineer in Slack: +> `@ai-ops Our API is slow, users are complaining` +> +> AI Response: +> ``` +> 🔍 Analysis complete: +> +> Root Cause: External payment API timeout (upstream) +> - Payment API p99 latency: 15,000ms (normally 200ms) +> - Correlated: API gateway retries causing backpressure +> +> Suggested Actions: +> 1. Enable circuit breaker (auto-deploy via /ops deploy) +> 2. Fallback to cache for payment status (auto via /ops deploy) +> 3. Monitor: https://grafana.link/d/abc123 +> +> Shall I proceed with option 1? (yes/no) +> ``` + +## 与 [[AIOps]] 的关系 + +AI ChatOps 是 [[AIOps]] 能力矩阵的用户交互层： + +```python +AIOps_Capabilities = { + "Anomaly Detection": "检测异常模式", + "Root Cause Analysis": "自动诊断", + "Predictive Maintenance": "预测性维护", + "Smart Alerting": "减少告警疲劳", + "Automated Remediation": "自动修复", + "Capacity Optimization": "容量优化", + "AI ChatOps ←": "自然语言交互层" # ← 本页 +} +``` + +## Related Concepts + +- [[AIOps]] — ChatOps 是 AIOps 的用户交互接口 +- [[Root Cause Analysis]] — ChatOps 依赖 RCA 能力 +- [[Observability]] — ChatOps 依赖可观测性数据 +- [[Incident Management]] — ChatOps 加速事故响应 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] diff --git a/wiki/concepts/APT-仓库配置.md b/wiki/concepts/APT-仓库配置.md new file mode 100644 index 00000000..a6b7c6ef --- /dev/null +++ b/wiki/concepts/APT-仓库配置.md @@ -0,0 +1,44 @@ +--- +title: "APT 仓库配置" +tags: [apt, ubuntu, repository] +date: 2026-04-22 +--- + +# APT 仓库配置 + +## Definition +APT (Advanced Package Tool) 仓库是 Ubuntu/Debian 系统的软件包来源，通过配置文件指定软件包的下载位置和签名验证方式。 + +## Docker 官方仓库配置流程 +1. 安装 HTTPS 传输依赖：`sudo apt-get install ca-certificates curl` +2. 创建密钥目录：`sudo install -m 0755 -d /etc/apt/keyrings` +3. 下载并导入 GPG 密钥 +4. 添加仓库源文件到 `/etc/apt/sources.list.d/` + +## 配置文件位置 +| 路径 | 作用 | +|------|------| +| `/etc/apt/sources.list` | 系统主仓库配置 | +| `/etc/apt/sources.list.d/*.list` | 第三方仓库配置 | +| `/etc/apt/keyrings/` | GPG 密钥存储目录 | + +## Docker 仓库源文件示例 +```bash +echo \ + "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ + $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ + sudo tee /etc/apt/sources.list.d/docker.list > /dev/null +``` + +## Key Concepts +- **架构变量** `$(dpkg --print-architecture)`：自动适配 amd64/arm64 等架构 +- **版本代号** `$VERSION_CODENAME`：Ubuntu 版本代号（如 jammy、noble） +- **签名验证** `signed-by`：指定 GPG 密钥路径 + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] — Docker APT 仓库完整配置流程 + +## Related Concepts +- [[GPG 密钥验证]] — apt 包签名验证机制 +- [[Docker Engine]] — 通过 APT 仓库安装 +- [[Ubuntu Server]] — APT 包管理器的宿主系统 diff --git a/wiki/concepts/Asset-Management.md b/wiki/concepts/Asset-Management.md new file mode 100644 index 00000000..a9ca360b --- /dev/null +++ b/wiki/concepts/Asset-Management.md @@ -0,0 +1,79 @@ +--- +title: "Asset Management" +type: concept +tags: [itsm, operations, finops] +date: 2025-03-01 +--- + +## Definition + +资产管理（Asset Management）是[[ITSM]]的核心流程之一，负责**跟踪和管理IT资产从采购到退役的完整生命周期**，优化资产利用率、控制成本并确保合规。 + +## Asset Lifecycle + +``` +┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ +│ Procure │ → │ Deploy │ → │Operate │ → │Maintain │ → │ Retire │ +└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ + ↓ ↓ ↓ ↓ ↓ + Purchase Provision Monitor Patch/Update Archive/ + Planning & Config & Optimize & Upgrade Dispose +``` + +## Asset Management Focus Areas + +| 领域 | 描述 | +|------|------| +| Hardware Lifecycle | 服务器、网络设备生命周期 | +| Software Licensing | 软件许可管理（SAM） | +| Cloud Optimization | 云资源成本优化 | +| Shadow IT Prevention | 影子IT发现与治理 | +| Compliance | 许可证合规审计 | + +## Modern Asset Management (ITSM 2.0) + +在[[ITSM 2.0]]中，资产管理由AI驱动： + +### Intelligent Features + +| 能力 | 描述 | 价值 | +|------|------|------| +| Automated Lifecycle Tracking | 自动追踪资产状态 | 减少人工 | +| License Optimization | 许可证使用分析 | 成本节省 | +| Usage Analytics | 利用率分析 | Rightsizing | +| Cost Forecasting | 成本预测 | 预算规划 | +| Cloud Resource Optimization | 云资源优化 | FinOps | + +### Cloud-Optimized SAM (Software Asset Management) + +``` +Software License Usage +├── Used Licenses: 80% +├── Unused Licenses: 15% +└── Over-licensed: 5% + ↓ + AI Analysis + ├── Reclaim unused + ├── Optimize purchases + └── Prevent overruns +``` + +## Key Metrics + +| 指标 | 描述 | +|------|------| +| Asset Utilization Rate | 资产利用率 | +| License Compliance | 许可证合规率 | +| Shadow IT Count | 影子IT数量 | +| Cost per Asset | 单资产成本 | + +## Related Concepts + +- [[ITSM]] — 父框架 +- [[FinOps]] — 云财务管理 +- [[Rightsizing]] — 资源优化 +- [[Cloud-Optimization]] — 云优化 + +## Sources + +- [[understanding-complete-itsm]] — Intelligent Asset Lifecycle Tracking diff --git a/wiki/concepts/Automated-Security-Audit.md b/wiki/concepts/Automated-Security-Audit.md new file mode 100644 index 00000000..a171c402 --- /dev/null +++ b/wiki/concepts/Automated-Security-Audit.md @@ -0,0 +1,83 @@ +--- +title: "Automated Security Audit" +tags: + - devops + - security + - automation + - compliance + - ai +created: 2026-04-25 +--- + +# Automated Security Audit + +## Definition + +Automated Security Audit 是通过 AI 自动扫描 IAM 策略、网络规则和容器漏洞，**检测安全风险并自动修复**的能力。Agentic AI 持续监控安全态势，实时执行合规修复。 + +## Scope + +| 扫描对象 | 检测内容 | 修复动作 | +|---------|---------|---------| +| IAM Policies | 过度权限、公共访问风险 | 自动限制权限 | +| Network Rules | 开放端口、安全组配置错误 | 自动收紧规则 | +| Container Images | 已知漏洞 (CVE) | 触发重建 + 更新 | +| S3 Buckets | 公开访问、数据泄露风险 | 自动阻止公共访问 | +| Firewalls | 配置错误、入站规则过宽 | 自动修正 | + +## Agentic AI Security Audit 工作流 + +``` +1. 持续扫描 → AWS Inspector / GCP Security Command Center / Azure Defender +2. 风险评估 → CVSS 评分 + 业务影响分析 +3. 自动修复 → 低风险自动修复，高风险人工审批 +4. 合规验证 → SOC 2 / FedRAMP / PCI DSS 持续检查 +5. 报告生成 → 安全态势仪表盘 + 合规报告 +``` + +## 与 [[DevSecOps]] 的关系 + +Automated Security Audit 是 [[DevSecOps]] 实践的核心组件： + +```python +DevSecOps_Pipeline = { + "Build": "SAST (Static Application Security Testing)", + "Test": "DAST (Dynamic Application Security Testing)", + "Deploy": "Container Scanning ←", # 漏洞扫描 + "Monitor": "Automated Security Audit ←", # ← 本页 + "Respond": "自动威胁缓解" +} +``` + +## 示例 + +> Agentic AI detects an over-permissive IAM role: +> - Role: `production-app-read-all` +> - Allows: `s3:*` on `arn:aws:s3:::customer-data-*` +> - Risk: Public access enabled on bucket +> - **AI Action**: +> - Immediately restricts bucket policy +> - Notifies DevOps team via Slack +> - Creates Jira ticket for IAM review +> - Logs audit trail for compliance + +## 与合规框架的关系 + +| 合规框架 | Agentic AI 支持方式 | +|---------|-------------------| +| SOC 2 | 持续访问审计 + 变更记录 | +| FedRAMP | 安全配置基线检查 + 报告 | +| PCI DSS | 数据访问控制 + 加密验证 | +| ISO 27001 | 风险评估 + 修复验证 | + +## Related Concepts + +- [[DevSecOps]] — Automated Security Audit 是 DevSecOps 的技术基础 +- [[Cloud Security]] — 审计是云安全的核心实践 +- [[IAM]] — 主要审计对象之一 +- [[Compliance]] — 审计支持合规证明 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] +- [[cloud-devop-maturity-guideline]] diff --git a/wiki/concepts/Blue-Green-Deployment.md b/wiki/concepts/Blue-Green-Deployment.md new file mode 100644 index 00000000..7075be94 --- /dev/null +++ b/wiki/concepts/Blue-Green-Deployment.md @@ -0,0 +1,84 @@ +--- +title: "Blue-Green Deployment" +type: concept +tags: [devops, deployment, release-management, high-availability] +date: 2025-03-01 +--- + +## Definition + +蓝绿部署（Blue-Green Deployment）是一种零停机发布策略，维护两套相同的生产环境（蓝环境和绿环境），通过负载均衡器切换流量实现无缝部署和快速回滚。 + +## Architecture + +``` + Load Balancer + │ + ┌──────────┴──────────┐ + │ │ + Blue Env Green Env + (Production) (Staging) + │ │ + v1.0 v1.1 (New) + │ + Traffic ON Traffic OFF +``` + +## Deployment Flow + +``` +1. Blue (v1.0) serving all traffic +2. Deploy to Green (v1.1) +3. Test/Verify Green +4. Switch LB to Green +5. Blue becomes standby (or update to next version) +``` + +## Key Benefits + +| 优势 | 描述 | +|------|------| +| 零停机 | 流量切换瞬间完成 | +| 快速回滚 | 切换回蓝色环境即可 | +| 测试完整性 | 完整生产环境测试 | +| 风险可控 | 新版本未暴露给全部用户 | + +## Comparison: Blue-Green vs Canary + +| 维度 | Blue-Green | Canary | +|------|-----------|--------| +| 流量切换 | 全量切换 | 渐进式 | +| 回滚速度 | 秒级 | 秒级 | +| 资源成本 | 2x | 增量 | +| 适用场景 | 关键系统 | 持续迭代 | +| 风险 | 全量暴露 | 逐步暴露 | + +## In ITSM Context + +在[[ITSM 2.0]]的[[Release-Management]]中，蓝绿部署是关键实践： + +``` +Release Management 2.0 +├── Blue-Green Deployment +│ ├── 零停机发布 +│ ├── 秒级回滚 +│ └── 全量验证 +├── Canary Release +│ ├── 渐进式发布 +│ └── 实时监控 +└── DevOps-integrated ITSM + ├── CI/CD Pipeline + └── Automated Governance +``` + +## Related Concepts + +- [[Release-Management]] — 发布管理总框架 +- [[Canary-Release]] — 金丝雀发布 +- [[High-Availability]] — 高可用架构 +- [[Failover]] — 故障转移 +- [[Deployment-Automation]] — 部署自动化 + +## Sources + +- [[understanding-complete-itsm]] — Blue-Green在现代ITSM中的应用 diff --git a/wiki/concepts/Break-the-Build.md b/wiki/concepts/Break-the-Build.md new file mode 100644 index 00000000..0b329901 --- /dev/null +++ b/wiki/concepts/Break-the-Build.md @@ -0,0 +1,64 @@ +# Break-the-Build + +## Definition +"Break the Build" is a mechanism that stops the development process if security risks are too high until resolved. + +## Concept +当 CI/CD 管道中的安全扫描发现高风险问题时，自动阻止构建继续进行，直到安全问题得到修复。 + +## How It Works + +### Trigger Conditions +- SAST 发现高危漏洞 +- SCA 发现有漏洞的依赖 +- 机密信息泄露检测 +- 许可证合规违规 + +### Process Flow +``` +代码提交 → 构建开始 → 安全扫描 → + ├─ 通过 → 继续部署 + └─ 失败 → 停止构建 → 通知团队 → 修复 → 重新提交 +``` + +## Implementation + +### CI/CD Integration +```yaml +# GitLab CI Example +security_scan: + stage: test + script: + - sast-scan + allow_failure: false # 阻止构建 +``` + +### Gatekeeping Strategy +| 漏洞等级 | 默认策略 | +|---------|---------| +| Critical | 强制阻止 | +| High | 阻止（可配置） | +| Medium | 警告 | +| Low | 忽略 | + +## Benefits +- 防止不安全代码进入生产环境 +- 强制开发者及时修复安全问题 +- 提高整体安全基线 +- 减少安全债务 + +## Best Practices +1. 明确定义"阻塞"阈值 +2. 平衡安全与开发速度 +3. 提供清晰的错误信息 +4. 集成通知机制 + +## Related Concepts +- [[DevSecOps]] — Break-the-Build 是其自动化组件 +- [[SAST]] — 触发条件来源 +- [[SCA]] — 触发条件来源 +- [[CI/CD Pipeline]] — 实施载体 +- [[Shift-Left-Security]] — 早期发现问题的策略 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Bug-Bounty.md b/wiki/concepts/Bug-Bounty.md new file mode 100644 index 00000000..8d476d9e --- /dev/null +++ b/wiki/concepts/Bug-Bounty.md @@ -0,0 +1,63 @@ +# Bug Bounty + +## Definition +Bug Bounty programs incentivize external security researchers to report vulnerabilities in an organization's systems, websites, or applications. + +## Concept +Bug Bounty（漏洞赏金）计划通过向外部安全研究人员提供奖励，激励他们报告组织系统、网站或应用程序中的漏洞。 + +## How It Works + +### Program Setup +1. 定义范围（Scope） +2. 制定规则和奖励表 +3. 建立提交和处理流程 +4. 部署公开平台或使用第三方服务 + +### Researcher Workflow +``` +发现漏洞 → 提交报告 → 厂商验证 → 确认/分类 → 修复 → 发放奖励 +``` + +## Benefits + +### For Organizations +- 扩展安全测试覆盖面 +- 成本效益比聘请专职安全团队更高 +- 获得多样化的安全研究人员视角 +- 提高安全响应能力 + +### For Researchers +- 获得经济奖励 +- 建立安全研究声誉 +- 学习真实环境漏洞 + +## Platforms +- HackerOne +- Bugcrowd +- Open Bug Bounty +- 厂商自有平台（Google VRP, Microsoft Bounty） + +## Best Practices + +### For Program Owners +1. 清晰的规则和范围定义 +2. 公平的奖励机制 +3. 快速响应提交 +4. 透明的沟通 +5. 法律保护（Safe Harbor） + +### Responsible Disclosure +- 给厂商合理时间修复 +- 不公开漏洞细节直到修复 +- 遵循协调漏洞披露（CVD） + +## Related Concepts +- [[DevSecOps]] — Bug Bounty 是持续安全改进的一部分 +- [[Penetration-Testing]] — 正式渗透测试 +- [[Vulnerability-Scanning]] — 自动化漏洞扫描 +- [[Incident-Response]] — 漏洞响应 +- [[Responsible-Disclosure]] — 负责任披露 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Business-Impact-Analysis.md b/wiki/concepts/Business-Impact-Analysis.md new file mode 100644 index 00000000..91e76328 --- /dev/null +++ b/wiki/concepts/Business-Impact-Analysis.md @@ -0,0 +1,102 @@ +--- +title: "Business Impact Analysis (业务影响分析)" +tags: [devops, disaster-recovery, risk-management, business-continuity, planning] +aliases: [BIA] +created: 2026-04-25 +--- + +# Business Impact Analysis (业务影响分析) + +**Business Impact Analysis (BIA)** 是确定不同应用系统故障对业务影响的分析过程，用于设定 [[RTO]] 和 [[RPO]] 目标以及分层保护策略。 + +## Aliases +- BIA +- 业务影响分析 + +## Definition + +BIA 的核心问题： +1. 如果系统停机 1 小时，会发生什么？ +2. 如果丢失过去 1 小时的数据，会发生什么？ + +回答这些问题，才能科学地确定每个系统的 RTO/RPO 目标，而非凭感觉设定"激进但无法实现"的目标。 + +## 关键分析问题 + +### 如果系统停机 1 小时？ + +- **收入损失**？损失多少？ +- **客户不满**？影响多少客户？ +- **员工受阻**？他们能绕过去工作吗？ +- **合规风险**？法律问题？ + +### 如果丢失过去 1 小时的数据？ + +- **数据能重建吗**？ +- **是否涉及资金/交易**？ +- **用户会注意到吗**？ +- **合规要求**是否要求保留这些数据？ + +## Tiered Protection Model + +基于 BIA 结论，将应用分为不同保护级别： + +| Tier | 场景 | RTO 目标 | RPO 目标 | 投资策略 | +|------|------|----------|----------|----------| +| **(1) Critical** | 支付处理、用户认证、核心产品功能 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动化监控 + 3AM 告警 + 热备 | +| **(2) Important** | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag（主要发布）+ 业务时间监控 + 标准备份 | +| **(3) Nice-to-have** | 内部工具、开发环境、文档站点 | < 4 小时 | < 1 小时 | 基础监控 + 手动恢复流程 + 每日备份 | + +## 投资优先级 + +> "Most teams try to give everything Tier 1 treatment, which can lead to burnout. Be ruthless about what actually matters to your business. You can't do *everything*." + +### Tier 1 投资 +- [[Feature Flag]] + 自动化监控 +- 自动化告警（支持 3AM 叫醒） +- [[Kill Switch]] + 备用路径就绪 +- 近实时数据复制 + +### Tier 2 投资 +- [[Feature Flag]]（主要发布场景） +- 业务时间监控 +- 文档化的回滚程序 +- 小时级备份 + +### Tier 3 投资 +- 基础监控 +- 手动恢复程序 +- 每日备份 +- 期望最好的结果 + +## BIA 与成本收益 + +> "Do the math honestly. What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it. You're better off accepting some downtime and investing in faster recovery." + +| 系统停机损失 | 合理灾备投资上限（年化） | +|-------------|------------------------| +| $10K/小时 | $100K/年 | +| $100K/小时 | $1M/年 | + +**关键洞察**：预防和恢复的成本必须与实际业务损失相匹配。 + +## BIA 与 [[Feature Flag]] 的关系 + +BIA 结论指导 Feature Flag 的使用策略： + +- **Tier 1 系统**：必须有 Kill Switch，Progressive Rollout 强制 +- **Tier 2 系统**：建议 Feature Flag 主要发布场景 +- **Tier 3 系统**：根据 ROI 决定是否使用 Feature Flag + +## Related Concepts + +- [[RTO]] — BIA 结论决定 RTO 目标 +- [[RPO]] — BIA 结论决定 RPO 目标 +- [[Feature Flag]] — 基于 BIA 分层保护的技术手段 +- [[Kill Switch]] — Tier 1 系统的必备应急机制 +- [[Disaster Recovery]] — BIA 是灾备规划的基础 +- [[Risk-Mitigation]] — BIA 是风险管理的一部分 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/CMDB.md b/wiki/concepts/CMDB.md new file mode 100644 index 00000000..679ac919 --- /dev/null +++ b/wiki/concepts/CMDB.md @@ -0,0 +1,68 @@ +--- +title: "Configuration Management Database (CMDB)" +type: concept +tags: [cloud, devops, operations, itsm] +date: 2025-03-01 +--- + +## Definition + +配置管理数据库（CMDB）是存储IT基础设施中所有配置项（Configuration Items, CI）及其关系关系的数据库。在现代ITSM中，AI驱动的CMDB增强了依赖映射、漂移检测和实时影响分析能力。 + +## Traditional vs Modern CMDB + +| 维度 | 传统CMDB | AI-Enhanced CMDB | +|------|---------|------------------| +| 数据来源 | 手动录入 | 自动发现 | +| 关系映射 | 静态 | 动态 | +| 漂移检测 | 定期审计 | 实时监控 | +| 影响分析 | 人工推断 | AI预测 | +| 多云支持 | 有限 | 原生支持 | + +## Key Capabilities (Modern CMDB) + +### 1. Dependency Mapping +``` +服务 → 应用 → 中间件 → 数据库 → 基础设施 + ↓ ↓ ↓ ↓ ↓ +自动发现配置项及其依赖关系 +``` + +### 2. Drift Detection +- 配置变更自动检测 +- 与预期配置对比 +- 告警和自动修复 + +### 3. Real-time Impact Analysis +- 变更前影响预测 +- 事件影响范围评估 +- 服务依赖可视化 + +## In ITSM Context + +在[[ITSM]]中，CMDB是[[Configuration-Management]]的核心： + +``` +Configuration Management (ITSM 5.0) +├── AI-powered CMDB +│ ├── 依赖映射 +│ ├── 漂移检测 +│ └── 实时影响分析 +├── Multi-cloud Orchestration +│ ├── 公有云 +│ ├── 私有云 +│ └── 混合云 +└── Misconfiguration Prevention + └── 安全漏洞预防 +``` + +## Related Concepts + +- [[Configuration-Management]] — 配置管理流程 +- [[ITSM]] — CMDB的父框架 +- [[AIOps]] — AI驱动的CMDB能力 +- [[Cloud-Native]] — 多云CMDB支持 + +## Sources + +- [[understanding-complete-itsm]] — AI-CMDB在现代ITSM中的应用 diff --git a/wiki/concepts/Canary-Release.md b/wiki/concepts/Canary-Release.md new file mode 100644 index 00000000..f98adc2d --- /dev/null +++ b/wiki/concepts/Canary-Release.md @@ -0,0 +1,63 @@ +--- +title: "Canary Release" +type: concept +tags: [devops, deployment, release-management, automation] +date: 2025-03-01 +--- + +## Definition + +金丝雀发布（Canary Release）是一种渐进式软件发布策略，将新版本首先部署给小部分用户，验证稳定性后再逐步扩大范围，最终替换全部用户。这种策略降低了全量发布风险，实现近乎零干扰的发布。 + +## How It Works + +``` +Phase 1: 5% Traffic Phase 2: 20% Traffic Phase 3: 100% Traffic +┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ +│ New Version │ │ New Version │ │ Old Version │ +│ ██ │ │ ████ │ │ ░░░░ │ +│ 5% users │ │ 20% users │ │ Rollback if │ +└─────────────────┘ └─────────────────┘ │ issues │ + ↓ ↓ └─────────────────┘ + Monitor metrics Monitor + Auto-rollback ↓ + Auto-promote if failure rate ↑ Full Deployment +``` + +## Key Metrics to Monitor + +| 指标 | 描述 | 告警阈值 | +|------|------|---------| +| Error Rate | 错误率变化 | +2% | +| Latency | 响应时间 | +50ms | +| Business KPIs | 转化率、订单量 | -5% | +| Resource Usage | CPU/内存 | +30% | + +## In ITSM Context + +在[[ITSM 2.0]]的[[Release-Management]]中，金丝雀发布是关键实践： + +``` +Release Management 2.0 +├── Canary Release +│ ├── 渐进式流量转移 +│ ├── 实时监控 +│ └── 自动回滚 +├── Blue-Green Deployment +│ ├── 零停机切换 +│ └── 快速回滚 +└── Feature Flags + ├── 精细化控制 + └── A/B Testing +``` + +## Related Concepts + +- [[Release-Management]] — 发布管理总框架 +- [[Blue-Green-Deployment]] — 蓝绿部署 +- [[Feature-Flag]] — 特性开关 +- [[Progressive-Rollout]] — 渐进式发布 +- [[Deployment-Automation]] — 部署自动化 + +## Sources + +- [[understanding-complete-itsm]] — Canary Release在现代ITSM中的应用 diff --git a/wiki/concepts/Centralized-Logging.md b/wiki/concepts/Centralized-Logging.md new file mode 100644 index 00000000..001a4f36 --- /dev/null +++ b/wiki/concepts/Centralized-Logging.md @@ -0,0 +1,38 @@ +--- +title: Centralized Logging +type: concept +tags: [DevOps, Observability, CloudOps, AWS] +date: 2025-10-24 +--- + +## Definition +Centralized Logging（集中日志）是一种将分散在多个系统、账户、服务或地理位置的日志汇总到单一中心位置进行统一管理的模式。核心目标是在分布式系统中消除监控盲区，提供全局可观测性。 + +## Core Properties +- **聚合**：将多个来源的日志合并到单一存储 +- **统一查询**：跨来源的集中搜索和分析 +- **集中告警**：基于聚合数据的统一告警策略 +- **合规保留**：统一的数据保留和合规策略 + +## Related Concepts +- [[Multi-Account Deployment]]：多账户场景是集中日志的主要驱动因素 +- [[Cross-Account Monitoring]]：跨账户监控依赖集中日志基础设施 +- [[StackSets Deployment Visibility]]：StackSets 部署可观测性依赖集中日志 +- [[Event Sourcing]]：集中日志可以视为事件溯源的一种实现 +- [[APM]]（Application Performance Monitoring）：APM 工具通常依赖集中日志数据 +- [[CloudWatch Logs]]：AWS 生态系统中的集中日志存储服务 +- [[Prometheus]]：时间序列监控，可与集中日志互补 + +## Implementation Patterns +1. **日志采集层**：Agent/Fluentd/Firelens 收集各来源日志 +2. **传输层**：EventBridge/Kinesis/Firehose 传输日志事件 +3. **存储层**：CloudWatch Logs/OpenSearch/S3 + Athena +4. **分析层**：CloudWatch Logs Insights/OpenSearch Dashboards/Grafana Loki +5. **告警层**：CloudWatch Alarms/Grafana Alerting/PagerDuty + +## AWS Context +- AWS CloudWatch Logs：AWS 原生日志存储和分析服务 +- AWS EventBridge：事件驱动的日志采集路由 +- AWS CloudTrail：AWS API 调用的审计日志（集中日志的特殊形式） +- AWS Systems Manager OpsCenter：基于集中日志的运营问题管理 +- [[Centralized Logging]] ← uses ← [[Amazon EventBridge]] ← routes ← [[Amazon CloudWatch Logs]] diff --git a/wiki/concepts/Change-Management.md b/wiki/concepts/Change-Management.md new file mode 100644 index 00000000..fc662f91 --- /dev/null +++ b/wiki/concepts/Change-Management.md @@ -0,0 +1,69 @@ +--- +title: "Change Management" +type: concept +tags: [itsm, devops, operations] +date: 2025-03-01 +--- + +## Definition + +变更管理（Change Management）是[[ITSM]]的核心流程之一，通过**结构化的方法评估、审批和实施IT变更**，在保持服务稳定性的同时实现业务所需的灵活性。 + +## Change Management Process + +``` +┌──────────────┐ ┌──────────────┐ ┌──────────────┐ +│ Change │ → │ Impact │ → │ CAB │ +│ Request │ │ Assessment │ │ Approval │ +└──────────────┘ └──────────────┘ └──────────────┘ + ↓ +┌──────────────┐ ┌──────────────┐ ┌──────────────┘ +│ Build & │ ← │ Change │ ← │ Schedule │ +│ Test │ │ Build │ │ & Prepare │ +└──────────────┘ └──────────────┘ └──────────────┘ +``` + +## Change Types + +| 类型 | 描述 | 审批级别 | +|------|------|---------| +| Emergency | 紧急变更（如P1事故响应） | 快速审批 | +| Standard | 标准变更（例行维护） | 自动审批 | +| Normal | 常规变更（新功能部署） | CAB审批 | + +## Modern Change Management (ITSM 2.0) + +在[[ITSM 2.0]]中，变更管理由AI和[[IaC]]驱动： + +### AI-Driven Risk Assessment +- **Automated Impact Analysis** — 自动评估变更影响 +- **Failure Probability Prediction** — AI预测变更失败概率 +- **Rollback Planning** — 自动生成回滚计划 + +### CI/CD Pipeline Governance +``` +Code Commit → Automated Testing → IaC Validation → Risk Score → Approval + ↓ ↓ ↓ ↓ ↓ + Git hooks Unit/Int Tests Terraform Plan ML Model Auto/CAB +``` + +## Key Metrics + +| 指标 | 描述 | +|------|------| +| Change Success Rate | 变更成功率 | +| Failed Change Rate | 失败变更率 | +| Rollback Rate | 回滚率 | +| Emergency Change Ratio | 紧急变更比例 | + +## Related Concepts + +- [[ITSM]] — 父框架 +- [[Change-Failure-Rate]] — 变更失败率 +- [[IaC]] — 基础设施即代码 +- [[CI/CD-Pipeline]] — CI/CD流水线 +- [[Rollback]] — 回滚机制 + +## Sources + +- [[understanding-complete-itsm]] — AI-driven Change Management diff --git a/wiki/concepts/Cloud-Adoption-Strategy.md b/wiki/concepts/Cloud-Adoption-Strategy.md index 47fd6662..33f5aa25 100644 --- a/wiki/concepts/Cloud-Adoption-Strategy.md +++ b/wiki/concepts/Cloud-Adoption-Strategy.md @@ -1,77 +1,144 @@ ---- -title: Cloud Adoption Strategy -source: https://www.bacancytechnology.com/blog/cloud-maturity-model -tags: [Cloud, Strategy, Transformation, Cloud-Maturity] ---- - # Cloud Adoption Strategy -## Overview +> **Cloud Adoption Strategy** — 组织将工作负载、应用程序和数据从本地基础设施迁移到云环境，并持续优化云服务使用的系统性方法。 -A **Cloud Adoption Strategy** is a comprehensive plan that guides organizations through the process of transitioning their workloads, applications, and infrastructure to cloud environments. The Cloud Maturity Model (CMM) provides a structured framework for developing and executing this strategy. +## Definition -## Key Elements +云采用策略（Cloud Adoption Strategy）是一份全面的行动计划，定义组织如何： -### 1. Setting Cloud Adoption Objectives +- 评估当前状态（遗留系统、云就绪度） +- 设定云采用目标 +- 选择合适的云平台和部署模型 +- 规划迁移路径和优先级 +- 管理变革和人员转型 +- 持续优化云运营 -Before adopting cloud services, organizations should: +## Core Framework -- **Clarify Motivations** — Focus on cloud economics and Total Cost of Ownership (TCO) to understand how cost savings and efficiency drive adoption -- **Determine Business Goals** — Align technical strategies with business objectives to ensure cloud adoption meets organizational needs -- **Develop a Business Case** — Create a strong business case to secure support from internal teams, including finance and management +根据 Open Alliance for Cloud Adoption (OACA) 的云成熟度模型，云采用策略应包含： -### 2. Identifying Current Maturity Level +### 1. GAP Analysis（差距分析） -Understanding your current cloud maturity level (0-5) allows for: -- Tailored objectives based on current state -- More effective cloud adoption strategy -- Right balance between cloud-native services and hybrid architecture +评估当前状态与目标状态之间的差距： +- 技术差距（基础设施、应用、数据） +- 流程差距（运营、安全、合规） +- 人员差距（技能、文化、能力） -### 3. Selecting the Right Maturity Model +### 2. Cloud Maturity Assessment -Various models are available: -- **OACA Cloud Maturity Model** — General framework, provider-neutral -- **AWS Cloud Adoption Framework** — AWS-specific best practices -- **Azure Cloud Adoption Framework** — Microsoft Azure guidance -- **Google Cloud Adoption Framework** — Google Cloud transition guide -- **Cloud Security Maturity Model (CSMM)** — Security-specific assessment +| 评估维度 | 评估内容 | +|----------|---------| +| **人员 (People)** | 技能水平、培训需求、文化适应性 | +| **流程 (Processes)** | 现有流程成熟度、改进机会 | +| **技术 (Technology)** | 基础设施、应用、数据、集成 | -### 4. Following Governance and Compliance +### 3. Migration Strategy -Establish: -- Framework defining roles, responsibilities, and decision-making -- Comprehensive policies (security, access controls, data protection, cost management, incident response) -- Alignment with industry regulations (HIPAA, PCI-DSS) - -### 5. Security and Risk Management - -- Encryption and access controls -- Regular backups and monitoring -- Frequent risk assessments -- Security awareness training - -## Relationship with Cloud Maturity Model - -The CMM serves as both a diagnostic tool and a roadmap: -- **Diagnostic** — Assess current state across people, processes, and technology -- **Roadmap** — Guide progression through 5 maturity levels -- **Benchmarking** — Compare progress against industry standards +| 策略类型 | 适用场景 | 风险/收益 | +|----------|---------|-----------| +| **Rehost (Lift & Shift)** | 快速迁移、时间紧迫 | 低风险/低收益 | +| **Replatform** | 部分优化需求 | 中风险/中收益 | +| **Repurchase** | SaaS 替代 | 低风险/中收益 | +| **Refactor** | 云原生需求 | 高风险/高收益 | +| **Retire** | 淘汰遗留系统 | 降低复杂性 | +| **Retain** | 暂不迁移 | 战略保留 | ## Best Practices -1. Avoid skipping maturity levels — sustainable transformation requires incremental progress -2. Focus on long-term sustainability over rapid technological change -3. Selectively adopt Level 5 elements that bring clear business benefits -4. Establish clear KPIs for cloud utilization -5. Invest in education and training programs +### 1. Set Up Cloud Adoption Objectives -## Related Concepts +**Clarify Motivations** +- 关注云经济学和总拥有成本 (TCO) +- 量化成本节省和效率提升 -- [[Cloud-Maturity-Model]] -- [[Multi-Cloud-Strategy]] -- [[Cloud-Native]] -- [[FinOps]] +**Determine Business Goals** +- 将技术战略与业务目标对齐 +- 确保云采用满足组织需求 -## Sources +**Develop a Business Case** +- 创建有说服力的业务案例 +- 争取财务和管理团队支持 -- [[sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md]] +### 2. Identify Current Maturity Level + +- 使用 Cloud Maturity Model 评估当前状态 +- 设定切合实际的改进目标 +- 平衡完全云原生与混合架构需求 + +### 3. Pick the Right Maturity Model + +| 模型 | 适用场景 | 特点 | +|------|---------|------| +| **OACA CMM** | 通用云采用 | 供应商中立 | +| **AWS CAF** | AWS 环境 | AWS 特定 | +| **Azure CAF** | Azure 环境 | Azure 特定 | +| **GCP CAF** | GCP 环境 | GCP 特定 | +| **CSMM** | 云安全成熟度 | 安全评估 | + +### 4. Follow Governance and Compliance + +- 建立治理框架定义角色和职责 +- 制定安全、访问控制、数据保护政策 +- 符合 HIPAA、PCI-DSS 等行业法规 + +### 5. Security and Risk Management + +- 部署加密和访问控制 +- 定期备份和威胁监控 +- 持续风险评估 +- 安全意识培训 + +## Cloud Deployment Models + +| 模型 | 描述 | 适用场景 | +|------|------|---------| +| **Public Cloud** | 共享基础设施 | 弹性扩展、成本优化 | +| **Private Cloud** | 专用基础设施 | 高安全、合规需求 | +| **Hybrid Cloud** | 公私混合 | 灵活性和控制平衡 | +| **Multi-Cloud** | 多云平台 | 避免锁定、优化性能 | + +## Key Considerations + +### CAPEX vs OPEX + +| 维度 | CAPEX (本地) | OPEX (云) | +|------|-------------|-----------| +| 前期成本 | 高 | 低 | +| 持续成本 | 维护、折旧 | 按需付费 | +| 灵活性 | 低 | 高 | +| 可扩展性 | 有限 | 弹性 | +| 可见性 | 固定 | 按使用付费 | + +### TCO (Total Cost of Ownership) + +评估云采用总成本时考虑： +- 直接成本（计算、存储、网络） +- 间接成本（培训、迁移、集成） +- 隐性成本（治理、安全、合规） +- 机会成本（创新速度） + +## Phases of Cloud Adoption + +``` +Phase 1: Discovery & Assessment + ↓ +Phase 2: Strategy & Planning + ↓ +Phase 3: Foundation & Readiness + ↓ +Phase 4: Migration + ↓ +Phase 5: Optimization + ↓ +Phase 6: Innovation & Transformation +``` + +## See Also + +- [[Cloud Maturity Model]] — 成熟度框架 +- [[Cloud Maturity Levels]] — 成熟度级别 +- [[Cloud Migration]] — 云迁移 +- [[Cloud Governance]] — 云治理 +- [[Multi-Cloud Strategy]] — 多云策略 +- [[FinOps]] — 云财务管理 +- [[Cloud-Native]] — 云原生 diff --git a/wiki/concepts/Cloud-Cost-Optimization.md b/wiki/concepts/Cloud-Cost-Optimization.md new file mode 100644 index 00000000..3154d0d8 --- /dev/null +++ b/wiki/concepts/Cloud-Cost-Optimization.md @@ -0,0 +1,73 @@ +--- +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]] diff --git a/wiki/concepts/Cloud-Governance.md b/wiki/concepts/Cloud-Governance.md new file mode 100644 index 00000000..ac85b7d3 --- /dev/null +++ b/wiki/concepts/Cloud-Governance.md @@ -0,0 +1,68 @@ +--- +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]] diff --git a/wiki/concepts/Cloud-Maturity-Levels.md b/wiki/concepts/Cloud-Maturity-Levels.md index 2ad7947b..6ef73f5a 100644 --- a/wiki/concepts/Cloud-Maturity-Levels.md +++ b/wiki/concepts/Cloud-Maturity-Levels.md @@ -1,90 +1,181 @@ ---- -title: Cloud Maturity Levels (0-5) -source: https://www.bacancytechnology.com/blog/cloud-maturity-model -tags: [Cloud, Maturity, Levels, Assessment, Transformation] ---- +# Cloud Maturity Levels -# Cloud Maturity Levels (0-5) +> **Cloud Maturity Levels** — 云成熟度5级模型的详细定义，每级对应组织在云采用旅程中的特定能力水平。 ## Overview -The Cloud Maturity Model defines **5 maturity levels** (Level 0-5) that represent stages of organizational cloud adoption capability. These levels provide a structured assessment framework for evaluating current state and planning progression. +Cloud Maturity Model 将组织的云成熟度分为 5 个级别（Level 0-5），每个级别代表不同的技术能力、流程成熟度和战略整合程度。 -## The Six Maturity Levels +## The 5 Maturity Levels -### Level 0: Legacy (No Cloud Readiness) -- Company doesn't use the cloud at all -- Relies solely on outdated systems -- No plans to adopt cloud services -- Starting new projects is slow and difficult -- Often due to strict regulations (high security or data requirements) rather than lack of readiness +### Level 0: No Cloud Readiness (Legacy) + +**定义**: 组织完全不使用云服务，仅依赖遗留系统。 + +**特征**: +- 无虚拟化 +- 所有工作负载在本地 +- 新项目启动缓慢困难 +- 通常受严格监管约束（高安全或数据要求） + +**典型场景**: +- 高度监管行业（某些金融、医疗） +- 数据主权要求极高的场景 +- 历史遗留系统迁移困难的组织 + +--- ### Level 1: Initial Readiness (Ad hoc) -- Company has assessed software and services for cloud integration -- Some initial experience with cloud services -- Possibly migrating a few systems -- Still operates primarily on legacy and non-virtualized systems -- Cloud mainly used for SaaS or specific business unit needs -- No clear overall strategy -**Key Challenges:** Limited cloud knowledge, minimal leadership support, absence of clear strategy, undefined processes +**定义**: 组织开始评估云服务，零星采用但无整体战略。 + +**特征**: +- 已评估软件和服务的云集成可能性 +- 部分工作负载尝试迁移 +- 仍主要运行在遗留和非虚拟化系统 +- 主要使用 SaaS 或特定业务单元需求 +- 缺乏清晰的整体云战略 + +**常见挑战**: + +| 挑战 | 解决方案 | +|------|---------| +| 云技术知识有限 | 获得高管对云计划的支持 | +| 领导层支持不足 | 使用非关键应用进行多个 PoC | +| 缺乏资金 | 获取云服务的综合访问资金 | +| 无清晰战略 | 为当前团队制定云技术有效使用战略 | +| 无定义流程/指南 | 通过教育培训增强云知识 | +| 无云使用优化 | 建立明确的 KPI（如降低 25% 基础设施成本） | +| 缺乏云安全意识 | 通过培训加深云安全风险理解 | + +**进阶路径**: 高管支持 → PoC 验证 → 资金保障 → 战略制定 → KPI 建立 + +--- ### Level 2: Repeatable, Opportunistic -- Established IT and procurement procedures for cloud services -- Decided who can subscribe and how -- Processes are defined and repeatable -- Cloud services used extensively -- Approach isn't yet fully systematic and clearly defined -**Key Challenges:** Cost control concerns, lack of documented policies, over-reliance on manual tasks, limited cloud usage visibility +**定义**: 组织建立了使用云服务的 IT 和采购流程，广泛使用云但方法不够系统。 + +**特征**: +- 已建立云订阅和访问流程 +- 流程已定义且可重复 +- 云服务使用广泛 +- 尚无完全系统化的方法 + +**常见挑战**: + +| 挑战 | 解决方案 | +|------|---------| +| 成本控制与管理问题 | 将云使用与业务目标对齐（市场扩张、新品发布） | +| 缺乏文档化政策 | 建立云卓越中心（CCoE） | +| 过度依赖手动任务 | 形成专门的云治理团队 | +| 云使用可见性有限 | 优先优化云采用总成本（TCO） | +| 云采用 ROI 和时间线担忧 | 采用标准化、可重复性和自动化 | +| 不愿从旧系统迁移 | 使用容器而非虚拟机部署应用 | +| 安全与合规顾虑 | 考虑多样化部署模型（私有、混合、多云） | +| 云团队/流程/迁移管理复杂性 | 制定详细的云运营指南和协议 | +| 加密和身份认证问题 | 将关键生产工作负载迁移到云 | +| 最小化云系统停机时间 | 确保所有云服务最小停机 | + +**进阶路径**: CCoE → 治理团队 → 标准化 → 自动化 → 容器化 + +--- ### Level 3: Systematic and Documented -- Implemented process or outsourced service to manage cloud subscriptions -- Monitor existing services systematically -- Operations are more efficient and systematic -- Documented practices and compliance in place -- Includes documented cloud management processes and updated operational policies -**Key Challenges:** Ensuring consistency, staff training, effective environment management, workload optimization +**定义**: 组织实施流程或外包服务来管理云订阅和监控现有服务，运营更加高效和系统化。 + +**特征**: +- 已文档化的云管理流程 +- 运营策略已更新 +- 流程和实践系统化 +- 可能外包云管理服务 + +**常见挑战**: + +| 挑战 | 解决方案 | +|------|---------| +| 确保云流程一致性 | 获得对完全 IT 分权的支持 | +| 员工培训提升能力 | 制定全面的应用迁移到目标环境战略 | +| 云环境有效管理 | 增强发布、密钥和策略管理 | +| 分析工作负载优化机会 | 建立稳健的治理和管理实践 | +| 识别适合自动化的任务 | 将所有相关工作负载和数据迁移到云 | +| 环境管理担忧 | 尝试高级云服务（AI、机器学习等） | +| 应用和系统迁移 | 拥抱完全自动化和编排 | + +**⚠️ 警惕**: 许多企业试图跳过 Level 2 和 3，直接从 Level 0/1 到 Level 4。虽然技术驱动的云转型框架使这看起来很诱人，但确保长期可持续性至关重要。 + +**进阶路径**: IT 分权支持 → 迁移战略 → 治理强化 → 自动化 → 高级云服务 + +--- ### Level 4: Measured -- Cloud-native applications used extensively in daily operations -- Widely adopted across organization -- Utilizes private, public, and hybrid cloud platforms -- Often partially reached — some capabilities may still be at levels 2 or 3 -- Transparent governance model to manage and measure cloud operations -- Measuring end-to-end process performance and data usage -**Key Challenge:** Need for governance model when deploying cloud services quickly +**定义**: 组织广泛使用云原生应用，采用私有、公共和混合云平台。 -### Level 5: Optimized (Highest Level) -- Open and interoperable cloud environment -- Actively developed using metrics and data -- Processes are optimized -- Decisions are data-driven -- Adeptly use various cloud platforms -- Flexibly move workloads between platforms +**特征**: +- 云原生应用在日常运营中广泛使用 +- 跨多云平台（私有/公共/混合） +- 透明治理模型管理云运营 +- 端到端流程性能可衡量 +- 数据使用和优化持续改进 -**Reality Check:** Often more aspirational than real. Companies usually lag in optimizing processes and fully leveraging data. Can be overinvestment if extensive hybrid cloud solutions are optional. +**常见挑战**: +- 快速部署云服务时需要治理模型 +- 数据利用需要特定技能和工具优化 +- 部分组织可能仅部分达到 Level 4（某些能力仍在 Level 2/3） -## Common Anti-Pattern: Skipping Levels +**关键成功因素**: +- 透明治理模型 +- 端到端性能测量 +- 数据驱动决策 +- 持续优化文化 -> "Often, businesses try to skip levels 2 and 3, aiming directly from level 0 or 1 to level 4 using technology solutions. While rapid technological change may seem attractive, ensuring long-term sustainability is crucial." +--- -## Key Insights +### Level 5: Optimized -1. **Incremental Progress** — Sustainable cloud maturity requires incremental advancement through each level -2. **Partial Maturity is Normal** — Organizations often partially reach level 4, with some capabilities still at levels 2 or 3 -3. **Not All Levels Are Necessary** — Selectively adopting Level 5 elements that bring clear business benefits may be more practical than full Level 5 achievement -4. **Governance is Critical** — A transparent governance model becomes essential from Level 4 onwards +**定义**: 最高成熟度级别，组织在开放互通的云环境中运营，基于指标和数据积极开发。 -## Related Concepts +**特征**: +- 流程优化，数据驱动决策 +- 熟练使用各种云平台 +- 灵活跨平台迁移工作负载 +- 持续创新和优化 -- [[Cloud-Maturity-Model]] -- [[Cloud-Adoption-Strategy]] -- [[Cloud-Native]] -- [[DevOps-Maturity]] +**⚠️ 现实检视**: +- Level 5 往往比现实更理想化 +- 许多公司可能开发开放互通的云环境 +- 在流程优化和充分利用数据方面通常落后 +- 如果广泛的混合云解决方案是可选的，Level 5 可能是过度投资 -## Sources +**最佳建议**: 不要追求完整的 Level 5，而是选择性采纳能带来明确业务价值的要素。 -- [[sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md]] +## Level Progression Insights + +``` +Level 0 ──→ Level 1 ──→ Level 2 ──→ Level 3 ──→ Level 4 ──→ Level 5 +(无云) (评估) (可重复) (系统化) (可衡量) (优化) + ↑ ↑ ↑ + └──────────────┴──── ⚠️ 跳过级别可能导致 + 后续挑战和不必要的成本 +``` + +## Key Metrics by Level + +| 维度 | Level 1 | Level 2 | Level 3 | Level 4 | Level 5 | +|------|---------|---------|---------|---------|---------| +| 成本优化 | 初始评估 | TCO 分析 | 持续优化 | 自动化调优 | 预测性优化 | +| 自动化 | 手动 | 部分自动化 | 流程自动化 | 编排 | 自主运营 | +| 治理 | 无 | 基础政策 | 文档化治理 | 透明治理 | 动态治理 | +| 安全性 | 基础 | 合规检查 | 主动安全 | 持续监控 | 主动防御 | +| 数据利用 | 有限 | 收集 | 分析 | 洞察 | 预测/AI | + +## See Also + +- [[Cloud Maturity Model]] — 主体框架 +- [[Cloud Adoption Strategy]] — 云采用策略 +- [[DevOps Maturity]] — DevOps 成熟度 +- [[DORA Metrics]] — DORA 指标 +- [[Cloud Governance]] — 云治理 +- [[FinOps]] — 云财务管理 diff --git a/wiki/concepts/Cloud-Native-Maturity-Model.md b/wiki/concepts/Cloud-Native-Maturity-Model.md new file mode 100644 index 00000000..4638e279 --- /dev/null +++ b/wiki/concepts/Cloud-Native-Maturity-Model.md @@ -0,0 +1,134 @@ +# Cloud Native Maturity Model + +> **Cloud Native Maturity Model** — 评估组织在采用云原生技术和服务方面成熟度的框架，基于 CNCF 云原生景观。 + +## Definition + +云原生成熟度模型评估组织在以下方面的成熟度： + +- **容器化和打包** +- **编排和自动化** +- **微服务和 API** +- **可观测性** +- **服务网格** +- **DevOps 实践** + +## CNCF云原生成熟度层级 + +### Level 1: Containerized（容器化） + +**特征** +- 应用程序已容器化（Docker） +- 使用容器镜像仓库 +- 基本的 CI/CD 流水线 + +**成熟度指标** +- [ ] 80%+ 应用已容器化 +- [ ] 标准化基础镜像 +- [ ] 镜像安全扫描集成 + +--- + +### Level 2: Orchestrated（编排） + +**特征** +- Kubernetes 集群管理 +- 自动化部署和扩缩容 +- 基础资源调度 + +**成熟度指标** +- [ ] 生产环境使用 K8s +- [ ] HPA（水平 Pod 自动扩缩容） +- [ ] 命名空间隔离 +- [ ] 基础调度策略 + +--- + +### Level 3: Microservices（微服务） + +**特征** +- 应用程序拆分为微服务 +- 服务间通过 API 通信 +- 异步消息队列使用 +- 服务发现 + +**成熟度指标** +- [ ] 微服务数量 > 10 +- [ ] 12-Factor App 遵循 +- [ ] API 网关使用 +- [ ] 消息队列集成 + +--- + +### Level 4: Meshed（服务网格） + +**特征** +- 服务网格部署（Istio/Linkerd） +- 零信任网络安全 +- 细粒度流量管理 +- 分布式追踪 + +**成熟度指标** +- [ ] 服务网格生产使用 +- [ ] mTLS 强制执行 +- [ ] 金丝雀发布/AB 测试 +- [ ] 分布式追踪完整覆盖 + +--- + +### Level 5: Auto-Pilot（自动驾驶） + +**特征** +- 策略即代码 +- 自动化安全策略执行 +- 自愈能力 +- 智能扩缩容 + +**成熟度指标** +- [ ] OPA/Kyverno 策略强制 +- [ ] 自动故障恢复 +- [ ] 预测性扩缩容 +- [ ] FinOps 自动化 + +## CNCF云原生技术全景 + +### Container Runtime +- containerd, CRI-O + +### Orchestration & Management +- Kubernetes, Helm, Kustomize + +### Coordination & Service Discovery +- etcd, CoreDNS + +### Networking & Service Mesh +- CNI (Calico, Flannel) +- Envoy, Istio, Linkerd + +### Observability +- Prometheus, Grafana, Jaeger, Loki, OpenTelemetry + +### Serverless / Faas +- Knative, OpenFaaS, AWS Lambda, Azure Functions + +### Application Definition +- Helm, Kustomize, OAM, Dapr + +## Assessment Criteria + +| 能力 | L1 | L2 | L3 | L4 | L5 | +|------|----|----|----|----|----| +| **容器化** | Ad-hoc | 标准镜像 | 统一流水线 | 自动化扫描 | 签名验证 | +| **编排** | 手动 | K8s 基础 | 自动部署 | 策略驱动 | 自愈 | +| **架构** | 单体 | 模块化 | 微服务 | 服务网格 | 混合 | +| **网络** | 基础 | VPC | API 网关 | 服务网格 | 零信任 | +| **可观测** | 基础日志 | 指标 | 追踪 | 完整 | 预测 | +| **安全** | 手动 | IAM | 扫描 | 策略即代码 | 自适应 | + +## See Also + +- [[Cloud-Native]] — 云原生核心概念 +- [[Cloud Maturity Model]] — 云成熟度模型 +- [[DevOps Maturity]] — DevOps 成熟度 +- [[Kubernetes]] — Kubernetes +- [[Service Mesh]] — 服务网格 diff --git a/wiki/concepts/Cloud-Native.md b/wiki/concepts/Cloud-Native.md index 0b218218..b9921665 100644 --- a/wiki/concepts/Cloud-Native.md +++ b/wiki/concepts/Cloud-Native.md @@ -1,35 +1,156 @@ # Cloud-Native +> **Cloud-Native** — 一种构建和运行应用程序的方法，充分利用云计算交付模型，将计算、存储和网络作为可弹性扩展的服务。 + ## Definition -Cloud-native is an approach to building and running applications that fully exploits the advantages of cloud computing delivery model. -## Core Characteristics -- **Microservices Architecture**: Applications built as small, independently deployable services -- **Containers**: Lightweight, portable packaging for applications -- **Dynamic Orchestration**: Automated management of containers (e.g., Kubernetes) -- **API-Based Communication**: Services communicate via lightweight APIs -- **DevOps Practices**: Continuous integration and delivery +云原生（Cloud-Native）是一套技术方法论和最佳实践，用于： -## Key Technologies -- **Containers**: Docker, containerd, Podman -- **Orchestration**: Kubernetes, Amazon EKS, Azure AKS, Google GKE -- **Service Mesh**: Istio, Linkerd, Consul Connect -- **Serverless**: AWS Lambda, Azure Functions, Google Cloud Functions +- 构建可在云环境中弹性运行的应用程序 +- 利用云平台的托管服务和自动化能力 +- 采用 DevOps 和 CI/CD 实践 +- 使用容器、无服务器和微服务架构 -## Benefits -- Scalability and elasticity -- Resilience and fault isolation -- Faster deployment cycles -- Resource efficiency -- Portability across cloud providers +## Cloud-Native Computing Foundation (CNCF) -## Sources -- [[sources/cloud-devop-maturity-guideline.md]] +CNCF 定义了云原生的核心技术要素： -## Related Concepts -- [[concepts/DevOps-Maturity]] -- [[concepts/CI-CD-Pipeline]] -- [[concepts/Infrastructure-as-Code]] +``` +Cloud-Native Stack: +├── Container Runtime (containerd, CRI-O) +├── Orchestration (Kubernetes) +├── Service Mesh (Istio, Linkerd) +├── Observability (Prometheus, Grafana) +├── Networking (CNI, Envoy) +└── Storage (CSI) +``` -## Ingested -- Date: 2026-04-21 +## 12-Factor App Methodology + +云原生应用遵循 12-Factor 原则： + +| # | 因素 | 描述 | +|---|------|------| +| 1 | Codebase | 单一代码库，版本控制 | +| 2 | Dependencies | 明确声明依赖 | +| 3 | Config | 配置与环境分离 | +| 4 | Backing Services | 将服务视为资源 | +| 5 | Build, Release, Run | 严格分离构建和运行 | +| 6 | Processes | 无状态进程 | +| 7 | Port Binding | 通过端口绑定导出服务 | +| 8 | Concurrency | 通过进程模型扩展 | +| 9 | Disposability | 快速启动和优雅关闭 | +| 10 | Dev/Prod Parity | 开发、预发、生产环境一致 | +| 11 | Logs | 将日志视为事件流 | +| 12 | Admin Processes | 将管理任务作为一次性进程 | + +## Core Technologies + +### Containers + +**优势** +- 轻量级虚拟化 +- 环境一致性 +- 快速启动 +- 资源隔离 + +**关键工具** +- Docker, containerd, Podman +- OCI 镜像规范 + +### Kubernetes + +**核心概念** +- Pod（最小调度单元） +- Deployment（声明式更新） +- Service（网络抽象） +- Ingress（HTTP 路由） +- ConfigMap/Secret（配置管理） + +**生态组件** +- Helm (包管理) +- Kustomize (配置管理) +- Operators (自愈自动化) + +### Service Mesh + +**功能** +- 零信任网络安全 +- 可观测性（追踪、指标、日志） +- 流量管理（A/B 测试、金丝雀发布） +- 熔断和限流 + +**工具** +- Istio, Linkerd, Consul Connect + +### Serverless + +**优势** +- 零服务器管理 +- 弹性扩展 +- 按使用付费 +- 快速原型 + +**服务** +- AWS Lambda, Azure Functions, GCP Cloud Functions +- Knative, OpenFaaS + +### Observability + +**三大支柱** +- **指标 (Metrics)** — Prometheus, Datadog +- **日志 (Logs)** — ELK Stack, Loki +- **追踪 (Traces)** — Jaeger, Zipkin + +## Cloud-Native Maturity Model + +| Level | 特征 | +|-------|------| +| **L1: Containerized** | 应用程序容器化 | +| **L2: Orchestrated** | 容器编排（K8s） | +| **L3: Microservices** | 微服务架构 | +| **L4: Meshed** | 服务网格 | +| **L5: Auto-Pilot** | 自主运维、自愈 | + +## Cloud-Native vs Traditional + +| 维度 | Cloud-Native | Traditional | +|------|-------------|-------------| +| **架构** | 微服务 | 单体 | +| **部署** | 容器 | 物理机/VM | +| **扩展** | 自动、弹性 | 手动、垂直 | +| **交付** | CI/CD | 传统发布 | +| **可用性** | 多副本 | 主备 | +| **成本** | 按需 | 固定 | +| **恢复** | 自动故障转移 | 手动恢复 | + +## Best Practices + +### Design for Failure + +- 幂等性设计 +- 超时和重试 +- 熔断器模式 +- 限流保护 + +### Observability + +- 结构化日志 +- 分布式追踪 +- 指标和告警 +- 健康检查 + +### Security + +- 零信任架构 +- 最小权限 +- 密钥管理 +- 镜像安全扫描 + +## See Also + +- [[Cloud Maturity Model]] — 云成熟度模型 +- [[DevOps Maturity]] — DevOps 成熟度 +- [[Kubernetes]] — K8s +- [[Microservices]] — 微服务 +- [[Service Mesh]] — 服务网格 diff --git a/wiki/concepts/Cloud-Operating-Model.md b/wiki/concepts/Cloud-Operating-Model.md new file mode 100644 index 00000000..6c7b3084 --- /dev/null +++ b/wiki/concepts/Cloud-Operating-Model.md @@ -0,0 +1,125 @@ +--- +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) diff --git a/wiki/concepts/Cloud-Security-Maturity-Model.md b/wiki/concepts/Cloud-Security-Maturity-Model.md new file mode 100644 index 00000000..57b1da39 --- /dev/null +++ b/wiki/concepts/Cloud-Security-Maturity-Model.md @@ -0,0 +1,148 @@ +# Cloud Security Maturity Model (CSMM) + +> **Cloud Security Maturity Model (CSMM)** — 评估组织云安全计划成熟度的框架，覆盖12个安全领域的3个域。 + +## Definition + +CSMM 是一个供应商中立的安全成熟度评估框架，帮助组织： + +- 评估当前云安全状态 +- 识别安全差距 +- 制定安全改进路线图 +- 量化安全投资回报 + +## CSMM Structure + +### 3 Domains + +| 域 | 描述 | +|----|------| +| **Governance & Strategy** | 安全治理、战略和风险管理 | +| **Technical Controls** | 实施的安全技术和控制 | +| **Operational Processes** | 安全运营流程和实践 | + +### 12 Security Domains + +| 域 | 类别 | +|----|------| +| **Asset Management** | 资产发现、分类、清单 | +| **Compliance Management** | 法规遵从、审计 | +| **Data Security** | 数据分类、加密、生命周期 | +| **Governance & Risk** | 安全策略、风险评估 | +| **Identity & Access** | IAM、特权访问、MFA | +| **Infrastructure Security** | 网络、计算、存储安全 | +| **Application Security** | 安全开发、测试、部署 | +| **Endpoint Security** | 终端保护、EDR | +| **Logging & Monitoring** | SIEM、日志管理、告警 | +| **Incident Response** | 检测、响应、恢复 | +| **Supply Chain Security** | 第三方风险管理 | +| **Human Factors** | 安全意识、培训、文化 | + +## 5 Maturity Levels + +| Level | 名称 | 描述 | +|-------|------|------| +| **1** | Initial | 无正式流程，响应式安全 | +| **2** | Developing | 基础控制，有文档 | +| **3** | Defined | 标准流程，全面覆盖 | +| **4** | Managed | 持续监控，量化管理 | +| **5** | Optimizing | 持续改进，主动防御 | + +## Level Characteristics + +### Level 1: Initial + +- 无正式安全流程 +- 响应式问题处理 +- 依赖个人知识 +- 无安全指标 + +### Level 2: Developing + +- 基本安全策略 +- 有限的 IAM 控制 +- 基础日志记录 +- 安全事件记录 + +### Level 3: Defined + +- 文档化安全策略 +- 全面的 IAM/MFA +- SIEM 部署 +- 安全培训计划 +- 事件响应流程 + +### Level 4: Managed + +- 持续安全监控 +- 自动化安全控制 +- KPI 追踪 +- 定期渗透测试 +- 威胁情报集成 + +### Level 5: Optimizing + +- AI/ML 驱动的安全 +- 自动化响应 +- 预测性威胁分析 +- 零信任架构 +- 安全即代码 + +## Assessment Areas + +### Governance & Strategy + +| 评估项 | 成熟度等级 | +|--------|-----------| +| 安全策略文档 | L1-L5 | +| 风险评估流程 | L1-L5 | +| 安全指标和报告 | L3-L5 | +| 董事会参与 | L4-L5 | + +### Technical Controls + +| 评估项 | 成熟度等级 | +|--------|-----------| +| IAM/MFA | L2-L5 | +| 网络分段 | L2-L5 | +| 数据加密 | L3-L5 | +| 容器安全 | L3-L5 | +| 云安全态势管理 | L4-L5 | + +### Operational Processes + +| 评估项 | 成熟度等级 | +|--------|-----------| +| 漏洞管理 | L2-L5 | +| 事件响应 | L3-L5 | +| 安全运营 | L4-L5 | +| 合规监控 | L3-L5 | + +## Implementation + +### Step 1: Assessment +- 自我评估或第三方评估 +- 问卷调查 +- 技术验证 + +### Step 2: Gap Analysis +- 对标 CSMM 成熟度等级 +- 识别优先改进项 + +### Step 3: Roadmap +- 制定改进计划 +- 分配资源和责任 +- 设定时间线 + +### Step 4: Execution +- 实施安全改进 +- 持续监控进度 +- 定期复盘 + +## See Also + +- [[Cloud Security]] — 云安全 +- [[Cloud Governance]] — 云治理 +- [[Cloud Maturity Model]] — 云成熟度模型 +- [[Zero Trust]] — 零信任 +- [[CSPM]] — 云安全态势管理 diff --git a/wiki/concepts/Compliance-Automation.md b/wiki/concepts/Compliance-Automation.md new file mode 100644 index 00000000..5bac8f04 --- /dev/null +++ b/wiki/concepts/Compliance-Automation.md @@ -0,0 +1,69 @@ +# Compliance Automation + +## Definition +Compliance automation uses technology to automatically enforce, monitor, and validate security and regulatory compliance requirements. + +## Aliases +- Automated Compliance +- Policy Automation +- Regulatory Automation + +## Concept +合规自动化使用技术手段自动执行、监控和验证安全及监管合规要求。 + +## Key Frameworks + +### SOC 2 +System and Organization Controls 2 — 针对服务组织的安全、可用性、处理完整性、保密性和隐私控制的合规框架。 + +### ISO 27001 +国际信息安全管理体系标准，提供建立、实施、维护和持续改进信息安全管理系统的要求。 + +### GDPR +欧盟通用数据保护条例，规定个人数据处理和隐私保护要求。 + +### HIPAA +美国医疗健康信息隐私法规，保护医疗信息的机密性、完整性和可用性。 + +## Automation Tools +- Chef InSpec — 合规即代码 +- Ansible — 配置和合规自动化 +- AWS Config — 云资源合规 +- Azure Policy — Azure 合规 +- Terraform Sentinel — IaC 合规 + +## Implementation + +### Policy as Code +```ruby +# Chef InSpec 示例 +control 'cis-aws-foundations-1.1' do + impact 1.0 + title 'Ensure MFA is enabled for all IAM users' + describe aws_iam_users.where(attached_managed_policies: []) do + its('entries') { should eq [] } + end +end +``` + +### Continuous Compliance +- 实时监控配置状态 +- 自动修复违规 +- 合规报告生成 + +## Benefits +- 减少人工审计成本 +- 持续合规而非间歇性合规 +- 快速响应监管变化 +- 减少人为错误 + +## Related Concepts +- [[DevSecOps]] — 合规自动化是 DevSecOps 的重要组成 +- [[Policy-as-Code]] — 以代码管理策略 +- [[ISO-27001]] — 信息安全管理标准 +- [[HIPAA]] — 医疗健康合规 +- [[GDPR]] — 数据保护法规 +- [[Continuous-Compliance]] — 持续合规 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Configuration-Management.md b/wiki/concepts/Configuration-Management.md new file mode 100644 index 00000000..c1ebe504 --- /dev/null +++ b/wiki/concepts/Configuration-Management.md @@ -0,0 +1,72 @@ +--- +title: "Configuration Management" +type: concept +tags: [itsm, devops, operations] +date: 2025-03-01 +--- + +## Definition + +配置管理（Configuration Management）是[[ITSM]]的核心流程之一，负责**识别、记录、控制和追踪IT环境中的所有配置项（Configuration Items, CI）及其关系**，为变更影响分析和事件诊断提供基础数据。 + +## Configuration Item Types + +| CI类型 | 示例 | +|--------|------| +| Hardware | 服务器、网络设备、存储 | +| Software | 操作系统、应用、中间件 | +| Documentation | 架构图、流程文档 | +| People | 运维人员、服务所有者 | +| Services | 应用服务、API接口 | + +## Configuration Management Process + +``` +┌──────────────┐ ┌──────────────┐ ┌──────────────┐ +│ CI │ → │ Relationship│ → │ Impact │ +│ Discovery │ │ Mapping │ │ Analysis │ +└──────────────┘ └──────────────┘ └──────────────┘ + ↓ ↓ ↓ + Auto Scan Dependency Change Planning + + Manual Entry Graph + Incident RCA +``` + +## Modern Configuration Management (ITSM 2.0) + +在[[ITSM 2.0]]中，配置管理由AI驱动的[[CMDB]]支撑： + +### AI-Enhanced Capabilities + +| 能力 | 描述 | 价值 | +|------|------|------| +| Dependency Mapping | 自动发现服务依赖 | 变更影响分析 | +| Drift Detection | 配置漂移实时检测 | 安全合规 | +| Real-time Impact Analysis | 实时影响分析 | 快速决策 | +| Multi-cloud Orchestration | 多云配置管理 | 统一视图 | + +### [[CMDB]] in Action + +``` +Multi-cloud Environment +├── Public Cloud (AWS/Azure/GCP) +├── Private Cloud (VMware/OpenStack) +└── Hybrid Environment + ↓ + AI-CMDB + ├── 自动发现CI + ├── 关系映射 + ├── 漂移检测 + └── 影响预测 +``` + +## Related Concepts + +- [[ITSM]] — 父框架 +- [[CMDB]] — 配置管理数据库 +- [[Change-Management]] — 变更管理 +- [[Multi-Cloud]] — 多云环境 +- [[IaC]] — 基础设施即代码 + +## Sources + +- [[understanding-complete-itsm]] — AI-powered CMDB for Configuration Management diff --git a/wiki/concepts/Cron定时任务.md b/wiki/concepts/Cron定时任务.md new file mode 100644 index 00000000..f7ed6a8d --- /dev/null +++ b/wiki/concepts/Cron定时任务.md @@ -0,0 +1,98 @@ +--- +title: "Cron定时任务" +tags: [linux, automation, devops, ubuntu] +date: 2026-04-26 +--- + +# Cron定时任务 (Cron Job) + +## Definition +Cron 是 Linux/Unix 系统的定时任务调度器，允许用户配置在指定时间自动执行命令或脚本。Cron 通过 crontab（cron table）配置文件管理所有定时任务。 + +## Basic Format +``` +┌───────────── 分钟 (0-59) +│ ┌───────────── 小时 (0-23) +│ │ ┌───────────── 日期 (1-31) +│ │ │ ┌───────────── 月份 (1-12) +│ │ │ │ ┌───────────── 星期 (0-7, 0和7都是周日) +│ │ │ │ │ +* * * * * command +``` + +## Examples + +### 每日凌晨3点执行备份 +``` +0 3 * * * /usr/local/bin/rsync_backup.sh +``` + +### 每6小时执行一次 +``` +0 */6 * * * /path/to/script.sh +``` + +### 每周日凌晨2点执行 +``` +0 2 * * 0 /path/to/weekly_backup.sh +``` + +### 每月的第一天凌晨4点执行 +``` +0 4 1 * * /path/to/monthly_backup.sh +``` + +## Crontab Commands +```bash +# 编辑当前用户的 crontab +crontab -e + +# 查看当前用户的 crontab +crontab -l + +# 删除当前用户的 crontab +crontab -r + +# 以 root 身份编辑系统 crontab +sudo crontab -e +``` + +## Best Practices for Backup Jobs + +### 1. 使用绝对路径 +Cron 任务的执行环境与交互式 shell 不同，PATH 环境变量可能不完整： +```bash +0 3 * * * /usr/local/bin/rsync_backup.sh # ✅ 使用绝对路径 +``` + +### 2. 使用 nohup 确保后台运行 +```bash +0 3 * * * sudo nohup /usr/local/bin/rsync_backup.sh > /dev/null 2>&1 & +``` + +### 3. 使用锁文件防止重复执行 +```bash +LOCKFILE="/tmp/rsync_backup.lock" +if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then + echo "备份任务已在运行中，跳过本次执行。" + exit +fi +echo $$ > ${LOCKFILE} +``` + +### 4. 日志记录 +```bash +LOG="/var/log/rsync_backup.log" +echo "--- 开始备份: $(date) ---" >> "$LOG" +rsync -azR ... >> "$LOG" 2>&1 +``` + +## Related Concepts +- [[增量备份]] — Cron 定时任务自动执行增量备份 +- [[进程管理]] — 后台进程的控制与监控 +- [[挂载点检查]] — 备份前的安全检查 +- [[永久挂载]] — 确保 Cron 任务执行时存储可用 + +## See Also +- [[Disaster-Recovery]] — Cron 任务实现自动化的灾备恢复点 +- [[RTO]] — Cron 任务频率影响恢复时间目标 diff --git a/wiki/concepts/Cross-Account-Monitoring.md b/wiki/concepts/Cross-Account-Monitoring.md new file mode 100644 index 00000000..6946055b --- /dev/null +++ b/wiki/concepts/Cross-Account-Monitoring.md @@ -0,0 +1,45 @@ +--- +title: Cross-Account Monitoring +type: concept +tags: [AWS, Security, CloudOps, Multi-Account] +date: 2025-10-24 +--- + +## Definition +Cross-Account Monitoring（跨账户监控）是指在 AWS 多账户环境中，通过安全配置的跨账户访问机制，实现对分布在多个账户的资源、日志和指标的集中监控能力。是 AWS 多账户策略的核心运营支柱之一。 + +## Core Properties +- **最小权限原则**：仅授予必要的跨账户读取权限 +- **集中可见性**：单一管理界面覆盖所有账户 +- **安全边界**：IAM 角色信任策略定义清晰的信任边界 +- **审计追踪**：所有跨账户访问均留下 CloudTrail 记录 + +## AWS Implementation Mechanisms +- **AWS Organizations + SCPs**：通过 Service Control Policies 定义账户权限边界 +- **IAM Cross-Account Roles**：跨账户角色切换实现安全访问 +- **Amazon EventBridge**：事件驱动的跨账户事件转发（该方案的核心机制） +- **AWS CloudWatch Cross-Account Observability**：CloudWatch 原生跨账户可观测性 +- **AWS Security Hub**：跨账户安全态势集中管理 + +## Related Concepts +- [[AWS Organizations]]：提供多账户层级结构，是跨账户监控的基础设施 +- [[Multi-Account Deployment]]：跨账户监控支撑多账户部署的可观测性 +- [[Centralized Logging]]：集中日志是跨账户监控的数据基础 +- [[StackSets Deployment Visibility]]：StackSets 部署监控是跨账户监控的具体应用场景 +- [[Landing Zone Architecture]]：AWS Landing Zone 推荐架构中包含跨账户监控设计 +- [[DevSecOps]]：跨账户安全监控是 DevSecOps 的重要组成部分 + +## Architecture Patterns +1. **Hub-and-Spoke**：管理账户作为中心（Hub），成员账户作为辐射（Spoke） +2. **Event-Driven Fan-out**：通过 EventBridge 将事件从各账户汇聚到管理账户 +3. **Aggregated Dashboards**：Grafana/CloudWatch Dashboards 聚合多账户视图 +4. **Centralized Alerting**：告警规则在管理账户统一定义，跨账户触发 + +## AWS Context +- AWS Organizations Management Account：管理账户，通常承载中心监控功能 +- AWS Organizations Member Accounts：成员账户，被监控的资源所在 +- Organizational Units (OUs)：组织单元，用于分组管理成员账户 +- Trusted Access：AWS StackSets 受信任访问，允许多账户协调操作 +- [[Cross-Account Monitoring]] ← enabled_by ← [[AWS Organizations]] Trusted Access +- [[Cross-Account Monitoring]] ← uses ← [[Amazon EventBridge]] Custom Event Bus +- [[Cross-Account Monitoring]] ← stores ← [[CloudWatch Logs (central-cloudformation-logs)]] diff --git a/wiki/concepts/DAST.md b/wiki/concepts/DAST.md new file mode 100644 index 00000000..778a4a97 --- /dev/null +++ b/wiki/concepts/DAST.md @@ -0,0 +1,64 @@ +# 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]] diff --git a/wiki/concepts/DRaaS.md b/wiki/concepts/DRaaS.md new file mode 100644 index 00000000..d6b8e6a4 --- /dev/null +++ b/wiki/concepts/DRaaS.md @@ -0,0 +1,77 @@ +--- +title: "Disaster Recovery as a Service (DRaaS)" +type: concept +tags: [cloud, disaster-recovery, business-continuity, security] +date: 2025-03-01 +--- + +## Definition + +灾备即服务（DRaaS）是一种云原生灾难恢复解决方案，提供基于云的故障转移能力，使组织能够快速恢复关键业务系统，同时降低传统灾备基础设施的成本和复杂性。 + +## Core Metrics + +### RTO (Recovery Time Objective) +- 灾难发生后系统恢复的最大可接受时间 +- [[ITSM]]中业务连续性的关键指标 + +### RPO (Recovery Point Objective) +- 最大可容忍的数据丢失时间窗口 +- 决定备份频率和策略 + +## DRaaS vs Traditional DR + +| 维度 | 传统灾备 | DRaaS | +|------|---------|-------| +| 成本 | 高CAPEX | 按需付费 | +| 恢复速度 | 小时/天 | 分钟 | +| 复杂度 | 高 | 托管服务 | +| 测试 | 困难 | 自动化测试 | +| 可扩展性 | 有限 | 云弹性 | + +## Key Features (Modern DRaaS) + +### AI-Driven Automated Failover +``` +监控检测 → 故障确认 → 自动触发 → 故障转移 → 服务恢复 + ↓ ↓ ↓ ↓ ↓ + AIOps ML模型 策略执行 DNS切换 健康检查 +``` + +### Multi-Cloud Support +- 跨云故障转移 +- 混合云灾备 +- 数据主权合规 + +## In ITSM Context + +在[[ITSM]]中，DRaaS是[[Disaster-Recovery]]流程的核心： + +``` +Disaster Recovery & Business Continuity (ITSM 8.0) +├── AI-driven Automated Failover +│ ├── 智能故障检测 +│ ├── 策略驱动的故障转移 +│ └── 自动服务恢复 +├── RTO/RPO Optimization +│ ├── 连续复制 +│ ├── 增量备份 +│ └── 快速恢复 +└── Cloud-native DRaaS + ├── 按需扩展 + ├── 托管服务 + └── 成本优化 +``` + +## Related Concepts + +- [[Disaster-Recovery]] — 灾备总框架 +- [[RTO]] — 恢复时间目标 +- [[RPO]] — 恢复点目标 +- [[Failover]] — 故障转移机制 +- [[Business-Impact-Analysis]] — 业务影响分析 + +## Sources + +- [[understanding-complete-itsm]] — DRaaS在现代ITSM中的应用 +- [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]] — RTO/RPO详解 diff --git a/wiki/concepts/Data-Governance.md b/wiki/concepts/Data-Governance.md new file mode 100644 index 00000000..1d99faff --- /dev/null +++ b/wiki/concepts/Data-Governance.md @@ -0,0 +1,74 @@ +--- +title: "Data Governance (Cloud)" +type: concept +tags: [cloud-computing, governance, data-management] +date: 2025-03-02 +--- + +# Data Governance (Cloud) + +**Data Governance**（数据治理）是云平台提供的用于管理、监控和保护数据的工具和策略，确保企业对其数据拥有完全的控制权。 + +## Definition + +云数据治理涵盖数据的整个生命周期：创建、存储、使用、共享、归档和销毁。核心目标是确保数据的安全性、完整性和合规性。 + +## Key Components + +### 1. Access Control +- 基于角色的访问控制（RBAC） +- 基于属性的访问控制（ABAC） +- 最小权限原则 +- 定期访问审查 + +### 2. Data Encryption +- 传输中加密（TLS 1.3） +- 静态加密（AES-256） +- 客户管理密钥（CMK） +- 密钥管理服务（KMS） + +### 3. Audit & Monitoring +- 访问日志（CloudTrail, Azure Monitor, Cloud Logging） +- 实时告警 +- 合规报告 +- 数据血缘追踪 + +### 4. Data Classification +- 敏感数据识别 +- 数据标签/标记 +- 自动分类 +- 基于分类的策略执行 + +### 5. Retention & Lifecycle +- 数据保留策略 +- 自动归档 +- 安全删除 +- 合规保留 + +## Cloud Myths Context + +数据治理能力是反驳"云中失去数据控制"误解的核心证据： +- 云平台提供细粒度的权限管理，企业完全控制谁能访问什么数据 +- 混合云和多云选项允许企业决定数据存储位置 +- 审计日志提供完整的访问追踪能力 + +## Cloud Provider Tools + +| Provider | Key Tools | +|----------|-----------| +| **AWS** | IAM, KMS, CloudTrail, Macie, S3 Access Points | +| **Azure** | Azure AD, Key Vault, Purview, Defender for Cloud | +| **Google Cloud** | IAM, Cloud KMS, Cloud Audit Logs, DLP API | + +## Related Concepts + +- [[cloud-computing]] — 云计算 +- [[cloud-security]] — 云安全 +- [[Data-Sovereignty]] — 数据主权 +- [[Compliance]] — 合规 +- [[Identity-and-Access-Management]] — 身份与访问管理 +- [[Cloud-Governance]] — 云治理 + +## Sources + +- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/concepts/Deployment-Automation.md b/wiki/concepts/Deployment-Automation.md new file mode 100644 index 00000000..a1d962b5 --- /dev/null +++ b/wiki/concepts/Deployment-Automation.md @@ -0,0 +1,75 @@ +--- +title: "Deployment Automation" +tags: + - devops + - cicd + - automation + - ai +created: 2026-04-25 +--- + +# Deployment Automation + +## Definition + +Deployment Automation 是通过自动化工具和 AI 代理实现软件部署的**全流程自动化**（构建 → 测试 → 发布 → 回滚）。Agentic AI 作为 Release Manager，自动执行部署策略（蓝绿/金丝雀）和回滚决策。 + +## Agentic AI 作为 Release Manager + +``` +传统 Release Manager: +人工决策 → 发布窗口 → 人工监控 → 人工回滚（可能延迟数小时） + +Agentic AI Release Manager: +实时分析 → 自动决策 → 持续发布 → 毫秒级自动回滚 +``` + +### 核心职责 + +| 职责 | 传统方式 | AI Release Manager | +|------|---------|-------------------| +| Feature Flag 测试 | 人工配置 | AI 自动分析指标 + 动态调整 | +| 部署策略选择 | 人工决策 | AI 基于流量/错误率选择 | +| 回滚触发 | 人工判断（延迟高） | AI 毫秒级自动触发 | +| 部署后验证 | 人工检查 | AI 持续监控 + 自动验证 | + +### 部署策略 + +- **Blue/Green**: 两套环境，AI 监控 + 自动切换 +- **Canary**: 灰度流量，AI 动态调整流量比例 +- **Rolling**: 滚动更新，AI 监控 + 自动暂停/回滚 + +## 与 [[CI/CD Pipeline]] 的关系 + +Agentic AI 增强 [[CI/CD Pipeline]] 的关键阶段： + +```python +CI_CD_Stages = { + "Build": "CI Server (Jenkins/GitHub Actions)", # 保持不变 + "Test": "AI: 自动缺陷预测 + 智能测试选择", + "Deploy": "AI Release Manager ←", # ← 本页 + "Monitor": "AI: 实时监控 + 自动回滚", + "Verify": "AI: 自动回归验证" +} +``` + +## 示例 + +> An AI agent detects that a new microservice deployment is causing latency issues: +> - Error rate spikes from 0.1% to 2.3% within 5 minutes +> - AI automatically rolls back the changes +> - AI generates fix suggestion: "Connection pool misconfiguration detected" +> - AI submits ticket with root cause analysis + +## Related Concepts + +- [[CI/CD Pipeline]] — Deployment Automation 的基础 +- [[Self-Healing Systems]] — 自动回滚是 Self-Healing 的体现 +- [[DORA Metrics]] — Deployment Automation 直接改善 Deployment Frequency 和 Change Failure Rate +- [[Blue-Green Deployment]] — 具体部署策略之一 +- [[Canary Deployment]] — 具体部署策略之一 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] +- [[cloud-devop-maturity-guideline]] diff --git a/wiki/concepts/Deployment-vs-Release.md b/wiki/concepts/Deployment-vs-Release.md new file mode 100644 index 00000000..e2e22581 --- /dev/null +++ b/wiki/concepts/Deployment-vs-Release.md @@ -0,0 +1,102 @@ +--- +title: "Deployment vs Release (部署与发布分离)" +tags: [devops, continuous-delivery, feature-management, release-management] +aliases: [Decoupled Deployment and Release] +created: 2026-04-25 +--- + +# Deployment vs Release (部署与发布分离) + +**Deployment vs. Release** 是 [[Feature Flag]] 实现的核心理念：代码**部署**（Deploy）到生产环境，与功能对用户**可见**（Release），是两个独立的事件。 + +## Definition + +> "Traditional deployments are all-or-nothing: you push code and everyone gets it immediately. This is why deployments are scary and why teams deploy at 2 AM 'just in case.'" + +> "Deploy whenever you want, release when you're ready." + +## Aliases +- Decoupled Deployment and Release +- 部署发布分离 + +## 核心对比 + +| 维度 | 传统方式（部署=发布） | Feature Flag（部署≠发布） | +|------|---------------------|--------------------------| +| 代码到达生产 | 与用户可见同步 | 提前到达，用户不可见 | +| 回滚能力 | 需要重新部署 | 配置变更，秒级 | +| 发布时机 | 必须与部署同步 | 任意时刻可发布 | +| 团队压力 | 2AM 部署"以防万一" | 白天从容发布 | +| 实验能力 | 低（全量或无） | 高（灰度、可控放量） | + +## 生命周期对比 + +### 传统方式 + +``` +开发 → 测试 → 合并 → 部署 → 发布（全量） + ↑ + 部署=发布 +``` + +### Feature Flag 方式 + +``` +开发 → 测试 → 合并 → 部署 → 发布控制 → 渐进放量 + ↑ ↑ + 代码到达 用户可见 + 生产环境 由开关控制 +``` + +## 关键价值 + +### 1. 降低部署风险 +> "Feature flags change this. You can deploy code to production without releasing it to users." + +代码可以在生产环境中就绪，但功能对用户保持隐藏，直到团队确认质量。 + +### 2. 加速交付 +团队不再需要等待"完美时机"发布功能。代码就绪即可部署，功能发布由业务决定。 + +### 3. 赋能团队 +- 产品：随时决定发布节奏 +- 工程：随时部署，无需等待发布窗口 +- 运营：渐进放量，数据驱动决策 + +### 4. 重新定义 RTO +当部署≠发布时，恢复（Rollback）不再是回滚部署，而是关闭 Feature Flag。 + +## 与 [[CI-CD-Pipeline]] 的关系 + +部署与发布的分离重构了 CI/CD 流程： + +| 阶段 | 传统 CI/CD | Decoupled CI/CD | +|------|-----------|-----------------| +| Build | 构建产物 | 构建产物 | +| Test | 单元/集成测试 | 单元/集成测试 | +| Deploy | 部署到 prod | 部署到 prod（用户不可见） | +| Release | — | Feature Flag 控制 | +| Monitor | 部署后监控 | 渐进放量期间监控 | +| Rollback | 重新部署旧版本 | 关闭 Feature Flag | + +## 风险模型转变 + +| 维度 | 传统模型 | Decoupled 模型 | +|------|----------|----------------| +| 风险集中点 | 部署时刻 | 功能发布时刻 | +| 风险暴露范围 | 全量用户 | 当前放量比例 | +| 应急响应 | 小时级回滚 | 秒级开关 | +| 团队心态 | 防御性（害怕部署） | 进攻性（敢于实验） | + +## Related Concepts + +- [[Feature Flag]] — 实现部署与发布分离的核心机制 +- [[CI-CD-Pipeline]] — Decoupled Deployment 是现代 CI/CD 的重要理念 +- [[Progressive Rollout]] — 部署与发布分离使渐进放量成为可能 +- [[Kill Switch]] — 发布控制权的极端体现（紧急关闭） +- [[RTO]] — 部署与发布分离将 RTO 从部署回滚转向配置变更 +- [[Micro-Recovery]] — 部署与发布分离使 feature 级别恢复成为可能 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/DevSecOps.md b/wiki/concepts/DevSecOps.md index 20d5990c..7cd00428 100644 --- a/wiki/concepts/DevSecOps.md +++ b/wiki/concepts/DevSecOps.md @@ -1,49 +1,61 @@ # DevSecOps ## Definition -DevSecOps integrates security practices into the DevOps process, embedding security throughout the entire software development lifecycle rather than treating it as a separate phase. +DevSecOps（Development-Security-Operations）是将安全实践深度集成到软件开发全生命周期的方法论，使安全成为开发、运维、安全团队的共同责任，而非独立环节。 -## Key Principles -- **Shift Left**: Integrate security early in the development process -- **Automation**: Security checks automated in CI/CD pipelines -- **Continuous Compliance**: Ongoing security validation and compliance monitoring -- **Proactive Vulnerability Management**: Early detection and remediation of security issues +## Core Principles +- **安全即代码**：安全策略、测试和合规检查均以代码形式实现 +- **共享责任**：安全是每个人的责任，而非仅安全团队的工作 +- **自动化优先**：通过自动化减少人为错误，提高安全检查效率 +- **持续安全**：安全贯穿开发、测试、部署、运营全阶段 -## Core Practices -- Static Application Security Testing (SAST) -- Dynamic Application Security Testing (DAST) -- Software Composition Analysis (SCA) -- Container security scanning -- Infrastructure as Code security validation -- Secret management and rotation +## Key Components -## Tools -- SAST: SonarQube, Checkmarx, Semgrep -- Container scanning: Trivy, Clair, Snyk -- Secret management: HashiCorp Vault, AWS Secrets Manager +### 1. Collaboration（协作） +安全任务在开发和运维团队间共享，安全团队确保安全标准嵌入整个开发流程。 -## Security Progression Across DevOps Maturity Levels +### 2. Communication（沟通） +安全专业人员需要用开发者理解的简单语言解释安全控制，建立共同的安全认知。 -| Maturity | Security Integration Level | -|----------|--------------------------| -| Phase 1 | Security involvement only weeks before release, minimal compliance scans | -| Phase 2 | Security operates separately from the rest of the team | -| Phase 3 | Security involved in design, architecture, and operations discussions; scans integrated throughout development | -| Phase 4 | Dependency vulnerability management; continuous security monitoring across the team | -| Phase 5 | Prevent insecure/non-compliant code from reaching production; high-level security integration | +### 3. Automation（自动化） +- 将自动化安全测试添加到 CI/CD 管道 +- "Break the Build" 机制在安全风险过高时停止构建 +- 确保软件依赖保持最新 -## Sources -- [[sources/cloud-devop-maturity-guideline.md]] -- [[sources/what-is-devsecops-best-practices-benefits-and-tools.md]] -- [[sources/devops-maturity-model-from-traditional-it-to-advanced-devops.md]] +### 4. Tool & Architecture Security（工具与架构安全） +- 选择和审查安全工具 +- 谨慎管理用户访问（多因素认证、最小权限） +- 定期监控漏洞和打补丁 +- 扫描代码中的敏感数据 + +### 5. Testing（测试） +在每个开发阶段集成安全测试，使用 SAST/DAST/IAST/SCA 等工具。 + +## DevSecOps vs DevOps + +| 维度 | DevOps | DevSecOps | +|------|--------|-----------| +| **定义** | 强调开发与运维协作加速交付 | 将安全实践集成到开发过程 | +| **安全角色** | 安全单独处理或最后处理 | 从一开始就将安全嵌入每个步骤 | +| **团队参与** | 开发与运维协作 | 开发、运维、安全三方协作 | +| **合规方式** | 开发后进行合规检查 | 开发部署全程确保合规 | + +## Benefits +- 早期发现漏洞，修复成本降低可达 100 倍 +- 70% 的上线后发现的安全漏洞可在开发阶段预防 +- 安全与开发速度实现双赢 +- 持续合规，减少审计压力 ## Related Concepts -- [[concepts/DevOps-Maturity]] -- [[concepts/CI-CD-Pipeline]] -- [[concepts/Infrastructure-as-Code]] -- [[concepts/DORA-Metrics]] -- [[concepts/Change-Failure-Rate]] +- [[Shift-Left-Security]] — 安全测试左移到开发早期 +- [[Shift-Right-Security]] — 生产环境持续安全监控 +- [[SAST]] — 静态应用安全测试 +- [[DAST]] — 动态应用安全测试 +- [[IAST]] — 交互式应用安全测试 +- [[SCA]] — 软件组成分析 +- [[CI/CD Pipeline]] — DevSecOps 的载体 +- [[Policy-as-Code]] — 以代码管理安全策略 +- [[Break-the-Build]] — 安全失败时停止构建 -## Ingested -- Date: 2026-04-21 -- Date: 2026-04-24 (updated with maturity level progression) +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Docker-Compose.md b/wiki/concepts/Docker-Compose.md new file mode 100644 index 00000000..669001b1 --- /dev/null +++ b/wiki/concepts/Docker-Compose.md @@ -0,0 +1,56 @@ +# Docker Compose + +## Description +Docker Compose 是 Docker 官方提供的多容器 Docker 应用定义和运行工具。通过 `docker-compose.yml`（或 `compose.yaml`）配置文件，使用 YAML 格式声明式定义多容器服务的网络、卷、端口映射、环境变量等，实现一键部署复杂应用。 + +## Version +- **V1 (独立包)**：`docker-compose` 命令（已弃用） +- **V2 (插件)**：`docker compose` 命令（当前主流），通过 `docker-compose-plugin` 包安装，集成到 Docker CLI + +## V1 vs V2 Command Reference +| V1 (独立包) | V2 (插件) | +|------------|-----------| +| `docker-compose up -d` | `docker compose up -d` | +| `docker-compose ps` | `docker compose ps` | +| `docker-compose down` | `docker compose down` | +| `docker-compose -f xxx.yml config` | `docker compose -f xxx.yml config` | + +## Core Concepts +- **Services**: 定义每个容器服务（镜像、构建、端口、卷、环境变量） +- **Volumes**: 命名数据卷，持久化容器数据 +- **Networks**: 容器网络配置（bridge、host、overlay） +- **Version**: `version: '3.8'` 为当前主流版本规范 + +## Example +```yaml +version: '3.8' +services: + it-tools: + image: corentinth/it-tools:latest + container_name: it-tools + restart: unless-stopped + stdin_open: true + tty: true + ports: + - "8999:80" + deploy: + resources: + limits: + memory: 128M +``` + +## Used By +- [[用docker安装it-tools]] +- [[用docker安装transmission]] +- [[Navidrome]] +- [[Jellyfin]] +- [[RSSHub]] + +## Related Concepts +- [[Docker-Image]] +- [[Docker-Save]] +- [[Docker-Load]] +- [[容器资源限制]] +- [[容器重启策略]] +- [[端口映射]] +- [[桥接网络]] diff --git a/wiki/concepts/Docker-用户组.md b/wiki/concepts/Docker-用户组.md new file mode 100644 index 00000000..8ba91a52 --- /dev/null +++ b/wiki/concepts/Docker-用户组.md @@ -0,0 +1,38 @@ +--- +title: "Docker 用户组" +tags: [docker, security, permissions] +date: 2026-04-22 +--- + +# Docker 用户组 + +## Definition +Docker 用户组是 Linux 系统中的用户组机制，允许组成员无需 `sudo` 前缀直接运行 Docker 命令。 + +## Configuration +```bash +# 将用户添加到 docker 用户组 +sudo usermod -aG docker $USER + +# 刷新组成员资格（需重新登录或重启终端） +newgrp docker +# 或直接登出再登入 +``` + +## Security Implications +⚠️ **安全警告**：docker 用户组成员拥有与 root 用户等效的权限，因为 Docker 容器默认以 root 身份运行。攻击者如果能访问 docker 用户组的成员账户，可能通过容器逃逸获得宿主机 root 权限。 + +## Best Practices +1. 仅将受信任的用户添加到 docker 用户组 +2. 优先使用非 root 用户运行容器（`PUID/PGID` 环境变量） +3. 定期审查 docker 用户组成员 +4. 考虑使用 Podman 作为替代方案（支持无 root 模式） + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] — docker 用户组配置步骤 + +## Related Concepts +- [[Docker Engine]] — 被无 sudo 访问的组件 +- [[用户权限]] — Linux 用户组机制 +- [[容器资源限制]] — 配合非 root 用户的安全实践 +- [[PUID/PGID]] — Docker 容器的非 root 用户映射 diff --git a/wiki/concepts/Event-Correlation.md b/wiki/concepts/Event-Correlation.md new file mode 100644 index 00000000..bb54ee34 --- /dev/null +++ b/wiki/concepts/Event-Correlation.md @@ -0,0 +1,85 @@ +--- +title: "Event Correlation" +type: concept +tags: [aiops, monitoring, incident-management, operations] +date: 2025-03-01 +--- + +## Definition + +事件关联（Event Correlation）是[[AIOps]]的核心技术之一，通过算法将大量分散的监控告警和系统事件归类为少量有意义的事件组，减少告警噪音，加速[[Incident-Management]]和[[Root-Cause-Analysis]]。 + +## The Problem + +``` +Without Event Correlation: +───────────────────────────── +Alert #1: CPU High on Server A +Alert #2: Memory High on Server A +Alert #3: Disk I/O High on Server A +Alert #4: Network Latency on Server A +Alert #5: App Response Slow +Alert #6: Database Connection Pool Full +Alert #7: API Timeout +... (100+ alerts for ONE root cause) +``` + +## Event Correlation Techniques + +### 1. Rule-Based Correlation +``` +IF alerts occur within time window T +AND involve same source/host/service +THEN group as single incident +``` + +### 2. Statistical Correlation +- Time series analysis +- Pattern matching +- Anomaly detection + +### 3. AI/ML Correlation +- Root cause inference +- Causal graph models +- Predictive correlation + +## Benefits + +| 收益 | 描述 | +|------|------| +| 告警降噪 | 减少90%+噪音 | +| 加速RCA | 快速定位根因 | +| MTTR降低 | 减少人工分析时间 | +| SLA保障 | 更快响应 | + +## In ITSM Context + +在[[ITSM 2.0]]的[[Incident-Management]]中，事件关联是关键能力： + +``` +Incident Management 2.0 +├── Event Correlation (ML-enhanced) +│ ├── 告警去重 +│ ├── 根因推断 +│ └── 关联推理 +├── AIOps-powered Analysis +│ ├── 异常检测 +│ ├── 模式识别 +│ └── 预测分析 +└── Self-Healing Automation + ├── 自动诊断 + └── 自动修复 +``` + +## Related Concepts + +- [[AIOps]] — 事件关联的AI引擎 +- [[Incident-Management]] — 事件管理的应用场景 +- [[Root-Cause-Analysis]] — 根因分析 +- [[MTTR]] — 平均恢复时间 +- [[Self-Healing-Systems]] — 自愈系统 + +## Sources + +- [[understanding-complete-itsm]] — ML-enhanced Event Correlation +- [[what-i-know-about-cloud-service-delivery-1]] — AIOps中的事件关联 diff --git a/wiki/concepts/Exporter.md b/wiki/concepts/Exporter.md new file mode 100644 index 00000000..418be772 --- /dev/null +++ b/wiki/concepts/Exporter.md @@ -0,0 +1,64 @@ +--- +title: "Exporter" +type: concept +aliases: [Prometheus Exporter, 指标导出器, Prometheus指标导出器] +tags: [prometheus, monitoring, metrics, infrastructure] +date: 2025-11-11 +--- + +# Exporter + +## Overview +Exporter（指标导出器）是 Prometheus 生态中的核心组件，负责从各类目标系统采集指标数据，并通过 HTTP `/metrics` 端点暴露 Prometheus 格式的指标，供 Prometheus 服务器定期抓取。Exporter 不处理数据存储和告警，只做"采集 + 暴露"这一件事。 + +## Design Philosophy +- **无代理（Agentless）**：大多数 exporter 作为独立进程运行，不需要在被监控系统上安装额外软件 +- **HTTP 暴露**：通过标准的 `/metrics` 端点提供文本格式的指标 +- **松耦合**：Exporter 与 Prometheus 通过 HTTP 协议解耦，可独立部署和升级 +- **Pull 模式**：Prometheus 主动抓取，而非 exporter 主动推送 + +## Official Exporters +| Exporter | 指标来源 | 默认端口 | +|----------|----------|----------| +| [[node_exporter]] | Linux/Unix 主机（CPU/内存/磁盘/网络） | 9100 | +| [[cAdvisor]] | Docker 容器 | 8080 | +| [[blackbox_exporter]] | HTTP/TCP/DNS/TLS 端点 | 9115 | +| alertmanager | Alertmanager 实例 | 9093 | +| postgres_exporter | PostgreSQL 数据库 | 9187 | +| mysql_exporter | MySQL/MariaDB 数据库 | 9104 | +| redis_exporter | Redis 缓存 | 9121 | +| nginx-exporter | Nginx 状态页 | 9113 | + +## /metrics Format +```text +# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. +# TYPE node_cpu_seconds_total counter +node_cpu_seconds_total{cpu="0",mode="idle"} 123456.789 +node_cpu_seconds_total{cpu="0",mode="user"} 98765.432 +``` + +## Key Fields +- `# HELP`：指标说明（人类可读描述） +- `# TYPE`：指标类型（gauge / counter / histogram / summary） +- 指标行：`{} ` + +## Prometheus scrape_config +```yaml +scrape_configs: + - job_name: 'node_exporter' + static_configs: + - targets: ['192.168.1.10:9100'] +``` + +## Related Entities +- [[Prometheus]] — 数据消费者 +- [[node_exporter]] — 主机指标 exporter +- [[cAdvisor]] — 容器指标 exporter +- [[blackbox_exporter]] — 网络探测 exporter +- [[Alertmanager]] — 告警 exporter + +## Related Concepts +- [[PromQL]] — 指标查询语言 +- [[Prometheus告警规则]] — 基于 exporter 指标的告警条件 +- [[时序数据库]] — exporter 产出的数据存储模型 +- [[System Monitoring]] — 应用领域 diff --git a/wiki/concepts/Failover.md b/wiki/concepts/Failover.md new file mode 100644 index 00000000..0c75aa13 --- /dev/null +++ b/wiki/concepts/Failover.md @@ -0,0 +1,57 @@ +--- +title: "Failover" +type: concept +tags: [cloud-computing, reliability, high-availability] +date: 2025-03-02 +--- + +# Failover + +**Failover**（故障转移）是高可用性系统的核心机制，当主系统发生故障时，自动切换到备用系统，确保服务连续性。 + +## Definition + +故障转移是一种自动化的冗余机制，监控系统检测到主节点故障后，自动将流量或工作负载切换到备用节点，用户通常无感知。 + +## Key Characteristics + +- **自动化**：无需人工干预，自动检测和切换 +- **快速恢复**：切换时间可从几分钟缩短到秒级 +- **透明切换**：用户无感知或感知极小中断 +- **健康检查**：持续监控主节点健康状态 + +## Failover Patterns in Cloud + +| Pattern | Description | +|---------|-------------| +| **Active-Passive** | 主节点处理流量，备用节点待命；故障时切换 | +| **Active-Active** | 多个节点同时处理流量；故障节点自动剔除 | +| **Geo-Failover** | 跨地理区域的故障转移 | +| **Multi-Region** | 多区域部署，单区域故障不影响其他区域 | + +## Cloud Myths Context + +Failover 是反驳"云不可靠"误解的关键机制： +- 云服务商通过全球分布式架构实现跨区域故障转移 +- 自动化故障转移 SLA 保障 99.99% 可用性 +- 传统本地部署难以实现同等水平的故障转移能力 + +## Implementation Components + +- **Load Balancer**：健康检查 + 流量分发 +- **Health Checks**：定期检测服务可用性 +- **DNS Failover**：Route 53 / Cloud DNS 的 DNS 级切换 +- **Database Replication**：数据库级别的同步/异步复制 +- **Auto Scaling Groups**：实例级别的自动替换 + +## Related Concepts + +- [[High-Availability]] — 高可用性 +- [[cloud-computing]] — 云计算 +- [[Scalability]] — 可扩展性 +- [[Disaster-Recovery]] — 灾难恢复 +- [[cloud-migration]] — 云迁移 + +## Sources + +- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/concepts/Feature-Flag.md b/wiki/concepts/Feature-Flag.md new file mode 100644 index 00000000..c26889db --- /dev/null +++ b/wiki/concepts/Feature-Flag.md @@ -0,0 +1,123 @@ +--- +title: "Feature Flag (功能开关)" +tags: [devops, continuous-delivery, deployment, risk-mitigation, feature-management] +aliases: [Feature Flagging, Feature Toggle, Feature Switch] +created: 2026-04-25 +--- + +# Feature Flag (功能开关) + +**Feature Flag**（功能开关/功能标记）是一种将代码部署（Deploy）与功能发布（Release）解耦的技术机制。通过在代码中嵌入条件判断（开关），团队可以在不重新部署的情况下控制功能的可见性和行为。 + +## Aliases +- Feature Flagging +- Feature Toggle +- Feature Switch +- Kill Switch（紧急情况下的特殊用法） + +## Core Mechanism + +```javascript +if (featureFlag.enabled('new-checkout-flow')) { + return newCheckoutProcess(); +} else { + return oldCheckoutProcess(); +} +``` + +**关键洞察**：部署代码 ≠ 发布功能。代码可以在任何时间部署到生产环境，但功能发布由开关控制。 + +## Key Capabilities + +### 1. Decoupled Deployment & Release + +| 传统方式 | Feature Flag 方式 | +|----------|-------------------| +| 部署 = 发布 | 部署 ≠ 发布 | +| 2AM 部署"以防万一" | 随时部署，择机发布 | +| 全有或全无 | 灰度发布，渐进放量 | + +### 2. Kill Switch（应急切断） + +紧急情况下，无需重新部署即可关闭故障功能： + +- 支付网关异常？切换到备用提供商（秒级） +- 搜索结果异常？回退到旧算法（秒级） +- AI 模型产生幻觉？切换回上一版本（秒级） + +> "Instead of debugging under pressure while users suffer, you flip a switch and fix the problem properly later." + +### 3. Progressive Rollout（渐进式放量） + +分阶段向用户群发布功能，控制影响范围： + +``` +1% 用户 → 监控错误率、性能指标 +5% 用户 → 监控转化率、用户反馈 +25% 用户 → 检查下游系统负载 +100% 用户 → 完成全量发布 +``` + +如果 5% 阶段出现问题，RTO 以秒计（只需关闭开关），而不是小时级（需要紧急回滚部署）。 + +### 4. Micro-Recovery（Feature 级别微恢复） + +不再将整个应用视为单一系统，不同功能有不同的风险和业务影响： + +| 功能 | RTO 目标 | RPO 目标 | +|------|----------|----------| +| 核心支付处理 | 秒级 | 零丢失 | +| 新推荐引擎 | 5 分钟 | 15 分钟 | +| Beta 仪表盘功能 | 30 分钟 | 1 小时 | + +### 5. 定向回滚（Targeted Rollback） + +如果某个功能只影响欧洲移动用户，可以仅针对该用户群禁用该功能，其他用户不受影响。 + +## Feature Flag vs. 传统灾备 + +| 维度 | 传统灾备 | Feature Flag | +|------|----------|--------------| +| 目标故障类型 | 硬件故障 | 代码变更 | +| RTO | 小时级（从备份恢复） | 秒级（配置变更） | +| RPO | 取决于备份频率 | 近零（不触碰数据层） | +| 故障频率 | 低（年均几次） | 高（每周可能发生） | +| 成本 | 高（冗余基础设施） | 低（软件工具） | + +## 商业案例数据 + +| 公司 | 改进前 | 改进后 | +|------|--------|--------| +| HP | 回滚时间：小时级 | 分钟级 | +| Christian Dior | 回滚时间：15 分钟 | 即时切换 | +| LaunchDarkly 客户 | — | 86% 在一天内恢复 | +| LaunchDarkly 客户 | — | 42% 在小时级（甚至分钟级）恢复 | + +**成本效益**：59% 的 LaunchDarkly 客户表示运维成本降低 11%-50%，8% 表示降低超过 50%。 + +## 核心价值 + +> "Deploy with confidence, recover instantly, and focus on building features instead of fixing outages." + +Feature Flag 将问题响应从**被动救火**转变为**主动预防**： + +- **预防优于恢复**：在 1% 用户中发现问题，比全量发布后止损更有价值 +- **减少焦虑**：部署不再可怕，随时可以回退 +- **提高迭代速度**：团队敢于快速实验 + +## Related Concepts + +- [[Kill Switch]] — Feature Flag 在紧急情况下的用法 +- [[Progressive Rollout]] — Feature Flag 支持的渐进式放量策略 +- [[Micro-Recovery]] — Feature Flag 实现的 feature 级别细粒度恢复 +- [[Deployment-vs-Release]] — Feature Flag 实现的部署与发布解耦 +- [[RTO]] — Feature Flag 将 RTO 从小时降至秒级 +- [[RPO]] — Feature Flag 保护 RPO（不丢失数据） +- [[LaunchDarkly]] — Feature Flag 管理平台 +- [[CI-CD-Pipeline]] — Feature Flag 是现代 CI/CD 的核心基础设施 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] +- [[sources/devops-culture-and-transformation-fostering-collaboration-agile-practices-and-innovation-linkedin.md]] +- [[sources/Deployment-Automation.md]] diff --git a/wiki/concepts/FinOps.md b/wiki/concepts/FinOps.md new file mode 100644 index 00000000..b0423342 --- /dev/null +++ b/wiki/concepts/FinOps.md @@ -0,0 +1,105 @@ +# 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 指标 diff --git a/wiki/concepts/GPG-密钥验证.md b/wiki/concepts/GPG-密钥验证.md new file mode 100644 index 00000000..69bfc85e --- /dev/null +++ b/wiki/concepts/GPG-密钥验证.md @@ -0,0 +1,42 @@ +--- +title: "GPG 密钥验证" +tags: [gpg, apt, security] +date: 2026-04-22 +--- + +# GPG 密钥验证 + +## Definition +GPG (GNU Privacy Guard) 密钥验证是 APT 包管理器的安全机制，通过 GPG 签名确保从仓库下载的软件包来自可信来源且未被篡改。 + +## Docker GPG 密钥配置 +```bash +# 创建密钥目录 +sudo install -m 0755 -d /etc/apt/keyrings + +# 下载 Docker 官方 GPG 密钥 +sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc + +# 设置密钥权限（所有人可读） +sudo chmod a+r /etc/apt/keyrings/docker.asc +``` + +## Verification Mechanism +1. apt 在下载软件包前，先用 GPG 密钥验证包的签名 +2. 签名不匹配或密钥缺失时，apt 会拒绝安装并报 GPG 错误 +3. `signed-by` 参数在 sources.list 条目中指定验证用的密钥路径 + +## Common Issues +| 问题 | 原因 | 解决 | +|------|------|------| +| `NO_PUBKEY` | GPG 密钥未导入 | 运行导入命令 | +| `GPG error` | 密钥权限不正确 | `chmod a+r` | +| `The following signatures couldn't be verified` | 密钥过期或损坏 | 重新下载密钥 | + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] — Docker GPG 密钥配置步骤 + +## Related Concepts +- [[APT 仓库配置]] — 密钥与仓库配置的关系 +- [[Docker Engine]] — 被 GPG 验证的软件包 +- [[Ubuntu Server]] — GPG 密钥管理的宿主系统 diff --git a/wiki/concepts/Gatekeeper.md b/wiki/concepts/Gatekeeper.md new file mode 100644 index 00000000..bbc3b94b --- /dev/null +++ b/wiki/concepts/Gatekeeper.md @@ -0,0 +1,69 @@ +# Gatekeeper + +> macOS 的安全机制，用于验证应用程序是否来自已识别的开发者可信来源。 + +## Overview +Gatekeeper 是 macOS 的应用安全验证系统，旨在保护用户免受恶意软件的侵害。它会检查应用程序的来源和签名状态，拒绝运行未授权的软件。 + +## How It Works +Gatekeeper 会在用户尝试运行从互联网下载的应用程序时触发验证流程： +1. 检查应用是否来自 App Store +2. 检查是否有有效的 Developer ID 签名 +3. 检查是否被标记为已隔离（quarantined） + +## Quarantine Attribute +macOS 使用扩展属性（Extended Attributes）来标记从互联网下载的文件： +- `com.apple.quarantine`：标记文件来自互联网下载 +- `com.apple.metadata`：包含下载来源 URL 等元数据 + +## Removing Quarantine +```bash +# 递归移除 quarantine 属性（适用于目录） +xattr -rd com.apple.quarantine /path/to/application/ + +# 验证（无输出表示解除成功） +xattr /path/to/application/binary + +# 查看 quarantine 状态 +xattr -l /path/to/application/binary +``` + +## Gatekeeper Modes +```bash +# 查看当前 Gatekeeper 状态 +spctl --status + +# 允许所有来源（不推荐，存在安全风险） +sudo spctl --master-disable + +# 查看应用状态 +spctl --assess --verbose /path/to/application +``` + +## Use Cases +- **Homebrew**：安装后需解除 quarantine 才能运行 +- **FRP**：从 GitHub 下载的二进制文件需解除限制 +- **第三方工具**：任何未签名的可执行文件 + +## Security Considerations +| 方法 | 安全性 | 适用场景 | +|------|--------|----------| +| Developer ID 签名 | 最高 | 正式发布的软件 | +| App Store | 高 | 仅限 App Store 应用 | +| 解除 quarantine | 低 | 自托管工具/开发环境 | + +## Best Practices +1. **仅对可信来源解除限制**：如 GitHub Release 官方二进制文件 +2. **使用 -r 递归参数**：确保目录内所有文件解除限制 +3. **验证文件完整性**：下载后检查 SHA256 校验和 +4. **保持 Gatekeeper 开启**：除非完全了解风险，否则不要禁用 + +## Related Concepts +- [[launchd]] — macOS 服务管理器 +- [[frp]] — 需要解除 Gatekeeper 才能运行 +- [[Mac Mini M4]] — 需要处理 Gatekeeper 问题 + +## References +- Apple Support: Safely open apps on your Mac +- `man xattr` +- `man spctl` diff --git a/wiki/concepts/Green-Computing.md b/wiki/concepts/Green-Computing.md new file mode 100644 index 00000000..f35fc200 --- /dev/null +++ b/wiki/concepts/Green-Computing.md @@ -0,0 +1,74 @@ +--- +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]] diff --git a/wiki/concepts/Hybrid-Cloud.md b/wiki/concepts/Hybrid-Cloud.md new file mode 100644 index 00000000..19f09fb2 --- /dev/null +++ b/wiki/concepts/Hybrid-Cloud.md @@ -0,0 +1,198 @@ +# Hybrid Cloud + +> **Hybrid Cloud** — 混合云是一种同时使用公有云和私有云的计算环境，通过在两者之间按策略分配工作负载来结合各自的优势——公有云的弹性与成本效率 + 私有云的安全性与控制力。 + +## Definition + +混合云（Hybrid Cloud）是一种将公有云和私有云整合在一起的云计算架构，允许数据和应用程序在两种环境之间移动。混合云策略基于业务和技术需求（安全性、性能、可扩展性、成本、效率）动态决定哪些工作负载运行在哪种云环境中。 + +## Core Principle + +> "The uses of each are driven by business and technical needs around: Security, Performance, Scalability, Cost, Efficiency." + +混合云的核心理念是：**工作负载应该运行在最适合它的环境中**，而不是一刀切地选择单一云部署模型。 + +## Architecture + +``` +┌─────────────────────────────────────────────────────────┐ +│ 混合云架构 │ +│ │ +│ ┌─────────────────────┐ ┌─────────────────────┐ │ +│ │ 私有云环境 │ │ 公有云环境 │ │ +│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │ +│ │ │ 敏感数据工作负载│ │ │ │ 弹性计算工作负载 │ │ │ +│ │ │ 核心业务系统 │◄─┼─────┼─►│ 峰值流量处理 │ │ │ +│ │ │ 受监管的工作负载│ │ │ │ 开发测试环境 │ │ │ +│ │ └───────────────┘ │ │ │ SaaS 应用 │ │ │ +│ │ │ │ └───────────────┘ │ │ │ +│ │ 专用物理服务器 │ │ │ │ │ +│ │ 本地数据中心 │ │ AWS / Azure / GCP │ │ │ +│ └─────────────────────┘ └─────────────────────┘ │ │ +│ │ │ │ +│ ┌──────────┴──────────┐ │ +│ │ 集成层（网络/数据） │ │ +│ │ - VPN / 专线连接 │ │ +│ │ - 数据同步 │ │ +│ │ - 统一身份管理 │ │ +│ └─────────────────────┘ │ +└─────────────────────────────────────────────────────────┘ +``` + +## Common Use Cases + +### 1. 核心 + 弹性模型 +``` +私有云：核心业务应用、数据库、敏感数据 +公有云：弹性扩展资源、峰值流量处理、CDN + +示例：电商平台 +- 私有云：订单系统、支付处理、客户数据 +- 公有云：双11大促峰值扩展 +``` + +### 2. 安全 + 成本模型 +``` +私有云：敏感数据、合规要求高的工作负载 +公有云：非敏感工作负载、开发测试环境 + +示例：医疗机构 +- 私有云：患者病历、HIPAA合规数据 +- 公有云：公开网站、健康资讯应用 +``` + +### 3. 本地 + 云爆发模型 +``` +私有云：日常稳定工作负载 +公有云：临时性高计算需求（突发工作负载） + +示例：工程仿真 +- 私有云：日常设计工作 +- 公有云：新项目仿真计算峰值 +``` + +## Advantages + +### 1. 策略驱动的灵活性 +- 基于安全、性能、成本需求灵活部署工作负载 +- 策略即代码（Policy-as-Code）自动化分配 +- 持续优化工作负载位置 + +### 2. 安全地扩展 +- 公有云的弹性扩展能力，无需将敏感工作负载暴露于安全风险 +- 敏感工作负载保留在私有云 +- 按需使用公有云资源，无需长期承诺 + +### 3. 最大化可靠性 +- 跨多个数据中心分发服务（公私混合） +- 不将可用性依赖于单一环境 +- 灾难恢复增强 + +### 4. 成本控制与效率 +- 敏感工作负载运行在私有云专用资源 +- 常规工作负载分布到廉价公有云基础设施 +- 投资回报优化 + +### 5. 互操作性和移动性 +- 工作负载在公私环境之间平滑移动 +- 跨环境访问和使用数据和应用 +- 统一身份和访问管理 + +### 6. 优化的负载分配 +- 敏感工作负载在私有云处理 +- 其他所有工作负载在公有云处理 +- 每个工作负载运行在最适合的环境 + +### 7. 业务连续性 +- 混合分布性质使灾难恢复更简单快速 +- 分布式架构降低单点故障风险 +- RTO/RPO优化 + +## Drawbacks + +### 1. 复杂的成本管理 +- 公私之间的切换难以跟踪 +- 可能导致浪费性支出 +- 需要精细的 FinOps 实践 + +### 2. 集成挑战 +- 不同位置和类别的云基础设施需要强兼容性 +- 跨云网络配置复杂 +- 数据一致性和同步挑战 + +### 3. 增加复杂性 +- 额外的架构复杂性 +- 需要同时管理公私两种环境 +- 运维团队技能要求更高 + +### 4. 安全风险 +- 跨云数据传输引入漏洞 +- 需要额外的网络安全控制 +- 合规边界更复杂 + +## Homogeneous vs Heterogeneous + +选择混合云后，还需决定云供应商策略： + +| 类型 | 定义 | 优势 | 劣势 | +|------|------|------|------| +| **同构混合云** | 使用单一云厂商的公私产品 | 简化管理、一致工具链、统一支持 | 供应商锁定 | +| **异构混合云** | 使用多个云厂商的混合 | 避免锁定、最佳组合 | 管理复杂性高 | + +示例： +- 同构：AWS Outposts + AWS 公有云 +- 异构：Azure Stack + AWS 公有云 + +## When to Use Hybrid Cloud + +| 场景 | 说明 | +|------|------| +| **多垂直领域的组织** | 不同业务线有不同IT安全、监管和性能要求 | +| **优化云投资** | 希望在不牺牲价值的前提下优化成本 | +| **增强现有云安全** | SaaS产品需要通过安全私有网络交付 | +| **战略性云投资** | 持续在最佳可用服务交付模式之间权衡 | +| **迁移过渡期** | 从本地向云迁移的渐进式路径 | +| **合规+弹性需求** | 既要数据本地化又要弹性扩展 | + +## Decision Framework + +``` +开始：评估工作负载特征 + ↓ + 这是敏感/受监管数据吗？ + /是的\ \否/ + ↓ ↓ + 私有云优先 这是稳定的基线负载吗？ + ↓ /是\ \否/ + 需要弹性和峰值容量？ ↓ ↓ + /是\ \否/ 私有云 公有云优先 + ↓ ↓ ↓ + 混合云 完成 需要弹性扩展？ + ↑ /是\ \否/ + └───────\ ↓ + 需要数据本地化？ + /是\ \否/ + ↓ ↓ + 混合云 公有云优先 +``` + +## Related Concepts + +- [[Public Cloud]] — 公有云 +- [[Private Cloud]] — 私有云 +- [[Multi-Cloud Strategy]] — 多云策略（对比） +- [[Shared Responsibility Model]] — 共享责任模型 +- [[Cloud Adoption Strategy]] — 云采用策略 +- [[FinOps]] — 云财务管理 +- [[Disaster Recovery Planning]] — 灾难恢复规划 +- [[Cloud Security]] — 云安全 +- [[Vendor-Lock-In]] — 供应商锁定 + +## See Also + +- [[Cloud Computing]] — 云计算基础 +- [[Cloud-Maturity-Model]] — 云成熟度模型 +- [[Cloud-Adoption-Strategy]] — 云采用策略 +- [[Cloud-Governance]] — 云治理 +- [[High Availability]] — 高可用性 +- [[Scalability]] — 可扩展性 diff --git a/wiki/concepts/Hyperautomation.md b/wiki/concepts/Hyperautomation.md new file mode 100644 index 00000000..f7ad6f66 --- /dev/null +++ b/wiki/concepts/Hyperautomation.md @@ -0,0 +1,61 @@ +--- +title: "Hyperautomation" +type: concept +tags: [automation, devops, ai, itsm] +date: 2025-03-01 +--- + +## Definition + +超自动化（Hyperautomation）是Gartner提出的技术趋势，指融合多种自动化技术（RPA、工作流引擎、ML、AI）实现**端到端流程自动化**的最大化。它超越了简单的流程自动化，追求组织内所有可自动化流程的识别和自动化。 + +## Core Components + +``` +┌─────────────────────────────────────────────────────────────┐ +│ Hyperautomation Stack │ +├─────────────────────────────────────────────────────────────┤ +│ Process Discovery → RPA → Workflow → AI/ML → IoT │ +│ ↓ ↓ ↓ ↓ ↓ │ +│ 流程识别 机器人 编排 智能决策 边缘自动化 │ +└─────────────────────────────────────────────────────────────┘ +``` + +### Technology Components + +| 技术 | 作用 | 示例 | +|------|------|------| +| RPA | 模拟人类操作 | UI自动化 | +| Workflow Engine | 流程编排 | n8n, Airflow | +| AI/ML | 智能决策 | 预测分析 | +| iPaaS | 系统集成 | API网关 | +| Low-Code | 快速开发 | 流程构建 | + +## In ITSM Context + +在[[ITSM 2.0]]中，超自动化是核心技术引擎： + +1. **[[Problem-Management]]** — 自动识别重复问题模式 +2. **[[Incident-Management]]** — 自动分类和路由工单 +3. **[[Change-Management]]** — 自动影响评估和审批 +4. **[[Security-and-Compliance]]** — Policy-as-Code自动执行 + +## Hyperautomation vs Automation + +| 维度 | 传统自动化 | 超自动化 | +|------|-----------|---------| +| 范围 | 单点流程 | 端到端 | +| 智能 | 规则驱动 | AI增强 | +| 发现 | 人工识别 | 自动发现 | +| 适应 | 静态 | 动态学习 | + +## Related Concepts + +- [[AIOps]] — AI驱动的运维智能 +- [[Self-Healing-Systems]] — 自愈自动化 +- [[Policy-as-Code]] — 策略自动化 +- [[ITSM 2.0]] — 超自动化的主要应用场景 + +## Sources + +- [[understanding-complete-itsm]] — ITSM 2.0中的超自动化应用 diff --git a/wiki/concepts/IAST.md b/wiki/concepts/IAST.md new file mode 100644 index 00000000..3c88077f --- /dev/null +++ b/wiki/concepts/IAST.md @@ -0,0 +1,76 @@ +# IAST (Interactive Application Security Testing) + +## Definition +IAST tools evaluate applications while they run to detect security issues that SAST or SCA tools might overlook. They are beneficial during testing and deployment phases when examining how different components interact within the application is important. + +## Aliases +- Interactive Application Security Testing +- Grey-box testing +- Instrumentation-based testing + +## Characteristics +- **运行时分析**：在应用运行时进行监控 +- **灰盒测试**：结合白盒和黑盒方法 +- **精确检测**：能准确定位漏洞位置 +- **低误报率**：基于实际执行分析 + +## How IAST Works + +### Instrumentation +IAST 工具在应用中植入代理（Agent）： +- 监控应用执行路径 +- 分析数据流 +- 检测不安全操作 + +### Agent Deployment +- Web 服务器插件 +- 应用服务器插件 +- 容器环境支持 +- 云函数支持 + +## What IAST Detects +- 运行时数据流问题 +- API 安全问题 +- 认证/授权问题 +- 配置错误 +- 与 [[SAST]] 和 [[DAST]] 互补的漏洞 + +## Comparison with Other Testing Methods + +| 维度 | SAST | DAST | IAST | +|------|------|------|------| +| **测试方式** | 白盒（静态） | 黑盒（动态） | 灰盒（运行时） | +| **需要代码** | 是 | 否 | 是（代理） | +| **误报率** | 中等 | 低 | 低 | +| **检测范围** | 代码层 | 应用层 | 代码+应用层 | +| **适用阶段** | 开发 | 测试/部署 | 测试 | +| **性能影响** | 无 | 中等 | 低-中等 | + +## Tools +- Contrast Assess +- Hdiv +- Quotium Q360 +- AppCheck + +## Integration +IAST 通常集成到： +- 自动化测试环境 +- QA 测试流程 +- CI/CD 管道（测试阶段） +- 预生产环境 + +## Advantages +- 高准确性（低误报） +- 精确的漏洞定位 +- 不中断开发流程 +- 可用于生产监控 + +## Related Concepts +- [[DevSecOps]] — IAST 是其重要组件 +- [[SAST]] — 静态应用安全测试 +- [[DAST]] — 动态应用安全测试 +- [[SCA]] — 软件组成分析 +- [[RASP]] — 运行时应用自我保护 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/IP纯净度.md b/wiki/concepts/IP纯净度.md new file mode 100644 index 00000000..473356a1 --- /dev/null +++ b/wiki/concepts/IP纯净度.md @@ -0,0 +1,58 @@ +--- +title: "IP纯净度" +type: concept +tags: [ip, risk-assessment, security] +date: 2025-12-31 +--- + +# IP纯净度 + +## 定义 +IP纯净度是评定某个IP地址是否安全可靠的风险等级，通过分析IP的历史使用记录、是否被标记为垃圾邮件源、VPN/代理使用情况等因素，计算出一个风险评分。 + +## 检测工具 +- **Scamalytics**: https://scamalytics.com/ — 主流IP风险评估网站 +- **IP111**: https://ip111.cn/ — IP归属地检测 + +## 风险等级 + +### 低风险（推荐） +- 数值低，分数越低越安全 +- IP信誉良好，无异常记录 +- 适合注册重要账号 + +### 中等风险（谨慎） +- 存在一定的历史问题 +- 可能被部分平台标记 +- 增加封号风险 + +### 高风险（避免） +- IP信誉差，有明显异常记录 +- 被多个平台标记 +- 极大概率导致封号 + +## 关键原则 +> **数值越低越安全** — 必须使用低风险IP才能有效降低账号封禁概率 + +## IP一致性检测 +使用多个网站检测，确保IP归属一致： +1. 国内IP检测网站 +2. 国外IP检测网站 +3. Google IP检测 + +**三处必须完全一致**，否则可能被平台判定异常。 + +## 影响纯度的因素 +- 是否为数据中心IP（住宅IP更优） +- 历史是否用于发送垃圾邮件 +- 是否被VPN/代理服务大量使用 +- 是否在黑名单中 +- DNS泄漏情况 + +## 相关概念 +- [[Socks5代理]] +- [[账号隔离]] +- [[指纹浏览器]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/concepts/ISOHybrid镜像.md b/wiki/concepts/ISOHybrid镜像.md new file mode 100644 index 00000000..c80b238b --- /dev/null +++ b/wiki/concepts/ISOHybrid镜像.md @@ -0,0 +1,35 @@ +--- +title: "ISOHybrid镜像" +type: concept +tags: [iso, uefi, bios, boot, rufus] +date: 2026-04-14 +aliases: [ISOHybrid, hybrid ISO, 混合镜像] +--- + +# ISOHybrid镜像 + +## Definition +一种同时包含 BIOS (MBR) 和 UEFI 两种引导方式的 ISO 镜像文件格式，Ubuntu 官方 ISO 属于此类。使用 Rufus 等工具写入 U 盘时需要明确选择写入模式。 + +## Two Writing Modes +| 模式 | 适用场景 | 说明 | +|------|----------|------| +| **ISO 镜像模式** | 推荐首选 | 保留 ISO 结构，兼容性最佳 | +| **DD 镜像模式** | 备选（启动失败时） | 逐字节复制，适合某些顽固设备 | + +## Why It Matters +Rufus 写入 ISOHybrid 镜像时会弹出模式选择对话框。选错模式会导致 U 盘在目标设备上无法启动，尤其是 HP ZBook 等 UEFI 严格模式设备。 + +## HP ZBook 的 ISOHybrid 配置 +- **分区方案**：GPT（必须，配合 UEFI） +- **目标系统类型**：UEFI (non CSM)（自动匹配） +- **文件系统**：FAT32（UEFI 标准） + +## Related +- [[Rufus]] — 写入工具 +- [[HP ZBook]] — 目标设备 +- [[GPT分区表]] — 分区方案 +- [[ISOHybrid镜像]] ← 由 [[Rufus]] 写入至 [[HP ZBook]] + +## Sources +- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] diff --git a/wiki/concepts/ITSM-2.0.md b/wiki/concepts/ITSM-2.0.md new file mode 100644 index 00000000..ca74e193 --- /dev/null +++ b/wiki/concepts/ITSM-2.0.md @@ -0,0 +1,56 @@ +--- +title: "ITSM 2.0" +type: concept +tags: [cloud, devops, ai, itsm] +date: 2025-03-01 +--- + +## Definition + +ITSM 2.0是IT服务管理的下一代范式，融合[[AIOps]]和[[Hyperautomation]]技术，具备**自学习、预测性和自主化**能力。它代表了从传统反应式服务管理向主动预防式智能运营的根本转变。 + +## Core Characteristics + +| 特性 | 描述 | 技术支撑 | +|------|------|---------| +| **Self-Learning** | 系统从历史数据中学习，自动优化运维决策 | ML模型、反馈循环 | +| **Predictive** | 预测潜在故障，在问题发生前采取措施 | 预测分析、根因预测 | +| **Autonomous** | 自动化执行运维任务，减少人工干预 | AIOps、自愈系统 | + +## Key Enablers + +### 1. AIOps Integration +``` +事件数据 → ML模型 → 异常检测 → 根因分析 → 自动修复 +``` + +### 2. Hyperautomation +- [[Policy-as-Code]] — 合规策略自动化 +- [[Self-Healing-Systems]] — 故障自动恢复 +- 端到端流程机器人 + +### 3. ITSM 2.0 Eight Processes + +1. **[[Problem-Management]] 2.0** — AI驱动的根因预测 +2. **[[Incident-Management]] 2.0** — 自愈驱动的秒级响应 +3. **[[Change-Management]] 2.0** — 风险预测驱动的智能审批 +4. **[[Release-Management]] 2.0** — 渐进式交付与灰度发布 +5. **[[Configuration-Management]] 2.0** — AI增强的CMDB +6. **[[Asset-Management]] 2.0** — 智能生命周期管理 +7. **[[Security-and-Compliance]] 2.0** — ZTA + Policy-as-Code +8. **[[Disaster-Recovery]] 2.0** — DRaaS + RTO/RPO优化 + +## Industry Trend + +> "The convergence of AIOps, hyperautomation, and ITSM 2.0 is defining a new paradigm: self-learning, predictive, and autonomous IT operations." — shenwei, LinkedIn + +## Related Concepts + +- [[ITSM]] — 传统ITSM基础 +- [[AIOps]] — 运维智能核心 +- [[Hyperautomation]] — 自动化引擎 +- [[Self-Healing-Systems]] — 自主恢复能力 + +## Sources + +- [[understanding-complete-itsm]] — ITSM 2.0核心概念来源 diff --git a/wiki/concepts/ITSM.md b/wiki/concepts/ITSM.md new file mode 100644 index 00000000..0511631b --- /dev/null +++ b/wiki/concepts/ITSM.md @@ -0,0 +1,54 @@ +--- +title: "IT Service Management (ITSM)" +type: concept +tags: [cloud, devops, operations, it-management] +date: 2025-03-01 +--- + +## Definition + +IT服务管理（ITSM）是一套用于设计、交付、管理和改进IT服务的方法论和实践。传统ITSM以工单处理为中心，而现代ITSM已演进为**企业运营卓越、风险缓解和创新加速的战略推动者**。 + +## Core Framework + +### Eight Core Processes (Modern ITSM) + +| 流程 | 核心功能 | 关键技术 | +|------|---------|---------| +| [[Problem-Management]] | 根因分析、预防重复故障 | AI异常检测、预测分析 | +| [[Incident-Management]] | 快速恢复、减少业务中断 | AIOps、自愈系统 | +| [[Change-Management]] | 受控变更、风险评估 | AI影响评估、IaC合规 | +| [[Release-Management]] | 渐进交付、零干扰发布 | Blue-Green、Canary | +| [[Configuration-Management]] | 依赖映射、漂移检测 | AI-CMDB、多云编排 | +| [[Asset-Management]] | 生命周期跟踪、成本优化 | SAM、云成本管理 | +| [[Security-and-Compliance]] | 风险评分、威胁情报 | ZTA、Policy-as-Code | +| [[Disaster-Recovery]] | 业务连续性、容灾 | DRaaS、RTO/RPO优化 | + +## Evolution + +``` +Traditional ITSM Modern ITSM ITSM 2.0 +───────────────── → ───────────── → ────────────── +- Ticketing-centric - Service-centric - AI-driven +- Reactive - Proactive - Predictive +- Manual - Automated - Autonomous +- Siloed - Integrated - Self-healing +``` + +## Key Technologies + +- **[[AIOps]]**：机器学习驱动的运维智能 +- **[[CMDB]]**：AI增强的配置管理数据库 +- **[[Hyperautomation]]**：端到端流程自动化 +- **[[Self-Healing-Systems]]**：自动化故障检测与修复 + +## Related Concepts + +- [[ITSM-2.0]] — 下一代ITSM，自学习、预测性、自主化 +- [[DevOps]] — ITSM与DevOps的文化融合 +- [[SRE]] — 站点可靠性工程与服务级别管理 +- [[ITIL]] — IT基础设施库，ITSM的方法论框架 + +## Sources + +- [[understanding-complete-itsm]] — 现代ITSM八大趋势与AI驱动转型 diff --git a/wiki/concepts/Immutable-Infrastructure.md b/wiki/concepts/Immutable-Infrastructure.md new file mode 100644 index 00000000..36ffde9b --- /dev/null +++ b/wiki/concepts/Immutable-Infrastructure.md @@ -0,0 +1,75 @@ +# Immutable Infrastructure + +## Definition +Immutable Infrastructure is an approach where components are never modified after deployment. Instead of updating existing components, new versions are created and replaced entirely. + +## Concept +不可变基础设施是一种部署策略，其中服务器和基础设施组件一旦部署就不再修改。任何变更都需要创建新版本并替换整个组件。 + +## Core Principles + +### 1. Never Modify Running Systems +- 不直接在生产环境修改配置 +- 所有变更通过重新部署实现 +- 使用版本化配置和模板 + +### 2. Replace, Don't Modify +- 新版本 = 新环境 +- 旧版本直接销毁 +- 保证一致性 + +### 3. Infrastructure as Code +- 所有基础设施定义代码化 +- 版本控制所有配置 +- 可重复的部署流程 + +## Benefits for DevSecOps + +### Security Benefits +- **减少攻击面**：生产环境无交互式访问 +- **一致性保证**：每个环境完全相同 +- **快速回滚**：发现问题时快速切换 +- **审计简化**：代码即记录 + +### Operational Benefits +- 环境一致性 +- 可预测的部署 +- 简化的故障排除 +- 更容易扩展 + +## Implementation Patterns + +### Container-Based Approach +``` +容器镜像 = 应用 + 依赖 + 配置 +每次变更 → 新镜像版本 → 滚动更新 +``` + +### Cloud Infrastructure +- AWS：使用 AMI + Auto Scaling +- Kubernetes：使用 Pod 重建 +- Terraform：管理不可变配置 + +## Best Practices + +1. **使用标签（Tag）管理版本** +2. **自动化构建流程** +3. **保存历史镜像版本** +4. **实施蓝绿部署或滚动更新** +5. **监控不可变资源的变更** + +## Related Concepts +- [[DevSecOps]] — 不可变基础设施是安全架构的重要组成部分 +- [[Policy-as-Code]] — 策略代码化 +- [[Container-Lifecycle-Hardening]] — 容器安全加固 +- [[Blue-Green-Deployment]] — 蓝绿部署模式 +- [[Infrastructure-as-Code]] — 基础设施即代码 + +## Tools +- Packer — 镜像构建工具 +- Terraform — IaC 工具 +- Kubernetes — 容器编排 +- Docker — 容器化 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Incident-Management.md b/wiki/concepts/Incident-Management.md new file mode 100644 index 00000000..a343d79c --- /dev/null +++ b/wiki/concepts/Incident-Management.md @@ -0,0 +1,74 @@ +--- +title: "Incident Management" +type: concept +tags: [itsm, operations, reliability] +date: 2025-03-01 +--- + +## Definition + +事件管理（Incident Management）是[[ITSM]]的核心流程之一，专注于**快速恢复服务正常运作**，将服务中断或降级对业务的影响降到最低。 + +## Incident Lifecycle + +``` +┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ +│ Event │ → │ Detect │ → │ Triage │ → │ Resolve │ → │ Review │ +│ Occurs │ │ & Alert │ │ & Prior │ │ & Recover│ │ & Learn │ +└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ +``` + +## Modern Incident Management (ITSM 2.0) + +在[[ITSM 2.0]]中，事件管理由[[AIOps]]和[[Self-Healing-Systems]]驱动： + +### Key Capabilities + +| 能力 | 描述 | 技术 | +|------|------|------| +| Real-time Observability | 实时可观测性 | Metrics, Logs, Traces | +| Automated Remediation | 自动化修复 | AIOps, Runbooks | +| Dynamic Prioritization | 动态优先级 | ML Models | +| Auto-escalation | 自动升级 | Alert Routing | +| Self-Healing | 自愈 | Automated Recovery | + +### AIOps-Powered Incident Response + +``` +监控检测 → 智能分类 → 自动路由 → 自动化修复 → SLA监控 + ↓ ↓ ↓ ↓ ↓ + AIOps ML模型 技能路由 Runbooks 告警升级 +``` + +## Key Metrics + +| 指标 | 描述 | +|------|------| +| [[MTTR]] | Mean Time to Recovery — 平均恢复时间 | +| [[MTTD]] | Mean Time to Detect — 平均检测时间 | +| MTTA | Mean Time to Acknowledge — 平均确认时间 | +| Change Failure Rate | 变更失败率 | + +## Priority Levels + +| 优先级 | 描述 | SLA | +|--------|------|-----| +| P1/Critical | 核心服务不可用 | 15分钟 | +| P2/High | 主要功能不可用 | 1小时 | +| P3/Medium | 次要功能受影响 | 4小时 | +| P4/Low | 轻微影响 | 24小时 | + +## Related Concepts + +- [[ITSM]] — 父框架 +- [[Problem-Management]] — 问题管理 +- [[AIOps]] — AI运维能力 +- [[Self-Healing-Systems]] — 自愈系统 +- [[MTTR]] — 平均恢复时间 +- [[MTTD]] — 平均检测时间 +- [[Event-Correlation]] — 事件关联 +- [[Root-Cause-Analysis]] — 根因分析 + +## Sources + +- [[understanding-complete-itsm]] — AIOps-driven Incident Management diff --git a/wiki/concepts/Infrastructure-as-Code.md b/wiki/concepts/Infrastructure-as-Code.md index 453cd755..e61950ec 100644 --- a/wiki/concepts/Infrastructure-as-Code.md +++ b/wiki/concepts/Infrastructure-as-Code.md @@ -13,6 +13,7 @@ Infrastructure as Code is the practice of managing and provisioning infrastructu - **Terraform**: Multi-cloud IaC tool using HCL - **Ansible**: Configuration management and orchestration - **CloudFormation**: AWS-native infrastructure provisioning +- **CloudFormation StackSets**: AWS-native cross-account/cross-region deployment extension for CloudFormation - **Pulumi**: IaC using general-purpose programming languages - **Terragrunt**: Wrapper for Terraform providing organization diff --git a/wiki/concepts/Intentional-Cloud-Strategy.md b/wiki/concepts/Intentional-Cloud-Strategy.md new file mode 100644 index 00000000..67d9371f --- /dev/null +++ b/wiki/concepts/Intentional-Cloud-Strategy.md @@ -0,0 +1,105 @@ +--- +title: Intentional Cloud Strategy +type: concept +tags: [cloud-computing, strategy, architecture, decision-making] +date: 2026-04-19 +--- + +# Intentional Cloud Strategy + +**Intentional Cloud Strategy（有意的云策略）** 是一种系统化的云部署决策框架，要求企业根据工作负载的具体需求（安全性、性能、成本、合规）主动选择合适的云部署模式，而非盲目跟随趋势或单一供应商偏好。 + +## Definition + +> "The key element in balancing your choices is to develop an intentional cloud strategy that optimizes your use of each cloud environment. Start with defining the needs of your various workloads, then prioritize them based on the pros and cons of each model." — BMC Blog + +核心理念：**平衡是云架构的核心驱动力**。今天适合企业的选择未必适合未来，云策略需要持续评估和迭代。 + +## Decision Framework + +### Step 1: 工作负载分类（Workload Classification） + +按需求对工作负载进行分类： + +| 维度 | 问题 | +|------|------| +| **安全性** | 数据是否敏感？是否受行业法规约束（HIPAA/GDPR/ISO 27001）？ | +| **性能** | 是否需要低延迟？是否对 SLA 有严格要求？ | +| **可扩展性** | 是否有不可预测的流量峰值？ | +| **成本** | 长期运营成本 vs 前期投入如何权衡？ | +| **合规** | 数据主权要求？物理位置限制？ | + +### Step 2: 工作负载到部署模式的映射 + +``` +工作负载需求 → 推荐部署模式 +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ +高安全 + 高合规 + 固定负载 → [[Private Cloud]] +低安全 + 高弹性 + 成本敏感 → [[Public Cloud]] +高安全 + 高弹性 + 跨地域 → [[Hybrid Cloud]] +多供应商 + 高可用 → [[Multi-Cloud-Strategy]] +``` + +### Step 3: 持续评估与平衡 + +云策略不是一次性决策，需要： +- 定期（季度/年度）审查现有工作负载分布 +- 跟踪 TCO 变化，识别过度配置 +- 评估新技术（Serverless、Edge Computing）对架构的影响 +- 保持对供应商锁定（Vendor Lock-In）的警惕 + +## Three Deployment Models Compared + +| 维度 | Public Cloud | Private Cloud | Hybrid Cloud | +|------|-------------|---------------|-------------| +| **安全性** | 中等（多租户隔离） | 高（专用资源） | 可控（敏感数据放私有） | +| **成本效率** | 高（小-中规模）/ 中（超大规模） | 中-高（大规模稳定负载） | 最优（动态分配） | +| **弹性扩展** | 极高 | 受限于私有容量 | 高（按需调用公） | +| **合规支持** | 基础合规 | 完全控制 | 灵活合规 | +| **管理复杂度** | 低 | 高 | 中-高 | + +## Workload Allocation Example (Hybrid) + +``` +Hybrid Cloud Workload Distribution: +┌──────────────────────────────────────────────┐ +│ Hybrid Cloud │ +│ │ +│ Private Cloud Public Cloud │ +│ ┌──────────────┐ ┌──────────────┐ │ +│ │ 核心业务系统 │←─────→│ 突发流量扩容 │ │ +│ │ (合规敏感) │ 策略 │ (Dev/Test) │ │ +│ │ ERP/CRM │ 驱动 │ CDN/静态资源 │ │ +│ │ 数据库 │ │ 批处理作业 │ │ +│ └──────────────┘ └──────────────┘ │ +│ ↕ 数据/应用共享 │ +└──────────────────────────────────────────────┘ +``` + +## Common Anti-Patterns (违背有意策略) + +1. **全押单一模式**：全部放公有云（忽略合规）或全部私有化（失去弹性） +2. **跟随趋势**：盲目追求"混合云"标签而未解决实际业务问题 +3. **供应商锁定**：过度依赖单一云供应商，迁移成本高 +4. **忽视 TCO**：只看初期成本，忽视长期运营费用 +5. **缺乏评估**：工作负载部署后不再复审，资源利用率低下 + +## Benefits of Intentional Approach + +- **成本最优化**：每种工作负载放在成本最低的云模式中 +- **安全性最强化**：敏感资产受专用资源保护 +- **业务连续性**：混合架构提供更好的灾难恢复能力 +- **技术敏捷性**：能快速响应业务变化和新技术 + +## Related Concepts + +- [[Cloud-Adoption-Strategy]] — 云战略的制定过程 +- [[Hybrid Cloud]] — 混合云是有意策略的常见实现形式 +- [[Multi-Cloud-Strategy]] — 多云策略是有意策略的进阶形式 +- [[Cost-Optimization]] — 有意策略驱动成本优化 +- [[Vendor-Lock-In]] — 有意策略需考虑避免供应商锁定 +- [[CapEx vs OpEx]] — 有意策略的财务决策基础 + +## Sources + +- [[Public vs Private vs Hybrid Cloud Differences Explained|sources/public-vs-private-vs-hybrid-cloud-differences-explained]] diff --git a/wiki/concepts/JFFS双清.md b/wiki/concepts/JFFS双清.md new file mode 100644 index 00000000..19ce339a --- /dev/null +++ b/wiki/concepts/JFFS双清.md @@ -0,0 +1,33 @@ +# JFFS双清 + +## Definition +清理路由器JFFS（Journaling Flash File System）分区中存储的文件系统缓存和数据配置的操作，用于刷机后重置干净的环境。 + +## Definition (English) +The process of clearing the JFFS (Journaling Flash File System) partition on ASUSWRT-based routers, removing cached data and old configurations to ensure a clean firmware environment. + +## When to Use +- 刷机后（从原厂固件刷入梅林固件后） +- 固件升级后出现异常 +- 重置插件配置 +- 清理旧缓存残留 + +## What It Clears +- JFFS 分区内容（插件存储、配置文件） +- 缓存数据 +- 旧的软件中心数据 + +## How to Perform +1. 进入梅林固件后台 +2. 找到"恢复/重置"选项 +3. 选择"恢复出厂设置" +4. 执行JFFS双清（可能需要手动命令） + +## Importance +- 防止旧配置干扰新固件 +- 清理过期的插件残留 +- 确保固件环境干净稳定 + +## Related +- [[固件刷入]] — JFFS双清是刷机流程的一部分 +- [[梅林固件]] — JFFS是梅林固件的文件系统 diff --git a/wiki/concepts/Kill-Switch.md b/wiki/concepts/Kill-Switch.md new file mode 100644 index 00000000..67ad9dc4 --- /dev/null +++ b/wiki/concepts/Kill-Switch.md @@ -0,0 +1,101 @@ +--- +title: "Kill Switch (应急切断开关)" +tags: [devops, disaster-recovery, reliability, feature-management, emergency-response] +created: 2026-04-25 +--- + +# Kill Switch (应急切断开关) + +**Kill Switch**（应急切断开关）是 [[Feature Flag]] 的一种紧急用法——在生产环境出现故障时，无需重新部署代码即可绕过或关闭故障组件的机制。Kill Switch 是 [[High Availability]] 的软件层保障。 + +## Definition + +Kill Switch 是部署在关键系统路径上的功能开关，用于在紧急情况下将流量切换到备用路径、备用组件或降级服务，从而实现秒级 RTO。 + +## Core Use Cases + +| 场景 | Kill Switch 动作 | RTO | +|------|-----------------|-----| +| 支付网关异常 | 切换到备用支付提供商 | 秒级 | +| 搜索结果异常 | 回退到旧搜索算法 | 秒级 | +| AI 模型产生幻觉 | 切换回上一版本模型 | 秒级 | +| 数据库迁移造成延迟 | 禁用新迁移相关功能 | 秒级 | +| 第三方 API 超时 | 切换到缓存数据或模拟响应 | 秒级 | + +## 与传统回滚的对比 + +| 维度 | 传统部署回滚 | Kill Switch | +|------|-------------|--------------| +| 触发时间 | 分钟到小时 | 秒级 | +| 数据影响 | 可能丢失新事务数据 | 不触碰数据层 | +| 故障窗口 | 整个回滚期间用户受影响 | 切换完成后立即恢复 | +| 操作复杂度 | 需要 CI/CD 流程重新部署 | 配置变更，点击开关 | +| 适用范围 | 全局，影响所有用户 | 可定向（地区/用户群/设备） | + +## Kill Switch 的价值 + +> "Instead of debugging under pressure while users suffer, you flip a switch and fix the problem properly later. Everybody wins." + +**传统方式**：在压力下调试 → 用户持续受损 → 时间窗口内无法保证修复质量 + +**Kill Switch 方式**：立即止血 → 切换到安全状态 → 有时间从容分析问题根源 + +## 设计原则 + +### 1. 识别关键路径 +- 支付流程 +- 用户认证 +- 核心数据写入 +- 第三方依赖调用 + +### 2. 预设备用路径 +- 备用支付提供商 +- 旧版本算法 +- 缓存数据 +- 降级服务（Degraded Mode） + +### 3. 可观测性优先 +- Kill Switch 切换前需要明确知道发生了什么 +- 监控指标、告警、日志必须到位 +- 切换后需要持续监控备用路径的健康状态 + +### 4. 文档化 +- 每个 Kill Switch 的触发条件需要事先定义 +- 团队成员需要知道开关在哪里、如何使用 +- 定期演练（Chaos Engineering） + +## Kill Switch 与 [[RTO]]/[[RPO]] + +Kill Switch 直接影响 RTO 和 RPO： + +- **RTO**：从小时级降至秒级（配置变更，不需要代码部署） +- **RPO**：保持近零（不触发数据回滚，不丢失新事务） + +## Kill Switch vs. Circuit Breaker + +| 维度 | Kill Switch | Circuit Breaker | +|------|-------------|-----------------| +| 触发方式 | 手动（人为决策） | 自动（基于错误率阈值） | +| 适用场景 | 已知故障、有预案 | 未知故障、无预期 | +| 灵活性 | 高（可指定备用路径） | 中（自动跳转到 fallback） | +| 协同需求 | 需要备用方案就绪 | 自动感知系统压力 | + +## 实践建议 + +1. **不要过度设计 Kill Switch**：每个关键路径设计 1-2 个关键开关即可 +2. **开关命名要语义化**：`kill_payment_v2` 而非 `flag_42` +3. **测试 Kill Switch**：定期在非紧急情况下测试开关是否正常工作 +4. **监控开关状态**：确保知道哪些开关处于开启/关闭状态 + +## Related Concepts + +- [[Feature Flag]] — Kill Switch 是 Feature Flag 的紧急用法 +- [[RTO]] — Kill Switch 将 RTO 从小时降至秒级 +- [[RPO]] — Kill Switch 保护 RPO（不丢失数据） +- [[High Availability]] — Kill Switch 是 HA 的软件层保障 +- [[Disaster Recovery]] — Kill Switch 是现代灾备的重要工具 +- [[Micro-Recovery]] — Kill Switch 实现 feature 级别的精准恢复 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/Micro-Recovery.md b/wiki/concepts/Micro-Recovery.md new file mode 100644 index 00000000..e9180946 --- /dev/null +++ b/wiki/concepts/Micro-Recovery.md @@ -0,0 +1,93 @@ +--- +title: "Micro-Recovery (微恢复)" +tags: [devops, disaster-recovery, reliability, feature-management] +created: 2026-04-25 +--- + +# Micro-Recovery (微恢复) + +**Micro-Recovery**（微恢复）是指不回滚整个部署，而是针对特定功能（Feature）进行精准恢复的能力。它是 [[Feature Flag]] 带来的核心理念转变：不再将整个应用视为单一恢复单元，而是按功能粒度进行风险管理。 + +## Definition + +> "Don't treat your entire app like one big system. Different features have different risks and business impacts, so they should have different recovery targets." + +传统灾备将整个系统作为恢复目标，而 Micro-Recovery 将恢复粒度缩小到单个功能模块。 + +## 传统方式 vs. Micro-Recovery + +| 维度 | 传统全量回滚 | Micro-Recovery | +|------|-------------|----------------| +| 恢复粒度 | 整个部署/系统 | 单个功能 | +| RTO | 小时级 | 秒级 | +| RPO | 取决于备份频率 | 近零 | +| 影响范围 | 全局（所有用户） | 局部（可定向） | +| 用户体验 | 可能感知到中断 | 可能完全无感知 | + +## Feature-Level Recovery Targets + +不同功能有不同的风险和业务影响： + +| 功能类型 | RTO 目标 | RPO 目标 | 恢复策略 | +|----------|----------|----------|----------| +| 核心支付处理 | 秒级 | 零丢失 | Kill Switch → 备用提供商 | +| 新推荐引擎 | 5 分钟 | 15 分钟 | Feature Flag → 旧算法 | +| Beta 仪表盘功能 | 30 分钟 | 1 小时 | Feature Flag → 禁用该功能 | + +## Micro-Recovery 的优势 + +### 1. 精准止血 +发现某功能异常时，只关闭该功能，其他正常功能不受影响。 + +### 2. 用户无感知 +> "Your checkout flow has a bug? Disable the new version and fall back to the old one in seconds. Users might not even notice." + +### 3. 数据保护 +[[Feature Flag]] 切换只改变代码执行路径，不触碰数据层，RPO 不受影响。 + +### 4. 定向恢复 +如果某功能只影响特定地区或用户群，可以只针对该群体禁用，其他用户继续使用新功能。 + +## 实现方式 + +Micro-Recovery 通过 [[Feature Flag]] 实现： + +```javascript +// 结账流程示例 +async function checkoutFlow(userId, cart) { + // Feature Flag 控制是否使用新版结账 + if (await flags.enabled('new-checkout-v2', userId)) { + return newCheckoutProcess(cart); // 故障时 → 切换到旧版 + } + return legacyCheckoutProcess(cart); +} +``` + +## Micro-Recovery vs. 其他恢复模式 + +| 模式 | 恢复粒度 | RTO | RPO | 复杂度 | +|------|----------|-----|-----|--------| +| 传统灾备 | 系统/数据中心 | 小时级 | 取决于备份 | 高 | +| CI/CD 回滚 | 部署版本 | 分钟级 | 可能丢失 | 中 | +| Kill Switch | 组件/功能 | 秒级 | 近零 | 低 | +| **Micro-Recovery** | **单个功能** | **秒级** | **近零** | **低** | + +## 实践建议 + +1. **功能分级**：不是所有功能都需要 Micro-Recovery 能力，关键路径必须有 +2. **Fallback 路径**：每个 Feature Flag 需要有明确的降级路径（Fallback） +3. **可观测性**：每次切换需要有清晰的日志和监控 +4. **文档化**：哪些功能支持 Micro-Recovery？团队需要知道 + +## Related Concepts + +- [[Feature Flag]] — Micro-Recovery 的技术基础 +- [[Kill Switch]] — Micro-Recovery 的紧急实现方式 +- [[RTO]] — Micro-Recovery 将 RTO 从小时降至秒级 +- [[RPO]] — Micro-Recovery 保护 RPO（不触碰数据层） +- [[Progressive Rollout]] — Micro-Recovery 与渐进式放量结合实现精细化风险控制 +- [[Disaster Recovery]] — Micro-Recovery 是现代灾备的重要组成部分 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/Multi-Account-Deployment.md b/wiki/concepts/Multi-Account-Deployment.md new file mode 100644 index 00000000..77c2255d --- /dev/null +++ b/wiki/concepts/Multi-Account-Deployment.md @@ -0,0 +1,48 @@ +--- +title: Multi-Account Deployment +type: concept +tags: [AWS, CloudOps, Infrastructure-as-Code, DevOps] +date: 2025-10-24 +--- + +## Definition +Multi-Account Deployment（多账户部署）是指使用 AWS CloudFormation StackSets 或类似工具，跨多个 AWS 账户和区域自动化部署和管理基础设施的实践。AWS 推荐使用多账户策略来改善安全隔离、成本管理和运营治理。 + +## Core Properties +- **自动化**：通过 StackSets 自动向目标账户推送配置 +- **一致性**：确保所有账户的配置保持一致 +- **可扩展性**：新增账户自动纳入部署范围（auto-deployment） +- **治理**：通过 AWS Organizations OU 层次结构管理账户分组 + +## AWS Recommended Account Structure +- **Management Account**：管理账户，承载中心监控、billing、 Organizations 管理 +- **Log Archive Account**：日志归档账户 +- **Security Tooling Account**：安全工具账户 +- **Workload Accounts**：工作负载账户，部署实际业务资源 + +## Key Mechanisms +- **AWS CloudFormation StackSets**：原生跨账户/跨区域部署服务 +- **AWS Organizations**：账户组织和管理 +- **Service Control Policies (SCPs)**：定义 OU 级别的权限边界 +- **Trusted Access**：启用 StackSets 在成员账户中执行操作 +- **Auto-Deployment**：新增账户自动部署预设 StackSet + +## Related Concepts +- [[AWS CloudFormation StackSets]]：多账户部署的核心工具 +- [[AWS Organizations]]：账户管理和分组 +- [[StackSets Deployment Visibility]]：多账户部署的可观测性挑战和解决方案 +- [[Cross-Account Monitoring]]：多账户部署需要跨账户监控支撑 +- [[Centralized Logging]]：多账户场景是集中日志的主要驱动因素 +- [[Landing Zone Architecture]]：AWS Landing Zone 架构定义了多账户最佳实践 +- [[Infrastructure as Code]]：多账户部署是 IaC 的高级应用场景 + +## Operational Challenges +1. **监控盲区**：跨50+账户部署故障时，逐账户排查效率低下 +2. **配置漂移**：手动配置导致账户间配置不一致 +3. **权限管理**：跨账户 IAM 权限配置的复杂性 +4. **成本追踪**：多账户成本归因和预算控制 + +## Solution Patterns +- [[Centralized Logging]]：集中存储所有账户的 CloudFormation 事件 +- [[Cross-Account Monitoring]]：统一监控界面覆盖所有账户 +- [[StackSets Deployment Visibility]]：CloudWatch Logs Insights 跨账户查询 diff --git a/wiki/concepts/Multi-Cloud-Strategy.md b/wiki/concepts/Multi-Cloud-Strategy.md index af661a2c..4f53017d 100644 --- a/wiki/concepts/Multi-Cloud-Strategy.md +++ b/wiki/concepts/Multi-Cloud-Strategy.md @@ -1,163 +1,131 @@ ---- -title: Multi-Cloud Strategy -source: https://www.bacancytechnology.com/blog/cloud-maturity-model -tags: [Cloud, Multi-Cloud, Strategy, Hybrid-Cloud, Cloud-Adoption] ---- - # Multi-Cloud Strategy -## Overview +> **Multi-Cloud Strategy** — 使用多个云服务提供商（公有云、私有云或两者结合）来托管工作负载和服务，以避免供应商锁定、增强弹性和优化成本。 -**Multi-Cloud Strategy** refers to an organization's use of multiple cloud computing services from different providers — combining public, private, and hybrid cloud environments to optimize flexibility, performance, and cost-efficiency. +## Definition -## Relationship with Cloud Maturity Model +多云策略（Multi-Cloud Strategy）是指组织同时使用两个或多个云服务提供商的服务。这种策略可以结合不同云服务商的优势，实现： -The Cloud Maturity Model addresses multi-cloud at multiple levels: +- **避免供应商锁定** — 不依赖单一提供商 +- **增强弹性和可用性** — 跨云冗余 +- **优化性能和成本** — 选择最适合每个工作负载的云 +- **满足合规和数据主权要求** — 地理位置控制 -### Level 2 (Repeatable, Opportunistic) -Organizations at this level consider diverse deployment models (private, hybrid, multi-cloud) to address: -- Security and compliance worries -- Need for flexibility in workload placement +## Multi-Cloud vs Hybrid Cloud -### Level 4 (Measured) -Companies at Level 4 adeptly use various cloud platforms and flexibly move workloads between them — this represents the **optimized state** of multi-cloud capability. +| 维度 | Multi-Cloud | Hybrid Cloud | +|------|------------|-------------| +| **定义** | 使用多个公有/私有云 | 公有云 + 私有/本地 | +| **连接** | 可选互联 | 强互联 | +| **用例** | 避免锁定、优化、成本 | 核心在本地、弹性在云 | +| **复杂性** | 中-高 | 中 | +| **成本** | 取决于设计 | 可能更优化 | -### Level 5 (Optimized) -The highest maturity level describes an organization that operates with an open and interoperable cloud environment across multiple providers. +## 8 Business Benefits -## Key Benefits of Multi-Cloud +### 1. Avoiding Vendor Lock-In -1. **Avoid Vendor Lock-in** — Freedom to choose best-of-breed services from each provider -2. **Optimize Costs** — Select most cost-effective provider for each workload -3. **Improve Resilience** — Redundancy across providers reduces single-point-of-failure risk -4. **Compliance Flexibility** — Match data residency requirements with appropriate provider/region -5. **Leverage Best Services** — Use unique capabilities from each cloud provider +- 保留谈判筹码 +- 避免单一供应商涨价风险 +- 灵活迁移工作负载 -## Multi-Cloud vs Related Concepts +### 2. Enhanced Resilience -| Concept | Description | -|---------|-------------| -| **Multi-Cloud** | Using multiple cloud services from different providers (can be all public, all private, or mix) | -| **Hybrid Cloud** | Combining private/public clouds with orchestration between them | -| **Poly-Cloud** | Strategic selection of best services from multiple providers | -| **Cross-Cloud** | Moving workloads seamlessly across cloud providers | +- 跨云冗余消除单点故障 +- 99.99%+ 可用性目标 +- 灾难恢复能力增强 -## Types of Cloud Maturity Models for Multi-Cloud +### 3. Improved Security -The Cloud Maturity Model document references: +- 隔离敏感工作负载 +- 利用各云最佳安全功能 +- 满足合规要求 -| Model | Focus | -|-------|-------| -| **Public Cloud Maturity Model** | Leveraging external cloud services for scalability and cost-efficiency | -| **Private Cloud Maturity Model** | Internal infrastructure for control and compliance | -| **Hybrid Cloud Maturity Model** | Integrating public and private clouds for flexibility | +### 4. Unlimited Scalability -## Challenges in Multi-Cloud Adoption +- 按需扩展计算资源 +- 全球分布式部署 +- 应对流量高峰 -1. **Complexity Management** — Managing multiple platforms, tools, and interfaces -2. **Data Consistency** — Ensuring data synchronization across providers -3. **Security Coordination** — Unified security policies across diverse environments -4. **Cost Visibility** — Tracking and optimizing spending across providers -5. **Skills Requirements** — Teams need expertise across multiple cloud platforms -6. **Interoperability** — Ensuring seamless integration between providers +### 5. Cost Optimization -## Best Practices for Multi-Cloud +- 选择最具成本效益的云服务 +- 持续成本监控和优化 +- 避免过度配置 -1. **Establish Clear Governance** — Define roles, responsibilities, and decision-making across providers -2. **Standardize where Possible** — Use common APIs, formats, and management tools -3. **Implement FinOps** — Cloud financial management across all providers -4. **Develop Cross-Cloud Skills** — Train teams on multiple platforms -5. **Use Cloud-Agnostic Tools** — Employ tools that work across providers (Kubernetes, Terraform, etc.) +### 6. Accelerated Innovation -## Related Concepts +- 访问最新云服务 +- 快速试验和原型 +- 缩短上市时间 -- [[Cloud-Maturity-Model]] -- [[Cloud-Adoption-Strategy]] -- [[Cloud-Native]] -- [[FinOps]] -- [[Hybrid-Cloud]] +### 7. Compliance Fulfillment + +- 数据主权控制 +- 满足地区合规要求 +- 审计和报告能力 + +### 8. Performance Optimization + +- 选择最近/最快的云区域 +- 针对工作负载优化 +- 降低延迟 ## ROI Maximization Framework -Based on [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi]]: +### 4 Paths to ROI -### Quantified Benefits -- **30%** reduction in operations costs after optimizing resources and negotiating favorable prices (Forrester) -- **78%** of businesses have workloads deployed in more than three public clouds for better agility and cost savings -- **86%** of companies intend to adopt multi-cloud approach by end of 2024 +1. **Cost Reduction** — 30% 成本降低 +2. **Resource Optimization** — 资源利用率提升 +3. **Efficiency Gains** — 运营效率提升 +4. **Elastic Scaling** — 弹性扩展节省 -### ROI Maximization Paths +### Industry Adoption -1. **Cost Reduction** - - Avoid high single-cloud pricing structures with one-size-fits-all models - - Drive hard bargains for better rates by leveraging multi-vendor competition - - Prevent paying for unnecessary resources through cross-cloud optimization - -2. **Resource Optimization** - - Allocate workloads to best-suited provider per task (e.g., Google Cloud for ML, AWS/Azure for general infra) - -3. **Efficiency Gains** - - Create tailored cloud architecture for specific needs - - Reduce downtime, improve performance - - Faster deployment times, better availability - -4. **Flexibility in Scaling** - - Dynamically allocate resources based on demand - - Expand on one provider during spikes without capacity limits on all providers - - Avoid overpaying for unused capacity - -5. **Better Risk Management** - - Eliminate single-provider dependency - - Other providers step in when one goes down +- 78% 的组织已采用多云策略 +- 平均使用 2-5 个云服务商 +- 混合云和多云是主流趋势 ## Implementation Roadmap -Based on [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi]], a 4-step implementation approach: +``` +Phase 1: Assessment & Strategy +├── 云就绪度评估 +├── 工作负载分析 +└── 供应商选择 -### Step 1: Assess Your Needs -- Identify goals: resiliency, cost optimization, or scale -- Budget analysis: initial and ongoing costs -- Resource requirements assessment +Phase 2: Foundation +├── 网络连接设计 +├── 安全架构 +└── 治理框架 -### Step 2: Choose Right Providers -- Align services with needs (AWS for infra, Google Cloud for analytics, Azure for AI) -- Evaluate features, security, compliance, cost, performance +Phase 3: Migration +├── 低风险工作负载优先 +├── 渐进式迁移 +└── 验证和测试 -### Step 3: Integrate and Manage -- Adopt multi-cloud management tools (Kubernetes, Terraform) -- Ensure data interoperability, avoid data silos +Phase 4: Optimization +├── 成本监控 +├── 性能调优 +└── 自动化运维 +``` -### Step 4: Monitor and Optimize -- Track resource usage (CloudHealth, Datadog) -- Implement cost-saving measures through workload optimization +## Key Risks and Mitigation -## Industry Use Cases +| 风险 | 缓解措施 | +|------|---------| +| 复杂性增加 | 统一管理平台 | +| 数据一致性 | 跨云数据同步策略 | +| 安全挑战 | 统一安全策略 | +| 成本超支 | FinOps 实践 | +| 技能缺口 | 培训和认证 | -### E-Commerce -- High availability during peak seasons (Black Friday, Cyber Monday) -- Scale resources across providers for traffic spikes -- Fast customer load times +## See Also -### Healthcare -- HIPAA-compliant patient data storage -- Distribute data across compliant cloud platforms -- Reduce costs from single-cloud dependency - -### Finance -- Stringent regulatory requirements compliance -- Use best security features of each provider -- Reduce risk and vendor lock-in for better SLAs and ROI - -## Challenges and Proven Solutions - -| Challenge | Solution | -|-----------|---------| -| Integration Complexity | Kubernetes, Terraform, cloud APIs | -| Security Risks | Centralized IAM, end-to-end encryption | -| Lack of Expertise | Upskilling, hiring experts, managed providers | - -## Sources - -- [[sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md]] -- [[sources/public-vs-private-vs-hybrid-cloud-differences-explained.md]] -- [[sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md]] +- [[Cloud Adoption Strategy]] — 云采用策略 +- [[Cloud Maturity Model]] — 云成熟度模型 +- [[Cloud Governance]] — 云治理 +- [[Cloud Cost Optimization]] — 云成本优化 +- [[Cloud-Native]] — 云原生 +- [[Hybrid Cloud]] — 混合云 +- [[FinOps]] — 云财务管理 diff --git a/wiki/concepts/Multi-Tenancy.md b/wiki/concepts/Multi-Tenancy.md new file mode 100644 index 00000000..09b2e78b --- /dev/null +++ b/wiki/concepts/Multi-Tenancy.md @@ -0,0 +1,75 @@ +--- +title: Multi-Tenancy +type: concept +tags: [cloud-computing, architecture, efficiency] +date: 2026-04-19 +--- + +# Multi-Tenancy + +**Multi-Tenancy（多租户架构）** 是一种软件架构模式，多个租户（用户或组织）共享同一底层基础设施、应用实例或资源池，同时通过逻辑隔离确保各租户数据的私密性。 + +## Definition + +多租户架构中，单个应用实例服务多个客户（租户），每个租户的数据和配置相互隔离，但共享计算、存储和网络资源。这是公有云实现规模经济效益的核心技术基础。 + +## How It Works + +``` +┌─────────────────────────────────────────────┐ +│ Cloud Provider Infrastructure │ +│ ┌─────────────────────────────────────┐ │ +│ │ Shared Application Instance │ │ +│ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌────┐ │ │ +│ │ │Tenant│ │Tenant│ │Tenant│ │Tn │ │ │ +│ │ │ A │ │ B │ │ C │ │.. │ │ │ +│ │ └──────┘ └──────┘ └──────┘ └────┘ │ │ +│ └─────────────────────────────────────┘ │ +└─────────────────────────────────────────────┘ +``` + +## Isolation Levels + +| 层级 | 说明 | 示例 | +|------|------|------| +| **数据隔离** | 租户数据逻辑/物理分离 | 独立数据库、独立 Schema、行级隔离 | +| **计算隔离** | 租户工作负载资源分离 | 独立容器、VM、命名空间 | +| **网络隔离** | 网络流量隔离 | VPC、虚拟网络、防火墙规则 | + +## Multi-Tenancy vs Single-Tenancy + +| 维度 | Multi-Tenancy | Single-Tenancy | +|------|--------------|----------------| +| **成本效率** | 高（资源共享） | 低（独占资源） | +| **隔离性** | 逻辑隔离（依赖虚拟化） | 物理隔离（独立基础设施） | +| **运维复杂度** | 高（需精细权限管理） | 低（独立部署） | +| **安全顾虑** | 更高（侧信道风险） | 更低（物理隔离） | +| **适用场景** | 公有云、SaaS | 私有云、高安全合规场景 | + +## In Cloud Context + +- **公有云**：默认多租户模式——多个组织共享同一批服务器 +- **私有云**：通常单租户，但也支持多租户配置（企业内部） +- **混合云**：跨租户数据流动带来额外的安全风险和管理复杂性 + +## Security Implications + +多租户环境下的安全挑战： +- **侧信道攻击**：恶意租户通过共享资源窃取信息 +- **数据泄露风险**：隔离机制失效导致跨租户数据访问 +- **资源竞争**：某一租户的高负载影响其他租户性能 +- **合规冲突**：不同租户的合规要求可能相互矛盾 + +缓解措施：微分段（Micro-segmentation）、零信任架构、加密隔离、Kubernetes 命名空间隔离。 + +## Related Concepts + +- [[Public Cloud]] — 多租户的主要载体 +- [[Private Cloud]] — 可选择多租户或单租户 +- [[Hybrid Cloud]] — 跨租户数据流动带来复杂性 +- [[High-Availability]] — 多租户架构需考虑高可用设计 +- [[Cloud-Security]] — 多租户隔离是云安全的核心议题 + +## Sources + +- [[Public vs Private vs Hybrid Cloud Differences Explained|sources/public-vs-private-vs-hybrid-cloud-differences-explained]] diff --git a/wiki/concepts/Multi-factor-Authentication.md b/wiki/concepts/Multi-factor-Authentication.md new file mode 100644 index 00000000..58c42b2d --- /dev/null +++ b/wiki/concepts/Multi-factor-Authentication.md @@ -0,0 +1,62 @@ +--- +title: "Multi-factor Authentication (MFA)" +type: concept +tags: [cloud-computing, security, identity] +date: 2025-03-02 +--- + +# Multi-factor Authentication (MFA) + +**MFA**（多因素认证）是云安全的基础机制，通过验证两个或多个独立身份凭证来确认用户身份，防止未经授权的访问。 + +## Definition + +多因素认证要求用户提供两种或以上的身份验证因素： +1. **知识因素**（Something you know）：密码、PIN +2. **持有因素**（Something you have）：手机、硬件令牌 +3. **固有因素**（Something you are）：指纹、面部识别 + +## MFA Methods + +| Method | Type | Security Level | +|--------|------|---------------| +| **SMS OTP** | 持有因素 | 中 | +| **TOTP** (Google Authenticator, Authy) | 持有因素 | 高 | +| **Hardware Token** (YubiKey) | 持有因素 | 极高 | +| **Biometrics** | 固有因素 | 高 | +| **Push Notification** | 持有因素 | 高 | +| **Adaptive/ Risk-based MFA** | 组合 | 极高 | + +## Cloud Provider Support + +| Provider | MFA Support | +|----------|------------| +| **AWS** | MFA via IAM, supports hardware tokens, virtual MFA, SMS | +| **Azure** | Azure AD MFA, Conditional Access, passwordless (FIDO2) | +| **Google Cloud** | 2FA, Security Keys, Google Prompt | + +## Cloud Myths Context + +MFA 是反驳"云不安全"误解的核心机制之一： +- 云平台强制或推荐 MFA，显著降低账户被盗风险 +- 云 MFA 实现比大多数本地系统更先进（自适应、条件访问） +- 云服务商的 MFA 通常免费或低成本提供 + +## Best Practices + +- **强制 MFA**：对所有用户强制启用 MFA +- **优先无密码**：FIDO2/WebAuthn 优于传统 OTP +- **条件访问**：高风险操作触发额外验证 +- **保护特权账户**：Admin 账户必须使用硬件令牌 +- **账户恢复**：安全的 MFA 恢复机制 + +## Related Concepts + +- [[cloud-security]] — 云安全 +- [[Identity-and-Access-Management]] — 身份与访问管理 +- [[Zero-Trust]] — 零信任 +- [[cloud-computing]] — 云计算 + +## Sources + +- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/concepts/NFS网络备份.md b/wiki/concepts/NFS网络备份.md new file mode 100644 index 00000000..2b72c32e --- /dev/null +++ b/wiki/concepts/NFS网络备份.md @@ -0,0 +1,46 @@ +--- +title: "NFS网络备份" +tags: [backup, nfs, network-storage, nas] +date: 2026-04-28 +--- + +# NFS网络备份 + +## Definition +NFS（Network File System）网络备份是指通过 NFS 协议将备份数据存储到网络存储设备（如 NAS）的方案。Clonezilla 通过 NFS 将磁盘镜像文件传输到 Synology NAS 等网络存储设备，实现跨设备的集中式备份存储。 + +## Why NFS for Clonezilla? +| 方案 | 优点 | 缺点 | +|------|------|------| +| NFS | Linux 原生支持，稳定可靠 | 需要配置 NFS 服务端 | +| SMB/CIFS | Windows 兼容性好 | 速度稍慢 | +| 外置硬盘 | 简单直接 | 需手动携带，不够自动化 | + +> Clonezilla 官方推荐 NFS 作为首选备份存储方案。 + +## Workflow +``` +源机器 (Clonezilla Live) + → 选择 nfs_server + → DHCP 自动获取 IP（或手动配置静态 IP） + → 输入 NAS IP（如 192.168.3.17） + → 输入 NFS 共享路径（如 /volume2/backups） + → 挂载成功 → 保存镜像到 NAS +``` + +## Prerequisites +1. NAS 端开启 NFS 服务 +2. 配置 NFS 导出（/etc/exports） +3. 源机器与 NAS 网络互通 +4. 防火墙放行 NFS 端口（2049/TCP） + +## Related Concepts +- [[全盘镜像备份]] — NFS 存储的对象类型 +- [[永久挂载]] — NFS 备份前需先完成永久挂载配置 +- [[增量备份]] — 互补方案（NFS 镜像 vs rsync 增量） +- [[裸机恢复]] — 从 NFS 镜像还原系统 + +## Related Sources +- [[clonezilla对ubuntu-server进行全盘镜像备份]] +- [[ubuntu服务器通过rsync实现日常增量备份]] +- [[如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹]] diff --git a/wiki/concepts/NVMe硬盘分区.md b/wiki/concepts/NVMe硬盘分区.md new file mode 100644 index 00000000..f6464dd2 --- /dev/null +++ b/wiki/concepts/NVMe硬盘分区.md @@ -0,0 +1,37 @@ +--- +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工作站笔记本上]] diff --git a/wiki/concepts/OWASP-Top-Ten.md b/wiki/concepts/OWASP-Top-Ten.md new file mode 100644 index 00000000..1b417a1b --- /dev/null +++ b/wiki/concepts/OWASP-Top-Ten.md @@ -0,0 +1,106 @@ +# OWASP Top Ten + +## Definition +The OWASP Top Ten represents a broad consensus about the most critical security risks to web applications. It is a standard awareness document for developers and web application security. + +## Aliases +- OWASP Top 10 +- OWASP Top Ten Web Application Security Risks + +## Purpose +为开发者和安全团队提供最关键 web 应用安全风险的共识性列表，是安全编码和测试的基础标准。 + +## Current List (2021) + +### A01:2021 – Broken Access Control +访问控制失效，包括： +- 越权访问 +- 绕过访问控制 +- 不安全的直接对象引用 + +### A02:2021 – Cryptographic Failures +密码学失败，包括： +- 敏感数据泄露 +- 弱加密算法 +- 不正确的密钥管理 + +### A03:2021 – Injection +注入攻击，包括： +- SQL 注入 +- NoSQL 注入 +- OS 命令注入 +- LDAP 注入 + +### A04:2021 – Insecure Design +不安全设计，包括： +- 缺失或无效的访问控制 +- 业务逻辑漏洞 +- 威胁建模缺失 + +### A05:2021 – Security Misconfiguration +安全配置错误，包括： +- 不安全的默认配置 +- 错误处理信息泄露 +- 云服务配置错误 + +### A06:2021 – Vulnerable and Outdated Components +易受攻击和过时的组件，包括： +- 使用有漏洞的库 +- 未更新依赖 +- 不支持组件 + +### A07:2021 – Identification and Authentication Failures +身份识别和认证失败，包括： +- 弱密码策略 +- 会话管理问题 +- 凭证泄露 + +### A08:2021 – Software and Data Integrity Failures +软件和数据完整性失败，包括： +- 不安全的 CI/CD +- 依赖混淆攻击 +- 更新未签名 + +### A09:2021 – Security Logging and Monitoring Failures +安全日志和监控失败，包括： +- 未记录安全事件 +- 告警未处理 +- 响应延迟 + +### A10:2021 – Server-Side Request Forgery (SSRF) +服务端请求伪造，包括： +- 从应用获取内部资源 +- 绕过防火墙 +- 访问云元数据服务 + +## Integration with DevSecOps + +### Development Phase +- 安全编码培训以 OWASP Top Ten 为基础 +- SAST 工具检测相关漏洞 +- 代码审查关注常见问题 + +### Testing Phase +- DAST 工具模拟 Top Ten 攻击 +- 渗透测试重点关注 +- 自动化测试集成 + +### Operations Phase +- 监控 Top Ten 相关告警 +- 漏洞扫描覆盖 +- 补丁管理 + +## Related Concepts +- [[DevSecOps]] — OWASP Top Ten 是安全编码和测试的基础 +- [[SAST]] — 检测代码中的 OWASP 问题 +- [[DAST]] — 动态检测 OWASP 漏洞 +- [[SCA]] — 检测易受攻击的组件 +- [[Shift-Left-Security]] — 早期发现 OWASP 问题 + +## Resources +- OWASP 官网：https://owasp.org/www-project-top-ten/ +- OWASP Cheat Sheets +- OWASP WebGoat（学习工具） + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Pay-as-you-go.md b/wiki/concepts/Pay-as-you-go.md new file mode 100644 index 00000000..fb4d8c2e --- /dev/null +++ b/wiki/concepts/Pay-as-you-go.md @@ -0,0 +1,55 @@ +--- +title: "Pay-as-you-go" +type: concept +tags: [cloud-computing, billing, economics] +date: 2025-03-02 +--- + +# Pay-as-you-go + +**Pay-as-you-go**（按使用量付费）是云计算的核心经济模型，用户仅为实际使用的资源付费，无需长期承诺或前期投入。 + +## Definition + +按需计费模式，允许用户根据实际资源消耗（计算、存储、网络）进行付费，无需预留容量或签订长期合同。 + +## Key Characteristics + +- **无前期成本**：无需购买硬件或签订长期合同 +- **弹性计费**：资源使用量决定费用，粒度可到秒/分钟 +- **按需扩缩**：流量高峰时扩容，低谷时缩减 +- **成本可见性**：实时监控和成本分摊 + +## Cost Optimization Strategies + +| Strategy | Description | Savings | +|----------|-------------|---------| +| **Reserved Instances/Spot** | 预留或抢占式实例 | 30-70% vs On-demand | +| **Auto Scaling** | 根据负载自动调整容量 | 避免过度配置 | +| **Serverless** | 按函数执行计费 | 仅在函数运行时计费 | +| **Savings Plans** | 承诺使用量换取折扣 | 20-40% 折扣 | + +## Cloud Myths Context + +Pay-as-you-go 是反驳"云太贵"误解的核心证据： +- **传统采购**：CapEx 模式，前期大量投入，利用率低时浪费 +- **云按需付费**：OpEx 模式，按需使用，成本与业务对齐 +- 消除本地硬件采购、维护和升级的隐性成本 + +## Challenges + +- **Egress 费用**：数据流出云端时的高额流量费 +- **意外计费**：缺乏监控导致超预期费用 +- **长期成本**：稳定负载下预留实例的复杂性 +- **复杂性**：多种计费模式的优化需要专业知识 + +## Related Concepts + +- [[Cost-Optimization]] — 云成本优化 +- [[cloud-computing]] — 云计算 +- [[Scalability]] — 可扩展性 +- [[FinOps]] — 云财务管理 + +## Sources + +- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/concepts/Penetration-Testing.md b/wiki/concepts/Penetration-Testing.md new file mode 100644 index 00000000..5536cab2 --- /dev/null +++ b/wiki/concepts/Penetration-Testing.md @@ -0,0 +1,81 @@ +# Penetration Testing + +## Definition +Penetration testing (pen testing) is an authorized simulated cyberattack on a computer system, performed to evaluate the security of the system. + +## Aliases +- Pen Testing +- Ethical Hacking +- Security Testing + +## Concept +渗透测试是授权的模拟网络攻击，用于评估系统的安全性。 + +## Types + +### By Scope +- **Black Box**：测试人员不了解目标内部结构 +- **White Box**：测试人员完全了解系统 +- **Grey Box**：部分了解系统信息 + +### By Target +- Network Penetration Testing +- Web Application Penetration Testing +- Mobile Application Testing +- Social Engineering +- Physical Security Testing + +## Methodology + +### PTES (Penetration Testing Execution Standard) +1. Pre-Engagement Interactions +2. Intelligence Gathering +3. Threat Modeling +4. Vulnerability Analysis +5. Exploitation +6. Post-Exploitation +7. Reporting + +### OWASP Testing Guide +- 信息收集 +- 配置和部署管理测试 +- 身份管理测试 +- 认证测试 +- 授权测试 +- 会话管理测试 +- 输入验证测试 +- 错误处理测试 +- 密码学测试 +- 业务逻辑测试 +- 客户端测试 + +## Tools +- Metasploit — 渗透测试框架 +- Burp Suite — Web 应用测试 +- Nmap — 网络扫描 +- Wireshark — 网络协议分析 +- SQLmap — SQL 注入测试 +- Kali Linux — 渗透测试操作系统 + +## Integration with DevSecOps + +### Continuous Pen Testing +- 定期执行 +- 自动化工具集成 +- 关键时间点测试 + +### Red Team Operations +- 模拟真实攻击 +- 全面评估防御能力 +- 团队对抗演练 + +## Related Concepts +- [[DevSecOps]] — 渗透测试是安全评估的重要组成 +- [[Bug-Bounty]] — 持续外部安全测试 +- [[Vulnerability-Scanning]] — 自动化漏洞发现 +- [[DAST]] — 动态应用安全测试 +- [[Threat-Modeling]] — 威胁建模 +- [[Incident-Response]] — 事件响应 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Policy-as-Code.md b/wiki/concepts/Policy-as-Code.md new file mode 100644 index 00000000..aa68b79e --- /dev/null +++ b/wiki/concepts/Policy-as-Code.md @@ -0,0 +1,75 @@ +--- +title: "Policy as Code (PaC)" +type: concept +tags: [security, devops, compliance, automation] +date: 2025-03-01 +--- + +## Definition + +策略即代码（Policy as Code）是将安全、合规和运维策略编写为可执行代码的做法，通过自动化执行和持续验证替代人工审计和手动检查。 + +## Core Concept + +``` +传统模式: PaC模式: +───────── ───────── +人工编写策略 → 文档化 → 人工检查 → 间歇性审计 + ↓ +策略代码化 → 自动执行 → 持续验证 → 实时合规 +``` + +## Benefits + +| 优势 | 描述 | +|------|------| +| **一致性** | 每次执行使用相同规则，消除人为错误 | +| **可版本控制** | 策略变更通过Git跟踪和审查 | +| **自动化** | CI/CD集成，持续验证 | +| **可测试** | 策略可单元测试和集成测试 | +| **审计友好** | 自动生成审计日志 | + +## Implementation Patterns + +### 1. OPA (Open Policy Agent) +```rego +# OPA Rego策略示例 +package kubernetes.admission + +deny[msg] { + input.request.kind.kind == "Pod" + not input.request.object.spec.hostIPC + msg := "HostIPC is not allowed" +} +``` + +### 2. Terraform Sentinel +```hcl +# Terraform策略即代码 +policy "require-tags" { + enforcement_level = "advisory" + validate = func(resource) { + all resource.values.tags != undefined + } +} +``` + +### 3. In ITSM Context + +在[[ITSM]]中，PaC支撑[[Security-and-Compliance]]： + +- **变更合规** — 自动验证变更符合安全策略 +- **配置基线** — 确保配置项符合基线 +- **访问控制** — 自动执行最小权限原则 +- **审计自动化** — 生成合规报告 + +## Related Concepts + +- [[Zero-Trust-Architecture]] — ZTA依赖PaC实现自动化 +- [[Security-and-Compliance]] — PaC的核心应用场景 +- [[Infrastructure-as-Code]] — IaC与PaC的协同 +- [[DevSecOps]] — PaC在DevSecOps中的角色 + +## Sources + +- [[understanding-complete-itsm]] — Policy-as-Code在ITSM中的应用 diff --git a/wiki/concepts/Predictive-Maintenance.md b/wiki/concepts/Predictive-Maintenance.md new file mode 100644 index 00000000..4e649049 --- /dev/null +++ b/wiki/concepts/Predictive-Maintenance.md @@ -0,0 +1,69 @@ +--- +title: "Predictive Maintenance" +tags: + - devops + - reliability + - ai + - operations +created: 2026-04-25 +--- + +# Predictive Maintenance + +## Definition + +Predictive Maintenance 是基于历史故障模式学习，**主动建议补丁或变更**以预防非计划停机的方法。Agentic AI 分析历史运维数据，预测潜在故障并提前采取预防措施。 + +## Mechanism + +``` +Historical Data → Pattern Learning → Failure Prediction → Proactive Action + ↓ +运维日志、告警历史、变更记录、监控数据 + ↓ +ML 模型识别故障前兆模式 + ↓ +- 磁盘 I/O 逐渐下降 → 预测磁盘故障 → 建议迁移 +- 内存使用率周期性峰值 → 预测 OOM → 建议扩容 +- API 响应时间逐步增加 → 预测容量瓶颈 → 建议扩缩容 +``` + +## 与 Self-Healing Systems 的关系 + +| 维度 | Reactive (Self-Healing) | Predictive (Predictive Maintenance) | +|------|------------------------|-----------------------------------| +| 时机 | 故障发生后修复 | 故障发生前预防 | +| 目标 | 减少 MTTR | 减少 MTBF (Mean Time Between Failures) | +| 成本 | 被动投入 | 主动投入，高 ROI | +| 成熟度 | Level 4 AIOps | Level 5 AIOps | + +## 示例 + +> Agentic AI analyzes 6 months of Kubernetes pod restart logs and identifies: +> - Pods restart every 48-72 hours +> - Pattern correlates with memory leak in v2.3.1 of service +> - **Predicts**: Next scheduled restart will cause cascade failure +> - **Proposes**: Patch to v2.3.2 + preventive restart during low-traffic window + +## 与 [[AIOps]] 的关系 + +Predictive Maintenance 是 [[AIOps]] Level 5 (Optimizing) 的核心能力： + +```python +DevOps_Maturity_AIOps = { + "Level 3 - Defined": "Smart Alerting", + "Level 4 - Advanced": "Self-Healing: Automated Remediation", + "Level 5 - Optimizing": "Predictive Maintenance ←" # ← 本页 +} +``` + +## Related Concepts + +- [[Self-Healing Systems]] — Predictive 是 Reactive 的进化 +- [[AIOps]] — Predictive Maintenance 是 AIOps 的高级能力 +- [[MTTR]] — Predictive 改善 MTBF，MTTR 不变但故障减少 +- [[Availability]] — Predictive 直接提升可用性 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] diff --git a/wiki/concepts/Private-Cloud.md b/wiki/concepts/Private-Cloud.md new file mode 100644 index 00000000..4a3af673 --- /dev/null +++ b/wiki/concepts/Private-Cloud.md @@ -0,0 +1,144 @@ +# Private Cloud + +> **Private Cloud** — 私有云是专属于单一组织的云环境，通过安全私有网络访问，可由组织本地托管或由第三方供应商托管，提供比公有云更高的性能、安全性和控制力。 + +## Definition + +私有云（Private Cloud）是专为单个组织构建和运营的云基础设施。与公有云不同，私有云的资源不与其他组织共享，因此提供更强的安全性、可定制性和性能保证。私有云可以部署在组织自己的数据中心（on-premises），也可以由第三方供应商在其设施中托管（hosted private cloud）。 + +## Key Characteristics + +| 特征 | 描述 | +|------|------| +| **独占环境** | 资源仅供单一组织使用，无多租户共享 | +| **高安全性** | 自定义安全协议和配置，满足严格合规要求 | +| **私有网络访问** | 通过专用连接访问，非公开互联网 | +| **可定制性** | 根据组织需求深度定制基础设施 | +| **强SLA保证** | 高性能和高效率的服务级别协议 | +| **部署灵活性** | 可本地托管、托管托管或混合部署 | + +## Deployment Architecture + +``` +┌──────────────────────────────────────────┐ +│ 组织 A 私有云环境 │ +│ │ +│ ┌──────────────────────────────────┐ │ +│ │ 私有数据中心 / 托管设施 │ │ +│ │ │ │ +│ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ +│ │ │ Web │ │ App │ │ DB │ │ │ +│ │ │层 │ │ 层 │ │ 层 │ │ │ +│ │ └─────┘ └─────┘ └─────┘ │ │ +│ │ │ │ +│ │ 虚拟化层（VMware/KVM/OpenStack） │ │ +│ │ 专用物理服务器集群 │ │ +│ └──────────────────────────────────┘ │ +│ │ +│ ↕ 私有网络/专用连接 │ +│ ┌──────────────────────────────────┐ │ +│ │ 组织内部用户 / 远程用户 │ │ +│ └──────────────────────────────────┘ │ +└──────────────────────────────────────────┘ +``` + +## Advantages + +### 1. 独占安全环境 +- 其他组织无法访问的专用安全环境 +- 定制安全协议满足严格合规需求 +- 不受其他租户安全事件影响（"噪音邻居"问题消除） + +### 2. 自定义安全配置 +- 运行自定义协议、配置和措施 +- 根据独特工作负载需求定制安全策略 +- 满足行业特定合规标准（HIPAA、PCI-DSS、ISO 27001） + +### 3. 无性能权衡的扩展性 +- 高扩展性和效率满足不可预测需求 +- 不牺牲安全性和性能 +- 可根据业务增长弹性扩展容量 + +### 4. 高效性能 +- 可靠的高SLA性能和效率 +- 无资源竞争和延迟问题 +- 专属资源保证一致性性能 + +### 5. 灵活性 +- 根据组织变化的需求灵活转型基础设施 +- 支持定制化集成和工作负载优化 +- 适应业务和技术双重变革 + +### 6. 专属资源无争用 +- 不与其他组织共享资源 +- 不存在资源竞争导致的性能下降 +- 延迟可预测和可控 + +## Drawbacks + +### 1. 成本较高 +- 相比公有云替代方案，TCO相对较高 +- 尤其对于短期使用场景不经济 +- 需要持续的资本投入和维护成本 + +### 2. 远程使用受限 +- 高安全措施可能导致远程用户访问受限 +- 移动办公支持不如公有云灵活 +- 需要额外的VPN或专线配置 + +### 3. 扩展性受限 +- 若数据中心局限于本地计算资源，基础设施可能无法高扩展 +- 应对突发流量需要提前容量规划 +- 扩展周期长于公有云 + +### 4. 管理复杂 +- 需要大量内部技术专业知识运营私有云 +- 维护、更新、安全需要专职团队 +- 运营成本持续较高 + +### 5. 潜在资源浪费 +- 可能无法充分利用资源，导致昂贵基础设施浪费 +- 容量规划不准确导致过度配置 +- 闲置资源成本高 + +## When to Use Private Cloud + +| 场景 | 说明 | +|------|------| +| **高度监管行业** | 金融、医疗、政府等对数据安全有严格要求的行业 | +| **敏感数据处理** | 包含个人隐私、商业机密、知识产权的数据 | +| **强控制和安全性要求** | 需要对IT工作负载和底层基础设施的完全控制 | +| **大型企业** | 需要先进技术数据中心高效运营的复杂组织 | +| **高可用性需求** | 任务关键型应用需要99.99%+ SLA保证 | +| **合规驱动** | 必须满足特定行业法规的数据驻留要求 | + +## Cost Structure + +| 成本维度 | 私有云 | 公有云 | +|----------|--------|--------| +| 前期资本投入 | 高（硬件采购） | 低 | +| 扩展成本 | 需要新硬件 | 按使用付费 | +| 人员成本 | 高（专职团队） | 低（供应商管理） | +| 维护成本 | 内部承担 | 提供商承担 | +| 适合场景 | 长期、稳定、高价值负载 | 短期、弹性、变化负载 | + +## Related Concepts + +- [[Public Cloud]] — 公有云部署模式对比 +- [[Hybrid Cloud]] — 混合云结合公私优势 +- [[Cloud Security]] — 云安全 +- [[Cloud Compliance]] — 云合规性 +- [[High Availability]] — 高可用性 +- [[SLA]] — 服务级别协议 +- [[Disaster Recovery Planning]] — 灾难恢复规划 +- [[ISO-27001]] — 信息安全管理体系标准 +- [[HIPAA]] — 美国医疗健康信息隐私法规 +- [[GDPR]] — 欧盟通用数据保护条例 + +## See Also + +- [[Cloud Computing]] — 云计算基础 +- [[Cloud-Adoption-Strategy]] — 云采用策略 +- [[Cloud-Maturity-Model]] — 云成熟度模型 +- [[Cloud-Migration]] — 云迁移 +- [[Shared-Responsibility-Model]] — 共享责任模型 diff --git a/wiki/concepts/Problem-Management.md b/wiki/concepts/Problem-Management.md new file mode 100644 index 00000000..5dd250e5 --- /dev/null +++ b/wiki/concepts/Problem-Management.md @@ -0,0 +1,63 @@ +--- +title: "Problem Management" +type: concept +tags: [itsm, incident-management, operations] +date: 2025-03-01 +--- + +## Definition + +问题管理（Problem Management）是[[ITSM]]的核心流程之一，专注于**识别和分析IT服务问题的根本原因**，防止同类事件重复发生。与事件管理（Incident Management）处理症状不同，问题管理处理的是根本原因。 + +## Problem Management vs Incident Management + +| 维度 | 事件管理 | 问题管理 | +|------|---------|---------| +| 目标 | 快速恢复服务 | 消除根本原因 | +| 处理 | 症状 | 根因 | +| KPI | MTTR | 问题消除率 | +| 时效 | 即时 | 中长期 | + +## Problem Management Process + +``` +┌──────────────┐ ┌──────────────┐ ┌──────────────┐ +│ Problem │ → │ Root Cause │ → │ Known Error │ +│ Detection │ │ Analysis │ │ Document │ +└──────────────┘ └──────────────┘ └──────────────┘ + ↓ ↓ ↓ + AI Anomaly ML-enhanced Known Error + Detection RCA Process Database (KEDB) +``` + +## Modern Problem Management (ITSM 2.0) + +在[[ITSM 2.0]]中，问题管理由AI驱动： + +### AI-Driven Features +- **Anomaly Detection** — 自动识别异常模式 +- **Predictive Analytics** — 预测潜在问题 +- **ML-enhanced RCA** — 机器学习加速根因分析 +- **Automated KEDB Updates** — 自动更新已知错误库 + +## Key Metrics + +| 指标 | 描述 | +|------|------| +| Problem Resolution Rate | 问题解决率 | +| Mean Time to Diagnose (MTTD) | 平均诊断时间 | +| Recurring Incidents | 重复发生事件数 | +| Known Error Accuracy | 已知错误准确率 | + +## Related Concepts + +- [[ITSM]] — 父框架 +- [[Incident-Management]] — 事件管理 +- [[Root-Cause-Analysis]] — 根因分析 +- [[AIOps]] — AI驱动的分析能力 +- [[MTTD]] — 平均诊断时间 +- [[Event-Correlation]] — 事件关联 + +## Sources + +- [[understanding-complete-itsm]] — AI-driven Problem Management diff --git a/wiki/concepts/Progressive-Rollout.md b/wiki/concepts/Progressive-Rollout.md new file mode 100644 index 00000000..c38db84d --- /dev/null +++ b/wiki/concepts/Progressive-Rollout.md @@ -0,0 +1,106 @@ +--- +title: "Progressive Rollout (渐进式放量)" +tags: [devops, continuous-delivery, feature-management, risk-mitigation] +aliases: [Canary Deployment, 灰度发布, Canary Release] +created: 2026-04-25 +--- + +# Progressive Rollout (渐进式放量) + +**Progressive Rollout**（渐进式放量/灰度发布）是一种通过 [[Feature Flag]] 控制新功能逐步向用户群发布的风险管理策略。与"全有或全无"的传统部署不同，Progressive Rollout 将影响范围控制在最小范围内，从而实现**可量化的 RTO**。 + +## Aliases +- Canary Deployment +- Canary Release +- 灰度发布 +- Staged Rollout + +## Core Mechanism + +> "Instead of flipping the switch for everyone simultaneously, roll out gradually." + +``` +1% 用户 → 观察错误率、性能指标 +5% 用户 → 监控转化率、用户反馈 +25% 用户 → 检查下游系统负载 +100% 用户 → 完成全量发布 +``` + +## Progressive Rollout vs. Big Bang Release + +| 维度 | Big Bang（全量发布） | Progressive Rollout（渐进式放量） | +|------|---------------------|----------------------------------| +| 影响范围 | 全部用户 | 受控小群体 | +| 问题发现 | 事后 | 事中（1% 阶段即可发现） | +| RTO（如果出问题） | 小时级（紧急回滚） | 秒级（关闭开关） | +| 回滚风险 | 可能丢失新事务 | 无数据损失 | +| 团队压力 | 高（2AM 部署） | 低（白天放量） | +| 反馈收集 | 事后分析 | 实时监控 | + +## RTO 重新定义 + +> "If something breaks at the 5% mark, you've contained the damage. Your RTO is measured in seconds (flip the flag off) instead of hours (emergency rollback deployment)." + +| 场景 | RTO（Big Bang） | RTO（Progressive Rollout） | +|------|-----------------|---------------------------| +| 发现问题 | 全量发布后 | 1% 阶段即可监控到 | +| 止血时间 | 小时级（回滚部署） | 秒级（关闭开关） | +| 受影响用户 | 100% | 最多 5%（当前阶段） | + +## 放量策略 + +### 基于用户群体的定向放量 + +| 策略 | 说明 | 适用场景 | +|------|------|----------| +| 随机抽样 | 随机选取 X% 用户 | 通用场景 | +| 地区定向 | 先在特定地区放量 | 法规合规、时区测试 | +| 用户分层 | 优先向付费用户放量 | 降低高价值用户风险 | +| 设备类型 | 先桌面后移动 | 移动端兼容性风险 | +| Beta 用户 | 先向内部/Beta 用户开放 | 需要早期反馈 | + +### 基于指标的自动 gates + +```yaml +rollout_stages: + - percentage: 1 + gates: + - error_rate < 0.1% + - p95_latency < 500ms + - percentage: 5 + gates: + - conversion_rate > baseline - 5% + - support_tickets < 10 + - percentage: 25 + gates: + - downstream_api_latency < 200ms + - no_critical_errors +``` + +## 与 [[Kill Switch]] 的关系 + +Progressive Rollout 和 Kill Switch 是同一机制的两面： + +- **Progressive Rollout**：控制功能如何到达用户（渐进式） +- **Kill Switch**：在发现问题时紧急切断（防御性） + +两者结合 → 既有渐进放量的可控性，又有 Kill Switch 的应急保障。 + +## 实践要点 + +1. **监控先行**：每次放量前确保监控仪表盘就绪 +2. **定义回退标准**：什么指标触发停止放量或回退？ +3. **自动化放量**：避免手动操作带来的错误 +4. **跨团队对齐**：产品、工程、运营需要共同定义放量节奏 + +## Related Concepts + +- [[Feature Flag]] — Progressive Rollout 的技术基础 +- [[Kill Switch]] — Progressive Rollout 的应急保障 +- [[RTO]] — Progressive Rollout 将 RTO 从小时降至秒级 +- [[Deployment-vs-Release]] — Progressive Rollout 实现部署与发布的解耦 +- [[Micro-Recovery]] — Progressive Rollout 支持 feature 级别的精准恢复 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/PromQL.md b/wiki/concepts/PromQL.md new file mode 100644 index 00000000..7682d2ac --- /dev/null +++ b/wiki/concepts/PromQL.md @@ -0,0 +1,83 @@ +--- +title: "PromQL" +type: concept +aliases: [Prometheus Query Language, Prometheus查询语言] +tags: [prometheus, query, monitoring, time-series] +date: 2025-11-11 +--- + +# PromQL + +## Overview +PromQL（Prometheus Query Language）是 Prometheus 内置的时序数据查询语言，用于从 Prometheus TSDB 中检索和处理指标数据。它支持即时向量查询（返回当前时间点的样本）、范围向量查询（返回一段时间内的样本序列）、标量转换、聚合操作和丰富的函数库。 + +## Query Types + +### 即时向量查询（Instant Vector） +返回当前时刻的一组时间序列，每个序列只有一个样本值： +```promql +node_memory_MemAvailable_bytes +``` +### 范围向量查询（Range Vector） +返回一段时间内的样本序列，用于计算速率： +```promql +rate(node_cpu_seconds_total{mode="user"}[2m]) +``` +### 标量（Scalar） +没有时间序列的单个数值： +```promql +count(node_cpu_seconds_total) +``` + +## Aggregation Operators +PromQL 内置丰富的聚合操作符： +| 操作符 | 说明 | +|--------|------| +| `sum()` | 求和 | +| `avg()` | 平均值 | +| `min()` / `max()` | 最小/最大值 | +| `count()` | 计数 | +| `stddev()` / `stdvar()` | 标准差/方差 | +| `topk()` / `bottomk()` | 最大/最小的 k 个值 | +| `rate()` | 平均速率（适合 Counter） | +| `increase()` | 增量（适合 Counter） | +| `irate()` | 瞬时速率（适合快速变化指标） | + +## Common Patterns for Home Server Monitoring +```promql +# CPU 使用率（5分钟平均 > 85%） +avg(rate(node_cpu_seconds_total{mode="user"}[2m])) * 100 > 85 + +# 磁盘可用空间 < 10% +(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) < 0.10 + +# 内存可用率 < 15% +(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.15 + +# HTTP 探测失败（黑盒） +probe_success == 0 + +# TLS 证书剩余天数 < 14 天 +(probe_ssl_earliest_cert_expiry - time()) / 86400 < 14 + +# 容器重启次数 +increase(container_restart_count[5m]) > 0 +``` + +## Label Matchers +| Matcher | 说明 | +|---------|------| +| `=` | 精确匹配 | +| `!=` | 不等于 | +| `=~` | 正则匹配 | +| `!~` | 正则不匹配 | + +示例：`{job=~"node.*", mode!="idle"}` + +## Related Entities +- [[Prometheus]] — 查询引擎宿主 + +## Related Concepts +- [[Prometheus告警规则]] — 基于 PromQL 的告警条件 +- [[时序数据库]] — 数据模型基础 +- [[Exporter]] — 指标来源 diff --git a/wiki/concepts/Prometheus告警规则.md b/wiki/concepts/Prometheus告警规则.md new file mode 100644 index 00000000..bcf946e0 --- /dev/null +++ b/wiki/concepts/Prometheus告警规则.md @@ -0,0 +1,116 @@ +--- +title: "Prometheus告警规则" +type: concept +aliases: [Prometheus Alert Rules, Prometheus告警规则YAML, alert_rules] +tags: [prometheus, alerting, monitoring, devops, prometheus] +date: 2025-11-11 +--- + +# Prometheus告警规则 + +## Overview +Prometheus 告警规则（Alert Rules）是以 YAML 格式定义的告警条件，基于 PromQL 表达式判断指标状态。当表达式结果为真且持续超过 `for` 指定的评估周期数时，告警从 `pending` 状态转为 `firing` 状态，触发后发送给 Alertmanager 进行路由分发。 + +## Rule Format +```yaml +groups: +- name: # 告警组名称（全局唯一） + interval: # 评估间隔（可选，默认 evaluation_interval） + rules: + - alert: # 告警名称（Alertmanager 中唯一标识） + expr: # 触发条件的 PromQL 表达式 + for: # 持续时间（告警变为 firing 前需满足条件的最短时间） + labels: # 标签（用于 Alertmanager 路由和分类） + severity: # 如：critical / warning / info + annotations: # 注解（人类可读的告警描述） + summary: # 简短摘要 + description: # 详细描述，支持模板变量 +``` + +## Template Variables（注解模板） +在 `description` 中可以使用 `$labels` 和 `$value` 等模板变量： +```yaml +annotations: + description: "主机 {{ $labels.instance }} CPU 使用率超过 85%（当前值：{{ $value }}%）" +``` + +## Home Server Alert Rules（alerts.yml 完整示例） +```yaml +groups: +- name: system-alerts + rules: + + - alert: HostHighCPU + expr: avg(rate(node_cpu_seconds_total{mode="user"}[2m])) * 100 > 85 + for: 2m + labels: + severity: warning + annotations: + summary: "高 CPU 使用率" + description: "主机 CPU 使用率超过 85%（持续 2 分钟）" + + - alert: HostLowDisk + expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) < 0.10 + for: 5m + labels: + severity: critical + annotations: + summary: "磁盘空间不足" + description: "磁盘剩余空间低于 10%" + + - alert: HostLowMemory + expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.15 + for: 5m + labels: + severity: warning + annotations: + summary: "内存使用率高" + description: "可用内存低于 15%" + + - alert: HTTPProbeFailed + expr: probe_success == 0 + for: 2m + labels: + severity: critical + annotations: + summary: "站点不可达" + description: "HTTP 探测失败：{{ $labels.instance }}" + + - alert: TLSCertExpiring + expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 14 + for: 1h + labels: + severity: warning + annotations: + summary: "TLS 证书即将到期" + description: "证书 {{ $labels.instance }} 剩余不到 14 天" +``` + +## Alert Lifecycle +``` +Inactive（正常）→ Pending（等待确认，for 计时中）→ Firing（触发，发送给 Alertmanager） +``` + +## Prometheus Configuration +```yaml +# prometheus.yml +rule_files: + - "/etc/prometheus/alerts.yml" + +alerting: + alertmanagers: + - static_configs: + - targets: ['alertmanager:9093'] + +global: + evaluation_interval: 30s # 告警规则评估间隔 +``` + +## Related Entities +- [[Prometheus]] — 告警引擎宿主 +- [[Alertmanager]] — 告警接收和分发 + +## Related Concepts +- [[PromQL]] — 告警条件的查询语言 +- [[Alertmanager]] — 告警分发机制 +- [[System Monitoring]] — 上游应用领域 diff --git a/wiki/concepts/Public-Cloud.md b/wiki/concepts/Public-Cloud.md new file mode 100644 index 00000000..c3064806 --- /dev/null +++ b/wiki/concepts/Public-Cloud.md @@ -0,0 +1,129 @@ +# Public Cloud + +> **Public Cloud** — 公有云是通过互联网交付、由第三方提供商同时为多个组织（多租户）提供计算资源（服务器、存储、应用）的云服务模式。用户按需付费，无需前期硬件投入。 + +## Definition + +公有云（Public Cloud）由第三方云服务提供商（如 AWS、Azure、GCP）通过公共互联网向所有用户提供共享的云基础设施和服务。所有资源在提供商的数据中心中运行，多个租户共享同一物理基础设施，但通过虚拟化技术实现逻辑隔离。 + +## Key Characteristics + +| 特征 | 描述 | +|------|------| +| **多租户共享** | 多个组织共享底层物理资源，通过虚拟化隔离 | +| **按需付费** | Pay-as-you-go 定价，根据实际消耗计费 | +| **弹性扩展** | 快速扩展或收缩资源，无需硬件采购 | +| **即服务交付** | IaaS / PaaS / SaaS 三层服务模型 | +| **供应商管理** | 提供商负责硬件维护、安全更新、容量规划 | + +## Deployment Model + +``` +用户终端 (PC/平板/手机) + ↓ + 互联网 + ↓ +┌─────────────────────────────────┐ +│ 云服务提供商数据中心 │ +│ ┌─────┐ ┌─────┐ ┌─────┐ │ +│ │租户A│ │租户B│ │租户C│ ... │ ← 多租户共享 +│ └─────┘ └─────┘ └─────┘ │ +│ │ +│ 虚拟化层（VM/容器） │ +│ 物理服务器集群 │ +└─────────────────────────────────┘ +``` + +## Advantages + +### 1. 无前期资本投入 (CapEx → OpEx) +- 无需采购和维护IT基础设施 +- 将资本支出转换为运营支出 +- 降低初始投资风险 + +### 2. 技术敏捷性 +- 高弹性和灵活性，应对不可预测的工作负载 +- 快速部署新服务和应用 +- 访问最新技术和版本 + +### 3. 全球可访问性 +- 任何有互联网连接的地方均可访问 +- 支持远程办公和分布式团队协作 +- 跨地域快速扩张 + +### 4. 专业管理与运维 +- 提供商负责硬件维护和更新 +- 始终运行在最新、正确配置的硬件上 +- 减少内部IT团队压力 + +### 5. 成本效率 +- 仅支付实际使用的资源 +- 灵活定价选项适应不同SLA需求 +- 支持精益增长战略 + +### 6. 快速灾难恢复 +- 数据和应用定期备份并存放在多个地理位置 +- 最小化数据丢失风险 +- 确保业务连续性 + +## Drawbacks + +### 1. 缺乏成本控制 +- 大规模使用时总拥有成本 (TCO) 可能指数增长 +- 对中大型企业尤为明显 +- 需要 FinOps 实践控制成本 + +### 2. 安全性较低 +- 多租户共享环境存在潜在安全风险 +- 不适合敏感和关键任务的IT工作负载 +- 合规性控制可能不足 + +### 3. 技术控制有限 +- 对基础设施的可见性和控制度低 +- 可能无法满足特定合规需求 +- 定制化能力受限 + +### 4. 供应商依赖 +- 更换供应商的数据和服务迁移复杂且成本高昂 +- 可能被锁定在单一提供商 +- 议价能力受限 + +## When to Use Public Cloud + +| 场景 | 说明 | +|------|------| +| **可预测的计算需求** | 通信服务、固定的业务运营应用 | +| **IT和业务运营必需的应用** | 核心业务系统 | +| **应对峰值负载** | 季节性流量波动、促销活动 | +| **软件开发与测试** | 快速创建和销毁测试环境 | +| **短期的特定项目** | 避免长期硬件投资 | + +## TCO Comparison + +| 成本维度 | 公有云 | 本地私有 | +|----------|--------|---------| +| 前期资本投入 | 低 | 高 | +| 扩展成本 | 边际成本低 | 需要新硬件采购 | +| 维护成本 | 提供商承担 | 内部承担 | +| 人员成本 | 较低 | 需要专职团队 | +| 峰值容量规划 | 自动弹性 | 需要过度配置 | + +## Related Concepts + +- [[Private Cloud]] — 私有云部署模式对比 +- [[Hybrid Cloud]] — 混合云结合公私优势 +- [[Multi-Cloud Strategy]] — 多云避免锁定 +- [[FinOps]] — 云成本管理 +- [[Cloud Security]] — 云安全 +- [[CapEx-vs-OpEx]] — 资本支出 vs 运营支出 +- [[Cloud Elasticity]] — 云弹性 +- [[SLA]] — 服务级别协议 +- [[Cloud Migration]] — 云迁移 +- [[Vendor-Lock-In]] — 供应商锁定风险 + +## See Also + +- [[Cloud Computing]] — 云计算基础（实体页面） +- [[Cloud-Adoption-Strategy]] — 云采用策略 +- [[Cloud-Maturity-Model]] — 云成熟度模型 +- [[Shared-Responsibility-Model]] — 共享责任模型 diff --git a/wiki/concepts/RPO.md b/wiki/concepts/RPO.md new file mode 100644 index 00000000..3e2e049f --- /dev/null +++ b/wiki/concepts/RPO.md @@ -0,0 +1,91 @@ +--- +title: "RPO (Recovery Point Objective)" +tags: [devops, disaster-recovery, sre, reliability, data-protection] +created: 2026-04-25 +--- + +# RPO (Recovery Point Objective) + +**RPO (Recovery Point Objective)** 是指系统发生故障时，能够接受的最大数据丢失量。它衡量的是数据保护程度——从故障时刻向前追溯，可接受丢失多长时间的数据。 + +## Definition + +> "RPO is about protecting data. It's measured backwards from the moment of failure." — LaunchDarkly + +RPO 是灾备规划的核心指标之一，与 [[RTO]]（恢复时间目标）共同构成灾备目标体系。 + +## Key Characteristics + +| 维度 | 说明 | +|------|------| +| **衡量对象** | 数据丢失量（Data Loss Amount） | +| **测量方向** | 从故障时刻向后（Backwards）追溯 | +| **关注点** | 数据完整性（How Much Data Can Be Lost） | + +## Example + +如果数据库在下午 3 点崩溃，而最后一次备份是下午 2 点，则： +- **RPO = 1 小时**：这意味着过去 1 小时内的数据可能丢失 +- 2:00 到 3:00 之间发生的所有事务都面临丢失风险 + +## RTO vs. RPO + +RTO 和 RPO 衡量的是不同维度，必须**同时优化**： + +| 场景 | RTO 目标 | RPO 目标 | 说明 | +|------|----------|----------|------| +| 电商结账 | 2 分钟 | 0 秒 | 必须快速恢复，且不能丢失任何交易 | +| 用户分析面板 | 30 分钟 | 1 小时 | 停机可接受，小时级数据丢失也可接受 | +| 内部 CRM | 4 小时 | 15 分钟 | 停机可绕过，但近期客户更新很重要 | +| 博客/营销站 | 2 小时 | 24 小时 | 访问者可以等，丢失一天评论可接受 | + +**关键**：不能只优化其中一个指标。 +- 30 秒一次备份（RPO 优秀）但恢复需要 6 小时（RTO 极差）= 无效 +- 5 分钟拉起新服务器（RTO 优秀）但丢失 4 小时客户数据（RPO 极差）= 无效 + +## [[Feature Flag]] 对 RPO 的保护 + +传统回滚（Full Deployment Rollback）在回滚过程中可能丢失新事务数据。而 [[Feature Flag]] 回滚**不丢失数据**： + +- Feature Flag 切换只改变代码执行路径，不触碰数据层 +- [[Kill Switch]] 关闭故障功能时，用户正在提交的数据不受影响 +- RPO 在整个 Feature Flag 操作期间始终保持近零 + +## Tiered RPO Targets + +| Tier | 场景 | RPO 目标 | 说明 | +|------|------|----------|------| +| Critical | 支付处理、交易系统 | < 1 分钟 | 不能丢失任何金钱相关数据 | +| Important | CRM、客户支持 | < 15 分钟 | 近期客户更新不可丢失 | +| Nice-to-have | 文档站、内部工具 | < 1 小时 | 数据可重建或接受丢失 | + +## 实现手段 + +| 方法 | RPO 效果 | 说明 | +|------|----------|------| +| 无备份 | ∞ | 完全不可接受 | +| 每日备份 | 24 小时 | 成本低，RPO 差 | +| 每小时备份 | 1 小时 | 中等成本和效果 | +| CDB（持续数据保护） | 秒级 | 持续复制，RPO 接近零 | +| 同步复制（Active-Active） | 0 | 零数据丢失，成本极高 | + +## RPO 与 RTO 必须协同 + +最佳实践是同时设定 RTO 和 RPO，并将 [[Feature Flag]] / [[Kill Switch]] 纳入灾备工具链： + +- RTO 短 → 系统快速恢复 +- RPO 小 → 数据损失少 +- Feature Flag → 两者兼得的性价比方案 + +## Related Concepts + +- [[RTO]] — Recovery Time Objective，停机时间指标 +- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标 +- [[Feature Flag]] — 保护 RPO 的配置级热修复机制 +- [[Kill Switch]] — 关闭故障功能，保护数据不被继续破坏 +- [[High Availability]] — 高可用性，降低 RPO 的基础设施 +- [[Data-Governance]] — 数据治理，包含 RPO 策略 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/RTO.md b/wiki/concepts/RTO.md new file mode 100644 index 00000000..8eba031f --- /dev/null +++ b/wiki/concepts/RTO.md @@ -0,0 +1,81 @@ +--- +title: "RTO (Recovery Time Objective)" +tags: [devops, disaster-recovery, sre, reliability] +created: 2026-04-25 +--- + +# RTO (Recovery Time Objective) + +**RTO (Recovery Time Objective)** 是指系统发生故障后，业务能够容忍的最大停机时间。它衡量的是恢复速度——从系统下线到用户可以重新使用系统的时间窗口。 + +## Definition + +> "RTO is about getting back online. It's the clock that starts ticking the moment your system goes down." — LaunchDarkly + +RTO 是灾备规划的核心指标之一，与 [[RPO]]（恢复点目标）共同构成灾备目标体系。 + +## Key Characteristics + +| 维度 | 说明 | +|------|------| +| **衡量对象** | 停机时间（Downtime Duration） | +| **起点** | 系统故障发生的时刻 | +| **终点** | 用户可以重新使用系统 | +| **关注点** | 速度（How Fast） | + +## RTO vs. RPO + +RTO 和 RPO 经常被混淆，但衡量的是完全不同的维度： + +- **RTO** — 关注速度：系统多久能恢复？ +- **RPO** — 关注数据：能承受多少数据丢失？ + +两者可以独立设定：快速恢复不代表数据不丢失，反之亦然。 + +## Tiered RTO Targets + +| Tier | 场景 | RTO 目标 | 说明 | +|------|------|----------|------| +| Critical | 支付处理、用户认证 | < 5 分钟 | 业务立即停止，需要 3AM 告警 | +| Important | 管理后台、报表 | < 1 小时 | 业务减速但不停止 | +| Nice-to-have | 内部工具、文档站 | < 4 小时 | 仅造成不便 | + +## RTO in Modern CD Context + +传统灾备规划假设 RTO 针对的是硬件故障（服务器宕机、数据中心断电），但现代持续交付中最大的风险来自**代码变更**： + +- 支付流程 Bug 导致结账失败 +- 数据库迁移锁死应用 +- AI 模型更新产生异常响应 +- 新功能在负载下性能骤降 + +**[[Feature Flag]]** 将 RTO 从小时级降至秒级：只需切换配置，无需重新部署代码。 + +## 实现手段 + +| 方法 | RTO 效果 | 说明 | +|------|----------|------| +| 传统灾备（从备份恢复） | 小时级 | 需要重建基础设施 | +| [[Kill Switch]]（Feature Flag） | 秒级 | 配置变更，无需部署 | +| 容器化 + 自动扩缩容 | 分钟级 | 需要容器编排平台 | +| Active-Active 多活 | 近零 | 成本极高 | + +## RTO 与成本的关系 + +- 近零 RTO 需要"冗余一切"（服务器、数据库、网络、跨数据中心） +- 大多数团队无法承担如此高的成本 +- **建议**：按应用分层级设定 RTO，而非对所有系统一刀切 + +> "What does an hour of downtime actually cost your business? If it's $10K, don't spend $100K/year on infrastructure to prevent it." + +## Related Concepts + +- [[RPO]] — Recovery Point Objective，数据丢失量指标 +- [[Disaster Recovery]] — 灾备策略，RTO/RPO 是其核心目标 +- [[Kill Switch]] — 通过 Feature Flag 实现秒级 RTO +- [[High Availability]] — 高可用性，降低 RTO 的基础设施 +- [[Feature Flag]] — 实现配置级热修复的核心机制 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/concepts/Release-Management.md b/wiki/concepts/Release-Management.md new file mode 100644 index 00000000..75b1616b --- /dev/null +++ b/wiki/concepts/Release-Management.md @@ -0,0 +1,68 @@ +--- +title: "Release Management" +type: concept +tags: [devops, deployment, itsm] +date: 2025-03-01 +--- + +## Definition + +发布管理（Release Management）是[[ITSM]]的核心流程之一，负责**规划和协调软件从开发到生产的整个发布过程**，确保高质量、低风险的版本交付。 + +## Release Management Process + +``` +┌──────────────┐ ┌──────────────┐ ┌──────────────┐ +│ Release │ → │ Build & │ → │ Testing & │ +│ Planning │ │ Package │ │ Validation │ +└──────────────┘ └──────────────┘ └──────────────┘ + ↓ +┌──────────────┐ ┌──────────────┐ ┌──────────────┘ +│ Monitoring │ ← │ Deployment │ ← │ Staged │ +│ & Rollback │ │ to Prod │ │ Release │ +└──────────────┘ └──────────────┘ └──────────────┘ +``` + +## Modern Release Management (ITSM 2.0) + +在[[ITSM 2.0]]中，发布管理深度集成DevOps： + +### DevOps-Integrated ITSM + +| 实践 | 描述 | +|------|------| +| [[Canary-Release]] | 渐进式流量转移 | +| [[Blue-Green-Deployment]] | 零停机双环境部署 | +| Feature Flags | 特性开关控制 | +| Automated Rollback | 自动回滚 | + +### Progressive Delivery Patterns + +``` +Traditional: v1.0 → v1.1 → v1.2 (Big Bang) +Canary: v1.0 → [v1.1 → 5%] → [v1.1 → 20%] → v1.1 +Blue-Green: Blue[v1.0] ←→ Green[v1.1] (instant switch) +Feature Flags: v1.0 + [Flag:NewFeature=ON] (dynamic control) +``` + +## Key Metrics + +| 指标 | 描述 | +|------|------| +| Deployment Frequency | 部署频率 | +| Lead Time for Changes | 变更前置时间 | +| Time to Market | 上市时间 | +| Release Success Rate | 发布成功率 | + +## Related Concepts + +- [[ITSM]] — 父框架 +- [[Canary-Release]] — 金丝雀发布 +- [[Blue-Green-Deployment]] — 蓝绿部署 +- [[CI/CD-Pipeline]] — CI/CD流水线 +- [[Feature-Flag]] — 特性开关 +- [[Deployment-Automation]] — 部署自动化 + +## Sources + +- [[understanding-complete-itsm]] — DevOps-integrated Release Management diff --git a/wiki/concepts/Rightsizing.md b/wiki/concepts/Rightsizing.md new file mode 100644 index 00000000..99d16e9a --- /dev/null +++ b/wiki/concepts/Rightsizing.md @@ -0,0 +1,79 @@ +--- +title: "Rightsizing" +tags: + - devops + - finops + - cost-optimization + - cloud +created: 2026-04-25 +--- + +# Rightsizing + +## Definition + +Rightsizing 是通过持续分析资源使用趋势，**动态调整云资源配置**以消除过度配置（over-provisioning）和不足配置（under-provisioning）的方法。Agentic AI 持续监控 CPU/内存/存储使用率，自动建议或执行资源配置变更。 + +## 与 [[FinOps]] 的关系 + +Rightsizing 是 [[FinOps]] 成本优化的核心实践之一： + +``` +FinOps Framework: +├── Understand (云成本归因) +├── Optimize (Rightsizing ←) # ← 本页 +└── Operate (持续成本管理) +``` + +## 传统 vs AI-Driven Rightsizing + +| 维度 | 人工 Rightsizing | AI-Driven Rightsizing | +|------|-----------------|----------------------| +| 分析频率 | 季度/年度 | 实时/每日 | +| 数据范围 | 有限指标 | 全量指标 + 历史趋势 | +| 响应速度 | 数周 | 数小时 | +| 准确性 | 基于经验估算 | 基于实际使用数据 | + +## Agentic AI Rightsizing 能力 + +```python +Rightsizing_Dimensions = { + "Compute": "EKS/RDS/VMs 自动扩缩容", + "Storage": "S3 生命周期策略 + 存储类型优化", + "Network": "NAT Gateway 峰值优化", + "Database": "RDS 实例类型调整 + 连接池优化" +} +``` + +## 示例 + +> An AI agent analyzes 30 days of AWS EKS cluster metrics: +> - CPU utilization: 15% average, peaks at 40% during business hours +> - Memory utilization: 22% average, 60% during batch jobs +> - **Suggests**: +> - Downsize from m5.xlarge to m5.large (saves 40% compute cost) +> - Implement auto-scaling: 2-8 instances based on CPU > 60% +> - **Result**: 40% cost reduction, zero performance impact + +## 与 [[Multi-Cloud Cost Optimization]] 的关系 + +Rightsizing 是 [[Multi-Cloud Cost Optimization]] 的基础能力之一： + +``` +Multi-Cloud Cost Optimization: +├── Rightsizing ← (单云资源优化) +├── Spot/Reserved Instance Optimization +├── Multi-Cloud Resource Consolidation +└── Pricing Model Selection +``` + +## Related Concepts + +- [[FinOps]] — Rightsizing 是 FinOps 框架的组成部分 +- [[Multi-Cloud Cost Optimization]] — Rightsizing 的扩展场景 +- [[Cloud Cost Optimization]] — Rightsizing 的广义概念 +- [[Scalability]] — Rightsizing 的技术基础 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] diff --git a/wiki/concepts/Root-Cause-Analysis.md b/wiki/concepts/Root-Cause-Analysis.md new file mode 100644 index 00000000..2565c2d8 --- /dev/null +++ b/wiki/concepts/Root-Cause-Analysis.md @@ -0,0 +1,71 @@ +--- +title: "Root Cause Analysis" +tags: + - devops + - troubleshooting + - ai + - observability +created: 2026-04-25 +--- + +# Root Cause Analysis (RCA) + +## Definition + +Root Cause Analysis (RCA) 是通过系统化方法追溯问题根本原因的过程，而非仅处理表面症状。Agentic AI 通过跨层日志关联（计算、网络、应用），比人工更快定位问题根因，显著加速事故解决。 + +## Traditional vs AI-Driven RCA + +| 维度 | 传统 RCA | AI-Driven RCA | +|------|---------|--------------| +| 分析速度 | 数小时至数天 | 分钟级 | +| 数据范围 | 有限日志样本 | 全量日志 + 跨源关联 | +| 关联能力 | 依赖人工经验 | 自动跨层相关性分析 | +| 准确性 | 受经验影响 | 基于模式匹配的一致性 | +| 知识积累 | 个人经验为主 | 可学习的组织知识 | + +## Agentic AI RCA 工作流 + +``` +1. 异常检测 → CloudWatch/Stackdriver/Azure Monitor 告警触发 +2. 数据收集 → 自动聚合相关时间段的所有日志 +3. 跨层关联 → 关联 compute/networking/application 日志 +4. 模式匹配 → 匹配历史故障模式 +5. 根因输出 → 输出结构化根因报告 + 修复建议 +``` + +## AI-Driven RCA 示例 + +> AI agent monitoring AWS EKS detects a spike in error rates. It correlates: +> - Kubernetes pod logs (application layer) +> - VPC flow logs (network layer) +> - RDS metrics (database layer) +> - → Identifies: External API timeout causing connection pool exhaustion +> - → Suggests: Implement retry strategy with exponential backoff + +## 与 [[AIOps]] 的关系 + +RCA 是 [[AIOps]] 能力矩阵的核心组件： + +```python +AIOps_Capabilities = { + "Anomaly Detection": "检测异常模式", + "Root Cause Analysis": "自动诊断 ←", # ← 本页 + "Predictive Maintenance": "预测性维护", + "Smart Alerting": "减少告警疲劳", + "Automated Remediation": "自动修复", + "Capacity Optimization": "容量优化" +} +``` + +## Related Concepts + +- [[Self-Healing Systems]] — RCA 发现根因后触发自动修复 +- [[AIOps]] — RCA 是 AIOps 的核心能力 +- [[MTTR]] — RCA 速度直接影响 MTTR +- [[Observability]] — RCA 依赖可观测性数据 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] +- [[what-i-know-about-cloud-service-delivery-1]] diff --git a/wiki/concepts/SAST.md b/wiki/concepts/SAST.md new file mode 100644 index 00000000..82fd560b --- /dev/null +++ b/wiki/concepts/SAST.md @@ -0,0 +1,52 @@ +# 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]] diff --git a/wiki/concepts/SCA.md b/wiki/concepts/SCA.md new file mode 100644 index 00000000..ae95da85 --- /dev/null +++ b/wiki/concepts/SCA.md @@ -0,0 +1,71 @@ +# SCA (Software Composition Analysis) + +## Definition +SCA tools focus on the various software components of an application, including libraries and frameworks, to find known security flaws. They help reveal vulnerabilities that may occur when using third-party components. + +## Aliases +- Software Composition Analysis +- Dependency Analysis +- Open Source Security + +## Characteristics +- **依赖分析**：扫描应用的所有第三方组件 +- **已知漏洞匹配**：与 CVE/NVD 数据库匹配 +- **许可证合规**：检查开源许可证合规性 +- **供应链安全**：关注依赖链中的安全问题 + +## What SCA Detects +- **已知漏洞**（Known Vulnerabilities） + - CVEs in dependencies + - Security advisories +- **过时组件**（Outdated Dependencies） + - Known vulnerabilities in old versions + - Missing security patches +- **许可证问题**（License Issues） + - GPL/AGPL restrictions + - Incompatible licenses +- **高风险依赖**（Risky Dependencies） + - Unmaintained packages + - Malicious packages + +## Common CVE Databases +- National Vulnerability Database (NVD) +- GitHub Advisory Database +- Snyk Vulnerability Database +- OSV (Open Source Vulnerabilities) + +## Tools +- [[Snyk]] — 专注开源安全的 SCA 工具 +- OWASP Dependency-Check +- WhiteSource (Mend) +- FOSSA +- Dependabot (GitHub) + +## Integration Points +- **CI/CD Pipeline**：在构建时自动扫描依赖 +- **IDE**：开发者本地实时检查 +- **Registry Scanning**：容器镜像仓库扫描 +- **SBOM Generation**：软件物料清单生成 + +## SBOM (Software Bill of Materials) +SCA 工具常用于生成 SBOM： +- 完整的依赖列表 +- 版本信息 +- 许可证信息 +- 漏洞状态 + +## Limitations +- 仅检测已知漏洞（零日漏洞无法检测） +- 需要保持漏洞数据库更新 +- 可能产生误报 + +## Related Concepts +- [[DevSecOps]] — SCA 是其重要组件 +- [[SAST]] — 静态应用安全测试 +- [[DAST]] — 动态应用安全测试 +- [[Supply-Chain-Security]] — 供应链安全 +- [[SBOM]] — 软件物料清单 +- [[Zero-Day-Vulnerability]] — 零日漏洞 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Security-and-Compliance.md b/wiki/concepts/Security-and-Compliance.md new file mode 100644 index 00000000..d1d19869 --- /dev/null +++ b/wiki/concepts/Security-and-Compliance.md @@ -0,0 +1,72 @@ +--- +title: "Security and Compliance" +type: concept +tags: [security, compliance, itsm] +date: 2025-03-01 +--- + +## Definition + +安全与合规管理（Security and Compliance）是[[ITSM]]的核心流程之一，通过[[Zero-Trust-Architecture]]、自动化风险评估和[[Policy-as-Code]]等手段，确保IT服务满足安全和监管要求。 + +## Security & Compliance Framework + +``` +┌─────────────────────────────────────────────────────────────┐ +│ Security & Compliance Management │ +├─────────────────────────────────────────────────────────────┤ +│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ +│ │ Zero Trust │ │ Risk Scoring │ │ Compliance │ │ +│ │ Architecture │ │ (Automated) │ │ Automation │ │ +│ └───────────────┘ └───────────────┘ └───────────────┘ │ +│ ↓ ↓ ↓ │ +│ ┌─────────────────────────────────────────────────────┐ │ +│ │ AI-based Threat Intelligence │ │ +│ │ Behavior Analysis │ Anomaly Detection │ Response │ │ +│ └─────────────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────┘ +``` + +## Modern Security & Compliance (ITSM 2.0) + +在[[ITSM 2.0]]中，安全与合规由AI和自动化驱动： + +### Key Components + +| 组件 | 描述 | 技术 | +|------|------|------| +| [[Zero-Trust-Architecture]] | 永不信任，始终验证 | IAM, MFA, 微分段 | +| Automated Risk Scoring | 自动化风险评估 | ML Models | +| AI Threat Intelligence | AI威胁情报 | Behavioral Analysis | +| [[Policy-as-Code]] | 合规自动化 | OPA, Sentinel | +| Compliance Automation | 审计自动化 | Continuous Monitoring | + +### Automated Compliance Pipeline + +``` +Code → Policy Check → Security Scan → Compliance Report → Audit + ↓ ↓ ↓ ↓ ↓ + Git hooks OPA SAST/DAST Auto-generate Evidence + PaC Security Report Pack +``` + +## Key Frameworks & Standards + +| 框架 | 描述 | +|------|------| +| [[ISO-27001]] | 信息安全管理体系 | +| [[GDPR]] | 欧盟数据保护 | +| [[HIPAA]] | 医疗健康数据保护 | +| SOC 2 | 服务组织控制 | + +## Related Concepts + +- [[ITSM]] — 父框架 +- [[Zero-Trust-Architecture]] — 零信任架构 +- [[Policy-as-Code]] — 策略即代码 +- [[Cloud-Security]] — 云安全 +- [[Data-Governance]] — 数据治理 + +## Sources + +- [[understanding-complete-itsm]] — Security & Compliance in Modern ITSM diff --git a/wiki/concepts/Self-Healing-Systems.md b/wiki/concepts/Self-Healing-Systems.md new file mode 100644 index 00000000..85697d9a --- /dev/null +++ b/wiki/concepts/Self-Healing-Systems.md @@ -0,0 +1,73 @@ +--- +title: "Self-Healing Systems" +type: concept +tags: [aiops, automation, reliability, agentic-ai] +date: 2026-04-14 +aliases: + - Self-Healing +--- + +## Definition + +自愈系统（Self-Healing Systems）是能够**自动检测异常、诊断问题并执行修复操作**的智能系统，无需人工干预即可恢复正常运行状态。这是[[Agentic AI]]和[[AIOps]]的核心能力之一。 + +## How It Works + +``` +┌──────────────┐ ┌──────────────┐ ┌──────────────┐ +│ Anomaly │ → │ Diagnosis │ → │ Repair │ +│ Detection │ │ & Root │ │ Action │ +│ │ │ Cause │ │ │ +└──────────────┘ └──────────────┘ └──────────────┘ + ↓ ↓ ↓ + AI/ML Model Decision Tree Automated Script + + Metrics + Knowledge Base + Runbooks + ↓ + ┌──────────────┐ ┌──────────────┐ + │ Monitoring │ ← │ Verification │ + │ Close │ │ & Report │ + └──────────────┘ └──────────────┘ +``` + +## Self-Healing Actions + +| 动作类型 | 描述 | 示例 | +|----------|------|------| +| Restart | 服务重启 | Pod重启、进程重启 | +| Scale | 扩缩容 | 增加Pod数量、扩容资源 | +| Evict | 驱逐问题节点 | Kubernetes节点驱逐 | +| Cleanup | 资源清理 | 清理磁盘、释放连接池 | +| Rollback | 版本回滚 | 回到上一个稳定版本 | +| Reroute | 流量切换 | DNS切换、负载均衡调整 | + +## In ITSM Context + +在[[ITSM 2.0]]的[[Incident-Management]]中，自愈是关键能力： + +### AIOps-Powered Self-Healing +- Real-time observability drives rapid detection +- ML models predict failure before it happens +- Automated runbooks execute recovery +- Continuous learning improves future responses + +### Kubernetes Self-Healing +[[Kubernetes]]提供原生自愈机制： +- **Liveness Probes** — 自动重启不健康容器 +- **Readiness Probes** — 停止流量到不健康Pod +- **Node Failure Detection** — 自动重新调度Pod + +## Related Concepts + +- [[Agentic AI]] — 自愈的驱动者 +- [[AIOps]] — 自愈的分析引擎 +- [[Incident-Management]] — 自愈的应用场景 +- [[Kubernetes]] — 自愈的主要载体 +- [[Root-Cause-Analysis]] — 自愈前的诊断过程 +- [[MTTR]] — 自愈改善的关键指标 + +## Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] — Agentic AI自愈场景 +- [[understanding-complete-itsm]] — ITSM 2.0自愈能力 +- [[Agentic-AI]] — 实体页面中的自愈描述 +- [[Kubernetes]] — Kubernetes自愈机制 diff --git a/wiki/concepts/Serverless-Computing.md b/wiki/concepts/Serverless-Computing.md new file mode 100644 index 00000000..8263daea --- /dev/null +++ b/wiki/concepts/Serverless-Computing.md @@ -0,0 +1,76 @@ +--- +title: "Serverless Computing" +type: concept +tags: [Cloud, Serverless, Cloud Native, Edge Computing] +date: 2026-04-26 +--- + +# Serverless Computing (无服务器计算) + +## Definition +**Serverless Computing** is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. Developers can build and deploy applications without worrying about infrastructure management. + +## Key Characteristics +- **No server management**: Cloud provider handles infrastructure +- **Automatic scaling**: Resources scale based on demand +- **Pay-per-use**: Pay only for execution time +- **Event-driven**: Functions respond to events/triggers + +## Key Platforms + +| Provider | Service | +|----------|---------| +| AWS | Lambda | +| Azure | Azure Functions | +| GCP | Cloud Functions | + +## Benefits + +### 1. Cost Efficiency +- Eliminates unnecessary resource consumption +- No idle capacity costs +- Pay only for actual execution time + +### 2. Scalability +- Automatic scaling from zero to thousands of instances +- Handles traffic spikes without provisioning +- Global distribution ready + +### 3. Developer Productivity +- Focus on business logic, not infrastructure +- Faster deployment cycles +- Reduced operational overhead + +## Use Cases + +### Event-Driven Automation +- Real-time file processing +- Automated backups +- Scheduled tasks and cron jobs + +### API Backends +- Microservices architecture +- Real-time data processing +- IoT data ingestion + +### AI/ML Inference +- On-demand model inference +- Image and video processing +- Natural language processing + +## Relationship to Green Computing +- Serverless computing contributes to [[Green Computing]] by: + - Eliminating idle resource consumption + - Optimizing energy efficiency through shared infrastructure + - Reducing data center carbon footprint + +## Related Concepts +- [[Cloud-Native]] +- [[Green Computing]] +- [[Event-Driven-Architecture]] +- [[Edge-Computing]] + +## Related Entities +- [[AWS Lambda]] +- [[Azure Functions]] +- [[Google Cloud Functions]] diff --git a/wiki/concepts/Shared-Responsibility-Model.md b/wiki/concepts/Shared-Responsibility-Model.md new file mode 100644 index 00000000..1dd74205 --- /dev/null +++ b/wiki/concepts/Shared-Responsibility-Model.md @@ -0,0 +1,174 @@ +# Shared Responsibility Model + +> **Shared Responsibility Model** — 共享责任模型是云安全的基本原则，定义了云服务提供商和客户组织之间在安全、运维、合规等方面的责任划分。无论使用公有云、私有云还是混合云，安全问题始终由双方共同承担。 + +## Definition + +共享责任模型（Shared Responsibility Model）阐明了在云环境中，云服务提供商和客户组织各自承担的安全和管理职责。客户组织购买云服务并不意味着将所有责任转移给提供商——数据安全、访问控制、灾难恢复规划等关键领域仍然是客户的核心职责。 + +> "No matter which cloud environment you work in, your problems don't go away. Though you're purchasing services from third-party vendors, you still have to do your due diligence to reduce risk." + +## Responsibility Matrix by Service Model + +### IaaS (Infrastructure as a Service) + +| 责任领域 | 提供商 | 客户 | +|----------|--------|------| +| 物理数据中心 | ✅ | — | +| 服务器/存储/网络硬件 | ✅ | — | +| 虚拟化层 | ✅ | — | +| 操作系统 | — | ✅ | +| 中间件/运行时 | — | ✅ | +| 应用程序 | — | ✅ | +| 数据 | — | ✅ | +| 身份和访问管理 | — | ✅ | +| 网络安全（配置） | — | ✅ | + +### PaaS (Platform as a Service) + +| 责任领域 | 提供商 | 客户 | +|----------|--------|------| +| 物理基础设施 | ✅ | — | +| 运行时/中间件 | ✅ | — | +| 操作系统补丁 | ✅ | — | +| 开发框架 | ✅ | — | +| 应用程序 | — | ✅ | +| 数据 | — | ✅ | +| 身份和访问管理 | — | ✅ | +| 网络安全配置 | — | ✅ | + +### SaaS (Software as a Service) + +| 责任领域 | 提供商 | 客户 | +|----------|--------|------| +| 所有底层基础设施 | ✅ | — | +| 应用程序 | ✅ | — | +| 数据 | — | ✅ | +| 身份和访问管理 | — | ✅ | +| 用户设备安全 | — | ✅ | +| 数据备份 | — | ✅ | + +## Always the Customer's Responsibility + +无论选择哪种云服务模型，以下领域**始终由客户组织负责**： + +### 1. Identity and Access Management (身份和访问管理) +- 定义谁可以访问什么资源（最小权限原则） +- 配置多因素认证（MFA） +- 定期审计访问权限 +- 管理服务账户和API密钥 + +### 2. Data Security and Encryption (数据安全和加密) +- 确定哪些数据需要加密 +- 管理加密密钥（BYOK/KMS） +- 配置传输加密（TLS/SSL） +- 数据分类和标签策略 + +### 3. Disaster Recovery Planning (灾难恢复规划) +- 制定业务连续性计划 +- 定义 RTO（恢复时间目标）和 RPO（恢复点目标） +- 定期测试灾难恢复流程 +- 维护离线/异地备份 + +### 4. Compliance and Governance (合规和治理) +- 确保符合行业法规（HIPAA、PCI-DSS、GDPR等） +- 定期合规审计 +- 数据主权和驻留要求 +- 审计日志收集和保留 + +### 5. User Devices and Endpoints (用户设备和端点) +- 端点安全（防病毒、EDR） +- 设备合规策略 +- 远程工作安全标准 + +## Always the Provider's Responsibility + +以下领域由云服务提供商负责： + +### 1. Physical Security (物理安全) +- 数据中心物理访问控制 +- 环境控制（温度、湿度） +- 物理冗余和容错 + +### 2. Infrastructure Availability (基础设施可用性) +- 底层网络可用性 +- 硬件故障恢复 +- 数据中心冗余 + +### 3. Hypervisor/Container Security (虚拟化安全) +- 虚拟机/容器隔离 +- 虚拟化层漏洞修复 + +## Hybrid/Multi-Cloud Responsibility Boundaries + +在混合云和多云环境中，责任划分更为复杂： + +``` +┌──────────────────────────────────────────────────────┐ +│ 客户组织责任 │ +│ ┌──────────────────────────────────────────────┐ │ +│ │ 数据 │ IAM │ DR │ 合规 │ 应用程序 │ 端点 │ │ +│ └──────────────────────────────────────────────┘ │ +└──────────────────────────────────────────────────────┘ + ↑ ↑ ↑ +┌──────────────┐ ┌──────────────┐ ┌──────────────┐ +│ 公有云 │ │ 私有云 │ │ 本地环境 │ +│ (AWS/Azure/ │ │ (自托管/托管) │ │ (数据中心) │ +│ GCP) │ │ │ │ │ +│ 提供商负责 │ │ 提供商/自管 │ │ 全部自管 │ +│ 物理+虚拟化 │ │ │ │ │ +└──────────────┘ └──────────────┘ └──────────────┘ +``` + +## Key Risks Without Shared Responsibility Awareness + +| 风险场景 | 后果 | +|----------|------| +| 假设提供商"全包"安全 | 数据泄露、访问失控 | +| 未配置MFA | 账户被入侵 | +| 未加密敏感数据 | 合规违规、数据泄露 | +| 无灾难恢复计划 | 业务中断、数据永久丢失 | +| 不了解合规要求 | 巨额罚款、品牌损害 | + +## Best Practices + +### 1. Know Your Responsibilities +- 阅读云提供商的SLA和安全文档 +- 理解服务模型对应的责任边界 +- 与提供商沟通不明确的领域 + +### 2. Implement Defense in Depth +- 不依赖单一安全层 +- 多层次安全控制（网络、应用、数据、身份） +- 假设任何层次都可能失败 + +### 3. Automate Security Controls +- IaC（基础设施即代码）确保一致性 +- 自动合规检查 +- 持续监控和告警 + +### 4. Regular Security Training +- 确保团队理解云安全责任 +- 关注社会工程和钓鱼攻击 +- 建立安全文化 + +## Related Concepts + +- [[Public Cloud]] — 公有云部署模式 +- [[Private Cloud]] — 私有云部署模式 +- [[Hybrid Cloud]] — 混合云部署模式 +- [[Cloud Security]] — 云安全 +- [[SLA]] — 服务级别协议 +- [[Disaster Recovery Planning]] — 灾难恢复规划 +- [[Multi-Factor-Authentication]] — 多因素认证 +- [[Data-Governance]] — 数据治理 +- [[FinOps]] — 云财务管理 +- [[Cloud Compliance]] — 云合规性 + +## See Also + +- [[Cloud Computing]] — 云计算基础 +- [[Cloud-Maturity-Model]] — 云成熟度模型 +- [[ISO-27001]] — 信息安全管理体系 +- [[HIPAA]] — 医疗健康信息隐私 +- [[GDPR]] — 欧盟数据保护条例 diff --git a/wiki/concepts/Shift-Left-Security.md b/wiki/concepts/Shift-Left-Security.md new file mode 100644 index 00000000..75e1ee1f --- /dev/null +++ b/wiki/concepts/Shift-Left-Security.md @@ -0,0 +1,56 @@ +# Shift-Left Security + +## Definition +"Shift left" means identifying security flaws early in the software development lifecycle. By focusing on these issues initially, teams can tackle and fix them before they become bigger problems. + +## Core Principle +将安全测试左移到软件开发生命周期的早期阶段，而非等到开发完成后才进行安全检查。 + +## Cost Efficiency +| 发现阶段 | 相对修复成本 | +|---------|------------| +| 设计阶段 | 1x | +| 开发/代码审查 | 5-10x | +| 测试阶段 | 10-30x | +| 生产环境 | 30-100x | + +## Implementation + +### Design Phase +- 威胁建模（Threat Modeling） +- 安全需求定义 +- 安全架构评审 + +### Development Phase +- [[SAST]] 静态代码分析 +- [[SCA]] 依赖扫描 +- 安全编码规范检查 +- IDE 安全插件集成 + +### CI/CD Integration +- 在构建阶段自动运行安全扫描 +- [[Break-the-Build]] 机制阻止高风险构建 +- 自动依赖更新和漏洞告警 + +## Best Practices +1. 开发者编写安全代码，从一开始就重视安全 +2. 安全专家与开发团队紧密协作 +3. 使用自动化工具减少人工审查负担 +4. 建立安全编码标准并持续培训 + +## Relationship with Shift-Right +- [[Shift-Left-Security]] ← complements → [[Shift-Right-Security]] +- 左移处理开发阶段的安全问题 +- 右移处理生产环境特有的安全问题 +- 两者结合形成完整的安全覆盖 + +## Related Concepts +- [[DevSecOps]] — 包含 Shift Left 策略的方法论 +- [[SAST]] — 静态应用安全测试 +- [[SCA]] — 软件组成分析 +- [[OWASP-Top-Ten]] — 常见安全漏洞标准 +- [[Threat Modeling]] — 威胁建模 +- [[Break-the-Build]] — 安全失败时停止构建 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Shift-Right-Security.md b/wiki/concepts/Shift-Right-Security.md new file mode 100644 index 00000000..963973a6 --- /dev/null +++ b/wiki/concepts/Shift-Right-Security.md @@ -0,0 +1,50 @@ +# Shift-Right Security + +## Definition +"Shift right" highlights the need for ongoing security measures even after launching the application. Some security vulnerabilities may go unnoticed until customers start using the software. Monitoring and addressing these issues post-deployment is crucial. + +## Core Principle +安全不仅是开发阶段的任务，生产环境部署后仍需持续进行安全监控和响应。 + +## Why Shift-Right? + +### Limitations of Pre-Production Testing +- 测试环境无法完全模拟真实用户行为 +- 某些漏洞仅在特定使用场景下暴露 +- 第三方组件漏洞可能在运行时被发现 +- 依赖库的零日漏洞需要实时响应 + +## Implementation + +### Production Monitoring +- 安全信息和事件管理（SIEM） +- 运行时应用自我保护（RASP） +- 异常行为检测 +- 日志安全分析 + +### Post-Deployment Practices +- 持续漏洞扫描 +- 威胁情报整合 +- 安全补丁管理 +- 事件响应计划 + +### Feedback Loop +- 从生产环境收集安全数据 +- 反馈给开发团队改进安全实践 +- 更新威胁模型和安全测试用例 + +## Relationship with Shift-Left +- [[Shift-Left-Security]] ← complements → [[Shift-Right-Security]] +- 左移处理开发阶段的安全问题 +- 右移处理生产环境特有的安全问题 +- 两者结合形成完整的安全覆盖 + +## Related Concepts +- [[DevSecOps]] — 包含 Shift Right 策略的方法论 +- [[RASP]] — 运行时应用自我保护 +- [[SIEM]] — 安全信息和事件管理 +- [[Vulnerability-Scanning]] — 持续漏洞扫描 +- [[Incident-Response]] — 安全事件响应 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/Socket-登录.md b/wiki/concepts/Socket-登录.md new file mode 100644 index 00000000..ec73b680 --- /dev/null +++ b/wiki/concepts/Socket-登录.md @@ -0,0 +1,36 @@ +# Socket 登录 + +## Concept Information +- **Type**: Concept +- **Status**: Active +- **Source**: [[mysql-mariadb-数据库详细信息]] + +## Definition +Socket 登录是一种通过 Unix socket 文件进行本地数据库认证的方式，不需要网络连接，适用于服务器本地管理员访问。 + +## How It Works +当使用 `-S /path/to/socket` 参数连接 MariaDB/MySQL 时，数据库服务器通过检查 socket 文件的进程所有权来验证用户身份，而不是通过网络传输密码。 + +## Example Command +```bash +sudo mysql -u root -p -S /run/mysqld/mysqld10.sock +``` + +## Key Characteristics +- **无需网络**：不经过 TCP/IP，直接通过文件系统通信 +- **更安全**：不暴露密码到网络，避免中间人攻击 +- **仅限本地**：只能从数据库服务器本机执行 +- **系统用户映射**：依赖操作系统用户身份 + +## Use Cases +1. 数据库初始配置 +2. 密码重置 +3. 创建远程访问用户 +4. 紧急修复 + +## Related Concepts +- [[用户权限]] — Host+User 组合权限模型 +- [[MariaDB]] — 使用 socket 登录进行本地管理 + +## Related Entities +- [[群晖 NAS]] — MariaDB socket 登录的目标服务器 diff --git a/wiki/concepts/Software-Assurance-Maturity-Model.md b/wiki/concepts/Software-Assurance-Maturity-Model.md new file mode 100644 index 00000000..4588b3e8 --- /dev/null +++ b/wiki/concepts/Software-Assurance-Maturity-Model.md @@ -0,0 +1,134 @@ +# Software Assurance Maturity Model (SAMM) + +> **SAMM (Software Assurance Maturity Model)** — 一个开源框架，用于评估、制定和改进软件安全保障策略，覆盖软件开发生命周期全流程。 + +## Definition + +SAMM 由 OWASP 维护，是一个供应商中立、可定制的安全框架： + +- 评估组织软件安全保障成熟度 +- 定义安全改进路线图 +- 展示安全活动的价值 + +## SAMM Core Structure + +### 4 Business Functions + +| 函数 | 描述 | 涵盖活动 | +|------|------|---------| +| **Governance** | 安全治理和管理 | 策略、标准、指南、培训 | +| **Construction** | 软件构建 | 安全需求、设计、编码 | +| **Verification** | 软件验证 | 评审、测试、漏洞管理 | +| **Deployment** | 软件部署 | 运营、托管、发布管理 | + +### 3 Security Practices per Function + +``` +Governance: +├── Strategy & Metrics +├── Policy & Compliance +└── Education & Guidance + +Construction: +├── Secure Requirements +├── Secure Architecture +└── Secure Coding + +Verification: +├── Threat Assessment +├── Security Testing +└── Security Review + +Deployment: +├── Secure Environment +├── Secure Release +└── Operational Enablement +``` + +## SAMM Maturity Levels + +每个实践评估为 0-3 级： + +| Level | 名称 | 描述 | +|-------|------|------| +| **0** | Implicit | 无正式实践 | +| **1** | Initial | 意识，但 ad-hoc | +| **2** | Practiced | 正式流程，部分覆盖 | +| **3** | Comprehensive | 量化管理，完全覆盖 | + +## Security Activities + +### Governance + +| Practice | L1 | L2 | L3 | +|----------|----|----|----| +| Strategy & Metrics | 安全指标定义 | 趋势分析 | 目标优化 | +| Policy & Compliance | 基线政策 | 合规评估 | 持续合规 | +| Education | 安全意识 | 开发者培训 | 安全冠军计划 | + +### Construction + +| Practice | L1 | L2 | L3 | +|----------|----|----|----| +| Secure Requirements | 安全需求清单 | 风险驱动需求 | 威胁建模集成 | +| Secure Architecture | 安全设计原则 | 架构评审 | 安全参考架构 | +| Secure Coding | 编码标准 | 代码扫描 | 实时分析 | + +### Verification + +| Practice | L1 | L2 | L3 | +|----------|----|----|----| +| Threat Assessment | 基础威胁识别 | 结构化威胁建模 | 持续威胁分析 | +| Security Testing | 基本渗透测试 | 自动安全测试 | 交互式测试 | +| Security Review | 代码审查 | 安全审查清单 | 专家审查 | + +### Deployment + +| Practice | L1 | L2 | L3 | +|----------|----|----|----| +| Secure Environment | 基础配置 | 配置基线 | 自动化配置管理 | +| Secure Release | 发布检查 | 签名验证 | 安全发布流程 | +| Operational Enablement | 运营安全意识 | 安全运维手册 | DevSecOps 集成 | + +## Assessment Process + +``` +1. 准备 + ├── 利益相关者识别 + └── 信息收集 + +2. 评估 + ├── 问卷调查 + ├── 文档审查 + └── 访谈 + +3. 分析 + ├── 评分计算 + ├── 差距分析 + └── 风险评估 + +4. 路线图 + ├── 改进计划 + ├── 优先级排序 + └── 资源分配 + +5. 实施 + ├── 迭代改进 + └── 效果验证 +``` + +## Comparison with Other Models + +| 模型 | 焦点 | 适用场景 | +|------|------|---------| +| **SAMM** | 软件开发生命周期 | SDLC 安全改进 | +| **BSIMM** | 实际安全活动 | 基准比较 | +| **OWASP ASVS** | 应用安全验证 | 安全测试标准 | +| **CSMM** | 云安全 | 云环境安全 | + +## See Also + +- [[Cloud Security]] — 云安全 +- [[DevSecOps]] — DevSecOps +- [[Cloud Maturity Model]] — 云成熟度模型 +- [[CSPM]] — 云安全态势管理 diff --git a/wiki/concepts/StackSets-Deployment-Visibility.md b/wiki/concepts/StackSets-Deployment-Visibility.md new file mode 100644 index 00000000..e172abe5 --- /dev/null +++ b/wiki/concepts/StackSets-Deployment-Visibility.md @@ -0,0 +1,57 @@ +--- +title: StackSets Deployment Visibility +type: concept +tags: [AWS, CloudFormation, StackSets, Observability, CloudOps] +date: 2025-10-24 +--- + +## Definition +StackSets Deployment Visibility（StackSets 部署可观测性）是指在 AWS 多账户/多区域场景下，通过 EventBridge + CloudWatch Logs 实现对 CloudFormation StackSets 部署状态的集中监控和故障排查能力。核心目标是消除多账户部署中的监控盲区，提供跨账户的统一可观测性视图。 + +## Core Properties +- **事件捕获**：EventBridge Rules 捕获所有 CloudFormation 操作事件（CREATE/UPDATE/DELETE） +- **跨账户转发**：EventBridge Custom Event Bus 将事件从成员账户转发到管理账户 +- **集中存储**：CloudWatch Log Group 聚合所有账户的 CloudFormation 日志 +- **统一查询**：CloudWatch Logs Insights 支持跨账户、跨区域的结构化日志分析 + +## Event Flow +``` +Member Account CloudFormation (CREATE/UPDATE/DELETE) + → EventBridge Rule (pattern: CloudFormation events) + → Event Bus (Custom, in Management Account) + → CloudWatch Log Group (central-cloudformation-logs) + → CloudWatch Logs Insights (aggregated queries) +``` + +## Related Concepts +- [[Multi-Account Deployment]]：StackSets 部署可观测性是跨账户部署运营的核心支撑 +- [[AWS CloudFormation StackSets]]：被监控的目标部署工具 +- [[Amazon EventBridge]]：事件捕获和跨账户路由的核心组件 +- [[Amazon CloudWatch Logs]]：集中日志存储 +- [[Centralized Logging]]：部署可观测性是集中日志的具体应用 +- [[Cross-Account Monitoring]]：共享同一套跨账户监控基础设施 +- [[Cloud Service Delivery]]：StackSets 部署可观测性是云服务交付运营的重要组成 + +## Monitorable Events +- Stack CREATE operation started/completed/failed +- Stack UPDATE operation started/completed/failed +- Stack DELETE operation started/completed/failed +- Resource creation/update/deletion events +- Stack set operation preferences (parallelism, fault tolerance) + +## Query Patterns (CloudWatch Logs Insights) +```sql +fields @timestamp, account, region +| parse @message /"resource-type":"(?[^"]+)"/ +| parse @message /"status":"(?[^"]+)"/ +| parse @message /"logical-resource-id":"(?[^"]+)"/ +| filter status = "FAILED" +| sort @timestamp desc +``` + +## Key Metrics to Track +- Deployment success/failure rate by account +- Time-to-deploy by resource type +- Regional distribution of deployments +- Failed operations and affected accounts +- Deployment timeline and operation duration diff --git a/wiki/concepts/Threat-Modeling.md b/wiki/concepts/Threat-Modeling.md new file mode 100644 index 00000000..96f1e811 --- /dev/null +++ b/wiki/concepts/Threat-Modeling.md @@ -0,0 +1,72 @@ +# Threat Modeling + +## Definition +Threat Modeling is a structured approach for identifying and prioritizing potential threats to a system, and determining the value that potential mitigations would have in reducing or neutralizing those threats. + +## Concept +威胁建模是一种系统化的方法，用于识别和优先处理系统的潜在威胁，并确定潜在缓解措施在减少或消除这些威胁方面的价值。 + +## When to Perform + +### Design Phase (Shift-Left) +- 新系统架构设计时 +- 重大功能变更时 +- 系统集成前 + +### Development Phase +- 安全编码时 +- 安全评审时 + +### Operations Phase (Shift-Right) +- 定期复审 +- 重大安全事件后 +- 系统退役评估 + +## Process (STRIDE Framework) + +### S - Spoofing（欺骗） +伪造身份，如会话劫持 + +### T - Tampering（篡改） +修改数据或代码 + +### R - Repudiation（抵赖） +否认执行的操作 + +### I - Information Disclosure（信息泄露） +未授权访问敏感数据 + +### D - Denial of Service（拒绝服务） +使系统不可用 + +### E - Elevation of Privilege（权限提升） +获得超出预期的权限 + +## Tools +- Microsoft Threat Modeling Tool +- OWASP Threat Dragon +- IriusRisk +- draw.io + 威胁建模模板 + +## Output +- 威胁文档 +- 风险矩阵（概率 × 影响） +- 缓解措施清单 +- 安全需求 + +## Best Practices +1. 从攻击者角度思考 +2. 覆盖所有信任边界 +3. 考虑依赖组件的安全 +4. 定期更新威胁模型 +5. 与安全专家协作 + +## Related Concepts +- [[DevSecOps]] — 威胁建模是安全开发的重要实践 +- [[Shift-Left-Security]] — 早期安全分析 +- [[Zero-Trust-Architecture]] — 零信任架构 +- [[Risk-Management]] — 风险管理 +- [[Security-Design]] — 安全设计 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/UEFI-Only.md b/wiki/concepts/UEFI-Only.md new file mode 100644 index 00000000..1af7fb7e --- /dev/null +++ b/wiki/concepts/UEFI-Only.md @@ -0,0 +1,34 @@ +--- +title: "UEFI Only" +type: concept +tags: [uefi, bios, boot, hp] +date: 2026-04-14 +aliases: [UEFI Only 模式, UEFI Only Mode] +--- + +# UEFI Only + +## Definition +BIOS/UEFI 固件中的一种启动模式设置，仅允许 UEFI 引导，跳过所有 Legacy/BIOS (BBS) 启动项。是 HP ZBook 等工作站解决"启动项混乱"问题的终极方案。 + +## The Problem: Hybrid Mode Pollution +HP ZBook 从 Legacy 或 Hybrid 模式切换到 UEFI 安装 Ubuntu 后，BIOS 中会残留大量 `Boot0000-Boot0004` 类型的 BBS (BIOS Boot Specification) 遗留项，这些 Legacy 项会干扰 UEFI 启动项识别。 + +## The Solution +在 BIOS 设置中 (`Boot Options` → `Boot Mode`) 将 `Legacy` 或 `Hybrid` 切换为 `UEFI Only`： +- 无效的 0000-0004 BBS 项自动消失 +- BIOS 被迫只识别 UEFI 启动项 +- BootOrder 中仅剩 0005 (Ubuntu) + +## Side Effects +- 关闭 Legacy Support 后，机器无法从传统 MBR 磁盘启动 +- 适用于纯 UEFI 环境（如现代工作站、服务器） + +## Related +- [[HP ZBook]] — 受影响的硬件平台 +- [[efibootmgr]] — 配合工具 +- [[UEFI启动修复]] — 完整修复策略 +- [[UEFI Only]] ← 解决 [[HP ZBook]] ← [[UEFI启动修复]] + +## Sources +- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] diff --git a/wiki/concepts/UEFI启动.md b/wiki/concepts/UEFI启动.md new file mode 100644 index 00000000..bba2045d --- /dev/null +++ b/wiki/concepts/UEFI启动.md @@ -0,0 +1,42 @@ +--- +title: "UEFI启动" +tags: [boot, uefi, bios, firmware] +date: 2026-04-28 +--- + +# UEFI启动 + +## Definition +UEFI（Unified Extensible Firmware Interface）是一种取代传统 BIOS 的现代固件接口标准，用于计算机启动过程。与 BIOS 相比，UEFI 提供图形界面、安全启动（Secure Boot）、支持超过 2TB 磁盘（GPT 分区）等先进特性。 + +## UEFI vs BIOS +| 特性 | UEFI | BIOS | +|------|------|------| +| 分区表 | GPT | MBR | +| 磁盘容量限制 | 无（>2TB） | 2TB | +| 主分区数限制 | 无（最多 128） | 4 个 | +| 启动速度 | 更快 | 较慢 | +| 安全启动 | 支持 Secure Boot | 无 | +| 界面 | 图形鼠标 | 文字界面 | +| 启动设备选择 | 通常按 F8/F9/F12 | 类似 | + +## UEFI Boot Process +``` +Power On → UEFI Firmware (POST) → EFI System Partition (ESP) +→ Boot Manager → UEFI OS Loader (.efi) → OS Kernel +``` + +## Clonezilla 中的 UEFI 注意事项 +- 启动盘分区方案必须选择 **GPT** +- 目标系统类型选择 **UEFI (非 CSM)** +- U 盘文件系统必须是 **FAT32**（ESP 标准格式） +- 若目标机器不支持 UEFI（老旧设备），降级使用 MBR + BIOS + +## Related Entities +- [[HP ZBook]] — 支持 UEFI 启动的笔记本 +- [[Rufus]] — 制作 UEFI 启动盘的工具 + +## Related Concepts +- [[GPT分区表]] — UEFI 使用的分区标准 +- [[MBR分区表]] — BIOS 使用的传统分区标准 +- [[ISOHybrid镜像]] — Rufus 写入 U 盘时的镜像格式 diff --git a/wiki/concepts/Vulnerability-Scanning.md b/wiki/concepts/Vulnerability-Scanning.md new file mode 100644 index 00000000..0df51099 --- /dev/null +++ b/wiki/concepts/Vulnerability-Scanning.md @@ -0,0 +1,69 @@ +# Vulnerability Scanning + +## Definition +Vulnerability scanning is the automated process of identifying and cataloging security weaknesses in systems, networks, or applications. + +## Concept +漏洞扫描是自动识别和分类系统、网络或应用程序安全弱点的过程。 + +## Types + +### Network Vulnerability Scanning +- 扫描网络设备和配置 +- 识别开放端口和服务 +- 检测配置弱点 + +### Web Application Scanning +- 检测 Web 应用漏洞 +- 爬取和测试所有页面 +- 测试 API 端点 + +### Container Image Scanning +- 检查镜像中的漏洞 +- 分析操作系统包 +- 检测应用依赖 + +### Database Scanning +- 配置审计 +- 弱密码检测 +- 权限检查 + +## Tools +- Nessus — 综合漏洞扫描器 +- OpenVAS — 开源漏洞扫描 +- Qualys — 云端漏洞管理 +- Trivy — 容器镜像扫描 +- Clair — 容器漏洞分析 + +## Integration with DevSecOps + +### CI/CD Pipeline +```yaml +# 示例：Trivy 容器扫描 +security_scan: + stage: security + script: + - trivy image myapp:latest + allow_failure: true +``` + +### Shift-Left Application +- 早期发现漏洞 +- 集成到 IDE +- 开发时实时检查 + +### Shift-Right Application +- 持续监控生产环境 +- 定期扫描 +- 自动化补丁管理 + +## Related Concepts +- [[DevSecOps]] — 漏洞扫描是持续安全的重要组成 +- [[SAST]] — 代码级漏洞检测 +- [[DAST]] — 动态漏洞检测 +- [[SCA]] — 依赖漏洞检测 +- [[Shift-Left-Security]] — 早期发现 +- [[Shift-Right-Security]] — 持续监控 + +## Sources +- [[what-is-devsecops-best-practices-benefits-and-tools]] diff --git a/wiki/concepts/What-If-Simulation.md b/wiki/concepts/What-If-Simulation.md new file mode 100644 index 00000000..d4dc3418 --- /dev/null +++ b/wiki/concepts/What-If-Simulation.md @@ -0,0 +1,78 @@ +--- +title: "What-If Simulation" +tags: + - devops + - architecture + - decision-support + - ai + - cloud-migration +created: 2026-04-25 +--- + +# What-If Simulation + +## Definition + +What-If Simulation 是 Agentic AI 模拟架构变更（如云迁移、实例类型变更）对**性能、成本和合规**的影响，支持数据驱动的决策。 + +## 应用场景 + +| 场景 | 模拟内容 | 决策支持 | +|------|---------|---------| +| 云迁移 | AWS → GCP 迁移影响 | 性能/成本/合规权衡 | +| 实例变更 | m5.xlarge → m5.large | 性能影响评估 | +| 架构重构 | 单体 → 微服务 | 复杂度/收益分析 | +| 多云策略 | 工作负载分配 | 成本优化建议 | + +## Agentic AI What-If Simulation 工作流 + +``` +1. Define Scenario → "Moving from AWS EKS to GCP GKE" +2. Gather Baseline → 当前性能/成本/合规指标 +3. Model Impact → AI 基于历史数据和预测模型 +4. Generate Report → 性能差异/成本差异/风险评估 +5. Recommend → 最优方案 + 实施路径 +``` + +## 示例 + +> An AI agent simulates moving an AWS-based SaaS application to GCP's Private Cloud in KSA (Saudi Arabia): +> +> **Performance Impact**: +> - Latency: +45ms (KSA → GCP EU) +> - Availability: 99.9% → 99.95% (enhanced SLA) +> +> **Cost Impact**: +> - Compute: -20% (GCP preemptible pricing) +> - Egress: +15% (cross-region data transfer) +> - Net: -12% annual savings +> +> **Compliance Impact**: +> - Data Sovereignty: ✅ KSA data residency satisfied +> - SLA: ✅ GCP private cloud meets enterprise agreement +> +> **Recommendation**: Proceed with migration, implement CDN for latency optimization + +## 与 [[Multi-Cloud Strategy]] 的关系 + +What-If Simulation 是 [[Multi-Cloud Strategy]] 决策支持的核心工具： + +``` +Multi-Cloud Strategy Process: +├── Assess → 评估多云需求 +├── Plan → What-If Simulation ← # ← 本页 +├── Execute → 实施迁移 +└── Optimize → 持续成本/性能优化 +``` + +## Related Concepts + +- [[Multi-Cloud Strategy]] — What-If Simulation 支持多云决策 +- [[Cloud Migration]] — 主要应用场景 +- [[Cost-Benefit Analysis]] — 类似分析方法 +- [[Decision Framework]] — 决策支持的通用框架 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] +- [[how-can-a-multi-cloud-strategy-transform-your-business-roi]] diff --git a/wiki/concepts/Zero-Trust-Architecture.md b/wiki/concepts/Zero-Trust-Architecture.md new file mode 100644 index 00000000..3a349181 --- /dev/null +++ b/wiki/concepts/Zero-Trust-Architecture.md @@ -0,0 +1,67 @@ +--- +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中的应用 diff --git a/wiki/concepts/cloud-security.md b/wiki/concepts/cloud-security.md index 4c8e98a0..17d5dc3d 100644 --- a/wiki/concepts/cloud-security.md +++ b/wiki/concepts/cloud-security.md @@ -1,44 +1,144 @@ ---- -title: Cloud Security ---- - # Cloud Security -**Cloud Security** encompasses the technologies, policies, controls, and services that protect cloud-based data, applications, and infrastructure from unauthorized access, data breaches, and other cyber threats. +> **Cloud Security** — 保护云环境、数据、应用程序和基础设施免受威胁的一组策略、技术和控制措施。 -## Common Misconception +## Definition -> **Myth**: Cloud computing is not secure. +云安全（Cloud Security）是一套全面的实践，确保： -> **Reality**: Cloud security is often more robust than on-premises solutions. +- **数据保护** — 加密、备份、访问控制 +- **身份管理** — IAM、MFA、零信任 +- **网络安全** — 防火墙、VPC、隔离 +- **合规性** — 满足法规和标准 +- **可见性** — 监控、日志、审计 -## Why Cloud Security Often Exceeds On-Premises +## Shared Responsibility Model -- **Massive Investment**: Leading cloud providers (AWS, Azure, GCP) invest billions annually in security infrastructure -- **Encryption**: Data encrypted at rest and in transit by default -- **Multi-Factor Authentication (MFA)**: Built-in identity and access management -- **Compliance Certifications**: ISO 27001, HIPAA, GDPR, SOC 2, and more -- **Automated Security Updates**: Continuous patching without user intervention -- **24/7 Monitoring**: Dedicated security operations centers monitoring threats round-the-clock -- **Advanced Firewalls**: Managed firewall services with DDoS protection +| 责任 | SaaS | PaaS | IaaS | +|------|------|------|------| +| **云服务商** | 全部基础设施 | 基础设施 | 物理层 | +| **客户** | 数据、应用 | 数据、应用、运行时 | OS、网络、应用 | -## Core Security Components +## Security Maturity Levels -| Component | Description | -|-----------|-------------| -| Identity & Access Management (IAM) | Role-based access control, MFA, least privilege | -| Encryption | AES-256 at rest, TLS 1.3 in transit | -| Network Security | VPCs, Security Groups, WAF, DDoS protection | -| Compliance | Automated compliance reporting and auditing | -| Threat Detection | AI/ML-powered anomaly detection and SIEM | +| Level | 特征 | +|-------|------| +| **L1: Basic** | 基础防火墙、简单 IAM | +| **L2: Standard** | MFA、日志、基本加密 | +| **L3: Advanced** | WAF、DDoS 保护、SIEM | +| **L4: Comprehensive** | CSPM、零信任、持续监控 | +| **L5: Optimized** | AI 威胁检测、自适应安全 | -## Related Concepts +## Key Security Practices -- [[Cloud Computing]] -- [[High Availability]] -- [[Multi-Cloud Strategy]] -- [[DevSecOps]] +### 1. Identity and Access Management -## Sources +**最佳实践** +- 最小权限原则 +- MFA 强制执行 +- 定期访问审查 +- 特权访问管理 (PAM) +- 服务账户限制 -- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|the-myths-and-misconceptions-about-cloud-computing-linkedin]] +**工具** +- AWS IAM / Azure AD / GCP IAM +- 身份提供者集成（SAML、OIDC） + +### 2. Data Protection + +**加密** +- 传输中加密（TLS 1.3） +- 静态加密（AES-256） +- 客户管理密钥（CMK） +- 密钥管理服务（KMS） + +**备份和恢复** +- 自动备份策略 +- 跨区域复制 +- 定期恢复测试 + +### 3. Network Security + +**层级** +``` +Internet → WAF → Firewall → VPC → 应用 +``` + +**组件** +- 虚拟私有云 (VPC/VNet) +- 安全组/网络 ACL +- Web 应用防火墙 (WAF) +- DDoS 防护 +- VPN/Direct Connect + +### 4. Cloud Security Posture Management (CSPM) + +**功能** +- 持续合规评估 +- 安全配置基准 +- 自动化修复 +- 风险优先级 + +**工具** +- AWS Security Hub / Azure Defender / GCP Security Command Center +- Prisma Cloud, Wiz, Lacework + +### 5. Container Security + +| 阶段 | 实践 | +|------|------| +| **Build** | 镜像扫描、基础镜像最小化 | +| **Deploy** | 签名验证、准入控制 | +| **Runtime** | 运行时安全、网络策略 | + +**工具**: Trivy, Falco, OPA Gatekeeper + +## Cloud Security Maturity Model (CSMM) + +CSMM 评估云安全成熟度的 12 个类别： + +| 域 | 类别 | +|----|------| +| **Governance** | 治理战略、风险管理 | +| **Architecture** | 安全架构、合规设计 | +| ** Data** | 数据分类、保护、保留 | +| **Applications** | 安全开发生命周期 | +| **Endpoint** | 终端保护、移动设备 | +| **Identity** | 身份管理、访问控制 | +| **Infrastructure** | 网络安全、计算安全 | +| **Logging** | 日志管理、监控 | +| **Incident** | 事件响应、业务连续性 | +| **Supply Chain** | 供应商安全、第三方风险 | +| **Physical** | 物理安全 | +| **People** | 安全意识、培训 | + +## Compliance Frameworks + +| 标准 | 适用场景 | +|------|---------| +| **SOC 2** | 通用数据处理 | +| **ISO 27001** | 信息安全管理 | +| **HIPAA** | 医疗健康数据 | +| **PCI-DSS** | 支付卡数据 | +| **GDPR** | 欧盟个人数据 | +| **FedRAMP** | 美国政府数据 | + +## Incident Response + +``` +检测 → 遏制 → 根除 → 恢复 → 事后分析 +``` + +**云环境特有考虑** +- 自动化响应（Lambda/Cloud Functions） +- 取证挑战（共享责任） +- 跨账户调查 + +## See Also + +- [[Cloud Maturity Model]] — 云成熟度框架 +- [[Cloud Governance]] — 云治理 +- [[DevSecOps]] — DevSecOps +- [[Disaster Recovery]] — 灾难恢复 +- [[WAF]] — Web 应用防火墙 +- [[CSPM]] — 云安全态势管理 diff --git a/wiki/concepts/efibootmgr.md b/wiki/concepts/efibootmgr.md new file mode 100644 index 00000000..f7b924c7 --- /dev/null +++ b/wiki/concepts/efibootmgr.md @@ -0,0 +1,40 @@ +--- +title: "efibootmgr" +type: concept +tags: [linux, uefi, boot, nvram] +date: 2026-04-14 +aliases: [efibootmgr, efibootmgr 命令] +--- + +# efibootmgr + +## Definition +Linux 系统下管理 UEFI NVRAM 启动项的工具，通过操作固件级启动寄存器实现启动顺序的查看、添加、删除和重排。 + +## Core Mechanism +- 读取当前 BootOrder（如 `BootOrder: 0005,0000,0001,0002,0003`） +- 将指定启动项编号强制写入 NVRAM 替换 BootOrder +- 持久化生效（重启后仍保持，除非固件重置） + +## Key Commands +```bash +# 查看当前启动项 +sudo efibootmgr + +# 强制将 0005 设为首选启动项 +sudo efibootmgr -o 0005,0000,0001,0002,0003 + +# 添加新启动项（假设 /dev/nvme0n1p1 是 EFI 分区） +sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Ubuntu_Force" -l "\EFI\ubuntu\shimx64.efi" +``` + +## Why It Matters +HP ZBook 等工作站存在 BIOS 固执行为：NVRAM 启动项注册成功（`Boot0005: Ubuntu`）但未被加入 `BootOrder`，导致开机忽略该启动项。`efibootmgr -o` 是绕过此问题的核心工具。 + +## Related +- [[HP ZBook]] — 受影响的硬件平台 +- [[UEFI启动修复]] — 完整修复策略 +- [[efibootmgr]] ← [[UEFI启动修复]] ← [[HP ZBook]] + +## Sources +- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] diff --git a/wiki/concepts/launchd.md b/wiki/concepts/launchd.md new file mode 100644 index 00000000..f386be39 --- /dev/null +++ b/wiki/concepts/launchd.md @@ -0,0 +1,111 @@ +# launchd + +> macOS 原生服务管理器，用于管理系统级和用户级守护进程（daemons）和代理（agents）。 + +## Overview +launchd 是 macOS 的核心初始化系统和服务管理器，替代了传统的 Unix init (SysV)、BSD rc 和 xinetd。它负责在系统启动时启动系统级服务，并在用户登录时启动用户级服务。 + +## Key Concepts +- **Daemon（守护进程）**：系统级后台服务，在系统启动时运行，无需用户登录 +- **Agent（代理）**：用户级后台服务，随用户登录启动 +- **LaunchAgent**：用户级代理，存放在 `~/Library/LaunchAgents/` +- **LaunchDaemon**：系统级守护进程，存放在 `/Library/LaunchDaemons/` +- **plist 文件**：Property List 格式的配置文件，定义服务参数 + +## launchctl Commands +```bash +# 加载服务（启动） +launchctl load ~/Library/LaunchAgents/com.frpc.client.plist + +# 卸载服务（停止） +launchctl unload ~/Library/LaunchAgents/com.frpc.client.plist + +# 启动服务 +launchctl start com.frpc.client + +# 停止服务 +launchctl stop com.frpc.client + +# 列出所有已加载的服务 +launchctl list + +# 查看服务状态 +launchctl print gui/$UID/com.frpc.client +``` + +## plist Configuration Example +```xml + + + + + Label + com.frpc.client + + ProgramArguments + + /opt/frp/frp_0.65.0_darwin_arm64/frpc + -c + /opt/frp/frp_0.65.0_darwin_arm64/frpc.toml + + + RunAtLoad + + + KeepAlive + + + StandardOutPath + /opt/frp/frp_0.65.0_darwin_arm64/frpc.log + + StandardErrorPath + /opt/frp/frp_0.65.0_darwin_arm64/frpc.error.log + + +``` + +## Key Properties +| 属性 | 说明 | +|------|------| +| Label | 唯一标识符 | +| ProgramArguments | 要执行的命令及参数数组 | +| RunAtLoad | 是否在加载时立即启动 | +| KeepAlive | 是否保持持续运行（崩溃后自动重启）| +| StandardOutPath | 标准输出日志路径 | +| StandardErrorPath | 错误输出日志路径 | +| WorkingDirectory | 工作目录 | + +## Comparison with Other Service Managers + +| 特性 | launchd | systemd (Linux) | tmux | nohup | +|------|---------|-----------------|------|-------| +| 系统级服务 | ✅ | ✅ | ❌ | ❌ | +| 用户级服务 | ✅ | ✅ | ❌ | ❌ | +| 开机自启 | ✅ | ✅ | ❌ | ❌ | +| 持久会话 | ❌ | ❌ | ✅ | ❌ | +| 简单后台 | ❌ | ❌ | ❌ | ✅ | +| 崩溃重启 | ✅ | ✅ | ❌ | ❌ | + +## Use Cases in Home Server +- **FRP 客户端**：开机自启的内网穿透服务 +- **N8n**：自动化工作流服务 +- **OpenClaw**：AI Agent 服务 +- **Home Assistant**：智能家居控制中心 + +## Best Practices +1. **使用 LaunchAgents**（而非 LaunchDaemons）：用户级代理更安全，权限更少 +2. **配置 KeepAlive**：确保服务崩溃后自动重启 +3. **设置日志路径**：便于故障排查 +4. **使用软链接版本路径**：便于升级时不修改 plist +5. **定期检查服务状态**：确保服务正常运行 + +## Related Concepts +- [[frp]] — 内网穿透工具，常用 launchd 管理 +- [[Gatekeeper]] — macOS 安全机制 +- [[Mac Mini M4]] — 常使用 launchd 管理 Home Server 服务 + +## References +- Apple Developer Documentation: Daemons and Services +- `man launchd.plist` +- `man launchctl` diff --git a/wiki/concepts/nas套件管理.md b/wiki/concepts/nas套件管理.md new file mode 100644 index 00000000..0ea492fc --- /dev/null +++ b/wiki/concepts/nas套件管理.md @@ -0,0 +1,82 @@ +--- +title: "NAS套件管理" +type: concept +tags: [nas, synology, dsm, spk, 套件中心] +date: 2025-12-29 +--- + +# NAS套件管理 + +## Aliases +- NAS Package Management +- Synology Package Center +- 套件中心 + +## Definition +NAS 套件管理是指通过网络附加存储设备（NAS）的图形化套件中心，统一安装、更新、配置第三方应用程序的机制。主流 NAS 厂商（Synology、QNAP、Asustor 等）均提供各自的套件生态系统。 + +## Synology Package Center Architecture +``` +用户界面（Web UI） + ↓ 套件中心 +Synology Package Manager (SPK) + ↓ 权限验证 / 依赖解析 +系统安装目录 (/var/packages/) + ↓ +Docker / 虚拟机 / 本地进程 +``` + +## Package Sources (Synology) +| 来源 | 说明 | +|------|------| +| 官方套件 | Synology 维护，经过安全审核 | +| 矿神源 | 社区维护，SPK 格式，补充官方未收录应用 | +| 第三方源 | 各开发者自行维护的套件仓库 | + +## SPK Package Format +Synology 的安装包格式（`.spk`），包含： +- `INFO` — 包的元数据、版本、依赖 +- `conf/` — 配置文件目录 +- `scripts/` — 安装/升级/卸载脚本 +- `package/` — 实际的应用文件 + +## DSM Version Compatibility +| DSM 版本 | 权限模型 | 第三方套件兼容性 | +|----------|----------|------------------| +| DSM 6.x | 传统 package 权限 | 大多数直接兼容 | +| DSM 7.x | 更严格的 root 隔离 | 部分需手动权限修复 | + +### DSM 7+ Root 权限修复 Pattern +对于 DSM 7+ 中无法正常运行的第三方套件，常见修复方法： +```bash +# 定位包配置文件 +sudo -i +# 修复权限配置（将 package 改为 root） +sudo sed -i 's/package/root/g' /var/packages//conf/privilege +# 重启套件 +sudo synopkg restart +``` + +**适用场景**： +- CloudDrive2 +- 某些第三方下载工具 +- 需要直接访问系统资源的应用 + +## Security Considerations +- 仅安装可信来源的套件 +- 定期检查更新，避免已知漏洞 +- 第三方套件可能绕过 Synology 安全审核 +- DSM 7+ 的权限收紧是安全改进，无需过度规避 + +## Related Entities +- [[Synology NAS]] — 硬件平台 +- [[矿神源]] — 社区套件来源 +- [[CloudDrive2]] — 典型第三方套件案例 + +## Related Concepts +- [[Root权限修复]] +- [[Docker容器化]] — 套件的技术替代方案 +- [[SPK套件格式]] + +## References +- Source: [[在Synology NAS上安装CloudDrive2]] diff --git a/wiki/concepts/process-management.md b/wiki/concepts/process-management.md new file mode 100644 index 00000000..a51db5c6 --- /dev/null +++ b/wiki/concepts/process-management.md @@ -0,0 +1,39 @@ +--- +title: "Process Management" +type: concept +aliases: [进程管理] +tags: [linux, system-admin, operations] +date: 2025-12-18 +--- + +# Process Management (进程管理) + +在操作系统中控制和管理运行中进程的行为。 + +## Definition +进程管理涵盖进程的查看、搜索、终止、优先级调整等操作，是系统管理员和开发者的核心技能。 + +## Key Operations +- **查看进程**：列出系统所有运行中的进程 +- **搜索进程**：通过名称、PID等条件过滤 +- **终止进程**：正常终止（SIGTERM）或强制杀死（SIGKILL） +- **优先级调整**：通过Nice值控制进程CPU优先级 +- **信号发送**：向进程发送各类系统信号 + +## Related Entities +- [[Btop++]] — 完整信号发送 + Nice值调整 +- [[Htop]] — 键盘驱动终止和优先级调整 +- [[Glances]] — 快速终止（k键） +- [[Mission Center]] — 右键终止/强制终止 +- [[Stacer]] — 进程审查与终止 + +## Related Concepts +- [[System Monitoring]] — 进程管理的上游需求 +- [[SSH Remote Access]] — 远程进程管理的应用场景 + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[Process Management]] ← 核心功能 ← [[Btop++]], [[Htop]], [[Glances]], [[Mission Center]], [[Stacer]] +- [[Process Management]] ← 上游需求 ← [[System Monitoring]] diff --git a/wiki/concepts/symbolic-link.md b/wiki/concepts/symbolic-link.md new file mode 100644 index 00000000..cb823250 --- /dev/null +++ b/wiki/concepts/symbolic-link.md @@ -0,0 +1,85 @@ +# Symbolic Link（符号链接） + +> Unix/Linux/macOS 文件系统中的一种特殊文件类型，指向另一个文件或目录的路径别名。 + +## Overview + +Symbolic Link（符号链接，简称 symlink）是文件系统中的一个特殊条目，它存储的是目标路径字符串，而非实际数据。访问符号链接时，操作系统自动将其解析为实际目标路径。符号链接可用于解决以下问题： +- 将隐藏目录映射为可见路径（如 `~/.openclaw` → `~/openclaw`） +- 为长路径或版本化目录创建稳定引用（如 `/opt/frp/current` → 版本目录） +- 跨文件系统创建文件引用 + +## Core Properties + +| 属性 | 说明 | +|------|------| +| 类型 | 特殊文件（ln -s 创建） | +| 存储内容 | 目标路径字符串（文本） | +| 跨文件系统 | ✅ 支持（记录路径，不记录 inode） | +| 删除行为 | 删除链接本身，不影响目标 | +| 相对路径 | 可使用（相对当前链接位置解析） | +| 绝对路径 | 推荐使用（避免歧义） | + +## Common Commands + +```bash +# 创建符号链接 +ln -s /source/path /link/path # 相对路径源 +ln -s /absolute/source /absolute/link # 绝对路径源 + +# 验证链接 +ls -la ~ | grep linkname # 查看链接关系 +readlink ~/linkname # 查看指向目标 + +# 删除符号链接（不会删除目标） +rm ~/linkname + +# 替换已有链接（-n 处理链接本身是目录的情况） +ln -sfn /new/target /link/path +``` + +## Use Cases + +### 1. 隐藏目录可见性映射 +将 OpenClaw 的 `~/.openclaw` 隐藏目录映射为 `~/openclaw`，使 Obsidian 可直接作为 Vault 访问。 +``` +~/.openclaw → ~/openclaw (符号链接) +``` + +### 2. 版本管理（软链接策略） +使用 `current` 符号链接指向当前激活的版本目录，简化启动命令并实现无缝升级/回滚。 +``` +/opt/frp/ +├── frp_0.65.0_darwin_arm64/ +├── frp_0.66.0_darwin_arm64/ +└── current → frp_0.66.0_darwin_arm64/ +``` + +### 3. Git 友好目录结构 +将实际数据目录放在 Git 可管理的位置，再创建指向它的符号链接。 + +## Symbolic Link vs Hard Link + +| 对比 | Symbolic Link | Hard Link | +|------|--------------|-----------| +| 跨文件系统 | ✅ 支持 | ❌ 不支持 | +| 指向目录 | ✅ 支持 | ❌ 不支持（Unix） | +| 删除目标 | 链接失效 | 仍可访问（引用计数>1） | +| 存储内容 | 路径字符串 | inode 引用 | +| 适用场景 | 路径别名、跨分区 | 同分区文件别名 | + +## Key Risks + +| 风险 | 说明 | 防范 | +|------|------|------| +| 目标不存在 | 链接成为悬空链接（dangling link） | 删除前确认无其他链接依赖 | +| 误删 `rm -rf` | 当链接指向目录时，`rm` 链接本身是安全的 | 不要对目录链接使用 `-rf` | +| 循环链接 | 链接指向自身或形成环 | 使用 `find -L` 或 `readlink -f` 展开 | + +## Related + +- [[软链接策略]] — Symbolic Link 在软件版本管理中的应用 +- [[Obsidian]] — Symbolic Link 的典型使用场景（Vault 映射） +- [[OpenClaw]] — Symbolic Link 的操作对象（隐藏目录可见化） +- [[frp]] — 软链接策略的典型应用 +- [[launchd]] — 使用软链接路径的服务管理 diff --git a/wiki/concepts/system-monitoring.md b/wiki/concepts/system-monitoring.md new file mode 100644 index 00000000..05828143 --- /dev/null +++ b/wiki/concepts/system-monitoring.md @@ -0,0 +1,44 @@ +--- +title: "System Monitoring" +type: concept +aliases: [系统监控] +tags: [linux, devops, observability, sre] +date: 2025-12-18 +--- + +# System Monitoring (系统监控) + +对计算机硬件资源和运行状态进行实时观测和分析。 + +## Definition +系统监控涵盖CPU使用率、内存占用、磁盘I/O、网络流量等硬件指标的实时观测，是运维、SRE和开发者保障系统稳定性的核心手段。 + +## Monitoring Dimensions +- **CPU监控**：核心利用率、负载均值、上下文切换 +- **内存监控**：物理内存、交换空间、缓存使用 +- **存储监控**：磁盘空间、I/O读写速度 +- **网络监控**：带宽使用、连接状态、流量统计 +- **进程监控**：运行中进程、资源占用、进程树 + +## Related Entities +- [[Btop++]] — 综合监控面板 +- [[Htop]] — 进程级监控 +- [[Glances]] — 快速一览 +- [[Bottom]] — 实时图表 +- [[Mission Center]] — 图形化监控 +- [[Stacer]] — 监控+历史记录 + +## Related Concepts +- [[Prometheus]] — 时间序列监控（Home Server Automation） +- [[Grafana]] — 监控可视化（Home Server Automation） +- [[Process Management]] — 下游操作需求 +- [[Observability]] — 更广的可观测性范畴 +- [[DORA Metrics]] — 运维效能指标 + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[System Monitoring]] ← 核心功能 ← all 6 tools (Btop++, Htop, Glances, Bottom, Mission Center, Stacer) +- [[System Monitoring]] ← 上游需求 ← [[Process Management]] +- [[System Monitoring]] ← 可视化层 ← [[Grafana]] diff --git a/wiki/concepts/systemd.md b/wiki/concepts/systemd.md new file mode 100644 index 00000000..cc863799 --- /dev/null +++ b/wiki/concepts/systemd.md @@ -0,0 +1,159 @@ +--- +title: "systemd" +type: concept +tags: [linux, init, service-manager, ubuntu] +aliases: [systemd服务管理, systemd unit] +--- + +# systemd + +## Overview +**systemd** 是 Linux 系统的服务管理器（初始化系统），是 Ubuntu Server、Debian、CentOS/RHEL、Fedora 等主流 Linux 发行版的默认初始化系统。systemd 通过 unit 文件（service、socket、timer 等）管理服务的生命周期，提供开机自启、自动重启、日志收集等生产级特性。 + +## Core Components + +### Unit Types +| Type | Description | Example | +|------|-------------|---------| +| **service** | 后台守护进程 | frpc.service | +| **socket** | 监听 socket，按需激活服务 | ssh.socket | +| **timer** | 定时任务（cron 替代） | backup.timer | +| **mount** | 文件系统挂载点 | opt-frp.mount | +| **path** | 文件系统路径监控 | download.path | + +### Core Commands +```bash +# 服务管理 +systemctl start # 启动服务 +systemctl stop # 停止服务 +systemctl restart # 重启服务 +systemctl status # 查看状态 +systemctl enable # 开机自启 +systemctl disable # 取消开机自启 +systemctl enable --now # 启用并立即启动 + +# 重新加载 +systemctl daemon-reload # 重新加载 unit 文件 +systemctl reload # 热重载配置 + +# 查看日志 +journalctl -u # 查看服务日志 +journalctl -u -f # 实时流式日志 +journalctl -u -n 50 # 最近 50 行 +journalctl --since "1 hour ago" -u # 指定时间范围 +``` + +## Service Unit Template +```ini +[Unit] +Description=<服务描述> +After=network.target # 网络就绪后启动 +Wants=network-online.target # 等待网络完全上线 + +[Service] +Type=simple # 简单进程（推荐） +ExecStart=/path/to/binary # 启动命令 +Restart=on-failure # 失败后自动重启 +RestartSec=10 # 重启间隔 10 秒 +User= # 可选：指定运行用户 +WorkingDirectory=/path # 可选：工作目录 + +[Install] +WantedBy=multi-user.target # 多用户模式下启动 +``` + +## Key Features + +### 1. Automatic Restart (Restart=on-failure) +```ini +Restart=on-failure # 进程异常退出时重启（非 0 退出码） +Restart=always # 任何退出都重启 +Restart=on-abnormal # 被信号终止时重启（SIGTERM/SIGKILL） +RestartSec=5 # 重启前等待 5 秒 +``` +**应用场景**：FRP 客户端连接中断后自动重连，无需手动干预。 + +### 2. Socket Activation (按需启动) +Ubuntu 24.04 SSH 默认使用 ssh.socket（按需激活）： +```bash +# 查看 socket 状态 +systemctl status ssh.socket + +# 切换为传统 service 模式（持续运行） +sudo systemctl disable --now ssh.socket +sudo systemctl enable --now ssh.service +``` +**优势**：无连接时节省资源，有连接时自动启动 sshd。 + +### 3. Journald Logging (日志管理) +systemd 集成 journald 日志系统，无需手动配置日志轮转： +- **自动日志轮转**：journald 自动管理日志大小 +- **结构化日志**：支持 systemd-cat 写入结构化日志 +- **二进制格式**：高效压缩，支持多种过滤条件 +- **持久化存储**：设置 Storage=persistent 在 /var/log/journal/ 持久化 + +### 4. Dependencies (服务依赖) +```ini +After=network.target # 网络就绪后启动 +After=network-online.target # 等待网络完全上线 +Wants=network-online.target # 软依赖：网络上线后启动 +Requires=postgresql.service # 强依赖：必须启动 +PartOf=postgresql.service # 停止时级联停止 +``` + +### 5. Environment Management +```ini +[Service] +Environment="FRP_TOKEN=secret123" +EnvironmentFile=/etc/frp/env # 从文件加载环境变量 +``` + +## systemd vs Alternatives + +| Feature | systemd | init (SysV) | OpenRC | runit | +|---------|---------|-------------|--------|-------| +| 开机自启 | systemctl enable | chkconfig | rc-update | ln -s | +| 进程监控 | 自动重启 | 需外部 watchdog | 外部 watchdog | supervise | +| 日志 | journalctl | 手动配置 | 手动配置 | 手动配置 | +| 并行启动 | 是 | 否 | 部分 | 是 | +| Socket 激活 | 是 | 否 | 否 | 否 | +| Timer 任务 | 是 | cron | cron | runit | + +## Best Practices + +1. **Type=simple**（推荐）：单进程服务，systemd 直接监控主进程 +2. **Restart=on-failure**：生产环境必备，防止进程崩溃后无人值守 +3. **RestartSec**：设置合理间隔（如 10 秒），避免频繁重启 +4. **daemon-reload**：修改 unit 文件后必须执行 +5. **User=**：使用非 root 用户运行服务，降低安全风险 +6. **ProtectSystem=**：限制服务对文件系统的访问范围 +7. **ReadOnlyPaths=**：只读文件系统目录列表 +8. **NoNewPrivileges=true**：防止服务提升权限 + +## FRP systemd Service Example +```ini +[Unit] +Description=frp client (frpc) +After=network-online.target +Wants=network-online.target + +[Service] +Type=simple +ExecStart=/opt/frp/current/frpc -c /opt/frp/current/frpc.toml +Restart=on-failure +RestartSec=10 +User=ubuntu + +[Install] +WantedBy=multi-user.target +``` + +## Related Concepts +- [[launchd]] — macOS 原生服务管理器，与 systemd 功能对应但实现不同 +- [[进程管理]] — systemd 是 Linux 进程管理的核心工具 +- [[开机自启]] — systemd 的 enable 功能实现服务开机自启 +- [[journald]] — systemd 集成的日志收集系统 + +## References +- Arch Wiki: https://wiki.archlinux.org/title/Systemd +- man pages: `man systemd.unit`, `man systemd.service`, `man systemctl` diff --git a/wiki/concepts/tui.md b/wiki/concepts/tui.md new file mode 100644 index 00000000..8d330438 --- /dev/null +++ b/wiki/concepts/tui.md @@ -0,0 +1,35 @@ +--- +title: "TUI" +type: concept +aliases: [Text User Interface, 文本用户界面] +tags: [linux, interface, cli] +date: 2025-12-18 +--- + +# TUI (Text User Interface) + +在终端/命令行环境中运行的交互式图形化用户界面。 + +## Definition +TUI（文本用户界面）是通过终端模拟器呈现的交互式界面，使用ASCII字符、ANSI颜色代码在文本模式下模拟图形化控件。相比GUI，TUI具有以下优势： + +- **高性能**：资源占用极低，在系统负载高时仍能流畅运行 +- **SSH友好**：可通过远程连接访问，适合服务器管理 +- **可脚本化**：易于集成到自动化工作流中 + +## Related Entities +- [[Btop++]] — TUI资源监控器（作者首选） +- [[Htop]] — TUI进程监控器 +- [[Glances]] — 超轻量TUI监控器 +- [[Bottom]] — TUI图表监控器 + +## Related Concepts +- [[GUI]] — 图形用户界面（TUI的对立面） +- [[CLI]] — 命令行界面（TUI的底层基础） + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[TUI]] ← 应用类型 ← [[Btop++]], [[Htop]], [[Glances]], [[Bottom]] +- [[TUI]] ← 应用类型 ← [[SSH Remote Access]] diff --git a/wiki/concepts/云盘挂载.md b/wiki/concepts/云盘挂载.md new file mode 100644 index 00000000..46ff672c --- /dev/null +++ b/wiki/concepts/云盘挂载.md @@ -0,0 +1,72 @@ +--- +title: "云盘挂载" +type: concept +tags: [云存储, 文件系统, fusefs, nas] +date: 2025-12-29 +--- + +# 云盘挂载 + +## Aliases +- Cloud Drive Mounting +- 云盘映射 +- 虚拟磁盘 + +## Definition +云盘挂载是通过虚拟文件系统技术（如 FUSE、Dokan）将云端存储服务映射为本地文件系统目录的一种技术方案。用户可以在本地文件管理器中直接浏览、读取、甚至写入云端文件，无需手动执行同步操作。 + +## Mechanism +``` +云存储服务（阿里云盘 / Google Drive / OneDrive） + ↓ HTTP API +虚拟文件系统驱动（CloudDrive FUSE / rclone） + ↓ VFS 转换 +本地挂载点（/mnt/clouddrive/aliyun） + ↓ +用户程序 / 文件管理器 +``` + +## Key Characteristics +| 特性 | 说明 | +|------|------| +| 即时访问 | 无需预下载，云端文件按需加载 | +| 透明使用 | 挂载后如同本地磁盘 | +| 缓存机制 | 热数据缓存在本地，节省流量 | +| 写穿透 | 部分实现支持直接写入云端 | +| 离线可用 | 缓存文件可离线访问 | + +## Comparison with Traditional Sync +| 维度 | 云盘挂载 | 传统同步 | +|------|----------|----------| +| 存储占用 | 仅缓存 | 完整副本 | +| 访问延迟 | 按需加载 | 即时访问 | +| 离线支持 | 仅缓存 | 完全支持 | +| 带宽消耗 | 按需读取 | 全量同步 | +| 一致性 | 云端优先 | 双向同步 | + +## Implementation Tools +- **CloudDrive2** — 支持阿里云盘、115、夸克等国内云盘，NAS 友好 +- **rclone** — 通用的云存储 CLI 工具，支持 70+ 云服务 +- **google-drive-ocamlfuse** — Google Drive 专用挂载方案 +- **Tdarr** — 媒体文件自动化处理流水线 + +## Use Cases +1. **NAS 多媒体中心**：将云盘挂载到 NAS，直接用 Jellyfin/Navidrome 播放云端媒体文件 +2. **文件备份中转**：无需 PC 中转，直接从云盘下载到 NAS +3. **团队共享存储**：统一云盘作为团队文件库，NAS 作为本地缓存层 + +## Security Considerations +- **最小权限授权**：仅授权必要目录，避免授予备份/系统目录访问权限 +- **Token 安全**：OAuth 授权 token 应妥善保管 +- **访问审计**：定期检查挂载日志，防止异常访问 +- **卸载即隔离**：停止挂载后云盘内容不可访问 + +## Connections +- [[CloudDrive2]] — NAS 场景的挂载工具 +- [[Navidrome]] — 可消费挂载目录中的音乐文件 +- [[Jellyfin]] — 可消费挂载目录中的视频文件 +- [[Synology NAS]] — 典型部署平台 +- [[rclone]] — 通用的云存储挂载工具 + +## References +- Source: [[在Synology NAS上安装CloudDrive2]] diff --git a/wiki/concepts/全盘镜像备份.md b/wiki/concepts/全盘镜像备份.md new file mode 100644 index 00000000..a64925d8 --- /dev/null +++ b/wiki/concepts/全盘镜像备份.md @@ -0,0 +1,52 @@ +--- +title: "Rufus" +tags: [tool, bootable-usb, iso-burning] +date: 2026-04-28 +--- + +# Rufus + +## Aliases +- Rufus +- Rufus USB + +## Definition +Rufus 是一款开源的 U 盘启动盘制作工具，用于将 ISO 镜像文件写入 U 盘，创建可启动的 USB 安装盘。支持 ISOHybrid 镜像的正确写入模式选择，是制作 Clonezilla 等 Linux Live USB 的首选工具。 + +## Key Workflow: Clonezilla 启动盘制作 +``` +1. 下载 Clonezilla ISO (amd64, debian 发行版) +2. 插入 U 盘（≥1GB，提前备份数据） +3. 打开 Rufus，选择设备（U 盘） +4. 点击"选择"加载 Clonezilla ISO +5. 分区方案：GPT（较新机器）/ MBR（老旧机器） +6. 目标系统类型：UEFI（非 CSM）/ BIOS（或 UEFI-CSM） +7. 文件系统：保持 FAT32 +8. 点击"开始" +9. 弹出"检测到 ISOHybrid 镜像" → 选择"以 ISO 镜像模式写入 (推荐)" +10. 等待完成 +``` + +## ISOHybrid 镜像写入模式 +| 模式 | 说明 | 适用场景 | +|------|------|----------| +| ISO 镜像模式（推荐） | 将 ISO 内容解压写入，U 盘看起来像光盘 | 绝大多数情况 | +| DD 镜像模式 | 将 ISO 作为原始磁盘镜像写入 | UEFI 无法识别 FAT32 时的备用方案 | + +> ⚠️ 错误模式会导致启动失败。如果 ISO 模式无法启动，再尝试 DD 模式。 + +## Partition Scheme & Target System +| 场景 | 分区方案 | 目标系统类型 | +|------|----------|-------------| +| 较新笔记本（UEFI） | GPT | UEFI (非 CSM) | +| 老旧笔记本（BIOS） | MBR | BIOS (或 UEFI-CSM) | +| 不确定 | GPT（默认尝试） | UEFI (非 CSM) | + +## Related Concepts +- [[UEFI启动]] — Rufus GPT+UEFI 组合对应的启动标准 +- [[MBR分区表]] — Rufus MBR+BIOS 组合对应的传统分区方案 +- [[ISOHybrid镜像]] — Rufus 处理的镜像类型 + +## Related Entities +- [[Clonezilla]] — Rufus 制作启动盘的目标工具 +- [[HP ZBook]] — 使用 Rufus 制作启动盘后启动的目标笔记本 diff --git a/wiki/concepts/合成监控.md b/wiki/concepts/合成监控.md new file mode 100644 index 00000000..196c54b7 --- /dev/null +++ b/wiki/concepts/合成监控.md @@ -0,0 +1,62 @@ +--- +title: "合成监控" +type: concept +aliases: [Synthetic Monitoring, 合成监测, Active Monitoring, 主动监控, Blackbox Monitoring] +tags: [monitoring, uptime, http, tls, proactive] +date: 2025-11-11 +--- + +# 合成监控 + +## Overview +合成监控（Synthetic Monitoring）也称为主动监控（Active Monitoring）或黑盒监控（Blackbox Monitoring），是通过模拟真实用户请求或系统调用，从外部视角主动探测服务可用性和响应质量的监控方法。与基于主机/应用内部指标的白盒监控（Whitebox Monitoring）互补，共同构成完整的可观测性覆盖。 + +## Core Principles +- **主动探测**：不依赖服务内部指标，从外部发起请求 +- **故障预判**：在用户发现前检测到服务异常 +- **SLA 验证**：客观量化服务可用性和响应时间 +- **全球分布**：从多个地理位置探测（定位区域性故障） +- **可重复**：周期性自动执行，历史可追溯 + +## Key Dimensions +| 维度 | 指标 | 告警阈值示例 | +|------|------|------------| +| 可用性 | `probe_success == 0` | 连续 2 次失败 | +| 响应时间 | `probe_duration_seconds > 5` | > 5s | +| HTTP 状态码 | `probe_http_status_code >= 400` | 非 2xx | +| TLS 证书 | `probe_ssl_earliest_cert_expiry - time() < 14d` | < 14 天 | +| DNS 解析 | `probe_dns_lookup_duration_seconds > 1` | > 1s | + +## Tools for Synthetic Monitoring +| 工具 | 类型 | 特点 | +|------|------|------| +| [[blackbox_exporter]] | Prometheus Exporter | HTTP/TCP/DNS/TLS 探测，PromQL 告警 | +| [[Uptime Kuma]] | 自托管 SaaS 替代 | Web UI 友好，Docker 部署 | +| UptimeRobot | SaaS | 全球节点，免维护 | +| Pingdom | SaaS | 企业级 SLA 监控 | +| Grafana Synthetic Monitoring | Grafana Cloud | Grafana 生态集成 | + +## Blackbox vs Whitebox Monitoring +| 维度 | 黑盒（合成监控） | 白盒（内部监控） | +|------|----------------|----------------| +| 数据来源 | 外部请求 | 内部指标 | +| 故障感知 | 用户视角的故障 | 基础设施故障 | +| 配置复杂度 | 低 | 中 | +| 覆盖范围 | HTTP/TCP 层 | CPU/内存/应用层 | +| 适用场景 | SLA 验证、可用性告警 | 根因分析、性能诊断 | + +## Home Server Use Cases +1. **外网服务探测**：检测 NAS / n8n / Grafana 等内网服务的公网访问可用性 +2. **TLS 证书监控**：提前发现即将到期的证书，避免生产事故 +3. **内网域名解析**：监控 DNS 解析是否正常（frp 隧道故障检测） +4. **API 健康检查**：检测第三方 API 服务的可用性（OpenAI / Claude API） + +## Related Entities +- [[blackbox_exporter]] — Prometheus 合成监控实现 +- [[Uptime Kuma]] — 互补的合成监控工具 + +## Related Concepts +- [[System Monitoring]] — 上游领域 +- [[Prometheus告警规则]] — 合成监控告警条件 +- [[PromQL]] — 探测指标查询语言 +- [[时序数据库]] — 探测数据存储 diff --git a/wiki/concepts/固件刷入.md b/wiki/concepts/固件刷入.md new file mode 100644 index 00000000..bf3d5a23 --- /dev/null +++ b/wiki/concepts/固件刷入.md @@ -0,0 +1,25 @@ +# 固件刷入 + +## Definition +将第三方固件写入路由器闪存以替换原厂固件的过程，使路由器能够获得更多原生固件不支持的功能。 + +## Process (以RAX50为例) +1. 登录原厂后台（192.168.1.1） +2. 下载过渡固件（.chk格式） +3. 刷入过渡固件（界面变为梅林风格） +4. 下载正式梅林固件（.w格式） +5. 刷入正式固件 +6. 恢复出厂设置 +7. 进行JFFS双清 +8. 配置WiFi和登录密码 + +## Key Considerations +- **刷机有风险**：不当操作可能导致路由器变砖 +- **过渡固件不可跳过**：网件路由器必须先刷.chk过渡固件 +- **双清是必要的**：刷机后应执行JFFS双清确保环境干净 +- **恢复出厂设置**：恢复的是梅林固件的默认配置，不会恢复网件原厂 + +## Related +- [[过渡固件]] — 刷入过程中的关键步骤 +- [[梅林固件]] — 刷入的目标固件 +- [[JFFS双清]] — 刷机后的必要清理操作 diff --git a/wiki/concepts/增量备份.md b/wiki/concepts/增量备份.md new file mode 100644 index 00000000..eeafdefa --- /dev/null +++ b/wiki/concepts/增量备份.md @@ -0,0 +1,67 @@ +--- +title: "增量备份" +tags: [backup, storage, devops] +date: 2026-04-26 +--- + +# 增量备份 (Incremental Backup) + +## Definition +增量备份是一种数据保护策略，仅备份自上次备份以来发生变化的数据。与全量备份相比，显著减少备份时间、存储空间和网络带宽需求。 + +## Core Principles +- **差异检测**: 通过比较源端与目标端文件的时间戳、大小或校验和，识别需要备份的变更 +- **链式依赖**: 增量备份依赖前一次备份作为基础，恢复时需按顺序还原所有增量链 +- **增量同步**: rsync 等工具通过 SSH 传输变更块，实现高效的增量数据传输 + +## Key Mechanisms + +### rsync Algorithm +rsync 是最常用的增量备份工具，核心机制包括： +- **快速检测**: 通过滑动窗口算法快速定位差异块 +- **增量传输**: 仅传输变化的部分，而非整个文件 +- **校验和对比**: 使用 MD4/MD5 校验和比较远程与本地文件块 + +### Key Parameters +```bash +rsync -azR --delete \ + --exclude="venv/" \ + --exclude="**/__pycache__/" \ + --exclude=".git/" \ + /source/ /destination/ +``` +- `-a`: 归档模式（保留权限、时间戳、链接等） +- `-z`: 压缩传输 +- `-R`: 使用相对路径 +- `--delete`: 删除目标端多余文件（镜像同步） + +## Related Concepts +- [[Disaster-Recovery]] — 增量备份是灾备策略的核心组件 +- [[RTO]] — 恢复时间目标，受备份频率影响 +- [[RPO]] — 恢复点目标，由增量备份间隔决定 + +## Related Practices +- **rsync 增量同步**: 通过 SSH 或直接访问实现本地/远程增量备份 +- **快照备份**: 通过 LVM/ZFS 快照实现接近零 RPO 的增量保护 +- **链式增量**: 定期创建全量备份，中间插入增量备份，形成备份链 + +## Best Practices +1. **定期全量 + 日常增量**: 每周/每月创建全量备份，中间每日增量 +2. **校验恢复测试**: 定期验证备份可还原性 +3. **差异对比**: 备份前后对比文件数量和大小 +4. **错误容错**: rsync 错误码 0/23/24 均视为成功（权限/文件变化问题属正常） + +## Example: rsync 备份脚本片段 +```bash +rsync -azR --delete \ + --exclude="venv/" \ + --exclude=".git/" \ + /var/lib/docker/volumes/ \ + /etc/docker/ \ + /mnt/nas_backup/docker_backups/$(date +%Y-%m-%d)/ +``` + +## See Also +- [[永久挂载]] — 增量备份需要可靠的网络存储作为目标端 +- [[Cron定时任务]] — 自动化执行增量备份 +- [[进程管理]] — 备份进程的安全终止 diff --git a/wiki/concepts/容器资源限制.md b/wiki/concepts/容器资源限制.md new file mode 100644 index 00000000..0d3762eb --- /dev/null +++ b/wiki/concepts/容器资源限制.md @@ -0,0 +1,29 @@ +# 容器资源限制 + +## Description +通过 Docker 的 `deploy.resources.limits` 字段对容器可使用的资源（内存、CPU）进行上限约束，防止单一容器耗尽宿主机资源，影响其他服务稳定性。 + +## 常用配置 +```yaml +deploy: + resources: + limits: + memory: 128M # 最大内存限制 + cpus: '0.5' # 最大 CPU 配额（50%） +``` + +## 典型应用场景 +- it-tools Web UI：128MB 内存足够运行 +- Jellyfin 媒体转码：建议 2-4GB 内存 +- 数据库容器（MariaDB）：建议 512MB-2GB +- Prometheus/Grafana：建议 512MB-1GB + +## 注意事项 +- 内存限制 `128M` 对于简单 Web UI 工具足够 +- 超出限制后容器可能被 OOM Killer 终止 +- 建议结合健康检查（healthcheck）确保服务可用性 + +## Used By +- [[用docker安装it-tools]] +- [[Docker-Compose]] +- [[Navidrome]]（转码缓存 200MB 限制） diff --git a/wiki/concepts/容器重启策略.md b/wiki/concepts/容器重启策略.md new file mode 100644 index 00000000..d8e02c76 --- /dev/null +++ b/wiki/concepts/容器重启策略.md @@ -0,0 +1,26 @@ +# 容器重启策略 + +## Description +Docker 容器的 `restart` 策略决定容器在退出后何时自动重启。通过设置合适的重启策略，可以实现服务的高可用和自愈能力，无需 systemd/supervisor 等进程管理器。 + +## 策略选项 +| 策略 | 行为 | +|------|------| +| `no` | 不自动重启（默认） | +| `always` | 容器退出后始终重启 | +| `unless-stopped` | 除非被手动停止，否则始终重启 | +| `on-failure[:n]` | 仅在退出码非零时重启，最多 n 次 | + +## 推荐场景 +- **Web 服务**（it-tools, Jellyfin, Navidrome）：`unless-stopped` +- **一次性任务**：`no` +- **守护进程**：需要精确控制时用 `on-failure` +- **关键基础设施**（数据库）：`always` + +## `unless-stopped` vs `always` +- `always`：即使手动 `docker stop`，Docker 守护进程重启后也会重启容器 +- `unless-stopped`：手动 `docker stop` 后，守护进程重启不会自动重启该容器 + +## Used By +- [[用docker安装it-tools]] — `restart: unless-stopped` +- [[Docker-Compose]] diff --git a/wiki/concepts/挂载点检查.md b/wiki/concepts/挂载点检查.md new file mode 100644 index 00000000..88b5f6c4 --- /dev/null +++ b/wiki/concepts/挂载点检查.md @@ -0,0 +1,48 @@ +--- +title: "挂载点检查" +tags: [linux, backup, safety, ubuntu] +date: 2026-04-26 +--- + +# 挂载点检查 (Mount Point Verification) + +## Definition +挂载点检查是在执行备份、文件同步等操作前，验证目标存储设备是否正确挂载的安全机制。防止在存储设备离线时将数据写入本地目录，导致硬盘空间迅速耗尽或数据丢失。 + +## Core Problem +当 NAS/网络存储离线时，挂载点目录仍然存在（但为空），备份脚本可能将数据写入本地文件系统而非网络存储： +1. 数据实际上写入本地磁盘 +2. 备份看似成功但数据不在目标位置 +3. 本地磁盘空间迅速耗尽 + +## Solution: mountpoint Command +Linux 提供 `mountpoint` 命令检查目录是否为有效的挂载点： + +```bash +mountpoint -q /mnt/nas_backup +# 返回 0 表示是挂载点，返回 1 表示不是 +``` + +## Implementation in Backup Script +```bash +# 检查挂载点是否是一个有效的挂载 +if ! mountpoint -q /mnt/nas_backup; then + echo "$(date): [错误] NAS 未挂载，备份任务取消！" >> /var/log/rsync_backup.log + exit 1 +fi +``` + +## Related Concepts +- [[永久挂载]] — 挂载点检查是永久挂载策略的补充安全机制 +- [[增量备份]] — 挂载点检查是备份流程的必要前置步骤 +- [[进程管理]] — NAS 离线时的进程安全处理 + +## Best Practices +1. **前置检查**: 任何写入挂载点的操作前必须检查 +2. **日志记录**: 挂载失败时记录详细日志和错误时间 +3. **告警机制**: 挂载失败时发送通知（如 Telegram 消息） +4. **双重验证**: 检查挂载点 + 检查 df 输出的一致性 + +## See Also +- [[Cron定时任务]] — 定时任务中嵌入挂载点检查 +- [[进程管理]] — 挂载失败后的进程终止逻辑 diff --git a/wiki/concepts/指纹浏览器.md b/wiki/concepts/指纹浏览器.md new file mode 100644 index 00000000..956ba1f9 --- /dev/null +++ b/wiki/concepts/指纹浏览器.md @@ -0,0 +1,54 @@ +--- +title: "指纹浏览器" +type: concept +tags: [browser, account-isolation, privacy] +date: 2025-12-31 +--- + +# 指纹浏览器 + +## 定义 +指纹浏览器是一种能够模拟不同设备、网络环境的多账号浏览器，通过隔离浏览器环境来减少账号关联和封号风险。 + +## 核心原理 +- **浏览器指纹隔离**: 每个浏览器环境有独立的： + - User Agent + - IP地址 + - 操作系统 + - 屏幕分辨率 + - 时区、语言等浏览器参数 +- **环境独立性**: 各环境之间互不干扰，防止平台通过浏览器特征识别关联账号 + +## 典型应用场景 +- 跨境电商多账号管理 +- 海外社交媒体多账号运营 +- AI服务注册（如Claude、ChatGPT） +- 广告投放多账号隔离 + +## 代表产品 +- [[AdsPower]] — 推荐，免费版提供5个环境 +- Multilogin +- Dolphin{anty} +- Linken Sphere + +## 与本地浏览器的区别 +| 特性 | 本地浏览器 | 指纹浏览器 | +|------|-----------|-----------| +| IP隔离 | ❌ 共享本机IP | ✅ 独立代理IP | +| 指纹隔离 | ❌ 暴露本机特征 | ✅ 模拟独立环境 | +| 账号关联 | ⚠️ 易被关联 | ✅ 有效隔离 | +| 免费额度 | N/A | 通常5个以内 | + +## 关键配置 +1. **代理类型**: Socks5代理最常用 +2. **User Agent**: 选择目标地区的浏览器版本 +3. **操作系统**: Windows/macOS/Linux均可 +4. **时区/语言**: 建议与IP所在地一致 + +## 相关概念 +- [[账号隔离]] +- [[IP纯净度]] +- [[Socks5代理]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/concepts/接码平台.md b/wiki/concepts/接码平台.md new file mode 100644 index 00000000..6aa6ce6a --- /dev/null +++ b/wiki/concepts/接码平台.md @@ -0,0 +1,66 @@ +--- +title: "接码平台" +type: concept +tags: [sms-verification, tool, registration] +date: 2025-12-31 +--- + +# 接码平台 + +## 定义 +接码平台是提供短信接码服务的在线平台或应用，用户可以租用临时手机号码来接收短信验证码，用于注册海外服务、绕过手机绑定限制等场景。 + +## 核心功能 +- **临时手机号租用**: 提供可接收短信的虚拟号码 +- **多国家/地区支持**: 支持美国、中国香港等地区号码 +- **实时接收**: 在线查看收到的验证码 +- **号码复用**: 订阅制可长期使用同一号码 + +## 平台类型 + +### 一次性号码 +- 号码用完即弃 +- 价格低廉 +- **风险**: 容易被平台识别和封禁 +- **代表**: 传统虚拟号服务商 + +### 订阅制号码（推荐） +- 长期持有同一号码 +- 充值后可续期使用 +- **优势**: 更稳定可靠，不易被封 +- **代表**: [[PingMe]] + +## 使用注意事项 +1. **选择目标地区号码**: 如注册Claude需美国号码 +2. **避免一次性号码**: 易被识别导致账号风险 +3. **及时查收验证码**: 部分平台有时效限制 +4. **保持号码活跃**: 订阅制需定期充值保持 + +## 推荐平台 +| 平台 | 特点 | 最低充值 | +|------|------|---------| +| [[PingMe]] | 支持中文，订阅制 | 2美元 | +| SMS-Activate | 俄罗斯平台，号码多 | 1美元 | +| TextNow | 免费号码（质量较低） | 免费 | + +## 典型应用场景 +- 注册Claude、ChatGPT等海外AI服务 +- 注册Telegram等社交平台 +- 电商平台验证 +- 薅羊毛/多账号注册 + +## 与传统手机号对比 +| 特性 | 接码平台 | 传统手机号 | +|------|---------|-----------| +| 隐私 | ✅ 匿名 | ❌ 实名 | +| 成本 | 低（按次/月） | 正常月租 | +| 便捷性 | 即时获取 | 需购买 | +| 稳定性 | ⚠️ 一次性号不稳定 | ✅ 长期稳定 | + +## 相关概念 +- [[PingMe]] +- [[账号隔离]] +- [[指纹浏览器]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/concepts/故障转移.md b/wiki/concepts/故障转移.md new file mode 100644 index 00000000..99021eae --- /dev/null +++ b/wiki/concepts/故障转移.md @@ -0,0 +1,28 @@ +# 故障转移 + +## Definition +当主代理节点连接失败或响应超时时，自动切换到备用节点以保持网络通畅的机制。 + +## Definition (English) +An automatic mechanism that switches to a backup proxy node when the primary node fails or becomes unresponsive, ensuring continuous network connectivity. + +## How It Works +1. 插件持续监控所有可用节点的延迟和可用性 +2. 当主节点不可达时（超时/错误） +3. 自动选择延迟最低的备用节点 +4. 切换过程中对用户透明（理论上） + +## Components +- **健康检查**：定期探测节点状态 +- **节点池**：维护多个备用节点 +- **切换逻辑**：定义何时、从哪个切换到哪个 + +## Importance in 科学上网 +- 避免单点故障导致的断网 +- 保证重要业务（如视频会议）的连续性 +- 在高延迟节点恢复时自动回切 + +## Related +- [[MerlinClash插件]] — 支持故障转移的插件 +- [[策略组分流]] — 故障转移是分流策略的一部分 +- [[机场]] — 提供多个节点的节点池 diff --git a/wiki/concepts/时序数据库.md b/wiki/concepts/时序数据库.md new file mode 100644 index 00000000..a866dcd9 --- /dev/null +++ b/wiki/concepts/时序数据库.md @@ -0,0 +1,57 @@ +--- +title: "时序数据库" +type: concept +aliases: [Time Series Database, TSDB, 时序数据, 时间序列数据库] +tags: [database, monitoring, time-series, storage] +date: 2025-11-11 +--- + +# 时序数据库 + +## Overview +时序数据库（Time Series Database，TSDB）是一种专门为带时间戳的数据点序列设计的数据库类型，适用于监控指标、传感器数据、金融行情等场景。与传统关系型数据库相比，TSDB 针对高写入吞吐、时间范围查询、聚合分析做了专门优化，是现代可观测性系统的核心基础设施。 + +## Core Properties +- **时间戳主键**：每条记录以时间戳为核心标识 +- **高写入吞吐**：支持每秒百万级数据点写入 +- **时间范围查询**：高效的范围扫描和聚合 +- **数据降采样**：自动压缩历史数据（high-resolution → low-resolution） +- **保留策略**：按时间自动过期旧数据（Retention Policy） + +## Key Operations +| 操作 | 说明 | 示例 | +|------|------|------| +| 插入 | 写入带时间戳的数据点 | `metric{labels} value timestamp` | +| 查询 | 时间范围检索 | `WHERE time > t1 AND time < t2` | +| 聚合 | 按时间窗口聚合 | `rate(metric[5m])`、`avg_over_time(metric[1h])` | +| 降采样 | 降低历史数据精度 | 1s → 1m → 1h → 1d | +| 内插 | 估算缺失数据点 | 线性内插、Previous Forward Fill | + +## Data Model +``` +Metric Name: node_cpu_seconds_total +Labels: {cpu="0", host="server1", mode="user"} +Data Points: (timestamp=1700000000, value=1234.56), (timestamp=1700000015, value=1235.10), ... +``` + +## Leading TSDB Solutions +| 产品 | 特点 | 适用场景 | +|------|------|----------| +| [[Prometheus]] TSDB | 单实例设计，简约高效 | 单节点/小规模监控 | +| [[VictoriaMetrics]] | PromQL 兼容，长期存储 | 中小型集群 | +| InfluxDB | Telegraf 生态丰富 | IoT/传感器 | +| TimescaleDB | PostgreSQL 扩展 | 需要 SQL 的场景 | +| QuestDB | 高性能，SQL 接口 | 金融高频数据 | +| Thanos | Prometheus 长期存储 | 多租户/大规模 | +| Grafana Mimir | Grafana 官方后端 | 企业级监控 | + +## Related Entities +- [[Prometheus]] — 核心 TSDB 实现 +- [[VictoriaMetrics]] — Prometheus 兼容替代方案 + +## Related Concepts +- [[Exporter]] — TSDB 的数据来源 +- [[PromQL]] — TSDB 查询语言 +- [[Prometheus告警规则]] — 基于 TSDB 数据的告警 +- [[System Monitoring]] — 上游应用领域 +- [[Centralized Logging]] — 互补的可观测性数据（日志/追踪） diff --git a/wiki/concepts/永久挂载.md b/wiki/concepts/永久挂载.md new file mode 100644 index 00000000..5fab88a9 --- /dev/null +++ b/wiki/concepts/永久挂载.md @@ -0,0 +1,83 @@ +--- +title: "永久挂载" +tags: [linux, storage, network, ubuntu] +date: 2026-04-26 +--- + +# 永久挂载 (Persistent Mount) + +## Definition +永久挂载指在 Linux 系统启动时自动挂载文件系统（如 NFS、SMB、USB 等），通过配置文件实现开机后自动挂载，无需手动执行 mount 命令。 + +## Core Concept: /etc/fstab +`/etc/fstab`（Filesystem Table）是 Linux 系统用于定义文件系统挂载配置的核心文件，系统启动时由 `mount -a` 命令读取并自动挂载所有配置项。 + +## Format +``` + +``` + +## Key Parameters + +### NFS Permanent Mount Example +``` +192.168.3.17:/volume2/backup /mnt/nas_backup nfs defaults,timeo=900,retrans=5,_netdev 0 0 +``` + +| Parameter | Description | +|-----------|-------------| +| `defaults` | 使用默认挂载选项（rw, suid, dev, exec, auto, nouser, async） | +| `timeo=900` | 超时时间 90 秒（单位 1/10 秒），网络慢时避免频繁失败 | +| `retrans=5` | 超时后重试 5 次 | +| `_netdev` | **关键参数**：告知系统这是网络设备，等网络完全启动后才挂载 | + +## Critical: _netdev Parameter +`_netdev` 是 NFS/SMB 等网络文件系统挂载的**必备参数**： +- 防止系统启动时因网络未就绪而卡死 +- 确保 `Remote File Systems` 服务先启动完成 +- 与 `systemctl enable remote-fs.target` 配合使用 + +## Verification Steps +**⚠️ 永远不要直接重启测试！** + +```bash +# 1. 备份原文件 +sudo cp /etc/fstab /etc/fstab.bak + +# 2. 测试挂载（不重启） +sudo umount /mnt/nas_backup +sudo mount -a + +# 3. 验证 +df -h | grep nas_backup +``` + +## Common Issues + +### Issue 1: 重启后挂载失效 +**Cause**: `nfs-common` 服务启动慢于 `mount -a` + +**Solution**: +```bash +sudo systemctl enable remote-fs.target +``` + +### Issue 2: 挂载点写入本地磁盘 +**Cause**: NAS 掉线时挂载失败，但脚本仍写入本地目录 + +**Solution**: 在备份脚本中添加挂载点检查 +```bash +if ! mountpoint -q /mnt/nas_backup; then + echo "错误：NAS 未挂载，备份任务取消！" >> /var/log/rsync_backup.log + exit 1 +fi +``` + +## Related Concepts +- [[增量备份]] — 永久挂载为增量备份提供可靠的存储目标 +- [[NFS]] — 网络文件系统是永久挂载的典型应用 +- [[挂载点检查]] — 备份前的安全检查机制 + +## See Also +- [[Cron定时任务]] — 永久挂载后自动执行备份 +- [[进程管理]] — 网络断开时的进程控制 diff --git a/wiki/concepts/用户权限.md b/wiki/concepts/用户权限.md new file mode 100644 index 00000000..982097a2 --- /dev/null +++ b/wiki/concepts/用户权限.md @@ -0,0 +1,44 @@ +# 用户权限 + +## Concept Information +- **Type**: Concept +- **Status**: Active +- **Source**: [[mysql-mariadb-数据库详细信息]] + +## Definition +MariaDB/MySQL 使用 `username@host` 组合作为权限控制的基本单元，同一个用户名在不同主机来源下可以拥有完全不同的权限级别。 + +## Permission Model +| Host Pattern | Meaning | +|--------------|---------| +| `localhost` | 仅允许本机通过 socket 连接 | +| `127.0.0.1` | 仅允许本机通过 TCP/IP 连接 | +| `%` | 允许任意主机连接 | +| `192.168.1.%` | 允许指定网段连接 | +| `%.example.com` | 允许指定域名后缀连接 | + +## Common Example +```sql +-- 本地管理员（仅本机 socket） +CREATE USER 'root'@'localhost' IDENTIFIED BY 'password'; + +-- 远程访问用户（任意主机） +CREATE USER 'shenwei'@'%' IDENTIFIED BY '!Abcde12345'; +GRANT ALL PRIVILEGES ON *.* TO 'shenwei'@'%' WITH GRANT OPTION; + +-- 限制特定网段 +CREATE USER 'app'@'192.168.3.%' IDENTIFIED BY 'password'; +GRANT SELECT, INSERT, UPDATE ON mydb.* TO 'app'@'192.168.3.%'; +``` + +## Key Principles +1. **最小权限**：只授予应用程序所需的最小权限 +2. **来源隔离**：生产环境避免使用 `%` 通配符 +3. **权限分离**：不同用途使用不同账户 + +## Related Concepts +- [[Socket 登录]] — 本地认证方式 +- [[MariaDB]] — 用户权限配置示例 + +## Related Entities +- [[MariaDB]] — 权限配置实践 diff --git a/wiki/concepts/策略组分流.md b/wiki/concepts/策略组分流.md new file mode 100644 index 00000000..8c042ce9 --- /dev/null +++ b/wiki/concepts/策略组分流.md @@ -0,0 +1,33 @@ +# 策略组分流 + +## Definition +基于预定义的流量分类规则（按应用、地区、目标网站等），将不同类型的网络请求转发到不同代理节点的流量管理机制。 + +## Definition (English) +A traffic management mechanism that routes different types of network requests to different proxy nodes based on predefined classification rules (by application, region, target website, etc.). + +## How It Works +用户在MerlinClash等插件中配置策略组，定义以下规则： +1. **域名规则**：指定域名走哪个节点（如Netflix走台湾节点） +2. **应用规则**：指定应用走哪个节点（如YouTube走香港节点） +3. **地区规则**：按目标服务器地理位置选择节点 +4. **兜底规则**：没有匹配时使用默认策略 + +## Example Configuration +| 目标 | 策略 | +|------|------| +| Google | 自动选择（延迟最低） | +| Netflix | 台湾节点 | +| YouTube | 香港节点 | +| 国内网站 | 直连（不经过代理） | + +## Benefits +- **优化访问速度**：选择物理距离最近的节点 +- **解锁地区限制**：如使用香港节点解锁TVB +- **负载均衡**：分散流量到多个节点 +- **故障转移**：主节点不可用时自动切换 + +## Related +- [[MerlinClash插件]] — 策略组分流的主要实现平台 +- [[故障转移]] — 与策略组配合的可靠性机制 +- [[订阅机制]] — 节点配置来源 diff --git a/wiki/concepts/虚拟信用卡.md b/wiki/concepts/虚拟信用卡.md new file mode 100644 index 00000000..a7c5646e --- /dev/null +++ b/wiki/concepts/虚拟信用卡.md @@ -0,0 +1,61 @@ +--- +title: "虚拟信用卡" +type: concept +tags: [payment, fintech, cross-border] +date: 2025-12-31 +--- + +# 虚拟信用卡 + +## 定义 +虚拟信用卡是一种不依赖实体卡的线上信用支付工具，通过生成一次性或可重复使用的卡号，实现跨境支付、隐私保护等功能。 + +## 核心特点 +- **无需实体卡**: 线上即时开通 +- **一次性卡号**: 可设置单次使用，防止盗刷 +- **跨境支付**: 支持海外商家支付 +- **隐私保护**: 不暴露真实银行卡信息 + +## 典型用途 +- 订阅海外服务（Claude Pro、ChatGPT Plus等） +- 保护真实银行卡信息 +- 限制消费额度 +- 无法办理国际信用卡的用户 + +## 代表产品 +- [[WildCard]] — 支持支付宝，适合国内用户 +- Depay +- Privacy.com +- Revolut + +## 使用场景 +``` +国内用户 → WildCard充值 → 订阅Claude Pro + ↓ +WildCard(美国虚拟卡) → Anthropic支付系统 + ↓ +成功订阅 → 享受Pro服务 +``` + +## 与传统信用卡对比 +| 特性 | 虚拟信用卡 | 传统信用卡 | +|------|-----------|-----------| +| 开通速度 | 即时 | 数天至数周 | +| 跨境支付 | ✅ 直接支持 | ⚠️ 可能被拒 | +| 额度控制 | 灵活可调 | 固定额度 | +| 隐私保护 | ✅ 更强 | ❌ 信息暴露 | +| 费用 | 有开卡费/年费 | 通常无额外费用 | + +## 安全建议 +- 选择正规服务商 +- 设置合理的消费限额 +- 优先使用一次性卡号 +- 避免在不可信网站使用 + +## 相关概念 +- [[跨境支付]] +- [[WildCard]] +- [[Claude Pro]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/concepts/裸机恢复.md b/wiki/concepts/裸机恢复.md new file mode 100644 index 00000000..baf0c87d --- /dev/null +++ b/wiki/concepts/裸机恢复.md @@ -0,0 +1,36 @@ +--- +title: "裸机恢复" +tags: [backup, disaster-recovery, bare-metal] +date: 2026-04-28 +--- + +# 裸机恢复 (Bare Metal Recovery) + +## Definition +裸机恢复是指在磁盘完全损坏或更换新磁盘后，无需重新安装操作系统和应用程序，直接从预先创建的磁盘镜像文件中还原整个系统到可用状态的过程。目标是实现系统的"即时复活"，使系统在还原完成后立即可投入生产使用。 + +## Core Process +``` +1. 系统正常时 → 使用 Clonezilla savedisk 备份整个磁盘为镜像 +2. 磁盘损坏 → 更换新磁盘 +3. 从 Clonezilla 启动 U 盘启动 +4. 选择 restoredisk → 挂载镜像存储（NAS/外置硬盘）→ 选择目标磁盘 +5. 确认覆盖 → 等待还原完成 +6. 系统启动 → 即刻可用 +``` + +## Key Characteristics +- **完整还原**: 包括操作系统、应用、配置、数据 +- **即时可用**: 还原后无需额外配置 +- **镜像依赖**: 依赖提前创建的完整磁盘镜像（与增量备份互补） +- **目标多样性**: 支持本地磁盘、外置硬盘、NFS、SMB 等多种镜像存储位置 + +## Related Concepts +- [[全盘镜像备份]] — 裸机恢复的前置条件 +- [[Clonezilla]] — 裸机恢复的核心工具 +- [[Disaster-Recovery]] — 裸机恢复是灾备策略的重要组成部分 +- [[RTO]] — 裸机恢复时间是 RTO 的核心组成部分 +- [[增量备份]] — 互补方案（增量备份=文件级，裸机恢复=系统级） + +## Related Sources +- [[clonezilla对ubuntu-server进行全盘镜像备份]] diff --git a/wiki/concepts/订阅机制.md b/wiki/concepts/订阅机制.md new file mode 100644 index 00000000..35071349 --- /dev/null +++ b/wiki/concepts/订阅机制.md @@ -0,0 +1,36 @@ +# 订阅机制 + +## Definition +通过机场提供的订阅链接，自动获取和更新代理节点列表的技术方案，无需用户手动逐个配置节点。 + +## Definition (English) +A technical solution where proxy clients automatically fetch and update proxy node lists via subscription links provided by service providers, eliminating the need for manual node configuration. + +## How It Works +1. 用户在机场注册并购买套餐 +2. 机场提供订阅链接（URL格式） +3. 用户将订阅链接导入代理客户端/路由器插件 +4. 客户端定期（如每6小时）自动请求该URL +5. 服务器返回最新的节点列表（通常为Base64编码） +6. 客户端解析并更新本地节点配置 + +## Subscription Link Format +``` +https://example-airport.com/api/v1/client/subscribe?token=xxxx +``` +返回内容通常为Base64编码的代理配置文件。 + +## Auto-Update Features +- 定时自动更新（可设置间隔） +- 手动一键更新 +- 更新后自动应用新配置 + +## Benefits +- **免手动维护**：节点变更无需重新配置 +- **批量管理**：一次性导入数十个节点 +- **动态更新**：机场更换IP/端口后自动同步 + +## Related +- [[机场]] — 订阅链接的提供者 +- [[MerlinClash插件]] — 支持订阅机制的代理插件 +- [[科学上网]] — 订阅机制的应用场景 diff --git a/wiki/concepts/账号隔离.md b/wiki/concepts/账号隔离.md new file mode 100644 index 00000000..ad9a78c2 --- /dev/null +++ b/wiki/concepts/账号隔离.md @@ -0,0 +1,67 @@ +--- +title: "账号隔离" +type: concept +tags: [account-management, security, privacy] +date: 2025-12-31 +--- + +# 账号隔离 + +## 定义 +账号隔离是通过技术手段确保多个账号在平台看来彼此独立、不存在关联关系的管理策略。主要应用于跨境服务注册、多账号运营等场景。 + +## 关联风险 +平台检测账号关联的常见维度： +- **IP关联**: 同一IP注册/登录多个账号 +- **浏览器指纹关联**: 相同的浏览器环境特征 +- **支付信息关联**: 相同的信用卡/支付账户 +- **行为模式关联**: 相同的操作习惯、时间规律 +- **设备关联**: 相同的设备ID、硬件信息 + +## 隔离策略 + +### 1. IP隔离 +- 使用独立代理IP为每个账号服务 +- 确保IP纯净度（低风险评分） +- 避免使用数据中心IP（易被识别） + +### 2. 浏览器指纹隔离 +- 使用[[指纹浏览器]]创建独立环境 +- 每个环境配置独立的User Agent +- 配合独立代理IP使用 + +### 3. 支付隔离 +- 使用独立的支付方式 +- [[虚拟信用卡]]可提供一次性卡号 +- 避免共享支付账户 + +### 4. 手机号隔离 +- 使用独立手机号注册 +- 推荐[[接码平台]]（如[[PingMe]]）获取独立号码 + +## 隔离工具链 +``` +指纹浏览器(AdsPower) + ↓ +独立代理IP + IP纯净度检测 + ↓ +独立手机号(PingMe) + ↓ +独立支付方式(WildCard虚拟信用卡) +``` + +## 风险等级 +| 风险等级 | 特征 | 建议 | +|---------|------|------| +| 低风险 | IP纯净、多维度隔离 | 可正常使用 | +| 中等风险 | 部分维度关联 | 谨慎使用 | +| 高风险 | 明显关联特征 | 极可能封号 | + +## 相关概念 +- [[指纹浏览器]] +- [[IP纯净度]] +- [[虚拟信用卡]] +- [[接码平台]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/concepts/跨境支付.md b/wiki/concepts/跨境支付.md new file mode 100644 index 00000000..38860e79 --- /dev/null +++ b/wiki/concepts/跨境支付.md @@ -0,0 +1,78 @@ +--- +title: "跨境支付" +type: concept +tags: [payment, fintech, international] +date: 2025-12-31 +--- + +# 跨境支付 + +## 定义 +跨境支付是指在不同国家或地区之间进行的资金转移和支付行为，包括线上和线下多种形式。 + +## 常见挑战 + +### 国内用户面临的障碍 +1. **信用卡限制**: 国内信用卡无法直接支付海外商家 +2. **外汇管制**: 个人购汇限额和申报要求 +3. **支付验证**: 3D Secure验证失败 +4. **地址验证**:账单地址与IP所在地不匹配 + +## 解决方案 + +### 1. 虚拟信用卡 +- [[WildCard]] — 支持支付宝，适合国内用户 +- Depay +- 开通美国虚拟卡号 +- 可绕过地址验证问题 + +### 2. 第三方支付平台 +- PayPal（国际版） +- 朋友的信用卡代付 +- Payoneer +- Wise + +### 3. 加密货币支付 +- 少部分服务商接受BTC/ETH +- 需转换为稳定币更稳定 + +## 典型应用场景 +| 场景 | 支付方式 | 推荐方案 | +|------|---------|---------| +| Claude Pro订阅 | 月费20美元 | WildCard | +| ChatGPT Plus | 月费20美元 | WildCard | +| GitHub Copilot | 月费10美元 | WildCard | +| Midjourney | 月费10-30美元 | WildCard | + +## 支付流程（以Claude Pro为例） +``` +1. 注册WildCard账号（手机号验证） + ↓ +2. 支付宝充值USD到WildCard + ↓ +3. 获取虚拟信用卡信息 + ↓ +4. 在Claude网站绑定信用卡 + ↓ +5. 完成支付订阅 +``` + +## 费用考量 +- **虚拟卡开卡费**: 通常10-20美元 +- **月费/年费**: 部分平台收取 +- **充值手续费**: 支付宝充值通常无额外费用 +- **汇率**: 按实时汇率结算 + +## 安全建议 +- 选择正规服务商，避免跑路风险 +- 不要在不可信网站使用真实银行卡 +- 设置合理的消费限额 +- 定期检查账单，及时发现问题 + +## 相关概念 +- [[虚拟信用卡]] +- [[WildCard]] +- [[Claude Pro]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/concepts/软链接策略.md b/wiki/concepts/软链接策略.md new file mode 100644 index 00000000..1899c4cf --- /dev/null +++ b/wiki/concepts/软链接策略.md @@ -0,0 +1,120 @@ +# 软链接策略 + +> 使用符号链接（Symbolic Link）实现软件版本管理和无缝切换的最佳实践。 + +## Overview +软链接策略是一种软件版本管理技术，通过创建指向不同版本目录的符号链接，实现： +- 简化启动命令 +- 实现无缝版本升级 +- 避免配置文件中的硬编码路径 + +## Core Concept +``` +/opt/frp/ +├── frp_0.65.0_darwin_arm64/ # 实际安装目录 +├── frp_0.66.0_darwin_arm64/ # 新版本目录 +└── current -> frp_0.65.0_darwin_arm64/ # 软链接指向 current +``` + +## Why Use Symlinks? + +| 优势 | 说明 | +|------|------| +| 简化路径 | 启动命令使用 `/opt/frp/current/frpc` 而非长版本号路径 | +| 快速升级 | 只需修改软链接，无需更新配置或启动脚本 | +| 版本回滚 | 出现问题时快速切换回旧版本 | +| 保持兼容性 | 配置文件中使用稳定路径，升级不受影响 | + +## Implementation + +### 创建软链接 +```bash +# 创建指向特定版本的软链接 +ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current + +# 验证 +ls -la /opt/frp/current +# lrwxr-xr-x 1 user staff 35 Apr 14 10:00 /opt/frp/current -> frp_0.65.0_darwin_arm64 +``` + +### 升级版本 +```bash +# 1. 下载并解压新版本 +wget https://github.com/fatedier/frp/releases/download/v0.66.0/frp_0.66.0_darwin_arm64.tar.gz +tar -xzf frp_0.66.0_darwin_arm64.tar.gz + +# 2. 停止旧版本服务 +launchctl stop com.frpc.client +# 或 +pkill frpc + +# 3. 切换软链接 +ln -sfn /opt/frp/frp_0.66.0_darwin_arm64 /opt/frp/current + +# 4. 验证 +ls -la /opt/frp/current # 确认指向新版本 + +# 5. 启动服务 +launchctl start com.frpc.client +``` + +### 回滚版本 +```bash +# 停止服务 +launchctl stop com.frpc.client + +# 切换回旧版本 +ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current + +# 启动服务 +launchctl start com.frpc.client +``` + +## Launchd Integration +```xml +ProgramArguments + + /opt/frp/current/frpc + -c + /opt/frp/current/frpc.toml + +``` + +## Best Practices + +### Directory Structure +``` +/opt// +├── _v1.0.0/ +├── _v1.1.0/ +├── _v1.2.0/ +├── current -> _v1.2.0/ +└── configs/ # 可选：配置文件独立存放 + ├── v1.0.0.toml + ├── v1.1.0.toml + └── current.toml -> v1.2.0.toml +``` + +### Naming Convention +- 版本目录：`_v..__` +- 软链接名称：`current`（行业标准）或 `-latest` + +### Security Considerations +1. **保持链接目标存在**：删除旧版本前确保软链接已切换 +2. **使用绝对路径**：`ln -sfn` 使用绝对路径避免相对路径问题 +3. **验证后再启动**：切换后验证软链接，再启动服务 + +## Use Cases +- **FRP**：版本升级无需修改 launchd plist +- **Docker**：使用 `:latest` 标签的软链接等价物 +- **Node.js**：nvm 使用软链接管理多版本 +- **Python**：pyenv 使用软链接切换版本 + +## Related Concepts +- [[frp]] — 软链接策略的典型应用场景 +- [[launchd]] — 使用软链接路径的服务管理 +- [[内网穿透]] — 需要版本管理的服务 + +## References +- `man ln` +- `man readlink` diff --git a/wiki/concepts/过渡固件.md b/wiki/concepts/过渡固件.md new file mode 100644 index 00000000..f187cb24 --- /dev/null +++ b/wiki/concepts/过渡固件.md @@ -0,0 +1,28 @@ +# 过渡固件 + +## Definition +用于引导路由器从原厂固件状态进入可刷入目标固件状态的中间固件文件。 + +## Definition (English) +A transitional firmware file that bridges the router's original factory firmware to the target third-party firmware state. + +## Formats +- `.chk` — 网件路由器专用过渡固件格式 +- `.w` — 梅林固件正式版本格式 + +## Why It's Needed +网件路由器的Bootloader不支持直接从原厂固件跳转到梅林固件，需要.chk过渡固件作为中间状态来完成这一转换。 + +## Process Flow +``` +原厂固件 → .chk过渡固件 → .w梅林固件 +``` + +## Common Mistakes +❌ **直接刷.w固件** → 会导致刷机失败 +✅ **必须先刷.chk** → 再刷.w + +## Related +- [[固件刷入]] — 过渡固件的应用场景 +- [[梅林固件]] — 过渡的目标固件 +- [[网件RAX50]] — 需要过渡固件的路由器 diff --git a/wiki/concepts/进程管理.md b/wiki/concepts/进程管理.md new file mode 100644 index 00000000..0f396fbf --- /dev/null +++ b/wiki/concepts/进程管理.md @@ -0,0 +1,111 @@ +--- +title: "进程管理" +tags: [linux, process, backup, ubuntu] +date: 2026-04-26 +--- + +# 进程管理 (Process Management) + +## Definition +进程管理涵盖 Linux 系统中进程的创建、监控、控制和终止。在备份场景下，进程管理主要指如何安全地启动、监控和停止 rsync 备份进程。 + +## Starting Background Processes + +### nohup (No Hang Up) +防止终端关闭导致进程被 SIGHUP 信号终止： +```bash +sudo nohup /usr/local/bin/rsync_backup.sh > /dev/null 2>&1 & +``` +- `nohup`: 忽略挂起信号 +- `> /dev/null 2>&1`: 重定向输出到空设备 +- `&`: 后台运行 + +### screen / tmux (推荐) +创建持久化终端会话： +```bash +# 创建新会话 +screen -S backup + +# 运行脚本 +sudo /usr/local/bin/rsync_backup.sh + +# 脱离会话 (继续运行) +Ctrl + A + D + +# 恢复会话 +screen -r backup +``` + +**tmux 命令相同**，将 `screen` 替换为 `tmux`。 + +## Stopping Processes + +### SIGTERM vs SIGKILL + +| Signal | Command | Behavior | Use Case | +|--------|---------|----------|----------| +| SIGTERM (15) | `killall rsync` | 优雅终止，允许进程完成当前写入并清理 | **首选**，防止数据损坏 | +| SIGKILL (9) | `killall -9 rsync` | 强制立即终止，无法清理 | 仅在进程卡死时使用 | + +### Process Management Commands +```bash +# 查看 rsync 进程 +ps aux | grep rsync + +# 优雅停止所有 rsync 进程 +sudo killall rsync + +# 强制杀死（谨慎使用） +sudo killall -9 rsync + +# 通过脚本名称停止 +sudo pkill -f rsync_backup.sh +``` + +## Lock File Pattern +防止重复执行同一备份任务： +```bash +LOCKFILE="/tmp/rsync_backup.lock" + +# 检查锁文件是否存在且进程存活 +if [ -e ${LOCKFILE} ] && kill -0 `cat ${LOCKFILE}`; then + echo "备份任务已在运行中，跳过本次执行。" + exit +fi + +# 创建锁文件（写入当前进程 PID） +echo $$ > ${LOCKFILE} + +# 脚本结束时清理锁文件 +trap "rm -f ${LOCKFILE}" EXIT +``` + +## Signal Handling +- `SIGHUP (1)`: 终端关闭，nohup 可屏蔽 +- `SIGINT (2)`: Ctrl+C 中断 +- `SIGTERM (15)`: 优雅终止请求 +- `SIGKILL (9)`: 强制终止（不可捕获） + +## Common Issues + +### rsync Error Code 20 +表示进程被手动中断（SIGINT/SIGTERM）： +```bash +# 使用 nohup 避免此问题 +sudo nohup /usr/local/bin/rsync_backup.sh > /dev/null 2>&1 & +``` + +### Temporary Files Residue +强行停止 rsync 后，目标目录可能残留 `.` 开头的临时文件： +```bash +# 清理残留临时文件（确保无 rsync 进程运行） +sudo find /mnt/nas_backup/ -name ".*" -type f -delete +``` + +## Related Concepts +- [[增量备份]] — 进程管理确保备份任务安全执行 +- [[Cron定时任务]] — 后台进程由 Cron 自动调度 +- [[挂载点检查]] — 进程执行前的安全验证 + +## See Also +- [[永久挂载]] — 网络存储与进程执行的关系 diff --git a/wiki/entities/AWS-CloudFormation-StackSets.md b/wiki/entities/AWS-CloudFormation-StackSets.md new file mode 100644 index 00000000..d9a8cc93 --- /dev/null +++ b/wiki/entities/AWS-CloudFormation-StackSets.md @@ -0,0 +1,39 @@ +--- +title: AWS CloudFormation StackSets +type: entity +tags: [AWS, IaC, Multi-Account, Deployment] +date: 2025-10-24 +--- + +## Overview +**AWS CloudFormation StackSets** 是 AWS 原生的跨多个 AWS 账户和区域部署和管理 CloudFormation 堆栈的服务。StackSets 扩展了 CloudFormation 的能力，使组织能够在整个 AWS Organization 中一致地部署基础设施，同时保持集中管理和治理。 + +## Key Capabilities +- **跨账户/跨区域部署**：单次操作同时在多个账户和区域部署 +- **自动部署（Auto-Deployment）**：新增账户加入组织时自动部署预设 StackSet +- **并行区域容错**：配置并发部署区域数量和容错设置 +- **操作偏好设置**：定义并发限制、容错百分比等操作级参数 + +## Architecture Components +- **Stack Set**：定义要部署的 CloudFormation 模板和参数 +- **Stack Instances**：Stack Set 在特定账户/区域的实例 +- **StackSet Operations**：部署、更新、删除操作的历史记录 + +## Related Concepts +- [[Multi-Account Deployment]]：StackSets 是多账户部署的核心工具 +- [[Infrastructure as Code]]：StackSets 扩展了 IaC 的多账户场景 +- [[StackSets Deployment Visibility]]：StackSets 部署可观测性是该服务的核心运营挑战 +- [[AWS Organizations]]：StackSets 依赖 Organizations 提供账户层级结构 +- [[Landing Zone Architecture]]：Landing Zone 推荐使用 StackSets 实现跨账户资源部署 +- [[GitOps]]：StackSets 可与 GitOps 工作流集成实现声明式部署 +- [[AWS]]（entity）：StackSets 是 AWS IaC 生态的核心成员 + +## Monitoring Integration +StackSets 部署通过 EventBridge 事件与 CloudWatch Logs 集成： +- EventBridge Rules 捕获 StackSets 操作事件 +- CloudWatch Logs Insights 提供跨账户部署状态查询 +- 详见 [[StackSets Deployment Visibility]] + +## Sources +- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]] +- AWS CloudFormation StackSets 官方文档 diff --git a/wiki/entities/AWS-Organizations.md b/wiki/entities/AWS-Organizations.md new file mode 100644 index 00000000..1ca8c469 --- /dev/null +++ b/wiki/entities/AWS-Organizations.md @@ -0,0 +1,46 @@ +--- +title: AWS Organizations +type: entity +tags: [AWS, Multi-Account, Security, Governance] +date: 2025-10-24 +--- + +## Overview +**AWS Organizations** 是 AWS 的账户管理服务，使组织能够创建和管理多个 AWS 账户，实现集中化的安全策略、成本管理和运维治理。AWS Organizations 是 AWS 多账户策略的基础设施，也是 CloudFormation StackSets 跨账户部署的前提条件。 + +## Key Capabilities +- **Organization**：组织根节点，管理整个组织的策略和成员 +- **Organizational Units (OUs)**：组织单元，分组管理多个账户 +- **Member Accounts**：成员账户，受组织策略约束的工作负载账户 +- **Management Account**：管理账户，组织的管理平面，承载集中监控和计费 +- **Service Control Policies (SCPs)**：服务控制策略，定义 OU/账户级别的权限边界 +- **Trusted Access**：受信任访问，允许 AWS 服务在成员账户中执行操作 + +## In This Solution +AWS Organizations 在多账户 CloudFormation StackSets 监控方案中的角色： +1. **账户层级结构**：提供管理账户和成员账户的层级关系 +2. **OU 范围界定**：StackSets 通过 OU ID 指定部署范围，一次性部署 EventBridge 规则到所有成员账户 +3. **Organization ID**：用于配置跨账户 IAM 权限 +4. **Trusted Access**：必须启用 CloudFormation StackSets 的受信任访问才能跨账户操作 + +## Prerequisites for StackSets +- AWS Organization with Management Account +- Member Accounts under OU(s) +- Trusted Access enabled for CloudFormation StackSets +- IAM permissions to create StackSets from Management Account + +## Related Concepts +- [[Multi-Account Deployment]]：Organizations 提供多账户部署的账户基础设施 +- [[Cross-Account Monitoring]]：Organizations 支撑跨账户监控的权限和账户模型 +- [[Landing Zone Architecture]]：AWS Landing Zone 架构基于 Organizations 构建 +- [[AWS CloudFormation StackSets]]：依赖 Organizations 提供账户层级和受信任访问 +- [[Centralized Logging]]：Organizations 支撑集中日志的账户范围配置 +- [[DevOps Culture]]：Organizations 的 SCPs 是 DevSecOps 治理的基础 + +## Related Entities +- [[AWS]]（entity）：Organizations 是 AWS 账户管理服务的核心成员 +- [[AWS CloudFormation StackSets]]：依赖 Organizations 的账户层级结构 + +## Sources +- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]] +- AWS Organizations 官方文档 diff --git a/wiki/entities/AWS.md b/wiki/entities/AWS.md index 25b11c8c..a5e04a04 100644 --- a/wiki/entities/AWS.md +++ b/wiki/entities/AWS.md @@ -14,13 +14,17 @@ AWS is one of the three major public cloud providers (alongside Azure and Google ## Key Services Referenced | Category | Services | -|----------|----------| +|---------|----------| | Compute | EC2, Lambda | | Storage | S3, EBS | | Database | RDS, DynamoDB, Aurora | | AI/ML | SageMaker, Bedrock | | Analytics | Redshift, Athena | | Networking | VPC, Route 53, CloudFront | +| IaC & Deployment | CloudFormation, **CloudFormation StackSets** | +| Observability | **EventBridge**, **CloudWatch Logs**, CloudWatch Logs Insights, CloudWatch Alarms | +| Security & Identity | **KMS**, IAM, CloudTrail, Security Hub | +| Organization | **AWS Organizations** | ## Multi-Cloud Context diff --git a/wiki/entities/Acronis.md b/wiki/entities/Acronis.md new file mode 100644 index 00000000..59657df9 --- /dev/null +++ b/wiki/entities/Acronis.md @@ -0,0 +1,80 @@ +--- +title: "Acronis" +type: entity +aliases: [Acronis Cyber Protect] +tags: [cloud, disaster-recovery, backup, security, enterprise, infrastructure] +date: 2026-04-25 +--- + +# Acronis + +**Acronis** 是一个融合数据保护和网络安全的一体化平台，提供跨区域复制、备份和灾难恢复能力，是传统灾备工具的代表。 + +## Overview + +Acronis 提供： + +- **跨区域复制**：异地数据复制 +- **备份解决方案**：文件、系统、虚拟机备份 +- **灾难恢复**：BC/DR 规划工具 +- **网络安全**：防恶意软件、防勒索 +- **云原生集成**：AWS、Azure、GCP + +## 定位：传统灾备 + 安全 + +Acronis 与 [[Veeam]] 类似，代表传统灾备思路，但其融合了网络安全功能（Acronis Cyber Protect）。 + +| 维度 | Acronis（传统） | [[Feature Flag]]（现代） | +|------|-----------------|------------------------| +| 保护对象 | 基础设施、数据 | 代码、功能、部署 | +| 故障类型 | 硬件故障、勒索软件 | 代码变更、Bug | +| RTO | 小时级（从备份恢复） | 秒级（配置变更） | +| 故障频率 | 低 | 高（每周可能发生） | +| 安全集成 | 有（Acronis Cyber Protect） | 无（专注于代码层） | + +## 与 [[RTO]]/[[RPO]] 的关系 + +Acronis 优化的是基础设施级别的 RTO 和 RPO： + +| 场景 | RTO | RPO | 说明 | +|------|-----|-----|------| +| 从 Acronis 备份恢复 | 小时级 | 取决于备份频率 | 需要重建基础设施 | +| 跨区域复制恢复 | 分钟级 | 取决于复制频率 | 数据已预复制到异地 | +| Acronis 即时恢复 | 分钟级 | 小时级 | 仍然需要恢复数据 | + +## 典型部署场景 + +- **硬件故障**：服务器损坏后的快速恢复 +- **勒索软件防护**：Acronis Cyber Protect 提供勒索软件防御和恢复 +- **跨数据中心灾备**：异地数据复制 +- **合规数据保留**：长期归档和保留 + +## 竞品 + +| 工具 | 定位 | +|------|------| +| Acronis | 数据保护 + 网络安全 | +| [[Veeam]] | 企业级虚拟机备份 | +| Rubrik | 云原生数据保护 | +| Commvault | 企业数据管理 | + +## 局限性 + +与 Veeam 类似，Acronis 无法解决**软件层面的问题**： + +- 无法防止 Bug 部署 +- 无法实现 Feature Flag 级别的快速回滚 +- 无法支持渐进放量 +- 灾备触发频率低，无法应对日常代码变更风险 + +## Related Concepts + +- [[Disaster Recovery]] — Acronis 是传统灾备工具 +- [[RTO]] — Acronis 优化基础设施级 RTO +- [[RPO]] — Acronis 优化数据保护级 RPO +- [[Veeam]] — 竞品灾备工具 +- [[LaunchDarkly]] — 代表现代软件层灾备方案 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/entities/AdsPower.md b/wiki/entities/AdsPower.md new file mode 100644 index 00000000..0fc50a45 --- /dev/null +++ b/wiki/entities/AdsPower.md @@ -0,0 +1,33 @@ +--- +title: "AdsPower" +type: entity +tags: [fingerprint-browser, tool, account-management] +date: 2025-12-31 +--- + +# AdsPower + +## 基本信息 +- **类型**: 工具/产品 +- **官网**: https://share.adspower.net +- **用途**: 指纹浏览器，多账号管理 + +## 功能特性 +- **浏览器指纹隔离**: 模拟不同设备和网络环境 +- **多账号管理**: 每个浏览器环境相互隔离，防止账号关联 +- **免费版限制**: 最多5个浏览器环境 +- **代理配置**: 支持Socks5代理配置 +- **谷歌授权登录**: 支持 + +## Aliases +- 无 + +## 相关页面 +- [[指纹浏览器]] +- [[IP纯净度]] +- [[PingMe]] +- [[WildCard]] +- [[Claude Pro]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/entities/Agentic-AI.md b/wiki/entities/Agentic-AI.md new file mode 100644 index 00000000..6a6ef54d --- /dev/null +++ b/wiki/entities/Agentic-AI.md @@ -0,0 +1,94 @@ +--- +title: "Agentic AI" +type: entity +tags: + - ai + - devops + - automation +created: 2026-04-25 +--- + +# Agentic AI + +## Definition + +Agentic AI (Agentic Artificial Intelligence) 是具有**自主决策和任务执行能力**的 AI 系统，能够感知环境、规划行动、执行任务并从反馈中学习。与传统 AI 不同，Agentic AI 不仅响应查询，而是能够自主完成复杂的多步骤工作流。 + +## Aliases + +- Autonomous AI +- AI Agents +- AI Automation +- Intelligent Automation + +## Core Capabilities + +| Capability | Description | Example | +|------------|-------------|---------| +| **感知 (Perceive)** | 感知环境和数据 | 监控云指标、日志分析 | +| **规划 (Plan)** | 制定行动策略 | 部署策略选择、回滚决策 | +| **执行 (Act)** | 自主执行任务 | 自动修复、配置变更 | +| **学习 (Learn)** | 从反馈中优化 | 历史模式学习、预测性维护 | + +## Agentic AI vs Traditional AI + +| Dimension | Traditional AI | Agentic AI | +|-----------|---------------|------------| +| Interaction | Request-Response | Goal-Directed | +| Autonomy | Low | High | +| Task Duration | Single Turn | Multi-Step Workflow | +| Human Oversight | Required | Minimal (Guardrails) | +| Adaptability | Static | Dynamic | + +## Applications in Cloud DevOps + +Agentic AI 在 Cloud DevOps 中的 7 大应用领域： + +1. **[[Self-Healing Systems]]** — 自动检测异常并修复 +2. **[[Root Cause Analysis (RCA)]]** — AI 驱动的根因分析 +3. **[[Predictive Maintenance]]** — 基于历史模式预防故障 +4. **[[Deployment Automation]]** — AI 作为 Release Manager +5. **[[Rightsizing]]** — 智能成本优化 +6. **[[Automated Security Audit]]** — 持续安全态势管理 +7. **[[AI ChatOps]]** — 自然语言运维协作 + +## Architecture Pattern + +``` +Agentic AI System: +┌─────────────────────────────────────────────────┐ +│ Agentic AI │ +├─────────────────────────────────────────────────┤ +│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ +│ │感知层 │ │规划层 │ │执行层 │ │ +│ │Sensors │ │Planner │ │Executor │ │ +│ └────┬────┘ └────┬────┘ └────┬────┘ │ +│ │ │ │ │ +│ ┌────┴────────────┴────────────┴────┐ │ +│ │ Tool Integration │ │ +│ │ (CloudWatch, IAM, K8s, etc.) │ │ +│ └──────────────────────────────────┘ │ +└─────────────────────────────────────────────────┘ +``` + +## Related Concepts + +- [[Self-Healing Systems]] +- [[Root Cause Analysis (RCA)]] +- [[Predictive Maintenance]] +- [[Deployment Automation]] +- [[Rightsizing]] +- [[Automated Security Audit]] +- [[AI ChatOps]] +- [[What-If Simulation]] +- [[AIOps]] + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] + +## Related Entities + +- [[Kubernetes]] — 主要管理和修复目标 +- [[Terraform]] — IaC 审查对象 +- [[CloudWatch]] — 监控数据来源 diff --git a/wiki/entities/Alertmanager.md b/wiki/entities/Alertmanager.md new file mode 100644 index 00000000..2307ff61 --- /dev/null +++ b/wiki/entities/Alertmanager.md @@ -0,0 +1,75 @@ +--- +title: "Alertmanager" +type: entity +aliases: [Prometheus Alertmanager, Alertmanager OSS] +tags: [alerting, prometheus, notification, devops, observability] +date: 2025-11-11 +--- + +# Alertmanager + +## Overview +Alertmanager 是 Prometheus 生态系统中的告警分发和路由组件。当 Prometheus 的告警规则触发时，告警被发送给 Alertmanager，由 Alertmanager 负责抑制（inhibition）、分组（grouping）、静默（silencing）和路由（routing）到最终的通知通道（邮件、Slack、PagerDuty、WeChat 等）。 + +## Key Characteristics +- **告警分组**：将相似告警合并为一条通知，避免告警风暴 +- **抑制机制**：当一个严重告警触发时，自动抑制相关的次要告警 +- **静默规则**：基于时间窗口的告警静默，支持重复告警抑制 +- **多通道路由**：邮件、Slack、WeChat、Telegram、PagerDuty、Webhook +- **重复间隔**：未解决的告警按可配置间隔重复发送 + +## Prometheus Configuration +```yaml +# prometheus.yml +alerting: + alertmanagers: + - static_configs: + - targets: ['alertmanager:9093'] +``` + +## Alertmanager Configuration +```yaml +# alertmanager/config.yml +global: + resolve_timeout: 5m + +route: + receiver: default + group_wait: 10s # 新告警等待 10s 再发送（收集同组告警） + group_interval: 5m # 告警组更新间隔 + repeat_interval: 3h # 重复告警间隔 + +receivers: + - name: default + email_configs: + - to: "youremail@example.com" + from: "monitor@example.com" + smarthost: "smtp.example.com:587" + auth_username: "monitor@example.com" + auth_password: "yourpassword" + # Slack 配置示例 + slack_configs: + - api_url: 'https://hooks.slack.com/services/xxx' + channel: '#alerts' +``` + +## Alertmanager vs Grafana Alerting +| 维度 | Alertmanager | Grafana Alerting | +|------|-------------|-----------------| +| 数据源 | Prometheus 原生 | 多数据源 | +| 告警规则 | Prometheus YAML | Grafana UI / YAML | +| 通知通道 | 原生多通道 | 原生 + 插件扩展 | +| 告警历史 | 需额外存储 | 内置告警历史 | +| 适用场景 | 标准化告警 | 仪表盘联动告警 | + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Prometheus]] — 告警规则源和发送方 +- [[Grafana]] — 可替代 Prometheus Alerting 的告警方案 + +## Related Concepts +- [[Prometheus告警规则]] — 告警条件定义 +- [[PromQL]] — 告警触发条件语言 +- [[System Monitoring]] — 上游应用领域 diff --git a/wiki/entities/Amazon-CloudWatch-Logs.md b/wiki/entities/Amazon-CloudWatch-Logs.md new file mode 100644 index 00000000..c6471fdc --- /dev/null +++ b/wiki/entities/Amazon-CloudWatch-Logs.md @@ -0,0 +1,53 @@ +--- +title: Amazon CloudWatch Logs +type: entity +tags: [AWS, Observability, Logging, CloudOps] +date: 2025-10-24 +--- + +## Overview +**Amazon CloudWatch Logs** 是 AWS 的监控日志服务，用于监控、存储和访问来自 AWS 资源、应用程序和服务的日志。本方案中 central-cloudformation-logs Log Group 作为所有账户 CloudFormation 事件的集中存储。 + +## Key Capabilities +- **Log Groups**：日志组，定义日志流的保留、加密和监控设置 +- **Log Streams**：日志流，来自同一来源的日志序列 +- **CloudWatch Logs Insights**：交互式日志分析和查询服务 +- **Metric Filters**：从日志中提取指标用于 CloudWatch Alarms +- **Subscription Filters**：实时流式日志到 Kinesis/EventBridge/Lambda + +## In This Solution +CloudWatch Logs 在多账户 CloudFormation StackSets 监控方案中的角色： +- **central-cloudformation-logs**：中心 Log Group，存储所有成员账户的 CloudFormation 事件 +- **加密**：使用客户管理的 AWS KMS 密钥加密日志 +- **查询**：CloudWatch Logs Insights 支持跨账户、跨区域的日志分析 + +## Log Group: central-cloudformation-logs +- **Purpose**：聚合所有 AWS 账户的 CloudFormation 部署事件 +- **Encryption**：客户托管 KMS 密钥（encryption at rest） +- **Retention**：可配置保留期（本方案未指定具体值） +- **Access**：管理账户可访问，成员账户通过 EventBridge 写入 + +## CloudWatch Logs Insights 查询 +```sql +fields @timestamp, account, region +| parse @message /"resource-type":"(?[^"]+)"/ +| parse @message /"status":"(?[^"]+)"/ +| parse @message /"logical-resource-id":"(?[^"]+)"/ +| sort @timestamp desc +``` + +## Related Concepts +- [[Centralized Logging]]：CloudWatch Logs 是 AWS 集中日志存储的核心 +- [[StackSets Deployment Visibility]]：CloudWatch Logs 存储 StackSets 部署事件 +- [[Cross-Account Monitoring]]：CloudWatch Logs Insights 支持跨账户查询 +- [[Cloud Service Delivery]]：CloudWatch Logs 是云服务交付可观测性的基础设施 +- [[APM]]（Application Performance Monitoring）：CloudWatch Logs 与 CloudWatch Metrics/Dashboards 共同构成 APM 能力 + +## Related Entities +- [[AWS CloudFormation StackSets]]：CloudWatch Logs 存储其部署事件 +- [[Amazon EventBridge]]：EventBridge 将事件路由到 CloudWatch Logs +- [[AWS]]（entity）：CloudWatch Logs 是 AWS 监控服务家族的核心成员 + +## Sources +- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]] +- AWS CloudWatch Logs 官方文档 diff --git a/wiki/entities/Amazon-EventBridge.md b/wiki/entities/Amazon-EventBridge.md new file mode 100644 index 00000000..3adddf55 --- /dev/null +++ b/wiki/entities/Amazon-EventBridge.md @@ -0,0 +1,47 @@ +--- +title: Amazon EventBridge +type: entity +tags: [AWS, Event-Driven, Serverless, Observability] +date: 2025-10-24 +--- + +## Overview +**Amazon EventBridge** 是 AWS 的无服务器事件总线服务，用于构建事件驱动的架构。它可以接收来自 AWS 服务、SaaS 应用程序和自定义应用程序的事件，并根据定义的规则路由到目标。本方案中 EventBridge 作为跨账户事件转发的核心组件。 + +## Key Capabilities +- **Event Bus**：默认事件总线和自定义事件总线 +- **Event Rules**：基于事件模式匹配捕获特定事件 +- **Cross-Account Event Routing**：跨账户事件转发（该方案的核心功能） +- **Event Filtering**：基于内容的事件过滤 +- **Schema Registry**：事件模式注册和管理 + +## In This Solution +EventBridge 在多账户 CloudFormation StackSets 监控方案中的角色： +1. **事件捕获**：在每个成员账户部署 EventBridge Rules，捕获 CloudFormation 事件 +2. **跨账户转发**：通过 Event Bus 的跨账户访问策略，将事件转发到管理账户的 Custom Event Bus +3. **路由到 CloudWatch**：管理账户 Event Bus 将事件路由到 central-cloudformation-logs Log Group + +## Event Flow +``` +Member Account: CloudFormation event + → EventBridge Rule (pattern match) + → Event Bus (custom, member account) + → [Cross-account permission via IAM] + → Event Bus (custom, management account) + → CloudWatch Logs (central-cloudformation-logs) +``` + +## Related Concepts +- [[Cross-Account Monitoring]]：EventBridge 是跨账户监控的核心事件路由机制 +- [[Centralized Logging]]：EventBridge 将事件路由到 CloudWatch Logs 进行集中存储 +- [[Event-Driven Architecture]]：EventBridge 是 AWS 事件驱动架构的基础设施 +- [[AWS]]（entity）：EventBridge 是 AWS 无服务器服务家族的重要成员 +- [[Amazon CloudWatch Logs]]：EventBridge 将事件发送到 CloudWatch Logs + +## Related Entities +- [[AWS CloudFormation StackSets]]：EventBridge 监控的目标服务 +- [[AWS Organizations]]：提供跨账户权限的基础设施 + +## Sources +- [[sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md]] +- AWS EventBridge 官方文档 diff --git a/wiki/entities/BMC.md b/wiki/entities/BMC.md new file mode 100644 index 00000000..391b31e3 --- /dev/null +++ b/wiki/entities/BMC.md @@ -0,0 +1,52 @@ +--- +title: BMC +--- + +# BMC + +**BMC**（BMC Software, Inc.）是一家全球企业IT管理解决方案提供商，专注于帮助企业自动化关键应用、系统和服务，以充分利用云、数据和新兴AI技术。 + +## About + +BMC 成立于1980年，总部位于美国德克萨斯州休斯顿，是企业软件领域的老牌厂商。其产品组合涵盖： + +- **BMC Helix**：AI驱动的IT运维平台，整合了AIOps、可观测性和服务管理 +- **BMC Control-M**：企业级工作负载自动化 +- **BMC AMI**：大型机和存储管理解决方案 +- **BMC Discovery**：自动发现和依赖关系映射 + +## Key Facts + +| 项目 | 描述 | +|------|------| +| **成立年份** | 1980年 | +| **总部** | 美国德克萨斯州休斯顿 | +| **核心业务** | 企业IT管理、运维自动化、AIOps | +| **目标客户** | 全球《财富》500强企业 | +| **标志性产品** | BMC Helix、Control-M、AMI | +| **市场定位** | 企业级ITOM/AIOps领导者 | + +## BMC in the Wiki + +BMC 是本文档库中以下文章的来源： + +- [[Public vs Private vs Hybrid Cloud Differences Explained|sources/public-vs-private-vs-hybrid-cloud-differences-explained]] — BMC Blog 关于三种云部署模型的对比分析 + +## BMC Helix + +BMC Helix 是 BMC 的旗舰AI运维平台： + +- **AIOps**：利用机器学习进行事件关联和异常检测 +- **可观测性**：统一的指标、日志和追踪 +- **服务管理**：ITIL兼容的服务台和事件管理 +- **自助服务门户**：最终用户自助服务 + +## Related Entities + +- [[Cloud Computing]] — 云计算基础（本文档来源文章主题） +- [[BMC Helix]] — BMC AI运维平台 + +## See Also + +- [BMC官网](https://www.bmc.com) +- [BMC Helix](https://www.bmc.com/products/brands/bmc-helix.html) diff --git a/wiki/entities/Claude-Pro.md b/wiki/entities/Claude-Pro.md new file mode 100644 index 00000000..f4bb8175 --- /dev/null +++ b/wiki/entities/Claude-Pro.md @@ -0,0 +1,37 @@ +--- +title: "Claude Pro" +type: entity +tags: [ai-service, subscription, anthropic] +date: 2025-12-31 +--- + +# Claude Pro + +## 基本信息 +- **类型**: AI服务/产品 +- **提供方**: Anthropic +- **官网**: https://claude.ai +- **月费**: 20美元 +- **支付方式**: 需要海外信用卡 + +## 功能特性 +- **访问Claude 3.5 Sonnet**: 更高性能的语言模型 +- **优先访问权**: 在高峰时段享受优先访问 +- **早期功能体验**: 优先体验新功能 + +## 订阅挑战（中国用户） +- 国内信用卡无法直接支付 +- 需要虚拟信用卡（如WildCard） +- 需要美国区手机号验证 +- 需要稳定的美国IP地址 + +## 相关页面 +- [[Claude]] +- [[WildCard]] +- [[AdsPower]] +- [[PingMe]] +- [[指纹浏览器]] +- [[虚拟信用卡]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/entities/Clonezilla.md b/wiki/entities/Clonezilla.md new file mode 100644 index 00000000..41624c5b --- /dev/null +++ b/wiki/entities/Clonezilla.md @@ -0,0 +1,64 @@ +--- +title: "Clonezilla" +tags: [backup, opensource, disk-imaging, dr] +date: 2026-04-28 +--- + +# Clonezilla (再生龙) + +## Aliases +- Clonezilla +- 再生龙 + +## Definition +Clonezilla 是一款开源的磁盘镜像/克隆工具，类似于 Norton Ghost，提供完整的系统级备份与还原功能。支持将整个磁盘或单个分区备份为镜像文件，存储到本地磁盘、NFS、SMB、SFTP 等多种目标位置。 + +## Core Capabilities +- **savedisk**: 将整个磁盘备份为镜像文件 +- **saveparts**: 仅备份指定分区 +- **restoredisk**: 从镜像还原整个磁盘 +- **restoreparts**: 从镜像还原指定分区 +- **device-image 模式**: 将磁盘映射为镜像文件存储（区别于直接磁盘对磁盘克隆） + +## Key Features +| 特性 | 说明 | +|------|------| +| 备份介质 | 本地磁盘、外置硬盘、NFS、SMB、SFTP、SSH | +| 压缩选项 | -z1p (高压缩率), -z2p, -z3p, -z4p | +| 文件系统支持 | ext2/3/4, NTFS, FAT, HFS+, XFS, Btrfs 等 | +| 分区表支持 | MBR 和 GPT | +| 模式 | Beginner（初学者）/ Expert（专家） | +| 启动介质 | Live CD, Live USB, PXE 网络启动 | + +## Backup Workflow +``` +1. 制作 Clonezilla 启动 U 盘 (Rufus ISO 模式) +2. 从 U 盘启动源机器，进入 Clonezilla Live +3. 选择 device-image 模式 +4. 挂载 NAS/外置硬盘作为备份目标 +5. 选择 savedisk → 选择源磁盘 → 配置参数 +6. 等待镜像生成 +``` + +## Restore Workflow +``` +1. 从 U 盘启动目标机器（或原机器） +2. 进入 Clonezilla，选择 device-image 模式 +3. 挂载存储镜像的 NAS/外置硬盘 +4. 选择 restoredisk → 选择镜像文件 → 选择目标磁盘 +5. 确认覆盖 → 等待还原完成 → 系统即刻复活 +``` + +## Related Concepts +- [[全盘镜像备份]] — Clonezilla 实现的备份方法 +- [[NFS网络备份]] — Clonezilla 推荐的网络存储方案 +- [[裸机恢复]] — Clonezilla 支持的核心场景 +- [[增量备份]] — Clonezilla 镜像备份 vs rsync 增量备份（互补方案） + +## Related Sources +- [[clonezilla对ubuntu-server进行全盘镜像备份]] + +## Related Entities +- [[Rufus]] — U 盘启动盘制作工具 +- [[Synology NAS]] — 备份镜像存储目标 +- [[HP ZBook]] — 源笔记本设备 diff --git a/wiki/entities/Cloud-Maturity-Model.md b/wiki/entities/Cloud-Maturity-Model.md index 61a00644..2793341c 100644 --- a/wiki/entities/Cloud-Maturity-Model.md +++ b/wiki/entities/Cloud-Maturity-Model.md @@ -1,95 +1,107 @@ ---- -title: Cloud Maturity Model (CMM) -source: https://www.bacancytechnology.com/blog/cloud-maturity-model -tags: [Cloud, Maturity, Framework, Cloud-Adoption, Enterprise] ---- +# Cloud Maturity Model -# Cloud Maturity Model (CMM) +> **Cloud Maturity Model (CMM)** — 企业云成熟度评估框架，用于衡量组织在云采用旅程中所处的阶段，并指导其向更高成熟度水平演进。 -## Overview +## Definition -The **Cloud Maturity Model** (CMM) is a structured framework for evaluating an organization's cloud adoption readiness. Developed and described by the Open Alliance for Cloud Adoption (OACA), it provides a systematic approach for organizations of all sizes and experience levels to assess their current cloud state, identify gaps, and plan their cloud transformation journey. +云成熟度模型（Cloud Maturity Model, CMM）是一个结构化框架，用于评估组织在云采用旅程中的当前状态，并提供通往更高成熟度的明确路径。根据 Open Alliance for Cloud Adoption (OACA) 的定义，CMM 协助组织： -## Key Definition +- 识别云采用或混合 IT 环境的定制化解决方案 +- 评估云采用就绪度 +- 评估当前云服务使用情况 +- 设定未来目标以制定云迁移战略 +- 进行 GAP 分析并基于业务目标识别云基础设施改进领域 -The OACA describes CMM as a framework that: -- Assists organizations in identifying tailored solutions for adopting cloud or hybrid IT environments -- Evaluates organizations' readiness for adopting the cloud -- Helps assess their current use of cloud services -- Sets future goals for developing a cloud migration strategy -- Conducts GAP analysis -- Identifies areas for improving cloud infrastructure based on business objectives +## Industry Context -## The 5 Maturity Levels +| 指标 | 数据 | +|------|------| +| 行业规模（2022） | 7.5 亿美元 | +| 预测规模（2025） | 15 亿美元 | +| 已实施 CMM 的组织 | 60%+ | +| 来源 | Forrester + Gartner | -| Level | Name | Description | -|-------|------|-------------| -| **Level 0** | Legacy | No cloud usage, relies solely on outdated systems | -| **Level 1** | Initial Readiness (Ad hoc) | Some cloud experience, primarily for SaaS or specific business units, no clear strategy | -| **Level 2** | Repeatable, Opportunistic | Established procedures, cloud services used extensively, but approach not fully systematic | -| **Level 3** | Systematic and Documented | Documented practices, outsourced/cloud management services, efficient operations | -| **Level 4** | Measured | Transparent governance model, cloud-native applications widely adopted across organization | -| **Level 5** | Optimized | Open, interoperable cloud environment, data-driven decisions, flexible workload placement | +## 5 Levels of Cloud Maturity + +| Level | 名称 | 特征 | +|-------|------|------| +| **Level 0** | 无云就绪（Legacy） | 完全不使用云，纯本地遗留系统 | +| **Level 1** | 初始就绪（Ad hoc） | 初步评估，部分 SaaS 使用，无整体战略 | +| **Level 2** | 可重复（Repeatable） | 建立流程，广泛使用云服务，方法尚不系统 | +| **Level 3** | 系统化（Systematic） | 文档化实践，托管服务，外包管理 | +| **Level 4** | 可衡量（Measured） | 云原生应用广泛采用，治理模型透明 | +| **Level 5** | 优化级（Optimized） | 数据驱动决策，跨平台灵活迁移工作负载 | + +> ⚠️ **Level 5 通常更具理想性** — 许多公司可能开发开放互通的云环境，但在流程优化和数据充分利用方面仍有差距。 ## Key Components ### Business Capability Areas -- Finance (CAPEX to OPEX shift) +- Finance（CAPEX → OPEX） - Enterprise Strategy - Organizational Structure -- Culture and Skills -- Governance and Compliance +- Culture +- Governance +- Skills & Training +- Compliance - Business Processes -- Procurement and Commercial +- Procurement +- Commercial Management +- Portfolio Management +- Projects ### Technical Capability Areas - IT Architecture -- Applications Modernization +- Applications +- Management Tools +- IT Operations Processes - DevOps - Security -- IaaS / PaaS / SaaS / STaaS / IPaaS -- Data and Information Services -- Network Infrastructure -- AI and IoT Integration +- IaaS / PaaS / SaaS +- IPaaS / STaaS +- Data & Information Services +- Network +- AI / ML +- IoT - APIs -### Three Core Evaluation Dimensions -1. **People** — Skills, ways of working, training programs -2. **Processes** — Workflow updates, continuous improvement -3. **Technology** — Infrastructure changes, new tech adoption +### Evaluation Dimensions +- **People** — 人员能力与新技能培养 +- **Processes** — 流程优化与更新 +- **Technology** — 技术基础设施适配 -## Benefits of Implementing CMM +## Benefits -1. **Enhanced Strategic Planning** — Focus on high-impact areas -2. **Improved Team Communications** — Shared framework for goals -3. **Enhanced Application Performance** — Smoother cloud apps -4. **Enhanced Security and Performance** — Best practices adherence -5. **Faster Time to Market** — Efficient resource use -6. **Industry Benchmarking** — Compare against sector peers -7. **Cost-Savings** — Efficiency and automation emphasis +1. **Enhanced Strategic Planning** — 聚焦高影响领域 +2. **Improved Team Communications** — 共享目标与进度 +3. **Enhanced Application Performance** — 提升可用性与响应 +4. **Enhanced Security** — 改进访问控制、加密、合规 +5. **Faster Time to Market** — 快速响应市场需求 +6. **Industry Benchmarking** — 与同行对标 +7. **Cost Savings** — 效率提升与自动化降低运营成本 -## Related Models and Frameworks +## Related Maturity Models -| Model | Focus | -|-------|-------| -| **CMM 4.8** | IT organization's business/technology functions across cloud domains | -| **Cloud Native Maturity Model** | CNCF ecosystem, scalable applications | -| **Cloud Security Maturity Model (CSMM)** | Cloud security across 12 categories | -| **Software Assurance Maturity Model (SAMM)** | Entire software lifecycle | -| **AWS CAF** | AWS-specific transformation roadmap | -| **Azure CAF** | Microsoft Azure adoption | -| **Google Cloud Adoption Framework** | Google Cloud transition | +- **CMM 4.8** — 跨域和云服务类型评估 +- **Cloud Native Maturity Model** — CNCF 云原生采用 +- **Cloud Security Maturity Model (CSMM)** — 云安全成熟度 +- **Software Assurance Maturity Model (SAMM)** — 软件开发生命周期 +- **AWS Cloud Adoption Framework** — AWS 特定最佳实践 +- **Azure Cloud Adoption Framework** — Azure 采用框架 +- **Google Cloud Adoption Framework** — GCP 采用框架 -## Related Concepts +## See Also -- [[Cloud-Adoption-Strategy]] -- [[Multi-Cloud-Strategy]] -- [[Cloud-Native]] -- [[DevOps-Maturity]] -- [[FinOps]] +- [[Cloud Maturity Levels]] — 5级成熟度详细定义 +- [[Cloud Adoption Strategy]] — 云采用策略 +- [[Cloud Governance]] — 云治理 +- [[Cloud-Native]] — 云原生 +- [[Multi-Cloud Strategy]] — 多云策略 +- [[FinOps]] — 云财务管理 +- [[DevOps Maturity]] — DevOps 成熟度 +- [[DORA Metrics]] — DORA 指标 ## Sources -- [[sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md]] -- [[sources/cloud-operating-model-key-strategies-and-best-practices.md]] -- [[sources/cloud-devop-maturity-guideline.md]] +- [Bacancy Technology: Cloud Maturity Model](https://www.bacancytechnology.com/blog/cloud-maturity-model) +- [[sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption]] diff --git a/wiki/entities/Docker卷.md b/wiki/entities/Docker卷.md new file mode 100644 index 00000000..b0b1964b --- /dev/null +++ b/wiki/entities/Docker卷.md @@ -0,0 +1,74 @@ +--- +title: "Docker卷" +tags: [docker, storage, container] +date: 2026-04-26 +--- + +# Docker卷 (Docker Volume) + +## Definition +Docker 卷是 Docker 容器用于持久化数据的首选机制。与容器层不同，卷存储在宿主机文件系统上，由 Docker 管理，独立于容器的生命周期。 + +## Key Properties +- **持久性**: 数据在容器删除后依然保留 +- **独立性**: 卷与容器文件系统隔离 +- **共享性**: 多个容器可挂载同一卷 +- **Host 管理**: Docker CLI 可直接管理卷 + +## Default Location +Linux 系统中，Docker 卷默认存储在： +``` +/var/lib/docker/volumes/ +``` + +## Docker卷备份策略 + +### Method 1: rsync 直接同步 (不推荐数据库) +```bash +rsync -azR --delete \ + /var/lib/docker/volumes/ \ + /mnt/nas_backup/docker_backups/ +``` +**⚠️ 警告**: 直接同步二进制数据库文件可能导致恢复后无法启动。 + +### Method 2: mysqldump + rsync (推荐用于数据库) +```bash +# 在容器中执行 mysqldump +docker exec mysqldump -u root -p --all-databases > dump.sql + +# rsync 同步导出文件 +rsync -az /path/to/dump.sql /mnt/nas_backup/docker_backups/ +``` + +### Method 3: docker save / docker load +```bash +# 导出镜像 +docker save -o images.tar image_name:tag + +# rsync 传输 +rsync -az images.tar user@nas:/backup/ + +# 导入镜像 +docker load < images.tar +``` + +## Related Concepts +- [[增量备份]] — Docker 卷备份是增量备份策略的重要组成部分 +- [[Docker-Image]] — 镜像备份使用 docker save/load +- [[Docker-Save]] — 镜像导出命令 +- [[Docker-Load]] — 镜像导入命令 + +## Related Entities +- [[Navidrome]] — 音乐流媒体服务使用 Docker 卷存储音乐文件和数据库 +- [[群晖 NAS]] — 网络存储作为 Docker 卷备份的目标位置 + +## Best Practices +1. **数据库一致性**: 使用 mysqldump 而非直接复制 +2. **定期快照**: 结合 LVM/ZFS 快照实现应用一致性 +3. **增量同步**: rsync 仅传输变更的卷数据 +4. **备份验证**: 定期测试从备份恢复的可行性 + +## See Also +- [[Disaster-Recovery]] — Docker 卷备份是灾备策略的核心 +- [[RTO]] — 恢复时间目标受备份策略影响 +- [[RPO]] — 恢复点目标由备份频率决定 diff --git a/wiki/entities/GDPR.md b/wiki/entities/GDPR.md new file mode 100644 index 00000000..e61d1ecc --- /dev/null +++ b/wiki/entities/GDPR.md @@ -0,0 +1,62 @@ +--- +title: "GDPR" +type: entity +tags: [security, compliance, privacy] +date: 2025-03-02 +--- + +# GDPR + +**GDPR**（General Data Protection Regulation，通用数据保护条例）是欧盟 2018 年 5 月生效的数据保护法规，是全球最严格的数据隐私法律之一。 + +## Overview + +GDPR 适用于处理欧盟居民个人数据的所有组织，无论该组织位于何处。主流云服务商通过 GDPR 合规，为全球客户提供数据保护。 + +## Key Principles + +1. **合法性、公平性和透明度**：数据处理必须有合法依据 +2. **目的限制**：数据仅用于指定目的 +3. **数据最小化**：仅收集必要数据 +4. **准确性**：保持数据准确 +5. **存储限制**：不超过必要时间存储 +6. **完整性和保密性**：确保数据安全 +7. **问责制**：数据控制者负责合规 + +## Key Rights + +| Right | Description | +|-------|-------------| +| **访问权** | 了解是否处理其数据及如何处理 | +| **更正权** | 要求更正不准确数据 | +| **删除权（被遗忘权）** | 要求删除数据 | +| **限制处理权** | 限制特定处理活动 | +| **数据可携权** | 以结构化格式获取其数据 | +| **拒绝权** | 拒绝自动化决策 | +| **撤回同意权** | 随时撤回同意 | + +## Cloud Provider GDPR Compliance + +| Provider | Key Mechanisms | +|----------|---------------| +| **AWS** | GDPR Data Processing Addendum, Data Privacy Center | +| **Azure** | GDPR DPA, Compliance Manager, Data Subject Requests | +| **Google Cloud** | GDPR Commitments, Data Processing Amendment | + +## Cloud Myths Context + +GDPR 是反驳"云不安全"误解的关键证据： +- 通过 GDPR 合规的云服务商必须满足全球最严格的数据保护标准 +- 云平台的数据加密、访问控制、审计日志等能力直接支持 GDPR 合规 + +## Related Concepts + +- [[Data-Sovereignty]] — 数据主权（GDPR 核心概念） +- [[cloud-security]] — 云安全实践 +- [[ISO-27001]] — 信息安全管理体系 +- [[HIPAA]] — 医疗数据保护（对比） +- [[SOC-2]] — 通用安全控制报告 + +## Sources + +- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/entities/Grafana.md b/wiki/entities/Grafana.md new file mode 100644 index 00000000..db38508e --- /dev/null +++ b/wiki/entities/Grafana.md @@ -0,0 +1,59 @@ +--- +title: "Grafana" +type: entity +aliases: [Grafana OSS, Grafana Labs] +tags: [visualization, dashboard, monitoring, observability, grafana] +date: 2025-11-11 +--- + +# Grafana + +## Overview +Grafana 是开源的可视化和监控平台，由 Grafana Labs 开发和维护。它能连接多种数据源（Prometheus、Loki、VictoriaMetrics、Elasticsearch、InfluxDB 等），提供丰富的仪表盘模板、查询编辑器和告警管理功能。家庭监控方案中，Grafana 通过 Dashboard ID 直接导入官方模板，快速搭建可视化界面。 + +## Key Characteristics +- **多数据源支持**：Prometheus、Loki、VictoriaMetrics、Elasticsearch、MySQL、PostgreSQL 等 +- **Dashboard 即代码**：JSON 格式导出存储，纳入 Git 版本控制（GitOps） +- **官方 Dashboard 市场**：Dashboard ID 直接导入，1860（Node Exporter Full）、14282（cAdvisor）、7587（Blackbox） +- **告警管理**：原生告警支持，可替代 Prometheus Alerting 独立使用 +- **变量和模板**：支持动态仪表盘、级联选择器 +- **权限控制**：组织（Org）、团队、用户三级权限体系 + +## Home Server Deployment +```yaml +# docker-compose.yml 片段 +grafana: + image: grafana/grafana:latest + container_name: grafana + ports: + - "3000:3000" + environment: + - GF_AUTH_ANONYMOUS_ENABLED=true + - GF_AUTH_ANONYMOUS_ORG_NAME=Main Org + - GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer + - GF_SECURITY_ADMIN_USER=admin + - GF_SECURITY_ADMIN_PASSWORD=admin + volumes: + - grafana-storage:/var/lib/grafana +``` + +## Quick Dashboard Import +1. 访问 `http://localhost:3000`，admin/admin 登录 +2. 添加数据源：`http://prometheus:9090` +3. Dashboards → Import → 输入 Dashboard ID： + - **1860** — Node Exporter Full（主机指标） + - **14282** — cAdvisor Container Metrics（容器指标） + - **7587** — Blackbox Exporter Probe（HTTP 探测） + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Prometheus]] — 主要数据源 +- [[Grafana Labs]] — 维护组织 +- [[Alertmanager]] — 告警接收 + +## Related Concepts +- [[System Monitoring]] — 上游领域 +- [[Centralized Logging]] — Grafana Loki 补充日志可视化 +- [[Observability]] — 可观测性三大支柱之一（可视化层） diff --git a/wiki/entities/HIPAA.md b/wiki/entities/HIPAA.md new file mode 100644 index 00000000..408b9c2b --- /dev/null +++ b/wiki/entities/HIPAA.md @@ -0,0 +1,57 @@ +--- +title: "HIPAA" +type: entity +tags: [security, compliance, healthcare] +date: 2025-03-02 +--- + +# HIPAA + +**HIPAA**（Health Insurance Portability and Accountability Act）是美国 1996 年颁布的联邦法律，主要规范医疗健康信息的隐私和安全。 + +## Overview + +HIPAA 是医疗行业云采用的关键合规门槛。主流云服务商通过 HIPAA 合规认证，使其能够服务医疗健康行业客户。 + +## Key Rules + +### Privacy Rule（隐私规则） +- 保护个人医疗信息（PHI / Protected Health Information） +- 规定谁可以访问 PHI +- 赋予患者访问和控制自己信息的权利 + +### Security Rule（安全规则） +- **Administrative Safeguards**: 安全管理和流程 +- **Physical Safeguards**: 物理设施安全 +- **Technical Safeguards**: 技术保护措施 + +### Breach Notification Rule（违约通知规则） +- 超过 500 人受影响必须在 60 天内通知 +- 向 HHS 和媒体通报 + +## Cloud Provider HIPAA Compliance + +主流云服务商通过 HIPAA 合规，允许医疗客户在云中处理 PHI： + +| Provider | HIPAA Compliance | +|----------|-----------------| +| **AWS** | BAA (Business Associate Agreement) 可用，HIPAA Eligible Services | +| **Azure** | HIPAA BAA，覆盖大量 Azure 服务 | +| **Google Cloud** | HIPAA BAA，支持 PHI 工作负载 | + +## Relevance to Cloud Myths + +HIPAA 认证是反驳"云不安全"误解的重要证据： +- 云服务商支持 HIPAA 合规 = 可安全处理最敏感的医疗数据 +- 通过 HIPAA 认证的云环境在某些方面优于传统本地医疗系统 + +## Related Standards + +- [[ISO-27001]] — 信息安全管理体系 +- [[GDPR]] — 欧盟数据保护条例（跨地区对比） +- [[SOC-2]] — 通用安全控制报告 +- [[PHI]] — Protected Health Information + +## Sources + +- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/entities/HP-ZBook.md b/wiki/entities/HP-ZBook.md new file mode 100644 index 00000000..2fe35929 --- /dev/null +++ b/wiki/entities/HP-ZBook.md @@ -0,0 +1,46 @@ +--- +title: "HP ZBook" +type: entity +tags: [hp, workstation, laptop, uefi] +date: 2026-04-14 +aliases: [ZBook, HP ZBook, HP ZBook Workstation, HP ZBook移动工作站] +--- + +# HP ZBook + +## Overview +HP ZBook 是 HP 公司的移动工作站笔记本系列，定位专业级图形/计算工作负载，配备高性能 CPU、NVMe 固态硬盘和 UEFI 固件。 + +## Key Hardware Characteristics +- **CPU**：Intel Core 或 Xeon 系列 +- **存储**：NVMe PCIe SSD（需 AHCI 模式，RAID/Intel RST 不兼容 Ubuntu） +- **固件**：UEFI（带传统 BIOS 兼容层） +- **启动键**：F9（启动菜单）、F10（BIOS 设置） + +## Ubuntu Installation Issues +HP ZBook 在安装 Ubuntu 24.04 时遇到的核心问题是 **BIOS 固执行为**： +1. Ubuntu 成功注册到 NVRAM（`Boot0005: Ubuntu`） +2. 但该启动项未被加入 `BootOrder` +3. 每次重启后，BIOS 忽略 Ubuntu 启动项 + +### BIOS Recommended Settings +| 设置项 | 建议值 | 原因 | +|--------|--------|------| +| SATA Mode | AHCI | Ubuntu 不兼容 Intel RST RAID | +| Secure Boot | Disabled | 避免第三方驱动安装麻烦 | +| Fast Boot | Disabled | 确保 U 盘顺利引导 | +| Legacy Support | Disabled / UEFI Only | 消除 BBS 遗留项干扰 | + +## Solutions Applied +1. **efibootmgr 强制重写**：将 0005 写入 BootOrder 首位 +2. **EFI 路径伪装**：复制 shimx64.efi → /EFI/BOOT/BOOTX64.EFI +3. **UEFI Only 模式**（终极方案）：切换后所有 Legacy 项自动消失 + +## Related +- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] — 完整安装与故障排除记录 +- [[Rufus]] — 启动盘制作工具 +- [[efibootmgr]] — NVRAM 启动项管理 +- [[UEFI Only]] — 终极启动修复方案 +- [[NVMe硬盘分区]] — 硬盘分区规范 +- [[HP ZBook]] ← 安装目标 ← [[Rufus]] +- [[HP ZBook]] ← 受影响平台 ← [[efibootmgr]] diff --git a/wiki/entities/ISO-27001.md b/wiki/entities/ISO-27001.md new file mode 100644 index 00000000..9cbe8940 --- /dev/null +++ b/wiki/entities/ISO-27001.md @@ -0,0 +1,65 @@ +--- +title: "ISO 27001" +type: entity +tags: [security, compliance, standard] +date: 2025-03-02 +--- + +# ISO 27001 + +**ISO 27001**（ISO/IEC 27001）是国际公认的信息安全管理体系（ISMS）标准，由国际标准化组织（ISO）和国际电工委员会（IEC）联合发布。 + +## Overview + +ISO 27001 是信息安全领域最权威的管理体系认证之一，云服务商普遍通过该认证以证明其安全能力。 + +## Key Requirements + +- **信息资产清单**：识别和分类所有信息资产 +- **风险评估**：系统性地识别、分析和评估信息安全风险 +- **控制措施**：从 114 项控制措施中选择适用的控制 +- **持续改进**：PDCA（Plan-Do-Check-Act）循环 +- **管理承诺**：领导层对信息安全的承诺和支持 + +## Control Domains (14 Domains) + +1. Information Security Policies +2. Organization of Information Security +3. Human Resource Security +4. Asset Management +5. Access Control +6. Cryptography +7. Physical and Environmental Security +8. Operations Security +9. Communications Security +10. System Acquisition, Development and Maintenance +11. Supplier Relationships +12. Information Security Incident Management +13. Business Continuity Management +14. Compliance + +## Cloud Context + +主流云服务商（AWS、Azure、Google Cloud）均通过了 ISO 27001 认证，作为其安全成熟度的核心证明： + +- **AWS**: ISO 27001, 27017, 27018 认证 +- **Azure**: SOC 1/2/3, ISO 27001, HIPAA, FedRAMP +- **Google Cloud**: ISO 27001, ISO 27017, ISO 27018, SOC 2/3 + +## Relevance to Cloud Myths + +ISO 27001 认证是反驳"云不安全"误解的关键证据： +- 云服务商通过 ISO 27001 认证 = 其安全管理体系达到国际标准 +- 传统本地部署往往缺乏同等级别的安全投入和认证 + +## Related Standards + +- [[ISO-27001]] ← self-reference +- [[HIPAA]] — 医疗健康数据标准 +- [[GDPR]] — 欧盟数据保护条例 +- [[SOC-2]] — 服务组织控制报告 +- [[FedRAMP]] — 美国政府云安全标准 + +## Sources + +- [[The Myths and Misconceptions About Cloud Computing (LinkedIn)|sources/the-myths-and-misconceptions-about-cloud-computing-linkedin]] diff --git a/wiki/entities/KoolCenter固件服务器.md b/wiki/entities/KoolCenter固件服务器.md new file mode 100644 index 00000000..a95fd038 --- /dev/null +++ b/wiki/entities/KoolCenter固件服务器.md @@ -0,0 +1,23 @@ +# KoolCenter固件服务器 + +## Aliases +- KoolCenter +- KoolCenter固件下载站 + +## Basic Info +- **Type**: 固件下载平台 +- **URL**: koolshare.cn / koolcenter.com +- **Content**: 梅林固件下载 + +## Description +KoolCenter是一个提供华硕和网件路由器梅林固件下载的平台网站。用户可以在此找到对应路由器型号的`.chk`过渡固件和`.w`正式固件。 + +## Download Process (RAX50) +1. 访问 KoolCenter 固件服务器 +2. 找到 RAX50 对应型号 +3. 下载 `.chk` 过渡固件（第一步刷机） +4. 下载 `.w` 正式梅林固件（第二步刷机） + +## Related +- [[梅林固件]] — 下载的固件类型 +- [[网件RAX50]] — 目标路由器 diff --git a/wiki/entities/Kubernetes.md b/wiki/entities/Kubernetes.md new file mode 100644 index 00000000..3a742454 --- /dev/null +++ b/wiki/entities/Kubernetes.md @@ -0,0 +1,112 @@ +--- +title: "Kubernetes" +type: entity +tags: + - cloud + - container + - orchestration + - devops +created: 2026-04-25 +--- + +# Kubernetes + +## Definition + +Kubernetes (K8s) 是 Google 开源的**容器编排平台**，用于自动化容器化应用的部署、扩缩容和管理。是云原生 (Cloud-Native) 架构的核心基础设施，也是 Agentic AI 自主修复 (Self-Healing) 的主要目标环境。 + +## Aliases + +- K8s +- Kubernetes +- Container Orchestration Platform + +## Major Cloud Implementations + +| Provider | Service | Description | +|----------|---------|-------------| +| AWS | EKS (Elastic Kubernetes Service) | 托管 Kubernetes on AWS | +| GCP | GKE (Google Kubernetes Engine) | 托管 Kubernetes on GCP | +| Azure | AKS (Azure Kubernetes Service) | 托管 Kubernetes on Azure | + +## Kubernetes Self-Healing Capabilities + +Kubernetes 原生提供基础 Self-Healing 能力： + +```yaml +# Kubernetes Self-Healing 原生机制 +apiVersion: apps/v1 +kind: Deployment +spec: + replicas: 3 + strategy: + type: RollingUpdate + template: + spec: + terminationGracePeriodSeconds: 30 +# 内置机制: +# - 自动重启失败的容器 +# - 替换不健康的 Pod +# - 滚动更新确保服务可用 +``` + +Agentic AI 在原生能力基础上提供**更高级的自我修复**： + +| 能力 | Kubernetes 原生 | Agentic AI Enhanced | +|------|---------------|-------------------| +| Pod 重启 | ✅ 自动重启崩溃容器 | ✅ 智能分析根因 + 预防性重启 | +| 扩缩容 | ✅ HPA 基于指标 | ✅ 预测性扩缩容 | +| 节点恢复 | ✅ 节点故障迁移 | ✅ 主动健康检查 + 预防性迁移 | +| 配置修复 | ❌ 需人工介入 | ✅ AI 自动修正 ConfigMap/Secret | + +## Agentic AI Monitoring Targets + +``` +┌─────────────────────────────────────────────────┐ +│ Agentic AI for Kubernetes │ +├─────────────────────────────────────────────────┤ +│ 监控层 │ +│ ├── Pod Metrics (CPU/Memory/Network) │ +│ ├── Workload Health (Deployment/ReplicaSet) │ +│ ├── Node Status (Ready/Condition) │ +│ └── Cluster Components (etcd, API Server) │ +│ │ +│ 决策层 │ +│ ├── Anomaly Detection (AI) │ +│ ├── Root Cause Analysis (AI) │ +│ └── Action Planning (AI) │ +│ │ +│ 执行层 │ +│ ├── kubectl API (restart/migrate/scale) │ +│ ├── HPA Override (AI-driven scaling) │ +│ └── Config Updates (AI-driven fixes) │ +└─────────────────────────────────────────────────┘ +``` + +## Example + +> An AI agent monitoring AWS EKS clusters detects high CPU usage due to a rogue pod: +> - Pod `payment-service-v2-abc123` CPU usage: 95% +> - AI correlates with recent deployment timestamp +> - AI identifies: Memory leak in new version +> - AI Actions: +> 1. Scale deployment to 3 replicas (distribute load) +> 2. Create rollback ticket +> 3. Notify team via Slack +> 4. Auto-rollback after approval + +## Related Concepts + +- [[Self-Healing Systems]] — Kubernetes 是 Self-Healing 的主要载体 +- [[Cloud-Native]] — Kubernetes 是 Cloud-Native 的核心 +- [[Deployment Automation]] — Kubernetes 部署的自动化 +- [[Container Lifecycle Hardening]] — 容器安全加固 + +## Related Entities + +- [[Agentic AI]] — Kubernetes 是 Agentic AI 的管理对象 +- EKS, GKE, AKS — 具体云服务商实现 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] diff --git a/wiki/entities/LaunchDarkly.md b/wiki/entities/LaunchDarkly.md new file mode 100644 index 00000000..da005ca4 --- /dev/null +++ b/wiki/entities/LaunchDarkly.md @@ -0,0 +1,84 @@ +--- +title: "LaunchDarkly" +type: entity +aliases: [Launch Darkly] +tags: [cloud, devops, feature-management, feature-flag, saas] +date: 2026-04-25 +--- + +# LaunchDarkly + +**LaunchDarkly** 是一个 Feature Flag 管理平台，为软件团队提供功能开关、渐进放量、A/B 测试和 Kill Switch 能力，是 [[Feature Flag]] 技术的商业实现。 + +## Overview + +LaunchDarkly 将 [[Feature Flag]] 能力产品化，提供： +- 可视化的 Flag 管理界面 +- 多环境支持（Dev/Staging/Production） +- 用户分群和定向投放 +- 渐进放量（Progressive Rollout）控制 +- 实时指标监控和集成 +- [[Kill Switch]] 紧急切断能力 + +## Key Features + +| 功能 | 说明 | +|------|------| +| Feature Flags | 创建、管理、版本控制功能开关 | +| Progressive Rollout | 分阶段向用户群发布功能 | +| User Targeting | 基于用户属性定向投放 | +| A/B Testing | 数据驱动的功能实验 | +| Kill Switches | 紧急情况下秒级切断 | +| SDKs | 支持 25+ 编程语言 | + +## 商业案例数据 + +| 公司 | 改进前 | 改进后 | 数据来源 | +|------|--------|--------|----------| +| HP | 回滚时间：小时级 | 分钟级 | LaunchDarkly Case Study | +| Christian Dior | 回滚时间：15 分钟 | 即时切换 | LaunchDarkly Case Study | +| LaunchDarkly 客户 | — | 86% 在一天内恢复 | 2024 Survey | +| LaunchDarkly 客户 | — | 42% 在小时级（甚至分钟级）恢复 | 2024 Survey | + +**成本效益**： +- 8% 客户：运维成本降低超过 50% +- 59% 客户：运维成本降低 11%-50% +- 26% 客户：运维成本降低最多 10% + +## 与 [[RTO]]/[[RPO]] 的关系 + +LaunchDarkly 直接影响 [[RTO]] 和 [[RPO]]： + +- **RTO**：从小时级降至秒级（通过 Kill Switch） +- **RPO**：保持近零（Feature Flag 切换不触碰数据层） +- **恢复成本**：远低于传统灾备基础设施 + +## 适用场景 + +- **持续交付团队**：每天多次部署，需要快速回滚能力 +- **产品实验**：A/B 测试，数据驱动决策 +- **灰度发布**：渐进放量，降低发布风险 +- **微服务架构**：跨服务的功能控制 +- **移动应用**：无需 App Store 审核即可关闭功能 + +## 竞品对比 + +| 平台 | 定位 | 优势 | +|------|------|------| +| LaunchDarkly | 企业级 Feature Flag | SDK 丰富、集成广泛 | +| Unleash | 开源自托管 | 灵活性、数据主权 | +| Split.io | 数据驱动实验 | 实验分析能力 | +| Flagsmith | 开源自托管 | 轻量级 | + +## Related Concepts + +- [[Feature Flag]] — LaunchDarkly 的核心能力 +- [[Kill Switch]] — LaunchDarkly 的紧急响应能力 +- [[Progressive Rollout]] — LaunchDarkly 支持的渐进放量 +- [[Micro-Recovery]] — LaunchDarkly 实现的 feature 级别恢复 +- [[RTO]] — LaunchDarkly 将 RTO 从小时降至秒级 +- [[RPO]] — LaunchDarkly 保护 RPO + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/entities/Mac-Mini-M4.md b/wiki/entities/Mac-Mini-M4.md new file mode 100644 index 00000000..95ee08ba --- /dev/null +++ b/wiki/entities/Mac-Mini-M4.md @@ -0,0 +1,98 @@ +# Mac Mini M4 + +> Apple Silicon Mac Mini M4，配备 Apple M4 芯片，作为家庭服务器运行各类服务。 + +## Overview +Mac Mini M4 是 Apple 2024 年推出的迷你台式机，搭载 Apple M4 芯片，采用 ARM64 架构。作为 Home Server，它运行 FRP 客户端、N8n 工作流引擎、OpenClaw AI Agent 等服务。 + +## Hardware Specifications + +| 规格 | Mac Mini M4 | +|------|-------------| +| 芯片 | Apple M4（10核CPU/10核GPU）| +| 内存 | 可选 16GB/24GB/32GB 统一内存 | +| 存储 | 可选 256GB-2TB SSD | +| 架构 | ARM64（Apple Silicon）| +| 尺寸 | 5cm × 12.7cm × 12.7cm | +| 功耗 | 约 30-150W（根据负载）| + +## Home Server Use Cases + +### Core Services +| 服务 | 用途 | 端口 | +|------|------|------| +| FRP 客户端 | 内网穿透，远程访问 | frpc → VPS:7000 | +| N8n | 工作流自动化 | 5678 | +| OpenClaw | AI Agent | 8080 | +| Hermes Agent | 个人 AI 助手 | Telegram Bot | + +### macOS-Specific Considerations +1. **ARM64 架构**：必须下载 ARM64 版本的软件（如 `frp_0.65.0_darwin_arm64.tar.gz`） +2. **Gatekeeper**：需使用 `xattr -rd com.apple.quarantine` 解除安全限制 +3. **launchd**：使用 launchd + launchctl 管理服务开机自启 +4. **`/opt` 目录**：需要手动创建并授权 +5. **Homebrew**：macOS 包管理器，安装开发工具 + +## Installation Paths +``` +/opt/ # 第三方软件安装目录（需手动创建） +├── frp/ +│ ├── frp_0.65.0_darwin_arm64/ +│ └── current -> frp_0.65.0_darwin_arm64/ +└── n8n/ + └── data/ + +~/Library/LaunchAgents/ # 用户级服务配置 +├── com.frpc.client.plist +└── com.n8n.service.plist +``` + +## Advantages as Home Server + +| 优势 | 说明 | +|------|------| +| 低功耗 | 空闲时仅 ~3W，负载时 ~150W | +| 无噪音 | 无风扇设计（被动散热）| +| 高性能 | M4 芯片性能远超同功耗 x86 | +| macOS 生态 | 原生支持 iOS/macOS 开发 | +| ARM64 效率 | 统一内存架构，高效处理 | +| 小巧便携 | 12.7cm × 12.7cm × 5cm | + +## Remote Access Architecture +``` +[用户/客户端] + │ + │ 公网（SSH 6000端口） + ▼ +[VPS: 192.227.222.142] + │ + │ FRP 隧道 + ▼ +[Mac Mini M4] + frpc ←── 连接到 VPS:7000 + SSH:22 ← 远程访问 + N8n:5678 + OpenClaw:8080 +``` + +## Process Management +| 方法 | 适用场景 | 命令 | +|------|----------|------| +| launchd | 开机自启（生产环境）| launchctl load/start/stop | +| tmux | 开发调试 | tmux new -s / attach | +| nohup | 简单后台 | nohup ./program & | + +## Related Concepts +- [[frp]] — 内网穿透工具 +- [[launchd]] — macOS 服务管理器 +- [[Gatekeeper]] — macOS 安全机制 +- [[软链接策略]] — 版本管理策略 +- [[内网穿透]] — 远程访问机制 + +## Related Entities +- [[VPS]] — 内网穿透的公网中转站 +- [[frps]] — FRP 服务端 + +## References +- Apple: Mac Mini +- Apple Silicon: ARM64 Architecture diff --git a/wiki/entities/MariaDB.md b/wiki/entities/MariaDB.md new file mode 100644 index 00000000..2477fe03 --- /dev/null +++ b/wiki/entities/MariaDB.md @@ -0,0 +1,69 @@ +# MariaDB + +## Entity Information +- **Type**: Database / Product / Project +- **Status**: Active +- **Source**: [[mysql-mariadb-数据库详细信息]] + +## Overview +MariaDB 是 Synology NAS Docker 环境部署的开源关系型数据库，提供内网和公网双通道访问能力。 + +## Aliases +- MySQL (MariaDB 是 MySQL 的开源分支，语法高度兼容) + +## Configuration + +### 内网访问配置 +| 项目 | 值 | +|------|-----| +| IP | 192.168.3.17 | +| Port | 3307 | +| Username | shenwei | +| Password | !Abcde12345 | +| Root | root / !Abcde12345 | + +### 公网访问配置 +| 项目 | 值 | +|------|-----| +| Domain | mysql.ishenwei.online | +| Port | 63307 | +| Username | shenwei | +| Password | !Abcde12345 | + +### Socket 登录（本地管理员访问） +```bash +sudo mysql -u root -p -S /run/mysqld/mysqld10.sock +``` + +### 创建远程访问用户 +```sql +-- 创建允许任意主机访问的用户 +CREATE USER 'shenwei'@'%' IDENTIFIED BY '!Abcde12345'; +GRANT ALL PRIVILEGES ON *.* TO 'shenwei'@'%' WITH GRANT OPTION; +FLUSH PRIVILEGES; + +-- 查看当前用户列表 +select host, user from mysql.user; +``` + +## Key Insights + +### Host+User 权限模型 +MariaDB 使用 `username@host` 组合决定访问权限： +- `root@localhost` — 仅允许本机 socket 连接 +- `shenwei@%` — 允许任意主机通过网络连接 + +### 新安装默认状态 +新安装的 MariaDB 通常只有 `root@localhost`，没有网络访问用户，这是远程连接失败的常见原因。 + +## Related Entities +- [[群晖 NAS]] — MariaDB 的部署宿主机 +- [[Docker卷]] — 数据持久化存储 + +## Related Concepts +- [[Socket 登录]] — 本地安全认证方式 +- [[用户权限]] — Host+User 组合权限模型 + +## Related Sources +- [[mysql-mariadb-数据库详细信息]] — 完整配置文档 +- [[Docker卷]] — 包含 mysqldump 备份方法 diff --git a/wiki/entities/MerlinClash插件.md b/wiki/entities/MerlinClash插件.md new file mode 100644 index 00000000..f7c1b746 --- /dev/null +++ b/wiki/entities/MerlinClash插件.md @@ -0,0 +1,39 @@ +# MerlinClash插件 + +## Aliases +- 小猫咪插件 +- MerlinClash +- Clash for Router + +## Basic Info +- **Type**: 科学上网插件 +- **Platform**: 梅林固件 +- **Core**: Clash +- **Distribution**: Telegram 鲁猫云频道 / GitHub + +## Description +MerlinClash（俗称"小猫咪插件"）是基于Clash核心的梅林固件科学上网插件，支持策略组配置、自动节点选择、分流规则和守护进程，是目前功能最全面的路由器代理插件之一。 + +## Key Features +- 策略组分流：基于应用、地区、服务进行流量分类 +- 自动节点延迟测试：定期检测节点可用性 +- 故障转移：节点故障时自动切换备用线路 +- 分流规则：国内外网站分流、不同应用使用不同线路 +- 定时自动更新订阅 +- 守护进程：插件崩溃后自动重启 + +## Comparison with 科学上网插件 (GitHub版本) +| Feature | MerlinClash | GitHub版本 | +|---------|-------------|------------| +| 策略组 | ✅ 支持 | ❌ 不支持 | +| 自动分流 | ✅ 支持 | ❌ 不支持 | +| 自动节点切换 | ✅ 支持 | ❌ 需手动 | +| 故障转移 | ✅ 支持 | ❌ 不支持 | +| 守护进程 | ✅ 支持 | ✅ 支持 | + +## Related +- [[梅林固件]] — 安装平台 +- [[网件RAX50]] — 硬件设备 +- [[机场]] — 节点订阅来源 +- [[策略组分流]] — 核心工作机制 +- [[故障转移]] — 可靠性保障机制 diff --git a/wiki/entities/Navidrome.md b/wiki/entities/Navidrome.md new file mode 100644 index 00000000..fff87eab --- /dev/null +++ b/wiki/entities/Navidrome.md @@ -0,0 +1,59 @@ +--- +title: "Navidrome" +type: entity +aliases: [] +tags: [music, media-server, self-hosted, open-source] +--- + +# Navidrome + +## Basic Info +- **Type**: Entity / Product / Open-source Project +- **Description**: 开源音乐流媒体服务器，支持 Subsonic API 协议，可通过网页端或移动客户端访问个人音乐库 +- **Author**: Deluan +- **Repository**: github.com/navidrome/navidrome +- **License**: GPL v3 + +## Aliases +- Navidrome +- deluan/navidrome（Docker 镜像名） + +## Key Capabilities +1. **Subsonic API 兼容** — 与 Subsonic 协议兼容的客户端均可使用（Jellyfin/Subsonic 客户端通用） +2. **网页播放器** — 内置响应式 Web UI，支持播放列表、专辑浏览、搜索 +3. **移动端支持** — 支持 DSub、Substreamer、Avanté 等 Subsonic 客户端 +4. **转码支持** — 按客户端网络情况自动转码为合适码率，节省带宽 +5. **元数据扫描** — 自动从音乐文件中读取 ID3 标签、封面信息 +6. **轻量部署** — 单 Docker 容器运行，最低 512MB 内存即可运行 + +## Configuration Highlights (Docker Compose) +```yaml +image: deluan/navidrome:latest +user: "1026:100" # 以非 root 用户运行 +ports: + - "4533:4533" +volumes: + - /volume1/music:/music:ro # 只读挂载音乐目录 + - /volume1/docker/navidrome/data:/data # 数据目录 +environment: + - ND_LOGLEVEL=info + - ND_ENABLETRANSCODINGCONFIG=true # 启用转码配置 UI + - ND_AUTOTRANSCODEDOWNLOAD=true # 启用自动转码下载 + - ND_TRANSCODINGCACHESIZE=200MB # 转码缓存上限 200MB +``` + +## Key Design Decisions +- **只读音乐挂载（`:ro`）** — 防止容器误操作修改原始音乐文件 +- **非 root 用户运行** — 提升容器安全性，UID/GID 与宿主机用户对应 +- **转码缓存限制** — 200MB 上限防止磁盘空间被缓存占满 +- **端口 4533** — Navidrome 默认端口，局域网访问地址：`http://:4533` + +## Related Entities +- [[Jellyfin]] — 视频媒体服务器，架构类似但服务视频内容 +- [[群晖 NAS]] — Navidrome 常见部署环境，音乐文件的存储位置 +- [[Docker-Image]] — Navidrome 的部署方式 +- [[Docker Compose]] — Navidrome 的配置管理方式 +- [[Deluan/Navidrome]] — 官方 Docker 镜像发布者 + +## Source +- [[用docker中安装navidrome]] — Navidrome Docker 部署实战笔记 diff --git a/wiki/entities/Netdata.md b/wiki/entities/Netdata.md new file mode 100644 index 00000000..85d1a00c --- /dev/null +++ b/wiki/entities/Netdata.md @@ -0,0 +1,76 @@ +--- +title: "Netdata" +type: entity +aliases: [netdata, netdata cloud] +tags: [monitoring, real-time, visualization, self-hosted, linux] +date: 2025-11-11 +--- + +# Netdata + +## Overview +Netdata 是开源的实时性能和健康监控工具，以"开箱即用"为设计理念，无需复杂配置即可提供高分辨率的主机和容器监控面板。默认监听端口 19999，提供交互式 Web 仪表盘。相比 Prometheus + Grafana 的组合，Netdata 更适合快速诊断和实时观测，但不适合长期数据存储和趋势分析。 + +## Key Characteristics +- **零配置**：安装后自动发现并监控所有系统资源 +- **实时高分辨率**：每秒采样，展示毫秒级性能波动 +- **交互式仪表盘**：内置 Web UI，支持缩放、筛选、对比 +- **容器监控**：自动发现 Docker 容器并采集资源指标 +- **可扩展**：支持通过 plugins 采集自定义指标 +- **Prometheus 集成**：可作为 Prometheus 数据源，实现长期存储 + +## Home Server Deployment +```yaml +# docker-compose.yml（来源：learn.netdata.cloud） +version: '3.8' +services: + netdata: + image: netdata/netdata:latest + container_name: netdata + hostname: home-server + restart: unless-stopped + ports: + - "19999:19999" + cap_add: + - SYS_PTRACE + security_opt: + - apparmor:unconfined + volumes: + - netdataconfig:/etc/netdata + - netdatalib:/var/lib/netdata + - netdatacache:/var/cache/netdata + - /etc/passwd:/host/etc/passwd:ro + - /etc/group:/host/etc/group:ro + - /proc:/host/proc:ro + - /sys:/host/sys:ro + environment: + - NETDATA_CLAIM_TOKEN= + - NETDATA_CLAIM_URL=http://localhost:19999/claim +``` + +访问 `http://localhost:19999` 查看实时监控仪表盘。 + +## Comparison: Netdata vs Prometheus +| 维度 | Netdata | Prometheus | +|------|---------|-----------| +| 采样频率 | 每秒 | 通常 15s+ | +| 数据保留 | 本地（默认 1h） | 长期（可配置） | +| 查询语言 | 无（Web UI） | PromQL | +| 告警配置 | 内置 Web UI | Prometheus rules | +| 学习门槛 | 低 | 中 | +| 长期趋势分析 | 弱 | 强 | +| 适用场景 | 实时诊断、快速排查 | SLA 报表、历史分析 | + +## Best Practice +Netdata + Prometheus 互补使用：Netdata 做实时诊断，Prometheus + Grafana 做长期存储和 SLA 报表。 + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Prometheus]] — 长期存储方案 +- [[Grafana]] — 可视化层 + +## Related Concepts +- [[System Monitoring]] — 上游领域 +- [[时序数据库]] — Prometheus 的数据模型对比 diff --git a/wiki/entities/Open-Alliance-for-Cloud-Adoption.md b/wiki/entities/Open-Alliance-for-Cloud-Adoption.md index 6f3b558c..f43c009e 100644 --- a/wiki/entities/Open-Alliance-for-Cloud-Adoption.md +++ b/wiki/entities/Open-Alliance-for-Cloud-Adoption.md @@ -1,30 +1,76 @@ ---- -title: Open Alliance for Cloud Adoption (OACA) -source: https://www.bacancytechnology.com/blog/cloud-maturity-model -tags: [Cloud, Framework, Organization, Cloud-Adoption] ---- - # Open Alliance for Cloud Adoption (OACA) -## Overview +> **Open Alliance for Cloud Adoption (OACA)** — 一个开放联盟，致力于为组织提供供应商中立（vendor-neutral）的云采用框架和最佳实践。 -The **Open Alliance for Cloud Adoption (OACA)** is an organization that defines and promotes the Cloud Maturity Model (CMM) as a framework for enterprise cloud transformation. +## Definition -## Role in Cloud Maturity Model +OACA 是一个跨行业的开放组织，提供： -OACA describes CMM as a framework that: -- Assists organizations in identifying tailored solutions for adopting cloud or hybrid IT environments -- Evaluates organizations' readiness for adopting the cloud -- Helps assess their current use of cloud services -- Sets future goals for developing a cloud migration strategy -- Conducts GAP analysis -- Identifies areas for improving cloud infrastructure based on business objectives +- **云成熟度模型 (CMM)** — 供应商中立的能力评估框架 +- **云采用指南** — 实用路线图和最佳实践 +- **评估工具** — 帮助组织评估当前云就绪度 -## Related Concepts +## Core Framework -- [[Cloud-Maturity-Model]] -- [[Cloud-Adoption-Strategy]] +OACA 定义了云成熟度模型（Cloud Maturity Model），涵盖： -## Sources +### Business Capability Areas -- [[sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md]] +| 能力域 | 描述 | +|--------|------| +| Finance | 成本管理，CAPEX → OPEX | +| Enterprise Strategy | 战略对齐 | +| Organizational Structure | 角色和决策 | +| Culture | 适应性和持续改进 | +| Governance | 合规和风险管理 | +| Skills | 能力发展和培训 | +| Compliance | 法规遵从 | +| Business Processes | 工作流优化 | +| Procurement | 供应商管理 | +| Commercial | 合同管理 | +| Portfolio Management | 投资优先级 | +| Projects | 项目规划执行 | + +### Technical Capability Areas + +| 能力域 | 描述 | +|--------|------| +| IT Architecture | 可扩展和安全架构 | +| Applications | 应用现代化 | +| Management Tools | 监控和优化工具 | +| IT Operations | 部署和运维流程 | +| DevOps | 开发和运维融合 | +| Security | 安全协议 | +| IaaS/PaaS/SaaS | 云服务模式 | +| IPaaS | 集成平台 | +| Data | 数据管理 | +| Network | 网络基础设施 | +| AI/ML | 人工智能集成 | +| IoT | 物联网支持 | +| APIs | 接口和自动化 | + +## Evaluation Dimensions + +OACA CMM 通过三个维度评估： + +| 维度 | 描述 | +|------|------| +| **People** | 人员能力、新技能培养、奖励机制 | +| **Processes** | 流程识别、改进、更新 | +| **Technology** | 技术需求识别、基础设施适配 | + +## OACA vs Cloud Provider Frameworks + +| 维度 | OACA | AWS CAF | Azure CAF | +|------|------|---------|-----------| +| **供应商** | 中立 | AWS 特定 | Azure 特定 | +| **覆盖** | 全面 | AWS 集成 | Azure 集成 | +| **适用性** | 通用 | AWS 用户 | Azure 用户 | + +## See Also + +- [[Cloud Maturity Model]] — 云成熟度模型 +- [[Cloud Adoption Strategy]] — 云采用策略 +- [[Cloud Maturity Levels]] — 成熟度级别 +- [[AWS Cloud Adoption Framework]] — AWS 云采用框架 +- [[Azure Cloud Adoption Framework]] — Azure 云采用框架 diff --git a/wiki/entities/PingMe.md b/wiki/entities/PingMe.md new file mode 100644 index 00000000..4607ab06 --- /dev/null +++ b/wiki/entities/PingMe.md @@ -0,0 +1,37 @@ +--- +title: "PingMe" +type: entity +tags: [sms-verification, tool, account-registration] +date: 2025-12-31 +--- + +# PingMe + +## 基本信息 +- **类型**: 工具/服务 +- **官网**: https://messages.pingme.tel/ +- **用途**: 短信接码平台 +- **最低充值**: 2美元 + +## 功能特性 +- **支持中文界面**: 便于国内用户使用 +- **美国区号码**: 提供美国手机号接收验证码 +- **订阅制服务**: 比一次性号码更稳定可靠 +- **App形式**: 需要下载手机应用 + +## 使用场景 +- 注册海外服务（如Claude） +- 接收短信验证码 +- 替代一次性虚拟号码 + +## Aliases +- 无 + +## 相关页面 +- [[接码平台]] +- [[Claude]] +- [[Claude Pro]] +- [[指纹浏览器]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/entities/Prometheus.md b/wiki/entities/Prometheus.md new file mode 100644 index 00000000..affa40a2 --- /dev/null +++ b/wiki/entities/Prometheus.md @@ -0,0 +1,63 @@ +--- +title: "Prometheus" +type: entity +aliases: [Prometheus OSS, Prometheus监控] +tags: [monitoring, observability, time-series, alerting, prometheus] +date: 2025-11-11 +--- + +# Prometheus + +## Overview +Prometheus 是 CNCF 毕业的开源系统监控和告警工具包，最初由 SoundCloud 开发，现已广泛用于云原生和家居服务器环境。作为时序数据库，Prometheus 通过 pull 模式定期从已配置的 targets 抓取指标数据，支持强大的 PromQL 查询语言和灵活的告警规则引擎。 + +## Key Characteristics +- **Pull 模式**：Prometheus 服务器定期从各 exporter 的 HTTP `/metrics` 端点拉取指标，无需在被监控主机安装代理 +- **PromQL**：强大的查询语言，支持聚合、函数、即时向量和范围向量查询 +- **告警规则**：基于 PromQL 表达式定义告警条件，触发后发送给 Alertmanager +- **多数据出口**：支持 Remote Write 远端写入（VictoriaMetrics/Thanos/Cortex）、Grafana 可视化 +- **服务发现**：支持 Kubernetes、Consul、静态配置等多种发现机制 + +## Home Server Deployment +```yaml +# docker-compose.yml 片段 +prometheus: + image: prom/prometheus:latest + container_name: prometheus + volumes: + - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro + - ./prometheus/alerts.yml:/etc/prometheus/alerts.yml:ro + ports: + - "9090:9090" + command: + - '--config.file=/etc/prometheus/prometheus.yml' + - '--storage.tsdb.path=/prometheus' + - '--web.enable-lifecycle' +``` + +## Core Metrics Types +| 类型 | 示例 | 说明 | +|------|------|------| +| Gauge | `node_memory_MemAvailable_bytes` | 可增可减的当前值 | +| Counter | `node_cpu_seconds_total` | 只增不减的累计值 | +| Histogram | `prometheus_http_request_duration_seconds_bucket` | 分布统计 | +| Summary | `go_gc_duration_seconds` | 分位数统计 | + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Grafana]] — 可视化层 +- [[Alertmanager]] — 告警分发 +- [[node_exporter]] — 主机指标采集 +- [[cAdvisor]] — 容器指标采集 +- [[blackbox_exporter]] — HTTP/TCP 探测 +- [[Uptime Kuma]] — 合成监控（互补） + +## Related Concepts +- [[PromQL]] — Prometheus 查询语言 +- [[Prometheus告警规则]] — 告警条件定义 +- [[Exporter]] — 指标暴露组件 +- [[时序数据库]] — 数据存储模式 +- [[System Monitoring]] — 上游领域 +- [[Centralized Logging]] — 可互补的日志聚合方案 diff --git a/wiki/entities/Public-Cloud-Provider.md b/wiki/entities/Public-Cloud-Provider.md new file mode 100644 index 00000000..8dd5eb60 --- /dev/null +++ b/wiki/entities/Public-Cloud-Provider.md @@ -0,0 +1,69 @@ +--- +title: Public Cloud Provider +type: entity +tags: [cloud, infrastructure, provider] +date: 2026-04-19 +--- + +# Public Cloud Provider + +**Public Cloud Provider** 是指向多个组织和用户提供共享云计算资源（计算、存储、网络、应用）的第三方服务商。用户通过互联网按需访问这些资源，按使用量付费（Pay-as-you-go）。 + +## Definition + +第三方云服务商拥有并运营大规模数据中心，通过多租户（Multi-Tenancy）架构向公众或企业客户提供云服务。提供商负责基础设施的构建、维护、更新和安全。 + +## Major Providers + +- [[AWS]] — Amazon Web Services，市场份额领先 +- [[Azure]] — Microsoft Azure，企业市场优势 +- [[Google-Cloud]] — Google Cloud Platform，技术创新领先 +- [[Cloud-Computing]] ecosystem + +## Key Characteristics + +- **多租户架构**：多个用户共享底层物理资源，通过虚拟化实现隔离 +- **按需付费**：无前期资本投入，按实际使用量计费 +- **高弹性扩展**：根据需求快速扩缩资源 +- **全球化覆盖**：跨多个地理区域和可用区部署 +- **托管运维**：供应商负责硬件维护、安全更新和可用性管理 + +## Services Offered + +| 层级 | 服务类型 | 示例 | +|------|---------|------| +| IaaS | 基础设施 | EC2, Azure VMs, GCE | +| PaaS | 平台服务 | AWS Lambda, Azure App Service, Cloud Run | +| SaaS | 软件服务 | Office 365, Salesforce, Google Workspace | + +## Advantages (from Public Cloud perspective) + +- 无前期 CapEx 投入 +- 全球可达、有网络即可访问 +- 高技术敏捷性，弹性应对突发负载 +- 使用最新、最优配置的基础设施 +- 业务聚焦，减少内部 IT 复杂度 +- 远程协作友好 +- 快速灾难恢复（多地备份） + +## Limitations & Risks + +- 大规模使用时 TCO 可能指数增长 +- 多租户共享带来的安全顾虑 +- 合规需求可能无法完全满足 +- 对供应商的技术控制有限 +- 跨供应商迁移复杂、代价高（Vendor Lock-In） + +## Related Concepts + +- [[Public Cloud]] — 部署模式 +- [[Private Cloud]] — 对比模式 +- [[Hybrid Cloud]] — 公私结合 +- [[Multi-Cloud-Strategy]] — 多供应商策略 +- [[Vendor-Lock-In]] — 供应商锁定风险 +- [[Shared-Responsibility-Model]] — 责任分担框架 +- [[Pay-as-you-go]] — 定价模型 + +## Sources + +- [[Public vs Private vs Hybrid Cloud Differences Explained|sources/public-vs-private-vs-hybrid-cloud-differences-explained]] diff --git a/wiki/entities/Raj-Vardhan-Singh.md b/wiki/entities/Raj-Vardhan-Singh.md new file mode 100644 index 00000000..71260290 --- /dev/null +++ b/wiki/entities/Raj-Vardhan-Singh.md @@ -0,0 +1,36 @@ +--- +title: "The Myths and Misconceptions About Cloud Computing | LinkedIn" +type: source +tags: [cloud-computing, myths, misconceptions] +date: 2025-03-02 +--- + +## Summary + +本文由 LinkedIn 作者 Raj Vardhan Singh 发布，系统性反驳了云计算领域七大常见误解： + +1. **云不如本地安全** — 事实：云服务商在加密、MFA、防火墙及合规认证上的投入远超中小企业 IT 预算 +2. **"云不过是别人的电脑"** — 事实：云是具备冗余、自动故障转移和高可用性的大规模数据中心网络 +3. **云计算太贵** — 事实：按需付费 + 预留实例 + 自动扩缩 + 无服务器可显著降低成本 +4. **数据在云中失去控制** — 事实：云提供完善的权限管理、加密和混合/多云选项 +5. **只有大企业才适合云** — 事实：SMB 和初创企业同样受益于灵活定价和企业级技术 +6. **云迁移太复杂太危险** — 事实：分阶段迁移 + 混合云 + 专业服务可平滑过渡 +7. **云性能不可靠** — 事实：主流服务商 SLA 保障 99.99%+ 可用性 + +## Key Insights + +- **安全 > 本地**：云服务商通过 ISO 27001、HIPAA、GDPR 合规认证和 24/7 监控超越传统本地部署 +- **成本优化**：Reserved Instances、Auto Scaling、Serverless 是三大降本杠杆 +- **SLA 保障**：99.99% uptime = 每年停机 < 52 分钟，远超自建数据中心 +- **迁移策略**：Phased Migration + Hybrid Cloud + Professional Services 是成熟路径 + +## Sources + +- [[cloud-computing]] +- [[High-Availability]] +- [[cloud-security]] +- [[cloud-migration]] +- [[Cost-Optimization]] +- [[AWS]] +- [[Azure]] +- [[Google-Cloud]] diff --git a/wiki/entities/Rufus.md b/wiki/entities/Rufus.md new file mode 100644 index 00000000..978b4a6f --- /dev/null +++ b/wiki/entities/Rufus.md @@ -0,0 +1,43 @@ +--- +title: "Rufus" +type: entity +tags: [bootable-usb, uefi, iso, tool] +date: 2026-04-14 +aliases: [Rufus USB, Rufus 启动盘, Rufus工具] +--- + +# Rufus + +## Overview +Rufus 是一款开源（GPL v3）Windows U 盘启动盘制作工具，以体积小（~1MB）、速度快、支持广泛著称。是制作 Ubuntu 启动盘的首选工具之一。 + +## Core Features +- 制作 BIOS/UEFI 启动盘 +- 支持 ISOHybrid 镜像（Ubuntu 官方 ISO 属于此类） +- 转换磁盘格式（MBR ↔ GPT） +- 下载官方镜像文件 + +## Key Settings for HP ZBook + Ubuntu 24.04 +| 设置项 | 值 | 说明 | +|--------|-----|------| +| 设备 | 目标 U 盘 | 注意：会清空 U 盘数据 | +| 引导类型选择 | ubuntu-24.04.2-desktop-amd64.iso | 下载或手动选择 | +| 分区方案 | **GPT** | HP ZBook 必须用 GPT | +| 目标系统类型 | UEFI (non CSM) | 自动匹配 GPT | +| 文件系统 | FAT32 | UEFI 标准 | + +## ISOHybrid Mode Selection +写入时弹出对话框要求选择模式： +- **✅ ISO 镜像模式（推荐）**：保留 ISO 结构，兼容性最佳 +- **❌ DD 镜像模式（备选）**：逐字节复制，仅在 ISO 模式失败后使用 + +## Additional Downloads +Rufus 可能在写入时提示下载 `ldlinux.sys` 或 `ldlinux.bss` 引导文件，应点击"是"让工具自动下载以确保引导成功。 + +## Related +- [[HP ZBook]] — 目标安装设备 +- [[Ubuntu 24.04]] — 目标操作系统 +- [[ISOHybrid镜像]] — 镜像格式说明 +- [[GPT分区表]] — 分区方案 +- [[Rufus]] ← 制作启动盘 → [[HP ZBook]] +- [[Rufus]] ← 写入 → [[ISOHybrid镜像]] diff --git a/wiki/entities/Terraform.md b/wiki/entities/Terraform.md new file mode 100644 index 00000000..c479e854 --- /dev/null +++ b/wiki/entities/Terraform.md @@ -0,0 +1,119 @@ +--- +title: "Terraform" +type: entity +tags: + - devops + - iac + - infrastructure + - automation +created: 2026-04-25 +--- + +# Terraform + +## Definition + +Terraform 是 HashiCorp 开源的**基础设施即代码 (IaC)** 工具，通过声明式配置文件管理云资源。Agentic AI 代理审查 Terraform 脚本，在执行前建议改进，确保基础设施配置的可靠性和安全性。 + +## Aliases + +- Terraform +- Terraform IaC +- Infrastructure as Code + +## Relationship with [[Infrastructure-as-Code]] + +Terraform 是 [[Infrastructure-as-Code]] 实践的主要实现工具之一： + +``` +Infrastructure as Code Tools: +├── Terraform ← +├── CloudFormation (AWS) +├── Pulumi +├── Ansible +└── Pulumi +``` + +## Agentic AI IaC Management + +Agentic AI 在 Terraform 工作流中扮演审查者角色： + +``` +┌─────────────────────────────────────────────────┐ +│ Agentic AI IaC Management Workflow │ +├─────────────────────────────────────────────────┤ +│ │ +│ 1. Developer writes Terraform │ +│ ↓ │ +│ 2. Agentic AI reviews (auto) │ +│ ├── Security scan (IAM policies) │ +│ ├── Cost estimation │ +│ ├── Best practices check │ +│ └── Compliance validation │ +│ ↓ │ +│ 3. AI Suggestions │ +│ ├── "S3 bucket should enable encryption" │ +│ ├── "Remove hardcoded credentials" │ +│ └── "Consider using modules for reuse" │ +│ ↓ │ +│ 4. Apply (after approval) │ +│ │ +└─────────────────────────────────────────────────┘ +``` + +## AI Review Capabilities + +| Check Type | Description | +|------------|-------------| +| **Security** | IAM 过度权限、公开 S3 访问、硬编码密钥 | +| **Cost** | 资源过度配置、未使用资源识别 | +| **Compliance** | 标签规范、资源命名、区域限制 | +| **Best Practices** | 模块化、状态管理、回滚计划 | + +## Example + +> Agentic AI reviews Terraform plan: +> ```hcl +> resource "aws_s3_bucket" "data" { +> bucket = "my-sensitive-data" +> } +> ``` +> +> AI Detection: +> - ⚠️ **Security Risk**: Bucket is public by default +> - ⚠️ **Missing**: Encryption not enabled +> - ⚠️ **Missing**: Versioning not enabled +> +> AI Suggestions: +> ```hcl +> resource "aws_s3_bucket" "data" { +> bucket = "my-sensitive-data" +> +> server_side_encryption_configuration { +> rule { +> apply_server_side_encryption_by_default { +> sse_algorithm = "AES256" +> } +> } +> } +> } +> +> versioning { enabled = true } +> acl = "private" # Block public access +> ``` + +## Related Concepts + +- [[Infrastructure-as-Code]] — Terraform 是 IaC 的实现工具 +- [[Automated Security Audit]] — AI 审查 Terraform 安全 +- [[Cloud-Native]] — IaC 支持 Cloud-Native 实践 +- [[Multi-Account Deployment]] — Terraform HCP/Cloud 多账户部署与 CloudFormation StackSets 对比 +- [[AWS CloudFormation StackSets]] — AWS 原生多账户 IaC 部署工具，与 Terraform 有功能重叠 + +## Related Entities + +- [[AWS CloudFormation StackSets]]：AWS 原生多账户部署服务，与 Terraform 在多账户 IaC 场景形成对比 + +## Related Sources + +- [[how-agentic-ai-can-help-for-cloud-devops]] diff --git a/wiki/entities/Ubuntu-Server.md b/wiki/entities/Ubuntu-Server.md new file mode 100644 index 00000000..1dd868e5 --- /dev/null +++ b/wiki/entities/Ubuntu-Server.md @@ -0,0 +1,154 @@ +--- +title: "Ubuntu Server" +type: entity +aliases: [Ubuntu, Ubuntu Server LTS, Ubuntu 24.04] +tags: [linux, server, lts, canonical] +--- + +# Ubuntu Server + +## Overview +**Ubuntu Server** 是由 Canonical 维护的 Linux 服务器操作系统，提供服务器优化的发行版，不包含图形桌面环境。Ubuntu Server 24.04 LTS 是当前的长期支持版本（LTS），默认使用 **systemd** 作为初始化系统，SSH 默认使用 **ssh.socket**（按需激活）替代传统的 sshd 持续运行模式。 + +## Key Characteristics + +|| 特性 | 说明 | +|------|------| +| **维护周期** | LTS 版本 5 年安全更新（Extended Security Maintenance 额外 5 年）| +| **默认初始化系统** | systemd | +| **SSH 默认配置** | ssh.socket（按需激活），可切换为 ssh.service | +| **软件包管理** | APT (apt/apt-get) | +| **内核** | 通用 Linux 内核，支持云镜像、容器优化镜像等 | +| **适用场景** | 云服务器、物理服务器、容器宿主机、边缘计算 | + +## Ubuntu Server 24.04 的关键变化 + +### 1. SSH 默认使用 Socket Activation +Ubuntu 24.04 SSH 服务默认使用 ssh.socket（按需激活）： +- **ssh.socket**：无 SSH 连接时不运行 sshd 进程，节省资源 +- **ssh.service**：传统模式，sshd 持续运行 +- 切换方法： +```bash +# 切换到传统模式（推荐服务器） +sudo systemctl disable --now ssh.socket +sudo systemctl enable --now ssh.service + +# 切回按需模式 +sudo systemctl disable --now ssh.service +sudo systemctl enable --now ssh.socket +``` + +### 2. Netplan 网络配置 +Ubuntu Server 使用 Netplan（YAML 配置）管理网络： +```yaml +# /etc/netplan/00-installer-config.yaml +network: + version: 2 + renderer: networkd # 或 NetworkManager + ethernets: + eth0: + addresses: + - 192.168.1.100/24 + gateway4: 192.168.1.1 + nameservers: + addresses: + - 8.8.8.8 + - 8.8.4.4 +``` +```bash +sudo netplan apply # 应用配置 +sudo netplan generate # 生成 systemd-networkd 配置 +sudo netplan debug # 调试配置 +``` + +### 3. Snap vs APT +Ubuntu 提供了两套包管理生态： +- **APT**：传统 Debian 包管理，deb 包，/var/lib/apt/lists 存储索引 +- **Snap**：Canonical 开发的容器化包格式，自包含依赖，自动更新 +- 典型场景：FRP 建议使用 APT 安装二进制或手动解压，不建议 snap + +## Common Operations + +### 安装软件 +```bash +sudo apt update # 更新软件包索引 +sudo apt install -y # 安装软件包 +sudo apt remove # 卸载软件包 +sudo apt autoremove # 清理不再需要的依赖 +``` + +### 系统更新 +```bash +sudo apt update && sudo apt upgrade -y # 更新所有包 +sudo apt full-upgrade -y # 包含内核更新的完整升级 +sudo do-release-upgrade # 升级到新版本 +``` + +### 用户管理 +```bash +sudo adduser # 创建用户 +sudo usermod -aG sudo # 添加到 sudo 组 +sudo visudo # 编辑 sudoers 文件 +``` + +### 防火墙 (UFW) +```bash +sudo ufw status # 查看状态 +sudo ufw allow 22/tcp # 开放 SSH +sudo ufw allow 80/tcp # 开放 HTTP +sudo ufw enable # 启用防火墙 +sudo ufw disable # 禁用防火墙 +``` + +### 服务管理 (systemd) +```bash +sudo systemctl status # 查看服务状态 +sudo systemctl enable --now # 开机自启并立即启动 +sudo systemctl restart # 重启服务 +sudo journalctl -u -f # 查看服务日志 +``` + +### Snap 操作 +```bash +snap list # 列出已安装的 snap +snap install # 安装 snap +snap remove # 卸载 snap +snap refresh # 更新所有 snap +``` + +## Ubuntu Server vs Ubuntu Desktop + +| 方面 | Ubuntu Server | Ubuntu Desktop | +|------|--------------|----------------| +| **默认包** | 无 GUI，服务器工具 | GUI 桌面环境 | +| **内核** | 服务器优化内核 | 桌面优化内核 | +| **SSH** | 已预装 | 需手动安装 | +| **资源占用** | 轻量（~500MB RAM） | 较重（~2GB RAM） | +| **适用场景** | 云服务器、NAS、容器宿主机 | 开发工作站 | +| **更新频率** | LTS 优先稳定性 | 更频繁的新特性 | + +## Home Server Applications on Ubuntu Server +Ubuntu Server 是家庭服务器的理想选择： +- **NAS 存储**：Samba/NFS/RAID 配置 +- **Docker 容器**：Portainer/Transmission/Jellyfin/Navidrome +- **FRP 内网穿透**：frpc 连接公网 VPS +- **媒体服务器**：Jellyfin/Navidrome/Emby +- **下载服务**：Transmission/Deluge/qBittorrent +- **监控服务**：Prometheus/Grafana/Nagios +- **Home Automation**：Home Assistant + +## Related Concepts +- [[systemd]] — Ubuntu Server 的默认初始化系统 +- [[UFW 防火墙]] — Ubuntu Server 推荐的防火墙工具 +- [[Docker]] — Ubuntu Server 常用容器运行时 +- [[内网穿透]] — FRP 在 Ubuntu Server 上的应用场景 +- [[Cron定时任务]] — Ubuntu Server 定时任务管理 + +## Related Entities +- [[VPS]] — Ubuntu Server 常部署在公网 VPS 上作为 frps 服务端 +- [[群晖 NAS]] — Ubuntu Server vs 群晖 NAS 的功能对比 +- [[frp]] — 在 Ubuntu Server 上运行的 frpc 客户端 + +## References +- Ubuntu Server Documentation: https://ubuntu.com/server/docs +- Ubuntu 24.04 LTS Release Notes: https://discourse.ubuntu.com/t/noble-numbat-release-notes/ diff --git a/wiki/entities/Uptime-Kuma.md b/wiki/entities/Uptime-Kuma.md new file mode 100644 index 00000000..5387ea6a --- /dev/null +++ b/wiki/entities/Uptime-Kuma.md @@ -0,0 +1,64 @@ +--- +title: "Uptime Kuma" +type: entity +aliases: [uptime-kuma, Louislam Uptime Kuma] +tags: [monitoring, uptime, http, tls, self-hosted] +date: 2025-11-11 +--- + +# Uptime Kuma + +## Overview +Uptime Kuma 是开源的自托管 uptime monitoring 工具，被称为"自托管的 UptimeRobot"，由 louislam 开发。它通过模拟 HTTP/TCP/DNS/TLS 请求来检测服务可用性，支持历史记录存储和丰富的通知通道。相比 Prometheus + blackbox_exporter 方案，Uptime Kuma 提供了更友好的 Web UI 和更低的配置门槛，适合家庭用户快速搭建合成监控。 + +## Key Characteristics +- **友好 Web UI**：现代化的监控面板，无需编写 YAML 配置文件 +- **多协议支持**：HTTP(S)、TCP、DNS、TLS 证书、Ping、Steam 游戏服务器 +- **通知通道**：邮件、Slack、Telegram、Discord、Webhook、PagerDuty 等 +- **历史记录**：持久化的 uptime 历史和响应时间图表 +- **证书监控**：自动检测 TLS 证书到期并告警 +- **Docker 部署**：一条命令即可启动 + +## Home Server Deployment +```yaml +# docker-compose.yml 片段（来源：uptimekuma.org） +version: '3.8' +services: + uptime-kuma: + image: louislam/uptime-kuma:latest + container_name: uptime-kuma + restart: unless-stopped + ports: + - "3001:3001" + volumes: + - ./uptime-kuma-data:/app/data + environment: + - TZ=Asia/Shanghai +``` + +访问 `http://localhost:3001` 完成初始化（首次访问时设置管理员账户）。 + +## Comparison: Uptime Kuma vs Prometheus blackbox_exporter +| 维度 | Uptime Kuma | blackbox_exporter | +|------|-------------|------------------| +| 配置方式 | Web UI 点点点 | YAML 配置文件 | +| 学习门槛 | 低 | 中 | +| 数据持久化 | 内置 SQLite | 依赖 Prometheus 存储 | +| 仪表盘 | 内置 | 需 Grafana | +| 告警配置 | UI 绑定通知 | Prometheus rules | +| 适合场景 | 快速验证、家庭使用 | 生产级、规模化 | + +## Use Case +Uptime Kuma 适合外网/内网服务可用性的快速监控搭建。配合 Prometheus + blackbox_exporter 使用：Uptime Kuma 负责外网端点快速告警，blackbox_exporter 负责更细粒度的指标（响应时间分布、证书剩余天数）。 + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Prometheus]] — 互补的 Prometheus blackbox_exporter +- [[blackbox_exporter]] — 细粒度探测方案 +- [[Alertmanager]] — 告警分发 + +## Related Concepts +- [[合成监控]] — 核心应用场景 +- [[System Monitoring]] — 上游领域 diff --git a/wiki/entities/Veeam.md b/wiki/entities/Veeam.md new file mode 100644 index 00000000..fbac8bfc --- /dev/null +++ b/wiki/entities/Veeam.md @@ -0,0 +1,81 @@ +--- +title: "Veeam" +type: entity +aliases: [Veeam Backup, Veeam Software] +tags: [cloud, disaster-recovery, backup, enterprise, infrastructure] +date: 2026-04-25 +--- + +# Veeam + +**Veeam** 是一个企业级数据保护和灾备解决方案提供商，专注于虚拟机备份、服务器镜像和跨区域复制，是传统灾备工具的代表。 + +## Overview + +Veeam 是传统灾备（Disaster Recovery）领域的主流工具，主要功能： + +- **虚拟机备份**：VMware vSphere、Hyper-V +- **服务器镜像**：物理和虚拟服务器的完整镜像 +- **跨区域复制**：异地数据复制，支持 RTO/RPO 优化 +- **云端备份**：AWS、Azure、 GCP 云工作负载保护 +- **恢复验证**：自动化恢复测试 + +## 定位：传统灾备 + +Veeam 代表的是传统灾备思路：保护**基础设施层**，应对**硬件故障**和**数据中心级灾难**。 + +| 维度 | Veeam（传统） | [[Feature Flag]]（现代） | +|------|---------------|------------------------| +| 保护对象 | 虚拟机、服务器、数据 | 代码、功能、部署 | +| 故障类型 | 硬件故障、数据中心灾难 | 代码变更、Bug | +| RTO | 小时级（从备份恢复） | 秒级（配置变更） | +| 故障频率 | 低（年均几次） | 高（每周可能发生） | +| 成本模型 | 基础设施投资 | 软件订阅 | + +## 与 [[RTO]]/[[RPO]] 的关系 + +Veeam 主要影响的是**基础设施级别**的 RTO 和 RPO： + +| 场景 | VTO | RPO | 说明 | +|------|-----|-----|------| +| 从 Veeam 备份恢复 VM | 小时级 | 取决于备份频率 | 需要重建基础设施 | +| Veeam 即时恢复 | 分钟级 | 小时级 | 仍然需要恢复数据 | +| Veeam CDP（连续数据保护） | 分钟级 | 秒级 | 高成本 | + +## 典型部署场景 + +- **数据中心故障**：服务器硬件损坏、火宅、水灾 +- **勒索软件攻击**：从干净备份恢复 +- **合规要求**：长期数据保留 +- **迁移场景**：P2V、V2V 迁移 + +## 竞品 + +| 工具 | 定位 | +|------|------| +| Veeam | 企业级虚拟机备份 | +| Acronis | 跨平台备份+安全 | +| Rubrik | 云原生数据保护 | +| Commvault | 企业数据管理 | +| [[Acronis]] | 跨区域复制 | + +## 局限性 + +Veeam 无法解决**软件层面的问题**： + +- 无法防止 Bug 部署 +- 无法实现 Feature Flag 级别的快速回滚 +- 无法支持渐进放量 +- 灾备触发频率低，无法应对日常代码变更风险 + +## Related Concepts + +- [[Disaster Recovery]] — Veeam 是传统灾备工具 +- [[RTO]] — Veeam 优化基础设施级 RTO +- [[RPO]] — Veeam 优化数据保护级 RPO +- [[Acronis]] — 竞品灾备工具 +- [[LaunchDarkly]] — 代表现代软件层灾备方案 + +## Sources + +- [[sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md]] diff --git a/wiki/entities/VictoriaMetrics.md b/wiki/entities/VictoriaMetrics.md new file mode 100644 index 00000000..4b6d43bf --- /dev/null +++ b/wiki/entities/VictoriaMetrics.md @@ -0,0 +1,58 @@ +--- +title: "VictoriaMetrics" +type: entity +aliases: [VictoriaMetrics, VM, vmstorage] +tags: [time-series, prometheus, long-term-storage, monitoring, scalable] +date: 2025-11-11 +--- + +# VictoriaMetrics + +## Overview +VictoriaMetrics 是高性能、成本优化的时序数据库，专为 Prometheus 设计，提供长期存储和高可用方案。相比原生 Prometheus TSDB，VictoriaMetrics 支持几乎无限的存储扩展，同时保持与 Prometheus Remote Write API 和 PromQL 的完全兼容。常见于单主机和小型集群场景的长期存储替代。 + +## Key Characteristics +- **Prometheus 兼容**：100% 兼容 PromQL，支持 Remote Write 协议 +- **高性能写入**：单节点支持每秒百万级指标写入 +- **资源效率**：比 Prometheus TSDB 更低内存和磁盘占用 +- **长期存储**：支持数据分层（热数据/冷数据）和压缩归档 +- **集群模式**：支持水平扩展，满足大规模需求 +- **单一二进制**：无外部依赖，开箱即用 + +## Prometheus Remote Write Integration +```yaml +# prometheus.yml +remote_write: + - url: http://victoriametrics:8428/api/v1/write + # 可选：queue 配置 + queue_config: + capacity: 10000 + max_shards: 30 + min_shards: 1 + max_samples_per_send: 10000 +``` + +## Use Cases +1. **长期数据保留**：存储超过 30 天的指标数据 +2. **多 Prometheus 聚合**：接收多个 Prometheus 实例数据集中查询 +3. **高性能写入**：高 cardinality 指标场景（如微服务 Kubernetes 集群） +4. **成本优化**：降低 Prometheus 存储成本 + +## Comparison +| 维度 | VictoriaMetrics | Prometheus TSDB | Thanos | +|------|---------------|----------------|--------| +| 部署复杂度 | 低 | 极低 | 高 | +| 扩展性 | 中（集群模式） | 无 | 高 | +| 存储成本 | 低 | 中 | 中 | +| 兼容性 | PromQL 100% | 原生 | Sidecar 模式 | +| 适用规模 | 中小型 | 单实例 | 大型多租户 | + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Prometheus]] — 数据源和写入端 + +## Related Concepts +- [[时序数据库]] — 数据存储层 +- [[Exporter]] — 数据来源 diff --git a/wiki/entities/WildCard.md b/wiki/entities/WildCard.md new file mode 100644 index 00000000..7b22ee6f --- /dev/null +++ b/wiki/entities/WildCard.md @@ -0,0 +1,36 @@ +--- +title: "WildCard" +type: entity +tags: [virtual-credit-card, payment, cross-border] +date: 2025-12-31 +--- + +# WildCard + +## 基本信息 +- **类型**: 金融工具/服务 +- **官网**: https://yeka.ai/i/UPHSP +- **用途**: 虚拟信用卡，跨境支付 +- **充值方式**: 支付宝 + +## 功能特性 +- **虚拟信用卡**: 不依赖实体卡，线上即时开通 +- **海外支付**: 支持订阅海外服务 +- **支付宝充值**: 便于国内用户充值 +- **Claude Pro订阅**: 可用于支付20美元/月的Claude Pro + +## 使用场景 +- 订阅Claude Pro等海外AI服务 +- 无法使用国内信用卡的跨境支付场景 +- 需要匿名或临时使用的支付场景 + +## Aliases +- 无 + +## 相关页面 +- [[虚拟信用卡]] +- [[Claude Pro]] +- [[跨境支付]] + +## 来源 +- [[如何用指纹浏览器安全注册并订阅claude-pro会员全攻略]] diff --git a/wiki/entities/blackbox-exporter.md b/wiki/entities/blackbox-exporter.md new file mode 100644 index 00000000..fc46e9d4 --- /dev/null +++ b/wiki/entities/blackbox-exporter.md @@ -0,0 +1,84 @@ +--- +title: "blackbox_exporter" +type: entity +aliases: [Blackbox Exporter, Prometheus Blackbox Exporter] +tags: [monitoring, probing, http, tls, prometheus, network] +date: 2025-11-11 +--- + +# blackbox_exporter + +## Overview +blackbox_exporter 是 Prometheus 官方的黑盒探测 exporter，允许通过 HTTP、HTTPS、DNS、TCP、ICMP 等协议探测端点的可用性和响应质量。它不依赖目标系统的内部指标，而是从外部视角模拟真实请求，检测服务是否可达、响应是否正常、TLS 证书是否即将到期。 + +## Key Characteristics +- **黑盒探测**：不依赖目标内部指标，从外部检测服务健康状态 +- **多协议支持**：HTTP、HTTPS、DNS、TCP、ICMP、SSH +- **TLS 证书监控**：检测证书到期时间，支持提前告警 +- **Prometheus 集成**：通过 `probe_success`、`probe_duration_seconds` 等指标暴露探测结果 + +## Key Metrics +| 指标 | 说明 | 用例 | +|------|------|------| +| `probe_success` | 探测是否成功（0/1） | HTTP 可用性告警 | +| `probe_duration_seconds` | 探测耗时（秒） | 响应时间告警 | +| `probe_http_status_code` | HTTP 响应码 | 4xx/5xx 检测 | +| `probe_ssl_earliest_cert_expiry` | TLS 证书最早到期时间（Unix 时间戳） | 证书到期告警 | +| `probe_dns_lookup_duration_seconds` | DNS 解析耗时 | DNS 健康检测 | + +## Prometheus scrape_config +```yaml +- job_name: 'blackbox_http' + metrics_path: /probe # 关键：不是 /metrics，而是 /probe + params: + module: [http_2xx] # 使用 http_2xx 模块 + static_configs: + - targets: + - "https://pq2435887bh.vicp.fun" + - "http://shenwei-nas.vip.cpolar.cn" + relabel_configs: + - source_labels: [__address__] + target_label: __param_target + - target_label: __address__ + replacement: blackbox:9115 # 指向 blackbox_exporter +``` + +## Home Server Deployment +```yaml +# docker-compose.yml 片段 +blackbox: + image: prom/blackbox-exporter:latest + container_name: blackbox + restart: always + ports: + - "9115:9115" +``` + +## Key Alerts (PromQL) +```yaml +# HTTP 探测失败告警 +- alert: HTTPProbeFailed + expr: probe_success == 0 + for: 2m + labels: + severity: critical + +# TLS 证书即将到期（14天） +- alert: TLSCertExpiring + expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 14 + for: 1h + labels: + severity: warning +``` + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Prometheus]] — 数据消费者 +- [[Uptime Kuma]] — 互补的合成监控工具 + +## Related Concepts +- [[Exporter]] — Prometheus 生态组件 +- [[合成监控]]（Synthetic Monitoring）— 黑盒探测的核心应用场景 +- [[System Monitoring]] — 应用领域 diff --git a/wiki/entities/bottom.md b/wiki/entities/bottom.md new file mode 100644 index 00000000..0ce2f559 --- /dev/null +++ b/wiki/entities/bottom.md @@ -0,0 +1,35 @@ +--- +title: "Bottom" +type: entity +aliases: [bottom] +tags: [linux, system-monitoring, open-source, tu i, graphing] +date: 2025-12-18 +--- + +# Bottom + +专注实时性能图表绘制的TUI监控工具，不提供进程管理功能。 + +## Overview +Bottom 是一款专注于CPU、网络、内存实时图表可视化的TUI监控工具，与其他工具不同，它不提供交互式进程管理，纯属性能观测用途。 + +## Key Features +- **实时图表**：专注绘制CPU、网络、内存的实时性能曲线 +- **进程树视图**：可显示进程层级关系 +- **非交互式**：纯监控工具，不可用于任务管理 +- **安装方式**： + - Arch/Pacman：官方仓库 + - Debian/Ubuntu：Snap包 + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[TUI]] ← interface type +- [[System Monitoring]] ← core feature (graphing focus) +- [[Resource Monitor]] ← tool category + +## Related Entities +- [[Btop++]] — 提供完整功能集（监控+管理） +- [[Glances]] — 轻量级替代 +- [[Htop]] — 进程管理替代 diff --git a/wiki/entities/btop++.md b/wiki/entities/btop++.md new file mode 100644 index 00000000..434a0f43 --- /dev/null +++ b/wiki/entities/btop++.md @@ -0,0 +1,41 @@ +--- +title: "Btop++" +type: entity +aliases: [btop++, btop-plusplus] +tags: [linux, system-monitoring, open-source, tu i] +date: 2025-12-18 +--- + +# Btop++ + +TUI风格的系统资源监控器，是作者的Top Pick。 + +## Overview +Btop++ 是一款功能全面的TUI（文本用户界面）系统监控工具，在终端中提供实时CPU、内存、网络、存储监控和交互式进程管理。 + +## Key Features +- **多面板布局**：CPU活动（顶部）、进程列表（右侧）、内存/存储/网络（左侧） +- **交互式进程管理**： + - `f` 搜索进程 + - `t` 发送终止信号（允许应用保存数据） + - `k` 立即杀死进程 + - `s` 发送其他信号 + - Nice值调整（进程优先级） +- **主题定制**：支持多皮肤和配色方案切换 +- **安装方式**： + - Arch/Pacman：官方仓库直接安装 + - Debian/Ubuntu：Snap包安装 + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[TUI]] ← interface type +- [[Process Management]] ← core feature +- [[System Monitoring]] ← core feature +- [[Btop++]] → implements → [[Resource Monitor]] + +## Related Entities +- [[Htop]] — 更轻量的替代品 +- [[Glances]] — 超轻量替代 +- [[Bottom]] — 图表为主的选择 diff --git a/wiki/entities/cAdvisor.md b/wiki/entities/cAdvisor.md new file mode 100644 index 00000000..1a06a540 --- /dev/null +++ b/wiki/entities/cAdvisor.md @@ -0,0 +1,67 @@ +--- +title: "cAdvisor" +type: entity +aliases: [cAdvisor, Container Advisor, Google cAdvisor] +tags: [monitoring, container, docker, prometheus, kubernetes] +date: 2025-11-11 +--- + +# cAdvisor + +## Overview +cAdvisor（Container Advisor）是 Google 开源的容器资源监控工具，专门为 Docker 容器提供资源使用和性能指标的采集。它能自动发现机器上运行的所有容器，收集包括 CPU、内存、网络、磁盘 I/O 在内的各项资源指标，并暴露 Prometheus 格式的 `/metrics` 端点。 + +## Key Characteristics +- **自动发现**：自动发现并监控机器上所有 Docker 容器，无需手动配置 +- **容器层级指标**：单容器粒度的资源使用数据 +- **历史数据**：支持容器级别的资源历史趋势 +- **Docker Socket 依赖**：需要挂载 `/var/run/docker.sock` 访问容器运行时信息 + +## Key Metrics Collected +| 分类 | 指标前缀 | 说明 | +|------|----------|------| +| CPU | `container_cpu_usage_seconds_total` | 容器 CPU 使用时间 | +| 内存 | `container_memory_usage_bytes` | 容器内存使用量 | +| 网络 | `container_network_receive_bytes_total` | 网络接收字节 | +| 磁盘 | `container_fs_reads_bytes_total` | 磁盘读取字节 | +| 进程 | `container_tasks` | 容器内任务/进程数 | +| 重启 | `container_restart_count` | 容器重启次数 | +| 资源限制 | `container_spec_memory_limit_bytes` | 内存限制值 | + +## Home Server Deployment +```yaml +# docker-compose.yml 片段 +cadvisor: + image: gcr.io/cadvisor/cadvisor:latest + container_name: cadvisor + restart: always + ports: + - "8080:8080" # 暴露 metrics 端点 + volumes: + - /:/rootfs:ro # 根文件系统 + - /var/run:/var/run:ro # Docker socket 目录 + - /sys:/sys:ro + - /var/lib/docker/:/var/lib/docker:ro # Docker 存储 +``` + +> ⚠️ **安全注意**：挂载 Docker socket（`/var/run/docker.sock`）授予容器等同于宿主机 root 的权限。审慎评估风险，仅在内网可信环境中使用。 + +## Prometheus scrape_config +```yaml +- job_name: 'cadvisor' + static_configs: + - targets: ['cadvisor:8080'] +``` + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Prometheus]] — 数据消费者 +- [[Docker]] — 容器运行时依赖 +- [[node_exporter]] — 互补的主机层指标 + +## Related Concepts +- [[Exporter]] — Prometheus 生态组件 +- [[容器资源限制]] — 容器 OOM / CPU 限制配置 +- [[System Monitoring]] — 应用领域 diff --git a/wiki/entities/clouddrive2.md b/wiki/entities/clouddrive2.md new file mode 100644 index 00000000..91963b0b --- /dev/null +++ b/wiki/entities/clouddrive2.md @@ -0,0 +1,53 @@ +--- +title: "CloudDrive2" +type: entity +tags: [云盘, 挂载, nas, synology, 阿里云盘] +date: 2025-12-29 +--- + +# CloudDrive2 + +## Aliases +- CloudDrive +- Cloud Drive 2 + +## Description +CloudDrive2 是一款云盘挂载工具，通过虚拟文件系统将阿里云盘、Google Drive、OneDrive、Dropbox 等主流云存储服务挂载为本地目录，用户可直接在文件管理器中访问和操作云端文件，无需手动同步。 + +## Key Features +- 多云盘支持：阿里云盘、天翼云、115、夸克等多种国内云盘 +- 本地挂载：挂载后如同本地磁盘使用，支持读写操作 +- Web UI 管理：提供独立管理界面（默认端口 19798） +- 自动扫描授权：支持手机 App 扫码授权 +- 文件夹级控制：可选择仅挂载特定目录，实现最小权限访问 + +## Installation on Synology NAS +1. 在套件中心添加矿神源 +2. 在矿神源社群中找到 CloudDrive2 并安装 +3. 对于 DSM 7+，需执行 Root 权限修复命令： + ```bash + sudo -i + # 输入 NAS admin 密码 + sudo sed -i 's/package/root/g' /var/packages/CloudDrive2/conf/privilege + ``` + +## Access Configuration +- 默认访问地址：`http://:19798/` +- 授权方式：使用阿里云盘 App 扫描二维码 +- 权限建议：仅授权"资源目录"，不授权"备份目录" + +## Connections +- [[Synology NAS]] — 部署平台 +- [[矿神源]] — 安装来源 +- [[阿里云盘]] — 主要挂载目标 +- [[群晖NAS科学上网]] — 相关场景 +- [[Navidrome]] — 可与 Navidrome 配合实现云端音乐播放 +- [[Jellyfin]] — 可与 Jellyfin 配合实现云端视频播放 + +## Related Concepts +- [[云盘挂载]] +- [[虚拟文件系统]] +- [[NAS套件管理]] + +## References +- Source: [[在Synology NAS上安装CloudDrive2]] diff --git a/wiki/entities/containerd.md b/wiki/entities/containerd.md new file mode 100644 index 00000000..e8341e84 --- /dev/null +++ b/wiki/entities/containerd.md @@ -0,0 +1,28 @@ +--- +title: "containerd" +tags: [docker, container, runtime] +date: 2026-04-22 +--- + +# containerd + +## Definition +containerd 是 Docker 的容器运行时底层引擎，现已捐赠给 CNCF 成为独立毕业项目。它负责容器的完整生命周期管理：镜像拉取、容器创建、进程运行、资源隔离。 + +## Architecture Position +``` +docker CLI → dockerd → containerd → runc → containers +``` + +## Key Characteristics +- **CNCF 毕业项目**：Kubernetes 默认使用的容器运行时 +- **OCI 标准兼容**：支持 OCI 镜像和运行时规范 +- **轻量级**：专注容器管理，不包含网络和存储编排 + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] — Docker Engine 安装时会同时安装 containerd.io + +## Related Concepts +- [[Docker Engine]] — containerd 的上层封装 +- [[Docker Compose]] — 通过 Docker Engine 间接使用 containerd +- [[Docker 用户组]] — 控制 Docker Engine 访问权限 diff --git a/wiki/entities/docker-buildx-plugin.md b/wiki/entities/docker-buildx-plugin.md new file mode 100644 index 00000000..9d9e4a95 --- /dev/null +++ b/wiki/entities/docker-buildx-plugin.md @@ -0,0 +1,22 @@ +--- +title: "docker-buildx-plugin" +tags: [docker, build, plugin] +date: 2026-04-22 +--- + +# docker-buildx-plugin + +## Definition +docker-buildx 是 Docker 的多平台镜像构建插件，支持在单一构建过程中为多个 CPU 架构（amd64、arm64 等）和操作系统生成镜像，是 Docker BuildKit 的一部分。 + +## Key Features +- **多平台构建**：一次构建生成多种架构镜像 +- **BuildKit 后端**：利用 BuildKit 的缓存和并发构建能力 +- **自定义构建器**：支持创建和管理多个构建器实例 + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] — 安装命令包含此插件 + +## Related Concepts +- [[Docker Engine]] — buildx 通过 Docker Engine 集成 +- [[Docker Compose]] — compose 使用 buildx 进行镜像构建 diff --git a/wiki/entities/docker-ce.md b/wiki/entities/docker-ce.md new file mode 100644 index 00000000..6439ae39 --- /dev/null +++ b/wiki/entities/docker-ce.md @@ -0,0 +1,29 @@ +--- +title: "Docker CE" +tags: [docker, package] +date: 2026-04-22 +--- + +# Docker CE (Community Edition) + +## Definition +Docker Community Edition (CE) 是 Docker 的开源版本，包含 Docker Engine 及其所有核心组件。 + +## Package Components +| 包名 | 说明 | +|------|------| +| `docker-ce` | Docker Engine 主包 | +| `docker-ce-cli` | Docker CLI 命令行工具 | +| `containerd.io` | containerd 容器运行时 | +| `docker-buildx-plugin` | 多平台镜像构建插件 | +| `docker-compose-plugin` | Docker Compose V2 插件 | + +## Installation +```bash +# 完整安装命令 +sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin +``` + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] — Docker CE 完整安装流程 +- [[Docker Engine]] — Docker CE 的核心组件 diff --git a/wiki/entities/docker-compose-plugin.md b/wiki/entities/docker-compose-plugin.md new file mode 100644 index 00000000..376ce627 --- /dev/null +++ b/wiki/entities/docker-compose-plugin.md @@ -0,0 +1,35 @@ +--- +title: "docker-compose-plugin" +tags: [docker, compose, plugin] +date: 2026-04-22 +--- + +# docker-compose-plugin + +## Definition +docker-compose-plugin 是 Docker Compose V2 的插件形式，作为 Docker CLI 扩展实现，通过 `docker compose` 子命令调用，而非独立的 `docker-compose` 命令。 + +## V1 vs V2 命令对比 +| V1 (独立包) | V2 (插件) | +|------------|-----------| +| `docker-compose up -d` | `docker compose up -d` | +| `docker-compose ps` | `docker compose ps` | +| `docker-compose down` | `docker compose down` | + +## Installation +V2 插件在安装 `docker-compose-plugin` 包后自动集成到 `docker` CLI： +```bash +sudo apt-get install docker-compose-plugin +docker compose version # 验证 +``` + +## Aliases +- docker-compose-plugin +- Docker Compose V2 + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] — V2 安装配置说明 + +## Related Concepts +- [[Docker Compose]] — 上层概念 +- [[Docker Engine]] — V2 插件依赖 Docker Engine diff --git a/wiki/entities/docker-engine.md b/wiki/entities/docker-engine.md new file mode 100644 index 00000000..369bb94a --- /dev/null +++ b/wiki/entities/docker-engine.md @@ -0,0 +1,54 @@ +--- +title: "Docker Engine" +tags: [docker, container] +date: 2026-04-22 +--- + +# Docker Engine + +## Definition +Docker Engine 是 Docker 的核心运行时组件，包含三个主要部分： +- **dockerd**：Docker 守护进程，管理容器生命周期 +- **docker CLI**：命令行客户端，与 dockerd 通信 +- **containerd**：容器运行时底层引擎（独立项目） + +## Package Components +| 包名 | 作用 | +|------|------| +| `docker-ce` | Docker Community Edition 引擎主包 | +| `docker-ce-cli` | Docker 命令行工具 | +| `containerd.io` | containerd 的 Docker 打包版本 | +| `docker-buildx-plugin` | 多平台镜像构建插件 | +| `docker-compose-plugin` | Docker Compose V2 插件 | + +## Installation Sources +- **官方 apt 仓库**（推荐）：从 `download.docker.com` 安装，确保获取最新版本 +- **系统默认仓库**：版本可能较旧，不推荐 + +## Key Commands +```bash +# 验证安装 +sudo docker run hello-world + +# 查看版本 +docker --version +docker compose version + +# 管理服务 +sudo systemctl start docker +sudo systemctl enable docker +``` + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] + +## Related Concepts +- [[Docker Compose]] — 多容器编排工具 +- [[Docker 用户组]] — 非 root 用户权限配置 +- [[APT 仓库配置]] — Docker 官方仓库配置方式 +- [[GPG 密钥验证]] — apt 包验证机制 +- [[containerd]] — 容器运行时底层 + +## Related Entities +- [[Docker-CE]] — Docker Community Edition 主包 +- [[hello-world]] — Docker 官方测试镜像 diff --git a/wiki/entities/glances.md b/wiki/entities/glances.md new file mode 100644 index 00000000..4f5f58ba --- /dev/null +++ b/wiki/entities/glances.md @@ -0,0 +1,39 @@ +--- +title: "Glances" +type: entity +aliases: [glances] +tags: [linux, system-monitoring, open-source, tu i] +date: 2025-12-18 +--- + +# Glances + +超轻量级TUI系统监控器，专注速度和SSH友好性。 + +## Overview +Glances 是一款极度轻量化的TUI系统监控工具，采用纯键盘驱动设计，特别适合通过SSH远程访问服务器的运维场景。 + +## Key Features +- **超轻量化**：资源占用极低，响应速度极快 +- **纯键盘驱动**：无需鼠标，通过快捷键操作 + - 方向键浏览进程 + - `h` 查看所有可用命令 + - `k` 快速终止进程 +- **实时信息**：网络、CPU、内存、存储一览 +- **安装方式**： + - Arch/Debian：官方仓库 + - Ubuntu：Snap包 + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[TUI]] ← interface type +- [[SSH Remote Access]] ← primary use case +- [[System Monitoring]] ← core feature +- [[Process Management]] ← basic support + +## Related Entities +- [[Btop++]] — 功能更全面的选择 +- [[Htop]] — 轻量但界面更丰富 +- [[Bottom]] — 图表为主的选择 diff --git a/wiki/entities/hello-world.md b/wiki/entities/hello-world.md new file mode 100644 index 00000000..8844faa6 --- /dev/null +++ b/wiki/entities/hello-world.md @@ -0,0 +1,33 @@ +--- +title: "hello-world (Docker Test Image)" +tags: [docker, test, verification] +date: 2026-04-22 +--- + +# hello-world (Docker 官方测试镜像) + +## Definition +hello-world 是 Docker 官方提供的轻量级测试镜像，用于验证 Docker Engine 是否正确安装。运行成功后输出欢迎信息并退出。 + +## Usage +```bash +# 验证安装（需 sudo） +sudo docker run hello-world + +# 无 sudo 验证（用户加入 docker 用户组后） +docker run hello-world +``` + +## Expected Output +``` +Hello from Docker! +This message shows that your installation appears to be working correctly. +... +``` + +## Related Sources +- [[如何在ubuntu-server安装-docker-docker-compose]] — 安装验证步骤 + +## Related Concepts +- [[Docker Engine]] — 被验证的核心组件 +- [[Docker 用户组]] — 影响非 sudo 运行方式 diff --git a/wiki/entities/htop.md b/wiki/entities/htop.md new file mode 100644 index 00000000..471dc8fd --- /dev/null +++ b/wiki/entities/htop.md @@ -0,0 +1,37 @@ +--- +title: "Htop" +type: entity +aliases: [htop] +tags: [linux, system-monitoring, open-source, tu i] +date: 2025-12-18 +--- + +# Htop + +轻量级TUI进程监控器，以极简键盘驱动为核心设计理念。 + +## Overview +Htop 是一款专注于进程的TUI系统监控工具，通过函数键驱动所有操作，提供最小化的资源占用和高效的进程管理体验。 + +## Key Features +- **键盘驱动操作**： + - `F3` 搜索进程 + - `F7` / `F8` 调整进程优先级（Nice值） + - `F9` 终止进程 + - 方向键滚动进程列表 +- **可定制仪表盘**：默认显示CPU核心和内存仪表，可通过 `F2` 添加电池、时钟、网络等仪表 +- **主题定制**：支持界面主题更换 +- **安装方式**：官方仓库直接安装（Arch/Debian） + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[TUI]] ← interface type +- [[Process Management]] ← core feature +- [[System Monitoring]] ← secondary feature + +## Related Entities +- [[Btop++]] — 更全面的替代品（作者首选） +- [[Glances]] — 超轻量替代 +- [[Bottom]] — 图表为主的选择 diff --git a/wiki/entities/it-tools.md b/wiki/entities/it-tools.md new file mode 100644 index 00000000..42492390 --- /dev/null +++ b/wiki/entities/it-tools.md @@ -0,0 +1,34 @@ +# it-tools + +## Aliases +- IT-Tools +- IT Tools +- CorentinTh/it-tools + +## Type +- 产品 / 开源项目 + +## Description +开源开发者工具集合 Web UI，提供超过 100+ 实用工具，涵盖编码转换、加密解密、UUID/Cron 表达式生成、QR 码、哈希计算、Base64 编解码、JWT 解析、正则测试、颜色转换等常见开发场景。 + +## Metadata +- **维护者**: Corentin Th +- **GitHub**: [CorentinTh/it-tools](https://github.com/CorentinTh/it-tools) +- **官方镜像**: `corentinth/it-tools:latest` +- **端口**: 80（容器内）/ 8999（宿主机映射） +- **内存需求**: ~128MB（建议限制） + +## Deployment +- [[Docker Compose]] 部署方式 +- [[容器重启策略]]: `unless-stopped` +- [[端口映射]]: `8999:80` +- [[容器资源限制]]: 128MB + +## Used By +- [[用docker安装it-tools]] +- [[Home Server Automation]] + +## Related Tools +- [[Portainer]] — Docker 容器管理 UI（同类 Docker Web UI 产品） +- [[Homarr]] — 仪表板式服务聚合 UI +- [[Jellyfin]] — 媒体服务器管理界面 diff --git a/wiki/entities/mission-center.md b/wiki/entities/mission-center.md new file mode 100644 index 00000000..9505a1d6 --- /dev/null +++ b/wiki/entities/mission-center.md @@ -0,0 +1,36 @@ +--- +title: "Mission Center" +type: entity +aliases: [missioncenter] +tags: [linux, system-monitoring, open-source, gui] +date: 2025-12-18 +--- + +# Mission Center + +类Windows任务管理器体验的GUI系统监控应用。 + +## Overview +Mission Center 是一款功能完善的GUI系统监控工具，提供图形化的性能图表和类似Windows任务管理器的用户体验，适合偏好桌面应用的Linux用户。 + +## Key Features +- **性能标签**：实时CPU和内存使用图表 +- **应用标签**：显示活跃应用和进程，支持右键终止或强制终止 +- **服务标签**：显示用户和系统服务，支持一键停止或重启 +- **类任务管理器体验**：图形化设计，直观友好 +- **安装方式**： + - Arch：官方仓库 + - Ubuntu：Snap包 + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[GUI]] ← interface type +- [[System Monitoring]] ← core feature +- [[Process Management]] ← integrated +- [[Mission Center]] → alternative_to → [[Windows Task Manager]] + +## Related Entities +- [[Stacer]] — 功能更全面的GUI替代 +- [[Btop++]] — TUI替代首选 diff --git a/wiki/entities/node-exporter.md b/wiki/entities/node-exporter.md new file mode 100644 index 00000000..e1615121 --- /dev/null +++ b/wiki/entities/node-exporter.md @@ -0,0 +1,70 @@ +--- +title: "node_exporter" +type: entity +aliases: [Node Exporter, Prometheus node_exporter] +tags: [monitoring, exporter, host-metrics, prometheus, linux] +date: 2025-11-11 +--- + +# node_exporter + +## Overview +node_exporter 是 Prometheus 官方的主机指标采集器，专门采集 Linux/Unix 系统的硬件和操作系统指标。它以守护进程形式运行，暴露一个 `/metrics` HTTP 端点供 Prometheus 抓取。默认端口 9100。设计上遵循无代理（agentless）原则：不需要在被监控主机安装任何特殊软件，只需运行一个独立的进程即可。 + +## Key Metrics Collected +| 分类 | 指标前缀 | 说明 | +|------|----------|------| +| CPU | `node_cpu_seconds_total` | 各模式（user/system/idle/iowait）CPU 时间 | +| 内存 | `node_memory_MemAvailable_bytes` | 可用内存 | +| 磁盘 | `node_filesystem_avail_bytes` | 文件系统可用空间 | +| 网络 | `node_network_receive_bytes_total` | 网络接口接收字节 | +| 磁盘 I/O | `node_disk_io_time_seconds_total` | 磁盘 I/O 时间 | +| 负载 | `node_load1` / `node_load5` / `node_load15` | 系统负载均值 | +| inode | `node_filesystem_files_free` | inode 可用数量 | +| 时间 | `node_time_seconds` | 系统时间（用于漂移检测） | + +## Home Server Deployment（Host Network 模式） +```yaml +# docker-compose.yml 片段 +node_exporter: + image: prom/node-exporter:latest + container_name: node_exporter + restart: always + network_mode: "host" # 关键：使用宿主机网络 + pid: "host" # 关键：共享宿主机 PID 命名空间 + volumes: + - /proc:/host/proc:ro # 只读挂载 + - /sys:/host/sys:ro + - /:/rootfs:ro +``` + +> ⚠️ **安全注意**：host network + pid mode 授予容器较高的系统可见性。仅在内网可信环境中使用。 + +## Prometheus scrape_config +```yaml +- job_name: 'node_exporter' + file_sd_configs: + - files: + - /etc/prometheus/targets/node.yml +``` + +## targets/node.yml 示例 +```yaml +- targets: + - "192.168.3.47:9100" + labels: + env: home + role: server +``` + +## Related Sources +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] + +## Related Entities +- [[Prometheus]] — 数据消费者（抓取 node_exporter 的指标） +- [[Docker]] — 部署平台 + +## Related Concepts +- [[Exporter]] — Prometheus 生态中的通用指标暴露组件 +- [[Prometheus]] — 上游采集目标 +- [[System Monitoring]] — 核心应用领域 diff --git a/wiki/entities/shenwei.md b/wiki/entities/shenwei.md new file mode 100644 index 00000000..46a70b1d --- /dev/null +++ b/wiki/entities/shenwei.md @@ -0,0 +1,37 @@ +--- +title: "shenwei" +type: entity +tags: [linkedin, author, cloud-devops] +date: 2025-03-01 +--- + +## Profile + +shenwei是LinkedIn上的IT运维和云转型领域作者，专注于现代IT服务管理（ITSM）、AIOps和DevOps实践。 + +## Contributions + +### Published Articles + +1. **Modern ITSM: Driving Efficiency, Security & Resilience** + - 探讨ITSM从传统工单系统向AI驱动、自愈智能运营的演进 + - 覆盖AIOps、Hyperautomation、ITSM 2.0等前沿趋势 + - 来源：[[understanding-complete-itsm]] + +## Areas of Expertise + +- [[ITSM]] & [[ITSM-2.0]] +- [[AIOps]] & Machine Learning +- [[DevOps]] Culture & Automation +- [[Self-Healing-Systems]] +- [[Zero-Trust-Architecture]] + +## Linked Sources + +- [[understanding-complete-itsm]] + +## Connections + +- [[The Agency]] — 相关领域（AI Agents for IT Operations） +- [[BMC]] — 相关厂商（AIOps平台提供商） +- [[Micro-Focus]] — 相关厂商（ITOM解决方案） diff --git a/wiki/entities/stacer.md b/wiki/entities/stacer.md new file mode 100644 index 00000000..c93cbbad --- /dev/null +++ b/wiki/entities/stacer.md @@ -0,0 +1,40 @@ +--- +title: "Stacer" +type: entity +aliases: [stacer] +tags: [linux, system-monitoring, system-maintenance, open-source, gui] +date: 2025-12-18 +--- + +# Stacer + +功能最全面的GUI系统监控与维护工具箱。 + +## Overview +Stacer 是一款集系统监控、启动项管理、包管理、系统清理于一体的GUI工具，提供比本文其他工具都更多的系统维护功能。 + +## Key Features +- **仪表盘**：CPU、内存、磁盘使用的可视化仪表 +- **历史图表**：CPU和内存负载的详细图形历史 +- **进程管理**：进程审查与终止 +- **服务管理**：启用/禁用系统服务 +- **启动项管理**：配置开机启动应用 +- **包管理**：卸载软件包 +- **APT仓库管理**：添加APT软件源 +- **GNOME设置**：在GNOME桌面下调整窗口设置 +- **缓存清理**：一键清理垃圾文件和缓存 +- **安装方式**：Snap包或官方包 + +## Related Sources +- [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] + +## Connections +- [[GUI]] ← interface type +- [[System Monitoring]] ← core feature +- [[Process Management]] ← integrated +- [[System Maintenance]] ← extended scope +- [[Stacer]] → extends → [[Mission Center]] + +## Related Entities +- [[Mission Center]] — 更简洁的GUI替代 +- [[Btop++]] — TUI替代首选 diff --git a/wiki/entities/机场.md b/wiki/entities/机场.md new file mode 100644 index 00000000..734f838c --- /dev/null +++ b/wiki/entities/机场.md @@ -0,0 +1,32 @@ +# 机场 + +## Aliases +- 代理机场 +- 翻墙机场 +- VPN机场 +- Subscription Service + +## Basic Info +- **Type**: 代理节点订阅服务 +- **Business Model**: 付费订阅（也有免费试用） + +## Description +机场是提供代理节点订阅服务的服务商。用户通过订阅链接（通常为SS/SSR/V2Ray/Trojan等协议格式）将节点配置导入到代理客户端或路由器插件中，实现科学上网。 + +## How It Works +1. 用户在机场注册账号 +2. 购买订阅套餐（通常按流量或时间计费） +3. 获取订阅链接 +4. 将订阅链接导入到 MerlinClash 等代理插件 +5. 插件自动获取并更新节点列表 + +## Common Protocols +- SSR (ShadowsocksR) +- V2Ray (VMess/VLESS) +- Trojan +- WireGuard + +## Related +- [[MerlinClash插件]] — 使用机场节点的插件 +- [[订阅机制]] — 节点管理机制 +- [[科学上网]] — 机场服务的应用场景 diff --git a/wiki/entities/梅林固件.md b/wiki/entities/梅林固件.md new file mode 100644 index 00000000..4d8d0ab7 --- /dev/null +++ b/wiki/entities/梅林固件.md @@ -0,0 +1,28 @@ +# 梅林固件 + +## Aliases +- Merlin Firmware +- ASUSWRT-Merlin +- 梅林固件 + +## Basic Info +- **Type**: 第三方路由器固件 +- **Developer**: Eric Sauvageau +- **Based On**: 华硕官方固件（ASUSWRT） +- **Platforms**: 华硕路由器、网件路由器（部分型号） + +## Description +梅林固件是基于华硕官方路由器固件的第三方改良版本，由开发者Eric Sauvageau维护。它在原厂固件基础上增加了更多高级功能和插件支持，是路由器玩家和科学上网用户最常使用的第三方固件之一。 + +## Key Features +- 支持更多插件（软件中心） +- 高级网络配置选项 +- JFFS 分区支持（用于安装插件） +- 科学上网插件支持 +- SSH/Telnet 远程访问 +- 更灵活的安全设置 + +## Related +- [[网件RAX50]] — 支持梅林固件的路由器型号 +- [[MerlinClash插件]] — 梅林固件上的科学上网插件 +- [[过渡固件]] — 刷入梅林固件的前置固件 diff --git a/wiki/entities/矿神源.md b/wiki/entities/矿神源.md new file mode 100644 index 00000000..c9f4f2fb --- /dev/null +++ b/wiki/entities/矿神源.md @@ -0,0 +1,45 @@ +--- +title: "矿神源" +type: entity +tags: [synology, nas, 套件, spk] +date: 2025-12-29 +--- + +# 矿神源 + +## Aliases +- 矿神 +- Synology Community Packages +- SPK 社区源 + +## Description +矿神源是 Synology NAS 社区维护的第三方套件源（SPK 格式），由爱好者社区提供大量 Synology 官方套件中心未收录的应用程序，是对官方生态的重要补充。 + +## Key Packages Available +- CloudDrive2 — 云盘挂载工具（阿里云盘、115、夸克等） +- 各种第三方 Docker 工具 +- 系统增强工具 +- 下载工具 + +## Installation +1. 在 Synology 套件中心 → 设置 → 常规 → 套件来源 +2. 添加矿神源 URL（社群维护的最新地址） +3. 返回套件中心即可在社群分类中找到第三方应用 + +## Connection to DSM Version Compatibility +- DSM 6.x：大多数第三方 SPK 可直接安装 +- DSM 7.x：部分套件需要额外的 Root 权限修复 + - 如 CloudDrive2 在 DSM 7+ 需要执行：`sudo sed -i 's/package/root/g' /var/packages//conf/privilege` + +## Connections +- [[Synology NAS]] — 平台 +- [[CloudDrive2]] — 典型应用 +- [[群晖NAS科学上网]] — 相关应用 + +## Related Concepts +- [[NAS套件管理]] +- [[Root权限修复]] +- [[SPK套件格式]] + +## References +- Source: [[在Synology NAS上安装CloudDrive2]] diff --git a/wiki/entities/网件RAX50.md b/wiki/entities/网件RAX50.md new file mode 100644 index 00000000..f82c960b --- /dev/null +++ b/wiki/entities/网件RAX50.md @@ -0,0 +1,21 @@ +# 网件RAX50 + +## Aliases +- NETGEAR Nighthawk RAX50 +- 网件RAX50 +- RAX50 + +## Basic Info +- **Type**: 路由器（网络硬件） +- **Manufacturer**: NETGEAR（网件） +- **Model**: Nighthawk RAX50 +- **WiFi Standard**: WiFi 6 (802.11ax) +- **Bands**: 双频 (2.4GHz + 5GHz) +- **Class**: AX3000 + +## Description +网件RAX50是一款支持WiFi 6的双频路由器，型号为Nighthawk RAX50。它支持刷入第三方梅林固件以扩展功能，包括安装科学上网插件。 + +## Related +- [[梅林固件]] — RAX50 支持的第三方固件 +- [[MerlinClash插件]] — 梅林固件上的科学上网插件 diff --git a/wiki/frp.md b/wiki/frp.md new file mode 100644 index 00000000..9e1a451b --- /dev/null +++ b/wiki/frp.md @@ -0,0 +1,142 @@ +--- +title: "frp" +type: entity +aliases: [frp内网穿透, frp工具] +tags: [network, proxy, tunneling, open-source] +--- + +# frp + +## Overview +**frp** (Fast Reverse Proxy) 是一个开源的高性能内网穿透工具，由 [fatedier](https://github.com/fatedier/frp) 开发维护。通过在公网服务器（frps）和内网机器（frpc）之间建立反向隧道，使内网服务可被公网访问。 + +## Architecture + +frp 采用 C/S 架构，包含两个核心组件： + +| 组件 | 全称 | 角色 | 部署位置 | +|------|------|------|---------| +| **frps** | frp Server | 服务端，监听客户端连接 | 公网 VPS | +| **frpc** | frp Client | 客户端，建立反向隧道 | 内网机器 | + +## Core Concepts + +### Protocol Types +- **TCP**：通用 TCP 代理，适用于 SSH、数据库等任意 TCP 服务 +- **UDP**：通用 UDP 代理，适用于 DNS、视频流等 UDP 服务 +- **HTTP/HTTPS**：专为 Web 服务设计，支持虚拟主机和路径路由 + +### Authentication +- **Token**：基于共享密钥的认证机制，frps 和 frpc 配置中的 `token` 必须一致 +- Token 不一致会导致认证失败：`authentication failed token mismatch` + +### Dashboard (Optional) +frps 可选启用 Web 管理面板： +```ini +[dashboard] +dashboard_addr = 0.0.0.0 +dashboard_port = 7500 +dashboard_user = admin +dashboard_pwd = StrongPassword123! +``` + +## Configuration Files + +### frps.ini (服务端) +```ini +[common] +bind_addr = 0.0.0.0 +bind_port = 7000 + +# 可选：Web Dashboard +dashboard_addr = 0.0.0.0 +dashboard_port = 7500 +dashboard_user = admin +dashboard_pwd = StrongPassword + +# 认证 Token（必须与客户端一致） +token = YourSecretTokenHere +``` + +### frpc.ini (客户端) +```ini +[common] +server_addr = +server_port = 7000 +token = YourSecretTokenHere + +# TCP 映射示例：本地 5000 → VPS 15000 +[nas] +type = tcp +local_ip = 127.0.0.1 +local_port = 5000 +remote_port = 15000 + +# SSH 映射示例 +[ssh] +type = tcp +local_ip = 127.0.0.1 +local_port = 22 +remote_port = 60022 +``` + +## Installation + +### VPS (frps) +```bash +cd /opt +sudo mkdir frp && cd frp +FRP_VER=0.65.0 +sudo curl -LO https://github.com/fatedier/frp/releases/download/v${FRP_VER}/frp_${FRP_VER}_linux_amd64.tar.gz +sudo tar xzf frp_${FRP_VER}_linux_amd64.tar.gz +sudo mv frp_${FRP_VER}_linux_amd64/* /opt/frp/ +``` + +### systemd Service (frps) +```ini +[Unit] +Description=frp server (frps) +After=network.target + +[Service] +Type=simple +ExecStart=/opt/frp/frps -c /opt/frp/frps.ini +Restart=on-failure + +[Install] +WantedBy=multi-user.target +``` + +```bash +sudo systemctl daemon-reload +sudo systemctl enable --now frps +sudo systemctl status frps +``` + +## Common Use Cases + +1. **Web 服务穿透**：内网 NAS、Web 应用通过子域名访问 +2. **SSH 远程访问**：通过 `ssh -p 60022 user@vps.domain.com` 访问内网机器 +3. **数据库远程连接**：MySQL、MongoDB 等数据库的远程管理 +4. **监控系统访问**：Grafana、Prometheus 等内网监控面板的公网展示 + +## Advantages + +| 特性 | 说明 | +|------|------| +| **轻量** | 单二进制文件，无额外依赖 | +| **高性能** | 基于 Go 语言，支持高并发连接 | +| **自动重连** | 网络中断后自动重连 | +| **热更新** | 支持配置热加载 | +| **多协议支持** | TCP/UDP/HTTP/HTTPS | +| **Web Dashboard** | 可选的图形化管理界面 | + +## Related Concepts +- [[内网穿透]] — frp 是实现内网穿透的典型工具 +- [[反向代理]] — frp 与 Caddy/Nginx 常配合使用 +- [[TCP 隧道]] — frp 建立的底层连接机制 +- [[VPS]] — frps 常部署在公网 VPS 上 + +## References +- GitHub: https://github.com/fatedier/frp +- 文档: https://gofrp.org/docs/ diff --git a/wiki/index.md b/wiki/index.md index ad9a0d55..93b33883 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,8 +4,15 @@ - [Overview](overview.md) — living synthesis ## Sources +- [2026-02-27] [nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器](sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md) — NodeWarden 将 Bitwarden 服务器端部署到 Cloudflare Workers，实现真正的无服务器（Serverless）密码管理，数据存储在 Cloudflare D1 + R2，零成本零运维，支持 Bitwarden 官方全平台客户端 +- [2026-02-10] [3x-ui-xray-on-bandwagonvps](sources/3x-ui-xray-on-bandwagonvps.md) — 在 Bandwagon VPS 上通过 3X-UI 可视化面板部署 Xray 代理服务（VLESS+Reality 协议）的完整操作记录，含一键安装命令、25项管理菜单说明、BBR启用及 v2rayN/v2rayNG 客户端配置 +- [2026-03-04] [rax50-路由器-更新merlin-clash订阅](sources/rax50-路由器-更新merlin-clash订阅.md) — 在 RAX50 路由器的 Merlin Clash 界面中更新科学上网订阅配置的完整操作流程，包含小白一键订阅助手导入 vless URL、配置文件切换及快速重启故障处理 +- [2025-03-02] [the-myths-and-misconceptions-about-cloud-computing-linkedin](sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md) — 云安全、成本、迁移复杂性与可靠性的七大误解与真相 +- [2026-04-19] [public-vs-private-vs-hybrid-cloud-differences-explained](sources/public-vs-private-vs-hybrid-cloud-differences-explained.md) — 公有云/私有云/混合云三种部署模式的特点、优缺点及适用场景对比 +- [2025-03-01] [cloud-operating-model-key-strategies-and-best-practices](sources/cloud-operating-model-key-strategies-and-best-practices.md) — 云运营模型(COM)全面指南：四大支柱（治理/自动化/安全/成本）、六步设计流程、行业用例及未来趋势 - [2026-04-21] [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing) - [2026-04-21] [实战笔记-本地部署-rsshub-并获取-youtube-订阅](sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md) — (expected: wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md — source missing) +- [2025-03-01] [understanding-complete-itsm](sources/understanding-complete-itsm.md) — 现代IT服务管理(ITSM)已超越传统工单系统，成为企业运营卓越、风险缓解和创新加速的战略推动者，涵盖AIOps、自愈系统、零信任等八大核心流程 - [2026-04-21] [n8n-调用openclaw-agents的工作流架构](sources/n8n-调用openclaw-agents的工作流架构.md) — (expected: wiki/sources/n8n-调用openclaw-agents的工作流架构.md — source missing) - [2026-04-21] [n8n-docker-配置-telegram-代理-troubleshooting](sources/n8n-docker-配置-telegram-代理-troubleshooting.md) — (expected: wiki/sources/n8n-docker-配置-telegram-代理-troubleshooting.md — source missing) - [2026-04-20] [n8n调用hermes-agents的工作流架构](sources/n8n调用hermes-agents的工作流架构.md) — (expected: wiki/sources/n8n调用hermes-agents的工作流架构.md — source missing) @@ -176,11 +183,11 @@ - [2026-04-17] [在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b](sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md) — (expected: wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md — source missing) - [2026-04-17] [codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch](sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md) — (expected: wiki/sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md — source missing) - [2026-04-17] [building-your-quartz](sources/building-your-quartz.md) — (expected: wiki/sources/building-your-quartz.md — source missing) -- [2026-04-17] [how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets](sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md) — (expected: wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md — source missing) +- [2025-10-24] [how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets](sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md) — 多账户 CloudFormation StackSets 部署场景下，将分散日志集中到管理账户，通过 EventBridge + CloudWatch Logs 实现单一界面监控 - [2026-04-16] [obsidian-官方-cli-命令全景速查表](sources/obsidian-官方-cli-命令全景速查表.md) — (expected: wiki/sources/obsidian-官方-cli-命令全景速查表.md — source missing) - [2026-04-16] [obsidian-cli](sources/obsidian-cli.md) — (expected: wiki/sources/obsidian-cli.md — source missing) - [2026-04-16] [learn-ai-for-free-directly-from-top-companies](sources/learn-ai-for-free-directly-from-top-companies.md) — (expected: wiki/sources/learn-ai-for-free-directly-from-top-companies.md — source missing) -- [2026-04-14] [ubuntu-安装-frp-0-65-0-x86_64-操作笔记](sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md) — (expected: wiki/sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md — source missing) +- [2026-04-14] [ubuntu-安装-frp-0-65-0-x86_64-操作笔记](sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md) — 在 Ubuntu Server 24.04（x86_64）上安装配置 FRP 0.65.0 内网穿透客户端，包含 systemd 服务管理、软链接版本策略、journald 日志配置及完整故障排查指南 - [2026-04-14] [养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录](sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md) — (expected: wiki/sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md — source missing) - [2026-04-14] [养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流](sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md) — (expected: wiki/sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md — source missing) - [2026-04-14] [养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑](sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md) — (expected: wiki/sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md — source missing) @@ -203,55 +210,55 @@ - [2026-04-14] [vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南](sources/vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南.md) — (expected: wiki/sources/vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南.md — source missing) - [2026-04-14] [useful-prompt-lib](sources/useful-prompt-lib.md) — (expected: wiki/sources/useful-prompt-lib.md — source missing) - [2026-04-14] [trae远程开发部署指南](sources/trae远程开发部署指南.md) — (expected: wiki/sources/trae远程开发部署指南.md — source missing) -- [2026-04-14] [these-6-linux-apps-let-you-monitor-system-resources-in-style](sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md) — (expected: wiki/sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md — source missing) +- [2026-04-14] [these-6-linux-apps-let-you-monitor-system-resources-in-style](sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md) — 6款Linux系统资源监控工具评测：TUI类（Btop++/Htop/Glances/Bottom）vs GUI类（Mission Center/Stacer），作者首推Btop++ - [2026-04-14] [tiktok-pm-python-django-project](sources/tiktok-pm-python-django-project.md) — (expected: wiki/sources/tiktok-pm-python-django-project.md — source missing) - [2026-04-14] [mcp在cursor中的集成与应用详解](sources/mcp在cursor中的集成与应用详解.md) — (expected: wiki/sources/mcp在cursor中的集成与应用详解.md — source missing) - [2026-04-14] [how-to-get-youtube-channel-id](sources/how-to-get-youtube-channel-id.md) — (expected: wiki/sources/how-to-get-youtube-channel-id.md — source missing) -- [2026-04-14] [macos-创建与解除-symbolic-link-openclaw-目录映射](sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md) — (expected: wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md — source missing) -- [2026-04-14] [mac-mini-安装-frp-0-65-0-arm64-操作笔记](sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md) — (expected: wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md — source missing) +- [2026-04-14] [macos-创建与解除-symbolic-link-openclaw-目录映射](sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md) — macOS 上为 OpenClaw 隐藏目录 `~/.openclaw` 创建 Symbolic Link（符号链接）映射为可见目录 `~/openclaw`，使 Obsidian 可直接作为 Vault 访问 +- [2026-04-14] [mac-mini-安装-frp-0-65-0-arm64-操作笔记](sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md) — 在 Apple Silicon Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，包含 Gatekeeper 解除、launchd 开机自启、tmux/nohup 后台运行三种方式 - [2026-04-14] [家庭网络环境概览_2026-04-03](sources/家庭网络环境概览_2026-04-03.md) — (expected: wiki/sources/家庭网络环境概览_2026-04-03.md — source missing) - [2026-04-14] [群晖nas科学上网方法](sources/群晖nas科学上网方法.md) — (expected: wiki/sources/群晖nas科学上网方法.md — source missing) -- [2026-04-14] [网件rax50路由器刷梅林固件与科学上网插件安装教程](sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md) — (expected: wiki/sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md — source missing) -- [2026-04-14] [用docker安装transmission](sources/用docker安装transmission.md) — (expected: wiki/sources/用docker安装transmission.md — source missing) -- [2026-04-14] [用docker安装it-tools](sources/用docker安装it-tools.md) — (expected: wiki/sources/用docker安装it-tools.md — source missing) +- [2026-04-14] [网件rax50路由器刷梅林固件与科学上网插件安装教程](sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md) — 网件RAX50路由器刷入梅林固件并安装配置科学上网插件的完整实操教程，涵盖二次刷机流程、JFFS双清、MerlinClash策略组分流配置 +- [2026-04-14] [用docker安装transmission](sources/用docker安装transmission.md) — 通过 Docker Compose 在 Home Server 部署 Transmission BT 下载服务，使用 linuxserver/transmission 镜像，包含 Web UI 认证配置（USER/PASS）、下载目录挂载、PUID/PGID 权限映射 +- [2026-04-14] [用docker安装it-tools](sources/用docker安装it-tools.md) — 使用 Docker Compose 在 Home Server 部署 it-tools 开发者工具集合，通过 `corentinth/it-tools:latest` 镜像暴露 8999 端口，配置 128MB 内存限制与 unless-stopped 重启策略 - [2026-04-14] [用docker安装portainer](sources/用docker安装portainer.md) — (expected: wiki/sources/用docker安装portainer.md — source missing) - [2026-04-14] [用docker安装jellyfin](sources/用docker安装jellyfin.md) — (expected: wiki/sources/用docker安装jellyfin.md — source missing) - [2026-04-14] [用docker安装homarr](sources/用docker安装homarr.md) — (expected: wiki/sources/用docker安装homarr.md — source missing) - [2026-04-14] [用docker安装apache-superset](sources/用docker安装apache-superset.md) — (expected: wiki/sources/用docker安装apache-superset.md — source missing) -- [2026-04-14] [用docker中安装navidrome](sources/用docker中安装navidrome.md) — (expected: wiki/sources/用docker中安装navidrome.md — source missing) +- [2026-04-14] [用docker中安装navidrome](sources/用docker中安装navidrome.md) — 通过 Docker Compose 在 NAS/服务器上部署 Navidrome 开源音乐流媒体服务器，配置转码缓存、自动转码下载、只读音乐挂载 - [2026-04-14] [家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox](sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md) — (expected: wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md — source missing) - [2026-04-14] [安装v2rayn](sources/安装v2rayn.md) — (expected: wiki/sources/安装v2rayn.md — source missing) -- [2026-04-14] [安装ubuntu-24-04-2在hp-zbook工作站笔记本上](sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md) — (expected: wiki/sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md — source missing) -- [2026-04-14] [如何用指纹浏览器安全注册并订阅claude-pro会员全攻略](sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md) — (expected: wiki/sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md — source missing) -- [2026-04-14] [如何在ubuntu-server安装-docker-docker-compose](sources/如何在ubuntu-server安装-docker-docker-compose.md) — (expected: wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md — source missing) +- [2026-04-14] [安装ubuntu-24-04-2在hp-zbook工作站笔记本上](sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md) — 在 HP ZBook 工作站笔记本上安装 Ubuntu 24.04.2 Desktop 的完整指南，涵盖 Rufus ISOHybrid 启动盘制作、GPT 分区方案、HP BIOS UEFI 设置及 efibootmgr NVRAM 启动项修复 +- [2026-04-22] [如何用指纹浏览器安全注册并订阅claude-pro会员全攻略](sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md) — 通过AdsPower指纹浏览器+高纯净度美国代理+PingMe接码平台+WildCard虚拟信用卡，安全注册并订阅Claude Pro的完整实操攻略 +- [2026-04-14] [如何在ubuntu-server安装-docker-docker-compose](sources/如何在ubuntu-server安装-docker-docker-compose.md) — 在 Ubuntu Server 上通过 Docker 官方 apt 仓库安装 Docker Engine 和 Docker Compose V2 的完整五步流程，涵盖仓库配置、GPG 密钥导入、非 root 用户权限配置及 hello-world 镜像验证 - [2026-04-14] [如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹](sources/如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹.md) — (expected: wiki/sources/如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹.md — source missing) -- [2026-04-14] [如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64](sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md) — (expected: wiki/sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md — source missing) +- [2026-04-14] [如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64](sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md) — Linux 服务器 CPU 架构检测方法：通过 uname/lscpu/proc/cpuinfo/file 四种命令快速识别 x86_64、aarch64、armv7l 等架构，确保安装正确的软件包版本 - [2026-04-14] [如何删除旧的废弃的docker-container-volume](sources/如何删除旧的废弃的docker-container-volume.md) — (expected: wiki/sources/如何删除旧的废弃的docker-container-volume.md — source missing) - [2026-04-14] [在ubuntu上通过vps-内网反向代理实现域名访问内网穿透](sources/在ubuntu上通过vps-内网反向代理实现域名访问内网穿透.md) — (expected: wiki/sources/在ubuntu上通过vps-内网反向代理实现域名访问内网穿透.md — source missing) -- [2026-04-14] [在synology-nas上安装clouddrive2](sources/在synology-nas上安装clouddrive2.md) — (expected: wiki/sources/在synology-nas上安装clouddrive2.md — source missing) +- [2025-11-11] [家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox](sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md) — 家庭/家居服务器一站式开源监控方案，Docker Compose 快速部署 Prometheus + Grafana + node_exporter + cAdvisor + blackbox_exporter，含可直接拷贝的 prometheus.yml、alerts.yml、alertmanager.yml 及 8 步落地路径 +- [2025-12-29] [在synology-nas上安装clouddrive2](sources/在synology-nas上安装clouddrive2.md) — 通过矿神源在群晖 NAS 安装 CloudDrive2，使用阿里云盘 App 扫码授权挂载云盘资源目录的完整操作流程，含 DSM 7+ Root 权限修复命令 - [2026-04-14] [ubuntu禁用合盖休眠](sources/ubuntu禁用合盖休眠.md) — (expected: wiki/sources/ubuntu禁用合盖休眠.md — source missing) - [2026-04-14] [ubuntu用rustdesk远程登录出现不能使用wayland登录的错误](sources/ubuntu用rustdesk远程登录出现不能使用wayland登录的错误.md) — (expected: wiki/sources/ubuntu用rustdesk远程登录出现不能使用wayland登录的错误.md — source missing) -- [2026-04-14] [ubuntu服务器通过rsync实现日常增量备份](sources/ubuntu服务器通过rsync实现日常增量备份.md) — (expected: wiki/sources/ubuntu服务器通过rsync实现日常增量备份.md — source missing) +- [2026-04-14] [ubuntu服务器通过rsync实现日常增量备份](sources/ubuntu服务器通过rsync实现日常增量备份.md) — Ubuntu服务器通过rsync实现日常增量备份到NAS的完整解决方案，含rsync自动化脚本、Cron定时任务、NFS永久挂载配置及灾备恢复策略 - [2026-04-14] [ubuntu-server科学上网](sources/ubuntu-server科学上网.md) — (expected: wiki/sources/ubuntu-server科学上网.md — source missing) -- [2026-04-14] [ubuntu-24-04-enable-ssh](sources/ubuntu-24-04-enable-ssh.md) — (expected: wiki/sources/ubuntu-24-04-enable-ssh.md — source missing) +- [2026-04-14] [ubuntu-24-04-enable-ssh](sources/ubuntu-24-04-enable-ssh.md) — Ubuntu 24.04 SSH 服务安装与配置，核心变化是默认使用 ssh.socket 按需激活机制，可切换传统 ssh.service 持续运行模式 - [2026-04-14] [rax50-路由器-更新merlin-clash订阅](sources/rax50-路由器-更新merlin-clash订阅.md) — (expected: wiki/sources/rax50-路由器-更新merlin-clash订阅.md — source missing) - [2026-04-14] [nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器](sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md) — (expected: wiki/sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md — source missing) -- [2026-04-14] [mysql-mariadb-数据库详细信息](sources/mysql-mariadb-数据库详细信息.md) — (expected: wiki/sources/mysql-mariadb-数据库详细信息.md — source missing) +- [2026-04-14] [mysql-mariadb-数据库详细信息](sources/mysql-mariadb-数据库详细信息.md) — MariaDB/MySQL 数据库访问配置信息及远程用户创建流程，包含内网/公网访问配置和 socket 登录方法 - [2026-04-14] [minio-zipline-自托管图床应用安装教程](sources/minio-zipline-自托管图床应用安装教程.md) — (expected: wiki/sources/minio-zipline-自托管图床应用安装教程.md — source missing) -- [2026-04-14] [linux-运维必会的-150-个命令](sources/linux-运维必会的-150-个命令.md) — (expected: wiki/sources/linux-运维必会的-150-个命令.md — source missing) -- [2026-04-14] [clonezilla对ubuntu-server进行全盘镜像备份](sources/clonezilla对ubuntu-server进行全盘镜像备份.md) — (expected: wiki/sources/clonezilla对ubuntu-server进行全盘镜像备份.md — source missing) +- [2026-04-14] [linux-运维必会的-150-个命令](sources/linux-运维必会的-150-个命令.md) — Linux 系统管理命令全面分类参考，涵盖 150 个运维必备命令，按 16 大类组织（文件操作、文本处理、网络、磁盘、权限、进程管理等） +- [2026-04-14] [clonezilla对ubuntu-server进行全盘镜像备份](sources/clonezilla对ubuntu-server进行全盘镜像备份.md) — 使用 Clonezilla 对 Ubuntu Server 进行全盘镜像备份到 NAS 的完整操作流程，含 Rufus 启动盘制作、NFS 网络挂载、savedisk/restoredisk 备份还原及 UEFI/BIOS 分区方案选择 - [2026-04-14] [3x-ui-xray-on-bandwagonvps](sources/3x-ui-xray-on-bandwagonvps.md) — (expected: wiki/sources/3x-ui-xray-on-bandwagonvps.md — source missing) -- [2026-04-14] [通过vps-内网反向代理实现域名访问内网穿透](sources/通过vps-内网反向代理实现域名访问内网穿透.md) — (expected: wiki/sources/通过vps-内网反向代理实现域名访问内网穿透.md — source missing) +- [2026-04-14] [通过vps-内网反向代理实现域名访问内网穿透](sources/通过vps-内网反向代理实现域名访问内网穿透.md) — 通过 VPS + frp + Caddy 实现内网服务的公网域名访问完整方案，支持 NAS/n8n/Grafana 等多服务子域名访问，包含 DNS 配置、服务端/客户端安装配置、Caddy 反向代理、SSH 穿透及完整故障排查指南 - [2026-04-14] [mac-mini-服务器配置-防止自动锁屏与睡眠](sources/mac-mini-服务器配置-防止自动锁屏与睡眠.md) — (expected: wiki/sources/mac-mini-服务器配置-防止自动锁屏与睡眠.md — source missing) - [2026-04-14] [install-apache-superset-in-docker](sources/install-apache-superset-in-docker.md) — (expected: wiki/sources/install-apache-superset-in-docker.md — source missing) - [2026-04-14] [cursor-2-0初学者使用指南](sources/cursor-2-0初学者使用指南.md) — (expected: wiki/sources/cursor-2-0初学者使用指南.md — source missing) -- [2026-04-14] [what-is-devsecops-best-practices-benefits-and-tools](sources/what-is-devsecops-best-practices-benefits-and-tools.md) — (expected: wiki/sources/what-is-devsecops-best-practices-benefits-and-tools.md — source missing) +- [2025-12-19] [what-is-devsecops-best-practices-benefits-and-tools](sources/what-is-devsecops-best-practices-benefits-and-tools.md) — DevSecOps 将安全深度集成到软件开发生命周期的方法论，通过 Shift Left/Right 策略、SAST/DAST/IAST/SCA 工具实现自动化安全测试，覆盖 DevOps 与 DevSecOps 核心对比、5 大组件（协作/沟通/自动化/工具安全/测试）、最佳实践及工具链 - [2026-04-14] [What I Know About Cloud Service Delivery 1](sources/what-i-know-about-cloud-service-delivery-1.md) -- [2026-04-14] [understanding-complete-itsm](sources/understanding-complete-itsm.md) — (expected: wiki/sources/understanding-complete-itsm.md — source missing) - [2026-04-14] [The Myths and Misconceptions About Cloud Computing | LinkedIn](sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md) -- [2026-04-14] [rto-vs-rpo-key-differences-for-modern-disaster-recovery](sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md) — (expected: wiki/sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md — source missing) +- [2025-07-26] [rto-vs-rpo-key-differences-for-modern-disaster-recovery](sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md) — RTO vs RPO：现代灾备核心指标详解 + Feature Flag 实现秒级恢复 - [2026-04-14] [How Can a Multi Cloud Strategy Transform Your Business ROI?](sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md) -- [2026-04-14] [how-agentic-ai-can-help-for-cloud-devops](sources/how-agentic-ai-can-help-for-cloud-devops.md) — (expected: wiki/sources/how-agentic-ai-can-help-for-cloud-devops.md — source missing) +- [2026-04-14] [how-agentic-ai-can-help-for-cloud-devops](sources/how-agentic-ai-can-help-for-cloud-devops.md) — Agentic AI 在 Cloud DevOps 中的7大应用领域（Self-Healing、RCA、成本优化、安全合规、日志分析、多租户SaaS、AI决策支持） - [2026-04-14] [Cloud Maturity Model - A Detailed Guide For Cloud Adoption](sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md) - [2026-04-14] [Cloud DevOp Maturity - Guideline](sources/cloud-devop-maturity-guideline.md) - [2026-04-14] [chinatextbook-41-53-gb-中国小学-初中-高中-大学-pdf-教材](sources/chinatextbook-41-53-gb-中国小学-初中-高中-大学-pdf-教材.md) — (expected: wiki/sources/chinatextbook-41-53-gb-中国小学-初中-高中-大学-pdf-教材.md — source missing) @@ -533,14 +540,20 @@ ## Entities - [AWS](entities/AWS.md) - [Azure](entities/Azure.md) +- [BMC](entities/BMC.md) - [cloud-computing](entities/cloud-computing.md) - [Cloud-Maturity-Model](entities/Cloud-Maturity-Model.md) - [Cloud-Provider](entities/Cloud-Provider.md) +- [Cloud-Provider](entities/Public-Cloud-Provider.md) - [DevOps-Maturity-Model](entities/DevOps-Maturity-Model.md) - [DORA-Metrics](entities/DORA-Metrics.md) +- [GDPR](entities/GDPR.md) - [Google-Cloud](entities/Google-Cloud.md) - [HemantSawant](entities/HemantSawant.md) +- [HIPAA](entities/HIPAA.md) +- [ISO-27001](entities/ISO-27001.md) - [Open-Alliance-for-Cloud-Adoption](entities/Open-Alliance-for-Cloud-Adoption.md) +- [Raj-Vardhan-Singh](entities/Raj-Vardhan-Singh.md) ## Concepts - [AgilePractices](concepts/AgilePractices.md) @@ -559,24 +572,31 @@ - [Continuous-Deployment](concepts/Continuous-Deployment.md) - [Continuous-Integration](concepts/Continuous-Integration.md) - [Cost-Optimization](concepts/Cost-Optimization.md) +- [Data-Governance](concepts/Data-Governance.md) - [Data-Sovereignty](concepts/Data-Sovereignty.md) - [DevOps-Maturity](concepts/DevOps-Maturity.md) - [DevOpsCulture](concepts/DevOpsCulture.md) - [DevSecOps](concepts/DevSecOps.md) - [DORA-Metrics](concepts/DORA-Metrics.md) - [Error-Budget](concepts/Error-Budget.md) +- [Failover](concepts/Failover.md) - [GitOps](concepts/GitOps.md) - [high-availability](concepts/high-availability.md) - [Infrastructure-as-Code](concepts/Infrastructure-as-Code.md) +- [Intentional-Cloud-Strategy](concepts/Intentional-Cloud-Strategy.md) - [Lead-Time](concepts/Lead-Time.md) - [MTTA](concepts/MTTA.md) - [MTTD](concepts/MTTD.md) - [MTTR](concepts/MTTR.md) +- [Multi-Tenancy](concepts/Multi-Tenancy.md) +- [Multi-factor-Authentication](concepts/Multi-factor-Authentication.md) - [Multi-Cloud-Strategy](concepts/Multi-Cloud-Strategy.md) +- [Pay-as-you-go](concepts/Pay-as-you-go.md) - [Risk-Mitigation](concepts/Risk-Mitigation.md) - [ROI](concepts/ROI.md) - [Rollback-Rate](concepts/Rollback-Rate.md) - [Scalability](concepts/Scalability.md) +- [Shared-Responsibility-Model](concepts/Shared-Responsibility-Model.md) - [Time-to-Market](concepts/Time-to-Market.md) - [Vendor-Lock-In](concepts/Vendor-Lock-In.md) diff --git a/wiki/log.md b/wiki/log.md index beb60d79..d218928c 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,247 @@ +## [2026-04-22] ingest | 如何在Ubuntu Server安装 Docker & Docker Compose + +- Source file: raw/Home Office/如何在Ubuntu Server安装 docker & docker compose.md +- Status: ✅ 成功摄入 +- Summary: 在 Ubuntu Server 上通过 Docker 官方 apt 仓库安装 Docker Engine 和 Docker Compose V2 的完整五步流程，涵盖仓库配置、GPG 密钥导入、非 root 用户权限配置及 hello-world 镜像验证 +- Concepts created: [[Docker 用户组]], [[APT 仓库配置]], [[GPG 密钥验证]] +- Entities created: [[Docker Engine]], [[Docker-CE]], [[containerd]], [[hello-world]], [[docker-buildx-plugin]], [[docker-compose-plugin]] +- Concepts updated: overview.md（Home Server Automation 概念列表新增 Docker Engine、Docker 用户组、APT 仓库配置、GPG 密钥验证）；[[Docker Compose]] Concept 新增 V1 vs V2 命令对比表 +- Entities updated: index.md（替换 placeholder 为实际内容）；Docker-Compose.md Concept 新增版本说明 +- Source page: wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md +- Notes: 该源文件是 Home Server 容器化环境搭建的基础；[[Docker Engine]] Entity 记录了 dockerd、CLI、containerd 三大组件及包组成；[[Docker 用户组]] Concept 记录了 usermod -aG docker 安全风险；[[APT 仓库配置]] Concept 记录了 /etc/apt/sources.list.d/ 配置方式；[[GPG 密钥验证]] Concept 记录了 Docker 官方密钥导入流程；docker-compose-plugin Entity 记录了 V1 到 V2 的命令变化；与 [[frp]]、[[Prometheus]] 等服务共同构成 Home Server 知识体系 +- Conflicts: 无 + +## [2026-04-30] ingest | Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记 +- Source file: raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md +- Status: ✅ 成功摄入 +- Summary: 在 Apple Silicon Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，包含 Gatekeeper 解除、launchd 开机自启、tmux/nohup 后台运行三种方式 +- Concepts created: [[launchd]], [[Gatekeeper]], [[软链接策略]] +- Entities created: [[Mac Mini M4]] +- Concepts updated: overview.md（Home Server Automation 概念列表新增 launchd、Gatekeeper、软链接策略） +- Entities updated: overview.md（新增 Mac Mini M4 实体描述；frp 实体新增 TCP/UDP/HTTP 多协议支持说明） +- Source page: wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md +- Notes: 该源文件是 Mac Mini 服务器化运维的重要组成部分；[[Mac Mini M4]] Entity 记录了 Apple Silicon 架构、ARM64 兼容性及 Home Server 应用场景；[[launchd]] Concept 记录了 macOS 原生服务管理器与 launchctl 命令；[[Gatekeeper]] Concept 记录了 xattr -rd com.apple.quarantine 解除方法；[[软链接策略]] Concept 记录了版本切换的最佳实践；与 [[frp]] Entity 形成完整的内网穿透知识体系（客户端安装→服务端配置→进程管理） +- Conflicts detected: 无冲突 + +## [2026-04-30] ingest | 在Synology NAS上安装CloudDrive2 +- Source file: raw/Home Office/在Synology NAS上安装CloudDrive2.md +- Status: ✅ 成功摄入 +- Summary: 通过矿神源在群晖 NAS 安装 CloudDrive2，使用阿里云盘 App 扫码授权挂载云盘资源目录的完整操作流程，含 DSM 7+ Root 权限修复命令 +- Concepts created: [[云盘挂载]], [[NAS套件管理]], [[Root权限修复]], [[SPK套件格式]] +- Entities created: [[CloudDrive2]], [[矿神源]], [[阿里云盘]] +- Concepts updated: overview.md（Home Server Automation 概念列表新增 云盘挂载、NAS套件管理、Root权限修复、SPK套件格式） +- Entities updated: overview.md（新增 CloudDrive2、矿神源、阿里云盘 实体描述） +- Source page: wiki/sources/在synology-nas上安装clouddrive2.md +- Notes: 该源文件是 NAS 云盘挂载的实操指南；[[CloudDrive2]] Entity 记录了云盘挂载工具的核心特性（多云盘支持、Web UI 端口 19798、最小权限授权原则）；[[矿神源]] Entity 记录了 Synology 社群套件源机制及 DSM 7+ 兼容性差异；[[云盘挂载]] Concept 详细阐述了 FUSE/虚拟文件系统的挂载原理、与传统同步方案的对比；[[NAS套件管理]] Concept 记录了 Package Center 架构、SPK 格式及 DSM 7+ Root 权限修复的标准 Pattern（sed 替换 privilege 文件中的 package→root）；形成 NAS 云盘生态知识体系（矿神源→CloudDrive2→阿里云盘） +- Conflicts detected: 无冲突 + +## [2026-04-29] ingest | 安装Ubuntu 24.04.2在HP ZBook工作站笔记本上 +- Source file: raw/Home Office/安装Ubuntu-24.04.2在HP Zbook工作站笔记本上.md +- Status: ✅ 成功摄入 +- Summary: 在 HP ZBook 工作站笔记本上安装 Ubuntu 24.04.2 Desktop 的完整指南，涵盖 Rufus ISOHybrid 启动盘制作、GPT 分区方案（/boot/efi FAT32 + / ext4 + /home ext4 + swap）、HP BIOS UEFI 设置（F9/F10/AHCI/Secure Boot/Fast Boot）、efibootmgr NVRAM 启动项修复及 UEFI Only 模式终极解决方案 +- Concepts created: [[efibootmgr]], [[ISOHybrid镜像]], [[UEFI Only]], [[NVMe硬盘分区]] +- Entities created: [[HP ZBook]], [[Rufus]] +- Source page: wiki/sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md +- Notes: HP ZBook Entity 记录 BIOS 固执行为（Boot0005 注册成功但未加入 BootOrder）及三种修复方案；Rufus Entity 记录 ISOHybrid 写入模式选择；efibootmgr Concept 记录核心命令及 NVRAM 操作机制；ISOHybrid Concept 记录 ISO/DD 两种写入模式；UEFI Only Concept 记录消除 Legacy BBS 项干扰的终极方案 +- Conflicts detected: 无冲突；与 [[clonezilla对ubuntu-server进行全盘镜像备份]] 在 HP ZBook 用途上互补（安装 → 镜像备份工作流） + +## [2026-04-29] ingest | 通过VPS+内网反向代理实现域名访问内网穿透 +- Source file: raw/Home Office/通过VPS+内网反向代理实现域名访问内网穿透.md +- Status: ✅ 成功摄入 +- Summary: 通过 VPS + frp + Caddy 实现内网服务的公网域名访问完整方案，支持 NAS/n8n/Grafana 等多服务子域名访问，包含 DNS 配置、服务端/客户端安装配置、Caddy 反向代理、SSH 穿透及完整故障排查指南 +- Concepts created: [[内网穿透]], [[反向代理]], [[TCP隧道]], [[Caddy]], [[frp]] +- Entities created: [[frp]], [[Caddy]], [[阿里云 DNS]], [[VPS]] +- Source page: wiki/sources/通过vps-内网反向代理实现域名访问内网穿透.md +- Notes: frp Entity 页面记录 frps/frpc 架构、认证机制、Dashboard 配置；Caddy Entity 页面记录自动 HTTPS、Caddyfile 配置、与 frp 集成；形成完整内网服务公网访问架构（frp 隧道 → Caddy 反代 → 自动 HTTPS） +## [2026-04-22] ingest | 如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略 +- Source file: raw/Home Office/如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略.md +- Status: ✅ 成功摄入 +- Summary: 通过AdsPower指纹浏览器+高纯净度美国代理+PingMe接码平台+WildCard虚拟信用卡，安全注册并订阅Claude Pro的完整实操攻略，涵盖从工具下载安装、IP设置、账号注册、验证码获取到付费订阅的完整流程 +- Concepts created: [[指纹浏览器]], [[IP纯净度]], [[账号隔离]], [[虚拟信用卡]], [[接码平台]], [[跨境支付]] +- Entities created: [[AdsPower]], [[PingMe]], [[WildCard]], [[Claude Pro]] +- Concepts updated: overview.md（Home Server Automation 概念列表新增 指纹浏览器、IP纯净度、虚拟信用卡、接码平台、账号隔离） +- Entities updated: overview.md（新增 AdsPower、PingMe、WildCard、Claude Pro 实体描述） +- Source page: wiki/sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md +- Notes: 该源文件是跨境AI服务注册的完整实操指南，提供了账号隔离的完整工具链（指纹浏览器→独立代理IP→IP纯净度检测→接码平台→虚拟信用卡）；[[AdsPower]] Entity记录了免费版5个环境限制；[[PingMe]] Entity记录了订阅制接码平台相比一次性号码的优势；[[WildCard]] Entity记录了支付宝充值这一国内用户友好特性；[[Claude Pro]] Entity记录了国内用户面临的支付挑战；6个Concept页面形成了跨境服务注册的知识体系 +- Conflicts detected: 无冲突；与 [[v2rayN]], [[v2rayNG]], [[Bandwagon VPS]] 等代理相关内容互补，共同构成跨境网络访问的完整方案（网络层：代理工具→应用层：指纹浏览器隔离→支付层：虚拟信用卡） + +## [2026-04-22] ingest | 用Docker安装it-tools +- Source file: raw/Home Office/用Docker安装it-tools.md +- Status: ✅ 成功摄入 +- Summary: 使用 Docker Compose 在 Home Server 部署 it-tools 开发者工具集合，通过 `corentinth/it-tools:latest` 镜像暴露 8999 端口，配置 128MB 内存限制与 unless-stopped 重启策略 +- Concepts created: [[Docker-Compose]], [[容器资源限制]], [[容器重启策略]], [[端口映射]] +- Entities created: [[it-tools]] +- Source page: wiki/sources/用docker安装it-tools.md +- Notes: 源文件内容简洁，仅包含 YAML 配置片段。it-tools 是 Home Server 工具栈（Transmission/Jellyfin/Navidrome）之外的开发者工具补充。 + +## [2026-04-28] ingest | Clonezilla对Ubuntu Server进行全盘镜像备份 +- Source file: raw/Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份.md +- Status: ✅ 成功摄入 +- Summary: 使用 Clonezilla 对 Ubuntu Server 进行全盘镜像备份到 NAS 的完整操作流程，含 Rufus 启动盘制作（ISOHybrid ISO 模式）、NFS 网络挂载、savedisk/restoredisk 备份还原及 UEFI/BIOS 分区方案选择 +- Concepts created: [[全盘镜像备份]], [[裸机恢复]], [[NFS网络备份]], [[UEFI启动]] +- Entities created: [[Clonezilla]], [[Rufus]], [[HP ZBook]] +- Concepts updated: overview.md（Home Server Automation 概念列表新增 全盘镜像备份、裸机恢复、NFS网络备份、UEFI启动） +- Entities updated: overview.md（新增 Clonezilla、Rufus、HP ZBook 实体描述） +- Source page: wiki/sources/clonezilla对ubuntu-server进行全盘镜像备份.md +- Notes: Clonezilla 与 rsync 增量备份互补（镜像备份=系统级完整恢复，rsync=文件级日常增量）；两者结合构成完整灾备策略（全盘镜像定期做，系统崩溃直接还原，日常增量数据随时可取）；[[NFS网络备份]] 是 Clonezilla 推荐的网络存储方案，Linux 原生支持；[[UEFI启动]] 与 MBR/BIOS 的分区方案选择是启动盘制作的关键 +- Conflicts detected: 无冲突 + +- Source file: raw/Home Office/3X-UI Xray on BandwagonVPS.md +- Status: ✅ 成功摄入 +- Summary: 在 Bandwagon VPS（VPS2）上通过 3X-UI 可视化管理面板部署 Xray 代理服务（VLESS+Reality 协议）的完整操作记录，包含一键安装命令（bash脚本）、25项管理菜单说明、公钥私钥生成流程、v2rayN/v2rayNG 客户端配置、BBR启用及双向网络测试（国内/国外直连均200） +- Concepts created: [[VPN Panel]], [[Xray]], [[BBR]], [[Web Proxy Protocol]] +- Entities created: [[3X-UI]], [[Bandwagon VPS]], [[v2rayN]], [[v2rayNG]] +- Concepts updated: overview.md（Home Server Automation 概念列表新增 VPN Panel、Xray、BBR、Web Proxy Protocol） +- Entities updated: overview.md（新增 3X-UI、Xray、Bandwagon VPS、v2rayN、v2rayNG、BBR、VPN Panel 实体描述；冲突区域第5条扩充为三层方案对比） +- Source page: wiki/sources/3x-ui-xray-on-bandwagonvps.md +- Notes: 3X-UI 与 [[网件RAX50刷梅林固件与科学上网]] 属于科学上网领域的不同实现层级，前者是 VPS 服务端（集中式），后者是路由器网关（透明代理）；两者可通过订阅机制联动，构成完整的家庭科学上网架构（路由器→VPS节点）；Bandwagon VPS 作为低总价 VPS 代表，其 openVZ/KVM 方案在个人科学上网场景中广泛应用；VLESS+Reality 协议组合因无状态特性（服务端不保存用户状态）适合多用户/高并发场景 +- Conflicts detected: 与 [[网件RAX50刷梅林固件与科学上网]] 存在实现层级冲突（见 Conflict Area #5），已协调处理 + +## [2026-04-28] ingest | 用Docker安装transmission +- Source file: raw/Home Office/用Docker安装transmission.md +- Status: ✅ 成功摄入 +- Summary: 通过 Docker Compose 在 Home Server 部署 Transmission BT 下载服务，使用 linuxserver/transmission 官方镜像，包含 Web UI 认证配置（USER/PASS）、下载目录挂载、PUID/PGID 权限映射、桥接网络端口映射 +- Concepts created: [[PUID/PGID]], [[端口映射]], [[桥接网络]] +- Entities created: [[Transmission]], [[LinuxServer.io]] +- Concepts updated: overview.md（新增 PUID/PGID、端口映射、桥接网络 到 Home Server Automation 概念列表） +- Entities updated: overview.md（新增 Transmission、LinuxServer.io 实体描述；更新群晖 NAS 实体补充 BT 文件存储角色） +- Source page: wiki/sources/用docker安装transmission.md +- Notes: Source page 包含完整 docker-compose.yml 配置；Transmission 与 Jellyfin/Navidrome 形成"下载→播放"媒体工作流（Transmission=下载，Jellyfin=视频播放，Navidrome=音乐播放）；LinuxServer.io 作为 Docker 镜像维护组织的标准化配置模式（PUID/PGID/TZ/restart:unless-stopped/bridge）贯穿所有自托管部署；Web UI 认证（USER/PASS）是生产环境安全必备配置 +- Conflicts detected: 无冲突；与 [[用docker安装jellyfin]] 形成互补（jellyfin=播放，transmission=下载，共同服务于家庭媒体中心工作流） + +## [2026-04-27] ingest | RAX50路由器更新Merlin Clash订阅 +- Source file: raw/Home Office/RAX50 路由器 更新Merlin Clash订阅.md +- Status: ✅ 成功摄入 +- Summary: 在 RAX50 路由器的 Merlin Clash 界面中更新科学上网订阅配置的完整操作流程，包含小白一键订阅助手导入 vless URL、配置文件切换（保存&启动）及快速重启故障处理 +- Concepts: 订阅更新, 配置文件切换, 快速重启（均为小操作步骤，未单独建页，归入 [[RAX50路由器刷梅林固件与科学上网]] 的操作子流程） +- Entities: 网件RAX50, MerlinClash插件, 小白一键订阅助手, 机场（均已存在，无新建） +- Source page: wiki/sources/rax50-路由器-更新merlin-clash订阅.md +- Notes: 本文档是 [[网件RAX50路由器刷梅林固件与科学上网插件安装教程]] 的日常维护补充篇；核心价值在于记录订阅更新的具体操作步骤（小白订阅助手 + 快速重启技巧）；所有关键实体和概念均已在主教程中建档，本次仅补充 source page +- Conflicts detected: 无冲突；与前一篇 RAX50 刷机教程形成完整生命周期覆盖（安装配置 → 订阅更新） + +## [2026-04-26] ingest | 网件RAX50路由器刷梅林固件与科学上网插件安装教程 +- Source file: raw/Home Office/网件RAX50路由器刷梅林固件与科学上网插件安装教程.md +- Status: ✅ 成功摄入 +- Summary: 网件RAX50路由器刷入梅林固件并安装配置科学上网插件的完整实操教程，涵盖二次刷机流程（.chk过渡固件 → .w正式固件）、JFFS双清、MerlinClash策略组分流配置、订阅机制和故障转移机制 +- Concepts created: 固件刷入, 过渡固件, JFFS双清, 策略组分流, 故障转移, 订阅机制 +- Entities created: 网件RAX50, 梅林固件, MerlinClash插件, KoolCenter固件服务器, 机场 +- Concepts updated: overview.md（新增固件刷入、过渡固件、JFFS双清、策略组分流、故障转移、订阅机制 到 Home Server Automation 概念列表） +- Entities updated: overview.md（新增网件RAX50、梅林固件、MerlinClash插件、机场、KoolCenter固件服务器实体描述） +- Source page: wiki/sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md +- Notes: Source page包含完整刷机流程详解；6个新Concept页面覆盖路由器固件和科学上网核心概念；5个新Entity页面覆盖硬件设备、软件平台和服务实体；新增冲突区域：路由器网关科学上网 vs NAS/服务器终端代理（部署层级差异）；与群晖NAS科学上网、ubuntu-server科学上网形成部署方案对比 +- Conflicts detected: 与群晖NAS科学上网（NAS终端代理 vs 路由器网关代理）、ubuntu-server科学上网（服务器VPN vs 路由器透明代理）形成部署层级冲突 +- SLUG: 网件rax50路由器刷梅林固件与科学上网插件安装教程 + +## [2026-04-26] ingest | MySQL MariaDB 数据库详细信息 +- Source file: raw/Home Office/MySQL MariaDB 数据库详细信息.md +- Status: ✅ 成功摄入 +- Summary: MariaDB/MySQL 数据库访问配置信息及远程用户创建流程，包含内网（192.168.3.17:3307）和公网（mysql.ishenwei.online:63307）双通道访问配置，以及通过 socket 登录创建远程访问用户的完整指南 +- Concepts created: Socket 登录, 用户权限 +- Entities created: MariaDB +- Concepts updated: overview.md（新增 Socket 登录、用户权限 到 Home Server Automation 概念列表） +- Entities updated: overview.md（新增 MariaDB 实体描述，补充群晖 NAS 为 MariaDB 部署平台） +- Source page: wiki/sources/mysql-mariadb-数据库详细信息.md +- Notes: Entity 页面记录完整内网/公网访问配置（IP、端口、域名、凭证）；Socket 登录是本地管理员访问的安全方式（通过 Unix socket 文件认证，无需网络）；Host+User 组合是 MariaDB 权限模型的核心；新安装 MariaDB 默认只有 root@localhost，这是远程连接失败的常见原因 +- Conflicts detected: 无冲突 +- SLUG: mysql-mariadb-数据库详细信息 + +## [2026-04-26] ingest | Ubuntu服务器通过rsync实现日常增量备份 +- Source file: raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md +- Status: ✅ 成功摄入 +- Summary: Ubuntu服务器通过rsync实现日常增量备份到NAS的完整解决方案，涵盖rsync自动化脚本、Cron定时任务、NFS永久挂载配置(/etc/fstab + _netdev参数)、Docker卷备份策略(先mysqldump再rsync)及灾备恢复流程 +- Concepts created: 增量备份, 永久挂载, 挂载点检查, Cron定时任务, 进程管理 +- Entities created: Docker卷 +- Concepts updated: overview.md（新增5个备份相关概念到Home Server Automation主题） +- Entities updated: overview.md（新增Docker卷实体描述） +- Source page: wiki/sources/ubuntu服务器通过rsync实现日常增量备份.md +- Notes: Source page包含完整可运行的rsync_backup.sh脚本；关键参数-a(归档)-z(压缩)-R(相对路径)--delete(镜像同步)；错误码0/23/24均视为成功(23=权限问题,24=源文件消失)；_netdev参数是NFS永久挂载的必备安全配置；与已有Disaster Recovery策略形成互补(增量备份vs整机镜像) +- Conflicts detected: 无冲突 +- SLUG: ubuntu服务器通过rsync实现日常增量备份 + +## [2026-04-26] ingest | Linux 运维必会的 150 个命令 +- Source file: raw/Home Office/Linux 运维必会的 150 个命令.md +- Status: ✅ 成功摄入 +- Summary: Linux 系统管理命令全面分类参考，涵盖 150 个运维必备命令，按 16 大类组织（线上查询帮助/文件目录操作/文本处理/压缩解压缩/信息显示/搜索文件/用户管理/基础网络/深入网络/磁盘文件系统/权限管理/用户登录信息/内置命令/系统监控/关机重启/进程管理） +- Concepts created: Shell 命令, 系统命令, 管道（Pipe）, 重定向 +- Source page: wiki/sources/linux-运维必会的-150-个命令.md +- Notes: 核心洞察："Linux 一切皆文件"哲学——CPU/内存/磁盘/键盘/用户等均抽象为文件；16 大类命令覆盖 Linux 运维全场景；与 Home Server Automation 主题形成互补（实用命令参考 vs 场景化部署指南）；该文档为纯知识参考，无冲突点 +- Conflicts detected: 无 + +- Source file: raw/Home Office/用Docker中安装Navidrome.md +- Status: ✅ 成功摄入 +- Summary: 通过 Docker Compose 在群晖 NAS 上部署 Navidrome 开源音乐流媒体服务器，包含转码缓存（200MB上限）、自动转码下载、只读音乐挂载、非root用户运行等关键配置 +- Concepts created: Docker Compose, 媒体服务器, 转码缓存, 只读挂载 +- Entities created: Navidrome（Entity页面：开源音乐流媒体服务器，Subsonic API兼容） +- Concepts updated: overview.md（新增 Docker Compose、媒体服务器、转码缓存、只读挂载到 Home Server Automation 概念列表） +- Entities updated: overview.md（新增 Navidrome、群晖 NAS 实体描述） +- Source page: wiki/sources/用docker中安装navidrome.md +- Notes: Docker Compose 配置使用 version: '3.8'；user: "1026:100" 对应宿主机用户权限；音乐目录只读挂载（:ro）是关键安全措施；ND_AUTOTRANSCODEDOWNLOAD=true 启用客户端按需转码；Navidrome 与 Jellyfin 形成音乐vs视频的媒体服务器互补关系 +- Conflicts detected: 无 + +## [2026-04-26] ingest | Cloud Operating Model: Key Strategies and Best Practices +- Source file: raw/Cloud & DevOps/Cloud Operating Model Key Strategies and Best Practices.md +- Status: ✅ 成功摄入 +- Summary: 云运营模型(COM)全面指南，涵盖四大核心支柱（治理与合规、自动化、 安全、成本管理）、六步设计流程、行业用例（金融/医疗/零售/SaaS）及未来趋势（AI运营、绿色计算、多云治理） +- Concepts created: Cloud Operating Model, Cloud Governance, Cloud Cost Optimization, Serverless Computing, Green Computing +- Concepts updated: overview.md（新增 Cloud Operating Model、Cloud Governance、Cloud Cost Optimization、Serverless Computing、Green Computing 概念链接） +- Source page: wiki/sources/cloud-operating-model-key-strategies-and-best-practices.md +- Notes: Source page 包含完整六大支柱和六步设计流程；5个新 Concept 页面覆盖云运营模型核心概念；与已有 FinOps、Multi-Cloud Strategy、Zero-Trust-Architecture、AIOps 等概念形成知识链接；89%组织预计2025年采用云优先架构；FinOps可降低40-70%计算成本；AI驱动异常检测可减少45%停机时间 +- Conflicts detected: 无重大冲突；与传统本地IT的对比形成方法论演进关系而非冲突 + +## [2026-04-26] ingest | What is DevSecOps? Best Practices, Benefits, and Tools +- Source file: raw/Cloud & DevOps/What is DevSecOps Best Practices, Benefits, and Tools.md +- Status: ✅ 成功摄入 +- Summary: DevSecOps 将安全深度集成到软件开发生命周期的方法论，通过 Shift Left（安全左移）和 Shift Right（安全右移）策略，在 SDLC 各阶段嵌入安全检查；通过 SAST/DAST/IAST/SCA 等工具实现自动化安全测试；涵盖 5 大核心组件（协作/沟通/自动化/工具安全/测试）和 8 大最佳实践；70% 的上线后漏洞本可通过 DevSecOps 预防 +- Concepts created: DevSecOps, Shift-Left-Security, Shift-Right-Security, SAST, DAST, IAST, SCA, Break-the-Build, Immutable-Infrastructure, Threat-Modeling, OWASP-Top-Ten, Bug-Bounty, Vulnerability-Scanning, Penetration-Testing, Compliance-Automation +- Entities referenced: Amazon-Inspector, Amazon-CodeGuru-Reviewer, AWS-CodePipeline, Snyk, SonarQube, Jenkins, Docker, Kubernetes +- Concepts updated: overview.md（新增 DevSecOps 生态相关概念链接） +- Source page: wiki/sources/what-is-devsecops-best-practices-benefits-and-tools.md +- Notes: 共创建 15 个 Concept 页面覆盖 DevSecOps 核心概念；补充 DevOps vs DevSecOps 完整对比表；SAST/DAST/IAST/SCA 四种安全测试方法形成互补体系；Shift Left/Right 互补策略覆盖开发到生产全链路；Bug Bounty 与传统渗透测试形成外部+内部安全测试闭环；Compliance-Automation 与 Policy-as-Code（已有）形成策略管理互补 +- Conflicts detected: 无重大冲突；Compliance-Automation 与已有的 Policy-as-Code 概念存在互补关系而非冲突（Policy-as-Code 是实现方式，Compliance-Automation 是目标） +- SLUG: what-is-devsecops-best-practices-benefits-and-tools + +## [2026-04-26] ingest | Modern ITSM: Driving Efficiency, Security & Resilience +- Source file: raw/Cloud & DevOps/Understanding Complete ITSM.md +- Status: ✅ 成功摄入 +- Summary: 现代IT服务管理(ITSM)已超越传统工单系统，成为企业运营卓越、风险缓解和创新加速的战略推动者。通过AIOps、预测分析、自动化修复、自愈系统等AI驱动技术重构ITSM八大核心流程。ITSM 2.0融合AIOps和超自动化，具备自学习、预测性和自主化能力。 +- Concepts created: ITSM, ITSM-2.0, Hyperautomation, AIOps, Self-Healing-Systems, Zero-Trust-Architecture, Policy-as-Code, CMDB, DRaaS, Canary-Release, Blue-Green-Deployment, Event-Correlation, Problem-Management, Incident-Management, Change-Management, Release-Management, Configuration-Management, Asset-Management, Security-and-Compliance +- Concepts updated: overview.md（新增[[Self-Healing-Systems]]链接覆盖命名不一致） +- Entities created: shenwei（LinkedIn文章作者） +- Source page: wiki/sources/understanding-complete-itsm.md +- Notes: 共创建18个Concept页面覆盖ITSM八大流程和关键使能技术；发现命名不一致问题：已有页面使用"Self-Healing Systems"（带空格），新建页面使用"[[Self-Healing-Systems]]"（无空格连字符）；建议后续统一为"Self-Healing-Systems"标准命名 +- Conflicts detected: Self-Healing Systems vs Self-Healing-Systems 命名不一致 + +## [2026-04-26] ingest | How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets +- Source file: raw/Cloud & DevOps/How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md +- Status: ✅ 成功摄入 +- Summary: 多账户 CloudFormation StackSets 部署场景下，通过 EventBridge Rules 捕获各账户 CloudFormation 事件，跨账户转发到管理账户统一 Event Bus，写入 CloudWatch Log Group，实现单一界面的跨账户部署可观测性。单次部署同时完成中心基础设施创建和成员账户规则推送。 +- Concepts created: Centralized Logging, Cross-Account Monitoring, Multi-Account Deployment, StackSets Deployment Visibility +- Entities created: AWS CloudFormation StackSets, Amazon EventBridge, Amazon CloudWatch Logs, AWS Organizations +- Concepts updated: Infrastructure-as-Code（补充 CloudFormation StackSets） +- Entities updated: AWS（补充 StackSets/EventBridge/CloudWatch Logs/Organizations 服务索引）, Terraform（补充与 StackSets 的多账户 IaC 对比） +- Source page: wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md +- Notes: Source page 包含完整四组件架构和事件流；4个新 Concept 页面覆盖多账户集中监控全链路；4个新 Entity 页面记录 AWS 服务能力；AWS entity 服务索引已扩展覆盖 IaC/可观测性/安全/组织四大类；Terraform entity 新增多账户 IaC 对比参考 +- SLUG: how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets + +## [2026-04-25] ingest | These 6 Linux Apps Let You Monitor System Resources in Style +- Source file: raw/Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md +- Status: ✅ 成功摄入 +- Summary: 6款Linux系统资源监控工具评测：TUI类（Btop++/Htop/Glances/Bottom）适合SSH远程服务器管理；GUI类（Mission Center/Stacer）适合桌面用户。作者首选Btop++，兼具美观与实用；GUI首选Mission Center（类Windows任务管理器）或Stacer（功能最全） +- Concepts created: TUI, Process Management, System Monitoring + +## [2026-04-25] ingest | RTO vs RPO: Key Differences for Modern Disaster Recovery +- Source file: raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md +- Status: ✅ 成功摄入 +- Summary: 现代持续交付场景下 RTO 和 RPO 的核心区别；传统灾备（硬件故障）vs 软件优先方法（代码变更风险）；Feature Flag 将 RTO 从小时降至秒级、RPO 保持近零；渐进式放量控制影响范围；Tier 1/2/3 分层保护策略；HP、Christian Dior、LaunchDarkly 客户案例数据 +- Concepts created: RTO, RPO, Feature Flag, Kill Switch, Progressive Rollout, Micro-Recovery, Deployment-vs-Release, Business Impact Analysis +- Entities created: LaunchDarkly, Veeam, Acronis +- Source page: wiki/sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md +- Notes: index.md 和 overview.md 已同步更新；与传统灾备工具（Veeam/Acronis）形成对比关系；Progressive Rollout 与 Kill Switch 结合形成精细化风险控制体系 +- Entities created: Btop++, Htop, Glances, Bottom, Mission Center, Stacer +- Source page: wiki/sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md +- Notes: 6个Entity页面（Btop++/Htop/Glances/Bottom/Mission Center/Stacer）+ 3个Concept页面（TUI/Process Management/System Monitoring）；与Home Server Automation分类下的Prometheus/Grafana监控体系形成补充（TUI/GUI工具 vs 时间序列数据库+可视化面板）；overview.md新增Linux System Monitoring主题段落 +- SLUG: these-6-linux-apps-let-you-monitor-system-resources-in-style + ## [2026-04-24] ingest | DevOps Maturity Model From Traditional IT to Advanced DevOps - Source file: raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md - Status: ✅ 成功摄入 @@ -38,14 +282,16 @@ - Notes: Source page 包含完整12个运营域详解；新创建3个 Concept 页面（Cloud-Service-Delivery、Cloud-DevOps-Maturity-Model、AIOps）；更新 overview.md 补充新概念索引（Cloud Service Delivery、Cloud DevOps Maturity Model、AIOps、SLA、SLO、Incident Management、Change Management、Disaster Recovery、WAF、APM）；与已有 DevOps Maturity、DORA Metrics、FinOps 等概念形成知识链接 - SLUG: what-i-know-about-cloud-service-delivery-1 -## [2026-04-22] ingest | Cloud Maturity Model - A Detailed Guide For Cloud Adoption +## [2026-04-25] ingest | Cloud Maturity Model - A Detailed Guide For Cloud Adoption - Source file: raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md - Status: ✅ 成功摄入 - Summary: Cloud Maturity Model (CMM) 综合指南，涵盖 OACA 定义的 CMM 框架、6个业务能力域和18个技术能力域、3大评估维度（People/Processes/Technology）、5个成熟度等级（Level 0-5）及其特征、7大收益、最佳实践（设定目标/识别等级/选模型/治理合规/安全风险管理）以及多种云成熟度模型对比（AWS CAF/Azure CAF/CSMM/SAMM等）。CMM 行业规模预计从2022年7.5亿美元增至2025年15亿美元，60%以上组织正在实施。 -- Concepts created: Cloud-Adoption-Strategy, Cloud-Maturity-Levels, Multi-Cloud-Strategy +- Concepts created: Cloud-Maturity-Levels, Cloud-Adoption-Strategy, Multi-Cloud-Strategy, Cloud-Governance, Cloud-Cost-Optimization, Cloud-Native, Cloud-Security, FinOps, Cloud-Native-Maturity-Model, Cloud-Security-Maturity-Model, Software-Assurance-Maturity-Model +- Concepts updated: Multi-Cloud-Strategy (补充已有) - Entities created: Cloud-Maturity-Model, Open-Alliance-for-Cloud-Adoption - Source page: wiki/sources/cloud-maturity-model-a-detailed-guide-for-cloud-adoption.md -- Notes: Source page 包含完整5个成熟度等级详解（含每级挑战表格）；新创建3个 Concept 页面（Cloud-Adoption-Strategy、Cloud-Maturity-Levels、Multi-Cloud-Strategy）；新创建2个 Entity 页面（Cloud-Maturity-Model、Open-Alliance-for-Cloud-Adoption）；更新 overview.md 补充新概念索引；与已有 DevOps-Maturity 和 Cloud-Native 形成知识链接 +- Notes: 本次补充创建11个 Concept 页面（覆盖治理、成本优化、云原生、安全、FinOps、云原生成熟度、CSMM、SAMM 等领域），使文档中的所有关键概念均有对应知识页面；Entity 页面补全（CMM 主体框架 + OACA 联盟介绍）；Source page 已于 2026-04-22 创建，本次完善概念/实体层 +- SLUG: cloud-maturity-model-a-detailed-guide-for-cloud-adoption ## [2026-04-22] ingest | Contributing to The Agency - Source file: raw/Agent/agency-agents/CONTRIBUTING.md @@ -579,4 +825,98 @@ - Source page: wiki/sources/how-can-a-multi-cloud-strategy-transform-your-business-roi.md - Notes: Source page 包含完整12个章节；新创建6个 Concept 页面（Vendor-Lock-In、Data-Sovereignty、Scalability、Cost-Optimization、ROI、Risk-Mitigation）；新创建1个 Entity 页面（Cloud-Provider）；更新 overview.md 补充新概念索引；Multi-Cloud-Strategy 概念页面已存在，本次补充来源引用；与已有 DevOps/Cloud DevOps 知识体系高度互补（成本/风险/合规是云成熟度模型的重要组成部分） -## [2026-04-23] \ No newline at end of file +## [2026-04-23] +## [2025-03-02] ingest | The Myths and Misconceptions About Cloud Computing | LinkedIn +- Source file: raw/Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn.md +- Status: ✅ 成功摄入 +- Summary: LinkedIn 文章系统性反驳云计算七大误解：云不如本地安全（实际云安全机制+合规认证超越本地）、云是别人电脑（实际是大规模高可用数据中心网络）、云太贵（实际按需付费+预留+自动扩缩可降本）、数据失控（实际完善权限管理+混合多云）、只适合大企业（实际 SMB 和初创同样受益）、迁移太复杂（实际分阶段+混合云+专业服务可平滑迁移）、性能不可靠（实际 SLA 保障 99.99% 可用性）。 +- Concepts created: Pay-as-you-go, Failover, Multi-factor-Authentication, Data-Governance +- Entities created: Raj-Vardhan-Singh（LinkedIn 作者）, ISO-27001, HIPAA, GDPR +- Source page: wiki/sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md +- Notes: cloud-computing.md 实体页面和 high-availability.md、cloud-security.md 概念页面已存在，本次补充来源引用和 Key Misconceptions 章节；新创建4个 Concept 页面和3个 Entity 页面；与 cloud-migration、Cost-Optimization、High-Availability 等已有概念高度互补 + +## [2026-04-25] ingest | How Agentic AI can help for Cloud DevOps +- Source file: raw/Cloud & DevOps/How Agentic AI can help for Cloud DevOps.md +- Status: ✅ 成功摄入 +- Summary: Agentic AI（具有自主决策和任务执行能力的AI系统）增强 Cloud DevOps 的全面指南，涵盖7大能力领域：自主事故检测与解决（Self-Healing + AI-driven RCA）、自动化云部署与配置（AI Release Manager + IaC审查）、智能成本优化（Rightsizing + Spot Instance）、AI驱动安全与合规（自动IAM审计 + 漏洞修复）、智能日志分析与可观测性（AI ChatOps）、增强多租户SaaS管理、AI增强决策支持（What-If Simulation）。核心理念：通过集成AI驱动的自动化实现更快部署、更主动的问题解决、更低成本和更强的安全合规。 +- Concepts created: Agentic AI, Self-Healing Systems, Root Cause Analysis (RCA), Predictive Maintenance, Deployment Automation, Rightsizing, Automated Security Audit, AI ChatOps, What-If Simulation +- Concepts updated: AIOps（补充 Agentic AI 具体实现场景）、Infrastructure-as-Code（补充 Terraform AI审查场景）、Multi-Cloud Strategy（补充 What-If Simulation 决策支持）、FinOps（补充 Rightsizing 实践） +- Entities created: Agentic AI（实体页面）、Kubernetes（补充 EKS/GKE/AKS Self-Healing 场景）、Terraform（补充 AI IaC 审查场景） +- Source page: wiki/sources/how-agentic-ai-can-help-for-cloud-devops.md +- Notes: Source page 包含完整7大应用领域详解；新创建8个 Concept 页面和3个 Entity 页面；补充 AIOps 的具体实现场景（从 Level 3 到 Level 5 的演进路径）；识别3个冲突领域（自动修复 vs 人工审批控制、Spot Instance vs SLA 保证、AI 自动化 vs DevOps 人本主义）；与已有 DevOps 成熟度、DORA Metrics、FinOps 等概念形成知识链接；Agentic AI 作为新主题首次系统建立为独立 Entity/Concept 体系 +- SLUG: how-agentic-ai-can-help-for-cloud-devops + +## [2026-05-02] ingest | Public vs Private vs Hybrid Cloud Differences Explained +- Source file: raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md +- Status: ✅ 成功摄入 +- Summary: BMC Blog 深入解析公有云、私有云和混合云三种云部署模型的定义、核心特征、优缺点及适用场景决策框架。强调"平衡是云架构核心驱动力"，引入 Shared Responsibility Model（无论哪种云模式，企业对访问控制、加密和灾难恢复规划负最终责任）；混合云部分详述同构/异构决策和三种典型用例（核心+弹性、安全+成本、本地+爆发）。 +- Concepts created: **[[Public-Cloud]]**（公有云：多租户共享、按需付费、九大优势/四大缺陷、适用场景TCO对比）、**[[Private-Cloud]]**（私有云：独占环境、高安全性、五大优势/五大缺陷、适用场景TCO对比）、**[[Hybrid-Cloud]]**（混合云：公私组合架构、三种典型用例、优缺点矩阵、决策树）、**[[Shared-Responsibility-Model]]**（共享责任模型：IaaS/PaaS/SaaS三层责任矩阵、客户始终负责五大领域） +- Entities created: **[[BMC]]**（企业IT管理解决方案提供商，BMC Helix / Control-M 核心产品） +- Source page: wiki/sources/public-vs-private-vs-hybrid-cloud-differences-explained.md +- Notes: Source page 采用标准 Source Page Format（含 Summary / Key Claims / Key Quotes / Key Concepts / Key Entities / Connections / Contradictions）；冲突检测：本文"公有云安全性最低"与 cloud-computing entity 的 Myth 1 真相存在视角冲突（前者从多租户共享角度，后者从整体云安全投入角度）；与已有 cloud-computing entity（已含三种部署模式）、Cloud-Adoption-Strategy concept（已有四模式对比表）、Multi-Cloud-Strategy concept（含公私混合对比表）形成立体知识网络；更新的 index.md 和 overview.md 补充新概念和实体索引 +- SLUG: public-vs-private-vs-hybrid-cloud-differences-explained +## [2026-04-22] ingest | Ubuntu 24.04 启动 SSH 服务 +- Source file: raw/Home Office/Ubuntu 24.04 enable SSH.md +- Status: ✅ 成功摄入 +- Summary: Ubuntu 24.04 SSH 服务安装与配置完整指南，核心变化是默认使用 ssh.socket 按需激活机制（连接请求来时才启动 sshd），可通过 systemctl 切换回传统 ssh.service 持续运行模式；包含 UFW 防火墙配置和自定义端口修改方法 +- Concepts created: Socket Activation, UFW 防火墙, 开机自启 +- Entities created: Ubuntu 24.04, OpenSSH Server, ssh.socket, ssh.service +- Concepts updated: overview.md（新增 Socket Activation、UFW 防火墙、开机自启 到 Home Server Automation 概念列表） +- Entities updated: overview.md（Home Server Automation 描述补充 Ubuntu 24.04 SSH socket 激活机制说明） +- Source page: wiki/sources/ubuntu-24-04-enable-ssh.md +- Notes: 核心发现是 Ubuntu 24.04 的 ssh.socket 激活机制——systemctl status ssh 显示 inactive 不代表 SSH 不可用，需检查 ssh.socket 监听状态；自定义端口推荐用 systemctl edit ssh.socket 而非直接修改 /etc/ssh/sshd_config；Socket Activation 是 systemd 按需服务模型的典型应用 +- Conflicts detected: 与旧版 Ubuntu SSH 行为冲突（旧版 inactive = 不可用；24.04 inactive + socket active = SSH 正常） +- SLUG: ubuntu-24-04-enable-ssh + +## [2026-04-29] ingest | 如何判别你的Linux服务器是x64还是ARM64 +- Source file: raw/Home Office/如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64.md +- Status: ✅ 成功摄入 +- Summary: Linux 服务器 CPU 架构检测方法，通过 uname -m / lscpu / cat /proc/cpuinfo / file 四种命令快速识别 x86_64（Intel/AMD 64位）、aarch64（ARM 64位）、armv7l（ARM 32位）架构，确保下载安装正确的软件包版本 +- Concepts created: [[CPU架构检测]], [[x86_64]], [[aarch64]], [[ARM64]], [[ELF格式]] +- Entities created: 无 +- Concepts updated: overview.md（Linux Operations Command Reference 部分补充 CPU 架构检测命令说明） +- Entities updated: 无 +- Source page: wiki/sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md +- Notes: 该内容属于 Linux 运维基础知识点，uname -m 是最简洁快速的检测方式；ARM64 架构在云服务商（AWS Graviton、阿里云 ARM 实例）使用越来越普遍；软件包下载时需特别注意架构匹配（.deb 分 amd64/arm64，容器镜像需拉取对应 tag） +- Conflicts detected: 无冲突 +- SLUG: 如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64 + +## [2026-05-01] ingest | Ubuntu 安装 FRP 0.65.0（x86_64）操作笔记 +- Source file: raw/Home Office/Ubuntu 安装 FRP 0.65.0（x86_64）操作笔记.md +- Status: ✅ 成功摄入 +- Summary: 在 Ubuntu Server 24.04（x86_64/amd64）上安装配置 FRP 0.65.0 内网穿透客户端，包含 systemd 服务管理、软链接版本策略、journald 日志配置及完整故障排查指南；与 Mac Mini ARM64 版本形成完整的多平台 FRP 覆盖 +- Concepts created: **[[systemd]]**, **[[Ubuntu Server]]** +- Entities created: **[[Ubuntu Server]]**（Entity 页面） +- Concepts updated: overview.md（Home Server Automation 概念列表新增 systemd、Ubuntu Server；新增 [[systemd]] 概念页面，详细覆盖 Unit Types、Core Commands、Service Template、自动重启机制、Socket Activation、Journald 日志管理、服务依赖等核心内容） +- Entities updated: overview.md（新增 Ubuntu Server 和 systemd 实体描述；frp Entity 已有，本次补充 Ubuntu Server 作为独立实体） +- Source page: wiki/sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md +- Notes: 该源文件是 Ubuntu Server FRP 运维的完整手册；[[systemd]] Concept 页面详细对比了 systemd vs launchd（macOS）、systemd vs init (SysV)、OpenRC、runit 等初始化系统，补充了 ProtectSystem=、ReadOnlyPaths= 等安全最佳实践；[[Ubuntu Server]] Entity 页面记录了 24.04 的关键变化（ssh.socket、Netplan、Snap vs APT）及 Home Server 典型应用场景；该源文件与 [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] 形成互补（Ubuntu=systemd，macOS=launchd），共同完善 FRP 多平台知识体系 +- Conflicts detected: 与 [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] 存在**平台差异**（systemd vs launchd），已在 Source Page Contradictions 部分记录，属于生态差异而非冲突 +- SLUG: ubuntu-安装-frp-0-65-0-x86_64-操作笔记 + +## [2026-05-01] ingest | 家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox +- Source file: raw/Home Office/家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor +Blackbox.md +- Status: ✅ 成功摄入 +- Summary: 家庭/家居服务器（NAS / Ubuntu Server）一站式开源监控方案，通过 Docker Compose 快速部署完整的 Prometheus 监控栈。涵盖主机层/容器层/服务层/日志层的监控覆盖，提供可直接拷贝的 docker-compose.yml、prometheus.yml、alerts.yml、alertmanager.yml 及 8 步落地路径 +- Concepts created: [[PromQL]], [[Prometheus告警规则]], [[Exporter]], [[时序数据库]], [[合成监控]] +- Entities created: [[Prometheus]], [[Grafana]], [[node_exporter]], [[cAdvisor]], [[blackbox_exporter]], [[Alertmanager]], [[Uptime Kuma]], [[Netdata]], [[VictoriaMetrics]] +- Concepts updated: overview.md（Home Server Automation 概念列表新增 PromQL、Prometheus告警规则、Grafana、node_exporter、cAdvisor、blackbox_exporter、Alertmanager、Uptime Kuma、Netdata、VictoriaMetrics、合成监控、Exporter、时序数据库） +- Entities updated: overview.md（新增 Prometheus、Grafana、node_exporter、cAdvisor、blackbox_exporter、Alertmanager、Uptime Kuma、Netdata、VictoriaMetrics、Portainer 实体描述）；system-monitoring.md 新增 [[Prometheus]] 和 [[Grafana]] 引用 +- Source page: wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md +- Notes: 该源文件是 Home Server Automation 监控领域的核心来源；[[Prometheus]] Entity 页面详细覆盖了 Pull 模式、PromQL、告警规则、Remote Write、和服务发现机制；[[Grafana]] Entity 页面记录了 Dashboard ID 快速导入（1860/14282/7587）和多数据源支持；[[PromQL]] Concept 页面提供家庭服务器监控常用 PromQL 表达式模板；[[Prometheus告警规则]] Concept 页面记录了完整的 alerts.yml 配置示例；[[合成监控]] Concept 页面对比了黑盒与白盒监控，明确 [[blackbox_exporter]] 与 [[Uptime Kuma]] 的互补关系；[[时序数据库]] Concept 页面梳理了 TSDB 核心操作和主流产品对比；[[Exporter]] Concept 页面系统总结了 Prometheus Exporter 生态的设计哲学和官方 exporter 列表；形成完整的家庭监控知识体系（Prometheus Stack） +- Conflicts detected: 与 [[these-6-linux-apps-let-you-monitor-system-resources-in-style]] 中关于 [[Btop++]] 的描述无直接冲突（Netdata vs Btop++ 是实时诊断 vs 交互式管理工具，定位不同）；与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] 在 OpenTelemetry 迁移路径上存在**方向差异**：Prometheus 生态成熟适合家庭服务器，OpenTelemetry 是云原生长期方向；与 [[ctp-topic-42-grafana-observability-dashboard]] 在场景上有**规模差异**：本来源侧重家庭轻量部署，后两者侧重企业级 AWS 场景 +- SLUG: 家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox + +## [2026-05-02] ingest | macOS 创建与解除 Symbolic Link（OpenClaw 目录映射） +- Source file: raw/Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md +- Status: ✅ 成功摄入 +- Summary: macOS 上为 OpenClaw 隐藏目录创建符号链接，使 Finder 和 Obsidian 能够直接访问 `~/.openclaw` 隐藏目录的完整操作记录，含创建/验证/解除流程及推荐的长期目录结构方案 +- Concepts created: [[Symbolic Link]], [[目录映射]] +- Entities created: 无 +- Concepts updated: overview.md（Home Server Automation 概念列表新增 Symbolic Link、软链接策略、目录映射）；新增 [[Symbolic Link]] 通用概念页面（vs Hard Link 对比表、悬空链接风险、ln/symlink 常用命令） +- Entities updated: 无 +- Source page: wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md +- Notes: Symbolic Link 是 Unix/macOS 生态中的基础文件系统特性，本源文件是其实践应用之一；[[Symbolic Link]] Concept 页面覆盖了符号链接与硬链接的完整对比（跨文件系统支持、指向目录、悬空链接风险）；与现有的 [[软链接策略]] Concept 形成互补（通用概念 vs 版本管理场景）；与 [[Obsidian]] 和 [[OpenClaw]] 实体关联，构建完整的目录可见化知识链路 +- Conflicts detected: 无冲突 +- SLUG: macos-创建与解除-symbolic-link-openclaw-目录映射 + diff --git a/wiki/overview.md b/wiki/overview.md index 79213296..f0739500 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -12,12 +12,20 @@ Key concepts: [[Agent Personality]], [[Agent Specialization]], [[Multi-Agent Coo ### Cloud Transformation & DevOps Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Terraform, GitOps, FinOps, observability, security, and enterprise architecture. Key themes: 3 Lines of Defence framework, ITSM, container hardening, backup & DR strategies. DevOps culture focuses on four pillars: Collaboration, Automation (CI/CD, IaC), Continuous Improvement (Kaizen), and Customer-Centricity. Agile practices (Scrum, Kanban) are symbiotic with DevOps. Emerging trends: DevSecOps, GitOps, Serverless DevOps, AI/ML-driven automation, and Edge Computing DevOps. -Key concepts: [[Landing Zone Architecture]], [[GitOps]], [[FinOps]], [[Event Sourcing]], [[Container Lifecycle Hardening]], [[AWS Backup]], [[ITSM]], [[Error Budgets]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[AIOps]], [[SLA]], [[SLO]], [[Incident Management]], [[Change Management]], [[Disaster Recovery]], [[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]] +Key concepts: [[Landing Zone Architecture]], [[GitOps]], [[FinOps]], [[Event Sourcing]], [[Container Lifecycle Hardening]], [[AWS Backup]], [[ITSM]], [[ITSM-2.0]], [[Hyperautomation]], [[AIOps]], [[Self-Healing-Systems]], [[Zero-Trust-Architecture]], [[Policy-as-Code]], [[Immutable-Infrastructure]], [[Error Budgets]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], **[[Serverless Computing]]**, **[[Edge Computing]]**, **[[Green Computing]]**, [[Vendor-Lock-In]], [[Data-Sovereignty]], [[SLA]], [[SLO]], [[Incident Management]], [[Change Management]], **[[Disaster Recovery]]**, [[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]] ### Home Server Automation -Home office setup guides cover Docker deployments, RSSHub, FRP reverse proxy, Synology NAS, network monitoring (Prometheus/Grafana), media servers (Jellyfin, Navidrome), and scientific internet access. +Home office setup guides cover Docker deployments, RSSHub, FRP reverse proxy, Synology NAS, MariaDB/MySQL databases, network monitoring (Prometheus/Grafana), media servers (**Jellyfin**, **Navidrome**, **Transmission**), **it-tools** developer utilities, **CloudDrive2** cloud drive mounting (Aliyun Drive, 115, Quark), **NodeWarden** serverless password manager (Cloudflare Workers + D1 + R2), and scientific internet access. Key configurations include read-only music mounts, transcode caching (200MB limit), MariaDB remote access (socket login, CREATE USER/GRANT), non-root container users, auto-transcode download features, and BT download Web UI authentication. The media workflow follows: Transmission (download) → organize → Jellyfin/Navidrome (play). **CloudDrive2** enables direct NAS access to cloud storage via virtual filesystem mount (Aliyun Drive resource directory only, scan QR code with App authorization). Backup automation is implemented via rsync incremental sync to NAS. SSH server setup on Ubuntu 24.04 introduces **ssh.socket activation** (on-demand startup) as the default; administrators can switch to persistent ssh.service mode. Cross-border AI service registration guides cover using **fingerprint browsers** (**AdsPower**), **high-purity US proxies**, **SMS verification platforms** (**PingMe**), and **virtual credit cards** (**WildCard**) to safely subscribe to **Claude Pro**. -Key concepts: [[Docker-Image]], [[Docker-Save]], [[Docker-Load]], [[RSSHub]], [[内网穿透]], [[Prometheus]] +Key concepts: [[Docker-Image]], [[Docker-Save]], [[Docker-Load]], [[Docker Compose]], [[Docker Engine]], [[Docker 用户组]], [[APT 仓库配置]], [[GPG 密钥验证]], [[it-tools]], [[RSSHub]], [[内网穿透]], [[反向代理]], [[TCP隧道]], [[Caddy]], [[frp]], [[Symbolic Link]], [[软链接策略]], [[目录映射]], [[Prometheus]], [[PromQL]], [[Prometheus告警规则]], [[Grafana]], [[node_exporter]], [[cAdvisor]], [[blackbox_exporter]], [[Alertmanager]], [[Uptime Kuma]], [[Netdata]], [[VictoriaMetrics]], [[合成监控]], [[Exporter]], [[时序数据库]], [[TUI]], [[Process Management]], [[System Monitoring]], [[容器资源限制]], [[容器重启策略]], [[端口映射]], [[媒体服务器]], [[转码缓存]], [[只读挂载]], [[增量备份]], [[永久挂载]], [[挂载点检查]], [[Cron定时任务]], [[进程管理]], [[Socket 登录]], [[用户权限]], [[固件刷入]], [[过渡固件]], [[JFFS双清]], [[策略组分流]], [[故障转移]], [[订阅机制]], [[PUID/PGID]], [[桥接网络]], [[Socket Activation]], [[UFW 防火墙]], [[开机自启]], [[VPN Panel]], [[Xray]], [[BBR]], [[Web Proxy Protocol]], **[[全盘镜像备份]]**, **[[裸机恢复]]**, **[[NFS网络备份]]**, **[[UEFI启动]]**, [[指纹浏览器]], [[IP纯净度]], [[虚拟信用卡]], [[接码平台]], [[账号隔离]], **[[云盘挂载]]**, **[[NAS套件管理]]**, [[Root权限修复]], [[SPK套件格式]], [[launchd]], [[Gatekeeper]], [[软链接策略]], **[[systemd]]**, **[[Ubuntu Server]]** + +### Linux System Monitoring +Six Linux resource monitoring tools reviewed: TUI tools (Btop++, Htop, Glances, Bottom) for SSH-friendly server management; GUI tools (Mission Center, Stacer) for desktop use. Author's top pick: Btop++ for its balance of usability and aesthetics. [[Btop++]], [[Htop]], [[Glances]], [[Bottom]], [[Mission Center]], [[Stacer]], [[TUI]], [[TOTP]], [[Passkey]], [[Self-Hosted Password Manager]] + +### Linux Operations Command Reference +A comprehensive Linux command reference covering 150 essential commands across 16 categories: help commands (man, help), file operations (ls, cd, cp, find, mkdir, mv, rm, touch, tree), text processing (cat, grep, sort, uniq, wc, diff, vim), compression (tar, gzip, zip, unzip), system info (uname, dmesg, uptime, du, df, top, free), search (which, locate), user management (useradd, sudo, visudo), networking (ssh, scp, wget, ping, ifconfig, netstat, ss, nmap, tcpdump), disk/filesystem (mount, fdisk, mkfs, mkswap, sync), permissions (chmod, chown, chgrp, umask), process management (kill, crontab, ps, nohup), and system shutdown/restart (shutdown, halt, poweroff). Key insight: Linux treats everything as a file (CPU, memory, disks, keyboard, users). **CPU architecture detection**: `uname -m` (x86_64/aarch64/armv7l), `lscpu` (Architecture field), `cat /proc/cpuinfo` (model name/AArch64), `file /bin/bash` (ELF metadata). + +Key concepts: [[CPU架构检测]], [[x86_64]], [[aarch64]], [[ARM64]], [[ELF格式]] ### AI Tools & Prompt Engineering Covers Claude Code, OpenCode, Cursor, Gemini CLI, Vibe Coding, RAG, multi-agent workflows, NotebookLM, Nano Banana prompting, and video generation tools. @@ -48,9 +56,85 @@ Key concepts: [[Obsidian Tasks]], [[Dataview]], [[Event Sourcing]], [[Second Bra - [[n8n]] — workflow automation - [[Quartz]] — static site generator for wikis - [[RSSHub]] — open-source RSS aggregator -- [[Synology NAS]] — network-attached storage +- [[群晖 NAS]]（Synology NAS）— 网络附加存储，Navidrome/Jellyfin/Transmission 音乐/视频/BT文件的宿主机，MariaDB 数据库的部署平台，CloudDrive2 云盘挂载的硬件平台 +- [[Docker卷]] — Docker 容器持久化数据存储，默认路径 /var/lib/docker/volumes，是 TikTok 业务数据备份的核心对象 +- [[it-tools]] — 开源开发者工具集合 Web UI（corentinth/it-tools），提供 100+ 实用工具如 URL 编解码、UUID 生成、Cron 解析、哈希计算等，通过 Docker Compose 部署，端口 8999，内存限制 128MB +- [[Navidrome]] — 开源音乐流媒体服务器，Subsonic API 兼容，支持网页端与移动客户端 +- [[Transmission]] — 开源 BT 下载客户端，Home Server 媒体中心核心组件，负责下载环节，与 Jellyfin/Navidrome 构成"下载→播放"工作流 +- [[LinuxServer.io]] — 开源 Docker 镜像维护组织，为 Transmission/Jellyfin/Navidrome 等自托管应用提供标准化 Docker 镜像 +- [[MariaDB]] — 开源关系型数据库，Synology NAS Docker 环境部署，支持内网（192.168.3.17:3307）和公网（mysql.ishenwei.online:63307）双通道访问 - [[Claude Code]] — Anthropic CLI agent - [[OpenCode]] — Vibe Coding CLI agent +- [[ISO-27001]] — 国际信息安全管理体系标准（云安全合规基础） +- [[HIPAA]] — 美国医疗健康信息隐私法规 +- [[GDPR]] — 欧盟通用数据保护条例 +- [[Raj-Vardhan-Singh]] — LinkedIn 云计算文章作者 +- [[Agentic AI]] — 自主决策和任务执行能力的AI系统 +- [[Kubernetes]] — 容器编排平台（EKS/GKE/AKS） +- [[Terraform]] — IaC 基础设施即代码工具 +- [[LaunchDarkly]] — Feature Flag 管理平台（HP、Christian Dior RTO 优化案例） +- [[Veeam]] — 传统灾备工具（数据库备份、服务器镜像） +- [[Acronis]] — 传统灾备工具（跨区域复制） +- [[Docker]] — 容器化平台，所有监控组件（Prometheus / Grafana / node_exporter / cAdvisor / blackbox_exporter）的部署底座，通过 Docker Compose 实现一键启动 +- [[Prometheus]] — CNCF 毕业项目，开源时序数据库和监控告警系统，pull 模式采集 exporters 指标，支持 PromQL 查询和告警规则引擎，是家庭监控方案的核心数据引擎 +- [[Grafana]] — 开源可视化平台，支持多数据源（Prometheus / Loki / VictoriaMetrics）仪表盘和告警管理，家庭方案中通过 Dashboard ID（1860/14282/7587）快速导入官方模板 +- [[node_exporter]] — Prometheus 官方主机指标采集器，以 host network 模式运行，采集 CPU / 内存 / 磁盘 / 网络 / I/O 等系统指标 +- [[cAdvisor]] — Google 开源容器资源监控工具，挂载 Docker socket 采集容器级别资源指标，为 Prometheus 提供容器层可观测性 +- [[blackbox_exporter]] — Prometheus 官方黑盒探测 exporter，通过 HTTP/TCP/ICMP/DNS/TLS 探测实现服务可用性和证书到期监控 +- [[Alertmanager]] — Prometheus 告警分发组件，支持告警分组、抑制、静默及邮件/Slack/Teams/Webhook 多通道路由 +- [[Uptime Kuma]]（louislam/uptime-kuma）— 自托管 uptime monitoring 工具，支持 HTTP/TCP/DNS/TLS 合成监控，适合外网/内网可用性探测 +- [[Netdata]] — 开箱即用的实时主机/容器监控面板，默认端口 19999，适合快速诊断，与 Prometheus 可互补使用 +- [[VictoriaMetrics]] — Prometheus 时序数据库替代方案，支持长期存储和高效写入，适合大规模数据保留场景 +- [[Portainer]] — Docker 可视化管理工具，不替代 Prometheus 但便于运维快速操作容器 +- **[[BMC]]** — 企业IT管理解决方案提供商（BMC Helix / Control-M） +- **[[AWS]]** — Amazon Web Services +- **[[Azure]]** — Microsoft Azure +- **[[Google-Cloud]]** — Google Cloud Platform +- [[Btop++]] — TUI系统监控器，作者首选 +- [[Htop]] — 轻量级TUI进程监控器 +- [[Glances]] — 超轻量TUI监控器 +- [[Bottom]] — TUI实时图表监控器 +- [[Mission Center]] — 类Windows任务管理器的GUI应用 +- [[Stacer]] — 功能最全的GUI监控+维护工具 +- [[网件RAX50]] — NETGEAR WiFi 6路由器，支持刷入梅林固件 +- [[梅林固件]] — 华硕路由器第三方固件改良版，支持软件中心插件 +- [[MerlinClash插件]] — 基于Clash核心的梅林固件科学上网插件，支持策略组分流 +- [[机场]] — 提供代理节点订阅服务的服务商 +- [[3X-UI]] — Xray 可视化管理面板（mhsanaei/3x-ui），提供 Web UI 管理 25 项运维操作（启停、更新、SSL证书、Geo更新、BBR等），支持 VLESS+Reality 入站配置生成 +- [[Xray]] — 新一代代理核心，支持 VLESS/VMess/Trojan/SS 等多协议，内置 Reality 流量伪装方案，是 3X-UI 的底层引擎 +- [[frp]] — 开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）两个组件，通过反向隧道使内网服务可被公网访问，支持 TCP/UDP/HTTP 等多种协议 +- [[Ubuntu Server]] — Ubuntu Server 是 Canonical 维护的 Linux 服务器操作系统，默认使用 systemd 作为初始化系统，Ubuntu Server 24.04 LTS 是当前长期支持版本 +- [[systemd]] — Linux 系统和服务管理器，Ubuntu Server 的默认初始化系统，通过 unit 文件（service/timer/socket）和 systemctl 命令管理服务生命周期，支持开机自启（enable）、自动重启（Restart=on-failure）、日志收集（journald）等生产级特性 +- [[Mac Mini M4]] — Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端、N8n、OpenClaw 等服务，支持 ARM64 架构 +- [[Caddy]] — Go 语言编写的自动 HTTPS 反向代理服务器，默认启用 Let's Encrypt 证书，与 frp 配合提供内网服务的 HTTPS 访问 +- [[VPS]] — 公网虚拟专用服务器，本方案中托管 frps 和 Caddy，作为内网穿透的公网中转站（IP: 192.227.222.142） +- [[阿里云 DNS]] — 域名 ishenwei.online 的 DNS 解析服务，通过 A 记录将子域名指向 VPS 公网 IP +- [[Bandwagon VPS]] — 低总价 OpenVZ/KVM VPS 提供商，资料中 VPS2（104.194.92.188）托管了 3X-UI + Xray 服务 +- **[[CloudDrive2]]** — 云盘挂载工具，支持阿里云盘/Google Drive/OneDrive 等，通过虚拟文件系统将云端存储挂载为本地目录，Web UI 端口 19798 +- **[[矿神源]]** — Synology 社群第三方套件源（SPK 格式），提供 CloudDrive2 等官方未收录应用 +- **[[阿里云盘]]** — 阿里巴巴云盘服务，CloudDrive2 的主要挂载目标 +- [[AdsPower]] — 指纹浏览器产品，支持浏览器指纹隔离，免费版提供5个环境，是跨境服务注册的推荐工具 +- [[PingMe]] — 短信接码平台，支持美国区号码接收验证码，需下载App，最低充值2美元 +- [[WildCard]] — 虚拟信用卡服务，支持支付宝充值，解决国内用户跨境支付难题 +- [[Claude Pro]] — Anthropic Claude AI聊天工具的Pro订阅服务，月费20美元，需海外支付方式 +- [[v2rayN]] — Windows/Linux 代理客户端（支持 VLESS+Reality），配合 Bandwagon VPS 上的 Xray 服务使用 +- [[v2rayNG]] — Android 代理客户端，v2rayN 的移动版，功能一致 +- [[BBR]] — Google TCP 拥塞控制算法，3X-UI 提供一键启用，可提升跨境网络吞吐量 +- [[VPN Panel]] — Web 界面类代理管理工具的统称，3X-UI 属于此类，降低 Xray 服务端运维门槛 +- [[KoolCenter固件服务器]] — 提供梅林固件下载的服务器平台 +- **[[Clonezilla]]** — 开源磁盘镜像工具（再生龙），支持 savedisk/restoredisk 全盘镜像备份到 NAS +- **[[Rufus]]** — 开源 U 盘启动盘制作工具，ISOHybrid 镜像写入模式选择（ISO 模式推荐） +- **[[HP ZBook]]** — HP 工作站笔记本，支持 UEFI/F9 启动菜单，F10 进入 BIOS，作为 Ubuntu 24.04 安装目标机 +- **[[NodeWarden]]** — 将 Bitwarden 服务器端部署到 Cloudflare Workers 的开源实现，运行在边缘计算平台，无需 VPS 和服务器维护，数据存储在 Cloudflare D1 + R2，支持 Bitwarden 官方全平台客户端 +- **[[Cloudflare Workers]]** — Cloudflare 边缘计算平台，基于 V8 隔离的 Serverless 运行时，NodeWarden 的部署环境 +- **[[Cloudflare D1]]** — Cloudflare 边缘 SQLite 数据库，NodeWarden 的主数据存储（保管库/同步数据） +- **[[Cloudflare R2]]** — Cloudflare S3 兼容对象存储，NodeWarden 用于存储密码附件 + +### New Linux/DevOps Concepts (recently added) +- **[[efibootmgr]]** — Linux NVRAM 启动项管理工具，可强制重写 BootOrder 解决 HP BIOS 固执行为 +- **[[ISOHybrid镜像]]** — 同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像，Rufus 提供 ISO/DD 两种写入模式 +- **[[UEFI Only]]** — HP ZBook 终极启动修复方案，切换后消除 Legacy BBS 项干扰 +- **[[NVMe硬盘分区]]** — Ubuntu 24.04 自动识别并优化 NVMe 分区对齐 ## Conflict Areas @@ -61,3 +145,9 @@ Key concepts: [[Obsidian Tasks]], [[Dataview]], [[Event Sourcing]], [[Second Bra 3. **Micro-Enterprise vs Portage Salarial**: Micro-enterprise yields higher net income but lacks social protections; Portage Salarial costs more but includes unemployment insurance, pension, mutuelle. Financial trade-off vs social safety net. 4. **CI/CD Build Output**: SECURITY.md says build output is always closed; GitHub Actions best practice says certain generated files should be committed for reproducibility. Reproducibility vs cleanliness tension. + +5. **路由器科学上网 vs VPS科学上网 vs NAS科学上网**：三层方案各有适用场景。[[网件RAX50刷梅林固件与科学上网]] 路由网关方案（[[MerlinClash插件]]）→ 全屋透明代理，无需客户端配置；[[3X-UI Xray on BandwagonVPS]] VPS服务端方案（[[3X-UI]] + [[Xray]]）→ 集中式代理节点，可扩展；[[群晖NAS科学上网]] / [[ubuntu-server科学上网]] 终端代理方案 → 仅服务于特定设备。最佳实践：路由器作为主网关（[[MerlinClash插件]]），VPS作为代理节点池（订阅机制），NAS/服务器按需单独配置。 + +6. **Prometheus 监控 vs OpenTelemetry**：Prometheus 生态成熟、部署简单，适合家庭服务器和小型集群；OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），长期可考虑迁移路径但学习成本高。[[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] vs [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]。 + +7. **Netdata vs Prometheus**：Netdata 开箱即用适合实时短期诊断（默认 19999 端口），Prometheus + Grafana 适合长期存储和趋势分析。两者可互补使用：Netdata 做快速排查，Prometheus 做 SLA 报表和历史分析。 diff --git a/wiki/sources/3x-ui-xray-on-bandwagonvps.md b/wiki/sources/3x-ui-xray-on-bandwagonvps.md new file mode 100644 index 00000000..0775ad8d --- /dev/null +++ b/wiki/sources/3x-ui-xray-on-bandwagonvps.md @@ -0,0 +1,60 @@ +--- +title: "3X-UI Xray on BandwagonVPS" +type: source +tags: [vps, xray, 3x-ui, 科学上网, vless, reality] +date: 2026-02-10 +--- + +## Source File +- [[raw/Home Office/3X-UI Xray on BandwagonVPS.md]] + +## Summary (中文描述) +- **核心主题**：在 Bandwagon VPS 上通过 3X-UI 可视化面板部署 Xray 代理服务（VLESS+Reality 协议） +- **问题域**：个人科学上网基础设施的搭建与维护 +- **方法/机制**： + - 使用 mhsanaei/3x-ui 一键安装脚本部署 Web 管理面板 + - 通过面板生成 VLESS+Reality 协议的入站配置 + - 客户端使用 v2rayN（Windows/Linux）和 v2rayNG（Android）连接 + - 启用 BBR 拥塞控制算法优化网络性能 +- **结论/价值**：3X-UI 提供了一条龙的可视化运维路径，降低了 Xray 服务端配置门槛，国内/国外双向访问均可达 200 OK + +## Key Claims (中文描述) +- 用户通过 3X-UI 面板在 Bandwagon VPS（104.194.92.188）上成功部署了 Xray 代理服务 +- VLESS+Reality 协议要求服务端生成公钥私钥对，客户端使用公钥连接 +- 3X-UI 面板支持 SSL 证书管理、云flare证书更新、Geo 文件更新、BBR 启用等 25 项运维操作 +- Panel 状态和 xray 状态均显示 Running，自动启动（Autostart）已启用 +- 国内访问和国外访问直连测试均返回 200，网络连通性验证通过 + +## Key Quotes +> "bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)" — 一行命令完成 3X-UI 的安装与初始配置 +> "使用 VLESS+Reality 方式配置，需要产生公钥和私钥" — Reality 协议的核心机制，需要非对称加密密钥对 + +## Key Concepts +- [[VPN Panel]]：Web 界面管理代理服务的统称，3X-UI 属于此类，提供启停、重启、日志、证书等可视化运维功能 +- [[Xray]]：新一代代理核心，支持 VLESS、VMess、Trojan、Shadowsocks 等多种协议，Reality 是其内置的流量伪装方案 +- [[VLESS+Reality]]：无状态的代理协议组合，VLESS 为传输层协议，Reality 负责 TLS 流量伪装，特征是服务端不需要保存用户状态，适合多用户场景 +- [[Web Proxy Protocol]]：代理协议家族，常见有 SOCKS5、HTTP，以及 VLESS/Trojan/VMess 等专有方案 +- [[BBR]]：Google 开发的 TCP 拥塞控制算法，可显著提升跨境网络吞吐量，3X-UI 内置一键启用功能 + +## Key Entities +- [[Bandwagon VPS]]：低总价 OpenVZ/KVM VPS 提供商，常用于个人科学上网场景，资料中涉及的 VPS 名称为 VPS2 +- [[3X-UI]]：mhsanaei/3x-ui 项目提供的 Xray 可视化管理面板，支持安装、更新、SSL、BBR 等 25 项操作 +- [[v2rayN]]：Windows/Linux 平台的代理客户端，支持 VLESS、VMess、Trojan 等多种协议，是本文档推荐的桌面端连接工具 +- [[v2rayNG]]：Android 平台的代理客户端，v2rayN 的移动版，支持同样的协议集 +- [[Xray-Project]]：VLESS 协议的主要维护方，也是 Reality 伪装方案的提出者 + +## Connections +- [[Bandwagon VPS]] ← 托管了 ← [[3X-UI]] +- [[3X-UI]] ← 运行了 ← [[Xray]] +- [[Xray]] ← 配置了 ← [[VLESS+Reality]] +- [[v2rayN]] ← 客户端连接到 ← [[Xray]] +- [[v2rayNG]] ← 移动客户端连接到 ← [[Xray]] +- [[Home Server Automation]] ← 包含 ← [[科学上网基础设施]] +- [[ubuntu-server科学上网]] ← 相关方案 ← [[3X-UI Xray on BandwagonVPS]]（均属于科学上网领域） + +## Contradictions +- 与 [[网件RAX50刷梅林固件与科学上网]] 冲突： + - **冲突点**：科学上网的实现层级不同 + - **当前观点**（本文）：在 VPS 层面部署 Xray 代理，属于服务端集中式方案 + - **对方观点**：在路由器固件层面（MerlinClash）实现分流，属于网关透明代理方案 + - **协调**：两者可以互补——路由器处理全屋流量，VPS 提供代理节点，通过订阅机制联动 diff --git a/wiki/sources/clonezilla对ubuntu-server进行全盘镜像备份.md b/wiki/sources/clonezilla对ubuntu-server进行全盘镜像备份.md new file mode 100644 index 00000000..07fdcd4a --- /dev/null +++ b/wiki/sources/clonezilla对ubuntu-server进行全盘镜像备份.md @@ -0,0 +1,66 @@ +--- +title: "Clonezilla对Ubuntu Server进行全盘镜像备份" +type: source +tags: [backup, clonezilla, nas, rufus, ubuntu] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份.md]] + +## Summary (用中文描述) +- **核心主题**：使用 Clonezilla 对 Ubuntu Server 进行全盘镜像备份到 NAS 的完整操作流程 +- **问题域**：系统灾难恢复、数据备份、裸机还原 +- **方法/机制**： + - 使用 Rufus 将 Clonezilla ISO 写入 U 盘制作启动盘（支持 GPT/UEFI 和 MBR/BIOS 两种分区方案） + - 通过 NFS 网络挂载将镜像存储到 NAS + - Clonezilla device-image 模式将磁盘备份为镜像文件 + - Beginner 模式简化配置（savedisk/savedisk） +- **结论/价值**：实现类似 Ghost 的全盘镜像功能，支持完整的系统灾难恢复 + +## Key Claims (用中文描述) +- Rufus 必须选择"以 ISO 镜像模式写入"（推荐），若无法启动再尝试 DD 模式 +- 较新笔记本选 GPT + UEFI (非 CSM)；老旧笔记本选 MBR + BIOS (或 UEFI-CSM) +- 推荐使用 NFS Server 连接 NAS（Linux 兼容性最好） +- Beginner 模式默认参数已足够，无需高级配置 +- savedisk 备份整个磁盘；restoredisk 从镜像还原到磁盘，可实现系统即时复活 + +## Key Quotes +> "Clonezilla (再生龙)" — 类 Ghost 的开源全盘镜像工具 + +> "以 ISO 镜像模式写入 (推荐)" — Rufus 写入 ISOHybrid 镜像的正确方式 + +> "Beginner 模式，默认参数已足够" — 初学者推荐使用简化配置 + +> "备份完后，它会覆盖新硬盘的所有数据，完成后系统即刻复活" — 灾难恢复效果 + +## Key Concepts +- [[全盘镜像备份]]：将整个磁盘/分区复制为镜像文件，支持完整还原 +- [[NFS网络备份]]：通过网络文件系统将备份镜像存储到远程NAS，支持跨设备备份 +- [[裸机恢复]]：磁盘损坏后从镜像文件还原整个系统，无需重新安装配置 +- [[UEFI启动]]：现代BIOS标准，使用GPT分区表；与传统MBR/BIOS的区别在于启动流程和分区限制 +- [[ISOHybrid镜像]]：同时支持ISO和DD两种写入模式的混合镜像，需正确选择写入模式 + +## Key Entities +- [[Clonezilla]]：开源磁盘镜像/克隆工具（再生龙），类 Ghost 功能，支持 device-image 模式备份到 NAS +- [[Rufus]]：开源 U 盘启动盘制作工具，支持 ISOHybrid 镜像写入模式选择 +- [[Ubuntu Server]]：目标备份系统，基于 Linux 的服务器操作系统 +- [[HP ZBook]]：源笔记本（F9 进入启动菜单） +- [[NFS]]：Network File System，网络文件系统备份存储协议 +- [[Synology NAS]]：备份存储目标设备（NAS 网络存储） +- [[GPT分区表]]：UEFI 启动使用的现代分区方案（相比 MBR 的区别：支持 >2TB 磁盘、无限分区数） +- [[MBR分区表]]：传统 BIOS 启动使用的分区方案（限制 2TB 磁盘、4 个主分区） + +## Connections +- [[NFS网络备份]] ← uses ← [[Clonezilla]] +- [[全盘镜像备份]] ← implements ← [[裸机恢复]] +- [[Ubuntu Server]] ← backed_up_by ← [[Clonezilla]] +- [[Rufus]] ← creates ← [[UEFI启动]] + [[MBR分区表]] (启动盘) +- [[Synology NAS]] ← stores ← [[NFS网络备份]] (镜像存储目标) + +## Related Sources +- [[ubuntu服务器通过rsync实现日常增量备份]] — rsync 增量备份方案（文件级 vs 镜像级互补） +- [[Disaster Recovery]] — 灾备策略（[[RTO]]/[[RPO]] 概念） + +## Contradictions +- 无冲突发现 diff --git a/wiki/sources/cloud-operating-model-key-strategies-and-best-practices.md b/wiki/sources/cloud-operating-model-key-strategies-and-best-practices.md new file mode 100644 index 00000000..c0a8fa4c --- /dev/null +++ b/wiki/sources/cloud-operating-model-key-strategies-and-best-practices.md @@ -0,0 +1,85 @@ +--- +title: "Cloud Operating Model: Key Strategies and Best Practices" +type: source +tags: [Cloud, DevOps, Cloud Strategy, Cloud Governance] +date: 2025-03-01 +--- + +## Source File +- [[raw/Cloud & DevOps/Cloud Operating Model Key Strategies and Best Practices.md]] + +## Summary (中文) +- **核心主题**：云运营模型（Cloud Operating Model, COM）是现代云战略的基础框架，涵盖治理、安全、成本优化和运营敏捷性四大支柱 +- **问题域**：企业在云迁移过程中面临成本失控、安全漏洞、运维混乱等挑战；89%的组织预计到2025年将采用云优先架构，但缺乏结构化方法 +- **方法/机制**： + - 四大核心支柱：治理与合规、自动化、安全、成本管理 + - 六步设计流程：评估成熟度 → 建立治理框架 → 自动化运营 → 实施成本管理 → 强化安全 → 持续监控与AI优化 + - FinOps策略：Reserved/Spot实例、自动扩缩、实时监控 + - Zero Trust安全模型：无隐式信任、持续验证 +- **结论/价值**：结构化的COM帮助企业实现治理标准化、成本优化、安全增强和运营敏捷；多云策略避免供应商锁定；AI驱动的自动化是未来趋势 + +## Key Claims (中文) +- 89%的组织预计到2025年将采用云优先架构以提升可扩展性、敏捷性和成本效率 +- 59%的企业在云成本管理方面遇到困难，8%的组织关注可持续性和碳足迹 +- 采用Cloud Operating Model的企业可实现：标准化治理、成本优化、安全增强、运营敏捷、多云灵活性 +- FinOps策略通过Reserved实例和Spot实例可降低40-70%的计算成本 +- 实施Zero Trust安全策略和自动化安全补丁可将安全事件减少60% +- AI驱动的异常检测可将停机时间减少45% +- 多云部署可将停机风险降低40% + +## Key Quotes +> "A Cloud Operating Model (COM) is a framework that standardizes how organizations manage cloud resources, security, automation, and costs across cloud environments." — Bacancy Technology + +> "Without proper governance, Cloud environments can spiral out of control quickly." — Bacancy Technology + +> "Security in the Cloud is no longer about physical perimeters and firewalls but about identity-based security, encryption, and continuous monitoring." — Bacancy Technology + +> "AI can predict resource usage, automatically adjusting workloads to avoid overprovisioning and reduce cloud costs." — Bacancy Technology + +## Key Concepts +- [[Cloud Operating Model]]：标准化组织管理云资源、安全、自动化和成本的框架 +- [[FinOps]]：云财务运营，通过成本监控、优化策略和预算控制管理云支出 +- [[Zero-Trust-Security]]：零信任安全模型，无隐式信任，持续验证所有访问请求 +- [[Multi-Cloud Strategy]]：多云策略，避免单一供应商锁定，提升韧性和灵活性 +- [[Infrastructure as Code]]：基础设施即代码，通过Terraform等工具实现自动化部署 +- [[Cloud Governance]]：云治理，建立政策和合规框架确保云环境有序运营 +- [[AIOps]]：AI驱动的IT运维，利用机器学习进行异常检测和性能优化 +- [[Cloud Cost Optimization]]：云成本优化，通过各种策略减少不必要的云支出 +- [[Serverless Computing]]：无服务器计算，Eliminate不必要资源消耗 +- [[Green Computing]]：绿色计算，降低数据中心能耗和碳足迹 + +## Key Entities +- [[AWS]]：Amazon Web Services，提供IAM、Cost Explorer、GuardDuty等云服务 +- [[Azure]]：Microsoft Azure，提供Azure AD、Cost Management、Defender等云服务 +- [[Google-Cloud]]：Google Cloud Platform，提供Google IAM、Security Command Center等云服务 +- [[Terraform]]：HashiCorp的IaC工具，支持多云基础设施自动化 +- [[Kubernetes]]：容器编排平台，支持跨云工作负载管理 + +## Connections +- [[Cloud Operating Model]] ← 构建于 ← [[Cloud Governance]] +- [[FinOps]] ← 依赖 ← [[Cloud Cost Optimization]] +- [[Zero-Trust-Security]] ← 包含于 ← [[Cloud Operating Model]] +- [[Multi-Cloud Strategy]] ← 解决 ← [[Vendor-Lock-In]] +- [[AIOps]] ← 增强 ← [[Cloud Operating Model]] +- [[Infrastructure as Code]] ← 实现 ← [[Cloud Governance]] + +## Industry Use Cases +- **金融服务**：合规自动化、FinOps成本治理、Zero Trust安全模型 +- **医疗健康**：HIPAA/HITRUST合规自动化、数据加密与访问控制、AI诊断 +- **零售电商**：自动扩缩应对流量高峰、多云避免供应商锁定 +- **SaaS科技**：CI/CD流水线加速部署、容器化架构提升伸缩性 + +## Challenges & Solutions +1. **Vendor Lock-In** → 多云策略 + Docker/Kubernetes容器化 + Terraform +2. **Cost Overruns** → FinOps + Reserved/Spot实例 + 自动关停策略 +3. **Compliance Risks** → Policy-as-Code + AWS Config/Azure Policy + RBAC +4. **Skills Gap** → 自动化工具 + 团队培训 + +## Future Trends +- AI & ML驱动的云运营（预测性分析、自愈环境） +- 云可持续性与绿色计算 +- 多云与混合云策略：无供应商锁定的云治理 + +## Contradictions +- 与传统本地IT对比：云运营需要全新的安全、自动化和成本管理策略，而非简单迁移 +- 初期投入vs长期收益：云运营模型需要前期治理框架投入，但长期可显著降低运营成本 diff --git a/wiki/sources/how-agentic-ai-can-help-for-cloud-devops.md b/wiki/sources/how-agentic-ai-can-help-for-cloud-devops.md new file mode 100644 index 00000000..0ef0f786 --- /dev/null +++ b/wiki/sources/how-agentic-ai-can-help-for-cloud-devops.md @@ -0,0 +1,136 @@ +--- +title: "How Agentic AI can help for Cloud DevOps" +type: source +tags: [Cloud, DevOps, AI, Agentic] +date: 2026-04-14 +--- + +## Source File +- [[raw/Cloud & DevOps/How Agentic AI can help for Cloud DevOps.md]] + +## Summary (中文描述) +### 核心主题 +Agentic AI（具备自主决策和任务执行能力的AI系统）如何通过自动化复杂工作流、提升效率和保障云环境可靠性来增强 Cloud DevOps。 + +### 问题域 +- 事故响应速度慢（MTTR高） +- 云成本持续攀升（资源过度配置） +- 安全合规持续监控困难 +- 多云环境管理复杂度高 +- 人工运维负担重 + +### 方法/机制 +七大能力领域： +1. **自主事故检测与解决** — Self-Healing + AI-driven RCA + Predictive Maintenance +2. **自动化云部署与配置** — AI Release Manager + IaC 智能审查 + 动态配置管理 +3. **智能成本优化** — AI Rightsizing + Spot Instance 优化 + 多云成本治理 +4. **AI驱动的安全与合规** — 自动安全审计 + 动态威胁缓解 + 合规实时执行 +5. **智能日志分析与可观测性** — AI日志分析 + 自动RCA + ChatOps +6. **增强的多租户SaaS管理** — 动态租户配置 + 自动退租 + 多租户成本优化 +7. **AI增强的决策支持** — AI Runbooks + What-If模拟 + AI异常检测 + +### 结论/价值 +Agentic AI 通过集成 AI 驱动的自动化，使企业能够实现更快的部署、更主动的问题解决、更低的成本和更强的安全合规——且无需增加 DevOps 工作负载。 + +--- + +## Key Claims (中文描述) +- Agentic AI 通过**自动检测异常并应用修复**（重启Pod、扩缩容、清理磁盘），实现**更快的 MTTR 和 SLA 合规** → Self-Healing Systems +- Agentic AI 通过**分析云监控日志关联跨层问题**，实现**AI驱动的根因分析**，比人工更快定位问题根因 → Root Cause Analysis (RCA) +- Agentic AI 通过**持续学习历史故障模式并主动建议补丁**，实现**预测性维护**，减少非计划停机 → Predictive Maintenance +- Agentic AI 作为 Release Manager 通过**自动执行蓝绿部署和金丝雀策略**，结合**自动回滚**，实现**更可靠的 CI/CD** → Deployment Automation +- Agentic AI 通过**持续分析使用趋势并动态调整资源**，实现**40%成本降低**（如夜间切换 Spot 实例） → Rightsizing +- Agentic AI 通过**扫描 IAM 策略和容器漏洞并自动修复**，实现**持续安全态势管理和实时合规执行** → Automated Security Audit +- Agentic AI 通过**跨云识别浪费支出并建议资源整合**，实现**多云成本治理** → Multi-Cloud Cost Optimization +- Agentic AI 通过**自动分析日志并关联外部API故障**，实现**智能故障排查和重试策略建议** → AI ChatOps +- Agentic AI 通过**动态配置租户资源分配**，实现**SaaS 多租户自动化供给** → Multi-Tenant SaaS +- Agentic AI 通过**What-If模拟云迁移对性能/成本/合规的影响**，实现**迁移前的数据驱动决策** → What-If Simulation + +--- + +## Key Quotes + +> "Agentic AI transforms Cloud DevOps by automating incident response, cost management, security, observability, and multi-cloud governance." — 结论总结 + +> "An AI agent monitoring AWS EKS clusters detects high CPU usage due to a rogue pod. It automatically throttles the pod, scales resources, or suggests a pod restart." — Self-Healing 示例 + +> "An AI agent detects that a workload in AWS **should be shifted to spot instances at night**, reducing cloud costs by 40%." — 成本优化示例 + +> "An AI agent simulates how moving an AWS-based SaaS application to **GCP's Private Cloud in KSA** will impact performance, cost, and compliance." — What-If Simulation 示例 + +--- + +## Key Concepts + +- [[Agentic AI]]：具有自主决策和任务执行能力的AI系统，能够感知环境、规划行动、执行任务并从反馈中学习 +- [[Self-Healing Systems]]：通过自动检测异常并应用修复（重启、扩缩容、清理资源）实现系统自主恢复的能力 +- [[Root Cause Analysis (RCA)]]：通过AI分析日志跨层关联，快速定位问题根本原因，而非仅处理表象 +- [[Predictive Maintenance]]：基于历史故障模式学习，主动建议补丁或变更以预防非计划停机 +- [[Deployment Automation]]：AI代理作为Release Manager，自动执行部署策略（蓝绿/金丝雀）和回滚决策 +- [[Rightsizing]]：AI持续分析资源使用趋势，动态调整云资源配置以消除过度配置 +- [[Automated Security Audit]]：AI自动扫描IAM策略、网络规则和容器漏洞，并自动修复问题 +- [[Multi-Cloud Cost Optimization]]：AI跨多云识别浪费支出，建议资源整合或替代定价模式 +- [[AI ChatOps]]：通过自然语言接口（Slack/Teams/CLI）进行故障排查，AI提供日志分析和解决方案建议 +- [[Multi-Tenant SaaS]]：AI动态管理多租户资源分配、供给、退租和成本分摊 +- [[What-If Simulation]]：AI模拟架构变更（如云迁移）对性能、成本和合规的影响，支持数据驱动决策 +- [[AIOps]]（已有）— 本文档扩展了 AIOps 的具体实现场景 + +--- + +## Key Entities + +- [[Kubernetes]]（EKS/GKE/AKS）：云原生容器编排平台，是 Agentic AI 自主修复的主要目标环境 +- [[Terraform]]：IaC 工具，AI 代理审查和改进 Terraform 脚本以确保基础设施配置正确 +- [[CloudWatch]]（AWS）/ Stackdriver（GCP）/ Azure Monitor：云监控平台，AI 分析其日志进行 RCA 和异常检测 +- [[IAM]]（Identity and Access Management）：云安全核心，AI 自动审计 IAM 策略以防止过度权限 +- [[Spot Instances]]（AWS）/ Preemptible（GCP）/ Savings Plan（Azure）：低成本云实例，AI 动态调度工作负载以优化成本 + +--- + +## Connections + +- [[Agentic AI]] ← 应用场景 ← [[Cloud DevOps]] +- [[Agentic AI]] ← 核心能力 ← [[Self-Healing Systems]] +- [[Agentic AI]] ← 核心能力 ← [[Root Cause Analysis (RCA)]] +- [[Agentic AI]] ← 核心能力 ← [[Predictive Maintenance]] +- [[Agentic AI]] ← 核心能力 ← [[Deployment Automation]] +- [[Agentic AI]] ← 核心能力 ← [[Rightsizing]] +- [[Agentic AI]] ← 核心能力 ← [[Automated Security Audit]] +- [[Agentic AI]] ← 核心能力 ← [[AI ChatOps]] +- [[Agentic AI]] ← 核心能力 ← [[What-If Simulation]] +- [[Kubernetes]] ← 修复目标 ← [[Self-Healing Systems]] +- [[Terraform]] ← 审查对象 ← [[Infrastructure-as-Code]] +- [[CloudWatch]] ← 数据源 ← [[AIOps]] +- [[IAM]] ← 审计对象 ← [[Automated Security Audit]] +- [[Multi-Cloud Strategy]] ← 依赖 ← [[Multi-Cloud Cost Optimization]] +- [[DORA Metrics]] ← 评估 ← [[Agentic AI]]（通过 MTTR 改善评估效果） +- [[FinOps]] ← 相关领域 ← [[Rightsizing]] + +--- + +## Contradictions + +- **Agentic AI 自动修复 vs 人工审批控制** + - 冲突点：Agentic AI 主张自动修复（自动重启Pod、自动限制权限），而企业安全合规通常要求人工审批 + - 当前观点：对于非关键操作（Pod重启、资源扩缩容），自动修复可显著降低 MTTR + - 对方观点：安全变更应有人工审批链路，SOC 2/ISO 27001 合规要求变更控制记录 + +- **Spot Instance 成本优化 vs SLA 保证** + - 冲突点：AI 建议夜间切换 Spot Instance（40%成本降低），但 Spot Instance 无 SLA 保证 + - 当前观点：对于容错 workloads（批处理、CI/CD、Dev 环境），Spot 是理想选择 + - 对方观点：生产环境关键 workloads 不应依赖无 SLA 的 Spot Instance + +- **AI 自动化 vs DevOps 文化的人本主义** + - 冲突点：过度自动化可能削弱 DevOps 团队的判断力和成长机会 + - 当前观点：AI 处理重复性工作（告警分诊、日志解析），工程师聚焦架构决策 + - 对方观点：自动化不应完全替代工程师的 Ops 判断，保留人工 Review 节点 + +--- + +## Metadata +- **Author**: shenwei +- **Tags**: Cloud, DevOps, AI, Agentic +- **Related Sources**: + - [[what-i-know-about-cloud-service-delivery-1]]（AIOps 相关） + - [[cloud-devop-maturity-guideline]]（DevOps 成熟度相关） + - [[devops-maturity-model-from-traditional-it-to-advanced-devops]]（DevOps 成熟度模型） diff --git a/wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md b/wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md new file mode 100644 index 00000000..800869cf --- /dev/null +++ b/wiki/sources/how-to-simplify-multi-account-deployments-monitoring-centralized-logs-for-aws-cloudformation-stacksets.md @@ -0,0 +1,86 @@ +--- +title: "How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets" +type: source +tags: [AWS, CloudFormation, StackSets, DevOps, Multi-Account, EventBridge, CloudWatch] +date: 2025-10-24 +--- + +## Source File +- [[raw/Cloud & DevOps/How to Simplify Multi-Account Deployments Monitoring Centralized Logs for AWS CloudFormation StackSets.md]] + +## Summary (用中文描述) +- 核心主题：通过 AWS CloudFormation StackSets 实现多账户基础设施部署时，将分散在多个账户的 CloudFormation 日志集中到管理账户进行统一监控。 +- 问题域：企业采用多账户策略后，在50+账户上部署安全基线时，故障排查需要逐个登录账户查看日志，运营开销随组织增长呈指数级增长。 +- 方法/机制：使用 EventBridge Rules 捕获各目标账户的 CloudFormation 事件，通过跨账户权限转发到管理账户的统一 Event Bus，再写入 CloudWatch Log Group，配合 CloudWatch Logs Insights 查询实现单一管理界面的集中监控。 +- 结论/价值：单次部署即可创建中心日志基础设施并自动向所有成员账户推送 EventBridge 规则，确保整个组织的一致配置；使用 CloudWatch Logs Insights 自定义查询实现跨账户故障排查。 + +## Key Claims (用中文描述) +- AWS CloudFormation StackSets 赋能组织跨多个账户和区域部署基础设施，但在多账户场景下监控和追踪分布式部署面临运营挑战。 +- 当跨50个账户部署关键安全基线突然失败时，团队面临艰巨任务：逐个登录账户理解问题所在及影响范围。 +- 该运营开销随组织增长呈指数级增长，要求平台团队花费大量时间在账户间切换并手动关联部署事件。 +- 通过将 CloudFormation 日志集中到管理账户，可实现跨整个组织的单一监控界面。 +- 解决方案通过两次 CloudFormation 部署完成：管理账户基础设施（log-setup-management.yaml）+ StackSet 部署模板（common-resources-stackset.yaml）。 + +## Key Quotes +> "As organizations adopt multi-account strategies for improved security features and governance, AWS CloudFormation StackSets enables organizations to deploy infrastructure across multiple accounts and regions." — 问题背景：多账户策略的采用带来 StackSets 部署监控挑战 + +> "Managing infrastructure across multiple AWS accounts doesn't have to be complex. By centralizing AWS CloudFormation logs, you can gain visibility into your multi-account deployments, troubleshoot issues more efficiently, and help achieve consistent resource deployment across your organization." — 核心价值主张：简化多账户基础设施管理 + +> "This single deployment: 1. Creates the central logging infrastructure in the management account. 2. Automatically deploys Amazon EventBridge rules to all accounts in the specified OU. 3. Sets up the necessary IAM roles and policies for cross-account access." — 一次性部署的三重价值 + +## Key Concepts +- [[Centralized Logging]]：将分散在多个系统/账户的日志汇总到中心位置进行统一管理的模式。该方案将多账户 CloudFormation 事件集中到管理账户的 CloudWatch Log Group。 +- [[Cross-Account Monitoring]]：跨账户监控能力，通过 IAM 跨账户角色和 EventBridge 跨账户事件转发实现。该方案使用 EventBridge Custom Event Bus + 跨账户访问策略。 +- [[Multi-Account Deployment]]：使用 AWS CloudFormation StackSets 跨多个 AWS 账户和区域自动部署和更新基础设施的能力，支持自动部署（新增账户自动纳入）和并行区域容错设置。 +- [[StackSets Deployment Visibility]]：StackSets 部署可观测性，通过 EventBridge 规则捕获 CloudFormation 事件（stack creation, updates, deletions, resource changes）并集中存储查询。 + +## Key Entities +- [[AWS CloudFormation StackSets]]：AWS 原生的跨账户/跨区域基础设施即代码部署服务，该方案的核心编排工具。 +- [[Amazon EventBridge]]：无服务器事件总线服务，用于捕获 CloudFormation 事件并跨账户转发，该方案的事件路由核心组件。 +- [[Amazon CloudWatch Logs]]：云监控日志服务，central-cloudformation-logs Log Group 存储所有账户的 CloudFormation 事件，支持 Logs Insights 自定义查询。 +- [[AWS Organizations]]：AWS 多账户组织管理服务，提供管理账户（Management Account）和成员账户（Member Accounts）层级结构，OU（Organizational Unit）用于批量配置 EventBridge 规则。 +- [[AWS KMS]]：Key Management Service，客户托管密钥用于 Log Group 加密。 + +## Connections +- [[AWS CloudFormation StackSets]] ← generates_events ← [[CloudWatch Logs (central-cloudformation-logs)]] +- [[Amazon EventBridge]] ← routes_events ← [[CloudWatch Logs (central-cloudformation-logs)]] +- [[AWS Organizations]] ← provides_account_hierarchy ← [[AWS CloudFormation StackSets]] +- [[AWS Organizations]] ← provides_OU_scope ← [[Amazon EventBridge]] (跨账户规则部署范围) +- [[AWS KMS]] ← encrypts ← [[CloudWatch Logs (central-cloudformation-logs)]] +- [[Centralized Logging]] ← implemented_by ← [[Amazon EventBridge]] + [[CloudWatch Logs]] +- [[Cross-Account Monitoring]] ← enabled_by ← [[AWS Organizations]] Trusted Access + IAM Cross-Account Roles +- [[Multi-Account Deployment]] ← visibility_solution ← [[StackSets Deployment Visibility]] + +## Contradictions +- 无已知冲突 + +## Architecture Summary + +### 四组件架构 +1. **Management Account Setup**：在管理账户创建 Central Event Bus + Log Group + KMS 加密 +2. **Target Account Configuration**：通过 StackSets 自动向所有成员账户部署 EventBridge 规则 +3. **Resource Deployment**：通过 StackSets 部署 S3 等通用资源，触发 CloudFormation 事件 +4. **Monitoring and Visualization**：CloudWatch Logs Insights 查询 + 自定义告警 + +### 事件流 +``` +目标账户 CloudFormation 事件 + → EventBridge Rules (按模式捕获) + → Cross-Account Event Bus (管理账户) + → CloudWatch Log Group (central-cloudformation-logs) + → CloudWatch Logs Insights 查询 +``` + +### CloudWatch Logs Insights 示例查询 +``` +fields @timestamp, account, region +| parse @message /"resource-type":"(?[^"]+)"/ +| parse @message /"status":"(?[^"]+)"/ +| parse @message /"logical-resource-id":"(?[^"]+)"/ +| sort @timestamp desc +``` + +### 成本组件 +- Amazon EventBridge：跨账户事件发布费用 +- Amazon CloudWatch Logs：集中存储 + Logs Insights 查询费用 +- AWS KMS：客户托管密钥费用 diff --git a/wiki/sources/linux-运维必会的-150-个命令.md b/wiki/sources/linux-运维必会的-150-个命令.md new file mode 100644 index 00000000..0c7a89f8 --- /dev/null +++ b/wiki/sources/linux-运维必会的-150-个命令.md @@ -0,0 +1,65 @@ +--- +title: "Linux 运维必会的 150 个命令" +type: source +tags: [linux,运维,命令行] +date: 2025-09-29 +--- + +## Source File +- [[raw/Home Office/Linux 运维必会的 150 个命令.md]] + +## Summary (用中文描述) +- 核心主题：Linux 系统管理命令的全面分类参考，涵盖 150 个运维必备命令 +- 问题域：Linux 系统日常运维中的命令查询与学习 +- 方法/机制：按功能将命令分为 16 大类（帮助、文件操作、文本处理、压缩、信息显示、搜索、用户管理、网络操作、磁盘管理、权限管理、系统监控等） +- 结论/价值：提供系统化的 Linux 命令速查清单，适合运维工程师日常参考和系统化学习 + +## Key Claims (用中文描述) +- Linux 命令是系统运行核心，与 DOS 命令类似，通过文件抽象管理所有资源（CPU、内存、磁盘、键盘、用户等） +- Linux 命令分为两类：内置 Shell 命令和独立 Linux 命令 +- 150 个命令覆盖 Linux 运维的 16 个核心领域 + +## Key Quotes +> "Linux 命令在系统中有两种类型：内置 Shell 命令和 Linux 命令。" — 核心分类原则 +> "对于 Linux 系统来说，无论是中央处理器、内存、磁盘驱动器、键盘、鼠标，还是用户等都是文件" — Linux 一切皆文件哲学 + +## Key Concepts + +### 命令分类体系（16 大类） + +| 类别 | 命令数 | 核心命令 | +|------|--------|----------| +| 线上查询及帮助命令 | 2 | man, help | +| 文件和目录操作命令 | 18 | ls, cd, cp, find, mkdir, mv, pwd, rm, touch, tree, chmod, chown | +| 查看文件及内容处理命令 | 21 | cat, tac, more, less, head, tail, grep, sort, uniq, wc, diff, vi/vim | +| 文件压缩及解压缩命令 | 4 | tar, unzip, gzip, zip | +| 信息显示命令 | 11 | uname, hostname, dmesg, uptime, du, df, top, free, date, cal | +| 搜索文件命令 | 4 | which, find, whereis, locate | +| 用户管理命令 | 10 | useradd, usermod, userdel, groupadd, passwd, su, sudo, visudo | +| 基础网络操作命令 | 11 | telnet, ssh, scp, wget, ping, ifconfig, netstat, ss | +| 深入网络操作命令 | 9 | nmap, lsof, mail, mutt, nslookup, dig, traceroute, tcpdump | +| 有关磁盘与文件系统的命令 | 16 | mount, umount, fsck, dd, fdisk, mkfs, mkswap, sync | +| 系统权限及用户授权相关命令 | 4 | chmod, chown, chgrp, umask | +| 查看系统用户登陆信息的命令 | 7 | whoami, who, w, last, lastlog, users, finger | +| 内置命令及其它 | 19 | echo, printf, rpm, yum, alias, history, time, xargs, export, bc | +| 系统管理与性能监视命令 | 9 | chkconfig, vmstat, mpstat, iostat, sar, strace, ltrace | +| 关机/重启/注销和查看系统信息的命令 | 6 | shutdown, halt, poweroff, logout, exit, Ctrl+d | +| 进程管理相关命令 | 15 | bg, fg, jobs, kill, crontab, ps, pstree, nohup, pgrep | + +### [[Shell 命令]]：内置在 Shell 中的命令（如 cd, echo, history） +### [[系统命令]]：独立可执行文件（如 ls, cp, grep） +### [[管道（Pipe）]]：通过 | 连接多个命令实现数据流处理 +### [[重定向]]：通过 >, >>, < 实现输入输出重定向 + +## Key Entities +- [[man 命令]]：查看命令帮助的手册工具 +- [[Shell]]：命令行解释器（bash/zsh等） +- [[文件系统]]：Linux 以文件为单位管理所有资源 + +## Connections +- [[Linux]] ← 基础平台 ← [[Linux 命令]] +- [[Shell]] ← 命令执行环境 ← [[管道]] +- [[管道]] ← 数据流处理 ← [[文本处理命令]] + +## Contradictions +无明显冲突点，该文档为纯知识参考文档 diff --git a/wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md b/wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md new file mode 100644 index 00000000..8eac458c --- /dev/null +++ b/wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md @@ -0,0 +1,81 @@ +--- +title: "Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记" +type: source +tags: [frp, frpc, gatekeeper, mac-mini, macos, arm64] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md]] + +## Summary (用中文描述) +- **核心主题**：在 Apple Silicon（ARM64）Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地服务 +- **问题域**：macOS 服务器化运维、内网穿透、远程访问 +- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，结合 tmux/nohup/launchd 三种方式实现后台持久运行 +- **结论/价值**：提供完整的 Mac Mini 服务器化运维指南，包含 macOS 特有障碍（Gatekeeper）的解决方案 + +## Key Claims (用中文描述) +- macOS 默认 `/opt` 目录需要手动创建并授权才能使用 +- macOS Gatekeeper 会阻止未签名程序运行，必须通过 `xattr -rd com.apple.quarantine .` 解除限制 +- launchd 是 macOS 推荐的开机自启服务管理方式，可通过 `launchctl` 管理生命周期 +- 软链接（symlink）策略可实现 FRP 版本无缝切换 + +## Key Quotes +> "macOS 默认 `/opt` 需要手动创建" — 说明了 macOS 与 Linux 目录结构的差异，需手动初始化系统目录 +> "xattr -rd com.apple.quarantine ." — macOS 特有的安全限制解除命令，针对整个目录递归执行 +> "launchd（推荐开机自启）" — macOS 原生服务管理器，是进程持久化的推荐方案 + +## Key Concepts +- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务 +- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端） +- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器 +- [[launchd]]：macOS 原生服务管理器，用于管理系统级和用户级守护进程 + +## Key Entities +- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端 +- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142） +- [[frpc]]：FRP 客户端程序，运行在 Mac Mini 上，建立与 frps 的连接 +- [[frps]]：FRP 服务端程序，运行在 VPS 上，接收公网请求并转发到 frpc +- [[Gatekeeper]]：macOS 安全机制，阻止未签名应用运行 + +## Connections +- [[Mac Mini M4]] ← runs_on ← [[frpc]] +- [[VPS]] ← runs_on ← [[frps]] +- [[frpc]] ← creates_tunnel ← [[frps]] +- [[内网穿透]] ← enables ← [[远程SSH访问]] +- [[launchd]] ← manages ← [[frpc]] 进程生命周期 +- [[Gatekeeper]] ← blocks ← [[frpc]] (需解除) + +## Contradictions +- 无已知冲突 + +## Environment Details +| 项目 | 内容 | +|------|------| +| 系统 | macOS（Mac Mini M4）| +| 架构 | Apple Silicon (ARM64) | +| 软件 | FRP 0.65.0 | +| 安装目录 | `/opt/frp/frp_0.65.0_darwin_arm64` | +| 客户端程序 | `frpc` | +| 配置文件 | `frpc.toml` | +| frps服务器 | 192.227.222.142:7000 | +| frps映射端口 | 6000（SSH）| + +## Installation Steps +1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp` +2. 下载 ARM64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_darwin_arm64.tar.gz` +3. 解压：`tar -xzf frp_0.65.0_darwin_arm64.tar.gz` +4. 解除 Gatekeeper：`xattr -rd com.apple.quarantine .` +5. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 proxies +6. 启动 frpc：`./frpc -c frpc.toml` + +## Background Running Methods +1. **tmux**（推荐开发环境）：创建持久会话，断开 SSH 后仍保持运行 +2. **nohup**（简单后台）：重定向输出到日志文件，适合简单部署 +3. **launchd**（生产环境）：系统级服务，开机自启，推荐使用 plist 配置 + +## Best Practices +- 统一安装路径：`/opt/frp/` 便于版本管理 +- 创建软链接：`ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current` 简化启动命令 +- 日志独立存储：配置 StandardOutPath 和 StandardErrorPath 分离日志 +- 进程守护：使用 launchd KeepAlive=true 确保服务持续运行 diff --git a/wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md b/wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md new file mode 100644 index 00000000..706ff080 --- /dev/null +++ b/wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md @@ -0,0 +1,49 @@ +--- +title: "macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）" +type: source +tags: [obsidian, openclaw, symbolic-link, macos] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md]] + +## Summary (用中文描述) +- **核心主题**：在 macOS 上为 OpenClaw 隐藏目录创建符号链接，使 Finder 和 Obsidian 能够直接访问 +- **问题域**：OpenClaw 默认使用 `~/.openclaw` 隐藏目录，在图形界面中不可见，无法直接作为 Obsidian Vault 使用 +- **方法/机制**：使用 `ln -s` 创建 Symbolic Link，将 `~/.openclaw` 映射为可见的 `~/openclaw` 目录，两个路径指向同一份数据 +- **结论/价值**：符号链接让 Obsidian 可以访问 OpenClaw 的 Markdown 文件，同时保持 OpenClaw 正常工作，是一种零成本、无风险的目录可见性解决方案 + +## Key Claims (用中文描述) +- OpenClaw 的默认数据目录 `~/.openclaw` 是隐藏目录，Finder 和 Obsidian 无法直接访问 +- Symbolic Link（符号链接）可以将隐藏目录映射为可见目录，两个路径指向同一份数据 +- 创建符号链接 `ln -s ~/.openclaw ~/openclaw` 不会复制数据，只创建指向关系 +- 删除符号链接 `rm ~/openclaw` 只会删除链接本身，不会影响原始数据 +- 推荐的长期方案是以 `~/openclaw` 为实际目录，再用 `ln -s` 反向链接到 `~/.openclaw`，便于 Git 管理和 Finder 访问 + +## Key Quotes +> "该操作**只会删除链接文件，不会删除真实目录**。" — Symbolic Link 删除操作的安全性说明 + +> "Finder / Obsidian 可直接访问；OpenClaw 兼容原路径；方便 Git 管理与备份。" — 推荐的长期目录结构三优点 + +## Key Concepts +- [[Symbolic Link]]：符号链接，Unix/Linux/macOS 文件系统特性，通过 `ln -s` 创建，指向另一个文件或目录的特殊文件类型 +- [[目录映射]]：将一个目录路径指向另一个目录内容的机制，使不同路径访问同一份数据 +- [[隐藏目录]]：以 `.` 开头的目录，macOS Finder 默认不显示，需用 `ls -a` 或 `Cmd+Shift+.` 可见 + +## Key Entities +- [[OpenClaw]]：多 Agent 框架，默认数据目录为 `~/.openclaw` 隐藏目录，本笔记的操作对象 +- [[Obsidian]]：本地 Markdown 知识库工具，可通过 Symbolic Link 将 OpenClaw 目录作为 Vault 直接打开 + +## Connections +- [[Obsidian]] ← 通过 Symbolic Link 访问 ← [[OpenClaw]] +- [[OpenClaw]] ← 数据存储于 ← [[Symbolic Link]] + +## Contradictions +- 无已知冲突 + +## Aliases +- Symbolic Link +- 符号链接 +- symlink +- 软链接 diff --git a/wiki/sources/mysql-mariadb-数据库详细信息.md b/wiki/sources/mysql-mariadb-数据库详细信息.md new file mode 100644 index 00000000..c475ef44 --- /dev/null +++ b/wiki/sources/mysql-mariadb-数据库详细信息.md @@ -0,0 +1,81 @@ +--- +title: "MySQL MariaDB 数据库详细信息" +type: source +tags: [database, mariadb, mysql, nas] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/MySQL MariaDB 数据库详细信息.md]] + +## Summary (用中文描述) +- 核心主题：MariaDB/MySQL 数据库的访问配置信息及远程访问用户创建流程 +- 问题域：NAS 上的 MariaDB 数据库内网/公网访问配置、用户权限管理 +- 方法/机制：通过 socket 本地登录创建远程访问用户，使用 `CREATE USER` 和 `GRANT` 语句配置权限 +- 结论/价值：提供完整的 MariaDB 远程访问配置指南，解决新安装 MariaDB 后只能本地 localhost 访问的问题 + +## Key Claims (用中文描述) +- 新安装的 MariaDB 默认只有 `root@localhost` 账户，无法从外部机器连接 +- 远程访问需要创建 `username@%` 格式的用户（`%` 表示允许任意主机） +- Socket 登录是本地管理员访问的安全方式，可绕过网络认证 + +## Key Quotes +> "你的 MariaDB 只有 `root@localhost`，并没有 `root@%` 或你要连接用的用户账号" — MariaDB 权限诊断核心问题 + +> "CREATE USER 'shenwei'@'%' IDENTIFIED BY '!Abcde12345';" — 允许任意主机远程访问的用户创建命令 + +## Key Concepts +- [[Socket 登录]]：通过 Unix socket 文件进行本地认证，无需网络连接 +- [[用户权限]]：Host+User 组合决定访问权限，`%` 表示任意主机 + +## Key Entities +- [[MariaDB]]：开源关系型数据库，Synology NAS 上通过 Docker 部署 +- [[群晖 NAS]]：MariaDB 数据库的宿主机（IP: 192.168.3.17） +- [[shenwei]]：数据库用户名 + +## Connections +- [[群晖 NAS]] ← hosts ← [[MariaDB]] +- [[MariaDB]] ← configured_by ← Socket 登录 + +## Contradictions +- 无冲突 + +## 访问配置摘要 + +### 内网访问 +| 项目 | 值 | +|------|-----| +| IP | 192.168.3.17 | +| Port | 3307 | +| Username | shenwei | +| Password | !Abcde12345 | +| Root | root / !Abcde12345 | + +### 公网访问 +| 项目 | 值 | +|------|-----| +| Domain | mysql.ishenwei.online | +| Port | 63307 | +| Username | shenwei | +| Password | !Abcde12345 | + +### Socket 登录命令 +```bash +sudo mysql -u root -p -S /run/mysqld/mysqld10.sock +``` + +### 创建远程访问用户 +```sql +CREATE USER 'shenwei'@'%' IDENTIFIED BY '!Abcde12345'; +GRANT ALL PRIVILEGES ON *.* TO 'shenwei'@'%' WITH GRANT OPTION; +FLUSH PRIVILEGES; +``` + +### 查看当前用户列表 +```sql +select host, user from mysql.user; +``` + +## Related Sources +- [[Docker卷]] — Docker卷备份中使用 mysqldump 进行数据库一致性备份 +- [[ubuntu服务器通过rsync实现日常增量备份]] — 包含数据库增量备份策略 diff --git a/wiki/sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md b/wiki/sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md new file mode 100644 index 00000000..45bc0d58 --- /dev/null +++ b/wiki/sources/nodewarden-把-bitwarden-搬上-cloudflare-workers-彻底告别服务器.md @@ -0,0 +1,87 @@ +--- +title: "NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器" +type: source +tags: ["Cloudflare", "Bitwarden", "Serverless", "Password-Manager"] +date: 2026-02-27 +--- + +## Source File +- [[raw/Home Office/NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器.md]] + +## Summary (用中文描述) +- **核心主题**：NodeWarden 将 Bitwarden 服务器端部署到 Cloudflare Workers，实现真正的无服务器（Serverless）密码管理 +- **问题域**：传统 Bitwarden 自托管需要维护 VPS/服务器，NodeWarden 彻底消除了这一需求 +- **方法/机制**：通过 Cloudflare Workers 运行 Bitwarden API 兼容层，数据存储在 Cloudflare D1（SQLite）和 R2（对象存储），利用 Workers 的边缘计算能力实现全球低延迟访问 +- **结论/价值**：用户只需一个 Cloudflare 账号（带域名和信用卡）和 GitHub 账号，即可零成本、零运维地运行自托管密码管理器，支持 Bitwarden 官方全平台客户端 + +## Key Claims (用中文描述) +- NodeWarden 通过 Cloudflare Workers 实现无服务器架构，将 Bitwarden 服务器端迁移到边缘计算平台 +- Cloudflare D1（边缘 SQLite）和 R2（对象存储）替代传统 VPS 数据库，数据可靠性由 Cloudflare 保证 +- NodeWarden 在核心功能上与 Bitwarden 保持兼容，同时移除企业级功能（多用户/组织/SSO）以简化架构 +- 通过 GitHub Actions + Cloudflare Pages 实现自动化部署，更新代码只需网页操作 +- TOTP（时间同步动态口令）通过 `TOTP_SECRET` 环境变量免费支持，无需 Bitwarden 付费会员 + +## Key Quotes +> "部署 NodeWarden 之后的效果，就是在无服务器的情况下，也能在手机、电脑上使用 Bitwarden 客户端来保存密码了，支持自动登陆、二次验证之类的功能。" — Appinn + +> "这个步骤需要在 Cloudflare 中绑定 GitHub 账号，根据页面提示即可。" — NodeWarden 一键部署说明 + +## Key Concepts +- [[Serverless Computing]]：NodeWarden 的核心技术范式，代码运行在 Cloudflare Workers 边缘节点而非传统服务器 +- [[Edge Computing]]：Cloudflare Workers 在全球边缘节点运行，提供低延迟访问 +- [[TOTP]]：时间同步一次性密码算法，NodeWarden 通过环境变量 `TOTP_SECRET` 免费提供，无需付费会员 +- [[Passkey]]：WebAuthn 无密码认证标准，NodeWarden 原生支持（Bitwarden 官方需付费会员） +- [[Self-Hosted Password Manager]]：自托管密码管理器，NodeWarden 是 Serverless 架构的变体 + +## Key Entities +- [[NodeWarden]]：GitHub 项目，将 Bitwarden 部署到 Cloudflare Workers 的开源实现，作者 shuaiplus +- [[Bitwarden]]：开源密码管理器，客户端与服务端均开源，NodeWarden 提供 API 兼容实现 +- [[Cloudflare Workers]]：边缘计算平台，NodeWarden 的运行时环境，基于 V8 隔离的 Serverless 平台 +- [[Cloudflare D1]]：边缘 SQLite 数据库，NodeWarden 的主数据存储 +- [[Cloudflare R2]]：S3 兼容对象存储，NodeWarden 用于存储附件 +- [[Cloudflare]]：提供 Workers/D1/R2 的云平台，构成 NodeWarden 的完整基础设施 +- [[shuaiplus]]：NodeWarden GitHub 项目作者 +- [[shenwei]]：本文档原作者（Appinn 作者），已部署 NodeWarden 实例 + +## Connections +- [[NodeWarden]] ← implements ← [[Bitwarden]] +- [[NodeWarden]] ← runs_on ← [[Cloudflare Workers]] +- [[NodeWarden]] ← uses ← [[Cloudflare D1]] +- [[NodeWarden]] ← uses ← [[Cloudflare R2]] +- [[NodeWarden]] ← deploys_via ← [[GitHub Actions]] +- [[Bitwarden]] ← alternative_to ← [[1Password]] +- [[Bitwarden]] ← alternative_to ← [[LastPass]] + +## Contradictions +- 无已知冲突 + +## NodeWarden vs Bitwarden 功能对比 + +| 能力项 | Bitwarden | NodeWarden | 说明 | +| --- | --- | --- | --- | +| 单用户保管库 | ✅ | ✅ | 基于 Cloudflare D1 | +| 文件夹/收藏 | ✅ | ✅ | 常用管理能力可用 | +| 全量同步 `/api/sync` | ✅ | ✅ | 已做兼容与性能优化 | +| 附件上传/下载 | ✅ | ✅ | 基于 Cloudflare R2 | +| 导入功能 | ✅ | ✅ | 覆盖常见导入路径 | +| 网站图标代理 | ✅ | ✅ | 通过 `/icons/{hostname}/icon.png` | +| Passkey、TOTP | ❌ | ✅ | 官方需要会员，NodeWarden 免费 | +| 多用户 | ✅ | ❌ | NodeWarden 定位单用户 | +| 组织/集合/成员权限 | ✅ | ❌ | 没必要实现 | +| 登录 2FA（TOTP/WebAuthn/Duo/Email） | ✅ | ⚠️ 部分支持 | 仅支持 TOTP（通过 `TOTP_SECRET`） | +| SSO / SCIM / 企业目录 | ✅ | ❌ | 没必要实现 | +| Send | ✅ | ❌ | 基本没人用 | +| 紧急访问 | ✅ | ❌ | 没必要实现 | +| 管理后台/计费订阅 | ✅ | ❌ | 纯免费 | +| 推送通知完整链路 | ✅ | ❌ | 没必要实现 | + +## 部署必要条件 +1. Cloudflare 账号（必须有一个域名和信用卡） +2. GitHub 账号 + +## 部署步骤 +1. Fork [NodeWarden GitHub 仓库](https://github.com/shuaiplus/NodeWarden) +2. 在 Cloudflare 页面点击"Deploy to Cloudflare"一键部署 +3. 访问临时地址或绑定自定义域名 +4. 通过设置页面配置：JWT_SECRET、自动更新、主账号密码、TOTP 二次验证 +5. 在 Bitwarden 官方客户端选择"自托管"，输入服务器 URL 即可登录 diff --git a/wiki/sources/public-vs-private-vs-hybrid-cloud-differences-explained.md b/wiki/sources/public-vs-private-vs-hybrid-cloud-differences-explained.md new file mode 100644 index 00000000..3c215841 --- /dev/null +++ b/wiki/sources/public-vs-private-vs-hybrid-cloud-differences-explained.md @@ -0,0 +1,61 @@ +--- +title: "Public vs Private vs Hybrid Cloud Differences Explained" +type: source +tags: [] +date: 2025-06-18 +--- + +## Source File +- [[raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md]] + +## Summary (中文) +- **核心主题**：公有云、私有云、混合云三种云部署模型的定义、优缺点、适用场景及选择决策框架 +- **问题域**：云部署策略选择；成本 vs 安全 vs 性能 vs 可扩展性的权衡 +- **方法/机制**：三种云模型的结构化对比；共享责任模型；混合云的同构/异构决策 +- **结论/价值**：云部署选择没有标准答案，需根据工作负载特点、预算、IT能力制定有意的云策略（intentional cloud strategy），且需持续平衡调整 + +## Key Claims (中文) +- 公有云通过多租户共享模式提供弹性扩展能力，但缺乏成本控制（大规模使用时TCO指数增长）和安全控制 +- 私有云提供独占环境带来更高性能和安全性，适合受监管行业和敏感数据，但TCO高且远程访问受限 +- 混合云通过在公私之间按策略分配工作负载，实现安全与弹性的平衡，但引入成本管理和集成的复杂性 +- 无论选择哪种云模型，云安全问题（访问控制、加密、灾难恢复）始终由用户组织与供应商共同承担——即"共享责任模型" + +## Key Quotes + +> "The rapid switch from local to cloud computing is driven by benefits such as the ability to scale without having to buy and configure hardware, accessibility from anywhere with an internet connection, professionally managed servers that are kept up-to-date with the latest tech and versions of apps, cost efficiency, and quick recovery from cyber attacks." — 云采用的核心驱动因素概述 + +> "The choice between public vs private vs hybrid cloud solutions depends on your use cases, budget, IT capabilities, and expectations for growth. It is rarely an either/or situation, as you may find ways to capture the benefits of each while avoiding the drawbacks." — 云部署选择的核心洞察 + +> "It is important to know that no matter which cloud environment you work in, your problems don't go away... your organization maintains responsibility for: Who has access to what, Cloud security and encryption, Disaster recovery planning." — 共享责任模型的核心 + +## Key Concepts + +- [[Public Cloud]]：通过互联网交付、多租户共享的云服务模式（AWS、Azure、GCP） +- [[Private Cloud]]：专属于单一组织的云环境，通过私有网络访问，可本地托管或第三方托管 +- [[Hybrid Cloud]]：同时使用公有云和私有云的混合环境，在两者之间按策略分配工作负载 +- [[Shared Responsibility Model]]：云安全由供应商和组织共同承担的安全责任划分模型 +- [[Cloud Elasticity]]：云环境快速扩展或收缩资源的能力，无需硬件采购和配置 +- [[CapEx-vs-OpEx]]：资本支出（前期硬件投入）与运营支出（按需付费）的对比 +- [[Cost Agility]]：根据业务需求灵活调整云资源消耗以控制成本的能力 +- [[SLA]]：服务级别协议，定义云服务可用性和性能保证 +- [[Disaster Recovery Planning]]：灾难恢复规划，云环境下的业务连续性保障 + +## Key Entities + +- [[BMC]]：BMC Software — 企业IT管理解决方案提供商，文章原出处 +- [[BMC Helix]]：BMC 旗下AI运维平台，帮助IT组织将AI转化为行动 + +## Connections + +- [[Public Cloud]] ← depends_on ← [[Cloud Infrastructure]] +- [[Private Cloud]] ← depends_on ← [[Cloud Infrastructure]] +- [[Hybrid Cloud]] ← combines ← [[Public Cloud]] AND [[Private Cloud]] +- [[Cloud Adoption Strategy]] ← informs ← [[Public Cloud]] / [[Private Cloud]] / [[Hybrid Cloud]] 选择 +- [[FinOps]] ← constrains ← [[Cost Agility]] +- [[Shared Responsibility Model]] ← applies_to ← ALL three cloud models +- [[SLA]] ← guarantees ← [[High Availability]] +- [[Multi-Cloud Strategy]] ← related_to ← [[Hybrid Cloud]]（有重叠但不同） + +## Contradictions + +- **公有云安全 vs 私有云安全**：文章认为"公有云安全性最低（least secure）"，但[[Cloud Computing]] entity页面引用的Myth 1真相认为"云比本地更安全"。当前观点：两者描述的角度不同——本文从多租户共享模型角度认为公有云安全性最低；Myth 1从整体云安全投入（加密、MFA、ISO 27001）角度认为云比本地安全。两者均为有效视角，安全最终取决于具体实现而非部署模型本身。 diff --git a/wiki/sources/rax50-路由器-更新merlin-clash订阅.md b/wiki/sources/rax50-路由器-更新merlin-clash订阅.md new file mode 100644 index 00000000..2d03e8bd --- /dev/null +++ b/wiki/sources/rax50-路由器-更新merlin-clash订阅.md @@ -0,0 +1,48 @@ +--- +title: "RAX50 路由器更新Merlin Clash订阅" +type: source +tags: [clash, merlin-clash, rax50] +date: 2026-03-04 +--- + +## Source File +- [[raw/Home Office/RAX50 路由器 更新Merlin Clash订阅.md]] + +## Summary (用中文描述) +- 核心主题：如何在 RAX50 路由器的 Merlin Clash 界面中更新科学上网订阅配置 +- 问题域：家庭网络科学上网订阅的日常维护与配置切换 +- 方法/机制：通过路由器 Web 管理界面进入 Merlin Clash，使用小白一键订阅助手导入 vless URL 并切换配置文件，最后通过快速重启使新订阅生效 +- 结论/价值：提供了一套完整的订阅更新操作流程，包含故障排查步骤（快速重启），适合非技术用户在路由器端维护科学上网配置 + +## Key Claims (用中文描述) +- 用户通过 RAX50 路由器管理界面（Web UI）可访问 Merlin Clash 配置界面 +- Merlin Clash 支持导入 vless URL 订阅 +- 小白一键订阅助手可管理多个订阅配置文件，并支持重命名（如 kiwi3） +- 切换配置文件后需点"保存&启动"，若未生效则执行"快速重启" + +## Key Quotes +> "进入RAX50路由器管理界面" — 起点操作，进入路由器 Web 管理后台 +> "在RAX50的Merlin Clash界面，复制vless url进到小白一键订阅助手，并重命名配置文件比如 kiwi3" — 订阅导入与配置文件命名操作 +> "选择新建的配置文件，点保存&启动，如果不行，就再点一次快速重启" — 订阅切换与故障处理 + +## Key Concepts +- [[订阅更新]]：在路由器层面重新导入新的代理节点订阅 URL，使路由器获得最新的代理节点列表 +- [[配置文件切换]]：在 Merlin Clash 中保存并激活不同的订阅配置文件，以切换不同的科学上网策略 +- [[快速重启]]：Merlin Clash 提供的轻量重启机制，用于在不重启整台路由器的情况下重新加载插件配置，解决订阅更新后未生效的问题 + +## Key Entities +- [[网件RAX50]]：NETGEAR WiFi 6 路由器，刷入梅林固件后支持 Merlin Clash 插件 +- [[MerlinClash插件]]：运行在梅林固件上的科学上网插件，基于 Clash 核心，支持多配置文件和订阅管理 +- [[小白一键订阅助手]]：Merlin Clash 内置的订阅管理工具，支持导入 vless/vmess 等多种协议的订阅 URL，并可创建和管理多个命名配置文件 +- [[机场]]：提供 VLESS 订阅 URL 的服务商，用户从此来源获取最新的节点列表 + +## Connections +- [[RAX50路由器刷梅林固件与科学上网]] ← 前置操作 ← 当前页面（订阅更新为同一台路由器的持续维护操作） +- [[MerlinClash插件]] ← 提供插件能力 ← 当前页面 +- [[机场]] ← 提供 vless URL ← 当前页面 + +## Contradictions +- 无冲突 + +## Related Source +- [[网件RAX50路由器刷梅林固件与科学上网插件安装教程]]：RAX50 刷梅林固件 + 安装 Merlin Clash 的完整前置流程 diff --git a/wiki/sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md b/wiki/sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md new file mode 100644 index 00000000..2ba344b3 --- /dev/null +++ b/wiki/sources/rto-vs-rpo-key-differences-for-modern-disaster-recovery.md @@ -0,0 +1,89 @@ +--- +title: "RTO vs RPO: Key Differences for Modern Disaster Recovery" +type: source +tags: [cloud, devops, disaster-recovery, feature-flags, continuous-delivery] +date: 2025-07-26 +--- + +## Source File +- [[raw/Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery.md]] + +## Summary (用中文描述) +- **核心主题**：现代持续交付场景下 RTO（恢复时间目标）和 RPO（恢复点目标）的区别，以及 Feature Flag 如何实现秒级恢复 +- **问题域**：传统灾备只关注硬件故障，而现代软件交付的最大风险来自代码变更本身 +- **方法/机制**： + - RTO 衡量系统停机时间，RPO 衡量数据丢失量 + - Feature Flag 将部署与发布解耦，支持微恢复（feature 级别回滚） + - Kill Switch 实现配置级热切换，无需重新部署 + - Progressive Rollout 通过分阶段放量控制影响范围 +- **结论/价值**：预防优于恢复；Feature Flag 工具（如 LaunchDarkly）可实现秒级 RTO、近零 RPO，远比传统灾备基础设施性价比高 + +## Key Claims (用中文描述) +- Feature Flag 将部署（deploy）与发布（release）解耦，实现配置级热修复 → RTO 从小时降至秒级 +- 渐进式放量（Progressive Rollout）将影响范围限制在 1% 用户 → 包含损害，RTO 以秒计 +- Kill Switch 支持支付网关、搜索算法、AI 模型等任意组件的热切换 → 无需重新部署代码 +- Feature Flag 回滚不丢失数据（只切换代码路径） → RPO 始终保持近零 +- 传统灾备规划关注硬件故障，但现代交付中代码变更频率更高、风险更大 +- 应用分层级保护（Tier 1/2/3），而非对所有系统一刀切 Tier 1 +- HP 将回滚时间从小时缩短到分钟，Christian Dior 从 15 分钟降至即时切换 + +## Key Quotes +> "RTO is about getting back online. It's the clock that starts ticking the moment your system goes down." — RTO 的本质是系统下线那一刻开始的倒计时 +> "RPO is about protecting data. It's measured backwards from the moment of failure." — RPO 从故障时刻向后追溯可接受的数据丢失窗口 +> "Deploy whenever you want, release when you're ready." — Feature Flag 的核心理念：部署与发布分离 +> "Prevention beats cure." — 预防优于恢复，减少故障比快速恢复更有价值 +> "Your RTO drops to seconds because fixing issues becomes a configuration change, not a code deployment." — Feature Flag 将修复变成配置变更而非代码部署 +> "86% of surveyed LaunchDarkly customers recover from incidents within a day." — LaunchDarkly 客户事故恢复数据 + +## Key Concepts +- [[RTO]]：Recovery Time Objective，系统可容忍的最大停机时间，衡量恢复速度 +- [[RPO]]：Recovery Point Objective，可接受的最大数据丢失量，衡量数据保护程度 +- [[Feature Flag]]：功能开关，将代码部署与功能发布解耦，支持热切换 +- [[Kill Switch]]：应急切断开关，紧急情况下绕过故障组件的机制 +- [[Progressive Rollout]]：渐进式放量，分阶段向用户群发布新功能 +- [[Micro-Recovery]]：feature 级别细粒度恢复，无需回滚整个部署 +- [[Deployment-vs-Release]]：部署（代码到达生产）与发布（用户可见）的分离 +- [[Business Impact Analysis]]：业务影响分析，用于确定不同应用的分层保护级别 + +## Key Entities +- [[LaunchDarkly]]：Feature Flag 管理平台，HP、Christian Dior 等企业的 RTO/RPO 优化案例 +- [[Veeam]]：传统灾备工具（数据库备份、服务器镜像） +- [[Acronis]]：传统灾备工具（跨区域复制） +- [[HP]]：HP 案例——Feature Flag 将回滚时间从小时缩短到分钟 +- [[Christian Dior]]：Christian Dior 案例——回滚从 15 分钟降至即时切换 + +## Connections +- [[Disaster Recovery]] ← extends ← [[RTO]] + [[RPO]]（RTO/RPO 是灾备的核心指标） +- [[Deployment-Automation]] ← depends_on ← [[Feature Flag]]（Feature Flag 是现代部署自动化的基础设施） +- [[CI-CD-Pipeline]] ← extends ← [[Deployment-vs-Release]]（持续交付中的部署与发布分离） +- [[High Availability]] ← depends_on ← [[Kill Switch]]（Kill Switch 是 HA 的应急保障机制） +- [[LaunchDarkly]] ← implements ← [[Feature Flag]]（LaunchDarkly 是 Feature Flag 的商业实现） +- [[Feature Flag]] ← enables ← [[Progressive Rollout]]（Feature Flag 支持渐进式放量） + +## Contradictions +- 与传统灾备观点冲突： + - **冲突点**：传统灾备投资（热备服务器、跨区域复制）vs Feature Flag 方案 + - **当前观点**（本文）：软件优先方法（Feature Flag + Kill Switch）ROI 更高；HP 案例显示 8% 客户运维成本降低超 50% + - **对方观点**（传统 DR）：关键业务系统需要完整的基础设施冗余（Active-Active、跨区域热备） + +## Tiering Reference Table + +| Tier | 场景 | RTO 目标 | RPO 目标 | 投资策略 | +|------|------|----------|----------|----------| +| (1) Critical | 支付处理、用户认证 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动化监控 + 3AM 告警 | +| (2) Important | 管理后台、报表 | < 1 小时 | < 15 分钟 | Feature Flag（主要发布）+ 业务时间监控 | +| (3) Nice-to-have | 内部工具、文档站 | < 4 小时 | < 1 小时 | 基础监控 + 手动恢复流程 | + +## Application Criticality Questions + +**If down for an hour:** +- Lost revenue? How much? +- Angry customers? How many? +- Blocked employees? Can they work around it? +- Regulatory issues? Legal problems? + +**If losing last hour of data:** +- Can we recreate it? +- Does it contain money/transactions? +- Will users notice? +- Is it required for compliance? diff --git a/wiki/sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md b/wiki/sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md index f571a885..b05713eb 100644 --- a/wiki/sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md +++ b/wiki/sources/the-myths-and-misconceptions-about-cloud-computing-linkedin.md @@ -1,62 +1,75 @@ --- title: "The Myths and Misconceptions About Cloud Computing | LinkedIn" -source: https://www.linkedin.com/pulse/myths-misconceptions-cloud-computing-raj-vardhan-singh-w86mc/?trackingId=rM%2B%2BhFXj9kp11hppPbPFkQ%3D%3D -author: shenwei -published: 2001-02-25 -created: 2025-03-02 -description: -tags: [] +type: source +tags: [cloud-computing, myths, misconceptions, cloud-migration] +date: 2025-03-02 --- -# The Myths and Misconceptions About Cloud Computing - -Cloud computing has revolutionized the way businesses and individuals manage data, applications, and IT infrastructure. However, despite its widespread adoption, many myths and misconceptions persist, leading to confusion and hesitation among potential users. In this article, we debunk some of the most common cloud computing myths to provide a clearer understanding of its capabilities and limitations. - -## Myth 1: Cloud Computing is Not Secure - -### Reality: Cloud Security is Often More Robust Than On-Premises Solutions - -One of the biggest misconceptions about cloud computing is that it is inherently insecure. In reality, leading cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication. Many cloud platforms comply with stringent industry standards such as ISO 27001, HIPAA, and GDPR. Additionally, cloud providers offer automated security updates and 24/7 monitoring, reducing the risk of breaches compared to traditional on-premises systems. - -## Myth 2: The Cloud is Just Someone Else's Computer - -### Reality: The Cloud is a Vast Network of Data Centers with Advanced Infrastructure - -While it is true that cloud services rely on remote servers, they are far more than just "someone else's computer." Cloud providers operate highly sophisticated data centers with redundancy, scalability, and high availability. These infrastructures are designed to handle massive workloads, offer automated failover, and provide secure, scalable computing power that surpasses typical on-premises solutions. - -## Myth 3: Cloud Computing is Too Expensive - -### Reality: Cloud Computing Can Be Cost-Effective with Proper Management - -Some organizations assume that moving to the cloud will lead to skyrocketing costs. However, cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed. Cost optimization strategies such as reserved instances, auto-scaling, and serverless computing help reduce expenses. Additionally, eliminating the need for on-premises hardware, maintenance, and upgrades often results in significant cost savings. - -## Myth 4: You Lose Control Over Your Data in the Cloud - -### Reality: Cloud Services Provide Extensive Data Control and Management Tools - -A common fear is that once data is in the cloud, companies lose control over it. However, cloud providers offer robust data governance tools, allowing organizations to manage permissions, encrypt data, and monitor access logs. Additionally, many cloud services provide hybrid and multi-cloud options, enabling businesses to maintain control over where and how their data is stored. - -## Myth 5: Cloud Computing is Only for Large Enterprises - -### Reality: Businesses of All Sizes Can Benefit from the Cloud - -While large enterprises have been early adopters, cloud computing is highly accessible to small and medium-sized businesses (SMBs). Cloud platforms offer flexible pricing, allowing SMBs to leverage enterprise-grade technology without large upfront investments. Many startups and small businesses rely on cloud solutions for agility, scalability, and cost savings. - -## Myth 6: Migration to the Cloud is Too Complex and Risky - -### Reality: Cloud Migration Can Be Smooth with Proper Planning - -Although migrating to the cloud requires careful planning, cloud providers offer extensive tools and support to facilitate the process. Strategies like phased migration, hybrid cloud solutions, and professional cloud migration services help mitigate risks and ensure a smooth transition. With the right approach, businesses can move workloads to the cloud with minimal disruption. - -## Myth 7: Cloud Performance is Unreliable - -### Reality: Cloud Providers Offer High Availability and Redundancy - -Some believe that cloud-based services are prone to frequent outages. However, major cloud providers offer service-level agreements (SLAs) that guarantee uptime, often exceeding 99.99%. Redundant infrastructure, automated failover, and global data center distribution enhance reliability, making cloud solutions highly resilient. - -## Last but not least - -Cloud computing is often misunderstood due to persistent myths and misconceptions. In reality, the cloud offers **enhanced security, cost-effectiveness, scalability, and control over data**. By debunking these myths, businesses, and individuals can make informed decisions about adopting cloud technology to drive efficiency and innovation. - ## Source File - [[raw/Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn.md]] + +## Summary (中文描述) +- **核心主题**：云计算领域常见的七大误解与真相，澄清企业和个人对云安全、成本、控制权、适用性、迁移复杂性及可靠性的认知误区。 +- **问题域**：云计算认知偏差、安全焦虑、成本管理、数据主权、技术门槛、性能预期。 +- **方法/机制**：通过逐一反驳误区，提供云服务商的安全投入、架构设计、计费模式、治理工具等实证依据。 +- **结论/价值**：破除误解后，企业和个人可以更理性地评估和采用云技术，推动业务效率和创新。 + +## Key Claims (中文描述) +- 云安全机制（加密、防火墙、MFA）+ 合规认证（ISO 27001、HIPAA、GDPR）+ 自动化监控，使云安全优于传统本地部署。 +- 云不是"别人的电脑"，而是覆盖冗余、自动故障转移和高可用性设计的大规模数据中心网络。 +- 按需付费（Pay-as-you-go）+ 预留实例 + 自动扩缩容 + 无服务器计算，可显著降低总拥有成本。 +- 云平台提供完善的权限管理、数据加密和访问日志监控，企业对数据拥有完全控制权。 +- 云服务对小微企业（SMB）和初创企业同样友好，支持灵活定价和企业级技术。 +- 阶段式迁移、混合云方案和专业迁移服务可以有效降低云迁移的复杂性和风险。 +- 主流云服务商 SLA 保障 99.99% 可用性，全球数据中心分布和冗余架构确保高可靠性。 + +## Key Quotes +> "One of the biggest misconceptions about cloud computing is that it is inherently insecure. In reality, leading cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication." — 安全误解的典型论点 + +> "While it is true that cloud services rely on remote servers, they are far more than just 'someone else's computer.' Cloud providers operate highly sophisticated data centers with redundancy, scalability, and high availability." — "云即他者之电脑"误解的澄清 + +> "Cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed." — 按需付费模式核心定义 + +> "major cloud providers offer service-level agreements (SLAs) that guarantee uptime, often exceeding 99.99%" — SLA 可用性保障 + +## Key Concepts +- [[cloud-computing]]：通过互联网按需提供计算资源（服务器、存储、数据库、网络等），无需本地维护。 +- [[Pay-as-you-go]]：按使用量付费的计费模式，是云计算的核心经济模型。 +- [[cloud-security]]：云环境下的安全实践，包括加密、MFA、防火墙、合规认证和 24/7 监控。 +- [[Data-Governance]]：云平台提供的权限管理、数据加密和访问日志监控能力。 +- [[High-Availability]]：通过冗余基础设施和自动化故障转移实现的高可用性架构。 +- [[Failover]]：主系统故障时自动切换到备用系统的机制。 +- [[SLA]]：服务等级协议，云服务商对可用性的正式承诺（如 99.99% uptime）。 +- [[cloud-migration]]：将工作负载从本地迁移到云端的过程，需合理规划以降低风险。 +- [[Cost-Optimization]]：通过预留实例、自动扩缩容和无服务器计算降低云支出。 +- [[Multi-factor-Authentication]]：多因素认证，云安全的基础机制之一。 +- [[Scalability]]：云平台根据负载动态扩展资源的能力。 + +## Key Entities +- [[ISO-27001]]：国际信息安全管理体系标准，云服务商合规认证之一。 +- [[HIPAA]]：美国健康信息隐私法规，云服务商合规认证之一（医疗行业）。 +- [[GDPR]]：欧盟通用数据保护条例，云服务商合规认证之一。 +- [[AWS]]：亚马逊云科技，主流云服务商之一。 +- [[Azure]]：微软云平台，主流云服务商之一。 +- [[Google-Cloud]]：谷歌云平台，主流云服务商之一。 +- [[Raj-Vardhan-Singh]]：本文作者（LinkedIn 发布）。 + +## Connections +- [[cloud-computing]] ← foundational_for ← [[cloud-migration]] +- [[cloud-computing]] ← requires ← [[cloud-security]] +- [[cloud-computing]] ← enabled_by ← [[High-Availability]] +- [[cloud-computing]] ← enabled_by ← [[Scalability]] +- [[cloud-computing]] ← enabled_by ← [[Cost-Optimization]] +- [[cloud-security]] ← enforced_by ← [[ISO-27001]] +- [[cloud-security]] ← enforced_by ← [[HIPAA]] +- [[cloud-security]] ← enforced_by ← [[GDPR]] +- [[cloud-computing]] ← supported_by ← [[AWS]] +- [[cloud-computing]] ← supported_by ← [[Azure]] +- [[cloud-computing]] ← supported_by ← [[Google-Cloud]] +- [[cloud-migration]] ← requires ← [[Failover]] +- [[cloud-computing]] ← governed_by ← [[SLA]] +- [[Pay-as-you-go]] ← enables ← [[Cost-Optimization]] + +## Contradictions +- 与 [[on-premises]] 的对比：本文认为云在安全、成本、控制方面优于本地部署，与某些企业 IT 保守派观点（"数据必须留在本地"）存在冲突。该冲突集中在数据主权和合规要求层面，非技术能力层面。 +- 与传统采购模式对比：本文主张 Pay-as-you-go 更经济，但未提及长期运行稳定工作负载时预留实例的复杂性，以及超大规模迁移初期的隐性成本（ egress 流量、数据传输费用）。 diff --git a/wiki/sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md b/wiki/sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md new file mode 100644 index 00000000..92a7adec --- /dev/null +++ b/wiki/sources/these-6-linux-apps-let-you-monitor-system-resources-in-style.md @@ -0,0 +1,63 @@ +--- +title: "These 6 Linux Apps Let You Monitor System Resources in Style" +type: source +tags: [linux, system-monitoring, devops-tools, open-source] +date: 2025-12-18 +--- + +## Source File +- [[raw/Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]] + +## Summary (中文描述) +- **核心主题**：介绍6款Linux系统资源监控工具，涵盖TUI（文本界面）和GUI两大类 +- **问题域**：Linux系统监控、进程管理、性能分析 +- **方法/机制**： + - TUI工具：Btop++（综合最强）、Htop（轻量）、Glances（超轻）、Bottom（图表为主） + - GUI工具：Mission Center（类Windows任务管理器）、Stacer（功能最全） +- **结论/价值**：作者首推Btop++，兼具美观与实用；需要GUI则选Mission Center或Stacer + +## Key Claims (中文描述) +- **Btop++** 通过提供CPU/内存/网络/存储实时面板、交互式进程管理（f搜索、t终止、k强杀、Nice值调整）成为作者最爱 +- **Htop** 以极简键盘驱动（F3搜索、F9终止、F7/F8调整优先级）提供轻量级进程监控 +- **Glances** 以纯键盘驱动和超轻量特性，适合SSH远程访问场景 +- **Bottom** 专注实时性能图表绘制，不提供交互式进程管理 +- **Mission Center** 以类Windows任务管理器的图形界面（性能/应用/服务三标签）提供友好体验 +- **Stacer** 提供最全面的功能集（监控+启动项管理+包卸载+GNOME设置+缓存清理） + +## Key Quotes +> "TUI apps make the best resource monitors — they're snappy and responsive, even when the GUI is lagging." — 作者偏好TUI工具的核心原因 +> "Btop++ always gets my vote. It features a nice balance between usability and aesthetics." — 作者最终推荐 +> "Mission Center is your friend" if you want something close to the Windows Task Manager. — GUI替代方案推荐 + +## Key Concepts +- [[TUI]]：文本用户界面，在终端运行的交互式图形化程序 +- [[Resource Monitor]]：系统资源监控工具，用于追踪CPU/内存/磁盘/网络使用情况 +- [[Process Management]]：进程管理，包括查看、搜索、终止、优先级调整 +- [[System Monitoring]]：系统监控，覆盖硬件资源与运行状态的实时观测 +- [[SSH Remote Access]]：通过SSH远程访问服务器进行系统管理 + +## Key Entities +- [[Btop++]]：作者的Top Pick TUI资源监控器，支持主题定制和信号发送 +- [[Htop]]：轻量级TUI进程监控器，键盘驱动（F3/F7/F8/F9） +- [[Glances]]：超轻量键盘驱动监控器，支持Arch/Debian/Snap安装 +- [[Bottom]]：专注实时图表的TUI监控器，支持进程树视图 +- [[Mission Center]]：类Windows任务管理器的GUI监控应用，支持Snap安装 +- [[Stacer]]：功能最全的GUI监控工具，包含系统维护套件 +- [[HowToGeek]]：技术博客，文章来源 + +## Connections +- [[TUI]] ← 应用类型 ← [[Btop++]], [[Htop]], [[Glances]], [[Bottom]] +- [[GUI]] ← 应用类型 ← [[Mission Center]], [[Stacer]] +- [[Process Management]] ← 核心功能 ← [[Btop++]], [[Htop]], [[Glances]], [[Mission Center]], [[Stacer]] +- [[System Monitoring]] ← 核心功能 ← all 6 tools +- [[SSH Remote Access]] ← 使用场景增强 ← [[TUI]] tools + +## Contradictions +- 无已知冲突 + +## Metadata +- **Author**: shenwei +- **Published**: 2025-12-16 +- **Source URL**: https://www.howtogeek.com/these-linux-apps-let-you-monitor-system-resources-in-style/ +- **Platform**: Linux +- **License**: HowToGeek diff --git a/wiki/sources/ubuntu-24-04-enable-ssh.md b/wiki/sources/ubuntu-24-04-enable-ssh.md new file mode 100644 index 00000000..c2dca507 --- /dev/null +++ b/wiki/sources/ubuntu-24-04-enable-ssh.md @@ -0,0 +1,57 @@ +--- +title: "Ubuntu 24.04 启动 SSH 服务" +type: source +tags: [ssh, ubuntu, systemd, firewall] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/Ubuntu 24.04 enable SSH.md]] + +## Summary (用中文描述) +- 核心主题：Ubuntu 24.04 中 SSH 服务的安装、启动与配置 +- 问题域：Linux 服务器远程访问与网络安全 +- 方法/机制： + - 安装 OpenSSH Server 软件包 + - 使用 systemctl 管理 SSH 服务（含开机自启） + - 配置 UFW 防火墙放行 SSH（端口 22） + - **Ubuntu 24.04 关键变化：默认使用 ssh.socket 激活机制**，即按需启动（连接请求来时才启动 sshd 守护进程） + - 可通过 systemctl edit ssh.socket 修改监听端口 + - 可切换回传统 ssh.service 持续运行模式 +- 结论/价值：Ubuntu 24.04 SSH 入门完整操作指南，含传统模式切换方案 + +## Key Claims (用中文描述) +- Ubuntu 24.04 默认使用 **ssh.socket 激活机制**，服务状态 `inactive` 不代表 SSH 不可用，需检查 `ssh.socket` 监听状态 +- 修改自定义端口（例 2222）推荐通过 `systemctl edit ssh.socket` 而非仅修改 `/etc/ssh/sshd_config` +- 若需 SSH 持续后台运行，可执行 `systemctl disable --now ssh.socket` + `systemctl enable --now ssh.service` + +## Key Quotes +> "在 Ubuntu 24.04 中，你可以使用以下命令来确保服务处于活动状态并随系统启动：sudo systemctl start ssh; sudo systemctl enable ssh" — 标准启动与自启命令 + +> "如果你发现 systemctl status ssh 显示服务未运行，别担心。24.04 默认使用 Socket 激活模式。你可以通过 sudo systemctl status ssh.socket 检查监听状态" — Ubuntu 24.04 行为的关键说明 + +## Key Concepts +- [[Socket Activation]]：systemd 机制，服务按需启动（ssh.socket 监听端口，有连接时才启动 ssh.service） +- [[UFW 防火墙]]：Ubuntu 默认防火墙，通过 `ufw allow ssh` 放行 SSH 流量 +- [[开机自启]]：systemd enable 命令将服务注册为开机启动 +- [[远程访问]]：通过 SSH 协议从另一台设备连接服务器 +- [[按需服务]]（On-Demand Service）：ssh.socket 代表的启动模式，节省资源 + +## Key Entities +- [[Ubuntu 24.04]]：Canonical Ubuntu LTS 版本，默认引入 ssh.socket 激活机制 +- [[OpenSSH Server]]：Ubuntu SSH 服务端软件包，提供 sshd 守护进程 +- [[UFW]]（Uncomplicated Firewall）：Ubuntu 默认防火墙管理工具 +- [[ssh.socket]]：systemd 的 socket 单元，负责监听 22 端口并按需触发 ssh.service +- [[ssh.service]]：systemd 的 service 单元，实际运行 sshd 守护进程 + +## Connections +- [[UFW 防火墙]] ← enables ← [[Ubuntu 24.04 启动 SSH 服务]] +- [[OpenSSH Server]] ← installed_by ← [[Ubuntu 24.04 启动 SSH 服务]] +- [[Socket Activation]] ← is_activated_by ← [[ssh.socket]] +- [[ssh.service]] ← substitutes ← [[ssh.socket]]（传统模式切换） + +## Contradictions +- 与旧版 Ubuntu SSH 行为冲突： + - 冲突点：旧版 `systemctl status ssh` 显示 `active (running)` 才代表正常；24.04 中服务可能显示 `inactive` 但 SSH 仍可正常工作 + - 当前观点：Socket 激活是 Ubuntu 24.04 默认行为，不代表故障 + - 对方观点：服务未 running 即认为 SSH 未启用 diff --git a/wiki/sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md b/wiki/sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md new file mode 100644 index 00000000..d741c3b7 --- /dev/null +++ b/wiki/sources/ubuntu-安装-frp-0-65-0-x86_64-操作笔记.md @@ -0,0 +1,127 @@ +--- +title: "Ubuntu 安装 FRP 0.65.0（x86_64）操作笔记" +type: source +tags: [frp, frpc, ubuntu, systemd, x86_64] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/Ubuntu 安装 FRP 0.65.0（x86_64）操作笔记.md]] + +## Summary (用中文描述) +- **核心主题**：在 Ubuntu Server 24.04（x86_64/amd64）上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地 SSH 服务 +- **问题域**：Linux 服务器运维、内网穿透、服务管理 +- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，通过 systemd 实现开机自启和进程管理 +- **结论/价值**：提供完整的 Ubuntu Server FRP 运维手册，包含 systemd 服务管理、最佳实践和故障排查指南；与 Mac Mini ARM64 版本形成完整的多平台覆盖 + +## Key Claims (用中文描述) +- Ubuntu Server 24.04 需手动创建 `/opt/frp` 安装目录 +- FRP 0.65.0 使用 TOML 配置文件格式（frpc.toml） +- systemd 是 Ubuntu/Linux 生产环境推荐的服务管理方式 +- 通过软链接（symlink）策略可实现版本无缝切换，无需修改 systemd 配置 +- journald 日志是 systemd 环境的推荐日志管理方案 + +## Key Quotes +> "login to server success" — frpc 成功连接 frps 的日志标志 +> "proxy added: ssh" — SSH 代理成功注册的日志标志 +> "Restart=on-failure + RestartSec=10" — systemd 服务自动恢复配置，确保服务中断后自动重启 +> "升级时只需要切换 symlink，无需修改 systemd 配置" — 软链接策略的核心价值 + +## Key Concepts +- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务 +- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端） +- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器 +- [[systemd]]：Linux 系统和服务管理器，Ubuntu Server 的默认初始化系统，用于管理 FRP 客户端开机自启 +- [[软链接策略]]：通过 `/opt/frp/current` 软链接指向具体版本目录，实现版本切换无需修改 systemd 配置 + +## Key Entities +- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142，端口: 7000） +- [[frpc]]：FRP 客户端程序，运行在 Ubuntu Server 上，建立与 frps 的反向隧道 +- [[frps]]：FRP 服务端程序，运行在 VPS 上，监听 7000 端口，接收 frpc 连接并转发请求 +- [[Ubuntu Server]]：Canonical 维护的 Linux 服务器操作系统，本次安装目标为 24.04 LTS 版本 +- [[systemd]]：Linux 系统和服务管理器，Ubuntu Server 24.04 的默认初始化系统 + +## Connections +- [[Ubuntu Server]] ← runs_on ← [[frpc]] +- [[VPS]] ← runs_on ← [[frps]] +- [[frpc]] ← creates_tunnel ← [[frps]] +- [[systemd]] ← manages ← [[frpc]] 进程生命周期 +- [[内网穿透]] ← enables ← [[远程SSH访问]] +- [[软链接策略]] ← simplifies ← [[版本升级]]（无需修改 systemd 配置） + +## Contradictions +- 与 [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] 存在**平台差异**： + - 差异点：服务管理机制（Ubuntu 用 systemd，macOS 用 launchd） + - 当前观点：systemd 是 Linux 生产环境标准，配置简单（service 文件 + systemctl 命令） + - 对方观点：launchd 是 macOS 原生方案，通过 plist + launchctl 管理 + - 结论：两个平台均推荐各自原生的服务管理机制，不存在优劣之分，只是生态差异 + +## Environment Details +| 项目 | 内容 | +|------|------| +| 系统 | Ubuntu Server 24.04 LTS | +| 架构 | x86_64 (amd64) | +| 软件 | FRP 0.65.0 | +| 安装目录 | `/opt/frp/frp_0.65.0_linux_amd64` | +| 客户端程序 | `frpc` | +| 配置文件 | `frpc.toml` | +| 服务管理 | systemd | +| frps服务器 | 192.227.222.142:7000 | +| frps认证token | your_token_here | +| frps映射端口 | 6000（本地 SSH 22 → 远程 6000）| + +## Installation Steps +1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp` +2. 下载 x86_64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_linux_amd64.tar.gz` +3. 解压：`tar -xzf frp_0.65.0_linux_amd64.tar.gz` +4. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 [[proxies]] 数组 +5. 测试运行：`./frpc -c frpc.toml`，验证 "login to server success" +6. 创建 systemd 服务文件：`/etc/systemd/system/frpc.service` +7. 启用开机自启：`sudo systemctl daemon-reload && sudo systemctl enable --now frpc` + +## Configuration Reference +```toml +serverAddr = "192.227.222.142" +serverPort = 7000 + +[auth] +token = "your_token_here" + +[[proxies]] +name = "ssh" +type = "tcp" +localIP = "127.0.0.1" +localPort = 22 +remotePort = 6000 +``` + +## systemd Service Template +```ini +[Unit] +Description=frp client +After=network-online.target +Wants=network-online.target + +[Service] +Type=simple +ExecStart=/opt/frp/frp_0.65.0_linux_amd64/frpc -c /opt/frp/frp_0.65.0_linux_amd64/frpc.toml +Restart=on-failure +RestartSec=10 + +[Install] +WantedBy=multi-user.target +``` + +## Maintenance Commands +- 查看状态：`sudo systemctl status frpc` +- 查看日志：`sudo journalctl -u frpc -f` +- 重启服务：`sudo systemctl restart frpc` +- 停止服务：`sudo systemctl stop frpc` +- 禁用开机自启：`sudo systemctl disable frpc` + +## Best Practices +1. **软链接策略**：创建 `/opt/frp/current` → 具体版本目录的软链接，systemd 配置使用 current 路径 +2. **日志管理**：使用 journald（journalctl）管理日志，支持实时流式查看和历史记录 +3. **配置验证**：使用 `./frpc validate -c frpc.toml` 验证配置文件语法后再重启服务 +4. **防火墙检查**：确保 frps 服务器端口（7000）和映射端口（6000）在防火墙中开放 +5. **版本管理**：多版本并存于 `/opt/frp/` 下，通过软链接切换，systemd 配置保持不变 diff --git a/wiki/sources/ubuntu服务器通过rsync实现日常增量备份.md b/wiki/sources/ubuntu服务器通过rsync实现日常增量备份.md new file mode 100644 index 00000000..5e6cb3da --- /dev/null +++ b/wiki/sources/ubuntu服务器通过rsync实现日常增量备份.md @@ -0,0 +1,56 @@ +--- +title: "Ubuntu服务器通过rsync实现日常增量备份" +type: source +tags: [ubuntu, rsync, backup, nas] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md]] + +## Summary (用中文描述) +- 核心主题：Ubuntu服务器通过rsync实现日常增量备份到NAS的完整解决方案 +- 问题域：数据备份、网络存储挂载、系统容灾恢复 +- 方法/机制：rsync自动化脚本 + Cron定时任务 + /etc/fstab永久挂载 + NFS网络文件系统 +- 结论/价值：rsync优势在于不关机运行、仅传输变化文件，是构建"工作室级"数据保护体系的最后一步；结合Clonezilla整机镜像实现完整灾备策略 + +## Key Claims (用中文描述) +- rsync通过SSH或不通过SSH方式增量同步数据，仅传输变化的文件，大幅降低带宽和时间成本 +- NFS永久挂载必须写入/etc/fstab，并使用_netdev参数确保网络完全启动后才尝试挂载，避免开机卡死 +- Docker卷数据备份建议先执行mysqldump导出SQL再rsync同步，直接复制二进制数据库文件可能导致恢复后无法启动 +- rsync错误码0/23/24均视为成功（23=部分文件权限问题，24=源文件消失），这些在运行系统备份中属正常情况 +- 停止rsync进程应优先使用SIGTERM（killall rsync）而非SIGKILL（killall -9 rsync），防止临时文件残留和数据损坏 + +## Key Quotes +> "rsync 的优势在于它可以**不关机**运行，并且只传输**变化过**的文件。" — rsync增量备份的核心价值 + +> "_netdev: **关键参数**。告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死。" — NFS挂载参数解析 + +> "rsync 返回 23 表示部分文件由于权限或消失未传输，这在备份正在运行的系统时常见。我们重点看是否大部分数据已同步。" — 错误码容错处理原则 + +## Key Concepts +- [[增量备份]]：通过rsync仅同步源端与目标端差异部分，实现高效的日常数据保护 +- [[永久挂载]]：通过/etc/fstab配置实现NFS/Samba等网络存储的开机自动挂载 +- [[挂载点检查]]：备份脚本执行前验证挂载点有效性，防止数据写入本地磁盘导致硬盘爆满 +- [[Cron定时任务]]：通过crontab配置凌晨3点自动执行备份，实现无人值守运维 +- [[进程管理]]：通过信号（SIGTERM/SIGKILL）控制rsync备份进程的优雅或强制终止 + +## Key Entities +- [[Docker卷]]：Docker容器持久化数据存储，默认路径/var/lib/docker/volumes，是TikTok业务数据备份的核心对象 +- rsync_backup.sh：自动化备份脚本，含锁文件机制、挂载检查、日志记录、错误容错 + +## Connections +- [[增量备份]] ← part_of ← [[Disaster-Recovery]] +- [[Docker卷]] ← backup_target ← [[增量备份]] +- [[NFS]] ← storage_backend ← [[永久挂载]] +- [[永久挂载]] ← requires ← [[挂载点检查]] + +## Contradictions +- 无已知冲突 + +## Metadata +- **Source type**: 运维实践笔记（个人经验总结） +- **Prerequisites**: NAS已挂载、NFS服务已配置 +- **Related practices**: Clonezilla整机镜像备份（时间点恢复的完整策略） +- **Key scripts**: /usr/local/bin/rsync_backup.sh +- **Schedule**: 0 3 * * * (每日凌晨3点) diff --git a/wiki/sources/understanding-complete-itsm.md b/wiki/sources/understanding-complete-itsm.md new file mode 100644 index 00000000..29bf7a01 --- /dev/null +++ b/wiki/sources/understanding-complete-itsm.md @@ -0,0 +1,78 @@ +--- +title: "Modern ITSM: Driving Efficiency, Security & Resilience" +type: source +tags: [] +date: 2025-03-01 +--- + +## Source File +- [[raw/Cloud & DevOps/Understanding Complete ITSM.md]] + +## Summary (用中文描述) +- **核心主题**：现代IT服务管理（ITSM）已超越传统工单管理，成为企业运营卓越、风险缓解和创新加速的战略推动者。 +- **问题域**：传统遗留服务管理模式无法应对快速变化的IT环境；需要敏捷性、自动化和弹性能力。 +- **方法/机制**：通过AIOps、预测分析、自动化修复、自愈系统等AI驱动技术重构ITSM八大核心流程：问题管理、事件管理、变更管理、发布管理、配置管理、资产管理、安全合规管理、灾备与业务连续性。 +- **结论/价值**：AIOps、超自动化与ITSM 2.0的融合定义了一个新范式——自学习、预测性和自主化的IT运营。 + +## Key Claims (用中文描述) +- **AI驱动异常检测** ← 通过预测分析消除重复故障 ← 聚焦根本原因根除而非症状管理。 +- **AIOps驱动的自愈IT生态系统** ← 实时可观测性 + 自动化修复 ← 最小化MTTR，最大化正常运行时间。 +- **风险感知变更审批** ← AI预测失败概率 ← 确保变更平稳落地。 +- **零信任架构（ZTA）+ 策略即代码（PaC）** ← 自动化风险评分 + AI威胁情报 ← 强化网络安全与合规。 +- **云原生DRaaS** ← AI驱动的自动故障转移策略 ← 保障业务连续性与RTO/RPO优化。 + +## Key Quotes +> "IT Service Management (ITSM) is no longer just about ticketing—it's the strategic enabler of operational excellence, risk mitigation, and innovation acceleration." — 文章开篇核心论点 + +> "ML-enhanced event correlation reduces incident duplication, streamlining RCA processes." — ML增强事件关联减少事件重复，加速根因分析 + +> "Risk-based change approvals leverage AI to predict failure probabilities, ensuring seamless rollouts." — 基于风险的变更审批利用AI预测失败概率 + +> "The convergence of AIOps, hyperautomation, and ITSM 2.0 is defining a new paradigm: self-learning, predictive, and autonomous IT operations." — 未来趋势：AIOps + 超自动化 + ITSM 2.0 = 自学习/预测/自主化IT运营 + +## Key Concepts +- [[AIOps]]：AI驱动的IT运维，通过机器学习实现异常检测、事件关联和自动修复。 +- [[ITSM]]：IT服务管理，从传统工单系统演进为战略业务推动者。 +- [[ITSM-2.0]]：下一代ITSM，融合AIOps和超自动化，具备自学习、预测性和自主化能力。 +- [[Zero-Trust-Architecture]]：零信任架构，持续验证、永不信任的安全框架。 +- [[Policy-as-Code]]：策略即代码，将安全合规策略编码为可执行代码。 +- [[CMDB]]：配置管理数据库，AI驱动的CMDB增强依赖映射和漂移检测。 +- [[Self-Healing-Systems]]：自愈系统，通过AIOps实现自动化故障检测和修复。 +- [[Hyperautomation]]：超自动化，融合多种自动化技术实现端到端流程自动化。 +- [[Problem-Management]]：问题管理，聚焦根本原因根除。 +- [[Incident-Management]]：事件管理，实时可观测性与自动化修复。 +- [[Change-Management]]：变更管理，AI驱动的风险评估和审批。 +- [[Release-Management]]：发布管理，DevOps集成与渐进式交付。 +- [[Configuration-Management]]：配置管理，AI增强的依赖映射与漂移检测。 +- [[Asset-Management]]：资产管理，智能生命周期跟踪。 +- [[Security-and-Compliance]]：安全与合规，ZTA + PaC + 合规自动化。 +- [[Disaster-Recovery]]：灾备与业务连续性，AI驱动的自动故障转移。 +- [[RTO]]：恢复时间目标，灾难恢复的关键指标。 +- [[RPO]]：恢复点目标，数据恢复的最大可容忍丢失量。 +- [[DRaaS]]：灾备即服务，云原生灾难恢复解决方案。 +- [[IaC]]：基础设施即代码，通过代码管理基础设施配置。 +- [[Canary-Release]]：金丝雀发布，渐进式发布策略。 +- [[Blue-Green-Deployment]]：蓝绿部署，零停机发布策略。 +- [[RCA]]：根因分析，问题管理的核心活动。 +- [[MTTR]]：平均恢复时间，事件管理关键指标。 +- [[Event-Correlation]]：事件关联，将相关事件归类以减少噪音。 + +## Key Entities +- [[shenwei]]：LinkedIn文章作者，专注于现代IT运维和云转型领域。 +- [[BMC]]：企业IT管理解决方案提供商，Helix/Control-M产品线。 +- [[Micro-Focus]]：企业IT运营管理厂商（CTP课程中涉及）。 + +## Connections +- [[AIOps]] ← enables ← [[Self-Healing-Systems]] +- [[ITSM]] ← evolves_to ← [[ITSM-2.0]] +- [[Zero-Trust-Architecture]] ← protects ← [[Cloud-Native]] +- [[Policy-as-Code]] ← enforces ← [[Security-and-Compliance]] +- [[CMDB]] ← supports ← [[Configuration-Management]] +- [[DRaaS]] ← achieves ← [[Disaster-Recovery]] + [[RTO]] + [[RPO]] +- [[Canary-Release]] ← is_a ← [[Release-Management]] pattern +- [[Blue-Green-Deployment]] ← is_a ← [[Release-Management]] pattern +- [[IaC]] ← enables ← [[Change-Management]] +- [[Hyperautomation]] ← enables ← [[ITSM-2.0]] + +## Contradictions +- （本文档未发现与其他页面的明显冲突） diff --git a/wiki/sources/what-is-devsecops-best-practices-benefits-and-tools.md b/wiki/sources/what-is-devsecops-best-practices-benefits-and-tools.md new file mode 100644 index 00000000..3693ba49 --- /dev/null +++ b/wiki/sources/what-is-devsecops-best-practices-benefits-and-tools.md @@ -0,0 +1,112 @@ +--- +title: "What is DevSecOps? Best Practices, Benefits, and Tools" +type: source +tags: [DevSecOps, Security, CI/CD, SDLC] +date: 2025-12-19 +source: https://www.bacancytechnology.com/blog/what-is-devsecops +author: shenwei +published: 2023-10-30 +--- + +## Source File +- [[raw/Cloud & DevOps/What is DevSecOps Best Practices, Benefits, and Tools.md]] + +## Summary (中文摘要) +- **核心主题**：DevSecOps 将安全实践深度集成到软件开发全生命周期的方法论，解决传统 DevOps 中安全滞后的问题 +- **问题域**：软件安全开发、安全自动化、DevOps 文化转型、企业安全合规 +- **方法/机制**：通过 Shift Left（安全左移）和 Shift Right（安全右移）策略，在 SDLC 各阶段嵌入安全检查；通过 SAST/DAST/IAST/SCA 等工具实现自动化安全测试 +- **结论/价值**：DevSecOps 可将 70% 的上线后漏洞在开发阶段预防，成本效益比传统安全实践高 3-5 倍 + +## Key Claims (中文描述) +- DevSecOps 通过在 CI/CD 流程中集成安全检查，使开发团队比传统团队能更好地处理安全问题 +- 70% 的上线后发现的安全漏洞本可以通过 DevSecOps 预防 +- 安全自动化将漏洞修复时间从数周缩短到数小时 +- DevSecOps 涵盖五大核心要素：协作（Collaboration）、沟通（Communication）、自动化（Automation）、工具与架构安全（Security of Tools and Architecture）、测试（Testing） +- Shift Left 策略通过早期发现安全问题，降低修复成本可达 100 倍 + +## Key Quotes +> "DevSecOps brings together three important groups: 'Dev' for development, 'Sec' for security, and 'Ops' for operations teams." — DevSecOps 命名来源 + +> "70% of software vulnerabilities discovered post-launch could have been prevented with DevSecOps" — DevSecOps 核心价值主张 + +> "'Shift left' means identifying security flaws early in the software development lifecycle." — 安全左移定义 + +> "'Shift right' highlights the need for ongoing security measures even after launching the application." — 安全右移定义 + +## Key Concepts +- [[DevSecOps]]：将安全深度集成到 DevOps 流程中的方法论，使安全成为开发、运维、安全团队的共同责任 +- [[Shift-Left-Security]]：安全测试左移到软件开发生命周期早期阶段的实践，降低修复成本 +- [[Shift-Right-Security]]：在生产环境部署后持续进行安全监控和响应的实践 +- [[SAST]]（Static Application Security Testing）：静态应用安全测试，分析源代码发现安全漏洞 +- [[DAST]]（Dynamic Application Security Testing）：动态应用安全测试，通过模拟外部攻击发现运行时刻漏洞 +- [[IAST]]（Interactive Application Security Testing）：交互式应用安全测试，在运行时检测漏洞 +- [[SCA]]（Software Composition Analysis）：软件组成分析，扫描第三方依赖中的已知漏洞 +- [[SDLC]]（Software Development Lifecycle）：软件开发生命周期，包括需求分析、规划、架构设计、开发、测试、部署六阶段 +- [[Break-the-Build]]：当安全风险过高时自动停止构建进程的机制 +- [[Policy-as-Code]]：以代码形式定义和管理安全策略的实践 +- [[Immutable-Infrastructure]]：不可变基础设施，通过预配置组件减少未授权变更风险 + +## Key Entities +- [[Amazon-Inspector]]：AWS 漏洞管理服务，可自动处理安全漏洞 +- [[Amazon-CodeGuru-Reviewer]]：AWS 代码审查服务，识别安全问题和资源泄漏 +- [[AWS-CodePipeline]]：AWS CI/CD 服务，用于应用部署和管理 +- [[Snyk]]：开源安全工具，集成到 DevSecOps 工具链 +- [[SonarQube]]：代码质量和安全静态分析工具 +- [[Jenkins]]：开源 CI/CD 工具（DevOps 工具） +- [[Docker]]：容器化平台（DevOps 工具） +- [[Kubernetes]]：容器编排平台（DevOps 工具） + +## DevSecOps vs DevOps Comparison + +| 维度 | DevOps | DevSecOps | +|------|--------|-----------| +| **定义** | 强调开发与运维协作加速交付 | 将安全实践集成到开发过程 | +| **主焦点** | 加速软件开发与部署 | 在每个开发阶段集成安全 | +| **安全角色** | 安全单独处理或最后处理 | 从一开始就将安全嵌入每个步骤 | +| **目标** | 提升团队速度和协作 | 早期解决安全问题预防后续问题 | +| **自动化** | 自动化开发与运维任务 | 自动化安全检查与开发任务 | +| **团队参与** | 开发与运维协作 | 开发、运维、安全三方协作 | +| **合规方式** | 开发后进行合规检查 | 开发部署全程确保合规 | + +## DevSecOps 核心组件 + +### 1. 协作（Collaboration） +- 安全任务在开发和运维团队间共享 +- 不需要独立的安全团队 +- 开发者被鼓励理解安全实践 + +### 2. 沟通（Communication） +- 安全专业人员需要用开发者理解的简单语言解释安全控制 +- 开发者应了解安全责任，识别潜在威胁，遵循安全编码最佳实践 +- 在开发过程中进行漏洞测试 + +### 3. 自动化（Automation） +- 将自动化安全测试添加到 CI/CD 管道 +- "Break the Build" 机制在安全风险过高时停止构建 +- 确保软件依赖保持最新 + +### 4. 工具与架构安全（Security of Tools and Architecture） +- 选择和审查安全工具 +- 谨慎管理用户访问（多因素认证、最小权限） +- 定期监控工作站和服务器漏洞 +- 扫描代码中的敏感数据 +- 新容器配置安全设置 + +### 5. 测试（Testing） +- 在每个开发阶段集成安全测试 +- 使用 OWASP Top Ten 进行基础安全测试 +- SAST/DAST/IAST 技术 +- 渗透测试和威胁建模 +- Bug Bounty 计划 + +## Connections +- [[DevOps]] ← extends ← [[DevSecOps]]（DevSecOps 是 DevOps 的安全扩展） +- [[Agile-Practices]] ← integrates_with ← [[DevSecOps]]（敏捷开发与 DevSecOps 相辅相成） +- [[CI/CD-Pipeline]] ← embeds ← [[DevSecOps-Security-Tools]]（安全工具集成到 CI/CD 管道） +- [[Cloud-Transformation]] ← includes ← [[DevSecOps]]（云转型包含 DevSecOps 实践） +- [[Shift-Left-Security]] ← complements ← [[Shift-Right-Security]]（左移与右移互补） + +## Contradictions +- **安全与速度的张力**：传统观点认为安全检查会减慢开发速度；DevSecOps 主张通过自动化实现安全与速度双赢 +- **集中式 vs 分布式安全**：传统安全团队独立负责安全；DevSecOps 倡导安全责任分散到整个开发团队 +- **合规时机**：传统做法在开发后进行合规检查；DevSecOps 强调全程合规 diff --git a/wiki/sources/在synology-nas上安装clouddrive2.md b/wiki/sources/在synology-nas上安装clouddrive2.md new file mode 100644 index 00000000..b2a34d7f --- /dev/null +++ b/wiki/sources/在synology-nas上安装clouddrive2.md @@ -0,0 +1,42 @@ +--- +title: "在Synology NAS上安装CloudDrive2" +type: source +tags: [clouddrive2, nas, synology, 阿里云盘] +date: 2025-12-29 +--- + +## Source File +- [[raw/Home Office/在Synology NAS上安装CloudDrive2.md]] + +## Summary (用中文描述) +- 核心主题：在 Synology NAS 上通过 CloudDrive2 将阿里云盘挂载为本地文件系统 +- 问题域：NAS 本地存储与云端存储的融合、家庭多媒体中心的云盘访问 +- 方法/机制：利用矿神源（社群套件源）安装 CloudDrive2，通过阿里云盘 App 扫码授权，实现云盘的本地挂载访问 +- 结论/价值：将阿里云盘无缝接入 NAS 文件系统，无需手动同步即可直接访问云端资源 + +## Key Claims (用中文描述) +- 矿神源提供了 CloudDrive2 等第三方套件，扩展了 Synology 官方套件中心的应用生态 +- DSM 7+ 版本要求额外的 Root 权限修复命令，否则 CloudDrive2 可能无法正常运行 +- 阿里云盘授权时应仅授权"资源目录"，避免"备份目录"以控制数据访问范围 + +## Key Quotes +> "不要授权备份目录，仅资源目录即可" — 最小权限原则，避免意外访问敏感备份数据 + +## Key Concepts +- [[云盘挂载]]：通过 FUSE/虚拟文件系统将云端存储映射为本地目录的技术 +- [[NAS套件管理]]：群晖 NAS 的 Package Center 套件安装与管理机制 +- [[Root权限修复]]：DSM 7+ 系统中第三方套件权限配置的特殊处理方法 + +## Key Entities +- [[CloudDrive2]]：云盘挂载工具，支持阿里云盘、Google Drive、OneDrive 等多种云存储服务 +- [[Synology NAS]]（群晖 NAS）：网络附加存储设备，本方案的硬件平台 +- [[矿神源]]：Synology 社群套件源（SPK 社区生态），提供大量官方未收录的第三方应用 +- [[阿里云盘]]：阿里巴巴云盘服务，本方案的挂载目标云存储 + +## Connections +- [[群晖NAS科学上网]] ← 关联场景 ← [[在Synology NAS上安装CloudDrive2]] +- [[Home Server 多服务架构]] ← 扩展 ← [[在Synology NAS上安装CloudDrive2]] +- [[CloudDrive2]] ← 挂载目标 ← [[阿里云盘]] + +## Contradictions +- 无已知冲突 diff --git a/wiki/sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md b/wiki/sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md new file mode 100644 index 00000000..4786ce8d --- /dev/null +++ b/wiki/sources/如何判别你的linux-服务器是-x64-也就是-x86_64-还是-arm64.md @@ -0,0 +1,46 @@ +--- +title: "如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64" +type: source +tags: [linux, 运维] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/如何判别你的Linux 服务器是 x64（也就是 x86_64）还是 ARM64.md]] + +## Summary (用中文描述) +- **核心主题**：Linux 服务器 CPU 架构检测方法 +- **问题域**：服务器运维中需要确定机器硬件架构以选择正确软件包的场景 +- **方法/机制**：通过 4 种系统命令（uname、lscpu、/proc/cpuinfo、file）读取系统硬件标识 +- **结论/价值**：快速准确识别服务器架构，确保下载和安装正确的软件版本（如 .deb/.rpm 包、容器镜像） + +## Key Claims (用中文描述) +- `uname -m` 命令通过返回机器硬件名称来标识 CPU 架构 +- `lscpu` 命令以结构化方式输出 CPU 架构、位宽和字节序等详细信息 +- `/proc/cpuinfo` 文件包含 CPU 型号和架构特性信息，可通过 model name 或 AArch64/ARMv8 标识判断 +- `file` 命令通过分析 ELF 可执行文件的元数据来判断二进制文件的目标架构 + +## Key Quotes +> `x86_64` → 表示 **64位 x86（Intel/AMD）架构** +> `aarch64` → 表示 **64位 ARM 架构** +> `armv7l` → 表示 **32位 ARM 架构** + +## Key Concepts +- [[CPU架构检测]]：通过系统命令识别服务器 CPU 微架构类型的方法论 +- [[x86_64]]：64位 x86 指令集架构，Intel 和 AMD 处理器使用的标准，由 x86 扩展而来 +- [[aarch64]]：ARM 64位架构规范，ARMv8-A 开始引入的 64位指令集 +- [[ARM64]]：基于 ARM 设计的 64位处理器架构，常见于云服务商（AWS Graviton、阿里云 ARM 实例） +- [[ELF格式]]：Executable and Linkable Format，Linux 可执行文件标准格式，包含目标架构元数据 + +## Key Entities +- 无特定实体（属于通用运维知识） + +## Connections +- [[Linux运维命令]] ← related_to ← [[CPU架构检测]] +- [[Docker镜像多架构]] ← depends_on ← [[CPU架构检测]] + +## Contradictions +- 无已知冲突 + +## Related Sources +- [[linux-运维必会的-150-个命令]] — 包含更多 Linux 系统诊断命令 diff --git a/wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md b/wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md new file mode 100644 index 00000000..9d8ec00a --- /dev/null +++ b/wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md @@ -0,0 +1,60 @@ +--- +title: "如何在Ubuntu Server安装 Docker & Docker Compose" +type: source +tags: [docker, ubuntu] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/如何在Ubuntu Server安装 docker & docker compose.md]] + +## Summary (用中文描述) +- 核心主题：在 Ubuntu Server 上通过官方 apt 仓库安装 Docker Engine 和 Docker Compose V2 的完整流程 +- 问题域：服务器容器化环境搭建 +- 方法/机制：五步标准安装流程——卸载旧版 → 配置官方仓库 → 安装引擎 → 验证安装 → 配置非 root 用户 +- 结论/价值：推荐从 Docker 官方仓库安装以确保获取最新版本；Docker Compose V2 已集成到 docker-compose-plugin，使用 `docker compose` 命令 + +## Key Claims (用中文描述) +- Docker 官方仓库安装能确保获取最新版本的 Docker Engine +- Docker Compose V2 通过 docker-compose-plugin 安装，使用 `docker compose` 命令而非 `docker-compose` +- 将用户加入 docker 用户组后，可无需 sudo 直接运行 Docker 命令 +- 必须先安装 ca-certificates 和 curl 才能通过 HTTPS 添加 Docker GPG 密钥和仓库 + +## Key Quotes +> "It's generally best to install from Docker's official repositories to ensure you have the latest version." — 官方仓库安装的最佳实践理由 +> "The `docker-compose-plugin` installs **Docker Compose V2**, which is used via the command `docker compose` instead of `docker-compose`." — V2 版本命令变化说明 +> "By default, running Docker commands requires `sudo`. To run Docker without `sudo`, you can add your user to the **`docker` group`." — docker 用户组的作用 + +## Key Concepts +- [[Docker Engine]]：Docker 核心运行时，包含 dockerd 守护进程、CLI 和 containerd 容器运行时 +- [[Docker Compose]]：多容器 Docker 应用的定义和运行工具，V2 版本集成到 docker CLI（`docker compose`） +- [[APT 仓库]]：Ubuntu/Debian 的软件包管理仓库，通过 /etc/apt/sources.list.d/ 配置 +- [[GPG 密钥]]：apt 仓库签名验证，确保软件包来源可信 +- [[Docker 用户组]]：Linux 用户组，允许组成员无需 sudo 直接运行 Docker 命令（存在安全风险） +- [[containerd]]：Docker 的容器运行时底层引擎，独立项目 + +## Key Entities +- [[Docker CE]]：Docker Community Edition，Docker Engine 的开源版本 +- [[docker-ce-cli]]：Docker 命令行工具 +- [[docker-buildx-plugin]]：Docker 扩展插件，支持多平台镜像构建 +- [[docker-compose-plugin]]：Docker Compose V2 插件，替代独立的 docker-compose 包 +- [[containerd.io]]：containerd 的 Docker 打包版本 +- [[hello-world]]：Docker 官方测试镜像，用于验证安装是否成功 + +## Connections +- [[Docker Engine]] ← installed_by ← [[Docker CE on Ubuntu]] +- [[Docker Compose]] ← extends ← [[Docker Engine]] +- [[APT 仓库]] ← provides ← [[Docker CE]] +- [[GPG 密钥]] ← authenticates ← [[APT 仓库]] +- [[Ubuntu Server]] ← runs_on ← [[Docker Engine]] +- [[Docker 用户组]] ← enables ← [[Docker Engine]] (non-root execution) +- [[containerd]] ← powers ← [[Docker Engine]] + +## Contradictions +- 无已知冲突 + +## Related Sources +- [[用docker安装transmission]] — Docker 部署实战 +- [[用docker安装portainer]] — Docker 可视化管理 +- [[用docker安装jellyfin]] — Docker 媒体服务 +- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] — Docker 监控堆栈 diff --git a/wiki/sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md b/wiki/sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md new file mode 100644 index 00000000..c21a46df --- /dev/null +++ b/wiki/sources/如何用指纹浏览器安全注册并订阅claude-pro会员全攻略.md @@ -0,0 +1,103 @@ +--- +title: "如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略" +type: source +tags: [adspower, claude, ip, pingme, wildcard, 指纹浏览器, 跨境支付] +date: 2025-12-31 +--- + +## Source File +- [[raw/Home Office/如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略.md]] + +## Summary (用中文描述) +- **核心主题**：通过指纹浏览器配合高质量代理IP，在避免账号被封的情况下，安全注册并订阅Claude Pro会员的完整实操攻略 +- **问题域**：跨境AI服务注册封号问题、支付限制问题、手机号验证问题 +- **方法/机制**： + 1. AdsPower指纹浏览器创建隔离浏览器环境 + 2. Socks5代理配置美国IP + 3. IP纯净度检测（Scamalytics低风险） + 4. PingMe接码平台接收短信验证码 + 5. WildCard虚拟信用卡完成跨境支付 +- **结论/价值**：掌握这套方法可有效降低Claude账号封禁风险，稳定使用Claude Pro服务 + +## Key Claims (用中文描述) +- 指纹浏览器通过隔离浏览器环境，能有效减少账号关联和封号风险 +- IP纯净度检测为"低风险"才能使用，中等风险以上会增加封号概率 +- 订阅制接码平台（如PingMe）比一次性号码更稳定可靠 +- WildCard虚拟信用卡支持支付宝充值，是国内用户跨境支付的可行方案 +- AdsPower免费版提供5个指纹浏览器环境，满足大多数多账号需求 + +## Key Quotes +> "指纹浏览器中的'新建浏览器环境'为什么不能使用本地浏览器？本地浏览器和指纹浏览器的环境互不干涉，使用本地浏览器会暴露设备和IP特征，易被关联封号。" + +> "IP纯净度为中等风险，能否保证注册的Claude账号长期不被封？不能，中等风险IP易被平台标记导致封号，应使用低风险IP。" + +> "为什么要使用PingMe平台代替传统短信接码平台？PingMe提供订阅制的美国地区稳定号码，避免一次性号码被封，且充值灵活。" + +## Key Concepts +- [[指纹浏览器]]：可模拟不同设备、网络环境的多账号浏览器，隔离使用环境，减少账号关联风险 +- [[IP纯净度]]：评定某IP是否安全可靠的风险等级，低风险代表良好信誉和较少异常，避免被平台标记 +- [[Socks5代理]]：一种网络代理协议，支持灵活的传输隧道，有助于隐匿真实IP和地理位置 +- [[虚拟信用卡]]：不依赖实体卡的线上信用支付工具，方便海外支付等场景 +- [[接码平台]]：提供短信接码服务的应用或网站，支持接收短消息以完成注册或验证 +- [[账号隔离]]：通过独立浏览器环境和独立IP，防止多个账号被平台识别为关联账号 + +## Key Entities +- [[AdsPower]]：推荐使用的指纹浏览器产品，支持谷歌授权登录，免费版提供5个环境 +- [[PingMe]]：新兴短信接码平台，支持中文界面，需下载App，最低充值2美元 +- [[WildCard]]：虚拟信用卡服务，支持支付宝充值，解决国内用户跨境支付难题 +- [[Claude Pro]]：Anthropic提供的AI聊天工具Pro订阅服务，月费20美元 +- [[Claude]]：Anthropic开发的AI聊天工具，支持Claude 3.5 Sonnet等模型 +- [[Scamalytics]]：IP风险评估网站，用于检测IP纯净度 + +## Connections +- [[指纹浏览器]] ← uses ← [[AdsPower]] +- [[Socks5代理]] ← configured_in ← [[指纹浏览器]] +- [[IP纯净度]] ← checked_by ← [[Scamalytics]] +- [[接码平台]] ← provides ← [[PingMe]] +- [[虚拟信用卡]] ← provides ← [[WildCard]] +- [[Claude Pro]] ← requires ← [[虚拟信用卡]] +- [[Claude]] ← requires ← [[接码平台]] + [[IP纯净度]] + +## Workflow Summary +``` +1. 安装AdsPower指纹浏览器 + ↓ +2. 创建新浏览器环境（Chrome最新版本 + Windows系统） + ↓ +3. 配置Socks5代理（从系统代理复制主机和端口） + ↓ +4. IP纯净度检测（Scamalytics低风险） + ↓ +5. 使用谷歌账号注册Claude + ↓ +6. PingMe接码平台获取美国区验证码 + ↓ +7. WildCard虚拟信用卡订阅Claude Pro +``` + +## Key Misconceptions (易错点) +1. ❌ 使用本地浏览器直接访问Claude → ✅ 必须使用指纹浏览器隔离环境 +2. ❌ 代理IP设置不一致 → ✅ 确保三处IP测试点完全一致 +3. ❌ 忽视IP纯净度检测 → ✅ 必须使用低风险IP +4. ❌ 使用一次性接码号码 → ✅ 使用订阅制接码平台 +5. ❌ 未使用虚拟信用卡 → ✅ 使用WildCard等支持海外支付的虚拟信用卡 + +## Tools & Resources +- **AdsPower下载**: https://share.adspower.net +- **PingMe**: https://messages.pingme.tel/ +- **WildCard**: https://yeka.ai/i/UPHSP +- **IP检测**: https://ip111.cn/ +- **IP纯净度检测**: https://scamalytics.com/ +- **Claude官网**: https://claude.ai + +## Contradictions +- （暂无发现与其他源的冲突） + +## Related Wiki Pages +- [[指纹浏览器]] +- [[IP纯净度]] +- [[虚拟信用卡]] +- [[AdsPower]] +- [[PingMe]] +- [[WildCard]] +- [[Claude Pro]] diff --git a/wiki/sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md b/wiki/sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md new file mode 100644 index 00000000..41d05331 --- /dev/null +++ b/wiki/sources/安装ubuntu-24-04-2在hp-zbook工作站笔记本上.md @@ -0,0 +1,61 @@ +--- +title: "安装Ubuntu 24.04.2在HP ZBook工作站笔记本上" +type: source +tags: [hp, ubuntu, zbook, rufus, uefi] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/安装Ubuntu-24.04.2在HP Zbook工作站笔记本上.md]] + +## Summary (中文) +- **核心主题**：在 HP ZBook 工作站笔记本上安装 Ubuntu 24.04.2 Desktop 的完整实操指南，涵盖启动盘制作、分区配置、BIOS 设置及启动引导修复。 +- **问题域**：HP ZBook 笔记本 + Ubuntu 24.04.2 双系统安装，聚焦 UEFI/GPT 引导环境下的 NVMe 硬盘分区与 HP BIOS 固执行为导致的启动项丢失问题。 +- **方法/机制**： + - Rufus ISOHybrid 镜像写入（ISO 模式优先） + - GPT 分区方案（/boot/efi FAT32, / ext4, /home ext4, swap） + - HP BIOS F9 启动菜单、F10 BIOS 设置 + - efibootmgr NVRAM 写入强制重写 BootOrder + - EFI 默认路径伪装（shimx64.efi → BOOTX64.EFI） + - UEFI Only 模式切换消除 BBS 遗留项 +- **结论/价值**：HP ZBook 等现代 UEFI 工作站安装 Ubuntu 的完整故障排除路线图，核心问题是 HP BIOS 不持久化 NVRAM 启动项；终极解法是切换到 UEFI Only 模式消除 Legacy BBS 项干扰。 + +## Key Claims (中文) +- HP ZBook 必须使用 GPT 分区表配合 UEFI 启动，MBR/Legacy 不适用于现代工作站。 +- ISOHybrid 镜像写入 Rufus 应优先选择"ISO 镜像模式"，DD 模式仅作为启动失败后的备选。 +- HP BIOS 的固执行为（不保存自定义启动项）可通过两种方式绕过：efibootmgr 强制重写 NVRAM，或将引导文件复制到 EFI 默认路径（/EFI/BOOT/BOOTX64.EFI）。 +- UEFI Only 模式是解决 HP ZBook 多余 BBS 遗留项干扰的终极方案，切換后 Boot0000-0004 等 Legacy 项自动消失，BIOS 被迫只识别 Ubuntu 启动项。 + +## Key Quotes +> "HP 的旧款 ZBook 有个'坏习惯'：如果它在 NVRAM 里找不到它认为'标准'的启动项，它会重置 BootOrder。我们可以把 Ubuntu 的引导文件复制到磁盘的默认备用路径。" — HP ZBook 引导伪装大法 + +> "一旦切换为 UEFI Only，那些无效的 0000-0004 就会消失，BIOS 将被迫只看 0005 (Ubuntu)。" — UEFI Only 切换后效果 + +> "Legacy Support (传统支持)：确保设置为 Disabled (或者选择 UEFI Without Legacy)。从你的输出看，你现在有大量的 BBS (Legacy) 启动项，这会干扰 UEFI 的识别。" — 混合模式问题诊断 + +## Key Concepts +- [[GPT分区表]]：现代 UEFI 设备的标准分区方案，支持 2TB+ 硬盘，与 UEFI 引导完美兼容 +- [[efibootmgr]]：Linux 系统下管理 NVRAM 启动项的工具，可强制重写 BootOrder +- [[ISOHybrid镜像]]：同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像，Rufus 提供 ISO/DD 两种写入模式 +- [[UEFI启动修复]]：HP BIOS固执行为导致启动项丢失的解决方案（efibootmgr + 路径伪装 + UEFI Only） +- [[NVMe硬盘分区]]：Ubuntu 24.04 自动识别并优化 NVMe 分区对齐 + +## Key Entities +- [[HP ZBook]]：HP 工作站笔记本，UEFI/F9 启动菜单，F10 进入 BIOS，固执的 BIOS NVRAM 行为 +- [[Rufus]]：开源 U 盘启动盘制作工具，支持 ISOHybrid 镜像写入（ISO 模式推荐） +- [[Ubuntu 24.04]]：LTS 桌面操作系统，默认 ssh.socket 按需激活，支持 NVMe 自动优化 + +## Connections +- [[HP ZBook]] ← 安装目标 ← [[Rufus]]（启动盘制作工具） +- [[efibootmgr]] ← 修复工具 ← [[UEFI启动修复]]（核心手段） +- [[GPT分区表]] ← 分区方案 ← [[NVMe硬盘分区]]（自动对齐优化） +- [[UEFI Only]] ← 终极方案 ← [[HP ZBook]] BIOS固执行为 + +## Contradictions +- **无冲突**：本文档与其他来源一致，未检测到矛盾点。 + +## Related Sources +- [[ubuntu-24-04-enable-ssh]] — Ubuntu 24.04 安装后的 SSH 配置 +- [[ubuntu禁用合盖休眠]] — Ubuntu 24.04 合盖休眠设置 +- [[ubuntu服务器通过rsync实现日常增量备份]] — 安装完成后 rsync 数据恢复建议 +- [[clonezilla对ubuntu-server进行全盘镜像备份]] — 母版镜像制作工具，文中提及 Clonezilla diff --git a/wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md b/wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md new file mode 100644 index 00000000..70ae7120 --- /dev/null +++ b/wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md @@ -0,0 +1,101 @@ +--- +title: "家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox" +type: source +tags: [grafana, monitoring, prometheus, home-server] +date: 2025-11-11 +--- + +## Source File +- [[raw/Home Office/家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor +Blackbox.md]] + +## Summary (中文描述) +- 核心主题：家庭/家居服务器（NAS / Ubuntu Server）的一站式开源监控方案，通过 Docker Compose 快速部署完整的 Prometheus 监控栈。 +- 问题域：如何对家庭服务器的主机层、容器层、服务层（HTTP 可用性、TLS 证书）进行全面的指标采集、存储、可视化和告警。 +- 方法/机制：使用 Prometheus 作为时序数据库和告警规则引擎，node_exporter 采集主机指标，cAdvisor 采集容器资源，blackbox_exporter 做 HTTP/TLS 探测，Grafana 做可视化仪表盘，Alertmanager 分发告警到邮件/Slack。配合 Uptime Kuma 做合成可用性监控。 +- 结论/价值：提供可直接拷贝的 docker-compose 模板、prometheus.yml、alerts.yml、alertmanager.yml，8 步落地路径，涵盖 PoC 验证到生产级部署的全流程。 + +## Key Claims (中文描述) +- Prometheus 通过 pull 模式定期抓取 node_exporter / cAdvisor / blackbox_exporter 暴露的指标，实现主机/容器/网络探测的统一采集。 +- Grafana 可通过 Dashboard ID（如 Node Exporter Full: 1860）直接导入官方仪表盘，快速搭建可视化界面。 +- Blackbox Exporter 通过 `probe_success == 0` 和 `probe_ssl_earliest_cert_expiry` 等指标实现 HTTP 可用性和 TLS 证书到期监控。 +- node_exporter 以 host network 模式运行，挂载 `/proc`、`/sys`、`/` 为只读卷，实现无代理（agentless）主机指标采集。 +- Docker socket 挂载（如 cAdvisor 中的 `/var/run/docker.sock`）是容器监控的必要条件，但需审慎评估安全风险。 +- Alertmanager 支持邮件/Slack/Teams/Webhook/PagerDuty 等多通道告警路由，并提供告警抑制（inhibition）和分组（grouping）功能。 + +## Key Quotes +> "Prometheus 通过 pull 模式定期抓取 exporters 采集指标，支持 PromQL 命名与告警规则。适合做主观测时序库与告警。" — Prometheus 核心机制说明 + +> "Docker socket 挂载（风险：容器拿到宿主机 root 等同权限）。" — 安全警告 + +> "把监控流量/端口放在管理 VLAN 或通过防火墙限定访问。" — 网络安全建议 + +> "Grafana 仪表盘 JSON 导出，Prometheus rule 与配置放在 Git（GitOps）。" — 配置备份最佳实践 + +## Key Concepts +- [[Prometheus]]：开源时序数据库和监控告警系统，支持 PromQL 查询语言和告警规则引擎 +- [[Grafana]]：开源可视化平台，支持多数据源仪表盘和告警管理 +- [[node_exporter]]：Prometheus 官方主机指标采集器，采集 CPU/内存/磁盘/网络/I/O 等系统指标 +- [[cAdvisor]]：Google 开源的容器资源监控工具，为 Prometheus 提供容器级别指标 +- [[blackbox_exporter]]：Prometheus 官方黑盒探测 exporter，支持 HTTP/TCP/ICMP/DNS/TLS 探测 +- [[Alertmanager]]：Prometheus 告警分发组件，支持告警分组、抑制、静默和多通道路由 +- [[PromQL]]：Prometheus Query Language，用于查询时序指标和告警条件 +- [[Uptime Kuma]]：自托管 uptime monitoring 工具，支持 HTTP/TCP/DNS/TLS 合成监控 +- [[Netdata]]：开箱即用的实时主机/容器监控面板，默认 19999 端口，适合快速诊断 +- [[VictoriaMetrics]]：Prometheus 时序数据库替代方案，支持长期存储和高效写入 +- [[合成监控]]（Synthetic Monitoring）：通过模拟真实用户请求检测服务可用性和响应时间 +- [[Exporter]]：Prometheus 生态中负责暴露指标数据的组件，通过 HTTP 端点提供 /metrics +- [[时序数据库]]（Time Series Database）：专门存储带时间戳的指标数据，支持高效的时间范围查询和聚合 +- [[Prometheus告警规则]]：YAML 格式的告警条件定义，基于 PromQL 表达式触发状态变更 + +## Key Entities +- [[Prometheus]]（CNCF 项目）：时序数据库 + 监控告警平台核心 +- [[Grafana Labs]]：Grafana 背后的公司和维护组织 +- [[Docker]]：所有组件的部署平台，通过 Docker Compose 实现一键启动 +- [[Uptime Kuma]]（louislam/uptime-kuma）：开源 uptime monitoring 工具 +- [[Portainer]]：Docker 可视化管理工具，不替代 Prometheus 但便于运维快速操作 + +## Connections +- [[Prometheus]] ← 数据源 ← [[node_exporter]] +- [[Prometheus]] ← 数据源 ← [[cAdvisor]] +- [[Prometheus]] ← 数据源 ← [[blackbox_exporter]] +- [[Grafana]] ← 可视化 ← [[Prometheus]] +- [[Alertmanager]] ← 告警接收 ← [[Prometheus]] +- [[Prometheus]] ← 告警规则 ← [[Prometheus告警规则]] +- [[Grafana]] ← 仪表盘模板 ← [[Node Exporter Full Dashboard]] +- [[Docker Compose]] ← 编排 ← 所有组件（Prometheus / Grafana / Alertmanager / node_exporter / cAdvisor / blackbox_exporter） + +## Contradictions +- 与 [[系统监控工具]]（Btop++ / Htop / Glances / Netdata）相比：Netdata 适合实时短期诊断，Prometheus + Grafana 适合长期存储和趋势分析，两者可互补使用而非互斥。 +- 与 [[ctp-topic-42-grafana-observability-dashboard]] 冲突：该来源标注为 expected（source missing），但内容为 Grafana 在 AWS 场景下的企业级应用；本来源侧重家庭服务器轻量部署，场景和规模不同。 +- 与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] 冲突：OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），Prometheus 生态更成熟但 OpenTelemetry 是未来方向；短期用 Prometheus，长期可考虑 OTel 迁移路径。 + +## Docker Compose 核心架构 +```yaml +# 监控栈组件 +services: + prometheus: # 时序数据库 + 告警引擎 + grafana: # 可视化仪表盘 + alertmanager: # 告警分发 + node_exporter: # 主机指标（host network） + cadvisor: # 容器指标（挂载 /var/run/docker.sock） + blackbox: # HTTP/TCP 探测 +``` + +## 关键监控项（PromQL 示例） +| 指标 | PromQL 表达式 | 阈值 | +|------|--------------|------| +| 磁盘空间 | `node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.10` | < 10% | +| CPU 使用率 | `avg(rate(node_cpu_seconds_total[2m])) * 100 > 85` | > 85% | +| 内存可用 | `node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15` | < 15% | +| HTTP 可用性 | `probe_success == 0` (持续 2min) | 探测失败 | +| TLS 证书到期 | `probe_ssl_earliest_cert_expiry - time() < 86400 * 14` | < 14 天 | + +## 落地 8 步路径 +1. 用 PoC docker-compose 启动 Netdata + Uptime Kuma（19999 / 3001）验证 +2. 上线 Prometheus + prometheus.yml，配置 scrape_configs +3. 每台主机部署 node_exporter（host network 模式） +4. Grafana 导入 Dashboard（1860 / 14282 / 7587） +5. Alertmanager 配置告警路由（邮件/Slack） +6. Uptime Kuma 建好所有内外网探测项 +7. GitOps 配置管理（Grafana JSON 导出，Prometheus rules 放 Git） +8. TLS 证书到期告警（blackbox_exporter 或 Uptime Kuma） diff --git a/wiki/sources/用docker中安装navidrome.md b/wiki/sources/用docker中安装navidrome.md new file mode 100644 index 00000000..855d0061 --- /dev/null +++ b/wiki/sources/用docker中安装navidrome.md @@ -0,0 +1,49 @@ +--- +title: "用Docker中安装Navidrome" +type: source +tags: [docker, music, navidrome] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/用Docker中安装Navidrome.md]] + +## Summary (用中文描述) +- 核心主题：通过 Docker Compose 在 NAS/服务器上部署 Navidrome 音乐服务器 +- 问题域：家庭音乐媒体库管理、跨设备音乐播放、流媒体服务自托管 +- 方法/机制：使用 Docker Compose YAML 配置，挂载 NAS 音乐目录与数据目录，设置环境变量启用转码功能，以非 root 用户运行容器 +- 结论/价值：Navidrome 提供开源、轻量、功能完整的自托管音乐流媒体解决方案，适合家庭媒体中心场景 + +## Key Claims (用中文描述) +- Navidrome 容器通过 `user: "1026:100"` 以非 root 用户身份运行，确保宿主机文件系统权限安全 +- 音乐目录以只读模式（`:ro`）挂载，防止容器误操作修改原始音乐文件 +- 转码缓存限制为 200MB（`ND_TRANSCODINGCACHESIZE=200MB`），保护磁盘空间 +- 启用自动转码下载功能（`ND_AUTOTRANSCODEDOWNLOAD=true`），客户端按需获取合适音质的音乐 + +## Key Quotes +> `ports: - "4533:4533"` — 容器端口映射到宿主机 4533，供局域网访问 +> `volumes: - /volume1/music:/music:ro` — 将 NAS 音乐目录只读挂载到容器内 /music 路径 +> `ND_ENABLETRANSCODINGCONFIG=true` — 在 Web UI 中启用转码配置界面 + +## Key Concepts +- [[Docker Compose]]：多容器 Docker 应用的声明式配置格式 +- [[媒体服务器]]：自托管音乐/视频流媒体服务 +- [[转码缓存]]：按需转码并缓存，保护计算资源与磁盘空间 +- [[只读挂载]]：保护原始文件不被容器修改 + +## Key Entities +- [[Navidrome]]：开源音乐流媒体服务器，Subsonic API 兼容，支持网页与移动客户端 +- [[群晖 NAS]]（Synology NAS）：NAS 存储设备，音乐文件的宿主机 +- [[Deluan/Navidrome]]：Navidrome 官方 Docker 镜像发布者 + +## Connections +- [[群晖 NAS]] ← 存储音乐文件并运行 Docker ← [[Navidrome]] +- [[Jellyfin]] ← 对标竞品媒体服务器 ← [[Navidrome]] +- [[Docker-Image]] ← 基础技术栈 ← [[Navidrome]] + +## Contradictions +- 无已知冲突 + +## Related Sources +- [[用docker安装jellyfin]] — Jellyfin 视频媒体服务器部署笔记，架构类似但服务对象不同（视频 vs 音乐） +- [[家庭网络环境概览]] — 家庭服务器整体网络架构说明 diff --git a/wiki/sources/用docker安装it-tools.md b/wiki/sources/用docker安装it-tools.md new file mode 100644 index 00000000..e5cf5d1e --- /dev/null +++ b/wiki/sources/用docker安装it-tools.md @@ -0,0 +1,48 @@ +--- +title: "用Docker安装it-tools" +type: source +tags: [docker, it-tools] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/用Docker安装it-tools.md]] + +## Summary (用中文描述) +- **核心主题**：使用 Docker Compose 在 Home Server 环境中一键部署 it-tools 开发者工具集合 +- **问题域**：开发者工具匮乏、工具安装繁琐 +- **方法/机制**：通过 Docker Compose YAML 定义服务，使用 `corentinth/it-tools:latest` 镜像，暴露 8999 端口，设置 128MB 内存限制 +- **结论/价值**：提供零配置、可移植的 it-tools 部署方案，实现开箱即用的开发者工具 Web UI + +## Key Claims (用中文描述) +- Docker Compose 通过 `version: '3.8'` 定义服务编排，实现 it-tools 容器化部署 +- it-tools 容器通过 `restart: unless-stopped` 策略确保异常重启后自动恢复 +- 交互模式配置（`stdin_open: true` + `tty: true`）保证容器与终端的标准 I/O 交互能力 +- 内存限制 128MB 足以支持 it-tools Web UI 运行，同时防止资源滥用 + +## Key Quotes +> `8999:80` — 宿主机 8999 端口映射到容器内 80 端口，通过浏览器访问 Web UI + +## Key Concepts +- [[Docker Compose]]：定义多容器 Docker 应用的配置文件格式 +- [[容器资源限制]]：通过 `deploy.resources.limits.memory` 约束容器最大内存使用 +- [[容器重启策略]]：`unless-stopped` 确保容器在 Docker 守护进程启动时自动重启 +- [[端口映射]]：`-p` 标志将宿主机端口与容器端口进行一对一映射 +- [[交互模式容器]]：`stdin_open` + `tty` 组合启用容器的交互式终端能力 + +## Key Entities +- [[it-tools]]：开源开发者工具集合 Web UI，提供 URL 编码/解码、UUID 生成、Cron 表达式解析等实用工具 +- [[corentinth/it-tools]]：it-tools 的官方 Docker 镜像，由 Corentin Th 维护 + +## Connections +- [[it-tools]] ← deployed_via ← [[Docker Compose]] +- [[Docker Compose]] ← dependency ← [[容器资源限制]] +- [[Docker Compose]] ← dependency ← [[容器重启策略]] + +## Contradictions +无 + +## Metadata +- **Author**: shenwei +- **Tags**: docker, it-tools +- **Source**: Home Office diff --git a/wiki/sources/用docker安装transmission.md b/wiki/sources/用docker安装transmission.md new file mode 100644 index 00000000..494935a9 --- /dev/null +++ b/wiki/sources/用docker安装transmission.md @@ -0,0 +1,47 @@ +--- +title: "用Docker安装transmission" +type: source +tags: [docker, transmission, home-office] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/用Docker安装transmission.md]] + +## Summary (用中文描述) +- 核心主题：通过 Docker Compose 在 Home Server 部署 Transmission BT 下载服务 +- 问题域：BT 下载服务容器化部署、Web UI 访问、下载目录管理 +- 方法/机制：使用 linuxserver/transmission 官方镜像，通过 Docker Compose 定义端口映射、环境变量（PUID/PGID/TZ/认证）、卷挂载（配置目录+下载目录）实现一键部署 +- 结论/价值：Transmission 是家庭媒体中心的核心组件，与 Jellyfin/Navidrome 共同构成"下载→整理→播放"媒体工作流 + +## Key Claims (用中文描述) +- LinuxServer.io 维护的 Transmission 镜像通过 docker-compose 一键部署 +- 端口 9091 映射 Web UI 访问，端口 51413/UDP 映射 BT Peer 通信 +- PUID/PGID 环境变量实现容器内进程以宿主机用户权限运行，避免文件权限问题 +- TZ=Etc/UTC 配置容器时区，可根据需要调整为 Asia/Shanghai +- USER/PASS 环境变量启用 Web UI 认证，保护服务安全 + +## Key Quotes +> "image: lscr.io/linuxserver/transmission:latest" — LinuxServer.io 官方维护镜像 +> "network_mode: bridge" — 采用桥接网络模式，与宿主机网络隔离但可访问 +> "restart: unless-stopped" — 容器异常退出后自动重启策略 + +## Key Concepts +- [[Docker Compose]]：YAML 格式定义多容器应用的配置规范，本文档使用 version: '3.8' +- [[Docker Volume]]：持久化存储机制，/config 目录存储配置和下载状态，/downloads 目录挂载宿主下载目录 +- [[PUID/PGID]]：Docker 容器进程以宿主机指定用户运行的环境变量，解决文件权限问题 +- [[端口映射]]：-p host:container 格式将容器端口暴露到宿主机网络 +- [[桥接网络]]：bridge 网络模式下容器共享宿主机网络栈，实现端口映射访问 + +## Key Entities +- [[LinuxServer.io]]：开源 Docker 镜像维护组织，transmission 镜像官方来源 +- [[Transmission]]：开源 BT 下载客户端，Home Server 媒体中心核心组件 +- [[Docker]]：容器化部署平台，本文档使用 docker-compose 管理服务生命周期 + +## Connections +- [[Transmission]] ← deployed_via ← [[Docker Compose]] +- [[Docker]] ← network_mode ← [[桥接网络]] +- [[Transmission]] ← upstream_image ← [[LinuxServer.io]] + +## Contradictions +- 无冲突；与 [[用Docker安装jellyfin]] 形成互补（jellyfin=播放，transmission=下载，共同服务于家庭媒体中心工作流） diff --git a/wiki/sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md b/wiki/sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md new file mode 100644 index 00000000..5a0d9af9 --- /dev/null +++ b/wiki/sources/网件rax50路由器刷梅林固件与科学上网插件安装教程.md @@ -0,0 +1,64 @@ +--- +title: "网件RAX50路由器刷梅林固件与科学上网插件安装教程" +type: source +tags: [clash, merlin-clash, rax50, 科学上网, 路由器固件] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/网件RAX50路由器刷梅林固件与科学上网插件安装教程.md]] + +## Summary (用中文描述) +- 核心主题：网件RAX50路由器刷入梅林固件并安装配置科学上网插件的完整实操教程 +- 问题域：家庭网络翻墙环境搭建、路由器固件定制、代理插件配置 +- 方法/机制：通过二次刷机（.chk过渡固件 → .w正式固件）完成梅林固件安装；通过MerlinClash插件实现策略组分流转发；通过订阅机制管理机场节点；通过JFFS双清确保固件环境干净 +- 结论/价值：提供了一套完整的"路由器官网固件 → 梅林固件 → 科学上网插件"的链路，适合家庭用户建立全屋翻墙网络 + +## Key Claims (用中文描述) +- 网件路由器必须通过`.chk`过渡固件才能刷入梅林固件，直接刷`.w`固件会失败 +- JFFS双清操作用于清理路由器文件系统缓存，刷机后执行可确保固件环境干净无残留 +- MerlinClash插件支持策略组配置，实现基于应用、地区和服务的自动分流和节点故障转移 +- 两款科学上网插件（MerlinClash与GitHub版本）不可同时开启，推荐使用功能更强的MerlinClash +- 恢复出厂设置指的是梅林固件的默认配置，不会恢复网件原厂系统 + +## Key Quotes +> "必须先刷`.chk`的过渡固件，再刷`.w`的正式梅林固件，二次刷机才能确保稳定" — 刷机顺序的核心原则 + +> "通过策略组配置不同节点和规则，实现基于应用、地区和服务的自动分流和节点故障转移" — MerlinClash的分流机制 + +> "JFFS双清是清理文件系统和缓存，通常刷机后执行，确保固件环境干净无旧数据残留" — JFFS双清的作用说明 + +> "访问Google和YouTube等被屏蔽网站，能成功打开说明科学上网成功" — 科学上网成功的判断标准 + +## Key Concepts +- [[固件刷入]]：将第三方固件写入路由器闪存以替换原厂固件的过程，RAX50需要两次刷机（过渡+正式） +- [[过渡固件]]：用于引导原厂路由器进入可刷入目标固件状态的中间固件，`.chk`格式为网件专用过渡固件 +- [[JFFS双清]]：清理路由器JFFS分区（文件系统）和缓存的操作，用于刷机后重置干净环境 +- [[策略组分流]]：基于预定义规则（地区/应用/网站）对流量进行分类并转发到不同代理节点的机制 +- [[故障转移]]：当主代理节点连接失败时自动切换到备用节点以保持网络通畅的机制 +- [[订阅机制]]：通过机场提供的订阅链接自动获取和更新代理节点列表，无需手动配置 + +## Key Entities +- [[网件RAX50]]：NETGEAR AX3000双频WiFi 6路由器，型号Nighthawk RAX50，支持梅林固件 +- [[梅林固件]]：华硕路由器第三方改良固件，由Eric Sauvageau开发，支持更多插件和高级网络功能 +- [[MerlinClash插件]]：基于Clash核心的梅林固件代理插件，支持策略组、自动节点选择、分流规则和守护进程 +- [[KoolCenter固件服务器]]：提供梅林固件下载的服务器平台，包含华硕和网件路由器对应的固件版本 +- [[机场]]：提供代理节点订阅服务的服务商，用户通过订阅链接导入节点配置 + +## Connections +- [[网件RAX50]] ← 硬件平台 ← [[梅林固件]] +- [[梅林固件]] ← 扩展能力 ← [[MerlinClash插件]] +- [[MerlinClash插件]] ← 依赖 ← [[机场]]（订阅节点来源） +- [[科学上网]] ← 技术手段 ← [[策略组分流]] +- [[科学上网]] ← 技术手段 ← [[故障转移]] + +## Contradictions +- 与 [[群晖NAS科学上网方法]] 冲突： + - 冲突点：科学上网部署位置 + - 当前观点：本教程通过路由器层面实现全屋统一翻墙，所有设备无需单独配置 + - 对方观点：NAS科学上网仅服务于NAS本身或特定容器，客户端设备仍需单独配置代理 + +- 与 [[ubuntu-server科学上网]] 冲突： + - 冲突点：科学上网的部署层级 + - 当前观点：路由器作为网关统一处理翻墙流量，对终端设备透明 + - 对方观点：服务器端VPN/V2Ray服务需要每个客户端主动连接 diff --git a/wiki/sources/通过vps-内网反向代理实现域名访问内网穿透.md b/wiki/sources/通过vps-内网反向代理实现域名访问内网穿透.md new file mode 100644 index 00000000..fc868093 --- /dev/null +++ b/wiki/sources/通过vps-内网反向代理实现域名访问内网穿透.md @@ -0,0 +1,89 @@ +--- +title: "通过VPS+内网反向代理实现域名访问内网穿透" +type: source +tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, 内网穿透] +date: 2026-04-14 +--- + +## Source File +- [[raw/Home Office/通过VPS+内网反向代理实现域名访问内网穿透.md]] + +## Summary (用中文描述) +- 核心主题：通过 VPS + frp + Caddy 实现内网服务的公网域名访问（内网穿透） +- 问题域：家庭网络内网服务（NAS、Ubuntu 服务器）无法直接被公网访问的问题 +- 方法/机制：frp 反向隧道（frps 服务端 + frpc 客户端）+ Caddy 反向代理 + Let's Encrypt 自动 HTTPS +- 结论/价值：建立完整的内网服务公网访问架构，支持 NAS n8n Grafana 等多服务通过独立子域名访问 + +## Key Claims (用中文描述) +- frp 专为内网穿透设计，支持 NAT 穿透、自动重连、Web 管理面板（可选） +- VPS 上的 Caddy 反向代理到 frps 映射端口（127.0.0.1:xxxxx），提供 HTTPS 访问 +- SSH 穿透与 HTTP 不同，SSH 是纯 TCP 流量不经过 Caddy，只用 frps + frpc 配置即可 +- frps 监听 7000 端口，dashboard 可选监听 7500 端口 + +## Key Quotes +> "frp 优点：专为内网穿透设计，支持 NAT、自动重连、Web 管理面板（可选）。推荐当你有多台设备和多端口时使用。" — frp 核心优势说明 + +> "SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 穿透的关键区别 + +## Key Concepts +- [[内网穿透]]：通过公网 VPS 建立反向隧道，使内网服务可被公网访问的技术 +- [[反向代理]]：VPS 上的 Caddy 将公网请求代理到 frp 映射的本地端口 +- [[TCP 隧道]]：frp 建立的 TCP 端口映射隧道，连接内网服务与公网 VPS +- [[Let's Encrypt]]：Caddy 自动申请的免费 SSL 证书提供商 + +## Key Entities +- [[frp]]：内网穿透工具，包含 frps（服务端）和 frpc（客户端）两个组件 +- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器 +- [[阿里云 DNS]]：域名 ishenwei.online 的 DNS 解析服务提供商 +- [[VPS]]：公网服务器（192.227.222.142），运行 frps 和 Caddy 作为反向代理中转站 + +## Connections +- [[内网穿透]] ← uses ← [[frp]] +- [[反向代理]] ← uses ← [[Caddy]] +- [[反向代理]] ← depends_on ← [[TCP 隧道]] +- [[VPS]] ← hosts ← [[frp]] +- [[VPS]] ← hosts ← [[Caddy]] +- [[群晖 NAS]] ← accessed_via ← [[内网穿透]] + +## Domain Mapping (本方案配置) +| 域名 | 内网服务 | 映射端口 | +|------|---------|---------| +| nas.ishenwei.online | NAS Web UI | 192.168.3.17:5000 → VPS:15000 | +| n8n.ishenwei.online | Ubuntu n8n | 192.168.3.47:5678 → VPS:15678 | +| transmission.ishenwei.online | Ubuntu Transmission | 192.168.3.47:9091 → VPS:19091 | +| grafana.ishenwei.online | Ubuntu Grafana | 192.168.3.47:3000 → VPS:13000 | +| ubuntu1.ishenwei.online:60022 | Ubuntu SSH | 192.168.3.47:22 → VPS:60022 | + +## Architecture Diagram +``` +Internet + │ + ▼ +┌─────────────────────────────────────┐ +│ VPS (192.227.222.142) │ +│ - frps (监听 7000) │ +│ - Caddy (80/443 TLS) │ +│ ├─ nas.ishenwei.online → 127.0.0.1:15000 +│ ├─ n8n.ishenwei.online → 127.0.0.1:15678 +│ └─ transmission.ishenwei.online → 127.0.0.1:19091 +└─────────────────────────────────────┘ + ▲ ▲ + │ frp tunnel │ frp tunnel +┌────────────┐ ┌────────────┐ +│ NAS (192.168.3.17) │ │ Ubuntu (192.168.3.47) │ +│ frpc.ini │ │ frpc.ini │ +│ 映射5000→15000 │ │ 映射5678→15678 │ +└────────────┘ └────────────┘ +``` + +## Contradictions +- 无 + +## Troubleshooting Summary +1. 确认 frps 是否监听端口：`ss -lntup | grep 7000` +2. 确认进程读取的配置：`ps -ef | grep frps` +3. 确认防火墙放行：`sudo ufw status` +4. 确认没有 Caddy/Nginx 占用端口 +5. 确认 token 一致性：`journalctl -u frps -n 100` +6. telnet 诊断：`telnet 192.227.222.142 7000` +7. 重启服务：`systemctl restart frps && systemctl restart frpc` diff --git a/wiki/内网穿透.md b/wiki/内网穿透.md new file mode 100644 index 00000000..0723fb03 --- /dev/null +++ b/wiki/内网穿透.md @@ -0,0 +1,122 @@ +--- +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 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/ diff --git a/wiki/反向代理.md b/wiki/反向代理.md new file mode 100644 index 00000000..bb92e1c7 --- /dev/null +++ b/wiki/反向代理.md @@ -0,0 +1,149 @@ +--- +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/ diff --git a/wiki/桥接网络.md b/wiki/桥接网络.md new file mode 100644 index 00000000..a59a99b6 --- /dev/null +++ b/wiki/桥接网络.md @@ -0,0 +1,47 @@ +# 桥接网络 + +## Type +- Concept + +## Definition +桥接网络（Bridge Network）是 Docker 的默认网络模式，每个容器连接到宿主机上的 `docker0` 网桥，容器之间通过内部 Docker 网络通信，外部流量通过端口映射（-p）访问。 + +## Mechanism + +### 工作原理 +``` +宿主机网络 + ↓ +docker0 网桥 (172.17.0.1) + ├── 容器A (172.17.0.2) ←→ 容器B (172.17.0.3) + └── 容器C (172.17.0.4) +``` + +### Docker Compose 配置 +```yaml +network_mode: bridge # 使用 Docker 默认桥接网络 +``` + +### 与 host 网络模式对比 +| 特性 | bridge（桥接） | host（主机） | +|------|---------------|-------------| +| 网络命名空间 | 独立 | 共享宿主机 | +| 端口映射 | ✅ 支持 | ❌ 被忽略 | +| 网络隔离 | ✅ 容器间隔离 | ❌ 无隔离 | +| 性能 | 轻微NAT开销 | 最优（直接访问） | +| 适用场景 | Web服务、数据库 | 网络监控、代理 | + +## Key Claims +- bridge 模式是 Docker 默认网络模式，无需显式配置 +- 容器通过 docker0 网桥与宿主机和互联网通信 +- 端口映射（-p）在 bridge 模式下生效，将容器端口暴露到宿主机 +- 容器间通过 DNS 自动解析服务名通信（同 docker-compose 服务名） + +## Relationship to [[端口映射]] +[[端口映射]] 是桥接网络模式的核心能力——通过 iptables NAT 规则将容器端口转发到宿主机，实现外部访问。 + +## Relationship to [[LinuxServer.io]] +LinuxServer.io 所有官方 Docker 镜像默认使用 `network_mode: bridge`，这是其标准化配置模式的一部分，确保端口映射正常工作。 + +## Sources +- [[用docker安装transmission]] diff --git a/wiki/端口映射.md b/wiki/端口映射.md new file mode 100644 index 00000000..33de8277 --- /dev/null +++ b/wiki/端口映射.md @@ -0,0 +1,43 @@ +# 端口映射 + +## Type +- Concept + +## Definition +端口映射（Port Mapping）是 Docker 容器网络配置的核心机制，通过 `-p host:container` 语法将容器内部端口暴露到宿主机网络，使得外部流量可以通过宿主机 IP:端口 访问容器内的服务。 + +## Mechanism + +### 基本语法 +```yaml +ports: + - "9091:9091" # host:container（TCP） + - "51413:51413/udp" # 支持协议指定 +``` + +### 映射规则 +| 格式 | 说明 | 适用场景 | +|------|------|---------| +| `host:container` | 指定宿主机和容器端口 | 生产环境 | +| `host:container/protocol` | 指定协议（TCP/UDP） | BT下载、语音等 | +| `:container` | 宿主机随机端口 | 开发环境 | +| `host-ip:host:container` | 绑定特定IP | 多网卡服务器 | + +## Key Claims +- Docker 通过 iptables 规则在宿主机层面实现端口映射转发 +- 桥接网络（bridge）模式下端口映射生效；host 网络模式下端口映射被忽略 +- 容器重启后端口映射保持（配置持久化在 Docker daemon） +- 宿主机端口冲突会导致容器启动失败 + +## Relationship to [[桥接网络]] +端口映射是 [[桥接网络]] 模式的核心功能： +- **host 网络模式**：容器直接共享宿主机网络命名空间，端口映射无效（服务直接在宿主机端口监听） +- **bridge 网络模式**（默认）：容器有独立网络命名空间，通过 NAT 规则实现端口映射访问 + +## Relationship to [[Transmission]] +Transmission 依赖端口映射实现两个关键功能： +- Web UI 访问：`9091:9091` → 用户通过浏览器访问 http://host:9091 +- BT Peer 通信：`51413:51413` + `51413:51413/udp` → 其他BT客户端发现并连接 + +## Sources +- [[用docker安装transmission]]