Come gestire gli errori in un sistema distribuito

-3

Nella mia esperienza, la maggior parte degli errori in un'applicazione sono bug :

  • Errore di sintassi
  • Intervallo errore (numero fuori limite)
  • Errore di riferimento (variabile non definita utilizzata)
  • digita errore
  • Asserzioni personalizzate

Questi dovrebbero essere catturati prima che un'applicazione sia in produzione. Se non vengono catturati, in genere l'applicazione si blocca .

Altri tipi di errori possono essere "recuperati da". Gli esempi includono:

  • Errore caricamento immagine
    • Soluzione: prova a caricare di nuovo alcune volte. E / o visualizzare un'immagine predefinita.
  • Errore di rete (più generale)
    • Soluzione: riprova. Altrimenti, nessuna soluzione.
  • Errore hardware
    • Soluzione: avere i server di backup in attesa di essere usati forse

Altri tipi sono nel mezzo:

  • Errore di sicurezza: tentativo di accedere a una risorsa senza credenziali o protocollo appropriati.
  • Errore memoria insufficiente
  • Errori di sistema distribuiti

La domanda è cosa dovresti fare con gli errori in generale in un sistema distribuito, magari concentrandoti solo su quelli di "livello medio". Invece di arresti anomali dell'app.

Forse c'è un approccio standard a questo. Ho sempre interrotto l'app e ho registrato l'errore, che sarebbe poi stato documentato come un bug. Quindi aggiungeremo del codice per evitare che si verifichi un arresto anomalo, risolvendo l'errore in qualche modo (ad esempio se la directory padre non esisteva quando si creava una directory con mkdir , magari passare a mkdir -p ), oppure inviando una notifica all'utente finale per riprovare, provare questo o quello in altro modo, o far loro sapere che abbiamo registrato l'errore.

Ma in un sistema puramente programmatico, non c'è umano a cui riportare l'errore per facilitare la continuazione del processo (anche se potremmo registrare l'errore per il debugging successivo). Invece, il sistema ha bisogno di crash o gestire l'errore .

Questa è la domanda principale:

How to deal with errors in a distributed system.

Se blocchi l'app, potresti perdere un sacco di dati memorizzati in memoria. Quindi, forse prima del crash, fai un dump (specificato dallo sviluppatore dell'applicazione), che può essere usato per "ripristinare" l'app in qualche modo (come il modo in cui il browser Chrome ripristina le tue schede dopo un arresto anomalo in qualche modo). Forse ci sono modi sofisticati per riprendere lo stato poco prima dell'errore, ma non fare ciò che ha causato l'errore questa volta . Non so come funzionerebbe o sarebbe possibile. O forse il sistema agisce "cautamente" su quel percorso di valutazione del codice la prossima volta (fino a quando l'errore non viene corretto), quindi non lo valuta, e restituisce invece una risposta standard che viene spiegata nella base del codice.

Mi sto solo chiedendo quali sono le tecniche generali per gestire gli errori in un sistema distribuito. Come recuperare da loro, o spostarsi (continuare l'elaborazione con try / catch sorta thing), in modo che il sistema non si arresti mai realmente ed è sempre in uno stato pulito noto . Non sono sicuro che sia possibile ma ho pensato di chiedere. Ovviamente non vuoi semplicemente provare / catturare ogni errore e semplicemente ignorarlo, ciò vanificherebbe lo scopo degli errori.

    
posta Lance Pollard 03.07.2018 - 18:10
fonte

1 risposta

1

Ho un pregiudizio verso la scrittura di software per le aziende, o quello che potrebbe essere chiamato software aziendale "e" minuscolo. Ci sono un certo numero di ipotesi errate dietro la premessa della tua domanda. Iniziamo con:

most errors in an application are bugs

A meno che non stiamo cavillando sulla definizione di "molti", qui c'è una supposizione molto scarsa insieme alla tua definizione di bug. Tutti questi esempi sono i fallimenti di igienizzare adeguatamente e amp; controlla gli input per i tuoi metodi o servizi. Non abbiamo bisogno di essere Marvin il robot paranoico, ma i nostri metodi devono essere sicuri che non vengano dati dei rifiuti prima di mettere in produzione quel codice.

La prossima ipotesi importante è qui, e mentre seleziono questo commento, c'è un ricorrente nella tua domanda.

If they aren't caught, then typically the application will crash.

Per l'amore di tutto ciò che è buono e sacro, no, semplicemente no . Non eseguire non l'arresto anomalo dell'applicazione solo perché ha ricevuto input non validi o non ha superato una condizione logica o ... qualsiasi cosa. Registra l'errore, genera un'eccezione, continua a gestire il bajillion altre chiamate che l'applicazione termina per supportare.

Per parafrasare persone più sagge, la differenza tra un bug e un attacco malevolo è l'intento. Per coincidenza, è possibile proteggersi da entrambi contemporaneamente: riconoscere (controllo della guardia), segnalare (log), scappare (lanciare un'eccezione).

Ero solito pensare più da vicino come hai fatto fino a quando ho appreso che lo scopo del software (enterprise) è quello di soddisfare le regole del business. Raramente c'è tempo sufficiente per trovare e soddisfare il 100% di quelle regole, quindi costruiamo sistemi che speriamo siano abbastanza robusti da gestire la stragrande maggioranza dei percorsi che potremmo seguire.

Quindi usiamo i controlli di guardia, la registrazione e le eccezioni per proteggere dai casi che noi o l'azienda non prevedevamo. La registrazione centralizzata facilita l'aggregazione dei problemi. Il monitoraggio automatizzato lo rende ancora più efficace. I gestori di eccezioni non gestiti rappresentano un'altra tecnica per mantenere attiva l'applicazione.

Da lì monitoriamo, valutiamo e iteriamo secondo necessità e in base alle priorità del business.

    
risposta data 04.07.2018 - 15:40
fonte

Leggi altre domande sui tag