Checklist de incidentes de produção para equipes pequenas que precisam de clareza

O que um runbook de produção resolve para uma equipe pequena

Um runbook de produção é um pequeno manual escrito para quando algo quebra em produção. Ele diz onde olhar primeiro, quais ações são seguras e quem comunica o quê. Equipes pequenas não têm o luxo de “alguém vai saber”. A pessoa certa pode estar dormindo, ocupada ou recém-chegada.

Durante um incidente, o objetivo é simples: reduzir o dano, restaurar o serviço e manter a equipe coordenada. A análise da causa raiz pode esperar até que os clientes possam fazer login, pagar ou usar o produto novamente. Um checklist previne pânico e cliques aleatórios ao transformar o estresse em alguns passos claros.

Este checklist foca na primeira hora: triagem rápida, decisões de rollback, comunicação com clientes e um loop básico pós-incidente para evitar repetições. Não substitui depuração aprofundada, trabalho de arquitetura de longo prazo ou um programa completo de segurança. Foi pensado para duas a cinco pessoas, incluindo não-especialistas.

Uma regra simples ajuda equipes a tomar melhores decisões sob pressão:

• Conserte primeiro o impacto no cliente, mesmo que a correção seja temporária.
• Escolha a mudança de menor risco (frequentemente um rollback) antes de um patch complexo.
• Comunique cedo e de forma breve, depois atualize em uma cadência previsível.
• Guarde o aprendizado para depois que o serviço estiver estável.

Exemplo: se um deploy causa erros no checkout, faça rollback primeiro para parar pagamentos falhos. Investigue a mudança no código quando a receita e a confiança não estiverem sangrando.

Defina severidade e papéis antes de precisar deles

Quando algo quebra, equipes perdem tempo debatendo quão sério é e quem decide. Uma escala simples de severidade e papéis claros transformam um runbook em ação, não discussão.

Severidade em linguagem simples

Mantenha curto e ligado ao impacto do usuário. Para muitas equipes pequenas, três níveis são suficientes:

• Minor: Alguns usuários afetados, existe workaround, sem risco de perda de dados.
• Major: Muitos usuários afetados, recurso core degradado, receita ou prazos em risco.
• Critical: Serviço majoritariamente fora do ar, risco de segurança ou perda de dados provável.

Uma regra extra ajuda: a severidade só pode ser aumentada durante um incidente, não reduzida. Isso evita discussões sobre aparência enquanto você deveria estar consertando.

Papéis que removem gargalos

Atribua papéis imediatamente, mesmo que sejam duas pessoas. Uma pessoa conduz decisões. Outra cuida das atualizações.

• Incident lead: responsável pela linha do tempo, escolhe próximos passos e previne troca de tarefas sem foco.
• Comunicador: posta atualizações, responde stakeholders e mantém os engenheiros focados.
• Rollback approver: a pessoa que pode dizer “sim, faça rollback agora” (frequentemente o incident lead, mais um backup).
• Scribe (opcional): anota horários e ações importantes para a revisão.

Decida como alcançar o rollback approver rapidamente (ligação, mensagem, o que vocês realmente respondem). Anote também o backup, porque incidentes adoram férias.

Por fim, defina “serviço restaurado” em uma frase. Exemplo: “Usuários conseguem fazer login e carregar o dashboard em até 3 segundos, e a taxa de erros fica abaixo de 1% por 15 minutos.” Essa frase evita vitórias prematuras.

Trabalho de preparação que torna o checklist realmente utilizável

Um checklist só funciona se aponta para lugares reais aos quais sua equipe tem acesso em minutos, não “devemos checar logs”. O objetivo é remover achismos quando o estresse é alto.

Comece com um mapa do sistema em uma página. Mantenha simples: o que roda onde e do que depende o quê (web app, API, banco de dados, cache, provedor de autenticação, jobs em background, serviços de terceiros). Adicione os pontos únicos de falha que você já conhece.

Escreva seus principais caminhos do cliente, não cada endpoint. A maioria das equipes pequenas vive e morre por alguns fluxos como login, inscrição, checkout e uma ou duas ações centrais. Se você consegue testar esses fluxos rapidamente, confirma impacto e sabe quando voltou ao normal.

Mantenha uma seção curta “onde olhar” que permaneça atualizada. Liste as poucas métricas em que você confia (taxa de erro, latência, sucesso no login, profundidade das filas, conexões DB), onde estão os dashboards, onde ficam os logs (app e edge/CDN) e como ver a versão e hora do último deploy. Adicione uma linha de base conhecida boa, como os números de ontem, para identificar o que é “normal”.

Armazene passos de acesso de emergência e contatos em um só lugar: quem pode aprovar mudanças, quem tem acesso à nuvem, quem pode reverter e como alcançá-los.

Documente onde ficam configs e segredos sem expô-los. Escreva “onde e como rotacionar”, não os valores reais.

Se você herdou uma base de código frágil, essa preparação muitas vezes revela variáveis de ambiente faltando, segredos hard-coded ou passos de deploy que existem só na cabeça de alguém.

Checklist de incidente dos 10 minutos (passo a passo)

Quando algo quebra, você precisa de um roteiro curto para seguir sob estresse. Este checklist é pensado para os primeiros 10 minutos, quando velocidade e segurança importam mais que diagnóstico perfeito.

Comece confirmando o impacto em termos claros. O que os usuários estão tentando fazer e o que falha? É todo mundo ou um subconjunto (região, plano, navegador, apenas contas novas)? Se você consegue reproduzir uma vez, anote os passos exatos e a mensagem de erro.

Então, estabilize o sistema antes de correr atrás da causa raiz. Pause deploys e evite ajustes rápidos que adicionem ruído. Se o problema pode se espalhar, limite o raio de ação (desligue um job arriscado, reduza tráfego ou desative temporariamente a funcionalidade afetada).

Trabalhe em uma hipótese pequena por vez. Escolha o gatilho mais provável (último deploy, mudança de config, outage de terceiro) e faça uma ou duas checagens rápidas para confirmar ou descartar.

• Minuto 0–2: Confirme impacto (o que está quebrado, quem é afetado, quando começou)
• Minuto 2–4: Congele mudanças arriscadas (pare deploys, evite novas migrations, mantenha a superfície pequena)
• Minuto 4–6: Checagens rápidas (status do último deploy, taxas de erro, conectividade auth/DB, status de terceiros se relevante)
• Minuto 6–8: Escolha um caminho (mitigue agora via rollback/flag-off, ou continue investigando se mitigação é arriscada)
• Minuto 8–10: Registre ações (horários, o que você mudou, o que observou e a próxima decisão)

Mantenha uma linha do tempo em um só lugar. Mesmo uma nota simples como “10:07 revertido build 214, erros caíram” poupa horas na revisão.

Onde olhar primeiro quando algo quebra

Comece pelos sintomas, não por suposições. Confirme o que os usuários estão vendo e quão difundido é: picos de erros, requisições lentas, timeouts ou uma enxurrada de mensagens ao suporte. Se puder, anote a hora exata em que o problema começou. Esse timestamp guia todo o resto.

Em seguida, ancore sua busca no que mudou. A maioria dos incidentes tem um gatilho: um deploy, uma alteração de config, uma migration de banco, a rotação de um segredo ou um flip de feature flag. Mesmo que a mudança pareça pequena, trate-a como suspeita até descartar.

Uma ordem simples de triagem de primeira passagem que funciona para equipes pequenas:

• Confirme impacto: taxa de erro, latência e quais endpoints ou telas estão falhando.
• Verifique as mudanças dos últimos 30–60 minutos: deploys, edições de config, migrations, jobs em background.
• Procure por capacidade e saturação: CPU, memória, disco, queries lentas, conexões no limite.
• Escaneie logs buscando um erro repetido (mesma mensagem, mesma stack trace, mesmo caminho).
• Verifique dependências: autenticação, email/SMS, pagamentos, CDN e APIs de terceiros.

Ao vasculhar logs, não leia tudo. Busque o padrão de erro mais comum e siga por ele. Se você ver repetidos “token signature invalid” ou “database connection refused”, já tem uma pista forte.

Cheque também fundamentos que falham silenciosamente: certificados expirados, variáveis de ambiente faltando e limites de taxa. Isso aparece muito em protótipos que não foram endurecidos para produção.

Quando encontrar uma causa provável, escreva-a imediatamente (hora, sintoma, evidência). Essa nota vira sua linha do tempo e mantém a equipe alinhada.

Opções rápidas de mitigação antes de uma correção completa

Quando a produção está pegando fogo, o objetivo não é uma correção perfeita. É reduzir o impacto com a menor mudança segura, então ganhar tempo para diagnosticar.

Comece escolhendo a ação de menor risco que altera menos coisas. Evite grandes refactors, upgrades de dependência ou “já que estamos aqui” melhorias. Cada mudança extra adiciona incerteza.

Movimentos de mitigação comuns que funcionam bem para equipes pequenas:

• Desabilitar o comportamento novo (feature flag, toggle de config ou variável de ambiente) para que os usuários voltem para um caminho conhecido.
• Mudar para um modo fallback, como somente leitura ou conjunto de recursos limitado, para manter o core disponível.
• Reduzir pressão: aplicar rate limits, bloquear temporariamente fontes abusivas ou aumentar cache para endpoints quentes.
• Pausar operações arriscadas se dados estiverem em risco (parar writes, jobs em background ou imports) até entender o que acontece.
• Adicionar uma proteção rápida: rejeitar inputs obviamente ruins, reduzir concorrência ou ajustar timeouts só se souber que ajuda.

Exemplo: você lançou uma mudança no checkout e a taxa de erro subiu. O movimento mais seguro pode ser desligar o novo fluxo e manter o antigo. Se pagamentos parecerem inconsistentes, talvez pause gravações de pedidos enquanto deixa a navegação de produtos disponível.

Duas regras impedem que mudanças “ajudantes” piorem as coisas. Primeiro, faça uma mitigação por vez e observe a métrica que você espera melhorar (erros, latência, profundidade da fila). Segundo, registre o que foi mudado e quando.

Como dar rollback com segurança sem piorar tudo

Rollback é a ação certa quando a última mudança claramente disparou o problema e você pode voltar para um estado conhecido e bom rapidamente. É arriscado quando o problema é relacionado a dados (migrations, jobs escrevendo registros ruins) ou quando reverter só corrige uma camada enquanto configs, feature flags ou dependências continuam quebradas.

Antes de mexer em qualquer coisa, confirme o que você realmente vai reverter. Equipes frequentemente reverte a versão do app e esquece que uma mudança de config, atualização de segredo ou migration causou a queda.

Um caminho de rollback simples para ter no runbook:

• Congele novos deploys e pause qualquer pipeline de auto-deploy.
• Identifique a última release conhecida boa (commit, build ID, tag do container) e o que mudou desde então.
• Verifique mudanças não relacionadas a código: variáveis de ambiente, feature flags, jobs na fila, chaves de terceiros, limites de taxa.
• Decida a abordagem do banco: é seguro reverter ou você precisa de um hotfix adiante.
• Reverter uma coisa por vez e anotar timestamps para correlacionar logs.

Mudanças de banco de dados são a armadilha usual. Se uma migration apaga ou remodela dados, um rollback pode falhar ou fazer o app travar pior. Nesse caso, prefira um conserto para frente pequeno (re-adicionar coluna, camada de compatibilidade ou desativar o novo caminho) em vez de tentar desfazer o esquema.

Após o rollback, faça smoke tests nos fluxos principais: login, inscrição, checkout/faturamento e uma ação core paga pelos usuários. Se o rollback falhar, não faça thrash. Tente um rollback limpo para a release anterior conhecida. Restaure de um backup verificado se necessário. Se nenhuma opção for segura, estabilize (modo manutenção, somente leitura) enquanto planeja um conserto controlado.

O que comunicar durante um incidente (e o que evitar)

Quando a produção está em pane, comunicação clara compra tempo e confiança. Também reduz trabalho duplicado. Compartilhe o que é verdade agora, o que os usuários devem fazer e quando ouvirão de novo.

Estabeleça um ritmo interno cedo e mantenha-o. Uma equipe pequena normalmente precisa de um dono para postar atualizações e um canal onde todas as notas vivem (mesmo que seja um único thread de chat). Use uma cadência estável, não um fluxo constante.

Checklist de atualização interna:

• Quem está no ponto (incident lead) e quem está consertando (responsáveis)
• Status atual (investigando, mitigando, monitorando, resolvido)
• Fatos confirmados mais recentes (o que mudou, o que vocês observaram)
• Próxima ação e quem é o dono
• Próxima atualização (por exemplo, em 15 minutos)

Para clientes, mantenha curto e prático. Diga o que está impactado em linguagem simples, o que podem fazer agora (se houver) e quando terão a próxima atualização.

Evite três coisas durante o incidente: suposições (“provavelmente é o banco”), culpa (“X quebrou”), e prazos não verificados (“consertado em 5 minutos”).

Um template leve que você pode colar:

Status: [Investigating | Mitigating | Monitoring | Resolved]
Impact: [Who is affected and what they can’t do]
Workaround: [If available, one clear step]
What we know: [1-2 confirmed facts, no guesses]
Next update: [time]

Feche o loop com uma atualização final que confirme a recuperação, note qualquer ação de follow-up para usuários (como re-login) e diga o que vem a seguir (revisão de causa raiz e trabalho de prevenção).

Cenário exemplo: queda no login logo após um deploy

São duas pessoas na equipe. Você lançou uma pequena release às 09:05. Às 09:08, mensagens do suporte chegam: “Não consigo fazer login” e “reset de senha não funciona.” Novos cadastros também falham. Todo o resto carrega.

Primeiro, confirme que é real e difundido. Tente fazer login você mesmo (janela anônima, conta normal e conta nova). Se falhar, cheque os sinais mais rápidos:

• Status do provedor de autenticação (outage, limites, desempenho degradado)
• Notas do deploy recente: vars de ambiente, URLs de callback, configurações de cookie, CORS, domínios de redirecionamento
• Logs do app ao redor do endpoint de login (401 vs 500 importa)
• Mudanças de config recentes (rotação de segredos, mudanças de domínio)
• Checagem rápida no banco: a tabela de usuários ou o armazenamento de sessão mudou?

Por volta do minuto 5, você geralmente chega a um ponto de decisão. Se erros começaram imediatamente após o deploy e você não consegue explicar rápido, prefira rollback. Se você isolar o problema para um caminho novo atrás de uma feature flag, desative-a. Escolha um hotfix apenas quando souber exatamente o que mudar e puder testar rápido.

A comunicação do incidente pode ser simples e calma:

• 5 min: “Estamos investigando um problema de login que afeta muitos usuários. Próxima atualização em 20 minutos.”
• 30 min: “A causa parece relacionada ao deploy das 9:05. Estamos revertendo agora. Próxima atualização em 15 minutos.”
• Resolvido: “Login restaurado. Vamos compartilhar um resumo do que aconteceu e como evitaremos repetições.”

Enquanto trabalha, mantenha um doc de notas pequeno: hora exata do deploy, hora do primeiro relato do usuário, mensagens de erro, o que testaram, o que resolveu e o que vão mudar (testes, checagens de config, alerts). Se a base de código for difícil de entender sob pressão, pode valer a pena trazer uma leitura externa rápida.

Erros comuns que atrasam a recuperação

A maioria dos incidentes não se prolonga porque o bug é difícil. Se prolonga porque a equipe perde o fio.

Mudar muitas coisas ao mesmo tempo é o erro clássico. Quando três pessoas cada uma tenta um “conserto rápido” em paralelo, você ganha sinais mistos: logs mudam, métricas oscilam e ninguém consegue dizer o que ajudou. Trate cada mudança como um experimento: uma ação, um resultado esperado, uma checagem rápida para confirmar.

Rollback frequentemente é pulado porque parece admitir derrota. É o contrário. Um rollback é um retorno controlado a um estado conhecido enquanto você depura com menos pressão. Se estiver em dúvida, pergunte: “Existe um rollback seguro que reduz o dano agora?” Se sim, faça.

Outro desperdício de tempo é não pausar deploys. Um colega empurra uma melhora mínima e sobrescreve sua mitigação, ou um pipeline CI continua enviando builds enquanto você está estabilizando. Coloque um passo de congelamento de deploy cedo e deixe visível.

A falta de um incident lead cria trabalho duplicado e conflitante. Uma pessoa deve coordenar, manter uma timeline curta e atribuir tarefas para que duas pessoas não corram atrás da mesma pista.

Finalmente, equipes costumam declarar “resolvido” cedo demais. Valide com um fluxo real de usuário (ou um check parecido com produção), confirme que métricas-chave voltaram ao normal e observe por 10–15 minutos antes de fechar. Muitos “segundos outages” são só o primeiro voltando.

Prevenção de repetição com uma rotina pós-incidente prática

Uma rotina pós-incidente deve ser curta, específica e agendada. Faça em 24 a 72 horas, enquanto logs, notas de deploy e memórias ainda estão frescas. O objetivo não é culpa. É tornar a próxima queda menor, mais rara e mais fácil de lidar.

Mantenha a revisão focada separando causa raiz de fatores contribuintes. A causa raiz é o gatilho direto (por exemplo, uma migration ruim). Fatores contribuintes são o que permitiu que chegasse à produção ou atrasou a recuperação (alerta faltando, propriedade obscura, deploy em horário arriscado, caminhos de código confusos).

Uma agenda de revisão de 30 minutos que funciona

Use uma estrutura simples para não deslizar para opiniões:

• Linha do tempo: o que os usuários viram, quando notaram, quando foi consertado
• Impacto: quem foi afetado e por quanto tempo
• Causa raiz e 2–3 fatores contribuintes principais
• O que funcionou bem (manter) e o que não funcionou (mudar)
• Itens de ação com dono e prazo

Transforme descobertas em trabalho concreto, não promessas vagas. Em vez de “adicionar mais testes”, escreva “adicionar teste que falha se login retornar 500 quando cookie de sessão estiver ausente”. Em vez de “melhorar monitoramento”, escreva “alertar se taxa de erro exceder 2% por 5 minutos após deploy”.

Depois de concordar nas tarefas, atualize seu runbook com uma checagem nova que teria encurtado o incidente. Exemplo: “Antes do deploy, verificar que a variável AUTH_SECRET existe em produção.” Pequenas edições se acumulam.

Se segurança esteve envolvida (segredos expostos, risco de SQL injection, autenticação ruim), inclua remediação clara e um passo de verificação. Remediação pode ser rotacionar chaves e patch no código. Verificação significa provar que está consertado: confirmar que chaves antigas não funcionam mais, reexecutar o caminho de exploração e checar logs por acessos suspeitos.

Checagens rápidas e próximos passos

Quando as coisas estão barulhentas, um checklist curto vence um documento longo. Prenda-o onde sua equipe realmente vai usar.

• Detectar: confirme impacto, janela de tempo e o que mudou mais recentemente.
• Estabilizar: pare o sangramento (pause deploys, desative jobs arriscados, adicione rate limits).
• Mitigar: aplique o workaround mais rápido e seguro para restaurar o serviço.
• Reverter: volte para a última versão conhecida boa se a correção estiver incerta ou for arriscada.
• Verificar + comunicar: confirme recuperação com fluxos reais de usuário e então poste uma atualização clara.

Após o incidente, certifique-se de que seu runbook tem o básico preenchido para sua stack. Você quer respostas que possa usar às 2 da manhã, não teoria.

• Onde checar primeiro: dashboards, logs, tracking de erros e histórico de deploys recentes.
• Como reverter: comandos exatos, quem pode fazer e o que sucesso significa.
• Toggles seguros: feature flags, kill switches, passos de modo de manutenção.
• Contatos: dono on-call, caminho de escalonamento, contatos de fornecedores/atendimento.
• Áreas conhecidas de risco: autenticação, pagamentos, jobs em background, migrations, segredos.

Traia ajuda externa quando incidentes se repetem, ninguém entende a arquitetura o suficiente para depurar rápido, ou houver qualquer sinal de problema de segurança (segredos expostos, queries estranhas no banco, tentativas de injeção).

Se você está lidando com um protótipo gerado por IA que continua falhando em produção, uma equipe de remediação como FixMyMess (fixmymess.ai) pode ajudar diagnosticando a base de código, reparando lógica, endurecendo segurança e preparando para deploys confiáveis.

Mantenha o runbook vivo: designe um único dono, revise mensalmente por 15 minutos e atualize após cada incidente enquanto os detalhes ainda estão frescos.