Descripción del Proyecto
Hownd, una plataforma de marketing promocional sirviendo a más de 10,000 comerciantes con su Método FetchRev™, enfrentaba una crisis existencial: su equipo IT completo renunció durante una adquisición debido a disputas internas entre liderazgo. Fuimos llamados como equipo de rescate de emergencia con solo 2 semanas para tomar control de un sistema masivamente complejo y pobremente documentado antes de que el último ingeniero partiera—mientras manteníamos la plataforma operacional para miles de clientes pagadores.
La Situación de Crisis
La Tormenta Perfecta
- Salida Completa del Equipo: Todo el equipo de ingeniería renunció debido a conflictos CTO-CEO durante adquisición
- Plazo de Dos Semanas: Solo 14 días para absorber conocimiento antes de partida del último ingeniero
- Cero Documentación: Documentación mínima del sistema, conocimiento tribal saliendo por la puerta
- Sistemas en Producción: Más de 10,000 comerciantes, 5M+ consumidores dependiendo de la plataforma diariamente
- Fecha Límite de Adquisición: Nuevos propietarios necesitaban continuidad operacional inmediatamente
- Arquitectura Compleja: Sistema distribuido cruzando múltiples continentes con muchas partes móviles
La Infraestructura No Documentada que Heredamos
Capa de Aplicación
- Aplicación legacy Rails 2.3 (más de 10 años)
- Aplicación móvil Flutter / Dart 2
- Múltiples microservicios Go corriendo en ECS
- Cluster Kubernetes en Sydney, Australia (para infraestructura WiFi)
Capa de Datos
- 2 bases de datos PostgreSQL (propósitos diferentes, relaciones poco claras)
- 1 base de datos MySQL (datos legacy de comerciantes)
- Caché Redis (patrones de keys no documentados)
- Buckets S3 dispersos por regiones
Infraestructura
- Contenedores ECS con nomenclatura inconsistente
- Cluster Kubernetes a 10,000 millas de distancia
- Múltiples cuentas AWS con límites poco claros
- Sin logging o monitoreo centralizado
- Credenciales hardcodeadas en varios lugares
- Procesos de deployment manuales
Las Primeras 2 Semanas: Transferencia de Conocimiento de Emergencia
Día 1-3: Triage Rápido
Objetivo: Identificar qué es crítico vs. qué puede fallar
- Sesiones de seguimiento con ingenieros salientes (días de 16 horas)
- Documentar cada credencial y punto de acceso
- Mapear sistemas críticos vs. no críticos
- Identificar puntos únicos de falla
- Listar todos los dominios y servicios de producción
- Capturar procedimientos de deployment (por manuales que fueran)
Día 4-7: Inventario del Sistema
Objetivo: Catalogar toda la infraestructura
- 90 servicios distintos a través de ECS y Kubernetes
- 23 bases de datos y almacenes de datos diferentes
- 15 cuentas AWS con accesos superpuestos
- 6 métodos diferentes de deployment (ninguno automatizado)
- Más de 200 variables de entorno dispersas por sistemas
- 12 integraciones de terceros con documentación variable
Día 8-14: Runbooks de Emergencia
Objetivo: Documentar suficiente para sobrevivir
- Creación de procedimientos de reinicio de emergencia
- Documentación de dependencias críticas del sistema
- Establecimiento de protocolos de rotación on-call
- Configuración de alertas básicas de monitoreo
- Preparación de procedimientos de rollback
- Establecimiento de canales de comunicación con stakeholders de negocio
Mes 1: Modo Estabilización
Semana 3-4: Volando Solos
Desafío: Último ingeniero partió, completamente por nuestra cuenta
Incidentes Críticos:
- Caída de Producción Día 16: Memory leak de app Rails (no documentado)
- Failover de Base de Datos Día 21: PostgreSQL primario cayó, sin recuperación documentada
- Cluster K8s Sydney Día 25: Servicio WiFi caído, afectando ubicaciones de comerciantes
- Procesamiento de Pagos Día 28: Falla webhook Stripe, reconciliación manual requerida
Tácticas de Supervivencia:
- Rotación on-call 24/7
- Canal Slack de sala de guerra
- Chequeos diarios de salud del sistema
- Comprensión gradual del sistema a través de apagafuegos
- Construcción de conocimiento institucional desde incidentes de producción
Logros Mes 1
- Cero Pérdida Mayor de Datos: A pesar del caos, protegimos datos de clientes
- 99.2% Uptime: Mantuvimos servicio (vs 99.95% objetivo)
- Mapa del Sistema Creado: Primer diagrama completo de arquitectura
- Monitoreo Establecido: Dashboards CloudWatch para rutas críticas
- Confianza del Equipo: De pánico a optimismo cauteloso
Meses 2-6: Comprensión y Estabilización
La Excavación Arqueológica
Abordamos el código base como expedición arqueológica, descubriendo capas de historia técnica:
Aplicación Legacy Rails 2.3
- Aplicación Ruby on Rails de 10 años
- Dependencias gem congeladas en 2014
- Integración SugarCRM personalizada (modificaciones no documentadas)
- Gestión de sesiones usando librerías obsoletas
- Vulnerabilidades de seguridad (CVEs sin parchear por años)
El Laberinto de Microservicios Go
- Más de 15 servicios Go en ECS Fargate
- Formatos de logging inconsistentes
- Sin rastreo centralizado de errores
- Auth servicio-a-servicio vía tokens hardcodeadas
- Conexiones de base de datos sin pooling
El Misterio de Sydney
- Cluster Kubernetes en Australia para infraestructura de hotspot WiFi
- Provisión WiFi para ubicaciones de comerciantes
- ¿Por qué Sydney? Nadie sabía (resultó: primer desarrollador era australiano)
- 300ms de latencia a bases de datos basadas en US
- Sin plan de recuperación ante desastres
Arqueología de Base de Datos
- PostgreSQL #1: Datos principales de comerciantes y transacciones
- PostgreSQL #2: Analíticas y reportes (duplicación masiva)
- MySQL: Datos legacy de plataforma original (aún consultado activamente)
- Sin constraints de foreign keys (integridad referencial por esperanza)
- 40% de tablas sin uso (de funcionalidades abandonadas)
Mejoras Críticas (Meses 2-6)
Monitoreo y Observabilidad
- Implementación de New Relic APM
- Logging centralizado con CloudWatch Logs Insights
- Trazado distribuido con X-Ray
- Creación de dashboards comprehensivos
- Configuración de escalaciones PagerDuty
Endurecimiento de Seguridad
- Secrets Manager para todas las credenciales
- Rotación de todas las contraseñas hardcodeadas
- Implementación de reglas WAF
- Adición de security groups VPC
- Habilitación de logging CloudTrail
- Aprobación de primera auditoría de seguridad post-adquisición
Optimización de Rendimiento
- Identificación de queries N+1 en Rails (docenas)
- Implementación de connection pooling de base de datos
- Adición de capa de caché Redis
- Optimización de dimensionamiento de tareas ECS
- Reducción de latencia Sydney-US con replicación de datos
Documentación
- Diagramas completos de arquitectura de sistema
- Mapas de dependencia de servicios
- Documentación de esquema de base de datos
- Runbooks de deployment
- Procedimientos de recuperación ante desastres
- Playbooks on-call
Meses 7-12: Comienza la Modernización
Migración Rails 2.3 → Rails 5
El Desafío: Actualizar app Rails de 10 años sin romper producción
Enfoque:
- Creación de entorno Rails 5 paralelo
- Migración funcionalidad por funcionalidad
- Pruebas extensivas de regresión
- Cambio gradual de tráfico
- Capacidad de rollback en cada paso
Obstáculos Superados:
- Más de 200 actualizaciones de gems deprecados
- Monkey patches personalizados (cientos)
- Cambios que rompen en ActiveRecord
- Renovación de gestión de sesiones
- Migración de asset pipeline
Consolidación de Servicios Go
El Problema: 15 microservicios, 8 haciendo cosas similares
Solución:
- Fusión de servicios redundantes
- Estandarización de logging y errores
- Implementación de circuit breakers
- Adición de endpoints de health check
- Containerización con mejores prácticas
Racionalización de Base de Datos
Descubrimiento: 40% de esquema sin uso, duplicación masiva de datos
Acciones:
- Consolidación de reportes a PostgreSQL único
- Archivado de datos legacy MySQL
- Implementación de foreign keys apropiados
- Adición de scripts de migración de base de datos
- Configuración de backups automatizados
Migración Kubernetes Sydney
Decisión: Mover infraestructura WiFi a US East
Ejecución:
- Construcción de cluster K8s idéntico en US-East-1
- Migración de servicios de provisión WiFi
- Reducción de latencia de 300ms a 15ms
- Desmantelamiento de cluster Sydney
- Ahorro de $8K/mes en costos cross-region
Meses 13-24: Construyendo para el Futuro
Pipeline CI/CD Automatizado
- Antes: Deployments manuales vía SSH (horas)
- Después: GitHub Actions con pruebas automatizadas (12 minutos)
- Deployments blue-green
- Rollbacks automatizados en falla
- Feature flags para lanzamientos graduales
Infraestructura como Código
- Antes: Clickops en consola AWS
- Después: 100% infraestructura gestionada con Terraform
- Infraestructura con control de versiones
- Entornos reproducibles
- Paridad Dev/QA/Prod
Crecimiento del Equipo y Conocimiento
- Contratación de 3 ingenieros adicionales
- Documentación comprensiva de onboarding
- Eliminación de puntos únicos de conocimiento
- Establecimiento de procesos de revisión de código
- Implementación de pair programming para sistemas complejos
Continuidad de Negocio
- Recuperación ante desastres multi-región
- Procedimientos automatizados de failover
- Simulacros regulares de DR
- RTO: 15 minutos, RPO: 5 minutos
- Plan comprensivo de respuesta a incidentes
Resultados e Impacto
Métricas Operacionales
- Uptime: De 99.2% (crisis) a 99.97% (estable)
- Respuesta a Incidentes: De horas a minutos
- Frecuencia de Deployment: De mensual (manual) a diario (automatizado)
- Mean Time to Recovery: De 4 horas a 15 minutos
- Alertas On-Call: Reducidas en 85%
Optimización de Costos
- Costos de Infraestructura: 40% de reducción a través de dimensionamiento correcto
- Costos Cross-Region: Eliminados con migración Sydney
- Optimización RDS: Movido a Aurora Serverless (35% ahorro)
- Recursos Sin Uso: Identificados y desmantelados (20% ahorro)
- Ahorro Anual Total: $450K
Impacto de Negocio
- Cero Churn de Clientes: Durante período de transición
- Adquisición Completada: A pesar de incertidumbre técnica
- Nuevas Funcionalidades: Entregadas dentro de 6 meses de toma de control
- Contratos Empresariales: Ganados 3 contratos mayores (confianza en seguridad)
- Moral del Equipo: De modo crisis a modo innovación
Conocimiento y Documentación
- Más de 3,000 Líneas: De documentación de runbooks
- 45 Diagramas de Arquitectura: Mapas completos de sistema
- 100% Recuperación: Todos los sistemas documentados para recuperación
- Onboarding Nuevo Ingeniero: De imposible a 2 semanas
- Bus Factor: De 1 (crisis) a resiliencia de equipo
Profundización Técnica
El Misterio Kubernetes Sydney Resuelto
¿Por qué había un cluster K8s en Australia?
Tras investigación extensiva, descubrimos:
- Desarrollador líder original era australiano
- Provisión de hotspot WiFi comenzó como proyecto paralelo
- Nunca migrado cuando equipo creció
- Se volvió producción antes de que alguien cuestionara
- Resultó en 300ms de latencia para llamadas de base de datos
Estrategia de Migración:
- Construcción de cluster paralelo en US-East-1
- Replicación de configuración de servicio WiFi
- Deployment de instancias canary
- Cambio gradual de tráfico por 2 semanas
- Monitoreo de problemas
- Desmantelamiento de cluster Sydney
- Resultado: 95% reducción de latencia
Cicatrices de Batalla Rails 2.3 a Rails 5
Obstáculos Mayores:
Infierno de Gems: Más de 50 gems sin soporte Rails 5
- Solución: Fork y actualización de gems críticos
- Reemplazo de gems deprecados con alternativas modernas
- Construcción de soluciones personalizadas para gems abandonados
Monkey Patches por Todas Partes: Más de 200 monkey patches
- Solución: Refactorización sistemática
- Reemplazo con herencia apropiada
- Algunos requirieron comprensión del core de Rails
Suite de Pruebas: Sin pruebas (en serio, cero)
- Solución: Adición de pruebas durante migración
- Ahora en 65% de cobertura
- Prevención de incontables regresiones
Descubrimientos de Consolidación de Base de Datos
Misterio Base de Datos PostgreSQL #2:
- Descubierto que era 90% duplicado de Base de Datos #1
- Creado 3 años atrás por ingeniero que “quería mejores reportes”
- Nunca sincronizado apropiadamente
- Deriva de datos del 15%
- Confusión de comerciantes por reportes conflictivos
Solución:
- Construcción de réplicas de lectura apropiadas desde primario
- Migración de todas las consultas de reporte
- Validación de consistencia de datos
- Desmantelamiento de base de datos duplicada
- Ahorro de $12K/mes en costos RDS
Lecciones de Gestión de Crisis
Lo Que Nos Salvó
- Enfoque Metódico: Inventario antes de acción
- Cobertura 24/7: Nadie solo durante crisis
- Comunicación: Actualizaciones diarias a stakeholders
- Priorización: Ruta crítica primero, todo lo demás después
- Documentación: Escribir todo inmediatamente
- Humility: “No sé” es mejor que adivinar
- Apoyo del Equipo: Seguridad psicológica durante caos
Lo Que Haríamos Diferente
- Negociar Transferencia Más Larga: 2 semanas no fueron suficientes (4-6 semanas mínimo)
- Congelar Cambios: Deberíamos haber congelado desarrollo de funcionalidades más tiempo
- Consultores Externos Antes: Trajimos experto Rails 2.3 mes 3 (debió ser semana 1)
- Pruebas de Carga: Deberíamos haber probado antes de hacer cambios
- Cadencia de Comunicación: Standups diarios insuficientes, necesitábamos dos veces al día durante crisis
Banderas Rojas Que Aprendimos a Detectar
- Ingenieros saliendo en masa
- Falta de documentación
- Procesos manuales de deployment
- Sin logging centralizado
- Credenciales hardcodeadas
- Explicaciones “simplemente funciona”
- Miedo de tocar cierto código
- Una persona conociendo sistemas críticos
Testimonio del Cliente
“Cuando nuestro equipo completo de ingeniería se fue durante la adquisición, pensamos que la plataforma estaba perdida. Greicodex vino en nuestra hora más oscura y no solo mantuvo las luces encendidas—hicieron la plataforma mejor de lo que jamás fue. Tomaron un desorden caótico de sistemas y lo convirtieron en una máquina bien aceitada. Su gestión de crisis, experiencia técnica y pura determinación salvaron nuestro negocio.”
— CEO, Hownd (Post-Adquisición)
Tecnologías con las que Luchamos
- Backend: Ruby on Rails 2.3 → 5.2, Go 1.11 → 1.21
- Frontend: Angular 8, React (introducido)
- Contenedores: Docker, Amazon ECS Fargate, Kubernetes
- Bases de Datos: PostgreSQL 9.6 → 14, MySQL 5.7, Redis 6
- Infraestructura: AWS (ECS, RDS, S3, CloudFront, Lambda)
- Monitoreo: New Relic, CloudWatch, X-Ray, PagerDuty
- CI/CD: GitHub Actions, Terraform
- Búsqueda: Elasticsearch 6 → 7
El Lado Humano
Salud Mental del Equipo
Los primeros 3 meses fueron brutales:
- Semanas de 80 horas
- Turnos on-call de fin de semana
- Incidentes de producción a las 3 AM
- Síndrome del impostor ("¿Realmente podemos hacer esto?")
- Presión de stakeholders de negocio
- Miedo al fracaso catastrófico
Cómo Sobrevivimos:
- Tiempo libre obligatorio después de incidentes
- Apoyo de terapia/consejería
- Cenas y unión de equipo
- Celebración de victorias pequeñas
- Comunicación honesta
- Responsabilidad distribuida
- Mentalidad “es un maratón, no un sprint”
El Punto de Inflexión
Mes 4, Semana 2: Primera semana con cero incidentes críticos
Esa semana cambió todo:
- Confianza del equipo se disparó
- Stakeholders de negocio se relajaron
- Cambiamos de defensa a ofensa
- Comenzamos a planear mejoras vs. apagar fuegos
- Nos dimos cuenta que habíamos superado lo peor
Viaje Continuo
Estado Actual (Mes 24+)
- Plataforma estable y creciendo
- Prácticas modernas de desarrollo
- Equipo feliz y confiado
- Nuevas funcionalidades desplegándose regularmente
- Deuda técnica siendo abordada sistemáticamente
- No más páginas a las 3 AM
Planes Futuros
- Completar actualización Rails a 7.x
- Mesh de microservicios con Istio
- Machine learning para detección de fraude
- Pipeline de analíticas en tiempo real
- Lista para expansión internacional
- Reescritura de app móvil (Flutter)
¿Enfrentando Crisis Similar?
Hemos pasado por el peor escenario posible y salimos más fuertes. Si estás enfrentando:
- Salidas de equipo
- Sistemas no documentados
- Caos técnico
- Desafíos de adquisición
- Riesgos de plataforma legacy
Entendemos la presión, la incertidumbre y el camino adelante.