DevOps and observability · Illustrative simulation Shift left: observability starts before go-live
New: follow a team from backlog to production in the Agile delivery playbook →
Why it matters · Was it the release? · What good looks like · Readiness check · How we help
DevOps teams ship changes many times a week. Most incidents start with a change, yet monitoring often can’t see what changed, who owns it or when it went out. Shifting left means building observability in while the code is written, so the team that ships a change can see what it did.
Why it matters
Shift left means moving work earlier in the life of a change: testing, security and now observability. Instead of operations adding monitoring after go-live, developers decide what to measure while they build, and every release carries the information needed to watch it.
- Faster answers. When releases show up in monitoring, the first question in an incident, ‘did something change?’, is answered in seconds.
- Clear ownership. Alerts go to the team that owns the service, not to a central queue that has to work out who to call.
- Less tool sprawl. One telemetry standard across teams means fewer agents, fewer formats and less to pay for.
This connects to how technology spend is managed too: telemetry is billed like any other service. Hybrid, observability and IT operations.
Was it the release?
What the simulation shows
This piece needs scripts to run. In plain terms, here is how long the on-call engineer takes to identify the cause with each combination of the three switches (illustrative times):
- All off (90 min): An alert says checkout is slow. Nothing on the dashboard says anything changed. A bridge call pulls in five teams; someone remembers a release after an hour and it is rolled back.
- Change events only (35 min): A release marker sits on the latency chart at 1:55 p.m. The team suspects the release, but services report in different formats, so proving it takes a while.
- Telemetry standard only (50 min): Traces show checkout is the slow service, but nothing links the slowdown to the release, and the alert went to a central queue first.
- Team ownership only (70 min): The alert goes straight to the checkout team, but they still have to work out what changed by asking around.
- Change events + Telemetry standard (20 min): The slow traces carry the new version number, and the release marker lines up with the slowdown. The cause is clear; finding the right team takes a few minutes.
- Change events + Team ownership (25 min): The checkout team is paged and sees their own release on the chart. They roll it back, then dig through mixed-format logs for the reason.
- Telemetry standard + Team ownership (40 min): The checkout team is paged and the traces point at checkout, but nothing shows a release went out, so they check other causes first.
- All on (8 min): The checkout team is paged directly. The latency chart shows their 1:55 p.m. release, the slow traces carry the new version, and they roll back with a precise reason and a defect ticket.
Illustrative scenario. Times are examples to show the difference, not a benchmark.
Tuesday 2:10 p.m., an online store. A new version of the checkout service went out at 1:55 p.m. Ten minutes later checkout slows down and some orders fail. The on-call engineer is paged.
None of this needs a new monitoring platform. It needs agreements: what every service reports, how changes are recorded, and who owns what.
What good looks like
A telemetry standard for new services
Which signals every service emits, how they are named and how long they are kept, with OpenTelemetry as the default. Written once, reused by every team.
Changes in the monitoring timeline
Releases, configuration and feature-flag changes appear as events next to the metrics they affect, with version, time and owner.
Alerts that reach the owning team
Every alert carries the service and its owner, taken from a CMDB that reflects reality, so it routes to the people who can fix it.
Release checks that use telemetry
Before and after a release, the same few signals (errors, latency, saturation) decide whether it stays or rolls back.
OpenTelemetry playbook → · From signal to ticket → · CMDB health →
DevOps observability readiness check
Six questions, about a minute. You get a scorecard with steps to fix each gap. Your answers stay in your browser unless you choose to send a project request.
The readiness check needs JavaScript.
How we help
We advise; your teams and your chosen tools do the building. Typical pieces of work:
- Telemetry standard: a short, written standard for what new services report, OpenTelemetry first, agreed with your development and operations leads.
- Change visibility: a plan for getting releases and configuration changes into monitoring and the CMDB, so incidents can be tied to changes.
- Ownership and alert routing: mapping services to owning teams and designing how alerts reach them.
- DevOps observability readiness review: the check above, done with your teams, with a prioritized plan.
Observability services · OpenTelemetry playbook · FinOps
Read next: Docker and Kubernetes: where each one fits →
Illustrative simulation. The store, the release and the times are invented to explain the idea and are not measured data or a benchmark.