一个人管服务器，最怕的不是技术难题，而是「不知道自己有什么」。这句话听起来抽象，举个具体例子：某天凌晨收到磁盘告警，登录上去发现是一台三年前买的 VPS 撑爆了，而那台机器上跑着两个早已没人访问的小站，其中一个还在持续被人扫描。要停掉它，得先知道它属于谁、域名解析在哪里、上面有没有数据库、备份放在哪。等你把这四件事查清楚，天已经亮了。

这种场景的解法不是更快的手，而是一张纸：一张资产台账。它记的不是配置细节，而是「这台机器是干什么用的、坏了会影响谁、要重装的话从哪开始」。这篇写这一张纸怎么建、记哪几列、怎么保证三个月后它还是准的。

一、为什么配置文档救不了你

很多站长有过一次「认真整理文档」的经历，结果是写了一份很漂亮的运维手册：Nginx 怎么装、PHP 怎么编译、MySQL 参数怎么调。半年后再看，所有内容都过期了，因为它记的是「怎么做」，而「怎么做」的答案在网上到处都是、每天都在变。

真正会过期得慢、真正救命的是「有什么」和「谁负责」。这两件事不会因为教程更新而失效，而且它们恰恰是查不到、只能靠记录的。分清这两类信息，是建台账的第一步：

• 过程知识（怎么装、怎么调）：不需要记，需要时搜。写下来必然过期。
• 状态事实（有哪些机器、域名指向哪、谁付费、到期日）：必须记，因为唯一来源就是你自己。

资产台账只装第二类。一旦这个边界划清，台账就不容易失控——它不会膨胀成又一本过期的手册。

二、先跑四条命令，把家底盘出来

建台账不要从「回忆」开始，要从「扫描」开始。人对自己拥有的东西的记忆，准确率远低于想象。四条命令能覆盖绝大部分遗漏：

# 1. 正在监听的端口与服务
ss -lntup

# 2. 开机自启的服务
systemctl list-unit-files --type=service --state=enabled

# 3. 所有定时任务（root 与业务用户都要看）
crontab -l; ls -l /etc/cron.d/ /etc/cron.daily/
systemctl list-timers --all

# 4. 所有被 nginx 托管的域名
grep -rhE '^\s*(server_name|root)\s' /usr/local/nginx/conf/vhost/ | sort -u

这四条跑完，你通常会发现至少一个「我以为早就下线了」的东西。我见过最典型的是一个 2019 年装的 phpMyAdmin 还开着公网访问，目录里连密码都没设——它不在任何人的记忆里，但一直在监听 8080。

把这些发现先倒进一张草表，不要急着分类，先求全。分类是下一步的事，一开始就追求结构会让这张表建不起来。

三、台账要记的七列，以及为什么是这七列

一张能用的资产台账，每行一个资产（一台服务器、一个域名、一个第三方服务），列数控制在七列左右。列太多没人填，列太少不够用。

七列里最容易被跳过、又最有价值的是「被依赖」和「处置动作」。前者回答「我能不能关掉它」，后者回答「现在就要关的话先做什么」。这两列是台账与清单的分水岭：清单告诉你有什么，台账告诉你动了它会怎样。

「归属」这一列值得单独说。很多人把域名和服务器分散在四五个注册商、七八个邮箱下，有的是公司账号、有的是个人邮箱、有的邮箱本身已经不用了。真正的事故不是服务器坏了，而是域名到期了却收不到提醒，因为提醒邮件发进了一个三年没登录的邮箱。把「账号邮箱」写进台账，是防止这类事情的最低成本手段。

四、四条命令自动更新，避免台账腐烂

台账的唯一死因是不准。手工维护的表格三个月后一定有错，所以必须有一部分是自动生成的。做法是把「能自动查的」与「只能人填的」分开：

#!/bin/bash
# asset_probe.sh —— 每天生成可自动采集的部分
OUT=/srv/ops/asset/auto_$(date +%Y%m%d).txt
{
  echo "## host $(hostname) $(date +%F)"
  echo "-- listening"
  ss -lntup | tail -n +2
  echo "-- enabled"
  systemctl list-unit-files --type=service --state=enabled | tail -n +2
  echo "-- disk"
  df -h --output=source,size,used,pcent,target | tail -n +2
  echo "-- cert"
  for d in $(grep -rhoE 'server_name\s+\S+' /usr/local/nginx/conf/vhost/*.conf \
             | awk '{print $2}' | grep -v '^_' | sort -u); do
    printf "%-30s " "$d"
    echo | timeout 10 openssl s_client -servername "$d" -connect "$d:443" 2>/dev/null \
      | openssl x509 -noout -enddate 2>/dev/null || echo "NO_CERT"
  done
} > "$OUT"

这份自动输出不直接当台账用，它是「对账依据」。每周花十分钟，把它和手工填的那张表对比一次，不一致的地方就是台账腐烂的位置：可能是一个被遗忘的服务、一个已经过期的证书、或者一台磁盘快满的机器。

对账这件事听起来像额外工作，但它比「凭印象更新台账」可靠一个数量级。人的记忆会骗人，ss -lntup 不会。

五、到期提醒：把日期变成一件会自己发生的事

台账里最容易被写进去、也最容易被忽略的是日期。写进表格不等于会有提醒，必须有机制。最简单的做法是从台账里抽出日期列，交给一个每天跑的脚本：

#!/bin/bash
# 从 CSV 里读到期日，30 天内到期就提醒
TODAY=$(date +%s)
while IFS=, read -r name owner expire rest; do
  [ -z "$expire" ] && continue
  [ "$name" = "标识" ] && continue
  E=$(date -d "$expire" +%s 2>/dev/null) || continue
  D=$(( (E - TODAY) / 86400 ))
  if [ "$D" -ge 0 ] && [ "$D" -le 30 ]; then
    echo "$name 还有 $D 天到期（$expire, $owner）"
  elif [ "$D" -lt 0 ]; then
    echo "已过期 $(( -D )) 天: $name ($expire)"
  fi
done < /srv/ops/asset/assets.csv

这个脚本的价值不在于技术含量，而在于它把「记得看台账」变成「不用记得」。任何依赖人主动去查的提醒，最终都会失效。

六、把「处置动作」写成人能执行的样子

台账里「处置动作」这一列，最常见的失败写法是关键步骤缺失。比如写「迁移到新服务器」，这句话在凌晨三点对一个睡眼惺忪的人毫无帮助。可执行的写法应该像这样：

• 第一步：把 DNS 的 TTL 提前一天改成 300，等一天生效。
• 第二步：rsync 同步 /home/wwwroot 与数据库到新机，校验文件数与最大的三张表行数。
• 第三步：新机改 Nginx 的 server_name 并 nginx -t。
• 第四步：改 DNS 指向新 IP。先不要关旧机，保留七天。
• 第五步：观察日志中旧机是否还有请求，为零后再下掉。

这五步每条都能直接执行，且每一步都有可验证的结果。判断标准很简单：如果一条处置动作里出现了「迁移」「切换」「部署」这类动词却没有具体命令，它就还不合格。

另外，「处置动作」不是给未来的自己看的锦上添花——它是给最坏情况准备的。人在事故中会变笨，会做出「先把机器重启一下试试」这种判断。这时候一张写着具体步骤的纸，比任何专业知识都管用。

七、台账越简单越活得久

在动手之前，先接受一个事实：绝大多数自制台账都死于「设计得太好」。总想加消费统计、加监控面板、加自动发现、加审批流，做完一期就再也没人碰过。所以第一版一定要克制到极致：

一个 CSV 文件，七列，存在 Git 仓库里。不用数据库，不用后台界面，不用权限系统。CSV 的好处是任何人都能打开、能 diff、能 grep；Git 的好处是每次修改都有记录，谁在什么时候改了哪一行一清二楚，而且天然有异地备份（推一份到远端）。

等这张表连续三个月都没腐烂、你也真的每周会对账一次之后，再考虑要不要上工具。多数时候答案是「不需要」——一张 30 行的 CSV 已经能覆盖一个人运维的全部场景，剩下的复杂度都是自找的。

八、第一个月该做什么

不要试图一次建全。按这个顺序推进，每周只做一件：

第一周，跑完第二节的四条命令，把发现的资产全部倒进 CSV，只填「标识」和「归属」两列。目标是不遗漏。

第二周，补「到期日」，同时把域名注册商、证书、VPS、CDN 这四类日期全部找出来，一个不落。这一周通常会发现一两个已经过期或者即将过期的东西。

第三周，补「依赖」与「被依赖」。这一列不用求大求全，先把「多个站共用的那台数据库」和「所有站都依赖的那个 CDN」标出来。共性依赖就是单点。

第四周，补「备份位置」与「处置动作」，只填最核心的三到五个资产，其它的留空。然后跑一次恢复演练——真的从备份里恢复一个文件，看看能不能成。

一个月后你手里会有一张不完美但真实的表。它比一份完美的、写在别处的方案有价值得多，因为它是准的。

九、小结

资产台账不是文档工程，是一件很质朴的事：把「我有什么」写下来，把「动了会怎样」想清楚，把「到期」交给脚本去提醒，然后每周花十分钟和机器对一次账。它的收益不会立刻显现，但会在某一个凌晨变成一条具体的命令，让你在五分钟内判断出「关掉这台机器不会影响任何人」。

对一个人维护的站点来说，比技术深度更稀缺的是这种「不需要想就能查到」的确定性。台账就是把这个确定性固定下来的那件东西。