Terraform i infrastruktura jako kod Kraków

Skąd bierze się standard, którego nikt u Was nie pisał

Krakowska spółka należąca do zagranicznej grupy dostaje w pewnym momencie dokument opisujący, jak ma wyglądać jej środowisko chmurowe. Wymienione są w nim dozwolone regiony, wymagane oznaczenia zasobów, zakazane typy usług, sposób szyfrowania i zasady nadawania uprawnień. Dokument liczy zwykle kilkadziesiąt stron, powstał w kraju właściciela i został napisany dla organizacji kilkukrotnie większej.

Problem nie polega na tym, że wymagania są nierozsądne. Zwykle są rozsądne. Polega na tym, że dokument nie ma żadnego związku z chwilą, w której ktoś zakłada zasób. Osoba uruchamiająca maszynę w środę po południu nie otwiera przy tym pliku PDF, tylko odtwarza z pamięci, jak robiła to poprzednio.

Efekt widać przy pierwszym przeglądzie z centrali i jest zawsze taki sam. Większość środowiska jest zgodna, kilkanaście zasobów nie, a nikt nie potrafi powiedzieć, kiedy i dlaczego powstało odstępstwo. Rozmowa schodzi wtedy z pytania o środowisko na pytanie o to, czy spółka w ogóle panuje nad własnym IT, a to jest znacznie gorsze pytanie.

Które wymagania da się zapisać jako regułę, a które nie

Wymaganie ze standardu	Postać reguły	Kiedy się uruchamia	Co, gdy nie da się jej spełnić
Zasoby wyłącznie w dozwolonych regionach	ograniczenie subskrypcji plus sprawdzenie w planie	przy każdej zmianie i raz na dobę	odstępstwo z terminem, przyjęte przez właściciela środowiska
Obowiązkowe oznaczenia kosztowe	walidacja w module, brak oznaczenia zatrzymuje zmianę	przy budowaniu planu	zasób po prostu nie powstaje, bez wyjątków
Zakaz publicznych adresów dla maszyn	reguła w kodzie i polityka po stronie dostawcy	przy każdej zmianie	wystawienie idzie przez wskazany punkt wejścia, nie przez maszynę
Szyfrowanie dysków i magazynu	ustawienie domyślne modułu	zawsze, bez możliwości pominięcia	to jedno z niewielu miejsc, gdzie nie zakładamy odstępstw
Wzorzec nazewnictwa zasobów	sprawdzenie nazwy w planie	przy tworzeniu zasobu	zasoby sprzed standardu na liście do zmiany przy okazji
Przegląd uprawnień co kwartał	nie da się zapisać jako reguła	czynność człowieka	zostaje w kalendarzu i w miesięcznym zestawieniu
Zatwierdzenie zmiany przez drugą osobę	wymóg w potoku, zmiana nie wchodzi sama	przy każdym wykonaniu	obsadę ról ustalamy między firmami przed startem

Dwa ostatnie wiersze pokazują granicę tej pracy. Reguła sprawdza stan zasobu, a nie zachowanie ludzi, więc wymagania dotyczące przeglądów, szkoleń i podejmowania decyzji zostają czynnościami wykonywanymi przez człowieka. Mówimy o tym na początku, bo obietnica zamknięcia całego standardu jednym wdrożeniem jest łatwa do złożenia i niemożliwa do dotrzymania.

Co się dzieje, gdy zmiana narusza regułę

Plan zatrzymuje się przed wykonaniem i wypisuje, którego punktu dotyczy naruszenie oraz jak wygląda zapis poprawny. Ten szczegół jest ważniejszy, niż się wydaje. Komunikat mówiący wyłącznie o odrzuceniu uczy zespół tego, żeby szukać obejścia. Komunikat pokazujący właściwą postać uczy zespół standardu, a przy okazji oszczędza pytanie skierowane do nas.

Dalej są dokładnie dwie drogi. Pierwsza to poprawienie zmiany, i tak kończy się zdecydowana większość zatrzymań. Druga to przyjęcie odstępstwa przez wskazaną osobę, z powodem i terminem wygaśnięcia.

Trzeciej drogi nie ma i to jest cała wartość takiego ustawienia. Reguła, którą da się cicho ominąć w pilnej sprawie, przestaje obowiązywać już przy drugim użyciu, a przy trzecim nikt nie pamięta, że kiedykolwiek istniała.

Jak prowadzimy rejestr odstępstw

Rejestr leży w repozytorium obok kodu, więc dopisanie do niego przechodzi tą samą drogą co zmiana środowiska: ktoś proponuje, ktoś przyjmuje, obie czynności zostają zapisane. Każda pozycja ma cztery rzeczy: czego dotyczy, dlaczego powstała, do kiedy obowiązuje i kto ją przyjął.

Termin jest tu elementem, który wykonuje pracę. Odstępstwo bez daty końca staje się po roku częścią środowiska i nikt już nie pamięta, że było wyjątkiem. Odstępstwo wygasające po kwartale wraca na biurko, a wtedy zwykle okazuje się, że powód zniknął, bo system, który go wymuszał, został w międzyczasie wymieniony.

Ten sam rejestr jest najkrótszą odpowiedzią na pytanie z centrali o zgodność ze standardem. Zamiast zapewnienia można pokazać listę wyjątków razem z ich terminami, a to zwykle robi lepsze wrażenie niż deklaracja pełnej zgodności, której nikt nie sprawdzał.

Dlaczego opis ma znaczenie, gdy środowisko obsługują dwa zespoły

W spółkach obsługujących procesy dla kilku rynków praca nad środowiskiem rzadko toczy się w jednych godzinach. Ktoś zaczyna rano w Krakowie, ktoś inny kończy późnym popołudniem w innej strefie, a między nimi nie ma spotkania, tylko wpis w narzędziu do zgłoszeń.

Środowisko klikane w konsoli nie znosi takiego układu. Osoba wchodząca do pracy widzi stan bieżący i nie widzi drogi, którą on powstał, więc pierwszą czynnością bywa pytanie zadane komuś, kto właśnie skończył dzień. Odpowiedź przychodzi nazajutrz, a sprawa czeka.

Przy opisie w kodzie ta sama osoba czyta historię zmian z ostatnich godzin i widzi, co, po co i przez kogo zostało zrobione. Wspólny stan z blokadą pilnuje przy okazji, żeby dwie osoby nie zaczęły równolegle tej samej zmiany, co w środowisku obsługiwanym z dwóch stron zdarza się częściej niż w zespole siedzącym w jednym pokoju.

Kiedy odradzamy tę pracę

Gdy standard jeszcze nie istnieje i trwają ustalenia, jak ma wyglądać. Wtedy lepiej poczekać, bo reguły napisane pod projekt dokumentu trzeba będzie przepisać. Gdy środowisko ma zostać zwinięte w ciągu kilku miesięcy, bo procesy wracają do innej lokalizacji. Gdy nikt po Waszej stronie nie będzie tego opisu czytał ani zatwierdzał zmian, a jednocześnie utrzymanie ma pozostać wewnątrz spółki.

Odradzamy też robienie tego przy okazji innego wdrożenia. Opis wymaga własnych godzin i własnych prób, a doklejony do większego projektu przestaje zgadzać się z rzeczywistością zanim ktokolwiek pierwszy raz do niego zajrzy.

Co po tej pracy zostaje w Waszym repozytorium

Kod odzwierciedlający stan środowiska, moduły z poprawnymi ustawieniami domyślnymi, zestaw reguł, rejestr odstępstw, opis uruchomienia oraz zapis pierwszej zmiany przeprowadzonej całą drogą, od propozycji do wykonania. Ten ostatni element bywa najbardziej przydatny, bo służy jako wzór, gdy kolejną zmianę zatwierdza już ktoś inny.

Bieżące prowadzenie zasobów opisuje administracja chmurą, subskrypcję opartą na kontach Microsoftu Azure dla firm, a podział wymuszony zapisem umownym chmura hybrydowa. Aplikacje uruchamiane na tak opisanych maszynach pakujemy zgodnie z tym, co pokazujemy przy konteneryzacji Docker, a nowe środowisko warto opisać kodem od pierwszego dnia, już przy migracji do chmury.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026