Logi, które agent czyta, a człowiek rozumie

Wyobraź sobie małą firmę logistyczną, której asystent od miesiąca po cichu przekłada dostawy. Któregoś ranka dzwoni klient w sprawie auta, które nigdy nie przyjechało. Właściciel pyta asystenta, co się stało, a asystent pewnym tonem opowiada ciąg zdarzeń, który może, ale nie musi, odpowiadać temu, co system zrobił.

Właściciel otwiera logi. Jedna usługa pisała zwykłe zdania. Druga pisała JSON z nazwami pól, które rozpoznaje tylko jej autor. Trzecia zrotowała plik w nocy i godziny, o którą chodzi, już nie ma. Agent, który faktycznie przesunął dostawę, działał we własnej piaskownicy, a jego zapis jest gdzieś tam, przeplatany tysiącem linii bicia serca usług.

Dwóch czytelników chciało tej samej odpowiedzi. Człowiek chciał wiedzieć, co się stało i czy ufać relacji asystenta. SI chciała przeczytać ten sam zapis, żeby ustalić, co zrobiła, i zrobić to lepiej następnym razem. Żadne z nich nie mogło.

Prawdziwa przyczyna

Logi w większości systemów zostały pomyślane jako pomoc w debugowaniu dla programisty, który napisał usługę, i nigdy nie zostały zaprojektowane na nowo, gdy zmienili się czytelnicy. W systemie, w którym agenci SI są pełnoprawnymi użytkownikami, log jest dwiema rzeczami naraz: interfejsem, który agent czyta równie łatwo jak plik, i dowodem, po który sięga człowiek, gdy przestaje ufać opowieści agenta. Nikt nie zdecydował, jak zapis ma wyglądać dla obojga, więc nie wygląda jak żaden z nich.

Dlaczego logi zawodzą obu czytelników

Każda usługa ma własny dialekt. Znaczniki czasu w trzech formatach, poziomy ważności, które znaczą co innego, pole „user” w jednym miejscu i „principal” w drugim. Człowiek uczy się dialektów powoli; agent parsuje je źle i nigdy tego nie zauważa.

Proza, którą czyta tylko człowiek. „Połączenie z usługą synchronizacji znowu się chwieje” wystarczy koledze. Dla agenta to szum bez pola, na którym mógłby zadziałać, a dzień później nikt nie pamięta, do czego odnosiło się „znowu”.

Zapisy, które da się edytować. Plik logu, do którego każdy proces może dopisywać, można też uciąć, przepisać albo zrotować w niebyt. Dowód, który da się zmienić po fakcie, nie jest dowodem, a agent, który może edytować własny zapis, ma jak ukryć błąd.

Brak związku między działaniem a sprawcą. Linia mówi, że plik został przeniesiony. Nie mówi, który agent, w której KyberCell, na czyje polecenie. Bez tego łańcucha człowiek nie odpowie na pytanie „kto to zrobił”, a agent nie nauczy się z własnej historii.

Retencja ustalona przez domyślne ustawienie. Siedem dni w jednej usłudze, wiecznie w drugiej, a o reszcie decyduje pełny dysk. Właściciel nigdy nie wybierał i godzina, o którą chodzi, znika dokładnie wtedy, gdy jest potrzebna.

Prywatna pamięć wyciekająca do zapisu. Najłatwiej zalogować, co agent zrobił, logując, co widział: prompt, dokument, zawartość pamięci asystenta. Wtedy log staje się najbardziej wrażliwym plikiem na maszynie, kopiowanym wszędzie tam, gdzie kopiuje się logi.

Jak powinien wyglądać log dla dwóch czytelników

KyberLinux traktuje log jako element projektu systemu, a nie skutek uboczny uruchomionych usług. Zamiar jest taki, by istniał jeden zapis, na którym mogą polegać oboje czytelnicy.

Ustrukturyzowany, z jednym słownikiem. Każde zdarzenie to rekord z tymi samymi polami: kiedy, które urządzenie, która usługa, która cela, który agent, co zrobił, na czym, na czyje polecenie. Te same nazwy na opasce, w robocie i na węźle w serwerowni, bo to jeden system od nadgarstka do serwerowni, a agent, który nauczył się czytać logi na jednym, nie powinien uczyć się od nowa na następnym.

Tylko dopisywanie. Zapisany rekord nie może być zmieniony ani usunięty przez proces, który go napisał, ani przez agenta, którego działania opisuje. Rotacja i kasowanie są aktem właściciela, a nie skutkiem pełnego dysku.

Cela jest jednostką odpowiedzialności. Każda KyberCell pisze własny strumień: co agent mógł widzieć, czego dotknął, jakie reguły sieciowe obowiązywały, o co poprosił i czego mu odmówiono. Tak KyberLinux trzyma rój w celach, a log jest miejscem, w którym ta izolacja staje się widoczna po fakcie.

Czytelny dwa razy. Ten sam rekord ma dwa widoki: zdarzenia strukturalne dla agenta i prostą oś czasu dla człowieka, w jego języku, z objaśnionymi nazwami pól. Jedno źródło, dwa widoki, żeby żaden z czytelników nie pracował na innej prawdzie.

Retencja, którą ustala właściciel. Jak długo rekord żyje, dokąd trafia i czy w ogóle opuszcza urządzenie, to ustawienia z nazwiskiem właściciela. Domyślnie zostaje na urządzeniu, a system mówi we własnym statusie, co przechowuje i jak długo.

Czego nigdy nie wolno logować

Tu dwaj czytelnicy kłócą się najbardziej. Agent uczyłby się najszybciej z zapisu wszystkiego, co widział. Człowiekowi dokładnie taki zapis służy najgorzej, bo staje się kopią jego prywatnego życia.

Zasada jest więc taka, że log zawiera kształt tego, co się stało, nigdy zawartość prywatnej pamięci. Że dokument został przeczytany, nie jego tekst. Że wiadomość została wysłana i na jaki adres, nie co w niej było. Że asystent sięgnął do długiej pamięci, nie co ta pamięć zawiera. Środowisko uruchomieniowe SI i cele mają to egzekwować na granicy, tak by usługa nie mogła zalogować promptu przez przypadek. Tam, gdzie człowiek potrzebuje treści, by zrozumieć zdarzenie, log wskazuje, gdzie ta treść leży, pod kontrolą właściciela, zamiast nieść jej kopię.

Agenta to coś kosztuje. Uczy się z chudszego zapisu, niż by chciał. Uważamy, że to właściwa wymiana i ta, którą wybrałby właściciel, gdyby go zapytać.

Granica jest prosta: nic z tego dziś nie działa. KyberLinux jest przed startem, format logu jest projektem, a pierwsze wydanie zdecyduje, ile z niego trafi do niego od razu. Nie ma narzędzia do zainstalowania i nic z opisanego tu nie było testowane na prawdziwej flocie.

Test, który możesz zrobić dziś

Wybierz jedną rzecz, którą Twój obecny asystent albo automatyzacja zrobiły w tym tygodniu z widocznym skutkiem: wysłaną wiadomość, przeniesiony plik, zmieniony wpis w kalendarzu. Teraz spróbuj odpowiedzieć, tylko z logów i bez pytania asystenta, na cztery pytania. Kiedy dokładnie to się stało? Który element to zrobił? Na czyje polecenie? Do czego miał w tej chwili dostęp?

Zmierz, ile to trwało, i policz, w ilu miejscach musiałeś szukać. Jeśli wszystkie cztery odpowiedzi dostałeś z jednego miejsca w kilka minut, Twoje logi już służą człowiekowi. Jeśli potem podasz te same zapisy asystentowi i odpowie na te same cztery pytania bez zgadywania, służą też agentowi. Jeśli któryś z czytelników przegrywa, to jest luka, którą system operacyjny dla SI powinien zamknąć, i powód, dla którego poprzedni wpis skończył się tam, gdzie się skończył: sterowniki dla sprzętu, którego nie znamy są uczciwe tylko wtedy, gdy to, co zgłaszają, zostaje zapisane w miejscu, któremu oboje czytelnicy mogą ufać.