生产级自托管基础设施全景:三宿主 162 容器高可用架构
一名工程师如何借助确定性脚本、内核隔离与三端拓扑,实现 162 个生产容器单人高可用运维。
核心架构抉择与生产权衡
单人运维 162 个生产容器,核心在于极度清晰的物理边界与责任划分,而非堆砌运维工时。 三端架构各司其职:Unraid 承担大容量持久化阵列存储与 GPU 算力;群晖 DSM 依托成熟的 Btrfs 快照运行 7×24 内部生产服务与数据库;公网 VPS 充当 DMZ 边缘硬化入口。 放弃在轻量节点上维护脆弱的分布式控制面(如 Kubernetes/Nomad),全站 78 个服务全部收敛为具备独立卷绑定的 Docker Compose 声明单元。系统的长期免维护性由 11 个零 AI 介入的确定性定时巡检脚本守护,以极简的确定性设计压制意外复杂度。
L1: 异构算力、存储与混合组网
物理硬件、网络拓扑与存储划分底座,将大容量 I/O、核心生产服务与公网入口合理分散在三台物理节点上。
-
一个人跑生产基础设施:三台主机、162 个容器
一个人、三台主机、78 个 compose stack 里的 162 个容器——Traefik、SSO、监控、邮件、CI/CD 与备份,以及两次改变了我「怎么核对数字」的故障。
-
我差点把这颗 SSD 送修——真正坏的是 SATA 数据线
一颗 Seagate IronWolf 110 SSD 疯狂报 WRITE FPDMA 超时、mkfs 报 'superblock magic doesn't match'、然后读写静默——教科书般的坏盘。我只换了一根 SATA 线,它就干净格式化、零报错。动手判死刑前,先这样排查。
-
换了不同的硬盘,同样的损坏又来了——真凶是 TRIM,不是 SSD
两周前 btrfs RAID1 阵列在看似健康的 NVMe 盘上静默损坏数据,两周后同一个全零校验和出现在完全不同的硬盘上。真凶是 Seagate IronWolf 110 上的队列化 TRIM(NCQ)——FreeBSD 早就拉黑了这个固件缺陷,Linux 却一直没有。我是怎么抓到它、以及修复方法的全过程。
-
Unraid 停止阵列时卡死的真相:Swapfile 锁住挂载点 — 附修复方案
Unraid 停止阵列时一直卡在卸载磁盘:btrfs RAID1 上的 8GB swapfile 通过 loop 设备锁住 /mnt/cache。根因分析、/boot/config/stop 陷阱、两个 User Scripts 彻底修复。
-
当降低 CRF 毫无效果:视频转码中 -maxrate 封顶与 SSIM 质量门禁的死锁
为什么将 CRF 下调 5 档仅让 SSIM 微升 0.00003:深度拆解高吞吐视频转码管线中 -maxrate 码率天花板与客观质量门禁之间的数学死锁与两档放行解法。
-
SMART 显示健康,RAID 却在悄悄损坏数据
两块看起来完全健康的 NVMe 组成的 btrfs RAID1 阵列,静默地把 Windows 虚拟机喂成了全零字节。靠的是一个校验和取证——每次失败都落在 found 一侧的全零块 CRC32C——以及两周后终于坐实的根因:异步 TRIM,既不是硬盘,也不是转接卡。
-
为什么 ffmpeg -map 0 会搞崩混流:跨容器多音轨、字幕与字体的深水区
为什么无脑使用 -map 0 会导致 Matroska 混流器直接报错退出、字幕字体静默丢失以及 Apple 客户端音轨失效:跨格式多媒体管线中的容器兼容性实战拆解。
L2: 边缘网关、容器运行时与身份
公网流量入口路由、声明式 Compose 服务治理、Linux 内核级内存隔离防护,以及统管全域服务的 SSO 鉴权中枢。
-
Apple iCloud 邮箱发信 465 超时:仅支持 587 STARTTLS 的协议陷阱
为什么在自动化邮件客户端中将 Apple iCloud SMTP 设为 465 端口会导致连接超时(WSAETIMEDOUT / os error 10060)?剖析 Apple 邮件网关对 587 端口显式 STARTTLS 的硬性要求。
-
验证完全正确的 Forward-Auth 网关——其实并未上线
我的 authentik forward-auth 网关在宿主机上返回了干净的 302 跳转到登录页,公网 URL 却仍然直接服务应用。这个主机名有两条入口层,而我只改了其中一条。
-
Authentik 从 2025.8 升级到 2026.8:那些没人提醒你会坏掉的部分
一年份的 authentik 大版本升级踩坑记录:存储挂载变更、RBAC 会话清理、可信代理,以及 authorization_flow 与 authentication_flow 搞混导致 SSO 彻底瘫痪。
-
Docker 报告退出码 0,内核却早已执行 OOM-Kill
NAS 上的一个容器反复异常退出,Docker 却上报 exit 0 与 OOMKilled=false。真实的证据在 dmesg 里:六次 cgroup OOM-kill。
-
反代超时返回 HTML,前端报 SyntaxError:一次 499 事故复盘
后台卡片报「Unexpected token '<'」,所有线索都指向前端,真正的故障却是一个跑在 GET 请求线程里的全库审计:289 到 341 篇笔记逐一切章、算哈希、stat 音频,穿过三层反代,实测从空闲时的 13.6 秒恶化到满载时的 2507 秒。
L3: 全域可观测性、巡检闭环与自愈
穿透 Docker 假象的真实底层监控,结合无需人工值守、无 AI 幻觉的确定性定时自愈闭环。
-
没有 Coding Agent 的 Loop Engineering:撑起我这套基础设施的 11 个定时任务
Loop engineering 是 2026 年对「设计让 agent 自己反复跑的系统」的叫法。我把它用在自己的自托管基础设施上而不是代码库上:11 个 cron,其中 8 个完全没有 AI。
-
用一个 Prometheus 监控 unRaid、群晖 NAS 和 VPS:我做错的四件事
三台主机、一个 Prometheus、一个 Grafana:覆盖矩阵、把同一个 NAS 卷算成三次的「总容量」,以及那台完全不导出 CPU 频率的虚拟机。
-
Prometheus 明明有数据,Grafana 面板却全是 No data 的原因
所有 target 都是 up、数据就在 Prometheus 里、面板表达式也没错——41 个面板却全部 No data。原因是 Grafana 变量过滤了自己,而我的验证方式恰好掩盖了它。
L4: 安全基线、CI/CD 与异地容灾
安全防御体系:紧急漏洞就地补丁、双代码源自动化发布流水线与经过实测恢复验证的 3-2-1 灾备链条。
-
我的备份爬得比爬虫还慢,因为我在用别人的 API 配额
1 TB 的 restic 种子传输卡在零字节。日志里点名的那个 Google 项目不是我的:那是 rclone 的共享 OAuth 客户端,配额和全世界每个 rclone 用户共池。
-
PHP2Shell:我管的每台机器,PHP 运行时全都中了
CVE-2026-109618 与 CVE-2026-109619 是 PHP 语言本身的未授权远程代码执行,披露前就已被利用。这篇记录我在自己管理的系统上实测到的版本、先修哪里,以及真正把它关掉的那几条命令。
-
用 IPBan 替换 RDPGuard:没人写出来的三个坑
我把付费的 RDPGuard 7.8.7 换成了开源的 IPBan 4.1.0,踩到三个没有文档的坑——其中一个卸载程序会悄悄放走 12 个正在攻击的 IP。
需要具备全链路实战能力的系统与 DevOps 工程师?
我具备从 Linux 内核排障、网络穿透到应用代码的全链路端到端交付能力,欢迎查阅完整履历或预约洽谈。
查看招聘方评估与技术栈 →