Terraform i infrastruktura jako kod Wrocław

Co odpowiedzieć w ankiecie o zarządzaniu zmianą

Wrocławskie firmy technologiczne poznają ten dokument wcześnie. Duży klient albo inwestor przysyła zestaw pytań przed podpisaniem umowy, a wśród nich takie: w jaki sposób zatwierdzacie zmiany w środowisku produkcyjnym, kto ma do niego dostęp administracyjny i jak odtworzycie konfigurację po awarii.

Odpowiedź, którą da się napisać przed wdrożeniem kodu, brzmi zwykle „mamy procedurę”. Jest szczera i jednocześnie bezwartościowa, bo procedura zapisana w dokumencie nie zostawia śladu w środowisku. Nikt nie potrafi pokazać, kto zmienił regułę dostępu trzy miesiące temu, a już na pewno nie potrafi pokazać, co dokładnie ta zmiana objęła.

Po opisaniu środowiska w kodzie odpowiedź jest inna, bo dowód powstaje sam przy każdej zmianie. Nie trzeba pisać raportu, wystarczy pokazać historię.

Dlaczego panel dostawcy nie jest dowodem

Panel pokazuje stan bieżący. Nie pokazuje, jak do niego doszło, kto podjął decyzję i co było wcześniej. Dziennik zdarzeń u dostawcy zapisuje operacje, ale w formie, której nikt nie czyta i która nie odróżnia zmiany przemyślanej od przypadkowego kliknięcia w niewłaściwym środowisku.

Repozytorium odwraca tę zależność. Zmiana zaczyna się od propozycji, przechodzi przez przegląd drugiej osoby, dostaje plan pokazujący dokładny zakres i dopiero wtedy jest wykonywana. Każdy z tych czterech kroków ma autora i datę. Środowisko jest wtedy skutkiem historii, a nie jej jedynym zapisem.

Pytanie z ankiety	Odpowiedź przed	Odpowiedź po
Kto zatwierdza zmiany na produkcji	osoba dyżurna, ustnie	druga osoba, w przeglądzie propozycji
Jak wygląda ślad zmiany	dziennik dostawcy, nieczytany	historia repozytorium i wynik planu
Kto ma stały dostęp administracyjny	kilka osób, bo tak wyszło	nikt na co dzień, dostęp awaryjny z zapisem
Ile trwa odtworzenie konfiguracji	nie wiadomo, nikt nie próbował	kilkanaście minut, sprawdzone
Czy test odpowiada produkcji	z grubsza	ten sam kod, różnice tylko w zmiennych
Gdzie trzymane są klucze i hasła	w kilku miejscach naraz	w menedżerze sekretów, poza kodem

Jak wygląda zmiana od zgłoszenia do wykonania

Prosto, bo im więcej kroków, tym większa pokusa, żeby je obejść. Osoba wprowadzająca zmianę opisuje ją w kodzie i zgłasza do przeglądu. Druga osoba patrzy na sam kod i na wygenerowany plan, czyli listę zasobów do dodania, zmiany i usunięcia. Po zatwierdzeniu potok wykonuje zmianę i zapisuje jej wynik.

Największą wartość ma tu trzeci krok. Plan pokazuje, że zmiana jednej linii skasuje przy okazji regułę dostępu, zanim ktokolwiek to zrobi. To jest ten moment, w którym da się jeszcze powiedzieć, że nie o to chodziło, i jedyna rzecz, której panel nie oferuje w ogóle.

Co wciągamy do kodu w pierwszej kolejności

Nie wszystko naraz i nie alfabetycznie. Zaczynamy od rzeczy, których utrata najbardziej boli i których odtworzenie z pamięci jest najtrudniejsze: sieć, reguły ruchu, uprawnienia i tożsamość usług. To one mają najwięcej drobnych ustawień powstałych przez dwa lata pojedynczych decyzji.

Potem maszyny i magazyny danych, na końcu elementy, które i tak powstają automatycznie przy wydaniu aplikacji. W praktyce po dwóch dniach pracy w repozytorium leży opis całego środowiska, a pierwsze uruchomienie planu ma pokazać brak zmian. Ten brak jest jedynym dowodem, że opis zgadza się z rzeczywistością, i dlatego to od niego zaczynamy, a nie od pierwszej poprawki.

Kto ma prawo uruchomić zmianę na produkcji

Po wdrożeniu nikt nie robi tego ze swojego komputera. Zmianę wykonuje potok, korzystając z własnej tożsamości, ograniczonej do tego, co faktycznie ma prawo zmienić. Ludzie mają dostęp do repozytorium i do podglądu, a konta z pełnymi uprawnieniami zostają jako droga awaryjna, z rejestrowaniem każdego użycia.

W rosnącym zespole ma to jeszcze jeden skutek. Nowa osoba może zaproponować zmianę pierwszego dnia, bez czekania na nadanie uprawnień produkcyjnych, bo jej propozycja i tak przechodzi przez przegląd. Rozdzielenie obowiązków przestaje być hamulcem i staje się sposobem pracy.

Komu ta praca się nie opłaci

Firmie z jedną maszyną, która nie planuje drugiej, i zespołowi, w którym nikt nie będzie czytał kodu opisującego środowisko. Koszt nauki przewyższy wtedy zysk, a repozytorium stanie się kolejną rzeczą do utrzymania.

Nie robimy też tego przy okazji innego projektu, bo import i sprawdzenie zgodności wymagają własnego czasu i własnej uwagi. Jeśli środowisko dopiero powstaje, warto zacząć od migracji do chmury i opisać je kodem od pierwszego dnia. Bieżące prowadzenie znajdziecie przy administracji chmurą, a układ z częścią sprzętu w biurze przy chmurze hybrydowej.

Treść sprawdzona i zaktualizowana: 31 lipca 2026