Fra gli innumerevoli compiti dei netework manager, uno dei più spinosi è la gestione dei blocchi di sistema e di rete. In questo senso, vi proponiamo 5 "building block" che possono aiutarvi a costruire un valido programma di incident management:
- Configurazione del database e audit
- Esperti esterni
- Triage (interpretazione e stima della gravità dell'incidente)
- Strumentazione
- Dye tracing
Avvalendovi di questi blocchi logici e di un competente responsabile, dovreste poter dar vita a un efficace e tranquillo sistema, in grado di gestire con meno stress sia gli eventi sistematici sia i problemi complessi.
Configurazione del database e audit
E' estremamente importante disporre di un configuration management database (CMDB) singolo e unificato, completamente aggiornato. A tale database possiamo chiedere quali sono stati i cambiamenti fatti nei componenti strategici nei momenti immediatamente antecedenti al guasto; possiamo anche chiedergli cosa accadrà se blocchiamo un particolare elemento per effettuarne la manutenzione.
Nel mondo reale, purtroppo, è praticamente impossibile trovare in azienda un CMDB. Di conseguenza, il system manager dovrebbe iniziare l'organizzazione pensando all'implementazione di un CMDB. Tale implementazione quasi certamente richiederà di stabilire severi richiami per ogni persona dello staff che opererà dei cambiamenti nel CMDB senza registrarli. Comunque sia, con o senza il CMDB, l'audit quotidiano e onnicomprensivo è uno strumento critico.
Tutte le applicazioni importanti dovrebbero essere riviste con regolarità tramite l'audit onnicomprensivo per rilevare le loro dipendenze e aggiornare la documentazione. Se una certa applicazione mission-critical gira su un Pc economico dimenticato sotto qualche scrivania, o sta funzionando soltanto perché gli sviluppatori hanno creato uno script Perl per mettere una pezza a qualche bug, è bene scoprirlo prima che si verifichi una crisi.
Perciò, almeno una volta al giorno, dovrebbe essere eseguito un audit rapido della rete e della configurazione di sistema per rilevare tutti i cambiamenti o i parametri e le configurazioni che esulano dalle specifiche. Per esempio, il tool NetMRI da Netcordia può individuare e documentare le modifiche apportate nella topologia e nella configurazione degli elementi della rete. Può anche far girare degli script per scoprire i cambiamenti incompatibili con la configurazione. Tool simili sono disponibili per i server e altri componenti di sistema. L'idea chiave è individuare i cambiamenti nella configurazione prima che interagiscano con eventuali malfunzionamenti successivi e diano così vita a una vera catastrofe. Anche se il loro effetto non è immediatamente riconosciuto, la documentazione dei cambiamenti è di grande aiuto ai troubleshooter nel caso si verifichi un problema.
Esperti esterni
Poche organizzazioni hanno al roprio interno l'esperienza per gestire problemi estremamente complessi. Perciò, solitamente, quando questi problemi compaiono, è bene ricorrere a esperti diagnostici esterni, che conoscono in modo dettagliato molti componenti di sistema e che hanno già affrontato differenti situazioni di grave crisi.
Per trovare questi esperti potete contattare i principali fornitori per sapere a chi ricorrono quando hanno un problema multi-vendor. Organizzate il lavoro affinché tali esperti lavorino a fianco del vostro staff durante la messa a punto dei programmi per la system instrumentation e per il triage (vedi dopo), quindi assicuratevi che siano sempre disponibili nell'eventualità che si verifichi qualche problema che non siete in grado di risolvere autonomamente.
Triage (intepretazione e stima della gravità dell'incidente)
Il triage si pone tre obiettivi:
1. Riconoscere e interpretare gli incidenti (trovando una veloce soluzione)
2. Isolare i problemi in un sottosistema per presentarli all'organizzazione responsabile
3. Individuare rapidamente problemi complessi e con
alto rischio di crisi
Anche se un incidente non viene riconosciuto, è spesso possibile isolarlo in un sottosistema particolare se è disponibile la metrica adatta. Per esempio, molti agent possono testare ripetutamente il DNS, tutti i percorsi di accesso a Internet, la disponibilità e le prestazioni delle VLAN critiche, il tempo di risposta alle principali query ai database e molte altre funzioni..
Se i tecnici di rete non riconosce un problema come un comune incidente, e quindi non possono isolarlo rapidamente in un particolare sottosistema, è necessario avvisare il responsabile delle crisi, informare tutti i programmatori e gli esperti di diagnostica che possono essere rapidamente avvertiti e avviare tutte le speciali attività di misura o tracciamento che sono state progettate per queste difficili situazioni.
I programmi di triage, la metrica e linee guida ad essi associate dovrebbero essere progettati dagli stessi gruppi a cui è stato chiesto di attivarsi quando c'è un'importante crisi: i progettisti della rete, lo staff del middleware e dei server, gli sviluppatori, il personale di sicurezza, gli architetti di sistema e qualsiasi esperto esterno che potrebbe essere coinvolto.
Strumentazione
I tool per effettuare le misure possono essere facilmente reperiti presso molti fornitori e diversi tool sono inseriti in dispositivi e sistemi che le imprese già possiedono. Per esempio, tutti i router di Cisco contengono i tool di misurazione IP-SLA e i load balancer F5 dispongono di tool estensivi per valutare le prestazioni dei server. Ci sono inoltre servizi a livello mondiale, come quelli di Gomez e Keynote, che consentono di testare i sistemi volti a fornire servizi accessibili dal Web pubblico.
All'interno dei sistemi aziendali, è importante che i tool di test siano ben conosciuti e che tutte le password siano note. Assicuratevi che le applicazioni annotino tutti gli errori che incontrano e che i messaggi di log contengano gli esatti riferimenti temporali e le informazioni per l'identificazione della transazione.
Tool come Splunk possono essere utilizzati per esplorare rapidamente i log al fine di individuare possibili indicazioni del motivo che ha originato il guasto del sistema. Un “falso contatto” che porta ad avere una comunicazione intermittente è una causa molto comune di guasti al sistema.
Dye tracing
Siccome è quasi impossibile riprodurre un moderno sistema di produzione multi-server network-based in laboratorio, e dato che solitamente è l'ambiente di produzione a causare i più complessi incidenti, i system manager devono poter disporre di programmatori esperti on site. Questi ultimi proveranno a effettuare il tracing di una transazione specifica all'interno di una serie di apparecchiature e percorsi di rete (in effetti, la rete è il backplane di un enorme sistema di elaborazione multi-server.) Presentarli con un semplice protocollo di tracciatura non è certo una soluzione efficiente.
Il dye tracing, che può seguire una transazione specifica attraverso molteplici server, spesso vale il costo di installazione e le spese generali supplementari, perché offre ai programmatori un ambiente diagnostico familiare. Possono guardare ogni chiamata di programma, i suoi tempi di esecuzione e i suoi parametri, come se l'intero processo fosse contenuto all'interno di un singolo server. Esempi di questi tool sono Introscope Transaction Tracer di CA, Transaction Analyzer di HP, PerformaSure di Quest Software, Tivoli Composite Applications Manager di IBM and Symphoniq di TrueVue.
Conclusione
Semplici metriche e procedure possono rilevare e
categorizzare (“triage”) molti incidenti relativi alle prestazioni al fine di
aiutare nel veloce ripristino di servizio, mentre gli incidenti più complessi
possono essere gestiti da tool specializzati, quali i dye tracer, e dalle
strategie di gestione pre-pianificate sotto il controllo di un responsabile di
crisi addestrato. In alcuni casi complessi, è inestimabile l'assistenza di
esperti esterni che hanno già familiarità con il corrente sistema. Questi
esperti dovrebbero contribuire a progettare le metriche di triage e di
diagnostica e poi essere facilmente reperibili nel momento in cui si verificano
problemi che richiedono il loro aiuto.
