Terraform i infrastruktura jako kod Bydgoszcz

Trzy sposoby na to, żeby środowisko dało się odtworzyć

Każda firma ma jeden z nich, choć rzadko nazywa go wprost. Pierwszym jest pamięć konkretnej osoby, zwykle tej, która środowisko zakładała. Drugim jest dokument: opis powykonawczy od wdrożeniowca, schemat narysowany przy okazji audytu, zestaw zrzutów ekranu w wewnętrznym katalogu. Trzecim są pliki, które nie tylko opisują stan, ale potrafią go odtworzyć.

Wybór między nimi nie jest wyborem między nowoczesnością a zacofaniem. Jest wyborem między trzema rachunkami, z których dwa pierwsze wystawiają się dopiero w dniu, w którym coś przestaje działać.

Sposób	Ile kosztuje utrzymanie	Stan po roku	Co się dzieje przy odejściu autora
Pamięć jednej osoby	nic widocznego w budżecie	zależny od tego, ile ta osoba pamięta	zostaje lista zasobów bez wyjaśnienia
Dokument opisowy	czas na aktualizację po każdej zmianie	rozbieżny, bo nikt tego czasu nie ma	zostaje opis, którego nikt nie potrafi sprawdzić
Opis w plikach	mieści się w wykonywaniu zmian	zgodny, o ile zmiany idą tą drogą	zostaje środowisko, które ktoś inny uruchomi
Pamięć plus dokument	podwójna praca, zwykle porzucana	dwa źródła mówiące co innego	spór o to, które z nich jest aktualne

Czwarty wiersz nie jest osobnym sposobem, tylko stanem, w którym zastajemy najwięcej firm. Dokument istnieje, jest nieaktualny, wszyscy o tym wiedzą i dlatego przy każdej wątpliwości i tak dzwoni się do jednej osoby.

Dlaczego dokument przegrywa z plikiem, który się wykonuje

Powód jest jeden i nie ma nic wspólnego z technologią. Dokument i rzeczywistość są dwiema osobnymi rzeczami, więc mogą się rozejść, a rozejście niczego nie psuje i przez to nikt go nie zauważa. Pliki wykonywalne rozejść się nie mogą, bo próba ich uruchomienia natychmiast pokazuje różnicę.

W praktyce wygląda to tak, że przed każdą zmianą powstaje plan: lista tego, co zostanie dodane, zmienione i usunięte, z nazwami konkretnych zasobów. Ten plan czyta osoba odpowiedzialna po Waszej stronie i dopiero jej zgoda uruchamia wykonanie. Jest to jednocześnie kontrola i dokumentacja, bo zapis pozostaje w historii razem z autorem, datą i powodem.

W zakładzie, w którym każda maszyna ma dokumentację techniczną, a każda zmiana w procesie ma swój zapis, to rozróżnienie zwykle nie wymaga tłumaczenia. Trudność polega tylko na tym, że w IT ten sam rygor jakoś nigdy się nie pojawił.

Od czego zaczynamy w środowisku składanym przez kilka firm

Od wciągnięcia do kodu tego, co już pracuje, i doprowadzenia do stanu, w którym plan nie pokazuje żadnej różnicy. Ten moment jest ważniejszy, niż wygląda: dopóki plan wskazuje rozbieżności, opis jest propozycją, a nie źródłem prawdy.

Wychodzi z tego również spis wszystkiego, co w środowisku pracuje, łącznie z rzeczami, dla których nikt nie potrafi wskazać powodu istnienia. Te ostatnie zbieramy osobno i przechodzimy przez nie razem z Wami. Część znajduje właściciela od razu, część okazuje się pozostałością po wdrożeniach zamkniętych lata temu. Tych drugich nie kasujemy z marszu: wyłączamy je na ustalony okres i usuwamy dopiero wtedy, gdy nikt się nie zgłosi.

Potem powtarzalne elementy zamykamy w modułach, stan trafia do zabezpieczonego magazynu z blokadą, hasła wychodzą do menedżera sekretów, a wykonywanie zmian przejmuje potok. Konsola dostawcy zostaje otwarta dla nazwanych osób jako droga awaryjna i każde jej użycie zostawia ślad.

Czego ten opis nie odtworzy

Danych i zawartości maszyn. Terraform odtwarza kształt środowiska: sieci, maszyny, uprawnienia, reguły ruchu i magazyny. Nie odtwarza tego, co w tych magazynach leży, i mówimy to na pierwszym spotkaniu, bo pomylenie jednego z drugim jest najkosztowniejszym możliwym nieporozumieniem w tej rozmowie.

Za zawartość odpowiadają kopie zapasowe i ich comiesięczne próbne odtwarzanie, prowadzone osobno. Dwie procedury zamiast jednej wyglądają na komplikację, dopóki nie trzeba ich użyć. Wtedy okazuje się, że pierwsza zajmuje kilkanaście minut, a druga tyle, ile trwa przesłanie danych, i że wykonanie ich w złej kolejności potrafi zniszczyć wynik obu.

Kiedy odradzamy tę pracę

Gdy środowisko ma zniknąć w ciągu kilku miesięcy, bo trwają przenosiny gdzie indziej. Gdy składa się z jednej maszyny, której dotyka jedna osoba, i nic tego nie zmieni. Gdy nikt po Waszej stronie nie zamierza czytać planu ani zatwierdzać zmian, a utrzymanie ma jednocześnie zostać wewnątrz firmy.

Nie zgadzamy się także na doklejenie tej pracy do innego projektu jako dodatkowej pozycji na fakturze. Wymaga własnych godzin i własnych prób, a wykonana przy okazji rozjeżdża się ze stanem faktycznym w kilka tygodni, czyli wraca do punktu wyjścia, tylko za Wasze pieniądze.

Co zabieracie ze sobą

Repozytorium, moduły, opis uruchomienia i procedurę odtworzenia środowiska od zera, wszystko od pierwszego dnia po Waszej stronie. Do tego listę dostępów awaryjnych z nazwiskami oraz zapis pierwszej przeprowadzonej zmiany, od propozycji do wykonania, przez którą przechodzimy razem z osobą mającą później zatwierdzać kolejne.

Rozmowy o tym prowadzimy zwykle w Waszym zakładzie albo w naszym biurze przy Orlej 66, bo przejście przez plan raz na kwartał idzie szybciej przy jednym stole niż wymianą wiadomości.

Bieżące prowadzenie zasobów opisuje administracja chmurą, subskrypcję Microsoftu Azure dla firm, a układ z częścią maszyn przy hali chmura hybrydowa. Program własnej roboty zamykamy w obrazie, zanim trafi na opisaną w ten sposób maszynę, co pokazujemy przy konteneryzacji Docker. Środowisko powstające od nowa warto opisać plikami już w trakcie migracji do chmury.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026