★ FEATURED ARTICLE 简介一份面向系统运维与数据库管理人员的服务器日常巡检规范文档聚焦数据库服务器和WEB应用服务器两大场景明确磁盘空间、日志文件、维护计划、计划任务及IIS运行日志等检查项可帮助读者建立标准化巡检流程提前规避因磁盘不足、日志异常增长或任务失败引发的中断与数据风险。文档共1个docx文件约23KB内容紧凑、结构清晰。针对HIS库与CPHS库列举了具体的计划任务如清除门诊临时数据、门诊医生数据统计、高血压首诊记录核实、索引重建与视图刷新等并给出WEB端CPHSOUT日志、LOG日志及Windows事件查看器的检查思路便于按步骤落地执行。已有689人学习下载适合需要完善日常巡检清单或梳理数据库与Web服务器运维规范的技术人员参考也可作为团队交接与内部培训的基础材料。1. 服务器巡检规范文档为什么你的服务器总在深夜出事管过服务器的人都懂一个场景凌晨三点值班手机被监控告警轰醒等你连上去负载和磁盘早就不是正常值了。这时候你翻出一份《服务器日常巡检规范.docx》却发现里面只写了“定期检查服务器状态”这种话。这不是文档少而是规范没写到点子上。这个标题背后的真实交付物不是一份漂亮的表格而是一套能强制执行的规则哪些指标必须看、多久看一次、看到什么数算异常、异常之后找谁、什么时候升级。这篇笔记就从一线运维视角把这套规则拆开落到命令、阈值和踩坑上。适合刚接手服务器环境的新手也适合管着几十台机器但巡检全靠感觉的老手。2. 巡检规范里最该写死的四件事对象、周期、阈值、处置流程一份巡检规范的核心骨架不是抄来的检查项模板而是四个问题的明确答案检查什么、多久查一次、查到什么程度算异常、异常之后走什么流程。很多团队拿到的巡检文档看着很厚实际上四个问题里至少有三个是含糊的。先说结论一份能落地的巡检规范建议不超过十页最好用表格把“检查项、命令、判定标准、处置动作”四列写齐否则执行的人翻两页就放弃了。2.1 巡检对象怎么圈定硬件、系统、应用三层清单巡检对象不要一开始就列几十个细项先把范围分成三层。第一层是硬件层包括电源状态、磁盘健康、网卡错误计数、温度。第二层是操作系统层包括负载、内存、磁盘空间、inode、文件句柄、时间同步。第三层是应用层包括关键进程、端口监听、日志报错、证书有效期、业务健康接口。三层缺哪层都会出事只查应用不查磁盘日志一膨胀应用先挂只查系统不查业务接口进程活着但请求超时照样没人知道。常见误用是把清单写成“检查服务器运行状态”“检查各项指标是否正常”这种含糊描述。等于没写。正确做法是每个检查项后面跟上一条可直接执行的命令比如负载检查对应uptime磁盘检查对应df -h进程检查对应systemctl status 服务名。执行的人不需要思考照着抄命令、对阈值规范才可能被执行。2.2 巡检周期怎么定L1到L4四级频率与时间点设计周期不能一刀切全做每日巡检也不能把重要的事拖到每周才看。我一般按影响程度把巡检分成四级级别周期覆盖范围执行方式投入参考L1每日负载、内存、磁盘、关键服务存活、昨日告警事件脚本自动采集 值班人晨检约10分钟L2每周日志错误统计、证书有效期、时间同步偏差、备份结果、临时文件清理值班人执行并写周报约30分钟L3每月容量趋势、补丁与固件、历史告警复盘、应急预案走查运维负责人主导半天L4每季度全量硬件自检、冗余与故障演练、季度容量规划运维团队 相关方1到2天时间点设计是另一个容易翻车的地方。很多人习惯把巡检设在凌晨低谷因为那时候业务不忙操作最安全。但凌晨的负载、内存、连接数都处于全天最低水平你看到的永远是“最好的一面”。正确做法是每台服务器至少覆盖两个巡检时间点一个落在业务高峰一个落在低谷。数据库服务器可以加一个午间高峰巡检Web服务器则看晚间流量曲线。2.3 阈值与处置流程先采两周基线再定预警与升级线阈值最忌讳在部署第一天就拍脑袋写死。常见做法是上线前先跑两周裸奔巡检只记录不告警把正常水位摸清楚。比如某台机器平时内存占用就在70%到80%之间波动那预警线就不能定在70%要定到85%以上。基线采集是写规范前最值得花时间的一步能省掉后面大量误报。处置流程要明确升级路径和时限。我通常把异常分成三档S1观察项记录数值并对比下个周期S2处理项要求当班人限时处理比如2小时内解决S3升级项业务受损或半小时内无法定位的直接上报并拉相关团队。规范里还必须写清每档的判断标准因为值班人最怕的不是干活而是拿不准“这算不算严重”。标准写得越具体值班决策越果断。3. 硬指标巡检CPU、内存、磁盘、网络的阈值设定与异常判定硬指标是巡检的地基但不只是“看一看高不高”而是要理解每个指标背后的运作逻辑。下面四个小节按我平时巡检的优先级排序每个都给出实际命令、参考阈值和判定思路。注意阈值是参考值生产环境以你自己采的基线为准。3.1 CPU巡检先看负载与饱和再看利用率CPU巡检第一眼看的不是百分比而是uptime里的 load average。这三个数分别代表过去1、5、15分钟的平均活跃进程数。判断负载合不合理要看它除以 vCPU 数量的比值参考线是0.7达到1.0说明请求开始排队持续15分钟以上还在1.0附近徘徊就说明CPU饱和了需要排查慢任务或扩容。利用率指标要看top里的 us用户态、sy内核态两项。us跑高常见于业务计算密集或死循环sy跑高则要警惕内核态CPU超过30%通常意味着有频繁中断、上下文切换或驱动异常。注意一个常见误读单核满载在多核机器上显示只有十几%百分比不高但load可能已经很高了。所以CPU告警必须同时绑两个条件利用率突增 或 load/vCPU 超线单看哪个都会漏报。3.2 内存巡检MemAvailable比free列更可信内存检查命令是free -h但别只看第一行的 free 列。Linux 内存回收机制比较激进cache 会在需要时自动释放free 低不代表内存不够。这里有个经常坑人的点free列的数值在低内存压力下会很小制造出“内存不足”的假象。真正可信的是 MemAvailable 列它已经把可回收的 cache 算进去了。我的参考逻辑是MemAvailable 占总内存比例低于20%时关注低于10%且持续不回升就告警。另一样重点看 swap 的 used 列swap 偶尔占用几百兆可以理解但如果 swap used 连续三个周期持续增长说明内存回收已经跟不上分配速度这是内存压力的前兆比立刻看阈值更值得重视。内存告警处理不要急着加内存先查有没有内存泄漏进程用ps aux --sort-%mem按内存占用排序找大头。3.3 磁盘巡检空间与inode要一起看容量要算趋势磁盘是故障率最高的巡检项。基础检查是df -h看空间使用率我的参考线是使用率达到85%关注92%告警98%属于紧急处理。为什么不定在95%再告警因为磁盘不是满到100%才出事写大文件、临时文件、日志突发增长都可能让剩余空间在几小时内耗尽预留缓冲比卡到极限再救要稳得多。另一个极其隐蔽的坑是 inode 耗尽。df -h显示还有空间但应用报“No space left on device”大概率是df -i的 inode 满了。大量小文件、Docker容器频繁创建删除、邮件队列堆积都会吃掉inode。巡检规范里必须把df -i和df -h并列写漏一个都是定时炸弹。除此之外磁盘巡检还要带趋势思维把每周的使用率数字记录下来算一算按当前增长速度多久会写满提前一个月做扩容或清理别等到85%告警了才开始想方案。3.4 网络巡检丢包、重传与带宽饱和的判定线网络巡检最容易做表面功夫。ping能通不代表网络健康内网丢包率超过0.1%就已经会影响应用超时特别是数据库和分布式存储这类对网络敏感的组件。巡检时建议看ip -s link里的错误计数和丢包计数如果数值在持续增长而不是静止就该排查交换机端口或网卡了。TCP重传率是判断网络质量的好指标。可以看/proc/net/netstat里的重传段比例也可以直接用ss -s看汇总信息。参考线重传率超过0.5%关注超过2%告警配合应用层的请求超时一起判断。带宽饱和则用iftop或nload看实时流量饱和不一定会丢包但会体现在连接超时和延迟飙升上。如果业务流量有明显早晚高峰把带宽峰值的记录纳入巡检对容量规划帮助很大。4. 容易被漏掉的应用层巡检日志趋势、端口监听、证书有效期与时间同步基础硬指标查完很多巡检就结束了。但根据我的经验真正造成业务中断的往往不是硬件而是应用层的“软状态”日志悄悄膨胀、证书过期没人知道、多台机器时间不一致导致数据错乱。这一层平时不显眼一出事就是大事故。4.1 日志巡检不查单个报错要看同类报错的增长趋势日志巡检最忌讳看到ERROR就去搜这是什么意思。单个报错可能只是一个无关紧要的异常真正有价值的是“同类报错在单位时间内的出现频率”。我通常每天用一行命令把当天的错误数统计出来存成历史记录grep -c ERROR /var/log/app/应用日志.log这条命令只看数量不看内容。关键是把昨天的数字拿出来对比如果今天比昨天翻了五倍才需要进一步看具体报错内容如果数量稳定甚至下降说明服务运行平稳。日志巡检的第二个重点是被忽略的轮转配置logrotate配了按天切割但没配压缩或者旧日志保留周期太长都会导致日志目录缓慢吞掉磁盘。每季度检查一次 logrotate 配置和磁盘巡检配合能拦截掉大量“磁盘被日志写满”的凌晨事故。4.2 进程与端口服务active不代表服务健康很多巡检规范写着“检查服务是否正常”于是值班人就跑一条systemctl status 服务名看到 active (running) 就划勾。但服务进程活着和业务能正常响应是两码事。我见过 Nginx 进程活得好好的上游应用已经挂了Nginx 返回的全是502也见过数据库端口还在监听但连接数打满新请求全部排队超时。所以进程巡检要分两步第一步用systemctl is-active 服务名确认进程状态第二步用ss -lntp确认关键端口在监听。更进一步对核心服务加一条拨测本地请求健康接口比如curl -s -o /dev/null -w %{http_code} http://127.0.0.1/health返回码非200即视为异常。拨测的成本极低但能把“进程活着但业务不可用”这类假健康状态揪出来。僵尸进程也值得单独看一眼如果ps aux里出现多个僵尸进程且持续不回收说明父进程有bug迟早会拖垮那个应用。4.3 时间同步与证书有效期两个最不起眼的定时炸弹时间同步问题平时一点存在感都没有但一旦多台服务器之间出现偏移分布式系统就开始出诡异故障。现象很典型日志时间对不上、签名验证失败、任务调度重复执行。巡检命令是chronyc tracking或ntpq -p重点看系统时间与时间源的偏移量超过50毫秒就要警惕超过200毫秒基本属于高危。排查时先确认时间同步服务是否在跑再看是不是个别机器访问不到时间源。证书有效期是另一个典型的“慢变量灾难”。证书不会突然失效但它的过期是倒计时完全可以提前处理。每月的L2巡检里加一条批量检查openssl s_client -connect 127.0.0.1:443 -servername 你的域名 /dev/null 2/dev/null | openssl x509 -noout -enddate把输出里的 expiry 日期统一收集成一张表。参考线是剩余天数少于30天就该走证书更新流程了。多台机器的证书分散在业务同学手里的话更要提前收集监控因为证书更新需要协调的时间远比想象中长。5. 巡检落地避坑五个让规范沦为摆设的典型问题规范写得再漂亮落地时还是会遇到各种真实阻力。这一章列五个我在不同环境里反复见过的坑按“现象、原因、解决”的格式写方便你直接对照自己的环境排查。5.1 清理了日志磁盘空间纹丝不动现象磁盘使用率告警值班人删了一堆日志文件df -h一看空间一点没释放。原因被删除的文件还被某个进程持有句柄文件已经被标记删除但进程没关闭它空间不会归还。解决先lsof | grep deleted找到持有着句柄的进程PID确认进程身份后重启该进程或让服务重新加载日志文件。如果日志服务在持续写入旧句柄重启前记得做轮转配置调整否则同样的问题会再次出现。5.2 CPU告警响了一夜业务却一切正常现象监控平台不停报CPU高运维打开面板一看确实有个核跑满但业务无感、响应正常。原因告警阈值只写了“CPU利用率大于80%”没按cCPU数量折算。在一个16核机器上单核满载的利用率只有6.25%按百分比告警永远触发不了而一个单核跑满的任务如果恰好那台机器只有4核按25%的阈值倒是会触发但业务本身可能只是正常的批处理。解决把CPU告警改成综合条件优先以 load average / vCPU 数量作为判定依据利用率只做辅助参考。5.3 每天固定时间巡检高峰问题永远看不到现象巡检记录天天全绿隔两周某个白天业务高峰时数据库连接数爆掉服务直接不可用。原因巡检任务全部安排在凌晨业务低谷凌晨2点的连接数、负载、内存使用都处于全天最低值你看到的是“最乖”的服务器。解决每台核心服务器至少设两个巡检时间点一个落在业务高峰一个落在低谷高峰期哪怕只看十分钟数据都比低谷巡一天有价值。5.4 巡检表勾满“正常”容量照样爆掉现象巡检表上每个检查项都是“正常”或“OK”但三个月后磁盘突然告警一查历史记录没有任何数据可参考。原因巡查表设计成了勾选项执行人只需要打勾没有要求填具体数值。没有数值就没有趋势容量规划、性能劣化分析全都无从谈起。解决巡检表里每个指标必须记录具体数值哪怕只是简单照抄uptime和df -h的输出也要落到表格里。只有数值化的巡检记录才能在故障发生时提供对比基线。5.5 磁盘告警线拍到95%等发现已经IO卡死现象告警阈值设成磁盘使用率高于95%才通知结果某天业务先出现写入超时随后机器卡到连SSH都慢。原因95%时剩余空间可能只剩几十GB大文件写入、应用临时文件生成、日志突发都可能把它填满而且高水位通常伴随IO性能下降等告警发出时已经连操作空间都没有了。解决把关注线提前到85%告警线提前到92%同时记录每周使用率增长量反向推算预计写满日期。记住磁盘告警的目的是在还能操作的时候介入而不是在临界点给你发一个通知。6. 从规范到巡检体系把L1巡检做成自动日报用复盘给规范打补丁规范文档只是起点真正让巡检跑起来的是自动化。我建议的第一步是把L1每日巡检做成一分钟出结果的脚本挂在定时任务里每天早上自动生成一份健康快照。脚本输出固定格式异常才需要人介入日常只看一眼数字就行。6.1 把L1巡检项变成脚本日报一个够用的L1脚本不需要引入复杂框架一段bash脚本就能覆盖核心项。下面是我常用的模板按实际服务名替换即可#!/bin/bash # 每日L1巡检输出核心健康快照供值班晨检 # 用法加入cron每天 09:00 执行日志追加到 /var/log/sys_check.log echo $(date %F %T) 巡检快照 echo -- 负载(1/5/15分钟) -- uptime echo -- 可用内存 -- free -h | awk /Mem:/{print 可用:$7 总:$2} echo -- 根分区使用率 -- df -h / | awk NR2{print 使用率:$5} echo -- 关键服务状态 -- systemctl is-active nginx redis-server echo -- 证书剩余天数 -- echo | openssl s_client -connect 127.0.0.1:443 -servername your-domain.com 2/dev/null \ | openssl x509 -noout -enddate这段脚本的精髓在于只输出“需要人看的数字”不做花哨处理。把输出追加到同一个日志文件每周自动形成一份趋势记录。后续要扩展也很方便在-- 关键服务状态部分加一行curl -s -o /dev/null -w %{http_code} http://127.0.0.1/health就成了健康拨测。cron 配置建议错开整点选在业务相对稳定的时刻比如上午9点半。6.2 每次故障复盘第一件事是给规范打补丁运维工作的进步来自复盘而复盘的主要产出应该是更新巡检规范。每次出故障后我都习惯在文档里加一行变更记录日期、变更项、原因。比如这周因为日志轮转配置出问题导致磁盘写满那下周的规范里就要加一条“每季度检查logrotate配置”如果这次故障是负载翻了十倍但告警没触发那阈值设计就要重新调整。规范文档最怕写完就不动三个月后它就和真实环境脱节了。一份文档如果每次故障后都更新几轮下来它就变成了运维团队真正的护城河。我这些年养成的习惯是在一次故障归零之前先把“这次学到什么”写进巡检规范。文档不改规范就只是一份docx文档持续在改它才真正替你值班。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
