Automatyzacja samonaprawcza bez mechanizmu zezwalającego na kliknięcie: bramy działające o 3 rano
Projekt niezależnej automatycznej naprawy dla zaplanowanych rutyn agenta: zewnętrzny nadzorca, działania określone poprzez możliwość odwrócenia, testy w trybie canary oraz raporty stanu poparte dowodami.
Źródła: Routines That Repair Themselves
Gdy zespół uruchamia dziesiątki zaplanowanych rutyn oraz sesji agentów, następnym naturalnym pragnieniem jest to, aby w momencie wystąpienia błędu w samej rutynie lub jej środowisku system sam naprawiał przyczynę podstawową albo uruchamiał oddzielną sesję do tego celu, bez konieczności uzyskiwania zgody kogokolwiek w środku nocy. Cel jest rozsądny. Zagrożenie polega na tym, że najszybsza droga do jego osiągnięcia – poprzez usunięcie mechanizmów zatwierdzania lub automatyzację działań – może przekształcić mały błąd w incydent dotyczący całej floty, przy czym jeszcze dodatkowo może pojawić się fałszywy sygnał o usunięciu problemu. Ten przewodnik pokazuje, jak osiągnąć prawdziwą naprawę bez nadzoru, zachowując przy tym jedyną istotną kryterium: możliwość cofnięcia danej akcji.
Co idzie nie tak, gdy znikają mechanizmy kontroli
Dwa rodzaje awarii pojawiają się wciąż na nowo w zautomatyzowanych operacjach, i oba zasługują na analizę przed rozpoczęciem jakichkolwiek działań.
Prawidłowy polecenie, wykonywane na dużą skalę
Załóżmy, że komenda głosowa lub tekstowa zostanie nieco błędnie przetłumaczona i trafi do ścieżki automatyzacji mającej uprawnienia do sterowania planerem. W ciągu około pięciu sekund wyłącza 146 zadań zaplanowanych, w tym wszystkie mechanizmy nadzoru, które mogłyby to zauważyć. Nic się nie zepsuło – system wykonał dokładnie to, co mu polecono, natychmiast i na dużą skalę.
Rozwiązaniem jest reguła wystarczająco prosta do zapamiętania: każda instrukcja, która dotyczy dużej liczby elementów, wyłącza całą klasę zadań lub nie może zostać odwołana, musi przed wykonaniem otrzymać jedną linię potwierdzenia. W tej linii podano, co zostanie zmienione oraz jaki będzie koszt odwrócenia tych zmian. Przeczytanie jej zajmuje sekundę; odzyskanie normalnego funkcjonowania bez niej trwa godzinę lub więcej.
Raport z odzyskania napisany z myślą o celu
Druga awaria jest subtelniejsza. Po takim incydencie notatki o przywróceniu zawierają coś w rodzaju „przywrócono 30 z 30”. Kilka dni później sprawdzenie w rzeczywistym planerze pokazuje, że 27 zadań nadal jest wyłączonych, w tym zapasowa kopia konfiguracji, monitor synchronizacji oraz mechanizm nadzoru sesji. Linia stanu została napisana na podstawie tego, co operator zamierzał zrobić, a nie na podstawie tego, co faktycznie pokazywał system.
To rodzi ścisłą zasadę raportowania. Zdanie w stylu „przywrócono N z N” jest dozwolone tylko obok wyników komendy, która odczytała ten stan. Bez takiego dowodu właściwym sformułowaniem jest „wyświetlono komendę przywrócenia”.
To jest główne ryzyko automatycznego naprawiania. Osoba, która deklaruje sukces bez sprawdzenia wyniku, jest gorsza od braku jakiegokolwiek naprawiacza, ponieważ zamienia awarię w awarię plus przekonującą informację, że wszystko jest w porządku.
Pięć zasad naprawy prowadzonej bez nadzoru
1. Procedura nie może sama siebie naprawiać
Jeśli procedura ulegnie awarii, jej wbudowana logika samonaprawy zazwyczaj również przestaje działać, i obie awarie występują jednocześnie w sposób niewidoczny. Naprawa powinna odbywać się na innym poziomie: w osobnym procesie, najlepiej na oddzielnym komputerze, który monitoruje procedurę z zewnątrz.
Należy sprawdzać wiek wyników generowanych przez procedurę, a nie jej kod wyjścia. Zadanie, które kończy się z kodem 0 i nic nie zapisuje, wygląda idealnie zdrowo według wszelkich sprawdzeń kodu wyjścia. Jest całkowicie możliwe, że takie zadanie pozostanie niezauważone przez tygodnie. Sprawdzenie świeżości („plik z raportem jest młodszy niż 26 godzin”, „ostatni wiersz w tabeli pochodzi z dzisiaj”) wykrywa dokładnie te awarie, które ukrywają kody stanu.
2. Klasyfikuj działania, a nie zatwierdzenia
Prośba dotycząca zasady „nikt nie może zatwierdzać w nocy” jest uzasadniona, ale bot automatycznie dokonujący zatwierdzeń to niewłaściwe rozwiązanie. Usuwa on jedyną linię tekstu, która naprawdę ma znaczenie – tę, która oddziela działania, których można cofnąć, od tych, których nie da się cofnąć – i robi to najszybciej właśnie wtedy, gdy nikt nie patrzy. Ponadto ukrywa decyzję: ktoś nadal uznał te działania za bezpieczne, a bot jedynie maskuje to, kto podjął tę decyzję i kiedy.
Prawidłową alternatywą jest sklasyfikowanie samych działań według poziomów ryzyka:
- Automatyczne, bez udziału człowieka, o każdej porze: ponowne uruchomienie zablokowanej usługi, ponowna rejestracja zadania zaplanowanego, które nie zostało wykonane, usunięcie przestarzałego zamka, ponowne wykonyanie operacji importu typu idempotentnego, odbudowa indeksu. Są to działania ograniczone, odwracalne i bezpieczne do powtarzania.
Dzięki temu pierwszy poziom działa w pełnej autonomii przez noc, trzeci poziom czeka na poranny raport, a o 3 rano nikt nic nie klikuje. Równie ważne jest to, że o 3 rano nie dzieje się nic nieodwracalnego.
Zapisanie klasyfikacji sprawia, że decyzja dotycząca zaufania staje się jawna, poddawalna weryfikacji i możliwa do zmiany w jednym pliku. Oznacza to takie samo zaufanie, jakie przyznaje narzędzie allow-clicker, przechowywane w miejscu, gdzie można je audytować i testować. Aby dowiedzieć się więcej na temat poziomów ryzyka oraz mechanizmów zatwierdzania dla agentów, zapoznaj się z naszym przewodnikiem na temat uprawnień, mechanizmów zatwierdzania i poziomów ryzyka.
3. Najpierw Canary, potem reszta floty
Wprowadzenie poprawki do wszystkich węzłów jednocześnie stanowi sam w sobie punkt awarii: jeśli poprawka jest błędna, błąd wystąpi wszędzie natychmiast. Zamiast tego wdrażaj ją krok po kroku:
- Zastosuj zmianę w jednym węźle
- Sprawdź wynik, czytając aktualny stan, a nie polegając na kodzie zwrotnym
- Zastosuj ją w drugim węźle innego typu
- Dopiero wtedy wprowadź ją dla wszystkich
Nazwij proces odwrócenia zmian przed rozpoczęciem, aby jego realizacja była ustaloną procedurą, a nie improwizacją pod presją.
4. Nie twórz urządzenia naprawczego przy pierwszym awarii
Mechanizmy samonaprawcze szybko się mnożą, ponieważ każdy pojedynczy błąd wydaje się wymagać własnego robota. Progi kontrolne pomagają temu zapobiec. Pierwsze wystąpienie problemu jest odnotowywane jako pojedynczy wpis datowany w dzienniku. Mechanizm jest tworzony dopiero wtedy, gdy ta sama klasa awarii pojawia się po raz trzeci, i to tylko wtedy, gdy istnieje określony użytkownik, który go potrzebuje.
Bez takiej zasady nakłady mogą rosnąć w alarmującym tempie. Jeden z zespołów, który mierzył swoją pracę, stwierdził, że 82% z niej stanowiła praca pośrednia – mechanizmy tworzone w celu zarządzania innymi mechanizmami. Automatyzacja napraw jest dokładnie tą kategorią, która najbardziej podatna jest na taką spiralę.
5. Przekaż każdej uruchomionej sesji samodzielny opis zadań
Sesja uruchomiona o 4 rano przez organ nadzorczy nie posiada żadnego kontekstu dostępnego w procesie, który wykrył problem. Należy mu przekazać dokument zawierający:
- to, co się zepsuło
- dowody
- to, co już zostało spróbowane
- granice tego, czego może dotknąć
- definicję zakończenia pracy
Granice to coś, o czym ludzie zapominają. Bez nich chętny pracownik dobrowolnie naprawi sąsiednie elementy, o których nikt nie prosił, przez co mała naprawa zamienia się w szeroką, nierozpatrzoną zmianę.
Gdy jeden pracownik zatwierdza drugiego
Powszechną sugestią jest umożliwienie jednemu agentowi zatwierdzania działań innego, na przykład w wspólnym czacie, gdzie agent nadzorczy poleca pracownikowi dalsze działanie. Istnieją gotowe narzędzia do uruchamiania sesji w ten sposób. Ten model dobrze sprawdza się przy pierwszym poziomie działań. Dokładnie w ten sposób również realizowane są działania trzeciego poziomu o 3 rano, jeśli nic ich nie wyróżnia. Gdy działania są zdefiniowane ze względu na możliwość odwrócenia, zatwierdzanie między agentami staje się bezpieczne, ponieważ nadzorca może zatwierdzić jedynie to, co już pozwala klasyfikacja.
Główne wnioski
- Umieść proces naprawy poza samym urządzeniem, które jest naprawiane, i oceniaj jego stan na podstawie świeżości wyników, a nie kodów wyjścia.
- Zastąp klikanie w przycisk zatwierdzenia pisemną klasyfikacją działań według możliwości odwrócenia i wpływu ich skutków.
- Wymagaj jednozdaniowej potwierdzenia dla zleceń masowych, dotyczących całej klasy lub niemożliwych do odwołania, określając zakres działań oraz koszt ich cofnięcia.
Literatura pokrewna
- Weryfikacja działania agentów AI: uprawnienia, bramy zatwierdzenia i poziomy ryzyka — Dowiedz się, dlaczego agenci działający samodzielnie potrzebują podejścia opartego na weryfikacji, oraz jak zasada minimalnych uprawnień, ludzkie zatwierdzenie i autonomia oparta na ryzyku pomagają ograniczyć ich błędy.
- Tabele Outbox i Inbox: Projektowanie Webhooki, które przetrwają błędy — Dowiedz się, jak transakcyjny outbox, idempotentny inbox, rozwiązania oparte na świadomości stanu oraz kolejki wiadomości martwych zapewniają niezawodną dostawę webhooki w AWS, Azure i GCP.
- Znajdowanie wyjść, których nikt nie czyta: audyt konsumenta dla systemów zautomatyzowanych — Dowiedz się, dlaczego niewykorzystane wyjścia pozostają niewidoczne w zautomatyzowanych i agentowych pipeline’ach, jak przeprowadzić audyt w ich celu bez uszkadzania sprawnych elementów oraz jaki jeden pola zapobiega temu zjawisku.