Backup, odzyskiwanie i rollback

Agent AI właśnie zrefaktoryzował twój moduł uwierzytelniania w 47 plikach. Testy przechodzą. Typy się zgadzają. Scalasz PR. Dwie godziny później tokeny sesji nie są walidowane w admin API — agent usunął rejestrację middleware, która nie była pokryta testami. Musisz cofnąć zmiany, ale trzy inne PR zostały scalone na wierzchu. To jest scenariusz disaster recovery, z którym każdy zespół używający narzędzi AI ostatecznie się spotyka.

Co wyniesiesz z tego rozdziału

• Strategie checkpointów i rollbacków specyficzne dla rozwoju wspomaganego AI
• Procedury odzyskiwania po regresjach wprowadzonych przez AI na każdym etapie pipeline’u
• Kontrole bezpieczeństwa przed uruchomieniem, które zapobiegają katastrofom zanim się wydarzą
• Wzorce reagowania na incydenty związane z AI w środowisku produkcyjnym
• Praktyki audytowe, które przyspieszają i ułatwiają analizę przyczyn źródłowych

Prewencja: Architektura siatki bezpieczeństwa

Najlepsza strategia disaster recovery to zapobieganie katastrofom. Buduj siatki bezpieczeństwa na każdym etapie.

Etap 1: Bezpieczeństwo przed zmianami

Cursor

System checkpointów Cursor zapewnia automatyczne punkty rollbacku:

• Checkpointy są tworzone automatycznie przed każdą akcją agenta
• Użyj panelu Timeline do przeglądania i przywracania dowolnego checkpointu
• Twórz ręczne checkpointy przed operacjami wysokiego ryzyka: kliknij prawym przyciskiem w timeline

Dodaj jawne reguły bezpieczeństwa:

.cursor/rules

SAFETY REQUIREMENTS:
Before any multi-file refactoring:
1. List all files that will be modified
2. Verify the test suite passes BEFORE making changes
3. After changes, run the full test suite
4. If any test fails, revert ALL changes and report what went wrong

NEVER delete files without explicit user confirmation.
NEVER modify configuration files (*.config.*, .env*, Dockerfile) without showing the diff first.

Claude Code

Claude Code pracuje bezpośrednio z Git. Ustanów bezpieczeństwo oparte na commitach:

CLAUDE.md

SAFETY PROTOCOL:
Before starting any multi-file modification:
1. Run: git stash (save any uncommitted work)
2. Create a safety branch: git checkout -b ai/[task-description]
3. Commit after each logical step with descriptive messages
4. Run tests after each commit
5. If tests fail, use git diff to identify the problem

After completing the task:
- Run the FULL test suite (npm test)
- Run type checking (npm run type-check)
- Run linting (npm run lint)
- Show the complete diff from main for review

NEVER force-push. NEVER modify the main branch directly.

System uprawnień Claude Code zapewnia dodatkową warstwę bezpieczeństwa — zapisy plików wymagają jawnego zatwierdzenia, chyba że auto-zatwierdzenie jest włączone w ustawieniach.

Codex

Zadania chmurowe Codex działają w izolowanych sandboxach z wbudowanym bezpieczeństwem:

codex.md

SAFETY PROTOCOL:
- All changes happen in a new branch (never modify main)
- Cloud tasks cannot push directly to main
- Every task produces a PR for human review
- Worktrees provide isolation between parallel tasks

Before submitting a PR:
1. Run the full test suite
2. Run the linter
3. Generate a comprehensive PR description explaining all changes
4. Flag any files that were deleted or had configuration changes

Izolowane środowisko Codex oznacza, że wymknięte zadanie nie może wpłynąć na twoje lokalne środowisko ani inne gałęzie.

Etap 2: Bezpieczeństwo przeglądu

Wskazówka

Gotowy prompt do przeglądu zmian AI:

I need you to review the changes the AI agent just made. Be adversarial.

1. Read the complete diff (git diff main...HEAD)
2. For each modified file, check:
   - Were any function calls removed that are not covered by tests?
   - Were any middleware registrations, event listeners, or side effects changed?
   - Were any error handling paths altered or removed?
   - Were any configuration values changed?
3. List files that were DELETED and verify nothing else depends on them
4. Check for behavioral changes that would pass type-checking but change runtime behavior
   (e.g., changing an async function to sync, changing error types, altering return values)

I am especially worried about silent behavioral changes that tests do not catch.

Etap 3: Bezpieczeństwo wdrożenia

1. Feature flagi dla zmian generowanych przez AI

   Wdrażaj zmiany wspomagane AI za feature flagami. Jeśli coś pójdzie nie tak, przełącz flagę zamiast cofać wdrożenie.

2. Wdrożenia canary

   Kieruj 5% ruchu do nowej wersji. Monitoruj wskaźniki błędów, opóźnienia i kluczowe metryki biznesowe przez 30 minut przed rozszerzeniem.

3. Automatyczne triggery rollbacku

   Skonfiguruj automatyczny rollback, gdy wskaźnik błędów przekroczy 2x linię bazową lub p99 opóźnienia przekroczy 3x linię bazową.

4. Monitorowanie po wdrożeniu

   Obserwuj dashboardy przez 4 godziny po wdrożeniu zmian generowanych przez AI. Tryby awarii kodu AI są często subtelne — edge case’y i warunki wyścigu zamiast crashów.

Procedury odzyskiwania

Scenariusz 1: AI złamało testy (pre-merge)

To jest najłatwiejsze odzyskiwanie. AI dokonało zmian, które łamią zestaw testów.

Cursor

Użyj timeline’u checkpointów Cursor, aby przywrócić ostatni dobry stan:

1. Otwórz panel Timeline
2. Znajdź checkpoint przed łamiącą zmianą
3. Kliknij “Restore”, aby wrócić do tego stanu
4. Alternatywnie użyj Cmd+Z agresywnie — Cursor śledzi zmiany AI oddzielnie od ręcznych edycji

Claude Code

# If working on a branch (recommended):
git diff main  # See what changed
git stash       # Save current state
git checkout main  # Return to clean state

# If you committed incrementally (recommended):
git log --oneline -10  # Find the last good commit
git revert HEAD~3..HEAD  # Revert the bad commits

Codex

PR-y Codex są granicą odzyskiwania. Jeśli PR łamie testy:

1. Zamknij PR bez scalania
2. Utwórz nowe zadanie z bardziej szczegółowymi ograniczeniami
3. Odnieś się do tego, co poszło nie tak: “The previous attempt broke auth middleware registration”

Scenariusz 2: Kod generowany przez AI scalony, ale powoduje problemy produkcyjne

Wskazówka

Gotowy prompt do dochodzenia w sprawie incydentu produkcyjnego:

We have a production incident. The error rate on /api/admin/* endpoints spiked to 15%
after merging PR #847 (AI-assisted auth module refactoring).

Investigate immediately:
1. Show me exactly what PR #847 changed in the auth middleware pipeline
2. Compare the middleware registration order before and after the PR
3. Check if any route-specific middleware was removed or reordered
4. Look at the error logs - what specific error are users hitting?
5. Identify the minimal fix (do not refactor further - just restore correct behavior)
6. Generate the fix as a hotfix PR with only the necessary changes

Speed is critical. Do not optimize or clean up. Fix the regression and nothing else.

Scenariusz 3: AI uszkodziło dane

Najniebezpieczniejszy scenariusz. Kod generowany przez AI wprowadził błąd powodujący uszkodzenie danych.

1. Zatrzymaj krwawienie

   Wdróż rollback natychmiast. Nie próbuj naprawiać w przód, gdy integralność danych jest zagrożona.

2. Oceń szkody

   Zapytaj bazę danych o rekordy zmodyfikowane w oknie czasowym incydentu. Określ zakres uszkodzenia.

3. Przywróć z backupu

   Użyj point-in-time recovery, aby przywrócić dotknięte dane do stanu sprzed incydentu.

4. Analiza przyczyn źródłowych

   Zidentyfikuj, który kod generowany przez AI spowodował uszkodzenie. Czy to była brakująca walidacja? Błędne zapytanie? Warunek wyścigu?

5. Zapobiegaj powtórzeniu

   Dodaj specyficzne przypadki testowe dla trybu awarii. Dodaj ograniczenia bazodanowe, które wyłapią uszkodzenie na warstwie danych. Zaktualizuj reguły AI, aby zapobiec podobnym wzorcom.

Budowanie odporności w przepływach pracy AI

Strategia przyrostowych commitów

Nigdy nie pozwalaj agentowi AI na dokonanie 47 zmian w plikach w jednym commicie. Rozbij duże zmiany na małe, przeglądalne, odwracalne commity.

Wskazówka

Gotowy prompt do przyrostowej refaktoryzacji:

I need to refactor the UserService from a monolithic class to the repository pattern.
This affects approximately 30 files.

DO NOT make all changes at once. Follow this incremental plan:

Commit 1: Create the UserRepository interface and implementation.
          Change nothing else. All existing code still works.
          Run tests.

Commit 2: Add the repository as a dependency to UserService.
          UserService still uses its internal methods (no behavior change).
          Run tests.

Commit 3: Migrate the first method (findById) to use the repository.
          Run tests.

Commit 4: Migrate the next method (create). Run tests.

Continue this pattern for each method. Every commit must:
- Pass all tests
- Be independently revertable
- Change the minimum number of files

Stop after each commit so I can review before continuing.

Strategia testów towarzyszących

Przed jakąkolwiek zmianą generowaną przez AI, stwórz test przechwytujący aktualne zachowanie.

Wskazówka

Gotowy prompt do testów przechwytujących zachowanie:

Before we refactor the auth middleware, I need behavior-capture tests.

For each middleware function in /src/middleware/auth/:
1. Write a test that calls the middleware with a valid request and asserts the EXACT current behavior
2. Write a test that calls it with an invalid request and asserts the EXACT error response
3. Write a test that verifies the middleware chain order (which middleware runs before which)

These tests should FAIL if the refactoring changes any observable behavior.
They are intentionally brittle - that is the point. They are our safety net.

Name them clearly: auth-middleware.behavior-capture.test.ts
After the refactoring is complete and verified, we will remove these in favor of proper tests.

Kiedy coś się psuje

“Scaliliśmy kod AI bez właściwego przeglądu i teraz produkcja leży.” Cofnij natychmiast. Nie próbuj naprawiać w przód podczas aktywnego incydentu. Po cofnięciu przeprowadź bezobwinieniowe post-mortem skupione na tym, jakiej siatki bezpieczeństwa brakowało, a nie kto zatwierdził PR.

“Nie możemy cofnąć, bo inne zmiany zależą od kodu generowanego przez AI.” Dlatego przyrostowe commity mają znaczenie. Jeśli możesz zidentyfikować, który konkretny commit wprowadził problem, możesz cofnąć tylko ten commit. Jeśli zmiany są splątane, możesz potrzebować stworzyć celowany hotfix zamiast pełnego rollbacku.

“AI usunęło pliki, których potrzebujemy, i nie zauważyliśmy tego aż dużo później.” Git cię wspiera. Użyj git log --diff-filter=D, aby znaleźć usunięte pliki i git checkout <commit>^ -- <filepath>, aby je przywrócić. Dodaj kontrolę CI, która flaguje usunięcia plików do dodatkowej kontroli podczas przeglądu kodu.

“Nasza strategia backupu nie obejmuje trybów awarii specyficznych dla AI.” Standardowe strategie backupu (backupy bazy danych, kod w Git) pokrywają większość trybów awarii AI. Unikalne ryzyko z AI to subtelne zmiany behawioralne, które przechodzą wszystkie kontrole. Dodaj behawioralne testy regresyjne dla krytycznych ścieżek i wdrażaj za feature flagami.

Co dalej

Reagowanie na incydenty Automatyzacja dyżurów i obsługa incydentów wspomagana AI.

Pipeline'y CI/CD Wbuduj siatki bezpieczeństwa wdrożeniowe w swój pipeline CI/CD.

Zgodność z bezpieczeństwem Standardy bezpieczeństwa i ścieżki audytowe dla rozwoju wspomaganego AI.