Lista de verificação e manual de resposta a incidentes de tempo de inatividade do site

Quando um alerta de monitoramento automatizado é acionado, as equipes de engenharia devem seguir um fluxo de trabalho estruturado de resposta a incidentes para minimizar o tempo médio de recuperação (MTTR) e evitar a interrupção do usuário.

Este manual operacional fornece uma lista de verificação passo a passo testada em batalha, projetada para engenheiros de confiabilidade de sites (SREs), equipes de DevOps e desenvolvedores da Web durante interrupções de produção de alta gravidade.

Resumo da resposta primeiro

Um fluxo de trabalho eficaz de resposta a incidentes de inatividade de um site consiste em quatro fases críticas: Identificação e triagem (verificação do consenso da investigação multirregional), Isolamento de causa raiz (inspeção de DNS, TLS, CDN de borda e camadas de banco de dados de back-end), Mitigação de incidentes (reversão de implantações recentes ou dimensionamento de recursos do servidor) e Análise post-mortem (documentação de causas raiz e itens de ação preventiva).Seguir uma lista de verificação padronizada reduz o tempo médio de recuperação (MTTR) de horas para minutos.

Fluxo de trabalho passo a passo de triagem de incidentes

Fase 1: Identificação e Triagem de Interrupção (0 - 2 Minutos)

1. Verificar o escopo da interrupção: inspecione o consenso da investigação multirregional em SimpleOps para confirmar se a interrupção afeta usuários globais ou regiões geográficas específicas.
2. Verifique a prioridade do alerta: Faça a distinção entre falhas completas de disponibilidade (HTTP 5xx, tempos limite de conexão TCP) e degradações de desempenho localizadas (LCP > 4,0s).
3. Notificar a equipe de plantão: encaminhe atualizações de incidentes para canais de bate-papo internos do desenvolvedor (Slack, Telegram) e atribua um comandante de incidente.

Fase 2: Isolamento da causa raiz (2 a 5 minutos)

1. Inspecione a camada de resolução de DNS: verifique se os servidores de nomes de domínio resolvem os registros A/AAAA corretos e verifique se há atrasos na propagação do DNS global ou erros de bloqueio do registrador.
2. Validar a integridade do certificado SSL/TLS: confirme as datas de expiração do certificado, os nomes alternativos do assunto (SANs) e a integridade da cadeia confiável da CA.
3. Examine o Edge CDN e o proxy reverso: inspecione os códigos de status de resposta HTTP do edge (por exemplo, 502 Bad Gateway, 504 Gateway Timeout, 500 Internal Error) e as taxas de acertos do edge cache.
4. Avalie o banco de dados de back-end e o servidor de aplicativos: verifique o uso da CPU, a utilização da memória, a saturação do pool de conexões e os bloqueios de banco de dados.

Fase 3: Mitigação e Resolução (5 a 15 minutos)

1. Executar reversão de emergência: se a interrupção coincidir com uma implantação recente de código ou alteração de infraestrutura, execute imediatamente uma reversão automática de CI/CD.
2. Failover para região secundária: redirecione o tráfego para nós de infraestrutura redundantes ou origens CDN secundárias se ocorrerem falhas de hardware regionais.
3. Aplique limitação de taxa ou disjuntores: proteja instâncias de banco de dados durante picos de tráfego ativando a limitação de taxa ou desativando temporariamente trabalhos em segundo plano não críticos.

Fase 4: Ações Post-Mortem e Preventivas (Pós-Incidente)

1. Documente o cronograma do incidente: registre carimbos de data/hora exatos para detecção de alertas, triagem inicial, identificação da causa raiz e resolução.
2. Conduzir post-mortem sem culpa: Convoque uma retrospectiva de engenharia para analisar por que as salvaguardas falharam e estabelecer itens de ação preventiva.
3. Atualizar monitoramento automatizado: adicione verificações de regressão específicas ou testes sintéticos personalizados em SimpleOps para detectar padrões de vulnerabilidade semelhantes no futuro.

Matriz de Gravidade de Incidentes

Padrões comuns de falhas e soluções de emergência

1. Esgotamento do pool de conexões de banco de dados: redefina as conexões ativas ou aumente o limite máximo do pool nos arquivos de configuração my.cnf / postgresql.conf.
2. Certificado SSL ACME expirado: execute comandos manuais de renovação do Certbot com --force-renewal e verifique o roteamento de desafio HTTP-01 por meio do Nginx.
3. Nginx Reverse Proxy 502 Bad Gateway: verifique se o processo do servidor de aplicativos upstream (por exemplo, instância Node.js PM2 ou binário Go Gin) está em execução na porta 8080 ou 4000.
4. Falhas no processo de vazamento de memória: reinicie os pools de threads de trabalho ou instâncias de aplicativos e, em seguida, colete instantâneos de memória de despejo de heap para criação de perfil de diagnóstico.

Comunicação e transparência das partes interessadas

Durante uma grande interrupção de produção, uma comunicação externa e interna clara é tão importante quanto a correção técnica:

• Notificação ao cliente: atualize as páginas de status públicas imediatamente com tempos de resolução estimados realistas e atualizações de progresso claras.
• Sincronização de status interno: mantenha sincronizações operacionais de 15 minutos entre o Incident Commander, líderes de engenharia e representantes de suporte ao cliente.
• Comunicação pós-incidente: envie relatórios de incidentes ao cliente explicando o que aconteceu, por que aconteceu e quais alterações permanentes de engenharia foram feitas para evitar recorrências.

Melhores práticas para manutenção do manual de incidentes

• Revisão após cada interrupção do SEV-1: atualize as etapas do procedimento imediatamente após as retrospectivas post-mortem para refinar as etapas de triagem.
• Automatizar ganchos de monitoramento: garanta que SimpleOps Webhooks publiquem alertas automaticamente nos canais do Slack e Telegram.
• Fluxos de trabalho de resposta a exercícios: realize simulações trimestrais de exercícios de interrupção de incêndio para treinar novos membros da equipe de engenharia no protocolo de incidentes.
• Mantenha caminhos de escalonamento claros: mantenha os detalhes de contato de plantão secundário e terciário atualizados em sua lista de gerenciamento de incidentes.

Usando SimpleOps para resposta automatizada a incidentes

SimpleOps integra-se diretamente com fluxos de trabalho DevOps modernos, enviando alertas instantâneos de incidentes via Slack, Telegram, Email ou Webhooks personalizados para iniciar automaticamente a lista de verificação de sua equipe após a primeira falha confirmada.