Crónica de un downtime anunciado

Esta es la historia del señor A. Es algo que me ha ocurrido hace poco y me parecía interesante explicarlo. Podría hablar sobre que ISO ha rechazado el OOXML para ser aprobado por la vía rápida, pero bueno, solo hay que esperar que lo sea por la vía lenta. Así que me parece que esto es más jugoso.

Hace un par de años el señor A no quería saber nada de Internet, eso no era para él; pero un buen día, vió que la competencia empezaba a moverse y había un negocio emergente: quería parte del pastel.

Así que contactó con el señor B, que le había dicho mil veces que montara una web decente y unas cuantas cosas más pero el señor A siempre le daba largas. Le explicó el negocio, que tenían ya un proveedor, que iban a comprar las máquinas y necesitaban una intranet para atarlos a todos en las tinieblas.

No empezó a lo grande sino con cautela y la cosa no fue mal. Compraron un servidor de juguete para empezar pero al año se les quedó bastante corto. Eso sí, hasta que no empezó a dar problemas graves como quedarse sin espacio o sin ancho de banda no reaccionaron. En definitiva, se puso una máquina mejor, pero sin grandes gastos: la versión MSDE de SQL Server, craso error, aunque en ese momento aun no lo sospechábamos.

Pasó el tiempo y llegó septiembre, una buena época para su negocio. Ya en navidades hubo algún aviso, con saturación del SQL por exceso del número de consultas, que en su versión gratuita vienen limitadas al ridículo número de 8 simultáneas. Se perdió algún pedido pero tampoco fue para tanto. Tras descubrir el motivo, aun en enero se sugirió comprar otro servidor o por lo menos una licencia de SQL 2005.

El señor A dijo que no era para tanto, que si iba lento era porque había muchos pedidos por lo que se archivaron los que tenían más de 6 meses. Bien, una medida barata pero de dudosa eficacia. Se invirtió tiempo en hacer un remiendo para un problema que estaba ahí. Quizás el señor B no insistió bastante en la importancia del asunto, pero con el dinero que estaba ganando el señor A, un servidor nuevo era calderilla.

El tiempo pasó y se acercaba septiembre. A finales de agosto la cosa empeoró ya, con unos buenos downtimes de SQL (por exceso de concurrencia), saturación del ancho de banda del sistema (los clientes tienen que subir gran cantidad de datos, es una característica de este servicio). Eso provocó las quejas de numerosos clientes y la pérdida de muchos pedidos que quedaban a medias. Ahí sonó la voz de alarma.

Desde julio estaba listo el nuevo servidor, pero bueno, venían las vacaciones y nadie tenía ganas de marrones en aquel momento. Resumiendo: el sistema se dejó a su suerte ya que con el parón veraniego la cosa iba bastante bien. Entonces nos plantamos en la última semana de agosto, cuando estaban los señores A y B de vacaciones: me llamaron durante toda la semana por problemas variados, siendo lo más grave que durante los periodos de saturación del SQL Server por exceso de consultas se pagaban transacciones que luego no tenían pedido reflejado.

Esto último la verdad es que es bastante mosqueante y hay protecciones para que tal cosa no ocurra pero al parecer, durante algunos instantes los datos ‘existen’ desde el punto de vista del servidor de base de datos o al menos las comprobaciones que se hacen son positivas. El cualquier caso el objetivo era conseguir que no fallase la base de datos nunca más.

La final llegó septiembre y con él los señores A y B. El señor A estaba nervioso y no era para menos porque cada tarde la base de datos estaba saturándose y perdían clientes. Por si no fuera poco, durante el fin de semana se quedó el servidor sin espacio por la cantidad de datos que subieron los usuarios y durante lunes y martes el tráfico era tan elevado que ni siquiera podíamos acceder a gestionar el servidor.

Al final: instalación de emergencia en el servidor nuevo. En menos de 24h montamos todo, copiamos todo, probamos todo y lo pusimos en marcha con 1h de retraso sobre la previsión. Ahora tienen 300Gb de disco, un SQL Server decente y una máquina con recursos de sobra, como tiene que ser. Además, las transferencias se siguen haciendo al servidor anterior de modo que ya no saturan la Intranet y todo parece que va como la seda.

En fin, fue un día estresante pero al final salió todo bien, solamente un problema con el objeto XMLHttpRequest y el método send, que daba un error de ‘Permiso denegado’. Leyendo información de Microsoft incluso pudimos aclarar algo y al final todo fue bien.

En resumen, que tuvimos suerte que las cosas han funcionado a la primera (bueno, hubo otro problema que comentaré otro día) pero ha sido una lástima que se haya tenido que hacer esto a toda prisa cuando ha habido tiempo de sobra para hacer las cosas y el señor A ha perdido un montón de dinero teniendo el sistema 4 o 5 días por los suelos. Pero bueno, en cierto modo lo tenían merecido.

Ya llamó el señor A para decir que todo iba mucho mejor y el señor B debería estar mucho más contento de lo que está. Seguro que hay una próxima vez.

Si te ha gustado esta entrada, por favor deja un comentario o suscríbete al RSS para que puedas recibir todas las novedades en tu lector de feeds favorito.
This entry was posted in Programación and tagged , , , . Bookmark the permalink.

2 Responses to "Crónica de un downtime anunciado"

Leave a reply