La fragilità dei sistemi

Solo per citare due eventi recenti: un apparente errore umano di un tecnico ha gettato i voli di British Airways nel caos per un weekend e un presunto ex dipendente avrebbe messo in ginocchio i servizi di Verelox.

Basta così poco? Vi facciamo fanno credere che i sistemi siano ridondati, fault tolerance, resilienti, inattaccabili, sicuri… E poi basta uno che stacca un’alimentazione a mandare tutto a donne di facili e assai licenziosi costumi.

Il problema principale è che i sistemi sono complessi e interdipendenti.

Il progettista del data centre vi darà l’alimentazione ridondante da due fonti differenti con due gruppi elettrogeni, due UPS e due PDU nel rack.

Chi sceglie l’hardware prende ogni dispositivo con alimentatore ridondante hot-swap.

Il sistema di virtualizzazione è pienamente ridondante e fault tolerant con reboot automatico delle VM in caso di guasto o VM che girano contemporaneamente su due host1414

Il backup avviene secondo i dettami della SLA e l’RTO è testato e garantito.

Il sistema operativo è completamente virtualization-aware e può riavviarsi dovunque nel mondo.

Poi ci si mette il software applicativo: strati geologici di modifiche, con svariate tecnologie applicate lì così perché in quel momento faceva figo usare quella tecnologia, magari con hardcoded l’indirizzo IP del database server, per velocizzare.

Potrei continuare: ogni singolo elemento preso da solo è lo stato dell’arte della tecnologia e funziona alla perfezione. Se esistesse solamente lui.

I problemi nascono quando c’è interazione tra gli elementi o quando uno si comporta in maniera erratica, ovvero non si guasta completamente.

Per definizione, i casini veri succedono quando capita qualcosa di imprevisto o definito poco probabile: il numero di interazioni tra i vari sistemi è tale che è onestamente impossibile prevedere ogni possibile combinazione di guasti.

Poi ci si mettono anche le manomissioni deliberate o presunte tali: spesso è più facile dare la colpa ad un ex dipendente piuttosto che ammettere di aver disegnato male l’infrastruttura. È sempre colpa degli assenti.

Se prevedere l’imprevedibile è difficile (ma non impossibile), contrastare i danni da manomissioni o guasti ai dischi è relativamente più semplice.

Un buon sistema di disaster recovery (enfasi su recovery perché il disaster siam bravi tutti a farlo) salva da questa classe di problemi e magari evita di dover avere per qualche giorno la home page come quella di Verelox:

Se in una piccola realtà non ci sono le risorse per provare ogni anno il recovery dalla distruzione totale di tutta infrastruttura, man mano che l’organizzazione cresce dovrebbe trovare il tempo per fermarsi e considerare se dall’alimentazione agli applicativi con tutte le loro interfacce possono essere ripristinati senza problemi e, possibilmente, senza che il ripristino di un servizio abbia troppe dipendenze da altri servizi esterni. Ad esempio: se non sono disponibili il domain controller AD o la connessione a Internet, cosa è possibile ripristinare e come?

Sono domande che ci si deve porre quando pensiamo come far ripartire tutto quanto e più domande ci poniamo, meno risposte scomode dovremo dare quando (non se, ma quando) succedono i disastri.