一个运维老手的自白：为什么我还在用 CentOS 搭文件服务器？
2026 年了。距离 CentOS 那个“断更”风波已经过去好几年。网上铺天盖地都是 Rocky Linux、AlmaLinux，甚至有人直接投奔 Ubuntu Server。但说实话，在我手里，那些跑了几年的 CentOS 7 文件服务器，依然稳得像块石头。不是因为情怀，而是因为成熟。
上个月接了个小项目，帮一个做设计外包的小团队搭一套内部文件共享仓库。对方团队七八个人，平时 A 货、B 稿传来传去，FTP 早就淘汰了，Samba 又不稳定，他们之前用某网盘同步，结果一个项目组同时编辑，版本全乱。我需要一个简单、稳定、权限分明的方案。
选型最终落在 CentOS 7.9 + Samba + WebDAV。为什么是 CentOS？因为对于纯粹的文件服务器，系统稳定性远比软件包版本新鲜度重要。CentOS 7.9 的长期支持周期虽然在 2024 年底结束，但针对其核心组件（如内核、Samba）的安全补丁，通过第三方仓库（比如 SCL 或 ELRepo）仍然可以维持到 2027 年。对于这种内部服务，完全够用。
搭建过程没什么花里胡哨的。yum install samba samba-client -y，然后配置 /etc/samba/smb.conf。关键点在于两点：一是用户账户映射（用 smbpasswd -a 添加系统用户），二是目录挂载点的 SELinux 上下文。很多新手一上来就 setenforce 0，我强烈不建议。正确做法是 semanage fcontext -a -t samba_share_t "/data/share(/.*)?"，然后 restorecon。这样既保证安全，又不出怪毛病。
到现在运行了快一个月，除了有一次因为硬盘空间满了导致写入失败（日常监控的锅），零故障。
MongoDB 云服务器的“省钱”与“花钱”之道
同样是在这个项目里，客户之前的单据、项目数据全存在本地 SQLite 里。随着服务端需要支持 Web 端和小程序，迁移到 MongoDB 成了必然。但问题是：买云服务器自己装 MongoDB，还是直接用托管的 Atlas？
我倾向于前者——尤其是对于预算敏感的中小团队。这不是技术洁癖，是数学问题。2026 年，一台 2C4G 的云服务器（比如阿里云或腾讯云的轻量应用服务器）年费大约 600-800 元人民币。同样配置的 MongoDB Atlas 免费版虽然不花钱，但存储只有 512MB，而且受限于共享集群，IOPS 根本扛不住多一点并发。换成 M10 实例，一个月就要 50-70 美元，一年下来是自建的五六倍。
当然，自建 MongoDB 需要你了解副本集和索引策略。我在这台服务器上用 Docker 跑了一个单节点副本集（没错，单节点也建议启用副本集，为了以后扩展简单，而且可以开启 oplog）。关键参数是 --replSet rs0 和 --wiredTigerCacheSizeGB 1（限制缓存大小，防止吃光系统内存）。两小时搞定。
不过我也得承认，如果你团队里没有能半夜起来处理故障的运维人员，或者你们的数据真的非常关键（金融、医疗），那多花点钱用托管服务，买的是安心。我的原则是：开发阶段、MVP 阶段，自己搭；业务跑起来、有收入了，再迁到托管也来得及。
上海机房里的“清洁”服务器：不只是擦灰那么简单
上周末去了趟上海某郊区机房。客户有几台老的物理服务器要退役，我们负责把上面的数据迁移到新的云主机。但客户这次特别强调了一个词：“清洁服务器”。
一开始我还以为他们迷信，要做法事。后来技术总监解释说，他们做的是日本客户的精密仪器数据预处理，对硬件寿命和洁净度有特殊合规要求。他们把“清洁”定义为：服务器在运行期间，其进风口出风口的粉尘累计量不得超过某个标准，同时要求所有物理服务器在维护时，必须由持有电子洁净服认证的技术人员操作。
老实说，这在国内机房不常见。很多 IDC 所谓的“防尘”就是多几层过滤网，定期用压缩气体吹一吹。但客户要求更严格。他们要求在服务器上机前，必须对硬盘笼、风扇模块、PCIe 插槽进行无尘布+异丙醇擦拭，然后放在百级洁净工作台里通电老化 24 小时。
过程很繁琐，但确实有效。同批次其他机房同型号服务器，两年后风扇噪音明显增大，而这个上海机房的服务器，运行三年，拆开看内部几乎没什么灰尘。这件事让我意识到，“清洁”在特定行业（制药、精密制造、金融核心日志归档）里，不是一个伪需求，而是一种硬成本。
Java 官方服务器？别被名字骗了
客户问了我一个问题：他们想部署一个 Spring Boot 应用，是不是要去 Oracle 官网下载那个“Java 官方服务器”？我当场阻止了。
这里必须讲清楚：Oracle 官网提供的“Java SE Server JRE”在 2021 年就已经不再单独发布了。现在所谓的“Java 官方服务器”通常指的是 Oracle JDK，但它的商业许可证在 2023 年做了重大调整——如果在生产环境中使用，且你的公司收入超过某个线（我记得好像是人均 50 万美元还是什么），就需要购买订阅。很多小公司不知不觉就踩了雷。
对于绝大多数生产环境，正确的选择是 OpenJDK 发行版。比如 Eclipse Temurin（原 AdoptOpenJDK），或者 Amazon Corretto，或者 Microsoft 的 OpenJDK。它们都是官方认证的，免费，而且更新及时。我通常选 Corretto，因为测试下来它对容器环境（尤其是 CGroup v2）的支持最稳定，在 ARM 架构的云服务器上也没有二义性问题。
安装其实都一样：wget 下载 tar.gz，解压到 /usr/local/java，然后配置 alternatives。别忘了设置 ulimit -n 65536 和 vm.max_map_count，不然高并发的时候会出莫名其妙的问题。
百度云服务器 BCC 安装：从入门到“想骂人”再到“真香”
最后聊聊百度云服务器 BCC。其实我一开始对百度云是有偏见的，觉得生态不如阿里，文档不如腾讯。但上半年有个客户因为域名备案和合规原因，必须用百度云。硬着头皮用了一把。
安装过程并不复杂：控制台创建 BCC 实例，选择 Ubuntu 22.04（注意：百度云默认提供的 CentOS 镜像是 7.6，内核太老，很多新软件装不上，建议直接用 Ubuntu 或 Debian）。关键点在于网络配置。百度云的 VPC 默认是有外网 IP 的，但内网 DNS 解析有时候会抽风。如果发现 apt update 速度慢或者报错，可以手动改成腾讯云或阿里云的公共 DNS（因为他们自己的软件源在国内速度其实不差，但 DNS 有时候不靠谱）。
真正让我“想骂人”的是安全组规则。默认只开通 22 端口，而且 ICMP 协议默认禁止，这意味着你 ping 不通服务器。很多运维同学第一次进来发现 SSH 连不上（因为默认密钥登录，密码登录没开），然后怀疑是自己操作问题，其实是被安全组拦了。后来我特意写了个初始化脚本：基于 Ansible 批量放通 80、443、3306、27017 端口的来源 IP，同时开启 PID 监控和日志采集。
但用顺了之后，百度云 BCC 的弹性扩容确实方便。我们做了一次压力测试，从 2C4G 直接热升级到 8C16G，耗时不到 5 分钟，应用零中断（前提是应用使用了负载均衡）。对于突发流量场景，这个体验比有些云厂商需要停机的“变配”要好。
再说一句，百度云的“监控云助手”现在做得不错，可以一键排查 CPU 软中断、进程 D 状态、磁盘 IO 打满等常见问题。对于新手团队，省去了很多登录服务器排查的时间。
写在最后：没有银弹，但有方法论
回看这五个关键词，其实代表了一个完整的项目生命周期：从本地文件服务（CentOS）开始，到数据库上云（MongoDB），再到合规运营（清洁服务器），应用开发（Java 服务器），直到最终的云原生产品交付（百度云 BCC）。每一步的选择背后，都是对稳定性、成本、团队能力的综合拷问。
技术选型从来不是非此即彼。比如你可以在百度云 BCC 上跑一个 Java 官方（其实是 OpenJDK）的应用，同时把 MongoDB 放在同一台服务器上，甚至用 Samba 挂载一块云盘做文件存储——前提是你知道你在做什么，以及愿意为可能的故障买单。
我不相信有什么万能方案。我只相信我测试过的、跑过的、甚至出过故障然后修好的东西。这大概就是运维人最朴素的“信任模型”。