COMUNE DI FIRENZE
PROGETTO dei FABBISOGNI
per la fornitura di “Servizi di Cloud Computing” SPC CLOUD LOTTO1
COMUNE DI FIRENZE
Pagina lasciata in bianco
S O M M A R I O
1 SOMMARIO 5
2 AMBITO 5
3 DEFINIZIONE ED ACRONIMI 5
4 RIFERIMENTI 7
4.1 Documenti contrattuali 7
4.2 Documenti di riferimento 7
4.2.1 Documentazione disponibile sul sito Consip 7
5 PROGETTO DI ATTUAZIONE DEL SERVIZIO IAAS E BAAS 8
5.1 Descrizione 8
5.2 Obiettivi del progetto 8
5.3 Servizio Iaas – Virtual Data Center 8
5.4 Servizio Baas 8
5.5 Impegni servizi professionali 9
5.6 Specifiche di Collaudo 9
6 DESCRIZIONE CENTRO SERVIZI 11
7 MODALITA’ DI PRESENTAZIONE E APPROVAZIONE STATI AVANZAMNETO MENSILI 12
8 PIANO DI ATTUAZIONE DEL SERVIZIO 12
8.1 Realizzazione dell’infrastruttura 12
8.2 Documento Programmatico di Gestione della Sicurezza dell’Amministrazione 12
9 TABELLA RIEPILOGATIVA FINALE SER’VIZI 13
REGISTRAZIONE MODIFICHE DOCUMENTO
La tabella seguente riporta la registrazione delle modifiche apportate al documento.
DESCRIZIONE MODIFICA | REVISIONE | DATA |
Prima emissione | 1 | 16/09/2021 |
1 SOMMARIO
Il presente documento descrive il Progetto dei Fabbisogni del RTI Telecom Italia, HP Enterprise Service, Postel, relativamente alla richiesta di fornitura dei servizi di Cloud Computing (IAAS/PAAS/SAAS)e dei nuovi servizi (Managed, DRaaS, DDoS, CaaS/ECaaS) nell’ambito del sistema pubblico di connettività e cooperazione (SPC) per l’Amministrazione.
Quanto descritto, è stato redatto in conformità alle richieste dell’Amministrazione e sulla base delle esigenze emerse durante gli incontri tecnici per la raccolta dei requisiti e sulla base delle informazioni contenute nel Piano dei Fabbisogni.
2 AMBITO
Il contratto per la fornitura di “Servizi di Cloud Computing, di Sicurezza, di Soluzioni di Portali di Servizi online e di Cooperazione Applicativa” Lotto 1, per le Pubbliche Amministrazioni ed il Raggruppamento Temporaneo di Impresa (RTI) costituito da:
• Telecom Italia S.p.A. (mandataria)
• Enterprise Services Italia S.r.l. - a DXC Technology Company
• Poste Italiane S.p.A
• Postel S.p.A
prevedono la fornitura dei seguenti servizi Cloud nell’ambito del Sistema Pubblico di Connettività e Cooperazione (SPC):
• Servizi IAAS
• Servizio BaaS
secondo quanto stabilito nel Capitolato Tecnico, nell’Offerta Tecnica e nella documentazione relativa all’implementazione di nuovi servizi, nella misura richiesta dalle amministrazioni Contraenti con i Contratti di Fornitura.
Telecom Italia, in qualità di mandataria, avrà in carico tutte le attività propedeutiche all’attivazione dei servizi contrattualizzati dall’Amministrazione Contraente relative, sia alla ricezione dei Piani dei Fabbisogni ed al conseguente invio dei relativi Progetti di Fabbisogni, sia all’accettazione dei Contratti di Fornitura.
In particolare la procedura per l’affidamento dei predetti servizi è articolata attraverso la stipula da parte di Consip
S.p.A. di un Contratto Quadro con l’Aggiudicatario della procedura medesima, che si impegna a stipulare, con le singole Amministrazioni Contraenti, Contratti di Fornitura aventi ad oggetto i predetti servizi alle condizioni stabilite nel Contratto Quadro.
La durata del Contratto Quadro è fissata in 36 mesi prorogabili, su comunicazione di Consip, sino ad un massimo di ulteriori 24 mesi. La proroga di ulteriori 24 mesi è stata approvata da CONSIP.
I singoli Contratti Esecutivi di Fornitura di ciascun Lotto avranno una durata decorrente dalla data di stipula del Contratto Esecutivo medesimo e sino al massimo della scadenza ultima, eventualmente prorogata (Lotto 1) del Contratto Quadro.
Le singole Amministrazioni contraenti potranno richiedere una proroga temporale dei singoli Contratti Esecutivi di Fornitura al solo fine di consentire la migrazione dei servizi ad un nuovo Fornitore al termine del Contratto Quadro, qualora la selezione dell’Operatore Economico subentrante non sia intervenuta entro i 3 mesi antecedenti la scadenza del presente Contratto Quadro.
3 DEFINIZIONE ED ACRONIMI
La seguente tabella riporta le descrizioni o i significati degli acronimi e delle abbreviazioni presenti nel documento.
Acronimi | Descrizione |
AgID | Agenzia per Italia Digitale |
API | Application Programming Interface |
BI | Business Intelligence |
CAD | Codice dell’Amministrazione Digitale |
CaaS | Container as a Service |
CONSIP | Consip S.p.A. |
DDoS as a Service | Distributed Denied of Service as a Service |
DRaaS | Disaster Recovery as a Service |
ECaaS | Enterprise Container as a Service |
F/OSS | Free and Open Source Software |
IaaS | Infrastructure as a Service |
ICT | Information and Communication Technology |
IE | Internet Explorer |
IT | Information Technology |
KPI | Key Performance Indicator |
PA | Pubblica Amministrazione |
PAC | Pubblica Amministrazione Centrale |
PAL | Pubblica Amministrazione Locale |
PaaS | Platform as a Service |
SaaS | SaaS: Software as a Service |
SPCoop | Sistema Pubblico di Connettività e Cooperazione |
HTTP | Hyper Text Transport Protocol |
HTTPS | Hyper Text Transport Protocol Secure |
SAL | Stato Avanzamento Lavori |
SAN | Storage Area Network |
SGSI | Sistema di Gestione della Sicurezza delle Informazioni |
SPC | Sistema Pubblico di Connettività |
VDC | Virtual Data Center |
VLB | Virtual Load Balancer |
VM | Virtual Machine |
VN | Virtual Network |
VF | Virtual Firewall |
VTS | Virtual Traffic Shaper |
VPN | Virtual Private Network |
Tabella – Glossario
4 RIFERIMENTI
4.1 Documenti contrattuali
Rif. | Documento |
#1 | PIANO dei Fabbisogni SERVIZIO |
Tabella dei documenti di contrattuali
4.2 Documenti di riferimento
La seguente tabella riporta i documenti che costituiscono il riferimento a quanto esposto nel seguito del presente documento.
Rif. | Documento |
#1 | BANDO DI GARA D’APPALTO – CONSIP S.p.A. |
#2 | LOTTO 1 - Relazione Tecnica “Procedura ristretta suddivisa in 4 lotti per l’affidamento di Servizi di Cloud Computing, di Sicurezza, di Soluzioni di Portali di Servizi online e di Cooperazione Applicativa per le Pubbliche Amministrazioni” (ID SIGEF 1403)” |
#3 | CAPITOLATO TECNICO – PARTE GENERALE – “Procedura ristretta suddivisa in 4 lotti per l’affidamento di Servizi di Cloud Computing, di Sicurezza, di Soluzioni di Portali di Servizi online e di Cooperazione Applicativa per le Pubbliche Amministrazioni” (ID SIGEF 1403)” |
#4 | Piano di Sicurezza dei Centri Servizi e Centri Servizi Ausiliari Cod. XX0000000 |
#5 | Specifiche di dettaglio delle prove di collaudo dei servizi in ambiente di test (Test Bed) |
#6 | Piano di Qualità CONSIP |
Tabella dei documenti di riferimento
4.2.1 Documentazione disponibile sul sito Consip
Riportare i nomi dei documenti ai quali si è fatto riferimento per i singoli servizi contrattializzati dall’Amministrazione.
5 PROGETTO DI ATTUAZIONE DEL SERVIZIO IAAS E BAAS
5.1 Descrizione
La soluzione proposta al cliente Comune di Firenze prevede un servizio in grado di garantire la gestione delle diverse procedure selettive di reclutamento del personale e specificatamente nelle fasi di organizzare e gestire i concorsi pubblici e le selezioni, curando l’espletamento di tutte le attività connesse allo svolgimento, garantire la totale sicurezza e trasparenza, nel pieno rispetto della normativa concorsuale vigente e a tutela della privacy, ottimizzare i costi ed azzerare il risk management.
Il servizio è dimensionato per la gestione di un totale massimo di 10.000 partecipanti alle procedure selettive, distribuiti in al massimo 4 procedure concorsuali, da svolgere anche nello stesso arco temporale.
5.2 Obiettivi del progetto
Gli obiettivi che l’Amministrazione si pone sono quelli di gestire, attraverso SPC Cloud, il sistema informatico per la gestione dei concorsi pubblici. Il sistema dovrà garantire l’espletamento di tutte le attività connesse allo svolgimento degli eventi, la totale sicurezza e trasparenza sempre nel pieno rispetto della normativa concorsuale vigente della privacy, ottimizzando infine i costi e il risk management .
5.3 Dettagli servizio contrattualizzato (ID servizio, quantità costi)
Le tabelle sotto riportate sono estratte dal configuratore SPC Cloud e prevedono 10 mesi di contratto.
5.3 Servizio Iaas – Virtual Data Center
Il servizio “IaaS - Virtual Data Center” permette alle Amministrazioni di creare e gestire in autonomia le proprie macchine virtuali partendo dalle singole risorse. Le risorse associate al Virtual Data Center possono essere richieste tramite pool base e upgrade di risorse aggiuntive di CPU [vCPU], RAM [GB] e spazio Storage [GB/TB]. Il servizio consente quindi all’Amministrazione di avere a disposizione e riservare risorse computazionali e di organizzarle autonomamente secondo una logica così definita di Virtual Data Center.
L’aggiornamento delle componenti software presenti nella macchina virtuale è a carico dell’Amministrazione che fruisce del servizio.
Il provider garantisce, senza oneri aggiuntivi per l’Amministrazione, di mantenere inalterate le performance e l’operatività del servizio fruito dall’Amministrazione per risorse superiori (gestione overload) fino al 10% del valore nominale del totale delle risorse indicate nei paragrafi successivi, con l’obiettivo di gestire picchi di lavoro estemporanei.
Per il servizio Virtual Data Center, oltre le risorse sopra elencate sono previste una serie di opzioni fatturate sulla percentuale di aumento della performance dello storage (velocità disco) e degli SLA di servizio (tempi di uptime e ripristino) su ora o mese, a consumo o a canone.
In fase di creazione delle VM l’utente ha la possibilità di inserire una propria licenza per il Sistema Operativo. Nella seguente tabella sono specificate le risorse messe a disposizione:
Servizio | Elementi | Profilo | Quant | Durata | Importo € |
Virtual Storage - Object - | VStorage - Medium - Canone | 1 TB | 1 | 10 | 286,0000 |
5.4 Servizio Baas
Il servizio “BaaS – Backup as a Service” permette alle Amministrazioni di acquistare e gestire in completa autonomia un servizio base di backup, per effettuare il salvataggio di dati presenti su server fisici di proprietà delle singole Amministrazioni o virtuali, compresi i dati di PC desktop o portatili del personale delle Amministrazioni stesse.
Requisiti funzionali:
Per il servizio di Backup as a Service sono disponibili cinque profili (Small, Medium, Large, X-Large e XX- Large), differenziati sulla base della quantità [in GB] di spazio di archiviazione disponibile.
Nella seguente tabella sono specificate le risorse messe a disposizione:
Servizio | Elementi | Profilo | Quant | Durata | Importo € |
Backup as a Service | Xlarge - Consumo | da 0,5 a 5 TB di spazio di archiviazione | 1.000 | 10 | 1.114,5750 |
5.5 Impegni servizi professionali
I Servizi di Cloud Enabling sono servizi professionali finalizzati a supportare l’Amministrazione nei progetti di Cloud Transformation al fine di utilizzare le risorse ed i servizi previsti dal Contratto Quadro.
ID Servizio | Elementi | Quantità | Costo [€] |
Xxxxxxx Xxxxxxxxxxxxx | XXXX XXXXXXXX | 00 | 00.000,0000 |
XX ARCHITECT SENIOR | 200 | 74.580,0000 | |
SPECIALISTA DI TECNOLOGIA/PRODOTTO | 440 | 132.673,2000 | |
SISTEMISTA SENIOR | 617 | 173.284,4500 |
l servizi sono erogati attraverso l’impiego di specifiche figure professionali. Le attività per questo progetto sono elencate di seguito:
Tabella servizi Cloud Enabling
5.6 Specifiche di Collaudo
I test di collaudo saranno eseguiti presso la sede del Cliente.
Le seguenti linee guida descrivono lo svolgimento delle prove di collaudo atte a verificare la conformità delle configurazioni particolari richieste dall’Amministrazione per il servizio in oggetto e descritte nel relativo paragrafo del presente documento.
Le modalità di esecuzione ed i relativi documenti di output saranno conformi a quanto già previsto per il collaudo Consip.
I test saranno eseguiti secondo il seguente processo:
1) configurazione del servizio, degli apparati e degli strumenti in base a quanto specificato nella scheda di test;
2) esecuzione del test secondo quanto descritto nella relativa scheda;
3) se l’esito del test è positivo si ritorna al punto 1) procedendo con il test successivo;
4) se l’esito è negativo viene registrata l’anomalia, a cui è associato un livello di gravità (bloccante, grave, accettabile);
5) se l’anomalia è di tipo bloccante si sospende il test in corso proseguendo eventualmente con il test successivo tornando al punto 1).
Le anomalie saranno gestite con le seguenti modalità:
• Classificazione: ogniqualvolta sia rilevata una anomalia essa sarà registrata dall’operatore che esegue il test con la classificazione “grave”. Sarà poi cura del team di verifica riclassificare, se necessario, l’anomalia in occasione dei controlli periodici di avanzamento della verifica.
• Notifica di rilevamento: la scheda anomalia compilata dall’operatore ed eventualmente quella con la riclassificazione operata dal team di verifica saranno inviate alle strutture di competenza.
• Notifica di risoluzione: le modalità di risoluzione delle anomalie saranno esaminate dal team di verifica in occasione dei controlli periodici di avanzamento delle verifiche in collaborazione con le strutture di competenza. Sarà quindi ripianificato il processo di verifica per effettuare i nuovi test a valle della risoluzione dell’anomalia.
Nel corso delle attività di verifica saranno condotti opportuni controlli di avanzamento con l’obiettivo di:
1. verificare l’avanzamento della pianificazione temporale;
2. analizzare le anomalie rilevate;
3. analizzare le modalità di risoluzione delle anomalie;
4. progettare i test di regressione per chiusura anomalie;
5. ripianificare le sessioni di test ed aggiornare la pianificazione temporale.
Il Piano di Test è articolato in schede, divise nelle seguenti sezioni:
Campo | Significato |
Requisito | Identificativo del requisito oggetto del test |
Scopo | Riassume l’obiettivo del test |
Modalità di esecuzione | Indica la modalità di esecuzione del test, ad esempio per accesso diretto alla piattaforma, iniziando dall’accesso all’ambiente. |
Scenario di riferimento | Descrive lo ‘scenario utente’ nel quale avviene il test e le condizioni che caratterizzano lo scenario |
Macro azioni | Sono i passi operativi che si compiono durante la rappresentazione del test. |
Risultato atteso | E’ lo scenario utente atteso, a seguito dell’esecuzione del test. |
Esito del test | E’ l’esito del test, positivo se lo scenario ottenuto a seguito del test coincide con lo scenario atteso, negativo in caso contrario. |
6 DESCRIZIONE CENTRO SERVIZI
Per gli ambienti attivi su piattaforma Helion OPenStack (HOS) per la descrizione si rimanda al paragrafo 3.3 del documento :
LOTTO 1 - Relazione Tecnica
“Procedura ristretta suddivisa in 4 lotti per l’affidamento di Servizi di Cloud Computing, di Sicurezza, di Soluzioni di Portali di Servizi online e di Cooperazione Applicativa per le Pubbliche Amministrazioni”
(ID SIGEF 1403)
A partire da luglio 2019 è stata messa in esercizio sia da TIM che da DXC la nuova piattaforma Canonical OpenStack che sostituisce l’attuale piattaforma HOS, pertanto gli ambienti attualmente attivi su HOS saranno migrati sulla nuova piattaforma mentre a partire da luglio 2019 i nuovi ambienti saranno attivati sulla nuova piattaforma Canonical.
La nuova piattaforma consente di aumentare l’affidabilità dei servizi e la continuità operativa mediante i seguenti elementi fondanti:
• abilitazione all’erogazione dei servizi SPC Cloud in modalità multi-Region che supportano servizi “Cloud nativi” con la predisposizione di Region contemporaneamente attive.
• reingegnerizzazione ed evoluzione del Disaster Recovery che per gli ambienti legacy non sarà più basato sull’intera piattaforma ma circoscritto ad ogni singolo progetto/tenant per scongiurare anche fault parziali; mentre per gli ambienti cloud nativi i clienti potranno avvalersi della continuità operativa dei propri servizi implementando autonomamente il bilanciamento geografico dei propri IP pubblici (Internet e Infranet) sulle due region.
Per sfruttare appieno le funzionalità delle Region i servizi applicativi devono essere concepiti in modalità cloud nativa ove, per applicazione “cloud nativa” si intende una qualsiasi applicazione che è stata sviluppata secondo le logiche dei servizi in cloud (API-first, microservizi) o in logiche più tradizionali, che possa utilizzare le proprie componenti middleware in modalità disaccoppiata e distribuita. Anche il classico modello multi-tier “web - application - database” con meccanismi di replica asincrona dei layer dati può avvalersi delle due region attive. Tuttavia si sconsiglia l’adozione di questo modello qualora almeno una delle componenti middleware non sia distribuibile geograficamente.
Sono state realizzate, sia da TIM sia da DXC, due Region distribuite su due diverse aree geografiche: nord e centro. La figura seguente riporta lo schema della nuova architettura che prevede: 2 Region per TIM posizionate rispettivamente a Acila-Pomezia (Region 1) e Rozzano (Region2); 2 Region per DXC posizionate rispettivamente a Inverno (Pavia) (Region 1) e Acilia (Region 2).
Architettura Multi-Region
Le Region TIM e DXC sono tra loro indipendenti.
Le due Region di un medesimo Provider (TIM o DXC) sono tra loro paritetiche ovvero, non c’è una Region primaria ed una secondaria e pertanto un intero ambiente legacy/tradizionale cliente potrà essere attivato su una Region mentre l’ambiente legacy di un altro cliente potrebbe essere attivato sull’altra Region. In fase di delivery sarà in generale il Provider (TIM o DXC) a stabilire su quale Region attivare l’ambiente legacy cliente. In questo modo viene garantito un più efficiente utilizzo delle risorse.
In quest’ottica, per gli ambienti legacy/tradizionali il concetto di Disaster Recovery viene applicato, anziché all’intera piattaforma, al contesto di ogni tenant/progetto Cloud degli utenti mentre per gli ambienti cloud nativi il DR di piattaforma evolve mediate le funzionalità offerte dalle Region.
L’introduzione delle Region consente una nuova modalità di implementazione del DR che garantisce, in caso di disastro in uno dei Centro Servizi che ospita una delle Region, che tutti i tenant in esso attivi e che ospitano servizi applicativi legacy (non Cloud nativi) possano essere ripristinati sull’altra Region già attiva. Questa nuova modalità consente inoltre, sempre per gli ambienti legacy, la gestione di problematiche infrastrutturali che impattano anche un singolo tenant mediante il ripristino dell’ambiente sull’altra Region, limitando in tal modo il disservizio.
Da un punto di vista dei requisiti del capitolato di gara la soluzione prospettata è, per gli ambienti legacy/tradizionali, funzionalmente equivalente in quanto garantirà lo stesso livello delle soglie di RPO = 1 ora e RTO = 4 ore.
Per gli ambienti cloud nativi il servizio di DR di piattaforma viene realizzato mediante l’implementazione delle Region. In tale contesto l’ambiente applicativo del Cliente sarà operativo su entrambe le Region, garantendo l’erogazione dei servizi, eventualmente con prestazioni ridotte, anche in caso di indisponibilità di una Region. Per un’efficace utilizzo delle applicazioni cloud native è necessario che il cliente dimensioni e configuri in modo opportuno le risorse dei propri ambienti su entrambe le Region in modo che la user- experience del cliente finale venga impattata al minimo in caso di fault di una Region.
7 MODALITA’ DI PRESENTAZIONE E APPROVAZIONE STATI AVANZAMNETO MENSILI
Per la descrizione si rimanda al capitolo 7.2.4 del documento:
CAPITOLATO TECNICO – PARTE GENERALE –
“Procedura ristretta suddivisa in 4 lotti per l’affidamento di Servizi di Cloud Computing, di Sicurezza, di Soluzioni di Portali di Servizi online e di Cooperazione Applicativa per le Pubbliche Amministrazioni”
(ID SIGEF 1403)”
8 PIANO DI ATTUAZIONE DEL SERVIZIO
8.1 Realizzazione dell’infrastruttura
Secondo quanto previsto dalla convenzione.
Il piano delle attività relative al Cloud Enabling sarà calendarizzato (Cronoprogramma) in fase di start up del progetto, in accordo con i Referenti del Cliente.
8.2 Documento Programmatico di Gestione della Sicurezza dell’Amministrazione
Il Documento programmatico di gestione della Sicurezza verrà consegnato entro 20 gg dalla data in cui l’ Amministrazione Contraente ne farà richiesta.
9 TABELLA RIEPILOGATIVA FINALE SER’VIZI
Famiglia di Servizi | Durata | UT | Canone |
VStorage - Medium - Canone | 10 [mesi] | 0 | 286,0000 € |
Backup as a Service | 10 [mesi] | 0 | 1.114,5750 € |
Cloud Enabling | - | 408.269,5500 € | 0 |
TOTALE | 408.269,5500 € | 1.400,5750 € | |