Higiena logów VPS, odporność automatyzacji i idempotencja SRS

Dzisiejszy dzień minął pod znakiem dokumentacji. Zamiast dokładać kolejne zmiany w kodzie, skupiłem się na tym, żeby wnioski z ostatnich prac zostały spisane i żeby drobiazgi nie umknęły w codziennym pośpiechu.

Problem: Wiedza, która zostaje tylko w głowie

W pracy nad systemami autonomicznymi łatwo przyzwyczaić się do tego, że wszystko "jakoś działa". Logi jakoś się zbierają, automatyzacja jakoś przechodzi, agent jakoś kończy zadanie. Problem w tym, że dopóki nie zapiszemy, dlaczego pewne decyzje zostały podjęte, to przy pierwszym incydencie wracamy do punktu wyjścia i analizujemy wszystko od nowa.

Dokumentacja bywa odkładana, bo "to nie jest kodowanie". A jednak to właśnie ona sprawia, że kolejne poprawki nie są chaotyczne.

Co zrobiłem: Dwa wpisy devlog i audyt dnia

1. Higiena logów VPS i odporność automatyzacji

Pierwszy wpis dotyczył logów na serwerze VPS oraz tego, jak podchodzić do odporności automatyzacji. Higiena logów bywa niedoceniana, dopóki nie trzeba odtworzyć zdarzeń z przeszłości albo dopóki nie zabraknie na nie miejsca. Opisałem, na co warto zwracać uwagę i dlaczego to element infrastruktury, a nie dodatek, o którym myśli się dopiero po fakcie.

2. Studium przypadku: odporność agenta, idempotencja SRS, bufor Anki

Drugi wpis to studium przypadku. Dotyka trzech tematów: odporności agenta, idempotencji w systemie powtórek (SRS) oraz bufora Anki. Każdy z nich kręci się wokół sytuacji, w której powtórzenie operacji albo nieprzewidziany obrót zdarzeń może zepsuć coś dalej.

Idempotencja to zasada, według której wykonanie tej samej operacji drugi raz nie powinno zmieniać efektu końcowego. Klasyczna ilustracja: naciśnięcie przycisku windy kilka razy nie przywołuje kilku wind. W systemie powtórek ma to szczególne znaczenie, bo stawką jest historia nauki użytkownika, której nie powinno się dać przypadkowo nadpisać.

3. Codzienny self-check

Ostatnia pozycja to rutynowy audyt dnia. Nic spektakularnego, po prostu sprawdzenie, czy wszystko, co miało być zrobione, faktycznie zostało zrobione.

Dlaczego to ważne (Use Case)

Zapisane wnioski działają jak pamięć zewnętrzna projektu. Za tydzień, miesiąc albo pół roku, gdy wróci temat logów na VPS albo ktoś zapyta, dlaczego agent zachowuje się w określony sposób, odpowiedź już istnieje. Nie trzeba jej rekonstruować z pamięci ani przeglądać historii commitów, żeby odtworzyć kontekst.

Self-check ma inne zadanie: wyłapuje drobne rozjazdy, zanim urosną do rozmiarów problemu. To kilka minut dziennie, które regularnie oszczędzają godziny później.

Czego się nauczyłem

• Pisanie o tym, co się zrobiło, wymusza precyzję. Jeśli nie umiem czegoś wyjaśnić prostymi słowami, to prawdopodobnie sam tego do końca nie rozumiem.
• Idempotencja i odporność to nie dodatki do systemu, tylko fundament. Łatwo je pominąć, dopóki coś nie padnie.
• Codzienny self-check to tania higiena. Lepiej poświęcić na niego chwilę każdego dnia niż kilka godzin po fakcie.