Dlaczego stabilny Linux nagle zaczyna się psuć

W poniedziałek o 9:00 wszystko wyglądało normalnie. CPU poniżej 40%, RAM bez presji, dysk niepełny. A mimo to panel klienta ładował się po 12 sekund, API losowo zwracało timeouty, a kolejki zadań zaczęły rosnąć. Dzień wcześniej „było przecież dobrze”.

To klasyka produkcji. System nie psuje się nagle. Najczęściej psuje się powoli, aż przekroczy próg, po którym objawy stają się widoczne dla użytkownika.

Dlaczego „stabilny” Linux bywa tylko pozornie stabilny

W wielu środowiskach „stabilny” oznacza tyle, że:

  • host nie padł,
  • usługa odpowiada na healthcheck,
  • nie ma krytycznych alertów.

To za mało. Linux może przez miesiące utrzymywać poprawny stan techniczny, a równolegle tracić margines bezpieczeństwa wydajnościowego. Gdy ten margines spadnie do zera, drobna zmiana ruchu, jedna wolniejsza odpowiedź DNS albo dłuższy backup wystarczą, żeby system wszedł w degradację.

Dlatego długoterminowa administracja serwerami Linux to nie tylko reagowanie na awarie, ale kontrola trendów, które na początku wyglądają niewinnie.

Co realnie narasta w czasie

Drift konfiguracji

Na starcie masz jedną wersję konfiguracji. Po pół roku masz „prawie tę samą”, ale:

  • ktoś ręcznie dopisał wyjątek w nginx.conf,
  • systemd ma lokalny override tylko na jednym hoście,
  • sysctl różni się między nodami,
  • limity ulimit nie są spójne po migracji użytkownika serwisowego.

Każda zmiana osobno jest mała. Razem tworzą środowisko, w którym ten sam release aplikacji zachowuje się inaczej zależnie od hosta.

Kolejki, które rosną wolniej niż alarmy

Najgroźniejsze kolejki rosną liniowo i długo nie przekraczają progów alarmowych. Przykład: worker przetwarzał 120 zadań/s, potem 110, potem 100. Biznes tego nie czuje od razu, bo ruch jest zmienny. Po paru tygodniach backlog robi się stały, a opóźnienie użytkownika rośnie z minut do godzin.

To samo dotyczy kolejek połączeń TCP, pooli DB i opóźnień w brokerze wiadomości. Jeżeli nie monitorujesz trendu, sam stan absolutny jest mylący.

Retry, które „ratują” system aż do momentu, gdy go zatykają

Retry maskuje problem źródłowy. Gdy jedna zależność zaczyna odpowiadać wolniej, aplikacja dokłada ponowienia. Na początku skuteczność wygląda dobrze. Potem retry zaczyna dominować ruch i podwaja obciążenie backendu.

Efekt w praktyce: rosną czasy odpowiedzi, rosną timeouty, rośnie liczba retry. Dodatnie sprzężenie zwrotne.

Ukryte limity

Widziałem incydenty, gdzie wszystko „nagle” padło przez limit, który istniał od początku:

  • nf_conntrack_max dobrany pod stary profil ruchu,
  • LimitNOFILE wystarczający przy 2 instancjach, za niski przy 6,
  • wyczerpanie inodów mimo wolnego miejsca,
  • vm.max_map_count za niski po zmianie sposobu cache’owania.

Limit staje się problemem dopiero po miesiącach wzrostu ruchu albo zmianie charakteru ruchu.

Najczęstsze wzorce opóźnionych awarii w produkcji

  1. Powolna degradacja DNS — sporadyczne timeouty resolvera zwiększają ogólny latency aplikacji.
  2. Nadpisana równowaga I/O — backup, snapshoty albo agresywny logrotate zaczynają kolidować z godzinami szczytu.
  3. Rozjechane timeouty między warstwami — reverse proxy, aplikacja i baza mają różne czasy oczekiwania.
  4. Starzenie się cache — rośnie dataset, maleje hit ratio, backend dostaje więcej zapytań.
  5. Zmiany poza kontrolą zespołu — aktualizacje dostawców, DNS, API, CDN.

Właśnie dlatego w praktyce łączę monitoring infrastruktury z okresowym przeglądem realnych ścieżek ruchu.

Dlaczego monitoring często tego nie łapie

Bo większość monitoringów jest zbudowana pod awarie twarde, nie pod degradację.

Typowe luki:

  • metryki są agregowane zbyt szeroko,
  • alarmy oparte są o statyczne progi,
  • brak metryk kolejki i czasu oczekiwania,
  • brak korelacji z operacją (deploy, backup, update),
  • brak metryk z perspektywy użytkownika.

W środowiskach Linux szczególnie widać to na poziomie kernela i sieci, gdzie krótkie piki nie przebijają się do uśrednionych metryk.

Sygnały, że środowisko degraduje się przed awarią

  • p95 i p99 rosną, choć średnia stoi,
  • liczba połączeń rośnie szybciej niż ruch,
  • rośnie liczba retry i błędów chwilowych,
  • worker ma coraz mniej „idle time”,
  • kolejki rzadziej wracają do zera,
  • pojawiają się powtarzalne skoki iowait,
  • po update rośnie koszt operacji (np. TLS, reconnecty).

Gdy widzisz kilka takich sygnałów naraz, to jest trend, nie przypadek.

Jak myśleć o długoterminowej stabilności Linuxa

Stabilność to nie stan, tylko zasób, który się zużywa.

  • rosnący ruch zabiera margines,
  • zmiany konfiguracyjne wprowadzają rozjazdy,
  • aktualizacje zmieniają zachowanie systemu.

Jeżeli tego nie mierzysz, dowiadujesz się o problemie dopiero przy awarii.

W praktyce mniej ufam „zielonym dashboardom”, a bardziej ścieżce żądania od DNS po storage. W kontekście bezpieczeństwa dotyczy to też hardeningu — źle zaplanowane zmiany potrafią poprawić security i pogorszyć stabilność, co szerzej opisuję w tekście o hardeningu usług publicznych.

Nawyki operacyjne, które realnie zmniejszają ryzyko

1. Przegląd driftu jako rutyna

Potrzebujesz cyklicznego diffu:

  • konfiguracji systemowej,
  • unitów systemd,
  • wersji pakietów,
  • parametrów kernela.

2. Alarmy na trend

Nie tylko „przekroczyło próg”, ale „rośnie od X dni”.

3. Korelacja zmian

Backup, cron, update — wszystko musi zostawiać ślad w czasie.

4. Kontrola zależności

  • sensowne timeouty,
  • ograniczony retry,
  • cache tam gdzie trzeba,
  • fallbacki.

5. Testy po aktualizacjach

Security update to zmiana produkcyjna. Może zmienić wydajność, TLS, zachowanie klienta.

Co sprawdzać raz w miesiącu

  1. Drift konfiguracji między hostami
  2. Trend p95/p99 z 90 dni
  3. Kolejki i retry
  4. DNS i sieć
  5. Limity systemowe
  6. Zadania utrzymaniowe vs obciążenie
  7. Zmiany po stronie dostawców

Jeśli robisz to regularnie, większość „nagłych” awarii przestaje być nagła.

Najważniejsza zasada operacyjna

Największy błąd, jaki można popełnić, to uznać stabilność za stan trwały.

W praktyce każdy system produkcyjny degraduje się od pierwszego dnia działania. Różnica polega tylko na tym, czy ktoś to obserwuje.

Jeżeli nie widzisz tej degradacji w metrykach, to nie znaczy, że jej nie ma. To znaczy, że patrzysz w złe miejsce.