O que é site reliability engineering? Guia para devs

Afinal, o que é site reliability engineering? É a prática de operar sistemas de produção usando engenharia de software, em vez de operação manual. Uma equipe de SRE define uma meta numérica de confiabilidade, mede o serviço contra ela e automatiza o trabalho repetitivo que mantém tudo no ar. Se o seu alerta toca às 3 da manhã por causa do mesmo problema de disco todo mês, é exatamente isso que o SRE existe para eliminar.

O termo surgiu no Google por volta de 2003. Hoje a ideia vai muito além da empresa, de startups com 20 pessoas a bancos. O que muda de um caso para outro é a escala, não a mecânica central.

O que um site reliability engineer realmente faz?

Ben Treynor Sloss, que criou a equipe de SRE do Google, resumiu bem no primeiro capítulo do livro sobre SRE do Google: SRE é o que acontece quando você pede a um engenheiro de software que desenhe uma equipe de operações. O trabalho é operação feita com código.

Em uma semana normal, isso significa quatro coisas. Você define o que significa "funcionando" para um serviço. Você monta o monitoramento que avisa quando ele não está. Você responde quando algo quebra. E você escreve a correção para que a próxima pessoa não seja acordada pelo mesmo motivo.

Dois exemplos deixam isso concreto. Uma equipe que faz deploy manual toda quinta-feira constrói um pipeline com rollback automático. Uma equipe que reinicia um serviço com vazamento de memória todas as noites encontra o vazamento e o corrige. As duas transformam uma tarefa recorrente em um projeto que se resolve uma vez só, e esse é o ponto.

A quarta parte é a que as equipes costumam pular. Um SRE que só responde a incidentes é um engenheiro de operações com um cargo novo. A parte de engenharia é o que torna o papel diferente.

Como SRE é diferente de DevOps?

DevOps é uma cultura: desenvolvedores e operadores compartilham a responsabilidade pelo que é lançado e por como roda em produção. Ele diz que o muro entre as equipes é um problema. Não diz quanto tempo fora do ar é aceitável nem quando parar de lançar novidades.

SRE fornece os números. Traz objetivos de nível de serviço (SLOs), orçamentos de erro e um limite para o trabalho manual. A visão do próprio Google é que SRE é uma forma concreta de colocar as ideias do DevOps em prática.

Deixe de lado a discussão sobre qual é "melhor". Se você lidera uma equipe de 8 pessoas, vai pegar emprestado de um e de outro. A pergunta útil é se a sua equipe consegue responder, em uma frase, quão confiável um determinado serviço precisa ser.

Quais são SLIs, SLOs e SLAs, e por que eles importam?

Três siglas carregam a maior parte do peso no SRE, e as pessoas as misturam o tempo todo.

• SLI (indicador de nível de serviço): uma medição. Por exemplo, a proporção de requisições HTTP que retornam uma resposta diferente de 5xx em menos de 300 ms.

• SLO (objetivo de nível de serviço): a meta para essa medição. Por exemplo, 99,9% das requisições em uma janela móvel de 28 dias.

• SLA (acordo de nível de serviço): o contrato com consequências, normalmente reembolsos, se a meta não for cumprida. O seu SLA deve ser menos exigente que o seu SLO.

A razão para se dar ao trabalho disso é que "o site precisa ser rápido e confiável" não pode ser testado. Uma meta como "99,9% dos pedidos de checkout são concluídos em menos de 500 ms" pode ser testada, e ainda encerra discussões.

Pense em uma loja online. Se 99,9% das compras terminam sem erro, a equipe sabe exatamente quantas falhas pode absorver no mês antes de congelar os lançamentos. Sem esse número, cada falha vira uma discussão nova, e ninguém sabe quem tem razão.

Comece com dois ou três SLIs por serviço. Mais do que isso e ninguém se lembra deles.

Escolha SLIs que o usuário sente. Uso de CPU é uma causa, não um sintoma. Compras que falham, páginas lentas e dados desatualizados são o que o cliente percebe.

Como funcionam os orçamentos de erro?

Um orçamento de erro é a falha que o seu SLO permite. É simplesmente 1 menos o SLO. Uma disponibilidade de 99,9% deixa 0,1%, o que equivale a cerca de 43 minutos de indisponibilidade em um mês de 30 dias.

Veja uma versão pequena em código, porque a aritmética é a ideia inteira:

slo = 0.999
janela_minutos = 30 * 24 * 60           # 43.200
orcamento = (1 - slo) * janela_minutos  # 43,2 minutos
gasto = 31                              # minutos de serviço ruim até agora
print(f"{orcamento - gasto:.1f} minutos restantes")  # 12.2 minutos restantes

Enquanto houver orçamento, a equipe lança rápido. Quando ele acaba, os lançamentos de funcionalidades são pausados e o trabalho passa para confiabilidade. O exemplo de política de orçamento de erro no SRE Workbook mostra como uma equipe escreve essa regra no papel.

A ideia não é punir. Ela substitui a velha briga, em que desenvolvedores querem lançar e operadores querem estabilidade, por um número compartilhado que os dois lados conseguem ler. Só funciona se a liderança concordar antecipadamente em respeitar a pausa. Uma política que é anulada a cada trimestre é só decoração.

Por que existe a regra de 50% de toil?

Toil é trabalho manual e repetitivo que cresce junto com o serviço e não deixa nada para trás. Reiniciar um worker travado à mão é toil. Escrever o health check que o reinicia automaticamente é engenharia.

A organização de SRE do Google busca manter o toil abaixo de 50% do tempo de cada engenheiro, como descrito no capítulo sobre eliminação de toil. O restante vai para projetos que reduzem o toil futuro ou adicionam funcionalidades. O raciocínio é direto: o toil se expande até ocupar 100% do tempo de todo mundo se ninguém o interromper.

Trate os 50% como teto, não como meta. Uma equipe saudável, com um serviço maduro, fica bem abaixo disso. Se você passa do limite por um trimestre inteiro, não está fazendo SRE: está tocando uma fila de operações.

Uma forma simples de começar: por duas semanas, marque cada chamado e cada alerta como toil ou projeto. Depois, ordene o toil por horas gastas. Os três primeiros itens são o seu backlog de automação.

O que as revisões pós-incidente sem culpa mudam?

Quando algo quebra, o post-mortem pergunta como o sistema permitiu que uma pessoa cometesse aquele erro, não quem o cometeu. A culpa ensina as pessoas a esconder informação. Uma revisão sem culpa ensina a registrá-la.

Um post-mortem útil é curto e tem quatro partes: uma linha do tempo, as causas contribuintes, o que funcionou e itens de ação com responsáveis e datas. Item de ação sem responsável é só um desejo.

A maior parte do valor vem do acompanhamento. Revise os itens abertos todo mês. Se a mesma causa aparecer duas vezes em seis meses, o primeiro post-mortem falhou, independentemente do que o documento dizia.

Quais ferramentas uma equipe de SRE precisa primeiro?

Não são muitas. Comece pelos sinais e depois adicione plantão e automação.

1. Métricas e dashboards. O suficiente para calcular seus SLIs. Grafana e Prometheus são uma combinação open source comum; Datadog e New Relic são o caminho hospedado.

2. Alertas ligados aos SLOs. Alerte quando o orçamento estiver queimando rápido, não quando um único host tiver um pico. Menos alertas, e melhores.

3. Feature flags e rollout gradual. Grosso modo, a maioria das falhas segue uma mudança, então a vitória mais barata em confiabilidade é tornar as mudanças reversíveis. LaunchDarkly e Statsig cobrem esse ponto.

4. Um runbook escrito para cada alerta. Se um alerta não tem runbook, escreva um ou apague o alerta.

Se o time é pequeno, comece com o que já existe: os logs da aplicação e uma planilha com o SLI calculado toda semana bastam para começar. Ferramenta cara não substitui a decisão sobre quais números importam.

Compre ou construa nessa ordem. Equipes que começam comprando uma ferramenta sem ter um SLO acabam com dashboards bonitos e sem propósito algum.

Onde entra a leitura de código desconhecido no SRE?

Esta é a parte que ninguém coloca na descrição da vaga. Durante um incidente, um SRE muitas vezes precisa entender um serviço que não escreveu, em um repositório que não abre há meses. A pergunta raramente é abstrata. É algo como "onde fica este loop de retry e o que ele faz em caso de timeout?"

Você já fez isso: grep, blame e depois mandar mensagem para quem mexeu por último no arquivo. Em um repositório de 80 mil linhas, funciona. Em doze serviços de seis equipes, isso consome os primeiros 20 minutos de um incidente, e esses minutos contam contra o orçamento.

É aí que uma ferramenta de busca de código que responde perguntas sobre o seu próprio repositório se justifica. Por exemplo, perguntar onde um serviço define seus timeouts e quais chamadores dependem deles. Ela não vai consertar a indisponibilidade. Ela reduz o tempo gasto lendo antes de você poder agir, e esse tempo é mensurável.

O SRE é exagero para a sua equipe, e como começar?

Você não precisa de uma equipe dedicada de SRE se tem um serviço, um punhado de engenheiros e usuários que toleram uma hora ruim de vez em quando. Você não precisa de uma equipe. Precisa de um SLO, de um alerta decente e de alguém que seja dono do plantão.

Considere estruturar a função quando uma destas condições for verdadeira: indisponibilidades custam receita real, o plantão está esgotando as pessoas ou os desenvolvedores estão sendo atrasados por pedidos de operação improvisados. Muitas empresas começam transformando um ou dois engenheiros em SREs de meio período e observam como funciona.

Um erro comum é renomear a equipe de operações para "SRE" sem mudar a forma de trabalho. Se a equipe ainda cuida de chamados, de deploys manuais e não tem orçamento de erro, o título mudou e nada mais mudou.

Como começar na próxima semana

Você não precisa de uma reorganização. Escolha o serviço voltado ao usuário que mais dói e faça cinco coisas.

1. Escreva um SLI e um SLO para ele. Mantenha ambos simples.

2. Calcule o orçamento de erro e coloque-o em um dashboard que a equipe inteira vê.

3. Registre o toil por duas semanas e escolha o item principal para automatizar.

4. Faça um post-mortem sem culpa do seu próximo incidente, com itens de ação que tenham dono.

5. Combine por escrito o que acontece quando o orçamento chegar a zero.

Se, daqui a um mês, a equipe discutir menos se deve lançar e mais o que os números dizem, o processo está funcionando. Se o orçamento nunca se mexe porque o SLO está frouxo demais, aperte o SLO.