SLI, SLO e error budget, com contas

1. Por que não 100%

Cada "nove" a mais na disponibilidade (99%, 99,9%, 99,99%) custa muito mais caro que o anterior: mais redundância, mais testes, mudanças mais lentas. E, acima de certo ponto, o usuário nem percebe. O Wi-Fi da casa dele e o celular dele costumam falhar mais que o seu serviço.

Por isso o SRE troca "nunca cair" por uma meta combinada. O que sobra da meta vira um orçamento para mudar e experimentar.

2. SLI: o que medir

SLI (Service Level Indicator) é o indicador. Ele deve medir o que o usuário sente. O formato mais útil é uma proporção:

SLI = eventos bons / eventos válidos

Exemplo de disponibilidade:
  requisições com resposta de sucesso / todas as requisições

Exemplo de latência:
  requisições respondidas em menos de 300 ms / todas as requisições

Exemplos de bons SLIs: compras concluídas com sucesso, páginas carregadas em menos de 2 segundos, dados do painel atualizados há menos de 10 minutos. CPU, memória e número de pods não são SLIs: são causas internas, que podem ou não afetar alguém.

3. SLO: a meta

SLO (Service Level Objective) é a meta para o SLI, sempre numa janela de tempo. Por exemplo: "99,5% das requisições de checkout com sucesso, medido em 30 dias corridos".

Para escolher o primeiro SLO, olhe o histórico do serviço e pergunte ao time de produto quanto de falha os usuários aceitam. Comece com uma meta que o serviço já cumpre na maior parte do tempo. Dá para apertar depois.

4. Error budget: as contas

O error budget é 100% menos o SLO. Em 30 dias há 43.200 minutos. Veja quanto de falha total cada meta permite:

Na prática, falha raramente é total. Se o serviço recebe 1 milhão de requisições no mês e o SLO é 99,9%, o budget é de 1.000 requisições com erro, não importa se vieram todas juntas ou espalhadas.

5. A política do error budget

O budget só funciona se o time combinar antes o que fazer com ele. Um modelo simples:

1. Budget acima de 50%: deploys normais, experimentos liberados.
2. Budget entre 0% e 50%: deploys continuam, mas toda mudança arriscada
   precisa de plano de volta testado.
3. Budget esgotado: só entram correções de confiabilidade e de segurança
   até a janela recuperar. Produto e engenharia revisam juntos as causas.

Produto e operação decidem juntos, com um número na mesa, e não no grito.

6. SLA: o contrato com o cliente

SLA (Service Level Agreement) é um contrato com o cliente, com consequência se for quebrado, como crédito ou multa. O SLA fica mais folgado que o SLO interno. Assim o time percebe o problema e age bem antes de quebrar o contrato.

7. Missão final