Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

Zamówienia na usługi data center

Data publikacji: 22-01-2020 Autor: Bohdan Widła
W listopadzie 2019 r. rozpoczął się spór między Amazonem a Departamentem Obrony Stanów Zjednoczonych dotyczący przetargu na udostępnienie infrastruktury w ramach projektu Joint Enterprise Defense Infrastructure (JEDI). O zamówienie warte ponad 10 miliardów dolarów ubiegali się też inni najwięksi gracze: Microsoft, Oracle, IBM. Choć w Polsce przetargi na usługi świadczone w centrach przetwarzania danych nie wywołują jeszcze tak spektakularnych sporów, zamówień z tej kategorii jest coraz więcej.
 
W przetargu JEDI to właśnie Amazon był uznawany za faworyta, a jednak zamówienia udzielono Microsoftowi. Czas pokaże, czy ta decyzja zostanie uznana za prawidłową przez amerykański sąd. Choć zapewne wiele czasu upłynie, zanim w Polsce będziemy mieli do czynienia z przedsięwzięciami na miarę JEDI, to należy zauważyć, że rosnąca liczba zamówień idzie w parze ze zróżnicowaniem ich charakteru: obok przetargów na usługi kolokacji można spotkać coraz więcej postępowań, których przedmiotem są usługi chmurowe, takie jak SaaS, PaaS czy IaaS. Także w postępowaniach, których przedmiotem jest „klasyczne” wdrożenie systemu informatycznego, można spotkać się z wymaganiem, aby infrastruktura została zapewniona w modelu IaaS. 
 
> WSPÓLNA INFRASTRUKTURA INFORMATYCZNA PAŃSTWA
 
Zainteresowanie podmiotów publicznych usługami przetwarzania danych w chmurze może wzrosnąć z uwagi na projekt Wspólnej Infrastruktury Informatycznej Państwa (WIIP) prowadzony przez Ministerstwo Cyfryzacji. Jego celem jest między innymi uruchomienie Rządowej Chmury Obliczeniowej (RChO), z której będą mogły korzystać przede wszystkim podmioty należące do sektora finansów publicznych. Wraz z nią ma powstać Rządowy Klaster Bezpieczeństwa.
 
Projekt WIIP jest wciąż na początkowym etapie. We wrześniu 2019 r. została przyjęta uchwała Rady Ministrów, która miała nadać mu ramy formalne. Z jej projektu nie wynikało jasno, czy korzystanie z zasobów RChO miało być obowiązkiem przynajmniej części podmiotów publicznych, czy też miały one „jedynie” obowiązek skonsultowania możliwości skorzystania z tych zasobów. Ostatecznie przesądzono, że skorzystanie z RChO będzie jedynie prawem, a nie obowiązkiem. Nie rozstrzygnięto wszystkich wątpliwości zgłaszanych na etapie prac nad uchwałą. Od strony czysto formalnej można wspomnieć o tym, że uchwała w sprawie WIIP co prawda odnosi się także do jednostek samorządu terytorialnego, jednak formalnie nie wiąże ich, bo nie są organizacyjnie podległe Radzie Ministrów. Krytyczne uwagi zgłaszał też Prezes Urzędu Ochrony Danych Osobowych. Kwestia tego, czy zostały uwzględnione, wyjaśni się dopiero, gdy znane będą pierwsze porozumienia pomiędzy Ministrem Cyfryzacji a podmiotami zainteresowanymi podłączeniem do RChO.
 
Wart uwagi jest także załącznik nr 2 do uchwały w sprawie WIIP. Opisano w nim kategorie systemów, które mogą korzystać z różnego rodzaju usług przetwarzania danych w chmurze. Wskazano w nim systemy, które muszą korzystać z osobnej infrastruktury informatycznej (np. przetwarzające informacje niejawne), systemy mogące działać także w ramach RChO (np. wykorzystywane do prowadzenia rejestrów, ewidencji i innych baz danych większości służb mundurowych) oraz systemy, które mogą funkcjonować w chmurze publicznej, o ile jest ona „w jurysdykcji” krajowej lub państwa UE (np. systemy ERP i systemy do elektronicznego zarządzania dokumentacją). Wydaje się, że przez „jurysdykcję” trzeba tu rozumieć fizyczną lokalizację centrum przetwarzania danych.
 
Podstawowym problemem praktycznym w tej chwili jest jednak to, że na usługi świadczone w ramach RChO trzeba jeszcze zaczekać. Według harmonogramu ogłoszonego latem 2019 r. centra przetwarzania danych, na podstawie których ma działać rządowa chmura, mają zostać wyposażone w drugiej połowie 2020 r. Na pierwsze usługi będzie trzeba poczekać do 2021 r., oczywiście zakładając, że nie dojdzie do opóźnień. Na początku w ramach RChO mają być świadczone usługi w modelu IaaS. Dopiero później mają do nich dołączyć usługi PaaS i SaaS, co będzie wymagało zaangażowania dostawców komercyjnych.
Jednym z elementów inicjatywy WIIP ma być także stworzenie mechanizmu ułatwiającego zamawianie usług świadczonych w ramach publicznej chmury obliczeniowej za pośrednictwem systemu o wdzięcznym akronimie ZUCh (system Zapewniania Usług Chmurowych). Według uchwały Rady Ministrów usługi przetwarzania danych w publicznych chmurach obliczeniowych trafią do katalogu prowadzonego w systemie ZUCh po zawarciu umów w wyniku postępowań o udzielenie zamówienia publicznego. Na produkcyjną wersję tego systemu także mamy czekać przynajmniej do 2021 r. Ministerstwo twierdzi, że dzięki systemowi ZUCh zamawiający będą mogli szybciej uzyskać potrzebne usługi, a lokalni dostawcy będą mogli łatwiej konkurować z dużymi przedsiębiorstwami. Czas pokaże, w jakim stopniu ta obietnica zostanie zrealizowana. Trzeba przy tym pamiętać, że ostatecznie za prawidłowe wydatkowanie środków publicznych odpowiadać będą poszczególni zamawiający. 
 
Obecnie zainteresowanym usługami świadczonymi przez centra przetwarzania danych zamawiającym z sektora publicznego pozostaje tradycyjne udzielanie zamówień. Z reguły będzie to oznaczać zastosowanie ustawy z 29 stycznia 2004 r. – Prawo zamówień publicznych (pzp), która będzie obowiązywać jeszcze do końca 2020 r.
 
> PROBLEMY Z SIWZ
 
Nie brakuje tu problemów znanych z innych kategorii zamówień w branży IT: niekonkurencyjnych wymagań i warunków udziału w postępowaniu czy też nieprzemyślanych warunków umowy.
W przypadku zamówień na usługi świadczone w centrach przetwarzania danych łatwo o wprowadzenie wymagań, które znacząco ograniczą grono wykonawców mogących ubiegać się o zamówienie. Nie szukając daleko, można wskazać tu na wymogi dotyczące niezawodności centrum przetwarzania danych. Chodzi zwłaszcza o wymóg posiadania jednego z uznawanych certyfikatów zgodności z takimi normami lub rodzinami norm, jak PN-EN 50600, ANSI TIA-942 czy normami Uptime Institute. Postawienie tu wymogu posiadania przez centrum przetwarzania danych najwyższej klasy bardzo mocno ogranicza grono potencjalnych wykonawców. 
 
Oczywiście wymagania w tym zakresie same w sobie mają merytoryczne uzasadnienie, a między poszczególnymi klasami są różnice. Skok jakościowy liczony w dziesiątkach godzin widać zwłaszcza między klasą II (w zależności od normy 99,749% lub 99,741% dostępności) a klasą III (z reguły 99,982% dostępności). Jednak za każdym razem wyznacznikiem powinny być uzasadnione, rzeczywiste potrzeby zamawiającego. Pewną podpowiedzią może być tu wymaganie ujęte we wspomnianym już załączniku do uchwały Rady Ministrów w sprawie Wspólnej Infrastruktury Informatycznej Państwa. Wynika z niego, że centrum przetwarzania danych, za pomocą którego ma być świadczona usługa w ramach Rządowej Chmury Obliczeniowej, do której mają przecież trafić niektóre systemy istotne z punktu widzenia interesu publicznego, powinno mieć co najmniej klasę 3 według PN-EN 50600.
 
Innym przykładem wymagania, które może budzić znaczne wątpliwości z punktu widzenia zasady konkurencyjności postępowania, jest ograniczenie lokalizacji centrum przetwarzania danych. Również w tym przypadku niektóre ograniczenia są w pełni uzasadnione. Na przykład ograniczenie terytorium do Unii Europejskiej lub Europejskiego Obszaru Gospodarczego może być uwarunkowane przepisami o ochronie danych osobowych. Także wymóg ulokowania centrum na terenie Polski może okazać się uzasadniony ze względu na specyficzny charakter przetwarzanych danych. Jednak w praktyce można spotkać się z dalej idącymi wymaganiami, np. aby centrum znajdowało się w konkretnym rejonie na terenie Polski, albo warunkami wymuszającymi to pośrednio przez ograniczenie odległości między siedzibą zamawiającego a centrami przetwarzania danych. Ograniczenia tego typu dużo trudniej uzasadnić. Z punktu widzenia zamawiającego istotne jest przede wszystkim zapewnienie, że usługi świadczone są w centrum przetwarzania danych mającym określone cechy. Nie decyduje o nich odległość między siedzibą zamawiającego a centrum ani tym bardziej ulokowanie centrum w konkretnej miejscowości.
 
Jeśli chodzi o warunki umów, niestety wciąż można spotkać się z przypadkami nieprzemyślanego narzucania wymagań dotyczących poziomu świadczonych usług. Nie zawsze oczywiste dla niektórych zamawiających okazuje się nie tylko to, jak wielka jest różnica między dostępnością na poziomie 99% (ponad 3 dni w skali roku) a 99,9% (niecałe dziewięć godzin w skali roku), ale także to, że konsekwencją skrócenia okresu rozliczenia z roku do miesiąca jest dwunastokrotne skrócenie dopuszczalnego czasu niedostępności, co jest radykalnym zwiększeniem wymagań.
 
Z drugiej strony zdarzają się też wymagania, które tylko z pozoru są wystarczające, a w praktyce nie zabezpieczają interesu zamawiającego. Można tu wyobrazić sobie na przykład jednostkę samorządu terytorialnego, która zamierza skorzystać w modelu SaaS z rozwiązania wspierającego rekrutację do szkół. Bardzo wysoka dostępność takiego systemu mimo znacznego obciążenia jest istotna tylko w kilkudniowym okresie w danym roku. Postawienie wymagania, aby rozwiązanie było dostępne na poziomie 99% w skali roku, narażałoby zamawiającego na utratę dostępu nawet przez kilka dni w newralgicznym okresie, a wykonawca mógłby z łatwością nadrobić stracony czas „poza sezonem” rekrutacji. W takich przypadkach sensowne może okazać się różnicowanie wymagań w zależności od okresu lub charakteru usługi, a także wprowadzenie wymagań dotyczących maksymalnego czasu trwania jednorazowej niedostępności w krytycznym okresie.
 
[...]
 
Radca prawny współpracujący z kancelarią Barta & Kaliński sp.j., doktor nauk prawnych, specjalista z zakresu prawa własności intelektualnej, prawa zamówień publicznych oraz problematyki prawnej związanej z realizacją projektów IT. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"