Administracja serwerami Linux Toruń

Co zostaje po programiście, który postawił Wam serwer i zniknął?

Zwykle działająca maszyna, hasło zapisane w mailu sprzed czterech lat i przekonanie, że wszystko jest w porządku, dopóki nic nie miga. Toruńskie firmy trafiają na to częściej, niż wynikałoby z ich wielkości, bo program do obsługi zamówień, ewidencji partii albo odczytu z rejestratorów bywa tu pisany na zamówienie przez jedną osobę, a nie kupowany z pudełka.

Serwer po takim autorze ma cechę, która odróżnia go od maszyny postawionej przez firmę: nie ma dokumentacji, bo nigdy nie była nikomu potrzebna. Autor pamiętał wszystko, więc niczego nie zapisywał. Po jego odejściu zostaje sprzęt, który działa i którego nikt nie umie dotknąć.

Skąd bierzemy wiedzę, skoro nie ma czego przeczytać?

Z samej maszyny. Działający system opisuje siebie dokładniej niż jakikolwiek dokument, o ile ktoś umie zadać mu właściwe pytania. Poniżej to, co odtwarzamy w pierwszym tygodniu i co z tego zostaje na stałe.

Co ustalamy	Skąd to czytamy	Co zostaje po przejęciu
Co startuje razem z systemem	jednostki systemd i ich zależności	wykaz usług z opisem, do czego służą
Co uruchamia się cyklicznie	cron, timery i skrypty w katalogach zadań	lista zadań z porą i właścicielem
Co jest widoczne z zewnątrz	otwarte porty i reguły zapory	opis wejść do maszyny i ich uzasadnienie
Kto ma dostęp	klucze w kontach, wpisy sudo, historia logowań	konta imienne, klucze przypisane osobom
Gdzie leżą dane	wolumeny, katalogi bazy, ścieżki w konfiguracji	mapa danych z retencją i objętością
Co przestanie działać po restarcie	próba kontrolowanego uruchomienia w oknie	kolejność startu zapisana w opisie

Ostatni wiersz jest najważniejszy i najczęściej pomijany. Maszyna działająca bez przerwy przez trzy lata potrafi nie wstać po planowym restarcie, bo usługa uruchomiona kiedyś ręcznie nigdy nie została dodana do autostartu. Sprawdzamy to w umówionym oknie, a nie przy pierwszej awarii zasilania.

Co robimy z danymi, które rosną same?

Odczyty z rejestratorów temperatury, wag i czujników w chłodni mają jedną uciążliwą cechę: przybywa ich w stałym tempie i nikt tego nie zauważa, dopóki zapis się nie zatrzyma. Baza rośnie liniowo, kopia rośnie razem z nią, a wolumen kończy się w środku sezonu.

Zamiast czekać na ten moment, ustalamy trzy rzeczy na starcie. Jak długo dane muszą być dostępne w systemie, żeby dało się z nich korzystać na co dzień. Jak długo trzeba je przechowywać w ogóle, co zwykle wynika z umowy z odbiorcą i z dokumentacji jakościowej. Gdzie trafia archiwum, gdy przestaje być potrzebne w bazie roboczej. Dopiero z tymi odpowiedziami wdrażamy usuwanie starszych odczytów, bo wcześniej byłoby to kasowanie w ciemno.

Do monitoringu dokładamy próg na zajętości wolumenu danych, liczony nie procentem, tylko przewidywanym czasem do zapełnienia. Osiemdziesiąt procent na dysku rosnącym o gigabajt dziennie znaczy coś zupełnie innego niż osiemdziesiąt procent na dysku, który stoi w miejscu.

Jak wpuszczamy autora aplikacji na maszynę, którą prowadzimy?

Na własnym koncie, z własnym kluczem i z uprawnieniami ograniczonymi do jego części środowiska. Nie odcinamy go, bo to zwykle jedyna osoba rozumiejąca kod, a spór o dostęp kończy się tym, że firma zostaje z aplikacją, której nikt nie rozwija.

Zmienia się natomiast tryb pracy. Wspólne konto, z którego korzystali wszyscy, przestaje istnieć. Wejścia zostawiają ślad w dzienniku, więc po nieudanej podmianie wiadomo, co i kiedy zostało zmienione. Przed zmianą w godzinach pracy produkcji robimy migawkę maszyny, żeby powrót trwał minutę. Granica odpowiedzialności jest przy tym prosta: autor odpowiada za swój program, my za maszynę pod nim.

Kto dostaje alert, gdy usługa żyje, ale odpowiada błędem?

Nikt, jeżeli monitoring sprawdza wyłącznie, czy proces jest uruchomiony. To najczęstszy błąd w środowiskach, które przejmujemy: na ekranie wszystko świeci na zielono, a aplikacja od godziny zwraca użytkownikom komunikat o błędzie połączenia z bazą.

Dlatego w Zabbiksie ustawiamy próby, które robią to samo, co robi program: pytają usługę na jej porcie i sprawdzają treść odpowiedzi. Do tego dochodzi kontrola certyfikatów z wyprzedzeniem trzydziestu dni, bo wygasły certyfikat zatrzymuje integrację równie skutecznie jak awaria sprzętu, oraz blokowanie prób logowania po serii nieudanych, standardowe na każdej maszynie widocznej z internetu.

Zdarzenia zapisujemy poza samą maszyną. Dziennik leżący wyłącznie na serwerze, który padł albo został przejęty, jest wart dokładnie tyle, ile pamięć osoby zgłaszającej awarię.

Kiedy Linux w Waszej firmie przestaje się opłacać?

Wtedy, gdy jest jedyną taką maszyną, obsługuje jedną aplikację, a w firmie nie ma nikogo, kto potrafiłby na nią wejść. Brak opłaty licencyjnej wygląda wtedy atrakcyjnie w zestawieniu kosztów i znika przy pierwszym dłuższym przestoju. W takiej sytuacji mówimy wprost, że opieka zewnętrzna nie jest luksusem, tylko warunkiem sensu całego rozwiązania.

Rachunek wygląda inaczej, gdy maszyn jest kilka, gdy stoją na nich bazy, aplikacje webowe i kontenery albo gdy liczy się wydajność na jeden serwer. Wtedy Linux wygrywa i nie ma o czym dyskutować.

Środowiska Microsoftu prowadzimy przy administracji Windows Server, całość warstwy serwerowej opisuje administracja serwerami, a hosty i maszyny wirtualne wirtualizacja serwerów. Kwotę dla własnego środowiska policzycie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026