Funzionalità IO: processo di gestione basato su ITIL/COBIT - dal livello Standard al livello Razionale

In questa pagina

Introduzione
Requisito: processi di gestione, ottimizzazione e modifica

Introduzione

Al fine di ottenere massimi vantaggi e prestazioni, i processi relativi alle procedure consigliate devono essere definiti per tutte le attività evidenziate nel modello di ottimizzazione dell'infrastruttura. Nella seguente tabella vengono elencate le sfide più impegnative, le soluzioni applicabili e i vantaggi del passaggio al livello Razionale nel processo di gestione basato su ITIL/COBIT.

Sfide	Soluzioni	Vantaggi
Sfide aziendali Gli SLA sono informali o impliciti La gestione della configurazione informale consiste nella generazione basilare di fogli di calcolo ed elenchi di controllo Sfide IT Gestione dei rilasci informale	Progetti Implementare la gestione dei livelli di servizio nelle operazioni IT Implementare le procedure consigliate per la gestione dei rilasci Ottimizzare i processi di amministrazione del sistema e della rete Implementare le procedure consigliate per la pianificazione dei processi	Vantaggi per l'azienda Le operazioni IT proattive consentono di risolvere preventivamente i problemi per evitare che la produttività degli utenti diminuisca Vantaggi IT Servizi e strumenti automatici forniscono risorse per implementare nuovi servizi oppure ottimizzare i servizi esistenti Gli SLA formali collegano l'IT all'azienda migliorando la credibilità dell'IT

Il livello Razionale di ottimizzazione richiede che l'organizzazione disponga di procedure definite per la gestione degli imprevisti, la gestione dei problemi, il supporto utente, la gestione della configurazione e delle modifiche.

Requisito: processi di gestione, ottimizzazione e modifica

Target

È necessario leggere questa sezione se non si dispone di processi per la gestione dei livelli di servizio, la gestione dei rilasci, l'amministrazione dei sistemi e della rete e la pianificazione dei processi.

Panoramica

L'ottimizzazione dell'infrastruttura va oltre i prodotti e le tecnologie. Il personale e i processi formano gran parte del livello di maturità del servizio IT di un'organizzazione. Alcune organizzazioni si occupano degli standard e delle procedure consigliate mirate alla gestione del personale e dei processi coinvolti nel servizio IT. Microsoft Operations Framework (MOF) applica gran parte delle informazioni contenute negli standard IT Infrastructure Library (ITIL) e Control Objectives for Information and related Technology (COBIT) e le rende correggibili e disponibili per i clienti Microsoft.

Fase 1: valutazione

L'obiettivo della fase di valutazione nella gestione delle operazioni è quello di valutare le attuali sfide e capacità dell'organizzazione. Per supportare il processo di valutazione delle operazioni, Microsoft ha sviluppato Service Management Assessment (SMA) di Microsoft Operations Framework (MOF) come parte di MOF Continuous Improvement Roadmap (in inglese), nonché una versione online più leggera chiamata MOF Self-Assessment Tool (in inglese).

Figura 16. Ciclo di vita di miglioramento continuo MOF

Lo strumento Service Management Assessment (SMA) di MOF riguarda soprattutto il miglioramento delle prestazioni dei collaboratori e dei processi di gestione del servizio IT e l'implementazione delle tecnologie che aumentano il valore aziendale. Tutti i suggerimenti risultanti dallo SMA sono dettagliati e giustificati dal punto di vista del loro valore aziendale mentre la mappa dettagliata fornita per il miglioramento dei servizi è supportata da specifici indicatori chiave delle prestazioni che consentono di monitorare lo stato di avanzamento man mano che i miglioramenti vengono implementati.

Fase 2: identificazione

I risultati dello strumento Service Management Assessment (SMA) di MOF costituiscono le basi della fase di identificazione. La valutazione spesso esporrà varie aree di potenziale miglioramento nelle operazioni IT. Durante la fase di identificazione vengono presi in considerazione questi risultati e viene assegnata una priorità ai progetti di miglioramento in base alle esigenze aziendali. Gli strumenti di supporto sono inclusi nel MOF Continuous Improvement Roadmap per fornire assistenza con questa definizione delle priorità.

Fase 3: stima e pianificazione

La fase di stima e pianificazione per i miglioramenti operativi si basa sulle aree identificate e a cui è stata assegnata una priorità per il miglioramento. La guida relativa al MOF Service Improvement Program (SIP) attiva questa fase. SIP è suddiviso in due principali aree di interesse: il miglioramento specifico dei processi MOF/ITIL e la guida sul miglioramento dei servizi. Questa guida viene fornita mediante uno strumento che assiste gli utenti nell'individuazione degli specifici punti problematici, offre indicazioni mirate per la loro risoluzione ed è supportato da indicatori chiave delle prestazioni che consentono di misurare il miglioramento dei processi.   

Procedure consigliate per il passaggio al livello Razionale

I suggerimenti riportati in questa sezione si basano sui problemi comuni riscontrati al livello Standard e sulle aree di miglioramento ricercate nel livello Razionale. Si tratta soltanto di suggerimenti che possono essere differenti a seconda dell'organizzazione specifica o del settore.

Sebbene il livello Standard porti un maggiore utilizzo di strumenti per la gestione e il monitoraggio dell'infrastruttura e delle operazioni IT, oltre a un ambiente in cui i processi quali la gestione delle modifiche, della configurazione e dei rilasci sono standard e prevedibili, offre opportunità di miglioramento nelle principali aree. La gestione del livello di servizio è rudimentale con contratti di servizio (SLA) informali o solamente impliciti. La gestione della configurazione è informale e in genere consiste nella generazione basilare di fogli di calcolo ed elenchi di controllo e la gestione dei rilasci non è ben definita e manca di rigore.

Nell'infrastruttura di livello Razionale i costi derivanti dalla gestione dei desktop e dei server sono minimi e i processi e i criteri sono stati ottimizzati per iniziare a svolgere un ruolo importante nel supporto e nell'espansione dell'azienda. La protezione è estremamente proattiva e consente di rispondere a minacce e sfide in modo rapido e controllato. L'uso di una distribuzione che non richiede alcun intervento aiuta a ridurre al minimo i costi, il tempo di distribuzione e le sfide tecniche. Il numero delle immagini è minimo, così come il processo necessario per gestire i desktop. Questi clienti dispongono di scorte complete di hardware e software e acquistano soltanto le licenze e i computer di cui hanno bisogno. La protezione è estremamente proattiva con criteri e controlli rigidi, dal computer desktop al server, al firewall o alla Extranet.

Microsoft fornisce Microsoft Operations Framework (MOF) come modello ripetitivo per la definizione e il miglioramento delle operazioni IT. MOF definisce le funzionalità di gestione dei servizi (SMF, Service Management Function) come funzionalità operative logiche all'interno di un'organizzazione IT. Le SMF vengono raggruppate in quattro grandi aree o fasi: Modifica, Gestione, Supporto e Ottimizzazione. Nella presente guida vengono sottolineate le aree da migliorare che in genere vengono riscontrate nelle organizzazioni al livello Standard di ottimizzazione:

• Gestione del livello di servizio

• Gestione dei rilasci

• Amministrazione del sistema

• Amministrazione della rete

• Pianificazione delle attività

I miglioramenti a queste funzionalità di gestione del servizio potrebbero avere il maggiore impatto sul miglioramento e sull'efficienza operativa in base all'organizzazione. Si consiglia che l'organizzazione completi almeno l'autovalutazione online e preferibilmente una valutazione SMA (Service Management Assessment) completa per identificare le aree più importanti che richiedono il miglioramento di servizi e processi.

Gestione del livello di servizio

La gestione del livello di servizio (SLM) è un processo importante che allinea le esigenze aziendali alla distribuzione dei servizi IT. Fornisce il confronto con l'azienda che consente alle altre SMF di distribuire soluzioni IT in linea con i requisiti dell'azienda e a costi accettabili. L'obiettivo principale è quello di distribuire, gestire e migliorare correttamente i servizi IT.

Il processo di SLM viene utilizzato per allineare e gestire i servizi IT tramite un processo di definizione, accordo, misurazione delle operazioni e revisione. Lo scopo del processo di SLM include la definizione dei servizi IT per l'organizzazione e la determinazione dei relativi SLA. Il rispetto degli SLA viene garantito dall'utilizzo di contratti UC (Underpinning Contract) e contratti OLA (Operating Level Agreement) per la distribuzione interna o esterna dei servizi. L'introduzione del processo di SLM in un'azienda non fornirà un miglioramento immediato nei livelli di servizio distribuiti. Si tratta di un impegno a lungo termine. Inizialmente, il servizio cambierà lievemente, ma con il passare del tempo, verranno raggiunti e persino oltrepassati gli obiettivi prefissati.

Se un'organizzazione desidera implementare il processo di SLM, deve prima valutare quali servizi IT fornisce ai clienti e determinare di quali contratti di servizio esistenti dispone correntemente per tali servizi. Questa valutazione può rendere il reparto del servizio IT consapevole, spesso per la prima volta, dell'ampia gamma di servizi di cui è prevista la distribuzione. Grazie alle informazioni acquisite attraverso questo esercizio, l'organizzazione può sviluppare e implementare tutti i vantaggi del processo di SLM.

Tale processo richiede che l'organizzazione IT abbia una totale comprensione dei servizi che offre. L'implementazione del processo di SLM segue le procedure riportate di seguito:

• Creazione di un catalogo di servizi.

• Sviluppo degli SLA.

• Monitoraggio e creazione di report.

• Esecuzione di regolari revisioni del livello di servizio.

Gli SLA vengono sviluppati in linea con i requisiti e le priorità dei servizi documentati nel catalogo di servizi, i requisiti specificati durante la negoziazione degli SLA, il monitoraggio del servizio rispetto ai criteri degli accordi e la creazione di report e la revisione delle informazioni per evidenziare e rimuovere gli errori nei livelli delle prestazioni del servizio.

Fase 4: distribuzione (Service Level Management)

Attività di configurazione

Le attività di configurazione constano di una serie di procedure di valutazione condotte all'inizio di un progetto di SLM. Queste procedure preliminari consentono all'azienda di determinare se si necessita del processo di SLM e se si dispone delle risorse necessarie alla relativa implementazione. Durante questo processo, il reparto IT stabilisce un linea di base per l'azienda effettuando un'istantanea dei servizi esistenti e delle attività di gestione. La procedura finale consiste nell'analizzare le informazioni raccolte nei passaggi precedenti e utilizzare i risultati per pianificare l'implementazione del processo di SLM per ottenere i maggiori vantaggi per l'azienda.

Creazione di un catalogo di servizi

Il catalogo di servizi elenca tutti i servizi attualmente forniti, fornisce un riepilogo delle caratteristiche del servizio, descrive gli utenti del servizio e fornisce dettagli sui responsabili della gestione continua.

Un servizio viene definito dalla percezione dell'organizzazione aziendale. Ad esempio, la posta elettronica e la stampa possono essere considerate servizi, indipendentemente dal numero dei componenti di servizio richiesti per distribuire il servizio all'utente finale.

La formalizzazione di un catalogo dei servizi è un passaggio importante in quanto crea una registrazione ufficialmente riconosciuta. Rendendo il catalogo dei servizi una registrazione ufficiale all'interno dell'organizzazione lo si sottopone al controllo delle modifiche. Ciò è importante poiché la registrazione ha un valore solo se precisa e gestita.

Esistono molti modi per formalizzare un catalogo di servizi. Quando si determina il metodo più adatto alle proprie esigenze, è necessario considerare come si desidera visualizzare, creare report su e utilizzare il catalogo di servizi. È possibile archiviare un catalogo di servizi come parte del database di gestione delle configurazioni (CMDB) come un componente (il catalogo di servizi) o come i relativi servizi. Le applicazioni Microsoft, come Microsoft Excel o Microsoft Access, possono essere utilizzate per registrare i servizi e dettagli quali i componenti, gli effetti, le priorità, gli SLA e gli SLO. Se lo strumento selezionato consente che il catalogo di servizi faccia parte del CMDB, questo può aggiungere valore integrando le informazioni nel catalogo di servizi con l'elemento di configurazione (CI) nel CMDB. Questo a sua volta può essere utilizzato per aggiungere valore alla SMF Gestione delle modifiche, SMF Gestione degli imprevisti e a tutte le altre SMF tramite il CMDB.

Sviluppo dei contratti di servizio (SLA)

Uno SLA è un contratto tra il fornitore di servizi IT e la community clienti/utenti. Lo SLA formalizza i requisiti clienti/utenti per i livelli di servizio e definisce le responsabilità di tutte le parti coinvolte.

Di seguito vengono riportate le operazioni necessarie alla creazione di uno SLA:

• Definire il tipo di SLA. Ad esempio, si tratta di un contratto interno, esterno, OLA o a livello di servizio multiplo?

• Definire gli SLA. Definire, ad esempio, i livelli di servizio che verranno distribuiti, inclusi gli elementi concreti come la disponibilità, la capacità di reazione e le prestazioni, l'integrità, la precisione e la sicurezza.

• Negoziazione e determinazione di un accordo sugli SLA. Determinare, ad esempio, se quello che è stato stabilito possa essere distribuito a costi ragionevoli all'azienda e al reparto IT.

• Documentare lo SLA. Ad esempio, registrare per iscritto quello che è stato stabilito e le parti coinvolte.

Allineamento di contratti SLA, OLA e UC

I contratti UC (Underpinning Contract), contratti che stabiliscono accordi legali con un provider di servizi di terze parti su cui è stato creato il servizio distribuibile per lo SLA e i contratti OLA (Operational Level Agreement), un contratto interno che supporta i requisiti dello SLA, devono disporre di unità di misura allineate con il contratto SLA.

Monitoraggio del livello di servizio

La gestione del livello di servizio richiede un ciclo continuo di operazioni di accordo, monitoraggio e creazione di report sui progressi del servizio IT e l'attuazione delle azioni appropriate per bilanciare i livelli di servizio con i costi e le esigenze aziendali.

Una volta stabiliti e attuati gli SLA, la fase successiva della gestione del livello di servizio consiste nel monitoraggio delle prestazioni dei servizi rispetto ai criteri specificati negli obiettivi del livello di servizio (SLO, Service Level Objective). Esistono diversi metodi di monitoraggio della gestione del livello di servizio, ma quello principale riguarda la possibilità che le prestazioni dei criteri violino o siano prossime a violare lo SLA.

Analisi del contratto di servizio (SLA)

L'analisi dello SLA è una delle quattro OMR (Operations Management Review) di MOF. Si tratta di un checkpoint di gestione chiave e si verifica a intervalli specifici (come documentato nello SLA). Tale analisi ha lo scopo di garantire che l'azienda e il reparto IT abbiano l'opportunità di valutare le prestazioni rispetto agli obiettivi dello SLA e di analizzare l'operato dello SLA. L'analisi dello SLA è progettata in modo da coinvolgere a livello generale la gestione del processo di revisione, garantendo il coinvolgimento e la comunicazione del reparto IT e dell'azienda in tutte le future decisioni relative alla distribuzione del servizio.

Gestione dei rilasci

La funzionalità di gestione del servizio (SMF, Service Management Function) della gestione dei rilasci è responsabile della distribuzione delle modifiche in un ambiente IT (Information Technology). Dopo lo sviluppo, la verifica e la preparazione dei rilasci per la distribuzione di una o più modifiche, la gestione dei rilasci ha il compito di introdurre tali modifiche e di gestirne i relativi rilasci. La gestione dei rilasci contribuisce anche all'efficace introduzione delle modifiche combinandole in un rilascio e distribuendole insieme.

L'obiettivo del processo di gestione dei rilasci è di garantire che tutte le modifiche vengano distribuite correttamente nell'ambiente di produzione in modo che abbiano il minor impatto possibile. Di conseguenza, la gestione dei rilasci è responsabile di quanto segue:

• La conduzione della strategia di rilascio, ossia il progetto, il piano e l'approccio principale della distribuzione nella produzione di una modifica, in collaborazione con il consiglio consultivo per le modifiche (CAB, Change Advisory Board).

• La determinazione della disponibilità di ogni rilascio in base ai relativi criteri (qualità e pacchetto del rilascio, disponibilità dell'ambiente di produzione, piani di supporto e formazione, piani di distribuzione e ritiro e piano per la gestione dei rischi).

La gestione dei rilasci:

• Fornisce un rilascio organizzato in pacchetti per tutte le modifiche distribuite nella produzione e distribuisce esclusivamente le modifiche approvate dalla gestione delle modifiche.

• Necessita della gestione delle modifiche per approvarle e registrarle durante il processo di rilascio.

• Garantisce che, non appena effettuate le modifiche, queste vengano riportate alla gestione della configurazione per l'inserimento nel CMDB.

• Necessita delle informazioni sulla gestione della configurazione per creare e verificare ambienti di test validi nella fase di sviluppo del nuovo rilascio.

• Necessita della gestione della configurazione per valutare l'impatto delle modifiche sull'ambiente IT e per fornire un archivio definitivo per il pacchetto di rilascio.

Fase 4: distribuzione (gestione dei rilasci)

Pianificazione del rilascio

La prima fase del processo di rilascio consiste nella creazione di un piano che identifichi le attività e le risorse necessarie per distribuire correttamente un rilascio nell'ambiente di produzione. Tale piano comprende la determinazione delle attività da eseguire, del momento in cui devono essere completate (scala cronologica) e della relativa priorità in relazione ad altre attività. Dopo aver completamente compreso queste problematiche, il Release Manager può definire un piano dettagliato delle attività e assegnare le risorse appropriate al progetto. Nella gestione dei rilasci, il Release Manager è responsabile della creazione di un piano (progetto) di rilascio per ogni RFC approvata dalla gestione delle modifiche.

Generazione del rilascio

Una volta determinato il piano di rilascio, i membri del team per i rilasci identificano e sviluppano i processi, gli strumenti e le tecnologie necessari per la distribuzione del rilascio nella produzione. Sebbene la maggior parte dei rilasci (se non tutti) possa essere distribuita manualmente nella produzione, è possibile utilizzare una serie di strumenti e tecnologie per eseguire tale attività. Per ottimizzare l'utilizzo di tempo e risorse, il team per il rilascio deve identificare gli strumenti e le tecnologie che consentono di automatizzare il più possibile il processo di distribuzione.

Una volta selezionato il meccanismo di rilascio, il team per il rilascio crea un pacchetto di rilascio che contiene i processi, gli strumenti e le tecnologie necessari per distribuire il rilascio nella produzione tramite la procedura selezionata e per rimuoverlo dalla produzione se dovesse essere necessario.

Per alcuni rilasci, il pacchetto potrebbe essere composto semplicemente da una serie di procedure di installazione e rimozione documentate.

Il pacchetto di rilascio completo deve essere verificato in un ambiente di laboratorio per consentire al team per il rilascio di acquisire un determinato livello di sicurezza nel garantire che il rilascio funzioni correttamente nella produzione. Dopo aver completato correttamente i test, il rilascio e il contenuto del pacchetto vengono collocati sotto il controllo della gestione delle modifiche.

Test di accettabilità

Fino a questo punto della procedura, i test avevano lo scopo di controllare il corretto funzionamento del rilascio e del pacchetto di rilascio all'interno di un ambiente di sviluppo. I test di accettabilità consentono agli sviluppatori e ai rappresentanti delle aziende di vedere l'esecuzione contemporanea del rilascio e del pacchetto di rilascio in un ambiente molto simile alla produzione. In alcuni casi, sono necessari dei test pilota per acquisire la sicurezza necessaria a procedere alla distribuzione globale della modifica.

Sebbene i test effettuati in un ambiente di produzione simulato forniscano al team per il rilascio un certo grado di fiducia nel rilascio, non garantiscono che il rilascio verrà eseguito correttamente nella produzione, dove le condizioni potrebbero essere significativamente diverse. Riguardo a questo, potrebbe essere necessario eseguire una serie di test controllati nell'ambiente di produzione per confermare che il rilascio realizzi le aspettative. L'esecuzione dei test pilota in un ambiente di produzione comporta una serie di rischi per tale ambiente e deve essere effettuata esclusivamente se le procedure di recupero contenute nel pacchetto di rilascio sono state sperimentate nell'ambiente di testing.

Preparazione al rilascio

Dopo aver completato i test pilota e di accettabilità, la fase successiva consiste nel preparare l'ambiente di produzione al rilascio, eseguire il processo di preparazione e accordarsi sulle operazioni da effettuare, passare all'analisi della disponibilità del rilascio o restituire il rilascio al proprietario della modifica o al Release Manager per ulteriori modifiche.

Il Release Manager, il gestore delle modifiche e il proprietario della modifica sono i protagonisti della discussione sull'analisi della disponibilità del rilascio, ma questa coinvolge anche rappresentanti di altri gruppi interessati, come i team per i test, il servizio di assistenza e la community degli utenti (in base alla natura e alle dimensioni del rilascio).

Anche se un rilascio non avesse superato una serie di test, sia nell'ambiente di laboratorio sia di produzione, i problemi potrebbero non essere tanto significativi da impedirne la distribuzione. Sebbene vi siano implicazioni per l'ambiente di produzione, potrebbero esserci diverse motivazioni commerciali convincenti per eseguire la distribuzione del rilascio.

Ad esempio, in un sito commerciale business to business, è possibile che una funzionalità come l'iscrizione automatizzata non funzioni. È semplice rimuovere questa funzionalità e utilizzare una soluzione alternativa manuale. Quindi, il team potrebbe decidere di procedere senza questa funzionalità.

Le esperienze dei test e gli insegnamenti tratti, oltre alle soluzioni alternative sviluppate, vengono acquisiti e documentati. Se i problemi vengono rilevati durante i test che riguardano la community degli utenti e i livelli di servizio, è necessario esaminare le soluzioni alternative e i problemi previsti con i rappresentanti del servizio di assistenza e accertarsi che le soluzioni alternative saranno disponibili per il servizio di assistenza prima della distribuzione. È possibile che siano necessarie altre RFC perché il rilascio funzioni come pianificato. In entrambi i casi, il registro delle modifiche deve essere aggiornato con la decisione e qualsiasi altra informazione di supporto.

Distribuzione del rilascio

Il processo di distribuzione del rilascio nell'ambiente di produzione dipende dal tipo e dalla natura del rilascio e dalla procedura di rilascio selezionata. In ogni caso, tuttavia, il Release Manager deve disporre di report sullo stato e, ove appropriato, di strumenti e tecnologie che consentono di registrare e monitorare i progressi della distribuzione. Quando vengono effettuate modifiche sui componenti IT durante la distribuzione, è necessario effettuare le modifiche corrispondenti agli elementi di configurazione e alle relazioni che li modellano nel CMDB.

Una volta distribuito il rilascio, il Release Manager ne conferma il corretto funzionamento prima di procedere con ulteriori distribuzioni. Per alcuni rilasci, il personale del supporto tecnico può ottenere conferma tramite una serie di strumenti e tecnologie; per altri, il Release Manager potrebbe dover chiedere al servizio di assistenza di contattare i singoli utenti per commenti e suggerimenti.

Se il rilascio delude le aspettative o se si verificano gravi problemi durante la distribuzione, può essere necessaria la gestione dei problemi per identificare e diagnosticare la causa principale del problema. Se è possibile trovare una correzione adatta o una soluzione alternativa, questo deve essere documentato e deve essere creata una richiesta di modifica per distribuirla nell'ambiente di produzione. In caso contrario, può essere appropriato utilizzare le procedure di ritiro per rimuovere il rilascio da tale ambiente.

Una volta completata la fase di distribuzione del rilascio, il processo di rilascio deve garantire che qualsiasi risultato e informazione sulle soluzioni alternative o sulle RFC generate a supporto del rilascio venga registrato. Anche nel caso in cui fosse necessario ritirare il rilascio, deve essere tutto registrato, inclusa qualsiasi informazione che supporti tale decisione.

Amministrazione del sistema

La funzionalità di amministrazione del sistema consente di eseguire l'amministrazione della protezione, il controllo e il monitoraggio dei servizi, la pianificazione delle attività, l'amministrazione della rete, l'amministrazione dei servizi directory, la gestione di output e stampante e la gestione dell'archiviazione. Il modo in cui progettare, sviluppare e implementare questa funzionalità sarà determinato dalle dimensioni e dall'architettura dell'organizzazione. Le organizzazioni di grandi dimensioni disporranno di modelli definiti chiaramente mentre le organizzazioni di dimensioni minori probabilmente consolideranno le funzionalità per gestire lo stato e le capacità operative dei sistemi.

L'obiettivo della SMF Amministrazione del sistema è di amministrare un ambiente informatico su base giornaliera. Questo implica gestire e fornire supporto operativo per diversi elementi all'interno dell'ambiente di produzione.

La funzionalità di amministrazione del sistema fornisce servizi amministrativi di supporto per ambienti informatici che contengono sia hardware centralizzato che distribuito.

Fornisce inoltre assistenza per l'amministrazione funzionale di altre SMF che non sono direttamente responsabili dell'implementazione e della gestione. Questa assistenza può comprendere quanto segue:

• Monitoraggio di primo livello di prestazioni e capacità per la funzionalità di controllo e monitoraggio del servizio.

• Amministrazione funzionale quotidiana della gestione degli account, tra cui l'aggiunta, l'eliminazione o lo spostamento di account. Richiesta di risorse quali privilegi di accesso alle stampanti e di protezione per l'amministrazione di servizi directory e l'amministrazione della protezione.

• Gestione delle risorse utilizzate per produrre report e output stampati per la gestione di output e stampante.

• Attività amministrative necessarie per eseguire il backup e ripristinare i dati importanti.

• Applicazione di criteri per la protezione di dati e risorse di rete condivise tra cui file, cartelle e stampanti.

Fase 4: distribuzione (amministrazione del sistema)

Implementazione del modello di amministrazione centralizzato

Nel modello di amministrazione centralizzato, tutte o la maggior parte delle operazioni e delle funzionalità di supporto sono localizzate centralmente in un uno o più siti. Con l'evolversi di aree locali, vaste aree, l'informatizzazione dei server client e distribuiti e le relative reti di supporto, sempre più organizzazioni hanno fatto grandi passi verso la centralizzazione del supporto per le risorse, le applicazioni e le soluzioni installate.

La larghezza di banda nei siti remoti e nelle filiali è sempre più disponibile e accessibile. Le tecnologie di base che supportano l'informatizzazione delle filiali (protocolli di trasmissione, strumenti di accesso remoto, server headless e così via) sono migliorate al punto che le filiali non necessitano più del proprio personale di supporto. Le aziende sono quindi sempre più in grado di centralizzare le funzionalità fondamentali di supporto necessarie per mantenere la disponibilità, l'affidabilità, il supporto quotidiano e la gestione dei sistemi distribuiti ai siti remoti o alle filiali.

L'amministrazione centralizzata in genere parte dal presupposto che tutti o la maggior parte dei sistemi informatizzati e delle risorse gestiti (amministrati) siano localizzati centralmente. Sebbene quasi sempre sia così, in alcuni casi le soluzioni specifiche (ossia, le applicazioni personalizzate, i database specializzati ecc.) non sono centralizzate nel data center aziendale, ma sono distribuite alle filiali o ai siti remoti. Questa distribuzione di applicazioni e database non impedisce di avere un approccio centralizzato al modello amministrativo.

Implementazione del modello di amministrazione centralizzato/remoto

Il modello di amministrazione centralizzato/remoto presenta la maggior parte dei vantaggi del modello completamente centralizzato. La maggior parte delle attività di amministrazione continua a essere eseguita nella sede centrale (ad esempio, nel data center centrale), mantenendo di conseguenza il maggiore controllo e consolidamento delle risorse necessarie per la gestione della funzionalità amministrativa.

Tuttavia, parte del consolidamento di risorse e controllo viene persa a causa del requisito di gestione di un ambiente data center remoto con la presenza amministrativa almeno in minima parte decentrata. I requisiti di gestione del sistema di riparazione sul sistema distribuito possono includere aggiornamenti del sistema che richiedono il riavvio del computer, come pure backup su nastro e funzionalità di archiviazione. In base all'applicazione o al determinato sistema gestito, è possibile che vi siano ulteriori requisiti amministrativi dei siti locali; è necessario stabilire le responsabilità necessarie in base all'applicazione della tecnologia.

Il modello di amministrazione centralizzato/remoto descrive i sistemi distribuiti a postazioni remote con tutto il controllo amministrativo principale che rimane nella sede centrale. Come descritto in precedenza, è necessario disporre di un data center nella postazione regionale o remota che contenga i server o le unità di archiviazione. Ciò implica che si sostengano i costi dell'infrastruttura del data center, che include l'impianto fisico, lo spazio pavimentato, la potenza, i cavi, HV/AC e i componenti di protezione.

Se l'applicazione della tecnologia evolve fino al punto da rendere questo modello non più perseguibile (ossia che non soddisfa più i contratti di servizio) o non più a costi contenuti, potrebbe essere necessario passare a un modello amministrativo distribuito. In un modello amministrativo distribuito, le risorse informatiche come le risorse umane si trovano fisicamente nella postazione remota. Questo modello viene descritto nella sezione che segue.

Implementazione del modello di amministrazione centralizzato/delegato

Questo modello tenta di combinare gli elementi migliori dei modelli di amministrazione remoto e centralizzato con tutte le funzionalità e i vantaggi inerenti, realizzando persino alcuni vantaggi del modello di amministrazione distribuito. Tali vantaggi vengono ottenuti delegando un sottogruppo relativamente piccolo e specifico di attività amministrative e responsabilità alle filiali locali e ai siti remoti.

Come con il modello centralizzato, la funzione amministrativa principale e la forza lavoro amministrativa risiedono nel data center aziendale (centrale) e tutte le direttive e i controlli amministrativi hanno origine da questa postazione. Le risorse centralizzate continuano a gestire i server di rete basati sul data center centralizzato e i servizi nonché ad amministrare in remoto i servizi in rete ove possibile, ragionevole e applicabile.

In alcune circostanze, è necessario distribuire servizi, risorse e server specifici. In questi casi può essere prudente e/o più efficace consentire che alcune delle attività amministrative vengano eseguite nelle postazioni regionali o remote. Ciò viene effettuato delegando un'autorità specifica alle risorse della postazione remota. Con "autorità specifica" si intende un piccolo sottogruppo di diritti amministrativi e accesso che consente agli amministratori remoti di eseguire attività distinte specifiche.

Implementazione del modello di amministrazione distribuito

A differenza degli altri modelli, l'amministrazione distribuita fa affidamento sulle risorse di supporto completo che si trovano nei siti remoti o nelle filiali. Le risorse che si trovano nei siti posizionati in remoto eseguono le funzionalità di supporto fondamentali (sebbene critiche) necessarie per mantenere l'integrità, la disponibilità e l'affidabilità dei sistemi distribuiti a questi siti.

È possibile che continuino a esservi direttive aziendali per la gestione dei sistemi distribuiti alle postazioni remote. Alcune di queste direttive potrebbero riguardare le prestazioni, la scalabilità, un determinato tipo di applicazione o i costi o la disponibilità della larghezza di banda della rete che dovrebbe supportare una soluzione centralizzata.

Le risorse informatiche e umane vengono completamente distribuite alle filiali remote e ai siti regionali. Di conseguenza, l'organizzazione può comprendere molto meglio le prestazioni del sito locale per le specifiche applicazioni della tecnologia.

Implementazione dell'amministrazione distribuita del modello dei data center centralizzati

La quinta possibilità di amministrazione del sistema, qui denominata modello "Follow the sun", può essere anche denominata modello "amministrazione distribuita-data center centralizzato" (più di uno).

"Follow the sun" in questo contesto significa fornire supporto globalmente 7 giorni a settimana, 24 ore al giorno, spostandone la responsabilità tra diverse zone del mondo in modo che nel momento in cui un ufficio chiude ne stia aprendo un altro.

Questo modello è unico e non è implementato tanto quanto i quattro modelli base precedentemente descritti. Da notare, tuttavia, che le aziende hanno tentato o stanno attualmente tentando di applicare questo modello per il lavoro delle organizzazioni.

Amministrazione della rete

La funzionalità di gestione del servizio di amministrazione delle rete riguarda principalmente le reti operative, che costituiscono i componenti dell'infrastruttura tramite cui i sistemi dei computer e le periferiche condivise comunicano tra loro. Si tratta del livello più basilare di un'infrastruttura IT; senza strutture di rete non esiste infrastruttura, solo una raccolta di singoli computer.

L'obiettivo della SMF Amministrazione di rete è quello di fornire e costituire una solida base di processi per l'amministrazione di un ambiente di rete su base quotidiana. Questo implica gestire e fornire supporto operativo per diversi elementi all'interno dell'ambiente di produzione. Gli obiettivi della SMF comprendono la pianificazione e la distribuzione di servizi per espandere le strutture di rete esistenti, come pure i servizi di supporto per la risoluzione dei problemi e la correzione degli errori nell'ambiente di rete. Attraverso l'efficace implementazione della SMF Amministrazione di rete, le organizzazioni IT possono prevedere quanto segue:

• Miglioramento della distribuzione dell'infrastruttura di rete.

• Miglioramento dei processi per la risoluzione dei problemi e dei processi associati per la gestione degli imprevisti.

• Aumento dell'affidabilità della rete.

• Aumento della disponibilità di servizi e soluzioni IT.

Una rete tipica è costituita da hardware, tra cui collegamento dei cavi, router, switch, hub, server fisici e altri componenti, e software o firmware che controlla il modo in cui vengono utilizzati i componenti fissi. Nel modello di rete descritto da OSI (Open Systems Interconnection), la tipica infrastruttura IT è costruita a livelli, dai componenti basali che vengono utilizzati da tutti i servizi che si trovano in fondo alla pila alle applicazioni specializzate che si trovano all'inizio.

I livelli che costituiscono la pila OSI sono i seguenti (dalla parte superiore alla parte inferiore):

1. Applicazione

2. Presentazione

3. Sessione

4. Trasporto

5. Rete

6. Collegamento (Collegamento dati)

7. Fisica

L'amministrazione della rete riguarda, in genere, i primi tre livelli della pila, costituiti principalmente da componenti hardware. Ci sono alcune sovrapposizioni tra l'amministrazione della rete e del sistema a livello di trasporto, che comprende i protocolli di collegamento e di rete che abilitano il trasferimento di dati da un punto a un altro. Dal punto di vista MOF, la gestione di servizi quali DNS, WINS e DHCP fornisce i servizi di risoluzione dei nomi di base necessari ai servizi IT completi. In base all'organizzazione, questi servizi principali possono anche essere considerati come funzionalità del servizio di rete. Poiché DNS, WINS e DHCP vengono eseguiti sui server, i server di rete a volte vengono inclusi tra i componenti hardware gestiti dalla SMF Amministrazione di rete.

Fase 4: distribuzione (amministrazione della rete)

Gestione di una rete

Rendere operativa la rete è principalmente una questione di monitoraggio delle relative prestazioni, valutazione rispetto alle norme previste e generazione di elementi di lavoro per la risoluzione dei problemi nel caso si verifichi una diminuzione delle prestazioni. La maggior parte dei componenti hardware all'interno di una rete deve funzionare senza intervento o gestione da parte degli utenti, con le specifiche fornite dal produttore per il valore MTBF (Mean Time Between Failure) e altri criteri delle prestazioni. La SMF Gestione delle funzionalità di MOF fornisce informazioni sulla pianificazione delle funzionalità che consentono al team di progettazione della rete di ottimizzarne le prestazioni.

Tuttavia, i componenti basati sul server della rete necessitano periodicamente di attenzione. Questi componenti necessitano di backup regolari, ove applicabili, e di valutazioni dei requisiti di archiviazione o capacità, in conformità alla SMF Gestione dell'archiviazione.

Supporto di una rete

Il supporto della rete è strettamente collegato alle attività della fase Supporto, in particolar modo la SMF Gestione degli imprevisti e la SMF Gestione dei problemi. Attraverso il processo di risoluzione degli imprevisti descritto nella SMF Gestione degli imprevisti, gli specialisti di rete IT correggono errori di rete, sviluppano soluzioni alternative e prevengono o attenuano problemi di rete imminenti. Sebbene il processo generico per la risoluzione degli imprevisti sia descritto nel documento della guida della SMF Gestione degli imprevisti, i processi specifici della rete per la risoluzione dei problemi vengono forniti nelle sezioni che seguono.

Pianificazione delle attività

La SMF Pianificazione delle attività riguarda la garanzia dell'efficace elaborazione dei dati in un periodo prestabilito e in una sequenza prescritta per ottimizzare l'utilizzo delle risorse di sistema e minimizzare l'impatto sugli utenti online. Un processo batch è l'interazione di un sistema con un database che viene eseguito in background e in modo sequenziale senza intervento da parte dell'utente finale. L'esecuzione dei processi batch può essere automatizzata o avviata manualmente. I processi batch in genere vengono eseguiti dopo le ore lavorative, quando l'interazione dell'utente con il sistema è ridotta.

Le esecuzioni dei processi batch in genere necessitano della propria architettura poiché tendono a utilizzare una grande quantità di risorse e di tempo e sono processi ripetitivi. Il processo solitamente consiste nella lettura di grandi quantità di dati da un database, nell'elaborazione dei dati e nella restituzione dei risultati a un database. Questo processo viene svolto attraverso l'esecuzione degli script.

Vengono di seguito riportati i tipi di processi batch eseguiti dalle organizzazioni:

• Report di gestione finanziaria

• Report di marketing

• Report di gestione della catena di fornitura

• Report di inventario

• Report delle fatture

• Elaborazione del conto cliente (fatturazione mensile ecc.)

• Backup automatizzati di dati dell'applicazione e di sistema

• Report della pianificazione della capacità e dei riepiloghi di elaborazione del sistema

Fase 4: distribuzione (pianificazione delle attività)

Architettura del batch

L'architettura di un batch consiste nei processi e i componenti utilizzati per gestire efficacemente l'elaborazione del batch. Lo scopo dell'architettura del batch è quello di ottimizzare l'elaborazione (migliorare il tempo di risposta e l'utilizzo delle risorse di sistema) eseguendo i batch durante i periodi di minore attività. L'architettura deve fornire al gestore delle capacità un'interfaccia di semplice utilizzo e consentire un approccio standard centralizzato per la pianificazione, il monitoraggio e la correzione degli errori del batch. L'architettura deve essere estremamente scalabile per soddisfare le future esigenze dell'organizzazione. Deve anche essere estremamente disponibile, con un tempo di inattività minimo e minimizzare l'impatto sulle operazioni online, che in genere, vengono eseguite contemporaneamente alle operazioni batch. Alcune organizzazioni possono decidere di disporre di componenti di backup, come il server degli eventi, per garantire il completamento di tutti i processi batch mission-critical.

I componenti base dell'architettura del batch includono il server di gestione, il database delle capacità (CDB), il monitor, la stampante, i server delle applicazioni e i database. Oltre al monitor collegato al server di gestione, ogni server delle applicazioni deve disporre di un monitor che consenta di visualizzare l'attività di elaborazione del batch locale; questo semplifica anche l'analisi degli errori a livello locale.

Elaborazione del batch

Prima di introdurre le esecuzioni pianificate del batch, è utile comprendere la gerarchia del processo batch e il contenuto dello script di un batch. L'esecuzione di un batch consiste in diversi processi batch indipendenti pianificati per l'esecuzione frequente. Una grande organizzazione può eseguire diversi batch nell'arco della giornata, in base alle risorse necessarie per l'elaborazione. Ogni processo batch consiste in più operazioni di processo batch che controllano le specifiche attività dell'esecuzione del processo.

Un'organizzazione in genere elabora numerosi processi batch. Per garantire un approccio coerente all'esecuzione di ogni processo, è necessario pianificare lo scheletro di un processo batch che contiene il codice standard necessario per ogni processo; le informazioni specifiche sul processo devono essere codificate in una determinata area all'interno dello scheletro. Lo scheletro consente anche di semplificare lo sviluppo e la gestione dei requisiti standardizzando il contenuto e la struttura degli script dei processi. Ad esempio, ogni tipo di azione standardizzata, come la notifica dell'esecuzione corretta o non corretta di un processo batch, l'archiviazione dei dati di transazione e l'eliminazione, deve essere inclusa nel codice di ogni script eseguito.

Le esecuzioni del batch pianificate vengono avviate da uno strumento di pianificazione in una finestra batch predefinita, in genere quando l'attività degli utenti del sistema è al minimo. Dopo aver programmato lo strumento di pianificazione, non dovrebbe essere necessario alcun intervento da parte del gestore delle capacità durante le esecuzioni del batch a meno che non si verifichi un errore da cui lo strumento non è in grado di eseguire un recupero.

Lo strumento di pianificazione avvia tutte le esecuzioni del batch. Se l'esecuzione non inizia come pianificato, lo strumento si blocca e registra un errore nel registro errori; alcuni strumenti di pianificazione sono in grado di provare a riavviare l'esecuzione del batch. Se l'avvio avviene correttamente, viene eseguito il primo processo batch. Lo strumento di pianificazione gestisce l'esecuzione dei processi su ogni server delle applicazioni destinato a eseguire l'elaborazione dei batch. Se non si verificano errori durante l'esecuzione del processo, lo strumento registra il corretto completamento del processo nel registro batch e viene eseguito il processo successivo.

Se si verifica un errore durante l'esecuzione di un processo batch, lo strumento di pianificazione arresta l'elaborazione di tale processo e viene inviato un errore al registro errori. L'effettiva esecuzione di un processo batch dipende da una serie di dati che potrebbero essere la causa della mancata esecuzione di un processo. Ad esempio, potrebbero essere necessari i seguenti dati:

• Disponibilità dei dati di produzione

• Completamento di un processo da cui dipende il processo in coda

• Disponibilità delle risorse per eseguire il processo

• Priorità del processo e della finestra del batch

È possibile che vengano generati degli avvisi durante l'elaborazione del processo se, ad esempio, la CPU o la capacità dello spazio su disco supera il valore limite per un server delle applicazioni che elabora il processo batch. Gli avvisi non impediscono il completamento di un processo batch; tuttavia, il gestore delle capacità deve considerare tutti gli avvisi il prima possibile perché questi potrebbero causare errori nell'elaborazione dei futuri processi. Se un errore provoca l'arresto di un processo, alcuni strumenti di pianificazione tentano di risolvere automaticamente il problema e iniziano l'elaborazione del processo dal passaggio che era in esecuzione al momento dell'arresto. Il recupero è utile durante l'elaborazione di processi batch molto lunghi perché consente di non dover riprendere dall'inizio i processi interrotti. Se non è possibile eseguire il recupero, è necessario riavviare il processo.

Se lo strumento di pianificazione non è in grado di riavviare o recuperare un processo interrotto (o di riavviare o ripristinare in una determinata istanza), il gestore delle capacità deve iniziare manualmente a riavviare o ripristinare le procedure.

Attività di pianificazione dei processi

In teoria, l'architettura del batch deve essere configurata in maniera tale da consentire il minimo intervento da parte del gestore delle capacità. Tuttavia, il gestore delle capacità deve eseguire ancora numerose attività quotidiane, tra cui:

• Monitoraggio

• Analisi

• Ottimizzazione

• Implementazione

• Gestione degli eventi

• Gestione delle richieste di operazioni necessarie

• Modifica della pianificazione

• Backup del sistema

• Archiviazione

• Controllo

• Voce registro del gestore delle capacità

• Creazione di report

Ognuna di queste attività è parte integrante del processo di pianificazione delle attività. Le attività di monitoraggio, analisi, ottimizzazione e implementazione costituiscono un processo iterativo. I dati relativi al processo comprendono l'utilizzo delle risorse e i limiti dei contratti OLA rispetto ai quali viene monitorata l'architettura del batch. Si tratta di attività continue il cui obiettivo è ottimizzare le prestazioni e l'utilizzo dell'architettura. Le restanti attività vengono eseguite in risposta a un evento, una richiesta o un requisito.

Documentazione e formazione

Tutti i criteri e le procedure devono essere chiaramente documentati affinché il gestore delle capacità disponga di un riferimento che lo guidi nelle attività quotidiane. La documentazione deve contenere informazioni su quanto segue:

• Procedure per l'avvio e l'arresto delle esecuzioni batch.

• Procedure per la modifica della priorità dei processi.

• Procedure per la gestione di avvisi ed errori.

• Procedure per la gestione degli errori comuni.

• Procedure per l'analisi della causa degli errori.

• Procedure per l'escalation degli errori.

• Procedure per l'inoltro delle RFC.

• Procedure per la documentazione delle attività nel registro del gestore delle capacità.

• Procedure per specificare cosa debba essere monitorato e quando.

• Procedure per la gestione delle richieste di operazioni necessarie tra cui l'esame, la verifica e l'esecuzione di queste richieste.

Senza una formazione adeguata, il gestore delle capacità non sarebbe in grado di eseguire le attività descritte in questo documento. È importante che il gestore delle capacità riceva una formazione adeguata in modo che l'elaborazione degli errori avvenga correttamente e tempestivamente. Il gestore delle capacità può partecipare a corsi di formazione organizzati dal fornitore, qualora fossero disponibili, sullo strumento di pianificazione utilizzato dall'organizzazione.

Ulteriori informazioni

Per ulteriori informazioni, visitare il sito Web Microsoft Operations Framework (in inglese).

Per informazioni su come il reparto IT Microsoft utilizza Microsoft Operations Framework e le procedure consigliate per la gestione del servizio IT, andare all'indirizzo https://www.microsoft.com/technet/itshowcase/content/mofmmppt.mspx.

Checkpoint: processi di gestione, ottimizzazione e modifica

	Requisito
	Implementata la gestione dei livelli di servizio nelle operazioni IT.
	Implementate le procedure consigliate per la gestione dei rilasci.
	Ottimizzati i processi di amministrazione del sistema e della rete.
	Implementate le procedure consigliate per la pianificazione dei processi.

Dopo aver completato le operazioni elencate in precedenza, l'organizzazione soddisfa il requisito minimo del livello Razionale per il requisito Processi di gestione, ottimizzazione e modifica del modello di ottimizzazione dell'infrastruttura principale. Si consiglia di seguire le indicazioni contenute nelle risorse aggiuntive relative alle procedure consigliate per la gestione delle operazioni in Microsoft Operations Framework.