Articulo de referencia

Alta disponibilidad

La alta disponibilidad ( HA ) es una característica de un sistema que tiene como objetivo garantizar un nivel acordado de rendimiento operativo, generalmente tiempo de actividad...

La alta disponibilidad ( HA ) es una característica de un sistema que tiene como objetivo garantizar un nivel acordado de rendimiento operativo, generalmente tiempo de actividad , durante un período superior al normal. [ 1 ]

Ahora existe una mayor dependencia de estos sistemas como resultado de la modernización. Por ejemplo, para llevar a cabo sus tareas diarias habituales, los hospitales y los centros de datos necesitan que sus sistemas tengan una alta disponibilidad. La disponibilidad se refiere a la capacidad del usuario para acceder a un servicio o sistema, ya sea para enviar nuevo trabajo, actualizar o modificar el trabajo existente, o recuperar los resultados de un trabajo anterior. Si un usuario no puede acceder al sistema, se considera que no está disponible desde la perspectiva del usuario . [ 2 ] El término tiempo de inactividad se utiliza generalmente para describir los períodos en los que un sistema no está disponible.

Resiliencia

La alta disponibilidad es una propiedad de la resiliencia de la red , la capacidad de "proporcionar y mantener un nivel de servicio aceptable ante fallos y desafíos al funcionamiento normal". [ 3 ] Las amenazas y los desafíos para los servicios pueden abarcar desde una simple configuración incorrecta hasta desastres naturales a gran escala o ataques dirigidos. [ 4 ] Por lo tanto, la resiliencia de la red abarca una amplia gama de temas. Para aumentar la resiliencia de una red de comunicación determinada, es necesario identificar los posibles desafíos y riesgos, y definir las métricas de resiliencia adecuadas para el servicio que se va a proteger. [ 5 ]

La importancia de la resiliencia de la red aumenta continuamente, ya que las redes de comunicación se están convirtiendo en un componente fundamental en el funcionamiento de las infraestructuras críticas. [ 6 ] En consecuencia, los esfuerzos recientes se centran en interpretar y mejorar la resiliencia de la red y la computación con aplicaciones a infraestructuras críticas. [ 7 ] Como ejemplo, se puede considerar como objetivo de resiliencia el aprovisionamiento de servicios a través de la red, en lugar de los servicios de la propia red. Esto puede requerir una respuesta coordinada tanto de la red como de los servicios que se ejecutan sobre ella. [ 8 ]

Estos servicios incluyen:

Los términos resiliencia y supervivencia se utilizan indistintamente según el contexto específico de cada estudio. [ 9 ]

Principios

En ingeniería de confiabilidad existen tres principios de diseño de sistemas que pueden ayudar a lograr una alta disponibilidad. [ 10 ]

  1. Eliminación de puntos únicos de fallo . Esto significa añadir o incorporar redundancia al sistema para que el fallo de un componente no implique el fallo de todo el sistema.
  2. Conmutación segura. En los sistemas redundantes , el punto de conmutación tiende a convertirse en un único punto de fallo. Los sistemas fiables deben garantizar una conmutación segura.
  3. Detección de fallos en el momento en que se producen. Si se respetan los dos principios anteriores, es posible que el usuario nunca vea un fallo, pero la actividad de mantenimiento sí debe hacerlo.

Tiempos de inactividad programados y no programados

Se puede distinguir entre tiempo de inactividad programado y no programado. Por lo general, el tiempo de inactividad programado es resultado de tareas de mantenimiento que interrumpen el funcionamiento del sistema y que normalmente no se pueden evitar con el diseño del sistema instalado actualmente. Los eventos de tiempo de inactividad programado pueden incluir parches para el software del sistema que requieren un reinicio o cambios en la configuración del sistema que solo surten efecto tras un reinicio. En general, el tiempo de inactividad programado suele ser el resultado de algún evento lógico iniciado por la administración. Los eventos de tiempo de inactividad no programado suelen surgir de algún evento físico, como una falla de hardware o software o una anomalía ambiental. Ejemplos de eventos de tiempo de inactividad no programado incluyen cortes de energía, fallas en la CPU o la RAM (o posiblemente en otros componentes de hardware), un apagado relacionado con sobretemperatura, conexiones de red interrumpidas lógica o físicamente, brechas de seguridad o diversas fallas de aplicaciones , middleware y sistemas operativos . [ 11 ]

Si se puede advertir a los usuarios sobre los periodos de inactividad programados, entonces la distinción es útil. Pero si el requisito es una verdadera alta disponibilidad, entonces el tiempo de inactividad es tiempo de inactividad, esté programado o no.

Muchos centros de computación excluyen el tiempo de inactividad programado de los cálculos de disponibilidad, asumiendo que tiene poco o ningún impacto en la comunidad de usuarios. Al hacerlo, pueden afirmar tener una disponibilidad excepcionalmente alta, lo que podría dar la ilusión de disponibilidad continua . Los sistemas que ofrecen una disponibilidad verdaderamente continua son relativamente escasos y más caros, y la mayoría cuenta con diseños especializados cuidadosamente implementados que eliminan cualquier punto único de fallo y permiten actualizaciones, parches y reemplazos en línea de hardware, red, sistema operativo, middleware y aplicaciones. Para ciertos sistemas, el tiempo de inactividad programado no importa; por ejemplo, el tiempo de inactividad del sistema en un edificio de oficinas después de que todos se hayan ido a casa por la noche.

Cálculo de porcentaje

La disponibilidad se suele expresar como un porcentaje de tiempo de actividad en un año determinado. La siguiente tabla muestra el tiempo de inactividad permitido para un porcentaje específico de disponibilidad, suponiendo que el sistema deba operar de forma continua. Los acuerdos de nivel de servicio (SLA ) suelen hacer referencia al tiempo de inactividad o disponibilidad mensual para calcular los créditos de servicio y ajustarlos a los ciclos de facturación mensuales. La siguiente tabla muestra la conversión de un porcentaje de disponibilidad determinado al tiempo correspondiente en que un sistema estaría inactivo. La disponibilidad se suele expresar en términos de "nueves", donde el 90 % se denomina "un nueve", el 99 % "dos nueves", el 99,9 % "tres nueves", y así sucesivamente. A medida que aumenta el número de nueves, los objetivos de disponibilidad se vuelven exponencialmente más estrictos.

Los niveles de fiabilidad superiores al nueve nueve son raros y, por lo general, solo se consiguen mediante redes distribuidas de sistemas redundantes, e incluso entonces, en gran medida solo en teoría, ya que es prácticamente imposible medir niveles tan bajos de tiempo de inactividad en un período razonable; incluso un solo segundo de inactividad de todo el sistema en 30 años (por ejemplo, debido a un error de software de modo común imprevisto) sería suficiente para destronar un sistema del 99,999% y reducirlo a un 99,999% de disponibilidad.

Los términos tiempo de actividad y disponibilidad se usan a menudo indistintamente, pero no siempre se refieren a lo mismo. Por ejemplo, un sistema puede estar "activo" pero sus servicios no estar "disponibles" en caso de una interrupción de la red . O un sistema en mantenimiento de software puede estar "disponible" para que un administrador de sistemas trabaje en él , pero sus servicios no aparecen "activos" para el usuario final o cliente. Por lo tanto, el tema de los términos es importante: ya sea que el foco de la discusión sea el hardware del servidor, el sistema operativo del servidor, el servicio funcional, el servicio/proceso de software o similar, solo si existe un tema único y coherente de la discusión, las palabras tiempo de actividad y disponibilidad pueden usarse como sinónimos.

Mnemotecnia de cinco por cinco

Una regla mnemotécnica sencilla establece que cinco nueves permiten aproximadamente cinco minutos de inactividad al año. Se pueden obtener variantes multiplicando o dividiendo por 10: cuatro nueves equivalen a 50 minutos y tres nueves a 500 minutos. En sentido contrario, seis nueves equivalen a 0,5 minutos (30 segundos) y siete nueves a 3 segundos.

Truco de "potencias de 10"

Otro truco de memoria para calcular la duración del tiempo de inactividad permitido para un "norte{\displaystyle n}El porcentaje de disponibilidad de "nueves" se debe usar con la fórmula8.64×104norte{\displaystyle 8.64\times 10^{4-n}}segundos por día.

Por ejemplo, el 90% ("uno nueve") produce el exponente41=3{\displaystyle 4-1=3}y por lo tanto el tiempo de inactividad permitido es8.64×103{\displaystyle 8.64\times 10^{3}}segundos por día.

Además, 99.999% ("cinco nueves") da el exponente45=1{\displaystyle 4-5=-1}y por lo tanto el tiempo de inactividad permitido es8.64×101{\displaystyle 8.64\times 10^{-1}}segundos por día.

"Nueve"

Los porcentajes de un orden de magnitud particular a veces se denominan mediante el número de nueves o "clase de nueves" en los dígitos. Por ejemplo, la electricidad que se suministra sin interrupciones ( apagones , bajadas de tensión o sobretensiones ) el 99,999% del tiempo tendría una fiabilidad de 5 nueves, o clase cinco. [ 12 ] En particular, el término se utiliza en relación con los mainframes [ 13 ] [ 14 ] o la informática empresarial, a menudo como parte de un acuerdo de nivel de servicio .

De manera similar, los porcentajes que terminan en 5 tienen nombres convencionales, tradicionalmente el número de nueves, luego "cinco", por lo que 99.95% es "tres nueves cinco", abreviado 3N5. [ 15 ] [ 16 ] A esto se le llama informalmente "tres nueves y medio", [ 17 ] pero esto es incorrecto: un 5 es solo un factor de 2, mientras que un 9 es un factor de 10, por lo que un 5 es 0.3 nueves (según la fórmula a continuación:registro1020,3{\displaystyle \log _{10}2\approx 0.3}): [ nota 1 ] La disponibilidad del 99,95 % es 3,3 nueves, no 3,5 nueves. [ 18 ] En pocas palabras, pasar de una disponibilidad del 99,9 % a una del 99,95 % es un factor de 2 (de 0,1 % a 0,05 % de indisponibilidad), pero pasar de una disponibilidad del 99,95 % a una del 99,99 % es un factor de 5 (de 0,05 % a 0,01 % de indisponibilidad), más del doble. [ nota 2 ]

Una formulación de la clase de 9do{\displaystyle c} basado en la indisponibilidad de un sistemaincógnita{\displaystyle x}sería

do:=registro10incógnita{\displaystyle c:=\lfloor -\log _{10}x\rfloor }

(véase Funciones del suelo y del techo ).

En ocasiones, se utiliza una medida similar para describir la pureza de las sustancias.

En general, el número de nueves no suele ser utilizado por un ingeniero de redes al modelar y medir la disponibilidad porque es difícil de aplicar en fórmulas. Más a menudo, se cita la indisponibilidad expresada como una probabilidad (como 0,00001) o un tiempo de inactividad por año. La disponibilidad especificada como un número de nueves se ve a menudo en documentos de marketing . El uso de los "nueves" ha sido cuestionado, ya que no refleja adecuadamente que el impacto de la indisponibilidad varía con el momento en que ocurre. [ 19 ] Para grandes cantidades de 9s, el índice de "inasistencia" (medida de tiempo de inactividad en lugar de tiempo de actividad) es más fácil de manejar. Por ejemplo, esta es la razón por la que se utiliza una métrica de "inasistencia" en lugar de disponibilidad en las tasas de error de bits de disco duro o enlace de datos .

A veces se utiliza el término humorístico "nueve cincos" (55,5555555%) para contrastar con "cinco nueves" (99,999%), [ 20 ] [ 21 ] [ 22 ] aunque este no es un objetivo real, sino más bien una referencia sarcástica a algo que no cumple en absoluto con ningún objetivo razonable.

Medición e interpretación

La medición de la disponibilidad está sujeta a cierto grado de interpretación. Un sistema que ha estado operativo durante 365 días en un año no bisiesto podría haber sufrido una interrupción de red de 9 horas durante un período de máxima actividad; los usuarios lo percibirán como no disponible, mientras que el administrador del sistema afirmará un tiempo de actividad del 100 %. Sin embargo, según la definición real de disponibilidad, el sistema tendrá una disponibilidad aproximada del 99,9 %, o tres nueves (8751 horas de tiempo disponible de un total de 8760 horas por año no bisiesto). Asimismo, los sistemas que experimentan problemas de rendimiento suelen ser considerados parcial o totalmente no disponibles por los usuarios, incluso cuando siguen funcionando. De igual modo, la indisponibilidad de ciertas funciones de la aplicación podría pasar desapercibida para los administradores, pero resultar devastadora para los usuarios  ; una verdadera medición de la disponibilidad es integral.

Para determinar la disponibilidad, es necesario medirla, idealmente con herramientas de monitorización integrales ("instrumentación") que, a su vez, ofrezcan alta disponibilidad. En caso de falta de instrumentación, los sistemas que procesan grandes volúmenes de transacciones las 24 horas del día, como los sistemas de procesamiento de tarjetas de crédito o las centrales telefónicas, suelen estar mejor monitorizados, al menos por los propios usuarios, que los sistemas que experimentan periodos de baja demanda.

Una métrica alternativa es el tiempo medio entre fallos (MTBF).

El tiempo de recuperación (o tiempo estimado de reparación (ETR), también conocido como objetivo de tiempo de recuperación (RTO)) está estrechamente relacionado con la disponibilidad, es decir, el tiempo total requerido para una interrupción planificada o el tiempo requerido para recuperarse completamente de una interrupción no planificada. Otra métrica es el tiempo medio de recuperación (MTTR). El tiempo de recuperación podría ser infinito con ciertos diseños de sistemas y fallas, es decir, la recuperación completa es imposible. Un ejemplo de esto es un incendio o una inundación que destruye un centro de datos y sus sistemas cuando no hay un centro de datos secundario de recuperación ante desastres .

Otro concepto relacionado es la disponibilidad de datos , que se refiere al grado en que las bases de datos y otros sistemas de almacenamiento de información registran e informan fielmente las transacciones del sistema. La gestión de la información suele centrarse por separado en la disponibilidad de datos, o en el Objetivo de Punto de Recuperación (RPO) , para determinar la pérdida de datos aceptable (o real) ante diversos fallos. Algunos usuarios pueden tolerar interrupciones en el servicio de las aplicaciones, pero no la pérdida de datos.

Un acuerdo de nivel de servicio ("SLA") formaliza los objetivos y requisitos de disponibilidad de una organización.

Sistemas de control militar

La alta disponibilidad es uno de los requisitos principales de los sistemas de control en vehículos no tripulados y embarcaciones marítimas autónomas . Si el sistema de control deja de estar disponible, el vehículo de combate terrestre (GCV) o la embarcación no tripulada de seguimiento continuo antisubmarino (ACTUV) quedarían inoperativos.

Diseño del sistema

Por un lado, añadir más componentes al diseño general de un sistema puede socavar los esfuerzos por lograr una alta disponibilidad, ya que los sistemas complejos inherentemente tienen más puntos de fallo potenciales y son más difíciles de implementar correctamente. Si bien algunos analistas plantean la teoría de que los sistemas con mayor disponibilidad se adhieren a una arquitectura simple (un único sistema físico multipropósito de alta calidad con redundancia de hardware interna integral), esta arquitectura adolece del requisito de que todo el sistema debe desconectarse para aplicar parches y actualizar el sistema operativo. Los diseños de sistemas más avanzados permiten aplicar parches y actualizar los sistemas sin comprometer la disponibilidad del servicio (véase el equilibrio de carga y la conmutación por error ). La alta disponibilidad requiere menos intervención humana para restablecer el funcionamiento en sistemas complejos; la razón es que la causa más común de interrupciones es el error humano. [ 23 ]

Alta disponibilidad mediante redundancia

Por otro lado, la redundancia se utiliza para crear sistemas con altos niveles de disponibilidad (por ejemplo, sitios web de comercio electrónico populares). En este caso, se requiere una alta detectabilidad de fallos y la prevención de fallos de causa común.

Si se utilizan partes redundantes en paralelo y tienen fallos independientes (por ejemplo, al no estar en el mismo centro de datos), pueden aumentar exponencialmente la disponibilidad y hacer que el sistema general sea altamente disponible. Si tiene N componentes en paralelo, cada uno con una disponibilidad X, puede utilizar la siguiente fórmula: [ 24 ] [ 25 ]

Disponibilidad de componentes en paralelo = 1 - (1 - X)^ N

Diez servidores, cada uno con un 50 % de disponibilidad. Pero si se utilizan en paralelo y fallan de forma independiente, pueden proporcionar una alta disponibilidad.
Diez servidores, cada uno con un 50 % de disponibilidad. Pero si se utilizan en paralelo y fallan de forma independiente, pueden proporcionar una alta disponibilidad.

Por ejemplo, si cada uno de sus componentes tiene solo un 50 % de disponibilidad, al usar 10 componentes en paralelo, puede lograr una disponibilidad del 99,9023 %.

Existen dos tipos de redundancia: la redundancia pasiva y la redundancia activa.

La redundancia pasiva se utiliza para lograr una alta disponibilidad mediante la inclusión de suficiente capacidad excedente en el diseño para compensar una disminución del rendimiento. El ejemplo más sencillo es un barco con dos motores independientes que impulsan dos hélices independientes. El barco continúa su rumbo a pesar del fallo de un solo motor o hélice. Un ejemplo más complejo son las múltiples instalaciones redundantes de generación de energía dentro de un sistema de transmisión de energía eléctrica de gran tamaño . El mal funcionamiento de componentes individuales no se considera un fallo a menos que la disminución del rendimiento resultante supere los límites de especificación para todo el sistema.

La redundancia activa se utiliza en sistemas complejos para lograr alta disponibilidad sin disminución del rendimiento. Se incorporan múltiples elementos del mismo tipo en un diseño que incluye un método para detectar fallas y reconfigurar automáticamente el sistema para omitir los elementos defectuosos mediante un esquema de votación. Esto se utiliza con sistemas informáticos complejos interconectados. El enrutamiento de Internet se deriva del trabajo inicial de Birman y Joseph en esta área. [ 26 ] La redundancia activa puede introducir modos de falla más complejos en un sistema, como la reconfiguración continua del sistema debido a una lógica de votación defectuosa.

El diseño de sistemas con tiempo de inactividad cero implica que el modelado y la simulación indican que el tiempo medio entre fallos supera significativamente el periodo entreel mantenimiento planificado,actualizacioneso la vida útil del sistema. El tiempo de inactividad cero requiere una redundancia masiva, necesaria para algunos tipos de aeronaves y para la mayoría de lossatélites de comunicaciones.El Sistema de Posicionamiento Global (GPS)es un ejemplo de sistema con tiempo de inactividad cero.

La instrumentación de fallos puede utilizarse en sistemas con redundancia limitada para lograr una alta disponibilidad. Las acciones de mantenimiento se realizan durante breves periodos de inactividad solo después de que se active un indicador de fallo. Un fallo solo es significativo si ocurre durante un periodo crítico para la misión .

El modelado y la simulación se utilizan para evaluar la fiabilidad teórica de sistemas de gran tamaño. El resultado de este tipo de modelo se emplea para evaluar diferentes opciones de diseño. Se crea un modelo del sistema completo y se somete a pruebas de estrés eliminando componentes. La simulación de redundancia utiliza el criterio Nx, donde N representa el número total de componentes del sistema y x el número de componentes utilizados para someterlo a estrés. N-1 significa que el modelo se somete a pruebas de estrés evaluando su rendimiento con todas las combinaciones posibles en las que falla un componente. N-2 significa que el modelo se somete a pruebas de estrés evaluando su rendimiento con todas las combinaciones posibles en las que fallan dos componentes simultáneamente.

Motivos de indisponibilidad

Una encuesta realizada en 2010 entre expertos en disponibilidad académica clasificó las razones de la indisponibilidad de los sistemas de TI empresariales. Todas las razones se refieren a no seguir las mejores prácticas en cada una de las siguientes áreas (en orden de importancia): [ 27 ]

  1. Seguimiento de los componentes relevantes
  2. Requisitos y adquisición
  3. Operaciones
  4. Prevención de fallos en la red
  5. Prevención de fallos en las aplicaciones internas
  6. Evitar los servicios externos que fallan
  7. Entorno físico
  8. Redundancia de red
  9. Solución técnica de respaldo
  10. Solución de proceso de copia de seguridad
  11. Ubicación física
  12. Redundancia de infraestructura
  13. Redundancia de la arquitectura de almacenamiento

En 2003 se publicó un libro sobre los factores en sí. [ 28 ]

Costes de indisponibilidad

En un informe de 1998 de IBM Global Services , se estimó que los sistemas no disponibles costaron a las empresas estadounidenses 4.540 millones de dólares en 1996, debido a la pérdida de productividad e ingresos. [ 29 ]

Véase también

Notas

  1. Consulte las coincidencias matemáticas relativas a la base 2 para obtener más detalles sobre esta aproximación.
  2. "El doble" en una escala logarítmica, lo que significa dos factores de 2:×2×2<×5{\displaystyle \times 2\times 2<\times 5}

Referencias

  1. Robert, Sheldon (abril de 2024). "alta disponibilidad (HA)" . Techtarget .
  2. Floyd Piedad, Michael Hawkins (2001). Alta disponibilidad: diseño, técnicas y procesos . Prentice Hall. ISBN 9780130962881.
  3. "Definiciones - ResiliNetsWiki" . resilinets.org .
  4. "Webarchiv ETHZ / Webarchive ETH" . webarchiv.ethz.ch .
  5. ^ Herrero, Pablo; Hutchison, David; Sterbenz, James PG; Schöller, Marcus; Fessi, Ali; Karaliopoulos, Merkouris; Lac, Chidung; Plattner, Bernhard (3 de julio de 2011). "Resiliencia de la red: un enfoque sistemático". Revista de comunicaciones IEEE . 49 (7): 88– 97. Código Bib : 2011IComM..49g..88S . doi : 10.1109/MCOM.2011.5936160 . S2CID 10246912 . 
  6. accesstel (9 de junio de 2022). "Resiliencia operativa | empresas de telecomunicaciones | accesstel | riesgo | crisis" . accesstel . Consultado el 8 de mayo de 2023 .
  7. "El proyecto CERCES - Centro para Infraestructuras Críticas Resilientes en el Instituto Real de Tecnología KTH" . Archivado del original el 19 de octubre de 2018. Consultado el 26 de agosto de 2023 .
  8. Zhao, Peiyue; Dán, György (3 de diciembre de 2018). "Un enfoque de descomposición de Benders para la ubicación resiliente de funciones de control de procesos virtuales en nubes de borde móvil". IEEE Transactions on Network and Service Management . 15 (4): 1460– 1472. Bibcode : 2018ITNSM..15.1460Z . doi : 10.1109/TNSM.2018.2873178 . S2CID 56594760 . 
  9. Castet J., Saleh J. Supervivencia y resiliencia de naves espaciales y redes espaciales: un marco para la caracterización y el análisis", Instituto Americano de Aeronáutica y Astronáutica, Informe Técnico AIAA 2008-7707. Conferencia sobre Protocolos de Red (ICNP 2006) , Santa Bárbara, California, EE. UU., noviembre de 2006.
  10. "Aprenda sobre la alta disponibilidad en la nube" . Centro de ayuda de Oracle . Consultado el 4 de junio de 2026 .
  11. "Alta disponibilidad: teoría" , Servicios de TI de alta disponibilidad , Auerbach Publications, 17 de diciembre de 2014, págs. 141–176 , ISBN  978-0-429-17452-0Consultado el 4 de junio de 2026.
  12. Apuntes de clase de M. Nesterenko, Universidad Estatal de Kent
  13. Introducción al nuevo mainframe: Computación comercial a gran escala Capítulo 5 Disponibilidad Archivado el 4 de marzo de 2016 en Wayback Machine IBM (2006)
  14. Vídeo sobre el valor empresarial de IBM zEnterprise EC12 en youtube.com
  15. Metales preciosos, Volumen 4. Pergamon Press. 1981. pág . 262. ISBN  9780080253695.
  16. PVD para microelectrónica: Deposición por pulverización catódica a la fabricación de semiconductores . 1998. pág. 387 . 
  17. Murphy, Niall Richard; Beyer, Betsy; Petoff, Jennifer; Jones, Chris (2016). Ingeniería de confiabilidad de sitios: cómo Google ejecuta sistemas de producción . pág. 38 . 
  18. Josh Deprez (23 de abril de 2016). "Nines of Nines" . Archivado del original el 4 de septiembre de 2016. Recuperado el 31 de mayo de 2016 .
  19. Evan L. Marcus, El mito de los nueves
  20. Newman, David; Snyder, Joel; Thayer, Rodney (24 de junio de 2012). "Alarmas falsas: ocultan ataques" . Network World . Vol. 19, n.º 25, pág. 60. Consultado el 15 de marzo de 2019. lo que lleva a fallos y a cifras de tiempo de actividad más cercanas al 95% que al 99,99% .   
  21. Metcalfe, Bob (2 de abril de 2001). "Después de 35 años de cruzadas tecnológicas, Bob Metcalfe se retira hacia el atardecer" . ITworld . Consultado el 15 de marzo de 2019. y cinco nueves (no nueve cincos) de confiabilidad
  22. Pilgrim, Jim (20 de octubre de 2010). "Adiós a los cinco nueves" . Clearfield, Inc. Recuperado el 15 de marzo de 2019. Pero me parece que nos estamos acercando más a los 9-5 (55,5555555%) en confiabilidad de red que a los 5-9
  23. "¿Qué es el tiempo de inactividad de la red?" . Redes . Consultado el 27 de diciembre de 2023 .
  24. Trivedi, Kishor S.; Bobbio, Andrea (2017). Ingeniería de confiabilidad y disponibilidad: modelado, análisis y aplicaciones . Cambridge University Press. ISBN 978-1107099500.
  25. Mantenimiento de sistemas: Procesos de adquisición e ingeniería para el mantenimiento de sistemas críticos y heredados (Serie World Scientific sobre tecnologías emergentes: Serie en memoria de Avram Bar-cohen) . World Scientific. 2022. ISBN 978-9811256844.
  26. RFC 992 
  27. Ulrik Franke, Pontus Johnson, Johan König, Liv Marcks von Würtemberg: Disponibilidad de sistemas de TI empresariales: un modelo bayesiano basado en expertos, Actas del Cuarto Taller Internacional sobre Calidad y Mantenibilidad del Software (WSQM 2010), Madrid,Enlace obsoleto archivado el 4 de agosto de 2012 en archive.today.
  28. Marcus, Evan; Stern, Hal (2003). Planos para alta disponibilidad (Segunda edición). Indianápolis, IN: John Wiley & Sons. ISBN  0-471-43026-9.
  29. IBM Global Services, Mejora de la disponibilidad de los sistemas , IBM Global Services, 1998,Archivado el 1 de abril de 2011 en Wayback Machine .
  • Apuntes de clase sobre informática empresarial archivados el 16 de noviembre de 2013 en la Wayback Machine de la Universidad de Tubinga.
  • Apuntes de clase sobre ingeniería de sistemas embebidos del profesor Phil Koopman.
  • Calculadora de tiempo de actividad (SLA)