Avito Explains How It Measures Reliability and Why Its Error Budget Differs from Google's

One of Russia's largest internet platforms has publicly explained how it turns "reliability" from a slogan into numbers. Ivan Tarasov, TUL Architecture Governance on Avito's tech platform, walked through the whole chain on Habr: from SLI, SLO and SLA to non-functional requirements (NFRs) for REST/RPC services, data buses and custom operations. The article puts particular emphasis on the fact that Avito's error budget differs from the canonical description in Google's SRE book. According to the author, this is a deliberate decision.

An important caveat: we have only the announcement of the article. Avito's specific thresholds, formulas and arguments are laid out in the full version, so below we examine the structure of the approach and its context rather than retell details we have not seen.

What the System Includes

Tarasov leads several teams. One of them, SLA, creates the conditions for improving technical reliability and develops NFR tooling and stability scenarios. The announcement points to the following set of elements:

• SLI, SLO and SLA as the basic hierarchy: what you measure, what target you set, what you promise.
• Stability Rate and Uptime as two different metrics; the author analyzes the difference between them separately.
• NFRs for REST/RPC services, that is, requirements for synchronous interaction.
• NFRs for data buses, where reliability is measured differently than for a request-response call.
• NFRs for custom operations that do not fit standard templates.
• An error budget that intentionally differs from the Google SRE version.

The list shows the key point: Avito does not limit itself to a single number of "nines" per service. Different types of interfaces get different ways of measuring.

Why Avito Did Not Take Google's Canon As-Is

In the Google SRE book, the error budget equals one minus the SLO. With a 99.9% target over 30 days, that is about 43 minutes of allowable downtime. As long as the budget is not exhausted, the team ships releases freely. Once it runs out, the priority shifts to stabilization. The mechanism is simple and defuses the perennial dispute between development and operations.

In practice, this model has weak spots. It assumes that the SLO is set meaningfully and is equally measurable for all services. In a company with hundreds of services, queues, buses and non-standard operations, that condition often does not hold. Avito states that it took this into account and deliberately changed the model. The announcement does not show which parameters were changed, and there is no point in guessing.

Stability Rate vs. Uptime

Uptime traditionally shows the share of time a service was considered available. The metric is convenient for reporting but crude: a service can respond and still return errors to some users. The name Stability Rate points to an assessment based on operation outcomes rather than the calendar. Avito gives the exact definition in the article, but the very fact that the two metrics are separated suggests a mature approach. Minutes of downtime and the share of failed operations describe different things, and the error budget depends on which of them you take as its basis.

How to Apply This Yourself

Even without implementation details, the publication offers several practical takeaways:

• Separate interface types. Synchronous calls, data buses and background operations need different SLIs. A single template gives you a pretty dashboard and a poor picture of reality.
• Do not confuse availability with success. If a team reports only Uptime, some degradations will stay invisible.
• Document deviations from the canon in writing. If you change the error budget model, record the reasons and limitations, or in a year nobody will remember why it was done.
• Tie NFRs to the architecture process. At Avito, this happens within Architecture Governance. Requirements verified at the design stage are cheaper than fixes after an incident.

The original Habr article is worth reading for anyone building SRE practices in a large distributed system. The example stands out because the company openly explains where and why it moved away from the generally accepted scheme.