Avito revela como calcula a confiabilidade e por que seu orçamento de erros difere do modelo do Google

Uma das maiores plataformas de internet da Rússia explicou publicamente como transforma a "confiabilidade" de slogan em números. Ivan Tarasov, TUL Architecture Governance na plataforma técnica do Avito, destrinchou no Habr toda a cadeia: de SLI, SLO e SLA até os requisitos não funcionais (NFRs) para serviços REST/RPC, barramentos de dados e operações customizadas. O texto dá destaque especial ao fato de que o orçamento de erros no Avito difere da descrição canônica do livro Google SRE. Segundo o autor, a diferença é uma decisão intencional.

Uma ressalva importante: temos em mãos apenas o anúncio do artigo. Os limites, as fórmulas e os argumentos concretos do Avito estão na versão completa. Por isso, analisamos abaixo a estrutura da abordagem e o contexto, sem recontar detalhes que não vimos.

O que compõe o sistema

Tarasov lidera equipes, e uma delas, a SLA, cria condições para elevar a confiabilidade técnica e desenvolve ferramentas de NFR e cenários de estabilidade. O anúncio indica o seguinte conjunto de elementos:

• SLI, SLO e SLA como hierarquia básica: o que medimos, que meta definimos e o que prometemos.
• Stability Rate e Uptime como duas métricas distintas, cuja diferença o autor analisa separadamente.
• NFRs para serviços REST/RPC, ou seja, requisitos para a comunicação síncrona.
• NFRs para barramentos de dados, onde a confiabilidade é medida de outra forma que em uma requisição com resposta.
• NFRs para operações customizadas, que não se encaixam nos modelos padrão.
• Um orçamento de erros que difere de propósito da versão do Google SRE.

A lista deixa claro o essencial: o Avito não se limita a um único número de "noves" por serviço. Cada tipo de interface ganha uma forma própria de medição.

Por que o modelo do Google não foi adotado como está

No livro Google SRE, o orçamento de erros é igual a um menos o SLO. Com uma meta de 99,9% em 30 dias, isso dá cerca de 43 minutos de indisponibilidade tolerada. Enquanto o orçamento não se esgota, a equipe lança releases livremente. Quando ele acaba, a prioridade passa para a estabilização. O mecanismo é simples e encerra a eterna disputa entre desenvolvimento e operação.

Na prática, esse modelo tem pontos fracos. Ele pressupõe que o SLO seja definido de forma significativa e que possa ser medido da mesma maneira em todos os serviços. Em uma empresa com centenas de serviços, filas, barramentos e operações fora do padrão, essa condição muitas vezes não se cumpre. O Avito afirma que levou isso em conta e alterou o modelo de propósito. Quais parâmetros exatamente foram modificados, o anúncio não mostra, e não vale a pena especular.

Stability Rate versus Uptime

O Uptime tradicionalmente mostra a fração do tempo em que o serviço foi considerado disponível. A métrica é conveniente para relatórios, mas grosseira: o serviço pode estar respondendo e, ainda assim, devolver erros para parte dos usuários. O nome Stability Rate indica uma avaliação pelo resultado das operações, e não pelo calendário. O Avito apresenta a definição exata no artigo, mas o simples fato de separar as duas métricas revela uma abordagem madura. Minutos de indisponibilidade e fração de operações malsucedidas descrevem coisas diferentes, e o orçamento de erros depende de qual delas se toma como base.

Como aplicar na sua empresa

Mesmo sem os detalhes de implementação, a publicação permite tirar algumas conclusões práticas:

• Separe os tipos de interface. Chamadas síncronas, barramentos de dados e operações em segundo plano exigem SLIs diferentes. Um modelo único gera um dashboard bonito e um retrato ruim da situação.
• Não confunda disponibilidade com sucesso. Se a equipe reporta apenas o Uptime, parte das degradações ficará invisível.
• Registre por escrito os desvios do modelo canônico. Se você muda o modelo de orçamento de erros, documente os motivos e as limitações. Caso contrário, em um ano ninguém vai lembrar por que isso foi feito.
• Vincule os NFRs ao processo de arquitetura. No Avito, isso é feito no âmbito do Architecture Governance. Requisitos verificados na fase de projeto saem mais baratos do que correções depois de um incidente.

O artigo original no Habr vale a leitura para quem constrói práticas de SRE em um grande sistema distribuído: o caso se destaca justamente porque a empresa explica abertamente onde e por que se afastou do esquema consagrado.