Terraform i infrastruktura jako kod Toruń

Dlaczego coś stawianego raz w roku najtrudniej odtworzyć

Środowisko, które zmienia się co tydzień, zna kilka osób i nikt nie musi go pamiętać, bo pamięć podtrzymuje codzienna praca. Środowisko, którego się nie rusza, też nie sprawia kłopotu, dopóki nie trzeba go odbudować. Najgorszy przypadek leży pośrodku i w toruńskich zakładach spotykamy go regularnie: coś, co powstaje raz w roku, przed przyjęciami surowca, pracuje kilkanaście tygodni i zostaje wygaszone do następnego sezonu.

Dwanaście miesięcy to odstęp dokładnie taki, żeby zapomnieć wszystko poza tym, że w zeszłym roku działało. Nie pamięta się rozmiaru maszyny, kolejności uruchamiania, adresu, pod którym stała usługa raportowa, ani powodu, dla którego jedno ustawienie odbiega od reszty. Zostaje kilka notatek i osoba, która wtedy to robiła, o ile nadal jest w firmie.

Odbudowa zaczyna się więc od pracy rozpoznawczej wykonanej rok wcześniej i za każdym razem od nowa. Środowisko wychodzi z niej podobne, ale nie takie samo, a różnice wychodzą przy pierwszym większym obciążeniu, czyli w tygodniu, w którym nikt nie ma na nie czasu.

Co wraca na sezon, a co pracuje przez dwanaście miesięcy

Element	Kiedy istnieje	Skąd bierze kształt	Co się dzieje bez opisu
Maszyna z raportowaniem kampanii	podnoszona przed przyjęciami	moduł, parametr rozmiaru	dobierana na oko, zwykle inaczej niż rok wcześniej
Środowisko próbne pod zmiany w programie	kilka tygodni wiosną	ten sam moduł, mniejsze parametry	stawiane ręcznie i różniące się od produkcji
Sieć i reguły brzegowe	cały rok	opis wspólny dla całego środowiska	poprawiane doraźnie, bez śladu kto i po co
Konta i role	cały rok	opis wspólny	uprawnienia kopiowane od poprzedniej osoby
Magazyn archiwum jakościowego	cały rok, rośnie po sezonie	opis wspólny, warstwy z parametrem	warstwa ustawiona raz i nigdy nieprzeliczona
Zasoby dodane w trakcie kampanii	od zdarzenia do końca sezonu	dopisywane do plików po fakcie	zostają na kolejny rok i płacicie za nie w lutym

Ostatni wiersz opisuje zjawisko, które napędza rachunek u dostawcy bardziej niż jakiekolwiek świadome decyzje. W środku sezonu coś powstaje, bo musi powstać natychmiast, a po sezonie nikt tego nie zdejmuje, ponieważ nie ma listy rzeczy dodanych. Gdy środowisko jest opisane, dopisanie zasobu do plików jest częścią zadania, a nie osobnym obowiązkiem, o którym trzeba pamiętać.

Skąd pewność, że tegoroczne środowisko jest takie samo jak zeszłoroczne

Z tego, że powstaje z tych samych plików, a wszystkie różnice wobec poprzedniego sezonu widać w historii zmian, z datą i z nazwiskiem osoby, która je wprowadziła.

W zakładzie przetwórczym ma to skutek wykraczający poza informatykę. Zestawienia z dwóch sezonów porównuje się co roku i za każdym razem ktoś zadaje pytanie, dlaczego coś przebiega inaczej. Odpowiedzi szuka się w surowcu, w pogodzie i w organizacji pracy, czyli tam, gdzie zwykle rzeczywiście leży. Infrastruktura powinna być tą częścią równania, którą da się wykluczyć w minutę, a nie kolejnym podejrzanym.

Bez opisu jej wykluczyć się nie da, bo nikt nie potrafi powiedzieć, czy maszyna liczyła w tym roku na tych samych zasobach co poprzednio. Z opisem to pytanie zamienia się w zajrzenie do historii zmian.

Jak wchodzimy do środowiska, którego nie wolno zatrzymać

Zaczynamy od wciągnięcia do kodu tego, co pracuje, w stanie zastanym i bez żadnego porządkowania po drodze. Nic się przy tym nie wyłącza i nie restartuje, więc pracę można prowadzić także wtedy, gdy hala chodzi.

Dopiero z gotowego opisu powstaje lista rzeczy, które warto zmienić. To ważna kolejność, bo lista sporządzona przed opisaniem opiera się na czyjejś pamięci i zwykle pomija połowę środowiska. Ujednolicamy wyłącznie to, co różni się przypadkiem, a nie z potrzeby: inna wielkość magazynu czy inna przepustowość łącza zostają parametrem.

Pierwszą realną zmianę wykonaną tą drogą planujemy poza kampanią i przechodzimy przez nią razem z osobą, która ma zatwierdzać kolejne. Chodzi o to, żeby zobaczyła całą drogę od propozycji do wykonania raz, zanim zdecyduje sama, i to w miesiącu, w którym nic nie stoi na rampie.

Kiedy mówimy, że ta praca się nie zwróci

Gdy firma ma jedną maszynę, nie podnosi niczego sezonowo i nie planuje zmiany, bo wtedy powtarzalność, czyli cała przewaga tego podejścia, nie ma zastosowania. Gdy całe środowisko i tak ma za kilka miesięcy przestać istnieć, bo trwa przeprowadzka do innego dostawcy. Gdy nikt po Waszej stronie nie zamierza czytać planu ani zatwierdzać zmian, a utrzymanie ma jednocześnie zostać w firmie.

Nie dopisujemy tego również jako pozycji dodatkowej do innego zlecenia. Opis powstający między innymi zadaniami przestaje zgadzać się ze stanem faktycznym po kilku tygodniach, a wtedy płacicie za pliki, którym nikt już nie ufa na tyle, żeby coś z nich uruchomić.

Co zostaje w Waszym repozytorium

Opis każdego zasobu, moduł części kampanijnej, procedura podniesienia środowiska od zera oraz procedura zdjęcia go po sezonie. Do tego lista dostępów awaryjnych z nazwiskami i zapis pierwszej zmiany przeprowadzonej tą drogą, od propozycji do wykonania.

Wszystko należy do Was od pierwszego dnia, więc dalsze zmiany możecie prowadzić sami albo zlecać nam. Przeglądy planów robimy zdalnie, a rozmowy przed sezonem w naszym biurze przy Grudziądzkiej 136 albo u Was, bo termin podniesienia środowiska ustala się razem z osobą odpowiadającą za produkcję.

Bieżące prowadzenie zasobów opisuje administracja chmurą, dzierżawę Microsoftu Azure dla firm, a układ z minimum sprzętu przy hali chmura hybrydowa. Programy uruchamiane na tak opisanych maszynach pakujemy wcześniej zgodnie z tym, co robimy przy konteneryzacji Docker, a nowe środowisko warto opisać plikami już w trakcie migracji do chmury.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026