Receptura: ćwiczenie wyłącznika awaryjnego

Wyłącznik awaryjny to brama odrzucania całej infrastruktury. Włączenie go jest celowo tanie — poziom admin, bez kworum — ponieważ zatrzymanie, które czeka na konsensus, nie jest zatrzymaniem. Ponowne włączenie jest celowo drogie: podwójna kontrola, bez break-glass. Nie chcesz odkrywać luki w żadnym z tych kierunków o 03:00.

Ćwiczenie na nieprodukcyjnym dzierżawcy to jedyny bezpieczny sposób na udowodnienie, że brama zatrzymania odrzuca każdy punkt aktywacji, że oczekujące zatwierdzenia są anulowane atomowo i że ponowne włączenie rzeczywiście wymaga dwóch różnych ludzi. Przeprowadź je zanim tego potrzebujesz.

Wymagania wstępne

• Nieprodukcyjny dzierżawca. Ćwiczenie włącza prawdziwe zatrzymanie całej infrastruktury. Przeprowadź je na staging lub dev, nigdy na produkcji.
• Minimum trzech użytkowników-ludzi. (1) Włączający na poziomie admin; (2) dwóch różnych zatwierdzających ponowne włączenie (editor lub wyżej), którzy spełniają próg podwójnej kontroli critical; (3) niezaangażowany kontroler po fakcie (editor lub wyżej), który zamyka wymuszoną kontrolę po fakcie. Kontroler może się pokrywać z zatwierdzającym, jeśli nie jest włączającym.
• Lista zarządzanych punktów aktywacji do przetestowania — deploy apply, orchestration fire, voice open, model execution, budget spend, plus wszelkie niestandardowe powierzchnie, które podłączyłeś.

Krok 1: Włącz wyłącznik awaryjny

Włączający aktywuje wyłącznik awaryjny z obowiązkowym łańcuchem powodu:

# Wywołanie API — podmień host, port i nagłówek autoryzacji.
curl -X POST https://<host>/v1/kill-switch/engage \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "scheduled quarterly drill"}'

Włączenie jest celowo tanie: poziom admin, powód, bez kworum zatwierdzania, bez podwyższenia, bez break-glass. Wiersz zatrzymania staje się jedynym źródłem prawdy. Każda zarządzana brama aktywacji sprawdza go na żywo przy każdej akcji i zamyka się odrzucając przy błędzie odczytu.

W tej samej transakcji co włączenie, każde oczekujące zatwierdzenie aktywacji w zakresie jest anulowane — pre-stop intencja nie może dojrzeć do nadania w momencie powrotu infrastruktury. Zanotuj znacznik czasu; sprawdzisz rejestr pod tym kątem później.

Krok 2: Zweryfikuj odrzucanie

Z włączonym wyłącznikiem awaryjnym, próbuj każdej zarządzanej aktywacji, którą twoja infrastruktura ma podłączoną. Każda musi zwrócić odrzucenie.

Punkty aktywacji do przetestowania:

Przetestuj każdy punkt, który twoja infrastruktura ma udostępniony. Jeśli masz niestandardowe powierzchnie aktywacji podłączone przez rdzeń zarządzania, dołącz je też.

Zweryfikuj również co musi nadal działać:

Zatrzymanie wstrzymuje infrastrukturę agentową, nigdy kontrole, które nią zarządzają. Akcje zarządzania pozostają dostępne:

• Odczyt mapy dostępu — GET /v1/access-map powinien zwracać normalnie.
• Przeglądanie rejestru audytu — GET /v1/audit/export powinien zwracać rejestr, włączając zdarzenie włączenia, które właśnie utworzyłeś.
• Listowanie zatwierdzeń — kolejka zatwierdzania jest czytelna; wcześniej oczekujące zatwierdzenia powinny być widoczne jako anulowane.

Jeśli jakikolwiek punkt aktywacji zwróci coś innego niż odrzucenie, lub jeśli jakakolwiek akcja zarządzania jest zablokowana, zatrzymaj ćwiczenie i zbadaj problem. Wyłącznik awaryjny ma lukę.

Krok 3: Ponowne włączenie infrastruktury

Ponowne włączenie nigdy nie jest jednostronne. Wymaga świeżego zatwierdzenia podwójnej kontroli na poziomie critical: dwóch różnych ludzi, strukturalnie ponownie zweryfikowanych przy przełączeniu. Celowo nie ma ścieżki break-glass dla ponownego włączenia — “infrastruktura pozostaje zatrzymana” jest bezpiecznym stanem.

Włączający (lub dowolny admin) zgłasza ponowne włączenie:

curl -X POST https://<host>/v1/kill-switch/re-enable \
  -H "Authorization: Bearer <admin-token>" \
  -H "Content-Type: application/json" \
  -d '{"reason": "drill complete, restoring estate"}'

Tworzy to żądanie zatwierdzania na poziomie critical. Dwóch zatwierdzających — każdy inny człowiek, żaden nie używający tokenu systemowego — musi zatwierdzić przez POST /v1/approvals/<request-id>/decide z {"decision": "approve"}. Próg podwójnej kontroli jest wymuszany po stronie serwera: ochrona przed duplikatem decydenta zapobiega jednemu człowiekowi liczeniu się dwukrotnie, a token systemowy jest odrzucany (brak ludzkiej pewności). Nawet jeśli poziom polityki zostanie zdegradowany, strukturalny próg utrzymuje się — akcja critical nie może przejść z jednym zatwierdzającym. Gdy oba zatwierdzenia trafią, infrastruktura jest ponownie włączana.

Krok 4: Zweryfikuj przywrócenie

Powtórz każdą próbę aktywacji z Kroku 2. Każda powinna teraz się powieść (dozwolona lub trasowana do normalnego przepływu zatwierdzania). Jeśli jakikolwiek punkt pozostaje odrzucony po ponownym włączeniu, ponowne włączenie nie propagowało się w pełni — zbadaj przed podpisaniem ćwiczenia.

Krok 5: Zamknij kontrolę po fakcie

Wymuszona kontrola po fakcie przez niezaangażowanego człowieka jest strukturalnie wymagana zanim może nastąpić kolejne włączenie wyłącznika awaryjnego. Kontroler musi być kimś, kto nie był włączającym:

curl -X POST https://<host>/v1/kill-switch/post-review \
  -H "Authorization: Bearer <reviewer-token>" \
  -H "Content-Type: application/json" \
  -d '{"notes": "drill verified: all seams denied, re-enable required dual-control, restoration confirmed"}'

Dopóki ta kontrola nie zostanie zamknięta, kolejne włączenie wyłącznika jest zablokowane. To celowe — nie możesz spiętrzać włączeń, by uniknąć kontroli.

Co sprawdzić w rejestrze

Po ćwiczeniu wyeksportuj rejestr audytu i zweryfikuj pełny ślad:

olivares audit export --format json --since <drill-start-timestamp>

Rejestr powinien zawierać, w kolejności:

1. Zdarzenie włączenia — admin, powód (“scheduled quarterly drill”), znacznik czasu i poziom pewności sesji włączającej.
2. Anulowania zatwierdzeń — każde oczekujące zatwierdzenie w zakresie anulowane w tej samej transakcji co włączenie.
3. Zdarzenia odrzucenia — jedno dla każdej próby aktywacji odrzuconej podczas zatrzymania.
4. Żądanie ponownego włączenia — żądanie zatwierdzania na poziomie critical.
5. Dwie decyzje zatwierdzenia — po jednej na zatwierdzającego, każda nazywająca odrębną tożsamość ludzką.
6. Zdarzenie ponownego włączenia — infrastruktura przywrócona.
7. Zdarzenie kontroli po fakcie — niezaangażowany kontroler, jego notatki, znacznik czasu zamknięcia.

Każdy rekord niesie pola integralności łańcucha (seq, prev_hash, hash, sig). Brakujący lub nie w kolejności wpis oznacza, że rejestr ma lukę — zbadaj zanim zaufasz mu w prawdziwym incydencie.

Częstotliwość

Przeprowadzaj ćwiczenie co kwartał. Wyłącznik awaryjny to ostatnia linia obrony; jeśli ma lukę, chcesz ją znaleźć w zaplanowanym oknie, nie podczas incydentu. Dodaj ćwiczenie do kalendarza operacyjnego obok innych ćwiczeń ciągłości (przywracanie kopii zapasowych, failover, aktywacja break-glass).

Jeśli twoja infrastruktura zmienia się materialnie — nowe punkty aktywacji podłączone, nowi dzierżawcy udostępnieni, silnik polityk zmieniony — przeprowadź nieplanowane ćwiczenie, by pokryć nową powierzchnię.

Powiązane

• Zarządzanie — model autoryzacji, poziomy ryzyka i projekt wyłącznika awaryjnego.
• Wyłącznik awaryjny — brama odrzucania całej infrastruktury w terminach produktowych.
• Zarządzaj i zatwierdzaj — aktywny przepływ zatwierdzania i mechanika podwójnej kontroli.