20 Common Ops Rookie Mistakes and How to Avoid Them

The article, based on eight years of ops experience, identifies twenty typical mistakes newcomers make and groups them into six categories: file & directory operations, database commands, network & firewall rules, scheduled tasks & version control, container/k8s handling, and system‑level actions. For each pitfall it describes the symptom, root cause, a safe corrective procedure, a risk warning and a concise one‑sentence takeaway.

Central to the methodology is the “5‑second rule”: before executing any command, ask five questions – what action will be performed, what scope it affects, how to roll back, what the worst‑case impact is, and whether a safer alternative exists. If any answer is unclear, stop and investigate.

Safe practices include always previewing destructive commands (e.g., ls before rm, find -print before find -delete), using explicit WHERE clauses and LIMIT for DELETE / UPDATE statements, wrapping changes in transactions, and backing up configurations before modification. Sample safe commands are shown:

File deletion:

# Preview
ls /opt/log/
# Delete safely
rm -i /opt/log/*.log

Find cleanup:

# Dry‑run
find /var/log -name "*.log" -print
# Execute
find /var/log -name "*.log" -delete

MySQL delete:

# Verify rows
SELECT COUNT(*) FROM users WHERE id=123;
# Delete safely
DELETE FROM users WHERE id=123 LIMIT 1;

Git force push:

# Review remote history
git log --oneline origin/main -5
# Push with protection
git push --force-with-lease origin main

iptables change:

# Backup
iptables-save > /tmp/iptables.bak.$(date +%Y%m%d)
# Add safe rule then flush
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
iptables -F
# Restore if needed
iptables-restore < /tmp/iptables.bak.20231101

Kubernetes delete:

# Dry‑run
kubectl delete pod mypod -n prod --dry-run=client -o yaml
# Confirm namespace
kubectl get pod mypod -n prod

Risk levels (0‑4) are listed in a table, with higher‑risk actions requiring backups, double‑person approval, rollback plans, monitoring, and execution during low‑traffic windows. A concise verification checklist (action type, scope, backup, rollback, change window, peer review, notification, test‑env validation, monitoring, gray‑release) is provided to run before any operation.

The guide concludes with best‑practice recommendations: enforce the 5‑second rule, always backup first, use staged rollouts, monitor continuously, employ role‑based sudo, maintain runbooks, conduct regular training and chaos‑engineering drills, and turn safety habits into muscle memory.