Alarm, który od tygodnia był „znanym błędem”, przespał prawdziwą awarię

Ciao! 🇵🇱🇮🇹

W poniedziałek 12 października dostałem na Telegramie dwa komunikaty „Błąd w automatyzacji”. Wyglądały tak samo jak tydzień wcześniej, więc prawie je przewinąłem. Dobrze, że tym razem zajrzałem głębiej.

Lecimy z tematem 🚀

Dwa zabezpieczenia, oba ślepe tego samego ranka

Na stronie mojej wspólnoty jest podstrona z nagraniami spotkań. W każdy poniedziałek o 9:00 mój Mac synchronizuje ją z kanałem na YouTube przez zadanie launchd. To zadanie już kiedyś po cichu nie wystartowało, więc postawiłem drugie zabezpieczenie: workflow w n8n na osobnym serwerze. O 10:00 sprawdza w REST API WordPressa datę ostatniej zmiany tej podstrony i alarmuje, jeśli jest stara.

Objaw. Oba workflowy n8n związane ze stroną zgłosiły błąd, o 9:00 i o 10:00. Tydzień wcześniej było dokładnie to samo i wtedy ustaliłem przyczynę: ochrona przed botami na hostingu zablokowała adres IP serwera z n8n i zamiast JSON-a oddawała 403. W notatkach zapisałem, że do czasu dodania wyjątku poniedziałkowe błędy to „znany stan”. Zgłoszenie do hostingu miałem wysłać i przez tydzień tego nie zrobiłem.

Co się naprawdę działo. Pod znanym komunikatem siedziała tym razem druga, nowa awaria. Podstrona z nagraniami miała datę zmiany z 5 października, czyli synchronizacja w ogóle się nie odpaliła. Mac był wyłączony od niedzieli 23:40 do poniedziałku 9:34. Dokumentacja launchd obiecuje, że zadanie z kalendarza wystartuje po wybudzeniu, jeśli komputer spał. O wyłączonym komputerze milczy, a u mnie trzy poniedziałkowe zadania po prostu przepadły. launchctl list pokazywał przy synchronizacji status 0, tyle że był to kod wyjścia sprzed tygodnia. Strażnik, który miał wyłapać właśnie taką ciszę, dostał 403 i wysłał ten sam komunikat co tydzień wcześniej. Słowo w słowo, choć sytuacja była zupełnie inna.

Jak to wykryć u siebie. Gdy automat na laptopie nie zostawił śladu, wpisz w terminalu last reboot. Pokaże, kiedy komputer się wyłączył i kiedy wstał. Jeśli termin zadania wypadł między tymi godzinami, launchd go nie nadrobi. Druga rzecz to przegląd alertów, które od jakiegoś czasu uznajesz za znane. Jeśli taki alert pochodzi od strażnika, to przez cały ten czas strażnika nie miałeś. Miałeś powiadomienie, które co tydzień przypominało o jego braku.

Jak naprawiłem. Trzy zadania puściłem ręcznie około 10:40 i podstrona dostała świeżą datę. Potem w końcu wysłałem zgłoszenie do hostingu. Po siedmiu minutach przyszła odpowiedź, że wyjątek mogę dodać sam: w panelu DirectAdmin jest sekcja „Ochrona przed botami” z zakładką „Wyjątki IP”. Dodałem adres serwera i z wnętrza kontenera n8n sprawdziłem dwie rzeczy: że ruch wychodzi właśnie przez ten adres i że strona oddaje mu JSON. Tydzień czekania na naprawę, która zajęła minutę.

Czego to uczy. Znany błąd strażnika oznacza, że strażnika nie ma. Taki błąd powinien iść na początek kolejki, bo zasłania wszystkie inne, a wpisanie go do notatek jako „znany stan” to najwygodniejszy sposób, żeby o nim zapomnieć.

🛠️ Narzędzie

last reboot

Polecenie last reboot w terminalu macOS (działa też na Linuksie) wypisuje historię uruchomień i wyłączeń komputera z dokładnymi godzinami. Użyłem go, żeby sprawdzić, czy Mac w ogóle działał o 9:00, kiedy miała ruszyć synchronizacja: wyłączył się w niedzielę o 23:40, a wstał o 9:34. Logi aplikacji tego nie pokażą, bo zadanie, które nie wystartowało, nie zostawia żadnego wpisu. Polecam, bo to pierwsze pytanie przy każdym milczącym automacie na laptopie, a odpowiedź przychodzi w sekundę.

https://ss64.com/mac/last.html

🌍 Ze świata

• An impatient SRE’s guide to deleting alerts. Poradnik dyżurnych GitLaba każe wyciszać alert o znanym problemie, ale zawsze z odnośnikiem do zgłoszenia, które śledzi naprawę. Ja wyciszyłem swój tylko w głowie i właśnie dlatego zgłoszenie przeleżało tydzień.
• How to Monitor Cron Jobs with Healthchecks.io. Zadanie po każdym przebiegu wysyła ping, a brak pingu w ustalonym oknie uruchamia alarm. Tak wyłapałbym wyłączonego Maca bez pytania strony, która akurat blokowała mój serwer.
• Dead man’s switch, explained for developers. Autor zwraca uwagę, że gdy jeden dostawca trzyma i zegar, i alarm, oba mogą paść razem. U mnie strażnik i strona stały za tym samym filtrem, więc padły razem.

😄 Na koniec

Z góry launchctl list pokazywał mi status 0. Od dołu strona widziała tydzień ciszy.

Komiks: vk.com/piterskii_punk_wall

Jeśli ktoś w Twoim otoczeniu powinien to przeczytać, prześlij mu ten numer. To najlepsza forma wsparcia.

A jeśli wolisz wesprzeć bezpośrednio: postaw mi kawę.