Rolki i odzyskiwanie stabilności

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Rollback to zarządzany powrót do najnowszej stabilnej wersji z minimalnym ryzykiem utraty danych i naruszeń SLO. Niezawodny proces obejmuje: sygnały SLO, przezroczyste bramy i kryteria wsteczne, mechanizm przełączania (GitOps/Ingress/mesh), kompatybilny schemat danych, izolowane konfiguracje/sekrety/pamięci podręczne, cykl poprawy po zdarzeniu.

1) Kiedy wrócić (kryteria rozpoczęcia)

Bramki SLO/business: p95/99 powyżej progu, wskaźnik błędu, spadek konwersji płatności/kursu, wzrost czasu PSP.
Sygnały techniczne: awarie paleniska, wycieki pamięci, wzrost kolejki, degradacja tokenu/sec (LLM), 5xx na krawędzi.
Ryzyko związane z danymi: nieprawidłowe migracje, niespójność replik, transakcje/płatności osierocone.
Bezpieczeństwo/PII: podejrzenie wycieku - natychmiastowy zwrot/izolacja.

Zasada: jeśli 2 + mierniki kluczy są poza progami> N minut, wałek jest uruchamiany.

2) Rodzaje wałków

1. aplikacji: Rollback kontenerów/pakietu do poprzedniego znacznika.
2. Funkcja: natychmiastowe wyłączenie poprzez flagę funkcji/kill-switch.
3. Routing - zwraca wagę do wersji stabilnej (kanaryjskiej → stabilnej) lub niebieskiej → zielonej.
4. Baza danych: logiczny zwrot (kompensacja), stopniowy zwrot programu; PITR to ostateczność.
5. Infrastruktura: toczące się manifesty/plan Terraform; zwraca konfiguracje sieci/WAF.
6. Dane/pamięć podręczna/kolejki: reset/disability/replay messages; bufory wersji.

3) Architektoniczne zasady bezpiecznego wstecznego

Kompatybilność schematu: rozszerzyć → migrate → strategia kontraktu (rollback jest możliwe między rozszerzeniem a kontraktem).
Izolowane zależności: oddzielne sekrety/konfiguracje/bufory/kolejki do korekt.
Idempotentne operacje: powtarzający się początek migracji i pracy - bezpieczne.
Niezmienność artefaktów: obrazy, wykresy, skrypty SQL - wersjonowane i podpisane.
GitOps true: Aktualna wersja i routing są zaangażowane w repozytorium manifestu.

4) Mechanika wsteczna (Kubernetes/GitOps)

Argo Rollouts (zwrot wagi)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: api }
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 10m }
in case of analysis failure → automatic rollback to stable

GitOps rollback (pomysł)

git revert <commit_with_bad_version>
git push # Argo CD/Flux revert cluster to previous revision

NGINX: szybki włącznik stabilny

nginx map $cookie_canary $to_canary { default 0; 1 1; }
upstream stable { server api-stable:80; }
upstream canary { server api-canary:80; }
server {
location / {
if ($to_canary) { proxy_pass http://canary; }
proxy_pass http ://stable; # removed canary cookie - instant rollback
}
}

5) Rolka bazy danych i ochrona danych

• Rozwiń - Dodaj nowe pola/indeksy, kod obsługuje stary i nowy schemat.
• Migracja: kod zaczyna pisać do nowego schematu, nie łamiemy starego.
• Kontrakt: usunąć stare tylko po ustabilizowaniu.
• PITR/migawki: używać tylko wtedy, gdy kompensacja logiczna nie jest możliwa.
• Rekompensaty: oddzielne skrypty/zadania związane z ustalaniem wkładek/sald/płatności.
• Tylko do odczytu okna: po krytykowaniu czasowo blokujemy nagranie w celu „zamrożenia” stanu.

sql
-- expand
ALTER TABLE wallet ADD COLUMN bonus_balance NUMERIC DEFAULT 0 NULL;
CREATE INDEX CONCURRENTLY idx_wallet_bonus ON wallet(bonus_balance);

-- migrate in code, two-sided write
-- contract (after stabilization)
ALTER TABLE wallet DROP COLUMN legacy_bonus_balance;

6) Kolejki i bufory na rolce

Pamięć podręczna wersji: klawisze wstępnie naprawiane z wersją ('v2:') → bezpieczne współistnienie.
Niepełnosprawność: podczas wstecznego czyszczenia masowego „v2:”, powrót do „v1:”.
Kolejki: strony/tematy według wersji; odpowiadając na wiadomości „z punktu kontrolnego”.
De-dublowanie/idempotencja: klucze idempotencji do duplikatu bez regeneracji.

7) bramki SLO i automatyczne rolki

Wskaźniki: p95/99, szybkość błędów, nasycenie (CPU/IO/GPU), głębokość kolejki, żetony/sec, konwersja płatności.

if p95_latency_ms > 250 for 5m OR error_rate > 1. 5% for 3m OR payment_conv < baseline-0. 3%
then rollback release && open incident && freeze deploys

8) Runabooks (playbooks)

A) Wzrost po uwolnieniu p99 i 5xx

1. Stop promować (zamrozić kanarka/niebiesko-zielony).
2. Przełącz ruch na stabilną wersję.
3. Sprawdź opóźnienie cache hitu/kolejki/PSP.
4. Usuń diagnostykę: dzienniki, profile, wersje klienta/schematu.
5. Komunikacja: ChatOps, kanał stanu, karta incydentu.
6. Rozpocznij działanie naprawcze: patch/hot fix/anulowanie funkcji.

B) Błąd migracji w bazie danych

1. Zamrażanie pisze (tylko do odczytu, krótko).
2. Aplikacja rollback → stabilna wersja (kompatybilna ze starym schematem).
3. Wykonaj skrypt kompensacyjny/rollback.
4. Thaw record; obserwować dryfowanie/błędy.

C) Degradacja płatności (PSP)

1. Przełącz trasę PSP na poprzednią trasę.
2. Zwolnienie przetwarzania wstecznego.
3. Pogodź wszystkie oczekujące płatności, powtórz z idempotent keys.

D) LLM/rozkład zaleceń

1. Wyłączyć nowy model/parametry (flaga funkcji).
2. Zwrócić poprzedni punkt końcowy/wagę; Wyczyść nową wersję pamięci podręcznej KV.
3. Sprawdź żetony, pierwszy token opóźnienia, toksyczność.

9) Komunikacja i zwolnienia zamrażania

Zamrażanie okna: po rollback - zwolnienia pauzy do RCA/fix.
Jeden kanał: aktualizacje stanu, chronologia działań, kto co zrobił.
Zainteresowane strony: Produkt/CS/Płatności/Prawnicy (w PII).

10) Po incydencie: analiza i zapobieganie

RCA (bez opłat): przyczyna główna, czynniki przyczyniające się, dlaczego bramy nie działały (jeśli nie).
Działania: testy migracyjne, limity, bramy funkcji, obserwowalność.
Próg SLO: regulacja, jeśli zbyt „miękki „/” twardy „.
Dokumentacja: aktualizacja runabooks, dodawanie wpisów, trening (gra-day).

11) Narzędzia i szablony

GitOps: Argo CD/Flux - 'revert'/' rollback' commit się z wersją.
Progresywna dostawa: Argo Rollouts/Flagger - stop/roll z powrotem na metrykach.
Krawędź/Ingress: routing wagi, routing ciasteczek, szybki przełącznik.
Flagi funkcyjne: rollout frakcyjny, kill-switch.
Migracja DB: mig-framorks with up/down, dry-run, throttling.
Obserwowalność: gotowe deski rozdzielcze „release compare” (stabilne vs canary).

12) Lista kontrolna gotowości do wałków

1. Wersjonowane i podpisane artefakty (obrazy/wykresy/SQL).
2. Konfiguracje/sekrety/pamięci podręczne/kolejki (prefiksy wersji).
3. Diagram DB przez rozszerzenie → migrate → kontrakt.
4. Kanaryjskie i niebiesko-zielone wydania z bramkami SLO i auto kickbacks.
5. Runabooks dla scenariuszy kluczowych (płatności/DB/cache/LLM).
6. Przyciski ChatOps: '/rollback ', '/freeze', '/promote '.
7. Audyt i rejestrowanie: kto, kiedy, co zwinięte z powrotem; artefakty diagnostyczne.
8. Treningi dnia gry: symulowanie dips i odzyskiwania.
9. Plan komunikacji biznesowej i pomocniczej.
10. Stabilny vs nowy na jednym ekranie.

13) Anty-wzory

Zakłócające migracje przed uruchomieniem kodu (brak kompatybilności wstecznej).
Wspólne bufory/kolejki bez wersji → dirty rollback.
Brak GitOps/Historia zmian → Ręczne edycje na Prod.
Kanaryjskie zwolnienie bez bram/telemetrii → późne wykrywanie.
Rollback bez zamrażania i RCA → powtórzyć incydent.
Monitorowanie tylko metryk technicznych bez wskaźników biznesowych (płatności/stawki).
„Tajemnice wspólne” dla wszystkich rewizji → trudno jest odizolować incydent.

Podsumowanie

Niezawodny rollback nie jest „stop crane”, ale proces wbudowany w wersje: wersioning i kompatybilność, izolowane zależności, bramy SLO, GitOps rzeczywistość, automatyczne rolki i jasne runabooks. Takie podejście pozwala platformom iGaming szybko odzyskać stabilność, minimalizując straty danych i przychodów oraz przekształcając każdy incydent w źródło poprawy.