Terraform i infrastruktura jako kod Warszawa

Skąd w warszawskich spółkach bierze się pytanie o ślad zmiany

Prawie nigdy nie zadaje go zespół techniczny. Zadaje je ktoś z zewnątrz: kontrahent przed podpisaniem umowy, dział zgodności spółki matki, ubezpieczyciel przy polisie od ryzyk cyfrowych albo audytor sprawdzający, jak firma panuje nad własnym środowiskiem. Wszyscy pytają o mniej więcej to samo, tylko innymi słowami.

Pytanie brzmi: skąd wiecie, co jest u Was skonfigurowane, kto to zmienił i czy da się to odtworzyć. Odpowiedź „mamy dokumentację” bywa przyjmowana dopóty, dopóki ktoś nie poprosi o pokazanie ostatniej aktualizacji tej dokumentacji. Odpowiedź „mamy dziennik zdarzeń u dostawcy” jest lepsza, ale niepełna, ponieważ dziennik mówi, które konto wykonało operację, a nie po co ją wykonano i kto się na nią zgodził.

W spółce, która obsługuje klientów wymagających takich odpowiedzi, to przestaje być kwestią porządku i zaczyna być warunkiem podpisania umowy. Wtedy zwykle dzwoni telefon.

Co ankieta pyta, a co środowisko musi umieć pokazać

Pytanie w ankiecie	Czym odpowiadamy	Czego kod nie załatwia
Czy zmiany w infrastrukturze są kontrolowane	historia repozytorium z autorem, opisem i zapisem przyjęcia	zmian wykonanych, zanim środowisko trafiło do kodu
Czy wnioskujący i zatwierdzający to różne osoby	wymóg przyjęcia zmiany przez drugą osobę, zapisany przy każdej pozycji	obsady ról, którą trzeba ustalić między firmami
Czy środowisko da się odtworzyć	uruchomienie opisu od zera na pustym koncie, sprawdzone przy odbiorze	danych i zawartości maszyn, do których służą kopie
Czy dostęp administracyjny jest ograniczony	nazwane konta, uprawnienia podnoszone na czas zadania, zapis użycia	dostępów wewnątrz aplikacji, nadawanych przez ich administratorów
Czy dane dostępowe są chronione	sekrety poza repozytorium, w menedżerze albo w Vault, z rotacją	haseł zapisanych w systemach, do których nie mamy wglądu
Czy istnieje plan powrotu po nieudanej zmianie	cofnięcie w repozytorium i ponowne uruchomienie potoku	odtworzenia danych, które ma osobną procedurę i osobny czas

Trzecia kolumna jest w tej tabeli najważniejsza. Ankieta bezpieczeństwa kusi, żeby zaznaczyć wszystko na tak, a potem raz na jakiś czas ktoś prosi o dowód. Wskazanie granicy przed podpisaniem jest tańsze niż tłumaczenie się z niej przy kontroli.

Jak rozdzielić wnioskowanie i zatwierdzanie w niewielkim zespole

To jest pytanie, które w warszawskich spółkach pada najczęściej, bo wymóg przychodzi z organizacji o kilkuset osobach, a spełnić ma go zespół, w którym infrastrukturą zajmuje się jedna osoba na część etatu.

Rozwiązanie jest prostsze, niż wygląda, o ile ktoś obsługuje środowisko z zewnątrz. Zmianę opisujemy my i przedstawiamy ją razem z planem, czyli listą konkretnych zasobów do dodania, zmiany i usunięcia. Wskazana osoba po Waszej stronie ją przyjmuje albo odrzuca, mając przed sobą konkret, a nie prośbę o zaufanie. Obie czynności zostają zapisane i to wystarcza, żeby role były faktycznie rozdzielone.

W drugą stronę działa to tak samo. Gdy zmianę proponuje Wasz zespół, przyjmuje ją nasz inżynier i patrzy przede wszystkim na to, czy plan nie usuwa czegoś przy okazji. Usunięcie bywa efektem ubocznym poprawki uznanej za drobną i jest najczęstszą przyczyną zdarzeń, które potem trzeba opisywać w raporcie.

Co robimy z dwoma środowiskami zastanymi po fuzji

Warszawa jest miejscem, w którym takie połączenia zdarzają się częściej niż gdziekolwiek indziej, a ich skutkiem jest zwykle firma z dwoma zestawami wszystkiego. Dwie subskrypcje, dwa katalogi kont, dwa sposoby nazywania tych samych rzeczy i dwie osoby przekonane, że ich wersja jest właściwa.

Nie zaczynamy od ujednolicania, tylko od opisu każdego środowiska osobno. Kod odzwierciedla wtedy stan faktyczny, a różnice przestają być kwestią pamięci i stają się listą, którą da się przeczytać. Dopiero z tej listy wybieramy wzorzec, pozycja po pozycji, i zwykle nie jest tak, że jedna strona wygrywa w całości.

Dochodzenie do wzorca rozkładamy na naturalne okazje: wymianę sprzętu, otwarcie nowego środowiska, przegląd uprawnień. Jednoczesna przebudowa obu stron w krótkim terminie jest kuszącą decyzją i najczęstszym powodem, dla którego takie porządki kończą się w połowie.

Na co idą te dwa dni pracy

Pierwszy dzień to wciągnięcie zasobów i doprowadzenie do stanu, w którym plan nie pokazuje żadnych różnic. Ten moment jest ważniejszy, niż wygląda: dopóki plan wskazuje rozbieżności, opis nie jest jeszcze źródłem prawdy, tylko propozycją. Przy okazji powstaje pełna lista zasobów, w tym takich, których nikt nie umie przypisać do żadnego projektu.

Drugi dzień to moduły na powtarzalne elementy, wspólny stan zamknięty blokadą, wyprowadzenie sekretów oraz podpięcie potoku wykonującego przyjęte zmiany. Na koniec przechodzimy z Waszą stroną przez jedną prawdziwą zmianę, od propozycji do wykonania, żeby osoba, która ma ją później zatwierdzać, zobaczyła całą drogę raz, zanim będzie musiała podjąć decyzję sama.

W kalendarzu zajmuje to zwykle dwa tygodnie, bo między krokami czekamy na potwierdzenia po Waszej stronie. Okno serwisowe ani przerwa w pracy biura nie są do tego potrzebne.

Kiedy odradzamy tę pracę

Gdy środowisko ma zniknąć w ciągu kilku miesięcy, bo trwa przenosiny gdzie indziej. Gdy nikt po Waszej stronie nie zamierza czytać opisu ani zatwierdzać zmian, a jednocześnie utrzymanie ma zostać wewnątrz firmy. Gdy pytanie o kontrolę zmian pada wprawdzie w ankiecie, ale środowisko składa się z jednej maszyny, której dotyka jedna osoba.

Odradzamy też dopisywanie tego do innego zlecenia jako pozycji dodatkowej. Opis wymaga własnych godzin i własnych prób, a robiony przy okazji rozjeżdża się z rzeczywistością w ciągu kilku tygodni.

Co zostaje u Was

Repozytorium, moduły, opis uruchomienia i procedura odtworzenia, wszystko od pierwszego dnia po Waszej stronie. Do tego lista dostępów awaryjnych z nazwiskami oraz zapis pierwszej przeprowadzonej zmiany, który zwykle wystarcza jako przykład przy odpowiadaniu na kolejną ankietę.

Bieżące prowadzenie zasobów opisuje administracja chmurą, subskrypcję Microsoftu Azure dla firm, a układ z częścią systemów w biurze albo w kolokacji chmura hybrydowa. Aplikacje uruchamiane na tak opisanych maszynach pakujemy wcześniej zgodnie z tym, co pokazujemy przy konteneryzacji Docker, a nowe środowisko warto opisać kodem od razu przy migracji do chmury.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026