Simulación de incidencias en entornos aislados

Objetivo:

Comprender y ejecutar metodologías controladas para la simulación de fallos e incidencias críticas en entornos de pruebas aislados, aprendiendo a evaluar la resiliencia del sistema, medir tiempos de recuperación y aplicar protocolos estructurados de respuesta ante emergencias tecnológicas.

Escenario:

  • Herramientas: Entorno virtualizado aislado (Red Interna), terminal Linux, herramientas de inyección de fallos (generación artificial de carga, saturación de disco, parada forzosa de demonios).
  • Conceptos analizados: Gestión de incidentes, alta disponibilidad, tolerancia a fallos, redundancia y análisis post-mortem (post-incident review).
  • Proceso clave: Diseño de un escenario de fallo controlado en una máquina virtual aislada, ejecución de la incidencia, detección mediante monitorización, aplicación del plan de contingencia y validación de la recuperación del servicio.

Escenario Real: Pruebas de estrés y respuesta ante caídas de servicios críticos

Una organización desea comprobar cómo reacciona su infraestructura ante la caída inesperada de un servidor web en producción y la saturación de espacio en disco. Como administrador de sistemas, debes diseñar un escenario de simulación en un entorno de laboratorio totalmente aislado donde provocarás de manera controlada una incidencia de indisponibilidad, midiendo los tiempos de detección y aplicando los procedimientos de recuperación establecidos para garantizar la continuidad del negocio.

Por defecto, los sistemas están expuestos a imprevistos técnicos de diversa índole. Realizar simulacros controlados en entornos aislados es la única manera fiable de comprobar la eficacia de los planes de contingencia antes de que ocurra una emergencia real en producción.

NOTA: Asegúrate de que las simulaciones de incidencias destructivas se ejecutan exclusivamente en máquinas virtuales dotadas de red interna aislada y con su correspondiente instantánea (snapshot) previa para evitar daños colaterales.

Instrucciones:

Fase 1: Diseño del escenario de prueba y aislamiento del entorno:

  • Preparar una máquina virtual de prácticas configurando su adaptador de red en modo Red Interna para garantizar el aislamiento absoluto respecto a la red de producción real.
  • Crear una instantánea (snapshot) de seguridad previa en el hipervisor denominada "Punto de partida simulación".
  • Definir los parámetros clave a medir: Tiempo Medio de Detección (MTTD) y Tiempo Medio de Recuperación (MTTR).

Fase 2: Inyección controlada de la incidencia en el sistema:

  • Simular un fallo crítico de servicio deteniendo de forma abrupta y deshabilitando el demonio principal del servidor web (ej. Apache o Nginx): sudo systemctl stop apache2 && sudo systemctl disable apache2
  • Simular una saturación de disco creando un fichero temporal masivo que consuma el 100% de los inodos o espacio libre del sistema de ficheros de pruebas: 
    sudo dd if=/dev/zero of=/var/log/fichero_saturacion.img bs=1M count=5000

Fase 3: Detección, diagnóstico y ejecución del plan de respuesta:

  • Detectar el origen del fallo utilizando las herramientas de auditoría y logs previamente estudiadas (como systemctl --failed, journalctl o df -h).
  • Ejecutar los procedimientos correctivos de emergencia para solucionar la incidencia (por ejemplo, liberar el espacio en disco eliminando el fichero artificial y reactivar los servicios detenidos): 
    sudo rm /var/log/fichero_saturacion.img
sudo systemctl enable --now apache2

Fase 4: Auditoría post-incidente y elaboración de métricas:

  • Verificar que los servicios recuperados responden de manera óptima y que el almacenamiento vuelve a disponer de los niveles de espacio seguros.
  • Calcular los indicadores de rendimiento del simulacro (MTTD y MTTR) y documentar los puntos débiles detectados durante el proceso de resolución.

Verificación:

  • Comprobar mediante comandos de estado que todos los servicios inyectados vuelven a encontrarse activos y operativos (active (running)).
  • Verificar que el uso del almacenamiento físico ha retornado a los valores normales y estables previos a la simulación.

Posibles errores y resolución de problemas:

Si al intentar solucionar la saturación de disco provocada durante la simulación descubres que el sistema operativo se ha bloqueado por completo y no permite ejecutar comandos en la terminal, se debe a la falta total de espacio para alojar ficheros temporales del kernel.

  • Solución: Apaga la máquina virtual desde el hipervisor o restaura de forma inmediata la instantánea de seguridad (snapshot) previa creada en la Fase 1 para recuperar el control operativo del sistema de forma instantánea.

Alternativa directa: Comprobación rápida del estado de servicios críticos

Si necesitas realizar una verificación instantánea de la disponibilidad de múltiples demonios de red tras la ejecución de una incidencia simulada, puedes consultar su estado de ejecución combinando comandos de systemctl:

sudo systemctl is-active apache2 ssh ufw

Preguntas de reflexión:

  1. ¿Por qué es un requisito indispensable realizar simulaciones de incidencias destructivas exclusivamente en entornos aislados de red y no directamente sobre servidores en producción?
  2. ¿Qué métricas operativas fundamentales (como MTTD y MTTR) se evalúan durante un simulacro de fallo y qué importancia tienen para la gestión de la calidad del servicio (SLA)?
  3. ¿Qué riesgos implica para la estabilidad del núcleo del sistema operativo una saturación completa del almacenamiento (disco al 100% de su capacidad)?
  4. ¿Qué utilidad aporta la elaboración de un informe post-mortem tras finalizar una simulación o incidencia real en la infraestructura tecnológica?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es un requisito indispensable realizar simulaciones de incidencias destructivas exclusivamente en entornos aislados de red y no directamente sobre servidores en producción?

Porque la inyección de fallos como caídas de servicios, corrupción de ficheros o saturación de almacenamiento puede provocar interrupciones masivas en los servicios reales que utilizan los usuarios, pérdida irreversible de datos de negocio o brechas de seguridad involuntarias si el fallo se propaga hacia el resto de la red corporativa.

2. ¿Qué métricas operativas fundamentales (como MTTD y MTTR) se evalúan durante un simulacro de fallo y qué importancia tienen para la gestión de la calidad del servicio (SLA)?

El MTTD (Mean Time to Detect) mide el tiempo medio que se tarda en detectar que se ha producido una incidencia, mientras que el MTTR (Mean Time to Repair/Recovery) mide el tiempo medio requerido para solucionar el problema y restaurar el servicio. Ambas métricas son vitales para cumplir con los Acuerdos de Nivel de Servicio (SLA) comprometidos con los clientes o departamentos de la organización.

3. ¿Qué riesgos implica para la estabilidad del núcleo del sistema operativo una saturación completa del almacenamiento (disco al 100% de su capacidad)?

Cuando el disco se llena por completo, el sistema operativo y las aplicaciones dejan de poder escribir ficheros temporales, registros (logs) o estructuras en la memoria virtual (swap). Esto provoca congelaciones repentinas de procesos, corrupción de bases de datos activas y la caída generalizada de los servicios del servidor.

4. ¿Qué utilidad aporta la elaboración de un informe post-mortem tras finalizar una simulación o incidencia real en la infraestructura tecnológica?

Permite analizar de forma objetiva qué falló en los protocolos de respuesta, identificar las debilidades técnicas de la infraestructura, medir la eficacia del equipo humano y proponer medidas correctoras o automatizaciones preventivas para evitar que el mismo tipo de incidencia vuelva a repetirse en el futuro.