Administracja serwerami Linux Bydgoszcz

Skąd w jednej firmie bierze się kilka maszyn linuksowych, z których każda jest inna?

Z historii, nie z decyzji. Pierwsza maszyna powstała, bo ktoś potrzebował miejsca na wymianę plików i postawił ją tak, jak umiał w tamtym roku. Druga przyszła razem z systemem zamówionym u zewnętrznej firmy i została skonfigurowana według jej zwyczajów. Trzecią uruchomił pracownik, który interesował się tematem i odszedł dwa lata później. Czwarta jest kopią trzeciej, zrobioną w pośpiechu przed jakimś terminem.

Efekt widać dopiero wtedy, gdy trzeba zrobić coś na wszystkich naraz. Na jednej logowanie idzie kluczem, na drugiej wspólnym hasłem, a na trzeciej kontem, które nazywa się jak imię kogoś z księgowości. Kopie wykonują się w trzech różnych narzędziach i o trzech różnych porach. Dzienniki leżą tam, gdzie akurat je zostawiono, czyli na tej samej maszynie, której miałyby dotyczyć.

Żadna z tych rzeczy nie jest awarią. Wszystkie razem sprawiają, że każda prosta czynność wymaga najpierw przypomnienia sobie, jak akurat ta maszyna była zrobiona, a to jest dokładnie ten koszt, którego nie widać w żadnym zestawieniu.

Co ujednolicamy najpierw, a czego nie ruszamy wcale?

Kolejność bierze się z ryzyka. Najpierw dostęp, bo bez niego nie da się odpowiedzialnie zrobić czegokolwiek innego. Potem kopie, bo dopiero one pozwalają zmieniać ustawienia bez wstrzymywania oddechu. Dalej nadzór i dzienniki, żeby awarie przestały być zaskoczeniem. Na końcu usługi i terminarz wydań.

Nie ruszamy natomiast trzech rzeczy. Dystrybucji, jeśli dostaje poprawki bezpieczeństwa i aplikacja na niej działa. Struktury katalogów, do której przywykli ludzie wgrywający tam pliki od lat. Sposobu, w jaki Wasz dostawca oprogramowania wdraża swoje wersje, dopóki nie koliduje z niczym innym. Każda z tych zmian kosztowałaby Was czas, a nie dołożyłaby ani jednej godziny dostępności.

Jak wyglądają pierwsze trzy miesiące?

Okres	Co robimy po naszej stronie	Co widać u Was
Tydzień pierwszy	spis usług, właścicieli i punktów wejścia	rozmowy z osobami korzystającymi z maszyn
Tydzień drugi i trzeci	konta imienne, klucze, koniec logowania roota	każdy pracuje na własnym dostępie
Miesiąc pierwszy, koniec	jednolity harmonogram kopii i pierwsze odtworzenie próbne	protokół z odtworzenia wybranej maszyny
Miesiąc drugi	nadzór na wszystkich maszynach, dzienniki wysyłane poza nie	alerty zamiast telefonów od pracowników
Miesiąc drugi, koniec	uporządkowanie zadań cyklicznych i powiadomień o błędach	informacja o nieudanym zadaniu tego samego dnia
Miesiąc trzeci	terminarz wydań i lista maszyn do podniesienia wersji	plan na rok z datami i skutkami

Rozłożenie prac na kwartał nie wynika z ich pracochłonności. Wynika stąd, że każda zmiana w dostępie dotyka ludzi, którzy pracują na tych maszynach od lat, i lepiej, żeby dowiadywali się o niej po kolei niż wszyscy w jednym tygodniu.

Dlaczego nie przenosimy wszystkiego na jedną dystrybucję?

Bo byłaby to wygoda kupiona za Wasze pieniądze. Ujednolicenie systemów wymaga sprawdzenia zgodności każdej aplikacji, odtworzenia konfiguracji, testów i okien serwisowych, a firma nie dostaje w zamian ani jednej nowej możliwości. Dostaje wyłącznie środowisko, które nam łatwiej się prowadzi.

Co innego wydanie, które przestało dostawać poprawki bezpieczeństwa. Wtedy mówimy o tym wprost, pokazujemy termin i planujemy podniesienie wersji jako osobne zadanie, ze sprawdzeniem, co producent aplikacji dopuszcza. Do tego czasu taka maszyna dostaje zawężony dostęp z sieci i częstszą kontrolę kopii.

Granica jest prosta: zmieniamy to, co grozi awarią albo włamaniem, i zostawiamy to, co jest wyłącznie kwestią gustu. Tę samą regułę stosujemy przy narzędziach. Jeżeli zadania cykliczne są opisane w cronie i działają, nie przenosimy ich do timerów systemd tylko dlatego, że nowszy zapis czyta się przyjemniej. Zmiana wchodzi wtedy, gdy przynosi coś mierzalnego, na przykład powiadomienie o zadaniu zakończonym błędem, którego wcześniej nie było.

Za co odpowiadamy przy maszynie postawionej przez kogoś innego?

Za system, pakiety, bazę jako usługę, certyfikaty, dostęp, kopie, nadzór oraz diagnozę z dzienników przy awarii. Restartujemy usługi, przywracamy działanie po nieudanej zmianie i przekazujemy opis zdarzenia z godziną i komunikatem.

Kod aplikacji zostaje u jej autora, tak samo jak decyzje o wersjach i migracjach danych. Przy podnoszeniu wersji języka albo silnika bazy pracujemy równolegle: my dostarczamy środowisko i listę niezgodności, autor wprowadza poprawki. Zapisujemy to przed pierwszą zmianą, bo bez takiego zdania każde trudniejsze wdrożenie kończy się ustalaniem, kto miał się tym zająć.

Pozostałe maszyny prowadzimy w ramach administracji serwerami, środowiska Microsoftu przy administracji Windows Server, a hosty i maszyny wirtualne przy wirtualizacji serwerów. Stawkę dla swojej liczby maszyn sprawdzicie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026