dev · ops

Ops

Everything in the index has to run somewhere, and keep running. This is the operations side of the work — and where I get specific about what I mean by DevOps.

There are two DevOps

Somewhere along the way “DevOps” came to mean two quite different things, and the difference matters enough to be clear about which one is mine.

One DevOps grew out of software engineering — developers owning the full lifecycle of their applications and building the pipelines that ship their own code. You build it, you run it. The centre of gravity is the application, and the operations work exists to serve its delivery.

The other grew out of systems administration — and that one is mine. It is what happened when systems people stopped configuring infrastructure by hand and started treating it as code: software-engineering rigour — version control, testing, peer review, repeatability — brought to infrastructure and operations. The centre of gravity is the platform, the reliable and reproducible systems that other people’s applications stand on. The code I write isn’t the product; it’s how the product stays up.

The slash matters

DevOps has a slash in it for a reason — it’s the meeting of two worlds. I came to it from the Ops side, after more than a decade of hands-on infrastructure before I wrote a line of Infrastructure as Code, and I’ve spent my career bringing the Dev discipline across the line: infrastructure as version-controlled, tested and reviewable as any application, without ever forgetting that its job is to run.

The principles I work by

  • Automation first. Manual work is waste. Automation should be reusable, sustainable and documented, so anyone can pick it up and improve it.
  • Disposable by design. Infrastructure should be disposable, redeployable and recoverable. The value is in data, code and service delivery, not any one server. Flocks, not pets.
  • Observability as governance. Monitoring isn’t an afterthought. Failures should be visible, measurable and traceable, and systems self-healing where they can be.
  • Security by design. Compliance isn’t bureaucracy — it’s reliability. From ISO 27001 practice to NIS2 readiness, good change and major-incident frameworks let you move quickly at lower risk.
  • People at the core. DevOps is a team sport. Tools and process only succeed when teams are engaged, trained and trusted.
  • Pragmatism over perfection. Not everything needs automating. The craft is knowing when to script, when to automate, and when to just get the job done.

In depth

Flock not Pets ↗ — why I treat servers as a flock of sheep rather than pets, and what that meant in practice on air-gapped, hardened infrastructure.

Operational write-ups and release notes live under writing, and the fuller career story is on tfindley.co.uk ↗.