Conceptos Básicos de Incidentes

8 ejemplos para gestionar tu primer incidente de Node.js con calma: 6 básicos y 2 intermedios. Cubre la severidad, la comunicación y la lista de verificación de los primeros 15 minutos.

Requisitos previos

• Rotación de guardia con PagerDuty/Opsgenie conectado a alertas SLO
• El README del servicio enlaza a los runbooks (consulta Iniciadores de Runbook de Guardia)
• Registros estructurados con requestId y traceId (consulta IDs de Correlación de Solicitudes)
• Paneles de control para latencia p95, tasa de error, RSS del heap y tiempo de espera del pool de DB

Ejemplos Básicos

1. Declara la Severidad en 5 Minutos

• SEV1 activa al Comandante de Incidente + actualización de la página de estado en 15 minutos
• Cuando tengas dudas, redondea hacia arriba: degradar es más fácil que subestimar la respuesta
• Documenta la severidad en el tema del canal de incidentes: [SEV2] orders-api alta latencia

Relacionado: Mejores Prácticas de Respuesta a Incidentes - lista de verificación completa del runbook

2. Asigna Roles de Incidente

Comandante de Incidente (IC) - posee las decisiones, el cronograma, la escalada
Líder Técnico (TL)        - impulsa la mitigación, lee registros/métricas
Líder de Comunicaciones   - página de estado, actualizaciones a las partes interesadas
Escriba                   - cronograma, comandos ejecutados, enlaces a gráficos

• El IC no depura solo, delega la investigación al TL
• El Escriba publica cada 10 minutos en #incident-orders-api
• Rota al IC si el incidente supera las 2 horas

3. Lista de Verificación de Node para los Primeros 15 Minutos

[ ] Reconoce la alerta; únete al puente / reunión de Slack
[ ] Confirma el radio de impacto (qué servicios, inquilinos, regiones)
[ ] Verifica el último despliegue (SHA de git, hora, quién)
[ ] Grafana: tasa de error, p95, reinicios de pods, recuento de OOMKilled
[ ] Registros: pico en 5xx, ECONNREFUSED, tiempo de espera del pool, ETIMEDOUT
[ ] Cambios recientes de configuración/secreto/bandera
[ ] Decide: rollback, escalar, desactivar feature-flag o investigar
[ ] Publica la primera actualización externa si es SEV1/SEV2

• No reinicies pods a ciegas antes de verificar la correlación del despliegue
• Captura kubectl get pods / estado de la tarea ECS antes de los cambios
• Guarda la instantánea del heap solo si la memoria es sospechosa y el tráfico está limitado

Relacionado: Respuesta al OOM Killer - triaje de memoria | Reversión de Despliegue Defectuoso - rutas de reversión

4. Estabiliza Antes de la Causa Raíz

La mitigación supera un diagnóstico perfecto en la primera hora.

• Registra cada acción de mitigación con marca de tiempo en el hilo del incidente
• Marca "estabilizado" cuando la tasa de error vuelve a estar por debajo del SLO durante 15 minutos
• El análisis de la causa raíz continúa después de que cesa el impacto en el cliente

5. Comunica en Lenguaje Sencillo

Mal: "El bucle de eventos se bloqueó debido a la saturación de libuv."

Bien: "El proceso de pago está fallando para aproximadamente el 30% de los usuarios. Desplegamos una solución a las 14:22 UTC y los errores están disminuyendo. Próxima actualización en 20 minutos."

Plantilla para actualizaciones a las partes interesadas:

**Impacto:** <quién está afectado, qué está roto>
**Estado:** Investigando | Mitigando | Monitoreando | Resuelto
**Acciones:** <lo que hicimos en los últimos 20 minutos>
**Próxima actualización:** <hora UTC>

• El PM y el soporte necesitan el impacto en el cliente, no volcados de heap
• Enlaza paneles de control internos solo en canales de ingeniería

6. Reúne Evidencia Específica de Node

# Memoria y reinicios de pods
kubectl top pods -n production -l app=orders-api
kubectl describe pod <pod> | grep -A5 "Last State"
 
# Despliegue reciente
kubectl rollout history deployment/orders-api -n production
 
# Registros con correlación
# filter: service=orders-api level=error last 30m

• Exporta gráficos de latencia p95 y tasa de error que cubran la ventana de despliegue
• Anota la versión de Node, el digest de la imagen y NODE_OPTIONS si está relacionado con la memoria
• Guarda los registros de consultas lentas si aparecen errores de DB en los rastreos de pila

Ejemplos Intermedios

7. Estructura de Llamada de Puente (Cadencia de 30 Minutos)

0:00  El IC declara la severidad, el impacto, la hipótesis actual
0:05  El TL comparte la última instantánea de métricas
0:10  Decisión: rollback / escalar / desactivar bandera / continuar depuración
0:15  El equipo de comunicaciones publica actualización externa
0:25  El escriba lee el cronograma; confirma los propietarios de las acciones
0:30  Repetir o degradar la severidad

• Limita los asistentes a 8; mueve la depuración profunda a un hilo secundario
• Termina el puente cuando SEV1/SEV2 esté mitigado; transfiere el seguimiento para el RCA

8. Entrega al Post-Mortem

Cuando se resuelva:

[ ] Marca el incidente como resuelto en PagerDuty
[ ] Publica el resumen final de cara al cliente
[ ] Crea el documento post-mortem en 48 horas (SEV1/SEV2)
[ ] Lista los elementos de acción con propietarios y fechas de vencimiento
[ ] Sin culpas: concéntrate en los sistemas y las brechas de proceso

• Usa la Plantilla de Post-Mortem para SEV1/SEV2
• Rastrea los elementos de acción en Jira/Linear con la etiqueta incident-followup

Preguntas Frecuentes

Relacionado

• Respuesta al OOM Killer - incidentes de memoria
• Reversión de Despliegue Defectuoso - reversión de despliegue
• Plantilla de Post-Mortem - plantilla de RCA
• Iniciadores de Runbook de Guardia - runbooks de servicio
• Mejores Prácticas de Respuesta a Incidentes - lista de verificación condensada

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS Activo), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.