你大概率刷到过类似标题某机场因为建成后使用率过低长期处于近乎空置的状态每天仍然要亏掉约 110 万美元。先不讨论这个数字到底是新闻口径还是项目内部的现金测算真正值得技术团队关注的是它背后的那套模型一个重资产项目一旦被启动无论业务有没有跑起来固定成本都会按天发生。这个模型放在服务器、GPU 集群、云资源和内部平台上几乎每天都能看到。很多团队习惯了“资源先买好、服务先启动、容量先预备”然后因为业务没起来或者需求估错让一批节点长期空转。投入产出表上看起来是“项目还没有正式上线”实际上账单是按小时在走的。这篇文章不写具体的机场规划而是把“空置机场为什么不赚钱”拆开映射到基础设施成本治理上。读完你会得到一套可以落地的判断方法怎么识别空置资源、怎么统计闲置成本、怎么确定缩容和停机的边界以及哪些资源看起来空置但实际上不能动。1. 先说结构机场“空置一天亏 110 万美元”是怎么亏的机场这类基础设施有一个共同特点前期建设投入巨大建成后的成本结构非常刚性。跑道、航站楼、机坪、供电、排水、消防、通信、安保系统这些设施一旦建成并不会因为你今天只有一个航班就自动停掉一半。可以把它简化成下面这张成本结构表成本类型与航班量的关系典型例子空置时是否可避免折旧与财务成本不随航班量变化建设贷款利息、设备折旧基本不可避免基础设施维护只在维护频次上略有变化跑道巡检、航站楼保养、机电设备年检很难压缩到零基础能源消耗弱相关候机楼照明、空调、消防监控、弱电系统可降低但无法完全关闭最低人力配置弱相关安保、消防值班、设备运维、行政值守可压缩但有关键岗位随业务量变化的成本强相关地勤服务、值机柜台、行李分拣、商业补货业务不跑时可以少发生收入端强相关起降费、旅客服务费、停车、商业租金航班少时大幅下降所谓“空置一天亏 110 万美元”通常不是指这一天的现金支出了 110 万美元而是指把一个周期内的亏损总额折算到每一天。这里面既包含了折旧和财务成本也包含了维持设施可用状态而必须支付的维护、安保和人员成本。真正有意思的问题是既然亏损已经这么明显为什么不能直接把机场停掉答案也很直接停掉一个机场不是拔电源那么简单。机场基础设施需要保持适航状态空域申请、消防等级、设备校验、人员资质都需要延续。一旦进入长期停航重新恢复的成本可能比继续维持更高。所以在很多情况下决策者会选择“低成本维持”而不是彻底关停。这个决策模型和 IT 系统里的资源治理几乎一模一样。2. 技术团队里的“闲置机场”为峰值准备却长期低负载运行如果你负责过成本治理一定见过这几类现象第一类是服务器预配过度。项目立项时按“未来三年增长”估算 CPU 和内存结果业务上线半年平均负载还不到 10%。这些机器每天开着电费和折旧没有停下来。第二类是 GPU 资源闲置。为了跑模型训练或推理服务提前采购了高端显卡。业务试运行阶段使用的是小模型显存占用很低但资源已经被独占其他任务也插不进来。第三类是云上预留资源没有回收。数据库备库、测试环境、预发环境、临时用的 ECS业务部门说“可能还要用”于是长期保留。没人定期审计这些资源的使用率结果每个月账单都有几千上万的成本沉淀在里面。第四类是服务“假运行”。进程一直在端口也开着健康检查也过了但没有任何外部流量。这种状态比完全停掉更隐蔽因为它消耗了资源却不会在监控大盘上形成一个明显的错。这些现象的共同点在于资源已经按“峰值容量”准备完成但实际负载远远低于设计容量。资源还在账单上成本还在发生价值却没有产生。技术团队可以观察到的指标和机场非常类似资源对象观察指标判断空置的方法云服务器CPU、内存、网络流量连续 30 天平均利用率低于阈值GPU 服务器GPU 利用率、显存占用、功耗连续多天利用率趋近于 0数据库QPS、连接数、慢查询、磁盘 IO无业务调用但连接仍活跃K8s 节点Pod 数量、CPU/内存水位节点长期处于 Ready 但无明显调度对象存储读写次数、存储量变化只有少量写入几乎没有读取API 服务QPS、请求延迟、错误率运行正常但请求量为 0这些指标不需要一次全部覆盖。先从成本占比最高的资源入手逐步把“空置资源清单”捞出来效率最高。3. 识别空置资源的数据采集思路这里给出一套通用的采集方法不依赖具体云厂商或监控系统。第一步先划分资源池。按项目、环境、业务模块给资源打标签。这一步很重要没有标签的资源很难做成本归因。标签至少包含项目名、负责人、资源类型、计费类型、允许停机时段。第二步确定采集频率。主机资源建议 1 分钟或 5 分钟采一次GPU 资源建议 1 分钟采一次数据库可以按连接数和 QPS 抽样。采样周期拉长到 30 天因为只看一天的负载容易误判。第三步设置空置阈值。阈值不能随意定否则容易把正常业务误伤。一个常用做法是连续 30 天内该资源的平均利用率长期低于 10%且没有明显周期性峰值则标记为疑似空置。第四步结合业务单据做二次判断。如果监控系统显示资源利用率很低但要确认是否真的没有请求进入可以看网关日志或调用链记录。有些服务会把数据直接放在内存里处理CPU 不高但业务很关键这种资源不能简单判定为空置。第五步计算闲置成本。成本不是单纯看资源单价还要看这段时间里它占用多少容量、是否能被其他任务复用、是否需要额外电力和带宽。在 Linux 主机上可以通过几条通用命令查看基础数据# 查看 CPU 核数和平均负载持续观察时建议配合采集脚本 lscpu # 按 2 秒间隔连续采样 30 次观察 CPU 空闲比例 mpstat -P ALL 2 30 # 查看内存使用情况 free -h # 查看磁盘读写是否活跃 iostat -x 2 30如果是 GPU 服务器可以用 nvidia-smi 采集显存和利用率# 查看 GPU 当前利用率、显存占用、功耗 nvidia-smi # 按秒采集 GPU 利用率并追加到日志方便后面分析 nvidia-smi --query-gputimestamp,index,utilization.gpu,memory.used,power.draw \ --formatcsv -l 60 gpu_usage.log如果是 Kubernetes 环境可以用 kubectl top 查看节点和 Pod 的资源水位# 查看节点整体 CPU 和内存使用量 kubectl top nodes # 查看所有命名空间下的 Pod 资源使用量 kubectl top pods -A需要强调的是这些命令只是采集数据的第一步。真正判断一个资源是否空置要综合 30 天趋势和业务调用链而不是只看当前一秒钟的数字。4. 一个简单的“30 天空置成本”分析脚本先给出一份演示用的资源清单字段包括资源 ID、资源名称、类型、每日成本、近 30 天平均利用率、是否可缩减。这里的数值只是演示逻辑不是某个真实系统的数据。resource_id,resource_name,type,daily_cost,avg_utilization,reducible gpu-001,GPU推理节点A,gpu,520,0.03,1 db-001,线上数据库备库,database,180,0.08,1 web-001,旧版官网文档页,web,40,0.12,0 redis-001,历史活动缓存,redis,60,0.02,1下面这段 Python 脚本会读取这份清单筛出平均利用率低于阈值的资源并估算 30 天内的闲置成本。import pandas as pd def analyze_idle_cost(csv_path: str, idle_threshold: float 0.1) - pd.DataFrame: 读取资源清单筛选疑似空置资源并估算 30 天闲置成本。 闲置成本只是粗略估算用于排序不代表精确金额。 df pd.read_csv(csv_path) # 估算 30 天内的闲置成本 # 闲置比例 1 - 平均利用率 df[idle_ratio] (1 - df[avg_utilization]).clip(lower0) df[idle_cost_30d] df[daily_cost] * df[idle_ratio] * 30 # 筛出低于利用率阈值的资源 idle_df df[df[avg_utilization] idle_threshold].copy() return idle_df.sort_values(idle_cost_30d, ascendingFalse) if __name__ __main__: result analyze_idle_cost(assets_cost.csv, idle_threshold0.1) print(result[[resource_name, type, daily_cost, avg_utilization, idle_cost_30d]].to_string(indexFalse))运行结果会输出类似下面的表格resource_name type daily_cost avg_utilization idle_cost_30d 历史活动缓存 redis 60 0.02 1764.0 GPU推理节点A gpu 520 0.03 15132.0 线上数据库备库 database 180 0.08 4968.0如果只看单日成本GPU 节点 520 元一天并不算特别突出。但当它连续 30 天空转时折算出来的闲置成本就变成了一个需要被关注的数字。这个脚本的逻辑本身很简单。真正要发挥作用的是筛选条件怎么定什么资源可以被自动关闭什么资源只能缩容什么资源必须继续维持运行。这个判断不能只靠成本管理员完成需要结合业务负责人、运维负责人和财务数据一起核对。5. 容量决策预留、热备、缩容和停机的边界机场不能因为旅客少就把候机楼全拆了因为航季和突发事件随时可能带来流量高峰。技术系统也一样不能单纯以“平均利用率低”作为关停资源的唯一标准。在实际治理中资源通常会处于下面四种状态状态典型表现决策动作判断要点正常承载业务利用率稳定有真实请求维持现状持续监控观察长期趋势不要只看单点低频但必须保持可用利用率不高但业务要求随时响应保留最小节点关闭多余副本明确服务等级和响应时间可随时拉起的备机平时不承担流量只在故障时接管优先考虑按需启动而不是常驻验证自动拉起时间是否满足要求已无业务需求长期无请求无明确负责人先备份再缩容最后关停需要保留数据和审计记录很多团队容易犯一个错误把所有低利用率资源都看成“应该关掉的东西”。实际上有些资源承担的是突发流量兜底有些是容灾节点有些是需要保持心跳的调度中心。在关停之前必须回答几个问题这个资源是否在业务链路中承担了请求入口如果关停相关服务是否会自动降级恢复启动需要多长时间启动后是否需要重新加载大量数据是否存在外部系统定时回调如果这些问题的答案不清晰就应该先做“缩容”而不是“彻底停机”。所谓缩容是把资源规格降低或者把副本数减少保留最小可用容量的同时降低固定成本。例如 8 核 64G 的实例降到 2 核 8G5 个 GPU 推理实例保留 1 个数据库从一主两备降为一主一备。缩容通常比停机更安全。当缩容到极限后如果业务仍然没有恢复迹象再启动停机流程。停机流程要包含数据备份、配置快照、责任人确认、预期恢复时间、重启演练步骤。6. 排查“看起来空但不能关”的常见问题闲置资源治理最大的难点不是计算成本而是判断一个资源是否真的可以被释放。下面这张表整理了常见误判和排查思路。问题现象可能原因排查方式解决方案CPU 利用率很低但数据库连接数很高存在长连接池业务请求少但连接没有释放查看连接来源、慢查询、活动会话清理空闲连接确认是否有定时任务GPU 利用率接近 0但服务不能被停模型加载耗时长每次推理前要重新加载权重查看服务日志中的模型加载时间保留一个常驻推理实例关闭其他副本白天利用率低夜间偶尔有高峰存在按天或按周的批处理任务按 24 小时和 7 天维度观察把批处理任务集中调度避免全天预留资源资源没有流量但账单持续增加绑定了固定公网 IP 或独立存储卷检查网络和磁盘账单释放闲置 IP解绑不用的存储历史项目资源没人认领缺乏标签和负责人根据项目标签回溯负责人建立下线审批无人认领则进入待回收池运维担心“关掉后起不来”缺少启动手册和验证流程做一次完整重启演练编写自动恢复脚本并定期测试在治理过程中最危险的并不是资源浪费本身而是有人拍脑袋决定“这个没人用直接删掉”结果影响了下游接口。所以在执行任何关闭操作前先看调用链看 30 天访问日志看是否有外部定时任务访问再看系统告警是否会因为该资源下线而触发误报。更稳妥的方式是设置“观察期”先把资源从对外路由中摘除业务不直接使用但保留进程运行 3 到 7 天。如果观察期内没有任何异常再进入关停或释放阶段。7. 团队落地“闲置治理”时的检查清单如果你打算把空置资源的成本控制落到团队里不建议一开始就搞大而全的平台。下面是一套最小可执行的检查清单。先列资源清单。把项目名、环境、资源类型、规格、成本、负责人、预计最多闲置天数全部列出来。清单里没有的资源不纳入本次治理范围。再采集 30 天数据。资源运行至少 30 天后再讨论它是不是空置。刚上线两周的项目和一整年没有流量的项目处理方式完全不同。然后设置两级阈值。低风险阈值用于提醒例如平均利用率低于 10% 且持续 7 天。高风险阈值用于强制收敛例如平均利用率低于 3% 且持续 30 天且业务负责人确认没有任何计划流量。处理顺序建议先小后大测试环境最容易动先清理历史测试资源然后处理预发环境和灰度环境最后处理生产环境。生产环境的每一次变更都要有回滚预案。对于真正需要长期保留空转服务的场景至少要做到给进程加上资源限制避免空转时意外占用全部 CPU 或内存。设置自动休眠策略例如连续 24 小时无请求时自动降级到最小模式。记录每次启动原因和启动时间避免“自动拉起”后再次被遗忘。把启动命令和依赖关系写清楚避免运维变动后没有人能恢复。还要注意合规边界。如果资源中存有用户数据、模型权重、日志、密钥等敏感信息即使资源空闲也不应该在没有备份的情况下直接删除。关停前要执行数据归档归档完成后至少保留一段时间并记录审计日志。8. 关于成本意识把“空置成本”放到决策入口空置机场的损失很难追回是因为建设阶段已经投入了大量固定成本。技术系统里的浪费很多也发生在资源规划和预算申请阶段。一个新的项目上线前建议先回答几个成本问题按现有业务量最小可用资源是什么上线后第一周的流量预估是多少如果流量没有达到预期什么时候触发缩容如果业务果然失败释放资源的负责人和流程是谁不是每个人都愿意在项目启动前讨论失败场景。但成本控制恰恰需要这个“反向场景”来兜底。如果项目一直不产生收入那么每多跑一周损失就是一周的固定成本。提前设定触发条件是唯一能让成本在可控范围内的方法。在实际操作中可以给每个较高成本的资源打一个“止损标签”标签名称含义触发动作keep-on-hot必须长期热备保留最小副本不做主动缩容scale-down-after-7d业务 7 天未达标则缩容第 7 天自动缩容到最小规格release-after-30d30 天未达标则释放进入回收流程备份后删除nowait临时资源随时可释放不参与数据恢复止损标签的好处是让“是否终止一个项目”不再依赖个人意志而是变成一项指标驱动的流程。当业务没有按期到来时不再需要某个领导拍板才缩容系统会按既定规则自动收敛。这就是把机场亏损问题转换成可执行的工程制度。9. 别把“低利用率”当成“必须关停”文章最后想补充一个容易被误解的点。空置资源治理的目标不是追求资源利用率达到 100%而是避免资源无价值地消耗成本。任何系统都需要预留容量机场也一样。高峰期、恶劣天气、设备故障都会导致临时性容量需求。如果把所有备用容量全部砍掉表面上看成本下降了但业务稳定性可能大幅下降。所以在做治理时要把资源分成两类一类是“为了应对不确定流量而保留的容量”一类是“没有任何用途但账单继续滚动的沉淀成本”。前者需要保留但要明确保留周期和数量后者才是治理对象。判断两者的主要依据不是平均利用率而是需求模型这个资源是否在可预见的场景里被使用如果业务需要多久能调度到替代资源保留它所需的固定成本是否低于临时调度的费用如果低于保留是合理的如果远高于就应该考虑用“按需启动”替代“常驻预留”。回到机场的例子。一个日吞吐设计量很高但实际航班很少的机场核心问题往往不是“为什么它有空余容量”而是“建设规模和现实需求之间出现了错配且缺少一个止损机制”。技术系统里的浪费也一样第一次踩坑可以说需求预估不准但如果资源长期空置、账单持续走高、又没有人负责收敛那就不是预估问题而是流程问题。把止损动作前移到资源申请阶段给一份预算上限和一份释放条件再配合 30 天的利用率观察大多数闲置资源其实都能在早期被控制住。不要让空转的资源继续在账单上运行才是在“每天损失 110 万美元”这个标题背后真正值得技术人记住的一点。
从空置机场到闲置云资源：基础设施成本治理的止损策略
你大概率刷到过类似标题某机场因为建成后使用率过低长期处于近乎空置的状态每天仍然要亏掉约 110 万美元。先不讨论这个数字到底是新闻口径还是项目内部的现金测算真正值得技术团队关注的是它背后的那套模型一个重资产项目一旦被启动无论业务有没有跑起来固定成本都会按天发生。这个模型放在服务器、GPU 集群、云资源和内部平台上几乎每天都能看到。很多团队习惯了“资源先买好、服务先启动、容量先预备”然后因为业务没起来或者需求估错让一批节点长期空转。投入产出表上看起来是“项目还没有正式上线”实际上账单是按小时在走的。这篇文章不写具体的机场规划而是把“空置机场为什么不赚钱”拆开映射到基础设施成本治理上。读完你会得到一套可以落地的判断方法怎么识别空置资源、怎么统计闲置成本、怎么确定缩容和停机的边界以及哪些资源看起来空置但实际上不能动。1. 先说结构机场“空置一天亏 110 万美元”是怎么亏的机场这类基础设施有一个共同特点前期建设投入巨大建成后的成本结构非常刚性。跑道、航站楼、机坪、供电、排水、消防、通信、安保系统这些设施一旦建成并不会因为你今天只有一个航班就自动停掉一半。可以把它简化成下面这张成本结构表成本类型与航班量的关系典型例子空置时是否可避免折旧与财务成本不随航班量变化建设贷款利息、设备折旧基本不可避免基础设施维护只在维护频次上略有变化跑道巡检、航站楼保养、机电设备年检很难压缩到零基础能源消耗弱相关候机楼照明、空调、消防监控、弱电系统可降低但无法完全关闭最低人力配置弱相关安保、消防值班、设备运维、行政值守可压缩但有关键岗位随业务量变化的成本强相关地勤服务、值机柜台、行李分拣、商业补货业务不跑时可以少发生收入端强相关起降费、旅客服务费、停车、商业租金航班少时大幅下降所谓“空置一天亏 110 万美元”通常不是指这一天的现金支出了 110 万美元而是指把一个周期内的亏损总额折算到每一天。这里面既包含了折旧和财务成本也包含了维持设施可用状态而必须支付的维护、安保和人员成本。真正有意思的问题是既然亏损已经这么明显为什么不能直接把机场停掉答案也很直接停掉一个机场不是拔电源那么简单。机场基础设施需要保持适航状态空域申请、消防等级、设备校验、人员资质都需要延续。一旦进入长期停航重新恢复的成本可能比继续维持更高。所以在很多情况下决策者会选择“低成本维持”而不是彻底关停。这个决策模型和 IT 系统里的资源治理几乎一模一样。2. 技术团队里的“闲置机场”为峰值准备却长期低负载运行如果你负责过成本治理一定见过这几类现象第一类是服务器预配过度。项目立项时按“未来三年增长”估算 CPU 和内存结果业务上线半年平均负载还不到 10%。这些机器每天开着电费和折旧没有停下来。第二类是 GPU 资源闲置。为了跑模型训练或推理服务提前采购了高端显卡。业务试运行阶段使用的是小模型显存占用很低但资源已经被独占其他任务也插不进来。第三类是云上预留资源没有回收。数据库备库、测试环境、预发环境、临时用的 ECS业务部门说“可能还要用”于是长期保留。没人定期审计这些资源的使用率结果每个月账单都有几千上万的成本沉淀在里面。第四类是服务“假运行”。进程一直在端口也开着健康检查也过了但没有任何外部流量。这种状态比完全停掉更隐蔽因为它消耗了资源却不会在监控大盘上形成一个明显的错。这些现象的共同点在于资源已经按“峰值容量”准备完成但实际负载远远低于设计容量。资源还在账单上成本还在发生价值却没有产生。技术团队可以观察到的指标和机场非常类似资源对象观察指标判断空置的方法云服务器CPU、内存、网络流量连续 30 天平均利用率低于阈值GPU 服务器GPU 利用率、显存占用、功耗连续多天利用率趋近于 0数据库QPS、连接数、慢查询、磁盘 IO无业务调用但连接仍活跃K8s 节点Pod 数量、CPU/内存水位节点长期处于 Ready 但无明显调度对象存储读写次数、存储量变化只有少量写入几乎没有读取API 服务QPS、请求延迟、错误率运行正常但请求量为 0这些指标不需要一次全部覆盖。先从成本占比最高的资源入手逐步把“空置资源清单”捞出来效率最高。3. 识别空置资源的数据采集思路这里给出一套通用的采集方法不依赖具体云厂商或监控系统。第一步先划分资源池。按项目、环境、业务模块给资源打标签。这一步很重要没有标签的资源很难做成本归因。标签至少包含项目名、负责人、资源类型、计费类型、允许停机时段。第二步确定采集频率。主机资源建议 1 分钟或 5 分钟采一次GPU 资源建议 1 分钟采一次数据库可以按连接数和 QPS 抽样。采样周期拉长到 30 天因为只看一天的负载容易误判。第三步设置空置阈值。阈值不能随意定否则容易把正常业务误伤。一个常用做法是连续 30 天内该资源的平均利用率长期低于 10%且没有明显周期性峰值则标记为疑似空置。第四步结合业务单据做二次判断。如果监控系统显示资源利用率很低但要确认是否真的没有请求进入可以看网关日志或调用链记录。有些服务会把数据直接放在内存里处理CPU 不高但业务很关键这种资源不能简单判定为空置。第五步计算闲置成本。成本不是单纯看资源单价还要看这段时间里它占用多少容量、是否能被其他任务复用、是否需要额外电力和带宽。在 Linux 主机上可以通过几条通用命令查看基础数据# 查看 CPU 核数和平均负载持续观察时建议配合采集脚本 lscpu # 按 2 秒间隔连续采样 30 次观察 CPU 空闲比例 mpstat -P ALL 2 30 # 查看内存使用情况 free -h # 查看磁盘读写是否活跃 iostat -x 2 30如果是 GPU 服务器可以用 nvidia-smi 采集显存和利用率# 查看 GPU 当前利用率、显存占用、功耗 nvidia-smi # 按秒采集 GPU 利用率并追加到日志方便后面分析 nvidia-smi --query-gputimestamp,index,utilization.gpu,memory.used,power.draw \ --formatcsv -l 60 gpu_usage.log如果是 Kubernetes 环境可以用 kubectl top 查看节点和 Pod 的资源水位# 查看节点整体 CPU 和内存使用量 kubectl top nodes # 查看所有命名空间下的 Pod 资源使用量 kubectl top pods -A需要强调的是这些命令只是采集数据的第一步。真正判断一个资源是否空置要综合 30 天趋势和业务调用链而不是只看当前一秒钟的数字。4. 一个简单的“30 天空置成本”分析脚本先给出一份演示用的资源清单字段包括资源 ID、资源名称、类型、每日成本、近 30 天平均利用率、是否可缩减。这里的数值只是演示逻辑不是某个真实系统的数据。resource_id,resource_name,type,daily_cost,avg_utilization,reducible gpu-001,GPU推理节点A,gpu,520,0.03,1 db-001,线上数据库备库,database,180,0.08,1 web-001,旧版官网文档页,web,40,0.12,0 redis-001,历史活动缓存,redis,60,0.02,1下面这段 Python 脚本会读取这份清单筛出平均利用率低于阈值的资源并估算 30 天内的闲置成本。import pandas as pd def analyze_idle_cost(csv_path: str, idle_threshold: float 0.1) - pd.DataFrame: 读取资源清单筛选疑似空置资源并估算 30 天闲置成本。 闲置成本只是粗略估算用于排序不代表精确金额。 df pd.read_csv(csv_path) # 估算 30 天内的闲置成本 # 闲置比例 1 - 平均利用率 df[idle_ratio] (1 - df[avg_utilization]).clip(lower0) df[idle_cost_30d] df[daily_cost] * df[idle_ratio] * 30 # 筛出低于利用率阈值的资源 idle_df df[df[avg_utilization] idle_threshold].copy() return idle_df.sort_values(idle_cost_30d, ascendingFalse) if __name__ __main__: result analyze_idle_cost(assets_cost.csv, idle_threshold0.1) print(result[[resource_name, type, daily_cost, avg_utilization, idle_cost_30d]].to_string(indexFalse))运行结果会输出类似下面的表格resource_name type daily_cost avg_utilization idle_cost_30d 历史活动缓存 redis 60 0.02 1764.0 GPU推理节点A gpu 520 0.03 15132.0 线上数据库备库 database 180 0.08 4968.0如果只看单日成本GPU 节点 520 元一天并不算特别突出。但当它连续 30 天空转时折算出来的闲置成本就变成了一个需要被关注的数字。这个脚本的逻辑本身很简单。真正要发挥作用的是筛选条件怎么定什么资源可以被自动关闭什么资源只能缩容什么资源必须继续维持运行。这个判断不能只靠成本管理员完成需要结合业务负责人、运维负责人和财务数据一起核对。5. 容量决策预留、热备、缩容和停机的边界机场不能因为旅客少就把候机楼全拆了因为航季和突发事件随时可能带来流量高峰。技术系统也一样不能单纯以“平均利用率低”作为关停资源的唯一标准。在实际治理中资源通常会处于下面四种状态状态典型表现决策动作判断要点正常承载业务利用率稳定有真实请求维持现状持续监控观察长期趋势不要只看单点低频但必须保持可用利用率不高但业务要求随时响应保留最小节点关闭多余副本明确服务等级和响应时间可随时拉起的备机平时不承担流量只在故障时接管优先考虑按需启动而不是常驻验证自动拉起时间是否满足要求已无业务需求长期无请求无明确负责人先备份再缩容最后关停需要保留数据和审计记录很多团队容易犯一个错误把所有低利用率资源都看成“应该关掉的东西”。实际上有些资源承担的是突发流量兜底有些是容灾节点有些是需要保持心跳的调度中心。在关停之前必须回答几个问题这个资源是否在业务链路中承担了请求入口如果关停相关服务是否会自动降级恢复启动需要多长时间启动后是否需要重新加载大量数据是否存在外部系统定时回调如果这些问题的答案不清晰就应该先做“缩容”而不是“彻底停机”。所谓缩容是把资源规格降低或者把副本数减少保留最小可用容量的同时降低固定成本。例如 8 核 64G 的实例降到 2 核 8G5 个 GPU 推理实例保留 1 个数据库从一主两备降为一主一备。缩容通常比停机更安全。当缩容到极限后如果业务仍然没有恢复迹象再启动停机流程。停机流程要包含数据备份、配置快照、责任人确认、预期恢复时间、重启演练步骤。6. 排查“看起来空但不能关”的常见问题闲置资源治理最大的难点不是计算成本而是判断一个资源是否真的可以被释放。下面这张表整理了常见误判和排查思路。问题现象可能原因排查方式解决方案CPU 利用率很低但数据库连接数很高存在长连接池业务请求少但连接没有释放查看连接来源、慢查询、活动会话清理空闲连接确认是否有定时任务GPU 利用率接近 0但服务不能被停模型加载耗时长每次推理前要重新加载权重查看服务日志中的模型加载时间保留一个常驻推理实例关闭其他副本白天利用率低夜间偶尔有高峰存在按天或按周的批处理任务按 24 小时和 7 天维度观察把批处理任务集中调度避免全天预留资源资源没有流量但账单持续增加绑定了固定公网 IP 或独立存储卷检查网络和磁盘账单释放闲置 IP解绑不用的存储历史项目资源没人认领缺乏标签和负责人根据项目标签回溯负责人建立下线审批无人认领则进入待回收池运维担心“关掉后起不来”缺少启动手册和验证流程做一次完整重启演练编写自动恢复脚本并定期测试在治理过程中最危险的并不是资源浪费本身而是有人拍脑袋决定“这个没人用直接删掉”结果影响了下游接口。所以在执行任何关闭操作前先看调用链看 30 天访问日志看是否有外部定时任务访问再看系统告警是否会因为该资源下线而触发误报。更稳妥的方式是设置“观察期”先把资源从对外路由中摘除业务不直接使用但保留进程运行 3 到 7 天。如果观察期内没有任何异常再进入关停或释放阶段。7. 团队落地“闲置治理”时的检查清单如果你打算把空置资源的成本控制落到团队里不建议一开始就搞大而全的平台。下面是一套最小可执行的检查清单。先列资源清单。把项目名、环境、资源类型、规格、成本、负责人、预计最多闲置天数全部列出来。清单里没有的资源不纳入本次治理范围。再采集 30 天数据。资源运行至少 30 天后再讨论它是不是空置。刚上线两周的项目和一整年没有流量的项目处理方式完全不同。然后设置两级阈值。低风险阈值用于提醒例如平均利用率低于 10% 且持续 7 天。高风险阈值用于强制收敛例如平均利用率低于 3% 且持续 30 天且业务负责人确认没有任何计划流量。处理顺序建议先小后大测试环境最容易动先清理历史测试资源然后处理预发环境和灰度环境最后处理生产环境。生产环境的每一次变更都要有回滚预案。对于真正需要长期保留空转服务的场景至少要做到给进程加上资源限制避免空转时意外占用全部 CPU 或内存。设置自动休眠策略例如连续 24 小时无请求时自动降级到最小模式。记录每次启动原因和启动时间避免“自动拉起”后再次被遗忘。把启动命令和依赖关系写清楚避免运维变动后没有人能恢复。还要注意合规边界。如果资源中存有用户数据、模型权重、日志、密钥等敏感信息即使资源空闲也不应该在没有备份的情况下直接删除。关停前要执行数据归档归档完成后至少保留一段时间并记录审计日志。8. 关于成本意识把“空置成本”放到决策入口空置机场的损失很难追回是因为建设阶段已经投入了大量固定成本。技术系统里的浪费很多也发生在资源规划和预算申请阶段。一个新的项目上线前建议先回答几个成本问题按现有业务量最小可用资源是什么上线后第一周的流量预估是多少如果流量没有达到预期什么时候触发缩容如果业务果然失败释放资源的负责人和流程是谁不是每个人都愿意在项目启动前讨论失败场景。但成本控制恰恰需要这个“反向场景”来兜底。如果项目一直不产生收入那么每多跑一周损失就是一周的固定成本。提前设定触发条件是唯一能让成本在可控范围内的方法。在实际操作中可以给每个较高成本的资源打一个“止损标签”标签名称含义触发动作keep-on-hot必须长期热备保留最小副本不做主动缩容scale-down-after-7d业务 7 天未达标则缩容第 7 天自动缩容到最小规格release-after-30d30 天未达标则释放进入回收流程备份后删除nowait临时资源随时可释放不参与数据恢复止损标签的好处是让“是否终止一个项目”不再依赖个人意志而是变成一项指标驱动的流程。当业务没有按期到来时不再需要某个领导拍板才缩容系统会按既定规则自动收敛。这就是把机场亏损问题转换成可执行的工程制度。9. 别把“低利用率”当成“必须关停”文章最后想补充一个容易被误解的点。空置资源治理的目标不是追求资源利用率达到 100%而是避免资源无价值地消耗成本。任何系统都需要预留容量机场也一样。高峰期、恶劣天气、设备故障都会导致临时性容量需求。如果把所有备用容量全部砍掉表面上看成本下降了但业务稳定性可能大幅下降。所以在做治理时要把资源分成两类一类是“为了应对不确定流量而保留的容量”一类是“没有任何用途但账单继续滚动的沉淀成本”。前者需要保留但要明确保留周期和数量后者才是治理对象。判断两者的主要依据不是平均利用率而是需求模型这个资源是否在可预见的场景里被使用如果业务需要多久能调度到替代资源保留它所需的固定成本是否低于临时调度的费用如果低于保留是合理的如果远高于就应该考虑用“按需启动”替代“常驻预留”。回到机场的例子。一个日吞吐设计量很高但实际航班很少的机场核心问题往往不是“为什么它有空余容量”而是“建设规模和现实需求之间出现了错配且缺少一个止损机制”。技术系统里的浪费也一样第一次踩坑可以说需求预估不准但如果资源长期空置、账单持续走高、又没有人负责收敛那就不是预估问题而是流程问题。把止损动作前移到资源申请阶段给一份预算上限和一份释放条件再配合 30 天的利用率观察大多数闲置资源其实都能在早期被控制住。不要让空转的资源继续在账单上运行才是在“每天损失 110 万美元”这个标题背后真正值得技术人记住的一点。
