Site reliability engineering é o que você obtém quando trata operações como um problema de software: um time de engenheiros que é dono da confiabilidade de um serviço em produção, mede essa confiabilidade do lado do usuário e gasta pelo menos metade do tempo escrevendo código que elimina trabalho operacional em vez de fazer esse trabalho à mão. Um SRE não é um sysadmin com nome novo nem um engenheiro DevOps com um pager. O papel tem um escopo definido, um conjunto definido de coisas que observa e uma relação definida com os desenvolvedores. Este post cobre os três.

Esta é a Parte 1 de Budget for Failure, uma série em quatro partes sobre o que é site reliability engineering e como praticar. As Partes 1 e 2 são nível 101: o papel, depois os números com que ele opera (SLI, SLO, SLA, error budgets). As Partes 3 e 4 são nível 201: o que um SRE precisa dominar na base de código e o que verificar do lado do provedor, seja ele uma nuvem ou o seu próprio data center. Os exemplos são em AWS; a prática não é específica de AWS.

De onde vem o papel

O termo vem do Google, onde Ben Treynor Sloss montou o primeiro time em 2003 e mais tarde o descreveu em uma linha no livro de SRE: SRE é o que acontece quando você pede a um engenheiro de software que projete um time de operações. A resposta do engenheiro a um serviço em crescimento não foi contratar operadores na proporção do tráfego. Foi automatizar o trabalho do operador e impor um teto rígido a quanto trabalho manual o time podia aceitar.

A relação com DevOps costuma ser resumida, de novo pelo Google, como "class SRE implements interface DevOps". DevOps é um conjunto de princípios: propriedade compartilhada, mudanças pequenas, automação, medição. SRE é uma implementação concreta desses princípios, com opiniões anexadas, como exatamente de que forma a confiabilidade é medida e exatamente o que acontece quando a medição diz que um serviço não está confiável o suficiente.

Pelo que um SRE é responsável

O livro de SRE lista o escopo em uma frase: um time de SRE é responsável pela disponibilidade, latência, desempenho, eficiência, gestão de mudanças, monitoramento, resposta a emergências e planejamento de capacidade dos seus serviços. Desdobrado no que isso significa em uma semana de trabalho:

  • Disponibilidade e latência. Definir como número o que "funcionando" significa para os usuários, medir isso e defender isso. A Parte 2 é inteiramente sobre esse ponto.
  • Gestão de mudanças. A maioria das quedas é causada por uma mudança. O SRE é dono da maquinaria que torna a mudança segura: rollouts progressivos, rollback automático e a evidência de que um release está saudável.
  • Monitoramento e alertas. Decidir quais sinais merecem um humano às 03:00 e quais pertencem a um dashboard. Um acionamento que não exige nenhuma ação é um defeito no alerta, e o SRE o corrige como qualquer outro defeito.
  • Resposta a emergências. Estar de plantão (on-call), conduzir incidentes com uma estrutura de comando clara e restaurar o serviço primeiro, diagnosticar depois.
  • Postmortems. Depois de um incidente, uma análise escrita e sem culpa (blameless) do que aconteceu e de qual correção sistêmica evita aquela classe de falha. Sem culpa é um requisito técnico: pessoas que esperam punição param de relatar o que viram.
  • Planejamento de capacidade. Saber quanta folga existe, como a demanda está crescendo e quanto tempo nova capacidade leva para chegar, em minutos numa nuvem, em meses on-prem.
  • Eficiência e desempenho. Confiabilidade comprada com capacidade sobressalente ilimitada não é engenharia. Custo por requisição também é um número do SRE.
  • Eliminar toil. Tratado abaixo, porque é a parte que torna o resto possível.

Para onde um SRE olha

Um engenheiro DevOps vindo de infraestrutura tende a observar recursos: CPU, memória, disco, contagem de nós. Um SRE começa uma camada acima, no que o usuário experimentou, e usa métricas de recurso apenas para explicar isso. O conjunto inicial padrão são os quatro sinais de ouro do capítulo de monitoramento do livro de SRE:

SinalPergunta que respondeOnde vive na AWS
LatênciaQuanto tempo as requisições levam, separando sucesso e falha?Percentis de TargetResponseTime do ALB, Latency do API Gateway, traces da aplicação
TráfegoQuanta demanda há sobre o sistema?RequestCount do ALB, mensagens enviadas ao SQS, Invocations do Lambda
ErrosQue fração das requisições falha?HTTPCode_Target_5XX_Count e HTTPCode_ELB_5XX_Count do ALB, Errors do Lambda
SaturaçãoQuão cheio está o recurso mais restrito?Conexões do RDS contra max_connections, idade da fila, reserva de CPU no ECS, uso de service quotas

Dois detalhes separam uma leitura de SRE desses sinais de uma leitura casual. Latência é lida como distribuição, nunca como média: o percentil 99 é onde estão os usuários insatisfeitos. E saturação é lida contra o limite que de fato será atingido primeiro, que raramente é CPU. É o pool de conexões do banco, a alocação de portas do NAT gateway, a concorrência de Lambda no nível da conta ou o orçamento de IOPS do volume EBS.

Além dos quatro sinais, um SRE observa as coisas que preveem o incidente do mês que vem: a taxa e a taxa de falha das mudanças, a idade da dependência mais antiga sem patch, quanto da semana passada foi gasto em trabalho manual e quantos acionamentos o engenheiro de plantão recebeu.

A regra dos 50 por cento e o toil

O que torna SRE diferente de um time de operações com um título melhor é um teto. No modelo do Google, um SRE gasta pelo menos 50 por cento do tempo em trabalho de engenharia, na média de alguns trimestres. O restante pode ir para trabalho operacional: tickets, plantão, tarefas manuais.

A parte manual tem um nome, toil, e uma definição precisa: trabalho ligado à operação de um serviço em produção que tende a ser manual, repetitivo, automatizável, tático, sem valor duradouro e que escala linearmente com o crescimento do serviço. Reiniciar um worker travado, rotacionar um certificado à mão, aprovar um pedido de quota, copiar um banco de dados para um desenvolvedor. Cada item é pequeno. Juntos, são o motivo pelo qual um time de cinco não consegue fazer nenhuma engenharia.

O teto é o que dá ao SRE autoridade para dizer não. Quando o toil passa da metade do tempo do time, a resposta não é heroísmo. É automatizar a maior fonte, ou devolver a carga operacional ao time que a gera até que ela encolha. O plantão segue a mesma lógica: o livro de SRE coloca a carga sustentável em cerca de dois incidentes por turno de plantão, porque cada incidente precisa de acompanhamento e de um postmortem, e uma pessoa que recebe cinco acionamentos por noite não faz nenhum dos dois.

Como um SRE ajuda os desenvolvedores

A pior versão deste papel é um portão: os desenvolvedores jogam um release por cima do muro e um time de confiabilidade decide se ele pode passar. A versão útil trata os desenvolvedores como o cliente e a confiabilidade como um produto que o SRE constrói para eles. Quatro formas concretas:

A estrada pavimentada (paved road). Um template de serviço que já chega com logging estruturado, métricas, tracing, health checks, um pipeline de deploy com canary e rollback e alarmes sensatos já conectados. Um desenvolvedor que aceita o padrão ganha um serviço confiável sem ler um runbook. É a coisa de maior valor que um time de SRE entrega.

A production readiness review. Antes de um novo serviço receber tráfego real, o SRE o percorre junto com os desenvolvedores: do que ele depende, o que acontece quando cada dependência fica lenta, quais são os timeouts, como é feito o rollback, quem é acionado. É uma revisão de design, feita cedo o bastante para mudar o design. A Parte 3 percorre o que procurar.

O orçamento de erros (error budget). Um número compartilhado e previamente acordado que diz aos dois lados quando é seguro entregar rápido e quando desacelerar. Ele substitui a discussão sobre se um release é "arriscado demais" por uma leitura. A Parte 2 o constrói.

Plantão compartilhado. Desenvolvedores que carregam o pager do próprio serviço escrevem código diferente. Muitas organizações começam um serviço na escala dos desenvolvedores e o movem para o SRE apenas quando ele atinge um patamar de confiabilidade, devolvendo-o se cair abaixo. O trabalho do SRE é tornar essa escala humana, com bons alertas e bons runbooks, não absorver a dor para que ninguém a montante a sinta.

SRE e DevOps: onde o trabalho difere

Se você vive de rodar pipelines, Terraform e Kubernetes, a maior parte das ferramentas se aproveita. O que muda é a pergunta que cada ferramenta responde.

Como engenheiro DevOps vocêComo SRE você também
Constrói o pipeline de CI/CDDecide que evidência interrompe um rollout automaticamente e mede quanta confiabilidade cada release custa
Configura alarmes de CPU, memória e discoAciona alguém só por sintomas visíveis ao usuário e mantém as métricas de recurso para diagnóstico
Provisiona infraestrutura como códigoConhece seus domínios de falha, suas quotas e o que acontece quando o control plane do provedor está fora
Corrige o incidenteConduz o incidente, escreve o postmortem e entrega a correção que elimina a classe de falha
Automatiza uma tarefa quando pedemAcompanha o toil como número e se recusa a deixá-lo passar da metade do tempo do time
Trata o código da aplicação como área dos desenvolvedoresLê esse código, revisa seus timeouts e retries e envia pull requests para ele

A última linha é a que a maioria dos engenheiros de infraestrutura subestima. Um SRE que não consegue ler o código do serviço só consegue observar falhas de fora. Confiabilidade se decide em como uma função lida com uma dependência lenta, e isso está no repositório, não no cluster.

Modos de falha e o que observar

A troca de nome. Um time de operações que recebe o título de SRE e a mesma fila de tickets não mudou nada. Sem o teto de toil e a autoridade que vem com ele, não há tempo para engenharia, e o título descreve uma aspiração.

O porteiro. Um time de confiabilidade que aprova releases vira o gargalo que a organização contorna. Influência vem da estrada pavimentada e de dados, não de um veto.

O herói. Um engenheiro que conhece todos os sistemas e resolve todas as quedas é um ponto único de falha com salário. Incidentes que terminam com "o Sam levou vinte minutos" precisam de um runbook, não de aplausos.

Confiabilidade sem número. "O mais confiável possível" não pode ser planejado, dimensionado em pessoas nem negociado contra features. Tudo neste post depende de conseguir dizer quão confiável um serviço deveria ser e se ele está sendo agora. Esse é o vocabulário de SLIs, SLOs e error budgets, e é a Parte 2.

Leia isto a seguir

Para consultoria em AWS, arquitetura de nuvem, prática de SRE, pipelines de CI/CD, Linux e mais, comece em ercanermis.com.

Referências