Administracja serwerami Linux Łódź

Co naprawdę robi ta maszyna w firmie żyjącej z wysyłki?

Rzadko jedną rzecz. W typowym łódzkim środowisku, w którym sklep internetowy spotyka się z magazynem, na jednym serwerze linuksowym siedzi kilkanaście strumieni danych naraz. Jeden przyjmuje zamówienia ze sklepu, drugi przekazuje je do systemu magazynowego, trzeci odbiera informację o skompletowaniu, czwarty zamawia etykietę u przewoźnika, piąty odsyła numer przesyłki do kupującego, szósty aktualizuje stany na marketplace’ach, a siódmy przygotowuje dane do księgowości.

Każdy z tych strumieni ma innego właściciela po drugiej stronie i inną porę, w której musi zadziałać. Wspólne mają to, że w chwili zatrzymania żaden nie wywołuje alarmu w klasycznym sensie: procesor jest wolny, dysk ma miejsce, system odpowiada. Rośnie za to liczba pozycji czekających w kolejce, a to widać wyłącznie wtedy, gdy ktoś tam patrzy.

Dlatego nadzór nad taką maszyną zaczynamy od czegoś innego niż od systemu. Zaczynamy od spisania, co przez nią przepływa, w jakim tempie i co się dzieje po drugiej stronie, gdy przepływ ustaje.

Po czym poznajemy, że wymiana danych stanęła?

Po kolejce, nie po telefonie. Poniżej strumienie, które w firmie fulfilmentowej wracają najczęściej, razem z tym, kiedy uznajemy je za zatrzymane.

Strumień	Co się w nim zbiera	Kiedy dzwoni alert	Co robimy najpierw
Zamówienia ze sklepu do magazynu	pozycje czekające na przyjęcie	gdy najstarsza czeka dłużej niż uzgodniony czas	sprawdzamy odpowiedź systemu magazynowego
Potwierdzenia skompletowania	zwrotki z magazynu do sklepu	gdy przestają wracać przy trwającym ruchu	czytamy dziennik integracji i kody odpowiedzi
Zamówienia etykiet u przewoźników	żądania odrzucone i ponawiane	przy serii odrzuceń z jednego kierunku	patrzymy na limity i na ważność poświadczeń
Statusy przesyłek do kupujących	wiadomości oczekujące na wysyłkę	gdy kolejka rośnie mimo pracującej usługi	sprawdzamy nadawcę i kolejkę poczty
Stany magazynowe do marketplace’ów	pakiety z aktualizacją dostępności	gdy ostatnia wysyłka jest starsza od progu	porównujemy stan w bazie ze stanem wysłanym
Dokumenty do księgowości	pliki i potwierdzenia odbioru	pierwszego dnia miesiąca, gdy zadanie nie kończy się w swoim przedziale	sprawdzamy zadanie cykliczne i kod wyjścia
Zwroty i korekty	pozycje bez przypisanego zamówienia	gdy grupa takich pozycji przekracza próg	oddajemy wykaz obsłudze klienta

Ostatni wiersz nie jest awarią techniczną i właśnie dlatego go pilnujemy. Zwrot, którego system nie umie przypisać, leży w kolejce tygodniami, a odzywa się dopiero jako reklamacja, w miesiącu, w którym nikt już nie pamięta okoliczności.

Co się psuje, gdy ruch rośnie kilkukrotnie przez trzy tygodnie?

Nie to, czego wszyscy się spodziewają. Procesor i pamięć zwykle wytrzymują, bo firmy kupują je z zapasem. Pierwsza pęka pojemność: dzienniki rosną w tempie proporcjonalnym do liczby zamówień, katalog z plikami tymczasowymi puchnie, a kopie zaczynają trwać dłużej, niż wynosi przerwa między nimi.

Drugą typową przyczyną są limity po stronie partnerów. Przewoźnik dopuszcza określoną liczbę zapytań na minutę, marketplace odrzuca zbyt częste aktualizacje stanów, a bramka płatności ma własne progi. W spokojnym miesiącu nikt tych granic nie dotyka, w listopadzie dotyka się ich codziennie. Odpowiedzią nie jest mocniejszy serwer, tylko rozłożenie zapytań w czasie i ponawianie odrzuconych z rosnącym odstępem.

Trzecia rzecz dotyczy bazy. Zapytanie, które przy dwustu zamówieniach dziennie wykonuje się w ułamku sekundy, przy dwóch tysiącach potrafi zablokować tabelę i zatrzymać kompletację. Dlatego odczyty ze szczytu zbieramy i zachowujemy, a wnioski z nich przekazujemy latem, gdy jest jeszcze czas coś zmienić.

Jak dzielimy pracę z firmą, która pisze sklep?

Granicę zapisujemy przed pierwszą zmianą, bo bez niej każde trudniejsze wdrożenie kończy się ustalaniem, czyja to kolej. Po naszej stronie zostaje wszystko pod aplikacją: system, pakiety, usługi, broker kolejek, baza jako usługa, certyfikaty, dostęp, kopie i nadzór. Podnosimy to, co przestało odpowiadać, szukamy śladu w dziennikach i oddajemy gotową diagnozę zamiast samego zgłoszenia.

Po stronie autora sklepu zostaje kod, jego wersje i migracje schematu. Przy podniesieniu wersji języka albo silnika bazy pracujemy równolegle: dostarczamy środowisko i listę niezgodności, zespół wprowadza poprawki na maszynie testowej, dopiero potem wchodzi to na produkcję.

Osobno umawiamy się co do wdrożeń w sezonie. Poza szczytem zespół wypuszcza wersje wtedy, kiedy chce. Od daty zamrożenia zmian wchodzą wyłącznie poprawki błędów, a każde wydanie poprzedza migawka maszyny. Ta jedna zasada oszczędza najwięcej rozmów w grudniu.

Za co odpowiadamy przy maszynie widocznej z internetu?

Za to, żeby widać było wyłącznie to, co widoczne być musi. Publiczny zostaje sklep i te punkty wymiany danych, do których łączą się partnerzy, a lista adresów, z których wolno się połączyć, jest tam, gdzie partner ma stały adres. Pozostałe usługi chowamy za tunelem, panele administracyjne przenosimy poza publiczny adres, a próby logowania powtarzane w krótkim czasie blokujemy.

Do tego dochodzi porządek w dostępie ludzi. Zastajemy zwykle jedno konto, jedno hasło i kilka osób, które je znają, w tym jedną pracującą już gdzie indziej. 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ą.

Pozostałe maszyny w środowisku prowadzimy w ramach administracji serwerami, systemy 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