Every DevOps engineer lives in Linux. Your CI/CD servers run Linux. Your Docker containers run Linux. Your Kubernetes nodes run Linux. Your cloud VMs run Linux. There is no DevOps without Linux. This part focuses specifically on Linux skills that matter most in a DevOps context — not general Linux, but the parts you will use every single day on the job.
SSH (Secure Shell) is how you connect to and manage remote servers. This is one of the most used tools in DevOps:
ssh user@server_ip # Connect to server
ssh -i key.pem ubuntu@54.1.2.3 # Connect with key file (AWS style)
ssh -p 2222 user@server # Non-standard port
# Copy files to/from remote server
scp file.txt user@server:/home/user/
scp user@server:/var/log/app.log .
# Sync directories
rsync -avz ./app/ user@server:/var/www/app/
In production, applications run as services managed by systemd:
sudo systemctl start nginx # Start service
sudo systemctl stop nginx # Stop service
sudo systemctl restart nginx # Restart
sudo systemctl reload nginx # Reload config without restart
sudo systemctl enable nginx # Start on boot
sudo systemctl disable nginx # Do not start on boot
sudo systemctl status nginx # Check status
sudo systemctl is-active nginx # Check if running
ps aux # All running processes
ps aux | grep nginx # Find specific process
top # Real-time process monitor
htop # Better process monitor (install separately)
kill 1234 # Kill process by PID
kill -9 1234 # Force kill
pkill nginx # Kill by name
nohup python app.py & # Run in background, survive logout
df -h # Disk usage by filesystem
du -sh /var/log/ # Size of directory
free -h # Memory usage
vmstat 1 # Virtual memory stats every 1 second
iostat # CPU and disk I/O stats
lsblk # Block devices
ip addr # Network interfaces and IPs
netstat -tulnp # Open ports and listening services
ss -tulnp # Modern replacement for netstat
ping google.com # Test connectivity
traceroute google.com # Trace network path
curl -I https://srjahir.in # HTTP headers check
wget https://example.com/file.zip # Download file
nslookup srjahir.in # DNS lookup
DevOps engineers automate repetitive tasks with shell scripts:
#!/bin/bash
# deploy.sh — Simple application deployment script
APP_DIR="/var/www/myapp"
BACKUP_DIR="/var/backups"
DATE=$(date +%Y%m%d_%H%M%S)
echo "Starting deployment: $DATE"
# Create backup
cp -r $APP_DIR $BACKUP_DIR/myapp_$DATE
echo "Backup created"
# Pull latest code
cd $APP_DIR
git pull origin main
echo "Code updated"
# Install dependencies
pip install -r requirements.txt -q
# Restart service
sudo systemctl restart myapp
sudo systemctl status myapp
echo "Deployment completed successfully"
journalctl -u nginx # Service logs
journalctl -f # Follow system logs
journalctl --since "1 hour ago" # Recent logs
tail -f /var/log/nginx/access.log # Follow nginx access log
grep "500" /var/log/nginx/error.log | tail -20
In Part 3, we will deep dive into Git — the version control system that is the foundation of every CI/CD pipeline.
Beyond basic navigation, DevOps engineers rely on specific Linux skills daily. Process management — knowing how to find resource-hungry processes with top and ps aux, kill stuck processes, and understand system load — is fundamental for production troubleshooting. Systemd service management — starting, stopping, enabling, and checking the status of services with systemctl — is how applications are managed on modern Linux systems. Log inspection with journalctl for systemd-managed services and direct log file reading with tail -f and grep are the first tools used in incident response. Network diagnostics with ss, curl, ping, and dig are used to diagnose connectivity issues between services.
DevOps engineers write shell scripts constantly — for deployment automation, system configuration, health checks, data processing, and operational tasks. Effective shell scripting requires understanding variables and parameter expansion, conditionals and loops, functions for code reuse, error handling with set -euo pipefail, and working with command output using pipes and redirection. A shell script that deploys an application, checks that the service started successfully, and rolls back on failure is a realistic DevOps deliverable. Investing in shell scripting proficiency pays continuous dividends throughout a DevOps career.
Write a deployment health check script: it should verify that a specified systemd service is running, check that a specific port is listening using ss -tulnp, make an HTTP request to a health check endpoint using curl and verify the response code is 200, and output a clear pass/fail status for each check. Test it against a real service on your system such as nginx or sshd. This is a simplified version of the health check scripts used in real deployment pipelines.
DevOps is not a destination but a continuous journey of improvement. The practices covered here — automation, monitoring, infrastructure as code, CI/CD pipelines — are tools in service of a deeper goal: enabling teams to deliver software changes to production quickly, safely, and reliably. The measurement that matters is not which tools you use but how long it takes to go from a committed code change to running in production, and how confident you are in that process. The best DevOps teams measure their deployment frequency, lead time for changes, change failure rate, and mean time to recovery (the DORA metrics), and treat these as engineering objectives to improve over time.
Every topic in technology and finance rewards the learner who goes beyond surface understanding to build genuine fluency. Fluency comes from repeated exposure, application in varied contexts, and reflection on what worked and what did not. The concepts discussed here are starting points — each one opens into a deeper field of study that could occupy years of focused learning. The most effective approach is not to try to master everything at once, but to pick the areas most relevant to your current goals, go deep there, and then expand. Depth in a few areas is more valuable than shallow familiarity with many. Build on what you know, stay curious about what you do not, and keep the practice of learning as a consistent daily habit rather than an occasional burst of effort.
The questions that make learning stick: How does this connect to what I already know? Where would I actually use this? What would happen if I tried to explain this to someone who knows nothing about it? What are the edge cases and exceptions? What is still unclear? Asking these questions transforms passive reading into active learning, and active learning is what builds the kind of understanding that is still accessible years later when you need it under real conditions.