服务器实际成本是多少？透明的 TCO 计算

先比较等价服务

一台 €3,600 的服务器不能直接与每月云费用比较。一份报价包含硬件，另一份可能包含计算时间和数据中心运营，两者都可能不含备份、支持和许可证。先制定服务规格：应用、可用容量、工作时段、允许的数据损失，以及最长可承受中断。

核心数量也不是统一性能单位。共享虚拟 CPU、专用核心和已有旧处理器，运行同一应用时可能表现不同。比较对象应能成功处理规定负载，并满足相同恢复目标。否则，更便宜的报价可能只是规模更小，或承担更少责任。

AWS Well-Architected Framework 将成本优化视为持续任务，关联使用情况、组织责任和资源选择。自有服务器也适用：预算需要负责人和定期审查，而非只在购买时批准。 AWS：成本优化支柱 ↗

示例是一台放在现有设备间的小服务器。假设硬件一次性 €3,600，设置和有记录的交接 €600。周期为五年，每年运行 8,760 小时。假设插座处测得的全年平均功率为 180 瓦，电价为每千瓦时 €0.30。

这里的公式是：一次性 €4,200 + 5 × 经常性 €3,053.04 = 五年 €19,465.20。分摊到 60 个月为每月 €324.42。这是比较值，既不是实际月付金额，也不是融资。由于购买支出，第一年成本为 €7,253.04，之后每年发生假设的运营成本。

模型中，硬件本身约占总额的 18.5%，假设的支持费用五年已达 €9,600。这不是普遍市场比例，而是公开输入值的结果。计算说明，如果配置不清每月增加工作，更便宜的设备也帮助不大。

750 瓦电源能提供该输出，但不代表服务器平均耗电。CPU 热设计指标也不是整机测量。计算关注插座取电和实际运行小时。包含典型备份的一周读数，比开机后短暂空闲测量更有意义。

模型中，180 瓦运行一年为 1,576.8 kWh。如果测试服务器确实只每周五天、每天十二小时运行，应使用实际时间，而非一律 8,760 小时。先检查关机是否兼容备份、更新及所需访问时间。声称晚上可关机却夜间导入数据的计算机，负载情况不同。

UPS 损耗、制冷和分摊的网络设备成本可能另计。示例未包含这些项目，比较时必须明确。如果已使用测得的站点总体附加值，就不要再次单列相同损耗。办公室服务器还受室温、噪声和散热限制，仅看电费无法体现。

这种敏感性分析，往往比最初精确到分的表格更有用。先问哪些输入不确定。如果没人知道支持每月需要两小时还是六小时，讨论十欧元电费意义不大。按活动记录实际工时：例行工作、事故、用户支持和后续开发。

运营期限值得单独比较。只用三年时，同样模型为 4,200 + 3 × 3,053.04 = €13,359.12。分摊到 36 个月约为每月 €371.09。更长使用期可分摊购置成本，但后期可能需要维修、延长支持和迁移。不要不检查运营影响就延长计算期限。

服务商可能负责硬件和数据中心，而团队仍负责客户操作系统、应用和配置。AWS 明确说明了 EC2 的这种分工。因此，租用计算机不自动等于托管应用运营，具体由约定范围决定。 AWS：责任共担模型 ↗

停机应纳入决策，但缺少可靠概率时，很难把它算成看似精确的年度数字。先描述一个场景：业务管理系统停四小时，影响五名员工。采用自行设定的每小时 €40 内部费率，会占用 €800 工作时间。丢失订单、返工和合同后果尚未包含。

这个场景并不自动意味着应购买昂贵高可用系统。团队也许可以用预备替代流程工作两小时，也许一小时就很关键。合适投入取决于实际受影响业务流程和经过测试的恢复，而非笼统停机成本公式。

至少比较基准场景，以及数据更多、电价更高或支持时间增加的不利版本。标明每项来自报价、测量还是假设。把投资和经常付款分开，让结果也符合现金流能力。

结果应包含明确范围、五项最大成本驱动因素，以及哪些条件下需要重新考虑。例如，增长超过可用 RAM 时可能触发第二次扩容；支持模式变化可能比新服务器报价更影响计算。这些触发条件让一次性价格表成为有用运营规划。