Le minacce alla Dependability di un sistema informatico

Le minacce alla Dependability di un sistema informatico

Il ciclo di vita del sistema, secondo l’ingegneria del software, può essere diviso sostanzialmente in due parti: la fase di sviluppo e la fase di utilizzo. La fase di sviluppo include tutte quelle attività che vanno dalla presentazione dell’idea iniziale del sistema alla decisione che il sistema sviluppato è pronto per essere messo in servizio. Durante tutta questa fase di progettazione può capitare che vengano inseriti all’interno del sistema dei guasti di progettazione (development fault). La fase di utilizzo inizia quando il sistema è messo in opera e l’utente finale può beneficiare del servizio offerto. In questa fase gli stati in cui può venirsi a trovare il sistema sono tre: il primo consiste nel corretto funzionamento, il secondo identifica un fallimento del sistema con conseguente interruzione di servizio (outage), mentre il terzo consiste nello stop forzato del sistema da parte di un utente autorizzato (service shutdown). Vengono poi definite le operazione di ripristino (restoration), cioè l’attività di riportare il sistema ad uno stato funzionante in seguito ad un fallimento, e di manutenzione ( maintenance ) che comprende gli interventi di riparazione effettuati sul sistema e anche tutte quelle semplici modifiche che vengono apportate per migliorarne il servizio. La manutenzione può essere intrapresa sia successivamente alla fase di utilizzo, sia contemporaneamente.

Introduciamo ora tre importanti concetti: il fallimento del sistema (failure) che consiste nella non corrispondenza dei servizi offerti dal sistema con le specifiche definite in fase di sviluppo, l’errore (error) che è la parte dello stato del sistema che causa un fallimento e il guasto (fault) che è la causa dell’errore. Il guasto viene definito attivo se origina un errore, altrimenti dormiente.

Le minacce alla Dependability di un sistema informatico

Guasti

In ambito informatico il guasto viene definito come una condizione di anomalia del sistema hardware o software. Le cause che possono indurre un guasto possono avere diversa origine e natura: possono essere difetti di progettazione del sistema, oppure problemi di interazione del sistema con l’ambiente circostante, oppure ancora avarie della componentistica hardware. Relativamente ai guasti del sistema è possibile utilizzare la classificazione fornita da Avizienis, secondo il quale è possibile identificare 16 tipologie di guasti software. Queste 16 tipologie sono a loro volta classificate in 8 sottoclassi chiamate classi di guasto elementari.

I criteri di classificazione sono i seguenti.

Il momento della vita del software in cui si origina il guasto.

Guasti di progetto: guasti che vengono generati durante lo sviluppo del software o nella fase di manutenzione.

Guasti operativi: guasti che vengono generati durante l’utilizzo del sistema.

La posizione del guasto.

Guasti interni: guasti che vengono generati all’interno del sistema.
Guasti esterni:  guasti che  vengono generati all’esterno del sistema e si propagano all’interno dello stesso causa interfacciamento o comunicazione.

La natura del guasto.

Guasti naturali: guasti causati da fenomeni ambientali senza la responsabilità umana.
Guasti causati dall’uomo: guasti causati dall’azione dell’uomo.

Il livello in cui il guasto si trova.

Guasti hardware: guasti che affliggono l’hardware.
Guasti software: guasti che affliggono il software, come ad esempio programmi o dati.

Il motivo della presenza del guasto.

Guasti maliziosi: guasti introdotti nel sistema con l’intento di causare danni al sistema.
Guasti non maliziosi: guasti introdotti nel sistema senza volontà.

L’intento di chi ha introdotto il guasto all’interno del sistema.

Guasti intenzionali: guasti intenzionali inseriti con la volontà di arrecare danno.
Guasti non intenzionali: guasti introdotti senza consapevolezza.

Le capacità della persona che ha introdotto l’errore.

Guasti accidentali: guasti inseriti accidentalmente.
Guasti dovuti ad incompetenza: guasti inseriti a causa dell’inadeguatezza ed incompetenza del programmatore autorizzato.

La persistenza nel tempo dell’errore.

Guasti permanenti: guasti che si presumono essere costanti nel tempo.
Guasti transienti: guasti la cui presenza è temporalmente limitata.

I 3 grandi gruppi dei gusti

Le classi di guasto combinato vengono quindi riassunte in 3 grandi gruppi:

Guasti di sviluppo che comprendono tutte quelle classi di guasto che si verificano in fase di sviluppo del sistema. Guasti fisici che comprendono quelle classi di guasto che affliggono l’ hardware. Guasti di interazione che comprendono quelle classi di guasto relative guasti esterni al sistema.

I guasti poi possono poi essere classificati in base alla loro persistenza nel sistema:

Guasti permanenti: sono guasti che si verificano in modo continuato. Guasti transienti: sono guasti che si verificano temporaneamente, in seguito ad una singola circostanza di errore, e non hanno bisogno di intervento di manutenzione poiché svaniscono da soli. Guasti intermittenti: sono guasti che si verificano occasionalmente e in diversi intervalli di tempo.

La differenza sostanziale tra guasti intermittenti e transienti è che i primi solitamente sono problemi che affliggono l’hardware e che possono quindi essere facilmente risolti con la riparazione della parte fisica del sistema, mentre invece i guasti transienti, o temporanei, proprio per la loro non ripetitività, sono più difficili da individuare e per questo sono spesso causa di fallimento per un sistema software. É importante secondo Avizienis partire dal presupposto che le cause che portano ad un guasto interno al sistema software sono il più delle volte per loro natura permanenti quindi, per fare un esempio, un errore di progettazione dell’applicazione porterà sempre al medesimo guasto del sistema fino a quando non si interverrà con opportune modifiche.

Fallimenti

Un fallimento è definito come l’evento che si verifica quando il sistema fornisce un servizio non in linea con quanto richiestogli. I fallimenti possono verificarsi con diverse modalità e differiscono tra loro per la gravità del disservizio arrecato. Ciò che è importante tenere presente è che un fallimento va sempre rapportato con quella che è la funzione del sistema e non con quanto scritto nelle specifiche poiché potrebbe accadere che il sistema, pur soddisfacendo le specifiche iniziali, non soddisfi la volontà del cliente. Questo significa che vi è stato un errore nella stesura delle specifiche di progetto e tale errore è riconoscibile solo dopo la sua comparsa, quindi a sistema già in funzione.

Le varie modalità con cui un sistema può incorrere in un fallimento sono detti modi di fallimento e vengono categorizzati secondo quattro punti di vista:

  • Dominio (Domain): Bisogna distinguere il caso in cui il fallimento sia dovuto al fatto che le informazioni inviate all’interfaccia del sistema si discostano dalla normale funzione del sistema, oppure al fatto che il tempo di arrivo o di durata dell’erogazione delle informazioni si discosta da quanto definito nelle Quando il fallimento del sistema è causato da entrambi i casi allora il sistema può cadere in uno stato di fallimento dove si verifica un blocco totale del sistema che non ritorna alcuna informazione all’interfaccia. Nello stato di blocco totale può anche accadere che alcune informazioni vengano inviate all’interfaccia ma queste sono comunque erronee.
  • Controllabilità (Detectability): si riferisce alla proprietà del sistema di segnalare all’utente lo stato di errore. A volte i sistemi sono progettati per fallire seguendo modalità precise. Questo avviene tramite meccanismi di rilevazione della correttezza del servizio In questo modo vengono generati fallimenti controllati, detti fallimenti segnalati, che il sistema controlla attuando contromisure come può essere il riavvio controllato del sistema.
  • Consistenza (Consistency): Quando il sistema ha due o più utenti definiamo il fallimento consistente se tutti gli utenti hanno la medesima percezione dell’errore, altrimenti incosistente se qualche utente percepisce diversamente la scorrettezza del servizio.
  • Conseguenze (Conseguences): i fallimenti vengono classificati secondo la gravità delle conseguenze, questa classificazione prevede una suddivisione sostanziale tra fallimenti minori, che hanno conseguenze accettabili e i costi di manutenzione minimi, e fallimenti catastrofici, dove il costo delle conseguenze del fallimento è di gran lunga maggiore rispetto al guadagno che si trarrebbe dall’erogazione corretta del servizio.

Errori

Si definisce l’errore come la parte dello stato totale del sistema che può portare ad un fallimento, questo avviene quando l’errore è in grado di discostare il servizio del sistema dal corretto funzionamento. Con “ stato totale del sistema” si intende l’insieme di tutti gli stati dei componenti che combinati identificano il sistema totale.

Questo fa sì che l’errore inizialmente sia limitato ad un singolo componente (o più di uno) e che questo si traduca in fallimento del sistema solo quando questo errore va a manifestarsi non più solo a livello di singola componente ma dell’intero sistema. Fino a questo momento infatti l’errore rimane limitato allo stato del componente interno e non influenza lo stato totale del sistema.

La causa di un errore è ciò che in precedenza abbiamo definito guasto. Un errore si dice errore rilevato se questo viene segnalato da un messaggio di errore o da qualsiasi altra forma di segnalazione, altriementi viene detto errore latente. Non abbiamo una classificazione propria degli errori, questo perché si usa descriverli sulla base della classificazione delle tipologie di fallimento. Una eventuale classificazione può essere data in base alla tipologia del danno causato: se singolo, per esempio, nel senso che affligge un solo componente oppure se multiplo, come può accadere in seguito ad una scarica elettromagnetica in grado di coinvolgere più componenti contemporaneamente.

È possibile evitare che un errore porti ad un fallimento implementando nel sistema una qualche forma di ridondanza. Vedremo nel dettaglio queste tecniche nel quarto capitolo. É altresì possibile non arrivare ad un fallimento qualora la parte dello stato affetta da errore non venga mai utilizzata dal sistema o qualora questa venga corretta prima della sua attivazione.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *