🚨

Handbook 35 min lectura

Incidentes de performance:
cómo detectar, responder, documentar y evitar que vuelva a pasar

Cuando el p95 supera el SLA, el performance tester no es un observador — es el SME con los datos que acelera la resolución. Después de leer esto sabés exactamente qué hacer cuando aparece una degradación: en test, en staging o en producción.

Incident ManagementPerformance TestingPostmortemMTTRSREObservabilidad

Por Rodrigo Campos · 2026-03-19

Tabla de contenidos

1. ¿Qué es un incidente de performance?

La mayoría de los equipos asocia "incidente" con caída total del servicio. Pero desde el punto de vista del performance tester, un incidente ocurre mucho antes de que el sistema deje de responder.

Un incidente de performance es cualquier degradación que afecta, o tiene el potencial de afectar, la experiencia del usuario o los SLAs. No hace falta que el sitio esté caído. Basta con que el p95 triplique el umbral acordado, que la tasa de errores supere el 1%, o que el throughput caiga por debajo del mínimo operativo.

El ángulo del performance tester

Los performance testers suelen ser los primeros en detectar un incidente, no los últimos. Durante una prueba de carga podés identificar una degradación antes de que llegue a producción. Cada run de test es una oportunidad de cortar el problema antes de que afecte usuarios reales.

También es importante distinguir entre un bug y un incidente. Un bug es un defecto en el comportamiento del sistema. Un incidente es un evento con impacto activo o potencial en usuarios o en el negocio. Un bug puede no ser un incidente (si está en un flujo no crítico). Un incidente casi siempre implica uno o más bugs, pero la gestión es diferente: el incidente requiere respuesta coordinada, comunicación y postmortem.

Métrica	Estado normal	Estado de incidente
p95 latencia	≤ 500ms	> 1.5s sostenido
Tasa de errores	< 0.5%	> 2% por más de 5 min
Throughput	≥ 200 req/s	< 100 req/s sin causa justificada
p99 latencia	≤ 1.2s	> 5s sostenido
Timeouts	0 por ventana de 5 min	≥ 3 en ventana de 5 min

⚠️ Importante

Estos umbrales son ejemplos. Cada sistema tiene SLAs distintos. Lo crítico es que los umbrales estén definidos antes del incidente. Cuando algo falla no es el momento para debatir qué constituye un incidente.

2. El ciclo de vida

Todo incidente sigue un ciclo predecible. Conocerlo permite actuar más rápido y no perderse en ninguna fase.

Fase Impacto

Algo falla. Puede ser que un alert dispare, que un load test detecte latencias elevadas, o que un usuario reporte un error. Esta fase no tiene un actor claro todavía — lo importante es que alguien la detecte. El performance tester puede anticipar esta fase corriendo tests proactivamente antes de que llegue a producción.

Fase Incidente activo

El incidente se declara. Arranca la investigación coordinada. El performance tester tiene un rol central aquí: tiene los datos. Métricas de throughput, percentiles de latencia, comparativas con el baseline — todo eso alimenta la investigación y acelera la identificación de la causa raíz.

Fase Estabilización

Se aplica un fix inmediato — rollback, escalado horizontal, feature flag desactivado. El monitoreo confirma que las métricas volvieron a rangos normales. No es el momento de la solución definitiva; es el momento de restaurar el servicio. Se monitorea durante 15–30 minutos antes de declarar el incidente resuelto.

Fase Seguimiento

El incidente está cerrado pero el trabajo no termina. El postmortem documenta qué pasó, por qué y qué va a cambiar. Las acciones correctivas tienen dueño y fecha. Sin esta fase, el mismo incidente vuelve en 3 meses.

3. Clasificación y severidad

Las clasificaciones de severidad sirven para coordinar la respuesta: quién se convoca, con qué urgencia, qué comunicaciones salen. Sin un sistema de severidad acordado, cada incidente se trata como una emergencia máxima (o como un ticket normal), y ninguno de los dos extremos funciona.

La siguiente tabla adapta el modelo SEV-1 a SEV-5 con criterios específicos de performance:

Severidad	Nombre	Criterio de performance	Respuesta
SEV-1	Crítico	p95 > 10x SLA o error rate > 20% o servicio caído	Inmediata — todo el equipo, 24/7
SEV-2	Alto	p95 > 3x SLA o error rate > 5%	Respuesta en < 30 min, horario laboral extendido
SEV-3	Moderado	p95 > 2x SLA o error rate entre 1% y 5%	Respuesta en < 2 horas
SEV-4	Bajo	p95 levemente sobre SLA, sin errores 5xx	Próximo sprint, sin urgencia
SEV-5	Informativo	Degradación detectada en test, no en producción	Backlog, monitorear en próximo deploy

💡 Punto clave

El SEV-5 es exclusivo del performance tester: detección en ambiente de prueba antes de que llegue a producción. Cada SEV-5 bien documentado es un SEV-1 evitado. Ese es el valor directo del testing proactivo.

4. Roles de respuesta

Un incidente bien manejado no depende de que alguien sea héroe. Depende de que los roles estén claros y cubiertos desde el primer minuto.

Incident Commander

Coordina toda la respuesta. Decide las prioridades. Asigna tareas. No hace trabajo técnico durante el incidente — su foco es orquestar. Declara el incidente resuelto.

Scribe

Documenta el timeline en tiempo real: qué se hizo, cuándo, quién. Esta documentación es la materia prima del postmortem. Sin un Scribe, el postmortem se reconstruye de memoria y pierde precisión.

Customer Liaison

Gestiona la comunicación externa: actualizaciones en el status page, respuestas a clientes afectados. Evita que el equipo técnico sea interrumpido con preguntas de estado mientras investigan.

SME — Performance Tester

Aporta los datos: métricas de latencia, throughput, error rate. Identifica qué endpoints están degradados. Compara el estado actual con el baseline. Genera hipótesis de causa raíz basadas en evidencia.

5. Detección desde performance testing

El performance tester detecta incidentes por vías distintas según el momento. Cuál aplica determina qué tan rápido llegás a declarar el incidente.

1. Detección proactiva — load tests antes de producción

Corrés un test de carga en staging y los resultados muestran que el p95 superó el SLA bajo 200 usuarios concurrentes. Producción todavía no vio ese tráfico, pero lo va a ver. Un SEV-4 o SEV-5 en staging evita un SEV-1 en producción. Este canal es el más valioso y el menos aprovechado.

2. Detección reactiva — alertas de monitoreo en producción

Las alertas configuradas en el sistema de monitoreo disparan cuando las métricas superan los umbrales. El performance tester puede haber definido esos umbrales y sabe interpretarlos. Cuando entra al canal de incidentes, ya tiene contexto sobre qué significa "p95 > 2s en checkout".

3. Detección por regresión — comparativa con baseline

El deploy 3.1.0 acaba de salir. Comparás los resultados de performance del build anterior con los del actual y encontrás que el endpoint /api/orders degradó un 40% en p95. No hay alerta todavía porque el umbral absoluto no se superó, pero la tendencia es clara. Esto justifica un SEV-4 o SEV-3 dependiendo del endpoint.

¿Abrís un incidente o un ticket?

¿El problema afecta usuarios reales ahora mismo?

├── Sí → Declarar incidente (mínimo SEV-3)

└── No → Continuar evaluación

¿El problema afectará usuarios si no se actúa en < 1h?

├── Sí → Declarar incidente (SEV-3 o SEV-4)

└── No → Continuar evaluación

¿La degradación supera el 20% del baseline en un endpoint crítico?

├── Sí → Declarar incidente SEV-4 o SEV-5

└── No → Abrir ticket en backlog, monitorear

6. Cómo se gestiona

Una vez declarado el incidente, hay seis pasos. El orden importa. Saltear pasos —especialmente la verificación— es una de las causas más comunes de reapertura de incidentes.

Declarar

Cualquier persona puede declarar un incidente. No esperés hasta estar seguro. Si tenés dudas entre SEV-2 y SEV-3, declarás SEV-2 y reclasificás hacia abajo si la investigación lo confirma. Al revés no funciona: si esperás certeza para declarar, perdés tiempo crítico.

Comunicar

Notificás al IC. Abrís el canal de incidente con un nombre estándar (#inc-2026-03-19-checkout). Actualizás el status page con el estado inicial. Esta comunicación temprana evita que otras personas pierdan tiempo reportando el mismo problema o interrumpiendo al equipo que investiga.

Investigar

El performance tester lidera esta fase con datos. ¿Cuándo empezó la degradación? ¿Qué endpoints están afectados? ¿Hay correlación con el último deploy? ¿La degradación es uniforme o afecta solo ciertas regiones/usuarios? El objetivo no es encontrar la causa raíz definitiva — es encontrar suficiente evidencia para mitigar.

Mitigar

Aplicás el fix inmediato. En performance, las opciones más comunes son: rollback al build anterior, escalado horizontal de la instancia afectada, o desactivación de la feature problemática via feature flag. Estabilidad primero, causa raíz después. No es el momento de aplicar el fix correcto definitivo si hay uno rápido disponible.

Verificar

Confirmás que las métricas volvieron a rangos normales. Monitoreás durante 15–30 minutos antes de declarar el incidente estable. Un incidente que se declara resuelto prematuramente y reabre 10 minutos después daña la confianza del equipo en el proceso.

Cerrar

El IC declara el incidente resuelto. Se asigna el dueño del postmortem con fecha límite. Se actualiza el status page con la resolución final. El canal de incidente se archiva pero no se borra — es historia operacional.

7. Cultura de incidentes

El proceso técnico puede estar bien diseñado y aun así fallar si la cultura no lo acompaña. Sin estos principios, el mismo incidente vuelve.

🤝

Sin culpa (Blameless)

Los incidentes no ocurren porque alguien fue descuidado. Ocurren porque los sistemas complejos tienen interacciones impredecibles. La pregunta del postmortem no es "¿quién lo rompió?" sino "¿qué condiciones permitieron que esto pasara?". Cuando los equipos tienen miedo al castigo, ocultan información durante la investigación. Eso mata la capacidad de aprender.

🎯

Ownership

El equipo que construyó el sistema es el responsable de mantenerlo operativo. Estar on-call no es un castigo — es parte del trabajo de un equipo que tiene orgullo de lo que construye. Equipos con ownership responden más rápido porque conocen el sistema mejor que nadie.

🚩

Declarar temprano

Es mejor reclasificar un SEV-2 a SEV-3 después de 20 minutos de investigación que dejar pasar 30 minutos tratando de confirmar si realmente es un incidente. El costo de declarar un falso positivo es bajo. El costo de no declarar un incidente real es alto.

💡 Para performance testers específicamente

Si un load test rompe algo en staging, declararlo como incidente (SEV-4 o SEV-5) aunque nadie más lo sepa. El equipo necesita practicar el proceso en entornos de bajo riesgo. Cuando llegue el SEV-1 real, la coordinación ya tiene músculo.

8. Métricas: MTTD, MTTA, MTTR

Son el lenguaje estándar para medir qué tan bien responde tu equipo. Sin medirlas, no podés mejorar.

MTTD

Mean Time To Detect

Tiempo promedio entre que el incidente empieza y que alguien lo detecta. El performance testing proactivo reduce el MTTD drásticamente: encontrás el problema en staging antes de que llegue a producción. Sin testing proactivo, el MTTD depende de que un usuario reporte el error o de que la alerta dispare.

MTTA

Mean Time To Acknowledge

Tiempo entre que se detecta y que alguien empieza a trabajar activamente en el problema. Depende de la claridad del proceso de escalado y on-call. Si las alertas son ambiguas o el proceso de notificación está roto, el MTTA sube. La fatiga de alertas (demasiados falsos positivos) también aumenta el MTTA con el tiempo.

MTTR

Mean Time To Resolve

El KPI principal. Tiempo total desde que el incidente empieza hasta que se resuelve. Se reduce con mejores runbooks, postmortems bien ejecutados que generan acciones reales y procesos que se practican regularmente. Un equipo que nunca simuló un incidente va a tener un MTTR mucho más alto que uno que lo practica.

Objetivos por nivel de madurez

Madurez	MTTD target	MTTA target	MTTR target
Inicial (no hay proceso formal)	> 60 min	> 30 min	> 4 horas
En desarrollo (proceso documentado)	15–60 min	10–30 min	1–4 horas
Maduro (proceso practicado)	5–15 min	3–10 min	30 min–1 hora
Avanzado (testing proactivo + automatización)	< 5 min	< 3 min	< 30 min

💡 Recurrence Rate y False Alarm Rate

Dos métricas adicionales: Recurrence Rate — incidentes que vuelven a ocurrir — indica que las acciones del postmortem no se ejecutaron o que la causa raíz no se identificó bien. False Alarm Rate — alertas que no corresponden a incidentes reales — genera fatiga y aumenta el MTTA gradualmente porque el equipo empieza a ignorar las alertas.

9. El Postmortem

El postmortem convierte un incidente en conocimiento del equipo. Sin él, cada uno reconstruye lo que pasó de memoria y los errores se repiten. Quien entre después no tiene forma de entender qué falló ni por qué.

Todo SEV-1 y SEV-2 necesita postmortem. Muchos equipos también lo hacen para SEV-3. La regla es simple: si el incidente fue suficientemente importante para coordinar una respuesta, fue suficientemente importante para documentar los aprendizajes.

1. Resumen ejecutivo

Máximo 3 oraciones. Qué pasó, cuánto duró, cuál fue el impacto. Tiene que ser legible para alguien que no estuvo en el incidente.

2. Cronología

Timeline con timestamps. Desde la primera señal hasta la resolución. El Scribe la construye durante el incidente — el postmortem la formaliza.

3. Análisis de causa raíz (5 WHYs)

Aplicar la técnica de los 5 WHYs hasta llegar a la causa sistémica. La mayoría de los incidentes tienen múltiples factores contribuyentes, no una causa única.

4. Acciones correctivas

Sin acciones correctivas asignadas y con fecha, el postmortem es un documento decorativo. Cada acción necesita responsable, descripción específica y fecha límite.

Ejemplo de postmortem

POSTMORTEM IR-001: Degradación checkout — 2026-03-15

SEV-2 · CERRADO

RESUMEN: El endpoint /api/checkout degradó p95 a 4.2s (SLA: 800ms) durante
2h 15min afectando ~12% de las transacciones. Causa: query N+1 en
el módulo de descuentos tras el deploy 2.4.1.

CRONOLOGÍA:
14:22 — Deploy 2.4.1 completado
14:35 — Alertas p95 superando 1.5s
14:41 — Incidente SEV-2 declarado por @rcampos
14:55 — Performance tester identifica /api/checkout como endpoint principal
15:10 — Causa raíz identificada: query N+1 en módulo descuentos
15:18 — Decision: rollback a 2.4.0 (fix rápido disponible)
16:15 — Rollback completado
16:37 — Métricas normalizadas, incidente cerrado

CAUSA RAÍZ (5 WHYs):
¿Por qué degradó /api/checkout?  → El ORM generaba N queries por usuario
¿Por qué pasó a producción?      → No había test de performance en el pipeline para ese endpoint
¿Por qué no había test?          → Los datos de prueba en CI no tenían suficientes descuentos por usuario
¿Por qué no?                     → El módulo de descuentos era nuevo y no se incluyó en los fixtures
¿Por qué no se detectó en code review? → No había criterios de performance en el checklist de PR

FACTORES CONTRIBUYENTES:
- Falta de test de performance para /api/checkout en CI
- Datos de prueba no representativos para el módulo de descuentos
- Sin criterios de performance definidos en el proceso de PR review

ACCIONES CORRECTIVAS:
→ Agregar test de performance para /api/checkout en pipeline CI
   Responsable: @dev-team | Fecha límite: 2026-03-22

→ Implementar query optimization con índices en módulo descuentos
   Responsable: @backend | Fecha límite: 2026-03-29

→ Revisar todos los endpoints de checkout con EXPLAIN ANALYZE
   Responsable: @dba | Fecha límite: 2026-03-25

→ Agregar criterios de performance al checklist de PR review
   Responsable: @tech-lead | Fecha límite: 2026-03-22

10. IA como apoyo en el ciclo

Un asistente de IA como Claude Code puede acelerar varias fases del ciclo. No reemplaza el criterio del performance tester: procesa datos más rápido y ayuda a generar documentación, pero las decisiones siguen siendo tuyas.

Flujo: Performance Test → Detección → Incidente

DETECCIÓN

Claude analiza resultados de test

• Recibe output de k6 o Gatling y detecta qué métricas superan los SLAs definidos
• Compara el run actual con el baseline histórico e identifica regresiones
• Sugiere el nivel de severidad con justificación basada en los datos

INVESTIGACIÓN

Claude procesa logs y genera hipótesis

• Ordena los logs cronológicamente e identifica el primer error registrado
• Lista los endpoints más afectados con frecuencia de error
• Genera hipótesis de causa raíz ordenadas por probabilidad

COMUNICACIÓN

Claude genera updates de estado

• Traduce datos técnicos a lenguaje que entiende el equipo de negocio
• Genera actualizaciones de status page desde el contexto del incidente
• Redacta comunicaciones a clientes afectados con tono apropiado

POSTMORTEM

Claude genera el documento completo

• Genera el postmortem estructurado a partir de las notas del Scribe
• Extrae acciones correctivas de los logs de la investigación
• Aplica la técnica de 5 WHYs a la causa raíz identificada
• Produce el resumen ejecutivo a partir del documento técnico completo

11. Prompts listos para usar

Estos prompts están diseñados para usarlos directamente con cualquier asistente de IA. Reemplazá los campos entre corchetes con los datos reales del incidente. Cuanto más contexto incluyas, más preciso va a ser el análisis.

PROMPT 1

Detectar si hay incidente desde resultados de test

Analizá estos resultados de performance test:
[pegá output de k6/Gatling]

SLAs definidos:
- p95 < 500ms
- error rate < 1%
- throughput mínimo: 100 req/s

¿Hay alguna métrica que justifique declarar un incidente?
Si sí: sugerí el nivel de severidad (SEV-1 a SEV-5) con justificación.
Si no: indicá qué endpoints están en zona de riesgo aunque no sea incidente aún.

PROMPT 2

Analizar logs durante el incidente

Tengo estos logs del incidente activo:
[pegá los logs]

Necesito:
1. Ordenarlos cronológicamente
2. Identificar el primer error registrado
3. Listar los top 3 endpoints afectados con su frecuencia de error
4. Sugerir las 3 hipótesis más probables de causa raíz

Sé conciso — estamos en medio de un incidente.

PROMPT 3

Generar update de status para stakeholders

Incidente activo:
- Severidad: SEV-2
- Servicio afectado: [nombre]
- Inicio: [hora]
- Estado actual: investigando
- Último hallazgo: [descripción técnica]

Generá una actualización de estado para enviar al equipo de negocio.
Máximo 4 oraciones. Sin jerga técnica. Incluí: qué está afectado, cuánto tiempo
lleva, cuándo es el próximo update.

PROMPT 4

Generar postmortem completo

Con base en estos datos del incidente resuelto:

Duración: [inicio] → [fin]
Severidad: SEV-[X]
Servicio: [nombre]
Causa raíz: [descripción]
Timeline de eventos: [pegar cronología]
Acciones tomadas: [pegar]

Generá el postmortem completo con:
1. Resumen ejecutivo (máx 3 oraciones)
2. Cronología formateada con timestamps
3. Análisis de causa raíz con técnica 5 WHYs
4. Factores contribuyentes
5. Acciones correctivas (con responsable y fecha límite sugerida)

PROMPT 5

Comparar métricas con baseline

Tengo estas métricas de los últimos 3 runs de performance test:

Run anterior (baseline): [métricas]
Run actual: [métricas]

¿Hay regresión?
Si hay endpoints con degradación > 20% respecto al baseline, listalos con:
- Porcentaje de degradación
- Posible relación con cambios recientes
- Recomendación: ticket, incidente o solo monitorear

💡 Consejo para mejores resultados

Los asistentes de IA funcionan mejor con datos específicos. Cuanto más contexto incluyas (métricas reales, logs, descripción del sistema), más preciso va a ser el análisis. Los prompts de arriba son estructuras base — adaptales a tu stack y al tipo de incidente.

Volver a Learning