Planteamiento y contexto
Cuéntame sobre una ocasión en la que escalaste un riesgo en producción antes de confirmar la causa raíz. Explica cómo separaste los hechos de las hipótesis, coordinaste a las personas, te comunicaste con las partes interesadas y demostraste que escalar fue lo correcto.
Esta pregunta conductual se adapta a roles de ingeniería, liderazgo técnico y SRE. Usa una experiencia real; el ejemplo STAR que se muestra a continuación es ficticio y sus números son ejemplos reemplazables. La señal evaluada es el criterio, la comunicación y la acción, no actos heroicos personales disfrazados de escalamiento.
Qué evalúa el entrevistador
El entrevistador busca evidencia de que protegiste a los usuarios con información incompleta, estableciste un umbral de escalamiento y tu responsabilidad, y mantuviste separados los hechos, las hipótesis, las siguientes verificaciones y las acciones de reversión (rollback). Una respuesta sólida también demuestra comunicación centralizada, búsqueda oportuna de ayuda, mitigación primero y una revisión sin culpas (blameless review) en lugar de esperar una causa raíz confirmada antes de informar a alguien.
Preguntas para aclarar antes de responder
- ¿El evento afectó a los usuarios, los datos, el cumplimiento normativo o un proceso interno?
- ¿Qué señales fueron evidencia directa y cuáles fueron correlaciones o suposiciones?
- ¿El equipo contaba con niveles de incidentes, roles de guardia (on-call) y una ruta de escalamiento?
- ¿De qué te hiciste cargo personalmente y qué requirió un comandante de incidentes (incident commander) o un responsable del negocio?
- ¿Los números de resultados son reales y verificables, o deben reemplazarse con ejemplos?
Marco de respuesta de treinta segundos
“Describiré un caso real en el que las señales de impacto cruzaron un umbral antes de que se conociera la causa raíz. Separaré los hechos confirmados de las hipótesis, luego explicaré la mitigación más pequeña, cuándo escalé y por qué no esperé más evidencia. Dividí la investigación, las operaciones y la comunicación, y mantuve informados a los usuarios y a las partes interesadas. Después, una revisión sin culpas convirtió la lección en responsables y fechas límite, y las métricas demostraron que el riesgo disminuyó”.
Análisis detallado paso a paso
1. Activa el escalamiento a partir de hechos e impacto, no del instinto
Registra la hora, las solicitudes o usuarios afectados, la tasa de errores, el alcance y los cambios recientes. Escribe “el nuevo despliegue puede estar relacionado” como una hipótesis y “la tasa de error regional superó la línea base durante cinco minutos” como un hecho. Escala debido al impacto en los usuarios, la propagación, el riesgo en los datos o un umbral de incidente existente, no porque sientas ansiedad.
2. Reduce el daño antes de perseguir la causa raíz
Elige una pausa, reversión (rollback), desvío de tráfico, límite de tasa (rate limit) o desactivador de funciones (feature kill switch) según el riesgo. Asigna a la acción un responsable, métricas de observación y una condición de reversión; ante la incertidumbre, prioriza el paso reversible más pequeño. La guía de Google SRE es reducir el impacto primero y luego encontrar la causa raíz, en lugar de tratar el “aún investigando” como una razón para no hacer nada.
3. Organiza los roles y el mensaje de escalamiento
Publica un estado breve en un solo canal: impacto, hechos conocidos, incógnitas, acciones intentadas, responsable actual y ayuda solicitada. Un escalamiento debe indicar el porqué, lo que intentaste y quién debe hacer qué, no solo reenviar una alerta. Puedes ser el investigador, el operador o el líder de comunicaciones, pero especifica qué decisiones corresponden al comandante del incidente.
4. Gestiona la incertidumbre y la frecuencia de actualización
Registra la marca de tiempo en cada actualización y clasifica el nivel de certeza: confirmado, en validación o no respaldado. Incluso sin una nueva causa raíz, informa el estado de mitigación y la hora de la próxima actualización. El silencio hace que los usuarios y líderes asuman que nadie está trabajando en el problema; la frecuencia debe seguir el nivel de impacto acordado previamente, no la improvisación.
5. Da forma a la historia real con STAR
Situación proporciona el contexto del negocio y los límites de impacto. Tarea establece tu responsabilidad y el objetivo de escalamiento. Acción detalla la evidencia, el umbral, la mitigación, la ayuda y la comunicación. Resultado brinda impacto verificable en usuarios, tiempo de recuperación, tasa de errores o mejoras de seguimiento. No reclames el resultado del equipo como propio; identifica el criterio que ejerciste y la acción que impulsaste.
6. Convierte el resultado en aprendizaje medible
La revisión registra la cronología, el impacto, los factores contribuyentes, la mitigación y los elementos de acción. Cada elemento necesita un responsable, fecha límite, métrica de validación y prioridad; por ejemplo, una compuerta de lanzamiento, un monitor faltante, un cambio de cobertura de guardia (on-call) o un simulacro de escalamiento. El lenguaje sin culpas examina las brechas del sistema y del proceso en lugar de reescribir una decisión razonable tomada con información incompleta como una falta personal.
Ejemplo de respuesta de alta calidad
El siguiente ejemplo es ficticio; reemplaza cada número con tu propia evidencia.
“Era responsable de un servicio de callback de pagos. Tras un despliegue de viernes, la tasa de éxito en el Sudeste Asiático cayó del 99.8% al 97.9%, pero no sabíamos si la causa era el código, un tercero o la red. Mi trabajo consistía en proteger a los usuarios de pagos y ofrecer al equipo de guardia una visión compartida. Registré la cronología, la región y la versión del lanzamiento como hechos y traté ‘una configuración del connection-pool está agotando el tiempo de espera’ como una hipótesis. Pausé el despliegue posterior y revertí esa región, observando la tasa de error de diez minutos y la métrica de cobros duplicados. Luego escalé en el canal de incidentes con los registros ya verificados, pedí a los equipos de bases de datos y pagos comprobaciones específicas y solicité al líder de guardia que actuara como comandante del incidente. Publiqué actualizaciones cada 15 minutos, incluso cuando la causa raíz aún era desconocida pero la tasa de éxito se había recuperado tras el rollback. Más tarde confirmamos que un tercero había ralentizado sus respuestas. Un resultado de ejemplo sería un 80% menos de solicitudes afectadas y recuperación en 18 minutos; en una entrevista reemplazaría eso con evidencia de monitoreo. La revisión agregó una alerta de latencia de terceros, límites de despliegue en horario comercial y un simulacro de rollback del cual fui responsable”.
Errores comunes
- Esperar a la causa raíz antes de escalar → el impacto puede crecer mientras continúa la investigación → usa primero los umbrales de impacto y propagación.
- Decir solo “notifiqué a todos” → la comunicación no es accionable → indica hechos, hipótesis, acciones intentadas y solicitudes.
- Describir el rollback como una corazonada → el riesgo y las condiciones de reversión quedan invisibles → explica la reversibilidad, las métricas y las condiciones de parada.
- Atribuirse el resultado del equipo como propio → la responsabilidad y la colaboración se vuelven confusas → atribúyete tu criterio y la acción que impulsaste.
- Inventar porcentajes o tiempos de recuperación → la evidencia no se puede comprobar → etiqueta los datos de ejemplo y reemplázalos con registros reales.
- Escribir “mejorar el monitoreo” como revisión → sin responsable ni definición de completado → asigna un responsable, fecha límite, métrica y verificación.
Preguntas de seguimiento y respuestas
¿Qué pasa si un líder dice que la evidencia es insuficiente y rechaza el escalamiento?
Escribe un breve resumen del alcance, la tendencia, el peor escenario y la mitigación reversible, luego propón un plazo de observación y una condición de escalamiento. Si el escalamiento se pospone, registra el desacuerdo, el responsable y la hora de la próxima verificación en lugar de discutir emocionalmente.
¿Harías un rollback si eso eliminara una función importante?
Compara el perjuicio para el usuario con el valor de la función y prioriza un kill switch, un rollback parcial o un límite de tasa que reduzca el radio de impacto (blast radius). Especifica la pérdida a corto plazo aceptada, la condición de recuperación y quién aprueba; evita presentar una regla binaria.
¿Cómo demuestras que tu criterio de escalamiento fue el correcto?
Revisa la decisión utilizando la información disponible en ese momento: ¿se mantuvo el umbral?, ¿la mitigación redujo el impacto?, ¿el equipo correcto se unió antes?, ¿la comunicación redujo la duplicación en la investigación? El resultado no necesita demostrar que predijiste la causa raíz; debe mostrar que el escalamiento redujo el riesgo y acortó la respuesta.
¿Qué pasa si tu hipótesis era completamente errónea?
Considérala una vía de investigación, no un hecho. Explica por qué era razonable en ese momento, qué señal la habría descartado antes y qué registros, paneles de control (dashboards) o pasos del runbook mejoraste.
¿Qué pasa si un equipo remoto no tiene un canal de incidentes compartido?
Elige un canal de incidentes con capacidad de búsqueda y un documento de estado, nombra responsables de comando de incidentes, investigación, operaciones y comunicaciones, y copia los hallazgos críticos de mensajes directos en el registro público para que el contexto no se fragmente.