Provisioning
A new server built from a repeatable checklist: users and SSH keys, no root password login, firewall, timezone, unattended security updates, swap sizing and monitoring agent.
Servers, Hosting & DevOps
Linux server management
Most sites that go down do not go down because of a clever attack. They go down because a disk filled with logs, a certificate expired, MySQL was killed by the out-of-memory killer, or a backup that nobody had tested turned out to be empty.
Server management is largely the discipline of removing those failure modes ahead of time, and then being reachable when something happens anyway.
How I work on it
Process
Adjusted to the job, but this is the shape it usually takes.
-
Audit before touching
What is installed, what is listening, what is in cron, what the update situation is. Undocumented servers get documented first.
-
Fix the dangerous things
Exposed services, missing updates, absent or unverified backups.
-
Tune to the workload
Configuration follows measurement. Copy-pasted my.cnf settings from a blog post are how servers end up swapping.
-
Leave a runbook
Where things live, how to restart them, how to restore a backup, who to call.
Questions
Things people ask
Most often PHP-FPM children multiplied by their memory limit exceeds RAM, or MySQL's InnoDB buffer pool was set as if the box had more memory than it does. Both are configuration, not hardware, and both are cheap to fix once measured.
If someone on your side is comfortable with SSH, reads alerts and applies updates, self-managing is fine. If nobody is, an unmanaged VPS is a liability that will eventually cost more than managed hosting would have.
At least quarterly, and after any significant change to the stack. An untested backup is a hypothesis, not a backup.