Most of my freelance work starts the same way: a stranger gives me access to a server that matters to them, and something is wrong with it. Here is the routine I follow every time. It's the reason clients come back.
1. Agree what "done" means
Before I log in, we agree in writing what I'm fixing or building, what I must not touch, and how we'll know it works. "Make the site faster" becomes "page loads under 2 seconds on the home page, no changes to the database schema".
2. Access the safe way
I ask for a separate user with sudo and my SSH public key, not the root password pasted into a chat. It's safer for the client, and when the job is done they remove one user and my access is gone. If a password is the only option, I ask them to change it as soon as I finish.
3. Look before changing anything
uptime; df -h; free -m
systemctl --failed
ss -tulpn
journalctl -p err -b | tail -50Five minutes of looking often finds the real problem. A full disk is behind more "the website is down" messages than you'd think.
4. Backup first, every time
A VM snapshot if they have one. If not, at least a copy of every config file I'm about to edit:
sudo cp -a /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%F)And for databases, a dump before any change. If I can't take a backup, I tell the client before I continue.
5. Write down every command
I keep a running log of what I ran and why. It makes rollback easy, and it becomes the client's documentation at the end.
6. Test like the user, not like the admin
nginx -t passing is not the same as the website working. I check from outside: the real URL, the real login, the real email.
7. Hand over properly
Every job ends with a short report: what was wrong, what I changed, how to check it, and how to undo it. Clients don't always read it on the day, but they're very glad to have it six months later.
Written by Ameer Hamza, Linux systems engineer in Lahore. Need help with something like this? Get in touch.