Recuerdo estas mismas fechas del año pasado. Fue uno de los momentos más complicados de la vida de la empresa. Y ahora, un año después, me apetece hacer reflexión y análisis sobre lo que pasó antes, durante y después de aquél desastre.
1) Antes del desastre:
Noviembre de 2011. En Logocomunica (ahora kuombo), estábamos en pleno proceso de crecimiento. Hacía pocos meses que se había hecho una fuerte ampliación de capital y se había dado cabida a nuevos socios.
Mucha ilusión, muchas ganas de crecer, y sobre todo muchas ganas de compartir todas esas experiencias con el equipo y los clientes. Se idearon nuevos proyectos y se contrató a nuevos profesionales para esa nueva etapa. Incluso estuvimos valorando la posibilidad de cambiarnos de oficinas a unas más grandes porque ya no cabíamos.
Pero todo aquello estuvo a punto de irse al traste porque tomé una decisión equivocada, mal ejecutada y en el momento menos apropiado.
Estábamos buscando la forma de mejorar nuestros servidores para tener una estructura tecnológica más segura y escalable. Sabíamos que el crecimiento que estábamos experimentando requería un cambio en la forma de gestionar las máquinas en las que se alojan los ecommerce de nuestros clientes. Así pues, buscando opciones, dimos con un proveedor de Valencia que nos prometió un sistema en cloud global que, a priori, nos daba la suficiente confianza como para ejecutar correctamente el cambio.
¿Mi primer gran error? Confiar en la palabra de las personas, sin pedir referencias reales y actuales sobre el trabajo de dicha empresa.
Cerramos un acuerdo para la migración y nos pusimos manos a la obra inmediatamente con todo. ¿Segundo gran error? Hacerlo todo de golpe sin un plan de contingencia adecuado. Nuevamente exceso de confianza en que el proveedor tendría todo previsto.
En menos de una semana estaba todo migrado y empezamos a comunicarlo a los cuatro vientos. Teníamos mucha ilusión con el cambio y lo hicimos con la mejor voluntad del mundo y pensando en los clientes y en la seguridad de la información. ¿Tercer gran error? Vender la piel del oso antes de cazarlo.
2) Durante el desastre:
Algunas pequeñas caídas después de la migración me hicieron sospechar que algo no iba bien. ¿Cuarto gran error? Volver a confiar en palabras del estilo “estamos ajustando el sistema, es normal” y no actuar rápido revocando el cambio y volviendo al punto de partida.
Día 24 de diciembre, recién abierta la oficina por la mañana y con muchas ganas de que el día fuese genial para acabar el año (la última semana de diciembre la solemos tomar de vacaciones), nos encontramos con que nuestro correo electrónico y nuestra web y nuestros blogs no funcionaban. Se acababa de caer el servicio de una máquina, y las sospechas de que aquello no tenía buena pinta iban a confirmarse en forma de desastre total al ver que lo que se había caído eran todos los servidores. Todos los nuestros y todos los de nuestros clientes por el suelo, nada funcionaba y no había una explicación clara por parte del proveedor.
Imagínate, todas las campañas de navidad activas, mailings de felicitación y de promociones enviados, redes sociales a tope generando tráfico, pero todas las tiendas online en el suelo y sin esperanza de poder ser levantadas con prontitud.
Inmediatamente se empezaron a suceder las llamadas, una tras otra, de clientes preguntando lo que estaba pasando y queriendo saber el motivo de que sus tiendas online no estuvieran operativas.
Fue el día de Noche Buena más angustioso de toda mi experiencia en esta empresa y lo pasé casi entero en el centro de datos, con el proveedor y con mi compañero Diego, intentando ver las opciones para levantar aquel desastre. Horas y horas de desesperación intentando averiguar los motivos de la caída e intentando encontrar un plan B para estabilizar el servicio de los clientes.
Al final conseguimos parchearlo para levantar varias máquinas, replicándolas en otros sitios, y por lo menos salvar lo más importante y dejar a los clientes operativos.
Durante aquellas navidades las caídas eran constantes, varios compañeros de Logocomunica estuvimos más pendientes de los servidores que de la familia. Y yo estuve atendiendo personalmente más llamadas de clientes enfadados (con motivo) que de amigos felicitándonos las fiestas.
Así que no se puede decir que el año empezase bien que digamos, pero por lo menos el problema gordo parecía resuelto.
3) Después del desastre:
Pero como todo lo malo puede ir a peor, durante el primer trimestre del año dichas caídas seguían sucediéndose, de manera intermitente pero molesta, en todos los servidores. Lo cual incrementó considerablemente el cabreo de los clientes, hasta el punto de perder más de la mitad de la cartera. ¿Quinto error? No haber sacado todo de allí en el primer momento y haber vuelto a confiar en que era una situación fortuita y aislada que habíamos tenido la mala pata de que nos hubiera tocado a nosotros.
La caída de ingresos, al perder tantos clientes de golpe, es grave, pero más lo es aún cuando coincide con que has contratado gente nueva para nuevos proyectos y por tanto han aumentado los costes de la empresa considerablemente. Y reconozco que mi ansiedad me llevó a un nefasto estado anímico que perjudicó mi gestión y trasladó al equipo emociones negativas. Llegó un momento en el que el barco no aguantó y fue directo a la deriva estando a punto de naufragar.
Teníamos los gastos muy por encima de los ingresos, con el problema tecnológico sin resolver y sin entrada de nuevo negocio. En una empresa de servicios como la nuestra las nóminas son el principal gasto, y tuve que hacer una de las cosas más duras a las que un empresario se enfrenta. No tuve otra salida que bloquear las nóminas de los socios y despedir a parte del equipo para equilibrar la estructura financiera y garantizar la continuidad de la empresa. Pero si es difícil tomar esa decisión, aún lo es más decidir quienes van a ser las personas que tienen que abandonar el barco. En ese momento yo me sentí verdugo, pero tuve que hacerlo. Creo que solo el que ha vivido algo así puede comprenderlo.
A partir de ese instante empezó una nueva etapa en la empresa. Me di cuenta de que nunca te puedes dormir, nunca puedes pensar que todo está hecho o todo va bien, nunca puedes bajar la guardia porque el desastre se esconde a la vuelta de la esquina y por el motivo menos esperado.
Una vez estabilizada la estructura financiera nos pudimos centrar en resolver el problema tecnológico. Se buscó con mucho esmero el proveedor adecuado a nuestras necesidades y a las de nuestros clientes. Se cambió la metodología de trabajo, la forma de implantar la tecnología en los diferentes proyectos y se cuidó mucho de establecer los acuerdos oportunos con el socio tecnológico.
A veces no hay proveedor malo si no mal elegido o mal gestionado.
Esta situación nos sirvió para replantearnos todo lo que estábamos haciendo, analizar nuestro pasado, reflexionar sobre nuestro presente y visualizar nuestro futuro. Entendimos que para una tienda online, que necesita estar 100% disponible todo el tiempo, no se debía escatimar con los costes de servidor, independientemente del tamaño de la tienda. Esto condicionaba el tipo de cliente con el que podíamos trabajar y el tipo de servicio que debíamos ofrecer.
Descubrimos a qué perfil de cliente aportamos más valor y nos pusimos manos a la obra en trabajar para él. Se fortaleció la relación con los clientes que quedaron y nos mostraron su apoyo incondicional para seguir adelante.
También descubrí la implicación de los compañeros, mucho mayor de todo lo que cabía esperar, que se hicieron cargo de la situación y lo dieron todo para reconducir de nuevo la empresa.
Hoy, un año después de aquello, la empresa ha vuelto a crecer, tanto en clientes, como en volumen de facturación, calidad de servicio, y en equipo. Nuestra infraestructura tecnológica es mucho más cara, pero mucho más estable. Nuestro actual socio tecnológico ha demostrado que su implicación es la que esperamos y hemos diseñado un método de trabajo en el que no cabe la posibilidad de un desastre en cadena similar al del año pasado.
Hoy, un año después y gracias a aquel desastre y al apoyo de los clientes, compañeros y amigos, hemos mejorado, hemos aprendido, y hasta hemos cambiado de nombre para adaptarnos a los nuevos tiempos.
Hoy, un año después de todo aquello hemos pasado unas navidades tranquilas, con todo bajo control y estable.
Hoy, un año después, necesito volver a pedir las más sinceras disculpas a los que se vieron afectados por aquél problema y quiero volver a dar las gracias a todos los que nos ayudaron a solucionarlo.
El riesgo está en cada decisión que se toma.
Después de esto aquí están mis propósitos para 2013 🙂
Miguel, totalmente de acuerdo pero tus necesidades son diferentes que las mías.
Vosotros sois una empresa con muchos proyectos propios. Entiendo la integración, el cloud y el ahorro de costes.
En nuestro caso tenemos un proyecto para cada cliente y preferimos que el hosting lo asuma cada cliente aunque se lo facilitemos y gestionemos nosotros. Lo que un cliente necesite en servidores no debe influir a los demás.
Hola Javier,
dejando a un lado el aspecto humano y el trato del proveedor en primer lugar comentarte que hasta en las “mejores familias” (como por ejemplo le ha ocurrido a Amazon Web Services un par de veces) los sistemas fallan.
El problema en estos casos es que hay que sopesar cuánto cuesta el montar una infraestructura que sea tolerante a fallos VS el coste que supone el perder el servicio en determinados momentos si un fallo de cualquier tipo ocurre y deja de ser accesible. Si podéis asumirlo económicamente os aconsejaría mirar el servicio de Amazon Elastic Load Balancing, con el que podéis tener en dos zonas de disponibilidad simultáneas vuestro servicio, con lo que si cae una siempre está disponible la otra. Y para bases de datos Amazon RDS en modo Multi A-Z. Como os comento quizá puede subir un poco de precio, por tanto hay que evaluar si merece la pena o no.
Dado mi perfil más técnico he echado de menos en este artículo un poco más de explicación en detalle sobre qué problemas se produjeron en los servidores, si pudieras dar algún detalle más sería interesante.
Un saludo
Hola Luis, gracias por el debate en Twitter y por tu comentario.
Entiendo tu punto de vista. Yo no discuto si cloud es mejor o peor.
Solo digo que en mi caso cada proyecto es de un cliente y por tanto cada cliente paga su servidor.
Mi modelo de negocio no vive de vender hosting porque no soy una empresa de hosting. Pero necesitamos una seguridad en los servidores.
Como nuestro tipo de cliente es de un cierto tamaño y como mínimo necesita un dedicado, a cada uno se le pone una máquina que paga él y que por lo tanto le da plena libertad para hacer con ella lo que quiera.
Cuando un cliente determinado tiene que crecer se estudia dicho crecimiento con el proveedor y nosotros le facilitamos la gestión pero no ganamos dinero con ella ni somos los prestadores de servicio ni los que asumimos la responsabilidad 🙂
Menos riesgo y mejor calidad de trabajo centrándonos en nuestro core, la estrategia, el desarrollo y la conversión 🙂
Daniel, ese es el problema, que nunca se nos dio una explicación técnica convincente. Muchas teorías con muchas propuestas de solución que nunca terminaban de arreglar el problema. No hablo de una caída puntual si no de paradas de servicio de bastante tiempo y diarias en TODOS los magentos.
Al final se sacó una de las máquinas para probar en el nuevo proveedor montándolo en un dedicado y se terminaron las caídas.
Una vez probado y testado se sacó todo lo demás y se terminaron las caídas para siempre.
No puedo darte más detalles técnicos puesto que no soy de sistemas pero ni siquiera mi propio equipo técnico pudo encontrar el problema 🙂
Hola! Tras el debate en Twitter, me animo a dejarte mi impresión por aquí. 🙂
Yo creo que estamos mezclando cosas, y eso no es del todo bueno, ya que un análisis parcial o sesgado puede ser peor que no hacerlo. Vaya por delante el hecho de que cada caso concreto debe ser analizado y esto no puede ser más que una regla general y, como tal, expuesta a excepciones.
En primer lugar, lo que puedo deducir es que hubo un exceso de confianza. Y en un caso concreto —sin saber exactamente lo ocurrido— el sistema falló. Esto no quiere decir que la tecnología Cloud para hosting web sea mala, ni mucho menos. De hecho todo lo contrario, bien implementada, es posiblemente la mejor.
La solución adoptada ahora —de un dedicado por proyecto— es altamente ineficiente. Por un lado, es posible que tengas mucho hardware rindiendo por debajo de sus posibilidades reales, lo que se traduce en un pérdida de euros. Es como comprar un trailer por si un día al año tengo que hacer una mudanza, o tener en plantilla 20 diseñadores porque un día al año tengo que hacer 20 felicitaciones navideñas. Ineficiente.
Por otro lado, tampoco estás seguro y cubierto al 100% ya que una web montada con PHP/MySQL corriendo sobre Apache Web Server que por cualquier motivo —un pico de visitas simultáneas inesperadas, un commit de un desarrollador, un sistema de ficheros que se corrompe, etc…— sufra una saturación del WebServer hará que te quedes sin web durante horas o más, con la consecuente pérdida de ingresos.
En resumen, para tener un sistema de alta disponibilidad no puedes, nunca, confiar todo a una sola máquina. Debe haber redundancia. Y esto no lo consigues con un sólo dedicado. Como el juego que os proponía en Twitter, si estuvieras conectado a un sistema que tuviera que responder, sin error, una petición http cada cierto tiempo para mantenerte con vida, lo apostarías todo a un solo dedicado? Yo no. Me aseguraría de que en caso de fallo, hubiera otra levantada lo antes posible, y esto no lo consigues con un sólo dedicado.
Bien montado, el Cloud es mejor. Ahora, hay cada cosa por ahí que… 😉
Muchas gracias. Un placer charlar con vosotros.
P.S.: El SEO de esta entrada va de gratis. 😉