一个人的基础设施控制平面：台账驱动、审批门禁、回合制收口

Kosen Infra 是我给自己搭的基础设施控制平面：管多台服务器、Cloudflare、域名和一堆自建服务。它解决的不是"怎么部署"，而是"一个人怎么安全地管越来越多的东西，而不靠记性、不靠手一抖"。

这篇讲它的设计理念，不涉及具体的服务器地址和拓扑细节（那些只该待在私有仓库里）。核心就一句：把基础设施当成一个需要纪律的系统来治理，而不是一堆随手敲的运维命令。

一、问题：规模一上来，"手动运维"就成了风险源

一个人管一台服务器时，怎么方便怎么来。但服务器变成几台、加上 Cloudflare 路由、域名、隧道、一堆自建服务之后，"手动运维"本身就成了最大的风险源：改错一条 DNS、手滑重启错服务、忘了某个证书要过期、某台机器悄悄开着公网端口——这些都不是技术问题，是没有系统的问题。

传统答案是上一套运维平台。但对个人规模，那太重。我的答案是一套轻量但有纪律的控制平面：版本化的台账 + 显式的审批门禁 + 回合制的收口循环。

二、执行原则：顺序本身就是安全设计

整个系统的执行原则写在第一屏，而且顺序是刻意的：

先台账，后改动。
先安全收口，后自动化。
先 Tailscale / 访问控制，后开放入口。
先健康检查，后部署更新。
先手工确认源站，后改 DNS / 隧道 / 访问策略。

每一条都是"先……后……"——因为基础设施事故大多不是因为不会做，是因为顺序错了：先改了 DNS 才发现源站没准备好、先开了自动化才发现权限没收口。把正确顺序固化成原则，比事后补救可靠。

三、台账即事实：应然与实然分离

系统的地基是一套版本化台账（一堆 YAML）：节点、部署、路由、云资产期限、审批策略、监控目标、运维命令白名单……基础设施的"应然状态"全部落在台账里。

关键设计是应然与实然分离：台账写"应该是什么样"，只读审计脚本采集"实际是什么样"，两者 diff 出缺口。当前状态不在任何文档里手写维护——靠脚本刷新生成。这条避免了运维文档最经典的腐烂：手写的"当前状态"永远滞后于现实，而生成的状态永远和现实对齐。

四、审批门禁：真实写操作都要显式许可

这是整个系统最像"纪律"的部分：所有真实写操作——改服务器、改 DNS、改隧道、改访问策略、写密钥——都需要一个匹配的台账请求 + 一句显式的审批短语。

运维命令是白名单化的，高危命令（重启服务、部署、应用路由变更）默认是 blocked 状态，需要单项审批才能执行。还有一条反作弊约束：缺失的生产遥测必须如实记为"缺失"，不许用合成或猜测的证据替代——一个诚实的"我不知道"比一个编造的"看起来没问题"安全得多。

这套门禁的价值在于：它把"手滑"这个最常见的事故源，从"随时可能发生"变成"需要主动越过一道显式的闸"。

五、回合制 Ledger：治理靠循环，不靠冲动

系统的推进不是"想到哪改到哪"，而是一个显式的回合循环：每回合评估当前最大缺口 → 设一个可验证的目标 → 只做当前授权允许的改动 → 本地验证 → 更新 Ledger。

有两条约束我觉得特别值得记：

• 新回合只能在事实变化时开启——台账事实变了、有新的真实需求、或有真实外部证据，才开新回合。禁止为了"保持循环运转"而造工作。
• 本地 meta-work 不能替代被阻塞的真实工作——如果最大的缺口需要一个审批或外部输入，就记下等待项然后停下，不许用"写个校验脚本、生成个报告"来假装在推进。

这两条治的是自动化系统最容易犯的病：为了显得在动而空转。一个诚实的"卡住了，在等 X"比十个自娱自乐的 meta 任务有价值。

六、防护边界

安全收口是这套系统的底色：所有节点入口收敛到内网网格（Tailscale），公网入站端口关闭；密钥走加密落盘，不进代码、日志和台账；聊天机器人网关只回传状态摘要、不传任何原文凭证；改源站前必须手工确认。所有敏感的基础设施细节只待在私有仓库里——包括这篇文章刻意不写的那些。

七、为什么值得

有人会问：一个人搞这么重的纪律，不累吗？我的体会正相反——这套纪律是省力的。它把"我得记着那台机器的端口""我得小心别改错 DNS""那个证书快过期了吧"这些持续占用注意力的东西，全部卸载到系统里：台账记着状态，审批挡着手滑，Ledger 追着缺口，健康检查盯着服务。

一个人能管的基础设施上限，不取决于你多能干，取决于你有没有一个不依赖记性的系统。这个项目就是那个系统——它让"一个人管一摊基础设施"从"迟早出事"变成"有纪律地、可持续地推进"。