Monitoring strony, który wie, że przestał działać

Problem

Zadanie było prozaiczne: sprawdzać codziennie, czy pod konkretnym adresem w Poznaniu nie ma zaplanowanej przerwy w dostawie wody, i wysłać maila, jeżeli jest. Dostawca publikuje taką listę na swojej stronie. Teoretycznie wystarczy tam zajrzeć. Praktycznie nikt nie zagląda codziennie na stronę, na której w dziewięćdziesięciu dziewięciu przypadkach na sto nic nie ma — i dlatego dowiaduje się o przerwie w momencie, w którym odkręca kran.

To jest zresztą typowy kształt takiego zadania w firmie. Ktoś ma raz dziennie sprawdzić stan przetargu, dostępność towaru u dostawcy albo status przesyłki. Robi to przez dwa tygodnie, potem nieregularnie, potem wcale — bo nagroda za sprawdzenie jest zerowa dziewięć razy na dziesięć, a kara za niesprawdzenie przychodzi rzadko i z opóźnieniem.

Co zbudowałem

Przepływ jest krótki: raz dziennie powstaje zrzut ekranu strony dostawcy, model wizyjny czyta z tego obrazu listę zaplanowanych przerw, a wynik decyduje o tym, który e-mail zostanie wysłany.

Zrzut ekranu zamiast czytania kodu strony to decyzja, którą warto uzasadnić. Strony bywają przebudowywane bez uprzedzenia, a każda zmiana w ich kodzie potrafi rozsypać automat czytający konkretne miejsce w strukturze. Obraz jest odporniejszy: dopóki człowiek widzi tabelę, model wizyjny też ją widzi, niezależnie od tego, jak strona została zbudowana od środka.

Pierwszy problem: monitoring patrzył na pustą stronę

Pierwsze zrzuty były bezużyteczne. Lista awarii dociąga się na stronie dostawcy skryptem, już po tym, jak strona się wyświetli, i leży nisko — a na wierzchu wita odwiedzającego baner zgód. Zrzut powstawał w momencie, w którym na ekranie nie było jeszcze nic poza banerem.

Przyczyna okazała się bardziej pouczająca niż sam błąd. W wywołaniu usługi robiącej zrzuty ustawiłem czas oczekiwania na doładowanie treści — tyle że parametr sterujący czekaniem nazywał się inaczej, niż zakładałem. Usługa dostała nieznaną sobie nazwę i po prostu ją zignorowała. Nie zwróciła błędu, nie ostrzegła, nie zapytała. Odpowiedziała normalnym zrzutem — tylko zrobionym natychmiast.

Poprawka była banalna: właściwa nazwa parametru, sześć sekund zapasu na doładowanie treści i zrzut całej wysokości strony zamiast samego widocznego kadru, bo tabela i tak nie mieściła się w pierwszym ekranie.

Drugi problem i sedno całej historii: cicha porażka

Naprawienie zrzutu odsłoniło usterkę o zupełnie innym ciężarze gatunkowym. Kiedy monitoring nie widział listy, odpowiadał „brak przerwy w dostawie”. Czyli dokładnie to samo, co wtedy, gdy przerwy naprawdę nie było.

Odbiorca dostawał uspokajającą wiadomość w sytuacji, w której nic nie zostało sprawdzone. Automatyzacja nie tylko przestała działać — zaczęła aktywnie wprowadzać w błąd, zachowując przy tym pozory pełnej sprawności. Gdyby po prostu przestała wysyłać maile, ktoś zauważyłby ciszę po kilku dniach. Tak nie zauważył nikt.

Rozwiązanie: trzecia odpowiedź

Model odczytujący zrzut zwraca teraz dwa dodatkowe pola: czy w ogóle widzi listę awarii — niezależnie od tego, co jest na niej wpisane — oraz krótki opis tego, co faktycznie widzi na obrazie.

Kluczowa jest wartość domyślna pierwszego pola. Brzmi ona „nie widzę”, nie „widzę”. To celowe ustawienie bezpiecznika w stronę alarmu: jeżeli odpowiedź modelu okaże się niemożliwa do odczytania, sam ten fakt jest sygnałem, że coś jest nie tak, więc ma trafić do gałęzi alarmowej, a nie do gałęzi „wszystko w porządku”. Domyślna odpowiedź automatu na własną niepewność powinna brzmieć „sprawdź mnie”, a nie „śpij spokojnie”.

Dzięki temu przepływ ma trzy zakończenia zamiast dwóch. Pierwsze: jest przerwa w dostawie — e-mail z datą i zakresem. Drugie: nie ma przerwy — e-mail potwierdzający. Trzecie: „PROBLEM: monitoring nie działa poprawnie” — osobna wiadomość, która wprost mówi, że to nie jest informacja o wodzie, tylko sygnał, że automat prawdopodobnie niczego nie sprawdził. Razem z opisem tego, co model widział na obrazie, i wskazówką, gdzie leży zrzut, żeby dało się zajrzeć własnymi oczami.

Wątek poboczny: automatyzacja działała, ale jej wynik nie docierał

Zanim to wszystko zaczęło mieć znaczenie, maile w ogóle nie dochodziły — odbijały się z błędem uwierzytelnienia nadawcy. Serwery pocztowe odbiorców odrzucały wiadomości, bo domena nadawcy nie miała skonfigurowanego podpisywania poczty. Trzeba było to ustawić po stronie domeny. Klasyczny przypadek automatyzacji, która „działa” w każdym możliwym pomiarze wewnętrznym, a mimo to jest bezużyteczna, bo jej wynik nie dociera do człowieka. Dlatego wdrożenie kończy się dopiero wtedy, gdy powiadomienie realnie ląduje w skrzynce odbiorcy — a nie wtedy, gdy przepływ świeci się na zielono.

Efekt

• 2 → 3 możliwe odpowiedzi automatu; trzecia brzmi „nie potrafiłem sprawdzić”,
• domyślna odpowiedź modelu na własną niepewność ustawiona w stronę alarmu, nie w stronę spokoju,
• osobny e-mail o niesprawności monitoringu, z opisem tego, co widział, i wskazówką gdzie sprawdzić,
• zrzut obejmuje całą stronę i powstaje po doładowaniu treści, więc lista jest na nim widoczna,
• poczta uwierzytelniona — powiadomienia docierają zamiast odbijać się od serwerów odbiorców.

Co z tego wynika dla firmy

Jeżeli kupujesz albo już masz automatyzację, która czegoś pilnuje, zadaj jej autorowi jedno pytanie: co się stanie, gdy ta automatyzacja nie będzie mogła wykonać swojego zadania? Jeżeli odpowiedź brzmi „nic” albo „nie wiem”, to znaczy, że w dniu awarii dostaniesz dokładnie tę samą uspokajającą wiadomość co zawsze.

Drugie pytanie jest jeszcze prostsze: kiedy ostatnio ta automatyzacja przysłała cokolwiek innego niż „wszystko w porządku”? Cisza i monotonia to nie jest dowód sprawności. Bywa dowodem, że nikt od pół roku niczego nie sprawdza.

Stack: n8n jako warstwa wykonawcza i harmonogram, zewnętrzna usługa robiąca zrzuty ekranu stron, model wizyjny odczytujący treść z obrazu, rozgałęzienie na trzy ścieżki, wysyłka przez uwierzytelnioną pocztę transakcyjną. Wdrożenie na własnej infrastrukturze.

Inne case studies