linux生产运维核心是理解系统行为、预判故障、建立可重复节奏；监控需基于动态基线而非固定阈值；变更必须验证回滚路径；日志须分层归档压缩；权限应最小化并强制确认与审计。
Linux生产环境运维不是靠堆命令，而是靠对系统行为的理解、对故障模式的预判，以及一套可重复、可验证的日常节奏。
监控不是“看图”，而是建立基线与异常敏感度
很多团队装了Zabbix或Prometheus，但只盯着CPU >90%才告警——这已经晚了。真正有效的监控，是先跑够一周以上稳定业务期，记录各服务在正常负载下的磁盘IO延迟（iostat -x 1）、网络重传率（netstat -s | grep -i retransmit）、Java应用GC频率与停顿时间等指标，形成动态基线。之后所有告警都基于偏离基线的幅度（比如：某DB节点的pg_stat_bgwriter.checkpoints_timed突增300%，且伴随buffer_checkpoint占比超85%），而非固定阈值。建议用Grafana配置“基线对比面板”，左侧显示当前7天均值，右侧叠加实时曲线，肉眼就能识别漂移。
变更必须带回滚路径，且提前验证过
上线新版本、升级内核、调整sysctl参数——任何变更在生产环境执行前，必须明确三件事：回滚命令是什么、回滚耗时是否在SLA内、回滚后是否真能恢复到原状态。例如升级Nginx，不能只写“./configure && make && make install”，而要准备好：① 备份旧二进制与conf目录（tar -czf /backup/nginx-1.20.2-$(date +%s).tgz /usr/sbin/nginx /etc/nginx）；② 验证回滚包解压后能否直接替换运行（测试机上走一遍cp + nginx -t + systemctl reload）；③ 记录进程PID与监听端口，确保reload失败时可用kill -USR2平滑切换回旧worker（需旧版本仍驻留内存）。没验证过的回滚，等于没回滚。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
日志不归档=没日志，归档不压缩=占满磁盘
生产环境/var/log下不能只靠logrotate配daily+rotate 7——访问日志一天几十GB时，7天就是半吨数据。必须分层处理：① 应用自身输出日志（如Spring Boot的out.log）用logback配置
权限最小化不是口号，是每次sudo都得问“为什么”
给运维账号配NOPASSWD ALL？等于给所有脚本开了root后门。正确做法是：① 用visudo按角色拆分权限，比如deploy组只能执行/usr/local/bin/deploy.sh，backup组只能运行/usr/local/bin/backup-mysql.sh，且每个脚本开头强制校验调用者UID与预设列表；② 关键操作（如rm、mkfs、iptables -F）全部封装成带确认环节的wrapper脚本，执行前输出影响范围（如“即将清空/tmp下所有7天未访问文件，共321个，最大文件1.2G”），按y继续，其他键退出；③ 禁用root直接SSH登录，所有提权必须经由sudo+双因素（如YubiKey或Google Authenticator），且sudo日志同步推送至独立日志服务器（rsyslog转发+TLS加密）。
不复杂但容易忽略。
