Terraform i infrastruktura jako kod Białystok

Dlaczego opis w plikach waży więcej niż pamięć jednej osoby

Środowisko trzymające się na tym, co ktoś pamięta, działa poprawnie do dnia awarii i do dnia, w którym ta osoba zmienia pracę. Oba te dni przychodzą bez zapowiedzi, a rachunek za nie wystawia się w godzinach przestoju, więc nikt go wcześniej nie liczy.

Kod usuwa z tego rachunku najdroższą pozycję, czyli ustalanie, jak było. Skoro stan środowiska wynika z plików, odtworzenie może wykonać ktoś, kto tego środowiska nie budował, i wykona je tak samo za rok. Zapis w repozytorium jest przy tym jedyną formą wiedzy, która nie odchodzi razem z człowiekiem.

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, i zwykle to spotkanie robimy u nas w biurze, przy jednym ekranie, bo pierwsze pytania padają wtedy właśnie tam.

Co dokładnie opisujemy, a co zostaje poza kodem

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 produkcyjnym

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 maszyna, do której trzeba wtedy wejść, nie ma żadnego przycisku po naszej stronie.

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 audycie albo przy sporze o to, po czym środowisko przestało działać, jest to jedyny dowód, jakim ktokolwiek dysponuje.

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.

Przekazanie repozytorium i przejście przez procedurę na dzień awarii robimy przy ludziach, którzy będą z niej korzystać, u Was albo w naszym białostockim biurze. Dopóki prowadzimy środowisko, próbę odtworzenia powtarzamy po większych zmianach i pokazujemy Wam wynik. 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ę cofnąć wydanie jednym poleceniem, konteneryzacja Docker.

Treść sprawdzona i zaktualizowana: 7 września 2026