Confiabilidade: SLOs, error budgets e incidentes

SLI, SLO e error budget

• SLI (service level indicator): uma medição do serviço como os usuários o percebem, como a fração de requisições que têm sucesso com rapidez suficiente.
• SLO (service level objective): a meta de um SLI em uma janela de tempo, por exemplo 99,9% das requisições com sucesso em até 300 ms em 30 dias.
• SLA (service level agreement): um contrato com consequências, geralmente mais frouxo que o SLO interno.
• Error budget: a não confiabilidade permitida (100% menos o SLO). Enquanto sobrar budget, entregue rápido; quando ele acabar, desacelere e invista em confiabilidade.

Por que isso muda as decisões

# SLI: proporção de requisições boas em 5 minutos
sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

# consumo rápido para um SLO de 99,9%: taxa de erros acima de 14,4x a permitida
(1 - (sum(rate(http_requests_total{status!~"5.."}[1h])) / sum(rate(http_requests_total[1h])))) > (14.4 * 0.001)

Resposta a incidentes

• Declare cedo e nomeie papéis: um incident commander que coordena, alguém que investiga, alguém que comunica.
• Mitigue primeiro, diagnostique depois: faça rollback, failover, desligue a flag.
• Comunique em intervalos regulares, mesmo quando não há nada de novo a dizer.
• Mantenha uma linha do tempo enquanto avança; ela é a matéria-prima da revisão.
• Faça um postmortem sem culpados: pergunte como o sistema permitiu a falha, não quem errou. Termine com ações específicas e com responsável.

Reduzindo o risco antes que ele aconteça

• Remova o toil: automatize operações manuais repetitivas para que as pessoas tenham tempo para engenharia.
• Teste a falha de propósito com game days e injeção de falhas.
• Planejamento de capacidade e testes de carga antes de o tráfego chegar.
• Runbooks para falhas conhecidas, mantidos em dia com o sistema.
• Degradação graciosa: quando uma dependência falha, faça menos, não nada.