闲置云资源识别与自动降配：别为不用的机器买单
去年一个客户，月底看账单发现测试环境费用异常高。一查，有台机器CPU平均使用率不到3%，网络流量几乎为零，但规格是8核32GB，每月费用不低。谁开的？忘了。干什么用的？不知道。能不能关？不敢。
这是云上成本浪费最常见的场景：机器开着，没人用，但每个月账单照付。
今天聊聊闲置云资源识别与自动降配。不是那种“要记得关”的废话，而是帮你理清楚：怎么找出那些“在睡觉”的机器？怎么判断能不能降配或关掉？怎么自动化？
01 闲置资源比你想的多
很多人以为只有测试环境有闲置资源。其实生产环境也不少，尤其是非核心服务、备份节点、冷备实例。
常见的闲置资源类型：
低利用率机器：CPU平均<5%，内存使用率<10%，网络流量近零
僵尸资源：创建后再也没人用过，TAG缺失，owner未知
非工作时间闲置：只在工作时间有流量，晚上和周末完全空闲
过度配置：业务只需要2核4GB，但开了8核32GB
那家客户的那台机器，是半年前一个实习生开的，跑完实验忘了关。没人知道，没人敢关，开了半年。
02 怎么判定一台机器是闲置的？
不能光看CPU。要综合多个指标。
判定标准参考：
CPU平均利用率：过去7天<5%
内存平均利用率：过去7天<10%（或稳定在基线值）
网络流量：入+出<1Mbps（或接近0）
连接数：活跃连接数接近0
时间段：非工作时间（如凌晨2-6点）利用率极低
如果一台机器连续7天满足以上条件，基本可以判定为闲置。
那家客户用云监控拉取过去30天的CPU和网络数据，发现几十台机器CPU长期低于5%。其中一半是测试环境，一半是生产环境的非核心服务。
03 闲置不等于可以关
机器闲置，但关之前要确认几个问题。
这个机器是做什么的？ 不知道用途，先别关。找owner，查TAG，看最近有没有人用。可以先发通知：“这台机器7天后将关机，如有异议请回复。”
关掉会影响谁？ 可能某个定时任务还在跑，虽然CPU低，但每周跑一次。关了就出问题。
能不能先降配，而不是关？ 8核降到2核，32GB降到8GB，先降配观察，不够再升回去。
关掉后能不能快速恢复？ 有关机前的快照吗？能从备份恢复吗？
那家客户对那台机器先降配到2核4GB，观察一周，业务没影响。再过两周，直接关机。一个月后没人投诉，删除。
04 自动降配：三步走
人工盯不现实。要自动化。
第一步：检测
定时扫描所有实例，拉取CPU、内存、网络指标。低于阈值，标记为“候选闲置”。频率每天一次。
第二步：预警
标记为闲置后，发通知给owner或负责团队：“机器XXX已闲置7天，3天后将自动降配/关机。”通知渠道：钉钉、Slack、邮件。给缓冲期。
第三步：执行
低风险：直接降配（如8核降到2核）
中风险：先关机，观察一周，无人重启则删除
高风险：不自动操作，发工单人工确认
那家客户用AWS Systems Manager Automation + Lambda实现了自动降配。每天凌晨扫描，CPU<5%且网络流量<1Mbps连续7天，自动发通知，3天后自动降配到最低规格。降配后再观察7天，无异常则关机。
05 哪些机器不能动
有些机器不能自动降配，要加白名单。
生产环境核心服务（数据库、网关、消息队列）
有明确SLA要求（响应时间敏感）
业务高峰时间窗口（大促期间不自动降配）
特殊规格实例（GPU、高内存实例）
可以设置标签auto-downsize: false，跳过自动降配。
那家客户给核心K8s节点、RDS实例加了白名单，不自动降配。其他非核心服务，全自动。
06 一个真实案例：月成本降25%
一个客户，几百台实例，月账单高。我们做了闲置资源扫描。
发现：
20%实例CPU<5%，其中一半是生产环境的非核心服务
10%实例规格明显过剩（8核跑单机应用）
5%实例已无人使用（创建时间>1年，最近30天无流量）
操作：
对无人使用的实例，直接关停
对CPU低的实例，降配到2核4GB
对非核心生产服务，配置自动降配策略，非工作时间降配
次月账单降了25%。运维负责人说：“以前觉得机器开着不贵，积少成多，一个月多花不少钱。”
写在最后
闲置资源是云成本的黑洞。机器开着，没人用，但钱照付。
那家客户的运维负责人后来总结：“先扫描，找出睡觉的机器；降配比关机风险小，先降再关；自动化比人工靠谱；白名单保护核心业务。”
你的云上，有多少机器在睡觉？今天就去查查。
