以为很熟悉 Linux，万万没想到在生产环境翻车了.....

作为IT工程师，在生产环境遇到Linux"翻车"是很常见的成长经历。以下是系统性的分析和解决方案框架，帮你从根本上提升生产环境运维能力：

一、典型翻车场景分析 1. 权限灾难 - 误执行 chmod -R 777 / 或 chown -R root:root /home - 症状：SSH无法登录、服务启动失败

2. 存储黑洞

- 没做分区隔离：/var/log 写满导致系统崩溃 - 没设磁盘限额：MySQL binlog撑爆磁盘

3. 网络配置翻车

- ifconfig临时修改导致重启失效 - iptables规则清空导致服务暴露

4. 包管理灾难

- 在CentOS上混用yum/dnf导致依赖地狱 - 盲目 apt-get upgrade 引发版本冲突

二、生产环境必备生存技能 1. 终极防护措施： - 所有高危操作前执行：screen -S rescue - 修改关键配置时：cp config.conf{,.bak} - 必须掌握的后悔药：echo 'alias rm="rm -i"' >> /etc/profile

2. 磁盘管理黄金法则：

# 查看inode使用情况（很多新人会忽略）
df -i

# 日志自动轮转必备
logrotate -f /etc/logrotate.d/nginx

# 快速定位大文件
ncdu -x /

3. 网络调试三板斧：

# 连接性检查
mtr -rwbzc 100 baidu.com

# 端口监听检查
ss -tulnp | grep 3306

# 流量实时监控
nethogs eth0

三、必须掌握的救命命令 1. 系统资源快速诊断：

# 综合检查（CPU/内存/IO）
dstat -tcmnd --disk-util

# 僵尸进程排查
ps -ef | grep defunct

2. 文件恢复技巧：

# ext4文件系统恢复
debugfs /dev/sda1
> lsdel
> dump <inode> /recovery/file

# 误删恢复神器
photorec /dev/sdb

3. 服务管理进阶：

# 查看服务启动耗时
systemd-analyze blame

# 禁止服务自动重启
systemctl mask --now kubelet

四、生产环境最佳实践 1. 必须建立的监控项： - inode使用率（建议阈值85%） - 僵尸进程数量 - 系统句柄数（/proc/sys/fs/file-nr） - 不可中断进程(D状态)数量

2. 推荐的安全基线配置：

# 禁止核心转储
ulimit -c 0

# 限制用户进程数
echo "* hard nproc 1000" >> /etc/security/limits.conf

# 历史记录加固
echo 'export HISTTIMEFORMAT="%F %T "' >> /etc/profile
echo 'export PROMPT_COMMAND="history -a"' >> /etc/profile

3. 必须安装的工具包：

- sysstat（sar性能分析） - perf-tools（内核级诊断） - bpftrace（现代追踪工具）

五、事故处理SOP 1. 立即止损： - 断开非必要网络连接 - 用systemctl isolate rescue.target进入救援模式

2. 信息收集：

# 系统快照
journalctl -b > /var/log/boot.log.full
dmesg > /var/log/dmesg.full

# 进程树存档
ps -ef --forest > /var/log/proc_tree.log

3. 根因分析：

- 使用strace -fp <PID>追踪异常进程 - 用perf top -g分析CPU热点

建议在日常建立"破坏性测试"环境，定期演练以下场景： - 磁盘写满恢复 - 内存OOM处理 - 网络分区模拟 - 服务雪崩演练

记住：生产环境的终极安全法则 - 任何修改都要有回滚方案，任何操作都要可审计。可以建立一个预生产沙盒环境，所有变更先在沙盒验证后再实施。