SLO para um time de cinco pessoas

Service level objectives têm fama de coisa de empresa grande. Error budget, burn rate, documento de política, um time de confiabilidade dedicado para tocar as reuniões. Um time de cinco pessoas lê sobre isso e conclui, com razão, que não é para ele. Essa conclusão está errada, e o motivo é que SLO não é a maquinaria em volta. É uma frase única que encerra uma discussão.

A discussão é a que todo time pequeno tem: a gente publica a feature ou corrige a instabilidade? Sem SLO, essa discussão é decidida por quem fala mais alto naquela semana. Com SLO, é decidida por um número.

A frase

'Noventa e nove vírgula cinco por cento das requisições de checkout completam com sucesso em até dois segundos, medidas em trinta dias.' Isso é um SLO. Nomeia algo voltado ao usuário, uma definição de bom, um alvo e uma janela. Todo o resto da literatura de SLO é elaboração dessa frase.

Escolher a coisa: pegue a única ação do usuário cuja falha mais dói. Não a API em geral, não uptime, o checkout, o agendamento, a busca. Uma coisa só. Dá para adicionar uma segunda depois.

Escolher a definição de bom: uma requisição é boa se retorna status de sucesso dentro de um limite de latência. As duas condições, porque sucesso lento é falha na cadeira do usuário. O limite de latência é o que faz o produto parecer quebrado, geralmente de um a três segundos para uma ação interativa.

Escolher o alvo: olhe os últimos trinta dias de dados e veja o que você já atinge. Se é 99,7 por cento, defina o alvo em 99,5. Um SLO que você já cumpre com uma folga pequena é útil. Um aspiracional é desejo. Um SLO de 99,99 para um time de cinco é desejo com pager preso.

O orçamento

A diferença entre o alvo e cem é o error budget. Em 99,5 por cento em trinta dias, você tem mais ou menos três horas e meia de falha total, ou um trecho bem mais longo de falha parcial, antes de perder o objetivo. Esse número é o ponto inteiro. Ele converte confiabilidade de sentimento em recurso que se gasta.

Quando o orçamento está saudável, publique features, corra riscos, faça deploy na sexta se quiser. Quando o orçamento está quase gasto, o próximo sprint é trabalho de confiabilidade, e isso não é negociação, porque todo mundo concordou com a frase antes. Essa regra, combinada antes da discussão, é o que faz um SLO funcionar num time sem organização de confiabilidade.

O que é preciso para medir

Menos do que as pessoas esperam. Você precisa de uma contagem de requisições para a ação escolhida, uma contagem das que foram boas e a capacidade de calcular a proporção numa janela deslizante. Se você já tem logs estruturados ou métricas de requisição na borda, isso é uma query. Coloque a proporção num dashboard com o alvo desenhado como linha. Adicione um único alerta: se o orçamento está queimando rápido o suficiente para acabar em poucos dias, avise alguém. Essa é a implementação inteira.

Não construa alerta de burn rate com múltiplas janelas no primeiro dia. Não escreva documento de política. Não crie dashboard com quinze SLOs. Uma frase, um gráfico, um alerta, uma regra.

Onde times pequenos erram

• Escolher uptime do servidor em vez de sucesso de uma ação do usuário, então o SLO fica verde enquanto o usuário não consegue finalizar a compra.
• Definir o alvo pela ambição em vez do histórico medido, então o orçamento está sempre gasto e a regra é sempre ignorada.
• Medir na aplicação em vez da borda, então timeout no load balancer nunca conta como falha.
• Pular a regra sobre o que acontece quando o orçamento acaba, então o SLO vira um número em que ninguém age.

O valor de um SLO para um time de cinco não é a medição. É que a medição toma por você uma decisão pela qual você brigaria a cada duas semanas. Uma frase, combinada num momento calmo, substitui uma dúzia de discussões em momentos tensos. Isso vale uma tarde de setup em qualquer tamanho de time.