简介这份《华为服务器日常维护及故障处理文档》面向服务器运维工程师、机房管理员及IT支持人员聚焦华为服务器日常巡检、软件升级与故障处置等典型工作场景。压缩包内共1个PDF文件约2.35MB内容以操作规范、检查表和流程说明为主便于现场查阅与培训使用。文档按“日常维护”和“故障处理”两大板块展开维护准备列出浮动螺母安装条、防静电腕带、万用表等硬件工具以及Toolkit Tools、Umate Tools、InfoCollect等软件工具的用途并提示用户指南、维护指南、告警参考等必读资料巡检部分覆盖机房温湿度、供电、线缆布放和服务器指示灯、iBMC/MM健康状态检查。故障处理部分给出诊断流程、信息收集与定位方法并说明部件更换流程及注意事项。已有1359人学习适合需要建立标准化维护流程、快速排查硬件与告警问题的读者参考。1. 面板红灯常亮、管理页面却一条告警都没有这类故障最耗人机柜前面板 HEALTHY 灯红色常亮登录带外管理页面概览一片绿色一条告警都没有。重启后恢复正常两天后同一位置再次亮红中间换过电源模块问题照旧。做服务器日常维护的人对这一幕不会陌生真正的根因往往不是硬件坏了而是巡检漏项、日志没收全、升级前没核对版本这三件事叠在一起把原本能定位的线索拖成了玄学。故障处理里最贵的成本从来不是换件是方向错了还在往前走。这份维护与故障处理文档把维护准备、日常巡检、软件升级、诊断流程、信息收集、故障定位、部件更换串成一条完整处置链天天跟机柜打交道、要出巡检报告、被「换件就好、过几天又坏」折腾过的人读它比读零散教程值。2. 巡检做完没几天又出问题日常巡检的判定阈值和漏项清单复发性故障里真正坏在板卡上的比例并不高。更多情况是环境在某段时间越界设备自我保护降频、风扇拉满、硬盘离线等维护人员到场时一切又恢复正常什么痕迹都没留下。巡检表上环境项看着最没技术含量但它往往是唯一能在故障发生前留下证据的一栏。这一章先把「巡检该看什么、看到什么算异常、异常了记在哪」这三件事定下来再谈工具。2.1 环境项先看这三个数字温度、湿度、供电机房环境不是「不热就行」。设备厂商给的指标是有上下限的越界不一定立刻宕机但会以性能下降、风扇转速异常、硬盘掉线这类间接形式表现出来而且往往在越界结束后才发作。技术指标项参考范围越界后的典型表现工作温度10℃ 35℃风扇长期高转速、CPU 降频、部分机型触发过温告警存储温度-40℃ 65℃长期断电备机重新上电时启动异常温度变化率15℃/h结露风险板卡受潮后偶发告警工作湿度8% RH 90% RH无冷凝湿度过低易积累静电过高易凝露存储湿度5% RH 95% RH无冷凝备机受潮工作海拔高度≤ 3000m空气稀薄导致散热效率下降交流供电100V AC 240V AC50/60Hz电压偏低时电源模块反复重启直流供电标称 -48V DC波动 -38.4V -57.6V超出波动范围电源模块保护性关断三个最容易被忽略的点一是温度变化率很多机房空调白天夜间切换绝对温度没超标但一小时掉了十几度结露和热胀冷缩带来的接触不良就是这样来的二是湿度必须无冷凝表上一句括号注掉了最容易出事的前提三是直流供电的负电压波动范围用万用表量的时候要按 -48V 体系读别拿绝对值直接和 48 比。操作上我一般按固定顺序走一遍先用温湿度计在机柜进风口和出风口各读一次记录时刻再用万用表测 PDU 输出端电压和接地导通最后才去看设备本身。顺序不能反先看设备容易被「设备看起来正常」误导把环境项跳过去。注意接地检查和插拔线缆必须在客户授权后进行机房规范以现场实际规定为准不要拿自己熟悉的机房习惯套别人的场地。2.2 线缆与指示灯把「看起来正常」变成可判定线缆这一项光靠眼睛扫一遍基本等于没查。文档里给的检查项是有判定标准的照着对才不会漏检查内容判定标准线缆总布放强电、弱电分两侧走线业务线与电源线分离光纤不得小角度弯折或强行拉伸电源线布放整齐有序与机柜整体风格一致电源线禁止挽圈业务线布放同上避免与电源线捆扎在一起地线连接设备按规定接地接地标识处的线缆不得缺失线缆标签字体清晰、含义准确、粘贴牢固两端都要有电源线插头牢固插入插座无松动、无局部发黑信号线插头服务器与交换机之间的信号、数据线连接牢固指示灯是另一套语言型号之间有差异但判定逻辑是统一的绿色常亮或闪烁为正常黄色、不亮、红色常亮或红色闪烁都算异常。前面板要看 UID 按钮/指示灯、HEALTHY 健康指示灯、网口指示灯、电源开关按钮指示灯后面板看电源模块指示灯硬盘托架看硬盘状态灯。风扇不亮灯靠听平稳运行是正常很响或者有异响就要处理。肉眼看不出来的部分交给带外管理模块。下面这组命令是我每次现场巡检都会跑的输出直接落到文件里# 读取当前所有传感器读数含温度、电压、风扇转速用于和阈值比对 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sensor | tee sensor_$(date %F).txt # 只筛出严重/主要/次要级别的事件历史告警往往比当前读数更能说明问题 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sel elist \ | grep -Ei critical|major|minor | tee sel_$(date %F).txt-I lanplus指定走 IPMI 2.0 over LAN是带外最通用的接口方式-H后面跟管理网口地址不是业务地址-U/-P是带外账号建议用只读维护账号别用管理员sensor输出的是实时读数sel elist输出的是事件日志两者要对着看——当前读数正常但历史里有 critical说明问题已经发生过一次。密码不要硬编码进脚本也不要留在 shell history 里用环境变量或交互输入更稳妥。提示面板红灯但管理页面无告警先怀疑你看的是概览页而不是事件日志页。SEL 里的历史条目才是「黑匣子」概览页只反映当下。2.3 巡检留痕一次只改一个地方巡检真正的价值不在「查了」在「能对比」。文档里那几条基本原则翻译成人话就是给每台设备一个唯一标识主机序列号或单板序列号每次都记日志一次只做一个改动并记录结果用厂商提供的工具和资源清楚操作系统和应用软件的更新情况有可靠的备份计划现场留关键备件保存最新网络拓扑图。这几条单看都是老生常谈凑在一起才构成可回溯的处置链。巡检报告至少要有这些字段设备所在位置、主机/单板序列号、巡检人及联系方式、巡检时间、现场接口人、报修电话然后是逐项结果。巡检项固定为前面板健康指示灯、电源按钮/指示灯、硬盘指示灯、后面板电源模块指示灯、风扇运行状态、线缆连接状态、带外健康信息与告警日志、刀片机型的 MM 管理模块健康状态、其他部件。每一项只有「正常/不正常」两个选项不允许写「大概正常」。归档方式建议按「序列号 日期」建目录把带外传感器输出、SEL、巡检报告放一起# 每台设备每次巡检一个目录后续做基线对比时直接 diff BASE~/inspect/$(date %F) mkdir -p $BASE ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sel elist $BASE/sel.txt ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sensor $BASE/sensor.txt # 和上次的 SEL 比对新增条目就是这段时间发生的事 diff -u ~/inspect/2025-05-01/sel.txt $BASE/sel.txtdiff出来的新增行就是两次巡检之间真实发生过的变化。这套做法救过我很多次面板红灯复现、但当场一切正常的场景靠历史 SEL 和两次 sensor 的差值才能把「偶发」变成「有据可查」。至于改动务必定好边界——现场只做授权范围内的操作重启、下电、插拔线缆这类动作提前报备别在业务高峰期做「顺手试一下」。3. 巡检工具扫不到设备、BMC 连不上远程巡检的四段链路排查远程巡检省事翻车也集中。最常见的三种表现ping 得通但巡检工具一台都扫不出来扫描列表里只出来一台其余全失败工具连上了但日志收不上来。这三种现象对应的断点完全不在同一层混在一起排查只会越查越乱。正确的姿势是从网络层往上一段一段确认。3.1 先分清是网络不通还是端口不通巡检工具要工作前提是便携机/跳板机能 ping 通服务器的带外管理地址刀片机型则是 MM 管理模块的浮动 IP同时 IPMI、SNMP、SSH、VMM 这几个通信端口是通的。ping 不通是网络层问题ping 通但工具报连接失败基本是端口或协议没开。# 第一层网络可达性 ping -c 4 10.10.20.31 # 第二层端口可达性逐个确认别只看一个 nc -vz 10.10.20.31 623 # IPMI nc -vz 10.10.20.31 161 # SNMP nc -vz 10.10.20.31 22 # SSH / SFTP nc -vz 10.10.20.31 8208 # VMM 虚拟媒体nc -vz只做连接探测不发数据成功会打印 succeeded。如果 623 通、161 不通说明带外侧没启用 SNMP需要登录带外 Web 把协议和团体名配上如果四个端口全不通但 ping 正常优先怀疑中间有策略拦截或者管理网口和业务网口接反了。这套判断顺序的意义在于先证明链路再怀疑工具否则你会花半天时间重装一个根本没问题的巡检工具。端口默认值记牢改过端口的话要在工具参数里同步改端口项默认值用途IPMI Port623带外传感器、SEL、开关机控制SNMP Port161读取硬件健康状态非 V3 版本需填读写团体名SSH / SFTP Port22操作系统侧巡检与日志传输VMM Port8208虚拟媒体挂载另外两个前置条件经常被跳过一是操作系统侧也要能被 ping 通且 SSH、SFTP 端口连通二是要确认服务器型号或操作系统版本在工具的支持列表里环境不满足工具运行要求时报错信息往往指向「连接失败」实际是兼容性问题。3.2 Start IP / End IP 与凭据扫描只出一台的三个原因批量巡检的参数面板看着简单填错的方式却很多。参数的含义和规则如下参数含义填写规则Start IP搜索起始地址带外管理板 IP、操作系统 IP或刀片 MM 的浮动 IPEnd IP搜索结束地址单台设备时与 Start IP 相同Username带外/操作系统管理员账号批量场景下必须全部一致Password对应密码同上Write CommunitySNMP 读写团体名SNMP 非 V3 版本时必填Root Passwordroot 用户密码非 root 用户操作 Linux 时需要IPMI/SNMP/SSH/SFTP/VMM Port端口号默认 623/161/22/22/8208「只扫到一台」通常就是这三条踩中其中之一连续地址批量扫描时Start IP 和 End IP 的前两段必须一致且各设备用户名密码必须相同地址不连续、或者密码各自不同的只能按单台设备逐条处理单台设备时 End IP 忘了填成和 Start IP 一样扫描范围就变成了一个巨大的地址段。不确定地址段里到底有哪些设备活着先自己扫一遍再填参数比在工具里盲目试要快得多# 快速探活只输出存活地址用于核对 Start/End IP 范围 for i in $(seq 2 60); do ip10.10.20.$i ping -c 1 -W 1 $ip /dev/null 21 echo $ip alive doneseq 2 60对应地址段末位范围-W 1把单次等待压到 1 秒几十个地址十几秒就能跑完。跑出来的存活列表和工具扫描结果对比差在哪几台问题就锁定在那几台的账号或协议配置上而不是整个网段。3.3 日志收不上来先带外、再系统、最后工具日志收不上来最忌讳的动作是「先重启试试」。重启会把内存里的现场信息清干净等于亲手把黑匣子扔了。正确的收法是三层递进先拿带外事件日志再拿操作系统侧日志最后才用日志收集工具做整包。# 第一层带外事件日志硬件层面的证据重启也不会丢 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sel elist sel.txt # 第二层操作系统内核与硬件错误日志 dmesg -T dmesg.txt journalctl -k --no-pager kernel.txt # systemd 系 grep -iE error|fail|timeout /var/log/messages messages_err.txt cat /var/log/mcelog mcelog.txt 2/dev/null # 有 mcelog 服务时才有 # 第三层用收集工具做整包Windows/Linux 都支持产出物用于提交分析 # InfoCollect 按交互提示选择日志类型与输出路径即可第一层优先级最高因为 SEL 存在带外模块里掉电、重装系统都不影响第二层解决「硬件正常但业务报错」的场景dmesg -T带可读时间戳方便和业务侧故障时间对齐第三层是给后续分析用的完整包文件大、耗时长放在最后做。三层都拿到再动手处理比先处理再补日志靠谱得多。注意日志文件可能包含主机名、IP、账号等敏感信息外发前按现场规范脱敏别直接把原始包丢到公共位置。4. 固件升级失败、升级后起不来升级前的三件核对和失败后的回退升级是维护动作里风险最高的一类因为它同时动了三个东西固件、配置、业务窗口。翻车的形态也很固定——升级包和型号对不上导致校验失败升级中途网络断掉模块停在半完成状态升级完成但配置漂移业务侧表现异常。这三类问题的处理方式完全不同所以升级前必须先分清自己在升什么。4.1 版本核对从「系统信息-固件版本」读不猜文件名升级包的文件名不可信尤其是从不同渠道拿到的包命名习惯五花八门。判断当前版本的唯一可靠方式是登录带外 Web依次进入「系统信息 → 固件版本」查看命令行方式也能读适合批量核对。# 读取管理模块自身信息确认固件版本与设备型号 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** mc info # 读取 FRU 信息拿到产品型号与序列号用于和升级包的适配列表比对 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** fru printmc info输出的是管理模块的制造商、固件版本、IPMI 版本fru print输出的是整机产品型号和序列号。升级前把这两个输出存档升级后再读一次做对比是最省事的「升级成功与否」判据。要升的固件类型也要分清楚带外管理模块固件不同机型叫 iBMC、iMana 或 MM、BIOS、以及硬盘/网卡/RAID 控制卡固件后者由专用升级工具处理不要和主板固件混在一个窗口里做。# 升级前快照版本 FRU BIOS 配置三份都留 D~/fwpre/$(date %F_%H%M) mkdir -p $D ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** mc info $D/mcinfo.txt ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** fru print $D/fru.txt # BIOS 配置通过带外 Web 的导出功能拿到本地一并放进该目录命名里带时分是为了在连续升级多台设备时不覆盖。这个目录在回退阶段就是对照物升级后如果业务异常先 diff 版本和配置能立刻排除「升错了包」和「配置被重置」这两种最常见的原因。4.2 升级中断的三种典型场景网络断掉。带外升级走的是管理网从便携机或跳板机上传镜像。上传过程中链路抖动、笔记本休眠、无线切换都会让升级卡在半路。规避方式很朴素用有线、用稳定电源、升级期间不切窗口镜像提前放本地不跨网段拉。批量并发。批量工具支持多台同时升级但并发数不是越大越好。同一台交换机下十几台设备同时拉镜像带宽打满超时率立刻上升。我的做法是分批单批控制在个位数每批完成后确认状态再进下一批。升级期间断电或误操作。BIOS 升级需要重启生效重启窗口内下电、按电源键、拔线都会把设备留在不可预期状态。升级前把业务迁走、把窗口报备清楚是唯一可靠的办法没有技术手段能替代。# 升级后逐台确认能读通带外且版本号已变化 for ip in 10.10.20.31 10.10.20.32 10.10.20.33; do echo $ip timeout 10 ipmitool -I lanplus -H $ip -U maint -P ****** mc info \ | grep -Ei firmware revision || echo NO RESPONSE donetimeout 10防止单台无响应把整个循环卡死grep只留版本行便于横向对比。输出NO RESPONSE的那台就是升级后带外没起来的设备需要走现场恢复流程不能指望再升一次能修好。4.3 升级后业务异常回退与配置对比升级后业务异常先分清是固件问题还是配置问题。判据很简单版本号对不对、配置项有没有被重置。版本号对、配置被重置属于配置漂移恢复配置即可版本号不对或者设备行为明显异常才考虑回退。回退的前提是升级前留了旧版本包和配置导出文件。旧包不要从网上临时找升级前就放在同一个目录里命名带上版本号。虚拟媒体挂载在这种情况下很好用把旧包挂在虚拟光驱/软驱上通过带外完成本地化的降级不依赖操作系统是否还能起来。带外还能做上电、下电、重启设备 OS 起不来时这条路径是唯一入口。5. 避坑清单五条把「小问题」拖成「大故障」的记录前面几章讲的是该怎么做这一章讲的是实际做的时候会在哪里翻车。下面五条都是我在现场或远程支持里真实遇到过的每一条都按「现象 → 原因 → 解决」写能对上号就直接抄处置方式。5.1 五条高频踩坑记录第一条面板红灯带外页面显示一切正常。现象前面板 HEALTHY 灯红色常亮登录带外 Web 概览页全绿无任何告警条目。 原因只看概览页没看事件日志。概览反映当前瞬时状态瞬时恢复正常后历史告警仍然留在 SEL 里硬件层面的信息不会因为页面刷新而消失。 解决导 SEL 并按级别过滤重点看 critical/major 条目对应的时间和部件同时导一份传感器读数做趋势对比。概览页正常不等于没发生过故障。第二条换了硬盘重建没跑完就拔了另一块。现象RAID 降级告警刚消几小时后又报降级怀疑背板故障。 原因新盘插入后阵列重建需要时间重建期间再动一块盘阵列直接失去冗余此时报出来的告警指向的是结果不是原因。 解决换盘后确认重建完成再动下一块重建进度在 RAID 配置界面或带外日志里都能看到。多盘故障要一台一台处理别图快。第三条在生产机上做「顺手试一下」的重启。现象巡检时发现某个传感器读数偏高顺手重启验证业务中断。 原因巡检和变更没有边界。文档里那条「一次只做一个改动并记录结果」前提是改动本身经过授权巡检阶段只做只读操作。 解决只读巡检和变更操作分开执行重启、下电、插拔线缆一律走窗口和授权流程现场操作前和接口人确认。第四条徒手拔插内存之后偶发内存告警。现象扩容内存后系统偶发 ECC 告警重新插拔后依旧换槽位才消失。 原因未做防静电措施。插拔单板、手拿精密器件时的静电放电不一定当场致命但会在器件内部留下隐患表现为间歇性错误。 解决接触设备和器件前戴防静电腕带或防静电手套操作前先释放自身静电机房里那个静电敏感区标识不是装饰。插拔类操作永远在断电状态下做。第五条升级完发现 BIOS 配置全变了。现象固件升级成功重启后启动项顺序变化业务起不来。 原因升级前没导出 BIOS 配置升级过程中配置被重置为默认值没人发现差异在哪。 解决升级前导出配置存档升级后逐项比对再放业务带外 Web 的配置导出功能就够用导出物和固件包放同一个目录。5.2 部件更换流程断电、防静电、记录、复测部件更换是维护动作里最容易「做完就完事」的一环而它恰恰是最需要收尾的。流程上我按固定四步走不做删减。第一步确认故障部件。依据是带外 SEL 里的告警条目加上现场指示灯状态两者指向同一个部件才动手只凭一条告警就换件很容易换错。第二步断电与防静电。断电、拔电源线、等待放电戴防静电腕带或手套在静电敏感区操作时严格按标识要求来。带高温表面标识的部件要等降温后再接触带高压标识的区域没有可维护器件不要打开。第三步更换并记录。换下的部件记录序列号、故障现象、更换时间、操作人新部件同样记录序列号这是后续判断是否为同一批次问题的依据。备件现场留存故障时才能及时更换。第四步复测。上电后先看指示灯再读传感器和 SEL确认原告警不再复现、无新增告警最后才把业务放回去。# 更换后复测清空前的 SEL 存档再确认当前无严重告警 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sel elist sel_after_replace.txt # 只看传感器是否有越界项正常应无 critical 级别输出 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sensor \ | awk $0 ~ /cr|nc/ {print}第二条命令用awk过滤包含crcritical或ncnon-critical的行没有输出说明当前读数全部在阈值内。复测的价值在于把「换完了」变成「修好了」——这两件事在现场经常被混为一谈然后过几天同一个故障再来一次。提示更换记录和巡检记录放在同一个归档目录里故障复发时把两次记录摆在一起看能快速判断是同一个部件、同一批次还是同一类环境因素。6. 快速定位从一条告警收敛到具体部件的三个动作故障现场最慌的时刻不是发现问题是发现问题之后不知道从哪下手。我的习惯是无论什么现象先做三个动作把范围从「一台设备」收敛到「一个部件」再谈处理。第一个动作看灯。前面板 HEALTHY 灯、电源按钮指示灯、硬盘状态灯、后面板电源模块灯四个位置扫一遍十秒钟。绿灯常亮或闪烁正常红灯、黄灯、不亮都是异常。这一步能立刻把「整机问题」和「单部件问题」分开。第二个动作读事件日志而不是概览页。概览页给的是当下SEL 给的是过程。把 SEL 里近 24 小时的条目按级别过滤出来按时间排序第一条 critical 出现的时间点通常就是故障起点。传感器数据同步导一份和阈值表对一遍。第三个动作对照告警参考。每一条告警码在厂商的告警参考文档里都有对应的处理建议别凭经验猜。文档里明确写了某类告警是「请更换」还是「请观察」照着做比自己判断准。把三个动作的结果拼起来基本能得到一张对照表现象优先查什么依据面板红灯概览页正常SEL 历史条目瞬时恢复的故障只留在事件日志里概览页有告警指示灯正常告警码对应的部件与处理建议告警参考文档硬盘黄灯或不亮硬盘状态与阵列重建进度硬盘指示灯 RAID 配置界面风扇异响或很响风扇模块与进风口温度现场听感 传感器读数带外连不上业务正常管理网口链路、端口、协议配置ping 端口探测 带外协议开关业务异常硬件全绿操作系统侧日志与配置变更记录dmesg、系统日志、升级/变更记录电源模块指示灯不亮供电输入与电源线连接万用表测电压 插头检查再补一个容易被忽略的收敛技巧用序列号对齐所有材料。巡检报告、SEL 导出、更换记录、报修单全都用主机序列号或单板序列号做索引而不是用「三号机柜第二台」这种位置描述。位置会变序列号不会故障复盘时按序列号能把一台设备半年的历史一次拉出来。从那以后我每次进机房哪怕只是看一眼都会强制走一遍「灯 → SEL → 告警参考」这三步并且把输出落盘归档。这套动作花不了几分钟但它把「我觉得没问题」变成了「我有证据说明没问题」也让下一次同类故障有了可以对比的基线。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/27 2:13:13 · 阅读 1.2k 服务器巡检与故障处理：带外日志、固件升级与部件更换避坑
简介这份《华为服务器日常维护及故障处理文档》面向服务器运维工程师、机房管理员及IT支持人员聚焦华为服务器日常巡检、软件升级与故障处置等典型工作场景。压缩包内共1个PDF文件约2.35MB内容以操作规范、检查表和流程说明为主便于现场查阅与培训使用。文档按“日常维护”和“故障处理”两大板块展开维护准备列出浮动螺母安装条、防静电腕带、万用表等硬件工具以及Toolkit Tools、Umate Tools、InfoCollect等软件工具的用途并提示用户指南、维护指南、告警参考等必读资料巡检部分覆盖机房温湿度、供电、线缆布放和服务器指示灯、iBMC/MM健康状态检查。故障处理部分给出诊断流程、信息收集与定位方法并说明部件更换流程及注意事项。已有1359人学习适合需要建立标准化维护流程、快速排查硬件与告警问题的读者参考。1. 面板红灯常亮、管理页面却一条告警都没有这类故障最耗人机柜前面板 HEALTHY 灯红色常亮登录带外管理页面概览一片绿色一条告警都没有。重启后恢复正常两天后同一位置再次亮红中间换过电源模块问题照旧。做服务器日常维护的人对这一幕不会陌生真正的根因往往不是硬件坏了而是巡检漏项、日志没收全、升级前没核对版本这三件事叠在一起把原本能定位的线索拖成了玄学。故障处理里最贵的成本从来不是换件是方向错了还在往前走。这份维护与故障处理文档把维护准备、日常巡检、软件升级、诊断流程、信息收集、故障定位、部件更换串成一条完整处置链天天跟机柜打交道、要出巡检报告、被「换件就好、过几天又坏」折腾过的人读它比读零散教程值。2. 巡检做完没几天又出问题日常巡检的判定阈值和漏项清单复发性故障里真正坏在板卡上的比例并不高。更多情况是环境在某段时间越界设备自我保护降频、风扇拉满、硬盘离线等维护人员到场时一切又恢复正常什么痕迹都没留下。巡检表上环境项看着最没技术含量但它往往是唯一能在故障发生前留下证据的一栏。这一章先把「巡检该看什么、看到什么算异常、异常了记在哪」这三件事定下来再谈工具。2.1 环境项先看这三个数字温度、湿度、供电机房环境不是「不热就行」。设备厂商给的指标是有上下限的越界不一定立刻宕机但会以性能下降、风扇转速异常、硬盘掉线这类间接形式表现出来而且往往在越界结束后才发作。技术指标项参考范围越界后的典型表现工作温度10℃ 35℃风扇长期高转速、CPU 降频、部分机型触发过温告警存储温度-40℃ 65℃长期断电备机重新上电时启动异常温度变化率15℃/h结露风险板卡受潮后偶发告警工作湿度8% RH 90% RH无冷凝湿度过低易积累静电过高易凝露存储湿度5% RH 95% RH无冷凝备机受潮工作海拔高度≤ 3000m空气稀薄导致散热效率下降交流供电100V AC 240V AC50/60Hz电压偏低时电源模块反复重启直流供电标称 -48V DC波动 -38.4V -57.6V超出波动范围电源模块保护性关断三个最容易被忽略的点一是温度变化率很多机房空调白天夜间切换绝对温度没超标但一小时掉了十几度结露和热胀冷缩带来的接触不良就是这样来的二是湿度必须无冷凝表上一句括号注掉了最容易出事的前提三是直流供电的负电压波动范围用万用表量的时候要按 -48V 体系读别拿绝对值直接和 48 比。操作上我一般按固定顺序走一遍先用温湿度计在机柜进风口和出风口各读一次记录时刻再用万用表测 PDU 输出端电压和接地导通最后才去看设备本身。顺序不能反先看设备容易被「设备看起来正常」误导把环境项跳过去。注意接地检查和插拔线缆必须在客户授权后进行机房规范以现场实际规定为准不要拿自己熟悉的机房习惯套别人的场地。2.2 线缆与指示灯把「看起来正常」变成可判定线缆这一项光靠眼睛扫一遍基本等于没查。文档里给的检查项是有判定标准的照着对才不会漏检查内容判定标准线缆总布放强电、弱电分两侧走线业务线与电源线分离光纤不得小角度弯折或强行拉伸电源线布放整齐有序与机柜整体风格一致电源线禁止挽圈业务线布放同上避免与电源线捆扎在一起地线连接设备按规定接地接地标识处的线缆不得缺失线缆标签字体清晰、含义准确、粘贴牢固两端都要有电源线插头牢固插入插座无松动、无局部发黑信号线插头服务器与交换机之间的信号、数据线连接牢固指示灯是另一套语言型号之间有差异但判定逻辑是统一的绿色常亮或闪烁为正常黄色、不亮、红色常亮或红色闪烁都算异常。前面板要看 UID 按钮/指示灯、HEALTHY 健康指示灯、网口指示灯、电源开关按钮指示灯后面板看电源模块指示灯硬盘托架看硬盘状态灯。风扇不亮灯靠听平稳运行是正常很响或者有异响就要处理。肉眼看不出来的部分交给带外管理模块。下面这组命令是我每次现场巡检都会跑的输出直接落到文件里# 读取当前所有传感器读数含温度、电压、风扇转速用于和阈值比对 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sensor | tee sensor_$(date %F).txt # 只筛出严重/主要/次要级别的事件历史告警往往比当前读数更能说明问题 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sel elist \ | grep -Ei critical|major|minor | tee sel_$(date %F).txt-I lanplus指定走 IPMI 2.0 over LAN是带外最通用的接口方式-H后面跟管理网口地址不是业务地址-U/-P是带外账号建议用只读维护账号别用管理员sensor输出的是实时读数sel elist输出的是事件日志两者要对着看——当前读数正常但历史里有 critical说明问题已经发生过一次。密码不要硬编码进脚本也不要留在 shell history 里用环境变量或交互输入更稳妥。提示面板红灯但管理页面无告警先怀疑你看的是概览页而不是事件日志页。SEL 里的历史条目才是「黑匣子」概览页只反映当下。2.3 巡检留痕一次只改一个地方巡检真正的价值不在「查了」在「能对比」。文档里那几条基本原则翻译成人话就是给每台设备一个唯一标识主机序列号或单板序列号每次都记日志一次只做一个改动并记录结果用厂商提供的工具和资源清楚操作系统和应用软件的更新情况有可靠的备份计划现场留关键备件保存最新网络拓扑图。这几条单看都是老生常谈凑在一起才构成可回溯的处置链。巡检报告至少要有这些字段设备所在位置、主机/单板序列号、巡检人及联系方式、巡检时间、现场接口人、报修电话然后是逐项结果。巡检项固定为前面板健康指示灯、电源按钮/指示灯、硬盘指示灯、后面板电源模块指示灯、风扇运行状态、线缆连接状态、带外健康信息与告警日志、刀片机型的 MM 管理模块健康状态、其他部件。每一项只有「正常/不正常」两个选项不允许写「大概正常」。归档方式建议按「序列号 日期」建目录把带外传感器输出、SEL、巡检报告放一起# 每台设备每次巡检一个目录后续做基线对比时直接 diff BASE~/inspect/$(date %F) mkdir -p $BASE ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sel elist $BASE/sel.txt ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sensor $BASE/sensor.txt # 和上次的 SEL 比对新增条目就是这段时间发生的事 diff -u ~/inspect/2025-05-01/sel.txt $BASE/sel.txtdiff出来的新增行就是两次巡检之间真实发生过的变化。这套做法救过我很多次面板红灯复现、但当场一切正常的场景靠历史 SEL 和两次 sensor 的差值才能把「偶发」变成「有据可查」。至于改动务必定好边界——现场只做授权范围内的操作重启、下电、插拔线缆这类动作提前报备别在业务高峰期做「顺手试一下」。3. 巡检工具扫不到设备、BMC 连不上远程巡检的四段链路排查远程巡检省事翻车也集中。最常见的三种表现ping 得通但巡检工具一台都扫不出来扫描列表里只出来一台其余全失败工具连上了但日志收不上来。这三种现象对应的断点完全不在同一层混在一起排查只会越查越乱。正确的姿势是从网络层往上一段一段确认。3.1 先分清是网络不通还是端口不通巡检工具要工作前提是便携机/跳板机能 ping 通服务器的带外管理地址刀片机型则是 MM 管理模块的浮动 IP同时 IPMI、SNMP、SSH、VMM 这几个通信端口是通的。ping 不通是网络层问题ping 通但工具报连接失败基本是端口或协议没开。# 第一层网络可达性 ping -c 4 10.10.20.31 # 第二层端口可达性逐个确认别只看一个 nc -vz 10.10.20.31 623 # IPMI nc -vz 10.10.20.31 161 # SNMP nc -vz 10.10.20.31 22 # SSH / SFTP nc -vz 10.10.20.31 8208 # VMM 虚拟媒体nc -vz只做连接探测不发数据成功会打印 succeeded。如果 623 通、161 不通说明带外侧没启用 SNMP需要登录带外 Web 把协议和团体名配上如果四个端口全不通但 ping 正常优先怀疑中间有策略拦截或者管理网口和业务网口接反了。这套判断顺序的意义在于先证明链路再怀疑工具否则你会花半天时间重装一个根本没问题的巡检工具。端口默认值记牢改过端口的话要在工具参数里同步改端口项默认值用途IPMI Port623带外传感器、SEL、开关机控制SNMP Port161读取硬件健康状态非 V3 版本需填读写团体名SSH / SFTP Port22操作系统侧巡检与日志传输VMM Port8208虚拟媒体挂载另外两个前置条件经常被跳过一是操作系统侧也要能被 ping 通且 SSH、SFTP 端口连通二是要确认服务器型号或操作系统版本在工具的支持列表里环境不满足工具运行要求时报错信息往往指向「连接失败」实际是兼容性问题。3.2 Start IP / End IP 与凭据扫描只出一台的三个原因批量巡检的参数面板看着简单填错的方式却很多。参数的含义和规则如下参数含义填写规则Start IP搜索起始地址带外管理板 IP、操作系统 IP或刀片 MM 的浮动 IPEnd IP搜索结束地址单台设备时与 Start IP 相同Username带外/操作系统管理员账号批量场景下必须全部一致Password对应密码同上Write CommunitySNMP 读写团体名SNMP 非 V3 版本时必填Root Passwordroot 用户密码非 root 用户操作 Linux 时需要IPMI/SNMP/SSH/SFTP/VMM Port端口号默认 623/161/22/22/8208「只扫到一台」通常就是这三条踩中其中之一连续地址批量扫描时Start IP 和 End IP 的前两段必须一致且各设备用户名密码必须相同地址不连续、或者密码各自不同的只能按单台设备逐条处理单台设备时 End IP 忘了填成和 Start IP 一样扫描范围就变成了一个巨大的地址段。不确定地址段里到底有哪些设备活着先自己扫一遍再填参数比在工具里盲目试要快得多# 快速探活只输出存活地址用于核对 Start/End IP 范围 for i in $(seq 2 60); do ip10.10.20.$i ping -c 1 -W 1 $ip /dev/null 21 echo $ip alive doneseq 2 60对应地址段末位范围-W 1把单次等待压到 1 秒几十个地址十几秒就能跑完。跑出来的存活列表和工具扫描结果对比差在哪几台问题就锁定在那几台的账号或协议配置上而不是整个网段。3.3 日志收不上来先带外、再系统、最后工具日志收不上来最忌讳的动作是「先重启试试」。重启会把内存里的现场信息清干净等于亲手把黑匣子扔了。正确的收法是三层递进先拿带外事件日志再拿操作系统侧日志最后才用日志收集工具做整包。# 第一层带外事件日志硬件层面的证据重启也不会丢 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sel elist sel.txt # 第二层操作系统内核与硬件错误日志 dmesg -T dmesg.txt journalctl -k --no-pager kernel.txt # systemd 系 grep -iE error|fail|timeout /var/log/messages messages_err.txt cat /var/log/mcelog mcelog.txt 2/dev/null # 有 mcelog 服务时才有 # 第三层用收集工具做整包Windows/Linux 都支持产出物用于提交分析 # InfoCollect 按交互提示选择日志类型与输出路径即可第一层优先级最高因为 SEL 存在带外模块里掉电、重装系统都不影响第二层解决「硬件正常但业务报错」的场景dmesg -T带可读时间戳方便和业务侧故障时间对齐第三层是给后续分析用的完整包文件大、耗时长放在最后做。三层都拿到再动手处理比先处理再补日志靠谱得多。注意日志文件可能包含主机名、IP、账号等敏感信息外发前按现场规范脱敏别直接把原始包丢到公共位置。4. 固件升级失败、升级后起不来升级前的三件核对和失败后的回退升级是维护动作里风险最高的一类因为它同时动了三个东西固件、配置、业务窗口。翻车的形态也很固定——升级包和型号对不上导致校验失败升级中途网络断掉模块停在半完成状态升级完成但配置漂移业务侧表现异常。这三类问题的处理方式完全不同所以升级前必须先分清自己在升什么。4.1 版本核对从「系统信息-固件版本」读不猜文件名升级包的文件名不可信尤其是从不同渠道拿到的包命名习惯五花八门。判断当前版本的唯一可靠方式是登录带外 Web依次进入「系统信息 → 固件版本」查看命令行方式也能读适合批量核对。# 读取管理模块自身信息确认固件版本与设备型号 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** mc info # 读取 FRU 信息拿到产品型号与序列号用于和升级包的适配列表比对 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** fru printmc info输出的是管理模块的制造商、固件版本、IPMI 版本fru print输出的是整机产品型号和序列号。升级前把这两个输出存档升级后再读一次做对比是最省事的「升级成功与否」判据。要升的固件类型也要分清楚带外管理模块固件不同机型叫 iBMC、iMana 或 MM、BIOS、以及硬盘/网卡/RAID 控制卡固件后者由专用升级工具处理不要和主板固件混在一个窗口里做。# 升级前快照版本 FRU BIOS 配置三份都留 D~/fwpre/$(date %F_%H%M) mkdir -p $D ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** mc info $D/mcinfo.txt ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** fru print $D/fru.txt # BIOS 配置通过带外 Web 的导出功能拿到本地一并放进该目录命名里带时分是为了在连续升级多台设备时不覆盖。这个目录在回退阶段就是对照物升级后如果业务异常先 diff 版本和配置能立刻排除「升错了包」和「配置被重置」这两种最常见的原因。4.2 升级中断的三种典型场景网络断掉。带外升级走的是管理网从便携机或跳板机上传镜像。上传过程中链路抖动、笔记本休眠、无线切换都会让升级卡在半路。规避方式很朴素用有线、用稳定电源、升级期间不切窗口镜像提前放本地不跨网段拉。批量并发。批量工具支持多台同时升级但并发数不是越大越好。同一台交换机下十几台设备同时拉镜像带宽打满超时率立刻上升。我的做法是分批单批控制在个位数每批完成后确认状态再进下一批。升级期间断电或误操作。BIOS 升级需要重启生效重启窗口内下电、按电源键、拔线都会把设备留在不可预期状态。升级前把业务迁走、把窗口报备清楚是唯一可靠的办法没有技术手段能替代。# 升级后逐台确认能读通带外且版本号已变化 for ip in 10.10.20.31 10.10.20.32 10.10.20.33; do echo $ip timeout 10 ipmitool -I lanplus -H $ip -U maint -P ****** mc info \ | grep -Ei firmware revision || echo NO RESPONSE donetimeout 10防止单台无响应把整个循环卡死grep只留版本行便于横向对比。输出NO RESPONSE的那台就是升级后带外没起来的设备需要走现场恢复流程不能指望再升一次能修好。4.3 升级后业务异常回退与配置对比升级后业务异常先分清是固件问题还是配置问题。判据很简单版本号对不对、配置项有没有被重置。版本号对、配置被重置属于配置漂移恢复配置即可版本号不对或者设备行为明显异常才考虑回退。回退的前提是升级前留了旧版本包和配置导出文件。旧包不要从网上临时找升级前就放在同一个目录里命名带上版本号。虚拟媒体挂载在这种情况下很好用把旧包挂在虚拟光驱/软驱上通过带外完成本地化的降级不依赖操作系统是否还能起来。带外还能做上电、下电、重启设备 OS 起不来时这条路径是唯一入口。5. 避坑清单五条把「小问题」拖成「大故障」的记录前面几章讲的是该怎么做这一章讲的是实际做的时候会在哪里翻车。下面五条都是我在现场或远程支持里真实遇到过的每一条都按「现象 → 原因 → 解决」写能对上号就直接抄处置方式。5.1 五条高频踩坑记录第一条面板红灯带外页面显示一切正常。现象前面板 HEALTHY 灯红色常亮登录带外 Web 概览页全绿无任何告警条目。 原因只看概览页没看事件日志。概览反映当前瞬时状态瞬时恢复正常后历史告警仍然留在 SEL 里硬件层面的信息不会因为页面刷新而消失。 解决导 SEL 并按级别过滤重点看 critical/major 条目对应的时间和部件同时导一份传感器读数做趋势对比。概览页正常不等于没发生过故障。第二条换了硬盘重建没跑完就拔了另一块。现象RAID 降级告警刚消几小时后又报降级怀疑背板故障。 原因新盘插入后阵列重建需要时间重建期间再动一块盘阵列直接失去冗余此时报出来的告警指向的是结果不是原因。 解决换盘后确认重建完成再动下一块重建进度在 RAID 配置界面或带外日志里都能看到。多盘故障要一台一台处理别图快。第三条在生产机上做「顺手试一下」的重启。现象巡检时发现某个传感器读数偏高顺手重启验证业务中断。 原因巡检和变更没有边界。文档里那条「一次只做一个改动并记录结果」前提是改动本身经过授权巡检阶段只做只读操作。 解决只读巡检和变更操作分开执行重启、下电、插拔线缆一律走窗口和授权流程现场操作前和接口人确认。第四条徒手拔插内存之后偶发内存告警。现象扩容内存后系统偶发 ECC 告警重新插拔后依旧换槽位才消失。 原因未做防静电措施。插拔单板、手拿精密器件时的静电放电不一定当场致命但会在器件内部留下隐患表现为间歇性错误。 解决接触设备和器件前戴防静电腕带或防静电手套操作前先释放自身静电机房里那个静电敏感区标识不是装饰。插拔类操作永远在断电状态下做。第五条升级完发现 BIOS 配置全变了。现象固件升级成功重启后启动项顺序变化业务起不来。 原因升级前没导出 BIOS 配置升级过程中配置被重置为默认值没人发现差异在哪。 解决升级前导出配置存档升级后逐项比对再放业务带外 Web 的配置导出功能就够用导出物和固件包放同一个目录。5.2 部件更换流程断电、防静电、记录、复测部件更换是维护动作里最容易「做完就完事」的一环而它恰恰是最需要收尾的。流程上我按固定四步走不做删减。第一步确认故障部件。依据是带外 SEL 里的告警条目加上现场指示灯状态两者指向同一个部件才动手只凭一条告警就换件很容易换错。第二步断电与防静电。断电、拔电源线、等待放电戴防静电腕带或手套在静电敏感区操作时严格按标识要求来。带高温表面标识的部件要等降温后再接触带高压标识的区域没有可维护器件不要打开。第三步更换并记录。换下的部件记录序列号、故障现象、更换时间、操作人新部件同样记录序列号这是后续判断是否为同一批次问题的依据。备件现场留存故障时才能及时更换。第四步复测。上电后先看指示灯再读传感器和 SEL确认原告警不再复现、无新增告警最后才把业务放回去。# 更换后复测清空前的 SEL 存档再确认当前无严重告警 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sel elist sel_after_replace.txt # 只看传感器是否有越界项正常应无 critical 级别输出 ipmitool -I lanplus -H 10.10.20.31 -U maint -P ****** sensor \ | awk $0 ~ /cr|nc/ {print}第二条命令用awk过滤包含crcritical或ncnon-critical的行没有输出说明当前读数全部在阈值内。复测的价值在于把「换完了」变成「修好了」——这两件事在现场经常被混为一谈然后过几天同一个故障再来一次。提示更换记录和巡检记录放在同一个归档目录里故障复发时把两次记录摆在一起看能快速判断是同一个部件、同一批次还是同一类环境因素。6. 快速定位从一条告警收敛到具体部件的三个动作故障现场最慌的时刻不是发现问题是发现问题之后不知道从哪下手。我的习惯是无论什么现象先做三个动作把范围从「一台设备」收敛到「一个部件」再谈处理。第一个动作看灯。前面板 HEALTHY 灯、电源按钮指示灯、硬盘状态灯、后面板电源模块灯四个位置扫一遍十秒钟。绿灯常亮或闪烁正常红灯、黄灯、不亮都是异常。这一步能立刻把「整机问题」和「单部件问题」分开。第二个动作读事件日志而不是概览页。概览页给的是当下SEL 给的是过程。把 SEL 里近 24 小时的条目按级别过滤出来按时间排序第一条 critical 出现的时间点通常就是故障起点。传感器数据同步导一份和阈值表对一遍。第三个动作对照告警参考。每一条告警码在厂商的告警参考文档里都有对应的处理建议别凭经验猜。文档里明确写了某类告警是「请更换」还是「请观察」照着做比自己判断准。把三个动作的结果拼起来基本能得到一张对照表现象优先查什么依据面板红灯概览页正常SEL 历史条目瞬时恢复的故障只留在事件日志里概览页有告警指示灯正常告警码对应的部件与处理建议告警参考文档硬盘黄灯或不亮硬盘状态与阵列重建进度硬盘指示灯 RAID 配置界面风扇异响或很响风扇模块与进风口温度现场听感 传感器读数带外连不上业务正常管理网口链路、端口、协议配置ping 端口探测 带外协议开关业务异常硬件全绿操作系统侧日志与配置变更记录dmesg、系统日志、升级/变更记录电源模块指示灯不亮供电输入与电源线连接万用表测电压 插头检查再补一个容易被忽略的收敛技巧用序列号对齐所有材料。巡检报告、SEL 导出、更换记录、报修单全都用主机序列号或单板序列号做索引而不是用「三号机柜第二台」这种位置描述。位置会变序列号不会故障复盘时按序列号能把一台设备半年的历史一次拉出来。从那以后我每次进机房哪怕只是看一眼都会强制走一遍「灯 → SEL → 告警参考」这三步并且把输出落盘归档。这套动作花不了几分钟但它把「我觉得没问题」变成了「我有证据说明没问题」也让下一次同类故障有了可以对比的基线。希望帮到你。本文还有配套的精品资源点击获取