Although conversation about observability often ignores SREs, SREs have a central role to play in observability success. To prove a point, here’s an …
Join the DZone community and get the full member experience. How do you achieve observability, which means the ability to understand the internal state of a system based on external outputs? The most obvious answer to that question is to deploy observability tools, which can collect and correlate data from multiple sources to provide visibility into the internal state of a system. But observability also requires the right people — including, above all, SREs. Although the SRE role originated before most IT organizations were thinking about observability, the explosion of interest in observability in recent years is part of the reason why now is such an exciting time to be an SRE. To prove the point, here’s an overview of the role that SREs play in observability. To start out, it’s worth noting that, historically, SREs and observability did not go hand-in-hand. Site Reliability Engineering, and the Site Reliability Engineer role, originated at Google in the early 2000s. Back then, almost no one was talking about observability within the context of IT. Observability has been a thing in other fields of engineering since the 1960s, but it wasn’t applied to IT work until starting in the 2010s. So, it would be wrong to argue that there is an intrinsic link between SREs and observability. Both concepts developed independently. And indeed, if you read most articles on observability today, you’ll find little mention of SREs. Likewise, important texts on observability — such as the Google SRE book — barely mention observability.
