Playbooks migracji
1) Klasyfikacja migracji
Schematy DB: dodawanie/zmiana kolumn, indeksy, shading, zmiana typu klucza.
Dane: zasypka/oczyszczenie masy, normalizacja, retencja/archiwizacja.
Usługi i interfejsy API: zmiana punktów końcowych, wersioning, refaktorowanie kontraktów.
Kolejki/autobusy: poruszanie tematów, zmiana klawiszy członkostwa, format zdarzeń.
Infrastruktura: przejście do nowego cluster/K8s/cloud/region, zmiana tajemnic/KMS.
Pamięć masowa i analityka: zmiana silnika (OLTP/OLAP), format/partycja zbiorów danych.
Bezpieczeństwo/zgodność: rotacja klucza, szyfrowanie w locie, geo-lokalizacja danych.
2) Zasady pomyślnej migracji
1. Rozwiń → Migracja → Kontrakt. Najpierw rozszerzamy schemat/zachowanie (kompatybilne), a następnie przesyłamy dane/ruch, a następnie usuwamy stare.
2. Cień & Dual. Odczyt/zapis cienia i podwójny wpis do walidacji.
3. Funkcja flagi i "czerwony przycisk. "Szybkie wyłączenie, aktywacja krok po kroku (percentyl/najemcy/regiony).
4. Idempotencja i powtarzalność. Skrypty i zadania można ponownie uruchomić bez skutków ubocznych.
5. Obserwowalność przed zmianami. Deski rozdzielcze/alerty z wyprzedzeniem, znaki migracyjne w logach/torach.
6. Rollback udokumentowany. Książka startowa jest tak szczegółowa jak plan do przodu.
7. Mini-gry i pauzy. Migrujemy w małych partiach, sprawdzając SLI i niezmiennych firm.
3) Analiza stanu inwentarza i zależności
Mapa konsumentów: usługi, miejsca pracy, raporty, partnerzy zewnętrzni, BI/ETL, haki internetowe.
Kontrakty i schematy: wersje API/event, kompatybilność wsteczna/forward.
Dostęp/sekrety: kto czyta/pisze gdzie są bufory/wskazówki.
Niezmienne domeny: wyjątkowość, równowaga, idempotencja, dzień raportowania.
Woluminy/prędkości: rozmiar danych, RPS, okna szczytowe, RPO/RTO.
4) Kanoniczny szablon playbook (szkielet YAML)
yaml playbook: "migrate-orders-to-v2"
owner: "orders-team"
stakeholders: ["platform", "data", "security", "support"]
change_type: ["schema", "data", "api"]
risk_level: "high"
preconditions:
- "Dashboards ready: latency/error/lag"
- "Runbook rollback validated on stage"
- "Backups verified (restore tested)"
plan:
phase_1_prepare:
steps:
- "Add new nullable columns (expand)"
- "Deploy code with dual-write (flag off)"
- "Enable CDC stream to target"
phase_2_shadow:
steps:
- "Shadow-read v2, compare with v1 (1%)"
- "Fix discrepancies; iterate"
phase_3_dual_write:
steps:
- "Enable dual-write (10%→50%→100%)"
- "Start backfill in batches (size=10k, sleep=200ms)"
phase_4_cutover:
steps:
- "Switch reads to v2 by tenants (canary)"
- "Monitor SLI 30m; expand scope"
phase_5_contract:
steps:
- "Drop old indices/columns after T+14d"
- "Disable old topic/api; update docs/SDK"
guardrails:
abort_if:
- "error_rate > 0. 5% for 5m"
- "p95 > baseline1. 5 for 10m"
- "data_mismatch > 0. 01%"
rollback:
steps:
- "Flip flag: reads back to v1"
- "Stop backfill; continue dual-write to v1"
- "Replay missed events (DLQ→v1)"
validation:
checks:
- "Row counts match within epsilon"
- "Business invariants hold (balances, limits)"
comms:
- channel: "on-call-bridge"
- status_updates: "T-24h, T-1h, start, cutover, finish"
window: "low-traffic Sun 02:00–05:00 UTC"5) Wzory migracji
5. Schematy 1 DB (RDBMS/NoSQL)
Dodaj - nie zmieniaj. Nowe nieważne kolumny/indeksy → kod czyta stare i nowe.
Odbudowa online. Użyj indeksów online/równoległych DDL.
Wersje serializacyjne. Wersja ładunku w kolumnach JSON/Proto/Avro.
Migracja kluczy. Przy zmianie PK - tablica czasu korespondencji + wyzwalacz/CDC.
5. 2 Dane (zasypka/oczyszczenie)
Zasypka CDC +. Najpierw przepływ zmian (aby nadążyć), a następnie zasypka partii.
Partie i terminy. Małe partie z kontrolą opóźnień, punktami kontrolnymi i ponownym uruchomieniem.
Idempotentne aktualizacje. Upsert przez naturalne klucze/wersje.
5. 3 Wydarzenia i kolejki
Wydarzenia wersioniczne. 'event _ type @ vN', konsumenci ignorują nieznane pola.
Poruszanie tematów. Podwójny post, konsumenci czytają z obu przed stabilizacją; potem „cięcie” starego.
Klucz partycji. Migracja kluczowa - poprzez ponowne uruchomienie mapy korespondencji i idempotencji.
5. 4 Usługi i interfejsy API
Niebieski/zielony/kanaryjski. Basen rozgrzewka, częściowy ruch, szybki zwrot.
Flagi Ficha. Według najemców/regionów/procent, obserwowane włączenie.
Umowy. Kontrakty CDC i testy kompatybilności - przed przełączaniem.
5. 5 regionów/kladów
Geo-podwójne nagranie. Dane są rejestrowane w dwóch regionach; odczyty - przez bliskość.
Przeniesienie państwa. Migawka + replikacja; RPO „czerwona linia”, przeładunek DNS/Anycast.
Jurysdykcja. Zgoda/lokalizacja danych, listy „zakazanych” do usuwania zestawów.
6) Fazy realizacji (szczegółowe)
1. Przygotowanie
Deski rozdzielcze, wpisy, limity, flagi funkcji, kopie zapasowe z testem odzyskiwania, uruchom na scenie.
2. Cień (kontrola cieni)
Żądania lustrzane/pisze do nowego systemu bez wpływu na użytkowników. Porównaj odpowiedzi/stany.
3. Podwójny zapis/podwójny odczyt
Piszemy w obu kierunkach. Odczyty - stopniowe przenoszenie do nowego systemu. Rejestry niezgodności są analizowane.
4. Zasypka
Ładujemy historyczne dane w partiach. Kontrolujemy opóźnienie CDC, monitorujemy obciążenie historii/pamięci podręcznej.
5. Cutover (przełączanie)
Canarim według segmentów (najemcy/regiony/procenty). Wspieramy szybki zwrot.
6. Umowa (czyszczenie)
Odciąć stare ścieżki, usunąć przestarzałe pola/indeksy/tematy po „okresie bezpieczeństwa”.
7. Weryfikacja i retro
Raport, metryki, lekcje, aktualizacja playbook/listy kontrolne.
7) Obserwowalność i SLO podczas migracji
Techniczne SLIs: p50/p95/p99, wskaźnik błędów, retry/timeout, wykorzystanie, lag CDC, głębokość kolejki.
Business SLI: sukces transakcji/konwersji, niezmienne (salda, limity, duplikaty).
Etykiety specjalne: 'migration _ id',' phase ',' lokator ',' flag _ state '.
Osłony alarmowe: progi dla ogonów i błędów, „auto-stop” (abort) dla SLO.
Panele porównawcze: v1 vs v2, delta według kluczowych mierników.
8) Scenariusze awaryjne i awaryjne
Logiczny zwrot: flagi/ruch drogowy z powrotem, zamrażanie zasypki.
Dane: „kompensacja” (Saga), powtórka zdarzeń, DLQ → system źródłowy.
Sekrety/klucze: powrót do poprzedniego klucza/certyfikatu (dual-key).
DNS/ruch: „odwrotny dryf” Anycast/ALB, TTL krótki w oknie migracji.
Komunikacja: wstępnie uzgodniony format kanału i statusu.
9) Bezpieczeństwo, prywatność, zgodność
Minimalizacja danych. Przenosimy tylko niezbędne pola; profile anonimizacji na kopii.
Kryptografia. Szyfrowanie „na drucie” i „w spoczynku”, rotacja KMS; kluczowy dziennik operacji.
Czas dostaje się. Tymczasowe role w zakresie pracy migracyjnej, wybór praw po zakończeniu.
Ślady stóp. Maskowanie PD w logach/śladach, ograniczenia eksportu.
10) Zarządzanie zmianami i komunikacja
Kto twierdzi, kto wykonuje, kto jest poinformowany.
Okresy zamrożenia: zakazać nieistotnych zwolnień w oknie migracji.
Statusy: T-24h, T-1h, start, canary, cutover, finish, post-sea.
Partnerzy zewnętrzni: okna kompatybilności, listy kontraktowe, piaskownica testowa.
11) Szablony książek startowych
11. 1 Zasypka (pseudokoda)
for batch in paginate(ids, size=10_000):
try:
rows = read_v1(batch)
upsert_v2 (rows) # idempotently mark_checkpoint (batch. end)
sleep(jitter_ms(100..300))
except Throttle:
sleep (5s) # backpressure respect except Fatal as e:
alert("backfill-failed", e, context=batch)
abort_if_needed()11. 2 Proverka一致nosti (migawka/próbka)
sample = random_ids(n=10_000, stratify=tenant,timestamp)
v1 = fetch_v1(sample); v2 = fetch_v2(sample)
assert schema_compatible(v2)
assert key_invariants_hold (v1, v2) # sum, statuses, versions mismatch_rate = diff (v1, v2). rate()
abort_if(mismatch_rate > 0. 0001)11. 3 Odczyty przełączania
flag. enable("read_from_v2", segment="tenants: cohort_A")
monitor(30m)
if SLO_ok(): expand_segment()
else: rollback_segment()12) Anty-wzory
„Wielki wybuch” zamiast kontraktu na migrację.
Zasypka bez CDC → wieczne nadrabianie zaległości i dryfowanie.
Brak idempotencji → duplikaty/brudne dane.
Ręczne kroki bez skryptów → ludzkie błędy.
Migracja bez desek rozdzielczych/strażników → „ślepy lot”.
Odnowiony rollback → Rollback nie działa w razie potrzeby.
Ignorowanie konsumentów (BI/partnerzy) → złamane raporty/integracje.
13) Lista kontrolna architekta
1. Zdefiniowane cele, granice, typ migracji i rezultaty?
2. Mapa konsumenta i umowy, testy zgodności zielone?
3. Przygotowane deski rozdzielcze, wpisy, tagi 'migration _ id', zestaw SLO/barierki?
4. Zaimplementowany cień i/lub podwójny zapis, backfill idempotent?
5. Czy istnieje praktyczna książeczka startowa, sprawdź powrót z kopii zapasowej?
6. Uzgodnione okno/koordynacja/komunikacja, zamrożenie?
7. Plan krok po kroku z kryteriami kanaryjskimi i rozszerzania/zatrzymywania gotowy?
8. Bezpieczeństwo/zgodność: klucze, dostęp, kanalizacja PII?
9. Czy dokumentacja/SDK/spec jest aktualizowana w tym samym cyklu wydania?
10. Po morzu i aktualizacji playbook po zakończeniu planowane?
Wniosek
Playbooks migracyjne są architektoniczną praktyką zarządzania ryzykiem: małe odwracalne kroki, przejrzyste mierniki, gotowy rollback i dyscyplina „rozszerzaj-migruj-kontrakt”. Zgodnie z opisanymi szablonami migrujesz schematy, dane, usługi i regiony bez przestojów i niespodzianek, zachowując niezmienność biznesu i zaufanie użytkowników.