Resumen ejecutivo
Durante la tarde del martes 22 de abril, uno de los componentes centrales de nuestra plataforma de datos entró en saturación y dejó de aceptar nuevas escrituras. Eso afectó al ciclo de vida de las llamadas y al panel de cliente. El equipo aceleró una migración estructural que ya teníamos en marcha desde hacía semanas, y a última hora del mismo día el servicio operaba con normalidad sobre una arquitectura más robusta.
No se han perdido datos. Las llamadas que quedaron bloqueadas a mitad de proceso fueron reconciliadas. Un pequeño subconjunto de llamadas que estaban en cola y nunca llegaron a ejecutarse se canceló de forma controlada para evitar dobles ejecuciones tras la recuperación.
Causa raíz
La plataforma utilizaba un componente de almacenamiento que estaba bien dimensionado para consultas de análisis, pero limitado para el ritmo de actualizaciones que exige nuestra operativa actual (cada llamada genera múltiples cambios de estado en pocos segundos).
Una combinación de tráfico elevado y una operación puntual ejecutada el día anterior llevaron a ese componente por encima de su umbral seguro y lo bloquearon. El bloqueo se propagó al flujo de llamadas en curso.
La causa raíz no es un fallo puntual de software, sino una decisión de arquitectura heredada que ya estábamos sustituyendo de forma planificada. La incidencia nos obligó a acelerar esa sustitución.
Lo que vimos: el componente de datos rechazando nuevas escrituras, llamadas atascadas a mitad de proceso, acumulación en cola y vistas del panel intermitentes en algunas secciones.
Línea temporal
| Cuándo | Fase | Qué ocurrió |
|---|---|---|
| 21 abr · tarde | Antecedente | Una operación analítica puntual deja a la plataforma con menos margen del habitual. |
| 22 abr · tarde temprana | Inicio impacto | El componente afectado deja de aceptar escrituras. Comienzan a acumularse llamadas sin progresar. |
| 22 abr · tarde | Detección y decisión | El equipo identifica el bloqueo y decide acelerar la migración estructural ya planificada. |
| 22 abr · tarde-noche | Conmutación | Conmutación del tráfico a la nueva plataforma de datos, con copia de seguridad previa. |
| 22 abr · noche | Servicio normalizado | Las llamadas vuelven a ejecutarse y a registrarse con normalidad. |
| 23 abr · mañana | Estabilización | Despliegue de correcciones residuales y reconciliación de llamadas heredadas. |
| 23 abr · mediodía | Validación y mejora | Pruebas de carga sobre la nueva plataforma y refuerzos de capacidad. |
Alcance e impacto real
Llamadas en curso
Un subconjunto de llamadas en curso quedó bloqueado a mitad de proceso. Todas fueron identificadas y reconciliadas posteriormente, sin pérdida de grabación ni transcripción.
Llamadas en cola
Las llamadas en cola que no llegaron a ejecutarse durante la ventana de impacto se cancelaron de forma controlada. Pueden reprogramarse con normalidad.
Panel y APIs
El listado de llamadas del panel quedó intermitentemente vacío. Otras vistas y las APIs públicas siguieron respondiendo, con mayor latencia durante el pico.
Lo que NO ocurrió
- No hubo pérdida de datos persistidos.
- No se vieron comprometidas credenciales ni datos personales.
- Las grabaciones y transcripciones existentes están íntegras.
- La integración telefónica no se vio afectada.
Lo que hemos hecho desde entonces
Trabajo completado en las 24 horas posteriores. Cada medida ataca un nivel distinto: arquitectura, disponibilidad, observabilidad y capacidad.
Nueva plataforma de datos
ArquitecturaHemos completado la migración a una plataforma de datos gestionada, alineada con el patrón real de uso de la aplicación. Es la única medida que ataca la causa raíz; el resto son refuerzos.
Replicación entre zonas
Alta disponibilidadLa nueva plataforma está replicada de forma sincronizada en varias zonas físicas, con recuperación automática ante el fallo de una de ellas y sin pérdida de información confirmada.
Copias de seguridad y protección
ResilienciaCopias automáticas diarias con retención prolongada, copias adicionales antes de cada cambio significativo y protección contra borrados accidentales activada.
Diagnóstico continuo
ObservabilidadActivadas herramientas de monitorización profunda que permiten detectar anomalías de carga antes de que se conviertan en incidentes y diagnosticar problemas en minutos, no en horas.
Ampliación de recursos
CapacidadHemos aumentado de forma significativa los recursos de cómputo, almacenamiento y velocidad de lectura/escritura para cubrir varias veces nuestro pico de tráfico actual con margen.
Optimización de búsquedas
PerformanceMejoras específicas en las consultas más frecuentes del panel, reduciendo de forma muy notable los tiempos de respuesta sobre conjuntos grandes de llamadas.
Gestión de credenciales
HigieneCentralización y separación por nivel de privilegio de las credenciales internas, eliminando focos sensibles en sistemas intermedios.
Endurecimiento del código
AplicaciónCorregidos varios casos límite descubiertos durante la conmutación, incluyendo normalización horaria y reconciliación de datos heredados.
Validación con pruebas de carga
Tras la estabilización ejecutamos una simulación de carga sintética contra la nueva plataforma en horario de baja actividad. La prueba identificó el siguiente cuello de botella —relacionado con la velocidad del almacenamiento— antes de que el tráfico real lo encontrase, y nos permitió corregirlo de forma proactiva. La nueva configuración cubre con margen nuestro pico operativo actual y deja un techo de crecimiento claro.
Próximos pasos y compromisos
Capacidad
Repetiremos pruebas de carga periódicas para validar el comportamiento sostenido por encima de nuestro pico actual.
Observabilidad
Despliegue de alertas proactivas sobre las señales que esta incidencia nos ha enseñado a vigilar.
Comunicación
Mantendremos a los clientes informados de forma transparente ante cualquier degradación, con tiempos de detección y resolución medidos.
Nuestro compromiso
Sabemos que la fiabilidad de la plataforma es una promesa que hacemos a cada cliente. Esta incidencia ha sido la oportunidad de ejecutar de golpe una mejora estructural que ya teníamos en marcha, y de salir con un sistema más sólido del que teníamos antes. Quedamos a disposición de cualquier cliente afectado para revisar su caso a través de nuestros canales habituales de soporte.
Equipo de Ingeniería de Meetzy
Comprometidos con la fiabilidad de la plataforma y la transparencia con nuestros clientes.