Los sistemas / programas / algoritmos distribuidos / ... a menudo se describen con el predicado robusto o tolerante a fallas .
¿Cuál es la diferencia?
Detalles:
Cuando busco en Google + robusto + "tolerante a fallas", solo obtengo dos resultados, ambos inútiles.
Cuando busco en Google los términos, encuentro muchos documentos que tienen ambos términos en su título. Desafortunadamente, no definen con precisión los términos :( Pero como usan ambos términos, parece que ninguno implica el otro.
Respuestas:
Ambos describen la consistencia del comportamiento de una aplicación, pero la "robustez" describe la respuesta de una aplicación a su entrada , mientras que la "tolerancia a fallas" describe la respuesta de una aplicación a su entorno .
Una aplicación es robusta cuando puede funcionar consistentemente con datos inconsistentes. Por ejemplo: una aplicación de mapas es robusta cuando puede analizar direcciones en varios formatos con varios errores ortográficos y devolver una ubicación útil. Un reproductor de música es robusto cuando puede continuar decodificando un MP3 después de encontrar un cuadro mal formado. Un editor de imágenes es robusto cuando puede modificar una imagen con metadatos EXIF incrustados que podría no reconocer, especialmente si puede realizar cambios en la imagen sin destruir los datos EXIF.
Una aplicación es tolerante a fallas cuando puede funcionar consistentemente en un entorno inconsistente. Una aplicación de base de datos es tolerante a fallas cuando puede acceder a un fragmento alternativo cuando el primario no está disponible. Una aplicación web es tolerante a fallas cuando puede continuar manejando solicitudes de caché incluso cuando no se puede acceder a un host de API. Un subsistema de almacenamiento es tolerante a fallas cuando puede devolver resultados calculados a partir de la paridad cuando un miembro del disco está fuera de línea.
En ambos casos, se espera que la aplicación permanezca estable, se comporte de manera uniforme, conserve la integridad de los datos y brinde resultados útiles incluso cuando se encuentre un error. Pero al evaluar la robustez, puede encontrar criterios que involucren datos, mientras que al evaluar la tolerancia a fallas, encontrará criterios que involucren tiempo de actividad.
Uno no necesariamente conduce al otro. Una aplicación móvil de reconocimiento de voz puede ser muy robusta, proporcionando una capacidad asombrosa para reconocer el habla de manera consistente en una variedad de acentos regionales con grandes cantidades de ruido de fondo. Pero si es inútil sin una conexión rápida de datos celulares, no es muy tolerante a fallas. Del mismo modo, una aplicación de publicación web puede ser inmensamente tolerante a fallas, con múltiples redundancias en todos los niveles, capaz de perder centros de datos completos sin fallar, pero si se cae una tabla de usuario y se bloquea la primera vez que alguien se registra con un apóstrofe en su apellido , no es robusto en absoluto.
Si está buscando literatura académica para ayudar a describir la distinción, puede buscar en dominios específicos que utilizan software, en lugar de software en general. La investigación de aplicaciones distribuidas podría ser un terreno fértil para los criterios de tolerancia a fallas, y Google ha publicado algunas de sus investigaciones que podrían ser relevantes. La investigación de modelos de datos probablemente aborda cuestiones de robustez, ya que los científicos están particularmente interesados en las propiedades de robustez que producen resultados reproducibles. Probablemente pueda encontrar documentos que describan aplicaciones estadísticas que podrían ser útiles, como en el modelado climático, el modelo de propagación de RF o la secuenciación del genoma. También encontrará ingenieros que discuten el "diseño robusto" en cosas como los sistemas de control.
El documento técnico del Sistema de archivos de Google describe su enfoque de los problemas de tolerancia a fallas, que generalmente implica la suposición de que las fallas de los componentes son rutinarias y, por lo tanto, la aplicación debe adaptarse a ellas:
Este proyecto para una clase en Rutgers admite una definición orientada a "falla de componentes" de "tolerancia a fallas":
Hay muchos documentos sobre "modelado robusto XYZ", dependiendo del campo que investigue. La mayoría describirá sus criterios para "robusto" en el resumen, y encontrará que todo tiene que ver con la forma en que el modelo maneja la entrada.
Este informe de un científico del clima de la NASA describe la robustez como un criterio para evaluar los modelos climáticos:
Este artículo de un investigador del MIT examina aplicaciones de protocolo inalámbrico, un dominio en el que se superponen la tolerancia a fallas y la solidez, pero los autores usan "robusto" para describir aplicaciones, protocolos y algoritmos, mientras que usan "tolerancia a fallas" en referencia a la topología y componentes:
fuente
Realmente me gusta la respuesta de @ johnnyb y la respaldo por sus definiciones nítidas. Pero después de haber trabajado en el campo durante algunas décadas, reconozco otra forma (mucho menos formal y precisa) de que estos términos se usan con frecuencia:
Como puntos informales a lo largo de un continuo de "poco confiable" a "perfectamente confiable".
No hay ningún sistema, aplicación o servicio que pueda garantizar que siempre y para siempre estará en funcionamiento ("continuamente disponible" o "permanentemente disponible"). "Tolerante a fallas" ha sido durante mucho tiempo un sustituto de "hemos hecho todo lo humanamente posible con la tecnología actual para asegurarnos de que esto siga funcionando correctamente".
Las palabras como "robusto", "endurecido" y "altamente disponible" se utilizan como hitos más suaves hacia ese objetivo de operación continua. Reflejan niveles crecientes de esfuerzo, inversión y confianza.
Debido a que estos términos se usan informalmente, no existe un ordenamiento totalmente canónico. "Altamente disponible" suele ser una afirmación fuerte, justo debajo de "resistente a fallas" o "tolerante a fallas". ¿Pero es "endurecido" mejor que "robusto"? ¿O viceversa? Depende del contexto. Estos también se utilizan con frecuencia como reclamos de comercialización de productos, con toda la jactancia e imprecisión intencional que conlleva.
Por lo general, las organizaciones que trabajan para alcanzar estos objetivos tienen su propia progresión acordada internamente, generalmente al menos aproximadamente vinculada a los objetivos / resultados del proyecto y métricas externas como "tres nueves" o "seis nueves".
@johnnyb también toca una distinción crítica: la diferencia entre el estado de subida / bajada de la plataforma (disponibilidad) por un lado, y los atributos de algoritmo, aplicación o servicio por el otro.
Digo "atributos" porque hay muchos: rendimiento, corrección e imperturbabilidad son solo unos pocos. ¿Existe un sistema significativamente disponible y correcto si está funcionando a solo el 10% del rendimiento nominal? ¡No según los dueños de negocios si es la temporada alta! No hay una gran virtud en un sistema que realmente nunca falla, pero que también da respuestas incorrectas la mayor parte del tiempo. Finalmente, ¿está funcionando un sistema de análisis de datos "correcto" si una variación del 0.2% en la entrada da una respuesta diferente del 3,400%? Quizás ... pero a muchos les parecerá un modelo bastante caprichoso e insatisfactorio. No revisaré la lista extendida de atributos, pero la integridad de los datos, la seguridad de los datos, la privacidad de los datos y otros problemas de corrección y seguridad son preocupaciones comunes. (Si es una organización muy grande o una agencia gubernamental, cada vez más se preocupa por preservar esos atributos no solo durante unos pocos años o ciclos de productos, sino también durante décadas o incluso siglos. Todavía no hay arquitecturas, procesos o enfoques probados para lograr esto).
Estas posibles variaciones entre "poner en marcha" y "hacer lo que queremos", y cómo especificar, medir y prevenir tales variaciones, han sido un desafío durante mucho tiempo, incluso una vez que la redundancia, el endurecimiento y otros pasos hacia la falla. La tolerancia ha sido tomada. Y en el uso informal, "correr" y varias formas de "correr como yo quiero" se combinan, sin todas las distinciones claras que uno desearía.
fuente