春节前云平台运维深度巡检-实操经验

春节对咱们运维人来说，从来不是单纯的假期，而是一场“保稳定”的硬仗。这段时间业务流量忽高忽低，比如电商的新春促销、社交平台的祝福发送，都可能让云平台承压，再加上值守人员比平时少，一旦出故障，响应和排查的难度都会翻倍。所以节前深度巡检绝不能走形式，核心就是要把隐性隐患挖出来、把潜在风险堵上，提前给平台“做个体检”，确保节日期间业务能平稳跑起来。下面结合我这些年的一线实操经验，拆解各核心组件的巡检要点和常用命令，都是实打实能用得上的干货。

一、巡检前先做好这几件事，少走弯路

节前巡检和日常例行检查不一样，得更细、更全，还得有预判性——不能只看当下指标正常，还要想到春节流量峰值可能带来的问题。动手前先把准备工作做足，能大幅提升效率。

首先，把要巡检的组件列个清单，云主机、容器集群、存储实例、负载均衡、数据库这些核心模块，每一个的数量、规格、部署架构都要摸清楚，避免漏检。其次，翻一翻近3年春节的流量数据、资源使用率和故障日志，心里有个基准，知道往年峰值在哪、容易出问题的环节是什么。然后，应急工具包提前备妥，常用命令脚本、故障处理流程、开发和安全团队的联系方式都整理好，真遇到情况能快速联动。最后，提前和相关团队对齐，节日期间非紧急变更一律停掉，有促销、红包这类特殊业务的，要提前预留好资源，别等流量上来了再手忙脚乱扩容。

二、核心组件巡检：命令+实操要点

（一）计算资源：云主机/容器是根基，绝不能掉链子

云主机和容器是业务运行的载体，CPU、内存、磁盘这些资源一旦扛不住，整个服务都可能崩。春节前重点查健康状态和冗余，确保能扛住流量峰值。

1. Linux云主机：这些命令每天都在用

CPU负载检查：日常最顺手的就是top，实时盯着用户态（%us）、内核态（%sy）CPU占比，要是持续超70%，就得赶紧揪出抢占资源的进程。怕单核心满载拖垮整机，就用mpstat -P ALL 1 5，把每个核心的负载都扒得明明白白。sar -u 1 5能统计平均负载，对比往年春节数据，大概能预判峰值扛不扛得住。另外pidstat -u 1 3比top更精准，能直接定位高CPU进程的PID和用户；uptime快速看1/5/15分钟负载，若15分钟负载持续高于CPU核心数，就得提前腾资源，别等峰值来临时掉链子。

内存状态排查：free -h一眼就能看清内存情况，重点盯available值，至少留20%空闲内存，不然流量一冲就容易卡壳。如果vmstat 1 5里的si（内存换入）、so（内存换出）值一直非零，说明内存不够用了，要么扩容要么清缓存。用ps aux --sort=-%mem | head -20揪出Top20内存占用进程，排查是否有内存泄漏或异常进程。补充slabtop看内核缓存占用，缓存过高可临时用echo 3 > /proc/sys/vm/drop_caches清理（生产环境务必谨慎，先确认无业务影响）；pmap -x 进程ID能拆解单个进程的内存分布，帮你精准定位内存泄漏的细节。

磁盘问题早发现：df -h是必查项，根分区和数据分区使用率绝对不能超80%，我之前就踩过满盘导致服务挂掉的坑，节前一定要清冗余日志。用du -sh /*快速定位大文件目录，再用find /data -type f -mtime +7 -name "*.log" -delete批量清理7天前的日志，省得手动删麻烦。磁盘IO用iostat -x 1 5查读写延迟，延迟高就用iotop -oP实时盯高IO进程，精准揪出拖慢磁盘的元凶。本地盘还要用smartctl -a /dev/vda查健康状态，排查坏道；另外lsattr 文件名能检查文件属性，避免因immutable属性导致日志删不掉，白忙活一场。

进程和服务别“假死”：systemctl status 服务名（比如Nginx、Apache）先确认服务状态，再用ps -ef | grep 服务名核实进程，防止出现“服务显示正常，进程早已挂掉”的假状态。端口监听用netstat -tulnp或ss -tulnp，确保业务端口没被异常占用。补充systemctl is-active 服务名能快速判断服务活跃状态，脚本巡检时用着更高效；nc -zv 本地IP 端口号测试端口连通性，比netstat更精准；若服务启动异常，用journalctl -u 服务名 -n 20 --no-pager看最近20条日志，基本能快速定位问题原因，不用翻整份日志浪费时间。

2. K8s容器集群：重点盯Pod和节点状态

集群状态先摸清：kubectl get nodes先看所有节点是不是Ready状态，有NotReady节点赶紧排查，春节期间少一个节点，整体承载压力就大一分。kubectl cluster-info验证APIServer等核心组件正常后，再用kubectl get cs查scheduler、controller-manager、etcd的健康状态，这些核心组件出问题，整个集群都可能瘫痪。kubectl get pods -A查看所有命名空间Pod，CrashLoopBackOff、Error状态的要重点盯，用kubectl logs Pod名 -n 命名空间 --previous看上一次崩溃日志，快速定位重启原因。另外kubectl get events -A --sort-by='.lastTimestamp' | tail -20能看集群最近20条事件，调度失败、资源不足等问题都能从这找到线索，比挨个查Pod高效多了。

资源使用要留冗余：kubectl top nodes看节点CPU、内存使用率，kubectl top pods -A --containers能细化到单个容器的资源占用，精准找到资源消耗大户。如果Pod调度失败，kubectl describe pod Pod名称 -n 命名空间是必用命令，多半是资源不够或存储挂载异常。补充kubectl get resourcequotas -n 命名空间查命名空间资源配额，避免因配额不足导致Pod无法调度；若怀疑容器内资源瓶颈，用kubectl exec -it Pod名 -n 命名空间 -- free -h进入容器内部查看，比猜问题更靠谱。还可以提前用命令设置默认资源限制，防止无限制Pod耗尽节点资源：kubectl apply -f - <<EOF apiVersion: v1 kind: LimitRange metadata: name: default-limit namespace: 命名空间 spec: limits: - default: cpu: "1" memory: "1Gi" defaultRequest: cpu: "500m" memory: "512Mi" type: Container EOF。

控制器和服务别出岔子：kubectl get deployments、kubectl get statefulsets确认副本数达标，就绪数和期望数必须一致，节前若有滚动更新，用kubectl rollout status deployment/部署名 -n 命名空间确认更新完成，别留更新残留问题。kubectl get svc -A检查服务端口映射，再用kubectl get endpoints 服务名 -n 命名空间验证服务与Pod的端点关联，避免服务找不到后端Pod。本地测试用kubectl port-forward svc/服务名 本地端口:容器端口 -n 命名空间，绕过LB直接连服务，快速判断是服务本身还是LB的问题。

（二）存储资源：数据安全是底线，备份一定要可用

存储出问题要么丢数据，要么业务读写出错，春节前不仅要查健康状态，更要验证备份有效性——光有备份没用，能恢复才是关键。

1.块存储（云硬盘）：挂载和性能都要查

先在云控制台看云硬盘状态，有没有脱机、故障的，挂载关系对不对。命令行用lsblk确认挂载点无误，mount检查是否为只读挂载（ro），要是ro状态，数据写不进去，业务直接受影响，可尝试用mount -o remount,rw /mnt重新挂载为可读写模式（先排查磁盘错误，别盲目操作）。性能测试用dd if=/dev/zero of=/mnt/test bs=1G count=1 oflag=direct，对比平时读写速度，排查性能衰减，测试完记得删掉test文件，别浪费空间。补充blkid查看硬盘UUID和文件系统类型，确保/etc/fstab里是用UUID挂载，避免重启后挂载失败；文件系统检查也不能少，ext系列用e2fsck -n /dev/vda1，XFS用xfs_repair -n /dev/vdb1，都是非破坏性检查，不会影响现有数据，放心用。还可以用iostat -d -x 1 5 /dev/vda针对性监控目标硬盘IO，精准定位单块磁盘的性能问题。

2.对象存储（OSS/S3）：权限和可用性双验证

在控制台看存储桶容量，结合春节业务预期判断空间是否充足，用命令能更精准统计：AWS S3或兼容S3协议的OSS，用aws s3 ls s3://存储桶名 --recursive --human-readable --summarize统计文件总量和大小；阿里云OSS用ossutil stat oss://存储桶名/测试文件验证文件元数据，同时测试访问连通性。权限一定要收紧，用aws s3api get-bucket-acl --bucket 存储桶名（S3）或对应OSS命令查看访问控制列表，清理匿名、越权访问规则，也可以用aws s3api put-bucket-policy --bucket 存储桶名 --policy file://policy.json批量更新权限策略。手动测试文件上传、下载、删除，确保API和SDK调用正常，节日期间用户传祝福图片、视频的场景多，这步不能省。另外检查生命周期规则，过期数据及时清理，还能用curl -X GET "https://存储桶名.oss-cn-beijing.aliyuncs.com/测试文件" -H "Authorization: 签名"手动验证OSS API访问，排查SDK调用异常问题。

3. 文件存储（NFS/SMB）：挂载和读写别出问题

NFS存储先⽤showmount -e 服务端IP确认共享目录正常暴露，再测试挂载mount -t nfs -o hard,nfsvers=4 服务端IP:/共享目录 /本地挂载点，加hard模式和指定NFS版本，能提升挂载稳定性，避免数据丢失和兼容性问题。拷贝小文件测试读写，确保权限和连通性没问题，权限排查用nfs4_getfacl /本地挂载点/测试文件，快速定位权限不足导致的读写失败。服务端用rpcinfo -p 服务端IP验证portmapper、nfs、mountd等相关RPC服务正常启动，少一个服务都可能导致挂载失败。若出现连接异常，用tcpdump -i eth0 port 2049 -c 10抓包测试NFS端口（2049）通信，排查网络层面阻塞；同时翻一翻/var/log/messages日志，里面会记录NFS连接、权限相关报错，提前处理掉，别等节日期间出问题。另外nfsstat -m能查看NFS挂载参数和状态，排查挂载选项不合理导致的性能瓶颈。

（三）网络资源：链路通、带宽足，业务才能稳

网络是业务的“生命线”，春节前要查链路连通性、负载均衡、安全规则，还要预留足够带宽，避免拥堵或被攻击。

1. 链路连通性：丢包、延迟早排查

ping 目标IP -c 10测试连通性，丢包率必须低于1%，延迟也要在合理范围，跨地域链路可稍微放宽要求。若有丢包，mtr 目标IP比traceroute更实用，能持续跟踪路由链路，精准定位是云平台内部还是公网链路的问题，不用反复执行命令。traceroute 目标IP（或tracepath 目标IP，无root权限也能用）排查路由路径，看有没有环路、跳数异常，避免流量走弯路导致延迟过高。补充ss -tulnp | grep 网关端口确认网关端口正常监听；ip route show查看路由表，验证默认路由和业务路由配置正确，防止路由漂移导致链路中断。还可以用curl -w "%{time_total}\n" -o /dev/null -s 目标域名测试HTTP链路耗时，直观评估用户访问延迟，提前预判链路承载能力。

2. 负载均衡（LB）：转发和健康检查要靠谱

在云控制台看LB状态，后端服务器的健康检查结果很重要，有节点被剔除的话，要排查是节点故障还是健康检查规则设置不合理。负载均衡算法要验证下，确保流量能均匀分发到后端节点，别出现某台机器满载、其他机器空闲的情况。HTTPS业务要重点查SSL证书，春节前过期的证书赶紧换，不然用户访问会报错。命令行用curl -I 域名测试转发是否正常，返回200就没问题，ss -s查看系统连接数，评估LB能不能扛住峰值。

3. 安全组与防火墙：别留“后门”

安全组、网络ACL规则要瘦身，没用的规则全删掉，只开放业务必需的端口，比如80、443、数据库端口，公网访问权限能关就关，避免被黑客攻击。防火墙状态也要查，CentOS用firewall-cmd --list-all，Ubuntu用ufw status，确保规则生效，既不阻断正常业务，又能挡住异常访问。

4. 带宽与流量：提前预留冗余

在控制台看公网、内网带宽的使用情况，对比往年春节峰值，至少预留30%的冗余带宽，不够的话提前升级。还要盯着流量趋势，预判会不会有DDoS攻击、流量突增，提前配置好流量清洗、弹性带宽，避免被突发流量打垮。

（四）数据库：业务的核心，容不得半点差错

数据库是业务数据的核心，春节前要查健康状态、性能、备份，还要优化慢查询，避免查询超时影响用户体验。

1. MySQL：重点盯主从同步和慢查询

健康状态别忽视：systemctl status mysqld确认服务在运行，mysql -u 用户名 -p 密码 -e "show status like 'Uptime'"看运行时长，判断有没有异常重启。主从架构的话，show slave status\G是必查命令，Slave_IO_Running和Slave_SQL_Running必须都是Yes，同步延迟也要控制在合理范围，不然数据不一致会出大问题。

性能优化要到位：通过show global status like '%QPS%'计算QPS，对比历史峰值，评估性能承载能力。show processlist查看当前连接和执行中的SQL，遇到锁等待、慢查询要及时处理，尤其是State列不是Sleep状态的进程，要重点分析。慢查询SQL用explain分析执行计划，优化索引或语句，避免节日期间查询超时。另外，show variables like 'max_connections'查最大连接数，预留足够冗余，防止连接数满了用户连不上。

备份一定要能恢复：check table 表名检查数据表一致性，避免数据损坏。定时备份任务要核实，crontab里的备份脚本有没有正常执行，备份文件是不是完整、时间对不对。关键一步是做恢复测试，随机抽一个备份文件恢复试试，确保真出问题时能用上，别等丢了数据才发现备份无效。用du -sh 备份目录清理过期备份，别占满磁盘。

2. Redis：内存和同步状态要盯紧

连通性和状态检查：redis-cli -h 主机IP -p 端口 -a 密码 ping，返回PONG说明服务正常。info Server查看运行状态、版本和内存使用，心里有个数。

内存别爆了：info Stats看QPS和连接数，info Memory监控内存使用，used_memory_rss占比太高的话，要么清理无效数据（设置合理过期策略），要么扩容。生产环境别用keys *，用scan排查无过期时间的key，避免阻塞服务。

高可用别掉链子：主从架构用info Replication验证同步状态，集群架构用cluster info、cluster nodes查看节点健康，确保故障时能正常切换，不影响业务。

巡检收尾=隐患闭环+应急预案

巡检不是查完就结束了，发现的隐患要逐一登记，明确整改责任人、整改时间，形成闭环，节前必须全部整改完毕，实在无法整改的，要制定针对性应急方案。另外，要和值守人员做好交接，把巡检结果、重点关注环节、应急预案讲清楚，确保节日期间有人盯、出问题能快速处理。

最后提醒一句，春节前巡检宁可多花点时间，也别抱有侥幸心理。很多故障都是平时没注意到的小问题，积累到节日流量峰值时集中爆发。把巡检做细、把隐患排净，咱们才能安心过个好年，也让业务平稳运行。