a cura di Alessandro Nizzo
Posts tagged ‘Infrastruttura ICT’
Questo è un post segnalibro di risorse interessanti per tutti i consulenti interessati ad intraprendere un’attività di management ICT senza reinventarsi la ruota.
Schema processi ITIL:
Le differenze tra le due versioni di ITIL sono esemplificate ottimamente in questo articolo di Stefano Rossini su Javaportal.
Spero di avere fornito due buoni punti di partenza per avviare lo studio di questo framework.
Service Continuity Management (“gestione della continuità del servizio”) è il processo mediante il quale si pianificano i piani di emergenza da attuare in casi di eventi catastrofici che dovessero compromettere seriamente, e/o mandare “down”, servizi ICT. Implica in primo luogo l’analisi dei rischi e l’implementazione di contromisure per ridurre al minimo la probabilità di tali eventi.
Il processo segue il workflow in figura
E’ una domanda alla quale è difficile fornire una risposta, in quanto il costo può variare in funzione di diversi fattori, in particolare:
In generale il costo della business continuity dei servizi dovrebbe essere controbilanciato dal valore aggiunto dello stesso e/o dal potenziale costo che si registrerebbe in caso di guasto.
Ho già parlato di questo argomento in un vecchio post ("Come si vende un progetto di infrastruttura ICT ?" ), e lo farò in futuro.
Il processo di Service Level Management (“gestione del livello di servizio”) ha come obiettivo quello di garantire che tutti i servizi ICT (connessione internet, fonia, email, software gestionale, etc.) siano mantenuti “up” per un “periodo accettabile”.
L’estensione di tale periodo definisce il “livello” del servizio.
E’ in pratica il processo che disegna il trade-off (compromesso) tra capacità e disponibilità.
Tale compromesso va sottoscritto in accordo con tutte le parti, tipicamente:
La Di Mauro srl ha un’officina dislocata presso una sede distaccata. In virtù della complessità dei servizi ICT offerti dalla sede centrale, in ambito di disegno dell’architettura di rete, si è optato per una Virtual Private Network, implementata su firewall di proprietà aziendale, al fine di garantire il collegamento tra le due sedi.
I punti di failure, in un contesto del genere, sono:
Vista l’assoluta necessità di mantenere il collegamento VPN sempre “up” durante le ore lavorative, si sono presi accordi con alcuni fornitori di hardware sul territorio, e si è deciso di dotarsi due linee XDSL per sede, una primaria e una di backup. Si sono poi presi SLA (Service Level Agreement – Accordi sui Livelli di Servizio) con il provider di connettività, del tipo:
Di seguita una immagine riepilogativa della To do list da attuare per implementare il processo
I passi sono i seguenti:
La “gestione della disponibilità e delle capacità” viene implementata in ITIL mediante l’utilizzo di due processi distinti.
Obiettivo del processo di “gestione della disponibilità” è quello di garantire che i servizi ICT abbiano downtime (tempo di malfunzionamento) bassi, soprattutto nelle ore necessarie.
Anche questo processo risulta essere caratterizzato da una fase proattiva, ed una fase reattiva:
Obiettivo del processo di “gestione delle capacità” è quello di aiutarvi a garantire che i componenti delle infrastrutture ICT siano in grado di supportare i servizi richiesti.
Esempi di capacità sono:
Questo processo risulta essere caratterizzato prevalentemente da una fase proattiva, che comporta la pianificazione della crescita necessaria di capacità, in funzione del cambiamento dei servizi / SLA, e l’individuazione di problemi di capacità potenziale (prima del loro verificarsi).
Tuttavia ci sono due temi comuni alla gestione delle disponibilità e a quella delle capacità: il rilevamento e la prevenzione. FITS razionalizza e semplifica l’approccio di ITIL, sulla base di questa comunanza, esemplificando due sotto-processi.
Monitorare la rete vuol dire rilevare tutte le attività in essere, e l’impatto che le stesse hanno sull’infrastruttura. Monitorare le capacità, i picchi di richiesta / uso, ricercare punti di failure e/o colli di bottiglia, sono tutte azioni incluse in questo sotto-processo che può essere sintetizzato nella figura che segue.
La manutenzione programmata (o preventiva) è incentrata sull’utilizzo intelligente delle informazioni risultanti dal monitoraggio di rete.
In sintesi si cerca di individuare i miglioramenti che possono essere svolti per evitare problemi di disponibilità e di capacità prima che accadano.
Riprendiamo i lavori continuando la rapida carrellata su FITS
, e affrontando nuovamente (lo abbiamo già fatto quì) il processo di Problem Management.
Nel post citato volli evidenziare, utilizzando un esempio banale, la differenza tra i due processi che, a prima vista, in virtù del nostro vocabolario ridotto (parlo di noi “tecnici”), possono apparire identici.
In realtà l’obiettivo del processo di “gestione dei problemi” è quello di ridurre al minimo sia il numero che la gravità degli incidenti.
Risulta pertanto essere un processo caratterizzato da una fase proattiva, ed una fase reattiva:
Se esiste un dipartimento ICT con risorse di personale e finanziarie adeguate, la fase “reattiva” del processo differisce dall’obiettivo della “gestione degli incidenti”, in quanto tenta dal principio di ripristinare il servizio al cliente, seppur il più rapidamente possibile, ma cercando di attuare da subito una soluzione permanente.
Un incidente si verifica quando qualcosa non funziona nel modo previsto.
Le espressioni maggiormente utilizzate sono:
Tuttavia il termine usato con FITS è “incidente“.
Un problema può essere:
Quindi un problema può esistere senza avere un impatto immediato per l’utente, mentre gli incidenti sono di solito più visibili e l’impatto sull’utente è più immediato.
Compiti per le vacanze.
E’ difficilissimo mantenere una linea di condotta aderente agli obiettivi prefissati a inizio anno mentre si lavora, per svariati motivi che (solo) chi lavora (sul serio) conosce.
E allora perché non usare un pezzetto delle proprie preziose ferie, per valutare dove siamo e ripensare la priorità dei progetti che stiamo seguendo?
Non sarà facile mettere ordine nelle cartelle cartacee ed elettroniche, analizzare i risultati raggiunti, i compiti posticipati e poi dimenticati, etc etc … ma sarà utile e soprattutto potrete farlo senza “fretta”, questa “emozione” che sta rovinando il mondo.
Aiutatevi riscrivendo gli obiettivi su un foglio di carta o in alternativa, se avete un netbook, con una mappa mentale.
Se lavorate nel mio settore, e soprattutto se volete continuare a farlo come consulenti, seguite questa piramide
L’ho trovata in questo interessantissimo articolo su TechRepublic.
Si commenta da sola. Sono sicuro che il ragionamento di fondo (le cose “importanti”, quelle veramente importanti, si fanno prima) si applica ad ogni “sistema”.
Come al solito i il riscontro positivo da parte del committente, si avrà nel lungo e medio periodo. Troppo spesso imprenditori poco illuminati, o frettolosi, ci fanno commettere degli errori che noi, per ragioni di visibilità o di un qualche tornaconto personale (non necessariamente di tipo economico, parlo della soddisfazione che si prova nel fare delle cose anziché altre), facciamo troppo poco per evitare.
Le fondamenta sono “importanti”. Smettiamola di costruire grattacieli su delle palafitte. Pretendiamo il “tempo necessario” per la realizzazione di infrastrutture solide.
Tanto prima o poi i debiti si pagano, ma se non si rispetta una gerarchia nei progetti ICT (e probabilmente anche quelli di altra natura), i conti tornano più “salati”.
Buone vacanze a tutti!
PS. La mia idea di “fretta”
Continuiamo la rapida carrellata sui processi FITS.
La gestione della configurazione è il processo di creazione e mantenimento delle informazioni rilevanti di ogni oggetto/elemento che costituisce l’infrastruttura ICT.
In altri termini è l’insieme di azioni che è necessario svolgere per mantenere costantemente aggiornato l’inventario hardware / software / servizi ICT.
Per mettere in atto il processo è indispensabile dotarsi di un CMDB, ovvero di un database estendibile, in grado di memorizzare tutte le informazioni di interesse degli oggetti di configurazione, denominati Configuration Item (CI).
Dal sito di Tecnoteca, che ha sviluppato e promuove CMDBuild, ovvero un CMDB Open Source tutto italiano, vi riporto alcuni passaggi chiave che meglio fanno comprendere di cosa stiamo parlando.
Chi utilizza il CMDB
Le organizzazioni per le quali è strategico avere sempre sotto completo controllo la situazione degli elementi informatici utilizzati(Gestione della Configurazione), conoscendone in ogni momento la composizione, la dislocazione e le relazioni funzionali.
Informazioni mancanti o non aggiornate significano costi inutili, operazioni ridondanti, ritardo nella risoluzione dei problemi, intralcio alle attività aziendali.
Le parole chiave di un CMDB sono: velocità di risposta < – > controllo del sistema
Quali elementi informatici gestisce il CMDB
- hardware: computer, periferiche, sistemi di rete, apparati di telefonia
- software: di base, di ambiente, applicativo
- documenti: progetti, contratti, manualistica
- altre risorse, interne ed esterne
A quali domande risponde il CMDB
- dove si trova un CI (configuration item) ?
- chi lo usa ?
- di cosa fa parte ?
- da cosa è composto ?quali sono e dove si trovano altri CI analoghi ?
- ho licenze sufficienti per l’utilizzo del software ?
- cosa è successo nella vita del CI ?
- su quali altri CI impatta una eventuale modifica ?
Un CMDB consente di:
- ridurre i problemi al proprio sistema informatico
- risolvere più velocemente i problemi residui
- disturbare meno frequentemente il personale più esperto
In altre parole diminuzione dei costi e miglioramento della qualità dei servizi.
Per contro gestire il sistema IT in modo controllato vuol dire anche:
- disporre nel posto giusto delle informazioni necessarie
- dotarsi di un sistema informatico di gestione
- utilizzare risorse che mantengano il sistema sempre aggiornato
Cosa fare in sintesi?
Riprendiamo la carrellata sui processi FITS.
Il change management è il processo per la gestione dell’attuazione delle modifiche all’infrastruttura ICT, è può quindi riguardare hardware, software o servizi, e la relativa documentazione.
Il suo scopo è quello di minimizzare il danno ai servizi di ICT causati dai cambiamenti, e di assicurare che le informazioni relative all’hardware, al software, ai servizi e alla documentazione siano tenute aggiornate.
Cosa genera un cambiamento?
Può essere il risultato di un guasto tecnico o di un problema infrastrutturale. In alternativa se si tratta di implementare un nuovo software o installare un nuovo hardware per rispondere ad una nuova esigenza funzionale, è necessario gestire l’attività con il processo di release management, discusso in un precedente post.
Alcuni esempi di cambiamento
Cosa fare in sintesi?
E’ dura la vita del CIO vero? Allora “aiutati che FITS ti aiuta” …
Nelle puntate precedenti ho elencato brevemente i processi di “Service Desk” e “Incident Management”.
Altrettanto brevemente, per consentire una lettura agevole di questi post introduttivi, è necessario fornire una definizione del processo di Release management.
Release Management è il processo di progettazione, costruzione, test e deployment di un nuovo hardware e/o software. Implementa il controllo di versione e aggiorna l’inventario hardware/software. L’obiettivo che si pone, è quello di fornire un metodo, coerente e ripetibile, per la distribuzione di un aggiornamento / novità all’interno della preesistente infrastruttura ICT.
Grossa enfasi viene data alle fasi di pianificazione e di preparazione dei nuovi servizi.
Le aziende che utilizzano tale processo, difficilmente impattano in ritardi di progetto, in quanto l’approccio strutturato consente di definire in anticipo le risorse necessarie per la realizzazione dell’obiettivo, e nel contempo riduce al minimo gli incidenti che interessano gli utenti ogniqualvolta viene introdotta una novità.
Di seguito una figura riepilogativa delle fasi del processo.
Definita la politica di rilascio (fondamentalmente bisogna rispondere alle domande “quando e come?”), pianficato / sviluppato / debbugato il servizio / applicazione, la fase di rollout consiste nella distribuzione / installazione dell’aggiornamento, e nel test in work dello stesso, che riguarda sia aspetti tecnici, che funzionali (rispetto dei requisiti “funzionali” forniti dal committente).
Il processo si interfaccia con quello di “Change Management” (attuazione del piano) e con quello di “Configuration Management” (aggiornamento della “situazione” parco macchine e/o del catalogo dei servizi).
Governare l’ICT è compito del Chief Information Officer.
Per non perdere la bussola (e ridursi ad avere un ufficio simile alla foto) è necessario innanzitutto stabilire i principi sui quali fondare la gestione di quella che, il più delle volte, è una azienda nell’azienda. Se siamo fortunati (o sfortunati … dipende dai casi), tali linee guida ci vengono imposte da uno standard al quale dobbiamo semplicemente adeguarci. Sto pensando a tutte quelle aziende che hanno una qualche certificazione di qualità che comprende la gestione dell’ICT nel loro manuale.
Se siamo sfortunati (o fortunati … dipende dai casi) e queste linee guida dobbiamo dettarle noi che facciamo?
Come spesso accade non dobbiamo inventarci la ruota ma solo scegliere. Esistono infatti differenti framework (insieme di processi) di best pratice (azioni pratiche da compiere) specifici per la gestione ICT.
Information Technology Infrastructure Library (ITIL) è un insieme di linee guida ispirate dalla pratica (Best Practice) nella gestione dei servizi IT (IT Service Management) e consiste in una serie di pubblicazioni che forniscono indicazioni sull’erogazione di servizi IT di qualità e sui processi e mezzi necessari a supportarli.
Sebbene sia stato sviluppato negli anni ottanta, ITIL non è stato largamente adottato fino alla metà degli anni novanta. Questa più larga adozione e conoscenza ha condotto all’emissione di standard a supporto, incluso ISO/IEC 20000 (precedentemente British Standards | BS 15000), il quale è uno standard internazionale che ricopre molti degli elementi di ITIL per la gestione dei servizi IT.
ITIL viene spesso considerato a fianco di altri framework di best practice quali Information Services Procurement Library (ISPL), Application Services Library (ASL), Dynamic Systems Development Method (DSDM), Capability Maturity Model (CMM/CMMI), e viene spesso collegato con l’IT governance attraverso Control Objectives for Information and related Technology (COBIT).
L’IT Service Management in quanto concetto è relativo ma non equivalente a ITIL. ITIL contiene una sezione specificatamente dedicata all’"IT Service Management" (la combinazione dei volumi sul Service Support e Service Delivery i quali sono uno specifico esempio di un framework ITSM), è comunque importante evidenziare che esistono altri framework.
Alternative
Oltre ITIL, esistono altri approcci all’IT Service Management, quali The BECTA Framework for ICT Technical Support (FITS) che è stato sviluppato dalla British Eductional Communications and Technology Agency ed è basato su ITIL ma è più snello per essere adottato nelle scuole secondarie e primarie britanniche (le quali hanno spesso dipartimenti IT molto piccoli). Similmente, The Visible OPS Handbook: Implementing ITIL in 4 Practical and Auditable Steps dichiara di essere basato su ITIL ma di essere specificatamente focalizzato sul più grande degli elementi di ITIL quello di "dare valore ai soldi".
Per chi volesse approfondire il discorso, la migliore risorsa online per ITIL in italiano, a mio avviso, è presente nel mio CIOROLL di fianco.
L’approccio utilizzato dalle alternative si adatta meglio a situazioni nelle quali le risorse, umane e tecnologiche, sono limitate. Tale condizione è tipica delle nostre PMI (o almeno di quelle al Sud).
“The Visible OPS Handbook”, redatto da ITPI (Information Technology Process Initiative, organizzazione no profit impegnata in attività di ricerca e sviluppo in ambito manageriale ICT), consiglia di implementare l’IT Service Management in 4 mosse:
FITS (The BECTA Frameworkfor ICT Technical Support) implementa un sottoinsieme dei processi ITIL.
Di seguito un elenco:
Riuscire a implementare tali processi (che cercherò di descrivere in post futuri) / seguire queste best practice, che altro non sono che “buon senso schematizzato e applicato”, è quanto di più difficile si possa fare ma, al tempo stesso, è l’obiettivo che ogni responsabile ICT deve perseguire con forza e volontà.
E’ chiaro che la scelta del framework da adottare dipende dalla tipologia di cliente che si segue. Nel mio caso utilizzo spesso FITS … e voi?
