用了快十年的MegaCLI突然有一天发现新到的服务器怎么都不识别RAID卡了命令敲下去直接给我报command not found。去官网一查才发现人家早就把管理工具换成了StorCLIMegaCLI停留在老版本不再更新新卡的固件和它根本不兼容。我当时心里是真的窝火意味着之前的脚本全要改还担心又要踩一堆文档不全的坑。但用了一段时间之后我反而觉得这次换工具不算坏事。StorCLI在命令结构、输出清晰度、功能完整性上都比MegaCLI强了不少操作手感完全不一样。这篇文章就是我在这段时间里从零摸索StorCLI的完整记录。它是什么、怎么装、日常怎么用、出问题时怎么救把我踩过的坑和现在常用的命令全部整理出来。如果你正在接手一批用LSI/Broadcom/Avago阵列卡现在叫Broadcom的服务器或者还在纠结要不要从MegaCLI迁移过来那这篇文章应该能帮你少走不少弯路。1. StorCLI到底是什么为什么它值得你换掉MegaCLI1.1 先搞明白StorCLI在存储管理生态里的位置StorCLI的全称是LSI Storage Command Line Interface是LSI公司后来被Avago收购再后来整个存储业务并入Broadcom推出的RAID管理命令行工具。它和MegaCLI的定位一样都是用来管理LSI/Broadcom家族的RAID控制器包括我们最常见的SAS 2008/3008系列、以及后来的SAS 3108/3408/3508系列等。它做的事情是通过命令行去操作RAID控制器包括查看控制器信息、创建删除RAID阵列、管理热备盘、处理硬盘故障、查看日志等。一句话概括StorCLI就是在Linux/Windows环境里用shell命令去控制RAID卡的那把螺丝刀。有人可能会问现在很多服务器都有图形化界面比如戴尔的iDRAC、惠普的iLO直接网页上也能配RAID为什么还要用命令行工具道理很简单图形化界面只在单机维护的时候方便当你手里有几十台甚至上百台服务器每一台都要配置RAID、批处理检查硬盘健康状态你就知道命令行批量操作有多香了。脚本一写SSH全部机器循环执行结果一汇总半小时能干完图形界面一整天的工作量。1.2 为什么MegaCLI该退休了StorCLI强在哪里MegaCLI的问题不只是“不再更新”这么简单。新出的RAID卡在固件层面改动了很多命令接口老工具根本识别不了。而且MegaCLI的输出格式是那种对机器不友好的纯文本表格想在脚本里做状态判断还得用grep、awk各种加工。StorCLI针对这些痛点做了很多改进具体来说输出格式更规整。StorCLI默认支持标准输出和JSON两种格式特别是加J参数之后输出的JSON结构写脚本的时候直接解析不用再去抠字符串。命令结构更统一。MegaCLI时代有-LDInfo、-AdpAllInfo、-PDList这些互不相同的参数格式每次都要翻文档。StorCLI统一成/call/eall/sall这种面向对象的路径式结构记忆成本低很多。新增了更多细粒度操作。比如可以直接查看某个硬盘的S.M.A.R.T.信息、查看缓存策略、调整回写/直写模式这些在MegaCLI里要折腾半天StorCLI一条命令就能搞定。对新硬件的支持更完整。NVMe硬盘做RAID、混合阵列、以及最新的Broadcom 95xx系列控制器StorCLI都是兼容的。用Shell写自动化脚本处理几十台机器StorCLI绝对是当前最合适的工具。如果你还在老服务器上跑MegaCLI我的建议是尽早迁移迟早要面对换工具这一天早换早省心。1.3 StorCLI能做什么看完这张功能清单你就心里有数了很多人对StorCLI的印象停留在“查查RAID状态”实际上它能做的事情远超你的预期。用我自己实际验证过的经验把它的核心能力整理如下功能模块具体能力典型使用场景控制器信息查询型号、固件版本、序列号、PCIE速率、缓存大小批量盘点服务器配置RAID阵列管理创建/删除/初始化/扩容阵列、切换RAID级别新机器初始化、阵列扩容物理硬盘管理查看硬盘状态、定位硬盘位置、下线/上线硬盘硬盘故障定位、更换硬盘热备盘管理添加/删除全局热备盘、专用热备盘保障阵列冗余能力缓存策略配置切换回写/直写、开启/关闭BBU保护优化读写性能日志与事件管理控制器事件日志、开机自检日志故障排查、定位异常状态监控重建进度、巡检状态、S.M.A.R.T.信息日常巡检、故障预警安全擦除物理硬盘数据擦除退役硬盘处理这里面每一项都有非常具体的命令结构后面的章节我会逐个拆开讲配上实际执行输出让你拿去就能用。2. StorCLI安装与基础环境配置五分钟搞定2.1 Linux下安装StorCLI的完整过程StorCLI的安装包可以从Broadcom官网下载这里提个醒官网的下载入口藏得很深搜索的时候直接搜“Broadcom StorCLI download”比在官网一层层点菜单要快得多。下载下来一般是一个zip包解压后里面有各种操作系统对应的安装文件。以最常见的CentOS/RHEL 7/8系统为例安装包通常是storcli-xxx-1.xx-xx.x86_64.rpm或者一个独立的二进制文件。整个安装过程非常简单# 解压下载的zip包 unzip storcli-7.xx_x64.zip # 进入对应目录安装rpm包 cd storcli-7.xx_x64/Linux rpm -ivh storcli-7.xx-1.noarch.rpm如果你用的系统不支持rpm也可以直接使用解压出来的独立二进制文件。装完之后命令默认在/opt/MegaRAID/storcli/目录下。为了使用方便建议大家把路径加到环境变量里echo export PATH$PATH:/opt/MegaRAID/storcli ~/.bashrc source ~/.bashrcUbuntu/Debian系统则是用dpkg安装过程几乎一样。Windows Server下安装更简单双击安装包按向导走就行装完后到安装目录下执行storcli.exe即可。注意有些新版本的StorCLI安装包解压后命令名变成了storcli64。如果敲storcli提示command not found看看安装目录下有没有storcli64这个文件。2.2 让StorCLI用起来更顺手的三个基础配置安装完成后有三件事我建议你马上做它们会在后续使用中帮你省下大量时间。第一件事给StorCLI添加软链接。因为安装包自带的命令路径比较深而且版本不同路径可能不同直接做一个软链接到/usr/local/bin下一劳永逸ln -s /opt/MegaRAID/storcli/storcli64 /usr/local/bin/storcli第二件事验证一下StorCLI能不能正常识别你的RAID卡。执行storcli show如果能正常列出控制器信息就说明工具和硬件之间通信正常。第三件事设置日志输出目录。StorCLI在执行某些操作时会生成日志文件默认日志目录在/var/log下如果你希望日志集中收集可以在执行命令时加-o参数导出到指定目录。比如storcli show -o /data/raid_logs/controller_info.txt这个-o参数在自动化脚本里非常好用每次巡检把结果导出到文件方便后续统一处理。实操心得我把storcli show的结果重定向到文件之后还会顺便加一个时间戳文件名。比如storcli show -o /data/raid_logs/ctrl_$(date %Y%m%d).txt这样每天的巡检结果自动归档出问题的时候回溯特别方便。2.3 适配内核版本异常时的处理经验Linux服务器内核更新太频繁会遇到StorCLI内核模块和当前内核版本不匹配的情况。具体表现是执行storcli show直接报类似Failed to initialize the controller或IOCTL call failed的错误。遇到这种情况第一反应不要急着重装StorCLI先查一下你当前内核版本和StorCLI的兼容性。Broadcom每次发布新版本StorCLI的时候他的Release Notes里都会列出支持的内核范围。核对之后一般有两种解法场景一StorCLI版本太老不支持新内核。这种情况去官网下载最新版安装覆盖。场景二内核太新最新版StorCLI也没覆盖。这种情况可以临时退回旧内核启动或者等Broadcom更新。我自己遇到过几次都是场景一升级StorCLI之后问题就消失了。另外多说一句排查这类问题的时候记得先看系统日志dmesg | tail -100 journalctl -u storcli --since 5 minutes ago这些日志信息在官方文档里可能找不到现成的答案但往往是解决问题的关键线索。3. StorCLI的核心查询命令日常巡检就靠它们3.1 控制器信息查询快速摸清这台服务器的家底拿到一台新服务器第一件事一定是看这台机器配的什么阵列卡、固件版本多少、支持哪些功能。StorCLI查看控制器信息的方式如下# 查看控制器概要信息 storcli show # 查看第一个控制器的详细信息 storcli /c0 show all执行storcli show你会看到类似下面的输出Status Code 0 Status Success Description None Number of Controllers 1 Host Name localhost Operating System Linux 4.18.0-193.el8.x86_64 System Config Serial Number ABC123456 Serial Number XYZ789 Controller 0 Status OK Product Name AVAGO MegaRAID SAS 9361-8i SerNum 1234567890 Firmware Package Build 25.5.1.0001这些信息对日常运维很重要。比如Product Name直接告诉你阵列卡型号Firmware Package Build是固件版本后面查兼容性问题时必须用到。查看控制器全部支持的功能用storcli /c0 show all输出会非常长包含阵列卡支持的RAID级别、最大硬盘数量、缓存大小、BBU状态、以及各种策略开关等。想看精简版加个| grep过滤就行storcli /c0 show all | grep -E Firmware|Model|Serial|RAID Level Supported|Cache注意在写自动化脚本时不要用show all的完整输出去做grep匹配不同版本StorCLI输出的文本格式略有差异。更稳定的做法是使用storcli /c0 show all J输出JSON格式然后用jq工具解析关键字段。3.2 物理硬盘状态查询一看就懂的硬盘健康体检硬盘是服务器里最容易坏的硬件没有之一。所以定期查看物理硬盘状态是所有巡检工作的重中之重。StorCLI查询物理硬盘的命令如下# 查看第一个控制器下的所有物理硬盘 storcli /c0 /eall /sall show # 查看某个硬盘位的详细信息 storcli /c0 /e32 /s3 show all执行后会看到类似输出EID:Slt | State | DG | Size | Intf | Med | SED | PI | SeSz | Model ---------------------------------------------------------------------------------- 32:0 | Onln | 0 | 1.818TB | SAS | HDD | N | N | 512B | HGST HUC101818 32:1 | Onln | 0 | 1.818TB | SAS | HDD | N | N | 512B | HGST HUC101818 32:2 | UGood | - | 1.818TB | SAS | HDD | N | N | 512B | HGST HUC101818 32:3 | Rbld | 0 | 1.818TB | SAS | HDD | N | N | 512B | HGST HUC101818这里我重点讲几个状态字段的含义Onln硬盘在线且已加入某个RAID阵列DG列显示阵列编号。UGood硬盘在线但是未使用没有加入任何阵列可以理解为空闲盘。Rbld硬盘正在重建通常是热备盘顶替故障盘。Offln硬盘离线可能故障或者被手动下线。DHS硬盘被配置为专用热备盘。GHS硬盘被配置为全局热备盘。这几个状态是日常判断硬盘健康的核心指标。比如你看到某块盘的状态是Offln那基本可以判断这块盘出问题了需要尽快处理。3.3 RAID阵列状态查询判断阵列是否健康的关键指标查看逻辑驱动器也就是RAID阵列状态的方法# 查看所有阵列概要 storcli /c0 /v all show # 查看某个阵列的详细信息 storcli /c0 /v0 show all执行后能看到类似输出DG | Arr | Row | Size | RAID | Gd State | PD State | Cache ------------------------------------------------------- 0 | 0 | 0 | 1.818TB | RAID6 | OPTL | Onln | RWBD这里重点看Gd State和PD State两个字段。Gd State是阵列的总体状态OPTL表示最佳状态。如果看到DGDdegraded降级状态说明你的阵列里有硬盘掉了数据仍可用但已经失去冗余保护了。另外Cache字段显示的是当前缓存策略RWBD表示读写缓存均开启并且启用了BBU备份保护。这是推荐的状态既能保证性能又能防止意外断电丢数据。阵列重建状态是运维人员最关心的指标之一查看方式storcli /c0 /v0 show rebuild输出类似Rebuild Progress : 45%我在实际运维中用这个命令去做定时巡检写了一个简单的while循环每小时检查一次重建进度一旦发现重建卡住不动超过三小时立刻短信告警。这在重建需要十几个小时的大容量阵列场景下特别实用能提前发现重建异常。4. StorCLI阵列配置实操从零开始创建你的RAID4.1 创建RAID阵列的完整命令与参数详解StorCLI创建阵列的命令格式如下storcli /c0 add vd typeraid6 sizeall nameDATA drives32:0-7这条命令的意思是在控制器0上新建一个RAID6阵列使用全部容量名字叫DATA使用插槽32:0到32:7共8块硬盘。我再展开讲几个常用参数这些参数在实际配置中很容易踩坑type指定RAID级别常见的有raid0、raid1、raid5、raid6、raid10。size指定阵列容量大小。可以写具体容量如size5TB也可以写sizeall表示使用所有可用空间。drives指定要使用的硬盘格式是控制器:插槽的组合多个硬盘用逗号或短横线分隔。name给阵列起一个名字方便管理。wt/wb分别表示直写模式Write Through和回写模式Write Back。nora/ra分别表示关闭/开启读预取Read Ahead。direct/cached分别表示直通IO和缓存IO模式。如果你想把所有可用硬盘都用来创建阵列可以简写成storcli /c0 add vd typeraid6 sizeall drives32:0-7,32:9-15实操心得批量创建多台服务器的阵列时我强烈建议先在一台机器上把阵列创建命令验证好再通过脚本批量下发。另一件特别重要的事是新阵列创建完成后初始化操作不要急着一键执行先确认硬盘数据不需要备份了再清。4.2 阵列扩容与在线扩容的注意事项业务增长之后原阵列容量不够用了这时候有两种扩容方式加硬盘扩阵列或者换更大的硬盘逐块替换。加硬盘扩容的命令格式# 查看当前阵列状态 storcli /c0 /v0 show all # 将新硬盘加入指定的阵列 storcli /c0 /v0 add drives32:8-9执行这个操作的前提是阵列类型支持在线扩容。RAID5/RAID6这类条带化阵列支持加盘扩容RAID1这种镜像阵列不支持加盘扩容只能通过换大容量硬盘再重组来实现。还有一点必须提醒扩容操作只能在阵列状态为Optimal最佳的时候执行。如果你的阵列已经处于Degraded状态先处理故障硬盘阵列状态恢复后才能扩容。另一种扩容方式逐块替换硬盘。做法是先把一块故障/小容量硬盘从阵列中踢出插入更大容量的新硬盘等阵列重建完成后再替换下一块直到所有硬盘都被替换成大容量盘最后执行容量扩展命令。这个过程非常漫长但不需要停机适合对可用性要求极高的业务。替换硬盘并启动重建的命令# 将物理硬盘设置为离线状态 storcli /c0 /e32 /s3 set offline # 拔出坏盘后插入新盘系统自动开始重建 # 手动触发重建 storcli /c0 /e32 /s3 start rebuild4.3 热备盘配置给你的数据上双保险热备盘Hot Spare是阵列冗余之外的第二道防线。当阵列中某块盘故障时热备盘会自动顶替上去触发重建最大限度缩短业务降级运行的时间窗口。配置全局热备盘的命令# 将插槽32:8的硬盘设为全局热备盘 storcli /c0 /e32 /s8 add hotspare # 将插槽32:8的硬盘设为指定阵列的专用热备盘 storcli /c0 /e32 /s8 add hotspare dgs0删除热备盘也很简单storcli /c0 /e32 /s8 delete hotspare我个人的建议是凡是配置了RAID5/RAID6的服务器只要还有空闲硬盘位至少配一块热备盘。原因很简单RAID5在阵列处于降级状态时如果同时还有另一块盘有坏道读取时就会发生不可修复的UECC错误可能导致整个阵列数据不可读。有热备盘在故障盘一旦被识别重建马上开始就算第二块盘在重建过程中出现问题也有更大的概率保住数据。4.4 缓存策略调整性能和安全怎么平衡StorCLI调整缓存策略非常方便。日常业务场景下我特别推荐使用WriteBack ReadAhead Direct的组合即wb、ra、direct。如果你的RAID卡有BBU电池备份单元或者超级电容这个组合在性能和安全性之间平衡得最好。# 设置阵列0的缓存策略为 回写读预取直通IO storcli /c0 /v0 set wb ra direct如果你的ROI卡没有BBU保护或者BBU状态异常建议先切回直写模式storcli /c0 /v0 set wt ra direct注意回写模式下数据先写入阵列卡的缓存再异步刷入硬盘。没有BBU保护的情况下一旦突然断电缓存中未刷入硬盘的数据就会全部丢失。所以BBU健康状态异常的服务器千万不要开回写模式这是我的血泪教训。5. StorCLI日志分析与故障排查实战5.1 如何从StorCLI日志里找到故障线索阵列卡的所有关键事件包括硬盘插拔、错误校验、配置变更都会被记录在控制器的事件日志里。查看方法# 查看最近的事件日志 storcli /c0 show events # 查看事件日志并显示详细信息 storcli /c0 show events file/tmp/raid_events.txt事件日志的输出通常是纯文本里面记录了硬件错误、重建完成、阵列状态变化等。实际排查中我一般先把事件导出到文件然后用grep过滤关键错误关键词storcli /c0 show events file/tmp/raid_events.txt grep -iE fail|error|rebuild|degrad|offline|bad /tmp/raid_events.txt有一次排查一个数据库服务器间歇性卡顿的问题第一次检查时阵列状态是正常的状态码也都是Success。但是事件日志里看到有一条记录说某个物理硬盘在30秒内出现了大量介质错误。后来把那块硬盘替换掉卡顿问题就消失了。这就说明日常巡检不仅看状态还要养成看事件日志的习惯。5.2 硬盘故障定位快速找出坏盘在哪个位置StorCLI最有价值的技能之一就是快速定位故障硬盘的物理位置尤其是服务器机柜里硬盘插满了的时候。查看物理硬盘位置信息# 查看控制器下的物理硬盘拓扑 storcli /c0 /eall /sall show location输出会给出类似Slot 3这样的插槽信息。如果你要更直观地找到这块盘的位置可以让阵列卡上的硬盘LED灯闪烁# 使插槽32:3的硬盘LED常亮 storcli /c0 /e32 /s3 start locate # 取消定位 storcli /c0 /e32 /s3 stop locate这个操作在物理更换硬盘时极其方便。你只需要在远处SSH执行命令走到机柜前面看哪个硬盘位在闪灯直接拔出来换掉不用盯着序列号逐个核对。特别是在几十个硬盘的机柜里这个方法能帮你省下大量时间。5.3 阵列降级状态的完整处理流程阵列进入Degraded状态是运维人员最紧张的时刻。不要慌按照下面这个流程处理能把风险降到最低第一步确认故障盘。执行以下命令找出状态为Offln、Failed、或者状态异常的硬盘storcli /c0 /eall /sall show | grep -iE offln|fail|ugood第二步备份重要数据。如果这台服务器上跑的是核心业务在阵列仍是降级状态时尽量先做一次数据备份因为此时阵列已经没有任何冗余能力了。第三步物理替换故障盘。确认故障盘位置后执行start locate让LED闪烁然后物理拔出故障盘换上新盘。如果配置了热备盘系统会自动开始重建如果没有新盘插入后需要手动触发重建。第四步确认重建进度。执行storcli /c0 /v0 show rebuild等待重建完成。这个过程根据阵列容量和硬盘速度可能持续几小时到十几个小时不等。第五步验证阵列状态。重建完成后再次检查阵列状态storcli /c0 /v0 show看到Gd State为OPTL说明阵列已经恢复正常。5.4 常见错误信息与应对方案速查表使用StorCLI的过程中你一定会遇到各种错误提示。我把最常见的几类错误和应对方案整理成了表格方便遇到问题的时候快速定位错误信息含义应对方案Status Failure命令执行失败查看Description字段的具体描述通常包含详细原因Controller ID not found控制器编号错误用storcli show确认控制器编号Could not create VD创建阵列失败检查硬盘是否被占用、容量是否足够、是否超过阵列卡VD数量上限Disk is not a valid target硬盘参数错误确认EID:Slt组合是否正确用storcli /c0 /eall /sall show确认Failed to initialize the controller工具无法访问控制器检查内核模块是否加载、当前用户是否有权限、是否新内核不兼容Rebuild already in progress已有重建任务在执行用storcli /c0 /v0 show rebuild查看现有重建进度这里面最让人迷惑的是第一条Status Failure因为不带其他提示信息。我的建议是查看Description字段比如Description Failed to create virtual drive这类然后再去排查具体问题。6. StorCLI自动化运维实战把日常巡检交给脚本6.1 一键巡检每天自动收集阵列状态并生成报告手动巡检少量服务器没问题但规模一上来必须靠脚本自动化。我这里分享一个我常用的巡检脚本思路用bash就能实现。核心逻辑很简单遍历所有控制器收集控制器信息、阵列信息、物理硬盘信息然后将结果导出到文件并发送给监控系统。#!/bin/bash # RAID巡检脚本输出结果到文件 DATE$(date %Y%m%d_%H%M%S) OUTPUT_DIR/data/raid_check OUTPUT_FILE${OUTPUT_DIR}/raid_${DATE}.txt # 确保输出目录存在 mkdir -p ${OUTPUT_DIR} # 收集控制器信息 echo Controller Info ${OUTPUT_FILE} storcli show ${OUTPUT_FILE} 21 # 收集所有阵列信息 echo Virtual Drive Status ${OUTPUT_FILE} storcli /c0 /v all show ${OUTPUT_FILE} 21 # 收集物理硬盘信息 echo Physical Drive Status ${OUTPUT_FILE} storcli /c0 /eall /sall show ${OUTPUT_FILE} 21 # 检查是否有错误状态并输出到单独的错误文件 ERROR_FILE${OUTPUT_DIR}/raid_error_${DATE}.txt grep -E DGD|Offln|Failed ${OUTPUT_FILE} ${ERROR_FILE} 21 if [ -s ${ERROR_FILE} ]; then echo Array degraded or disk offline detected! else echo All arrays healthy. fi # 清理7天前的旧巡检文件 find ${OUTPUT_DIR} -name raid_*.txt -mtime 7 -delete这个脚本配合crontab每天早上定时执行一次再把输出文件汇总到日志中心。一旦脚本检测到降级或离线状态直接触发告警运维人员的手机马上就能收到通知。6.2 使用StorCLI的JSON输出对接监控平台如果你的监控平台支持接收JSON格式的数据现在的Prometheus、Zabbix等基本都支持自定义脚本采集那StorCLI的JSON输出功能就非常有用了。查看JSON格式输出的命令storcli /c0 /v all show J输出的JSON结构类似这样{ Controllers: [ { Command Status: { Status: Success, Description: None }, Response Data: { Virtual Drives: [ { DG: 0, Arr: 0, Row: 0, Size: 1.818TB, RAID: RAID6, Gd State: Optl, PD State: Onln, Cache: RWBD } ] } } ] }配合jq命令可以非常方便地提取关键字段storcli /c0 /v all show J | jq .Controllers[0].Response Data.Virtual Drives[] | {DG, RAID, Size, Gd State, PD State}这样写脚本监控就完全不用依赖字符串匹配了。我的生产环境里就是通过这个方式把阵列状态推送到了监控系统实现了阵列状态的可视化和告警。6.3 常用命令速查让StorCLI成为你的肌肉记忆最后把我日常最常用的一批命令整理成速查表放在手边随时翻阅。这些命令都是经过生产环境验证的按需取用功能命令查看控制器列表storcli show查看控制器详细信息storcli /c0 show all查看所有阵列状态storcli /c0 /v all show查看指定阵列详情storcli /c0 /v0 show all查看所有物理硬盘storcli /c0 /eall /sall show创建RAID5阵列storcli /c0 add vd typeraid5 sizeall nameDATA drives32:0-3创建RAID10阵列storcli /c0 add vd typeraid10 sizeall nameDATA drives32:0-7添加热备盘storcli /c0 /e32 /s8 add hotspare删除热备盘storcli /c0 /e32 /s8 delete hotspare设置缓存策略storcli /c0 /v0 set wb ra direct查看重建进度storcli /c0 /v0 show rebuild触发硬盘重建storcli /c0 /e32 /s3 start rebuild定位硬盘位置storcli /c0 /e32 /s3 start locate停止定位硬盘storcli /c0 /e32 /s3 stop locate查看事件日志storcli /c0 show events安全擦除硬盘storcli /c0 /e32 /s3 secure erase7. 写在最后的几条实战心得上面把StorCLI从安装到高级用法都过了一遍最后再分享几点我自己在实际运维中获得的体会算是给这篇文章收个尾。第一点是关于心态的转变。我从MegaCLI迁移到StorCLI一开始也带着很大的抵触情绪觉得老工具用得好好的为什么要换。但真正用了StorCLI一段时间后我发现自己回不去了。JSON输出让脚本处理变得干净利落命令结构也比以前好记。技术迭代不可怕关键是尽早伸手试试新东西别拖到无法回避的时候才被动学习。第二点是关于自动化脚本的稳定性。StorCLI毕竟是命令行工具不同版本之间的输出格式会有微调。我的经验是关键监控脚本要固定一个StorCLI版本不要跟着最新版频繁升级。真要升级先在测试机上跑一遍完整的巡检脚本确认输出格式没有被破坏再推到生产环境。第三点是关于阵列数据的备份意识。StorCLI再强大也只是管理工具它不能让RAID变成免死金牌。RAID能抵御单块硬盘故障但抵御不了误删除、逻辑损坏、控制器烧毁、甚至整个服务器进水的灾难。不管你用StorCLI把阵列管理得多么井井有条独立的数据备份永远是最后那道底线。这条经验是我在经历过一次阵列卡故障、整机硬盘无法被识别差点以为全部数据要陪葬之后才真正刻进骨子里的。如果你正打算把StorCLI用在生产环境建议先找一台测试服务器把创建阵列、删除阵列、热备盘切换、硬盘故障模拟这些操作都完整演练一遍。等到真正出故障的那一天你就能从容不迫地应对了。