Administracja serwerami Linux Wrocław

Dlaczego wrocławskie firmy zostają na starej wersji systemu?

Rzadko z zaniedbania. Zwykle dlatego, że aplikacja, na której firma zarabia, powstała na konkretnej wersji języka i biblioteki, a jej autor albo już z Wami nie pracuje, albo ma w kolejce rzeczy przynoszące pieniądze szybciej niż aktualizacja środowiska. Serwer działa, sprzedaż idzie, więc temat wraca raz w roku i za każdym razem przegrywa z czymś pilniejszym.

Drugi powód jest organizacyjny. Przejście na nowszą wersję wymaga okna, w którym wolno coś zepsuć, a w sklepie internetowym takiego okna nie ma nigdy. Nikt też nie chce być osobą, która zaproponuje zmianę i będzie tłumaczyć, dlaczego w piątek nie działa koszyk.

Efekt jest przewidywalny. Maszyna dociąga do momentu, w którym producent dystrybucji przestaje wydawać poprawki, i od tego dnia każda znaleziona luka zostaje w niej na zawsze.

Co dokładnie się kończy i kiedy zaczynamy o tym mówić?

Terminy są znane z wyprzedzeniem i to jedyna dobra wiadomość w tym temacie. Poniżej rzeczy, których daty pilnujemy przy maszynach linuksowych.

Co się kończy	Jak zwykle wychodzi na jaw	Co robimy z wyprzedzeniem
Wsparcie wydania dystrybucji	brak poprawek bezpieczeństwa po dacie	plan przejścia zaczęty rok wcześniej
Wersja języka aplikacji	biblioteka przestaje dostawać wydania	próba na klonie i lista niezgodności
Wersja silnika bazy	funkcja usunięta w kolejnym wydaniu	migracja logiczna na środowisku testowym
Obraz podstawowy kontenera	rosnąca lista podatności w skanie	przebudowa obrazu na nowszej bazie
Certyfikat usługi	strona przestaje się otwierać	automatyczne odnawianie i alert
Wsparcie sprzętu albo instancji u dostawcy	koniec gwarancji, wycofanie typu maszyny	przeniesienie w zaplanowanym oknie

Wszystkie te daty trafiają do harmonogramu i do raportu miesięcznego. Nie po to, żeby wymuszać zmianę natychmiast, tylko po to, żeby decyzja o jej odłożeniu była decyzją, a nie przypadkiem.

Jak wygląda przejście, które nie zatrzymuje sprzedaży?

Kolejność mamy stałą i żaden jej etap nie dotyka produkcji, dopóki nie ma pewności, co się stanie.

Najpierw powstaje klon maszyny w środowisku testowym, z tymi samymi usługami i z kopią bazy. Na nim podnosimy wersję i uruchamiamy aplikację, notując wszystko, co przestaje działać. Ta lista jest właściwym produktem tego etapu, bo dopiero ona pozwala oszacować pracę po stronie zespołu.

Potem dzielimy zmianę na kawałki. Bibliotekę, którą da się podnieść osobno, podnosimy osobno. Usługę, którą da się przenieść na nową maszynę i przełączyć ruchem, przenosimy w ten sposób, bo powrót polega wtedy na cofnięciu jednego ustawienia. Dopiero to, czego nie da się rozdzielić, wchodzi w jedno okno serwisowe, ustalone poza godzinami największego ruchu.

Na koniec zostaje sprzątanie: stara maszyna wyłączona, ale nieskasowana przez ustalony czas, zadania kopii przepisane na nową, progi monitoringu poprawione i dokumentacja opisująca, co się zmieniło.

Co robimy z maszyną, której nie da się dziś ruszyć?

Czasem odpowiedź brzmi: nic, przez najbliższy rok. Aplikacja jest krytyczna, zespół nie ma mocy, a wymiana kosztowałaby więcej niż cały budżet na IT. Wtedy zamiast udawać, że problemu nie ma, zmniejszamy jego zasięg.

Maszyna dostaje węższy dostęp: usługi chowamy za tunelem albo za listą dozwolonych adresów, publiczne zostaje wyłącznie to, co musi. Ruch do niej i z niej ograniczamy do znanych kierunków. Dzienniki wynosimy poza samą maszynę, żeby w razie incydentu dało się ustalić przebieg zdarzeń, a nie opowiadać, jak mogło być. Kopie sprawdzamy odtworzeniem częściej niż przy pozostałych maszynach.

Całość wpisujemy do rejestru ryzyka z datą kolejnej rozmowy. To jedyna forma, w jakiej godzimy się na system po terminie wsparcia: świadoma, opisana i tymczasowa.

Za co odpowiadamy, a gdzie kończy się nasza część?

Nasze jest wszystko poniżej aplikacji: system, pakiety, baza jako usługa, certyfikaty, dostęp, kopie, monitoring i dokumentacja opisująca, co na maszynie stoi i dlaczego. Restartujemy usługi, czytamy dzienniki i przy awarii dostajecie od nas zdiagnozowany opis, a nie samo zgłoszenie.

Kod aplikacji zostaje po Waszej stronie albo po stronie jej autora. Przy przejściach na nowsze wersje pracujemy razem: my dostarczamy środowisko i listę niezgodności, zespół wprowadza poprawki. Ten podział zapisujemy przed pierwszą zmianą, bo bez niego każda migracja kończy się ustalaniem, czyja to była kolej.

Warstwę wirtualną pod tymi maszynami opisuje wirtualizacja serwerów, środowiska Microsoftu prowadzimy w ramach administracji Windows Server, a cała warstwa serwerowa w mieście to administracja serwerami. Stawkę dla swojej liczby maszyn linuksowych wyliczycie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 31 lipca 2026