我的服务器上现在只有三样东西：nginx、sshd，加一个每天跑一次的 cron。
这不是洁癖。是之前吃过几次亏之后，慢慢删成这样的。
每加一个组件，就多一个要照顾的东西
刚买服务器那阵子，我装过面板，装过数据库，装过 Docker，还装过一个带 Web 界面的监控。装的时候都很顺利，一小时能搞定，界面上绿油油一片，很有安全感。
问题在三个月后开始出现。面板要升级，升级失败过一次，管理端口直接打不开；数据库要备份，备份脚本自己也需要被备份；Docker 的镜像越积越多，磁盘某天早上满了，nginx 连日志都写不进去。
最难受的是那次磁盘满。人在外面，只能拿手机连上去，先停服务，再一层层找是哪个目录占的空间。排查了一个多小时，发现是一个早就忘了的日志文件。那一刻我意识到，我对这台机器的了解，已经跟不上它自己长出来的复杂度了。
每一次故障单独看都不难修，但它们加在一起，构成了一种持续的低强度焦虑：你不知道下一次会是哪个组件。
服务器上最稳定的组件，是那个你没有装的组件。
一笔很具体的账
我拿面板和手写 nginx 配置做过一次对比。
面板占掉大约两百兆内存和几十兆磁盘，一年升级十几次，每次都可能带来兼容问题。手写配置只是一百多行的文本，改错了有测试命令，改对了几年不用动。
证书续期是少数我认为值得引入外部组件的地方。用 certbot 加上系统的定时任务，装完就不用管，这种“加”是划算的。区别在于：它解决的是我完全无法手工处理的问题。
监控也是同样的逻辑。我没有在服务器上装任何监控服务，而是用了一个外部的小工具，每天定时请求首页，失败就发邮件。它在机器外面，所以机器挂掉的时候它还能报警。
什么时候该加
我的判断方法很土：写下这个组件三个月后最可能出的三个问题，如果其中有两个我答不上来，就先不加。
另一个信号是“能不能一个人看完”。如果半夜出故障，我需要翻五个文档才能定位，那这套架构对我就太重了。一个人维护的系统，规模应该控制在一个人的视野之内。
这套做法也有代价：我没有可视化后台，查日志要 ssh 进去敲命令；做备份要自己写脚本，没有一键恢复；想临时跑个服务，还得先想清楚怎么回收。这些麻烦我认了，因为它们发生在我主动操作的时候，而不是在某个不知情的清晨。
最小化不是目的。目的是让故障面小到你能理解它，而不是让配置看起来干净。