Blueking Lite 本周上线了内置僵尸机分析报表，目标很直接：把长期低负载、低频使用或可能闲置的资源筛选出来，为降配和回收提供依据。对于资源规模不大、又不希望引入重型平台的团队，这类开箱即用的分析能力比单纯展示 CPU 曲线更实用。
本次更新还涉及平台布局切换、接口文档及 PDF 导出、凭据仓库等系统管理能力。它们共同指向一个方向：让轻量运维平台不仅能“看见问题”，还具备接入现有流程和执行治理动作的基础。
僵尸机分析解决的不是监控，而是决策
传统监控通常回答“这台机器现在是否异常”，僵尸机分析则要回答另一个问题：“这项资源还有没有必要保持当前规格”。两者使用相似的指标，但观察窗口和判断逻辑不同。
一个可用于资源治理的候选规则通常需要组合多项证据：
- 在 14 至 30 天窗口内，CPU 平均利用率持续偏低；
- 内存峰值距离容量上限较远，而非仅看平均值；
- 磁盘读写、网络流量或请求次数长期处于低位；
- 资源没有近期发布、扩容、迁移或容灾职责；
- 业务负责人能够确认其用途和维护窗口。
因此，“僵尸机”更适合作为待核查标签，而不是自动回收结论。批处理节点、灾备实例、月末任务和低流量但高价值的服务，都可能在常规观察窗口内表现得很安静。
报表应当把资源分成可执行队列
一张只有利用率排行的报表很难推动治理。更有效的输出方式，是把资源映射到明确动作：
| 分类 | 典型信号 | 建议动作 |
|---|---|---|
| 疑似闲置 | CPU、内存、网络均长期低位 | 联系负责人，确认后停机观察 |
| 可降配 | 平均负载低，但仍有稳定访问 | 选择低一档规格并设置回滚条件 |
| 低频使用 | 大部分时间空闲，固定时段活跃 | 定时启停或迁移到弹性资源 |
| 暂不处理 | 指标不足、用途未知或存在峰值 | 补充标签和监控，延长观察窗口 |
Blueking Lite 的内置报表可以降低发现候选资源的门槛，但真正产生节省的环节仍然是责任人确认、变更审批、执行和复核。平台接口文档以及凭据仓库的加入，也为后续把这些环节接入自动化流程提供了条件。凭据应由仓库托管并按最小权限授权，不应直接写进脚本或流水线变量文件。
可以这样实践：生成一份降配候选清单
下面是一个不依赖第三方库的最小示例。由于摘要没有给出 Blueking Lite 的具体接口字段，这里假设先从平台或监控系统导出 resources.csv，再由脚本生成初筛结果。实际使用时，应按接口文档替换字段映射和数据获取部分。
创建 resources.csv：
resource_id,owner,days,cpu_avg,cpu_p95,memory_p95,network_mb_day
vm-001,team-a,30,3.2,8.4,21.0,18
vm-002,team-b,30,11.5,42.0,67.0,820
vm-003,team-c,7,1.8,5.0,14.0,3
vm-004,team-a,30,6.1,18.0,38.0,96
创建 classify_resources.py：
#!/usr/bin/env python3
import csv
MIN_DAYS = 14
def classify(row):
days = int(row['days'])
cpu_avg = float(row['cpu_avg'])
cpu_p95 = float(row['cpu_p95'])
memory_p95 = float(row['memory_p95'])
network = float(row['network_mb_day'])
if days < MIN_DAYS:
return 'insufficient_data'
if cpu_avg < 5 and cpu_p95 < 15 and memory_p95 < 30 and network < 50:
return 'possible_idle'
if cpu_avg < 10 and cpu_p95 < 30 and memory_p95 < 50:
return 'downsize_candidate'
return 'keep'
with open('resources.csv', newline='', encoding='utf-8') as source:
rows = list(csv.DictReader(source))
for row in rows:
row['recommendation'] = classify(row)
fields = list(rows[0]) if rows else []
with open('candidates.csv', 'w', newline='', encoding='utf-8') as target:
writer = csv.DictWriter(target, fieldnames=fields)
writer.writeheader()
writer.writerows(rows)
print(f'Wrote {len(rows)} records to candidates.csv')
运行并查看结果：
python3 classify_resources.py
column -s, -t candidates.csv
阈值必须根据业务类型调整。例如，Java 服务不宜只根据平均内存判断，周期性任务应覆盖完整业务周期，生产实例还应检查高峰时段的 P95 或 P99 指标。建议把分类结果作为工单输入，而不是直接调用关机或缩容接口。
把 AI 用在解释和归因，而不是跳过审批
AI First 运维产品可以进一步帮助管理员汇总多个指标、解释异常模式，并把“为什么推荐降配”转换成可读结论。例如，一条建议可以同时列出观察窗口、CPU P95、内存峰值、最近变更和资源负责人，而不是只返回一个风险分数。
但模型结论仍受数据质量制约。资源标签缺失、采样间隔过长、指标断档或业务周期覆盖不完整，都会造成误判。面向生产环境时，至少应保留以下控制措施：
- 推荐依据可追溯，能查看使用的指标、窗口和阈值；
- AI 建议与执行权限分离，默认需要人工审批；
- 降配前保存原规格，并定义明确的回滚指标；
- 变更后持续观察错误率、延迟、负载和业务吞吐；
- 所有凭据通过凭据仓库引用，并记录访问审计。
落地顺序：先建立闭环，再提高自动化程度
团队可以先从非核心环境和明确归属的资源开始，每周处理一批候选项。推荐采用“报表发现、负责人确认、低风险变更、观察复核”的闭环，连续运行两到四周后再调整阈值。
经典布局与应用顶栏模式切换属于使用体验改进；接口文档和 PDF 导出便于集成与内部评审；凭据仓库则承担自动化访问的安全基础。把这些能力组合起来后，僵尸机报表才不只是一次性盘点工具，而能成为持续容量治理流程的入口。
上线前可以检查五件事：观察窗口是否覆盖业务周期、指标是否包含峰值、资源是否有明确负责人、变更是否可回滚、凭据和操作是否留有审计记录。满足这些条件，再逐步从人工筛选推进到半自动治理。