ტექნოლოგია და ინფრასტრუქტურა - ღრუბლოვანი არქიტექტურა და SLA
მოღრუბლული არქიტექტურა და SLA
1) რატომ უნდა მართოთ SLA და როგორ
SLA (Service Level Agreement) - ბიზნესის/პარტნიორების გარე დაპირება მომსახურების ხელმისაწვდომობის, სიჩქარისა და სისწორის შესახებ.
SLO (Service Level Objective) - შიდა მიზნობრივი დონე გუნდებისთვის.
SLI (Service Level Indicator) - გაზომილი მეტრიკა, რომლის საფუძველზეც შეფასებულია SLO.
iGaming/fintech- ს ახასიათებს მკაცრი მწვერვალების ფანჯრები (ტურნირები, მსუბუქი განაკვეთები, საანგარიშო პერიოდები, „ხელფასის“ დღეები), ძლიერი დამოკიდებულება PSP/KYC პროვაიდერებზე და გეოგრაფიაზე. SLA- მ უნდა გაითვალისწინოს ეს ქცევა, ხოლო არქიტექტურამ უნდა უზრუნველყოს გარანტიები არა მხოლოდ საშუალო, არამედ პერცენტული.
2) ძირითადი ტერმინოლოგია
წვდომა (Availability) არის წარმატებული ინტერვალის მოთხოვნის წილი.
ლატენტობა - P50/P95/P99 ძირითადი ოპერაციებისთვის.
შეცდომა - ზუსტად განსაზღვრეთ (5xx, ტაიმუტი, ბიზნეს შეცდომა?).
RTO (Recovery Time Objective) - რამდენი დრო დასჭირდება გამოჯანმრთელებას.
RPO (Recovery Point Objective) - რამდენი მონაცემი შეიძლება დაიკარგოს უბედური შემთხვევის დროს.
Error Budget - 1 − SLO, „რეზერვი“ ცვლილებებისა და ინციდენტებისთვის.
3) ღრუბლოვანი არქიტექტურის ჩარჩო SLA- სთვის
3. 1 მრავალმხრივი (Multi-AZ)
სახელმწიფოს რეპლიკაცია (BD, ქეში, რიგები) მინიმუმ 2-3 AZ.
ცივი/თბილი standbay, ავტომატური failover.
ადგილობრივი დაბალანსება (L4/L7) ჯანმრთელობის შემოწმებით per-AZ.
3. 2 მულტირეგიონი
აქტივი აქტივი: დაბალი RTO/RPO, უფრო რთული თანმიმდევრულობა და ღირებულება.
აქტივი (ცხელი/ვარმი): იაფია, RTO უფრო დიდია, მაგრამ მონაცემთა კონტროლი უფრო ადვილია.
გეოგრაფიული როუტინგი (GeoDNS/Anycast), იზოლაცია „blast radius“.
3. 3 შენახვა და მონაცემები
გარიგების დიაპაზონი: სინქრონული რეპლიკაცია რეგიონში, ასინქრონული ინტერრეგიონალური.
ქეში: ჯვარედინი რეგიონალური რეპლიკები, „ადგილობრივი რეალობების + ასინკ warmup“ რეჟიმი.
ობიექტის საცავი: ვერსია, ცხოვრების ციკლები, ჯვრის რეგულირება.
რიგები/ნაკადი: სარკის მტევანი/მრავალ-რეგიონალური ნაკადები.
3. 4 კონტურის იზოლაცია
კრიტიკული სერვისების გამიჯვნა (payments/wallet) და „მძიმე“ ანალიტიკური დავალებები.
Rate-limits/íttas კონტურებს შორის ისე, რომ მოხსენებები არ „ჭამენ“ პროდ.
4) მაღალი ხელმისაწვდომობის ნიმუშები
Bulkhead & Pool Isolation - ნაერთებისა და რესურსების ტყვიების იზოლაცია.
Circuit Breaker + Timeouts არის საგარეო ინტეგრაციის დამოკიდებულებისგან დაცვა.
Idempotence - ვიმეორებთ მოთხოვნებს ორმაგი ჩამოწერის გარეშე.
Graceful Degradation - დეგრადაციის დროს გამორთეთ არაოფუნქციური ფიჩები (ავატარები, გაფართოებული ფილტრები).
Backpressure - აკონტროლეთ შემომავალი ნაკადი, არ დაუშვათ რიგები „ჰორიზონტამდე“.
Chaos/Failure Injection - დაგეგმილი „წარუმატებლობა“ საიმედოობის ჰიპოთეზის შესამოწმებლად.
5) სტრატეგია DR (Disaster Recovery)
არჩევანი: გადახდა/საფულე - მინიმუმ Hot Standby; შინაარსი/კატალოგი - Warm; მოხსენებები - Backup & Restore მკაფიო ფანჯრებით.
6) SLI/SLO- ს შესახებ: როგორ გავზომოთ სწორად
6. 1 SLI დონეზე
კლიენტი SLI: end-to-end (მათ შორის კარიბჭე და გარე პროვაიდერები).
მომსახურების SLI: სამსახურის „სუფთა“ ლატენტობა/შეცდომები.
ბიზნეს SLI: CR (რეგისტრაცია - ანაბარი), T2W (დრო-ვალეტი), PSP-decline რბოლა.
6. 2 SLO მაგალითები
Core API- ს ხელმისაწვდომობა: 99. 95% 30 დღეში.
Payout ინიციაციის ლატენტობა: P95-350 ms, P99-700 ms.
ვებჰუკების მიწოდება PSP: 99. 9% 60 წამში (გამოსხივებით).
Data Freshness მოხსენებები: 10 წუთი lag დროის 95%.
6. 3 Error Budget Policy
ბიუჯეტის 50% - ცვლილებებისთვის (გამოშვებები/ექსპერიმენტები), 50% - ინციდენტებზე.
ბიუჯეტის დაწვა - ფრიზ ფიჩი, მხოლოდ სტაბილიზაცია.
7) პროდუქტიულობა და სკალირება
HPA/VPA SLO ორიენტირებული სიგნალებით (არა მხოლოდ CPU, არამედ ხაზი/ლატენტობა).
პრედიკატიკური სკეილინგი გრაფიკებზე და ისტორიულ მწვერვალებზე დაყრდნობით.
Warm pools/წინასწარ გაათბეთ ფორმირებები BD/PSP ტურნირებამდე.
ქეშირება და edge - RTT- ის შემცირება, განსაკუთრებით თამაშების კატალოგებისა და სტატიკური ასეტებისთვის.
8) ქსელის ფენა და გლობალური ტრაფიკი
Anycast/GeoDNS ლატენტობის შესამცირებლად და უბედური შემთხვევების ლოკალიზაციისთვის.
Failover პოლიტიკოსები: რეგიონის ჯანმრთელობის ტესტები, ბარიერები, „ბედნიერება“ TTL- სთან.
MTLS/WAF/Rate Limit ზღვარზე, ტრაფიკისგან დაცვა.
Egress კონტროლი PSP/KYC allow-list და SLA-aware retras.
9) მონაცემები და თანმიმდევრულობა
თანმიმდევრობის დონის არჩევა: მკაცრი (payments) ღონისძიება (დირექტორია/რეიტინგი).
CQRS კრიტიკული ბრძანებების კითხვისა და ვერტიკალების გადმოტვირთვისთვის.
Outbox/Inbox მოვლენების „ზუსტად ერთხელ“ მიწოდებისთვის.
მიგრაცია dounthaim- ის გარეშე: ექსპანსია-migrate-contract, ორმაგი ჩანაწერი MAJOR ცვლილებების დროს.
10) Observability (Observability) ქვეშ SLA
ბილიკები კარიბჭის საშუალებით: 'trace _ id' კორელაცია პარტნიორთან/რეგიონთან/API ვერსიასთან.
SLO დაშბორდები burn-rate- ით, „ამინდი“ რეგიონებისა და პროვაიდერების მიხედვით.
ალერტები სიმპტომების მიხედვით და არა მარიონეტული სიმპტომების მიხედვით (არა CPU, არამედ P99/შეცდომები).
სინთეტიკა: გარე შემოწმებები ტარგეტის ქვეყნებიდან (TR, BR, EU...).
აუდიტი და ანგარიში: SLI/SLO ექსპორტი პარტნიორულ პორტალზე.
11) უსაფრთხოება და შესაბამისობა
ქსელების სეგმენტი და საიდუმლო მენეჯმენტი (KMS/Vault).
ფრენის/დასვენების დაშიფვრა, PAN/PII ტოქსიკაცია.
როლების დაშვების პოლიტიკოსები ადმირალებისთვის/ოპერატორისთვის.
ლოგოები უცვლელია (WORM) და აუდიტის ჭერი.
მარეგულირებელი: შენახვა რეგიონში, მოხსენებები, SLA- ს შესრულების დადასტურება.
12) FinOps: SLA, როგორც ღირებულების მძღოლი
დააყენეთ SLO გადახედვის ფასები: რამდენი ღირს + 0. წვდომის 01%?
პროფილირებული მწვერვალის ფანჯრები, არ გააფართოვოთ მუდმივი ძალა.
Right-sizing და „spot სადაც შეგიძლიათ“ ფონის დავალებებისთვის.
კონტურების კვოტები და ბიუჯეტები, არ დაუშვათ „უფასო“ დეგრადაცია.
13) საიმედოობის ტესტირება
GameDay/Chaos სესიები: AZ/PSP გამორთვა, რიგების შეფერხება, BGP რღვევები.
DR დრილები: რეგულარული რეგიონების გადართვის ტრენინგი RTO- ს მიზნებით.
Load & Soak: გახანგრძლივება ფსონების/ტურნირების რეალური პროფილებით.
Replay ინციდენტები: ცნობილი ყალბების ბიბლიოთეკა და რეპროდუქციის სკრიპტები.
14) SLA პროცესის მხარე
SLO კატალოგი: მფლობელი, ფორმულა, მეტრიკა, წყაროები, ალერტები.
ცვლილებები RFC/ADR- ის საშუალებით: გავლენის შეფასება error budget- ზე.
პოსტმორტემები: არქიტექტურისა და რანბუკების გაუმჯობესება, SLO- ს კორექტირება.
პარტნიორებთან კომუნიკაცია: შეტყობინებები, სტატუსის გვერდი, პლატფორმა.
15) მაგალითები SLI/SLO/მოხსენებები
15. 1 ფორმულა
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 SLO ნაკრების მაგალითი Core API- სთვის
წვდომა (30 დღე): 99. 95%
P95 endpointe '/v2/payouts/create ': 350 ms ევრო
შეცდომები 5xx (მოცურების 1 საათი): <0. 3%
Webhook delivery ≤ 60 сек (P99): ≥ 99. 9%
RPO საფულისთვის: 60 წამი, RTO - 5 წუთი
15. 3 SLA ანგარიში
დასრულებულია: 99. 97% (SLO 99. 95%) +
დარღვევები: 2 ეპიზოდი BR რეგიონში PSP Timauts- ის გამო (ერთად 8 წუთი).
ზომები: დაემატა smart-routing უკმარისობის კოდებს, გაიზარდა warm pool ნაერთები PSP-B- მდე
16) განხორციელების შემოწმების სია
1. განისაზღვრება კრიტიკული მომხმარებლის გზები და შესაბამისი SLI.
2. SLO 30/90 დღის განმავლობაში + error budget პოლიტიკა.
3. მრავალმხრივი და DR გეგმა RTO/RPO მიზნებით, რეგულარული დრიფტი.
4. სინთეტიკა გეო-ტარგეტისგან, დაშბორდები per-region/per-PSP.
5. სტაბილურობის ნიმუშები: circuit breaker, backpressure, idempotence.
6. დეგრადაციის პოლიტიკა და განთავისუფლების შეცდომები.
7. FinOps: კონტურების ბიუჯეტები, მწვერვალების პროგნოზი, warm pools.
8. უსაფრთხოება: სეგმენტი, დაშიფვრა, აუდიტი.
9. SLA დოკუმენტაცია პარტნიორებისთვის, კომუნიკაციის პროცესი.
10. რეტროსპექტივები და SLO გადასინჯვა ყოველ 1-2 კვარტალში.
17) ანტი შაბლონები
დაპირება SLA გაზომილი SLI და გამჭვირვალე გაანგარიშების მეთოდოლოგიის გარეშე.
განიხილეთ „სამსახურის შესასვლელში“ ხელმისაწვდომობა, კარიბჭის/პროვაიდერების უგულებელყოფა.
დაეყრდნო მხოლოდ საშუალო ლატენტობას, უგულებელყოფს P99 კუდებს.
DR „ქაღალდზე“, რეალური ვარჯიშის არარსებობა.
„მარადიული“ რესურსები ლიმიტების გარეშე: ერთი ანგარიში დაეცემა პროდ.
შეურიეთ პროდი და მძიმე ანალიტიკა ერთ კლასტერში/BD.
18) შედეგი
ღრუბლის არქიტექტურა SLA- ს ქვეშ არის ტექნიკური ნიმუშების ერთობლიობა (multi-AZ/region, იზოლაცია, შეუსაბამო მონაცემები), პროცესები (SLO, error budget, DR drilli) და ეკონომიკა (FinOps). მიეცით საკუთარ თავს პროგნოზირებული გაუმართაობის უფლება: შეამოწმეთ წინააღმდეგობა, გაზომეთ percentiles, შეზღუდეთ „ასაფეთქებელი სხივი“ და ღიად დაუკავშირდით. შემდეგ SLA დაპირებები გახდება არა მარკეტინგი, არამედ კონტროლირებადი საინჟინრო პრაქტიკა.