上篇聊eBPF那篇发了之后，评论区翻到一个有意思的提问：

"你们银行生产环境到底有多严？"

我想了想，这么说吧——我们连echo xx > test.log都要走工单变更。

今天聊5个命令，我在行里的事故通报里都见过它们的"杰作"。每个命令背后，都有真人真事。

碰了哪个，轻则整改通报，重则监管约谈。不是吓你，是真事。

一个变量为空的脚本

先说个我刚入行时就听师傅讲过的案例。

某清算系统，批量清理脚本挂在crontab里跑，凌晨2点准时触发。脚本里有这么一行：

rm -rf $TARGET_DIR/

正常情况下没问题。但那天上游任务失败，$TARGET_DIR没被赋值，变量是空字符串。

命令变成什么样了呢？

rm -rf /

从根目录开始删。

值班哥们根本来不及反应，发现告警的时候/usr/bin已经没了，批量直接中断。

清算文件下发迟到1小时，责任人通报。

这事发生在2023年。不是十年前的旧账，是最近的事。

为什么是银行？换个公司不就没这么严重？

说实话，互联网公司删了服务器，顶多背个P0，写个复盘，该干嘛干嘛。

银行不一样。原因很实际：

第一，合规审计卡着。 生产环境每一条操作都要有审计日志，谁操作的、操作了什么、有没有备份记录，差一条就过不了测评。你今天凌晨2点手动执行了个rm，没有工单、没有堡垒机会话记录？测评直接打回来。

第二，PCI-DSS卡着。 数据库文件权限变更必须可追溯，改了什么、谁改的、什么时候改的，都得说清楚。你一条chmod 777把整个目录权限放开了，别说PCI-DSS，等保都过不了。

第三，停机=事故。 核心交易系统可用性指标99.99%，一年停机时间不能超过52分钟。超过这个数，就不是运维事故了，是监管事件。

所以下面这5个命令，在我们行不是写PPT里说"慎用"，是**白纸黑字写在运维规范里的"禁止"**。

rm -rf：变量一空，天就塌了

前面那个案例就是rm -rf的典型。

但很多人觉得"我小心点就行了"——不会的。你永远想不到它会在哪种巧合下出事。

我见过三种翻车方式：

银行的做法是三道防线：自动化脚本执行高危命令（变更确认、多人审批）、sudoers禁止直接执行rm -rf、执行操作走自动化平台（先备份再删，全程审计）。

你要用，只能这样：

# 先备份cp -a /path/to/target /backup/$(date +%Y%m%d_%H%M%S)/rm -rf /path/to/target# 或者用trash-cli，好歹有个回收站trash-put /path/to/file

不备份直接删？堡垒机那一关都过不了。

chmod 777：图省事的代价是整改两周

这个命令的危害不像rm -rf那样"立刻爆炸"，但它有个更烦人的特点：你当时不会觉得有问题，等保测评的时候才爆炸。

某银行测试环境，应用启动报错"Permission denied"。工程师排查了半天权限，最后一句解决：

chmod 777 -R /app

秒解决，应用正常启动了，问题关闭，下班。

三个月后等保测评，安全扫描工具一扫——/app/.ssh/id_rsa权限777。高危漏洞，一票否决。整改两周，相关责任人写检查。

说白了，chmod 777就是"我不想查到底是哪个权限不对"的投降方案。 测试环境可能没人管你，但生产环境这一条就是红线。

正确做法其实也不复杂：

# 查看当前权限ls -la /path/to/target# 只给需要的人/组最小权限chown appuser:appgroup /path/to/filechmod 640 /path/to/file   # 所有者读写，组读，其他没权限# 巡检时找一下有没有"投降方案"的痕迹find /app -perm 777 -type f 2>/dev/null

iptables -F：临时清一下？没有临时这回事

这个我身边就有同事中过招。

排查网络连通性，想"临时清一下防火墙规则试试"。随手敲了：

iptables -F

然后忘了存原来的规则。

服务器一重启，iptables规则全丢，MySQL的3306端口直接暴露在公网。安全态势感知平台秒报警，一级安全事件，全部门停下手头的事处理。

防火墙变更在我们行有严格流程： 变更窗口内、双人复核、必须先iptables-save备份规则、改完验证通过才能收工。

如果你只是想删某一条规则，别清空整个链：

# 备份当前规则iptables-save > /backup/iptables_$(date +%Y%m%d_%H%M%S).rules# 只删特定规则iptables -D INPUT 5   # 按序号删# 或者用firewalld，比直接操作iptables安全firewall-cmd --add-port=8080/tcp --permanentfirewall-cmd --reload

kill -9：最快的那一刀，代价也最大

kill本身没问题，kill -9才是问题。

kill -9发的是SIGKILL信号——进程收到这个信号，连说再见的机会都没有。没法捕获，没法忽略，没法做清理。

对普通进程可能没事，但对数据库进程来说，这一刀下去可能8小时的数据就没了。

某银行MySQL主库慢查询堆积，系统hang住，工程师急了，直接：

kill -9 $(pgrep mysqld)

InnoDB缓冲池没来得及刷盘，事务日志损坏，数据库起不来。从昨晚备份恢复，6小时数据没了。（听起来都惊为天人，但是真的发生过）

你急，数据库不急。 正确做法是给进程一个优雅退出的机会：

# MySQLmysqladmin -u root -p shutdown# 或者systemctl stop mysqld# Oraclesqlplus / as sysdbaSQL> shutdown immediate;# 真卡死了，先试 kill -15（默认信号）kill <pid>   # 给进程30秒清理资源# 30秒还不行，再考虑-9，但必须提前拉DBA进来

在我们行，数据库启停根本不可能直接上手操作——必须走变更工单，由DBA执行，这是硬规矩。

dd：sdb打成sda的区别，是重装和失业的区别

dd这个命令有个外号叫"disk destroyer"，不是开玩笑的。

它直接在块级别读写磁盘，绕过文件系统。写对了是工具，写错了就是武器——对自己的武器。

最经典的事故：新系统上线，做系统盘的时候，设备名打错了一个字母。

# 本来要写U盘dd if=CentOS.iso of=/dev/sdb bs=1M# 手一滑dd if=CentOS.iso of=/dev/sda bs=1M    # sdb → sda，一个字母

系统盘被ISO镜像覆盖。服务器起不来，RAID数据也坏了。重装系统，从备份恢复，不过没啥大事。

所以生产环境直接禁止dd。 哪怕你确实需要用，也只能在测试环境，而且必须找同事复核设备名——两个人对着lsblk的输出，一个念一个对。

备份走正经工具：

# 文件系统级备份，有日志、可审计rsync -avz /source/ /backup/destination/# 或者用企业级备份（NBU、Commvault），审计日志完整

光说"禁止"没用，怎么落地？

规范写得再好，不落地就是一纸空文。我们在行里靠三件事：

sudoers卡权限。 把高危命令从普通用户的权限里摘掉，想用？走审批。

# /etc/sudoers.d/ops-policyopsuser ALL=(ALL) !/bin/rm -rf *opsuser ALL=(ALL) !/sbin/iptables -Fopsuser ALL=(ALL) !/bin/dd

堡垒机卡操作。 所有生产操作必须通过堡垒机，高危命令弹二次确认，会话全程录像。

平台化替代人工。 删文件？走工单→自动备份→平台执行。改防火墙？防火墙变更模块，自动备份+自动回滚。杀进程？服务管理模块，优雅停止。

如果你也在金融机构干运维

等保2.0的合规检查，每次巡检这6条必须过：

□ 生产服务器禁了SSH直连（只能通过堡垒机）□ sudoers限制了高危命令□ 所有操作有审计日志□ 数据库启停有变更工单□ 防火墙变更前备份了规则□ 定期巡检有没有777权限的文件

这6条不是"建议"，是测评不过就得整改的硬指标。

生产远不止这几个坑，在银行生产环境碰了它，出了事不光是你自己扛——整个组、整个部门都得跟着你背锅。

你们生产环境还有哪些"禁区命令"？评论区聊聊。

我整理了一份《银行生产环境高危命令清单》，回复关键词「命令清单」获取，里面包含禁用命令对照表、等保2.0合规检查清单和sudoers安全配置示例。