中小团队自建内部服务：旧硬件适合什么，不适合什么？

中小团队有时会用旧硬件或二手服务器承载内部工具。这个选择的价值不在于低价硬件一定更划算，而在于先评估服务的重要性、维护能力和故障成本，再决定自建还是使用云资源。

先判断服务的重要程度

用于开发测试、内部知识库或低频协作的服务，性能要求可能并不高；但一旦承担核心业务、外部访问或关键数据，电源、网络、磁盘和恢复时间都会成为实际成本。

硬件成本之外还有维护成本

旧硬件的购置成本可能较低，但仍需考虑硬盘状态、散热、功耗、备件、网络稳定性与谁负责处理故障。设备能运行不等于服务已经具备可持续运行条件。

自建环境至少要准备什么

• 明确数据备份频率、保存位置和恢复演练方式；
• 按最小权限配置访问，不将管理入口随意暴露；
• 记录部署、更新和故障处理步骤；
• 为停电、磁盘故障和网络中断预留应对方式。

什么场景更适合云或正式托管

当团队需要随时从外部访问、服务不可中断、缺少维护人员或需要明确的资源扩展能力时，云服务器或正式机房通常更容易获得相对清晰的运维边界。

一套旧硬件内部环境带来的启发

这篇文章最初记录的是一次用旧款 E3 平台搭建内部服务的实践：把开发协作、代码托管和少量内部工具放到团队可管理的环境中。具体硬件型号、内存和磁盘配置只是当时的选择，并不是今天部署任意服务的推荐清单。它真正值得保留的经验，是先按业务重要性确定恢复要求，再决定是否让旧设备承担该服务。

在内部测试或低频工具场景，团队可能更在意能否自主安装、观察和维护，而不是追求最高配置。但一旦数据成为日常工作的唯一来源，就必须重新评估旧硬件故障、停电和恢复所造成的影响。不能因为“现在跑得动”，就把未来的故障责任留给无人负责的设备。

购置前要算完整成本

比较旧设备与云资源时，除了购买或租用费用，还要计入电力、网络、备件、现场处理时间、数据备份空间和迁移成本。旧硬件的价格优势并非必然成立；团队无法及时处理故障时，便宜的设备也可能带来更高的中断代价。反过来，云资源也不自动解决备份和权限配置问题，责任仍需说清楚。

虚拟化、磁盘与备份不要混为一谈

在一台机器上隔离多个内部服务，能让部署和维护更有条理，但虚拟化本身不是备份。系统盘与数据盘分开便于维护，也不能代替异地或离机副本。较稳妥的做法是明确哪些数据必须备份、多久一次、由谁检查、恢复时先恢复哪项服务，并定期用副本做一次恢复验证。没有验证过可用性的“备份成功”提示，不等于真实故障时能够恢复。

决定自建之前先做三项演练

1. 模拟设备停机：谁会收到通知，内部同事如何继续工作，能接受中断多久？
2. 模拟磁盘损坏：最近一次可用备份在哪里，是否能在替代环境恢复？
3. 模拟维护人员离开：部署说明、账号和更新步骤能否交接给下一位负责人？

如果这些问题回答不了，就应先降低服务重要性或选择更可控的运行方式，而不是直接把生产关键数据迁入旧设备。