20 Common Ops Newbie Pitfalls – Which Ones Have You Hit?

The article identifies twenty typical errors that fresh operations engineers encounter, grouping them into five categories—file handling, database commands, network/firewall rules, container/Kubernetes actions, and system configuration. For each pitfall it shows the dangerous command, the underlying cause, a safe replacement workflow, and a concise risk reminder.

1. File‑system mistakes

Example: rm -rf / or rm -rf /* deletes the entire root filesystem. The author recommends a three‑step safe deletion:

# 1. Preview what will be removed
ls /opt/log/
# 2. Dry‑run with find
find /opt/log -name '*.log' -mtime +30 -print
# 3. Delete after confirmation
find /opt/log -name '*.log' -mtime +30 -delete

Risk: immediate system crash and unrecoverable data loss.

2. Database pitfalls

Running DELETE FROM users or UPDATE users SET balance=0 without a WHERE clause can wipe entire tables. Safe practice includes:

# Verify impact
SELECT COUNT(*) FROM users WHERE id=123;
# Use LIMIT and transactions
BEGIN;
DELETE FROM users WHERE id=123 LIMIT 1000;
COMMIT;

Risk: massive data loss, long binlog replay, possible downtime.

3. Network/firewall errors

Executing iptables -F or systemctl stop firewalld && iptables -F clears all firewall rules, often leaving the default DROP policy active and cutting SSH access. The safe approach is to back up and add a fallback rule before flushing:

# Backup current rules
iptables-save > /tmp/iptables.bak.$(date +%Y%m%d%H%M)
# Ensure SSH is allowed
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
# Flush only after confirmation
iptables -F
# Verify connectivity, then restore if needed
iptables-restore < /tmp/iptables.bak.$(date +%Y%m%d%H%M)

Risk: loss of remote access, especially on cloud VMs.

4. Container & Kubernetes mistakes

Deleting Docker volumes indiscriminately ( docker volume rm $(docker volume ls -q)) destroys persistent data. The recommended workflow is to inspect mounts first and delete only dangling volumes:

# List volumes used by a container
docker inspect my_container | jq '.[0].Mounts'
# Delete only unused volumes
docker volume rm $(docker volume ls -qf dangling=true)

For Kubernetes, forgetting the namespace ( kubectl delete pod mypod) can remove a production pod. Always specify -n <namespace> and use --dry-run=client to preview:

# Dry‑run deletion
kubectl delete pod mypod -n prod --dry-run=client -o yaml
# Real deletion after review
kubectl delete pod mypod -n prod

Risk: accidental service outage and data loss.

5. System configuration hazards

Running sysctl -p on a modified /etc/sysctl.conf can break networking and SSH. Safe practice is to test each parameter individually:

# Backup config
cp /etc/sysctl.conf /etc/sysctl.conf.bak
# Test a single setting
sysctl -w net.ipv4.ip_forward=1
# Verify before applying whole file
sysctl -p -N /etc/sysctl.conf

Risk: immediate loss of network connectivity.

Across all sections the author stresses the "5‑second rule": before executing any destructive command, pause, ask what the command does, what resources it touches, how to roll back, and whether a safer alternative exists. The article also provides a concise "one‑sentence" summary for each pitfall, a risk‑level table, recovery playbooks, and a checklist to use before any production change.