[备忘] 运维参考手册

本文是个人服务运维的唯一参考源，不是教程。所有记录以此刻实际情况为准，每次改基础设施必须同步更新这里，否则下次出事你就等着对着半年前的配置挠头吧。

0x00 操作系统与初始配置

操作系统标准

新机器统一装服务商提供的最新 Debian 稳定版。现在能买到的机器，要么 Debian 13，要么 Debian 12。优先级：

1. Debian 13（首选，能用新的就别用旧的）
2. Debian 12（备选，部分服务商模板更新慢）
3. 连 Debian 12 都提供不了的厂商直接拉黑

装机后必做清单

拿新机器第一步：

# 1. 主机名 & hosts
hostnamectl hostname <name>
echo "127.0.1.1 <fqdn> <hostname>" >> /etc/hosts

# 2. 时区 & NTP
timedatectl set-timezone Asia/Shanghai
timedatectl set-ntp true

# 3. 基础包
apt-get update && apt-get install -y curl wget git vim sudo htop net-tools \
  dnsutils ca-certificates

# 4. SSH 加固

# 5. 防火墙
ufw default deny incoming
ufw default allow outgoing
ufw limit 55822/tcp
ufw enable

# 6. 换源
# 见 0x0C 章节

# 7. BBR
sysctl net.ipv4.tcp_congestion_control

# 8. 装 Docker
# 见 0x06 章节
# 部分机器可跳过

这 8 步做完机器才算达到上线标准。缺任何一步都不要往上面跑服务。

Homelab 物理服务器

配置如下：

SSH 配置

文件：/etc/ssh/sshd_config

密钥路径：~/.ssh/authorized_keys

防火墙规则

管理工具：ufw（有在想迁到 nftables，但目前 ufw 除了难用和傻逼没出过问题，所以优先级不高）

其余端口由 Docker iptables 集成或反向代理负责放行。ufw 只管主机层面的出入口，应用层面交给反代和 WAF。

内核参数

# /etc/sysctl.d/99-bbr.conf
# BBR 拥塞控制 —— 新内核默认就有
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

# /etc/sysctl.d/98-conntrack.conf
# conntrack 表容量 —— 默认 65536 对大多数场景够用
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_buckets = 65536

日常管理

• 系统更新：

  apt update && apt upgrade -y && apt autoremove -y

  每月至少跑一次。内核更新后需要重启，别忘了。

• 日志轮转：目前各服务自己管自己的日志，没有统一方案。Docker 容器日志建议加 --log-opt max-size=10m --log-opt max-file=3 配置在 compose.yml 里，不然 /var/lib/docker 迟早撑爆。

• 查看磁盘：

  df -h
  du -sh /var/lib/docker  # 这个目录最容易暴涨
  
  docker system prune -a  # 快速清理 Docker

• 查实时连接：

  ss -tunp
  lsof -i
  
  # 计数
  ss -s

0x01 命名规范

主机命名规则

格式：[分组-]国家-类型-标识符

• 分组（可选）：环境或项目前缀（prod、dev、infra）
• 国家：ISO 3166-1 二位国家代码（us、jp、de、sg）
• 类型：虚拟化方式（systemd-detect-virt 输出值，如 kvm、lxc）
• 标识符：服务商缩写（≤5 字符，如 vultr、buyvm）

示例：infra-us-kvm-vultr、prod-jp-kvm-ali

这套规则最大的价值：看名字就知道机器在哪、跑在什么上面、是谁家的。出事了随手 ssh hostname 不用翻笔记。

标签规范

0x02 DNS 管理

托管商

域名分散托管于多家主流 DNS 提供商：

• Cloudflare — 主力 DNS，大部分网站通过 CF 代理
• Aliyun DNS — 傻逼
• 华为云 DNS — 大部分有合规要求的域名
• 腾讯云 DNSPod — 懒得改 NS 的域名
• 火山引擎 TrafficRouter — 没啥用的 100% SLA
• AWS Route53 — 部分业务
• Google Cloud DNS — 部分业务

分散托管的原因：鸡蛋不放一个篮子里，单家出问题不影响所有域名解析。代价是管理复杂度增加了，所以必须上 DNSControl 等 IaC 方案。

Zone 管理

• 管理工具：DNSControl
• 配置仓库：https://git.6l.ink/liuzhen932/dns（私有仓库）
• 自动化：Forge Actions 触发

工作流程：

1. 修改 DNSControl 配置（dnsconfig.js）
2. 提交到 Git
3. Forge Actions 自动执行 dnscontrol push 同步到各 DNS 服务商

禁止手动在 DNS 面板修改记录，否则不一致将造成服务停机

DDNS

• 客户端：ddns-go（默认端口 9876）
• 部署方式：Docker
• 适用场景：动态 IP 的机器

ddns-go 的 Web 管理界面很直观，配好之后自动轮询公网 IP 变化并更新 DNS 记录。接入多个 DNS 提供商也支持。

0x03 SSL/TLS 证书续签方案

ACME 客户端

ACME 账户邮箱：tls#932.moe

Caddy 自动续期

Caddy 的 ACME 客户端是内置的，只要有：

example.com {
    reverse_proxy 172.17.0.1:8080
}

Certimate 管理

对于不用 Caddy 的服务（OpenResty、自建 API 等），用 Certimate 编排：

1. 证书申请（支持 HTTP-01 / DNS-01 challenge）
2. 证书保存
3. 自动部署到目标服务器（通过 SCP / API / 文件写入等方式）

0x04 BGP 路由策略

资源

Upstream

对等 ASN

除上行和 IXP 成员外，还维持了少量直接对等：

其他都不认识。

社区标记

用于路由策略标记：

BIRD2 配置

托管于私有仓库：https://git.6l.ink/liuzhen932/as213891.conf

BIRD 配置用 Git 管理最大的好处是回滚。某次改策略把路由搞崩了，git revert 然后 birdc configure，没有版本控制的配置就是定时炸弹。

运维

# 查看 BGP 会话状态
birdc show protocols

# 查看路由表
birdc show route

# 重新加载配置（不中断会话）
birdc configure

# 查看特定前缀的传播情况
birdc show route for 2a0e:aa07:e150::/44 all

0x05 OID 分配表

• 根 OID：1.3.6.1.4.1.64517
• 用途：SNMP 监控的自定义 OID，暂只注册了根节点

目前没有用 SNMP 监控任何东西，Prometheus 生态更香。

0x06 容器与编排

运行环境

Docker 安装脚本

curl -fsSL https://get.docker.com | sh

容器化服务清单

所有自定义镜像托管于 docker.io/liuzhen932/*，私有镜像除外。

反向代理

网络 & 隧道

BGP & 网络监控

Compose 配置规范

所有服务统一目录结构：

/opt/<项目名>/
├── compose.yml      # 服务定义
├── .env             # 环境变量
└── data/            # 持久化数据

日志配置

每个 compose.yml 里建议加上：

services:
  app:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

更新策略

• 镜像更新检测：Diun（监控 Docker Hub / GHCR 的镜像更新）
• 实际操作：手动执行

cd /opt/<项目名>
docker compose pull && docker compose up -d

为什么不全自动更新？全自动滚动更新一旦出问题很难定位。个人运维场景，手动跑一条命令比半夜被告警吵醒划算。Diun 负责通知你有新版本，收到通知后挑个方便的时间手动更新。

Docker daemon 配置

// /etc/docker/daemon.json
{
  "features": { "buildkit": true },
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

全局限制日志大小，防止日志撑爆磁盘。

0x07 端口与服务映射

公网入站

其余端口（如各服务管理端口）按需放行，但只对特定来源 IP 开放。基本原则：默认全关，按需放行。

反向代理

OpenResty 负责主要流量的反向代理和 WAF；Caddy 负责次要服务和新项目的快速部署，优势是零配置 HTTPS。

Tailscale

Tailscale 作为运维通道使用，不暴露到公网：

Tailscale 最大的价值：不管机器在哪个国家、有没有公网 IP、NAT 类型是什么，只要它能联网，Tailscale 就能把它拉进你的网络。IPv4 NAT 后面裸 SSH ？还是 Tailscale 吧。

0x08 关键服务备忘

邮件

没有自建邮件服务器。自建邮件是运维界公认的深坑——IP 信誉、反 spam 配置、DKIM/SPF/DMARC、各大厂商拒收……为个人博客搞一套不值当。

CI/CD

自动化流水线：

• DNS 发布：提交 DNSControl 配置 → 自动 dnscontrol push
• Docker 构建：提交 Dockerfile → 自动构建并 push 到 Docker Hub
• 博客发布：提交文章 → 自动构建并部署

日志

日志是出事之后唯一的上帝视角。平时没人看，但真出问题了没日志你连从哪查起都不知道。

现状：ELK 和 OpenObserve 已经部署，但还没把所有服务的日志都接入。持续完善中。

0x09 数据持久化与备份

重要数据路径

所有持久化数据都在各服务的 /opt/<项目名>/ 目录下：

/opt/<项目名>/
├── compose.yml    # 服务定义
├── .env           # 环境变量
├── data/          # 数据库、文件存储等持久化数据
└── config/        # 配置文件（如果是卷映射出来的）

备份现状

这个是最大短板。云 VPS 上的数据目前没有统一备份方案。理论上服务商有快照功能，但快照不是备份——机房起火你的快照也跟着烧了。TODO：restic 覆盖所有云 VPS。

Restic 备份命令（快速参考）

# 初始化仓库
restic init --repo s3:https://<endpoint>/<bucket>

# 创建快照
restic --repo <repo> backup /opt

# 查看快照
restic --repo <repo> snapshots

# 恢复
restic --repo <repo> restore latest --target /

凭据存储

跟凭据有关的核心原则：.env 文件不入库。compose.yml 里用 ${VAR} 引用环境变量，.env 写本地 .gitignore 里。不小心 push 了密钥怎么办？一个字：换。

0x0A 监控与告警

监控栈

告警渠道

ntfy 是真的好用。手机装个 App，收到告警推送直接点开看。比邮件快，比 QQ 稳定，而且不依赖国内生态。

关键告警阈值

告警处理流程

1. 收到告警 → 确认告警真实性（不是误报）
2. 如果是误报 → 调优告警规则，避免下次再误报
3. 如果是真问题 → 按 SOP 处理
4. 处理完 → 记录到本文的对应章节
5. 如果是同类问题第二次出现 → 考虑自动化修复

0x0B 安全防护

WAF — 两层防护

Cloudflare WAF 挡掉大部分常见攻击流量（SQL 注入、XSS、路径遍历等）。但不要把安全全押在 CF 上——

为什么源站还要 WAF：CF 不是万能的。有些人直接扫源站 IP 绕过 CDN，或者你的服务有一部分没走 CF（API 直连、非 Web 服务等）。源站 WAF 是最后一道防线。

fail2ban & CrowdSec

两者的区别：fail2ban 只管自己机器上的日志；CrowdSec 有社区威胁情报网络，一台机器发现恶意 IP 会同步给其他用户。

实际效果：fail2ban 主要是挡住了 SSH 扫描脚本。CrowdSec 的数据更有价值，能识别到一些普通的 WAF 规则没挡住的异常请求模式。

登录审计

# 近期 SSH 登录记录
last -n 20

# sudo 执行记录
journalctl -t sudo --since "7 days ago"

# 所有登录失败的 IP
lastb | awk '{print $3}' | sort | uniq -c | sort -rn | head -10

# 当前登录用户
who

SSH 日志是安全排查的第一站。lastb 看暴力破解的来源，last 看有没有陌生 IP 成功登录。

0x0C 软件源/镜像加速

apt

大厂内网的机器用服务商提供的内部镜像源（延迟最低，带宽不限），其余机器统一用 中科大 USTC 镜像。

# /etc/apt/sources.list — USTC 镜像（Debian 12 Bookworm）
deb https://mirrors.ustc.edu.cn/debian/ bookworm main contrib non-free
deb https://mirrors.ustc.edu.cn/debian-security bookworm-security main contrib non-free
deb https://mirrors.ustc.edu.cn/debian/ bookworm-updates main contrib non-free

Debian 13（Trixie）发布后把 bookworm 替换为 trixie 即可。

pip

# ~/.pip/pip.conf
[global]
index-url = https://mirrors.ustc.edu.cn/pypi/web/simple
trusted-host = mirrors.ustc.edu.cn

npm

npm config set registry https://mirrors.ustc.edu.cn/npm/

Docker

Docker 镜像源在 daemon.json 里配置，但目前没配国内的 mirror。在大陆的机器可能 pull 得慢，考虑加一行 "registry-mirrors": ["https://docker.mirrors.ustc.edu.cn"]。

USTC 镜像是目前国内最靠谱的开源镜像站之一，维护团队靠谱、更新及时、容量够大。清华 TUNA 也可以做备选。

0x0D 续费与到期日历

域名

30 多个域名分散在多家注册商，这就是个管理噩梦。目前靠邮箱收续费提醒，真漏了一个就完了。TODO：搞个域名管理看板或脚本，统一监控到期日。

VPS / 服务器

各厂商续费策略：大部分按年付（便宜）、少数按月付。

VPS 续费没有统一的日历管理。到期的钱不多，但忘了续导致服务停摆就尴尬了。目前靠手机日历设提醒。

SSL 证书

全部 Let’s Encrypt，Caddy 和 Certimate 自动续期。没有手动过期风险，只需要确保 ACME 客户端正常运行。

0x0E GitOps / IaC 速查

配置仓库

部署流程

# DNS 变更
修改 dnsconfig.js → git push → Forge Actions 自动 dnscontrol push

# BGP 变更
修改 bird.conf → git push → 登录机器 → birdc configure

# 服务更新
cd /opt/<项目名>
docker compose pull
docker compose up -d

# 配置文件更改
修改 compose.yml 或 config 文件 → docker compose up -d（重建容器）

敏感文件管理

原则：所有敏感信息都不进 Git。.env 和 compose.yml 里的明文密码只用在 homelab 内网机器上，云 VPS 上必须用 Infisical 或环境变量注入。

0x0F 服务依赖关系

启动顺序

数据库（PostgreSQL / MySQL / SQLite）
  → 后端服务（API / Web 应用）
    → 反向代理（Caddy / OpenResty）
      → 监控（Prometheus / Grafana / AlertManager）

反过来，关机顺序：监控 → 反代 → 后端 → 数据库。

故障影响矩阵

0x10 灾难恢复 SOP

服务器完全挂了的恢复步骤

1. 从提供商控制台进入救援模式（Rescue Mode / Live CD）
2. 挂载系统盘 mount /dev/sdaX /mnt
3. 检查文件系统 fsck /dev/sdaX
4. 从备份恢复 /opt 目录数据 restic --repo <repo> restore latest --target /mnt/opt
5. 重装系统（同版本 Debian）
6. 执行装机后必做清单（见 0x00）
7. 安装 Docker
8. 恢复 compose.yml 和 .env
9. docker compose up -d 恢复所有服务
10. 验证各服务正常运行

恢复后的验证清单

# 1. SSH 能登
ssh -p 55822 root@<host>

# 2. 反代正常运行
curl -I https://<domain>

# 3. 数据库连接正常
docker compose exec db pg_isready  # PostgreSQL 为例

# 4. 备份已恢复
restic --repo <repo> snapshots

# 5. 监控正常
curl http://localhost:9090/api/v1/query?query=up

# 6. DNS 解析正常
dig <domain>

离线入口

灾难恢复最重要的是恢复前想清楚先恢复什么。数据库 → 反代 → 服务，按这个顺序恢复最快能让用户访问到服务。不要试图把所有服务同时恢复，先让核心业务跑起来，其他的慢慢来。

预防性措施

除了这条文档本身，以下措施能显著减少灾难恢复的工作量：

1. 所有 compose.yml 放在 Git 仓库里
2. 关键配置截图/存一份离线备份
3. 定期做恢复演练
4. 多地域备份
5. 备份失败要有告警