Progetto "Razionalizzazione delle infrastrutture IT" - Documento di Strategy - ATS ...
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Progetto «Razionalizzazione delle infrastrutture IT» Documento di Strategy
Indice
1 INTRODUZIONE ....................................................................................................................... 4
1.1 Metodologia di lavoro ...................................................................................................... 5
1.2 Facility ............................................................................................................................ 6
1.3 Infrastruttura................................................................................................................... 7
1.4 Servizi applicativi ............................................................................................................. 7
1.5 Service management ........................................................................................................ 8
1.6 Livelli di servizio ............................................................................................................... 8
1.7 Risorse umane ................................................................................................................. 8
2 Evoluzione tecnologica ............................................................................................................. 9
2.1 Cloud strategy ................................................................................................................. 9
2.1.1 Vantaggi e svantaggi delle tre soluzioni di cloud. .......................................................... 12
2.1.2 Modalità standard di collegamenti tra il Data Center in Cloud e la rete ATS Sardegna ........ 14
2.1.3 Interventi proposti per indirizzare la cloud strategy ...................................................... 15
2.1.4 Soluzioni Iperconvergenti.......................................................................................... 16
2.2 Applicativi ..................................................................................................................... 17
2.2.1 Consolidamento applicativi e dati............................................................................... 17
2.3 Facility .......................................................................................................................... 18
2.3.1 Consolidamento DC.................................................................................................. 19
2.3.1.1 Sassari ................................................................................................................ 30
2.3.1.2 Olbia................................................................................................................... 30
2.3.1.3 Nuoro ................................................................................................................. 31
2.3.1.4 Lanusei ............................................................................................................... 31
2.3.1.5 Oristano .............................................................................................................. 32
2.3.1.6 Sanluri ................................................................................................................ 32
2.3.1.7 Carbonia ............................................................................................................. 33
2.3.1.8 Cagliari................................................................................................................ 33
2.3.2 Migrazione ............................................................................................................. 34
2.4 Infrastruttura................................................................................................................. 36
2.4.1 Aggiornamento tecnologico hardware per i data center principali e DR ........................... 36
2.4.2 Sistemi integrati ...................................................................................................... 36
2.4.3 Infrastrutture convergenti......................................................................................... 37
2.4.4 Infrastrutture iperconvergenti ................................................................................... 37
2.4.5 Aggiornamento software (sistemi operativi e hypervisor) .............................................. 38
2.4.6 Adeguamento rete................................................................................................... 39
2.4.7 Sostituzione apparati obsoleti.................................................................................... 39
2.4.8 Adeguamento della banda disponibile ........................................................................ 40
3 Eccellenza operativa .............................................................................................................. 41
3.1 Service management ...................................................................................................... 41
3.1.1 Introduzione DCIM................................................................................................... 42
3.1.2 CMDB .................................................................................................................... 43
3.1.3 Adozione di un sistema di gestione e monitoraggio dell’infrastruttura ............................. 44
3.1.4 Service Desk e Ticketing ............................................................................................ 46
3.1.5 Implementazione di un Service Desk........................................................................... 46
3.1.6 Relazioni con altri processi ........................................................................................ 48
3.1.7 Capacity planning .................................................................................................... 48
3.1.8 License Management ............................................................................................... 49
3.1.9 Definizione degli SLA ................................................................................................ 50
3.2 Evoluzione delle Competenze .......................................................................................... 51
3.2.1 Ridefinizione dei ruoli del personale operativo ............................................................. 51
3.2.2 Esternalizzazione delle attività di basso livello legate all’informatica distribuita ................ 51
3.2.3 Nuova organizzazione delle attività interne ................................................................. 51
3.2.4 Evoluzione delle competenze .................................................................................... 51
3.2.4.1 Cloud management .............................................................................................. 52
3.2.4.2 ITSM/ITIL............................................................................................................. 52
4 Piano di lavoro 2019-2021 ...................................................................................................... 54
1 INTRODUZIONE
Nell’arco dei mesi di ottobre e novembre 2018 è stato effettuato un assessment sulle infrastrutture, sulle
tecnologie e sui processi di gestione IT delle otto ASSL che sono confluite in ATS Sardegna, con l’obiettivo di
definire una strategia evolutiva congruente sulla base delle criticità rilevate e da sanare, in accordo con il
piano triennale definito. L’attività di assessment è stata eseguita coinvolgendo il personale di riferimento per
ognuna delle 8 facility e realizzata tramite questionari, interviste e sopralluoghi, suddivisi nei vari ambiti:
Facility, valutazione sui locali in cui risiedono le componenti hardware, sulla loro capacità di
sostenere il funzionamento degli apparati in termini di potenza elettrica, raffreddamento, spazio e
sicurezza fisica.
Infrastruttura, valutazione su network layout, circuiti di collegamento e banda disponibile e
identificazione delle caratteristiche di componenti hardware quali server, storage, switch, router e
firewall e software (VM). Valutazione sull’occupazione e monitoraggio delle risorse e sulle soluzioni
di disaster recovery.
Servizi Applicativi, valutazione sugli applicativi presenti in ogni ASSL e ricostruzione dello stack
tecnologico attraverso la mappatura dell’infrastruttura sottostante e identificazione delle
sovrapposizioni funzionali in ottica di consolidamento.
Service Management, analisi dei ticket aperti per incidenti e anomalie, riguardanti infrastruttura e
facility. Valutazione sul livello di maturità e sulla dislocazione degli uffici e sui contratti di gestione e
manutenzione.
Livelli di servizio richiesto, analisi sui livelli di servizio minimi da garantire per i servizi erogati dai
data center, sulle linee guida, regolamenti e normative di rilievo per la gestione e manutenzione dei
data center e su vincoli e requisiti per l’utilizzo delle applicazioni.
Risorse umane, valutazione sul numero di persone interne presenti in ogni ASSL che si occupano di
infrastruttura IT e i loro compiti.
Le rilevazioni effettuate durante la fase di assessment sono state descritte e catalogate nel documento
Assessment Progetto ATS Sardegna.docx
Nel presente documento, a fronte delle evidenze emerse nell’assessment, riassunte di seguito, vengono
delineate le possibili strategie di evoluzione per i data center ed i servizi ICT dell’Azienda di Tutela della
Salute della Regione Autonoma della Sardegna.
I tre stream principali su cui si basano le iniziative strategiche sono i seguenti:
Evoluzione dell’infrastruttura verso il Cloud, attraverso la considerazione di tre scenari di
migrazione:
Migrazione parziale di alcuni applicativi in funzione della loro cloud-readiness;
Migrazione parziale in funzione della conclusione di precedenti accordi contrattuali;
Definizione di un piano massivo di migrazione da adottare in un momento successivo rispetto
alla razionalizzazione dei CED.
Delineando poi una cloud strategy ad hoc per le necessità dell’azienda e sulla base della situazione attuale.
Consolidamento Data Center, attraverso la valutazione delle facility in ambito sulla base di:
Adeguatezza dei locali e forniture accessorie;
Sistemi di sicurezza installati e misure di mitigazione dei rischi;
Esposizione a rischi ambientali;
Spazio fisico disponibile ed espandibilità;
Dislocazione geografica;
Volumi gestiti.
Individuando i due data center principali in cui confluiranno i servizi dell’ATS e il terzo data center che avrà
la funzione di disaster recovery e che si attiverà nel momento in cui uno dei due principali avrà problemi nel
regolare svolgimento delle proprie attività.
Evoluzione dell’IT verso l’Eccellenza operativa, attraverso l’analisi dei processi e delle metodologie
di service management. Indicando i passi da seguire e gli strumenti da adottare per raggiungerla e
svolgere in questo modo il lavoro nella maniera più adeguata possibile in base agli standard.
1.1 Metodologia di lavoro
Per la stesura del documento di strategy, è stata preso in considerazione un framework basato sugli
elementi descritti nel seguente diagramma, tale framework è frutto dell’esperienza di Bip consolidata negli
anni in progetti di definizione di IT strategy condotti in diverse industries. Il framework si allinea alla
strategia aziendale ed è costituito da componenti di strategia ed abilitatori. I primi aiuteranno l’IT a
raggiungere gli obiettivi mentre gli abilitatori forniranno supporto alla governance e allo sviluppo delle
competenze necessarie per garantire che gli obiettivi finali siano raggiunti.
La componente strategica si divide in:
Service Strategy: fornire servizi migliori e conveniente per azienda e clienti;
Information/Data Strategy: mantenere l’integrità, la disponibilità e l’accuratezza dei dati aziendali
nei processi aziendali;
Platform/Application Strategy: offrire le funzionalità aziendali richieste con un TCO inferiore, una
facile manutenzione e tempi di consegna ridotti;
Infrastructure Strategy: fornire un ambiente ad alte prestazioni, affidabile, efficiente
energeticamente ed economicamente per gestire i servizi IT;
Security Strategy: proteggere la riservatezza, l’integrità e la disponibilità delle informazioni
stabilendo controlli fisici e logici;
Sourcing Strategy: procurare i servizi con la giusta qualità, al giusto prezzo e con i giusti controlli.
Gli abilitatori sono invece:
Governance: processi, strutture e meccanismi per controllare e gestire la strategia e assicurare la
realizzazione degli obiettivi strategici IT;
Operating Model: allineamento funzionale delle strutture aziendali e IT e dei gruppi di fornitori;
Architecture: processo aziendale e mappa tecnologica per consentire un’erogazione efficace dei
cambiamenti, la continuità operativa e il processo strategico decisionale;
Processes: quadri e modelli di settore (come l’ITIL per la fornitura di servizi) per garantire consegne
coerenti, rilavorazioni ridotte e maggiore produttività;
Skills and Capabilities: esperienza e competenza nell’allineamento dell’IT con il business, gestione
del rapporto commerciale, comprensione della strategia e dei piani aziendali, fornitura di soluzioni
e servizi e miglioramento continuo.
Figura 1 - Framework per la definizione della strategy
L’output della fase di IT Strategy si compone del presente documento Word, che presenta inizialmente le
principali evidenze dell’analisi di assessment e si articola, successivamente, nelle due fasi di evoluzione:
tecnologica: attraverso cloud strategy e consolidamento dei data center
eccellenza operativa: attraverso introduzione di strumenti di monitoraggio ed evoluzione delle competenze
per il personale interno ad ATS.
Di seguito le principali evidenze dell’analisi di assessment divise negli ambiti di interesse.
1.2 Facility
Per l’analisi delle facility in ambito sono state valutate l’adeguatezza dei locali e delle forniture accessorie, i
sistemi di sicurezza installati e le misure di mitigazione dei rischi, l’esposizione a rischi ambientali, lo spazio
fisico disponibile e l’espandibilità, la dislocazione geografica e i volumi gestiti. Da tale analisi risulta che solo
le facility di Cagliari e Sassari presentano le caratteristiche adeguate ad assolvere le funzionalità minime per
accogliere il consolidamento dei data center, disponendo di tutti i sistemi di sicurezza fisica, tra cui
antincendio, antiallagamento, videosorveglianza e gestione accessi fisici tramite badge, sufficiente spazio
fisico e capacità elettrica disponibile per eventuali espansioni, locali suddivisi in TLC, DC principale e DR, e
sono inoltre dimensionate per indirizzare una buona scalabilità futura.
In subordine i data center di Olbia e Lanusei possono essere adeguabili con investimenti contenuti, mentre i
data center di Nuoro, Oristano, Sanluri e Carbonia si trovano nelle condizioni meno adeguate a
intraprendere iniziative di evoluzione.
Le maggiori criticità rilevate nella fase di assessment riguardante le facility, si concentrano su una diffusa
obsolescenza tecnologica, sia per l’hardware che per l’hypervisor di riferimento sui server. Soluzioni di
Disaster Recovery, quando presenti, sono implementate parzialmente e i locali adibiti sono distanti dal data
center principale in modo non sufficiente. È stata rilevata inoltre una mancata definizione dei livelli di
servizio, per i servizi erogati in tutte le ASSL, al di fuori di Olbia dove sono comunque definiti in modo
parziale e incompleto. Inoltre, i processi di governance e service management risultano in generale assenti
o parziali.
1.3 Infrastruttura
Le soluzioni adottate sono implementate in modo estremamente eterogeneo tra le varie ASSL, e non sono
presenti soluzioni convergenti che avrebbero il vantaggio di ottimizzare l’utilizzo delle risorse grazie alla
maggiore modularità e alla virtualizzazione delle componenti di elaborazione e storage.
Dai rilevamenti effettuati sull’infrastruttura emergono le seguenti principali criticità:
L’hardware presente è obsoleto nella quasi totalità dei casi, come anche circa un terzo dei sistemi
operativi impiegati. La situazione è la stessa anche per le piattaforme di virtualizzazione.
Per quanto riguarda il Disaster Recovery, tutte le implementazioni sono parziali e incomplete,
presentano lacune in ambito di procedure e test di funzionamento e non sono conformi alle best
practice di settore.
Esistono alcune implementazioni per sistemi di IT service management e monitoraggio, non sono
in alcun modo omogenee e coprono solo poche aree critiche. Non risulta presidiata in particolare
l’area di log management che è prevista delle normative vigenti.
1.4 Servizi applicativi
Le ex-ASL impiegano in parte gli stessi applicativi di base, ciò nonostante le implementazioni e le
customizzazioni non sono sempre omogenee, anche i metodi di codifica dei dati non sono normalizzati tra
le diverse istanze. Sono inoltre presenti soluzioni applicative diverse, adottate dalle diverse ASSL, per
supportare la stessa funzione, in questi casi di sovrapposizione funzionale dovrà essere valutata
puntualmente la soluzione sulla quale convergere.
Alcune delle possibili criticità da gestire per questi casi, sono tipicamente:
strutture dati da dover normalizzare;
anagrafiche duplicate;
presenza di indici ed identificativi non congruenti fra le diverse istanze di uno stesso applicativo.
Tale situazione determina quindi la necessità di analisi più approfondite per poter eseguire il
consolidamento.
1.5 Service management I sistemi di help desk e ticketing, ove presenti, sono utilizzati direttamente solo da poche ASSL e dedicati alle aree applicative/end user, mentre nella maggior parte dei casi sono affidati in outsourcing, soprattutto per quanto riguarda la gestione delle componenti critiche dei data center. Si evidenzia la generale scarsa maturità nell’ adozione di processi ITSM, come il change management e la gestione dei problem/incident, l’assenza di uno strumento centralizzato di catalogazione di tutto l’asset IT in maniera strutturata (CMDB) e di sistemi di monitoring. Dalle rilevazioni effettuate è stata data evidenza che nei data center delle otto ASSL, le informazioni sull’infrastruttura non siano centralizzate, non sia presente uno strumento di tipo ITSM, informazioni sulla catalogazione delle istanze OS e virtual machine in funzione, sono gestite in modo locale sulla console degli strumenti, come ad esempio gli strumenti della suite VMWare, oppure sparse su fogli excel o conosciute solo da pochi addetti ai lavori. Tutto questo porta a difficoltà generali nella gestione del data center stesso e scarsa tempestività, dovuta a lavoro in più da svolgere per riuscire a raccogliere le informazioni necessarie, ad esempio per la stesura di piani di capacity o di troubleshooting durante problemi e incidenti IT.. L’importanza di avere uno strumento che gestisca centralmente tutte queste informazioni è determinata dalla possibilità di abilitare una serie di practices di rilievo come ad esempio gli studi sul capacity, sull’obsolescenza, il consolidamento e l’ottimizzazione. 1.6 Livelli di servizio In questo ambito sono stati valutati requisiti sui livelli di servizio (Service Level Agreement SLA) per i servizi erogati dai data center, la presenza di linee guida, regolamenti o normative per la gestione e manutenzione dei data center ed eventuali vincoli e requisiti generali per l’utilizzo delle applicazioni. Esempi di livelli di servizio tipici di un data center sono la service availability tipicamente valutata in percentuale su un arco di tempo annuale, i tempi di risoluzione di incidenti e i volumi per la gestione delle richieste. Solo in alcuni casi è stato riscontrato che i livelli di servizio sono in fase di definizione o parzialmente definiti, per il resto sono stati dichiarati totalmente assenti. La definizione di KPI ed il monitoraggio infrastrutturale volto alla raccolta delle metriche per il calcolo degli indicatori in grado di descrivere e tenere sotto controllo la qualità dei servizi erogati, è cruciale per la gestione dei data center e per mantenere la continuità operativa ad un livello congruo con le aspettative degli utenti, fornendo il minor numero di ore di inattività all’anno causate da interruzioni non previste e non gestite in maniera adeguata. 1.7 Risorse umane Da quanto emerge dalle interviste con i referenti, e per le informazioni relative al perimetro di attività svolte, il personale interno dedicato ad attività inerenti ai sistemi informativi presente nelle diverse ASSL, non è dimensionato per poter svolgere tutti i compiti richiesti per la gestione dei data center: nella maggior parte dei casi si ricorre a società esterne che forniscono le competenze più specializzate e gestiscono di fatto le attività critiche nel data center. Le risorse interne sono impiegate infatti prevalentemente nel supporto all’informatica distribuita, non sono state fornite evidenze dell’esistenza di una solida struttura di governance sui fornitori coinvolti operata dalle risorse interne. Un’ ulteriore criticità relativa ai volumi ridotti dello staff
interno, emersa durante gli incontri con il DGL di ATS Sardegna, riguarda il fatto che nel 2019 è prevista
un’ulteriore diminuzione del personale per il taglio dei contratti a termine.
La scarsa maturità dell’impianto di governance sui collaboratori esterni, operato da risorse interne alla
struttura di ATS Sardegna, può determinare il rischio di lock-in verso i fornitori, e ostacola una adeguata
visione d’insieme delle attività e dei servizi basati nel DC. Per questo è fondamentale un’evoluzione delle
competenze e successiva riorganizzazione delle attività del personale interno.
2 Evoluzione tecnologica
Gli obiettivi principali che si intende perseguire con l’evoluzione tecnologica, sono riassunti nei seguenti
punti:
Aumento di performance e agilità: adottare soluzioni innovative per agevolare l’operatività interna,
essere pronti per evoluzioni future e cogliere le nuove opportunità offerte dal mercato (es. cloud,
iperconvergenza)
Ottimizzazione e semplificazione: attraverso il consolidamento e la riduzione delle componenti
ridondanti, si intende semplificare l’infrastruttura ottimizzando l’effort per la gestione.
Mitigazione dei rischi e continuità di servizio: indirizzando la trasformazione delle attività di service
management ed il refresh delle tecnologie obsolete
A seguito dell’analisi condotta sulle evidenze dell’assessment e sui gap da colmare per il raggiungimento degli
obiettivi prefissati, emerge principalmente l’elevato grado di obsolescenza sia per l’hardware che per il
software di base (S.O., hypervisor). È necessario intervenire su più livelli per garantire che l’operatività dei
sistemi sia adeguata alle esigenze attuali e future in termini evolutivi.
Gli interventi proposti in questo documento di strategy, su cui si basa l’evoluzione tecnologica, saranno
focalizzati su diversi ambiti, il cloud, gli applicativi, le facility e l’infrastruttura. Per ognuno di questi ambiti è
stato valutato un set di interventi volto al raggiungimento degli obiettivi prefissati.
2.1 Cloud strategy
La cloud strategy proposta in questo paragrafo, dovrà essere sviluppata in armonia con un modello evolutivo
basato sull’analisi delle applicazioni esistenti e della loro distribuzione all’interno dei data center delle otto
ex-ASL.
La proposta per la migrazione delle applicazioni verso il cloud, si basa sulla valutazione del grado di maturità
tecnologica, standardizzazione e portabilità verso il cloud. Tale indicazione è riassunta con il termine cloud-
readiness.
La modalità di evoluzione delle infrastrutture verso il cloud è stata valutata considerando i driver contenuti
nel Piano Triennale di Sviluppo del Sistema Informativo:
migrazione parziale di alcuni applicativi in funzione della loro cloud-readiness;
migrazione parziale in funzione della conclusione di precedenti accordi contrattuali;
definizione di un piano massivo di migrazione da adottare in un momento successivo rispetto alla
razionalizzazione del CED;
In considerazione dei punti precedenti e dello stato attuale delle infrastrutture e dei processi, risultante
dall’assessment eseguito, si ritiene opportuno eseguire una migrazione parziale su cloud di alcuni
applicativi valutata verticalmente sulla base della loro cloud-readiness, come evidenziato nella tabella
seguente:
SCENARIO DI PRO CONTRO
MIGRAZIONE
a) Migrazione parziale in Risultati c onc reti ottenibili Approc c io parziale, ulteriori
funzione della c loud- c on uno sforzo ridotto, v alutazioni da effettuare in
readiness impatti e risc hi c ontenuti un sec ondo momento
b) Migrazione parziale in Risultati c onc reti ottenibili Approc c io parziale, molto
funzione della c onc lusione c on uno sforzo ridotto, dipendente dal v endor,
di ac c ordi c ontrattuali soluzioni garantite dal potenziale risc hio sui tempi
v endor di negoziazione c ontrattuale
c ) Definizione di un piano Approc c io c ompleto, Effort e risc hi elev ati,
massiv o suc c essivo alla soluzione strategic a impossibilità di fare sinergia
razionalizzazione del CED c onsolidata v erso una unic a c on il c onsolidamento DC
piattaforma c loud
La cloud-readiness degli applicativi nel perimetro di analisi è stata individuata principalmente secondo le
metriche di basso profilo di rischio per la migrazione in cloud (in considerazione del contesto di un’ azienda
sanitaria), contenimento dei costi di replatforming e inizio di un percorso di migrazione verso il cloud,
dando priorità agli applicativi in ambito anatomia patologica, rianimazione e radiologia, in linea con i
requisiti raccolti.
Le applicazioni identificate sono state analizzate secondo i criteri riportati nel grafico seguente, su ciascun
criterio è stato attribuito un punteggio che determina la readiness (1 = più bassa; 5 = più alta) sulla base
delle informazioni a disposizione.
Per gli applicativi individuati, attualmente erogati dalle facility delle ex-ASL, sarà necessario formulare un
piano specifico che tenga conto dei seguenti aspetti:
Consolidamento istanze delle diverse ex-ASL e normalizzazione dati; Adeguamento livello di cloud-readiness;
Valutazione esigenze di continuity;
Valutazione dipendenze e flussi di integrazione dati con altri applicativi.
La Cloud strategy dovrà individuare principalmente la tipologia di cloud da adottare in base all’area di
applicazioni/sistemi da migrare.
Cloud Privato: i servizi sono erogati dall’azienda stessa, o da un provider esterno, unicamente
all’azienda stessa ed alle sue diverse unità. Implementato tramite virtualizzazione ed
orchestrazione (Software Defined Data Center), tipicamente single tenant; Questo tipo di servizio è
tipicamente impiegato in ambiti in cui sono presenti particolari vincoli imposti da normative, policy
o regolamenti che impediscono l’utilizzo di piattaforme multi-tenant, oppure in casi in cui
potrebbero emergere potenziali problemi di performance.
Cloud Pubblico: i servizi sono erogati a più clienti attraverso la rete Internet o link dedicato, da un
service provider che possiede e gestisce l’infrastruttura, e la piattaforma cloud, tipicamente multi
tenant (segregazione logica delle risorse); Questo tipo di servizio è largamente impiegato e
consente di sgravare tutto l’onere interno di gestione e manutenzione sull’infrastruttura.
Cloud Ibrido: i servizi sono costruiti su infrastrutture ibride che utilizzano la modalità privata per
alcuni aspetti (ad esempio la conservazione dei dati) e la modalità pubblica per altri (ad esempio le
interfacce di accesso);
All’interno delle convenzioni Consip (servizi Infrastrutturali: servizi cloud IaaS, PaaS e SaaS) è presente il
fornitore RTI (costituito dal consorzio TIM, HPE, Poste) che dispone di un paniere di servizi cloud basate nei
data center di TIM, e su tecnologia HPE Helion OpenStack®. Sono offerti oltre che un set di servizi SaaS,
anche una gamma di servizi standard di tipo IaaS e PaaS.
Infrastructure as a Service (IaaS):
Virtual Machine;
Virtual Data Center;
Sistema operativo;
Storage prestazionali;
Protezione avanzata;
Virtual Network;
Virtual Storage;
Backup as a Service.
Platform as a Service (PaaS):
LAMP, WAMP, WIMP;
JBoss;
Oracle Weblogic;
MySQL, PostgreSQL, SQL server 2014;
Oracle DBMS Enterprise and Standard edition;
Pandora FMS, ZABBIX (monitoring).
I punti di forza di tale soluzione sono la possibilità di attivare i servizi disponibili in modo rapido, servizi
standard comunemente utilizzati, connessione alla rete SPC e i nuovi servizi in rilascio come Disaster
Recovery as a Service e Managed/ManagedH24 services.I cloud providers considerati nelle nostre analisi, oltre al fornitore della community cloud CONSIP SPC, sono
il public cloud Azure di Microsoft e AWS di Amazon.
Azure di Microsoft presenta diverse caratteristiche come la presenza di diffusi servizi SaaS, è acquistabile
attraverso la convenzione CONSIP EA4, ha conformità dichiarata con il GDPR e presenta diverse
implementazioni in ambito PA.
AWS di Amazon invece presenta caratteristiche come un’ampia gamma di servizi, è leader nei servizi IaaS,
ha conformità dichiarata con le direttive europee GDPR e presenta anch’esso diverse implementazioni in
ambito PA.
2.1.1 Vantaggi e svantaggi delle tre soluzioni di cloud.
La soluzione SPC cloud del consorzio RTI ha fra i diversi vantaggi il fatto di essere presente nella
convenzione CONSIP CLOUD, è stata realizzata sulla base delle specifiche caratteristiche della PA italiana, è
disponibile su connettività SPC, dispone di servizi PaaS di tipo JBoss e Oracle ed è presente nella community
cloud. Tra gli svantaggi si evidenzia che i servizi sono di tipo unmanaged, ovvero il provisioning ed le attività
di gestione sono a carico dell’acquirente.
La soluzione microsoft Azure ha come vantaggi il fatto di essere presente nella convenzione CONSIP EA4,
dispone di Azure App Service da utilizzare con Jboss come AS e dispone di diverse soluzione per
implementare la scalabilità dinamica. Fra gli svantaggi si evidenzia l’indisponibilità di Oracle all’interno
dell’offerta managed DB, necessita dell’installazione del server DB (IaaS) e l’acquisto delle licenze Oracle,
non disponibile di connettività standard su rete SPC.
La soluzione AWS di Amazon ha come vantaggi la disponibilità di managed DB Oracle e una scalabilità
dinamica. Fra gli svantaggi si evidenzia l’assenza di servizi standard di connettività SPC, non è supportata
JBoss PaaS out of the box, presenta un costo elevato e non è attualmente acquistabile in convenzione
CONSIP.
Nelle tabelle seguenti sono evidenziati alcuni costi standard per il provisioning di servizi sulle piattaforma
cloud analizzate.
SOLUZIONE RTI Cloud SPC Opex
Area Componente Informazioni Costo Sconto
(Eur/mese (Eur/mese
) )
Offerta PaaS PaaS-Base (JBOSS) CPU [1vCPU]; 28,84 2,88
RAM[4GB]; HD[20GB]
VCPU aggiuntive (2vCPU) 25,61 2,56
VRAM aggiuntive (1 GB) 7,60 0,76
Vstorage aggiuntivo (10 GB) 16,10 1,61
PaaS-Base (oracle dbms Standard CPU [2vCPU]; 239,68 23.97
ed.) RAM[12GB];
HD[20GB]
VCPU aggiuntive (1vCPU) 0,00 23,97
VRAM aggiuntive (1 GB) 5,70 0,57
Vstorage aggiuntivo (10 GB) 33,60 3,36
Licensing Rh 7 Support Incluso in offerta 0,00 0,00
PaaSRh JBOSS Incluso in offerta 0,00 0,00
PaaS
Oracle Linux Support Incluso in offerta 0,00 0,00
PaaS
Oracle Standard Edition Incluso in offerta 0,00 0,00
PaaS
Connettività VN base-IP [1 slot di 16 IP costo disponibilità IP, 2,08 0,21
pubblici/privati] servizi ntw, VPN
Connettività utenti --> REMS via VPN su Internet 0,00 0,00
REMS--> Applicazioni DC CdM via VPN su Internet 0,00 0,00
Backup BaaS Small - fino a 5GB di spazio di primo scaglione 0,89 0,00
archiviazione
BaaS Medium - da 6 GB a 50GB di secondo scaglione 1,27 0,00
spazio di archiviazione
BaaS Large - da 51 GB a 500 GB di terzo scaglione 0,00 0,00
spazio di archiviazione
Servizi Costo Gestione applicativa 2 gg/mese 600,00 0,00
(correttiva non evolutiva)
(Engineering)
Gestione sistemistica (DB) (Personale 1 gg/mese 155,00 0,00
interno)
Costo monitoraggio (Personale 1 gg/mese 155,00 0,00
interno)
SOLUZIONE AZURE Opex
Area Componente Informazioni Costo Sconto
(Eur/mese (Eur/mese
) )
Offerta PaaS App Service (Standard) Tipo istanza s3 (4 core, 7GB 250,97 85,33
RAM, 50GB DISK) Utilizzo
WebApp Service
Offerta IaaS DB Server (Azure E2 v3 CPU [2vCPU], RAM [16GB], 100,39 0,00
machine type) HD [30GB] (temporary)
Standard Managed Disks (S20) 512GB 18,36 0,00
Licensing Licenze SO e supporto incluso in prezzo PaaS 0,00 0,00
(Application layer)
Licenze Applicativi (Application incluso in prezzo PaaS 0,00 0,00
layer)
Licenze SO e supporto (DB Oracle linux Support 87,00 0,00
layer) subscription
Licenze Oracle (DB layer) Supporto updates + licenza 272,67 0,00
d'uso (14 875 EUR)
Connettività VPN gateway Basic 100 Mbps, Max 10 S2S 22,59 0,00
connectionOutbound datato on premises Connettività via Internet 0,00 0,00
DC (5GB/month free) No linea dedicata (Azure
€0,074 per GB per dati da 5GB Express Route)
a 10TB
Connettività Utenti -->REMS
REMS--> Applicazioni
Backup Backup DB Performed on standard 0,00 0,00
managed disk
Servizi Azure Support Plan Standard Microsoft 252,99 86,02
Costo Gestione Applicativa 600,00 0,00
Gestione sistemistica (DB) Personale interno 155,00 0,00
Costo monitoraggio Personale Interno 155,00 0,00
SOLUZIONE AWS Opex
Area Componente Informazioni Costo Sconto
(Eur/mese (Eur/mese
) )
Offerta PaaS AWS Elastic Beanstalk Necessaria AMI custom 0,00 0,00
per gestire JBOSS
AWS EC2 (istanza riservata, 1 m4.xlarge (4vCPU, 16 GB 153,98 0,00
anno) RAM)
Storage EBS 250 GB 0,00 0,00
Amazon RDS Oracle SE2 (license db.r3.large (2vCPU, 15 489,97 0,00
included) istanza riservata GB RAM)
Storage per DB 500 GB 53,81 0,00
Licensing Supporto SO (Red Hat Enterprise 56,43 0,00
Linux Server, Standard)
Licenze applicativi Red Hat Jboss Enterprise 564,97 0,00
Application Platform
Licenze DB Incluso in DB PaaS offer 0,00 0,00
Connettività AWS VPC service 31,02 0,00
Dati da Internet (VPN) verso l'AS Connettività via Internet 1,07 0,00
di 5GB/mese (gratis) + dati AS No linea dedicata (AWS
verso Direct Connect)
Internet (VPN) di 5GB/mese
Connettività Utenti --> REMS
REMS --> Applicazioni
Backup Backup DB Incluso in servizio RDS 0,00 0,00
Servizi Amazon Support (Business) 84,75 0,00
Costo Gestione Applicativa 300,00 0,00
Costo monitoraggio Personale interno 155,00 0,00
2.1.2 Modalità standard di collegamenti tra il Data Center in Cloud e la rete ATS Sardegna
VPN IPSEc mediante rete pubblica InternetPermette una connessione crittografata attraverso la rete pubblica Internet tramite proprie infrastrutture Internet/VPN/Firewall disponibili nel Cloud Data Center e dell’ATS Sardegna. Internet è una rete pubblica di conseguenza non sono garantiti SLA End to End e non sono garantiti parametri di rete quali (packet loss, latenza e Jitter) che potrebbero impattare le applicazioni. Connettività mediante rete privata Permette una connessione mediante rete privata fornita da carrier di telecomunicazioni (esempio punto- punto) tra il Cloud Data Center e ATS Sardegna. In questo caso sono garantiti SLA e sono garantiti parametri di rete quali (packet loss, latenza e Jitter). Caratteristiche principali delle due tipologie di collegamento: Nella soluzione con VPN IPSEc over Internet ci sono costi bassi ma non è presenta la garanzia della qualità del servizio End to End e dei parametri della rete. Nella soluzione con connettività mediante rete privata è presente, invece, la garanzia della qualità del servizio e dei parametri della rete ma i costi sono elevati. 2.1.3 Interventi proposti per indirizzare la cloud strategy La tipologia di cloud ritenuta più adatta per ATS Sardegna, sulla base dei razionali costituit i da necessità di ottimizzazione di effort di gestione e tempi per l’implementazione, è basata su una soluzione cloud pubblica disponibile in convenzione CONSIP, quindi come descritto in precedenza costituita da una piattaforma multi-tenant, accessibile attraverso la rete Internet oppure mediante la rete dell’amministrazione pubblica. Tale indicazione strategica è da considerare come linea guida all’interno dello sviluppo delle iniziative proposte e da approfondire durante la fase di fattibilità. I servizi disponibili in Lotto 1 della convenzione CONSIP, sono finalizzati ad incentivare il consolidamento dei data center delle Pubbliche Amministrazioni attraverso l’utilizzo di servizi abilitanti come la fruizione di risorse software e hardware attraverso la logica del Cloud Computing. Tali risorse sono rese disponibili grazie a infrastrutture fisiche centralizzate basate su un modello di condivisione tra le PA di tipo “Community Cloud”. Tali servizi sono di tipo IaaS, PaaS e SaaS, come già accennato, che sono erogati presso i Centri Servizi del Fornitore, in aggiunta ci sono servizi di Cloud Enabling, ovvero servizi professionali, che sono presenti nelle strutture dell’Amministrazione in modalità on premise. Essi hanno la funzione di supporto per le attività progettuali di virtualizzazione di infrastrutture delle Pubbliche Amministrazioni. Sono disponibili diversi servizi di Cloud Computing in ambito IT security, realizzazione di portali, servizi online e di cooperazione applicativa per la Pubblica Amministrazione. Fra i più importanti si evidenziano i servizi per la gestione delle identità digitali erogati in modalità as a service, i servizi di firma digitale remota che presenta anche la fornitura di certificati e di timbro elettronico anch’essi erogati in moda lità as a service e che hanno il compito di digitalizzare i processi amministrativi. Sono presenti poi i servizi di sicurezza erogati sia in modalità as a service che on premise, destinati a garantire la sicurezza applicativa e a sostenere le Amministrazioni nella gestione e prevenzioni di incidenti di natura informatica e nell’analisi delle vulnerabilità dei sistemi informativi. Infine, i servizi professionali, come supporto per effettuare attività nell’ambito della sicurezza applicativa, unitamente alle attività dei servizi di monitoraggio. Gli interventi proposti sullo stream Evoluzione sul cloud sono i seguenti:
Consolidamento applicativi per il cloud: in questa fase avverrà l’eliminazione dei server e delle
infrastrutture ridondanti, afferenti agli stessi applicativi e localizzati in diverse facility e ci sarà il
trasferimento e la normalizzazione dei dati per ogni applicativo soggetto al consolidamento sul
cloud;
Cloud Readiness: in questa fase ci sarà l’evoluzione degli applicativi ad uno stato cloud-ready sulla
base delle caratteristiche evidenziate in precedenza;
Cloud Procurement: qui ci sarà l’individuazione e l’abilitazione dei servizi cloud adeguati alle
esigenze di supporto ai servizi applicativi;
Cloud migration: avverrà la migrazione dei servizi applicativi selezionati e delle relative
componenti, su servizi cloud di tipo IaaS.
2.1.4 Soluzioni Iperconvergenti
L’iperconvergenza è un approccio che fornisce un ambiente virtualizzato completo senza richiedere
all’utente un impegno a livello di configurazione. L’infrastruttura IT viene incentrata su un’architettura
software in cui convergono risorse di calcolo, di memorizzazione, di networking e di virtualizzazione e il
tutto è reso disponibile su un sistema hardware supportato da un provider.
Differenze tra soluzioni tradizionali, convergenti e iperconvergenti.
Nella soluzione tradizionale, l’infrastruttura è costituita da componenti individuali: storage separato, server,
apparati di rete e appliance per il backup e ogni unità deve essere configurata individualmente. Per la
gestione e per la definizione della compatibilità dei componenti è necessario un team di esperti, per ogni
campo. Comunemente i componenti sono di fornitori differenti per cui la tipologia di garanzia e di supporto
può variare.
Nella soluzione convergente i server applicativi, gli storage e gli apparati di rete sono venduti come una
soluzione chiavi in mano da un unico fornitore. Tutto il prodotto è preconfigurato per gestire un
determinato carico ma è comunque possibile modificare la configurazione per gestire i carichi di lavoro
variabili. In questa soluzione è possibile che determinate componenti più critiche siano di un altro
produttore e normalmente ogni componente deve essere gestito separatamente.
La soluzione iperconvergente presenta storage, networking e risorse computazionali (HW e SW) combinate
in una singola unità, gestita centralmente ed acquistata da un unico fornitore. Il software di orchestrazione
permette di utilizzare l’hardware e il deployment di macchine virtuali velocemente. È un software defined
data center, quindi può essere agnostico rispetto all’hardware ed è scalabile e può utilizzare commodity
hardware.
Alla base della soluzione di tipo iperconvergente c’è una nuova intelligenza del software. Il modello fa
collassare un intero data center in un nodo che viene gestito attraverso un’interfaccia utente semplice ed
intuitiva e gestita in cloud. La flessibilità e la scalabilità dell’infrastruttura iperconvergente si basano su di
uno o più nodi che si aggiungono, all’occorrenza, al sistema di base.
Le soluzioni iperconvergenti presentano vantaggi e svantaggi che si possono riassumere quanto segue.
I vantaggi si riferiscono a:
Compatibilità by design: presenta certificazioni in cui è indicato che non ci sono problemi di
compatabilità;
Facilità di deployment: il prodotto è pronto per la connessione alla rete dati e alla rete elettrica,
presenta un software di gestione di tipo Software Defined Data Center già preinstallato; No finger-pointing tra fornitori: le dinamiche di controversie tra i vari fornitori sono molto ridotte;
Scalabilità: utilizzando e aggiungendo componenti dello stesso fornitore è facilmente ottenibile;
Costi: utilizzando il commodity hardware si eliminano i costi per hardware specifico come SAN e
NAS;
Staffing IT: saving ottenibile da un minore effort necessario per la gestione.
Gli svantaggi invece si riferiscono a:
Vendor lock-in: l’utilizzo di soluzioni prodotte da un solo fornitore può causare rischi di lock-in;
Inflessibilità di configurazioni hardware: non sempre è possibile selezionare tra le configurazioni
offerte dal fornitore quella che si adatta ai carichi di lavoro effettivi (per esempio una soluzione con
elevato storage impone di acquistare anche non necessarie elevate risorse di calcolo).
2.2 Applicativi
L’analisi dell’assessment ha evidenziato che gli stessi moduli applicativi sono presenti in quasi tutti i data
center delle diverse ASSL. Ciò che differenzia un’ASSL da un’altra sono però le diverse configurazioni di uno
stesso applicativo o l’utilizzo di applicativi diversi per la stessa area di interesse. È stato rilevato inoltre che
in ogni data center è presente un rack fornito dalla Regione Autonoma della Sardegna in relazione al
progetto H.Cloud, che non è fisicamente accessibile al personale in loco, ma è gestito esternamente dal
persona della Regione. Per questo motivo questi applicativi dovranno rimanere dislocati nei vari data
center senza poter essere spostati nei due nuovi data center principali scelti per la migrazione. Anche altri
applicativi dovranno rimanere nei data center delle ASSL, a causa della mole di dati che utilizzano o perché
si riferiscono ad attività strettamente legate al luogo in cui sono dislocati. Per questi applicativi non si potrà
scegliere la migrazione verso il Cloud o lo spostamento nei due data center principali.
2.2.1 Consolidamento applicativi e dati
Per consolidamento applicativo si intende, nel contesto in cui esistono diverse istanze dello stesso
applicativo o di applicativi diversi che supportano la medesima funzione, l’azione di individuare e
convergere (utenti, processi, interfacce e dati) verso la soluzione applicativa e l’istanza da mantenere attiva
e di conseguenza dismettere le restanti istanze applicative.
Nello scenario che emerge dall’assessment effettuato, siamo in presenza di due diverse circostanze che
abilitano lo scenario di consolidamento:
1. In riferimento ad un modulo applicativo, esiste una soluzione applicativa installata su diverse
istanze presso le diverse infrastrutture delle ASSL
2. In riferimento ad un modulo applicativo, esistono diverse soluzioni applicative installate su diverse
istanze presso le diverse infrastrutture delle ASSL
In entrambe i casi è indispensabile:
- Normalizzare le codifiche dei dati tra le diverse implementazioni;
- Normalizzare le eventuali customizzazioni sulle istanze degli applicativi;
- Consolidare le basi dati;
- Formare gli utenti all’utilizzo dell’applicazione consolidata con le relative modalità di codifica dei
dati.Per ogni applicazione da consolidare è quindi necessario prevedere un impegno specifico per le fasi di
analisi e disegno della soluzione di consolidamento. Per eseguire il consolidamento, si potrà partire dalla
matrice degli applicativi e partendo da ogni modulo applicativo si farà un’analisi verticale e si individuerà la
soluzione applicativa di riferimento. Il piano di consolidamento attraverserà diverse fasi, innanzitutto ci sarà
la catalogazione degli stakeholders e delle aree organizzative interessate, poi si acquisiranno i requisiti
funzionali e di esercibilità come la valutazione della necessità di avere hardware in prossimità degli
strumenti di analisi. Ci sarà un’analisi degli impatti, valutando se è possibile fare il move creando disservizi o
se farlo in continuità e ci sarà la stesura di un piano e ingaggio delle risorse. Avverrà poi un’analisi
funzionale con individuazione di eventuali GAP della soluzione target, un’analisi e normalizzazione dei dati
e delle codifiche e un adattamento applicativo. Infine, ci sarà il trasferimento di dati e il consolidamento
delle basi di dati e la formazione degli utenti con evoluzione del know how.
Il consolidamento di applicativi e dati è estremamente importante è porta diversi benefici quali:
Il recupero e la dismissione dei sistemi inutilizzati;
La normalizzazione degli ambienti di produzione e no produzione e di disaster recovery;
La semplificazione nella gestione grazie alla riduzione dei volumi;
Il saving su licenze, manutenzione e gestione per hardware e software;
La redistribuzione dei carichi sui sistemi server;
La riduzione delle esigenze sui volumi dei dati (sia di storage che di backup).
Per ognuno degli applicativi da consolidare è necessario definire la destinazione ottimale: on premise nei
rinnovati data center di Cagliari e Sassari o in cloud. Nei casi di migrazione in cloud sono identificate le
macchine virtuali che possono essere traferite direttamente senza modifiche significative. In alcuni casi è
preferibile non migrare tutte le macchine virtuali ma trasferire in cloud alcune funzionalità applicative (ad
esempio i database) senza utilizzare istanze specifiche di server virtuali, ma accedendo ai servizi in modalità
SaaS, svincolando completamente la gestione della piattaforma di base che resta delegata al provider con
notevoli vantaggi.
Altre indicazioni specifiche non è possibile darle al momento ma è necessaria una successiva analisi
approfondita.
2.3 Facility
Con l’unificazione delle otto ex-ASL verso un unico ente regionale, si è scelto di cogliere l’opportunità di
unificare anche l’infrastruttura IT e le facility relative ai data center. valutando diverse alternative che
garantiscano l’ottimizzazione della spesa in funzione dei risultati attesi.
Tra tutti i data center analizzati, sono stati identificati quelli che possono offrire il miglior supporto per il
consolidamento delle infrastrutture attuali e per la centralizzazione dell’erogazione dei servizi applicativi e
per strutturare un sistema centrale di disaster recovery.
È necessario quindi, sulla base della configurazione proposta, definire nel dettaglio un piano di lavoro che
indichi scrupolosamente la sequenza e le fasi del processo di consolidamento dal punto di vista:
Logistico
o Indicare i servizi e i sistemi che devono essere migrati in cloud, trasferiti nei data center
selezionati o consolidati a livello applicativo Temporale
o Pianificare le date più opportune per le attività da svolgere in modo da minimizzare
l’impatto delle stesse sull’operatività dell’utenza in funzione della criticità delle singole
componenti
Economico
o Coordinare le esigenze operative, logistiche e temporali con i budget definito per il triennio
2019-2021 da allocare opportunamente in funzione delle relative disponibilità note.
2.3.1 Consolidamento DC
Abbiamo individuato lo scenario di consolidamento che prevede l’impiego di due data center principali nei
quali distribuire uniformemente gli applicativi e l’impiego di un terzo data center come sito di Disaster
Recovery.
Il consolidamento su un numero ridotto di data center ha una serie di vantaggi:
Concentrare effort ed investimenti sui data center attualmente dotati delle migliori caratteristiche
di capacità, espandibilità e soluzioni di sicurezza fisica, dismettendo le facility meno adatte che
avrebbero necessità di maggiori interventi per essere rese adeguate
Focalizzare gli interventi creando poli di aggregazione delle risorse che possono essere gestiti
centralmente e permettere di sfruttare al meglio le competenze interne per la gestione dei sistemi
Permettere di traguardare il consolidamento dei principali applicativi utilizzati trasversalmente da
tutte le ASSL in un’unica infrastruttura semplificandone l’erogazione
Degli otto data center attualmente operativi, quelli di Sassari e Cagliari risultano complessivamente i più
adeguati a supportare l’evoluzione tecnologica, sia dal punto di vista logistico che strutturale: entrambi
dispongono di spazio sufficiente ad ospitare i sistemi necessari per supportare il consolidamento dei servizi
applicativi attuali ed inoltre dispongono di capacità di erogazione di energia elettrica e di capacità di
raffreddamento ampiamente sufficienti.
Ambito Sassari Olbia Nuoro Lanusei Oristano Sanluri Carbonia Cagliari
Potenza
massima
144 30 96 50 54 60 56 120
erogabile
(kW)
Consumi
energetici Non
40 57 8 20 52 47 79
attuali forniti
(kWh)Figura 2 - Evidenza DC da sviluppare e ridimensionare Tra i rimanenti datacenter sia quello di Olbia che quello di Lanusei sono adeguati a essere impiegati come sito di Disaster Recovery: entrambi dispongono delle risorse, degli spazi e della capacità necessarie per ospitare un sistema di disaster recovery in grado di supportare i due siti principali. Gli altri data center possono essere gradualmente ridimensionati nel corso delle attività di consolidamento, valutandone l’eventuale dismissione totale considerando eventuali vincoli dovuti alla presenza di alcuni sistemi (ad esempio HS/Cloud) che non sono sotto il diretto controllo di ATS Sardegna e che dovranno pertanto rimanere operativi in attesa di una valutazione specifica. Inoltre, sono state individuate applicazioni (es. RIS/PACS) che per necessità di integrazione con sistemi che si trovino in diretta prossimità dei macchinari che gestisco, per esigenze di performance sulla latenza, e per i volumi di dati gestiti (grandi quantità di file di dimensioni rilevanti che devono essere conservati per tempi molto lunghi 10-30 anni secondo normativa) necessitano di valutazioni verticali specifiche, con il supporto del vendor, per confermare la fattibilità sulla rilocazione fisica. In questi casi verrà valutato un presidio tecnico locale, mentre, laddove non emergeranno vincoli, si procederà alla dismissione del datacenter. Il consolidamento previsto avrà la conseguenza di ridurre le necessità di effort operativo e gestionale dei data center che non saranno impiegati come poli principali, rendendo possibile la riallocazione di una parte delle rispettive risorse economiche ed organizzative. Di seguito sono riportate le schede di valutazione specifiche per ogni facility oggetto della fase di assessment.
Nella valutazione dei data center e nella selezione delle location da mantenere e dismettere, sono stati
presi in considerazione anche alcuni altri parametri rilevanti in relazione al rischio ambientale:
- Rischio sismico
o La Sardegna in genera è ritenuta zona a bassissimo rischio sismico ed infatti l’ultimo evento
significativo risale al 1948
- Rischio idrogeologico (possibilità di frane o alluvioni)
o In questo caso il rischio è più sensibile in funzione della zona: Lanusei si trova in un’area
con elevato rischio di frane e Olbia in un’area a rischio di alluvioni
Di seguito il rapporto ISPRA 2018 che evidenzia le aree critiche sulla mappa italiana:Figura 3 - Aree italiane ad alto rischio idrogeologico
Per completezza, in ambito di assessment, sono state verificate le aree specifiche relative alla dislocazione dei singoli data center di Sassari, Olbia, Lanusei e Cagliari sulle mappe di rischio idrogeologico messe a disposizione dal portale SIRA (Sistema Informativo Regionale Ambientale) dalla Regione Sardegna. 2.3.1.1 Sassari Non si rilevano rischi di ordine generale per la sede di Sassari. 2.3.1.2 Olbia Olbia in generale è esposta al rischio di alluvioni, ma la sede della ASSL è situata in un’area sufficientemente lontana dal mare e non specificatamente esposta al rischio.
Puoi anche leggere
