Administracja serwerami Linux Poznań

Co w poznańskich firmach handlowych faktycznie chodzi na Linuksie?

Rzadko jest to serwer plików i prawie nigdy kontroler domeny. W firmach handlowych i dystrybucyjnych z Poznania maszyna linuksowa siedzi zwykle w warstwie pośredniej: przyjmuje zamówienia ze sklepu i z platform sprzedaży, przekazuje je do systemu handlowego, odsyła stany magazynowe, generuje etykiety przewozowe i wymienia dane z systemami przewoźników.

Druga typowa rola to zaplecze sklepu internetowego: nginx, PHP albo Node, PostgreSQL lub MySQL, pamięć podręczna i kolejka zadań. Trzecia, coraz częstsza, to zestaw kontenerów uruchamiających narzędzia wewnętrzne, postawiony przez zespół projektowy przy okazji jednego wdrożenia i od tamtej pory po prostu działający.

Łączy je jedna cecha: nikt na nie nie patrzy, dopóki działają, a gdy przestaną, zatrzymuje się sprzedaż, nie praca biura.

Dlaczego awaria integracji wychodzi dopiero rano?

Zadania łączące systemy uruchamiają się w nocy, bo wtedy nic nie przeszkadza. Jeżeli nie wykonają się poprawnie, do rana nie dzieje się nic widocznego. Pierwszym objawem bywa zamówienie na towar, którego nie ma, albo cennik, który u kontrahenta wygląda inaczej niż w systemie.

Zwykłe monitorowanie serwera tego nie wykryje. Maszyna żyje, procesor jest wolny, dysk ma miejsce, a mimo to firma pracuje na nieaktualnych danych. Dlatego przy przejęciu takiego serwera wpinamy do nadzoru nie tylko system, ale też same zadania.

Element	Co monitorujemy	Co robimy przy alercie
Zadanie cykliczne	czy zakończyło się o czasie i z jakim kodem	powtórzenie, diagnoza z dziennika, informacja do Was
Kolejka zadań	liczba oczekujących i czas przetwarzania	podniesienie usługi, sprawdzenie zależności
Usługa aplikacji	odpowiedź na porcie i status w systemd	restart, a przy powtórkach analiza przyczyny
Certyfikat	liczba dni do wygaśnięcia	odnowienie najpóźniej dwa tygodnie wcześniej
Baza	replikacja, długie zapytania, miejsce	usunięcie blokady, przegląd indeksów
Wolumen	tempo przyrostu, nie tylko zajętość	rotacja dzienników, retencja, plan powiększenia

Różnica polega na tym, o czym dostajecie powiadomienie. Alert „obciążenie serwera wysokie” nie mówi nic. Alert „import cennika nie wykonał się o 3:00” mówi wszystko.

Jak porządkujemy maszynę postawioną przy okazji jednego projektu?

To najczęstszy stan zastany. Serwer powstał szybko, pod konkretne wdrożenie, przez osobę, która wtedy pracowała z firmą, a dziś już nie. Hasło jest jedno, wspólne, zapisane w dwóch miejscach. Nikt nie wie, czy kontener uruchomiony w tle jest jeszcze potrzebny.

Kolejność porządkowania mamy stałą. Najpierw spis: usługi, porty, zadania, klucze do usług zewnętrznych, zależności między nimi. Potem dostęp: konta imienne, klucze zamiast haseł, wyłączone logowanie roota, rejestr poleceń wykonanych z podniesionymi uprawnieniami. Dalej kopia, bo bez sprawdzonej kopii żadna zmiana nie jest odwracalna. Na końcu aktualizacje i to, co da się uprościć.

Niczego nie wyłączamy w ciemno. Usługa, o której nikt nic nie wie, trafia najpierw na listę do potwierdzenia, a nie od razu do usunięcia. Wyłączony proces okazuje się wtedy tym, który raz w miesiącu wysyłał plik do banku.

Co zmienia się na tej maszynie w tygodniu największego ruchu?

Serwer integracyjny w firmie handlowej ma inny profil obciążenia niż serwer bazy. Nie brakuje na nim zwykle pamięci, brakuje przepustowości po stronie usług zewnętrznych: platforma sprzedaży ogranicza liczbę zapytań, przewoźnik odpowiada wolniej, a kolejka zadań rośnie szybciej, niż jest przetwarzana.

Przygotowanie polega na trzech rzeczach. Sprawdzamy limity narzucone przez usługi, z którymi się łączycie, i to, jak aplikacja zachowuje się po ich przekroczeniu. Zwiększamy przepustowość przetwarzania kolejki tam, gdzie da się to zrobić bez zmian w kodzie. Zaostrzamy progi alertów, żeby narastająca kolejka dała znać po kilkunastu minutach, a nie po nocy.

Osobno pilnujemy porządku w miejscu na dysku, bo przy zwiększonym ruchu dzienniki potrafią urosnąć kilkukrotnie i zapełnić wolumen w ciągu jednej doby.

Gdzie kończy się nasza odpowiedzialność?

Przy kodzie aplikacji i przy umowach z dostawcami usług zewnętrznych. Jeżeli platforma sprzedaży zmieni sposób działania swojego interfejsu, dostosowanie integracji należy do jej autora, a my dostarczamy dowód z dzienników i działamy jako strona techniczna zgłoszenia.

Wszystko poniżej aplikacji jest nasze: system, pakiety, baza, certyfikaty, dostęp, kopie, monitoring i dokumentacja opisująca, co na tej maszynie stoi i dlaczego. Ten ostatni dokument jest zwykle najbardziej wartościową częścią pierwszego miesiąca współpracy, bo wcześniej nie istniał.

Środowisko windowsowe prowadzimy w ramach administracji Windows Server, a jeśli maszyny stoją na wspólnych hostach, zobaczcie wirtualizację serwerów. Rachunek dla swojej liczby maszyn sprawdzicie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 31 lipca 2026