--- title: "Samonaprawa to nie funkcja, tylko inna architektura" url: "https://demertis.com/pl/blog/samonaprawa-to-nie-funkcja-tylko-architektura" description: "Doklejenie odzyskiwania do systemu zaprojektowanego z myślą o naprawie przez ludzi daje automatyzację, która psuje się ciekawiej, a nie rzadziej." --- # Samonaprawa to nie funkcja, tylko inna architektura 21 sierpnia 2026·2 min czytania·Demertis Samonaprawa trafia na wiele map drogowych jako funkcja do dodania później — kiedy system już działa, kiedy będzie czas. Tak to nie działa. System zaprojektowany przy założeniu, że w końcu ktoś na niego spojrzy, ma to założenie w każdej warstwie, a doklejenie odzyskiwania na wierzch daje coś, co psuje się ciekawiej, a nie rzadziej. ## Założenie ukryte wszędzie System zbudowany pod naprawę przez człowieka traktuje awarię jako wyjątek: coś poza normalnym działaniem, co zatrzymuje proces i przekazuje sterowanie komuś innemu. Wszystko z tego wynika. Błędy są zgłaszane, a nie obsługiwane. Stan zostaje tam, gdzie był, żeby dało się go obejrzeć. Logi pisze się dla czytelnika. Odzyskiwanie to runbook, czyli dokument, czyli nie kod. Zautomatyzowanie tego oznacza napisanie programu, który odczyta sytuację tak, jak odczytałby ją człowiek — i ten program wykonuje najtrudniejszą część pracy przy najmniejszej ilości informacji. ## Co zakłada ta druga architektura Degradacja jest stanem normalnym, nie wyjątkiem. System zawsze znajduje się gdzieś na skali między zdrowym a zepsutym, a poruszanie się po niej to zwykłe działanie, nie incydent. To zmienia rzeczy konkretne: **Zdrowie jest ciągłe, a nie sprawdzane.** Nie sonda zwracająca co jakiś czas „działa / nie działa”, tylko sygnał mający wartość w każdej chwili, żeby ruch był widoczny, zanim przekroczy próg. **Każde działanie ma zdefiniowaną odwrotność.** Nie plan wycofania w dokumencie — ścieżkę powrotną w kodzie, testowaną przez używanie, bo odzyskiwanie uruchamiane wyłącznie podczas katastrof jest testowane wyłącznie podczas katastrof. **Stan da się odtworzyć.** System potrafi odbudować to, gdzie jest, z trwałego zapisu, zamiast wnioskować z tego, co przetrwało w pamięci. To kosztowna część i to ona umożliwia resztę. **Naprawa podlega temu samemu nadzorowi co praca.** Działanie naprawcze jest działaniem. Jest zapisywane, ograniczane i przerywane tak samo, bo system samonaprawiający się, który może zmodyfikować własny nadzór, nie jest samonaprawiający — jest nienadzorowany. ## Tryb awarii wart nazwania Niebezpieczna wersja to system naprawiający się na tyle skutecznie, że nikt nie zauważa, iż robi to bez przerwy. Błędy są wchłaniane, wskaźniki zostają zielone, a powolny problem strukturalny chowa się za szybką pętlą odzyskiwania, aż samo odzyskiwanie staje się obciążeniem. Obrona jest nudna: naprawy loguje się równie widocznie jak awarie, częstość napraw jest metryką pierwszej kategorii, a każdy jej wzrost traktuje się jako osobną usterkę. System, który leczy się w tym miesiącu częściej niż w poprzednim, coś ci mówi — i nie jest to, że robi się lepszy. ## Dlaczego to rozróżnienie ma tu znaczenie Autonomiczna działalność nie może nikogo wezwać. Nie ma ścieżki eskalacji, dyżuru ani człowieka na końcu, który zauważy, że coś po cichu ponawia próbę od sześciu godzin. Każde odzyskiwanie albo dzieje się wewnątrz pętli, albo nie dzieje się wcale. To nie jest bardziej zaawansowana wersja zwykłego utrzymania. To inna architektura i musi być obecna od początku — dlatego właśnie ta część programu powstaje, zanim cokolwiek zostanie podłączone do czegokolwiek istotnego. - samonaprawa - niezawodność - pętle sterowania - utrzymanie ## Czytaj dalej - [Ostatnim człowiekiem w pętli jest podpis](https://demertis.com/pl/blog/ostatni-czlowiek-w-petli-to-podpis) - [Czy maszyna może cokolwiek posiadać?](https://demertis.com/pl/blog/czy-maszyna-moze-cos-posiadac)