Consigna y contexto
Diseña una plataforma de comando de incidentes para múltiples equipos. Debe recibir alertas, crear incidentes, asignar roles de respuesta, coordinar la comunicación interna y externa y conservar una línea de tiempo auditable después de la recuperación. Explica la consistencia, los permisos, las tormentas de notificaciones y los objetivos de recuperación.
Esto encaja en roles de diseño de sistemas, SRE, plataforma y backend. Evalúa cómo la detección, el comando, la colaboración y la revisión se convierten en un sistema recuperable bajo presión. La plataforma no es simplemente un chat: es un plano de control con responsables asignados, transiciones de estado, evidencia y rutas de degradación. Clarifica las tasas de alertas normales y pico, incidentes concurrentes, participantes, canales y retención.
Qué evalúan los entrevistadores
- Separar la gestión de incidentes del monitoreo, el chat y los sistemas de tickets.
- Definir el estado, la idempotencia, una fuente de la verdad y reglas de edición concurrente.
- Separar los deberes del incident manager, tech lead, communications lead y scribe.
- Manejar la deduplicación, la correlación, las tormentas de notificaciones y la autorización.
- Proporcionar degradación, recuperación regional, integridad de auditoría y retención.
- Validar el diseño con MTTA, MTTR, ruido de alertas y retraso en la comunicación.
Una respuesta en 30 segundos
“Dividiría la plataforma en ingesta de alertas, orquestación de incidentes, colaboración en tiempo real, notificación y almacenamiento de revisiones. La capa de ingesta deduplica por origen y ventana de tiempo; la orquestación trata el incidente como la fuente de la verdad y versiona los cambios de estado y de roles para auditoría. El incident manager comanda, el tech lead diagnostica, el communications lead actualiza a las partes interesadas y el scribe mantiene la línea de tiempo. Los eventos se persisten antes de que los flujos reproducibles envíen actualizaciones. Las notificaciones se priorizan y se limitan por tasa. Durante una falla regional, el plano de control mínimo y la alternativa manual permanecen disponibles; la recuperación genera una revisión a partir de la línea de tiempo”.
Solución paso a paso
Paso 1: Definir límites y objetivos
Las señales pueden provenir de métricas, registros, verificaciones sintéticas, escalamiento de soporte o un humano. La plataforma organiza las señales en incidentes y flujo de trabajo de respuesta; no reemplaza el cómputo de monitoreo, el almacenamiento de chat ni el despliegue. Establece objetivos para la latencia de creación de incidentes, la entrega de notificaciones críticas, la durabilidad de la línea de tiempo, el tiempo de recuperación regional y la retención de auditoría.
Separa la carga normal de una interrupción grande: decenas de miles de alertas por minuto, cientos de incidentes concurrentes, cientos de participantes por incidente y entrega simultánea por SMS, correo electrónico, push y webhooks. Los picos requieren contrapresión y prioridad para que las notificaciones de bajo valor no puedan bloquear las acciones de comando.
Paso 2: Ingerir, deduplicar y correlacionar alertas
Conserva el origen, la versión de la regla, la marca de tiempo, la huella digital y la carga útil sin procesar para cada señal. Los reintentos del cliente y la reproducción de red requieren claves de idempotencia; una restricción única o concesión previene incidentes duplicados para una misma huella digital. Una ventana de deduplicación no debe ocultar una nueva interrupción para siempre, así que configúrala por servicio, entorno y tiempo.
La correlación puede comenzar con la topología del servicio, la versión de despliegue, la región y las etiquetas compartidas, para luego permitir que el incident manager divida o fusione. La correlación automática debe registrar su regla y evidencia; no puede cambiar silenciosamente el alcance del incidente. Las alertas sin procesar son inmutables, mientras que la agregación es un estado derivado.
Paso 3: Modelar el estado y los roles
Un incidente puede usar estados como detectado, clasificado, mitigando, monitoreando, resuelto y cerrado. Define transiciones legales, actores y evidencia requerida. El estado no es un booleano; registra el impacto, la hipótesis actual, la siguiente acción y el tiempo de actualización juntos.
Separa los roles de respuesta de la identidad. El incident manager es dueño de la prioridad y las decisiones, el tech lead es dueño de la investigación, el communications lead es dueño de las actualizaciones internas y externas, y el scribe mantiene la línea de tiempo. Los cambios de rol anexan eventos de auditoría. Las concesiones y versiones evitan que dos respondedores sobrescriban silenciosamente un comando.
Paso 4: Construir la colaboración alrededor de una sola fuente de la verdad
Persiste el estado, los roles, los elementos de acción y los resúmenes de comunicación en un registro de eventos o almacén transaccional antes de publicarlos a través de un bus a canales de WebSocket, SSE, correo electrónico y móviles. Un cliente puede renderizar de forma optimista, pero un conflicto de versiones requiere una nueva lectura del servidor. La memoria del navegador nunca es la verdad final.
Almacena el actor, la hora del servidor, la versión del incidente, el tipo de acción, el resumen y las alertas relacionadas en la línea de tiempo. El chat extenso puede residir en otro lugar, pero las decisiones y la evidencia de recuperación pertenecen a una línea de tiempo estructurada. Los modelos de lectura pueden renderizar el incidente actual, mientras que la reproducción aún lo reconstruye.
Paso 5: Controlar las tormentas de notificaciones y el acceso
Limita las tasas según la prioridad del incidente, el cronograma de guardia, la confiabilidad del canal y la confirmación. Resume las alertas de baja prioridad; utiliza retroceso, escalamiento y tiempos de espera de confirmación para notificaciones de alta prioridad. Un solo incidente no debe enviar cientos de mensajes duplicados a un respondedor. Aísla las colas de notificación del plano de control para que una interrupción del proveedor no pueda bloquear los cambios de estado.
Autoriza a observadores, respondedores, incident managers, communications leads y administradores por inquilino, servicio y entorno. Una página de estado externa es una proyección de lectura redactada del impacto y el progreso; no debe exponer hipótesis, datos de clientes ni credenciales. Registra lecturas y exportaciones, y exige un motivo más una revisión posterior para el acceso de emergencia (break-glass).
Paso 6: Degradar, recuperar y revisar
Si la plataforma falla, conserva un puente telefónico, un runbook estático o un registro de incidentes de respaldo. Preserva primero la creación de incidentes, el reclamo de roles y las escrituras en la línea de tiempo; los análisis, la búsqueda y los informes históricos pueden no estar disponibles. El despliegue regional puede usar un escritor principal con replicación asíncrona o escrituras particionadas, pero documenta el manejo de conflictos y la readquisición de concesiones durante la conmutación por error.
Después de la recuperación, redacta una revisión a partir de las marcas de tiempo de detección, confirmación, mitigación, recuperación y cierre, las decisiones, la calidad de las alertas, la comunicación y el trabajo de seguimiento. No sobrescribas la línea de tiempo original; las revisiones anexan versiones. Haz seguimiento de MTTA, MTTM, MTTR, la proporción de alertas duplicadas, la latencia de reclamo de roles, la entrega de notificaciones y la finalización de elementos de acción.
Ganancia de información y límites
El valor de una plataforma de comando de incidentes proviene de estructurar la propiedad, el estado y la evidencia, no de mover cada conversación a una sola página. No puede garantizar una causa raíz correcta ni reemplazar la calidad del monitoreo y la capacitación de los respondedores. Las notificaciones, la identidad, las redes regionales y la plataforma misma pueden fallar juntas, por lo que el diseño necesita un plano de control mínimo y una alternativa manual.
Respuesta modelo
“Definiría el límite primero: la plataforma organiza las alertas y la respuesta, mientras que el monitoreo, el despliegue y el chat ordinario permanecen separados. Los objetivos son la latencia de creación, la entrega de notificaciones críticas, la durabilidad de la línea de tiempo, la recuperación regional y la retención de auditoría. La ingesta conserva las alertas sin procesar y utiliza huellas digitales de origen más claves de idempotencia para la deduplicación. La correlación por servicio, región, versión y topología es explicable y reversible.
La capa de orquestación es una máquina de estados versionada cuyos cambios de estado y de rol se anexan a un registro duradero. El incident manager es dueño de las decisiones, el tech lead investiga, el communications lead actualiza a las partes interesadas y el scribe mantiene la evidencia. Los clientes reciben actualizaciones reproducibles y vuelven a leer ante conflictos de versión; la caché del navegador no es autoritativa. Las acciones de control y las notificaciones utilizan colas separadas, con límites de prioridad, guardia y confirmación.
El acceso está aislado por inquilino, servicio y entorno, y la proyección externa está redactada. Durante una falla regional, la creación, el reclamo de roles y las escrituras en la línea de tiempo se mantienen disponibles mientras que la búsqueda y los informes se degradan a solo lectura o fuera de línea. La recuperación produce una revisión a partir de una línea de tiempo inmutable y calcula MTTA, MTTR, ruido de alertas y finalización de acciones. Si la plataforma no está disponible, un puente telefónico y un runbook estático mantienen posible el comando”.
Errores comunes
- Tratar la plataforma como chat → el estado clave se vuelve no auditable → usa una máquina de estados estructurada y una línea de tiempo.
- Transmitir cada alerta → las tormentas de notificaciones bloquean el comando → deduplica, prioriza, confirma y limita la tasa.
- Mantener los roles solo en la UI → los respondedores concurrentes se sobrescriben entre sí → usa concesiones de servidor, versiones y eventos de auditoría.
- Ocultar la correlación automática → un alcance incorrecto no se puede explicar → conserva las alertas sin procesar y la evidencia de correlación.
- Diseñar solo la región en buen estado → una interrupción de la plataforma elimina el comando → proporciona un plano de control mínimo y una alternativa manual.
- Sobrescribir la evidencia de revisión → las decisiones y las marcas de tiempo no se pueden verificar → mantén el registro sin procesar inmutable y anexa revisiones.
Preguntas de seguimiento
¿Qué sucede si dos incident managers reclaman el control a la vez?
Usa una concesión de toma de control con expiración y una versión monotónica. El servidor acepta escrituras de control únicamente del poseedor de la concesión actual. El respondedor perdedor vuelve a leer y muestra al propietario; el acceso de emergencia (break-glass) requiere autorización, motivo y auditoría.
¿Puede una interrupción del proveedor de notificaciones afectar el estado del incidente?
No debe hacer que la entrega de notificaciones sea un requisito previo para las escrituras de estado. Persiste primero el incidente y la notificación pendiente, luego permite que un worker aislado reintente, cambie de canal o active un proceso telefónico mientras el plano de control sigue siendo utilizable.
¿Cómo evitas que la correlación oculte un nuevo incidente?
La correlación crea una relación candidata y conserva la señal sin procesar. Usa múltiples dimensiones de evidencia como tiempo, servicio, región y topología. Las señales de alto impacto o baja confianza requieren confirmación humana, y las versiones de reglas más las divisiones ingresan a la línea de tiempo.
¿Qué pertenece a una página de estado externa?
Solo una proyección con filtros de privacidad del impacto, la fase actual, la hora de la próxima actualización y el progreso de la recuperación. Mantén las hipótesis internas, los identificadores de clientes, las credenciales, las causas raíz no confirmadas y los registros detallados en vistas internas controladas.