Administracja Windows Server Olsztyn

Kiedy wypada okno serwisowe w obiekcie, który nie ma nocy?

W większości firm odpowiedź jest oczywista i brzmi „w nocy albo w weekend”. W hotelu, ośrodku i pensjonacie ta odpowiedź nie działa, bo noc jest w nich najbardziej zajętą porą po stronie systemu. Około północy uruchamia się zamknięcie dnia, które nalicza pobyty, zamyka rachunki i przygotowuje zestawienia. Nad ranem zaczynają się wyjazdy, po południu meldunki, a weekend jest w sezonie najgorszym możliwym terminem na cokolwiek.

Zostaje jedno okno w ciągu doby i trzeba je znaleźć, zanim będzie potrzebne.

Pora doby	Co dzieje się w obiekcie	Czy wolno restartować serwer
0:00 do 3:00	zamknięcie dnia i naliczenia w systemie	nie, przerwanie zostawia niedomknięty dzień
6:00 do 11:00	wyjazdy, rachunki, wydawanie faktur	nie, kolejka przy ladzie
13:00 do 15:00	pusto między wyjazdami a meldunkami	tak, to jest to okno
15:00 do 22:00	meldunki, gastronomia, obsługa gości	nie
poza sezonem	obiekt zamknięty albo prawie pusty	tak, i wtedy robimy większość prac

Godziny w tabeli są typowe, a nie uniwersalne, więc na starcie spisujemy je z kierownikiem konkretnego obiektu. Ta jedna rozmowa zamyka temat na cały sezon i oszczędza dziesięć telefonów zaczynających się od pytania, czy teraz można.

Co ma się wydarzyć, gdy baza systemu obiektowego stanie na kwadrans?

Przerwa w recepcji jest widoczna od razu, więc procedurę na taki kwadrans przygotowuje się wcześniej, a nie w jego trakcie. Przed każdym oknem serwisowym powstaje wydruk listy przyjazdów i wyjazdów na bieżącą dobę. Recepcja przyjmuje gościa na papierze, wpisuje numer pokoju i wprowadza dane po powrocie systemu. Terminal płatniczy pracuje niezależnie, bo należy do operatora płatności, a nie do Waszego serwera.

Ta sama procedura obowiązuje przy awarii nieplanowanej i to jest jej właściwy sens. Obiekt, który raz w miesiącu przećwiczył kwadrans bez systemu przy okazji aktualizacji, przechodzi przez awarię łącza spokojnie. Obiekt, który nigdy tego nie robił, dzwoni po dwóch minutach i ma rację.

Jak aktualizujemy serwer pod aplikacją, której wersję dyktuje producent?

Aplikacja obiektowa, program gastronomiczny i moduł kasowy zwykle mają w umowie wsparcia zapisaną listę wspieranych wersji systemu i bazy. To ona wyznacza kolejność, a nie kalendarz Microsoftu.

Wygląda to tak. Najpierw sprawdzamy u producenta aplikacji, czy dana wersja serwera jest przez niego wspierana. Potem robimy migawkę maszyny. Potem wgrywamy łatki w oknie serwisowym. Potem sprawdzamy trzy rzeczy: czy usługa bazy wstała, czy stanowisko recepcji się loguje i czy nocne zamknięcie dnia przeszło poprawnie. Dopiero po tym ostatnim, czyli następnego ranka, uznajemy okno za zamknięte.

Jeżeli producent nie wspiera nowszego wydania, zostajemy przy obecnym i zabezpieczamy je inaczej: zawężonym ruchem, częstszą kopią i wpisem do wykazu ryzyka z datą kolejnego pytania o zgodność. Aktualizacja wbrew wymaganiom dostawcy oznaczałaby utratę wsparcia do programu, na którym stoi obiekt, więc byłaby najdroższą z możliwych oszczędności.

Dlaczego kontroler domeny nie powinien mieszkać razem z bazą?

W obiektach, które przejmujemy, jedna maszyna robi zwykle wszystko naraz. Loguje pracowników, trzyma pliki, obsługuje wydruk i utrzymuje bazę systemu obiektowego. Działa to dobrze do chwili, w której jedna z tych ról zaczyna zachowywać się nietypowo.

Baza po sezonie potrafi zająć pamięć, której zabraknie logowaniu. Aktualizacja wymagana przez producenta aplikacji pociąga za sobą restart, który przy okazji odcina wszystkich od plików. Awaria dysku zatrzymuje cztery rzeczy naraz, a odtwarzanie trwa tyle, ile najdłuższy element.

Rozdzielenie ról na osobne maszyny wirtualne kosztuje pracę raz i pieniądze co miesiąc, bo każda maszyna jest osobną pozycją w rozliczeniu. Robimy to poza sezonem i zawsze mówimy wprost, ile to zmieni na fakturze. W małym pensjonacie z jednym serwerem bywa, że nie warto i tak też odpowiadamy.

Co zostaje na dyskach po sezonie i co z tym robimy?

Cztery miesiące pełnego obłożenia zostawiają po sobie więcej danych, niż wygląda z recepcji. Baza rośnie o pobyty, rachunki i historię zmian. Serwer plików zbiera skany dokumentów, listy grup zorganizowanych i dokumenty personelu sezonowego. Do tego dochodzą wydruki, załączniki z poczty i katalogi, których po wrześniu nikt już nie otwiera.

Jesienią porządkujemy to w ustalonej kolejności. Sprawdzamy tempo nocnego zamknięcia dnia i przebudowujemy indeksy. Archiwizujemy stare pobyty, po wcześniejszym ustaleniu z producentem aplikacji, jak długo dane mają zostać dostępne z poziomu programu. Katalogom nadajemy limity przestrzeni i włączamy migawki poprzednich wersji, żeby skasowany przez pomyłkę plik dało się odzyskać bez sięgania po kopię. Na koniec sprawdzamy uprawnienia, bo w sezonie nadaje się je szybciej, niż odbiera.

Czego w tej stawce nie ma

Nie ma w niej licencji Windows Server ani licencji dostępowych, bo należą do Was. Nie ma sprzętu. Nie ma zmian w samej aplikacji obiektowej, bo pisze ją i wspiera jej producent, a my prowadzimy z nim rozmowę techniczną w Waszym imieniu. Nie ma dyżuru poza godzinami pracy helpdesku, który jest osobno płatną usługą, wycenianą po ustaleniu, których maszyn ma dotyczyć.

Bieżący nadzór nad wszystkimi maszynami i roczny kalendarz prac opisuje administracja serwerami. Maszyny z Debianem i Ubuntu, na których zwykle stoi strona obiektu i integracje z portalami, prowadzi administracja serwerami Linux. Rozdzielenie ról na osobne maszyny wirtualne zebraliśmy przy wirtualizacji serwerów. Rachunek dla własnej liczby maszyn policzycie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026