Pregunta y contexto
Esta pregunta evalúa el criterio, la redacción y la coordinación durante un incidente, no en una retrospectiva. Asume que el impacto aún podría estar creciendo, que existen un incident manager, un technical lead y un responsable de comunicaciones, y que la causa raíz es desconocida. Necesitas una notificación inicial, una cadencia de actualizaciones, mensajes de mitigación y recuperación, y una ruta de corrección.
Es adecuada para technical leads, SREs, platform engineers, customer engineers y roles generales que coordinan entre múltiples equipos. Separa el flujo de trabajo interno de la página de estado pública. No conviertas una hipótesis no verificada en una conclusión ni dejes a las personas afectadas sin información mientras se espera la causa raíz.
Qué está evaluando el entrevistador
Una respuesta sólida establece primero la gravedad y las audiencias a partir del impacto en el negocio, y luego asigna una única fuente de verdad, un responsable de comunicaciones y una cadencia. Indica lo que se sabe, lo que se desconoce, lo que está en progreso y cuándo llegará la próxima actualización. Aborda el escalamiento de seguridad, pérdida de datos y cumplimiento normativo, además de la coherencia entre canales, los mensajes desactualizados, la recuperación y una revisión posterior al incidente.
Preguntas de aclaración para hacer
- ¿Qué usuarios, regiones, funciones y datos están afectados? ¿El alcance es total, parcial o desconocido?
- ¿Podría esto involucrar seguridad, privacidad, pérdida de datos o una obligación regulatoria? Eso cambia las rutas de aprobación y notificación.
- ¿Quiénes son el incident manager, el technical lead y el responsable de comunicaciones? ¿Quién puede aprobar la redacción externa?
- ¿Qué canales internos y externos existen, y pueden los clientes acceder a una página de estado o a una notificación dirigida?
- ¿Qué cadencia de actualización se espera? ¿Se debe enviar una actualización de "aún investigando" aunque no haya nueva evidencia?
Marco de respuesta de 30 segundos
"Primero establezco el impacto, la gravedad y cualquier riesgo de seguridad o de datos; luego asigno un incident manager, un technical lead y un responsable de comunicaciones en torno a una única fuente de verdad. Reconozco el problema rápidamente indicando el impacto conocido, la investigación o mitigación actual y la hora de la próxima actualización. Los mensajes internos incluyen roles, el canal de trabajo y la ruta de escalamiento; los mensajes externos contienen solo hechos y acciones relevantes para el cliente. Mantengo la cadencia incluso sin una nueva conclusión. Cada canal utiliza el mismo estado y el mismo ID de incidente, y los mensajes de recuperación incluyen la confirmación, el resumen del impacto y la ruta hacia la revisión posterior al incidente".
Respuesta paso a paso
Paso 1: Evaluar el impacto y los límites de la comunicación
Establece quién está afectado, qué experimenta, cuándo comenzó, si se está expandiendo y si existe riesgo de seguridad o de datos. La gravedad determina la respuesta 24/7, el escalamiento a ejecutivos, la revisión legal o la intervención del equipo de privacidad. Etiqueta lo desconocido como desconocido; no reemplaces la evidencia con la suposición más optimista ni con la más alarmante.
Paso 2: Definir roles y una única fuente de verdad
El incident manager es dueño de las prioridades y decisiones, el technical lead es dueño de las hipótesis, mitigación y evidencia, y el responsable de comunicaciones es dueño de los mensajes internos y externos. Todos comparten un único ID de incidente, documento de estado y cronología; el chat, la página de estado, el correo electrónico y los tickets son canales de distribución. Comunicaciones no puede cambiar los hechos técnicos, y los ingenieros no deben publicar suposiciones fuera de la ruta de aprobación.
Paso 3: Enviar la notificación inicial
Una vez que el incidente esté razonablemente confirmado, publica un mensaje breve con el producto afectado, el síntoma actual, el estado de la investigación, la acción temporal que el usuario puede tomar y la próxima actualización. Los mensajes internos pueden incluir la gravedad, el canal de guardia (on-call), el responsable y la ruta de escalamiento; la redacción externa debe evitar la jerga interna y las causas no verificadas. Si se desconoce el impacto en la seguridad o en los datos, indica que se está evaluando y utiliza el proceso de notificación de seguridad independiente cuando sea necesario.
Paso 4: Establecer una cadencia de actualización y una plantilla
Elige una cadencia que coincida con la gravedad, como cada 30 minutos; actualiza antes si la evidencia cambia. Mantén cada mensaje enfocado en el estado actual, el impacto en el usuario, las acciones en curso y la hora de la próxima actualización. Incluso sin nueva evidencia, indica que el impacto sigue bajo investigación o mitigación. El nivel de detalle interno y externo puede diferir, pero el estado, la hora y el impacto deben coincidir.
Paso 5: Resolver conflictos entre canales y correcciones
Cuando los mensajes entren en conflicto, deja de copiar la redacción anterior y regresa a la fuente de verdad para la hora, el impacto y el estado. El responsable de comunicaciones publica una corrección que señala lo que cambió en lugar de sobrescribir el historial en silencio. Usa el mismo ID de incidente y las mismas transiciones de estado en todas partes; marca las páginas obsoletas como resueltas o enlázalas al resumen final.
Paso 6: Comunicar mitigación, recuperación y riesgo residual
La mitigación no es la recuperación total. Distingue entre la acción de mitigación, los usuarios que aún podrían verse afectados, las comprobaciones de consistencia de datos y la siguiente validación. Tras la recuperación, indica la hora de confirmación, la ventana de impacto, si los usuarios deben reintentar o iniciar sesión de nuevo, y si habrá una revisión posterior al incidente. Si el alcance se descubre más tarde, envía una notificación dirigida en lugar de presentar una estimación como definitiva.
Paso 7: Convertir la comunicación en un ciclo de mejora
Revisa el tiempo transcurrido hasta la primera notificación, el cumplimiento de la cadencia, la coherencia entre canales, el volumen de soporte y qué información generó confusión. Crea acciones asignadas y verificables para plantillas, acceso a la página de estado, roles de guardia y rutas de escalamiento. Mejora la comunicación junto con la revisión técnica, pero no redactes una actualización pública en curso como si fuera la conclusión de la causa raíz posterior al incidente.
Ejemplo de una respuesta sólida
"Primero establecería los usuarios, regiones, funciones afectadas, la hora de inicio y el riesgo para los datos; luego definiría la gravedad a partir del impacto en el negocio. El incident manager es dueño de las prioridades, el technical lead mantiene las hipótesis y la evidencia, y el responsable de comunicaciones gestiona los mensajes; los tres comparten un mismo ID de incidente, documento de estado y cronología.
Tras confirmar el problema, enviaría rápidamente una notificación inicial: qué está afectado, si estamos investigando o mitigando, qué pueden hacer los usuarios y cuándo llegará la próxima actualización. La redacción interna agrega la gravedad, el canal de trabajo y el contacto de escalamiento; la redacción externa contiene hechos relevantes para el cliente y no especula sobre la causa raíz. Mantendría la cadencia prometida incluso si no hay una nueva conclusión.
Si la página de estado, el correo electrónico y la respuesta de soporte difieren, recurriría a la fuente de verdad y pediría al responsable de comunicaciones que publique una corrección con el ID de incidente. Distinguiría entre mitigación, recuperación y riesgo residual, y luego publicaría la ventana de impacto, la guía de reintento y la ruta de la revisión posterior al incidente. Por último, revisaría la cadencia, el alcance, la coherencia y la carga de soporte, y asignaría mejoras con responsables claros".
Errores comunes
- Esperar a conocer la causa raíz antes de notificar → los usuarios no pueden evaluar el riesgo → indica primero el impacto conocido, la acción y la próxima actualización.
- Redactar de forma independiente para cada canal → el estado y la hora entran en conflicto → mantén una única fuente de verdad y un único ID de incidente.
- Copiar jerga interna hacia el exterior → los clientes no saben qué hacer → adapta el lenguaje según la audiencia conservando los hechos.
- Decir solo "mitigado" → los usuarios asumen una recuperación completa → separa mitigación, recuperación, validación y riesgo residual.
- No ofrecer una cadencia → el silencio parece pérdida de control → comprométete a una cadencia y actualiza incluso sin nuevas conclusiones.
- Editar en silencio un mensaje incorrecto → la confianza y la auditabilidad disminuyen → publica una corrección con marca de tiempo y conserva el historial.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: Se desconoce la causa y los clientes preguntan si los datos están seguros. ¿Qué respondes?
Indica las comprobaciones completadas y la evaluación en curso, por ejemplo: "Hasta el momento no tenemos evidencia de exposición de datos y el equipo de seguridad continúa investigando". No conviertas "aún no encontrado" en "definitivamente ninguno". Utiliza la ruta de notificación de seguridad y privacidad si se alcanza su umbral.
Pregunta de seguimiento 2: ¿Se debe actualizar cuando no hay avances?
Sí. Cumple con el compromiso e indica si el impacto cambió, qué hipótesis se está probando, qué validación está pendiente y cuándo llegará la próxima actualización. Si la cadencia cambia, explica la nueva frecuencia y el motivo.
Pregunta de seguimiento 3: Un subconjunto de clientes está afectado. ¿Una página de estado pública generará pánico?
Decide según el alcance y si los canales dirigidos pueden llegar a todos rápidamente. Si el conjunto afectado es desconocido o los canales habituales no están disponibles, una página pública puede complementar las notificaciones dirigidas. Describe las funciones afectadas y los síntomas visibles para el usuario sin detalles internos innecesarios.
Pregunta de seguimiento 4: ¿Cuándo debe publicarse la revisión posterior al incidente?
Publica primero la confirmación de recuperación y la ventana de impacto conocida. Publica la revisión cuando la evidencia y el análisis de impacto sean suficientes. Si los clientes necesitan contexto antes, proporciona un resumen preliminar etiquetado con su nivel de incertidumbre y agrega más tarde la cronología y las acciones validadas.