Dziś o 9:16 dostałem maila z porannym podsumowaniem dnia: co w kalendarzu, które wiadomości czekają, co zalega. Zwykła rzecz, mój asystent AI miał mi to wysyłać codziennie. Tyle że poprzedni taki mail przyszedł 6 kwietnia. Przez prawie pół roku zadanie uruchamiało się co rano, kończyło pracę i zostawiało w harmonogramie ten sam wpis: operacja zakończona pomyślnie. Ani jednego błędu. Ani jednego raportu.
Najgorsze, że nawet za nim nie zatęskniłem. Prowadzę małą firmę, która wdraża automatyzację i AI w innych małych firmach, a to, co radzę klientom, najpierw testuję na sobie. Ten test wypadł słabo: w ostatnich trzech tygodniach znalazłem u siebie pięć automatów, które pracowały na niby. Każdy wyglądał na żywy. Żaden niczego nie robił.
Spis treści
- Co właściwie znaczy „zakończone sukcesem”?
- Ile moich automatów pracowało na niby?
- Dlaczego nikt tego nie zauważył, skoro monitoring świecił na zielono?
- Jak wygląda czujnik, który krzyczy?
- Co zepsułem już po naprawie?
- Jak sprawdzić własne automaty w jedno popołudnie?
- Słownik pojęć
Co właściwie znaczy „zakończone sukcesem”?
Każdy program, kończąc pracę, zostawia po sobie jedną liczbę. Zero znaczy „skończyłem bez awarii”, cokolwiek innego znaczy „coś poszło źle”. To jest kod wyjścia i na nim opiera się większość harmonogramów, od windowsowego po serwerowe. Widzą zero, wpisują sukces.
Problem w tym, że zero odpowiada na inne pytanie, niż Ci się wydaje. Najprościej porównać je do karty zegarowej. Pracownik przyszedł, odbił kartę, wyszedł, odbił kartę. System kadrowy pokazuje pełną dniówkę. Czy cokolwiek w tym czasie zrobił? Karta tego nie wie i nigdy nie twierdziła, że wie.
Z automatami jest tak samo. Program może uruchomić się, nie znaleźć pliku, złapać własny błąd, grzecznie go przemilczeć i wyjść z zerem. Może też w ogóle nie dojść do właściwej pracy, bo ktoś uciął mu ostatnią linijkę. Zero dostaniesz w obu przypadkach.
Kto pracuje z modelami językowymi, zna to z innej strony. AI odpowiada tym samym pewnym tonem, kiedy ma rację i kiedy zmyśla. Ton nie jest dowodem. Kod wyjścia jest właśnie takim tonem: brzmi przekonująco i z treścią nie ma wiele wspólnego.
Ile moich automatów pracowało na niby?
W połowie września zrobiłem przegląd całego systemu, na którym stoi moja firma: asystent, pamięć, skrzynki, serwery. Dziewięć obszarów, każdy z jednym pytaniem: czy to naprawdę działa, czy tylko jest zainstalowane. Potem przez trzy tygodnie wypadały kolejne trupy z szafy. Wszystkie pięć przypadków jest z mojej firmy, żaden od klienta.
Przypomnienia, które przestały wychodzić w marcu
Mam system follow-upów, o którym pisałem tu wiosną z niemałą dumą. Po każdym wysłanym mailu dopisuje przypomnienie, a osobne zadanie codziennie o 8:00 miało te przypomnienia wysyłać. Dopisywanie działało bez zarzutu. Wysyłka stanęła pod koniec marca.
Zadanie startowało każdego ranka i każdego ranka się wywracało. Tutaj kod wyjścia akurat mówił prawdę, bo w harmonogramie stał kod błędu. Nikt go nie czytał przez sześć miesięcy, ja też nie, bo w kolumnie „ostatnie uruchomienie” widniała dzisiejsza data i to mi wystarczało. Kiedy w końcu zajrzałem, w kolejce czekało 178 zaległych przypomnień, a najstarsze miało 196 dni.
Blog, który „publikował” codziennie o 7:30
Ten blog ma swój automat. Między 6 sierpnia a 28 września uruchomił się ponad pięćdziesiąt razy i za każdym razem kończył tym samym błędem: nie znajdował programu, który miał wywołać. Harmonogram pokazywał zero, bo plik startowy, przez który przechodziło uruchomienie, połykał kod błędu i oddawał dalej sukces. Prawdę znał tylko plik z logiem, do którego nikt nie zaglądał.
Przez siedem tygodni nie ukazał się tu ani jeden tekst. Zorientowałem się, kiedy sam wszedłem na stronę.
Skrypt bez ostatniej linijki
18 września wgrywałem na serwer poprawkę skryptu, który przenosi maile na moją tablicę zadań. Przy kopiowaniu urwał się koniec pliku, akurat ta linijka, która mówi „a teraz uruchom to wszystko”. Skrypt startował co kwadrans, wczytywał definicje, nie wywoływał żadnej i kończył z zerem. Dwadzieścia osiem razy w siedem godzin.
Sprawdziłem po wgraniu sumę kontrolną i zgadzała się idealnie. Suma dowodzi jednak tylko tego, że na serwerze leży dokładnie to, co mam u siebie. Wiernie skopiowałem uszkodzony plik. Wykrył to nie monitoring, tylko moje oko: na tablicy było 16 pozycji, a powinno być 29, i coś mi nie pasowało.
Kontener, który zmienił nazwę
W czerwcu zmieniłem nazwę jednej z naszych aplikacji na serwerze. Zadanie, które co noc zamykało w niej przeterminowane oferty, dalej wołało starą nazwę. Aplikacji o takiej nazwie już nie było, więc polecenie nie miało czego wykonać, ale dla harmonogramu noc w noc kończyło się zerem. Wyszło to dopiero teraz, przy porządkach, po ponad trzech miesiącach.
Raport, od którego zacząłem
Poranne podsumowanie padło z najbardziej prozaicznego powodu. Skrypt był napisany ostrożnie: każdą sekcję otaczał zabezpieczeniem „jak coś pęknie, nie przerywaj”. Brzmi rozsądnie. W praktyce oznaczało to, że kiedy pękało wszystko po kolei, skrypt dochodził do końca z pustymi rękami i meldował sukces. Do tego uruchamiał się w trybie bez okna, w którym nie ma gdzie wypisać komunikatu o błędzie, więc nawet narzekać nie miał jak.
Po naprawie zasada jest odwrotna. Sekcja, która się nie uda, trafia do raportu jako „niedostępne”, a jeśli nie uda się wysyłka, skrypt kończy z błędem i zostawia ślad w logu. Ma prawo zawieść. Nie ma prawa udawać.
Dlaczego nikt tego nie zauważył, skoro monitoring świecił na zielono?
Bo monitoring mam, i to porządny. W dniu przeglądu pokazywał 112 sprawdzanych punktów, 112 na zielono, zero alarmów. Serwery odpowiadały, poczta chodziła, strony klientów stały. A w tym samym czasie kopia zapasowa wysyłana poza budynek nie działała od 23 dni i żaden wskaźnik tego nie widział, bo nikt nigdy nie kazał mu na to patrzeć. O samych kopiach napisałem osobno, w tekście o tym, że backup, którego nikt nie otworzył, nie jest backupem.
Zielony panel mówi tylko tyle, że działa to, co kazałeś mierzyć. Ja kazałem mierzyć maszyny. Nie kazałem mierzyć roboty.
Jest też drugi powód, mniej techniczny. Awaria serwera boli od razu, bo ktoś dzwoni, że strona nie działa. Automat, który przestał wysyłać przypomnienia, nie boli nikogo. Przypomnienie, które nie przyszło, nie zostawia pustego miejsca na biurku. Klient, któremu nie przypomniałem o ofercie, nie napisze „czemu pan mi nie przypomina”. Brak czegoś, na co nikt nie czeka, jest niewidzialny.
Szczerze? Było mi głupio. Zawodowo tłumaczę ludziom, że automat trzeba nadzorować, a u siebie miałem pięć takich, których nie nadzorował nikt.
W całym przeglądzie powtarzał się jeden wzór. To, co pilnował kod, żyło: nadawca maila jest wymuszony w funkcji wysyłającej, więc nigdy się nie pomylił. To, co zależało od „pamiętaj i zrób”, chorowało. Reguł miałem aż nadto, spisanych w kilku miejscach naraz. Żadna nie krzyczała, kiedy przestawała być wykonywana.
Jak wygląda czujnik, który krzyczy?
Jeszcze tego samego wieczoru, 14 września, powstał mały program, który nazywam kolektorem zdrowia. Nie pyta, czy zadanie się uruchomiło. Pyta o ślad, który zostaje po zrobionej robocie.
Różnicę najlepiej widać na przykładach. Dla bloga czujnik nie sprawdza, czy automat wystartował o 7:30, tylko ile tekstów z harmonogramu zalega dłużej niż dwa dni. Dla skrzynki patrzy na wiek znacznika ostatniego przeglądu. Dla kopii zapasowej na datę ostatniej udanej. Dla przypomnień na wiek najstarszego w kolejce. Każde z tych pytań da się zadać bez wiedzy o tym, jak automat jest zbudowany, i każde ma odpowiedź w postaci liczby: ile godzin albo dni minęło, odkąd coś naprawdę zostało zrobione.
Pierwszy pomiar potwierdził to, co wyszło w przeglądzie: cztery czujniki na czerwono, cztery na żółto, jeden zielony. Kiepski wynik, ale pierwszy raz był to wynik, a nie przeczucie.
Co pół godziny odczyty lecą do tego samego panelu, który pilnuje serwerów. Nie stawiałem nowego narzędzia, bo kolejny ekran do oglądania skończyłby jak poranny raport. Dopisałem dwa alarmy. Pierwszy odzywa się, gdy któryś proces stanie. Drugi, gdy sam kolektor zamilknie na dłużej niż dwie godziny, bo strażnik, którego nikt nie pilnuje, jest tylko kolejnym automatem do cichej śmierci.
Alarm też trzeba sprawdzić skutkiem
Kilka dni później budowałem podobny czujnik na serwerze i wpadłem we własne sidła. Alarm miał iść mailem, systemowym poleceniem do wysyłki. Polecenie kończyło się zerem. Dopiero w logu serwera pocztowego stało czarno na białym, że ta maszyna w ogóle nie wysyła poczty na zewnątrz. Alarm ginąłby po cichu, dokładnie tak jak awarie, które miał zgłaszać.
Od tamtej pory czujnik uznaję za gotowy dopiero wtedy, gdy sztucznie wywołam alarm i zobaczę go u siebie w skrzynce. Cofam znacznik o dwa dni, czekam, aż zadzwoni. Jeśli nie zadzwoni, to nie mam czujnika, tylko jego atrapę.
Dziś czujników jest piętnaście. Ten od przypomnień pokazał 178 zaległych, z czego 151 starszych niż miesiąc poszło do archiwum, zostało 27 żywych. Automatyczną wysyłkę przypomnień do klientów wyłączyłem zresztą świadomie. Po pół roku przerwy nie chciałem, żeby maszyna nagle sama zasypała ludzi ponagleniami w sprawach, które dawno się rozwiązały.
Co zepsułem już po naprawie?
Chciałbym napisać, że od 14 września jest porządek. Nie jest, i to z mojej winy.
Tego samego wieczoru, kiedy spisałem sobie zasadę „egzekwuj kodem, nie pamięcią”, założyłem dziennik działań, które asystent wykonuje samodzielnie. I oparłem go na pamiętaniu: po każdej takiej akcji miał być ręcznie dopisywany wpis. Ostatni wpis pojawił się 15 września. Dziennik umarł po jednym dniu, a ja zauważyłem to dziesięć dni później, przy drugim przeglądzie. Dziś dopisuje go sama funkcja wysyłająca maile i nikt nie musi o niczym pamiętać.
Druga wpadka jest świeża, z dzisiaj. Czujnik bloga podniósł alarm, że automat nie startuje od dwóch dni. Automat startował normalnie. To czujnik źle czytał nagłówek w logu, bo poprzedzał go zabłąkany znak po przerwanym przebiegu. Fałszywy alarm to osobny kłopot i jeszcze do niego wrócę w innym tekście, ale tu przyznam jedno: wolę czujnik, który raz krzyknie niepotrzebnie, od takiego, który pół roku milczy.
I trzecia rzecz, starsza, ale z tej samej rodziny. W sierpniu wyszło, że funkcja sprawdzająca ważność certyfikatów miała na sztywno wpisany adres, pod którym jedna z naszych maszyn nie odpowiadała. Zamiast zgłosić „nie umiem sprawdzić”, zwracała pustą odpowiedź, a pusta odpowiedź nie zapalała żadnej lampki. Certyfikat na tej maszynie był nieważny od piętnastu miesięcy. Takie lekcje lądują w rejestrze luk, a ta brzmi: sprawdź, co funkcja zwraca, kiedy jej się nie uda. Jeśli zwraca ciszę, to nie masz monitoringu.
Jak sprawdzić własne automaty w jedno popołudnie?
Nie potrzebujesz do tego ani mojego kolektora, ani programisty na etacie. W firmie na 10 - 50 osób takich cichych automatów jest zwykle kilka do kilkunastu: eksport do księgowości, kopia bazy, synchronizacja sklepu z magazynem, cotygodniowy raport sprzedaży, przypomnienia o płatnościach. Wystarczy kartka i kilka pytań.
- Spisz wszystko, co w firmie „robi się samo”. Także to, co ktoś ustawił trzy lata temu i odszedł. Sama lista bywa zaskoczeniem.
- Przy każdej pozycji zapisz, jaki ślad zostaje po zrobionej robocie. Plik z dzisiejszą datą, nowy wiersz w tabeli, mail w skrzynce, liczba w raporcie. Jeżeli nie umiesz wskazać śladu, nie masz jak sprawdzić, czy automat żyje.
- Sprawdź datę tego śladu, nie datę uruchomienia. „Ostatnio uruchomione: dziś” nic nie znaczy. „Ostatni plik kopii: z sierpnia” znaczy wszystko.
- Policz, zamiast zerkać. Ile faktur wyszło z systemu sprzedaży, a ile dotarło do księgowości? Mnie uratowało 16 zamiast 29 na tablicy.
- Ustal, kto ma się dowiedzieć, gdy ślad się zestarzeje, i jak. Najprostszy czujnik to przypomnienie w kalendarzu konkretnej osoby: w poniedziałek otwórz folder i sprawdź datę. Lepszy to skrypt, który sam wyśle wiadomość.
- Raz zepsuj coś celowo. Wyłącz zadanie na dzień i zobacz, czy ktokolwiek się zorientuje. Jeśli nikt, masz odpowiedź.
Jedna uwaga do ostatniego punktu: rób to na czymś, co da się nadrobić następnego dnia. Raport tak, przelewy nie.
Kiedy doradzam, który proces zautomatyzować jako pierwszy, patrzę na powtarzalność, wolumen i koszt błędu. Po tych trzech tygodniach dopisałem czwarte pytanie: po czym poznamy, że to przestało działać? Jeśli nie ma na to odpowiedzi, automat nie jest skończony, choćby działał pięknie w dniu odbioru.
Słownik pojęć
- Kod wyjścia - liczba, którą program zostawia po zakończeniu pracy. Zero oznacza, że nie zgłosił awarii. Nie oznacza, że zrobił to, po co został uruchomiony.
- Harmonogram zadań - narzędzie systemu, które uruchamia programy o ustalonych porach. W Windows nazywa się Harmonogram zadań, na serwerach linuksowych najczęściej cron.
- Healthcheck - automatyczne sprawdzenie, czy coś żyje. Dobry mierzy skutek pracy, na przykład wiek ostatniego wyniku, a nie sam fakt uruchomienia.
- Log - plik, do którego program zapisuje, co robił i co mu nie wyszło. Często jedyne miejsce, gdzie widać prawdę.
- Suma kontrolna - krótki „odcisk palca” pliku. Dwa pliki o tej samej sumie są identyczne, co nie znaczy, że są poprawne.
Masz automat, o którym od dawna nic nie słyszałeś?
Cisza bywa dobrym znakiem, ale równie często znaczy, że coś umarło i nikt nie zgłosił zgonu. Jeśli chcesz przejść swoją listę z kimś, kto właśnie odkopał pięć własnych trupów, napisz na [email protected]. Zaczniemy od pytania o ślad, nie od narzędzi.
własnej firmie cybulski.ai JC
