Sprint Data Center • ul. Jagiellończyka 26, 10-062 Olsztyn
+48 89 522 12 20
info@sprintdatacenter.pl

Przetarg na serwer dedykowany — dlaczego sam opis procesora w OPZ to za mało

blog informacyjny dla użytkowników usług SDC

Created with Sketch.

Przetarg na serwer dedykowany — dlaczego sam opis procesora w OPZ to za mało (grafika wygenerowana przez AI)

Przetarg na serwer dedykowany — dlaczego sam opis procesora w OPZ to za mało

Opis przedmiotu zamówienia na serwer dedykowany w wielu postępowaniach wygląda jak wyciąg ze specyfikacji sprzętowej: model procesora, liczba gigabajtów pamięci, pojemność dysków, przepustowość karty sieciowej. To zrozumiały odruch — tak opisuje się dostawę sprzętu. Problem w tym, że serwer dedykowany dostawą sprzętu nie jest.

Zamawiający nie stanie się właścicielem maszyny, nie podpisze protokołu odbioru urządzenia i nie wprowadzi go do ewidencji środków trwałych. Kupuje usługę świadczoną przez kilkadziesiąt miesięcy: moc obliczeniową, łącze, zasilanie, chłodzenie, utrzymanie i gotowość do naprawy. Jeśli OPZ tego nie odzwierciedla, postępowanie kończy się rundą pytań wykonawców, odwołaniem albo — najgorzej — umową, którą formalnie zrealizowano, a której nie da się sensownie używać.

Kupujesz usługę, nie sprzęt — i to zmienia cały dokument

Konsekwencje tej różnicy są bardzo praktyczne. Skoro nie ma odbioru urządzenia, punktem odniesienia dla rozliczeń jest dostępność usługi, a nie fakt dostarczenia sprzętu. Skoro serwer pozostaje własnością wykonawcy, jego wymiana na równoważny w trakcie umowy jest normalnym elementem utrzymania, a nie zmianą przedmiotu zamówienia — o ile OPZ przewidział to wprost.

Dlatego dokument powinien opisywać trzy warstwy, a nie jedną:

  1. Parametry techniczne — minimalne wymagania wydajnościowe.
  2. Warunki świadczenia usługi — czas reakcji, czas naprawy, czas uruchomienia, dostęp zdalny, wsparcie.
  3. Warunki organizacyjno-prawne — gdzie dane są przetwarzane, kto ma do nich dostęp fizyczny, co dzieje się po zakończeniu umowy.

Pierwsza warstwa zwykle jest opisana zbyt szczegółowo, a dwie kolejne — wcale.

Parametry techniczne: opisuj wymaganie, nie katalog dostawcy

Art. 99 ustawy Prawo zamówień publicznych zakazuje opisywania przedmiotu zamówienia w sposób, który mógłby utrudniać uczciwą konkurencję. Wskazanie znaku towarowego, patentu lub pochodzenia jest dopuszczalne tylko wyjątkowo — z dopiskiem „lub równoważny" oraz z opisem kryteriów równoważności. W praktyce oznacza to, że nazwa konkretnego modelu procesora w OPZ niemal zawsze jest błędem, który wykonawcy szybko wyłapią.

Procesor i pamięć

Zamiast wskazywać konkretny układ, opisz minimalną liczbę rdzeni fizycznych i wymagany poziom wydajności potwierdzony powszechnie dostępnym testem porównawczym — z podaniem nazwy testu i progu punktowego. Taki zapis jest weryfikowalny i nie zamyka drogi ani platformom AMD, ani Intel. To realna różnica: w naszym katalogu funkcjonuje kilkanaście linii serwerów opartych na procesorach obu producentów, a tę samą potrzebę obliczeniową da się zaspokoić na kilka sposobów. Jak czytać taki katalog, opisaliśmy w tekście Ponad 20 linii serwerów dedykowanych — jak czytać katalog SDC.

Dyski i przestrzeń użytkowa

Nie opisuj liczby i pojemności nośników — opisz przestrzeń użytkową po zestawieniu macierzy oraz wymaganą redundancję, na przykład odporność na awarię jednego nośnika bez utraty danych. Zamawiający zwykle potrzebuje określonej ilości miejsca i pewnego poziomu bezpieczeństwa, a nie konkretnej konfiguracji RAID. Osobno warto wskazać wymaganą technologię nośników, jeśli aplikacja jest wrażliwa na czas dostępu.

Łącze i transfer

Sama przepustowość portu to połowa informacji. Druga połowa to miesięczny limit transferu i to, co dzieje się po jego przekroczeniu: naliczenie opłaty, ograniczenie prędkości czy wstrzymanie usługi. Różnice między wykonawcami bywają tu ogromne, a porównywanie ofert bez tego parametru jest pozorne. W naszej ofercie serwerów dedykowanych limit wynosi 10 TB miesięcznie w cenie usługi, a ochrona anty-DDoS należy do standardu — jeśli dla zamawiającego to istotne, powinno wprost wynikać z OPZ, bo nie u każdego dostawcy jest oczywistością.

Trzy rzeczy, których zwykle brakuje

Lokalizacja przetwarzania i dostęp fizyczny

Dla instytucji publicznej to często najważniejszy parametr, a w OPZ pojawia się najrzadziej. Warto wymagać wskazania konkretnej lokalizacji ośrodka przetwarzania, opisania zasad dostępu fizycznego do infrastruktury oraz rejestracji wizyt. Nasze serwery pracują we własnym centrum danych w Olsztynie, objętym całodobowym monitoringiem wizyjnym i systemem kontroli dostępu z pełną rejestracją wejść — szczegóły opisuje strona Data Center.

Do tego dochodzi warstwa certyfikacyjna. Jeśli postępowanie dotyczy danych wrażliwych, kryteria mogą odwoływać się do systemów zarządzania potwierdzonych certyfikatami ISO 27001, ISO 22301 i ISO 9001, do certyfikatu natowskiego systemu zarządzania jakością AQAP czy do świadectwa bezpieczeństwa przemysłowego. Które z nich mają znaczenie przy jakim rodzaju danych, rozkładamy na czynniki pierwsze we wpisie Dane wrażliwe i niejawne — jakie certyfikaty data center naprawdę decydują. Pamiętaj też o umowie powierzenia przetwarzania danych — jej projekt powinien być załącznikiem do SWZ, a nie tematem negocjacji po wyborze oferty.

Czas reakcji, naprawy i uruchomienia

To parametry, które w praktyce decydują o jakości usługi, a łatwo je pominąć. W OPZ powinny znaleźć się co najmniej trzy wartości: czas reakcji na zgłoszenie, czas przywrócenia sprawności po awarii sprzętowej oraz termin uruchomienia usługi liczony od zawarcia umowy. W naszym przypadku uszkodzony element lub cały serwer wymieniamy w ciągu 6 godzin, a uruchomienie usługi zajmuje od 5 minut do 72 godzin w zależności od konfiguracji — takie liczby da się porównać między ofertami i egzekwować w umowie.

Warto też wymagać zdalnej konsoli zarządzania (IPMI) oraz określić dostępność wsparcia technicznego. Jeśli zamawiający potrzebuje kontaktu poza godzinami pracy urzędu, zapis o wsparciu 24/7 musi znaleźć się w dokumencie, a nie w domyśle.

Zakończenie umowy i zwrot danych

Umowa w zamówieniu publicznym jest terminowa, więc scenariusz jej zakończenia trzeba opisać z góry: w jakim terminie i w jakiej formie wykonawca udostępni dane, jak potwierdzi ich trwałe usunięcie ze swoich zasobów i czy zapewni wsparcie przy migracji. Brak tych zapisów zamienia koniec umowy w improwizację — a instytucja zostaje z danymi u dostawcy, którego właśnie przestała opłacać.

Kryteria oceny ofert — jak nie kupić najtańszego problemu

Przepisy ograniczają możliwość oceniania ofert wyłącznie przez pryzmat ceny i słusznie: w usługach infrastrukturalnych cena bez kontekstu jest myląca. Sensowne kryteria pozacenowe to skrócony czas naprawy, szerszy zakres wsparcia, wyższy limit transferu, potwierdzona lokalizacja przetwarzania czy udokumentowane systemy zarządzania bezpieczeństwem.

Dobrym pomysłem jest też sprawdzenie usługi, zanim stanie się przedmiotem sporu — w ofercie komercyjnej udostępniamy 7-dniowy okres próbny, a umowy zawieramy bezterminowo i bez opłat aktywacyjnych. Nawet jeśli reżim zamówieniowy nie pozwala na test przed wyborem oferty, warto wiedzieć, że deklarowane parametry da się zweryfikować w praktyce.

Analogiczne podejście dla usługi kolokacji opisaliśmy wcześniej w tekście Kolokacja w zamówieniach publicznych — jeśli postępowanie obejmuje obie usługi, warto zestawić oba dokumenty.

Podsumowanie

Dobry OPZ na serwer dedykowany opisuje potrzebę, nie katalog. Parametry wydajnościowe formułuj jako minima możliwe do zweryfikowania, warunki świadczenia usługi opisz liczbowo, a warstwę organizacyjną — lokalizację, dostęp, certyfikaty, zwrot danych — potraktuj równie poważnie jak liczbę rdzeni. Postępowanie przygotowane w ten sposób jest odporne na odwołania i daje instytucji usługę, z której faktycznie da się korzystać przez cały okres umowy.

Przygotowujesz postępowanie na infrastrukturę serwerową? Zobacz ofertę serwerów dedykowanych Sprint Data Center albo napisz do nas — pomożemy dobrać parametry techniczne, które opiszesz w OPZ bez wskazywania konkretnego producenta.

FAQ – najczęściej zadawane pytania o serwer dedykowany w zamówieniu publicznym

Czy w OPZ można wskazać konkretny model procesora?

Co do zasady nie. Prawo zamówień publicznych dopuszcza wskazanie znaku towarowego tylko wyjątkowo, gdy nie da się opisać przedmiotu zamówienia w inny sposób — i wymaga wtedy dopisku „lub równoważny" oraz opisania kryteriów równoważności. Bezpieczniej opisać minimalną liczbę rdzeni fizycznych i wymagany wynik testu wydajności.

Serwer dedykowany to dostawa czy usługa w rozumieniu zamówienia publicznego?

To usługa. Zamawiający nie nabywa własności sprzętu, tylko prawo do korzystania z zasobów wraz z ich utrzymaniem przez czas trwania umowy. Ma to wpływ na rozliczenia, oznacza brak protokołu odbioru urządzenia i sprawia, że wymiana sprzętu na równoważny jest normalnym elementem realizacji.

Jakie parametry SLA warto wpisać do opisu przedmiotu zamówienia?

Minimum to czas reakcji na zgłoszenie, czas przywrócenia sprawności po awarii sprzętowej i termin uruchomienia usługi. Warto dodać wymaganą dostępność wsparcia technicznego oraz dostęp do zdalnej konsoli zarządzania serwerem, bo bez niej administrator zamawiającego traci kontrolę nad maszyną przy awarii systemu.

Czy można wymagać, żeby serwery stały w Polsce?

Tak, o ile wymaganie jest uzasadnione charakterem przetwarzanych danych i opisane przez cel, a nie przez wskazanie konkretnego wykonawcy. Zamawiający może żądać podania lokalizacji ośrodka przetwarzania, zasad dostępu fizycznego oraz przedstawienia projektu umowy powierzenia przetwarzania danych.

Co powinno znaleźć się w zapisach o zakończeniu umowy?

Termin i forma udostępnienia danych zamawiającemu, sposób potwierdzenia ich trwałego usunięcia po stronie wykonawcy oraz zakres wsparcia przy migracji do nowego środowiska. Bez tych zapisów zakończenie umowy staje się improwizacją, a instytucja traci kontrolę nad harmonogramem.


Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.