Royal Pingdom ha pasado revista a los veinte sitios de Internet más importantes según Alexa, y ha medido el tiempo que han estado caídos en lo que llevamos de año 2007, y los resultados son muy interesantes. El mejor ha sido Yahoo!, con simplemente el mejor resultado que se puede tener: cero minutos de caída, nada de nada, todo funcionando como un reloj todo el tiempo. Tras él, sitios como AOL o Comcast con tres minutos totales de caída, eBay con seis, Google con siete, y así hasta llegar a los peores, dos propiedades de Google: Youtube.com, con cuatro horas cuarenta y cuatro minutos, y Blogger.com, con cuatro horas cuarenta y siete. Por el medio, sitios como la Wikipedia, con dos horas y veintitres minutos de caída, o los sitios de Microsoft: sólo trece minutos para Microsoft.com, dos horas cuarenta y cinco para MSN, mientras Live estuvo «dead» un total de una hora cuarenta y ocho minutos.
La siguiente reflexión interesante sería una que hacía yo en una clase hace no mucho: el coste del downtime: ¿cuánto pierde eBay, por ejemplo, en una hora de caída, con todas esas subastas afectadas, con gente siendo incapaz de pujar o de cerrar las pujas? ¿Cuánto en términos de negocio o lucro cesante? ¿Cuánto en términos de confianza? ¿Y Google, por todos esos adwords que se dejan de clicar o esa agenda que no te deja actualizar? Está claro que en los tiempos que corren y con cada vez más personas confiando sus datos a la web, en la fiabilidad de un servidor van mucho más que las simples transacciones que se dejan de hacer.
Muy buen artículo.
El tema del coste del «downtime» siempre ha sido un excelente argumento de venta para vender clusters de máquinas. Ahora bien, conseguir los famosos 5 nueves de alta disponibilidad (5 minutos de downtime no planificado al año) cuesta un pastón tanto en máquina como en soporte.
No obstante aparte de los costes intrínsecos de la caída del servidor es cada día más importante la relación entre caída del servicio y caída de las acciones bursátiles.
Precisamente anoche y esta mañana Blogger ha tenido unas caídas majas. Ley de Murphy, justo cuando iba a escribir unos post en el blog. Un voto menos de confianza en Blogger. El 23 de Abril se acerca y con él WordPress 2.2 (creo que es ese día el previsto) y el nuevo script de importación de Blogger ;-).
Por otra parte, enhorabuena a Yahoo.
Trabajo en un fabricante, y efectivamente el coste del donwtime es uno de los argumentos que utilizamos para convencer al cliente de la necesidad de la «high availability» y la «full redundancy», que se traduce en comprar más equipos, y más cargados. Lo que pone a mis jefes y comerciales muy contentos.
Se pueden conseguir cifras de disponibilidad superiores al 99,999%, pero pagando mucho. Afortunadamente el caso de negocio se explica por sí mismo: si el coste del tiempo de caída que se pretende eliminar es superior a la inversión extra necesaria.
Ojalá todos los casos de negocio fueran así de evidente.
Estoy totalmente de acuerdo contigo, pero sin necesidad de recurrir a las caídas de los servidores de grandes webs… ¿a quién no le ha pasado que se le ha caido el servidor en la empresa y se ha quedado horas con cara de poker?
Ya no digo si dispones de herramientas que «atacan» a ese servidor, tipo business objects o cosas así…
la sensación de inutilidad y frustración que te generan serían dignas de un estudio psicológico… o acaso es la sensación de abandono por no disponer del correo electrónico???
Jesús Menéndez tiene toda la razón.
El coste esta en relación a la inversión necesaria.
Las estadisiticas que ofreces tienen que ver mucho con esos ratios.
La perdida de eBay, lucro cesante, se pone en relación a los costes y al nivel de criticidad. El tiempo de recuperación se cruza con el coste asumible y de ahí salen los tiempos que puedo asumir de parada no programada.
En empresas tan grandes, MSN, por ejemplo, pueden asumir esos cortes, sin duda. En el blogger también. No hay criticidad de datos.
Lo físico se cruza con lo virtual y nos dice que tenemos los pies de barro.
Enrique, no se si te comente esto en el IE, pero hay otro factor a considerar en la ecuacion que seria el saber lo que se esta dispuesto a tolerar en caso de picos.
El caso mas concreto que recuerdo fue cuando el concierto de U2 el 2005, se suponia que iba a ser posible la venta de entradas online, pero a efectos practicos el servidor de ticktackticket nunca estuvo disponible en ninguno de los dias de venta. Al principio pense que era falta de prevision para poder gestionar la demanda, pero como decian algunos igual no les compensaba el gasto para dar soporte a ese trafico, y claro podian vivir (privilegios de la exclusividad) 3 dias sin vender las entradas para sus otros eventos.
Como de costumbre el pagano es el usuario que contaba con comprar online.
Por cierto, ¿alguien sabe cómo se miden a priori el porcentaje de disponibilidad? A posteriori es fácil, está claro.
El porcentaje de disponibilidad, en mis tiempos de trabajo en un fabricante de 2 letras nunca ha estado del todo claro. Generalmente el concepto de «fiabilidad» es un concepto más bien tipo Hardware, de componentes, de hecho para calcular el tiempo de disponibilidad de un sistema compuesto por varios componentes tales como fuente de alimentación, disco, CPUs, etc, etc, se calcula mediante fórmulas a partir del MTBF (Mean Time between Failures) o tiempo medio entre fallos y luego está el MTTR (Mean Time to Repair). Yo me pasaba la vida pidiendo MTBF de discos.
aqui tienes la relación entre estas cifras y la disponibilidad.
http://www.eventhelix.com/RealtimeMantra/FaultHandling/reliability_availability_basics.htm
Gracias Kiki. Sí, ya conocía los conceptos de MTTR y MTBF. De hecho creo que recordar que existe un MTBF «teórico» (que da el fabricante en el momento del lanzamiento del producto, fruto de sus pruebas previas) y un MTBF «real», cuando ya hay una base instalada en un tiempo suficientemente largo como para tener un valor observable.
Mi duda viene del cálculo total de la disponibilidad: a la fiabilidad del hardware hay que añadir la fiabilidad de los enlaces (que supongo que vendrán dados por el SLA de la operadora), los tiempos de convergencia al componente o enlace redundante y demás.
En fin, que siempre me ha parecido que el valor de la disponibilidad (a priori) es meramente estimativo, que no es fiable, y que es un intento de darle un valor cuantitativo a una propiedad que en realidad es cualitativa.
#9 efectivamente Jesús, la idea en alta disponibilidad es siempre identificar SPOF (simples puntos de fallos en la estructura) y duplicarlos o tripicarlos en paralelo, caso fuentes de alimentación, discos, etc. Realmente salvo casos de empresas de ingeniería que sí están muy acostumbrados a estos modelos de fiabilidad, el resto de los clientes lo que pueden pedir a priori es el MTBF de algún componente como mucho.
En cuanto al tema de software, ya sabes usar sistemas de alta disponibilidad que paquetizan la aplicación y la mueven de un servidor a otro, virtualización ,etc.
Como siempre la mejor estrategia de venta de alta disponibilidad es acojonar al cliente con historias de desastres :).
Yahoo es una referencia principal para FreeBSD, que presume de ser un sistema operativo que no se cae (y emparentado con MacOS X por medio de Darwin).