IT Service Operations · Observability
From Symptom To Cause.
Monitoring tells you something is wrong. Observability tells you why, while it is still happening.
Observability is the understand stage of the operations loop. Detection catches the moment a service moves. Observability explains what moved it: which dependency, which change, which request, and why now.
In a modern estate the cause is rarely where the symptom shows up, and the gap between the two is where incidents get long, expensive and repeated.
The Problem
Drowning In Data, Starved For Insights.
You were sold a simple promise: collect everything, and when something breaks the answer will be in there somewhere. So we all collect, en masse: logs from every container, metrics from every host and thousands of traces.
“Somewhere” is the problem. Mid-incident, at three in the morning, somewhere is nowhere. Somebody swivels between dashboards. Somebody asks in chat whether anything changed. The service is often restored before anyone can say why it broke, which means nobody can promise it will stay fixed.
Enterprises have never collected more about their systems, or understood them less. The gap between the two is the whole problem.
“The collecting is never free. Telemetry bills climb year on year while the number that matters, the time from symptom to cause, barely moves.”
What It Actually Is
A Property, Not A Purchase.
The definition is borrowed from control engineering. A system is observable when you can work out what is happening inside it from what it shows on the outside.
Monitoring covers the questions you thought to ask in advance. Is it up. Is it fast. Is the disk filling. Ask them ahead of time, wire them to thresholds, and the detect stage does its job.
Real incidents ask new questions. Why is checkout slow, but only for customers in one region, on one payment type, since Tuesday’s deploy? Nobody built that dashboard in advance, because nobody knew to. Observability is being able to ask it anyway, of the live system, mid-incident, and get an answer in minutes.
Observability is not a product you buy or a pillar count you hit. It is a property of your system: how well it can answer a question you did not plan to ask.
Three stacks of evidence and no verdict.
And the three pillars? Logs, metrics and traces are ingredients, not the meal. Having logs, metrics, and traces doesn’t mean you have observability. If they exist in isolation, managed by different teams in different tools, you are still blind. That is just three stacks of evidence and no verdict. Understanding lives in the connections, one request, one service, one change, traceable across all of it. That connection is engineered, not purchased.
Why It Is Hard Now
Three Services Away.
A monolith was cruel but simple: when it broke, you knew where to look. Today the checkout slows and the cause is a dependency timing out, under one specific load, behind an API you do not even own. The logs arrive in four formats. The trace stops dead at a service boundary. The container that misbehaved was recycled twenty minutes ago and took its evidence with it.
So the unit of understanding is no longer the server. It is the request. Follow one request across every hop it makes and the cause has nowhere to hide. That takes context that travels with the request, telemetry that speaks one standard end to end, and instrumentation put there on purpose by people who knew which questions would matter.
This is where most companies fall down. Nobody designed the telemetry. It accumulated.
Modern architecture did not make understanding optional, it made it a requirement. The symptom surfaces in one place and the cause hides three services away.
- DetectMonitoring & Alerting →
- UnderstandObservability
- DecideAIOps →
- ActIT Service Management →Learn
Instrument With Purpose
Built To Be Questioned.
Good observability starts with the questions, not the data. Decide what the business needs to understand, then instrument to answer exactly that.
01
Questions first.
For every service that matters, write down what you would need to know on the night it misbehaves: which customer paths, which dependencies, which changes. Instrument to answer those questions. Everything else is cost.
02
One standard, end to end.
Context has to survive every hop, so every service speaks the same telemetry language. Open standards do this without a licence fee: OpenTelemetry captures, standardises and routes telemetry, and leaves you free to choose the analysis layer that earns its keep.
03
Built by owners.
The team that writes a service knows what it looks like when it is sick. They instrument it, against the standard, as part of the release, so understanding ships with the code.
04
Cost-aware by design.
Not everything deserves keeping. Sample the routine, keep the unusual, expire the stale, and tag every stream with what it costs and who owns it. The measure is answers per pound, not terabytes per day.
How We Engagement
Start With Questions.
A dotslash engagement starts with a blunt test. Take your most important services and ask each one what an incident would ask: what changed in the last hour, which dependency is degrading, who is actually affected. If the answers take hours, we have found the work.
We make what you already collect answer harder questions before we ever suggest collecting more.
Then we make it engineering. We define the questions each service must answer, set the telemetry standard every service speaks, and stand up instrumentation patterns teams deploy themselves, with cost governance built in from the first sprint. Premium tooling goes where minutes cost the most; the rest of the estate runs lean on open standards. And expect us to tell you what to switch off. Fewer terabytes, faster answers: that is the trade we engineer.
Understand, Then Decide.
Understanding is not the destination. It is fuel for decisions you can trust, automation you can allow, and problems you can resolve at the root.