Cuando se trabaja en proyectos informáticos hay un valor conocido como el uptime o tiempo que un ordenador (o sistema, o sitio web en general) ha estado funcionando sin interrupciones. No estoy del todo seguro de cuál es la traducción más aceptada, pero podría ser «disponibilidad» (algún ingeniero que por favor me corrija). Para que se entienda mejor: conseguir un uptime alto es necesario en algunos proyectos y sistemas que requieren lo que se denomina «alta disponibilidad», que es ligeramente de estar construido «a prueba de fallos». Se puede pensar en los ordenadores de un avión, una torre de control, que necesitan un funcionamiento ininterrumpido y sin fallos. O, por hablar de algo con menos peligro para las vidas humanas, los sistemas de bancos, la Bolsa o un comercio en Internet, donde tener un sistema de pagos o una web caída significan pérdidas de ventas y de dinero.
Hay diversas técnicas para mejorar la disponibilidad de un sistema como utilizar redundancia, sistemas escalables, balanceos y otros inventos para evitar problemas, excesos de carga y fallos de diversos tipos y reducir así el tiempo en que un sistema está inactivo (también llamado downtime).
Hay geeks que disfrutan viendo altísimos datos de uptime (también es un comando de Unix) de su sistema operativo, incluso hay quien lo pone en su firma como señal de lo bien que funciona. El iBook en el que escribo esto marca ahora 3 días y medio de uptime. El otro día el servidor donde se aloja Microsiervos marcó 24 días de uptime y ciertamente dábamos palmas de alegría (por desgracia tuvimos que reiniciarlo para actualizar unas cosillas).
Normalmente se habla de uptime en porcentajes como técnica marketroide para impresionar en los folletos publicitarios. Un uptime del 99% quiere decir que a lo largo del tiempo el 99 por ciento del tiempo está funcionando y sólo un uno por ciento caído. Aunque un 99 por ciento parezca mucho, pensándolo mejor quiere decir que un ordenador que deje de funcionar unos tres o cuatro días al año tiene un uptime del 99% lo cual en muchas situaciones no es aceptable - ni para el ingeniero ni para quien usa el servicio, basta imaginar tu ordenador o línea de teléfono estropeada tres días al año.
En la industria se «añaden nueves» para hablar de sistemas con un uptime del 99,9% (tres nueves), del 99,99% (cuatro nueves), etc. A partir de cinco nueves (99,999%) se considera «alta disponibilidad». Seis nueves son un funcionamiento continuo con una caída de sólo tres segundos al año, y más allá casi está fuera del límite de la percepción humana. Esto ha dado lugar que a veces se hable del mito de los nueves como una exageración del márketing sin mucho sentido real. Encontré una anotación curiosa sobre esto y sobre algunas webs y servicios actuales:
What is 99% uptime anyway? - en No escales: el uptime del 99,999% uptime es sólo para Wal-Mart se menciona que en 37signals está encantados con un uptime del 98%, y que el coste de mejorarlo no merece la pena. [Allí se habla de que para empresas como un Wal-Mart, que equivaldría a El Corte Inglés, sería un verdadero problema tener 30 minutos parado su sistema de cobros con tarjeta de crédito en plena campaña de rebajas, por ejemplo - perderían literalmente millones de dólares].
Lo que hay en la tabla a continuación sería un resumen de lo que se consigue al «añadir nueves». Como regla general, se suele decir que cada nueve que se añade al uptime también añade un cero al coste del proyecto:
| Uptime | Tiempo perdido al año |
|---|---|
| 98% | 7,3 días |
| 99,0% | 3,7 días |
| 99,9% | 8 horas |
| 99,99% | 1 hora |
| 99,999% | 5 minutos |
Personalmente, creo que la medida del uptime sirve más para medir la fiabilidad y la redundancia que para medir la escalabilidad, y soy un poco escéptico respecto a la gente que habla de esto.
En el resto del artículo se explica que muchas veces la sensación para el usuario no tiene nada que ver con el famoso «valor del uptime». Por ejemplo en la Web no es lo mismo que un sistema se caiga a las tres de la mañana de un sábado cuando apenas habrá gente usándolo a un lunes al mediodía.
El valor tampoco dice nada sobre fallos parciales (tal vez el sistema estaba «arriba» pero no funcionaba del todo bien) e ignora cuando un sistema funciona aunque sea demasiado despacio como para resultar utilizable, típico problema de algunos servidores demasiado lentos o sobrecargados, que aunque estén «arriba» durante una semana apenas se pueden utilizar de lo lentos que van.
En general parece que teniendo en cuenta ese factor de coste ×10 para ganar unas pocas horas más de disponibilidad a la semana o al mes no tiene sentido excepto para sistemas muy críticos, y que la gente de 37siglas utiliza bien el sentido común para explicar que algunas veces no es ningún drama si ciertos servicios están «parados» durante algunas horas a la semana o si fallan.
Se me ocurren algunos representantes de la famosa Web 2.0 como Technorati (que funciona muy irregularmente) o Flickr con sus famosos «masajes», incluso Blogger tuvo sus malos momentos - tal vez encajen en esta idea. Para estos servicios mejorar el uptime no debe servir de mucho en la práctica: siempre puedes volver luego a hacer esa búsqueda o subir esa foto, y en cambio añadir más máquinas o sistemas extra resultaría tal vez carísimo.
(Vía Feh! v2.)
{Foto (CC) dlohner @ Pixabay}
