Noções Básicas de Incidentes

8 exemplos para gerenciar seu primeiro incidente Node.js com calma - 6 básicos e 2 intermediários. Cobre severidade, comunicação e o checklist dos primeiros 15 minutos.

Pré-requisitos

• Rotação de plantão com PagerDuty/Opsgenie conectada a alertas de SLO
• README do serviço com links para runbooks (veja Iniciadores de Runbook para Plantão)
• Logs estruturados com requestId e traceId (veja IDs de Correlação de Requisição)
• Dashboards para latência p95, taxa de erros, uso de heap RSS e tempo de espera do pool do DB

Exemplos Básicos

1. Declare a Severidade em 5 Minutos

• SEV1 aciona o Comandante do Incidente + atualização da página de status em 15 minutos
• Na dúvida, arredonde para cima - rebaixar é mais fácil do que subestimar a resposta
• Documente a severidade no tópico do canal de incidentes: [SEV2] orders-api alta latência

Relacionado: Melhores Práticas de Resposta a Incidentes - checklist completo do runbook

2. Atribua Funções de Incidente

Comandante do Incidente (IC)  - responsável pelas decisões, cronograma, escalonamento
Líder Técnico (TL)      - conduz a mitigação, lê logs/métricas
Líder de Comunicação (Comms Lead) - página de status, atualizações para stakeholders
Escriba (Scribe)        - cronograma, comandos executados, links para gráficos

• O IC não depura sozinho - delega a investigação ao TL
• O Escriba posta a cada 10 minutos no #incident-orders-api
• Rotacione o IC se o incidente exceder 2 horas

3. Checklist dos Primeiros 15 Minutos para Node.js

[ ] Acuse o alerta; entre na ponte / sala de bate-papo do Slack
[ ] Confirme o raio de explosão (quais serviços, tenants, regiões)
[ ] Verifique o último deploy (SHA do git, hora, quem)
[ ] Grafana: taxa de erros, p95, reinícios de pods, contagem de OOMKilled
[ ] Logs: pico de 5xx, ECONNREFUSED, timeout de pool, ETIMEDOUT
[ ] Mudanças recentes de configuração/segredo/flag
[ ] Decida: rollback, escalar, desativar feature-flag ou investigar
[ ] Poste a primeira atualização externa se SEV1/SEV2

• Não reinicie pods cegamente antes de verificar a correlação com o deploy
• Capture o estado de kubectl get pods / tarefas ECS antes das mudanças
• Salve um snapshot do heap apenas se a memória for suspeita e o tráfego for limitado

Relacionado: Resposta ao OOM Killer - triagem de memória | Rollback de Deploy Ruim - caminhos de rollback

4. Estabilize Antes da Causa Raiz

Mitigação é melhor que diagnóstico perfeito na primeira hora.

• Registre cada ação de mitigação com timestamp na thread do incidente
• Marque "estabilizado" quando a taxa de erros retornar abaixo do SLO por 15 minutos
• A análise da causa raiz continua após a cessação do impacto no cliente

5. Comunique em Linguagem Clara

Ruim: "O loop de eventos foi bloqueado devido à saturação do libuv."

Bom: "O checkout está falhando para cerca de 30% dos usuários. Implantamos uma correção às 14:22 UTC e os erros estão diminuindo. Próxima atualização em 20 minutos."

Modelo para atualizações de stakeholders:

**Impacto:** <quem é afetado, o que está quebrado>
**Status:** Investigando | Mitigando | Monitorando | Resolvido
**Ações:** <o que fizemos nos últimos 20 min>
**Próxima atualização:** <hora UTC>

• PM e suporte precisam do impacto no cliente, não de dumps de heap
• Linke dashboards internos apenas em canais de engenharia

6. Colete Evidências Específicas do Node.js

# Memória e reinícios do pod
kubectl top pods -n production -l app=orders-api
kubectl describe pod <pod> | grep -A5 "Last State"
 
# Deploy recente
kubectl rollout history deployment/orders-api -n production
 
# Logs com correlação
# filter: service=orders-api level=error last 30m

• Exporte gráficos de latência p95 e taxa de erros cobrindo a janela de deploy
• Anote a versão do Node, o digest da imagem e NODE_OPTIONS se for relacionado à memória
• Salve logs de consultas lentas se erros de DB aparecerem nas traces

Exemplos Intermediários

7. Estrutura da Chamada de Ponte (Cadência de 30 Minutos)

0:00  IC declara severidade, impacto, hipótese atual
0:05  TL compartilha último snapshot de métricas
0:10  Decisão: rollback / escalar / desativar flag / continuar depuração
0:15  Comms posta atualização externa
0:25  Escriba lê o cronograma; confirma os responsáveis pelas ações
0:30  Repetir ou rebaixar a severidade

• Limite os participantes a 8 - mova a depuração profunda para uma thread lateral
• Encerre a ponte quando SEV1/SEV2 for mitigado; passe para acompanhamento para RCA

8. Passe para o Pós-Mortem

Quando resolvido:

[ ] Marque o incidente como resolvido no PagerDuty
[ ] Poste o resumo final para o cliente
[ ] Crie o documento de pós-mortem em até 48 horas (SEV1/SEV2)
[ ] Liste os itens de ação com responsáveis e datas de vencimento
[ ] Sem culpa - foque em sistemas e lacunas de processo

• Use o Modelo de Pós-Mortem para SEV1/SEV2
• Acompanhe os itens de ação no Jira/Linear com o rótulo incident-followup

FAQs

Relacionados

• Resposta ao OOM Killer - incidentes de memória
• Rollback de Deploy Ruim - rollback de deploy
• Modelo de Pós-Mortem - modelo de RCA
• Iniciadores de Runbook para Plantão - runbooks de serviço
• Melhores Práticas de Resposta a Incidentes - checklist condensado

Versões da Stack: Esta página foi escrita para Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, e NestJS 11.