Reliability Without an SRE Team

I'm Tom Lang — I've built and scaled engineering organizations for three decades, through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

The enterprise pitch for AI observability goes like this: buy the platform, point it at your systems, and it becomes the SRE team you can't afford. It's a seductive pitch for a small team. It's also backwards — and I want to give you the version that actually works when you're running real scale without a dedicated reliability org.

I learned reliability at Videology, keeping a platform healthy at more than three billion transactions and four terabytes of data a day. Here's the rule of thumb that matters most: mitigate synchronously, investigate asynchronously. If a human has to diagnose a problem in order to stop the bleeding, you are not reliable. Minimum viable reliability means shifting your entire focus from preventing failure to automatically surviving it.

The four non-negotiables

To survive real transaction volume without burning out a small or fractional team, these have to be in place:

• Automated rollbacks on golden signals. Your CI/CD must be wired to your observability. If a deployment spikes your error rate or pushes latency past a threshold in the first five minutes, the system reverts to the previous version automatically — no human approval required.
• Ruthless, user-centric SLOs. Stop alerting on CPU spikes and memory usage. Alert only when a critical user journey actually breaks — "checkout failure rate above 0.5%." Everything else goes to a dashboard for next-day review, not to a pager at 3 a.m.
• High-cardinality distributed tracing. At this scale, logs are noise. What you need are traces that follow a single request across your entire architecture, tagged with high-cardinality data — tenant ID, region, client version — so you can isolate exactly who is failing, not just that something is.
• Circuit breakers and load shedding. The system has to be designed to aggressively drop low-priority traffic and gracefully degrade non-essential features — turn off the recommendation engine — to protect core transaction processing when things spike.

This is survival, not "self-healing AI"

One clarification, because it matters and it's where people get confused. Elsewhere I've called "self-healing infrastructure" snake oil — an AI that autonomously diagnoses and resolves complex failures while you sleep. This isn't that. Everything above is deterministic engineered survival: pre-defined, well-understood safe reactions — roll back, shed load, trip a breaker. No AI is diagnosing anything or exercising judgment. You designed the reflexes in advance. That's exactly why they're trustworthy enough to run without human approval — and exactly why the "AI figures it all out" version isn't.

Where AI observability earns its keep — and where it's premature

So where does AI actually help? The biggest mistake small teams make is buying an AIOps tool hoping it'll act as a fractional SRE and make sense of a messy environment. It won't. AI doesn't fix bad telemetry — it amplifies it. Here's the honest split:

	Premature (the snake oil)	Earned (the reality)
Log analysis	Dumping terabytes of unstructured, messy logs into an AI tool and expecting it to find the needle.	Feeding clean, structured trace data in so it can instantly link a performance dip to a specific PR or config change.
Alerting	Using AI to generate more alerts on minor anomalies — mass alert fatigue for a small team.	Dynamic baselining — AI adjusting thresholds to historical patterns, so it knows a 5x spike is normal for Tuesday morning.
Incident response	An LLM chatbot you query for metrics by hand while the system is burning down.	Automated context — the AI attaching the likely failing service, the recent deployment, and the blast radius to the alert before you even open it.

The bottom line

AI-assisted observability earns its place once your telemetry is clean enough that it can connect infrastructure signals directly to business impact. If you haven't instrumented distributed tracing, or you don't have structured logs, AI observability is premature — it will only generate expensive noise. Build the survival mechanisms and the clean telemetry first; add the AI once there's something worth correlating. And a human still stays in the loop on anything that touches production — the same judgment line I draw on governance.

If you're a small team trying to hit real reliability without an SRE org — or you've bought an AIOps tool that's just making noise — that's exactly the kind of problem I help with. Book a call.