简介面向IT运维团队与驻场服务管理人员的实操型文档系统梳理驻场技术服务范围内的日常系统巡检、监控分析、变更与问题管理、备份恢复、资产管理、安全事件处置及服务报告等工作模块。内容具体到Linux资源负载、网络端口、日志错误、RAID/IPMI硬件健康、Tomcat与Ceph服务状态等巡检要点并明确监控报警分析、漏洞修补、备份策略制定、应急响应等执行要求可帮助读者建立规范化运维流程、完善巡检清单与服务报告模板。资源为单个docx文档约34KB正文含系统运维服务日巡查表示例可直接参考并改编为团队日常运维表单。已有80人学习适合正在准备IT运维驻场项目方案、需要细化运维交付物或制定运维标准化文件的读者。1. 驻场运维服务内容本质是一套可执行的SOP我拿到一份《IT运维驻场服务内容.docx》这类文档在驻场服务合同里很常见把日常巡检、监控分析、变更管理、备份恢复、安全事件处置、服务报告全部列成了交付物清单。它的价值不在文档本身而在“能不能变成每天可执行的SOP”。实际驻场工作中很多团队把巡检做成“点到为止”但甲方要的是可量化、可追溯、可复盘的活动。这份文档适合三类人正在写驻场服务方案的售前、刚接手驻场项目的运维工程师以及想把自己的巡检流程做成自动化工具的人。下面按我自己的执行顺序拆解这份内容。2. 日常巡检怎么拆系统层、硬件层、业务层2.1 巡检对象分层从“看监控”到“看台账”文档里把巡检分成了 Linux 系统层、硬件健康状态、重点保障业务服务三个模块。我一般不会一上来就敲命令而是先做对象清单把每台主机的角色、IP、服务、负责人列清楚再按照三层逐项巡检避免漏项。系统层看 CPU/MEM/HD 负载及利用率、内核版本、系统运行时间、登录用户、网络接口状态、端口监听、进程状态、日志错误信息。硬件层看 IPMI、RAID、温度、风扇、固件、驱动状态。业务层看 Tomcat/HTTPD/Nginx 集群、Ceph OSD、Pacemaker、云平台控制节点、云管平台、Ansible Tower、ITIL 等。三层对应不同的判断标准巡检层关注对象判断标准系统层CPU、内存、磁盘、网络接口、端口/进程、日志指标不超阈值日志无新增错误硬件层IPMI、RAID、温度、风扇、固件、驱动RAID 状态 Online温度在规格内无错误事件业务层Tomcat/HTTPD/Nginx、Ceph OSD、Pacemaker服务状态 Active集群无脑裂分层的好处是出问题时能快速定位是哪一层而不是把业务异常和系统异常混在一起排查。比如 Ceph 存储利用率超过 80% 时OSD 可能出现慢请求业务层现象是写入超时但根因在存储层巡检时两层都要留证据。2.2 巡检命令和参数速查巡检要落到命令上以下这组 Linux 常用命令基本覆盖了日巡检 80% 的场景# 负载、系统运行时间、登录用户数 uptime # 内核版本和操作系统版本 uname -r cat /etc/os-release # 内存和Swap使用情况 free -m # 磁盘空间、文件系统类型和inode df -hT df -i # 块设备IO状态间隔1秒统计3次 iostat -x 1 3 # 网络接口状态、丢包和速率 ip -s link # 网关连通性和丢包率 ping -c 5 -i 0.2 10.0.0.1 | tail -3 # 监听端口和对应进程 ss -lntp # 关键服务运行状态 systemctl status sshd ntpd crond # 本次启动后的错误日志 journalctl -p err -b这套命令的参数需要理解清楚不然容易误判。uptime看的是 1/5/15 分钟负载多核机器不能只看数字小于 18 核机器到 8.0 才算满载文档里“Avg CPU Load 80%”应该指所有核归一后的使用率。free -m以 MB 输出注意看 available 列不要看到 buffer/cache 高就杀进程。df -hT带文件系统类型方便分辨 xfs、ext4、tmpfsdf -i查 inodeinode 满了同样会报“No space left on device”但df -h还有空间。iostat -x里的%util是磁盘忙碌程度SSD 上高 util 不一定代表性能瓶颈要结合延迟看。ss -lntp用来代替旧命令netstat -lntp能看到监听端口对应的完整进程名。ping -c 5 -i 0.2是驻场网络运维中常用做法发 5 个包、间隔 0.2 秒避免测试时间过长看丢包率和平均延迟。硬件状态巡检不能只看操作系统还要通过带外管理口确认常见命令是# IPMI传感器温度和电压 ipmitool sensor list # IPMI系统事件日志 ipmitool sel elist # MegaRAID控制器逻辑盘状态 megacli -LDInfo -LALL如果服务器是戴尔可以用omreport storage vdisk华为和浪潮环境通常用storcli64替代megacli。RAID 状态必须看清出现磁盘 failed 要第一时间安排换盘否则第二块盘故障会直接丢数据。2.3 巡检表设计把“正常/异常”改成量化门槛文档示例中的“系统运维服务日巡查表”是“正常口异常口”勾选模式。实际操作中纯勾选没有意义除非把“正常”的定义量化。我给甲方做巡检表时会保留勾选列但后面追加“当前值”和“阈值”两列。巡检项阈值建议检查命令判断逻辑Avg CPU Load按核数归一后 80%uptime负载/核数持续超过 0.8 需关注Avg Disk Usage 80%df -hT超过 80% 就要清理或扩容Response Time 500mscurl -w %{time_total}页面或 API 接口响应时间Ceph 存储空间利用率 80%ceph df超过 80% 会影响数据均衡网络接口状态Upip link物理口和逻辑口都要 Up阈值不是一成不变。比如磁盘使用率 80% 可能是因为/var/log被日志撑满也可能因为备份文件没清理所以巡检表里最好再带一列“处置动作”。Solarwinds、Ansible Tower 这类系统运维工具自身也要巡检工具挂了告警会跟着失效反而比业务故障更隐蔽。2.4 巡检里最容易忽略的细节文档里把 SELinux、Firewall、SSH、NTP、Crontab 单独拿出来是有原因的。NTP 时间漂移会导致告警时间不准确、证书校验失败日志审计也串不起时间线。SSH 配置改了没重启连接直接被拒。Crontab 脚本里没有加MAILTO任务失败根本不通知。SELinux 状态和应用不匹配时端口是通的但连接被拒绝这类问题最耗时。我的巡检习惯是每次最后做一次时间一致性检查用chronyc tracking或ntpq -p看偏移量确认crond服务是 active并抽查最近两天的/var/log/cron。驻场服务不是把命令跑完而是要形成“检查-记录-跟进”的闭环异常项如果当时没解决必须进问题台账。3. 监控、告警与安全事件处置把“盯屏”变成闭环流程3.1 监控系统的告警分级与数据源文档里提到通过资源监控系统监控网络、硬件、安全、系统、服务、端口记录并按重要性级别分类。现在的驻场环境里监控工具通常不止一套。Solarwinds 负责网络设备和链路云管平台看虚拟机状态Ansible Tower 看作业执行情况ITIL 管工单流程备份系统看作业状态日志平台做审计。这些数据源要按“基础设施、平台层、业务层”归好类然后给告警定义等级级别定义响应时限P1核心业务中断、数据丢失立即处理15 分钟响应P2服务性能显著下降1 小时响应4 小时解决P3非关键异常、资源超阈值当天处理P4提示信息可后续观察记录并周报告警分级和文档里说的“按重要性级别分类形成书面报告”是一个意思。关键是别把 P4 的邮件也当 P1 去轰炸甲方否则真正出大事时没人看消息。3.2 告警分析从“报出”到“关闭”的步骤监控只是入口动手处理才是驻场价值。完整闭环是收到告警 → 确认影响范围 → 查日志和监控图 → 定位根因 → 执行临时措施 → 修复 → 复盘记录。一个常见场景是云平台告警“虚拟机内存使用率超过 90%”。先登录虚拟机或云管平台看是哪个进程占用命令是ps aux --sort-%mem | head -15。再确认最近是否有业务发布或任务变更。然后查系统日志比如journalctl -u kubelet和tail -n 200 /var/log/messages。如果内存持续增长不要急着加内存先用top看进程是否有泄漏。处置完以后写分析报告说明结论、证据、优化建议。文档里说的“对监测和报警记录进行分析、评审发现可疑行为形成分析报告”对应到操作上就是上面这套动作。报告不是流水账要包含时间线、影响面、根因、临时措施和长期措施。3.3 安全事件处置的常见动作安全事件处置在驻场文档里占了不少篇幅涉及 DDoS 攻击源和数据量查看、防火墙内外网管控、堡垒机安全访问控制、综合日志审计、漏洞扫描、网页防篡改。我一般先看三样东西当前连接分布、边界设备日志、账号登录记录。# 查看当前TCP连接数和来源IP Top20 ss -ntu | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -20 # 抓取HTTP入口流量保存文件便于分析 tcpdump -i eth0 -nn port 80 -c 500 -w /tmp/http_capture.pcap # 检查登录失败记录 last -f /var/log/btmp | head -20 # 查看当前登录会话 whoss -ntu把 TCP 和 UDP 连接都列出来截取第 5 字段的 IP 部分统计后能快速判断是否有单一 IP 发起大量连接。tcpdump抓包时用-c 500限制只抓 500 个包-w写文件避免长时间抓包影响业务抓完的文件要归档留作证据。last -f /var/log/btmp显示多次登录失败的记录如果一个 IP 刷了上千次基本可以判断是暴力破解。文档里提到的“查看攻击源和数据量 DDoS”一般要从防火墙或流量分析平台里看攻击源 IP、攻击类型、峰值带宽。如果还没有专门平台可以先用ifstat或nload看入口流量再配合tcpdump定位来源。3.4 基线配置和应急响应文档怎么沉淀驻场文档要求在安全事件处置后制作《系统运维基线配置》和《系统故障应急响应方案》。我接触过的项目里这两份文档经常是“写了就扔”没有和实际环境匹配。基线配置至少包含账号权限策略、密码复杂度、SSH 端口和协议、防火墙默认策略、日志保留周期、NTP 时间源。应急响应方案不用写一百页把角色分工和关键操作写清楚就够了。比如“谁负责判断影响谁负责执行封禁谁负责通知甲方”然后附上各系统的重启、回滚命令。每次安全事件处置后把最终处置步骤更新到知识库和应急响应手册里而不是另起一个新文档这样文档不会烂尾新人也能直接照做。4. 变更管理、补丁与备份恢复驻场最见功力的部分4.1 变更管理的范围和“先备份再变更”原则驻场运维里变更管理最容易出事故。文档里列出的变更包括新的业务系统搭建、KVM 虚拟系统创建、网络路由配置、防火墙配置、数据库部署、应用软件部署、RPM 包安装/卸载/升级、系统核心软件包升级、环境变量参数变更等。无论是哪一类我的原则都是“变更前必须备份变更中记录操作变更后验证结果”。以 KVM 创建虚拟系统为例常见做法是先用qemu-img create规划磁盘再用virt-install安装系统。为了降低风险先确认宿主机的存储池和网络桥接状态再创建虚拟机不然虚拟机可能出现桥接不通或者磁盘 IO 抢占严重。4.2 变更执行记录模板和回滚思路正式的变更管理每次操作前要填一张变更表字段内容变更编号CHG-2025-001申请人和审批人甲方运维负责人变更原因日志磁盘扩容影响范围相关服务短暂重启执行步骤1. 备份配置 2. 调整参数 3. 重启服务回滚操作使用备份文件还原重新加载配置验证命令df -h、systemctl status xxx回退条件验证失败立即回滚实际变更时把要改的配置文件先复制一份备份cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) vim /etc/ssh/sshd_config sshd -t systemctl reload sshdsshd -t用来测试 SSH 配置语法不报错再执行systemctl reload重载服务。参数$(date %F)让备份文件名带上日期方便以后回滚。这套思路同样适用于/etc/security/limits.conf、/etc/hosts、/etc/profile等文件。改完/etc/profile后记得用source /etc/profile重新加载或重新登录验证环境变量不要直接在登录会话里乱 source。4.3 备份策略设计从“有备份”到“能恢复”文档要求根据数据重要性和对系统运行的影响确定备份策略定期备份重要业务信息、系统数据和软件系统并且每月提交数据备份报告。我在设计备份策略时先把数据分成几类数据类别备份频率保留周期验证方式系统配置文件每日增量每周全量30 天变更回滚测试数据库数据每日全备binlog90 天每月恢复演练应用数据和日志每日增量180 天抽样校验文件完整性虚拟机和镜像每周全量30 天随机抽取一台恢复备份脚本里不能只做tar或mysqldump要加校验。我一般会在备份后比较文件大小和 md5 值mysqldump -u backup -p --single-transaction --routines --triggers appdb appdb_$(date %F).sql echo appdb_$(date %F).sql backup_manifest.txt md5sum appdb_$(date %F).sql backup_manifest.txt--single-transaction保证 InnoDB 表备份时事务一致不锁业务表--routines和--triggers把存储过程和触发器一起备份。备份文件名和 md5 写到清单里恢复时先校验校验和再导入能减少“备份文件是坏的”的概率。4.4 恢复演练要看时间窗口文档里特别提了“定期执行恢复程序检查和测试备份介质的有效性”。很多环境备份每天都成功但恢复时才发现备份文件损坏或者恢复时间远超预期。驻场工程师需要每季度至少做一次恢复演练。演练时记录实际耗时和计划中的 RTO/RPO 对比。比如数据库每天全备需要 40 分钟恢复却要 6 小时这就是风险。解决方案通常是并行恢复、使用备份存储的更高带宽网络或者把全备拆成多个分片同步恢复。恢复验证后生成“恢复演练记录表”把备份集名称、恢复目标、消耗时间、验证结果列出来。这份表比每天的成功备份日志更有说服力。5. 把驻场文档变成自动化巡检脚本和指标卡驻场文档里最实用的部分就是日巡查表和巡检内容清单。把这两张表变成脚本每天早上自动跑一遍再输出固定格式的报告效率会提高不少。下面是一段基础脚本算是自动化运维的起步写法。#!/bin/bash # 把巡检输出写到带日期的文件方便按周/月归档 REPORTreport_$(date %F).txt { echo 系统巡检 $(date %Y-%m-%d %H:%M:%S) uptime free -m | head -3 df -hT | grep -vE tmpfs|overlay|devtmpfs ss -lntp | grep LISTEN systemctl is-active sshd ntpd crond ceph df 2/dev/null || echo ceph命令不可用或未在执行节点 } $REPORT cat $REPORTgrep -vE用正则排除无关文件系统避免 tmpfs 和容器 overlay 区干扰判断。systemctl is-active后面跟多个服务名会逐个输出 active 或 failed。ceph df只在 Ceph 管理节点执行其他节点会走||分支打印提示脚本不会因为某条命令不存在而中断。随后加入 crontab 定时执行10 9 * * * /opt/scripts/daily_check.sh单独一个脚本还不够要把脚本输出的值和巡检表里的阈值列对应起来。例如增加一段负载判断LOAD$(cat /proc/loadavg | awk {print $1}) CORES$(nproc) if [ $(echo $LOAD $CORES * 0.8 | bc) -eq 1 ]; then echo 负载超过阈值: load$LOAD cores$CORES fi用bc做浮点比较没装bc的环境可以用awk代替。这样脚本不仅生成报告还能在超标时主动告警。把脚本内容和当日报告一起放进原巡检表的“附注”里文档就从静态的勾选表变成了活的工具。本文还有配套的精品资源点击获取 驻场运维服务实践指南：巡检、监控、变更与备份恢复
简介面向IT运维团队与驻场服务管理人员的实操型文档系统梳理驻场技术服务范围内的日常系统巡检、监控分析、变更与问题管理、备份恢复、资产管理、安全事件处置及服务报告等工作模块。内容具体到Linux资源负载、网络端口、日志错误、RAID/IPMI硬件健康、Tomcat与Ceph服务状态等巡检要点并明确监控报警分析、漏洞修补、备份策略制定、应急响应等执行要求可帮助读者建立规范化运维流程、完善巡检清单与服务报告模板。资源为单个docx文档约34KB正文含系统运维服务日巡查表示例可直接参考并改编为团队日常运维表单。已有80人学习适合正在准备IT运维驻场项目方案、需要细化运维交付物或制定运维标准化文件的读者。1. 驻场运维服务内容本质是一套可执行的SOP我拿到一份《IT运维驻场服务内容.docx》这类文档在驻场服务合同里很常见把日常巡检、监控分析、变更管理、备份恢复、安全事件处置、服务报告全部列成了交付物清单。它的价值不在文档本身而在“能不能变成每天可执行的SOP”。实际驻场工作中很多团队把巡检做成“点到为止”但甲方要的是可量化、可追溯、可复盘的活动。这份文档适合三类人正在写驻场服务方案的售前、刚接手驻场项目的运维工程师以及想把自己的巡检流程做成自动化工具的人。下面按我自己的执行顺序拆解这份内容。2. 日常巡检怎么拆系统层、硬件层、业务层2.1 巡检对象分层从“看监控”到“看台账”文档里把巡检分成了 Linux 系统层、硬件健康状态、重点保障业务服务三个模块。我一般不会一上来就敲命令而是先做对象清单把每台主机的角色、IP、服务、负责人列清楚再按照三层逐项巡检避免漏项。系统层看 CPU/MEM/HD 负载及利用率、内核版本、系统运行时间、登录用户、网络接口状态、端口监听、进程状态、日志错误信息。硬件层看 IPMI、RAID、温度、风扇、固件、驱动状态。业务层看 Tomcat/HTTPD/Nginx 集群、Ceph OSD、Pacemaker、云平台控制节点、云管平台、Ansible Tower、ITIL 等。三层对应不同的判断标准巡检层关注对象判断标准系统层CPU、内存、磁盘、网络接口、端口/进程、日志指标不超阈值日志无新增错误硬件层IPMI、RAID、温度、风扇、固件、驱动RAID 状态 Online温度在规格内无错误事件业务层Tomcat/HTTPD/Nginx、Ceph OSD、Pacemaker服务状态 Active集群无脑裂分层的好处是出问题时能快速定位是哪一层而不是把业务异常和系统异常混在一起排查。比如 Ceph 存储利用率超过 80% 时OSD 可能出现慢请求业务层现象是写入超时但根因在存储层巡检时两层都要留证据。2.2 巡检命令和参数速查巡检要落到命令上以下这组 Linux 常用命令基本覆盖了日巡检 80% 的场景# 负载、系统运行时间、登录用户数 uptime # 内核版本和操作系统版本 uname -r cat /etc/os-release # 内存和Swap使用情况 free -m # 磁盘空间、文件系统类型和inode df -hT df -i # 块设备IO状态间隔1秒统计3次 iostat -x 1 3 # 网络接口状态、丢包和速率 ip -s link # 网关连通性和丢包率 ping -c 5 -i 0.2 10.0.0.1 | tail -3 # 监听端口和对应进程 ss -lntp # 关键服务运行状态 systemctl status sshd ntpd crond # 本次启动后的错误日志 journalctl -p err -b这套命令的参数需要理解清楚不然容易误判。uptime看的是 1/5/15 分钟负载多核机器不能只看数字小于 18 核机器到 8.0 才算满载文档里“Avg CPU Load 80%”应该指所有核归一后的使用率。free -m以 MB 输出注意看 available 列不要看到 buffer/cache 高就杀进程。df -hT带文件系统类型方便分辨 xfs、ext4、tmpfsdf -i查 inodeinode 满了同样会报“No space left on device”但df -h还有空间。iostat -x里的%util是磁盘忙碌程度SSD 上高 util 不一定代表性能瓶颈要结合延迟看。ss -lntp用来代替旧命令netstat -lntp能看到监听端口对应的完整进程名。ping -c 5 -i 0.2是驻场网络运维中常用做法发 5 个包、间隔 0.2 秒避免测试时间过长看丢包率和平均延迟。硬件状态巡检不能只看操作系统还要通过带外管理口确认常见命令是# IPMI传感器温度和电压 ipmitool sensor list # IPMI系统事件日志 ipmitool sel elist # MegaRAID控制器逻辑盘状态 megacli -LDInfo -LALL如果服务器是戴尔可以用omreport storage vdisk华为和浪潮环境通常用storcli64替代megacli。RAID 状态必须看清出现磁盘 failed 要第一时间安排换盘否则第二块盘故障会直接丢数据。2.3 巡检表设计把“正常/异常”改成量化门槛文档示例中的“系统运维服务日巡查表”是“正常口异常口”勾选模式。实际操作中纯勾选没有意义除非把“正常”的定义量化。我给甲方做巡检表时会保留勾选列但后面追加“当前值”和“阈值”两列。巡检项阈值建议检查命令判断逻辑Avg CPU Load按核数归一后 80%uptime负载/核数持续超过 0.8 需关注Avg Disk Usage 80%df -hT超过 80% 就要清理或扩容Response Time 500mscurl -w %{time_total}页面或 API 接口响应时间Ceph 存储空间利用率 80%ceph df超过 80% 会影响数据均衡网络接口状态Upip link物理口和逻辑口都要 Up阈值不是一成不变。比如磁盘使用率 80% 可能是因为/var/log被日志撑满也可能因为备份文件没清理所以巡检表里最好再带一列“处置动作”。Solarwinds、Ansible Tower 这类系统运维工具自身也要巡检工具挂了告警会跟着失效反而比业务故障更隐蔽。2.4 巡检里最容易忽略的细节文档里把 SELinux、Firewall、SSH、NTP、Crontab 单独拿出来是有原因的。NTP 时间漂移会导致告警时间不准确、证书校验失败日志审计也串不起时间线。SSH 配置改了没重启连接直接被拒。Crontab 脚本里没有加MAILTO任务失败根本不通知。SELinux 状态和应用不匹配时端口是通的但连接被拒绝这类问题最耗时。我的巡检习惯是每次最后做一次时间一致性检查用chronyc tracking或ntpq -p看偏移量确认crond服务是 active并抽查最近两天的/var/log/cron。驻场服务不是把命令跑完而是要形成“检查-记录-跟进”的闭环异常项如果当时没解决必须进问题台账。3. 监控、告警与安全事件处置把“盯屏”变成闭环流程3.1 监控系统的告警分级与数据源文档里提到通过资源监控系统监控网络、硬件、安全、系统、服务、端口记录并按重要性级别分类。现在的驻场环境里监控工具通常不止一套。Solarwinds 负责网络设备和链路云管平台看虚拟机状态Ansible Tower 看作业执行情况ITIL 管工单流程备份系统看作业状态日志平台做审计。这些数据源要按“基础设施、平台层、业务层”归好类然后给告警定义等级级别定义响应时限P1核心业务中断、数据丢失立即处理15 分钟响应P2服务性能显著下降1 小时响应4 小时解决P3非关键异常、资源超阈值当天处理P4提示信息可后续观察记录并周报告警分级和文档里说的“按重要性级别分类形成书面报告”是一个意思。关键是别把 P4 的邮件也当 P1 去轰炸甲方否则真正出大事时没人看消息。3.2 告警分析从“报出”到“关闭”的步骤监控只是入口动手处理才是驻场价值。完整闭环是收到告警 → 确认影响范围 → 查日志和监控图 → 定位根因 → 执行临时措施 → 修复 → 复盘记录。一个常见场景是云平台告警“虚拟机内存使用率超过 90%”。先登录虚拟机或云管平台看是哪个进程占用命令是ps aux --sort-%mem | head -15。再确认最近是否有业务发布或任务变更。然后查系统日志比如journalctl -u kubelet和tail -n 200 /var/log/messages。如果内存持续增长不要急着加内存先用top看进程是否有泄漏。处置完以后写分析报告说明结论、证据、优化建议。文档里说的“对监测和报警记录进行分析、评审发现可疑行为形成分析报告”对应到操作上就是上面这套动作。报告不是流水账要包含时间线、影响面、根因、临时措施和长期措施。3.3 安全事件处置的常见动作安全事件处置在驻场文档里占了不少篇幅涉及 DDoS 攻击源和数据量查看、防火墙内外网管控、堡垒机安全访问控制、综合日志审计、漏洞扫描、网页防篡改。我一般先看三样东西当前连接分布、边界设备日志、账号登录记录。# 查看当前TCP连接数和来源IP Top20 ss -ntu | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head -20 # 抓取HTTP入口流量保存文件便于分析 tcpdump -i eth0 -nn port 80 -c 500 -w /tmp/http_capture.pcap # 检查登录失败记录 last -f /var/log/btmp | head -20 # 查看当前登录会话 whoss -ntu把 TCP 和 UDP 连接都列出来截取第 5 字段的 IP 部分统计后能快速判断是否有单一 IP 发起大量连接。tcpdump抓包时用-c 500限制只抓 500 个包-w写文件避免长时间抓包影响业务抓完的文件要归档留作证据。last -f /var/log/btmp显示多次登录失败的记录如果一个 IP 刷了上千次基本可以判断是暴力破解。文档里提到的“查看攻击源和数据量 DDoS”一般要从防火墙或流量分析平台里看攻击源 IP、攻击类型、峰值带宽。如果还没有专门平台可以先用ifstat或nload看入口流量再配合tcpdump定位来源。3.4 基线配置和应急响应文档怎么沉淀驻场文档要求在安全事件处置后制作《系统运维基线配置》和《系统故障应急响应方案》。我接触过的项目里这两份文档经常是“写了就扔”没有和实际环境匹配。基线配置至少包含账号权限策略、密码复杂度、SSH 端口和协议、防火墙默认策略、日志保留周期、NTP 时间源。应急响应方案不用写一百页把角色分工和关键操作写清楚就够了。比如“谁负责判断影响谁负责执行封禁谁负责通知甲方”然后附上各系统的重启、回滚命令。每次安全事件处置后把最终处置步骤更新到知识库和应急响应手册里而不是另起一个新文档这样文档不会烂尾新人也能直接照做。4. 变更管理、补丁与备份恢复驻场最见功力的部分4.1 变更管理的范围和“先备份再变更”原则驻场运维里变更管理最容易出事故。文档里列出的变更包括新的业务系统搭建、KVM 虚拟系统创建、网络路由配置、防火墙配置、数据库部署、应用软件部署、RPM 包安装/卸载/升级、系统核心软件包升级、环境变量参数变更等。无论是哪一类我的原则都是“变更前必须备份变更中记录操作变更后验证结果”。以 KVM 创建虚拟系统为例常见做法是先用qemu-img create规划磁盘再用virt-install安装系统。为了降低风险先确认宿主机的存储池和网络桥接状态再创建虚拟机不然虚拟机可能出现桥接不通或者磁盘 IO 抢占严重。4.2 变更执行记录模板和回滚思路正式的变更管理每次操作前要填一张变更表字段内容变更编号CHG-2025-001申请人和审批人甲方运维负责人变更原因日志磁盘扩容影响范围相关服务短暂重启执行步骤1. 备份配置 2. 调整参数 3. 重启服务回滚操作使用备份文件还原重新加载配置验证命令df -h、systemctl status xxx回退条件验证失败立即回滚实际变更时把要改的配置文件先复制一份备份cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %F) vim /etc/ssh/sshd_config sshd -t systemctl reload sshdsshd -t用来测试 SSH 配置语法不报错再执行systemctl reload重载服务。参数$(date %F)让备份文件名带上日期方便以后回滚。这套思路同样适用于/etc/security/limits.conf、/etc/hosts、/etc/profile等文件。改完/etc/profile后记得用source /etc/profile重新加载或重新登录验证环境变量不要直接在登录会话里乱 source。4.3 备份策略设计从“有备份”到“能恢复”文档要求根据数据重要性和对系统运行的影响确定备份策略定期备份重要业务信息、系统数据和软件系统并且每月提交数据备份报告。我在设计备份策略时先把数据分成几类数据类别备份频率保留周期验证方式系统配置文件每日增量每周全量30 天变更回滚测试数据库数据每日全备binlog90 天每月恢复演练应用数据和日志每日增量180 天抽样校验文件完整性虚拟机和镜像每周全量30 天随机抽取一台恢复备份脚本里不能只做tar或mysqldump要加校验。我一般会在备份后比较文件大小和 md5 值mysqldump -u backup -p --single-transaction --routines --triggers appdb appdb_$(date %F).sql echo appdb_$(date %F).sql backup_manifest.txt md5sum appdb_$(date %F).sql backup_manifest.txt--single-transaction保证 InnoDB 表备份时事务一致不锁业务表--routines和--triggers把存储过程和触发器一起备份。备份文件名和 md5 写到清单里恢复时先校验校验和再导入能减少“备份文件是坏的”的概率。4.4 恢复演练要看时间窗口文档里特别提了“定期执行恢复程序检查和测试备份介质的有效性”。很多环境备份每天都成功但恢复时才发现备份文件损坏或者恢复时间远超预期。驻场工程师需要每季度至少做一次恢复演练。演练时记录实际耗时和计划中的 RTO/RPO 对比。比如数据库每天全备需要 40 分钟恢复却要 6 小时这就是风险。解决方案通常是并行恢复、使用备份存储的更高带宽网络或者把全备拆成多个分片同步恢复。恢复验证后生成“恢复演练记录表”把备份集名称、恢复目标、消耗时间、验证结果列出来。这份表比每天的成功备份日志更有说服力。5. 把驻场文档变成自动化巡检脚本和指标卡驻场文档里最实用的部分就是日巡查表和巡检内容清单。把这两张表变成脚本每天早上自动跑一遍再输出固定格式的报告效率会提高不少。下面是一段基础脚本算是自动化运维的起步写法。#!/bin/bash # 把巡检输出写到带日期的文件方便按周/月归档 REPORTreport_$(date %F).txt { echo 系统巡检 $(date %Y-%m-%d %H:%M:%S) uptime free -m | head -3 df -hT | grep -vE tmpfs|overlay|devtmpfs ss -lntp | grep LISTEN systemctl is-active sshd ntpd crond ceph df 2/dev/null || echo ceph命令不可用或未在执行节点 } $REPORT cat $REPORTgrep -vE用正则排除无关文件系统避免 tmpfs 和容器 overlay 区干扰判断。systemctl is-active后面跟多个服务名会逐个输出 active 或 failed。ceph df只在 Ceph 管理节点执行其他节点会走||分支打印提示脚本不会因为某条命令不存在而中断。随后加入 crontab 定时执行10 9 * * * /opt/scripts/daily_check.sh单独一个脚本还不够要把脚本输出的值和巡检表里的阈值列对应起来。例如增加一段负载判断LOAD$(cat /proc/loadavg | awk {print $1}) CORES$(nproc) if [ $(echo $LOAD $CORES * 0.8 | bc) -eq 1 ]; then echo 负载超过阈值: load$LOAD cores$CORES fi用bc做浮点比较没装bc的环境可以用awk代替。这样脚本不仅生成报告还能在超标时主动告警。把脚本内容和当日报告一起放进原巡检表的“附注”里文档就从静态的勾选表变成了活的工具。本文还有配套的精品资源点击获取