Produção em chamas no desenvolvimento — o que é, causas e algoritmo de ação

O que significa “produção em chamas” e tipos de falhas

A expressão “produção em chamas” (tudo caiu) descreve uma situação em que o ambiente de produção está funcionando incorretamente e os usuários são afetados. A falha pode se manifestar como indisponibilidade total do aplicativo (tela em branco, erro 502), indisponibilidade parcial (o módulo de pagamento não funciona mas as demais funções estão disponíveis) ou degradação de desempenho (carregamento extremamente lento). A severidade do incidente é determinada pela porcentagem de usuários afetados e pela duração da queda.

De acordo com a Atlassian Statuspage (2025), o tempo de inatividade médio para aplicativos móveis em 2024 foi de 27 minutos por incidente. As causas mais comuns: regressão de código após implantação (34%), queda do provedor de nuvem (22%), problemas com banco de dados (18%), erros de configuração (15%) e ataques DDoS (11%). Conclusão principal: a maioria das falhas é causada por mudanças que a própria equipe introduziu, não por fatores externos.

É importante distinguir entre um crash (falha do aplicativo no cliente) e uma queda do backend (indisponibilidade do servidor). Um crash geralmente é corrigido com um hotfix do código do cliente, enquanto uma queda do backend requer mudanças na infraestrutura ou reimplantação do serviço. Métricas de monitoramento: para o cliente — taxa livre de crashes, para o servidor — taxa de erro 5xx e latência p95. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — ajuda a determinar rapidamente o tipo de falha.

Severidade de incidentes: P0, P1, P2 e critérios de classificação

Uma classificação unificada de severidade é a base de uma resposta rápida. Sem ela, a equipe perde tempo discutindo “tão urgente é isso” em vez de agir. A escala clássica: P0 (crítico) — o aplicativo está completamente indisponível ou dados de usuários estão vazando, tempo de resposta — imediato; P1 (alto) — a funcionalidade crítica não funciona para 50%+ dos usuários, tempo de resposta — 15 minutos; P2 (médio) — funcionalidade não crítica indisponível para alguns usuários, tempo de resposta — 1 hora.

P0 requer escalonamento imediato: o engenheiro de plantão interrompe qualquer trabalho em andamento e foca no incidente. Se o problema não for resolvido em 10 minutos — o tech lead é envolvido. Se após 30 minutos — escalonamento para o engineering manager. Para incidentes P0 é permitido quebrar qualquer processo: fazer um hotfix sem revisão completa de código, implantar diretamente em produção, ignorar regras de proteção de branch. Emergency override deve ser previamente acordado em nível de equipe.

Tabela de severidade

É extremamente importante não subestimar a severidade. Incidentes P0 e P1 classificados como P2 levam a resposta tardia e aumento do tempo de inatividade. Regra: se estiver em dúvida — defina P0. Sobreclassificar é melhor que subclassificar: é melhor realizar uma reunião extra do que perder uma hora de recuperação.

Primeiros 10 minutos: algoritmo de ação durante uma falha

O cronômetro começa: a partir do momento em que um alerta ou mensagem de um usuário chega. Os primeiros 10 minutos são os mais importantes. Algoritmo: 1) confirmar o problema — garantir que o problema é real (não é um falso alarme); 2) estancar o sangramento — reduzir o impacto imediatamente (rollback, feature toggle, bloqueio de endpoint); 3) comunicar — escrever no canal geral #incident o status: o que aconteceu, severidade, o que está sendo feito. Os primeiros 10 minutos não são gastos na análise da causa raiz.

Em paralelo com estancar o sangramento, um engenheiro começa o diagnóstico enquanto outro gerencia a comunicação. Canais de comunicação: canal Slack #incident (para a equipe), página de status (para os usuários), e-mail/SMS de escalonamento (para a gerência). A cada 15 minutos — uma atualização de status com informações: o que se sabe, o que está sendo feito, tempo estimado de recuperação. Página de status (StatusPage, Statuspal) exibe o tempo de atividade e o histórico de incidentes para usuários externos.

Como estancar o sangramento: rollback, feature toggle e hotfix

A primeira e mais importante regra: não tente corrigir o problema em produção. Se um novo lançamento causou a falha — reverta para a versão estável anterior. Se a falha é causada por uma funcionalidade específica que está atrás de um feature toggle — simplesmente desative o toggle. Se nem rollback nem toggle estão disponíveis — aplique um hotfix com diff mínimo. Rollback é a opção mais segura porque retorna a um estado que já estava funcionando.

Feature toggle (também conhecido como feature flag) é uma ferramenta poderosa para estancar o sangramento sem uma implantação. Se o módulo de pagamento falhar mas estiver desativado por toggle — os usuários simplesmente não veem o botão de pagamento em vez de receberem uma tela de erro. Um toggle não requer compilação, não requer revisão da loja e entra em vigor em segundos. Cada funcionalidade crítica deve estar atrás de um feature toggle com capacidade de desativação em nível de servidor (config remota). Feature flag — a primeira linha de defesa.

Se o rollback for impossível (por exemplo, devido a uma migração irreversível de banco de dados) e não houver toggle — o último recurso é um hotfix com alterações mínimas. O hotfix é criado a partir da última tag de lançamento, contém apenas as linhas necessárias para corrigir a falha e passa por implantação rápida (veja o artigo “Hotfix — correções urgentes”). Regra de ouro: após a estabilização, sempre faça uma análise de causa raiz, mesmo que a causa pareça óbvia.

Diagnóstico de causas: logs, métricas e alertas

Após estancar o sangramento (ou em paralelo, se o número de engenheiros permitir), começa o diagnóstico. A primeira fonte são os logs. O registro centralizado (ELK, Grafana Loki, Datadog Logs) permite encontrar erros por timestamp, ID de usuário ou ID de requisição. Importante: os logs devem ser estruturados (JSON) para que o grep funcione rapidamente. Registro estruturado é um requisito obrigatório para todos os serviços.

A segunda fonte são as métricas. Grafana, Datadog, New Relic mostram quando ocorreu o pico de erros, em quais endpoints e com quais códigos de status. A comparação de métricas antes e depois da implantação ajuda a localizar o problema em um serviço ou endpoint específico. Métricas RED (Rate, Errors, Duration) — o padrão de monitoramento de microsserviços.

A terceira fonte é o rastreamento distribuído (distributed tracing). Jaeger, Zipkin, Datadog APM mostram o caminho da requisição através dos microsserviços e identificam onde exatamente ocorreu o atraso ou erro. O rastreamento é especialmente útil em falhas em cascata, quando uma falha em um serviço causa erros em todos os dependentes. Trace ID deve ser transmitido do cliente para todos os serviços backend.

# Exemplo de diagnóstico rápido usando kubectl e logs
# Listar pods com erros
kubectl get pods --field-selector=status.phase!=Running

# Verificar logs do pod que caiu
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Procurar erros no serviço nos últimos 30 minutos
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Importante: não tente diagnosticar a causa antes de estancar o sangramento. Se 50% dos usuários estão vendo um crash — primeiro reverta, depois investigue. Exceção: se um rollback levasse mais tempo que um hotfix direto (por exemplo, devido a incompatibilidade de dados). Neste caso, aplique o hotfix imediatamente e realize o post-mortem após a estabilização. Diagnosticar antes de corrigir é um padrão perigoso que aumenta o tempo de inatividade.

Post-mortem: como analisar incidentes sem procurar culpados

Post-mortem (também chamado de revisão de incidentes) é uma análise estruturada do incidente realizada 24–72 horas após sua resolução. Seu objetivo: entender por que a falha ocorreu, por que o monitoramento e os testes não a detectaram antes da produção, e o que mudar nos processos para prevenir a recorrência. Cultura sem culpa é um princípio fundamental: o post-mortem discute processos, ferramentas e comunicação, não os erros de pessoas específicas.

Estrutura do documento post-mortem: cronologia (sequência de eventos com timestamps), impacto (usuários afetados, duração, perdas financeiras), causa raiz (causa técnica principal), detecção (como foi descoberto, por que não foi detectado antes), resposta (o que foi feito, o que poderia ter sido feito mais rápido), ações (tarefas específicas com responsáveis e prazos). As ações devem ser S.M.A.R.T.: específicas, mensuráveis, atribuíveis, realistas e com prazo definido.

Ações típicas após uma falha de produção: adicionar monitoramento e alertas para a métrica que estava silenciosa; expandir a cobertura de testes para o caso perdido; adicionar uma página ao runbook com um algoritmo passo a passo para uma situação similar; realizar treinamento da equipe na ferramenta que foi usada incorretamente. Cada ação é uma mudança concreta que reduz a probabilidade de recorrência do incidente.