Bem-vindo à aula sobre SLIs, SLOs e SLAs! Esses três acrônimos são pilares da engenharia de confiabilidade de sites (SRE) e essenciais para qualquer profissional de DevOps que deseja garantir que seus serviços atendam às expectativas dos usuários de forma mensurável e acionável. Nesta aula, vamos entender cada um deles, como se relacionam e como aplicá-los no dia a dia.

Se você já ouviu falar de SRE (Site Reliability Engineering), sabe que a confiabilidade não é algo subjetivo: ela precisa ser definida, medida e gerenciada. SLIs, SLOs e SLAs são as ferramentas que permitem fazer isso de forma objetiva, alinhando a equipe de desenvolvimento, operações e negócios em torno de metas claras.

Definições

Vamos começar pelas definições formais, mas de forma acessível:

  • SLI (Service Level Indicator): é uma métrica quantitativa que mede um aspecto específico da confiabilidade do serviço. Por exemplo, a latência de uma API, a taxa de erros, ou a disponibilidade (porcentagem de tempo em que o serviço está funcionando). Um SLI é algo que você pode medir diretamente e que reflete a experiência do usuário.
  • SLO (Service Level Objective): é uma meta ou alvo que você define para um SLI. Por exemplo, “a latência média deve ser menor que 200ms” ou “a disponibilidade deve ser de 99,9%”. O SLO é um acordo interno entre as equipes de engenharia e produto sobre o nível de confiabilidade desejado.
  • SLA (Service Level Agreement): é um contrato formal com o cliente (externo ou interno) que define as consequências (geralmente financeiras) caso o SLO não seja cumprido. Por exemplo, “se a disponibilidade cair abaixo de 99,9% em um mês, o cliente recebe um crédito”. O SLA é tipicamente mais rigoroso que o SLO, pois envolve obrigações legais ou comerciais.

É importante notar que os três trabalham juntos: você mede um SLI, define um SLO como meta e, se aplicável, formaliza um SLA com base nesse SLO. A diferença crucial é que o SLA é um compromisso externo, enquanto o SLO é um compromisso interno.

Error budgets

O conceito de error budget (orçamento de erro) é uma das ideias mais poderosas do SRE. Ele deriva diretamente do SLO: se você define um SLO de 99,9% de disponibilidade, isso significa que você pode ficar fora do ar por 0,1% do tempo em um período (por exemplo, 43 minutos por mês). Esse tempo “permitido” de falha é o seu error budget.

O error budget serve para tomar decisões sobre o equilíbrio entre inovação e confiabilidade. Quando o error budget está alto (ou seja, você está longe de estourar), a equipe pode se sentir à vontade para lançar novos recursos, fazer deploys mais arriscados ou experimentar. Quando o error budget está baixo (próximo de zero), a prioridade deve ser a estabilidade: pausar lançamentos, focar em correções e reduzir o ritmo de mudanças.

Na prática, o error budget é calculado como: (1 - SLO) multiplicado pelo período. Por exemplo, para um SLO de 99,9% em um mês de 30 dias (720 horas), o error budget é de 0,1% de 720 horas = 0,72 horas = 43,2 minutos. Se o serviço ficar indisponível por mais de 43 minutos no mês, o error budget foi estourado.

# Exemplo de cálculo de error budget mensal para SLO de 99,9%
# Período: 30 dias
# Total de minutos no mês: 30 * 24 * 60 = 43200
# Error budget = (1 - 0.999) * 43200 = 0.001 * 43200 = 43.2 minutos

Gerenciar o error budget é uma prática que ajuda a evitar o conflito clássico entre desenvolvimento (que quer lançar rápido) e operações (que quer estabilidade). Em vez de discutir subjetivamente, você tem um número objetivo que orienta as decisões.

Como definir

Definir SLIs, SLOs e SLAs não é uma tarefa trivial, mas pode ser feita seguindo um processo estruturado. Aqui estão as etapas principais:

  1. Escolha os SLIs relevantes: identifique os aspectos do serviço que mais impactam a experiência do usuário. Os mais comuns são disponibilidade, latência, throughput (vazão) e taxa de erros. Para cada um, defina uma métrica clara. Por exemplo, para disponibilidade, você pode medir o percentual de requisições bem-sucedidas; para latência, o percentil 95 (p95) ou a média.
  2. Defina os SLOs com base em dados históricos e expectativas de negócio: olhe para o desempenho passado do sistema e para o que é aceitável para o usuário. Um SLO muito agressivo pode ser caro de manter; muito frouxo pode prejudicar a confiança. Comece com metas realistas e ajuste ao longo do tempo.
  3. Formalize os SLAs quando necessário: se você tem clientes externos ou contratos internos, transforme os SLOs mais importantes em SLAs, com penalidades claras. Lembre-se de que o SLA deve ser alcançável; não adianta prometer 100% de disponibilidade se isso é impossível.
  4. Implemente monitoramento e alertas: para medir SLIs, você precisa de ferramentas de observabilidade (como Prometheus, Grafana, Datadog, New Relic, etc.). Configure dashboards e alertas para acompanhar os SLIs em tempo real e saber quando os SLOs estão em risco.
  5. Revise e ajuste periodicamente: os SLOs não são imutáveis. À medida que o sistema evolui, os padrões de uso mudam, e você deve revisar os SLOs regularmente (por exemplo, a cada trimestre) para garantir que ainda fazem sentido.

Uma dica importante: comece com poucos SLIs (3 a 5) para não sobrecarregar a equipe. É melhor ter poucos indicadores bem monitorados do que muitos sem ação.

Exemplos

Vamos ver exemplos práticos de SLIs, SLOs e SLAs para diferentes tipos de serviço.

Exemplo 1: API REST

  • SLI: disponibilidade da API, medida como a porcentagem de requisições que retornam status 2xx ou 3xx em um minuto.
  • SLO: 99,9% de disponibilidade em 30 dias.
  • SLA: se a disponibilidade for menor que 99,9% em um mês, o cliente recebe 10% de crédito na próxima fatura.

Também podemos definir um SLI de latência: o p95 da latência deve ser menor que 500ms. SLO: 95% das requisições devem ter latência abaixo de 500ms.

Exemplo 2: Banco de dados

  • SLI: disponibilidade do banco, medida pela capacidade de aceitar conexões.
  • SLO: 99,95% de disponibilidade (aprox. 22 minutos de indisponibilidade por mês).
  • SLA: se a disponibilidade cair abaixo de 99,95%, a equipe de infraestrutura deve pagar multa simbólica (em termos de créditos internos).

Exemplo 3: Site de e-commerce

  • SLI: taxa de erros de checkout (por exemplo, falhas ao finalizar compra).
  • SLO: menos de 0,1% de erros no checkout por dia.
  • SLA: não há SLA externo, mas internamente a equipe de pagamentos deve ser acionada imediatamente se o erro exceder 0,5%.

Esses exemplos mostram como os conceitos se aplicam a diferentes cenários. O importante é que os SLIs sejam mensuráveis, os SLOs sejam realistas e os SLAs sejam acionáveis.

Boas práticas e observações finais

Ao trabalhar com SLIs, SLOs e SLAs, algumas boas práticas podem ajudar:

  • Comece pequeno: não tente definir SLOs para tudo de uma vez. Escolha os serviços mais críticos.
  • Use percentis em vez de médias: médias podem esconder problemas (ex.: 99% das requisições são rápidas, mas 1% é extremamente lenta). Percentis como p95 ou p99 são mais representativos.
  • Automatize o monitoramento: ferramentas como Prometheus e Grafana são suas aliadas. Configure alertas baseados em SLOs (por exemplo, usando o Prometheus com a função histogram_quantile).
  • Comunique os SLOs: todos na equipe devem conhecer os SLOs e o error budget. Isso cria uma cultura de confiabilidade.
  • Revise regularmente: o mundo muda, e seus SLOs devem acompanhar.

Exercícios

  1. Explique com suas palavras a diferença entre SLI, SLO e SLA, e dê um exemplo de cada para um serviço de streaming de vídeo.

    2. ✓ Resposta: SLI é a métrica (ex.: taxa de rebuffering). SLO é a meta (ex.: menos de 2% de rebuffering). SLA é o contrato (ex.: se rebuffering > 5%, cliente recebe desconto).
  2. Calcule o error budget mensal para um SLO de 99,95% de disponibilidade em um mês de 31 dias. Mostre os cálculos.

    3. ✓ Resposta: Total de minutos em 31 dias: 31 * 24 * 60 = 44640. Error budget = (1 - 0.9995) * 44640 = 0.0005 * 44640 = 22.32 minutos.
  3. Dado um serviço com SLI de latência p95, como você definiria um SLO e que tipo de alerta você configuraria?

    4. ✓ Resposta: Exemplo: SLO: p95 < 300ms. Alerta: quando o p95 ultrapassar 300ms por 5 minutos, disparar alerta crítico.
  4. Por que é importante ter um error budget e como ele ajuda na tomada de decisão sobre lançamentos?

    5. ✓ Resposta: O error budget define um limite de falhas aceitável. Se ainda há orçamento, a equipe pode lançar novos recursos com mais confiança; se estourou, deve priorizar estabilidade.
  5. Descreva um cenário em que um SLO pode ser muito agressivo e quais as consequências práticas para a equipe.

    6. ✓ Resposta: Um SLO de 99,999% de disponibilidade (menos de 5 minutos de downtime por ano) pode levar a custos altíssimos, sobrecarga da equipe e medo de mudanças, reduzindo a inovação.

Referências