Jak zaprojektować infrastrukturę IT w firmie?

Strategiczny przewodnik od RTO/RPO do Zero Trust

Infrastruktura, która działa… do dnia incydentu

W poniedziałek rano system ERP nie wstał po weekendowej aktualizacji. Serwer fizycznie działał, backupy „gdzieś były”, a kluczowy administrator był na urlopie.

Pierwsze pytanie Zarządu nie dotyczyło technologii. Brzmiało: ile potrwa przywrócenie systemu i ile danych stracimy?

I wtedy okazało się, że nikt w firmie nie zna konkretnej odpowiedzi.

Nie dlatego, że ktoś popełnił błąd. Dlatego, że infrastruktura IT nigdy nie była zaprojektowana tylko była doraźnie składana, decyzja po decyzji, bez jednego punktu odniesienia.

W takich momentach wychodzi na jaw, że straty nie są tylko finansowe. To także utrata danych transakcyjnych, utrata zaufania klientów, przestój operacyjny, a czasem naruszenie RODO, za które odpowiedzialność ponosi Zarząd, nie dział IT.

Projektowanie infrastruktury IT nie polega na doborze serwerów ani technologii.
Polega na świadomym zaplanowaniu:

• co ma działać w sytuacji krytycznej,
• ile firma może nie działać,
• ile danych może stracić,
• i kto ponosi odpowiedzialność, gdy coś pójdzie nie tak.

To jest różnica między infrastrukturą, która „jakoś działa”, a infrastrukturą, która działa również wtedy, gdy pojawia się incydent.

Dokładnie z takimi scenariuszami trafiają do nas firmy w SparkSome. Nie po awarii, tylko w momencie, gdy chcą sprawdzić, czy ich infrastruktura została faktycznie zaprojektowana, a nie tylko „złożona z elementów”.

Problem, który „nie istnieje” do pierwszego audytu

Większość firm nie projektuje infrastruktury IT. Tylko dokładają nowy serwer, więcej dysków i kolejne maszyny wirtualne czy nową usługę w chmurze.

Ten model działa… aż do momentu, w którym:

• dane trzeba realnie odtworzyć, a nie tylko „mieć backup”,
• system trzeba przenieść lub odbudować po awarii,
• spółka musi udowodnić audytorowi, że systemy są od siebie logicznie odseparowane,
• albo ktoś z kluczową wiedzą przestaje być dostępny.

Ten problem najczęściej ujawnia się dopiero przy pierwszym audycie, pierwszej awarii albo pierwszym incydencie bezpieczeństwa. I wtedy okazuje się, że brak projektu nie jest problemem technicznym tylko jest problemem decyzyjnym.

Faza 1: fundamenty strategiczne – BIA, RTO i RPO

Projektowanie infrastruktury IT zaczyna się od jednego pytania: co musi działać, kiedy wszystko inne przestaje działać?

Dopiero odpowiedź na to pytanie nadaje sens wszystkim decyzjom technicznym od wyboru architektury, przez backup, po bezpieczeństwo. Bez niej infrastruktura zawsze będzie reagować na problemy, zamiast być na nie przygotowana.

BIA – analiza wpływu na biznes

Business Impact Analysis to proces, w którym firma identyfikuje:

• które systemy są naprawdę krytyczne,
• jakie straty finansowe, prawne i wizerunkowe powoduje ich niedostępność,
• po jakim czasie przestój przestaje być „problemem IT”, a zaczyna być problemem Zarządu.

Ten problem ujawnia się w momencie, gdy Zarząd musi podjąć decyzję, który system ratujemy pierwszy, a nie ma do tego żadnych danych tylko presję czasu i rosnące straty.

W SparkSome bardzo często widzimy, że BIA nigdy nie została przeprowadzona formalnie, a RTO i RPO istnieją wyłącznie w dokumentach. Ich realne wartości wychodzą dopiero podczas testów odtwarzania… albo pierwszego incydentu.

RTO – ile czasu firma może nie działać

RTO określa maksymalny czas niedostępności systemu, jaki firma jest w stanie zaakceptować, zanim przestój zacznie realnie paraliżować operacje lub generować straty.

Jeśli po awarii przywracanie systemu trwa dni, a nie godziny, to znaczy, że:

• RTO istniało tylko „na papierze”,
• infrastruktura nigdy nie była projektowana pod rzeczywiste scenariusze awaryjne.

Firmy dowiadują się o tym dopiero w momencie, gdy Zarząd musi odpowiedzieć na pytanie klientów lub kontrahentów, dlaczego system nadal nie działa.

RPO – ile danych możesz stracić

RPO odpowiada na pytanie, jaką utratę danych firma jest w stanie zaakceptować i czy jest tego świadoma.

To parametr, który bezpośrednio wpływa na:

• strategię backupu,
• sposób replikacji danych,
• koszty infrastruktury i jej złożoność.

W praktyce po incydencie zawsze pada to samo pytanie: dlaczego nikt nie sprawdził wcześniej, czy backup da się odtworzyć w wymaganym czasie?

I to jest moment, w którym problem techniczny staje się problemem decyzyjnym.

Faza 2: architektura fizyczna i warstwa abstrakcji

Dopiero po zdefiniowaniu RTO i RPO wybiera się technologie. W nowoczesnym podejściu serwer fizyczny nie jest centrum infrastruktury. Jest tylko zasobem obliczeniowym, którym zarządza warstwa abstrakcji.

Wirtualizacja, HCI i konteneryzacja

Warstwa abstrakcji w infrastrukturze IT ma jeden cel: zmniejszyć zależność biznesu od pojedynczego elementu technicznego i skrócić czas odtwarzania po awarii.

Hiperkonwergencja (HCI) pozwala traktować:

• moc obliczeniową,
• pamięć masową,
• sieć

jako jeden spójny zasób zarządzany centralnie. Dzięki temu awaria jednego serwera nie musi oznaczać przestoju usługi ponieważ obciążenie jest przejmowane przez pozostałe węzły klastra.

Konteneryzacja (Docker, Kubernetes) idzie krok dalej. Umożliwia bardzo szybkie odtwarzanie aplikacji i większą elastyczność, ale tylko wtedy, gdy istnieje warstwa orkiestracji, która:

• wie, gdzie aplikacja powinna działać,
• decyduje, kiedy ją przenieść,
• pilnuje zależności między usługami.

Pułapka techniczna pojawia się wtedy, gdy firmy wdrażają kontenery bez Kubernetes. W takim scenariuszu chaos operacyjny bywa większy niż w klasycznej wirtualizacji.

Ten problem ujawnia się w momencie, gdy aplikacja przestaje działać, a nikt nie potrafi odpowiedzieć na pytanie: gdzie ta aplikacja powinna się teraz uruchomić i kto za to odpowiada.

I wtedy problem techniczny bardzo szybko staje się problemem zarządczym.

Sieć: dlaczego architektura Spine-Leaf jest konieczna

W środowiskach zwirtualizowanych i klastrowych większość ruchu w sieci nie pochodzi już od użytkowników. To tzw. ruch wschód–zachód - komunikacja między serwerami, maszynami wirtualnymi, kontenerami i usługami wewnętrznymi.

Tradycyjne sieci firmowe były projektowane głównie pod ruch północ–południe (użytkownik ↔ serwer).
W momencie wdrożenia klastrów HA HCI lub Kubernetes ten model przestaje działać to pojawiają się opóźnienia, wąskie gardła i trudne do zdiagnozowania problemy z wydajnością.

Topologia Spine-Leaf to architektura sieciowa zaprojektowana właśnie pod takie środowiska.
Opiera się na dwóch warstwach przełączników:

• Leaf – do których podłączone są serwery i węzły klastra,
• Spine – zapewniających równorzędne, szybkie połączenia pomiędzy wszystkimi segmentami sieci.

Dzięki temu:

• każda komunikacja między serwerami ma stałą, niską latencję,

infrastruktura może być skalowana bez przebudowy całej sieci,

• ruch systemowy (między węzłami) jest logicznie oddzielony od ruchu użytkowników.

Ten problem najczęściej ujawnia się dopiero przy wdrażaniu klastrów HA, gdy teoretycznie poprawnie skonfigurowana infrastruktura zaczyna działać niestabilnie, a przyczyna leży nie w serwerach, lecz w architekturze sieci.

Ten temat szerzej opisujemy w osobnym materiale o tym, dlaczego kontenery bez warstwy orkiestracji i odpowiedniej architektury sieciowej zwiększają ryzyko operacyjne, zamiast je zmniejszać.

Faza 3: odporność i ciągłość działania (HA i DR)

Wysoka dostępność nie jest luksusem. Jest odpowiedzią na bardzo konkretne pytanie: czy firma może pozwolić sobie na przestój jednego serwera?

Jeśli odpowiedź brzmi „nie” to architektura musi to uwzględniać.

HA a DR: dwie różne odpowiedzialności

Wysoka dostępność (HA) i odtwarzanie po awarii (DR) często są wrzucane do jednego worka. W praktyce odpowiadają na zupełnie różne scenariusze.

HA zapewnia ciągłość działania w przypadku awarii pojedynczego elementu:

• serwera,
• węzła klastra,
• komponentu infrastruktury.

System nadal działa, użytkownik często nawet nie zauważa problemu.

DR odpowiada na sytuacje, których nie da się „przełączyć jednym kliknięciem”:

• utratę całej lokalizacji,
• poważne uszkodzenie danych,
• incydent bezpieczeństwa lub ransomware,
• błędną aktualizację, która rozjeżdża całą usługę.

Ten problem ujawnia się dokładnie w momencie, gdy backup istnieje, ale nie spełnia założonego RTO.

Backup ≠ Disaster Recovery

Backup to nie strategia ciągłości działania. To jeden z elementów tej strategii.

Zasada 3-2-1 jest absolutnym minimum technicznym. Ale bez regularnych testów odtwarzania pozostaje tylko założeniem, nie planem.

W praktyce po incydencie zawsze pada to samo pytanie: dlaczego nikt nie sprawdził wcześniej, czy da się to odtworzyć w wymaganym czasie?

W SparkSome zaczynamy zawsze od weryfikacji podstaw:

• czy istniejący backup da się faktycznie odtworzyć,
• ile realnie trwa przywrócenie systemów,
• i czy to, co zapisano w dokumentacji, zgadza się z rzeczywistością.

To właśnie ten moment najczęściej obnaża różnicę między założeniami projektowymi a faktyczną odpornością infrastruktury.

Faza 4: bezpieczeństwo jako architektura - Zero Trust

Nowoczesna infrastruktura IT nie może opierać się na założeniu, że „wewnątrz sieci jest bezpiecznie”.

To założenie przestało działać w momencie, gdy:

• użytkownicy pracują zdalnie,
• dane są przetwarzane w wielu lokalizacjach,
• a ataki nie zaczynają się „z zewnątrz”, tylko od przejęcia jednego konta lub jednego laptopa.

Model Zero Trust zakłada, że:

• nie ufamy urządzeniom ani użytkownikom z definicji,
• każda komunikacja musi zostać zweryfikowana,
• ruch poprzeczny w infrastrukturze jest świadomie ograniczany.

Ten problem ujawnia się w momencie, gdy po incydencie okazuje się, że atakujący mógł swobodnie poruszać się po całej sieci.

Mikrosegmentacja i SIEM

Mikrosegmentacja sprawia, że incydent na jednym urządzeniu — na przykład laptopie pracownika — nie rozlewa się automatycznie na całą infrastrukturę.

Zamiast jednej, płaskiej sieci powstają logiczne strefy:

• aplikacje komunikują się tylko tam, gdzie jest to konieczne,
• dostęp wynika z roli i kontekstu, a nie lokalizacji w sieci.

SIEM (Security Information and Event Management) odpowiada za drugi, równie krytyczny element: widoczność tego, co naprawdę dzieje się w systemach.

Pozwala wykrywać:

• nietypowe logowania,
• próby eskalacji uprawnień,
• podejrzany ruch wewnętrzny, który nie wygląda jak standardowa praca użytkownika.

Ten problem ujawnia się wtedy, gdy po incydencie nikt nie potrafi jednoznacznie odpowiedzieć na pytanie: co dokładnie się wydarzyło i jak długo to trwało?

Zero Trust w praktyce nie zaczyna się od narzędzi. Zaczyna się od architektury.

Dlatego w SparkSome projekt bezpieczeństwa zawsze łączymy z:

• architekturą sieci,
• zarządzaniem tożsamościami,
• logiką dostępu do systemów zanim pojawią się konkretne technologie i rozwiązania bezpieczeństwa.

Faza 5: operacje i moment odpowiedzialności

Każda awaria i każdy incydent bezpieczeństwa prowadzi do tego samego momentu.

Momentu, w którym Zarząd zadaje pytanie:

• kto odpowiada?
• kto przywraca system?
• kto decyduje o kolejności działań?
• kto podpisuje się pod raportem po incydencie?

Jeśli na te pytania nie ma jasnych odpowiedzi, to znaczy, że problem już istnieje tylko jeszcze się nie ujawnił.

Checklista decyzyjna SparkSome – test ryzyka

Sprawdź, czy dziś potrafisz jednoznacznie odpowiedzieć:

• Czy wiesz, ile danych możesz stracić (RPO)?
• Czy infrastruktura przetrwa awarię jednego serwera?
• Czy masz realny plan DR, a nie tylko backup?
• Czy sieć jest podzielona logicznie (Zero Trust)?
• Czy testowaliście odtwarzanie systemów w ostatnich 6 miesiącach?

Jeśli przy kilku punktach pojawia się wątpliwość to znaczy, że ryzyko już istnieje.

To dokładnie ten zestaw pytań, od którego zaczynamy rozmowy projektowe w SparkSome, zanim pojawi się jakakolwiek decyzja technologiczna.

Projektowanie infrastruktury IT w firmie — decyzja biznesowa, nie techniczna

Infrastrukturę IT można zaprojektować z wyprzedzeniem — stabilnie, bezpiecznie i w sposób przewidywalny kosztowo. Albo można pozwolić, żeby zaprojektował ją incydent, audyt albo realny przestój w biznesie.

W SparkSome zaczynamy od rozmowy projektowej i weryfikacji ryzyka, zanim odpowiedzialność za decyzje infrastrukturalne trafi na stół zarządu w trybie kryzysowym.
Nie od oferty. Od faktów, ryzyk i realnych konsekwencji.

Jeśli podczas lektury pojawiła się myśl: „to brzmi jak u nas” albo „musimy to sprawdzić” to dokładnie ten moment, w którym firmy zaczynają działać z wyprzedzeniem, a nie po fakcie.

Poniższe materiały rozwijają obszary, które najczęściej ujawniają się dopiero wtedy, gdy brak decyzji zaczyna kosztować czas, pieniądze albo zaufanie:

• Backup to nie Disaster Recovery — dlaczego odzyskiwanie danych kończy się zaskoczeniem
• Zero Trust w praktyce — dlaczego nieautoryzowane urządzenia w sieci firmowej to realne ryzyko (i problem zgodności z NIS2)
• Kubernetes w firmie — kiedy porządkuje środowisko, a kiedy je destabilizuje
• Testy odtwarzania systemów i dokumentacja techniczna — co wychodzi dopiero przy audycie lub incydencie

Jeśli chcesz sprawdzić, gdzie naprawdę jest dziś Twoja firma zacznijmy od rozmowy projektowej, zanim decyzję wymusi sytuacja kryzysowa.