Software Engineering   Operations   Observability  

Toward a Maturity Model for Observability

By Rachel Perkins  |   Last modified on June 11, 2019

Access to observability is becoming critical to organizations shipping software, running modern infrastructures in production, and to understanding how users are experiencing their service. To achieve success in delivering a complex service, it's no longer optional to instrument for real visibility and ease of troubleshooting, to optimize alerting to enable a focused response, to do what is needed to drive toward real understanding and ownership of the code we deliver.

If you're building an observability practice, you need guideposts and an understanding of how different aspects of the practice can affect your business. You need to consider what to do first, what to do next, and why. The goals and practices of observability are closely inter-related, and can be iterated on via the practice of Observability-Driven Development. Developers get happier and more productive when code is cleaner and easier to maintain. Clean, easier-to-maintain code results in a more stable product and a more pleasant experience for folks oncall and ultimately, for your customers. Where should you start?

diagram of a proposed observability model

The framework we describe in the Framework for an Observability Model is a starting point. With it, we aim to give  organizations the structure and tools to begin asking questions of  themselves, and the context to interpret and describe their own  situation--both where they are now, and where they could be.

Download the Framework for an Observability Model and join our discussion (find an HTML version here). We'll be hosting a roundtable meetup at Velocity this week looking to get your feedback, and will be hosting more, similar discussions through the summer as we develop a suitably rigorous approach.


Ready to take the next step toward growing your observability practice? Sign up for a free trial!

 

Related Posts

Software Engineering   Culture  

The CoPE and Other Teams, Part 1: Introduction & Auto-Instrumentation

The CoPE is made to affect, meaning change, how things work. The disruption it produces is a feature, not a bug. That disruption pushes things...

Software Engineering   Dogfooding  

Destroy on Friday: The Big Day 🧨 A Chaos Engineering Experiment - Part 2 

In my last blog post, I explained why we decided to destroy one third of our infrastructure in production just to see what would happen....

Teams & Collaboration   Software Engineering   Culture  

What Makes for a 'Good' Pair Programming Session?

Software changes so rapidly that developing on the cutting edge of it cannot fall to a single person. When it comes to asynchronously disseminating information...