Volver a proyectos

Recuperación ante desastres y reconstrucción de infraestructura en AWS

Goapp Perú SAC · Disgo, 2018 — De la pérdida total de la infraestructura a la operación restablecida, reconstruyendo los datos desde los logs y montando backups multi-cloud

S

Situación

En Goapp Perú SAC, startup dueña del producto Disgo, y con el puesto de CTO vacante, un escalamiento mal ejecutado eliminó accidentalmente toda la infraestructura de la empresa en AWS: instancias EC2 (Windows Server, MongoDB), RDS (SQL Server) y buckets S3.

  • Sistema totalmente inaccesible para clientes y operación.
  • Sin snapshots utilizables para restauración directa desde la consola de AWS.
  • Riesgo real de pérdida irreparable de datos operativos de clientes.
T

Tarea

Debía diseñar e implementar un plan de recuperación de emergencia para reconstruir la infraestructura desde cero y recuperar la integridad de la información operativa de los clientes, sin interrumpir la continuidad del negocio ni generar pérdida irreparable de datos.

A

Acción

  1. Parsing de logs multi-fuente: diseñé scripts en JavaScript para procesar en streaming (por bloques de memoria) los logs de Apache y de la aplicación, identificando patrones con expresiones regulares para reconstruir las mutaciones de datos y consultas ejecutadas hacia SQL Server y MongoDB.
  2. Estandarización e ingesta: transformé los logs procesados en archivos CSV estructurados y ejecuté scripts automatizados de migración para reingresar masivamente la información reconstruida en las bases de datos.
  3. Reaprovisionamiento de arquitectura: reconstruí la topología de red y servidores en AWS (RDS SQL Server, EC2 con MongoDB y S3) bajo configuraciones seguras.
  4. Backup cross-cloud: diseñé un pipeline serverless con AWS Lambda que generaba dumps periódicos hacia S3 y los replicaba de forma asíncrona en Google Drive corporativo, eliminando el riesgo de punto único de fallo (SPOF) a nivel de proveedor cloud.

Compromisos de ingeniería (trade-offs)

  • Procesamiento en stream vs. uso de memoria RAM: procesar los logs por bloques de texto mediante streams en JS, en lugar de cargar archivos completos en memoria, a cambio de mayor tiempo de procesamiento y más complejidad en los scripts Regex, evitó cierres por Out Of Memory (OOM) en archivos de log de varios gigabytes.
  • Redundancia multi-cloud vs. costo operativo: replicar backups fuera de AWS hacia Google Drive mediante Lambda introdujo una dependencia externa adicional (API de Google Drive) y lógica de autenticación OAuth, a cambio de garantizar la supervivencia de los datos ante eventos catastróficos o pérdida de acceso al tenant de AWS.
R

Resultado

Métrica Antes del incidente Tras la recuperación
Estado del sistema Pérdida total (sistema inaccesible) Operación restablecida por completo
Datos operativos Sin backups directos utilizables Reconstruidos desde los logs, con pérdida residual acotada
Estrategia de respaldos Inexistente (vulnerable a borrado total) Automática y multi-cloud (AWS + Google Drive)

Se reanudó la operación sin interrupciones reportadas por los usuarios finales. La resolución del incidente y la estrategia defensiva implementada me otorgaron la confianza de la directiva para asumir la posición vacante de CTO.