Come lo abbiamo fatto: 600+ applicazioni, un Ente Regionale e la continuità che si ripaga da sola

Con questo articolo apriamo «Come lo abbiamo fatto»: una serie in cui prendiamo un progetto reale e lo raccontiamo com'è andato — senza nomi, per riservatezza, ma con i numeri e le scelte vere. Cominciamo da uno dei più impegnativi: la gestione pluriennale, l'evoluzione e la continuità operativa delle infrastrutture tecnologiche di un grande Ente Regionale italiano.

Abbiamo partecipato attivamente alla progettazione, implementazione e gestione di un modello completo di IT Service Management per un Sistema Informativo in rapida evoluzione, con un data center multi-sede di elevata complessità tecnologica. La fornitura ha riguardato la gestione e lo sviluppo delle infrastrutture a supporto di oltre 650 applicazioni distribuite su tre filiere tecnologiche, al servizio di migliaia di utenti interni ed esterni, con un team dedicato di professionisti specializzati.

Il progetto ha introdotto elementi di forte innovazione: un Sistema di Governance Operativa integrato, una soluzione di Business Continuity e Disaster Recovery con modello both-active e un approccio metodologico basato sulle best practice ITIL, garantendo piena conformità al D.Lgs. 235/2010 (art. 50-bis del CAD) e alle direttive dell'Agenda Digitale.

Il contesto e le sfide

L'Ente si trovava ad affrontare una trasformazione profonda del proprio Sistema Informativo. Da un'infrastruttura IT di tipo mid-range, progettata per le esigenze interne dell'Amministrazione, si era progressivamente passati a un data center dotato di un'infrastruttura tecnologica particolarmente complessa a livello di networking, storage e server, a supporto di servizi erogati non solo all'Ente stesso, ma anche a numerosi enti locali, associazioni di categoria, aziende private e cittadini del territorio.

Il processo di federalismo regionale aveva sostanzialmente modificato, sia in termini qualitativi che quantitativi, il perimetro del Sistema Informativo, comportando una crescita significativa dei volumi, dei sistemi e delle applicazioni da gestire: il numero di applicazioni pubblicate era cresciuto del 15% in un solo biennio, nelle tre filiere tecnologiche.

Le criticità identificate

L'analisi del contesto AS-IS aveva evidenziato problemi che chi lavora nella Pubblica Amministrazione riconoscerà al volo:

• frammentazione degli strumenti di monitoraggio: molteplici tool diversi (trouble ticketing, monitoraggio, CMDB, project management) con dati scorrelati e assenza di una visione integrata dei servizi IT;
• scollamento tra sviluppo ed esercizio: la mancata «saldatura» tra il ciclo di vita del progetto software e il ciclo di vita del servizio rappresentava l'anello debole della catena di controllo;
• assenza di un piano strutturato di Business Continuity e Disaster Recovery, in violazione degli obblighi normativi introdotti dal D.Lgs. 235/2010;
• storage non classificato secondo logiche di tier (performance, capacità, affidabilità), con conseguenti inefficienze operative;
• single point of failure a livello di connettività internet e protezione perimetrale;
• backup su nastro con finestre temporali insufficienti per i servizi critici;
• assenza di un cruscotto integrato per la governance operativa e la rendicontazione dei servizi.

Gli obiettivi strategici

L'Ente aveva definito obiettivi chiari — e nessuno di questi era «comprare tecnologia»:

1. adottare una metodologia di gestione dei servizi IT orientata ai processi, con il livello di qualità percepito dagli utenti come cardine di azione;
2. dotarsi di un piano di Business Continuity e Disaster Recovery conforme alla normativa vigente;
3. implementare una piattaforma integrata di governance per il controllo end-to-end dei servizi IT;
4. garantire la continuità operativa senza soluzione di continuità durante la transizione;
5. assicurare la piena misurabilità e trasparenza dei servizi erogati attraverso SLA e KPI oggettivi.

Modello organizzativo e governance

Abbiamo quindi progettato un modello organizzativo snello e flessibile, con chiari ruoli decisionali, strutturato su tre livelli di governance:

• Livello strategico — IT Steering Group: comitato esecutivo composto da rappresentanti dell'Amministrazione, con il compito di assicurare l'allineamento degli obiettivi strategici, valutare gli investimenti necessari e il percorso di evoluzione dell'infrastruttura IT;
• Livello tattico — Comitato di Controllo dei Servizi IT: organo operativo per la pianificazione e il coordinamento delle azioni attuative, con la figura del Technical Manager come interfaccia principale per le attività giornaliere di controllo, gestione e progettazione;
• Livello operativo — tre team integrati, descritti nella tabella che segue.

Area Change: integrazione del ciclo di vita del software e del servizio

Uno degli elementi più innovativi della soluzione è stata la creazione dell' Area Change, un'unità organizzativa trasversale ai tre team dedicata alla fase di «presa in carico» del software prodotto e successiva «trasformazione» in servizio all'utente — lo stesso principio che oggi applichiamo lungo tutto il ciclo di vita del servizio. L'Area Change ha garantito:

• l'integrazione tra la fase di progettazione e sviluppo dell'applicazione (Service Design) e la fase di erogazione del servizio (Service Operation);
• una forte attenzione alle fasi di test e validazione del servizio (Service Transition);
• la pianificazione delle attività di rilascio di ogni nuovo servizio/prodotto;
• l'individuazione e la proposta di strategie e percorsi di innovazione nel ciclo di vita dei servizi;
• il coordinamento degli interventi delle risorse dedicate alla definizione e al controllo degli standard e delle linee guida.

Area Audit e Miglioramento

Per garantire una valutazione costante e oggettiva della qualità dei servizi, abbiamo istituito l' Area Audit e Miglioramento, con le seguenti responsabilità:

• monitoraggio continuo dei parametri di qualità predefiniti (KPI e SLA);
• pianificazione di azioni di miglioramento anche in presenza di livelli soddisfacenti;
• supporto alla redazione di una Carta dei Servizi ICT per formalizzare il «patto di servizio» tra il Servizio Informativo e le Direzioni Generali fruitrici;
• gestione del processo di customer satisfaction;
• raccolta degli indicatori statistici per la rendicontazione periodica.

Il Sistema di Governance Operativa: un solo cruscotto, quasi tutto open source

Alla frammentazione degli strumenti abbiamo risposto partecipando all'implementazione di una piattaforma completa e integrata a supporto delle funzioni e dei processi IT — il cuore di quella che chiamiamo IT governance — strutturata in tre aree principali, costruite in larga parte su componenti open source.

Governance dei servizi

• gestione integrata di incidenti, problemi, change e configuration management tramite CMDBuild;
• strumento di trouble ticketing ( RT) per il tracciamento delle richieste di servizio e degli incident;
• interazione con i sistemi di bilanciamento ( LBL LoadBalancer) per il Capacity Management;
• knowledge base basata su Alfresco per la gestione documentale centralizzata.

Governance dell'infrastruttura

• Storage Management: gestione dei dati, backup e ripristino;
• System Fault & Performance Management: monitoraggio in tempo reale tramite Zabbix con console centralizzata, filtraggio e correlazione degli eventi;
• Application Performance Management: controllo dei servizi dal punto di vista utente con transazioni campione;
• storicizzazione dei dati in un data warehouse open source SpagoBI per analisi e reporting.

Gestione della conoscenza

• repository documentale centralizzato basato su Alfresco;
• organizzazione, persistenza e fruizione della conoscenza prodotta nell'ambito dell'erogazione dei servizi;
• supporto alle attività di formazione e addestramento.

Cruscotto Monitor di governance

Sopra tutto, il Cruscotto Monitor realizzato su tecnologia SpagoBI. Per un'amministrazione pubblica non è un dettaglio estetico: è la differenza tra dichiarare la qualità del servizio e poterla dimostrare, numero per numero. Il cruscotto ha offerto:

• vista d'insieme «semaforica» sullo stato globale dei servizi;
• navigazione dei KPI associati a ciascun servizio erogato;
• approfondimenti per dimensioni e periodi temporali diversi (real-time, giorno, settimana, mese);
• report, OLAP, data mining e QBE;
• Libro di Bordo: visione d'insieme su tutti gli eventi che caratterizzano l'erogazione dei servizi, con filtraggio per momento temporale, servizio, sistema, evento scatenante e tipologia;
• modulo di rendicontazione con ribaltamento dei costi sulle direzioni fruitrici;
• gestione delle presenze e dei turni del personale tecnico;
• Site Activity per la tracciatura di «chi fa che cosa»;
• attivazione progetti con visione dello stato di avanzamento tramite Redmine.

I processi fondamentali ITIL

È stato quindi implementato un set completo di Processi Fondamentali (PF) basati su ITIL v3, contestualizzati sulle specifiche esigenze dell'Ente:

Change Management e IMaaS

Per la gestione dei cambiamenti infrastrutturali abbiamo introdotto il concetto di «Infrastructure Model as a Service» (IMaaS): il Team Sviluppo Progetti eroga modelli infrastrutturali che, una volta approvati, vengono trasformati in architetture IT operative. Il processo di change si articola in:

1. Request For Change e analisi di fattibilità;
2. Service Design secondo le 4 P di ITIL (People, Products, Processes, Partners);
3. rilascio del Service Design Package (SDP) contenente requisiti, specifiche tecniche, piani di test, transition plan e operation plan;
4. approvazione da parte dell'Ente;
5. Transition: sviluppo ambienti di test e collaudo;
6. messa in produzione con supporto del Team Gestione Operativa;
7. CSI (Continual Service Improvement) trasversale a tutte le fasi.

È stato inoltre proposto un laboratorio virtuale (IaaS) per la simulazione delle fasi di transizione, con l'obiettivo di semplificare il processo di adozione e gestione del cambiamento, standardizzare le attività di transizione, garantire l'integrità delle configurazioni dell'infrastruttura di produzione e ridurre problemi e incident in produzione.

Business Continuity e Disaster Recovery: la continuità che si ripaga da sola

Il capitolo più innovativo è la business continuity. La soluzione è stata progettata in piena conformità con:

• D.Lgs. 30 dicembre 2010, n. 235, art. 50-bis (continuità operativa);
• direttive DigitPA (ora AgID) per gli studi di fattibilità tecnica;
• standard ISO 22301 / BS 25999 per il Business Continuity Management;
• framework ITIL — processo di IT Service Continuity Management (ITSCM);
• metodologia M_o_R (Management of Risk) per la risk analysis e il risk management.

Architettura multi-sito

L'approccio classico prevede un sito secondario che costa, consuma e resta spento in attesa dell'emergenza. Qui abbiamo fatto l'opposto, articolando l'architettura su più livelli.

Business Continuity Site (BCS) — all'interno del campus dell'Ente:

• modello both-active: il BCS non è un costo passivo ma partecipa attivamente all'erogazione dei servizi in tempo reale;
• replica asincrona a livello storage (Tier 4) per i servizi critici, tramite virtualizzatori IBM SVC e sistemi Global Mirror/FlashCopy;
• replica tramite agenti/snapshot (Tier 3) per i servizi a criticità inferiore, tramite VMware Site Recovery Manager e vSphere Replication;
• dorsale ethernet a 10 Gbit e Storage Area Network estesa con doppio fabric in fibra ottica;
• connettività internet autonoma e sistemi di protezione perimetrale dedicati.

Disaster Recovery Site (DRS) — presso provider esterno a oltre 80 km:

• predisposizione architetturale nativa per l'attivazione in emergenza;
• interconnessione tramite tecnologie DWDM (Dense Wavelength Division Multiplexing) per distanze superiori ai 100 km;
• infrastruttura prevalentemente virtualizzata con possibilità di bare metal restore.

Un sito di continuità che resta spento è un costo in attesa di un disastro. Uno che lavora ogni giorno è capacità produttiva — e si ripaga da solo.

LBL Surface Cluster: orchestrazione e prevenzione dello split brain

Il rischio tecnico più insidioso di un'architettura a due siti attivi è lo split brain: entrambi i siti convinti di essere quello «vero», con corruzione logica dei dati. Per la gestione delle procedure di failover/failback e la prevenzione di questo scenario, grazie alla collaborazione con il partner Oplon abbiamo introdotto la suite LBL Surface Cluster (Decision Engine e WorkFlow), con le seguenti funzionalità:

• algoritmo «Split Brain Assassin»: prevenzione della corruzione logica dei dati in caso di alimentazione parallela delle basi dati;
• Decision Engine: 3 istanze clusterizzate per sito, per la verifica costante del funzionamento dei servizi critici e la presa di decisioni;
• WorkFlow: esecuzione coordinata delle sequenze di attività (script, riavvii, spegnimenti) tramite comandi remoti RWC (Remote Workflow Command);
• auto-documentazione delle procedure di failover e failback;
• web console intuitiva per la riattivazione dei servizi anche da parte di personale non specializzato — perché nelle emergenze vere lo specialista potrebbe non esserci.

Livelli di protezione (Tier)

Non tutti i servizi valgono uguale, e la Business Impact Analysis lo ha tradotto in livelli di protezione differenziati — lo stesso principio che raccontiamo in «Il backup non basta»: RTO e RPO si definiscono per servizio, non per l'organizzazione intera.

I piani: BCP, DRP, BIA e analisi dei rischi

Si è quindi redatto un corpo documentale completo, mantenuto nel tempo:

• il Business Continuity Plan (BCP): identificazione dell'esposizione a pericoli interni ed esterni, asset hardware/software e processi atti a prevenire e ripristinare i servizi;
• il Disaster Recovery Plan (DRP): procedure operative step-by-step, check list, schemi tecnici per le fasi reattive di Response e Recovery;
• la Business Impact Analysis (BIA): quantificazione dell'impatto dell'interruzione dei servizi IT sul business;
• la Risk Analysis e il Risk Management: identificazione delle minacce, valutazione della probabilità di accadimento e definizione delle contromisure.

La gestione del servizio applicativo

Il processo — creato ad hoc — che governa l'intera vita di un'applicazione in esercizio, dalla nascita alla dismissione.

Presa in carico e avviamento

Il processo di presa in carico di un nuovo servizio applicativo ha previsto:

1. verifica della completezza e adeguatezza della documentazione;
2. analisi di impatto e gestione del cambiamento (CAB);
3. allestimento dell'ambiente di esercizio (software di base, applicativo, base dati);
4. allestimento dell'ambiente di monitoraggio (sonde e regole specifiche);
5. allestimento dell'ambiente di gestione (parametrizzazione e passaggio di consegne);
6. registrazione dei Configuration Item nel CMDB;
7. collaudo dell'intera infrastruttura;
8. formazione del Team Gestione Operativa.

Evoluzione del servizio

Per le evoluzioni (nuove funzionalità, cambi di configurazione), il processo ha previsto l'identificazione delle modifiche e l'analisi di impatto, l'esecuzione del regression test prima del rilascio in produzione e l'aggiornamento del CMDB e della documentazione operativa.

Terminazione del servizio

Per la dismissione di un servizio: verifica dell'impatto sugli altri servizi, salvataggio degli archivi, disinstallazione della componente applicativa, aggiornamento del CMDB e riallocazione delle risorse tramite il Capacity Management.

Formazione, knowledge management e trasferimento del know-how

Una fornitura pluriennale si giudica anche da come finisce: la conoscenza, alla fine, deve restare a chi la deve esercitare.

Addestramento del personale

Si è implementato un processo di knowledge sharing continuo con:

• un numero congruente di giornate di formazione annue per ciascuna risorsa;
• percorsi certificativi ITIL (Foundation, Service Strategy, Service Design, Service Operation, CSI) per i responsabili di unità;
• corsi presso la Scuola di Alta Formazione ICT interna;
• formazione a distanza (FAD) e seminari in presenza;
• auto-formazione su manuali di prodotto e risorse documentali.

Knowledge management

Il processo di knowledge management si è articolato in due fasi ricorsive: l' organizzazione della conoscenza (identificazione dei bisogni, ricerca, catalogazione in un repository classificato per processi di servizio) e la valorizzazione della conoscenza (distribuzione, utilizzo e continuo aggiornamento del know-how raccolto).

Trasferimento del know-how a fine fornitura

Il piano di exit management ha previsto:

• Step 1 — Programmazione: predisposizione della documentazione, riunioni preparatorie, allestimento di seminari, verifica dello stato dei sistemi tramite check list;
• Step 2 — Affiancamento: sessioni di apprendimento frontale, esecuzione autonoma di compiti specifici, valutazione e autovalutazione, training on the job;
• due mesi di assistenza on-demand successivi al termine della fornitura (e-mail, telefono, comunicazione online).

Risorse e competenze

Il Team Supporto Sistemistico Centralizzato ha operato con presidio H24 su sei aree verticali:

1. Infrastruttura (server blade IBM/HP, networking, virtualizzazione VMware/Citrix);
2. Middleware (WebSphere, JBoss, IIS, Apache, Tomcat);
3. Database (Oracle, SQL Server, PostgreSQL, MySQL, DB2);
4. Cartografia (sistemi GIS e territoriali);
5. OpenSource (Linux, Red Hat, soluzioni FOSS);
6. SAP (ambienti ERP, BW, CRM).

Il tutto sostenuto da un sistema di certificazioni e partnership:

ISO 9001ISO 14001ISO/IEC 27001CMMI Livello 3ITIL v3PMPPRINCE2

Risultati e benefici

Benefici infrastrutturali

• affidabilità: soluzione certificata dai fornitori e validata attraverso implementazioni analoghe;
• elasticità: componenti hardware e software scelte per rispondere con minimo impatto a cambiamenti infrastrutturali;
• standardizzazione: confronto costante con standard ISO, framework ITIL e normative di settore;
• resilienza: corretto dimensionamento delle infrastrutture e scelta ponderata delle tecnologie;
• controllo: gestione globale di tutti i siti tramite strumenti centralizzati.

Benefici economici

• economia di scala: il BCS attivo ha incrementato complessivamente i servizi erogati;
• virtualizzazione: riduzione del costo totale di possesso (TCO) dell'infrastruttura;
• ottimizzazione dello storage: razionalizzazione tramite tecnologia multi-tier (EasyTier) con dischi SSD per i dati critici e dischi capacitivi per il resto;
• riuso degli asset esistenti: limitazione dell'acquisto di nuovo hardware grazie alla ridistribuzione di risorse già in possesso dell'Ente.

Benefici organizzativi

• superamento del conflitto sviluppo/esercizio grazie all'Area Change;
• miglioramento continuo istituzionalizzato tramite l'Area Audit e il processo CSI;
• trasparenza nella cooperazione tra Ente e fornitore;
• Carta dei Servizi ICT come formalizzazione del patto di servizio;
• rendicontazione e ribaltamento dei costi sulle direzioni fruitrici.

Gli elementi di innovazione

Conclusioni

Il progetto realizzato rappresenta un caso di eccellenza nella gestione integrata delle infrastrutture tecnologiche per la Pubblica Amministrazione. La combinazione di competenze specialistiche, metodologia ITIL, strumenti open source di governance e soluzioni innovative di Business Continuity ha consentito all'Ente di:

• garantire la continuità operativa dei propri servizi IT in conformità alla normativa vigente;
• ottenere una visione integrata e trasparente dell'intera infrastruttura tecnologica;
• ridurre i rischi operativi e di disastro del 50%;
• ottimizzare i costi attraverso la virtualizzazione, il riuso degli asset e il modello BCS attivo;
• migliorare continuamente la qualità dei servizi erogati attraverso processi strutturati di auditing e CSI;
• preservare il patrimonio di conoscenze attraverso un piano strutturato di knowledge management e trasferimento del know-how.

La soluzione si è dimostrata scalabile, sostenibile e pienamente integrata con il contesto organizzativo e tecnologico dell'Ente: un modello replicabile per altre Amministrazioni Pubbliche di analoghe dimensioni e complessità — ne parliamo nella pagina dedicata alla PA locale, mentre il nostro approccio a misura, analisi e miglioramento continuo è raccontato nel metodo. Se la tua organizzazione sta affrontando una transizione simile — governance da costruire, continuità da mettere a norma, servizi che crescono più in fretta della capacità di gestirli — parliamone.

Per riservatezza non citiamo l'Ente; dati e indicatori si riferiscono al periodo di erogazione del servizio.