ერთობლივი დაშბორდები

1) რა არის „ერთობლივი დაშბორდები“ და რატომ არიან ისინი ეკოსისტემაში

ერთობლივი დაშბორდები არის მეტრიკის და მოვლენების ერთიანი პანელები, რომლებიც ერთდროულად ხელმისაწვდომია ქსელის რამდენიმე მონაწილეს (ოპერატორები, სტუდიები/RGS, აგრეგატორები, PSP/APM, KYC/AML, აფილატები/მედია, ანალიტიკა, SRE/უსაფრთხოება).
მიზანია შეთანხმებული გადაწყვეტილების მიღება რეალურ დროში (კამპანიები, საგადახდო მარშრუტები, ლიმიტები, ფიგურის დროშები), ხოლო თითოეული მხარე ხედავს ზუსტად იმას, რაც მას აქვს უფლება, ერთ „ჭეშმარიტების წყაროში“.

• მოკლე გზა სიგნალიდან მოქმედებამდე (Observe-Decide მარყუჟის მოქმედება).
• გამჭვირვალე პასუხისმგებლობა SLO/SLA და შეცდომების ბიუჯეტში.
• ნაკლები დავა ატრიბუტისა და ტრაფიკის ხარისხის შესახებ.
• Cost-to-Serve- ის შემცირება ზოგადი მონაცემთა სტანდარტებისა და ვიზუალიზაციის გამო.

2) ტიპიური სცენარები და აუდიტორია

ომის ოთახი/ინციდენტები: p95 ლოგინი/დეპოზიტი/განაკვეთები, მოვლენების საბურავების ლაგი, პროვაიდერების ჯანმრთელობა, გაჩერების ღილაკები.
კამპანიები და ზრდა: FTD/ARPU/LTV არხებით, აფილიატების წვლილი, მისიებისა და ტურნირების დინამიკა, წინსაფარი დროშები.
გადახდები და KYC: CR APM/PSP, 3DS ავტორიზაცია, ჩარჟბეკი, KYC ეტაპის სიჩქარე.
შინაარსი/სტუდია: თამაშის/პროვაიდერების შენარჩუნება, RTP/ცვალებადობა, SLI ცოცხალი ვიდეო.
SRE/Infra: ინტეგრაციის აფთიაქი, p95/p99 API, DR ფირფიტები, headroom და განკარგვა.
უსაფრთხოება/RG: PDN ინციდენტები, ანტიფროდიული სიგნალები, RG გარდერობები, სანქციების დამთხვევები.
ფინანსები: GGR/netto, rake/fee, სესხები/ჯარიმები, Cost-to-Serve, ROI გამოშვებები.

3) დაშბორდის არქიტექტურული ფენა (საიდანაც შედგება)

1. ღონისძიების საბურავი (EDA): დომენის ტოპები 'click/session/bet/spin/deposit/kyc _ status/...' Schema Registry და trace კორელაციით.
2. Data Contracts & Ontology: ერთეულების ერთიანი სახელები, იდენტიფიკატორების ტიპები ('playerId', 'campaignId'), გაზომვის ერთეულები, დროებითი ზონები (UTC/ISO-8601).
3. Metric Store: KPI/SLO კანონიკური გამოთვლები (ვერსირებული ფორმულები), მონაცემთა ხაზები.
4. Real-Time/Streaming ფენა: მატერიალიზებული წარმოდგენები (1-5 წმ), CDC/Stream აგრეგაცია.
5. Access Layer: RBAC + ABAC + ReBAC, მონაცემთა ტოქსიკაცია და შენიღბვა, მრავალფუნქციური იზოლაცია.
6. Visualization & Actions: პანელები, მიმოფანტვა, კონტექსტური მოქმედებები (დროშები, cut-over), შეტყობინებები და ვებჰუკები.

4) მონაცემთა კონტრაქტები და მეტრული კატალოგები

რატომ არის მნიშვნელოვანი: ფორმულების კატალოგის გარეშე, სხვადასხვა მონაწილე მიიჩნევს „FTD“, „CR“, „მოქმედი ანაბარი“ დავების სხვადასხვა გზით.
რა უნდა ჩაწეროთ: მეტრიკის განსაზღვრა, აგრეგაციის ფანჯარა, ფილტრები/გამონაკლისი, წყაროები, მფლობელი, ვერსია.
პრაქტიკა: თითოეული ძირითადი მეტრი მიბმული მფლობელთან (Data Steward) და დომენთან (Council). ფორმულების ვერსიები - სემანტიკური ვერსიის საშუალებით (v1, v1. 1…).

5) ხელმისაწვდომი, კონფიდენციალურობა და ფედერაცია

RBAC + ABAC: როლი ("პარტნიორი. Affiliat"), ატრიბუტები (იურისდიქცია, გარემო, რისკის ნაკადი, verified).
ReBAC: „ვხედავ მხოლოდ კამპანიებს/თამაშებს/ნაკადებს, რომლებსაც მე ვეკუთვნი“.
PII მინიმიზაცია: ნიშნები PDN- ის ნაცვლად, შენიღბვა, პანელის მხარეს დეტოკენიზაციის აკრძალვა.
იურისდიქცია: მონაცემების ლოკალიზაცია და ხილვადობის ფილტრები ქვეყნის მიხედვით; ექსპორტი მხოლოდ ერთეულებია.
წვდომის ჟურნალი: WORM-logs „ვინც დაინახა რა და რა ქმედებები გააკეთა“ TraceId- დან.

6) ნამდვილი დრო და შესრულება (SLO დაშბორდები)

მონაცემთა განახლება (ნაკადი): p95 შეფერხება 1-5 წმ ოპერატიული პანელებისთვის; ფინანსებისთვის - 15 წუთი.
პანელის დახატვა: p95-1.5 წმ ახალი ქეში; გაათბეთ 4 წმ.
ხელმისაწვდომობა: 99.9% ევრო კრიტიკული პანელებისთვის (ომის ოთახი, გადახდები, KYC).
დრილი და ექსპორტები: გაისროლეს მოვლენამდე 2-3 წმ; დანაყოფების ექსპორტი - მშვილდი აუდიტით.
კვოტები და ქეშები: per-tenant rate-limit, ცხელი ვიჯეტის ქეში, რთული მოთხოვნებისთვის.

7) ვიზუალიზაციის ნიმუშები და UX

გლობალური SLO „ქუდი“: p95 ლოგინის/დეპოზიტის/განაკვეთების შუქნიშანი, მოვლენების მიწოდება, RG ინდიკატორები.
სექციები დომენებზე: პროდუქტი, გადახდა, KYC/AML, შინაარსი/Live, Affiliates, SRE/Infra, უსაფრთხოება, ფინანსები.
Dreely: ბილიკი: ანომალიის დაწკაპუნება იწვევს რეგიონის/პროვაიდერის/ვერსიის დაყოფას - გადასვლას ტრასაზე/ლოგზე.
მოქმედებები პანელიდან: გადართეთ A/B/დროშა, შეცვალეთ მარშრუტის პრიორიტეტი, დაიწყეთ cut-over PSP, გაყინეთ ოფშორული (დადასტურებით და აუდიტით).
Guardrails UI- ში: გაფრთხილებები RG/იურისდიქციის/შეცდომების ბიუჯეტის დარღვევის რისკის ქვეშ.

8) დაშბორდის პაკეტების კატალოგი (მზა ნაკრები)

8. 1 ომის ოთახი (ოპერაციული)

p95/p99 კრიტიკული API, KYC გადახდების/აფრების წარმატება, ბროკერის ლაგი, პროვაიდერების მდგომარეობა (outlier-ejection), DR ფლიპები, შეცდომების ბიუჯეტი, გაჩერების ღილაკები.

8. 2 კამპანია/მარკეტინგი/აფილიატები

FTD/CR, არხების/სეგმენტების წვლილი, „ბოლო ელიტარული ტური“ ატრიბუტი, მისიებისა და ტურნირების სიხშირე/შემოსავალი, იურისდიქციის ლიმიტები.

8. 3 გადახდა/PSP/APM

CR ARM/რეგიონში/მოწყობილობაში, p95 ავტორიზაციისთვის, ჩარჟბეკისთვის, ფროიდის სიგნალებისთვის, ავტო-cut-over სახელმწიფოსთვის.

8. 4 KYC/AML

SLA ეტაპები (doc/face/watchlist), FP/FN, მოდულური მიმოხილვის ეტაპი, ანაბრის/განაკვეთზე გავლენის ძაბვა.

8. 5 შინაარსი/სტუდია და ცოცხალი

თამაშების გამართვა/სესიები, RTP/ცვალებადობა, live strim SLI (e2e შეფერხება, packet loss), ლიდერები.

8. 6 SRE/ინფრა

ინტეგრაციის უფსკრული, headroom, გამტარუნარიანობა, rps/event/stream- ის ღირებულება, დაგეგმილი ცვლილების ფანჯრები.

8. 7 ფინანსები

GGR/netto, rake/fee, სესხები/ჯარიმა (SLO- ს მიხედვით), Cost-to-Serve, კამპანიების/არხების მომგებიანობა.

9) პარტნიორობა

• SLI/SLO: აფთიაქი, p95, შეცდომების წილი, საბურავები, პროტოკოლების კონფორმაცია.
• ეკონომიკა: წილი GGR/fee, cost-to-serve, სესხები/ჯარიმა.
• შესაბამისობა/RG: PDN ინციდენტები, RG ტრიგერები, სანქციების შეცდომები.
• ნდობა: ვაჭრობის/ლოგოების სისრულე, აუდიტის პაკეტის მიწოდების სიჩქარე.
• ბარათი ხელმისაწვდომია ორივე მხარისთვის, გაფორმებულია საანგარიშო პერიოდის ბოლოს.

10) ცვლილების მენეჯმენტი (ვერსია, მიგრაცია, A/B)

ვიჯეტების და ფორმულების ვერსია: vN მეტამონაცემებში; „Feature Notes“ ცვლილებების დროს.
A/B- ვუ: იგივე პანელები სხვადასხვა ფორმულით/სექციებით შედარებისთვის; guardrails შეცდომების ბიუჯეტის შესახებ.
Change Windows: პანელების/წყაროების გამოშვების კალენდარი ავტომატური rollback.
Conformance ტესტები: ტესტების გაშვება შერჩევის/ფორმულების სისწორეზე.

11) თავად დაშბორდის დაკვირვება

პანელის მეტრიკები: TTFB, p95 Render, მოთხოვნის შეცდომების სიხშირე, ქეშების ჰიტების წილი.
მონაცემთა ხარისხი: freshness/completeness/uniqueness, schema-violations, drift.
მოქმედების აუდიტი: ვინ შეცვალა დროშა/მარშრუტი/ლიმიტი UI- დან; ორსაფეხურიანი დადასტურება.
ალერტები: „მონაცემები არ განახლდა> N წუთი“, „რეაგირების მკვეთრი ზრდა“, „RG guardrail ახლოს არის ზღურბლთან“.

12) უსაფრთხოება და კონფიდენციალურობა

Zero Trust: mTLS, მოთხოვნის ხელმოწერა (JWS/HMAC), მოკლემეტრაჟიანი ნიშნები, egress-allow-list.
SoD: როლების გამიჯვნა „მე ვუყურებ “/„ მოქმედი “/„ ადმინისტრირება“.
ექსპორტი: მხოლოდ დანაყოფები PDN- ის გარეშე; პერსონალიზაცია - safe ზონებში.
იურისდიქცია: მონაცემთა ფილტრაცია და ლოკალიზაცია, DPIA/DPA; „redline“ ჯვარედინი ბორდერის ექსპორტზე.

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

ბევრი „ჭეშმარიტებაა“: პანელების დუბლები სხვადასხვა ფორმულით - ქაოსი და დავები.
CI „ბრმად“: არ არსებობს ხაზები და ვერსიები - შეუძლებელია გაანგარიშების დამტკიცება.
PII ფანჯარაში: ტოკენიზაციის/შენიღბვის არარსებობა.
მძიმე მოთხოვნები ქეშისა და კვოტების გარეშე: პანელის ვარდნა მწვერვალზე.
დაშბორდი მოქმედების გარეშე: ყველაფერი ჩანს, თქვენ არ შეგიძლიათ შეცვალოთ - სიჩქარე იკარგება.
ერთი SPOF კარიბჭე: არა N + 1 და health-flip არ არის მიუწვდომლობა კრიტიკულ მომენტში.

14) განხორციელების სია

1. დააფიქსირეთ ონტოლოგია და მონაცემთა კონტრაქტები, გამოყავით მეტრიკის მფლობელები.
2. გაზარდეთ Metric Store ფორმულების და ხაზის ვერსიით.
3. Stream ფანჯრების პარამეტრები რეალურ დროში პანელებისთვის, საბრძოლო მასალები ფინანსური ანგარიშებისთვის.
4. ჩართეთ RBAC + ABAC + ReBAC, ტოკენიზაცია, SoD, აუდიტი.
5. შეაგროვეთ მზა პანელების კატალოგი (ომის ოთახი, კამპანიები, გადახდები, KYC, შინაარსი, SRE, ფინანსები).
6. დაამატეთ კონტექსტური მოქმედებები (დროშები, cut-over, limites) დადასტურებით.
7. შეიყვანეთ SLO პანელები (განახლება, რენდერი, წვდომა), კვოტები და ქეში.
8. Sconformance და e2e ტესტები, გააკეთეთ ქვიშის ყუთი/დემო მონაცემები.
9. მოაწყეთ ცვლილებების პორტალი: ჩეინჯლოგი, მიგრაცია, უკუკავშირი.
10. რეგულარული შურისძიება პარტნიორებთან და RCA „დამნაშავეების გარეშე“.

15) სიმწიფის გზის რუკა

v1 (ფონდი): მეტრიკის ერთიანი კატალოგი, საბაზო პანელები, RBAC, batch განახლებები.
v2 (Integration): stream ფანჯრები, ABAC/ReBAC, მოქმედებები პანელიდან, scorecards.
v3 (Automation): ავტო-ალერტები და ავტომობილების დოზა SLI, A/B-Vu ფორმულები, ავტოკეში.
v4 (ქსელის მთავრობა): პანელის ინტერპარტიული პორტფელები, ფედერალური ფანჯრები, ML პრედიკულური მინიშნებები.

16) დაშბორდის წარმატების მეტრიკა

გადაწყვეტილებების სიჩქარე: დრო ანომალიიდან მოქმედებამდე (TTD).
მონაცემთა ერთიანობა: კატალოგიდან დათვლილი მეტრიკის წილი (სინქრონული ვერსიები).
წვდომა და შესრულება: p95 რენდერი, პანელების აფთიაქი, ქეშების ჰიტების წილი.
უსაფრთხოება: PDN ინციდენტები = 0, შენიღბვის/ტოქსიკაციის მოთხოვნის%.
ეკონომიკა: Cost-to-Serve- ის შემცირება, CR/FTD/ARPU- ს ზრდა სწრაფი მოქმედებების წყალობით.
პარტნიორობა: რეგულარული მიმოხილვები, სადავო საქმეების წახალისება.

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

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