企业官网建设流程全解析

机房夜班最怕什么？不是交换机闪灯，不是服务器风扇狂转，而是存储阵列在你手机还没响的时候先响了。我手里管着两台颇有代表性的中端存储——一台HPE 3PAR C630，一台H3C CF22030，一个外资品牌的老将，一个国产全闪的新锐。今天把这两台设备这些年用下来的监控命令集整理成文，希望能帮同样要伺候这两类存储的朋友少走弯路。

这套命令集解决的就是存储运维里最核心的三件事：容量还够不够、磁盘有没有坏、控制器和端口状态正不正常。覆盖日常巡检、故障定位、自动化采集三大场景。刚接手存储的新人可以照着命令敲一遍，老运维则可以拿走改造自己的巡检脚本。

1. 先摸清家底：这两台存储到底在机房干什么

1.1 一台块存储老将，一台国产全闪新锐

HPE 3PAR C630是3PAR中端产品线里的主力型号，也是很多人接触3PAR的第一台设备。它的核心优势在于硬件ASIC加速和小颗粒度chunklet数据分布机制。传统存储做RAID是把一整块盘绑进一个RAID组，3PAR会把每块盘切成很小的chunklet再均匀打散到所有磁盘上，所以它的热点分布比传统阵列均匀得多。C630支持FC、iSCSI、NAS等多种协议，混合负载场景下表现很稳，虚拟机、数据库、文件共享都能扛。

H3C CF22030则完全是另一个路数。它是H3C UniStor CF22000系列里的全闪阵列，型号里的30一般对应容量档位或者盘位规模。全闪配置让它在高IOPS场景里有天然优势，尤其适合数据库在线日志、容器平台、VDI这类对响应时间敏感的负载。最近几年国产化替代需求多，CF22030在政企、金融、教育行业的出场率明显上升。

这两台设备的定位和监控逻辑其实不一样。3PAR C630我更多担心的是机械盘老化、RAID重构、chunklet分布是否均匀；CF22030是全闪，反而更关注SSD磨损寿命、控制器瓶颈和光纤链路协商速率。所以监控命令虽然都叫“看状态”，但看的东西侧重点完全不同。

1.2 存储监控为什么不能只靠看灯

存储设备有个特点：它是“慢变量”设备。服务器出问题往往是即时的，比如宕机、死循环、内存溢出，一台机器挂了影响的是单点业务。但存储不一样，一块磁盘从出现坏道到彻底fail可能持续几周甚至几个月，控制器内存从频繁纠错到真正报错也是一点点劣化的过程。这个过程中，数据可能已经在悄悄处于危险状态。

所以存储监控的关键是“把慢变量变成可观测的趋势”。你需要在故障真正发生之前，看到磁盘错误计数在上涨、控制器CPU使用率在爬坡、容量水位在逼近阈值。这也是为什么命令行监控比Web界面更值得依赖——Web界面适合单次查看，但命令行的输出格式统一、字段明确，方便脚本化采集、历史化对比。

1.3 命令集的三条主线

我整理监控命令时习惯分成三条主线，后面所有命令都按这个逻辑组织：

• 状态类命令：回答“现在有没有问题”。比如告警查看、磁盘状态、控制器状态、端口状态。
• 性能类命令：回答“现在快不快”。比如IOPS、带宽、时延、CPU占用率。
• 空间类命令：回答“还能撑多久”。比如卷容量、池容量、chunklet使用情况。

这三条主线分别对应存储运维的三个核心问题：安全、效率、容量。日常巡检按这三条线走一遍，基本能把存储的健康状况摸个八九不离十。

2. 3PAR C630：这套命令背下来，日常巡检就稳了

2.1 登录方式和权限控制

3PAR的CLI登录方式很简单，SSH到存储管理IP，默认端口22，用户一般是3paradm或者单独创建的只读用户。登录后直接进入CLI界面，不需要像网络设备那样再输入enable进入特权模式。对于已经熟悉Cisco或H3C网络设备的人来说，这个设计反而要小心——没有模式隔离，意味着你在普通会话里也能敲出配置类命令。

我的建议是严格区分账号用途。日常巡检单独创建一个只读账号，比如monitor_c，只授权show类命令权限。运维操作再用3paradm主账号。这样就算巡检脚本逻辑写错了，最多也就是多看几遍输出，不会把生产配置搞坏。3PAR的权限体系可以做到命令级授权，这个能力别浪费。

登录后有几个实用习惯可以养成。第一，先用showalert看全局告警，这是所有巡检动作的第一步。第二，用showversion确认当前固件版本，很多命令输出字段在不同版本间有细微差异，知道版本才能正确解读。第三，准备退出前用showhealth或者showservicestate整体扫一遍，作为快速体检的收尾。

2.2 第一优先：showalert看告警

showalert是3PAR监控里含金量最高的一条命令，建议每天第一次登录先敲它。它会列出所有硬件和系统告警，输出包含告警ID、状态、严重级别、发生时间、代码和消息描述。

输出里有两个字段需要特别重视。第一个是State，取值一般是New、Ack、Sev三种。New表示告警还没被任何人确认，Ack表示已确认但还没解决，Sev表示当前仍然处于严重状态。第二个是Severity，从轻到重大致是Info、Warning、Minor、Major、Critical、Fatal。真正需要立即处理的，是Critical和Fatal级别的告警，以及所有New状态的新告警。

# 查看所有告警 showalert # 只看新告警 showalert -f new # 按严重级别过滤，数字越小越严重（不同版本参数略有差异） showalert -p 3

实际巡检中我不建议只敲一条裸的showalert然后盯着屏幕看，因为告警多了以后输出非常长。更实用的做法是配合过滤参数，先看新增的、再看严重的。如果showalert -f new输出为空，说明从上一次确认以来没有新问题，这一天的心可以放下大半。

这里有个经验之谈：3PAR的告警，尤其是磁盘相关的，很多是“提示性”的而非“故障性”的。比如某块盘出现几个坏块，系统会报Minor告警，但它会通过内部机制把数据重映射到备用区域。所以看到Minor级别磁盘告警不用立刻准备换盘，但需要持续观察错误计数是否在增长。真正到了Major级别，才需要进入换盘流程。

2.3 磁盘健康是命根子：showpd与showpd -s

磁盘是存储里最脆弱也最容易被量化的部件。3PAR里查看磁盘状态的核心命令是showpd，它会列出每块物理磁盘的详细信息，包括磁盘ID、所在笼位、状态、类型、转速、容量、已分配容量等。

State字段是重点中的重点，常见取值有normal、degraded、failed、absent。normal是正常，failed是彻底故障，absent是物理上检测不到磁盘。这里特别要提醒degraded这个状态，它不直接等同于坏盘，而是表示这块盘的数据完整性和可用性受到了影响。可能是出现了坏道，也可能是某个chunklet读写异常。遇到degraded的第一反应应该是确认原因，而不是直接拔盘。

# 查看所有物理磁盘状态 showpd # 查看系统总体容量（裸容量汇总） showpd -s # 查看磁盘初始化/重构进度，新增盘后必看 showpd -i

showpd -s输出的是整个系统的裸容量汇总，包括总容量、已分配容量、空闲容量。这条命令适合每天早上快速确认“空间有没有突然掉一大块”。如果昨天看总空闲还有20%，今天突然变成10%，那大概率是有卷在做快照或者有大批量数据写入，需要进一步定位。

还要学会看showpd输出里的Degrade列。正常情况下这块应该全是0，只要出现非0值，说明有chunklet处于降级状态，底层数据分布已经受到影响。巡检时如果发现Degrade列有数字，配合showalert看有没有对应告警，基本能确定问题方向。

2.4 卷和逻辑盘：showvv与showld联动排查

3PAR存储里用户看到的是虚拟卷VV，VV底层由逻辑磁盘LD构成，LD再落实到具体的chunklet。这个三层架构是3PAR和传统存储最大的区别，也是排查问题时最容易绕弯的地方。

showvv查看虚拟卷状态。重点关注Prov字段，它标记这个卷是TP（Thin Provisioning，精简配置）还是FP（Fully Provisioned，完全配置）。精简卷的空间是动态分配的，实际使用量可能远小于显示容量。另一个关键字段是V-State，normal是正常状态，如果看到rare、base_only这类非正常状态，说明底层LD可能存在数据不完整的情况。

showld则往下看一层，查看逻辑磁盘的状态。LState字段有complete、initializing、modifying等取值。complete表示正常，initializing说明正在初始化，modifying说明正在做RAID类型调整或扩容。如果LD长期停留在非complete状态，比如一直initializing不结束，就需要深入排查了。

# 查看所有虚拟卷 showvv # 查看虚拟卷详细空间使用 showvv -sp # 查看逻辑磁盘状态 showld

实际排障中，VV和LD要联动看。比如业务反馈某个卷性能突然下降，showvv看V-State正常，但showld发现对应LD正在modifying，那性能下降大概率是底层数据重构导致的，属于正常现象只是需要告知业务方忍耐一段时间。反过来，如果showvv状态异常而showld正常，问题往往出在卷配置或映射层面，和物理盘无关。

2.5 端口、主机和映射：showport/showhost/showvlun

存储和主机之间是通过端口和映射关系连起来的。主机报“看不到存储卷”的时候，很多人第一反应是去查Zoning，但其实存储侧的三条命令就能帮你快速定位问题。

showport查看端口状态，包括FC端口和iSCSI端口。Ready字段是yes还是no直接决定链路通不通，Speed字段看协商速率是否符合预期。如果端口显示no，后端主机那边再怎么做Zoning也看不到盘。另外3PAR有“主机端口”和“磁盘端口”之分，查链路时别只盯着一类看，前后端端口都要过一遍。

showhost显示主机信息，包括主机名、WWN号、操作系统类型。当服务器换了HBA卡或者做了双机切换，WWN会变化，此时showhost里记录的主机信息可能已经过时，映射关系就会对不上。

showvlun则查看虚拟卷和主机之间的映射关系，输出会告诉你哪个VV映射给了哪个主机，对应的LUN ID是多少。

# 查看端口状态 showport # 查看主机信息 showhost # 查看LUN映射 showvlun

我排查主机看不到盘的顺序通常是：先showvlun看映射在不在，再showport看端口up不up，最后showhost确认主机WWN有没有变化。这三个命令按顺序走一遍，90%的“找不到盘”问题都能定位到具体环节。

2.6 性能类命令：statcpu/statport/statvv

存储性能排障和服务器不一样，不能光看CPU和内存，更要关注存储内部的数据路径。3PAR的性能命令以stat开头，含义是“统计”，和show类命令的“状态查看”是两码事。

statcpu查看控制器的CPU使用率，它会显示每个控制器的实时和历史负载，类似Linux下的top命令输出。如果某个控制器CPU长期跑满，说明压力不均或者有异常负载，需要进一步下钻。

statport按端口维度统计IOPS、吞吐量、队列深度。这条命令可以用来判断链路是否成为瓶颈。比如主机侧业务卡顿，但statport显示端口带宽已经打满，那瓶颈就在链路而不在存储本身。

statvv则按照虚拟卷维度统计性能，能直接看出到底是哪个业务卷消耗了最多的IOPS和带宽。这是定位“存储慢是谁拖的”最有用的命令。

# 查看控制器CPU使用率 statcpu # 查看端口性能统计 statport # 查看卷性能统计 statvv # 查看缓存命中率 statcache

使用性能命令有个注意事项：它们本身会消耗系统资源。虽然这个开销通常很小，但在业务高峰期反复长时间跑性能统计还是会造成额外负担。我的习惯是采样几轮，拿到趋势数据就停，不持续挂在那里刷屏。另外性能数据要看历史趋势才有意义，单次的瞬时值说明不了太多。所以如果要长期留存，建议脚本化定期采集并归档。

2.7 容量规划：showvvspace与showpdch

容量监控是存储运维里最“常态化”的工作，也是规划性最强的一部分。3PAR的容量命令看起来很基础，但用好了能避免很多“临时抱佛脚”的扩容操作。

showvvspace按卷展示空间使用详情，包括卷大小、已使用空间、保留空间、快照占用等。重点关注Rsvd字段，它代表这个卷实际占用的物理空间。对于精简卷来说，Rsvd才是真实成本，VSize只是逻辑上限。如果某个卷的Rsvd接近VSize，说明这个卷即将写满，需要提前扩容或者清理数据。

showpdch查看chunklet的分布情况。chunklet是3PAR的数据分布单元，了解chunklet分布能判断底层数据是否均匀。如果大量chunklet集中在某几块盘上，那么这几块盘的负载会远高于其他盘，形成热点。

# 查看卷空间使用 showvvspace # 查看chunklet分布 showpdch # 查看系统整体空间汇总 showspace

showspace是容量报表的核心来源，它把系统总容量、已用容量、可用容量汇总在一张表里。做季度容量规划的时候，直接拿showspace的历史数据进行趋势分析，比逐卷加起来靠谱得多。容量规划的核心思路是“看趋势不看绝对值”，单周的数据说明不了问题，连续两个月的下降斜率才是扩容决策的依据。

3. H3C CF22030监控命令：国产全闪的巡检套路

3.1 登录方式，顺带澄清一个常见误区

H3C CF22030属于H3C UniStor存储产品线。这里必须先澄清一个很多朋友容易混淆的点：很多人因为H3C这个品牌，习惯性拿它和H3C交换机路由器的Comware命令体系去套，这是不对的。CF22030是存储阵列，不是网络设备，登录方式、命令体系、管理思路都和网络设备完全不同。

登录CF22030通常有三种方式。第一是SSH到存储管理IP，在命令行下执行监控命令；第二是登录存储Web管理界面，图形化查看状态；第三是通过带外管理HDM口查看硬件层面信息。日常巡检我最常用的是SSH命令行，因为输出格式统一，方便脚本采集。

我现场这台CF22030固件版本的CLI命令大部分以show开头，下面涉及的命令均以该版本为例。不同版本之间有细微差异，拿不准的时候先敲help或者?查看命令补全列表，这个习惯比死记命令本身更值钱。

3.2 系统状态和告警：第一时间知道存储是否降级

CF22030巡检的第一条命令是查看系统整体状态。存储和服务器不一样，它最怕的不是单部件故障，而是“降级运行”。控制器故障后剩下一个控制器硬扛所有业务，这个状态下性能会明显下降，而且恰好在这个时间点再坏一个控制器，整个存储就会停摆。

# 查看系统整体状态，确认控制器节点角色 show system status # 查看系统告警 show alarm # 查看历史事件记录 show event

show system status输出控制器状态、节点角色、HA状态等信息。正常情况下两个控制器都是active状态，一主一备或者双活。如果看到某个控制器状态是failed或者offline，说明存储已经进入降级运行模式，需要立即处理。

show alarm和3PAR的showalert作用类似，列出所有告警。重点关注Critical级别的告警，以及出现了但还没确认的New告警。show event则能查看历史事件，比如控制器切换记录、磁盘插拔记录。排查问题时先翻这个，很多时候能把故障时间线拼出来。

3.3 磁盘状态和SSD寿命：全闪存储的独特挑战

CF22030是SSD全闪配置，所以磁盘监控的重点和机械盘阵列完全不同。机械盘怕坏道，SSD则怕磨损和高温。温度过高会加速SSD老化，频繁写入会消耗PE寿命。所以全闪存储的磁盘巡检，除了看状态，还要看寿命。

# 查看磁盘列表和状态 show disk # 查看磁盘健康信息和SSD寿命 show disk -s # 查看RAID组状态 show raid

show disk列出所有磁盘的型号、容量、状态。状态字段正常应该是online或者normal，出现degraded、failed就需要告警升级。show disk -s能看到SMART信息，包括磨损度（Wear_Leveling_Count）、媒体磨损指示（Media_Wearout_Indicator）、重定位扇区数、温度等。

这里要特别提醒：全闪阵列换盘不像机械盘那样可以从“有没有异响”来辅助判断，SSD坏了往往就是毫无征兆地从online变成failed。所以SSD寿命数据一定要主动盯，等它彻底挂了再处理，你就已经处于被动位置了。我一般以70%寿命作为警戒线，到线就开始准备备件，低于50%就列入月度重点观察。

3.4 存储池和卷：容量水位的正确视角

全闪存储的容量管理比机械盘阵列更微妙。SSD写入有放大效应，容量使用率越高，GC垃圾回收越频繁，性能劣化越明显。所以全闪阵列的容量阈值要设置得比机械盘更保守，不能等满了再扩。

# 查看存储池容量 show pool # 查看卷状态和容量 show volume # 查看LUN映射 show lun # 查看主机信息 show host

show pool展示存储池的容量、已用空间、剩余空间。容量水位一般建议保持在80%以下，如果超过85%就要触发扩容流程或者清理无效数据。show volume查看每个卷的状态和容量分配情况，和3PAR的showvv类似。show lun查看卷和主机之间的映射关系，show host查看主机WWN和iSCSI发起程序信息。

很多朋友习惯把show disk里的磁盘容量加起来跟领导汇报“系统还有多少空间”，这个做法其实不准确。磁盘容量之和是裸容量，真正业务可用的要扣掉RAID校验空间、热备盘、快照预留、文件系统开销等。所以容量汇报应该以show pool的输出为准，而不是盘子加总。

3.5 性能数据：全闪阵列的瓶颈往往不在盘

全闪阵列的硬件IOPS能力非常强，单块NVMe盘动辄几十万IOPS。但实际业务中很少有人能把全闪的盘性能完全发挥出来，因为瓶颈往往出在控制器、缓存、光纤链路这些环节。所以性能监控的重点要放在数据路径上。

# 查看整体性能 show performance # 按卷查看性能 show performance volume # 查看控制器CPU和缓存使用率 show controller performance

show performance输出系统的整体IOPS、带宽、时延，这是最顶层的性能视图。如果整体时延异常，再通过show performance volume下钻到具体卷，看看是哪个业务“拖后腿”。show controller performance则关注控制器的CPU使用率、缓存命中率、写入缓存水位。

实际排障经验：全闪阵列出现“存储慢”的反馈，先查控制器CPU是否打满，再查光纤链路的协商速率，最后才怀疑磁盘本身。因为全闪磁盘的性能余量太大，盘本身成为瓶颈的概率其实很低。很多时候是控制器忙不过来，或者主机侧链路被限速。

3.6 日志导出和版本信息：排查前先留证据

处理存储故障有个原则：先留证后动手。因为一旦执行了切换、重启、拔盘这类操作，故障现场就被破坏了，事后想复盘只能靠日志。

# 查看固件版本 show version # 查看授权状态 show license # 导出日志 show log export

show version务必牢记，同一个问题在不同版本上的处理方式可能完全不同，向原厂报障时对方第一句话大概率就是问版本号。show license则确认功能授权是否正常，有些高级功能（比如远程复制、快照）如果授权到期，会导致对应功能异常。排查前把这几个信息记录下来，是对自己也是对原厂工程师负责。

4. 从命令集到巡检脚本：半小时巡检压缩到三分钟

4.1 脚本设计三原则

命令集整理出来之后，下一步一定是脚本化。手敲命令适合临时排障，日常巡检必须自动化。我在设计存储巡检脚本时始终坚持三个原则。

第一是只读原则。巡检脚本只能使用show类只读命令，绝不能包含任何配置类操作。这样即使脚本因为逻辑BUG误执行，最坏情况也只是多采集了一些数据，不会影响生产。

第二是带时间戳原则。每次巡检输出都保存到以日期命名的文件里，比如20250609_3par_health.log。没有时间戳的输出不具备历史对比价值，存了跟没存一样。

第三是可对比原则。巡检不是看单次输出，而是对比相邻两次输出的变化。容量下降了5%、告警新增了两条、控制器CPU使用率上涨了10%，这些变化才是巡检真正要捕捉的信息。

4.2 3PAR巡检脚本：用expect做SSH交互

3PAR的CLI是交互式会话，直接用bash的ssh命令不方便采集输出，我用expect来做自动交互。下面这个脚本覆盖了3PAR日常巡检的核心命令。

#!/bin/bash # 3PAR日常巡检脚本 IP="10.0.0.10" USER="monitor_c" PASS="yourpass" DATE=$(date +%Y%m%d) OUTDIR="/var/log/storage-monitor/3par" mkdir -p $OUTDIR expect << EOF set timeout 30 spawn ssh $USER@$IP expect { "password:" { send "$PASS\r" } "yes/no" { send "yes\r"; exp_continue } } expect "cli>" send "showalert -f new\r" expect "cli>" send "showpd -s\r" expect "cli>" send "showvv -sp\r" expect "cli>" send "showport\r" expect "cli>" send "exit\r" expect eof EOF

注意脚本里的password是明文存储的。在测试环境可以这么用，生产环境建议改用SSH密钥认证，或者从加密的凭据文件里动态读取。另外expect脚本里的cli>提示符要和实际登录后的提示符完全一致，否则expect会在错误的位置继续执行。登录一次确认提示符格式，再写进脚本。

这个脚本执行完，整个expect << EOF块内的输出都会打到标准输出。实际使用时可以整体重定向到日志文件，同时加上时间戳：

./3par_monitor.sh > ${OUTDIR}/${DATE}_3par.log 2>&1

4.3 CF22030巡检脚本：用paramiko解决SSH难题

H3C CF22030的CLI虽然也走SSH，但交互方式和3PAR不完全一样。为了省去麻烦的expect状态机，我用Python的paramiko库来执行命令，代码更可读，后期加命令也方便。

import paramiko import datetime host = "10.0.0.20" user = "monitor" pwd = "yourpass" cmds = [ "show system status", "show alarm", "show disk", "show disk -s", "show pool", "show volume", "show performance", ] client = paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, username=user, password=pwd) output_lines = [] for cmd in cmds: stdin, stdout, stderr = client.exec_command(cmd) output_lines.append(f"### {cmd}") output_lines.append(stdout.read().decode()) client.close() date_str = datetime.date.today().strftime("%Y%m%d") with open(f"/var/log/storage-monitor/cf22030/{date_str}_cf22030.log", "w") as f: f.write("\n".join(output_lines))

这段脚本核心逻辑不复杂：连上设备，依次执行命令，把输出写入带日期的日志文件。paramiko的exec_command对每个命令都是独立执行，不需要维护交互状态，比expect更省心。

4.4 告警推送：把关键输出扔给值班群

光有巡检日志还不够，真出了事不能等着人去看日志。我做的第三层是把巡检输出里的关键告警自动推到值班群，用的是企业微信和钉钉都支持的Webhook方式。

思路很简单：在巡检脚本里加一段解析逻辑，如果输出里出现了Critical、Fatal、failed这类关键词，就触发Webhook推送。

if grep -qiE "Critical|Fatal|failed|degraded" ${DATE}_3par.log; then curl -s 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=your-key' \ -H 'Content-Type: application/json' \ -d '{"msgtype":"text","text":{"content":"3PAR巡检发现异常，请登录存储查看日志"}}' fi

这种方式能保证“巡检到问题后第一时间有人知道”，即使凌晨三点也没问题。当然推送只能作为通知手段，真正排查还是需要登录设备看详细输出，所以推送消息里最好附上日志文件名，方便值班人员快速定位。

4.5 监控账号的授权建议

自动化巡检的前提是专用监控账号。3PAR那边创建只读用户，CF22030那边同样创建只读用户。存储设备的账号权限体系大多能做到命令级授权，巡检脚本用到的每一条命令都可以单独授权，这是最稳妥的方式。

带外管理HDM账号和存储CLI账号是分开的，两边都要配置监控账号。巡检脚本只走CLI通道，HDM账号单独用于硬件状态检查。两个通道的账号权限都遵循最小化原则，不授权任何写操作。

5. 真实遇到过的坑：巡检命令是这样救命的

5.1 degraded不一定就是盘坏了，先确认再动手

有一次巡检3PAR，showpd输出里有一块盘的State是degraded。按照常规思路，degraded就是要换盘的前兆，我当时连备件都准备下单了。后来多敲了一条showpd -i才发现，这块盘不是坏了，而是前一天加盘后系统正在做数据重构，chunklet正在往新盘里搬数据，所以状态显示降级。这个状态下如果贸然拔盘，反而会打断重构流程，给系统造成额外的数据风险。

从那以后我养成了一个习惯：看到degraded先查原因，确认是坏道、数据重构还是其他逻辑操作引起的，再决定要不要进入换盘流程。showalert里对应告警的详细描述，showpd -i里的初始化状态，结合起来看基本能判断出来。

5.2 showpd -s显示的是裸容量，汇报前先换算

做容量汇报时最容易踩的坑是把裸容量当可用容量。showpd -s输出的总容量是把所有物理磁盘容量加起来的裸容量，它没有扣除RAID校验开销、热备盘、快照预留、内部元数据占用。所以看到“系统还剩50%空间”很可能只是裸容量维度，真正业务可用的空间要小得多。

正确做法是看showspace输出里的可用容量，或者showpool/showvvspace里汇总之后的值。给领导汇报容量之前，先确认自己看的是物理层还是逻辑层的数据，口径不一样结果差很多。CF22030那边同理，show disk加总是裸容量，show pool才是业务视角的容量。

5.3 全闪存储的寿命数据，比状态字段更值得盯

CF22030是SSD全闪，我踩过最深的坑就是只盯着磁盘状态字段看，忽略了寿命数据。SSD和机械盘不一样，它在生命周期内状态很长一段时间都是online，看起来一切正常，但实际上磨损已经悄悄推进。等状态从online变成failed的时候，往往是寿命耗尽的瞬间，留给你的反应时间非常短。

现在我做全闪存储巡检，show disk -s里的SMART寿命数据是我重点关注的对象。磨损度超过70%就列入备件计划，超过50%的话月度巡检变成每周巡检。这个经验同样适用于所有SSD阵列，不管是H3C还是其他品牌的闪存存储。

5.4 巡检节奏：日常、每周、每月各看什么

顺手整理一个巡检频率表，供参考。实际操作中可以根据设备重要程度和业务敏感度调整节奏。

巡检不是“看一遍”就结束，关键是历史对比。所有输出保存成文件后，每周挑一天做一次对比分析，看容量曲线、告警数量、磁盘状态变化。这种趋势分析才是巡检真正的价值所在，也是从“被动救火”走向“主动运维”的分水岭。

存储这行干久了，最大的体会是真正的高手不是会救火，而是能在故障发生前把苗头按下去。这套命令集整理出来，就是希望后来的人能站在这些经验上少走弯路。命令本身都不难，难的是知道什么时候该看哪条命令、输出里的哪个字段才是关键。希望大家拿着这套命令集，把存储巡检这件事从烦心事变成肌肉记忆。