როლბეკი და სტაბილურობის აღდგენა

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

დაბრუნება არის კონტროლირებადი დაბრუნება ბოლო სტაბილურ ვერსიაში, მონაცემთა დაკარგვისა და SLO დარღვევების მინიმალური რისკით. საიმედო პროცესში შედის: SLO სიგნალები, მკაფიო კარიბჭეები და დაბრუნების კრიტერიუმები, გადართვის მექანიზმი (GitOps/Ingress/mesh), თავსებადი მონაცემთა სქემა, იზოლირებული კონფიგურაციები/საიდუმლოებები/ქეში, runabuk და პოსტ-ინციდენტის გაუმჯობესების ციკლი.

1) როდესაც გადადით (გაშვების კრიტერიუმები)

SLO/ბიზნეს კარიბჭეები: ბარიერის ზემოთ p95/99, error-rate, გადახდის/განაკვეთების კონვერტაციის ვარდნა, PSP ტაიმუტის ზრდა.
Techsignals: პოდების დაშლა, მეხსიერების გაჟონვა, რიგების ზრდა, ტოქსინების დეგრადაცია/წმ (LLM), Edge- ზე 5xx.
მონაცემთა რისკი: არასწორი მიგრაცია, რეპლიკების შეუსაბამობა, მართლწერის გარიგებები/გადახდები.
უსაფრთხოება/PII: გაჟონვის ეჭვი - დაუყოვნებლივი დაბრუნება/იზოლაცია.

წესი: თუ 2 + ძირითადი მეტრი ბარიერების მიღმა> N წუთი - გამოტოვება იწყება.

2) როლბეკის ტიპები

1. პროგრამა: კონტეინერების/პაკეტის გამოტოვება წინა ჭდეზე.
2. ფიჩები: მყისიერი გამორთვა flaature/kill-switch მეშვეობით.
3. მარშრუტიზაცია: წონის დაბრუნება სტაბილურ ვერსიაზე (სტაბილური) ან ცისფერი - მწვანე.
4. მონაცემთა ბაზა: ლოგიკური დაბრუნება (ანაზღაურება), სქემის ეტაპობრივი დაბრუნება; PITR უკიდურესი ზომაა.
5. ინფრასტრუქტურა: მანიფესტების გამოტოვება/Terraform გეგმა; ქსელის კონფიგურაციების დაბრუნება/WAF.
6. მონაცემები/ქეში/ხაზები: გამონადენი/ინვალიდობა/შეტყობინებების განმეორება; ოფიციალური ქეში.

3) უსაფრთხო დაბრუნების არქიტექტურული პრინციპები

სქემების თავსებადობა: expand-migrate-contract სტრატეგია (გამოტოვება შესაძლებელია ექსპანსიასა და კონტრაქტს შორის).
იზოლირებული დამოკიდებულებები: ცალკეული საიდუმლოებები/კონფიგურაცია/ქეში/გადასინჯვის ხაზები.
იდემპოტენტური ოპერაციები: მიგრაციის დაწყების განმეორება და ჯობი უსაფრთხოა.
არტეფაქტების იმიტაცია: სურათები, ჩარტები, SQL სკრიპტები - ვერსია და გაფორმებულია.
GitOps ჭეშმარიტება: მიმდინარე ვერსია და მარშრუტიზაცია დაფიქსირდა მანიფესტის საცავებში.

4) დაბრუნების მექანიკა (Kubernetes/GitOps)

Argo Rollouts (წონის დაბრუნება)

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 გამოტოვება (იდეა)

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

NGINX: სწრაფი სვიტრი stable

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) Rolback BD და მონაცემთა დაცვა

• Expand: დაამატეთ ახალი ველები/ინდექსები, კოდი მხარს უჭერს ძველ და ახალ სქემას.
• Migrate: კოდი იწყებს ახალ სქემაში წერას, ძველი არ არის გატეხილი.
• Contract: ამოიღეთ ძველი მხოლოდ სტაბილიზაციის შემდეგ.
• PITR/snaphots: გამოიყენეთ მხოლოდ ლოგიკური კომპენსაციის შეუძლებლობის შემთხვევაში.
• კომპენსაცია: ინდივიდუალური სკრიპტები/ჯობი ჩანართების/ბალანსების/გადახდების გამოსწორების მიზნით.
• Read-only ფანჯარა: კრიტიკის დროს - ჩვენ დროებით ბლოკავს ჩანაწერს მდგომარეობის „გაყინვის“ მიზნით.

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) რიგები და ქეში უკან დახევის დროს

ვერსიის ქეში: გასაღებები ვერსიის პრეფიქსი ('v2:') - უსაფრთხო თანაცხოვრება.
ინვალიდობა: დაბრუნებისას - მასობრივი გაწმენდა 'v2:', დაბრუნება 'v1:'.
რიგები: წვეულებები/ტოპები ვერსიის მიხედვით; შეტყობინებების შესვენება „საკონტროლო წერტილიდან“.
Dedebotation/idempotence: idempotenty გასაღებები ხელახლა დამუშავების გარეშე.

7) SLO კარიბჭეები და მანქანების გამოტოვება

მეტრიკა: p95/99, error-rate, saturations (CPU/IO/GPU), queue depth, ნიშნები/წმ, გადახდის კონვერტაცია.

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) რუნაბუკი (playbooks)

ა) ზრდა p99 და 5xx გამოშვების შემდეგ

1. Stop promote (გაყინვა canary/blue-green).
2. Switch traffic სტაბილური გადასინჯვისთვის.
3. შეამოწმეთ ქეში/ხაზი/PSP შეფერხებები.
4. დიაგნოზის ამოღება: ლოგოები, პროფილები, მომხმარებელთა ვერსიები/სქემები.
5. კომუნიკაცია: ChatOps, სტატუსის არხი, ინციდენტის ბარათი.
6. დაიწყეთ მაკორექტირებელი ეფექტი: patch/ცხელი ფიქსაცია/ჩიპის გაუქმება.

ბ) BD მიგრაციის შეცდომა

1. Freeze writes (read-only, მოკლედ).
2. განაცხადის გამოტოვება - სტაბილური ვერსია (თავსებადია ძველ სქემასთან).
3. კომპენსაციის/rollback სკრიპტის შესრულება.
4. გაყინვა ჩანაწერი; დაათვალიერეთ დრიფტი/შეცდომები.

C) გადახდის დეგრადაცია (PSP)

1. შეცვალეთ PSP მარშრუტიზაცია წინა მარშრუტზე.
2. გამომუშავების დაბრუნება.
3. ყველა დაუმთავრებელი გადახდის შერიგება, გამეორება იდემპოტენტური კლავიშებით.

D) LLM/რეკომენდაციების გაუქმება

1. ახალი მოდელის/პარამეტრების გამორთვა.
2. დაუბრუნეთ წინა წონის/წონის; გაასუფთავეთ ახალი გადასინჯვის KV ქეში.
3. შეამოწმეთ tokens/s, პირველი latency ნიშანი, ტოქსიკურობა.

9) კომუნიკაციები და გამოშვებების გაყინვა

უფასო ფანჯარა: დაბრუნების შემდეგ - გამოშვებების პაუზა RCA/fix- მდე.
ერთი არხი: სტატუს აპდეიტი, მოქმედებების ქრონოლოგია, ვინ რა გააკეთა.
Steekholders: პროდუქტი/CS/გადასახადები/იურისტები (PII).

10) პოსტის ინციდენტი: ანალიზი და პრევენცია

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

11) ხელსაწყოები და შაბლონები

GitOps: Argo CD/Flux - 'revert '/' rollback' კომუნა ვერსიით.
პროგრესული მიწოდება: Argo Rollouts/Flagger - გაჩერება/გამოტოვება მეტრებზე.
Edge/Ingress: წონის მარშრუტი, cookie routing, სწრაფი სვიტრი.
Feature flags: fractional rollout, kill-switch.
DB მიგრაცია: მომენტალური ჩარჩოები up/down, dry-run, throttling.
Observability: მზა დაშბორდები „stable vs canary“.

12) უკან დახევის მზადყოფნის სია

1. ვერსირებული და ხელმოწერილი არტეფაქტები (სურათები/ჩარტები/SQL).
2. ორმაგი სარკინიგზო კონფიგურაცია/საიდუმლოებები/ქეში/რიგები (ვერსიის პრეფიქსი).
3. Expand-migrate-contract BD სქემა.
4. კანარის და ცისფერი მწვანე გამოშვებები SLO კარიბჭეებით და ავტო-გამოტოვებით.
5. ძირითადი სცენარების რუნები (გადახდები/BD/ქეში/LLM).
6. ChatOps ღილაკები: '/rollback ', '/freeze', '/promote '.
7. აუდიტი და ლოჯისტიკა: ვინ, როდის, რა გამოტოვა; დიაგნოზის ნიმუშები.
8. თამაშის დღის ტრენინგი: წარუმატებლობისა და აღდგენის იმიტაცია.
9. ბიზნესთან და საფორტეპიანო კომუნიკაციის გეგმა.
10. შედარების მეტრიკა (stable vs ახალი) ერთ ეკრანზე.

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

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

შედეგები

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