Terraform i infrastruktura jako kod Rzeszów

Dlaczego jeden zakład prowadzi kilka osobnych środowisk naraz

Poddostawca z Podkarpacia rzadko pracuje dla jednego klienta. Zwykle prowadzi w tym samym czasie kilka programów dla różnych odbiorców, a każdy z nich przychodzi z własnym kompletem wymagań co do tego, jak ma być traktowany powierzony materiał. Część tych wymagań dotyczy hali i magazynu, a część dotyczy miejsca, w którym leżą dane.

Wymaganie brzmi zwykle prosto i jest trudne dokładnie z tego powodu. Materiał jednego odbiorcy nie ma dzielić przestrzeni ani dostępu z materiałem innego, a firma ma umieć to pokazać. Odpowiedź w postaci osobnego folderu z ograniczonymi prawami przekonuje na pierwszym spotkaniu i przestaje przekonywać przy pierwszym pytaniu o to, kto nadał te prawa i kiedy.

Dlatego przy takim środowisku podział przestaje być kwestią porządku, a staje się częścią konstrukcji. Osobne zasoby, osobne sieci, osobne role i przypisania, a nad tym opis, z którego widać, że tak właśnie jest zbudowane. Ten opis daje się utrzymać tylko wtedy, gdy jest plikiem, a nie dokumentem aktualizowanym przy okazji.

Co dokładnie zamyka w sobie strefa jednego odbiorcy

Element strefy	Co obejmuje	Co się dzieje przy zamknięciu programu
Sieć i jej reguły	wydzielony obszar bez połączenia z innymi strefami	znika razem ze strefą
Przestrzeń na materiał powierzony	katalogi z danymi wejściowymi odbiorcy	kasowana w terminie z umowy, z zapisem
Role i przypisania	osoby dopuszczone do tego programu	wygasają w dniu zamknięcia
Maszyny robocze	zasoby liczące i pomocnicze	usuwane po zatwierdzeniu planu
Oznaczenia kosztowe	numer programu w każdej nazwie	zostaje w historii rachunków
Kopie i archiwum	egzemplarz z ustalonym okresem przechowywania	zostaje, ma blokadę usunięcia

Ostatni wiersz jest jedynym, który przeżywa zamknięcie strefy, i jedynym, przy którym kod nie decyduje. Blokada usunięcia stoi wyżej niż plik, bo polecenie wydane w pośpiechu nie ma prawa zabrać archiwum, do którego firma ma wracać przez lata.

Trzeci wiersz bywa źródłem nieporozumienia. Wygaśnięcie ról nie zamyka sprawy osób, które w trakcie programu miały dostęp, i dlatego historia przypisań zostaje. Odbiorca pyta zwykle o okres, a nie o stan na dziś.

Jak pokazać, że zmiana nie połączyła dwóch stref

Każda zmiana zaczyna się od planu, czyli od listy zasobów, które powstaną, zmienią się i znikną. Ta lista powstaje przed wykonaniem czegokolwiek, jest czytelna dla osoby nietechnicznej i zostaje w historii razem z nazwiskiem tego, kto ją zatwierdził.

W środowisku podzielonym na strefy plan pełni jeszcze jedną rolę. Widać z niego, czy zmiana dotyka tylko jednej strefy, czy sięga zasobu wspólnego, a to jest dokładnie to pytanie, które przy podziale ma znaczenie. Reguła jest prosta: zmiana obejmująca więcej niż jedną strefę wymaga osobnej decyzji, bo w takim środowisku niczego się tak nie robi przypadkiem.

Do tego dochodzi porównanie kodu ze stanem faktycznym, wykonywane regularnie. Wychwytuje ono zmiany zrobione ręcznie w konsoli, a przy podziale na strefy jest jedynym sposobem, żeby dowiedzieć się o furtce otwartej między nimi przez kogoś, kto naprawiał usterkę wieczorem.

Co się dzieje, gdy program produkcyjny dobiega końca

Zamykanie jest w tej pracy trudniejszą połową i najczęściej pomijaną. Zasoby postawione na potrzeby jednego odbiorcy zostają zwykle włączone długo po wydaniu ostatniej partii, ponieważ nikt nie ma pewności, czy jeszcze się nie przydadzą, a skasowanie czegoś, czego nie da się odtworzyć, jest decyzją ryzykowną.

Opis w plikach zdejmuje to ryzyko z osoby, która wykonuje polecenie. Skoro strefę da się postawić od nowa z tego samego kodu, jej wygaszenie przestaje być krokiem bez powrotu. Plan usunięcia pokazuje wcześniej pełną listę, więc zamiast rozmowy o odwadze jest rozmowa o konkretnych pozycjach.

Po wykonaniu zostaje zapis: data, zakres, osoba oraz potwierdzenie, co zostało zachowane i na jak długo. Ten dokument bywa potem częścią odpowiedzi dla odbiorcy, który pyta, co stało się z jego materiałem po zakończeniu współpracy.

Komu w takim zakładzie mówimy, że to się nie zwróci

Firmie, która ma jedno środowisko, jednego odbiorcę i nie zakłada nowych zasobów przez całe kwartały. Firmie, w której cała informatyka to serwer plików i poczta, bo tam opisywanie kodem dokłada narzędzie bez żadnej pracy do zaoszczędzenia. Zakładowi, który dopiero porządkuje podstawy, bo najpierw trzeba wiedzieć, co ma stać, a dopiero potem opisywać jak.

Mówimy to przed wyceną. Ta praca zwraca się w środowiskach, które się zmieniają, i nie zwraca się w tych, które od trzech lat wyglądają tak samo, choćby brzmiała nowocześnie.

Co zabieracie do własnego repozytorium

Pliki opisujące środowisko, moduł do powielenia przy kolejnym programie, opis sposobu przechowywania stanu, listę zasobów objętych blokadą usunięcia oraz krótką instrukcję uruchomienia planu. Repozytorium należy do Was od pierwszego dnia i nie jest kopią naszego, tylko jedynym egzemplarzem.

Nie bierzemy na siebie zmian w programach produkcyjnych ani konfiguracji maszyn, bo należą do ich producentów. Nie odtworzymy też kodem sprzętu stojącego w Waszej hali i nie udajemy, że jest inaczej.

W Rzeszowie nie mamy biura. Pracę prowadzimy przez sieć, wyjazdy umawiamy z krakowskiego biura przy Reducie 26a, a umowę i faktury prowadzi biuro główne w Gorzowie Wielkopolskim przy Baczyńskiego 24.

Bieżące prowadzenie środowiska opisuje administracja chmurą, część zostającą przy hali chmura hybrydowa, a środowisko na kontach Microsoftu Azure dla firm. Przeniesienie biura prowadzimy jako migrację do chmury, a własne programy zamykamy w obrazie przy konteneryzacji Docker. Koszt stałej opieki nad IT pokaże kalkulator.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026