Kompletny scenariusz zdalnego odzyskania¶

Zdarzenie¶

W lokalizacji P12 przestaje odpowiadać N5. Czujniki N2 i Vision N14 działają, ale kolejka analizy magazynu rośnie. Podstawowy WAN jest niedostępny; Starlink działa. UPS ma 68% SOC.

Przebieg¶

N0 wykrywa trzy brakujące heartbeat i porównuje stan switcha, zasilania oraz ostatni log.
N1/N16 przełącza kanał zarządzania na Starlink i podnosi priorytet KVM/audytu.
Broker przestaje przydzielać nowe joby N5; kolejka zachowuje idempotency keys.
N0 próbuje health endpoint i restart runtime — brak odpowiedzi.
Management wysyła kontrolowany restart OS. Po timeout nadal brak POST.
WOL nie pomaga, ponieważ węzeł jest logicznie włączony.
Operator otrzymuje approval związane z node_id=N5, celem „ATX short press” i czasem 10 minut.
ATX short press nie daje rezultatu. KVM pokazuje zawieszenie przed bootloaderem.
Operator wybiera zatwierdzony wpis boot. System startuje w trybie recovery.
Narzędzie sprawdza filesystem, log sterownika i hash konfiguracji. Wykrywa niedokończoną aktualizację runtime.
Rollback przywraca poprzedni podpisany obraz. Węzeł restartuje się.
Attestation, test GPU i canary job przechodzą. N5 wraca z limitem 50% kolejki.
Po godzinie stabilności limit zostaje przywrócony przez wcześniej zatwierdzoną politykę.
Raport wiąże alarm, sesję KVM, approval, obraz recovery, testy i finalny receipt.

sequenceDiagram
    participant N0 as Sentinel
    participant G as Gateway
    participant M as Management
    participant K as KVM/ATX
    participant W as N5 Worker
    participant A as Audit
    N0->>G: primary WAN failed
    G-->>M: Starlink management path
    N0->>M: N5 heartbeat failed
    M->>W: restart runtime / OS
    W--xM: no response
    M->>K: scoped ATX + KVM session
    K-->>M: boot failure visible
    M->>K: signed recovery image
    K->>W: rollback and reboot
    W-->>M: attestation + canary PASS
    M->>A: complete recovery receipt

Walidacja wyniku¶

Recovery jest zakończone tylko, gdy: OS ma właściwy czas, storage jest spójny, config hash pasuje, sterownik GPU przechodzi test, audyt ma ciągłość, canary wynik jest zgodny i nie ma aktywnej sesji KVM. Sam ping nie wystarcza.

Błędy alternatywne¶

Brak obrazu KVM: sprawdzenie kabla/power, drugi KVM lub onsite.
Uszkodzony storage: boot z podpisanego nośnika, restore backup, pozostawienie w kwarantannie.
Niski SOC: pominięcie długiej diagnostyki, shutdown niekrytycznych węzłów, E1.
Brak obu WAN: lokalny runbook N0 i operator fizyczny.
Nieznany hash obrazu: recovery zatrzymane; nie wolno „tymczasowo” ominąć podpisu.
Nieudany rollback: smart plug nie rozwiązuje uszkodzenia danych; wizyta i wymiana nośnika.

Ryzyko i uczenie operacyjne¶

Po incydencie można poprawić alert, retry budget albo obraz recovery, ale nie wolno automatycznie poszerzyć uprawnień N0 dlatego, że człowiek był potrzebny. Zwiększenie autonomii jest osobną decyzją po review dowodów.