Na testach wszystko wygląda idealnie: CPU ma zapas, RAM się mieści, odpowiedzi API są szybkie. Potem wchodzi realny ruch i po dwóch godzinach użytkownicy zgłaszają „spowolnienie”, timeouty i losowe błędy 502. Z perspektywy zespołu to trudny scenariusz: monitoring nie pokazuje jeszcze alarmów, a biznes już widzi spadek konwersji i rosnącą liczbę zgłoszeń.

To nie jest anomalia. To standardowy efekt różnicy między ruchem laboratoryjnym a produkcją, gdzie requesty nie są równe, użytkownicy nie zachowują się przewidywalnie, a wiele komponentów walczy o te same zasoby. W praktyce takie przypadki najczęściej wychodzą podczas stałego utrzymania, które łączy system, aplikację i warstwę usług w jeden model operacyjny, zamiast rozdzielania ich na silosy typu „to na pewno nie u nas”.

CPU nie jest problemem, dopóki nie spojrzysz na iowait i scheduler

Najczęstszy błąd to patrzenie wyłącznie na „CPU usage”. Serwer pokazuje 45%, więc teoretycznie ma zapas. W rzeczywistości użytkownik czeka, bo procesy blokują się na I/O.

W incydentach produkcyjnych regularnie widać ten sam wzorzec:

  • load average rośnie szybciej niż użycie CPU
  • iowait podbija się skokowo przy piku ruchu
  • run queue wydłuża się, mimo że CPU nie jest wysycone

To moment, w którym scheduler staje się wąskim gardłem. Procesy aplikacji, workerzy bazy, zadania systemowe i operacje I/O konkurują o czas CPU.

Z zewnątrz wygląda to jak trudne do wyjaśnienia opóźnienie. W praktyce to klasyczny przypadek: CPU wygląda dobrze, ale system nie nadąża z obsługą zadań.

Dysk: opóźnienie zabija szybciej niż brak IOPS

W benchmarku dysk daje dobre wyniki, bo test jest czysty i przewidywalny. W produkcji pojawia się miks operacji: losowe odczyty, fsync, logi, rotacje, snapshoty.

Problemem nie jest liczba IOPS, tylko stabilność latencji.

Użytkownik odczuwa p95 i p99, nie średnią. Wystarczy, że opóźnienie skacze z 2 ms do 50 ms, żeby:

  • baza zaczęła czekać
  • aplikacja czekała na bazę
  • kolejki requestów zaczęły rosnąć

W logach pojawia się wtedy charakterystyczna sekwencja:

  • wydłużone zapytania do DB
  • rosnący upstream response time
  • później timeouty i 5xx

System formalnie działa, ale użytkownik doświadcza już degradacji usługi.

Pula połączeń: problem, który daje niespójne objawy

Źle dobrana pula połączeń nie degraduje systemu natychmiast. Najpierw:

  • rośnie czas oczekiwania na wolne połączenie
  • requesty zaczynają się kolejkować
  • pojawiają się timeouty

Testy obciążeniowe rzadko to wychwytują, bo używają jednej ścieżki. Produkcja ma nierówny ruch, różne endpointy i zmienne czasy odpowiedzi.

Efekt jest powtarzalny: krótki pik ruchu powoduje długi ogon opóźnień. System wraca do normy po kilku minutach, ale użytkownik już odczuł problem.

Noisy neighbor i lock contention

W środowisku współdzielonym wydajność może spaść bez żadnej zmiany po Twojej stronie.

  • backup na tym samym storage
  • job analityczny
  • snapshot VM

To wystarczy, żeby podnieść latencję całej platformy.

Do tego dochodzi lock contention: transakcje blokują się na tych samych danych. Na wykresach wszystko wygląda poprawnie, a użytkownik czeka.

To dokładnie ten typ problemu, który nie wychodzi w testach syntetycznych.

Sieć: problem, którego nie widać na wykresie interfejsu

Brak dropów na interfejsie nie oznacza, że sieć jest zdrowa.

Problemy siedzą wyżej:

  • retransmisje TCP
  • kolejki na load balancerze
  • DNS pod presją
  • timeouty między usługami

Efekt: „czasem działa, czasem nie”.

To najdroższy typ problemu operacyjnego, bo jest trudny do odtworzenia i kosztuje czas zespołu.

Dlaczego metryki wyglądają dobrze, a biznes widzi problem

Większość monitoringu opiera się na średnich i progach.

Problem: degradacja zaczyna się w:

  • percentylach (p95/p99)
  • kolejkach
  • czasach oczekiwania

Z perspektywy biznesu oznacza to:

  • spadek konwersji
  • więcej ticketów
  • rosnący koszt obsługi
  • pogorszenie SLA

Dlatego realna wydajność Linux w produkcji nie wynika z „czy serwer żyje”, tylko z tego, jak szybko użytkownik dostaje odpowiedź.

Wniosek: testy pokazują potencjał, produkcja weryfikuje stabilność

Benchmark mówi, co system potrafi w idealnych warunkach.

Produkcja pokazuje, ile z tego realnie dostarczasz użytkownikowi pod normalnym ruchem.

Największy problem nie polega na tym, że system natychmiast traci stabilność.

Problem polega na tym, że przez długi czas wygląda na zdrowy.

Jeżeli metryki mówią „jest dobrze”, a użytkownik mówi „jest wolno” — to zwykle użytkownik ma rację.