Reliability Engineering Mindset • Alex Ewerlöf & Charity Majors • GOTO 2025

In a conversation with Charity Majors, Alex Ewerlöf shares insights from his journey into reliability engineering, which began accidentally when his company shifted to a model where generalist software developers own their code in production. This experience highlighted the common challenges engineering organizations face when trying to adopt Site Reliability Engineering (SRE) principles.

Bridging the “Google SRE Gap”

A core theme of the discussion is the significant gap between the SRE practices described in Google’s books and the operational reality of most companies. Alex uses the metaphor of a Michelin-starred chef’s recipe being given to a home cook whose kitchen has “three fires burning.” Most companies lack Google’s mature platforms, resources, and business model, making a direct “cargo cult” adoption of SRE ineffective.

This reality gap is a primary driver for the rise of platform engineering, as companies realize they must first build the foundational “kitchen”—the tooling, automation, and infrastructure—before they can effectively implement advanced SRE recipes.

From “Best Practice” to “Fit Practice”

The conversation critiques the notion of “best practices” as a form of absolutism. Instead, a “fit practice” approach is advocated, where principles and methodologies are adapted to the specific context of a company, including its technology landscape, budget, headcount, and business goals. A one-size-fits-all recipe for reliability, SRE, or DORA metrics is unlikely to succeed. The focus should be on understanding the unique problems a company is trying to solve.

Making SLOs Practical and Meaningful

Both speakers agree that Service Level Objectives (SLOs) and Service Level Indicators (SLIs) are one of Google’s most significant contributions to the field, providing a universal language for reliability. However, their implementation is fraught with common pitfalls.

The most common mistake is not defining SLIs at all, often because the concepts are perceived as complex Google jargon. The second most common pitfall is measuring the wrong thing, such as defaulting to the “four golden signals” (latency, traffic, errors, saturation) without connecting them to actual user experience or business impact.

To avoid this, Alex proposes a structured, visual process:

1. Map the relationships between your service providers and service consumers.
2. Identify potential failures at these dependency points.
3. Sort these failures based on their real-world business impact.
4. Finally, define SLIs that are directly tied to these high-impact failure modes.

SLOs as a Communication Tool

A powerful framing for SLOs is as “the API for your engineering teams.” They serve as a formal contract that empowers teams with autonomy. As long as a team is meeting its agreed-upon SLOs, management doesn’t need to micromanage its roadmap or technical decisions.

This approach uses hard data to put an end to emotional discussions. When reliability slips and an error budget is breached, the conversation shifts from subjective arguments to a pre-agreed-upon contract: feature work must be paused to address the reliability deficit.

This framework is crucial for engineering leaders to effectively say “no” or, more accurately, to illuminate the costs and trade-offs of new requests. It transforms the discussion from “what are we being asked to do?” to “what does it cost in terms of reliability and engineering effort?”

The Economics of Reliability

Reliability is not free. For every “nine” of availability added (e.g., moving from 99.9% to 99.99%), the error budget shrinks by a factor of 10, and the associated cost increases significantly. This cost includes refactoring, changing vendors, improving tooling, or hiring more engineers.

Teams must ask why a higher level of reliability is needed. Often, what stakeholders want is a “good customer experience,” which doesn’t necessarily require five-nines availability. For one media streaming app, user research revealed that customers could tolerate up to two hours of downtime before considering switching vendors, which translated to a much more achievable and less expensive reliability target of 99.7%. Not every system deserves the same investment in reliability; a notification service, for example, can tolerate delays that a payment processing system cannot.

The Future of Observability and SLOs

For SLOs to be truly effective, they must be a first-class citizen in observability platforms, not a bolted-on feature. The ideal state is to calculate SLOs from the same underlying event data that is used for debugging and investigation.

Charity Majors emphasizes the power of this integration:

When you can click on the events that are violating an SLI and immediately analyze their common characteristics (e.g., they all come from a specific Android version, a certain region, or a particular cache server), you dramatically shorten the feedback loop between detection and resolution. This fluid transition from the “what” (the SLO violation) to the “why” (the root cause) is a game-changer for modern, complex systems.

• Tags:
• Platform Engineering
• Observability
• SRE
• Reliability Engineering
• SLO
• SLI