Terraform i infrastruktura jako kod Białystok

Dlaczego opis w plikach waży więcej tam, gdzie nikt nie podjedzie

Firma, do której dostawca IT ma dwadzieścia minut drogi, może sobie pozwolić na środowisko trzymające się na czyjejś pamięci. Kosztuje to dzień pracy przy awarii i zwykle nikt tego dnia nie liczy. Firma z Białegostoku obsługiwana z Warszawy płaci za to samo dwa razy: raz czasem odtwarzania, drugi raz czasem dojazdu osoby, która wie, jak było skonfigurowane.

Kod usuwa drugi z tych składników w całości. Skoro stan środowiska wynika z plików, odtworzenie może wykonać ktoś, kogo nie ma na miejscu, i ktoś, kto tego środowiska nie budował. Przy obsłudze zdalnej to nie jest wygoda, tylko warunek, żeby cała ta konstrukcja miała sens.

Jest jeszcze trzeci powód, mniej techniczny. W podlaskich firmach, z którymi rozmawiamy, środowisko powstawało zwykle rękami kilku osób z regionu, przez kilka lat, bez jednej dokumentacji. Import do kodu jest wtedy pierwszym momentem, w którym ktokolwiek widzi całość naraz.

Co dokładnie opisujemy, gdy środowisko stoi po drugiej stronie kraju

Element	Czy trafia do kodu	Dlaczego akurat tak
Sieci, reguły ruchu, adresacja	tak	odtworzenie z pamięci trwa najdłużej i najczęściej się myli
Maszyny wirtualne i dyski	tak	rozmiar i konfiguracja mają wynikać z pliku, nie z decyzji sprzed roku
Uprawnienia i role	tak	to najczęstsze źródło różnic między środowiskiem próbnym a produkcją
Zadania kopii zapasowych	tak	kopia skonfigurowana ręcznie potrafi zniknąć razem z zasobem
Sekrety i hasła	nie, tylko odwołanie	w kodzie zostaje wskazanie miejsca, wartość leży w menedżerze sekretów
Dane w systemach	nie	kod odtwarza środowisko, dane wracają z kopii
Sterowniki i urządzenia w hali	nie	mają własny sposób konfiguracji i własną dokumentację

Wiersz czwarty bywa pomijany, a jest jedną z ważniejszych pozycji. Środowisko odtworzone bez zadań kopii wygląda na sprawne i przez kilka tygodni nikt nie zauważy, że nic się nie zabezpiecza.

Co się dzieje, zanim wykonamy zmianę w środowisku, do którego nikt nie dojedzie

Plan, przegląd, zatwierdzenie, wykonanie przez potok. Ta kolejność brzmi jak formalność do momentu, w którym zmiana w regułach sieci odetnie administratora od środowiska, a najbliższa osoba mogąca cokolwiek zrobić fizycznie jest kilkaset kilometrów dalej.

Plan pokazuje przed wykonaniem, co zostanie dodane, zmienione i usunięte. Najważniejsze jest w nim słowo usunięte, ponieważ Terraform potrafi zaproponować odtworzenie zasobu od zera tam, gdzie człowiek spodziewał się drobnej poprawki. Wyłapanie tego w planie kosztuje minutę, wyłapanie po wykonaniu kosztuje dzień.

Zmiany wykonuje potok, a nie osoba z własnego komputera. Dzięki temu wiadomo, kto zaproponował, kto zaakceptował i co dokładnie się wydarzyło, a przy pracy na odległość jest to jedyny dowód, jakim dysponujecie.

Ile trwa odtworzenie i skąd to wiadomo

Z próby wykonanej przy odbiorze. Stawiamy środowisko z kodu obok istniejącego, mierzymy czas i zapisujemy go razem z kolejnością uruchamiania poszczególnych części. Wynik jest liczbą, którą możecie podać kontrahentowi albo ubezpieczycielowi, jeśli zapyta, i której nie trzeba bronić.

Sama liczba to nie wszystko. Próba pokazuje zwykle dwie albo trzy rzeczy skonfigurowane kiedyś ręcznie i nieujęte nigdzie, bo działają od lat i nikt o nich nie pamięta. Wyjście na jaw takiego elementu przy próbie jest tanie. Wyjście na jaw przy awarii kosztuje dokładnie tyle, ile trwa ustalenie, czego brakuje.

Próbę powtarzamy po większych zmianach, bo czas zmierzony rok temu opisuje środowisko, którego już nie ma.

Komu odradzamy tę pracę

Firmie z jedną maszyną, która nie planuje drugiej, bo koszt nauki przewyższy zysk i lepiej wydać te pieniądze na kopie. Firmie, u której środowisko ma się zmienić w ciągu najbliższych miesięcy, ponieważ opisywanie stanu przejściowego jest pracą do wyrzucenia. Zespołowi, który nie chce zmienić sposobu pracy: Terraform prowadzony obok ręcznych zmian w panelu jest gorszy niż jego brak, bo daje fałszywe poczucie, że opis jest aktualny.

Mówimy to również wtedy, gdy zapytanie brzmiało wprost o infrastrukturę jako kod. Jeśli po tej rozmowie decyzja zostaje, robimy pracę w całości i z próbą odtworzenia.

Co zostaje u Was

Repozytorium z kodem, moduły, opis uruchomienia, zmierzony czas odtworzenia i procedura na dzień awarii. Wszystko jest Wasze, więc dalsze zmiany możecie wykonywać sami albo zlecić komukolwiek, bez rozmowy o tym, kto wie więcej.

Wyjazdy na Podlasie umawiamy z wyprzedzeniem, a jedzie do Was inżynier z warszawskiego biura przy Jerzego Waldorffa 24. Stroną umowy pozostaje podmiot z biurem głównym w Gorzowie Wielkopolskim przy Baczyńskiego 24. Bieżące prowadzenie środowiska opisuje administracja chmurą, układ z częścią sprzętu zostawioną w hali chmura hybrydowa, a programy pakowane tak, żeby dało się je cofnąć bez dojazdu, konteneryzacja Docker.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026