CHIARIMENTI – TRANCHE V
GARA A PROCEDURA APERTA PER L’AFFIDAMENTO DI UN ACCORDO QUADRO PER LA FORNITURA DI SERVIZI CLOUD IAAS E PAAS IN UN MODELLO DI EROGAZIONE PUBBLICO NONCHÉ PER LA PRESTAZIONE DI SERVIZI CONNESSI, SERVIZI PROFESSIONALI DI SUPPORTO ALL’ADOZIONE DEL CLOUD, SERVIZI PROFESSIONALI TECNICI PER LE PUBBLICHE AMMINISTRAZIONI – ID 2213
La presente Errata Corrige e i chiarimenti sono visibili su: xxx.xxxxxx.xx e xxx.xxxxxxxxxxxxxxx.xx.
In ragione dell’errata corrige i seguenti documenti di gara sono stati ripubblicati:
A. Capitolato d’Oneri;
XXXXXX XXXXXXX x. 0
1) Capitolato d’Xxxxx, paragrafo 3 tabella “prezzi unitari a base d’asta e quantità per il LOTTO 1”, paragrafo 17.1 tabella “Tabella dei criteri discrezionali (D) e tabellari (T) di valutazione dell’offerta tecnica per il LOTTO 1”, paragrafo 15 Contenuto dell’Offerta tecnica.
CHIARIMENTI – TRANCHE V
ID chiarimento | Riferimento documentazione | Chiarimento |
1073 | Capitolato d’Oneri_NEW. | QUESITO: Con riferimento al par. 7.2 del Capitolato d’Oneri, lett. b) punti 1 e 2, ed in particolare alla previsione per cui il concorrente deve dimostrare il possesso del requisito di fatturato specifico medio annuo riferito agli ultimi due esercizi finanziari approvati alla data di scadenza del termine per la presentazione delle offerte, in considerazione delle successive proroghe e delle attività già svolte dai concorrenti per accertare il possesso di tale requisito alla data della prima scadenza del termine di presentazione dell’offerta, si chiede di confermare che il possesso del requisito potrà essere dichiarato avendo a riferimento gli ultimi due esercizi finanziari approvati alla prima data di scadenza di presentazione delle offerte (2 marzo 2020). RISPOSTA: Non si conferma |
1074 | Capitolato d’Oneri_NEW e Allegato 11A - Condizioni di assicurazione del Lotto 1 | QUESITO: Nel Capitolato d’Oneri all’inizio dell’art.27 (pag.127) si dice: “Con la stipula del singolo Appalto Specifico/Ordini e per tutta la durata del singolo Contratto di Fornitura, l’Amministrazione ha facoltà di richiedere al Fornitore il possesso di una adeguata copertura assicurativa (come da allegati 11A e 11B distinti per lotti) a garanzia di responsabilità civile per danni a terzi nell’esecuzione delle prestazioni contrattuali, sulla base delle condizioni di assicurazione di cui all’allegati al presente Capitolato d’oneri… ”, mentre nell’allegato 11A, in corrispondenza dell’Art.2, si richiede un massimale di 3 milioni di Euro. Domanda: Premesso che l’aggiudicazione dell’Accordo Quadro potrebbe comportare l’esecuzione di alcune decine di contratti esecutivi, per ognuno dei quali, a prescindere dal valore, dovrà essere prevista un’assicurazione con un massimale di 3 milioni di Euro, e che le Compagnie di Assicurazione, anche le più grandi e blasonate, non sono in grado di assicurare contratti con massimali complessivi dell’ordine di alcune decine di milioni di euro, si chiede di sapere se il massimale richiesto per ciascun contratto esecutivo, indicato all’art.2 dell’allegato 11A, sia un refuso. In caso contrario si chiede di conoscere le compagnie assicurative interpellate da Consip, disponibili a rilasciare assicurazioni con un massimale complessivo compatibile con le previsioni di acquisto del capitolato. |
RISPOSTA: Si conferma che la polizza indicata, da fornire all’amministrazione dovrà essere conforme all’Allegato “Condizioni di Assicurazione” fornito secondo il lotto di riferimento. Confermiamo che in procedure di gara che vedono l’aggiudicazione di più lotti da parte del medesimo fornitore, quest’ultimo ha potuto fornire la polizza richiesta con il massimale di 3 milioni qualora richiesta. | ||
QUESITO: | ||
La risposta al quesito n.1034 ha modificato la tabella Oggetto dell’Accordo Quadro | ||
del Lotto 1 del Capitolato d’Oneri, introducendo un cambio di metrica di tutti i | ||
servizi Storage da GB/Ora a GB/mese, sulla base della seguente affermazione: ”In | ||
relazione al servizio di Object Storage si rappresenta che il valore unitario posto a | ||
quesito n.1034 | base d'asta risulta particolarmente elevato rispetto ai prezzi correnti che si | |
con la relativa | possono riscontrare sul mercato. In particolare, la totalità di CSP offre tale servizio | |
risposta e tabella | ad un prezzo notevolmente inferiore rispetto a quanto indicato nella | |
“Oggetto | documentazione di gara, fino a due ordini di grandezza inferiori”. | |
1075 | dell'Accordo quadro Lotto 1” | Si fa presente, tuttavia, che la nuova base d’asta per i suddetti servizi, risulta essere fortemente squilibrata rispetto ai valori correnti di mercato offerti dai |
del Capitolato | principali Cloud Provider. | |
d’Oneri_NEW, | Infatti, ipotizzando per semplicità che il prezzo medio di mercato sia riferito solo | |
relativo all’errata | alla media dei prezzi applicati dai tre principali Cloud Provider (AWS, Google e | |
corrige n.5. | Microsoft) per l’occupazione dei GB, il rapporto tra il prezzo unitario medio di | |
mercato dei servizi Storage ed il relativo prezzo a base d’asta, prima della modifica | ||
attuata con il quesito n.1034, è riportato nella seguente tabella: |
Da tale tabella si potrebbe evincere, apparentemente, che la base d’asta dei servizi Storage sia sovradimensionata rispetto al prezzo unitario medio di mercato. In realtà il prezzo unitario medio di mercato si riferisce al solo costo di occupazione dei GB e non tiene conto né dei costi di I/O (scrittura, lettura, lista, ecc…) nè dei costi di replica su più AZ, da prevedere invece nei suddetti servizi di Storage, come richiesto dal capitolato. Per contro il cambio di metrica dei servizi Storage da GB/Ora a GB/mese, produce un elevato squilibrio tra prezzo unitario medio di riferimento (valutato come indicato più sopra) e base d’asta. A seguito della modifica apportata, infatti, la tabella sopraindicata si modifica come segue: |
Da tale tabella, infatti, si può evincere lo squilibrio di rapporto tra il prezzo unitario medio di riferimento e la base d’asta: di fatto la nuova base d’asta oscilla tra ca lo 0,17% e ca il 19% del prezzo unitario medio di riferimento (valutato come indicato più sopra), equivalente alla necessità di applicare sconti tra l’81% ed il 99% dal prezzo unitario medio di mercato solo per arrivare alla base d’asta. A fronte di tutto quanto sopra, poiché il quesito n.1034 risulta errato e malposto, inducendo la stazione appaltante ad effettuare una modifica non coerente con la realtà del mercato, si chiede di ripristinare la metrica del precedente capitolato d’oneri, valutando tutti i servizi di Storage in GB/ora e non in GB/mese. RISPOSTA: Si conferma. Pertanto la risposta al chiarimento ID 1034 è da considerarsi un refuso. Si veda errata corrige n.6 con particolare riferimento alla lettera A. | ||
1076 | Capitolato D’oneri – Capitolo 3. OGGETTO DELL’ACCORDO QUADRO, IMPORTO E SUDDIVISIONE IN LOTTI | QUESITO: Con riferimento alla tabella che riporta i prezzi unitari a base d’asta e le relative quantità per il LOTTO 1 e nello specifico, con riferimento alla Categoria Storage, si evidenzia che il Costo Unitario a Base d’asta espresso in GB/mese per tutti e 4 gli elementi di servizio (“File Storage Standard”, “File Storage Premium”, “Block Storage Standard”, “Block Storage Premium”), risulta enormemente più basso dei valori a listino pubblicati dai principali CSP. Lo sconto che andrebbe applicato per poter traguardare il costo unitario a base d’asta espresso in capitolato d’oneri dovrebbe essere superiore al 99,5%; tali scontistiche oltre ad essere impossibili da traguardare tenderebbero ad allineare ai valori di base d'asta tutti i prezzi di uscita dei concorrenti. Si chiede di confermare che la metrica espressa per "GB/mese" è un refuso e che per i quattro servizi precedentemente indicati trova invece applicazione la metrica per "GB/ora". RISPOSTA: Si veda risposta al chiarimento ID 1075 |
1077 | Capitolato D’oneri – Categoria Servizi PaaS | QUESITO: Le offering dei servizi PaaS rendono fruibile i servizi (es. Database, Containers, Application Platforms) attraverso l'utilizzo predeterminato di tagli di vCPU, RAM e storage. L'utente ha a disposizione diverse tipologie di servizio, predeterminati dal CSP, con associati differenti valori di potenza elaborativa (vcpu e RAM) e di storage; per fruire dei servizi l'utente sceglie dal catalogo il servizio PaaS fra i tagli disponibili e specificati in tabella A. Confermare che la rendicontazione del servizio avverrà utilizzando gli elementi di vCPU, RAM e storage inclusi nei servizi PaaS per i diversi tagli ed i prezzi della categoria compute e storage. RISPOSTA: In linea con quanto disciplinato nel Capitolato tecnico speciale lotto 1, si conferma. |
1078 | quesito n.1034 con la relativa risposta e tabella “Oggetto dell'Accordo quadro Lotto 1” del Capitolato d’Oneri_NEW, relativo all’errata | QUESITO: Si inoltra il seguente quesito con la richiesta di una urgente risposta di rettifica.Riferimento: quesito n.1034 con la relativa risposta e tabella “Oggetto dell'Accordo quadro Lotto 1” del Capitolato d’Oneri_NEW, relativo all’errata corrige n.5.Domanda: La risposta al quesito n.1034 ha modificato la tabella Oggetto dell’Accordo Quadro del Lotto 1 del Capitolato d’Oneri, introducendo un cambio di metrica di tutti i servizi Storage da GB/Ora a GB/mese, sulla base della seguente affermazione: ”In relazione al servizio di Object Storage si rappresenta che il valore unitario posto a base d'asta risulta particolarmente elevato rispetto ai |
corrige n.5. | prezzi correnti che si possono riscontrare sul mercato. In particolare, la totalità di CSP offre tale servizio ad un prezzo notevolmente inferiore rispetto a quanto indicato nella documentazione di gara, fino a due ordini di grandezza inferiori”. La modifica apportata, tuttavia, che ha riguardato esclusivamente la metrica (da GB/Ora a GB/mese) mentre sono rimaste invariati prezzo unitario a base d’asta e quantità, di fatto equivale dividere i prezzi unitari a base d’asta per 730 (=365 giorni x 24 ore / 12 mesi) ovvero di 3 ordini di grandezza.Stante gli attuali prezzi di mercato dei servizi Storage applicati dai tre principali provider mondiali (AWS, MS e Google), la suddetta modifica implicherebbe la necessità di ottenere sconti da parte di questi ultimi compresi tra l’80% ed il 99% solo per offrire i prezzi unitari Consip a base d’asta. Poiché ovviamente i suddetti provider non sono disponibili ad applicare tali entità di sconto, il differenziale tra prezzo a base d’asta e costo d’acquisto, moltiplicato per le quantità previste, pari ad oltre 127 miliardi di unità (GB/mese), comporterebbe perdite molto ingenti valutabili fino a miliardi di Euro sul complesso dell’Accordo, impedendo pertanto ai concorrenti la formulazione di un’offerta xxxxxxxxxxxx.Xx scrivente ritiene che si tratti di un errore e si richiede pertanto la rettifica in tempi molto rapidi, almeno per questo particolare aspetto. Questo al fine di permettere alle aziende partecipanti di poter definire con tempi adeguati il proprio business case e poter quindi proporre il proprio miglior listino prezzi alle Amministrazioni. Infatti, qualora la rettifica avvenisse a pochi giorni dalla scadenza, come è talora accaduto per la completa risposta a precedenti quesiti, potrebbe sussistere l’impossibilità per molte aziende di poter completare le indispensabili attività di preparazione e approvazione della propria offerta e di conseguenza impedirebbe la più ampia possibilità di partecipazione alla procedura di affidamento . Questa problematica risulta ancora più evidente visto l’elevato impatto economico del quesito formulato, la complessità del listino da proporre nonché il valore complessivo della gara in oggetto. RISPOSTA: Si veda risposta al chiarimento ID 1075 | |
1079 | Con riferimento al par. 7.2 del Capitolato d’Oneri, lett. b) punti 1 e 2 | QUESITO: Con riferimento al par. 7.2 del Capitolato d’Oneri, lett. b) punti 1 e 2, ed in particolare alla previsione per cui il concorrente deve dimostrare il possesso del requisito di fatturato specifico medio annuo riferito agli ultimi due esercizi finanziari approvati alla data di scadenza del termine per la presentazione delle offerte, in considerazione delle successive proroghe e delle attività già svolte dai concorrenti per accertare il possesso di tale requisito alla data della prima scadenza del termine di presentazione dell’offerta, si chiede di confermare che il possesso del requisito potrà essere dichiarato avendo a riferimento gli ultimi due esercizi finanziari approvati alla prima data di scadenza di presentazione delle offerte (2 marzo 2020). RISPOSTA: Si veda la risposta alla domanda n. 1073 |
1080 | QUESITO: Si chiede di confermare che l’aggiudicatario di uno o più lotti, tra i lotti 2-11, è tenuto a stipulare un’unica polizza assicurativa, di massimale pari a 3.000.000,00 (RCT, RCO e RC Professionale) a copertura di tutti i Contratti Esecutivi eventualmente sottoscritti. RISPOSTA: Il fornitore dovrà presentare idonea polizza assicurativa secondo le prescrizioni dell’Allegato condizione di Assicurazione pertinente al lotto aggiudicato per ogni Appalto specifico contratto con la specifica Amministrazione che ne faccia |
richiesta. | ||
QUESITO: | ||
ID 2213 - IV | Si fa notare alla stazione appaltante come le due risposte ID1068 e ID1069 | |
TRANCHE | sembrino in contraddizione tra loro. Nella ID1068 si conferma la necessità di | |
Xxxxxxxxxxx e | descrivere il servizio di Support, sia per i casi di re-host che di re-purchase. Nella | |
Errata corrige | ID1069 si precisa che per i casi di re-purchase il servizio di Support (M5.1) non | |
ID1068 | debba essere descritto. | |
ID1069 | Xx chiede pertanto di confermare che la ID1068 sia un refuso e che coerentemente | |
con la richiesta del Capitolato Tecnico Speciale Lotti 7-11 per il caso di re-host | ||
1081 | All. 16C - ID 2213 | vadano descritte le fasi M1,M2,M3,M4 ed M5, mentre per il caso di re-purchase |
- Gara Public | vadano descritte solamente le fasi M2,M3,M4 ed M5.2 | |
cloud - | RISPOSTA: | |
Appendice 3 al | Non si conferma. La risposta ID 1068 non è un refuso. Difatti, l'inciso tra | |
CT Speciale L 7- | parentesi della risposta al chiarimento ID 1068 e segnatamente "(per la fasi | |
11 - Scheda | previste dalla trattazione dei casi re-host e re-purchase)" limita la trattazione a | |
Business | quanto specificato nel Capitolato tecnico speciale lotti 7-11 e cioè le fasi | |
cases_NEW | M1,M2,M3,M4 ed M5 per il caso re-host e le fasi M2,M3,M4 ed M5.2 per il re- | |
purchase. | ||
ID 2213 - IV | ||
TRANCHE | ||
Chiarimenti e | ||
Errata corrige | QUESITO: | |
ID1007 | La risposta ID1007 fa riferimento alla risposta ID890 e chiede di confermare che in | |
analogia al chiarimento: “non deve essere migrata l'applicazione interna di | ||
ID 2213 - III | protocollo informatico”, anche l’applicazione Dematerializzazione Atti non sia | |
TRANCHE | oggetto di migrazione. Ma la ID890 fa riferimento alla pag.16 delle schede di BC e | |
Chiarimenti e | quindi alla scheda di re-purchase del Lotto11 dove è presente un’applicazione | |
1082 | Errata corrige n 4 ID890 | interna di protocollo informatico ma non l’applicazione di Dematerializzazione Atti, che invece è presente nel Lotto7 Re-hosting. |
Si chiede quindi di chiarire se la scheda BC Re-hosting del Lotto 7 l’applicazione di | ||
All. 16C - ID 2213 | Dematerializzazione Atti sia o meno oggetto di migrazione. | |
- Gara Public | ||
cloud - | RISPOSTA: | |
Appendice 3 al | L’applicazione di Dematerializzazione Atti, relativa alla scheda BC Re-hosting del | |
CT Speciale L 7- | Lotto 7 non è oggetto di migrazione. | |
11 - Scheda | ||
Business | ||
cases_NEW |
1083 | ID 2213 - IV TRANCHE Chiarimenti e Errata corrige ID1008 | QUESITO: Nella risposta alla domanda, riferita alla scheda di Business case del Lotto2, si conferma come l’applicazione Gestione Documentale sia da intendersi come un sistema composto da Protocollo Informatico e Dematerializzazione Atti, e non come Applicazione autonoma. Si chiede conferma che la risposta sia da ritenersi valida anche per la scheda Business Case di re-hosting del Lotto7, che ha come oggetto un sistema documentale simile a quello del Lotto2. RISPOSTA: Si conferma. |
QUESITO: | ||
TESTO: L’operatore economico indica, ai sensi dell’art. 45, comma 4, del Codice, il | ||
nome e le qualifiche professionali delle persone fisiche incaricate di fornire la | ||
prestazione relativa allo specifico contratto. | ||
In merito alla suddetta indicazione riportata in Capitolato d'Oneri, le seguenti | ||
risposte ai chiarimenti pubblicate nelle diverse tranches sembrano essere | ||
conflittuali: | ||
ID 14/534 – Viene indicato che la richiesta è riferita alle sole figure relative ai Ruoli | ||
di coordinamento, indicati nel cap 2.3.6 del Capitolato Generale. | ||
ID 330 - Non si conferma che tali nominativi debbano essere inseriti in Offerta | ||
Tecnica. | ||
ID 648/701 - Si conferma che tali nominativi saranno da indicare al momento | ||
dell’esecuzione del contratto esecutivo, non essendo possibile in questa fase | ||
conoscere né i tempi, né la relativa consistenza né la eventuale contemporaneità | ||
delle attività da gestire in fase esecutiva. | ||
ID 787 – Si conferma che le figure di cui indicare i nominativi siano quelle relative | ||
ai ruoli di coordinamento ma vengono contraddette parzialmente le risposte | ||
1084 | Capitolato d’Oneri par. 15 - CONTENUTO DELL’OFFERTA TECNICA | precedenti in quanto si fa riferimento alla offerta tecnica e non al contratto esecutivo (come invece indicato alle risposte 648 e 701). ID 829 – Si chiarisce che non è richiesta l'indicazione del nominativo del RUAC in Offerta tecnica. ID 885 - Si riporta il testo integrale del quesito e della risposta: Indicazione nominativo RUAC AQ in OT. I chiarimenti forniscono risposte all’apparenza |
contrastanti. Si chiede di confermare che il nominativo del RUAC AQ non debba | ||
essere inserito in OT, come chiaramente già dichiarato nella risposta al | ||
chiarimento 829, difformemente da quanto indicato nella risposta al chiarimento | ||
787. In caso contrario, si chiede di indicare in quale capitolo dell’offerta tecnica | ||
questa informazione debba essere fornita. RISPOSTA: Si conferma quanto indicato | ||
nel Chiarimento ID 787, in relazione al chiarimento ID 829 non è necessario | ||
indicare il RUAC relativo al Contratto Esecutivo. L'informazione può essere inserita | ||
in ambito del criterio C01. | ||
ID 928 – Si chiede verifica della contraddizione rilevata all'ID 787, ma la risposta si | ||
limita a cosa indicare nel contratto esecutivo e non in offerta tecnica. | ||
DOMANDA: Si chiede di confermare definitivamente che nessun nominativo | ||
relativo alle figure dei ruoli di coordinamento vada indicato in Offerta Tecnica ma | ||
che questi dovranno essere comunicati esclusivamente in sede di Contratto | ||
Esecutivo. | ||
RISPOSTA: | ||
Si conferma che nessun nominativo relativo alle figure va riportato in OT. Si | ||
veda errata corrige n.6 con riferimento alla lettera A. Come previsto dal |
Capitolato tecnico Generale il fornitore dovrà indicare i nominativi del RUAC congiuntamente all’atto della stipula di ciascun Accordo Quadro e di ogni singolo Contratto Esecutivo. | ||
1085 | IV Tranche di chiarimenti ed Errata Corrige – Chiarimento ID 1055 | QUESITO: Nella risposta al chiarimento 1055 si afferma che “Tutti i listini pubblici disponibili apertamente on-line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage. Nessuno dei listini pubblici disponibili apertamente online riporta una logica come quelle esposte dall'OE di licensing "fino a 4" ed "oltre 4" vCPU che sembra invece essere legata a logiche di rivendita commerciale on-premises. Ne consegue che il concorrente dovrà presentare un’offerta che sia congrua e sostenibile per tutta la durata contrattuale dell’Accordo Quadro, sulla scorta delle proprie valutazioni economiche. “ Considerando che nei listini pubblici dei principali cloud service providers il prezzo del sistema Operativo Licensed è legato alla dimensione della macchina virtuale su cui tale sistema operativo viene ospitato, si chiede di poter indicare un prezzo in funzione di CPU e Ram. |
RISPOSTA: Non si conferma. |
1086 | Schema di contratto esecutivo Lotto1 | QUESITO: Nel cap. 12 dello Schema di Contratto Esecutivo si afferma che: “Il Responsabile del trattamento deve mettere a disposizione del Titolare del trattamento tutte le informazioni necessarie per dimostrare il rispetto degli obblighi di cui al Regolamento UE, oltre a contribuire e consentire al Titolare - anche tramite soggetti terzi dal medesimo autorizzati, dandogli piena collaborazione - verifiche periodiche o circa l’adeguatezza e l’efficacia delle misure di sicurezza adottate ed il pieno e scrupoloso rispetto delle norme in materia di trattamento dei dati personali. A tal fine, il Titolare informa preventivamente il Responsabile del trattamento con un preavviso minimo di tre giorni lavorativi, fatta comunque salva la possibilità di effettuare controlli a campione” Si chiede alla SA di chiarire se tali verifiche siano da considerarsi audit fisici presso i datacenter del Cloud Service Provider e in caso di conferma concordare con il Cloud Service Provider la tempistica, escludendo la possibilità di visite senza preavviso. Questa richiesta è motivata dalla necessità di concordare un lasso di tempo congruo per la gestione delle procedure di sicurezza fisica e antintrusione in essere presso i Datacenter, nonché per ridurre rischi per gli altri clienti del CSP. RISPOSTA: Si conferma che potranno essere effettuati anche audit fisici presso i datacenter del CSP. Per quanto riguarda le visite a campione, come indicato nello schema di atto di nomina il Titolare, la stessa è indicata quale possibilità rimessa alle scelte del Titolare che, nel caso di specie, è la singola Amministrazione contraente. Pertanto, come chiarito più volte, lo schema messo a disposizione in sede di AQ è un “format tipo” che può essere adattato da ciascuna Amministrazione con il soggetto contraente anche al fine di contemperare le varie esigenze in tema di audit. |
1087 | Capitolato D’Oneri par. 17.1 | QUESITO: Il requisito R6 stabilisce l'assegnazione di un punteggio pari ad 1 se il Cloud Service provider dimostra la possibilità di istanziare Virtual machine custom (free CPU free RAM) nei limiti delle massime dimensioni disponibili. Si chiede alla SA di confermare, in riferimento al requisito migliorativo R6, che debba essere possibile instanziare VM con qualsiasi combinazione di vCPU e RAM. Nello specifico, tenendo conto che le vCPU partono da 1 e sono incrementabili a multipli di 2, che sia possibile creare VM con 1,2,4,6,8,10,12,14,16 vCPU e qualsiasi taglio di RAM che vada da almeno 1GB a 64 GB, per un totale di almeno 576 combinazioni possibili (9 configurazioni vCPU X 64 configurazioni di RAM). RISPOSTA: Si conferma |
1088 | IV Tranche di chiarimenti ed Xxxxxx Xxxxxxx – Chiarimento ID 1040 | QUESITO: Nella risposta al chiarimento n. 1040 si afferma che ai fini della rendicontazione delle VM le 'risorse assegnate alle VM', in termini di CPU e RAM devono essere conteggiate solo in caso di macchina accesa (power on). In considerazione del fatto che una macchina potrebbe essere creata, accesa per un utilizzo minimale (ad esempio pochi secondi), e poi spenta per un arco temporale ben più ampio (ad esempio un trimestre), si chiede alla SA di confermare che in caso di macchina poweredoff il consumo delle risorse (diverse dallo storage) comunque allocate venga conteggiato ai fini della rendicontazione attraverso un costo forfettario o, in alternativa, che venga cancellata l’istanza. |
RISPOSTA: Non si conferma | ||
1089 | Capitolato tecnico speciale lotto 1 | QUESITO: Nel capitolato tecnico speciale per la categoria DB si specifica che la consuntivazione avverrà tra l’altro sulle risorse consumate a partire dal listino Compute STD e dal listino per la categoria Storage. Tenuto conto che tipicamente i Database richiedono Storage dalle prestazioni elevate e che a listino la tipologia più performante (Premium) viene classificata come avente almeno 1,5 IOPS, si chiede di aggiungere ulteriori categorie Storage tra quelle a listino con caratteristiche più elevate ad esempio almeno 5IOPS e almeno 10 IOPS. RISPOSTA: Non si conferma. Eventuali necessità di performance più elevate rispetto a quelle previste nei c.d. "Servizi di base" possono essere indirizzate tramite Appalto Specifico con riapertura del confronto competitivo. |
1090 | rif. ID 2213 - IV TRANCHE Chiarimenti e Errata corrige, chiarimento 1012 | QUESITO: Con la risposta al chiarimento 1012 è stato introdotto il requisito R2b che prevede un punteggio migliorativo qualora il CSP offra Region con la distanza minima tra loro di 150km (così che ci sia garanzia di protezione “contro eventi disastrosi naturali o causati dall’uomo”) e ma è stato rimosso il requisito di distanza minima tra le Availability Zones di 2,5 kmPerciò, riteniamo evidente che, con il chiarimento 1012, la SA intenda prefigurare uno scenario in cui sarà garantita alle PP.AA. la possibilità di avere la massima resilienza rispetto alla distanza geografica tramite l’implementazione di architetture multi Region; dove, tale soluzione, seppur comunemente accettata in letteratura, ha però il limite che distanze geografiche importanti (come 150 km) possano causare problemi di latenza e quindi downgrade nelle performance.Pertanto, riteniamo che una soluzione che garantisca sia una buona resilienza (in termini di minor rischio geografico) senza problemi di performance sia offrire Region composte da Availability Zones con distanza minima fra ciascuna coppia di 2,5 kmDi conseguenza, considerando quanto sopra descritto, la SA intende inserire un requisito migliorativo per premiare i CSP in grado di garantire 2.5km di distanza minima fra ciascuna coppia di Availability Zone della stessa Region per tutte le Region offerte così da offrire alle PP.AA. un’alternativa altrettanto valida alla implementazione di architetture |
Multi Region? RISPOSTA: Non si conferma. I requisiti fissati garantiscono da un lato resilienza a disastri naturali (distanza tra Region >150km) e dall’altro resilienza ad eventi quali incendi o failure elettrici e/o condizionamento (AZ distribuite su DC fisicamente separati). | ||
QUESITO: Con la risposta al chiarimento 1012 è stato eliminato il requisito minimo di 2.5 | ||
Km di distanza minima tra Availability Zone (AZ) della stessa Region (introdotto | ||
con la risposta al chiarimento 391). Sempre con la risposta al chiarimento 1012 è | ||
stato introdotto il requisito di 150 Km di distanza minima fra le Region offerte. | ||
Avere Availability Zone (AZ) a distanza minima di 2.5 Km per ogni Region, | ||
fornisce agli utenti un servizio di più affidabile rispetto ad un CSP che invece | ||
abbia Region composte da Availability Zone (AZ) limitrofe (edifici separati o data | ||
center su piani diversi dello stesso edificio). L’affidabilità con le AZ distanti | ||
minimo 2.5 Km l’una dall’altra è maggiore: questa configurazione dà maggiore | ||
garanzia e protezioni a seguito di eventi imprevisti locali. Spesso per le | ||
Availability Zone (AZ) i CSP prevedono oltre al raffreddamento, all’alimentazione | ||
1091 | Capitolato d’oneri - 17.1.Criteri di valutazione dell’offerta tecnica | e alla rete indipendenti, anche una distanza geografica dell’ordine dei Km l’una dall’altra con l’intento di garantire maggiormente i profili di rischio. Un cliente che utilizzi un CSP che propone AZ tramite data Center diversi ma ubicati nello stesso edificio o limitrofi, avrebbe e otterrebbe delle garanzie ben |
diverse dal servizio erogato mediante Data Center ubicati ad almeno 2,5 km di | ||
distanza. | ||
Ad Esempio, si ipotizzino 3 Region in diverse nazioni dell’unione Europea, nello | ||
scenario “A” con, in ogni Region, AZ distanti tra loro più di 2,5 Km, nello | ||
scenario “B” con, in ogni Region, AZ distanti tra loro meno di 50 metri: |
Sulla base degli ultimi chiarimenti emerge che una siffatta situazione in presenza di 2 proposte nettamente diverse tra di loro in termini di garanzie, verrebbero trattate, secondo il nuovo schema valutativo, nello stesso modo: |
Si chiede pertanto alla luce dei modificati requisiti, come la stazione appaltante intenda rimodulare questo aspetto che risultava correttamente premiante ante i chiarimenti pervenuti e dare il giusto valore al servizio offerto che risulta comunque più oneroso per il fornitore. RISPOSTA: Si vedano risposta al chiarimento ID 1090 | ||
1092 | Capitolato d’oneri - 17.1. Criteri di valutazione dell’offerta tecnica | QUESITO: Considerando che XxxxXX ha raggiunto la sua end-of-life il 26 Maggio 2020 e non riceverà ulteriori aggiornamenti (xxxx://xxxxxx.xxx/xx/xxx/) si chiede di confermare che il requisito “R9 - OS Support - Linux – CoreOS” non sia più da considerarsi ai fini del calcolo del punteggio dei requisiti migliorativi. RISPOSTA: Si conferma. Si veda Errata corrige n.6 con particolare riferimento alla lettera A. |
1093 | Risposta domanda 1034 e Capitolato d’oneri, tabella “Oggetto dell'Accordo quadro Lotto 1” | QUESITO: Si chiede di confermare che per tutti i servizi di storage gli importi a base d’asta indicati in Costo unitario orario a base d'asta – valore massimo di riferimento, siano da considerarsi in € per GB/ora. Infatti se espressi in € per GB/mese sarebbero un eccessivo ribasso rispetto ai listini pubblici dei CSP, senza tenere in considerazione che spesso il modello di costo dei CSP non è quello richiesto dal capitolato e che quindi, oltre al costo della sola componente di storage, è necessario costruire un business case che consenta di includere anche gli altri elementi di costo previsti per i diversi servizi. Di seguito sono riportati alcuni esempi di confronto tra la base d’asta e l’ordine di grandezza della media dei costi pubblici delle relative componenti di storage dei CSP: - per lo storage premium a blocchi il solo costo della componente di storage (senza considerare le altre componenti di costo, quali ad esempio la replica su almeno 2 AZ) come media di mercato è dell’ordine dei 0,1 €/GB mese contro una base d’asta riportata nell’ultima versione del documento di 0,00060000 €/GB mese. - per il file storage premium il solo costo della componente di storage (senza considerare le altre componenti di costo, quali ad esempio la replica su almeno due AZ) come media di mercato è dell’ordine dei 0,2 €/GB mese contro una base d’asta riportata nell’ultima versione del documento di 0,004 €/GB mese. - per lo storage ad oggetti il solo costo della componente di storage (senza considerare le altre componenti di costo, quali ad esempio letture, scritture e cancellazioni fatte sugli oggetti, policy di gestione del ciclo di vita) come media di mercato è dell’ordine dei 0,025 €/GB mese contro una base d’asta riportata nell’ultima versione del documento di 0,004 €/GB mese. Analogo discorso vale anche per le componenti di storage standard. A fronte delle evidenze sopra riportate, riteniamo che ci sia un rischio molto elevato che i CSP non possano partecipare alla gara con gli attuali prezzi a base d’asta per lo storage. In caso si confermi che per tutti i servizi di storage gli importi a base d’asta indicati in “Costo unitario orario a base d'asta – valore massimo di riferimento”, siano da considerarsi in € per GB/ora e pertanto si chiede di emendare la documentazione di gara. |
RISPOSTA: Si veda risposta al chiarimento ID 1075 | ||
1094 | Risposta al chiarimento 1012 e Capitolato tecnico speciale lotto 1, par 2.2 | QUESITO: Con riferimento alla definizione di Data Center, si chiede di confermare che non sono accettate come “Data Center” diversi dello stesso CSP, soluzioni di sale dati contenute all’interno dello stesso edificio, ad esempio in due piani diversi o in due ali diverse. In altri termini si chiede di confermare che ai fini del presente capitolato è condizione necessaria che due Data Center siano ospitati in edifici distinti affinché siano considerabili come Data Center distinti. RISPOSTA: In linea con quanto disciplinato nel Capitolato tecnico speciale lotto 1, si conferma. |
1095 | Risposta ai chiarimenti 155 e 1012 | QUESITO: Con riferimento alla definizione di Availability Zone come da chiarimento 155 (“Per Availability zone, si intende un insieme di uno o più data center interconnessi con una rete a bassissima latenza (<1ms).”), si chiede di confermare che non sono accettate come “Availability Zone” indipendenti dello stesso CSP soluzioni progettate e allestite all’interno dello stesso edificio. In altri termini si chiede di confermare che ai fini del presente capitolato è condizione necessaria che due Availability Zone siano ospitate in edifici distinti affinché siano considerabili come Availability Zone distinte. RISPOSTA: In linea con quanto disciplinato nel Capitolato tecnico speciale lotto 1, si conferma. |
1096 | Capitolato tecnico speciale lotto 1 – par. 3 “Verifiche tecniche” | QUESITO: Con riferimento alla comprova documentale del requisito R1b, si chiede di confermare che in fase di sottomissione sia sufficiente ai fini della comprova documentale del requisito una dichiarazione ai sensi del DPR 445/2000 e s.m.i. da parte del concorrente offerente relativamente al rapporto DC/AZ per ogni Region offerta. RISPOSTA: Non si conferma. Per il requisito R1b è richiesto che "il Concorrente dovrà altresì produrre in fase di stipula una ulteriore dichiarazione ai sensi del DPR 445/2000 e s.m.i. che i Datacenter offerti risultino tutti presenti nell’infrastruttura cloud qualificata da AgID." (cfr. Capitolato tecnico speciale lotto 1). |
1097 | Risposta ai chiarimenti 391 e 1012 | QUESITO: La risposta al chiarimento 391 introduceva il requisito minimo di 2.5km di distanza minima fra ciascuna coppia di Availability Zone (AZ) della stessa Region. Invece la risposta al chiarimento 1012 ha rimosso tale requisito, introducendo contestualmente il requisito minimo di 150km di distanza minima fra ciascuna coppia di Region proposte, giustificando tale modifica con il fatto che le Region distanti proteggono “contro eventi disastrosi naturali o causati dall’uomo”. Ma un CSP che propone tutte le Region con ciascuna coppia di AZ della stessa Region a distanza minima di 2.5 km offre, per ciascuna Region proposta, già all’interno di una sola Region un servizio di gran lunga più resiliente di un CSP che invece realizzi Region che possono avere AZ semplicemente in edifici separati (ovvero, potenzialmente a distanza di decine di metri o addirittura minore di 10 metri). Il servizio è di gran lunga più resiliente in quanto “zone” distanti minimo 2.5 km l’una dall’altra molto più probabilmente garantiscono profili di rischio idrogeologico distinti (soprattutto se scelte a tale scopo dal CSP), nonché comunque proteggono da qualsiasi tipo di evento che abbia una portata circoscritta nel raggio di poche decine o poche centinaia di metri. A tale scopo alcuni CSP realizzano di proposito le proprie AZ non solo con alimentazione, cooling e rete indipendenti, ma anche a distanza geografica appunto dell’ordine dei km o decine di km l’una dall’altra, e studiando la dislocazione di tali AZ sul territorio per garantire profili di rischio idrogeologico distinti. È chiaro che una Pubblica Amministrazione potrebbe decidere di implementare un’architettura multi Region per ottenere la massima resilienza rispetto alla distanza geografica, e questa è una buona pratica in molti casi. Ma se l’architettura multi Region fosse l’unica soluzione per ottenere resilienza con distanza geografica, questo potrebbe forzare le PP.AA. ad avere una latenza decisamente più elevata (data la distanza di minimo 150 km fra le Region), e in molti casi richiederebbe l’utilizzo di Region in nazioni differenti, con la conseguenza per esempio di non poter avere architetture con un buon grado di resilienza (perché con AZ a distanza non di pochi metri o decine di metri ma bensì di almeno 2.5 km) ma nella stessa nazione (per esempio in Italia in caso di CSP che abbiano Region in Italia) e nella stessa Region. In base alle considerazioni di cui sopra, riteniamo, nell’interesse delle PP.AA. e quindi della SA, che dovrebbe avere carattere di premialità (dato il miglior servizio offerto dai CSP in tal caso) il requisito di 2.5km di distanza minima fra ciascuna coppia di Availability Zone della stessa Region, ove offerto per tutte le Region proposte. Si chiede quindi alla SA se e come intende introdurre il requisito di 2.5km di distanza minima fra ciascuna coppia di Availability Zone della stessa Region, per ogni Region proposta, come criterio migliorativo. RISPOSTA: Non si conferma. Si veda inoltre risposta al chiarimento XX 0000. |
1098 | All. 16A - ID 2213 - Gara Public Cloud - Capitolato tecnico speciale Lotto 1_NEW | QUESITO: In riferimento alle modifiche del paragrafo 3 del Capitolato tecnico speciale Lotto 1 e alla risposta al quesito con identificativo 1012, si chiede alla SA di confermare che per la comprova di ciascuno dei requisiti indicati è sufficiente esibire la seguente documentazione: 1. R2a: Riferimento alla documentazione del CSP che evince la presenza di Cloud Regions nelle aree offerte 2. R2b: Dichiarazione del CSP che dia evidenza dell’area (non necessariamente minima) contenente tutti i DC della Reaion, per esempio “Tutti i DC della Region italiana sono presenti nel raggio di 50 Km dal centro della città di Roma” 3. R1a: Riferimento alla documentazione del CSP che attesti il numero di AZ presenti per ciascuna Region presente nell’offerta 4. R1b: Dichiarazione del CSP che attesti il numero di DC disponibili per ogni Region e attestazione ai sensi del DPR 445/200 e smi che i DC offerti siano presenti nell’infrastruttura cloud qualificata da AgID. RISPOSTA: In relazione ai punti 1,3 e 4 si conferma. In relazione al punto 2, e quindi al criterio R2b, è richiesto che la documentazione presentata dimostri opportunamente quanto definito dal criterio ossia "misurata la distanza tra tutte le AZ di una Region con tutte le AZ di tutte le altre Region, non esistono misurazioni inferiori ai 150 Km". |
1099 | All. 16A - ID 2213 - Gara Public Cloud - Capitolato tecnico speciale Lotto 1_NEW" e risposte alle domande di chiarimento 72, 80, 410 e 414 | QUESITO: All. 16A - ID 2213 - Gara Public Cloud - Capitolato tecnico speciale Lotto 1_NEW" e le risposte alle domande di chiarimento 72, 80, 410 e 414 riportano che per i servizi di Database, Containers e Application Platform “oltre il costo dei singoli servizi/istanza sono da fatturare in aggiunta anche il costo delle risorse computazionali e di storage”.Considerato che i suddetti servizi rientrano in una definizione di servizio PaaS - in linea con quanto richiesto nel capitolato – e del fatto che i cloud provider pubblici prevedono per tali servizi la disponibilità di istanze con caratteristiche computazionali predefinite, si chiede di confermare:1. che il riferimento alle risorse computazionali utilizzate (eg. CPU, RAM, storage, …) è da considerarsi applicabile unicamente in termini di consuntivazione. 2. che le caratteristiche computazionali dei servizi PaaS presentati in offerta devono essere riportate in tabella A nelle relative sezioni. RISPOSTA: Si conferma |
1100 | Capitolato d’Oneri par. 15 - CONTENUTO DELL’OFFERTA TECNICA | QUESITO: TESTO: L’operatore economico indica, ai sensi dell’art. 45, comma 4, del Codice, il nome e le qualifiche professionali delle persone fisiche incaricate di fornire la prestazione relativa allo specifico contratto. In merito alla suddetta indicazione riportata in Capitolato d'Oneri, le seguenti risposte ai chiarimenti pubblicate nelle diverse tranches sembrano essere conflittuali: ID 14/534 – Viene indicato che la richiesta è riferita alle sole figure relative ai Ruoli di coordinamento, indicati nel cap 2.3.6 del Capitolato Generale. ID 330 - Non si conferma che tali nominativi debbano essere inseriti in Offerta Tecnica. ID 648/701 - Si conferma che tali nominativi saranno da indicare al momento dell’esecuzione del contratto esecutivo, non essendo possibile in questa fase conoscere né i tempi, né la relativa consistenza né la eventuale contemporaneità delle attività da gestire in fase esecutiva. |
ID 787 – Si conferma che le figure di cui indicare i nominativi siano quelle relative ai ruoli di coordinamento ma vengono contraddette parzialmente le risposte precedenti in quanto si fa riferimento alla offerta tecnica e non al contratto esecutivo (come invece indicato alle risposte 648 e 701). ID 829 – Si chiarisce che non è richiesta l'indicazione del nominativo del RUAC in Offerta tecnica. ID 885 - Si riporta il testo integrale del quesito e della risposta: Indicazione nominativo RUAC AQ in OT. I chiarimenti forniscono risposte all’apparenza contrastanti. Si chiede di confermare che il nominativo del RUAC AQ non debba essere inserito in OT, come chiaramente già dichiarato nella risposta al chiarimento 829, difformemente da quanto indicato nella risposta al chiarimento 787. In caso contrario, si chiede di indicare in quale capitolo dell’offerta tecnica questa informazione debba essere fornita. RISPOSTA: Si conferma quanto indicato nel Chiarimento ID 787, in relazione al chiarimento ID 829 non è necessario indicare il RUAC relativo al Contratto Esecutivo. L'informazione può essere inserita in ambito del criterio C01. ID 928 – Si chiede verifica della contraddizione rilevata all'ID 787, ma la risposta si limita a cosa indicare nel contratto esecutivo e non in offerta tecnica. DOMANDA: Si chiede di confermare definitivamente che nessun nominativo relativo alle figure dei ruoli di coordinamento vada indicato in Offerta Tecnica ma che questi dovranno essere comunicati esclusivamente in sede di Contratto Esecutivo. RISPOSTA: Si veda risposta al chiarimento ID 1084 | ||
1101 | Chiarimenti IV tranche - ID 1049 | QUESITO: In merito alla risposta di chiarimento con ID 1049 si chiede di chiarire cosa si intende per esecuzione del test. Nello specifico essendo una gara di servizi infrastrutturali non necessariamente il fornitore deve avere competenze di sviluppo applicativo per cui si chiede di confermare che il test sarà effettuato attraverso l'esecuzione del codice infrastrutturale volto ad effettuare il deploy dell'infrastruttura funzionale al webcrawler RISPOSTA: Si conferma |
1102 | Chiarimenti IV tranche - ID 738 e Chiarimenti I tranche - ID 214 | QUESITO: In riferimento alla risposta di chiarimento alla domanda 738 che introduce il requisito minimo di replica tra almeno 2 Availability Zone per tutti i servizi di storage, si chiede di confermare che, analogamente a quanto previsto nella risposta di chiarimento alla domanda 214 relativamente ad esempio alle VM con backup, non sono richieste modalità di aggregazione dei servizi richiedibili dalle Amministrazioni anche con riferimento al servizio di replica dello storage, fermo restante che la CMP deve garantire a queste ultime massima autonomia e tempestività nell'attivazione dei servizi senza la necessità di intervento manuale del CSP. RISPOSTA: Fermo restando che la richiesta di replica dello storage è un meccanismo richiesto di sicurezza intrinseca dei servizi e non una opzione attivabile dalle PPAA, si conferma. |
1103 | Chiarimenti IV tranche - ID 1033 | QUESITO: In riferimento al requisito minimo REQ_DBR_03 per i Database Relazionali e analogamente a quanto confermato per la replica dello storage nella risposta alla domanda di chiarimento 739, si chiede conferma che la "possibilità di configurare alta affidabilità in modalità Master/Slave" si configura come caratteristica inclusa in tutte le tipologie di Database proposte e che il prezzo offerto debba intendersi comprensivo del Database secondario. RISPOSTA: Si veda risposta al chiarimento ID 1117 |
1104 | Capitolato d'Oneri - 3. OGGETTO DELL’ACCORDO QUADRO, IMPORTO E SUDDIVISIONE IN LOTTI | QUESITO: In riferimento al servizio di Database Relazionale si chiede di confermare che il costo per l'Amministrazione sarà formato sommando: - costo unitario di 1 Istanza Database Relazionale inclusiva del Database Secondario e della funzionalità di replica. - costo delle risorse di vcpu, ram, storage e sistema operativo per il DB principale - costo delle risorse di vcpu, ram, storage e sistema operativo per il DB secondario Nel caso di risposta negativa si richiede di specificare come debba essere calcolato il costo del servizio. RISPOSTA: In linea con quanto disciplinato nel Capitolato tecnico speciale lotto 1, il costo per il servizio Database Relazionale verrà consuntivato "sul numero di istanze DB attivate su base oraria e sulle risorse consumate a partire dal listino Compute STD e dal listino per la categoria Storage per le istanze DB relazionale". Si veda inoltre risposta al chiarimento ID 1117 |
1105 | Chiarimenti IV tranche - ID 1034 | QUESITO: Con riferimento alla risposta di chiarimento ID 1034 e alla contestuale errata corrige n.5 il cambio metrica da "ora" a "mese" per tutte le tipologie di storage a parità di valore unitario di base d'asta equivale, nella sostanza, alla riduzione del valore unitario di riferimento di 720 volte (24 ore x 30 giorni). Risulta pertanto che il nuovo valore unitario di riferimento a base d'asta sia notevolmente inferiore rispetto alla media di mercato con una evidente difficoltà dei concorrenti a poter rispettare il vincolo di prezzo proposto non superiore a tale valore. Per altro verso al fine di mantenere invariata la base d'asta complessiva si rileva un incremento delle quantità (pesi) di un fattore pari a 720 volte, ipotizzando un acquisto complessivo di storage da parte delle PPAA dell'ordine di diversi Exabyte. Tali quantità risultano evidentemente sovrastimate e di conseguenza determinano una base d'asta complessiva che non rispecchia i reali e congrui fabbisogni delle Amministrazioni. Si chiede pertanto di riconsiderare la variazione introdotta affinché' il valore unitario di base d'asta sia allineato ad un prezzo di mercato sostenibile e le quantità siano congrue rispetto all’effettivo fabbisogno delle PPAA, al fine di consentire ai concorrenti la presentazione di una soluzione tecnica che ottemperi a quanto richiesto dalla documentazione di gara e consenta ai concorrenti di poter effettuare le proprie valutazioni di redditività dell'offerta basandosi su ipotesi di ricavi realizzabili. Ciò al fine di salvaguardare la legittimità del bando rispetto ai principi stabiliti dalla norma di massima partecipazione alle procedure ad evidenza pubblica e di congruità del valore posto a base d'asta dell'appalto. RISPOSTA: Si veda risposta al chiarimento ID 1075 |
1106 | Capitolato d'Oneri - Par 17.1. Criteri di valutazione dell’offerta tecnica - Requisito R6 - Possibilità di istanziare Virtual machine custom (free CPU free RAM) nei limiti delle massime dimensioni disponibili. | QUESITO: In riferimento al requisito migliorativo R6 si chiede di confermare che debba essere possibile instanziare VM con qualsiasi combinazione di vCPU e RAM. Nello specifico tenendo conto che le vCPU partono da 1 e sono incrementabili a multipli di 2 è quindi possibile creare VM con 1,2,4,6,8,10,12,14,16 vCPU e qualsiasi taglio di RAM che va da almeno 1GB a 64 GB per un totale di almeno 576 combinazioni possibili (9 configurazioni vCPU X 64 configurazioni di RAM). RISPOSTA: Si conferma |
1107 | Capitolato d'Oneri - 24. APPALTI SPECIFICI/ORDINI – LOTTO 1 | QUESITO: Si chiede di confermare che nel momento in cui l'Amministrazione debba utilizzare il configuratore per identificare il fornitore destinatario dell'ordine, i valori di vCPU e di RAM relativi alle VM che intende acquistare saranno ricondotti ai tagli previsti dal Capitolato di Xxxx al fine di poter effettuare il confronto tra le offerte presenti in Accordo Quadro. In caso contrario si chiede di chiarire come il configuratore gestirà i valori di vCPU e di RAM indicati dalla Pubblica Amministrazione qualora tali valori non corrispondano ad una delle combinazioni offerte dai concorrenti. Ciò anche nell'ipotesi in cui i concorrenti non offrano il requisito migliorativo R6. RISPOSTA: Non si conferma. Il configuratore agisce sul totale di vCPU e vRAM richiesti dalle PPAA. Difatti, a prescindere dai diversi tagli disponibili, la somma delle vCPU complessive e della vRAM complessiva ordinata dalle PPAA (e conseguentemente consuntivata) secondo i vari scaglioni consente di normalizzare le eterogenee disponibilità di tagli di VM presenti nei listini dei CSP. |
1108 | Chiarimenti 391 e 1012 | QUESITO: A comprensione della scrivente Società il chiarimento 1012 rimuove il requisito volto a premiare i fornitori in grado di presentare una soluzione che abbia più availability zones distanti tra di loro almeno 2,5km all'interno di una region, sostituendolo con un differente requisito di minima distanza tra le region di 150km. Preme sottolineare come i due requisiti siano da considerarsi, in una ottica di protezione e disponibilità del servizio, non alternativi ma piuttosto complementari andando ciascuno a proteggere differenti casi di rischio. In particolare la disponibilità di più avalability zones (AZ) a distanza superiore a 2,5km consente di garantire un servizio più ridondante all'interno di una region offrendo ad esempio una protezione da rischi che hanno una rilevanza territoriale limitata e comunque inferiore ai 2,5km (i.e. incendi, allagamenti, ...) pur tuttavia garantendo una bassissima latenza tra carichi distribuiti tra differenti AZ.Una distribuzione dei medesimi carichi su più region, garantirebbe si un più elevato livello di disponibilità ma potrebbe - in talune circostanze in cui la latenza introdotta da una distanza di 150km o superiore non sia sostenibile - non essere praticabile.Stante quanto sopra si richiede di reintrodurre, nell'interesse delle PP.AA. un punteggio migliorativo collegato con la possibilità di fruire di AZ la cui distanza in ciascuna region sia superiore a 2,5km |
RISPOSTA: Si veda risposta al chiarimento ID 1090 | ||
1109 | Chiarimenti 999 e 1000 | QUESITO: In riferimento al chiarimento 999 e al chiarimento 1000, poiché è possibile offrire soluzioni sviluppate dal concorrente che integrino e/o estendano le funzionalità offerte nativamente dal CSP utilizzando le standard API messe a disposizione dal CSP stesso, si richiede di confermare che, nel caso in cui un fornitore intenda intraprendere la strada dello sviluppo, le funzionalità oggetto dello stesso - poichè realizzate in fase successiva - potranno essere comprovate in fase di risposta, mediante dichiarazione ai sensi del DPR 445/2000 RISPOSTA: Non si conferma. Le modalità di comprova sono quelle definite nella lex specialis di gara ed in tutti gli allegati al Capitolato d'Oneri. |
1110 | Quesito n 1034 | QUESITO: La risposta al quesito n 1034 ha introdotto un radicale cambio di metrica di tutti i servizi Storage da GB/Ora a GB/mese con la conseguenza di introdurre un notevole squilibrio tra prezzo unitario medio di riferimento e base d’asta. Tenuto conto dei valori correnti di mercato generalmente offerti dalle aziende fornitrici di questo tipo di servizi, la modifica introdotta porta la base d’asta ad essere del tutto fuori mercato e pertanto si chiede di riconsiderare come valida la metrica originariache misurava tutti i servizi di Storage in GB/ora RISPOSTA: Si veda risposta al chiarimento ID 1075 |
1111 | Capitolo 3 del Capitato Tecnico Speciale lotto 1 | QUESITO: In relazione al Capitolo 3 del Capitato Tecnico Speciale lotto 1, a proposito dei test previsti per il "Web Crawler”, si chiede di chiarire se al fornitore è richiesto alternativamente:a) lo sviluppo dell’intera applicazione “Web crawler” sulla base delle specifiche fornite nella documentazione;b) lo sviluppo del codice di automazione infrastrutturale (blueprint), cioè quello necessario al deploy dei servizi di supporto all’applicazione stessa. Quest’ultima sarà invece fornita da una terza parte e quindi non a carico del Fornitore o CSP;c) un disegno architetturale che rappresenti le relazioni tra i componenti applicativi e la loro interazione con il servizi del CSP, tenuto conto del dimensionamento richiesto. RISPOSTA: Sono richiesti i punti b) e c). |
1112 | All. 15 - ID 2213 - Gara Public Cloud - Schema di Offerta Tecnica_NEW | QUESITO: si chiede se in relazione alla modifica ai criteri R1 e R2 non debba essere modificato anche lo schema di offerta tecnica L1, con i nuovi criteri X0x, X0x, X0x, X0x. RISPOSTA: Si conferma. Pertanto il Concorrente potrà suddividere (anche mediante elenco a bullet) i paragrafi relativi alla trattazione dei suddetti criteri. |
1113 | Capitolo 3 del Capitato Tecnico Speciale lotto 1 | QUESITO: Con riferimento alla “verifica tecnica” prevista per il lotto 1, in considerazione della quantità di documentazione da produrre si chiede di chiarire se esista un limite al numero di file che possono essere caricati in relazione ad un singolo campo del portale e se, fatto salvo la dimensione massima di 13 Mb per singolo file, esista un limite dimensionale che non può essere superato dall’offerta nel suo complesso (dato dalla somma di offerta tecnica, offerta economica, doc. amministrativa, doc. di comprova, etc.) RISPOSTA: Il limite è esclusivamente sul singolo documento che non può superare i 13mb. Non esiste alcun limite né di sezione né di offerta complessiva. |
1114 | Capitolato Tecnico Lotto 1 | QUESITO: Il Capitolato Tecnico Lotto 1, nella versione pubblicata il 11/03/2020, al §2.2 indicava in 2,5 KM la distanza minima da prevedersi tra i Datacenter che costituiscono le Availability Zone che appartengono alla stessa Region. Il chiarimento n. 391 - pubblicato il 11/03/2020 - ha confermato tale distanza come requisito minimo per la presente procedura. Il chiarimento n. 1012 e la nuova versione degli atti di gara - pubblicati il 19/05/2020 - hanno completamente rimosso tale requisito. Si sottolinea come una soluzione che preveda una distanza fisica non inferiore a 2,5 KM (come avveniva nella versione del CT Lotto 1 precedentemente citato) tra le Availability Zone di una Region rappresenta con grande evidenza una soluzione migliore rispetto al prevedere una distanza piccola o nulla; cosa che consentirebbe ad esempio che vengano dichiarati come Data Center distinti due edifici limitrofi. Per citare soltanto il principale vantaggio di due Availability Zone che siano realmente lontane fisicamente, si fa notare che in questo caso la garanzia di resilienza della soluzione proposta - a fronte di eventi quali incendio, terremoto, situazioni atmosferiche molto avverse - si baserebbe su dati concreti e verificabili. Ciò premesso, si chiede di introdurre un criterio tecnico che premi esplicitamente tale evidentissimo miglioramento, rispetto ai requisiti minimi di capitolato, oppure di chiarire in quale criterio tecnico sarà valorizzato. RISPOSTA: Si veda risposta al chiarimento ID 1090 |
1115 | I tranche chiarimenti pubblicati in data 11/03/2020; II tranche di chiarimenti pubblicati in data 08/04/2020; III tranche di chiarimenti pubblicati in data 29/04/2020; IV tranche di chiarimenti pubblicati in data 19/05/2020 | QUESITO: DOMANDA: vista la numerosità dei chiarimenti pubblicati nelle tranche sopra riportate, per un totale di 1.072 contenute in 389 pagine di documenti .pdf, e la conseguente difficoltà alla loro consultazione, anche in considerazione dei numerosi rimandi presenti sia nelle domande sia nelle risposte, si chiede alla Spettabile Stazione Appaltante di pubblicare la totalità dei chiarimenti in formato xls al fine di mettere a disposizione dei Concorrenti uno strumento di più facile consultazione anche in analogia a quanto già effettuato nell’ambito di altre gare bandite da Consip. RISPOSTA: Non si conferma. |
1116 | Capitolato d’Oneri cap. 3 - Tabella “Prezzi unitari a base d’asta e le relative quantità per il LOTTO 1” - categoria STORAGE e Chiarimenti Tranche IV - ID 1034 | QUESITO: DOMANDA: con riferimento alla rimodulazione della metrica delle componenti File Storage, Block Storage e Object Storage (prezzo a GB/mese), si fa presente che i prezzi di mercato dei principali CSP per tale categoria sono di due/tre ordini di grandezza superiori a quelli previsti dall’attuale base d’asta tenendo anche in considerazione di quanto riportato al par. 2.4 del Capitolato Tecnico speciale Lotto 1: “Il costo dovrà includere tutte le voci necessarie al pieno utilizzo delle funzionalità del servizio offerto, tra cui operazioni di archiviazione, operazioni di accesso, utilizzo della rete, operazioni di lettura, etc.”. A titolo di esempio si veda la tabella seguente (prezzo base del servizio a cui, in particolare, per Object Storage vanno aggiunti i costi per le operazioni di lettura/scrittura): Si chiede pertanto di rivedere il valore a base d’asta per le componenti d’offerta della categoria Storage tenendo presente dei reali prezzi di mercato. RISPOSTA: Si veda risposta al chiarimento ID 1075 |
1117 | Capitolato Tecnico Speciale Lotto 1 – par. 2.9 Categoria DATABASE/DB Relazionali - REQ_DBR_03 | QUESITO: si chiede di confermare che la configurazione in Alta Affidabilità richiesta con il requisito REQ_DBR_03 è una opzione che deve essere obbligatoriamente offerta ma configurata solo se richiesta dalle Amministrazioni, e pertanto la quotazione offerta per il servizio DB Relazionali si intende espressa per una singola istanza RISPOSTA: Si conferma |
1118 | Capitolato d’Oneri_NEW, par.17.1. Criteri di valutazione dell’offerta tecnica - lotto 8 (C09) pag.82-83. Capitolato Tecnico Generale_NEW, par.1, pag.6. APPENDICE 3 AL CAPITOLATO TECNICO SPECIALE LOTTI 7-11 SCHEDA BUSINESS CASE, pag.2 | QUESITO: TESTO: “La valutazione si baserà sui seguenti elementi: - concretezza, efficacia e valore aggiunto della proposta; - descrizione dei processi di interazione tra l’Amministrazione (PAL) ed i soggetti coinvolti; - approccio metodologico e progettuale; - competenze e soluzioni/strumenti proposti” (PAC 2) Pubblica Amministrazione Centrale “2”- Altri enti (Lotti n. 3 e 8) Nell’ambito della presente iniziativa, i Lotti nn. 3 e 8 sono destinati, relativamente al parametro del “Consolidato ISTAT”, a tutti i soggetti derivanti dalla differenza della precedente lettera A e da quelli indicati dalla precedente lettera B. “In relazione al caso affrontato, la valutazione della proposta si baserà sui seguenti elementi: - concretezza, efficacia e valore aggiunto della proposta; - approccio metodologico e progettuale; - competenze e soluzioni/strumenti proposti.” DOMANDA: Si chiede di chiarire se l’inserimento dell’elemento di valutazione “descrizione di processi di interazione tra l’Amministrazione (PAL) ed i soggetti coinvolti” possa essere considerato un refuso visto che il lotto 8 è riferito a Pubbliche Amministrazioni Centrali e che tale elemento di valutazione non è citato nell’appendice 3 al Capitolato Tecnico speciale lotti 7-11 Scheda Business Case e non compare nel criterio C09 in nessun altro dei lotti del blocco 7-11. RISPOSTA: Si conferma |
1119 | All. 15 - ID 2213 - Gara Public Cloud - Schema di Offerta Tecnica | QUESITO: DOMANDA: Si chiede di indicare se è possibile inserire nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma |
1120 | Capitolato d'Oneri paragrafo 3 | QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziato. RISPOSTA: Si veda risposta al chiarimento ID 1075 |
1121 | Capitolato d'Oneri par. 17.1 | QUESITO: In riferimento al requisito migliorativo R9 si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9. |
1122 | Quesito ID 1048 | QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 |
1123 | Quesito ID 1055 | QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. |
1124 | Capitolato d'Oneri NEW | QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. |
1125 | Capitolato d'Oneri NEW e quesito ID 1012 | QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al |
singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di |
servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 il provider debba permettere, in fase di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Region. RISPOSTA: Non si conferma. Il criterio R1b rappresenta un grado di resilienza aggiuntivo rispetto ad avere AZ composte da un singolo DC. | ||
1126 | Capitolato d'Oneri NEW e quesito ID 1012 | QUESITO: In risposta al quesito # 1012, la SA afferma che: “la numerosità dei Datacenter su cui insistono le AZ di una Region influisce positivamente su caratteristiche di sicurezza, resilienza e performance dei servizi offerti”. Si vuole far notare che nella pratica la numerosità dei datacenter non influisce positivamente né sulla sicurezza e né sulle performance dei servizi offerti. La resilienza dei servizi viene normalmente garantita dalle Availability Zones e da tecniche di ridondanza che il provider implementa all’interno delle stesse e che non hanno nessuna diretta correlazione con il numero di edifici di cui è composta una Availability Zone. In alcuni casi è previsto un ulteriore livello di isolamento (cluster o fault‐domain) all’interno della singola Availability Zone che garantisce l’anti‐affinity a livello hardware (utilizzo di HW differenti su Cluster/Fault domain differenti) e risorse elettriche indipendenti e ridondate. Il cliente può esplicitamente scegliere come distribuire e ridondare la propria applicazione sui diversi Fault Domain / Clusters anche all’interno della singola AZ. Si chiede quindi di: a) eliminare i punteggi premianti relativi alla numerosità dei Datacenter – R1b (livello di astrazione inesistente a livello internazionale per i più importanti CSP) b) introdurre eventuali punteggi premianti per il provider che eroghi un livello ulteriore esplicito (visibile al cliente) di alta affidabilità all’interno della singola AZ (clusters, fault‐domains) c) reintrodurre la possibilità di utilizzo di Regions con singolo AZ e Fault‐domains/clusters multipli RISPOSTA: Non si conferma. Si tengano presenti le risposte ai chiarimenti ID 1124 e 1125 |
Xxx. Xxxxxxxxx Xxxxxxxx
(L’Amministratore Delegato)
Firmato digitalmente da XXXXXXXX XXXXXXXXX C=IT
O=CONSIP SPA