Self-hosted Infrastructure & Automation

背景

这套基础设施来自我和家人使用照片、媒体、代码托管及个人应用的需要。为了让数据尽量掌握在自己手里，服务逐步分布到家庭设备和远程服务器上，配套建立了部署、网络、监控和备份流程。

服务放在哪里，是建设过程中反复权衡的问题：远程主机有硬件冗余，距离却影响访问体验；家庭设备便于掌控，也带来供电、网络和恢复方面的责任。随着服务增加，选型的优先级逐渐明确：数据与基础设施自主权、服务可用性、访问速度、运维简单度和固定成本。

设计

早期我很看重磁盘冗余和 ECC 内存，后来开始结合每种工作负载评估这些条件的实际影响。迁移从可重复执行的 CI 编译入手，逐步扩展到个人应用，监控和备份则保留在远程主机上。

服务位置由存储行为、网络路径、故障影响和维护成本共同决定。考虑到主要用户是自己和家人，方案接受人工恢复，并配有独立备份和恢复步骤。监控部署在家庭应用主机之外，备份跨地区、跨服务商保存。

实施

配置由 Git 管理，应用通过 Gitea Actions 构建和部署。容器分布在不同主机上，通过私有网络连接。Prometheus 与 Grafana 汇集主机和服务指标，外部探测检查公网入口。

Restic 保存应用数据与配置的历史版本，Shell 和 Python 脚本处理证书分发、服务发现、定期检查和备份报告。配置、执行日志和验收记录为后续维护提供依据。

遇到的问题

• 硬件的吸引力会影响取舍。 我曾舍不得一台好不容易拿到的高配服务器，也反复考虑增加亚太源站。经过比较，决定先保留已有的合适资源，减少迁移工作；随后也认识到，这些服务器的性能超出了实际需求。
• 收集的数据未必进入排障流程。 因为不常查看监控数据，我一度考虑停用整套监控。重新梳理后发现，日常排障通常从告警开始，再登录目标主机检查，采集范围应当围绕这个过程调整。
• 迁移会改变数据和备份的含义。 停写前复制的数据需要再次同步，旧部署也可能重新启动。多次迁移后，以机器命名的备份仓库还会与实际内容发生偏移，给维护造成混淆。

解决方案

选型回到现有服务的负载、数据量和访问路径上，家庭应用、远程媒体、监控与备份的分工逐步明确。家庭主机后来改为直接运行 Debian，承载适合它的服务，减少当时没有必要保留的虚拟机划分。

监控调整包括移除 Loki 与 Promtail 的集中日志收集，保留 Prometheus 与 Grafana，并在当时将采集间隔调整为一分钟。排障继续沿 DNS、入口、私有网络和应用检查真实请求，采集内容服务于实际使用的告警和诊断流程。

迁移流程先停止写入，再同步最终数据。SQLite 迁移结合日志检查点、完整性检查、文件对照和公网入口验收，同时停用旧部署入口。备份逐步与主机名称解耦，用稳定的数据集标识及目的地矩阵检查缺失、失败或过期的结果。恢复检查则选取实际数据，核对文件、数据库和配置，并记录适用范围。

成果

平台逐步形成家庭应用主机、远程服务和独立备份的分工，并留下可追溯的迁移与恢复记录。后续服务迁移可以依据数据集和职责核对备份，公网入口验收也成为交付检查的一部分。

几轮迭代明确了各类服务的运行位置，精简了监控采集，并统一了备份数据集的标识。已完成的恢复检查覆盖选定文件、数据库和配置，检查结果与迁移记录一起用于后续维护。