Why infrastructure should run without you

Most infrastructure problems aren’t really technical. They’re the accumulated cost of manual work that never got automated — the deploy that only one person knows how to run, the server that was configured by hand two years ago, the alert everyone ignores because it’s always noisy.

Good automation attacks that cost directly. Here are the principles I bring to every engagement.

Everything is code, and code is reviewed

If it isn’t in version control, it doesn’t exist. Infrastructure, pipelines, alerts, and runbooks all belong in a repository where changes are proposed, reviewed, and applied the same way. This turns “who touched the server?” into a git history and makes every environment reproducible.

The system should tell you when it’s unhealthy

You shouldn’t learn about an outage from a customer. Observability — metrics, logs, tracing — and meaningful alerting tied to user-facing symptoms mean the system surfaces problems while they’re still small.

Make the safe path the easy path

Engineers don’t cut corners because they’re careless; they cut corners because the safe way is slower. When the golden path — the paved road for shipping a service — is also the fastest one, quality follows for free.

Automation is about people

The point of automating toil isn’t to remove humans from the loop. It’s to move them up the stack — from running scripts to designing systems, from firefighting to building. Infrastructure that runs without you is infrastructure that lets you do the work that actually matters.

---

If any of this resonates with where your team is today, get in touch — I’d love to hear what you’re working on.