Przećwiczony rollback z ludzką władzą produkcyjną

Ścieżka rollbacku jest gotowa dopiero wtedy, gdy ma wersjonowany runbook, chronioną tożsamość wykonawczą, obserwowalne kryteria recovery i świeże dowody z ćwiczenia. Agent może przygotować komendę, wskazać rewizję, zebrać wpływ i zweryfikować dry run. Produkcję uruchamia zadeklarowany approver przez bramkę platformy, chyba że osobno zatwierdzona polityka niskiego ryzyka jawnie zezwala na automatyzację.

Pytanie scorecardu: Jak szybko i bezpiecznie potrafisz odwrócić szkodliwą zmianę produkcyjną?

Maksymalna odpowiedź: Testowany rollback jednym poleceniem lub jobem ma ograniczone credentials, nazwaną akceptację, deterministyczne checki recovery i zapisane ćwiczenie.

Kontrakt rollbacku

Zapisz te pola obok workflow deploymentu:

service: checkout-api
rollback_target: immutable release identifier
command: ./scripts/rollback --release RELEASE_ID
approver_role: incident-commander
executor_identity: protected-deploy-job
preconditions:
  - current release matches EXPECTED_RELEASE
  - rollback target is retained and signed
recovery_checks:
  - error-rate burn alert clears for 10 minutes
  - checkout synthetic succeeds from two regions
abort_conditions:
  - data migration is not backward compatible
  - rollback target has an active security block
evidence_retention: incident record and deployment audit

To przykładowy kontrakt repo. Zastąp polecenie i kryteria przetestowanym interfejsem swojej platformy.

Oddziel przygotowanie od wykonania

Deterministyczny alert lub człowiek tworzy rekord incydentu.
Tożsamość diagnostyczna zbiera dowody read-only i proponuje target.
CI sprawdza istnienie targetu, kompatybilność, uprawnienia i dry-run.
Nazwany approver ocenia wpływ i zatwierdza chroniony job.
Tożsamość deploymentu wykonuje jedną operację na niezmiennym artefakcie.
Monitoring ocenia recovery; incident commander deklaruje wynik.
Incydent tworzy dowody regresyjne i następny intent.md.

Rollback nie jest automatycznie bezpieczny. Migracje DB, kolejki, efekty zewnętrzne, formaty cache i klienci mobilni mogą uczynić cofnięcie bardziej ryzykownym niż forward fix.

Prompty do skopiowania

Przygotuj rekord decyzji rollback dla bieżącego incydentu.
Użyj tylko metadanych deploymentu read-only i wersjonowanego runbooka.
Nazwij bieżący i docelowy release, ryzyka kompatybilności, braki,
query recovery, abort conditions i wymaganego ludzkiego approvera.
Nie wykonuj, nie zatwierdzaj i nie używaj credentials produkcji.

Po zakończeniu chronionego joba porównaj zapisane metryki
z kryteriami recovery w runbooku. Cytuj query IDs i timestamps.
Oddziel recovered, not recovered i inconclusive.
Naszkicuj follow-ups; nie zamykaj incydentu.

Gdy rollback zawodzi

Docelowy artefakt zniknął. Zachowuj niezmienne releases i testuj ich pobranie podczas ćwiczeń.

Schema nie jest backward compatible. Użyj expand/contract, forward recovery albo jawnie przetestowanego odtwarzania danych.

Komenda działa, lecz recovery jest nieznane. Zdefiniuj checki usługi i użytkownika przed incydentem.

Ćwiczenie używa innych uprawnień. Testuj prawdziwy chroniony job w bezpiecznym środowisku i audytuj tę samą ścieżkę tożsamości.

Weryfikacja gotowości

Runbook nazywa niezmienne bieżące i docelowe rewizje.
Tożsamość wykonawcza różni się od coding agenta.
Preconditions, abort conditions i recovery są automatyczne, gdzie to możliwe.
Ćwiczenie zapisuje polecenie, aktora, czas, wynik i wnioski.
Migracje danych i efekty zewnętrzne mają recovery path.
Incident commander — nie model — deklaruje recovery.

Powrót dowodów do cyklu

Użyj Deploy dla chronionej bramki release i Maintain dla powrotu incydentu.

Q20 · Akceptacja produkcji Trzymaj władzę produkcyjną poza coding agentem.

Q22 · Detekcja anomalii Uruchamiaj diagnozę read-only z deterministycznej polityki.