DIREZIONE SISTEMI INFORMATIVI

FORNITURA DI UNA “DATA PROTECTION SOLUTION”

(data archiving, backup, recovery and DR-support)

CAPITOLATO SPECIALE

INDICE

LEGENDA 3

Art. 1 – Oggetto della fornitura. Corrispettivo 7

Art. 2 – Precisazioni sulla fornitura 7

Art. 3 – Caratteristiche della fornitura 8

Art. 3.1 – Requisiti di MANUTENZIONE on-site e supporto obbligatori 10

Art. 3.2 – Requisiti di HARDWARE obbligatori minimi 15

Art. 3.3 – Requisiti di LICENZE, performance minime e norme obbligatorie 17

Art. 3.4 – Requisiti di SISTEMA obbligatori minimi 19

Art. 3.5 – Requisiti di PROTEZIONE e sicurezza obbligatori minimi 22

Art. 4 – Caratteristiche generali degli apparati 26

Art. 5 – Cronoprogramma delle attività della fornitura 27

Art. 6 – Verifiche ed emissione del certificato di regolare esecuzione (C.R.E.) 28

Art. 7 – Durata e parti del contratto. Sospensioni. 31

Art. 8 – Modalità di fatturazione e pagamento 31

Art. 9 – Organizzazione e gestione del rapporto contrattuale 32

Art. 10 – Penali e rispetto livelli di servizio 33

Art. 11 – Osservanza delle norme in materia di lavoro 35

Art. 12 – Risoluzione del contratto 35

Art. 13 – Recesso 36

Art. 14 – Modifiche del contratto 36

Art. 15 – Subappalto 36

Art. 16 – Revisione e invariabilità dei prezzi 36

Art. 17 – Garanzie 37

Art. 18 – Trattamento dati. Obblighi di riservatezza. 37

Art. 19 – Clausola di rinvio e foro competente 38

LEGENDA

Per semplificare la lettura della documentazione tecnica, in questo paragrafo viene riportata la legenda delle abbreviazioni, degli acronimi, delle definizioni e della terminologia utilizzata nei diversi documenti di gara.

Agent	Un agent è un software particolare o un'applicazione installata su un computer che si connette ad un processo server e svolge sul client predeterminate funzioni assegnate tramite un pannello di controllo e di gestione generalmente centralizzato.
Appliance	Appliance è un particolare dispositivo o sistema (sia fisico che virtuale) provvisto di un software integrato e dedicato a svolgere particolari, complesse e mirate funzioni. Il termine “appliance” infatti significa apparecchio progettato per un compito specifico.
BC (Business Continuity) o CO (Continuità Operativa)	In informatica, la Continuità Operativa riguarda il processo critico che, nel caso di grave e prolungata indisponibilità dei sistemi informativi, disservizio incompatibile con le esigenze di continuità di funzionamento, prevede delle misure e delle procedure per garantire il ripristino dello stato del sistema informatico (o di parte di esso), per riportarlo alle condizioni di funzionamento e di operatività antecedenti all’evento disastroso verificatosi. Eventualmente possono attivarsi modalità parziali e temporanee di erogazione e di fruizione e, progressivamente, si devono prevedere strategie per tornare alla normalità.
Best effort	Con servizio “best effort” si intende che viene fornito con il massimo di quello che si può fare, senza garantire alcuna affidabilità o stabilità in termini di controllo, di tempistiche, di risposta e nemmeno di certezza dell’erogazione.
Cloud e cloud-based	In informatica con il termine inglese cloud si indica un insieme di tecnologie che permettono, tipicamente sotto forma di un servizio offerto da un provider, di memorizzare/archiviare e/o elaborare dati e/o erogare servizi applicativi grazie all'utilizzo di risorse hardware/software distribuite e virtualizzate in rete. Una tecnologia cloud-based è pertanto un sistema in grado di fruire di tali soluzioni in modo assolutamente corretto e compatibile.
Cluster	Cluster indica in generale un gruppo di oggetti; nello specifico in informatica, un cluster è un insieme di computer, detti nodi, connessi tramite una rete o altre modalità per lo scambio dati con lo scopo di erogare congiuntamente dei servizi o delle funzioni specifiche.
DBMS (DataBase Management System)	In informatica, un sistema di gestione di basi di dati, dall’inglese Database Management System (abbreviato in DBMS) è un sistema software progettato per consentire la creazione, la manipolazione e l'interrogazione efficiente di database, per questo detto anche "gestore o motore del database" stesso.
DPS (Data Protection Solution)	Per quanto concerne la presente fornitura, si intende un sistema informatico centralizzato, costituito da hardware e software opportunamente integrati e configurati tra loro, che affianchi ai classici servizi di archiviazione, salvataggio e ripristino di dati elettronici, anche tipiche funzionalità di recupero dal disastro (in inglese, Disaster Recovery o DR) – Si rimanda anche a quanto precisato nell’introduzione del presente documento.

DR (Disaster Recovery)

Nell'ambito della sicurezza informatica, si intende l'insieme delle tecnologie, delle misure tecniche e logistico/organizzative atte a ripristinare sistemi, dati e infrastrutture necessarie all'erogazione di servizi informatici, a fronte di gravi eventi o emergenze che ne compromettano la regolare attività.

DRaaS

Disaster-Recovery-as-a-Service o DRaaS è un particolare servizio informatico che consente di erogare le funzionalità proprie di una soluzione di tipo DR basandole completamente su funzioni realizzate e fruibili dal cloud.

Fabric o switched fabric

Fabric o switched fabric è una topologia di rete in cui i nodi sono interconnessi tra loro mediante più apparati di switch; considerato che il traffico è distribuito simultaneamente attraverso più collegamenti fisici, complessivamente si riesce a garantire un throughput maggiore rispetto a reti di broadcast, quali Ethernet.

Fail-over (tecniche di fault-tolerant)

In informatica, il fail over è una tecnica automatica di attivazione di un sistema ICT (network, hardware, software, servizio) ridondante, o in stato passivo, dopo

il fallimento o l’anomala terminazione del precedente sistema attivo o che aveva quella particolare funzione in carico

Fibre-channel

In telecomunicazioni e informatica il termine “fibre channel”, abbreviato come FC, indica sia un protocollo che la tecnologia per reti dati, usata principalmente per implementazioni in Storage Area Network (SAN), attualmente con velocità nell’ordine delle decine di Gbps.

GbE o

Gigabit Ethernet

In informatica e telecomunicazioni, il Gigabit Ethernet è un protocollo di trasmissione dati, identificato dagli standard IEEE 802.3z su fibra e IEEE 802.3ab su rame. È l'evoluzione a 1.000 Mbit/s del protocollo Fast Ethernet (standard IEEE 802.3u) operante a 100 Mbit/s a sua volta un’evoluzione del protocollo originale Ethernet operante a 10 Mbit/s.

Hardware

Con il termine hardware si indica la parte fisica di un computer, ovvero tutti i moduli e tutte quelle parti elettroniche, meccaniche, magnetiche, ottiche che ne consentono il funzionamento; più in generale si fa riferimento a qualsiasi

componente fisico di una periferica o di una apparecchiatura elettronica.

HBA (Host Bus Adapter)

L'host bus adapter o HBA, detto anche host adapter/controller, è una scheda d'espansione che consente di connettere un computer e/o dispositivi di memorizzazione dei dati, tipicamente in una rete di Storage Area Network.

Host

Un nodo ospite, host o anche “end system”, indica qualsiasi terminale collegato ad una rete o più in particolare ad Internet, quindi PC client, server, router, switch e, nell’accezione più generica, un qualsiasi apparato fisico ICT.

Hot-spare

La funzionalità hot-spare è caratteristica dei sistemi RAID e consiste nella disponibilità di dischi di ricambio conosciuti dal sistema. Nel caso uno dei dischi si dovesse rendere inutilizzabile, il sottosistema provvederà a proteggere i dati mediante il proprio algoritmo di fault-tolerance, mentre potrà abilitare il disco di riserva al posto di quello guasto in attesa del ripristino della situazione

iniziale.

Hypervisor

L'hypervisor è il componente centrale e più importante di un sistema basato sulle macchine virtuali (virtual machines o VM) per la completa astrazione della sottostante infrastruttura fisica. Deve operare in maniera del tutto trasparente per consentire il funzionamento e le prestazioni adeguate dei sistemi operativi ospiti sulle VM gestite.

LUN

Una Logical Unit Number, più comunemente LUN, è un numero che identifica

(Logical Unit Number)	diverse periferiche che condividono lo stesso bus. Il termine è molto usato nelle storage area networks (SAN) per identificare partizioni differenti di un medesimo insieme di dischi configurati in RAID.
MTBF (Mean Time Between Failures)	Il tempo medio fra i guasti, in inglese Mean Time Between Failures (abbreviato in MTBF), è un parametro di affidabilità applicabile a dispositivi meccanici, elettrici ed elettronici che fornisce una misura del valore medio di vita di un certo apparecchio elettronico o componente meccanico.
NAS (Network Attached Storage)	È un dispositivo con funzionalità e caratteristiche più o meno sofisticate, collegato ad una rete di computer la cui funzione base è quella di condividere tra gli utenti della rete una memoria di massa per archiviare dati elettronici, in pratica costituita da uno o più dischi rigidi.
NTFS (New Technology File System)	New Technology File System o NTFS è la sigla adottata da Microsoft per indicare il filesystem presente sui sistemi operativi basati su kernel NT.
On-premises	Un servizio, un software o un sistema “on-premises” (a volte indicato anche “on-premise” o abbreviato “on-prem”) è installato ed eseguito su computer e apparati informatici che sono presenti nell’organizzazione o nella rete aziendale dei soggetti che ne fanno uso, piuttosto che in sale server esterne o tramite soluzioni remote e basate sul cloud.
Private cloud	Un private cloud è un particolare modello di “cloud computing” che implica l’impiego di un ambiente cloud-based con un predeterminato livello di isolamento, cioè un insieme di risorse informatiche dedicate per l’utilizzo e per l’accesso a specifici utenti/clienti/organizzazioni e non al pubblico in generale.
RAID (Redundant Array of Independent Disks)	In informatica un RAID, acronimo di Redundant Array of Independent Disks, insieme ridondante di dischi indipendenti, è un sistema informatico che usa un gruppo di dischi rigidi per condividere o replicare le informazioni. Esistono diverse modalità di RAID a seconda dei livelli di prestazioni, di ridondanza e di protezione ai guasti desiderati.
RAM (Random Access Memory)	Memoria ad accesso casuale, in inglese random-access memory, in contrapposizione con la memoria ad accesso sequenziale, è un tipo di memoria volatile caratterizzata dal permettere l'accesso diretto a qualunque indirizzo di memoria con lo stesso tempo di accesso. In informatica rappresenta generalmente la memoria centrale di sistema per l’esecuzione dei processi.
RDM (Raw Device Mapping)	In ambito di storage centralizzato e virtualizzazione, un sistema Raw Device Mapping è una particolare modalità di mappatura di un volume fisico, generalmente una LUN, presente sullo storage fisico. La tecnologia RDM consente ad una macchina virtuale di accedere e di gestire direttamente il dispositivo storage senza intermediazione da parte dell’Hypervisor, con diversi livelli possibili di autonomia e indipendenza a seconda della configurazione.
RPO (Recovery Point Objective) e RTO (Recovery Time Objective)	Il Recovery Point Objective (RPO) è uno dei parametri usati nell'ambito delle politiche di recupero da disastri per descrivere la tolleranza ai guasti di un sistema informatico. Esso rappresenta il massimo tempo che deve intercorre tra la produzione di un dato e la sua messa in sicurezza (ad esempio con i backup). Invece il Recovery Time Objective (RTO) è il tempo necessario per il pieno recupero dell'operatività di un sistema. È in pratica la massima durata, prevista o tollerata, del disservizio per quel particolare sistema.

SALA-DR	È la sala prevista per ospitare fisicamente i moduli hardware della soluzione DPS offerta, si rimanda alla lettura del paragrafo sulle sedi.
SAN (Storage Area Network)	Una Storage Area Network è una rete ad alta velocità di trasmissione (Gigabit/sec o decine di Gbps) costituita esclusivamente da dispositivi di memorizzazione di massa di dati elettronici il cui scopo è quello di rendere tali risorse di immagazzinamento (storage) disponibili per qualsiasi computer connesso ad essa.
Server e client	Il termine ‘server’ indica genericamente un componente o un sottosistema informatico di elaborazione che fornisce, a livello logico e a livello fisico, un qualunque tipo di servizio ad altre componenti (tipicamente chiamate ‘client’) che ne fanno richiesta generalmente attraverso una rete di computer.
SPoF (Single Point of Failure)	In un sistema informatico un singolo punto di vulnerabilità o Single Point of Failue (in inglese), è una parte del sistema, hardware o software, il cui singolo malfunzionamento può portare ad anomalie o addirittura alla cessazione del servizio da parte del sistema nella sua interezza.
SQL (Structured Query Language)	In informatica SQL (Structured Query Language) è un linguaggio standardizzato per database basati sul modello relazionale e progettato per la manipolazione (creare, modificare, leggere, aggiornare, inserire, cancellare) dei dati presenti in un DBMS.
SSD (Solid-State Drive)	In informatica e elettronica, un’unità disco o di memoria a stato solido (acronimo SSD, dal termine inglese solid-state drive) è una tipologia di dispositivo di memorizzazione di massa basata su semiconduttore, che utilizza memoria allo stato solido (memoria flash) per l'archiviazione dei dati.
Standby	La modalità di attesa, ovvero “standby” che in inglese significa in attesa, è quella condizione in cui un dispositivo elettronico non è operativo, ma è pronto per la commutazione, manuale o automatica, da stato di inutilizzo a modalità operativa.
Thin/Thick provisioning	In informatica, il “thin provisioning” comporta l’impiego di una tecnologia di virtualizzazione per fornire in “apparenza” più risorse di quelle realmente a disposizione. In particolare, in ambito archiviazione o storage, tale termine indica che in un certo momento viene allocato solo lo spazio effettivamente occupato dai dati elettronici e non la dimensione complessiva richiesta. Invece nella modalità “thick provisioning” tutto lo spazio richiesto, anche se vuoto e non ancora utilizzato, viene completamente assegnato e preallocato, pertanto del tutto indisponibile ad altri sistemi.
TIX, DC-TIX o HyperTIX	Tuscany Internet eXchange è il data center principale di Regione Toscana.
VM (Virtual Machine)	L’abbreviazione macchina virtuale (VM) o virtual machine indica un software che, attraverso un processo di virtualizzazione, fornisce un ambiente che emula tipicamente il comportamento di una macchina fisica grazie all'assegnazione di risorse computazionali adeguate (processore, memoria, disco, rete, ecc.).
VMDK (Virtual Machine Disk)	Il Virtual Machine Disk, abbreviato VMDK, è un formato di file utilizzato da prodotti VMware; con questo formato viene descritto e documentato l'ambiente operativo della macchina virtuale e le modalità con le quali è memorizzato.
VDC-COFI	Vecchio Data Center del Comune di Firenze, si veda il paragrafo sulle sedi.

Art. 1 – Oggetto della fornitura. Corrispettivo.

1. Oggetto del presente Capitolato è la fornitura della soluzione tecnologica di protezione dei dati del Comune di Firenze (di seguito anche “committente” o, congiuntamente al fornitore, anche “Parti”) nel suo complesso (hardware, apparati, nodi e sistemi ICT), da installare e da configurare in modo adeguato nell’attuale infrastruttura di rete e da interfacciare con il sistema virtuale centralizzato su VMware vSphere del Comune di Firenze, e tutto quanto ad essa risulti correlato per la messa in produzione e per assicurarne successivamente il corretto funzionamento e la contemporanea piena rispondenza ai requisiti tecnici del presente Capitolato Speciale (cioè prodotti, software, licenze, plug-in, add-on, …) e relativi allegati; sono pertanto compresi eventuali moduli di espansione, il firmware o il relativo sistema operativo, il software, tutte le licenze (sistema operativo, prodotti software e moduli aggiuntivi, eventuali DBMS, ecc.) con i codici di attivazione, il supporto almeno triennale (3 anni) e tutti i servizi a corredo, come meglio specificato nell’art. 3 del presente Capitolato.

2. Il corrispettivo della presente fornitura è pari a complessivi € 217.066,50 oltre IVA 22%, per un totale di € 264.821,13 . Il suddetto corrispettivo si suddivide in:

a) importi di pertinenza degli apparati forniti, delle licenze e dei servizi correlati, per € 172.131,15 oltre IVA 22%, per un totale di € 210.000,00;

b) importi dei servizi di assistenza tecnica e manutenzione dopo la messa in produzione; per € 44.935,34 oltre IVA 22%, per un totale di € 54.821,12.

Art. 2 – Precisazioni sulla fornitura

1. Al fine di consentire la corretta esecuzione della prestazione si allega al presente Capitolato, quale parte integrante dello stesso, la Relazione Tecnica già resa disponibile per i concorrenti in fase di gara (Allegato 1), contenente un’esauriente descrizione dello “scenario di riferimento”.

2. Per contenere i costi complessivi, la fornitura oggetto del presente Capitolato non richiede obbligatoriamente hardware aggiuntivo per realizzare il “cluster DR”, basato su VMware vSphere, e per il vCenter di gestione, ovverosia le risorse computazionali (CPU), di memoria (RAM) e di infrastruttura-connettività di rete (LAN ethernet), mentre rimane e deve essere fornito lo storage che ospiterà le vm e i dati gestiti da tale nuovo cluster. Infatti, le risorse informatiche indicate (CPU, RAM e LAN) sono previste e saranno messe a disposizione dal committente tramite, appunto, il riutilizzo di host preesistenti (come precisato al paragrafo 2.9 della Relazione Tecnica allegata), ritenuti sufficienti per soddisfare tale funzione a livello base, e impiegando dei network core switch di recente acquisizione. Caratteristiche che probabilmente non consentiranno di “riaccendere contemporaneamente” tutte le macchine virtuali (vm) presenti in origine sul cluster primario di produzione, ma sono una base di partenza per le funzioni cercate di supporto al DR.

3. Si sottolinea che, qualsiasi sia la modalità di reperimento delle risorse computazionali del “cluster DR” individuata dal fornitore, la predisposizione e la configurazione di tale cluster sarà concordata, rivista e realizzata obbligatoriamente in collaborazione e validata sempre dal committente, per assicurare la piena riuscita del progetto, per condurre in modo proficuo tutte

le successive attività di verifica e, non ultimo, per soddisfare quanto previsto nelle fasi di esercizio effettivo.

4. Tenuto conto che la soluzione tecnologica definita e realizzata dal fornitore è stata dimensionata anche in considerazione dei valori indicati nel documento di gara “ RELAZIONE TECNICA SULLO SCENARIO DI RIFERIMENTO”, valori che in corso di esecuzione potrebbero modificarsi, le Parti del presente Capitolato danno atto che la diminuzione di qualche valore rispetto scenario descritto nel suddetto documento non introduce criticità; qualora, invece, durante le attività di verifica finale della soluzione tecnologica realizzata di cui al successivo art. 6 o altre fasi fondamentali della presente fornitura l’Aggiudicataria riscontri discrepanze sostanziali ed in aumento dei valori indicati nel documento di gara “RELAZIONE TECNICA SULLO SCENARIO DI RIFERIMENTO”, la stessa è tenuta a darne immediata comunicazione al Committente, in modo da definire ad una gestione adeguata della evenienza mediante gli istituti contrattuali previsti dal D.Lgs. 50/2016, con particolare riferimento a quanto previsto dall’art. 106 del suddetto decreto.

Art. 3 – Caratteristiche della fornitura

1. Nel seguito, con i termini apparati, nodi, sistemi e prodotti si intenderanno e si farà sempre riferimento agli apparati e ai moduli HW/SW che compongono la piattaforma tecnologica “Data Protection Solution” oggetto della presente fornitura.

2. La fornitura deve comprendere, nei diversi ambiti tecnologici di interesse, le caratteristiche obbligatorie minime indicate nel presente articolo, che la soluzione completa o i singoli apparati/nodi dovranno necessariamente soddisfare, nonché le altre caratteristiche di tipo opzionale, migliorative o comunque che rientrano nell’ambito dell’offerta tecnica formulata dal fornitore ed accettata dal committente, allegata al presente Capitolato quale parte integrante dello stesso (Allegato 2).

3. È vietato l’inserimento, da parte del fornitore, di vincoli “stringenti” di licenza legati, a titolo esemplificativo e non esaustivo, alla quantità di traffico trattato (GB/orari piuttosto che TB/giornalieri) oppure al numero di interfacce attivate, alla quantità di oggetti presenti nei salvataggi, alle macchine virtuali coperte dalla funzionalità di DR base, alle risorse computazionali in gioco, ecc.

4. Nella dizione “caratteristiche o requisiti minimi” sono anche ricompresi valori numerici o dati e caratteristiche superiori a quanto espressamente richiesto, purché adeguati e se soddisfano tutte le condizioni tecniche. A titolo esemplificativo e non esaustivo:

a) se viene richiesto un minimo di 8 (otto) interfacce GbE RJ45 rame e un singolo apparato è strutturato con 6 (sei) interfacce 1 GbE RJ45 rame e 2 (due) a 10 GbE RJ45 rame, purché autosensing e compatibili con velocità 1 GbE, allora il requisito è soddisfatto;

b) se viene richiesto un minimo di 2 (due) alimentatori hot-swap e l’apparato singolo ne alloggia 4 (quattro), ma tutti di tipologia fixed (non hot-swap) allora il requisito è disatteso;

c) se viene richiesto un quantitativo complessivo di memoria per la soluzione tecnologica pari a 64 (sessantaquattro) GB e la stessa si compone di 2 (due) apparati rispettivamente da

48 (quarantotto) GB e 32 (trentadue) GB, quindi complessivamente 80 (ottanta) GB, allora il requisito è soddisfatto.

5. Il fornitore dovrà predisporre, entro 30 (trenta) giorni lavorativi dall’aggiudicazione (si rimanda al successivo art. 5 per il cronoprogramma delle attività della presente fornitura), il cosiddetto “Piano di Progetto definitivo”, completo in ogni sua parte. Il “Piano di Progetto definitivo” consiste nel Piano di Progetto” presentato dal fornitore in sede di offerta tecnica sviluppato ed ulteriormente dettagliato in esito ad una compiuta valutazione dell’infrastruttura informatica dell’Ente nel cui contesto sarà dispiegata la soluzione tecnologica del fornitore.

L’obiettivo è arrivare a una piena condivisione con il personale tecnico e sistemistico del Comune di Firenze sulla soluzione tecnica, le configurazioni e i test relativi. Il “Piano di Progetto definitivo”, ove necessario, dovrà dunque essere integrato dal fornitore con le ulteriori eventuali specificazioni emergenti dai contatti con l’Amministrazione, al fine di chiarire ogni aspetto tecnico di dettaglio del dispiegamento.

6. Le caratteristiche, le protezioni e i servizi di seguito indicati e richiesti nella forma di “requisiti obbligatori minimi” devono essere presenti sugli apparati offerti (sottostando al vincolo di occupazione complessiva di spazio negli armadi rack) senza integrazioni aggiuntive esterne di hardware (ad esempio storage, bilanciatori, firewall, ecc.), fatta eccezione per tutti gli aspetti di networking e di connettività ridondata esterna basata su ethernet. Devono essere tutti attivi, utilizzabili e completamente funzionanti senza nessuna ulteriore limitazione o vincolo di uso rispetto al numero di utenti, alle quantità di client, al numero di server fisici e/o virtuali, al throughput di traffico dati, alla quantità di dati da salvare (archive, backup, restore e DR-support), al numero di restore giornalieri/annuali, al numero di schedulazioni e di policy attivate e a tutte le altre specifiche inerenti l’infrastruttura informatica interna dell’Ente, come dettagliatamente indicato nei successivi articoli del presente Capitolato.

7. I requisiti dovranno essere verificabili direttamente da brochure, dagli specsheet e nei datasheet ufficiali del produttore dell’apparato offerto; da qui l’importanza di indicare serie, tipologia, modello esatto offerto, licenza di attivazione e gli eventuali moduli o add-on di espansione a corredo per la presente fornitura. Si precisa che i datasheet, possibilmente solo la parte strettamente di pertinenza a quanto offerto e cercando di ridurre il più possibile informazioni ripetitive e ridondate, dovranno essere inseriti anche nella documentazione contenuta nel “Piano di Progetto Definitivo” e, se esistente, indicato anche con un riferimento al loro link web ufficiale su Internet, generalmente pubblicato a cura del produttore. In ogni caso, per i datasheet da inserire in documentazione, si ritiene non sussistano motivi di riservatezza o di segreto industriale, in quanto saranno visibili esclusivamente dal committente e dal fornitore stesso.

8. Qualsiasi costo, intervento o futura spesa di adeguamento dovessero risultare necessari per l’attuale infrastruttura esistente (ambiente di produzione o “cluster DR” di recupero), per renderla del tutto compatibile o abilitarla al supporto delle diverse funzionalità previste dalla soluzione di Data Protection offerta, rimangono esclusivamente a carico del fornitore. A titolo esemplificativo e non esaustivo: il potenziamento di qualche apparato, eventuali licenze aggiuntive per abilitare qualche funzionalità sullo storage primario o sbloccare porte in fibra sugli switch FC esistenti, la sostituzione di interfacce (NIC, HBA, CNA, ecc.), ulteriori moduli o dispositivi sugli apparati coinvolti (host, blade, switch, storage), l’eventuale upgrade delle licenze dell’ambiente di virtualizzazione, ecc.

9. Le attività di trasporto apparati, di installazione, di configurazione, di conversione e di migrazione policy, di formazione, di supporto tecnico, di assistenza allo “startup” e di messa in produzione della soluzione tecnologica, nelle sedi indicate dal committente, dovranno essere svolte da personale tecnico specializzato secondo quanto stabilito dal produttore originale degli apparati e rimangono totalmente a carico del fornitore, sempre da concordare preventivamente e sotto l’eventuale supervisione di personale tecnico del committente.

10. Si precisa ulteriormente che i servizi offerti dovranno comprendere: trasporto degli apparati nella sede, consegna, sballo, controlli, servizi di assemblaggio, inserimento e attivazione moduli aggiuntivi, montaggio dentro l’armadio a rack (anche fornitura dei necessari dadi e viti compatibili), collegamento di tuti i cablaggi necessari (e loro fornitura), prima installazione di base, attivazione degli apparati, configurazione di base, abilitazioni licenze e funzionalità, migrazione di tutti i nodi/sistemi attualmente sotto backup (o almeno di un sottoinsieme ritenuto significativo e adeguato dal committente), attività di test e di verifica della conformità hardware, software e della soluzione nella sua interezza, l’aggiornamento del firmware/microcode/middleware/software/sistema operativo di base a tutte le ultime versioni disponibili (compatibili con quello che sarà presente sulla restante infrastruttura e sistemi informatici dell’Ente) e tutto quanto altro necessario a rendere gli apparati/nodi ICT che compongono la soluzione stessa correttamente attivati, funzionanti, collaudabili e, successivamente, fruibili senza limitazioni dal sistema informatico dell’Ente.

11 - Sono a carico del fornitore, intendendosi remunerati con il corrispettivo contrattuale, tutti gli oneri e rischi relativi alla prestazione delle attività e dei servizi oggetto della presente fornitura.

12 - Il fornitore e il personale da questi impiegato sono obbligati ad osservare tutte le norme e le prescrizioni tecniche e di sicurezza in vigore, nonché quelle che dovessero essere successivamente emanate; gli eventuali maggiori oneri derivanti dalla necessità di osservare le norme e le prescrizioni di cui sopra, anche se entrate in vigore successivamente alla stipula del presente atto, resteranno ad esclusivo carico del fornitore, intendendosi in ogni caso remunerati con il corrispettivo contrattuale ed il fornitore non potrà, pertanto, avanzare pretesa di compensi a tal titolo, nei confronti del committente, assumendosene pertanto ogni relativa alea. Inoltre, il fornitore si obbliga a mallevare e tenere indenne il committente da tutte le conseguenze derivanti dalla eventuale inosservanza delle norme e prescrizioni tecniche, di sicurezza, di igiene e sanitarie vigenti.

13 - Con la sottoscrizione del presente atto, il fornitore dichiara di disporre e si obbliga ad avvalersi di risorse professionali e tecniche adeguatamente formate, competenti e specializzate in relazione alle prestazioni contrattuali dovute, nonché di adeguati mezzi, beni e servizi necessari per l’esatto adempimento delle obbligazioni assunte con il presente atto, e garantisce e dichiara, altresì, che l’attività oggetto del presente contratto costituisce ordinaria attività di cui al proprio oggetto sociale, e che è dotato di propria autonomia organizzativa e gestionale, capace di operare nel settore dei servizi in oggetto, come di fatto opera, con propri capitali, mezzi ed attrezzature.

Si riporta lo schema compilato e presentato in sede di gara dal fornitore; per i dettagli specifici si rimanda alla consultazione dell’offerta tecnica denominata “Tlc18njcato Rev1124102018.pdf”, quale parte integrante del presente contratto.

Art. 3.1 – Requisiti di MANUTENZIONE on-site e supporto obbligatori

1. Fa parte della presente fornitura anche la garanzia, la manutenzione hardware on-site e l’assistenza o il supporto tecnico con il produttore sull’intera soluzione fornita per un periodo pari almeno a 3 (tre) anni dalla data di verifica di conformità sulla soluzione con esito positivo); servizi e interventi eventualmente erogati, previsti e/o assicurati in collaborazione e, eventualmente, coinvolgendo il personale tecnico del fornitore con supervisione dei tecnici del committente.

2. Le obbligazioni che formano oggetto del servizio di garanzia e di manutenzione hardware on-site (livelli di servizio o SLA) riguardano le attività necessarie a mantenere o ripristinare il regolare funzionamento dei singoli sistemi offerti o della soluzione nella sua interezza, a fronte di guasti e malfunzionamenti hardware e di anomalie e disservizi software, e comprendono le seguenti caratteristiche minime e attività obbligatorie:

RM01 – rispettato - l’intervento sugli apparati che compongono la soluzione offerta dovrà essere effettuato rispettando quanto previsto dalle modalità operative e nella garanzia offerta direttamente dal produttore. Gli interventi si intendono sempre on-site ovvero presso la sede territoriale dove è effettivamente dislocato l’apparato, come comunicato e concordato con il personale dell’Ente;

RM02 – rispettato - l’analisi del guasto/anomalia e la riparazione dei sistemi, inclusa la fornitura delle parti, l’installazione dei componenti da sostituire a quelli guasti/difettosi e tutta la manodopera;

RM03 – rispettato - l’attivazione di questi servizi e il relativo supporto non esclude né limita in alcun modo al personale dell’Amministrazione la possibilità di accedere ai sistemi la cui manutenzione/assistenza è prevista in questa fornitura;

RM04 – rispettato - l’eventuale sostituzione e/o riparazione di componenti difettosi o guasti dovrà avvenire a cura dell’impresa fornitrice (o direttamente dal produttore) con parti e/o componenti, nuovi o rigenerati/ricondizionati, ma solo se certificati dal vendor, dello stesso produttore di quelli sostituiti o, in caso di non reperibilità, previo avviso scritto e approvazione da parte del committente, con parti garantite equivalenti o migliorative e assolutamente compatibili con l’apparato che le ospita;

RM05 – rispettato - “semplici” sostituzioni a caldo delle parti/moduli hot-swap guasti, quindi ad esempio di dischi fissi (HDD/SSD) presenti sull’apparato, di alimentatori, di ventole o di singole interfacce SFP/SFP+ potranno essere concordati ed effettuati direttamente dal personale tecnico del Comune, ma rimane in carico a produttore e fornitore la spedizione degli stessi presso la sede dove è presente l’apparato. Nel caso di problematiche non superabili anche per questa tipologia di operazioni, si dovrà operare alla loro risoluzione in sede se così richiesto dai tecnici del committente;

RM06 – rispettato - i componenti guasti sostituiti verranno normalmente ritirati dal fornitore ed eventualmente, se concordato, procederà l’Ente al loro normale smaltimento. Nel caso di ritiro da parte del fornitore, fanno eccezione le memorie di massa; infatti nel caso in cui un dispositivo di memoria di massa (hard disk drive, flash, microSD, …) debba essere sostituito a causa di un guasto o malfunzionamento, il servizio si intende comprensivo del tentativo on-site di recupero dati, se richiesto dal committente. Inoltre, in applicazione della normativa vigente, vista la possibile presenza di dati personali e/o sensibili del cui trattamento il committente è titolare, la memoria elettronica potrà essere ritirata dal fornitore solo su espressa autorizzazione dei tecnici del Comune, previa verifica della completa e totale impossibilità di rileggerne i dati;

RM07 – rispettato - qualsiasi richiesta di intervento aperta entro la scadenza del periodo di manutenzione della presente fornitura dovrà in ogni caso essere risolta o chiusa, sempre con parere positivo dell’Ente, anche se si protrarrà nei mesi successivi;

RM08 – rispettato - qualora, a causa della sostituzione di periferiche e/o dispositivi interni (scheda madre, modulo interno, interfaccia di rete, disk controller, GBIC, HDD, SSD, ecc.), si rendesse necessaria anche l'installazione o l’aggiornamento di specifiche componenti software/firmware/microcode questa attività deve ritenersi inclusa nel servizio;

RM09 – rispettato - a fronte di ogni intervento effettuato per l’esecuzione dei servizi oggetto dell’appalto, dovrà essere prodotto un rapporto d’intervento, anche in forma digitale o reperibile direttamente dal committente tramite il sistema on-line CRM o di ticketing messo a disposizione.

3. La formula utilizzata per gli interventi on-site sull’hardware in garanzia o in manutenzione oltre alle tempistiche inerenti assistenza e supporto tecnico deve prevedere un tipo di servizio con specifiche di Service Level Agreement (SLA) non inferiori rispetto a quelle sotto riportate e, nel caso il produttore preveda solo qualcosa di peggiorativo, rimangono in carico al fornitore tutte le necessarie attività, operazioni e orari da assicurare per la copertura di quanto non coperto dal produttore:

RM10 – rispettato - la disponibilità del servizio di garanzia/manutenzione hardware e di assistenza/supporto tecnico (anomalie, problemi software, malfunzionamenti, ecc.) sulla soluzione offerta (sistemi, apparati ICT e software di gestione) dovrà essere garantito da lunedì a venerdì (giorni feriali) con inizio dalle ore 09:00 fino alle ore 17:00 (nove-diciassette, durata di otto ore), se non prevista dal produttore, la “parte di compensazione” rimane comunque in carico al fornitore per la durata contrattuale;

RM11 – rispettato - si intende per “tempo di presa in carico” o “tempo di risposta” il periodo, espresso in ore lavorative secondo il modello orario sopra richiamato, che intercorre fra la segnalazione del problema da parte del personale dell’Ente e la comunicazione all’Amministrazione almeno della “diagnosi iniziale” e della stima/previsione fatta del tempo necessario a completare l’intervento (ovverosia a risolvere il problema):

a) in caso di malfunzionamenti bloccanti, l’intervento deve avvenire entro 4 (quattro) ore lavorative dalla segnalazione. Occorre precisare che per “guasto o anomalia bloccante” si intende una indisponibilità del sistema nel suo complesso per erogare i servizi richiesti, quindi avendo richiesto espressamente una configurazione che presenta moduli e funzioni ridondate o clustering di sistemi, il disservizio deve in qualche modo coinvolgere contemporaneamente più apparati e arrivare a compromettere completamente specifiche funzioni (backup, restore) o creare disservizi generalizzati (assenza connettività sugli apparati, storage indisponibile, ecc.);

b) in caso di malfunzionamenti non bloccanti e altre problematiche in genere, l’intervento deve essere effettuato o almeno iniziato entro il giorno lavorativo successivo (NBD) a quello della segnalazione;

RM12 – rispettato - si intende per “tempo di ripristino” o “tempo di intervento” il periodo, espresso in ore o giorni lavorativi secondo il modello orario sopra richiamato, che intercorre fra la segnalazione del problema da parte dell’Amministrazione e l’intervento con ripristino definitivo, o almeno parziale se approvato dal committente, delle condizioni normali di operatività dell’apparato in manutenzione o dell’intera soluzione:

a) in caso di problematiche che riducano in modo grave l’uso o compromettano in modo critico le funzionalità del sistema nel suo complesso (malfunzionamenti bloccanti), si deve provvedere al suo ripristino, o a porre in atto un adeguato work-around di natura temporanea e in ogni caso preventivamente concordato e approvato dal committente, entro il secondo giorno (2°) lavorativo successivo a quello della segnalazione;

b) in caso di problematiche che riducano solo in modo lieve la produttività, le prestazioni o per qualsiasi altra richiesta di assistenza e di supporto riguardante gli apparati in manutenzione (malfunzionamenti non bloccanti e altre anomalie e problematiche in genere) si deve provvedere al ripristino entro il quinto (5°) giorno lavorativo successivo a quello dell’apertura della segnalazione.

4. Il livello di servizio base descritto spesso rientra in varianti della nota formula “8x5x4” e sarà in ogni caso la denominazione adottata nel presente capitolato per fare riferimento agli SLA minimi richiesti.

RM13 – rispettato - una volta conclusa la procedura e aggiudicata la fornitura, i canali da utilizzare (PEC, numero verde, e-mail, web-ticketing, sistema di gestione CRM del fornitore approvato dal committente, ecc.) e le modalità o il workflow per i contatti tra committente, fornitore e il produttore saranno concordati direttamente tra le parti. Si precisa che l’apertura e/o chiusura del ticket con il vendor dell’apparato potranno avvenire sia direttamente da personale del Comune di Firenze che della ditta fornitrice, quest’ultima sempre in accordo con i tecnici dell’Ente ai quali dovrà garantire comunque un eventuale supporto per collaborare nella positiva risoluzione e conclusione dell’intervento, se espressamente richiesto dai tecnici dell’Ente e se sono rilevate carenze con il produttore finale. Come riferimento iniziale, fatto salvo i successivi accordi tra le parti, la mail dell’Ente a cui fare riferimento sarà: monitordataps AT xxxxxx.xx.xx

RM14 – rispettato - vista la delicatezza della soluzione tecnologica oggetto della fornitura e considerato che possibili fraintendimenti durante le attività di configurazione e gestione potrebbero comportare gravi malfunzionamenti, anomalie o disservizi, si richiede che l’assistenza e il supporto, oltre agli eventuali interventi in sede, siano condotti ed erogati tramite personale tecnico di lingua italiana.

Art. 3.2 – Requisiti di HARDWARE obbligatori minimi

1. La soluzione tecnologica definita e realizzata dal fornitore deve prevedere e soddisfare complessivamente (salvo diversa indicazione) tutte le seguenti caratteristiche HARDWARE per garantire i livelli minimi stimati di ridondanza, di affidabilità e di connettività di rete:

RH01 – previsti 4U- form factor 19” rack-mountable, massimo complessivo 16 U (sedici unità rack) con slitte/staffe comprese nella fornitura. Cioè tutto quanto andrà a comporre la soluzione tecnologica presentata dal fornitore (apparati ICT, moduli, server, host, eventuali switch FC, storage, ecc.) sarà vincolato a tale dimensione e non potrà richiedere od occupare ulteriore spazio negli armadi rack di alloggiamento indicati. Il requisito risponde sia a carenza di spazio registrata negli armadi della futura sala DR, ma anche per lasciare adeguato spazio per una futura espandibilità. Per la tipologia di armadi si rimanda a quanto già indicato nel presente Capitolato;

RH02 – previsti 640GB - memoria complessiva di tutta la soluzione non inferiore ai 256 GB (duecentocinquantasei), si intende la cosiddetta RAM, che la soluzione offerta prevede conteggiando tutti gli apparati;

RH03 – rispettato - totale assenza di single-point-of-failure (SPoF) “intra-soluzione”, vincolo da rispettare su qualsiasi apparato “core” che la compone. A titolo esemplificativo e non esaustivo, in quanto chiaramente può variare in base alla soluzione tecnologica presentata dal fornitore:

a) alimentatori ridondati hot-plug per singolo apparato distinto previsto che andrà a comporre il sistema finale offerto, entrambi presenti e almeno AC 110-230V 50/60Hz;

b) ridondanza di tutta la connettività di networking (o eventualmente fibre channel) interna;

c) ridondanza di tutti i sistemi di raffreddamento e/o ventilazione degli apparati;

d) ridondanza dell’apparato/nodo/sistema che eroga i servizi di archive/backup/restore;

e) ridondanza dei controller presenti sullo storage offerto e, se distinto per le due funzioni di

archive/backup/restore e DR-support, deve essere assicurata su entrambi gli storage;

f) ridondanza di tutta la connettività verso gli host del cluster DR che infatti dispongono già di multiple schede di rete (ethernet) e doppie porte HBA (fibre channel), a seconda della soluzione di storage offerta dal fornitore.

RH04 – previsti numero 16 SFP+ 10G e numero 16 SFP+ 10G - numero 4 (quattro) interfacce 10 GbE SFP+ con 4 (quattro) moduli SFP+ 10G SR presenti e attivi/licenziati per singolo apparato distinto e previsto che andrà a comporre il sistema finale. Viene fatto esplicito riferimento agli apparati della soluzione offerta che avranno funzionalità di interfacciamento con gli altri sistemi, server e dispositivi ICT del committente, quindi da “contatto verso l’esterno della soluzione tecnologica o extra-soluzione”, quindi per gestire le connessioni, lo scambio e il trasferimento dati elettronici da proteggere oltre all’accesso allo storage per il DR-support (se si utilizza un protocollo ethernet-based). Si fa presente che il committente metterà a disposizione massimo numero 20 (venti) interfacce 10 GbE SFP+ sui propri core switch di rete per l’interconnessione della soluzione offerta dal fornitore, precisamente 10 (dieci) interfacce per core switch distinto, questo per assicurare contemporaneamente ridondanza e fault-tolerance su tutta la connettività ethernet per la futura Data Protection Solution;

RH05 – previsti numero 8 ingressi RJ45 da 1G - numero 2 (due) interfacce 1 GbE RJ45 presenti e con tutte le funzionalità attivate per le connessioni IPMI (Intelligent Platform Management Interface, con le funzioni attive di out-of-band management & monitoring) per singolo apparato distinto e previsto che va a comporre il sistema finale. A seconda del produttore generalmente

queste interfacce integrate sono denominate Dell Remote Access Control (iDRAC), IBM Integrated Management Module (IMM), HP Integrated Lights-Out (ILO), Baseboard Management Controllers (BMC), ecc.;

RH06 – previsti 3.2 TB raw flash e 144 TB raw capacitivi - presenza di storage misto sulla soluzione offerta con dischi prestazionali (ad esempio tecnologia flash/SSD) e dischi capacitivi (meccanica rotativa) per garantire aspetti evoluti, trasparenti e automatizzati di tiering, Hierarchical Storage Management (HSM), buffering & caching, ecc. Come dato obbligatorio minimo, a prescindere da quanto possano essere efficienti e ottimizzati gli algoritmi di compressione e deduplica supportati dalla soluzione di protezione offerta, complessivamente devono essere installati e attivi almeno 3,0 TB (tre) raw con dischi prestazionali e almeno 120 TB (centoventi) raw con dischi capacitivi. Per “raw” si intende lo spazio grezzo fornito dal sistema stesso, senza alcuna configurazione di fault-tolerance o di ridondanza in essere.

Se sono offerti storage distinti per gestire le funzioni di archive/backup/restore rispetto al DR- support, non viene richiesto di duplicare i valori appena indicati, ma un adeguato dimensionamento “maggiore” rimane responsabilità del fornitore per consentire la protezione di tutti i dati e, in ogni caso, entrambi gli storage devono obbligatoriamente prevedere una combinazione tra dischi prestazionali (dimensione ridotta) e capacitivi (quasi tutto il totale) per assicurare performance e tempi di risposta adeguati;

RH07 – previsti 90 TB capacitivi - sempre come dato obbligatorio minimo, a prescindere da quanto possano essere efficienti e ottimizzati gli algoritmi di compressione e deduplica supportati dalla soluzione di protezione offerta, lo storage per memorizzare i salvataggi (al netto degli algoritmi di protezione, di ridondanza e di fault-tolerance applicati) non deve risultare inferiore ai 90 TB (novanta) utili capacitivi. Un corretto dimensionamento in tal senso rimane a carico del fornitore in quanto per lo stesso non è possibile specificare questo valore che necessariamente risulta intimamente e tecnicamente legato alle caratteristiche proprie della “Data Protection Solution” offerta, alle relative risorse computazionali presenti, alla tipologia di deduplica supportata, agli algoritmi di compressione e al relativo ratio conseguito, ecc. Rimane chiaramente il vincolo che la soluzione deve essere in grado di ospitare tutti i dati attualmente ospitati nei backup secondo le politiche indicate e tutte le vm presenti in elenco, cioè quanto già riportato in narrativa;

RH08 – rispettato - funzionamento con temperatura certificata almeno nel range 10-35° C (intervallo dieci-trentacinque gradi), equivalentemente 50-95° F, e umidità relativa standard (10%- 90%) senza condensa, di ogni singolo apparato offerto che compone la soluzione finale (si precisa che mediamente nella sala che ospiterà gli apparati si registrano valori ambientali costanti nell’intervallo di 20-25 gradi centigradi);

RH09 – rispettato - fornitura di tutti i GBIC, cavetti e i cablaggi necessari a corredo (alimentazione, rete, eventuale fibra, KVM, ecc.), delle lunghezze adeguate una volta collocati gli apparati nei rack. Per una stima iniziale si può considerare lunghezze sui 5 (cinque) metri anche se tale valore non è in alcun modo vincolante per il committente. Inoltre, anche tutti i dadi, viti, staffe, adattatori, ecc. e tutto quanto dovesse poi risultare necessario per consentire di alloggiare i nuovi apparati ICT offerti nei rack dell’Ente rimane completamente a carico del fornitore e nessuna ulteriore spesa o costo può essere imputato al Comune per rispondere a tale requisito.

Art. 3.3 – Requisiti di LICENZE, performance minime e norme obbligatorie

1. La soluzione tecnologica definita e realizzata dal fornitore deve prevedere e soddisfare complessivamente le seguenti caratteristiche minime di LICENZE e performance, per supportare e fornire al meglio i propri servizi di protezione dati:

RL01 – rispettato - nessuna limitazione o vincoli di impiego esistenti per l’uso della capacità computazionale o delle risorse già presenti nella soluzione offerta (numero CPU, numero socket/core, quantità di RAM, quantità di storage, velocità e tipologia networking); ad esempio con blocchi o limiti sulla quantità di dati espressa in GB, TB, PB, ecc. o alla tipologia di dati protetti, ai DBMS coinvolti o ancora al numero di sistemi ICT (client/server fisici, macchine virtuali, desktop, NAS, singoli DBMS, ecc.) oggetto di data archive, backup e recovery.

NB: se ciò non fosse possibile per la particolare modalità di licenza della soluzione offerta allora devono essere in ogni caso attivati, gestiti e coperti dalla licenza offerta i seguenti valori e parametri:

a) almeno 200 TB (duecento) di dati digitali, facendo riferimento ai dati presenti nei nodi sorgente protetti dal sistema DPS offerto. Quindi si intende il totale di dati elettronici ospitati nei backup al netto di eventuali copie di riserva e/o di copie secondarie (anche in cloud), conteggiando invece tutte le versioni e il periodo di presenza nei backup stessi (versioning & retention), sommando anche i dati protetti in modalità archive e senza prevedere alcun beneficio dall’eventuale attivazione e dall’uso di funzioni a disposizione della soluzione proposta, quali deduplica e compressione;

b) almeno 550 (cinquecentocinquanta) sistemi ICT o nodi sorgenti protetti. Come nodi attualmente si intendono indifferentemente server fisici, macchine virtuali, eventuali desktop client, workstation, portatili, laptop, file-server della tipologia NAS, singoli DBMS, ecc. ma la soluzione offerta potrebbe conteggiare gli oggetti in modo differente, pertanto si vedano anche tutti i punti elenco seguenti;

c) almeno 60 (sessanta) socket per gli host di virtualizzazione VMware (hypervisor host), se occorre licenziare contemporaneamente il cluster di produzione e quello di DR, altrimenti 44 (quarantaquattro) socket per i soli host del cluster di produzione;

d) almeno 30 (trenta) apparati fisici ulteriori, escludendo dal computo gli hypervisor host e contando i server fisici dual-socket (vendor Acer, IBM, HP, Dell) e degli storage con funzionalità di file-server della tipologia NAS (entry or middle level) generalmente sistemi prodotti dal vendor Synology.

e) le attuali licenze denominate “IBM Spectrum Protect Suite Terabyte – Annual SW Subscription & Suppor Renewal” sono licenziate e rinnovate dal committente fino al 31/12/2019 compreso; nel caso il fornitore abbia basato la propria soluzione tecnologica coinvolgendo tale suite di prodotti, anche ampliandola, deve prevedere i costi dei relativi rinnovi per il triennio successivo alla data di verifica di conformità superata con esito positivo o per fino a coprire tutto il periodo di durata aggiuntiva indicato nell’offerta presentata.

2. Si evidenzia come i valori sopra indicati siano superiori alle necessità immediate in ambito di dati digitali sorgenti da proteggere e di infrastruttura di virtualizzazione del committente. Questo è voluto per consentire all’Ente una crescita autonoma, senza vincoli e senza ulteriori costi da sostenere, almeno per i primi anni di utilizzo; mentre si precisa che per gli altri apparati fisici si tratta di ambienti “residuali” e progressivamente in via di eliminazione o di riduzione nel corso dei prossimi anni, almeno a livello numerico;

RL02 – rispettato - nessuna limitazione prestazionale o vincoli di licenze sulla soluzione tecnologica offerta; ad esempio con blocchi o limiti di uso legati alla quantità di dati espressa in GB, TB, PB, ecc. o alla tipologia di dati protetti, al numero di host utilizzati o ancora al numero di sistemi ICT (macchine virtuali o vm e desktop o postazioni client virtualizzate) per cui si prevede la copertura e le funzionalità di DR-support.

NB: se ciò non fosse possibile per la modalità di licenza della soluzione offerta, si veda quanto già precisato nel requisito precedente;

RL03 – rispettato - tutti i sistemi, l’hardware e i software che compongono la stessa piattaforma di “Data Protection Solution/Suite/Software” devono essere già licenziati, completi e attivati per rispondere compiutamente a tutti i requisiti e le funzionalità richiesti nel presente capitolato;

RL04 – rispettato - fornitura dei servizi di garanzia, di manutenzione on-site, di aggiornamenti firmware, middleware e software pertinenti, di assistenza e di supporto tecnico, anche remoto, su anomalie e problematiche, guasti e funzionalità della soluzione tecnologica offerta per una durata contrattuale di almeno 3 (tre) anni dalla verifica di conformità superata con esito positivo;

RL05 – rispettato - piena conformità degli apparati con la normativa vigente, italiana e comunitaria, in tutti gli ambiti pertinenti come emissioni elettromagnetiche, sicurezza negli ambienti di lavoro, emissioni sonore, manualistica obbligatoria fornita a corredo, ecc. A titolo esemplificativo e non esaustivo possiamo ricordare almeno le seguenti, precisando che alcune sono parzialmente sovrapponibili:

a) ElectroMagnetic Compatibility (EMC/EMI) certifications (FCC, CE, VCCI);

b) Safety (UL/cUL, CB);

c) Criteri Minimi Ambientali (CAM) per la fornitura di “Apparecchiature elettriche ed elettroniche per ufficio” di cui al Decreto 13 dicembre 2013 (G.U. n. 13 del 17 gennaio 2014) - Aggiornamento 2013 - Allegato 2.

RL06 – rispettato - conformità degli apparati/nodi offerti, per tutti gli aspetti di pertinenza, in ambito sicurezza informatica, di privacy e trattamento dei dati con quanto eventualmente previsto in tale ambito dal “General Data Protection Regulation” (o GDPR), cioè dal regolamento europeo n. 679 del 2016.

Art. 3.4 – Requisiti di SISTEMA obbligatori minimi

1. La soluzione nel suo complesso, in base alla configurazione prevista e offerta, deve prevedere tutte le seguenti caratteristiche di SISTEMA completamente attivate e abilitate, già totalmente licenziate e rispondenti a quanto richiesto in fornitura, senza limitazioni ulteriori od oneri aggiuntivi per l’Ente:

RS01 – rispettato - funzioni e piena compatibilità con il protocollo standard TCP-IP (IPv4 e IPv6) per le funzionalità di trasferimento dati e interfacciamento con gli altri apparati ICT dell’infrastruttura informatica, eventualmente anche per collegamento a servizi cloud-based;

RS02 – rispettato - supporto attivo e piena compatibilità con lo standard jumbo frames, almeno fino a 9.000 (novemila) bytes per tutte le connessioni di rete degli apparati/nodi componenti la soluzione per la connettività “esterna” con i restanti apparati di rete già presenti e gestiti dal committente;

RS03 – rispettato - compatibilità delle funzioni richieste (archive, backup, restore) per gestire anche intere macchine virtuali (vm) a prescindere dal sistema operativo ospite o, internamente ad esse per il relativo filesystem, con tutti i sistemi operativi x86 e a 64 bit più recenti;

RS04 – rispettato - caratteristiche adeguate a supportare i DBMS della famiglia Oracle e interfacciamento con le funzioni specifiche denominate “target Recovery Manager (RMAN)”;

RS05 – rispettato - funzioni e algoritmi di compressione e deduplica dati salvati nell’area di memorizzazione interna alla soluzione, o su spazio storage in cloud, già attivi e licenziati, senza limiti di utilizzo, trasparenti nella gestione dei dati stessi e automatizzati/automatizzabili dagli operatori;

RS06 – rispettato - funzioni e supporto per configurare aree multiple di destinazione dei dati di archive e backup (i cosiddetti pool in ambito IBM Spectrum Protect suite o genericamente i backup target), quali storage locale, ambienti cloud, spazio archiviazione di rete esterno (ad esempio tramite protocolli NFS, iSCSI, ecc.) attivabili e utilizzabili contemporaneamente e in modalità gerarchica o “a cascata” anche in base a impostazioni, soglie, regole e politiche configurabili dagli operatori;

RS07 – rispettato - supporto nativo del protocollo aperto di cloud object-storage denominato:

OpenStack Swift over HTTPS

e compatibilità con almeno un altro vendor tra i seguenti più diffusi e di interesse per l’Ente:

a) Amazon Simple-Storage-Service (S3);

b) Microsoft Azure Blob Storage;

c) Google Cloud Storage;

d) IBM Softlayer;

e) Oracle Cloud.

Si ricorda che è interesse del committente sperimentare e poi utilizzare tali funzionalità, quindi tale requisito è assolutamente imprescindibile;

RS08 – rispettato CIFS/SMB v3 e NFS v3 - funzioni per l’utilizzo e l’accesso allo storage presente sulla soluzione ed eventualmente a quelli remoti, quindi per/verso altri apparati e sistemi ICT (ovviamente si pensi anche agli host che compongono il cluster DR stesso), tramite connessione TCP-IP con almeno 2 (due) standard e versioni tra i seguenti protocolli:

a) Common Internet File System/Server Message Block (CIFS/SMB) almeno v3;

b) iSCSI (Internet Small Computer Systems Interface);

c) NFS (Network File System) almeno v3.

Si ricorda che il cluster DR, cioè quello composto dagli host messi a disposizione del fornitore da parte del Comune, non ha storage dove ripristinare, ospitare, mandare in esecuzione e tenere accese delle vm in situazione di DR, quindi tale funzione è assolutamente imprescindibile;

RS09 – rispettato - la soluzione offerta deve garantire l’accesso alla console di gestione, tutte le funzionalità di restore dati e, sfruttando eventualmente gli host del cluster DR in base al progetto presentato, le caratteristiche proprie di DR-support (storage, ripristino e registrazione per accendere vm) anche nel caso di disastro o grave malfunzionamento strutturale che comporti la totale indisponibilità del cluster principale VMware di virtualizzazione, cioè dell’ambiente dove sono ospitati i dati sorgente e dove sono in esecuzione tutte le vm di produzione;

RS10 – rispettato tramite la modalità di restore del contenuto delle VM - la soluzione tecnologica offerta deve continuare a garantire l’accesso alla console di gestione per tutte le funzionalità di restore dati nella condizione estrema di totale e contemporanea indisponibilità di entrambi i cluster di virtualizzazione (si intende fare riferimento ad assenza completa di host VMware), quindi sia di quello di produzione che di quello previsto per il DR, consentendo il ripristino dati. Tale restore può avvenire sull’ulteriore storage previsto in offerta per il cluster DR oppure su altri NAS attivati in emergenza o ancora via rete in remoto su alcune postazioni degli operatori stessi;

RS11 – rispettato - totale assenza di backdoor ovvero qualsiasi modalità di accesso, di monitoraggio e di gestione, sia locale che remota, deve essere resa nota e gestibile al personale del committente (per eventuale disattivazione, restrizione, cambio password, ecc.). Richiesta anche la totale assenza di modalità attivate e nascoste, celate od offuscate di comunicazione, di tracciamento dell’utilizzo e di controllo remoto del sistema stesso, se non appunto preventivamente rese note e autorizzate dal committente. Considerata la criticità del sistema e la sua primaria funzione di proteggere i dati (pubblici, privati, personali e/o sensibili) e i relativi aspetti inerenti la sicurezza informatica, l’eventuale futura scoperta di natura pubblica (siti Internet specializzati, forum sulla cybersecurity, Wikileaks, xxxxxxxxxxxx.xx, ecc.), nel corso di tutta la durata della fornitura, dell’esistenza di una tale modalità di comunicazione e/o accesso sul sistema tenuta segreta al

personale dell’Ente, quindi la presenza di una grave vulnerabilità e/o di una modalità di bypassare la sicurezza stessa del sistema e/o di accedervi a insaputa del committente, costituisce grave e dolosa inadempienza contrattuale e, pertanto, può essere motivo di risoluzione unilaterale oltre alla possibilità di piena rivalsa nelle sedi legali, considerando responsabili il fornitore ed eventualmente il produttore del sistema. A seguito della scoperta pubblica o da parte del personale dell’Ente di una eventuale backdoor o di un sistema occulto di accesso e/o tracciamento, sono fattori mitiganti ed è in ogni caso fatto obbligo al fornitore consegnare gratuitamente, in un tempo massimo di giorni indicato dall’Ente, tutti gli strumenti necessari per rimuovere tale vulnerabilità (firmware, software, istruzioni di disattivazione, ecc.) oltre a fornire delle evidenze oggettive (logging, analisi di soggetti terzi indipendenti, dimostrazioni oggettive, ecc.) dell’eventuale utilizzo limitato di tale funzione o, anche, che in realtà tale funzione non è mai stata utilizzata su nessuno dei sistemi e apparati oggetto della fornitura.

RSLR – rispettato - È inoltre un requisito obbligatorio minimo, prevedere delle funzioni di logging, di registrazione e analisi delle anomalie, di calcolo indici prestazionali, di produzione statistiche sulle schedulazioni e di reportistica evoluta sulle funzioni previste, interattive e possibilmente in tempo “quasi” reale rispetto alle operazioni e alle attività in corso sugli apparati/nodi, sia quello corrente che storico collezionato nei log stessi. Si parla in generale di funzionalità dinamiche e flessibili, ad esempio in base a filtri, schedulazioni varie, soglie di segnalazione automatica o configurate, di ricerche e impostazioni personalizzabili dall’operatore, necessariamente associate con le caratteristiche e le funzionalità attive nella soluzione offerta, pertanto sicuramente senza alcuna limitazione rispetto ai requisiti minimi previsti dal capitolato.

2. La soluzione tecnologica offerta deve prevedere una modalità automatica di protezione in caso di carenza di spazio ad esempio sovrascrittura dei log più vecchi, se esiste appunto un vincolo sullo spazio disponibile o sullo spazio utilizzabile in base alla configurazione realizzata, e delle funzioni di esportazione dei log raccolti oltre a produrre delle segnalazioni preventive quando lo spazio dedicato a tale funzionalità è prossimo a esaurimento o vengono superate soglie impostate in tal senso dagli operatori. Questo per rispondere alla normativa vigente e per esigenze precise di conservazione storica, per diagnosi sulle anomalie, per analisi di tipo forense e per evitare possibili perdite nei dati di log che invece ci si aspetta di collezionare.

3. Nelle funzioni di monitoraggio e allerta (proattiva e/o reattiva) devono essere previste anche quelle di impostazioni di segnalazioni e di allarmi al raggiungimento di varie soglie o valori predefiniti sempre sull’andamento dei backup, sullo spazio disponibile, sui fallimenti nelle schedulazioni, ecc. oltre a quelle inerenti possibili anomalie e/o guasti che si presentino sull’apparato o sui nodi dello stesso, ad esempio un disco interno o un alimentatore “in fail” e situazioni similari. In tali ambiti devono essere supportati i protocolli di segnalazione Simple Network Management Protocol (SNMP) e messaggio su posta elettronica standard (SMTP).

RSMM – rispettato - È inoltre un requisito obbligatorio minimo il rispetto completo di quanto previsto nel documento di "Misure minime di sicurezza ICT per le Pubbliche Amministrazioni" (aggiornato al 26 aprile 2016 al momento di redazione del presente documento o di quello più recente disponibile al momento di presentazione dell’offerta) emanato da AgID per tutte le voci e le caratteristiche di stretta pertinenza e attinenza con la soluzione tecnologica offerta e gli apparati/nodi forniti per le misure che rientrano nella classificazione “Minima”. Tale aspetto, quindi almeno tutte le misure pertinenti con il sistema offerto, dovrà essere riportato nel “Piano di Progetto Definitivo”. A

titolo meramente esemplificativo e non esaustivo, si riporta come esempio che gli apparati proposti devono essere sicuramente aderenti a misure quali:

- 5.7.1 “Quando l’autenticazione a più fattori non è supportata, utilizzare per le utenze amministrative credenziali di elevata robustezza (e.g. almeno 14 caratteri)”

- 5.10.1 “Assicurare la completa distinzione tra utenze privilegiate e non privilegiate degli amministratori, alle quali debbono corrispondere credenziali diverse.”

mentre non sono considerati pertinenti per la tipologia di apparati offerti e in base all’utilizzo che ne viene richiesto misure quali:

- 2.1.1 “Stilare un elenco di software autorizzati e relative versioni necessari per ciascun tipo di sistema, compresi server, workstation e laptop di vari tipi e per diversi usi. Non consentire l’istallazione di software non compreso nell’elenco.”

- 8.7.3 “Disattivare l’apertura automatica dei messaggi di posta elettronica.”

- 13.8.1 “Bloccare il traffico da e verso URL presenti in una blacklist.”

Art. 3.5 – Requisiti di PROTEZIONE e sicurezza obbligatori minimi

1. Il sistema nel suo complesso, in base alla configurazione prevista e attivata dalla soluzione offerta, deve prevedere le seguenti caratteristiche di PROTEZIONE sui dati elettronici completamente attivate, già totalmente licenziate e rispondenti a quanto richiesto in fornitura, senza limitazioni ulteriori od oneri aggiuntivi per l’Ente:

RP01 – rispettato - funzioni per il supporto al DR semiautomatico o almeno manuale ovverosia recupero il più possibile istantaneo e sicuramente integro, corretto e consistente delle vm oltre a loro registrazione e attivazione controllata su altro cluster di virtualizzazione (rispetto al primario in produzione, cioè sul cluster DR) direttamente dallo storage presente sulla soluzione offerta (può essere distinto dallo storage di archive/backup). Sono sottintesi e ammessi interventi e operazioni manuali svolte dagli operatori e dai tecnici coinvolti per completare alcune parti delle attività appena indicate, quindi una funzione non completamente automatizzata. Per soluzione “autonoma e auto-contenuta”, si intende senza necessità di ulteriori software e moduli o apparati ICT aggiuntivi (quali storage, balancer, server, ecc.) da predisporre, fornire o utilizzare da parte del committente, eccetto gli apparati di networking per la connettività (LAN), il vCenter e gli host dell’hypervisor per le sole risorse computazionali e di memoria (CPU e RAM) che costituiranno il cluster DR. Sono esclusi esplicitamente dal supporto delle funzionalità di DR i sistemi e i server della “tipologia fisico” ancora presenti nell’Ente, ma non dal pieno supporto e dalle funzioni di backup e di restore;

RP02 – rispettato - il supporto al DR presentato deve essere esaustivo in riferimento all’elenco completo delle vm allegato al presente Capitolato Speciale, quindi lo storage offerto nella “Data Protection Solution” deve essere adeguato come dimensionamento e prestazioni, considerando ovviamente che si sta parlando di una situazione di emergenza e le risorse messe a disposizione dal committente sono minori rispetto all’ambiente di produzione. Si sottolinea che gli unici vincoli tollerati che potranno presentarsi, nel caso fosse necessario riaccendere tutte le vm del cluster di produzione, possono essere legati a “insufficienze computazionali” degli host costituenti il cluster DR (se utilizzati esclusivamente quelli messi a disposizione dal Comune), pertanto a carenze di CPU e RAM, e non a fattori ostativi causati da limiti dello storage (quali di performance o problemi di “boot storm”) o dalle funzioni di DR-support presenti nella soluzione tecnologica stessa;

RP03 – rispettato - la soluzione offerta deve assicurare almeno tutte le funzionalità che l’attuale suite di backup/restore fornisce e che sono state illustrate nella Relazione Tecnica allegata. Quindi a titolo esemplificativo e non esaustivo prevedere politiche differenziabili e puntuali, con granularità a livello di vm e anche di singolo file, per la retention (quantità di tempo per cui un insieme di dati è disponibile per il ripristino), il versioning (numero di versioni conservate di tali dati) degli oggetti salvati nei backup, retain of last file version, il journaling (identificazione immediata e tracciamento dei soli file modificati), comandi verso il sistema di backup e funzioni di scripting per automatizzare certe operazioni schedulate o batch anche lato nodo sorgente, la quantità di dati trasferibili durante i backup giornalieri e il numero di nodi protetti. È obbligatorio che la soluzione possa garantire la capacità di ospitare tutti i 130 TB (centotrenta) di dati attualmente salvati senza applicare deduplica, ma con compressione attiva ovverosia circa 200 TB (duecento) sorgente “grezzi”;

RP04 – rispettato - funzioni disponibili per cifrare tutti i dati prima della loro memorizzazione e gestione anche sui servizi cloud esterni, sfruttando chiavi a 128 bit (centoventotto) o superiori e tramite almeno 1 (uno) algoritmo standard di crittografica tra Advanced Encryption Standard (AES), Arcfour (RC4), Blowfish, GOST, Serpent, Twofish e International Data Encryption Algorithm (IDEA) e 3-DES;

RP05 – rispettato - autenticazione utenti Single-Sign-On (SSO) con sistemi quali Active Directory (Microsoft Windows versioni 2012/2016 e la successiva che sarà rilasciata a breve da Microsoft) e generico LDAP, si intende di tipo non esclusivo ovverosia la possibilità che siano attive anche più modalità contemporanee o almeno con possibilità di autenticazione a cascata, in

base alle impostazioni, sugli altri sistemi o su utenze locali definite sull’apparato in caso di anomalie, irraggiungibilità o disservizi vari del servizio di autenticazione esterna;

RP06 – rispettato - funzioni integrate e trasparenti per il supporto (almeno manuale) al DR compatibili ed erogabili con la piattaforma centralizzata basata sull’hypervisor VMware vSphere dell’Ente (private cloud) dalla versione 6.0 e superiori. Si precisa che tali funzionalità dovranno essere obbligatoriamente garantite fino almeno alla versione 7.x di VMware vSphere o anche per versioni successive se fossero rilasciate nel corso della durata contrattuale della fornitura;

RP07 – rispettato - funzioni evolute e abilitazione per il pieno supporto delle API VMware per l’integrazione completa e trasparente con sistemi VMware vCenter e vSphere ESX dalla versione

6.0 e superiori (obbligatoriamente fino almeno alla 7.x o superiori se rilasciate nel corso della durata contrattuale). Si parla di funzioni quali, a titolo esemplificativo e non esaustivo autodiscovery host, vm & applications, identificazione vm non protette da backup, registrazione di vm ripristinate, controllo degli snapshot, ecc. o anche tramite specifici plug-in di integrazione che la soluzione prevede per la console stessa del vCenter;

RP08 – rispettato - funzioni di backup e restore per intera vm, sia per sistemi operativi recenti (x86 & 64bit based, quali Microsoft Windows e varie distribuzioni Linux) che per quelli obsoleti o desupportati dal produttore stesso, quali ad esempio Microsoft Windows 2003, XP, Vista, … o Linux basato su distribuzioni Red Hat, Debian e CentOS versioni 4/5 ovverosia con kernel versioni 2.x.

RP09 – rispettato - funzioni di archive, backup e restore del filesystem interno alle vm. Nel dettaglio si fa riferimento a un filesystem sia locale che montato localmente come “VMware Raw Device Mapping” (RDM) o ancora mappato localmente via rete “Network Attached Storage” (NAS); le tipologie di filesystem da supportare sono obbligatoriamente NTFS, ext3, ext4, xfs e reiserfs. Le funzioni di recovery devono comprendere piena indicizzazione, ricerca e recupero con granularità anche a livello del singolo file e/o (sotto)cartella e delle relative proprietà (data, ora, diritti di accesso, ecc.) dell’oggetto considerato;

RP10 – rispettato - funzioni di archive, backup e restore per apparati NAS e server fisici, raggiungibili via TCP-IP, o loro parti del filesystem (stesse tipologie già indicate) con piena indicizzazione, ricerca e recupero con granularità a livello del singolo file o (sotto)cartella e delle relative proprietà (data, ora, diritti di accesso, ecc.) dell’oggetto considerato;

RP11 – rispettato tramite la funzionalità Cloud Scale File system coperta dalla tecnologia Atlas - capacità di proteggere e gestire centinaia di milioni di oggetti nei salvataggi (archive e backup) contando file, cartelle, vm, server fisici, blocchi di dati, loro versioni, ecc.;

RP12 – rispettato - supporto e possibilità di attivare le funzioni di archiving di lungo termine, potenzialmente anche “all’infinito”, per tutti gli oggetti presenti nei backup su storage locale, storage di rete e storage di archiviazione in cloud;

RP13 – rispettato - configurazione dello storage (tutto quello presente, quindi sia per archiving/backup che per la parte di supporto al DR, se distinti) della soluzione tecnologica offerta per la protezione dei dati in fault-tolerant con soluzioni in grado di garantire elevate prestazioni, scalabilità e piena affidabilità. Si richiede espressamente l’impiego di tecnologie informatiche che garantiscano l’assenza di disservizi e contro le perdite di dati con guasti di 2 (due) unità contemporanee, quindi l’applicazione nativa di tecnologie tipo RAID (Redundant Array of Independent Disks). Si precisa che standard più recenti ed evoluzioni tecnologiche, quali RAIN (Redundant Array of Independent Nodes / Reliable Array of Independent Nodes) o ECS (Erasure

Coding Storage) o loro ulteriori combinazioni che siano resistenti a guasti di 2 (due) unità contemporanee soddisfano il requisito;

RP14 – rispettato - sullo storage, sia per l’ambito di archive/backup/restore che DR-support se si tratta di apparati distinti, devono essere assicurate almeno le seguenti prestazioni complessive, quindi sono sommabili se la soluzione offerta è composta da più sistemi e da nodi che le combinano o le parallelizzano per fornire le funzioni indicate. Prestazioni che devono essere misurate con la configurazione di protezione dello storage da fallimenti di cui al punto precedente:

a) Network Data Throughput = 1 GB/s (o circa 3,5 TB/h). In questa misurazione si intende di tipo “reale”, quindi senza alcuna compressione e/o deduplica applicata lato sorgente per ottenere la suddetta misurazione;

b) Random IOps (4KB) Read=20.000, Write=10.000. Equivalentemente R/W=15.000 con un rapporto tra le operazioni almeno 50/50, se poi i “write” sono più alti ovviamente il requisito è soddisfatto.

Questi valori tengono conto sia di quanto rilevato sullo storage di produzione dai grafici presenti nello scenario già descritto, ma anche dalle prestazioni di picco che lo storage primario assicura. In fase di verifica di conformità, dopo aver montato via rete (o via protocollo fibra, se viene proposta tale soluzione) lo storage offerto con uno dei protocolli obbligatori richiesti (si vedano i requisiti obbligatori in tal senso), potranno essere misurate con strumenti di terze parti quali CrystalDiskMark, IOmeter, UserBenchMark (UBM), Atto Disk Benchmark o una combinazione degli stessi. Il fornitore dovrà produrre grafici ottenuti con i medesimi software per comprovare le prestazioni, se già non disponessero di tali misurazioni sui datasheet o su altra documentazione da inserire nell’offerta tecnica.

Art. 4 – Caratteristiche generali degli apparati

1. Il fornitore deve consegnare al committente sistemi hardware, moduli, apparati, prodotti ed eventuali codici di attivazione e licenze software/middleware/firmware/microcode, se necessarie, di tipo originale e rilasciate appositamente dal costruttore/produttore per il Comune di Firenze; conseguentemente, il Comune di Firenze risulterà il primo e unico proprietario, in via esclusiva, di tutta la soluzione tecnologica realizzata in attuazione del presente Capitolato.

2. La fornitura deve obbligatoriamente prevedere apparati hardware assolutamente nuovi ovverosia che il sistema e i moduli/nodi/cluster che lo compongono non siano a loro volta formati da apparati rigenerati e/o ricondizionati. Durante il periodo di garanzia e manutentivo, invece, è possibile che come parti di ricambio siano utilizzati apparati rigenerati e/o ricondizionati.

3. La soluzione presentata non deve richiedere, per il suo funzionamento necessario a rispondere ai requisiti minimi obbligatori, aggiunte successive di componenti hardware e/o software e/o firmware e/o licenze e/o codici di attivazione o, comunque, modifiche successive che comportino spese aggiuntive o un qualsiasi tipo di costo o di aggravio economico per l’Ente per tutta la durata contrattuale.

4. I prodotti offerti devono essere presenti sul mercato ancora in produzione e recanti il marchio del costruttore al momento del loro utilizzo o della loro installazione; devono essere certificati dal produttore come nuovi e inclusi nella loro confezione originale. E’ obbligo del fornitore garantire che il costruttore licenzi i prodotti specificatamente per il Comune di Firenze, che sarà il “primo acquirente finale” di tali prodotti e primo licenziatario dell’hardware e dei moduli e di qualsiasi, eventuale, copia del software, compreso quello incluso nei prodotti. A tal fine il committente potrà effettuare tutti i controlli ritenuti adeguati per verificarne l’origine, anche contattando direttamente il produttore ufficiale degli apparati oggetto della fornitura e chiedendone verifica e apposita certificazione ufficiale.

5. Ad integrazione di quanto già richiesto, tutti gli apparati e i dispositivi forniti dovranno essere assolutamente conformi con la normativa vigente, italiana ed europea, in ambito di sicurezza sul lavoro, di consumi energetici, di emissioni, di rumorosità, di modalità di riscaldamento e di raffreddamento; dovranno riportare anche tutte le marcature obbligatorie di legge (CE, modello e numeri seriali, l’anno di costruzione, ecc.) e, inoltre, dovranno essere forniti, a corredo, i libretti di uso e la relativa manualistica digitale in lingua italiana o in lingua

inglese, eventualmente con i riferimenti per reperirla da siti on-line o da supporti magnetici/ottici.

6. Il fornitore dovrà trasmettere, contestualmente alla consegna del materiale e degli apparati, tutte le certificazioni sull’originalità, provenienza e garanzia dei prodotti forniti.

Art. 5 – Cronoprogramma delle attività della fornitura

1. Il fornitore deve rispettare la tempistica sotto indicata, fatte salve eventuali proroghe (rinvio di una o più scadenze) nei casi eventualmente indicati esclusivamente da parte del committente; in particolare, il fornitore deve:

a) consegnare l’elenco esaustivo e dettagliato di tutti i codici prodotto del vendor pertinenti alla fornitura, entro 30 (trenta) giorni lavorativi dall’avvio dell’esecuzione della prestazione (decorrente dalla ricezione da parte del fornitore del relativo ordine), sia per la parte hardware, sia per il software, che per tutto quanto verrà licenziato e attivato con la fornitura;

b) predisporre e consegnare il “Piano di Progetto definitivo”, discusso, concordato e approvato dal committente, deve avvenire entro 30 (trenta) giorni lavorativi dalla data dell’ordine;

c) consegnare tutto il materiale e gli apparati offerti entro 30 (trenta) giorni lavorativi dalla data dell’ordine, con il seguente dettaglio;

c.1) l’installazione con le relative slitte o staffe a rack, la loro messa in funzione o attivazione di base di tutto il materiale e di tutti gli apparati hardware deve avvenire entro 10 (dieci) giorni lavorativi dalla data di consegna di tutto il materiale, presso le sedi indicate dal committente;

c.1.1) il fornitore deve svolgere tutte le attività per consentire che la verifica dei requisiti hardware di tutto il materiale e di tutti gli apparati di cui al successivo art. 6 si concluda entro 10 (dieci) giorni lavorativi dalla data in cui si sono concluse le attività di installazione e di attivazione di base;

c.2) l’aggiornamento del personale e il training-on-the-job previsto in offerta dovrà concludersi al massimo entro 60 (sessanta) giorni lavorativi dall’attivazione di base degli apparati.

c.3) l’avvio delle attività necessarie per la migrazione dei nodi dal vecchio sistema di backup e la protezione delle vm per il supporto al DR deve iniziare al massimo entro 15 (quindici) giorni lavorativi dall’attivazione di base del sistema;

c.4) il fornitore deve svolgere tutte le attività per consentire che la verifica finale della soluzione di cui al successivo art. 6, o il primo tentativo in caso di esito negativo, avvenga al massimo entro 60 (sessanta) giorni solari dall’attivazione di base e, comunque, solo quando nella nuova soluzione risulteranno protetti una quantità di dati e il numero adeguato di vm (qualitativo e quantitativo) per poter procedere con la verifica stessa;

c.4.1) la redazione del Piano DR (PDR) definitivo, in accordo con il personale tecnico dell’Ente, e con le indicazioni, spunti e suggerimenti tecnici aggiornati e adeguati all’infrastruttura ICT del committente, quindi quelle parti del Piano CO (PCO) di interesse, dovrà avvenire al massimo entro 30 (trenta) giorni lavorativi dalla verifica finale della soluzione conclusa con esito positivo;

c.4.2) la garanzia/manutenzione on-site e il supporto sulla parte software e sulle anomalie deve essere assicurata per un periodo di 3 (tre) anni (dato da aggiornare in base a quanto offerto in sede di gara dall’aggiudicatario) dalla data della verifica finale della soluzione conclusa con esito positivo;

c.4.3) il fornitore deve garantire il pieno riscontro su tutte le licenze entro 10 (dieci) giorni dalla verifica finale della soluzione conclusa con esito positivo, cioè la visualizzazione e il riscontro che le licenze e tutte le altre funzionalità offerte siano registrate e correttamente attivate sul sistema informatico con riscontro diretto su quanto presente sul sito del produttore (se previsto altrimenti tramite comunicazione scritta dallo stesso) in merito alla gestione (a titolo esemplificativo e non esaustivo, se pertinenti: numero di apparati, periodo di durata, funzioni previste, titolare delle licenze, ecc.).

c.4.4) il completamento della migrazione dei sistemi sotto backup dal vecchio ambiente alla nuova soluzione tecnologica dovrà avvenire al massimo entro 60 (sessanta) giorni lavorativi dalla verifica finale della soluzione registrata con esito positivo.

2. Il committente trasmetterà al fornitore l’elenco corrente dei sistemi virtuali coinvolti nonché gli eventuali chiarimenti richiesti prima di pervenire alla data di svolgimento della verifica finale da eseguirsi su tutta la soluzione (requisiti, licenze, caratteristiche e funzionalità).

3. Nell’ambito dell’assistenza allo “startup”, il tempo di intervento dovrà essere tassativamente inferiore o uguale alle 4 (quattro) ore solari o alla durata inferiore migliorativa proposta nell’offerta tecnica.

4. Tutte le scadenze e le tempistiche sopra indicate sono soggette a penali come disposto dall’art. 10 del presente Capitolato. Si precisa che in caso di ritardi rispetto ai tempi sopra indicati o di esito negativo delle verifiche di conformità, il committente, prima dell’applicazione delle penali, valutate le specifiche motivazioni addotte e le problematiche tecniche eventualmente rilevate e riportate dal fornitore, può decidere di prorogare il termine della particolare scadenza disattesa.

5. Data l’importanza di portare a conoscenza delle parti contraenti le misure di prevenzione e di protezione (ad esempio percorsi e uscite di sicurezza, modalità di accesso ai locali, prescrizioni esistenti, ecc.) e i rischi connessi con l’esecuzione della presente fornitura e di eventuali altre attività che potrebbero essere in corso negli stessi ambienti delle sedi coinvolte, nel pieno rispetto di quanto previsto dalla norma sulla sicurezza sul lavoro, D.Lgs. 81/2008 (art. 26, comma 2, lettere a, b) e ss.mm.ii., per l’accesso alle sedi dove si svolgeranno le attività, il committente e il fornitore sono tenuti alla compilazione del verbale allegato denominato “Verbale di cooperazione e di coordinamento per le interferenze nelle sedi”, da effettuarsi come prima attività successiva al conferimento dell’ordine.

Art. 6 – Verifiche ed emissione del certificato di regolare esecuzione (C.R.E.)

1. Tenuto conto delle caratteristiche della prestazione oggetto del presente capitolato, le verifiche sulla stessa si svolgeranno in parte nel corso dell’esecuzione del contratto, in parte al termine dello stesso, con successiva emissione del Certificato di Regolare Esecuzione (C.R.E.).

Le verifiche sulla prestazione resa dal fornitore verranno svolte in accordo tra le Parti e con la compresenza del personale tecnico dell’Ente, procederanno come richiesto dal committente, prevedendo i diversi aspetti presenti nel “Piano di Progetto definitivo”. La verifica si svolge con controlli, con test di esecuzione e con l’esercizio delle funzionalità e delle caratteristiche dell’intera soluzione.

2. Il piano delle attività di verifica presente nel “Piano di Progetto” dovrà essere disponibile (inizialmente come proposta, poi validata) per consentire di stabilire le verifiche che riguardano sia le caratteristiche hardware, sia il riscontro formale della presenza di certe caratteristiche, licenze o funzioni, sia l’esercizio (configurazione, utilizzo, test, ecc.) stesso di funzionalità proprie (archive, backup, restore e DR support) della soluzione fornita. Le procedure di verifica sulla prestazione resa dal fornitore, relative sia ai nuovi apparati che sull’intera soluzione tecnologica, si articolano nelle seguenti attività:

a) verifica dei requisiti hardware (quali RAM, interfacce, ecc.) del tipo RHxx

a.1) Test della funzionalità hot-swap dei moduli su alcuni apparati a campione

a.2) Test, anche a campione, delle interfacce presenti sugli apparati

b) verifica finale della soluzione (requisiti, licenze, caratteristiche e funzionalità):

b.1) Verifica, anche a campione, dei requisiti di licenze RLxx

b.1.1) Test di almeno ¼ (un quarto o 25%) dei requisiti di sistema RSxx richiesti

b.1.2) Test base delle funzioni di logging & monitoring (requisito RSLR)

b.1.3) Verifica, anche a campione, delle misure minime RSMM

b.2) Test esteso della funzione di protezione RP01 e RP02

Nell’effettuare il test indicato e per simulare una situazione di DR significativa per il committente, si richiede che complessivamente siano ripristinate, se necessario, su storage della Data Protection Solution, registrate su vCenter del cluster DR e poi accese in modo contemporaneo (sfruttando gli host del cluster DR) almeno il 33% (trentatré percento, calcolato sulla consistenza numerica) delle macchine virtuali presenti nel cluster di produzione, in un tempo contenuto stimabile non superiore alle 8 (otto) ore, considerando quanto indicato nello Studio di Fattibilità Tecnico riportato all’inizio del capitolato stesso. Le vm coinvolte saranno scelte in modo casuale, a campione o in base a quanto voluto e indicato dal committente. Preso atto che le vm più grandi di dimensioni e risorse saranno probabilmente anche quelle più critiche da gestire, in questo test saranno in ogni caso coinvolte:

1) la vm denominata SR-VM171-SIGDB già descritta negli allegati;

2) al massimo n. 1 (una) altra vm con dimensioni disco complessive oltre i 10 TB (dieci);

3) al massimo n. 2 (due) vm con dimensioni disco tra 3 TB (tre) e 10 TB (dieci);

4) tutte le restanti vm saranno individuate senza ulteriori restrizioni e adottando una delle metodologie indicate per assicurare di raggiungere la percentuale richiesta.

Le vm dovranno riaccendersi correttamente senza presentare situazioni di BSoD (Blue- Screen-of-Death su Microsoft Windows), kernel panic (su Linux e derivati), crash middleware ospitato (a titolo esemplificativo e non esaustivo DBMS Oracle, MS SQL, PostgreSQL, ecc. web server quali Apache, IIS, Tomcat, ecc.) o comportamenti anomali tipo riavvii ciclici, console non responsive, blocchi o congelamenti inspiegabili (freeze), ecc. Sono consentite situazioni di avviso e notifica che la situazione precedente non riporta una chiusura “pulita”, appunto causa situazione (simulata) di disastro, ma alla fine devono

essere messi in atto gli interventi per consentire alla vm e ai sistemi in essere di avviarsi completamente. Se tale test supera i limiti temporali sarà permesso al fornitore di motivare a livello tecnologico le cause e spetterà al committente valutare se le stesse siano sufficienti a giustificare il ritardo. In ogni caso il committente può richiedere di eseguire il test fino al completo soddisfacimento dei vincoli e, in caso di non raggiungimento degli stessi, registrare un esito negativo.

b.3) Test di almeno ¼ (un quarto o 25%) delle restanti funzioni di protezione RPxx

b.4) Test di almeno ¼ (un quarto o 25%) delle eventuali caratteristiche offerte di tipo VTPx

b.5) Verifica di almeno ¼ (un quarto o 25%) delle misure minime migliorative dichiarate VTSx

b.6) Test di almeno ¼ (un quarto o 25%) delle eventuali caratteristiche offerte di tipo VTUxx

b.7) Test di almeno ¼ (un quarto o 25%) delle eventuali caratteristiche offerte di tipo VTWxx

b.8) Verifica dell’attivazione delle licenze, della garanzia/manutenzione on-site e del supporto tecnico con il produttore per il periodo e con gli SLA richiesti dalla presente fornitura (o per quanto indicato in offerta migliorativa) per gli apparati/nodi offerti (verifica dei relativi seriali) usando l’account predisposto per il Comune di Firenze. Sarebbe corretto che tale controllo potesse essere fatto in “modalità remota” ovvero accedendo sul sito Internet del produttore dedicato a tali servizi e trovando pieno riscontro a quanto indicato altrimenti, se assolutamente impossibile, saranno valutate altre modalità con il produttore stesso (comunicazione via PEC, documento cartaceo, ecc.).

3. Il committente potrà inserire ulteriori verifiche e test mirati nella procedura sopra indicata, specialmente per esercitare tutte quelle caratteristiche tecniche di tipo migliorativo che sono state offerte in sede di gara, aspetti che dovranno poi essere riportati sempre nel “Piano di Progetto definitivo” che sarà discusso, condiviso, concordato e, infine, approvato dai responsabili tecnici dell’Ente entro 30 gg. dalla consegna dello stesso da parte del fornitore ai sensi del precedente art. 5, comma lett. b).

4. La decisione definitiva sulle caratteristiche da verificare e le funzionalità da esercitare è di esclusiva competenza del committente e l’elenco scelto può essere indifferentemente una selezione specifica e puntuale o anche una scelta casuale a campione o una loro combinazione.

5. Prima della verifica finale sull’intera soluzione, tutti gli apparati e i sistemi coinvolti dovranno essere pronti e attivati con l’ultima versione di software/firmware/microcode rilasciata e certificata dal produttore, compatibile con la preesistente infrastruttura ICT dell’Ente, aspetto da riportare nel “Piano di Progetto definitivo”.

6. La verifica dei requisiti hardware deve essere conclusa con esito positivo entro il termine di cui all’art. 5, comma 1, lett. c.1.1). la verifica finale della soluzione deve essere conclusa con esito positivo entro il termine di cui all’art. 5, comma 1, lett. c.4).

7. Durante tutte le prove svolte (nell’eventualità che ci possano essere più tentativi a seguito di precedenti esiti insoddisfacenti) si terrà traccia dei test e delle operazioni condotte che saranno riportate nel relativo verbale, scritto dettagliando le singole attività e il relativo risultato conseguito; il verbale delle operazioni svolte è da compilare a carico del fornitore ed è soggetto a controllo, verifica ed approvazione da parte dei tecnici dell’Ente. In particolare, la suddetta procedura di verifica con esito positivo e definitivo si perfezionerà solo alla fine, quando tutte le operazioni e le verifiche tecniche risulteranno superate con successo, aspetto che identificherà il verbale finale di verifica della soluzione che dovrà risultare firmato per accettazione da entrambe le Parti. Si ribadisce che solo dalla data dello stesso decorre il periodo di attivazione della garanzia on-site richiesto dalla fornitura o del periodo migliorativo

previsto nell’offerta.

8. La firma finale del suddetto verbale di verifica con esito positivo da parte dell’Amministrazione è comunque condizionata dall’avvenuta completa consegna in formato digitale, o nella forma concordata successivamente tra le parti, di tutte le informazioni e di tutta la documentazione, compreso il PDR preliminare e le indicazioni per il PCO. Questa documentazione sarà stata prima elaborata dal fornitore e validata dal committente durante lo svolgimento delle attività delle diverse fasi del progetto per la predisposizione della soluzione tecnologica completa, oltre che durante la configurazione definitiva degli apparati ICT che la compongono, le varie ottimizzazioni (tuning) e la parametrizzazione realizzata e applicata per il corretto funzionamento del sistema, nel suo complesso, e di tutto quanto previsto dalla fornitura. Si sottolinea che in assenza della documentazione indicata o in presenza di valutazione insufficiente e/o negativa della stessa da parte del committente, la verifica non sarà perfezionata e sarà valutata come NON superata.

9. In esito alla sottoscrizione da parte di entrambe le Parti del verbale di cui al precedente comma 7, il committente (RUP) emetterà, ai sensi dell’art. 102, comma 2 del D.Lgs. 50/2016 il C.R.E., attestante che l’oggetto del contratto in termini di prestazioni, obiettivi e caratteristiche tecniche, economiche e qualitative, è stato eseguito nel rispetto delle previsioni contrattuali.

10. Si richiama quanto previsto dall’art. 2, comma 4, in ordine agli obblighi di comunicazione del fornitore.

Art. 7 – Durata e parti del contratto. Sospensioni.

1. Il presente contratto avrà durata dalla data della stipula fino ai 3 (tre) anni (dato da aggiornare in considerazione di quanto offerto dall’aggiudicatario) successivi dalla data di verifica finale della soluzione con esito positivo. Quindi la garanzia on-site, l’assistenza e il supporto tecnico avrà la durata minima di 3 (tre) anni (dato da aggiornare in considerazione di quanto offerto dall’aggiudicatario) con decorrenza dalla data della suddetta verifica finale della soluzione con esito positivo.

2. Le condizioni di cui al presente Capitolato Speciale hanno validità per tutta la durata contrattuale.

3. Le sospensioni dell’esecuzione del contratto possono essere disposte dal RUP unicamente nei casi di cui all’art. 107, commi 1 e 2 del D.Lgs. 50/2016. In caso di sospensioni totali o parziali in difformità delle suddette disposizioni, il risarcimento dovuto al fornitore è quantificato secondo i criteri di cui all’art. 10, comma 2 del D.M. 49/2018, in quanto compatibili. Per tutto quanto non disciplinato nel presente Capitolato si rinvia a quanto previsto dall’art. 107 del D.Lgs. 50/2016.

Art. 8 – Modalità di fatturazione e pagamento

1. Il corrispettivo pattuito dovrà essere fatturato successivamente alla verifica da parte dell’Ente della conformità della prestazione oggetto del presente Capitolato.

2. La fatturazione della presente fornitura dovrà avvenire nel rispetto delle percentuali del RTI come di seguito indicato:

	TELECOM ITALIA	ADITINET CONSULTING	TOTALE
a)	70.678,29 €	7.161,24 €	77.839,53 €
b)	76.264,49 €	1.575,04 €	77.839,53 €
c)	38.919,76 €		38.919,76 €
d)	11.233,84 €		11.233,84 €
e)		11.233,84 €	11.233,84 €
TOT.	197.096,38 €	19.970,12 €	217.066,50 €

In particolare, con riferimento alle voci della precedente tabella:

a) € 77.839,53 alla consegna e dopo la verifica, con esito positivo, dei requisiti hardware;

b) € 77.839,53 dopo la verifica finale, con esito positivo, sulla soluzione offerta (requisiti, licenze, caratteristiche e funzionalità);

c) € 38.919,76 dopo la migrazione di almeno il 95% di tutti i nodi/sistemi protetti da backup dal precedente ambiente esistente sulla nuova soluzione tecnologica oggetto della presente fornitura e la consegna del Piano DR definitivo (PDR) e comunque non prima del 30/12/2019;

d) € 11.233,84 dopo un anno (365 gg) dalla verifica finale registrata con esito positivo del sistema e, comunque, non prima del 30/12/2020;

e) € 11.233,84 dopo due anni (730 gg) dalla verifica finale registrata con esito positivo del sistema.

3. Il pagamento in favore del fornitore sarà effettuato secondo le norme di legge in vigore. Il fornitore dovrà sempre riportare obbligatoriamente nelle fatture gli estremi del contratto, il codice CIG e gli estremi della determinazione dirigenziale che autorizza la spesa.

4. Le fatture in formato elettronico dovranno essere intestate:

Direzione Sistemi Informativi - Comune di Xxxxxxx - Xxx X. Xxxxxxxx, 000 – 00000 Xxxxxxx

che curerà le procedure per la loro liquidazione.

5. Il fornitore provvederà all’invio delle stesse tramite il Sistema di Interscambio (SDI).

6. Il pagamento, al netto delle eventuali penali applicate, verrà effettuato entro 30 (trenta) giorni dalla data di ricevimento della relativa fattura e sarà comunque subordinato alla verifica della regolarità contributiva risultante dal Documento Unico di Regolarità Contributiva (DURC) e, in generale, alle verifiche di legge.

7. Ai sensi dell’art. 30, comma 5-bis del D.Lgs, 50/2016, il committente opererà sull’importo netto progressivo delle prestazioni una ritenuta dello 0,5% (zero virgola cinque per cento), che verrà svincolata solo in sede di liquidazione finale e dopo l’approvazione del C.R.E. e previa acquisizione del documento unico di regolarità contributiva.

8. Ai fini del pagamento del corrispettivo il fornitore dovrà utilizzare uno o più conti correnti bancari o postali dedicati alle commesse pubbliche, secondo quanto previsto dalla Legge n. 136 del 13/08/2010.

Art. 9 – Organizzazione e gestione del rapporto contrattuale

1. Fanno parte del contratto:

- La documentazione di gara

- Il presente Capitolato Speciale e i relativi allegati

- Il “Piano di Progetto iniziale o preliminare”, compilato come richiesto dai documenti di

gara e presentato dal fornitore nell’offerta tecnica;

- Il “Piano di Progetto definitivo”, redatto dal fornitore dopo essere stato discusso, condiviso, concordato e approvato dal committente.

2. Il Comune di Firenze – Direzione Sistemi Informativi provvederà a nominare un direttore dell’esecuzione del contratto allo scopo di assicurare la regolare esecuzione del contratto stesso verificando che le attività e le prestazioni contrattuali siano eseguite in conformità dei documenti contrattuali.

3. Il direttore dell’esecuzione del contratto, che può coincidere con il responsabile unico del procedimento (RUP), può avvalersi allo scopo di uno o più assistenti.

4. Tutte le comunicazioni ufficiali della Ditta in merito alla fornitura dovranno essere indirizzate al direttore dell’esecuzione del contratto e, eventualmente, in copia a terzi come richiesto. Analogamente tutte le comunicazioni del Comune saranno indirizzate ai referenti della Ditta.

5. Il direttore dell’esecuzione del contratto, ove verifichi che uno o più servizi erogati non abbiano raggiunto i risultati previsti o siano stati eseguiti in modo difforme dalle prescrizioni del presente capitolato, ne dispone il rifacimento.

6. Il fornitore ha l’obbligo di predisporre appositi canali di comunicazione dedicati quali: telefono, mail, PEC, etc.

7. Il fornitore dovrà nominare, nella propria offerta, un capo progetto (Responsabile Operativo) e un referente commerciale con il compito di rappresentare e impegnare la ditta stessa nella fase esecutiva del contratto. Tali responsabili saranno gli interlocutori dell’Ente ogniqualvolta si presentino problemi nell’erogazione dei servizi oggetto del presente.

8. Il fornitore si assume tutte le responsabilità inerenti eventuali infortuni o danni a persone o cose arrecati all’Ente o a terze parti, durante lo svolgimento di attività.

9. Il fornitore si impegna ad ottemperare a tutti gli obblighi verso i propri dipendenti, derivanti da disposizioni legislative, regolamenti e norme contrattuali vigenti in materia di lavoro, assicurazioni sociali e previdenza, assumendo a suo carico tutti gli oneri relativi.

Art. 10 – Penali e rispetto livelli di servizio

1. Nel caso che le tempistiche, le attività previste e i livelli di servizio (SLA) indicati nel presente Capitolato Speciale negli artt. 3, 4 e 5 non siano rispettati, l’Ente si riserva di agire nelle sedi legali per tutelarsi nei confronti dell’eventuale danno arrecato dal fornitore; pertanto le penali sotto riportate sono definite facendo sempre salvo risarcimento del maggior danno.

2. Per il calcolo delle penali, i valori ottenuti saranno arrotondati sempre per difetto al numero intero tralasciando, quindi, i decimali di euro.

3. Le penali, in conformità a quanto indicato dal Decreto legislativo n. 50 del 18 aprile 2016 e ss.mm.ii., sempre salvo la risarcibilità dell’eventuale maggior danno, saranno applicate nei seguenti casi:

P01 - ritardo nel tempo di presa in carico (o tempo di risposta) o nel tempo di ripristino (o tempo di intervento) non imputabile al committente e imputabile al fornitore (salvo prova contraria a carico del fornitore), in caso di:

o malfunzionamenti bloccanti la penale equivale a 1/25.000 (un venticinque millesimo o 0,04‰) dell’importo di aggiudicazione per ogni ora intera (escluse le frazioni) lavorativa di ritardo nell’intervallo indicato dalla copertura obbligatoria minima richiesta da Capitolato o della migliorativa offerta in gara. Ne consegue che si va da un minimo teorico, calcolato considerando di base gli SLA minimi richiesti, pari allo 0,32‰ (8 ore con penale dello 0,04‰ l’ora) per ogni giorno lavorativo di ritardo (lunedì-venerdì, festivi esclusi) fino al massimo possibile dello 0,96‰ (24 ore sempre con penale dello 0,04‰ l’ora) in qualsiasi giorno della settimana e festivi inclusi, quindi per giorni solari;

o altre segnalazioni non bloccanti la penale equivale a 1/50.000 (un cinquanta millesimo o 0,02‰) dell’importo di aggiudicazione per ogni ora intera (escluse le frazioni) lavorativa di ritardo nell’intervallo indicato dalla copertura obbligatoria minima richiesta dal presente Capitolato o della migliorativa offerta in gara. Ne consegue che si va da un minimo teorico, calcolato considerando di base gli SLA minimi richiesti, pari allo 0,16‰ (8 ore con penale dello 0,02‰ l’ora) per ogni giorno lavorativo di ritardo (lunedì-venerdì, festivi esclusi) fino al massimo possibile dello 0,48‰ (24 ore sempre con penale dello 0,02‰ l’ora) in qualsiasi giorno della settimana e festivi inclusi, quindi per giorni solari;

P02 - carenze professionali, tecniche e/o qualitative nell’espletamento della fornitura; qualora la formazione erogata, il personale tecnico, le tempistiche, le attività svolte e le scadenze previste (ad es. per la consegna, per l’installazione, per la verifica di conformità, la formazione, la migrazione dei nodi, etc.) non risultino adeguati/rispettati, non rispondano ai livelli di professionalità richiesti, non siano in grado di adempiere alle operazioni o alle prestazioni e ai requisiti previsti in fornitura o non siano di un livello soddisfacente, il Comune invierà una prima comunicazione formale di richiamo alla ditta fornitrice ed eventualmente al produttore con l’indicazione dettagliata delle carenze rilevate. A tale prima comunicazione, il fornitore e il produttore degli apparati, se coinvolto, possibilmente congiuntamente e in modo coerente, devono rispondere entro 5 (cinque) giorni lavorativi indicando i comportamenti e le soluzioni poste in essere, entro al massimo 3 (tre) giorni lavorativi a decorrere dalla data della risposta, per risolvere le criticità e le carenze. Qualora si verificassero successivamente i medesimi problemi tecnici e/o professionali, di qualità e/o di inadeguatezza, il Comune potrà inviare una seconda comunicazione di richiamo e applicare contestualmente una penale di 1/2.000 (un due millesimo o 0,50‰) al giorno (escluse le frazioni) lavorativo (lunedì-venerdì, festivi esclusi) o, in base alla miglioria offerta, anche per qualsiasi giorno della settimana e festivi compresi ovverosia per giorno solare; questo per ogni singolo episodio distinto contestato. Al perdurare dei problemi l’Ente potrà continuare ad applicare le penali come sopra specificato;

P03 - ritardi di intervento durante il periodo di assistenza allo “startup”; considerato il tempo di intervento fissato estremamente ristretto e la criticità o il disservizio che si potrebbe presentare in queste circostanze per l’Ente, in caso di anomalie o problematiche segnalate dal committente e in caso di mancata attivazione dei tecnici nei tempi richiesti dal presente Capitolato o in quelli migliorativi offerti dal fornitore, verranno contestate immediatamente le mancanze e si inizierà ad applicare le penali. Rimane in tal caso totalmente a carico del fornitore provare la totale estraneità con le cause all’origine del ritardo, entro al massimo 2 (due) giorni solari dall’evento. La penale applicata in questi casi equivale a 1/25.000 (un venticinque millesimo o 0,04‰) dell’importo di aggiudicazione per ogni ora intera (escluse le frazioni) di ritardo nell’intervallo di copertura indicato ovverosia qualsiasi giorno solare dell’anno su 24 ore, quindi per un massimo possibile, considerando gli SLA richiesti, pari allo 0,96‰ per ogni giorno solare.

4. Ai sensi dell’art. 113-bis del D.Lgs. 50/2016, le penali non possono comunque superare, complessivamente, il 10 per cento dell’ammontare netto contrattuale; in caso di superamento di tale importo, si procede ai sensi del successivo art. 12.

Art. 11 – Osservanza delle norme in materia di lavoro

1. Il fornitore è tenuto all’osservanza rigorosa delle disposizioni in materia di collocamento, igiene sicurezza sul lavoro anche con riguardo alla nomina del responsabile della sicurezza, di tutela dei lavoratori in materia contrattuale e sindacale, delle norme relative alle assicurazioni obbligatorie ed antinfortunistiche, previdenziali ed assistenziali e deve adottare tutti i procedimenti e le cautele atte a garantire l’incolumità e la sicurezza delle persone addette e dei terzi con scrupolosa osservanza delle norme antinfortunistiche e di tutela della salute dei lavoratori in vigore nel periodo contrattuale.

2. A richiesta dell’Amministrazione la ditta è tenuta, in ogni momento, a dimostrare la regolare applicazione delle norme contrattuali di lavoro, delle norme assicurative, previdenziali e antinfortunistiche relative al personale dalla stessa impiegato.

3. Si evidenzia che le attività ed i servizi oggetto dell’affidamento di cui trattasi non interferiscono con quelle di questa Azienda in maniera tale da creare rischi, quindi, il conseguente importo degli oneri della sicurezza per rischio da interferenze è pari a zero.

Art. 12 – Risoluzione del contratto

1. Tutte le clausole del presente Capitolato sono essenziali e, pertanto, ogni eventuale inadempienza può produrre un’immediata risoluzione del contratto stesso, di diritto e di fatto, con esclusione di ogni formalità legale o di pronunzia di arbitri o di magistrati.

2. Le inadempienze del fornitore devono essere contestate per iscritto dall’Amministrazione Comunale con fissazione di un termine per la relativa regolarizzazione e danno luogo alla risoluzione contrattuale in caso di persistente inottemperanza del termine stabilito.

3. In tal caso, l’Amministrazione Comunale potrà procedere nei confronti del fornitore alla determinazione dei danni eventualmente sofferti, rivalendosi con l’incameramento della garanzia definitiva e, e se ciò non bastasse, agendo per il risarcimento completo dei danni subiti.

4. In caso di risoluzione, per la quale sarà dato preavviso di almeno 15 giorni, sarà dovuto unicamente il compenso per il servizio svolto fino al momento dell’interruzione.

5. In ogni caso, pur in presenza di risoluzione, il fornitore sarà tenuto ad effettuare le prestazioni strettamente necessarie, richieste dal committente, per consentire il subentro del nuovo appaltatore.

6. L’Amministrazione avrà la facoltà di risolvere il contratto, con tutte le conseguenze che tale risoluzione comporta, sia di legge, sia previste dalle disposizioni del presente capitolato, anche nelle seguenti ipotesi:

a) Cessione del contratto, dell’attività, atti di pignoramento e sequestro a carico dell’impresa, fallimento;

b) Fallimento o altre cause che possano pregiudicare l’espletamento del servizio, salvo il recupero dei maggiori danni sulla garanzia definitiva.

7. La risoluzione del contratto è disposta con atto dell’organo competente da notificare al fornitore ai sensi e per gli effetti dell’art. 108 del D.Lgs. 50/2016.

Art. 13 – Recesso

1. Il recesso dal contratto è soggetto alla disciplina dell’art. 109 del D.Lgs. 50/2016.

Art. 14 – Modifiche del contratto

1. Le modifiche, nonché le varianti del presente contratto devono essere autorizzate dal RUP.

2. Si applicano in ogni caso le disposizioni dell’art. 106 del D.Lgs. 50/2016.

Art. 15 – Subappalto

1. È vietata qualunque cessione di tutto o di parte della fornitura ad altre ditte sotto pena di risoluzione del contratto, nonché del risarcimento di ogni eventuale conseguente danno.

2. L’affidatario potrà affidare in subappalto i servizi compresi nel contratto previa autorizzazione della stazione appaltante purché:

a) l’affidatario del subappalto non abbia partecipato alla procedura per l'affidamento dell'appalto;

b) all'atto dell'offerta il fornitore abbia indicato le attività che intende subappaltare o concedere in cottimo;

b) il fornitore dimostri l’assenza in capo ai subappaltatori dei motivi di esclusione di cui all’art. 80 del D.Lgs. 50/2016 e ss.mm.ii.

c) il subappaltatore sia in possesso dei necessari requisiti di ordine speciale.

3. Rimangono in ogni caso escluse dalla possibilità di ricorrere al subappalto le attività inerenti alle verifiche di conformità e la predisposizione del “Piano di Progetto definitivo”, che rimangono totalmente in carico al fornitore.

4. Qualora l’appaltatore si sia riservato in sede di gara la facoltà di ricorrere al subappalto, lo stesso potrà essere autorizzato nei limiti e con le modalità previste dall’art. 105 del D. Lgs. 50/2016.

5. Per tutto quanto non disciplinato dal presente articolo, si rinvia a quanto disposto dall’art. 105 del D.Lgs. 50/22016.

Art. 16 – Revisione e invariabilità dei prezzi

1. Il rischio dell’esecuzione del presente appalto è a totale carico dell’Appaltatore. L’art. 1664 c.c., 1° comma, non si applica al presente appalto. E’ possibile procedere alla revisione dei prezzi esclusivamente nei casi, con le modalità e nei limiti di cui all’art. 106, comma 1, lett. a) del D.lgs.n.50 del 2016. Non si procede alla revisione dei prezzi in aumento quando la variazione dei prezzi è imputabile a fatto dell’Appaltatore.

2. Nei prezzi offerti e contrattualmente fissati si intendono compresi e compensati tutti gli oneri di cui all’appalto, tutto incluso e nulla escluso, per la completa attuazione dell’appalto.

3. Il fornitore, pertanto, non avrà diritto alcuno di pretendere sovrapprezzi o indennità di alcun genere per aumento dei costi, perdite o qualsiasi altra sfavorevole circostanza che possa verificarsi dopo la data dell’offerta.

Art. 17 – Garanzie

1. Il fornitore, a garanzia del regolare adempimento della fornitura, sarà tenuto a prestare una garanzia definitiva sotto forma di cauzione o fideiussione con le modalità previste dall’art. 103 comma 1 e 2 D. Lgs. 50/2016.

2. La mancata costituzione della suddetta garanzia entro 15 (quindici) giorni dalla richiesta del committente determina la decadenza dell’affidamento.

3. La garanzia fideiussoria, valida per tutto il periodo contrattuale, è svincolata secondo le modalità previste dall’art. 103 D.Lgs. 50/2016.

Art. 18 – Trattamento dati. Obblighi di riservatezza.

1. Il fornitore è tenuto a garantire il rispetto delle disposizioni in materia di trattamento dei dati personali (e in particolare quelle contenute nel regolamento UE 2016/679) con specifico riferimento alle misure di sicurezza adeguate, al rispetto dei principi di privacy by design e privacy by default, nonché delle prescrizioni specificatamente dal Titolare e suoi delegati durante l’espletamento della fornitura.

2. Con la sottoscrizione del presente Capitolato il fornitore assume, nella persona del sig. Xxxxx Xxxxxxxx, il ruolo, gli obblighi e le responsabilità del responsabile privacy ai sensi dell’art. 28 del Regolamento UE n. 679/2016.

3. Il fornitore provvede ad individuare al proprio interno, ai sensi del medesimo art. 28, i soggetti autorizzati al trattamento dei dati personali per l’esecuzione del presente Capitolato.

4. Il Fornitore ha l’obbligo di mantenere riservati i dati e le informazioni, ivi comprese quelle che transitano per le apparecchiature di elaborazione dati, di cui venga in possesso e, comunque, a conoscenza, di non divulgarli in alcun modo e in qualsiasi forma e di non farne oggetto di utilizzazione a qualsiasi titolo per scopi diversi da quelli strettamente necessari all’esecuzione della presente fornitura, anche successivamente alla cessazione di efficacia del rapporto contrattuale.

5. Al termine della esecuzione della presente fornitura, il fornitore è tenuto a distruggere ogni supporto informatico, cartaceo e/o di qualsiasi altra natura ancora in suo possesso, nei quali siano contenuti i dati e le informazioni, ivi comprese quelle che transitano per le apparecchiature di elaborazione dati, di cui venga in possesso e, comunque, a conoscenza, nel corso del rapporto contrattuale, in conformità a quanto all’uopo previsto dalla normativa sul trattamento dei dati personali (D.Lgs. n. 196/2003 xx.xx. e Regolamento UE 675/2016) e fermo restando altresì l’obbligo di restituzione al committente dei predetti dati ed informazioni.

6. L’obbligo di cui ai precedenti commi sussiste, altresì, relativamente a tutto il materiale originario o predisposto in esecuzione della presente fornitura; tale obbligo non concerne i dati che siano o divengano di pubblico dominio.

7. Il Fornitore è responsabile per l’esatta osservanza da parte dei propri dipendenti, consulenti e collaboratori, nonché dei propri eventuali subappaltatori e dei dipendenti, consulenti e collaboratori di questi ultimi, degli obblighi di segretezza sopra indicati.

8. In caso di inosservanza degli obblighi di riservatezza, il committente ha la facoltà di dichiarare risolto di diritto il presente contratto, fermo restando che il fornitore sarà tenuto a

risarcire tutti i danni che dovessero derivare da tale comportamento al committente.

Art. 19 – Clausola di rinvio e foro competente

1. Il Foro di Firenze sarà competente per tutte le controversie che dovessero insorgere in dipendenza dell’appalto e del relativo contratto.

2. È escluso il ricorso all’arbitrato e alla commissione. Per la definizione delle controversie si applicheranno gli artt. 208 e seguenti del D. lgs. n. 50/2016.

3. Per tutto quanto non diversamente previsto si applicano le disposizioni di cui al D.Lgs. 50/2016 e alle vigenti norme di legge e regolamentari in materia di appalti pubblici di forniture.

Document Metadata

Table of Contents

DIREZIONE SISTEMI INFORMATIVI

Document Metadata