Flujo de Trabajo de Respuesta a Incidentes

Los incidentes ocurren. Lo que importa es cómo respondes. Una buena respuesta a incidentes minimiza impacto al cliente, reduce estrés y crea oportunidades de aprendizaje. Una respuesta pobre extiende outages y quema a los equipos. Esta guía cubre flujos de trabajo prácticos de respuesta a incidentes.

Fases de Incidentes

Niveles de Severidad

Clasificación

SEVERIDAD DE INCIDENTES
═══════════════════════

P1 - CRÍTICO:
─────────────────────────────────────
Impacto:
├── Outage completo del servicio
├── Feature mayor completamente caída
├── Breach de seguridad
├── Pérdida/corrupción de datos
├── Todos los clientes afectados
└── Crítico para el negocio

Respuesta:
├── Todas las manos a la obra
├── Escalamiento inmediato
├── C-level informado
├── Comunicación externa
├── Dejar todo
└── Hasta que se resuelva

P2 - ALTO:
─────────────────────────────────────
Impacto:
├── Feature significativa afectada
├── Workaround puede existir
├── Muchos clientes afectados
├── Servicio degradado
└── Inconveniente mayor

Respuesta:
├── Responders dedicados
├── Manager informado
├── Soporte al cliente al tanto
├── Fix de alta prioridad
└── Resolver en horas

P3 - MEDIO:
─────────────────────────────────────
Impacto:
├── Feature menor afectada
├── Impacto limitado a clientes
├── Workaround disponible
├── Experiencia degradada
└── Inconveniente, no crítico

Respuesta:
├── Prioridad normal
├── Resolver en días
├── Sin escalamiento necesario
├── Proceso estándar
└── Fix programado

P4 - BAJO:
─────────────────────────────────────
Impacto:
├── Issues cosméticos
├── Impacto mínimo
├── Pocos clientes notan
└── Molestia menor

Respuesta:
├── Prioridad de backlog
├── Arreglar cuando convenga
├── Proceso regular
└── Sin urgencia

Proceso de Respuesta

Respuesta Estructurada

FLUJO DE TRABAJO DE RESPUESTA A INCIDENTES
══════════════════════════════════════════

DETECCIÓN:
─────────────────────────────────────
Cómo se detectan incidentes:
├── Alertas de monitoreo automatizadas
├── Reportes de clientes
├── Reportes internos
├── Monitoreo sintético
├── Picos de tasa de error
└── Múltiples señales

TRIAGE:
─────────────────────────────────────
Primeros 5 minutos:
├── ¿Qué está roto?
├── ¿Quién está afectado?
├── ¿Cuál es la severidad?
├── ¿Quién necesita saber?
├── Evaluación rápida
└── No debugear—hacer triage

ENSAMBLAR EQUIPO:
─────────────────────────────────────
Basado en severidad:
├── Incident commander (lidera respuesta)
├── Responders técnicos
├── Lead de comunicaciones
├── Expertos en la materia
├── Roles claros
└── No todos—las personas correctas

INVESTIGAR:
─────────────────────────────────────
Encontrar la causa:
├── Revisar cambios recientes
├── Revisar logs y métricas
├── Comparar con baseline saludable
├── Formar hipótesis
├── Probar hipótesis
└── Encontrar causa raíz

MITIGAR:
─────────────────────────────────────
Prioridad: Restaurar servicio
├── Rollback si relacionado a deploy
├── Deshabilitar feature flag
├── Escalar recursos
├── Redirigir tráfico
├── Fix temporal está OK
├── Fix permanente después
└── Cliente primero

RESOLVER:
─────────────────────────────────────
Servicio restaurado:
├── Verificar todos los sistemas saludables
├── Monitorear recurrencia
├── Comunicar resolución
├── Documentar qué pasó
├── Programar post-mortem
└── Incidente cerrado

Comunicación

Updates a Stakeholders

COMUNICACIÓN DE INCIDENTES
══════════════════════════

COMUNICACIÓN INTERNA:
─────────────────────────────────────
Canal de Slack del incidente:
├── Crear canal: #inc-2024-01-15-api-outage
├── Postear updates regulares
├── Taguear personas relevantes
├── Timeline de eventos
├── Acciones siendo tomadas
├── Única fuente de verdad
└── No dispersar información

Cadencia de updates:
├── Cada 15 min para P1
├── Cada 30 min para P2
├── Según necesidad para P3/P4
├── Más frecuente es mejor
└── Stakeholders informados

COMUNICACIÓN EXTERNA:
─────────────────────────────────────
Status page:
├── Acknowledge incidente
├── Descripción (no técnica)
├── Resolución estimada
├── Updates según progreso
├── Anuncio de resolución
├── Transparente con clientes

Plantilla:
"Actualmente estamos experimentando issues
con [servicio]. Estamos investigando
y proporcionaremos updates.

Impacto: [qué experimentan usuarios]
Inicio: [hora]
Status: Investigando

Última actualización: [hora]
Próximo update en: [duración]"

UPDATES A STAKEHOLDERS:
─────────────────────────────────────
Updates a liderazgo:
├── Resumen de impacto
├── Impacto a clientes
├── Impacto a negocio
├── ETA si se conoce
├── Qué estamos haciendo
├── Resumen ejecutivo
└── No simplificar de más

On-Call

Preparación para Respuesta

ESTRUCTURA DE ON-CALL
═════════════════════

ROTACIÓN:
─────────────────────────────────────
Configuración típica:
├── On-call primario
├── Backup secundario
├── Rotación semanal
├── Distribución justa
├── Sin punto único de falla
└── Schedule documentado

EXPECTATIVAS:
─────────────────────────────────────
Persona on-call:
├── Responder a alertas en 15 min
├── Acceso a laptop e internet
├── Disponible durante horario
├── Escalar si es necesario
├── No ser héroe—pedir ayuda
└── Expectativas claras

COMPENSACIÓN:
─────────────────────────────────────
On-call justo:
├── Pago extra o tiempo libre
├── Respetar horario fuera de trabajo
├── No quemar a la gente
├── Rotar justamente
├── Reconocer la carga
└── Sistema sostenible

RUNBOOKS:
─────────────────────────────────────
Procedimientos documentados:
├── Incidentes comunes
├── Fixes paso a paso
├── Rutas de escalamiento
├── Información de contacto

Mejores Prácticas

1. Triage rápido evaluar severidad inmediatamente
2. Roles claros IC, técnico, comunicaciones, scribe
3. Updates frecuentes cada 15-30 min durante incidentes activos
4. Restaurar primero fix permanente después
5. Documentar en tiempo real para post-mortem preciso
6. Post-mortem sin culpa enfocarse en sistemas

Soluciones Relacionadas

• Gestión de Incidentes con GitScrum
• Respuesta a Incidentes y Post-mortems
• Respuesta a Incidentes para Equipos