Odkrywanie wyników, których nikt nie czyta: audyt konsumenta dla systemów zautomatyzowanych

Każdy system automatyczny gromadzi prace, które wykonywane są poprawnie, ale nie mają żadnego znaczenia dla nikogo: raport regenerowany co noc, którego nikt nie otwiera, brama walidacyjna, która może zawieść, ale nigdy nie jest używana, zasada dodana do listy kontrolnej, której żaden proces tak naprawdę nie czyta. Żadna z tych rzeczy niczego не psuje, i to właśnie dlatego przetrwają. Ten artykuł opisuje, jak przeprowadzić audyt systemu generującego wyniki bez odbiorcy, co zwykle ujawnia takie badanie, trzy błędy, które powodują, że audyt niszczy zdrowe komponenty, oraz jeden element metadanych, który sprawia, że całe to działanie jest niemal bezkosztowe.

Zasada stojąca za audytem: każdy krok ma nadawcę i odbiorcę

Korzystną zasadą w przepływach pracy, niezależnie od tego, czy składają się one z zadań cron, kroków w procesach CI, czy łańcuchowych sesji agentów AI, jest wymaganie, aby każda jednostka pracy była połączona z obu stron. Coś w górę strumienia dostarcza jej kontekst i dane wejściowe; coś w dół strumienia odbiera to, co zostało wygenerowane. Krok, który prawidłowo otrzymuje dane, ale nic im nie przekazuje, nie wykonywa pracy użytecznej, nawet jeśli wszystko, co robi, jest poprawne.

Sformułowanie tej zasady jest proste. Jej sprawdzanie jest trudniejsze, ponieważ naruszenie nie pozostawia żadnych śladów. Audyt służy do wykrywania kroków, które wykonują jakieś sensowne działania, których rezultaty nigdy nie są wykorzystywane. Najlepiej sprawdza się wtedy, gdy jest przeprowadzany regularnie, na przykład jako część każdej retrospektywy, a nie tylko raz po incydencie związku z koniecznością uporządkowania.

Czego zwykle odkrywa uczciwy audyt

Załóżmy zespół, który używa silnie zautomatyzowanego procesu pracy opartego na agentach do przeprowadzenia tej audytoryjnej analizy we własnym zakresie. Wyniki nie były pomyślne, co właśnie sprawiło, że okazały się przydatne.

• Bramki, które nigdy się nie aktywują. Znaleziono 95 kontrol, które mogły zmienić kolor na czerwony, ale żadna z nich nigdy nie została uruchomiona. Każda z nich została prawidłowo wdrożona i przetestowana, a w momencie stworzenia wydawała się niezbędna, mimo to żadna z nich nie została włączona do żadnego szlaku działania.
• Zasady bez źródła wywołania. Spośród 25 niedawno przyjętych zasad 19, czyli 76%, nie miało żadnego odniesienia w żadnym szlaku kodu, liście kontrolnej ani rutynie. Problemem nie była nieposłuszeństwo – nic w ogóle na nie nie wskazywało. Jedna procedura debugowania pozostała w oficjalnym przewodniku zespołu przez 42 dni, nie będąc ani razu zastosowana. Nikt jej nie zapomniał – po prostu zapisanie jej pomyliło się z faktem jej przyjęcia.

Baza zadań pełna nieaktywnych pozycji. Aktualny licznik pokazywał 417 otwartych zadań, z których 146 nie wykazywało żadnej aktywności, a 104 nie miało określenia statusu ukończenia. Najstarsza, nienaruszona pozycja miała 37 dni.

Panel sterowania, którego nikt nie mógł zobaczyć. Panel sterujący procesem publikacji był aktualizowany przy każdej publikacji i przechowywany w umówionym miejscu. Jednak udostępnienie na maszynie produkcyjnej było skonfigurowane tylko na odbiór, więc nic zapisane tam nie było przekazywane dalej. Przez tygodnie był dokładny i aktualny, ale nikt inny go nie widział.

Ostatni przypadek w jednej linii podsumowuje lekcję: umieszczenie czegoś we właściwym miejscu to nie to samo, co jego dostarczenie.

Dlaczego awarie zawsze występują w najtrudniejszych momentach

Straty zazwyczaj występują na granicach między systemami, a nie jest to specyficzne tylko dla sztucznej inteligencji. Coś zostaje przekazane, ale nie jest przyjęte, albo jest przyjęte, lecz nie zauważone na czas. We wszystkich powyższych przypadkach strona produkująca funkcjonowała perfekcyjnie – autor pisał, licznik liczył, brama mogła otworzyć się. Brakowało jedynie określonego konsumenta.

Głównym problemem jest to, że nic się nie psuje, gdy brakuje konsumenta. Brak konsumpcji nie powoduje żadnego błędu, żadnego alertu ani żadnej linii w dzienniku. Producenci są monitorowani, ponieważ ich awarie są wyraźnie słyszalne; konsumentów rzadko monitoruje się, ponieważ ich brak pozostaje bezgłośny.

Dwa kolejne przypadki pokazują konsekwencje utrzymywania się tej ciszy:

• Przełącznik alarmowy buforował wiadomości dla operatora ludzkiego i obiecywał dostawę przy następnej udanej transmisji. W jednym węźle program zawsze kończył działanie przed uruchomieniem pierwszej linii logiki. 552 wiadomości czekało przez 16 dni. Producent funkcjonował prawidłowo, a trasa była poprawna, ale do konsumenta nigdy nie doszło.
• Publikzowany panel sterowania pokazywał 17 publikacji pochodzących z lustra, podczas gdy rejestr, który rzekomo odzwierciedlał te dane, nie istniał nigdzie w całym systemie. Ekran wiernie pokazywał to, co miał do zaoferowania. Nikt nie pytał, z czego faktycznie czerpie dane.

Oba problemy zostałyby wykryte podczas sprawdzenia po stronie odbiorczej: czy operator otrzymał coś, czy źródło danych w panelu sterowania rzeczywiście istnieje.

Trzy sposoby, w jakie może pójść nie tak audytu użytkowania

Naiwna wersja tej audytoryzacji, polegająca na „liczeniu, jak często jest używany każdy komponent, i usuwaniu tych, które dają wynik zero”, aktywnie szkodzi systemowi. Te trzy korekty adresują najczęstsze przyczyny jej błędów.

1. Mierz użycie, a nie wywołanie

Kuszące jest podłączenie licznika do oczywistego punktu wejścia, takiego jak wywołanie narzędzia, które ładuje umiejętność lub uruchamia skrypt. Jednak komponenty są często wykorzystywane pośrednio. Jeśli rutyny automatyczne jedynie czytają plik z informacjami o umiejętności, zamiast wywoływać narzędzie, które je obsługuje, licznik wywołań pokaże zero dla komponentu, który jest używany ciągle, a audytoryzacja uzna go za niesprawny.

Licz efekt, jaki komponent ma w dalszej części systemu, a nie punkt wejścia, który go uruchamia. Jeśli jest wykorzystywany jakiś raport, to w wyniku tego powinny ulec zmianie jakieś decyzje, zgłoszenia lub pliki w dalszej części systemu; to właśnie ta zmiana jest dowodem wartym zapisania.

2. Wydrukuj wiek danych i przestrzegaj okna czasowego

Komponent stworzony dziewięć dni temu nie może konkurować w porównaniu trwania użytkowania przez trzydzieści dni. Audyt musi wskazać, jak daleko sięgają jego dane, i nigdy nie może wydawać osądów na temat elementów powstałych przed rozpoczęciem okna obserwacji. Werdykt, który nie określa omawianego okresu, nie ma żadnej rzeczywistej mocy prawniczej i systematycznie kara te elementy, które zostały stworzone najpóźniej.

3. Wyłącz elementy, których wartością jest dostępność

Część artefaktów istnieje po to, by być gotowymi rozwiązaniami, a nie by być używanymi. Podręcznik postępowania w przypadku incydentu, który nigdy się nie wydarzył, powinien mieć zero wywołań. W tym przypadku właściwym pytaniem jest to, czy nadal funkcjonuje, a nie jak często był wywoływany. Zastosowanie metryki wykorzystania sprawi, że usuniesz dokładnie te materiały, których będziesz potrzebował w najgorszym dniu. Procedury przywracania po klęskach żywiołowych, konfiguracje awaryjne oraz rzadko używane narzędzia administracyjne należą do tej samej kategorii; testuj je regularnie, zamiast liczyć wywołania.

Głębsza pułapka: metryki, które mogą jedynie potwierdzać

Poza licznikami istnieje problem o znacznie głębszym charakterze. Wskaźnik, który może zmieniać się wyłącznie na korzyść stworzonego przez nas rozwiązania, nie stanowi dowodu. Audyt, który nigdy nie może zalecić wyłączenia procesu, jest w rzeczywistości jedynie raportem stanu pod inną nazwą. Zanim zaufasz wynikom, zastanów się, jaki rezultat skłoniłby cię do usunięcia czegoś, i sprawdź, czy taki rezultat jest rzeczywiście osiągalny.

Rozwiązanie: określ użytkownika w momencie powstania artefaktu

Najskuteczniejsze zmiany są małe. Dla każdego artefaktu – czy to bramka, reguła, raport, panel sterowania czy zadanie – zapisz jedną linię w momencie jego stworzenia, a nie podczas audytu: kto go używa oraz jaka zmiana stanu potwierdza, że został on wykorzystany.

Każda z opisanych powyżej awarii ma swoje źródło w nierozwiązaniu tego pytania już od samego początku, a każde późniejsze rozwiązanie kosztuje więcej niż odpowiedź na nie. Oto kilka praktycznych sposobów na egzekwowanie tego wymogu:

• dodanie obowiązkowego pola „consumer” do szablonów nowych zadań, reguł i zadań zaplanowanych
• Odrzucenie definicji zakończenia pracy, które opisują jedynie działanie producenta („panel sterowania zaktualizowany”) bez wskazania odbiorcy („panel sterowania widoczny dla osoby pełniącej dyżur”)
• w przypadku czegokolwiek przekazywanego przez granicę, taką jak udostępnienie, kolejka lub przekaźnik, konieczne jest sprawdzenie po stronie odbierającej, a nie tylko wysyłającej

Gdy to pole już istnieje, audyt nie wymaga już pracy detektywistycznej. Wystarczy zapytać o elementy z pustym wpisem w polu consumer; ta lista jest wynikiem i mogła zostać odczytana w dowolnym momencie.

Główne wnioski

• Dane wyjściowe bez wskazanego odbiorcy są domyślnie niewidoczne, ponieważ nic się nie psuje, gdy nikt ich nie czyta.
• Błędy występują głównie przy przekazywaniu danych, dlatego należy sprawdzić ich dostarczenie po stronie odbierającej.

Licz liczbę zmian stanu spowodowanych konsumpcją, a nie wywołaniami punktu wejścia.

Raportuj okno czasowe danych, nigdy nie oceniaj komponentów młodszych od niego i testuj artefakty dotyczące wyłącznie dostępności zamiast liczyć ich użycie.

Zapisz „kto to konsumuje i skąd to wiemy”, gdy tworzony jest artefakt; wtedy audyt kosztuje prawie nic.