Playbooks მიგრაცია

1) მიგრაციის კლასიფიკაცია

DD სქემები: სვეტების დამატება/ცვლილება, ინდექსები, შარდვა, კლავიშების ტიპის შეცვლა.
მონაცემები: მასობრივი backfill/cleanup, ნორმალიზაცია, გადაკეთება/არქივირება.
სერვისები და API: ენდოინების შეცვლა, ვერსიის შეცვლა, კონტრაქტების რეფაქტორი.
რიგები/საბურავები: ტოპიკის გადაადგილება, განაწილების გასაღებების შეცვლა, მოვლენების ფორმატი.
ინფრასტრუქტურა: გადასვლა ახალ კლასტერზე/K8s/ღრუბელი/რეგიონი, საიდუმლოების შეცვლა/KMS.
საცავი და ანალიტიკა: ძრავის შეცვლა (OLTP/OLAP), Datasets- ის ფორმატი/განლაგება.
უსაფრთხოება/შესაბამისობა: გასაღების როტაცია, „ფრენის“ დაშიფვრა, მონაცემების გეო-ლოკალიზაცია.

2) წარმატებული მიგრაციის პრინციპები

1. Expand → Migrate → Contract. ჯერ ჩვენ ვაფართოვებთ სქემას/ქცევას (თავსებადობას), შემდეგ გადავიტანთ მონაცემებს/ტრაფიკს, შემდეგ კი ძველი ამოიღეთ.
2. Shadow & Dual. ჩრდილის შემოწმება (shadow read/write) და ორმაგი ჩაწერა.
3. დროშები და წითელი ღილაკი. სწრაფი გათიშვა, ეტაპობრივი ჩართვა (პერსონალი/ტენანტი/რეგიონები).
4. Idempotence და განმეორება. სკრიპტების და დავალებების გადატვირთვა შესაძლებელია გვერდითი მოვლენების გარეშე.
5. დაკვირვება ცვლილებებზე ადრე. Dashboards/alertes წინასწარ, მიგრაციის ნიშნები ლოგოებში/ტრეისებში.
6. ნაგავსაყრელი დოკუმენტირებულია. Runbook გამოტოვება ისეთივე დეტალურია, როგორც წინსვლის გეგმა.
7. მინი ნაწილები და პაუზები. ჩვენ მიგრირებულნი ვართ მცირე ნაწილებით, შეამოწმეთ SLI და ბიზნეს ინვარიანტები.

3) ინვენტარიზაცია და დამოკიდებულების ანალიზი

მომხმარებელთა რუკა: მომსახურება, ჯობი, მოხსენებები, გარე პარტნიორები, BI/ETL, ვებჰუკი.
კონტრაქტები და სქემები: API/მოვლენების ვერსიები, backward/forward თავსებადობა.
წვდომა/საიდუმლოებები: ვინ კითხულობს/წერს, სადაც კეშები/შენიშვნები.
დომენის ინვარიანტები: უნიკალურობა, ბალანსი, იდემპოტენტობა, საანგარიშო დღე.
მოცულობა/სიჩქარე: მონაცემთა ზომა, RPS, მწვერვალი ფანჯრები, RPO/RTO.

4) პლეიბუკის კანონიკური შაბლონი (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) მიგრაციის ნიმუშები

5. 1 BD სქემები (RDBMS/NoSQL)

დაამატეთ - არ შეცვალოთ. ახალი nullable სვეტები/ინდექსები, კოდი კითხულობს ძველ და ახალს.
ონლაინ აღდგენა. გამოიყენეთ ონლაინ ინდექსები/პარალელური DDL.
სერიალიზაციის ვერსიები. ვერსია payload JSON/Proto/Avro სვეტებში.
კლავიშების მიგრაცია. PK- ის შეცვლისას - შესაბამისობის დროებითი ცხრილი + ტრიგერი/CDC.

5. 2 მონაცემები (backfill/cleanup)

CDC + backfill. ჯერ ცვლილებების ნაკადი (იმისათვის, რომ არ ჩამორჩეს), შემდეგ პაკეტის ზურგჩანთა.
წვეულებები და ვადები. მცირე ბრძოლები ლაგების კონტროლით, ჩეკპოტებით და ხელახალი გაშვებით.
Idempotent apdates. Upsert ბუნებრივი კლავიშებით/ვერსიებით.

5. 3 მოვლენები და რიგები

მოვლენების ვერსია. 'event _ type @ vN', კონსუტერები უგულებელყოფენ უცნობ ველებს.
ტოპიკების გადაადგილება. ორმაგი პუბლიკაცია, მომხმარებლები კითხულობენ ორივედან სტაბილიზაციამდე; შემდეგ ძველი „ჭრა“.
Partition key. გასაღების მიგრაცია - კორესპონდენციის ბარათით ხელახლა გამოქვეყნების გზით და იდემპოტენტურობით.

5. 4 მომსახურება და API

Blue/Green/Canary. აუზის დათბობა, ნაწილობრივი ტრაფიკი, სწრაფი დაბრუნება.
ფიჩას დროშები. ტენანტების/რეგიონების/პროცენტების მიხედვით, შეინიშნება ჩართვა.
კონტრაქტები. CDC კონტრაქტები და თავსებადობის ტესტები გადართვამდე.

5. 5 რეგიონები/კლაუდები

გეო-ორმაგი ჩანაწერი. მონაცემები იწერება ორ რეგიონში; კითხვები - სიახლოვეს.
State transfer. სურათი + რეპლიკაცია; RPO „წითელი ხაზი“, DNS/Anycast ტრანსპორტირება.
იურისდიქციები. მონაცემთა თანხმობა/ლოკალიზაცია, „აკრძალული“ სიები კომპლექტების ამოღებისთვის.

6) შესრულების ფაზები (დეტალურად)

1. მომზადება

დაშბორდები, ალერტები, ლიმიტები, წინსაფარი დროშები, აღდგენის ტესტით დაფები, გაფიცვა სტეჯზე.

2. Shadow (ჩრდილის შემოწმება)

ჩვენ ვირჩევთ მოთხოვნებს/ჩანაწერებს ახალ სისტემაში, მომხმარებლებზე გავლენის გარეშე. ჩვენ ვადარებთ პასუხებს/მდგომარეობას.

3. Dual-write / Dual-read

ორივე მხარეს ვწერთ. კითხვები - თანდათანობით გადავიტანოთ ახალ სისტემაში. ანალიზდება შეუსაბამობის ლოგოები.

4. Backfill

ჩვენ ვატარებთ ისტორიულ მონაცემებს პარტიების მიერ. ჩვენ ვაკონტროლებთ CDC lag- ს, ვაკონტროლებთ storight/ქეში დატვირთვას.

5. Cutover (გადართვა)

კანარიმი სეგმენტების მიხედვით (ტენანტი/რეგიონები/პროცენტი). ჩვენ მხარს ვუჭერთ სწრაფ უკან დაბრუნებას.

6. კონტრაქტი (გაწმენდა)

ჩვენ გავაფართოვებთ ძველ ბილიკებს, ამოიღეთ მოძველებული ველები/ინდექსები/ტოპები „უსაფრთხოების პერიოდის“ შემდეგ.

7. გადამოწმება და რეტრო

ანგარიში, მეტრიკა, გაკვეთილები, ფლეიბუკის/ჩეკის ფურცლების განახლება.

7) მიგრაციის დროს დაკვირვება და SLO

ტექნიკური SLI: p50/p95/p99, error rate, retry/timeout, utilization, lag CDC, რიგების სიღრმე.
ბიზნეს SLI: გარიგების/კონვერტაციის წარმატება, ინვარიანტები (ბალანსი, ლიმიტები, დუბლიკატები).
სპეციალური ეტიკეტები: 'migration _ id', 'phase', 'tenant', 'flag _ state'.
ალერტას მცველები: კუდის ბარიერები და შეცდომები, SLO- ს „ავტო გაჩერება“ (abort).
შედარებითი პანელები: v1 vs v2, „დელტა“ საკვანძო მეტრებში.

8) გამოტოვება და გადაუდებელი სცენარები

ლოგიკური გამოტოვება: დროშები/უკან მიმავალი ტრაფიკის მარშრუტი, ზურგჩანთა გაყინვა.
მონაცემები: „ანაზღაურება“ (საგა), მოვლენების ნიშნები, DLQ - საწყისი სისტემა.
საიდუმლოებები/გასაღებები: წინა გასაღების/სერთიფიკატის დაბრუნება.
DNS/ტრაფიკი: Anycast/ALB „საპირისპირო დრიფტი“, TTL მოკლე მიგრაციის ფანჯარაში.
კომუნიკაციები: წინასწარ შეთანხმებული არხი და სტატუსის ფორმატი.

9) უსაფრთხოება, კონფიდენციალურობა, შესაბამისობა

მონაცემთა მინიმიზაცია. ჩვენ მხოლოდ საჭირო სფეროებს ვატარებთ; ანონიმიზაციის პროფილები ასლებისთვის.
კრიპტოგრაფია. დაშიფვრა „მავთულზე“ და „დასვენებაში“, როტაცია KMS; კლავიშების ოპერაციების ჟურნალი.
დროულად წვდომა. დროებითი როლები მიგრაციის ჯობებისთვის, უფლებების შერჩევა დასრულების შემდეგ.
კვალი. PD- ის შენიღბვა ლოგოებში/ტრეისებში, ექსპორტის შეზღუდვები.

10) ცვლილებებისა და კომუნიკაციის მენეჯმენტი

RACI: ვინ ირწმუნება, ვინ ასრულებს, ვინ არის ინფორმირებული.
უფასო პერიოდები: მიგრაციის ფანჯარაში არარელევანტური გამოშვებების აკრძალვა.
სტატუსები: T-24h, T-1h, დასაწყისი, კანარინგი, cutover, დასრულება, პოსტ-ზღვა.
გარე პარტნიორები: თავსებადობის ფანჯრები, საკონტრაქტო წერილები, სატესტო ქვიშის ყუთი.

11) runbook შაბლონები

11. 1 Backfill (ფსევდო კოდი)

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 შემოწმება (snapshot/ნიმუში)

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 კითხვის შეცვლა

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

12) ანტი შაბლონები

„დიდი აფეთქება“ გამოცდის ნაცვლად.
Backfill CDC გარეშე არის მარადიული დაჭერა და დრიფტი.
იდემპოტენტურობის არარსებობა - დუბლი/ბინძური მონაცემები.
სახელმძღვანელო ნაბიჯები სკრიპტების გარეშე არის ადამიანის შეცდომები.
მიგრაცია დაშბორდების/დაცვის გარეშე არის „ბრმა ფრენა“.
დაუდასტურებელი დაბრუნება, დაბრუნება არ მუშაობს საჭიროების შემთხვევაში.
მომხმარებელთა (BI/პარტნიორების) უგულებელყოფა - „გატეხილი“ მოხსენებები/ინტეგრაცია.

13) არქიტექტორის ჩეკის სია

1. განსაზღვრულია თუ არა შედეგი მიზანი, საზღვრები, მიგრაციის ტიპი და ინვარიანტები?
2. შედგენილია მომხმარებელთა და კონტრაქტების რუკა, მწვანეთა თავსებადობის ტესტები?
3. მომზადებულია დაშბორდები, ალერტები, ეტიკეტები 'migration _ id', SLO/guardrails მითითებულია?
4. ხორციელდება shadow ან/და dul-write, backfill imempotent?
5. პრაქტიკულია rollback runbook, bacap- დან აღდგენის შემოწმება?
6. ფანჯარა/კოორდინაცია/კომუნიკაცია შეთანხმებულია, ჩართულია თუ არა freeze?
7. ეტაპობრივი გეგმა კანარინგით და გაფართოების/შეჩერების კრიტერიუმებით მზად არის?
8. უსაფრთხოება/შესაბამისობა: გასაღებები, წვდომა, PII შეკვეთა?
9. განახლებულია დოკუმენტაცია/SDK/სპეკები იმავე გამოშვებულ ციკლში?
10. დაგეგმილია პოსტ-ზღვა და პლეიბუკის განახლება დასრულების შემდეგ?

დასკვნა

მიგრაციის პლეიბუსები რისკის მართვის არქიტექტურული პრაქტიკაა: მცირე შექცევადი ნაბიჯები, გამჭვირვალე მეტრიკა, მზა გამოტოვება და დისციპლინა „გამოცდა-ფიგურა-კონტრაქტი“. აღწერილი შაბლონების შემდეგ, თქვენ მიგრირებთ სქემებს, მონაცემებს, სერვისებსა და რეგიონებს უსაქმური და სიურპრიზების გარეშე, შეინარჩუნებთ ბიზნესის ინვარიანტებს და მომხმარებელთა ნდობას.