代码
#!/bin/bash
# 阿里云监控/云盾组件占用扫描脚本（只统计不删除）
RESULT_FILE="log_aliyun_soft_scan_result.txt"
> $RESULT_FILE # 清空旧结果
# 阿里云核心冗余组件目录（固定路径，精准匹配）
ALI_DIRS=(
"/usr/local/aegis" # 云盾安骑士核心目录
"/var/log/aliyun" # 阿里云监控日志目录
"/var/lib/aliyun" # 阿里云组件缓存目录
"/usr/lib/systemd/system/aliyun-*.service" # 阿里云服务配置
"/etc/aliyun" # 阿里云配置目录
"/usr/bin/aliyun*" # 阿里云命令行工具
"/usr/sbin/aliyun*" # 阿里云服务命令
)
TOTAL_SIZE=0
TOTAL_FILES=0
echo "========== 阿里云监控/云盾组件占用扫描结果 ==========" >> $RESULT_FILE
echo "扫描时间：$(date "+%Y-%m-%d %H:%M:%S")" >> $RESULT_FILE
echo "说明：仅统计占用，不删除，供决策是否卸载" >> $RESULT_FILE
echo "======================================================" >> $RESULT_FILE
# 循环扫描每个目录/文件
for dir in "${ALI_DIRS[@]}"; do
echo -e "\n【扫描目标：$dir】" >> $RESULT_FILE
# 查找实际存在的文件
FILES=$(find $dir 2>/dev/null)
if [ -z "$FILES" ]; then
echo "目录/文件不存在" >> $RESULT_FILE
continue
fi
# 统计文件数和大小
FILE_COUNT=$(echo "$FILES" | wc -l)
DIR_SIZE=$(du -b $dir 2>/dev/null | awk '{print $1}')
# 单位转换
DIR_SIZE_MB=$(echo "scale=2; $DIR_SIZE/1024/1024" | bc)
DIR_SIZE_GB=$(echo "scale=2; $DIR_SIZE/1024/1024/1024" | bc)
# 输出详情
echo "文件个数：$FILE_COUNT 个" >> $RESULT_FILE
echo "总占用：$DIR_SIZE 字节（$DIR_SIZE_MB MB / $DIR_SIZE_GB GB）" >> $RESULT_FILE
# 累加总统计
TOTAL_SIZE=$((TOTAL_SIZE + DIR_SIZE))
TOTAL_FILES=$((TOTAL_FILES + FILE_COUNT))
done
# 总统计汇总
TOTAL_SIZE_MB=$(echo "scale=2; $TOTAL_SIZE/1024/1024" | bc)
TOTAL_SIZE_GB=$(echo "scale=2; $TOTAL_SIZE/1024/1024/1024" | bc)
echo -e "\n========== 阿里云组件占用合计 ==========" >> $RESULT_FILE
echo "合计文件总数：$TOTAL_FILES 个" >> $RESULT_FILE
echo "合计总占用：$TOTAL_SIZE 字节 = $TOTAL_SIZE_MB MB = $TOTAL_SIZE_GB GB" >> $RESULT_FILE
echo -e "\n扫描完成，结果已保存至 $RESULT_FILE"
cat $RESULT_FILE以阿里云冗余组件清理为例：浅谈服务器瘦身的双重价值 ------ 释放资源 + 降低漏洞风险
在服务器日常运维中，很多运维人员都会遇到这样的困惑：明明没有部署高负载业务，服务器磁盘却在缓慢被占用、系统响应偶尔莫名卡顿；明明定期做了漏洞扫描，却总有无头苍蝇般的低危漏洞提醒，甚至偶尔爆出高危漏洞无从溯源。
这份阿里云监控 / 云盾组件扫描脚本，正是运维人员应对此类问题的第一步 ------ 它不直接执行删除操作，而是精准统计阿里云系列冗余组件（安骑士、监控、命令行工具等）的文件数量与磁盘占用，为后续的服务器 "瘦身" 提供数据支撑。而服务器瘦身，远不止释放磁盘空间这么简单，更核心的价值在于：冗余软件越少，服务器暴露的高危漏洞越少，整体安全性越高。
一、先看清：冗余组件到底在 "消耗" 什么？
我们先从这份扫描脚本的作用说起，它针对阿里云服务器默认预装的一系列监控、云盾组件，划定了 7 个核心扫描路径，从组件安装目录、日志缓存，到系统服务配置、命令行工具，实现了全维度的占用统计。这些组件在服务器初期部署时，或许能提供一定的基础监控与安全防护能力，但在实际运维过程中，很多企业会部署更贴合自身业务的运维监控系统（如 Zabbix、Prometheus）和安全防护方案，此时这些默认预装的组件就变成了 "食之无味、弃之可惜" 的冗余存在，而它们的 "消耗" 却真实可见。
1. 硬件资源的无意义占用
这是最直观的消耗。从脚本的统计逻辑来看，它会累加所有冗余组件的文件数量与磁盘占用，小到几 MB 的命令行工具，大到几十 GB 甚至上百 GB 的日志缓存文件，长期累积下来，会严重挤占服务器的宝贵磁盘空间。尤其是对于一些采用云服务器轻量磁盘配置的企业，这种无意义的占用可能直接导致磁盘满溢，引发业务服务崩溃、日志无法写入等一系列故障。
除此之外，这些冗余组件大多会以系统服务的形式后台运行，默默占用 CPU 资源与内存空间。即使是低负载运行，长期下来也会拖慢服务器整体响应速度，增加业务服务的运行延迟，对于对实时性要求较高的业务（如电商交易、在线支付）而言，这种隐性的性能消耗可能带来不可预估的损失。而通过这份脚本先摸清占用底数，再进行针对性清理，相当于为服务器 "减负"，让硬件资源能集中服务于核心业务，提升整体运行效率。
2. 安全防线的 "隐形漏洞入口"
这是比硬件资源消耗更值得警惕的风险，也是我们核心强调的 "冗余软件越少，高危漏洞越少" 的底层逻辑。很多运维人员存在一个认知误区：只要不启用冗余组件，它就不会带来安全风险。但事实恰恰相反，任何一款软件，只要它存在于服务器的磁盘中，并且以某种形式（即使是休眠状态）注册在系统中，就存在被利用的安全隐患。
这些默认预装的阿里云冗余组件，和所有软件一样，都存在自身的版本迭代与漏洞修复周期。阿里云官方会定期发布组件的安全更新，但很多企业在运维过程中，往往会忽略这些非核心业务组件的更新维护 ------ 一方面，运维人员的精力集中在核心业务系统上，无暇顾及这些 "无关紧要" 的组件；另一方面，很多冗余组件的更新通道与服务器核心系统脱节，难以纳入统一的运维更新体系。
这就导致了一个严重的问题：这些冗余组件长期处于 "版本过时" 状态，其中可能包含已经被公开披露的高危漏洞。黑客在进行服务器渗透攻击时，往往会通过全网扫描，寻找这些存在已知漏洞的老旧软件作为突破口。一个看似无关紧要的阿里云监控组件漏洞，就可能成为黑客进入服务器内部的 "敲门砖"，进而横向移动，窃取核心业务数据、篡改业务配置，甚至掌控整个服务器集群。
更可怕的是，这些冗余组件因为不被运维人员重视，即使已经被黑客利用，也很难在第一时间被发现。相比之下，如果服务器上只保留核心业务必需的软件，运维人员就能集中精力对这些软件进行版本更新、漏洞修复，形成更聚焦、更牢固的安全防线。这就像一个家庭，多余的门窗越多，被小偷突破的可能性就越大；关闭并封死那些无用的门窗，只保留核心出入口，才能更好地防范盗窃风险，服务器瘦身的核心安全逻辑正在于此。
二、再明白：服务器瘦身，该如何 "科学操作"？
通过这份阿里云组件扫描脚本，我们已经能清晰地摸清冗余组件的 "家底"，但服务器瘦身并非 "一刀切" 的删除操作，而是一套科学的运维流程，既要实现 "减负" 与 "降风险" 的目标，又要避免误删核心组件，引发不必要的业务故障。
1. 先统计，再决策：用数据支撑瘦身行动
这份扫描脚本的一大亮点就是 "只统计不删除"，这正是科学瘦身的第一步。在进行任何清理操作前，必须先通过扫描工具，明确冗余组件的分布、占用规模、与系统核心服务的关联度。对于脚本输出的统计结果，运维人员需要进行逐一核对：哪些组件确实从未启用过？哪些组件与核心业务服务无任何关联？哪些组件的占用规模已经达到了必须清理的程度？
只有基于这些数据做出的清理决策，才能避免 "盲目删、误删" 的风险。例如，对于一些虽然冗余但占用空间极小，且与系统核心服务存在微弱关联的组件，可暂时保留，优先清理那些占用空间大、无任何关联、且存在已知漏洞的冗余组件，实现 "收益最大化、风险最小化" 的瘦身目标。
2. 先备份，再清理：为服务器留好 "退路"
在明确清理目标后，正式清理前，必须对相关组件进行完整备份。尤其是对于一些系统默认预装的组件，可能存在一些隐藏的配置文件与系统核心配置相关联，直接删除可能导致系统服务异常。此时，可通过打包压缩的方式，将冗余组件的完整目录备份至外接存储或云存储中，一旦清理后出现异常，可快速进行恢复，将业务损失降至最低。
3. 清理后，再验证：确保业务与安全双稳定
清理完成后，需要进行两轮验证：一是业务稳定性验证，检查核心业务服务是否能正常启动、运行，服务器的 CPU、内存、磁盘占用是否得到有效优化；二是安全漏洞验证，通过漏洞扫描工具对服务器进行全维度扫描，查看是否还存在与已清理冗余组件相关的漏洞提醒，验证服务器的安全防线是否得到加固。
同时，清理完成后，还需要将这些冗余组件从系统开机自启服务中移除，避免服务器重启后，这些组件再次自动运行，造成二次资源消耗与安全风险。
三、最后总结：服务器瘦身，是一场长期的运维修行
服务器瘦身，从来不是一项一次性的运维任务，而是一场长期的、持续的运维修行。随着企业业务的迭代升级，服务器上会不断产生新的冗余组件、日志文件、过期配置，这些都可能成为资源消耗的 "源头" 与安全漏洞的 "入口"。
而这份阿里云组件扫描脚本，不仅为我们提供了一种针对特定冗余组件的统计方法，更为我们树立了一种 "先摸清、再决策、后执行" 的科学运维理念。它让我们明白，服务器运维的核心，不仅是保障业务的正常运行，更是通过持续的优化与清理，构建一个 "轻量、高效、安全" 的运行环境。
回到我们最初的核心观点：冗余软件越少，高危漏洞越少。服务器的安全防线，从来不是靠堆砌更多的安全软件来构建的，而是靠 "做减法"，剔除一切无用的冗余存在，集中精力守护核心业务的安全。这场服务器瘦身的修行，既是对服务器硬件资源的优化，更是对企业核心业务安全的负责。在网络安全威胁日益严峻的今天，这样的修行，值得每一位运维人员投入足够的精力与重视。
总结
- 服务器冗余组件的危害包含两层：一是无意义占用磁盘、CPU 等硬件资源，拖慢业务运行效率；二是作为 "隐形漏洞入口"，未及时更新的冗余软件易被黑客利用，且难以被运维人员察觉。
- 科学的服务器瘦身遵循 "统计 - 决策 - 备份 - 清理 - 验证" 的流程，核心是 "只清冗余、不碰核心"，兼顾资源释放与业务安全。
- 服务器瘦身的核心价值是 "做减法"，冗余软件越少，运维人员的安全防护聚焦度越高，服务器暴露的高危漏洞越少，整体安全性越有保障。
阿雪技术观
在科技发展浪潮中，我们不妨积极投身技术共享。不满足于做受益者，更要主动担当贡献者。无论是分享代码、撰写技术博客，还是参与开源项目维护改进，每一个微小举动都可能蕴含推动技术进步的巨大能量。东方仙盟是汇聚力量的天地，我们携手在此探索硅基生命，为科技进步添砖加瓦。
Hey folks, in this wild tech - driven world, why not dive headfirst into the whole tech - sharing scene? Don't just be the one reaping all the benefits; step up and be a contributor too. Whether you're tossing out your code snippets, hammering out some tech blogs, or getting your hands dirty with maintaining and sprucing up open - source projects, every little thing you do might just end up being a massive force that pushes tech forward. And guess what? The Eastern FairyAlliance is this awesome place where we all come together. We're gonna team up