企业官网建设流程全解析

1. 项目缘起与整体设计思路

1.1 为什么要把 Hermes 塞进一台免费服务器

手里有台常年吃灰的云主机，是很多人共同的经历。Oracle Cloud 的永久免费额度里包含 ARM 架构的 Ampere A1 实例，配置给得相当大方，但大多数人开完机器、跑个测试脚本之后就再也没登录过。我这次做的事情，就是把这台闲置机器改造成一个 7×24 小时在线的 AI 助手节点，核心跑的是 Hermes 这套智能体框架。

先说清楚 Hermes 在这里扮演什么角色。它不是一个大语言模型本身，而是一个智能体编排层——你可以把它理解成一个“调度中枢”，负责接收消息、管理会话上下文、调用后端模型、执行工具函数、维护技能库。真正干推理活儿的可以是本地跑的模型，也可以是远程 API。这种分层设计的好处是：模型可以随时换，但助手的行为逻辑、技能配置、对话记忆都留在 Hermes 这一层，迁移成本极低。

那为什么偏偏选 Oracle Cloud Free？三个理由。第一，成本为零，永久免费额度不像某些厂商的试用期，到期就收费，它是真的一直免费。第二，ARM 实例的性价比，A1 实例最高可以给到 4 核 24GB 内存，这个配置跑一个轻量智能体框架加一个小参数量本地模型完全够用。第三，公网 IP 固定，机器重启后地址不变，省去了动态域名解析的麻烦。

适合谁来参考这套方案？我觉得有三类人。一是手里有闲置云资源、想物尽其用的开发者；二是想搭一个私人 AI 助手但不想每月掏订阅费的个人用户；三是对智能体框架感兴趣、想找个真实场景练手的技术爱好者。不需要你是运维专家，但基本的 Linux 命令行操作得会，SSH 登录、编辑配置文件、看日志这些是绕不开的。

1.2 整体架构怎么搭：分层解耦是核心原则

在动手之前，我先把整个架构想清楚了。很多人部署 AI 助手容易犯一个错误：把所有东西揉在一起，模型、框架、前端、数据库全塞在一个进程里，结果一出问题就抓瞎。我的做法是分层解耦，每一层职责单一，出问题能快速定位。

整个系统分成四层。最底层是基础设施层，就是 Oracle Cloud 的那台 ARM 实例，负责提供计算、存储和网络。往上是运行时层，包括容器运行时和进程管理工具，我用的是 Docker 加 systemd 的组合，Docker 负责隔离各个服务，systemd 负责开机自启和崩溃重启。再往上是服务层，Hermes 主进程、模型推理服务、向量数据库各跑各的容器，通过内部网络通信。最上面是接入层，负责对外暴露接口，可以是 HTTP API，也可以是消息平台的 webhook。

这么分层的好处，我在后面实操中体会特别深。有一次模型服务因为内存不足被系统杀掉了，但 Hermes 主进程毫发无损，只是调用模型时报错。我只需要重启模型容器就行，不用把整个助手推倒重来。如果当初全揉在一起，那就是整个服务挂掉，排查起来至少多花半小时。

提示：分层解耦不是让你过度设计。如果你只是跑一个纯 API 调用的助手，本地不跑模型，那服务层可以简化成 Hermes 加一个轻量数据库就够了。架构要匹配你的实际需求，别为了分层而分层。

1.3 选型背后的取舍：为什么是这套组合

工具选型这块我纠结了挺久，这里把思考过程摊开讲，方便你根据自己的情况调整。

容器运行时选 Docker 而不是 Podman。两者功能上差不多，但 Docker 的生态更成熟，文档多，遇到问题搜一下基本都有答案。Podman 虽然 rootless 更安全，但在 ARM 架构上偶尔会有兼容性小毛病，我不想在环境问题上浪费时间。

进程管理用 systemd 而不是 supervisor。systemd 是系统自带的，不用额外装东西，而且和 Docker 配合得很好——用systemctl enable docker就能保证容器运行时开机自启，再用 restart policy 控制容器本身的重启策略，两层保险。

模型后端留了可切换的接口。我一开始想直接跑本地模型，但实测下来 ARM 架构上跑 7B 以上的模型推理速度不太理想。所以最终方案是：默认走远程 API，本地模型作为备选。Hermes 的配置里把模型端点做成可配置项，想换随时改，不用动代码。

数据库选 SQLite 而不是 PostgreSQL。对于个人助手这种单用户、低并发的场景，SQLite 完全够用，而且零配置、单文件、备份就是复制一个文件，省心。等哪天真的多用户高并发了再迁移也不迟，Hermes 的存储层抽象做得不错，换数据库不用重写业务逻辑。

2. 环境准备与核心细节解析

2.1 Oracle Cloud 实例开通与基础配置

开通实例这一步看似简单，但有几个坑我踩过，提前说清楚能帮你省时间。

登录 Oracle Cloud 控制台后，创建实例时镜像一定要选对架构。ARM 实例（VM.Standard.A1.Flex）只能用 aarch64 架构的镜像，如果你手滑选了 x86 的 Ubuntu 镜像，创建会直接失败。我推荐选 Ubuntu 22.04 的 aarch64 版本，长期支持，软件源里的包也全。

配置规格时，免费额度允许你分配最多 4 个 OCPU 和 24GB 内存。我的建议是别一次性拉满。先给 2 核 12GB，跑起来看看资源占用，不够再加。因为 Oracle 的免费额度是账户级别的，你如果同时开多台机器，总额度是共享的。留点余量，以后想开第二台测试机也方便。

网络配置这块，安全列表（Security List）和网络安全组（NSG）要放行你需要的端口。默认只开了 22 端口给 SSH，如果你要通过 HTTP 访问助手，得手动加一条入站规则放行 80 或 443。我一开始忘了这茬，服务明明跑起来了，外网就是访问不了，排查了半天才发现是安全列表没放行。

SSH 登录后第一件事是更新系统并安装基础工具：

sudo apt update && sudo apt upgrade -y sudo apt install -y curl wget git vim htop net-tools

htop和net-tools是我必装的，前者看资源占用直观，后者排查网络问题方便。别小看这些基础工具，真出问题时能帮你快速定位。

注意：Oracle Cloud 的 ARM 实例默认没有 swap 分区。如果你打算跑本地模型，内存吃紧时容易触发 OOM Killer 把进程杀掉。建议手动创建一个 4GB 的 swap 文件作为缓冲，具体命令后面实操部分会讲。

2.2 Docker 与容器运行时的安装要点

在 ARM 架构上装 Docker，一定要用官方源而不是系统自带的版本。Ubuntu 仓库里的 Docker 版本往往偏旧，而且 ARM 支持不一定完整。官方源安装步骤如下：

# 安装依赖 sudo apt install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加软件源 echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装 Docker sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

装完之后把当前用户加入 docker 组，这样就不用每次敲命令都加 sudo：

sudo usermod -aG docker $USER newgrp docker

newgrp这步很多人会漏，导致当前会话里权限还没生效，得退出重登才行。加上这行就省事了。

验证安装是否成功，跑一个 ARM 架构的测试容器：

docker run --rm hello-world

如果能看到欢迎信息，说明 Docker 在 ARM 上工作正常。这里有个细节：拉取镜像时要注意架构匹配。有些镜像只有 x86 版本，在 ARM 上跑会报exec format error。遇到这种情况，要么找 ARM 版本的镜像，要么用--platform linux/amd64强制模拟运行（性能会打折，不推荐长期用）。

2.3 Hermes 框架的获取与依赖梳理

Hermes 的获取方式取决于你用的具体发行版本。我这边用的是社区维护的智能体框架，通过 Git 克隆到本地：

cd /opt sudo git clone https://github.com/your-org/hermes-agent.git sudo chown -R $USER:$USER /opt/hermes-agent cd /opt/hermes-agent

克隆下来之后先别急着跑，花十分钟读一遍 README 和 requirements 文件。这一步很多人跳过，结果后面报错一堆。重点看三样东西：Python 版本要求、系统级依赖、环境变量清单。

Python 版本这块，Hermes 一般要求 3.10 以上。Ubuntu 22.04 自带的 Python 是 3.10，刚好够用。但如果你需要更新的版本，建议用pyenv管理，别直接替换系统 Python，否则系统工具可能出问题。

系统级依赖通常包括编译工具和某些库的开发头文件：

sudo apt install -y python3-pip python3-venv build-essential libssl-dev libffi-dev python3-dev

创建虚拟环境是必须的，别把依赖装到系统 Python 里：

python3 -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt

在 ARM 上装依赖时，某些包可能需要从源码编译，耗时会比较长。如果卡在某个包上超过五分钟，大概率是在编译，耐心等等。实在等不及可以看看有没有预编译的 wheel 包，用pip install --only-binary :all: 包名试试。

提示：如果 requirements 里有torch这类大包，ARM 版本的 wheel 可能不在默认源里。需要去 PyTorch 官网找对应的 aarch64 安装命令，别直接 pip install，会下一堆源码编译到天荒地老。

3. 实操过程与核心环节实现

3.1 模型后端的接入与配置

Hermes 本身不带模型，得给它接一个推理后端。我分两种情况讲：走远程 API 和跑本地模型。

远程 API 方式最简单，适合快速跑通。在 Hermes 的配置文件里找到模型配置段，填入 API 地址和密钥：

model: provider: openai_compatible base_url: "https://api.example.com/v1" api_key: "your-api-key-here" model_name: "your-model-name" max_tokens: 2048 temperature: 0.7

这里provider填openai_compatible是因为大多数模型服务都兼容 OpenAI 的接口格式，Hermes 用统一的适配层去调，换服务商只需要改base_url和model_name。

本地模型方式稍微复杂点。我在 ARM 实例上试过用 Ollama 跑小模型，步骤如下：

# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取一个适合 ARM 的小模型 ollama pull qwen2.5:3b # 验证服务 curl http://localhost:11434/api/generate -d '{"model":"qwen2.5:3b","prompt":"你好"}'

然后在 Hermes 配置里把base_url改成http://localhost:11434/v1，model_name填qwen2.5:3b。

实测下来，3B 参数量的模型在 2 核 ARM 上推理速度大概每秒 5-8 个 token，日常对话够用，但复杂任务会有点慢。如果你分配到 4 核，速度能提升到 10-15 token/秒。模型选择上，参数量不是越大越好，得在效果和速度之间找平衡。我的经验是：3B 用于简单问答和意图识别，7B 用于需要一定推理能力的场景，再大就不建议在免费 ARM 实例上跑了。

注意：本地跑模型时，一定要限制并发数。Hermes 默认可能允许多个请求同时进来，ARM 实例的 CPU 核心少，并发一高就卡死。在配置里把max_concurrent设成 1 或 2，宁可排队也别把机器拖垮。

3.2 用 Docker Compose 编排多服务

手动一个个起容器太麻烦，我用 Docker Compose 把整个栈编排起来。在项目根目录建一个docker-compose.yml：

version: "3.8" services: hermes: build: . container_name: hermes-agent restart: unless-stopped ports: - "8080:8080" volumes: - ./data:/app/data - ./config:/app/config environment: - MODEL_BASE_URL=http://ollama:11434/v1 - MODEL_NAME=qwen2.5:3b - DB_PATH=/app/data/hermes.db depends_on: - ollama networks: - hermes-net ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: - ./ollama-data:/root/.ollama networks: - hermes-net networks: hermes-net: driver: bridge

几个关键点解释一下。restart: unless-stopped保证容器崩溃后自动重启，除非你手动停了它。volumes把数据和配置挂载到宿主机，这样容器重建时数据不丢。depends_on控制启动顺序，让 Ollama 先起来再起 Hermes。networks让两个容器在同一个内部网络里，Hermes 可以直接用服务名ollama访问，不用管 IP。

启动整个栈：

docker compose up -d

查看状态：

docker compose ps docker compose logs -f hermes

logs -f是实时跟踪日志，调试阶段特别有用。看到 Hermes 打印出 “listening on port 8080” 之类的信息，就说明起来了。

3.3 配置 systemd 实现开机自启与崩溃恢复

Docker Compose 本身不保证开机自启，得靠 systemd 兜底。创建一个服务单元文件：

sudo vim /etc/systemd/system/hermes.service

内容如下：

[Unit] Description=Hermes AI Agent Stack Requires=docker.service After=docker.service network-online.target Wants=network-online.target [Service] Type=oneshot RemainAfterExit=yes WorkingDirectory=/opt/hermes-agent ExecStart=/usr/bin/docker compose up -d ExecStop=/usr/bin/docker compose down TimeoutStartSec=300 [Install] WantedBy=multi-user.target

Type=oneshot配合RemainAfterExit=yes是标准做法，因为docker compose up -d执行完就退出了，但服务状态要保持“活跃”。TimeoutStartSec=300给足启动时间，ARM 上拉镜像和启动服务可能比较慢。

启用并启动：

sudo systemctl daemon-reload sudo systemctl enable hermes.service sudo systemctl start hermes.service

验证状态：

sudo systemctl status hermes.service

看到active (exited)就对了。这时候你重启机器，服务也会自动起来。

提示：systemd 的日志用journalctl -u hermes.service -f查看，比 docker logs 更全，能看到服务启动阶段的报错。排查开机自启失败的问题时，这个命令是首选。

3.4 反向代理与 HTTPS 接入

直接暴露 8080 端口不太优雅，也不安全。我用 Nginx 做反向代理，顺便配上 HTTPS。

安装 Nginx：

sudo apt install -y nginx

配置站点：

sudo vim /etc/nginx/sites-available/hermes

内容：

server { listen 80; server_name your-domain.com; location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; 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_read_timeout 300s; } }

proxy_read_timeout 300s这行很重要。AI 助手的响应时间可能比较长，默认 60 秒容易超时断开。设成 300 秒给足余量。

启用站点并重载：

sudo ln -s /etc/nginx/sites-available/hermes /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx

HTTPS 证书我用的是 Let's Encrypt 的 certbot，自动签发和续期：

sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d your-domain.com

certbot 会自动改 Nginx 配置，加上 443 监听和证书路径。续期也是自动的，systemd 里有个 timer 会定期跑。验证一下：

sudo certbot renew --dry-run

看到 “Congratulations” 就说明续期配置没问题。

4. 常见问题与排查技巧实录

4.1 服务起不来？按这个顺序排查

服务起不来是最常见的问题，我整理了一套排查顺序，照着走基本能定位。

第一步，看 systemd 状态：

sudo systemctl status hermes.service

如果显示failed，看下面的错误信息。常见的是WorkingDirectory路径不对，或者docker compose命令找不到。

第二步，看容器状态：

docker compose ps -a

-a会显示已退出的容器。如果某个容器状态是Exited (1)，说明它启动后崩溃了。

第三步，看容器日志：

docker compose logs --tail=100 服务名

--tail=100只看最后 100 行，避免日志太多刷屏。重点找Error、Exception、Traceback这些关键词。

第四步，进容器手动跑：

docker compose run --rm 服务名 /bin/bash

进去之后手动执行启动命令，看报什么错。这一步能排除掉环境变量、配置文件路径之类的问题。

我把常见错误和对应解法整理成表：

4.2 内存不够用怎么办：swap 与资源限制

ARM 免费实例的内存虽然给得多，但跑模型时还是容易吃紧。我遇到过 Ollama 加载模型时被 OOM Killer 杀掉的情况，日志里能看到Killed字样。

加 swap 是最直接的缓解办法：

sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

fallocate比dd快得多，推荐用这个。加到/etc/fstab里保证重启后自动挂载。

调整 swappiness让系统更愿意用 swap：

sudo sysctl vm.swappiness=60 echo 'vm.swappiness=60' | sudo tee -a /etc/sysctl.conf

默认值 60 其实就够用，如果你内存特别紧张可以调到 80，但太高会影响性能，因为 swap 在磁盘上，读写比内存慢几个数量级。

给容器加内存限制，防止单个服务吃光所有内存：

services: ollama: deploy: resources: limits: memory: 8G

这样 Ollama 最多用 8GB，超了会被限制而不是拖垮整台机器。

注意：swap 只是缓冲，不是解决方案。如果你发现系统频繁使用 swap，说明内存是真的不够了，该考虑升级实例规格或者换更小的模型。长期依赖 swap 跑服务，性能会差到没法用。

4.3 网络访问不通的排查思路

服务在本地跑得好好的，外网就是访问不了，这种问题我遇到过好几次，原因各不相同。

先确认服务本身在监听：

curl http://localhost:8080

如果本地能通，说明服务没问题，问题出在网络层。

检查防火墙：

sudo ufw status sudo iptables -L -n

Ubuntu 默认 ufw 是关闭的，但如果你开过，得放行对应端口：

sudo ufw allow 80/tcp sudo ufw allow 443/tcp

检查 Oracle Cloud 的安全列表。这是最容易漏的一步。登录控制台，找到实例对应的子网，在安全列表里加入站规则。源 CIDR 填0.0.0.0/0表示允许所有来源，端口填 80 和 443。

检查 Nginx 配置：

sudo nginx -t sudo tail -f /var/log/nginx/error.log

nginx -t检查语法，error.log 看具体报错。常见的是proxy_pass地址写错，或者 upstream 服务没起来。

用外部工具验证。我常用的是在另一台机器上curl -v或者用在线端口检测工具，确认端口从外部是否可达。如果外部不通但本地通，基本就是防火墙或安全列表的问题。

4.4 模型响应慢的优化经验

本地模型响应慢是 ARM 实例的固有短板，但通过一些调整能明显改善。

限制上下文长度。Hermes 默认可能保留很长的对话历史，每次请求都把全部历史发给模型，token 数一多推理就慢。在配置里设max_context_tokens: 2048，超出部分自动截断或摘要。

启用流式输出。让模型生成一个 token 就返回一个，用户感知上会快很多，虽然总时间没变。Hermes 配置里找stream: true打开。

模型量化。如果用的是 Ollama，它默认拉取的模型已经是量化过的（通常是 Q4）。如果你想进一步压缩，可以找 Q3 或 Q2 的版本，速度更快但效果会打折扣。我的建议是 Q4 起步，效果和速度平衡得比较好。

减少工具调用轮次。Hermes 的智能体模式可能会多次调用工具再生成最终回答，每一轮都是一次模型推理。如果发现响应特别慢，看看日志里是不是工具调用太频繁。可以在配置里限制最大工具调用轮次，比如max_tool_rounds: 3。

把不常用的技能禁用。Hermes 启动时会加载所有技能定义，技能多了会占用上下文。在配置里只启用你真正需要的技能，减少 prompt 长度。

4.5 数据备份与迁移的实操建议

跑了一段时间积累的对话数据、配置、技能库，这些都是有价值的，得做好备份。

SQLite 数据库备份最简单，直接复制文件：

cp /opt/hermes-agent/data/hermes.db /backup/hermes-$(date +%Y%m%d).db

但注意，复制前最好先停服务，或者用 SQLite 的在线备份命令，避免复制到写入一半的文件：

sqlite3 /opt/hermes-agent/data/hermes.db ".backup /backup/hermes-$(date +%Y%m%d).db"

配置文件备份，把config目录整个打包：

tar -czf /backup/hermes-config-$(date +%Y%m%d).tar.gz /opt/hermes-agent/config

设置定时任务自动备份：

crontab -e

加入：

0 3 * * * /opt/hermes-agent/scripts/backup.sh

每天凌晨 3 点跑一次备份脚本。脚本里记得加上清理旧备份的逻辑，别让磁盘被备份文件塞满。

迁移到新机器时，把备份文件拷过去，解压到对应目录，然后docker compose up -d就行。因为所有状态都在挂载的卷里，容器本身是无状态的，迁移很干净。

提示：Oracle Cloud 的免费实例如果长期不用可能会被回收。虽然官方说永久免费，但实际有闲置回收策略。我的做法是让助手每天定时给自己发一条消息，保持活跃。具体实现可以在 Hermes 里配一个定时任务，每天触发一次自检。

5. 技能扩展与日常维护心得

5.1 给助手加技能的正确姿势

Hermes 的技能系统是它比较有意思的地方。一个技能本质上就是一段可被调用的函数，加上描述和参数定义。模型根据用户输入决定调用哪个技能。

加技能有两种方式。一种是写代码，在skills目录下建 Python 文件，按框架的接口规范实现。这种方式灵活，能做的事情多，但需要写代码和测试。另一种是用配置文件声明，适合简单的 HTTP 调用类技能，填个 URL、方法、参数映射就行。

我建议新手从配置式技能开始，跑通了再尝试写代码。比如加一个“查天气”的技能，配置里写清楚 API 地址和参数怎么从用户输入里提取，Hermes 会自动处理调用和结果回传。

写代码技能时有个坑要注意：函数签名和文档字符串很重要。模型是根据文档字符串来判断什么时候调用这个技能的，描述写得含糊，模型就不知道该不该用。我的经验是描述里写清楚“什么时候用”和“什么时候不用”，比只写“这个技能做什么”效果好得多。

技能测试建议单独写测试用例，别每次都通过对话去试。Hermes 一般提供了技能调用的测试接口，直接传参数看返回结果，比走完整对话流程快得多。

5.2 日志监控与异常告警

7×24 小时跑的服务，不能靠人盯着。我配了一套简单的监控告警。

日志轮转用 logrotate，防止日志文件无限增长：

sudo vim /etc/logrotate.d/hermes

内容：

/opt/hermes-agent/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty create 0640 $USER $USER }

每天轮转一次，保留 7 天，自动压缩旧日志。

异常告警我用的是一个简单的脚本，定期检查服务状态，异常时发通知：

#!/bin/bash if ! curl -sf http://localhost:8080/health > /dev/null; then echo "Hermes 服务异常 $(date)" | mail -s "告警" your-email@example.com fi

加到 crontab 里每 5 分钟跑一次。curl -sf的-f参数让 HTTP 错误码也返回非零退出码，这样 4xx、5xx 都能被捕获。

资源监控用htop手动看就行，或者装个netdata做可视化。不过 netdata 本身也吃资源，在免费实例上要权衡。我的做法是只在排查问题时临时开，平时关掉。

5.3 长期运行的经验教训

跑了几个月，踩过的坑总结几条。

别频繁重启服务。每次重启 Hermes 都要重新加载模型和技能，ARM 上这个过程可能要一两分钟。如果不是必须，让它一直跑着。配置改了用热重载，别动不动就 restart。

定期清理对话历史。SQLite 数据库会越来越大，查询变慢。我写了个脚本每月清理一次超过 30 天的对话记录，保留最近的就行。清理前记得备份。

关注磁盘空间。免费实例的磁盘通常只有几十 GB，模型文件、日志、数据库加起来容易占满。设个阈值，超过 80% 就告警。清理时优先删旧日志和旧备份，模型文件如果不用了也及时删。

模型更新要谨慎。Ollama 拉新模型会占额外空间，而且新版本不一定比旧版本好。我一般先在测试环境验证，确认没问题再更新生产。更新前备份配置，万一新模型不兼容可以快速回滚。

网络波动是常态。免费实例的网络质量不能跟付费的比，偶尔会有延迟抖动。Hermes 调用远程 API 时如果超时，配置里设好重试次数和退避策略，别一次失败就报错给用户。

这套方案跑下来，一台闲置的 Oracle Cloud 免费实例确实能变成一个可用的 7×24 小时 AI 助手。成本是零，维护工作量也不大，每天花几分钟看看日志就行。如果你手里也有吃灰的云资源，不妨试试这个思路，把闲置算力利用起来。