Posts Tagged "Operations"

Infrastructure Is Not an Application

We took the software-engineering playbook — DRY, long-lived feature branches, package managers, dynamic in-cluster orchestration — and pointed it wholesale at running infrastructure. It keeps breaking, and not because the tools are bad. An application is a stateless artifact you stamp out in identical, disposable copies; infrastructure is stateful, singular, and alive in production. The patterns that make app development fast make operations fragile — and knowing which is which is most of the job.

You're Not Writing Code. You're Running a System.

The most important change an engineer can make isn't a new language or framework — it's a single sentence about what they think they're doing. 'I am writing code' makes the diff the deliverable and production someone else's problem. 'I am running a system' makes the live behavior the deliverable and the merge the starting line. Same keyboard, same person, a completely different job — and nearly everything good downstream flows from the switch.

Load-Bearing Humans

A system that only keeps running because a person is continuously holding it up is not working. The person is working. The system is on life support. 'Working' is one more overloaded word, and most of the time it quietly means 'works as long as the right human is standing there.'

Stop Holding Out for a Hero

Incident response is either an engineering discipline — measured, quantified, repeatable, owned, evaluated — or it is a craft a few heroes practice and nobody else can duplicate. Heroes are great. You shouldn't need them, and you shouldn't bet the company on still having them.

Incident Management

The role-based incident-response model Jesse Robbins brought from the fire service into web operations, written down from memory as I learned it. Incident Commander, Scribe, SMEs, severity, the CAN format, and the discipline that makes the framework actually work when the page goes off at 3 AM.