Ogni anno vengono perse milioni di ore a causa di interruzione di servizi e reti informatiche. Parliamo di dipendenti ed interi uffici fermi, impianti di produzione bloccati, vendite mancate, potenziali clienti perduti, di reputazione compromessa. E di Responsabili IT in grande imbarazzo. Perché il più delle volte non è un calamita naturale a causare l’interruzione, ma un semplice guasto hardware, l’improvvisa indisponibilità di una risorsa o un errore umano. Proviamo a dare alcune indicazioni per rendere più affidabili i servizi offerti dalla nostra infrastuttura.
1. Individuare i punti deboli del sistema
In inglese vengono chiamati Single point of failure. Si tratta di quei punti dell’infrastruttura in cui un singolo guasto può compromettere la funzionalità dell’intero sistema. Probabilmente nella nostra infrastruttura ci sono server e apparati di rete non ridondati (switch, firewall, router) ma anche facility esterne quali linee dati e linee elettriche. Anche il sistema di condizionamentodei locali server è un elemento da non sottovalutare: spesso è sottodimensionato ed una avaria può far fermare il nostro data center nell’arco di poche ore.
Non è detto che la soluzione sia “raddoppiare tutto”: per molte organizzazioni i costi di acquisto e di gestione di un sistema completamente ridondato sono improponibili. Per alcune realtà, disporre a magazzino di un certo numero di apparati di emergenza o stipulare dei contratti di assistenza sull’hardware con tempi di risposta veloci, costituisce già un buon paracadute.
2. Identificare le possibili minacce
“Se qualcosa può andare storto, lo farà” sentenziava la legge di Murphy. Nel vostro datacenter, grande o piccolo che sia, un sacco di cose possono andare storte. E purtroppo, prima o poi lo faranno. Se predisporre un elenco esaustivo delle sventure è impossibile, l’esperienza accumulata negli anni vi potrà certo permettere di considerare gli scenari più probabili e con impatto più alto sulla continuità del sistema.
Ricordiamoci inoltre che i grandi disastri dell’IT hanno sempre un concorso di cause (“l’applicazione aveva un bug, il monitoraggio era spento per manutenzione e il backup quella notte non aveva funzionato, …”). Quindi è riduttivo supporre che i problemi si presenteranno “ordinatamente” uno alla volta. Questo è un lavoro in cui essere pessimisti (senza sconfinare nel paranoico) può essere molto salutare.
Di solito la prima cosa da garantire è l’ integrità dei dati (oltre che l’incolumità delle persone in caso gestiate sistemi critici in ambiti sanitario o industriale). Qualsiasi cosa accada dovete garantire che i vostri dati vengano protetti il più possibile. Tradotto: se l’impianto di condizionamento si guasta la sala server va a 40° gradi i server devono spegnersi prima di… fondere o causare incendi.
3. Prepararsi all’evento infausto
Proviamo a immaginarci di fronte ad un degli eventi infausti che abbiamo individuato nel punto precedente. Di cosa avremmo bisogno per poter sistemare le cose? Le procedure per il restore sono documentate? Le password di sistema sono disponibili su supporti alternativi? I CD o i media per l’eventuale reinstallazione dei server sono reperibili? Abbiamo a disposizione un mezzo di comunicazione alternativo per informare gli utenti e dare indicazioni su come devono comportarsi o sui tempi previsti per il ripristino? (può darsi che le email non funzionino!).
Chiaramente le organizzazioni complesse avranno piani di gestione delle emergenze più sofisticati e collaudati (almeno si spera!) ma anche una piccola realtà dovrebbe sapere esattamente cosa fare e di cosa avrà bisogno in una ipotetica situazione critica. Prepararsi prima costa molto pocoed è sciocco non farlo.
4. Backup, ma non solo
Va da sé che nella nostra infrastruttura devono essere in esercizio procedure di backup dei dati efficaci, affidabili, il cui buon funzionamento è tenuto costantemente sotto controllo. Ma spesso questo non è sufficiente. Andiamo a verificare: le procedure di restore sono adeguatamente descritte? In tutte le possibili casistiche? Vengono eseguiti periodicamente dei test di restore? E ancora: quanto tempo impiega il restore dei dati? Questi tempi sono compatibili con gli SLA concordati o con i requisiti di continuità del mio business?
Diciamocelo: sono argomenti un po’ tediosi e demodé, ma se non vi sentite a vostro agio con i doveri dell’IT manager che si prende cura dei sui dati, forse questo non è il lavoro giusto per voi!
5. Tenere monitorato lo stato dell’infrastruttura
Dotarsi di un sistema di monitoraggio che tengasotto controllo lo stato della rete, dei sistemi e dei servizi applicativi è un passaggio oggigiorno irrinunciabile. State ancora valutando se vi serve o meno un sistema di monitoraggio? Probabilmente state perdendo del tempo prezioso.
Un sistema di monitoraggio vi consente ad esempio di sapere:
- se ci sono servizi fermi, prima che gli utenti o i clienti (o l’amministratore delegato) vi chiamino per lamentarsi;
- se il disco del database server sta esaurendo lo spazio, prima che la produzione o la contabilità si fermino (anzi, molto prima, per consentirvi di far arrivare nuovi dischi o un nuovo server);
- se la vostra rete sta subendo un degrado delle performance e per quale motivo, prima chel’ultimo neo-assunto la intasi del tutto nel tentativo di scaricare la discografia completa dei Pooh;
- se la temperatura della sala server è al di sopra dei valori di riferimento, prima che qualche server si guasti per surriscaldamento.
E’ garantito: senza un sistema di monitoraggio passerete la vostra esistenza a rincorrere e ad annaspare nei problemi.
Decidete voi.
6. Documentare, documentare, documentare
Anche questo, lo ammetto, è un’argomento un po’ impopolare. Se da un lato i file di word e di excel (che diventano obsoleti in meno di 24 ore) son duri a morire, dall’altro sempre più aziende decidono di creare la documentazione su sistemi online come i wiki, le knowledge base e CMDB (configuration management database). Nei casi d’eccellenza la documentazione è dinamica, automatizzata ed attinge direttamente ai sistemi di inventory, discovery o network management. Questo aiuta a mantenerla consistente ed aggiornata.
Ricordiamoci in ogni caso che ci sono situazioni in cui è vitale disporre onsite di una copia cartacea della documentazione. Non fate affidamento su reti e sistemi che potrebbero non essere disponibili proprio nel momento in cui ne avete bisogno. E’ buona abitudine redigere e stampare il cosiddetto running book che dovrebbe contenere quanto meno le informazioni essenziali per un primo soccorso:
- Il diagramma aggiornato della infrastruttura (fisico, logico e applicativo)
- Un elenco con le caratteristiche di tutti i server e la descrizione dei componenti software installati;
- Un dump delle configurazioni di firewall e switch;
- La descrizione delle procedure di restore;
- I numeri di telefono e i contatti delle aziende che forniscono servizi di assistenza e supporto;
- Le password principali di amministrazione (attenzione però a dove conservate queso running book!)
7. La sicurezza non è un optional
Sul rapporto tra sicurezza e disponibilità ci sono diverse scuole di pensiero. C’è chi sostiene che policy di sicurezza troppo stringenti e strette aumentino la possibilità che qualcosa vada storto ed il servizio diventi indisponibile a causa dell’intervento di un meccanismo di protezione.
Per contro è evidente che un sistema vulnerabile è molto più esposto ad interruzioni e perdite di daticausate da intrusioni ed accessi inautorizzati. Ma non solo. E’ noto che una buona percentuale delle interruzioni dei servizi IT sono causate da errori umani involontari. Per evitare che questi errori si traducano in disastri c’è un principio molto semplice: minimi privilegi per chiunque. Ciascun utente dovrebbe essere abilitato ad eseguire le operazioni strettamente necessario al proprio ruolo e nulla di più. In questo modo anche eventuali errori hanno un impatto circoscritto.
8. Gestire i cambiamenti
Un’altra fetta sostanziosa di interruzioni è causata da una mancata applicazione del change management da parte del reparto IT. Si tratta di cambiamenti che vengono apportati all’infrastruttura senza una adeguata analisi degli impatti e delle modalità corrette di implementazione. Accade così che una nuova regola sul firewall per un nuovo servizio implementato va inficiare sulle funzionalità di un’altra applicazione già in uso. Gli esempi sono tanti. I cambiamenti apportati senza le opportune attività di analisi, pianificazione e verifica possono portare a risultati inaspettati e poco piacevoli.
9. Acquisire e coltivare le competenze interne
Anche questo punto può sembrare banale ma è necessario sottolinearlo. La competenza professionale di chi opera sui sistemi non è un fattore secondario e nei momenti critici fa la differenza (enorme). I tecnici competenti causano meno disservizi e meno interruzioni durante le loro attività ordinarie, inoltre sono solitamente in grado di diagnosticare e risolvere i problemi molto più velocemente. Risparmiare sulle persone, è davvero risparmiare?
