Production Readiness Review

Em 2007, o Google formalizou um processo que a equipe de SRE já praticava informalmente: antes de um novo serviço receber suporte de on-call da SRE, ele precisava passar por uma Production Readiness Review — uma avaliação estruturada de se o serviço estava preparado para operar em produção. A ideia era elegantemente simples: é mais barato verificar antes do lançamento que um serviço tem monitoramento adequado, runbooks, plano de capacidade e SLOs do que descobrir essas lacunas durante um incidente às 3h da manhã.

O PRR (Production Readiness Review) tornou-se um padrão amplamente adotado além do Google — com variações nos nomes (Launch Readiness Review, Service Readiness Checklist, Production Launch Criteria) mas com a mesma premissa: existem critérios objetivos que um serviço deve atender antes de ir para produção, e a equipe de operações tem autoridade para barrar o lançamento se os critérios não forem atendidos.

A tensão que o PRR resolve é entre velocidade de lançamento e estabilidade operacional. Sem PRR, cada serviço vai para produção quando o time de produto decide que está pronto — e os critérios de "pronto" tendem a ser funcionais (a feature faz o que foi especificada?) sem incluir critérios operacionais (o time de on-call sabe o que fazer quando ela falhar?). O PRR formaliza a voz da operação no processo de lançamento.

As categorias de critério do PRR

O SRE Book do Google (capítulo 32, "The Production Environment at Google, from the Viewpoint of an SRE") descreve as categorias de critérios que o PRR avalia. Traduzidas para o contexto de times modernos:

1. Monitoramento e observabilidade

O serviço tem os quatro sinais de ouro instrumentados? Rate (throughput), errors (taxa de erro), duration (latência), saturation (utilização de recursos) — as quatro métricas que o SRE Book identifica como as mais relevantes para qualquer serviço.

Os alertas estão configurados e testados? Um alerta configurado mas nunca verificado pode não funcionar quando necessário. O PRR exige que alertas sejam disparados intencionalmente em staging para confirmar que chegam no canal correto.

Existe dashboard de health do serviço que um engenheiro sem contexto profundo consegue interpretar em menos de 2 minutos? O dashboard não é para quem construiu o serviço — é para quem será acordado às 3h da manhã para resolver o problema.

2. SLOs definidos e medidos

O serviço tem SLOs formalmente definidos? Para um serviço novo, a ausência de histórico dificulta a calibração, mas o time deve propor SLOs com base na especificação técnica e nos SLOs dos serviços dependentes.

Os SLIs estão instrumentados e os dados estão sendo coletados? Não é possível verificar um SLO que não está sendo medido. O PRR verifica que os SLIs existem como métricas reais em produção antes do lançamento amplo.

3. Escalabilidade e capacidade

O time fez capacity planning? Para um serviço novo: qual é o volume esperado de tráfego no lançamento e 3 meses depois? A infraestrutura provisionada suporta esse volume com margem de segurança de pelo menos 50%?

O serviço tem auto-scaling configurado? Se o tráfego dobrar inesperadamente, o serviço escala automaticamente ou requer intervenção manual?

4. Dependências e falhas

As dependências do serviço foram mapeadas? Para cada dependência: qual é o comportamento quando ela falha? O serviço tem fallback? O fallback foi testado?

As dependências críticas têm SLOs adequados para suportar o SLO do serviço? Se o serviço tem SLO de 99.9% mas uma dependência tem SLO de 99%, o SLO do serviço é matematicamente inatingível.

5. Rollback e deploy

Existe um procedimento de rollback definido e testado? Rollback deve ser executável em menos de 5 minutos e não deve requerer intervenção de quem fez o deploy original.

O deploy é incremental (canary ou blue-green)? Um deploy que vai de 0% para 100% de uma vez não permite detectar problemas antes de afetar todos os usuários.

6. Documentação e runbooks

Existe documentação de operação? Runbooks para os cenários de falha mais prováveis, diagrama de arquitetura atualizado, lista de contatos de escalação.

Os runbooks foram testados? Idealmente em um game day ou tabletop exercise antes do lançamento.

O checklist como ferramenta, não como burocracia

O maior risco do PRR é se tornar uma burocracia que atrasa lançamentos sem adicionar valor real. Isso acontece quando o checklist é longo demais, subjetivo, ou quando aprovação é puramente formal (o aprovador assina sem verificar). O antídoto é calibrar o checklist para o risco real do serviço.

Um microserviço de baixo tráfego que processa dados não-críticos em background precisa de um PRR muito mais simples que um serviço de checkout de pagamentos. A proporcionalidade é uma propriedade essencial do processo.

O modelo do Google SRE diferencia entre serviços que receberão suporte de on-call da equipe de SRE (rigor máximo de PRR) e serviços que serão suportados pelo próprio time de desenvolvimento (PRR mais simples). A estrutura do rigor proporcional ao suporte é elegante: quanto maior a demanda operacional que um serviço criará, maior o rigor antes do lançamento.

O PRR como antecipação, não como barreira

Times que aplicam PRR bem relatam um efeito secundário valioso: o processo de preencher o PRR revela problemas antes que se tornem urgentes. Ao responder "qual é o comportamento quando o banco de dados primário cai?", o time frequentemente descobre que não tem uma resposta clara — e isso é muito melhor descobrir antes do lançamento do que durante um incidente.

O PRR funciona melhor quando é iniciado cedo no ciclo de desenvolvimento — não como checklist de última hora antes do lançamento, mas como ferramenta de planejamento que guia decisões arquiteturais. "O PRR vai exigir SLOs definidos — quais SLOs são realistas para esse serviço?" é uma pergunta que deve ser feita no início do projeto, não no dia antes do go-live.

PRR em times que não são Google

A maioria dos times não tem um time de SRE separado para conduzir PRRs. Mas o processo pode ser adaptado: um engenheiro sênior do time (rotacionado) pode conduzir o PRR de um novo serviço desenvolvido por colegas. Isso tem um benefício adicional: transferência de conhecimento — o revisor aprende sobre o serviço enquanto o revisa.

Uma versão minimalista de PRR para times pequenos pode se resumir a quatro perguntas:

1. Temos alertas configurados para os quatro sinais de ouro?
2. Sabemos como fazer rollback em menos de 5 minutos?
3. Temos runbook para as 3 falhas mais prováveis?
4. Definimos SLOs — mesmo que provisórios?

Se alguma das respostas é "não", o lançamento espera. Simples assim.

Como praticar

1. Criar um PRR template para o time. Baseado nas categorias acima, crie um template de PRR proporcional ao risco dos serviços do seu contexto. Deve ter: lista de critérios objetivos (não subjetivos), quem aprova cada categoria, o que constitui "aprovado" para cada critério. Revise com o time — o debate sobre o que deve estar no checklist é parte do valor do exercício.
2. Aplicar o PRR retroativamente em um serviço existente. Escolha um serviço em produção há mais de 6 meses. Aplique o PRR template nele. Identifique os critérios que não seriam aprovados hoje. Priorize as lacunas por risco. Isso frequentemente revela dívidas operacionais significativas em serviços aparentemente estáveis.
3. Cronometrar o stranger test. Peça a um engenheiro que não conhece um dos serviços do time que tente responder: "O serviço está com alta taxa de erro. O que você faria nos primeiros 10 minutos?" Forneça apenas a documentação disponível (runbook, dashboard, README). Cronometre. Se passar de 20 minutos para formular uma hipótese, a documentação operacional está incompleta.