Planteamiento y alcance
Un proveedor de pagos, identidad, mensajería o datos sufre una caída y el producto queda parcialmente no disponible. El entrevistador busca una historia real: cómo verificaste los hechos, asignaste roles, protegiste a los clientes, coordinaste con el proveedor, elegiste una degradación o rollback y transformaste una falla externa en una mejora medible.
Qué evalúa el entrevistador
- Si los hechos demuestran el impacto en el cliente y la prioridad en lugar de culpar al proveedor.
- Si estableciste un mando de incidentes claro y una titularidad técnica y de comunicación definida.
- Si tomaste decisiones reversibles bajo incertidumbre con condiciones explícitas de escalamiento.
- Si te haces responsable del gobierno a largo plazo de las dependencias, los simulacros y las métricas.
Preguntas para aclarar primero
- ¿Qué clientes, regiones, flujos de trabajo y propiedades de integridad de datos se vieron afectados, y el impacto iba en aumento?
- ¿Cuál era tu rol y autoridad formal, y quién era el comandante del incidente?
- ¿Existía un proveedor de respaldo, cola, caché, modo degradado o ruta manual?
- ¿Qué hechos estaban confirmados y cuáles eran solo hipótesis del proveedor?
- ¿Cómo demostraste que no quedaron cargos duplicados, mensajes perdidos o errores de permisos?
Una respuesta de 30 segundos
Utilizaría un evento STAR concreto: verificar el alcance con telemetría y muestras de clientes, y luego designar los roles de mando del incidente, técnico y de comunicación. Elegir una degradación reversible o pausar escrituras con tiempos definidos de revisión y escalamiento, compartir con el proveedor la evidencia mínima necesaria y solicitar un ETA claro. La página de estado y soporte deben usar una única versión de los hechos. Tras la recuperación, conciliar datos y compensaciones para clientes, y luego implementar una ruta alternativa, SLO de dependencia y simulacros con un responsable asignado.
Análisis detallado paso a paso
Paso 1: Establecer los hechos y el impacto
Registra la hora de inicio, la funcionalidad afectada, la tasa de errores, el alcance por cliente/tenant y el riesgo de datos. Contrasta los logs de peticiones, el estado del proveedor y una muestra pequeña y reproducible en lugar de asumir un solo reporte como verdad absoluta.
Paso 2: Asignar roles durante el incidente
Nombra a un comandante del incidente para las prioridades, a un líder técnico para la mitigación y a un líder de comunicaciones para las actualizaciones. Establece quién tiene autorización para pausar escrituras, cambiar de proveedor o aprobar créditos para evitar que las personas emitan órdenes contradictorias.
Paso 3: Elegir una mitigación reversible
Compara los efectos secundarios de reintentos, colas, caché, modo de solo lectura, respaldo y desactivación de funcionalidades. En el caso de escrituras de pagos, identidad o datos, protege la consistencia mediante validaciones de duplicados y plazos límite. Registra el detonante, el responsable y el plan de rollback para cada opción.
Paso 4: Coordinar con el proveedor y los equipos internos
Envía la cronología, request IDs, región y muestras de errores sin incluir contenido confidencial. Vuelve a verificar la evidencia y el ETA con una frecuencia fija; cuando las actualizaciones del proveedor entren en conflicto con las observaciones del negocio, utiliza métricas reproducibles de clientes para decidir la siguiente acción.
Paso 5: Comunicarse con los clientes
La página de estado debe publicar el impacto confirmado, el alcance, la hora de inicio y la próxima actualización, no suposiciones sobre la causa raíz o el tiempo de recuperación. Soporte y Customer Success deben usar un único guion para clientes de alto valor o regulados y registrar solicitudes y soluciones ofrecidas.
Paso 6: Verificar la recuperación y la integridad
Una tasa de error más baja no es prueba de recuperación. Concilia colas, escrituras duplicadas, eventos perdidos, permisos, liquidación de pagos y flujos críticos de clientes. Incrementa el tráfico gradualmente con un mecanismo de rollback disponible hasta que transcurran ventanas de observación consecutivas sin fallos.
Paso 7: Transformar el incidente en una mejora
Revisa la cronología, las evidencias, las decisiones y las condiciones del sistema sin asignar culpas personales. Define SLOs de dependencias, límites de timeout y circuit breaker, rutas de respaldo, escalamiento contractual, simulacros y una revisión trimestral con un responsable designado.
Ejemplo de respuesta de alta calidad
Contaría la historia real de la caída de un proveedor de mensajería. Las alertas mostraron un aumento en los fallos de entrega; los análisis por cliente y región demostraron que la confirmación de transacciones estaba demorada, mientras que las escrituras en la base de datos se mantenían seguras. Un comandante del incidente, un líder técnico y un líder de comunicación con clientes se dividieron el trabajo. Pausamos las notificaciones no críticas, encolamos los mensajes reintentables con claves de deduplicación y revisamos el estado cada diez minutos. El proveedor recibió request IDs, la cronología y la región sin contenido de clientes. La página de estado publicó el alcance confirmado. Tras la recuperación, reprocesamos la cola, conciliamos la entrega y muestreamos el estado de los clientes para comprobar que no hubiera duplicados ni pérdidas. La revisión posterior agregó un canal de respaldo, un SLO de dependencia, simulacros con el proveedor y una métrica de backlog por cliente, quedando bajo mi responsabilidad la verificación trimestral.
Errores comunes
- Convertir la historia en una queja sobre el proveedor sin mostrar tu criterio ni tus acciones.
- Omitir la asignación de roles del incidente mientras todos modifican configuraciones o hacen promesas a los clientes.
- Activar reintentos sin analizar los efectos secundarios, provocando cobros duplicados o tormentas de mensajes.
- Publicar en la página de estado causas raíz o tiempos de recuperación no confirmados.
- Escribir “mejorar el monitoreo” sin asignar un responsable, una fecha límite ni una métrica de aceptación.
Preguntas de seguimiento y respuestas
¿Qué pasa si el proveedor no responde?
Utiliza la ruta de escalamiento contractual mientras ejecutas las acciones aprobadas de degradación o respaldo basándote en tu propia evidencia. El silencio del proveedor no puede impedir la protección de los clientes y de los datos.
¿Cuándo se deben pausar las escrituras?
Pausa cuando continuar con las escrituras pueda generar inconsistencias irreversibles, cargos duplicados o errores de permisos y no exista una protección confiable de idempotencia. Define quién está autorizado a reanudar las escrituras y qué comprobaciones deben completarse primero.
¿Cómo demuestras que la historia no fue inventada a posteriori?
Proporciona una cronología verificable, cambios en las métricas, tus acciones y los resultados obtenidos. Separa los hechos confirmados de las hipótesis y no exageres tu autoridad ni las promesas del proveedor.
¿Cómo mides una mejora duradera?
Monitorea la duración del impacto en el cliente debido a errores de dependencias, el éxito de los respaldos, la recuperación del backlog, los eventos duplicados o perdidos, la tasa de éxito en simulacros y las acciones vencidas, en lugar de fijarte únicamente en el recuento de alertas.