Describe tu peor incidente de producción y los primeros 30 minutos.

Question

IT Interview Practice · Accepted Answer

**Una buena respuesta muestra cómo redujiste daño, decidiste con pruebas incompletas y evitaste recurrencias.** Explica tu papel sin atribuirte todo el trabajo del equipo.

Usa un incidente real. El siguiente es ficticio y muestra estructura; sustitúyelo por acciones y resultados verificados. Los tiempos son ilustrativos, no plazos universales.

## 1. Establece situación y responsabilidad

Supongamos que era backend lead de guardia cuando subieron los fallos de checkout tras un release. Se podía navegar, pero algunos no completaban pedidos. La proximidad temporal era una hipótesis, no una causa demostrada.

Explicaría mi responsabilidad: coordinar recuperación técnica, repartir investigación e informar al responsable del incidente. Si también dirigía el incidente, lo diría y delegaría comunicación o investigación directa para no bloquear al equipo.

## 2. Primeros cinco minutos: confirmar y organizar

Revisa errores, latencia y pedidos exitosos para saber afectados y continuidad. Abre un canal único, asigna roles, pausa cambios ajenos y registra observaciones y acciones.

La razón es práctica: cambios independientes pueden ocultar la causa o empeorar el problema. Las actualizaciones separan hechos de hipótesis y fijan la siguiente comunicación. Véase [respuesta a incidentes de Google](https://sre.google/workbook/incident-response/).

## 3. Siguientes diez minutos: aliviar con seguridad

Supón conexiones agotadas y un nuevo informe costoso. Compararía rollback con desactivar temporalmente ese camino preservando checkout.

- Comprueba compatibilidad del rollback con cambios de esquema y datos ya aplicados. La versión anterior no es automáticamente segura.
- Si un interruptor probado desactiva informes opcionales, úsalo y observa checkout.
- Asigna a alguien las conexiones y a otro verificar recuperación para seguir investigando sin retrasar una mitigación razonable.

Decide con evidencia y reversibilidad. No esperaría certeza total mientras los clientes están bloqueados, pero registraría por qué debía ayudar la acción.

## 4. Hasta treinta minutos: verificar servicio útil

Bajar CPU no basta. Confirma compras reales, latencia aceptable y reducción de cola sin nueva presión. Observa después de mitigar, no declares recuperación por una sola petición.

Con pagos inciertos, concilia antes de cobrar otra vez: un timeout puede esconder un cobro completado. Comunica qué volvió, qué falta saber y qué hacer, sin inventar una hora de recuperación.

## 5. Después: cambia las condiciones del fallo

En este ejemplo, investigación podría revelar conexiones compartidas y reportes sin límite efectivo. El seguimiento debe corregir ese mecanismo, no terminar en «tener más cuidado».

- Limita trabajo y concurrencia de informes para no consumir todo el recurso compartido.
- Evalúa aislamiento y prueba informes junto con checkout bajo carga representativa.
- Alerta sobre éxito y latencia del checkout y ensaya mitigación o rollback.
- Da a cada corrección un responsable, fecha y verificación de cierre.

En una entrevista real, cierra con resultados y evidencias de pruebas o operación posterior. Si no mediste algo, dilo en lugar de inventar números. La lección debe conectarse con una mejora que ayudaste a entregar y verificar.

1. Establece situación y responsabilidad

2. Primeros cinco minutos: confirmar y organizar

3. Siguientes diez minutos: aliviar con seguridad

4. Hasta treinta minutos: verificar servicio útil

5. Después: cambia las condiciones del fallo

Preguntas relacionadas