Gestiona un incidente desde la detección hasta la recuperación

Declara el incidente según su impacto

Un incidente es un evento que interrumpe, degrada o amenaza el servicio lo suficiente para requerir una respuesta coordinada. Tu organización define niveles de gravedad y reglas de escalado. Aplícalos según el impacto en usuarios, los datos afectados, la duración y el alcance.

No esperes una explicación completa de la causa raíz para pedir ayuda. Una descripción clara del impacto observado basta para iniciar la coordinación. Trata una sospecha de seguridad por separado de una conclusión confirmada.

Prepara la vía de respuesta antes de publicar. Mantén disponibles contactos, procedimientos de acceso, runbooks y canales de comunicación cuando el servicio principal no esté disponible. Prueba esa vía con un incidente ficticio.

Asigna responsabilidades antes de realizar cambios incompatibles

La coordinación del incidente fija prioridades y gestiona decisiones. El personal técnico investiga y mitiga. La comunicación mantiene informadas a las personas afectadas. Google SRE describe estas responsabilidades como funciones distintas. Un equipo pequeño puede combinarlas, pero debe cubrir todo el trabajo. Respuesta a incidentes.

Mantén una cronología compartida. Registra hora, observación, acción, actor y resultado. Distingue hechos de hipótesis. Usa una zona horaria común y señala las marcas temporales poco fiables.

Recorre un incidente ficticio

Todas las horas siguientes son UTC. La organización nombra a una persona coordinadora cuando el fallo de exportación afecta a varios clientes.

Una primera actualización útil indica la función afectada, el alcance conocido, la mitigación y la hora de la siguiente actualización. No promete un plazo de reparación sin pruebas. Evita incluir registros de clientes en la actualización compartida.

A las 09:10, el incidente cambia. Restaurar las exportaciones ya no basta. El equipo debe evaluar una posible divulgación, controlar el acceso, conservar pruebas e involucrar a quienes deban decidir.

Mitiga sin perder el control

Usa runbooks probados cuando sean aplicables. Comprueba las condiciones previas a un rollback, una conmutación por error o un cambio de credenciales. Una versión anterior de la aplicación podría no entender el esquema actual de la base de datos. Una conmutación regional puede trasladar los mismos datos corruptos.

Deja que un asistente de IA organice pruebas sin datos sensibles o compare hipótesis dentro de límites autorizados. El equipo de respuesta debe verificar sus conclusiones. Los logs y tickets son entradas no fiables, no una autorización para ejecutar su contenido.

El acceso de emergencia debe tener una finalidad autorizada, duración limitada y registro de auditoría. La urgencia no hace correcto el comando sugerido por un agente.

Cierra la recuperación y el seguimiento por separado

Verifica el flujo del usuario, la integridad de datos, los límites de acceso y la actualidad de la monitorización antes de declarar recuperado el servicio. Registra las restricciones restantes. Mantén abierta la investigación de seguridad si quedan preguntas sin resolver.

Después, examina las condiciones que hicieron posible el incidente. Asigna trabajo posterior concreto con responsables y criterios de verificación. Una revisión sin culpabilización busca una explicación precisa y cambios útiles. No elimina la responsabilidad de completar esos cambios. Práctica de postmortem.

Continúa con operaciones de seguridad y el cierre del ciclo de aprendizaje.