RÁMCOVÁ DOHODA
RÁMCOVÁ DOHODA
Realizace a podpora SDDC pro účely kritické infrastruktury – část 1
Číslo smlouvy objednatele: PPR-9216-22/ČJ-2022-990656
Číslo smlouvy dodavatele: J220020/2022
Smluvní strany:
Česká republika – Ministerstvo vnitra
Sídlo: Nad Xxxxxx 000/0, XXX 000 00, Xxxxx
IČO: 00007064
DIČ: CZ00007064
Zastoupená: plk. Mgr. Xxxxxxxxxxx Xxxxxx, ředitelem Ředitelství pro podporu
výkonu služby Policejního prezidia České republiky
Korespondenční adresa: Policejní prezidium ČR, Ředitelství pro podporu výkonu služby,
xxxxxxxx xxxxxxxx 00/ XXXX, 000 00 Xxxxx 0 (dále jen „Objednatel“ nebo „Zadavatel“)
a
ALWIL Trade, spol. s r.o.
Sídlo: Xxxxxxxxxx 0, 000 00 Xxxxx 00
IČO: 16188641
DIČ: CZ16188641
Zastoupená: ednatelem
Bankovní spojení: UniCredit Bank Czech Republic and Slovakia, a.s.
č. účtu: 249978004/2700
Korespondenční adresa: Xxxxxxxxxx 0, 000 00 Xxxxx 00
Obchodní společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze,
xxxxx X, xxxxxx 1553
(dále jen „Dodavatel“)
(společně dále také jen „Smluvní strany“, nebo jednotlivě „Smluvní strana“)
uzavřely v souladu s ustanoveními zákona č. 89/2012 Sb., občanský zákoník, (dále jen „občanský zákoník“) a zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen „ZZVZ“), a příslušnými ustanoveními zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (dále jen „autorský zákon“) a zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (dále jen „zákon o kybernetické bezpečnosti“) a jeho prováděcích předpisů tuto
Rámcovou dohodu
Realizace a podpora SDDC pro účely kritické infrastruktury – část 1
(dále jen „Dohoda“)
PREAMBULE
1. Tato Dohoda je uzavřena na základě výsledků zadávacího řízení, které bylo uskutečněno dle ust. zákona č. 134/2016 Sb., o zadávání veřejných zakázek k veřejné zakázce s názvem “Realizace a podpora SDDC pro účely kritické infrastruktury – Rámcová dohoda“ č.j. PPR- 9216-4/ČJ- 2022-990656 (dále též „Veřejná zakázka“).
2. Dílčí veřejné zakázky budou zadávány postupem dle ustanovení § 132 ZZVZ, na základě něhož budou s Dodavatelem uzavřeny jednotlivé Prováděcí smlouvy. Tato Rámcová dohoda vymezuje obecné obchodní podmínky v budoucnu uzavřených Prováděcích smluv. Tato Xxxxxxx dohoda se uzavírá s jedním Dodavatelem.
3. Účelem této Dohody je zajištění služeb a podpory pro realizaci, provoz a udržitelnost cloudové infrastruktury dle konceptu SDDC (softwarově definované datové centrum) a konceptu privátního Cloudu Objednatele, v rámci něhož budou provozovány kritické informační systémy a systémy KII a VIS (KII – kritická informační infrastruktura a významné informační systémy podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, dále jen „ZKB“).
1. PŘEDMĚT DOHODY
1.1. Dodavatel se zavazuje poskytnout Objednateli plnění specifikované touto Dohodou a jejími přílohami, dle podmínek a v rozsahu stanoveném touto Dohodou. Dodavatel na základě této Dohody dodá zejména následující plnění:
I. Plnění A – Realizační, rozvojové, provozní a konzultační služby (variabilní část)
a) Plnění A1 – Implementační, konfigurační a konzultační služby (dále také jen „Plnění A1“)
b) Plnění A2 – Služby realizace a rozvoje infrastruktury SDDC (dále také jen „Plnění A2“)
(souhrnně dále také jen „Plnění A“), blíže definováno v Příloze č. 1;
II. Plnění B – Služby provozní podpory (fixní část)
a) Plnění B1 – Služby provozní podpory – Primární datové centrum (dále také jen „Plnění B1“)
b) Plnění B2 – Služby provozní podpory – Vzdálené datové centrum (dále také jen „Plnění B2“)
c) Plnění B3 – Služby provozní podpory – EDGE datové centrum (dále také jen „Plnění B3“)
(souhrnně dále také jen „Plnění B“), blíže definováno v Příloze č. 1; (Plnění A a Plnění B souhrnně dále též „Předmět plnění“).
1.2. Podrobná specifikace Předmětu plnění je uvedena v Příloze č. 1 této Dohody.
1.3. Objednatel se za řádně poskytnuté plnění zavazuje Dodavateli zaplatit cenu sjednanou v této Dohodě a podrobně specifikovanou v Příloze č. 2 této Dohody.
2. POSTUP PŘI UZAVÍRÁNÍ PROVÁDĚCÍCH SMLUV
2.1. Na základě této Rámcové dohody budou zadány dílčí veřejné zakázky, jejichž výsledkem bude uzavření Prováděcí smlouvy, postupem stanoveným touto Dohodou, a to, následujícím postupem:
Objednatel písemně vyzve Dodavatele k podání nabídky. Výzva k podání nabídky musí obsahovat alespoň tyto náležitosti:
a) identifikační údaje Objednatele;
b) podrobnou specifikaci požadovaného plnění (v případě Plnění A může být podrobnou specifikací plnění míněno stanovení počtu MD jednotlivých rolí na čerpání variabilních služeb dle ceníku obsaženého v Dohodě v období stanoveném v příslušné Prováděcí smlouvě s detailní specifikací způsobu objednávání jednotlivých služeb);
c) místo a dobu požadovaného plnění;
d) podpis a označení osoby oprávněné podat výzvu;
e) číslo výzvy;
f) lhůtu, způsob a místo pro podání nabídek.
2.2. Dodavatel je povinen na základě výzvy k podání nabídky doručit Objednateli ve lhůtě stanovené ve výzvě svou nabídku. Minimální lhůta stanovená pro doručení nabídky je 5 dní od doručení výzvy Dodavateli. Nabídka Dodavatele bude obsahovat vyplněný návrh Prováděcí smlouvy, jejíž vzor je uveden v Příloze č. 3 této Dohody.
2.3. Nabídka Xxxxxxxxxx nesmí být v rozporu s touto Rámcovou dohodou. Dodavatel není oprávněn navrhnout ve své nabídce smluvní podmínky, které budou pro Objednatele méně výhodné v porovnání s jeho nabídkou v Zadávacím řízení a touto Dohodou.
3. CENA ZA PLNĚNÍ
3.1. Objednatel má povinnost zaplatit Dodavateli za řádně poskytnuté plnění sjednanou cenu.
3.2. Podrobné určení jednotkových cen pro Plnění A a Plnění B je uvedeno v Příloze č. 2 této
Dohody.
3.3. Celková cena plnění dle Prováděcích smluv uzavřených dle této Dohody (tj. součet smluvních cen uzavřených prováděcích smluv) nesmí přesáhnout 215 810 000,00 Kč bez DPH (dvěstěpatnáctmiliónůosmsetdesettisíc korun českých), 261 130 100,00 Kč s DPH ( dvěstěšedesátjedenmiliónjednostotřicettisícjednosto korun českých).
3.4. Smluvní strany se dohodly, že cena za plnění dle konkrétní Prováděcí smlouvy je cenou konečnou, nejvýše přípustnou, nepřekročitelnou. Pokud není Rámcovou dohodou, nebo příslušnou Prováděcí smlouvou stanoveno jinak, sjednaná cena zahrnuje veškeré náklady, které Dodavateli v souvislosti s řádným poskytováním dohodnutého plnění vzniknou, vč. veškerých licenčních poplatků, nákladů na dopravu, cel, nákladů na balení, doručení apod., a jsou v nich zohledněna rizika, bonusy, slevy a další vlivy ve vztahu k celkové době plnění dle této Dohody.
3.5. Cena plnění bude upravena o případnou zákonnou procentní změnu DPH, a to ode dne účinnosti změny.
3.6. Veškeré ceny dohodnuté v této Dohody a Prováděcích smlouvách jsou ceny v korunách českých.
4. PLATEBNÍ PODMÍNKY
4.1. Dodavatel je povinen vystavit platební doklad (tzv. fakturu) do 10 dnů ode dne podpisu příslušného akceptačního protokolu oběma Smluvními stranami.
4.2. Dodavatel je oprávněn vystavit fakturu za poskytnuté dílčí plnění, a to vždy za uplynulé kalendářní čtvrtletí, na základě dílčího akceptačního protokolu, pokud není v Prováděcí smlouvě stanoveno jinak. V případě dílčího plnění je datem uskutečnění zdanitelného plnění poslední kalendářní den příslušného kalendářního čtvrtletí, to neplatí v posledním čtvrtletí, ve kterém je poskytováno plnění dle smlouvy, když datem uskutečnění zdanitelného plnění je poslední den poskytnutého plnění v daném čtvrtletí.
4.3. Splatnost faktury je 30 dnů od data jejího prokazatelného doručení Objednateli na adresu uvedenou v Dohodě, s výjimkou případu, kdy faktura doručená v termínu od 1. 12. daného roku do 31. 1. následujícího roku je splatná ve lhůtě 60 dnů od data jejího prokazatelného doručení Objednateli.
4.4. Faktura musí obsahovat číslo této Dohody a náležitosti řádného daňového dokladu podle příslušných právních předpisů, zejména pak zákona o dani z přidané hodnoty v platném znění a náležitosti obchodní listiny dle občanského zákoníku. V případě, že faktura nebude mít odpovídající náležitosti nebo nebude vystavena v souladu s touto Dohodou, je Objednatel oprávněn zaslat ji zpět k doplnění Dodavateli, aniž se dostane do prodlení se splatností, lhůta splatnosti počíná běžet znovu od opětovného doručení náležitě doplněné či opravené faktury Objednateli.
4.5. Adresa Objednatele pro doručení daňového dokladu je: Policejní prezidium ČR, Ředitelství pro podporu výkonu služby, Strojnická 27, poštovní schránka 62/ŘPVS, 170 89 Praha 7
4.6. Fakturovaná částka se považuje za uhrazenou okamžikem odepsání příslušné finanční částky z bankovního účtu Objednatele uvedeného v Prováděcí smlouvě v prospěch bankovního účtu Dodavatele uvedeného v Prováděcí smlouvě.
4.7. Objednatel je oprávněn od faktury Dodavatele odečíst své splatné pohledávky za Dodavatelem, které vzniknou v souvislosti s plněním dle této Dohody, resp. Prováděcí smlouvy.
4.8. Přílohou faktury za poskytnuté plnění je vždy originál akceptačního protokolu podepsaného pověřenými zástupci obou Smluvních stran, jinak Objednatel nebude fakturu Dodavatele akceptovat. Akceptační protokol obsahuje přehled poskytnutého plnění, tak aby bylo možné poskytnuté plnění jednoznačně identifikovat.
4.9. Akceptační protokol musí obsahovat alespoň:
- označení čísla Dohody a Prováděcí smlouvy;
- předmět poskytnutého plnění;
- datum převzetí, resp. akceptace;
- identifikace osob pověřených akceptační protokol za Smluvní strany podepsat;
4.10. Objednatel neposkytuje Dodavateli finanční zálohy na předmět plnění.
5. DOBA, MÍSTO A PODMÍNKY PLNĚNÍ DODÁVEK
5.1. Místem plnění dle této Dohody jsou zejména lokality Objednatele umístněné v České republice. Konkrétní místo plnění bude vždy specifikováno v jednotlivé Prováděcí smlouvě.
5.2. Řádně a včas dodaný Předmět plnění dle odst. 1.1. Dohody je předán okamžikem akceptace, tj. podpisem závěrečného akceptačního protokolu oběma Smluvními stranami, resp. dílčího akceptačního protokolu. Podpisu akceptačního protokolu může předcházet akceptační řízení, tak jak je definováno v přílohách Dohody, nebo v příslušné Prováděcí smlouvě.
5.3. Dodavatel je povinen při předání předmětu plnění Objednateli předat veškerou dokumentaci související s předmětem plnění, a to zejména technickou dokumentaci, včetně detailního popisu dodaného řešení a popisu adaptérů pro komunikaci, návody na obsluhu a údržbu, záruční listy, uživatelský manuál, a to v českém jazyce.
5.4. Termíny plnění budou upraveny v konkrétních Prováděcích smlouvách s tím, že
- Plnění A (tj. Plnění A.1 až A.2) – dle termínu uvedeného v dílčích Prováděcích smlouvách s tím, že Xxxxxxxxx je povinen zahájit požadované činnosti ve lhůtě nejdéle do 5 pracovních dní od účinnosti Prováděcí smlouvy, pokud nebude v Prováděcí smlouvě stanoveno jinak.
- Plnění B (tj. B.1 až B.3) – od účinnosti prováděcí smlouvy zpravidla na období 12 měsíců, pokud nebude v Prováděcí smlouvě stanoveno jinak.
6. ZÁRUČNÍ PODMÍNKY A ODPOVĚDNOST ZA VADY
6.1. Dodavatel zaručuje a odpovídá za to, že předané plnění:
a) odpovídá sjednané specifikaci;
b) je bez faktických vad;
c) je bez právních vad.
6.2. Dodavatel poskytuje Objednateli záruku na předmět plnění na dobu uvedenou v Příloze č. 1 této Dohody, pokud není v jednotlivé Prováděcí smlouvě stanoveno jinak. Zárukou přejímá Dodavatel závazek, že dodané plnění bude po tuto dobu způsobilé pro použití ke smluvenému, jinak k obvyklému účelu, a že si zachová smluvené, jinak obvyklé vlastnosti. Objednatel je povinen záruční vady oznámit Dodavateli neprodleně od jejich zjištění. Záruční doba neběží po dobu, po kterou trvá vada, za kterou odpovídá Dodavatel, a to od doby oznámení vady Objednatelem až do jejího úplného odstranění Dodavatelem. Dodavatel je povinen odstranit vadu dle podmínek specifikovaných v jednotlivých Prováděcích smlouvách.
6.3. Dodavatel odpovídá za to, že plněním této Dohody nebude zasaženo do práv třetích osob, a to včetně práv k předmětům duševního vlastnictví.
6.4. Záruka za plnění se nevztahuje na případy a situace, které potenciálně nastanou v důsledku legislativních nebo provozně-technických změn nezávislých na vůli Smluvních stran oproti podmínkám sjednaným touto Dohodou.
6.5. Dodavatel neodpovídá za vady plnění způsobené vyšší mocí, neoprávněným zásahem či opomenutím Objednatele nebo třetí osoby na straně Objednatele v rozporu s dokumentací, písemně prokazatelně předanými doporučeními výrobce nebo Dodavatele.
6.6. Plnění má vady, jestliže nebylo dodáno v souladu s touto Dohodou. Za vady se považují i
vady v návodech k použití, dokladech a dokumentech.
6.7. Objednatel uplatní požadavek na odstranění vady na helpdesk Dodavatele, pokud se Smluvní strany nedomluví jinak.
6.8. Uplatněním nároku z odpovědnosti za vady není dotčen nárok Objednatele na náhradu újmy.
6.9. Veškeré činnosti související s odstraněním vady činí Dodavatel sám na své náklady (včetně nákladů na dopravu) v součinnosti s Objednatelem tak, aby svými činnostmi neohrozil nebo neomezil činnost Objednatele.
6.10. V případě opravy zařízení, které obsahuje paměťové médium, které bylo součástí předmětu plnění, tak jednotlivá paměťová média zůstávají po dobu opravy zařízení ve vlastnictví a v držbě Objednatele. V případě závady na paměťovém médiu se Dodavatel zavazuje nahradit nefunkční zařízení novým paměťovým médiem s tím, že vadné paměťové médium zůstává ve vlastnictví a v držbě Objednatele.
6.11. Další podmínky záruky a specifikace poskytování záručních oprav jsou stanoveny v Příloze č. 1 Dohody u jednotlivých částí Plnění. Příloha č. 1 může definovat podmínky záruky odlišně od čl. 6 Dohody, v takovém případě má přednost ustanovení uvedené v Příloze č. 1 Dohody.
7. SANKCE
7.1. V případě prodlení Dodavatele s poskytnutím plnění dle této Dohody vzniká Objednateli nárok na smluvní pokutu ve výši 0,15 % z celkové ceny nedodaného plnění s DPH dle příslušné Prováděcí smlouvy, a to za každý den prodlení, pokud není v Příloze č. 1 Dohody uvedeno jinak.
7.2. Pokud není v Dohodě, nebo v textu příloh, v příslušné Prováděcí smlouvě stanoveno jinak, Dodavatel je povinen zaplatit smluvní pokutu za každé porušení stanovených smluvních povinností ve výši 50 000,- Kč za každé jednotlivé porušení. Příloha č. 1 stanoví další sankce za porušení povinností Dodavatele.
7.3. V případě prodlení Objednatele s úhradou řádně vystavených a doručených faktur, je Dodavatel oprávněn požadovat zákonný úrok z prodlení.
7.4. Smluvní strany se dohodly, že závazek zaplatit smluvní pokutu nevylučuje právo na náhradu újmy, a to v rozsahu, který přesahuje částku smluvní pokuty. Dodavatel odpovídá za způsobenou újmu maximálně do výše 200 000 000,- Kč (dvě stě milionů korun českých). Není-li stanoveno jinak, zaplacení jakékoliv sjednané smluvní pokuty nebo slevy z ceny nezbavuje povinnou Smluvní stranu povinnosti splnit své závazky.
7.5. Úrok z prodlení a Smluvní pokuta je splatná ve lhůtě 30 dnů od dne doručení písemné výzvy oprávněné Smluvní strany k její úhradě povinnou Smluvní stranou, není-li ve výzvě uvedena lhůta delší.
8. PODDODAVATELÉ
8.1. Dodavatel je oprávněn poskytovat plnění dle této Dohody prostřednictvím poddodavatele pouze v rozsahu, v jakém si toto právo vyhradil v rámci podání nabídky v zadávacím řízení na Veřejnou zakázku, a pouze prostřednictvím tam uvedených poddodavatelů. Ve všech ostatních případech je Dodavatel oprávněn poskytovat plnění prostřednictvím poddodavatele pouze s předchozím písemným souhlasem Objednatele.
8.2. Za plnění poddodavatelů Dodavatel odpovídá jako za své plnění, včetně odpovědnosti za důsledky vzniklé.
9. MLČENLIVOST A DŮVĚRNÉ INFORMACE
9.1. Smluvní strany se zavazují, že nezpřístupní třetí osobě důvěrné informace, okolnosti a údaje, které se dozvěděly nebo získaly v souvislosti s realizací předmětu plnění této Dohody, ani je neposkytnou jiným osobám bez předchozího výslovného souhlasu druhé Smluvní strany.
9.2. Za důvěrnou informaci se rovněž považuje obchodní tajemství ve smyslu občanského zákoníku. Pro vyloučení pochybností se za důvěrnou informací dle této Dohody považuje veškerá technická, provozní, bezpečností apod. dokumentace týkající se předmětu plnění dle této Dohody. Objednatel je rovněž oprávněn označit za důvěrnou taky informaci, dokument, zprávu, která není výslovně uvedena v čl. 10 Dohody, o této skutečnosti Xxxxxxxxxx informuje.
9.3. Informace poskytnuté Dodavatelem Objednateli v souvislosti s realizaci předmětu plnění této Dohody se považují za důvěrné, pouze pokud na jejich důvěrnost Dodavatel Objednatele předem písemně upozornil a Objednatel Dodavateli písemně potvrdil svůj závazek zachovávat důvěrnost těchto informací. Pokud jsou důvěrné informace Dodavatele poskytovány v písemné podobě anebo ve formě textových souborů na elektronických nosičích dat (médiích), je Dodavatel povinen upozornit Objednatele na důvěrnost takového materiálu též jejím vyznačením alespoň na titulní stránce nebo přední straně média.
9.4. Smluvní strany se v této souvislosti zavazují poučit veškeré osoby, které se na jejich straně budou podílet na plnění této Dohody, o povinnostech mlčenlivosti a ochrany důvěrných informací uvedených v článku 10 Dohody a dále se zavazují vhodným způsobem zajistit dodržování těchto povinností všemi osobami podílejícími se na plnění této Dohody.
9.5. Za důvěrné informace Objednatele se dále bezpodmínečně považují veškerá data, která obsahuje informační systém Objednatele, která do něj mají být, byla nebo budou Dodavatelem, Objednatelem či třetími osobami vložena i data, která z něj byla získána. Bez ohledu na ostatní ustanovení této Dohody jsou za důvěrné informace Objednatele považovány též zdrojové kódy systému Objednatele, jejichž poskytnutí třetí osobě by mohlo ohrozit bezpečnost dat Objednatele v tomto systému.
9.6. Bez ohledu na výše uvedená ustanovení se za důvěrné nepovažují informace, které:
a) se staly veřejně známými, aniž by jejich zveřejněním došlo k porušení závazků Smluvní strany či právních předpisů;
b) měla přijímající Smluvní strana prokazatelně legálně k dispozici před uzavřením této Dohody, pokud takové informace nebyly předmětem jiné, dříve mezi Smluvními stranami uzavřené smlouvy o ochraně informací
c) jsou výsledkem postupu, při kterém k nim přijímající Smluvní strana dospěje nezávisle a je to schopna doložit svými záznamy nebo důvěrnými informacemi třetí strany;
d) po podpisu této Dohody poskytne přijímající Smluvní straně třetí osoba, jež není
omezena v takovém nakládání s informacemi.
9.7. Právo užívat, poskytovat a zpřístupnit důvěrné informace mají Smluvní strany pouze v rozsahu a za podmínek nezbytných pro řádné plnění práv a povinností vyplývajících z této Dohody, a to způsobem definovaným v bezpečnostních politikách Objednatele.
9.8. Ujednání této Dohody upravující ochranu důvěrných informací se nevztahují na skutečnosti, které je nutno zveřejnit, poskytnout nebo sdělit dle platných právních předpisů včetně práva EU nebo závazného rozhodnutí oprávněného orgánu. Dodavatel výslovně souhlasí se zveřejněním celého textu Dohody, včetně všech Příloh.
9.9. Ukončení účinnosti této Dohody z jakéhokoliv důvodu se nedotkne ustanovení tohoto článku Dohody a účinnost včetně ustanovení o sankcích přetrvá bez omezení i po ukončení účinnosti této Dohody.
9.10. V případě porušení povinností dle tohoto článku č. 10 Dohody je Xxxxxxxxx povinen zaplatit
Objednateli smluvní pokutu ve výši 500 000,- Kč za každé porušení.
10. ÚČINNOST DOHODY A ODSTOUPENÍ
10.1. Rámcová dohoda se uzavírá na dobu určitou, a to na čtyři (4) roky od účinnosti této Dohody, nebo do vyčerpání celkové ceny plnění ve výši 215 810 000,00 Kč bez DPH (vyčerpáním se rozumí součet jednotlivých smluvních cen dle uzavřených Prováděcích smluv) dle toho, která skutečnost nastane dříve. Skončení účinnosti této Dohody nemá vliv na účinnosti jednotlivých, již uzavřených Prováděcích smluv.
10.2. Ukončením účinnosti této Dohody nejsou dotčena ustanovení Dohody týkající se převodu vlastnického práva a užívacích práv, nároků z odpovědnosti za vady, nároků z odpovědnosti za újmu a nároků ze smluvních pokut, ustanovení o ochraně informací, ani další ustanovení a nároky, z jejichž povahy vyplývá, že mají trvat i po zániku účinnosti této Dohody.
10.3. Rámcovou dohodu, resp. Prováděcí smlouvu lze dále ukončit následujícími způsoby:
a) písemnou dohodou Smluvních stran, jejíž součástí bude i vypořádání vzájemných závazků a pohledávek;
b) písemným odstoupením jedné Smluvní strany doručeným druhé Smluvní straně
v souladu s touto Dohodou.
10.4. Každá ze smluvních stran může od této Dohody, resp. Prováděcí smlouvy odstoupit v případech stanovených touto Dohodou nebo zákonem, zejména pak dle ust. § 1977 a násl. a ust. § 2002 a násl. občanského zákoníku. Účinky odstoupení od Dohody Prováděcí smlouvy nastávají dnem doručení oznámení o odstoupení příslušné Smluvní straně.
10.5. Smluvní strany jsou oprávněné odstoupit od této Dohody, resp. Prováděcí smlouvy i pro nepodstatné porušení smlouvy dle příslušných ustanovení občanského zákoníku. V případě nepodstatného porušení smluvní povinnosti, může druhá Smluvní strana od Dohody odstoupit poté, co strana, která se dopustila nepodstatného porušení smluvní povinnosti, svoji povinnost nesplní ani v dodatečné přiměřené lhůtě, kterou jí druhá Smluvní strana poskytla.
10.6. Objednatel je dále oprávněn odstoupit od Dohody, resp. Prováděcí smlouvy, jestliže bylo vydáno rozhodnutí o úpadku Dodavatele v insolvenčním řízení nebo Dodavatel sám podá dlužnický návrh na zahájení insolvenčního řízení; Xxxxxxxxx vstoupí do likvidace nebo dojde k jinému, byť jen faktickému podstatnému omezení rozsahu jeho činnosti, který by mohl mít negativní dopad na jeho způsobilost plnit závazky podle této Dohody.
10.7. Objednatel má právo odstoupit od Dohody, resp. Prováděcí smlouvy také tehdy, pokud Dodavatel přestane splňovat podmínky základní a profesní způsobilosti nebo technické kvalifikace stanovených v zadávacích podmínkách na realizaci této Veřejné zakázky.
11. KOMUNIKACE SMLUVNÍCH STRAN, OPRÁVNĚNÉ OSOBY
11.1. Veškerá komunikace mezi Smluvními stranami bude probíhat prostřednictvím oprávněných osob stanovených zákonem, touto Dohodou, resp. Prováděcí smlouvou nebo jimi pověřených zástupců. Osoby oprávněné podepsat příslušné akceptační protokoly budou určeny v konkrétní Prováděcí smlouvě.
11.2. Kromě zákonných zástupců Smluvních stran, další kontaktní osoby oprávněné jednat ve věcech plnění poskytovaného dle této Dohody:
za Dodavatele: za Objednatele:
11.3. V případě, že dojde ke změně oprávněných osob nebo kontaktních údajů u nich uvedených, jako je e-mail, tel., apod., povinná strana doručí písemné oznámení o této změně druhé Smluvní straně bez zbytečného odkladu.
12. LICENCE
12.1. V případě, že předmětem plnění dle této Dohody je i plnění, které naplňuje znaky autorského díla dle zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (dále jen „autorský zákon“), Objednatel má k tomuto dílu jako celku i k jeho jednotlivým částem následující licenci:
a) Objednatel má nevýhradní, přenosné, časově a územně neomezené právo užít autorské dílo ke všem způsobům užití v neomezeném rozsahu. Objednatel má právo autorské dílo zpracovávat, upravovat či jinak měnit, a to i prostřednictvím třetích osob. Objednatel je oprávněn tuto licenci ve formě sublicence poskytnout třetí osobě, nebo ji na třetí osobu převést, a to v celém rozsahu, nebo jenom ohledně určitých práv vyplývajících z licence.
b) Účinek poskytnuté licence nastává okamžikem předání plnění dle této Dohody, do okamžiku předání je Objednatel oprávněn autorské dílo užít v rozsahu a způsobem nezbytným k provedení akceptace příslušného plnění;
c) V případě, že předmětem plnění je tzv. software vytvořený na zakázku, tedy software vytvořený pro účely plnění této Dohody, licence dle tohoto článku Dohody se vztahuje i na zdrojové kódy, včetně přípravných koncepčních materiálů k takovému software. Dodavatel je povinen při předání plnění dle této Dohody, tedy před podpisem akceptačního protokolu nebo protokolu o převzetí software vytvořeného na zakázku, předat Objednateli aktuální verzi komentovaných zdrojových kódů, včetně přípravných koncepčních materiálů v elektronické i tištěné formě, a to v takovém rozsahu a podobě, aby Objednatel sám, nebo prostřednictvím třetí osoby, mohl případně převzít další rozvoj takového software vytvořeného na zakázku.
d) Pro vyloučení pochybností se uvádí, že v případě, že Xxxxxxxxx je povinen dodat dokumentaci např. projektovou, analytickou, programátorskou, uživatelskou, provozní, technickou, bezpečnostní apod., tak se jedná o autorské dílo na zakázku a vztahuje se na ni licence dle tohoto článku Dohody, tj. Objednatel má kromě jiného právo takové dokumenty měnit a upravovat.
e) Udělení licence nelze ze strany Dodavatele vypovědět. Licence se poskytuje bezúplatně;
f) Je-li součástí plnění tzv. standardní software, u kterého Dodavatel nemůže udělit, nebo zajistit Objednateli licenci dle předchozích ustanovení, řídí se poskytovaná licence licenčními podmínkami dodaného softwarového produktu, ale s tím, že Objednatel má vždy nevýhradní, přenosné, časově a územně neomezené právo užít tento software v rozsahu stanoveném touto Dohodou. Objednatel je oprávněn licenci převést na třetí osobu. Pro vyloučení pochybností Smluvní strany uvádějí, že za standardní software se považuje pouze:
- softwarové produkty s GPL licencí;
- SW komponenty, které jsou patentově chráněny;
- SW komponenty, pokud jsou Dodavatelem prokazatelně dodávány jako ucelené SW dílo jiným subjektům a není do nich v rámci dodávky zasahováno nebo jsou měněny jen konfiguračně;
g) Objednatel nemá povinnost licenci využít.
13. POJIŠTĚNÍ
13.1. Dodavatel je povinen být po celou dobu plnění dle této Rámcové dohody a plnění vzniklých na jejím základě, pojištěn z odpovědnosti za újmu způsobenou třetí osobě při výkonu podnikatelské činnosti se shodným předmětem plnění, jako je předmět této Dohody, a to ve výši minimální pojistné částky 20 000 000,- Kč se spoluúčastí maximálně 10% s tím, že pojistná smlouva musí zahrnovat odpovědnost Dodavatele za újmu způsobenou Objednateli nebo třetí osobě až do výše sjednané pojistné částky.
13.2. Dodavatel je povinen prokázat platnou pojistnou smlouvu, kdykoliv na požádání
Objednatele v průběhu trvání této Dohody.
13.3. Veškeré náklady související s pojištěním odpovědnosti Dodavatele za újmu dle výše uvedeného jsou nákladem Dodavatele.
13.4. Nesplnění povinnosti Dodavatele dle tohoto článku Dohody bude považováno za podstatné porušení této Dohody.
13.5. V případě porušení povinností dle tohoto článku je Dodavatel povinen zaplatit smluvní pokutu ve výši 500 000,- Kč.
14. OBECNÁ USTANOVENÍ
14.1. Dodavatel je povinen postupovat s odbornou péčí, podle nejlepších znalostí a schopností, sledovat a chránit oprávněné zájmy Objednatele a postupovat v souladu s jeho pokyny nebo s pokyny jím pověřených osob. Dodavatel je povinen upozorňovat Objednatele v odůvodněných případech na případnou nevhodnost pokynů Objednatele.
14.2. Smluvní strany se výslovně dohodly, že Dodavatel odpovídá Objednateli za újmu majetkovou i za újmu nemajetkovou.
14.3. Dodavatel se zavazuje upozornit Objednatele na všechny okolnosti, které by mohly vést při plnění smlouvy k omezení činností nebo ohrožení chodu Objednatele, zejména pak ve vztahu k jím používaným produktům, zařízení, programovému vybavení a prostředí.
14.4. Dodavatel je povinen upozornit Objednatele na potenciální rizika vzniku škod a včas a řádně dle svých možností provést taková opatření, která riziko vzniku škod zcela vyloučí nebo (pokud je nelze zcela vyloučit) v maximální možné míře sníží. Jde-li o zamezení vzniku škod nezapříčiněných Dodavatelem, má Dodavatel právo na úhradu nezbytných a účelně vynaložených nákladů odsouhlasených předem Objednatelem.
14.5. Dodavatel je povinen upozorňovat Objednatele včas na všechny hrozící vady či výpadky svého plnění, jakož i poskytovat Objednateli veškeré informace, které jsou pro plnění Dohody nezbytné a neprodleně oznámit písemnou formou Objednateli překážky, které mu brání v plnění předmětu Dohody a výkonu dalších činností souvisejících s plněním předmětu Dohody.
14.6. Objednatel i Dodavatel se dále zavazují sdělit či poskytnout bez zbytečného odkladu druhé Straně veškeré nezbytné přístupy k věcným i technickým informacím, kterých je nezbytně zapotřebí k provedení řádného plnění ze strany Dodavatele.
14.7. Dodavatel je povinen po celou dobu plnění dle této Dohody mít v platnosti veškerá oprávnění, licence a certifikáty ke všem činnostem dle této Dohody.
14.8. Dodavatel při plnění této Dohody nebude mít přístup k reálným datům. Veškeré ladící a testovací práce musí být provedeny na testovacích datech, která Objednatel poskytne Dodavateli nebo si je Dodavatel zajistí a odsouhlasí jejich validitu pro účely testování s Objednatelem.
14.9. Dodavatel není oprávněn připojovat jakákoli vlastní zařízení nebo zprostředkovávat jakýkoli logický přístup do ICT infrastruktury Objednatele, pracující s reálnými daty. V případě stavu, kdy Objednatel a Dodavatel společně odstraňují závadu v předmětu díla nebo v datech, je možný přístup k reálným datům jen pod dohledem odpovědného pracovníka Objednatele a jen za účelem odstranění závady.
14.10. Dodavatel se zavazuje, že při poskytování plnění dle této Dohody bude dodržovat bezpečnostní politiky Objednatele. Aktuálně platná verze bezpečnostních politik Objednatele bude Dodavateli předána při uzavření Dohody. Dodavatel bere na vědomí, že je vázán i dalšími, aktualizovanými verzemi těchto bezpečnostních politik, za podmínky, že aktualizace vychází z příslušných, závazných, právních předpisů upravujících zejména kyberbezpečnost.
15. ZÁVĚREČNÁ USTANOVENÍ
15.1. Tato Xxxxxx nabývá účinnosti dnem uveřejnění v registru smluv dle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv).
15.2. Tato Xxxxxx nesmí být postoupena bez předchozího písemného souhlasu druhé Smluvní strany, nebo být součástí projektu přeměny dle Zákona č. 125/2008 Sb., o přeměnách obchodních společností a družstev, bez předchozího písemného souhlasu druhé Smluvní strany.
15.3. Smluvní strany nemají zájem, aby nad rámec výslovných ustanovení této Dohody byla jakákoliv práva a povinnosti dovozovány z dosavadní či budoucí praxe zavedené mezi stranami či zvyklostí zachovávaných obecně či v odvětví týkajícím se předmětu plnění dle těchto smluv, ledaže je stanoveno jinak. Vedle shora uvedeného si Smluvní strany potvrzují, že si nejsou vědomy žádných dosud mezi nimi zavedených obchodních zvyklostí či praxe.
15.4. Smluvní strany vylučují aplikaci ustanovení § 557 občanského zákoníku na tuto Dohodu.
15.5. Práva Objednatele vyplývající z této Dohody či jejího porušení se promlčují ve lhůtě 10 let ode dne, kdy právo mohlo být uplatněno poprvé.
15.6. Dodavatel přebírá podle § 1765 občanského zákoníku nebezpečí změny okolností, zejména v souvislosti s cenou za poskytnuté plnění, požadavky na poskytované plnění a licenčními podmínkami výrobce.
15.7. Ukáže-li se některé z ustanovení této Dohody zdánlivým (nicotným), posoudí se vliv této vady na ostatní ustanovení Dohody obdobně podle ust. § 576 občanského zákoníku.
15.8. Všechny spory vyplývající z právního vztahu založeného touto Dohodou a v souvislosti s ním, budou řešeny podle obecně závazných právních předpisů České republiky a soudy České republiky.
15.9. Tato Dohoda může být měněna pouze formou číslovaných písemných dodatků.
15.10. Zadávací podmínky zadané Veřejné zakázky a smluvní podmínky sjednané touto Dohodou jsou bezvýhradně závazné pro Prováděcí smlouvy. Při zadávaní zakázek formou
Prováděcích smluv na základě této Dohody, Smluvní strany nesmí provádět podstatné změny v podmínkách stanovených v této Dohodě.
15.11. Tato Dohoda je podepsána oběma Smluvními stranami elektronickým podpisem.
15.12. Nedílnou součástí této Dohody jsou následující Přílohy: Příloha č. 1 – „Specifikace předmětu plnění“
Příloha č. 2 – „Specifikace ceny za předmět plnění“ Příloha č. 3 – „Vzor prováděcí smlouvy“
V Praze dne …………. V Praze dne
Objednatel: Dodavatel:
…………………..
Ministerstvo vnitra – Česká republika Zástupce: plk. Xxx. Xxxxxxxxx Xxxxx Xxxxxx: ředitel ŘPVS
Příloha č. 1 – Specifikace předmětu plnění
Specifikace předmětu plnění – Realizace a podpora SDDC pro účely kritické
infrastruktury – část 1
Obsah
1. OBECNÉ POŽADAVKY A VYMEZENÍ PŘEDMĚTU PLNĚNÍ 3
1.1. Cíl sledovaný uzavřením Rámcové dohody 3
1.2. Obecný koncept infrastruktury SDDC Zadavatele 3
1.2.2. Fyzická reprezentace konceptu 7
1.2.4. Popis koncepce datacentrové síťové infrastruktury 8
1.2.5. Typy a účel datových center 9
2.2. Plnění A – Realizační, rozvojové, provozní a konzultační služby (variabilní část) 10
2.2.1. Obecné požadavky pro Plnění A 11
2.2.2. Plnění A.1 – Implementační, konfigurační a konzultační služby – rámcová specifikace činnosti 12
2.2.3. Plnění A.2 – Služby realizace a rozvoje infrastruktury SDDC – rámcová specifikace činnosti 14
2.2.4. Požadavky na role a kvalifikace pracovníků zajišťujících služby dle Plnění A 14
2.3. Plnění B – Služby provozní podpory (fixní část): 22
2.3.1. Plnění B.1 – Služby provozní podpory – Primární datové centrum 23
2.3.2. Plnění B.2 – Služby provozní podpory – Vzdálené datové centrum 23
2.3.3. Plnění B.3 – Služby provozní podpory – EDGE datové centrum 23
2.3.4. Specifikace Služby provozní podpory 23
2.4.1. Základní dokument projektů 28
2.4.2. Certifikační požadavky na Dodavatele 29
2.4.3. Zásady projektového řízení 29
2.5.1. Definice termínů pro účely SLA 37
2.6.1. Akceptace Plnění A – Implementační a konzultační služby 40
2.6.2. Akceptace Plnění B – Služby podpory 40
2.6.4. Akceptace Dokumentace 41
Seznam zkratek a pojmů
SDDC | Softwarově definované datové centrum |
SDN | Softwarově definovaná síť |
ZKB | Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů |
KII | Kritická informační infrastruktura dle ZKB |
VIS | Významný informační systém dle ZKB |
OOB | Out of Band (ve smyslu vyhrazené rozhraní pro správu zařízení) |
MD | Man-day, člověkoden, odpovídá 8 člověkohodin |
HCI | Hyper-converged infrastrukture, hyper-konvergovaná infrastruktura |
IaaS | Infrastructure as a Service, infrastruktura jako služba |
PaaS | Platform as a Service, platforma jako služba |
XaaS | Anything as a Service, cokoli jako služba |
1. Obecné požadavky a vymezení předmětu plnění
Předmětem Rámcové dohody je poskytování služeb a provozní podpory, které jsou potřeba pro realizaci, podporu a udržitelnost datových center kritické infrastruktury Zadavatele tvořených dle konceptu SDDC Zadavatele.
Záměrem Zadavatele je realizace a modernizace datových center dle konceptu SDDC Zadavatele, principiálně vycházejícího z obecného konceptu SDDC (softwarově definované datové centrum, pro vyloučení pochybností je pro účely této Rámcové dohody uvažován SDDC koncept VMware s využitím platformy VMware Cloud Fondation) v modulární HCI (hyper-konvergované) architektuře s maximální mírou využití prvků virtualizace a automatizace s cílem poskytování služeb typu IaaS a PaaS.
Zadavatel provozuje systémy KII a VIS (podle zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů, dále jen „ZKB“) a vývoj dalších systémů, které budou podléhat tomuto režimu, aktuálně probíhá. Pro zajištění jejich koncepčního, optimálního a vysoce dostupného provozu bude Zadavatel realizovat jednotnou infrastrukturu ve více datových centrech pro provoz všech KII, VIS a dalších systémů Zadavatele.
Předmětem plnění této Rámcové dohody jsou služby umožňující realizaci komplexní vrstvy virtualizační a automatizační platformy dle konceptu SDDC pro primární, vzdálená a EDGE datová centra Zadavatele a komplexní provozní podporu těchto datových center, resp. infrastruktury SDDC. Takto realizovaná vrstva virtualizační a automatizační platformy tvořená produkty VMware (zejména VMware Cloud Foundation, licence VMware nejsou předmětem plnění této Rámcové dohody) musí společně se SPINE- LEAF datacentrovým fabrikem (datacentrový fabrik není předmětem plnění této Rámcové dohody) a HCI infrastrukturou (realizace HCI infrastruktury není předmětem plnění této Rámcové dohody) tvořit základ infrastruktury SDDC Zadavatele, zejména v úrovních služeb typu IaaS a PaaS.
1.1. Cíl sledovaný uzavřením Rámcové dohody
Vytvoření a provoz plně funkční, robustní, bezpečné, dostatečně výkonné a vysoce dostupné, pružně škálovatelné efektivně monitorované a spravované infrastruktury SDDC (vybudovaná nad datacentrovým fabrikem a HCI infrastrukturou) poskytující služby zejména typu IaaS a PaaS umožňující efektivní, optimální, vysoce dostupný a plně řiditelný provoz systémů KII a VIS systémů realizovaných v rámci eu-INIS a dalších systémů Zadavatele.
1.2. Obecný koncept infrastruktury SDDC Zadavatele
Kapitola si klade za cíl seznámit jen velmi obecně s konceptem infrastruktury softwarově definovaného datového centra (dále jen „SDDC“) Zadavatele z pohledu rozsahu plnění této Rámcové dohody, tak aby si Účastník mohl utvořit představu, co je cílem realizace v rámci jednotlivých plnění této Rámcové
dohody. Detailní zadání a specifikaci koncepce poskytne Zadavatel Dodavateli až po podpisu smlouvy o mlčenlivosti.
Zadavatel v současné době provozuje několik různě velkých datových center realizovaných dle tradiční architektury, tj. v případě HW infrastruktury tří vrstvá datacentrová síť, převážně blade serverové řešení a tradiční blokové storage realizované samostatnými diskovými poli v rámci SAN sítě. Nad HW infrastrukturou primárně využívána virtualizační platforma VMware. Architektura současných datových center, resp. i způsob, jak byly v čase realizovány, kdy téměř vždy jednotlivé aplikační celky tvořili tzv. „ostrůvek“ v rámci infrastruktury, neumožňuje:
• pružně škálovat infrastrukturu vždy dle aktuálních potřeb jak výkonově, tak i funkčně;
• efektivně a optimálně využít možností SW licencí a současných modelů licencování SW různých výrobců, protože je převážná většina HW zastaralá a již ne plně odpovídající výkonově a kapacitně současným potřebám;
• efektivně využívat odbornost pracovníků, kdy je nutné, aby správci systémů a infrastruktury znali proprietární detaily pro každý daný „ostrůvek“ – což je nad určitý počet ostrovů neudržitelné;
• řízeně rozvíjet kapacity datového centra s ohledem na pořízené technologie.
S ohledem na stav datových center (viz výše) a potřebě zajištění optimálního provozu systémů KII a vzhledem k aktuálním potřebám realizace a následného zajištění provozu nových systémů KII, zejména systémů v rámci eu-INIS, vypracoval Zadavatel na základě podkladů projektu optimalizace a s využitím služeb VMware Technical Account Managera (dále jen „VMware TAM“) koncepci a návrh podoby nových moderních datových center splňujících požadavky Zadavatele. Zejména se jedná o požadavky na vysokou dostupnost, flexibilní škálování výkonu, kapacity i funkcí, efektivní využití HW i SW vybavení a s tím související možnost maximální možné míry synergie, efektivní provoz s ohledem na provozní náklady a užitnou hodnotu, transparentní architekturu a v neposlední řadě nižší nároky na počet a zatížení pracovníků Zadavatele s využitím sjednocené infrastruktury, prvků automatizace a posunutí infrastruktury do roviny poskytování služeb.
Na základě výše popsaného vznikl koncept SDDC infrastruktury Zadavatele realizovaný na principech datacentrového SPINE-LEAF fabriku, hyper-konvergované infrastruktury (dále jen „HCI“) a konceptu VMware SDDC využívající virtualizační platformu VMware Cloud Foundation včetně např. využití SDS technologie vSAN v rámci HCI řešení. Hlavním premisou koncepce je standardizace a využívání komoditních komponent namísto proprietárních řešení.
Celé řešení je stavěné jako standardizované, unifikované a modulární. Je postaveno na těchto základních pilířích:
1. Síťový datacentrový fabrik na architektuře SPINE-LEAF, který je napojen na síťovou infrastrukturu Zadavatele zajišťující přístup uživatelů k řešení a na páteřní síť mezi jednotlivými lokalitami. Fabrik je tvořen v rámci primárního datového centra a v případě vzdálených a edge datových center v režimu tzv. vzdálený LEAF. Všechny tyto vzdálené LEAF jsou připojeny a řízeny centrálním kontrolerem fabriku v primární lokalitě;
2. Unifikované blokové řešení požadovaných výpočetních, úložných a síťových kapacit pomocí tzv. PODů (viz 1.2.2), které jsou integrovaným blokem fyzického hardware poskytujícího
„Compute-Storage-Network“ na principech HCI. Tyto PODy budou používány ve všech lokalitách v konfiguraci podle místně potřebných kapacit a určení;
3. Virtualizační platforma na bázi produktů VMware (zejména platforma VMware Cloud Foundation) s vytvořenou nadstavbou pro automatizaci jak administračních, tak uživatelských funkcionalit a služeb (např. vytvoření nového serveru nebo deployment uživatelských služeb, resp. služeb typu IaaS a PaaS), jednotným monitoringem a jednotnou správou celého řešení. V rámci virtualizační platformy jsou tvořeny clustery s různou požadovanou funkcionalitou zařazené do různých workloadových domén;
4. Specifikace poskytovaných služeb prostřednictvím definovaného katalogu služeb;
5. Personální zajištění a zajištění udržitelnosti provozu.
Primární datové centrum
Site A
Site B
L2 network
DC management cluster
vSphere Cluster (vSphere Metro Storage Cluster)
L3 Datacentrový fabrik (L2 over L3 network)
Produkční cluster
LOKÁLNÍ
vSphere Cluster
...
Produkční cluster
LOKÁLNÍ
vSphere Cluster
...
Produkční stretched cluster
vSphere Cluster (vSphere Metro Storage Cluster)
Produkční stretched cluster
vSphere Cluster (vSphere Metro Storage Cluster)
TESTovací stretched cluster
vSphere Cluster (vSphere Metro Storage Cluster)
Produkční cluster LOKÁLNÍ
vSphere Cluster
Produkční cluster LOKÁLNÍ
vSphere Cluster
S ohledem na výše zmíněné základní pilíře SDDC infrastruktury Zadavatele, nejsou předmětem plnění této Rámcové dohody žádné HW a SW technologie, ale pouze služby související s realizací, provozem a udržitelností SDDC infrastruktury. Jedná se tedy o pilíře 3 (jedná se o služby realizace, dodávka licencí VMware není předmětem plnění této Rámcové dohody), 4 a 5.
...
Obrázek 1 - Konceptuální architektura primárního datového centra
Na obrázku 1 je vyobrazena konceptuální datacentrová architektura infrastruktury. Je na ní patrné prostorové rozložení celého řešení, kdy primární datové centrum je rozprostřeno přes dvě geograficky oddělené lokality (site A a site B) v rámci Prahy. Vzdálenost lokalit je do 10 km pro možnost zajištění vysoké dostupnosti v případě výpadku jedné lokality.
L3 Datacentrový fabrik (L2 over L3 network) | ||
Produkční cluster LOKÁLNÍ vSphere Cluster | ... | Produkční cluster LOKÁLNÍ vSphere Cluster |
L2 network | |
Produkční cluster LOKÁLNÍ vSphere Cluster | |
Vzdálené (sekundární) datové centrum
DR management cluster
vSphere Cluster
L2 network
EDGE datové centrum
Obrázek 2 - Konceptuální architektura vzdáleného a EDGE datového centra
Zadavatel bude rovněž provozovat vzdálená a tzv. EDGE datová centra v lokalitách, ve kterých potřebuje disponovat serverovou kapacitou. Zpravidla je předpokládáno 5 lokalit vzdálených datových center a max do 8 EDGE datových center. Vzdálená a EDGE datová centra se zpravidla liší jen velikostí a účelem.
Pro potřeby Disaster Recovery (dále jen „DR“) a Witness primárního datového centra bude rozšířeno minimálně jedno ze vzdálených datových center o potřebná prostředí (clustery a kapacitu) a vybavení.
Z obrázku 1 je dále patrné, že koncept řešení se skládá z jednotlivých clusterů (logicky členěné virtuální prostředí pro tvorbu a provoz virtuálních serverů nad konkrétně definovaným HW s konkrétně definovaným účelem a pravidly). Jednotlivé typy clusterů jsou popsány v následující kapitole.
1.2.1. Typy clusterů
• DC management cluster
Pro provoz technologií určených pro správu datových center, řízení a správu fabriku a síťové infrastruktury, řízení bezpečnosti, monitoring a provoz SDDC management platformy, řízení zálohování, DR, apod., bude použit vysoce dostupný cluster rozložený mezi oběma lokalitami (tzv. stretched cluster). Tento dedikovaný management cluster bude připojený k nezávislé síti napříč datacentry, která není funkčně závislá na datacentrovém fabriku, na který budou napojeny produkční clustery. Důvodem je dostupnost management a monitoring nástrojů pro provoz data centra i v případě problémů s jednou z lokalit nebo s datacentrovým fabrikem.
Prostředí pro správu (dále jen „management prostředí“) a řízení datových center a SDDC infrastruktury je koncipováno jako komplexní fyzicky (na úrovni HW a konfigurace síťové infrastruktury) a logicky oddělené prostředí od produkčního prostředí datových center (na úrovni virtualizace, SDDC management platformy apod.). Management prostředí bude sloužit pro správu a řízení celé SDDC infrastruktury PČR napříč datovými centry, ať už primárním, vzdálenými nebo EDGE datovými centry. Fyzicky z pohledu PODu bude prostředí tvořeno management clusterem (nody HCI infrastruktury, virtualizační platforma VCF), zařízeními a komponentami síťové a bezpečnostní infrastruktury včetně např. technologií pro řízení a správu datacentrového fabriku, řízení rozkládání zátěže (Load Balancery), přepínání datových center apod.
• Produkční cluster – lokální
Lokální clustery produkčního prostředí budou využity pro aplikace nevyžadující od infrastruktury vysokou dostupnost napříč lokalitami primárního datového centra. Např. aplikace, kterým dostačuje vysoká dostupnost na úrovni aplikační vrstvy např. s využitím rozkládání zátěže a komunikace mezi více aplikačních nodů anebo aplikace, jimž z pohledu SLA stačí prostá standardní záloha a obnova. Clustery budou připojeny k datacentrovému fabriku.
• Produkční cluster – stretched
Geograficky rozprostřené clustery produkčního prostředí, které jsou určeny pro aplikace vyžadující zajištění vysoké dostupnosti napříč lokalitami na úrovni infrastruktury. Clustery budou připojeny k datacentrovému fabriku.
• Testovací cluster – stretched
Dedikovaný cluster, resp. prostředí určené pro realizaci, testování a akceptaci nových aplikací nebo jejich verzí (vyvíjených jak interně PČR tak i dodavatelsky) a technologií před jejich produkčním nasazením, dále pro testování nových softwarových verzí infrastrukturních komponent, validaci hardwarových profilů a driverů. Prostředí bude tvořeno samostatným clusterem v obou lokalitách primárního datového centra, který funkčně odpovídá produkčnímu clusteru, resp. prostředí, a který bude možné konfiguračně provozovat jak v lokálním, tak stretchovaném režimu. Cluster bude připojen k datacentrovému fabriku.
1.2.2. Fyzická reprezentace konceptu
Z pohledu fyzické reprezentace je standardní POD tvořen jedním rackem obsahujícím dvojici síťových přepínačů (ToR/LEAF) pro připojení PODu k datacentrovému fabriku a jedním přepínačem pro připojení k management síti (OOB přepínač) a 4 – 18 nody (při použití standardizovaných 2U nodů / HW serverů). V některých případech může být POD rozložen do více racků, např. z důvodu rozložení zátěže napájení a chlazení. Ale vždy se jedná o dvojici přepínačů (ToR/LEAF) a jedním přepínačem pro out of band management síť, které jsou sdílené pro serverové nody rozmístěné do více racků.
POD je primárně koncipován jako:
• Univerzální vyměnitelný datacentrový blok / komponenta;
• Integrovaný blok HCI infrastruktury (compute-storage-network);
• Zpravidla 1 workload doména, zpravidla 1 cluster;
• Izolovaná fault zóna.
42 U
1 U LEAF přepínač
1 U LEAF přepínač
1 U OOB přepínač
4 – 18 HCI nodů / HW serverů
2 U
2 U
2 U
2 U
Obrázek 3 - Fyzické schéma PODu
1.2.3. Typy HCI nodů
Z pohledu standardizace konfigurace HCI nodů, resp. HW serverů je obecně počítáno se dvěma základními typy:
• NODE-DB - 2U server se dvěma procesory s nižším počtem jader s vysokým taktováním určeným např. pro databázové aplikace;
• NODE-UNI - 2U servery se dvěma procesory s vysokým počtem jader pro obecné použití.
Tyto dva základní typy mohou být doplněny o identické konfigurace nodů osazené vždy jen jedním CPU, poloviční kapacitou RAM a případně poloviční kapacitou uložiště. Obecným principem je maximálně využít technologii jednoho výrobce z důvodů snadnosti údržby, patchování, update firmware, monitoringu atd.
1.2.4. Popis koncepce datacentrové síťové infrastruktury
Základem datacentrové infrastruktury je fabrik vybudovaný dle konceptu SPINE – LEAF. Datacentrový fabrik bude plnit zejména roli vysoce propustné a robustní síťové vrstvy a v kombinaci s nástroji SDN (zejména NSX) obsaženými v rámci virtualizační platformy VCF bude tvořit vysoce dostupnou, robustní, softwarově definovanou, automatizovatelnou síťovou infrastrukturu jako základ SDDC infrastruktury Zadavatele s důrazem na řízení úrovně bezpečnosti.
DC A DC B
SPINE
WDM (darkfiber)
SPINE
25GE
LEAF / ToR
Border LEAF
MultiPod
Border LEAF
LEAF / ToR
Obrázek 4 - Logické schéma datacentrového fabriku
Jednotlivé nody HCI budou k datacentrovému fabriku připojeny prostřednictvím čtyř 25G síťových rozhraní, tak by bylo možné rozdělit provoz zejména management, SDS, DRS/vMotion a datové komunikace.
1.2.5. Typy a účel datových center
• Primární datové centrum
Primární datové centrum je tvořeno dvěma lokalitami datových center Zadavatele tvořících jedno logické datové centrum, jak z pohledu síťového fabriku, tak z pohledu stretched clusterů, workload domén apod. Primární datové centrum je tvořeno 6 PODy s předpokladem budoucího rozšíření na 60 PODů. Primární datové centrum bude poskytovat největší penzum výpočetních a kapacitních zdrojů SDDC infrastruktury Zadavatele a současně služby umožňující zajištění provozu aplikací a informačních systémů a dalších ICT služeb v nejvyšších úrovních SLA. Primární datové centrum, resp. obě jeho lokality se nacházejí v Praze. Primární datové centrum obsahuje hlavní a řídící část datacentrového fabriku a správy SDDC infrastruktury.
• Vzdálené (sekundární) datové centrum
Vzdálené datové centrum je tvořeno vždy jednou lokalitou s 1 PODem s předpokladem budoucího rozšíření na cca 14 PODů. Základ vzdálených datových center bude 1 POD a připojením k fabriku na úrovni „vzdálený“ LEAF. Jedno nebo více ze vzdálených datových center může být rozšířeno o komponenty, resp. výpočetní a kapacitní zdroje pro DR a Witness prostředí primárního datového centra. Zadavatel předpokládá realizaci až 5ti vzdálených datových center v lokalitách některých krajských měst (mimo Prahu) a v rámci Letiště Xxxxxxx Xxxxx Praha.
• EDGE datové centrum
EDGE datové centrum je tvořeno vždy jednou lokalitou s 1 PODem s předpokladem budoucího rozšíření na cca 3 PODy s cílem provozu specifických systémů a aplikací Zadavatele. EDGE datové centrum bude připojeno k fabriku na úrovni „vzdálený“ LEAF. Zadavatel předpokládá realizaci až 8mi
EDGE datových center v lokalitách Zadavatele v rámci České republiky a v rámci mezinárodních letišť
s veřejným provozem mimo Letiště Xxxxxxx Xxxxx Praha.
Jakékoli z datových center může být realizováno jak v rámci budov Zadavatele, tak i v podobě kontejnerových řešení datových center.
2. Rámcová dohoda
2.1. Požadovaná plnění
Vzhledem ke komplexnosti požadavku Zadavatele na realizaci celého konceptu SDDC, jsou předmětem plnění této Rámcové dohody všechny služby potřebné pro realizaci takovéhoto konceptu. Ze zmíněných důvodů se Rámcová dohoda člení na dílčí plnění dle jednotlivých typů služeb.
Rámcová dohoda se dělí na jednotlivá plnění dle následující tabulky:
Část | Předmět |
Plnění A (A.1 až A.2) | Realizační, rozvojové, provozní a konzultační služby (variabilní část) |
Plnění B (B.1 až B.3) | Služby provozní podpory (fixní část) |
2.2. Plnění A – Realizační, rozvojové, provozní a konzultační služby (variabilní část)
Předmětem dodávky Plnění A Rámcové dohody jsou volitelně objednatelné práce (formou MD).
Nabídnutá cena musí obsahovat všechny náklady Dodavatele včetně cestovného do jednotlivých míst plnění služby.
Zadavatel požaduje plnění realizačních, rozvojových, implementačních, konfiguračních, provozních a konzultačních služeb v rozsahu uvedeném dále. Konkrétní služby, jejich rozsah a podmínky konkrétního čerpání v jednotlivých případech bude upřesněn v jednotlivých prováděcích smlouvách. Služby provozního charakteru mohou být poptány i na delší časové období, resp. ve větším množství MD čerpaných kontinuálně.
V případě volitelných Plnění A platí, že minimální jednotka k objednání je 1/2 člověkohodiny, tj. 1/16
člověkodne.
Dodavatel je povinen poskytnout požadované MD, resp. zahájit požadované činnosti ve lhůtě nejdéle do 5 pracovních dní od účinnosti prováděcí smlouvy, resp. od přijetí dílčí objednávky z prováděcí smlouvy, pokud nebude v prováděcí smlouvě nebo dílčí objednávce dohodnuta lhůta delší. Zadavatel není oprávněn požadovat poskytnutí paralelní práce více pracovníků jednotlivých rolí, než je uvedeno
v požadovaném počtu pracovníků u jednotlivých rolí v kapitole 2.2.4. a v rozsahu větším než je standardní pracovní doba, tj. 40 hod. týdně na osobu – nebude-li dohodnuto v konkrétním plnění jinak.
Poskytované služby se člení na služby v oblasti realizace a rozvoje infrastruktury SDDC, služby provozu a služby konzultační, implementační, konfigurační, školící, projektové a servisní pro realizaci, rozvoj a udržitelnost virtualizační platformy dle konceptu SDDC pro primární, vzdálené a EDGE datová centra Zadavatele a jejich automatizace. A s tím související realizace služeb typu IaaS a PaaS v rámci infrastruktury SDDC Zadavatele.
2.2.1. Obecné požadavky pro Plnění A
V případě, že je v rámci Plnění A.1 Zadavatelem objednáno ucelené plnění ve větším rozsahu (počtu MD, zpravidla více než 10 MD) v podobě rozsáhlejší implementační, případně konfigurační činnosti, musí být součástí Plnění A.1 implementační projekt. Požadavek na implementační projekt bude vždy Zadavatelem specifikován v dílčích objednávkách pro čerpání z prováděcí smlouvy na Plnění A.1. V případě Plnění A.2 je implementační projekt součástí plnění vždy.
Implementační projekt musí obsahovat minimálně tyto činnosti:
• Analýza stávajícího stavu, návrh řešení včetně definice přesných kroků vedoucích k úspěšné implementaci řešení, včetně konfigurace a integrace HW a SW technologií a zařízení do infrastruktury Zadavatele, je-li úprava jejich konfigurace a jejich integrace součástí plnění. Po akceptaci návrhu řešení jeho řízená realizace;
• Návrh testovacích scénářů pro otestování plné funkcionality dodaného plnění v infrastruktuře Zadavatele. Po odsouhlasení testů ze strany Zadavatele bude provedení těchto testů podmínkou akceptace a protokol o provedení a výsledcích testů bude přílohou akceptačního protokolu;
• Proškolení administrátorů, seznámení se správou a konfigurací implementovaných nebo konfigurovaných SW technologií a technologií virtualizační platformy nebo změnou jejich konfigurace minimálně v rozsahu:
o seznámení s virtualizační platformou případně změnou její konfigurace a způsobu obsluhy a konfigurace;
o vysvětlení všech použitých nastavení v rámci konfigurace a integrace
do infrastruktury Zadavatele;
o způsob spuštění nouzových režimů obnovy;
o možné režimy uživatelského a administrativního přístupu a seznámení se základními funkcemi;
o předpokládá se účast maximálně 12 pracovníků Zadavatele.
Implementační projekt je ukončen provedením akceptačních testů (viz Akceptační testy, kapitola 2.6.3.).
Rozsah a detailní zadání implementačního projektu bude upřesněno v dílčích prováděcích smlouvách a následně před samotnou implementací.
Součástí výstupů implementačního projektu je dokumentace, která musí zahrnovat alespoň:
• V případě realizace implementace virtualizační platformy nebo konfiguračních změn musí dokumentace obsahovat popis této implementace a popis technologií platformy, případně popis změn. Dokumentace musí být zpracována v míře detailu, při které i odborná osoba, u které bylo provedeno úvodní seznámení se správou a konfigurací virtualizační platformy, může v krátké době rozumět důvodům pro danou konfiguraci a její funkčnosti v daném prostředí;
• Technický popis, popis konfigurace, upgrade SW technologie virtualizační platformy, popis uvedení do nouzového režimu, popis zálohy a obnovy konfigurace, schéma zapojení, a to v rozsahu potřebném pro konfiguraci a správu prostředí třetí osobou;
• Nouzový plán obnovy – Detailní plán obnovy v úrovni dostatečné pro osobu seznámenou se správou a konfigurací implementovaných a konfigurovaných SW technologií virtualizační platformy;
• Dokumentace bude vytvořena na základě standardizované šablony Zadavatele, pokud takovou Zadavatel Dodavateli poskytne a upřesní před samotnou implementací;
• Dokumentaci skutečného provedení;
• Informace o znalostní bázi technologií virtualizační platformy (může být vedena výrobcem/Dodavatelem externě);
• Dokumentaci obsahující detailní popis všech implementovaných funkcí;
• Vypracování nebo aktualizaci stávající dokumentace APD (administrátorská provozní
dokumentace) Zadavatele.
Všechna jednání a způsob zajištění a realizace implementačního projektu, která se uskuteční v rámci plnění z této Rámcové dohody mezi Zadavatelem a Dodavatelem (příp. i dalšími stranami) se řídí pravidly projektového řízení pro účely plnění z této Rámcové dohody definovanými v kapitole 2.4. - Projektové řízení.
2.2.2. Plnění A.1 – Implementační, konfigurační a konzultační služby – rámcová specifikace činnosti
V případě požadavků na služby dle Plnění A.1 se jedná o činnosti převážně z oblasti implementační, konzultační, konfigurační, provozní, architektonické, školící a projektové, a to zejména:
• Analýza a návrh realizace a následný rozvoj SDDC infrastruktury;
• Konzultace k architektonickým návrhům v oblasti SDDC infrastruktury, datových center a
cloudu obecně;
• Konzultace, implementační a konfigurační činnosti k zajištění realizace a integrace SDDC infrastruktury (IaaS a PaaS) dle konceptu VMware SDDC tvořeného na principech HCI infrastruktury a virtualizační platformy VMware Cloud Foundation;
• Konzultace k novým funkcím oproti stávajícím s návrhem způsobu jejich využití a
implementace;
• Zajištění integrace do systémů dohledu a řízení Zadavatele;
• Součinnost Zadavateli a Dodavateli HCI infrastruktury při instalaci a konfiguraci HCI
infrastruktury;
• Součinnost při instalaci a konfiguraci virtualizační platformy dle VMware SDDC konceptu a konceptu SDDC infrastruktury Zadavatele;
• Provozní činnosti pro zajištění optimálního a udržitelného provozu SDDC infrastruktury Zadavatele včetně všech souvisejících technologií jako zejména HCI infrastruktury, virtualizační platformy apod.;
• Aktivní účast na architektonických jednáních s účastí dodavatelů dalších částí, komponent a služeb datových center za účelem společných návrhů k realizaci úprav a integraci zařízení a služeb do datových center Zadavatele;
• Plánování a koordinace instalace software s dalšími dodavateli součástí SDDC infrastruktury (jak v rámci virtualizační platformy, tak i HCI infrastruktury) ve formě zpracovaného plánu uvolňování nové verze software včetně informací o nových funkčnostech, doporučení pro implementaci, případné změny v kompatibilitě a jiné závislosti;
• Konzultace v oblasti privátních cloudů, cloudových služeb, SDDC a HCI řešení, datových center apod. pro rozšíření znalostí Zadavatele v těchto oblastech. Zaměřené na předem dohodnutá témata, od asistence při konfiguracích a instalacích nových zařízení po plánování dostupnosti infrastruktury po živelných událostech;
• Optimalizace nastavení SDDC infrastruktury ve formě analytické služby, jejímž předmětem je kontrola nastavení prvků HCI infrastruktury ve vztahu k virtualizační technologii, kontrola nastavení jednotlivých technologií virtualizační platformy a porovnání současného stavu nastavení s doporučenou politikou „best practices“ a návrh změn konfigurací směřující k efektivnějšímu a stabilnějšímu provozu zmíněných zařízení a technologií. Po dohodě s pracovníky Zadavatele aplikace těchto doporučených změn;
• Konzultace ke správě a aktualizaci životního cyklu katalogu služeb SDDC infrastruktury
(zejména katalog IaaS a PaaS služeb);
• Analýza, návrh, tvorba a správa životního cyklu služeb SDDC infrastruktury typu IaaS a PaaS,
případně dle potřeby Zadavatele i obecně jakékoli služby typu XaaS;
• Příprava, tvorba, testování a následná řízená instalace (po schválení Zadavatelem) update a upgrade SW všech částí SDDC infrastruktury;
• Tvorba a aktualizace dokumentace dle požadavků Zadavatele;
• Tvorba analýzy rizik a bezpečnostní dokumentace podle ZKB (vztahuje se jak k infrastruktuře,
tak i k aplikacím);
• Aktualizace provozní dokumentace v elektronické podobě, která bude dostupná pro jednotlivé určené osoby Zadavatele;
• Zajišťování infrastruktury a dokumentace v souladu se zákonem č. 181/2014 Sb., jeho prováděcími vyhláškami a resortními interními akty;
• Návrh na sjednocení a optimalizaci servisních programů u jednotlivých provozních celků infrastruktury Zadavatele, jejich správu a řízení, případně jejich postupné převedení na Dodavatele podle toho, jak budou ukončeny současné smlouvy s jejich původními Dodavateli;
• Tvorba veškeré potřebné dokumentace a plánu předání služeb novému Dodavateli na konci
platnosti této Rámcové dohody;
• Zajištění školení pro pracovníky Zadavatele zejména z oblastí datových center, cloudových a virtualizačních technologií a souvisejících HW technologií (detailní požadavky na školení budou vždy upřesněny v prováděcí smlouvě, resp. dílčí objednávce z prováděcí smlouvy);
• Účast na interních workshopech / školeních pro pracovníky Zadavatele, za účelem seznámení pracovníků Zadavatele s novinkami, trendy, technologiemi apod. z oblasti datových center, cloudových a virtualizačních technologií a souvisejícím HW technologií. Předpokládaný počet
takovýchto workshopů je 1x za 6 měsíců. Workshopy budou realizovány v prostorách Zadavatele v rámci celé ČR. Je-li to odsouhlaseno oběma stranami, je přípustné zajistit zázemí pro průběh workshopů / školení v prostorách Dodavatele.
Výčet činností není konečný, ale rámcový. Předmětem dodávky Plnění A.1 jsou projektové, implementační, konzultační, konfigurační, provozní, architektonické a školící činnosti z celkové problematiky serverových HW, virtualizačních a cloudových technologií a platforem (zejména produkty VMware, ale např. i MS, KVM, Citrix), datových center, bezpečnosti apod. Plnění A.1 nesouvisí jen s technologiemi dle jednotlivých plnění této Rámcové dohody, ale i s dalšími obdobnými zařízeními a souvisejícím SW.
Plnění A.1 bude čerpáno jednotlivými prováděcími smlouvami s definováním maximálního počtu a
druhu objednávaných rolí dle Přílohy č.2 Rámcové dohody.
Služby jsou poskytovány provedením objednaných prací. Služba A.1 je poskytována na základě konkrétních objednávek Zadavatele a dle jeho aktuálních potřeb. Služba A.1 je účtována na základě schváleného výkazu poskytnutých prací, nejmenší účtovací jednotkou je započatá ½ člověkohodina.
2.2.3. Plnění A.2 – Služby realizace a rozvoje infrastruktury SDDC – rámcová specifikace činnosti
V případě požadavků na služby dle Plnění A.2 se jedná o činnosti převážně z oblasti realizace a rozvoje infrastruktury SDDC, a to zejména:
• Realizace katalogu služeb typu XaaS;
• Tvorba metodiky správy životního cyklu katalogu služeb typu XaaS;
• Tvorba metodiky návrhu, realizace a správy životního cyklu automatizovaných procesů;
• Tvorba metodiky udržitelnosti a správy životního cyklu infrastruktury SDDC;
• Tvorba metodiky DR a souvisejících runbooků.
Výčet činností není konečný, ale rámcový. Předmětem dodávky Plnění A.2 jsou realizační a rozvojové činnosti z celkové problematiky infrastruktury SDDC realizované na platformě VCF.
Plnění A.2 bude čerpáno jednotlivými prováděcími smlouvami s definováním maximálního počtu a
druhu objednávaných rolí dle Přílohy č.2 Rámcové dohody.
2.2.4. Požadavky na role a kvalifikace pracovníků zajišťujících služby dle Plnění A
Zadavatel bude v rámci čerpání služeb z Plnění A, zejména pro dlouhodobé, opakující se činnosti související s realizací, provozem a udržitelností infrastruktury SDDC, uvádět v prováděcí smlouvě mimo jiné soupis požadovaných rolí pracovníků Dodavatele.
Záměrem Zadavatele je pro realizaci, provoz a udržitelnost infrastruktury SDDC vytvořit tým specialistů tvořený interními pracovníky Zadavatele v kombinaci s pracovníky Dodavatele objednanými v rámci Plnění A této Rámcové dohody.
Zadavatel požaduje pro zajištění činností souvisejících s realizací, provozem a udržitelností infrastruktury SDDC v rámci Plnění A této Rámcové dohody následující role dle dílčích logicky členěných oblastí:
Oblast architektury, projektového řízení a podpory projektu:
• Projektový manažer
• Architekt řešení / Infrastrukturní architekt
• Analytik
Oblast inženýringu:
• Kapacitní manažer
• HCI inženýr
• Storage inženýr (SDS)
• Desktop a mobility inženýr
• Inženýr síťové virtualizace (SDN)
• Inženýr správy cloudu a automatizace
Oblast provozu:
• HCI Operátor
• Storage Operátor
• Desktop a mobility operátor
• Operátor síťové virtualizace (SDN)
• Vývojář cloudové automatizace
Požadavky na kvalifikaci jednotlivých rolí jsou uvedeny v Příloze č. 5 Zadávací dokumentace– Požadavky na technickou kvalifikaci – dílčí část 1.
Detailní požadavky na specifikaci jednotlivých rolí jsou uvedeny v následující tabulce. V tabulce je uveden i požadovaný počet pracovníků pro jednotlivé role. Počet odpovídá počtu Zadavatelem předpokládaného maximálního současného využití jednotlivých rolí. Účastník musí brát v potaz možné dovolené a jiné pracovní neschopnosti jimi nabízených pracovníků v různých rolích, a tak počítat s vykrytím jejich případných nedostupností jinými pracovníky Účastníka se stejnou nebo vyšší kvalifikací požadovanou Zadavatelem. Pro vyloučení pochybností Zadavatel požaduje pro každou roli samostatného pracovníka, resp. jeden Účastníkem nabídnutý pracovník může pokrýt současně jen jednu roli.
Role | Požadavek Zadavatele |
Projektový manažer | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití 1/2 úvazku) |
Primární zodpovědnost | • Koordinace a zajištění sběru požadavků a omezení od konzumentů cloudových služeb • Mapování infrastrukturních požadavků na katalog IaaS služeb • Analýza možností k vypořádání se se specifickými požadavky a omezeními a zásadní projektová rozhodnutí (ve spolupráci s Architektem řešení) • Koordinace a dohled nad jednotlivými IT zaměstnanci, konzultanty, výrobci a Dodavateli • Komunikace s konzumenty cloudových služeb • Předávání informací z / do engineeringu |
Kompetence / kvalifikace | • Minimálně teoretická znalost architektonických, provozních a projektových metodik v enterprise prostředí (TOGAF, ITIL, PRINCE2) • Minimálně základní technický přehled v IT infrastruktuře |
Primární předpokládané výstupy | • Projektové plány • Projektová komunikace s konzumenty cloudových služeb • Revize dokumentů připravených architektem |
Architekt řešení / Infrastrukturní architekt | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití 1/3 úvazku) |
Primární zodpovědnost | • Návrh technologií a jejich využití pro naplnění byznys cílů a strategie na základě specifických požadavků a omezení • Analýza možností k vypořádání se s požadavky a omezeními a architektonická rozhodnutí • Plánování roadmapy rozvoje prostředí IT infrastruktury včetně finančních aspektů • Spolupráce s vlastníky jednotlivých systémů, definování obchodních, finančních a provozních požadavků a cílů systémových řešení • Spolupráce na IT Strategii v oblasti HW infrastruktury včetně cloud řešení • Spolupráce na zavádění a dohledu dodržování architektonických principů • Poskytování odborných posouzení řešení s ohledem na SW a HW standardy • Návrh technických řešení v souladu s byznys požadavky • Tvorba dokumentace, modelování, kreslení a prezentace • Předávání informací z / do engineeringu |
Kompetence / kvalifikace | • Minimálně teoretická znalost provozních a projektových metodik v enterprise prostředí (ITIL, PRINCE2) • Praktická znalost architektonické metodiky v enterprise prostředí (TOGAF) • Minimálně obecný technický přehled v IT infrastruktuře • Zkušenost s business komunikací s konzumenty cloudových služeb • Zkušenost s technickou komunikací s technickými konzumenty cloudových služeb |
Primární předpokládané výstupy | • Koncepční architektura infrastruktury • Podkladů pro investiční záměry • Podklady pro dokumenty pro RFI/RFP • Business komunikace s konzumenty cloudových služeb • Technická komunikace s technickými konzumenty cloudových služeb |
Kapacitní manažer / plánovač | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití 1/3 úvazku) |
Primární zodpovědnost | • Kapacitní plánování compute / storage / network kapacity • Návrh optimalizace infrastrukturních zdrojů • Sledování konzumace fyzické infrastruktury jako je el.energie, obsazenost racků, kapacita datacentrového síťového fabriku • Sledování objednávání, implementace a alokace virtualizovaných infrast. zdrojů v návaznosti na definované SLO/SLA • Příprava a exekuce testovacích plánů monitorovacích systémů • Realizace technických PoC (Proof Of Concept) • Knowledge transfer pro provozního týmu • Předávání informací z / do architekturního týmu • Předávání informací z / do provozního týmu • Předávání informací v rámci engineering týmu • Tvorba dashboardů, pohledů a šablon pro monitoring a report v rámci monitoring nástrojů dle návrhu z architektury nebo engineeringu • Konfigurace monitorovacích nástrojů a agentů pro monitoring dle návrhu z architektury a engineeringu • Tvorba dokumentace monitoringu |
Kompetence / kvalifikace | • Praktická znalost datacentrové infrastruktury • Minimálně obecný technický přehled v kompletní datacentrové infrastruktuře (compute / storage / networking) • Expertní znalost monitorovacích, provozních a kapacitních nástrojů z platformy VMware vRealize jako je VMware vRealize Operations Manager, VMware vRealize Log Insight, VMware vRealize Network Insight a Zabbix • Praktická znalost provozu a monitoringu kritické enterprise infrastruktury • Technická komunikace s engineeringem a architekturou |
Primární předpokládané výstupy | • Logická architektura monitoring infrastruktury (ve spolupráci s architektem) • Fyzická architektura monitoring infrastruktury • Custom reporting a dashboard pro vizualizaci kapacitního stavu • Forecasting capacity • Testovací plány • Technické plány a výstupy z PoC • Report funkčnosti infrastruktury / cloudu • Report řešených incidentů • Report provedených činností • Report funkčností cloudu v souladu s nastavenými SLA • Dashboardy a report sestavy |
HCI inženýr (HCI Engineer) | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití 1/3 úvazku) |
Primární zodpovědnost | • Návrh řešení a tvorba dokumentace infrastrukturních technologií (compute, storage, network) na základě specifických technických požadavků a omezení příprava a exekuce testovacích plánů • Realizace technických PoC (Proof Of Concept) • Knowledge transfer pro provozní tým • Předávání informací z / do architekturního týmu • Předávání informací z / do provozního týmu • Předávání informací v rámci engineering týmu |
Kompetence / kvalifikace | • Praktická znalost návrhové metodiky technické infrastruktury v enterprise prostředí • Zkušenost s technickou komunikací s technickými experty konzumentů cloudových služeb |
• Technický přehled v kompletní datacentrové infrastruktuře (compute / storage / networking / backup) • Expertní technický přehled v oblastech x86 servers, VMware vSphere, VMware vSAN | |
Primární předpokládané výstupy | • Logická architektura POD infrastruktury (ve spolupráci s architektem) • Fyzická architektura POD infrastruktury • Testovací plány • Technické plány a výstupy z PoC |
Storage inženýr (Storage Engineer) | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití 1/3 úvazku) |
Primární zodpovědnost | • Spolupráce na BIA (Business Impact Analysis) • Návrh řešení a tvorba dokumentace infrastrukturních technologií (storage, data protection, disaster recovery, archivace, apod.) na základě specifických technických požadavků a omezení • Příprava a exekuce testovacích plánů • Realizace technických PoC (Proof Of Concept) • Knowledge transfer pro provozní tým • Předávání informací z / do architekturního týmu • Předávání informací z / do provozního týmu • Předávání informací v rámci engineering týmu |
Kompetence / kvalifikace | • Praktická znalost návrhové metodiky technické infrastruktury v enterprise prostředí • Zkušenost s technickou komunikací s technickými experty konzumentů cloudových služeb • Technický přehled v kompletní datacentrové infrastruktuře (compute / storage / networking / backup) • Expertní technický přehled v oblastech storage, zálohování, archivace, disaster recovery a informační management |
Primární předpokládané výstupy | • Logická architektura storage a data protection infrastruktury (ve spolupráci s architektem) • Fyzická architektura storage a data protection infrastruktury • Testovací plány • Technické plány a výstupy z PoC |
Desktop a mobility inženýr (Desktop and Mobility Engineer) | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití 1/3 úvazku) |
Primární zodpovědnost | • Návrh řešení a tvorba dokumentace infrastrukturních technologií (compute, storage, network) na základě specifických technických požadavků a omezení • Příprava a exekuce testovacích plánů • Realizace technických PoC (Proof Of Concept) • Knowledge transfer pro provozní oddělění • Předávání informací z / do architekturního týmu • Předávání informací z / do provozního týmu • Předávání informací v rámci engineering týmu |
Kompetence / kvalifikace | • Praktická znalost návrhové metodiky technické infrastruktury v enterprise prostředí • Zkušenost s technickou komunikací s technickými experty konzumentů cloudových služeb • Technický přehled v kompletní datacentrové infrastruktuře (compute / storage / networking / backup) • Expertní technický přehled v oblasti VMware vSphere a desktopové virtualizaci VMware Horizon |
Primární předpokládané výstupy | • Logická architektura desktopové virtuální infrastruktury (ve spolupráci s architektem) • Fyzická architektura desktopové virtuální infrastruktury • Testovací plány • Technické plány a výstupy z PoC |
Inženýr síťové virtualizace (Network Virtualization Engineer) | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití 1/3 úvazku) |
Primární zodpovědnost | • Návrh řešení a tvorba dokumentace infrastrukturních technologií (compute, storage, network) na základě specifických technických požadavků a omezení • Příprava a exekuce testovacích plánů • Realizace technických PoC (Proof Of Concept) • Knowledge transfer pro provozní tým • Předávání informací z / do architekturního týmu • Předávání informací z / do provozního týmu • Předávání informací v rámci engineering týmu |
Kompetence / kvalifikace | • Praktická znalost návrhové metodiky technické infrastruktury v enterprise prostředí • Zkušenost s technickou komunikací s technickými experty konzumentů cloudových služeb • Technický přehled v kompletní datacentrové infrastruktuře (compute / storage / networking / backup) • Expertní technický přehled v oblasti VMware vSphere a NSX • Expertní technický přehled v oblasti datacentrových SPINE-LEAF Fabriků typu CISCO ACI, Dell EMC SmartFabric, Cumulus, BigSwitch, apod. |
Primární předpokládané výstupy | • Logická architektura síťové infrastruktury (ve spolupráci s architektem) • Fyzická architektura síťové infrastruktury • Testovací plány • Technické plány a výstupy z PoC |
Inženýr správy cloudu a automatizace (Cloud Management and Automation Engineer) | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití 1/3 úvazku) |
Primární zodpovědnost | • Návrh řešení a tvorba dokumentace technologií pro cloud management a automatizaci na základě specifických technických požadavků a omezení • Příprava a exekuce testovacích plánů • Realizace technických PoC (Proof Of Concept) • Knowledge transfer pro provozní tým • Předávání informací z / do architekturního týmu • Předávání informací z / do provozního týmu • Předávání informací v rámci engineering týmu |
Kompetence / kvalifikace | • Praktická znalost návrhové metodiky technické infrastruktury v enterprise prostředí • Zkušenost s technickou komunikací s technickými experty konzumentů cloudových služeb • Technický přehled v kompletní datacentrové infrastruktuře (compute / storage / networking / backup) • Expertní technický přehled v oblasti cloud managementu a automatizace • Expertní technický přehled v produktech VMware vRealize Automation, VMware vRealize Orchestrator, VMware vRealize Operations Manager |
Primární předpokládané výstupy | • Logická architektura technologií pro cloud management a automatizaci (ve spolupráci s architektem) • Fyzická architektura technologií pro cloud management a automatizaci • Testovací plány |
• Technické plány a výstupy z PoC | |
HCI operátor (HCI Operator) | |
Požadovaný počet pracovníků pro roli | 2 (předpokládané využití ½ - 2 úvazky) |
Primární zodpovědnost | • Implementace nové infrastruktury dle návrhu z engineeringu • Aktualizace a upgrade infrastruktury dle návrhu z engineeringu • Provoz PODů (compute / storage / network) • Provoz VMware HCI (vSAN) • Kontrola automatizovaných kontrol korektního stavu VMware HCI systému (health-checks) • Řešení varovných alarmů o stavu systému • Řešení chybových alarmů o stavu systému • Předávání informací z / do engineering týmu |
Kompetence / kvalifikace | • Praktická znalost provozu kritické enterprise infrastruktury • Technická komunikace s engineeringem • Expertní technický přehled v oblastech x86 servers, VMware vSphere, VMware vSAN |
Primární předpokládané výstupy | • Report funkčnosti svěřené infrastruktury (vROps dashboard) • Report řešených incidentů (vROps dashboard) • Report provedených činností • Report funkčnosti virtuální infrastruktury v souladu s nastavenými SLA |
Storage operátor (Storage Operator) | |
Požadovaný počet pracovníků pro roli | 2 (předpokládané využití ½ - 2 úvazky) |
Primární zodpovědnost | • Implementace nové infrastruktury dle návrhu z engineeringu • Aktualizace a upgrade infrastruktury dle návrhu z engineeringu • Provoz PODů (storage systémů) • Provoz zálohovacích a archivačních systémů • Provoz Disaster Recovery systémů • Řešení varovných alarmů o stavu systému • Řešení chybových alarmů o stavu systému • Kontrola automatizovaných kontrol korektního stavu storage a zálohovacích systémů v PODech • Předávání informací z / do engineering týmu |
Kompetence / kvalifikace | • Praktická znalost provozu kritické enterprise infrastruktury • Technická komunikace s engineeringem • Expertní technický přehled v oblastech storage, zálohování a archivace dat, disaster recovery. |
Primární předpokládané výstupy | • Report funkčnosti svěřené infrastruktury • Report řešených incidentů • Report provedených činností • Report funkčnosti zálohovacích jobů v souladu s nastavenými SLA • Report funkčnosti DR systémů v souladu s nastavenými SLA |
Desktop a mobility operátor (Desktop and Mobility Operator) | |
Požadovaný počet pracovníků pro roli | 1 (předpokládané využití ½ - 1 úvazek) |
Primární zodpovědnost | • Implementace nové infrastruktury dle návrhu z engineeringu • Aktualizace a upgrade infrastruktury dle návrhu z engineeringu • Provoz dektopové virtualizace |
• Správa diskových obrazů virtuálních desktopů • Balíčkování aplikací • Řešení varovných alarmů o stavu systému • Řešení chybových alarmů o stavu systému • Kontrola automatizovaných kontrol korektního stavu infrastruktury VMware Horizon a WorkspaceOne • Předávání informací z / do engineering týmu | |
Kompetence / kvalifikace | • Praktická znalost provozu kritické enterprise infrastruktury • Technická komunikace s engineeringem • Expertní technický přehled v oblastech desktopové virtualizace VMware Horizon a balíčkování aplikací. |
Primární předpokládané výstupy | • Report funkčnosti svěřené infrastruktury • Report řešených incidentů • Report provedených činností • Report funkčnosti virtuálních desktopů v souladu s nastavenými SLA |
Operátor síťové virtualizace (Network Virtualization Operator) | |
Požadovaný počet pracovníků pro roli | 2 (předpokládané využití ½ - 2 úvazky) |
Primární zodpovědnost | • Implementace nové infrastruktury dle návrhu z engineeringu • Aktualizace a upgrade infrastruktury dle návrhu z engineeringu • Provoz síťové virtualizace • Provoz bezpečnostní virtualizace • Správa NSX DFW • Správa NSX Load Balancer • Správa NSX DLR a Logických Switchů • Řešení varovných alarmů o stavu systému • Řešení chybových alarmů o stavu systému • Kontrola automatizovaných kontrol korektního stavu síťové virtualizace • Předávání informací z / do engineering týmu |
Kompetence / kvalifikace | • Praktická znalost provozu kritické enterprise infrastruktury • Technická komunikace s engineeringem • Expertní technický přehled v oblastech síťové virtualizace a bezpečnosti |
Primární předpokládané výstupy | • Report funkčnosti svěřené infrastruktury • Report řešených incidentů • Report provedených činností • Report funkčnosti síťové virtualizace v souladu s nastavenými SLA |
Vývojář cloudové automatizace (Cloud Management and Automation Developer) | |
Požadovaný počet pracovníků pro roli | 2 (předpokládané využití ½ – 2 úvazky) |
Primární zodpovědnost | • Implementace nové infrastruktury dle návrhu z engineeringu • Vývoj a provoz (DevOps) automatizace cloud procesů (Workflows) • Provoz self-service portálu a automatizační platformy (vRealize Automation) • Provoz orchestrátoru workflows (vRealize Orchestrator) • Řešení varovných alarmů o stavu automatizačního systému • Řešení chybových alarmů o stavu automatizačního systému • Kontrola automatizovaných kontrol korektního stavu automatizačního systému (vRA, vRO) • Předávání informací z / do engineering týmu |
Kompetence / kvalifikace | • Praktická znalost provozu kritické enterprise infrastruktury • Technická komunikace s engineeringem • Expertní technický přehled v oblastech automatizace, orchestrace a skriptování. • Technická kompetence v programovacích jazycích JavaScript a PowerShell (VMware PowerCLI) |
• Technická kompetence v konfiguračním managementu (Ansible, Puppet, Chef, apod.) | |
Primární předpokládané výstupy | • Report funkčnosti automatizačního systému • Report řešených incidentů • Report provedených činností • Report úspěšných a neúspěšných automatizačních úloh |
Analytik | |
Požadovaný počet pracovníků pro roli | 2 (předpokládané využití ½ - 2 úvazky) |
Primární zodpovědnost | • Analýza a sběr požadavků a omezení od konzumentů cloudových služeb • Analýza možností k vypořádání se se specifickými požadavky a omezeními • Koordinace a dohled nad tvorbou dokumentací • Komunikace s konzumenty cloudových služeb • Projektová podpora |
Kompetence / kvalifikace | • Minimálně teoretická znalost, projektových, analytických, provozních a bezpečnostních metodik v enterprise prostředí (ITIL, PRINCE2, apod.) • Minimálně základní technický přehled v IT infrastruktuře |
Primární předpokládané výstupy | • Analýzy a dokumentace dle požadavku Zadavatele • Bezpečnostní analýzy (tvorba nebo aktualizace stávajících) • Zápisy z jednání |
Účastník v nabídce uvede jmenný seznam jím nabízených pracovníků s uvedením, pro jakou roli
pracovníka nabízí a s uvedením a doložením splnění veškerých požadovaných kvalifikací a certifikací.
V případě požadavků na certifikace VMware Zadavatel požaduje certifikace na aktuální verze produktů, resp. aktuální verze certifikací (aktuální poslední verze ke dni uveřejnění veřejné zakázky). V případě že Účastníkem nabízený pracovník pro danou roli disponuje starší verzí certifikace (max. o dvě verze starší), požaduje Zadavatel, aby Dodavatel zajistil u tohoto pracovníka aktualizaci certifikace nejdéle do jednoho roku od účinnosti této Rámcové dohody. V opačném případě je Xxxxxxxxx povinen nahradit nabídnutého pracovníka pracovníkem, který splňuje nebo převyšuje požadavky na danou roli a současně disponuje aktuálními certifikacemi. To samé platí i v případě, že po dobu platnosti této Rámcové dohody bude dostupná ze strany VMware nová verze certifikace. V tomto případě musí Dodavatel zajistit u všech pracovníků, kde je daná certifikace požadována, její aktualizaci nejdéle do jednoho roku od zveřejnění této certifikace ze strany VMware.
2.3. Plnění B – Služby provozní podpory (fixní část):
Předmětem dodávky Plnění B, resp. B.1 až B.3 je poskytnutí služeb potřebných pro zajištění efektivního bezproblémového provozu infrastruktury SDDC Zadavatele realizovaného virtualizační platformou implementovanou a konfigurovanou v rámci Plnění A této Rámcové dohody a dalšími zařízeními a s tím souvisejícími službami, např. datacentrový fabrik, HCI infrastruktura, datová uložiště, infrastruktura pro zálohování a DR, které nejsou předmětem plnění této Rámcové dohody a u nichž bude zajištěna smluvní provozní podpora (SLA) od dodavatelů těchto zařízení zpravidla v režimu 24x7x4 nebo 5x8xNBD dle charakteru jednotlivých zařízení.
Plnění B (resp. Plnění B.1 až B.3) – Služby provozní podpory (fixní část) je objednáváno zpravidla vždy na celý rok (tj. 12 kalendářních měsíců) nebo jeho celé násobky a hradí se paušální platbou. Účastník stanoví cenu za jeden rok, cena za jiné období bude vypočítána příslušným poměrem dnů. Dodavatel
je povinen začít plnit požadovanou službu ve lhůtě od účinnosti prováděcí smlouvy, pokud nebude
v prováděcí smlouvě stanovena lhůta delší.
Provozní podpora infrastruktury SDDC Zadavatele musí být poskytnuta v souladu s požadovanými SLA definovanými v kapitole 2.5. - SLA.
2.3.1. Plnění B.1 – Služby provozní podpory – Primární datové centrum
Předmětem dodávky Plnění B.1 je poskytnutí služeb definovaných v kapitole 2.3.4. Specifikace Služby provozní podpory pro primární datové centrum dle kapitoly 1.2.5., tvořené dvěma lokalitami v rámci Prahy.
2.3.2. Plnění B.2 – Služby provozní podpory – Vzdálené datové centrum
Předmětem dodávky Plnění B.2 je poskytnutí služeb definovaných v kapitole 2.3.4. Specifikace Služby provozní podpory pro 1 lokalitu „vzdáleného“ datového centra dle kapitoly 1.2.5., zpravidla v rámci krajských měst.
2.3.3. Plnění B.3 – Služby provozní podpory – EDGE datové centrum
Předmětem dodávky Plnění B.3 je poskytnutí služeb definovaných v kapitole 2.3.4. Specifikace Služby provozní podpory pro 1 lokalitu EDGE datového centra dle kapitoly 1.2.5., v rámci Prahy, krajských měst nebo mezinárodních letišť.
2.3.4. Specifikace Služby provozní podpory
Provozní podporou jsou pro Plnění B této Rámcové dohody myšleny korektivní, preventivní a adaptivní služby představující pravidelné činnosti, jejichž cílem je co největší prevence výskytu případného nestandardního stavu, respektive incidentu, který by vyústil v nefunkčnost nebo omezení funkčnosti infrastruktury datových center a s tím souvisejícího infrastruktury SDDC, resp. v nefunkčnost, nedostupnost anebo omezení dostupnosti systémů na ní provozovaných, zejména systémů KII a VIS. V případě výpadku pak uvedení infrastruktury do provozního stavu v souladu s parametry kapitoly 2.5.
- SLA definovanými níže.
Nedílnou součástí podpory je zajištění Helpdesku.
2.3.4.1. Korektivní služby podpory:
Korektivní služba podpory zahrnuje zejména:
• Reaktivní podporu zaměřenou na detekci příčin zjištěných či nahlášených anomálií, nestandardních a chybových stavů (dále problém) ve fungování infrastruktury během jejího provozu a implementaci odpovídajících oprav nebo dočasných řešení v souladu s SLA, s jasným cílem zprovoznit infrastrukturu, odstranit příčinu problému a navrhnout, otestovat a nasadit trvalé řešení;
• Vedení záznamů o výskytu anomálií během provozu infrastruktury;
• Seznámení pracovníků Zadavatele s problémem, jeho příčinou a způsobem řešení;
• Podporu Zadavatele v případě potřeby eskalace anomálie, nestandardního nebo chybového stavu, tj. poskytnutí potřebných podkladů, případně na základě žádosti Zadavatele přímou komunikaci s třetí stranou.
2.3.4.2. Preventivní služba podpory:
Preventivní služba podpory zahrnuje zejména:
• Proaktivní podporu zaměřenou na detekci a předcházení anomáliím, nestandardním a chybovým stavům (dále problémům) ve fungování infrastruktury během jejího provozu a implementaci odpovídajících oprav nebo dočasných řešení s jasným cílem přesně definovat příčinu problému a navrhnout, otestovat a nasadit trvalé řešení;
• Detekci a odstraňování latentních chyb dříve než se mohou projevit selháním funkčnosti infrastruktury nebo její části. Provádět úpravy konfigurací nebo nasazovat aktualizace, které sníží šanci budoucích problémů infrastruktury nebo jejich jednotlivých částí;
• Prověřování možností optimalizace konfigurace infrastruktury prostřednictvím analýzy technických, procesních i organizačních aspektů systému a návrhu úprav technických, procesních nebo organizačních směřujících k vyšší spolehlivosti a efektivitě provozu infrastruktury, její správy a provozu systémů nad ní.
2.3.4.3. Adaptivní služby podpory:
Adaptivní služby podpory zahrnují zejména:
• Aktualizaci konfigurace infrastruktury (a jednotlivých částí) s cílem zachování úrovně HW a SW podpory pro jednotlivá zařízení a technologie infrastruktury SDDC;
• Přizpůsobování konfigurace infrastruktury a jednotlivých částí s cílem udržet infrastrukturu na úrovni garantované dostupnosti, odezvy a dalších kvalitativních ukazatelů;
• Sledování dlouhodobých trendů využívaní infrastruktury a jednotlivých zařízení, zátěže a struktury zátěže infrastruktury a jednotlivých zařízení, analýzu trendů a včasnou reakci na ně formou úprav parametrů, dílčích změn architektury, nebo doporučení posílení infrastruktury o další zařízení, resp. jeho konfiguraci, resp. jeho propojení nebo zapojení;
• V případě použití certifikátů, jejich správa a včasná reakce na potřebu jejich změny včetně vedení jejich přehledu.
Z pohledu správy provozu a udržitelnosti infrastruktury jako celku služba souhrnně představuje
zejména následující základní aktivity:
• Podpora a provádění pravidelné kontroly hlavních parametrů infrastruktury (využití a vytížení kapacitních, přenosových a systémových zdrojů, dlouhodobé trendy, stav zařízení);
• Detekce a analýza případných nestandardních stavů a dlouhodobých trendů, které se doposud neprojevily vůči dalším částem datových center nebo systémům v rámci nich provozovaných;
• Podpora Zadavatele při plánování a provádění testování vysoké dostupnosti (například test přepnutí provozu do jiné lokality) a DR v intervalu 1x ročně;
• Na základě provozních stavů vytváření návrhů změn v infrastruktuře a jejím nastavení, aplikacích a aplikačních parametrech, nasazení aplikací do prostředí infrastruktury, procesů dohledu a správy;
• Pravidelný měsíční reporting s přehledem významných událostí v rámci provozu
infrastruktury;
• Pravidelný měsíční reporting dostupnosti (SLA) infrastruktury v uplynulém období;
• Vedení potřebné administrace v obvyklém rozsahu řízení a vedení projektu viz část Projektové řízení;
• Vedení provozního deníku o událostech při správě systému;
• Aktualizace technické a provozní dokumentace v případě jejich úprav souvisejících s Plněním B;
• Správa úložiště konfigurací jednotlivých zařízení v infrastruktuře Zadavatele včetně jejich proaktivní tvorby a tvorby návrhů provozních opatření;
• V intervalu jednou za 14 dnů realizaci pravidelných jednání za účelem zhodnocení stavu provozu infrastruktury, nahlášených a vyřešených incidentů, konzultace k provozu infrastruktury (činnost je součástí pouze Plnění B.1, ale vztahuje se ke všem dodávaným Plnění B.1 až B.3)
2.3.4.4. Služby Helpdesku
Služba Helpdesku je součástí pouze Plnění B.1, ale vztahuje se ke všem dodávaným Plnění B.1 až B.3. Služba Helpdesku je dostupná nepřetržitě 24x7 alespoň jedním z definovaných kanálů.
Služby reaktivní podpory představují stálou připravenost pracovníků Dodavatele pro řešení nestandardních stavů (viz též korektivní podpora), které nebylo možné odhalit v rámci proaktivních služeb. Dodavatel v návaznosti na proaktivní služby bude aktualizovat znalostní bázi tak, aby bylo možno na nahlášenou vadu operativně reagovat a odstranit ji v co nejkratším časovém úseku.
Dodavatel zajistí pro potřeby Zadavatele pro poskytování všech služeb z Rámcové dohody a prováděcích smluv či dalších požadavků po dobu trvání smluvního vztahu po celou dobu účinnosti Rámcové dohody i po celou dobu záruky plnění zakoupených z Rámcové dohody Helpdesk podle níže definovaných parametrů.
Helpdesk má primárně podobu webové aplikace zřízené a provozované Dodavatelem a slouží jako jednotné kontaktní místo. Dodavatel zřídí určeným pracovníkům Zadavatele vzdálený přístup k Helpdesku. Kromě vzdáleného přístupu zajistí Dodavatel minimálně další 2 způsoby komunikace s Helpdeskem. Dodavatel zpracuje dokument k používání a vnitřnímu členění Helpdesku. Služba Helpdesk bude sloužit jak pro zaznamenávání případných vad a problémů, tak dotazů zodpovědných osob jmenovaných Zadavatelem.
Základní funkce/parametry této služby jsou:
• Příjem a řízení životního cyklu všech incidentů, vad, problémů a požadavků;
• Prvotní analýza incidentů, nahlášených vad, problémů a požadavků, přidělení k řešení a stanovení návrhu řešení (analytická podpora řešení problémů zadaných do Helpdesku);
• Řešení incidentů, problémů a požadavků a vad dle smluvních závazků (podpora, záruční oprava, pozáruční oprava, nutnost úpravy systému atd.);
• Monitoring a reportování stavů incidentů, vad, problémů a požadavků a plnění parametrů SLA;
• Dokumentace incidentů, vad, problémů, příčin vzniku a jejich řešení;
• Reakce na dotazy oprávněných uživatelů Zadavatele;
• Komunikace v českém jazyce;
• Dostupnost služby Helpdesk v režimu 24x7x365;
• Reakční doba pro započetí řešení nahlášeného požadavku dle požadovaného SLA, viz část SLA
tohoto dokumentu;
• Přístup prostřednictvím webové služby, e-mailu, telefonu nebo dalšími navrženými způsoby;
• Definice chyb a požadavky na jejich odstranění – viz část SLA tohoto dokumentu.
Servisní záznam (Ticket) – nahlášení události typu incident, problém nebo požadavek sjednaným způsobem. Události jsou nahlašovány prostřednictvím Helpdesku. Servisní záznam může být registrován pouze prostřednictvím k tomu stanovených kontaktů a postupů. Servisní záznam musí být oprávněným zástupcem Zadavatele klasifikován z hlediska závažnosti. O řešení, odmítnutí, uzavření či jiných změnách stavu a závažnosti servisního záznamu bude vždy informován oprávněný zástupce, kdy jednotlivá stádia, zejména pak odmítnutí a uzavření servisního záznamu, musí být oprávněným zástupcem Zadavatele odsouhlasena.
Závažnost (Severita) – klasifikace naléhavosti incidentu, problému nebo požadavku, která je odvozena od úrovně nefunkčnosti nebo nedostupnosti systému.
Dodavatel vyhotoví a předá Zadavateli 1x měsíčně strukturovaný souhrnný report o stavu všech otevřených nebo v daném měsíci uzavřených incidentů, problémů a požadavků, z něhož budou zřejmé minimálně následující údaje:
• předmět incidentu, problému nebo požadavku;
• jejich stav;
• čas nahlášení, registrace a autorizace;
• reakční doba;
• doba řešení;
• čas a způsob uzavření a autorizace;
• doba a důvod nedostupnosti zařízení, infrastruktury nebo její části;
• doba a důvod nedostupnosti služby Helpdesk.
Dodavatel je dále Xxxxxxxxxx povinen na vyžádání poskytnout ve lhůtě do 10 dnů veškerá data shromážděná v souvislosti s poskytováním shora uvedených služeb ve strojově zpracovatelné podobě (např. *.xml, *.csv apod.).
Zadavatel a Dodavatel vytvoří komunikační matici, která bude obsahovat všechny relevantní kontaktní osoby pro komunikaci mezi stranami včetně eskalačních mechanismů (viz Základní dokument projektu kapitola Projektové řízení).
Doba vyřešení servisního případu se řídí specifikací uvedenou v popisu konkrétního objednaného plnění.
2.3.4.5. Ostatní služby poskytované jako součást fixní podpory
• Je požadováno zajištění průběžného seznamování a informování pracovníků Zadavatele se změnami, novými funkcionalitami infrastruktury a změnami v dokumentaci, které vznikly při poskytování technické podpory;
• Poskytování podpory takovým způsobem, který vyloučí přístup pracovníků Dodavatele
k datům IS Policie ČR;
• Vytvoření a udržování plánu zajištění udržitelnosti, poskytované podpory a provozu infrastruktury v požadované kvalitě;
• Obnova provozu infrastruktury SDDC a komponent datového centra po výpadcích, jež souvisí
s dodaným plněním dle této Rámcové dohody;
• Předběžná analýza a předběžné oceňování prací objednávaných z Plnění A;
• Pravidelný update a upgrade (automatizovaně pomocí nástrojů VCF, případně manuálně) SW komponent VCF;
• Za součinnosti Dodavatele HW komponent HCI infrastruktury pravidelný update a upgrade těchto komponent (automatizovaně pomocí nástrojů VCF). Za předpokladu kompatibility (uvedeno v HCL spol. VMware) HW komponent HCI infrastruktury s nástroji VCF pro update a upgrade HW (např. vSphere Lifecycle Manager, SDDC Manager nebo obdobné jež jsou součástí VCF) je za proces update a upgrade zodpovědný Dodavatel plnění dle této Rámcové dohody. V případě update nebo upgrade HW komponent HCI infrastruktury s využitím SW nástrojů, jež jsou součástí HW infrastruktury komponent HCI, nebo ručně je za proces update nebo upgrade zodpovědný Dodavatel HW komponent HCI infrastruktury. Za kompatibilitu patche pro update nebo upgrade HW komponent HCI infrastruktury s celým řešením infrastruktury SDDC, potažmo VCF, je zodpovědný Dodavatel plnění dle této Rámcové dohody (potvrzení kompatibility musí vycházet z HCL spol. VMware). Za funkčnost a bezchybnost patche pro update nebo upgrade zodpovídá Dodavatel HW komponent HCI infrastruktury (součástí infrastruktury Zadavatele bude testovací prostředí určené právě i na testování funkčnosti update nebo upgrade SW a HW komponent infrastruktury);
• Konzultace a upozorňování Zadavatele a s tím související garance doporučení pro využití těchto komponent a jejich aktuálnosti pro celou infrastrukturu (zařízení a komponenty HCI a technologie VCF tvořící celek v podobě infrastruktury SDDC), resp. všech komponent a jejich vzájemného propojení, které jsou kompatibilní a certifikovány pro vzájemné použití dle online dostupných matic kompatibility a certifikace zveřejněných (a pravidelně aktualizovaných) výrobci těchto komponent. A s tímto související garanci a zajištění vždy postupné instalace nových verzí firmware, update SW komponent včetně Biosu, firmware jednotlivých komponent (disk, NIC, apod.), komponent VCF apod. tak, aby nebyl způsoben výpadek nebo omezení funkčnosti infrastruktury SDDC. Zadavatel předpokládá a pro tento požadavek zajistí součinnost Dodavatele HCI infrastruktury případně dalších součástí SDDC;
• Testování všech balíčků pro instalace patchů a update na s produkcí identické konfiguraci v infrastruktuře Zadavatele za součinnosti Dodavatele HCI infrastruktury. Nasazení balíčku na produkční prostředí bude možné vždy až po úspěšném prokazatelném otestování a schválení ze strany Zadavatele;
• Ostatní nevyjmenované práce nutné pro garantování funkčnosti systému.
Provozní podpora definovaná v rámci Plnění B (B.1 až B.3) této Rámcové dohody se vztahuje jak k jednotlivým vrstvám, tak i k celkové funkčnosti a dostupnosti realizované infrastruktury SDDC dle požadovaného SLA, jak v primárním datovém centru Zadavatele, tak i ve vzdálených a EDGE datových centrech.
2.4. Projektové řízení
Aktivity, jež jsou součástí Rámcové dohody o realizaci a podpoře SDDC pro účely kritické infrastruktury, jsou natolik rozsáhlé, různorodé, komplexní a časově i technologicky náročné, že pro jejich úspěšnou realizaci a koordinaci je nutné tyto aktivity řídit projektově, tj. s použitím metod projektového řízení.
Pojmem „projekt“ Zadavatel rozumí jedinečnou sadu činností, procesů, nástrojů a lidí, jejichž cílem je vytvořit předem definovaný produkt (resp. výstup, předmět plnění). Projekt je ohraničen časem (má daný začátek a konec), náklady a kvalitativními požadavky. V kontextu RD Realizace a podpory SDDC pro účely kritické infrastruktury je zpravidla pro každý projekt realizace zapotřebí uzavřít samostatnou prováděcí smlouvu, s čímž je spojeno vytvoření rozsáhlé dokumentace a řada administrativních procesů, jež mají dopad na Zadavatele i Dodavatele a jež na řízení projektů kladou specifické nároky (popsané níže). Vzhledem k tomu, že jednotlivé projekty mohou probíhat paralelně a jsou mezi sebou provázané (a kromě projektů je navíc nutné řídit i služby technické podpory), je zapotřebí je navzájem koordinovat jako jeden celek, tj. „program“. Pro označení všech činností souvisejících s údržbou a rozvojem SDDC pro účely kritické infrastruktury Zadavatele je proto užíván pojem „Program SDDC pro účely kritické infrastruktury“.
2.4.1. Základní dokument projektů
Do 30 pracovních dnů od podpisu Rámcové dohody Dodavatel vytvoří draft Základního dokumentu projektů (dále též „ZDP“), který bude popisovat zásady řízení projektů (tj. veškeré projektové procesy, dokumenty, role, odpovědnosti, rizika ad.) – tyto zásady budou závazné pro celý „Program SDDC pro účely kritické infrastruktury“, a to jak pro Dodavatele, tak pro Zadavatele. Draft ZDP Zadavatel opřipomínkuje do 10 pracovních dnů od jeho doručení, Dodavatel tyto připomínky zapracuje ve lhůtě 10 dnů od jejich přijetí a zašle ZDP Zadavateli ke druhému čtení. Zadavatel ZDP opřipomínkuje ve lhůtě 10 dní. Pokud v rámci druhého čtení žádné připomínky nevzniknou, je dokument akceptován. Pokud připomínky vzniknou, budou vypořádány osobně mezi Zadavatelem a Dodavatelem na jednání k tomu svolanému. Vypořádáním připomínek je dokument akceptován.
Za účelem vyjasnění zadání při vytváření (resp. vypořádávání připomínek) ZDP mohou být svolána jednání mezi Zadavatelem a Dodavatelem, která se budou konat v prostorách Zadavatele. Vyplyne-li to z okolností jako nejúčelnější varianta, může vybrané kapitoly ZDP po vzájemné dohodě vytvořit Zadavatel.
Gestorem ZDP bude Dodavatel. Pojmem „gestor“ je míněn v projektovém smyslu (resp. ve smyslu řízení dokumentů) vlastník1 dokumentu. Zde však tento termín není použit z důvodu hrozící záměny pojmu vlastník s termíny smluvními. Tj. gestorem je označován subjekt, který je za dokument odpovědný (z věcného i formálního hlediska včetně pravopisu) v celém životním cyklu – vytváří jeho první verzi, zajišťuje jeho distribuci určeným osobám k připomínkám, vypořádává obdržené připomínky, zasílá zpět finální verzi dokumentu. Dodavatel bude ZDP pravidelně aktualizovat (dle potřeby, nejméně však 1× ročně).
ZDP musí pokrývat všechny relevantní principy, témata a procesy metodiky PRINCE2 a musí respektovat projektové zásady Zadavatele, které z metodiky PRINCE2 vycházejí a které jsou popsány níže. Tyto principy mohou být upřesněny v jednáních k tomu svolaných (viz výše). Dodavatel má povinnost sladit své procesy se zásadami uvedenými v odsouhlaseném ZDP.
2.4.2. Certifikační požadavky na Dodavatele
Projekty jsou řízeny na základě metodiky PRINCE2, která byla přizpůsobena potřebám Zadavatele. Projektový tým Dodavatele musí být s metodikou PRINCE2 dobře obeznámen. Projektový manažer Dodavatele musí být držitelem certifikace PRINCE2 (alespoň na úrovni Practitioner), příp. držitelem certifikace jiné světově uznávané metodiky obdobného stupně, např. PMP.
2.4.3. Zásady projektového řízení
2.4.3.1. Projektová dokumentace
Gestorem veškeré dokumentace, která bude vznikat v souvislosti s Programem SDDC pro účely kritické infrastruktury, je Dodavatel (pokud nebude dohodnuto jinak). Konkrétní způsob vznášení a vypořádávání připomínek (např. přes e-mail, Sharepoint apod.) bude dohodnut a popsán v ZDP – součástí ZDP budou komunikační pravidla, komunikační matice a seznam kontaktů na všechny členy projektového týmu.
Při vytváření projektové dokumentace bude Dodavatel používat vzory (šablony) Zadavatele, nebude-li stanoveno jinak. Pokud bude zapotřebí vytvořit dokument, pro nějž dosud šablona neexistuje, bude Dodavatel na jeho vzhledu (vizuální stránka, formátování, struktura atd.) spolupracovat se Zadavatelem.
Detailní aspekty řízení projektové dokumentace budou popsány v ZDP, který musí obsahovat zejména
tato pravidla:
• Název dokumentu – bude respektovat dohodnutý vzorec, např.:
system_typDokumentu_poradoveCislo_datumVzniku_nazev/predmet_verze.pripona;
1 Z hlediska majetkoprávního je vlastníkem (majitelem) vytvořené dokumentace a držitelem autorských práv ke všem dokumentům Zadavatel.
• Použité nástroje a formát dokumentu – pokud nebude dohodnuto jinak, všechny dokumenty jsou zasílány v upravitelném a revidovatelném formátu, ve formátu *.docx a nikoli PDF. Všechny dokumenty musejí být zasílány ve standardním, běžně dostupném formátu. Zadavatel má k dispozici tyto nástroje: Microsoft Word 2016, Microsoft Excel 2016, Microsoft PowerPoint 2016, Microsoft Project 2016, Visio 2016, Adobe Acrobat Reader 2015 (verze nástrojů budou průběžně povyšovány), finální verze budou ve formátu archivní pdf;
• Struktura a vzhled dokumentu – bude dáno vzorem, který dodá Zadavatel, resp. který bude u dosud neexistujících dokumentů vypracován v součinnosti s Dodavatelem. Dokumenty nebudou obsahovat loga ani jiné identifikační údaje Dodavatele;
• Gestor dokumentu – pro každý dokument musí být definován jeho gestor (v projektové terminologii vlastník) – tedy subjekt odpovědný za jeho životní cyklus;
• Schválení dokumentu – pro každý dokument musí být definováno, jak proběhne jeho schválení – zda stačí odsouhlasení e-mailem či zanesením rozhodnutí do zápisu z jednání, anebo zda musí být dokument podepsán (pokud ano, tak kým), příp. zda bude uplatněno pravidlo tichého souhlasu po uplynutí definované lhůty apod.;
• Stupeň utajení dokumentu – každý dokument musí mít vyznačený stupeň utajení nebo
důvěrnosti a musí být dodržována bezpečnostní pravidla danému stupni odpovídající;
• Velikost dokumentu – maximální velikost dokumentu zasílaného přes e-mail bude 10 MB;
• Formální úprava dokumentu (textu) – text zarovnán do bloku, data psát ve formátu DD.MM.RRRR (např. 28.02.2018), finanční částky psát s tečkou mezi tisíci a vždy uvádět, zda se jedná o částku včetně anebo bez DPH (např. 3.500.000 Kč bez DPH) atd.
Neúplný seznam projektové dokumentace je uveden v následující tabulce. Nejedná se o kompletní výčet – účelem tabulky je pouze poskytnout rámcovou představu o množství dokumentů. Skladba dokumentů a jejich další atributy (gestor apod.) budou předmětem dohody. Dokumenty, jejichž gestorem není Dodavatel, však mohou být s Dodavatelem konzultovány, příp. může být Dodavatel požádán, aby vytvořil část dokumentu nebo pro jeho vytvoření dodal podklady.
Č. | Dokument | Navrhovaný gestor |
1 | investiční záměr | Zadavatel |
2 | stanovisko architekta kybernetické bezpečnosti MV ČR k investičnímu záměru | Zadavatel |
3 | návrh na zadání veřejné zakázky | Zadavatel |
4 | stanovisko architekta kybernetické bezpečnosti MV ČR k návrhu na zadání veřejné zakázky | Zadavatel |
5 | základní dokument projektů | Dodavatel |
6 | harmonogram projektu | Xxxxxxxxx |
7 | personální zajištění projektu | Xxxxxxxxx |
8 | zpráva o stavu projektu | Xxxxxxxxx |
9 | závěrečná zpráva z projektu | Dodavatel |
10 | zápis z jednání (programový výbor, akceptační komise, eskalační komise, odborné schůzky ad.) | Dodavatel |
11 | akceptační protokol (měsíční akceptace technické podpory, akceptace celého projektu nebo jeho dílčích částí ad.) | Dodavatel |
12 | předávací protokol | předávající subjekt |
13 | výkaz činností | Dodavatel |
14 | změnový požadavek | Dodavatel |
15 | testovací scénáře | Xxxxxxxxx |
16 | protokol o provedení testů | subjekt, který testuje |
17 | evidence změn | Xxxxxxxxx |
18 | evidence projektových rizik | Dodavatel |
19 | evidence úkolů | Xxxxxxxxx |
20 | evidence získaných zkušeností (lessons learnt) | Xxxxxxxxx |
2.4.3.2. Životní cyklus projektu
Každý projekt realizovaný na základě plnění této Rámcové dohody má tyto fáze:
Příprava
Fáze přípravy zahrnuje aktivity od identifikace potřebnosti realizace nebo změny po uzavření prováděcí smlouvy, která realizaci nebo změnu smluvně ošetřuje. V případě změn jsou identifikované změny vedeny v evidenci změn. Iniciátorem potřeby na realizaci nebo změnu může být řada subjektů – koncoví uživatelé, administrátoři, pracovníci Dodavatele, třetí strany (např. eu-LISA), legislativa atd. Požadavky na realizaci nebo změnu jsou ohodnoceny dle jejich priority, která vychází z aspektů bezpečnostních, technických, legislativních, finančních atd. Po vybrání nových realizací nebo změn, které budou realizovány, následuje tento proces:
• Vytvoření investičního záměru (IZ) – slouží k alokaci potřebných finančních prostředků. Vytváří jej Zadavatel na základě podkladů od Dodavatele (zejména specifikace předmětu plnění, ceny a termínů);
• Vypořádání stanoviska architekta kybernetické bezpečnosti k IZ – má-li k investičnímu záměru připomínky architekt kybernetické bezpečnosti MV ČR, Zadavatel je vypořádá. Dodavatel může být požádán o dodatečné informace či podklady;
• Vytvoření návrhu na zadání veřejné zakázky (NZVZ) – slouží jako podklad pro vyhlášení veřejné zakázky. Vytváří jej Zadavatel na základě investičního záměru a dodatečných podkladů od Dodavatele (zejména rozpad ceny na jednotlivé role a člověkodny a technický popis řešení);
• Vypořádání stanoviska architekta kybernetické bezpečnosti k NZVZ – má-li k NZVZ připomínky architekt kybernetické bezpečnosti MV ČR, Zadavatel je vypořádá. Dodavatel může být požádán o dodatečné informace či podklady;
• Vyhlášení veřejné zakázky – v reakci na výzvu Zadavatele zašle Dodavatel nabídku, tj. vyplněný vzor prováděcí smlouvy. Nabídka je schválena/rozporována hodnotící komisí, kterou tvoří zástupci Zadavatele;
• Uzavření prováděcí smlouvy – po schválení nabídky Dodavatele je podepsána prováděcí
smlouva;
Realizace
Fáze realizace zahrnuje aktivity od zahájení prací na projektu po dodání a finální akceptaci všech výstupů/produktů projektů (celého předmětu plnění). Projekt je formálně zahájen kick-off meetingem, na kterém Xxxxxxxxx prezentuje Zadavateli Plán projektu (resp. je na tomto jednání upřesněn), jenž zahrnuje tyto dokumenty:
• Harmonogram projektu – obsahuje rozpad projektu na jednotlivé etapy (typicky se jedná o analýzu, vývoj, testování, nasazení do produkce, zvýšený monitoring), přičemž vždy alespoň aktuální etapa je rozpracována na vyšší úroveň detailu (jednotlivé činnosti), je-li to účelné. Harmonogram je dodán v tabulkové podobě i v grafickém vyjádření (Ganttův diagram). Na vyžádání Dodavatel poskytne Zadavateli zdrojový soubor Harmonogramu projektu (např. soubor ve formátu *.mpp – MS Project). Z harmonogramu musí být zřejmé, kdy jsou platební milníky a kdy bude svolána akceptační komise;
• Personální zajištění projektu – Dodavatel i Zadavatel jmenují do projektových rolí konkrétní pracovníky, kteří jsou vedeni v evidenci včetně kontaktních údajů (e-mail, mobilní telefon, příp. pevná linka);
• Rizika projektu – Dodavatel vede evidenci projektových rizik, která jsou průběžně aktualizována. Evidence obsahuje mj. název/předmět rizika, pravděpodobnost a dopad rizika, protiopatření;
• Úkoly – Dodavatel vede evidenci úkolů, které je zapotřebí splnit. Tuto evidenci pravidelně
aktualizuje;
• Získané zkušenosti (lessons learnt) – Dodavatel vede evidenci získaných lekcí/postřehů/znalostí, které vyplývají ze zkušeností (z praxe), a tyto zkušenosti průběžně uplatňuje/zohledňuje a učí se z nich;
• Akceptační kritéria – Dodavatel v součinnosti se Zadavatelem definuje akceptační kritéria, která budou předmětem testování, resp. akceptační komise. Akceptační kritéria mohou být upřesněna v analytické etapě projektu.
Dodavatel průběžně reportuje Xxxxxxxxxx stav realizace projektu (postup prací) na pravidelných jednáních programového výboru (viz dále). Nedaří-li se některé problémy vyřešit na úrovni projektových manažerů (programového výboru), je svolána eskalační komise, která tyto problémy řeší na úrovni ředitelů projektu. V případě potřeby jsou svolávána ad hoc odborná jednání.
Etapa testování vždy zahrnuje nejprve testování na straně Dodavatele a poté na straně Zadavatele. Dodavatel je povinen vytvořit pro Zadavatele testovací scénáře, které komplexně prověří funkčnost předmětu plnění a které musejí zahrnovat akceptační kritéria stanovená v počáteční fázi projektu. Zadavatel vytvoří protokol o provedení testů, který slouží jako vstup pro akceptační řízení.
Po dosažení milníků stanovených v Harmonogramu projektu dochází k akceptaci dílčích etap projektu (anebo projektu jako celku v jeho závěru). Detailní akceptační proces je popsán v kapitole této dokumentace „Akceptace“.
Akceptační proces
Viz kapitola 2.56. - Akceptace.
Ukončení
Fáze ukončení zahrnuje rekapitulaci celého projektu včetně konsolidace, kontroly a archivace veškeré projektové dokumentace. Projekt je formálně ukončen wrap-up meetingem, na kterém Xxxxxxxxx prezentuje Zadavateli závěrečnou zprávu z projektu, která obsahuje mj. shrnutí harmonogramu (příp. kdy a proč byl porušen), nákladů, nově identifikovaných rizik a protiopatření, získaných zkušeností apod.
2.4.3.3. Organizace projektu
Jednání
Pro všechna jednání, která se uskuteční v rámci Programu Realizace a podpory SDDC pro účely kritické
infrastruktury mezi Zadavatelem a Dodavatelem (příp. i dalšími stranami), platí:
• Jednání se konají v prostorách Zadavatele ve vzájemně dohodnutém čase (Zadavatel zajistí patřičné prostory a případné vybavení – dataprojektor, flipchart ad.);
• Jednání formálně svolává Dodavatel, není-li dohodnuto jinak, (po předchozí domluvě ohledně místa, času a účastníků) standardně vytvořením schůzky v kalendáři Outlook nebo s Exchange kompatibilním a jejím rozesláním určeným osobám, variantně je možné schůzku svolat mailem nebo obvoláním účastníků;
• Dodavatel pořizuje Zápis z jednání:
o draft zápisu z jednání zašle Dodavatel k připomínkám Zadavateli, a to do 2 pracovních dnů od konání daného jednání;
o zápis z jednání je vytvořen ve vzoru/šabloně Zadavatele.
Organizační struktura projektu - každý projekt má tuto strukturu:
• Realizační týmy – jedná se o pracovní tým Zadavatele a pracovní tým Dodavatele, který na základě pokynů projektových manažerů realizuje jednotlivé aktivity směřující k vytvoření předmětu plnění. Určení jednotlivých rolí a jejich obsazení konkrétními osobami (včetně kontaktních údajů) je uvedeno v Plánu projektu (viz výše) – typicky se jedná o programátory, analytiky, testery, architekty, databázové specialisty, bezpečnostní experty atd. Pracovní týmy se scházejí ad hoc dle potřeby, řeší odbornou problematiku. Na základě tematického zaměření může jít např. o jednání analytické, jednání testerů apod.;
• Programový výbor – jedná se o hlavní řídicí orgán, který je tvořen projektovými manažery Zadavatele a Dodavatele a jimi přizvanými osobami. Schází se každý týden v pevně stanoveném dni a čase (případně jinak – dle aktuální potřeby). Na programovém výboru Dodavatel podává Zadavateli report o stavu projektu, prezentuje aktualizovaný Plán projektu
– postup prací, (ne)dodržování harmonogramu, stav rizik, získaných zkušeností, úkolů a jejich plnění, problémy a jejich řešení atd. Dodavatel také vytváří a prezentuje Zadavatelem definované reporty o stavu provozu systému a vývoji sledovaných ukazatelů;
• Eskalační komise – jedná se o vrcholový orgán, který je svoláván ad hoc na podnět projektového manažera Zadavatele či Dodavatele v případě, že nastane problém, který se nedaří vyřešit na úrovni programového výboru. Je tvořena řediteli projektů Zadavatele a Dodavatele, projektovými manažery Zadavatele a Xxxxxxxxxx a případně dalšími jimi přizvanými osobami;
• Akceptační komise – jedná se o orgán, který je svoláván, když je zapotřebí akceptovat předmět plnění projektu nebo jeho dílčí etapu. Posuzuje (ne)splnění akceptačních kritérií a tím rozhoduje o (ne)akceptování předmětu plnění. Je tvořena projektovými manažery Zadavatele a Dodavatele a případně dalšími jimi přizvanými osobami. Detailní průběh akceptačního procesu bude rozpracován v ZDP, obecně je stanoven výše.
2.4.3.4. Implementace metodiky PRINCE2
Jak je uvedeno výše, při řízení projektů vychází Zadavatel z metodiky PRINCE2, jejíž zásady musejí být zahrnuty do ZDP. Pro přehlednost je způsob implementace PRINCE2 do prostředí Zadavatele shrnut v následujících podkapitolách:
Principy - principy PRINCE2 jsou implementovány následujícím způsobem:
1. Nepřetržité zdůvodňování potřebnosti projektu
• Dodavatel vede evidenci změn, jejíž součástí je ohodnocení priority změn;
• Součástí NZVZ je povinné pole „Stručný důvod potřeby“, v němž je zdůvodnění potřebnosti projektu zdokumentováno a schváleno;
2. Učit se ze zkušeností
• Dodavatel vede evidenci získaných zkušeností, její aktualizace je součástí pravidelného reportingu a závěrečné zprávy z projektu;
3. Definované role a odpovědnosti
• Role (a jejich obsazení konkrétními osobami) a odpovědnosti jsou definovány v Plánu
projektu v části Personální zajištění projektu;
• Kromě projektových rolí je zapotřebí mít stanoveny i další povinné role (z hlediska bezpečnosti, ochrany osobních údajů apod.) – zajišťuje Zadavatel;
4. Řízení po etapách
• Na kick-off meetingu Dodavatel prezentuje mj. rámcový Harmonogram projektu, přičemž detailně je vždy rozpracována, monitorována a řízena aktuální etapa;
5. Řízení podle výjimek
• Cílem není zabývat se detailním monitoringem a řízením každého detailu a jednotlivého úkonu každého pracovníka, ale pouze aktivit/problémů, které danou úroveň řízení svou komplexitou přesahují. Dílčí problémy v projektu si primárně řeší každý pracovník sám, a teprve když je nedokáže vyřešit anebo potřebuje součinnost, je problém řešen s kolegy v rámci realizačního týmu. Pokud realizační tým problém nevyřeší, je postoupen programovému výboru. Pokud není vyřešen ani tam, je postoupen eskalační komisi;
6. Zaměření na produkt
• Úspěšné projekty jsou zaměřeny na výstup, nikoli na dílčí aktivity. Cílem projektu je dodat výstup, který všem dotčeným subjektům (tzv. „stakeholderům“) přinese přidanou hodnotu. Proto je vždy zapotřebí při plánování projektu postupovat tímto způsobem: identifikace potřebnosti změny -> definice výstupu z pohledu všech stakeholderů -> dekompozice výstupu na dílčí subvýstupy -> identifikace etap, které vedou k vytvoření (sub)výstupů -> identifikace jednotlivých aktivit (úkolů), které vedou ke splnění etap;
7. Přizpůsobení metodiky PRINCE2 danému prostředí
• Je realizováno tímto dokumentem, detailněji pak v ZDP.
Témata - témata PRINCE2 jsou implementována následujícím způsobem:
1. Business case
• Roli business casu plní IZ a NZVZ;
2. Organizace
• Řídicí struktura projektu je třístupňová – realizační tým, programový výbor, eskalační
komise. Akceptaci předmětu plnění zajišťuje akceptační komise;
3. Kvalita
• Řízení projektů vychází z celosvětově uznávaných standardů (viz tento dokument);
• Jsou stanovena akceptační kritéria, která musejí být splněna, aby byl výstup akceptován jako odpovídající požadované kvalitě;
• Součástí každého projektu je etapa testování, a to jak na straně Dodavatele, tak na straně Zadavatele. Dodavatel vytváří testovací scénáře, podle nichž Zadavatel ověřuje správnou funkčnost. Testovací scénáře jsou sladěny s akceptačními kritérii. Výsledek testování je uveden v protokolu o provedení testů;
• Stav projektu je průběžně monitorován a reportován;
4. Plány
• V souladu s principem řízení po etapách vytváří Dodavatel na počátku projektu rámcový Plán projektu s úrovní detailu na jednotlivé etapy. Vyšší úroveň detailu s rozpadem na jednotlivé aktivity je rozpracována pro aktuální etapu. Plán projektu je průběžně aktualizován a prezentován na programovém výboru;
• Plán projektu je tvořen těmito dokumenty: Harmonogram projektu, Personální zajištění projektu, Rizika projektu, Úkoly, Získané zkušenosti, Akceptační kritéria;
5. Rizika
• Jsou součástí Plánu projektu;
6. Změny
• Změny v rámci mantinelů daných prováděcí smlouvou jsou řešeny formou dohody na programovém výboru (resp. na eskalační komisi, pokud vedení programu nedospěje ke shodě). Změny přesahující prováděcí smlouvu (např. změna termínu dodání výstupu, změna ceny apod.) musejí být řešeny eskalační komisí, a to formou dodatku k dané prováděcí smlouvě;
7. Postup prací
• Postup prací v projektu je pravidelně monitorován a reportován na programovém výboru.
Procesy - PRINCE2 definuje tyto procesy:
• zahájení projektu (předprojektová příprava),
• nastavení (iniciace) projektu,
• směřování (strategické řízení) projektu,
• kontrola (řízení) etapy,
• řízení dodávky produktu,
• řízení přechodu mezi etapami,
• ukončení projektu.
Vzhledem ke specifickému prostředí, v němž se Zadavatel pohybuje, jsou jeho projektové procesy vysoce customizované a nelze je na procesy PRINCE2 namapovat jedna ku jedné. Všechny výše vyjmenované procesy PRINCE2 však Zadavatel i Dodavatel ctí a jejich zásady jsou porůznu rozptýlené v předchozích kapitolách, zejména 2.4.3.2 – Životní cyklus projektu a 2.4.3.3. – Organizace projektu.
2.5. SLA
2.5.1. Definice termínů pro účely SLA
Plánovaná odstávka – Zadavatelem schválený čas, kdy a po jakou dobu nebude část infrastruktury SDDC nebo jednotlivá zařízení dostupná, např. kvůli upgrade firmware nebo rozsáhlejší rekonfiguraci apod. V průběhu plánované odstávky se nepočítá doba reakční, zahájení a doba opravy. Plánovaná odstávka je vždy prováděna na základě rozhodnutí odpovědných pracovníků Zadavatele. Tato doba rovněž není započítávána jako doba nedostupnosti systému pro účel dodržení požadované dostupnosti.
Reakční doba – doba od nahlášení do zahájení řešení incidentu, vady, problému nebo požadavku nahlášeného formou servisního záznamu na Helpdesk Dodavatele.
Zahájení řešení incidentu, vady, problému nebo požadavku znamená zpětný kontakt pracovníka Dodavatele s cílem komunikovat s pracovníky Zadavatele jejich požadavky a problémy a nabídnout řešení požadavku, resp. problému.
Doba opravy – doba od nahlášení incidentu do vyřešení incidentu, vady, problému nebo požadavku nahlášeného formou servisního záznamu na Helpdesk Dodavatele.
Obrázek 5 - Schéma hierarchie zodpovědnosti v rámci SLA na jednotlivé úrovně infrastruktury SDDC
2.5.2. SLA pro plnění A
Dodavatel je povinen poskytnout požadované MD a služby, resp. zahájit požadované činnosti ve lhůtě nejdéle do 5 pracovních dnů od účinnosti prováděcí smlouvy, resp. od přijetí dílčí objednávky z prováděcí smlouvy, pokud nebude v prováděcí smlouvě nebo dílčí objednávce dohodnuta lhůta jiná.
2.5.3. SLA pro plnění B
Typ závady | Požadovaná reakce a vyřešení závady |
A – Kritická závada 1 | Reakční doba: do 4 hodin Oprava: do 8 hodin |
A – Kritická závada 2 | Reakční doba: do 2 hodin Oprava (zajištění úrovně opravy umožňující provoz kritických systémů a aplikací Zadavatele v rámci dotčené lokality): do 4 hodin Oprava (zajištění plnohodnotného optimálního provozu infrastruktury): do 24 hodin Kritická závada 2 se vztahuje k výpadku jedné nebo obou lokalit (availability zón) primárního datového centra |
B – Významná závada | Reakční doba: do 8 hodin Oprava: do 24 hodin |
C – Ostatní závady a incidenty | Reakční doba: následující pracovní den (NBD) Oprava: do 30 dní |
Dodavatel je dle Plnění B této Rámcové dohody povinen poskytnout SLA na dostupnost a funkcionality infrastruktury SDDC Zadavatele v rozsahu dle objednaných jednotlivých Plnění B. V případě, že Xxxxxxxxx identifikuje příčinu závady nebo problém na jiné vrstvě infrastruktury SDDC, resp. na jiné úrovní než v rámci virtualizační platformy (jejíž realizace do podoby SDDC a provoz je předmětem plnění této Rámcové dohody), předá Zadavatel nebo v případě vzájemné dohody Dodavatel tuto závadu, resp. incident na Dodavatele příslušené úrovně infrastruktury SDDC, která závadu, resp. incident způsobila. V případě takovéhoto předání závady, resp. incidentu na Dodavatele jiných úrovní, resp. zařízení infrastruktury SDDC se Dodavateli tato skutečnost nezapočítává do doby výpadku určující SLA pouze za předpokladu, že následkům závady, resp. incidentu, nemohlo být zabráněno nebo předejito na úrovní virtualizační infrastruktury a služeb s tím spojených, jež jsou předmětem plnění této Rámcové dohody (např. pro případ výpadku serveru / nodu v rámci HCI infrastruktury, musí být následky eliminovány využitím vysoké dostupnosti apod. na úrovni virtualizační platformy). V případě „kombinovaných“ závad, resp. incidentů, kdy je příčinou nebo nezbytným předpokladem eliminace jejích následků a uvedení infrastruktury opět do provozu součinnost Dodavatelů více úrovní, resp. zařízení nebo technologií infrastruktury SDDC, nezapočítává se do doby určující SLA doba, po kterou Dodavatel nemůže prokazatelně plnit z důvodu potřebnosti výstupu Dodavatele jiné úrovně, resp. zařízení nebo technologie infrastruktury SDDC.
Z důvodu výše popsaných bude mít Zadavatel k dispozici smluvní SLA zpravidla v režimu 24x7x4 nebo 5x8xNBD (dle charakteru jednotlivých zařízení) se všemi Dodavateli jednotlivých zařízení, technologií a služeb infrastruktury SDDC.
2.5.4. Kategorie vad
2.5.4.1. Vada typu A – Kritická závada
Kritickou závadou se rozumí stav, kdy infrastruktura SDDC nebo její část (jednotlivá zařízení nebo technologie virtualizační platformy, jejich kombinace, implementace nebo konfigurace těchto zařízení, případně funkce a vlastnosti samotného zařízení) neposkytuje některou z funkcionalit nebo vlastností
specifikovaných v této Rámcově dohodě nebo prováděcí smlouvě, neposkytuje vlastnosti nebo
funkcionality běžně očekávané a předpokládané dle charakteru infrastruktury SDDC a:
a) znemožňující provoz (způsobení výpadku) celého datového centra nebo jeho podstatné části; mající dopad do znemožnění nebo omezení provozu (způsobení výpadku, snížení nedostupnosti, snížení odezvy, apod.) kritických aplikací Zadavatele; ohrožení bezpečnosti datové sítě a datových center Zadavatele;
b) infrastruktura SDDC, resp. zařízení a služby nesplňují účel, pro který byly dodány, implementovány a konfigurovány (definovaná v Rámcové dohodě případně prováděcí smlouvě) nebo není možné využívat všechny funkcionality, které jsou od takovýchto zařízení a služeb tvořících infrastrukturu SDDC z pohledu účelu infrastruktury SDDC, očekávané a nutné pro provoz kritických informačních systémů, přestože to bylo účelem plnění;
c) znemožňuje provedení požadovaných akceptačních testů nebo jinou akceptační proceduru;
d) způsobí nefunkční službu Helpdesk, pokud není zajištěn náhradní způsob hlášení chyb;
e) nebo libovolná kombinace výše uvedených stavů.
2.5.4.2. Vada typu B – Významná závada
a) závada způsobuje omezení provozu celého datového centra (např. výpadek jedné z redundantních částí) anebo jeho podstatné části (jak z pohledu HW infrastruktury, tak i virtualizační platformy tvořící infrastrukturu SDDC), mající dopad do omezení provozu aplikací Zadavatele (snížení dostupnosti, odezvy apod.) nebo omezení bezpečnosti infrastruktury a datových center Zadavatele;
b) infrastruktura SDDC, její část anebo zařízení (ať už HW nebo virtualizační platforma) je schopna omezeného provozu nebo neposkytuje některou z funkcionalit specifikovaných v Rámcové dohodě nebo prováděcí smlouvě, ale přesto lze bez významného omezení provozovat infrastrukturu SDDC, resp. zejména kritické systémy nad ní;
c) závada způsobuje, že některá část infrastruktury SDDC nebo některé zařízení není plně funkční, avšak tento stav má jen zanedbatelné dopady nebo omezení na provoz infrastruktury SDDC, resp. systému provozovaných nad ní;
d) způsobí nefunkční službu Helpdesk, pokud je zajištěn náhradní způsob hlášení chyb;
e) nebo libovolná kombinace výše uvedených stavů.
2.5.4.3. Vadou typu C – Ostatní závady a incidenty
Vadou typu C se rozumí ostatní vady, incidenty a neúplnosti, které nemají zásadní vliv na provoz, dostupnost nebo funkcionality infrastruktury datových center a virtualizační platformy (VCF) nad ní, resp. nemají vliv na provoz a funkcionality infrastruktury SDDC. Vada, která nespadá do kategorie A ani B.
2.6. Akceptace
2.6.1. Akceptace Plnění A – Implementační a konzultační služby
Plnění v rámci implementačních a konzultačních služeb A je akceptováno v akceptačním řízení na základě podpisu dílčího akceptačního protokolu.
Součástí akceptačního řízení jsou akceptační testy, je-li to pro dané plnění relevantní, které byly navrženy Dodavatelem a schváleny Zadavatelem dle požadavků na akceptační testy, projektové řízení a požadavků implementačního projektu. Z akceptačního řízení musí být pořízen zápis, jehož součástí je akceptační protokol. Akceptační protokol musí zejména přesně uvádět souhrn všech aktivit v členění, v jakém plnění bylo poskytnuto a v jakém rozsahu (např. počet MD), kdy k plnění došlo, jak dlouho trvalo, kdo jej provedl (jméno a příjmení pracovníka a jeho role), kdo jej objednal a kdy a současně musí obsahovat výstupy z akceptačního testování.
Dílčí akceptační protokoly budou podepisovány vždy za uplynulé kalendářní čtvrtletí (3 měsíce). Podkladem pro fakturaci jsou dílčí akceptační protokoly za předchozí kalendářní čtvrtletí, pokud se Smluvní strany v příslušné prováděcí smlouvě nedohodnou jinak.
2.6.2. Akceptace Plnění B – Služby podpory
Plnění B (B.1 až B.3) - Služby podpory je akceptováno na základě podpisu dílčího akceptačního protokolu. Dílčí akceptační protokol musí zejména uvádět číslo prováděcí smlouvy, dojednaný souhrn daných aktivit v členění, v jakém bylo plnění poskytnuto, v jakém rozsahu a za jaké období k plnění došlo. Dílčí akceptační protokoly budou podepisovány vždy za uplynulé kalendářní čtvrtletí (3 měsíce). Ke dni podpisu dílčího akceptačního protokolu Zadavatelem nesmí být evidována žádná vada kategorie A, která je způsobena plněním Dodavatele a s jejímž odstraněním by byl Dodavatel v prodlení. V takovém případě může být dílčí akceptační protokol podepsán Zadavatelem až po odstranění těchto vad. Podkladem pro fakturaci jsou dílčí akceptační protokoly za předchozí kalendářní čtvrtletí, pokud se Smluvní strany v příslušné prováděcí smlouvě nedohodnou jinak.
2.6.3. Akceptační testy
a) Před ukončením předmětného plnění musí Zadavatel provést za účasti Dodavatele oboustranně schválené akceptační testy, pokud je tento přístup aplikovatelný (nejedná se např. o samostatnou dodávku dokumentů, konzultace nebo obdobných činností nemající charakter implementačního projektu).
b) Předmět akceptace je akceptován, pokud nebude Zadavatelem uplatněna žádná vada kategorie A nebo taková kombinace vad typu B a/nebo C, které by ve svém důsledku způsobily vadu A a byla předána veškerá relevantní nová a/nebo aktualizovaná dokumentace. Chyby B a C nebránící akceptaci musí být popsány v akceptačním protokolu a musí být dohodnut termín jejich odstranění. To není možné, pokud jde o poslední plnění z Rámcové dohody, po jejím ukončení.
c) Jestliže předmětné plnění splní akceptační kritéria akceptačních testů specifikovaných a schválených v rámci implementačního projektu nebo odsouhlasených před započetím testů, podepíšou k němu Smluvní strany akceptační protokol. Podpisem akceptačního protokolu oběma Smluvními stranami se má za to, že předmětné plnění bylo řádně Dodavatelem poskytnuto a Zadavatelem převzato.
d) Jestliže předmětné plnění nesplňuje stanovená akceptační kritéria, zaznamenají tuto skutečnost Smluvní strany do akceptačního protokolu tak, že zde budou uvedeny, popsány a prokázány veškeré zjištěné vady a nedostatky. Dodavatel se zavazuje napravit tyto nedostatky ve lhůtě, která bude Smluvními stranami dohodnuta, a příslušné akceptační testy budou provedeny znovu (termín odstranění vad nesmí překročit termín plnění uvedený v příslušné prováděcí smlouvě včetně případných dodatků). Tento proces testování a následných oprav se bude opakovat, dokud Dodavatel nesplní veškerá akceptační kritéria.
e) Vadou se pro účely této Smlouvy rozumí rozpor mezi vlastností nebo funkčností plnění proti požadované vlastnosti nebo funkčnosti dodaných služeb a s tím případně souvisejících zařízení tak, jak bude specifikováno v této Rámcové dohodě nebo prováděcí smlouvě, případně dílčí objednávce z prováděcí smlouvy.
f) V případě schválení akceptačních testů, Zadavatel provede akceptaci (tj. podepíše akceptační protokol). V případě zjištěných dalších nedostatků nebo vad sdělí toto Zadavatel Dodavateli bez zbytečného odkladu, přičemž se opětovně postupuje dle písm. d) 2.6.3.
2.6.4. Akceptace Dokumentace
Bude-li plnění Dodavatele spočívat ve vypracování dokumentu v listinné nebo elektronické podobě, bude jeho akceptace provedena následovně:
a) Dodavatel předá v dohodnutém termínu první verzi dokumentu;
b) Zadavatel vznese své výhrady nebo připomínky k první verzi dokumentu obecně do tří (3), nejpozději do patnácti (15) pracovních dnů od jejího doručení (podle rozsahu dokumentace, do pěti dnů u rozsahu do 30-ti stran, nad 30 stran obecně nejpozději do 15-ti dnů, nebude-li dohodou na vedení projektu stanoveno jinak); nevznese-li Zadavatel ve stanovené lhůtě k první verzi dokumentu žádné výhrady ani připomínky, považují Smluvní strany uplynutím této lhůty dokument ve znění jeho první verze za řádně akceptovaný a pro Smluvní strany závazný;
c) vznese-li Zadavatel ve stanovené lhůtě své výhrady nebo připomínky k první verzi dokumentu, zavazuje se Dodavatel obecně do tří (3), nejpozději do pěti (5) pracovních dnů od jejich doručení provést veškeré potřebné úpravy dokumentu dle výhrad a připomínek Zadavatele a takto upravený dokument předat jako jeho druhou verzi Zadavateli k akceptaci.
d) Zadavatel se zavazuje vznést své výhrady nebo připomínky k druhé verzi dokumentu obecně do tří (3), nejpozději do pěti (5) pracovních dnů od jejího doručení. Nevznese-li Zadavatel ve stanovené lhůtě k druhé verzi dokumentu žádné výhrady ani připomínky, považují Smluvní strany uplynutím této lhůty dokument ve znění jeho druhé verze za řádně akceptovaný a pro Smluvní strany závazný. K výhradám nebo připomínkám, které Zadavatel opomněl vznést již k první verzi dokumentu, se pro účely akceptace nebude přihlížet, Dodavatel však bude povinen takovéto výhrady nebo připomínky Zadavatele vypořádat do deseti (10) pracovních dnů od akceptace dokumentu;
e) vznese-li Zadavatel ve stanovené lhůtě své výhrady nebo připomínky k druhé verzi dokumentu, zavazují se Smluvní strany zahájit společné jednání za účelem odstranění veškerých vzájemných rozporů a za účelem akceptace dokumentu, a to nejpozději do tří (3) pracovních dnů od výzvy kterékoliv Smluvní strany. Nepodaří-li se Smluvním stranám dojít ke shodě o akceptaci dokumentu ani ve lhůtě dvaceti (20) pracovních dnů od zahájení společného jednání dle předchozí věty, je kterákoli ze Smluvních stran oprávněna odstoupit od prováděcí smlouvy, které se schvalovaný dokument týká.
2.7. Záruky
2.7.1. Záruky plnění A
Na práce a služby dodané v rámci jednotlivých Plnění A se vztahuje záruka 12 měsíců.
2.7.2. Záruky plnění B
Není definována, je součástí probíhající služby/garance funkčnosti.
2.8. Smluvní pokuta
Zadavatel vyhodnotí vznik nároku na sankci vždy do 30 dnů od konce každého kalendářního čtvrtletí, kdy je služba poskytována. Zadavatel při vyhodnocení nároku na sankci přihlíží vždy ke všem okolnostem, za kterých k porušení SLA došlo. V případě, že není primární příčina na straně Dodavatele, tj. porušení bylo zapříčiněno nesoučinností Zadavatele či okolností, která se nedala předvídat, nebude sankce uplatněna. Maximální výše sankce je 10 000 000 Kč (deset miliónů korun českých) za každý jednotlivý případ porušení SLA, dosažení této hranice může být důvodem k vypovězení Rámcové dohody i všech prováděcích smluv.
2.8.1.1. Smluvní pokuta při nedodržení SLA
Při nedržení povolené doby výpadku dle 2.5. je Xxxxxxxxx povinen uhradit Zadavateli následující smluvní pokutu:
B. 1 – Sankce ve výši 50 000 Kč za každou započatou 1 hodinu překročení povolené doby výpadku.
B. 2 – Sankce ve výši 20 000 Kč za každou započatou 1 hodinu překročení povolené doby výpadku.
B. 3 – Sankce ve výši 10 000 Kč za každou započatou 1 hodinu překročení povolené doby výpadku.
2.8.1.2. Smluvní pokuta při překročení reakční doby a doby opravy
Výše sankce se vyčísluje vždy na překročení reakční doby a doby opravy.
V případě prodlení Xxxxxxxxxx s dodržením reakční doby a doby opravy dle smlouvy je Dodavatel
povinen uhradit Zadavateli následující smluvní pokutu dle níže uvedené kategorizace:
• Kategorie A (Kritická závada)
Sankce ve výši 10 000 Kč (deset tisíc korun českých) za každou započatou 1 hodinu překročení reakční
doby.
Sankce ve výši 10 000 Kč (deset tisíc korun českých) za každou započatou 1 hodinu překročení doby
opravy.
• Kategorie B (Významná závada)
Sankce ve výši 3 000 Kč (tři tisíce korun českých) za každou započatou 1 hodinu překročení reakční doby. Smluvní sankce ve výši 5 000 Kč (pět tisíc korun českých) za každou započatou 1 hodinu překročení doby opravy.
• Kategorie C (Ostatní závady a incidenty)
Sankce ve výši 1 000 Kč (jeden tisíc korun českých) za každou započatou 1 hodinu překročení reakční doby. Sankce ve výši 10 000 Kč (deset tisíc korun českých) za každých započatých 24 hodin překročení doby opravy.
2.8.1.3. Smluvní pokuta při nefunkčnosti Helpdesku
Při nefunkčnosti Helpdesku podle specifikace 2.3.4.4. je sankce ve výši 5 000 Kč (pět tisíc korun českých) za každou započatou hodinu pokud prostřednictvím Helpdesku (a to ani náhradním kanálem) nelze nahlásit vadu (zadat ticket).
Příloha č. 2 – „Specifikace ceny za předmět plnění“
Specifikace ceny Plnění A.1 a A.2 | |||
Název služby Plnění A.1 a A.2 (variabilní část) | Jednotka služby | Cena za 1 jednotku (v Kč bez DPH) | Cena za 1 jednotku (v Kč s DPH) |
Projektový manager | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Architekt řešení / Infrastrukturní architekt | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Kapacitní manažer | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
HCI inženýr | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Storage inženýr (SDS) | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Desktop a mobility inženýr | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Inženýr síťové virtualizace (SDN) | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Inženýr správy cloudu a automatizace | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
HCI Operátor | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Storage Operátor | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Desktop a mobility Operátor | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Operátor síťové virtualizace (SDN) | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Vývojář cloudové automatizace | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Analytik | 1 MD = 8hodin | 17 900,00 Kč | 21 659,00 Kč |
Specifikace ceny Plnění B | |||
Plnění | Jednotka služby | Cena za 1 jednotku (v Kč bez DPH) | Cena za 1 jednotku (v Kč s DPH) |
B.1 - Primární datové centrum (2 lokality) | 1 datové centrum / 1 rok | 1 280 000,00 Kč | 1 548 800,00 Kč |
B.1a - rozšíření B.1 o 1 POD | 1 POD / 1 rok | 40 000,00 Kč | 48 400,00 Kč |
B.2 - Sekundární datové centrum (1 lokalita) | 1 datové centrum / 1 rok | 1 280 000,00 Kč | 1 548 800,00 Kč |
B.2a - rozšíření B.2 o 1 POD | 1 POD / 1 rok | 40 000,00 Kč | 48 400,00 Kč |
B.3 - EDGE datové centrum | 1 datové centrum / 1 rok | 700 000,00 Kč | 847 000,00 Kč |
B.3a - rozšíření B.3 o 1 POD | 1 POD / 1 rok | 30 000,00 Kč | 36 300,00 Kč |
Příloha č. 3 – „Vzor prováděcí smlouvy“
Příloha č. 3 Rámcové Dohody č.j.:…………………..
Vzor návrhu na uzavření
Prováděcí smlouvy o poskytnutí plnění dle Rámcové dohody (lze upravit dle konkrétních podmínek)
Prováděcí smlouva č. ……… č.j…………..…..
k Rámcové dohodě č.j.………………………
Smluvní strany:
Česká republika – Ministerstvo vnitra
Sídlo: Nad Xxxxxx 000/0, XXX 000 00, Xxxxx
IČ: 00007064
DIČ: CZ00007064
Zastoupená: ,
Bankovní spojení: Česká národní banka, Praha 1
č.ú. 5504881/0710
Korespondenční adresa: Policejní prezidium ČR, Ředitelství pro podporu výkonu služby,
xxxxxxxx xxxxxxxx 00/ XXXX, 000 00 Xxxxx 0
(dále jen „Objednatel“)
a
……………………………..
……………………………..
……………………………..
(dále jen „Dodavatel“)
(společně dále také jen „Smluvní strany“, nebo jednotlivě „Smluvní strana“)
uzavřely tuto Prováděcí smlouvu (dále jen „Prováděcí smlouva“) k Rámcové dohodě
………………….., ze dne………… (dále jen „Rámcová dohoda“) v souladu s ustanoveními zákona č. 89/2012 Sb., občanský zákoník, (dále jen „občanský zákoník“) a zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen „ZZVZ) k veřejné zakázce s názvem ……………….
č.j……………..
1. PŘEDMĚT SMLOUVY
1.1. Předmětem této Prováděcí smlouvy je závazek Dodavatele poskytnout Objednateli plnění
v souladu se specifikací uvedenou v Příloze č. 1 této Prováděcí smlouvy (dále též jen
„Plnění“).
1.2. Objednatel se zavazuje řádně dodané Plnění převzít a zaplatit za něj dohodnutou cenu, a to způsobem definovaným v této Prováděcí smlouvě a v Rámcové dohodě.
2. CENA
2.1. Celková cena za Plnění dle této Prováděcí smlouvy činí ……………,- Kč bez DPH,
……………,- Kč s DPH. Cena za jednotlivé položky Plnění je uvedena v Příloze č. 2 této Prováděcí smlouvy.
3. TERMÍN PLNĚNÍ A MÍSTO PLNĚNÍ
3.1. Dodavatel je povinen dodat předmět plnění do od účinnosti smlouvy (v období
od………. do… ), pokud v Příloze č. 1 není stanoveno jinak.
3.2. Místem plnění je………..
3.3. Adresa Objednatele pro doručení daňového dokladu je: Policejní prezidium ČR, Ředitelství pro podporu výkonu služby, Strojnická 27, poštovní schránka 62/ŘPVS, 170 89 Praha 7
4. OSTATNÍ UJEDNÁNÍ
4.1. Veškerá ujednání této Prováděcí smlouvy navazují na Rámcovou dohodu a podmínkami uvedenými v Rámcové dohodě se řídí, tj. práva a povinnosti či skutečnosti neupravené v této Prováděcí smlouvě se řídí ustanoveními Rámcové dohody.
4.2. Tato Prováděcí smlouva nabývá účinnosti dnem uveřejnění v registru smluv dle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv).
4.3. Tato Smlouva je podepsána oběma Smluvními stranami elektronickým podpisem.
4.4. Nedílnou součástí této Smlouvy jsou následující přílohy: Příloha č. 1 – „Specifikace předmětu plnění“
Příloha č. 2 – „Rozpočet ceny“ (další přílohy )
V ……….. dne …………. V ………… dne …………….
Objednatel: Dodavatel:
………………….. …………………..
Ministerstvo vnitra – Česká republika …………………………
Zástupce: …………….. Zástupce: ………………..