Posts Tagged "Reliability"

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.

Maintainability Against the Unknown Unknowns

You can harden a system against the failures you can imagine. You cannot harden it against the ones you can't — and those are the ones that take you down. The only defense against a failure you never predicted is a system you can understand, change, and recover fast enough to survive the surprise. That capacity has a name: maintainability. It's the most undervalued property in engineering, because its payoff is invisible until the day it's everything.

Manual, Automated, Autonomous

There are three rungs on the operations ladder — do it by hand, run a script that does it, or build a system that keeps it done without you. Most teams climb to the middle rung, call it 'automated,' and stop — never realizing the rung above is where reliability actually lives. The Google SRE book laid this out a decade ago. It's the most-cited, least-applied book in the field.

Chasing Nines

Your availability target — how many nines you promise — isn't a line in a contract, it's an architecture decision. Get it wrong in one direction and you fail the SLA you sold. Get it wrong in the other and you burn money buying nines you never promised. I once looked at a stack paying $10,000 a month for high availability it did not actually have.

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.'

Nice People Who Give Us Money

We are not paid to solve interesting engineering problems. We are paid to make products that make customers happy, and a customer is a nice person who gives us money. Under that definition, monitoring, testing, deployment, security, and resilience are not 'non-functional requirements.' They are the function.