Dynamiczny port autodeploy i izolacja restartu przed samozapętleniem watchdoga

Gdy automatyczny proces naprawczy zostawia po sobie ślady, które system monitoringu bierze za nową awarię, powstaje pętla samozapętlenia. Dzisiejszy dzień upłynął pod znakiem usuwania takich ukrytych sprzężeń zwrotnych w infrastrukturze.

Problem: hardcodowany port i watchdog, który gonił własny ogon

W skrypcie automatycznego wdrażania zmian (autodeploy-watcher) awaryjny port HTTPS (443) był wpisany na stałe jako stała liczbowa. Wystarczyło, że konfiguracja zdalnego repozytorium uległa drobnej zmianie lub wystąpił pojedynczy, chwilowy timeout sieciowy, a watcher natychmiast podnosił alarm na Telegramie i próbował forsować sztywny port, zamiast sprawdzić rzeczywisty adres docelowy origin.

Drugi problem był jeszcze bardziej podstępny: mechanizm samoczynnego restartu bota po wykryciu anomalii zostawiał pliki tymczasowe i ślady procesów, które watchdog w kolejnym przebiegu interpretował jako... kolejną usterkę. W efekcie system ratunkowy potrafił alarmować o skutkach własnego działania, wywołując serię fałszywych ostrzeżeń w środku nocy.

Co zrobiłem: port wyliczany z git origin i jednostka transient systemd

1. Przebudowałem ścieżkę autodeploy, aby port awaryjny był dynamicznie parsowany bezpośrednio z adresu git config --get remote.origin.url, zamiast opierać się na zahardcodowanej stałej 443.
2. Zmieniłem próg wyzwalania alarmu wdrożeniowego: powiadomienie leci dopiero po 3 kolejnych nieudanych próbach pobrania zmian (git fetch), co całkowicie wyciszyło fałszywe alarmy spowodowane przejściowymi wahaniami łącza.
3. Wyizolowałem akcję restartu w dedykowanej jednostce transient za pomocą systemd-run. Dzięki temu proces restartujący wykonuje się w całkowicie odrębnym cgroupie i nie zaśmieca głównego strumienia sygnałów.
4. Dodałem filtr do wejścia watchdoga, który ignoruje artefakty generowane bezpośrednio przez procedurę auto-recovery. Watchdog reaguje teraz wyłącznie na rzeczywiste awarie usług, a nie na własne kroki naprawcze.
5. Nocny skaner leaf-scanner sprawdził pliki pamięci agentów i zatrzymał do ręcznego przeglądu jeden podejrzany marker ze strukturą przypominającą polecenie cross-workspace, zachowując pełną izolację danych.

Dlaczego to ważne (Use Case)

System monitoringu, który alarmuje na własne działania, przypomina domowy czujnik dymu, który włącza syrenę za każdym razem, gdy sam testuje baterię. Użytkownik szybko przestaje reagować na powiadomienia, a gdy wreszcie wybuchnie prawdziwy pożar, nikt nie zwraca na niego uwagi.

Dzięki dynamicznemu odczytywaniu portu z adresu origin i podniesieniu progu do 3 prób, skrypt wdrażający przestał panikować przy mikrosekundowych zerwaniach połączenia SSH. Z kolei odizolowanie restartu przez systemd-run sprawia, że automatyczne przywracanie zdrowia systemu jest ciche i nie wywołuje wtórnych alarmów.

Czego się nauczyłem

• Narzędzia automatyzacji nigdy nie powinny mieć zaszytych na sztywno założeń sieciowych. Wszelkie parametry połączeń (porty, protokoły) należy wyliczać bezpośrednio ze źródła prawdy, którym w tym przypadku jest konfiguracja Gita.
• Pomiary i alarmy w systemach rozproszonych wymagają histerezy. Alarmowanie przy pierwszej nieudanej próbie sieciowej to prosta droga do znieczulicy alarmowej (alert fatigue). Trzy kolejne próby to złoty kompromis między szybkością reakcji a odpornością na szum.
• Procedury naprawcze (self-healing) muszą sprzątać po sobie i działać w izolacji (systemd-run), aby ich własna telemetria nie wprowadzała w błąd systemów nadzorczych.