Რატომ არის კრიტიკული API მოთხოვნების შედგენა და გადაკვეთა
სტატიის სრული ტექსტი
1) რატომ არის ლოგო და ტრეისი iGaming- ში
ფული და რეპუტაცია. ნებისმიერი დანაკარგი/დუბლი არის პირდაპირი ზარალი. ჩვენ უნდა დავამტკიცოთ, რომ ოპერაცია ერთხელ ჩატარდა.
მარეგულირებელი. მოხსენება, დავა, გამოძიება - ჟურნალების გარეშე თქვენ ხართ „ბრმა“.
SLO და ინციდენტები. ლატენტობა იზრდება? დეპოზიტის კონვერტაცია ეცემა? ტრეისი ვიწრო ადგილს აჩვენებს.
უსაფრთხოება და ფროიდი. არანორმალური ნიმუშები, რეპერები, სკრიპტის შეტევები - ჩანს ტელემეტრიებში.
დასკვნა: დაკვირვება ფულის დიზაინის ნაწილია და არა „ბოლო შეხება“.
2) რა არის ტრეკისა და გაუმჯობესება
2. 1 კორელაცია მთელ ჯაჭვში
'trace _ id' - ერთი edge - დომენის სერვისების, საბურავების და კონსიუმერების მოთხოვნით.
'span _ id' - თითოეული ჰოპისთვის, 'parent _ span _ id'.
ბიზნესის გასაღებები: 'tenant _ id/brand _ id/region', 'player _ id' (ფსევდონიმი), 'session _ id', 'round _ id', 'settlement _ id', 'idempotency _ key'.
2. 2 რა უნდა დაწეროთ ლოგებში (სტრუქტურა)
ტაიმსტამპი ISO-8601 დროსონთან.
მეთოდი/გზა/სტატუსი, ხანგრძლივობა (ms), payload (ბაიტი) ზომა.
შედეგი და შეცდომის კლასი ('ბიზნეს/4xx/5xx'), კოდი ('RG _ BLOCK', 'DUPLICATE', 'IDEMPOTENCY _ MISMATCH').
მასპინძელი/ბილეთის ზონა/ვერსია, მომსახურების სახელი და გარემო ('eu-west-1').
ქსელის ნიშნები: IP/ASN (საერთო), მომხმარებელი-აგენტი (შემცირებული/ნორმალიზებული).
2. 3 სად - ფენებში
Edge/API gateway: ავთენტურობა, rate limits, geo/bot ფილტრები.
დომენები (Wallet/Bonus/RGS): ბრძანებები/მოვლენები, საგნების სტატუსები, BD/ქეში ლატენტობა.
საბურავი/ხაზი: lag, retry, DLQ, დედაპლატი.
Kacca/PSP: ავტორიზაცია, 3-DS, ციმციმი/როუტი.
3) ფორმატები: მხოლოდ სტრუქტურული ლოგოები
უფასო ტექსტი აზრი არ აქვს ძებნას და ალერტებს. გამოიყენეთ JSON სტრიქონები (ერთი ჩანაწერი - ერთი სტრიქონი).
მაგალითი (შემცირებული):json
{
"ts":"2025-10-23T16:21:05. 481Z",  "env":"prod",  "service":"wallet",  "version":"1. 14. 3",  "level":"INFO",  "event":"bet. settle",  "trace_id":"tr_a1b2c3",  "span_id":"sp_01",  "tenant_id":"brand-7",  "region":"EU",  "bet_id":"b_001",  "round_id":"r_8c12",  "idempotency_key":"settle_r_8c12_1",  "latency_ms":124,  "status":"credited",  "win_minor":1460,  "currency":"EUR"
}4) ტრეისი: OpenTelemetry, როგორც სტანდარტი
HTTP/gRPC/DB/ქეში + კასტომიური სპილოები საგებზე ('authorize' commit- ის settle 'credit').
კონტექსტის პროპაგანდა: W3C Trace Context ('traceparent', 'tracestate'), ვებჰუკებში - სათაურები.
ბარგი: მხოლოდ უსაფრთხო გასაღებები (brand/trace flags), არა PII.
სამპლინგი:- სტანდარტულად 1-10% ზოგადი ტრაფიკისთვის, ყოველთვის 100% ფულადი შეცდომის/ლატენტობისთვის> SLO, დინამიური გაფართოება ინციდენტში.
5) WORM აუდიტი და უცვლელი
კრიტიკული ქმედებებისთვის (შეზღუდვების ცვლილება, კეი-როტაცია, ჯეკპოტის კონფისკაცია, სახელმძღვანელო დამხმარე ოპერაციები) - WORM საცავი (write once read many).
მოთხოვნები: უცვლელი, ხელმოწერები/ჰეში, კომპოზიციის დამოუკიდებელი წვდომა, რეტენჩენი კანონით (მაგალითად, 5-7 წელი).
6) PII და მეტყველების უსაფრთხოება
არ მოაწყოთ PAN, CVV, დოკუმენტი-ID, ელექტრონული ფოსტის/ტელეფონი ღია ფორმით. ნიღაბი/ტოკნიზირება.
ლოგებში გამოიყენეთ მოთამაშის ფსევდო იდენტიფიკატორი (stable hash).
საიდუმლოებები/ნიშნები არასდროს შედის ლოგში (ფილტრები SDK/აგენტის დონეზე).
მონაცემების რეზიდენცია: ჟურნალები და ტრეისი ფიზიკურად რეგიონში (EU/UK/BR...), ცალკეული წვდომის როლები (RBAC/ABAC).
at-rest/in-transit დაშიფვრა, წვდომა - დროებითი ნიშნით, მინიმალური უფლებების პრინციპი.
7) მეტრიკა და SLO, რომლებიც პლატფორმას ინარჩუნებენ
Latency p95/p99 საკვანძო ენდოინტებში: 'bets. authorize`, `bets. settle`, `wallet. credit`, `cashier. deposit`.
Error rate კლასში და კოდში.
Queue/consumer lag (საბურავი),% retrays და „ქარიშხალი“.
Settle lag (შედეგიდან სესხამდე), deposit success rate PSP/geo- სთვის.
Webhook lag p99 თემებზე.
ალერტები - „SLO ბიუჯეტში“ (გადააჭარბა შეცდომების/ლატენტობის ბიუჯეტს ფანჯრის მიღმა - ინციდენტი).
8) გამოძიებისა და დავებისთვის: მინიმალური ნაკრები
ჯვარედინი ბმული 'trace _ id _ event _ id _ idempotency _ key - settlement _ id'.
დროულად საგნების სტატუსის სურათი.
ხელმოწერა/ჰაში მოთხოვნა/ვებჰუკი (არაკომერციული).
კონფიგურაციის ეკრანული/სურათი (ბონუსის/ჯეკპოტის წესების ვერსია) 'ts'.
9) შენახვა და ღირებულება
ცხელი (7-14 დღე): ინციდენტების ძებნა და პოსტმორტემი.
თბილი (30-90 დღე): პროდუქტის ანალიტიკა და ფროიდის ნიმუშები.
ცივი/არქივი (1 წელი): იურიდიული/მარეგულირებელი საჭიროებები.
გამოიყენეთ ფილტრები და ნაკრები, შეინახეთ დანაყოფები, ჩართეთ TTL და შეკუმშვა. გამოიყენეთ ინდექსაცია 'trace _ id', 'tenant _ id', 'event', 'status _ code'.
10) ჩეკის ფურცლები
პლატფორმისთვის/ოპერატორისთვის
- ყველგან არის 'trace _ id', 'idempotency _ key', ჭდეები 'tenant/brand/region ".
- სტრუქტურირებული JSON Logs; OpenTelemetry on HTTP/gRPC/DB/ქეში/ავტობუსი.
- საკრუიზო მოქმედებების WORM აუდიტი; რეგულირების ჭრილობა.
- PII/საიდუმლოებების ნიღაბი; ჟურნალები და ტრეისი - რეგიონების მიხედვით.
- SLO დაშბორდები: p95/p99, error-rate, queue-lag, settle-lag, webhook-lag.
- ალერტები SLO ბიუჯეტში; დეგრადაციის დროს ტრეისების მანქანა-გაფართოება.
- DR/xaoc სავარჯიშოები: ორმაგი მიწოდება, რეგიონის დაცემა, საფულის შეფერხება.
- ლოგებსა და ტრასებზე წვდომა - RBAC/ABAC, ექსპორტისთვის „ოთხი თვალი“.
პროვაიდერისთვის (RGS/live/JP)
- „trace _ id“ და „idempotence _ key“ გამოგიგზავნით/გადადით ყველა გამოწვევასა და ვებჰუკში.
- ლოგები - სტრუქტურირებული; შეცდომის კოდი/კლასი ფიქსირდება.
- ვებჰუკი გაფორმებულია; შევინახავ 'event _ id' და დედუპლიკურს.
- შედეგის/ნაკადის კვალი, გაზომეთ 'settle _ lag'.
- შენიღბვა PII; ნიშნები/გასაღებები არ შედის ლოგებში.
- მე ვქმნი სემპლინგს გონივრულად (100% შეცდომებისა და ფულადი ანომალიებისთვის).
11) ანტი-ნიმუშები (წითელი დროშები)
ტექსტური ლოგოები სტრუქტურის გარეშე და 'trace _ id'.
„idempotence _ key“ არარსებობა write ოპერაციების ლოგოებში.
PII/საიდუმლოებების ლოგიკა, Bearer ნიშნების ჩაწერა.
ყველა რეგიონის ლოგოები ერთ ბაქოში დემარკაციის გარეშე.
Crity მოქმედებებისთვის WORM- ის არარსებობა; „რედაქტირებული“ აუდიტები.
მოვლენები ქვეყნდება outbox/CDC გვერდის ავლით „დაკარგული“ ოპერაციებით.
უსინათლო 100% ვაჭრობა ფილტრების გარეშე (შენახვა, ხმაური).
არ არსებობს SLO/ალერტების დაშბორდები; გამოძიება საათს გრძელდება.
12) ნაბიჯების დანერგვა (რეალისტური)
1. შეიყვანეთ ერთი 'trace _ id' და 'idempotence _ key "ყველა კონტრაქტში (REST/gRPC/webhuks).
2. ლოგების თარგმნა JSON- ზე; დაამატეთ სავალდებულო ველები (მომსახურება, ვერსია, რეგიონი, ტაიმსტამპი, კოდი).
3. დააკავშიროთ OpenTelemetry და კონტექსტის პროპაგანდა; ფულადი გზების მინიმალური ტრეისი.
4. SLO დაშბორებისა და ალერტების კონფიგურაცია; განსაზღვრეთ ბიუჯეტები.
5. ჩართეთ კრიტიკული მოქმედებების WORM აუდიტი; განსაზღვრეთ retenschen.
6. შემოიღეთ PII/საიდუმლოებების ნიღაბი, ჟურნალებზე წვდომის განასხვავება.
7. დაამატეთ ქაოსის შემთხვევები და სავარჯიშოები, შეიმუშავეთ პოსტმორტემები.
8. შენახვის ოპტიმიზაცია: სიმულაცია, TTL, არქივები.
13) შედეგი
ლოგოები და ტრეკები არ არის „მოსახერხებელი“, არამედ პლატფორმისა და iGaming პროვაიდერის შეუდარებელი მოვალეობაა. სტრუქტურირებული ლოგოები, ტრეისები, WORM აუდიტი, PII და SLO დაკვირვება ინციდენტებს კონტროლირებად მოვლენებად აქცევს, ხოლო დავები რეპროდუქციულ შემთხვევებად იქცევა. ამ საძირკველზე ფული ერთხელ მოძრაობს, მოხსენება რეპროდუცირდება ნებისმიერ დროს, ხოლო გუნდი რჩება სწრაფი და მშვიდი - თუნდაც ტურნირების მწვერვალში და გამოშვების დროს.
