Wiadomości z frontu produkcji

Co znajdujemy w logach w pierwszych 15 minutach

1. Flagi GC z poprzedniej wersji Javy. Parametry dobrane pod JDK 6 przeniesione przy migracji na JDK 8 albo 11: stary kolektor, sztywne rozmiary generacji, brak logu GC. Efekt to pauzy full GC liczone w sekundach, dokładnie w porze szczytu, kiedy sterta jest najbardziej pofragmentowana.
2. Pula wątków ustawiona dziesięć lat temu. Limit wątków, work managery i progi stuck thread ustawione pod ruch z innej epoki. W szczycie serwer zgłasza stuck threads, health state przechodzi w „warning", a load balancer wyłącza węzeł — MTTR rośnie, bo zanim ktoś zajrzy w logi, ruch przeniósł się na pozostałe węzły i problem „sam minął".
3. Pula JDBC mniejsza niż liczba wątków. Wątki czekają na połączenie z bazą, CPU stoi na 30 %, a użytkownik widzi timeouty. Dokładanie vCPU nic tu nie zmienia, bo procesor nie jest wąskim gardłem.

Żadna z tych rzeczy nie znika po dołożeniu sprzętu. Wszystkie widać w logu serwera, logu GC i thread dumpie zebranym w momencie spowolnienia — nie po restarcie, kiedy dowody już zniknęły.

Co zbierać, zanim zadzwonisz

• Log GC z ostatniego incydentu (włączony na stałe, rotowany — koszt pomijalny).
• Trzy thread dumpy w odstępie 10 sekund z momentu spowolnienia, nie po restarcie.
• Parametry startowe JVM i konfigurację pul (wątki, JDBC, JMS) z domeny — jeden plik konfiguracyjny.

Co daje audyt zamiast kolejnej zmiany hardware

Mapa ryzyk jednej domeny w dwa tygodnie, z priorytetami i planem — nie 80-stronicowy raport. Pierwszy tydzień zwykle wystarcza, żeby wskazać dwie, trzy zmiany konfiguracji do wdrożenia w jednym oknie serwisowym. Reszta to plan na kolejne okna, z pomiarem przed i po.

Masz log GC i thread dump z ostatniego incydentu? Piętnaście minut i powiemy, które z tych trzech. Punkt wyjścia: Audyt Middleware albo planner ryzyka wersji WebLogic.

Źródła: Oracle, „Tuning Performance of Oracle WebLogic Server" (Thread Management, Tuning Data Sources), docs.oracle.com; Oracle, „HotSpot Virtual Machine Garbage Collection Tuning Guide", docs.oracle.com. Liczby w scenariuszu są ilustracyjne — pochodzą z typowych przypadków, nie z jednego klienta.

Dwie rzeczy, z którymi oddajemy nowe środowisko

1. Runbook. Start i stop w kolejności, restart po awarii, podniesienie fix packa lub PSU, rollback, lista portów z uzasadnieniem, kontakty do dostawców. Napisany tak, żeby wykonał go inżynier, który środowiska nie widział — a nie tak, żeby zrozumiał go autor.
2. Test nieobecności. Druga osoba, po stronie klienta albo naszej, przechodzi runbook na środowisku testowym, zanim produkcja ruszy. Jedna osoba wychodzi, druga przeprowadza restart z dokumentu. Jeśli się nie da, niekompletny jest runbook, nie środowisko.

Co zwykle siedzi tylko w głowie

• Kolejność startu: baza, LDAP, node manager, admin server, klaster, load balancer — i co się dzieje, gdy się ją pomyli.
• Ręczne kroki po restarcie, których nikt nie zautomatyzował („trzeba jeszcze kliknąć w konsoli").
• Wyjątki na firewallu i certyfikaty z datą ważności, o której wie jedna osoba.
• Hasła do kont serwisowych w pliku na czyimś laptopie.

Istniejące środowiska

To samo robimy po audycie w środowiskach, które działają od lat: najpierw spisujemy, co siedzi w głowach, potem sprawdzamy, czy da się to wykonać bez nich. Zwykle wychodzi, że da się w 80 %, a brakujące 20 % to dokładnie te kroki, które wydłużają każdy incydent o godzinę.

Jeśli w Twojej firmie odpowiedź na „kto oprócz niego umie to zrestartować" brzmi „nikt", zacznij od tego, nie od migracji. Wycena nowego środowiska z runbookiem w 24 h: pakiety WebLogic, pakiety WebSphere.

Dlaczego teraz

WebLogic 12.2.1.4 jest w Premier Support do grudnia 2026, w Extended Support do grudnia 2027 (zakres poprawek w Extended zależy od umowy z Oracle). 14.1.1 ma koniec error correction 31.12.2027 wg komunikatu Oracle. 14.1.2 to wydanie LTS: Premier Support do 2030, Extended do 2033. Stan na 14.09.2026 — daty potwierdź w My Oracle Support dla swojej umowy, bo Oracle przesuwał je już dwa razy w tej linii.

Co się zmienia naprawdę

1. JDK. 12.2.1.4 działa na JDK 8, 14.1.1 na JDK 8 lub 11, 14.1.2 jest certyfikowane dla JDK 17 i 21. To największa zmiana: flagi GC, moduły JPMS, biblioteki, które nie przeszły na Javę 17 (stare Hibernate, XML-owe frameworki, agenty APM). Sprawdź to przed serwerem, nie po.
2. Konsola administracyjna. Klasyczna Administration Console została usunięta w 14.1.2. Zastępuje ją WebLogic Remote Console — osobna, lekka aplikacja. Runbooki, zrzuty ekranu w procedurach i szkolenia zespołu L1 trzeba zaktualizować; skrypty WLST działają jak dotąd.
3. Secured production mode domyślnie. W 14.1.2 wybór trybu produkcyjnego włącza bezpieczniejsze ustawienia domyślne (m.in. ograniczenia na porty administracyjne i protokoły). Środowiska, które „zawsze tak działały", zaczynają odrzucać połączenia — to najczęstszy powód wydłużenia okna migracji.
4. Bezpieczeństwo i tożsamość. Nowy provider OpenID Connect (uwierzytelnianie i identity assertion) oraz Jipher — dostawca JCE oparty na OpenSSL 3.0, natywnie zgodny z FIPS. Jeśli audyt wymaga FIPS, to argument za 14.1.2, a nie za obejściami.
5. Narzędzia do migracji. WebLogic Migration Analysis Tool wskazuje klasy i API, których nie ma już w nowej wersji; recepty OpenRewrite automatyzują część zmian w kodzie i deskryptorach. Oba wchodzą do naszego assessmentu jako pierwszy krok.
6. JMS i równoważenie. Automatyczny rebalans instancji JMS targetowanych na klaster oraz inteligentne równoważenie w Oracle HTTP Server według realnej pojemności serwerów. Realny zysk przy nierównych węzłach; bez wpływu na klastry jednorodne.

Co się nie zmienia

• Przestrzeń nazw javax.* — 14.1.2 to Jakarta EE 8, czyli te same API co Java EE 8. Nie ma potrzeby zmiany importów.
• Model domeny, klastrów, node managera, T3, deployment plans — działają jak w 12c.
• Kwartalne CPU — 14.1.2 dostaje te same poprawki bezpieczeństwa co 12.2.1.4 (w lipcowym CPU 2026 obie wersje były na tej samej liście), ale przez kolejne lata, a nie do końca 2027.

A 15.1.1?

WebLogic 15.1.1 implementuje Jakarta EE 9.1 — tu następuje zmiana javax.* → jakarta.* w kodzie i deskryptorach. Oracle udostępnia recepty Rewrite do tej transformacji, ale to nadal projekt po stronie aplikacji, nie operacja na serwerze. Dla większości środowisk produkcyjnych sensowna ścieżka to 12c → 14.1.2 (LTS) teraz, 15.1.1 dopiero razem z modernizacją aplikacji.

Jak to robimy

Assessment: inwentaryzacja domen, JDK, bibliotek i integracji; raport Migration Analysis Tool; lista zmian w konfiguracji pod secured production mode. Potem migracja domena po domenie, z klastrem 12c pracującym równolegle do przełączenia ruchu — bez okna serwisowego dla użytkowników. Punkt wyjścia: planner ryzyka wersji WebLogic albo Audyt Middleware.

Źródła: Oracle, „What's New in Oracle WebLogic Server 14.1.2.0.0", docs.oracle.com; Oracle, „WebLogic Server Compatibility" 15.1.1, docs.oracle.com; Oracle Critical Patch Update Advisory — July 2026; Oracle Lifetime Support Policy: Oracle Fusion Middleware (daty wsparcia, dostęp 14.09.2026 przez My Oracle Support).

Co IBM mówi naprawdę

• Brak planowanego EOS. „There is no planned end-of-support date for WebSphere Application Server 8.5 and 9.0" — strona polityki wsparcia WAS traditional i Liberty, zaktualizowana 9 września 2026. IBM deklaruje też wsparcie tych wydań poza datą Extended Support Oracle dla Javy 8.
• Fix packi w modelu continuous delivery. 8.5.5.x i 9.0.5.x dostają kolejne fix packi; przykład z tej samej strony: 9.0.5.28 opublikowany 16 czerwca 2026.
• iFix tylko przez dwa lata od fix packa. Poprawka tymczasowa (iFix) przysługuje dla fix packów nie starszych niż dwa lata od wydania — 9.0.5.28 traci tę eligibility 16 czerwca 2028. To jest prawdziwy zegar: nie „koniec 8.5.5", tylko koniec poprawek dla fix packa, na którym stoi Twoja produkcja.
• Java 7 i 7.1 — skończone w lipcu 2022. Serwer 8.5.5 na SDK 7 działa, ale bez poprawek bezpieczeństwa JVM. To najczęstsza realna luka, którą znajdujemy w audytach.

Skąd biorą się mity

Z mieszania trzech różnych rzeczy: końca wsparcia dla starych fix packów (rzeczywisty, kroczący), końca wsparcia dla Javy 7 (rzeczywisty, 2022) i „końca 8.5.5" (nieistniejący). Do tego dochodzą oferty migracji z datą w tytule — data zwykle pochodzi z cudzego cennika, nie z dokumentu IBM.

Gdzie jest ryzyko

1. Zaległe fix packi. Środowisko na 8.5.5.18 z 2020 roku jest poza oknem iFix od dawna: każde nowe CVE w serwerze zostaje bez poprawki do czasu podniesienia fix packa. Fix pack w WAS traditional to operacja bez zmiany wersji API — zwykle jedno okno serwisowe na klaster.
2. Wersja Javy. 8.5.5 na SDK 8, 9.0.5 na SDK 8 albo 11/17 (IBM Semeru). Sprawdź, na czym stoi JVM i czy dostaje aktualizacje — to zwykle pierwszy punkt raportu, nie ostatni.
3. Konfiguracja, nie wersja. Domyślne hasła konsoli, brak TLS 1.2+ na portach wewnętrznych, dziesięcioletnie ustawienia pul wątków i JDBC. Podniesienie wersji nic z tym nie robi.
4. Aplikacje. 8.5.5 to Java EE 6, 9.0.5 to Java EE 7, Liberty idzie w Jakarta EE 10 i wydania co cztery tygodnie z zerową migracją między nimi. Skok 8.5.5 → Liberty to zwykle dwa poziomy Java EE — dlatego zaczynamy od aplikacji, nie od serwera.

Co zrobić w tym kwartale

• Spisać wersję fix packa i SDK na każdym węźle produkcyjnym i policzyć, które są poza dwuletnim oknem iFix.
• Zaplanować podniesienie fix packa tam, gdzie okno minęło — to tańsze niż jakakolwiek migracja i usuwa większość otwartych CVE.
• Decyzję „9.0.5 czy Liberty" odłożyć do assessmentu aplikacji. Bez terminu narzuconego przez IBM można ją podjąć na spokojnie — ale trzeba ją podjąć, bo zespół, który zna 8.5.5, też się starzeje.

Punkt wyjścia: planner ryzyka wersji WebSphere — trzy pytania, ocena i cel migracji. Pełny obraz jednej domeny w dwa tygodnie daje Audyt Middleware.

Źródła: IBM, „WebSphere Application Server traditional and WebSphere Liberty support lifecycle policy and end of iFix eligibility", ibm.com/support, zmod. 9 września 2026; IBM, „Lifecycle Policy: WebSphere Application Server traditional", ibm.com/support, zmod. 8 maja 2025.

Narzędzia do optymalizacji JDK / JVM

1. VisualVM — śledzenie wydajności aplikacji Java, monitorowanie zasobów pamięci i diagnostyka problemów performansowych.
2. JMC (Java Mission Control) — narzędzie zintegrowane z JDK, analiza wydajności w czasie rzeczywistym, monitorowanie pamięci i zasobów systemowych.
3. JProfiler — specjalistyczne oprogramowanie do identyfikacji wąskich gardeł wydajnościowych i analizy wykorzystania zasobów.
4. Java Optimizer — automatyczne narzędzie identyfikujące i rozwiązujące problemy performansowe, generujące raporty optymalizacyjne.

Najlepsze praktyki

• Prawidłowe ustawienie rozmiarów stosu (-Xss) i puli pamięci (-Xms i -Xmx)
• Konfiguracja pamięci dostosowana do wymagań aplikacji (1024 / 2048 MB)
• Wybór odpowiedniej wersji JDK (32 / 64-bit) zgodnie z potrzebami
• Optymalizacja ustawień Garbage Collector (GC)
• Na systemach Linux/Unix zmiana źródła losowości na /dev/./urandom
• Regularne monitorowanie i aktualizacja konfiguracji

Red Hat staje się częścią oddziału IBM zajmującego się chmurą hybrydową. Prezes Red Hat dołączył do zespołu zarządzającego IBM i podlega bezpośrednio dyrektorowi generalnemu IBM.

Transakcja stanowi największe przejęcie w historii IBM. Firma Red Hat to jeden z największych na świecie dostawców oprogramowania typu open-source dla sektora przedsiębiorstw.

Rozwiązania opracowywane wspólnie mają odpowiadać na potrzeby związane z zapewnieniem wysokiej skalowalności i elastyczności wykorzystania zasobów informatycznych — niezależnie od rodzaju infrastruktury, na której będą działać.

Certyfikat potwierdza wiedzę z zakresu administracji środowiskiem WebSphere Application Server Network Deployment w wersji 8.5.5 oraz nowo wprowadzonego wówczas Liberty Profile — lekkiej, modułowej alternatywy dla pełnego serwera tWAS.

Zapraszamy zainteresowanych do współpracy z FlexNet — sekcja kariery zawiera aktualne stanowiska i informacje o bazie ekspertów.

Skan certyfikatu i pełna lista zdobytych certyfikacji dostępna na stronie certyfikatów.

Lokalizacja i zasada działania

Plik .htaccess znajduje się zwykle w głównym katalogu domeny. Dla wielu domen na serwerze może być wiele takich plików. Dyrektywy działają dla katalogu, w którym plik się znajduje, oraz wszystkich podkatalogów poniżej.

Tworzenie pliku

Plik .htaccess to zwykły plik tekstowy ASCII:

• Utwórz nowy plik (Ctrl+N w Notatniku)
• Dodaj potrzebne dyrektywy z enterem po każdej
• Zapisz jako: nazwa ".htaccess", typ pliku: "wszystkie pliki"
• Po wgraniu na serwer ustaw uprawnienia: chmod 644 .htaccess

Zastosowania

• Parametry ogólne — admin serwera, indeks katalogów, ochrona .htaccess, sygnatura serwera, limit wgrywanych plików, blokada przeglądania katalogów
• Rozszerzenia plików — CSS, HTML, JS, JSON, audio (OGA, MP4), wideo (OGV, MP4, WebM, FLV)
• Kompresja — mod_deflate kompresuje HTML, CSS, JS, PDF
• Cache przeglądarki — wygasanie cache dla obrazów, CSS, JS na 30 dni
• WordPress — ochrona wp-config.php oraz przepisywanie URL-i (przyjazne adresy)

Tip 1: Wyszukiwanie dużych załączników

Aby znaleźć wiadomości z dużymi załącznikami (np. powyżej 20 MB), wklej w pasek wyszukiwania Gmaila operator: has:attachment size:20M. Pomaga zidentyfikować i usunąć maile zajmujące dużo miejsca. Operatorów wyszukiwania jest wiele więcej — pełna lista w dokumentacji Google.

Tip 2: Zaplanowane wysyłanie wiadomości

Jeśli chcesz wysłać maila w przyszłości, zainstaluj wtyczkę Boomerang. Pozwala zaplanować wysyłkę na wybrany czas — przydatne przy zarządzaniu komunikacją w różnych strefach czasowych.