O que é SLO? Guia prático para devs que trabalham sozinhos

O que é SLO? É um número que você promete a si mesmo sobre com que frequência o seu serviço deve funcionar, medido em uma janela de tempo fixa. "99.9% das requisições dão certo em 30 dias" é um SLO. Ele transforma "o site parece bem" em algo que você consegue verificar, e mostra quando parar de lançar funcionalidades para corrigir o que está quebrado.

Você não precisa de um time de plataforma para isso. Um dev sozinho, com uma API e um banco Postgres, consegue escrever um SLO útil em uma tarde. Aqui vai o que o termo significa, como escolher o número e onde ele costuma dar errado.

O app caiu às 2 da manhã e ninguém sabia

Imagine um projeto paralelo com 400 usuários semanais. Numa noite, o endpoint de checkout começa a responder com erro 500 por cerca de 20 minutos. Ninguém twittou, ninguém mandou e-mail. Você descobre três dias depois, por causa de uma única mensagem de suporte.

Isso foi grave? Sem uma meta, não dá para responder. Com uma meta, dá: se o seu SLO permite cerca de 43 minutos de falha por mês e você acabou de consumir 20, sabe que gastou quase metade da cota numa noite ruim. É esse o sentido do SLO. Ele troca uma sensação por um orçamento.

SLI, SLO e SLA, sem o tom de glossário

Todo mundo mistura SLI, SLO e SLA, então aqui vai a versão curta.

Um SLI (service level indicator) é uma medição. "Porcentagem de requisições HTTP que não retornaram 5xx nos últimos 30 dias" é um SLI. É uma razão entre eventos bons e o total de eventos.

Um SLO (service level objective) é a meta para essa medição. "Essa razão precisa ficar em 99.9% ou acima" é o SLO. Ele é interno. Você define, pode mudar e ninguém processa você por causa dele.

Um SLA (service level agreement) é um contrato com consequências, normalmente reembolso ou créditos. A maioria dos projetos paralelos não tem SLA, e tudo bem. Dá para rodar SLOs sem ele. O capítulo do workbook de SRE do Google sobre implementar SLOs é a referência padrão se você quiser a versão longa.

A ordem importa: escolha o SLI primeiro, depois o SLO, e só pense em SLA se um cliente pagante exigir isso por escrito.

Error budget: a parte que muda como você trabalha

Um SLO de 99.9% também significa que 0.1% dos eventos podem falhar. Essa margem é o seu error budget, e é a metade útil da ideia.

Em um mês de 30 dias, 99.9% de disponibilidade deixa cerca de 43 minutos de indisponibilidade permitida. A conta é 30 dias vezes 24 horas vezes 60 minutos, o que dá 43.200 minutos, vezes 0.001. Uma meta de 99% dá cerca de 7.2 horas. Uma meta de 99.99% dá cerca de 4.3 minutos.

Esses dois últimos números explicam por que a maioria dos projetos pequenos não deve mirar alto. Quatro minutos por mês significa que um deploy ruim seguido de rollback já quebra a meta. Na prática, quanto mais alto você mira, mais do seu tempo vai para defender o número em vez de construir o produto.

O budget também dá uma regra para decidir o que construir em seguida. Budget quase intacto: lance a funcionalidade arriscada. Budget consumido: corrija primeiro o que está instável. Não precisa de reunião, só de um número no painel.

Vamos a um exemplo com números reais. Suponha um SLO de 99.5% de disponibilidade em 30 dias e cerca de 600.000 requisições por mês. A meta permite 0.5% de falhas, ou seja, 3.000 requisições com erro antes de o budget acabar.

No dia 9, uma migração ruim devolve 500 por 25 minutos e custa 1.100 requisições com falha. Você já gastou cerca de 37% do budget em uma noite. No dia 17, uma API de terceiros expira e consome mais 900. Agora você está em cerca de 67% gastos, com 13 dias restantes.

É aí que o budget faz o trabalho dele. Você não precisa entrar em pânico, mas também não deve subir a refatoração arriscada que tinha planejado para o dia 20. Coloca um timeout e um fallback na chamada de terceiros, escreve a checagem da migração que pulou e empurra a refatoração para o mês seguinte.

A lição não é que falhas são ruins. Falhas são esperadas e já estão previstas no número. O que a meta dá é uma resposta calma e compartilhada para "podemos bancar esse risco agora?", mesmo quando a única pessoa na sala é você.

Como escolher um SLI que dá para medir

Comece pelo que um usuário chamaria de "quebrado". Em uma aplicação web, isso geralmente se resume a duas perguntas: a requisição deu certo e foi rápida o bastante?

Para a maioria dos projetos pequenos, dois SLIs cobrem 90% do valor:

• Disponibilidade: requisições boas divididas pelo total, em que "boa" significa resposta sem 5xx.

• Latência: a fração de requisições respondidas abaixo de um limite, por exemplo 95% das requisições abaixo de 500 ms.

Repare que a latência é escrita como fração de requisições abaixo de um limite, e não como média. A média esconde a cauda lenta, e a cauda lenta é onde o usuário desiste. Pensar em percentis importa: uma média de 300 ms pode conviver com um p99 de 4 segundos.

Meça na borda do sistema, o mais perto possível do usuário. Um health check que bate em /healthz de dentro da mesma VPC diz que o processo está vivo, não que o usuário consegue fazer login. Se só der para fazer uma medição, teste um caminho real do usuário, como login ou checkout, a partir de fora.

Um SLO é só monitoramento de uptime com passos extras? Em parte, os dois se sobrepõem. Um monitor de ping diz que o site respondeu em determinado minuto. Um SLO diz qual fração das requisições reais deu certo em um mês e o que isso muda na sua próxima decisão. Imagine duas semanas em que o ping fica verde o tempo todo, mas uma consulta lenta no banco faz a página de dashboard estourar timeout para 3% dos usuários logados. O monitor diz que está tudo bem. O SLI diz que você errou a meta de latência. Só um dos dois muda o que você faz na segunda-feira.

Mantenha o monitor de ping mesmo assim. Ele é barato e pega quedas totais rápido. Só trate como uma entrada, não como a definição de "funcionando".

Escolha o número: comece mais baixo do que parece

A resposta honesta para um projeto novo é 99% ou 99.5%. Olhe os últimos 30 dias de dados, descubra o que você de fato entregou, defina o SLO um pouco abaixo disso e aperte depois, se os usuários reclamarem.

Um guia aproximado para um projeto solo:

• Ferramenta de hobby, sem receita: 99% basta. Cerca de 7 horas de falha por mês são invisíveis para a maioria dos usuários.

• SaaS pago com algumas dezenas de clientes: entre 99.5% e 99.9%, dependendo de quão sensível ao tempo é o produto.

• Qualquer coisa de que clientes dependem em horário comercial: 99.9%, e teste o caminho de rollback antes de prometer qualquer coisa.

Testado, não ótimo, mas vale a pena de qualquer forma: um SLO que você cumpre 100% das vezes está definido baixo demais, e um SLO que você erra todo mês é um número em que ninguém confia. Mire em errar de vez em quando, porque é aí que o budget faz o trabalho dele.

Três erros tornam um SLO inútil.

Medir o que é fácil em vez do que o usuário sente. Uso de CPU não é um SLI. O usuário não se importa se a CPU está em 40%. Ele se importa se a página carregou.

Definir a meta pela ambição. "Queremos cinco noves" soa sério e não significa nada se o seu banco é uma única instância numa VM pequena. Defina o SLO a partir da realidade observada, depois melhore o sistema e só então aperte o número.

Nunca usar o budget. Se você fecha todo mês com 98% do budget sobrando, está lançando devagar demais ou a meta está frouxa. Budget não usado é capacidade de risco desperdiçada.

Revisite o número uma vez por trimestre, ou depois de qualquer mês em que você errou feio ou nunca tocou no budget. Errar duas vezes seguidas significa que o sistema precisa de trabalho de verdade ou que a meta era ambiciosa para a fase em que você está. Os dois são fatos úteis.

Alerta por burn rate, não por cada oscilação

O erro que quase todo mundo comete é alertar sempre que a taxa de erro passa de um limite. Você acorda às 3 da manhã por um pico de 90 segundos que custou 0.2% do budget do mês.

Burn rate resolve isso. Ele pergunta com que velocidade você está consumindo o budget, comparado ao ritmo que o esgotaria exatamente no fim da janela. Burn rate 1 significa que você termina o mês com o budget zerado e sem surpresas. Burn rate 10 significa que ele acaba em três dias.

Um setup sensato para uma pessoa só são dois alertas. Um rápido, por exemplo burn rate acima de 10 durante uma hora, que te acorda. Um lento, por exemplo burn rate em torno de 2 durante um dia, que vira um ticket para a manhã seguinte. O capítulo do livro de SRE do Google sobre objetivos de nível de serviço explica o raciocínio por trás disso, e a versão com múltiplas janelas está no workbook citado acima.

Um SLO pequeno que você escreve hoje

Você não precisa de fornecedor para começar. Escreva isto no seu repositório, em um arquivo chamado SLO.md:

service: checkout-api
window: 30d
slis:
  availability:
    good: http_status < 500
    total: all requests except /healthz
  latency:
    good: response_time < 500ms
    total: all requests except /healthz
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - freeze non-urgent features
  - fix the top error source first

Se a sua stack já exporta contagens de requisições, o SLI de disponibilidade em sintaxe estilo Prometheus cabe em uma linha:

sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

Essa razão, comparada com a sua meta, é todo o seu painel de SLO. O resto é acabamento. Três painéis bastam: SLI atual, budget restante e uma linha de burn rate.

Qual ferramenta usar quando você é o time de ops inteiro

Você pode rodar SLOs numa planilha e um cron job durante um mês, enquanto descobre o que importa para você. Quando os números passarem a importar, uma ferramenta se paga. Três valem a pena olhar, com a ressalva de que a sua stack pesa mais do que a lista de funcionalidades.

Grafana é a escolha padrão para quem já exporta métricas do Prometheus. O plano gratuito é generoso para um projeto paralelo, e a funcionalidade de SLO fica em cima de dados que você provavelmente já tem. Pule se ainda não tiver um pipeline de métricas e nenhuma vontade de construir um.

New Relic tem um plano gratuito com 100 GB de ingestão de dados por mês e ferramentas de SLO integradas à plataforma. Serve se você quer uma configuração baseada em agente com pouca configuração. O custo é que fica menos previsível quando você passa da franquia gratuita.

Datadog é a opção mais completa e também a mais cara, com infraestrutura, APM e logs cobrados separadamente. Vale a pena se um time está crescendo ao seu redor. Pule se for um projeto solo, a não ser que outra pessoa esteja pagando.

Qualquer que seja a escolha, resista à vontade de definir quinze SLOs no primeiro dia. Um SLO de disponibilidade e um de latência por serviço voltado ao usuário já bastam para aprender.

Escolha um endpoint que os usuários notariam se quebrasse. Escreva o SLI em linguagem simples, defina a meta 0.5 ponto abaixo do que você entregou no mês passado e confira de novo em 30 dias. Qual dos seus serviços você confiaria menos hoje?