SRE para equipes pequenas: SLIs, SLOs e orçamento de erro

Uma equipe pequena não precisa copiar a estrutura de uma big tech para aplicar SRE. Precisa medir a experiência certa e definir o que fazer quando ela piora.

Workshop: qual falha realmente importa para a equipe? Uma equipe de seis pessoas mantém uma plataforma de atendimento. Ela monitora: CPU; memória; espaço em disco; quantidade de containers; tempo de resposta do banco; disponibilidade dos servidores; tamanho das filas. Os painéis estão verdes, mas alguns usuários não conseguem concluir o envio de uma solicitação. O backend responde, o banco está disponível e os processos continuam ativos. O problema aparece somente na etapa final, quando um serviço externo demora e a operação expira. A equipe possui muitas métricas e nenhuma definição objetiva de serviço saudável. É nesse ponto que práticas de Site Reliability Engineering, ou SRE, podem ser úteis. Não é necessário criar um departamento, adotar dezenas de ferramentas ou estabelecer plantão 24 horas imediatamente. A primeira aplicação prática é mais simples: escolher uma experiência importante, medi la de forma consistente e registrar qual nível de falha a organização aceita antes de mudar suas prioridades. Primeira rodada: escolha uma jornada, não um servidor A pergunta inicial do workshop não deve ser: Qual disponibilidade do nosso cluster queremos? Comece por: Qual tarefa o usuário precisa conseguir concluir? No exemplo: Enviar uma solicitação de atendimento e receber confirmação. A jornada pode envolver navegador, API, banco, fila e provedor de mensagens. Um indicador restrito ao servidor web não representa a experiência completa. Outros exemplos de jornadas: entrar na conta; concluir um pedido; gerar um relatório; enviar uma mensagem; consultar uma fatura; restaurar um arquivo; publicar uma nova versão. Uma equipe pequena deve começar com uma ou duas jornadas críticas. O Google SRE Book recomenda selecionar poucos indicadores representativos em vez de transformar toda métrica coletada em indicador de nível de serviço. Segunda rodada: transforme a jornada em SLI SLI significa Service Level Indicator , ou indicador de nível de serviço. É uma medida quantitativa de uma característica relevante do serviço. Um SLI de sucesso pode ser: Exemplo: A definição precisa deixar claro: qual evento entra no denominador; o que é considerado sucesso; quais erros contam; onde a medição ocorre; qual janela é analisada; quais exclusões são legítimas. Uma especificação inicial: Esse arquivo é ilustrativo. O formato importa menos do que a definição compartilhada. O que excluir Uma requisição malformada pode retornar 400 . Ela deve consumir orçamento? Depende. Se o erro resulta de uma integração oficial mal documentada, a experiência está falhando mesmo que a API classifique o problema como erro do cliente. Se alguém envia tráfego aleatório a uma rota inexistente, incluir essas tentativas pode distorcer o indicador. As exclusões precisam ser: explícitas; justificadas; estáveis; auditáveis; difíceis de manipular. Não retire eventos do cálculo apenas porque deixam o gráfico pior. Terceira rodada: defina o SLO SLO significa Service Level Objective , ou objetivo de nível de serviço. É a meta estabelecida para um SLI. Exemplo: Em uma janela móvel de 28 dias, pelo menos 99,5% das solicitações válidas devem ser confirmadas em até 30 segundos. A formulação contém: experiência; população; limite; percentual; janela; fonte de medição. Compare: O sistema deve ser estável. com: 99,5% das solicitações válidas serão confirmadas em até 30 segundos, medido no backend durante uma janela móvel de 28 dias. A segunda versão permite verificar se o objetivo foi cumprido. SLI, SLO e SLA não são sinônimos Termo Função SLI Mede uma característica do serviço SLO Define a meta para essa medição SLA Estabelece compromisso e consequências entre partes Um SLA pode prever crédito, ressarcimento ou outra consequência contratual. Um SLO interno pode existir sem qualquer penalidade formal. A distinção é importante porque nem toda meta operacional deve virar promessa comercial. Quarta rodada: calcule o orçamento de erro Se o SLO é 99,5%, a fração de falha tolerada é: Esse é o orçamento de erro. Com 600 mil eventos válidos na janela: O orçamento não é autorização para ignorar três mil pessoas. Ele representa a margem de risco assumida na meta definida. Se o serviço apresentar 1.500 eventos ruins, consumiu metade do orçamento. Se apresentar 3.000, esgotou a margem. Se apresentar 4.000, violou o SLO. Objetivos baseados em tempo Para um indicador puramente temporal, 99,9% em 30 dias equivale aproximadamente a 43,2 minutos fora do objetivo: Essa equivalência não deve ser aplicada automaticamente a SLIs baseados em requisições. Dez minutos em horário de pico podem afetar muito mais eventos do que uma hora durante a madrugada. Escolha a unidade que representa o uso real. Por que não escolher 100% Uma meta absoluta costuma produzir uma destas consequências: custo desproporcional; deploys excessivamente lentos; resistência a qualquer mudança; alertas permanentes; objetivo impossível de cumprir; manipulação da forma de medição. O capítulo de SLOs do Google recomenda trabalhar com uma margem de falha e evitar objetivos absolutos. A confiabilidade possui custo, e o alvo precisa refletir o valor do serviço. Uma página institucional e uma API usada para autorizar pagamentos não precisam do mesmo objetivo. Quinta rodada: escreva a política antes do incidente O orçamento só muda decisões quando existe uma política. Exemplo: A política deve ser aprovada por tecnologia e negócio. Caso contrário, o conflito reaparece durante a crise: produto quer publicar; operação quer congelar; direção quer uma previsão; ninguém possui regra acordada. O Google SRE Workbook apresenta políticas de orçamento como mecanismo para decidir quando reduzir mudanças e concentrar esforço em confiabilidade. Congelamento não precisa ser absoluto Uma política madura distingue: correções de segurança; recuperação; alterações que reduzem risco; demandas regulatórias; recursos comerciais adiáveis; mudanças cosméticas. Bloquear uma correção crítica porque o orçamento foi esgotado seria contraproducente. Sexta rodada: acompanhe a velocidade de consumo Burn rate, ou taxa de consumo, compara a taxa observada de falhas com a taxa permitida pelo SLO. Para um SLO de 99,9%: Se a taxa observada é 1%: O orçamento está sendo consumido dez vezes mais rápido do que o sustentável. O capítulo sobre alertas de SLO mostra como burn rate ajuda a detectar falhas grandes rapidamente sem alertar por cada erro isolado. Duas janelas evitam extremos Um alerta pode usar: janela longa para confirmar impacto sustentado; janela curta para confirmar que a falha continua acontecendo. Exemplo conceitual: A janela longa evita reação a um pico mínimo. A curta evita alertar sobre um problema que já terminou. Os limites precisam ser calibrados. Copiar valores de outra organização sem considerar volume, SLO e capacidade de resposta cria ruído. O desafio dos serviços com pouco tráfego Considere uma rotina executada dez vezes por dia. Uma falha representa 10% naquele conjunto. O percentual varia muito e pode não produzir volume suficiente para análises rápidas. Alternativas: combinar contagem absoluta e percentual; utilizar janelas maiores; executar transações sintéticas; acompanhar atraso máximo; alertar por ausência de processamento; revisar eventos individualmente; usar objetivos baseados em lotes. Exemplo: O próprio material do Google alerta que mecanismos baseados em burn rate exigem cuidado em serviços de baixo tráfego. Alertas devem indicar uma ação possível A documentação do Prometheus recomenda alertas simples, orientados a sintomas e vinculados a algo que alguém possa fazer. Página imediata Use quando: há impacto significativo agora; a ação não pode esperar; existe responsável; há runbook. Ticket Use quando: o orçamento está diminuindo lentamente; existe risco futuro; a correção pode ocorrer no horário normal. Dashboard Use quando: o dado é útil para análise; não há ação imediata. Não acorde alguém porque a CPU chegou a 82% se a experiência continua dentro do objetivo e nenhuma ação urgente é necessária. Um painel suficiente para começar Uma equipe pequena pode operar com cinco blocos: Acrescente: versão ativa; deploys; incidentes; volume; origem dos dados. A observabilidade orientada à decisão precisa fornecer a telemetria, mas o painel não deve virar uma coleção de todos os gráficos disponíveis. O primeiro SLO não precisa ser perfeito Plano de quatro semanas: Semana 1 — escolher identificar uma jornada; conversar com usuários e suporte; definir sucesso e falha; localizar dados existentes. Semana 2 — medir instrumentar eventos; validar contagens; comparar backend e experiência; documentar exclusões. Semana 3 — propor observar baseline; definir alvo inicial; calcular orçamento; obter concordância das partes. Semana 4 — operar criar painel; configurar alertas; escrever política; executar uma simulação. O objetivo pode ser revisado depois de: aprender sobre sazonalidade; melhorar instrumentação; observar uso real; mudar a criticidade do serviço. Não altere a meta retroativamente para esconder uma violação. Quando o SLO diz para continuar entregando SRE não existe apenas para bloquear mudanças. Se o serviço: cumpre o objetivo; possui orçamento disponível; recupera rapidamente; apresenta poucos incidentes; a equipe pode ter evidência para publicar com maior frequência. O fluxo DevOps confiável e estratégias como canary e blue green reduzem o risco de cada alteração. O orçamento cria espaço explícito para experimentar sem fingir que falhas nunca ocorrerão. A pergunta que encerra o workshop Depois de escolher o indicador, pergunte: Quando este número piorar, qual decisão será diferente? Se a resposta for “nenhuma”, provavelmente a equipe criou apenas mais um gráfico. Um SLO útil ajuda a decidir: se uma release continua; se um projeto de confiabilidade deve ser priorizado; se um alerta merece interrupção; se o serviço suporta uma nova dependência; se a promessa comercial é viável. Para equipes pequenas, essa capacidade de priorização costuma ser mais valiosa do que a sofisticação matemática do modelo.