Administracja serwerami Linux Warszawa

Co dzieje się na tej maszynie między północą a północą?

Serwer linuksowy w warszawskiej firmie rzadko ma jedną rolę. Tej samej nocy przelicza dane z poprzedniego dnia, rano przyjmuje wdrożenie od zespołu, w południe obsługuje wewnętrzne narzędzia, a wieczorem odpowiada klientom, którzy korzystają z aplikacji po pracy. Każda z tych pór ma inne wąskie gardło i inną osobę, którą trzeba zawiadomić.

Pora	Co się zwykle dzieje	Na co patrzymy
00:00 do 05:00	zadania wsadowe, kopie logiczne bazy, przeliczenia	czy zadanie skończyło się w swoim przedziale
05:00 do 08:00	wysyłka plików i raportów do systemów zewnętrznych	kody odpowiedzi i wielkość wysłanych paczek
08:00 do 12:00	wdrożenia zespołu, zmiany konfiguracji	wersje usług, restarty, dziennik poleceń
12:00 do 17:00	ruch wewnętrzny i praca na narzędziach firmowych	czas odpowiedzi usług, kolejka zadań
17:00 do 22:00	ruch klientów z zewnątrz, szczyt zapytań	najdłuższe zapytania, blokady, liczba połączeń
22:00 do 00:00	okno prac, rotacja dzienników, porządki	wolne miejsce po rotacji, czas restartów

Ta tabela powstaje przy przejęciu maszyny i bywa pierwszym dokumentem, w którym ktokolwiek zapisał, kiedy właściwie wolno tę maszynę zatrzymać.

Dlaczego awaria zadania nocnego kosztuje najwięcej rano?

Bo nocą nic nie krzyczy. Proces kończy się błędem o drugiej, maszyna pracuje dalej, procesor jest wolny, dysk ma miejsce. Objaw pojawia się po ośmiu godzinach, kiedy kontrahent pyta o plik, którego nie dostał, albo gdy raport sprzedaży pokazuje dane sprzed doby.

Zwykły nadzór nad serwerem tego nie wychwyci, bo wszystko, co mierzy, wygląda poprawnie. Dlatego przy przejęciu maszyny wpinamy do nadzoru nie sam system, ale też każde zadanie z osobna: jego oczekiwaną porę zakończenia, kod wyjścia i długość wykonania. Zadanie, które nagle trwa trzy razy dłużej, jest ostrzeżeniem na tydzień przed tym, aż przestanie się mieścić w nocy.

Powiadomienie ma przy tym mówić, co się stało. Komunikat o wysokim obciążeniu nie przydaje się nikomu o szóstej rano.

Jak dzielimy dobę na nasze okna i Wasze wdrożenia?

Ustalamy to raz, przy starcie, i wpisujemy do wspólnego kalendarza. Nasze prace wymagające restartu idą w oknie wieczornym albo weekendowym, po migawce maszyny. Wdrożenia zespołu mają swoje pory, zwykle przedpołudniowe, kiedy jest komu zareagować, gdy coś pójdzie nie tak.

Reguła jest jedna: dwie strony nie ruszają tej samej usługi w tej samej godzinie. Brzmi banalnie, a rozwiązuje najczęstszy spór w firmach, które mają własnych programistów i zewnętrznego administratora. Po nieudanym wieczorze nikt nie ustala, czy zawiniła nowa wersja biblioteki, czy wgrana wtedy poprawka systemu, bo jedno z dwojga po prostu nie miało wtedy prawa się wydarzyć.

Poprawki bezpieczeństwa są wyjątkiem i wchodzą poza tym rytmem. Mówimy o tym z góry, żeby nikt nie odbierał tego jako złamania ustaleń.

Co robimy z maszyną, do której loguje się pół zespołu?

Zastajemy zwykle jedno konto, jedno hasło i kilkanaście osób, które je znają, w tym dwie pracujące dziś gdzie indziej. Nie odbieramy nikomu dostępu, bo to kończy się pracą obok procesu. Zamiast tego każdy dostaje własne konto i własny klucz, logowanie na roota znika, a polecenia wykonane z podniesionymi uprawnieniami trafiają do dziennika trzymanego poza samą maszyną.

Zysk widać dopiero po nieudanym wieczorze. Zamiast trzech rozmów o tym, kto co zmienił, jest lista poleceń z godzinami. Drugi zysk pojawia się przy odejściu osoby z zespołu: odbiera się jeden klucz zamiast zmieniać hasło, o którym trzeba poinformować wszystkich pozostałych.

Przy okazji powstaje odpowiedź na pytanie, kto naprawdę ma prawa administracyjne. W środowiskach, które przejmujemy w stołecznych spółkach, ta lista bywa dłuższa niż skład działu technicznego.

Gdzie kończy się nasza część, a zaczyna Wasza?

Nasze jest wszystko pod aplikacją: system, pakiety, baza jako usługa, certyfikaty, dostęp, kopie, nadzór i opis środowiska. Restartujemy usługi, czytamy dzienniki i przy awarii przekazujemy zdiagnozowany opis zdarzenia.

Wasze zostaje samo oprogramowanie: jego wersje, migracje schematu i wydania. Przy podnoszeniu wersji języka albo silnika bazy pracujemy razem, my dostarczamy środowisko i listę niezgodności, zespół wprowadza poprawki. Granicę zapisujemy przed pierwszą zmianą, bo bez niej każde trudniejsze wdrożenie kończy się ustalaniem, czyja to była kolej.

Pozostałe maszyny w środowisku prowadzimy w ramach administracji serwerami, systemy Microsoftu przy administracji Windows Server, a stawkę dla swojej liczby maszyn sprawdzicie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026