Suena contraintuitivo, pero puede que no lo sea tanto: un estudio demuestra que un plan de mantenimiento preventivo demasiado habitual convierte los datacenters no en más fiables como cabría esperar, sino en menos (vía Slashdot).
Parece ser que una cantidad no despreciable de los problemas de caídas en datacenters tienen que ver con errores humanos surgidos durante las operaciones de mantenimiento. Procesos supuestamente preventivos, conflictos entre procesos manuales y automáticos, y superposiciones de agendas de mantenimiento recomendadas por fabricantes de componentes. son, aparentemente, las mayores causas de caídas en este tipo de instalaciones. Los planes de mantenimiento son un negocio muy importante para muchos vendedores de equipos, lo que podría llevarlos a intentar imponer agendas excesivas que en ocasiones llegan a comprometer la estabilidad del datacenter. En muchos casos, las máquinas funcionan mejor si las dejamos solas, sin demasiados humanos cerca susceptibles de olvidarse cosas. Más mantenimiento no es siempre mejor: como en todo, la virtud está en el término medio.
Un estudio que tiene mucho sentido para mí precisamente hoy: esta página estuvo caída durante casi toda la noche de ayer, parece ser que debido a un problema derivado de un proceso de mantenimiento. Durante el último mes han sido tres caídas, una estadística mucho peor de lo habitual. Mis disculpas a los que hayan intentado entrar en la página y la hayan encontrado caída, especialmente a mis lectores de Latinoamérica, los más numerosos a las horas en que tuvieron lugar las dos caídas más prolongadas. Espero que los porcentajes de uptime vuelvan a sus niveles habituales próximamente.
Pues yo, ni enterarme.
La pregunta sería ¿Cuantas caídas habría de haber realizado esos mantenimientos preventivos?
Poniendo la balanza riesgo recompensa no creo que sea rentable reducir los mantenimientos, pero quizás deberían de plantearse el automatizar ciertos procesos para evitar errores operativos.
#001: Pues han sido tres, nada menos. El día 13 de este mes, un problema de un plugin mal actualizado posibilitó un ataque que dejó el servidor caído toda la mañana, desde las siete hasta las doce y media. Nos llevamos la página a otro sitio hasta identificar y aislar el problema, y estando en ese alojamiento provisional, una cuestión de mantenimiento mal hecha tiró la web el día 24 entre las tres y la siete de la mañana. Finalmente, esta mañana, otro problema provocó una caída que duró entre las tres y media y las diez y media. Tras eso, nos hemos vuelto ya a nuestra casita habitual en Acens, donde esperamos llevar una vida un poco más tranquila…
Yo tampoco me habia enterado, está claro que los que entramos por la tarde-noche no lo hemos notado. Suerte con las caidas en el futuro, y si logras evitarlas, ya sabremos el resto que hosting utilizar.
Yo creo que en mantenimiento de data centers está todo inventado. Es pura y exclusivamente un problema de coste / calidad. Un datacenter que no tenga caídas requiere unas políticas de mantenimiento y unas redundancias de infraestructura perfectamente estudiadas y, nos guste o no, es muy caro. Cuando se buscan atajos ocurre lo que ocurre, que son las caídas.
Aplicaciones de misión crítica con fiabilidad 99,9999999 hay muchas. Pero ninguna de ellas será barata.
De todas formas según mi experiencia, el lucro cesante de estas caídas accidentales, si no son muy prolongadas, es muy bajo. Es decir que cuando alguien tiene realmente deseos de entrar en una página, si esta caída durante un tiempo, suele volver a intentarlo despuès, y mucho más insiste si de lo que se trata es de hacer una trasaccion económica, como una operacion bancaria, o una compra. En este caso, lo habitual es que si no puedes hacerlo ahora, lo intentes más tarde.
Otra cosa es, si realmente no tenías especial interés en visitar el lugar y solo vayas a fisgar un poco a ver que te encuentras en él, en ese caso, con que solo vaya lento el sitio, no esperas, pero desde el punto de vista económico esas visitas son muy poco relevantes.
A mi el problema de la caida me preocupa menos (comparada con la del pelo), pero si me parece preocupante ese síntoma que indicas: exceso de mantenimiento…
La sociedad terrestre( hablo de aquellos de sus sectores que tienen un standing tecnológico considerable)tiende a favorecer el exceso de todo: información dirigida, limpieza corporal excesiva, basura en general también «dirigida», hambre en sectores desprotegidos…por que va a ser diferente a la hora de pensar en la producción industrial evitando «planificar» la obsolescencia garantizada y el mantenimiento ineficiente?…aparte, lógicamente, de que el ser humano es algo manazas cuando se empeña en serlo…
#6: Tienes razón pero ‘nunca dejes, aunque sea un poco, ese tráfico fresco que hace que tu web aumente de forma natural’.
Saludos.
Prueba Cloudflare (https://www.cloudflare.com/overview). Es gratis y mantiene tu sitio visible mientras tu servidor está caído, ademas de todas las otras ventajas de una CDN. (No tengo nada que ver con ellos aparte de ser un usuario contento).
Ajá, y quien «demuestra» eso es un tío de una empresa experta en valoración de riesgos enfocada a sistemas complejos, a eso le llamo yo un estudio independiente. Por cierto, no veo la «demostración» por ningún lado.
#009 yo uso cloudflare y también tiene caidas de cierta frecuencia.
El problema siempre reside en la complejidad de los sistemas, en la complejidad de su mantenimiento y en la complejidad de la PLANIFICACION de su mantenimiento.
Yo administro un cluster de supercomputación de 200 servidores (http://i3a.unizar.es), y la complejidad del sistema ha ido aumentando a medida que se han ido integrando tecnologías que mejoraban diversas partes del mismo … casi siempre haciendo que el sistema sea más complejo en relación a la cantidad de «piezas móviles» del mismo.
Si se llevan sistemas grandes, la aplicación de ITIL (http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library) al final acaba siendo necesaria (y muy beneficiosa).
Más complejidad en diseño suele implicar un mantenimiento más complejo: Si tocas una pieza en un sitio, es posible que rompas algo en otro. Es por ello por lo que sistemas de gestión del cambio (tener una CMDB bien diseñada y un sistema que permita rollbacks y administración centralizada) es fundamental. Estos sistemas son también críticos a la hora de planificar el mantenimiento (sabes lo que tocas, a qué afecta y puedes dar «marcha atrás). Si no tienes un sistema así montado la complejidad se te termina comiendo por los pies (a veces poquito a poco como las pirañas, a veces de un bocado en plan tiburón).
De lo contrario, la complejidad de todo el sistema se te come. Y te dejas cosas colgando. Y esas cosas son las que producen luego fallos que el usuario final ve.
Yo soy firme partidario del mantenimiento, porque en muchos casos puede ser proactivo y te permite darte cuenta de fallos antes de que se produzcan. O porque en caso de provocar un fallo estás delante del sistema y lo puedes arreglar al momento. O simplemente porque el hecho de «cacharrear» mucho con un sistema hace que tengas un «feeling» del mismo y puedas muchas veces de forma casi intuitiva saber qué pieza es la que te da problemas …
En conclusión: Mantenimiento sí, y todo el que sea necesario. Pero bien hecho.
Me ha resultado muy útil e instructivo, gracias.
#06 «Es decir que cuando alguien tiene realmente deseos de entrar en una página, si esta caída durante un tiempo, suele volver a intentarlo despuès, y mucho más insiste si de lo que se trata es de hacer una trasaccion económica, como una operacion bancaria, o una compra.»
Es verdad. Es como en el caso de la página de la RENFE que cierra por la noche y donde la gente que no ha podido entrar regresa por la mañana…
Pero hablando en serio me pregunto porque en estos casos no existe siempre, como norma, una estructura permanente alternativa, quizás mas liviana, y a donde se derive el tráfico que no puede acceder a la página caída.
#014 Columbo
¿En serio crees que alguien deja de viajar en Renfe porque una página para reservar billetes este caída a las 12 de la noche? El que tiene previsto viajar a Alicante en tren no cambia de proyecto por tan poco. ¿Has cambiado tu cuenta de banco porque hayas dado alguna vez con un cajero que no funciona?
Hacer un sistema de respaldo cuesta dinero y nunca da 100% de seguridad y siempre se mide si lo que vas a perder en una incidencia es mas o menos que lo que te cuesta mantener el sistema de respaldo que la evite. Siempre se elige un hosting con un umbral de funcionamiento marcado por contrato, si quieres un umbral más bajo tienes que pagar más. Y aun así no hay sistema seguro al 100%, a Dans no le funcionaba bien la lista de fuentes que usa y eso no era culpa del hosting
Llega un poco tarde, pero si creeis que mantener un CPD da problemas, probar a no mantenerlo…
En serio, puede haber algo de verdad en el estudio, pero este no entra en las personas y las estructuras (empresariales) que intervienen en el mantenimiento. Alguna vez hemos tenido que improvisar haciendo cosas que no debiamos hacer (aunque supieramos no era de nuestro departamento) porque la persona encargada estaba al otro lado del oceano y no tenia la experiencia necesaria para hacerla (ni sabia que la maquina que daba problemas existia).
Cadenas de subcontratacion de tres o cuatro niveles, plantillas con alta rotacion porque los precios del servicio cada vez bajan mas y la gente simplemente encuentra sitios donde le pagan mas, jornadas maratonianas (conozco a uno que un jueves llevaba dormidas tres horas esa semana), CPDs sin operadores in situ por las noches… Puede ser que las empresas que venden hard exageren con los mantenimientos para facturar mas, pero el que pone un CPD tiene que pagarlo, y un SLA no soluciona problemas, solo trata de indemnizaciones.
Hola Enrique,
Tengo curiosidad por saber de cuál proveedor de hosting se trata. Revisando por allí, me parece que es uno cuya inicial coincide con la de un popular buscador y que comenzó a operar hace poco. No sé si podrías confirmarme.
¡Éxitos con tu nuevo-antiguo proveedor! :)
No me di cuenta, pues siempre sigo el blog via Google reader y solo entro a la pagina si deseo comentar, lo que me hace preguntar ¿Porque Google reader no permite conectar directamente con los comentarios sin la necesidad de entrar a la pagina del blog?
Saludos,
#018: El ataque lo sufrí estando en Acens, no por culpa de ellos, sino de la falta de actualización de un plugin de WordPress. De ahí me fui a Gigas mientras terminábamos de entender lo que había pasado, y estando allí tuve dos caídas, una porque hicieron una intervención en sus sistemas para actualización de drivers y no me balancearon a un entorno que ofreciera continuidad (no me tenían etiquetado como cliente), y otra derivada de un balanceo entre máquinas que produjo una excepción al intentar montar el disco y que terminó con el disco en estado de solo lectura, por razones todavía desconocidas. Finalmente, tras haber reinstalado completamente el servidor y actualizado el plugin en Acens, nos volvimos a la situación inicial.
Muchas gracias por los detalles, Enrique.
Mas mantenimiento preventivo supone menos problemas y mas coste. La clave esta en encontrar el punto optimo de esa relacion ya que no es lineal, los primeros euros disminuyen el numero de problemas mas que los ultimos. Implicacion de coste numero 1.
Las politicas de mantenimiento son esenciales. Se corta el servicio a las doce de la noche que hay 100 usuarios o esperamos a las 3 a.m que hay dos y pagamos al señor de mantenimiento las horas extras? Implicacion de coste numero 2.
Los criterios de redundancia hacen mayor o menor el impacto del corte en una parte del sistema. Mas redundancia implica mas coste. Implicacion de coste numero 3
Tener mano de obra cualifiada y foco en calidad para tener procesos adecuados cuesta dinero. Implicacion de costes numero 4.
Siempre hay manazas o cisnes negros, claro, pero es la posicion que una empresa toma ante los puntos anteriores lo que determina el numero de problemas a largo plazo. Es lo que distingue a alguien serio de quien no lo es. Esto, perdoname Enrique, me parece el problema que has tenido en tu caso.
Muchas gracias por el aporte y por cierto totalmente de acuerdo con las aportaciones de PAK.