Articles
Working methods for production infrastructure: diagnosing failures, reading the evidence, and writing down only what it supports.
Say Only What the Evidence Supports in the Postmortem
Part two of two. What each postmortem claim costs in evidence, how to state a finding plainly once the review earns it, what to write instead of a finding about a person, and how to record prevention, action items, and residual risk so the document stays accurate after it leaves the room.
Say Only What the Evidence Supports: Incident Language for the People Who Decide
Part one of two, for IT staff who explain running incidents to directors, managers, and VPs: how to label what you know, carry the same evidence into three audience-specific updates, ask for a decision, and report recovery honestly, with rewrites of the sentences that most often go wrong.
The Directive That Was Ignored
systemd-analyze verify can warn and continue with a unit file whose meaning has changed. By default it still exits zero, so a gate reading exit status lets the change through unless it asks for warnings to count.
What a Bounded Blast Radius Still Lets Through
A target-count cap can pass while a job is about to touch the wrong things. This piece works through four operational questions a cap can't answer on its own: what gets touched, how fast it happens, whether it can be undone, and how soon you'd know, each backed by an executed, reproducible demonstration. Every experimental or calculated number here is generated by the reproduction script or an explicit calculation shown in the piece.
The Alert That Cried Wolf: Designing Monitoring People Don't Mute
Why alert fatigue is a design problem before it is a discipline problem, and the six decisions that keep an alerting system trusted: persistence thresholds, alert-once with asymmetric recovery, actionable payloads, a delivery path that fails independently, ruthless triage, and suppression that expires on its own.
Surviving Hostile Remote Shells
The defensive habits that keep pasted commands intact through RDP clipboards, screen-share remote control, and web consoles: deliberate terminators, one-lining on purpose, and knowing when your shell will save you.
Modernizing What You Cannot Redeploy
Weighted systems need modernization too, just translated for infrastructure that will never be disposable. Five practices that survive the crossing, what each one turns into on the other side, and the failure mode each one carries.
Observability Meets the Filesystem
The 2026 observability doctrine wants everything streamed continuously. At the filesystem the physics push back, and scheduled batch collection turns out to be the correct engineering response rather than the un-modernized one.
Why Change Management Is Deliberately Slow
Deployment frequency is the celebrated metric of the age, so an hour spent on one paragraph of a change plan looks like pathology. Sometimes it is. Sometimes it is the most rational activity in the building, and what separates the two cases is weight rather than maturity.
Old Protocols Persist Because They Are Correct
The old monitoring and messaging protocols are load-bearing members of the modern stack rather than fossils it tolerates. The reason says something general about why stable interfaces ossify, and why that ossification is usually a feature.
The Ideal and the Actual
The 2026 infrastructure ideal is declarative, ephemeral, and self-healing, and for a large class of companies it is simply correct. For the weighted world that holds most of the data that matters, a different set of rules applies, and the skill that counts is telling which world a given system lives in.
Script, Configure, or Orchestrate
Imperative, declarative, orchestrated: how to recognize which one a problem actually needs, the tells that you have stretched a script past its boundary, and an honest line between knowing where the boundary sits and running the tools on the far side of it.
Bulk Deletion Is Not a Threading Problem
Why -exec rm {} \; is the real cost, what -delete and -exec + fix that threads do not, the one thing that decides whether parallelism helps or hurts, and a safe parameterized cleanup that does the right thing by default.
Exported Is Not Mounted: The Gap Between showmount and a Working Client
The layered failure modes between an NFS export existing and an NFS export working: RPC services, version differences, client resolution, squash rules, and why the only honest check is a mount and a read.
Anatomy of a Failover
A layer-by-layer walk through a NAS node failover: what the network does, what TCP does, how NFSv3, NFSv4, and SMB3 each recover state, and why the timers stack the way they do.
Idempotency Before the Word
A jargon-free introduction to idempotency, why run-it-twice safety is the foundation of trustworthy automation, how to build it in bash, and why the entire infrastructure-as-code world is organized around this one idea.
Design for the Failure First
Why the senior move is to design the failure behavior first: the questions to ask before an unattended job ships, why partial failure is the one that gets you, and the judgment about which systems earn the discipline and which do not.
Break/Fix Taught Me Safer Automation
The guardrails support work drills into you before you write a line of automation: dry runs by default, bounded blast radius, timeouts on everything, and logging decisions instead of just actions.