Terraform i infrastruktura jako kod Lublin

Dlaczego pytanie o czas powrotu do pracy przychodzi dziś od zleceniodawcy

Kilka lat temu przewoźnik odpowiadał na pytania o ubezpieczenie, licencje i flotę. Dziś do tego zestawu doszło pytanie, którego wcześniej nikt nie zadawał. Co się stanie z Waszymi zleceniami, jeśli w poniedziałek rano nie uruchomi się system, i w ile godzin wrócicie do pracy.

Pytanie przychodzi od dużych odbiorców, którzy sami muszą wykazać, że ich łańcuch dostaw ma odporność, a przewoźnik jest w tym łańcuchu ogniwem. Ma termin, ma konsekwencję handlową i nie da się go przeczekać.

Kłopot w tym, że typowa odpowiedź jest szczera i bezużyteczna. Brzmi mniej więcej jeden dzień, może dwa, zależy co się zepsuje. Nikt nie kłamie, tylko nikt nigdy tego nie sprawdził, bo sprawdzenie wymagałoby odbudowania środowiska, a odbudowanie środowiska bez opisu jest pracą na kilka dni i nikt nie zrobi jej dla próby.

Opisanie środowiska w plikach odwraca tę zależność. Odbudowa staje się czynnością na tyle tanią, że da się ją wykonać ćwiczebnie, a skoro da się ją wykonać ćwiczebnie, to czas przestaje być szacunkiem.

W jakiej kolejności ma wstawać środowisko firmy transportowej

Kolejność	Co wraca	Dlaczego akurat wtedy	Co się dzieje, gdy tego brakuje
1	tożsamość i uprawnienia	bez logowania nie działa nic innego	ludzie siedzą przy sprawnych komputerach i nie mogą wejść
2	zlecenia i awizacje	tym firma zarabia w pierwszej godzinie	samochód jedzie bez potwierdzonego okna u odbiorcy
3	poczta i dokumenty przewozowe	kontrahenci piszą dalej, niezależnie od Waszej awarii	zamówienia wpadają w pustkę i nikt o tym nie wie
4	wymiany danych z kontrahentami	odbiorcy liczą statusy w umówionych oknach	milczenie systemu bywa w umowie karą
5	program serwisowy warsztatu	naprawy mogą poczekać kilka godzin	mechanik pracuje na papierze i przepisuje później
6	archiwum odczytów pokładowych	sięga się po nie w rozliczeniu, nie w kryzysie	rozliczenie miesiąca przesuwa się o dzień

Ta kolejność jest jedyną częścią planu odbudowy, której nie da się wyprowadzić z techniki. Wynika z tego, czym firma zarabia w pierwszej godzinie po zdarzeniu, więc ustala ją ktoś od przewozów, a nie od informatyki.

Zapisana w opisie środowiska przestaje być tematem rozmowy w trakcie awarii, gdy pod telefonem są akurat ci, którzy są, a nie ci, którzy wiedzą.

Skąd bierze się różnica między szacunkiem a zmierzonym czasem

Z rzeczy, o których nikt nie pamięta, dopóki ich nie zabraknie. Adres, pod którym stała usługa wymiany danych. Reguła na urządzeniu brzegowym, dopisana kiedyś doraźnie dla jednego kontrahenta. Powód, dla którego jedna maszyna ma inne ustawienie niż pozostałe. Konto techniczne, którym loguje się program spedycyjny.

Każda z tych rzeczy z osobna to kilkanaście minut. Razem to kilka godzin, a w praktyce więcej, bo szuka się ich po kolei i każda wychodzi na jaw dopiero wtedy, gdy coś przez nią nie wstaje.

Próba odbudowy wykonana w spokojny wtorek wyciąga je wszystkie naraz i za pierwszym razem prawie zawsze wypada gorzej od deklaracji. Właśnie dlatego ma sens. Druga próba, po uzupełnieniu opisu, jest zwykle o rząd wielkości krótsza, a trzecia daje liczbę, którą można wpisać do dokumentu dla zleceniodawcy.

Zapisujemy przy niej datę, zakres i osobę, która ją wykonała. Bez tych trzech informacji zmierzony czas jest tylko ładniejszą wersją tego samego szacunku.

Co robimy, żeby opisywanie nie zatrzymało przewozów

Zaczynamy od wciągnięcia do plików tego, co pracuje, w stanie zastanym i bez porządkowania po drodze. Nic się przy tym nie wyłącza i nie restartuje, więc pracę prowadzimy w zwykłym tygodniu, także wtedy, gdy flota jeździ pełną obsadą.

Dopiero z gotowego opisu powstaje lista rzeczy wartych zmiany. Wyrównujemy to, co rozjechało się bez powodu, i zostawiamy każdą różnicę, którą ktoś potrafi uzasadnić. Inna przepustowość łącza na bazie, inna liczba maszyn i inna pula adresowa w biurze zostają parametrami, bo wynikają z rzeczywistości.

Pierwszą realną zmianę wykonaną tą drogą planujemy w tygodniu o mniejszym ruchu i przechodzimy przez nią razem z osobą, która ma zatwierdzać kolejne. Chodzi o to, żeby zobaczyła całą drogę od propozycji do wykonania raz, zanim zdecyduje sama, i żeby stało się to w miesiącu, w którym nic nie stoi na rampie.

Komu odradzamy tę pracę

Firmie z jedną maszyną i jednym adresem, która nie planuje drugiego, bo wtedy powtarzalność, czyli cała przewaga tego podejścia, nie ma zastosowania. Firmie, która za kilka miesięcy i tak przenosi środowisko gdzie indziej. Firmie, w której nikt nie zamierza czytać planu ani zatwierdzać zmian, a utrzymanie ma jednocześnie zostać po jej stronie.

Odmawiamy również wtedy, gdy ta praca ma być doklejona do innego zlecenia jako dodatkowa pozycja. Pliki powstające przy okazji przestają odpowiadać rzeczywistości w ciągu miesiąca, a wtedy zapłaciliście za opis, z którego nikt nie odważy się niczego uruchomić.

Co zostaje u Was po tej pracy

Opis każdego zasobu, moduły na części powtarzalne, procedura odbudowy środowiska od zera z zapisaną kolejnością, lista dostępów awaryjnych z nazwiskami oraz protokoły z wykonanych prób odbudowy razem ze zmierzonymi czasami. Ten ostatni komplet jest tym, który pokazujecie zleceniodawcy pytającemu o ciągłość pracy.

Repozytorium jest Wasze od dnia założenia, więc kolejne zmiany możecie wprowadzać własnymi rękami albo zlecać je nam. Przeglądy planów prowadzimy zdalnie, a rozmowy o kierunku w biurze przy Kresowej 6 albo u Was, bo kolejność odbudowy ustala się razem z osobą odpowiadającą za dyspozytornię.

Bieżące prowadzenie zasobów opisuje administracja chmurą, dzierżawę Microsoftu Azure dla firm, a układ z minimum sprzętu przy bramie chmura hybrydowa. Wymiany danych uruchamiane na tak opisanych maszynach pakujemy wcześniej zgodnie z tym, co robimy przy konteneryzacji Docker, a nowe środowisko warto opisać plikami już w trakcie migracji do chmury.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026