很多人用「网盘同步」「RAID 1」「rsync 镜像」当备份，这些方案有一个共同的盲区：它们忠实地复制错误。
真正的备份必须能回答：「我想回到三天前的那个版本」——这需要历史版本和不可变性，是同步类方案给不了的。
经典的备份策略只有一句话：
对一台个人云服务器，可落地的组合是：本地快照（快速恢复）+ 异地对象存储（灾难恢复）。成本不过每月几元，换来的是睡得着觉。
rsync 是增量传输的瑞士军刀，适合做本机或内网的快速备份层：
rsync -avz --delete \
--exclude={'/dev/*','/proc/*','/sys/*','/tmp/*'} \
/var/www/ /backup/www-$(date +%F)/
关键参数：
-a 归档模式（保留权限、时间戳、软链）-v -z 显示过程、传输压缩--delete 让目标与源一致（用前想清楚：源目录误删会同步到备份，这就是它只能算「快照」不能算唯一备份的原因）配合 --link-dest 可以实现「占空间很小的每日全量快照」：未变化的文件用硬链接共享同一份数据，每天一个目录却几乎不占额外空间。
数据库备份注意：不能直接 rsync 数据目录——运行中的数据库文件处于不一致状态。正确顺序是先导出逻辑备份：
# PostgreSQL
pg_dump -U myapp myapp | gzip > /backup/db/myapp-$(date +%F).sql.gz
# MySQL
mysqldump --single-transaction -u myapp -p myapp | gzip > /backup/db/myapp-$(date +%F).sql.gz
（--single-transaction 对 InnoDB 做一致性快照导出，不锁表。）
restic 是现代备份工具的代表：增量去重、端到端加密、支持 S3 兼容存储，一份数据加密后才离开服务器——就算存储端被攻破，攻击者拿到的也是密文。
初始化仓库（以 S3 兼容对象存储为例）：
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx
export RESTIC_PASSWORD=备份仓库的加密口令
restic -r s3:https://s3.example.com/mybucket/backups init
日常备份一条命令：
restic -r s3:https://s3.example.com/mybucket/backups \
backup /var/www /etc /backup/db \
--exclude-file /etc/restic/excludes
restic 每次备份生成一个快照，自动去重——重复备份 100 GB 数据，第二次只传变化的部分。
保留策略：旧快照不是无限留的，按策略清理：
restic -r s3:... forget --prune \
--keep-daily 7 --keep-weekly 4 --keep-monthly 6
保留最近 7 个日备份、4 个周备份、6 个月备份，其余删除并回收空间。
定时化：把备份命令写成脚本，用 cron 或 systemd timer 每天凌晨执行，并把结果输出到日志，纳入监控告警——「备份任务失败」必须是一条会叫醒人的告警，静默失败的备份等于没有备份。
没恢复过的备份只能算「愿望」。restic 的恢复：
# 列出快照
restic -r s3:... snapshots
# 恢复指定快照到临时目录（先在临时位置验证，别直接覆盖生产）
restic -r s3:... restore latest --target /tmp/restore-check
# 只取回单个文件
restic -r s3:... dump latest /var/www/config.yml > config.yml
建议每季度做一次完整演练：把备份恢复到一台干净的机器，验证应用真的能跑起来。演练会暴露各种想当然——比如备份里漏了某个关键目录、数据库导出脚本早就因为密码轮换而失败。
pg_dump/mysqldump 导出数据库到本地目录。这套方案全部用开源工具和对象存储搭建，月成本一杯咖啡钱，换的是任何单点事故都不致命的底气。
安全组是云平台的虚拟防火墙，规则在系统之外生效——就算系统内防火墙没配，安全组也能兜底。原则：默认全拒，按需放行。
一台 Web 服务器的典型放行清单：
| 端口 | 来源 | 用途 |
|---|---|---|
| 22（或自定义 SSH 端口） | 你的办公/家庭 IP 段 | SSH 管理 |
| 80 | 0.0.0.0/0 | HTTP（跳转 HTTPS 及证书验证） |
| 443 | 0.0.0.0/0 | HTTPS |
数据库 3306、Redis 6379、管理面板端口永远不要对公网开放，内部访问走 VPC 内网。SSH 来源限制为固定 IP 段是性价比最高的一条规则，直接砍掉 99% 的爆破流量。
adduser deploy
usermod -aG sudo deploy # Debian/Ubuntu；RHEL 系是 wheel 组
此后所有日常操作用 deploy 登录，需要特权时 sudo。直接以 root 工作，一个手滑的 rm -rf 就没有任何挽回余地。
在本地生成密钥（如果还没有）：
ssh-keygen -t ed25519 -C "deploy@myserver"
ssh-copy-id deploy@服务器IP
验证密钥能登录后，修改服务器 /etc/ssh/sshd_config：
PasswordAuthentication no # 禁用密码登录
PermitRootLogin no # 禁止 root 直接登录
PubkeyAuthentication yes
改完务必新开一个终端验证能登录，再关掉旧会话——配置写错又断开会话，就只能靠云厂商的 VNC 控制台救场了。
sudo sshd -t # 语法检查
sudo systemctl reload ssh
关于改 SSH 端口（如 2222）：它能减少日志噪音，但对有目的的扫描者作用有限（全端口扫描照样找到）。可做可不做；如果改，记得同步更新安全组。
即使有密钥登录，爆破流量仍会灌满日志。fail2ban 监控日志，把反复失败的 IP 自动拉进防火墙黑名单：
sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
jail.local 中调整 sshd 段：
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
含义：10 分钟内失败 5 次，封禁 1 小时。启动并查看状态：
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
安全组在云侧，ufw 在系统侧，两层独立互备：
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp # 若改了 SSH 端口则填新端口
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
:::warning
ufw enable 前确认 SSH 端口已放行，否则会把自己锁在门外。云服务器至少还有安全组和 VNC 可以补救，裸金属机器上这条错误可能意味着一趟机房。
:::
系统漏洞补丁不及时打，前面的加固都是沙上筑塔。Debian/Ubuntu 用 unattended-upgrades 自动安装安全更新：
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades # 交互式确认开启
默认只自动更新安全源（security），不动功能更新——这个平衡对服务器正合适。
timedatectl 显示 NTP 同步正常——证书验证、日志时间线、排障对齐全依赖准确时间。apt install htop iotop ncdu mtr-tiny。ss -tlnp # 监听端口是否与预期一致，没有多余服务
grep "PasswordAuthentication" /etc/ssh/sshd_config
sudo fail2ban-client status # jail 是否生效
sudo ufw status
对照清单逐项打钩。安全不是一次性动作——定期检查登录日志（journalctl -u ssh）、关注所用软件的安全公告，才是常态。
npm run build、手动 rsync 上传——每次发文都多一步出错的机会。GitHub Actions 可以把这条链路完全自动化：push 到主分支后，构建、部署、通知全部自动完成。本文以一个 Node 系静态站（Astro/Hugo 同理）为例走通全流程。
push 到 main
│
▼
GitHub Actions Runner 启动
├─ 1. 拉代码
├─ 2. 装依赖、构建静态产物
├─ 3. 部署产物（rsync 到服务器 / 推到 Pages）
└─ 4. 失败时通知
工作流文件放在仓库的 .github/workflows/deploy.yml：
name: Deploy Blog
on:
push:
branches: [main]
workflow_dispatch: # 允许在网页上手动触发
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: 拉取代码
uses: actions/checkout@v4
- name: 安装 Node
uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- name: 安装依赖并构建
run: |
npm ci
npm run build
- name: 部署到服务器
uses: burnett01/rsync-deployments@7.0.1
with:
switches: -avzr --delete
path: dist/
remote_path: /var/www/blog/
remote_host: ${{ secrets.DEPLOY_HOST }}
remote_user: ${{ secrets.DEPLOY_USER }}
remote_key: ${{ secrets.DEPLOY_KEY }}
触发器 on：push: branches: [main] 表示推送到 main 分支时触发；workflow_dispatch 加一个手动按钮，改完配置想立刻验证时不用特意造一个 commit。
npm ci 而不是 npm install：CI 环境的铁律。ci 严格按 package-lock.json 安装，保证每次构建依赖版本完全一致；install 可能按 semver 范围悄悄升级某个包，让「本地能过、CI 挂掉」变成悬案。搭配 setup-node 的 cache: npm，依赖下载在多次运行间缓存，构建快很多。
部署环节的安全：服务器地址、用户名、SSH 私钥全部放仓库的 Settings → Secrets and variables → Actions 里，以 ${{ secrets.XXX }} 引用。私钥内容绝不能写进 YAML——这个文件在仓库里是公开的。
--delete 参数让 rsync 删除服务器上多余的旧文件，保持目录与构建产物一致；它对部署目录是安全的，但务必确认 remote_path 没填错——填成 /var/www/ 会把兄弟站点的目录清掉。
不要在多个地方复用同一把私钥，给 Actions 单独生成一对：
ssh-keygen -t ed25519 -C "github-actions-blog" -f ~/.ssh/gh-actions-deploy
公钥追加到服务器部署用户的 ~/.ssh/authorized_keys，私钥全文粘贴到仓库 Secret DEPLOY_KEY。这样即便 CI 侧泄露，也只暴露这一把受限密钥，可以随时吊销更换。更严格的做法是在服务器上给该用户配置 command= 前缀限制它只能执行 rsync。
如果博客就托管在 GitHub Pages，部署步骤换成官方 Action，连服务器和密钥都不用管：
- name: 配置 Pages
uses: actions/configure-pages@v5
- name: 上传产物
uses: actions/upload-pages-artifact@v3
with:
path: dist/
- name: 部署到 Pages
id: deployment
uses: actions/deploy-pages@v4
（需要在仓库 Settings → Pages 里把来源选为 GitHub Actions。）
流水线最大的谎言是「绿钩即一切正常」，第二大的谎言是「失败了会有人发现」。加一步失败通知，比如用 curl 调用任意 webhook（Server 酱、Telegram Bot、企业微信均可）：
- name: 失败通知
if: failure()
run: |
curl -s "https://api.day.app/${{ secrets.BARK_KEY }}/博客部署失败/${{ github.sha }}?level=critical"
if: failure() 表示仅当前面步骤失败才执行。同理 if: success() 可以发成功确认——初期建议两种都开，跑稳定后只留失败通知，避免消息疲劳。
npm run check（如果项目提供），让 Front Matter 缺字段这类问题在 CI 阶段就拦住，而不是部署后才发现页面异常。concurrency:
group: deploy
cancel-in-progress: true
同一时刻只允许一个部署在跑，新的 push 会取消未完成的旧任务——反正部署的目标是「最新状态」，中间的半成品没有意义。
传统运维是命令式的：「启动 3 个容器」「这台挂了，重启它」。K8s 是声明式的：你只提交期望状态（"这个应用要有 3 个副本"），K8s 的控制循环持续观察实际状态，发现偏差就自动纠正——副本少了就补，节点挂了就迁。
你提交的每一份 YAML 都是一张「愿望清单」，而不是操作手册。这个模型是理解一切 K8s 行为的前提。
Pod 是一个或多个共享网络与存储的容器组，是 K8s 调度的最小单位。同一 Pod 内的容器共享 IP 和端口空间，通过 localhost 互访。
为什么不是直接调度容器？因为存在「主容器 + 紧密耦合的辅助容器」场景：比如应用容器写日志到共享目录，边车（sidecar）容器负责把日志转发出去——它们必须同生共死、共享存储，打包成一个 Pod 正合适。
实践中很少手写 Pod 定义，但要知道它的两个特性：IP 是临时的（Pod 重建就换）、Pod 是不可变的（想改配置？删掉重建）。
直接创建 Pod 是自虐：它挂了就挂了，没人管。Deployment 在 Pod 之上加了副本管理和更新策略：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3 # 期望 3 个副本
selector:
matchLabels:
app: web
template: # Pod 模板
metadata:
labels:
app: web
spec:
containers:
- name: web
image: registry.example.com/myapp:1.4.2
ports:
- containerPort: 8080
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
kubectl apply -f deployment.yaml
kubectl get pods # 看到 3 个 web-xxx 的 Pod
滚动更新：改 image 版本后再 apply，Deployment 默认用 RollingUpdate 策略——先起一个新版本 Pod，健康了再灭一个旧的，如此滚动，全程服务不中断。
回滚：历史版本被自动记录，新版出问题时一键回到上一个：
kubectl rollout status deployment/web # 观察更新进度
kubectl rollout undo deployment/web # 回滚
自愈：手动 kubectl delete pod web-xxx 试试——Deployment 立刻补一个新 Pod 维持 replicas: 3。这就是声明式控制循环的直观体现。
Pod IP 会变、副本会扩缩，客户端该连哪个地址？Service 用标签选择器圈定一组 Pod，提供一个稳定的虚拟 IP 和 DNS 名，并把流量转发过去。
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web # 选中所有带 app=web 标签的 Pod
ports:
- port: 80 # Service 自己的端口
targetPort: 8080 # 转发到 Pod 的端口
集群内其他应用现在可以通过 http://web（同命名空间下）访问你的服务——不用关心后面是 3 个还是 30 个 Pod、IP 换了几次。
Service 的三种常用类型：
| 类型 | 作用 |
|---|---|
ClusterIP（默认） |
仅集群内访问，内部服务间调用的标准方式 |
NodePort |
在每个节点开一个端口（30000-32767），外部可经节点 IP 访问 |
LoadBalancer |
向云厂商申请一个外部负载均衡器，生产暴露服务的常用方式 |
对外提供 HTTP 服务时，更常见的组合是 Service + Ingress（统一域名、路径路由和 TLS 终结），Ingress 可以认为是「HTTP 层的 Service」。
管理副本与更新
Deployment ──────────────────► Pod × 3（标签 app=web）
▲
│ 标签选择器
Service ───────────────────────────┘
（稳定 IP/DNS，负载均衡转发）
客户端访问 Service 的固定地址；Service 按标签把请求分发给当前存活的 Pod；Deployment 保证 Pod 的数量和版本符合期望。三层各司其职，任何一层都不需要知道其他层的实现细节。
本地学习用 minikube 或 kind（Kubernetes in Docker）起单节点集群；云厂商的托管 K8s（ACK、TKE、EKS）省掉控制面运维，适合生产起步。学会 kubectl get/describe/logs/apply 四件套，就足以完成日常 80% 的操作——describe 尤其重要，任何对象「不正常」，先看它末尾的 Events。
docker run 维护这些，命令越攒越长、参数越记越乱。Docker Compose 把整套应用写进一个 YAML 文件，docker compose up -d 一条命令完整拉起。
目标架构：一个 Web 应用，连接 PostgreSQL 存数据、Redis 做缓存；数据库数据要持久化；Redis 不对外暴露端口。
services:
web:
image: registry.example.com/myapp:1.4.2
build: .
ports:
- "8080:8080"
environment:
DATABASE_URL: postgres://myapp:${DB_PASSWORD}@db:5432/myapp
REDIS_URL: redis://cache:6379/0
depends_on:
db:
condition: service_healthy
cache:
condition: service_started
restart: unless-stopped
networks:
- appnet
db:
image: postgres:16
environment:
POSTGRES_USER: myapp
POSTGRES_PASSWORD: ${DB_PASSWORD}
POSTGRES_DB: myapp
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U myapp"]
interval: 5s
timeout: 3s
retries: 10
restart: unless-stopped
networks:
- appnet
cache:
image: redis:7
restart: unless-stopped
networks:
- appnet
volumes:
pgdata:
networks:
appnet:
保存为 compose.yml（新版标准文件名，旧的 docker-compose.yml 同样兼容），同目录执行：
docker compose up -d # 创建并后台启动全部服务
docker compose ps # 查看服务状态
docker compose logs -f web # 跟踪某个服务日志
docker compose down # 停止并删除容器与网络（数据卷保留）
docker compose down -v # 连数据卷一起删（危险操作）
build 与 image 共存：build: . 表示用当前目录构建；同时写 image: 则构建产物以该名字存储。有现成镜像时省略 build。
depends_on 的正确用法：默认只保证启动顺序，不保证「数据库真的就绪了」。Web 应用在 Postgres 还没初始化完时启动照样崩。正确姿势是 condition: service_healthy 配合数据库的 healthcheck——Compose 会等到健康检查通过才启动依赖方。
服务名即主机名：同一 network 下的服务可以用服务名互相访问。DATABASE_URL 里的 @db:5432 和 redis://cache:6379 就是靠这个机制，不需要写死 IP。
端口映射的最小暴露原则：只有 web 映射了宿主端口；db 和 cache 不写 ports，外界（包括宿主机之外的机器）就无法访问它们，天然隔离。
Compose 自动读取同目录的 .env 文件做变量替换：
# .env（不要提交到 Git）
DB_PASSWORD=s3cure-random-string
${DB_PASSWORD} 在 YAML 里被替换成实际值。纪律：
.env 加入 .gitignore，仓库里只放 .env.example 模板。docker compose --env-file .env.prod up -d。# 重新构建并更新某个服务（改了代码后）
docker compose up -d --build web
# 在服务容器里执行一次性命令（如数据库迁移）
docker compose exec web ./migrate up
# 临时跑一个一次性容器
docker compose run --rm web ./bin/console
# 看整体资源占用
docker compose top
开发环境要挂源码、开调试端口，生产不要。用多文件叠加而不是复制整份配置：
docker compose -f compose.yml -f compose.dev.yml up -d
docker compose -f compose.yml -f compose.prod.yml up -d
后面的文件覆盖前面的同名配置。compose.dev.yml 里给 web 加源码挂载，生产文件里加资源限制，公共部分只维护一份。
Compose 解决的是单机多容器编排。它的定位很清晰：开发环境、小项目部署、CI 集成测试。需要跨机器调度、自动扩缩容、滚动更新时，就该上 Kubernetes 了——那是下一篇文章的话题。但即便上了 K8s，本地开发用 Compose 起一套依赖依然是高效的做法。
FROM golang:1.23
WORKDIR /app
COPY . .
RUN go build -o server .
CMD ["./server"]
它能工作，但问题一堆：镜像近 900MB（整个 Go 工具链都在里面）、构建上下文混入无关文件、以 root 运行、每次改代码都全量重装依赖。
基础镜像是体积的大头，常见档位：
| 镜像 | 体积 | 说明 |
|---|---|---|
golang:1.23 |
~850MB | 完整工具链，只用于构建 |
debian:bookworm-slim |
~80MB | 精简 Debian，适合需要 libc 的动态链接程序 |
alpine |
~8MB | musl libc，极小，但注意 glibc 兼容问题 |
scratch |
0 | 空镜像，静态编译程序的终极选择 |
distroless |
~20MB | Google 出品，只有运行时依赖，无 shell 无包管理器 |
:::warning Alpine 用 musl 替代 glibc，某些依赖 glibc 特定行为的程序（典型如部分 DNS 解析、某些加密库）在 Alpine 上会出现难以排查的问题。静态链接的 Go 程序不受影响，但 Python、Node 等含原生扩展的生态要慎重。 :::
核心思想：编译用的镜像不进入最终镜像。第一阶段构建，第二阶段只拷贝产物：
# ---- 构建阶段 ----
FROM golang:1.23 AS builder
WORKDIR /app
# 先拷贝依赖清单，利用层缓存
COPY go.mod go.sum ./
RUN go mod download
# 再拷贝源码并构建（CGO_ENABLED=0 产出静态二进制）
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o server .
# ---- 运行阶段 ----
FROM gcr.io/distroless/static-debian12
WORKDIR /app
COPY --from=builder /app/server .
EXPOSE 8080
USER nonroot:nonroot
ENTRYPOINT ["/app/server"]
效果：最终镜像从 ~900MB 降到 20MB 以内。拉取更快、攻击面更小、漏洞扫描报告更干净。
几个细节：
-ldflags="-s -w" 去掉符号表和调试信息，二进制再小一截。USER nonroot 让进程以非特权用户运行，容器被攻破时攻击者拿到的不是 root。distroless 自带 nonroot 用户。node_modules 生产依赖和构建产物；Java 用 jlink 定制 JRE。Docker 按层缓存：某一层变了，它之后的所有层全部重建。因此 Dockerfile 的指令顺序按「变化频率从低到高」排列：
COPY go.mod go.sum ./ # 依赖清单很少变
RUN go mod download # 上面没变这层就用缓存
COPY . . # 源码天天变，放最后
RUN go build ...
依赖下载层被缓存后，日常改代码的构建不再访问网络，速度差一个数量级。反例就是开头那把梭的写法：COPY . . 在前，任何文件变动都会让 go mod download 缓存失效。
docker build 的第一步是把整个目录发给 Docker daemon。没有 .dockerignore 的话，.git、本地依赖、测试数据、密钥文件全都会被发送，甚至可能被 COPY . . 打进镜像：
.git
node_modules
*.log
.env
.dockerignore
Dockerfile
docs/
tests/
这既是体积问题，更是安全问题——.env 进了镜像层，就算后面 RUN rm .env，文件依然存在于历史层中，docker history 可以翻出来。
ENTRYPOINT 直接启动应用，不要在容器里跑 supervisord 管一堆服务——那是虚拟机的玩法。docker exec 挂载，常驻只会扩大攻击面。myapp:1.4.2 可追溯可回滚；latest 让「线上现在跑的到底是哪版」变成悬案。HEALTHCHECK CMD wget -qO- http://localhost:8080/healthz || exit 1，让 docker ps 直接显示健康状态。构建完成后自查：
docker images myapp # 体积是否达标（Go 静态程序应 < 50MB）
docker history myapp:1.0 # 每层是否合理，有没有敏感文件痕迹
docker run --rm myapp:1.0 # 能否以非 root 正常启动
体积、缓存、安全三件事做到位，这个 Dockerfile 就可以进生产了。
镜像是一个只读的、分层的文件系统快照，里面打包了应用及其全部依赖。容器是从镜像启动的进程，拥有自己的文件系统视图（在镜像之上加一层可写层）、进程空间、网络空间。
一个镜像可以启动多个互不干扰的容器，就像一个类可以 new 出多个实例：
docker run -d --name web1 -p 8081:80 nginx
docker run -d --name web2 -p 8082:80 nginx
两条命令用同一个 nginx 镜像起了两个独立容器，分别映射到宿主机 8081、8082。
docker run 的关键参数：
| 参数 | 作用 |
|---|---|
-d |
后台运行（detached） |
--name |
给容器命名，否则随机生成 |
-p 宿主端口:容器端口 |
端口映射 |
-e KEY=VALUE |
注入环境变量 |
-v 卷名或路径:容器内路径 |
挂载数据 |
--restart unless-stopped |
崩溃或重启后自动拉起 |
docker ps # 运行中的容器
docker ps -a # 包括已停止的
docker stop web1 # 优雅停止（先发 SIGTERM）
docker start web1 # 重新启动
docker restart web1 # 重启
docker rm web1 # 删除已停止的容器
docker rm -f web1 # 强制删除运行中的（慎用）
排错三件套，记牢：
docker logs -f web1 # 看容器标准输出（应用日志都该打到这里）
docker exec -it web1 sh # 进容器里看看
docker inspect web1 # 查看容器全部配置（IP、挂载、环境变量）
:::note 容器的正确心智模型是「一次性的进程」，而不是「轻量虚拟机」。不要在容器里改配置然后指望它一直活着——容器删掉就没了，配置应该通过镜像、环境变量或挂载注入。 :::
容器删了，可写层里的数据就没了。需要持久化的数据必须挂载出来：
1. 命名卷（Volume，推荐）——由 Docker 管理存储位置：
docker volume create pgdata
docker run -d --name db -v pgdata:/var/lib/postgresql/data postgres:16
2. 绑定挂载（Bind Mount）——直接映射宿主机路径，开发时常用：
docker run -d --name app -v /opt/myapp/config:/app/config myapp
3. tmpfs——只存在于内存，容器停即消失，适合敏感临时数据。
选择原则：生产数据用命名卷（可备份、可迁移）；需要宿主机直接读写的配置用绑定挂载。
bridge（默认）：Docker 建一个虚拟网桥 docker0，每个容器分配独立 IP。同网桥上的容器可以互相通信，配合 --link 已废弃的旧做法不同，现在用自定义网络实现服务发现：
docker network create appnet
docker run -d --name db --network appnet postgres:16
docker run -d --name app --network appnet myapp
# app 容器里可以直接用主机名 "db" 访问数据库
自定义网络内置 DNS，容器名即主机名——这是多容器应用的标准做法。
host：容器直接用宿主机网络栈，没有隔离也没有端口映射，性能最好。适合对网络性能敏感的组件，但端口冲突要自己管。
none：完全断网，只留回环口，用于批量计算任务。
docker images # 本地镜像列表
docker pull redis:7 # 拉取指定 tag
docker build -t myapp:1.0 . # 用当前目录 Dockerfile 构建
docker tag myapp:1.0 reg.example.com/myapp:1.0 # 打私仓标签
docker push reg.example.com/myapp:1.0
docker system prune # 清理停止的容器、悬空镜像、未用网络
磁盘空间告警时，docker system df 先看占用分布，再决定 prune 范围（加 -a 连未使用的镜像一起删，下手前确认）。
Ansible 与被管机器之间只走 SSH——不需要在目标机器预装任何 agent 或服务。控制节点装好 Ansible，目标机有 Python 和 SSH 就行。对比 Puppet/SaltStack 需要先给全网装客户端，Ansible 的接入成本几乎为零，这也是它成为中小团队首选的原因。
Inventory 是被管机器的清单，INI 格式（也支持 YAML）：
[web]
web1 ansible_host=10.0.1.11
web2 ansible_host=10.0.1.12
[db]
db1 ansible_host=10.0.2.11
[all:vars]
ansible_user=deploy
ansible_ssh_private_key_file=~/.ssh/id_ed25519
要点：
ansible_host、ansible_user 这类连接变量可以按主机、按组、按 all 全局三个层级设置，就近覆盖。验证连通性（Ansible 的「hello world」）：
ansible all -i inventory.ini -m ping
-m ping 不是 ICMP，而是实际 SSH 上去执行一个 Python 模块，返回 pong 说明连接、认证、Python 环境全部就绪。
不写剧本也能直接批量操作，适合一次性任务：
# 查看所有 web 机器的负载
ansible web -i inventory.ini -m shell -a "uptime"
# 给所有机器安装 htop
ansible all -i inventory.ini -m apt -a "name=htop state=present" --become
--become 表示在目标机提权（默认 sudo）。
重复性任务要写成 playbook。例如「部署 Nginx 并启动」：
- name: 配置 web 服务器
hosts: web
become: true
tasks:
- name: 安装 nginx
apt:
name: nginx
state: present
update_cache: true
- name: 下发站点配置
template:
src: nginx.conf.j2
dest: /etc/nginx/sites-available/default
notify: 重载 nginx
- name: 确保服务运行
service:
name: nginx
state: started
enabled: true
handlers:
- name: 重载 nginx
service:
name: nginx
state: reloaded
执行：
ansible-playbook -i inventory.ini site.yml
同一个 playbook 执行一次和执行一百次，结果应该相同。 Ansible 的模块大多遵循这个原则：apt: name=nginx state=present 表示「确保 nginx 处于已安装状态」——已安装就跳过，没装才装。这与 shell 脚本里裸写 apt install nginx 有本质区别：脚本每次执行都产生副作用，playbook 描述的是目标状态。
写 playbook 时警惕破坏幂等的写法：shell/command 模块没有状态概念，默认每次都执行。能用专用模块（apt、copy、template、file、user……）就不用 shell；必须用 shell 时，加 creates/removes 参数告诉 Ansible 如何判断「已经做过了」。
template 模块用 Jinja2 渲染配置文件，变量在运行时注入，同一份模板可以给测试、生产环境生成不同配置。handler 是「变更后动作」：上面的例子里，只有配置文件真的发生变化时才会触发 nginx reload，配置没动就不打扰服务。这也是幂等思想的一部分。| 模块 | 用途 | 例子 |
|---|---|---|
apt / dnf |
包管理 | name=vim state=latest |
copy |
直接下发文件内容 | content="..." dest=/etc/motd |
template |
Jinja2 模板下发 | src=app.conf.j2 dest=... |
file |
建目录、改权限 | path=/data state=directory mode=0755 |
user |
用户管理 | name=deploy shell=/bin/bash groups=sudo |
service / systemd |
服务管理 | name=nginx state=restarted enabled=true |
cron |
定时任务 | name=backup job="/opt/backup.sh" hour=3 |
lineinfile |
确保某行存在/不存在 | 改 sshd 配置单条参数 |
ansible-vault encrypt_string 加密后再写进变量文件，仓库里只存密文。--check + --diff 先演习：ansible-playbook site.yml --check --diff 只演算不执行，并展示将发生的变化，上线前必跑。name: 安装 nginx 比 name: apt 好——执行输出和失败定位都靠任务名。tail -f 加 grep 就是全部日志方案。服务器变成五台、十台之后，「登录每台机器逐个翻日志」彻底失效，集中式日志管理成为刚需。本文按技术演进的顺序讲三种方案，帮你按团队规模选择，而不是盲目上最重的那个。
分散日志有三个致命伤：
Linux 自带的 rsyslog 本身就支持把日志转发到远端。发送端 /etc/rsyslog.d/50-forward.conf：
*.* @@log-server:514
（@@ 表示 TCP，@ 是 UDP；生产用 TCP 防丢。）
接收端开启监听并写入按来源分目录的文件：
$ModLoad imtcp
$InputTCPServerRun 514
$template RemoteHost,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteHost
优点：零新增组件、资源占用忽略不计、稳定跑了几十年的老方案。
缺点：只能 grep，没有结构化解析，没有 Web 界面，检索大数据量时全靠手动。
适用：服务器少于十台、日志量小、团队习惯命令行。
ELK = Elasticsearch + Logstash + Kibana，是日志分析领域的事实标准。管道是：
Filebeat(采集) → Logstash(解析/富化) → Elasticsearch(存储/索引) → Kibana(查询/展示)
实际部署常用 Filebeat 直接写 ES，跳过 Logstash 以省资源，解析交给 ES 的 ingest pipeline。
核心能力是全文检索：每条日志的每个词都被倒排索引，「找出所有包含 timeout 且来自 api-server 的日志」毫秒返回。Kibana 的 Discover 界面、可视化图表和告警插件构成了完整的日志分析工作流。
代价是资源：Elasticsearch 基于 JVM，给全文索引建的倒排表让存储放大到原始日志的 1.5~3 倍，一个中等规模集群轻松吃掉几十 GB 内存。个人项目单节点 ES 最低建议 4GB 堆内存起步。
适用：日志需要复杂检索与分析、有专门运维人力、资源预算充足。
Grafana Labs 出品的 Loki 提出了一个关键洞察：大部分时候人们查日志是先按「哪个服务、哪台机器」缩小范围，再在里面 grep。所以 Loki 只为标签建索引（如 job="nginx", host="web1"），日志原文压缩存储，不做全文索引。
Promtail(采集) → Loki(存储) → Grafana(查询)
架构和 Prometheus 几乎同构（Loki 自称是「日志界的 Prometheus」），查询语言 LogQL 也神似 PromQL：
{job="nginx"} |= "timeout" | json | status >= 500
含义：取 job=nginx 的日志流 → 过滤含 timeout 的行 → 按 JSON 解析 → 筛 status 字段 ≥ 500。
优点：存储成本低一个数量级（压缩率通常 10:1 以上）、内存友好、与 Grafana 天然集成——点一下就能从指标曲线跳到同时间段的日志。 缺点：不做全文索引意味着「不按标签过滤的全文搜索」很慢；高基数标签（如把 user_id 做成标签）会拖垮索引，使用上有纪律要求。
适用：已经在用 Prometheus + Grafana、日志主要用于排障而非复杂分析、追求低成本。
| 维度 | rsyslog | ELK | Loki |
|---|---|---|---|
| 部署复杂度 | 极低 | 高 | 中 |
| 全文检索 | 无（靠 grep） | 强 | 弱（标签+过滤） |
| 存储成本 | 原始大小 | 1.5~3 倍 | 约 1/10 |
| 学习成本 | 低 | 高 | 中 |
| 适合规模 | < 10 台 | 中大规模、重分析 | 中小规模、重排障 |
三个方案有个共同前提：应用输出结构化日志（JSON）比纯文本好处理一百倍。
{"ts":"2026-10-11T10:30:00+08:00","level":"error","service":"api","trace_id":"abc123","msg":"db query timeout","latency_ms":2300}
字段明确后，任何管道都能准确解析；而 2026/10/11 ERROR something happened 这种自由文本，到了平台侧还得写正则猜字段。改造应用日志格式，是投入产出比最高的日志治理动作。
Prometheus 的核心特点是主动拉取（Pull）：它按配置的时间间隔访问各目标暴露的 /metrics HTTP 接口，把文本格式的指标抓回来存进内置时序数据库。被监控方只需要「暴露」，不需要知道监控系统的存在。
三个角色：
node_exporter。在被监控机器上（以 Linux amd64 为例）：
# 下载官方发布的二进制（版本号以 releases 页面为准）
wget https://github.com/prometheus/node_exporter/releases/download/v1.9.1/node_exporter-1.9.1.linux-amd64.tar.gz
tar xzf node_exporter-1.9.1.linux-amd64.tar.gz
sudo cp node_exporter-1.9.1.linux-amd64/node_exporter /usr/local/bin/
用 systemd 管理，新建 /etc/systemd/system/node_exporter.service：
[Unit]
Description=Node Exporter
After=network.target
[Service]
User=nobody
ExecStart=/usr/local/bin/node_exporter
Restart=on-failure
[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
curl http://localhost:9100/metrics | head
最后一行应该输出大量 node_cpu_seconds_total、node_memory_MemAvailable_bytes 之类的指标——采集端就绪。
Prometheus 的配置文件 prometheus.yml 里加一段 job：
scrape_configs:
- job_name: "node"
scrape_interval: 15s
static_configs:
- targets: ["10.0.1.11:9100", "10.0.1.12:9100"]
labels:
env: "production"
scrape_interval: 15s 是全局常用值，太密浪费存储，太疏丢失细节。labels 会附加到这个 job 抓到的所有序列上，是多环境区分的标准做法。改完执行 promtool check config prometheus.yml 校验，再重启或调用 /-/reload 热加载。打开 Prometheus 自带 UI（:9090/targets），目标状态变为 UP 即成功。
PromQL 是这套体系的核心资产，掌握五个常用查询就能应对日常：
# 1. CPU 使用率（按实例）：1 减去空闲比例，irate 取最近两点瞬时变化率
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# 2. 内存使用率
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100
# 3. 根分区磁盘使用率
100 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100)
# 4. 磁盘 IO 繁忙度
irate(node_disk_io_time_seconds_total[5m]) * 100
# 5. 网络入向流量（字节/秒）
irate(node_network_receive_bytes_total{device="eth0"}[5m])
几个关键点：irate 对计数器求「每秒增长」；[5m] 是采样窗口，至少为抓取间隔的 2~4 倍；by (instance) 是聚合维度。在 UI 的 Graph 页逐个输入观察曲线，比背语法更快建立直觉。
http://<prometheus地址>:9090。1860，导入后选择数据源即得一套完整主机监控页。:::tip
grafana.com 的共享面板质量参差，导入后务必检查两件事：查询语句里的变量（如 $job、$instance）是否在你的标签体系里有值；面板的默认时间范围和刷新频率是否合适。
:::
Prometheus 默认把数据存 15 天（--storage.tsdb.retention.time）。粗略估算磁盘占用：每个活跃时间序列每秒样本约 1~2 字节。一台 node_exporter 约暴露 1000 个序列，15 秒抓取一次，15 天约 3~6 GB——几十台机器的规模单机 Prometheus 完全扛得住。
需要更长保留期或全局查询时，再考虑 Thanos、VictoriaMetrics 这类横向扩展方案，初期不必过度设计。
主机监控跑通后，按相同模式扩展：MySQL 用 mysqld_exporter，Nginx 用 nginx-prometheus-exporter，自己的应用则引入客户端库（如 Go 的 prometheus/client_golang）在代码里暴露 /metrics。采集-存储-展示的管道不变，只是数据来源变多。
「系统现在正常吗？」——用于告警，要求快、准、少误报。
「出问题的时候，哪里出了问题？」——用于排障，要求数据足够细、维度足够多。
这两个目标有时矛盾：告警要求聚合后的少量信号，排障要求保留大量原始数据。好的监控体系同时服务两者，而不是用同一套东西勉强应付。
从底向上，每一层关注不同的问题：
| 层级 | 关注什么 | 典型指标 |
|---|---|---|
| 基础设施层 | 机器活着吗、资源够吗 | CPU、内存、磁盘、网络 |
| 系统服务层 | 依赖的中间件健康吗 | MySQL 连接数、Redis 命中率、Nginx 状态码分布 |
| 应用层 | 我的服务正常吗 | QPS、响应延迟分位数、错误率、队列堆积 |
| 业务层 | 用户在受影响吗 | 下单成功率、支付转化率、在线人数 |
新手常犯的错误是只监控第一层——CPU 60% 告警响了，但用户一切正常；反过来数据库连接池耗尽导致全站 500，CPU 却风平浪静。越靠近用户的层级，告警价值越高。
指标（Metrics）：按时间间隔采样的数值，如「过去 1 分钟平均延迟」。特点是聚合后体积小、查询快，适合趋势图和告警条件。局限是维度爆炸——给指标加 user_id 标签，时间序列数量直接失控。
日志（Logs）：离散事件的记录，信息量最大但检索成本高。排障时回答「这个具体请求发生了什么」靠它。
追踪（Traces）：一个请求跨多个服务的完整路径，微服务架构下定位慢调用靠它。
三者的关系：指标告诉你出事了，日志告诉你发生了什么，追踪告诉你卡在哪一环。
告警太多 = 没有告警。值班的人每天收到 50 条告警，其中 49 条可以安全忽略，那么第 50 条也必然被忽略。设计告警时遵守几条纪律：
1. 只对「需要人立即行动」的情况告警。 CPU 高需要人半夜爬起来吗？通常不需要。磁盘 95% 需要吗？可能只需要工作日处理。用户支付失败率飙升呢？需要，立刻。
2. 告警基于症状，不是原因。 「数据库连接数高」是原因，「接口错误率超过 5%」是症状。原因类信号适合做成巡检报表，症状类信号才配叫醒人。
3. 每条告警都要有处理手册。 收到告警的人（可能是三个月后的你）应该能照着 runbook 一步步排查，而不是对着一个指标名干瞪眼。告警消息里附上相关面板链接和处理文档地址。
4. 设置抑制与静默。 主机宕机时，它上面的 30 个服务告警应该被收敛成一条；计划内维护期间对应告警提前静默，别让噪音训练大家忽略告警。
「平均响应时间」是最具欺骗性的指标——99 个 10ms 的请求和 1 个 10s 的请求，平均下来 109ms，看起来还行，但有一个用户等了 10 秒。
正确做法是监控分位数：p50 看中位体验，p95/p99 看尾部体验。告警条件再加上持续时间窗口，避免毛刺触发：
# 伪代码：p99 延迟连续 5 分钟超过 2 秒才告警
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2
同样的思路适用于错误率：「5 分钟内错误率 > 2%」比「单次错误」可靠得多。
暂时不上复杂系统，一台 Linux 服务器也能做好基础监控：
node_exporter，暴露机器指标到 :9100/metrics。journalctl -u <你的服务> 能查到应用日志，rsyslog 正常轮转。这套组合足够支撑个人项目和小团队初期，等它不够用时，痛点会自然告诉你下一步该补什么。
申请证书的本质是向 CA 证明两件事：你持有域名的控制权，以及你持有证书私钥。ACME 用「挑战-应答」完成验证，主流有两种方式：
HTTP-01 挑战：Let's Encrypt 给你一个随机 token，要求你的服务器在 http://<域名>/.well-known/acme-challenge/<token> 路径上返回指定内容。CA 从公网访问这个 URL，能拿到正确内容就证明你控制该域名指向的服务器。
DNS-01 挑战：要求你创建一个 _acme-challenge.<域名> 的 TXT 记录。能改 DNS 就证明控制权。它是申请通配符证书（*.example.com）的唯一方式，也适合服务器不暴露 80 端口的场景；缺点是需要 DNS 服务商 API 才能自动化。
Certbot 是 EFF 维护的 ACME 客户端，各大发行版均可安装。以 Debian/Ubuntu + Nginx 为例：
apt update && apt install -y certbot python3-certbot-nginx
如果 80 端口已经由 Nginx 提供服务，最省事的方式是让 Certbot 直接改 Nginx 配置：
certbot --nginx -d example.com -d www.example.com
Certbot 会依次完成：生成私钥 → 发起 HTTP-01 挑战 → 通过验证拿到证书 → 修改 Nginx 配置启用 443 监听和 HTTP 跳转 HTTPS → 输出证书存放路径。
证书与私钥位置（Debian/Ubuntu 默认）：
/etc/letsencrypt/live/example.com/fullchain.pem # 证书（含中间证书链）
/etc/letsencrypt/live/example.com/privkey.pem # 私钥
:::note
不想让 Certbot 动配置文件的话，用 certbot certonly --webroot -w /var/www/html -d example.com，挑战文件会放进 webroot，拿到证书后自己改 Nginx 配置。这种方式流程更透明，适合需要精细控制的场景。
:::
申请成功后检查证书内容：
openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -dates -subject
输出里能看到有效期——Let's Encrypt 证书只有 90 天，这是故意的：短周期倒逼自动化，私钥泄露后的暴露窗口也更短。
Certbot 安装时会自动注册一个 systemd timer（或 cron 任务），每天跑两次续期检查。验证它存在且工作正常：
systemctl list-timers | grep certbot # 查看定时器
certbot renew --dry-run # 演习一次续期流程
--dry-run 是续期排错的第一件武器：它走完整的验证流程但不实际签发，能提前发现 80 端口不通、Nginx 配置变化导致的失败。续期默认在证书剩余 30 天内才实际执行，此前的调用只是空转。
续期成功后需要让服务加载新证书。用钩子把重载动作挂进去：
certbot renew --deploy-hook "systemctl reload nginx"
或者写入 /etc/letsencrypt/renewal/example.com.conf 的 [renewalparams] 段：
deploy_hook = systemctl reload nginx
按出现频率排序：
/.well-known/acme-challenge/ 路径。--dry-run 报错里如果看到 IPv6 地址就是它。查看续期日志定位具体原因：
journalctl -u certbot.timer --since "7 days ago"
less /var/log/letsencrypt/letsencrypt.log
证书装完不等于高枕无忧：
curl -vI https://example.com 确认返回 200 且证书链完整（输出里能看到 SSL certificate verify ok）。Strict-Transport-Security），让浏览器以后直接走 HTTPS。假设后端应用监听本机 3000 端口，希望通过 80 端口对外提供 HTTP 服务：
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
四行 proxy_set_header 不是装饰，缺了它们后端会丢失关键信息：
Host：默认情况下 Nginx 会把请求头改成上游地址，后端基于域名的虚拟主机路由会失效。X-Real-IP / X-Forwarded-For：后端看到的来源 IP 全是 127.0.0.1，日志和限流就废了。X-Forwarded-For 用追加模式，保留完整代理链。X-Forwarded-Proto：告诉后端原始请求是 HTTP 还是 HTTPS，避免应用生成错误的重定向地址。修改配置后先测试再生效，这是 Nginx 运维的铁律：
nginx -t # 语法检查
systemctl reload nginx # 平滑重载，不断开已有连接
多个后端实例时，用 upstream 定义服务器组：
upstream app_backend {
# 默认算法：加权轮询
server 10.0.1.11:3000 weight=3;
server 10.0.1.12:3000;
server 10.0.1.13:3000 backup; # 备用节点，前面全挂才启用
# keepalive 32; # 与后端保持的长连接数，减少 TCP 握手
}
server {
listen 80;
location / {
proxy_pass http://app_backend;
# ... 同上 proxy_set_header
}
}
| 算法 | 写法 | 适用场景 |
|---|---|---|
| 加权轮询（默认） | server ... weight=N |
后端无状态、配置不同 |
| 最少连接 | least_conn; |
请求处理时长差异大（如报表导出） |
| IP 哈希 | ip_hash; |
需要会话粘滞但又没有共享 session 存储 |
:::warning
ip_hash 用客户端 IP 做哈希，同一个 IP 永远落到同一台后端。它解决的是「会话粘滞」问题，但会带来负载不均（比如大量用户从同一个公司出口 IP 进来）。更好的做法是应用层改用 JWT 或 Redis 集中存 session，让后端彻底无状态。
:::
开源版 Nginx 没有主动探活，但可以用两个参数实现被动摘除：
server 10.0.1.11:3000 max_fails=3 fail_timeout=30s;
含义：30 秒内连续 3 次连接失败，就把该节点标记为不可用，30 秒后再试探。配合 proxy_next_upstream 可以定义「失败」的范围和重试策略：
proxy_next_upstream error timeout http_502 http_503;
proxy_next_upstream_tries 2;
反向代理层顺手做两件事，后端压力能降一个数量级：
# 静态文件直接由 Nginx 返回
location ~* \.(jpg|jpeg|png|css|js|ico|woff2)$ {
root /var/www/app/public;
expires 7d;
add_header Cache-Control "public, immutable";
}
# 开启 gzip
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1k;
反向代理挂起的连接会拖垮 worker 进程，这组参数值得显式设置：
proxy_connect_timeout 5s; # 与后端建立 TCP 连接的超时
proxy_send_timeout 60s; # 向后端写请求的超时
proxy_read_timeout 60s; # 从后端读响应的超时（慢接口要调大）
如果后端是长轮询或 SSE 接口，proxy_read_timeout 必须大于推送间隔，否则连接会被 Nginx 掐断。
代理出问题时，两个日志位置记牢：
error_log（默认 /var/log/nginx/error.log）：后端连接失败、上游超时都记在这里。access_log：用自定义格式记录上游耗时，快速定位慢后端：log_format upstream_log '$remote_addr - $upstream_addr '
'rt=$request_time urt=$upstream_response_time '
'status=$status "$request"';
access_log /var/log/nginx/upstream.log upstream_log;
$request_time 是总耗时，$upstream_response_time 是后端处理耗时——两者差值就是 Nginx 排队和网络开销，一眼看出瓶颈在哪一层。
Redis 的 value 不只是字符串。选对结构，很多看似复杂的逻辑一条命令就能解决：
| 结构 | 特征 | 典型场景 |
|---|---|---|
| String | 最基本，可存文本、数字、序列化数据 | 缓存对象、计数器（INCR）、分布式锁（SET NX PX） |
| Hash | 字段-值对的集合 | 存对象的部分字段，避免整取整存 |
| List | 有序、可两端操作 | 简单消息队列（LPUSH + BRPOP）、最新 N 条记录 |
| Set | 无序去重、支持交并差 | 标签、共同好友（SINTER）、抽奖去重 |
| Sorted Set | 每个成员带分数、按分排序 | 排行榜（ZADD/ZREVRANGE）、延迟队列 |
以排行榜为例，用 MySQL 实现需要 ORDER BY score DESC LIMIT 10 扫索引；用 Sorted Set 只需要：
ZADD rank 2580 "player:1001"
ZREVRANGE rank 0 9 WITHSCORES # 前十名
:::note Redis 7 之后还内置了 Stream（消息流）、Bitmap、HyperLogLog、GEO 等高级结构。HyperLogLog 做 UV 统计只需约 12KB 内存就能估算上亿基数，误差约 0.81%，适合「只要近似值」的大数据统计。 :::
把 Redis 放在数据库前面挡流量，是标准用法；但缓存层本身也会引入新的故障模式。这三个问题名字相似，成因和对策完全不同。
请求恶意或异常地查询不存在的 key，缓存必然不命中，每次都打到数据库。
对策：
某个被百万并发访问的热点 key 过期瞬间，所有请求同时涌向数据库。
对策：
SET lock NX PX 3000），由它查库回填，其余请求短暂等待后读缓存。通常是两个原因：大量 key 设了相同 TTL，或 Redis 实例整体宕机。
对策：
3600 + random(600) 秒，打散过期时间点。纯内存意味着重启即清空。Redis 提供两种把数据落盘的方式，可以单独用也可以同时开。
RDB（快照）：按配置的时间间隔（如 save 900 1 表示 900 秒内至少 1 次修改）fork 子进程把全量数据写成二进制文件 dump.rdb。
AOF（追加日志）：把每条写命令追加到 appendonly.aof，配合三种 fsync 策略：
| 策略 | 安全性 | 性能 |
|---|---|---|
appendfsync always |
每命令落盘，几乎不丢 | 最差 |
appendfsync everysec（默认） |
宕机最多丢 1 秒 | 折中，推荐 |
appendfsync no |
交给操作系统，可能丢几十秒 | 最好 |
AOF 文件会持续增长，Redis 通过 AOF rewrite（重写）在后台把它压缩成当前数据的最小命令集；7.0 起改用「主文件 + 增量文件」的多部分 AOF，重写期间更省内存和磁盘。
实际选择：缓存场景可以不持久化；需要数据可靠性时开 AOF everysec，再用 RDB 定时快照做异地备份，两者互补。
KEYS *——它 O(N) 全量扫描，会直接阻塞单线程的 Redis。用 SCAN 分批遍历。UNLINK 替代 DEL（4.0+），把内存释放放到后台线程，避免阻塞。经典转账场景：A 给 B 转 100 元，需要两条 UPDATE：
UPDATE accounts SET balance = balance - 100 WHERE name = 'A';
UPDATE accounts SET balance = balance + 100 WHERE name = 'B';
如果第一条执行完系统宕机，钱就凭空消失了。用 START TRANSACTION 把两条语句包起来，数据库保证要么都生效，要么都不生效。这就是事务存在的意义。
| 特性 | 含义 | 靠什么实现 |
|---|---|---|
| 原子性 Atomicity | 事务内操作全做或全不做 | undo log（回滚日志） |
| 一致性 Consistency | 事务前后数据满足业务约束（如总额不变） | 由其他三个特性 + 应用代码共同保证 |
| 隔离性 Isolation | 并发事务互不干扰 | 锁与 MVCC |
| 持久性 Durability | 提交后的修改不因宕机丢失 | redo log（重做日志） |
其中「一致性」最容易被误解：它不是数据库单方面能保证的。比如「余额不能为负」这条约束，需要应用代码或 CHECK 约束配合，数据库只提供原子、隔离、持久这三块地基。
如果所有事务都严格串行执行，隔离性完美但吞吐量惨不忍睹。为了性能，数据库允许事务并发交错执行，于是产生了三种经典异常。可以用两个会话（Session 1 和 Session 2）亲手复现。
脏读（Dirty Read）：读到了别的事务还没提交的修改。如果对方随后回滚，你读到的就是从未存在过的数据。
不可重复读（Non-Repeatable Read）：同一事务内，两次读同一行结果不同——因为中间有别的事务修改并提交了它。
幻读（Phantom Read）：同一事务内，两次按相同条件范围查询，第二次多出了「幽灵行」——别的事务插入并提交了符合条件的新行。
SQL 标准定义了四个隔离级别，逐级收紧：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| READ UNCOMMITTED | 可能 | 可能 | 可能 |
| READ COMMITTED | 不会 | 可能 | 可能 |
| REPEATABLE READ | 不会 | 不会 | 可能* |
| SERIALIZABLE | 不会 | 不会 | 不会 |
* MySQL InnoDB 在 REPEATABLE READ 下通过 Next-Key Lock 基本杜绝了幻读，这是它比 SQL 标准要求更严格的地方。
MySQL（InnoDB）默认 REPEATABLE READ，Oracle、PostgreSQL 默认 READ COMMITTED。从 MySQL 迁移到 PostgreSQL 的应用，要特别注意这个差异——同样的代码在 PG 下可能开始出现不可重复读。
查看与设置当前隔离级别：
-- 查看
SELECT @@transaction_isolation;
-- 仅对下一个事务生效
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
准备数据后开两个终端：
-- 准备
CREATE TABLE t (id INT PRIMARY KEY, val INT);
INSERT INTO t VALUES (1, 100);
-- 会话 1 -- 会话 2
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT val FROM t WHERE id = 1; -- 返回 100
START TRANSACTION;
UPDATE t SET val = 200 WHERE id = 1;
COMMIT;
SELECT val FROM t WHERE id = 1; -- READ COMMITTED 下返回 200
-- REPEATABLE READ 下仍返回 100
COMMIT;
把隔离级别换成 REPEATABLE READ 再跑一遍，会话 1 两次读取结果相同——InnoDB 的 MVCC 让事务看到的是「事务开始那一刻」的一致性快照。
:::note MVCC（多版本并发控制）的核心思路：读不阻塞写、写不阻塞读。每行数据背后挂着一条 undo log 版本链，事务按自己的「 Read View」沿链条找到对自己可见的那个版本。 :::
没有索引时，找 WHERE id = 9527 要把表里的数据页从头到尾翻一遍，一百万行就是一百万次比较，还伴随大量磁盘 I/O。优化目标很明确：少读数据页。
二叉查找树在内存里很好，但树太深——百万级数据也有 20 层，每层一次磁盘 I/O 就受不了。B+ 树的做法是让每个节点「变胖」：一个节点放一个数据页（InnoDB 默认 16KB），存几百到上千个键。这样千万级数据的索引也只有 3~4 层，绝大多数查询 3 次 I/O 内命中。
B+ 树的两个结构特征决定了它的使用规则：
BETWEEN、>）和排序（ORDER BY 索引列）可以顺着叶子链表扫，不需要回树。类比：非叶子节点是书的章节目录，叶子链表是按页码排好的正文。
InnoDB 的表数据本身就按主键组织成一棵 B+ 树（聚簇索引），叶子节点存整行。二级索引（普通索引）的叶子节点存的是「索引列 + 主键值」。所以用二级索引查到后，如果 SELECT 的列不在索引里，还要拿主键再去主键树查一次——这叫回表。
覆盖索引是避免回表的技巧：SELECT order_id, status FROM orders WHERE status = 'paid'，若 (status, order_id) 上有索引，需要的列全在索引里，EXPLAIN 的 Extra 列会显示 Using index，一跳到位。
索引 (a, b, c) 的排序规则是：先按 a 排，a 相同按 b，b 相同按 c。因此它能服务：
WHERE a = 1WHERE a = 1 AND b = 2WHERE a = 1 AND b = 2 AND c = 3但不能直接服务 WHERE b = 2（跳过 a）或 WHERE a = 1 AND c = 3（跳过 b 后 c 不再有序，c 条件只能过滤不能导航）。这就是最左前缀原则：条件必须从索引最左列连续匹配。范围条件（>、<、LIKE 'x%'）之后，索引的导航能力也到此为止，后面的列只能用来过滤。
WHERE DATE(create_time) = '2026-09-27' → 改成范围 create_time >= '2026-09-27' AND create_time < '2026-09-28'。WHERE UPPER(email) = 'A@B.COM'。WHERE phone = 13800000000，列被套了 CAST，索引失效。手机号、验证码列务必用字符串类型并带引号查询。LIKE '%abc' 无法利用有序性；LIKE 'abc%' 可以。WHERE a = 1 OR d = 2，d 无索引时整体退化为全表扫描。!=、NOT IN：选择性太差时优化器宁可全表扫（严格说这是优化器的成本选择，不是绝对失效）。WHERE age + 1 > 30 → 写成 age > 29。EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'paid';
重点看四列：
| 列 | 关注点 |
|---|---|
type |
从好到差大致是 const > eq_ref > ref > range > index > ALL（全表扫描，危险信号） |
key |
实际用了哪个索引；NULL 就是没用 |
rows |
预估扫描行数，越小越好 |
Extra |
Using index（覆盖索引，好事）；Using filesort、Using temporary（通常需要优化） |
EXPLAIN ANALYZE（MySQL 8.0.18+）还能给出实际执行耗时，比预估更可靠。
每个索引都让写入变慢（INSERT/UPDATE 要维护树），还占磁盘。给表设计索引的原则是：按真实查询模式建少量联合索引，而不是给每列都建一个。慢查询日志（slow_query_log + long_query_time = 1）是发现「该建什么索引」的最佳输入。
密码登录暴露在公网上，等于把门交给全世界的爆破脚本。密钥认证则是「你有一把私钥，服务器存着公钥」，即使密码泄露也进不来。
# 本地生成密钥（ed25519 是当前推荐算法，更短更快）
ssh-keygen -t ed25519 -C "alice@laptop"
# 把公钥推送到服务器（仍需密码登录一次）
ssh-copy-id alice@server.example.com
验证 ssh alice@server.example.com 免密登录成功后，再修改服务器 /etc/ssh/sshd_config 加固：
PasswordAuthentication no # 关闭密码登录
PermitRootLogin no # 禁止 root 直连
PubkeyAuthentication yes
:::warning
改配置后不要关闭当前会话，先 sudo systemctl reload sshd，另开终端验证新会话能登录，再退出旧会话。顺序反了可能把自己锁在门外。
:::
私钥设置强口令（passphrase）+ ssh-agent 缓存，兼顾安全与便利：
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519 # 输一次口令，本次会话内免密
本地 ~/.ssh/config 可以给每台服务器起别名、指定端口和密钥：
Host prod
HostName 203.0.113.20
User alice
Port 2222
IdentityFile ~/.ssh/id_ed25519
Host db-via-prod
HostName 10.0.1.15
User dba
ProxyJump prod
之后 ssh prod 即可登录；ssh db-via-prod 通过 prod 作跳板直连内网数据库服务器——ProxyJump（-J）替代了手动两段跳转。
本地转发（-L）：把远端服务「搬到」本地端口。场景：数据库只在服务器内网监听 3306，本地想用 GUI 客户端连接：
ssh -L 13306:127.0.0.1:3306 prod -N
# 本地连接 127.0.0.1:13306，流量经 SSH 隧道到 prod 的 3306
-N 表示只转发不开 shell。语义记忆：-L 本地端口:目标(从SSH服务器视角):目标端口。
远程转发（-R）：把本地服务「暴露」给远端。场景：本地开发了一个 webhook 接收服务，想让外部测试环境回调：
ssh -R 9090:127.0.0.1:3000 prod -N
# 访问 prod 的 9090 端口 = 访问你本地的 3000
注意服务器默认只把转发端口绑在回环上，要对公网开放需服务端开启 GatewayPorts（谨慎评估暴露面）。
动态转发（-D）：开一个 SOCKS5 代理，浏览器或 curl 的全部流量都经服务器出口：
ssh -D 1080 prod -N
curl --socks5 127.0.0.1:1080 https://ifconfig.me # 显示的是 prod 的出口 IP
耗时任务（编译、导入数据、训练）最怕 SSH 断线——进程收到 SIGHUP 直接终止。tmux 让会话运行在服务器端，断线后重连再贴回去：
tmux new -s import # 新建名为 import 的会话
# 在会话里跑长任务；随时 Ctrl+b 然后按 d 脱离（detach）
tmux ls # 查看会话列表
tmux attach -t import # 重新接管
几个高频快捷键（前缀键 Ctrl+b 之后按）：c 新建窗口、数字 切换窗口、% 左右分屏、" 上下分屏、[ 进入滚屏模式（q 退出）。
团队协作时 tmux attach 到同一会话还能实现「双人同屏排障」。
网络不稳时，客户端定时发心跳防止 NAT/防火墙静默断连（写入本地 ~/.ssh/config）：
Host *
ServerAliveInterval 30
ServerAliveCountMax 3
要求更高的场景可以用 mosh（基于 UDP，支持漫游和本地回显），在高铁、弱 Wi-Fi 下体验明显更好，但服务端需额外安装并放行 UDP 端口。
man 1 ssh、man 5 ssh_config、man 5 sshd_configMAS（Microsoft Activation Scripts） 是由 massgrave 维护的一套开源激活脚本集合，它提供了多种激活 Windows 与 Microsoft Office 的方式，所有操作通过 PowerShell 一行命令即可完成。
本文整理了 MAS 的三种核心激活模式：HWID（Windows 永久数字许可）、Ohook（Office 永久激活）、KMS（通用 180 天续期模式），供有正版授权但遇到激活问题的用户参考。
⚠️ 本文面向已持有合法正版授权或可接受开源工具试用的读者。请遵守当地法律法规与 Microsoft 服务条款。
PowerShell 或 pwshPowerShell 窗口标题会显示「管理员」字样，确认无误后再继续。
在管理员 PowerShell 中复制粘贴以下命令并回车：
irm https://get.activated.win | iex
如果官方链接不稳定，可以使用镜像：
irm https://zf.meow.us.kg/https://get.activated.win | iex
脚本执行后会弹出交互式菜单：
Microsoft Activation Scripts (MAS)
1. HWID [Windows 永久激活]
2. Ohook [Office 永久激活]
3. AAct [可选，支持更多产品]
4. KMS38 / Online KMS [180 天续期]
5. 查看当前激活状态
0. 退出
HWID 是 MAS 最受欢迎的功能。它会生成与你的机器硬件指纹绑定的数字授权，写入系统后由 Microsoft 官方服务器在线识别——效果等同于原生数字激活，重装系统后只要硬件不变会自动恢复激活。
适用场景：
操作步骤：在菜单中按 1，脚本会自动执行硬件指纹采集、公钥上传和许可证写入，全程无需人工干预。完成后系统提示 Activation successful 即成功。
Ohook（Office Hoook）采用 Hook 方式在 Office 运行时拦截授权校验，实现永久激活。
适用场景：
操作步骤：先确保 Office 已安装，在菜单中按 2，脚本会自动完成 Ohook 的部署。
KMS（Key Management Service）是 Microsoft 官方设计的企业批量授权机制。通过 KMS 续期激活后，每 180 天自动向 KMS 服务器续一次，实际使用体验等同于永久。
适用场景：
操作步骤：在菜单中按 4，脚本会自动寻找可用 KMS 服务器并配置自动续期计划任务。
方式一：系统设置
设置 → 系统 → 激活，页面会显示激活状态。
方式二：命令行
slmgr /xpr
弹出窗口会显示激活期限。若为 HWID 激活则显示「永久许可证」。
打开任意 Office 应用（Word / Excel / PowerPoint），进入 账户 页面：
也可以通过命令查看：
# 找到 Office 安装路径（常见）
cd "C:\Program Files\Microsoft Office\Office16"
cscript ospp.vbs /dstatus
不会。HWID 激活绑定的是你的主板 MAC 地址、TPM、CPU 等硬件指纹，Microsoft 服务器端存储该指纹与合法许可证的映射。只要硬件不发生大规模更换（如换主板），重装 Windows 后首次联网会自动识别并重新激活。
Ohook 是运行时 Hook，不会篡改 Office 安装包或注册表核心键，Windows 更新和 Office 更新通常不会将其视为异常。但它无法通过 Microsoft Online 账户的设备管理页面查询到。
MAS 是 GitHub 上高星（>20k stars）的开源项目，源码全部公开可审计。建议：
irm https://raw.githubusercontent.com/massgrave/Microsoft-Activation-Scripts/master/MAS/All-In-One-Version/MAS_AIO.cmd | iex 指向官方仓库 raw 地址可以。先执行模式 1 激活 Windows，再执行模式 2 或 4 激活 Office，两次操作互不干扰。
MAS 本身是 PowerShell 脚本，不含病毒。个别安全软件对未知签名脚本会有提示，属于正常行为。如果下载受阻，可以先临时关闭实时防护再运行，运行完毕后重新开启。
先在本机确认监听状态：
ss -tlnp | grep 8080
ss 是 netstat 的现代替代（更快、信息更全）。选项：-t TCP、-l 监听中、-n 数字端口、-p 显示进程。输出看两点：
Local Address 是 0.0.0.0:8080（监听所有网卡）还是 127.0.0.1:8080（只听回环）。外网连不上而本机 curl 通，八成是服务只监听了 127.0.0.1，改配置绑到 0.0.0.0 或具体网卡。本机监听正常，再从外部测连通性：
# 在客户端执行
curl -v telnet://服务器IP:8080 # 或 nc -vz 服务器IP 8080
连接超时（timeout）= 中间有设备丢包，查防火墙/安全组；连接拒绝（refused）= 包到了但没人接，回到上一步查监听。这个「超时 vs 拒绝」的区分是最有价值的判断。
防火墙检查（在服务器上）：
sudo iptables -L -n | grep 8080 # 或 nft list ruleset
sudo firewall-cmd --list-ports # firewalld 系
# 云服务器还要检查控制台的安全组规则
分层验证，从近到远：
ip addr # 网卡有没有拿到 IP
ip route # 默认网关是否存在
ping -c 4 网关IP # 局域网通不通
ping -c 4 223.5.5.5 # 出网通不通（用 IP 排除 DNS 干扰）
ping -c 4 example.com # DNS 是否正常
哪一步失败就停在哪一层：网关不通查网线和交换机，IP 通而域名不通去查 DNS（参考本系列 DNS 一文），都通但应用不通回到症状一。
ping 只能告诉你「到终点丢不丢」，定位「在哪一跳开始丢」用 mtr（My Traceroute）：
mtr -rwbzc 100 目标IP # 发 100 个包，输出报告模式
报告里逐跳显示丢包率和延迟。判读要点：从某一跳开始丢包率显著升高且延续到终点，那一跳附近就是问题点；中间某跳丢包但终点不丢，多半是该设备限速响应 ICMP，属误报。mtr 同时给出 Best/Wrst/Avg 延迟，看抖动比看平均值更有用。
带宽是否跑满用 iperf3 两台机器对测；实时看网卡流量用 iftop 或 nload。
「间歇性断连」「应用说收到了乱码」这类问题只能靠看报文。tcpdump 常用模式：
# 抓与某主机的 HTTP 流量并显示内容
sudo tcpdump -i any -nnA 'host 203.0.113.5 and port 80'
# 只看 TCP 标志位（找 RST、重传）
sudo tcpdump -i any -nn 'tcp[tcpflags] & tcp-rst != 0'
# 写到文件，回头用 Wireshark 分析
sudo tcpdump -i any -nn -w /tmp/issue.pcap 'port 3306'
生产环境抓包务必加过滤条件并限制数量（-c）或文件大小（-C/-W），避免打满磁盘。.pcap 文件传到本地用 Wireshark 打开，「Follow TCP Stream」能把一条连接的完整会话重组出来，排查应用层问题极其高效。
| 症状 | 第一工具 | 判断依据 |
|---|---|---|
| 端口不通 | ss -tlnp + 客户端 nc |
超时=丢包，拒绝=未监听 |
| 整网不通 | ip route、ping 分层 |
从网关向外逐层推进 |
| 慢/丢包 | mtr |
找丢包率跳变的那一跳 |
| 带宽跑满 | iperf3、iftop |
确认瓶颈在链路还是应用 |
| 间歇断连 | tcpdump + Wireshark |
看 RST 出现在哪一侧 |
排错的通用节奏是：先本机（监听、防火墙）→ 再链路（ping/mtr）→ 最后报文（tcpdump）。每用一个工具都要能回答「这个结果排除了什么可能性」，工具才不会白用。
man 8 ss、man 8 mtr、man 8 tcpdumpcurl -v 输出的每一行都对应协议栈里的一个阶段。学会读它，HTTP/HTTPS 问题就排掉了一半。本文以一次真实请求为样本，讲清 HTTP 报文结构、TLS 握手在干什么、证书报错怎么定位。
curl -v https://example.com/
> 开头是客户端发出的，> 之外带 < 的是收到的，* 是 curl 自己的注释。发出部分：
GET / HTTP/2
Host: example.com
User-Agent: curl/8.x
Accept: */*
这就是 HTTP 请求报文的全部骨架：请求行（方法 + 路径 + 版本）+ 首部（键值对）+ 可选的请求体。响应同理：状态行（HTTP/2 200）+ 首部 + 正文。
要单独看首部用 curl -I（发 HEAD 请求）；要忽略正文只看交换过程用 curl -sv https://... -o /dev/null。
curl -v 里 * 部分有一段 TLS 日志：
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
握手的两个目标：协商加密参数和验证服务器身份。
对使用者来说结论很简单：TLS 1.3 更快更安全，服务端应优先启用并保留 1.2 兜底，1.0/1.1 必须禁用。
服务器在握手中出示的不是一张证书，而是一条链：
服务器证书（example.com）
↑ 由 中间 CA（如 R3）签发
↑ 由 根 CA（如 ISRG Root X1）签发 ← 预置在操作系统/浏览器信任库
验证逻辑：逐级用上级公钥校验签名，直到碰到信任库里已有的根。中间证书必须由服务器一起下发——最常见的「浏览器正常、curl/旧安卓报证书错误」，就是服务器漏配中间证书（fullchain），浏览器能自动补齐而别的客户端不能。
用 OpenSSL 查看证书细节：
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
-dates 看有效期（过期是第二大常见故障），-servername 用于一台服务器托管多个 HTTPS 站点（SNI）时指定域名。
| curl 报错 | 含义 | 处理 |
|---|---|---|
certificate has expired |
证书过期 | 续期，检查自动续期任务是否失效 |
unable to get local issuer certificate |
服务器没发中间证书，或本地 CA 库太旧 | 服务端配置 fullchain；客户端更新 ca-certificates |
subject name mismatch |
证书域名与访问域名不符 | 证书上 SAN 没包含该域名（注意 www. 前缀差异） |
self signed certificate |
自签名证书 | 内网可 -k 跳过或分发 CA；公网换正规证书 |
:::warning
curl -k（不验证证书）只能在临时测试时使用。写进脚本等于放弃了 HTTPS 防中间人攻击的核心价值。
:::
接口慢，到底是 DNS 慢、握手慢还是服务器处理慢？
curl -so /dev/null -w 'DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s 首字节:%{time_starttransfer}s 总:%{time_total}s\n' https://example.com/
time_connect - time_namelookup ≈ TCP 握手耗时（约等于 RTT）；time_appconnect - time_connect ≈ TLS 握手耗时；time_starttransfer - time_appconnect ≈ 服务器处理并返回首字节的耗时。一眼就能看出慢在哪一段，比凭感觉猜高效得多。
HTTP/2 在单条 TCP 连接上多路复用（解决 HTTP/1.1 队头阻塞），首部走 HPACK 压缩；HTTP/3 把底层换成基于 UDP 的 QUIC，进一步消除 TCP 层队头阻塞并改善弱网切换。对开发者透明——curl 和浏览器会自动协商（curl -v 里能看到 ALPN: server accepted h2），服务端用 Nginx/云 CDN 开启即可。
应用发起解析（如 curl 访问 example.com）时，典型的查找顺序：
chrome://net-internals/#dns 可查看。/etc/hosts，优先级最高。/etc/resolv.conf 里配置的 DNS。223.5.5.5（阿里）、119.29.29.29（腾讯）、8.8.8.8（Google）。它代替客户端完成剩下的全部工作。递归解析器手上没有答案时，执行迭代查询：问根服务器（.）→ 得到 .com 顶级域服务器地址 → 问顶级域 → 得到 example.com 权威服务器地址 → 问权威 → 拿到 A 记录。结果按 TTL 缓存后返回给客户端。
递归 vs 迭代一句话区分：递归是「你给我最终答案」（客户端↔解析器），迭代是「你告诉我下一步问谁」（解析器↔各级服务器）。
dig（bind-utils / dnsutils 包）是 DNS 排障的标准工具。基础用法：
dig example.com # 用系统默认解析器查 A 记录
dig example.com A +short # 只要答案：IP
dig example.com AAAA +short # IPv6
dig example.com MX # 邮件记录
dig example.com NS # 权威服务器
dig @223.5.5.5 example.com # 指定解析器，绕开本机配置
dig -x 93.184.216.34 # 反解 PTR
输出里先看三个位置：
status: NOERROR：查询成功；NXDOMAIN 表示域名不存在；SERVFAIL 通常是解析器或权威故障。ANSWER SECTION：真正的答案和 TTL。SERVER: 127.0.0.53#53：这次是谁回答的——判断是否命中本地缓存的关键。逐跳追踪：dig example.com +trace 从根开始把迭代过程完整走一遍，可以定位「到底是哪一级给的答案不对」。
1. 别人能打开，我这台机器打不开。 先 dig example.com 对比 dig @223.5.5.5 example.com。默认解析器答案错、公共解析器答案对 → 本机 DNS 配置或运营商劫持问题，检查 /etc/resolv.conf。两者都错 → 域名本身的问题。
2. 刚改了 DNS 记录，有的生效有的不生效。 TTL 缓存所致。dig example.com 看 ANSWER 里的 TTL 秒数和 SERVER 是谁——不同递归解析器缓存过期时间不同，全球生效需要等到旧记录 TTL 全部到期。变更前把 TTL 临时调低（如 300 秒）是标准操作。
3. 域名能解析，但 IP 不对。 检查 /etc/hosts 是否有人写过静态映射；再确认查的记录类型对不对——把 AAAA 当 A 看会以为「解析异常」。
4. 内网域名解析失败。 内网域名通常只存在于内网 DNS。dig @内网DNS地址 域名 能通而默认不行，说明 /etc/resolv.conf 没指向内网 DNS，或 systemd-resolved 的分流规则没配对。
:::warning
/etc/resolv.conf 在很多发行版上由 NetworkManager / systemd-resolved / 云厂商 cloud-init 自动管理，手改后会被覆盖。要持久修改，应改对应管理器的配置（如 /etc/systemd/resolved.conf 或 Netplan/NetworkManager 的连接配置）。
:::
| 类型 | 作用 | 注意点 |
|---|---|---|
| A / AAAA | 域名 → IPv4 / IPv6 | 一个域名可有多条，客户端轮询 |
| CNAME | 域名 → 另一个域名 | 不能与其他记录共存在同名节点；根域名（如 example.com）按标准不应使用 CNAME |
| MX | 邮件投递目标 | 指向域名，优先级数字越小越优先 |
| TXT | 任意文本 | SPF 反垃圾、域名所有权验证都靠它 |
| NS | 指定该域的权威服务器 | 改 NS 等于把整个域的解析权移交 |
| PTR | IP → 域名（反解） | 邮件服务器常校验，普通网站可不管 |
DNS 排障的核心动作只有三个：对比不同解析器的答案（dig @）、看状态码和 TTL、必要时 +trace 走全程。先确认「解析出来的 IP 对不对」，再去怀疑网络和服务器——顺序反了会浪费大量时间。
tcpdump 在本地抓一次完整连接，逐包对照。
开两个终端。终端 A 抓包：
sudo tcpdump -i any -nn 'tcp port 8000 and host 127.0.0.1' -c 20
终端 B 起一个简单的 HTTP 服务并访问它：
python3 -m http.server 8000 &
curl -s http://127.0.0.1:8000/ > /dev/null
（-nn 不做域名/端口名解析，输出更快更直观。）
抓到的前三行类似：
IP 127.0.0.1.53462 > 127.0.0.1.8000: Flags [S], seq 3829000, ...
IP 127.0.0.1.8000 > 127.0.0.1.53462: Flags [S.], seq 871000, ack 3829001, ...
IP 127.0.0.1.53462 > 127.0.0.1.8000: Flags [.], ack 871001, ...
标志位对照：[S] = SYN，[.] = 纯 ACK，[S.] = SYN+ACK。
每个包在做的事：
为什么是三次而不是两次？ 因为双方都要确认对方的初始序号。第二次握手把「服务端的 SYN」和「对客户端的 ACK」合并在一个包里，所以三次就够了。只握手两次的话，服务端无法确认客户端真的收到了自己的序号——一个延迟到达的旧 SYN 就可能让服务端白白建立连接浪费资源，三次握手用第三个 ACK 杜绝了这种情况。
中间 Flags [P.] 的是带数据的包（PSH）。结束时：
IP ...8000 > ...53462: Flags [F.], seq ..., ack ... # 服务端 FIN
IP ...53462 > ...8000: Flags [.], ack ... # 客户端 ACK
IP ...53462 > ...8000: Flags [F.], seq ..., ack ... # 客户端 FIN
IP ...8000 > ...53462: Flags [.], ack ... # 服务端 ACK
为什么挥手是四次？ 因为 TCP 是全双工的，两个方向要分别关闭。一端发 FIN 只表示「我没数据要发了」，另一端的 ACK 确认后，反向通道还能继续传数据——这叫半关闭（half-close）。等对端也发 FIN 并收到 ACK，连接才真正结束。HTTP/1.1 短连接里通常是服务端先发 FIN（如本例）。
TIME_WAIT：主动关闭方在发完最后一个 ACK 后等待 2 倍 MSL（报文最大生存时间，Linux 默认合计约 60 秒）。它在防两件事：最后一个 ACK 丢了可以重发；旧连接的迟到报文不会混进下一条同五元组的新连接。用 ss -tan state time-wait | wc -l 可以统计。高并发短连接的机器上 TIME_WAIT 堆积是正常现象，只有当它耗尽端口资源（ss -s 查看）时才需要调优（如开启 tcp_tw_reuse 或改用长连接），不要盲目调小。
CLOSE_WAIT：被动关闭方收到 FIN 回复 ACK 后进入的状态，意味着「对端已关闭，但本端应用还没调用 close()」。大量 CLOSE_WAIT 几乎总是应用代码没正确关闭连接，属于程序 bug，不是系统参数能调的。
| 现象 | 抓包特征 | 常见原因 |
|---|---|---|
| 连接超时 | 只有 SYN 发出，无回应 | 防火墙丢包、对端不存在 |
| 连接被拒 | SYN 后立即收到 [R.]（RST+ACK） |
端口没人监听 |
| 连接突然断开 | 中途出现 [R] |
应用崩溃、中间设备超时 |
| 大量重传 | 同一序号反复出现 | 丢包、链路质量差 |
tcpdump 输出里 ack 值长期不动说明对方数据没被确认，也是定位单向丢包的线索。
握手三次 = 双方各发一次 SYN、各确认一次；挥手四次 = 全双工两个方向各关一次。抓一次包比背十遍定义更有用——下次看到 ss -tan 里的状态时，你脑子里浮现的会是报文本身。
man 8 tcpdump、man 8 ss| 层 | 解决的问题 | 关键概念 | 常见协议 |
|---|---|---|---|
| 应用层 | 数据的内容是什么 | 请求/响应、域名 | HTTP、DNS、SSH |
| 传输层 | 交给本机哪个进程、要不要可靠 | 端口、连接 | TCP、UDP |
| 网际层 | 送到哪台主机 | IP 地址、路由 | IP、ICMP |
| 网络接口层 | 怎么在物理链路上传 | MAC 地址、帧 | Ethernet、Wi-Fi |
类比寄快递：你写的信是应用层内容；信封上写「某公司前台转张三」相当于传输层指定接收人（端口）；收件地址的城市街道是网际层负责的跨网络寻址；而快递车在高速上一站站转运，是网络接口层的事。
假设浏览器访问 http://192.168.1.20:8080/hello：
GET /hello HTTP/1.1\r\nHost: ...。每层都把上一层的整体当作「数据」原样打包，自己只关心自己加的首部——这就是封装。
数据包从你的电脑到服务器，会经过交换机和路由器：
所以 MAC 地址每过一台路由器就换一次（只负责「本段链路内的下一跳」），而 IP 地址全程不变（负责「最终目的地」）。这正回答了「有了 IP 为什么还要 MAC」：IP 是端到端的全局寻址，MAC 是逐跳的局部交付。
服务器网卡收到帧，逐级向上：
发送方的「封装」和接收方的「解封装」完全对称。同层之间仿佛在直接对话——TCP 不知道自己经过了几个路由器，HTTP 也不知道下面是 TCP 还是别的什么，这正是分层带来的解耦。
| 地址 | 长度 | 作用范围 | 类比 |
|---|---|---|---|
| MAC | 48 bit | 同一段链路/局域网 | 快递员手上这一站的交接对象 |
| IP | 32 bit（v4）/128 bit（v6） | 跨网络端到端 | 快递单上的收件地址 |
| 端口 | 16 bit | 主机内部区分进程 | 收件地址里的「转交某部门」 |
完整标识一条连接的是五元组：协议 + 源 IP + 源端口 + 目标 IP + 目标端口。这就是为什么同一台服务器能同时承载成千上万个 TCP 连接而不混乱。
分层模型不是考试知识点，而是排障的决策树：能 ping 通但打不开网页，说明三层以下通、问题在四层以上；curl 返回 403，说明 TCP 都正常，问题在应用层。后续文章讲的抓包、DNS 排查，都是把这一模型落到具体工具上。
.deb 包），RHEL/CentOS/Fedora/Rocky 用 DNF（.rpm 包，YUM 的后继）。本文给出对照速查，并讲几件手册之外但天天会碰到的事。
| 目的 | APT (Debian/Ubuntu) | DNF (RHEL 系) |
|---|---|---|
| 刷新软件源索引 | sudo apt update |
sudo dnf check-update（通常可省，自动刷新） |
| 安装 | sudo apt install nginx |
sudo dnf install nginx |
| 升级全部 | sudo apt upgrade |
sudo dnf upgrade |
| 卸载 | sudo apt remove nginx |
sudo dnf remove nginx |
| 卸载+清配置 | sudo apt purge nginx |
sudo dnf remove nginx（rpm 无独立配置清理，需手动删） |
| 搜索 | apt search 关键词 |
dnf search 关键词 |
| 查看包信息 | apt show nginx |
dnf info nginx |
| 列出包内文件 | dpkg -L nginx |
rpm -ql nginx |
| 查文件属于哪个包 | dpkg -S /usr/sbin/nginx |
rpm -qf /usr/sbin/nginx 或 dnf provides */nginx |
| 清理不用的依赖 | sudo apt autoremove |
sudo dnf autoremove |
apt update 只是从软件源下载最新的包索引（有哪些包、什么版本），系统上的软件一个都没动。真正的升级是 apt upgrade。所以正确流程是两条一起跑：
sudo apt update && sudo apt upgrade -y
只跑第二条会用旧索引升级，经常提示「已是最新」而实际上源里有新版。DNF 系没有这个问题，dnf upgrade 会自动刷新元数据。
另外区分：apt full-upgrade（旧称 dist-upgrade）允许为升级而增删包，内核大版本、桌面环境升级时才需要；日常安全更新用 upgrade 即可。
服务器上发现一个陌生文件 /usr/local/bin/xyz，想知道是不是包管理器装的：
# Debian 系
dpkg -S /usr/local/bin/xyz
# RHEL 系
rpm -qf /usr/local/bin/xyz
如果查不到，说明它是手工编译安装或脚本释放的，卸载和升级都得自己管。反过来，想找「提供 dig 命令的包叫什么」：
apt-file search bin/dig # 需先装 apt-file
dnf provides '*/bin/dig' # DNF 原生支持路径通配
答案分别是 dnsutils（新版为 bind9-dnsutils）和 bind-utils——包名和命令名不一致是常态，查一下比猜快。
数据库这类对版本敏感的服务，你可能不希望它被 upgrade 顺手升级：
# APT
sudo apt-mark hold mysql-server # 锁定
sudo apt-mark unhold mysql-server # 解锁
apt-mark showhold # 查看锁定列表
# DNF（需 versionlock 插件）
sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock add mysql-server
锁定只是「不自动升」，手动 install 包名=版本号 仍可指定版本。
apt remove 会保留配置文件（方便重装后找回配置），要彻底清理用 purge。装包时被顺带拉进来的依赖，卸载主包后不会自动消失，定期 sudo apt autoremove --purge 保持系统干净。
DNF 的 remove 默认行为接近 remove + autoremove 的组合（会提示移除孤儿依赖），但 /etc 下手工改过的配置文件不会动，需要时手动删。
-y 盲升：先 apt list --upgradable 或 dnf check-update 看看要动哪些包，数据库、内核类单独安排窗口。.deb 包强行装在不匹配的发行版版本上，依赖地狱就是这么来的。优先用官方源，第三方源确认其支持你的发行版代号。needrestart（Debian）或 dnf needs-restarting -r 可以告诉你哪些服务或系统本身需要重启。/opt、~/bin、或 Flatpak/AppImage，别把手工编译的东西塞进 /usr/bin，与包管理器抢地盘。man 8 apt、man 8 dnf、man 1 dpkg、man 8 rpmsystemctl 管服务，用 journalctl 看日志。本文再进一步：写一个自己的 unit 文件，把脚本变成受管服务。
systemctl status nginx # 状态 + 最近几行日志
sudo systemctl start nginx # 启动
sudo systemctl stop nginx # 停止
sudo systemctl restart nginx # 重启
sudo systemctl reload nginx # 重载配置（进程不中断，需服务支持）
sudo systemctl enable nginx # 开机自启（不改当前状态）
sudo systemctl enable --now nginx # 自启 + 立即启动
sudo systemctl disable --now nginx # 取消自启并停止
status 输出里最值钱的两行：Active: active (running) since ... 和 Main PID。如果看到 failed，先别急着 restart——失败原因往往就在 status 显示的最近日志里。
几个容易混淆的点：
enable 只管开机自启，不影响当前运行状态；--now 把两件事一起做。reload 依赖服务自己支持（ExecReload），不支持时会报错，这时只能用 restart。systemctl is-active nginx、is-enabled、is-failed 返回简单状态，适合写脚本判断。unit 文件通常在 /etc/systemd/system/（自定义）和 /usr/lib/systemd/system/（软件包安装）下。systemctl cat nginx 能直接查看。
一个最小可用的自定义服务，把 /opt/myapp/run.sh 变成服务：
[Unit]
Description=My App
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/run.sh
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
三个段落的分工：
[Unit]：元信息和启动顺序。After=network-online.target 保证网络就绪后再启动——依赖网络的服务只写 network.target 是不够的。[Service]：怎么跑。Type=simple 表示 ExecStart 的进程就是主进程；Restart=on-failure 异常退出时自动拉起；User= 让服务以非 root 身份运行，是安全基线。[Install]：何时被启用。WantedBy=multi-user.target 表示 enable 后随正常多用户模式启动。改完 unit 文件必须执行 sudo systemctl daemon-reload 让 systemd 重新读取，然后 sudo systemctl enable --now myapp。
:::tip
想让用户自己的脚本免 root 开机运行，可以用 loginctl enable-linger 用户名 加 systemctl --user 体系，比往系统服务里塞更干净。
:::
systemd 把服务标准输出、错误输出和内核日志统一收进 journal。基本用法：
journalctl -u myapp # 某个服务的全部日志
journalctl -u myapp -n 200 # 最近 200 行
journalctl -u myapp -f # 实时跟踪（类似 tail -f）
journalctl -u myapp --since "1 hour ago"
journalctl -u myapp --since "2026-09-12 20:00" --until "2026-09-12 21:00"
journalctl -p err # 只看 err 及以上优先级（所有服务）
journalctl -k # 内核日志（等价 dmesg）
journalctl -b # 本次开机以来的日志
journalctl --disk-usage # 日志占了多少磁盘
两个实用技巧：
-o json-pretty 输出完整结构化字段，能看到 _PID、_EXE 等元数据，写日志收集脚本时用得上。-x 给部分日志附加解释文字（如 OOM、core dump），排障时值得一看。systemctl status myapp：看退出码和最后几行输出。journalctl -u myapp -n 100 --no-pager：看完整错误。status=203/EXEC：ExecStart 路径错误或文件不可执行；status=217/USER：User= 指定的用户不存在；code=exited, status=1：程序自己报错，去读程序日志；User= 是否可写。daemon-reload（改了 unit 才需要）→ reset-failed → start。journal 默认持久化程度因发行版而异：/var/log/journal/ 存在才持久，否则重启即丢。生产机器建议确认 Storage=persistent（/etc/systemd/journald.conf），并用 SystemMaxUse= 限制体积。
man 5 systemd.service、man 1 journalctl、man 5 journald.confps、top、信号这三件事按这个流程组织起来。
ps -eo pid,ppid,user,stat,etime,%cpu,%mem,args --sort=-%cpu | head
这条命令按 CPU 占用倒序列出前几个进程。各列含义：PPID 是父进程，STAT 是状态，ETIME 是运行时长，ARGS 是完整命令行。
如果已经知道名字，pgrep -af nginx 直接列出 PID 和命令行；pgrep -x 要求进程名精确匹配，避免误伤。要按内存排序就把 --sort=-%cpu 换成 --sort=-%mem。
| 状态 | 含义 | 该担心吗 |
|---|---|---|
| R | 运行中或排队等 CPU | 多核机器上大量 R 说明 CPU 饱和 |
| S | 可中断睡眠（在等事件） | 正常服务大多时间在此状态 |
| D | 不可中断睡眠（等 I/O） | 持续 D 状态指向磁盘/NFS 故障，查 dmesg |
| T | 被暂停 | 谁按了 Ctrl+Z 或发了 STOP？ |
| Z | 僵尸 | 父进程没回收，杀它没用，要找父进程 |
僵尸进程本身不耗资源，只是进程表里的一个条目，正确做法是重启它的父进程。ps -eo ppid,stat,args | awk '$2 ~ /Z/' 可以快速找到僵尸的父进程。
top 打开后几个按键显著提高效率：
1：展开每个 CPU 核心的使用率，判断是单线程打满还是整体饱和。M：按内存排序，P 回到按 CPU 排序。c：显示完整命令行。k：在 top 里直接发信号（输入 PID 和信号编号）。头部 load average 三个值是 1/5/15 分钟的平均负载。经验法则：负载长期超过 CPU 核心数，说明有进程在排队。但负载高不等于 CPU 高——大量 D 状态进程等磁盘也会推高负载，需要结合 %wa（iowait）一起看。
信号是发给进程的「通知」，进程可以决定怎么响应。常用的三个：
| 信号 | 编号 | 行为 |
|---|---|---|
| TERM | 15 | 请求退出，程序可以捕获并做清理（关闭连接、写盘） |
| HUP | 1 | 挂起；许多守护进程约定为重载配置 |
| KILL | 9 | 内核直接终止，不给程序任何清理机会 |
正确顺序是先 TERM，等几秒，再考虑 KILL：
kill 12345 # 默认发 TERM
sleep 5
kill -0 12345 2>/dev/null && kill -9 12345 # 还活着才补 KILL
kill -9 的代价：事务没写完、锁没释放、临时文件残留。对数据库类进程尤其危险。kill -0 不真的发信号，只探测进程是否存在。
别用 killall 名字 或 pkill 模式 模糊批量杀，测试环境和生产环境混用的机器上很容易误伤。
如果进程是由 systemd 管理的服务，直接 kill 会被 Restart= 策略自动拉起来，越杀越多。正确入口：
systemctl status myapp # 看状态和最近日志
sudo systemctl stop myapp # 停止
journalctl -u myapp -n 100 # 看日志
判断进程归谁管：systemctl status <PID> 直接传 PID 也行，会显示它属于哪个 unit。
症状：网站响应慢。
top 发现 load 12（8 核），按 1 看 CPU 有空闲，但 %wa 高达 40%——瓶颈在 I/O。ps -eo pid,stat,args | awk '$2 ~ /D/' 找到一批 D 状态的备份脚本进程。dmesg | tail 看到磁盘 I/O error——是硬件/存储层问题，不是业务进程的问题。工具只是入口，「先形成假设、再找证据」才是排障的核心。
man 1 ps、man 1 top、man 7 signalPermission denied 是 Linux 新手最高频的报错。排查它需要的不是背 chmod 数字，而是一张决策图：进程以谁的身份运行？路径每一级目录能不能进？文件本身让不让读写？本文先把权限模型讲清楚，再用一个共享目录案例把 umask、SGID、ACL 串起来。
ls -l 输出的 -rw-r--r-- 分四段：文件类型 + 属主权限 + 属组权限 + 其他人权限。文件和目录上，同样字母含义不同：
| 权限 | 对文件 | 对目录 |
|---|---|---|
| r | 读内容 | 列出文件名 |
| w | 改内容 | 增删改目录项（需配合 x） |
| x | 作为程序执行 | 进入目录、访问其中已知名字的对象 |
最容易误判的是目录的 x 权限：文件本身可读，但路径上任何一级目录没有 x，照样打不开。用 namei -l /srv/app/data/config.yml 可以把路径逐级权限一次列出来，是排查权限问题的首选命令。
另一个反直觉点：删除文件看的是父目录的 w+x，与文件本身是否可写无关。这就是为什么 /tmp 里自己的文件能被自己删掉，而 sticky bit（t）又阻止你删别人的文件。
r=4, w=2, x=1 按位相加：644 = 属主读写、组内只读、其他人只读；755 = 属主全权、其他人可读可进入。修改归属需要管理员权限：
chmod 640 report.txt # 或 chmod u=rw,g=r,o= report.txt
chown alice:project report.txt
:::warning
chmod -R 777 不是权限问题的解药，它只是把门拆了。先 namei -l 找到真正缺失的权限位。
:::
程序创建文件时会声明一个期望权限（普通文件通常 666，目录 777），umask 负责屏蔽其中部分位：umask 为 022 时，新文件是 644、新目录是 755。注意它是按位掩码，不是算术减法——umask 011 作用于 666 得到的是 666 而非 655（奇数位本来就没有执行位可减）。
umask 命令查看当前值。改 umask 只影响之后创建的文件，已有文件不受影响。
目标：project 组的成员都能在 /srv/project 里协作，新建文件自动继承组归属，组内成员默认可互相修改。
sudo groupadd -f project
sudo usermod -aG project alice # 把成员加入组（重新登录生效）
sudo mkdir -p /srv/project
sudo chown root:project /srv/project
sudo chmod 2775 /srv/project
sudo setfacl -d -m g:project:rwx /srv/project
逐条解释：
2775 中的 2 是 SGID 位：目录带 SGID 后，其中新建的文件和子目录自动继承 project 组，而不是创建者的私人主组——这是共享目录的关键。-d）：仅靠 SGID 只解决「组归属」，不解决「组内可写」——如果成员的 umask 是 022，新文件的组权限仍没有 w。默认 ACL 强制组内新建对象带 rwx，绕开各成员 umask 不一致的问题。验证：两名成员各自 touch 一个文件，互相 getfacl 确认 effective 权限含 w，再交叉修改一次。
| 症状 | 先查 | 常见根因 |
|---|---|---|
| 文件明明存在却说找不到 | namei -l |
某级父目录缺 x |
| 能读不能改 | ls -l、getfacl |
缺 w，或 ACL mask 收窄 |
| 能改不能删 | 父目录权限 | 父目录缺 w+x，或有 sticky bit |
| 加组后还是 denied | 重开终端后 id |
会话未刷新 |
| 权限全对仍拒绝 | getenforce、dmesg |
SELinux/AppArmor 策略 |
能用到组权限解决的共享问题，就不要发 sudo。确实需要授权时，用 visudo -f /etc/sudoers.d/team 写只覆盖必要命令的规则，例如只允许重启指定服务：
%project ALL=(root) /usr/bin/systemctl restart myapp
允许 sudo vim、sudo bash 或执行用户可写的脚本，等于把整个 root 交出去。
man 5 acl、man 1 namei、man 5 sudoers脚本开头建议固定写上：
#!/usr/bin/env bash
set -euo pipefail
三个选项各自的含义：
-e（errexit）：任何命令返回非零退出码，脚本立即退出。没有它，备份脚本里「进入目录失败」之后，rm 照样会在错误的位置执行。-u（nounset）：使用未定义的变量直接报错。把 rm -rf "$bakup_dir/"（手滑拼错变量名，展开为空）这类事故扼杀在摇篮。pipefail：管道中任一环节失败，整条管道算失败。grep error app.log | wc -l 在日志文件不存在时默认仍返回 0 并输出 0，开了 pipefail 才会暴露 grep 的报错。注意 -e 有些反直觉的例外：if 条件里、&&、|| 左侧的命令失败不会触发退出，这是特意保留的判断能力。
单词分割是 Bash 事故第一大来源。文件名含空格时：
file="daily report.txt"
cat $file # 报错：被拆成 "daily" 和 "report.txt" 两个参数
cat "$file" # 正确：作为一个参数
规则只有一条：变量展开一律加双引号，除非你明确需要分词（很少见）。相关约定：
$( ) 而不是反引号，可嵌套、可读性好。readonly BACKUP_DIR=/data/backup，脚本开头的配置项建议大写。[ -n "$dir" ] || { echo "dir 为空" >&2; exit 1; }。[ ] 是命令不是语法糖，常见判断：
[ -f /etc/nginx/nginx.conf ] # 文件存在
[ -d /var/log ] # 目录存在
[ -z "$var" ] # 字符串为空
[ "$code" -eq 200 ] # 数值比较用 -eq/-ne/-gt/-lt
[ "$ans" = "y" ] # 字符串比较用 =
判断上一条命令成败，直接把它放进 if：
if systemctl is-active --quiet nginx; then
echo "nginx 运行中"
else
echo "nginx 已停止，尝试启动" >&2
sudo systemctl start nginx
fi
不要先执行命令再判断 $?，那会让 set -e 提前把脚本杀掉。
脚本的输出分两类：结果是 stdout，诊断信息走 stderr（>&2）。这样 脚本 > result.txt 不会把日志混进数据。一个简单可用的日志函数：
log() { printf '[%s] %s\n' "$(date '+%F %T')" "$*" >&2; }
循环里处理文件列表，用 find -print0 配合 read -d ''，避免文件名含空格、换行时出错：
find /data -name '*.tmp' -print0 | while IFS= read -r -d '' f; do
rm -- "$f"
done
「手动跑没问题，cron 里就失败」几乎总是环境差异：cron 的 PATH 很短、没有交互终端、工作目录不同。对策：
export PATH=/usr/local/bin:/usr/bin:/bin；>> /var/log/myjob.log 2>&1，留好现场；ShellCheck 是 Bash 静态检查工具，能抓出未加引号、弃用语法、误判退出码等绝大多数低级错误：
shellcheck backup.sh
把它当成 Bash 的编译器警告来对待，告警清零再上线。配合上面这套骨架，脚本的可靠性会提升一个量级。
普通编辑器里，键盘的每个键都用来输入字符；Vim 把键盘复用了：普通模式下按键是命令（删除、跳转、复制），插入模式下按键才是输入文本，可视模式用来选区，命令行模式用来执行保存、查找等动作。
刚接触时最大的混乱来源是「不知道自己处于哪个模式」。两条救命规则：
Esc，连按几下一定回到普通模式；:q! 回车，不保存强制退出——这是你误进 Vim 的逃生门。服务器改配置，掌握下面这些就足够应付 90% 的场景：
进入与退出
| 操作 | 按键 |
|---|---|
| 打开文件 | vim nginx.conf |
| 进入插入模式 | i（光标前）、a（光标后）、o（下一行新建） |
| 回到普通模式 | Esc |
| 保存退出 | :wq 或 ZZ |
| 不保存退出 | :q! |
移动与定位
h j k l：左下上右（先用方向键也行，别纠结）。gg 到文件头，G 到文件尾，42G 跳到第 42 行——看报错里的行号时直接用。/关键词 回车搜索，n 下一个，N 上一个。找 server_name、listen 这类配置项极快。0 行首，$ 行尾。编辑
dd 删整行，yy 复制整行，p 粘贴。x 删光标处字符，u 撤销，Ctrl+r 重做。cw：删一个词并进入插入模式（change word），改参数值最常用。5dd 删 5 行，3yy 复制 3 行。典型改配置流程：:set nu 显示行号 → 42G 跳到出错行 → cw 改掉参数 → Esc → :wq。
注释/取消注释一段配置。 Ctrl+v 进入块可视模式，j 选中若干行，I（大写 i）输入 # 后按 Esc，选区每行行首都插入 #。删除注释则选中后按 x。
全文替换。 :%s/旧值/新值/g 回车，加 c 变确认模式（:%s/8080/80/gc），逐个确认避免误伤。
不退出 Vim 执行 shell 命令。 :!nginx -t 测试配置，看完输出回车回到编辑——改完 Nginx 配置立即验证，不用退出编辑器。
服务器上不需要花哨插件，以下配置写入 ~/.vimrc 即可：
set number " 显示行号
set relativenumber " 相对行号，配合 5j 这类跳转
syntax on " 语法高亮
set tabstop=4 " Tab 显示宽度
set shiftwidth=4 " 缩进宽度
set expandtab " Tab 转空格
set ignorecase " 搜索忽略大小写
set smartcase " 含大写时恢复精确匹配
set incsearch " 边输入边高亮
set hlsearch " 高亮搜索结果（:noh 取消）
set cursorline " 高亮当前行
保留原有缩进风格的注意事项：改 Python 或 YAML 时 expandtab 很重要，混用 Tab 和空格是常见的语法错误来源。
i、Esc、:wq、dd、/关键词 活下来，用得多了自然扩展。vimtutor，官方交互教程，约半小时走完一遍。:syntax off。学会 Vim 的意义不在于炫技，而在于任何一台干净的服务器上，你都有一个可靠的编辑能力兜底。
grep、sed、awk 是处理这类文本的三件基础工具。本文不复述参数手册，而是用一条「排查 Nginx 访问日志」的主线把它们串起来。
示例日志格式（combined）：
203.0.113.10 - - [02/Sep/2026:10:15:01 +0800] "GET /api/users HTTP/1.1" 200 1234 "-" "curl/8.0"
排查的第一步永远是过滤。grep 模式 文件 把匹配行打印出来：
grep ' 500 ' /var/log/nginx/access.log # 找状态码 500 的行
grep -c ' 500 ' /var/log/nginx/access.log # 只统计行数
grep -v ' 200 ' access.log # 反向：排除正常请求
grep -i 'timeout' app.log # 忽略大小写
grep -r 'database' /etc/nginx/ # 递归搜目录
三个高频技巧：
grep -A 5 -B 2 'ERROR' app.log：同时显示匹配行后 5 行、前 2 行，看异常堆栈时必备。grep -E '401|403' access.log：-E 启用扩展正则，多模式「或」匹配。error 匹配到 terror），加 -w。:::tip
日志很大时不要先 cat 再管道，grep 直接接文件名即可，少一次无谓的读取。
:::
awk 默认按空白切分列，$1 是第一列。统计访问日志里各状态码的数量：
awk '{print $9}' access.log | sort | uniq -c | sort -rn
拆解这条管道：$9 取出状态码列 → sort 排序 → uniq -c 去重计数 → 按数量倒序。
awk 真正的威力在条件与计算：
# 只看 500 错误，打印时间和路径
awk '$9 == 500 {print $4, $7}' access.log
# 统计响应体总字节数（$10 求和）
awk '{sum += $10} END {print sum/1024/1024 " MB"}' access.log
# 找出响应最大的 5 个请求
awk '{print $10, $7}' access.log | sort -rn | head -5
行筛选条件写在 {} 前面，多列处理写在里面，「先条件后动作」是 awk 的基本句式。
sed 按行处理，最常用于替换和删行：
sed 's/404/找不到页面/' app.log # 每行只替换第一个匹配
sed 's/404/找不到页面/g' app.log # 加 g 全部替换
sed -n '100,200p' big.log # 只打印第 100~200 行
sed '/DEBUG/d' app.log # 删除含 DEBUG 的行
默认只把结果打印到屏幕，不改文件。确认无误后再加 -i 就地修改，macOS 下 -i 需要跟一个备份后缀参数（如 sed -i '.bak'），与 GNU sed 行为不同。
改配置文件前先备份是铁律：
cp nginx.conf nginx.conf.bak
sed -i 's/listen 80;/listen 8080;/' nginx.conf
线上接口告警，怀疑被恶意爬取。三步定位：
# 1. 近一小时的日志里，按 IP 统计请求数
grep '02/Sep/2026:10' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# 2. 看看第一名 IP 都在访问什么路径
grep '^203.0.113.10 ' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# 3. 确认它的 User-Agent
grep '^203.0.113.10 ' access.log | awk -F'"' '{print $6}' | sort -u
第 3 步用了 -F'"' 以双引号切分，因为 User-Agent 里含空格，按空格切会错位。日志分析里「选对分隔符」比记更多参数更重要。
. 在正则里匹配任意字符，想匹配字面句点要写 \.（比如匹配 IP）。* 表示「前一个字符重复零次或多次」，不是 shell 通配符里的「任意串」；任意串是 .*。+、?、| 需要 -E 或转义。grep -E '你的模式' sample.log | head。三剑客适合几十 MB 到几 GB 的单机文本。如果日志已经集中收集到 ELK/Loki，或者要做复杂的关联分析，就该用平台查询而不是在服务器上敲管道了——工具的价值在于「就地、快速、零依赖」。
rm 这个新手事故高发区。
Windows 以 C:、D: 划分磁盘，Linux 则把所有设备挂载到同一棵以 /（根目录）为起点的树上。常见顶层目录的职责：
| 目录 | 用途 | 日常是否需要碰 |
|---|---|---|
/home/alice |
用户 alice 的家目录 | 主要活动区 |
/etc |
系统与服务的配置文件 | 改配置时 |
/var/log |
日志 | 排查问题时 |
/tmp |
临时文件，重启可能清空 | 随手放，别存重要数据 |
/usr |
安装的程序与库 | 一般只读 |
/root |
超级用户的家目录 | 普通用户进不去 |
几个快捷符号：. 表示当前目录，.. 表示上一级，~ 表示当前用户家目录，- 在 cd 中表示「上一个所在目录」。
绝对路径从 / 写起，如 /var/log/nginx/access.log；相对路径从当前位置出发，如当前在 /var 时写 log/nginx/access.log。
判断用哪个的原则很简单：写脚本、写定时任务一律用绝对路径，避免工作目录变化导致找不到文件；交互式操作图省事可以用相对路径。
pwd # 我在哪
cd /var/log # 绝对路径跳转
cd .. # 回上一级
cd - # 回上一次所在目录
ls -lh # 列表 + 人类可读的文件大小
ls -la # 显示隐藏文件（以 . 开头）
ls 的两个高频选项值得记牢：-h 把字节数换算成 K/M/G，-t 按修改时间排序，找最新日志时特别好用：ls -lht /var/log | head。
mkdir -p projects/demo/assets # -p 一次创建多级，存在也不报错
touch projects/demo/notes.md # 创建空文件或刷新时间戳
cp -r projects/demo /tmp/demo-backup # 复制目录必须加 -r
mv notes.md todo.md # 重命名
mv todo.md /tmp/ # 移动
几个容易踩的细节：
cp 不加 -r 复制目录会直接报错 omitting directory。mv 同名目标已存在时会静默覆盖，加 -i 让它覆盖前先问你。mkdir -p 是脚本里的好习惯：目录已存在时不报错退出。rm 删除不走回收站，命令回车即生效，且 Linux 没有统一的「撤销删除」。三道保险：
第一道：确认目标再回车。 删除前先 ls 同一个路径，确认列出的是你想删的：
ls /tmp/demo-backup
rm -r /tmp/demo-backup
第二道：交互模式。 给重要操作加 -i，每删一个文件都要确认：
rm -ri old-logs/
可以在自己 shell 的配置里加别名 alias rm='rm -i'，但注意脚本里不要依赖别名。
第三道：通配符先打印后执行。 rm *.log 之前先 echo *.log，看展开结果是否符合预期。尤其警惕变量为空导致的路径漂移——脚本里 rm -rf "$dir/" 在 $dir 为空时会变成 rm -rf /，这是真实发生过的生产事故。安全写法：
[ -n "$dir" ] && rm -rf -- "$dir/"
-- 告诉命令「后面没有选项了」，防止文件名以 - 开头被当成选项。
:::warning
rm -rf 会强制递归删除且不询问，执行前务必确认路径里没有变量展开错误，也不要用 sudo 运行来源不明的清理脚本。
:::
记不清参数时优先问系统而不是凭印象：
man ls # 完整手册，q 退出，/关键词 搜索
ls --help # 快速速查
type cd # 看这个命令是内建还是外部程序
命令行的肌肉记忆来自高频使用，但「先确认、再执行」的习惯从第一天就该养成。