Consigna y alcance
Cuéntame sobre un incidente del que fuiste responsable en producción. Más allá de la solución, explica cómo confirmaste el impacto, definiste la severidad y los roles, te comunicaste con las partes interesadas, validaste la recuperación y convertiste la experiencia en mejoras.
ISO/IEC/IEEE 23612:2026 define un proceso genérico de gestión de incidentes y documentación de respaldo para sistemas, servicios, software y productos a lo largo de sus ciclos de vida. La pregunta no requiere memorizar cláusulas; evalúa si puedes situar tu contribución individual dentro de un ciclo de incidentes colaborativo, verificable y auditable.
Qué evalúa el entrevistador
El entrevistador busca hechos detrás del impacto y las decisiones, un manejo sereno de roles y cronogramas, una clara separación entre restaurar el servicio y encontrar la causa raíz, y acciones de seguimiento con responsables y fechas. Una respuesta sólida protege a las personas y evita convertir una retrospectiva en una narrativa de culpables.
Preguntas para clarificar antes de responder
- ¿Cuál fue la ventana de tiempo, el impacto en usuarios, el objetivo de servicio y la prioridad de negocio?
- ¿Fuiste comandante de incidentes, líder técnico, coordinador de comunicaciones u otro rol?
- ¿Qué evidencias, incógnitas y riesgos irreversibles existían en ese momento?
- ¿Qué partes interesadas necesitaban qué nivel de actualización y cuándo?
- ¿Quién fue responsable de la recuperación, el análisis de causa raíz y la prevención, y cómo se verificó su cumplimiento?
Marco de respuesta en 30 segundos
“Respondería con contexto, tarea, acción, resultado y retrospectiva. Expondría el tiempo, el impacto y las señales medibles, luego explicaría mi rol, la severidad, las asignaciones y la fuente única de verdad. Durante la respuesta, reduciría primero el impacto en el usuario y actualizaría a los equipos de negocio y soporte con una cadencia fija; tras la recuperación, validaría el monitoreo, los datos y los flujos de usuario. Finalmente, separaría los detonantes de las condiciones sistémicas, asignaría a cada mejora un responsable, fecha y métrica de verificación, y explicaría cómo hice el seguimiento.”
Respuesta profunda paso a paso
1. Elige un incidente real y verificable
Elige un incidente en el que realmente hayas participado con un impacto concreto. No inventes una historia en la que solucionaste todo tú solo. Prepara el cronograma, los usuarios afectados o la proporción de solicitudes, la señal de detección, el tiempo de recuperación y el resultado final; elimina nombres de clientes y credenciales mientras mantienes los hechos que respaldan tus decisiones.
2. Explica la severidad y los roles
Describe cómo el impacto, la duración, el riesgo de datos y la prioridad de negocio determinaron la severidad. Nombra los roles de comando de incidentes, investigación técnica, operaciones, comunicaciones y redactor de notas; si un equipo pequeño combinó roles, explica cómo se confirmaron igualmente las decisiones. La severidad no es una etiqueta; define la velocidad de respuesta, la autoridad y el alcance de la comunicación.
3. Describe una respuesta guiada por evidencia
Crea un único cronograma y lista de hipótesis, separando evidencia conocida, desconocida y pendiente. Da prioridad a acciones reversibles como rate limiting, rollback o failover; establece la señal esperada y la condición de parada para cada una. No incorpores retroactivamente la causa raíz final en las decisiones tomadas en ese momento; explica por qué ese camino era razonable con la evidencia disponible entonces.
impact -> severity -> roles -> reversible mitigation
-> evidence update -> recovery validation -> follow-up owner4. Diseña una comunicación en capas
Comunica a los usuarios y dueños de negocio el impacto, la mitigación actual y la hora de la próxima actualización sin afirmar una causa raíz no confirmada. Proporciona a los ingenieros registros, hipótesis, riesgos y solicitudes; entrega a soporte un libreto de usuario procesable. Mantén una cadencia fija e informa qué permanece bajo validación incluso cuando no haya una nueva conclusión.
5. Valida la recuperación, no solo un panel en verde
Revisa la tasa de errores, latencia, transacciones críticas de negocio, integridad de datos, acumulación en colas y la salud de dependencias tras la recuperación. Haz que un ingeniero de guardia y un representante de negocio confirmen el flujo de usuario y conserven evidencia de antes y después. Continúa durante una ventana completa de observación si las métricas mejoran solo brevemente.
6. Convierte la retrospectiva en mejora del sistema
Separa detonante, condiciones amplificadoras, brechas de detección y brechas de respuesta en lugar de escribir únicamente “alguien cometió un error”. Cada acción necesita un responsable, fecha límite, prioridad y evidencia de finalización, como una nueva alerta, simulacro de rollback, verificación de permisos o runbook. Vuelve a revisar las acciones en el siguiente simulacro o incidente similar para probar si el riesgo realmente disminuyó.
Respuesta de ejemplo de alta calidad
Elegiría un incidente real cuyo impacto y cronograma pueda explicar. Indicaría el impacto en el usuario, la duración y mi rol técnico o de comando de incidentes, luego mostraría cómo el impacto y el riesgo de datos definieron la severidad, cómo establecimos una fuente única de verdad y cómo asignamos la investigación y la comunicación. Primero utilizamos medidas reversibles de rate limiting o rollback, registramos hipótesis, evidencias y condiciones de parada, y actualizamos a los equipos de negocio, soporte e ingeniería con una cadencia fija. Tras la recuperación, validé transacciones críticas, integridad de datos, colas, dependencias y el flujo de usuario con un representante de negocio. En la retrospectiva separé detonante, condiciones amplificadoras, brechas de detección y de respuesta, y asigné responsables, fechas y métricas de verificación. Esto coincide con el enfoque de gestión de incidentes a lo largo del ciclo de vida de ISO/IEC/IEEE 23612:2026, preservando al mismo tiempo el límite de información y el principio de no culpabilidad en ese momento.
Errores comunes
- Describir únicamente comandos técnicos → la colaboración y las decisiones desaparecen → añade impacto, roles, comunicación y validación.
- Presentar la causa raíz final como conocida en ese momento → la historia se vuelve inexacta → separa la evidencia contemporánea del análisis retrospectivo.
- Equiparar la recuperación con un panel en verde → los datos o transacciones críticas aún pueden fallar → valida flujos, integridad y una ventana de observación.
- Culpar a una sola persona en la retrospectiva → las condiciones sistémicas permanecen → identifica brechas de detección, permisos, procesos y diseño.
- Listar acciones sin responsables ni verificación → la lista se vuelve una expresión de deseos → indica responsable, fecha, prioridad y evidencia.
Preguntas de seguimiento y respuestas
¿Cómo respondes si el monitoreo era incompleto?
Expón las incógnitas, reconstruye el impacto a partir de registros, tickets de soporte, registros de despliegue y datos del negocio, y convierte la brecha de observabilidad en una acción con un responsable y una métrica de aceptación.
¿Cuándo deberías hacer un rollback en lugar de continuar diagnosticando?
Cuando el impacto se está expandiendo, probar hipótesis resulta costoso y existe un rollback seguro. Restaura el servicio primero, luego analiza la causa de forma aislada mientras registras el riesgo de rollback y su validación.
¿Cómo manejas a un dueño de negocio que pide actualizaciones cada cinco minutos sin que haya un nuevo resultado?
Acuerda una cadencia fija e informa el impacto, las hipótesis que se están probando, las acciones completadas y el próximo punto de control. Comunica las incógnitas actuales en lugar de inventar progresos.
¿Cómo demuestras que las acciones de la retrospectiva funcionaron?
Define métricas como tiempo de detección, duración del rollback, tasa de aprobación en simulacros o error budget, y luego compara la línea base en simulacros e incidentes posteriores.
¿Cómo evitas que una retrospectiva se convierta en una reunión de culpables?
Enfócate en los sistemas y el contexto de las decisiones, utiliza un lenguaje sin culpas y protege la información confidencial. Maneja los asuntos separados de cumplimiento o rendimiento a través de su propio proceso en lugar de mezclarlos en la revisión técnica.