La noche que se nos cayó el sistema

Un domingo de febrero, en medio de la campaña de un cliente, nuestro sistema dejó de responder. No fue un parpadeo: fue una noche entera. Publicamos esto porque los casos que salen bien los muestra cualquiera, y lo que de verdad dice algo de un proveedor es qué hace la noche que se rompe.

Lo que pasó

El cliente mandó una campaña masiva por WhatsApp. La gente empezó a responder toda junta, como pasa siempre, y ahí el sistema se traba: unas 3.500 conversaciones entrando casi al mismo tiempo. A media tarde todo iba bien. A las ocho de la noche, el agente dejó de contestar.

Lo incómodo del caso, y la parte que más nos dolió, es que no fue un problema de tamaño. El servidor tenía capacidad de sobra, casi sin usar, mientras todo se venía abajo. Era un error nuestro de diseño: había una parte del código que, cuando se ponía a trabajar, no atendía a nadie más hasta terminar. Con poca gente eso no se nota. Con mucha gente al mismo tiempo, tapa todo.

Lo que hicimos esa noche

Nos quedamos. De las 20:00 a las 00:36 estuvimos arreglando en vivo, con el cliente al tanto de lo que estaba pasando en cada momento. No fue un solo problema: fue uno atrás de otro, porque cada arreglo destapaba el siguiente cuello de botella.

No hay heroísmo en esto. Una noche de guardia es la consecuencia de algo que se podría haber previsto, no un mérito. Pero sí hay una decisión: cuando el problema es tuyo, te quedás hasta que esté resuelto. No se deriva, no se minimiza y no se deja para el lunes.

El día después

Lo de esa noche fue contención. El trabajo real vino al día siguiente, y es el que importa: en vez de poner un parche y seguir, paramos a revisar el sistema entero buscando el mismo tipo de error en todos lados. Aparecieron siete puntos distintos con la misma clase de problema.

• Nada que sea urgente espera a algo que no lo es. El sistema frenaba la respuesta al usuario para terminar de guardar registros internos que podían esperar. Eso se separó.
• Lo que hay que compartir, se comparte de verdad. Había información viviendo dentro de un solo proceso, lo que hacía imposible repartir el trabajo entre varias máquinas. Se movió a un lugar común.
• Límites explícitos. Se definieron topes claros para que un pico inesperado haga que el sistema vaya más lento, en vez de tirarlo abajo. Degradar es aceptable, caerse no.
• Más capacidad, pero al final. Se multiplicó por seis la capacidad de atención simultánea, y esto fue lo último a propósito: agrandar el servidor antes de arreglar el defecto solo hubiera comprado unos minutos.

Qué aprendimos

La lección no fue técnica. Ninguno de los siete problemas era difícil de arreglar: casi todos fueron cambios chicos. Eran difíciles de ver, porque con poco tráfico el sistema funcionaba perfecto. Un defecto que solo aparece cuando hay mucha gente a la vez es invisible hasta el día que hay mucha gente a la vez.

Lo que faltaba no era conocimiento, era método: nadie había probado el sistema contra el volumen que iba a recibir. Eso es lo que cambiamos. Hoy, antes de cada envío masivo, estimamos cuánta gente va a responder al mismo tiempo, probamos contra ese número y ajustamos los límites. El envío siguiente fue de 60.000 mensajes, casi veinte veces el que nos había tumbado, y no hubo noche.

El otro aprendizaje fue sobre el aviso. Un problema que el cliente descubre antes que vos es un problema doble: el técnico y el de confianza. Parte de lo que cambiamos después de esa noche fue cómo miramos el sistema, para enterarnos primero nosotros.

Cómo quedó el sistema

El mismo sistema que se cayó esa noche hoy sostiene picos de cuatro a cinco veces ese volumen. Para dar una medida concreta y no una promesa: en un lapso de 26 días, la cuenta de uno de nuestros clientes procesó 27.897 conversaciones, de las cuales la IA resolvió sola el 93,3%, con un tiempo de respuesta promedio de 32 segundos. Sin noches de guardia.

Por qué contamos esto

Podríamos no haberlo publicado. Nadie de afuera lo sabía salvo el cliente que lo vivió con nosotros. Pero si vas a confiarle a alguien la atención de tus clientes, mereces saber cómo se comporta ese alguien el día que algo sale mal, y no solo cuando todo funciona.

Nadie que opere sistemas de verdad puede prometerte que nunca va a fallar nada. Lo que sí se puede prometer es qué pasa después: que te enterás por nosotros, que nos quedamos hasta resolverlo, y que el arreglo no es un parche sino una revisión de todo lo que tenía el mismo defecto.

Si estás evaluando con quién construir, mirá cómo trabajamos y cómo cotizamos por módulos