Infrastructure
My first decade in IT was almost entirely physical. Cables, racks, switches, routers, patch panels. Environments where the debugging process started with a visual inspection and a cable tester rather than a grep. Where understanding the network meant being able to draw it from memory — because if you couldn’t, you probably didn’t understand it.
I’m not nostalgic about it. But it set a useful baseline: a strong preference for systems that behave predictably, that you can reason about under failure, that do what they appear to do.
The networking years
The core of the infrastructure writing is the networking series — Making Systems Predictable. It covers the period where I was responsible for wide-area networks across multiple sites: the design decisions, the failure modes, the gap between what the network topology diagram said and what the traffic was actually doing.
These posts aren’t tutorials. They’re accounts of specific problems and the thinking that resolved them — which is either useful to you or it isn’t.
From networks to servers
The Linux server work runs alongside the networking period and carries on after it. Building Linux Servers Before Automation covers the build-from-scratch era — before configuration management, before IaC, when repeatable meant having a good checklist and doing it carefully. Learning to Harden Linux is the security methodology post: what it looks like to develop hardening practice by reading the vulnerability databases rather than inheriting a checklist from someone else.
The platform administration period
The WebCenter work — Inheriting the Unmappable and the associated lab posts — is the current chapter. It’s infrastructure of a different kind: a platform with fifteen years of accumulated decisions, no documentation worth the name, and a constituency of users who don’t understand why it works the way it does, only that it does.
The approach is the same as it always was. Understand the system. Reduce the variables. Don’t touch what you don’t understand yet.
Disaster recovery
What Counts as Disaster Recovery? is worth reading separately from the series. It’s an argument about intent versus implementation — that most disaster recovery plans are an exercise in optimism, and that the gap between the plan and the reality tends to surface at the worst possible moment.