Microsoft IT, avvalendosi dei più recenti prodotti hardware per i server e per l'archiviazione, come pure di Microsoft Exchange Server 2003 eseguito in cluster Microsoft Windows Server 2003, si pone come obiettivo da raggiungere una disponibilità del 99,99 percento per i server delle cassette postali. A questo fine, Microsoft IT implementa rigidi contratti del livello di servizio e processi regolari di verifica per garantire il rispetto rigoroso degli obiettivi o per sapere quando e perché ciò non avviene.

I dipendenti Microsoft spesso sostengono che la loro azienda vive sulla posta elettronica. La cassetta postale standard di un dipendente Microsoft ha una capacità di 200 MB. In media, ogni giorno lavorativo in Microsoft vengono elaborati 3 milioni di messaggi inviati internamente, e vengono ricevuti oltre 10 milioni di messaggi inviati dall'esterno, inclusa la posta indesiderata, ad esempio pubblicità non richiesta e virus. La posta elettronica è uno strumento essenziale per la collaborazione e la condivisione delle conoscenze in Microsoft.

Avendo compreso quanto la posta elettronica sia essenziale per la produttività e la creatività dei dipendenti Microsoft, il gruppo Microsoft Information Technology (IT) ha stabilito l'obiettivo di raggiungere una disponibilità a "quattro nove" (99,99%). Ciò comporta che tutti i server di cassette postali Exchange devono rimanere attivi e funzionanti per il 99,99 percento del tempo. Pertanto, è accettabile solo un periodo di inattività inferiore a un'ora all'anno per ciascuna cassetta postale.

Microsoft si avvale di più parametri di misurazione della disponibilità, tra i quali il principale è la disponibilità dei server delle cassette postali. Al momento della stesura di questo documento, Microsoft ha superato il 99,99 percento di disponibilità dei server delle cassette postali per un periodo di sei settimane nell'ultimo trimestre, con una disponibilità settimanale che ha raggiunto una media del 99,97 percento.

Nota: le statistiche e i dati forniti in questo documento derivano dai report del primo trimestre dell'esercizio 2005. In generale, i parametri di misurazione della disponibilità di Exchange durante lo scorso anno sono simili a quelli menzionati qui.

In questo documento viene spiegato in quale modo Microsoft misura la disponibilità di Exchange e vengono illustrati i processi implementati per migliorarne la disponibilità. Tuttavia, non bisogna considerare questo documento come un manuale operativo. Nel dettaglio, infatti, il modo in cui Microsoft fa funzionare la propria infrastruttura di messaggistica difficilmente può applicarsi direttamente ad altre aziende. I principi guida sviluppati da Microsoft IT, tuttavia, possono essere applicati a quasi tutti gli ambienti. Sono applicabili non solo a Exchange ma anche ad altre tecnologie.

Al livello più elevato, le conoscenze chiave acquisite da Microsoft IT sono:

• "Nessuna scusa". Per Microsoft IT, qualsiasi interruzione del servizio di Exchange incide negativamente sulla disponibilità di Exchange, a prescindere da chi ne è il responsabile. Che l'inattività sia pianificata o che non lo sia, che sia causata da un problema in Exchange o della rete, da un guasto dell'hardware o da una calamità naturale, tutto viene comunque considerato un mancato rispetto dei contratti del livello di servizio. Questo atteggiamento influenza profondamente il modo in cui il team risolve i problemi che incidono sulla qualità del servizio di posta elettronica.

• Misurazione e verifica delle prestazioni. Non basta impostare o calcolare i parametri di misurazione. Ognuno di essi deve essere esaminato con regolarità dai dirigenti, e occorre intraprendere la necessaria azione per mantenere le prestazioni effettive entro i livelli di tolleranza fissati. Microsoft IT tiene riunioni settimanali di verifica del servizio durante le quali tutte le parti interessate esaminano i dati della settimana, analizzano gli eventuali scostamenti e formulano gli opportuni rimedi. Per essere efficaci, le verifiche devono avere luogo ogni settimana anziché ogni mese. Vale la pena sottolineare quanto una verifica regolare sia importante per ottenere un'elevata disponibilità. Definire i contratti del livello di servizio è facile. Difficile è invece avere la costanza necessaria per analizzare con regolarità i successi e i fallimenti.

Nella prossima sezione viene descritto in quale modo Microsoft sceglie i parametri di misurazione appropriati e i contratti del livello di servizio. Successivamente vengono esaminate le quattro aree che meritano attenzione continua per mantenere un'elevata disponibilità.

In questa pagina

Come Microsoft misura la disponibilità di Exchange
Raggiungimento e conservazione della disponibilità
Conclusioni
Ulteriori informazioni

Come Microsoft misura la disponibilità di Exchange

Nel gruppo Microsoft IT si è verificato un fondamentale cambiamento di prospettiva da quando Microsoft ha basato il proprio sistema di posta elettronica su Microsoft Exchange Server 5.5. Prima di allora, il team della messaggistica riteneva che il proprio compito fosse quello di mantenere in funzione i server Exchange. Se la rete si bloccava, non era un problema di Exchange. Exchange era pur sempre disponibile, anche se la rete non lo era. Se occorreva pianificare tempi di inattività per l'installazione degli aggiornamenti del sistema operativo, anche questo non era un problema di Exchange.

L'introduzione di Microsoft Exchange 2000 Server in Microsoft è stato un importante fattore nel motivare un cambiamento di atteggiamento. Exchange 2000 è strettamente integrato con il servizio directory Active Directory®, pertanto un problema in Active Directory non può essere ignorato come se la sua risoluzione fosse di competenza altrui e non richiedesse la collaborazione del team della messaggistica. Dal punto di vista del team di Active Directory, Exchange era il maggiore utilizzatore dei servizi directory. È stato necessario strutturare correttamente Active Directory affinché riuscisse a gestire il carico posto da Exchange.

Quando Active Directory è stato implementato in Microsoft, il team di Exchange e quello di Active Directory sono stati trasferiti in sedi vicine. Si sono così potuti incontrare ogni settimana per risolvere i problemi e discutere dell'architettura. Questa riuscita collaborazione ha contribuito al cambiamento di prospettiva del team della messaggistica, che ha così iniziato a considerarsi non solo responsabile della gestione di Exchange ma anche garante dell'affidabilità di tutto ciò da cui Exchange dipende.

Il team della messaggistica considera ora le proprie responsabilità dalla prospettiva dei servizi di Exchange, non unicamente da quella dei server Exchange. Come dice Chris Nelson, il direttore del team della messaggistica che fa parte di Microsoft IT, "adesso siamo i proprietari di ciò che non ci appartiene". Questa prospettiva conduce a non trovare scuse quando viene misurata la disponibilità.

"Nessuna scusa"

Molti contratti aziendali del livello di servizio fanno una distinzione tra tempo di inattività pianificato e non pianificato, e prendono in considerazione il tempo di inattività solo se si verifica durante l'orario di lavoro. Microsoft IT prende in considerazione tutti i tempi di inattività durante i quali i client non riescono a connettersi al rispettivo database di posta elettronica né ad accedervi, a prescindere dal motivo e dal momento in cui accade e senza fare distinzione tra periodi di maggiore o di minore utilizzo. Inoltre, non importa se la causa dell'inattività sia un problema di Exchange o dell'infrastruttura da cui Exchange dipende. Se un altro servizio deve essere disattivato per l'installazione di un nuovo aggiornamento della protezione, l'interruzione viene presa in considerazione nella misurazione della disponibilità fatta dal team della messaggistica.

Di recente in un grande centro dati regionale in outsourcing si è verificata un'interruzione del servizio che è stata causata da un tifone e che è durata per un intero fine settimana. I server Exchange non erano in funzione perché il centro dati era letteralmente sommerso dall'acqua. Questo evento è stato preso in considerazione nel rilevamento della disponibilità mondiale di Exchange anche se l'interruzione del servizio non è stata causata da Exchange.

Può sembrare che considerare il team della messaggistica di Microsoft IT responsabile di questa interruzione significhi esasperare la politica "nessuna scusa". È davvero giusto ritenere il team della messaggistica responsabile di una tempesta tropicale o di un blackout elettrico?

L'importante è che questo approccio cambi il modo in cui il team reagisce ai problemi. Il team della messaggistica si sente responsabile non solo del funzionamento dei propri server ma anche del monitoraggio, del controllo e, se necessario, della modifica dell'infrastruttura su cui Exchange fa affidamento. In Microsoft IT un'interruzione del servizio di Exchange non è mai considerato un problema altrui. Il team della messaggistica è formato da professionisti seri e inflessibili nell'assicurarsi che il sistema Exchange risulti affidabile in ogni sua parte, dai server organizzati in cluster alla rete WAN che li collega ai vari client, a prescindere dalla loro ubicazione.

L'interruzione del servizio del centro dati causata da un tifone è stata conteggiata, nelle misurazioni previste dai contratti del livello di servizio, sotto forma di migliaia di minuti di tempo di attività persi. Anziché accettare l'interruzione come problema altrui, il team della messaggistica lo ha trattato come un proprio problema. Durante la calamità il team ha proposto soluzioni creative e fornito indicazioni pratiche per il rapido ripristino del servizio piuttosto che attendere passivamente che la situazione tornasse alla normalità. In seguito, il team della messaggistica si è attivato per individuare modalità di miglioramento di processi e capacità in quel centro dati. Quando era chiaro che il centro dati non poteva essere migliorato a sufficienza per impedire il verificarsi di un nuovo disastro simile, il team della messaggistica ha deciso di spostare i propri server in una struttura più solida. È previsto che questo centro dati non più affidabile esca dal ciclo produttivo prima della fine del 2004 e che le sue funzioni vengano trasferite in un centro dati ospitato in una struttura più protetta e dotata di migliori attrezzature.

Il team della messaggistica si assume la responsabilità di tutte le interruzioni, indipendentemente dalla causa, che poi individua. Queste informazioni sono preziose per la risoluzione dei problemi e per la previsione delle tendenze future. Costituiscono inoltre la prova oggettiva che occorre presentare quando si chiede a un altro team o a un fornitore di apportare delle modifiche o quando si giustificano risorse o modifiche necessarie per migliorare la disponibilità dei servizi di Exchange.

La maggior parte del tempo di inattività di Exchange in Microsoft non ha nulla a che fare con Exchange. Questa constatazione è significativa, visto che Microsoft utilizza sempre un gran numero di server con versioni di prova non definitive di Exchange Server. Nel corso degli ultimi mesi, il 7 percento del tempo di inattività di Exchange è stato dovuto agli aggiornamenti pianificati di Exchange. Il 6 percento del tempo di inattività di Exchange è stato imputato ad altri problemi specifici di Exchange. Il rimanente tempo di inattività, ossia l'87 percento, è stato causato da problemi esterni a Exchange.

Le tre principali cause a cui va ascritta la maggior parte del recente tempo di inattività di Exchange in Microsoft IT sono state:

• Problemi dell'archiviazione

• Interruzione totale del servizio dei centri dati

• Installazione di software diverso da Exchange e di aggiornamenti del firmware

Il team della messaggistica collabora stabilmente con i più importanti produttori di sistemi di archiviazione alla realizzazione di prodotti migliori e alla definizione di procedure consigliate per Exchange sulla piattaforma di ciascun produttore. I centri dati sono stati rinnovati o trasferiti in conseguenza di interruzioni del servizio. Il team della messaggistica ha inoltre collaborato fattivamente con il team di sviluppo dei prodotti Windows Server e con altri produttori per ridurre i requisiti e la frequenza di riavvio dei sistemi in conseguenza di aggiornamenti del software. Tutto questo avviene perché il team della messaggistica considera questi problemi come i propri.

Definizione di parametri di misurazione e contratti del livello di servizio appropriati

Cosa significa esattamente per Exchange essere perfettamente funzionante? Se per inviare i messaggi di posta elettronica da un server all'altro occorre un'ora, significa che il sistema sta funzionando perfettamente? Che valutazione dare se i database sono montati e disponibili ma i client non riescono a connettervisi? Come valutare una situazione in cui i client riescono a inviare messaggi di posta elettronica ma non a riceverli? La misurazione della disponibilità del servizio deve prendere in considerazione non solo la disponibilità o meno dell’accesso alle cassette postali da parte dei client, ma anche le prestazioni di tale servizio. Occorre inoltre che la misurazione avvenga a un livello di dettaglio tale che non sia troppo pesante da eseguire o troppo vasta per essere significativa.

Riguardo alla misurazione della disponibilità dei server delle cassette postali, un modo ovvio per esprimere il tempo di inattività è il ricorso ai minuti-cassetta postale: si fa la somma delle cassette postali di ciascun server o database interessato, la si moltiplica per il numero di minuti di disponibilità possibili e si sottraggono gli eventuali minuti di inattività per ciascuna cassetta postale. In alternativa, esiste un modo più semplice: esprimere il tempo di inattività in minuti-server per periodo. Microsoft IT ha adottato i minuti-database, ossia il numero di minuti in cui ciascun database risulta non disponibile. Il motivo di questa scelta risiede nel fatto che la misurazione in minuti-cassetta postale è inutilmente difficile, mentre la misurazione in minuti-server non tiene in considerazione i diversi carichi dei server o le situazioni di interruzione del servizio, ad esempio quando viene interrotto solo un database di un server ma tutti gli altri server rimangono in funzione.

L'interruzione, nel reparto Microsoft IT, per un solo minuto di un tipico server di cassette postali Exchange che ospita 20 database costa 20 minuti-database. Per conservare una disponibilità del 99,99 percento, Microsoft IT può permettersi solo 623 minuti-database di inattività a settimana in tutti i server di cassette postali in Microsoft. Se il team della messaggistica deve disattivare un server di cassette postali per più di mezz'ora, l'interruzione comprometterà il raggiungimento di una disponibilità del 99,99 percento per un'intera settimana, a dimostrazione di quanto severo sia effettivamente un obiettivo del genere. Il suo superamento frequente o anche occasionale (a condizione che non si scenda mai troppo al di sotto di esso) costituisce un risultato significativo.

Nota: in Microsoft, ogni server virtuale di cassette postali Exchange Server 2003 organizzato in cluster ospita 20 database, che rappresenta il numero massimo possibile su un server Exchange o su un server virtuale Exchange. Un tipico database Exchange in Microsoft IT è dimensionato in modo da contenere 200 cassette postali. Pertanto, in Microsoft un server Exchange completamente utilizzato ospita all'incirca 4.000 cassette postali. I server che si trovano in sedi regionali possono ospitare un numero minore di database e di utenti, ma un minuto-database di inattività può, in termini generali, essere considerato come un costo di circa 200 minuti di inattività per gli utenti finali. Tuttavia, il tempo di inattività per utente non viene misurato direttamente. Dato che alcuni database contengono meno di 200 cassette postali, la pratica adottata da Microsoft IT di misurare la disponibilità in minuti-database anziché in minuti-cassette postali potrebbe di quando in quando sovrastimare l'impatto di un'interruzione.

Un grande sistema Exchange è un insieme complesso di più servizi e funzioni. È importante definire i parametri di misurazione del tempo di attività in modo appropriato e coerente con le reali esigenze aziendali. I contratti del livello di servizio devono essere pianificati accuratamente, prestando una particolare attenzione ai costi effettivi che occorre affrontare per rispettarli. I contratti del livello di servizio pianificati in modo carente possono condurre a decisioni assurde, come dimostra l'esempio seguente.

Le aspettative inadeguate espongono a costi inopportuni

In riferimento a un'installazione di Exchange in una grande azienda, era stato stipulato un contratto del livello di servizio che prevedeva l'erogazione in meno di cinque minuti del 100 percento di tutte le funzionalità interne di posta elettronica in tutte le sedi aziendali sparse per il mondo. Questo contratto era stato rispettato facilmente nel 99,99 percento del tempo, ad eccezione di un messaggio di posta elettronica inviato una volta al mese a tutta l'azienda. Erano infatti stati necessari quasi otto minuti affinché ogni cassetta postale dell'azienda ricevesse questo messaggio eccezionale. Dal punto di vista pratico, questo prevedibile ritardo non aveva inciso negativamente sull'azienda, tuttavia il contratto del livello di servizio risultava comunque violato.

Per risolvere questo problema furono aggiornati i collegamenti di rete, che per il resto servivano adeguatamente tutte le altre richieste degli utenti, e questo con un costo considerevole. I gruppi di distribuzione e i server di espansione dei gruppi di distribuzione furono ristrutturati. Per ridurre i tempi massimi di consegna furono apportate modifiche, che però ebbero l'effetto di rallentare i tempi medi di consegna. Il denaro che si sarebbe potuto spendere per la sostituzione di sistemi disco obsoleti o per l'aggiornamento delle prestazioni dei server delle cassette postali fu impiegato tutto per far giungere prima a destinazione quell'unico messaggio di posta elettronica.

Il contratto del livello di servizio relativo alla consegna della posta elettronica interna stipulato in Microsoft è da un lato più rigido dall'altro più indulgente di quello descritto nell'esempio. Il contratto del livello di servizio stipulato in Microsoft tiene conto del fatto che gli utenti si aspettano che i messaggi di posta elettronica arrivino rapidamente ma non esige il rafforzamento della rete onde fare in modo che questa aspettativa non vada mai delusa.

In Microsoft il 99 percento di tutti i messaggi di posta elettronica scambiati tra i vari indirizzi microsoft.com deve raggiungere la propria destinazione in qualsiasi parte del mondo entro 90 secondi. Questo contratto del livello di servizio non si applica alla consegna a indirizzi esterni, in quanto sarebbe impossibile misurare accuratamente questa condizione e inappropriato da parte di Microsoft IT tentare di migliorare o controllare la situazione.

I contratti del livello di servizio incompleti ne compromettono l'efficacia

Ironicamente, nell'installazione di Exchange nella grande azienda menzionata in precedenza, non era previsto alcun contratto del livello di servizio che richiedesse la conservazione o il ripristino dei messaggi di posta elettronica inviati e ricevuti. Per questa omissione, gli errori di backup e ripristino non dettero luogo a violazioni del contratto del livello di servizio, pertanto non giunse subito all'attenzione dei dirigenti. Il reparto IT si abituò a eseguire ripristini di emergenza avviando nuovi database, senza sforzarsi di recuperare i dati precedenti. Quando un server fondamentale che ospitava le cassette postali dei dirigenti fu implicato in un ripristino di emergenza, il problema fu finalmente preso in considerazione.

Come dimostra questa vicenda, i contratti del livello di servizio malconcepiti o carenti non sono innocui. Possono distogliere le poche risorse disponibili dalle vere priorità e indurre gli esperti a concentrare la propria attenzione su questioni banali. Quando si definiscono parametri di misurazione e contratti, è essenziale coinvolgere tutti i team operativi che saranno responsabili del conseguimento degli obiettivi. La rigidità di contratti e misure imposti senza la collaborazione e il contributo di tutti coloro che ne sono interessati può provocare conseguenze impreviste e problemi importanti che vengono trascurati o nascosti.

L'esistenza di linee guida produce contratti del livello di servizio significativi

Microsoft IT ha considerato i seguenti punti nello stilare i propri contratti del livello di servizio e nel fissare i parametri di misurazione del tempo di attività, e li propone all'attenzione di altri clienti:

• Reali esigenze aziendali. I costi occorrenti per ottenere una maggiore disponibilità potrebbero non valere i benefici. Occorre analizzare la disponibilità di cui l'azienda ha bisogno prima di fissare gli obiettivi.

• Livello di dettaglio appropriato. Le misurazioni della disponibilità di un sistema Exchange sono molte e non si riducono a una sola misurazione positiva o negativa. Le diverse parti del sistema hanno requisiti differenti. Ad esempio, un server di cartelle pubbliche i cui dati sono replicati su un altro server non necessita della stessa disponibilità del server che ospita la cassetta postale dell'amministratore delegato.

• Responsabilità. Occorre che vi sia una persona o un team responsabile di ciascuna misurazione. Inoltre, è indispensabile garantire che chi ha tale compito disponga delle necessarie autorizzazioni per fare quanto occorre per controllare i sistemi dai quali dipende la misurazione.

• Rischi ordinari e straordinari. I guasti dei dischi e dei server come pure le interruzioni della rete e della corrente sono rischi prevedibili e ordinari. Si sa che prima o poi diverranno realtà, pertanto devono essere pianificati come eventi previsti. Buona parte del tempo di inattività può essere evitata prevedendo i rischi ordinari. Se ad esempio non si acquistano parti hardware di ricambio prima che occorrano, si prolunga di ore o giorni un'interruzione che potrebbe durare solo alcuni minuti.

  Il tipo di pianificazione che occorre eseguire per gli eventi straordinari è di natura molto diversa, e deve prendere in considerazione la perdita di personale e attrezzature. Il centro di questa pianificazione è l'identificazione dei dati essenziali e lo sviluppo di contratti del livello di servizio per conservare altrove i dati essenziali.

• Ambiti e tolleranze. Requisiti rigidi e assoluti per le misurazioni possono fare più male che bene. Nei contratti del livello di servizio è necessario prendere in considerazione le prestazioni medie o previste e fissare i limiti di tolleranza per fluttuazioni ragionevoli.

• Misurabilità. Al centro di ogni contratto del livello di servizio dovrebbe esservi un parametro di misurazione oggettivo. Se quest'ultimo è costoso, difficile o non accurato, deve essere cambiato. Spesso esistono più modi per misurare una funzione, e un parametro di misurazione più semplice può sostituirne uno più difficile.

  Ad esempio, per misurare la disponibilità delle cassette postali, Microsoft non si basa sui minuti effettivi in cui ciascuna cassetta postale risulta inutilizzabile, bensì sui minuti-database. Per basare le misurazioni sui minuti-cassetta postale occorrerebbe contare le cassette postali di ciascun database per eseguire calcoli specifici ogni volta che un database non funziona. Misurare in minuti-database, nonché considerare ciascun database come formato da un numero medio di cassette postali, semplifica la misurazione e consente di ottenere lo stesso risultato complessivo.

  Un altro aspetto della misurabilità è il margine di errore inerente una misurazione. Microsoft ha dozzine di controller di dominio e di server Exchange in tutto il mondo. Con l'espressione asimmetria di orario si fa riferimento al fatto che non tutti i computer sono sempre sincronizzati al secondo esatto. Infatti alcuni computer possono presentare una differenza di orario di un minuto o anche maggiore, fino a 5 minuti. Pertanto, la misurazione dei tempi di consegna dei messaggi di posta elettronica all'interno della rete di Microsoft non è precisa. Talvolta le misurazioni dei tempi di consegna mostrano la ricezione di un messaggio ping come se fosse avvenuta prima del suo effettivo invio, e questo a causa dell'asimmetria di orario. Talaltra sembra che per arrivare a destinazione un messaggio abbia impiegato più tempo di quanto avrebbe dovuto, mentre la sua consegna è in realtà avvenuta entro i limiti di tolleranza. I contratti del livello di servizio stipulati in Microsoft per la posta elettronica non sono tanto rigidi da permettere ad errori casuali dovuti all’asimmetria di orario di fare la differenza tra una settimana positiva e una negativa.

  Nota: il team di prodotto Exchange renderà presto disponibile un aggiornamento di Microsoft Operations Manager (MOM) 2005 che consentirà di evitare il problema dell'asimmetria di orario nella misurazione dei tempi di consegna della posta elettronica. Microsoft IT inizierà il testing di questo aggiornamento nel dicembre del 2004.

• Essere realistici. Prima di fissare un obiettivo di miglioramento, occorre effettuare un benchmark delle attuali prestazioni basandosi su un parametro di misurazione. Non è opportuno stabilire obiettivi troppo distanti dalla situazione del momento. Se gli obiettivi fissati dal contratto del livello di servizio vengono disattesi di settimana in settimana, tali obiettivi non verranno più presi sul serio.

Microsoft IT ha stabilito che siano tre i parametri di misurazione specifici più importanti da utilizzare per tenere traccia della qualità complessiva del servizio di posta elettronica. I dirigenti Microsoft esaminano settimanalmente questi parametri, mentre il team della messaggistica analizza un insieme più dettagliato di parametri di misurazione:

• Disponibilità delle cassette postali. Se viene montato un database Exchange in grado di rispondere alle connessioni client, le corrispondenti cassette postali vengono considerate come disponibili, anche se la rete non funziona o nessun client riesce a connettersi al database. Questa misurazione viene eseguita in minuti-database, come descritto in precedenza, e l'obiettivo è una disponibilità del 99,99 percento.

  Nota: nella pratica, la misurazione della disponibilità dei server delle cassette postali di Microsoft richiede molto di più che la semplice disponibilità di server e database per i client. Inoltre, anche la parte della rete controllata dal centro dati deve funzionare.

• Tempi di consegna dei messaggi di posta elettronica. Il 99 percento del totale dei messaggi di posta elettronica interni inviati nell'ambito della rete aziendale di Microsoft deve essere recapitato entro 90 secondi in qualsiasi parte del mondo.

• Disponibilità per i client di posta elettronica. Tutti i client Outlook devono potersi collegare ai rispettivi server delle cassette postali nel 99 percento del tempo. Questa condizione viene misurata separatamente dalla disponibilità delle cassette postali, così da mantenere un adeguato livello di dettaglio nella misurazione. Il personale in grado di risolvere i problemi dei server è diverso da quello che si occupa dei problemi della rete o dei client. Separando questi criteri di misurazione, il team della messaggistica risponde automaticamente a domande importanti su dove concentrarsi per incrementare il tempo di attività e fornisce dati che ogni team può utilizzare per stimare i propri progressi.

  Nota: la disponibilità settimanale per i client assicurata da Microsoft IT ha raggiunto una media di oltre il 99,97 percento nell'ultimo trimestre, e spesso ha toccato il 99,99 percento.

Gli altri parametri di misurazione adottati da Microsoft IT sono descritti nella sezione "Verifica dei progressi" più avanti in questo documento.

Raggiungimento e conservazione della disponibilità

Per Microsoft IT il raggiungimento e la conservazione di un'elevata disponibilità hanno richiesto una particolare attenzione a quattro aspetti:

• Hardware e software

• Architettura e topologia

• Esercizio

• Verifica dei progressi

In questa sezione vengono evidenziati i fattori più importanti di ciascun aspetto che hanno contribuito al miglioramento della disponibilità di Exchange in Microsoft.

Hardware e software

Exchange Server 2003 è un prodotto molto diverso rispetto a Exchange 4.0, la prima versione commerciale di Exchange. Nell'ambito aziendale, un tipico server Exchange ospita ora migliaia, e non centinaia, di cassette postali. Il volume di messaggi di posta elettronica inviati e ricevuti dall'utente medio è oggi svariate volte maggiore di quello di alcuni anni fa. Inoltre Internet è diventato un ambiente molto più ostile da quando si viene inondati di posta indesiderata e di altro software non autorizzato (malware) che viene inviato tramite i server di messaggistica. Server, reti e periferiche di archiviazione sono caratterizzati ora da una capacità e da una velocità di molte volte superiore rispetto a quelle diffuse quando Exchange fu introdotto per la prima volta.

Le funzionalità, la scalabilità e l'affidabilità di Exchange Server 2003 come piattaforma software sono state notevolmente aumentate così da poter sfruttare le nuove caratteristiche dei componenti hardware e della piattaforma Microsoft Windows® nonché fare fronte alle nuove minacce:

• Exchange Server 2003 supporta 20 database su ciascun server o server virtuale organizzato in cluster. In Microsoft i server delle cassette postali includono in genere 20 database a servizio di circa 4.000 cassette postali. Ripartendo i dati delle cassette postali tra 20 database, ciascuno di essi può essere dimensionato in modo che possa essere ripristinato completamente in un'ora, e se necessario tutti i database possono essere ripristinati simultaneamente.

  Nota: quando Exchange 2000 Server è stato pubblicato, veniva consigliato, per ottenere prestazioni ottimali dei server, di configurare ogni server con un numero di gruppi di archiviazione e database il più ridotto possibile. In conseguenza dei miglioramenti apportati in Exchange 2000 Service Pack 3 e in Exchange Server 2003, le prestazioni non vengono più penalizzate qualora si aggiungano altri database. Ora è possibile ripartire le cassette postali tra più database per ottenere una migliore tolleranza di errore e una maggiore gestibilità, senza dover incorrere in un ulteriore overhead del server.

• Il modulo di gestione di database Exchange è stato molto migliorato per ciò che riguarda le prestazioni, la recuperabilità e la scalabilità. Con Exchange Server 2003 Service Pack 1, i danneggiamenti fisici a bit singolo delle pagine di database vengono automaticamente risolti, cosicché Exchange è in grado di correggere automaticamente i danni casuali del database causati da problemi dell'hardware o dei dischi, senza che occorra ripristinare il database. Le attività in linea di manutenzione e deframmentazione sono state ottimizzate in modo che non sia più necessario eseguire una manutenzione e una deframmentazione di routine non in linea. Il risultato di questi miglioramenti, e di molti altri, è che la necessità di tempi di inattività pianificati è molto minore in Exchange Server 2003 rispetto alle precedenti versioni di Exchange.

• Negli ultimi anni la tecnologia di backup e archiviazione non solo si è evoluta, si è rivoluzionata. Le tecnologie di archiviazione SAN (Storage Area Network) e iSCSI (Internet Small Computer System Interface) non sono più astruse ed economicamente proibitive. L'archiviazione non è più legata direttamente a un solo server, ma è condivisa e portabile. Le tecnologie di backup mediante duplicazione e snapshot hanno reso possibili il trasferimento e il ripristino efficace di enormi quantità di dati pressoché istantaneamente. Ora, dopo un'emergenza, è possibile ripristinare i dati di Exchange molto più rapidamente di quanto fosse possibile prima di queste innovazioni.

• Il supporto del clustering di Windows Server 2003 è maturo e funziona bene con Exchange. A parte poche eccezioni regionali marginali, tutte le cassette postali in Microsoft si trovano ora su cluster Windows Server 2003 a sette nodi. Il clustering contribuisce significativamente alla riduzione del tempo di inattività pianificato, perché un server virtuale Exchange non è legato a un singolo host Windows, ma può essere spostato da un nodo cluster a un altro quando occorrono gli aggiornamenti del software o la manutenzione dell'hardware. Ciò non elimina del tutto il tempo di inattività pianificato poiché potrebbero occorrere alcuni minuti per trasferire i servizi di Exchange da un nodo cluster all'altro. Tuttavia, non occorre che i servizi di Exchange vengano disattivati per l'intera durata delle installazioni, dei riavvii e delle sostituzioni hardware pianificate.

  Prima di ospitare Exchange sui server Windows Server 2003, in Microsoft il rapporto tra tempo di inattività pianificato e non pianificato era di 7:1. Ora è di 1:1, senza che il tempo di inattività non pianificato sia complessivamente aumentato.

  Molti credono che il clustering sia una soluzione che assicura un'elevata disponibilità e che protegge dal tempo di inattività non pianificato. Ciò, in un certo senso, è vero. Però, l'odierno hardware di fascia alta è in genere più affidabile di quello disponibile alcuni anni fa. Nei server e nelle strutture contenitrici di archiviazione di livello aziendale sono presenti un elevato livello di ridondanza, funzionalità di segnalazione preventiva dei guasti e di collegamento a caldo ancor prima dell'installazione delle funzionalità di clustering per software o applicazioni.

  Forse il vantaggio maggiore derivante dall'uso del clustering di Windows Server 2003 sull'hardware di livello aziendale attualmente disponibile non è costituito tanto dalle funzionalità di failover quanto piuttosto dalla flessibilità gestionale e dall'effetto che ha sul tempo di inattività pianificato. Individuare dei modi per ridurre il tempo di inattività pianificato può contribuire all'incremento della disponibilità molto più della capacità di far fronte al tempo di inattività non pianificato. A prescindere dal fatto che il clustering Windows sia stato implementato o meno nell'ambiente Exchange in uso, ogni volta che un server o un servizio deve essere arrestato, occorre registrare e analizzare l'evento per scoprire se lo si sarebbe potuto evitare o se sarebbe stato possibile ridurne l'impatto.

  Per ulteriori informazioni sulla modalità di configurazione e gestione dei cluster di cassette postali Exchange in Microsoft, vedere il white paper IT Showcase Exchange 2003 Design and Architecture at Microsoft all'indirizzo http://www.microsoft.com/services/microsoftservices/exchange.mspx#69 (informazioni in lingua inglese).

  Nota: l'implementazione delle tecnologie di clustering Windows Server richiede una maggiore competenza da parte del personale addetto al supporto per Exchange. Non solo deve conoscere Exchange, ma deve anche essere esperto di clustering e dei diversi comportamenti e requisiti di Exchange quando viene utilizzato in un ambiente di clustering. In generale, si dovrebbe riuscire a raggiungere una disponibilità complessiva del 99,5 percento senza ricorrere all'organizzazione in cluster dei server Exchange. Se non si è ancora raggiunto questo livello, è probabile che si ottengano riscontri più immediati da miglioramenti operativi e da altri aggiornamenti piuttosto che dal clustering di Exchange. Il clustering di per se stesso e in se stesso non può ovviare alle deficienze operative né a un'infrastruttura o a componenti hardware inadeguati o inaffidabili. Dopo aver raggiunto una disponibilità del 99,5 percento (che equivale a circa due giorni di inattività per server all'anno), l'introduzione del clustering può avere un impatto positivo notevole sugli ulteriori miglioramenti, specialmente per ciò che concerne la riduzione del tempo di inattività pianificato.

Architettura e topologia

L'installazione di un solo server Exchange è semplice, specialmente se ci si avvale delle istruzioni dettagliate incluse nei nuovi Strumenti di distribuzione di Exchange Server 2003. Tuttavia, la distribuzione di un sistema Exchange supportabile in un ambiente aziendale o mondiale richiede una notevole esperienza. L'interazione di Exchange con Active Directory deve essere progettata in maniera attenta e precisa. L'uso di guide e white paper Microsoft completi dedicati alla distribuzione possono risultare utili agli architetti di sistema che intendono progettare e realizzare un sistema Exchange efficiente. Per ulteriori informazioni sulla distribuzione di Exchange, vedere la sezione "Deployment" all'indirizzo http://www.microsoft.com/exchange/techinfo/deployment/2003.asp (informazioni in lingua inglese).

Oltre ai suggerimenti e alle informazioni rinvenibili in tali documenti, Microsoft IT propone all'attenzione i seguenti utili principi di progettazione:

• Utilizzare server front-end sparsi per la tolleranza di errore. All'interno dei confini geografici regionali, i server front-end devono essere ripartiti fra più centri dati.

• Creare siti Active Directory dedicati per Exchange. Ciò rende più deterministico e stabile il carico sui server di directory utilizzati da Exchange.

• Consolidare e centralizzare quanto più possibile i servizi in grandi centri dati. La centralizzazione migliora la gestibilità, e i grandi centri dati tendono ad avere una qualità e un'affidabilità maggiori.

Per aiutare gli amministratori e gli addetti alla risoluzione dei problemi ad analizzare e capire le distribuzioni esistenti, Microsoft ha di recente messo a disposizione un nuovo strumento chiamato ExBPA (Microsoft Exchange Server Best Practices Analyzer Tool). ExBPA analizza oltre 1.200 elementi di configurazione di un'organizzazione Exchange esistente e utilizza più di 800 regole incorporate per individuare i problemi di progettazione della configurazione e dell'architettura che le rendono non ottimali. Per ulteriori informazioni su ExBPA, vedere Microsoft Exchange Server Best Practices Analyzer Tool all'indirizzo http://www.microsoft.com/exchange/exbpa (informazioni in lingua inglese).

Esercizio

Il mancato monitoraggio dei sistemi è forse l'errore più comune osservato dagli esperti Microsoft della messaggistica in occasione di consulenze presso clienti esterni. Questa omissione comporta due problemi comuni:

• Problemi che si sarebbero potuti gestire con facilità, se notati con più anticipo, crescono invece in modo incontrollato.

• I tempi di risposta quando vi è un guasto sono misurati in ore invece che in minuti.

L'efficienza e la coerenza operative sono essenziali per conseguire un'elevata disponibilità. Se le rimostranze degli utenti finali costituiscono l’abituale veicolo di notifica dei problemi di posta elettronica al personale di supporto per la messagistica, significa che il monitoraggio del sistema non viene eseguito adeguatamente Per mantenere un sistema estremamente disponibile, il team di amministrazione di Exchange dovrebbe essere il primo a notare i problemi e dovrebbe verificare giornalmente il corretto funzionamento del sistema.

Microsoft Operations Manager 2005

Microsoft IT collabora strettamente con il team di sviluppo di MOM 2005. MOM include le conoscenze acquisite da Microsoft IT circa il monitoraggio delle prestazioni di applicazioni e server. In Microsoft, MOM ha sostituito numerosi strumenti estemporanei. I commenti e i suggerimenti di Microsoft IT continuano a essere fondamentali per le nuove funzionalità e caratteristiche di MOM. I gruppi di sviluppo di applicazioni in Microsoft forniscono i pacchetti di gestione per MOM che sono ottimizzati per ciascuna applicazione.

Il pacchetto di gestione di Exchange per MOM è stato sviluppato congiuntamente dai team di prodotto di MOM e di Exchange, con l'ampia collaborazione del team della messaggistica di Microsoft IT. Include numerosi avvisi predefiniti dedicati al monitoraggio dei server Exchange e informazioni dettagliate relative a ciascun avviso per la risoluzione dei problemi. MOM 2005 e il relativo pacchetto di gestione per Exchange sono vivamente consigliati da Microsoft IT e dal gruppo di prodotto Exchange per l'automatizzazione della raccolta e dell'analisi di dati gestionali essenziali dei server Exchange.

Disponibilità operativa 24x7x365

Il personale di Microsoft IT tiene sotto controllo i server Exchange dell'azienda 24 ore al giorno, sette giorni la settimana, 365 giorni l'anno (24x7x365). Molte organizzazioni non possono giustificare questi costi, pertanto fanno in modo che il personale del supporto per la messaggistica possa essere raggiungibile mediante cercapersone. Questo approccio fa un grande differenza per la velocità con cui il personale del supporto è in grado di rispondere dopo il rilevamento di un problema, e può fare la differenza tra ottenere il 99,9 percento e ottenere il 99,99 percento di disponibilità. A prescindere dall'obiettivo desiderato in termini di disponibilità, è essenziale che vi sia sempre qualcuno pronto a rispondere a ciascun avviso, di notte o di giorno.

Pianificazione del ripristino di emergenza

Oltre alla disponibilità di qualcuno in caso di problemi, occorre che tale persona sia ben preparata ed esperta del sistema. Il personale del supporto non solo deve essere competente nello svolgimento delle attività quotidiane di amministrazione e monitoraggio, ma deve anche sapere come ricreare il sistema in seguito a un'emergenza.

Microsoft IT ha guide dettagliate per l'esecuzione delle normali attività quotidiane di manutenzione, monitoraggio e amministrazione. Tuttavia, non esiste alcuna guida dettagliata per il ripristino d'emergenza. Il motivo è che probabilmente un'emergenza può distruggere completamente parti essenziali del sistema, dai server a interi siti geografici o a tutte le informazioni incluse in Active Directory. Per rispondere a una situazione di emergenza straordinaria, il personale deve essere addestrato, sapere come ricreare ogni sistema essenziale e conoscerne l'architettura per ovviare ai siti e ai servizi inattivi. La conduzione periodica di simulazioni o esercitazioni antincendio laddove parti del sistema e personale essenziale diventano indisponibili è un buon mezzo per individuare i punti deboli nella gestione di emergenze straordinarie.

Con le giuste competenze e una documentazione esaustiva sulla configurazione del sistema un team di supporto per Exchange può ricreare efficacemente un'intera organizzazione di Exchange. Un modo per verificare se un team ha queste capacità è che provi a recuperare un'intera organizzazione di Exchange in un ambiente di laboratorio, utilizzando niente altro che backup di database e la documentazione sull'architettura del sistema.

Per effettuare un ripristino di emergenza, il personale deve sapere come eseguire quanto segue:

• Reinstallare o ricreare un intero server Exchange (o un server virtuale, se sono utilizzati i cluster di Exchange).

• Importare o esportare oggetti utente e attributi di configurazione di cassette postali Exchange.

• Spostare cassette postali o database in server diversi.

• Connettere e disconnettere le cassette postali da diversi oggetti utente di Active Directory.

• Utilizzare i gruppi di archiviazione di ripristino e la strategia di ripristino "segnale di linea".

• Configurare i server virtuali di protocollo Exchange.

Per white paper e pubblicazioni tecniche su Exchange relativi a questi argomenti, vedere Administering Exchange Server 2003 all'indirizzo http://www.microsoft.com/exchange/techinfo/administration/2003.asp (informazioni in lingua inglese).

Inoltre, nei seguenti articoli della Microsoft Knowledge Base sono incluse importanti informazioni e dettagli sulle modalità di interazione delle cassette postali di Exchange con gli account utente di Active Directory:

• "How to Move Exchange 2003 to New Hardware and Keep the Same Server Name" http://support.microsoft.com/kb/822945 (informazioni in lingua inglese).

• "Requirements for Disabling the Recipient Update Service" http://support.microsoft.com/kb/296479 (informazioni in lingua inglese).

• "Removing Duplicate and Unwanted Proxy Addresses in Exchange" http://support.microsoft.com/kb/318774 (informazioni in lingua inglese).

• "How to Modify a User's E-mail Addresses by Using Ldifde" http://support.microsoft.com/kb/313823 (informazioni in lingua inglese).

• "Workarounds for Problems with Mbconn.exe"
  http://support.microsoft.com/kb/301585 (informazioni in lingua inglese).

Verifica dei progressi

Il compito più arduo è forse creare un processo continuo di verifica e attenervisi. Si tratta di un compito essenziale.

Le verifiche eseguite da Microsoft IT hanno luogo con cadenza settimanale, così da permettere di affrontare i problemi quando sono ancora ben impressi nella mente di tutti ed è possibile raccogliere dati per la risoluzione dei problemi e l'individuazione delle cause.

Le verifiche settimanali svolte dal team della messaggistica non consistono solo nel controllare se le prestazioni del sistema rientrano entro i limiti fissati dai contratti del livello di servizio, ma considerano anche se vengono misurati i giusti elementi e se determinati parametri di misurazione contribuiscono o meno al miglioramento del sistema. Riguardano inoltre importanti statistiche e tendenze e prevedono il confronto dei dati attuali con le misurazioni precedenti. Le verifiche concernono non solo la disponibilità ma anche altri importanti criteri di valutazione, ad esempio il volume di traffico, il numero di utenti, la percentuale di utenti per i vari servizi e così via.

Sebbene il team del supporto per il sistema Exchange non abbia la responsabilità di rispondere a chiamate per assistenza tecnica, vengono esaminati anche questi dati statistici, e il team si assume la responsabilità di condurre alla riduzione del numero di problemi riferiti all'assistenza tecnica e alla più rapida conclusione delle chiamate.

Tra i parametri di misurazione esaminati settimanalmente in Microsoft vi sono:

• Disponibilità dei server Exchange. Viene misurata la percentuale di tempo durante il quale i database sono montati, funzionanti e pronti al collegamento per i client.

• Percentuale di posta elettronica consegnata nel rispetto del contratto del livello di servizio. Viene misurato se viene consegnato più del 99 percento dei messaggi di posta elettronica tra mittenti e riceventi interni entro 90 secondi.

• Accesso alle cassette postali in modalità "segnale di linea". Consente di verificare se il ripristino del servizio di posta elettronica dopo un'interruzione è stato completato in meno di un'ora. Il ripristino di tutti i dati precedenti delle cassette postali deve essere realizzato entro due giorni.

  Microsoft IT dimensiona i database e ottimizza i sistemi di backup per consentire tempi di ripristino di un'ora per qualsiasi database di cassette postali. A seconda della natura e della durata di un'interruzione, il team della messaggistica può scegliere di ripristinare i dati di tutti gli utenti simultaneamente al servizio oppure di ripristinare prima il servizio e poi i dati. Per informazioni dettagliate sulla configurazione di un server Exchange onde consentire un facile ripristino del tipo "segnale di linea", vedere Using Exchange 2003 Recovery Storage Groups all'indirizzo http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ue2k3rsg.mspx (informazioni in lingua inglese).

• Disponibilità per i client di posta elettronica. Viene controllato se i client Microsoft Outlook® riescono a connettersi a ciascun server Exchange. Questo criterio vale sia per le connessioni RPC (Chiamata di procedura remota, Remote Procedure Call) standard sia per le connessioni RPC su HTTP (Hypertext Transfer Protocol). Outlook Web Access e le connessioni mediante altri protocolli client vengono misurati sulla base di contratti distinti del livello di servizio.

• Prestazioni per i client di posta elettronica. Questa misurazione consente di tenere traccia della capacità di risposta di ciascuna richiesta server-client. Per Microsoft IT questo criterio di valutazione corrisponde alla percentuale di operazioni client che vengono completate in meno di due secondi. Questo criterio risulta inoltre utile per prendere decisioni circa il bilanciamento del carico e il dimensionamento dei server.

• Richieste di assistenza per la posta elettronica evase entro i limiti fissati dal contratto del livello di servizio. Viene misurata la velocità di soluzione delle richieste di assistenza. Microsoft IT tiene traccia anche del numero di richieste di assistenza generate e delle relative priorità di risoluzione, cercando di far diminuire soprattutto le richieste urgenti.

• Soddisfazione per l'uso del client di messaggistica (percentuale di insoddisfazione). Si basa su questionari proposti successivamente alle richieste di assistenza.

• Utilizzo della posta elettronica. Questi dati statistici includono il numero di messaggi di posta elettronica inviati e ricevuti da Internet nonché il numero di messaggi inviati internamente.

• Utenti della posta elettronica. Tra questi dati statistici rientrano il numero totale di cassette postali del sistema, il numero di cassette postali degli utenti rispetto al numero di cassette postali del sistema nonché il numero di utenti del più grande server Exchange del sistema.

• Infrastruttura per la posta elettronica. Nell'ambito di questi dati statistici rientrano il numero totale di server di messaggistica utilizzati in Microsoft e la percentuale di backup riusciti.

• Inoffensività dei messaggi. Mediante questi dati statistici si tiene traccia del volume di messaggi indesiderati individuati, della quantità di virus rimossi dai messaggi e di statistiche similari correlate alla protezione e agli attacchi da Internet. Microsoft IT tiene traccia anche del numero di reclami all'assistenza correlati al filtraggio della posta indesiderata, per misurare la riuscita del blocco della posta elettronica indesiderata.

• Messaggistica mobile. Vi sono incluse le misurazioni concernenti la disponibilità del server front-end Exchange, le statistiche sul numero di utenti di Outlook Web Access, di Exchange Active Sync e di Microsoft Outlook Mobile Access. Anche l'utilizzo di questi servizi viene espresso in termini di percentuale di utenti. Ciò consente di tenere facilmente traccia dei tassi di adozione e di utilizzo.

• Messaggistica unificata e fax. Anche questi servizi vengono forniti tramite l'infrastruttura di Microsoft Exchange. Le varie misurazioni concernenti l'utilizzo, la disponibilità e le prestazioni di questi servizi vengono analizzate settimanalmente.

• Riuscita dei backup. I backup devono essere completati correttamente ogni notte per il 99 percento di tutti i server. La misurazione del tasso di riuscita dei backup non solo conduce a migliorare l'affidabilità del sistema di backup ma assicura anche che gli errori di backup vengano immediatamente individuati e risolti.  

I parametri di misurazione indicati precedentemente non dovrebbero essere utilizzati come linee guida per stabilire il modo in cui le altre organizzazioni devono misurare le prestazioni dei propri sistemi Exchange. Ciò che Microsoft IT misura cambia nel corso del tempo e continuerà a cambiare con il variare delle circostanze e dei problemi riscontrati.

In occasione di ogni verifica settimanale ogni misurazione è di competenza di una particolare persona che ha la responsabilità di riferire su di essa indicando nel dettaglio gli eventuali eventi che hanno provocato gli scostamenti. Tutte le misurazioni sono messe a disposizione dell'intero team su una tabella settimanale che indica le misurazioni correnti, quelle precedenti e le tendenze. Le misurazioni vengono consolidate in report trimestrali e annuali che vengono esaminati insieme con il CIO (Chief Information Officer) di Microsoft. Pertanto, l'intero team ha la possibilità di farsi regolarmente un quadro completo della situazione e di contribuire a trovare soluzioni e apportare miglioramenti. Dal momento che il team esamina i problemi settimana dopo settimana, gli effetti diretti della creatività e delle soluzioni ideate si possono individuare confrontando le misurazioni delle prestazioni del momento con quelle precedenti.

Conclusioni

Per ottenere e conservare un'elevata disponibilità, occorrono diversi miglioramenti incrementali dei processi e della tecnologia, abbinati a un regolare controllo e monitoraggio in tempo reale dello stato del sistema.

Non esistono regole fisse a cui attenersi per conseguire una disponibilità elevata in modo permanente. La conservazione di un'elevata disponibilità è un impegno attivo e continuo che richiede prontezza di risposta e di adattamento a nuove situazioni e tecnologie. Al livello minimo, occorre prestare attenzione a ciò che avviene nel sistema 24 ore al giorno, 7 giorni alla settimana, 365 giorni all'anno se si desidera che il sistema sia sempre disponibile.

Quando inizialmente ci si concentra sul miglioramento della disponibilità, è probabile che si scopra che è possibile conseguire miglioramenti significativi implementando semplici modifiche del comportamento e delle procedure. Ciò può essere sia un bene sia un male. Può essere frustrante scoprire che si sono trascurate le prestazioni di fondamentali attività operative o che ci si è comportati in maniera incoerente nell'eseguirle.

Ad esempio, uno dei più comuni problemi che il personale dell'assistenza tecnica e i consulenti Microsoft osservano nelle sedi dei clienti dopo un'emergenza è l'incapacità di eseguire backup di dati essenziali o di verificarne la corretta esecuzione. Per quanto ciò possa sembrare elementare, è sorprendente notare quanto questa incapacità sia diffusa. Correggere pazientemente questi problemi e assicurarsi che ogni settimana sia leggermente migliore di quella precedente è la chiave del successo.

Una volta installate le giuste tecnologie e implementate le corrette procedure, la conservazione di un'elevata disponibilità richiede costanza e impegno nell'eseguire verifiche regolari a cadenza settimanale. Dal momento che queste verifiche mettono in evidenza dove si verificano i problemi e cosa è che non funziona bene, vi è la naturale tendenza a evitarle. Inoltre, può avvenire facilmente che queste verifiche degenerino in esercizi sterili o che, ancora peggio, diventino poco più che incontri per cercare scuse o accusare altri. Per ottenere un'elevata disponibilità, è necessario che siano in atto procedure di controllo e che le persone interessate concordino sull'utilità delle verifiche.

Assumendo un atteggiamento che escluda lo scarico di responsabilità e che preveda il regolare monitoraggio dei propri progressi, è possibile migliorare il livello di disponibilità nell'organizzazione, a prescindere dalle risorse finanziarie o tecnologiche attualmente disponibili. Raggiunto un certo punto, però, l'ulteriore miglioramento della disponibilità richiede nuovi investimenti in tecnologie e infrastrutture.

È importante comprendere chiaramente quali problemi possono essere risolti adottando nuove tecnologie e quali invece devono essere risolti applicando nuove procedure. L'incidenza delle nuove tecnologie e delle nuove funzionalità viene enormemente accresciuta se si lavora già in un ambiente operativamente eccellente.

Il raggiungimento di un'elevata disponibilità è possibile sfruttando la sinergia tra tecnologie, infrastruttura, esercizio e verifiche regolari.

Ulteriori informazioni

Per informazioni su prodotti e servizi Microsoft, rivolgersi alla filiale Microsoft locale o visitare i seguenti siti Web (le informazioni in alcuni siti possono essere in lingua inglese):

http://www.microsoft.com

http://www.microsoft.com/itshowcase

http://www.microsoft.com/technet/itshowcase

Per domande, commenti o suggerimenti sul presente documento o per ulteriori informazioni su Microsoft IT Showcase, inviare un messaggio di posta elettronica all'indirizzo:

showcase@microsoft.com

Problema

Microsoft IT desiderava migliorare la disponibilità per i client delle cassette postali di Exchange Server portandola dal 99,9 al 99,99 percento.

Soluzione

Microsoft IT ha implementato Exchange Server 2003 su server Windows Server 2003 riuniti in cluster e collegati a strutture contenitrici SAN (Storage Area Network). Per conservare i miglioramenti ottenuti mediante le modifiche dell'infrastruttura, sono stati posti in essere rigidi contratti del livello di servizio che prevedono verifiche settimanali.

Vantaggi

• L'affidabilità del servizio di posta elettronica per i dipendenti corrisponde o supera il 99,99 percento.

• La capacità di risposta ai problemi è assicurata da verifiche settimanali delle prestazioni a fronte di quanto previsto dai contratti del livello di servizio.

• L'atteggiamento rigido adottato in merito al rispetto dei contratti del livello di servizio spinge a essere creativi e determinati nell'affrontare i problemi.

Prodotti e tecnologie

• Microsoft Windows Server 2003

• SAN

• Server organizzati in cluster

• Microsoft Exchange Server 2003

• Microsoft Office Outlook 2003