Por que você precisa de um plano escrito
Durante um incidente, seu cérebro não funciona com capacidade total. O estresse reduz seu foco. Você esquece etapas. Você pula a comunicação. Você corrige o sintoma, mas não a causa.
Um plano escrito de resposta a incidentes elimina o pensamento dos primeiros 10 minutos. Você segue uma lista de verificação. Você sabe o que fazer e em que ordem. O plano cuida do processo para que seu cérebro possa cuidar da depuração.
Este modelo foi projetado para equipes pequenas (2 a 10 pessoas). Ele pressupõe que você não tem uma equipe SRE dedicada nem um rodízio de plantão com 15 pessoas. Ele pressupõe que a pessoa que é alertada também é a pessoa que corrige o problema.
O plano de resposta a incidentes
Passo 1: Detectar
Sua ferramenta de monitoramento alerta você. Você recebe uma notificação: “Monitor [nome] está fora do ar. 3 falhas consecutivas. HTTP 500.”
Não entre em pânico. Tire 30 segundos para verificar. Acesse o site você mesmo. Verifique seu painel de monitoramento em busca de outros alertas. Um único monitor fora do ar pode ser um alarme falso. Vários monitores fora do ar significam um incidente real.
Se você usa o PingWatchdog, os incidentes são criados automaticamente quando os monitores caem. Você obtém uma linha do tempo do que aconteceu e quando. Este é seu ponto de partida para depuração.
Passo 2: Declarar
Se este for um incidente real (não um alarme falso ou um evento planejado), declare-o. Informe sua equipe. Informe seus usuários.
Para sua equipe: Publique no canal de incidentes designado (Slack, Discord, Teams). Inclua o que você sabe: quais monitores estão fora do ar, quando caíram, quais erros você está vendo. Marque qualquer pessoa que possa precisar ser envolvida.
Para seus usuários: Atualize sua página de status. Publique uma atualização de “Investigando”. Você não precisa saber a causa raiz. Você só precisa reconhecer o problema. “Estamos investigando relatos de erros elevados de API. Próxima atualização em 15 minutos.”
Sua página de status deve se atualizar automaticamente a partir dos seus dados de monitoramento. Se um monitor está fora do ar, a página de status deve mostrar isso. A atualização manual informa aos usuários que você está cuidando disso.
Passo 3: Investigar
Comece com a explicação mais simples. Você implantou recentemente? Uma dependência mudou? Um serviço terceirizado teve um incidente?
Verifique seus dados de monitoramento. Quais erros as sondas estão reportando? Conexão recusada? Falha de DNS? Tempo limite? HTTP 500 com uma mensagem de erro específica? Os dados da sonda mostram o que o mundo exterior vê.
Verifique seus logs. Logs de aplicação, logs de banco de dados, logs do servidor web. Procure erros que começaram mais ou menos no mesmo horário em que o monitor caiu.
Verifique sua infraestrutura. O servidor está no ar? O banco de dados está aceitando conexões? O uso de memória ou disco está aumentando? A utilização da CPU está anormal?
Passo 4: Mitigar
Uma vez que você sabe o que está errado, estanque o sangramento. Esta pode não ser a correção permanente. Tudo bem. O objetivo é restaurar o serviço primeiro, depois corrigir a causa raiz.
Mitigações comuns:
- Implantar um rollback: Se uma implantação recente causou o problema, volte para a versão anterior. Implante a correção após o incidente ser resolvido.
- Reiniciar um serviço: Pools de conexão de banco de dados, servidores de cache e filas de mensagens às vezes precisam de uma reinicialização. Reinicie o serviço e monitore a recuperação.
- Escalar recursos: Se o problema for esgotamento de recursos (CPU, memória, conexões), escale para cima. Você pode reduzir após o incidente.
- Failover: Se um único servidor ou região for afetado, redirecione o tráfego para outro lugar.
Passo 5: Comunicar
Durante a mitigação, publique outra atualização de status. “Problema identificado como esgotamento do pool de conexões do banco de dados. Estamos implantando uma correção.”
Após a implantação da correção, publique novamente. “Correção implantada. Monitorando recuperação.”
Após confirmar a recuperação, publique a atualização final. “Serviço restaurado. Duração do incidente: 23 minutos.”
Não deixe passar mais de 30 minutos sem uma atualização, mesmo que a atualização seja “Ainda investigando. Delimitamos o problema à camada de banco de dados.” O silêncio cria incerteza. Atualizações criam confiança.
Passo 6: Resolver
Aguarde seus monitores confirmarem a recuperação. Não declare o incidente resolvido com base em uma verificação manual rápida. Deixe as verificações automatizadas confirmarem que o serviço está estável.
O PingWatchdog resolve incidentes automaticamente quando os monitores retornam ao status “no ar” por um período sustentado. Isso garante que você não feche um incidente prematuramente.
Passo 7: Post-mortem
Dentro de 24 horas após o incidente, escreva um breve post-mortem. Não precisa ser um documento formal. Uma mensagem no Slack ou um documento curto funciona. Responda a estas perguntas:
- O que aconteceu? Descreva o incidente em linguagem simples.
- Qual foi o impacto? Por quanto tempo os serviços foram afetados? Quais serviços? Quantos usuários?
- Qual foi a causa raiz? O que especificamente desencadeou a falha?
- Como foi detectado? O monitoramento detectou? Um usuário reportou?
- Como foi resolvido? Quais etapas foram tomadas para corrigir?
- O que impedirá a recorrência? Quais itens de ação resultam disso?
O objetivo do post-mortem não é atribuir culpa. É aprender e melhorar. Cada incidente é uma oportunidade de tornar seu sistema mais confiável.
Configurando seu kit de ferramentas para incidentes
Para executar este plano, você precisa de algumas coisas preparadas antes que um incidente aconteça:
Monitoramento: Monitoramento de uptime, monitoramento SSL e monitoramento heartbeat. Você precisa saber dos problemas antes que os usuários os reportem. Configure o monitoramento do PingWatchdog.
Alertas: Alertas roteados para os canais certos. Monitores críticos vão para o PagerDuty ou notificações por telefone. Os não críticos vão para o Slack. Configure canais de alerta.
Página de status: Uma página de status pública onde os usuários podem verificar a saúde do serviço. As atualizações durante incidentes devem ser rápidas e honestas. Configure uma página de status.
Gerenciamento de incidentes: Incidentes criados automaticamente com linhas do tempo. Quando um incidente começa, você não deve precisar criar um ticket manualmente. A ferramenta de monitoramento deve fazer isso por você. Saiba mais sobre gerenciamento de incidentes.
Canais de comunicação: Um canal do Slack, sala do Discord ou canal do Teams designado para incidentes. Todos sabem para onde ir durante um incidente.
Pratique o plano
Faça um simulado. Escolha um serviço não crítico. Derrube-o intencionalmente. Siga o plano. Cronometre quanto tempo cada etapa leva.
A maioria das equipes descobre que a parte mais difícil não é a correção técnica. É a comunicação. “Corrigi o problema em 5 minutos, mas passei 15 minutos descobrindo o que dizer na página de status.” A prática torna a comunicação mais rápida.
Comece a construir seu plano
O modelo acima funciona como está. Personalize os nomes dos canais, os caminhos de escalonamento e as referências de ferramentas para sua equipe. Mantenha-o curto. Se o plano tiver mais de uma página, sua equipe não o lerá durante um incidente.
Comece a monitorar gratuitamente com o PingWatchdog. Todos os planos incluem gerenciamento de incidentes com criação e resolução automática de incidentes.