Planteamiento y contexto
Durante un incidente en producción, el ingeniero de guardia desea una respuesta de alta gravedad mientras que el product owner ve un impacto limitado. No cuentas con datos completos, pero retrasar la escalación podría expandir el radio de impacto (blast radius). Explica cómo avanzas, cómo comunicas el impacto a los usuarios y cómo mejoras el proceso de definición de gravedad después del incidente.
Qué evalúa el entrevistador
- Proteger a los usuarios ante la incertidumbre antes de discutir culpas o responsabilidades.
- Reemplazar la jerarquía o el volumen de la voz por señales observables y umbrales de escalación.
- Convertir el desacuerdo en registros, acciones y mejoras de procesos.
Preguntas para aclarar primero
- ¿Qué impacto, usuarios y rutas críticas están confirmados en este momento?
- ¿Qué establecen las reglas actuales de gravedad, autoridad de guardia y tiempos de escalación?
- ¿Existen métricas retrasadas, brechas de observabilidad o señales de negocio por verificar?
Una respuesta de 30 segundos
Pondría los hechos conocidos, las incógnitas y el peor escenario de riesgo en una sola línea de tiempo; luego propondría una acción de protección breve y acotada en el tiempo (time-boxed) junto con un umbral de escalación. Si el riesgo para el usuario o de reversión (rollback) es alto, iniciaría la respuesta de mayor gravedad y la registraría como una decisión de protección reversible. Asignaría un coordinador, definiría una cadencia de actualizaciones y mantendría un registro de decisiones. Tras la recuperación, una revisión sin culpas examinaría las señales, las reglas de gravedad y el cumplimiento de acciones en lugar de atribuir el desacuerdo a una persona.
Análisis detallado paso a paso
1. Establecer hechos compartidos
Enumera alertas, despliegues, tasas de error, reportes de usuarios y acciones con marcas de tiempo. Separa claramente las observaciones de las hipótesis. No trates el "parece grave" como evidencia, pero no esperes a tener datos perfectos antes de proteger a los usuarios.
2. Tomar una decisión de riesgo temporal
Escribe las condiciones de escalación como señales observables: errores sostenidos en una ruta crítica, un conjunto de tenants en expansión, integridad de datos incierta o una ventana de reversión que se reduce. En caso de desacuerdo, comienza en el nivel más alto si es necesario, establece un punto de revisión de diez minutos o menos y haz explícita la reducción de gravedad (downgrade).
3. Aclarar roles y cadencia
Asigna un líder de incidente, un responsable técnico, un redactor de notas (scribe) y un responsable de comunicaciones. Dirige las demás actualizaciones a un solo canal o ticket y publica el estado interno con una cadencia fija. Las actualizaciones externas deben indicar el impacto confirmado, la mitigación y la hora de la próxima actualización, no suposiciones sobre la causa raíz.
4. Ofrecer opciones comparables al área de producto
Explica el costo de la escalación, el riesgo de esperar y el detonante para cambiar de rumbo en lugar de debatir quién entiende mejor los incidentes. Las opciones pueden incluir pausar lanzamientos riesgosos, habilitar el modo de solo lectura o realizar una reversión, cada una con un responsable y una fecha límite.
5. Registrar el desacuerdo mientras se actúa
El registro de decisiones captura la evidencia, el desacuerdo, la acción elegida y la hora de revisión. Esto permite que la retrospectiva evalúe la calidad de la decisión en lugar de utilizar el resultado final para declarar quién tenía razón. Los nuevos riesgos deben tener una vía directa de reevaluación.
6. Ejecutar una revisión sin culpas
La guía de revisión de incidentes de GitLab se enfoca en comprender el sistema y el porqué/cómo de las decisiones, así como en las acciones preventivas. Incluye la línea de tiempo, los factores contribuyentes, las brechas de detección, la comunicación con el usuario y los elementos de acción. Decir que "alguien debió haber tenido más cuidado" no es una mejora de procesos.
7. Hacer que las mejoras sean verificables
Asigna a la matriz de gravedad, el monitoreo, los simulacros o el runbook un responsable, una fecha de entrega y una métrica. Un simulacro posterior debería reproducir el desacuerdo y verificar que los umbrales, los permisos y las plantillas de comunicación reduzcan el retraso en lugar de limitarse a añadir páginas a un documento.
Respuesta modelo
Pondría el impacto confirmado, las incógnitas y el riesgo del peor escenario en una línea de tiempo y propondría una acción de protección breve y acotada en el tiempo. Si una ruta crítica o la integridad de los datos están en riesgo, iniciaría la respuesta de mayor gravedad, la etiquetaría como reversible y la revisaría en diez minutos utilizando la tasa de errores, el alcance de usuarios y el progreso de la reversión. Asignaría roles de coordinación, técnico, redactor de notas y comunicaciones, y publicaría actualizaciones basadas en hechos. Tras la recuperación, una revisión sin culpas inspeccionaría las alertas, las reglas de gravedad y la comunicación, asignando luego responsables y métricas de verificación a cada mejora.
Errores comunes
- Esperar datos completos y perder la ventana de oportunidad para proteger el sistema.
- Usar la antigüedad o jerarquía para imponerse sobre un colega sin una señal verificable.
- Convertir el canal del incidente en conjeturas sobre la causa raíz y asignación de culpas.
- Escribir "mejorar el monitoreo" sin un responsable, fecha o métrica de aceptación.
- Tratar el resultado final como la única evidencia de la calidad de la decisión.
Preguntas de seguimiento y respuestas
¿Qué sucede si la escalación activa una guardia cruzada entre equipos de alto costo?
Compara ese costo con el riesgo de esperar y utiliza un límite de tiempo corto con criterios explícitos de reducción de gravedad. Una escalación preventiva es reversible cuando su revisión y su vía de salida son visibles.
¿Qué sucede si el product owner insiste en una gravedad baja?
Pídele que confirme la suposición de impacto, luego registra la señal de riesgo, la mitigación y el umbral. Sigue la ruta de escalación autorizada para riesgos de seguridad, integridad de datos o cumplimiento normativo, y notifica al responsable.
¿Qué sucede si las señales de monitoreo entran en conflicto?
Señala el problema de calidad de datos, asume la postura más conservadora sobre el impacto al usuario, toma una acción de protección de bajo riesgo y asigna personas para verificar registros, usuarios de muestra y dependencias. No ocultes evidencia contradictoria.
¿Cómo evitas que una cultura sin culpas se convierta en falta de rendición de cuentas?
La cultura sin culpas busca el aprendizaje y el análisis de factores del sistema, no la ausencia de responsabilidad. Cada acción tiene un responsable, una fecha de entrega y una verificación; el desprecio reiterado de riesgos conocidos sigue la gobernanza normal.
¿Cuándo debe ser pública una revisión?
Utiliza el impacto en el usuario, los contratos y las políticas para decidirlo. Un resumen público debe cubrir el impacto, la línea de tiempo, la solución y la prevención, eliminando al mismo tiempo datos personales innecesarios y especulaciones no verificadas.
¿Cómo demuestras que el enfoque funcionó?
Rastrea el retraso en la escalación, la tasa de falsas escalaciones, las actualizaciones puntuales a usuarios, el cumplimiento de acciones y los resultados de simulacros a lo largo de múltiples incidentes o ejercicios. Un solo ejemplo exitoso no es evidencia suficiente.