把服务跑起来，往往是整件事里最简单的一步。真正难的是，让这套东西在接下来的几年里持续运转下去。
我最初只是想对日常使用的软件和数据有更多控制权，于是把越来越多的服务搬上自己的服务器。几年下来，我发现当初一些看起来完全合理的决定，后来都变成了不必要的麻烦。这些教训改变了我今天做自托管的方式，也是我如果重新开始会避开的错误。
能跑，不等于需要跑
我犯的第一个错误，是把自托管当成一场挑战，看自己能把多少数字生活搬上服务器。只要发现某个在用服务的开源替代品，我就想试一试。没过多久，我的容器里塞满了各种几乎不用的东西，理由仅仅是“我能跑起来”。
这种做法写在纸上很唬人，实际却让我的整套环境变得异常复杂。每加一个服务，就多一个要学的界面、多一个要盯着的应用。有些工具解决的是我根本不存在的问题，另一些则纯粹是几周后就被我遗忘的实验。
后来我不再问“这个我能自托管吗”，而是改问“我真的需要自托管这个吗”。这个小小的转变，帮我搭出了一套真正在用、规模小得多的环境，而不是为了折腾而维护一堆项目。
把服务直接暴露在公网上
我还吃过另一个亏：让一个自托管服务能从任何地方访问，并不意味着它必须直接暴露在互联网上。一开始，只要需要远程访问，我就开放端口，很少去想还有哪些东西因此变得可达。
这样确实方便，但也带来了更多要操心的事。每一个暴露的服务都成了一个潜在入口，尤其是那些仪表盘和管理面板，它们本来就不是为公开访问设计的。
我最终改变了远程访问的方式。大多数服务被放在带 HTTPS 的反向代理后面，不需要公开的东西则走私有访问通道。我也不再因为“这样最快”就暴露管理界面。现在，联网访问是我刻意配置的结果，而不是默认打开的状态。
备份不是可选项
有一段时间，我把备份当成“以后再弄”的事。只要服务运行正常、文件都在服务器上，我就觉得一切尽在掌握。直到我不得不面对数据丢失或损坏，才意识到一个小问题能多快演变成大麻烦。
现在，备份成了任何存储重要数据的服务的搭建环节之一。我会备份那些难以或无法替代的文件、数据库和应用数据，也会在不同位置保留副本，而不是完全依赖运行服务的那台机器。
最关键的是，我把备份流程自动化了。我不想依赖自己记得每隔几天手动跑一次。自托管给了我对自己数据的控制权，但只有当我拥有可靠的方式把数据找回来时，这种控制才有意义。
一有更新就立刻升级
我曾经把每一个可用的更新都当成必须马上装的东西。只要打开 Docker 面板看到一列新的镜像版本，我就会一次性更新好几个服务。这看起来是保持最新的好办法，却常常制造出意料之外的问题。
一次更新可能改变应用的工作方式、移除某个选项，或者引入与其他组件的兼容性问题。当多个服务一起更新时，想搞清楚是哪个环节出的问题就难上加难。
现在，我放慢了节奏。对于每天都要用的服务，我会先看发布说明再决定是否更新，也避免一次做多个重大改动。我还会给新版本留出一点时间，尤其是那些有破坏性更新历史的应用。保持更新很重要，但我不再把“最新”和“必要”混为一谈。
文档是必需品
早些年，我对环境做的小改动从不记录，因为我确信自己会记得做过什么。这招一直管用，直到几个月后我需要排查问题。盯着一个 Compose 文件或配置，我完全想不起某个设置为什么在那里，也不知道删掉会发生什么。
现在，我会记录那些不明显的改动：自定义配置、端口、文件夹路径、环境变量，以及让某个服务跑起来所需的任何非常规步骤。我也会把 Compose 文件整理好，而不是让重要配置散落在不同文件夹里。
这在重建或修改服务时不止一次帮了我。我不必依赖记忆，也不用去翻旧论坛帖子来搞清楚自己当初做了什么。自托管本身已经够多排查工作了，我不想让自己遗忘的决定再变成一个问题。
“我会记得这个是怎么配的”——这只是一个幻觉。
简化之后，自托管才变好
运行自己的服务多年后，我意识到自托管不是要搭出最令人印象深刻的配置，而是创造一个能可靠运转、又不会不断占用我注意力的环境。我犯过的错误教会我，不要只盯着最初的搭建，还要考虑长期要投入的精力。现在，我少花心思在实验上，多花心思在搭建一个我能舒心相处的环境上。
热门跟贴