Administracja serwerami Linux Olsztyn

Co w warmińskim obiekcie stoi akurat na Linuksie?

Prawie zawsze ta sama grupa rzeczy, choć rzadko ktoś ją tak wymienia. Strona obiektu razem z galerią i cennikiem. Silnik rezerwacji, przez który gość wybiera termin i płaci zadatek. Warstwa wymiany danych z portalami rezerwacyjnymi, która pilnuje, żeby ten sam pokój nie był w dwóch miejscach opisany jako wolny. Poczta wychodząca z potwierdzeniami. Do tego zwykle drobiazgi dopisywane przez lata: formularz zapytania o grupę, eksport do księgowości, skrypt zbierający zdjęcia z monitoringu terenu.

Wspólna cecha tej listy jest taka, że wszystko na niej działa na zewnątrz. Klient końcowy widzi te usługi bezpośrednio, a nie przez pracownika obiektu. Awaria nie kończy się utrudnieniem w pracy, tylko sprzedażą, która nie doszła do skutku, i to w miesiącu, w którym robi się wynik całego roku.

Dlaczego pilnujemy wieku ostatniej udanej synchronizacji, a nie tylko usługi?

Bo najgorsza awaria w tym środowisku nie wygląda jak awaria. Usługa odpowiada, strona się otwiera, formularz działa, a mimo to dostępność wysłana do portali pochodzi sprzed sześciu godzin. Portal sprzedaje według tego, co dostał ostatnio, więc pokój wyjeżdża drugi raz i dowiadujecie się o tym przy ladzie, w chwili meldunku.

Dlatego na takiej maszynie ustawiamy dwa niezależne zegary. Pierwszy mierzy to, co mierzy się zawsze: czy usługa odpowiada i w jakim czasie. Drugi mierzy wiek ostatniej wymiany zakończonej powodzeniem.

Co sprawdzamy	Jak często	Kiedy powstaje zgłoszenie
Odpowiedź silnika rezerwacji	co minutę	brak odpowiedzi w dwóch kolejnych sprawdzeniach
Wiek ostatniej udanej wymiany z portalem	co 5 minut	przekroczenie progu ustalonego z obiektem
Kolejka nieudanych ponowień	co 5 minut	kolejka rośnie w trzech kolejnych odczytach
Czas odpowiedzi bazy przy rezerwacji	co minutę	wyraźne odejście od pomiaru sprzed sezonu
Kolejka poczty wychodzącej	co 5 minut	wiadomości zalegające dłużej niż zwykle
Certyfikaty usług wystawionych na świat	codziennie	30 dni przed wygaśnięciem

Próg dla drugiego wiersza ustalamy z obiektem, bo zależy od tego, jak szybko schodzą u Was terminy. Pensjonat z dwunastoma pokojami i ośrodek z dwustoma miejscami mają w tej sprawie zupełnie inne oczekiwania i obie odpowiedzi są poprawne.

Co robi ta maszyna w noc, w której ruszają rezerwacje na długi weekend?

Dostaje w kilka godzin tyle zapytań, ile w lutym zbiera przez tydzień. Serwer, który przez osiem miesięcy nudził się przy dziesięciu odsłonach na minutę, nagle musi obsłużyć kolejkę ludzi klikających jednocześnie ten sam termin.

Zawodzi wtedy rzadko sam sprzęt. Zawodzą limity ustawione kiedyś pod zwykły ruch: liczba procesów PHP-FPM, pula połączeń do bazy, pamięć przydzielona na zapytanie, czas oczekiwania serwera stron na odpowiedź aplikacji. Każdy z nich z osobna jest rozsądny, a razem tworzą sufit, o który maszyna uderza w najgorszym momencie.

Dlatego wydajność mierzymy w kwietniu, przy sztucznym obciążeniu odtwarzającym szczyt, i dopiero po pomiarze zmieniamy ustawienia. Przy okazji sprawdzamy, co da się odciążyć bez dokładania sprzętu: pamięć podręczną stron, kompresję, rozmiary zdjęć w galerii oraz zapytania, które silnik rezerwacji wykonuje przy każdym wyświetleniu kalendarza.

Dlaczego potwierdzenie rezerwacji trafia gościowi do spamu?

To pytanie pada w każdym obiekcie i prawie zawsze ma tę samą przyczynę. Wiadomości wychodzą prosto z serwera, na którym stoi silnik rezerwacji, adres nadawcy jest z jednej domeny, strona z drugiej, a wpisów potwierdzających prawo tego serwera do wysyłki albo nie ma, albo pochodzą sprzed pięciu lat i wymieniają dostawcę, z którego dawno nie korzystacie.

Porządek robimy w ustalonej kolejności. Najpierw ustalamy, kto faktycznie wysyła pocztę w imieniu obiektu, bo zwykle są to co najmniej trzy źródła: serwer rezerwacji, skrzynka recepcji i narzędzie do wysyłki ofert. Potem układamy wpisy SPF, DKIM i DMARC tak, żeby obejmowały wszystkie trzy i nie przepuszczały niczego więcej. Potem pilnujemy kolejki Postfiksa, bo zatrzymana kolejka wygląda z recepcji identycznie jak filtr antyspamowy po drugiej stronie.

Efekt jest mierzalny w raportach zwrotnych z DMARC i pokazujemy go w rozliczeniu miesiąca, zamiast zapewniać, że teraz na pewno dochodzi.

Kiedy podnosimy wydanie dystrybucji i dlaczego akurat wtedy?

Zimą, między listopadem a lutym, bo to jedyny okres, w którym powrót do stanu sprzed zmiany nikogo nie kosztuje. Przejście z jednego wydania Debiana albo Ubuntu LTS na kolejne to zawsze zmiana wersji PHP, bibliotek i często bazy, a silnik rezerwacji bywa na te wersje wrażliwy bardziej niż na cokolwiek innego.

Kolejność jest stała. Sprawdzenie u dostawcy silnika, na czym ma prawo pracować. Kopia całej maszyny. Uruchomienie kopii obok, na tym samym hoście, i przejście przez rezerwację testową od wyboru terminu po wiadomość z potwierdzeniem. Dopiero potem zmiana na maszynie produkcyjnej, w oknie liczonym w godzinach, a nie w minutach, bo zimą taki komfort jest.

Poprawki bezpieczeństwa nie czekają na tę porę roku i wchodzą przez cały rok, także w sierpniu. Różnica polega na tym, że łatka zamykająca lukę w usłudze wystawionej do internetu jest naprawą, a zmiana wydania dystrybucji jest projektem.

Co zostaje po Waszej stronie

Domena, hosting u zewnętrznego dostawcy, umowy z portalami rezerwacyjnymi i sam kod strony, jeśli pisała ją agencja. My odpowiadamy za maszynę, za usługi na niej, za dane i za to, żeby o kłopocie było wiadomo wcześniej niż z telefonu gościa. Dostępy administracyjne są Wasze przez cały czas trwania umowy, więc zmiana dostawcy nie wymaga odbudowywania środowiska.

Domenę, pliki i bazę systemu obiektowego prowadzi administracja Windows Server. Roczny kalendarz prac i podział na to, co robimy zdalnie, opisuje administracja serwerami. Hosty i konsolidację sprzętu zebraliśmy przy wirtualizacji serwerów. Koszt przy Waszej liczbie maszyn wyliczy kalkulator.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026