Pular para o conteúdo principal

SLI, SLO, SLA e Error Budget

Ao falar em DevOps, o objetivo é entregar os projetos da melhor forma possível e criar a melhor experiência para o usuário. Mas para saber se estamos atingindo esse objetivo é necessário medir.

Nem sempre o que achamos que está bom de fato é bom.

SLI, SLO, SLA e Error Budget ajudam a alinhar as expectativas como seu usuário. São os pilares para medir a entrega e a qualidade de qualquer serviço de TI.

É necessário alinhar com a sua equipe esses níveis de serviço para ter sucesso. São usados para medir e estabelecer metas para a qualidade da aplicação e da sua infraestrutura, além de alinhar com o usuário o desempenho e a disponibilidade do produto que vamos entregar.

Eficiência e Confiabilidade são peças chaves no mundo DevOps sendo o diferencial entre o serviço bom e o excelente.

Aprender sobre essas siglas envolve a melhoria contínua da aplicação.

SLI (Service Level Indicator)​

O indicador de nível de serviço são as métricas que definem o bom funcionamento do sistema. Tudo depende de qual tipo de sistema estamos falando, mas se colocando no lugar do usuário, o que seria um bom sistema funcionando? Algumas métricas que poderiam ser consideradas para medir um desempenho. Não precisa usar todas, fica só como ideia, pois cada sistema é um sistema diferente.

  • Tempo de carregamento da página. Uma espera de mais de 3 segundos pode fazer um cliente desistir de uma compra. Poderíamos criar uma métrica para medir o percentual de vezes que a página carrega em menos de 2 segundos. O que poderíamos fazer para melhorar esse percentual?
    • Melhorar o tamanho das imagens?
    • Melhorar a infraestrutura do servidor?

Exemplos:

  • Disponibilidade: Percentual de tempo que o serviço esteve disponível (uptime).
    • Exemplo de valor de métrica: 99.9%.
  • Latência: Tempo médio de resposta de uma API (em milissegundos).
    • Exemplo de valor de métrica: p95 ≤ 200ms.
  • Erro/Taxa de Sucesso: Percentual de requisições bem-sucedidas.
    • Exemplo de valor de métrica: HTTP 2xx / Total Requests.
  • Taxa de Falhas/Percentual de erros: (HTTP 4xx e 5xx) em relação ao total de requisições. Exemplo: Erros ≤ 1%.
  • Throughput: Número de requisições processadas por segundo (RPS).
    • Exemplo de valor de métrica: 500 RPS.
  • Capacidade: Utilização média de recursos, como CPU, memória ou banco de dados.
    • Exemplo: Uso de CPU ≤ 75%.
  • Saturação: Percentual de uso de filas ou conexões simultâneas.
    • Exemplo: ≤ 90% de conexões simultâneas.
  • Retentividade: Percentual de usuários que retornam ao serviço.
    • Exemplo de valor de métrica: ≥ 70% dos usuários retornam em 30 dias.

SLO (Service Level Objective)​

É a meta de desempenho que queremos alcançar nos indicadores SLIs. Poderíamos definir que o SLO para o SLI de carregamento da página principal fosse 90%, ou seja, ela carrega 90% das vezes em menos de 2 segundos.

100% não existe, é utopia! Picos de tráfego existem, problemas no hardware acontecem, ataques acontecem, etc. Vamos ser realistas, nem a AWS garante 100%, quem dirá nós.

Exemplos de SLOs:

  • Disponibilidade: O sistema deve estar disponível pelo menos 99.95% do tempo em um mês.
  • Latência: 95% das requisições devem ter latência menor ou igual a 200ms.
  • Erro/Taxa de Sucesso: Pelo menos 99.9% das requisições devem retornar códigos 2xx.
  • Taxa de Falhas: O percentual de erros 5xx deve ser menor ou igual a 0.5% por semana.
  • Throughput: O sistema deve processar pelo menos 10.000 RPS durante picos de uso.
  • Capacidade: A utilização de CPU/memória não deve exceder 80% durante 99% do tempo.
  • Saturação: As filas de mensagens não devem exceder 90% de utilização por mais de 5 minutos consecutivos.
  • Retentividade: Pelo menos 75% dos usuários devem voltar a usar o serviço no prazo de 30 dias.

SLA (Service Level Agreements)​

Os SLA são acordos de níveis de serviço. São contratos formais entre prestadores de serviço e seus clientes que detalham todo o serviço prometido, os padrões de desempenho e as consequências caso o prometido não seja cumprido.

Na maioria das vezes quando o objetivo não é atingido envolve pagamento de multa, desconto na fatura e até quebra de contrato.

É comum que o SLA não seja o mesmo valor do SLO para que exista uma folga para trabalhar e uma margem de erro.

Error Budget​

O Error Budget é a quantidade de falhas ou indisponibilidades aceitáveis que um sistema pode ter em um determinado período de tempo sem violar o SLO.

Por exemplo:

  • SLO de disponibilidade: 99.9%.
  • Tempo total em um mês: 30 dias = 43.200 minutos.
  • Tempo permitido de indisponibilidade (Error Budget): 43.200 x (1 - 0.999) = 43.2 minutos.

Neste caso, o sistema pode estar indisponível por até 43.2 minutos no mês sem quebrar o SLO. Ou seja, é a folga que temos.

Esse valor incentiva o equilíbrio entre inovação e estabilidade. Quando há possibilidade, pode-se priorizar a entrega de novas funcionalidades mesmo que aumente o risco de instabilidade. É uma forma de ajudar a tomar decisões baseadas em dados e definir limites operacionais.

Saber definir SLIs e SLOs é importante no papel do DevOps e pode ser um grande diferencial.

Não adianta começar com muitos SLIs e SLOs, defina poucos e aqueles que são mais importantes para o projeto, os stakeholders e os clientes. Ao longo do caminho, conhecendo melhor a capacidade da equipe, os números devem ser cada vez mais desafiadores e eles devem ser de responsabilidade de TODOS.

A dica é tentar iniciar com SLOs menores e ir ajustando e nunca prometer um SLA que você não possa cumprir.