Windows主机信息收集成果量化评估与可视化大屏实战

拿到一堆信息收集成果之后，最尴尬的事情是什么？不是数据不够，而是数据多到没人看。我见过太多评估项目开头就是“唰唰唰”跑采集脚本，Windows 主机信息收集一晚上下来就是几千上万条记录，systeminfo、进程、服务、端口、计划任务堆成四五个 Excel sheet，最后汇报的时候只能把原始表格往投影上一甩。你辛辛苦苦收集的信息，在决策者眼里就是一堆密密麻股的乱码，价值约等于零。

这个项目就是来解决这个问题的：把信息收集成果做量化评估，再用可视化大屏呈现出来。核心思路不复杂——先定义一套评分规则，让每台主机的信息能换算成分数；再用 Python 做数据处理和可视化图表，最后合成一页可交互的 HTML 可视化大屏。适合做安全评估、资产梳理、运维体检的朋友参考，也适合想把自己的数据收集能力从“能跑脚本”升级到“能把结论讲清楚”的人。

我自己实践下来，这套流程从采集到出图，一个人两天就能搭完。下面把整个思路、选型、编码细节和踩过的坑都摊开讲。

1. 项目定位：把信息收集从“交差”变成“决策”

1.1 信息收集成果为什么需要量化评估

先说一个很普遍的误解：很多人觉得信息收集就是“越全越好”，于是脚本越写越长，字段越采越多，最后采回来一堆互相矛盾、重复、过时的数据。真到了写结论的时候，没人能说清楚“这批主机到底哪台最该优先查”。

量化评估解决的就是这个“看不懂”的问题。它的本质不是替代人去分析，而是把分散的信息点压缩成几个可对比、可排序、可解释的数字。比如同样两台 Windows 主机，A 主机采集到 14 类信息、开放了 3 个高危端口、有 2 条可疑外联；B 主机只采集到 5 类信息、但有 20 条异常计划任务。如果没有统一评分，你只能凭感觉说“B 好像问题多一点”。有了评分模型之后，A 得 81 分、B 得 66 分，优先级立刻清晰。

另一个常被忽略的价值是：量化能反向检验“采集动作本身的质量”。很多评估项目跑完，发现某些主机信息根本没采全，因为权限不够、脚本报错、主机离线。如果没有完整度这个维度，后面所有分析都建立在不完整的数据上，结论自然经不起推敲。所以我在评分模型里把“信息完整度”放进去，先判断“我这轮收获得够不够”，再判断“收获里面有没有问题”。

1.2 评分模型设计：三个维度一个公式

我用的量化模型包含三个维度，权重设置如下：

综合得分公式：

综合得分 = 100 × (0.3 × 完整度 + 0.5 × 风险密度归一化 + 0.2 × 线索价值归一化)

这里解释一下为什么权重这么分配。风险密度给到 0.5，是因为这个项目的核心受众是安全评估和运维体检，领导最关心的是“哪台机器最容易出事”；信息完整度给 0.3，是给整个评估的可靠性兜底，数据不全时分数自然被压低；线索价值给 0.2，是考虑到有些主机虽然风险不高，但信息之间的关联性很强，值得人工顺藤摸瓜。如果你的场景是“纯资产盘点”，可以把完整度权重调高到 0.5，风险密度降到 0.3。

得分映射到三个区间：90-100 为高价值主机，优先深入排查；70-89 为中等关注，常规复核；70 分以下需要检讨是不是数据采漏了，或者主机本身存在明显问题。阈值不是拍脑袋定的，我建议先用历史一批主机数据回带跑一遍，看分布是否符合直觉，再微调。

2. 可视化呈现：选型、布局与图表业务映射

2.1 为什么选择“HTML + ECharts”而不是现成大屏工具

做可视化之前我纠结过一阵子：是直接用 Grafana，还是自己写页面？中间还专门研究过 Redis 可视化客户端、Kafka 可视化工具的思路，发现一件事——好的工具本质上都是解决同一个问题：数据有，但不好读，所以要找一个更符合人眼习惯的呈现方式。Grafana 当然很好，但在“离线评估 + 报告交付 + 非持续性监控”这个场景里反而是重资产。

最后选了 HTML + ECharts 方案，原因很实际：

ECharts 本身很成熟，图表类型丰富，中文文档友好，而且 pyecharts 可以直接把 Python 数据变成 ECharts 配置，省去了手写一堆 JSON option。整个项目的数据流就是：采集脚本生成原始 JSON → Pandas 清洗 → 评分函数计算 → pyecharts 生成图表 → 渲染进 HTML 模板 → 打包成可视化大屏。

2.2 大屏布局：每张图表都要回答一个问题

我见过很多失败的可视化大屏，通病是把所有能画的图都塞上去，最后变成“图表全家福”。我的布局原则是：一张图表必须且只能回答一个问题。评估大屏的整体布局如下：

• 顶部：标题和总体指标卡，展示总主机数、平均综合得分、高风险主机数、信息完整度均值。
• 左侧：信息完整度分布环形图，回答“这轮采集到底采全了没有”。
• 中间：TOP10 高风险主机横向柱状图，回答“优先排查哪几台”。
• 右侧：风险特征分类统计，用饼图展示高危端口、异常外联、可疑进程各占多少。
• 底部：单机维度雷达图联动，点击柱状图里的主机名时切换，回答“单台主机的强项和短板分别在哪”。

这样的好处是汇报时有一张主页就够了。业务逻辑上，你可以先在主页上面看到整体形势，然后逐步下钻到单台主机的雷达图，再点“查看明细”弹出这台主机的原始采集记录。整个过程像讲故事，而不是甩表格。

3. 实操过程：从采集脚本到评估大屏全流程

3.1 Windows 主机信息采集与数据清洗

先说采集端。Windows 主机的信息收集脚本我一般用 PowerShell 写，因为系统自带，不需要额外安装 agent。为了方便后面 Python 处理，统一输出成 JSON 格式。核心采集项包括：

• 系统基本信息：hostname、系统版本、补丁列表
• 网络连接与端口监听：netstat -ano 结果
• 进程列表：进程名、PID、可执行路径
• 服务信息：服务名、状态、启动类型
• 计划任务：任务名称、触发器、执行动作
• 启动项：注册表 Run 键、启动文件夹内容
• 用户与组信息（仅限授权评估范围内）

下面是一段简化的采集脚本示例：

$result = @{} # 系统信息 $result.hostname = $env:COMPUTERNAME $result.os = Get-WmiObject Win32_OperatingSystem | Select-Object -ExpandProperty Caption # 网络连接 $result.netstat = netstat -ano | Select-Object -First 200 # 进程列表 $result.processes = Get-Process | Select-Object ProcessName, Id, Path # 计划任务 $result.tasks = Get-ScheduledTask | Select-Object TaskName, State $result | ConvertTo-Json -Depth 3 | Out-File -Encoding utf8 "$env:COMPUTERNAME.json"

注意最后一定要用-Encoding utf8，否则 Python 端读中文会乱码。这行代码我吃了三次亏才记住。

采集完成后，所有 JSON 文件集中到一个目录，接下来就是 Python 数据分析与可视化的主场。第一步是用 Pandas 把所有主机数据合并成一张表，并做基础清洗：

import pandas as pd import json import glob records = [] for f in glob.glob("data/*.json"): with open(f, "r", encoding="utf-8") as fp: data = json.load(fp) records.append({ "hostname": data.get("hostname"), "os": data.get("os"), "netstat_count": len(data.get("netstat", [])), "process_count": len(data.get("processes", [])), "task_count": len(data.get("tasks", [])), }) df = pd.DataFrame(records) df = df.drop_duplicates(subset="hostname") df = df.fillna(0)

这里的关键动作是去重和空值填充。实际采集中会出现同一台主机被反复采集多次的情况，以 hostname 为粒度去重；空值直接填充为 0 而不是删除行，是因为一台主机采集失败也是一个有效信号，它会让“信息完整度”这个维度如实反映出来。

3.2 量化评分模型落地实现

清洗之后进入评分环节。我的做法是先把每个维度的原始数据转成分数，再按权重合成。下面这段函数是核心：

def score_host(row): # 信息完整度：预设了 8 类关键字段，按实际存在比例计算 fields = ["os", "netstat_count", "process_count", "task_count"] present = sum(1 for f in fields if row.get(f, 0) and row.get(f) != "未知") completeness = present / len(fields) # 风险密度：从原始数据中统计风险点数量，这里用简化字段替代 risk_points = row.get("high_port_count", 0) + row.get("suspicious_conn_count", 0) risk_density = min(1.0, risk_points / 10) # 线索价值：外联 IP 数量和自启动项数量越多，越值得人工牵引 leads = min(1.0, row.get("external_ip_count", 0) / 5) total = 100 * (0.3 * completeness + 0.5 * risk_density + 0.2 * leads) return round(total, 1) df["score"] = df.apply(score_host, axis=1)

风险密度里我做了归一化处理，把风险点数量除以 10，封顶为 1，原因是一台主机发现 10 个风险点和发现 50 个风险点，在决策层面已经“都算严重”，不需要线性放大。线索价值除以 5 也是同理，外部连接数据一旦超过 5 个，就足以触发人工排查，后面数字再大也只是噪声。

评分出来之后，我用 Pandas 的 cut 函数做区间分级：

bins = [0, 70, 90, 100] labels = ["需要复查", "中等关注", "高价值"] df["level"] = pd.cut(df["score"], bins=bins, labels=labels)

这个分级结果后面会直接用于大屏配色，高价值主机显示为深红色，中等关注显示为橙色，需要复查显示为灰色。颜色映射在可视化环节很关键，因为观众第一眼看到的不是数字，是颜色。

3.3 可视化大屏生成与“点击按钮、打印日志”交互

可视化部分我用 pyecharts 生成图表，然后拼进 HTML 模板。pyecharts 的好处是生成的图表自带交互，鼠标悬停就能看明细，对评估报告这种既需要全景又需要细节的场景很合适。先看一个柱状图的生成：

from pyecharts.charts import Bar from pyecharts import options as opts top10 = df.nlargest(10, "score") bar = ( Bar() .add_xaxis(top10["hostname"].tolist()) .add_yaxis("综合得分", top10["score"].tolist()) .set_global_opts( title_opts=opts.TitleOpts(title="TOP10 主机综合得分"), yaxis_opts=opts.AxisOpts(name="得分"), ) )

生成完图表后，通过bar.render_embed()拿到渲染后的 HTML 片段，再用 Jinja2 模板把所有图表嵌入同一个页面。页面布局用 CSS Grid 两行三列，顶部指标卡用 ECharts 的gauge或者单纯 HTML 卡片都行，我习惯用 HTML 卡片，加载更快，也没有无用交互。

这里特别说一下交互细节。用户搜“点击按钮、打印日志即可”的时候，我想起来自己也踩过不少坑。一开始我做的大屏只有图表，没有“导出详细评估日志”的入口，导致汇报现场别人问“你这 81 分凭什么”，我只能现场翻代码解释。所以后来我在大屏右上角加了一个“打印评估日志”按钮，点击后用 JavaScript 把每台主机的评分明细输出到控制台：

<button onclick="printLog()">打印评估日志</button> <script> function printLog() { const data = JSON.parse(document.getElementById('score-data').textContent); data.forEach(item => { console.log(`${item.hostname} 得分=${item.score} 完整度=${item.completeness} 风险密度=${item.risk_density}`); }); } </script>

这小成本做得特别值。汇报的时候只要打开浏览器控制台，点一下按钮，每个分数的构成都清清楚楚，说服力直接上一个台阶。如果有持续采集的需求，还可以在页面里设置setInterval定时重新 fetch 更新后的 JSON，实现准实时刷新。

4. 落地过程中的坑与排查实录

4.1 数据噪声与误报：先给自己泼盆冷水

第一次跑完评分，我把 TOP10 拉出来一看，差点笑出声：排前面的全是“活多事也多”的域控服务器和文件服务器。它们确实开放了大量端口，也确实有大量网络连接，但绝大多数是正常业务流量。直接套用风险密度公式，等于惩罚了业务最繁忙的主机。

后来我在风险点统计里加了白名单机制。比如网络连接里的目的 IP，先跟已知业务服务器 IP 列表比对；进程列表里的 wscript、powershell、rundll32 这类高可疑对象，不能见一个报一个，要看它的父进程和启动参数是否匹配正常运维任务。白名单做成一个字典放在配置里：

whitelist = { "ip": ["10.10.1.10", "10.10.2.20"], "process_cmdline": ["C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"] }

误报是量化模型最大的敌人。宁可让一个异常藏在水下，也不要让十个误报把真实风险淹没掉，因为一旦汇报对象发现“这大屏标红的机器其实没事”，整个评估的可信度就崩了。洗数据花的时间永远比建模多，这句话放在信息收集领域一样成立。

4.2 评分分布不合理：阈值不是拍脑袋

有次客户环境跑完，所有主机得分都在 85 分以上。我一开始很高兴，觉得“评估质量真好”，后来一想不对——这个结果等于没区分度，汇报时“高价值主机”占了大半个屏幕，领导只会说“那是不是都该处理？”，这没法落地。

问题出在风险密度的归一化因子定太高了。那批主机本身暴露面小，最高风险点也就 3 个，我拿来归一化的分母却是 10，所以大家风险密度得分都集中在 0.3 以下，区分度全被压没了。修复方式是先看一次数据分布，按实际分位数来定归一化分母，比如把分母定为“所有主机风险点数量的 75 分位数”，这样 TOP 25% 的主机分数自然拉开。我后面也把评分函数加了一个calibrate阶段，每次跑完先用样本数据校准，再出正式结果。

4.3 可视化体验优化的三个细节

第一，配色必须用“红绿灯”逻辑，不要用彩虹色。高价值、中等关注、需要复查分别对应红、黄、灰，用户扫一眼就能形成判断。ECharts 默认的彩色系列好看，但用在风险场景里会干扰语义。

第二，tooltip 里放明细，不要只放数值。大屏柱状图鼠标悬停时，我会额外显示这台主机的端口数、外联 IP 数、任务数、采集时间，让观众不用再翻原始报告。

第三，中文字体要统一指定。pyecharts 默认字体在部分 Windows 机器上会渲染成宋体，观感很“古董”。我直接在模板 CSS 里加一句：

body, div { font-family: "Microsoft YaHei", "PingFang SC", sans-serif; }

4.4 常见问题速查表

排查逻辑也很简单：先看数据进了没有，再看评分对不上是哪个维度出了问题，最后看图表渲染是不是参数配置错了。大部分问题都能在 5 分钟内定位。

我个人做完这个项目最深的体会是：量化评估和可视化都不是目的，而是手段。量化帮你在几千条记录里快速锁定“该看哪里”，可视化让这个结论能被不同角色的人快速接受。做的时候别贪多，第一次只需要把完整度算明白、把 TOP 问题主机展示出来就够了。后续如果要把这套能力扩展到更长周期的监控，可以考虑对接时序数据库，或者做成编辑器插件，但我始终建议先用手工采集 + 离线大屏的方式跑通一次流程，用起来之后再谈自动化。毕竟，能让人看懂的交付物，比一个无人访问的漂亮平台有价值得多。