Sistemi / programmi / algoritmi distribuiti / ... sono spesso descritti con il predicato robusto o fault-tolerant .
Qual è la differenza?
Dettagli:
Quando google per + robust + "fault-tolerant", ottengo solo due hit, entrambi inutili.
Quando ho googlescholar per i termini, trovo molti documenti che hanno entrambi i termini nel titolo. Sfortunatamente, non definiscono con precisione i termini :( Ma dal momento che usano entrambi i termini, sembra che nessuno dei due implichi l'altro.
Entrambi descrivono la coerenza del comportamento di un'applicazione, ma "robustezza" descrive la risposta di un'applicazione al suo input , mentre "fault tolerance" descrive la risposta di un'applicazione al suo ambiente .
Un'app è solida 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 è solido quando può continuare a decodificare un MP3 dopo aver incontrato un fotogramma malformato. Un editor di immagini è solido quando può modificare un'immagine con metadati EXIF incorporati che potrebbe non riconoscere, specialmente se può apportare modifiche all'immagine senza distruggere i dati EXIF.
Un'app è a tolleranza d'errore quando può lavorare in modo coerente in un ambiente incoerente. Un'applicazione di database è a tolleranza d'errore quando può accedere a un frammento alternativo quando il primario non è disponibile. Un'applicazione Web è a tolleranza d'errore quando può continuare a gestire le richieste dalla cache anche quando un host API non è raggiungibile. Un sottosistema di memoria è a tolleranza di errore 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 robustezza, è possibile trovare i criteri che coinvolgono i dati, mentre quando si valuta la tolleranza di errore, si troveranno criteri che implicano il tempo di attività.
Uno non conduce necessariamente all'altro. Un'app mobile di riconoscimento vocale può essere molto robusta, fornendo una straordinaria 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 fault-tolerant. Allo stesso modo, un'applicazione di web publishing può essere immensamente tollerante ai guasti, con ridondanze multiple a tutti i livelli, capace di perdere interi data center senza fallire, ma se si abbassa una tabella utente e si blocca la prima volta qualcuno si registra con un apostrofo nel loro cognome , non è affatto robusto.
Se stai cercando una letteratura accademica che aiuti a descrivere la distinzione, potresti cercare in domini specifici che fanno uso di software, piuttosto che in generale su software in generale. La ricerca di applicazioni distribuite potrebbe essere un terreno fertile per i criteri di tolleranza agli errori e Google ha pubblicato alcune delle sue ricerche che potrebbero essere pertinenti. La ricerca sulla modellazione dei dati probabilmente affronta questioni di robustezza, in quanto gli scienziati sono particolarmente interessati alle proprietà di robustezza che danno risultati riproducibili. Probabilmente è possibile trovare documenti che descrivono applicazioni statistiche che potrebbero essere utili, come la modellazione del clima, la modellazione della propagazione RF o il sequenziamento del genoma. Troverai anche ingegneri che discutono di "design robusto" in cose come i sistemi di controllo.
Il whitepaper di Google File System descrive il loro approccio ai problemi di tolleranza agli errori, che generalmente implica l'ipotesi che i guasti dei componenti siano di routine e quindi l'applicazione deve adattarsi a loro:
Questo progetto per una classe in Rutgers supporta una definizione di "tolleranza agli errori" orientata ai "componenti difettosi":
Ci sono un sacco di articoli su "modellazione robusta XYZ", a seconda del campo che studi. Molti descriveranno i loro criteri per "robusti" in astratto, e scoprirete che tutto ha a che fare con il modo in cui il modello si occupa dell'input.
Questo breve resoconto 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 di protocollo wireless, un dominio in cui tolleranza agli errori e robustezza si sovrappongono, ma gli autori usano "robusto" per descrivere applicazioni, protocolli e algoritmi, mentre usano "tolleranza di errore" in riferimento alla topologia e ai componenti:
Mi piace molto la risposta di @ johnnyb e approvarla per le sue definizioni nitide. Ma avendo lavorato sul campo per alcuni decenni, riconosco un altro (molto meno formale e preciso) modo in cui questi termini sono usati frequentemente:
Come punti informali lungo un continuum da "inaffidabile" a "perfettamente affidabile".
Non ci sono sistemi, applicazioni o servizi che possano garantire che saranno sempre e per sempre al lavoro ("continuamente disponibili" o "permanentemente disponibili"). "Fault tolerant" è stato a lungo un sostituto di "abbiamo fatto tutto quanto umanamente possibile con la tecnologia attuale per assicurarci che questa cosa continui a funzionare correttamente".
Parole come "robusto", "indurito" e "altamente disponibile" vengono usate come pietre miliari più morbide verso quell'obiettivo di funzionamento continuo. Riflettono livelli crescenti di impegno, investimento e fiducia.
Poiché questi termini sono usati in modo informale, non esiste un ordinamento interamente canonico. "Molto disponibile" è di solito un reclamo strong, appena sotto "fault resilient" o "fault tolerant". Ma è "indurito" meglio di "robusto"? O vice versa? Dipende dal contesto. Questi sono anche usati frequentemente come rivendicazioni di marketing di prodotto, con tutte le vanterie e le imprecisioni intenzionali che comportano.
Di solito le organizzazioni che lavorano verso questi obiettivi hanno una propria progressione concordata internamente, di solito almeno approssimativamente legata agli obiettivi / risultati del progetto e metriche esterne come " three nines "o" six nines. "
@johnnyb tocca anche una distinzione fondamentale: la differenza tra lo stato della piattaforma up / down (disponibilità) da una parte e gli attributi dell'algoritmo, dell'applicazione o del servizio dall'altra.
Dico "attributi" perché ce ne sono molti: prestazioni, correttezza e imperturbabilità sono solo alcune di quelle chiave. Un sistema è significativamente disponibile e corretto se funziona solo al 10% delle prestazioni nominali? Non secondo gli imprenditori se è la stagione impegnativa! Non c'è una grande virtù in un sistema che non scenda mai veramente, ma che dia anche risposte errate per la maggior parte del tempo. Infine, un sistema di analisi dei dati funziona "a destra" se una variazione dello 0,2% nell'input dà una risposta diversa al 3,400%? Forse ... ma sembrerà un modello piuttosto capriccioso e insoddisfacente per molti. Non passerò attraverso l'elenco esteso di 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 quegli attributi non solo nel corso di pochi anni o cicli di prodotto, ma in periodi di decenni o forse anche di secoli. Non ci sono ancora architetture, processi, provati o approcci per realizzare questo.)
Queste possibili differenze tra "attivo e funzionante" e "fare ciò che vogliamo" - e come specificare, misurare e prevenire tali scostamenti - sono state a lungo una sfida, anche una volta la ridondanza, l'indurimento e altri passaggi verso la tolleranza d'errore sono stati presi. E nell'uso informale, "correre" e varie forme di "correre come voglio io" sono fuse, senza tutte le distinzioni chiare che si vorrebbe.
Leggi altre domande sui tag error-handling errors architecture definition failure