Los cinco 9s

scroll

Si existiera el nirvana informático, se llegaría al mismo al conseguir las famosas “cinco nueves” o lo que es lo mismo, un 99,999% de disponibilidad. Para alcanzarlo, tu aplicación podría estar caída o no disponible un máximo de cinco minutos… al año.

cinco-nueves

Cada nueve que añades a tu nivel de servicio incrementa varios ordenes de magnitud el coste de desarrollo y mantenimiento. Para conseguir los cinco nueves, no sólo el software tiene que ir fino Pochettino, sino que debes contar con una arquitectura que te permita hacer despliegue continuo y una infraestructura de hardware redundante y distribuida que te haga inmune a la caída de un servidor… o de un CPD entero.

Para que nos hagamos una idea del nivel de exigencia de los cinco nueves, Amazon sólo se compromete a una disponibilidad del 99,95% -entre los 3 y los 4 nueves– o lo que es lo mismo, un tiempo fuera de servicio de un máximo de cinco minutos a la semana. Un nivel de servicio que, en 2013, con el apagón de varios de sus CPDs, no han cumplido ni por asomo.

¿Hay vida más allá de los cinco nueves?

Si quieres cumplir los cinco nueves, olvídate de cambiar de hosting o modificar tu configuración de DNS. La pregunta es ¿realmente importa? Es EXTREMADAMENTE difícil conseguir las estadísticas de disponibilidad de una web, pero en el lejano 2007, Pingdom publico un informe de disponibilidad donde se podía comprobar que sólo 3 de las 20 webs más populares alcanzaban los cinco nueves.

Google, el Cherif que dictamina lo que está bien o mal en Internet, dice que estar caído un día entero no afectará a tu posicionamiento en buscadores si la hecatombe se produce de forma esporádica, como explica Matt Cutts en este video:

[thb_video url=”http://www.youtube.com/watch?v=4eYJuT0yGrI”]

Me daría con un canto en los dientes si Otogami llegara a los tres nueves, pero ahora mismo estamos en algún punto entre los dos y los tres.

He trabajado en proyectos que buscaban los cinco nueves, pero los presupuestos eran GIGANTESCOS. Mucho más grandes de lo que el cliente medio español estaría dispuesto a pagar. Si ofreces servicios informáticos y algún cliente te exige que garantices más de 2 nueves en una oferta, sal corriendo. Cuando hablamos de compromisos de disponibilidad, la pregunta que tienes que hacerte es ¿Cuantos nueves estarías dispuesto a asegurar si te jugaras tu coche o tu casa?

  • Helios VIcente

    Mas allá del problema que plantea poner más o menos nueves después de la coma, tenemos el hecho de que quien decide los 9 que van detrás algunas veces no sabe ni para qué los pone. Es como lo del diseño responsive, mola poner muchos nueves detrás. No se paran a evaluar ya no lo que supone de esfuerzo, sino si verdaderamente hace falta ese nivel de no-caida. COmo dices, evalúa cuan importante son las caidas y como pueden afectar a tu negocio y luego decide hasta donde llegas.

    Cuando trabajaba en consultoría algún proyecto me ha tocado con muchos 999999. Y ahora que no trabajo, pues también. Y es que el papel todo lo aguanta.

  • amoragon

    Sí, hay vida más allá de los cinco nueves: los nueve nueves alcanzados por el AXD301 de ericsson en sus 20 años de servicio, usando Erlang como lenguaje de implementación (http://stackoverflow.com/a/8427032). Así que ya sabéis a migrar @OtogamiCOM a Erlang 😉

    • No se lo digas dos veces a Jeroclo, que lo migramos todo a Erlang en menos que canta un gallo. Ojalá algún día tengamos problemas de escalabilidad como para plantearnoslo. Eso significaría que las cosas van BIEN 🙂

      • Bueno, lo de migrar a Erlang, si lo haceis, os va a tomar “pelín más” que “en menos que canta un gallo”, yo advierto, ¿eh? X-D

        Además, Erlang no te da mágicamente esa estabilidad, de hecho es complicado y costoso tener un sistema estable en Erlang, principalmente porque es muy fastidiado de depurar. Eso sí, una vez está “afinado”, el punto fundamental es que permite hacer despliegues sin “downtime”, que está muy bien… Pero hasta que lo tienes afinado, espera DOLOR cada vez que casque estrepitosamente y no sepas ni a cuento de qué…

        Es que me conozco el cuento de “vamos a hacerlo en Erlang, que va a ser muy escalable y estable” y luego pasa lo que pasa… Erlang funciona muy muy bien, pero para casos muy muy MUY concretos… Para el resto de cosas, bueno, es complicadillo y carece de muchas cosas que en otros lenguajes son facilísimas de encontrar (vamos, cosas tan básicas como que el tratar una cadena de texto sea un infien’no)

        • mrubio166

          Hola Jaime, no sé si hablas desde el conocimiento de lo que significa tener un sistema montado en Erlang y en producción o no. Yo llevo trabajando con Erlang desde hace 4 años, he escrito el primer libro en castellano sobre el tema y te puedo asegurar de que todos los servidores que mantengo con Erlang no me han dado nunca ningún problema. Yendo por pasos:

          1.- Complicado y costoso… incierto. Erlang está diseñado para correr en máquinas pequeñas y sin apenas recursos, cosa contraria a otros mastodontes como los servidores de aplicaciones Java 😉

          2.- Fastidiado de depurar… incierto de nuevo. El sistema permite depurar procesos independientes en sistemas en producción sin necesidad de pararlos a través de interfaz wxWindows. Además, programar en sistemas de asignación único facilita muuuuucho la tarea de encontrar fallos antes de poner lo sistemas en producción. Ya no hablamos de facilidades como proper, dialyzer o el uso aconsejado (y casi obligado) de eunit o common-tests 😉

          3.- “DOLOR cada vez que casque estrepitosamente”… ¿qué has usado? 😀 … normalmente el traceback de Erlang a partir de la R15B es bastante claro.

          4.- Erlang funciona muy bien para casos muy concretos… sí, totalmente cierto, funciona MUY bien para montar servidores, y servicios de acceso por parte de enormes cantidades de usuarios.

          5.- “Tratar una cadena de texto sea un infierno” … ??? en qué sentido? porque la versatilidad que te da el lenguaje permite no solo emplear expresiones regulares, matching o troceado, sino también otras técnicas avanzadas… como en el resto de lenguajes.

          No obstante, es normal que Erlang se vea así. Yo no aconsejaría a nadie que está empezando con Java (a aprender el lenguaje) que se hiciera una web con Spring, sería un infierno para él. Lo mismo pasa con Erlang, si no tienes a nadie experimentado al lado que te pueda guiar en las mejores prácticas, los primeros meses de proyecto lo vas a pasar francamente mal, porque es otro paradigma (modelo actor), otro lenguaje (funcional), otra plataforma (beam), otras herramientas (rebar, dialyzer, …) … Pero también te digo que cuando lo aprendes no quieres otra cosa 😉

          • Bueno, seguro que tengo mucha menos experiencia que tú en Erlang 😉 Lo usé durante 6 meses más o menos habitualmente hace un par de años y en mi empresa actual tenemos un sistema en Erlang que da servicio a millones de usuarios (aunque el contacto que tengo yo con esa parte es muy limitado) Usamos Erlang para la parte que está mejor diseñado, todo el tema de conectividad y acceso de usuarios, y después de esa capa de acceso, va todo en Python.

            Cuando decía complicado y costoso no era el coste una vez que está operativo (en eso es cierto que no hacen falta muchos recursos), sino al coste de desarrollar propiamente el sistema. La curva de aprendizaje me parece alta y la posibilidad de encontrar know-how para desarrollar algo (ya sea módulos existentes, programadores que tengan experiencia en ello, o simplemente artículos en blogs) es complicado. Cuando uno utiliza una herramienta, no es sólo la herramienta, sino también el entorno que haga más sencillo el desarrollar.
            Por ejemplo, el tema de las cadenas de texto. Componer textos largos (como pueda ser una plantilla donde hay que personalizar algunos valores) es complicado, al menos usando el lenguaje sin más (donde un texto tiene que definirse como un array de números). Es probable que existan módulos para hacerlo, pero volvemos al mismo problema. Encontrar qué módulo es el adecuado y tener experiencia con él puede ser difícil. Vamos, yo tuve ese problema, quizá haya alguna solución a día de hoy, pero entonces, o no lo había, o no era fácil de encontrar (también el uso de texto era muy limitado, así que no era un problema tan grave, pero bueno)

            Por eso digo que no debe ser tomado a la ligera. Es fantástico para ciertos problemas muy particulares, pero no es sencillo para empezar y requiere tiempo y, probablemente, conocer alguien que tenga experiencia previa y se las haya visto de colores previamente. Y, como toda tecnología, sólo por el hecho de usarla no significa que tus problemas desaparezcan mágicamente…

          • mrubio166

            Totalmente de acuerdo (salvo en el tema de las cadenas 😀 … tengo curiosidad, si eso envíame un privado y vemos eso más en detalle, porque no termino de entender donde pueda residir el problema). Sobre poner un sistema en producción, obviamente es mejor tener a alguien que ya se las haya visto anteriormente con este tipo de sistemas y que te pueda dar su apoyo para acelerar el proceso de desarrollo. En Java, por ejemplo puedes contar con gente como Autentia… igual que en Erlang con gente como Altenwald 😉 (sí… ya, autobombo, lo sé 😛 )… lo que cuenta es la suma de factores, como bien dices, si tu prioridad absoluta es el resultado, quizás puedas adecuar el entorno de los desarrollos para conseguir más fácilmente el resultado 😉

  • Daniel Brandi

    Teniendo en cuenta que los suministros de un CPD muy top (Tier4) tienen unos SLA de 99,999% para la electricidad, 99,995% para la climatización y 99,99% para el acceso a Internet siempre que ellos te lo gestionen usando varios proveedores, y que hay que considerar el SLA del hardware, SO, servicios y luego aplicaciones, conseguir un SLA mayor de 99,90% sólo se hace de dos maneras:
    1.- por suerte porque no ha pasado nada, pero pasará y te joderá los números
    2.- porque inviertes alrededor de 1mm€ al año en todo lo relacionado con infraestructura para tener geo failover activo-activo

    Cuando era CTO de Toprural teníamos un objetivo de SLA del 99,85% trimestral sin considerar intervenciones propias y lo conseguíamos habitualmente si no pasaba nada raro. En cuanto se nos torcía un poco, a la mierda el objetivo.

    • A mi 99,85% me parece Fino Pochettino, mucho más para una web de gran consumo. Si tuviera que gestionar el software de una central nuclear o de un submarino, sería otra cosa, pero para una web comercial, me parece un CIFRÓN ¡Kudos para ti Dani!

  • Hola David,

    Alrededor de estos nueves, hay mucha gente queriendo conseguir mucho dinero por algo que es imposible.

    A primera hora de la mañana retomé una integración con Mailchimp, he tenido que pasar a otra cosa por un ataque DDoS que están sufriendo ahora mismo. De estos hay todos los días, y una vez a la semana de los gordos.

    Mi opinión es que por encima de todo debe estar el sentido común y después, elegir un buen proveedor de IaaS que te dé rendimiento y que cuando pasen cosas, reaccione y sea transparente.

    Un saludo

    • Completamente de acuerdo contigo. A mi, conseguir 3 nueves -que es menos de 1h sin servicio al mes- ya me parece la repanocha y, desde luego un NICE TO HAVE, más que un MUST en toda regla.

      Mucho más aún en nuestro caso. Que alguien no pueda buscar el precio más barato del FIFA 14 y tenga que volver en 20 minutos, no creo que sea una cuestión de vida o muerte. En vuestro caso, al dar servicios a profesionales que dependen de vuestro software para hacer su trabajo, supongo que es mucho más crítico, pero tampoco me volvería loco. Si algo se cae, se cae. Como bien dices, con trasparencia, honestidad e intentar ir mejorando continuamente, a la mayoría de los clientes les vale.

  • Que es utópico, totalmente de acuerdo.
    Y si no pensamos en webs y pensamos en servicios de infraestructuras críticas, seguro que coincidimos todos que nos gustaría que las secciones TIC de los sistemas de emergencia si lo cumplieran.
    El problema es el mismo de siempre, la gente que toma las decisiones raramente esta capacitada para ello porque sus puestos son políticos y no técnicos. Ni comentar ya que pongan el dinero y la gente necesaria para poder llevarlo a cabo.

    Lo que comentaban… sentido común, intentar hacer las cosas con cabeza, disponer de unos mínimos y tener a gente preparada, así estarán paradas el mínimo tiempo posible … y lo de los nueves se lo dejaremos a los que piensen más en las medallitas que en garantizar los servicios.

  • El tema de la fiabilidad y resistencia al “downtime” es hacerse la pregunta del millón: “¿Hasta donde tiene sentido llegar?”. Porque la inmensísima mayoría de servicios, con hasta una hora de mantenimiento programado al día, no dejan de hacer bien su trabajo.

    No sé si os acordareis que Stack Overflow estaba en mantenimiento cada dos por tres, y el mundo no se acababa. Si Google está 1 minutoscaído (y hablamos de Google), el mundo no se termina (aunque vale que es una inconveniencia). En mi experiencia, hay que justificar MUY MUY bien la reducción drástica de downtime, sobre todo en lo referente a reiniciar sistemas o a mantenimiento programado (a lo mejor estar 5 minutos caídos un martes a las 3 de la mañana no es tan tan horrible), porque, aunque todos queramos tener los sistemas operativos el mayor tiempo posible, conseguir una fiabilidad de muchosnueves tiene un coste tremendo, tanto en lo que es en sí administración como en la carga que pone al desarrollo (¿qué pasa cuando hay una migración? ¿se puede hacer a la vez que el sistema está disponible?, etc, etc)

    Al final, hay que poner una línea en algún lado, y en la inmensa mayoría de sistemas, en realidad la diferencia entre estar no disponible 5 minutos al día o 30 minutos es muy pequeña… Otra cosa es que esté caído y ni te enteres, claro…

  • zordor

    En amazon se comienza a compensar a clientes cuando en el mes la disponibilidad ha bajado del 99.5% y si en lugares como AWS se juega con estos numeros mejorarlos es muy complicado. Hay que mirarlo tambien a nivel global. Si tienes tus servidores en una empresa y esa empresa tiene un incendio en los datacenters (lo he visto pasar) y estas caido durante 3 dias, quiza consigas tirar de algun plan de contingencia y levantarlo en dia y medio, pero ya te estas yendo al 95%. Creo que es mejor asegurar con servicios como AWS el 99.5% en largo plazo que apostar por el 99.999% cada mes y un mes tener una caida de dos dias.

    De cara al cliente una caida de dos dias tendra una percepcion mucho peor que una caida de unos minutos aunque esta ocurra cada mes.

    Resumiendo, creo que no hay que perder la cabeza con esto, es como con la seguridad hay que preocuparse por ella (y mucho) pero tener en cuenta que puede destruir la viabilidad de nuestro plan de forma economica o usable. Estar entre los dos 9s y los 3 9s me parece aceptable y es donde creo deberia tratar de estar.

  • Se debería añadir también como indicador de calidad la probabilidad de que un usuario coincida con un downtime, ya que su percepción será completamente diferente… No es lo mismo un sistema que esté caído todos los lunes de 8.00h a 8.20h (un 99,8% uptime) si el 100% de sus usuarios lo utiliza solo los lunes a las 8.10h cuando llega a la oficina… que uno que esté caído de 24.00h a 8.00h todos los días de la semana (65% uptime!) si el 100% de los usuarios sólo lo usan de 8.00h a 18.30h y nunca lo van a encontrar caído…

  • Pingback: SEGURIDAD DE LA INFORMACIÓN | NOTAS SAD()