GH GambleHub

Cărți de redare pentru migrare

1) Clasificarea migrațiilor

Scheme DB: adăugarea/schimbarea coloanelor, indici, sharding, schimbarea tipului de cheie.
Date: masa de rambursare/curățare, normalizare, retenție/arhivare.
Servicii și API-uri: schimbarea punctelor finale, versionarea, refactorizarea contractelor.
Cozi/autobuze: subiecte în mișcare, schimbarea cheilor de membru, formatul evenimentului.
Infrastructură: trecerea la o nouă cluster/K8s/cloud/region, schimbarea secretelor/KMS.
Stocare și analiză: schimbarea motorului (OLTP/OLAP), formatul/partiționarea seturilor de date.
Securitate/conformitate: rotație cheie, criptare pe zbor, geo-localizare a datelor.

2) Principiile migrației de succes

1. Extindeți → migrați → contract. În primul rând, extindem schema/comportamentul (compatibil), apoi transferăm datele/traficul, apoi îl eliminăm pe cel vechi.
2. Shadow & Dual. Shadow citire/scriere și intrare dublă pentru validare.
3. Caracteristică steaguri și "butonul roșu. "Oprire rapida, activare pas cu pas (percentile/chiriasi/regiuni).
4. Idempotenţă şi repetabilitate. Scripturile și sarcinile pot fi repornite fără efecte secundare.
5. Observabilitate înainte de schimbări. Tablouri de bord/alerte în avans, markeri de migrare în jurnale/piste.
6. Rollback documentat. Runbook rollback este la fel de detaliat ca planul înainte.
7. Mini-jocuri şi pauze. Migrăm în porțiuni mici, verificând SLI și invarianții de afaceri.

3) Analiza inventarului și a dependenței

Harta consumatorilor: servicii, locuri de munca, rapoarte, parteneri externi, BI/ETL, carti web.
Contracte și scheme: versiuni API/eveniment, compatibilitate înapoi/înainte.
Accese/secrete: cine citește/scrie unde sunt cache-urile/indiciile.
Invarianți de domeniu: unicitate, echilibru, idempotență, zi de raportare.
Volume/viteze: dimensiunea datelor, RPS, ferestre de vârf, RPO/RTO.

4) șablon canonic playbook (schelet 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) Modele de migrare

5. 1 scheme DB (RDBMS/NoSQL)

Adăugare - nu se schimbă. Noi nullable coloane/indexuri → cod citește vechi și noi.
Reconstrucție online. Utilizați indici online/DDL-uri concurente.
Versiuni de serializare. Versiunea sarcinii utile în JSON/Proto/Avro coloane.
Migrarea cheie. La schimbarea PK - tabelul de timp al corespondențelor + trigger/CDC.

5. 2 Date (rambursare/curățare)

CDC + rambursare. În primul rând, fluxul de modificări (pentru a ține pasul), apoi rambursarea lotului.
Părţi şi termene limită. Loturi mici cu lag control, puncte de control și repornire.
Actualizări idempotente. Upsert de chei naturale/versiuni.

5. 3 Evenimente și cozi

Versioning evenimente. „event _ type @ vN”, consumatorii ignoră câmpurile necunoscute.
Subiecte în mişcare. Dublu post, consumatorii citesc de la ambele înainte de stabilizare; apoi „tăierea” celui vechi.
Cheia de partiție. Migrația cheie - prin reeditarea cu o hartă a corespondențelor și idempotenței.

5. 4 Servicii și API-uri

Albastru/Verde/Canar. Încălzire în piscină, trafic parţial, revenire rapidă.
Steaguri Ficha. Prin chiriași/regiuni/procente, incluziunea observată.
Contracte. Contractele CDC și testele de compatibilitate - înainte de comutare.

5. 5 Regiuni/Clade

Înregistrare geo-dublă. Datele sunt înregistrate în două regiuni; citiri - de proximitate.
Transfer de stat. Instantaneu + replicare; RPO „linie roșie”, transbordare DNS/Anycast.
Jurisdicții. Consimțământul/localizarea datelor, listele de „interzise” pentru eliminarea kiturilor.

6) Faze de execuție (detaliate)

1. Pregătirea

Tablouri de bord, alerte, limite, steaguri de caracteristici, backup-uri cu un test de recuperare, rula pe o scenă.

2. Umbră (verificare umbră)

Oglinda solicită/scrie la noul sistem fără a afecta utilizatorii. Comparați răspunsurile/stările.

3. Dual-write/Dual-read

Scriem în ambele direcţii. Citiri - se transferă treptat la un nou sistem. Jurnalele neconforme sunt analizate.

4. Backfill

Încărcăm datele istorice în loturi. Controlăm decalajul CDC, monitorizăm sarcina pe poveste/cache.

5. Cutover (comutare)

Canarim pe segmente (chiriași/regiuni/procente). Susţinem o revenire rapidă.

6. Contract (curățenie)

Tăiați căile vechi, ștergeți câmpurile/indexurile/subiectele învechite după „perioada de securitate”.

7. Verificare și retro

Raport, valori, lecții, actualizați playbook/liste de verificare.

7) Observabilitate și SLO în timpul migrației

SLI-uri tehnice: p50/p95/p99, rata de eroare, încercați din nou/timeout, utilizare, lag CDC, adâncimea de coadă.
SLI de afaceri: succesul tranzacțiilor/conversiilor, invarianților (solduri, limite, duplicate).
Etichete speciale: 'migration _ id',' phase ',' chiriaş ',' flag _ state '.
Alert guards: praguri pentru cozi și erori, „auto-stop” (avort) pentru SLO.
Panouri de comparație: v1 vs v2, delta după valori cheie.

8) Rollback și scenarii de urgență

Rollback logic: steaguri/rutare de trafic înapoi, rambursare congelare.
Date: „compensare” (Saga), reluarea evenimentului, DLQ → sistemul sursă.
Secrete/chei: reveniți la cheia/certificatul anterior (dual-key).
DNS/trafic: „derivă inversă” Anycast/ALB, scurt TTL în fereastra de migrare.
Comunicații: canal pre-agreat și format de stare.

9) Securitate, confidențialitate, conformitate

Minimizarea datelor. Transferăm doar câmpurile necesare; profiluri de anonimizare pe copie.
Criptografie. Criptare „pe sârmă” și „în repaus”, rotație KMS; jurnal de operare cheie.
Accesele de timp. Roluri temporare pentru locurile de muncă în domeniul migrației, selectarea drepturilor după finalizare.
Urme de paşi. PD mascare în bușteni/urme, restricții de export.

10) Managementul schimbărilor și comunicații

RACI: cine pretinde cine efectuează, cine este informat.
Perioade de înghețare: interziceți eliberările irelevante în fereastra de migrare.
Statusuri: T-24h, T-1h, start, canar, cutover, finish, post-sea.
Parteneri externi: ferestre de compatibilitate, litere de contract, sandbox de testare.

11) Șabloane Runbook

11. 1 Backfill (pseudocod)


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 (instantaneu/eșantion)


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 Citiri de comutare


flag. enable("read_from_v2", segment="tenants: cohort_A")
monitor(30m)
if SLO_ok(): expand_segment()
else: rollback_segment()

12) Anti-modele

„Big bang” în loc de extindere-migrare-contract.
Backfill fără CDC → eternă catch-up și derivă.
Fără idempotență → duplicate/date murdare.
Pași manuali fără scripturi → erori umane.
Migrație fără tablouri de bord/gărzi → „zbor orb”.
Rollback → rollback fără cunoștință nu funcționează atunci când este necesar.
Ignorarea consumatorilor (BI/parteneri) → rapoarte/integrări defectuoase.

13) Lista de verificare a arhitectului

1. Scopul, limitele, tipul de migrație și invarianții rezultatului definiți?
2. Harta consumatorilor și a contractelor întocmită, testele de compatibilitate sunt verzi?
3. Tablouri de bord, alerte, etichete "migration _ id', set SLO/guardrails?
4. Implementat umbra și/sau dual-write, backfill idempotent?
5. Există un runbook rollback practicat, verificați recuperarea din backup?
6. Fereastră/coordonare/comunicare convenită, congela?
7. Plan pas cu pas cu criterii canare și de expansiune/stop gata?
8. Securitate/conformitate: chei, acces, salubritate PII?
9. Documentația/SDK/specificațiile sunt actualizate în același ciclu de lansare?
10. Post-mare și o actualizare playbook după finalizarea planificată?

Concluzie

Cărțile de migrație sunt o practică arhitecturală de gestionare a riscurilor: pași mici reversibili, metrici transparenți, rollback gata și disciplină „extinde-migrează-contract”. Urmând șabloanele descrise, migrați scheme, date, servicii și regiuni fără întreruperi și surprize, menținând în același timp invarianții de afaceri și încrederea utilizatorilor.

Contact

Contactați-ne

Scrieți-ne pentru orice întrebare sau solicitare de suport.Suntem mereu gata să ajutăm!

Telegram
@Gamble_GC
Pornește integrarea

Email-ul este obligatoriu. Telegram sau WhatsApp sunt opționale.

Numele dumneavoastră opțional
Email opțional
Subiect opțional
Mesaj opțional
Telegram opțional
@
Dacă indicați Telegram — vă vom răspunde și acolo, pe lângă Email.
WhatsApp opțional
Format: cod de țară și număr (de exemplu, +40XXXXXXXXX).

Apăsând butonul, sunteți de acord cu prelucrarea datelor dumneavoastră.