简介面向华为服务器运维人员的一份标准化维护与故障处理知识文档系统覆盖维护准备、日常巡检、软件升级和故障诊断全流程可帮助新手快速建立规范操作框架也适合数据中心及企业机房运维者作为日常参考。内容从硬件工具清单如螺丝刀、万用表、防静电腕带/手套等、软件工具清单Putty/Winscp、Toolkit Tools、Umate Tools、InfoCollect等到必读资料均有详解并针对巡检意义、基本原则、现场环境指标温湿度、供电、海拔等和服务器运行状态检查给出了可落地的执行要点故障处理部分梳理了诊断流程、信息收集方法、定位思路及部件更换注意事项实操指导性强。资源以1份PDF文档提供压缩包仅2.35MB内容集中便于阅读当前已有1357人学习浏览适合需要系统掌握华为服务器日常运维与排障要点的工程技术人员。1. 为什么机房老手也要一份服务器维护文档从一次凌晨告警说起凌晨两点机房某台运行多年的服务器亮起红色告警灯。值班同事按习惯先重启结果系统没能起来登录管理口一看系统盘所在的RAID组里两块盘同时离线。如果当时手边有一份服务器日常维护及故障处理文档按流程先确认对端盘状态再动手事故完全可以避免。这不是设备质量翻车是维护流程出了问题。服务器日常维护及故障处理文档要解决的就是这类问题把“凭经验处理”变成“按文档处置”。它面向机房运维、系统管理员和刚接手服务器维护的新人覆盖日常巡检该看什么、告警来了怎么分级、故障现场先采集哪些信息以及怎么把一次故障处理沉淀成后续可复用的步骤。文档本身不神秘核心是两件事知道正常长什么样以及异常发生时知道先做什么、不做什么。2. 服务器日常维护到底维护什么硬件、固件与日志三条主线服务器维护不是巡检时看两眼指示灯就完事。我习惯把日常维护拆成三条主线硬件健康、固件版本、日志基线。三条线各有各的工具和判定标准但最终都要落到一份能留痕的文档上否则维护工作做没做、做到什么程度根本说不清楚。2.1 硬件健康检查从电源、风扇到硬盘的巡检顺序与判定标准巡检顺序建议从外到内、从供电到存储。先看机箱面板指示灯和告警灯再进管理口看传感器读数最后登录系统看硬盘和内存的错误计数。常见做法是每周一次例行巡检每月一次深度巡检深度巡检时要把管理口日志导出来归档。顺序不能乱因为面板指示灯能反映整机状态管理口传感器能定位到具体部件系统日志则能解释这些状态背后的原因。巡检项工具/命令正常判定异常动作电源模块管理口传感器双电源均在线无电压越限单模块告警时确认另一路负载能力尽快更换风扇转速管理口传感器转速非零且在调速区间内转速为0或持续满载检查积灰和风扇本体CPU/进风温度管理口传感器进风温度低于35℃CPU核心低于85℃超阈值先查机房空调和风道再查硅脂硬盘SMARTsmartctlReallocated计数不增长Pending为0计数增长就准备更换不等彻底掉盘内存ECC管理口/SEL日志CE计数不持续增长无UE错误CE持续增长安排内存替换UE立刻处理硬盘这块踩坑最多。系统里查看SMART信息我一般用这条命令smartctl -a /dev/sda | grep -E Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable输出里三个关键计数分别代表已经重映射的坏扇区数、等待重映射的扇区数、无法纠正的扇区数。只要Current_Pending_Sector不是0或者Reallocated计数比上次巡检时变大这块盘就处于亚健康状态不要因为系统还能跑就拖到下次巡检。类似场景里某厂商的硬盘告警策略是持续性的不会自动消失重启只是暂时掩盖现象过几天告警还会回来。进管理口看传感器时别只盯着温度。电源功率和风扇转速的“历史曲线”比瞬时值更有用瞬时值正常不代表一整天都正常。我习惯把每次巡检的传感器读数记录下来时间一长就能看出趋势比如某块硬盘的Pending计数每月涨一点那就按月份倒推更换窗口而不是等它某天突然掉线。2.2 固件与补丁管理版本对齐是维护的地基日常维护里最容易被忽视的是固件版本。服务器不是装完系统就一劳永逸管理口固件、BIOS、硬盘固件、RAID卡固件都有自己的版本而且彼此之间存在兼容约束。很多服务器在管理口里能直接看到各部件固件版本也能做在线升级但升级前必须确认版本组合是否在兼容性列表里。我见过不止一次因为固件版本不匹配导致风扇策略异常、硬盘识别不稳定的案例。我一般会做一张固件版本台账字段包括部件名称、当前版本、目标版本、升级日期、升级前备份名。固件升级的原则不是“越新越好”而是“和整机其他部件匹配”。实际维护中遇到过升级管理口固件后风扇调速策略变化导致噪声变大、温度反而升高的情况最后只能回退旧版本。所以升级前一定要做两件事备份当前固件记录升级前传感器基线。管理口固件通常支持备份和回退但回退操作往往比升级更耗时别在业务高峰期做这种操作。补丁管理同样要留痕。操作系统补丁、驱动补丁、管理口补丁每打一个都要在维护文档里记录时间和操作人。故障处理时最怕的就是不知道系统最近改过什么有了版本记录排查范围能缩小一大半。很多故障的根因不是硬件本身而是某个驱动补丁和现有固件组合出了冲突这种问题靠查日志很难定位靠变更记录一眼就能看到。2.3 日志采集与基线对比把“感觉正常”变成“数据正常”很多机房老手判断服务器正不正常靠“感觉”听风扇声、摸机箱温度。感觉在多数时候可靠但没法写进文档也没法追溯。要建立基线就得靠日志和数据。管理口日志记录硬件告警和传感器事件系统日志记录操作系统层面的错误两者要配合看单看哪一边都容易误判。# 查看最近一次启动以来的内核硬件错误 journalctl -b -1 -p err --no-pager | grep -iE hard error|memory error|pcie # 查看今日系统错误日志 journalctl --since 24 hours ago -p err --no-pager | tail -50 # 查看内存ECC相关的SEL记录需要系统装有IPMI工具 ipmitool sel list | grep -i ECC\|Correctable | tail -20第一行里的-b -1表示查看上一次启动的日志服务器每次重启都会把上一轮的日志保留下来出问题时先看这里。第二行看最近24小时的错误排除噪声后如果每天都有同样的报错那大概率不是偶发需要顺着这个线索往下挖。第三行是管理口记录的硬件事件内存CE可纠正错误如果持续增长说明内存颗粒或通道有问题要提前安排更换别等到UE不可纠正错误出现才动手。有了日志还要有基线。我的习惯是每月导出一份管理口日志在维护文档里登记以下内容进风温度、CPU温度、风扇转速区间、电源功率、硬盘SMART关键计数、内存CE计数。下次巡检只需要对比这两次数值任何明显偏离都能被揪出来。日志是黑匣子基线就是解读黑匣子的参照系缺了参照系日志只是一堆看不懂的记录。3. 故障处理的标准动作告警分级、信息采集与三板斧故障处理最容易犯的错是“急着重启”。正确的做法是先分级、再采集、后处置这个顺序一旦颠倒轻则丢失证据重则把小故障扩大成大故障。这一章把三个动作拆开讲每个动作都有明确的步骤和边界。3.1 告警分级哪些告警必须立即处理哪些可以排队管理口会把告警分成几级但实际值班时不能只按管理口的级别走还要结合业务影响来判断。有的告警管理口标成“严重”但业务无感知可以等窗口期处理有的告警管理口只标了“警告”但意味着冗余已经丢失必须马上行动。我常用的分级表如下级别典型告警响应要求P1 紧急双电源失效、RAID组降级、CPU/内存UE错误、温度超上限持续立即处理先恢复业务再定位根因P2 重要单硬盘离线、单风扇转速为0、内存CE持续增长、电源单模块告警4小时内处理可等低峰窗口更换P3 次要日志告警风暴、性能阈值、电池老化、非关键传感器波动登记跟踪列入周巡检分级的核心原则是优先恢复业务但恢复操作前必须留证据。比如RAID组降级先登录管理口把SEL日志和RAID卡状态导出再决定是更换硬盘还是重启。现实中很多翻车都发生在这一步硬盘离线后直接重启结果RAID组里其他盘也被带崩本来是单盘故障变成整组丢失。3.2 现场信息采集故障发生后的黄金半小时故障发生后的半小时是信息采集的黄金时间。过了这段时间系统可能被重启、日志可能被滚动覆盖、现场可能被破坏很多关键证据就没了。所以标准的动作是四步先对机箱面板、告警灯、管理口界面拍照或截图存档再通过管理口导出SEL事件日志和传感器历史记录然后登录系统保存上次启动日志和系统消息最后记录故障发生时间、当时业务负载、最近一次变更操作。采集用的命令很简单关键是顺序# 先导出管理口SEL这一步通常在管理口Web界面操作也可以命令行执行 ipmitool sel list /tmp/sel_$(date %Y%m%d).txt # 再收集系统日志 journalctl -b -1 --no-pager /tmp/last_boot.log dmesg -T /tmp/dmesg_$(date %Y%m%d).txt # 最后记录RAID卡状态如果有RAID卡工具 storcli /c0 show all /tmp/raid_status.txt这里强调顺序SEL在最前面因为管理口日志不受系统重启影响但越早导出越完整。系统日志在重启前导出一旦重启-b -1的内容还在但内存里的dmesg会丢失。RAID状态务必在重启前查看很多RAID卡在重启后会重新同步原始失败信息可能被覆盖。这几步做完故障处理才有依据后面不管是换硬件还是提工单都拿得出证据。注意故障处理的第一步永远是采集证据不是重启。SEL日志和RAID状态必须在重启前导出错过这个窗口很多关键信息就永久丢失了。3.3 重启、拔插、替换处理故障的“三板斧”与生效边界运维圈里流传的“三板斧”是重启、拔插、替换简单有效但也有边界。重启能解决临时性软件故障和驱动卡死但解决不了硬件损坏拔插能解决接触不良但解决不了器件老化替换能解决单点故障但替换前必须确认备件型号和固件兼容。搞不清边界三板斧就是三把坑。我处理故障时会给“三板斧”加两个前置条件。第一重启前必须确认RAID卡状态和硬盘状态系统盘所在RAID组里有盘离线时盲目重启可能触发重建或导致系统起不来。第二拔插前必须确认槽位和防呆设计戴防静电手腕带断电操作比带电拔插安全得多除非是设计为热插拔的部件。这两个条件写进维护文档后新人出错的概率会低很多。替换也有讲究。换硬盘前先确认热备盘状态、确认新盘容量和转速不低于原盘换电源前确认新电源功率不低于原模块换内存前确认新内存的规格和rank数与现有内存匹配。每一步操作都要在维护文档里记录替换下来的旧件贴上标签保存一段时间别急着丢——有时候换完后问题还在旧件还能提供线索。4. 用文档驱动运维把维护经验沉淀成一份可复用的检查单很多团队的维护文档是故障发生后补写的平时没人看出事了才翻。真正有效的维护文档是日常就在更新、故障时能直接照着做的东西。这一章讲怎么把文档建起来重点不是模板而是让文档真正服务于下一次故障处理。4.1 维护文档的骨架从设备台账开始没有设备台账维护文档就是空中楼阁。台账是每一台服务器的“身份证”字段不用太多但关键信息不能少。字段太多会没人维护字段太少又起不到作用平衡点大概就是下面这几项字段示例说明设备编号SRV-01唯一标识机柜标签一致序列号SN开头字符串保修和备件查询用硬件配置CPU/内存/硬盘/RAID卡型号变更时同步更新固件版本管理口、BIOS、RAID卡固件升级后当天更新业务用途数据库/应用/存储决定维护窗口网络信息管理口IP、业务IP故障时登录入口维保状态在保/过保、备件位置决定替换策略台账建议用表格维护每个机柜一张服务器变化时当天更新。序列号尤其重要报修或申请备件时都要用别等故障了再开机箱去找。备件位置这一项容易被忽略但对故障处理速度影响很大知道备件在哪个柜子哪一层比临时打采购电话快得多。4.2 操作步骤的写法让新人照着做也不会出错维护文档里最值钱的部分是操作SOP特别是故障处理步骤。我见过的失败SOP有两种一种是只写“更换故障硬盘”六个字等于没写另一种是写了几十页原理操作时找不到重点。合格的SOP应该包含五部分目标、前置条件、操作步骤、预期结果、异常处理。前置条件尤其重要它决定了新人能不能安全开始操作。以更换故障硬盘为例一个可复用的SOP是这样写的确认故障盘槽位、序列号登录管理口确认该盘处于离线或降级状态。检查RAID组内其他盘状态正常有热备盘则确认热备已顶替。在管理口界面点亮故障盘定位灯物理确认槽位无误。断电或热拔插取下硬盘装入新盘确认新盘容量和转速不低于原盘。登录RAID卡工具确认新盘被识别触发重建并观察进度。重建完成后更新维护文档中的硬盘信息。写得细不等于啰嗦关键是把“怎么判断正确”写进去。比如第2步就是血泪经验换来的很多新人拿到告警就拔盘拔完后发现其他盘也快不行了。预期结果和异常处理也要有新盘不识别怎么办、重建失败怎么办、定位灯不亮怎么办每种情况给一句话处理建议就够不需要长篇大论。4.3 版本记录与变更回溯文档是故障处理的后悔药故障处理时最痛苦的事是不知道系统最近改过什么。服务器不会无缘无故出问题很多故障的根因是前一天升级了固件、更新了驱动、调整了BIOS参数。如果没有变更记录排查就像大海捞针有了记录先看最近一次变更范围立刻缩小。这也是为什么我把变更记录称为“后悔药”——出事的时候它是唯一能让你快速回到问题起点的东西。变更记录表建议包含日期、变更内容、变更前版本、变更后版本、操作人、审批人、结果备注。每次变更后当天更新不要攒到月底。还有一个容易被忽略的动作变更完成后立即做一次巡检基线采集作为回滚判断的参照。这样如果变更后一周内出现异常可以把当前数据和基线对比快速决定是否回滚而不是靠感觉猜。5. 服务器维护避坑指南五个典型翻车场景与处置记录这一章写五个典型的翻车场景每条按“现象→原因→解决”来写都是我见过或处理过的高频问题。如果你能避开这五个坑服务器维护的大半风险就控住了。5.1 RAID降级后直接重启系统直接起不来现象一块硬盘离线RAID组降级值班同事没细看就直接重启结果系统起不来进恢复界面发现另一块盘也离线了。原因单盘离线后RAID组其他盘往往也处于亚健康状态重启时的读盘压力会加速坏盘掉线导致故障扩大。解决硬盘离线后先登录管理口和RAID卡工具确认其他盘SMART状态再决定操作。需要重启时严格执行先导出RAID状态和SEL日志再重启。这个顺序写进文档能避免大多数RAID翻车。5.2 升级固件后风扇全速转温度反而升高现象升级管理口固件后风扇转速策略变化风扇持续全速运转噪声变大CPU温度比升级前还高了几度。原因新固件默认的调速策略和当前硬件组合不匹配固件版本之间不是简单的“新版更好”版本组合需要对齐。解决升级前备份当前固件记录传感器基线。升级后出现异常就回退到上一版本回退后再对照基线确认温度恢复。固件升级这件事慢就是快做好回退预案再动手。5.3 SMART报warning没处理一周后硬盘彻底失效现象硬盘SMART状态显示warning系统日志有坏道报错值班同事看系统还能跑就没处理结果一周后盘彻底掉线RAID重建耗时太久。原因把SMART warning当成“偶发告警”以为重启或观察几天会自己消失实际上SMART告警是硬件持续性的不会自愈。解决看到Current_Pending_Sector非0或Reallocated计数增长直接安排更换不要赌运气。巡检时把SMART计数单独列出来和上次巡检对比增长就是信号。5.4 清灰后开机黑屏折腾半天才找到原因现象机房清灰后服务器无法开机管理口显示已上电但黑屏反复插拔电源线也没解决最后发现是内存没插到位。原因清灰时机箱搬动、部件拆装容易导致内存或电源插头松动主板自检不过表现就是“有电但黑屏”。解决清灰后开机前逐根按压内存到卡扣弹起检查电源线、硬盘数据线、RAID卡和网卡是否插到位。先最小化配置点亮单内存、单电源再逐步接回其他部件能快速定位松动点。5.5 导出日志文件打不开白忙活一场现象故障现场从管理口导出日志事后在电脑上打开时提示格式错误或文件大小异常证据链断了一截。原因浏览器直接“另存为”管理口页面拿到的是网页而不是日志文件或者导出过程网络中断文件不完整。解决用管理口自带的导出功能下载不要手动另存页面。大日志分段导出导完检查文件大小和末尾是否有结束标记。保存后第一时间解压打开验证别等故障处理时才发现文件有问题。6. 进阶一条命令生成巡检快照把维护文档变成自动化的底稿维护文档不能只靠手动填写日常巡检的重复内容完全可以脚本化。我习惯写一个巡检快照脚本每次执行后生成一个带时间戳的文本文件内容包含主机信息、传感器读数、硬盘SMART关键计数和最近的系统错误日志。这个文件既是巡检记录也是维护文档的底稿还能在故障时快速对比“上一次正常是什么样”。#!/bin/bash # 巡检快照把关键硬件状态汇总到一个文本文件用于日常维护留痕 SNAPSHOT/var/log/hw_check_$(date %Y%m%d_%H%M%S).txt { echo 巡检快照 $(date) echo 主机名: $(hostname) # 序列号通常来自主板DMI信息不同厂商字段略有差异 echo 序列号: $(dmidecode -s system-serial-number) echo --- CPU温度与风扇转速 --- # sensors命令输出因主板和监控芯片而异抓关键词即可 sensors | grep -iE Package|Core|fan[0-9] echo --- 硬盘SMART关键计数 --- # 按实际磁盘列表调整生产环境建议从/etc/fstab解析设备名 for disk in /dev/sda /dev/sdb; do [ -e $disk ] || continue echo 磁盘: $disk smartctl -a $disk | grep -E Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable done echo --- 24小时内系统错误日志 --- journalctl --since 24 hours ago -p err --no-pager | tail -30 } $SNAPSHOT echo 快照已生成: $SNAPSHOT脚本本身不复杂关键是几个参数的意义。-p err只取错误级别及以上的日志排除info和warning的噪声tail -30控制错误日志条数避免文件无限膨胀dmidecode -s system-serial-number读取整机序列号方便多台服务器巡检后按序号归档。磁盘列表建议根据实际配置修改生产环境可以从/etc/fstab或/proc/mounts动态获取避免漏掉新增的盘。这份巡检快照落地后日常维护就变成了“跑脚本、对基线、存归档”三步。跑完脚本把关键数值和上一份快照做对比有偏离就查原因没偏离就存档。故障发生时先跑一次脚本生成当前快照再翻出上一份正常快照能立刻看出是哪个部件出了问题。这是我做服务器维护几年下来最实用的习惯——把玄学变成数据把经验变成文档出问题时手里永远有底牌。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 5:51:34 · 阅读 1.2k 服务器日常维护与故障处理：从巡检到文档化实战指南
简介面向华为服务器运维人员的一份标准化维护与故障处理知识文档系统覆盖维护准备、日常巡检、软件升级和故障诊断全流程可帮助新手快速建立规范操作框架也适合数据中心及企业机房运维者作为日常参考。内容从硬件工具清单如螺丝刀、万用表、防静电腕带/手套等、软件工具清单Putty/Winscp、Toolkit Tools、Umate Tools、InfoCollect等到必读资料均有详解并针对巡检意义、基本原则、现场环境指标温湿度、供电、海拔等和服务器运行状态检查给出了可落地的执行要点故障处理部分梳理了诊断流程、信息收集方法、定位思路及部件更换注意事项实操指导性强。资源以1份PDF文档提供压缩包仅2.35MB内容集中便于阅读当前已有1357人学习浏览适合需要系统掌握华为服务器日常运维与排障要点的工程技术人员。1. 为什么机房老手也要一份服务器维护文档从一次凌晨告警说起凌晨两点机房某台运行多年的服务器亮起红色告警灯。值班同事按习惯先重启结果系统没能起来登录管理口一看系统盘所在的RAID组里两块盘同时离线。如果当时手边有一份服务器日常维护及故障处理文档按流程先确认对端盘状态再动手事故完全可以避免。这不是设备质量翻车是维护流程出了问题。服务器日常维护及故障处理文档要解决的就是这类问题把“凭经验处理”变成“按文档处置”。它面向机房运维、系统管理员和刚接手服务器维护的新人覆盖日常巡检该看什么、告警来了怎么分级、故障现场先采集哪些信息以及怎么把一次故障处理沉淀成后续可复用的步骤。文档本身不神秘核心是两件事知道正常长什么样以及异常发生时知道先做什么、不做什么。2. 服务器日常维护到底维护什么硬件、固件与日志三条主线服务器维护不是巡检时看两眼指示灯就完事。我习惯把日常维护拆成三条主线硬件健康、固件版本、日志基线。三条线各有各的工具和判定标准但最终都要落到一份能留痕的文档上否则维护工作做没做、做到什么程度根本说不清楚。2.1 硬件健康检查从电源、风扇到硬盘的巡检顺序与判定标准巡检顺序建议从外到内、从供电到存储。先看机箱面板指示灯和告警灯再进管理口看传感器读数最后登录系统看硬盘和内存的错误计数。常见做法是每周一次例行巡检每月一次深度巡检深度巡检时要把管理口日志导出来归档。顺序不能乱因为面板指示灯能反映整机状态管理口传感器能定位到具体部件系统日志则能解释这些状态背后的原因。巡检项工具/命令正常判定异常动作电源模块管理口传感器双电源均在线无电压越限单模块告警时确认另一路负载能力尽快更换风扇转速管理口传感器转速非零且在调速区间内转速为0或持续满载检查积灰和风扇本体CPU/进风温度管理口传感器进风温度低于35℃CPU核心低于85℃超阈值先查机房空调和风道再查硅脂硬盘SMARTsmartctlReallocated计数不增长Pending为0计数增长就准备更换不等彻底掉盘内存ECC管理口/SEL日志CE计数不持续增长无UE错误CE持续增长安排内存替换UE立刻处理硬盘这块踩坑最多。系统里查看SMART信息我一般用这条命令smartctl -a /dev/sda | grep -E Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable输出里三个关键计数分别代表已经重映射的坏扇区数、等待重映射的扇区数、无法纠正的扇区数。只要Current_Pending_Sector不是0或者Reallocated计数比上次巡检时变大这块盘就处于亚健康状态不要因为系统还能跑就拖到下次巡检。类似场景里某厂商的硬盘告警策略是持续性的不会自动消失重启只是暂时掩盖现象过几天告警还会回来。进管理口看传感器时别只盯着温度。电源功率和风扇转速的“历史曲线”比瞬时值更有用瞬时值正常不代表一整天都正常。我习惯把每次巡检的传感器读数记录下来时间一长就能看出趋势比如某块硬盘的Pending计数每月涨一点那就按月份倒推更换窗口而不是等它某天突然掉线。2.2 固件与补丁管理版本对齐是维护的地基日常维护里最容易被忽视的是固件版本。服务器不是装完系统就一劳永逸管理口固件、BIOS、硬盘固件、RAID卡固件都有自己的版本而且彼此之间存在兼容约束。很多服务器在管理口里能直接看到各部件固件版本也能做在线升级但升级前必须确认版本组合是否在兼容性列表里。我见过不止一次因为固件版本不匹配导致风扇策略异常、硬盘识别不稳定的案例。我一般会做一张固件版本台账字段包括部件名称、当前版本、目标版本、升级日期、升级前备份名。固件升级的原则不是“越新越好”而是“和整机其他部件匹配”。实际维护中遇到过升级管理口固件后风扇调速策略变化导致噪声变大、温度反而升高的情况最后只能回退旧版本。所以升级前一定要做两件事备份当前固件记录升级前传感器基线。管理口固件通常支持备份和回退但回退操作往往比升级更耗时别在业务高峰期做这种操作。补丁管理同样要留痕。操作系统补丁、驱动补丁、管理口补丁每打一个都要在维护文档里记录时间和操作人。故障处理时最怕的就是不知道系统最近改过什么有了版本记录排查范围能缩小一大半。很多故障的根因不是硬件本身而是某个驱动补丁和现有固件组合出了冲突这种问题靠查日志很难定位靠变更记录一眼就能看到。2.3 日志采集与基线对比把“感觉正常”变成“数据正常”很多机房老手判断服务器正不正常靠“感觉”听风扇声、摸机箱温度。感觉在多数时候可靠但没法写进文档也没法追溯。要建立基线就得靠日志和数据。管理口日志记录硬件告警和传感器事件系统日志记录操作系统层面的错误两者要配合看单看哪一边都容易误判。# 查看最近一次启动以来的内核硬件错误 journalctl -b -1 -p err --no-pager | grep -iE hard error|memory error|pcie # 查看今日系统错误日志 journalctl --since 24 hours ago -p err --no-pager | tail -50 # 查看内存ECC相关的SEL记录需要系统装有IPMI工具 ipmitool sel list | grep -i ECC\|Correctable | tail -20第一行里的-b -1表示查看上一次启动的日志服务器每次重启都会把上一轮的日志保留下来出问题时先看这里。第二行看最近24小时的错误排除噪声后如果每天都有同样的报错那大概率不是偶发需要顺着这个线索往下挖。第三行是管理口记录的硬件事件内存CE可纠正错误如果持续增长说明内存颗粒或通道有问题要提前安排更换别等到UE不可纠正错误出现才动手。有了日志还要有基线。我的习惯是每月导出一份管理口日志在维护文档里登记以下内容进风温度、CPU温度、风扇转速区间、电源功率、硬盘SMART关键计数、内存CE计数。下次巡检只需要对比这两次数值任何明显偏离都能被揪出来。日志是黑匣子基线就是解读黑匣子的参照系缺了参照系日志只是一堆看不懂的记录。3. 故障处理的标准动作告警分级、信息采集与三板斧故障处理最容易犯的错是“急着重启”。正确的做法是先分级、再采集、后处置这个顺序一旦颠倒轻则丢失证据重则把小故障扩大成大故障。这一章把三个动作拆开讲每个动作都有明确的步骤和边界。3.1 告警分级哪些告警必须立即处理哪些可以排队管理口会把告警分成几级但实际值班时不能只按管理口的级别走还要结合业务影响来判断。有的告警管理口标成“严重”但业务无感知可以等窗口期处理有的告警管理口只标了“警告”但意味着冗余已经丢失必须马上行动。我常用的分级表如下级别典型告警响应要求P1 紧急双电源失效、RAID组降级、CPU/内存UE错误、温度超上限持续立即处理先恢复业务再定位根因P2 重要单硬盘离线、单风扇转速为0、内存CE持续增长、电源单模块告警4小时内处理可等低峰窗口更换P3 次要日志告警风暴、性能阈值、电池老化、非关键传感器波动登记跟踪列入周巡检分级的核心原则是优先恢复业务但恢复操作前必须留证据。比如RAID组降级先登录管理口把SEL日志和RAID卡状态导出再决定是更换硬盘还是重启。现实中很多翻车都发生在这一步硬盘离线后直接重启结果RAID组里其他盘也被带崩本来是单盘故障变成整组丢失。3.2 现场信息采集故障发生后的黄金半小时故障发生后的半小时是信息采集的黄金时间。过了这段时间系统可能被重启、日志可能被滚动覆盖、现场可能被破坏很多关键证据就没了。所以标准的动作是四步先对机箱面板、告警灯、管理口界面拍照或截图存档再通过管理口导出SEL事件日志和传感器历史记录然后登录系统保存上次启动日志和系统消息最后记录故障发生时间、当时业务负载、最近一次变更操作。采集用的命令很简单关键是顺序# 先导出管理口SEL这一步通常在管理口Web界面操作也可以命令行执行 ipmitool sel list /tmp/sel_$(date %Y%m%d).txt # 再收集系统日志 journalctl -b -1 --no-pager /tmp/last_boot.log dmesg -T /tmp/dmesg_$(date %Y%m%d).txt # 最后记录RAID卡状态如果有RAID卡工具 storcli /c0 show all /tmp/raid_status.txt这里强调顺序SEL在最前面因为管理口日志不受系统重启影响但越早导出越完整。系统日志在重启前导出一旦重启-b -1的内容还在但内存里的dmesg会丢失。RAID状态务必在重启前查看很多RAID卡在重启后会重新同步原始失败信息可能被覆盖。这几步做完故障处理才有依据后面不管是换硬件还是提工单都拿得出证据。注意故障处理的第一步永远是采集证据不是重启。SEL日志和RAID状态必须在重启前导出错过这个窗口很多关键信息就永久丢失了。3.3 重启、拔插、替换处理故障的“三板斧”与生效边界运维圈里流传的“三板斧”是重启、拔插、替换简单有效但也有边界。重启能解决临时性软件故障和驱动卡死但解决不了硬件损坏拔插能解决接触不良但解决不了器件老化替换能解决单点故障但替换前必须确认备件型号和固件兼容。搞不清边界三板斧就是三把坑。我处理故障时会给“三板斧”加两个前置条件。第一重启前必须确认RAID卡状态和硬盘状态系统盘所在RAID组里有盘离线时盲目重启可能触发重建或导致系统起不来。第二拔插前必须确认槽位和防呆设计戴防静电手腕带断电操作比带电拔插安全得多除非是设计为热插拔的部件。这两个条件写进维护文档后新人出错的概率会低很多。替换也有讲究。换硬盘前先确认热备盘状态、确认新盘容量和转速不低于原盘换电源前确认新电源功率不低于原模块换内存前确认新内存的规格和rank数与现有内存匹配。每一步操作都要在维护文档里记录替换下来的旧件贴上标签保存一段时间别急着丢——有时候换完后问题还在旧件还能提供线索。4. 用文档驱动运维把维护经验沉淀成一份可复用的检查单很多团队的维护文档是故障发生后补写的平时没人看出事了才翻。真正有效的维护文档是日常就在更新、故障时能直接照着做的东西。这一章讲怎么把文档建起来重点不是模板而是让文档真正服务于下一次故障处理。4.1 维护文档的骨架从设备台账开始没有设备台账维护文档就是空中楼阁。台账是每一台服务器的“身份证”字段不用太多但关键信息不能少。字段太多会没人维护字段太少又起不到作用平衡点大概就是下面这几项字段示例说明设备编号SRV-01唯一标识机柜标签一致序列号SN开头字符串保修和备件查询用硬件配置CPU/内存/硬盘/RAID卡型号变更时同步更新固件版本管理口、BIOS、RAID卡固件升级后当天更新业务用途数据库/应用/存储决定维护窗口网络信息管理口IP、业务IP故障时登录入口维保状态在保/过保、备件位置决定替换策略台账建议用表格维护每个机柜一张服务器变化时当天更新。序列号尤其重要报修或申请备件时都要用别等故障了再开机箱去找。备件位置这一项容易被忽略但对故障处理速度影响很大知道备件在哪个柜子哪一层比临时打采购电话快得多。4.2 操作步骤的写法让新人照着做也不会出错维护文档里最值钱的部分是操作SOP特别是故障处理步骤。我见过的失败SOP有两种一种是只写“更换故障硬盘”六个字等于没写另一种是写了几十页原理操作时找不到重点。合格的SOP应该包含五部分目标、前置条件、操作步骤、预期结果、异常处理。前置条件尤其重要它决定了新人能不能安全开始操作。以更换故障硬盘为例一个可复用的SOP是这样写的确认故障盘槽位、序列号登录管理口确认该盘处于离线或降级状态。检查RAID组内其他盘状态正常有热备盘则确认热备已顶替。在管理口界面点亮故障盘定位灯物理确认槽位无误。断电或热拔插取下硬盘装入新盘确认新盘容量和转速不低于原盘。登录RAID卡工具确认新盘被识别触发重建并观察进度。重建完成后更新维护文档中的硬盘信息。写得细不等于啰嗦关键是把“怎么判断正确”写进去。比如第2步就是血泪经验换来的很多新人拿到告警就拔盘拔完后发现其他盘也快不行了。预期结果和异常处理也要有新盘不识别怎么办、重建失败怎么办、定位灯不亮怎么办每种情况给一句话处理建议就够不需要长篇大论。4.3 版本记录与变更回溯文档是故障处理的后悔药故障处理时最痛苦的事是不知道系统最近改过什么。服务器不会无缘无故出问题很多故障的根因是前一天升级了固件、更新了驱动、调整了BIOS参数。如果没有变更记录排查就像大海捞针有了记录先看最近一次变更范围立刻缩小。这也是为什么我把变更记录称为“后悔药”——出事的时候它是唯一能让你快速回到问题起点的东西。变更记录表建议包含日期、变更内容、变更前版本、变更后版本、操作人、审批人、结果备注。每次变更后当天更新不要攒到月底。还有一个容易被忽略的动作变更完成后立即做一次巡检基线采集作为回滚判断的参照。这样如果变更后一周内出现异常可以把当前数据和基线对比快速决定是否回滚而不是靠感觉猜。5. 服务器维护避坑指南五个典型翻车场景与处置记录这一章写五个典型的翻车场景每条按“现象→原因→解决”来写都是我见过或处理过的高频问题。如果你能避开这五个坑服务器维护的大半风险就控住了。5.1 RAID降级后直接重启系统直接起不来现象一块硬盘离线RAID组降级值班同事没细看就直接重启结果系统起不来进恢复界面发现另一块盘也离线了。原因单盘离线后RAID组其他盘往往也处于亚健康状态重启时的读盘压力会加速坏盘掉线导致故障扩大。解决硬盘离线后先登录管理口和RAID卡工具确认其他盘SMART状态再决定操作。需要重启时严格执行先导出RAID状态和SEL日志再重启。这个顺序写进文档能避免大多数RAID翻车。5.2 升级固件后风扇全速转温度反而升高现象升级管理口固件后风扇转速策略变化风扇持续全速运转噪声变大CPU温度比升级前还高了几度。原因新固件默认的调速策略和当前硬件组合不匹配固件版本之间不是简单的“新版更好”版本组合需要对齐。解决升级前备份当前固件记录传感器基线。升级后出现异常就回退到上一版本回退后再对照基线确认温度恢复。固件升级这件事慢就是快做好回退预案再动手。5.3 SMART报warning没处理一周后硬盘彻底失效现象硬盘SMART状态显示warning系统日志有坏道报错值班同事看系统还能跑就没处理结果一周后盘彻底掉线RAID重建耗时太久。原因把SMART warning当成“偶发告警”以为重启或观察几天会自己消失实际上SMART告警是硬件持续性的不会自愈。解决看到Current_Pending_Sector非0或Reallocated计数增长直接安排更换不要赌运气。巡检时把SMART计数单独列出来和上次巡检对比增长就是信号。5.4 清灰后开机黑屏折腾半天才找到原因现象机房清灰后服务器无法开机管理口显示已上电但黑屏反复插拔电源线也没解决最后发现是内存没插到位。原因清灰时机箱搬动、部件拆装容易导致内存或电源插头松动主板自检不过表现就是“有电但黑屏”。解决清灰后开机前逐根按压内存到卡扣弹起检查电源线、硬盘数据线、RAID卡和网卡是否插到位。先最小化配置点亮单内存、单电源再逐步接回其他部件能快速定位松动点。5.5 导出日志文件打不开白忙活一场现象故障现场从管理口导出日志事后在电脑上打开时提示格式错误或文件大小异常证据链断了一截。原因浏览器直接“另存为”管理口页面拿到的是网页而不是日志文件或者导出过程网络中断文件不完整。解决用管理口自带的导出功能下载不要手动另存页面。大日志分段导出导完检查文件大小和末尾是否有结束标记。保存后第一时间解压打开验证别等故障处理时才发现文件有问题。6. 进阶一条命令生成巡检快照把维护文档变成自动化的底稿维护文档不能只靠手动填写日常巡检的重复内容完全可以脚本化。我习惯写一个巡检快照脚本每次执行后生成一个带时间戳的文本文件内容包含主机信息、传感器读数、硬盘SMART关键计数和最近的系统错误日志。这个文件既是巡检记录也是维护文档的底稿还能在故障时快速对比“上一次正常是什么样”。#!/bin/bash # 巡检快照把关键硬件状态汇总到一个文本文件用于日常维护留痕 SNAPSHOT/var/log/hw_check_$(date %Y%m%d_%H%M%S).txt { echo 巡检快照 $(date) echo 主机名: $(hostname) # 序列号通常来自主板DMI信息不同厂商字段略有差异 echo 序列号: $(dmidecode -s system-serial-number) echo --- CPU温度与风扇转速 --- # sensors命令输出因主板和监控芯片而异抓关键词即可 sensors | grep -iE Package|Core|fan[0-9] echo --- 硬盘SMART关键计数 --- # 按实际磁盘列表调整生产环境建议从/etc/fstab解析设备名 for disk in /dev/sda /dev/sdb; do [ -e $disk ] || continue echo 磁盘: $disk smartctl -a $disk | grep -E Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable done echo --- 24小时内系统错误日志 --- journalctl --since 24 hours ago -p err --no-pager | tail -30 } $SNAPSHOT echo 快照已生成: $SNAPSHOT脚本本身不复杂关键是几个参数的意义。-p err只取错误级别及以上的日志排除info和warning的噪声tail -30控制错误日志条数避免文件无限膨胀dmidecode -s system-serial-number读取整机序列号方便多台服务器巡检后按序号归档。磁盘列表建议根据实际配置修改生产环境可以从/etc/fstab或/proc/mounts动态获取避免漏掉新增的盘。这份巡检快照落地后日常维护就变成了“跑脚本、对基线、存归档”三步。跑完脚本把关键数值和上一份快照做对比有偏离就查原因没偏离就存档。故障发生时先跑一次脚本生成当前快照再翻出上一份正常快照能立刻看出是哪个部件出了问题。这是我做服务器维护几年下来最实用的习惯——把玄学变成数据把经验变成文档出问题时手里永远有底牌。希望帮到你。本文还有配套的精品资源点击获取