Resolvendo Problemas de Produção às 2 da Manhã: Um Guia de Sobrevivência

2:17 AM. PagerDuty. O alerta diz que a taxa de erro do serviço de pagamento é de 95%. 847 transações afetadas. Seu estômago cai. Você acorda instantaneamente—aquele tipo específico de adrenalina que só vem de incidentes de produção. Seu telefone já está desbloqueado, o laptop iniciando, a cafeteira gorgolejando para a vida apenas pela memória muscular. Esta é a página número 847 na sua carreira. Sim, você acompanha isso. Começou a contar depois da página 200 quando percebeu que isso seria uma parte definidora da sua vida profissional e que, se fosse acordado em horários impensáveis, pelo menos teria dados sobre isso. O serviço de pagamento. Claro que é o serviço de pagamento. É sempre o serviço de pagamento, ou a camada de autenticação, ou aquele microserviço que alguém jurou que era "apenas uma simples camada" há três anos e desde então se metastatizou em uma dependência crítica para metade da sua infraestrutura. Você tem talvez 90 segundos antes que a segunda página seja enviada para o seu gerente. Talvez três minutos antes que os clientes comecem a inundar os canais de suporte. Talvez cinco minutos antes que alguém do C-suite acorde e comece a fazer perguntas no Slack. O tempo está passando, suas mãos estão se movendo e seu cérebro já está percorrendo a lista mental que você construiu ao longo de centenas desses incidentes. Este não é seu primeiro rodeio. Mas aqui está algo que ninguém te diz sobre depuração em produção às 2 da manhã: nunca fica mais fácil. Você apenas fica mais rápido. Você constrói ferramentas melhores. Você comete menos erros estúpidos. Você aprende a confiar em seus instintos enquanto questiona tudo ao mesmo tempo. Você desenvolve um sexto sentido para o que realmente está quebrado versus o que apenas parece quebrado. E, mais importante, você aprende que a diferença entre um incidente de 10 minutos e um incidente de 4 horas muitas vezes se resume aos primeiros 60 segundos da sua resposta. Este guia é tudo o que eu desejava que alguém tivesse me dito antes da página número 1.

Os Primeiros 60 Segundos: Triagem Como se Sua Emprego Dependesse Disso

O primeiro minuto de qualquer incidente de produção é pura gestão do caos. Seu cérebro ainda está iniciando, você provavelmente não está vestindo calças, e você precisa tomar decisões críticas que determinarão se esse incidente será resolvido em minutos ou horas. Aqui está o que eu faço, por ordem, toda vez: Reconheça o alerta imediatamente. Não espere para "investigar primeiro." Reconheça-o. Isso interrompe a cadeia de escalonamento e sinaliza para sua equipe que alguém está a postos. Vi muitos incidentes em que várias pessoas foram alertadas porque o primeiro respondente queria "apenas dar uma olhada rápida" antes de reconhecer. Aqueles 30 segundos de investigação custaram a você respostas de backup que poderiam estar dormindo. Abra seu painel de resposta a incidentes. Não o aplicativo. Não os logs. Seu painel. Aquele que mostra a saúde do sistema em um relance. Para mim, esse é um painel personalizado do Grafana que mostra taxas de erro, percentis de latência, pools de conexão de banco de dados, profundidades de fila e CPU/memória em todos os serviços críticos. Posso ver o raio de explosão em menos de 5 segundos. Verifique se ainda está acontecendo. Isso parece óbvio, mas já fui alertado para problemas que se resolveram 30 segundos antes do alerta disparar. Sistemas de monitoramento têm atraso. Limiares de alerta têm janelas de avaliação. Às vezes, o problema já desapareceu, e você precisa saber disso antes de começar a reverter implantações ou reiniciar serviços. Avalie o impacto no cliente. Não impacto teórico—impacto real. Quantos usuários estão afetados neste momento? É 100% do tráfego ou 5%? Está isolado em uma região, um segmento de cliente, uma funcionalidade? Isso determina a urgência da sua resposta e se você precisa acordar mais pessoas. Neste incidente em particular—o serviço de pagamento às 2:17 AM—meu painel me informou tudo que eu precisava saber em 8 segundos. Taxa de erro: 94.7%. Solicitações afetadas: 847 nos últimos 5 minutos. Distribuição geográfica: global. Segmento de cliente: todos. Latência da API do provedor de pagamento: normal. Conexões de banco de dados: normais. O problema não estava a montante ou a jusante. Era nós. Foi quando eu soube que estava prestes a ter uma longa noite.

A Metodologia de Depuração Que Realmente Funciona Sob Pressão

Todo mundo tem uma metodologia de depuração quando está calmo, com cafeína, e trabalhando em um ambiente de desenvolvimento às 2 PM. Muito poucas pessoas têm uma metodologia que se mantém quando você está com sono, o CEO está no canal de incidentes, e cada segundo de tempo de inatividade está custando dinheiro de verdade. Eu uso o que chamo de abordagem "Raio de Explosão para Causa Raiz". Não é sofisticado, mas funciona quando seu cérebro está funcionando a 60% da capacidade. Comece pelo raio de explosão, não pela causa raiz. Isso é contraintuitivo. Todo instinto diz que você deve encontrar a causa raiz imediatamente. Resista a esse instinto. Primeiro, entenda exatamente o que está quebrado e o que não está. Mapeie os limites da falha. Isso serve a dois propósitos: impede que você persiga falsos positivos em sistemas saudáveis e, frequentemente, aponta diretamente para a causa raiz por meio do processo de eliminação. No incidente do serviço de pagamento, passei 90 segundos mapeando o raio de explosão: - Iniciação de pagamento: falhando - Verificações de status de pagamento: falhando - Webhooks de pagamento: falhando - Processamento de reembolso: funcionando bem - Consultas de pagamento de admin: funcionando bem Esse padrão me disse algo importante: operações de leitura estavam boas, operações de escrita estavam falhando. Isso é um problema de banco de dados, um problema de fila, ou um problema de permissões. Três possibilidades em vez de trinta. Siga o fluxo de dados, não o fluxo de código. Quando você está depurando às 2 AM, não tem tempo para rastrear o código. Siga os dados. Onde um pedido de pagamento entra no sistema? Para onde ele vai a seguir? Onde ele falha? Eu abri nosso rastreamento distribuído (ainda bem que tínhamos isso) e assisti a uma única solicitação fluir pelo sistema. Ela passou pela autenticação, pelo controle de taxa, pela validação, e morreu no momento em que tentou gravar no banco de dados. Banco de dados. Era ali. Verifique primeiro as coisas chatas. Espaço em disco. Memória. Pools de conexão. Descritores de arquivo. Expiração de certificado. DNS. As coisas chatas matam mais sistemas de produção do que bugs inteligentes jamais farão. Fui alertado às 2 AM porque o cron job de alguém preencheu o disco. Fui alertado porque um certificado expirou. Fui alertado porque alguém mudou um TTL de DNS e não esperou pela propagação. Neste caso, o pool de conexão do banco de dados estava a 100%. Cada conexão estava em uso. Mas por quê? O tráfego não havia disparado. Os padrões de consulta não tinham mudado. Algo estava mantendo as conexões abertas. Confie no seu monitoramento, mas verifique tudo. Sistemas de monitoramento mentem. Não maliciosamente—são apenas software, e software tem bugs. Já vi sistemas de monitoramento relatar serviços saudáveis que estavam completamente fora do ar. Já vi eles relatarem erros que não existiam. Sempre verifique manualmente o caminho crítico. Para sistemas de pagamento, mantenho um cartão de crédito de teste e um comando curl prontos para usar. Posso validar todo o fluxo de pagamento em 10 segundos. Eu executei meu pagamento de teste. Ele travou por 30 segundos e expirou. O monitoramento não estava mentindo. Estávamos realmente fora do ar.

O Incidente Que Me Ensinou Tudo Sobre Conexões de Banco de Dados

Deixe-me contar sobre a página número 312. Era 3:47 AM numa terça-feira de março, e mudou a forma como penso sobre a gestão de conexões de banco de dados para sempre. Estávamos realizando uma venda relâmpago. O tráfego estava alto, mas não sem precedentes—já havíamos lidado com picos maiores. Então, de repente, todos os serviços que tocavam no banco de dados começaram a expirar. Pool de conexões esgotado. Sintomas clássicos. A resposta óbvia: aumentar o tamanho do pool de conexões. Então fizemos isso. Nós dobramos. Depois triplicamos. O problema só piorou. Foi quando aprendi que às vezes a solução torna o problema pior. Cada conexão que adicionamos ao pool era outra conexão tentando executar uma consulta em um banco de dados que já estava sobrecarregado. Estávamos DDoSando a nós mesmos. O verdadeiro problema? Um desenvolvedor adicionou um novo recurso que fez uma varredura completa em uma tabela com 50 milhões de linhas. Sem índice. A consulta levou 45 segundos para ser concluída. Cada solicitação que atingiu esse caminho de código segurou uma conexão de banco de dados por 45 segundos. Com tráfego suficiente, esgotamos o pool de conexões não porque não tínhamos conexões suficientes, mas porque cada conexão estava presa esperando aquela consulta horrível terminar. A correção não era mais conexões. Era matar aquela consulta, adicionar um índice e implementar timeouts de consulta no nível da aplicação. Esse incidente me ensinou três coisas: O esgotamento do pool de conexão é um sintoma, não uma doença. Quando você vê isso, não aumente imediatamente o pool. Pergunte-se por que as conexões não estão sendo liberadas. As consultas estão lentas? Existem deadlocks? Alguma coisa está mantendo transações abertas? O pool de conexão está dizendo que há um problema em outro lugar. Time-outs de consulta devem estar em todo lugar. Cada consulta de banco de dados deve ter um tempo limite. Cada requisição HTTP deve ter um tempo limite. Cada operação de fila deve ter um tempo limite. Timeouts não são opcionais. Eles são a diferença entre um serviço degradado e um serviço completamente morto. Quando algo dá errado, timeouts permitem que você falhe rápido em vez de acumular conexões bloqueadas até que todo o sistema colapse. Monitorar a utilização do pool de conexão não é suficiente. Você precisa monitorar a duração da conexão. Quanto tempo é a média de uma conexão mantida? Qual é o P99? Se a duração média da conexão saltar repentinamente de 50ms para 5 segundos, você tem um problema mesmo que seu pool ainda não esteja esgotado. Esse é seu sistema de alerta precoce. Voltando ao incidente do serviço de pagamento às 2:17 AM. Eu verifiquei a duração da conexão. Média: 8 segundos. P99:

Debugging Production Issues at 2 AM: A Survival Guide

Resolvendo Problemas de Produção às 2 da Manhã: Um Guia de Sobrevivência

Os Primeiros 60 Segundos: Triagem Como se Sua Emprego Dependesse Disso

A Metodologia de Depuração Que Realmente Funciona Sob Pressão

O Incidente Que Me Ensinou Tudo Sobre Conexões de Banco de Dados