企业官网建设流程全解析

简介：这份《华为服务器日常维护及故障处理文档》面向服务器运维工程师、机房管理员及IT支持人员，聚焦华为服务器日常巡检、软件升级与故障处置等典型工作场景。压缩包内共1个PDF文件，约2.35MB，内容以操作规范、检查表和流程说明为主，便于现场查阅与培训使用。文档按“日常维护”和“故障处理”两大板块展开：维护准备列出浮动螺母安装条、防静电腕带、万用表等硬件工具，以及Toolkit Tools、Umate Tools、InfoCollect等软件工具的用途，并提示用户指南、维护指南、告警参考等必读资料；巡检部分覆盖机房温湿度、供电、线缆布放和服务器指示灯、iBMC/MM健康状态检查。故障处理部分给出诊断流程、信息收集与定位方法，并说明部件更换流程及注意事项。已有1359人学习，适合需要建立标准化维护流程、快速排查硬件与告警问题的读者参考。

1. 面板红灯常亮、管理页面却一条告警都没有：这类故障最耗人

机柜前面板 HEALTHY 灯红色常亮，登录带外管理页面，概览一片绿色，一条告警都没有。重启后恢复正常，两天后同一位置再次亮红，中间换过电源模块，问题照旧。做服务器日常维护的人对这一幕不会陌生：真正的根因往往不是硬件坏了，而是巡检漏项、日志没收全、升级前没核对版本这三件事叠在一起，把原本能定位的线索拖成了玄学。故障处理里最贵的成本从来不是换件，是方向错了还在往前走。这份维护与故障处理文档把维护准备、日常巡检、软件升级、诊断流程、信息收集、故障定位、部件更换串成一条完整处置链，天天跟机柜打交道、要出巡检报告、被「换件就好、过几天又坏」折腾过的人，读它比读零散教程值。

2. 巡检做完没几天又出问题：日常巡检的判定阈值和漏项清单

复发性故障里，真正坏在板卡上的比例并不高。更多情况是环境在某段时间越界，设备自我保护降频、风扇拉满、硬盘离线，等维护人员到场时一切又恢复正常，什么痕迹都没留下。巡检表上环境项看着最没技术含量，但它往往是唯一能在故障发生前留下证据的一栏。这一章先把「巡检该看什么、看到什么算异常、异常了记在哪」这三件事定下来，再谈工具。

2.1 环境项先看这三个数字：温度、湿度、供电

机房环境不是「不热就行」。设备厂商给的指标是有上下限的，越界不一定立刻宕机，但会以性能下降、风扇转速异常、硬盘掉线这类间接形式表现出来，而且往往在越界结束后才发作。

三个最容易被忽略的点：一是温度变化率，很多机房空调白天夜间切换，绝对温度没超标，但一小时掉了十几度，结露和热胀冷缩带来的接触不良就是这样来的；二是湿度必须无冷凝，表上一句括号注掉了最容易出事的前提；三是直流供电的负电压波动范围，用万用表量的时候要按 -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.txt"

diff出来的新增行，就是两次巡检之间真实发生过的变化。这套做法救过我很多次：面板红灯复现、但当场一切正常的场景，靠历史 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 正常，优先怀疑中间有策略拦截或者管理网口和业务网口接反了。这套判断顺序的意义在于：先证明链路，再怀疑工具，否则你会花半天时间重装一个根本没问题的巡检工具。

端口默认值记牢，改过端口的话要在工具参数里同步改：

另外两个前置条件经常被跳过：一是操作系统侧也要能被 ping 通，且 SSH、SFTP 端口连通；二是要确认服务器型号或操作系统版本在工具的支持列表里，环境不满足工具运行要求时，报错信息往往指向「连接失败」，实际是兼容性问题。

3.2 Start IP / End IP 与凭据：扫描只出一台的三个原因

批量巡检的参数面板看着简单，填错的方式却很多。参数的含义和规则如下：

「只扫到一台」通常就是这三条踩中其中之一：连续地址批量扫描时，Start IP 和 End IP 的前两段必须一致，且各设备用户名密码必须相同；地址不连续、或者密码各自不同的，只能按单台设备逐条处理；单台设备时 End IP 忘了填成和 Start IP 一样，扫描范围就变成了一个巨大的地址段。

不确定地址段里到底有哪些设备活着，先自己扫一遍再填参数，比在工具里盲目试要快得多：

# 快速探活，只输出存活地址，用于核对 Start/End IP 范围 for i in $(seq 2 60); do ip="10.10.20.$i" ping -c 1 -W 1 "$ip" > /dev/null 2>&1 && echo "$ip alive" done

seq 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 print

mc 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" done

timeout 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过滤包含cr（critical）或nc（non-critical）的行，没有输出说明当前读数全部在阈值内。复测的价值在于把「换完了」变成「修好了」——这两件事在现场经常被混为一谈，然后过几天同一个故障再来一次。

提示：更换记录和巡检记录放在同一个归档目录里，故障复发时把两次记录摆在一起看，能快速判断是同一个部件、同一批次，还是同一类环境因素。

6. 快速定位：从一条告警收敛到具体部件的三个动作

故障现场最慌的时刻不是发现问题，是发现问题之后不知道从哪下手。我的习惯是无论什么现象，先做三个动作，把范围从「一台设备」收敛到「一个部件」，再谈处理。

第一个动作，看灯。前面板 HEALTHY 灯、电源按钮指示灯、硬盘状态灯、后面板电源模块灯，四个位置扫一遍，十秒钟。绿灯常亮或闪烁正常，红灯、黄灯、不亮都是异常。这一步能立刻把「整机问题」和「单部件问题」分开。

第二个动作，读事件日志而不是概览页。概览页给的是当下，SEL 给的是过程。把 SEL 里近 24 小时的条目按级别过滤出来，按时间排序，第一条 critical 出现的时间点，通常就是故障起点。传感器数据同步导一份，和阈值表对一遍。

第三个动作，对照告警参考。每一条告警码在厂商的告警参考文档里都有对应的处理建议，别凭经验猜。文档里明确写了某类告警是「请更换」还是「请观察」，照着做，比自己判断准。

把三个动作的结果拼起来，基本能得到一张对照表：

再补一个容易被忽略的收敛技巧：用序列号对齐所有材料。巡检报告、SEL 导出、更换记录、报修单，全都用主机序列号或单板序列号做索引，而不是用「三号机柜第二台」这种位置描述。位置会变，序列号不会；故障复盘时，按序列号能把一台设备半年的历史一次拉出来。

从那以后我每次进机房，哪怕只是看一眼，都会强制走一遍「灯 → SEL → 告警参考」这三步，并且把输出落盘归档。这套动作花不了几分钟，但它把「我觉得没问题」变成了「我有证据说明没问题」，也让下一次同类故障有了可以对比的基线。希望帮到你。

本文还有配套的精品资源，点击获取