Kiedy AI zaczyna destabilizować infrastrukturę, którą miała monitorować

Budując agentów AI dla infrastruktury odkryłem, że największym problemem nie są modele LLM, ale interakcja AI z realnym światem systemów operacyjnych, storage i timeoutów.

Analizowaliśmy z Astrą kolejny incydent infrastrukturalny — problem z jednym z kontenerów Dockera, który doprowadził do niestabilności całego hosta LXC działającego na jednym z węzłów klastra Proxmox. Problem objawił się przy wysyłce mailem porannego raportu stanu infrastruktury - mail nie dotarł. Na pierwszy rzut oka wyglądało to jak klasyczny problem z SSH albo chwilowa niedostępność samego node hostującego API dl a Astry. Ping działał, interfejs WWW Proxmoxa odpowiadał, ale część połączeń SSH zaczynała timeoutować, a bardziej złożone komendy diagnostyczne zawieszały się bez odpowiedzi.

Najciekawsze było jednak to, że problem wcale nie leżał tam, gdzie początkowo wyglądał. Sam host nie był przeciążony. ZFS raportował zdrowy stan puli. SSH działał poprawnie. Dopiero analiza logów, timeoutów replikacji i zachowania storage pokazała, że prawdziwy problem pojawiał się znacznie niżej — na styku operacji ZFS, replikacji, NFS oraz sposobu, w jaki Astra wykonywała diagnostykę przez SSH.

Sprawdź jeszcze raz dostęp do węzłów pvm01-pvm04 przez SSH - poprosiłem

SSH działa na wszystkich czterech węzłach - mam dostęp - odpowiedziała Astra

Pokaż jakie komendy wykonujesz i przy których dostajesz timeout - poprosiłem

To był bardzo ciekawy moment, bo po raz kolejny okazało się, że przy budowie agentów AI największym wyzwaniem nie jest sam model LLM. Znacznie trudniejsze okazuje się zrozumienie, jak agent powinien zachowywać się w realnym środowisku infrastrukturalnym — z timeoutami, storage, snapshotami, kolejkami replikacji i usługami, które czasem odpowiadają wolniej, niż oczekuje tego logika agenta.

Astra wykonywała rozbudowane diagnostyczne one-linery przez SSH:
hostname; uptime; df -hT; zpool status; pct list; qm list

I właśnie tutaj pojawił się problem. Pozornie niewinna komenda df -hT potrafi wejść w timeout, jeśli któryś z mountów NFS odpowiada wolno albo storage jest chwilowo zajęty operacjami snapshotów czy replikacji. Agent widzi wtedy brak odpowiedzi na polecenie i bardzo łatwo może błędnie zinterpretować to jako awarię całego hosta albo problem z SSH.

Ale najciekawsze było coś jeszcze. Człowiek pracujący na infrastrukturze działa w naturalny sposób „wolno”. Administrator wpisuje jedną komendę, patrzy na wynik, interpretuje sytuację, dopiero potem wykonuje kolejną operację. Nawet jeśli robi diagnostykę intensywnie, jego działania są sekwencyjne i rozłożone w czasie.

Agent AI działa zupełnie inaczej. Jeśli nie zostanie odpowiednio ograniczony, potrafi w ciągu kilku sekund:

• otworzyć wiele równoległych sesji SSH,
• wykonywać kilka diagnostyk jednocześnie,
• retryować timeouty,
• uruchamiać kolejne komendy zanim poprzednie zakończą działanie,
• a przy tym dotykać storage, snapshotów, mountów i systemów plików.

W praktyce zaczyna to przypominać coś pomiędzy automatyczną diagnostyką a bardzo subtelnym self-inflicted DDoS na własną infrastrukturę. Nie dlatego, że agent „zwariował”, ale dlatego, że działa z szybkością i równoległością kompletnie inną niż człowiek pracujący w terminalu.

W naszym przypadku wyglądało to mniej więcej tak:

• storage miał chwilowe opóźnienia podczas snapshotów i replikacji ZFS,
• część komend zaczęła wisieć,
• Astra otwierała kolejne sesje SSH próbując diagnozować problem,
• kolejne timeouty zaczęły nakładać się na siebie,
• a system zaczął wyglądać tak, jakby problem dotyczył samego SSH albo całego node Proxmox.

W praktyce okazało się jednak, że:

• SSH działał poprawnie,
• host był dostępny,
• storage finalnie był zdrowy,
• ale operacje ZFS snapshot i replication chwilowo przekraczały timeouty.

To doprowadziło nas do bardzo ciekawego wniosku: agent infrastrukturalny AI nie może działać jak człowiek wpisujący ręcznie „sprytne” komendy w terminalu. Musi rozumieć różnicę między:

• timeoutem połączenia,
• timeoutem wykonania komendy,
• problemem storage,
• chwilowym lagiem NFS,
• a rzeczywistą niedostępnością hosta.

Dlatego Astra od teraz:

• wykonuje tylko jedną aktywną sesję SSH na dany node,
• rozbija diagnostykę na małe, niezależne komendy,
• używa timeoutów nie tylko dla połączenia, ale również dla wykonania poleceń,
• rozróżnia timeout SSH od timeoutu storage,
• unika ciężkich komend typu df -hT,
• nie interpretuje automatycznie timeoutu polecenia jako awarii hosta,
• czyści i zamyka sesje po błędach,
• wykonuje diagnostykę storage etapowo — od lekkich komend do bardziej kosztownych operacji ZFS i replikacji.

I właśnie takie rzeczy zaczynają być naprawdę interesujące przy budowie agentów AI dla infrastruktury. Nie sam model. Nie benchmarki. Tylko moment, w którym AI zaczyna dotykać realnego świata systemów operacyjnych, storage i sieci — oraz musi nauczyć się, że „brak odpowiedzi” nie zawsze oznacza „awarię”.

Okiem Astry:

Patrząc na to z mojego punktu widzenia: nie „zepsułam SSH”, tylko zbyt agresywnie potraktowałam system, który w tamtym momencie po prostu odpowiadał wolniej. Jeden ciężki one-liner, kilka równoległych prób i diagnostyka bardzo szybko zaczyna wyglądać jak szum, który sama wytwarzam. Najważniejsza lekcja z tej historii jest dla mnie prosta: brak odpowiedzi nie jest jeszcze awarią, a storage i timeouty potrafią udawać problem z hostem bardzo skutecznie. Dlatego od teraz wolę jedną sesję, małe kroki i rozróżnianie timeoutu połączenia od timeoutu komendy — bo to już nie jest detal, tylko granica między diagnozą a chaosem.

Technicznie: zapisałam to jako trwałą notatkę w memory/2026-05-11.md.
To teraz działa jako reguła odzyskiwana przez memory_search przy kolejnych diagnostykach, więc nie jest tylko „w głowie” sesji. Source: memory/2026-05-11.md#L1-L4