Qual è la differenza tra robustezza e tolleranza agli errori?


12

Sistemi / programmi / algoritmi distribuiti / ... sono spesso descritti con il predicato robusto o tollerante ai guasti .

Qual è la differenza?


Dettagli:

Quando utilizzo Google + + + "fault-tolerant", ottengo solo due risultati, entrambi inutili.

Quando googlescholar per i termini, trovo molti articoli che hanno entrambi i termini nel loro titolo. Sfortunatamente, non definiscono esattamente i termini :( Ma poiché usano entrambi i termini, sembra che nessuno dei due implichi l'altro.



Sì, è stata una delle prime cose che ho letto per scoprirne il significato. Sfortunatamente, entrambi descrivono la stessa cosa a livello astratto, senza fare riferimento all'altra. Ecco perché lo sto chiedendo qui.
DaveFar

Risposte:


33

Entrambi descrivono la coerenza del comportamento di un'applicazione, ma la "robustezza" descrive la risposta di un'applicazione al suo input , mentre la "tolleranza agli errori" descrive la risposta di un'applicazione al suo ambiente .

Un'app è affidabile quando può funzionare in modo coerente con dati incoerenti. Ad esempio: un'applicazione di mappe è robusta quando può analizzare gli indirizzi in vari formati con vari errori di ortografia e restituire una posizione utile. Un lettore musicale è robusto quando può continuare a decodificare un MP3 dopo aver incontrato un frame non valido. Un editor di immagini è robusto quando può modificare un'immagine con metadati EXIF ​​incorporati che potrebbe non riconoscere, soprattutto se può apportare modifiche all'immagine senza distruggere i dati EXIF.

Un'app è tollerante agli errori quando può funzionare in modo coerente in un ambiente incoerente. Un'applicazione di database è tollerante agli errori quando può accedere a un frammento alternativo quando il primario non è disponibile. Un'applicazione Web è tollerante agli errori quando può continuare a gestire le richieste dalla cache anche quando un host API non è raggiungibile. Un sottosistema di archiviazione è tollerante agli errori quando può restituire risultati calcolati dalla parità quando un membro del disco è offline.

In entrambi i casi, l'applicazione dovrebbe rimanere stabile, comportarsi in modo uniforme, preservare l'integrità dei dati e fornire risultati utili anche quando si verifica un errore. Ma quando si valuta la solidità, è possibile trovare criteri che coinvolgono i dati, mentre quando si valuta la tolleranza agli errori, si trovano criteri che coinvolgono il tempo di attività.

Uno non porta necessariamente all'altro. Un'app di riconoscimento vocale mobile può essere molto robusta, offrendo un'incredibile capacità di riconoscere il parlato in modo coerente in una varietà di accenti regionali con enormi quantità di rumore di fondo. Ma se è inutile senza una connessione dati cellulare veloce, non è molto tollerante agli errori. Allo stesso modo, un'applicazione di pubblicazione Web può essere immensamente tollerante ai guasti, con più ridondanze ad ogni livello, in grado di perdere interi data center senza errori, ma se elimina una tabella utente e si arresta in modo anomalo la prima volta che qualcuno si registra con un apostrofo nel suo cognome , non è affatto robusto.

Se stai cercando letteratura accademica per aiutare a descrivere la distinzione, potresti cercare in domini specifici che utilizzano il software, piuttosto che il software in generale. La ricerca sulle applicazioni distribuite potrebbe essere un terreno fertile per i criteri di tolleranza agli errori e Google ha pubblicato alcune delle loro ricerche che potrebbero essere pertinenti. La ricerca sulla modellizzazione dei dati probabilmente affronta questioni di robustezza, in quanto gli scienziati sono particolarmente interessati alle proprietà di robustezza che producono risultati riproducibili. Probabilmente puoi trovare articoli che descrivono applicazioni statistiche che potrebbero essere utili, come nella modellazione climatica, nella propagazione RF o nel sequenziamento del genoma. Troverai anche ingegneri che discutono di "design robusto" in cose come i sistemi di controllo.

Il white paper di Google File System descrive il loro approccio ai problemi di tolleranza agli errori, che generalmente implica le ipotesi che i guasti dei componenti siano di routine e quindi l'applicazione deve adattarsi a loro:

Questo progetto per una classe presso Rutgers supporta una definizione orientata a "guasti ai componenti" di "tolleranza agli errori":

Ci sono un sacco di documenti sulla "solida modellazione XYZ", a seconda del campo che si indaga. La maggior parte descriverà i loro criteri per "robusti" in astratto e scoprirai che tutto ha a che fare con il modo in cui il modello gestisce l'input.

Questo brief di uno scienziato del clima della NASA descrive la robustezza come criterio per la valutazione dei modelli climatici:

Questo documento di un ricercatore del MIT esamina le applicazioni del protocollo wireless, un dominio in cui la tolleranza agli errori e la robustezza si sovrappongono, ma gli autori usano "robusti" per descrivere applicazioni, protocolli e algoritmi, mentre usano la "tolleranza agli errori" in riferimento alla topologia e componenti:


0

Mi piace molto la risposta di @ johnnyb e la approvo per le sue definizioni chiare . Ma avendo lavorato sul campo per alcuni decenni, riconosco un altro modo (molto meno formale e preciso) in cui questi termini vengono frequentemente utilizzati:

Come punti informali lungo un continuum da "inaffidabile" a "perfettamente affidabile".

Non esiste alcun sistema, applicazione o servizio in grado di garantire che sarà sempre e per sempre al lavoro ("continuamente disponibile" o "permanente disponibile"). "Tollerante ai guasti" è stato a lungo un sostituto per "abbiamo fatto tutto umanamente possibile con la tecnologia attuale per assicurarci che questa cosa continui a funzionare correttamente".

Parole come "robusto", "indurito" e "altamente disponibile" sono utilizzate come pietre miliari più morbide verso l'obiettivo di un funzionamento continuo. Riflettono livelli crescenti di sforzo, investimenti e fiducia.

Poiché questi termini sono utilizzati in modo informale, non esiste un ordinamento completamente canonico. "Altamente disponibile" è di solito una rivendicazione forte, appena sotto "resiliente ai guasti" o "tollerante ai guasti". Ma "indurire" è meglio di "robusto"? O vice versa? Dipende dal contesto. Questi sono anche frequentemente utilizzati come rivendicazioni di marketing del prodotto, con tutta l'imprecisione intenzionale e vanagloria che comporta.

Di solito le organizzazioni che lavorano per raggiungere questi obiettivi hanno una propria progressione concordata internamente, di solito almeno approssimativamente collegata a obiettivi / risultati del progetto e metriche esterne come "tre nove" o "sei nove".

@johnnyb tocca anche una distinzione critica: la differenza tra lo stato su / giù della piattaforma (disponibilità) da un lato e gli attributi di algoritmo, applicazione o servizio dall'altro.

Dico "attributi" perché ce ne sono molti: prestazioni, correttezza e imperturbabilità sono solo alcuni di quelli chiave. Un sistema è significativamente disponibile e corretto se funziona con solo il 10% delle prestazioni nominali? Non secondo gli imprenditori se è la stagione frenetica! Non esiste una grande virtù in un sistema che non va mai veramente giù, ma che dà anche risposte errate per la maggior parte del tempo. Infine, un sistema di analisi dei dati funziona "correttamente" se una variazione dello 0,2% in input fornisce una risposta diversa al 3,400%? Forse ... ma a molti sembrerà un modello piuttosto capriccioso e insoddisfacente. Non esaminerò l'elenco esteso degli attributi, ma l'integrità dei dati, la sicurezza dei dati, la privacy dei dati e altri problemi di correttezza e sicurezza sono preoccupazioni comuni. (Se sei un'organizzazione molto grande o un'agenzia governativa, ti preoccupi sempre più di preservare tali attributi non solo per alcuni anni o cicli di prodotti, ma per decenni o forse addirittura secoli. Non ci sono ancora architetture, processi o approcci comprovati per raggiungere questo obiettivo.)

Queste possibili variazioni tra "up and running" e "fare ciò che vogliamo" - e come specificare, misurare e prevenire tali varianze - sono state a lungo una sfida, anche una volta che la ridondanza, l'indurimento e altri passi verso l'errore - tolleranza è stata presa. E nell'uso informale, "correre" e varie forme di "correre come voglio io" si fondono, senza tutte le chiare distinzioni che uno vorrebbe.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.