长期运行的 Minecraft 服务器，真正花时间的是什么

第一次开服通常很顺利：下载服务端、装好 Java、改两行配置、双击启动，看到控制台里出现 Done，然后兴奋地喊朋友进来。

真正的成本从第二天开始。

开服不是终点

一个能运行的服务器和一个能长期运行的服务器，是两种完全不同的东西。

前者只需要一个端口和一份服务端 jar；后者需要回答很多不浪漫的问题：昨晚的备份在哪里？谁有 OP 权限？为什么 TPS 在晚上八点掉到 12？上一个管理员离开后，规则还有人维护吗？

这些问题没有一条会出现在「五分钟开服」的教程里，但它们决定了服务器能活多久。

备份：先保证能回去

在所有运维工作里，备份的优先级最高。不是因为它最难，而是因为其他所有操作都假设你还能回去。

我的做法很简单：每天凌晨做一次完整备份，保留最近 14 天；每次大版本更新前手动再打一个带标签的包。

#!/usr/bin/env bash
set -euo pipefail

WORLD="/srv/minecraft/world"
BACKUP_DIR="/srv/backups"
STAMP="$(date +%Y%m%d-%H%M)"

mkdir -p "$BACKUP_DIR"
tar --use-compress-program=zstd \
  -cf "$BACKUP_DIR/world-$STAMP.tar.zst" \
  -C "$(dirname "$WORLD")" "$(basename "$WORLD")"

find "$BACKUP_DIR" -name 'world-*.tar.zst' -mtime +14 -delete

关键不是脚本本身，而是恢复演练。一个从未被恢复过的备份，不能算备份。每隔一段时间，我会把最近的包解压到一个临时目录，用不同的端口启动一次，确认存档能正常加载。

权限：默认拒绝

权限系统的第一原则是默认拒绝。

新玩家进来只有最基本的 default 组权限；OP 权限不常驻，需要时临时授予，用完就收回；管理命令通过权限节点拆分，而不是把整个 minecraft.command.* 丢给管理员。

这样做会麻烦一点，但它把「误操作」和「恶意操作」的代价都压低了。服务器里最贵的不是插件授权，而是被人误删的存档和失去信任的玩家。

性能：先测量，再优化

TPS 掉下来的时候，最容易犯的错误是立刻加插件、换服务端、升级机器。

正确的顺序应该是：先看 spark 或其他 profiler 的报告，确认是实体过多、区块加载、红石高频，还是某个插件在主线程里做了阻塞操作。

我见过最常见的问题不是硬件不够，而是：

• 一个每 tick 都在遍历所有玩家的插件；
• 一个把数据库查询放在主线程的统计插件；
• 一个没有限制的漏斗或村民繁殖场。

先定位，再优化。大多数时候，改一段代码比换一台机器便宜得多。

社区：规则要短，执行要稳

规则写成长篇文档，通常没有人读。我的规则只有三条：

1. 不破坏别人的东西；
2. 不利用漏洞获取优势；
3. 有问题先沟通，不要直接报复。

规则短，执行必须稳定。管理员可以有个性，但不能有心情执法：今天因为心情好放过的事，明天不能因为心情差就封人。玩家对服务器的信任，来自这种可预测性。

自动化：把重复动作交给脚本

长期维护的另一半，是把重复动作变成脚本：

• 定时备份与清理；
• 崩溃后自动重启，并保留最后一次控制台输出；
• 玩家举报写入一个简单的队列，而不是散落在聊天记录里；
• 版本更新前自动跑一次配置校验。

这些脚本不需要多优雅，但它们能把你从「每天手动检查一遍」里解放出来，让你有时间去做真正有趣的部分：设计玩法、写插件、和玩家一起玩。

最后

开服是一个技术问题，长期运行是一个组织问题。

技术问题有标准答案，组织问题没有。你只能不断观察、调整，然后在某一天发现：服务器已经不只是几行配置和几个插件，而是一群人共同维护的一个小世界。

这大概也是它值得花时间的原因。