Administracja serwerami Linux Kraków

Dlaczego opis krakowskiej maszyny kończy się na historii poleceń?

Bo powstawała etapami, a każdy etap miał inny termin. Serwer uruchomiono pod jedno narzędzie zespołu, po roku dołożono na nim drugą usługę, potem ktoś poprawił ustawienia przy okazji awarii, a jeszcze później dostawca aplikacji dopisał własne zadanie cykliczne. Żadna z tych zmian nie była błędem i żadna nie trafiła nigdzie poza samą maszynę.

W krakowskich centrach usług wygląda to szczególnie kontrastowo. Procesy biznesowe są tam opisane co do kroku, bo wymaga tego rozliczenie z grupą, a serwer, na którym te procesy stoją, nie ma nawet listy uruchomionych usług. Firma potrafi powiedzieć, kto zatwierdza fakturę powyżej pewnej kwoty, i nie potrafi powiedzieć, dlaczego jedna z maszyn restartuje się w każdą niedzielę.

Objaw jest zawsze ten sam. Nikt nie chce jej dotknąć, bo nikt nie umie przewidzieć skutku, więc zmiany odkłada się latami, a kolejne potrzeby zaspokaja kolejną maszyną obok. Po pięciu latach koszt utrzymania rośnie, a wiedza się nie zwiększa.

Co przenosimy do zapisu, a czego nie warto?

Nie wszystko naraz i nie wszystko w ogóle. Zaczynamy od rzeczy, które trzeba umieć powtórzyć po awarii, i od tych, które wykonuje się często. Poniżej podział, który stosujemy przy pierwszym przeglądzie maszyny.

Element środowiska	Skąd odtwarzamy go po awarii	Czego z niego nie zapisujemy
Pakiety i wersja systemu	wykaz z repozytorium konfiguracji	pojedynczych poprawek wgranych awaryjnie
Ustawienia usług i serwera www	pliki trzymane w repozytorium	zawartości katalogów z danymi
Konta, klucze i uprawnienia sudo	zapis ról, bez samych sekretów	haseł i kluczy prywatnych, te idą osobno
Zadania cykliczne i timery	definicje razem z oczekiwanym wynikiem	dzienników z poprzednich uruchomień
Reguły zapory na hoście	zapis dozwolonych kierunków	adresów przypisanych doraźnie na godzinę
Baza danych	zrzut logiczny i ustawienia silnika	danych, które przychodzą z kopii, nie z zapisu
Certyfikaty	procedura wydania i odnowienia	materiału klucza, który zostaje w magazynie

Kolumna trzecia bywa zaskoczeniem. Repozytorium konfiguracji ma opisywać sposób, w jaki maszyna powstaje, a nie zastępować kopii zapasowej. Wrzucenie do niego danych albo sekretów kończy się tym, że najlepiej chroniona część środowiska leży w miejscu, do którego zagląda cały zespół.

Jak wygląda zmiana, której nie wolno wprowadzić ręcznie?

Krócej, niż zakłada ktoś, kto nigdy tak nie pracował. Poprawka trafia najpierw do zapisu, potem ktoś ją czyta, następnie wchodzi na maszynę testową, a na końcu na produkcję. Przy drobnej zmianie cała droga zajmuje kwadrans, przy poważniejszej dzień, bo dochodzi uzgodnienie okna.

Zysk widać dopiero za trzecim razem. Ta sama zmiana wykonana na pięciu maszynach jest jednym wykonaniem, a nie pięcioma seriami poleceń, z których jedna prawie zawsze różni się od pozostałych. Przy okazji znika najczęstsza przyczyna awarii po zmianie, czyli rozjazd między serwerem testowym a produkcyjnym, o którym nikt nie wiedział, bo obie maszyny stawiano ręcznie w odstępie roku.

Wyjątek robimy dla dwóch sytuacji i mówimy o nim od razu. Poprawka bezpieczeństwa wchodzi natychmiast, a zapis uzupełniamy po niej. Podobnie przy awarii: najpierw przywracamy działanie, potem opisujemy, co zostało zrobione. Reguła, która przeszkadza w gaszeniu pożaru, jest łamana już przy pierwszym pożarze i przestaje obowiązywać.

Skąd wiadomo, że tę maszynę da się odtworzyć?

Stąd, że raz to zrobiliśmy i zmierzyliśmy czas. Próba wygląda tak: bierzemy czysty system, wykonujemy na nim zapis konfiguracji, przywracamy dane z kopii i sprawdzamy, czy usługi odpowiadają. Wynik zapisujemy jako liczbę godzin, razem z listą rzeczy, których zabrakło.

Braki są przy pierwszej próbie zawsze i po to ją robimy. Zwykle okazuje się, że gdzieś zostało hasło wpisane kiedyś ręcznie, że jedna biblioteka została zainstalowana poza repozytorium pakietów albo że aplikacja zapisuje coś do katalogu, którego nikt nie objął kopią. Każdy z tych braków jest tani do usunięcia w środę po południu i kosztowny w dniu awarii.

Próbę powtarzamy po większych zmianach oraz raz na kwartał, bo środowisko żyje, a zapis, którego nikt nie sprawdza, po roku opisuje maszynę sprzed roku. Wynik z datą trafia do raportu i jest jedyną uczciwą odpowiedzią na pytanie o czas powrotu po awarii.

Co z tego ma zespół, który pracował tu po swojemu?

Przede wszystkim koniec zgadywania. Nowa osoba dostaje repozytorium zamiast rozmowy z kimś, kto pamięta, jak było, a urlop autora konfiguracji przestaje zatrzymywać jakąkolwiek pracę. Przy zgłoszeniu widać, co zmieniło się na maszynie w ostatnich dniach, więc diagnoza zaczyna się od faktu, a nie od pytania, czy ktoś ostatnio czegoś nie ruszał.

Druga korzyść dotyczy rozmów poza zespołem. Wykaz maszyn, ich ustawień, kont i wyników prób odtworzenia jest gotową odpowiedzią na pytania, które w spółkach rozliczanych przez grupę przychodzą cyklicznie. Dokument powstaje przy pracy, a nie na wezwanie, więc nie zabiera nikomu tygodnia.

Repozytorium zakładamy przy tym po Waszej stronie, nie u siebie. Zmiana firmy prowadzącej maszyny sprowadza się wtedy do przekazania dostępów, a nie do odbudowywania wiedzy, która znów zdążyła zamienić się w czyjąś pamięć.

Pozostałe maszyny w środowisku prowadzimy w ramach administracji serwerami, systemy Microsoftu przy administracji Windows Server, a węzły, na których te maszyny stoją, przy wirtualizacji serwerów. Stawkę dla swojej liczby maszyn sprawdzicie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026