O que é site reliability engineering SRE? Guia para dev solo

O que é site reliability engineering SRE? É tratar operação como problema de software: você define uma meta de confiabilidade mensurável, acompanha quantas vezes erra essa meta e deixa esse número decidir se a prioridade é lançar funcionalidades ou consertar o que quebra. O Google criou o termo, mas a ideia funciona em qualquer escala. Para um dev solo com um app e alguns usuários, significa decidir antes quanto tempo fora do ar você aceita.

Na prática, o problema é que a maioria dos projetos paralelos não tem esse número. O site está "no ar" até alguém mandar um e-mail reclamando. Este guia explica SRE em termos simples e depois reduz a ideia a algo que uma pessoa consegue manter num fim de semana.

O que é SRE, de verdade?

A versão curta vem do livro de SRE do Google: SRE é o que você obtém quando pede a um engenheiro de software para desenhar uma equipe de operações. Em vez de alguém reiniciar servidores à mão, você escreve código que faz isso e mede o resultado.

Três ideias sustentam quase tudo. Confiabilidade é uma funcionalidade com meta, não uma sensação. Trabalho manual repetitivo (o livro chama de toil) é um bug a ser automatizado. E falha é esperada, então você planeja como aprender com ela em vez de como evitar culpados.

DevOps e SRE se sobrepõem bastante. A diferença prática: DevOps é uma cultura de entregar e rodar código juntos, enquanto SRE oferece ferramentas concretas para discutir isso com números. Ninguém precisa escolher um lado para usar os números.

Em uma empresa grande, um SRE divide o tempo entre plantão, resposta a incidentes, planejamento de capacidade e automação. O livro do Google recomenda limitar a carga operacional a cerca de metade do tempo do engenheiro, para que o resto vá para engenharia. Esse teto é uma restrição de design, não um detalhe.

O trabalho recorrente se parece com isto:

• Definir SLOs junto com os times de produto e alertar sobre queima do orçamento, não sobre cada falha isolada

• Manter escalas de plantão e escrever runbooks para que o alerta das 3 da manhã tenha um checklist

• Liderar a resposta a incidentes e escrever um postmortem sem culpados

• Automatizar tudo que foi feito à mão mais de algumas vezes

• Revisar lançamentos quanto a riscos de confiabilidade antes de chegarem à produção

Feature flags são um bom exemplo dessa mentalidade. Uma flag permite desligar uma versão ruim em segundos, sem novo deploy, e isso protege o orçamento. Se você precisa de uma ferramenta hospedada para isso depende de quantas flags tem: uma variável de ambiente resolve as primeiras três.

SLI, SLO e SLA: três siglas, uma ideia cada

Um SLI (service level indicator) é algo que você mede. Para um app web, geralmente é a proporção de requisições que dão certo, ou a proporção que responde em menos de 300 ms. Escolha um ou dois. Não doze.

Um SLO (service level objective) é a meta que você define sobre essa medida, por exemplo "99.9% das requisições dão certo em 30 dias". É interno. É uma promessa para você mesmo.

Um SLA (service level agreement) é um contrato com o cliente, geralmente com reembolso se a meta não for cumprida. Se ninguém paga por uptime, você ainda não tem um SLA, e não deveria escrever um sem querer no texto da sua página de preços.

Orçamento de erros: a parte que muda o jeito de trabalhar

O orçamento de erros é simplesmente 100% menos o seu SLO. Uma meta de 99.9% em 30 dias deixa cerca de 43 minutos de falha permitida. É o orçamento que você pode gastar com deploys arriscados, migrações e experimentos.

O útil é a regra ligada a ele. Enquanto sobrar orçamento, você lança. Quando acabar, para de lançar funcionalidades e corrige confiabilidade até o número se recuperar. O capítulo do livro sobre risco apresenta isso como forma de resolver a discussão entre "ir mais rápido" e "não quebrar nada" com um número compartilhado, em vez de uma negociação sem fim.

Ele também deixa um ponto direto que vale repetir: 100% quase nunca é a meta certa. Usuários em rede móvel instável não percebem a diferença entre 99.99% e 99.9%, e cada nove a mais custa muito mais que o anterior. Não é uma meta perfeita. É uma meta que funciona.

Se você quer o fluxo concreto para escolher indicadores e escrever o primeiro objetivo, o workbook de SRE sobre implementação de SLOs é o capítulo mais prático, e é curto.

Você precisa de SRE se está construindo sozinho?

Três razões para fazer, uma para não fazer.

As razões para fazer: seu próprio projeto vai acabar te acordando de madrugada; uma meta escrita impede você de superengenheirar; e "eu opero produção com SLO" soa bem quando alguém decide se vai te contratar ou confiar em você. A razão para não fazer: se o projeto ainda não tem usuários, você está treinando para um problema que não tem. Construa primeiro, meça quando alguém depender dele.

Então pule o aparato completo. Não contrate serviço de pager para um app hobby, não suba Kubernetes para parecer sério e não escreva um template de incidente de dez páginas. Vale a pena fazer se você tem pelo menos dez usuários reais: um health check, um SLO e um lugar para olhar quando quebrar.

Uma configuração de SRE em uma noite para projeto paralelo

Este é o mínimo que costuma se sustentar mesmo com 10 000 usuários. Leva uma noite. Testado. Não é ótimo. Fazemos mesmo assim porque é simples, e o simples aguenta.

Primeiro, escolha um SLI: a proporção de requisições HTTP que retornam algo diferente de 5xx. Segundo, defina o SLO em 99.5% em 30 dias, o que dá cerca de 3.6 horas de orçamento. Comece frouxo e aperte depois. Terceiro, adicione um monitor externo de uptime batendo num endpoint de saúde de verdade.

Um endpoint de saúde útil verifica o que de fato quebra, não só se o processo está vivo:

// GET /healthz
app.get("/healthz", async (req, res) => {
  try {
    await db.query("select 1");          // banco acessível
    await cache.ping();                  // cache acessível
    res.status(200).json({ ok: true });
  } catch (err) {
    res.status(503).json({ ok: false });
  }
});

Quarto, mande alertas para um lugar onde você vá ver: notificação push no celular, não uma caixa de e-mail. Quinto, mantenha um arquivo de texto chamado postmortems.md e adicione quatro linhas depois de cada queda: o que aconteceu, por quê, quanto tempo durou, o que muda. Esse arquivo é a ferramenta de confiabilidade mais subestimada que você vai ter.

Sobre alertas: um erro comum de quem começa é receber aviso toda vez que uma única requisição falha. Em uma semana você silencia o canal. Um sinal melhor é a taxa de queima: a velocidade com que você gasta o orçamento de erros, comparada com o ritmo que o esgotaria exatamente no fim da janela. Para um projeto paralelo, mantenha simples. Envie push se a taxa de erro dos últimos 10 minutos passar de 5%, e um resumo por e-mail se a taxa semanal caminhar para não cumprir o SLO. Isso dá dois níveis: acordar agora, ou olhar na segunda. Qualquer coisa mais sofisticada pode esperar até os usuários reclamarem do primeiro nível.

Onde a IA ajuda e onde não ajuda

Assistentes são razoáveis na parte braçal: escrever o health check, o Terraform de um monitor de uptime, um primeiro rascunho de runbook, ou um script que lê logs e calcula a taxa de 5xx. São ruins para decidir o seu SLO, porque isso é uma decisão de produto sobre o que os seus usuários toleram.

Durante um incidente, cuidado. Um assistente pode sugerir uma correção plausível que você aplica em produção às 2 da manhã sem ler direito. Use para explicar um stack trace ou rascunhar o postmortem depois, e deixe a decisão de rollback com um humano acordado.

Os portões de qualidade de código também entram nesse quadro. Muitas quedas vêm de uma mudança que parecia inofensiva na revisão. Análise estática no CI não te dá confiabilidade, mas elimina uma classe de erros bobos antes que eles consumam o orçamento.

Como escrever um postmortem que alguém vai ler

Seja curto e sem culpados. Sem culpados não quer dizer que ninguém é responsável. Quer dizer que você pergunta o que no sistema permitiu o erro, e não quem errou. Quando você é a única pessoa do time, isso pesa mais do que parece, porque a tentação é se sentir mal e pular a escrita.

Quatro títulos bastam: o que aconteceu, por que aconteceu, quanto tempo os usuários foram afetados e o que muda. O último deve citar uma ação que você de fato vai fazer, com data. "Ter mais cuidado" não é ação. "Adicionar uma checagem em staging para migrações antes do próximo release" é.

Ao longo de um ano, esse arquivo vira um mapa dos seus pontos fracos. A regra depois de três quedas causadas pelo mesmo certificado vencido: se a mesma causa aparece duas vezes, automatize. Levou uma noite para adicionar monitoramento de renovação, e não voltou a acontecer.

Carreira em SRE e o que construir em seguida

Depende do que você gosta. Funções de SRE combinam com quem gosta mais de sistemas, modos de falha e automação do que de construir interfaces. Se você sente satisfação em deixar o plantão mais silencioso, vai gostar. Se quer ver usuários clicando na sua funcionalidade nova, provavelmente não.

O caminho de entrada costuma ser backend ou infraestrutura: você começa cuidando dos deploys e alertas de um serviço e depois assume mais da confiabilidade dele. Habilidades que se transferem: noções de Linux, redes, um provedor de nuvem, uma stack de monitoramento e o hábito de escrever as coisas. Projetos paralelos são um bom lugar para construir tudo isso, porque você é o time inteiro.

Escolha uma coisa que você já roda, mesmo um app no plano gratuito, e anote o SLI, o SLO e a ação exata que vai tomar quando o orçamento acabar. Se você não consegue dizer o que deixaria de fazer, o número é só decoração. Qual dos seus projetos você perceberia fora do ar antes de um usuário avisar?