Terraform i infrastruktura jako kod Kielce

Dlaczego firma wykonawcza zakłada i gasi środowiska częściej niż inne

Większość firm buduje swoje IT raz i potem je rozwija. Firma prowadząca kontrakty pracuje inaczej: kilka razy w roku powstaje coś, co ma istnieć przez kilkanaście miesięcy i potem zniknąć. Obszar na dokumentację nowej inwestycji, komplet uprawnień, konta dla brygad podwykonawcy, znacznik kosztowy, czasem maszyna pod program używany tylko przy tym zadaniu.

Robione ręcznie, za każdym razem wygląda to trochę inaczej. Nie z niedbalstwa, tylko dlatego, że zakłada to inna osoba, w innym pośpiechu i po innej rozmowie. Po trzech latach firma ma kilkanaście środowisk zbudowanych według kilkunastu wariantów tego samego pomysłu, a jedynym miejscem, gdzie zapisano różnice między nimi, jest pamięć osoby, która akurat je zakładała.

Kod odwraca tę zależność. Zestaw dla nowego kontraktu jest jeden i ma parametry: numer inwestycji, daty, listę firm zewnętrznych, wielkość obszaru na dokumentację. Kolejna budowa to kilka linii wartości, a nie kilkadziesiąt czynności odtwarzanych z poprzedniej.

Co dokładnie zamyka w sobie moduł nowej inwestycji

Element	Skąd bierze wartość	Co się z nim dzieje przy odbiorze
Obszar na dokumentację	numer i nazwa kontraktu	przechodzi na warstwę archiwalną, zostaje
Uprawnienia zespołu firmy	role, nie osoby	wygasają wraz z zamknięciem kontraktu
Konta gościnne firm zewnętrznych	daty z umów podwykonawczych	gasną w dacie końcowej, bez czyjejś decyzji
Znacznik kosztowy	numer inwestycji	zostaje na zasobach archiwalnych, dla rozliczeń
Maszyna pod program branżowy	rozmiar z pomiaru	usuwana po planie, jeśli powstała tylko dla tego zadania
Reguła kopii zapasowej	klasa danych	zostaje, i to jest jedyny element bez daty końcowej
Miejsce na materiał wracający z placu	liczba osób w terenie	zamykane do odczytu i wciągane do archiwum

Ostatnia kolumna jest właściwym powodem, dla którego ta tabela w ogóle powstaje. Zakładanie środowiska umie zrobić każdy. Zamykanie go w sposób, po którym nie zostaje ani otwarty dostęp dla firmy, która zeszła z budowy, ani rachunek za zasoby zamkniętego kontraktu, wymaga listy i konsekwencji.

Dlaczego zamykanie jest trudniejszą połową tej pracy

Bo jest nieodwracalne, a wykonuje się je zawsze w tygodniu, w którym nikt nie ma na to czasu. Odbiór, rozliczenie, przekazanie dokumentacji, a gdzieś na końcu listy pytanie, czy folder z tej budowy jest jeszcze potrzebny. Odpowiedź brzmi wtedy zawsze tak samo: zostawmy na razie. Po dwóch latach takich odpowiedzi połowa środowiska należy do kontraktów dawno zamkniętych.

Kod nie rozwiązuje tego przez odwagę, tylko przez widoczność. Wykonanie zaczyna się od planu, który wypisuje każdy zasób przeznaczony do usunięcia, z nazwą i przypisaniem. Ten wykaz da się przeczytać na spotkaniu i podpisać, bo mówi wprost, co zniknie, a nie „usuniemy środowisko kontraktu”. Osoba rozliczająca budowę widzi w nim rzeczy, o których informatyk nie wiedziałby, że jeszcze mają znaczenie.

Druga rzecz to symetria. Skoro zakładanie i zamykanie opisuje ten sam zestaw plików, to zamknięcie nie może pominąć czegoś, co powstało przy starcie. Ręcznie pomija się prawie zawsze i prawie zawsze to samo: konto gościnne firmy, która schodziła z budowy w pośpiechu.

Co chronimy przed usunięciem, nawet gdy kod mówi inaczej

Trzy grupy zasobów dostają oznaczenie, przy którym próba usunięcia kończy się błędem, a nie skutkiem. Archiwum dokumentacji, bo pytania o wykonane roboty wracają po latach i wtedy nikogo nie interesuje, że kontrakt formalnie zamknięto. Kopie zapasowe wraz z ich magazynem, bo to jedyna rzecz, której skasowanie jest nie do naprawienia. Konta i grupy należące do firmy jako całości, bo nie mają nic wspólnego z pojedynczą budową, choć bywają w jej module używane.

Do tego dochodzi zasada, której trzymamy się niezależnie od kodu: stan środowiska sprzed każdej większej zmiany zapisujemy tego samego dnia, nie tydzień wcześniej. Plik stanu leży zdalnie, z blokadą i z historią, więc pomyłka jednej osoby nie zabiera pracy drugiej.

Kiedy odradzamy opisywanie środowiska kodem

Gdy firma ma jedną maszynę, jeden obszar na pliki i nie planuje drugiego. Wtedy nauka i utrzymanie kosztują więcej niż to, co upraszczają, i mówimy to przed wyceną, a nie po pierwszym miesiącu.

Odradzamy też robienie tego przy okazji innego projektu. Opisanie działającego środowiska wymaga własnego czasu, własnych testów i spokojnego tygodnia, a nie doklejenia do migracji, w której i tak zmienia się połowa firmy. Jeśli środowisko dopiero powstaje, sytuacja jest odwrotna i wtedy warto pisać je w plikach od pierwszego dnia, bo import później zawsze kosztuje więcej niż opis od razu.

Co przechodzi na Waszą stronę

Repozytorium z kodem, moduły, opis uruchomienia i spisana kolejność odtwarzania. Wszystko jest Wasze i nic z tego nie wymaga naszej obecności, żeby zadziałało, bo praca, którą da się wykonać wyłącznie z naszym udziałem, jest tak naprawdę uzależnieniem, a nie usługą. Zmiany możecie wykonywać sami albo zlecić je nam.

Przegląd planu przed zamknięciem kontraktu robimy natomiast przy jednym stole, a nie na czacie. Inżynier przychodzi z kieleckiego biura z wydrukiem wykazu, a Wy zapraszacie do niego kogoś z rozliczeń, i to spotkanie mieści się w zwykłym tygodniu, bo nie wymaga wyjazdu przez pół Polski. Stroną papierową, czyli umową i fakturami, zajmuje się biuro główne w Gorzowie Wielkopolskim.

Bieżące prowadzenie środowiska opisuje administracja chmurą, a jego budowa od zera zaczyna się przy migracji do chmury. Część lokalną i chmurową opisujemy jednym zestawem modułów, co wyjaśnia chmura hybrydowa. Środowisko oparte na kontach Microsoftu prowadzimy jako Azure dla firm, a aplikacje uruchamiane z gotowego obrazu opisuje konteneryzacja Docker. Stawkę za opiekę nad całym IT policzy kalkulator.

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